Computer-implemented method for communicating emergency information to a vehicle

Abstract

Computer-implemented method for communicating emergency information to a vehicle, including: Receiving at least one emergency notification with a geographic attribute on a vehicle computer, wherein the at least one emergency notification includes location information related to an emergency; Receiving GPS data on the vehicle computer; Determining the geographical location of the vehicle based on GPS data on the vehicle computer; Select at least one emergency notification based on the vehicle's geographic location and the geographic attribute on the vehicle computer and Issuance of at least one selected emergency notification, such that a notification is presented to a vehicle occupant, characterized in that the procedure further comprises: Determine, if the vehicle is not within the geographical location of the emergency, whether a direction of movement of the vehicle leads towards the geographical location of the emergency, holding the at least one emergency notification in a message queue of the vehicle computer if the direction of movement of the vehicle leads towards the geographical location of the emergency, and present the at least one emergency notification in the queue when the vehicle has reached the geographical location of the emergency. Determine, if the vehicle is within the geographical location of the emergency, whether the vehicle's direction of movement is away from the geographical location of the emergency, and issue at least one selected emergency notification until the vehicle is outside the geographical location.

Description

[0001] Various embodiments relate to a method and system for notifying a vehicle occupant of emergencies at the local, state, and national levels. The vehicle occupant can also respond to the emergency notifications. In some embodiments, the vehicle's location can be used to determine which notifications are made available to the vehicle occupant.

[0002] It is the responsibility of local, state, and federal governments to notify the public of emergencies such as child abductions, weather-related emergencies, and public safety emergencies. Traditionally, such notifications were broadcast via television and radio.

[0003] In this field, there are several examples that provide methods for transmitting announcements. One example is US 2009 / 0322560 A1, which discloses a delivery of onboard notifications that maximizes communication efficiency while maintaining participant confidentiality. Specifically, the publication discloses a system and procedure for improving participant confidentiality while delivering location-based onboard notifications to participants in a mobile traffic reporting system. This is achieved by separating participant information from location information transmitted by a traffic monitoring vehicle. The onboard notifications include alerts about flash floods, hurricanes, Amber Alerts (child abductions), as well as non-crisis-related notifications such as traffic jams, locations of low-cost gas stations, and various points of interest.

[0004] Another example is US 2009 / 0325538 A1, which discloses a method for geotargeting emergency notifications. Specifically, the publication discloses that geotargeting, in combination with wireless notification capabilities, can be used to deliver notifications to a more specific geographic area. A system and method for performing geotargeting for different notification areas is discussed in the publication, enabling the delivery of emergency messages to mobile and static facilities of various types within a localized area. In the example provided by the publication, geotargeting supports the delivery area for wireless emergency notifications by identifying cell sites located within a specified geographic area that possess technologies capable of delivering wireless emergency notifications.The components of the telecommunications system that supports a wireless emergency notification system can be identified and mapped to any geographical area.

[0005] Another example is US 2007 / 0139182 A1, which discloses emergency communications for mobile environments. This publication specifically discloses systems and methods for interactive two-way communication with regard to emergency notifications and responses in mobile environments. A specific geographic area is designated for selective emergency communications. The emergency communications can include text, audio, video, and other data types. The emergency communications are sent to users' mobile communication devices, such as onboard telematics units, mobile phones, PDAs (Personal Digital Assistants), and laptops, currently located within the designated area. The sender of the emergency message or the user's service provider(s) can remotely control cameras and microphones belonging to the user's mobile communication devices.As one example given in the publication, a reversing camera, normally used when backing up, can be used to capture images and video that can help authorities locate a suspect. Users' vehicles can send photos or video streams of nearby people, cars, and license plates, along with real-time location information, in response to an emergency notification. Image recognition algorithms can be used to analyze license plates, vehicles, and faces captured by the user's cameras and determine if they match a suspect's description.

[0006] Another example is US 2007 / 0265768 A1, which discloses an audible / visual road warning information system device that can be mounted on the dashboard or carried in the hand. The publication specifically discloses an audible / visual road warning information system device, mounted on the dashboard or carried in the hand, designed to improve driver situation awareness and road safety by issuing child abduction warning messages and road warning information. The device also provides a summary of private businesses and their contact numbers, business hours, and detailed summaries of business services, special sales, and advertisements located along a road and at a road exit.The information is presented via a loudspeaker as an electronic voice and in text on a display screen, either attached to the dashboard of a vehicle, built into a vehicle radio, or as a portable handheld device.

[0007] German patent DE 602 07 992 T2 discloses a wireless communication system and method for generating position-dependent event data. A proximity server manages user profiles and position data for each user. With this information, event messages can be selected for individual users based on their position. A similar system is known from US patent 2009 / 0322560 A1. A server receives telemetry vehicle data to select position-related event data for individual users.

[0008] The present invention proposes a novel computer-implemented method with the features of claim 1. One aspect comprises a computer-implemented method for communicating emergency information to a vehicle. The method includes receiving one or more emergency notifications (e.g., state-issued emergency notifications) with a geographic attribute on a vehicle computer and furthermore receiving GPS data. A geographic location of the vehicle can be determined based on the GPS data. Based on the geographic location of the vehicle and the geographic attribute, at least one emergency notification is selected, and a notification is displayed so that it can be presented to the vehicle occupant.

