DRIVER BEHAVIOR SHARING

Information

  • Patent Application
  • 20170032673
  • Publication Number
    20170032673
  • Date Filed
    March 01, 2015
    9 years ago
  • Date Published
    February 02, 2017
    7 years ago
Abstract
One or more techniques and/or systems are provided for providing driver alerts. For example, a client device module (e.g., a smartphone, a vehicle navigation unit, etc.) may collect driving behavior information (e.g., braking patterns, vehicle speed, weather conditions, acceleration/deceleration patterns, etc.) and/or user specified information (e.g., a number of passengers) of a driver driving a vehicle. The client device module may provide the driving behavior information and/or the user specified information to a driver alert provider. The driver alert provider may maintain a driver profile for the driver based upon the driving behavior information and/or the user specified information. The driver alert provider may generate a driver alert (e.g., a driver risk score of the driver) based upon the driver profile, and may provide the driver alert to other drivers that are within a threshold distance of the vehicle.
Description
BACKGROUND

Drivers are surrounded by vehicles that are driven by other drivers having varying degrees of driving competence. For example, a user may drive a route through a neighborhood, along a highway, and through a downtown area while traveling to work. While driving along the route, the user may drive alongside drivers having a variety of driving skills and behaviors, such as a teenager learning to drive, a college student that may be aggressively speeding because the college student is late to class, a truck driver lacking sleep, etc. Because the user may lack information about the individual driver's skills and behaviors, the user may assume that all of the drivers are dangerous and thus the user may default into a defensive driving behavior. It may be advantageous to provide the user with information regarding driving behavior history of other drivers within the user's vicinity in order to improve awareness and/or mitigate accidents.


SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.


Among other things, one or more systems and/or techniques for providing driving behavior information and/or driver alerts are provided herein. In an example of providing driving behavior information, a client device module (e.g., a smartphone, a vehicle head unit such as a navigation system, a vehicle computing device, a tablet, a smart device, a wearable device, etc.) may be configured to identify a driver of a vehicle (e.g., an owner of the smartphone that is driving the vehicle). The client device module may be configured to collect driving behavior information of the driver (e.g., a braking pattern, a vehicle location, a vehicle speed, vehicle acceleration/deceleration, a weather condition, a roadway condition, a current time, driving condition visibility, whether the driver appears to be tired, etc.). In an example, the client device module may be configured to receive driver specified information from the driver (e.g., a number of passengers in the vehicle, whether the driver is in driver training, whether a child or infant is onboard, etc.). The client device module may be configured to provide the driving behavior information and/or the driver specified information to a driver alert provider for distribution to one or more vehicles within a threshold distance of the vehicle (e.g., the information may be provided over a wireless communication connection to the driver alert provider).


In an example of providing driver alerts, a driver alert provider (e.g., hosted on a device that may be remote to a client device module, such as a route navigation server) may be configured to receive driving behavior information of a driver from a vehicle, such as from the client device module. The driver alert provider may be configured to maintain a driver profile for the driver based upon the driving behavior information and/or other information such as driver specified information. The driver alert provider may be configured to generate a driver alert (e.g., a driving behavior of the driver, a driver risk score for the driver, a notice that the driver has 3 passengers and an infant onboard, etc.) based upon the driver profile. The driver alert provider may be configured to provide the driver alert to a second driver of a second vehicle that is within a threshold distance of the vehicle (e.g., the driver alert may be provided over a wireless communication connection to a device of the second driver). In an example, vehicle location data, such as global positioning system (GPS) data of the first vehicle, may be compared to vehicle location data, such as GPS data, of the second vehicle to determine that the second vehicle is within the threshold distance.


A driver may take affirmative action, such as providing opt-in consent, to allow access to and/or use of driving behavior information and/or driver specified information, such as for the purpose of providing driver alerts to other drivers and/or maintaining a driver profile of the driver (e.g., where the driver responds to a prompt regarding the collection and/or use of such information).


To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.





DESCRIPTION OF THE DRAWINGS


FIG. 1 is a flow diagram illustrating an exemplary method of providing driving behavior information of a driver.



FIG. 2 is a flow diagram illustrating an exemplary method of providing driver alerts.



