Method and apparatus for remote vehicle function control

Abstract

The present disclosure relates to a method and apparatus for remote vehicle function control. A system includes a processor configured to wirelessly communicate with a mobile device application. The processor is further configured to receive vehicle commands from the mobile device application and transmit wireless instructions to a vehicle, the wireless instructions indicating an action corresponding to and responsive to the received vehicle commands.

Description

Technical Field

[0001] The illustrative embodiments generally relate to methods and apparatus for remote vehicle function control. Background Art

[0002] Vehicle ignition and entry systems have come a long way over the past few decades. Previously requiring the use of a key, these systems now typically require only the touch of a hand or finger to function, provided a key fob is present. Key fobs, which used to provide push-button unlocking (on the key fob) and sometimes remote start or entry functionality (also accessed on the key fob), now typically include technology that allows a user to access multiple aspects of the vehicle based on user / vehicle interaction while the key fob is in the user's pocket or purse.

[0003] While the vehicle interaction and key fob presence model is certainly more convenient than having to find the key fob in a pocket or purse to access vehicle functions, many people still feel that the key fob represents another inconvenient device that they have to carry and / or potentially lose.

[0004] A proposed alternative to the key fob model is to use the phone as a key model, where the phone itself has native key fob functionality or app-driven key fob functionality. However, for various reasons, this has proven to be a rather difficult solution to implement in practice, and no attractive, viable, large-scale replacement for key fobs has yet to be found. Summary of the Invention

[0005] In a first illustrative embodiment, a system includes a processor configured to wirelessly communicate with a mobile device application. The processor is further configured to receive a vehicle command from the mobile device application and send wireless instructions to a vehicle indicating an action corresponding to and responsive to the received vehicle command.

[0006] In a second illustrative embodiment, a system includes a mobile device processor configured to detect the presence of a key fob device configured for communication with a mobile device application executed by the mobile device processor. The mobile device processor is further configured to present a set of vehicle functions controllable by the key fob device, receive a selection of a vehicle function, and send a wireless command corresponding to the vehicle function to the key fob device.

[0007] According to the present invention, a system is provided, comprising a mobile device processor configured to: detect a wireless connection advertised from a remote key device, the remote key device being configured for communication with a mobile device application executed by the mobile device processor; wirelessly connect using the advertised wireless connection; after connecting to the remote key device, present a group of vehicle functions controllable by the remote key device; receive a selection of a vehicle function on a mobile device; and send a wireless instruction corresponding to the selected vehicle function to the remote key device.

[0008] According to one embodiment of the present invention, the vehicle function database is on a mobile device.

[0009] According to one embodiment of the present invention, the vehicle function database is remote from the mobile device.

[0010] In a third illustrative embodiment, a computer-implemented method includes storing a plurality of vehicle control credentials corresponding to a plurality of vehicles on a local memory of a remote key device. The method further includes wirelessly receiving an instruction from a mobile device to select one of the plurality of vehicles; and providing vehicle control functionality using the control credentials corresponding to the selected vehicle, such that only the selected vehicle is controllable by the remote key device until a new instruction is received from the mobile device to select another vehicle from the plurality of vehicles.

[0011] According to one embodiment of the present invention, the remote key device includes a Passive Entry Passive Start (PEPS) function, and the method further includes providing the PEPS function only to the selected vehicle until a new instruction for selecting another vehicle of the plurality of vehicles is received from the mobile device.

[0012] According to an embodiment of the present invention, the method further comprises: in response to a request for the list of the plurality of vehicles from the mobile device, providing the list from the remote control key device to the mobile device.

[0013] According to one embodiment of the present invention, the method further includes: receiving a control command corresponding to a vehicle function controllable by the remote control key device from a mobile device at the remote control key device; and sending an instruction for instructing the control of the vehicle function from the remote control key device to the selected vehicle based on the received control command. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 An illustrative vehicle computing system is shown;

[0015] Figure 2A An illustrative example of a vehicle control process performed on a mobile device is shown;

[0016] Figure 2B An illustrative example of a remote key fob command relay process is shown;

[0017] Figure 3A An illustrative process for a key fob control presentation process executed on a mobile device is shown;

[0018] Figure 3B An illustrative example of a remote key fob control query response process is shown;