[0009] In one embodiment, the vehicle's proximity to the geographical attribute can be received and / or determined, and the selected emergency notification is issued based on this proximity. In additional embodiments, a distance parameter defining the distance to the vehicle's geographical location can be used when issuing the emergency notification based on this distance parameter.

[0010] According to the invention, the geographical location of the vehicle will be based on the vehicle's direction of travel.

[0011] In some implementations, the selected emergency notification can be an updated notification.

[0012] Another aspect involves a computer program for communicating emergency information within a vehicle. This program can include instructions for receiving one or more emergency notifications with a geographic attribute, as well as GPS data. The program can also include instructions for determining the vehicle's geographic location based on GPS data and for determining the vehicle's direction of travel. Depending on the vehicle's geographic location and direction of travel, one or more emergency notifications can be issued and presented to a vehicle occupant.

[0013] The direction of travel can be determined based on the geographical attribute of the emergency notification(s).

[0014] In some embodiments, one or more emergency notifications can be issued based on a standard notification location (which can optionally be defined by the vehicle occupant) and the geographical attribute. In other embodiments, the emergency notification can be issued based on a distance parameter that defines a distance from the standard notification location.

[0015] In some designs, the notification can be issued until the vehicle occupant acknowledges one or more emergency notifications. This can define an output priority for the notifications.

[0016] Another aspect includes a system that comprises at least one data processor configured to receive emergency notifications and GPS data. The data processor can further be configured to determine the vehicle's geographic location based on the GPS data. At least one emergency notification can be selected based on the vehicle's geographic location. The selected emergency notification can then be transmitted so that it can be presented to a vehicle occupant.

[0017] In some embodiments, the emergency notifications may contain one or more images of a subject, including, but not limited to, missing persons, suspected criminals, and / or stolen vehicles. In some embodiments, the image may be a license plate.

[0018] These and other aspects will become clearer with reference to the attached drawings and the following detailed description of the invention.

[0019] The figures identified below are exemplary of some embodiments of the invention. The figures are not intended to limit the invention as set forth in the appended claims. The embodiments, with regard to their organization and function, together with their further purpose and advantages, are best understood with reference to the following description, in conjunction with the accompanying drawings, in which Fig. 1 shows a detailed block diagram of a vehicle computer system; Fig. 2. A block diagram of a system that notifies a vehicle occupant of emergencies and allows the vehicle occupant to respond to the emergencies; Fig. 3 shows a user registration process associated with the telematics services, the execution of which is requested in the vehicle by a user; Fig. 4 the operation of the in Fig. 2 system shown according to one embodiment; and Fig. 5 the operation of the in Fig. 2 shows a system according to another embodiment.

[0020] Detailed embodiments of the invention are disclosed herein. It is understood, however, that the disclosed embodiments are merely exemplary of an invention that can be implemented in various and alternative forms. Therefore, specific functional details disclosed herein should not be interpreted as limiting, but rather as a representative basis for the claims and / or as a representative basis for teaching a person skilled in the art different uses of the present invention.

[0021] In an increasingly mobile society, sending emergency alerts to a broad public can be challenging, especially to those members of the public who travel frequently. One reason for this challenge is that subscribers to such information generally only receive notifications within the areas defined in their subscription.

[0022] Another reason could be that notifications are based on static geographic data. This means that a notification might be sent to members of the public who are identified as being in specific geographic areas. For example, if a member of the public travels from point A to point B and an emergency transmission is sent to point B, they might not receive the transmission at point B because they were not identified as being in that geographic area. Therefore, an emergency notification and response system and a procedure that use geographic data associated with a vehicle and / or a vehicle occupant can be helpful as part of emergency notification transmissions.

[0023] Fig. Figure 1 shows an example block topology for a vehicle computing system (VCS) used in a vehicle-based emergency notification and response system. Fig. 2. This is a non-restrictive illustration of an emergency notification and response system. System 100 can function by notifying a vehicle occupant in the vehicle of federal, state, and local emergencies. The vehicle occupant(s) can also respond to such emergency notifications via System 100. Emergencies can include, but are not limited to, environmental emergencies (such as tornadoes, hurricanes, severe thunderstorms, and other environmental threats) and community emergencies (including, but not limited to, local, state, and federal emergencies such as child abductions and public safety / healthcare emergencies).

[0024] First, with reference to Fig. 1. A vehicle equipped with the VCS 1 can include a visual front-end interface 4 located within the vehicle. The user can also interact with the interface, for example, if it is equipped with a touch-sensitive screen. In another illustrative embodiment, interaction occurs through the pressing of buttons, audible speech, and speech synthesis. An example of such a VCS 1 is the SYNC system, manufactured and distributed by THE FORD MOTOR COMPANY.

[0025] In the illustrative embodiment 1, which is shown in Fig. As shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based computing system. The processor, which is provided in the vehicle, allows for the processing of instructions and routines within the vehicle. Furthermore, the processor is connected to both volatile memory 5 and non-volatile memory 7. In this illustrative embodiment, the volatile memory is RAM (Random Access Memory) and the non-volatile memory is a hard disk drive (HDD) or flash memory.

[0026] The processor is also equipped with a number of different inputs that allow the user to interact with it. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, and a BLUETOOTH input 15 are provided. An input selector is also provided to allow the user to choose between different inputs. Input signals to both the microphone and the auxiliary input are converted from analog to digital by a converter 27 before being passed on to the processor.

