FIELD OF THE INVENTION

The present invention relates generally to collecting information from traffic hardware devices and transmitting traffic data to remote devices. The technology may be installed in new or existing traffic control cabinets or independently. The invention has particular advantages for improving traffic safety, reducing traffic congestion, connecting vehicles and automating vehicles.

BACKGROUND

Existing traffic signals at intersections and along roadways utilize various traffic hardware devices to affect or monitor signalization. Generally, these devices are positioned adjacent to the intersection they impact and are frequently disposed upon traffic signal poles or arms (e.g., cameras), within a traffic control cabinet (e.g., conflict monitor unit), or in/on the roadway pavement (e.g., loop detector). Traffic control cabinets are well known within the industry and generally comprise an enclosure constructed from metal or plastic to house electronic equipment associated with a traffic signal or other traffic control/monitoring devices. For example, the National Electrical Manufacturers Association specifies various cabinet types which may be effective for housing embodiments of the present invention. Some specific, non-limiting examples include a NEMA P-44 or Model 332 marketed by Trafficware®, Econolite®, McCain®, etc. As used herein, “traffic control cabinet” may also refer to a control device disposed adjacent to a railway or at-grade railway crossing.

Within a traffic control cabinet, a control assembly may be used to manipulate the various phases of a traffic signal. The operation of the traffic signal may be adaptive, responsive, pre-timed, fully-actuated, or semi-actuated depending upon the hardware available at the intersection and the amount of automation desired by the operator (e.g., municipality). For instance, cameras, loop detectors, or radar may be used to detect the presence or location of a vehicle. In response to a vehicle being detected, a traffic signal controller may alter the timing of the traffic signal cycle, for example, to shorten a red light to allow a waiting vehicle to traverse the intersection without waiting for a full phase to elapse. As another example, a traffic signal controller may extend a green phase if it determines an above-average volume of traffic is present and the queue needs additional time to clear before initializing a red phase.

Motorists are frequently concerned with the duration of drive times and seek to identify routes that may reduce overall travel time. Often this includes avoiding intersections which are characterized by either long red phases or excessive traffic congestion causing a queue too large to clear during a single signal cycle. However, the nature of traffic congestion makes it very difficult to predict and therefore difficult to avoid. For instance, traffic collisions and stalled vehicles may occur anywhere within a traffic network, causing a localized disturbance in traffic flow which may ripple throughout the system.

Additionally, not all disruptions in traffic flow are caused by substantial events such as collisions and breakdowns. In many instances, minor delays are created by human behavior which may aggregate into significant delays. For instance, a minor delay may be created following a red light phase during which a driver may not instantly react to the fact that the light has changed to green. This may be caused by the driver being distracted or simply by the human delay in perceiving the change and then reacting to it. Although a single instance of such a delay may be only a few seconds or even less than one second, the aggregated effect of dozens or hundreds of these delays throughout a corridor may add up to a consequential delay.

Safety is a primary concern in the operation of motor vehicles. In some instances, a driver may be distracted by a mobile device, a passenger in the vehicle, or an interesting object or occurrence outside the vehicle. For instance, lingering car accidents or traffic stops by police often distract uninvolved drivers as they pass by. Unfortunately, distractions frequently lead to collisions, injuries, and fatalities.

Another problem in the industry involves security vulnerabilities in communication protocols. This is a concern in a variety of contexts, including connected, autonomous or semi-autonomous vehicles. For example, messages between one traffic signal and another, or between a traffic signal and a vehicle may be spoofed or otherwise accessed by unauthorized parties. One concern in this regard is that a communication may be sent to a vehicle (or a device associated with a vehicle) emulating a message from a traffic signal but which contains false information. For example, the message may indicate that a given approach to an intersection is currently under a green phase when in fact it's a red phase (or vice versa). Such communications may cause traffic collisions. A means of securing and authenticating communications from traffic signals is needed to prevent such spoofing or unauthorized access.

SUMMARY OF THE INVENTION

