A mobile device that communicates with and performs ranging from an access control system for automatic functions

Abstract

To provide a method for using two different wireless protocols for ranging between a mobile device and an access control system (e.g., a vehicle).SOLUTION: A first wireless protocol (e.g., Bluetooth(R)) can be used to perform authentication of a vehicle and exchange ranging capabilities between a mobile device (e.g., a phone or watch, 910) and the vehicle. A second wireless protocol (e.g., ultra-wideband, UWB) can use a pulse width that is less than a pulse width used by the first wireless protocol (e.g., 1 ns v. 1 ms, 940). The narrower pulse width can provide greater accuracy for distance (ranging) measurements.SELECTED DRAWING: None

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application is a PCT application of U.S. Patent Application No. 15 / 983,388, filed on May 18, 2018, entitled "Mobile Device For Communicating And Ranging With Access Control System For Automatic Functionality", which claims the benefit of U.S. Provisional Patent Application No. 62 / 565,637, filed on September 29, 2017, entitled "Mobile Device For Communicating And Ranging With Access Control System For Automatic Functionality". The disclosure of this application is hereby incorporated by reference in its entirety into this specification.

Background Art

[0002] Automobiles often come with proximity key fobs that can automatically unlock the vehicle doors when a person with the fob approaches. People often carry their phones or smartwatches along with the key fob. Carrying both items can be inconvenient. However, it can be difficult to obtain accurate distance measurements between a phone and a vehicle using standard communication protocols (e.g., Bluetooth®) typically used between them, thereby making proper control of door unlocking difficult.

Summary of the Invention

[0003] To provide accurate distance measurement values, in embodiments, two different wireless protocols can be used. A first wireless protocol (e.g., Bluetooth®) can be used to perform vehicle authentication and exchange ranging capabilities between a mobile device (e.g., a phone or a watch) and the vehicle. In a second wireless protocol (e.g., ultra-wideband, UWB), a pulse width smaller than the pulse width used by the first wireless protocol can be used (e.g., 1 ns vs. 1 μs). Making the pulse width narrower can provide improved accuracy for distance (ranging) measurements.

[0004] Exemplary ranging capabilities can include specifying a format for ranging messages between the mobile device and the vehicle, a frequency range to use, the number of antenna units of the vehicle, and an encryption protocol for ranging messages that use the second wireless protocol. By using the first wireless protocol to specify such ranging capabilities, the mobile device can connect to and use various vehicles that each have different settings and capabilities.

[0005] The mobile device can send a ranging request message that includes a first set of pulses to one or more antenna units of the vehicle and receive one or more ranging response messages that include a second set of pulses. In various embodiments, the times of such pulse transmission and reception can be determined and sent to the vehicle so that the vehicle can determine the distance between the mobile device and the vehicle, or so that the mobile device can determine the distance for transmission to the vehicle. Various functions (e.g., set by the user) can be automatically performed based on a distance that crosses a threshold or a rate of change of distance that exceeds a threshold.

[0006] Other embodiments are directed to systems, portable consumer devices, and computer-readable media associated with the methods described herein.

[0007] A better understanding of the nature and advantages of the embodiments of the present disclosure can be obtained by referring to the following detailed description and the accompanying drawings.

Brief Description of the Drawings

[0008]

Figure 1

[0009]

Figure 2

[0010]

Figure 3

[0011]

Figure 4

[0012]

Figure 5

[0013]

Figure 6

[0014]

Figure 7

[0015]

Figure 8

[0016]

Figure 9

[0017]

Figure 10

Embodiments for Carrying Out the Invention

[0018] In an embodiment, a mobile device (e.g., a phone or a watch or other accessory) can be provided that securely communicates with a motor vehicle for authentication and ranging and unlocks the door in a timely manner when the user approaches the motor vehicle. Also, other operations other than unlocking, such as turning on lights, engine, heater, air conditioner, or providing information from the motor vehicle to the mobile device, can be provided. Secure communication can involve not only key exchange typically associated with a first wireless protocol but also key negotiation occurring over the first wireless protocol, where the keys are later used, for example, with a second wireless protocol used in ultra-wideband (UWB) ranging. The cryptographic keys can also be used as part of a challenge-response message for authenticating the mobile device and the vehicle to each other.

[0019] As part of authentication, different access privileges can be provided. For example, even if the owner's child has a phone, the access privileges for that phone are restricted to only unlocking the rear seat and cannot start the engine. In various embodiments, such access privileges can be programmed into the phone (e.g., when commands are provided from the phone to the vehicle for specific functions), or can be programmed into the vehicle for a specific phone, and the device identifier can be used to determine when a specific phone is communicating with the vehicle. Some embodiments can be extended to multiple people approaching the vehicle, each equipped with a separate mobile device that can perform ranging independently.

[0020] In some embodiments, Bluetooth® (e.g., classic, high speed, or low energy (BTLE), collectively referred to as BT) can be used to authenticate a mobile device with a vehicle. However, BT pulses are wide (e.g., 1 microsecond) and do not allow for accurate distance measurements. Instead, UWB can be used for distance measurement when the pulses are narrower (e.g., ~1 nanosecond), thereby enabling better time-of-flight calculations. UWB may not be suitable for authentication and other data communications where guaranteed data transfer latency is desired.

[0021] Accordingly, a mobile device can use a first wireless protocol (e.g., BT) for the exchange of authentication and ranging capabilities (e.g., ranging message format, number of antenna units, encryption protocol, etc.) with an access control system such as a vehicle or a building (e.g., as part of a home lock). Examples of vehicles include automobiles, trucks, boats, and trains. Additionally, a message via the first wireless can initiate a ranging process, which uses a second wireless protocol (e.g., UWB) with pulses that are narrower than the pulses used by the first wireless protocol to determine the distance between two devices. The defined functionality can be performed at various distances from a vehicle (or other access control systems such as a building or other structure (e.g., fence) including locks such as gates, doors), for example, turning on a light 5 meters away and unlocking a vehicle 2 meters away. Any of the following considerations regarding vehicles are also applicable to other access control systems. I. Communication and Ranging Using Two Protocols

[0022] A first wireless protocol link between a mobile device (e.g., a phone, tablet, or watch) and a vehicle can be used for authentication and then, for ranging and exchanging distance information, can be initiated and controlled using a second wireless protocol (e.g., UWB). For example, the first wireless protocol can provide a security key, negotiate a ranging interval, and provide a low-power framework for initiating ranging via UWB.

[0023] FIG. 1 is a flowchart showing a method 100 for automated distance-based access control for a vehicle according to an embodiment of the present invention. Method 100 is generally presented to both devices to affect the operation of the vehicle. One of ordinary skill in the art will understand which steps are performed by which device.

[0024] In block 110, the mobile device and the vehicle are paired using a first wireless protocol. As will be described in more detail later, pairing (e.g., BT pairing) can involve authentication between the mobile device and the vehicle via any one of various techniques. As a result of pairing, a shared secret can be stored on both devices, and the shared secret can be used for future authentication (e.g., via challenge response) and / or encryption of messages between the mobile device and the vehicle. The mobile device can play a central role during initial setup and pairing.

[0025] The identity addresses of the mobile device and the vehicle (e.g., media access control (MAC) address) can be exchanged during pairing. For example, a 48-bit address unique to each BT device can be used. The mobile device can use a resolvable private address and can periodically cycle the address, for example, change the random value at the timing intervals that can occur when the BTLE privacy mode is used. In addition, a resolution key (e.g., BT identity resolution key (IRK)) can be exchanged during pairing, thereby enabling the device to convert the random MAC address in the advertisement packet to the actual MAC address for authentication purposes. If the vehicle supports multiple BT controllers, all controllers may use the same identity address and resolution key. Each controller may have a different random resolvable address at any given time.

[0026] In block 120, a vehicle and / or a mobile device can be authenticated using a first wireless protocol when the mobile device is present. This authentication may occur immediately after pairing or at some point later. For example, the mobile device and the vehicle can be paired, and then the user can leave the vehicle. The user can then return the next day or at any later time and perform authentication using the information obtained during the pairing process. As an example, once paired, the mobile device can always be in advertising mode and assume a peripheral role in all subsequent connections to the vehicle. The mobile device may send multiple advertising packets each having a different payload. A resolvable random address within the payload can be used by the vehicle to identify the paired device, for example, using an IRK. The vehicle can filter advertising packets based on the payload.

[0027] When the vehicle receives an advertising packet from a paired mobile device, it can initiate a BT (e.g., BTLE) connection to the mobile device, whereby the vehicle functions as a central device for this connection. The BT connection can be initiated by the vehicle sending a response message indicating a desire to create a connection and including the vehicle's identifier. A connection interval (e.g., 30 ms) can be required by the mobile device.

