Virtual network interface connection

Abstract

The invention relates to virtual network interface connections. A mobile device receives a message from a vehicle computing platform via a remote procedure communication (RPC), updates a source address of the message to indicate the mobile device, sends the message to a destination address of the message, receives a response message from the destination, updates a destination address of the response message to indicate the vehicle computing platform, and sends the response message to the vehicle computing platform via the RPC. For a request received from a vehicle application for a network protocol not supported by the mobile device, the computing platform constructs a remote procedure call (RPC) message by a virtual network interface application and sends the RPC message to the mobile device to cause the mobile device to update a source address of the request to indicate the mobile device and send the request to a destination address of the request.

Description

Technical Field

[0001] Several aspects of this disclosure generally relate to a virtual network interface used by a vehicle application for accessing network connectivity for connected mobile devices. Background Technology

[0002] Mobile devices, such as smartphones, can connect to the vehicle's head unit to provide connectivity services to vehicle occupants. These connectivity services may include hands-free calling, audio streaming, and integration with applications carried on the mobile device. Applications running on the mobile device can utilize the mobile device's network connectivity. However, applications running in the vehicle require a connection to the mobile device (e.g., via WiFi, Bluetooth, or USB) to use the mobile device's network connectivity. Summary of the Invention

[0003] In one or more illustrative embodiments, a system includes a mobile device. The mobile device is configured to: receive a message from a vehicle computing platform via remote processing communication (RPC); update the source address of the message to indicate the mobile device; send the message to the destination address of the message; receive a response message from the destination address; update the destination address of the response message to indicate the vehicle computing platform; and send the response message to the vehicle computing platform via RPC.

[0004] According to one embodiment of the present invention, a message is sent from a vehicle application executed by a vehicle computing platform, and the vehicle application communicates via the Message Queuing Telemetry Transport (MQTT) protocol.

[0005] According to one embodiment of the present invention, a message is sent from a vehicle application executed by a vehicle computing platform, and the vehicle application communicates via a file transfer protocol (FTP).

[0006] According to one embodiment of the present invention, a message is sent from a vehicle application executed by a vehicle computing platform, and the vehicle application communicates via Hypertext Transfer Protocol (HTTP).

[0007] In one or more illustrative embodiments, a system includes a computing platform. The computing platform is configured to: construct a Remote Procedure Call (RPC) message via a virtual network interface application in response to a request received from a vehicle application for a network protocol not supported by the mobile device; send the RPC message to the mobile device such that the mobile device updates the source address of the request to instruct the mobile device, and sends the request to the destination address of the request.

[0008] According to one embodiment of the present invention, the computing platform is further configured to: query the mobile device for network protocols supported by the mobile device itself; and identify network protocols not supported by the mobile device based on the query.

[0009] According to one embodiment of the present invention, the computing platform is further configured to: receive from another vehicle application another request for another network protocol supported by the mobile device; and send the other request to the mobile device for processing by an application of the mobile device corresponding to the other network protocol.

[0010] According to one embodiment of the invention, the computing platform is further configured to: receive a response to a request from a mobile device; and send the response to a vehicle application.

[0011] According to one embodiment of the present invention, the source address and destination address are Internet Protocol (IP) addresses.

[0012] According to one embodiment of the present invention, RPC is executed according to the Smart Device Link (SDL) protocol.

[0013] According to one embodiment of the invention, the computing platform is further configured to receive from the mobile device a network status indicating details of a network connection to a communication network provided by the mobile device's physical network interface, wherein a destination address is reached via the communication network.

[0014] In one or more illustrative embodiments, a method includes: receiving from a mobile device an indication of a network protocol supported by the mobile device itself by a computing platform; receiving a request from a vehicle application utilizing the network protocol; in response to the network protocol being supported by the mobile device itself, sending the request to the mobile device for processing by a native application of the mobile device; and in response to the network protocol not being supported by the mobile device itself, sending the request to the mobile application using a proxy method. Attached Figure Description

