Vehicle control device, vehicle control method

Abstract

A vehicle control device and a vehicle control method are provided. If an intelligent ECU is communicably connected with a mobile device, the intelligent ECU authenticates the communication partner using a one-time authentication key previously distributed to the mobile device. In a case where the one-time authentication key is used up, the mobile device returns a signal indicating that the one-time authentication key is used up, to a signal from the intelligent ECU. In a case where the communication partner exists in a trunk and the reason for authentication failure is that the one-time authentication key is used up, the intelligent ECU determines that a regular mobile device having a device ID of the communication partner exists in the trunk, and implements a lock warning process.

Description

[0001] Cross-references to related applications

[0002] This application is based on Japanese Patent Application No. 2022-048819, filed on March 24, 2022, and is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to a vehicle control device and a vehicle control method for locking / unlocking a vehicle based on authentication of the legitimacy of the communication counterpart. Background Technology

[0004] A system is known to wirelessly communicate with a key device via an in-vehicle system to perform key device location estimation and authentication processing, and automatically lock / unlock the vehicle. This system is called an intelligent entry system or a passive entry / passive start (PEPS) system, etc.

[0005] Patent Document 1 discloses a structure that identifies and disables a key device left inside the vehicle when locking it using an automatic locking function. If the key device left inside the vehicle is not disabled beforehand, it responds to a search signal from the vehicle based on an unlocking operation, allowing anyone to unlock the vehicle. The aforementioned control related to disabling the key device addresses this problem.

[0006] In addition, to prevent the key device from being locked inside the vehicle (so-called In lock), the PEPS key system also includes controls such as outputting a warning sound when the key device is detected to be left inside the vehicle during the locking operation.

[0007] Patent Document 1: Japanese Patent No. 5846024

[0008] Controls that prevent the output of warning sounds when the car is locked and disable key devices left inside the vehicle operate according to the designer's intent (in other words, normally) on the condition that the key device can be confirmed to be inside the vehicle via wireless communication.

[0009] However, because location determination and verification based on wireless communication are affected by the radio wave environment, there may be situations where the system fails to recognize the key device even if it remains inside the vehicle. Of course, if the vehicle system cannot recognize the key device left inside the vehicle for some reason while locking, its lock prevention and other control functions will not work.

[0010] Furthermore, in recent years, due to countermeasures against relay attacks and the introduction of digital key systems, the authentication process of key devices and vehicle systems has become increasingly sophisticated and complex. Consequently, authentication failures of mobile devices may occur for various reasons. In other words, there are concerns that in the future, there will be a greater likelihood that warning sounds preventing locking or the invalidation of key devices left inside the vehicle will not function. Summary of the Invention

[0011] This disclosure is based on the above research or perspective, and one of its objectives is to provide a vehicle control device and vehicle control method that can reduce concerns that although a mobile device that can function as a vehicle key is actually present in the vehicle, it may be determined that the mobile device is not present in the vehicle due to authentication failure.

[0012] The vehicle control device disclosed herein is a vehicle control device that determines the location of a key device by wirelessly communicating with the key device, wherein the key device is a mobile device pre-registered as a vehicle key. The vehicle control device includes: a device location confirmation unit that performs wireless authentication processing and location determination processing, wherein in the wireless authentication processing, it determines whether the communication partner is a key device based on data sent from the communication partner, and in the location determination processing, it determines whether the communication partner exists in the vehicle based on the reception status of the signal from the communication partner; and a failure reason determination unit that, when the device location confirmation unit fails to determine that the communication partner is a key device through the wireless authentication processing, determines an authentication failure reason based on data received from the communication partner, wherein the authentication failure reason is the reason why the communication partner is not determined to be a key device. The device location confirmation unit is configured such that, even when it cannot determine that the communication partner is a key device, if the authentication failure reason is a specific reason and the location of the communication partner is determined to be in the vehicle, the key device is considered to exist in the vehicle.

[0013] Furthermore, the vehicle control method disclosed herein is a vehicle control method implemented by at least one processor that determines the location of a key device by wirelessly communicating with the key device, wherein the key device is a mobile device pre-registered as a key to the vehicle. The vehicle control method includes the following steps: determining whether the communication partner exists in the vehicle based on the reception status of wireless signals sent from the communication partner; determining whether the communication partner is a key device based on data sent from the communication partner; if the communication partner is not determined to be a key device, determining an authentication failure reason based on the content of the received data, the authentication failure reason being a reason for not identifying the communication partner as a key device; and even if the communication partner is not determined to be a key device, if the authentication failure reason is a specific reason and it is determined that the communication partner exists in the vehicle, the key device is also considered to exist in the vehicle.

[0014] According to the aforementioned apparatus / method, even if authentication of a mobile device fails, the mobile device is considered to be present in the vehicle if the reason is specific. Therefore, concerns can be reduced regarding the possibility that a mobile device may be deemed not to be present in the vehicle due to authentication failure, even if it is actually present in the vehicle.

[0015] Furthermore, the reference numerals in parentheses in the claims indicate the correspondence between the specific means described in the embodiments described later as an example, and do not limit the technical scope of this disclosure. Attached Figure Description

[0016] Figure 1 This is a diagram showing the overall image of a vehicle's digital key system.

[0017] Figure 2 It is a block diagram representing the structure of a mobile device.

[0018] Figure 3 This is a functional block diagram of the equipment control department.

[0019] Figure 4 It is a block diagram representing the structure of the vehicle-mounted system.

[0020] Figure 5 This is a diagram showing an example of the mounting location of a BLE communicator.

[0021] Figure 6 This is a diagram showing the structure of a BLE communicator.

[0022] Figure 7 This is a functional block diagram of the intelligent ECU.

[0023] Figure 8 This is a timing diagram representing the wireless authentication process.

[0024] Figure 9 It is a flowchart used to explain how mobile devices work.

[0025] Figure 10 This is a flowchart for handling locked warnings.

[0026] Figure 11 This is a flowchart of the trunk unlocking process.

[0027] Figure 12 This is a flowchart for the process of invalidating remaining devices.

[0028] Figure 13 This is a diagram showing other configuration examples of BLE communicators.

[0029] Figure 14 This is a diagram illustrating an example of a vehicle's independent space. Detailed Implementation

[0030] Hereinafter, embodiments of the present disclosure will be described using the accompanying drawings. Figure 1 This is a diagram illustrating a schematic example of the structure of a vehicle digital key system (Sys). For example... Figure 1 As shown, the vehicle digital key system Sys includes an in-vehicle system 1, a mobile device 2, and a digital key server (DKS) 3. The in-vehicle system 1 is the system installed in the vehicle (Hv). The mobile device 2 is a device carried by the user of the vehicle (Hv). Multiple mobile devices 2 can exist.

[0031] <Introduction>

[0032] The vehicle Hv mentioned below, as an example, refers to a privately owned four-wheeled vehicle. The user of a vehicle Hv can be the owner, their family members, etc. A vehicle Hv can be a company vehicle owned by a corporation or a public vehicle owned by a public institution. In the case of a company or public vehicle, the person belonging to the organization managing the vehicle Hv can become the user. A vehicle Hv can be a vehicle providing rental services (so-called car rental) or a vehicle providing car-sharing services (so-called car sharing). In the case of a vehicle Hv providing the above services (hereinafter, service vehicle), a person who has signed a service agreement and has temporary access to the vehicle Hv based on service reservations, etc., can become the user.

[0033] Vehicle Hv can be an electric vehicle such as a hybrid electric vehicle (so-called a plug-in hybrid electric vehicle) that can be externally charged. Electric vehicles, besides electric cars, also include hybrid electric vehicles and fuel cell vehicles. Furthermore, hybrid electric vehicles are vehicles that have both an engine and a motor as power sources. Alternatively, vehicle Hv can also be a motor-powered vehicle.

[0034] A vehicle with a trunk (Hv) is a type of vehicle, such as a sedan, where the driver's cab and trunk are not connected. An Hv is configured to keep all doors locked even when the trunk door is open. The trunk door can also be called the rear hatch, rear hatch cover, or rear hatch door.

[0035] The vehicle Hv has the driver's seat located on the right side. Alternatively, the vehicle Hv may also be a vehicle with the driver's seat located on the left side. Unless otherwise noted (in other words, generally speaking), the front-back, left-right, and up-down directions in the following description are defined based on the vehicle Hv.

[0036] The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowcharts and the order of execution of processes can be appropriately changed. Furthermore, the following descriptions can be appropriately modified to comply with the regulations and customs of the regions where vehicle Hv is used.

[0037] <Overall Summary>

[0038] Both the vehicle system 1 and the mobile device 2 are configured for short-range communication. Here, short-range communication refers to communication using a defined short-range wireless communication standard with a practical communication range of 1m to 30m, and a maximum of approximately 100m. The short-range communication standard can be Bluetooth (registered trademark), Wi-Fi (registered trademark), etc. The Bluetooth standard can be Bluetooth Classic or BLE (Bluetooth Low Energy). The Wi-Fi standard can be IEEE 802.11n, IEEE 802.11ac, and IEEE 802.11ax (the so-called Wi-Fi 6), among others. Furthermore, IEEE (registered trademark) is an abbreviation for the Institute of Electrical and Electronics Engineers, which can also refer to the Institute of Electrical and Electronics Engineers. Additionally, the communication method between the vehicle system 1 and the mobile device 2, in other words, the short-range communication method, can be UWB-IR (Ultra Wide Band-Impulse Radio). Furthermore, the vehicle system 1 and the mobile device 2 can also be configured to use radio waves in the LF (Low Frequency) band, such as 125kHz and 134kHz, for wireless communication.

[0039] The following explanation describes the operation of each component, using a vehicle system 1 and a mobile device 2 configured to implement wireless communication (hereinafter, BLE communication) according to the BLE standard as an example. Details of the communication sequence, such as communication connection and the initiation of encrypted communication, are implemented according to the BLE standard. The term BLE communication can be replaced with UWB communication or short-range communication. Furthermore, the vehicle system 1 includes an intelligent ECU 4 as a device for actual data communication with the mobile device 2. ECU is an abbreviation for Electronic Control Unit, referring to an electronic control device.