[0028] In block 130, the mobile device and the vehicle can exchange ranging capabilities using a first wireless protocol. By exchanging the ranging capabilities, it can be ensured that the signaling between the mobile device and the vehicle is performed in a consistent manner by both devices. Such an exchange enables the mobile device to adapt to new vehicles, e.g., vehicles with different numbers and types of antenna units. Exemplary ranging capabilities can include specifying a format for ranging messages between the mobile device and the vehicle, the frequency range to be used, the number of antenna units of the vehicle, and an encryption protocol for ranging messages using a second wireless protocol.

[0029] In block 140, ranging can be started using the first wireless protocol. In some embodiments, the start can be initiated by a ranging request message transmitted from the mobile device or the vehicle. The responding device can respond using a start notification event (message). Once the start notification event occurs, ranging can be performed using the second wireless protocol, e.g., by turning on the corresponding radio within a specific time of receiving the start message. Further examples and details are provided herein.

[0030] In block 150, ranging can be performed using a second wireless protocol (e.g., UWB). After the start signal using the first wireless protocol, the vehicle can start scanning for ranging signals at a specific time using one or more vehicle antenna units corresponding to the second wireless protocol. The one or more vehicle antenna units can receive one or more ranging request messages and transmit one or more ranging response messages. If the control unit is in or shared among each of the one or more vehicle antenna units, various levels of processing of such ranging messages can be performed to, for example, determine a timestamp. The mobile device can receive the ranging response message and determine the timestamp for the transmission of one or more ranging request messages and the timestamp for one or more ranging response messages. The mobile device can transmit these timestamps to the vehicle to determine the distance between the mobile device and the vehicle. In other implementations, the mobile device can determine the distance based on the transmission time and reception time of the ranging signal. Ranging can continue until a stop ranging request is processed.

[0031] In block 160, the vehicle can perform a predetermined operation based on the ranging. For example, the vehicle can determine that the mobile device is within a first threshold, whereby a first operation is performed, for example, the vehicle lights are turned on. Further ranging can be performed to determine the distance over time. When the mobile device is within a closer threshold, a second operation can be performed, for example, the door can be unlocked.

[0032] In some embodiments, the operation can depend on the trajectory of the mobile device, e.g., which side of the vehicle the mobile device is approaching. For example, if the mobile device is approaching the passenger side, potentially only the passenger door can be unlocked. If the mobile device is approaching the rear of the vehicle, the trunk or hatch can be unlocked.

[0033] Figure 2 shows the exaggerated movement of mobile device 210 that communicates with vehicle 205 using a first wireless protocol to authenticate and prepare for ranging. The mobile device then participates in ranging using a second wireless protocol according to an embodiment of the present invention. Mobile device 210 and vehicle 205 are assumed to be already paired, for example, such that a secure channel has already been established between the two devices via a shared secret. Mobile device 210 is shown at three times T1 to T3. The actual movement of mobile device 210 during these times is typically smaller than shown because the distances are exaggerated for ease of illustration. Vehicle 205 includes a BT antenna and four UWB antennas 1 to 4, although other numbers of UWB antennas are possible.

[0034] At a first instance of T1, mobile device 210 can authenticate the vehicle using the first wireless protocol, and vice versa. For example, mobile device 210 can send an unencrypted random number to vehicle 205. Vehicle 205 can encrypt the random number using the shared secret established during pairing and send the encrypted value in the message to mobile device 210, and mobile device 210 can decrypt the message to confirm that the same random number was received.

[0035] After authentication, still nominally at T1, mobile device 210 and vehicle 205 can exchange information about ranging that will occur at subsequent times (e.g., times T2 and T3). The exchanged information can ensure that both devices perform ranging in the same way and that ranging occurs in a synchronized manner.

[0036] At time T2, the mobile device 210 or the vehicle 205 can transmit an initial ranging message that may include a series of pulses. These pulses are narrower than the pulses used in the first wireless protocol at time T1. The mobile device 210 can broadcast the initial ranging message so that each of the four UWB antennas 1-4 of the vehicle can receive the initial ranging message. The mobile device 210 can track the exact time (e.g., up to nanosecond accuracy) at which the initial ranging message was transmitted. Each of the UWB antennas can transmit a ranging response message, and the ranging response message can include an identifier that identifies which UWB antenna transmitted a particular response message. The mobile device 210 can track the exact time for receiving four UWB ranging response messages.

[0037] In some embodiments, the mobile device 210 can transmit the tracking time to the vehicle 205, and the vehicle can use its own tracking time for receiving the initial ranging message at each of the UWB antennas 1-4 and the time for transmitting each of the four ranging response messages to determine the distance between the mobile device and the vehicle. For example, when the clocks of the two devices are synchronized, the distance can be determined using the difference between the time for transmitting and receiving each message. As another example, the round-trip time can be obtained by subtracting the time delay between receiving the initial ranging response message and transmitting the ranging response message from the transmission time and the reception time at the mobile device 210. The round-trip time can be converted to a distance based on the speed of the electromagnetic signal. The position of the mobile device 210 relative to the vehicle 205 can be triangulated using the known positions of the different UWB antennas within the vehicle.

[0038] In other embodiments, the mobile device 210 can determine the distance from the vehicle 205. For example, if the ranging information exchanged by the vehicle includes the relative position of the vehicle's UWB antenna and the expected delay between the reception of the ranging request message and the transmission of the ranging response message, the mobile device 210 can use the round-trip time of sending and receiving the ranging message to determine the distance. II. Exemplary Protocols and Signaling

[0039] Two wireless protocols can be BT and UWB. Details for each wireless protocol are described below along with further details regarding the sequence of messaging between the mobile device and the vehicle. A. First Wireless Protocol (e.g., Bluetooth)

[0040] The mobile device and the vehicle may have multiple antennas for the first wireless protocol (e.g., BT). BT can use short-wavelength ultra-high frequency (UHF) radio waves in the 2.4 - 2.485 GHz ISM band.

[0041] A particular mode of the first wireless protocol can be used over a relatively long range. For example, one BT radio can increase the communication range by using lower packet encoding of 125 kbps or 500 kbps and increasing the maximum transmit power (e.g., up to +20 dBm). Such a radio can be used for both advertising packets and data packets and can provide a range of up to 100 meters, as opposed to a lower power mode that can only function up to 20 meters. Thus, if a user is approaching a vehicle while moving at a speed of 1.5 meters per second, the 100 - meter range can still provide sufficient time for authentication, negotiation of ranging parameters, and transmission of the ranging start message. Such additional time for establishing communication can be advantageous in cases where there may be interference from other vehicles that could otherwise delay the detection of the mobile device and the start of ranging.

[0042] However, these packets may have a duration that is approximately 2 to 8 times longer, for example, up to about 16 milliseconds, and thus are not suitable for ranging. A 1 microsecond pulse provides a range of + / - 300 meters. Also, even in the normal power mode for BT, pulses that are not suitable for ranging are provided. B.UWB

[0043] The second wireless protocol has a narrower pulse, for example, a narrower full width at half maximum (FWHM), than the first wireless protocol. In some embodiments, the second wireless protocol (e.g., UWB) can provide a distance accuracy of 5 cm or better. In various embodiments, the frequency range can be 3.1 to 10.6 GHz. Multiple channels can be used, for example, one channel at 6.5 GHz and another channel at 8 GHz. Thus, in some cases, the second wireless protocol does not overlap with the frequency range of the first wireless protocol. Mobile devices and vehicles may have multiple antennas for the second wireless protocol.

[0044] The second wireless protocol can be specified by IEEE802.15.4, a type of UWB. Historically, UWB has been used for high - bandwidth communication but has interference with GPS. Each pulse within a pulse - based UWB system can occupy the entire UWB bandwidth (e.g., 500 MHz), thereby enabling the pulse to be localized in time (i.e., a narrow time width, e.g., 0.5 ns to several nanoseconds). With respect to distance, the pulse can be less than 60 cm wide for a 500 MHz - wide pulse and less than 23 cm wide for a 1.3 GHz - bandwidth pulse. Because the bandwidth is so wide and the width in real space is so narrow, very accurate time - of - flight measurements can be obtained. C. Sequence Diagram

[0045] FIG. 3 shows a sequence diagram of communication between a mobile device 300 and a vehicle 350 involving BT and UWB protocols according to an embodiment of the present invention. Since it is assumed that the mobile device 300 and the vehicle 350 are already paired, the vehicle has the credentials of the mobile device, and the mobile device has the credentials of the vehicle. The mobile device 300 may be in the screen-off state or may be actively used by the user. The steps of the sequence diagram may be optional.

[0046] At 301, the BT antenna of the mobile device 300 transmits an advertisement signal, for example, in a low energy (LE) mode. The mobile device can broadcast the advertisement signal in several duty cycles without the user providing any user input. Causing the mobile device 300 to transmit the advertisement signal may be preferable to the vehicle 350 transmitting the advertisement signal. If the vehicle is advertising, there may be excessive advertisements. For example, if all the automobiles in a parking lot are advertising (for example, when there are only 3 channels available for the use of beacon signal advertisements), the channels can become saturated. Another problem is that when the mobile device is in the pocket, it may enter the battery save mode and need to scan at a very low duty cycle, so the vehicle has to scan at a high rate, for example, every 20 milliseconds, to establish a connection.

