System and method of low energy mobile device recognition

A method of car access includes receiving a localization secret at data processing hardware. The localization secret defines a portion of vehicle authentication information for a vehicle. The method also includes receiving at least one localization frame from a mobile device at the data processing hardware. The at least one localization frame includes identification information for the mobile device. The method further includes determining, by the data processing hardware, whether the at least one localization frame includes a derived localization secret. The derived localization is defined by the localization secret. The method further includes, when the at least one localization frame includes the derived localization secret, supplying, by the data processing hardware, power to a vehicle control module of the vehicle and authentication information to the vehicle control module of the vehicle.

TECHNICAL FIELD

This disclosure relates to vehicle access operations or more particularly to low energy mobile device recognition.

BACKGROUND

A mobile device, such as a smartphone, a smart watch, or a computer (e.g., a tablet, laptop, personal digital assistant, etc.), for example, can be used to communicate with a motor vehicle. For example, a mobile device can communicate with vehicle systems of the vehicle in order to access, diagnose faults, start/stop, or provide power to certain components or systems within the vehicle. In particular, a user may utilize a wireless communication protocol (e.g., short-range radio wave communication, Wi-Fi, BLUETOOTH®, BLUETOOTH® low energy (BLE), near field communication (NFC), etc.) to access or to operate the vehicle. For example, the operator may access or operate the vehicle by utilizing a wireless communication protocol controlled and powered by a mobile device.

Vehicles today may use Bluetooth low energy nodes as a wireless communication method to communicate with vehicle systems. As more and more vehicles begin to use Bluetooth low energy systems for vehicle access and vehicle operation, a user who operates the vehicle conveniently may use a mobile device to communicate with the vehicle systems via BLUETOOTH® or BLUETOOTH® low energy as the wireless communication protocol. Because many mobile devices may be within range of a Bluetooth low energy system for a vehicle, Bluetooth low energy vehicle systems may be susceptible to security threats, which can occur when one or more unauthorized mobile devices communicate with the vehicle. Unauthorized mobile devices may intercept, or otherwise receive, one or more wireless communications between a vehicle and an authorized mobile device. Unauthorized wireless communication may compromise the safety of the vehicle and the vehicle system because, for example, the vehicle may allow an unauthorized mobile device to unlock the doors on the vehicle or to start the engine of the vehicle. The vulnerability of the vehicle system may become even more complex when an owner of the vehicle wishes to grant or to manage privileges to more than one vehicle operator. For example, the owner of the vehicle is a car rental agency or a car share service. In this scenario, the owner of the vehicle only wants trusted users to have the capability to control functions of the vehicle. Unfortunately, the vehicle must, therefore, be able to constantly distinguish between mobile devices of trusted users and mobile devices of users who are not trusted. If the Bluetooth system of an adjacent mobile device is active, the adjacent mobile device broadcasts Bluetooth signals that may be heard or received by the Bluetooth system of the vehicle. Because the vehicle must constantly determine the status of users, the vehicle may consume costly amounts of power if the vehicle systems are active during this process. While known systems and methods for low energy mobile device recognition have proven acceptable for their intended purpose, a continuous need for improvement in the relevant art remains.

SUMMARY

One aspect of the disclosure provides a method of car access. The method includes receiving a localization secret at data processing hardware. The localization secret defines a portion of vehicle authentication information for a vehicle. The method also includes receiving at least one localization frame from a mobile device at the data processing hardware. The at least one localization frame includes identification information for the mobile device. The method further includes determining, by the data processing hardware, whether the at least one localization frame includes a derived localization secret. The derived localization is defined by the localization secret. The method further includes, when the at least one localization frame includes the derived localization secret, supplying, by the data processing hardware, power to a vehicle control module of the vehicle and authentication information to the vehicle control module of the vehicle.