[0019] Figure 3C An alternative example of a key fob control presentation process executed on a mobile device is shown;

[0020] Figure 4A An illustrative example of a key fob vehicle selection process executed on a mobile device is shown;

[0021] Figure 4B An illustrative example of a key fob setup process is shown. DETAILED DESCRIPTION

[0022] As required, specific embodiments are disclosed herein; however, it will be understood that the disclosed embodiments are merely illustrative and may be embodied in various and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to illustrate details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the claimed subject matter.

[0023] Figure 1 An example block diagram of a vehicle-based computing system (VCS) 1 for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by Ford Motor Company. A vehicle equipped with a vehicle-based computing system may include a visual front-end interface 4 located within the vehicle. If the interface is provided with, for example, a touch-sensitive screen, a user may also be able to interact with the interface. In another illustrative embodiment, interaction occurs through button presses or a spoken dialogue system with automatic speech recognition and speech synthesis.

[0024] exist Figure 1In the illustrated illustrative embodiment 1, processor 3 controls at least a portion of the operation of a vehicle-based computing system. The processor, located within the vehicle, allows for onboard processing of commands and routines. Additionally, 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. Generally speaking, persistent (non-temporary) memory can include all forms of memory that retain data when a computer or other device loses power. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0025] The processor is also provided with a number of different inputs that allow the user to interact with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which may be a touchscreen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between the various inputs. Inputs from both the microphone and the auxiliary connector are converted from analog to digital by a converter 27 before being transmitted to the processor. Although not shown, the various vehicle components and auxiliary components that communicate with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to transmit data to and from the VCS (or its components).

[0026] The outputs of the system may include, but are not limited to, a visual display 4 and a speaker 13 or 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. Outputs may also be generated to a remote Bluetooth device (such as a personal navigation device (PND) 54) or a USB device (such as a vehicle navigation device 60) along the bidirectional data streams shown at 19 and 21, respectively.

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

[0028] Exemplary communication between the nomadic device and the Bluetooth transceiver is represented by signal 14 .

[0029] The nomadic device 53 may be instructed to pair with the Bluetooth transceiver 15 via a button 52 or similar input. Accordingly, the CPU is instructed that the onboard Bluetooth transceiver will pair with the Bluetooth transceiver in the nomadic device.

[0030] Data may be transferred between the CPU 3 and the network 61 using, for example, a data plan associated with the nomadic device 53, data over voice, or DTMF tones. Optionally, it may be desirable to include an onboard modem 63 having an antenna 18 to transfer data (16) between the CPU 3 and the network 61 over the voice band. The nomadic device 53 may then be used to communicate (59) with the network 61 outside the vehicle 31, for example, by communicating (55) with a cellular tower 57. In some embodiments, the modem 63 may establish communication 20 with the cellular tower 57 to communicate 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.

[0031] In one illustrative embodiment, the processor is provided with an operating system including an API (application programming interface) for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (such as found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. 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 within vehicles. Other communication methods that can be used in this field are free space optical communication (such as IrDA) and non-standardized consumer infrared (IR) protocols.

[0032] In another embodiment, the nomadic device 53 includes a modem for voice-band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing (FDM) can be implemented, allowing the owner of the nomadic device to speak through the device while data is being transferred. At other times, when the owner is not using the device, data transfer can utilize the entire bandwidth (300 Hz to 3.4 kHz in one example). While FDM may have been common for analog cellular communications between the vehicle and the internet and is still used, it has largely been replaced by a mix of code domain multiple access (CDMA), time domain multiple access (TDMA), and spatial domain multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the nomadic device, the data plan may allow for broadband transmission, and the system can utilize a much wider bandwidth (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 nomadic device (ND) 53 may be a wireless local area network (LAN) device capable of communicating over, for example (but not limited to), an 802.11g network (i.e., Wi-Fi) or a WiMax network.

[0033] In one embodiment, incoming data may pass through the nomadic device via a data-over-voice or data plan, through the onboard Bluetooth transceiver, and into the vehicle's internal processor 3. For example, in the case of certain temporary data, the data may be stored on a HDD or other storage medium 7 until the data is no longer needed.

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

[0035] Additionally, the CPU may communicate with various other auxiliary devices 65. These devices may be connected via wireless connections 67 or wired connections 69. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless healthcare devices, portable computers, and the like.

[0036] Additionally or alternatively, the CPU may be connected to a vehicle based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) transceiver 71. This may allow the CPU to connect to a remote network while within range of the local router 73.

[0037] In addition to the example processes being performed by a vehicle computing system located in the vehicle, in certain embodiments, the example processes may also be performed by a computing system in communication with the vehicle computing system. Such systems may include, but are not limited to, wireless devices (e.g., but not limited to, mobile phones) or remote computing systems (e.g., but not limited to, servers) connected via wireless devices. Such systems may be collectively referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform specific portions of the processes depending on the specific implementation of the system. By way of example and not limitation, if a process includes a step for sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform that portion of the process because the wireless device does not "send and receive" information with itself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0038] In each of the illustrative embodiments discussed herein, exemplary, non-limiting examples of processes that may be performed by a computing system are shown. For each process, the computing system performing the process may become a dedicated processor configured to perform the process for the limited purpose of performing the process. Not all processes need be performed, and are understood to be examples of various types of processes that may be performed to implement elements of the present invention. Additional steps may be added to or removed from the exemplary processes as needed.