[0047] At 302, the BT antenna of the vehicle 350 scans in a certain duty cycle. In some embodiments, the vehicle 350 can have two or more BT antennas, and any of the BT antennas can detect the advertisement signal from the mobile device 300. Advertising and scanning can be part of the discovery process for the two devices to detect each other, thereby creating a connection.

[0048] In 303, a BT connection is created between two devices. For example, vehicle 350 can respond with a message containing its credentials (e.g., identifier), and mobile device 300 can respond with its credentials. In some implementations, each device can check its network address with the address stored for the previously paired device, for example, to obtain an encryption key which is other information used for the connection.

[0049] In 304, the processors of the two devices communicate with their respective BT antenna devices to perform signal processing and are awakened to provide control signals to the BT antenna devices for transmitting signals. For example, the operating system of mobile device 300 can access a database (e.g., a table) of paired devices to match the stored credentials with those obtained from vehicle 350. Similarly, the engine control unit (ECU) of vehicle 350 can access the database of paired devices to match the stored credentials with those obtained from mobile device 300. Information from each device's profile can be used at a later stage of the communication.

[0050] In some embodiments, the ECU can be programmed with such functionality. In other embodiments, a software upgrade can be applied to the ECU. Further, the ECU can include one or more hardware devices added after manufacture, and such one or more hardware devices can interface with an antenna that executes the first or second wireless protocol. Such an antenna may also be added after manufacture, for example, as part of an aftermarket installation.

[0051] At 305, the encryption key is derived by each of the two devices. For example, the corresponding profile that matches the received credentials can include a shared secret, and this can be used to derive the encryption key. The derivation can be performed according to default procedures, for example, based on a counter or a timestamp.

[0052] As part of this stage, a first level of challenge response can be executed as part of authentication. For example, the mobile device 300 can provide a random number to the vehicle 350, and the vehicle 350 can provide a response using the encryption key. The mobile device 300 can match the response to the expected encrypted value corresponding to the random number.

[0053] At 306, a communication channel is set up. The communication channel can include an intermediate layer between the application layer and lower layers, for example, a host controller interface (HCI). In some embodiments, the intermediate layer can be a logical link control and adaptation protocol (L2CAP) layer. This layer can be responsible for protocol multiplexing capabilities, segmentation, and reassembly operations for data exchanged between the host and the protocol stack.

[0054] At 307, a security handshake is performed between the mobile device 300 and the vehicle 350. The security handshake can provide an additional level of protection for unlocking the vehicle on top of typical BT authentication. Each of the mobile device 300 and the vehicle 350 can have a hardware secure element that can store keys. The keys in the secure element can be used for challenge responses for the additional level of authentication. In various embodiments, the keys can be hardware keys added by the manufacturer or obtained in a provisioning process. In the case of the provisioning process, each of the devices can communicate with a server (e.g., a website), and the server can provide the keys stored in the hardware secure element. The hardware secure element can be a tamper-resistant platform (typically, a single-chip secure microcontroller) that can securely host applications and their confidential and encrypted data (e.g., key management).

[0055] An application on the mobile device 300 communicating with the BT circuit (e.g., as part of an operating system or an application installed on the operating system) can communicate with the secure element and notify the secure element of a connection to a particular vehicle. The secure element can generate a challenge (e.g., a random number) to be sent to the vehicle 350. Once received, the vehicle 350 can send the challenge to its secure element, and the secure element can generate a response. The secure element on the mobile device 300 can confirm the response, for example, by knowing the hardware key of the provisioned device. The secure element can store, in the key, the credentials of the matching vehicle that can be obtained from a provisioning server after the vehicle is paired.

[0056] In other embodiments, the mobile device 300 can track which vehicle it is paired with and determine which vehicle is currently connected. The secure element can generate a challenge based on key provisioning for that vehicle. Through authentication, the vehicle 350 knows which mobile device corresponds to the current link and thus which key to use to respond to the challenge. The vehicle 350 can obtain the key corresponding to the mobile device during the pairing process. In other embodiments, the vehicle 350 can initiate the challenge.

[0057] The challenge message can include information indicating that the type of the message is a challenge. The location of such information in the packet definition of such a message can be added as part of the ranging service via a first radio protocol defined by the operating system or the installed application.

[0058] In other embodiments, one or more new keys (e.g., shared secrets) for this security handshake can be exchanged after all dialogue sessions, e.g., after the vehicle is unlocked. Then, for the next dialogue session (i.e., when the user uses the vehicle next time), one device can send data to the other device as part of the challenge, and the other device can encrypt the data or perform a transformation to obtain a response that is compared with the expected value.

[0059] At 308, any additional data is exchanged. For example, the vehicle may send information about the fuel in the tank or other information, which may be defined by the user, for example. In some embodiments, the information can appear as a notification or a pop-up window.

[0060] At 309, a ranging setup handshake is exchanged between the mobile device 300 and the vehicle 350. The ranging setup handshake can include the ranging capabilities of the two devices. Different vehicles can have different numbers of UWB receivers, or information about the UWB receivers on the vehicle can be provided if the vehicle wants to turn on only a few. Coarse ranging may occur first, and finer ranging may occur using the UWB receivers after the mobile device gets closer. For example, more receivers can be turned on if the mobile device is estimated to be inside the vehicle so that high accuracy can be obtained before the user can start the vehicle's engine. Which UWB receiver to turn on first can depend on which side of the vehicle the user is approaching. Other settings / parameters may be provided after pairing or during the ranging procedure, for example, as part of the dynamic determination or update of software or physical components.

[0061] Other examples of ranging capabilities include the number of antennas, the locations of those antennas (e.g., the relative distances between the antennas and / or the relative distances between origins within the vehicle such as the ECU), the number of antennas used, the encryption protocol, the packet format, the operating mode, and the supported frequency range. Such capabilities can bring new or different capabilities by reflecting software updates to the vehicle or the mobile device.

[0062] The ranging setup handshake can include negotiation about the frequency of ranging or the ranging schedule method (e.g., in the case of multiple vehicles or multiple mobile devices - round robin, one at a time, or other options), and the method of performing ranging. For example, there may be multiple devices near a vehicle (e.g., the whole family is heading towards one car), or multiple vehicles near a mobile device (e.g., three cars in a garage). Since a mobile device may know that it is connected to three different vehicles, the mobile device can desire a lower rate (e.g., 25 milliseconds) of ranging measurements for each vehicle, or schedule specific times / frequencies to perform ranging on each vehicle. Similarly, a vehicle may perform such scheduling when multiple devices are nearby. The ranging setup handshake may also depend on whether vehicles are communicating with each other.

[0063] The ranging setup handshake can specify the time when ranging is to be started, for example, by adjusting the time when a vehicle should turn on its UWB radio and start searching for packets. The start message sent via BT can be used, for example, using specific messages detailed below. The duty cycle when the UWB radio is on can be specified, for example, at 1KHz or 10KHz. For example, upon receiving the start message, the device can agree to start ranging 100 milliseconds (or 90 milliseconds for additional margin) from the start message, and then every 1KHz thereafter.

[0064] The ranging setup handshake can derive a set of new session keys for UWB ranging. The keys can be updated periodically, for example, for each session or every Nth session. In some embodiments, the session keys can be derived from a common shared secret used in a challenge response for a security handshake, and the derivation uses default or negotiation procedures. Thus, the ranging setup handshake can function as a control channel to notify vehicles and mobile devices about what is expected for ranging.

[0065] At 310, for example, ranging is performed using UWB messages. In some embodiments, ranging can be performed by the mobile sending a ranging request message to one or more antennas of the vehicle. The vehicle antennas can respond, and the mobile device can potentially receive ranging response messages at different times. Such an example using three antenna nodes is provided in FIG. 4. In other examples, more antenna nodes, for example, 6 - 8, can be included. A single node can have one transceiver and potentially two or more antennas.

[0066] FIG. 4 shows a sequence diagram of a ranging operation involving a mobile device 400 and three vehicle antennas 452 - 456 according to an embodiment of the present invention. In the example of this FIG. 4, the mobile device 400 broadcasts a single packet received by antennas 452 - 456 (e.g., each of different nodes). In another implementation, the mobile device 400 can send packets to each node and have each node respond to its respective packet. The vehicle can listen to a particular antenna so that both devices can know which vehicle antenna is involved, or the packet can indicate which antenna the message is for. For example, the first antenna can respond to the received packet and, upon receiving the response, can send another packet to a different antenna. However, this alternative procedure takes more time and power.