[0040] The following explanation describes the scenario where the intelligent ECU 4 is configured to operate as the host in communication with the mobile device 2, and the mobile device 2 operates as a slave device. The intelligent ECU 4 establishes a communication connection with the mobile device 2 by receiving an advertising signal from the mobile device 2, and detects the presence of the mobile device 2 (and thus the user) in the vicinity of the vehicle Hv. The advertising signal is a signal used to notify other devices of its presence (i.e., an advertisement). Alternatively, the mobile device 2 can also be configured to operate as the host in communication with the intelligent ECU 4.

[0041] Furthermore, BLE signals, as wireless signals based on the BLE standard, can be transmitted from various devices. In this disclosure, devices transmitting BLE signals are collectively referred to as BLE devices. BLE devices are categorized into registered devices paired with the vehicle Hv / intelligent ECU4 and unregistered devices that have not been paired. Pairing can be achieved by registering the device ID of the communicating party at least in internal memory or the like. The device ID is an identification number for the BLE device. The device ID can be a device address, a UUID (Universally Unique Identifier), etc. Mobile device 2 is a registered device. BLE signals, such as advertising signals, contain a device ID indicating the sending source. The intelligent ECU4 can identify whether the communicating party is mobile device 2 or an unregistered device based on the device ID contained in the received signal.

[0042] Furthermore, the intelligent ECU4 and the mobile device 2 are configured to communicate with the DKS3 using either a cellular line or a Wi-Fi (registered trademark) line. In this disclosure, communication using a cellular line is referred to as cellular communication. Cellular communication refers to wireless communication based on standards such as 4G and 5G. In this disclosure, data communication using a Wi-Fi line is referred to as Wi-Fi communication. Wi-Fi standards can include various standards such as IEEE 802.11n, IEEE 802.11ac, and IEEE 802.11ax (so-called Wi-Fi 6).

[0043] DKS3 is a server configured externally to the vehicle Hv. DKS3 can communicate with each of the intelligent ECU4 and mobile device 2 via wide area communication networks such as the Internet. Based on requests from mobile device 2, DKS3 issues service keys and one-time authentication keys to mobile device 2 for using the vehicle Hv.

[0044] The service key is the fundamental code that enables the mobile device 2 to function as the key to the vehicle Hv. The service key is different for each combination of vehicle Hv and mobile device 2. DKS3 can issue the service key as the output value of a prescribed hash function that takes the value combining the vehicle ID and device ID as input. The vehicle ID is a unique identification number assigned to each vehicle. The vehicle ID can be a Vehicle Identification Number (VIN). Furthermore, the service key can be either a password of a specified number of characters registered by the user or the value obtained by hashing that password using a prescribed hash function.

[0045] A one-time authentication key is a so-called one-time authentication key that is discarded after a single use. The one-time authentication key is used to verify the legitimacy of the intelligent ECU4 as the communication partner; that is, to confirm that it is indeed the mobile device 2. The one-time authentication key is generated by combining a variable code (variation factor) with the service key. Each time a one-time authentication key is issued, the variable code is a different value. The variable code can be an epoch second, the number of times the one-time authentication key has been issued, or a random number. A one-time authentication key can be generated by inputting the service key and the variable code into a specified generation function. The generation function is a function that generates a one-time authentication key based on these two input values. The generation function can be a specified hash function. The input value to the generation function can be a value obtained by simply concatenating the service key and the variable code (i.e., a linked value), or a value obtained by multiplying or adding the service key and the variable code. Such a one-time authentication key can also be called a token.

[0046] <About Mobile Devices 2>

[0047] Mobile device 2 is a portable and universal information processing terminal with BLE communication capabilities. Mobile device 2 can be various communication terminals such as smartphones and wearable devices. Wearable devices are devices worn on the user's body and can take various shapes such as wristbands, watches, rings, glasses, and headphones. Furthermore, the mobile device 2 disclosed herein can be implemented by dividing it into a host device (such as a smartphone) and a wearable device.

[0048] like Figure 2 As shown, the mobile device 2 includes a device control unit 20, a display 21, a touch panel 22, an accelerometer 23, a biometric authentication device 24, a BLE communication unit 25, a cellular communication unit 26, and a Wi-Fi communication unit 27.

[0049] The device control unit 20 is a module that controls the overall operation of the mobile device 2. The device control unit 20 is configured as a computer including a device processor 201, RAM (Random Access Memory) 202, and memory 203. The device processor 201 may be a CPU (Central Processing Unit). RAM 202 is a volatile storage medium. Memory 203 has a structure that includes non-volatile storage media such as flash memory.

[0050] In addition, the device control unit 20 includes a digital key application 204 as application software (hereinafter, application). The digital key application 204 is used for secure user authentication, service key acquisition / storage, and communication with the intelligent ECU 4. The digital key application 204 is installed in the memory 203, etc.

[0051] Display 21 can also be a liquid crystal display (LCD) or an organic EL display. Display 21 displays images corresponding to input signals from the device control unit 20. Touch panel 22 is a capacitive touch panel, stacked on top of display 21. Touch panel 22 is an input device provided by mobile device 2. Touch panel 22 and display 21 serve as interfaces for users to input passwords for logging into digital key application 204 or for pairing mobile device 2 with intelligent ECU 4.

[0052] Accelerometer 23 is a sensor that detects the acceleration acting on mobile device 2. The output of accelerometer 23 (i.e., the detected data) is input to device control unit 20. The output signal of accelerometer 23 functions as a signal indicating whether mobile device 2 is in a carrying state or a placed state. The carrying state can be a state in which the user moves with the user or is operated by the user. The placed state can be a state in which the user does not carry mobile device 2; in other words, the mobile device 2 is placed in a stable place for a specified time. The stable place can be a table, counter, shelf, floor, etc. The seat, console, trunk, etc. of a parked car can also be considered a stable place.

[0053] The biometric authentication device 24 is a device that authenticates a user using biometric information such as fingerprints or facial images. The biometric authentication device 24 can also be a device that authenticates a user using vein patterns of the hand or fingers, iris patterns, voiceprints, etc. The user's authentication result is provided to the device control unit 20.

[0054] BLE communication unit 25 is a communication module for implementing BLE communication. Cellular communication unit 26 is a communication module for implementing cellular communication. Wi-Fi communication unit 27 is a communication module for implementing Wi-Fi communication. Each communication module includes an antenna capable of transmitting and receiving radio waves in the target frequency band, a communication microcomputer serving as a control computer for communication, and modulation / demodulation circuitry. Cellular communication unit 26 and Wi-Fi communication unit 27 are optional components and may be omitted.

[0055] Equipment Control Department 20 Figure 3 The device shown includes a one-time authentication key management unit G1 and a vehicle response unit G2, which are functional units that are discovered by executing digital key application 204 through device processor 201.

[0056] In addition, the device control unit 20 includes a key information storage unit KyM. The key information storage unit KyM is implemented using the storage area provided by the memory 203 or RAM 202. The key information storage unit KyM is a storage area used to store service keys, one-time authentication keys, user IDs, etc., issued by DKS3 for use with this device.

[0057] One-time authentication key management unit G1 obtains one-time authentication keys from DKS3 and stores them in key information storage unit KyM. One-time authentication key management unit G1 sends signals to DKS3 requesting the distribution of one-time authentication keys at any time to maintain a state where the key information storage unit KyM holds a predetermined number or more of one-time authentication keys. If the remaining number of one-time authentication keys stored in the key information storage unit KyM is less than a predetermined replenishment threshold, one-time authentication key management unit G1 sets a replenishment requirement flag to "ON". Based on the replenishment requirement flag being set to "ON" and the system being online, one-time authentication key management unit G1 downloads multiple one-time authentication keys from DKS3. The replenishment threshold can be 150, 300, etc.

[0058] Furthermore, DKS3 distributes one-time authentication keys and change codes in a set. That is, the one-time authentication key management unit G1 obtains each one-time authentication key from DKS3 in a state associated with the change code used to generate that one-time authentication key. The one-time authentication key management unit G1 itself does not have the function of generating one-time authentication keys. According to this structure, the details of the one-time authentication key generation method can be concealed. Therefore, the security performance of the vehicle digital key system Sys can be improved.

[0059] The vehicle response unit G2 executes the data communication structure based on the established link (connection) between the intelligent ECU4 and BLE. The vehicle response unit G2 implements wireless communication for authentication based on the established BLE communication link between the intelligent ECU4 and BLE. Wireless authentication processing between the intelligent ECU4 and the mobile device 2 can also be implemented using a challenge-response method. The vehicle response unit G2 uses a one-time authentication key to generate a response code from the challenge code sent from the intelligent ECU4 and returns it to the intelligent ECU4.

[0060] The device control unit 20 determines whether the mobile device 2 is in a carrying state or a placement state based on the signal from the acceleration sensor 23. The device control unit 20 can determine that it is in a placement state if the stationary state persists for a predetermined placement determination time or longer. A stationary state is a state where no acceleration exceeding a predetermined value is detected from the acceleration sensor 23. The placement determination time can be set to 3 minutes or 5 minutes. If the device is determined to be in a placement state, the vehicle response unit G2 does not return a response code to the vehicle Hv. A shorter placement determination time reduces the possibility of the mobile device 2 unintentionally responding to a call from the intelligent ECU 4, thus improving safety and energy efficiency. Furthermore, the device control unit 20 determines that it is in a carrying state if it detects acceleration exceeding a predetermined value. This carrying state determination can be maintained until it is determined to be moved to a placement state.

[0061] Furthermore, the device control unit 20 performs user authentication processing when the digital key application 204 is started. User authentication (login) can be performed by entering a specified user ID and password into the digital key application 204. User authentication can be implemented using the biometric authentication device 24. Since the digital key application 204 is part of the vehicle digital key system Sys, the user's login status in the digital key application 204 corresponds to the user's login status in the vehicle digital key system Sys. Thus, the device control unit 20 has a user authentication function that uses biometric information or a password to determine the legitimacy of the operator (i.e., the user).

[0062] Furthermore, the login state is terminated if a specified validity period has elapsed since the login time or the last operation time, or if the mobile device 2 is turned off. In other words, the digital key application 204 transitions to the logout state under specified conditions. The logout state requires user re-authentication. In this disclosure, the state in which the mobile device 2 / digital key application 204 authenticates the user using biometric information or a password is referred to as the user authentication state.

