Low-latency vehicle access with phone as key

Abstract

The present disclosure provides "low-latency vehicle access with phone as a key". A phone as a key (PaaK) system includes: a preprocessor; a security processor, the security processor is configured to communicate with the preprocessor; a cache memory, the cache memory is associated with the preprocessor and the security processor; and a memory, the memory is used to store executable instructions. The preprocessor and the security processor are configured to perform steps that can reduce delays caused by mobile device authentication. For example, the preprocessor authenticates an authentication message associated with a mobile device used as a vehicle key and stores the message in the cache memory. The preprocessor receives a door latch actuation signal and, in response, initializes the security processor. The preprocessor then provides access to the vehicle based on the security processor initialization instructions and the authentication message stored in the cache memory.

Description

Technical Field

[0001] The present disclosure relates to passive vehicle entry systems, and more particularly, to a system for wireless passive entry passive start providing vehicle access using a mobile device. Background Art

[0002] Phone-as-a-Key (PaaK) systems use a personal area network (e.g., using a Low Energy (BLE) protocols) to detect and locate mobile phones without the need for dedicated antennas and controllers for wireless communications. To maximize availability and minimize energy use, a PaaK-enabled vehicle can cycle from a low-power mode after being parked for long periods of time to a higher-power mode when a user actuates a door handle or performs another action to "wake up" the vehicle.

[0003] U.S. Patent No. 9,351,102 assigned to Apple, Inc. (hereinafter referred to as the "'102 publication") discloses a mobile device for accessing a vehicle by transmitting an activation message including a vehicle access credential. The mobile device in the '102 publication sends an authorization code to the vehicle, and the vehicle compares the code to a locally stored code. Although the method disclosed in the '102 publication uses the credential to activate a higher energy consumption mode in a parked vehicle, the current method does not disclose the use of pre-authenticated messages, caching messages, using a new set of messages to confirm authenticity after unlocking the vehicle, and issuing an alarm or performing other remedial actions if such messages are not confirmed. Summary of the invention

[0004] The present disclosure relates to reducing latency in a phone-as-a-key (PaaK) system. A vehicle PaaK system determines and monitors the location of a PaaK-enabled mobile device relative to a vehicle location in order to broadcast a pre-authentication message to the mobile device. When the mobile device is close to a predetermined communication range relative to the vehicle location, the mobile device may transmit a preliminary response message to the PaaK-enabled vehicle. The vehicle PaaK system may cache the preliminary response message until a user associated with the authentication device performs an unlocking action, such as actuating a door latch / unlock mechanism by pulling a door handle, for example. The PaaK system may unlock the door using data that has been sent to a preprocessor to perform a first level of authentication without the delay associated with a full authentication step. After actuating the door latch, the PaaK system may use a security processor to perform post-authentication confirmation by transmitting a verification message including a challenge value requiring a verification response from the requesting device and using the security processor to authenticate the response. A response message that correctly replies to the verification message may confirm the authenticity of the requesting device, and no further mitigation actions are taken. The PaaK system may perform one or more mitigation actions in response to an incorrect or unreceived verification response. Mitigation actions may include logging the event with a diagnostic trouble code (DTC), offloading the DTC for further analysis on a server, triggering an alarm, sending a notification of a potential safety issue to the owner of the vehicle, blocking the vehicle ignition, prohibiting shifting the vehicle out of park, limiting the vehicle's travel speed, and other possible actions. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Detailed description is set forth with reference to the accompanying drawings. The use of the same reference numerals may indicate similar or identical items. Various embodiments may utilize elements and / or components other than those shown in the accompanying drawings, and some elements and / or components may not be present in various embodiments. The elements and / or components in the accompanying drawings are not necessarily drawn to scale. Throughout this disclosure, singular terms and plural terms may be used interchangeably, depending on the context.

[0006] Figure 1 An exemplary computing environment is depicted in which techniques and structures for providing the systems and methods disclosed herein may be implemented.

[0007] Figure 2 An exemplary embodiment of the present disclosure is shown in which a car computer is configured with a PaaK system to provide vehicle access using a pre-processor and a security processor.

[0008] Figure 3 Another exemplary embodiment of the present disclosure is shown, wherein Figure 2 The vehicle computer uses a secure processor to determine authenticity after providing access according to the embodiments described herein, and performs remedial actions in response to failed authentication.

[0009] Figure 4 A block diagram of an exemplary computer system for practicing the embodiments described herein is shown. DETAILED DESCRIPTION

[0010] The present disclosure can reduce the delay associated with unlocking a PaaK-enabled vehicle using a mobile device, and improve vehicle security using a post-unlock verification step that confirms the device authenticity of the PaaK-enabled mobile device. In this way, the PaaK system and method of using the same as described herein can improve security while minimizing or eliminating any delays associated with the unlocking and authentication steps. It should be understood that the mechanisms disclosed herein can be applied to additional passive entry devices that utilize similar wireless communication protocols. These devices can include Bluetooth key fobs and NFC access cards with additional wireless capabilities.

[0011] These and other advantages of the present disclosure are provided in greater detail herein.

[0012] The present disclosure will be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments of the disclosure are shown and which are not intended to be limiting.

[0013] Figure 1 An exemplary computing environment 100 is depicted, which may include a vehicle 105 configured with and / or as part of a phone-as-a-key (PaaK) system 107, which may include and / or be configured to communicate with one or more servers 161 and a mobile device 123. The mobile device 123 may be communicatively coupled to the vehicle 105 and / or the server 161 via one or more networks 125, which may transmit data using one or more wireless channels 133. The mobile device 123 may include and / or be configured to execute an application 135. The application 135 may perform information retrieval steps that provide information to the server 161, which may be used to provide access to the vehicle 105 as described herein. The application 135 may also authenticate a vehicle user, such as a user 143 of the vehicle 105, by authenticating the mobile device 123 on which the application 135 may operate.