[0067] FIG. 4 shows a ranging request 410 transmitted at T1 and received by antennas 452 - 456 at times T2, T3, and T4 respectively. Thus, the antennas (e.g., UWB antennas) listen substantially simultaneously and respond independently. Antennas 452 - 456 provide ranging responses 420, which are transmitted at times T5, T6, and T7 respectively. The mobile device 400 receives the ranging responses at times T8, T9, and T10 respectively. Optional ranging messages 430 can be sent (shown at T11), which are received by antennas 452 - 456 at times T12, T13, and T14 respectively. Distance / time information 440 can be sent after a set of ranging messages, and it may only be necessary for it to be received by one antenna that relays the information to a control unit. In the illustrated example, a timestamp tracked by the mobile device 400 is sent to at least one of antennas 452 - 456, whereby the vehicle can determine the distance from the vehicle, for example based on the location of the antennas within the vehicle. In other examples, the mobile device 400 can determine the distance and send that distance to the vehicle.

[0068] In some embodiments, in order to determine which ranging response is from which antenna, the vehicle can notify the mobile device, for example, of the order of response messages to be transmitted during a ranging setup handshake. In other embodiments, the ranging response can include an identifier. The identifier indicates which antenna transmitted the message. These identifiers can be agreed upon in a ranging setup handshake.

[0069] Using the ranging message 430 can enable an improvement in accuracy. The antennas can be synchronous clocks with each other, but the response times (e.g., the delay between T2 and T5) may be different. For example, T5 - T2 and T6 - T3 may be different. The ranging message 430 can provide recoverability for different turnaround times for each of the antenna nodes. If there are such differences in the turnaround time, ranging errors of 1 meter or 2 meters may occur. By adding the ranging message 430, in embodiments, the errors caused by different turnaround times can be reduced.

[0070] Messages 410 - 430 can contain little data in the payload, for example, by including a small number of pulses. The use of fewer pulses can be advantageous. Depending on the environment of the vehicle and the (potentially in - pocket) mobile device, the measurement may become difficult. As another example, the vehicle antenna may be oriented in a direction different from the direction in which the mobile device is approaching. Therefore, it is desirable to use high and low for each pulse, but there are government regulations (as well as concerns about the battery) regarding how much power can be used within a specific time window (e.g., averaged over 1 millisecond). The packet frames within these messages can be on the order of 150 - 180 microseconds in length. The packet frame of message 440 can be made longer, for example, 200 or 250 microseconds in length.

[0071] At 311, further ranging can be performed. For example, two or more distances can be determined that can be used to determine the trajectory. If the trajectory indicates movement towards the vehicle (e.g., the distance is getting smaller for a specified number of measurements), the vehicle can infer the intention of the user entering the vehicle. As another example, different operations can be performed at different distance thresholds, for example, turning on the light at one distance threshold, unlocking the vehicle at a closer distance threshold, and turning on the engine at an even closer distance threshold (e.g., after the user presses a button).

[0072] At 312, the engine control unit of vehicle 350 can determine which operation(s) should be performed based on the distance and / or rate of change of the distance, and the trajectory. The specific operation(s) may depend on settings programmed by the user in the mobile device and / or the vehicle. Further communication between the mobile device and the vehicle can also be used to determine the operation(s) to be performed, including communication via BT, for example, prompting the user for input regarding whether to turn on the air conditioner or heater.

[0073] D. Pulse Each one of the ranging messages (also called a frame or packet) can include a sequence of pulses that can represent the information to be modulated. Each data symbol within the frame can be a sequence. The packet can have a preamble including header information, for example, of the physical layer and MAC layer, and can include a destination address. In some embodiments, the packet frame can include a synchronization part and a start frame delimiter (SFD) that can line up the timing.

[0074] Packets can include the way security is configured and can include encrypted information, such as an identifier of which antenna transmits the packet. The encrypted information can be used for authentication. In the case of ranging operations, the content of the data may not need to be determined. In some embodiments, the pulse timestamps of specific data pieces can be used to track the difference between transmission and reception. Thus, the content can be used to match the pulses. In some embodiments, the encrypted information can include an indicator for authenticating the stage to which the message corresponds. For example, the ranging request 410 can correspond to stage 1, the ranging response 420 can correspond to stage 2, and the ranging message 430 can correspond to stage 3.

[0075] E. Distance determination Narrow pulses (e.g., ~1 ns width) can be used to accurately determine the distance. A high bandwidth (e.g., 500 MHz spectrum) enables narrow pulses and accurate position determination. The cross-correlation of the pulses can provide timing accuracy that is a small fragment of the pulse width, for example, providing accuracy within hundreds or tens of picoseconds and providing sub-meter level ranging accuracy. The pulses can represent ranging waveforms of plus 1 and minus 1 in some patterns recognized by the receiver.

[0076] For distance measurement, round-trip time measurement, also called time-of-flight measurement, can be used. As described above, the mobile device can transmit a set of timestamps, and the set of timestamps can eliminate the need for clock synchronization between the two devices. III. Authentication and secure channel establishment (pairing)

[0077] As described above, a BT communication channel (or a part thereof) can be established during a pairing process, for example, when a user acquires a new mobile device and / or a new vehicle. In some embodiments, the pairing is initiated by the vehicle that starts the BT advertisement. The advertisement payload for initiating the pairing can include various data. In other embodiments, the mobile device can initiate the pairing with the vehicle. Once the pairing is complete, the mobile device can set up a channel (e.g., a connection-oriented L2CAP channel). A connection-oriented channel can be used to exchange ranging service messages to exchange capabilities and to exchange security keys to complete the UWB pairing.

[0078] Once the vehicle and the iOS device are paired, subsequent BT connections can be initiated by the vehicle. The vehicle can also initiate a standard BT encryption handshake to set up an encrypted link using the link key created during the pairing. The mobile device or the vehicle can initiate UWB ranging by first initiating a ranging handshake over BT. Further details regarding the pairing are provided below.