[0027] Output devices on the system can include, among others, an optical display 4 and a loudspeaker 13 or a stereo system output device. The loudspeaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. It can also be output via the bidirectional data streams shown at 19 and 21, respectively, to a remote BLUETOOTH device such as a PND 54 or a USB device such as a vehicle navigation device 60.

[0028] In one illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate with a user's portable device 53 (e.g., mobile phone, smartphone, PDA, or other device with wireless remote network connectivity). The portable device (nomadic device - ND) can then be used to communicate with a network 61 outside the vehicle 31 59, e.g., by communicating 55 with a cell tower 57. In some embodiments, the tower 57 may be a WiFi access point.

[0029] Example communication between the portable device and the BLUETOOTH transceiver is represented by signal 14.

[0030] Pairing a portable device 53 and the BLUETOOTH transceiver 15 can be commanded by a key 52 or similar input device. Accordingly, the CPU is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a portable device.

[0031] Using, for example, a data plan, data-over-voice, or two-tone multi-frequency (DTMF) communication in conjunction with the portable device 53, data can be communicated between the CPU 3 and the network 61. Alternatively, it may be desirable to include an onboard modem 63 with antenna 18 to communicate data between the CPU 3 and the network 61 via the voice band 16. The portable device 53 can then be used to communicate with a network 61 outside the vehicle 31 59, for example, by communicating 55 with a mobile phone mast 57. In some embodiments, the modem 63 can establish communication 20 with the mast 57 to communicate with the network 61. As a non-restrictive example, the modem 63 could be a USB mobile cellular modem, and the communication 20 could be mobile cellular communication.

[0032] In a simplified embodiment, the processor is equipped with an operating system and an application programming interface (API) for communication with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (e.g., such as that found in a portable device).

[0033] In another embodiment, the portable device 53 includes a modem for voice-band or broadband data transmission. In the data-over-voice embodiment, a technique called frequency-division multiplexing can be implemented when the owner of the portable device can speak over the device while data is being transmitted. At other times, when the owner is not using the device, the data transmission can utilize the entire bandwidth (300 Hz to 3.4 kHz in one example).

[0034] If the user has a data plan associated with the portable device, it is possible that the data plan allows broadband transmission and the system could use a much wider bandwidth (which speeds up data transmission). In yet another embodiment, the portable device 53 is replaced by a (not shown) cellular communication device installed in the vehicle 31. In yet another embodiment, the portable device 53 can be a wireless local area network (LAN) device that can communicate, for example, via an 802.11g network (i.e., WiFi) or a WiMAX network.

[0035] In one embodiment, incoming data can be routed through the portable device via Data-Over-Voice or a data plan, through the on-board Bluetooth transceiver, and into the vehicle's internal processor 3. For example, in the case of certain temporary data, the data can be stored on the HDD or other storage media 7 until it is no longer needed.

[0036] Additional sources that can interact with the vehicle include a personal navigation device 54, which may have, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60, which may have a USB connection 62 and / or other connection, an on-board GPS device 24 or a remote navigation system (not shown) with connectivity to the network 61.

[0037] Furthermore, the CPU could be in communication with various other auxiliary devices 65. These devices can be connected via a wireless connection 67 or a wired connection 69. Alternatively, or in addition, the CPU could be connected to a vehicle-mounted wireless router 73 using, for example, a WiFi transceiver 71. This would allow the CPU to connect to remote networks within range of the local router 73. Auxiliary devices 65 include, among others, personal media players, wireless healthcare devices, portable computers, and the like.

[0038] Now with reference to Fig. 2. As described above, the vehicle 31 can be equipped with the VCS 1 (e.g., a vehicle-mounted data processor), which can communicate and process data received from it within the vehicle. The VCS 1 can also have installed programmed software logic for mediating emergency notifications and responses received by the VCS 1. The on-board emergency notification and response broker 102a can be programmed onto the VCS 1 and / or installed as software from a computer-readable medium (including, but not limited to, CD-ROMs, DVDs, flash memory, one or more servers, and the like). The logic can be installed onto the VCS 1 by an OEM during vehicle manufacturing, a vehicle dealer, or a user (e.g., a vehicle occupant) after purchasing the vehicle. In some embodiments, the broker 2 can be installed from a software repository or database.

[0039] The broker 102a can be activated and operated while the vehicle is running (e.g., when the vehicle 31 is operating). However, the user can choose to disable emergency notifications. Alternatively or additionally, the broker 102a can be activated in response to manual user activation (e.g., via touch and / or voice activation commands). Once activated, the broker 102a can communicate with an Emergency Notification System (ENS) 104 via the VCS 1, from which it can receive emergency event notifications. The broker 102a can communicate with the Emergency Notification System 104 via wired or wireless communication. In one embodiment, communication can take place via network 112. Network 112 can be the communication network used by the ENS 104 to send emergency notifications, as is known in the field.As a non-restrictive example, network 112 can be a mobile communication carrier. It is understood that network 61 and network 112 could be the same or different networks; however, for clarity, the networks are illustrated as separate networks. In another embodiment, broker 102a can communicate directly with ENS 104 via a communication network that is already known in the prior art or yet to be disclosed.