[0015] Figure 1 An example diagram of a system configured to provide telematics services to a vehicle is shown;

[0016] Figure 2 This diagram illustrates a sample data flow of a vehicle application using a mobile device's network connection via a network interface proxy.

[0017] Figure 3 An example processing is shown for a computing platform to help vehicle applications use network connectivity from mobile devices;

[0018] Figure 4 An exemplary process for using mobile devices to assist vehicle applications in utilizing the network connectivity of mobile devices is shown. Detailed Implementation

[0019] Detailed embodiments of the invention are disclosed herein as needed; however, it will be understood that the disclosed embodiments are merely examples of the invention, which may be implemented in various alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as teaching those skilled in the art to utilize the representative basis of the invention in various ways.

[0020] When an application executed by a vehicle requests data using a standard protocol (such as Hypertext Transfer Protocol (HTTP)), the vehicle can provide HTTP header information to the connected device (e.g., via a Smart Device Link (SDL)), and the mobile device can execute an application that implements the standard protocol as a remote service to upload or download data using the mobile device. However, if the vehicle application uses an application-layer protocol (such as Message Queuing Telemetry Transport (MQTT)) that is not supported by the mobile device's service, the mobile device cannot fulfill the vehicle application's request.

[0021] While vehicle occupants can configure their mobile devices to act as a hotspot for use as a modem, this setup may prevent occupants from using their mobile devices for wireless projection onto the vehicle's user interface. Furthermore, the hotspot function typically requires vehicle occupants to actively enable a hotspot that is not normally enabled.

[0022] Improved systems and methods are provided for allowing vehicle applications to utilize the connectivity of mobile devices. Applications executed by a vehicle computing platform utilize a virtual network interface to present the network interface of the connected device. IP packets generated by the application are captured using a packet sniffer (e.g., a Layer 3 packet sniffer). These IP packets can be forwarded to the mobile device using a remote procedure mechanism (e.g., the RPC mechanism of SDL), where the source IP address of the IP packet is changed to the IP address of the mobile device. This updated IP packet is then sent from the mobile device to the destination IP. When a response to the packet is sent back to the mobile device, the packet address is updated again, and the packet is routed back via an RPC mechanism (e.g., via the SDL core) to the vehicle application. The virtual network interface also allows the vehicle application to receive active network status information (e.g., cellular connection, WiFi connection, etc.) related to the connected mobile device. Other aspects of this disclosure are described in detail below.

[0023] Figure 1An example diagram of a system 100 configured to provide telematics services to vehicle 102 is shown. Vehicle 102 may include various types of passenger vehicles (such as hybrid multi-purpose vehicles (CUVs), sport multi-purpose vehicles (SUVs), trucks, RVs, boats, aircraft, or other mobile machines used for transporting people or goods). As some non-limiting possibilities, telematics services may include navigation, turn-by-turn direction, vehicle health reports, local business search, accident reporting, and hands-free calling. In the example, system 100 may include the SYNC system manufactured by Ford Motor Company of Dearborn, Michigan. It should be noted that system 100 shown is merely an example and more, fewer, and / or different arrangements of elements may be used.

[0024] The computing platform 104 may include one or more processors 106 connected to both memory 108 and computer-readable storage medium 112 and configured to execute instructions, commands, or other routines supporting the processing described herein. For example, the computing platform 104 may be configured to execute instructions for a vehicle application 110 to provide functions such as navigation, accident reporting, satellite radio decoding, and hands-free calling. Such instructions and other data may be stored in a non-volatile manner using various types of computer-readable storage medium 112. The computer-readable medium 112 (also referred to as processor-readable medium or memory) includes any non-transitory medium (e.g., tangible medium) involved in providing instructions or other data that can be read by the processors 106 of the computing platform 104. Computer-executable instructions may be compiled or interpreted from computer programs created using various programming languages ​​and / or technologies, including but not limited to one or a combination of the following: Java, C, C++, C#, Objective C, Fortran, Pascal, JavaScript, Python, Perl, and PL / SQL.