[0039] With respect to the illustrative embodiments described in the accompanying figures showing illustrative process flows, it should be noted that a general-purpose processor can be temporarily used as a special-purpose processor for the purpose of performing some or all of the exemplary methods illustrated by these figures. While executing code providing instructions for performing some or all of the steps of the described methods, the processor can be temporarily repurposed as a special-purpose processor until the method is completed. In another example, to the extent appropriate, firmware running on a pre-configured processor can cause the processor to function as a special-purpose processor provided for the purpose of performing the described method or some reasonable variation of the described method.

[0040] While using a phone as a key alone may be difficult to implement due to various considerations that make it difficult to utilize a device (such as a phone) over which the vehicle original equipment manufacturer (OEM) has little control as a vehicle ignition device, the illustrative embodiments do provide functionality on a phone or other mobile device that allows a user to interact with the phone and effectively utilize various aspects of the key fob functionality. In an illustrative example, a portable device, such as a credit card-sized device (or other similar portable device), that may be provided by the vehicle OEM includes key fob-like transmission capabilities. That is, the device can be used for unlocking purposes based on the presence of the device, and for ignition starting purposes based on the presence of the device, for example. This can generally function in the same manner as the presence of a physical key fob.

[0041] In one illustrative example, the phone housing includes electrical connections and a receiving bay for a remote key fob device. If the remote key fob device is, for example, card-shaped, the device can be clipped, ejected, or slid into a receiving bay located on the rear of the housing or within the housing. The housing can have an independent power source, and the remote key fob itself can also have a power source such as a button battery. Securing the remote key fob to the housing allows it to be powered through the housing, from a phone attached to the housing, or, if neither the phone nor the housing can provide sufficient power, using the remote key fob's own power.

[0042] One aspect of the illustrative embodiments allows a remote key fob (illustratively referred to as a key fob, but not limited to a card shape or form) to function as a presence device for multiple vehicles. That is, a user can use the device as a proxy for a key fob to enable touch unlock and touch start for multiple different vehicles. In this example, the key fob learns security sequences for multiple vehicles and stores the necessary authentication data for these vehicles on the key fob. The user can use a mobile device interface (such as provided by a smartphone in communication with the key fob) to select a specific vehicle for which the key fob will be enabled. In this example, the key fob is then configured to interact with the selected vehicle, and interacting with a different stored vehicle requires the user to select a new vehicle via the interface.

[0043] Since the key fob may not have physical controls (lock / unlock / start / trunk, etc.) located on it and can simply serve as a presence device for vehicle interaction in the absence of a control device, smartphone app, or other similar device application, it can act as a proxy for the typical in-vehicle controls of a traditional key fob. That is, for a selected vehicle, the phone app can present a typical set of key fob controls, or even advanced controls not typically found on a key fob, as more interface space is available. Pressing a control selection causes the phone to communicate with the key fob, which then communicates with the vehicle. This maintains the security features associated with the key fob's own vehicle communications (provided by the vehicle manufacturer) while still allowing the phone to effectively control the vehicle.