[0079] Pairing is a way for two devices (e.g., a phone and a vehicle's control unit) to create a connection (e.g., a Bluetooth® connection) in relation to each other. When pairing occurs, the two devices can communicate with each other. Pairing is generally manually initiated by the user, for example, by selecting a device discovered on the settings page of the initiator device. The initiator device can then send a pairing request to the responder device that is not yet paired. Pairing usually occurs once between the two devices. After pairing, the connection between the two devices is automatically authenticated.

[0080] To continue pairing, an authentication password or "passkey" can be exchanged between two devices. The passkey is used to confirm that both devices have agreed to pair with each other. Once the two devices are paired, the devices can verify each other's identity. To complete the pairing, the two devices generate a shared secret key(s) to be used for all future communication between the devices.

[0081] In the case of Bluetooth® (BT) Low Energy, the Security Manager Protocol (SMP) performs pairing in three phases. In Phase 1, the two devices advertise their input and output capabilities, which is used to determine the preferred method for Phase 2. In Phase 2, the two devices authenticate each other and determine the key generation method for the keys used in Phase 3. More specifically, in Phase 2, the two devices use the IO capabilities from the pairing request and pairing response packets in Phase 1 to determine which authentication method to use. Typically, four authentication techniques are available, namely Just Works®, numeric comparison, passkey, and Out-of-Band (OOB). In Phase 3, each device can distribute one or more keys to the other device for future communication. Exemplary keys include (a) a Long Term Key (LTK) used to generate a session key for an encrypted connection, (b) a Connection Signature Resolution Key (CSRK) used to sign data and verify signatures, and (c) an Identity Resolution Key (IRK) used to generate a private address. In Bluetooth® 4.2 devices, the LTK is exchanged / generated using Elliptic Curve Diffie Hellman (ECDH) public key cryptography.

[0082] With Just Works (registered trademark), the devices exchange their public keys. Then, the responder device generates a nonce (e.g., a random seed value) and generates a confirmation value Cb using the nonce and both public keys. The responder device then sends Cb along with the nonce to the initiator device. The initiator device then generates its own confirmation value Ca that should match Cb using the responder device's nonce (along with both public keys). If the confirmation values match, the connection proceeds. The initiator device can generate its own nonce, send it to the responder device, and perform its own verification.

[0083] Numeric comparison follows the same procedure as Just Works (registered trademark) but adds an additional step at the end. When the two devices confirm that the confirmation values match, both devices independently generate a final 6-digit confirmation value using both nonces. Both devices display their calculated values to the user. The user then manually checks that both values match to confirm the connection. This additional step enables this pairing method to provide protection against man-in-the-middle (MITM) attacks.

[0084] With the passkey, a 6-digit number is entered on one or both of the devices. The two devices authenticate the connection using the password, previously exchanged public keys, and nonces. This process can be done bit-by-bit for all bits of the passkey. For example, one device calculates a confirmation value for one bit of the passkey and reveals it to the other device. The other device then calculates its own confirmation value for the first bit of the passkey and reveals it to the first device. This process continues until all bits of the passkey have been exchanged and confirmed to match. This passkey method is resilient to MITM attacks.

[0085] In out-of-band (OOB), external communication means such as Near Field Communication (NFC) are used to exchange some information (e.g., public key, nonce, and confirmation value) used in the pairing process. Pairing is completed using a Bluetooth® radio, but requires information from the OOB mechanism. This provides only the level of MITM protection present within the OOB mechanism.

[0086] FIG. 5 shows a sequence diagram of a pairing process 500 according to an embodiment of the present invention. The pairing process involves an initiator device 502 (e.g., a phone) and a responder device 504 (e.g., a vehicle). Each device determines its capabilities with respect to input and output (IO). For each device within the pairing link, the IO capabilities determine their ability to create an encrypted shared secret key. Public key cryptography can be used.

[0087] In step 505, the user activates the discovery mode on the responder device 504. The device should be set to a discoverable mode so that it can be found by other Bluetooth devices. The advertisement signal enables other nearby devices to detect its presence and attempt to establish a connection. For example, the user can activate a button on the responder device 504.

[0088] In step 510, the responder device 504 emits an advertisement signal in response to the user's activation. The initiator device 502 can detect the advertisement signal. For example, the initiator device 502 can scan for the advertisement signal periodically. The user can enable the initiator device 502 to perform such a scan and set the scan rate, or the scan rate can be set by default. The advertisement signal can include identifiers such as the type of device (e.g., phone, headset, etc.), the device name (e.g., assigned by the user or manufacturer), etc.

[0089] In step 515, the user starts the pairing process by providing user input to the user interface of the responder device 504. For example, the user can navigate to the settings page, determine that the responder device 504 is detected via an advertisement signal, and select the option to pair with the responder device 504.

[0090] In step 520, a pairing request message is sent from the initiator device 502 to the responder device 504. As an example, the pairing request message can include the IO capabilities of the initiator device 502, authentication data availability, authentication requirements, key size requirements, and other data.

[0091] In step 525, a pairing response message is sent from the responder device 504 and includes much of the same information as the pairing request message. Steps 520 and 525 can occur as part of Phase 1. The devices can use the information in the messages to perform authentication, for example, to select authentication options and conduct authentication.

[0092] In step 530, authentication is performed, for example, via one of the four modes described above. In authentication, the devices can establish that they are communicating with another device corresponding to the encryption key being used. Authentication can be verified by one device or both devices. Authentication can be performed as Phase 2.

[0093] In step 535, the key is exchanged, for example, as part of phase 3. The key exchange can correspond to the bonding process so that pairing (e.g., phases 1 and 2) does not need to be performed every time the devices connect (link) to each other. Thus, the key can be used to encrypt future communications. For example, the advertisement signal can identify the responder device, and the initiator device can determine that the two devices are already paired. The initiator device can then continue to use one or more keys to send a message to the responder device, and the responder device can decrypt the message using its stored key or otherwise read the message.

[0094] Subsequently, in step 540, a communication link is automatically established between the devices. As just explained, this link can use the exchanged key. Also, since the devices are already paired, once the advertisement signal is detected, a message can be immediately sent via the link. However, this automatic connection requires that the pairing process has already been performed. The device can determine that another device is already paired by comparing the data in the advertisement signal with a list of already paired devices. IV. Ranging Service - First Protocol

[0095] In various embodiments, the ranging service may be instantiated as a primary service or as a secondary service. In some of the provided examples, the ranging service defines messages that can be exchanged over a BT connection-oriented channel. Both the mobile device and the vehicle can support a database and can use procedures defined to interact with the database, independent of the ranging service. The vehicle can function as a central device and can open a channel. Aspects of the protocol for establishing the ranging service using a first wireless protocol (e.g., for performing a security handshake 307, data exchange 308, and ranging setup handshake 309) are described below, followed by several exemplary message sequences. A. Protocol

[0096] An exemplary format for the ranging service message format can provide a code (e.g., 1 octet long) indicating the type of the message. A length field (e.g., 2 octets long) can indicate the size in octets of the data field of the message, which may or may not include the code field and the length field. The data field can have a variable length. Thus, the code field can determine the format of the data field, and the length field can indicate the length of the data field. The following section provides exemplary details of the ranging service messages for negotiating, starting, and completing UWB ranging between a mobile device and a vehicle. 1. Ranging Capability Request / Response

[0097] At the start of all connections, a ranging setup (capability) handshake can be initiated to exchange the states of the mobile device and the UWB devices on the vehicle. The ranging capability request message can have a specific ID code (e.g., 1). Some exemplary parameters of this message include the supported feature mask, the required feature mask, the software version, the link identifier, the number of UWB radio devices, and the UWB device descriptor.

[0098] The software version parameter can indicate the current ranging software version running on the initiator device. The link identifier can be a random number that enables the responder to match the received UWB packet to the BT connection with the initiator. Thus, the link identifier can be included within the UWB message.

[0099] Both the mobile device and the vehicle can maintain two feature masks, namely, the supported feature mask and the required feature mask. The supported feature mask can indicate the supported features. The feature mask parameter can be a bitmask of all features. For each feature, a single bit can be specified and set to 1 if the feature is supported and 0 otherwise. Exemplary features are secure ranging, one-to-one ranging (e.g., 1 device to 1 device), and one-to-many ranging (e.g., 1 mobile device to multiple vehicles, or multiple vehicles to multiple mobile devices). The required feature mask can indicate the required features. For example, support for secure ranging and one-to-one ranging may be essential.

[0100] The UWB device descriptor can have one entry for each available UWB antenna device (e.g., an antenna, or a node having two or more antennas). The feature request message can have one UWB device descriptor entry for each UWB device on the initiator device. Each of the UWB antenna devices can be characterized by a UWB device descriptor having the following parameters. That is, firmware version - the version of the current UWB firmware, hardware version - the version of the current UWB hardware, manufacturer's name - the name of the UWB manufacturer.

[0101] The number of available UWB devices can be specified for a particular ranging session. The link identifier can map a BT link to a UWB packet. The calibration data can be exchanged in pairing or all connections.

[0102] The ranging capability response message can be similar to the ranging capability request message. The responder may be specified to send this message. If the responder does not support any of the features listed in the requested features of the ranging capability request message, the responder can respond with an additional ranging command completion message with an unsupported feature error code. The ranging capability response message can include parameters, that is, supported features, software version, number of UWB devices, and UWB device descriptors. 2. Ranging Security Key Request / Response

[0103] The request and response can be used in a handshake for key exchange and can derive a shared secret during pairing. Periodic key refresh can also be used. In some embodiments, the handshake can be performed in all connections and challenges / responses can be implemented. 3. Ranging Start / Stop Request

[0104] The ranging session can be started by sending a ranging start request command that includes a set of parameters. The receiving device can decide to propose different parameters or accept the request by responding with its own ranging start request. If the receiving device decides to accept the request, it can send a ranging start notification event. If secure ranging is required and the security handshake is not complete, this request can be rejected with an additional ranging command completion message with an insufficient authentication error code.

[0105] Examples of ranging start requests can include a minimum ranging interval (e.g., 30 ms), a maximum ranging interval (e.g., 2,550 ms), a ranging offset (e.g., 30 ms to 2,550 ms), and a ranging timeout (e.g., 300 ms to 25.5 s). The ranging interval can define the amount of time between each successive ranging attempt. The minimum and maximum ranging intervals can specify the allowable minimum and maximum ranging periods, for example, in milliseconds. Either a mobile device or a vehicle may request to start ranging.

[0106] The ranging mode can be exited by either a mobile device or a vehicle by sending a ranging stop request. The requested device can respond with a ranging command completed with a success status code. 4. Ranging Event Notification

[0107] Event notifications can be used to encapsulate events generated by central and peripheral devices. The sub-event code can be the first of the event parameters (e.g., the first octet) having the following sub-event parameters. Examples of ranging sub-event types are as follows. That is, ranging command completion sub-event (parameter: status), ranging capability update sub-event (parameters: number of UWB devices and UWB device descriptor), ranging start sub-event (parameters: ranging interval and ranging offset), ranging session state change sub-event (parameter: session state), and ranging device state change sub-event (parameter: device state).

[0108] The ranging command completion sub-event can be sent by the responder and indicate that the command sent by the initiator has been completed. The status parameter can indicate whether the command was successful.

[0109] The ranging capability update sub-event can indicate any change in the availability of UWB sensors for ranging. This event is optional and may be ignored by the receiving device. This event can be used to indicate that the initiator device does not have a subset of UWB sensors that are not available or suitable for initial ranging. The parameter for this event can be the number of UWB devices.

[0110] The ranging start sub-event can be sent in response to a ranging start request from the initiator. The responder can send this event with the received ranging interval and ranging offset. The ranging offset parameter can provide a rough estimate of the start UWB session for this event. By using this event and setting the ranging interval and offset to 0, a one-shot immediate ranging session can be triggered. Previous ranging start request messages are not required for the immediate ranging session. The responder may be ignored by the immediate request. The ranging interval parameter can be set to 30 ms to 2,550 ms and can be set to 0 to request immediate ranging. The ranging offset parameter can be set to 30 ms to 2,550 ms and can be set to 0 to request immediate ranging.

[0111] To indicate the start, progress, and completion of UWB-related actions, a set of ranging session state change sub-events can be generated. These sub-events can be generated by both the mobile device and the vehicle. A security key refresh event may be initiated by the vehicle or the mobile device to request a new set of security keys. Lock and unlock events can be generated by the vehicle after a successful ranging session. Examples of this set of sub-events include the following. That is, a ranging session key refresh sub-event (for example, when the initiator requires a refresh of all security keys), a ranging session lock start sub-event (for example, when the initiator is performing a locking operation), a ranging session lock completion sub-event (for example, when the initiator has completed the locking operation), a ranging session unlock start sub-event (for example, when the initiator is performing an unlocking operation), a ranging session unlock completion sub-event (for example, when the initiator has completed the unlocking operation), a ranging session ignition start sub-event (for example, when the initiator is performing an immobilizer operation), a ranging session ignition completion sub-event (for example, when the initiator has completed the immobilizer operation), and a ranging session timeout sub-event (for example, when the initiator has stopped ranging due to a timeout).

[0112] A set of ranging device state change sub-events can be generated in response to a change in the state of the vehicle or the mobile device. The device state parameter indicates the new state of the initiator. Examples of sub-events include the following. That is, a ranging device invalidation sub-event (for example, when the initiator does not recognize the receiver as a valid key), a ranging device authentication sub-event (for example, when the initiator has completed local authentication of the device), and a ranging device activation sub-event (for example, when the initiator recognizes the receiver as a valid device).

[0113] The ranging device deactivation sub - event can be used by a vehicle to indicate that the mobile device has been deactivated and can no longer perform any action until the mobile device completes user authentication. If the initiator or responder decides to stop any existing ranging session in response to this event, the initiator or responder can send a ranging stop request message.

[0114] The ranging device authentication completion sub - event can indicate that the initiator device has performed the user's local authentication. The responder can accept this event and may enable the initiator device to perform actions on the responder.

[0115] The ranging device activation sub - event can be used by the initiator to indicate that the receiver has been re - activated as a valid device for performing any operation on the initiator. In response to this event, a ranging session can be started by the initiator or the receiver.

[0116] The ranging device can use error codes that closely match its error situation. Exemplary error codes include the following: namely, success, insufficient authentication, ranging timeout, maximum ranging client limit exceeded, and unsupported features. B. Message Sequence

[0117] This section shows an exemplary interaction between a vehicle and a mobile device using ranging service messages. It is assumed that the communication channel has already been established.

[0118] Figure 6 shows ranging interval negotiation according to an embodiment of the present invention. A first ranging start request can be sent by initiator 600 to responder 650. Responder 650 can in response send its own second ranging start request 610, but with a different set of ranging parameters. Ranging exchange messages 615 - 625 can be sent as part of the negotiation of ranging capabilities, for example as defined by the parameters. If the ranging parameters from the remote side are acceptable, responder 650 can send a ranging start sub - event along with the parameters for the ranging session.

[0119] Figure 7 shows key refresh negotiation according to an embodiment of the present invention. A security key refresh request 715 can be initiated by initiator 700 (mobile device or vehicle) after a refresh sub - event 705 and a stop message 710 have been sent, and then the UWB ranging session can be paused. Initiator 700 can provide security parameters for a subsequent ranging session to responder 750, and responder 750 can provide a security key response 720. When the security key is successfully refreshed, initiator 700 can start a new UWB ranging session using a ranging start request message 725 followed by a start sub - event 730.

[0120] The ranging key refresh handshake may need to be completed within a specified time. If the timer expires before the handshake is completed, the ranging session may resume with the current security parameters. The UWB radio may need to resynchronize to compensate for any drift caused by the timeout. V. Ranging Service - Second Protocol

[0121] A description of exemplary messages used for ranging services via a second wireless protocol (e.g., UWB) will be described below along with an exemplary message sequence. Further details of UWB messaging can be found in "IEEE Standard for Low-Rate wireless networks", IEEE Standard 802.15.4 (R) (2016), which is incorporated by reference. A. Protocol

[0122] The UWB ranging start request is an optional message that can indicate the start of a UWB ranging session and enable precise alignment between the initiator and the responder.

[0123] The UWB ranging stop request is an optional message that can indicate the end of a ranging session. The session can end because the keys need to be updated, for example, because ranging between devices is no longer necessary, or because one or more devices desire the end of ranging.

[0124] The UWB ranging start event message can be sent in response to a UWB ranging start request message. The UWB ranging stop event message can be sent in response to a UWB ranging stop request message.

[0125] The UWB ranging exchange message can have the dual purpose of providing an optionally encrypted preamble for secure ranging and transferring the necessary round-trip time timestamps between the initiator and the responder. Exemplary parameters of this message can include the expiration time, transmit and receive timestamps, timestamp uncertainty, timestamp validity, RSSI, and status. This event can be triggered as part of a single bi-directional ranging exchange, or a ranging exchange with more than three directions for either one-to-one ranging or one-to-many ranging.

[0126] Further explanation of exemplary parameters of UWB ranging exchange messages is as follows. The validity timestamp can be absolute time-based. The number of ranging nodes can correspond to the number of valid ranging timestamps in the message. The index (node_x_index) can be an index into the responder node list. The ranging timestamp node_x can correspond to the timestamp of the UWB packet most recently received or transmitted from a particular node. For example, the ranging timestamp uncertainty node_x 1 can have a value range of 1.5 cm to 3.6 m with various confidence levels. RSSI_node_x 1 can be the RSSI of the received packet in dBm. The ranging state node_x can provide the state of node x. Node_x_antenna can define which antenna for node_x to receive or transmit the packet.

[0127] Examples of UWB ranging states can be as follows. That is, success (success of packet reception and transmission), timestamp overflow (timestamp counter overflow), transaction timeout (the transaction is too long and times out), frame is too long, unavailable key (key not available for secure ranging), unsupported security (unsupported secure ranging mode), and unsupported ranging (unsupported ranging mode). B. Message Sequence

[0128] In some embodiments of one-to-one ranging, as soon as a responder can see the first UWB ranging exchange packet, each responder (e.g., UWB radio) can perform a UWB ranging exchange with the initiator. FIG. 6 shows two-sided bidirectional ranging involving three packet exchanges. One optional exchange not shown is the reception time of the final packet at responder 650 that is being sent to initiator 600. This can be performed if the initiator desires to calculate a more accurate range from all the timestamps.

[0129] FIG. 8 shows one-to-many ranging according to an embodiment of the present invention. In one-to-many ranging, for example, after the first UWB ranging exchange packet from the initiator, the initiator and each responder can perform UWB ranging exchange in a predetermined sequential order.

[0130] FIG. 8 shows two-sided bidirectional ranging involving three packet exchanges between initiator 800 and each of three responders 852 - 856. The ranging start request 802 (e.g., using a first wireless protocol) can be received by responders 852 - 856 that can respond with a ranging start event message 804. Responders 1, 2, and 3 each receive the first ranging packet 810 from initiator 800 but respond at different times. They can also all receive the final ranging packet 840 from initiator 800, which may correspond to message 430 in FIG. 4. One optional exchange is the reception time of message 840 at each responder 852 - 856 sent back to initiator 800. This can be performed if initiator 800 desires to calculate a more accurate range from all the timestamps.

[0131] To support one-to-many ranging where a vehicle may include two or more UWB transceivers, special provisioning of addressing can be defined. Using the four least significant bits (LSBs) of the source address and destination address, the intended transceiver can be defined, for example, with possible transceiver IDs from 0x0 to 0xE. In the case of one-to-many ranging, the destination address can be set to a specific value (e.g., 0xF) indicating that the packet is for all transceivers. VI. Method

[0132] FIG. 9 is a flowchart of a method 900 for performing communication between a mobile device and an access control system (e.g., associated with a vehicle or a building) according to an embodiment of the present invention. The method 900 can be executed by a mobile device (or other computing device) that may include one or more processors and a memory storing program code executed by the one or more processors. Aspects of the method 900 can be executed in a manner similar to the method 100.

[0133] In block 910, a first wireless protocol is used (e.g., via a first antenna) to authenticate the access control system. The first wireless protocol can be BT. In the authentication, as described herein, information exchanged during a previously executed pairing process between the mobile device and the access control system (e.g., a vehicle) can be used. The authentication can involve a challenge-response procedure between the mobile device and the access control system. An expected response to a given challenge can be determined using an identifier from the access control system, for example, obtaining a key expected to be used by the access control system to generate a response, and authenticating the response using the key (e.g., by decrypting or regenerating the response). The access control system can also authenticate the mobile device.

[0134] The authentication can be that of the control unit of the access control system. For example, a challenge (e.g., a random number) can be sent to the access control system. The control unit of the access control system (e.g., the ECU in FIG. 3) can operate on the challenge using an encryption key to provide a response. The encryption key can be derived from or be the shared secret established during the pairing of the mobile device with the access control system. The response is received from the access control system and compared with the expected result, thereby enabling the authentication of the control unit of the access control system. As an example, the response can be decrypted and compared with the original challenge, or the mobile device can encrypt the challenge (e.g., using the same encryption key) and compare the result with the received response. As another example of authentication, a digital signature of the control unit of the access control system can be received using a first wireless protocol. The digital signature can be verified using the public key of the control unit, thereby authenticating the control unit of the access control system.

[0135] After authentication, at block 920, a secure channel is created between the mobile device and the access control system (e.g., the control unit of the vehicle) using the shared secret. The secure channel can use a first wireless protocol. The shared secret can be established during the pairing process between the mobile device and the access control system. The shared secret can be used for the authentication at block 910. The creation of the secure channel can be performed by accessing a database (e.g., a table) of paired devices using an identifier obtained from the access control system to determine one or more encryption keys, for example, by deriving or retrieving an Elliptic-curve Diffie-Hellman (ECDH) key pair.

[0136] In block 930, for ranging performed using a second wireless protocol, a secure channel is used to communicate between the access control system and the ranging capability. As an example, the ranging capability can specify, for example, a format for ranging messages between a mobile device and the access control system as described herein. Other examples of ranging capabilities include the number of antennas, the location of those antennas (e.g., the relative distances between the antennas and / or between origins within the access control system such as an ECU), the number of antennas used, the encryption protocol, the packet format, the operating mode, and the supported frequency range.

[0137] In block 940, using a second wireless protocol, a first set of pulses within a ranging request message can be transmitted to the access control system. In the second wireless protocol, a pulse width smaller than the pulse width used by the first wireless protocol can be used. In some embodiments, the first wireless protocol is Bluetooth® (e.g., BTLE) and the second wireless protocol is UWB.

[0138] In block 950, a second set of pulses within one or more ranging response messages is received from the access control system (e.g., using a second antenna). The one or more ranging response messages can be a plurality of ranging response messages (e.g., as shown in FIGS. 4 and 8). Each ranging response message can be from a different antenna unit (e.g., different node) of the access control system, include identification information unique to a particular antenna unit, and such identification information may be encrypted. In some embodiments, the ranging request message can be broadcast to a plurality of ranging response messages (e.g., ranging request 410 of FIG. 4 or as shown in FIG. 8). In other embodiments, separate ranging request messages can be sent to various antenna units.

[0139] In block 960, distance information corresponding to the transmission time(s) of the first pulse set and the reception time(s) of the second pulse set is determined. The distance information can include, for example, timestamps corresponding to the first pulse set in the ranging request message and the second pulse set in one or more ranging response messages, as shown in FIG. 4. The timestamp can be configured to be used, for example, by a control unit of the access control system to determine the distance of the mobile device from the access control system, as described herein.

[0140] In some embodiments, the mobile device can determine the distance. For example, the mobile device can use the transmission time(s) of the first pulse set and the reception time(s) of the second pulse set to determine the distance. Accordingly, the distance information can include the distance.

[0141] In block 970, the distance information is transmitted to the access control system, thereby enabling the access control system to perform an operation. The distance information can be transmitted using either a first wireless protocol (e.g., using a secure channel) or a second wireless protocol. In various embodiments, the operation can be unlocking a door of the access control system (e.g., all doors, or a specific door based on user access privileges, or the nearest door), turning on a heater or an air conditioner, or enabling a start button of a vehicle. Any such operation can be triggered based on a distance or a rate of change of distance (e.g., speed towards the vehicle) that exceeds a threshold. A plurality of such thresholds can be used, for example, for different operations, as described herein. VII. Exemplary Devices

[0142] FIG. 10 is a block diagram of an exemplary device 1000 that can be a mobile device. Device 1000 generally includes a computer-readable medium 1002, a processing system 1004, an input / output (I / O) subsystem 1006, a wireless circuit 1008, and an audio circuit 1010 including a speaker 1050 and a microphone 1052. These components can be coupled by one or more communication buses or signal lines 1003. Device 1000 can be any portable electronic device including, but not limited to, a handheld computer, a tablet computer, a mobile phone, a laptop computer, a tablet device, a media player, a personal digital assistant (PDA), a key fob, an automobile key, an access card, a multifunctional device, a mobile phone, a portable gaming device, a display unit for an automobile, etc. (including combinations of two or more of these items).

[0143] The architecture shown in FIG. 10 is merely an example of an architecture for device 1000, and it is apparent that device 1000 can have more components, fewer components, or components of a different configuration than those shown. The various components shown in FIG. 10 can be implemented as hardware, software, or a combination of both hardware and software, including one or more signal processing circuits and / or application-specific integrated circuits.

[0144] Use the wireless circuit 1008 to transmit and receive information with the conventional circuits of one or more other devices, such as an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a codec chipset, a memory, etc., via a wireless link or network. The wireless circuit 1008 can use various protocols as described herein, for example. For example, the wireless circuit 1008 can have one component for one wireless protocol (e.g., Bluetooth (registered trademark)) and a separate component for another wireless protocol (e.g., UWB). Different antennas can be used for different protocols.

[0145] The wireless circuit 1008 is coupled to the processing system 1004 via the peripheral device interface 1016. The interface 1016 can include conventional components to establish and maintain communication between the peripheral device and the processing system 1004. The voice and data information received by the wireless circuit 1008 (e.g., in a speech recognition application or a voice command application) is transmitted to one or more processors 1018 via the peripheral device interface 1016. The one or more processors 1018 can be configured to process various data formats for one or more application programs 1034 stored on the medium 1002.

[0146] The peripheral device interface 1016 couples the input / output peripheral devices of the device to the processor 1018 and the computer-readable medium 1002. The one or more processors 1018 communicate with the computer-readable medium 1002 via the controller 1020. The computer-readable medium 1002 can be any device or medium capable of storing code and / or data for use by the one or more processors 1018. The medium 1002 can include a memory hierarchy including a cache, main memory, and secondary memory.

[0147] Device 1000 also includes a power system 1042 that supplies power to various hardware components. The power system 1042 can include a power management system, one or more power sources (e.g., batteries, alternating current (AC)), a recharge system, a power outage detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)), and any other components typically associated with the generation, management, and distribution of power within a mobile device.