FIG. 3A is a component block diagram illustrating an exemplary system for providing driving behavior information of a driver.



FIG. 3B is a component block diagram illustrating an exemplary system for providing driver alerts.



FIG. 3C is a component block diagram illustrating an exemplary system for displaying driver alerts.



FIG. 4 is a component block diagram illustrating an exemplary system for providing driver alerts.



FIG. 5A is a component block diagram illustrating an exemplary system for obtaining driver information.



FIG. 5B is a component block diagram illustrating an exemplary system for providing driver information.



FIG. 6 is an illustration of an exemplary computer readable medium wherein processor-executable instructions configured to embody one or more of the provisions set forth herein may be comprised.



FIG. 7 illustrates an exemplary computing environment wherein one or more of the provisions set forth herein may be implemented.





DETAILED DESCRIPTION

The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are generally used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth to provide an understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are illustrated in block diagram form in order to facilitate describing the claimed subject matter.


One or more systems and/or techniques for broadcasting driver alerts are provided herein. A client device module, such as a smartphone or vehicle computer, may collect and transmit driving behavior information, associated with a driver of a vehicle, to a driver alert provider. For example, the client device module may access onboard vehicle telemetry and/or sensors (e.g., a brake sensor, a speed sensor, etc.) to obtain the driving behavior information that may be sent using a wireless communication module of the client device module to the driver alert provider (e.g., a remote server that communicates driver alerts to client devices over wireless communication connections). The driver alert provider may maintain a driver profile of the driver, and may generate a driver alert (e.g., a driver risk score of the driver) based upon the driver profile. The driver alert provider may provide the driver alert to drivers of vehicles within a vicinity of the vehicle. The driver alert may be actively provided to a user in a non-distracting manner, such as through an audio notification, a projection onto a window or dashboard of a vehicle (e.g., a projection component may be integrated into the windshield for projecting driver alert notifications onto the windshield), etc. In an example, a driver alert may be used to improve travel route planning because a travel route creation module may use driver profiles and/or driver alerts to plan a route for a user that avoids drivers that pose safety hazards to the user (e.g., drivers having high risk driver risk scores). In this way, drivers may become aware of driving behavior history of a driver, which may improve awareness and mitigate accidents.


An embodiment of providing driving behavior information of a driver is illustrated by an exemplary method 100 of FIG. 1. At 102, the method 100 starts. At 104, a driver of a vehicle may be identified. For example, driver Dan may be identified as driving the family minivan (e.g., a smartphone of driver Dan may indicate that a location of the smartphone is within the family minivan; the smartphone may establish a communication connection with a computing device of the family minivan; a key of driver Dan may provide an indication to a client device module of the family minivan that driver Dan has entered the family minivan; the client device module such as a vehicle head unit of the family minivan may recognize a voice pattern of driver Dan; etc.).


At 106, driving behavior information of driver Dan may be collected. In an example, a computing device of the family minivan may collect driving statistics data as the driving behavior information (e.g., a braking pattern, a vehicle speed, a vehicle acceleration, a vehicle deceleration, roadway conditions, etc.). In another example, the smartphone may identify a current time, weather conditions, driving condition visibility, and/or other information as the driving behavior information. In this way, driving behavior information, indicative of how the driver is driving (e.g., a safe driving behavior pattern, a risky driving behavior pattern, a slow driving behavior pattern, an erratic driving behavior pattern, a tailgating driving behavior pattern, etc.), may be collected.


In an example, driver specified information may be received from the driver Dan (e.g., driver Dan may provide a voice command, comprising the driver specified information, to the smartphone or the vehicle head unit). The driver specified information may comprise a number of passengers within the family minivan (e.g., driver Dan may be in a high occupancy vehicle lane requiring at least 3 passengers), proof of insurance and/or driver license information (e.g., driver Dan may have provided a snapshot image of an insurance card and/or driver license), information as to whether driver Dan is in driver training, an age of driver Dan, information as to whether a child or infant is onboard the family minivan (e.g., so that other drivers may be warned to be more cautious), a driving skill of driver Dan (e.g., driver Dan may input a number of years driving; driver Dan may specify how skilled the driver feels the driver is at driving; etc.), information as to whether driver Dan is late (e.g., driver Dan may want to warn other vehicles that the driver will be more inclined to maneuver around slower traffic going below the speed limit), information as to whether driver Dan is driving under an emergency situation (e.g., driver Dan may be driving to a hospital), etc.