[0025] The computing platform 104 may be configured with various functions that allow vehicle occupants to interact with it. For example, the computing platform 104 may include an audio input 114 and an auxiliary audio input 118. The audio input 114 is configured to receive spoken commands from the vehicle occupants via a connected microphone 116, and the auxiliary audio input 118 is configured to receive audio signals from a connected device. The auxiliary audio input 118 may be a physical connection (such as a wire or fiber optic cable) or a wireless input (such as a Bluetooth audio connection). In some examples, the audio input 114 may be configured to provide audio processing capabilities, such as pre-amplification of low-level signals and conversion of analog inputs into digital data for processing by the processor 106.

[0026] The computing platform 104 may also provide one or more audio outputs 120 to the input of the audio module 122, which has audio playback capabilities. In other examples, the computing platform 104 may provide audio output to occupants using one or more dedicated speakers (not shown). The audio module 122 may include an input selector 124 configured to provide audio content from a selected audio source 126 to an audio amplifier 128 for playback via vehicle speakers 130 or headphones (not shown). As some examples, the audio source 126 may include decoded AM or FM radio signals, and audio signals from CD or DVD audio playback. The audio source 126 may also include audio received from the computing platform 104 (such as audio content generated by the computing platform 104), audio content decoded from a flash drive connected to the Universal Serial Bus (USB) subsystem 132 of the computing platform 104, and audio content transmitted through the computing platform 104 from auxiliary audio input 118.

[0027] The computing platform 104 may provide a hands-free interface to the computing platform 104 via the voice interface 134. The voice interface 134 may support speech recognition of audio received via the microphone 116 according to a standard syntax describing the available command functions, and may support voice prompt generation for output via the audio module 122. The voice interface 134 may utilize probabilistic speech recognition technology using a standard syntax that compares to the input speech. In many cases, the voice interface 134 may include standard user profile tuning for use by the speech recognition function to allow speech recognition to be tuned to provide a generally good result, thereby providing a positive experience for a maximum number of initial users. In some cases, the system may be configured to temporarily mute or otherwise override the audio source specified by the input selector 124 when an audio prompt is ready to be presented by the computing platform 104 and another audio source 126 is selected for playback.

[0028] The standard grammar includes data to allow the voice interface 134 to match voice input with words and phrases defined by rules in the standard grammar. The standard grammar may be designed to recognize a predefined set of words or phrases. More complex standard grammars may be designed to recognize and organize semantic content from a variety of user utterances. In one example, the standard grammar may include commands for initiating telematics functions of vehicle 102, such as “call,” “direction,” or “set navigation destination.” In another example, the standard grammar may include commands for controlling other functions of vehicle 102, such as “open the windows,” “turn on the headlights,” or “tune to radio preset three.”

[0029] The computing platform 104 may also receive input from a human-machine interface (HMI) control 136 configured to provide interaction between the occupants and the vehicle 102. For example, the computing platform 104 may interact with one or more buttons or other HMI controls (e.g., steering wheel audio buttons, push-button buttons, dashboard controls, etc.) configured to invoke functions on the computing platform 104. The computing platform 104 may also drive or otherwise communicate with one or more displays 138, which are configured to provide visual output to the vehicle occupants via a video controller 140. In some cases, the display 138 may be a touchscreen, further configured to receive user touch input via the video controller 140; in other cases, the display 138 may simply be a display without touch input capability.

[0030] The computing platform 104 may also be configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 142. As some examples, the in-vehicle network 142 may include one or more of a vehicle controller local area network (CAN), Ethernet, and media-oriented system transport (MOST). The in-vehicle network 142 may allow the computing platform 104 to communicate with other systems of the vehicle 102, such as a vehicle modem 144 (which may be absent in some configurations), a Global Positioning System (GPS) module 146 configured to provide current position and heading information of the vehicle 102, and various vehicle electronic control units (ECUs) 148 configured to cooperate with the computing platform 104. As some non-limiting alternatives, the vehicle ECU 148 may include: a powertrain control module configured to provide control of engine operating components (e.g., idle speed control components, fuel delivery components, emission control components, etc.) and monitoring of engine operating components (e.g., the status of engine diagnostic codes); a body control module configured to manage various electrical control functions (such as exterior lighting, interior lighting, keyless entry, remote start, and entry point status verification (e.g., the closing status of the hood, doors, and / or trunk of vehicle 102)); a radio transceiver module configured to communicate with the remote key or other local devices of vehicle 102; and a climate control management module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).

