Method and device for using vehicles as mobile network nodes for digital data transfer

Abstract

System (1), comprising: a vehicle-based processor (3) designed to: Delivering a digital message to a message destination defined by a message delivery characteristic, the message being received wirelessly from a queuing system passed by a first vehicle including the processor (3), which is received in response to a transmission of vehicle delivery characteristics by the processor (3).

Description

TECHNICAL FIELD

[0001] The exemplary embodiments generally relate to a method and apparatus for using vehicles as mobile network nodes for digital data transfer. STATE OF THE ART

[0002] We live in a highly connected world where internet services and cellular data connections are available almost everywhere. Yet, there remain areas of the world, even in high-tech nations, where limited or no connectivity is available. People in these areas must either install very costly connectivity solutions (paying for dedicated line installation, paying for high-performance transceivers, etc.) or travel some distance to obtain a usable signal.

[0003] At the same time, vehicles are now equipped with telematics control units that offer both Wi-Fi and cellular capabilities, as well as short-range in-vehicle communication capabilities provided by vehicle computers with Bluetooth and other short-range services. These vehicles are ubiquitous on the roads and frequently (or at least occasionally) travel near areas where connectivity is unavailable.

[0004] Document DE 10 2015 104 746 A1 describes a method that includes calculating a possible capacity of a plurality of vehicle relay nodes in an area, wherein the plurality of vehicle relay nodes forward data between a plurality of portable devices and at least one base station. Document US 2014 / 0 155 019 A1 shows the provision of a mobile cellular communication system that includes at least one mobile relay. Any message received by a mobile relay or any station subtree and having an IP address that does not match any mobile station in the subtree is transmitted to the simulated stationary network.

[0005] The task is to improve message transmission by vehicles. SUMMARY

[0006] This object is achieved by a system according to claim 1 and claim 10. In a first exemplary embodiment, a system comprises a processor configured to request delivery of a queued digital message from passing vehicles in wireless communication with the processor after determining that the vehicle is emitting suitable delivery characteristics likely to enable eventual delivery of the message to an intended recipient by the vehicle acting as an intermediate carrier of the message.

[0007] In a second exemplary embodiment, a system includes a vehicle-based processor configured to deliver a digital message to a message destination defined by a message delivery characteristic, the message being received wirelessly from a queuing system passed by a first vehicle including the processor in response to a broadcast of vehicle delivery capabilities by the processor.

[0008] In a third exemplary embodiment, a system includes a processor configured to examine received delivery capabilities broadcast by passing vehicles to select a vehicle whose delivery capabilities match a message delivery characteristic, and to wirelessly transfer a digital message to a selected vehicle, the message having the message delivery characteristic specifying an intended message destination. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows an exemplary vehicle data processing system; Fig. 2 shows an illustrative example of a message transmission process; Fig. 3 shows an illustrative example of a message carrier notification process; Fig. 4 shows an illustrative example of a message transfer process; Fig. 5 shows an illustrative example of a vehicle selection process; Fig. 6 shows an illustrative example of a message delivery process; and Fig. Figure 7 shows an illustrative example of a message delivery notification process. DETAILED DESCRIPTION

[0009] As required, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Specific structural and functional details disclosed herein are, therefore, not to be considered limiting, but merely as a representative basis for teaching those skilled in the art to variously employ the present invention.

[0010] Fig. 1 shows an exemplary block topology for a vehicle-based computing system 1 (VCS) 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 enabled with a vehicle-based computing system may include an in-vehicle visual front-end interface 4. The user may also be able to interact with the interface if it is equipped with a touchscreen, for example. In another exemplary embodiment, the interaction occurs through button presses, a voice dialog system with automatic speech recognition, and speech synthesis.

[0011] At the Fig. In the exemplary embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based computing system. The processor is provided in the vehicle and allows onboard processing of instructions and routines. Further, the processor is connected to both non-persistent 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-volatile) memory can include any form of storage that can retain data when a computer or other device is turned off. This includes, but is not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any suitable form of persistent memory.