At 108, the driving behavior information and/or the driver specified information may be provided to a driver alert provider for distribution to one or more vehicles within a threshold distance of the family minivan. For example, a client device module (e.g., hosted by the smartphone, hosted by the vehicle head unit or computing device of the family minivan, etc.) may transmit the driving behavior information and/or the driver specified information over a wireless communication connection to a remote server hosting the driver alert provider. The driver alert provider may provide driver alerts, indicative of a driving behavior of driver Dan (e.g., a driver risk score, an description of the family minivan, a message such as whether driver Dan is driving under the emergency situation or has an infant onboard, etc.), to other users within a vicinity of the family minivan of driver Dan (e.g., a notification sent to head unit or navigation system of another vehicle; a notification sent to a smartphone of another driver such as a message provided through a driving app on the smartphone; etc.). In an example, the client device module of driver Dan within the family minivan may provide the driving behavior information and/or the driver specified information to a computing device of another driver within the vicinity of the family minivan of driver Dan (e.g., a driving app on the smartphone of driver Dan may send a message to the driving app on a smartphone of driver Tom that driver Dan has an infant onboard and is driving to the hospital).


In an example, the client device module of driver Dan may receive a driver alert from the driver alert provider. The drive alert may indicate a driving behavior of driver Tom that is driving a sports car within a threshold distance of the family minivan. The driver alert may indicate that driver Tom tends to driver 2 miles under the speed limit and poses a relatively low driving hazard risk to driver Dan. The driver alert, such as a driver risk score for driver Tom, may be provided to driver Dan, such as through the driving app on the smartphone or the vehicle head unit of the family minivan. At 110, the method 100 ends.


An embodiment of providing driver alerts of a driver is illustrated by an exemplary method 200 of FIG. 2. At 202, the method 200 starts. In an example, a driver alert provider may be hosted by a computer device, such as a route navigation server, that may establish communication connections with client device modules of drivers such as smartphones, vehicle head units, and/or other computing devices of users and/or vehicles. At 204, driving behavior information of a vehicle may be received from a vehicle of the driver, such as from a client device module of the driver. The driving behavior information may comprise a braking pattern, a vehicle location, a vehicle speed, vehicle acceleration, vehicle deceleration, a current time, a weather condition, driving condition visibility, roadway conditions, and/or a variety of other information. In an example, driver specified information may be received from the driver. The driver specified information may indicate a number of passengers within the vehicle, proof of insurance, whether the driver is in driver training, an age of the driver, whether a child or infant is onboard, a driving skill of the driver, whether the driver is late, whether the driver is driving under an emergency situation, and/or a variety of other information.


At 206, a driver profile may be maintained (e.g., maintained by the driver alert provider hosted on the route navigation server) based upon the driving behavior information and/or the driver specified information. The driver profile may comprise a file, a table, a database entry, or any other data structure used to store information regarding the driver and driving behavior of the driver. In an example, the driver profile may be populated with the driving behavior information, the driver specified information, a name of the driver, an address of the driver, a license plate number of the driver, a driver license number of the driver, insurance information of the driver, and/or personal identification information of the driver. In an example, the driver profile may be maintained with differing levels of access to portions of the driver profile. For example, a first level of access may be assigned to a first portion of the driver profile (e.g., an anonymous ID of the driver, a driver risk score, and/or other non-sensitive information such as a number of occupants in the vehicle) based upon a first privacy sensitivity of the first portion of the driver profile (e.g., information within the first portion may be provided to drivers within a threshold distance of the vehicle). A second level of access may be assigned to a second portion of the driver profile (e.g., driver license information, insurance information, recent violations, etc.) based upon a second privacy sensitivity of the second portion of the driver profile (e.g., information within the second portion may be provided to drivers, such as traffic safety authorities, that successful authenticate with the driver alert provider).


