METHOD AND DEVICE FOR VEHICLE-TO-VEHICLE COMMUNICATION AND INFORMATION TRANSFER

Abstract

System (1), comprising: a processor (3) designed to: to detect an emergency condition of a primary vehicle (301); to determine that communication with emergency services is not possible through an onboard device (303); to search for a secondary vehicle with vehicle-to-vehicle communication capabilities (201); to send an emergency communication request to the secondary vehicle (209) in order to establish a communication link with the secondary vehicle (211); to send prioritized emergency data to the secondary vehicle (213); and the processor (3) is designed to receive confirmation from the secondary vehicle that an emergency request has been sent (215) to request assistance for the primary vehicle, characterized by the fact that the processor (3) is designed to send instructions to terminate emergency requests from additional secondary vehicles as soon as acknowledgment is received (221).

Description

[0001] The illustrative embodiments generally relate to a method and a device for vehicle-to-vehicle communication and vehicle-to-vehicle information forwarding.

[0002] Vehicle telematics systems offer the possibility of communication between a vehicle and remote entities. In many cases, this can be used to obtain traffic and navigation data, as well as other information such as media, that is of interest to the driver. Telematics systems also provide the ability to contact emergency services if a vehicle is involved in an accident. In some cases, the vehicle can use an embedded modem, and in others, it can use a driver's mobile device to contact an external source.

[0003] While using an in-vehicle communication provider is convenient, problems can arise if the device is damaged or disabled in an accident. If the vehicle relies on its own system to contact emergency services, and the device is damaged, the occupants may be unable to contact emergency services automatically. Since the occupants may also be injured, it can be difficult for them to get help.

[0004] US Patent 8,396,449 B2 generally relates to an emergency system comprising a restraint control module (RCM), a global positioning system module (GPSM), at least one output, at least one input, a single-pole double-dial (SPDJB), and a vehicle-associated computing system (VACS) communicating with the RCM, the GPSM, the at least one output, the at least one input, and the SPDJB. Upon detecting an emergency event, the RCM requests that the VACS make a distress call. Upon receiving a request from the RCM, the VACS queries the GPSM to obtain vehicle coordinates, informs the occupants of the commencement of the call, and instructs a wireless device communicating with the VACS to make a distress call. The VACS can be operated to determine when a distress call is connected.Once the emergency call is connected, the VACS forwards a message to the RCM to indicate the connection and contacts the smart power distribution junction box (SPDJB).

[0005] US Patent 8,014,752 B2 generally relates to the automatic use of a cellular telephone device, achieved by a control unit and a vehicle-mounted wireless short-range communicator, wherein the wireless short-range communicator has peer-to-peer communication capability; in response to an emergency notification message, pinging a long-range communication device that is simultaneously within the peer-to-peer communication capability range by the wireless short-range communicator, wherein the long-range communication device is physically separate from the vehicle; following the ping, receiving a reply message indicating that user authorization is required; in response to the reply message, sending a request for an authorization message by the wireless short-range communicator to the long-range communication device;Following a positive response from a user to the authorization request, receiving an authorization message to add the long-range communication device; and in response to the authorization, sending an emergency notification message from the short-range wireless communicator through the added long-range communication device to a specified recipient party.

[0006] DE 10 2008 023 281 A1 discloses an emergency call device for a vehicle for transmitting an emergency call to a recipient selected from a stored set, who can then provide immediate assistance. US 8 014 752 B2 discloses a system installed in a vehicle for the automatic detection of a vehicle accident or a vehicle malfunction based on sensors installed in the vehicle, wherein the system uses a short-range communication means to determine whether suitable communication devices with long-range communication capabilities are within range of the short-range communication signal. DE 11 2008 003 932 B4 discloses a method for transmitting event information about a traffic accident, a traffic delay, or a traffic hazard. DE 103 03 755 A1 discloses a method for disseminating information between vehicles connected to each other via Bluetooth devices.German patent DE 199 17 207 A1 discloses an emergency call device that, based on a critical driving situation detected by sensors, sends an initial message containing at least the vehicle's geographical position, even before an actual accident has occurred. US patent 2004 / 0 075 553 A1 discloses an anti-theft device installed in a vehicle for transmitting data to and from another vehicle.