[0012] The processor is also equipped with a number of different inputs that allow the user to connect to the processor. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a display 4, which may be a touchscreen display, and a BLUETOOTH input 15 are all provided. An input selector 51 is also provided to allow a user to switch between different inputs. Inputs to both the microphone and auxiliary connectors are converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, numerous of the vehicle components and auxiliary components in communication with the VCS may utilize a vehicle network (such as, but not limited to, a CAN bus) to pass data to and from the VCS (or components thereof).

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

[0014] In an exemplary embodiment, system 1 uses BLUETOOTH transceiver 15 to communicate 17 with a user's mobile device 53 (e.g., a mobile phone, smartphone, PDA, or any other device with connectivity to a wireless remote network). The mobile device can then be used to communicate 59 with a network 61 external to vehicle 31, for example, through communication 55 with a cellular tower 57. In certain embodiments, tower 57 may be a Wi-Fi access point.

[0015] Example communication between the nomadic device and the BLUETOOTH transmitter / receiver is represented by signal 14.

[0016] Pairing of a nomadic device 53 and the BLUETOOTH transceiver 15 can be commanded by a button 52 or similar input. Accordingly, the CPU is notified that the onboard BLUETOOTH transceiver is being paired with a BLUETOOTH transceiver in a nomadic device.

[0017] Data may be communicated between the CPU 3 and the network 61, for example, using a data plan, data over voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to provide an onboard modem 63 having an antenna 18 to communicate 16 data between the CPU 3 and the network 61 over the voice band. The nomadic device 53 may then be used to communicate 59 with a network 61 external to the vehicle 31, for example, through communication 55 with a cellular tower 57. In certain embodiments, the modem 63 may establish communication 20 with the tower 57 for communication with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem, and the communication 20 may be cellular communication.

[0018] In an exemplary embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the BLUETOOTH transceiver to establish wireless communication with a remote BLUETOOTH transceiver (such as one found in a nomadic device). BLUETOOTH is a subset of the IEEE 802 PAN (Personal Area Network) protocols. The IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication in a vehicle. Other communication means that can be used in this area include free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0019] In another embodiment, the nomadic device 53 includes a modem for voiceband or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiple access may be implemented when the owner of the nomadic device can speak over the device while data is transferred. At other times, when the owner is not using the device, data transfer may utilize the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiple access may be common for analog cellular communication between the vehicle and the Internet and continues to be used, it has largely been replaced by hybrids of CDMA (Code Domain Multiple Access), TDMA (Time Domain Multiple Access), SDMA (Space-Domain Multiple Access) for digital cellular communication.These are all ITU IMT-2000 (3G) compliant standards and offer data rates of up to 2 mbs for stationary or walking users and 385 kbps for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which offers 100 mbs for users in a vehicle and 1 gbs for stationary users. If the user has a data plan associated with the nomadic device, it is possible that the data plan enables broadband transmission and the system could use a much larger bandwidth (thus speeding up data transfer). In another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed in the vehicle 31. In another embodiment, the ND 53 may be a wireless local area network (LAN) device, for example (and without limitation) via an 802.11g network (i.e.WiFi) or a WiMax network.

[0020] In one embodiment, incoming data can be routed through the nomadic 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, the data can be stored, for example, on the HDD or other storage medium 7 until the data is no longer needed.

[0021] Additional sources that may be connected to the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) having connectivity to the network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), 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 backbone of device-to-device serial standards. Most of the protocols can be implemented for either electrical or optical communication.

[0022] Furthermore, the CPU could be in communication with a variety of other auxiliary devices 65. These devices may be connected by a wireless 67 or wired 69 connection. The auxiliary device 65 may include, but is not limited to, personal media players, wireless healthcare devices, portable computers, and the like.

[0023] Additionally, or alternatively, the CPU could be connected to a vehicle-based wireless router 73, for example, using a WiFi (IEEE 803.11) transceiver 71. This would allow the CPU to connect to remote networks within range of the local router 73.