[0031] As shown, the audio module 122 and HMI control unit 136 can communicate with the computing platform 104 via a first vehicle network 142A, and the vehicle modem 144, GPS module 146, and vehicle ECU 148 can communicate with the computing platform 104 via a second vehicle network 142B. In other examples, the computing platform 104 may be connected to more or fewer vehicle networks 142. Alternatively or additionally, one or more HMI controls 136 or other components may be connected to the computing platform 104 via a different vehicle network 142 than the one shown, or directly connected to the computing platform 104 without being connected to any vehicle network 142.

[0032] The computing platform 104 may also be configured to communicate with a mobile device 152 belonging to a vehicle occupant. The mobile device 152 may be any of various types of portable computing devices (such as cellular phones, tablets, smartwatches, laptops, portable music players, or other devices capable of communicating with the computing platform 104). In many examples, the computing platform 104 may include a wireless transceiver 150 (e.g., a Bluetooth module, Zigbee transceiver, WiFi transceiver, IrDA transceiver, RFID transceiver, etc.) configured to communicate with a compatible wireless transceiver 154 of the mobile device 152. Alternatively or concurrently, the computing platform 104 may communicate with the mobile device 152 via a wired connection (such as a USB connection between the mobile device 152 and the USB subsystem 132). In some examples, the mobile device 152 may be battery-powered, while in others, the mobile device 152 may receive at least a portion of the vehicle's power from the vehicle 102 via a wired connection.

[0033] Communication network 156 can provide communication services such as packet-switched network services (e.g., Internet access, VoIP communication services) to devices connected to communication network 156. Examples of communication network 156 may include cellular telephone networks. Mobile device 152 can provide network connectivity to communication network 156 via device modem 158 of mobile device 152. To facilitate communication through communication network 156, mobile device 152 can be associated with a unique device identifier (e.g., Mobile Device Number (MDN), Internet Protocol (IP) address, etc.) to identify communications conducted by mobile device 152 through communication network 156. In some cases, the occupants of vehicle 102 or devices authorized to connect to computing platform 104 can be identified by computing platform 104 based on pairing device data 160 stored in storage medium 112. For example, pairing device data 160 may indicate a unique device identifier of a mobile device 152 previously paired with computing platform 104 of vehicle 102, so that computing platform 104 may automatically reconnect to the mobile device 152 referenced in pairing device data 160 without user intervention.

[0034] When a network-connected mobile device 152 is paired with a computing platform 104, the mobile device 152 allows the computing platform 104 to use the network connectivity of the device modem 158 to communicate with a telematics server 162 or other remote computing devices via a communication network 156. In one example, the computing platform 104 may use the mobile device 152's on-demand data plan or data plan to transmit information between the computing platform 104 and the communication network 156. Alternatively, the computing platform 104 may use a vehicle modem 144 to transmit information between the computing platform 104 and the communication network 156 without using the communication facilities of the mobile device 152.

[0035] Similar to computing platform 104, mobile device 152 may include one or more processors 164 configured to execute instructions of mobile application 170 loaded from storage medium 168 of mobile device 152 into memory 166 of mobile device 152. In some examples, mobile application 170 may be configured to communicate with computing platform 104 via wireless transceiver 154 and with telematics server 162 or other network services via device modem 158.

