Patent Description:
Driving a vehicle while drowsy is dangerous. The National Highway Traffic Safety Administration of the U. government estimated that, between <NUM> and <NUM>, drowsy driving has the following affects: <NUM>,<NUM> police-reported crashes per year; <NUM>,<NUM> injuries per year; and more than <NUM> deaths per year.

The document <CIT> discloses an on-vehicle information processing device that comprises an other-vehicle position detector that detects a position of another vehicle existing in a vicinity of an own vehicle, and a communication unit that acquires, via communication, other-vehicle information including driver dynamic information from said other vehicle whose position is detected by said other-vehicle position detector, said driver dynamic information indicating a current state of activity of a driver of said other vehicle. A controller controls calling attention of a driver of said own vehicle or traveling of said own vehicle based on said driver dynamic information acquired by said communication unit.

It is an object underlying the present invention to provide an improved way for detecting a presence of a drowsy driver of a vehicle based on Vehicle-to-Everything communications. According to the invention, this object is achieved by a method according to claim <NUM> and a system according to claim <NUM>. Further features and advantageous modifications are shown in the dependent claims.

Described herein are embodiments of a drowsy detection system that is installed in an onboard vehicle computer of a connected vehicle (an "ego vehicle"). In some embodiments, the drowsy detection system is operable to provide two solutions to the problem of drowsy driving, wherein the claimed invention refers to the second solution and the first solution shows an unclaimed comparative example.

The first solution according to the unclaimed comparative example is now described. Vehicles are increasingly equipped with Dedicated Short-Range Communication (DSRC) capabilities. DSRC-equipped vehicles transmit Basic Safety Messages ("BSM" if singular or "BSMs" if plural) at a regular interval (e.g., once every <NUM> seconds). BSMs have a mandatory payload that includes, among other things, information about the path history of the vehicle that transmits the BSM. A remote vehicle is driven by a drowsy driver. The remote vehicle is DSRC-equipped, and it regularly transmits BSMs that include path history data of the remote vehicle. The drowsy detection system includes software installed on an ego vehicle that receives the BSMs from the remote vehicle and analyzes the path history data to identify the presence of the drowsy driver. The ego vehicle is driven by an ego driver. The drowsy detection system is operable to notify the ego driver of the presence of the drowsy driver so that they can take steps to mitigate the danger posed to them by the drowsy driver.