[0040] In another embodiment, communication can additionally or alternatively include USB, FireWire, WiFi, WiMAX, cellular networks, radio frequency (RF), Bluetooth, and the like. In some further embodiments, the VCS 1 can include a programming interface (API) that allows communication between the Broker 102a and the ENS 104.

[0041] In one embodiment, the broker 102a can be implemented in the ND 53. The ND 53 can communicate with the VCS 1 as described above. In this case, the portable device can include an API to allow communication between the portable device and the VCS 1. This API, or an additional API implemented in the VCS 1, can allow communication with the ENS 104. The broker 102a can be incorporated into the portable device using similar methods described above.

[0042] Emergency notifications may include information related to an emergency, including, but not limited to, dates, times, descriptions of geographical attributes (e.g., location information), identification information, severity of the condition, and the like. Alternatively or additionally, emergency notifications may include images. These images may be of (without limitation) people, vehicle registration plates, vehicles, weather conditions, and other similar images. Thus, visual information may be provided in the emergency notification(s).

[0043] Broker 102a can receive emergency notifications from ENS 104 in many ways. As a non-restrictive example, Broker 102a can monitor information from ENS 104 for new emergency notifications. In some embodiments, when notifications are transmitted by ENS 104, they can be stored in a database or other (not shown) repository that Broker 102a monitors for new / updated emergency notifications. In this case, the notifications can be transmitted via ENS 104 or an intermediary entity (e.g., a mobile carrier in the case of Network 112).

[0044] In one embodiment, emergency notifications can be stored in memory. For example, modifications can be stored in memory locations 5, 7, or an external memory location (not shown). Broker 102a can be programmed to identify new / updated emergency notifications based on information from the emergency notifications stored in memory. This information includes, among other things, keywords, key phrases, graphics, images, and the like. Furthermore, a combination of this information can be used.

[0045] While Broker 102a monitors ENS 104 for new notifications, the Broker can use the information obtained from the stored notifications (or a combination of information) to determine which notification(s) from ENS 104 are new. This can be achieved by using logic programmed in Broker 102. This logic can be, without limitation, text recognition logic, speech recognition logic, and / or image recognition logic. Text / speech recognition logic can include the recognition of numeric characters, alphabetic characters / speech, alphanumeric characters / speech, and the like. Alternatively, the recognition information can be stored in a lookup table (not shown) on VCS 1, along with an identifier (e.g., and without limitation, a numeric, alphabetic, or alphanumeric identifier) ​​that identifies each notification.

[0046] To determine whether a new notification has been issued by the ENS 104, the broker 102a can compare the stored notification(s) with notifications from the ENS 104 using the information (or combination of information). In one embodiment, if a match exists, the broker 102a does not receive the notification(s). Alternatively, if there is no match, the broker 102a can receive and store the notification(s). In another embodiment, the notification can be received regardless of whether a match exists. In this case, the information from the stored notification(s) can be used to identify the new notification, so that the vehicle occupant is notified that a new notification has been received.

[0047] As an example, stored notifications can be associated with keyword information. For instance, if the notification concerns a child abduction (AMBER Alert), the abducted child's name can be used as a keyword. This keyword can then be linked to the notifications when they are stored in memory. If Broker 102a monitors the notifications received by ENS 104, the keyword can be used to determine whether the incoming notification has already been received or whether it is an update to the notification(s).

[0048] As another example, stored notifications can include an image (e.g., a picture of a missing person). If the Broker 102a monitors the notifications received by the ENS 104, image processing of the stored notification(s) can be performed to determine whether the incoming notification(s) has already been received or whether an update is available.

[0049] The ENS 104 can be monitored periodically by the Broker 102a. For example, monitoring can occur hourly, daily, weekly, bimonthly, or according to other recurring patterns. Furthermore, the stored notifications can be periodically presented to the user. The interval can be predefined and set by an OEM, a dealer, or the vehicle occupant.

[0050] Broker 102a can additionally or alternatively receive emergency notifications by submitting requests to ENS 104. These requests can be submitted periodically.

[0051] In one embodiment, Broker 102a can track which notifications are stored in memory and send one or more requests to ENS 104 to receive new and / or updated notifications. Broker 102a can track the stored notifications using information associated with them, as described above (keyword, key phrase, etc.). Additionally or alternatively, the stored notifications can be associated with time and date information. For example (and without limitation), each stored notification can contain a time and / or date stamp that can be associated with the notification(s) upon storage. Using the information associated with each stored notification, Broker 102a can request new or updated notifications.As a non-restrictive example, Broker 102a can use the date stamp to request notification(s) dated after the date of a filed notification. In one embodiment, Broker 102a can receive all notifications in response to a request, and the new and / or updated notifications can be filtered and identified by Broker 102a.

[0052] In one embodiment, the broker 102a can receive specific types of notifications from the ENS 104. For example, the broker 102a can receive only weather notifications. As another example, the broker 102a can receive only child abduction notifications within a specific geographic area. It is understood that the broker 102a can receive one or more types of notifications. The types of notifications that the broker 102a receives can be determined based on the subscription profile of the vehicle occupant. The subscription profiles are described below in relation to… Fig. 3 described. Alternatively or additionally, the received notifications can be predetermined. For example, the Broker 102a could be programmed to always receive certain types of notifications (e.g., child abduction notifications, disaster weather emergencies, etc.).