[0044] This doesn't mean there's no security between the phone and the key fob, and certain apps might require a password or other encrypted protocol to access the key fob. This would prevent a user standing near another user's key fob from accessing it. However, in a model where the key fob sends commands to the vehicle, responding to instructions from a phone app, the manufacturer doesn't need to expose the key fob's own security features / protocols to any security vulnerabilities that might exist on the phone, over which the manufacturer has little or no control. Furthermore, in this scenario, even if the phone were hacked, someone wouldn't be able to replicate the vehicle access protocols from the phone. At most, they might be able to use the key fob through a secondary device, which still requires the card to be present to access vehicle controls or features.

[0045] In another example, a key fob may have physical controls and even LEDs (light-emitting diodes) mounted thereon. This allows the key fob to function as a physical device similar to a traditional key fob, even in the absence of a housing or phone. Using the phone, the user can select which of a set of programmed vehicles the key fob will currently control. Subsequently, when the key fob is disconnected and not communicating with the phone, the key fob can save the settings for that specific vehicle and function as a key fob for that selected vehicle. In this model, each time the key fob is re-paired with an approved phone, the phone can be used to select a different vehicle to control. LED indicators on the key fob can indicate connection status, command success, pairing mode, and even the currently selected vehicle (for example, if there are four LEDs, each LED can correspond to one of the four vehicles, and pressing a key fob button can cause the correct LED for the currently selected vehicle to flash, indicating which vehicle the key fob is currently configured for).

[0046] In one example, a mobile device application can be used to command key fob functions via the mobile device. In this example, the key fob can actually connect to the vehicle via a wireless protocol (such as BLE), which can provide the phone with additional functionality beyond that of a traditional key fob. That is, a traditional key fob can control the locks, tailgate, and remote start, but because the key fob can send BLE commands (when connected), the phone can provide the user with additional commands (e.g., window control), and selection of a command will cause the phone to relay the command to the vehicle via the key fob via the wireless connection.

[0047] Figure 2A An illustrative example of a vehicle control process executed on a mobile device is shown. In this illustrative example, the control process is executed as an application on the mobile device or a similar portable device that includes a user interface. This may include, but is not limited to, a tablet computer, a smartwatch, or even a portable computer.

[0048] At 201, a user launches a control application, which in this example provides control of vehicle key fob functions using communication with the vehicle facilitated by the key fob. That is, commands are not sent directly from the phone to the vehicle, but rather commands are sent to the key fob, which then appropriately instructs the vehicle to take appropriate actions in response to the commands from the application.

[0049] In this example, after the app is launched, at 203 , the app seeks communication with a key fob or similar device. In at least one example, the similar device may be the key fob itself, which may be provided with the multi-vehicle functionality described herein, but in other examples, the device may be a device (e.g., a card, a housing, etc.) that can be more easily integrated with the phone as needed. Once the key fob is detected, the process exchanges any necessary security credentials with the key fob, and then at 205 , the process provides a set of controls corresponding to the user-selectable key fob functionality. In another example, the key fob may be paired with the phone, such that launching the app will cause the phone to communicate with the already paired key fob. Pairing may require placing the phone and / or key fob in pairing mode and having the key fob advertise a BLE connection (e.g., a BLE connection that can be accepted by the phone).

[0050] In one example, these controls include more common key fob controls (such as lock, unlock, alarm, remote start, and trunk release). Even if the key fob device includes local functions controllable via traditional key fob controls (e.g., buttons), the phone may also include a more advanced set of controls than the typical key fob control set. Thus, as needed, a wider range of controls can be achieved via the phone than can be achieved using the key fob alone. On the other hand, even if the key fob does not include local controls, once a vehicle is selected by the phone, the key fob can provide local Passive Entry Passive Start (PEPS) functionality for that vehicle. This means that even a buttonless key fob, once configured, can be used to start the vehicle without the control device (phone). This allows the user to provide the key fob as a loaner to a friend or child, and the borrower can still access and start the vehicle just as if they had a traditional key fob.

[0051] In this example, once the user selects a specific key fob function on the phone interface at 207, the process sends the command to the key fob at 209, which is then responsible for transmitting the command to the vehicle. Different command functions may be available for different vehicles controllable by a single key fob, and the configuration of command / control menus is discussed later in this document. If a single menu with all possible commands is provided and the specific vehicle selected lacks the indicated function (e.g., sunroof open, and the vehicle does not have a sunroof), the selectable option will simply inform the user that the option is not available for the selected vehicle, or make the option unselectable (even if displayed).