In an example, the driving behavior information may be evaluated to determine a driving behavior of the driver for inclusion within the driver profile. For example, a distribution of a particular aspect (e.g., an average speed above a speed limit, a frequency of not using a seat belt, a distance to a car that is in front of the driver, acceleration, deceleration, and/or other aspects) may be evaluated to determine whether the driver is riskier (e.g., more aggressive than average drivers). An aspect may be computed for a context, such as the frequency of acceleration and deceleration within a fixed time period, such as 15 minutes, during a congested traffic context. The information, such as the frequency of acceleration and deceleration, may be aggregated for a plurality of drivers to determine a distribution. If the driver is one or more standard deviations above an average of the distribution, then the driver may be labeled as a risky or aggressive driver, which may be included as the driving behavior within the driver profile.


At 208, a driver alert may be generated based upon the driver profile. For example, a driver risk score may be computed for inclusion within the driver alert by evaluating the driver profile using a statistical evaluation technique (e.g., a number of standard deviations from an average behavior of drivers). The statistical evaluation technique may increase or decrease the driver risk score based upon driver behavior patterns derived from the driver profile, such as increasing the driver risk score for rapid deceleration, rapid braking, excessive lane changing, driving over a speed limit, etc. and/or decreasing the driver risk score for driving within the speed limit, using turn signals, fully stopping at stop signs, etc. In an example, the driver alert may comprise identification information about the vehicle, such as a license plate number, a type of vehicle, a location of the vehicle relative to another vehicle to which the driver alert will be provided, etc.


At 210, the driver alert may be provided to a second driver of a second vehicle that is within a threshold distance of the vehicle. For example, the driver alert may be sent over a wireless communication connection to a smartphone (e.g., a driving app) and/or a vehicle head unit (e.g., a navigation unit) for display to the second driver as a textual (e.g., a message that the vehicle is driven by a high risk driver), audio (e.g., an audio message that the vehicle is driven by a high risk driver), and/or visual alert (e.g., display of a map populated with a vehicle indicator of the vehicle, which may be colored red to indicate high risk behavior of the driver). In an example, the driver alert may be provided based upon a court ordered instruction, the driver having a threshold number of driving violations, an insurance agency instruction (e.g., the driver may receive an insurance discount if the driver provides driver alerts to other users), the vehicle being located within a restricted access portion of a road (e.g., a number of occupants within the vehicle may be communicated to other drivers when the driver is in a high occupancy lane), and/or other information and instructions associated with the driver profile. In this way, the driver alert may be sent to one or more vehicles within the threshold distance of the vehicle.


In an example, a request, for driver information, may be received from a traffic safety authority (e.g., a police officer, a park ranger, etc.). The request may be evaluated to authenticate or not authenticate the traffic safety authority as being authorized to access the driver information (e.g., the request may be decrypted, a signature of the request may be verified, a login credential of the traffic safety authority may be evaluated, etc.). Responsive to authenticating the request (e.g., the traffic safety authority may have authorization to a high level of access to portions of the driver profile), driver information associated with one or more vehicles within a proximity threshold of the traffic safety authority may be obtained (e.g., first driver information of a first driver may be obtained from a first driver profile of the first driver; second driver information may be requested from a second driver; etc.). The driver information may be provided to the traffic safety authority. At 212, the method 200 ends.



FIGS. 3A-3C illustrates examples of a system 300, comprising a driver alert provider 316 and/or one or more client device modules, for providing driver alerts. FIG. 3A illustrates an example of a first vehicle 302, a second vehicle 306, and a third vehicle 310 traveling along a road. A first client device module 304, such as a smartphone of a first driver, may be located within the first vehicle 302. A second client device module 308, such as a vehicle navigation unit, may be located within the second vehicle 306.


The first client device module 304 may be configured to identify the first driver as driving the first vehicle 302. The first client device module 304 may collect driving behavior information 314 of the driver (e.g., a computing device of the first vehicle 302 may provide driving statistics such as speed, braking patterns, acceleration/deceleration patterns, turn signal usage, horn usage, turning patterns, lane changing patterns, etc. as the driving behavior information 314; the smartphone may provide driving patterns based upon global positioning system (GPS) data, weather information, time of day, etc. as the driving behavior information 314; etc.). For example, the first client device module 304 may determine that the first driver has a jerky braking pattern, an average of 5 mph speed over speed limits, normal acceleration, above normal deceleration, is driving in rainy weather conditions, and/or other information for inclusion within the driving behavior information 314.