[0014] The vehicle 105 may include a vehicle computer 148 having a processor 151 and a memory 157. The vehicle 105 may also include a vehicle telematics control unit (TCU) 163, which may be configured to communicate with and / or be a part of the vehicle computer 148. In some exemplary embodiments, the vehicle TCU 163 may transmit information to and receive communications from the mobile device 123 and / or one or more servers 161, which may be connected to a telematics service delivery network (SDN) ( Figure 1 The vehicle 105 may also receive a global positioning system (GPS) 178 and / or be configured to communicate with the GPS.

[0015] Although illustrated as a sport utility vehicle, the vehicle 105 may also take the form of any passenger or commercial vehicle, such as, for example, a car, a truck, a crossover vehicle, a van, a minivan, a taxi, a bus, a work vehicle, etc. In addition, the vehicle 105 may be a manually driven vehicle, and / or be configured to operate in a fully autonomous (e.g., unmanned) mode and / or a partially autonomous mode, and may include any powertrain, such as, for example, a gasoline engine, one or more electric actuation motors, a hybrid powertrain, etc.

[0016] According to an exemplary embodiment, the user 143 can control one or more applications 135 operating on the mobile device 123 to transmit a wake-up message to the vehicle TCU 163 and the vehicle computer 148. The wake-up message can cause the vehicle computer 148 (and more accurately, the security processor 155) to transition from a low energy state (sleeping or powered off) to a higher energy state (e.g., activated and ready to process computer instructions from memory, perform authentication steps, etc.). The low energy state and the higher energy state are generally referenced herein to describe the operating states associated with the vehicle TCU 163 and the vehicle computer 148. The energy state is associated with a corresponding energy consumption rate, wherein power can be drawn from a stored power source on the vehicle (such as a vehicle battery or battery pack ( Figure 1 Not shown)) consumption.

[0017] It should be appreciated that the vehicle TCU system can place the vehicle TCU 163 in a low power state when the vehicle is parked to allow and / or limit vehicle functions. In one aspect, the low power state can limit wireless communications between the vehicle TCU 163 and other devices (e.g., mobile devices 123) within the communication range of the vehicle 105, and prevent other types of wireless communications with the vehicle TCU 163 when in the low power state to save battery power when parked for long periods of time. An exemplary technique for TCU power consumption state management is described in U.S. Patent No. 9,462,545 assigned to Ford Global Technologies LLC (hereinafter referred to as the "'545 patent", which is incorporated herein by reference). The '545 patent describes a system that places a vehicle TCU in a sleep mode and activates a higher power consumption mode (e.g., a TCU extended power consumption mode) to establish a data session with a telecommunications network. These non-limiting examples for low power consumption modes and higher power consumption modes are presented to provide examples only, and are not intended to limit the functionality that may be enabled, disabled, and / or otherwise altered by changing the TCU power consumption state.

[0018] For example, the preprocessor 153 may remain active (that is, receiving continuous power) in a low energy state such that clock time information, date information, etc. are maintained while keeping the security processor 155 powered off or otherwise in a limited power consumption mode. Thus, the preprocessor 153 may receive one or more BLE signals from the mobile device 123 and trigger a higher energy state based on the proximity of the mobile device 123 to the vehicle 105. An exemplary system for moving a PaaK system from a low energy state to a higher energy state is described in U.S. Patent No. 10,244,476 B2 assigned to Ford Global Technologies, LLC, which is incorporated herein by reference.

[0019] A passive entry passive start (PEPS) zone may be a zone defined by a radius having a predetermined distance from the vehicle 105. The predetermined distance may be, for example, one meter, three meters, five meters, etc. In an exemplary embodiment, the vehicle 105 sensors may determine that the mobile device 123 is within the PEPS zone and is approaching the vehicle using a receiving antenna associated with the PaaK system. Using the antenna, the vehicle 105 may wirelessly connect to a configured low energy transponder (e.g., a BLE transponder) of the mobile device 123. The BLE signal may include power consumption mode instructions from the mobile device, which may be configured to change the power consumption mode state of the vehicle TCU 163 and / or the vehicle computer 148 from a low energy state to a higher energy state based (at least in part) on authentication messages and verification of those received messages by the security processor 155.

[0020] In some aspects, the mobile device 123 can establish one or more wireless channels 133 between the mobile device 123 and the vehicle TCU 163 and communicate with the vehicle 105 via the wireless channels 133. The wireless channels 133 can be encrypted or unencrypted. The mobile device 123 can use a wireless transceiver ( Figure 1 163). The wireless transceiver may communicate with the mobile device 123 via a wireless communication network such as, for example, one or more networks 125.

[0021] The one or more networks 125 illustrate one example of a communication infrastructure in which the connected devices depicted in the computing environment 100 can communicate. The one or more networks 125 can be the Internet, a private or public network, or another configuration. The network 125 can use and / or include known communication protocols such as, for example, Transmission Control Protocol / Internet Protocol (TCP / IP), Low energy (BLE), Wi-Fi, ultra-wideband (UWB), and one or more cellular network technologies, such as, for example, time division multiple access (TDMA), code division multiple access (CDMA), high-speed packet access (HSPDA), long-term evolution (LTE), global system for mobile communications (GSM), and fifth generation (5G), to name a few. Network 125 may also include and / or embody a vehicle-to-vehicle (V2V) network, such as 1, for example, a dedicated short-range communication (DSRC) network associated with an intelligent transportation system (ITS). In one aspect, network 125 may also include a vehicle ad hoc network (VANET) or a mobile ad hoc network (MANET).

[0022] The vehicle TCU 163 can provide communication with and control access to multiple vehicle computing modules, such as, for example, a controller area network (CAN) bus 183, one or more engine control modules (ECM) 189, a transmission control module (TCM) 193, and / or a body control module (BCM) 198. Control of and / or communication with other control modules not shown is possible, and such control is contemplated. In some aspects, the vehicle telematics control unit (TCU) 163 can control various aspects of the vehicle 105 through the control modules 183, 189, and 193, and implement one or more instruction sets received from the application 135 operating on the mobile device 123. In some aspects, the vehicle computer 148 can control the TCU 163 to provide vehicle functions in response to a determination associated with the authentication of the mobile device 123, and perform actions such as sounding an alarm, transmitting a message, and other functions. In other aspects, the vehicle computer 148 can also be directly interfaced to one or more other vehicle modules (e.g., BCM 198) without communicating with the TCU 163.

[0023] The car computer 148 may include a processor 151 and may also include a computer readable memory 157. According to the present disclosure, the car computer 148 may be installed in the engine compartment of the vehicle 105 (or elsewhere in the vehicle 105) as part of the PaaK system 107.

[0024] In other embodiments, the vehicle TCU 163 may be integrated and / or merged with the vehicle computer 148. For simplicity, the computing system architecture of the vehicle computer 148 may omit certain computing modules. Figure 1 The computing environment 100 depicted in FIG. 1 is one example of possible implementations according to the present disclosure and, therefore, should not be considered limiting or exclusive.

[0025] The one or more processors 151 may be configured to communicate with one or more memory devices (e.g., memory 157 and / or one or more external databases ( Figure 1157) communications. One or more processors 151 may utilize memory 157 to store programs and / or store data in code to perform various aspects of the present disclosure, such as authenticating messages received from mobile devices 123, which may be configured as part of the PaaK system 107, for generating security processor initialization instructions in response to various sensor signals received from sensors connected to the TCU, and for providing access to the vehicle 105. The key-on request may be an actuation of a door latch, a touch of a door handle or a keyless entry keypad, presence detection by a camera or other electromagnetic sensing, or another similar action. Providing access may include, for example, unlocking a latch mechanism, opening a door, automatically opening a door when an authorized user is detected, unlocking a locking mechanism, turning off an alarm sound, disabling an immobilizer and unlocking an electronic steering column lock, or performing another function associated with the operation of the vehicle 105.

[0026] Memory 157 may be a non-temporary computer-readable memory. Processor 151 may be configured to execute computer-executable instructions stored in memory 157 for performing various functions of the PaaK system and for performing vehicle control capabilities according to the present disclosure. Therefore, memory 157 may be used to store code and / or data code and / or data for performing operations according to the present disclosure. Memory 157 may include any one or combination of volatile memory elements (e.g., dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc.), and may include any one or more non-volatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electronically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.).

[0027] The memory 157 may be an example of a non-transitory computer-readable medium and may be used to store programs in code form and / or store data to perform various operations according to the present disclosure. The instructions in the memory 157 may include one or more separate programs, each of which may include an ordered list of computer-executable instructions for implementing logical functions. In another exemplary implementation, some or all components of the vehicle computer 148 may be shared with the vehicle TCU 163.

[0028] The memory 157 may store various code modules, such as, for example, a pre-processor communication controller ( 102 ) for establishing one or more wireless channels 133 between the mobile device 123 and the vehicle 105 . Figure 1 The memory 157 may also store a secure communication controller ( Figure 1), such other functionality as message generation associated with authenticating the mobile device 123 for use as a key (e.g., as part of the PaaK system 107), and providing physical and / or operational access to the vehicle 105 (e.g., by unlocking the doors 159 and / or actuating one or more vehicle modules via the TCU 163).

[0029] The memory 157 may also store code modules for establishing communications between the vehicle TCU 163, the vehicle computer 148, the server 161, and the mobile device 123. In an exemplary embodiment, the memory 157 may store an instruction set received from one or more servers 161 and / or mobile devices 123, which may include an analytical model for predicting when the user 143 will approach the vehicle 105 to initiate a key-on event. In another embodiment, the memory 157 may store authentication information associated with the vehicle 105, information associated with the user 143 and / or the mobile device 123, credentials for authentication purposes (such as, for example, a public key and / or a private key), and / or information associated with an application 135 operating on the mobile device 123. The memory 157 may also store information related to the following regarding Figure 2 and Figure 3 Describes the instructions associated with the steps.

[0030] Server 161 may be and / or include one or more cloud computing mainframe computing platforms configured to receive data from vehicle 105 and / or other vehicles in the fleet ( Figure 1 The key-on event data 165 may be a centralized storage service associated with a data storage device for the PaaK system 107 and may include information associated with a user's access to the vehicle 105. For example, the key-on event data 165 may include authentication information and encryption keys, such as public key data 167, which may be stored for authenticating the mobile device 123, the key fob 179, or the like. Figure 1The key-on event data 165 may also include key fob data 169, which may be used to store information for authenticating the key fob 179 and / or associating the key fob 179 with the user 143 and / or the mobile device 123. The key-on event data 165 may also include user-level data 171 that may be associated with the user 143, including identification information, biometric information, password credentials, persistent user access tokens (such as OAuth2 tokens), address information, and / or other user-specific information (such as, for example, user schedule information and vehicle usage pattern information) associated with the user 143. The key-on event data 165 may also include vehicle-level data 175 that may be used to store information.

[0031] Although described in this section with respect to user 143 and vehicle 105, it should be understood that key-on event data 165 may include and / or be associated with user data from any number of users, vehicles, etc. For example, server 161 may also include a telematics SDN ( Figure 1 ) and / or is configured to communicate with the SDN, the SDN and the fleet ( Figure 1 Vehicle TCU communications associated with other vehicles (not depicted).

[0032] The vehicle 105 (and more specifically, the vehicle TCU 163) can transmit key-on event data 165 to the server 161 at predetermined intervals during the course of daily vehicle use. For example, the usage data can be transmitted by the TCU and / or received by the server 161 at periodic intervals (one hour, one day, one week, etc.). The usage data can include date information and time information associated with the time when the user 143 historically approached the vehicle 105, unlocked the vehicle 105, operated the vehicle 105, etc. These events are collectively referred to herein as key-on events, and the date, time, and other information are referred to herein as key-on event data 165. In other aspects, the vehicle TCU 163 can transmit the key-on event data 165 to the server 161 in response to receiving a request from the server 161.

[0033] The key fob data 169 may include information associated with a key fob 179 that is paired with the vehicle 105 and is configured to control aspects of the operation of the vehicle 105. For example, the key fob may be used to control vehicle locking, unlocking, arming / disarming, light control, starting, etc. Thus, the key fob data 169 may include a key fob identifier ( Figure 1), the key fob identifier uniquely associating the key fob 179 with the user 143, the vehicle 105, the vehicle TCU 163, and / or the mobile device 123. In some aspects, the key fob usage data may also include frequency information, signal strength information, time information, date information, location data, VIN, vendor, number of vehicles paired with the key fob, number of key fobs paired with vehicles, and / or other information that may be associated with determining a pattern associated with usage of the user 143 and the vehicle 105 and may be used to verify access via a verification response to an authentication message.

[0034] According to another embodiment, server 161 may access calendar information and / or other schedule information with specific event dates and times to determine user-level data 171 associated with user 143. Thus, user-level data 171 may include schedule information associated with user 143, which may be specific to that individual. User-level data 171 may include, for example, schedule information associated with a digital calendar ( Figure 1 143), and a pattern associated with the user 143, wherein the pattern indicates that the key-on event 165 occurs on a particular day of the week, at a particular time of the day, on a particular calendar day, etc. The user-level data 171 may also include information associated with the user 143, with which one or more challenge values ​​may be specific to the user 143, known only to the user 143, and / or set by the user 143. For example, the security processor 155 may save a working copy of the user-level data 171 in the memory 157 of the vehicle computer 148, and use the user-level data 171 (or a copy thereof) to formulate a challenge value sent from the vehicle computer 148 to the mobile device 123.

[0035] The pre-processor 153 may receive the authentication message 181 from the mobile device 123 and store the authentication message 181 in the memory 157 for preliminary authentication purposes when the mobile device 123 later approaches the vehicle 105. By storing the authentication message 181 in the memory 157, the PaaK system 107 may reduce or eliminate any delays in providing secure access to the vehicle 105 (e.g., by unlocking the door upon first touch without delaying the unlock instruction until the security processor 155 can initialize, generate a new authentication message, wait for the mobile device 123 to respond, and process the resulting authentication message 181).

[0036] When the mobile device 123 is within the PEPS zone, the pre-processor 153 may provide initial access to the vehicle 105. Determining that the mobile device 123 is proximate to the vehicle 105 and within the PEPS zone in conjunction with one or more other triggering factors may cause a pre-authorization step to begin. For example, the pre-processor 153 may generate a security processor initialization instruction in response to a door latch opening or a user touching a door handle or a sensing area of ​​a keyless entry keypad or presence detection by a camera or other electromagnetic sensing. The pre-processor 153 may receive sensor output indicating an attempt to enter the vehicle.

[0037] The handle touch itself does not trigger the unlock command. Rather, in an exemplary embodiment, the touch of the door handle 160 plus the proximity indication associated with the position of the mobile device 123 relative to the vehicle 105 can cause the door handle sensor ( Figure 1 The preprocessor 153 may receive the vehicle sensor output associated with the actuation of the door handle 160 (and more precisely, associated with the actuation of the door latch mechanism 197 of the door handle 160), and in response, generate a security processor initialization instruction to the security processor 155.

[0038] The pre-processor 153 can also provide access to the vehicle 105 by unlocking the door 159 in conjunction with the security processor 155 based on the key-on request 165 and / or the authentication message 181 stored in the cache memory of the vehicle computer 148. The security processor initialization instruction can initialize the security processor 155 by sending an instruction to "wake up" the security processor 155, which is achieved by changing the power consumption mode profile from a low-power state to a higher-power state. After initialization, the security processor 155 can verify the authentication message 181 stored in the cache memory of the vehicle computer 148 before unlocking the door 159.

[0039] The initialization instructions may cause the security processor 155 to change the power consumption mode profile from a low power consumption mode to a higher power consumption mode based on (at least in part) an authentication message received from the mobile device and / or based on an actuation of the door handle 160. The preprocessor 153 may begin to perform other authorization steps described in more detail below in response to these triggering factors. For example, the security processor initialization instructions may trigger the security processor 155 to generate an authorization message including one or more challenge values ​​for the mobile device 123 (and / or application 135). The challenge value may be a question with an answer specific to user information, such as a conventional password recovery challenge value. In other aspects, the challenge value may be a request for encryption key information associated with a public / private key set (associated with an encrypted password or other data) (this may not require user input, but rather a response is automatically generated by the application 135 on the mobile device 123).

[0040] The mobile device 123 may generate an output based (at least in part) on a challenge value transmitted by the vehicle computer 148. In one aspect, the user 143 (and more specifically, the mobile device 123) may receive an output message indicating the challenge value and select or enter an answer that only the user 143 and / or the user device 123 may know. In other words, the challenge value may be an electronic request for a response from the mobile device 123, the response including a private key stored thereon, or it may be an electronic request for a response from the mobile device 123, the response including a user input in response to a verification question. An example of the latter may be, for example, selecting the user's undergraduate college from a list with multiple selections. The purpose of the challenge-question and response may be to determine whether the preliminary vehicle access provided to the mobile device 123 is correct.

[0041] After the security processor 155 has verified user access using a subsequent authentication step, the PaaK system 107 can prove within a reasonable or predetermined level of probability that the requesting device (i.e., the mobile device 123) is authorized to access and enable the operational capabilities of the vehicle 105, and is not merely requesting vehicle access fraudulently or fraudulently. Therefore, aspects of the present disclosure can mitigate and / or eliminate the lag time associated with full authentication of the mobile device 123 by providing intermediate access concurrently with the initialization of the security processor 155, without introducing unreasonable risks associated with invalid vehicle access and operation.

[0042] Figure 2 An exemplary embodiment of the present disclosure is shown, in which the vehicle computer 148 is configured with the PaaK system 107 (eg, Figure 1 ). Figure 2In an embodiment of the present invention, the vehicle computer 148 may use the pre-processor 153 and the security processor 155 to provide vehicle access to the mobile device 123. The preliminary steps 205 to 215 may be performed when the mobile device 123 is within range for low energy communication (e.g., as described above with respect to Figure 1 For example, preliminary steps 205 to 215 may occur while the vehicle 105 is in a higher energy consumption state, such as a vehicle 105 setup cycle, or during another operation that places the mobile device 123 within wireless communications of the vehicle 105 while the security processor 155 is in a higher power consumption mode.

[0043] At step 205, the pre-processor 153 may transmit a wireless signal to a vehicle transceiver (e.g., a Bluetooth Low Energy (BLE) module associated with the vehicle 105), wherein the transceiver establishes a connection with the mobile device 123. At step 210, the security processor 155 may also generate a random challenge value. Generating the random challenge value may include, for example, generating a question with a predetermined answer. The question and answer pair described as a random challenge value may be a literal question and answer that may be associated with the mobile device 123, the user 143, the vehicle 105, and other information that may be used to determine whether the person answering the random challenge is the intended authorized user.

[0044] In another example embodiment, the random challenge value may be a challenge question used in two-factor authentication and password retrieval operations (eg, mother's maiden name, make and model of first car owned, etc.).

[0045] In other aspects, the random challenge value may include the public key data 167 (eg, Figure 1 The security processor 155 may generate a random challenge message using the user-level data 171, the vehicle-level data 175, the public key data 167, or other information, wherein the question is a request for the private key and the answer is a message with the private key. At step 210, the security processor 155 may use the user-level data 171, the vehicle-level data 175, the public key data 167, or other information to generate a random challenge message, which may include one or more of the challenge values ​​described above.

[0046] At step 215, the security processor 155, while in a higher power state (ie, not in sleep or low power state), may transmit a random challenge value as an authentication message 181 to the mobile device 123 ( Figure 1 The mobile device 123 may store the authentication message 181 in the computer memory of the mobile device ( Figure 2143). For example, after receiving the wake-up message at 215, the user may leave the vehicle parked for a duration sufficient to cause the vehicle 105 to enter a low energy state. For clarity, after receiving the wake-up message at step 215, the mobile device 123 may store the wake-up message, which will be referred to as the authentication message 181 below. In response to determining that the mobile device 123 and / or the user 143 are not in the PEPS zone for at least a predetermined time threshold, the security processor 155 may enter a low power consumption mode at step 220. For example, the user 143 may have parked the vehicle 105 and left the vicinity of the vehicle 105 such that they are not in the PEPS zone for the predetermined time threshold.

[0047] The user 143 may later (after the vehicle 105 has entered the low energy mode) return to the communication zone of the vehicle 105 simultaneously with the mobile device 123. The user approaches 217 at Figure 2 Depicted as rectangular bars in FIG. 21 , the proximity of the user 143 to the vehicle 105 after a certain duration has elapsed since the authentication message 181 was received at step 215 .

[0048] When the mobile device 123 is within the communication zone of the vehicle 105 (e.g., within the PEPS zone), the pre-processor 153 can evaluate the approximate physical distance between the mobile device 123 and the vehicle 105. The pre-processor can determine the proximity of the mobile device 123 using a variety of known methods, including, for example, measuring the strength of the BLE signal, evaluating GPS data returned from the mobile device 123, and / or via other methods.

[0049] In response to determining at step 225 that the mobile device 123 is near the vehicle 105, the preprocessor 153 may transmit a start response prompt message using a low energy transmitter (e.g., a BLE module or another near field communication transmitter) at step 230. Step 230 is configured to cause the mobile device 123 to transmit an authentication message in an iterative manner (e.g., at predetermined time intervals and / or at predetermined times). For example, in a response cache loop 535, in response to receiving the start response prompt message at step 230, the mobile device 123 may start a response cache loop 535 by transmitting an authentication message at step 240. After receiving the authentication message, the preprocessor 153 may cache the response in a cache memory (e.g., a cache memory associated with the preprocessor 153) at step 245. Figure 2The preprocessor 153 may iteratively cache the responsive authentication message to ensure that a usable authentication message is received from the mobile device 123. In other aspects, a power consumption mode instruction that causes the security processor 155 to enter a higher power consumption mode may be sent by the preprocessor after a predetermined number of iterations of the response caching loop 535 have been received and / or cached. In this case, the predetermined number may be, for example, three times, two times, etc.

[0050] At step 255, in the example where the vehicle is in a higher power consumption state, after determining that the mobile device 123 is in the vicinity of the vehicle 105 (at step 225), and simultaneously with, substantially simultaneously with, or after completing the response cache cycle 535, the pre-processor 153 may transmit a power consumption mode instruction ( Figure 2 ) to cause the security processor 155 to wake up and initialize.

[0051] In the example of a vehicle in a low power consumption mode, only a door handle pull 250 or other direct vehicle action request can cause the security processor to wake up. For example, the power consumption mode instructions may include one or more coded instructions configured to cause the vehicle TCU 163 to change the TCU state from a low power consumption state to a higher power consumption state in response to the door handle pull 250, and may also initialize the security processor 155.

[0052] Although outside the scope of the present disclosure, those skilled in the art will appreciate that initialization of the processor may include several power cycles, memory clears, and other steps that are omitted herein for simplicity. Thus, during step 260, in response to issuance of a power mode instruction, the security processor 155 may wake up and initialize at step 255 by entering a higher power consumption mode.

[0053] At step 250, the preprocessor 153 may sense a door handle pull. For example, in conjunction with the door latch mechanism 197 ( Figure 1 ) and / or associated with the door handle 160 (also depicted in Figure 1 143) may generate output signals in response to touch or actuation by user 143. Additional output signals may be related to detection of physical touch on the vehicle surface through capacitive sensing or presence detection through camera or other electromagnetic sensing.

[0054] At step 260 , the preprocessor 153 may determine whether the mobile device 123 is within the PEPS zone in response to receiving the output signal associated with the door handle / door latch signal. Furthermore, step 255 may provide an indication in conjunction with the door handle actuation that the user performing the door opening operation is the authorized user 143 associated with the mobile device 123 .

[0055] At step 265 , the pre-processor 153 may forward the cached information associated with the first authorization (which was saved to the cache memory of the vehicle computer 148 at step 245 ) to the security processor 155 .

[0056] At step 270, secure processor 155 may verify the cached first authorization response by comparing the first authorization response to information stored in a secure data store (eg, a portion of memory 157).

[0057] At step 275 , in response to determining that the mobile device 123 has been authenticated, the device is validated and approved by the secure processor 155 for unlocking.

[0058] At step 280, the vehicle sensor output associated with the actuation of the door latch mechanism 197 may, after being received by the preprocessor 153, in conjunction with determining that the mobile device 123 is in the vicinity of the vehicle 105 (at step 225), and further in conjunction with the verification step 270, cause the preprocessor 153 to generate an instruction to cause the door latch mechanism 197 to unlock. Thus, the preprocessor 153 may transmit one or more vehicle operation instructions to the vehicle TCU 163 that allow the vehicle 105 to start. It should be appreciated that with respect to the timing of the steps, the wake-up and initialization steps 255 may be substantially similar to and / or performed simultaneously with respect to the issuance of the unlock instruction.

[0059] In addition to the initial authentication at step 270, which may be based on a combination of various authentication factors (e.g., proximity of the mobile device 123 and receipt of the authentication message from step 215), it may be beneficial to increase the reliability of the authentication of the user 143 and the mobile device 123 even after providing vehicle access at step 280. Therefore, the security processor 155 may perform a second authentication, which may include transmitting a verification message via the security processor 155 at step 285. The verification message generated at step 285 and transmitted at step 290 may be configured to elicit a response 295 from the mobile device 123. The response transmission may include a verification message response having an answer associated with the random challenge value generated at step 210. The answer to the random challenge may be uniquely paired with the corresponding challenge value, wherein a plurality of challenge values ​​may be generated by the security processor 155 and stored in the memory 157, from which a challenge value of the same type as that sent at step 215 may be randomly selected and sent again by the security processor 155 at step 290. In some aspects, the challenge value in the verification message sent at step 290 may be associated with a private key stored on the mobile device 123. In other embodiments, the challenge value may be a question with a unique answer that ideally should only be known by the user 143.

[0060] Thus, at step 297, the security processor 155 may receive the verification message from step 295 and determine whether the verification message response confirms the validity of the mobile device 123 and the user 143. In response to determining that the verification message is correct, the security processor 155 may allow vehicle operation, and Figure 2 The process ends.

[0061] Figure 3 Another exemplary embodiment of the present disclosure is depicted in which the vehicle computer 148 is Figure 2 After providing access to the vehicle 105 after the unlocking step 280, the security processor 155 is used to determine the authenticity of the mobile device 123 and the user 143. The security processor 155 can generate one or more remedial action instructions in response to determining at step 297 that the mobile device 123 and / or the user 143 are not authenticated. For example, the security processor 155 can determine that the mobile device 123 is not authorized to access the vehicle 105 by the mobile device 123 returning an invalid authentication response message or by not returning a response at all. The security processor 155 can then generate one or more instructions that cause remedial actions, such as recording an event with a diagnostic trouble code (DTC), offloading the DTC for further analysis on a server, triggering an alarm (e.g., anti-theft alarm, horn, etc.), flashing headlights, disabling one or more operating functions, transmitting a message to one or more remote servers (e.g., remote server 161), transmitting a message to the owner of the vehicle, prohibiting the vehicle from being shifted out of park, limiting the speed of the vehicle, generating an automatic message to an agency such as, for example, a local police department, and / or performing other actions not listed herein.

[0062] Figure 4 Describes a method for providing access to a PaaK system such as Figure 1 An exemplary method 400 for two-step authentication of a mobile device that is part of a PaaK system 107 is shown.

[0063] At step 405, a preprocessor (e.g., Figure 1 The pre-processor 153 shown may receive an authentication message associated with a mobile device.

[0064] At step 410, the security processor 155 may verify the authentication message received from the mobile device 123 at a pre-processor of the vehicle computer (e.g., pre-processor 153). Figure 1 The vehicle computer 148 depicted in FIG. 1 is substantially similar or identical to that depicted in FIG.

[0065] As shown in step 415 , the method includes storing the authentication message response in a cache memory of the vehicle computer. The cache memory may be provided as part of the security processor 155 , the preprocessor 153 , and / or may be included in the memory 157 .

[0066] At step 420, the method may include receiving a vehicle sensor output associated with an actuation of a vehicle door latch 160. For example, a vehicle sensor configured with a door latch and / or a door handle 160 may sense a user touch when a user attempts to open a door. The touch may cause the sensor to generate a sensor output, which may be received by a preprocessor 153 as described in the above embodiments.

[0067] At step 425 , the pre-processor 153 may generate security processor 155 initialization instructions that initialize the security processor of the vehicle computer.

[0068] At step 430 , the pre-processor 153 may provide access to the vehicle based on the security processor 155 initialization instructions and the authentication message stored in the cache memory of the vehicle computer.

[0069] In the above disclosure, reference has been made to the accompanying drawings that form part of the above disclosure, which illustrate specific implementations in which the present disclosure may be practiced. It should be understood that other implementations may be utilized and structural changes may be made without departing from the scope of the present disclosure. References to "one embodiment," "embodiment," "exemplary embodiment," etc. in this specification indicate that the described embodiment may include specific features, structures, or characteristics, but each embodiment may not necessarily include the specific features, structures, or characteristics. In addition, such phrases do not necessarily refer to the same embodiment. In addition, when features, structures, or characteristics are described in conjunction with an embodiment, whether or not explicitly described, those skilled in the art will recognize such features, structures, or characteristics in conjunction with other embodiments.

[0070] It should also be understood that the word "example" as used herein is intended to be non-exclusive and non-limiting in nature. More specifically, the word "exemplary" as used herein indicates one of several examples, and it should be understood that there is no undue emphasis or preference on the specific example described.

[0071] Computer-readable media (also referred to as processor-readable media) include any non-transitory (e.g., tangible) media that participate in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor of a computer). Such media can take many forms, including but not limited to non-volatile media and volatile media. A computing device may include computer-executable instructions, where the instructions are executable by one or more computing devices (such as those listed above and stored on computer-readable media).

[0072] With respect to the processes, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes may be practiced with the described steps performed in an order different from that described herein. It should also be understood that certain steps may be performed simultaneously, other steps may be added, or certain steps described herein may be omitted. In other words, the descriptions of the processes herein are provided for the purpose of illustrating various embodiments and should in no way be construed as limiting the claims.

[0073] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Upon reading the above description, many embodiments and applications other than the examples provided will be apparent. The scope should not be determined with reference to the above description, but should be determined with reference to the entire scope of the equivalents of the attached claims and the rights to such claims. It is expected and anticipated that the technology discussed herein will develop in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In short, it should be understood that the present application is capable of modification and variation.

[0074] All terms used in the claims are intended to be given their ordinary meanings as understood by those skilled in the art as described herein, unless clear contrary indications are made herein. In particular, unless the claims state a clear limitation to the contrary, the use of singular articles such as "one", "the", "said" and the like should be interpreted as one or more of the elements indicated in the narration. Unless otherwise specifically stated or understood in other ways within the context when used, conditional language such as, in particular, "can", "may", "can" or "may" is generally intended to express that certain embodiments may include certain features, elements and / or steps, while other embodiments may not include certain features, elements and / or steps. Therefore, such conditional language is generally not intended to imply that one or more embodiments require the features, elements and / or steps in any way.

[0075] According to one embodiment, the security processor is configured to: determine the sum of verification message responses that do not match a predetermined authorization response associated with a private key or a public key and the sum of verification message responses that have not been received within a predetermined time interval from receiving a vehicle sensor output; determine that the sum of invalid verification message responses exceeds a first threshold; determine that the sum of invalid verification message responses exceeds a second threshold for a given geographic location of the vehicle or mobile device; determine that the sum of invalid verification message responses exceeds a third threshold for a given date or time of day; and select a remedial action from a plurality of remedial actions associated with vehicle operation or a vehicle alarm based on the first threshold, the second threshold, and the third threshold.

[0076] According to one embodiment, the security processor is configured to: determine a remedial action instruction based on a response to a verification message; in response to determining that the verification message response is invalid or a timeout error occurs, transmit the remedial action instruction to a vehicle telematics control unit (TCU); wherein the remedial action instruction is configured to cause the TCU to issue an alarm or disable a vehicle function.

[0077] According to one embodiment, the preprocessor is configured to: authenticate the pre-authentication message associated with the mobile device; and send a power consumption mode instruction to the security processor, wherein the power consumption mode instruction is configured to cause a vehicle telematics control unit (TCU) to change the TCU state from a low energy consumption state to a higher energy consumption state.

[0078] According to the present invention, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium having instructions, the instructions when executed by one or more processors causing the processors to perform actions for authenticating a mobile device as a vehicle key, the actions comprising: determining or receiving a geographic location of the vehicle and the mobile device; determining or receiving a current date and time for sending a message to the mobile device, the message being configured to trigger the sending of a pre-authentication message when it is detected that the mobile device has reached a predetermined distance from the vehicle; receiving an authentication message from the mobile device; verifying the authentication message via a pre-processor of a vehicle computer; storing the authentication message in a cache memory of the vehicle computer; receiving a vehicle sensor output associated with actuation of a door latch, detection of a physical touch on a vehicle surface by capacitive sensing, or presence detection by a camera or other electromagnetic sensing; generating, via the preprocessor, a security processor initialization instruction in response to the vehicle sensor output associated with the actuation of the door latch, detection of a physical touch on a vehicle surface by capacitive sensing, or presence detection by a camera or other electromagnetic sensing, wherein the security processor initialization instruction initializes a security processor of the vehicle computer; and providing access to the vehicle via the preprocessor based on the security processor initialization instruction and the authentication message stored in the cache memory of the vehicle computer.

[0079] According to one embodiment, the present invention is also characterized by: transmitting a verification message to the mobile device via a wireless transceiver configured to communicate with the security processor, the verification message having a private key associated with the mobile device; receiving a verification message response via the wireless transceiver based on the verification message having the private key associated with the mobile device; determining a remedial action based on the verification message response; determining a series of upgraded remedial actions based on multiple verification message responses; determining a remedial action based on the verification message response and the geographic location of the vehicle or mobile device; determining a remedial action based on multiple verification message responses in a given geographic location of the vehicle or mobile device; determining a remedial action based on a verification message response and a date and time; determining a remedial action based on multiple verification message responses at a given date or time of day; generating instructions for performing the remedial action; and performing the remedial action based on the instructions.

Claims

1. A computer-implemented method for authenticating a mobile device as a vehicle key, the method comprising: sending a message to a mobile device, the message being configured to trigger the sending of a pre-authentication message upon detecting that the mobile device has reached a predetermined distance from the vehicle; receiving a pre-authentication message sent at predetermined intervals from the mobile device; authenticating the pre-authentication message via a pre-processor of a vehicle computer; storing the pre-authentication message in a cache memory of the vehicle computer; receiving a vehicle sensor output associated with detection of a physical touch on a surface of the vehicle; generating, via the pre-processor, security processor initialization instructions in response to the vehicle sensor output associated with the detection of the physical touch on the vehicle surface, wherein the security processor initialization instructions initialize a security processor of the vehicle computer; as well as providing access to the vehicle via the pre-processor based on the security processor initialization instructions and the authentication message stored in the cache memory of the vehicle computer; authenticating the mobile device with a second authentication, the authentication comprising: transmitting, via the security processor configured to communicate with a wireless transceiver, a verification message associated with a private key associated with the mobile device; determining a remedial action based on the validation message response; and A series of escalated remedial actions are determined based on the plurality of validation message responses, including: determining a remedial action based on the verification message response and the geographic location of the vehicle or mobile device; determining a remedial action based on a plurality of validation message responses in a given geographic location of the vehicle or mobile device; determining a remedial action based on the validation message response and the date and time; and determining a remedial action based on a plurality of validation message responses during a given date or time of day; generating instructions for performing the remedial action; and The remedial action is performed based on the instruction.

2. The computer-implemented method of claim 1 , wherein receiving the vehicle sensor output comprises: receiving a user touch to a surface of the vehicle detected by a capacitive sensor or an electromagnetic sensor; receiving a signal indicative of an actuation of a door latch; or A video feed is received by a camera associated with the vehicle.

3. The computer-implemented method of claim 1 , wherein determining the remedial action comprises: receiving, via the security processor, the verification message, and comparing, via the security processor, the verification message to a public key associated with the private key; and The remedial action is selected from a plurality of remedial actions associated with vehicle operation or a vehicle alarm or other vehicle feature, the selection being responsive to the geographic location, date and time of day of the vehicle or mobile device, and a determination that the verification message response does not match a predetermined authorization response associated with the private key and the public key.

4. The computer-implemented method of claim 1 , wherein determining the remedial action comprises: determining that the verification message response has not been received within a predetermined time interval from receiving the vehicle sensor output; and Selecting the remedial action from a plurality of remedial actions associated with vehicle operation or a vehicle alarm or other vehicle feature, the selection being responsive to the geographic location of the vehicle or mobile device, the date and time of day, and determining that the verification message response has not been received within the predetermined time interval from receiving the vehicle sensor output.

5. The computer-implemented method of claim 1 , wherein determining the remedial action comprises: determining that the verification message response is received within a predetermined time interval from receiving the vehicle sensor output; determining that the verification message response is valid; and Vehicle operation is permitted based on determining that the verification message response is valid.

6. The computer-implemented method of claim 1 , wherein determining the remedial action comprises: determining that a sum of invalid authentication message responses exceeds a first threshold; determining that the sum of invalid authentication message responses exceeds a second threshold for a given geographic location of the vehicle or mobile device; determining that the sum of invalid authentication message responses exceeds a third threshold for a given date or time of day; as well as A remedial action from among a plurality of remedial actions associated with vehicle operation or a vehicle alarm is selected based on the first threshold, the second threshold, and the third threshold.

7. The computer-implemented method of claim 1, further comprising: determining a remedial action based on a response to the verification message; as well as In response to determining that the verification message response is invalid or a timeout error occurs, transmitting the remedial action instruction to a vehicle telematics control unit (TCU); The remedial action instruction is configured to cause the telematics control unit to sound an alarm or disable a vehicle function.

8. The computer-implemented method of claim 1 further comprising, after authenticating the pre-authentication message associated with the mobile device via the pre-processor of the vehicle computer, sending a power consumption mode instruction to the security processor, the power consumption mode instruction being configured to cause a vehicle telematics control unit (TCU) to change a telematics control unit state from a low power consumption state to a higher power consumption state.

9. A phone-as-a-key (PaaK) system for a vehicle, comprising: Preprocessor; a security processor configured to communicate with the preprocessor; a cache memory associated with the preprocessor and the security processor; as well as a memory for storing executable instructions, wherein the pre-processor and the security processor are configured to execute the instructions to: determining geographic locations of the vehicle and mobile device; Determine the current date and time; sending a message to a mobile device, the message being configured to trigger the sending of a pre-authentication message upon detecting that the mobile device has reached a predetermined distance from the vehicle; receiving an authentication message at predetermined intervals from a mobile device used as a key for the vehicle; authenticating the authentication message via the preprocessor; storing the authentication message in the cache memory; receiving a vehicle sensor output associated with a user's proximity to the vehicle; generating, via the preprocessor, security processor initialization instructions in response to the vehicle sensor output associated with user proximity, wherein the security processor initialization instructions initialize the security processor of a vehicle computer; as well as providing access to the vehicle via the pre-processor based on the security processor initialization instructions of the authentication message stored in the cache memory; transmitting, via a wireless transceiver associated with the security processor, a verification message to the mobile device, the verification message having a private key associated with the mobile device; receiving, via the wireless transceiver, a verification message response based on the verification message having the private key associated with the mobile device; determining a remedial action based on the verification message response, the geographic location of the vehicle or mobile device, and the date and time of day; as well as Instructions for performing the remedial action are generated based on the validation message response.

10. The system of claim 9, wherein receiving the vehicle sensor output associated with a user's proximity to the vehicle comprises: receiving a user touch to a surface of the vehicle detected by a capacitive sensor or an electromagnetic sensor; receiving an actuation of a door latch; or A video feed is received by a camera associated with the vehicle.

11. The system of claim 9, wherein the security processor is further configured to: receiving, via the security processor, the verification message and comparing the verification message to a public key associated with a private key; determining the geographic location of the vehicle or mobile device; determining, based on the private key and the public key and based on the geographic location of the vehicle or the mobile device, that a verification response does not match a predetermined authorization response; and Select remedial actions that restrict vehicle operation or trigger the alarm.

12. The system of claim 9, wherein the security processor is further configured to: determining, via the security processor, that a verification message response has not been received within a predetermined time interval from receiving the vehicle sensor output; and The remedial action is selected from a plurality of remedial actions associated with vehicle operation or a vehicle alarm, the selection being responsive to a geographic location, date and time of day of the vehicle or mobile device, and determining that the verification message response has not been received within the predetermined time interval from receipt of the vehicle sensor output.

13. The system of claim 9, wherein the security processor is further configured to: determining that a verification message response is received within a predetermined time interval from receiving the vehicle sensor output; determining that the verification message response is valid; and Vehicle operation is permitted based on determining that the verification message response is valid.

Images