Implementations of the disclosure may include one or more of the following optional features. In some implementations, when the at least one localization frame comprises the derived localization secret, the method updates, by data processing hardware, a white list with a device ID of the mobile device. The white list may contain device identifications (IDs) corresponding to known mobile devices. The method may also include determining, by data processing hardware, that the mobile device is not a respective known mobile device of the white list. Additionally or alternatively, the method includes determining, by the data processing hardware, that the mobile device is a respective known mobile device of the white list and validating at least one localization frame of the mobile device.

In some configurations, the method includes determining, by the data processing hardware, that a signal strength of a signal broadcasted by the mobile device corresponds to a wake-up proximity zone. Here, the wake-up proximity zone indicates a threshold distance of the mobile device from the vehicle acceptable to supply power to the vehicle control module of the vehicle based on signal strength. In some examples, the derived localization secret is derived from the localization secret. For example, the derived localization secret is cryptographically derived from the localization secret.

In some implementations, the method further includes determining, by the data processing hardware, whether the vehicle control module has requested receipt of the authentication information from the mobile device. When the vehicle control module has requested receipt of the authentication information from the mobile device, the method also includes establishing, by the data processing hardware, a connection with the mobile device.

Another aspect of the disclosure provides a system of car access. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that when executed on the data processing hardware cause the data processing hardware to perform operations. The operations include receiving a localization secret. Here, the localization secret defines a portion of vehicle authentication information for a vehicle. The operations also include receiving at least one localization frame from a mobile device. The at least one localization frame includes identification information for the mobile device. The operations further include determining whether the at least one localization frame includes a derived localization secret. The derived localization is defined by the localization secret. The operations further include, when the at least one localization frame includes the derived localization secret, supplying power to a vehicle control module of the vehicle and authentication information to the vehicle control module of the vehicle.

Implementations of the disclosure may include one or more of the following optional features. In some implementations, when the at least one localization frame comprises the derived localization secret, the operations further include updating a white list with a device ID of the mobile device. The white list may contain device identifications (IDs) corresponding to known mobile devices. The operations may also include determining that the mobile device is not a respective known mobile device of the white list. Additionally or alternatively, the operations include determining that the mobile device is a respective known mobile device of the white list and validating at least one localization frame of the mobile device.

In some configurations, the operations include determining that a signal strength of a signal broadcasted by the mobile device corresponds to a wake-up proximity zone. Here, the wake-up proximity zone indicates a threshold distance of the mobile device from the vehicle acceptable to supply power to the vehicle control module of the vehicle based on signal strength. In some examples, the derived localization secret is derived from the localization secret. For example, the derived localization secret is cryptographically derived from the localization secret.

In some implementations, the operations further include determining whether the vehicle control module has requested receipt of the authentication information from the mobile device. When the vehicle control module has requested receipt of the authentication information from the mobile device, the method also includes establishing, by the data processing hardware, a connection with the mobile device.

Optionally, a Bluetooth low energy communication node includes the data processing hardware. For instance, the Bluetooth low energy communication node defines a node within a Bluetooth low energy node network configured to communicate with the vehicle control module. In some configurations, the Bluetooth low energy communication node is a satellite node.

DETAILED DESCRIPTION

FIG. 1Ais an example of a Bluetooth low energy environment10for a vehicle12. The Bluetooth low energy environment10includes a backend entity14, a user16, and a mobile device18. The backend entity14is someone who is able to grant permission to use the vehicle12in any way. Some examples of a backend entity14include a car rental agency, a car sharing service, a used car seller, a vehicle manufacturer, or an individual owner of the vehicle12. The user16is a person who receives permission from the backend entity14to use the vehicle12in some way. The user16includes a mobile device18(e.g., cell phone, tablet, laptop, etc.) capable of communicating via Bluetooth protocol with the vehicle12. Bluetooth communications from the mobile device18enable the mobile device18to interact with various computers or electronic control units (ECUs) that sense and command modules throughout the vehicle12. As some examples, the ECUs may include modules such as an engine control module, a transmission control module, a body control module, a chassis control module, a safety module, an antitheft module, an airbag module, a cruise control module, a steering module, or a lighting module. To simplify for explanation, the mobile device18communicates with the vehicle12to perform vehicle applications like lighting, vehicle access (lock doors, unlock doors, open windows, etc.), or starting the vehicle12. To prevent unwanted users from controlling vehicle functions, the mobile device18of the user16is programmed with security and/or authentication credentials.