One embodiment of the present invention is installable in or adjacent to traffic control cabinets located at roadway intersections, at-grade rail crossings, or otherwise adjacent to roadways, and may collect data from various traffic hardware devices associated with the respective intersection. In one aspect, the invention is a localized data collection module (“LDCM”) which may be connectable to an existing data bus within a traffic cabinet. An LDCM may detect electric signal changes within a data bus and interpret them into useful data, such as messages sent from various sensors. For example, a loop detector may send a signal that a vehicle has passed over the loop. This signal may be sent through the data bus to other hardware such as a traffic signal controller. An LDCM may intercept the signal and identify it as a signal from the loop detector indicating the presence of a vehicle.

Alternatively, an LDCM may be in direct communication with a processor (the term “a processor” as used herein may refer to a single processor or a plurality of processors configured to perform recited functions) of a control assembly. In this regard, an LDCM may not need to intercept signals through a data bus, but rather may receive signals directly from, and may be in direct communication with, a processor associated with traffic hardware devices at an intersection. In this regard, such a processor may be operable to process various signals from a plurality of traffic hardware devices and also to communicate with an embodiment of the present invention (e.g., an LDCM) to send data directly thereto.

In either regard, the present invention may collect data from a plurality of traffic hardware devices disposed locally at a site of interest along a roadway (e.g., an intersection). This data may be comprised of traffic signal phase timings (past, current, and potential), cycle times, traffic counts, camera imagery, radar signals, loop detector responses, conflict monitor alerts, etc. Any data generated locally by traffic hardware devices may be considered relevant to the present invention and may be collected accordingly. The data may be collected using any protocol including but not limited to serial, USB, FTP, SDLC, Ethernet, or general I/O. The data may be compiled and aggregated locally by the present invention. The aggregated data may be transmitted over a network connection (e.g., 802.11, LTE, Bluetooth, Ethernet, fiber optic, satellite, radio, etc.).

The data may be received at a data center for storage in a cloud-based architecture. In this regard, the data may be accessible remotely from any location via a network connection. Alternatively or additionally, data may be received at a traffic control center for use by a municipality operating the respective traffic network.

Traffic data (e.g., related to roadway, railway, vehicles, etc.) from various traffic hardware devices and other components associated with a traffic control cabinet, as well as status data pertaining to the state and condition of an LDCM itself, may be analyzed by an LDCM to trigger certain actions in accordance with rules stored on a memory module of the LDCM. For instance, a rule may contain instructions to generate an email alert to a client when a rule has been satisfied, indicating that a power failure has occurred. As another example, a similar alert may be generated for the failure of a traffic camera, or any other traffic hardware device. The health of the LDCM may also be monitored, and alerts may be transmitted if an internal temperature exceeds a threshold, if voltage drops below a threshold, etc. Notably, traffic data may be transmitted to a cloud platform, and the cloud platform may analyze the traffic data to determine if an alert is to be generated.

It should be appreciated that many hardware options exist for the implementation of the current invention. For example, a storage device may be disposed locally in a traffic cabinet to at least temporarily store all of the data being received. This may be a stand-alone storage device or it may be incorporated into (e.g., housed within) an LDCM. Data may be stored temporarily as it is received and periodically transferred from an LDCM to a remote location via a network connection. For example, one hour worth of data may be acquired at which point the data may be sent to a cloud storage location. After confirmation is received that the data has been properly duplicated, the local storage device may erase the data locally such that capacity is created for collecting a subsequent period of data. Alternatively, data may be streamed out as it is received such that data may be remotely accessible in real-time. Additionally, local storage may be used to cache data during network outages such that data loss is avoided or minimized.