[0063] Additionally, as a function of the digital key application 204, the device control unit 20 can also be configured to display a screen confirming the status of the vehicle Hv, i.e., a vehicle status confirmation screen. The vehicle status confirmation screen displays information such as the remaining fuel / battery level, the open / closed status of each window and door, their lock / unlock status, and the interior temperature. Furthermore, the device control unit 20 can also be configured as part of the electrical equipment provided with the vehicle Hv for remote operation. Based on user operations via the touch panel 22, the device control unit 20 can send wireless signals instructing the vehicle Hv to lock / unlock, turn the air conditioning on / off, open / close windows, and turn off hazard lights, etc. For convenience, the instruction signal used to lock the vehicle Hv will be referred to as a lock instruction signal.

[0064] In addition, the mobile device 2 can also be a smart key, which is a dedicated device serving as the electronic key to the vehicle's HV. The smart key is a device transferred to the owner along with the vehicle HV upon purchase. The smart key can be understood as an accessory to the vehicle HV. Smart keys can take various shapes, such as a flat cuboid, a flat oval (so-called FOB type), or a card. Smart keys can also be referred to as portable vehicle devices, key fobs, key cards, access keys, etc.

[0065] <Structure of Vehicle System 1>

[0066] Here, the structure and operation of the vehicle-mounted system 1 are described. For example... Figure 4 As shown, the vehicle system 1 includes an intelligent ECU 4, multiple lock / unlock sensors 5, a start switch 6, and multiple BLE communicators 7. Additionally, the vehicle system 1 includes a power ECU 11, a main unit ECU 12, a main unit actuator 13, a main unit sensor 14, a notification ECU 15, an in-vehicle display 16, an alarm 17, and a wide-area communicator 18.

[0067] The intelligent ECU 4 connects to each of the lock / unlock sensor 5, start switch 6, and BLE communicator 7 via dedicated signal lines. Additionally, the intelligent ECU 4 can communicatively connect to the power ECU 11, main ECU 12, etc., via the vehicle intranet Nw. The vehicle intranet Nw is a communication network built within the vehicle's internal network (HV). The standard of the vehicle intranet Nw can be any standard. Figure 4 The connection method shown is an example; the connection method of specific devices can be changed as appropriate.

[0068] The intelligent ECU 4, in cooperation with the BLE communicator 7, determines the device position relative to the vehicle's Hv (height and width) and implements vehicle control corresponding to the determined device position. In this disclosure, "device position" refers to the position of the mobile device 2. Since the mobile device 2 corresponds to the user, determining the device position is equivalent to determining the user's position. The intelligent ECU 4 is located within the dashboard. The intelligent ECU 4 can be installed on the interior side of the right or left C-pillar. The C-pillar is the third pillar from the front of the vehicle's Hv.

[0069] The intelligent ECU4 is implemented using a computer. Specifically, the intelligent ECU4 includes a processor 41, RAM 42, memory 43, I / O 44, and buses connecting these components. In this embodiment, the intelligent ECU4 includes a BLE communicator 7 within its housing.

[0070] The memory 43 is a structure that includes a non-volatile storage medium such as flash memory. The memory 43 stores a control program executed by the processor 41. The control program includes a device location confirmation program, which determines the location of the mobile device 2. The processor 41 executes various processes to implement the functions of the functional units described later by accessing the RAM 42. The processor 41 executing the control program is equivalent to executing the vehicle control method corresponding to that control program. The I / O 44 is a circuit module used for communication with other devices.

[0071] The memory 43 stores the device ID of each mobile device 2. Additionally, the memory 43 stores communicator setting data indicating the mounting position of each BLE communicator 7 within the vehicle's Hv (height). The mounting position of each BLE communicator 7 can be represented as a point on a defined vehicle coordinate system. This vehicle coordinate system can be a two-dimensional coordinate system where the X-axis is parallel to the width direction of the vehicle's Hv, and the Y-axis is parallel to the front-rear direction. The center of the vehicle coordinate system can be any location, such as the center of the vehicle body or the mounting position of the intelligent ECU 4. Details regarding the intelligent ECU 4 will be described later.

[0072] The lock / unlock sensor 5 is a touch sensor used by a user to lock and unlock the doors of the vehicle (Hv). The lock / unlock sensor 5 is installed on the outer door handle of each door. An outer door handle is a gripping component located on the outer side of the door for opening and closing. The lock / unlock sensor 5 is installed on all door handles, including the trunk door handle. The lock / unlock sensor 5 detects that it has been touched by the user based on changes in electrostatic capacitance or pressure, and outputs an electrical signal indicating this to the intelligent ECU 4. Furthermore, the structure for receiving at least one of the user's unlocking and locking instructions can be a button / switch. A lock / unlock button can also replace the lock / unlock sensor 5, or be installed together with the lock / unlock sensor 5 on each door handle. The lock / unlock sensor 5 disclosed herein can also be referred to as a door button for locking and unlocking.

[0073] Start switch 6 is a push-button switch used by the user to switch the driving power supply on / off. The driving power supply is the power source for the vehicle's (Hv) operation; in a motorized vehicle, it is the ignition power supply. In an electric vehicle (Hv), the driving power supply can be the system's main relay. If start switch 6 is pressed by the user, an electrical signal indicating this is output to the intelligent ECU 4. Start switch 6 can also be referred to as the start switch.

[0074] BLE communicator 7 is a communication module used to implement BLE communication. Multiple BLE communicators 7 are installed in the vehicle's Hv (Hardware Vehicle). For example... Figure 5 As shown, the vehicle system 1 of this embodiment includes BLE communicators 7a, 7b, 7c, 7p, and 7x as BLE communicators 7. BLE communicator 7x is built into the intelligent ECU 4, while the other BLE communicators 7 are disposed outside the intelligent ECU 4. Each BLE communicator 7 disposed outside the intelligent ECU 4 is communicatively connected to the intelligent ECU 4 via a dedicated communication line or the vehicle network Nw.

[0075] Each BLE communicator 7 operates based on control signals from the intelligent ECU 4. Furthermore, each BLE communicator 7 provides the intelligent ECU 4 with received data and data related to the reception status of signals from the mobile device 2. In this disclosure, signals from the mobile device 2 are also recorded as device signals. Each BLE communicator 7 has a unique communicator number. The communicator number functions as information for identifying the multiple BLE communicators 7.

[0076] The power ECU 11 is an ECU that controls the on / off state of the driving power supply installed in the vehicle Hv. Based on a request signal from the intelligent ECU 4, the power ECU 11 switches the driving power supply from off to on. Furthermore, when the vehicle Hv is an engine-driven vehicle, the power ECU 11 starts the engine based on a request signal from the intelligent ECU 4.

[0077] The main ECU 12 controls the main system actuators 13 based on requests from the intelligent ECU 4 and the user. The main ECU 12 is communicatively connected to various main system actuators 13 and various main system sensors 14. The main system actuators 13 include door lock motors that constitute the locking mechanisms of each door. The main system sensors 14 include door control switches, etc., configured for each door. The door control switches are sensors that detect the opening and closing of doors. The main ECU 12 switches the locking mechanisms of each door from an unlocked state to a locked state, or performs the opposite control, by outputting prescribed control signals to the door lock motors of each door installed in the vehicle Hv based on requests from the intelligent ECU 4.

[0078] The ECU 15 is notified to use the in-vehicle display 16 or the alarm 17 to warn of the locking of the mobile device 2. Locking means that the device 2 is locked while inside the vehicle. Locking is also referred to as internal locking, etc. The in-vehicle display 16 can be an LCD display or an OLED display. The in-vehicle display 16 is located in the central area of ​​the dashboard in the width direction of the vehicle or in the front area of ​​the driver's seat. The alarm 17 is a device that outputs a warning sound to the outside of the vehicle.

[0079] Based on a request from the intelligent ECU 4, the notification ECU 15 displays a warning message on the in-vehicle display 16 or activates the alarm 17. The warning message may be something like "A mobile device is left in the trunk." The in-vehicle system 1 may have a speaker, either in place of the alarm 17 or alongside the alarm 17, capable of outputting an audible message to the outside of the vehicle near the trunk door. Alternatively, the in-vehicle system 1 may output the warning message audibly, along with or in place of the warning sound.

[0080] Wide area communicator 18 is a communication device used to connect to a wide area communication network via cellular lines or Wi-Fi lines. Wide area communicator 18 can function as an interface for data communication between intelligent ECU4 and DKS3.

[0081] <About the structure of BLE communicators>

[0082] Here, the structure of each BLE communicator 7 is described. For example... Figure 6 As shown, each BLE communicator 7 includes an antenna 71, a transceiver unit 72, and a controller 73. The antenna 71 is a metal element used for transmitting and receiving radio waves in the frequency band used for BLE communication, namely the 2.4 GHz band. The antenna 71 is electrically connected to the transceiver unit 72. The antenna 71 can also be configured as an array antenna consisting of multiple antenna elements arranged in a row.

[0083] The transceiver unit 72 is a circuit module that performs signal processing involved in at least one of transmitting and receiving BLE signals. The transceiver unit 72 performs at least one of modulation, demodulation, frequency conversion, amplification, digital-to-analog conversion, and detection. The transceiver unit 72 can be an IC. The transceiver unit 72 is connected to the controller 73. In addition to the modulation and demodulation circuitry, the transceiver unit 72 also includes a received signal strength detection unit 721 and a ranging processing unit 722.

[0084] The receive strength detection unit 721 is a structure that sequentially detects the strength of the signal received by the antenna 71. The signal representing the received strength detected by the receive strength detection unit 721, or its measured value, can also be called RSSI (Received Signal Strength Indicator / Indication). The received strength detected by the receive strength detection unit 721, along with the device ID representing the transmitting source of the received signal and the frequency information of the received signal, is output to the controller 73.