[0024] In addition to example processes being performed by a vehicle computing system located in a vehicle, in certain embodiments, the example processes may be performed by a computing system in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (e.g., and not limited to, a cellular phone) or a remote computing system (e.g., and not limited to, a server) connected by the wireless device. Collectively, such systems may be referred to as a vehicle-associated computing system (VACS). In certain embodiments, depending on the particular implementation of the system, certain components of the VACS may perform certain portions of a process. E.g.,And without limitation, if a process includes a step of sending or receiving information with a paired wireless device, then the wireless device is likely not performing that part of the process, as the wireless device would not "send and receive" information with itself. Those of ordinary skill in the art will understand when it is not appropriate to apply a particular data processing system to a given solution.

[0025] In each of the exemplary embodiments discussed herein, an exemplary, non-limiting example of a process executable by a data processing system is shown. With respect to each process, it is possible for the data processing system executing the process to be configured as a special-purpose processor for executing the process for the limited purpose of executing the process. Not all processes need to be fully executed, and it should be understood that they are examples of types of processes that may be performed to achieve elements of the invention. Additional steps may be added or removed from the exemplary processes as desired.

[0026] In the sparsely populated areas of developed nations and the vastly populated areas of developing world nations where there is little or no mobile connectivity, this represents a huge disadvantage and inconvenience for the people living in these locations. At the very least, these people must either pay exorbitant fees to obtain internet service or travel some distance to use even basic messaging services and email. This may be completely unfeasible in some cases and represents an inconvenience in others.

[0027] Fortunately, vehicles often or occasionally travel through areas where limited service exists. Although the vehicle itself may lose long-distance connectivity in these areas, the vehicle's short-range networking capabilities (BLUETOOTH, Wi-Fi) are unaffected (i.e., these capabilities continue to function). This can be effectively used to connect a remote participant to the vehicle, and the vehicle can be used as a digital transport for the transfer and delivery of messages and data.

[0028] For example, a vehicle passing near a Wi-Fi router can connect to the router. This router can also be connected, directly or indirectly, to any number of message owners (i.e., people who have messages or data they want delivered). In one case, a community or group of residences might locate a router as an access point near a road and then be hardwired to the router to deliver messages to the router, which can then be forwarded to vehicles. This is not currently a common solution, but this may be due in large part to the fact that the principle of vehicles as message carriers is not currently used.

[0029] When the vehicle passes the router, the vehicle's installed Wi-Fi capabilities can be used to connect to the router (which would be a public network, for example), and the vehicle can broadcast data about its delivery capabilities to the network. For example, the vehicle could broadcast a route (since it's not necessarily desirable to use the vehicle as transportation when traveling to the mountains for a month), as well as a common "home" location. A message delivery application can compare the route and home location with areas of known service and message recipients to determine whether the vehicle is suitable for delivering the message(s).

[0030] Other vehicle capabilities (BLUETOOTH, cellular modem, etc.) can also be broadcast, as a vehicle with long-distance connectivity is a useful transportation vehicle in areas with cellular service, regardless of route or home location, unless those locations also lack cellular service. Once a vehicle receives a message to be delivered, it can travel until it reaches a point where the internet or cellular networks can be contacted, or it can relay the message to another vehicle that might be traveling in a direction where the message might be delivered more quickly.For example, this message relay capability could be very useful when a message is to be delivered to the remote area, as it might be prudent to place the message on a number of vehicles traveling in the general direction of the remote area, with each vehicle relaying the message to other vehicles when they are near the remote area, thus increasing the chances of the message actually being delivered to the remote area (by way of one of the vehicles passing close enough to the access point to relay the message(s)).

[0031] In some communities, if enough people use this service, it may even be reasonable for a designated vehicle to travel regularly from the access point to a service point, effectively acting as a digital postman for the purposes of sending and receiving messages. In another example, it might actually be reasonable to equip postal service vehicles with such a capability, as they travel regularly to most residences and could thus be ideal carriers for digital messages. One method for transferring a message to a vehicle, between vehicles, and / or to an intended recipient network involves DSRC (Dedicated Short Range Communication), which is wireless spectrum allocated for wireless automotive use.