[0148] In some embodiments, device 1000 includes a camera 1044. In some embodiments, device 1000 includes a sensor 1046. The sensor 1046 can include an accelerometer, a compass, a gyroscope, a pressure sensor, an audio sensor, an optical sensor, a barometer, and the like. The sensor 1046 can be used to sense aspects of a location, such as an auditory or optical signature of the location.

[0149] In some embodiments, device 1000 can include a GPS receiver, sometimes referred to as a GPS unit 1048. The mobile device can obtain location information, timing information, altitude, or other navigation information using a satellite navigation system such as the Global Positioning System (GPS). During operation, the GPS unit can receive signals from GPS satellites orbiting around the Earth. The GPS unit analyzes the signals to perform travel time and distance estimations. The GPS unit can determine the current position (current location) of the mobile device. Based on these estimations, the mobile device can determine its location fix, altitude, and / or current speed. The location fix can be in the form of geographical coordinates such as latitude information and longitude information.

[0150] One or more processors 1018 execute various software components stored in the medium 1002 to perform various functions for the device 1000. In some embodiments, the software components include an operating system 1022, a communication module (or instruction set) 1024, a location determination module (or instruction set) 1026, a ranging module 1028 used as part of the ranging operations described herein, and other applications (or instruction sets) 1034.

[0151] The operating system 1022 can be any suitable operating system, including an embedded operating system such as iOS, MacOS, Darwin, RTXC, LINUX, UNIX, OSX, WINDOWS, or VxWorks. The operating system can include procedures, sets of instructions, software components, and / or drivers for controlling and managing common system tasks (such as memory management, storage device control, power management, etc.), and facilitating communication between various hardware components and software components.