[0085] The ranging processing unit 722 generates a ranging value representing the distance from the BLE communicator 7 to the communicating partner by performing ranging communication with the communicating partner. This ranging value is a parameter representing the time of flight of the signal from the mobile device 2 until it is received by the BLE communicator 7. The ranging value is a parameter different from the received signal strength. Specifically, the ranging value is the round-trip time (RTT) or the dual-frequency phase difference. Ranging communication can be described as communication used to determine the RTT or the dual-frequency phase difference. Since the ranging value represents the one-way or round-trip signal flight time (ToF), it can be called a ToF correlation value.

[0086] Furthermore, RTT is the time from sending a response request signal to the communication partner to receiving a response signal from the communication partner. The ranging processing unit 722 can also use a value obtained by subtracting, from the assumed value of the response processing time generated in the mobile device 2 and the assumed value of the delay time that may occur in the BLE communicator 7, as the RTT, after performing a prescribed correction process on the elapsed time from the actual transmission of the signal to the reception. Additionally, the dual-frequency phase difference is a parameter determined by transmitting and receiving continuous wave (CW) signals through the BLE communicator 7 and the mobile device 2; it is the difference between the transmit and receive phase differences observed at each of the two frequencies. The dual-frequency phase difference corresponds to the displacement of the transmit and receive phase difference caused by frequency changes.

[0087] Based on instructions from the intelligent ECU 4, the BLE communicator 7 performs ranging communication with the mobile device 2 and generates a ranging value report to the processor 41. In this embodiment, a more preferred method is for the ranging processing unit 722 to calculate both the RTT and the dual-frequency phase difference. Furthermore, the ranging processing unit 722 calculates the dual-frequency phase difference for each frequency combination provided for BLE communication. Additionally, the generation (calculation) of the ranging value can be performed by the controller 73 or the intelligent ECU 4. Alternatively, the ranging processing unit 722 can determine the transmit / receive phase difference for each frequency, and the intelligent ECU 4 can calculate the dual-frequency phase difference based on the transmit / receive phase difference for each frequency. The functional division between the BLE communicator 7 and the intelligent ECU 4 can be appropriately varied.

[0088] The controller 73 is a microcomputer that controls the data exchange with the intelligent ECU 4. The controller 73 provides the received data input from the transceiver unit 72 sequentially or based on requests from the intelligent ECU 4. Based on requests from the intelligent ECU 4 or spontaneously, the controller 73 outputs data related to the reception status of signals from the mobile device 2 and ranging values ​​to the intelligent ECU 4. The data indicating the reception status also includes each device ID and the reception strength for each frequency.

[0089] <Regarding the placement and function of BLE communicators>

[0090] like Figure 5 As shown, the vehicle system 1 of this embodiment includes BLE communicators 7a, 7b, 7c, 7p, and 7x. BLE communicator 7a is located on the outer door handle for the driver's seat. BLE communicator 7b is located on the outer door handle for the passenger seat. BLE communicator 7c is located near the trunk door. BLE communicators 7a, 7b, and 7c correspond to BLE communicators 7, i.e., outdoor units, located on the outer surface of the vehicle's Hv (height). BLE communicator 7p is a BLE communicator 7 located inside the vehicle interior. BLE communicator 7p can be located in the center of the dashboard in the vehicle width direction. BLE communicator 7p can be referred to as an indoor unit.

[0091] The BLE communicator 7x is a BLE communicator 7 built into the intelligent ECU 4. The BLE communicator 7x is used for data communication with the mobile device 2. In this disclosure, the communicator used for data communication with the mobile device 2 is also referred to as a gateway communicator. The gateway communicator can also be referred to as a representative, data communicator, etc. Furthermore, the BLE communicator 7x can also be configured outside the frame of the intelligent ECU 4. The settings of the gateway communicator can be dynamically changed by the intelligent ECU 4.

[0092] If the BLE communicator 7x receives an advertising signal from the mobile device 2, it automatically establishes a communication connection with the mobile device 2 using the saved device information. After establishing the communication connection, the intelligent ECU 4 begins encrypted data communication with the mobile device 2. Furthermore, if the BLE communicator 7x establishes a communication connection with the mobile device 2, it provides the device ID of the connected mobile device 2 as connection device information to the processor 41.

[0093] The intelligent ECU4 uses BLE communicator 7, other than BLE communicator 7x, as a communicator for determining the device's position (i.e., for position determination). The so-called BLE communicator 7 for position determination is, in one aspect, equivalent to a BLE communicator 7 used to determine the distance to the mobile device 2. In this disclosure, the BLE communicator 7 for position determination is also referred to as an observation device. In this embodiment, BLE communicators 7a, 7b, 7c, and 7p are equivalent to observation devices. Furthermore, the observation device can also be referred to as a rangefinder or a satellite communicator.

[0094] Furthermore, in BLE communication, data transmission and reception are performed while sequentially changing 37 channels after a communication connection between devices is established. That is, frequency hopping is performed during data communication after the connection is established. Therefore, normally, only the BLE communicator 7x with the communication connection can capture data signals from the mobile device 2. The observer cannot observe the device signals. As a structure to address this situation, the BLE communicator 7x in this embodiment sequentially provides the intelligent ECU 4 with information indicating the channels used for communication with the mobile device 2 (hereinafter, channel information).

[0095] The intelligent ECU4 distributes channel information and device ID obtained from the BLE communicator 7x to each observer as reference information. Each observer can then identify which of the multiple usable channels in BLE can receive the device signal based on the channel information shown in the reference information. As a result, the observer can detect and report the received signal strength of the device, etc., even without a communication connection.

[0096] In this disclosure, the method of determining the device location based on the reception status of signals sent from the mobile device 2 to the gateway communicator in the observation unit is also referred to as a sniffing method. According to the sniffing method, the number of BLE communicators 7 connected to the mobile device 2 can be reduced to a minimum of one. Therefore, power consumption in the mobile device 2 can be suppressed. Furthermore, according to the sniffing method, indicators representing the distances from multiple BLE communicators 7 to the mobile device 2 can be collected in parallel. Therefore, the system responsiveness to the approach of a user holding the mobile device 2 can be improved. Of course, in other methods, each BLE communicator 7 can independently conduct bidirectional communication with the mobile device 2 and send information such as reception strength and distance measurement values ​​to the intelligent ECU 4.

[0097] <Regarding the functions of Intelligent ECU4>

[0098] Here, the functions and operation of the intelligent ECU4 are explained. The intelligent ECU4 provides [services / equipment] by executing programs stored in memory 43. Figure 7 The various functional modules shown correspond to their respective functions. Specifically, the intelligent ECU4 comprises a vehicle information acquisition unit F1, a communication control unit F2, a device location confirmation unit F3, and a response processing unit F4 as its functional units. Additionally, the intelligent ECU4 includes a device information storage unit (DvM).

[0099] The Device Information Storage Unit (DvM) is a storage medium used to store information of the mobile device 2, which is used as an electronic key for the vehicle (Hv). The DvM is implemented using a portion of the storage area of ​​the memory 43. Alternatively, the DvM can be implemented using a non-volatile storage medium physically independent of the memory 43. The DvM is configured to perform data writing, reading, and deletion based on the processor 41.

[0100] The Device Information Storage Unit (DvM) stores information about at least one mobile device 2. Within the DvM, a device ID for each mobile device 2 is stored, linked to a service key, user ID, etc. The user ID is an identifier used to identify multiple users and is set for each user.

[0101] The processor 41 obtains the service key issued by DKS3 to a certain mobile device 2 via the wide area communication device 18, and stores it in the device information storage unit (DvM) in association with the device ID of the mobile device 2. Alternatively, the processor 41 can obtain data related to the service key issued by DKS3 via the mobile device 2 without using the wide area communication device 18, and store it in the device information storage unit (DvM). The device ID of the mobile device 2 is obtained and registered through pairing processing.

[0102] The vehicle information acquisition unit F1 acquires the status of the vehicle's Hv and various vehicle information indicating user operations on the vehicle's Hv from sensors, ECUs, switches, etc., mounted on the vehicle's Hv. This vehicle information includes the status of the driving power supply (on / off), the open / closed status of each door, the locked / unlocked status of each door, the user's operation status on the lock / unlock sensor 5 and the start switch 6, and the gear shift position, etc. Furthermore, acquiring electrical signals from the lock / unlock sensor 5 and the start switch 6 is equivalent to detecting user operations on these operating components. In one aspect, the vehicle information acquisition unit F1 is equivalent to detecting user operations on the vehicle's Hv such as touching the lock / unlock sensor 5, opening / closing a door, or pressing the start switch 6.

[0103] The communication control unit F2 controls the operation of the BLE communicator 7 on the vehicle system 1. When registering a user / device with the intelligent ECU 4, the communication control unit F2 uses the BLE communicator 7x to implement a key exchange protocol with the mobile device 2, a process known as pairing and binding. The information of the mobile device 2 obtained through pairing, i.e., device information, is stored in the memory 43. The device information can also be stored in the non-volatile memory of the controller 73 of each BLE communicator 7. The device information may include keys for cryptographic communication / communication connection exchanged through pairing, device IDs, etc.

[0104] The communication control unit F2 obtains the device ID of the mobile device 2 connected to the BLE communicator 7x. The intelligent ECU4 determines the users present in the vicinity of the vehicle Hv based on the received device ID. Furthermore, if the vehicle Hv is shared by multiple users, it stores the device information of each user's mobile device 2. Additionally, if the vehicle Hv is a service vehicle, the intelligent ECU4 can also pre-obtain the device information corresponding to the user who made the reservation from the DKS3 / other servers cooperating with the DKS3 and temporarily store it in a designated storage medium.

[0105] The communication control unit F2 detects that the mobile device 2 is within close-range communication range with the vehicle system 1 by receiving advertising signals sent from the mobile device 2 via the BLE communicator 7x, and executes the sequence involved in the communication connection. Once a communication connection is established between the BLE communicator 7x and the mobile device 2, the communication control unit F2 uses the BLE communicator 7x to conduct data communication with the mobile device 2.

[0106] In addition, the communication control unit F2 obtains the received signal strength and ranging value for each frequency of the device signal from each BLE communicator 7. The observation data, such as the received signal strength and ranging value provided by each of the multiple BLE communicators 7, are associated with the device ID and the communicator ID providing the signal and stored in RAM 42. For device location determination, the communication control unit F2 causes each BLE communicator 7 to sequentially perform ranging communication with the mobile device 2.