[0053] Some notifications may expire. Accordingly, stored notifications can be displayed until they expire. After the notification(s) expire, they can be deleted from storage. For example, weather emergency notifications might include a time and date for which the weather alert applies. Once this time / date has passed, the stored notifications can be deleted from storage.

[0054] It goes without saying that emergency notifications can be received and identified even without notifications stored on the VCS 1. However, in some configurations, the notification(s) can be filtered as described above (e.g., based on specific notification types identified in the subscription profile).

[0055] Notifications can be presented audibly or visually. For example, an emergency notification can be presented in spoken language through speaker 13. Text-to-speech technology (as is known in the field) can be used to output a notification audibly. Alternatively, speech-to-text technology (as is known in the field) can be used to output notifications visually. It is understood that audible notifications can also be presented as beeps, ringtones, and other acoustic sounds indicating the presence of one or more notifications. As another example, the emergency notification(s) can be displayed on display 4 (e.g., and without limitation, as pop-ups, scrolling text, graphics / images, etc.). The notifications can contain text, numbers, images, graphics, or a combination of these visual means. Furthermore, the following are described below with reference to Fig. Four further details of the submission process are described.

[0056] Emergency notifications can be assigned a priority that defines the output priority given to the notification(s). Accordingly, the notification(s) can be presented in such a way as to attract the attention of the vehicle occupant(s) and cannot be removed or deleted until the user acknowledges the notification(s). Acknowledgement includes, but is not limited to, putting the notification(s) away, deleting the notification(s), minimizing the notification(s), confirming (e.g., by touching an "OK" button on the touchscreen or speaking the word "OK"), and the like. It is understood that these examples serve for illustrative purposes and are therefore not intended to be limiting. Furthermore, the types of acknowledgements can vary without deviating from the scope of the invention.

[0057] As an example of output priority, a pop-up can be displayed and remain in focus on the screen until the user acknowledges it. As another non-restrictive example, the notification can be spoken repeatedly (and in some embodiments, frequently) through speaker 13 until the user acknowledges it. As yet another non-restrictive example, a beep or ringtone can be played repeatedly or periodically (e.g., every minute), indicating the presence of the notification(s). The beep or ringtone can continue to play until the user requests the notification(s) (via an audible and / or touch command). The notification(s) can be presented in an acknowledged manner.

[0058] The notification(s) can be presented to the user automatically and / or in response to manual input. Automatic presentation of the notification(s) is described above. In the case of manual notification, the vehicle occupant can navigate a menu on the VCS 1 to retrieve the notifications. Menu navigation can be performed via touch input and / or voice input. For example, the vehicle occupant could use a touchscreen display to navigate the menu. Alternatively or additionally, the vehicle occupant could use voice commands.

[0059] In some configurations, the vehicle occupant could also use manual input to search the notifications stored on the VCS 1. Notifications can be stored on the VCS 1 until they are deleted, for example, by manual deletion and / or expiration of the notification.

[0060] Emergency notifications can be received by vehicle 31 whether or not vehicle 31 is started (i.e., running). For example, even when the vehicle is switched off (and therefore not running), VCS 1 can still receive enough power from the vehicle battery to receive the notifications. In either case, the received notification(s) can be queued in memory. When the vehicle is running and / or the notification service is enabled, the notification(s) can be delivered from the queue and presented to the user. The notification message(s) can be queued according to procedures known in the field.

[0061] Now with reference to Fig. 2. The ENS 104 can be a government, municipality, or other public institution that issues emergency notifications. In some embodiments, the ENS 104 can consist of terminal devices, servers, networks, and databases for exchanging data with and from the VCS 1. The specific configuration of the ENS 104 can be arranged according to various implementations without deviating from the scope of the invention.

[0062] As described above, emergency notifications can be presented on display 4 and / or through speaker 13. Further details of the presentation process are given below in relation to Fig. 4 described.

[0063] The broker 102a can use GPS data received from a satellite 108. As described below, the GPS data can be used to tailor emergency notifications to the geographic area of ​​the vehicle 31. This geographic area can be the default location of the vehicle occupant or "home" location (as defined by the user), one or more areas along a route, or both. The geographic area can include varying degrees of specificity, such as street, postal code, city, county, state, and country.

[0064] A vehicle occupant can contact a Public Safety Access Point (PSAP) 110 from vehicle 31 in response to receiving an emergency notification. The occupant can do this using conventional methods (e.g., manually placing a call from ND 53). Alternatively, the occupant can do so via a command instructing them to connect to PSAP 110. Commands can be audible or tactile. For example, the command might be to place a call to PSAP 110 or to send a text message (e.g., an email, text message, or instant message (IM)). In one embodiment, the emergency notification(s) may include a link, button, or other input device for contacting PSAP 110.For example, a notification displayed on screen 4 may contain an input method that, when selected, initiates a call to the PSAP 110. Alternatively, the input method may be one that sends a text message to the PSAP 110. In the case of text messages, the broker 102a can be programmed to generate a message using the messaging tools of the VCS or the ND. Alternatively, the broker 102a can generate one or more messages, for example, by using messaging tools located on a remote server (not shown) via network 61. The PSAP 110 can respond to the message by making a call and / or sending back one or more text messages.