A conventional server may be disposed locally (e.g., in a traffic control cabinet) or remotely (e.g., in a traffic control center). A server may be operable to allow access to data by a plurality of client applications through application program interfaces (“APIs”), for instance. For example, a municipality may access data to ascertain and analyze the state of the traffic network. The information may be useful, for example, to reduce congestion, improve travel times, increase safety, plan future roadway improvement projects, coordinate advertisements (as discussed below), etc. A server as utilized by the present invention, may include an input port operable to receive data (e.g., traffic information) through a network, a memory module to store logic, a processor to apply the logic to the data received, and an output port to transmit data to another location or device (e.g., a cloud storage data center, a vehicle, etc.). A server may be an independent unit or may be integrated with an embodiment of the present invention. For instance, a localized data collection module may comprise a server.

Although current traffic operations are generally controlled locally within a municipality, the present invention may enable traffic control centers to be located anywhere around the globe. As has been discussed, data collected by the present invention may be transmitted to a cloud-based location such that the data is accessible remotely. In this regard a central traffic center may be set up to control the operations of a plurality of municipalities (or other entities responsible for traffic operations). This may be advantageous, for instance, in coordinating traffic operations throughout an entire metropolitan area rather than having each entity within the area operate their traffic network independently, which may create conflicts (e.g., where one municipality's traffic network borders another's and traffic signals are not coordinated across the border) that exacerbate congestion or travel time issues.

In another aspect, the present invention may be a set of computer readable instructions operating on a processor to perform the various functions described herein. The set of computer readable instructions may be stored in local memory such as on an LDCM, it may be installed on existing hardware within a traffic control cabinet, or it may be stored in a remote location accessible through a network connection. Accordingly, the present invention may be deployed within existing traffic control infrastructure.

In yet another aspect, the present invention may be operable to perform various procedures associated with traffic data and the transfer thereof. For example, the present invention may synchronize a clock (either an existing clock integrated with traffic hardware devices such as a traffic signal controller or a clock provided within the present invention) with a clock of a remote device for data synchronization. This procedure may be conducted using a GPS signal, an NTP server, contact closure, or any other method which allows the local devices and the remote devices to maintain time synchronization. In this regard, the local clock (e.g., at a traffic signal) and the remote clock (e.g., at a cloud server) may be maintained in unison such that stored and transmitted data are associated with time stamps which are reliable on both ends of a data transfer. These time stamps may be used to ensure all data is transferred from the local site to the remote site and also that no data is transferred more than once. Thus, a data transfer may be performed in which only data recorded up until a certain time is sent, a record of this time is created, and the next data transfer only includes data which was recorded after the aforementioned recorded time.

The present invention may be operable not only to receive data from various traffic hardware devices, but it may also be able to retrieve data. For example, the present invention may send a request to a traffic hardware device, in response to which the traffic hardware device transfers the requested data. In this regard, the data may either be pushed by the various traffic hardware devices to the present invention or the present invention may retrieve the data as needed. Furthermore, the present invention may be operable to validate the data it receives. In this regard, the data may be inspected as it is received to ensure it is in the proper format and has not been compromised. Before transmitting the data, the present invention may compress the data to reduce the volume needing to be transmitted and may encrypt the data (e.g., using SSL or any other encryption technique) to ensure privacy and security.

In an embodiment, an LDCM comprises the following features:

ConnectivityCell Modem3G/LTE/GSM/GPRS; 4G OptionalWiFiTravel Time (Receive Only)Ethernet PortStandard - 2 ports (10/100 Base-T)EIA-232YesSDLCStandard (NEMA TS-2 controllers & MMU's)USBStandard - 2 portsBluetoothOptionalAux. PortsStandard - 8 ports (RE-485 inputs)Cabinet I/OAnalog Inputs16 (8 × 120 VAC; 8 × 24 VDC)Digital Inputs20 (16 × 24 DC; 4 × 24 VDC)Time SyncNormally Open and Normally Closed with userselectable timeDigital Outputs3 (either Normally Open and Normally Closed 5 Arelay)MiscellaneousOperating SystemLinux - Ubuntu 12.04.2 LTS kernel ver. 3.15.3GPSGeolocation with Time SyncOperating−40° F. to 176° F.TemperatureHumidity0-95% Non-CondensingDimensions5.5″ (D) × 8.2″ (H) × 3.5″ WWeight3.6 lbs.Power Input8-28 VDC (2 A 250 V 5 mm × 20 mm Fast-blo fuse)VoltageReal-time ClockYesFlash DiskYesBattery BackupYes - allows communications and logging up to ~5hoursBatteryNon-Spillable Sealed Lead-Acid 6 VDC 4.5 AhProtocolsSDLCStandard (Ts2 or TS2 Type 2 cabinets only)RS-485Standard up to 32 channels of inputiCITE ™Used to connect to iCITE ™G2 ™OtherSolar PowerYesCapableAntenna5 band (Cellular, GPS, WiFi, Bluetooth and DSRC)

In one embodiment, a localized data collection module may include a least one input port, a time synchronization module, a power module, a backup battery, a multi-band antenna, a data modem, a data storage module, and a processor. An input port may be operable to receive data from either wired or wireless communications channels. For example, a traffic hardware device, such as a camera, may wirelessly transmit video footage (which may include still frames) to the LDCM and such video footage may be received through the input port. In this regard, an input port may comprise or may be in operative communication with an antenna, an Ethernet port, a coaxial port, etc. Notably, localized data collection modules may be able to transmit data from one LDCM to another. In this regard, an input port may receive incoming data from other LDCMs. LDCMs may form a data chain such that data is transferred from a first LDCM to a second LDCM, from the second LDCM to a third LDCM, and so on until the data reaches a communications channel which provides a connection to a remote terminal or storage location. A time synchronization module may comprise a clock, or may be in operative communication with a clock. A time synchronization module may comprise a global positioning system receiver operable to calculate a local time based on signals received from at least one satellite transmitter. A time synchronization module may comprise instructions for a processor to maintain a local clock in synchronization with a remote clock. A power module may comprise a power connection for attachment of a power cable to an LDCM. The power cable may transfer power to an LDCM from any power source available. For example, a power source may be a solar panel, an electric power grid, etc. A multi-band antenna may be any antenna operable to receive data, and perhaps even transmit data, via more than one radio frequency band. Radio frequency bands receivable by a multi-band antenna may include any radio frequency bands such as, but not limited to, cellular, 3G, 4G, LTE, GPS, WiFi, Bluetooth, DSRC, GSM, GPRS, etc. A data modem may be any device capable of transmitting data to an external receiver. Transmission of data from a data modem may be via a wired or wireless channel. For example, a data modem may comprise an Ethernet connection, a fiber optic connection, a radio frequency transmitter operative on any of the previously described bands, a telephonic connection, a coaxial connection, etc. A data storage module may comprise any means of storing data, including but not limited to, a flash memory device, a hard disk drive, a solid state hard drive, etc.

A localized data collection module may be installable in a traffic control cabinet. In this regard, an LDCM may be sized and configured to be installed into an existing traffic control cabinet which has been installed at a roadway intersection or other roadway point of interest. Alternatively, an LDCM may be installable on an external wall of a traffic control cabinet should there not be a sufficient volume of space available for installation inside the traffic control cabinet. Additionally, an LDCM may be installable adjacent to a traffic control cabinet such as in an in-ground utility box or on a support mast. In this regard, a support mast may refer to a mast used to support traffic signals in a position above or adjacent a roadway, or may also refer to a mast, such as a pole or stake, used to support an LDCM in a location near traffic hardware devices.

An LDCM may be operable to receive traffic data from at least one traffic hardware device (e.g., traffic controller, data bus, crosswalk pedestrian push button, camera, loop detector, radar device, thermal sensor, crossing arm, train detection circuit, etc.), to store at least a portion of the traffic data locally in a storage module, to process at least a portion of the traffic data locally to generate an alert (e.g., applying locally stored rules to the traffic data to determine whether or not a condition is satisfied), and to transmit at least a portion of the traffic data to a remote facility. An alert generated by an LDCM may provide a remotely disposed client (such as a municipality) an indication of a status of a device in operative communication with the localized data collection module. In this regard, an alert may notify a client that a camera has detected undesirable weather conditions, a traffic controller is overheated, a loop detector is inoperative, a power source is providing less than the recommended voltage, a power surge has occurred at the traffic control cabinet, etc. In fact, an alert may include any information that a client may find relevant for continued operation or monitoring of the intersection and equipment associated therewith. An alert, in this sense, may itself be a message which is communicated to the client, or may be a signal which is transmitted to a remote device disposed at another location to cause the remote device to generate a message to be sent to the client. For example, an LDCM may not have the capacity to transmit an email message. Therefore, an LDCM may send an alert to a remotely disposed email server, instructing the server to generate an email to the client. Notably, alerts or messages sent to clients may utilize any appropriate means of communication. For example, a telephone call may be placed, a text message may be sent, or a notification may be made available through a web-based interface such that the message is made available when a client logs in to the interface.

In another embodiment, a system for aggregating and communicating traffic data may be provided. Such a system may comprise a traffic control cabinet disposed adjacent to a roadway intersection, a plurality of traffic hardware devices operable to collect traffic data, a localized data collection module, and a remote storage facility. Such a remote storage facility may be a municipal traffic control center, a cloud-based storage center, or any other appropriate storage device disposed remotely from an LDCM. Data may be transmitted to the remote storage facility via a wireless communications channel, a wired connection, or both. In some implementations, existing traffic control cabinets (or others to be installed in the future) are not connected to robust data channels such as a cable or fiber optic network. In some instances, existing traffic hardware devices at an intersection are only able to communicate locally with other devices and there is no means of accessing the devices or data contained thereon from a remote location. An LDCM as disclosed herein may be operable to provide a data connection from a signalized intersection to remote devices. In this embodiment, a localized data collection module may be disposed within the traffic control cabinet and may be operable to aggregate traffic data from a plurality of traffic hardware devices and transmit at least a portion of the traffic data to a remote storage facility.

In another embodiment, the present invention may include a method of aggregating and communicating traffic data. The method may include generating traffic data by observing conditions present at a roadway intersection using a plurality of traffic hardware devices, transmitting traffic data to a localized data collection module disposed within a traffic control cabinet via a plurality of communications channels (or the devices may transmit on a single channel), receiving the traffic data at the localized data collection module via a plurality of input ports (or alternatively through a single input port), storing at least a portion of the traffic data in a memory module disposed within the localized data collection module, validating at least a portion of the traffic data using a processor disposed within the localized data collection module, compressing at least a portion of the traffic data using the processor, encrypting at least a portion of the traffic data using the processor, transmitting at least a portion of the traffic data to a remote storage facility, and receiving a confirmation, from the remote storage facility, indicating that at least a portion of the traffic data is successfully received at the remote storage facility. Notably, each of these steps may be optional in various implementations of the present invention.

Furthermore, transmitting at least a portion of the traffic data to remote storage facility may comprise sending at least a portion of the traffic data through a wireless communications channel such as 3G, 4G, LTE, GSM, or GPRS. Alternatively or additionally, transmitting at least a portion of the traffic data to remote storage facility may comprise sending at least a portion of the traffic data through a wired communications channel, such as Ethernet, fiber optic, or cable.

The method may further involve accessing a clock maintained by the localized data collection module, assigning time stamps to traffic data as it is received, recording a first time stamp indicating a first time associated with a first data transfer to the remote storage facility, wherein the first data transfer comprises traffic data stored at the localized data collection module and assigned time stamps indicating times of receipt before the first time, and recording a second time stamp indicating a second time associated with a second data transfer, wherein the second data transfer comprises traffic data stored at the localized data collection module and assigned time stamps indicating times of receipt after the first time and before the second time.

The plurality of communications channels described above may be in operative communication with a data bus disposed within the traffic control cabinet. The data bus may interconnect a plurality of traffic hardware devices for transmission of data messages between various traffic hardware devices. Transmitting the traffic data to a localized data collection module may comprise intercepting the data messages as they are transmitted between the plurality of traffic hardware devices via a communications channel (could be any appropriate means such as a wire or Bluetooth) linking the data bus to the localized data collection module.

Although traffic data, as used herein, may comprise a wide variety of information, some non-limiting examples of information which may be included in traffic data include video footage, a traffic signal cycle timing schedule, a volume of traffic observed at an intersection during a specified period of time, an observed time required for a vehicle to traverse a path leading to the roadway intersection (e.g., a camera or sensor at remote location may detect a vehicle and, in response, initiate a timing sequence which is terminated when the vehicle is detected at the roadway intersection), personally identifiable information (e.g., license plate number or an image of a driver's face), etc.

Another aspect of the present invention is a cloud platform. A cloud platform may be operable to receive, process, store or retrieve traffic data. All data received by such cloud platform may be managed by proprietary architecture. Data may be decompressed, decrypted, processed and stored. Databases associated with the architecture may utilize primary keys which allow for efficient data storage and retrieval. Data may be homogenized by storage with a high level of resolution such that information of the same type but from different traffic hardware devices with different data formatting structures may be stored and accessed in a similar format. The data may be utilized through a web-based portal for accessing, analyzing, or creating visualizations of the data.

Another aspect of the present invention is a method of communication between traffic signals and vehicles. Communications may be sent via any wireless means of transmission (e.g., radio). In this regard, a traffic signal may be able to communicate to a vehicle information about the state of the traffic signal (e.g., Signal Phase and Timing (“SPaT”) message, current signal output, emergency vehicle data, etc.). For instance, current phase information may be sent, thereby letting the vehicle know that a light is currently red for example, allowing the vehicle to safely slow to a stop. This may be particularly advantageous for autonomous or connected vehicles to allow them to safely traverse intersections efficiently and without collisions.

Notably, the present invention is not limited to only autonomous vehicles but has advantages which are applicable to manually operated vehicles as well. For instance, communications from a light may be utilized to generate an alert to a driver. In this regard, if a vehicle is approaching a red light and not slowing down, an audible tone or message may be conveyed to the driver as a warning.

Also, a driver may be alerted to begin moving if distracted when a green light appears or is about to appear. It should be appreciated that a traffic signal or associated traffic hardware devices may, but need not, communicate with a vehicle itself. For instance, a device associated with a vehicle, rather than a vehicle itself, may receive communications. For example, a traffic signal monitoring device may be disposed in a vehicle. Such a device may include an antenna for receiving signals from traffic lights (directly or through a network), an output port for transmitting instruction or alert signals to the vehicle or other devices (may be Bluetooth, wired connection, etc.), a speaker for generating audible alarms, a GPS receiver for identifying the vehicle's location and generating a data set comprising location information, or logic for applying rules which associate location and traffic signal phases to generate alerts. A traffic signal monitoring device may be: integrated with a vehicle, a stand-alone unit installed by the manufacturer, an after-market accessory, or any other device with the described functionality (e.g., an occupant's mobile phone). For example, a traffic signal monitoring device may include an in-dash display console.

Another aspect of the present invention is a security and authentication protocol for communications between traffic signals and vehicles (including devices within vehicles). In this regard, a public/private key system may be used to authenticate that a signal received by a vehicle is relevant to a particular traffic signal. This may be advantageous for securing messages (determining which communications may be fake, e.g., spoofed) and also for filtering out messages that are being transmitted by a traffic signal within range of the vehicle but which are not from the traffic signal at the intersection the vehicle is approaching. In this regard, a vehicle may be receiving communications from a plurality of traffic signals at any given moment. However, there may be a particular signal (or signals) which is most relevant at that moment. For instance, a vehicle approaching an intersection may primarily concern itself with that intersection's traffic signal communications and may ignore the communications from all other traffic signals being received. Alternatively, the communications from the other traffic signals may also be processed and the data may be stored in order to be utilized as the vehicle approaches those particular traffic signals. In some instances, extraneous traffic signal communications may be received from intersections which are not pertinent to a vehicle's planned route and therefore may be ignored or discarded. In that same regard, a vehicle may store data from all traffic signals along its planned route which it receives. This may allow logic within the vehicle (or associated device) to plan a route, braking, accelerating, or other functions well before reaching a particular intersection. For example, a vehicle may be able to plan ahead several traffic signals by analyzing current traffic conditions and traffic signal cycle timings in order to determine an optimal strategy regarding routing, speed, etc. to reduce travel time or improve fuel efficiency.

In order to properly utilize communications being received, a vehicle may need to identify which particular communication is being sent by which particular intersection's traffic hardware devices (e.g., an LDCM, traffic signal controller, etc.). Moreover, a need may exist to determine which specific approach is transmitting a particular communication. For instance, a northbound vehicle with a planned left turn may need to determine which communication being received is indicative of the northbound left-turn traffic signal, as opposed to the other approaches for that particular traffic signal or other intersections altogether. A vehicle may employ various methods for determining its geographical location in order to ascertain which traffic signal is most relevant at a given time. One such method may be to utilize a global positioning satellite (“GPS”) signal. In this regard, a vehicle's GPS receiver (or any other GPS receiver associated with a vehicle such as an occupant's mobile phone) may ascertain the location of the vehicle and convey that data to a processor or logic. The location data may be used to identify which traffic signal's communications are most immediately relevant.

In this regard, public/private key pairings may assist a vehicle (or associated device) in filtering communications and verifying their authenticity. Each traffic signal (or each traffic data transmitter associated with a traffic signal or other feature of interest such as a traffic sign, emergency vehicle access, truck entrance, merge lane, rail crossing, etc.) may be assigned a secret (i.e., private) key for signing the information which it transmits and also a public key for authentication by vehicles. Each traffic signal monitoring device may have access to a unique public key for each intersection (or other feature of interest) in a traffic network. Public keys may be subscribed to by a vehicle and downloaded or accessed over a network or may be uploaded to a vehicle from a memory device (e.g., flash memory, hard disk drive, SD card, etc.). In this regard, a vehicle may access public keys for every traffic signal anticipated along its planned route. A vehicle may additionally or alternatively access public keys for all traffic signals within a given radius of the vehicle or region so that the public keys are available for use by the vehicle if/when it changes its route. Public keys may be retrieved or received before a vehicle embarks on a trip or while a vehicle is in use. A vehicle may be able to verify authenticity of each message by using a public/private key pair. Moreover, because every traffic signal, and perhaps even every approach, may have its own public/private key pair, a vehicle may be able to identify which traffic signal is the source of a particular communication.

Keys may be generated, issued, and revoked by a Trusted Key Authority. In the event it is determined that a private key has been compromised, the Trusted Key Authority may update that traffic signal's key. A web-socket connection may be initiated over a secure socket layer (“SSL”) connection to a server. Upon notification of a compromised key, a server may immediately push a new key to a traffic signal for signing future communications. This procedure may also be used pro-actively to prevent spoofing before it occurs.

Another aspect of the present invention is a mobile application. Such an application may be installed within a vehicle's integrated memory (e.g., navigation system, radio receiver, etc.) or on a mobile device (e.g., cellular telephone). Although this disclosure primarily discusses the application as it applies to a mobile device, it is similarly applicable as an integral feature of a vehicle. An anticipated function of the mobile application is to provide improved safety for motor vehicle operation. In this regard, logic may be implemented to apply certain rules which generate alerts to drivers. For example, the application may force a mobile device to suppress notifications (e.g., text message received, incoming phone call, new social media post) while a vehicle is in motion. In this regard, a driver may not receive notifications which may distract the driver while operating the vehicle. While suppressing notifications, the application may also be receiving data (e.g. directly through infrastructure to vehicle (I2V) or infrastructure to mobile (I2M) technology) or accessing data (e.g., through an internet connection) associated with traffic signals along a vehicle's route such as current or projected traffic signal infoiiiiation. If, for instance, a vehicle stops at a red light, the application may receive data associated with that traffic signal which indicates the light will remain red for at least some period of time (e.g., sixty seconds). Logic implemented by the application may determine that the remaining time is sufficient for the driver to review the notifications which are currently being suppressed. Therefore, the application may allow the mobile device to provide the notifications to the driver, thus allowing the driver to access content (e.g., new text message, missed phone call data, or new social media posts). As a traffic signal nears the end of a red light, the application may once again begin suppressing notifications and/or lock the device. The application may also generate an alert which notifies the driver that the red light will soon change to green (e.g., within 3 seconds) in order to allow the driver to refocus on operating the vehicle. One, should appreciate that the previously described functionality may prevent a driver from being distracted while driving, yet allow the driver to interact with his/her phone while stopped at traffic signals. Additionally, minor traffic delays may be avoided by alerting drivers to changes in traffic lights before they occur, thus allowing drivers to be prepared rather than distracted.

In another embodiment of a mobile application, an alert may be generated to prevent a vehicle from running a red light or colliding with another vehicle. In this regard, the application may detect that a mobile device is currently unlocked or the application may receive or retrieve data from the mobile device indicating key strokes, screen swipes, or other input from the user. This information may allow the application to recognize that the mobile device is currently being operated by a driver. Contemporaneously, the mobile device may be receiving traffic signal communications from a nearby intersection which the vehicle is approaching. If a red or amber light is being indicated for the driver's approach, if a red or amber light will soon be displayed, or if traffic is currently stopped or slowly moving at the intersection, the application may generate an audible or visual alert notifying a driver of the hazard which may permit the driver (or artificial intelligence) to safely decelerate the vehicle.

One should appreciate that such an application, associated logic, or processor may access and utilize various data in determining if or when alerts should be generated. For example, GPS location may identify the vehicle's speed and direction, gyroscopes or accelerometers may measure acceleration/deceleration, or third-party navigation applications may provide route data. All of this data, and more, may be employed by the application and its associated logic, or may be sent to a server for processing.

As mentioned above, the present invention may also be advantageous for implementing advertising strategies. For instance, traffic data may be combined with application data to determine that a driver is currently stopped at a red light, that the red light is expected to last for at least a certain period of time (e.g., 20 seconds), that the driver is at a certain location and that the driver is currently running the application on his/her mobile device. This information may allow a remote server to select an advertisement to push to the driver's mobile device for immediate or delayed playback. Alternatively or additionally, advertisements may be sent to and stored on the device for subsequent selection for playback by the device. The advertisement may be selected, for example, based upon the driver's proximity to a given business, the duration of a video advertisement in relation to the traffic signal timing, etc. Moreover, a pricing model may be constructed which incorporates various factors such as a driver's proximity to a business being advertised, how long an advertisement may be displayed without interfering with the driver's operation of the vehicle, etc. As an example, a business may agree to a higher payment for an advertisement that will be displayed for thirty seconds on a mobile device of a user within a quarter-mile of a business than the same business would pay for an advertisement that will be displayed for ten seconds on a mobile device of a user over a mile away from the business. This dynamic pricing model may be desired to relate pricing with advertising hit rates.

There are many alternatives to the specifics discussed herein. For one thing, any of the features shown in any of the discussion provided herein could be incorporated into or combined with any other feature or design discussed herein. As a further example, any of the functionality of any of the described components could be combined with other components or further separated (e.g., method elements may be performed in other sequences, system elements may be combinable with method elements, etc.). While the embodiments of the invention described in the foregoing description are illustrative, they are merely examples and not restrictive in character. Furthermore, the word “or” as used within this application may be interpreted as “and/or” such that any combination of elements within the phrase may be included. The word “vehicle” may reference not only any means of transportation on a roadway (e.g., motor vehicle, car, truck, bicycle, motorcycle, autonomous vehicle, manually operated vehicle), but may also reference a device which is disposed within or integral with a vehicle (e.g., a cellular phone, tablet, laptop computer, traffic signal monitoring device, etc.).