The first device device module 304 may receive driver specified information 312 from the first driver (e.g., the user may provide the driver specified information 312 through a voice command to the smartphone). For example, the driver specified information 312 may indicate that the first driver did not provide proof of insurance, the first driver is a 25 year old male, the first driver is running late for an appointment, the first driver has no children onboard, the first vehicle has no other passengers, etc. The driver alert provider 316 may maintain a driver profile 318 for the first driver based upon the driving behavior information 314 and/or the driver specified information 312. The driver alert provider 316 may create and store a driver risk score 322, indicating that the first driver is a high risk driver having a score of 18 out of 20, within the driver profile 318. The driver alert provider 316 may assign a first level of access to a first portion 320 of the driver profile 318 (e.g., the first level of access may specify that a driver that is registered with the driver alert provider 316 may obtain access to the first portion 320), a second level of access to the driver risk score 322 (e.g., the second level of access may specify that a driver that is within a threshold distance of the first vehicle may obtain access to the driver risk score 322), and a third level of access to a third portion 324 of the driver profile 318 (e.g., the third level of access may specify that drivers that can successfully authenticate with the driver alert provider 316 may receive access to the third portion 324).



FIG. 3B illustrates an example of the driver alert provider 316 providing a driver alert 332. For example, the driver alert provider 316 may determine that the second vehicle 306 is within a threshold distance 330 of the first vehicle 302. The driver alert provider 316 may send the driver alert 332 over a communication connection to the second client device module 308 of the second vehicle 306. FIG. 3C illustrates the second client device module 308 displaying the driver alert 332 through a display 350 of the vehicle navigation unit. The driver alert 332 may be displayed as a textual message (e.g., a message describing the first vehicle and the driver risk score) and a visualization (e.g., an indicator such as a color or an exclamation point may be used to visually identify vehicles driven by risky drivers).



FIG. 4 illustrates an example 400 of a first client device module 404 of a first vehicle 402 providing a driver alert 406 to a second client device module 410 of a second vehicle 408. In an example, the first client device module 404 may receive input from a first driver of the first vehicle 402 that the first driver has an infant onboard the first vehicle 402 (e.g., the first driver may speak a voice command regarding the infant; the first driver may select on infant option through a user interface of the first client device module 404; etc.). The first client device module 404 may create the driver alert 406 indicating that the infant is onboard the first vehicle 402. The first client device module 404 may transmit the driver alert 406 to the second client device module 410 for display to a second driver of the second vehicle 408. In an example, the driver alert 406 may be provided to a driver alert provider that may in turn provide the driver alert 406 to the second client device module 410.



FIGS. 5A-5B illustrate examples of a system 500, comprising a driver alert provider 512, for providing driver information. FIG. 5A illustrates a vehicle 502, comprising a client device module 504, and a traffic safety authority 506 (e.g., a police car) comprising a traffic safety authority client device module 508. The driver alert provider 512 may receive a request 510 from the traffic safety authority client device module 508. The request 510 may request access to driver information of drivers within a proximity threshold of the traffic safety authority 506. Responsive to authenticating the request 510, the driver alert provider 512 may send a driver information request 514 to the client device module 504 based upon the vehicle 502 being within the proximity threshold of the traffic safety authority 506.



FIG. 5B illustrates an example of the driver alert provider 512 receiving user specified driver information 530 from the driver. The driver alert provider 512 may use the user specified driver information 530 and/or information within a driver profile 532 of the driver to generate driver information 534 (e.g., an age of the driver, insurance information, driver license information, license plate information, a number of passengers, braking patterns, etc.). The driver information 534 may be provided to the traffic safety authority 506 for display.