[0107] The device location confirmation unit F3 is a module for determining the location of the mobile device 2. In this disclosure, the device location confirmation unit F3 primarily determines whether the authenticated mobile device 2 exists in the trunk. The device location confirmation unit F3 includes a wireless authentication unit F31, a location determination unit F32, and a failure reason determination unit F33 as sub-functional units.

[0108] The wireless authentication unit F31 collaborates with the BLE communicator 7x to verify (in other words, authenticate) the legitimacy of the communication partner, confirming that the communication partner is indeed the mobile device 2. Communication for authentication is implemented through encryption. As an example, in this embodiment, the wireless authentication unit F31 authenticates the mobile device 2 (communication partner) using a challenge-response method employing a challenge code and a one-time authentication key. The detailed sequence of the wireless authentication process will be described later. Furthermore, the wireless authentication unit F31 also includes a temporary key generation unit F311 as a sub-functional unit, which dynamically generates the one-time authentication key required in the wireless authentication process. The temporary key generation unit F311 is an arbitrary element and may be omitted.

[0109] To enhance security, the intelligent ECU4 in this embodiment only confirms that the communication partner is indeed the mobile device 2 after successful wireless authentication, and then performs various vehicle control functions such as locking and unlocking. In other words, in principle, even if the communication partner is indeed the mobile device 2, the intelligent ECU4 in this embodiment will not allow the mobile device 2 to function as the key for the vehicle's Hv if the wireless authentication process fails. However, as will be described later, this restriction does not apply if the authentication failure reason is specific.

[0110] The timing for the wireless authentication unit F31 to perform wireless authentication processing can be the timing when a communication connection is established between the BLE communicator 7 and the mobile device 2. Alternatively, the wireless authentication unit F31 can be configured to perform wireless authentication processing at predetermined intervals during the period when the BLE communicator 7 and the mobile device 2 are in communication connection.

[0111] Furthermore, the intelligent ECU 4 initiates communication for wireless authentication processing upon triggering a locking operation on the vehicle Hv (hereinafter, locking operation). A locking operation can be the act of touching the lock / unlock sensor 5 with the driving power disconnected and all doors connected to the driver's compartment closed. Receiving a locking instruction signal from the mobile device 2 is also equivalent to performing a locking operation on the vehicle Hv. Based on receiving the locking operation, the intelligent ECU 4 locks all doors of the vehicle Hv.

[0112] Furthermore, the intelligent ECU4 accepts touch from the lock / unlock sensor 5 as a locking and unlocking operation, provided that the authenticated mobile device 2 is present in the lock / unlock area. The lock / unlock area is the area where the vehicle system 1 locks / unlocks the doors, and is the area outside the vehicle exterior within a specified distance (e.g., 1.5m) from each door. The so-called authenticated mobile device 2 is the mobile device 2 that has successfully undergone wireless authentication.

[0113] Furthermore, the intelligent ECU4 triggers the wireless authentication process by closing the trunk door when the vehicle's HV (Hard Vehicle) is locked and only the trunk door is open. The process targets the communication device located inside the trunk. The vehicle's HV being locked means that all the locking mechanisms of the vehicle's HV doors are set to the locked state. Additionally, the trunk door's locking mechanism is configured to be locked even when the trunk door is open. If all the door locking mechanisms are set to the locked state when the trunk door is open, and then the trunk door is closed, the trunk door is locked and will not be opened again.

[0114] The locked state of the vehicle Hv can include a closed-door standby state. The closed-door standby state is the state where locking is completed as soon as a door that has been opened after a lock-up operation is performed closes. As mentioned above, the closed-door standby state also includes a trunk-closed standby state where only the trunk door is open while all door locking mechanisms are set to locked. The closed-door standby state can also include a state where locking of the vehicle Hv has been scheduled using a pre-lock function. The pre-lock function is a function that accepts a lock-up operation while the door is open and locks all doors upon all doors being closed. Thus, the closed-door standby state corresponds to a state where a user's lock-up operation has been performed.

[0115] In addition, the wireless authentication unit F31 can also implement communication for wireless authentication processing by being triggered when the start switch 6 is pressed, the lock / unlock sensor 5 is touched by the user while the vehicle Hv is locked.

[0116] The position determination unit F32 determines the device position based on the reception status of the device signals in each BLE communicator 7. The position determination unit F32 determines the position coordinates relative to the vehicle Hv by combining the ranging values ​​from multiple BLE communicators 7 with the mounting position of each BLE communicator 7 within the vehicle Hv. Since the installation positions of each BLE communicator 7 are known, if three or more distances from the BLE communicators 7 to the mobile device 2 can be obtained, the position coordinates of the mobile device 2 can be calculated using the principles of triangulation or trilateration. The position coordinates of the mobile device 2 can be represented using a vehicle coordinate system, etc.

[0117] Furthermore, the position determination unit F32 determines whether the mobile device 2 is inside the trunk and whether the mobile device 2 is within the trunk's locking / unlocking area based on the determined device position coordinates. The so-called trunk locking / unlocking area is the locking / unlocking area formed around the trunk door handle, which is the area outside the vehicle within a specified distance (e.g., 1.5m) from the trunk door handle.

[0118] Furthermore, to reduce processing load, the location determination unit F32 is configured not to perform location determination on unregistered devices. Additionally, the location determination unit F32 can perform location determination only on devices that are in communication connection with registered devices or devices capable of receiving BLE signals. The smaller the scope of location determination, the lower the processing load on the processor 41 and the more energy is saved.

[0119] In the event of a failure in the wireless authentication process of mobile device 2, the failure reason determination unit F33 determines the reason, i.e., the authentication failure reason, based on the data received from mobile device 2. Reasons for authentication failure include, as described later, inconsistencies between the response code and the verification code, and failure to receive the response from mobile device 2. Furthermore, even for a registered device, reasons for wireless authentication failure include user non-authentication, placement status, and exhaustion of the authentication key. User non-authentication, placement status, and exhaustion of the authentication key will be described separately later. User non-authentication, placement status, and exhaustion of the authentication key are considered specific reasons. Inconsistencies between the response code and the verification code, and failure to receive the response from mobile device 2, are considered other reasons.

[0120] The response processing unit F4, in response to user operations on the vehicle (Hv), collaborates with other ECUs to execute control / processing corresponding to the device location determined by the device location confirmation unit F3. The response processing unit F4 implements either or both of the following: lockout warning processing and device retention invalidation processing. Lockout warning processing is vehicle control that outputs a prescribed warning sound, etc., when it is detected that the key device was left in the trunk during a locking operation. If the conditions for executing lockout warning processing are met, the response processing unit F4 sends a signal to the notification ECU 15 requesting the output of a warning sound, etc.

[0121] The device invalidation process is a vehicle control measure that disables key devices left inside the vehicle when a vehicle HV (Hardware Drive) is locked. Invalidation means temporarily preventing them from functioning as keys for locking and unlocking the vehicle HV. Invalidation can be achieved by removing them from the communication partner or setting them outside the scope of wireless authentication processing. Details regarding lockout warning handling and device invalidation will be discussed later.

[0122] Furthermore, if the device location confirmation unit F3 determines that the mobile device 2 is present in the lock / unlock area and detects that the lock / unlock sensor 5 has been touched by the user, the response processing unit F4, in conjunction with the main ECU 12, locks or unlocks the door. Additionally, if the device location confirmation unit F3 determines that the mobile device 2 is present in the driver's cab and detects that the start switch 6 has been pressed by the user, the response processing unit F4, in conjunction with the power ECU 11, switches the driving power supply from off to on.

[0123] Furthermore, the response processing unit F4 in this embodiment cooperates with other ECUs to perform user notifications such as warnings, locking and unlocking, and switching on and off the driving power supply, but is not limited to this. The intelligent ECU4, which is the response processing unit F4, can also be configured to directly control the electrical devices involved in user notifications, locking and unlocking, etc. Outputting control signals for performing vehicle control to other ECUs is also included in performing vehicle control.

[0124] <Regarding Wireless Authentication Processing>

[0125] Here, the sequence of processing for the intelligent ECU4 to authenticate the mobile device 2 as the communication counterpart is described. The wireless authentication processing of the mobile device 2 performed by the intelligent ECU4 can be as follows: Figure 8 The process includes steps S11 to S18. The wireless authentication process is performed on the premise that an encrypted BLE communication link has been established between the mobile device 2 and the intelligent ECU 4.

[0126] Furthermore, the establishment of a BLE communication link indicates that the communication partner is a paired mobile device 2. If the authentication used for communication connection is considered as the first level of authentication processing, i.e., one authentication process, then the wireless authentication process is equivalent to the second level of authentication processing, i.e., two authentication processes.

[0127] Step S11 is the step of sending a challenge code from the intelligent ECU4 to the mobile device 2. The challenge code can be a random number of a specified length generated using a pre-prepared random number table. Alternatively, the challenge code can be a random number generated by using the timing information (so-called system timing) possessed by the intelligent ECU4 as a SEED. The challenge code can be determined in various ways.

[0128] Step S12 is the step whereby the mobile device 2 generates a response code by combining any one-time authentication key stored in the device information storage unit (DVM) and the received challenge code in a prescribed manner. The one-time authentication key is discarded after use. Step S13 is the step whereby the mobile device 2 returns the response code generated in step S12 and the set of variable codes corresponding to the one-time authentication key used to generate the response code to the intelligent ECU 4.

[0129] Step S14 is the step where the intelligent ECU4 generates a one-time authentication key using the change code received from the mobile device 2 and the service key corresponding to the communication counterpart stored in the device information storage unit (DVM). Here, the combination of the service key and the change code used by the intelligent ECU4 in generating the one-time authentication key is the same as the material used to generate the one-time authentication key for generating the response code. Therefore, the one-time authentication key generated by the intelligent ECU4 in step S14 is the same as the one-time authentication key used by the mobile device 2 in generating the response code. This step S14 is equivalent to the process of recovering the one-time authentication key used by the mobile device 2 in generating the response code based on the change code received from the mobile device 2 and the service key of the mobile device 2 stored within the ECU itself.