[0152] The communication module 1024 includes various software components for facilitating communication with other devices via one or more external ports 1036 or via the wireless circuitry 1008, and for handling data received from the wireless circuitry 1008 and / or the external ports 1036. The external ports 1036 (such as USB, FireWire®, Lightning connector, 60-pin connector, etc.) are adapted to couple directly to other devices or indirectly via a network (such as the Internet, a wireless LAN, etc.).

[0153] The location determination / movement module 1026 can assist in determining the current location (e.g., coordinates or other geographical location identifiers) and the movement of the device 1000. The latest positioning systems include satellite-based positioning systems such as the Global Positioning System (GPS), cellular network positioning based on "cell ID", and Wi-Fi positioning technology based on Wi-Fi networks. Also, GPS determines an estimated position value based on the visibility of multiple satellites. The satellites may not be visible (or the signal may be weak) indoors or in "valleys between buildings". In some embodiments, the location determination / movement module 1026 receives data from the GPS unit 1048 and analyzes the signal to determine the current position of the mobile device. In some embodiments, the location determination / movement module 1026 can use Wi-Fi or cellular positioning technology to determine the current location. For example, the location of the mobile device can be estimated using knowledge of nearby cell sites and / or Wi-Fi access points and knowledge of their locations. Information identifying the Wi-Fi or cellular transmitter is received by the wireless circuit 1008 and transmitted to the location determination / movement module 1026. In some embodiments, the location determination module receives one or more transmitter IDs. In some embodiments, a series of transmitter IDs can be compared with a reference database (e.g., a cell ID database, a Wi-Fi reference database). The reference database maps or correlates the transmitter ID to the location coordinates of the corresponding transmitter and calculates estimated location coordinates for the device 1000 based on the location coordinates of the corresponding transmitter. Regardless of the specific location determination technology used, the location determination / movement module 1026 receives information that can lead to a location fix, interprets that information, and returns location information such as geographical coordinates, latitude / longitude, or other location fix data.