[0065] The PSAP 110 can be any entity responsible for responding to emergency calls, such as, but not limited to, the fire department, police stations, or any other entity connected to an emergency call system. Further details regarding communication with the PSAP 110 are described below.

[0066] In the embodiments described above, Broker 102a is an onboard Broker 102a. In an alternative embodiment, the emergency notification relay system can be an off-vehicle Broker 102b. An off-vehicle Broker can be a media broadcasting service (e.g., radio and / or television) or an emergency notification service provider (e.g., an OEM). In one embodiment, the off-vehicle Broker 102b can perform all the tasks and functions described above (and in more detail below) for emergency notification and response. In this case, one or more application programs for releasing various functions related to emergency notification and response can be programmed into the VCS 1 and / or the ND 53.In other embodiments, there can be both a broker located inside the vehicle and one located outside the vehicle, so that, for example, a broker 102a works together with a broker 102b.

[0067] An OEM may require the collection of usage information for System 100. Accordingly, a usage database 114 can collect usage information from the onboard broker 102a or the off-vehicle broker 102b. This usage information can be used to collect data on calls / messages to the PSAP 110, the number and / or types of notifications issued during a time period and / or in one or more geographic areas, and similar data. The usage information can be collected by the database 114 based on a marker, message, or other usage identifier transmitted to the database 114 in response to a usage event (e.g., a call placed to the PSAP 110).

[0068] Fig. Figure 3 illustrates a user registration process to enable the use of VCS 1. As an example, the registration process can enable services to be activated within the vehicle or loaded on the vehicle. These services can be loaded during registration or later. The Fig. The registration process shown in Figure 3 can take place after the vehicle has been purchased. It is understood that the registration process can take place locally at the VCS 1 or remotely, for example, on a personal computer (PC) or a portable device. In one embodiment, the registration process can take place via an internet connection.

[0069] It is understood that the revelation and arrangement of Fig. 3. They can be modified or rearranged to best conform to a particular implementation of the various embodiments of the invention. Furthermore, it is understood that the profile information and the configuration information can be provided and / or modified during or after initial registration.

[0070] A vehicle occupant can enter user profile information (block 200) and vehicle profile information (block 202) so that Broker 102 can identify the user and the vehicle, respectively. User profile information includes details to identify the vehicle occupant(s). For example, user profile information might include a mobile identification number (MIN) linked to the vehicle occupant's portable device. Other information includes, but is not limited to, the user's name and address.

[0071] Vehicle profile information may include information about the vehicle. This information includes a vehicle identifier, such as a Vehicle Identification Number (VIN), associated with the vehicle. In addition to identifying the vehicle, this VIN may also be used to register for or subscribe to vehicle-based services. Therefore, vehicle profile information may also include vehicle-based services enabled in the vehicle. These services may be transmitted to the vehicle (using well-known methods) via a wired or wireless connection between the VCS and the device used to generate the profile. Non-restrictive examples of such wired or wireless connections are given above.

[0072] The vehicle-based services can additionally or alternatively be connected to the ND 53 using the MIN. In this case, the vehicle-based services can be operated via the ND 53 (e.g., through a mobile application). Alternatively, the vehicle-based services can be connected to the vehicle 31 and the ND 53 using the VIN or MIN. For example, and without limitation, the MIN can be used to identify the user of the service(s), and the VIN can be used to identify which service(s) are authorized. This can, for example, provide a multi-factor authentication process.

[0073] The emergency notification service can be a standard service (or automatic selection service) offered to the vehicle occupant. Accordingly, the vehicle occupant can choose to deselect the emergency notification service (Block 204). However, it is understood that the user can decide whether to select or deselect the emergency notification service without this deviating from the scope of the invention.

[0074] As illustrated in Block 206, it is possible that emergency notifications will not be received if the user has opted out. In some embodiments, the user may still receive emergency notifications, such as mandatory notifications or notifications concerning a critical emergency, even if they have opted out. Broker 102 can be programmed to identify these notifications based on information associated with them.

[0075] If the user does not opt ​​out of notifications, they can configure the emergency notification service as shown in blocks 208, 210, and 212. As illustrated in block 208, preference notifications can be configured. For example, a default or "home" notification location can be defined. The "home" notification location can be the geographic location(s) for which the vehicle occupant(s) regularly receive emergency notifications. The location(s) can be determined automatically (e.g., based on user profile information and / or GPS information) or entered by the user. This location can be based on where the user lives, works, or it can be another location entered by the user.

[0076] A radius (or distance) defining the area where emergency notifications are received by a vehicle occupant can also be specified. For example, emergency notifications can be presented for emergencies occurring within a distance of "X" (e.g., measured in miles, kilometers, meters, etc.) from the "home" location. Alternatively, emergencies can be presented for emergencies occurring within a distance of "X" from the vehicle's location (e.g., if it is not at its "home" location or if there is no "home" location).

[0077] In some embodiments, it will be understandable that the geographical parameters can be predefined. Other geographical parameters and the process of dispatching emergency alerts will be discussed in more detail in relation to… Fig. 5 described.

[0078] As part of the notification targeting process, Broker 102a,b can determine the geographic coverage area of ​​the notification based on information contained within the notification. This can be referred to as a geographic attribute associated with the emergency notifications. Emergency notifications contain an area or areas (e.g., county or state) that may be affected by the emergency notifications. Broker 102a,b can intercept (e.g., from a data transmission) or interpret (e.g., from the notifications) this information to determine the affected areas. In one embodiment, a lookup table or a map database can be used in the determination.