[0130] In step S15, the intelligent ECU4 generates a verification code based on the one-time authentication key generated in step S14 and the challenge code sent in step S11. The method for generating the verification code is the same as that for generating the response code. If the communication counterpart is a mobile device 2 that holds the service key registered in the Device Information Storage Unit (DVM), the verification code can be expected to match the response code. However, if the communication counterpart is an unregistered device, no response code may be returned, or the response code may not match the verification code. Therefore, the generated / received response code functions as information used to verify the legitimacy of the communication counterpart.

[0131] In step S16, the intelligent ECU4 determines the legitimacy of the communication partner by comparing the verification code generated in step S15 with the response code received from the mobile device 2. If the two codes match, the intelligent ECU4 determines that authentication is successful (step S17). On the other hand, if the two codes are different, the intelligent ECU4 determines that authentication has failed (step S18). Furthermore, if no response code is returned even after a specified response wait time has elapsed since the challenge code was sent, the intelligent ECU4 can also determine that authentication has failed. Additionally, the intelligent ECU4 of this disclosure can also replace the response code from the mobile device 2 and determine that authentication has failed upon receiving a signal indicating that authentication is not possible (described later).

[0132] The aforementioned vehicle system 1 uses a one-time authentication key generated based on the service key inherent to each mobile device 2 to authenticate both the mobile device 2 and the user. Therefore, compared to structures that use fixed key information for mobile terminal authentication, security is improved. Furthermore, according to the above method, the information exchanged between the intelligent ECU 4 and the mobile device 2 when generating the response code is a change code and a challenge code. During authentication, the one-time authentication key itself is not sent or received between the authentication ECU and the mobile terminal. Moreover, the one-time authentication key used for authentication changes each time. Therefore, according to the above method, concerns about third parties improperly enabling successful wireless authentication processing can be reduced. Here, "third party" refers to someone who is not a user of the vehicle (Hv).

[0133] Furthermore, the authentication sequence described above is an example and is not limited to it. The actions of each device can be designed such that the one-time authentication key used to generate the response code / verification code is the same in both the mobile device 2 and the smart ECU 4. In a structure where the smart ECU 4 and the mobile device 2 share multiple one-time authentication keys, the smart ECU 4 can also notify the number of the one-time authentication key used for wireless authentication processing with the mobile device 2.

[0134] <Device Response Processing>

[0135] Here, as a device response process, it is used Figure 9 The operation of mobile device 2 upon receiving a challenge code is explained. If mobile device 2 receives a challenge code from vehicle Hv, it determines whether it is in a user authentication state (S21). Here, if it is not in a user authentication state, i.e., the user has not logged into digital key application 204 (S21: No), mobile device 2 returns a user unauthenticated signal to vehicle Hv (S22). The user unauthenticated signal is a BLE signal containing a code indicating that it is not in a user authentication state. The user unauthenticated signal is equivalent to a response signal indicating that it cannot respond to wireless authentication processing or has not returned a response code.

[0136] Additionally, if mobile device 2 is in user authentication mode (S21: Yes), it determines whether the current state of mobile device 2 conforms to the placement mode based on the signal from acceleration sensor 23 (S23). If the current state of mobile device 2 conforms to the placement mode (S23: Yes), mobile device 2 returns a no-action signal to vehicle Hv (S24). The no-action signal is a BLE signal containing a code indicating that it is in the placement mode. The no-action signal is equivalent to a response signal indicating that it cannot respond to wireless authentication processing or has not returned a response code.

[0137] If the mobile device 2 is not in a placed state (S23: No), it determines whether at least one one-time authentication key remains in the key information storage unit KyM (S25). If at least one one-time authentication key remains in the key information storage unit KyM (S25: Yes), the mobile device 2 uses any one of the remaining one-time authentication keys to generate a response code (S26) and returns it to the vehicle Hv (S27). Steps S26 to S27 correspond to Figure 8 The sequence of steps S12 to S13.

[0138] On the other hand, when there are no one-time authentication keys remaining in the key information storage unit KyM, an authentication key exhaustion signal is returned to the vehicle Hv (S28). The authentication key exhaustion signal is a BLE signal containing a code indicating that the one-time authentication keys have been exhausted, i.e., the authentication key exhaustion state. The authentication key exhaustion signal is equivalent to a response signal indicating that the wireless authentication process cannot be responded to or that no response code is returned.

[0139] As described above, when the mobile device 2 receives a challenge code, it implements a response corresponding to whether the user has been authenticated, whether it is in a placement state, and whether it retains a one-time authentication key. In this disclosure, the user unauthenticated signal, the no-action signal, and the authentication key exhaustion signal are collectively referred to as authentication failure signals. When the intelligent ECU 4 receives an authentication failure signal, such as a user unauthenticated signal, it determines that the authentication has failed. Furthermore, when the failure reason determination unit F33 receives a user unauthenticated signal from the communication partner, it determines that the authentication failure reason is user unauthentication. When the failure reason determination unit F33 receives a no-action signal from the communication partner, it determines that the authentication failure reason is placement. When the authentication exhaustion signal is received, the failure reason determination unit F33 determines that the authentication failure reason is authentication key exhaustion.

[0140] Furthermore, the mobile device 2 is not limited to sending an authentication failure signal upon receiving a challenge code; it can also send the signal before receiving a challenge code, such as at the time when a BLE communication link is established. The device control unit 20 can also send an authentication failure signal as a response to a response request signal from the intelligent ECU 4, or it can send the signal spontaneously at any time after the BLE communication link is established. The timing of sending the authentication failure signal can be appropriately changed.

[0141] Alternatively, the device control unit 20 can also send a preparation signal indicating readiness to handle wireless authentication processing after the reason for the failure to authenticate has been eliminated following the initial failure signal. Reasons for failure to authenticate include exhaustion of the one-time authentication key, storage status, and user non-authentication. Upon receiving the preparation signal, the intelligent ECU4 can also send a challenge code to the source of the preparation signal and perform wireless authentication processing.

[0142] <Handling of Lockout Warnings>

[0143] Here, use Figure 10 The flowchart shown illustrates the lock warning process implemented by the intelligent ECU4. The lock warning process can be triggered by the trunk door being closed while the door is in a closed standby state. As an example, the lock warning process includes steps S101 to S108.

[0144] Step S101 is a trunk search process where the device location confirmation unit F3 determines whether the mobile device 2 exists in the trunk. In step S101, the device location confirmation unit F3 determines the device's location coordinates by enabling each BLE communicator 7 to perform ranging communication with the mobile device 2, and then determines whether the mobile device 2 exists in the trunk. This search process can be performed on the mobile device 2 that has been paired with the intelligent ECU 4. Step S101 is equivalent to a location determination process.

[0145] As a result of the trunk search process in step S101, if the mobile device 2 is not found in the trunk (S102: No), the intelligent ECU4 assumes that the locked mobile device 2 does not exist in the trunk, and the intelligent ECU4 completes the locking process (S103). In this case, no special controls such as warning processing are implemented. The state of "locking completed" can be a state where all doors, including the trunk door, are closed and locked.

[0146] On the other hand, if it is determined that a registered device exists in the trunk (S102: Yes), the intelligent ECU4 performs wireless authentication processing for the device in the trunk (S104). The so-called device in the trunk can be a mobile device 2 that exists in the trunk.

[0147] If the wireless authentication of the device in the trunk is successful (S105: Yes), the intelligent ECU4 performs a lock-on record process (S107). The lock-on record process is used to maintain the internal state that a mobile device 2 is locked in the trunk. The lock-on record process includes setting the trunk lock flag to "ON" and saving the device ID of the device in the trunk as locked device information in the memory 43. The trunk lock flag is an indicator indicating whether a locked device exists. The locked device refers to the mobile device 2 locked in the trunk.

[0148] Furthermore, in the event that the wireless authentication process of the device in the trunk fails (S105: No), the intelligent ECU4 in this embodiment determines the reason for the failure based on the received data of the device. Then, it determines whether the reason for the failure meets any one of the following: user not authenticated, placement status, or authentication key exhausted (S106).

[0149] If the authentication failure is due to any of the following reasons: user not authenticated, placement status, or exhaustion of authentication keys (S106: Yes), the intelligent ECU4 assumes that the mobile device 2 is located in the trunk and performs the same locking record processing as if the wireless authentication process were successful (S107). On the other hand, if the wireless authentication process for the device in the trunk fails for other reasons (S106: No), the intelligent ECU4 locks the vehicle (S103).

[0150] Upon detecting that the mobile device 2 is locked in the trunk, the intelligent ECU 4, in cooperation with the notification ECU 15, implements a warning process (S108). The warning process may include at least one of the following: outputting a prescribed warning sound from the alarm 17 and displaying a warning message on the in-vehicle display 16. By implementing this warning process, the user can recognize that the mobile device 2 has been accidentally placed in the trunk.

[0151] Next, use Figure 11 The flowchart shown illustrates the trunk unlocking process. The trunk unlocking process is the control process used to unlock the trunk door. The trunk unlocking process is implemented based on the user touching the lock / unlock sensor 5 located on the trunk door when the vehicle's Hv (Hard Vehicle Valve) is locked. Figure 11 The trunk unlocking procedure shown can be used as Figure 10 The process is carried out in the subsequent steps of step S103 or S108.

[0152] Step S201 is a step of determining whether a locked device exists by referring to the records in the memory 43, etc. If the records indicate that a locked device exists (S201: Yes), the intelligent ECU 4 sequentially / simultaneously performs the trunk exterior confirmation process and the trunk interior confirmation process (S202-S203). The trunk exterior confirmation process determines whether the mobile device 2 exists within the trunk's lock / unlock area, including device location determination and wireless authentication. The trunk interior confirmation process determines whether the mobile device 2 exists inside the trunk, including location determination and wireless authentication. The trunk interior confirmation process in step S203 is equivalent to the opening confirmation process.

[0153] Step S204, as a result of steps S202 to S203, determines whether mobile device 2 has been found in the trunk or in the trunk's lock / unlock area. Finding mobile device 2 means that not only is mobile device 2 present, but its wireless authentication process is also successful. If mobile device 2 is found in the trunk or in the trunk's lock / unlock area, the trunk door is unlocked (S220).