[0036] For example, computing platform 104 may include device link interface 172 to facilitate the integration of functionality of mobile application 170, which is configured to communicate with device link application core 174 executed by mobile device 152. In some examples, mobile application 170 supporting communication with device link interface 172 may be statically linked to functionality of device link application core 174 or otherwise incorporate functionality of device link application core 174 into binary mobile application 170. In other examples, mobile application 170 supporting communication with device link interface 172 may access shared or separate application programming interfaces (APIs) of device link application core 174 to facilitate communication with device link interface 172.

[0037] As an example, the integration of functionality provided by the device link interface may include the ability of a mobile application 170 executed by mobile device 152 to incorporate additional voice commands into the syntax of commands available via voice interface 134. Device link interface 172 may also provide mobile application 170 with access to vehicle information available to computing platform 104 via in-vehicle network 142. An example of device link interface 172 may be the SYNC APPLINK component of the SYNC system provided by Ford Motor Company, Dearborn, Michigan. Other examples of device link interface 172 may include MIRRORLINK, APPLE CARPLAY, and ANDROID AUTO.

[0038] Figure 2 An example data flow diagram 200 is shown for vehicle application 110 using a network connection of mobile device 152. This connection can be used through virtual network interface application 202 of computing platform 104 and virtual network mobile application 208 of mobile device 152.

[0039] Virtual network interface application 202 may be an example of vehicle application 110 stored in memory 112 and executed by one or more processors 106 of computing platform 104. Virtual network interface application 202 may include virtual interface manager 204 and virtual interface plug-in 206. Virtual interface manager 204 may be configured to receive Internet Protocol (IP) packets or other data (such as get or upload requests) from vehicle application 110 and place these requests in a channel for processing by virtual interface plug-in 206. In the example, virtual interface manager 204 of virtual network interface application 202 uses a packet sniffer (e.g., a Layer 3 packet sniffer) to capture IP packets generated from vehicle application 110.

[0040] Virtual interface plugin 206 can be configured to access channel traffic to send traffic to device link interface 172. In some examples, virtual network interface application 202 can be configured to utilize different device link interfaces 172. In this example, virtual network interface application 202 may include or otherwise be able to access multiple virtual interface plugins 206, and may utilize the virtual interface plugin 206 corresponding to the specified device link interface 172 used.

[0041] Device link interface 172 and device link application core 174 can be configured to maintain a communication link between computing platform 104 and mobile device 152. In this example, the communication link may be supported by wireless transceiver 150 of computing platform 104 (e.g., for WiFi or Bluetooth links) or by services of USB subsystem 132 of computing platform 104 (e.g., for USB links).

[0042] Virtual interface plugin 206 can forward IP packets monitored by virtual interface manager 204 to mobile device 152 via device link interface 172. In this example, virtual interface plugin 206 can use a remote procedure mechanism (e.g., an RPC mechanism available via SDL) to send packets to mobile device 152. Device link application core 174 can receive data from device link interface 172 and provide the received data to virtual network mobile application 208.

[0043] Virtual network mobile application 208 may be an example of mobile application 170 stored in memory 168 and executed by one or more processors 164 of mobile device 152. Virtual network mobile application 208 may include IP data manager 210 and agent 212. IP data manager 210 may be configured to receive binary packet data from device link application core 174 and decode the binary packet data. IP data manager 210 may also be configured to send received IP packet data to agent 212.

[0044] Agent 212 can be configured to create new IP packets for data received from IP data manager 210. Agent 212 can also update the source IP address of the packet to the IP address of mobile device 152, instead of updating it to the IP address of computing platform 104. Agent 212 can also create a TCP (Transmission Control Protocol) socket and write the IP data packet to the physical network interface 214 of mobile device 152. This updated IP packet can then be sent from mobile device 152 to its destination IP address via physical network interface 214.