The Bluetooth protocol operates at a 2.4 GHz frequency. Bluetooth network design may include slave nodes and master nodes. Master nodes are generally capable of sending and receiving data from any connected slave node such that a master node may connect to more than one slave node. Slave nodes, on the other hand, are typically connected to a single master node and are configured to transmit to and receive from the connected master node. Bluetooth nodes may have bonded connections where bonded nodes automatically establish connection at a particular proximity or paired connections where a pairing process exchanges Bluetooth node information to permit bonding. Paired connections may be temporary or for a duration depending on a stored memory of either or both paired Bluetooth node. In some examples, master nodes are also referred to as main nodes while slaves nodes may be referred to as satellite nodes.

Referring furtherFIG. 1A, the backend entity14generates authentication information100. The authentication information100contains information for both the mobile device18of the user16and the vehicle12. The authentication information100is configured to validate the mobile device18; to enable the user16to perform vehicle functions permitted by the backend entity14; and to distinguish the mobile device18of the user16from other mobile devices that broadcast Bluetooth low energy signals within range of the vehicle12(e.g., other mobile devices adjacent to the vehicle12). The authentication information100includes at least a localization secret110, a derived localization secret112, a digital access key120, and/or encrypted authentication information130. The localization secret110is a cryptographic digital access key. From the localization secret110, the backend entity14generates a derived localization secret112to share with the user16(e.g., customer or permitted operator of the vehicle12). For example, the derived localization secret112is related to localization secret110such that the derived localization secret112may function as a type of possession factor authentication between the mobile device18that stores the derived localization secret112and the vehicle12. In some examples, the derived localization secret112is computed from or cryptographically derived from the localization secret110. The backend entity14sends the derived localization secret112and the digital access key120to the mobile device18of the user16while also sending the localization secret110and the encrypted authentication information130to the vehicle12.

FIGS. 1A-1Bdepict the vehicle12including a plurality of Bluetooth low energy nodes200, including at least one Bluetooth low energy main node200aand at least one Bluetooth low energy satellite node200b. Each Bluetooth low energy node200of the plurality of Bluetooth low energy nodes200is registered to the vehicle12when the vehicle12is outfitted with the Bluetooth low energy nodes200. For mobile device recognition, at least one of the Bluetooth low energy main node200aor the at least one Bluetooth low energy satellite node200bis configured for long-range Bluetooth low energy activity. As depicted byFIG. 1A, the at least one Bluetooth low energy main node200areceives the localization secret110from the backend entity14and stores the localization secret110.

FIG. 1Bis an example of the Bluetooth low energy environment10with multiple mobile devices18,18a-cnear the vehicle12. Each mobile device18,18a-ccorresponds to a potential user16,16a-cof the vehicle12. With multiple mobile devices18,18a-cnear the vehicle12, the vehicle12must distinguish the permitted mobile device (e.g.,18,18a) from the other mobile devices (e.g.,18,18b-c) that have not received permission from the backend entity14.

Each mobile device18,18a-cmay broadcast at least one Bluetooth low energy signal or at least one localization frame20. The at least one localization frame20includes device identification of the corresponding mobile device18,18a-cand the derived localization secret112if the broadcasting mobile device18contains the derived localization secret112. For example, in the case of a rental agency, the user16,16a(e.g., a licensee) enters into a contract with the backend entity14(e.g., rental agency). In the vehicle parking lot of the rental agency, people (e.g.,16,16b-c) besides the user16,16amay be adjacent to the vehicle12that the user16has rented such that the vehicle12must determine which adjacent mobile device (e.g.,18,18a-c) is the permitted mobile device (e.g.,18,18a) of the user16. Either the at least one main node200aor the at least one satellite node200bof the Bluetooth low energy nodes200may receive the at least one localization frame20from an adjacent mobile device (e.g.,18,18a-c). If at least one of the Bluetooth low energy nodes200receives the derived localization secret112, the at least one Bluetooth low energy main node200acommunicates with a secure authenticator300. AlthoughFIG. 1Bdepicts seven satellite nodes200band one main node200ain different locations in the vehicle12, any number of Bluetooth low energy nodes200may be configured in the vehicle12.