[0052] An application running on a mobile device can provide various functions when wirelessly interacting with the key fob. For example, and not limitation, the application can allow for changing profiles, requesting the vehicle assigned to a profile slot (or identifying an empty slot), obtaining the current key fob battery status and active profile, disabling the key fob's remote keyless entry (RKE) or other functions, receiving and providing low key fob battery alerts, obtaining the key fob's wireless ID, enabling / disabling Bluetooth or other wireless notifications for the key fob, changing key fob timing parameters, and obtaining diagnostic parameters for the key fob. Some of these functions may require the mechanic / dealer to use special code in some cases, but any or all of these functions can be provided to the user as needed.

[0053] For example, an app can be used to disable RKE commands on a key fob (such as commands corresponding to buttons included on the key fob). This disabling can also occur when the key fob is connected to the phone case, which can help prevent accidental button activation while the case is in the user's pocket. If RKE has been automatically disabled, detaching the key fob can cause the RKE functionality to be enabled. If RKE is manually disabled (via the app), the disabling can persist until RKE is manually re-enabled. In another example, if RKE is manually disabled, it can be re-enabled if the BLE connection is lost, rather than if the key fob is disconnected from the case (which could also cause re-enabling). This model (re-enabling when the wireless connection is lost) allows the user to still use the key fob functionality even if the phone and / or case batteries are dead.

[0054] Another application function can cause the key fob to flash an LED in response to a request. This can help identify which key fob is paired with which phone if multiple key fobs are present (for example, multiple key fobs on a coffee table at home). To preserve battery life, the key fob may not always announce a connection when it is not already connected. Pressing a button on the key fob (perhaps for a longer than normal duration) can cause the key fob to enter pairing / announcement mode. This can be accomplished without providing a different button, using a button press pattern that requires a longer press or buttons normally reserved for key fob control functions. An LED on the key fob can indicate whether the key fob is in announcement mode or pairing mode.

[0055] Figure 2B An illustrative example of a key fob command relay process is shown. In this example, at 211, the key fob / device receives a command from an authenticated phone application. Subsequently, at 213, the device accesses the security protocol necessary to authenticate the command for the selected vehicle. This is useful if more than one vehicle can be controlled by the key fob; otherwise, a single local security protocol can be used when only one vehicle can be controlled by the key fob. The key fob then transmits instructions corresponding to the phone command to the vehicle at 215.

[0056] Figure 3A An illustrative process for a key fob control presentation process executed on a mobile device is shown. In this example, an application executing on the mobile device communicates with a key fob that includes control capabilities for more than one vehicle. Alternatively, or additionally, the application may be authorized to communicate with multiple different key fobs, each of which may also include various vehicle functions depending on the specific vehicle controlled by the specific key fob.

[0057] Once the process detects the key fob and exchanges any necessary security authentication at 301, the process sends a query to the key fob to determine the functionality corresponding to the currently selected vehicle at 303. For example, if the key fob controls vehicle A and vehicle B and only vehicle B has heated seats, the functionality presented on the app may include heated seat controls only if vehicle B is the selected vehicle to be controlled by the key fob.

[0058] At 305, the key fob responds to the query with the set of controllable functions, or at least an additional set of controllable functions if a specific function (e.g., lock / unlock / start / trunk) is assumed. The process then configures the application control menu at 307, which may include adding or removing specific functions or enabling / disabling specific functions. The configuration may even include specific reporting functions. For example, if vehicle B above is able to report temperature to the key fob but vehicle A is not, the menu for vehicle B may include an interior temperature reporting display that will be removed or disabled if the user selects vehicle A as the controllable vehicle.

[0059] In other models, the phone may have pre-stored commands associated with specific vehicle identifiers and / or fobs. Querying the fob may yield a fob identifier (which can be used to select from a plurality of fobs known to the phone) and a vehicle identifier (which can be used to select from a plurality of vehicle command sets associated with the identified fob). Alternatively, any of these identifiers may be returned individually and / or responsively in response to different queries.