[0007] According to the invention, a system according to claim 1 is provided. Advantageous embodiments of the invention are specified in the dependent claims.

[0008] In a first illustrative embodiment, a system includes a processor designed to detect an emergency condition in a primary vehicle. The processor is also designed to determine that communication with emergency services via an onboard device is not possible. Furthermore, the processor is designed to search for a secondary vehicle with vehicle-to-vehicle communication capabilities. The processor is additionally designed to send an emergency service request to the secondary vehicle in order to establish a communication link with the secondary vehicle and transmit prioritized emergency data to the secondary vehicle.

[0009] In a second illustrative embodiment, a system includes an in-vehicle processor designed to receive an emergency service request from a primary vehicle in an emergency situation. The processor is also designed to establish vehicle-to-vehicle communication with the primary vehicle. Furthermore, the processor is designed to receive emergency data from the primary vehicle and to send a communication requesting emergency services on behalf of the primary vehicle.

[0010] In a third illustrative embodiment, a system includes a processor designed to receive an emergency communication from a secondary vehicle, sent on behalf of a primary vehicle. The processor is also designed to compare an emergency communication identifier with all previously received emergency communication identifiers to determine whether the emergency communication is a duplicate. Furthermore, the processor is designed to send a request to an emergency service provider based on a non-duplicate emergency communication containing emergency data received as part of the communication that is not a duplicate of previously transmitted emergency data. Fig. shows an illustrative vehicle computer system; Fig. shows an illustrative process for vehicle-to-vehicle communication; Fig. shows an illustrative example of the process for making an emergency call; Fig. shows an illustrative example of a process for emergency call communication; Fig. shows another illustrative process for emergency call communication; Fig. shows an illustrative process for handling emergency calls; and Fig. shows an illustrative process for vehicle-to-vehicle connection.

[0011] As required, detailed embodiments of the present invention are disclosed here; however, it should be understood that the disclosed embodiments are merely exemplary of the invention, which can be implemented in various and alternative forms. The illustrations are not necessarily to scale; some features may be exaggerated or reduced in size to show details of certain components. Therefore, specific structural and functional details disclosed here are not to be understood as limiting, but merely as a representative basis to provide guidance to those skilled in the art in this field for the diverse applications of the present invention.

[0012] Fig. Figure 1 shows an exemplary block topology for a vehicle-based computing system (VCS) 1 for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computing system may have a visual front-end interface 4 located in the vehicle. The user may also interact with the interface when provided, for example, by means of a touch-sensitive screen. In another illustrative embodiment, interaction occurs through keystrokes, spoken language, and speech synthesis.

[0013] In the illustrative embodiment shown in Fig. As shown, a processor 3 controls at least part of the operation of the vehicle's onboard computer system. By being located within the vehicle, the processor enables the onboard processing of instructions and routines. Furthermore, the processor is connected to both non-persistent memory 5 and persistent memory 7. In this illustrative embodiment, the non-persistent memory is random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory.

[0014] The processor is also equipped with a number of different inputs that allow the user to communicate with the processor. In this illustrative embodiment, a microphone 29, an auxiliary device input 25 (for input 33), a Universal Serial Bus input 23, a Global Positioning System input 24, and a Bluetooth input 15 are provided. An input selector switch 51 is also provided to allow the user to switch between different inputs. Inputs via the microphone and the auxiliary device input are converted from analog to digital by a converter 27 before being passed on to the processor.Although not shown here, numerous vehicle components and accessories that communicate with the VCS can use a vehicle network (for example, but not limited to a "Controller Area Network" bus (CAN bus)) to forward data to and from the VCS (or components thereof).