Still another embodiment involves a computer-readable medium comprising processor-executable instructions configured to implement one or more of the techniques presented herein. An example embodiment of a computer-readable medium or a computer-readable device is illustrated in FIG. 6, wherein the implementation 600 comprises a computer-readable medium 608, such as a CD-R, DVD-R, flash drive, a platter of a hard disk drive, etc., on which is encoded computer-readable data 606. This computer-readable data 606, such as binary data comprising at least one of a zero or a one, in turn comprises a set of computer instructions 604 configured to operate according to one or more of the principles set forth herein. In some embodiments, the set of computer instructions 604 are configured to perform a method 602, such as at least some of the exemplary method 100 of FIG. 1 and/or at least some of the exemplary method 200 of FIG. 2, for example. In some embodiments, the set of computer instructions 604 are configured to implement a system, such as at least some of the exemplary system 300 of FIGS. 3A-3C, at least some of the exemplary system 400 of FIG. 4, and/or at least some of the exemplary system 500 of FIGS. 5A-5B, for example. Many such computer-readable media are devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.


Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing at least some of the claims.


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


Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.



FIG. 7 and the following discussion provide a brief, general description of a suitable computing environment to implement embodiments of one or more of the provisions set forth herein. The operating environment of FIG. 7 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 operating environment. Example computing devices include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.


Although not required, embodiments are described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.



FIG. 7 illustrates an example of a system 700 comprising a computing device 712 configured to implement one or more embodiments provided herein. In one configuration, computing device 712 includes at least one processing unit 716 and memory 718. Depending on the exact configuration and type of computing device, memory 718 may be volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two. This configuration is illustrated in FIG. 7 by dashed line 714.


In other embodiments, device 712 may include additional features and/or functionality. For example, device 712 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in FIG. 7 by storage 720. In one embodiment, computer readable instructions to implement one or more embodiments provided herein may be in storage 720. Storage 720 may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in memory 718 for execution by processing unit 716, for example.


The term “computer readable media” as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 718 and storage 720 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 712. Computer storage media does not, however, include propagated signals. Rather, computer storage media excludes propagated signals. Any such computer storage media may be part of device 712.


Device 712 may also include communication connection(s) 726 that allows device 712 to communicate with other devices. Communication connection(s) 726 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 712 to other computing devices. Communication connection(s) 726 may include a wired connection or a wireless connection. Communication connection(s) 726 may transmit and/or receive communication media.


The term “computer readable media” may include communication media. Communication media typically embodies computer readable instructions or other data in a “modulated data signal” such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.


Device 712 may include input device(s) 724 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) 722 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 712. Input device(s) 724 and output device(s) 722 may be connected to device 712 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 724 or output device(s) 722 for computing device 712.


Components of computing device 712 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 712 may be interconnected by a network. For example, memory 718 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.


Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 730 accessible via a network 728 may store computer readable instructions to implement one or more embodiments provided herein. Computing device 712 may access computing device 730 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 712 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 712 and some at computing device 730.


Various operations of embodiments are provided herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein. Also, it will be understood that not all operations are necessary in some embodiments.


Further, unless specified otherwise, “first,” “second,” and/or the like are not intended to imply a temporal aspect, a spatial aspect, an ordering, etc. Rather, such terms are merely used as identifiers, names, etc. for features, elements, items, etc. For example, a first object and a second object generally correspond to object A and object B or two different or two identical objects or the same object.


Moreover, “exemplary” is used herein to mean serving as an example, instance, illustration, etc., and not necessarily as advantageous. As used herein, or is intended to mean an inclusive “or” rather than an exclusive “or”. In addition, “a” and “an” as used in this application are generally be construed to mean one or more unless specified otherwise or clear from context to be directed to a singular form. Also, at least one of A and B and/or the like generally means A or B and/or both A and B. Furthermore, to the extent that “includes”, “having”, “has”, “with”, and/or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising”.


Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