[0032] Fig. Figure 2 shows an illustrative example of a messaging process. With reference to the example embodiments described in this figure, it is noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily used as a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating according to a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0033] In this illustrative example, the process receives a message to be delivered 201. The message is in digital form, but can be delivered to an email, a telephone, or even a physical location or person (if the carrier is willing to assist with such delivery). Delivery data is added to the message 203, specifying the parameters for delivery. These can include, for example, a physical location, a subscriber, an image of the recipient or a recipient location, a network address, a mobile number, etc.

[0034] The message is then sent to a delivery queue 205, where it waits with other messages for an opportunity to be transferred to a vehicle that can act as a suitable carrier. While the message queue is building, the process searches for a suitable carrier for one or more messages 207. For example, the messages may be queued in a near-roadside system equipped with a wireless access point. The system queues the messages and scans passing vehicles for communication opportunities and drivers / vehicles able and / or willing to participate in carrying and delivering messages. When a vehicle becomes available 209, the process uploads one or more messages to that vehicle 211. At this point, an acknowledgment may be sent to the message owner 213 (i.e.the originating participant) that lets the owner know that the message delivery process has begun.

[0035] Fig. Figure 3 shows an illustrative example of a message carrier notification process. With reference to the example embodiments described in this figure, it is noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily used as a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating according to a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0036] In this exemplary embodiment, a participating vehicle broadcasts its delivery capabilities and other relevant information about any access points or other points where a message may wait. In this example, the vehicle maintains a log of its recent capabilities (i.e., which networks it has recently encountered and / or commonly accesses, such as, but not limited to, a cellular network, one or more local area networks (LANs), one or more internet access points, and / or any locations that may be relevant to a physical message delivery location) 301. These delivery options are broadcast by the vehicle 303 so that a message sender knows whether or not the vehicle is suitable for delivering a particular message.

[0037] When the process receives a request to broadcast the message 305, the process opens a communication channel (BLUETOOTH, WiFi, etc.) with the access point or local system, thereby requesting message delivery 307. At this point, any messages to be delivered by that particular vehicle are transferred to the vehicle 309.

[0038] Fig. Figure 4 shows an illustrative example of a message transfer process. With reference to the example embodiments described in this figure, it is noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily used as a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating according to a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0039] This is an illustrative example of a verification process where a message queuing system or a message originating system determines whether a passing vehicle is eligible for message delivery. The queuing or originating system can be an access point, a computing system (laptop, desktop, tablet, etc.), or even a mobile device (e.g., the user types a text message on a mobile device and is queued on the device for transfer to a passing vehicle).

[0040] The message origination or queuing system communicates with a passing vehicle 401 and receives the various outputs (delivery options) broadcast by that particular vehicle 403. Since a bidirectional communication process with the vehicle may not yet be established, the process can simply receive broadcast information regarding the vehicle's delivery capabilities. This process examines the capabilities to determine whether these capabilities are suitable for delivering a particular message 405.

[0041] For example, and without limitation, if the message is to be delivered to a physical location, the process may examine a current vehicle route and / or common vehicle locations (such as a "home" location). If the vehicle is traveling toward or is likely to be within a physical delivery area within a reasonable time frame, the process may confirm that the vehicle's physical location is likely suitable for message delivery. In another example, if the message is to be delivered over a cellular network, the process may determine whether the vehicle has access to a cellular connection (e.g., a modem or Bluetooth connection to a cellular device) and whether it is likely to soon enter a service area (although merely the existence of a cellular connection may be sufficient, since it can be assumed that the vehicle will also have cellular service at some point).

