Vehicle control device and vehicle control method

Abstract

To provide a vehicle control device and a vehicle control method which are capable of reducing the risk of determining that a portable device does not exist in a vehicle due to authentication failure although the portable device functioning as a key of the vehicle actually exists in the vehicle.SOLUTION: A smart ECU, when establishes a communication connection with a portable device, authenticates a communication partner by using a one-time authentication key distributed in advance to the portable device. When the portable device runs out of the one-time authentication key, the portable device returns a signal indicating that the one-time authentication key has been run out to the signal from the smart ECU. When the communication partner exists in the trunk and the reason for the authentication failure is that the one-time authentication key has expired, the smart ECU determines that a legitimate portable device having the device ID of the communication partner exists in the trunk, and performs a confinement warning process.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present disclosure relates to a vehicle control device and a vehicle control method that executes vehicle control related to locking / unlocking a vehicle after authenticating the legitimacy of a communication partner. [Background technology]

[0002] Conventionally, a system that controls vehicle locking / unlocking is known in which an in-vehicle system communicates wirelessly with a key device to estimate the key device's location and perform authentication processing, automatically locking / unlocking the vehicle, etc. This system is called a smart entry system or a passive entry / passive start (PEPS) system.

[0003] Patent Document 1 discloses a system that recognizes a key device left inside a vehicle when the vehicle is locked using the auto-lock function and disables the key device. If the key device left inside the vehicle is not disabled, anyone can unlock the vehicle by responding to a search signal from the vehicle based on an unlocking operation. The above-mentioned control for disabling the key device addresses this issue.