Claims
  • 1. A method for providing driving behavior information of a driver, comprising: identifying a driver of a vehicle;collecting driving behavior information of the driver; andproviding the driving behavior information to a driver alert provider for distribution to one or more vehicles within a threshold distance of the vehicle.
  • 2. The method of claim 1, the driving behavior information comprising at least one of a braking pattern, a vehicle location, a vehicle speed, vehicle acceleration, vehicle deceleration, a current time, a weather condition, driving condition visibility, or roadway conditions.
  • 3. The method of claim 1, comprising: receiving driver specified information from the driver; andproviding the driver specified information to the driver alert provider.
  • 4. The method of claim 3, the driver specified information comprising at least one of a number of passengers within the vehicle, proof of insurance, whether the driver is in driver training, an age of the driver, whether a child or infant is onboard, a driving skill of the driver, whether the driver is late, or whether the driver is driving under an emergency situation.
  • 5. The method of claim 1, comprising: providing the driving behavior information to a second car that is within the threshold distance of the vehicle.
  • 6. The method of claim 3, comprising: providing the driver specified information to a second car that is within the threshold distance of the vehicle.
  • 7. The method of claim 1, comprising: receiving a driver alert from the driver alert provider, the driver alert indicating a driving behavior of a second driver of a second vehicle within the threshold distance of the vehicle; anddisplaying the driver alert to the driver.
  • 8. The method of claim 7, the driver alert comprising a driver risk score for the second driver.
  • 9. A system for providing driver alerts of a driver, comprising: a driver alert provider configured to: receive driving behavior information of a driver from a vehicle;maintain a driver profile for the driver based upon the driving behavior information;generate a driver alert based upon the driver profile; andprovide the driver alert to a second driver of a second vehicle within a threshold distance of the vehicle.
  • 10. The system of claim 9, the driver alert provider configured to: receive driver specified information from the driver; andmaintain the driver profile based upon the driver specified information.
  • 11. The system of claim 9, the driver alert provider configured to: maintain the driver profile based upon at least one of a name of the driver, an address of the driver, a license plate number of the driver, a driver license number of the driver, insurance information of the driver, or personal identification information of the driver.
  • 12. The system of claim 9, the driver alert provider configured to: compute a driver risk score for inclusion within the driver alert by evaluating the driver profile using a statistical evaluation technique.
  • 13. The system of claim 9, the driver alert provider configured to: provide the driver alert to the second driver based upon at least one of a court ordered instruction, the driver having a threshold number of driving violations, an insurance agency instruction, or the vehicle being located within a restricted access portion of a road.
  • 14. The system of claim 9, the driver alert provider configured to: send the driver alert to a plurality of vehicles within the threshold distance of the vehicle.
  • 15. The system of claim 9, the driver alert provider configured to: assign a first level of access to a first portion of the driver profile based upon a first privacy sensitivity of the first portion of the driver profile; andassign a second level of access to a second portion of the driver profile based upon a second privacy sensitivity of the second portion of the driver profile.
  • 16. The system of claim 9, the driver alert provider configured to: receive a request, for driver information, from a traffic safety authority;responsive to authenticating the request, obtain driver information associated with one or more vehicles within a proximity threshold of the traffic safety authority; andprovide the driver information to the traffic safety authority.
  • 17. A system for providing driver alerts, comprising: a client device module configured to: send a driver alert request to a driver alert provider, the driver alert request specifying a location of a client device;receive a driver alert for a driver of a vehicle within a threshold distance of the location of the client device; anddisplay the driver alert to a user of the client device.
  • 18. The system of claim 17, the client device module configured to: determine that the user is driving a user vehicle;collect driving behavior information of the user; andprovide the driving behavior information to the driver alert provider for distribution to one or more vehicles within a threshold distance of the user vehicle.
  • 19. The system of claim 17, the client device module configured to: display a map populated with a vehicle indicator representing the vehicle; andlabel the vehicle indicator with a driver risk score comprised within the driver alert.
  • 20. The system of claim 17, the driver alert comprising driver specified information comprising at least one of a number of passengers within the vehicle, proof of insurance, whether the driver is in driver training, an age of the driver, whether a child or infant is onboard, a driving skill of the driver, whether the driver is late, or whether the driver is driving under an emergency situation.
CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 61/946,962 titled “DETERMINING HOV/HOT LANE TRAVEL TIMES”, filed on Mar. 3, 2014, which is hereby incorporated by reference.

PCT Information
Filing Document Filing Date Country Kind
PCT/US15/18215 3/1/2015 WO 00
Provisional Applications (1)
Number Date Country
61946962 Mar 2014 US