[0079] As shown in Block 210, the vehicle occupant's communication preferences can be entered and saved for communication with the PSAP 110. As described above, a phone call can be made or text messages can be sent. The communication preference set by the user can be the default communication method. However, the user can also override the default and select the communication mode from the VCS 1, for example, before or during the communication event.

[0080] Presentation preferences can also be configured (Block 212). These preferences can include those relating to acoustic presentation (and the types of acoustic presentations) or visual presentation (and the types of visual presentations). In some embodiments, the default presentation mode can be acoustic. As illustrated in Block 214, profile information and configuration information can be transmitted and / or stored in and / or outside the vehicle.

[0081] Fig. Figure 4 illustrates the process for emergency notification and response. It is understood that the disclosure and arrangement of Fig. 4 can be modified or rearranged to best conform to a particular implementation of the various embodiments of the invention.

[0082] Emergency notifications from ENS 104 can be monitored and / or request messages can be sent to ENS 104 for the emergency notification(s) (Block 300). If there are no messages (Block 302), monitoring can continue and / or request messages can continue to be sent. If there are messages, the emergency notification(s) can be received and / or identified by Broker 102a, b (Block 304), as described above.

[0083] As described above, the notification(s) may contain images. Accordingly, Broker 102a, b can determine whether the notification(s) contain images (Block 306). If not, Broker 102a, b can process the image excluding the notification(s) for presentation purposes (Block 308). If the notification(s) contain images, the image including the notification(s) can be processed (Block 310) to present the image(s) to the vehicle occupant(s). The images may be embedded in the notification messages or retrieved from a remote location (e.g., by following a path of an electronic address on the notification message).

[0084] The notification(s) can be presented to the vehicle occupant(s) as illustrated in Block 312. As described above, the presentation / transmission can be visual and / or audible. Further details of the notification transmission are given in more detail in Fig. 5 described.

[0085] The user can contact a PSAP 110 in response to receiving a notification (Block 314). In some embodiments, if no contact is made with the PSAP 110, the notification(s) can be stored on the VCS 1 (Block 316). Alternatively, the notification(s) can be deleted if no contact is made with the PSAP 110.

[0086] When contact is established with the PSAP 110, the connection can be established as described above (Block 318). In some configurations, the notification(s) can be stored. Furthermore, as described above, usage information can be sent to and stored in a usage database 114 in response to contacting the PSAP 110.

[0087] Vehicle-related information can be transmitted to the PSAP 110 for identification and location tracking purposes (Block 320). Transmitting the location can be advantageous, for example, if the vehicle occupant has located a kidnapped child and / or a person suspected of kidnapping. In some configurations, the message can also identify the emergency notification to which the vehicle occupant is responding.

[0088] Once a connection is established, the vehicle occupant(s) can then communicate with the PSAP 110 personnel (Block 322). The different communication modes are described above.

[0089] In one embodiment, the PSAP 110 can receive a match between an image in the notification(s) and an image captured by the vehicle's camera. The match can be determined in the vehicle using image processing logic. For example, the vehicle's camera can capture a license plate image, which can then be compared to the image in the notification(s). If they match, the user can be notified, and the match can be transmitted to the PSAP 110 automatically or manually. Image capture by the camera can be triggered by the vehicle occupant via a touch or acoustic command.

[0090] Fig. Figure 5 illustrates a process for presenting emergency notification messages. It is understood that the disclosure and arrangement of Fig. 5 can be modified or rearranged to best conform to a particular implementation of the various embodiments of the invention.

[0091] The profile information and emergency notification configuration information can be received inside or outside the vehicle (Block 400). The notification configuration can be checked (Block 402). In some embodiments, the configuration information can also be stored on the VCS 1.

[0092] A determination can be made, either inside or outside the vehicle, as to whether the vehicle is at the "home" location of the vehicle occupant (Block 404). Alternatively or additionally, the broker 102a, b can receive the vehicle's location (Block 406). In either case, the broker 102a, b can determine whether the vehicle is within the specified geographic parameters for sending emergency notifications (Block 408). Some non-restrictive examples are given above. The geographic parameters can also be based on the vehicle's location within a specific city, county, state, or territory. It is understood that if the broker is outside the vehicle, the determination can be made by application software inside the vehicle (as described above).

[0093] Additionally or alternatively, the geographical parameters may include the vehicle's proximity to the emergency, as defined by a geographical attribute specified in the emergency notifications. For example, the decision to present the emergency notification(s) to the vehicle occupant may be based on the vehicle's proximity to the last known location of the suspect or abducted child, as defined in (or with) the emergency notification(s).

[0094] As another example, the decision could be based on proximity to a tornado. It is understood that the vehicle's location can be determined using GPS data and / or other location-finding methods known in the field. Furthermore, it is understood that the various geographical parameters (e.g., distance and proximity parameters) can be used in combination.

[0095] As described above, Broker 102a, b can determine the coverage area of ​​the notifications. Using this information, Broker 102a, b can determine whether the vehicle's geographic location parameters fall within the coverage area of ​​the notification(s). For example, and without limitation, Broker 102a, b can determine whether the notification area and the geographic location parameters match.