[0045] A response to the packet can be sent back to the physical network interface 214 of mobile device 152. The response packet can then be forwarded to virtual network mobile application 208. Agent 212 can receive the response packet, update the response packet using the address information of computing platform 104, and return the response packet to IP data manager 210. IP data manager 210 can construct a binary representation and forward the binary representation to device link application core 174. Device link application core 174 can send the response back to device link interface 172 via RPC mechanism to forward the response to virtual network interface application 202. Virtual interface plugin 206 of virtual network interface application 202 can decode the packet according to the protocol of virtual interface plugin 206 and can provide the decoded packet to virtual network manager 204 to add to the channel. Vehicle application 110 can read the decoded packet from the channel accordingly. Therefore, vehicle application 110 can utilize the connection from mobile device 152 to communication network 156 without considering whether mobile device 152 supports the specific protocol used by vehicle application 110.

[0046] In addition to packet streams, the virtual network interface can also allow vehicle application 110 to receive active network status information (e.g., cellular connection, WiFi connection, etc.) related to the connected mobile device 152. In the example, vehicle application 110 can request network status information from virtual network interface application 202, which in turn allows virtual interface plugin 206 to query device link interface 172 for the connection status between device link interface 172 and device link application core 174. If no connection to mobile device 152 exists, device link interface 172 can report the absence of connection to virtual interface plugin 206, which in turn allows virtual network interface application 202 to notify vehicle application 110 that no network interface is available. However, if mobile device 152 is connected, device link application core 174 can provide device link interface 172 with information about the network status of the connected mobile device 152. In the example, device link interface 172 can indicate whether mobile device 152 is connected to communication network 156 via physical network interface 214 via cellular connection and / or via WiFi connection. Alternatively, the device link interface 172 may indicate other details of the network connection provided by the physical network interface 214, such as data connection rate, latency, and number of packet losses or retransmissions.

[0047] Figure 3 An example process 300 is shown for computing platform 104 to assist vehicle application 110 in using the network connection of mobile device 152. In the example, process 300 may be executed using virtual network interface application 202 of computing platform 104.

[0048] In operation 302, computing platform 104 receives a request from vehicle application 110. In this example, vehicle application 110 may send an MQTT get or upload request to virtual network interface application 202.

[0049] In operation 304, computing platform 104 writes message data to the channel. In the example, virtual interface manager 204 of virtual network interface application 202 receives a request from vehicle application 110 and places the request on the channel. In operation 306, computing platform 104 reads message data from the channel. In the example, virtual interface plug-in 206 accesses channel traffic to receive requests. In the example, virtual interface plug-in 206 may also provide requests to device link interface 172.

[0050] In operation 308, computing platform 104 constructs an RPC message. In this example, device link interface 172 constructs the RPC message. In operation 310, computing platform 104 sends the RPC message to the connected mobile device 152. In this example, device link interface 172 sends the constructed RPC message to the connected mobile device 152. Mobile device 152 may process the RPC message as discussed in further detail with respect to processing 400.

[0051] In operation 312, computing platform 104 receives a response to the message from the connected mobile device 152. In this example, device link interface 172 receives the response as discussed in further detail with respect to processing 400. Device link interface 172 may also send the received response RPC message to virtual interface plug-in 206. In operation 314, computing platform 104 decodes the response message. In this example, virtual interface plug-in 206 decodes the received message according to the type of connection provided by device link interface 172.

[0052] In operation 316, computing platform 104 writes a response message to the channel. In this example, virtual interface plugin 206 writes decoded message data to the channel. In operation 318, computing platform 104 reads a response message from the channel. In this example, virtual interface manager 204 reads decoded message data from the channel in response to a data request from connected vehicle application 110. In operation 320, vehicle application 110 of computing platform 104 receives the response message. Accordingly, vehicle application 110 can utilize the network services of the connected mobile device via RPC, even if the mobile device 152 itself does not support the requested network service. After operation 320, processing 300 ends.

[0053] Figure 4An exemplary process 400 for assisting vehicle application 110 in using the network connectivity of mobile device 152 is illustrated. In the example, process 400 may be executed using virtual network mobile application 208 of mobile device 152.