[0015] Outputs to the system can include, but are not limited to, a visual display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. The output can be made to a remote BLUETOOTH device such as a personal navigation device 54 (PND) or a USB device such as a vehicle navigation device 60 along the bidirectional data streams shown at 19 and 21, respectively.

[0016] In an illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate with a user's 53 nomadic device (e.g., mobile phone, smartphone, personal digital assistant (PDA), or any other device with wireless remote network connectivity) 17. The nomadic device can then be used to communicate with a network 61 outside the vehicle 31 59, for example, by communicating 55 with a cell tower 57. In some embodiments, the tower 57 can be a Wi-Fi access point.

[0017] An example of communication between the location-independent device and the BLUETOOTH transmitter / receiver is represented by signal 14.

[0018] Pairing a portable device 53 and the BLUETOOTH transceiver 15 can be initiated via a key 52 or similar input. Accordingly, the central processing unit (CPU) is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a portable device.

[0019] Data can be transmitted between CPU 3 and network 61, for example, using a data plan, data via voice, or DTMF (Dual-Tone Multi-Frequency) tones, as associated with the idled device 53. Alternatively, it may be desirable to include an onboard modem 63, which has an antenna 18, to transmit data between CPU 3 and network 61 over the voice band 16. The idled 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 a communication link 20 with the mast 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem, and the communication link 20 can be a cellular communication link.