[0060] Figure 3B An illustrative example of a remote key fob control query response process is shown, and in this example, the remote key fob receives a request from a phone application at 311, and the remote key fob responds with an identified set of controllable functions / reporting options at 313. As described above, the remote key fob may also respond with a vehicle identifier and / or a remote key fob identifier, and as described below with reference to Figure 3C As shown, the phone can simply look up (either on-board the vehicle or remotely) the commands associated with the identified key fob / vehicle.

[0061] Figure 3C An alternative example of a key fob control presentation process executed on a mobile device is shown. In this example, the phone detects the key fob at 321 and receives an identification of the vehicle selected for the key fob controls at 323. The receipt of the identification can be a message from the key fob, or it can be a selection made by the phone and / or a selection previously saved by the phone.

[0062] In this example, the phone uses a lookup to find out which controls are included for the remote key card functionality for the selected vehicle. This may include a lookup 325 on a local database that stores the various vehicle control configurations on the phone, or a query to a remote source (OEM server or other remote data set). Using this data, the process then configures the menu 327 in a manner similar to that discussed above.

[0063] Figure 4A An illustrative example of a key fob vehicle selection process performed on a mobile device is shown. In this example, at 401, the process detects a key fob, which in this example may be configured to control multiple different vehicles. Authentication data for each vehicle may be stored on the key fob and / or obtained through a process (such as a copy process from an existing vehicle key fob) or in collaboration with the vehicle itself. Key fob authentication copying can be accomplished in a variety of ways, and the particular way selected does not affect the scope of the invention as a whole. The key fob itself may have a limit on the number of vehicles that can be stored locally, and before that limit is reached, a phone may be used in the copy process to select an unassigned control set. If a vehicle limit exists and has been reached, the phone may also be used to select a control set for overwriting.

[0064] Once the phone app has authenticated itself with the key fob, the phone sends a request to the key fob to find out which vehicles can be controlled by the key fob based on the data currently stored on the key fob 403. This data may have been configured through the phone app or stored locally on the phone after configuration, but in cases where multiple phone apps can interact with a reconfigurable key fob, it may be useful to be able to obtain this information from the key fob itself.

[0065] At 405, the phone receives the vehicle identifier (VIN, ESN, or other suitable identifier) from the key fob, and if a serial number or other alphanumeric identifier is used, it is typically presented to the user in a more understandable format at 407. That is, instead of displaying XX224XFR and XY332GGE, the phone might display FORD EXPLORER and FORD FOCUS. The user can also save vehicle names on the key fob or on the phone, so that the user sees MOM'S EXPLORER and ALEXA'S FOCUS instead of FORD EXPLORER and FORD FOCUS. If these names are stored on the key fob, they can be returned instead of or in addition to the VIN / ESN / identifier data. If the phone uses a lookup to identify specific vehicle features accessible via a specific key fob setup, both types of data may be expected.

[0066] The process then receives a user selection of a specific vehicle to be controlled by the key fob at 409 and sends instructions to the key fob to configure itself to control the selected vehicle at 411. In this example, once configured, the key fob or other key fob device can then be loaned or transferred to another user for at least PEPS functionality. If the application utilizes a transferable authentication process, the borrower may also receive a password that grants the borrower limited key fob functionality on their own phone. This may include, for example, control functionality for the selected vehicle, but not the ability to select a new vehicle. Alternatively, in another example, a child may be able to select between the family SUV or sedan using a restricted password, but not access the family sports car. Tiered access permissions can be combined with different access credentials for configuring / controlling applications, allowing for various levels of security while still making basic PEPS and / or key fob functionality transferable through the loan of the key fob.

[0067] Figure 4BAn illustrative example of a key fob setup process is shown. In this example, at 421, the key fob first receives a query from the app requesting a list of selectable vehicles. As described above, if there is a hierarchy of access credentials, the key fob can limit this list to vehicles that are controllable by the key fob and that are also selectable by the specific user with the current credential set. Thus, for example, a child may not see a selection option for the family sports car because the key fob does not return it as a selectable option for the child's credential set provided by the child's phone app. An alternative approach would be to return all vehicles but block requests for vehicles that are not authorized for a specific credential set. Regardless of the specific example selected, in this example, at 423, the key fob returns some form of user-selectable vehicle group (one or more user-selectable vehicles).