[0154] The ranging module 1028 can transmit a ranging message to and receive it from, for example, an antenna connected to the wireless circuit 1008. For various purposes, for example, to identify the vehicle's transmission antenna, to determine the time stamp of a message (e.g., for transmission to the vehicle), and potentially to determine the distance from the vehicle to the mobile device 1000, the message can be used.

[0155] One or more application programs 1034 on the mobile device can include, without limitation, any application installed on the device 1000, including a browser, address book, contact list, email, instant messaging, word processing, keyboard emulation, widgets, Java-enabled applications, encryption, digital rights management, voice recognition, voice replication, a music player (for playing prerecorded music recorded in one or more files such as MP3 or AAC files), etc.

[0156] There may be other modules or instruction sets (not shown), such as a graphics module, a time module, etc. For example, the graphics module can include various conventional software components for rendering, animating, and displaying graphic objects (including, without limitation, text, web pages, icons, digital images, animations, etc.). In another example, the timer module can be a software timer. The timer module can also be implemented in hardware. The time module can maintain various timers for any number of events.

[0157] The I / O subsystem 1006 can be coupled to a display system (not shown), which can be a touch-sensitive display. The display system presents a visual output to the user on the GUI. This visual output can include text, graphics, video, and any combination thereof. Some or all of the visual output can correspond to user interface objects. The display can use LED (light-emitting diode), LCD (liquid crystal display) technology, or LPD (light-emitting polymer display) technology, although other display technologies can be used in other embodiments.

[0158] In some embodiments, the I / O subsystem 1006 can include a display and user input devices such as a keyboard, mouse, and / or trackpad. In some embodiments, the I / O subsystem 1006 can include a touch-sensitive display. The touch-sensitive display can also receive input from the user based on tactile contact and / or haptic contact. In some embodiments, the touch-sensitive display forms a touch-sensitive surface for receiving user input. The touch-sensitive display / touch-sensitive surface (along with any associated modules and / or instruction sets within the medium 1002) detects contact (and any movement or release of the contact) on the touch-sensitive display and converts the detected contact into an interaction with user interface objects (such as one or more soft keys) displayed on the touch screen when the contact occurs. In some embodiments, the point of contact between the touch-sensitive display and the user corresponds to one or more fingers of the user. The user can contact the touch-sensitive display using any suitable object or appendage such as a stylus, pen, finger, etc. The touch-sensitive display surface can detect contact and any movement or release thereof using any suitable touch-sensing technology. Examples of touch-sensing technology include capacitive, resistive, infrared, and surface acoustic wave technology, as well as other proximity sensor arrays or other elements that determine one or more points of contact with the touch-sensitive display.

[0159] Furthermore, to control or execute various functions such as power control, speaker volume control, incoming call volume, keyboard input, scrolling, hold, menu, screen lock, and clearing and ending communication, the I / O subsystem can be coupled to one or more other physical control devices (not shown) such as push buttons, keys, switches, rocker buttons, dials, slider switches, sticks, LEDs, etc. In some embodiments, in addition to the touch screen, device 1000 can include a touch pad (not shown) for activating or deactivating specific functions. In some embodiments, the touch pad, unlike the touch screen, is a touch-sensing area of the device that does not display visual output. The touch pad can be a touch-sensing surface separate from the touch-sensing display or an extension of the touch-sensing surface formed by the touch-sensing display.

[0160] In some embodiments, some or all of the operations described herein can be performed using an application that runs on the user's device. Circuits, logic modules, processors, and / or other components can be configured to perform the various operations described herein. Those skilled in the art will appreciate that such configurations can be realized through specific component design, setup, interconnection, and / or programming depending on the implementation form, and similarly, depending on the implementation form, the configured components may or may not be reconfigurable for different operations. For example, a programmable processor can be configured by providing suitable executable code, and a dedicated logic circuit can be configured by suitably connecting logic gates and other circuit elements.

[0161] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language, such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, for example, using conventional or object-oriented techniques. The software code may be stored on a computer-readable medium as a series of instructions or commands for storage and / or transmission. Suitable non-transitory computer-readable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard drives or floppy disks, or optical media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, and the like. The computer-readable medium may be any combination of such storage devices or transmission devices.

[0162] Computer programs incorporating various features of the present disclosure may be encoded on various computer-readable storage media, suitable media including magnetic disks or tapes, optical storage media such as compact discs (CDs) or digital versatile discs (DVDs), flash memory, and the like. The computer-readable storage media encoded with program code may be packaged with compatible devices or provided separately from other devices. Additionally, the program code may be encoded and transmitted via various wired and / or wireless networks compliant with various protocols, including the Internet, such that distribution is possible, for example, via Internet download. Any such computer-readable medium may be on or within a single computer product (e.g., a solid-state drive, hard drive, CD, or an entire computer system) or may exist on or within different computer products within a system or network. The computer system may include a monitor, printer, or other suitable display for providing any of the results described herein to a user.

[0163] Although the present disclosure has been described with respect to specific embodiments, it is to be understood that the present disclosure is intended to cover all modifications and equivalents falling within the scope of the following claims.

[0164] References to "a," "an," or "the" are intended to mean "one or more" unless specifically stated to the contrary. When used with "or," it is intended to mean "inclusive or" rather than "exclusive or" unless specifically stated to the contrary. References to a "first" element do not necessarily require that a second element be provided. Further, references to a "first" or "second" element do not, unless otherwise stated, limit the recited component to a particular location.

[0165] All patents, patent applications, publications, and descriptions referred to in this specification are hereby incorporated by reference in their entirety for all purposes. There is no admission that any of the foregoing is prior art.

Claims

1. A method for performing communication between a mobile device and an access control system, the method comprising, by the mobile device, starting a ranging session between the access control system and the mobile device using a first wireless protocol and a set of security keys for determining the distance of the mobile device from the access control system; after the ranging session using the first wireless protocol is paused, communicating a security key refresh request to the access control system using a communication channel; communicating a security key response to the access control system using the communication channel, the security key response providing a new set of security keys; in response to receiving the security key response, starting a new ranging session using the first wireless protocol with the new set of security keys, thereby enabling the access control system to perform operations; comprising performing.

2. The method according to claim 1, wherein starting the new ranging session comprises transmitting a first set of pulses in a ranging request message to the access control system; receiving a second set of pulses in one or more ranging response messages from the access control system; determining the transmission time(s) of the first set of pulses and the reception time(s) of the second set of pulses; transmitting the transmission time(s) and the reception time(s) to the access control system; including, The one or more ranging response messages include a plurality of ranging response messages from a plurality of antenna units of the access control system, each ranging response message being from an individual antenna unit of the plurality of antenna units and including identification information unique to the individual antenna unit. Method. **Claim 3** The method according to claim 2, wherein the ranging request message is broadcast to the plurality of antenna units. Method. **Claim 4** The method according to claim 2, further comprising: determining a distance of the mobile device from the access control system using the transmission time(s) of the first pulse set and the reception time(s) of the second pulse set. A method comprising the above. **Claim 5** The method according to claim 2, further comprising: transmitting a time stamp corresponding to the first pulse set in the ranging request message and the second pulse set in the one or more ranging response messages to the access control system, the time stamp being configurable to be used by a control unit of the access control system to determine a distance of the mobile device from the access control system. Method. **Claim 6** The method according to claim 1, wherein the operation is unlocking a door of the access control system. Method. **Claim 7** The method according to claim 1, wherein the communication channel uses a second wireless protocol. Method. **Claim 8** The method according to claim 7, wherein the first wireless protocol is Ultra Wide Band (UWB), the second wireless protocol is Bluetooth (registered trademark), the first wireless protocol uses a first antenna, the second wireless protocol uses a second antenna, and the mobile device is a mobile phone. Method.

9. The method according to claim 1, wherein the access control system is a vehicle. Method.

10. The method according to claim 1, further comprising communicating a stop message to the access control system in response to a key refresh sub-event before communicating the security key refresh request, wherein the ranging session is paused in response to the stop message. A method comprising the above.

11. The method according to claim 7, wherein the first wireless protocol uses a pulse width smaller than the pulse width used by the second wireless protocol. Method.

Images