[0020] In an illustrative embodiment, the processor is equipped with an operating system that includes an API for communication with modem application software. The modem application software can access an embedded module or firmware in the Bluetooth transceiver to establish a wireless communication link with a remote Bluetooth transceiver (such as one found in a static device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocols. IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and exhibit significant cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle.Other communication methods that can be used in this area include optical free-space communication (such as Infrared Data Association (IrDA)) and non-standardized infrared (IR) remote control protocols.

[0021] In another embodiment, the portable device 53 includes a modem for voice-band or broadband data communication. In the data-over-speech embodiment, a method called frequency division multiplexing can be implemented when the owner of the portable device can speak through the device while data is being transmitted simultaneously. At other times, when the owner is not using the device, the data transmission can occupy the entire bandwidth (300 Hz to 3.4 kHz in one example).While frequency division multiplexing may be common and still used for analog mobile communication between vehicles and the internet, it has been largely replaced by hybrid methods for digital mobile communication, including code-domain multiple access (CDMA), time-domain multiple access (TDMA), and space-domain multiple access (SDMA). These are all ITU IMT-2000 (3G) compliant standards, offering data rates of up to 2 Mbps for stationary or walking users and 385 kbps for users in a moving vehicle. 3G standards are now increasingly being replaced by IMT-Advanced (4G), which offers 100 Mbps for users in vehicles and 1 Gbps for stationary users.If the user has a data plan for the nomadic device, the data plan can allow broadband transmission, and the system could utilize a significantly greater bandwidth (and thus accelerate data transmission). In yet another embodiment, the nomadic device 53 is replaced by a (not shown) cellular communication device installed in the vehicle 31. In yet another embodiment, the ND 53 (nomadic device) can be a wireless device of a local area network (LAN) that can communicate, for example (and without limitation), via an 802.11g network (i.e., Wi-Fi) or a WiMAX network.

[0022] In one embodiment, incoming data can be forwarded by the location-independent device via data-over-voice or data plan through the onboard BLUETOOTH transceiver and into the vehicle's internal processor 3. In the case of certain temporary data, for example, the data can be stored on the HDD or another storage medium 7 until the data in question is no longer needed.

[0023] Additional sources that can communicate with the vehicle include a personal navigation device 54, for example, with a USB port 56 and / or an antenna 58, a vehicle navigation device 60 with a USB port 62 or other port, an onboard GPS device 24, or a remote navigation system (not shown) connected to the network 61. USB is one of a class of serial network protocols. IEEE 1394 (FireWire), the EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the framework of serial standards for device-to-device communication. Most of the protocols can be implemented for both electrical and optical communication.

[0024] Furthermore, the CPU could communicate with a variety of other peripheral devices 65. These devices could be connected via a wireless 67 or a wired 69 connection. Peripheral devices 65 could be, but are not limited to, personal media playback devices, wireless medical devices, portable computers, and the like.

[0025] Alternatively, or in some other way, the CPU could be connected to an in-vehicle wireless router 73, for example by means of a Wi-Fi transceiver 71. This could allow the CPU to connect to remote networks within range of the local router 73.

[0026] In addition to the execution of exemplary processes by an in-vehicle computer system within a vehicle, in certain embodiments the exemplary processes can also be executed by a computer system that communicates with an in-vehicle computer system. Such a system can be, but is not limited to, a wireless device (e.g., but not limited to, a mobile phone) or a remote computer system (e.g., but not limited to, a server) connected via the wireless device. Collectively, such systems can be referred to as Vehicle Associated Computer Systems (VACS). In certain embodiments, specific components of the VACS can execute specific parts of a process, depending on the specific implementation of the system.For example, if a process includes a step of sending or receiving information to or from a coupled wireless device, it is likely that the wireless device will not perform the process, since it is unlikely that the wireless device would "send and receive" information in communication with itself. An average person skilled in this field of engineering will understand when it is inappropriate to use a particular VACS in a given solution. All solutions assume that at least the vehicle's in-vehicle computer system (VCS), located within the vehicle itself, is capable of performing the exemplary processes.

[0027] In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of a process executable by a computer system is shown. With respect to each process, the computer system executing the process may be designed, for the limited purpose of executing the process, as a special-purpose processor. None of the processes need be executed in their entirety and are understood as examples of process types that may be executed to achieve elements of the invention. Additional steps may be added to or removed from the exemplary processes as desired.

[0028] Typical telematics systems use some form of onboard communication to contact remote entities when data transmission is required. Whether this is done via an onboard modem or a driver's personal communication device, data conventionally flows to and from the vehicle in a closed system. However, if the communication device is damaged, this can lead to problems connecting to necessary remote services in the event of an accident.

[0029] The illustrative embodiments consider vehicle-to-vehicle communication, whereby, for example, in an emergency situation, a driver can use the resources available in another vehicle to contact an emergency service provider.

[0030] In the illustrative examples, vehicle telematics systems are capable of short-range communication with other vehicle telematics systems, for example, using Wi-Fi or Bluetooth. Other forms of local communication can also be used to contact localized vehicles. Once a connection to another vehicle (assuming functioning communication with remote entities), the damaged vehicle can use this communication to request emergency assistance.

[0031] The same model of local communication can be used to relay information from vehicle to vehicle, such as traffic, weather, or other useful information concerning conditions recently observed by either vehicle. For example, cars traveling in opposite directions on a road can relay information about traffic conditions previously experienced and / or received from other vehicles on the same road. While traffic flow may differ in different directions on the same road (i.e., traffic reports on one side of the road traveling south may not be as useful to a northbound vehicle), information received from other northbound vehicles further north on the road can be relayed to vehicles traveling further south.Essentially, a southbound vehicle can be used as an intermediary to relay information from vehicles at various points on a northbound side, thus informing vehicles further south about what to expect when traveling north.

[0032] Fig. This figure illustrates a process for vehicle-to-vehicle communication. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, to a suitable extent, firmware operating in accordance with a pre-configured processor can cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a meaningful variation thereof.

[0033] In this illustrative embodiment, a primary vehicle (designated as such for illustrative purposes only) wishes to connect with a secondary vehicle. This connection could be used to exchange information or to utilize the secondary vehicle's communication services in an emergency if onboard communication with emergency services fails. Of course, it is also possible that the vehicle will not attempt to locate other vehicles with which to communicate unless an emergency occurs and onboard communication is unavailable. Such a procedure is described with reference to Fig. discussed in more detail.

[0034] In the Fig. In the illustrated embodiments, vehicles exchange various types of information with other vehicles similarly equipped with telematics to establish an ad-hoc network for shared data use. Since the vehicle constantly (or at least periodically) attempts to communicate with other vehicles, it will likely know which vehicles are available for remote communication in the event of a vehicle emergency.

[0035] In this illustrative example, the vehicle sends a communication request to other local vehicles 201. Specifically, the vehicle searches for other vehicles with which it can communicate via short-range communication, such as low-energy Bluetooth. If other vehicles are detected, the process will receive a list of those detected vehicles 203 and can decide which, if any, should be used for ad-hoc communication.

[0036] As long as more than zero vehicles are detected, the process can continue. Otherwise, the process can choose to continue querying for locally connectable vehicles until a suitable vehicle is detected.

[0037] In this example, it is possible that the request was sent as a result of an emergency condition, where the onboard long-range communication is disabled or unavailable for other reasons. If an emergency condition exists (207), the process will send an emergency communication request to other local vehicles (209).

[0038] In some cases, a driver may disable vehicle-to-vehicle communication for general information exchange. However, in this case, consideration is given to ensuring that, in the event of an emergency, the rejection of communication by a secondary vehicle for safety reasons is bypassed. If the emergency communication request results in a connection to 211, the process can send an emergency service request from the primary vehicle to the secondary vehicle.

[0039] In many cases, the secondary vehicle can only be within range for a very short period. Consequently, it can be difficult to utilize the secondary vehicle's resources to maintain emergency communications. However, critical data (e.g., without limitation, accident location, number of occupants, and any other brief relevant information) can be quickly transmitted to the secondary vehicle. The secondary vehicle can then, even if it has moved out of communication range, communicate with an emergency services provider or an intermediary to alert the relevant parties, even if the secondary vehicle is no longer in communication contact with the primary vehicle.Naturally, if the communication link with the primary vehicle is lost, the secondary vehicle will only be able to forward information that it has already received, which is why it may be advantageous to transmit the most important information (e.g., location of the accident) first.

[0040] When the secondary vehicle receives a suitable amount of information and sends a support request while still in communication with the primary vehicle, the primary vehicle receives an acknowledgment that a support request has been sent 215. At this point, assuming that no further information needs to be relayed by secondary vehicles, the primary vehicle sends a termination request to delete the remaining support requests 221.

[0041] If the secondary vehicle does not send an acknowledgment or a communication link cannot be established with a first secondary vehicle, the process can continue to search for further secondary vehicles 217. The process can be repeated for each further secondary vehicle 219 until no secondary vehicle remains or an acknowledgment of a request for assistance is received and / or no more data is to be transmitted.

[0042] As long as communication with at least one secondary vehicle is maintained, additional information can be sent for forwarding to an emergency service provider. Even if communication is interrupted because a first secondary vehicle moves out of range, the process can continue searching for further secondary vehicles until all relevant information has been forwarded and / or confirmed.

[0043] If the request for secondary vehicles was not triggered by an emergency and / or does not involve emergency communication, the process can send a general connection request. Unlike the emergency service request, this request, in this example, can be ignored by vehicles equipped with telematics units whose occupants do not wish to communicate with other vehicles. In other models, communication between appropriately equipped vehicles can simply be enabled at all times.

[0044] If the communication request is accepted by the secondary vehicle, 225 any relevant data can be exchanged in the process. 227 This includes, but is not limited to, weather data, traffic data, game data (for ad-hoc games), and any other pertinent data. In at least one example, this could even include emergency data from another vehicle. For instance, if vehicle A is involved in an accident and contacts vehicle B, the emergency data can be transmitted to vehicle B. However, if vehicle B does not have a long-range communication link (e.g., if the driver's phone is dead), vehicle B can relay the information until it communicates with vehicle C. Vehicle C, receiving the information and possessing the appropriate telematics services, can then transmit the emergency to a service provider.Such a paradigm can be very useful in accidents in remote areas where few vehicles can pass by.

[0045] Once any data exchange is complete, or during the data exchange, the process can continue to attempt to communicate with other vehicles and do so. In this way, useful information can be relayed between vehicles as they travel on roads. It could even relay road condition information, which could help identify slippery or otherwise unsafe road conditions long before any other information-providing source has access to the information.

[0046] Fig. Figure 1 shows an illustrative example of a process for making an emergency call. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, firmware operating in accordance with a pre-configured processor can, to a suitable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a meaningful variation thereof.

[0047] This illustrative example provides a case of a process in which, in the event of a collision, an attempt is made to first handle a distress call via an onboard communication device, and then to seek an external communication device if a problem occurs with the onboard device.

[0048] After the collision has been detected (301), the process first determines whether a telephone (or other similar communication device) is connected to the vehicle (303). The connected telephone or similar communication device will be the preferred communication device for this process; however, if the telephone is not currently connected (e.g., the driver forgot it or it has switched off), the process proceeds to step 201 of Fig. to continue searching for other vehicles, for example. Other suitable search and connection algorithms than those in Fig. are also being considered.

[0049] If the phone is currently connected (303), the process will use the connected phone to make a call (305). While this process will work as long as the connected phone remains connected and powered on, if the phone loses power or is otherwise disconnected from the system (for example, if it is damaged in an accident), the process may not be able to complete the call.

[0050] If the call has not yet been resolved (307), and there is a connection interruption of a connected telephone (309), the process may proceed to step 201 or a similar algorithm to attempt to transmit any remaining emergency information by using secondary vehicles, as described herein.

[0051] Fig. Figure 1 shows an illustrative example of a process for emergency communication. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, firmware operating in accordance with a pre-configured processor can, to a suitable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a meaningful variation thereof.

[0052] As previously noted, the connection between any two vehicles can be of short duration. Although it can be prolonged by vehicles traveling at the same speed, or by stop signs or traffic lights, any two vehicles will generally not remain in close proximity to each other for long. This is especially true if one of the vehicles has crashed at the side of the road and the other vehicle is passing by.

[0053] Accordingly, it is desirable to establish a communication link between the vehicles quickly and easily and to transmit relevant communication data to the secondary vehicle as rapidly as possible. In this illustrative example, priority data (403) is sent as soon as the emergency communication link is established. This can include, but is not limited to, the accident location, vehicle type, information about occupants, etc. For example, very basic information, such as location information, can be sent in an initial packet. Additional critical information can be sent in a second or subsequent packets, depending on its perceived importance. For instance, if the vehicle detects a fuel leak or if airbags have been deployed, the process could send this information in the first or a second packet.By keeping the initial packages small, there is a chance that a complete, important package can be delivered.

[0054] Once the initial data has been sent, the process determines whether there is any additional data that needs to be transmitted (405). This may include less critical data, but data that could still be useful in supporting the response to the accident. If additional data is found, the process continues to attempt to send it (407) until all relevant data has been sent.

[0055] In addition to sending the relevant data, the process can request acknowledgment from one or more of the secondary vehicles. In this example, acknowledgment is requested once all data has been sent (error code 409), but in another example, acknowledgment can be requested as soon as any data has been sent.

[0056] The acknowledgment can be confirmation that the data has been received, but in at least one example, the acknowledgment is confirmation that a distress message has actually been sent to a remote server. This allows the primary vehicle to know that help has been contacted and that it can stop sending a distress signal relayed by secondary vehicles. Multiple acknowledgments can be requested for each data packet, and as each packet is relayed and the relaying is acknowledged, the sending of the packets in question can be stopped. Once an acknowledgment (for all data or a single packet or packets) has been received, the process can send a termination signal regarding the acknowledged data to all secondary vehicles still in communication with the system.

[0057] For example, if a user has an accident in heavy highway traffic during rush hour, ten to fifteen vehicles might be available as secondary vehicles for a certain period when traffic slows down. Since the user doesn't need to send fifteen copies of an emergency message, once a single vehicle has confirmed sending any or all of the relevant data, the primary vehicle could instruct the other vehicles to stop attempting to send that data. If multiple requests have already been sent, this could be resolved at the receiving end.

[0058] Fig. This shows another illustrative process for emergency communication. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, firmware operating in accordance with a pre-configured processor can, to a suitable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a meaningful variation thereof.

[0059] This illustrative example shows the process for handling a rerouting request received by a secondary vehicle. The secondary vehicle receives the 501 request and, in this example, checks if an available remote communication device is enabled (503). In some examples, the vehicle may receive and handle the request regardless of its remote communication capability because the request could still be rerouting, as described previously. However, in this example, the process rejects the 505 request if the secondary vehicle lacks remote communication capability because it cannot handle the request by contacting emergency services on behalf of the primary vehicle.

[0060] If the secondary vehicle has remote communication capabilities, the process can connect to the requesting vehicle (507) and receive relevant emergency data (509). As noted, an initial packet or packets of the most relevant data can be received and processed. In this example, to provide emergency assistance as soon as possible, the secondary vehicle will send a text message (SMS message) to an appropriate source containing the necessary information.

[0061] While it may be possible to use the ad-hoc network in conjunction with a secondary vehicle's communication to make an actual emergency call, this could prove difficult because it depends on the secondary vehicle remaining within communication range of the primary vehicle. Therefore, in this example, the secondary vehicle instead sends a text message containing the relevant information to 511. In this example, the text message is forwarded to an OEM server or a third-party emergency service server for processing. This solution allows the emergency service server to obtain additional information regarding the vehicle (make, model, security system, etc.) for transmission to an emergency service provider. If desired, and if the emergency service provider has the capability to receive text messages, the vehicle could, of course, send the message directly to the emergency service provider.

[0062] Once the SMS message has been sent, the process checks if there is any additional data that might need to be sent (513). This could be data useful for emergency services, but not necessarily the most essential data for responding to the accident. If additional data is available, it can be received (515) and sent as SMS messages until all relevant data has been received and sent. At this point, if desired, a confirmation message can be sent to the primary vehicle (517).

[0063] In an alternative embodiment, the secondary vehicle can first receive the initial data and send an initial message. Subsequently, all further data can be received, either until no data remains or until a connection with the primary vehicle is interrupted. At this point, the additional data can be sent as a single message. In yet another embodiment, as much data as possible can be received before the initial message is sent. Any suitable variation of this model is considered to fall within the scope of the invention.

[0064] Fig. This figure illustrates a process for handling emergency calls. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, firmware operating in accordance with a pre-configured processor can, to a suitable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a meaningful variation thereof.

[0065] This process illustrates a server-side process for handling emergency calls. In at least one model, messages or notifications relating to the primary vehicle are sent to a server for handling emergency situations. Since this server receives all emergency communications, the process can eliminate duplicate requests before they reach an actual emergency service provider. This way, if there are several secondary vehicles making a request on behalf of the primary vehicle, emergency services are not overwhelmed with unnecessarily high numbers of requests.

[0066] In this example, the process receives an emergency SMS from a secondary vehicle (601). Before processing the request further, the process checks if there are any existing SMS messages of a similar nature relating to the same accident. This can be done by comparing location information, identification numbers of the primary vehicle, or any other suitable identifier that can be used to uniquely identify the accident. If the current request (605) has already been processed, the process can ignore the incoming SMS message.

[0067] If the current request has not yet been processed, the process can determine whether the request is a new (e.g., initial) request for assistance (607). If the request is an initial request, the process can send an initial assistance request to emergency services (609). A user account associated with the primary vehicle can then be updated (611) so that future requests can be handled accordingly (e.g., ignored if they have already been handled).

[0068] If the current request is not an initial request, the process can compare data in the message with data that has already been forwarded to the emergency service provider (613). This can help avoid forwarding data to the provider twice. If the data consists of new data (615), the process will send the new data to the service provider (617).

[0069] For example, a primary vehicle can contact up to three secondary vehicles without restriction and must send three data packets. All three vehicles can send the first packet, in this example an SMS; two of the vehicles might remain connected long enough to send the second packet; and a single vehicle can send the third packet.

[0070] When the first packet is received, it indicates the emergency, and emergency services can be contacted. Upon receiving the first packet a second and third time, it is ignored because emergency services have already been contacted. Subsequently, upon receiving the second packet for the first time, the additional data is forwarded to the emergency services. Upon receiving the second packet again, it is ignored because the data has already been sent. Finally, upon receiving the third packet, the data is forwarded because it has not yet been sent. In this way, the process helps avoid sending redundant data to emergency services while simultaneously forwarding as much new, relevant data as is received.

[0071] Fig.Figure 1 illustrates a process for vehicle-to-vehicle communication. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, firmware operating in accordance with a pre-configured processor can, to a suitable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a meaningful variation thereof.

[0072] This example handles a standard connection request. It considers a driver's ability to choose whether or not to exchange communication with a vehicle computer system in another vehicle. While emergency service requests are processed independently of driver preferences in some examples, other data exchange requests may be accepted or rejected by a driver for safety reasons.

[0073] A standard, non-emergency connection request is received from the secondary vehicle (701). If such requests are permitted (703), the process will connect to the primary vehicle (705). Otherwise, the process will reject the request (709). Once connected to the secondary vehicle, relevant data can be exchanged (707). This data can include, but is not limited to, road condition data, traffic data, weather data, etc. Even social data can be exchanged; for example, a driver could receive a playlist from another vehicle if the driver wants a random music suggestion to listen to. In this way, any useful or relevant data can be exchanged.

[0074] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the terms used in this specification are merely descriptive and do not imply any limitation. It is understood that various modifications can be made without altering the essence and scope of the invention. Furthermore, features from different implementing embodiments can be combined to form further embodiments of the invention.

Claims

[1] System (1), comprising: a processor (3) designed to: to detect an emergency condition of a primary vehicle (301); to determine that communication with emergency services is not possible through an onboard device (303); to search for a secondary vehicle with vehicle-to-vehicle communication capabilities (201); to send an emergency communication request to the secondary vehicle (209) in order to establish a communication link with the secondary vehicle (211); to send prioritized emergency data to the secondary vehicle (213); and the processor (3) is designed to receive confirmation from the secondary vehicle that an emergency request has been sent (215) to request assistance for the primary vehicle, characterized by , that the processor (3) is designed to send instructions to terminate emergency requests from additional secondary vehicles as soon as acknowledgment is received (221). [2] System (1) according to claim 1, wherein the processor (3) is designed to send the prioritized emergency data until no data remains to be sent (407). [3] System (1) according to claim 1, wherein the processor (3) is designed to terminate emergency service requests to additional secondary vehicles (413) as soon as an acknowledgment is received (411). [4] System (1) according to claim 1, wherein the processor (3) is designed to search for a plurality of secondary vehicles (229) and to send requests and data to them (227). [5] System (1) according to claim 1, wherein the processor (3) is designed to prioritize emergency data and to send first a single packet containing the highest priority data (403). [6] System (1) according to claim 5, wherein the highest priority data includes the location of the primary vehicle. [7] System (1) according to claim 5, wherein the highest priority data includes activation of an emergency disarming system of the primary vehicle.

Images