The second solution that refers to the claimed invention is now described according to some embodiments. An ego vehicle is driven by a drowsy driver and a remote vehicle is driven by a remote driver. Both the ego vehicle and the remote vehicle are DSRC-equipped, and both include an instance of the drowsy detection system installed in their onboard vehicle computer. The ego vehicle includes a driver monitoring system that detects that the driver is drowsy. In some embodiments, the drowsy detection system of the ego vehicle is installed in an Engine Control Unit (ECU) that operates the driver monitoring system. The drowsy detection system of the ego vehicle (<NUM>) identifies that the ECU is processing signals that indicate that the driver is drowsy and (<NUM>) determines whether the ego vehicle is in automated driving mode. The drowsy detection system of the ego vehicle inserts digital data into a BSM transmitted by the ego vehicle that describes (<NUM>) whether driver of the ego vehicle is drowsy; and (<NUM>) whether the ego vehicle is in automated driving mode [i.e., because the driver's drowsiness does not matter if automated driving is engaged]. The ego vehicle transmits the BSM. The remote vehicle receives the BSM. The drowsy detection system of the remote vehicle notifies the driver of the remote vehicle about the presence of the drowsy driver so that they can take steps to mitigate the danger posed to them by the drowsy driver. If the remote vehicle is an autonomous vehicle, then the remote vehicle automatically responds to the danger posed by the
drowsy driver (e.g., by not assuming that the ego vehicle will be driven based on existing models of driver behavior).

There are no existing solutions to the problem of detecting drowsy drivers that use V2X communications to detect a drowsy driver and then take steps to mitigate the harm to the other drivers that are nearby the drowsy driver. The drowsy detection system beneficially provides a safer driving environment and improves the operation of a connected vehicle by assisting the connected vehicle to avoid drowsy drivers and reduce the risk caused by drowsy drivers. The drowsy detection system works even if local onboard sensors do not detect that another vehicle is driven by a drowsy driver due to non-line of sight scenarios, bad weather conditions, bad road conditions, and other variables that impede the operation of the local onboard sensors.

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a method including: receiving, by a first connected vehicle, a V2X message including digital data describing a path history of a second connected vehicle; determining, by the first connected vehicle, that a driver of the second connected vehicle is drowsy based on the path history described by the digital data included in the V2X message; and executing, by the first connected vehicle, a remedial action that is operable to modify an operation of the first connected vehicle based on the driver of the second connected vehicle being drowsy so that a risk created by the driver is reduced. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The method where the V2X message is a dedicated short-range communication (DSRC) message. The method where the V2X message is not one of the following: a WiFi message; a <NUM> message; a <NUM> message; a <NUM> message; a long-term evolution (LTE) message; a millimeter wave communication message; a Bluetooth message; and a satellite communication. The method where the V2X message is a basic safety message. The method where the digital data describes a location of the second connected vehicle with an accuracy of substantially plus or minus half a width of a roadway which is being traveled by the second connected vehicle. The method where the remedial action includes providing a notification that describes the second connected vehicle as being operated by a drowsy driver. The method where the first connected vehicle is an autonomous vehicle and the remedial action includes the first connected vehicle automatically taking an evasive maneuver to avoid the second connected vehicle. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

One general aspect includes a system including: a processor of a first connected vehicle that is operable to receive a V2X message including digital data describing a path history of a second connected vehicle; and a non-transitory memory communicatively coupled to the processor, where the non-transitory memory stores computer code that is operable, when executed by the processor, to cause the processor to determine that a driver of the second connected vehicle is drowsy based on the path history described by the digital data included in the V2X message and execute a remedial action that is operable to modify an operation of the first connected vehicle based on the driver of the second connected vehicle being drowsy so that a risk created by the driver is reduced. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The system where the V2X message is a dedicated short-range communication (DSRC) message. The system where the V2X message is not one of the following: a WiFi message; a <NUM> message; a <NUM> message; a <NUM> message; a long-term evolution (LTE) message; a millimeter wave communication message; a Bluetooth message; and a satellite communication. The system where the V2X message is a basic safety message. The system where the digital data describes a location of the connected vehicle with an accuracy of substantially plus or minus half a width of a roadway which is being traveled by the connected vehicle. The system where the remedial action includes providing a notification that describes the second connected vehicle as being operated by a drowsy driver. The system where the first connected vehicle is an autonomous vehicle and the remedial action includes the first connected vehicle automatically taking an evasive maneuver to avoid the second connected vehicle. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

One general aspect includes a computer program product including instructions that, when executed by a processor of a first connected vehicle, causes the processor to perform operations including: receiving a V2X message including digital data describing a path history of a second connected vehicle; determining that a driver of the second connected vehicle is drowsy based on the path history described by the digital data included in the V2X message; and executing a remedial action that is operable to modify an operation of the first connected vehicle based on the driver of the second connected vehicle being drowsy so that a risk created by the driver is reduced. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The computer program product where the V2X message is a dedicated short-range communication (DSRC) message. The computer program product where the V2X message is not one of the following: a WiFi message; a <NUM> message; a <NUM> message; a <NUM> message; a long-term evolution (LTE) message; a millimeter wave communication message; a Bluetooth message; and a satellite communication. The computer program product where the remedial action is different depending on whether the first connected vehicle is an autonomous vehicle or a non-autonomous vehicle. The computer program product where the remedial action includes providing a notification that describes the second connected vehicle as being operated by a drowsy driver. The computer program product where the first connected vehicle is an autonomous vehicle and the remedial action includes the first connected vehicle automatically taking an evasive maneuver to avoid the second connected vehicle. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

The disclosure is illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings in which like reference numerals are used to refer to similar elements.

Embodiments of a drone assistance system that are operable to reduce or eliminate adjacent channel interference for V2X communications are now described. Examples of V2X communication include one or more of the following: DSRC (including BSMs, among other types of DSRC communication); LTE; millimeter wave communication; full-duplex wireless communication; <NUM>; <NUM>; <NUM>; LTE-Vehicle-to-Everything (LTE-V2X); LTE-Vehicle-to-Vehicle (LTE-V2V); LTE-Device-to-Device (LTE-D2D); Voice over LTE (VoLTE); <NUM>-Vehicle-to-Everything (<NUM>-V2X); etc..

In some embodiments, the connected vehicle that includes the drone assistance system is a DSRC-equipped vehicle. A DSRC-equipped vehicle is a vehicle which: (<NUM>) includes a DSRC radio; (<NUM>) includes a DSRC-compliant Global Positioning System (GPS) unit; and (<NUM>) is operable to lawfully send and receive DSRC messages in a jurisdiction where the DSRC-equipped vehicle is located. A DSRC radio is hardware that includes a DSRC receiver and a DSRC transmitter. The DSRC radio is operable to wirelessly send and receive DSRC messages. A DSRC-compliant GPS unit is operable to provide positional information for a vehicle (or some other DSRC-equipped device that includes the DSRC-compliant GPS unit) that has lane-level accuracy. The DSRC-compliant GPS unit is described in more detail below.

A "DSRC-equipped" device is a processor-based device that includes a DSRC radio, a DSRC-compliant GPS unit and is operable to lawfully send and receive DSRC messages in a jurisdiction where the DSRC-equipped device is located. Various endpoints may be DSRC-equipped devices, including, for example, a roadside unit (RSU), a smartphone, a tablet computer and any other processor-based computing device that includes a DSRC radio and is operable to lawfully send and receive DSRC messages as described above.

In some embodiments, an RSU that is a DSRC-equipped device does not include a DSRC-compliant GPS unit, but does include a non-transitory memory that stores digital data describing positional information for the RSU having lane-level accuracy, and the DSRC radio or some other system of the RSU inserts a copy of this digital data in the BSM data that is transmitted by the DSRC radio of the RSU. In this way, the RSU does not include a DSRC-compliant GPS unit but is still operable to distribute BSM data that satisfies the requirements for the DSRC standard. The BSM data is described in more detail below with reference to <FIG> and <FIG> according to some embodiments.

A DSRC message is a wireless message that is specially configured to be sent and received by highly mobile devices such as vehicles, and is compliant with one or more of the following DSRC standards, including any derivative or fork thereof: EN <NUM>:<NUM> Dedicated Short-Range Communication - Physical layer using microwave at <NUM> (review); EN <NUM>:<NUM> Dedicated Short-Range Communication (DSRC) - DSRC Data link layer: Medium Access and Logical Link Control (review); EN <NUM>:<NUM> Dedicated Short-Range Communication - Application layer (review); and EN <NUM>:<NUM> Dedicated Short-Range Communication (DSRC) - DSRC profiles for RTTT applications (review); EN ISO <NUM>:<NUM> Electronic Fee Collection - Application interface.

In the United States and Europe, DSRC messages are transmitted at <NUM>. In the United States, DSRC messages are allocated <NUM> of spectrum in the <NUM> band. In Europe, DSRC messages are allocated <NUM> of spectrum in the <NUM> band. In Japan, DSRC messages are transmitted in the <NUM> band with <NUM> of spectrum. A wireless message, therefore, is not a DSRC message unless it operates in the <NUM> band in the United States and Europe or the <NUM> band in Japan. A wireless message is also not a DSRC message unless it is transmitted by a DSRC transmitter of a DSRC radio.

Accordingly, a DSRC message is not any of the following: a WiFi message; a <NUM> message; a <NUM> message; an LTE message; a millimeter wave communication message; a Bluetooth message; a satellite communication; and a short-range radio message transmitted or broadcast by a key fob at <NUM> or <NUM>. For example, in the United States, key fobs for remote keyless systems include a short-range radio transmitter which operates at <NUM>, and transmissions or broadcasts from this short-range radio transmitter are not DSRC messages since, for example, such transmissions or broadcasts do not comply with any DSRC standard, are not transmitted by a DSRC transmitter of a DSRC radio and are not transmitted at <NUM>. In another example, in Europe and Asia, key fobs for remote keyless systems include a short-range radio transmitter which operates at <NUM>, and transmissions or broadcasts from this short-range radio transmitter are not DSRC messages for similar reasons as those described above for remote keyless systems in the United States.

The wireless messages of key fobs made as a component of a remote keyless entry system are not DSRC messages for additional reasons. For example, the payload for a DSRC message is also required to include digital data describing a rich amount of vehicular data of various types of data. In general, a DSRC message always includes, at a minimum, a unique identifier of the vehicle which transmits the DSRC message as well as the GPS data for that vehicle. This amount of data requires a larger bandwidth than what is possible for other types of non-DSRC wireless messages. For example, <FIG> and <FIG> depict examples of a permissible payload for a particular type of DSRC message referred to as a BSM message. The wireless messages of key fobs as a component of a remote keyless entry system are not DSRC messages because they do not include a payload which is permissible under the DSRC standard. For example, a key fob merely transmits a wireless message including a digital key which is known to a vehicle which is paired with the key fob; there is not sufficient bandwidth for other data to be included in the payload because the bandwidth allocated for these transmissions is very small. By comparison, DSRC messages are allocated large amounts of bandwidth and are required to include a far richer amount of data, including, for example, a unique identifier and the GPS data for the vehicle which transmitted the DSRC message.

In some embodiments, a DSRC-equipped vehicle does not include a conventional global positioning system unit ("GPS unit"), and instead includes a DSRC-compliant GPS unit. A conventional GPS unit provides positional information that describes a position of the conventional GPS unit with an accuracy of plus or minus <NUM> meters of the actual position of the conventional GPS unit. By comparison, a DSRC-compliant GPS unit provides GPS data that describes a position of the DSRC-compliant GPS unit with an accuracy of plus or minus <NUM> meters of the actual position of the DSRC-compliant GPS unit. This degree of accuracy is referred to as "lane-level accuracy" since, for example, a lane of a roadway is generally about <NUM> meters wide, and an accuracy of plus or minus <NUM> meters is sufficient to identify which lane a vehicle is traveling in on a roadway.

In some embodiments, a DSRC-compliant GPS unit is operable to identify, monitor and track its two-dimensional position within <NUM> meters of its actual position <NUM>% of the time under an open sky.

Referring to <FIG>, depicted is an operating environment <NUM> for a drowsy detection system <NUM> according to some embodiments. As depicted, the operating environment <NUM> includes the following elements: an ego vehicle <NUM>; and a remote vehicle <NUM>. These elements are communicatively coupled to one another by a network <NUM>.

Although one ego vehicle <NUM>, one remote vehicle <NUM>, and one network <NUM> are depicted in <FIG>, in practice the operating environment <NUM> may include one or more ego vehicles <NUM>, one or more remote vehicles <NUM>, and one or more networks <NUM>.

The network <NUM> may be a conventional type, wired or wireless, and may have numerous different configurations including a star configuration, token ring configuration, or other configurations. Furthermore, the network <NUM> may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), or other interconnected data paths across which multiple devices and/or entities may communicate. In some embodiments, the network <NUM> may include a peer-to-peer network. The network <NUM> may also be coupled to or may include portions of a telecommunications network for sending data in a variety of different communication protocols. In some embodiments, the network <NUM> includes Bluetooth® communication networks or a cellular communications network for sending and receiving data including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, wireless application protocol (WAP), e-mail, DSRC, full-duplex wireless communication, mmWave, WiFi (infrastructure mode), WiFi (ad-hoc mode), visible light communication, TV white space communication and satellite communication. The network <NUM> may also include a mobile data network that may include <NUM>, <NUM>, LTE, <NUM>, LTE-V2V, LTE-V2X, LTE-D2D, VoLTE, <NUM>-V2X or any other mobile data network or combination of mobile data networks. Further, the network <NUM> may include one or more IEEE <NUM> wireless networks. The network <NUM> may include any type of V2X network described herein.