[0054] In operation 402, mobile device 152 receives a message from connected vehicle 102 via RPC. In this example, the message may be sent to device link application core 174 in response to the sending process discussed above with respect to operation 310 of process 300. In operation 404, mobile device 152 decodes the message. In this example, IP data manager 210 of virtual network mobile application 208 receives the RPC message from device link application core 174 and decodes the binary packet data from device link application core 174. IP data manager 210 may also be configured to send the received IP packet data to agent 212.

[0055] In operation 406, mobile device 152 uses mobile device 152 as the source address to create a message. In this example, agent 212 may update the source address of the message to the address of mobile device 152, instead of updating it to the address of computing platform 104. In operation 408, mobile device 152 sends the message to its destination. In this example, agent 212 creates a socket and writes the message to the physical network interface 214 of mobile device 152. This updated message can then be sent from mobile device 152 to the destination address via physical network interface 214.

[0056] In operation 410, mobile device 152 receives a response message. In this example, a response to the packet can be sent back to the physical network interface 214 of mobile device 152. The response packet can then be forwarded to the virtual network mobile application 208. In operation 412, mobile device 152 uses the vehicle as the destination address to create a message. In this example, agent 212 uses the address information of computing platform 104 to update the response packet and returns the response packet to IP data manager 210. In operation 414, mobile device 152 constructs a response message for the RPC. In this example, IP data manager 210 constructs a binary representation and forwards the binary representation to device link application core 174.

[0057] In operation 416, mobile device 152 sends a response message to computing platform 104 of connected vehicle 102 via RPC. The response message can be received by computing platform 104 as discussed above with respect to operation 312. After operation 416, processing 400 ends.

[0058] Variations of the above system and processing are feasible. In the example, computing platform 104 can query mobile device 152 for protocols supported by mobile device 152 itself. Based on the query results, if mobile device 152 cannot support the protocol requested by vehicle application 110, then the above processes 300 and 400 can be used. However, if mobile device 152 does have the capability to support the protocol itself, then a request for mobile device 152 to utilize its own capabilities can be sent, avoiding channel and proxy operations. As a specific example, mobile device 152 can respond indicating that mobile device 152 supports HTTP but not MQTT or File Transfer Protocol (FTP). Therefore, HTTP requests for data can be sent to mobile device via RPC so that mobile device 152 can retrieve the requested data using its own web browser and then send the requested data back once retrieved. However, FTP or MQTT requests can be channeled and processed using mobile device 152 as a proxy.

[0059] The computing devices described herein, such as computing platform 104, mobile device 152, and telematics server 162, generally include computer-executable instructions that can be executed by one or more computing devices such as those described above. Computer-executable instructions such as virtual network interface application 202 or virtual network mobile application 208 can be compiled or interpreted from computer programs created using individual or combined programming languages ​​and / or technologies, including but not limited to: Java. TM The languages ​​used include C, C++, C#, Visual Basic, JavaScript, Python, Perl, PL / SQL, Prolog, LISP, Corelet, etc. Generally, a processor (e.g., a microprocessor) receives instructions from, for example, memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including the one or more processes described herein. Various computer-readable media can be used to store and transmit such instructions and other data.

[0060] Regarding the processes, systems, methods, teachings, etc., described herein, it should be understood that although the steps of such processes are described as occurring in a specific ordered order, such processes can be implemented using steps performed in an order other than that described herein. It should also be understood that specific steps may be performed simultaneously, other steps may be added, or specific steps described herein may be omitted. In other words, the description of the processes herein is provided for the purpose of illustrating specific embodiments and should not be construed as limiting the claims in any way.

[0061] Accordingly, it should be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications beyond the examples provided will become apparent when reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the claims and the full scope of their equivalents. It is anticipated and planned that future developments will occur in the art described herein, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and changes are possible with this application.

[0062] Unless expressly indicated otherwise herein, all terms used in the claims are intended to be given their broadest and most reasonable interpretation as understood by one skilled in the art described herein, and their general meaning. Specifically, unless the claims describe an express limitation to the contrary, the use of singular articles such as “a,” “the,” “the,” etc., should be understood to describe one or more elements of the designation.