[0068] Next, at 425, the process receives the user's vehicle selection from the application. If necessary, the key fob can check for permission to access the requested vehicle controls, but multiple options are available that do not directly require the key fob to block the request (not returning unauthorized vehicles, blocking control selection over the phone, etc.). Assuming the user is authorized to access the requested vehicle controls, the key fob then selects the security and communication credentials for the selected vehicle at 427 and sets itself up to control that vehicle. The key fob typically remains configured to control the selected vehicle, and only the selected vehicle, until a new vehicle is selected, but the key fob can also revert to a specific control group or an empty control group after a period of time for security purposes, as needed.

[0069] Through the illustrative embodiments, a reconfigurable, multi-vehicle key fob that can interact with a phone to provide phone-based key fob control is implemented. This greatly expands the convenience of the key fob while mitigating some of the security issues associated with direct phone-to-vehicle control.

[0070] While exemplary embodiments have been described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, the features of the various implementing embodiments may be combined in a logical manner to produce context-appropriate variations of the embodiments described herein.

Claims

1. A system for remotely controlling vehicle functions, comprising: A portable device processor configured to: wirelessly pairing with a mobile device; receiving, from a mobile device application executing on the mobile device, a selection of one of a plurality of vehicles controllable by the portable device processor; wirelessly receiving a vehicle command from the mobile device application; Wireless instructions are sent to the selected vehicle, the wireless instructions indicating an action corresponding to and responsive to the received vehicle command.

2. The system of claim 1, wherein: The portable device processor is included as part of the phone housing.

3. The system of claim 1, wherein: The portable device processor is included as part of a credit card shaped device.

4. The system of claim 1, wherein: The portable device processor is further configured to authenticate the mobile device application as permitted to control the plurality of vehicles.

5. The system of claim 1, wherein: The portable device processor is further configured to provide the mobile device requested function only to a selected one of the plurality of vehicles.

6. The system of claim 1, wherein: The portable device processor is further configured to provide the list of the plurality of vehicles to the mobile device application in response to a request from the mobile device application.

7. The system of claim 1, wherein: The portable device processor is further configured to provide, in response to a request from the mobile device application, a list of vehicle functions for a selected vehicle that are controllable by the portable device processor.

8. The system of claim 1, wherein: The portable device processor is further configured to provide passive entry passive start functionality when within a predefined proximity of a transponder of a selected vehicle.

9. A system for remotely controlling vehicle functions, comprising: A mobile device processor configured to: detecting a wireless connection advertised from a key fob device configured to communicate with a mobile device application executed by the mobile device processor; Connect wirelessly using the advertised wireless connection; After connection to the remote control key device, presenting a set of vehicle functions controllable by the remote control key device; receiving a selection of a vehicle function on the mobile device; A wireless command corresponding to the selected vehicle function is sent to the remote control key device.

10. The system of claim 9, wherein: The mobile device processor is further configured to: requesting, from the remote control key device, a list of vehicles controllable by the remote control key device; receiving, in response to the request, a list of the vehicles from the remote key device; Based on the received list, a list of selectable vehicles is presented.

11. The system of claim 10, wherein: The mobile device processor is further configured to: receiving a selection of a vehicle from the vehicle list; The identification of the selected vehicle is sent to the remote key device.

12. The system of claim 11, wherein: The mobile device processor is further configured to: requesting a remote control key identifier and an identifier of a currently activated vehicle from the remote control key device; receiving, via the wireless connection, a remote key identifier and an identifier of a currently activated vehicle; accessing a stored list of vehicles corresponding to the remote key identifier; accessing a command set corresponding to an identifier of a currently activated vehicle according to the vehicle list; Based on the accessed command set, the group of vehicle functions is presented.

13. The system of claim 11, wherein: The mobile device processor is further configured to: accessing a vehicle function database to identify a vehicle function controllable by the remote key device and corresponding to the selected vehicle; The vehicle function group including at least the vehicle function identified by the identification of the vehicle function is presented.

14. A method for remotely controlling a vehicle function, comprising: storing a plurality of vehicle control credentials corresponding to a plurality of vehicles in a local memory of the remote key device; wirelessly receiving an instruction from a mobile device, the instruction for selecting one of the plurality of vehicles; Vehicle control functionality is provided using the control credentials corresponding to the selected vehicle so that only the selected vehicle can be controlled by the remote key device until a new instruction is received from the mobile device to select another vehicle of the plurality of vehicles.

Images