[0154] Furthermore, if the mobile device 2 is not found in the trunk or in the trunk locking / unlocking area, it is determined whether the mobile device 2, which failed wireless authentication for a specific reason, exists in the trunk or in the trunk locking / unlocking area (S205). If the mobile device 2, which failed wireless authentication for a specific reason, exists in the trunk or in the trunk locking / unlocking area (S205: Yes), the intelligent ECU4 unlocks the trunk door (S220).

[0155] Furthermore, if no legitimate device is found in the trunk or in the trunk's lock / unlock area, and there is no mobile device 2 that failed wireless authentication for a specific reason (S205: No), the intelligent ECU4 maintains the trunk door locked (S221). The legitimate device is the mobile device 2 that has successfully undergone wireless authentication. Additionally, if no locked device is found (S201: No), the intelligent ECU4 does not perform trunk-in-the-trunk confirmation processing, but only trunk-outside confirmation processing (S210). Moreover, if a legitimate device is found in the trunk's lock / unlock area, the intelligent ECU4 unlocks the trunk door (S220).

[0156] Based on the above structure, even if the trunk is closed and in standby mode, and the trunk door is accidentally closed while a mobile device 2 is inside the trunk, and even worse, if wireless authentication fails due to reasons such as running out of authentication keys, the user can still unlock the trunk. Furthermore, according to... Figure 11The trunk unlocking procedure shown allows anyone other than the user to open the trunk by touching the lock / unlock sensor 5, even when the mobile device 2 is locked in the trunk. However, in this situation, a lock warning is triggered once the trunk door is closed. Therefore, when the mobile device 2 is locked in the trunk, the user must perform the trunk unlocking operation before leaving the vehicle. In other words, Figure 11 The trunk unlocking process shown works in a way that, in reality, only the user can unlock the trunk door.

[0157] <Regarding the handling of residual equipment>

[0158] Here, use Figure 12 The flowchart shown illustrates the process of invalidating left-behind devices. This invalidation process involves disabling the mobile device 2 left in the trunk at a predetermined time upon receiving a locking operation. The intelligent ECU 4 performs this invalidation process when it receives a locking operation while the driving power is off and all doors are closed. Specifically, receiving a locking operation means receiving a locking instruction signal. Additionally, the situation where the locking / unlocking sensor 5 is pressed after confirming the presence of a legitimate device within the locking / unlocking area can also be included in the scenario of receiving a locking operation.

[0159] The aforementioned lockout warning processing corresponds to the situation where the user accidentally locks the mobile device 2 inside the vehicle (in the trunk). In contrast, the device invalidation processing corresponds to the situation where the user intentionally locks the mobile device 2 in the trunk. From the perspective of execution conditions, the lockout warning processing is triggered by the door closing after the locking operation, while the device invalidation processing is triggered by accepting the locking operation. As an example, the device invalidation processing includes steps S301 to S306.

[0160] Step S301 is the same as step S101, where the device location confirmation unit F3 determines whether the mobile device 2 exists in the trunk. If the mobile device 2 is found in the trunk (S302: Yes), the intelligent ECU 4 performs wireless authentication processing for the device in the trunk (S303). Alternatively, if the mobile device 2 is not found in the trunk (S302: No), the process ends.

[0161] If the wireless authentication of the device in the trunk is successful (S304: Yes), the intelligent ECU4 disables the device in the trunk (S306). Specifically, data indicating that the device in the trunk is unusable when the door is unlocked is stored in the memory 43, etc.

[0162] Additionally, if the wireless authentication process of a device in the trunk fails (S304: No), the intelligent ECU4 determines the reason based on the received data of that device. Then, it determines whether the reason for the authentication failure matches any one of the following: user not authenticated, placement status, or authentication key exhausted (S305).

[0163] If the authentication failure is due to any of the following reasons: user not authenticated, placement status, or authentication key exhaustion (S305: Yes), the intelligent ECU4 considers the mobile device 2, as a legitimate device, to exist in the trunk and disables the device in the trunk (S306). In other words, if the authentication failure reason meets a specific condition, the intelligent ECU4 performs the same processing as if the wireless authentication process were successful. On the other hand, if the wireless authentication process for the device in the trunk fails for other reasons (S305: No), the intelligent ECU4 does not disable the device in the trunk and terminates the process.

[0164] Based on the above structure, since the mobile device 2 placed in the trunk by the user before the locking operation is disabled, even if the trunk's lock / unlock sensor 5 is touched as a trigger to perform the trunk confirmation process, the wireless authentication process will fail. Therefore, it is possible to prevent unauthorized unlocking of the trunk by a third party. Furthermore, since the device invalidation process is triggered by a locking operation with all doors closed, it presupposes that the user possesses a different mobile device 2 than the locked device. In other words, even if the locked device is disabled, the user can still unlock the vehicle using this different mobile device 2 without any problems.

[0165] <Summary of the operation and effects of Intelligent ECU4>

[0166] In a typical PEPS system, vehicle control corresponding to the location of mobile device 2 is not executed if wireless authentication processing fails. However, if the execution conditions and authentication methods for wireless authentication processing become more complex / stricter, the possibility of determining that mobile device 2 is not in the trunk even if it is actually there increases. As a result, the number of times control corresponding to the device's location fails to function may also increase. Even if a system is configured not to return a response code when mobile device 2 is in a placed state to improve security, the same problem may still occur.

[0167] Regarding this issue, according to the structure of this embodiment, even if the wireless authentication process of the communication partner fails, and the reason for failure is specific, the mobile device 2 is considered to be present in the trunk, assuming the communication partner is a registered device. Furthermore, as a result, concerns about the invalidation failure of locked devices or the malfunction of locked warning processing can be reduced.

[0168] Furthermore, as a comparison structure, any communication partner whose wireless authentication process fails is considered an illegitimate device, regardless of the reason for the failure. In this comparison structure, if authentication of a device in the trunk fails, the intelligent ECU4 cannot recognize the presence of mobile device 2 in the trunk. As a result, the comparison structure locks mobile device 2 in the trunk against the user's intention. Moreover, the comparison structure also fails to disable mobile device 2 left in the trunk.

[0169] Furthermore, the failure due to key exhaustion can be eliminated over time by the mobile device 2 obtaining a one-time authentication key from the DKS3. The mobile device 2 left in the trunk may, over time, obtain a one-time authentication key from the DKS3 and regain an authenticable state. If the uninvalidated mobile device 2 left in the trunk regains an authenticable state, a third party may unlock the trunk. According to this embodiment, the problems inherent in the above comparison structure can be mitigated / eliminated.

[0170] Furthermore, in cases where authentication of a device in the trunk fails due to the exhaustion of authentication keys, this includes situations where mobile device 2, having exhausted its one-time authentication key during the wireless authentication process used for locking, is placed in the trunk and the trunk door is closed. Ideally, mobile device 2 should operate to replenish the one-time authentication key from DKS3 before the remaining number of one-time authentication keys reaches zero. However, depending on the communication environment, the communication settings of mobile device 2, maintenance of DKS3, etc., it is possible that the one-time authentication key cannot be replenished in time. The so-called authentication failure of mobile device 2 due to its placement state refers to the situation where the trunk door is closed after the placement determination time has elapsed since mobile device 2 was placed in the trunk. If, after the user performs the locking operation and places mobile device 2 in the trunk, the placement determination time passes while tidying up goods or talking to fellow passengers, authentication failure due to the placement state may occur. The user's authentication state may also be naturally released due to the passage of time. According to the structure of this disclosure, concerns about being warned of being locked and leaving the device inoperable in situations that, while not frequent, are likely to occur frequently can be reduced.

[0171] The embodiments of this disclosure have been described above, but this disclosure is not limited to the above-described embodiments. Various modifications described below are also included within the technical scope of this disclosure. Furthermore, various changes and implementations can be made without departing from the spirit of the text, except as described below. The various supplements and modifications described below can be appropriately combined and implemented without creating technical contradictions. In addition, components having the same function as the components described above are marked with the same reference numerals, and their descriptions are omitted. Furthermore, when only a part of the structure is mentioned, the above description can be applied to other parts.

[0172] <Implementation of the confirmation process in the trunk>

[0173] In the aforementioned trunk unlocking process, the trunk interior confirmation process is triggered only when the intelligent ECU4 detects that the mobile device 2 is locked inside the trunk, by touching the trunk lock / unlock sensor 5. However, this is not a limitation. When the trunk lock / unlock sensor 5 is touched, both trunk interior and trunk exterior confirmation processes can be performed regardless of whether the vehicle is locked or not. In this case, the intelligent ECU4 can also ignore responses from invalid mobile devices 2. An invalidated mobile device 2 can also be reactivated when another mobile device 2 is used to unlock the vehicle (Hv).

[0174] <BLE Communicator Installation Location>

[0175] The number and configuration of the BLE communicators 7 described above are just one example and can be modified as appropriate. BLE communicators 7a and 7b can also be configured on the outer side of the B-pillar or C-pillar. Furthermore, the B-pillar of the vehicle Hv can be divided into the door-side B-pillar (included in the door module) and the body-side B-pillar (serving as a support / frame for the roof of the vehicle body). The door-side B-pillar corresponds to the portion where the front or rear seat door abuts against the body-side pillar. The outdoor unit can be located in the portion of the door-side B-pillar adjacent to the side window, i.e., the portion above the lower end of the side window. Alternatively, the outdoor unit can also be configured on the outer side of the vehicle's outer B-pillar.

[0176] The BLE communicator 7p can also be located near the gearshift lever, near the start switch 6, on the center console, or at the foot of the driver's seat. The BLE communicator 7p can also be located on the interior side of the driver's side door, such as in the door pocket or at the base of the B-pillar. Furthermore, multiple indoor units can be present. The vehicle system 1 can also have a BLE communicator 7 located on the interior side of the right-hand door and a BLE communicator 7 located on the interior side of the left-hand door. For example... Figure 13 As shown, the vehicle system 1 may also have a trunk-mounted communicator 7t, which is a BLE communicator 7 located in the trunk.

[0177] <Methods for determining equipment location>