The following are endpoints of the network <NUM>: the ego vehicle <NUM>; and the remote vehicle <NUM>.

The ego vehicle <NUM> is any type of connected vehicle. For example, the ego vehicle <NUM> is one of the following types of vehicles: a car; a truck; a sports utility vehicle; a bus; a semi-truck; a robotic car; a drone or any other roadway-based conveyance. In some embodiments, the ego vehicle <NUM> is a DSRC-equipped vehicle.

In some embodiments, the ego vehicle <NUM> is an autonomous vehicle or a semi-autonomous vehicle. For example, the ego vehicle <NUM> includes a set of Advanced Driver Assistance Systems <NUM> (a set of "ADAS systems <NUM>") which provide autonomous features to the ego vehicle <NUM> which are sufficient to render the ego vehicle <NUM> an autonomous vehicle.

The National Highway Traffic Safety Administration ("NHTSA") has defined different "levels" of autonomous vehicles, e.g., Level <NUM>, Level <NUM>, Level <NUM>, Level <NUM>, Level <NUM> and Level <NUM>. If an autonomous vehicle has a higher-level number than another autonomous vehicle (e.g., Level <NUM> is a higher-level number than Levels <NUM> or <NUM>), then the autonomous vehicle with a higher-level number offers a greater combination and quantity of autonomous features relative to the vehicle with the lower level number. The different levels of autonomous vehicles are described briefly below.

Level <NUM>: The set of ADAS systems <NUM> installed in a vehicle (e.g., the ego vehicle <NUM>) have no vehicle control. The set of ADAS systems <NUM> may issue warnings to the driver of the vehicle. A vehicle which is Level <NUM> is not an autonomous or semi-autonomous vehicle.

Level <NUM>: The driver must be ready to take driving control of the autonomous vehicle at any time. The set of ADAS systems <NUM> installed in the autonomous vehicle may provide autonomous features such as one or more of the following: Adaptive Cruise Control ("ACC"); and Parking Assistance with automated steering and Lane Keeping Assistance ("LKA") Type II, in any combination.