[0042] In another example, the message may be an email that requires internet or network access for delivery. In this case, the process may determine whether the vehicle has data delivery capabilities (WiFi access and / or cellular data connection, allowing access to the internet). If the vehicle is capable of delivering a message, the process may request, based on the outbound capabilities, that one or more messages be uploaded to the vehicle 407. On the vehicle side, the driver may be given an option to "carry" the message(s), or the driver may have chosen to simply participate as a delivery source. If the driver agrees (implicitly or explicitly), the process may establish a connection with the vehicle 409 and upload one or more messages for delivery 411.

[0043] Fig. 5 shows an illustrative example of a vehicle selection process. With reference to the exemplary embodiments described in this figure, it is noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the exemplary methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily used as a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating according to a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0044] In this illustrative example, the process examines the vehicle's physical delivery capabilities (i.e., whether the vehicle is traveling to a physical location suitable for message delivery). This can include delivering messages to an actual physical location and / or whether the vehicle is likely to travel through a physical location corresponding to known network or cellular access. The process communicates with the vehicle 501 and, in this example, receives a current vehicle route 503 indicating where the vehicle is likely to travel next.

[0045] Additionally, in this example, the process receives one or more usual locations to which the vehicle travels (e.g., home location, work location, etc.) 505. Even if a vehicle is not currently traveling toward a desirable location, the vehicle's garage location or usual parking location may indicate that it is likely to travel to the desired area soon, which may be sufficient depending on the specific model enabled. The destination / route and / or usual vehicle locations are compared with physical delivery properties associated with the message or known to be needed to deliver the message 507, and if a suitable match exists 509, the process requests the message(s) to be uploaded for delivery 511.In another example, the mere fact that a vehicle will soon be traveling on a busy road may be sufficient, as the vehicle may also be able to relay the message to one or more other vehicles by entering the busy road.

[0046] Once the upload is requested and the process connects (via BLUETOOTH, WiFi, etc.) to a vehicle computer 513, the process uploads the message(s) for delivery using the particular vehicle 515.

[0047] Fig. Figure 6 shows an illustrative example of a message delivery process. With reference to the example embodiments described in this figure, it is noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily used as a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating according to a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0048] In this illustrative example, a person creates a message for delivery. This could be an email message to be delivered to the cloud (where it can be routed accordingly), an SMS or text message to be delivered to a cellular network (for eventual transmission), or even a message requesting physical delivery (assuming the vehicle driver is willing to assist, such as "Please tell X that their services are needed at location Y"). The recipient of the message and the delivery method, among other things, can be set as delivery conditions 601.

[0049] The process first determines whether a network (e.g., the Internet or a cellular network) is named as a delivery condition 603. If so, the process adds an IP address (or mobile number to which a cellular message is to be delivered) 605. Next, the process determines whether any physical delivery is required (such as personal delivery of the message or delivery of the message to a physical network router located at a specific location) 607. If a physical location is part of the delivery protocol, the process adds coordinates 609 as one of the delivery specifications. In this example, the process also adds one or more geofences surrounding the coordinates, which can be used in conjunction with a vehicle home location or a vehicle route to determine whether a vehicle is suitable for delivering the message to the specified physical location.For example, four fences could be set at one, five, ten, and twenty miles from the destination. The first fence could designate any vehicle traveling within 20 miles or with a home location as a potential carrier.

[0050] Once the initial vehicle is selected, the second fence would be used to relay the message to one or more vehicles traveling within ten miles of the selected location. This could occur at any time the initial carrier passes such a vehicle, or once the initial carrier reaches the twenty-mile fence. Similarly, vehicles can be selected for relaying based on five-mile and one-mile fences, allowing vehicles to be quickly and easily identified as suitable for message delivery without requiring a complicated application in the vehicles or with the message package to determine whether the message can be delivered by a potential carrier.

[0051] Finally, in this example, the process determines whether there are any visual properties associated with the message delivery 613. For example, assume that a message is to be delivered to Bob at the local grocery store. A picture of Bob may be added so that the delivering participant can easily identify Bob. At this point, any required images may be added 615. In addition, any other delivery properties 617 may be added to the message as needed.