[0096] If the vehicle is not within the geographical location, a further determination can be made as to whether the vehicle is moving in the direction of the geographical location (Block 410). If not, the notification(s) cannot be presented (Block 412). However, in some embodiments, the notification(s) can be stored in an on-board memory or in an off-vehicle memory.

[0097] If the vehicle is traveling towards the geographical location, a further determination can be made as to whether the geographical location has been reached (Block 416). For example, reaching the geographical location may include driving within the specified radius, crossing the state border, driving within the specified proximity distance, and the like. In some embodiments, the notification message(s) may be held in a message queue until the geographical location is reached (Block 414).

[0098] If the geographical location is not reached, Broker 102 can continue to monitor whether the vehicle is moving in that direction (Block 410). If a message queue exists, the notification(s) can be held in the queue. If the vehicle reaches the geographical location, the notification(s) can be presented to the vehicle occupant (Block 418). The notification(s) can be presented until acknowledged by the vehicle occupant.

[0099] In one embodiment, as the vehicle travels toward the geographical location, varying levels of detail regarding the emergency can be presented to the vehicle occupant. For example, if the vehicle is a distance "Y" from the geographical location, the occupant may be presented with a message (audible and / or visual) stating: "You are approaching an emergency notification area." As the vehicle approaches the geographical location, additional details may be presented to the occupant. Naturally, a full emergency notification with all details can be presented upon reaching the geographical location.

[0100] Additionally or alternatively, the priority of the emergency notification can increase as the vehicle approaches the geographical location. For example, while the vehicle is approaching the location, the message can be displayed for a specific period (e.g., a few seconds) and then removed from the display without acknowledgment. However, once the vehicle reaches the location, the message can remain locked on the display until acknowledged by a vehicle occupant. Alternatively, the message can be presented less frequently (audibly or visually) until the location is reached. Once the location is reached, the notification can be presented repeatedly (and frequently in some implementations), and acknowledgment may be required.

[0101] Now, with reference back to Block 408, if the vehicle is within the geographical location, a further determination can be made as to whether the vehicle is moving away from that location (Block 420). If so, the notification(s) can be presented to the vehicle occupant(s) until the vehicle is outside the geographical location (Block 422). If the vehicle is not moving away from the geographical location, the notification(s) can be presented to the vehicle occupant(s), as illustrated in Block 418. In both cases, the vehicle occupant can acknowledge the notification(s).

[0102] In some embodiments, the process can consist of Fig.5. This can also be used for existing stored notifications. For example, notifications can be stored in or outside the vehicle and presented to the user periodically (e.g., daily without restriction) until the notification(s) expire and / or an update is received from the ENS 104 regarding a change in the emergency status (e.g., the emergency has been resolved).

[0103] While exemplary embodiments are illustrated and described above, these embodiments are not intended to illustrate and describe all possibilities. Instead, the words used in the description are descriptive and not limiting, and it is understood that various modifications can be made without deviating from the inventive concept and scope.

Claims

[1] Computer-implemented method for communicating emergency information to a vehicle, comprising: Receiving at least one emergency notification with a geographic attribute on a vehicle computer, wherein the at least one emergency notification includes location information related to an emergency; Receiving GPS data on the vehicle computer; Determining the geographical location of the vehicle based on GPS data on the vehicle computer; Select at least one emergency notification based on the vehicle's geographic location and the geographic attribute on the vehicle computer and Output of at least one selected emergency notification, so that a notification is presented to a vehicle occupant, characterized by , that the procedure continues to include: Determine, if the vehicle is not within the geographical location of the emergency, whether a direction of movement of the vehicle leads towards the geographical location of the emergency, holding the at least one emergency notification in a message queue of the vehicle computer if the direction of movement of the vehicle leads towards the geographical location of the emergency, and present the at least one emergency notification in the queue when the vehicle has reached the geographical location of the emergency. Determine, if the vehicle is within the geographical location of the emergency, whether the vehicle's direction of movement is away from the geographical location of the emergency, and issue at least one selected emergency notification until the vehicle is outside the geographical location. [2] Computer-implemented method according to claim 1, wherein the emergency notification is an emergency notification issued by the government or an authority. [3] Computer-implemented method according to claim 1 or 2, further comprising: determining the proximity of the vehicle to the geographical attribute and outputting the selected emergency notification based on the proximity. [4] Computer-implemented method according to one of the preceding claims, further comprising: receiving a distance parameter on the vehicle computer which defines a distance from the geographical location of the vehicle for the purpose of issuing the emergency notification and issuing the emergency notification based on the distance parameter. [5] Computer-implemented method according to claim 4, wherein the distance is defined as a radius. [6] Computer-implemented method according to claim 4 or 5, wherein the distance parameter is defined by a user. [7] Computer-implemented method according to one of the preceding claims, further comprising listening for emergency notifications on the vehicle computer. [8] Computer-implemented method according to any of the preceding claims, further comprising transmitting a request for at least one emergency notification. [9] Computer-implemented method according to any of the preceding claims, wherein the at least one selected emergency notification is an updated notification. [10] Non-volatile computer-readable storage medium containing instructions which, when executed by a processor of a vehicle computer, cause the processor to execute a method according to any one of claims 1-9.

Images