Level <NUM>: The driver is obliged to detect objects and events in the roadway environment and respond if the set of ADAS systems <NUM> installed in the autonomous vehicle fail to respond properly (based on the driver's subjective judgement). The set of ADAS systems <NUM> installed in the autonomous vehicle executes accelerating, braking, and steering. The set of ADAS systems <NUM> installed in the autonomous vehicle can deactivate immediately upon takeover by the driver.

Level <NUM>: Within known, limited environments (such as freeways), the driver can safely turn their attention away from driving tasks, but must still be prepared to take control of the autonomous vehicle when needed.

Level <NUM>: The set of ADAS systems <NUM> installed in the autonomous vehicle can control the autonomous vehicle in all but a few environments such as severe weather. The driver must enable the automated system (which is comprised of the set of ADAS systems <NUM> installed in the ego vehicle <NUM>) only when it is safe to do so. When the automated system is enabled, driver attention is not required for the autonomous vehicle to operate safely and consistent with accepted norms.

Level <NUM>: Other than setting the destination and starting the system, no human intervention is required. The automated system can drive to any location where it is legal to drive and make its own decision (which may vary based on the jurisdiction where the vehicle is located).

A highly autonomous vehicle (HAV) is an autonomous vehicle that is Level <NUM> or higher.

Accordingly, in some embodiments the ego vehicle <NUM> is one of the following: a Level <NUM> autonomous vehicle; a Level <NUM> autonomous vehicle; a Level <NUM> autonomous vehicle; a Level <NUM> autonomous vehicle; a Level <NUM> autonomous vehicle; and an HAV.

The set of ADAS systems <NUM> may include one or more of the following types of ADAS systems: an ACC system; an adaptive high beam system; an adaptive light control system; an automatic parking system; an automotive night vision system; a blind spot monitor; a collision avoidance system; a crosswind stabilization system; a driver drowsiness detection system; a driver monitoring system <NUM>; an emergency driver assistance system; a forward collision warning system; an intersection assistance system; an intelligent speed adaption system; a lane departure warning system (also referred to as a lane keep assistant); a pedestrian protection system; a traffic sign recognition system; a turning assistant; a wrong-way driving warning system; autopilot; sign recognition; and sign assist. Each of these example ADAS systems provide their own features and functionality that may be referred to herein as an "ADAS feature" or "ADAS functionality," respectively. The features and functionality provided by these example ADAS systems are also referred to herein as an "autonomous feature" or an "autonomous functionality," respectively.

The driver monitoring system <NUM> is an ADAS system that identifies when a vehicle, such as the ego vehicle <NUM>, is being driven by a drowsy driver. The driver monitoring system <NUM> is a conventional driver monitoring system.

In some embodiments, the ego vehicle <NUM> includes the following elements: a processor <NUM>; a memory <NUM>; a sensor set <NUM>; a communication unit <NUM>; the set of ADAS systems <NUM> including the driver monitoring system <NUM>; and a drowsy detection system <NUM>.

In some embodiments, the processor <NUM> and the memory <NUM> may be elements of an onboard vehicle computer system (such as computer system <NUM> described below with reference to <FIG>). The onboard vehicle computer system may be operable to cause or control the operation of the drowsy detection system <NUM> of the ego vehicle <NUM>. The onboard vehicle computer system may be operable to access and execute the data stored on the memory <NUM> to provide the functionality described herein for the drowsy detection system <NUM> of the ego vehicle <NUM> or its elements (see, e.g., <FIG>). The onboard vehicle computer system may be operable to execute the drowsy detection system <NUM> which causes the onboard vehicle computer system to execute one or more steps of one or more of the method <NUM> described below with reference to <FIG>. The onboard vehicle computer system may be operable to execute the drowsy detection system <NUM> which causes the onboard vehicle computer system to execute one or more steps of one or more of the method <NUM> described below with reference to <FIG> and <FIG>.

In some embodiments, the processor <NUM> and the memory <NUM> may be elements of an onboard unit. The onboard unit includes an ECU or an onboard vehicle computer system that may be operable to cause or control the operation of the drowsy detection system <NUM>. The onboard unit may be operable to access and execute the data stored on the memory <NUM> to provide the functionality described herein for the drowsy detection system <NUM> or its elements. The onboard unit may be operable to execute the drowsy detection system <NUM> which causes the onboard unit to execute one or more steps of one or more of the method <NUM> described below with reference to <FIG>. The onboard unit may be operable to execute the drowsy detection system <NUM> which causes the onboard unit to execute one or more steps of one or more of the method <NUM> described below with reference to <FIG> and <FIG>. In some embodiments, the computer system <NUM> depicted in <FIG> is an example of an onboard unit.

In some embodiments, the ego vehicle <NUM> may include a sensor set <NUM>. The sensor set <NUM> includes one or more sensors that are operable to measure the physical environment outside of the ego vehicle <NUM>. For example, the sensor set <NUM> includes one or more sensors that record one or more physical characteristics of the physical environment that is proximate to the ego vehicle <NUM>. The memory <NUM> may store sensor data that describes the one or more physical characteristics recorded by the sensor set <NUM>.

In some embodiments, the sensor set <NUM> of the ego vehicle <NUM> includes one or more of the following vehicle sensors: a camera; a LIDAR sensor; a radar sensor; a laser altimeter; an infrared detector; a motion detector; a thermostat; a sound detector, a carbon monoxide sensor; a carbon dioxide sensor; an oxygen sensor; a mass air flow sensor; an engine coolant temperature sensor; a throttle position sensor; a crank shaft position sensor; an automobile engine sensor; a valve timer; an air-fuel ratio meter; a blind spot meter; a curb feeler; a defect detector; a Hall effect sensor, a manifold absolute pressure sensor; a parking sensor; a radar gun; a speedometer; a speed sensor; a tire-pressure monitoring sensor; a torque sensor; a transmission fluid temperature sensor; a turbine speed sensor (TSS); a variable reluctance sensor; a vehicle speed sensor (VSS); a water sensor; a wheel speed sensor; and any other type of automotive sensor.

In some embodiments, the sensor set <NUM> includes any sensors which are necessary to record the information included in the BSM data <NUM> or provide any of the other functionality described herein.

The processor <NUM> includes an arithmetic logic unit, a microprocessor, a general-purpose controller, or some other processor array to perform computations and provide electronic display signals to a display device. The processor <NUM> processes data signals and may include various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. The ego vehicle <NUM> may include one or more processors <NUM>. Other processors, operating systems, sensors, displays, and physical configurations may be possible.

The memory <NUM> is a non-transitory memory that stores instructions or data that may be accessed and executed by the processor <NUM>. The instructions or data may include code for performing the techniques described herein. The memory <NUM> may be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory, or some other memory device. In some embodiments, the memory <NUM> also includes a non-volatile memory or similar permanent storage device and media including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device for storing information on a more permanent basis. A portion of the memory <NUM> may be reserved for use as a buffer or virtual random-access memory (virtual RAM). The ego vehicle <NUM> may include one or more memories <NUM>.

In some embodiments, the memory <NUM> stores, as digital data, any data described herein. In some embodiments, the memory <NUM> stores any data that is necessary for the drowsy detection system <NUM> to provide its functionality.

As depicted, the memory <NUM> stores: BSM data <NUM>; drowsy driving signals data <NUM>; automated driving signals data <NUM>; and determination data <NUM>.

The BSM data <NUM> is digital data that is included as the payload for a BSM that is received by the DSRC radio <NUM> or the communication unit <NUM>. The BSM data <NUM> is described in more detail below with reference to <FIG> and <FIG>.

The drowsy driving signals data <NUM> is digital data that describes whether the driver monitoring system <NUM> has determined that a vehicle (e.g., the ego vehicle <NUM>) is being driven by a drowsy driver. See, e.g., step <NUM> of the method <NUM> depicted in <FIG> and <FIG>. For example, in some embodiments the drowsy detection system <NUM> includes hooks into an ECU of the ego vehicle <NUM> that operates the drowsy monitoring system <NUM> so that the drowsy detection system <NUM> can determine whether the drowsy monitoring system <NUM> has determined that the ego vehicle <NUM> is being operated by a drowsy driver. The drowsy detection system <NUM> uses these hooks to intercept "drowsy driving signals" generated by the driver monitoring system <NUM> which describe whether the drowsy monitoring system <NUM> has determined that the ego vehicle <NUM> is being operated by a drowsy driver. The drowsy driving signals data <NUM> describes these intercepted signals.

The automated driving signals data <NUM> is digital data that describes whether an automated driving system (e.g., the set of ADAS systems <NUM>) is engaged such that the ego vehicle <NUM> is in an automated driving mode. See, e.g., step <NUM> of the method <NUM> depicted in <FIG> and <FIG>. For example, the set of ADAS systems <NUM> is an automated driving system. The drowsy detection system <NUM> includes hooks into one or more ECUs of the ego vehicle <NUM> that operate the automated driving system so that the drowsy detection system <NUM> can determine whether the automated driving system is in the automated driving mode. The automated driving mode is a mode of operation whereby the ego vehicle <NUM> is operated as a Level <NUM> or higher automated vehicle by the set of ADAS systems <NUM>. The drowsy detection system <NUM> uses these hooks to intercept "automated driving signals" generated by the automated driving system which describe whether the automated driving system is in the automated driving mode. The automated driving signals data <NUM> describes these intercepted signals.

The determination data <NUM> is digital data that describes and identifies a particular vehicle (e.g., the ego vehicle <NUM> or the remote vehicle <NUM>) which the drowsy detection system <NUM> has determined to be operated by a drowsy driver.

The communication unit <NUM> transmits and receives data to and from a network <NUM> or to another communication channel. In some embodiments, the communication unit <NUM> may include a DSRC transceiver, a DSRC receiver and other hardware or software necessary to make the ego vehicle <NUM> a DSRC-equipped device.

In some embodiments, the communication unit <NUM> includes a port for direct physical connection to the network <NUM> or to another communication channel. For example, the communication unit <NUM> includes a USB, SD, CAT-<NUM>, or similar port for wired communication with the network <NUM>. In some embodiments, the communication unit <NUM> includes a wireless transceiver for exchanging data with the network <NUM> or other communication channels using one or more wireless communication methods, including: IEEE <NUM>; IEEE <NUM>, BLUETOOTH®; EN ISO <NUM>:<NUM> Electronic Fee Collection - Application interface EN <NUM>:<NUM> Dedicated Short-Range Communication - Physical layer using microwave at <NUM> (review); EN <NUM>:<NUM> Dedicated Short-Range Communication (DSRC) - DSRC Data link layer: Medium Access and Logical Link Control (review); EN <NUM>:<NUM> Dedicated Short-Range Communication - Application layer (review); EN <NUM>:<NUM> Dedicated Short-Range Communication (DSRC) - DSRC profiles for RTTT applications (review); the communication method described in <CIT> and entitled "Full-Duplex Coordination System"; or another suitable wireless communication method.

In some embodiments, the communication unit <NUM> includes a full-duplex coordination system as described in <CIT> and entitled "Full-Duplex Coordination System," the entirety of which is incorporated herein by reference.

In some embodiments, the communication unit <NUM> includes a cellular communications transceiver for sending and receiving data over a cellular communications network including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, e-mail, or another suitable type of electronic communication. In some embodiments, the communication unit <NUM> includes a wired port and a wireless transceiver. The communication unit <NUM> also provides other conventional connections to the network <NUM> for distribution of files or media objects using standard network protocols including TCP/IP, HTTP, HTTPS, and SMTP, millimeter wave, DSRC, or any other type of V2X communication.

In some embodiments, the communication unit <NUM> includes a DSRC radio <NUM>. In some embodiments, the DSRC radio <NUM> is an electronic device that includes a V2X transmitter and a V2X receiver that is operable to send and receive wireless messages via any V2X protocol. For example, the DSRC radio <NUM> is operable to send and receive wireless messages via DSRC. The V2X transmitter is operable to transmit and broadcast DSRC messages over the <NUM> band. The V2X receiver is operable to receive DSRC messages over the <NUM> band. The DSRC radio <NUM> includes seven channels (e.g., DSRC channel numbers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>) with at least one of these channels reserved for sending and receiving BSMs (e.g., DSRC channel number <NUM> is reserved for BSMs). In some embodiments, at least one of these channels is reserved for sending and receiving Pedestrian Safety Messages (PSMs) as described in <CIT> and entitled "PSM Message-based Device Discovery for a Vehicular Mesh Network," the entirety of which is hereby incorporated by reference. In some embodiments, DSRC channel number <NUM> is reserved for sending and receiving PSMs. In some embodiments, DSRC channel number <NUM> is reserved for sending and receiving PSMs.

In some embodiments, the DSRC radio <NUM> includes a non-transitory memory which stores digital data that controls the frequency for broadcasting BSMs. In some embodiments, the non-transitory memory stores a buffered version of the GPS data for the ego vehicle <NUM> so that the GPS data for the ego vehicle <NUM> is broadcast as an element of the BSMs (e.g., as an element of the BSM data <NUM>) which are regularly broadcast by the DSRC radio <NUM>.

In some embodiments, the DSRC radio <NUM> includes any hardware or software which is necessary to make the ego vehicle <NUM> compliant with the DSRC standards. In some embodiments, the DSRC-compliant GPS unit <NUM> depicted in <FIG> is an element of the DSRC radio <NUM>.

In some embodiments, the DSRC radio <NUM> includes a single channel that is dedicated to sending and/or receiving a particular type of wireless message. For example, the DSRC radio <NUM> includes a single channel that is dedicated to sending and receiving BSMs. In another example, the DSRC radio <NUM> includes a single channel that is dedicated to receiving PSMs.

In some embodiments, the drowsy detection system <NUM> includes software that is operable, when executed by the processor <NUM>, to cause the processor <NUM> to execute one or more steps of the method <NUM> described below with reference to <FIG>. In some embodiments, the drowsy detection system <NUM> includes software that is operable, when executed by the processor <NUM>, to cause the processor <NUM> to execute one or more steps of the method <NUM> described below with reference to <FIG> and <FIG>. The functionality of the drowsy detection system <NUM> is described in more detail below according to some embodiments.

In some embodiments, the drowsy detection system <NUM> is implemented using hardware including a field-programmable gate array ("FPGA") or an application-specific integrated circuit ("ASIC"). In some other embodiments, the drowsy detection system <NUM> implemented using a combination of hardware and software.

The remote vehicle <NUM> is a connected vehicle similar to the ego vehicle <NUM>. The remote vehicle <NUM> includes elements that are similar to those included in the ego vehicle <NUM>. As depicted, the remote vehicle <NUM> includes a drowsy detection system <NUM> and a communication unit <NUM> having a DSRC radio <NUM>. The communication unit <NUM> and the DSRC radio <NUM> provide similar functionality as the communication unit <NUM> and the DSRC radio <NUM> described above for the ego vehicle <NUM>, and so, those descriptions will not be repeated here. The drowsy detection system <NUM> of the remote vehicle <NUM> provides similar functionality as the drowsy detection system <NUM> of the ego vehicle <NUM>, and so, that description will not be repeated here. The remote vehicle <NUM> may include any of the elements that are included in the ego vehicle <NUM>.

The drowsy detection system <NUM> is described herein with reference to DSRC, but the functionality of the drowsy detection system <NUM> is not limited to DSRC. Instead, the drowsy detection system <NUM> works with any V2X communication protocol including, among others, LTE-V2X and <NUM>-V2X.

Driving a vehicle while drowsy is dangerous. The NHTSA estimated that, between <NUM> and <NUM>, drowsy driving has the following affects: <NUM>,<NUM> police-reported crashes per year; <NUM>,<NUM> injuries per year; and more than <NUM> deaths per year. The purpose of our invention is to decrease the damage done by drowsy driving using V2X communications.

The drowsy detection system <NUM> is operable to provide two solutions to the problem of drowsy driving wherein the claimed invention refers to the second solution and the first solution shows an unclaimed comparative example.

Vehicles are increasingly equipped with DSRC capabilities. DSRC-equipped vehicles transmit BSMs at a regular interval (e.g., once every <NUM> seconds). BSMs have a mandatory payload (referred to as "BSM data <NUM>") that includes, among other things, information about the path history of the vehicle that transmits the BSM. Examples of the information described by the BSM data <NUM> are depicted in <FIG> and <FIG>. This information also includes the GPS location for the vehicle that transmitted the BSM, as well as its trajectory information.

This example solution according to the unclaimed comparative example assumes that the remote vehicle <NUM> is driven by a drowsy driver. The remote vehicle <NUM> is DSRC-equipped, and it regularly transmits BSMs that include path history data of the remote vehicle <NUM>. The ego vehicle <NUM> receives the BSMs from the remote vehicle <NUM>. The drowsy detection system <NUM> of the ego vehicle <NUM> analyzes the path history data included in these BSMs. Based on this analysis, the drowsy detection system <NUM> identifies the presence of the drowsy driver operating the remote vehicle <NUM>. The ego vehicle <NUM> is driven by an ego driver. The drowsy detection system <NUM> notifies the ego driver of the presence of the drowsy driver so that they can take steps to mitigate the danger posed to them by the drowsy driver.

If the ego vehicle <NUM> is an autonomous vehicle, then the drowsy detection system <NUM> notifies the autonomous driving system of the ego vehicle <NUM> about the identity of the remote vehicle <NUM> having the drowsy driver so that the autonomous driving system responds to the presence of the drowsy driver, e.g., by driving further away from them and not applying standard driving models to predict the behavior of the drowsy driver. Instead, models that predict the behavior of drowsy drivers may be applied. The method <NUM> depicted in <FIG> is an example of the first solution according to the unclaimed comparative example.

This solution according to the claimed invention assumes that the ego vehicle <NUM> is driven by a drowsy driver and the remote vehicle <NUM> is driven by a "remote driver. " Both the ego vehicle <NUM> and the remote vehicle <NUM> are DSRC-equipped, and both include their own instance the drowsy detection system <NUM>. The drowsy detection system <NUM> provides different functionality for these endpoints, but it could be the same software operating in different modes based on whether it is the transmitter (Tx) or receiver (Rx) of a BSM.

In addition to the drowsy detection system <NUM>, the ego vehicle <NUM> includes a driver monitoring system <NUM> that detects that the ego driver is drowsy.

In some embodiments, the drowsy detection system <NUM> of the ego vehicle <NUM> is installed in an ECU that operates the driver monitoring system <NUM> for the ego vehicle <NUM>. The drowsy detection system <NUM> of the ego vehicle <NUM> includes code and routines that are operable, when executed by the ECU, to cause the ECU to execute the following steps of an example process:.

At step <NUM>, identify when the ECU is processing signals that indicate that the ego driver is drowsy. In some embodiments, the drowsy detection system <NUM> of the ego vehicle <NUM> includes hooks in the code of the driver monitoring system <NUM> so that it is able to determine the presence of a drowsy driver without monitoring for signals within the ECU or some other activity outside of the driver monitoring system <NUM>.

At step <NUM>, determine whether the ego vehicle <NUM> is in automated driving mode. For example, the drowsy detection system <NUM> of the ego vehicle <NUM> determines whether the ego vehicle <NUM> includes an automated driving system and, if so, whether the automated driving system is currently engaged.

According to the invention, the drowsy detection system <NUM> of the ego vehicle inserts digital data into the BSM data <NUM> of a BSM transmitted by the ego vehicle <NUM> that describes (<NUM>) whether ego driver of the ego vehicle <NUM> is drowsy; and (<NUM>) whether the ego vehicle <NUM> is in automated driving mode [i.e., because the driver's drowsiness does not matter if automated driving is engaged]. The ego vehicle <NUM> transmits the BSM.

The remote vehicle <NUM> receives the BSM. The drowsy detection system <NUM> of the remote vehicle <NUM> analyzes the BSM data <NUM> to determine whether it indicates that the ego vehicle <NUM> is being operated by a drowsy driver. If so, the drowsy detection system <NUM> of the remote vehicle <NUM> notifies the remote driver of the remote vehicle <NUM> about the presence of the drowsy driver (e.g., the driver of the ego vehicle <NUM>) so that they can take steps to mitigate the danger posed to them and the remote vehicle <NUM> by the drowsy driver. If the remote vehicle <NUM> is an autonomous vehicle, then the remote vehicle <NUM> automatically responds to the danger posed by the drowsy driver (e.g., by not assuming that the ego vehicle <NUM> will be driven based on existing models of driver behavior). The method <NUM> depicted in <FIG> and <FIG> is an example embodiment of the second solution according to the claimed invention.

For first solution according to the unclaimed comparative example, the remote vehicle <NUM> does not need to include a drowsy detection system but the ego vehicle <NUM> does need to include a drowsy detection system. For the second solution according to the claimed invention, both the remote vehicle <NUM> and the ego vehicle <NUM> include a drowsy detection system <NUM>.

Neither the first solution according to the unclaimed comparative example nor the second solution according to the claimed invention requires an automated driving system in either the ego vehicle <NUM> or the remote vehicle <NUM>, but the drowsy detection system <NUM> is compatible with automated driving systems and has unique functionality if an automated driving system is present in the vehicle and also engaged such that the vehicle is operated in automated driving mode.

Referring now to <FIG>, depicted is a block diagram illustrating an example computer system <NUM> including the drowsy detection system <NUM> according to some embodiments. In some embodiments, the computer system <NUM> may include a special-purpose computer system that is programmed to perform one or more steps of one or more of the method <NUM> described below with reference to <FIG>. In some embodiments, the computer system <NUM> may include a special-purpose computer system that is programmed to perform one or more steps of one or more of the method <NUM> described below with reference to <FIG> and <FIG>. In some embodiments, the computer system <NUM> is an onboard vehicle computer of the ego vehicle <NUM>. In some embodiments, the computer system <NUM> is an onboard unit of the ego vehicle <NUM>. In some embodiments, the computer system <NUM> is an ECU, head unit or some other processor-based computing device of the ego vehicle <NUM>.

The computer system <NUM> includes one or more of the following elements according to some examples: the drowsy detection system <NUM>; the processor <NUM>; the communication unit <NUM>; the memory <NUM>; the set of ADAS systems <NUM>; the sensor set <NUM>; the driver monitoring system <NUM>; and a DSRC-compliant GPS unit <NUM>. The components of the computer system <NUM> are communicatively coupled by a bus <NUM>.

In the illustrated embodiment, the processor <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>. The communication unit <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>. The memory <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>. The set of ADAS systems <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>. The sensor set <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>. The driver monitoring system <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>. The DSRC-compliant GPS unit <NUM> is communicatively coupled to the bus <NUM> via a signal line <NUM>.

The following elements were described above with reference to <FIG>, and so, those descriptions will not be repeated here: the processor <NUM>; the communication unit <NUM>; the memory <NUM>; the set of ADAS systems <NUM>; the sensor set <NUM>; and the driver monitoring system <NUM>.

The memory <NUM> may store any of the data described above with reference to <FIG> or below with reference to <FIG>. The memory <NUM> may store any data needed for the computer system <NUM> to provide its functionality.

In some embodiments, the DSRC-compliant GPS unit <NUM> includes any hardware and software necessary to make the ego vehicle <NUM>, computer system <NUM>, or the DSRC-compliant GPS unit <NUM> compliant with one or more of the following DSRC standards, including any derivative or fork thereof: EN <NUM>:<NUM> Dedicated Short-Range Communication - Physical layer using microwave at <NUM> (review); EN <NUM>:<NUM> Dedicated Short-Range Communication (DSRC) - DSRC Data link layer: Medium Access and Logical Link Control (review); EN <NUM>:<NUM> Dedicated Short-Range Communication - Application layer (review); and EN <NUM>:<NUM> Dedicated Short-Range Communication (DSRC) - DSRC profiles for RTTT applications (review); EN ISO <NUM>:<NUM> Electronic Fee Collection - Application interface.

In some embodiments, the DSRC-compliant GPS unit <NUM> is operable to provide GPS data describing the location of the ego vehicle <NUM> with lane-level accuracy. For example, the ego vehicle <NUM> is traveling in a lane of a roadway. Lane-level accuracy means that the location of the ego vehicle <NUM> is described by the GPS data so accurately that the lane of travel of the ego vehicle <NUM> within the roadway may be accurately determined based on the GPS data for this ego vehicle <NUM> as provided by the DSRC-compliant GPS unit <NUM>. In some embodiments, the GPS data is an element of the BSM data <NUM> (see, e.g., <FIG> and <FIG>).

In some embodiments, the DSRC-compliant GPS unit <NUM> includes hardware that wirelessly communicates with a GPS satellite to retrieve GPS data that describes the geographic location of the ego vehicle <NUM> with a precision that is compliant with the DSRC standard. The DSRC standard requires that GPS data be precise enough to infer if two vehicles (one of which is, for example, the ego vehicle <NUM>) are located in adjacent lanes of travel. In some embodiments, the DSRC-compliant GPS unit <NUM> is operable to identify, monitor and track its two-dimensional position within <NUM> meters of its actual position <NUM>% of the time under an open sky. Since driving lanes are typically no less than <NUM> meters wide, whenever the two-dimensional error of the GPS data is less than <NUM> meters the drowsy detection system <NUM> described herein may analyze the GPS data provided by the DSRC-compliant GPS unit <NUM> and determine what lane the ego vehicle <NUM> is traveling in based on the relative positions of two or more different vehicles (one of which is, for example, the ego vehicle <NUM>) traveling on the roadway at the same time.

By comparison to the DSRC-compliant GPS unit <NUM>, a conventional GPS unit which is not compliant with the DSRC standard is unable to determine the location of an ego vehicle <NUM> with lane-level accuracy. For example, a typical roadway lane is approximately <NUM> meters wide. However, a conventional GPS unit only has an accuracy of plus or minus <NUM> meters relative to the actual location of the ego vehicle <NUM>. As a result, such conventional GPS units are not sufficiently accurate to identify a lane of travel for an ego vehicle <NUM> based on GPS data alone; instead, systems having only conventional GPS units must utilize sensors such as cameras to identify the lane of travel of the ego vehicle <NUM>. Identifying a lane of travel of a vehicle is beneficial, for example, because in some embodiments it may enable the automated driving system to do a better job of avoiding the vehicle which is operated by a drowsy driver.

In the illustrated embodiment shown in <FIG>, the drowsy detection system <NUM> includes: a communication module <NUM>; and a determination module <NUM>.

The communication module <NUM> can be software including routines for handling communications between the drowsy detection system <NUM> and other components of the operating environment <NUM> of <FIG>.

In some embodiments, the communication module <NUM> can be a set of instructions executable by the processor <NUM> to provide the functionality described below for handling communications between the drowsy detection system <NUM> and other components of the computer system <NUM>. In some embodiments, the communication module <NUM> can be stored in the memory <NUM> of the computer system <NUM> and can be accessible and executable by the processor <NUM>. The communication module <NUM> may be adapted for cooperation and communication with the processor <NUM> and other components of the computer system <NUM> via signal line <NUM>.

The communication module <NUM> sends and receives data, via the communication unit <NUM>, to and from one or more elements of the operating environment <NUM>. For example, the communication module <NUM> receives or transmits, via the communication unit <NUM>, some or all of the digital data stored on the memory <NUM>. The communication module <NUM> may send or receive any of the digital data or messages described above with reference to <FIG> or below with reference to <FIG>, via the communication unit <NUM>.

In some embodiments, the communication module <NUM> receives data from components of the drowsy detection system <NUM> and stores the data in the memory <NUM> (or a buffer or cache of the memory <NUM>, or a standalone buffer or cache which is not depicted in <FIG>). For example, the communication module <NUM> broadcasts a BSM message including the BSM data <NUM> from the communication unit <NUM> at a regular interval such as once every <NUM> seconds.

In some embodiments, the communication module <NUM> may handle communications between components of the drowsy detection system <NUM>. For example, the communication module <NUM> transmits the GPS data from the memory <NUM> to the determination module <NUM> so that the determination module <NUM> is able to form BSM data <NUM> including the GPS data as an element of the BSM data <NUM>.

In some embodiments, the determination module <NUM> can be a set of instructions executable by the processor <NUM> which are operable, when executed by the processor <NUM>, to cause the processor <NUM> to execute one or more steps of the method <NUM> described below with reference to <FIG>. In some embodiments, the determination module <NUM> can be a set of instructions executable by the processor <NUM> which are operable, when executed by the processor <NUM>, to cause the processor <NUM> to execute one or more steps of the method <NUM> described below with reference to <FIG> and <FIG>. In some embodiments, the determination module <NUM> can be stored in the memory <NUM> of the computer system <NUM> and can be accessible and executable by the processor <NUM>. The determination module <NUM> may be adapted for cooperation and communication with the processor <NUM> and other components of the computer system <NUM> via signal line <NUM>.

<FIG> depicts a method <NUM> for modifying the operation of a connected vehicle to reduce the risk caused by a drowsy driver according to an unclaimed comparative example. The steps of the method <NUM> are executable in any order, and not necessarily the order depicted in <FIG>.

At step <NUM>, a remote vehicle transmits BSM including path history data.

At step <NUM>, an ego vehicle receives the BSM.

At step <NUM>, the drowsy detection system of the ego vehicle parses out the BSM data from the BSM.

At step <NUM>, the drowsy detection system analyzes the path history data that is included in the BSM data.

At step <NUM>, the drowsy detection system analyzes the path history data to determine, based on the driving pattern indicated in the path history data, whether the remote vehicle is operated by a drowsy driver.

At step <NUM>, responsive to determining that the remote vehicle is operated by a drowsy driver, the drowsy detection system executes a remedial action (e.g., either sub-step <NUM> or sub-step <NUM>) that is operable to modify the risk created by the drowsy driver.

At sub-step <NUM>, if the ego vehicle is a non-autonomous vehicle, then the drowsy detection system notifies the driver of the presence of the drowsy driver. This includes a visual notification (e.g., via the head unit), an audio notification or a combination of visual and audio notification.

At sub-step <NUM>, if the ego vehicle is an autonomous vehicle, then the drowsy detection system provides digital data to the autonomous driving system that describes the geographic location of the remote vehicle (e.g., based on the GPS data that is included in the BSM data; see, e.g., <FIG> and <FIG>) and the trajectory for the remote vehicle so that the autonomous driving system can take evasive maneuvers including one or more of: (<NUM>) creating distance between the ego vehicle and the remote vehicle; and (<NUM>) applying a different model of behavior to predicting the behavior of the remote vehicle that is operable for predicting the behavior of drowsy drivers. The drowsy detection system may also provide visual and audio notifications to the driver of the ego vehicle so that the driver of the ego vehicle understands that the ego vehicle is about to take evasive maneuvers and why these maneuvers are occurring.

Referring now to <FIG>, depicted is a block diagram illustrating an example of the BSM data <NUM> according to some embodiments of the invention.

The regular interval for transmitting BSMs may be user configurable. In some embodiments, a default setting for this interval may be transmitting the BSM every <NUM> seconds or substantially every <NUM> seconds.

A BSM is broadcasted over the <NUM> DSRC band. DSRC range may be substantially <NUM>,<NUM> meters. In some embodiments, DSRC range may include a range of substantially <NUM> meters to substantially <NUM>,<NUM> meters. DSRC range is generally <NUM> to <NUM> meters depending on variables such as topography and occlusions between DSRC-equipped endpoints.

Referring now to <FIG>, depicted is a block diagram illustrating an example of BSM data <NUM> according to some embodiments.

A BSM may include two parts. These two parts may include different BSM data <NUM> as shown in <FIG>.

Part <NUM> of the BSM data <NUM> may describe one or more of the following: the GPS data of the vehicle; vehicle heading; vehicle speed; vehicle acceleration; vehicle steering wheel angle; and vehicle size.

Part <NUM> of the BSM data <NUM> may include a variable set of data elements drawn from a list of optional elements. Some of the BSM data <NUM> included in Part <NUM> of the BSM are selected based on event triggers, e.g., anti-locking brake system ("ABS") being activated may trigger BSM data <NUM> relevant to the ABS system of the vehicle.

In some embodiments, some of the elements of Part <NUM> are transmitted less frequently in order to conserve bandwidth.

In some embodiments, the BSM data <NUM> included in a BSM includes current snapshots of a vehicle.

Referring now to <FIG> and <FIG>, depicted is a method <NUM> for modifying the operation of a connected vehicle to reduce the risk caused by a drowsy driver according to some embodiments.

Referring now to <FIG>, at step <NUM> the drowsy detection system of the ego vehicle monitors for whether a driver monitoring system of the ego vehicle has determined that the ego vehicle is being operated by a drowsy driver.

At step <NUM>, the drowsy detection system of the ego vehicle determines that the driver monitoring system of the ego vehicle has detected a drowsy driver.

At step <NUM>, the drowsy detection system of the ego vehicle determines whether an automated driving system of the vehicle is engaged such that the ego vehicle is in automated driving mode. If the automated driving system of the vehicle is engaged, then the method returns to step <NUM> because a drowsy driver is not problematic if the vehicle is in automated driving mode.

At step <NUM>, the drowsy detection system of the ego vehicle inserts digital data into a BSM transmitted by the ego vehicle that (<NUM>) indicates that ego vehicle is being operated by a drowsy driver; and (<NUM>) that the ego vehicle is not in automated driving mode. The BSM also includes digital data that describes the geographic location of the ego vehicle and the trajectory of the ego vehicle.

At step <NUM>, the ego vehicle transmits the BSM.

At step <NUM>, the remote vehicle receives the BSM.

At step <NUM>, the drowsy detection system of the remote vehicle parses out the BSM data from the BSM.

At step <NUM>, the drowsy detection system of the remote vehicle determines that the ego vehicle is operated by a drowsy driver.

Referring now to <FIG>, at step <NUM>, responsive to determining that the ego vehicle is operated by a drowsy driver, the drowsy detection system executes a remedial action (e.g., either sub-step <NUM> or sub-step <NUM>) that is operable to modify the risk created by the drowsy driver.

At sub-step <NUM>, if the remote vehicle is a non-autonomous vehicle, then the drowsy detection system of the remote vehicle notifies the driver of the remote vehicle about the presence of the drowsy driver. This includes a visual notification (e.g., via the head unit), an audio notification or a combination of visual and audio notification.

At sub-step <NUM>, if the remote vehicle is an autonomous vehicle, then the drowsy detection system of the remote vehicle provides digital data to the autonomous driving system of the remote vehicle that describes the geographic location of the ego vehicle (e.g., based on the GPS data that is included in the BSM data) and the trajectory for the ego vehicle so that the autonomous driving system of the remote vehicle can take evasive maneuvers including (<NUM>) creating distance between the remote vehicle and the ego vehicle and (<NUM>) applying a different model of behavior to predicting the behavior of the remote vehicle that is operable for predicting the behavior of drowsy drivers. The drowsy detection system of the remote vehicle may also provide visual and audio notifications to the driver of the remote vehicle so that they know about the presence of the drowsy driver and why the remote vehicle may be operating in an unexpected way.

In the above description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the specification. It will be apparent, however, to one skilled in the art that the disclosure can be practiced without these specific details. In some instances, structures and devices are shown in block diagram form in order to avoid obscuring the description. For example, the present embodiments can be described above primarily with reference to user interfaces and particular hardware. However, the present embodiments can apply to any type of computer system that can receive data and commands, and any peripheral devices providing services.

Reference in the specification to "some embodiments" or "some instances" means that a particular feature, structure, or characteristic described in connection with the embodiments or instances can be included in at least one embodiment of the description. The appearances of the phrase "in some embodiments" in various places in the specification are not necessarily all referring to the same embodiments.

Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms including "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices.

The present embodiments of the specification can also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, including, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flash memories including USB keys with non-volatile memory, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

The specification can take the form of some entirely hardware embodiments, some entirely software embodiments or some embodiments containing both hardware and software elements. In some preferred embodiments, the specification is implemented in software, which includes, but is not limited to, firmware, resident software, microcode, etc..

Furthermore, the description can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

A data processing system suitable for storing or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including, but not limited, to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem, and Ethernet cards are just a few of the currently available types of network adapters.

Finally, the algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the specification is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the specification as described herein.

The foregoing description of the embodiments of the specification has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the specification to the precise form disclosed. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims of this application. As will be understood by those familiar with the art, the specification may be embodied in other specific forms while not leaving the scope of the claims.

Claim 1:
A method comprising:
detecting, by a second connected vehicle (<NUM>), whether a second driver of the second connected vehicle (<NUM>) is drowsy;
determining, by the second connected vehicle (<NUM>), whether the second connected vehicle (<NUM>) is in automated driving mode;
inserting, into a Vehicle-to-Everything message, digital data that describes whether the second driver of the second connected vehicle (<NUM>) is drowsy, and whether the second connected vehicle (<NUM>) is in automated driving mode;
receiving, by a first connected vehicle (<NUM>), the Vehicle-to-Everything message indicating that the second connected vehicle (<NUM>) is being operated by a drowsy driver based on the digital data included in the Vehicle-to-Everything message,
characterized by determining, by the first connected vehicle (<NUM>), whether it is in an automated driving mode; and
responsive to the first connected vehicle (<NUM>) not being in automated driving mode, providing a notification to a first driver of the first connected vehicle (<NUM>), and
responsive to the first connected vehicle (<NUM>) being in automated driving mode, providing the notification to the first driver of the first connected vehicle (<NUM>), and the first connected vehicle (<NUM>) automatically taking an evasive maneuver to avoid the second connected vehicle (<NUM>).