FIG. 1Cis an example Bluetooth low energy system environment10that includes multiple proximity zones Z1-Z3surrounding the vehicle12. Each proximity zone Z of the multiple zones Z1-Z3is a pre-configured zone of functionality. When the permitted mobile device18,18ais in a particular pre-configured zone of functionality, the secure authenticator300may wakeup and enable the permitted mobile device18,18ato perform a permitted vehicle function. For purposes of this disclosure, waking up the secure authenticator300means supplying power to the secure authenticator300and/or enabling the secure authenticator300to perform authentication functions and/or functions of the vehicle12. For example, if the permitted mobile device18,18ais in a first proximity zone Z1of the multiple proximity zones Z1-Z3, the secure authenticator300wakes up and enables the permitted mobile device18,18ato access the vehicle12and/or start the vehicle12. If the permitted mobile device18,18ais in a second proximity zone Z2of the multiple proximity zones Z1-Z3, the secure authenticator300wakes up and enables the permitted mobile device18,18ato solely access the vehicle12. If the permitted mobile device18,18ais in a third proximity zone Z3of the multiple proximity zones Z1-Z3, the permitted mobile device18,18ais unable to wake up the secure authenticator300because the third zone Z3is too far from the vehicle12. Thus, in this example, the first proximity zone Z1and the second proximity zone Z2are wake-up proximity zones where a distance of the mobile device from the vehicle is an acceptable distance to supply power to the secure authenticator300to wake-up the secure authenticator300and, depending on the proximity zone Z, perform other vehicle functions (e.g., access or starting). Although the pre-configured zones of functionality are illustrated inFIG. 1Cwith three proximity zones Z1-Z3, any number of proximity zones Zi-nmay be configured for various functionalities.

In some implementations, each proximity zone Z corresponds to a range of signal strength values acceptable to perform the programmed proximity zone Z function or functions. For example, each proximity zone Z has a signal strength threshold that demarcates whether a signal strength reading (i.e. measurement) is in a particular proximity zone Z or not in any proximity zone Z. In other words, each proximity zone Z may correspond to a range of signal strength values indicative of distance range from the vehicle of a mobile device emitting the signal. Merely for illustration, the first proximity zone Z1may have a signal strength range of X to Y (e.g., −55 dbm to −65 dBm) while the second proximity zone Z2may have a signal strength range of Y to Z (e.g., −65 dBm to −75 dBm). Here, the signal strength value of Y is the signal strength threshold that distinguishes whether the signal strength measurement is in the first proximity zone Z1or in the second proximity zone Z2.

With reference toFIG. 2A, interactions of the at least one Bluetooth low energy node200to detect an unknown mobile device18,18uwill now be described.

At step202, the at least one Bluetooth low energy main node200amay determine whether the Bluetooth low energy main node200ais connected with the backend entity14. If the Bluetooth low energy main node200ais connected with the backend entity14, the process may proceed to step204. Otherwise, the Bluetooth low energy main node200amay wait for a connection with the backend entity14. The connection between the Bluetooth low energy main node200aand the backend entity14may only need to occur once to transfer the localization secret110to initiate the user16. For example, the connection occurs when the backend entity14initially grants permissions related to the vehicle12to the user16. In other examples, the connection occurs during production or manufacturing of the vehicle12.

At step204, the Bluetooth low energy main node200amay receive the localization secret110of the authentication information100from the backend entity14. At step206, the Bluetooth low energy main node200adetermines if the Bluetooth low energy main node200ahas received at least one localization frame20while scanning for adjacent Bluetooth low energy signals. If the Bluetooth low energy main node200areceives at least one localization frame20, the process may proceed to step208. In some examples, the at least one Bluetooth low energy satellite node200bmay receive the at least one localization frame20and then relay the at least one localization frame20received by the at least one Bluetooth low energy satellite node200bto the at least one Bluetooth low energy main node200a. If neither Bluetooth low energy node200receives at least one localization frame20, the Bluetooth low energy nodes200wait for at least one localization frame20to be received.