[0063] This summary of the specification is provided to allow the reader to quickly determine the essence of the technical disclosure. It is understood accompanying this submission that the summary will not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing detailed description, multiple features are combined in multiple embodiments for the purpose of simplifying this disclosure. The method of this disclosure should not be construed as reflecting an intention to claim that the embodiment requires more features than are clearly recited in each claim. Rather, as reflected in the claims, the subject matter of the invention lies in fewer than all features of a single disclosed embodiment. Therefore, the claims are hereby incorporated into the detailed description, wherein each claim exists independently as a separate claimed subject matter.

[0064] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the invention. Rather, the terms used in this specification are descriptive rather than restrictive, and it should be understood that various changes can be made without departing from the spirit and scope of the invention. Furthermore, features of various implementations can be combined to form further embodiments of the invention.

Claims

1. A system for implementing a virtual network interface connection, comprising: a mobile device configured to: receive a message from a vehicle computing platform via a remote procedure call; update a source address of the message to indicate the mobile device; send the message to a destination address of the message with the source address updated; receive a response message from the destination address; update a destination address of the response message to indicate the vehicle computing platform; send the response message to the vehicle computing platform via the remote procedure call with the destination address updated.

2. The system of claim 1, wherein, the message is sent from a vehicle application executed by the vehicle computing platform and the vehicle application communicates via one or more of message queue telemetry transfer protocol, file transfer protocol, and hypertext transfer protocol.

3. The system of claim 1, wherein, the source address and the destination address are internet protocol addresses.

4. The system of claim 1, wherein, the remote procedure call is executed according to a smart device link protocol.

5. The system of claim 1, wherein, the mobile device includes a proxy configured to update the source address of the message and to update the destination address of the response message.

6. The system of claim 1, wherein, the mobile device includes a data manager configured to: translate the message from a format of the remote procedure call to a format for communication over a communication network to the destination address; translate the response message from the format for communication over the communication network to the format of the remote procedure call.

7. The system of claim 1, further comprising: a computing platform configured to: for a request received from the vehicle application for a network protocol not supported by the mobile device, construct a remote procedure call message by a virtual network interface application; send the remote procedure call message to the mobile device to cause the mobile device to update a source address of the request to indicate the mobile device and to send the request to a destination address of the request with the source address updated.

8. The system of claim 7, wherein, the computing platform is further configured to: query the mobile device in the mobile device for network protocols supported by the mobile device itself; identify network protocols not supported by the mobile device according to the query.

9. The system of claim 7, wherein, the computing platform is further configured to: receive another request from another vehicle application for another network protocol supported by the mobile device; send the other request to the mobile device for processing by an application of the mobile device corresponding to the other network protocol.

10. The system of claim 7, wherein, the computing platform is further configured to: receive a response to the request from the mobile device; send the response to the vehicle application.

11. The system of claim 10, wherein, the computing platform is further configured to receive from the mobile device an indication of network conditions provided by a physical network interface of the mobile device to a communication network through which the destination address is reached.

12. A method for implementing a virtual network interface connection, comprising: receiving, by a computing platform, an indication from a mobile device of network protocols supported by the mobile device itself; receiving a request from a vehicle application utilizing a network protocol; in response to the network protocol utilized by the vehicle application being supported by the mobile device itself, sending the request to the mobile device for processing by a native application of the mobile device; in response to the network protocol utilized by the vehicle application not being supported by the mobile device itself, sending the request to the mobile application using a proxy method, wherein the proxy method comprises: creating a remote procedure call message through a virtual network interface application; sending the remote procedure call message to the mobile device to cause the mobile device to update a source address of the request to indicate the mobile device and send the request to a destination address of the request with the source address updated.

13. The method of claim 12, further comprising: The remote procedure call is performed according to a smart device link protocol.

14. The method of claim 13, further comprising: receiving a response to the request from the mobile device; sending the response to the vehicle application.

Images