[0178] The presence of mobile device 2 in the trunk can also be determined based on the reception strength of mobile device 2 in the trunk's communicator 7t. The location determination unit F32 can also determine that mobile device 2 exists in the trunk based on the reception strength of mobile device 2 in the trunk's communicator 7t being a predetermined value or higher. Similarly, the location determination unit F32 can also determine that mobile device 2 exists in the driver's cab based on the reception strength in the indoor unit being a predetermined value or higher.

[0179] <A variation of the space as a locked / invalidated object>

[0180] like Figure 14 As shown, the vehicle Hv, apart from the trunk interior space CSt, can have a charging inlet storage section CSc and a front storage section CSb located inside the hood, as an independent enclosed space separate from the driver's cab (Cbn). The trunk interior space CSt is the inner space of the trunk, and the charging inlet storage section CSc is the inner space of the charging cover. The independent space CS, which is used for applications such as locking warning processing of mobile device 2, can be the charging inlet storage section CSc, the front storage section CSb, etc. Furthermore, the so-called charging cover is a cover that blocks the opening of the connector, etc., that connects to the charging plug / cable, and is also called a charging port cover.

[0181] Furthermore, while the above description addresses the operation when the mobile device 2 is placed in the trunk, the same structure can also be applied when the mobile device 2 is placed in the passenger compartment. The intelligent ECU 4 can also implement lock warnings and disable functions if the mobile device 2, which has failed wireless authentication for a specific reason, is present in the passenger compartment. The vehicle interior includes not only the passenger compartment but also the trunk, charging port storage area, and front storage area.

[0182] <Regarding the issuance terminal of one-time authentication keys>

[0183] The above implementation illustrates how DKS3 generates a one-time authentication key and distributes it to mobile device 2, but it is not limited to this. Smart ECU4 may also generate and distribute a one-time authentication key based on conditions such as successful wireless authentication processing. DKS3 is an arbitrary element and can be omitted. DKS3 and Smart ECU4 are equivalent to issuing terminals.

[0184] <Other>

[0185] In the event of authentication failure for a specific reason, the control that the intelligent ECU4 can perform can be limited to either the locked warning or the device invalidation. The intelligent ECU4 can be configured to not implement control over unlocking the door connecting to the driver's cab in the event of authentication failure of the mobile device 2, regardless of the reason for the failure. Regarding the control of switching the driving power supply from off to on, the intelligent ECU4 can also be configured not to implement this control even if the authentication failure of the mobile device 2 is due to a specific reason. Regarding the control of locking the vehicle Hv, it can be implemented even if authentication fails, provided that the authentication failure reason is a specific reason, the communication partner is a registered device, and the communication partner exists in the lock / unlock zone. According to this structure, concerns about the vehicle Hv being used by third parties can be reduced, and user convenience can be improved.

[0186] <Postscript>

[0187] The apparatus, systems, and methods described in this disclosure can also be implemented by a dedicated computer, which constitutes a processor programmed to perform one or more functions embodied in a computer program. The apparatus and methods described in this disclosure can also be implemented using dedicated hardware logic circuits. The apparatus and methods described in this disclosure can also be implemented by more than one dedicated computer, which is composed of a processor executing a computer program and a combination of more than one hardware logic circuit. Some or all of the functions of the intelligent ECU4 can be implemented as hardware. Implementing a function as hardware includes using one or more ICs, etc. The processor (processor core) can be a CPU, MPU, GPU, or DFP (Data Flow Processor), etc. Some of the functions of the intelligent ECU4 can be implemented using a SoC (System-on-Chip), IC (Integrated Circuit), or FPGA (Field-Programmable Gate Array). The concept of IC also includes ASIC (Application Specific Integrated Circuit).

[0188] Furthermore, computer programs can be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. The recording medium for the program can be an HDD (Hard-disk Drive), an SSD (Solid State Drive), flash memory, etc. The program used to enable the computer to function as an intelligent ECU4, and non-transitory physical recording media such as semiconductor memory storing the program, are also included within the scope of this disclosure.

Claims

1. A vehicle control device that determines the location of a key device by wirelessly communicating with the key device, wherein, The aforementioned key device is a mobile device that is pre-registered as a vehicle key. The aforementioned vehicle control device includes: The device location confirmation unit performs wireless authentication processing and location determination processing. In the wireless authentication processing, it determines whether the communication partner is the key device based on the data sent from the communication partner. In the location determination processing, it determines whether the communication partner is inside the vehicle based on the reception status of the signal from the communication partner. as well as The failure reason determination unit, when the device location confirmation unit fails to determine that the communication counterpart is the key device through the wireless authentication process, determines the authentication failure reason based on the data received from the communication counterpart. This authentication failure reason is the reason why the communication counterpart was not identified as the key device. The device location confirmation unit is configured such that even if it cannot be determined that the communication counterpart is the key device, if the authentication failure reason is a specific reason and it is determined that the communication counterpart is located inside the vehicle, the key device is considered to be present inside the vehicle.

2. The vehicle control device according to claim 1, wherein, The aforementioned device location confirmation unit determines whether the communication counterpart exists in the independent space section based on the reception status of the signal from the communication counterpart. The independent space section is a closed space provided by the vehicle that is separate from the driver's cab. The device location confirmation unit is configured such that even if it cannot be determined that the communication counterpart is the key device, if the authentication failure reason is the specific reason and it is determined that the communication counterpart exists in the independent space, the key device is also considered to exist in the independent space.

3. The vehicle control device according to claim 2, wherein, The aforementioned independent space is the trunk.

4. The vehicle control device according to claim 3, wherein, The device location confirmation unit is triggered when the vehicle is set to a locked state with only the trunk door open, and then the trunk door is closed, to confirm whether the key device exists in the trunk.

5. The vehicle control device according to claim 4, wherein, The aforementioned vehicle control device is used to prevent the aforementioned key device from being locked in the aforementioned trunk. The vehicle control device includes a response processing unit. When the device location confirmation unit determines that the key device is present in the trunk when the trunk door is closed, the response processing unit performs a warning that the key device is present in the trunk. When a user operation to open the trunk door is detected after the aforementioned warning, the device location confirmation unit performs a confirmation process to verify whether the key device is present in the trunk. If the key device is determined to be present in the trunk during the opening confirmation process, the response processing unit performs a process to switch the locking mechanism of the trunk to the unlocked state.

6. The vehicle control device according to claim 3, wherein, The aforementioned vehicle control device is configured to register multiple of the aforementioned key devices. The device location confirmation unit is configured to determine whether the key device exists in the trunk when a user operation to lock the vehicle is received while all doors are closed.

7. The vehicle control device according to claim 6, wherein, If the device location confirmation unit determines that the key device is present in the trunk when the vehicle is locked, the key device present in the trunk is invalidated.

8. The vehicle control device according to claim 1, wherein, The above wireless authentication process includes the following steps: Send a challenge code to the aforementioned communication counterpart; and The aforementioned communication counterpart uses a one-time authentication key generated by a designated issuing terminal to generate a response code as a response to the aforementioned challenge code, and sends the response code to the aforementioned vehicle. The aforementioned key device is configured to, in the absence of the aforementioned one-time authentication key, return an authentication key exhaustion signal indicating that the aforementioned one-time authentication key has been exhausted. If the device location verification unit receives the authentication key exhaustion signal, it will not determine that the communication counterpart is the key device. The failure reason determination unit determines that the authentication failure reason is authentication key exhaustion based on the receipt of the authentication key exhaustion signal. The aforementioned authentication key exhaustion is set for the specific reason stated above.

9. The vehicle control device according to claim 1, wherein, The aforementioned key device is configured such that, when stationary for a specified period of time, in response to a response request signal from the aforementioned vehicle, it returns a no-action signal indicating that the key device has not moved within the specified time. If the aforementioned device location confirmation unit receives the aforementioned no-action signal, it will not determine that the aforementioned communication counterpart is the aforementioned key device. The failure reason determination unit, based on the receipt of the aforementioned no-action signal, determines that the authentication failure reason is no action. The aforementioned inaction is set for the specific reason stated above.

10. The vehicle control device according to claim 1, wherein, The aforementioned key device has a user authentication function that uses biometric information or a password to determine the user's legitimacy. The key device is configured such that, in the event that the user's authentication fails, it returns a user unauthentication signal indicating that the user's authentication failed in response to a response request signal from the vehicle. If the aforementioned device location verification unit receives the aforementioned unauthenticated user signal, it will not determine that the aforementioned communication counterpart is the aforementioned key device. The failure reason determination department, based on the receipt of the aforementioned user unauthentication signal, determines that the authentication failure reason is user unauthentication. The above-mentioned user is not authenticated, which is set as the specific reason mentioned above.

11. The vehicle control device according to claim 2, wherein, The aforementioned independent space is the inner space of the charging cover or the inner space of the engine hood.

12. The vehicle control device according to any one of claims 1 to 11, wherein, The above-mentioned equipment position confirmation unit is configured as follows: Obtain the device ID of the aforementioned communication partner. Based on the condition that the device ID is registered as the aforementioned key device, the aforementioned location determination process and the aforementioned wireless authentication process are performed. Even if the above wireless authentication process fails, the key device corresponding to the above device ID is considered to exist in the vehicle, provided that the above device ID has been registered as the above key device, the above authentication failure reason is the above specific reason, and the location of the communication counterpart is determined to be inside the vehicle.

13. A vehicle control method, implemented by at least one processor, wherein the vehicle control method determines the location of a key device by wirelessly communicating with the key device, wherein... The aforementioned key device is a mobile device that is pre-registered as a vehicle key. The above vehicle control method includes the following steps: The presence of the other party in the vehicle is determined based on the reception status of the wireless signal sent by the other party. Based on the data sent from the aforementioned communication counterpart, determine whether the aforementioned communication counterpart is the aforementioned key device; If the communication counterpart is not determined to be the key device, the authentication failure reason is determined based on the content of the received data. The authentication failure reason is the reason for not determining the communication counterpart to be the key device. as well as Even if the aforementioned communication counterpart is not determined to be the aforementioned key device, if the aforementioned authentication failure reason is a specific reason and it is determined that the aforementioned communication counterpart is present in the vehicle, the aforementioned key device is also considered to be present in the vehicle.

Images