At step208, the Bluetooth low energy main node200averifies the accessibility of the mobile device18that sent the received at least one localization frame20. To verify accessibility, the Bluetooth low energy main node200amay perform steps210-212. At step210, the Bluetooth low energy main node200adetermines if the mobile device18corresponding to the received at least one localization frame20is listed on a white list. The white list is a list that contains confirmed device identifications corresponding to a known mobile device18,18kof the vehicle12. If the Bluetooth low energy main node200adetermines that the mobile device18is a known mobile device18,18kof the white list, the Bluetooth low energy main node200aperforms operations depicted by steps224-232ofFIG. 2B. Otherwise, if the at least one localization frame20corresponding to an unknown mobile device18,18u, at step212, the Bluetooth low energy main node200adetermines if the at least one localization frame20received by the Bluetooth low energy main node200acontains the derived localization secret112generated by the backend entity14. If the Bluetooth low energy main node200adetermines that the at least one localization frame20validly contains the derived localization secret112, the process may continue to step214. Otherwise, the Bluetooth low energy main node200acontinues to wait for the receipt of localization frames20that may contain the derived localization secret112.

At step214, the Bluetooth low energy main node200awakes up the secure authenticator300. The secure authenticator300may be any control module of the vehicle12configured to perform vehicle functions based on the authentication information100programmed by the backend entity14. The disclosed processes seek to limit or to minimize an amount time the secure authenticator300is awake in order to conserve power for the vehicle12. Once the secure authenticator300is awake, the Bluetooth low energy main node200a, at step216, determines whether the secure authenticator300has requested the Bluetooth low energy main node200ato receive authentication information100from the unknown mobile device18,18uwith the derived localization secret112. If the Bluetooth low energy main node200ahas been requested to receive authentication information100from the unknown device18,18u, the Bluetooth low energy main node200arequests to connect to the unknown mobile device18,18uand, if successful, receives authentication information100from the unknown mobile device18,18u. If the Bluetooth low energy main node200areceives authentication information100from the unknown mobile device18,18u, the Bluetooth low energy main node200a, at step218may forward the authentication information100to the secure authenticator300.

At step220, the Bluetooth low energy main node200adetermines if the secure authenticator300has instructed the Bluetooth low energy main node200athat the forwarded authentication information100is valid. If the secure authenticator instructs the Bluetooth low energy main node200athat the authentic indication information100is valid, the Bluetooth low energy main node200amay proceed to step222and update the white list to contain the unknown mobile device18,18uin order to reflect that the secure authenticator300validated the unknown mobile device18,18u. If, however, the Bluetooth low energy main node200areceives instruction that the unknown mobile device18,18uis not valid, the Bluetooth low energy main node200amay sleep the secure authenticator300and continue the receipt of localization frames20. Here, sleeping the secure authenticator300refers to reducing the power supplied to the secure authenticator300. This power reduction (i.e. “sleeping”) may be a complete power shutoff to the secure authenticator300to reserve as much power consumption as possible or a low-power state. In some examples, a low-power state for the secure authenticator300enables the secure authenticator300to wake without needing to completely initialize (e.g., boot up) processes to function the secure authenticator300(e.g., much like a computer transitioning from a sleep state to a wake state compared to shut down state to a wake state).

Referring toFIG. 2B, if the mobile device18corresponds to a known mobile device18,18kon the white list, the Bluetooth low energy main node200amay perform localization processing of steps to224-232. In some examples, at least one Bluetooth low energy satellite node200bmay additionally or alternatively be configured to perform the localization processing steps of224-232. Yet, for simplification, the steps of224-232are described via the Bluetooth low energy main node200a.