[0052] Fig. Figure 7 shows an illustrative example of a message delivery notification process. With reference to the example embodiments described in this figure, it is noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily used as a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating according to a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0053] All processes described for determining whether a vehicle is a suitable carrier for a message can also be used by a vehicle to determine whether another vehicle passing the original vehicle is suitable for forwarding the message. Just as the message is initially transferred to the original carrier vehicle, the message can be further transferred to one or more additional delivery vehicles if they have suitable characteristics for delivery. In the Fig.In the example shown in Figure 7, the message includes a record of the IP addresses of the vehicles that carried it, so that when the message is delivered to the recipient, the vehicles can be notified of the delivery and thus the remaining vehicles can stop attempting to deliver the message. In another example, the message can be deleted after transfer, assuming that the recipient vehicle will ultimately deliver the message. The message can also expire after a certain period of time, allowing for "cleanup" of messages in vehicles that carry them.

[0054] In this example, when the message is finally delivered 701 (e.g., the vehicle encounters a location or accesses a network suitable for completing the delivery), the vehicle sends a notification to the other vehicles that acted as carriers 703. This allows the other vehicles to delete the message. If each vehicle keeps track of the IP addresses of the vehicles to which the message was routed, then by contacting the original vehicle, that vehicle can contact its subsequent carrier, and so on, so that the message can be quickly deleted from all current carriers (assuming they are online at the time).

[0055] Additionally, the message in this example has an expiration date / time 705, which will help clean up old messages that have likely been delivered but for which no acknowledgment has yet been received. After the message expires 705, the process also sends a notification to the other carriers 707 (although this may not be necessary if all carriers have the same expiration date / time stored). In this case, a notification is also sent to the message owner (origin) 709, so that the owner knows that the message has been deleted due to expiration from one or more systems (and may or may not have been delivered). Of course, if the message owner is at the remote location, it may take some time for the notification of the reverse of the above delivery process to reach the owner (i.e.an application running on a server on behalf of the owner can route messages to the owner in a similar way, by attaching them to vehicles that are likely to pass the owner's location based on, for example, the route).

[0056] Although exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the invention. The words used in the specification are words of description, not limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, the features of various implementation embodiments may be combined to form further embodiments of the invention.

Claims

[1] System (1), comprising: a vehicle-based processor (3) designed to: Delivering a digital message to a message destination defined by a message delivery characteristic, the message being received wirelessly from a queuing system passed by a first vehicle including the processor (3), which is received in response to a transmission of vehicle delivery characteristics by the processor (3). [2] The system (1) of claim 1, wherein the message delivery property comprises a network address and the processor (3) is configured to deliver the message after connectivity to a network over which the network address can be reached is established. [3] The system (1) of claim 1, wherein the message delivery property comprises a mobile phone number and the processor (3) is configured to deliver the message to a mobile network as soon as a connection to the mobile network is available. [4] The system (1) of claim 1, wherein the processor (3) is configured to broadcast vehicle delivery characteristics comprising common physical locations where the first vehicle is parked. [5] The system (1) of claim 1, wherein the processor (3) is configured to transmit vehicle delivery characteristics comprising a current vehicle route. [6] The system (1) of claim 1, wherein the processor (3) is configured to broadcast vehicle delivery characteristics including vehicle connectivity capabilities. [7] The system (1) of claim 1, wherein the processor (3) is configured to determine that a second vehicle in communicable proximity of the first vehicle is a realistic candidate for message delivery to the message destination based on message delivery characteristics of the second vehicle transmitted by the second vehicle and received by the processor (3), and to subsequently wirelessly deliver the message to the second vehicle. [8] The system (1) of claim 1, wherein the queuing system comprises a mobile device. [9] The system (1) of claim 1, wherein the queuing system comprises a computer. [10] System (1), comprising: a processor (3) designed to: Examining received vehicle delivery characteristics transmitted by passing vehicles to select a vehicle whose vehicle delivery characteristics match a message delivery characteristic, and wirelessly transferring a digital message to a selected vehicle, the message having the message delivery property specifying an intended message destination.

Images