[0004] In addition, some PEPS key systems have controls that emit a warning sound or other alarm if the system detects that the key device is still inside the vehicle when the locking operation is accepted, in order to prevent the key device from being locked inside the vehicle (so-called "lock-in"). [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 5846024 Summary of the Invention [Problem to be solved by the invention]

[0006] Controls such as sounding an alarm to prevent people being locked inside the vehicle and disabling a key device left inside the vehicle will operate as intended by the designer (i.e., normally), provided that wireless communication can be used to confirm that the key device is still inside the vehicle.

[0007] However, because location determination and verification processes using wireless communication are affected by factors such as the radio wave environment, it is possible that the key device may not be determined to be inside the vehicle even though it is still inside. Naturally, if the in-vehicle system cannot recognize the key device remaining inside the vehicle for some reason when locking the vehicle, controls such as lock-in prevention will not function.

[0008] In recent years, the introduction of countermeasures against relay attacks and digital key systems has led to increasingly sophisticated and complex authentication processes between key devices and in-vehicle systems. This has led to various reasons for failure of authentication of portable devices. This raises concerns about an increasing number of cases in which the alarm sound output to prevent lock-in and the disabling of key devices left inside the vehicle will not work.

[0009] The present disclosure has been made based on the above considerations or points of view, and one of its purposes is to provide a vehicle control device and a vehicle control method that can reduce the risk of determining that a portable device that can function as a vehicle key is not present in the vehicle due to authentication failure, even though the portable device is actually present in the vehicle. [Means for solving the problem]

[0010] The vehicle control device disclosed herein is a vehicle control device that determines the location of a key device by wirelessly communicating with a key device, which is a portable device that has been pre-registered as a vehicle key, and is equipped with a device location confirmation unit (F3) that performs a wireless authentication process that determines whether the communication partner is a key device based on data sent from the communication partner, and a location determination process that determines whether the communication partner is present inside the vehicle based on the reception status of the signal from the communication partner, and a failure reason identification unit (F33) that, if the device location confirmation unit does not determine that the communication partner is a key device in the wireless authentication process, identifies the authentication failure reason that is the reason why the communication partner was not determined to be a key device based on the data received from the communication partner.The device location confirmation unit is configured to consider the key device to be present inside the vehicle even if it cannot determine that the communication partner is a key device, if the reason for the authentication failure is the identified reason and the location of the communication partner is determined to be inside the vehicle.

[0011] In addition, 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, which is a portable device that has been pre-registered as a key for the vehicle, by wirelessly communicating with the key device, and includes the steps of: determining whether the communication partner is present in the vehicle based on the reception status of a wireless signal transmitted from the communication partner; determining whether the communication partner is a key device based on data transmitted from the communication partner; if the communication partner is not determined to be a key device, identifying the authentication failure reason that is the reason for not determining the communication partner as a key device based on the content of the received data; and, even if the communication partner is not determined to be a key device, if the authentication failure reason is a specified reason and the communication partner is determined to be present in the vehicle, determining that the key device is present in the vehicle.

[0012] According to the above-described apparatus / method, even if authentication of a portable device fails for a specific reason, the portable device is considered to be present in the vehicle, thereby reducing the possibility that the portable device is determined not to be present in the vehicle due to authentication failure, even though the portable device is actually present in the vehicle.

[0013] In addition, the symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a diagram showing an overall view of a vehicle digital key system. [Figure 2] FIG. 1 is a block diagram showing a configuration of a portable device. [Figure 3] FIG. 2 is a functional block diagram of a device control unit. [Figure 4] FIG. 1 is a block diagram showing a configuration of an in-vehicle system. [Figure 5] FIG. 1 is a diagram illustrating an example of a mounting position of a BLE communication device. [Figure 6] FIG. 1 is a diagram illustrating the configuration of a BLE communication device. [Figure 7] FIG. 2 is a functional block diagram of a smart ECU. [Figure 8] FIG. 10 is a sequence diagram showing the flow of wireless authentication processing. [Figure 9] 10 is a flowchart illustrating the operation of the mobile device. [Figure 10] 10 is a flowchart of a confinement warning process. [Figure 11] 10 is a flowchart of a trunk unlocking process. [Figure 12] 10 is a flowchart of a remaining device invalidation process. [Figure 13] FIG. 10 is a diagram illustrating another example of the arrangement of BLE communication devices. [Figure 14] FIG. 2 is a diagram illustrating an example of an independent space portion provided in a vehicle. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. FIG. 1 is a diagram showing an example of a schematic configuration of a vehicle digital key system Sys. As shown in FIG. 1, the vehicle digital key system Sys includes an in-vehicle system 1, a portable device 2, and a digital key server (DKS) 3. The in-vehicle system 1 is a system mounted on a vehicle Hv. The portable device 2 is a device carried by a user of the vehicle Hv. There may be multiple portable devices 2.

[0016] <Preface> In the following description, the vehicle Hv is, as an example, a four-wheeled vehicle owned by an individual. The user of the vehicle Hv refers to the owner, their family, etc. The vehicle Hv may be a company car owned by a company organization or an official car owned by a public institution. If the vehicle Hv is a company car or official car, the user may be a person belonging to the organization that manages the vehicle Hv. The vehicle Hv may be a vehicle provided for a rental service (a so-called rental car), or a vehicle provided for a car sharing service (a so-called shared car). If the vehicle Hv is a vehicle provided for the above services (hereinafter referred to as a service vehicle), the user may be a person who has signed a service contract for those services and has the authority to temporarily use the vehicle Hv based on a service reservation, etc.

[0017] The vehicle Hv is, for example, an electric vehicle, more specifically, a hybrid vehicle that can be externally charged (so-called plug-in hybrid vehicle). The concept of an electric vehicle includes not only electric vehicles, but also hybrid vehicles and fuel cell vehicles. A hybrid vehicle is a vehicle equipped with an engine and a motor as a power source. In another embodiment, the vehicle Hv may be an engine vehicle.

[0018] The vehicle Hv is a type of vehicle, such as a sedan, in which the cabin and trunk are not connected. The vehicle Hv is configured so that the locking mechanisms of all doors can be set to a locked state even when the trunk door is open. The trunk door may also be called a rear hatch, hatchback, or rear gate.

[0019] The vehicle Hv has a driver's seat on the right side. Alternatively, the vehicle Hv may have a driver's seat on the left side. In the following description, the front-rear, left-right, and up-down directions are defined based on the vehicle Hv unless otherwise noted.

[0020] The various flowcharts shown in this disclosure are merely examples, and the number of steps constituting the flowcharts and the order in which the processes are executed can be changed as appropriate. In addition, the following description can be modified as appropriate to conform to the laws, regulations, and customs of the region in which the vehicle Hv is used.

[0021] <Overview> Both the in-vehicle system 1 and the portable device 2 are configured to be capable of short-range communication. Here, short-range communication refers to communication conforming to a predetermined short-range wireless communication standard in which the actual communication distance is, for example, 1 m to 30 m, and at most approximately 100 m. Examples of short-range communication standards that can be adopted here include Bluetooth (registered trademark) and Wi-Fi (registered trademark). The Bluetooth standard may be Bluetooth Classic or Bluetooth Low Energy (BLE). Various Wi-Fi standards can be adopted, such as IEEE802.11n, IEEE802.11ac, and IEEE802.11ax (so-called Wi-Fi 6). IEEE (registered trademark) is an abbreviation for the Institute of Electrical and Electronics Engineers. Alternatively, UWB-IR (Ultra Wide Band - Impulse Radio) can be adopted as a communication method between the in-vehicle system 1 and the portable device 2, in other words, as a short-range communication method. Furthermore, the in-vehicle system 1 and the portable device 2 may be configured to be capable of wireless communication using radio waves in the LF (Low Frequency) band, such as 125 kHz or 134 kHz.

[0022] The following describes the operation of each part, taking as an example a case where the in-vehicle system 1 and the portable device 2 are configured to be able to perform wireless communication conforming to the BLE standard (hereinafter referred to as BLE communication). Details of the communication sequence, such as establishing a communication connection and starting encrypted communication, are performed in accordance with the BLE standard. In the following, the term "BLE communication" can be replaced with "UWB communication" or "short-range communication." The in-vehicle system 1 includes a smart ECU 4 as a device that actually performs data communication with the portable device 2. ECU is an abbreviation for Electronic Control Unit, and refers to an electronic control device.

[0023] The following describes a case where the smart ECU 4 is configured to act as a master in communication with the portable device 2, and the portable device 2 is configured to act as a slave. By receiving an advertising signal from the portable device 2, the smart ECU 4 establishes a communication connection with the portable device 2 and detects the presence of the portable device 2 (and thus the user) in the vicinity of the vehicle Hv. The advertising signal is a signal for notifying (i.e., advertising) other devices of its own presence. In another aspect, the portable device 2 may be configured to act as a master in communication with the smart ECU 4.

[0024] BLE signals, which are wireless signals conforming to the BLE standard, can be transmitted from a variety of devices. In this disclosure, devices that transmit BLE signals are collectively referred to as BLE devices. BLE devices are classified into registered devices that are paired with the vehicle HV / smart ECU 4 and unregistered devices that are not paired. Pairing refers to registering at least the device ID of the communication partner in internal storage or the like. The device ID is an identification number for the BLE device. Examples of device IDs that can be used include a device address or a universally unique identifier (UUID). The mobile device 2 is a registered device. BLE signals, such as advertising signals, include a device ID that indicates the sender. The smart ECU 4 can identify whether the communication partner is the mobile device 2 or an unregistered device based on the device ID included in the received signal.

[0025] The smart ECU 4 and the portable device 2 are configured to be able to communicate with the DKS 3 using 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 conforming to standards such as 4G or 5G. Data communication using a Wi-Fi line is referred to as Wi-Fi communication. Various Wi-Fi standards can be adopted, such as IEEE802.11n, IEEE802.11ac, and IEEE802.11ax (so-called Wi-Fi 6).

[0026] The DKS 3 is a server located outside the vehicle Hv. The DKS 3 can perform data communication with each of the smart ECU 4 and the portable device 2 via a wide area communication network such as the Internet. Based on a request from the portable device 2, the DKS 3 issues a service key and a one-time authentication key to the portable device 2 for using the vehicle Hv.

[0027] The service key is a core code that enables the portable device 2 to function as a key for the vehicle Hv. The service key is different for each combination of the vehicle Hv and the portable device 2. For example, the DKS 3 issues the output value of a predetermined hash function, which uses a value obtained by combining the vehicle ID and the device ID as an input value, as the service key. The vehicle ID is a unique identification number assigned to each vehicle, such as a vehicle identification code (VIN: Vehicle Identification Number). The service key may be a password of a predetermined number of characters registered by the user, or a value obtained by inputting the password into a predetermined hash function.

[0028] The one-time authentication key is a disposable authentication key that is discarded after one use. The one-time authentication key is a code used by the smart ECU 4 to verify the legitimacy of the communication partner, that is, to verify that the mobile device 2 is truly the mobile device 2. The one-time authentication key is generated by combining a service key with a variable code (variation factor). The variable code has a value that differs each time a one-time authentication key is issued. The variable code can be, for example, epoch seconds, the number of times the one-time authentication key is issued, or a random number. For example, the one-time authentication key can be generated by inputting the service key and the variable code into a predetermined generation function. The generation function is a function that takes two inputs, the service key and the variable code. The generation function may also be a predetermined hash function. The input value to the generation function may be a value that simply combines (i.e., concatenates) the service key and the variable code, or a value obtained by multiplying or adding them. Such a one-time authentication key may also be called a token.

[0029] <About Mobile Device 2> The portable device 2 is a portable, general-purpose information processing terminal equipped with a BLE communication function. Various communication terminals, such as a smartphone or a wearable device, can be used as the portable device 2. A wearable device is a device worn on the user's body and can take various forms, such as a wristband, a watch, a ring, glasses, or earphones. The portable device 2 of the present disclosure may be realized by separating it into a motherboard (main unit) such as a smartphone and a wearable device.

[0030] As shown in FIG. 2, the portable device 2 includes a device control unit 20, a display 21, a touch panel 22, an acceleration sensor 23, a biometric authentication device 24, a BLE communication unit 25, a cellular communication unit 26, and a Wi-Fi communication unit 27.

[0031] The device control unit 20 is a module that controls the overall operation of the portable device 2. The device control unit 20 is configured as a computer including, for example, a device processor 201, a RAM (Random Access Memory) 202, a storage 203, etc. The device processor 201 is, for example, a CPU (Central Processing Unit). The RAM 202 is a volatile storage medium. The storage 203 is configured to include a non-volatile storage medium such as a flash memory.

[0032] The device control unit 20 also includes a digital key application 204 as application software (hereinafter, referred to as application). The digital key application 204 is an application for securely performing user authentication, acquisition / storage of a service key, and communication with the smart ECU 4. The digital key application 204 is installed in, for example, the storage 203.

[0033] The display 21 is, for example, a liquid crystal display or an organic EL display. The display 21 displays an image in response to an input signal from the device control unit 20. The touch panel 22 is a capacitance-type touch panel and is layered on the display 21. The touch panel 22 is an input device provided in the portable device 2. The touch panel 22 and the display 21 correspond to an interface through which the user inputs a password for logging in to the digital key application 204 into the portable device 2 and through which the portable device 2 is paired with the smart ECU 4.

[0034] The acceleration sensor 23 is a sensor that detects acceleration acting on the portable device 2. The output (detection data) of the acceleration sensor 23 is input to the device control unit 20. The output signal of the acceleration sensor 23 functions as a signal indicating whether the portable device 2 is in a portable state or an abandoned state. The portable state refers to a state in which the portable device 2 is moving with the user or being operated by the user. The abandoned state refers to a state in which the user is not carrying the portable device 2, for example, a state in which the portable device 2 has been placed in a stable place for a predetermined period of time or more. A stable place refers to a desk, counter, shelf, floor, etc. A seat, console box, or trunk of a parked car can also be a stable place.

[0035] The biometric authentication device 24 is a device that authenticates a user using, for example, the user's fingerprint or face image. The biometric authentication device 24 may also be a device that authenticates a user using a vein pattern of a hand or finger, an iris pattern, a voiceprint, or the like. The user authentication result is provided to the device control unit 20.

[0036] The BLE communication unit 25 is a communication module for performing BLE communication. The cellular communication unit 26 is a communication module for performing cellular communication. The Wi-Fi communication unit 27 is a communication module for performing Wi-Fi communication. The various communication modules include an antenna capable of transmitting and receiving radio waves in the frequency band to be transmitted and received, a communication microcomputer that controls communication, a modulation / demodulation circuit, etc. The cellular communication unit 26 and the Wi-Fi communication unit 27 are optional elements and may be omitted.

[0037] The device control unit 20 includes a one-time authentication key management unit G1 and a vehicle response unit G2 as functional units that are realized when the device processor 201 executes the digital key application 204, as shown in FIG.

[0038] The device control unit 20 also includes a key information storage unit KyM. The key information storage unit KyM is realized using a storage area included in the storage 203 or the RAM 202. The key information storage unit KyM is a storage area for storing a service key for the device itself issued by the DKS 3, a one-time authentication key, a user ID, and the like.

[0039] The one-time authentication key management unit G1 acquires one-time authentication keys from the DKS3 and stores them in the key information storage unit KyM. The one-time authentication key management unit G1 occasionally transmits a signal to the DKS3 requesting the delivery of one-time authentication keys so that a predetermined number or more of one-time authentication keys are maintained stored in the key information storage unit KyM. For example, the one-time authentication key management unit G1 sets a replenishment necessity flag to ON when the remaining number of one-time authentication keys stored in the key information storage unit KyM falls below a predetermined replenishment threshold. The one-time authentication key management unit G1 downloads multiple one-time authentication keys from the DKS3 when the replenishment necessity flag is set to ON and the DKS3 is online. The replenishment threshold can be, for example, 150 or 300.

[0040] The DKS3 distributes a one-time authentication key and a variable code as a set. In other words, the one-time authentication key management unit G1 obtains each one-time authentication key from the DKS3 while linking it to the variable code used to generate the one-time authentication key. The one-time authentication key management unit G1 itself does not have the function to generate one-time authentication keys. This configuration makes it possible to keep the details of the one-time authentication key generation method confidential. This ultimately improves the security performance of the vehicle digital key system Sys.

[0041] The vehicle response unit G2 is configured to execute data communication with the smart ECU 4 via BLE based on the establishment of a BLE communication link (connection) with the smart ECU 4. For example, the vehicle response unit G2 executes wireless communication for authentication based on the establishment of a BLE communication link with the smart ECU 4. The wireless authentication process between the smart ECU 4 and the portable device 2 can be performed, for example, by a challenge-response method. In this case, the vehicle response unit G2 generates a response code using a one-time authentication key in response to the challenge code transmitted from the smart ECU 4, and transmits the response code back to the smart ECU 4.

[0042] The device control unit 20 determines whether the portable device 2 is in a carried state or an abandoned state based on a signal from the acceleration sensor 23. For example, the device control unit 20 determines that the portable device 2 is in an abandoned state based on the fact that the stationary state has continued for a predetermined abandoned state determination time or longer. The stationary state is a state in which the acceleration sensor 23 does not detect acceleration of a predetermined value or greater. The abandoned state determination time is set to, for example, 3 minutes or 5 minutes. If the abandoned state is determined, the vehicle response unit G2 does not return a response code to the vehicle Hv. The shorter the abandoned state determination time, the less likely the portable device 2 will inadvertently respond to a call from the smart ECU 4, thereby improving security and power-saving performance. The device control unit 20 determines that the portable state is in a carried state when acceleration of a predetermined value or greater is detected. The result of the determination that the portable device is in a carried state can be maintained until it is determined that the portable device has transitioned to an abandoned state.

[0043] The device control unit 20 also performs user authentication processing when the digital key application 204 is started. User authentication (login) can be performed by inputting a predetermined user ID and password into the digital key application 204. User authentication may also be performed using the biometric authentication device 24. Because the digital key application 204 is part of the vehicle digital key system Sys, a state in which a user is logged in to the digital key application 204 corresponds to a state in which a user is logged in to the vehicle digital key system Sys. In this way, the device control unit 20 has a user authentication function that determines the legitimacy of an operator (i.e., a user) using biometric information or a password.

[0044] The logged-in state is released when a predetermined expiration date has passed since the login time or the last operation time, or when the portable device 2 is shut down. In other words, the digital key application 204 transitions to a logged-off state under predetermined conditions. The logged-off state is a state in which the user must be re-authenticated. In this disclosure, the state in which the portable device 2 / digital key application 204 authenticates the user using biometric information or a password is referred to as a user authentication state.

[0045] Additionally, the device control unit 20 may be configured to display a vehicle status confirmation screen, which is a screen for checking the status of the vehicle hybrid, as a function of the digital key app 204. The vehicle status confirmation screen is a screen that shows the remaining gasoline / battery level, the open / closed status of each window and door, the lock status, the temperature inside the vehicle, etc. The device control unit 20 may also be configured to remotely operate some of the electrical equipment provided in the vehicle hybrid. For example, based on a user operation on the touch panel 22, the device control unit 20 may transmit wireless signals instructing the user to lock / unlock the vehicle hybrid, turn on / off the air conditioning system, open / close windows, turn off hazard lights, etc. For convenience, an instruction signal for locking the vehicle hybrid will be referred to as a lock instruction signal.

[0046] The portable device 2 may be a smart key, which is a dedicated device used as an electronic key for the vehicle Hv. The smart key is a device that is transferred to the owner together with the vehicle Hv when the vehicle Hv is purchased. The smart key can be considered one of the accessories to the vehicle Hv. The smart key can have a variety of shapes, such as a flat rectangular parallelepiped type, a flat ellipsoid type (a so-called fob type), or a card type. The smart key may be called a vehicle portable device, a key fob, a key card, an access key, or the like.

[0047] <Configuration of In-Vehicle System 1> This section describes the configuration and operation of the in-vehicle system 1. As shown in Fig. 4, the in-vehicle system 1 includes a smart ECU 4, multiple lock / unlock sensors 5, a start switch 6, and multiple BLE communication devices 7. The in-vehicle system 1 also includes a power supply ECU 11, a body ECU 12, body-related actuators 13, body-related sensors 14, a notification ECU 15, an in-vehicle display 16, a warning horn 17, and a wide-area communication device 18.

[0048] The smart ECU 4 is connected to the lock / unlock sensor 5, the start switch 6, and the BLE communication device 7 via dedicated signal lines. The smart ECU 4 is also connected to the power supply ECU 11, the body ECU 12, and the like so that they can communicate with each other via an in-vehicle network Nw. The in-vehicle network Nw is a communication network built in the vehicle Hv. A variety of standards can be adopted for the in-vehicle network Nw. The connection configuration between devices shown in FIG. 4 is an example, and the specific connection configuration between devices can be changed as appropriate.

[0049] The smart ECU 4 is an ECU that determines the device position relative to the vehicle Hv in cooperation with the BLE communication device 7 and the like, and performs vehicle control according to the device position determination result. In this disclosure, the device position means the position of the portable device 2. Since the portable device 2 corresponds to the user, determining the device position is equivalent to determining the user's position. The smart ECU 4 is disposed, for example, in the instrument panel. The smart ECU 4 may be attached to the interior side of the right or left C-pillar. The C-pillar refers to the third pillar from the front among the pillars provided on the vehicle Hv.

[0050] The smart ECU 4 is implemented using a computer. That is, the smart ECU 4 includes a processor 41, a RAM 42, a storage 43, an I / O 44, and a bus line connecting these components. The smart ECU 4 of this embodiment includes one BLE communication device 7 in its housing.

[0051] The storage 43 includes a non-volatile storage medium such as a flash memory. The storage 43 stores control programs executed by the processor 41. The control programs include a device location confirmation program that determines the location of the portable device 2. The processor 41 accesses the RAM 42 to execute various processes for realizing the functions of each functional unit described below. Execution of the control program by the processor 41 corresponds to execution of a vehicle control method corresponding to the control program. The I / O 44 is a circuit module for communicating with other devices.

[0052] The storage 43 stores a device ID for each portable device 2. The storage 43 also stores communication device setting data indicating the mounting position of each BLE communication device 7 in the vehicle Hv. The mounting position of each BLE communication device 7 can be expressed as a point on a vehicle coordinate system, which is a two-dimensional coordinate system centered on an arbitrary position on the vehicle Hv and parallel to both the width direction and the front-to-rear direction of the vehicle Hv. The X axis forming the vehicle coordinate system can be set parallel to the vehicle width direction, and the Y axis can be set parallel to the front-to-rear direction of the vehicle. The center of the coordinate system can be any location, such as the center of the vehicle body or the mounting position of the smart ECU 4. Details of the smart ECU 4 will be described separately later.

[0053] The locking / unlocking sensor 5 is a touch sensor that allows a user to lock and unlock the doors of the vehicle Hv. The locking / unlocking sensor 5 is provided on the outer door handle of each door. The outer door handle refers to a gripping member provided on the outer surface of the door for opening and closing the door. The locking / unlocking sensor 5 is provided on all door handles, including the trunk door handle. The locking / unlocking sensor 5 detects a user's touch from a change in capacitance or a change in pressure, and outputs an electrical signal indicating this to the smart ECU 4. Note that a button / switch can also be used as a configuration for receiving at least one of the user's unlocking instruction and locking instruction. A locking / unlocking button can be provided on each door handle instead of or together with the locking / unlocking sensor 5. The locking / unlocking sensor 5 of the present disclosure can be interpreted as a door button for locking and unlocking.

[0054] The start switch 6 is a push switch that the user uses to turn the running power supply on and off. The running power supply is the power supply for the vehicle HV to run, and if the vehicle is an engine vehicle, it refers to the ignition power supply. If the vehicle HV is an electric vehicle, the running power supply refers to the system main relay. When the start switch 6 is pushed by the user, it outputs an electrical signal indicating this to the smart ECU 4. The start switch 6 can also be read as a starting switch.

[0055] The BLE communicator 7 is a communication module for performing BLE communication. A plurality of BLE communicators 7 are provided in the vehicle Hv. As shown in FIG. 5 , the in-vehicle system 1 of this embodiment includes BLE communicators 7a, 7b, 7c, 7p, and 7x as the BLE communicators 7. The BLE communicator 7x is built into the smart ECU 4, while the other BLE communicators 7 are arranged outside the smart ECU 4. Each BLE communicator 7 provided outside the smart ECU 4 is connected to the smart ECU 4 via a dedicated communication line or an in-vehicle network Nw so as to be able to communicate with the smart ECU 4.

[0056] Each BLE communicator 7 operates based on a control signal from the smart ECU 4. Each BLE communicator 7 also provides the smart ECU 4 with received data and data related to the reception status of signals from the portable device 2. In this disclosure, signals from the portable device 2 are also referred to as device signals. Each BLE communicator 7 is assigned a unique communicator number. The communicator number functions as information for identifying multiple BLE communicators 7.

[0057] The power supply ECU 11 is an ECU that controls the on / off state of the running power supply installed in the vehicle Hv. For example, the power supply ECU 11 switches the running power supply from off to on based on a request signal from the smart ECU 4. If the vehicle Hv is an engine vehicle, the power supply ECU 11 starts the engine based on a command signal from the smart ECU 4.

[0058] The body ECU 12 is an ECU that controls the body system actuators 13 based on requests from the smart ECU 4 or the user. The body ECU 12 is communicatively connected to various body system actuators 13 and various body system sensors 14. Here, the body system actuators 13 are, for example, door lock motors that constitute the lock mechanisms of each door. The body system sensors 14 include courtesy switches disposed on each door. The courtesy switches are sensors that detect whether the doors are open or closed. Based on a request from the smart ECU 4, for example, the body ECU 12 outputs a predetermined control signal to the door lock motors provided on each door of the vehicle Hv, thereby switching the lock mechanisms of each door from an unlocked state to a locked state, or vice versa.

[0059] The notification ECU 15 uses the in-vehicle display 16 and the horn 17 to warn the user that the portable device 2 has been trapped inside the vehicle. Being trapped refers to the user locking the portable device 2 while leaving it inside the vehicle. Being trapped is also called being locked out. The in-vehicle display 16 is, for example, a liquid crystal display or an organic EL display. The in-vehicle display 16 is disposed, for example, in the central region of the instrument panel in the vehicle width direction or in the region in front of the driver's seat. The horn 17 is a device that outputs a warning sound to the outside of the vehicle.

[0060] Based on a request from the smart ECU 4, the notification ECU 15 displays a warning message on the in-vehicle display 16 or activates the horn 17. The warning message may be, for example, a message such as "A mobile device has been left in the trunk." The in-vehicle system 1 may be provided with a speaker capable of outputting a voice message toward the outside of the vehicle, for example, near the trunk door, instead of or in parallel with the horn 17. In this case, the warning message may be output as voice along with or instead of the warning sound.

[0061] The wide - area communication device 18 is communication equipment for connecting to a wide - area communication network using a cellular line or a Wi - Fi line. The wide - area communication device 18 can function as an interface for the smart ECU 4 to perform data communication with the DKS 3.

[0062] <Configuration of the BLE communication device> Here, the configuration of each BLE communication device 7 will be described. As shown in FIG. 6, each BLE communication device 7 includes an antenna 71, a transceiver unit 72, and a controller 73. The antenna 71 is a metal element for transmitting and receiving radio waves in the frequency band used for BLE communication, that is, the 2.4 GHz band. The antenna 71 is electrically connected to the transceiver unit 72. The antenna 71 may be configured as an array antenna formed by arranging a plurality of antenna elements side by side.

[0063] The transceiver unit 72 is a circuit module that performs signal processing related to at least one of the transmission of BLE signals and the reception of 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 is realized, for example, as an IC. The transceiver unit 72 is connected to the controller 73. In addition to the modulation - demodulation circuit, the transceiver unit 72 includes a reception strength detection unit 721 and a ranging processing unit 722.

[0064] The reception strength detection unit 721 is configured to sequentially detect the strength of the signal received by the antenna 71. A signal indicating the reception strength detected by the reception strength detection unit 721 or the measured value itself may also be called RSSI (Received Signal Strength Indicator / Indication). The reception strength detected by the reception strength detection unit 721 is output toward the controller 73 together with the device ID indicating the transmission source of the received signal and the frequency information of the received signal.

[0065] The ranging processing unit 722 performs ranging communication with the communication partner, thereby generating a ranging value indicating the distance from the BLE communication device 7 to the communication partner. The ranging value here is a parameter indicating the signal flight time from when a signal is transmitted from the portable device 2 until it is received by the BLE communication device 7. The ranging value is a parameter different from the reception strength. Specifically, the ranging value is the round-trip time (RTT) or the two-frequency phase difference. Ranging communication can be rephrased as communication for measuring the RTT or the two-frequency phase difference. The ranging value indicates the signal flight time (ToF) for one way or round trip, and therefore can be called a ToF-related value.

[0066] The RTT is the time from when a response request signal is transmitted to a communication partner until a response signal is received from the communication partner. The ranging processing unit 722 may use, as the RTT, a value obtained by performing a predetermined correction process, such as subtracting an estimated value of a response processing time that occurs in the mobile device 2 or an estimated value of a delay time that may occur in the BLE communication device 7, from the time that has elapsed since the actual transmission of a signal until it is received. The two-frequency phase difference is a parameter determined by the BLE communication device 7 and the mobile device 2 transmitting and receiving a continuous wave (CW) signal, and is the difference between the transmission and reception phase differences observed at each of the two frequencies. The two-frequency phase difference corresponds to the amount of change in the transmission and reception phase difference due to a change in frequency.

[0067] The BLE communication device 7 performs ranging communication with the mobile device 2 based on an instruction from the smart ECU 4, generates a ranging value, and reports it to the processor 41. In a more preferred aspect of this embodiment, the ranging processing unit 722 calculates both the RTT and the two-frequency phase difference. Further, the ranging processing unit 722 calculates the two-frequency phase difference for each combination of frequencies used for BLE communication. Note that the generation (calculation) of the ranging value may be performed by the controller 73 or the smart ECU 4. For example, the ranging processing unit 722 may identify the transmission / reception phase difference for each frequency, and the smart ECU 4 may calculate the two-frequency phase difference for each combination of frequencies based on the transmission / reception phase difference for each frequency. The functional sharing between the BLE communication device 7 and the smart ECU 4 can be changed as appropriate.

[0068] The controller 73 is a microcomputer that controls the transfer of data with the smart ECU 4. The controller 73 sequentially provides the received data input from the transmission / reception unit 72 to the smart ECU 4 based on a request from the smart ECU 4. The controller 73 outputs data regarding the reception status of signals from the mobile device 2 and the ranging value to the smart ECU 4 based on a request from the smart ECU 4 or spontaneously. The data indicating the reception status also includes the reception intensity for each device ID and each frequency.

[0069] <Regarding the mounting position and role of the BLE communication device> As shown in FIG. 5, the vehicle-mounted system 1 of this embodiment includes BLE communication devices 7a, 7b, 7c, 7p, and 7x. The BLE communication device 7a is provided on the outer door handle for the driver's seat. The BLE communication device 7b is provided on the outer door handle for the passenger seat. The BLE communication device 7c is provided near the trunk door. The BLE communication devices 7a, 7b, and 7c correspond to outdoor units, which are BLE communication devices 7 arranged on the outer surface of the vehicle Hv. The BLE communication device 7p is a BLE communication device 7 arranged inside the vehicle cabin. The BLE communication device 7p is arranged, for example, at the center in the vehicle width direction of the instrument panel. The BLE communication device 7p can be called an indoor unit.

[0070] The BLE communicator 7x is a BLE communicator 7 built into the smart ECU 4. The BLE communicator 7x is used for data communication with the portable device 2. In the present disclosure, a communicator used for data communication with the portable device 2 is also referred to as a gateway communicator. The gateway communicator can also be referred to as a representative device or a data communicator. The BLE communicator 7x may be located outside the housing of the smart ECU 4. The settings of the gateway communicator may be dynamically changed by the smart ECU 4.

[0071] When the BLE communication device 7x receives an advertising signal from the portable device 2, it automatically establishes a communication connection with the portable device 2 using the stored device information. After the communication connection is established, the smart ECU 4 starts encrypted data communication with the portable device 2. When the BLE communication device 7x establishes the communication connection with the portable device 2, it provides the processor 41 with the device ID of the portable device 2 with which it is connected as connected device information.

[0072] The smart ECU 4 uses the BLE communicators 7 other than the BLE communicators 7x as communicators for determining the device position (i.e., for position determination). In one aspect, the BLE communicators 7 for position determination correspond to the BLE communicators 7 for measuring the distance to the portable device 2. In this disclosure, the BLE communicators 7 for position determination are also referred to as observation devices. In this embodiment, the BLE communicators 7a, 7b, 7c, and 7p correspond to the observation devices. The observation devices can also be called distance finders or satellite communication devices.

[0073] In BLE communication, once a communication connection between devices is established, data is transmitted and received while successively changing among 37 channels. That is, frequency hopping is performed during data communication after the connection is established. Therefore, normally, only the BLE communication device 7x that is connected to the device can capture the data signal from the portable device 2. The observation device will not be able to observe the device signal. To address such a situation, the BLE communication device 7x of this embodiment successively provides the smart ECU 4 with information indicating the channel to be used for communication with the portable device 2 (hereinafter, referred to as channel information).

[0074] The smart ECU 4 distributes the channel information and device ID acquired from the BLE communication device 7x to each observation device as reference information. Each observation device can recognize, based on the channel information indicated in the reference information, which of the many channels available for BLE it should use to receive the device signal. As a result, the observation device can detect and report the reception strength of the device signal, etc., without a communication connection.

[0075] In the present disclosure, a method for determining a device location based on the reception status at an observation device of a signal transmitted from the portable device 2 to the gateway communication device is also referred to as a sniffing method. The sniffing method allows the number of BLE communication devices 7 connected to the portable device 2 to be reduced to a minimum of one, thereby reducing power consumption at the portable device 2. Furthermore, the sniffing method allows for parallel collection of indicators indicating the distance to the portable device 2 from multiple BLE communication devices 7, thereby improving system responsiveness to the approach of a user carrying the portable device 2. Of course, in another embodiment, each BLE communication device 7 may individually perform bidirectional communication with the portable device 2 and transmit information such as reception strength and distance measurements to the smart ECU 4.

[0076] <About the Smart ECU4 functions> Here, the functions and operations of the smart ECU 4 will be described. The smart ECU 4 provides functions corresponding to the various functional blocks shown in FIG. 7 by executing programs stored in the storage 43. That is, the smart ECU 4 includes, as functional units, a vehicle information acquisition unit F1, a communication control unit F2, a device location confirmation unit F3, and a response processing unit F4. The smart ECU 4 also includes a device information storage unit DvM.

[0077] The device information storage unit DvM is a storage medium for storing information about the portable device 2 used as an electronic key for the vehicle Hv. The device information storage unit DvM is realized using a part of the storage area of ​​the storage 43. The device information storage unit DvM may also be realized using a non-volatile storage medium that is physically independent from the storage 43. The device information storage unit DvM is configured so that the processor 41 can write, read, delete, and so on data.

[0078] The device information storage unit DvM stores information about at least one portable device 2. The device information storage unit DvM stores a device ID for each portable device 2 in association with a service key, a user ID, etc. The user ID is an identifier for identifying multiple users and is set for each user.

[0079] The processor 41 acquires a service key issued by the DKS3 to a certain portable device 2 via the wide area communication device 18, associates it with the device ID etc. of the portable device 2, and stores it in the device information storage unit DvM. Note that the processor 41 may acquire data related to the service key issued by the DKS3 via the portable device 2, rather than via the wide area communication device 18, and store it in the device information storage unit DvM. The device ID etc. of the portable device 2 are acquired and registered by BLE pairing.

[0080] The vehicle information acquisition unit F1 acquires various vehicle information indicating the state of the vehicle Hv and user operations on the vehicle Hv from sensors, ECUs, switches, etc. mounted on the vehicle Hv. The vehicle information includes, for example, the state (on / off) of the running power supply, the open / closed state of each door, the locked / unlocked state of each door, the user's operations on the locking / unlocking sensor 5 and start switch 6, the shift position, etc. Note that acquiring electrical signals from the locking / unlocking sensor 5 and start switch 6 corresponds to detecting user operations on these operating members. In one aspect, the vehicle information acquisition unit F1 corresponds to a configuration that detects user operations on the vehicle Hv, such as touching the locking / unlocking sensor 5, opening / closing a door, pressing the start switch 6, etc.

[0081] The communication control unit F2 controls the operation of the BLE communication device 7 included in the in-vehicle system 1. For example, at the time of user registration, the communication control unit F2 executes a key exchange protocol with the portable device 2, so-called pairing / bonding, using the BLE communication device 7x. Device information about the portable device 2 acquired through pairing is stored in the storage 43 and also in a non-volatile memory included in the controller 73 of each BLE communication device 7. The device information includes, for example, a key for encrypted communication / communication connection exchanged through pairing, a device ID, etc.

[0082] The communication control unit F2 acquires the device ID of the portable device 2 connected for communication from the BLE communication device 7x. The smart ECU 4 identifies the users present in the vicinity of the vehicle Hv based on the received device ID. If the vehicle Hv is shared by multiple users, device information for each portable device 2 owned by each user is stored. Furthermore, if the vehicle Hv is a service vehicle, the smart ECU 4 may acquire device information corresponding to the user who has reserved use in advance from the DKS 3 or another server linked thereto, and temporarily store the device information in a predetermined storage medium.

[0083] The communication control unit F2 receives a signal, such as an advertising signal, transmitted from the portable device 2 via the BLE communication device 7x, thereby detecting that the portable device 2 is within a range where short-distance communication is possible with the in-vehicle system 1, and executes a sequence for establishing a communication connection. When a communication connection between the BLE communication device 7x and the portable device 2 is established, the communication control unit F2 performs data communication with the portable device 2 using the BLE communication device 7x.

[0084] Additionally, the communication control unit F2 acquires the reception strength and distance measurement values ​​for each frequency of the device signal from each BLE communication device 7. Observation data such as reception strength and distance measurement values ​​provided from each of the multiple BLE communication devices 7 is associated with the device ID and the communication device ID of the provider and stored in the RAM 42. The communication control unit F2 may cause each BLE communication device 7 to perform distance measurement communication with the portable device 2 in turn to determine the device position.

[0085] The device location confirmation unit F3 is a module that determines the location of the portable device 2. In the present disclosure, the device location confirmation unit F3 mainly determines whether or not an authenticated portable device 2 is present in the trunk. The device location confirmation unit F3 includes, as sub-functional units, a wireless authentication unit F31, a location determination unit F32, and a failure reason identification unit F33.

[0086] The wireless authentication unit F31 cooperates with the BLE communication device 7x to perform processing to confirm the legitimacy of the communication partner, that is, to confirm that the communication partner is truly the portable device 2 (in other words, to authenticate). Communication for authentication is performed in an encrypted form. As an example, the wireless authentication unit F31 of this embodiment authenticates the portable device 2 (communication partner) using a challenge-response method that uses a challenge code and a one-time authentication key. A detailed sequence of the wireless authentication processing will be described separately later. The wireless authentication unit F31 further includes, as a sub-function unit, a temporary key generation unit F311 that dynamically generates a one-time authentication key required for the wireless authentication processing. The temporary key generation unit F311 is an optional element and may be omitted.

[0087] To improve security, the smart ECU 4 of this embodiment determines that the communication partner is truly the portable device 2 only after the wireless authentication process is successful, and executes various vehicle controls such as locking and unlocking. In other words, even if the communication partner is truly the portable device 2, the smart ECU 4 of this embodiment does not allow the portable device 2 to function as a key for the vehicle Hv unless the wireless authentication process is successful. However, as will be described later, this does not apply if the authentication failure is due to a specific reason.

[0088] The timing at which the wireless authentication unit F31 performs the wireless authentication process may be, for example, the timing at which a communication connection is established between the BLE communication device 7 and the portable device 2. The wireless authentication unit F31 may be configured to perform the wireless authentication process at a predetermined cycle while the BLE communication device 7 and the portable device 2 are connected for communication.

[0089] The smart ECU 4 also performs communication for wireless authentication processing when an operation to lock the vehicle Hv (hereinafter referred to as a locking operation) is performed. A locking operation refers to the act of touching the locking / unlocking sensor 5 with the driving power turned off and all doors leading to the cabin closed. Receiving a locking instruction signal from the portable device 2 also corresponds to an operation to lock the vehicle Hv. The smart ECU 4 locks all doors of the vehicle Hv based on the reception of the locking operation.

[0090] The smart ECU 4 accepts touches of the locking / unlocking sensor 5 as locking and unlocking operations on the condition that it has confirmed that an authenticated portable device 2 is present in the locking / unlocking area. The locking / unlocking area is an area outside the vehicle compartment where the in-vehicle system locks / unlocks the doors, and is an area within a predetermined distance (e.g., 1.5 m) from each door. An authenticated portable device 2 is a portable device 2 for which wireless authentication processing has been successful.

[0091] Furthermore, when the trunk door is closed while the vehicle Hv is locked and only the trunk door is open, the smart ECU 4 performs wireless authentication processing on the communication partner present in the trunk. A state in which the vehicle Hv is locked refers to a state in which the lock mechanisms of all doors equipped in the vehicle Hv are set to a locked state. Note that the trunk door lock mechanism is configured to be set to a locked state even when the trunk door is open. If the trunk door is closed after the lock mechanisms of all doors are set to a locked state while the trunk door is open, the trunk door latch is fixed and the trunk door cannot be opened.

[0092] The state in which the vehicle Hv is locked can include a door-close standby state. The door-close standby state is a state in which locking is completed as soon as the door that is open at the time the locking operation is accepted is closed. The door-close standby state also includes, for example, a trunk-close standby state in which the locking mechanisms of all doors are set to a locked state but only the trunk door is open, as described above. The door-close standby state can also include a state in which locking of the vehicle Hv is reserved using a reservation lock function. The reservation lock function accepts a locking operation when the doors are open and locks all doors when all doors are closed. In this way, the door-close standby state corresponds to a state in which the user's locking operation has been accepted.

[0093] In addition, the wireless authentication unit F31 can perform communication for wireless authentication processing when triggered by, for example, the start switch 6 being pressed or the user touching the lock / unlock sensor 5 while the vehicle Hv is locked.

[0094] The position determination unit F32 determines the device position based on the reception status of the device signal at each BLE communication device 7. For example, the position determination unit F32 identifies the position coordinates relative to the vehicle Hv by combining the distance measurements from multiple BLE communication devices 7 and the installation position of each BLE communication device 7 in the vehicle Hv. Since the installation position of each BLE communication device 7 is known, if the distances from three or more BLE communication devices 7 to the portable device 2 can be obtained, the position coordinates of the portable device 2 can be calculated using the principles of triangulation or trilateration. The position coordinates of the portable device 2 can be expressed in a vehicle coordinate system, for example.

[0095] The position determination unit F32 determines whether the portable device 2 is present in the trunk based on the specified device position coordinates, and whether the portable device 2 is present in a trunk locking / unlocking area. The trunk locking / unlocking area is an area formed around the trunk door handle, and is an area outside the vehicle within a predetermined distance (e.g., 1.5 m) from the trunk door handle.

[0096] In addition, the location determination unit F32 is configured not to perform location determination for unregistered devices in order to reduce the processing load. Furthermore, the location determination unit F32 may perform location determination only for registered devices that are connected for communication or that can receive BLE signals. The more the number of devices for which location determination is performed is narrowed, the more the processing load on the processor 41 can be reduced and power can be saved.

[0097] When the wireless authentication process of the portable device 2 fails, the failure reason identification unit F33 identifies the reason for the authentication failure based on the data received from the portable device 2. Reasons for authentication failure include a mismatch between the response code and the verification code, which will be described later, and not receiving a response from the portable device 2. Reasons for the wireless authentication process failing despite the device being registered include an unauthenticated user, an abandoned state, and an expired authentication key. Unauthenticated user, an abandoned state, and an expired authentication key will be described separately below. Unauthenticated user, an abandoned state, and an expired authentication key correspond to the identified reasons. Other reasons include a mismatch between the response code and the verification code, and not receiving a response from the portable device 2.

[0098] The response processing unit F4 responds to user operations on the vehicle Hv and cooperates with other ECUs to execute control / processing according to the device location identified by the device location confirmation unit F3. For example, the response processing unit F4 executes a locked-in warning process and a remaining device invalidation process. The locked-in warning process is a vehicle control that outputs a predetermined warning sound or the like when it detects that a key device remains in the trunk when a locking operation is received. When the conditions for executing the locked-in warning process are met, the response processing unit F4 sends a signal to the notification ECU 15 requesting the output of a warning sound or the like.

[0099] The residual device disable process is a vehicle control that disables a key device left inside the vehicle when an operation to lock the vehicle Hv is accepted. Disabling means temporarily preventing the device from functioning as a key for locking and unlocking the vehicle Hv. Disabling can be achieved by excluding the device from communication partners or by setting it as an exception to the wireless authentication process. Details of the locked-in warning process and the residual device disable process will be described separately later.

[0100] Additionally, when the device location confirmation unit F3 determines that the portable device 2 is present in the locking / unlocking area and detects that the locking / unlocking sensor 5 has been touched by the user, the response processing unit F4 cooperates with the body ECU 12 to lock or unlock the doors. When the device location confirmation unit F3 determines that the portable device 2 is present in the cabin and detects that the start switch 6 has been pressed by the user, the response processing unit F4 cooperates with the power supply ECU 11 to switch the driving power supply from off to on.

[0101] In this embodiment, the response processing unit F4 cooperates with other ECUs to notify the user of warnings and other notifications, lock and unlock the vehicle, and turn on and off the driving power supply, but this is not limiting. The smart ECU 4 serving as the response processing unit F4 may be configured to directly control electrical equipment related to user notifications, locking and unlocking, etc. Outputting a control signal to another ECU for executing a certain vehicle control is also included in executing the vehicle control.

[0102] <About wireless authentication processing> Here, a process sequence in which the smart ECU 4 authenticates the portable device 2 as a communication partner will be described. The wireless authentication process of the portable device 2 by the smart ECU 4 includes steps S11 to S18, as shown in Fig. 8, for example. The wireless authentication process is executed on the premise that an encrypted BLE communication link between the portable device 2 and the smart ECU 4 has been established.

[0103] The fact that a BLE communication link has been established indicates that the communication partner is the paired portable device 2. If the authentication for communication connection is considered to be the first stage of authentication processing, which is the primary authentication processing, then the wireless authentication processing corresponds to the second stage of authentication processing, which is the secondary authentication processing.

[0104] Step S11 is a step in which the smart ECU 4 transmits a challenge code to the portable device 2. The challenge code is, for example, a random number of a predetermined length generated using a random number table prepared in advance. The challenge code may be a random number generated using time information (so-called system time) provided in the smart ECU 4 as a seed. The challenge code can be determined by various methods.

[0105] In step S12, the portable device 2 generates a response code by combining an arbitrary one-time authentication key stored in the device information storage unit DvM with the received challenge code in a predetermined manner. The used one-time authentication key is discarded as needed. In step S13, the portable device 2 returns the response code generated in step S12 and the variable code corresponding to the one-time authentication key used to generate the response code to the smart ECU 4, either together or separately.

[0106] In step S14, the smart ECU 4 generates a one-time authentication key using the variable code received from the portable device 2 and the service key corresponding to the communication partner, which is stored in the device information storage unit DvM. Here, the combination of the service key and variable code used by the smart ECU 4 to generate the one-time authentication key is the same as the materials used to generate the one-time authentication key used to generate the response code. Therefore, the one-time authentication key generated by the smart ECU 4 in step S14 is the same as the one-time authentication key used by the portable device 2 to generate the response code. Step S14 corresponds to a process of restoring the one-time authentication key used by the portable device 2 to generate the response code, based on the variable code received from the portable device 2 and the service key of the portable device 2 that the smart ECU 4 holds.

[0107] In step S15, the smart ECU 4 generates a verification code based on the one-time authentication key generated in step S14 and the challenge code transmitted in step S11. The method for generating the verification code is the same as that for generating the response code. If the communication partner is a portable device 2 that holds a service key registered in the device information storage unit DvM, the verification code and the response code are expected to match. On the other hand, if the communication partner is an unregistered device, either no response code is returned or the response code and the verification code do not match. Therefore, the response code generated / received in the above steps functions as information for verifying the legitimacy of the communication partner.

[0108] In step S16, the smart ECU 4 compares the verification code generated in step S15 with the response code received from the portable device 2 to determine the legitimacy of the communication partner. That is, if the two codes match, it determines that authentication is successful (step S17). On the other hand, if the two codes do not match, it determines that authentication is unsuccessful (step S18). Note that if a response code is not returned even after a predetermined response waiting time has elapsed since the transmission of the challenge code, the smart ECU 4 may determine that authentication is unsuccessful. Furthermore, the smart ECU 4 of the present disclosure also determines that authentication is unsuccessful when it receives an authentication impossible signal (described later) from the portable device 2 instead of a response code.

[0109] According to the above configuration, the portable device 2 and the user are authenticated using a one-time authentication key generated based on a service key unique to each portable device 2. Therefore, security can be improved compared to a configuration in which fixed key information is used to authenticate the portable terminal. Furthermore, according to the above method, the information exchanged between the smart ECU 4 and the portable device 2 when generating a response code is a variable code and a challenge code. During authentication, the one-time authentication key itself is not transmitted or received between the authentication ECU and the portable terminal. Furthermore, the one-time authentication key used for authentication is changed every time. Therefore, according to the above method, it is possible to reduce the risk that a third party will fraudulently succeed in wireless authentication processing. Here, the third party refers to a person who is not the user of the vehicle Hv.

[0110] The above authentication sequence is merely an example and is not limiting. The operation of each device may be designed so that the portable device 2 and the smart ECU 4 use the same one-time authentication key to generate a response code / verification code. For example, the smart ECU 4 and the portable device 2 may be configured to notify each other of the numbers of the one-time authentication keys used in the wireless authentication process, assuming that they share multiple one-time authentication keys.

[0111] <Device response processing> Here, the operation of the portable device 2 when a challenge code is received will be described as device response processing with reference to FIG. 9. When the portable device 2 receives a challenge code from the vehicle Hv, it determines whether the vehicle is in a user authenticated state (S21). If the portable device 2 is not in a user authenticated state, i.e., if the user is not logged in to the digital key application 204 (NO in S21), the portable device 2 returns a user unauthenticated signal to the vehicle Hv (S22). The user unauthenticated signal is a BLE signal that includes a code indicating that the vehicle is not in a user authenticated state. The user unauthenticated signal is a response signal indicating that the portable device 2 cannot respond to the wireless authentication processing, specifically, that it will not return a response code.

[0112] Furthermore, if the portable device 2 is in the user authentication state (S21 YES), it determines whether the current state of the portable device 2 corresponds to the abandoned state based on the signal from the acceleration sensor 23 (S23). If the current state of the portable device 2 corresponds to the abandoned state (S23 YES), it returns a no-motion signal to the vehicle Hv (S24). The no-motion signal is a BLE signal including a code indicating that the portable device 2 is in the abandoned state. The no-motion signal is a response signal indicating that it cannot respond to the wireless authentication process, specifically, that it will not return a response code.

[0113] If the portable device 2 is not in an abandoned state (S23 NO), the portable device 2 determines whether or not 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 portable device 2 generates a response code using any one of the remaining one-time authentication keys (S26) and returns it to the vehicle Hv (S27). Steps S26 to S27 are a sequence corresponding to steps S12 to S13 in FIG. 8.

[0114] On the other hand, if no one-time authentication keys remain in the key information storage unit KyM, an authentication key out-of-date signal is returned to the vehicle Hv (S28). The authentication key out-of-date signal is a BLE signal including a code indicating an authentication key out-of-date state in which the one-time authentication keys have run out. The authentication key out-of-date signal is a response signal indicating that a response cannot be made to the wireless authentication process, specifically, that a response code will not be returned.

[0115] As described above, when the portable device 2 receives a challenge code, it responds according to whether the user has been authenticated, whether the portable device 2 is in an unattended state, and whether the portable device 2 holds a one-time authentication key. In the present disclosure, the unauthenticated user signal, the no-motion signal, and the expired authentication key signal are collectively referred to as authentication failure signals. When the smart ECU 4 receives an unauthenticated user signal or other such signal, it determines that the authentication has failed (is unsuccessful). Furthermore, when the smart ECU 4 receives an unauthenticated user signal from the communication partner, it determines that the authentication failure is due to the unauthenticated user. When the smart ECU 4 receives a no-motion signal from the communication partner, it determines that the authentication failure is due to the unattended state. When the smart ECU 4 receives an expired authentication signal, it determines that the authentication failure is due to the expired authentication key.

[0116] The portable device 2 may transmit the authentication impossible signal not only when receiving the challenge code but also before receiving the challenge code, for example, when the BLE communication link is established. The device control unit 20 may transmit the authentication impossible signal in response to a response request signal from the smart ECU 4, or may transmit the authentication impossible signal voluntarily at any timing after the BLE communication link is established. The timing of transmitting the authentication impossible signal can be changed as appropriate.

[0117] Furthermore, after transmitting the authentication impossible signal, if the reason for authentication impossible is resolved, the device control unit 20 may transmit a ready signal to the smart ECU 4 indicating that wireless authentication processing is now possible. The reason for authentication impossible refers to a one-time authentication key expiring, an abandoned state, an unauthenticated user, etc. When the smart ECU 4 receives the ready signal, it may transmit a challenge code to the sender of the ready signal and execute wireless authentication processing.

[0118] <Regarding the trapped warning process> Here, the trapped-in warning process executed by the smart ECU 4 will be described with reference to the flowchart shown in Fig. 10. The trapped-in warning process is triggered by the trunk door being closed in a door-closing standby state, for example, a trunk-closed standby state. The trapped-in warning process includes, for example, steps S101 to S108.

[0119] Step S101 is a trunk search process in which the device location confirmation unit F3 determines whether or not the portable device 2 is present in the trunk. For example, each BLE communicator 7 performs distance measurement communication with the portable device 2 to identify the device location coordinates, and determines whether or not the portable device 2 is present in the trunk. This search process can be executed for the portable device 2 that has already been paired with the smart ECU 4. Step S101 corresponds to the location determination process.

[0120] If the portable device 2 is not found in the trunk as a result of the trunk search process in step S101 (NO in S102), the smart ECU 4 determines that there is no portable device 2 locked in the trunk, and completes the locking process (S103). In this case, no special control such as a warning process is performed. The state in which the locking process is completed means that all doors, including the trunk door, are closed and locked.

[0121] On the other hand, if it is determined that a registered device is present in the trunk (YES in S102), the smart ECU 4 executes wireless authentication processing for the device in the trunk (S104). The device in the trunk refers to the portable device 2 present in the trunk.

[0122] If the wireless authentication process for the in-trunk device is successful (YES in S105), the smart ECU 4 performs a lock-in recording process (S107). The lock-in recording process is a process for retaining the presence of a portable device 2 locked in the trunk as an internal state. The lock-in recording process includes, for example, setting a trunk lock-in flag to ON and storing the device ID of the in-trunk device as locked-in device information in the storage 43 or the like. The trunk lock-in flag is a flag indicating whether a locked-in device exists. The locked-in device refers to the portable device 2 locked in the trunk.

[0123] Furthermore, if the wireless authentication process of the in-trunk device fails (NO in S105), the smart ECU 4 of this embodiment identifies the reason for the authentication failure based on the received data of the device, and then determines whether the reason for the authentication failure corresponds to any of the following reasons: unauthenticated user, abandoned state, and expired authentication key (S106).

[0124] If the authentication failure is due to unauthenticated user, abandoned state, or expired authentication key (YES in S106), the smart ECU 4 determines that the portable device 2 is present in the trunk and performs the locked-in recording process (S107) as if the wireless authentication process was successful. On the other hand, if the wireless authentication process of the device in the trunk fails for any other reason (NO in S106), the smart ECU 4 transitions to the normal locked state.

[0125] When the smart ECU 4 detects that the portable device 2 has been locked in the trunk, it executes a warning process in cooperation with the notification ECU 15 (S108). The warning process includes, for example, at least one of outputting a predetermined warning sound from the horn 17 and displaying a warning message on the in-vehicle display 16. By executing the warning process, the user can recognize that he or she has accidentally placed the portable device 2 in the trunk.

[0126] Next, the trunk unlocking process will be described with reference to the flowchart shown in Fig. 11. The trunk unlocking process is a control process for unlocking the trunk door. The trunk unlocking process is performed when the user touches the locking / unlocking sensor 5 provided on the trunk door when the vehicle Hv is locked. The trunk unlocking process shown in Fig. 11 can be performed as a process subsequent to step S103 or step S108 in Fig. 10.

[0127] Step S201 is a step of referring to records in the storage 43 or the like to determine whether or not a locking device is present. If it is recorded that a locking device is present (S201 YES), the smart ECU 4 sequentially / simultaneously executes trunk outside confirmation processing and trunk inside confirmation processing (S202-S203). The trunk outside confirmation processing is processing of determining whether or not the portable device 2 is present in the trunk locking / unlocking area, and includes device position determination processing and wireless authentication processing. The trunk inside confirmation processing is processing of determining whether or not the portable device 2 is present in the trunk, and includes position determination processing and wireless authentication processing. The trunk inside confirmation processing as step S203 corresponds to the open-time confirmation processing.

[0128] Step S204 is a step for determining whether the portable device 2 has been found in the trunk or in the trunk locking / unlocking area as a result of steps S202 and S203. The case where the portable device 2 has been found corresponds not only to the portable device 2 being present but also to the case where the wireless authentication process for the portable device 2 has been successful. If the portable device 2 has been found in the trunk or in the trunk locking / unlocking area, the trunk door is unlocked (S220).

[0129] If the smart ECU 4 cannot find the portable device 2 in the trunk or in the trunk locking / unlocking area, it determines whether or not a portable device 2 for which the wireless authentication process has failed for a specific reason is present in the trunk or in the trunk locking / unlocking area (S205). If a portable device 2 for which the wireless authentication process has failed for a specific reason is present in the trunk or in the trunk locking / unlocking area (S205 YES), the smart ECU 4 unlocks the trunk door (S220).

[0130] If no authorized device is found in the trunk or in the trunk locking / unlocking area, and no portable device 2 for which wireless authentication processing has failed for a specific reason exists (NO in S205), the smart ECU 4 keeps the trunk door locked (S221). An authorized device is a portable device 2 for which wireless authentication has been successful. Furthermore, if no locked-in device exists (S201), the smart ECU 4 performs only the trunk exterior confirmation processing without performing the trunk interior confirmation processing (S210). If an authorized device is found in the trunk locking / unlocking area, the smart ECU 4 unlocks the trunk door (S220).

[0131] According to the above configuration, even if the user accidentally closes the trunk door with the portable device 2 still in the trunk while the trunk is waiting to be closed, or if the wireless authentication fails due to a specific reason such as an expired authentication key, the user can still unlock the trunk. According to the trunk unlocking process shown in FIG. 11 , if the portable device 2 is locked in the trunk, in principle, anyone other than the user could open the trunk door by touching the trunk lock / unlock sensor 5. However, in the above case, the lock-in warning process is executed as soon as the trunk door is closed. Therefore, if the portable device 2 is locked in the trunk, the user must perform the above-described trunk unlocking operation before leaving the vehicle Hv. In other words, the trunk unlocking process shown in FIG. 11 is actually operated so that only the user can unlock the trunk door.

[0132] <About the process to disable residual devices> Here, the residual device invalidation process will be described using the flowchart shown in FIG. 12. The residual device invalidation process is a process for invalidating the portable device 2 left in the trunk when a locking operation is received. The smart ECU 4 performs the residual device invalidation process when a locking operation is received with the driving power on and all doors closed. Specifically, a case where a locking operation is received refers to a case where a locking instruction signal is received. In addition, a case where the locking / unlocking sensor 5 is pressed in a situation where it has been confirmed that a legitimate device is present in the locking / unlocking area can also be included as a case where a locking operation is received.

[0133] The locked-in warning process described above is a process that responds to a case where a user accidentally locks the portable device 2 inside the vehicle (in the trunk), whereas the remaining device invalidation process is a process that responds to a case where a user intentionally locks the portable device 2 inside the trunk. In terms of execution conditions, the locked-in warning process is triggered by closing the door after a locking operation, whereas the remaining device invalidation process is triggered by receiving a locking operation, which can be a difference. The remaining device invalidation process includes, as an example, steps S301 to S306.

[0134] In step S301, similar to step S101, the device location confirmation unit F3 determines whether the portable device 2 is present in the trunk. If the portable device 2 is found in the trunk (YES in S302), the smart ECU 4 performs wireless authentication processing for the device in the trunk (S303). If the portable device 2 is not found in the trunk (NO in S302), this flow ends.

[0135] If the wireless authentication process for the in-trunk device is successful (YES in S304), the smart ECU 4 disables the in-trunk device (S306). Specifically, the smart ECU 4 stores data in the storage 43 or the like indicating that the in-trunk device cannot be used to unlock the vehicle.

[0136] If the wireless authentication process of the in-trunk device fails (NO in S304), the smart ECU 4 identifies the reason based on the received data of the device, and determines whether the reason for the authentication failure corresponds to any of the following reasons: unauthenticated user, abandoned state, or expired authentication key (S305).

[0137] If the authentication failure reason is any one of unauthenticated user, abandoned state, and expired authentication key (YES in S305), the smart ECU 4 determines that the portable device 2 is present in the trunk as a legitimate device and disables the in-trunk device (S306). In other words, if the authentication failure reason corresponds to a specific reason, the smart ECU 4 performs the same process as when the wireless authentication process is successful. On the other hand, if the wireless authentication process of the in-trunk device fails for other reasons (NO in S305), the smart ECU 4 ends this flow without disabling the in-trunk device.

[0138] According to the above configuration, the portable device 2 placed in the trunk by the user before the locking operation is disabled, so even if the trunk interior confirmation process is executed triggered by touching the trunk lock / unlock sensor 5, the wireless authentication process will not be successful. This prevents a third party from unlocking the trunk illicitly. Furthermore, since the remaining device disable process is executed triggered by the locking operation with all doors closed, it is assumed that the user has a portable device 2 other than the locking-in device. In other words, even if the locking-in device is disabled, the user can still unlock the vehicle Hv without any problems using the other portable device 2.

[0139] <Summary of Smart ECU4 operation and effects> In a typical PEPS system, successful wireless authentication processing is a prerequisite for vehicle control according to the location of the portable device 2. However, as the execution conditions and authentication methods for the wireless authentication processing become more complex and stricter, the possibility of the portable device 2 being deemed not to be in the trunk increases, even when it is actually in the trunk. As a result, there may be an increased number of cases where control according to the device's location does not work. Similar issues can arise even if, for the sake of security, the system is configured not to return a response code when the portable device 2 is left unattended.

[0140] To address this issue, the configuration of this embodiment allows the portable device 2 to be considered to be in the trunk even if the wireless authentication process of the communication partner fails due to a specific reason, provided that the communication partner is a registered device. As a result, it is possible to reduce the risk of failure to disable the locked-in device or of the locked-in warning process becoming inoperative.

[0141] A comparative configuration is possible in which a communication partner that fails wireless authentication processing is considered to be an unauthorized device, regardless of the reason for the authentication failure. In such a comparative configuration, if authentication of the trunk-mounted device fails, the smart ECU 4 cannot recognize the presence of the portable device 2 in the trunk. As a result, the portable device 2 is locked in the trunk against the user's intention. Furthermore, in the comparative configuration, it is not possible to disable the portable device 2 that failed authentication and was intentionally left in the trunk.

[0142] Incidentally, the reason for failure due to the authentication key expiring may be resolved over time by obtaining a one-time authentication key from the DKS 3. Therefore, the portable device 2 left in the trunk may obtain a one-time authentication key from the DKS 3 over time and return to an authentication-enabled state. If a non-revoked portable device 2 left in the trunk returns to an authentication-enabled state, a third party may be able to unlock the trunk. According to this embodiment, the problems of the above-described comparative configuration can be alleviated / resolved.

[0143] An example of a case in which authentication of a device in the trunk fails due to an authentication key expiration is when a portable device 2 whose one-time authentication key has been used up in the wireless authentication process for locking is placed in the trunk and the trunk door is closed. The portable device 2 is supposed to replenish one-time authentication keys from the DKS 3 before the remaining number of one-time authentication keys reaches one. However, depending on the communication environment, the communication settings of the portable device 2, maintenance of the DKS 3, and the like, it may not be possible to replenish the one-time authentication key in time. An example of a case in which authentication of a portable device 2 fails due to an abandoned state is when the trunk door is closed after the portable device 2 has been left in the trunk for an abandoned state determination time. If a user locks the trunk and places the portable device 2 in the trunk, and then the abandoned state determination time elapses while the user is organizing luggage or talking to a passenger, authentication failure due to the abandoned state may occur. The user authentication state may also be released naturally over time. According to the configuration of the present disclosure, it is possible to reduce the risk of the locked-in warning or the remaining device disablement not working in the above case, which is not frequent but can occur.

[0144] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments, and various modifications described below are also included within the technical scope of the present disclosure. Furthermore, various modifications other than those described below can be implemented without departing from the gist of the present disclosure. For example, the various supplements and modifications described below can be implemented in appropriate combinations as long as no technical contradictions arise. Note that components having the same functions as the components described above are given the same reference numerals, and their description may be omitted. Furthermore, when only a portion of the configuration is mentioned, the above description can be applied to the other portions.

[0145] <About trunk check processing> In the above trunk unlocking process, the trunk in - vehicle confirmation process is carried out with the touch of the trunk locking / unlocking sensor 5 as a trigger only when the smart ECU 4 recognizes that the portable device 2 is confined in the trunk, but it is not limited to this. When the trunk locking / unlocking sensor 5 is touched, both the trunk in - vehicle confirmation process and the trunk out - of - vehicle confirmation process may be carried out regardless of whether there is confinement. In that case, the disabled portable device 2 can be ignored. The disabled portable device 2 can be enabled when the vehicle Hv is unlocked using another portable device 2.

[0146] <Mounting position of the BLE communication device> The number and arrangement mode of the above-described BLE communication devices 7 are just examples and can be appropriately changed. The BLE communication device 7a and the BLE communication device 7b may be arranged on the outer surface of the B - pillar or the C - pillar. Note that the vehicle Hv can be divided into a door - side B - pillar provided in the door module and a vehicle - body - side B - pillar as a pillar / frame provided in the roof part of the vehicle body. The door - side B - pillar corresponds to the part that abuts on the vehicle - body - side pillar in the front - seat door or the rear - seat door. The outdoor unit can adopt the part adjacent to the side window in the door - side B - pillar, that is, the part above the lower end of the side window. Also, the outdoor unit may be arranged on the outer surface of the vehicle - outer - side B - pillar.

[0147] The BLE communication device 7p may be arranged near the shift lever, near the start switch 6, the center console, the foot area of the driver's seat, etc. The BLE communication device 7p may be arranged on the inner surface of the door for the driver's seat, for example, in the door pocket or at the base of the driver's - side B - pillar. Also, there may be multiple indoor units. For example, the in - vehicle system 1 may include a BLE communication device 7 arranged on the inner surface of the right - hand door and a BLE communication device 7 arranged on the inner surface of the left - hand door. The in - vehicle system 1 may include a trunk - in communication device 7t, which is a BLE communication device 7 arranged in the trunk as shown in FIG. 13.

[0148] <Regarding the method for determining the device position> Whether or not the portable device 2 is present in the trunk may be determined based on the reception strength of the trunk communication unit 7t from the portable device 2. For example, the position determination unit F32 may determine that the portable device 2 is present in the trunk based on the reception strength of the trunk communication unit 7t from the portable device 2 being equal to or greater than a predetermined value. Similarly, the position determination unit F32 may determine that the portable device 2 is present in the cabin based on the reception strength of the indoor unit being equal to or greater than a predetermined value.

[0149] <Variations in the space targeted for confinement warning / invalidation> As shown in FIG. 14 , in addition to the trunk interior space CSt, the vehicle Hv may also have a charging inlet storage section CSc and a front storage section CSb located inside the hood as closed spaces independent of the cabin (Cbn). The trunk interior space CSt is the space inside the trunk, and the charging inlet storage section CSc is the space inside the charging lid. The independent space CS to which the trapped-in warning process of the portable device 2 is applied may be the charging inlet storage section CSc or the front storage section CSb. The charging lid is a lid that covers an opening where a connector to be connected to a charging plug / cable is disposed, and is also called a charging port lid.

[0150] Although the above describes the operation when the portable device 2 is left in the trunk, the above configuration can also be applied to the case when the portable device 2 is left in the cabin. Even when a portable device 2 for which wireless authentication has failed for a specific reason is present in the cabin, the smart ECU 4 may issue a locked-in warning, disable the portable device, etc., in the same way as when a device for which wireless authentication processing has succeeded is present in the cabin. The interior of the vehicle includes the trunk, the charging inlet storage area, the front storage area, etc. in addition to the cabin.

[0151] <About the issuing device for one-time authentication keys> In the above-described embodiment, the DKS 3 generates a one-time authentication key and distributes it to the portable device 2, but this is not limiting. The smart ECU 4 may generate and distribute the one-time authentication key on the condition that the wireless authentication process is successful. The DKS 3 is an optional element and can be omitted. The DKS 3 and the smart ECU 4 correspond to issuing terminals.

[0152] <Other> The smart ECU 4 may execute both or either one of the following controls as if authentication were successful, provided that the authentication failure reason is a specific reason: issuing a locked-in warning and disabling the remaining device. It is preferable that the smart ECU 4 not execute the control to unlock the door leading to the cabin if authentication of the portable device 2 present in the locking / unlocking area fails, regardless of the reason for the failure. It is also preferable that the smart ECU 4 not execute the control to switch the running power from off to on if authentication of the portable device 2 present in the vehicle is not successful, regardless of the reason for the authentication failure. It may also be configured to execute the control to lock the vehicle Hv even if authentication is unsuccessful, provided that the authentication failure reason is a specific reason, the communication partner is a registered device, and the communication partner is present in the locking / unlocking area. This configuration can improve user convenience while reducing the risk of the vehicle Hv being used by a third party.

[0153] <Additional remarks> The apparatus, system, and method described herein may be implemented by a special-purpose computer including a processor programmed to execute one or more functions embodied in a computer program. The apparatus and method described herein may be implemented using dedicated hardware logic circuits. The apparatus and method described herein may be implemented by one or more special-purpose computers configured by a combination of a processor executing a computer program and one or more hardware logic circuits. For example, some or all of the functions of the smart ECU 4 may be implemented in hardware. Implementations of certain functions in hardware include implementations using one or more integrated circuits (ICs). Examples of processors (computation cores) include CPUs, MPUs, GPUs, and data flow processors (DFPs). Some of the functions of the smart ECU 4 may be implemented using a system-on-chip (SoC), an integrated circuit (IC), or a field-programmable gate array (FPGA). The concept of an IC also includes an application-specific integrated circuit (ASIC).

[0154] The computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. Examples of storage media for the program include a hard-disk drive (HDD), a solid-state drive (SSD), and flash memory. The scope of the present disclosure also includes a program for causing a computer to function as the smart ECU 4, and a non-transitory tangible storage medium such as a semiconductor memory on which the program is stored. [Explanation of symbols]

[0155] 1 In-vehicle system, 2 Portable device, 4 Smart ECU (vehicle control device), 7 BLE communication device, 41 Processor, F1 Vehicle information acquisition unit, F2 Communication control unit, F3 Device location confirmation unit, F4 Response processing unit, F31 Wireless authentication unit, F32 Location determination unit, F33 Failure reason identification unit, F311 Temporary key generation unit, CSt Trunk interior space, CSb Front storage unit, CSc Charging inlet storage unit, CS Independent space unit

Claims

1. A vehicle control device that determines the location of a key device, which is a portable device that is pre-registered as a key for a vehicle, by wirelessly communicating with the key device, a device location confirmation unit (F3) that performs a wireless authentication process to determine whether or not a communication partner is the key device based on data transmitted from the communication partner, and a location determination process to determine whether or not the communication partner is present inside the vehicle based on a reception status of a signal from the communication partner; a failure reason identification unit (F33) that, when the device location confirmation unit does not determine that the communication counterpart is the key device in the wireless authentication process, identifies an authentication failure reason that is the reason why the communication counterpart was not determined to be the key device based on the data received from the communication counterpart, A vehicle control device configured such that, even if the device location confirmation unit cannot determine that the communication partner is the key device, if the reason for the authentication failure is a specific reason and the location of the communication partner is determined to be inside the vehicle, the device location confirmation unit considers the key device to be present inside the vehicle.

2. The vehicle control device according to claim 1, The device location confirmation unit Based on the reception status of a signal from the communication partner, it is determined whether the communication partner is present in an independent space section (CS), which is a closed space provided in the vehicle independent from the cabin, A vehicle control device that is configured to consider the key device to be present in the independent space section even if it cannot be determined that the communication partner is the key device, if the reason for the authentication failure is the specific reason and it is determined that the communication partner is present in the independent space section.

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

4. The vehicle control device according to claim 3, The device location confirmation unit is a vehicle control device that checks whether the key device is present in the trunk when the trunk door is closed after the vehicle is set to a locked state with only the trunk door open.

5. 5. A vehicle control device for preventing the key device from being locked in the trunk according to claim 4, comprising: a response processing unit (F4) that, when the device location confirmation unit determines that the key device is present in the trunk when the trunk door is closed, performs processing to warn that the key device is present in the trunk; When a user operation to open the trunk door is detected after the warning, the device location confirmation unit performs an opening confirmation process to confirm whether the key device is present in the trunk; The response processing unit is a vehicle control device that performs processing to switch the trunk lock mechanism to an unlocked state when the open confirmation processing determines that the key device is present in the trunk.

6. 6. The vehicle control device according to claim 3, wherein a plurality of the key devices can be registered, The device location confirmation unit is configured to determine whether the key device is present in the trunk when it receives a user operation to lock the vehicle while all doors are closed.

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

8. The vehicle control device according to any one of claims 1 to 7, The wireless authentication process includes: transmitting a challenge code to the communication partner; the communication partner generates a response code in response to the challenge code using a disposable one-time authentication key generated by a predetermined issuing terminal, and transmits the response code to the vehicle; the key device is configured to, when it does not have the one-time authentication key, return an authentication key expiration signal indicating that the one-time authentication key has expired; When the authentication key expiration signal is received, the device location confirmation unit does not determine that the communication partner is the key device, the failure reason identification unit determines that the authentication failure reason is an authentication key expiration based on the reception of the authentication key expiration signal, A vehicle control device in which the authentication key expiration is set to the specific reason.

9. The vehicle control device according to any one of claims 1 to 8, the key device is configured to, when the stationary state continues for a predetermined time, return a no-motion signal indicating that the key device has not moved for a predetermined time in response to a response request signal from the vehicle; When the device location confirmation unit receives the no-motion signal, it does not determine that the communication partner is the key device, the failure reason identification unit determines that the authentication failure reason is no motion based on the reception of the no motion signal; A vehicle control device in which the no-motion is set to the specific reason.

10. The vehicle control device according to any one of claims 1 to 9, the key device has a user authentication function that determines the legitimacy of a user using biometric information or a password, and is configured to return a user unauthenticated signal indicating that the user authentication has not been successful in response to a response request signal from the vehicle if the user authentication has not been successful; When the device location confirmation unit receives the user unauthenticated signal, the device location confirmation unit does not determine that the communication partner is the key device, the failure reason identification unit determines that the authentication failure reason is user unauthentication based on the reception of the user unauthenticated signal; A vehicle control device in which the specific reason is set to "unauthenticated user."

11. The vehicle control device according to claim 2, The vehicle control device, wherein the independent space portion is an inner space of a charging lid or an inner space of a hood.

12. The vehicle control device according to any one of claims 1 to 11, The device location confirmation unit acquires a device ID of the communication partner, and executes the location determination process and the wireless authentication process on the condition that the device ID is registered as the key device; A vehicle control device that considers the key device corresponding to the device ID of the communication partner to be present inside the vehicle even if the wireless authentication process fails, provided that the device ID is registered as the key device, the reason for the authentication failure is the specific reason, and the location of the communication partner is determined to be inside the vehicle.

13. 1. A vehicle control method implemented by at least one processor, comprising: determining a location of a key device by wirelessly communicating with the key device, the key device being a portable device that has been pre-registered as a key for the vehicle; determining whether a communication partner is present inside the vehicle based on a reception status of a wireless signal transmitted from the communication partner; a step of determining whether the communication partner is the key device based on data transmitted from the communication partner; a step of identifying a reason for authentication failure that is the reason why the communication counterpart was not determined to be the key device based on the content of the received data, if the communication counterpart was not determined to be the key device; A vehicle control method including a step of determining that the key device is present in the vehicle even if the communication partner is not determined to be the key device, if the reason for the authentication failure is a specific reason and the communication partner is determined to be present in the vehicle.

Images