At step224, the Bluetooth low energy main node200avalidates the at least one localization frame20of the known mobile device18,18k. During validation of the at least one localization frame20, the Bluetooth low energy main node200a, at step226, determines if the Bluetooth low energy main node200ahas received processed authentication localization information (e.g., from the secure authenticator300). For instance, the processed authentication localization information refers to validated If the Bluetooth low energy main node200ahas not received processed authentication localization information, the Bluetooth low energy main node200awaits for at least one valid localization frame20. If the Bluetooth low energy main node200ahas received processed authentication localization information, the process may proceed to step228.

At step228, the Bluetooth low energy main node200aperforms localization. For example, the Bluetooth low energy main node200amay perform a localization strategy such as determining the signal strength of the Bluetooth low energy signal broadcasted by the known mobile device18,18k. If, based on the performed localization, the Bluetooth low energy main node200adetermines that the known mobile device18,18kis within a particular pre-configured proximity zone Z (e.g., as generally described according toFIG. 1C), the process may proceed to step232where the Bluetooth low energy main node200awakes up the secure authenticator300. If, however, based on the performed localization, the known mobile device18,18kis not within the particular pre-configured proximity zone Z, the Bluetooth low energy main node200adoes not wake up secure authenticator300, but instead waits to validate another at least one localization frame20.

FIG. 3is an example of interactions of the secure authenticator300. The interactions of the secure authenticator300depend upon whether a mobile device18is a known mobile device18,18kor an unknown mobile device18,18u. At step302, the secure authenticator300determines why the secure authenticator300has been awoken by the Bluetooth low energy main node200a; whether the mobile device18is a known mobile device18,18kor an unknown mobile device18,18u. If the secure authenticator300has been awoken because the mobile device18is a known mobile device18,18k, the secure authenticator300, at step312, performs an application or a function corresponding to the preconfigured proximity zone Z (e.g., generally described according toFIG. 1C) related to the known mobile device18,18k. If, however, secure authenticator300has been awoken because the mobile device18is an unknown mobile device18,18u, the secure authenticator300may proceed to step304.

At step304, the secure authenticator300receives authentication information100relayed by the Bluetooth low energy main node200afrom the unknown mobile device18,18u. If the secure authenticator300, at step306, determines that it has received authentication information100, the secure authenticator300may proceed to validate and/or decrypt the authentication information100at step308. Once the authentication information100is decrypted and/or validated, at step310, the unknown mobile device18,18umay communicate with the secure authenticator300to perform applications or functions of the vehicle12, at step312, authorized according to the authentication information100generated by the backend entity14.

FIG. 4is schematic view of an example computing device400that may be used to implement the systems and methods described in this document. The computing device400is intended to represent various forms of processing devices that may be contained within the Bluetooth low energy environment10(e.g., the Bluetooth low energy nodes200, the secure authenticator300, the mobile device18, or the backend entity14). The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document.

The computing device400includes a processor410, memory420, a storage device430, a high-speed interface/controller440connecting to the memory420and high-speed expansion ports450, and a low speed interface/controller460connecting to a low speed bus470and a storage device430. Each of the components410,420,430,440,450, and460, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor410can process instructions for execution within the computing device400, including instructions stored in the memory420or on the storage device430to display graphical information for a graphical user interface (GUI) on an external input/output device, such as display480coupled to high speed interface440. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices400may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

The storage device430is capable of providing mass storage for the computing device400. In some implementations, the storage device430is a computer-readable medium. In various different implementations, the storage device430may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory420, the storage device430, or memory on processor410.

The high speed controller440manages bandwidth-intensive operations for the computing device400, while the low speed controller460manages lower bandwidth-intensive operations. Such allocation of duties is exemplary only. In some implementations, the high-speed controller440is coupled to the memory420, the display480(e.g., through a graphics processor or accelerator), and to the high-speed expansion ports450, which may accept various expansion cards (not shown). In some implementations, the low-speed controller460is coupled to the storage device430and a low-speed expansion port490. The low-speed expansion port490, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

The computing device400may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server400aor multiple times in a group of such servers400a, as a laptop computer400b, or as part of a rack server system400c.