Lock control device

Abstract

To provide a lock control device and a vehicle digital key system that are capable of reducing power consumption during standby.SOLUTION: A vehicle digital key system Sys includes a mobile device 1, an in-vehicle system 2, and a DKS (digital key server) 3. The in-vehicle system includes a certification ECU. The DKS, based on receipt of a code issuance request from the mobile device, sends a verification package to the certification ECU in a vehicle Hv specifying an authentication method for each authentication step that constitutes multi-step authentication to the certification ECU. The authentication ECU receives a data set from the DKS by setting a cellular communication function during standby (while parking) and constantly / intermittently, and if the verification package included in the data set is received, an authentication sensor used for the first authentication step indicated in the package is made effective, and if the verification package is not received, each authentication sensor is set to a power-saving state.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to a technology for performing unlocking / locking on the condition that the user is authenticated.

Background Art

[0002] Patent Documents 1-2 disclose a configuration including a plurality of types of authentication devices in an in-vehicle system that unlocks a vehicle on the condition that the user has been authenticated.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] A vehicle may be equipped with various authentication sensors for authenticating a user. For example, a vehicle may be equipped with a communication device for receiving an authentication code transmitted from a user's mobile device, a camera, a microphone, a fingerprint reader, a vein sensor, etc. as authentication sensors. In a configuration where a vehicle is equipped with a plurality of authentication sensors, if all the plurality of authentication sensors are driven during standby, the power consumption may increase.

[0005] Place Place The present disclosure has been made based on the above considerations or points of view, and one of its purposes is to provide a lock control device capable of reducing power consumption during standby.

Means for Solving the Problems

[0006] The lock control device disclosed herein is used in connection with a first authentication sensor that acquires information for authenticating a user in a predetermined manner, and a second authentication sensor that acquires information for authenticating a user in a manner different from that of the first authentication sensor. It is also used in conjunction with a communication unit (51) for wireless connection to a wide-area communication network. A lock control device comprising: an abnormality detection unit (G2) for detecting an abnormality in the first authentication sensor; and a control unit (G1) for controlling the operation of the first authentication sensor and the second authentication sensor; A communication control unit (G3) controls the operation of the communication unit and determines whether the communication unit is in a state where it can connect to a wide-area communication network based on the signal reception status of the communication unit. The control unit is configured to not activate the second authentication sensor until at least the authentication process using the first authentication sensor is successful, provided that no abnormality is detected in the first authentication sensor. Furthermore, if the communication control unit determines that it is possible to connect to the wide-area communication network, the first authentication sensor is activated based on the receipt of a set of commands from a predetermined server via the wide-area communication network instructing the start of the process for authenticating the user. On the other hand, if the communication control unit determines that it is not possible to connect the first authentication sensor to the wide-area communication network, the first authentication sensor is activated intermittently. . Other lock control devices disclosed herein are lock control devices used in connection with a first authentication sensor that acquires information for authenticating a user in a predetermined manner, and a second authentication sensor that acquires information for authenticating a user in a manner different from that of the first authentication sensor, and are also used in connection with a communication unit (51) for wireless connection to a wide-area communication network, and include an abnormality detection unit (G2) that detects abnormalities in the first authentication sensor, and a control unit (G1) that controls the operation of the first authentication sensor and the second authentication sensor, wherein the control unit is configured not to activate the second authentication sensor until an authentication process using the first authentication sensor is successful if no abnormality is detected in the first authentication sensor, and if it has not received an instruction set from a predetermined server via the wide-area communication network that instructs the start of a process for authenticating a user and instructs the execution procedure of the authentication process, it sets the first and second authentication sensors to a power-saving state, while if it has received an instruction set from the server via the wide-area communication network, it returns the first authentication sensor from the power-saving state to the normal state while keeping the second authentication sensor in the power-saving state.

[0007] With the above configuration, the frequency of activation of the second authentication sensor is reduced, thereby enabling a reduction in power consumption.

[0009] The reference numerals in parentheses in the claims indicate the correspondence with the specific means described later in the embodiments, and do not limit the technical scope of this disclosure. [Brief explanation of the drawing]

[0010] [Figure 1] This diagram shows an overview of a vehicle digital key system. [Figure 2] This is a block diagram showing the configuration of a mobile device. [Figure 3] This is a functional block diagram of the mobile phone control unit. [Figure 4] This figure shows an example of a mobile device display screen. [Figure 5] This figure shows an example of a mobile device display screen. [Figure 6] This is a diagram illustrating the contents of the authentication package. [Figure 7] This figure shows an example of guide images for each authentication step. [Figure 8] This is a block diagram showing the configuration of an in-vehicle system. [Figure 9] It is a functional block diagram of the authentication ECU. [Figure 10] It is a block diagram showing the configuration of the DKS. [Figure 11] It is a functional block diagram of the data processing unit. [Figure 12] It is a sequence diagram for explaining the interaction between the DKS, the mobile device, and the authentication ECU for unlocking the vehicle. [Figure 13] It is a diagram showing an example of the BLE authentication procedure. [Figure 14] It is a diagram showing an example of the display screen of the mobile device when an authentication error occurs. [Figure 15] It is a flowchart for explaining the operation of the system when an authentication error occurs. [Figure 16] It is a flowchart for explaining the operation of the authentication ECU when the vehicle is outside the cellular coverage area. [Figure 17] It is a flowchart for explaining the operation of the DKS when the vehicle is outside the cellular coverage area.

Mode for Carrying Out the Invention

[0011] Hereinafter, the vehicle digital key system Sys of the present disclosure will be described with reference to the drawings. The vehicle digital key system Sys is a system that enables a user to access the vehicle Hv without having a dedicated key by distributing an authentication code, which is a code for using the vehicle Hv, to the mobile device 1.

[0012] In addition, the dedicated key in the present disclosure is a dedicated electronic key for operating the vehicle Hv. The dedicated key is provided to the owner together with the vehicle Hv as proof of being the owner of the vehicle Hv or as a master key having a physical entity at the time of purchasing the vehicle Hv. The dedicated key can be regarded as one of the accessories of the vehicle Hv. The dedicated key can be called a vehicle portable device, a key fob, a key card, a card key, an access key, etc.

[0013] The vehicle digital key system Sys, as shown in Figure 1, includes a portable device 1, an in-vehicle system 2, and a digital key server (DKS) 3. The in-vehicle system 2 includes an authentication ECU 4. ECU stands for Electronic Control Unit, which refers to an electronic control unit.

[0014] Portable device 1 is a general-purpose information processing terminal that can be possessed / carried by the user. In-vehicle system 2 is installed in the vehicle Hv and, provided that the user has been authenticated, performs vehicle control according to the user's location relative to the vehicle Hv or the user's actions. Vehicle control here may include locking / unlocking doors, turning the power on / off, starting the engine, etc. This in-vehicle system 2 is called a smart entry system or a passive entry / passive start (PEPS) system. DKS3 is a server located outside the vehicle Hv.

[0015] The mobile device 1, the in-vehicle system 2, and the DKS3 are configured to communicate with each other via a wireless base station 8 and a wide-area communication network 9. Based on a request from the mobile device 1, the DKS3 transmits an authentication code to the mobile device 1 for using the vehicle Hv. The DKS3 also communicates with the in-vehicle system 2 to indirectly control the operating state of the authentication sensor 6x provided by the in-vehicle system 2. Data communication between the devices can be carried out using encrypted communication, for example, TLS (Transport Layer Security).

[0016] Note that the wireless base station 8 shown in Figure 1 is, for example, a base station for cellular communication. Cellular communication refers to wireless communication compliant with standards such as 4G / 5G. Note that the wireless base station 8 may also be an access point or roadside unit for Wi-Fi (registered trademark). The wide-area communication network 9 is, for example, the internet.

[0017] Furthermore, the in-vehicle system 2 and the mobile device 1 are configured to enable short-range wireless communication. Here, short-range wireless communication refers to communication compliant with a predetermined short-range wireless communication standard, where the actual communication range is, for example, 5m to 30m, and at most about 100m. Examples of short-range wireless communication standards that can be used include Bluetooth®, Wi-Fi®, ZigBee®, UWB-IR (Ultra Wide Band - Impulse Radio), EnOcean®, and Wi-SUN®. Bluetooth standards include BLE (Bluetooth Low Energy) and Bluetooth Classic. As for Wi-Fi standards, various standards can be used, such as IEEE802.11n, IEEE802.11ac, and IEEE802.11ax (so-called Wi-Fi 6). IEEE® stands for Institute of Electrical and Electronics Engineers.

[0018] Here, the operation of each part will be explained using the example of a case where the in-vehicle system 2 and the mobile device 1 are configured to perform BLE communication, which is wireless communication compliant with the BLE standard. In the following, the term BLE communication can be replaced with various short-range wireless communication methods.

[0019] In addition, the in-vehicle system 2 and the mobile device 1 are configured to enable NFC (Near Field Communication) communication, which is wireless communication in accordance with the NFC standard. Here, NFC communication refers to communication with a communication range of several centimeters to several tens of centimeters. NFC communication can also be called near-field communication, contactless communication, or touch communication. NFC communication is a communication method with a communication range that is sufficiently smaller than that of BLE communication (for example, less than one-tenth). Various communication standards such as ISO / IEC 14443 and ISO / IEC 18092 can be adopted as specific communication standards to realize NFC communication. Near-field communication may conform to the Type-F standard, or it may conform to the Type-A or Type-B standard. The Type-F standard corresponds to the so-called FeliCa (registered trademark).

[0020] In this disclosure, "user" refers to a user of the services provided by the vehicle digital key system Sys. A user is a person who has created an account to use the services provided by the vehicle digital key system Sys; in other words, the owner of a mobile device 1 on which the digital key app 104 (described later) is installed. Naturally, there may be multiple vehicles and users managed by DKS3. There may also be multiple mobile devices 1. Each of the multiple users is assigned a user ID. Each of the multiple mobile devices 1 is assigned a device ID. The user ID is a management number used by DKS3 to identify multiple users, and a different value is assigned to each user. The device ID is an identification number used to identify mobile device 1.

[0021] The following description of the vehicle digital key system (Sys) focuses primarily on one vehicle (Hv) and one user. In other words, a user, as used hereafter, refers to any individual with the right to use the vehicle (Hv). The following description is applicable to various vehicle and user combinations.

[0022] <About user authentication methods> The in-vehicle system 2 is configured to authenticate users using multiple methods. For example, the in-vehicle system 2 supports four types of authentication methods: BLE authentication, NFC authentication, image authentication, and voice authentication. Since the mobile device 1 is associated with the user, authenticating the mobile device 1 is equivalent to authenticating the user. In other words, user authentication can also be achieved by authenticating the mobile device 1. User authentication in this disclosure may be interpreted as device authentication as appropriate.

[0023] BLE authentication refers to a method in which an in-vehicle system 2 authenticates a user by performing BLE communication with a mobile device 1. For example, BLE authentication may include the steps of the mobile device 1 sending an authentication code to the in-vehicle system 2 via BLE communication, and the in-vehicle system 2 verifying the validity of the received code. The received code here refers to the authentication code received by the in-vehicle system 2 from the mobile device 1. The step of verifying the validity of the received code includes determining whether the code obtained by decrypting the received code using an encryption key for the mobile device 1 that has been previously registered in the in-vehicle system 2 matches a verification code held by the in-vehicle system 2.

[0024] The encryption key is a code used to verify the legitimacy of the person attempting to access the vehicle Hv, and a different value is assigned to each mobile device 1. For example, the encryption key is the output value obtained by inputting the user ID registered by the user in the system, or the device ID of mobile device 1, into a predetermined hash function. The encryption key is stored in both the in-vehicle system 2 and DKS3. The verification code may be distributed from DKS3 to the in-vehicle system 2 for each authentication process. The verification code may also be pre-registered in the in-vehicle system 2.

[0025] NFC authentication refers to a method in which an in-vehicle system 2 authenticates a user by performing BLE communication with a mobile device 1. This may include the steps of the mobile device 1 sending an authentication code to the in-vehicle system 2 via NFC communication, and the in-vehicle system 2 verifying the validity of the received code. Image authentication may include the steps of the mobile device 1 displaying an image showing the authentication code, and the in-vehicle system 2 reading the image with an in-vehicle camera and verifying the validity of the authentication code shown in the read image. The image showing the authentication code (hereinafter referred to as the code image) is, for example, a one-dimensional code such as a barcode, or a two-dimensional code such as a QR code (registered trademark). The code image may also be implemented as a multi-color code consisting of a two-dimensional array pattern of three or more colors. The code image may also be a secure SQRC (registered trademark) that allows the public and private disclosure of recorded information to be set.

[0026] Voice authentication may include the steps of a mobile device 1 outputting a code tone from its speaker, and an in-vehicle system 2 collecting the code tone with an in-vehicle microphone and verifying the validity of the authentication code indicated by the code tone pattern. The code tone is a continuous sound obtained by converting the authentication code in a predetermined manner. For example, the code tone corresponds to a synthesized signal sound obtained by converting each of the multiple characters (numbers / letters / symbols) that make up the authentication code into a different sound for each character and then concatenating them. For example, the code tone corresponds to a sound pattern obtained by converting the authentication code using DTMF (Dual-Tone Multi-Frequency).

[0027] <About the configuration and functions of mobile devices> Here, we will first explain the configuration / functions of mobile device 1 using Figure 2. Mobile device 1 can include, for example, a smartphone, a tablet, or a wearable device. A wearable device is a device worn on the user's body and can take on a variety of forms, such as a wristband, watch, ring, glasses, or earphone. Wearable devices may also include hearable devices.

[0028] The mobile device 1 comprises a mobile control unit 10, a display 11, a touch panel 12, a biometric authentication device 13, a speaker 14, an NFC communication unit 16, a BLE communication unit 15, and a cellular communication unit 17.

[0029] The mobile control unit 10 is a module that controls the operation of the entire mobile device 1. The mobile control unit 10 is configured to communicate with each of the following: the display 11, the touch panel 12, the biometric authentication device 13, the NFC communication unit 16, the BLE communication unit 15, and the cellular communication unit 17. The mobile control unit 10 is configured as a computer, for example, equipped with a device processor 101, memory 102, storage 103, etc. The device processor 101 is, for example, a CPU (Central Processing Unit). The memory 102 is, for example, a volatile storage medium such as RAM (Random Access Memory). The device processor 101 performs various processes to realize the functions of each functional unit, which will be described later, by accessing the memory 102. The storage 103 is configured to include a non-volatile storage medium such as flash memory.

[0030] Furthermore, the mobile control unit 10 is equipped with a digital key application 104 as application software (hereinafter referred to as "app"). The digital key application 104 is application software for securely performing user authentication, acquisition / storage of authentication codes, and communication with the in-vehicle system 2. The digital key application 104 is installed, for example, on storage 103. Hereafter, "digital key application 104" can be read as "mobile control unit 10" or "device processor 101". The functions of the mobile control unit 10 / digital key application 104 will be described later.

[0031] The display 11 is, for example, a liquid crystal display or an organic EL display. The display 11 displays an image corresponding to the input signal from the mobile control unit 10. The touch panel 12 is a capacitive touch panel and is stacked on the display 11. The touch panel 12 and the display 11 constitute an interface for the user to input instructions into the digital key application 104 and to pair the mobile device 1 with the in-vehicle system 2. The touch panel 12 is an input device. The signals output by the touch panel 12 correspond to the user's operation on the mobile device 1. Hereafter, the output signals of the touch panel 12 will also be referred to as operation signals.

[0032] The biometric authentication device 13 is a device that authenticates a user using, for example, the user's fingerprint or facial image. The biometric authentication device 13 may also authenticate a user using a hand or finger vein pattern or an iris pattern. The biometric authentication device 13 may also be an ear acoustic authentication device that identifies (authenticates) the wearer using a sound reflection pattern determined by the shape of the ear canal. In addition, the biometric authentication device 13 may also be a device that performs authentication using characteristics of spoken voice, such as a voiceprint. The user authentication result is provided to the mobile control unit 10. The speaker 14 outputs sound based on the electrical signal input from the mobile control unit 10. The sounds in this disclosure may include sound effects, notification sounds, voices, melodies, music, etc.

[0033] The NFC communication unit 16 is a communication module for performing NFC communication. The BLE communication unit 15 is a communication module for performing BLE communication. The cellular communication unit 17 is a communication module for performing cellular communication. The cellular communication unit 17 is a communication module that is responsible for the data link layer and physical layer in wireless communication protocols such as LTE. The cellular communication unit 17 provides the mobile control unit 10 with data indicating the reception status of signals from the wireless base station 8, for example, whether or not it is outside the cellular coverage area. In this disclosure, "outside the cellular coverage area" refers to a situation where it is outside the communication area of ​​the wireless base station 8, in other words, a situation where it is not possible to connect to the wide-area communication network 9. In this disclosure, the area where it is possible to receive signals from the wireless base station 8 is also referred to as the cellular coverage area. Unless the cellular communication function is set to off for power saving or the like, the in-vehicle system 2 can go online when the vehicle Hv is within the cellular coverage area.

[0034] Various communication modules include an antenna capable of transmitting and receiving radio waves in the target frequency band, a communication microcontroller (a microcomputer that controls communication), and modulation / demodulation circuits. The portable device 1 may also include a Wi-Fi communication module for performing Wi-Fi communication as a means of communication with the DKS3.

[0035] When the mobile device 1 is connected to the wide-area communication network 9 via cellular communication or Wi-Fi communication, in a so-called online state, the mobile control unit 10 performs various data communications with the DKS3.

[0036] The mobile control unit 10 includes, as shown in Figure 3, an operation response unit F1, a code management unit F2, an authentication guidance unit F3, an authentication execution unit F4, and a reporting unit F5, which are functional units that are activated when the device processor 101 executes the digital key application 104. The various functional units can be enabled when the digital key application 104 is authenticating the user (operator).

[0037] User authentication (login) via the digital key application 104 can be performed by entering a predetermined user ID and password into the digital key application 104. User authentication via the digital key application 104 may also be performed using the biometric authentication device 13. Since the digital key application 104 is part of the vehicle digital key system Sys, the state in which a user is logged into the digital key application 104 corresponds to the state in which a user is logged into the vehicle digital key system Sys. Note that the login state is canceled when a predetermined expiration date has passed since login, and the digital key application 104 may transition to a logout (logoff) state requiring user re-authentication.

[0038] Furthermore, the mobile control unit 10 includes a mobile storage unit 105. The mobile storage unit 105 is a storage area where various data used by the digital key application 104 is stored. The mobile storage unit 105 is implemented using the storage area provided by the memory 102 or storage 103.

[0039] The operation response unit F1 performs processing in response to user operations on the mobile device 1. The operation response unit F1 acquires user instructions based on user selections on buttons displayed on the display 11 and voice input data. For example, in response to the operation start button B11, as illustrated in Figure 4, being pressed, the operation response unit F1 sends a code issuance request to the DKS3. The operation start button B11 is a button used to initiate operations on the vehicle Hv (such as unlocking). The code issuance request is a wireless signal requesting the transmission of an authentication code. Here, wireless signals can be interpreted as messages, frames, packets, etc. The code issuance request corresponds to the operation start signal.

[0040] Figure 4 shows an example of the home screen of the digital key application 104. The home screen is the screen displayed after the application is launched / logged in, and can be considered a waiting screen for user operations. The home screen may include a login status notification image E1 that indicates the login status, and a status confirmation button B12 for displaying a screen that shows the current status of the vehicle Hv. The operation response unit F1 may also display an operation screen as exemplified in Figure 5 in response to the pressing of the operation start button B11. The operation screen may include an unlock button B21, a lock button B22, a start button B23, etc. The unlock button B21 is a button for instructing unlocking, and the lock button B22 is a button for instructing locking. The start button B23 is a button for switching the driving power on. The driving power is the power source for the vehicle Hv to run, and if the vehicle is an engine vehicle, it refers to the ignition power. If the vehicle Hv is an electric vehicle or a hybrid vehicle, the system main relay corresponds to the driving power.

[0041] Figure 5 illustrates a case where the vehicle Hv is currently locked and the lock button B22 and start button B23 are displayed in a way that makes them unselectable. Unselectable means, for example, grayed out or toned down. Unselectable options may also be hidden. Control buttons B2x such as the unlock button B21, lock button B22, and start button B23 may be located on the home screen. The screen configuration can be changed as appropriate. The operation response unit F1 may send a code issuance request based on the fact that a control button B2x such as the unlock button B21 has been pressed. The control buttons B2x may be located on the home screen. In addition, the home screen may have an authentication start button, which is a button for requesting the issuance of an authentication code. In that case, the operation response unit F1 may send a code issuance request based on the fact that the authentication start button has been pressed.

[0042] The code management unit F2 decompresses (unzips / decrypts) the authentication package received from DKS3 and provides it to the authentication guidance unit F3. The authentication package includes at least one authentication code and sequence specification data indicating the procedure for executing the authentication process. In this embodiment, as an example, the in-vehicle system 2 is configured to authenticate the user using so-called multi-stage authentication, which includes multiple stages (authentication steps). For example, the in-vehicle system 2 is configured to perform three-stage authentication, which includes three authentication steps. For each authentication step, at least one of the authentication method and authentication code is different. The authentication package is configured as a dataset showing the authentication method and authentication code used in each authentication step, as shown in Figure 6, for example. The authentication package can be understood as a dataset that instructs the mobile device 1 on the procedure for executing the authentication process in one phase. The authentication package can also be called an instruction set for the mobile device.

[0043] The authentication guidance unit F3 guides the user through the authentication process according to the procedures specified in the authentication package. The authentication process guidance can be provided using images or audio. For example, if the authentication process is set to BLE authentication, NFC authentication, and image authentication, the images shown in Figure 7 will be displayed in that order.

[0044] The authentication execution unit F4 is a functional module that performs the actual processing related to the sending and receiving of authentication codes with the in-vehicle system 2. For example, in the phase of performing BLE authentication, the authentication execution unit F4 generates a transmission frame containing the authentication code and outputs it to the BLE communication unit 15. The authentication code transmitted to the in-vehicle system 2 via BLE communication is basically the authentication code received from DKS3 as a code for BLE authentication.

[0045] In the phase of performing NFC authentication, the authentication execution unit F4 generates a transmission frame containing the authentication code received from DKS3 for NFC authentication and sends it to the NFC communication unit 16. In the phase of performing image authentication, the authentication execution unit F4 generates a code image based on the authentication code received from DKS3 for image authentication and displays it on the display 11. In the phase of performing voice authentication, the authentication execution unit F4 generates an electrical code tone signal based on the authentication code received from DKS3 for voice authentication and sends it to the speaker 14.

[0046] The reporting unit F5 reports the verification results for each step of the authentication process to the DKS3. Furthermore, if code verification fails using a particular authentication method, it sends a message to the DKS3 indicating a malfunction in the corresponding in-vehicle equipment (authentication sensor).

[0047] <About the configuration and functions of the in-vehicle system 2> This section describes the configuration and functions of the in-vehicle system 2. As shown in Figure 8, the in-vehicle system 2 includes an authentication ECU 4, a cellular communication unit 51, a cooperating ECU 52, a controlled object 53, a BLE communication unit 61, an NFC communication unit 62, a camera 63, and a microphone 64.

[0048] The authentication ECU 4 is connected to the cellular communication unit 51, the interoperability ECU 52, the BLE communication unit 61, the NFC communication unit 62, the camera 63, and the microphone 64 via the in-vehicle network, enabling mutual communication. The interoperability ECU 52 is connected to the controlled object 53, enabling communication. The in-vehicle network is a communication network built within the vehicle Hv. Various standards can be adopted for the in-vehicle network, such as Controller Area Network (CAN), Ethernet (registered trademark), and FlexRay (registered trademark). Some devices, such as the cellular communication unit 51, may be connected to the authentication ECU 4 via a dedicated line without going through the in-vehicle network. The connection configuration between devices can be changed as appropriate.

[0049] The authentication ECU 4 is an ECU that authenticates the user in cooperation with the BLE communication unit 61 and other components. Furthermore, the authentication ECU 4, in cooperation with the linked ECU 52, performs predetermined vehicle controls such as unlocking the doors and turning on the driving power, provided that user authentication is successful. The authentication ECU 4 maintains its function for authenticating the user even when the driving power is off, using power supplied from the vehicle's battery.

[0050] The authentication ECU 4 is implemented using a computer. Specifically, the authentication ECU 4 includes an authentication processor 41, memory 42, storage 43, I / O 44, and bus lines connecting these components. The authentication processor 41 is, for example, a CPU. The authentication processor 41 performs various processes to realize the functions of each functional unit, which will be described later, by accessing the memory 42. The storage 43 stores a vehicle authentication program, which is a program related to the authentication process of users accessing the vehicle Hv. The I / O 44 is a circuit module for communicating with other devices. Details of the functions of the authentication ECU 4 will be described later. The authentication ECU 4 corresponds to the lock control device and the in-vehicle device.

[0051] The cellular communication unit 51 is a communication module for performing cellular communication. The cellular communication unit 51 transmits data input from the authentication ECU 4 to the DKS3 and outputs data received from the DKS3 to the authentication ECU 4. The cellular communication unit 51 outputs a connection status signal to the authentication ECU 4 indicating whether or not it is receiving a signal from the radio base station 8, that is, whether or not it is within the cellular coverage area. The cellular communication unit 51 may maintain a so-called standby state, capable of receiving signals from the radio base station 8 even when the driving power is off, using power supplied from the vehicle battery. The standby state corresponds to a state in which it can receive IP-PUSH notifications from the DKS3. The operating state of the cellular communication unit 51 may be controlled by the authentication ECU 4. The vehicle system 2 may also be equipped with a Wi-Fi communication module instead of the cellular communication unit 51, or in combination with the cellular communication unit 51.

[0052] The linked ECU 52 is any ECU connected to the authentication ECU 4. There may be multiple linked ECUs 52. Linked ECUs 52 can be, for example, a body ECU, a power supply ECU, or a display ECU. The body ECU controls body system actuators such as door lock motors. The power supply ECU controls the on / off state of the driving power supply installed in the vehicle Hv. The display ECU controls the display on the in-vehicle display.

[0053] The linked ECU 52 controls the controlled object 53 based on a request from the authentication ECU 4. The controlled object 53 is an actuator / electrical equipment that the linked ECU 52 can control. The controlled object 53 may be, for example, a door lock motor, an in-vehicle display, a speaker, an in-vehicle lighting system, or an air conditioning system. The door lock motor is a motor that switches the state (locked, unlocked) of the lock mechanism of each door. The in-vehicle lighting system may be a headlight, an interior light, a welcome lamp, etc. The in-vehicle display may be a liquid crystal / organic EL display located inside the vehicle, or a projector that projects images onto the side window of the vehicle or the road surface. Some of the controlled objects 53 may be configured to be directly controllable by the authentication ECU 4 without going through the linked ECU 52.

[0054] The BLE communication unit 61 is a communication module for performing BLE communication. The BLE communication unit 61 is located, for example, in the center console, the ceiling of the vehicle, the upper edge of the front / rear windows, or the C-pillar. The operating state of the BLE communication unit 61 is controlled by the authentication ECU 4. The BLE communication unit 61 has the function of a reader for obtaining (receiving) an authentication code from the mobile device 1 via BLE communication.

[0055] The NFC communication unit 62 is a communication module for performing NFC communication. The NFC communication unit 62 functions as a reader for obtaining (receiving) an authentication code from the mobile device 1. The NFC communication unit 62 may include, for example, an external communication module and an internal module. The external NFC communication unit 62 corresponds to a configuration for performing authentication for locking and unlocking control. The internal NFC communication unit 62 corresponds to a configuration for performing authentication for on / off control of the driving power supply. The external NFC communication unit 62 may be installed on the driver's side outer door handle, side mirror, or A / B / C pillar. The internal NFC communication unit 62 may be installed on the instrument panel or center console, etc. The operating state of each NFC communication unit 62 is controlled by the authentication ECU 4.

[0056] Camera 63 is an optical camera. Camera 63 corresponds to a device for reading the code image displayed on the mobile device 1. For example, the in-vehicle system 2 may include an external camera 63 and an internal camera 63. The operation of each camera 63 is driven based on signals from the authentication ECU 4. The external camera 63 is located, for example, on the B-pillar on the driver's side, the edge of the roof, or the side mirror. The internal camera 63 is installed, for example, on the steering column cover or the upper edge of the front windshield, with its optical axis facing the direction of the driver's seat headrest. Image data acquired by camera 63 is provided to the authentication ECU 4.

[0057] Microphone 64 is a device that converts sound into electrical signals and provides them to the authentication ECU 4. Microphone 64 is responsible for collecting the chord tones output by the portable device 1, converting them into electrical signals (digital data), and outputting them to the authentication ECU 4. The in-vehicle system 2 may include an external microphone 64 and an internal microphone 64. The external microphone 64 may be placed on the B-pillar or side mirror on the driver's side. The internal microphone 64 may be placed around the driver's seat, such as on the instrument panel or steering wheel.

[0058] The BLE communication unit 61, NFC communication unit 62, camera 63, and microphone 64 can function as devices for acquiring information (in this case, an authentication code) for user authentication. Therefore, in this disclosure, the BLE communication unit 61, NFC communication unit 62, camera 63, and microphone 64 are collectively referred to as the authentication sensor 6x.

[0059] In addition to the sensors / switches / ECUs mentioned above, various other devices are directly or indirectly connected to the authentication ECU4. For example, the authentication ECU4 may receive output signals from courtesy switches and shift position sensors. A courtesy switch is a switch that outputs a signal indicating the open or closed state of the door. A shift position sensor is a sensor that outputs a signal indicating the current shift position.

[0060] As shown in Figure 9, the authentication ECU 4 comprises a sensor control unit G1, a sensor diagnostic unit G2, a communication control unit G3, an authentication processing unit G4, and a control request unit G5 as functional units. These functional units are realized, for example, by the authentication processor 41 executing a vehicle authentication program.

[0061] Furthermore, the authentication ECU 4 includes a vehicle storage unit 45 for storing data related to user authentication. The vehicle storage unit 45 is implemented using a storage area provided by the storage 43 or memory 42. The vehicle storage unit 45 includes an encryption key storage unit 451. The encryption key storage unit 451 is a storage area where encryption keys are stored. The encryption key described in this disclosure is a code used by the in-vehicle system 2 to authenticate the user, and can be called an authentication encryption key.

[0062] The sensor control unit G1 is a software module that controls the operation (active / sleep) of various authentication sensors 6x. The active state of the authentication sensor 6x corresponds to a state in which it can acquire wireless signals / images / sounds indicating an authentication code. The active state can also be called the normal state. The sleep state refers to a state in which functionality is limited compared to the active state, for example, a state in which it is unable to send or receive signals. The sleep state may also be a state in which the power is set to off. The sleep state should be a state in which power consumption can be reduced compared to the active state. The sleep state can also be called the off state or inactive state. The sleep state corresponds to the power saving state. Activating the authentication sensor 6x corresponds to transitioning from the sleep state to the active state.

[0063] The sensor control unit G1 sets each authentication sensor 6x to sleep mode when the vehicle Hv is parked, unless the activation conditions described below are met (i.e., basically). The authentication ECU 4 basically keeps even the highest priority sensors in sleep mode while parked. The sensor control unit G1 sequentially activates the authentication sensors 6x according to the procedure specified in the verification package delivered from, for example, DKS3. The sensor control unit G1 activates the authentication sensor 6x corresponding to the next step each time the previous step of the multiple authentication steps is completed. The authentication sensor 6x to be activated is selected by the authentication processing unit G4. Based on instructions from the authentication processing unit G4, the sensor control unit G1 activates the sleep-state authentication sensor 6x or puts the active authentication sensor 6x to sleep.

[0064] The sensor diagnostic unit G2 is configured to determine whether each authentication sensor 6x is functioning correctly by communicating with it. Whether or not it is functioning correctly can be determined using various methods, such as a watchdog timer method or a homework answer method. The sensor diagnostic unit G2 may also determine that there is a problem with the authentication sensor 6x if it is unable to communicate with it due to a broken cable or a disconnected connector.

[0065] Furthermore, the sensor diagnostic unit G2 may diagnose the authentication sensor 6x in a manner appropriate to the type of authentication sensor 6x. For example, the sensor diagnostic unit G2 may detect an abnormality in the camera 63 based on the fact that some pixels in the image provided by the camera 63 are always at a constant value. Alternatively, based on the fact that the noise level input from the microphone 64 is above a predetermined value, the unit may consider the surrounding environment to be noisy and determine that authentication using the microphone 64 will temporarily not function properly. When a sensor is not functioning properly or is malfunctioning, this may include cases where the sensor itself is normal, but the authentication process is prone to failure due to noise.

[0066] The diagnostic results from the sensor diagnostic unit G2 are stored in the memory 42 and transmitted to the DKS3 by, for example, the communication control unit G3. The sensor diagnostic unit G2 may diagnose the authentication sensor 6x periodically, or it may diagnose it when a specific event is detected. A specific event could be the timing when the power supply for driving switches from on to off, or from off to on. The sensor diagnostic unit G2 corresponds to the anomaly detection unit. The portable device 1 or the DKS3 may also have the function of an anomaly detection unit.

[0067] The communication control unit G3 controls the operation (active / inactive) of the cellular communication unit 51. An active state of the cellular communication unit 51 corresponds to a state in which the function for communicating with the radio base station 8 is operational, such as a standby state. An inactive state of the cellular communication unit 51 corresponds to a state in which it cannot receive signals from the radio base station 8, and the receiving function is set to off. An inactive state of the cellular communication unit 51 may also be a state in which the power to the cellular communication unit 51 is turned off. The communication control unit G3 may change the control policy for the operation of the cellular communication unit 51 while it is parked based on the connection status signal input from the cellular communication unit 51.

[0068] For example, if the location where the vehicle is parked is outside of cellular coverage, the communication control unit G3 may turn off the power to the cellular communication unit 51 thereafter. Whether or not the parking location is outside of cellular coverage can be determined based on the last connection status signal input at the time the driving power is switched from on to off. The state where the driving power is off corresponds to the parked state.

[0069] On the other hand, if the parking location is within cellular coverage, the communication control unit G3 keeps the cellular communication unit 51 in standby mode even while the vehicle is parked. In another configuration, if the location where the vehicle is parked is within cellular coverage, the communication control unit G3 may operate the cellular communication unit 51 in low-power mode. Low-power mode is a mode in which the unit is intermittently (temporarily) activated and connected to the wireless base station 8.

[0070] By intermittently activating the cellular communication unit 51, verification packages can be received from the DKS3 even while parked. Restoring the cellular communication unit 51 to an active state corresponds to querying the DKS3 for any data (messages) intended for the vehicle Hv.

[0071] In low-power mode, the recovery interval, which is the interval at which the cellular communication unit 51 returns to an active state, can be set to 1 second, 3 seconds, 10 seconds, etc. The recovery interval may also be changed according to the elapsed parking time, which is the time elapsed since the driving power supply was set from on to off. The communication control unit G3 may increase the recovery interval as the elapsed parking time increases. For example, the communication control unit G3 may set the recovery interval to 1 second, 2 seconds, or 3 seconds when the elapsed parking time is less than a predetermined value (30 minutes), while setting the recovery interval to 5 seconds, 10 seconds, 15 seconds, etc., when the elapsed parking time is equal to or greater than the predetermined value.

[0072] Furthermore, the communication control unit G3 may change the recovery interval according to the battery voltage. As the parking time increases, the battery voltage decreases, so the battery voltage can be used as an indicator of the parking time. For example, the communication control unit G3 may set the recovery interval to 1 second, 2 seconds, or 3 seconds when the battery voltage is above a predetermined value (12.0V), while setting the recovery interval to 5 seconds, 10 seconds, or 15 seconds when the battery voltage is below a predetermined value.

[0073] The communication control unit G3, in cooperation with the cellular communication unit 51, also performs processing related to data communication with the DKS3. The communication control unit G3 may send a sensor status report, which is a communication packet indicating whether each authentication sensor 6x is operating normally or if a malfunction has occurred, to the DKS3. The communication control unit G3 may also send an authentication result report, which is a communication packet indicating the result of the authentication process, to the DKS3. Furthermore, the communication control unit G3 may send a signal to the DKS3 indicating when the driving power supply is switched on or off. In addition, the communication control unit G3, in cooperation with the cellular communication unit 51, may also send the current location, interior temperature, battery level / fuel level, etc., to the DKS3. The communication control unit G3 may send data indicating the current status of the vehicle Hv (so-called current status) to the DKS3.

[0074] Furthermore, the communication control unit G3 receives a verification package from DKS3 and transmits it to the authentication processing unit G4. The verification package includes sequence specification data indicating the execution procedure of the authentication process, and the authentication code used in each authentication step / or the verification code from which the authentication code is based. The communication control unit G3 also receives an encryption key from DKS3 and stores it in the encryption key storage unit 451.

[0075] The authentication processing unit G4 performs multi-stage authentication according to the procedure specified in the verification package. The authentication processing unit G4 includes a decryption unit G41 and a verification unit G42 as sub-functional units. The decryption unit G41 is configured to decrypt the received code, which is the authentication code acquired via the authentication sensor 6x, using the encryption key stored in the encryption key storage unit 451. The verification unit G42 is configured to compare the decrypted received code obtained by the decryption unit G41 decrypting the received code with the verification code acquired from the DKS3. Hereinafter, the decrypted received code will also be referred to as the received code. When the received code and the verification code do not match, the authentication processing unit G4 determines that authentication has failed. The comparison (code verification) between the received code and the verification code is performed for each authentication step. The authentication processing unit G4 determines that user authentication has succeeded based on successful code verification in all steps. The details of the operation of the authentication processing unit G4 will be described separately later.

[0076] Based on the successful authentication of the user, the control request unit G5 is configured to perform vehicle control according to the user operation in cooperation with the cooperation ECU52. For example, when a signal indicating that the unlocking button B21 has been pressed by the user is received via cellular communication or BLE communication, a request is made to the body ECU as the cooperation ECU52 to unlock the door. The body ECU controls the door lock motor based on the request from the authentication ECU4 to switch the door to the unlocked state. Other vehicle controls such as locking, turning on and off the driving power supply, and turning on the air conditioning function can also be similarly performed by the control request unit G5 in cooperation with the cooperation ECU52. As another embodiment, the authentication ECU4 itself may be directly configured to control the control target 53 to perform control according to the user operation.

[0077] <Regarding the Configuration and Function of DKS> Here, the configuration and function of the DKS3 will be described. As shown in FIG. 10, the DKS3 includes a data processing unit 30, a network connection device 31, and a vehicle DB32. DB is an abbreviation for Database (Database).

[0078] The data processing unit 30 performs various processes based on signals / data input from the network connection device 31. The data processing unit 30 is connected to both the network connection device 31 and the vehicle DB 32 in a manner that allows for mutual communication. The data processing unit 30 is composed of a server processor 301, memory 302, and storage 303. The server processor 301 is an arithmetic core that performs various calculation processes and is implemented using, for example, a CPU or GPU. The storage 303 stores the vehicle management program. When the server processor 301 executes the vehicle management program, various functional units described later are realized. Note that the execution of the vehicle management program by the server processor 301 corresponds to the execution of a vehicle management method that corresponds to the program.

[0079] The network connection device 31 is a communication module for connecting to the wide-area communication network 9. The network connection device 31 is configured to communicate with communication equipment that constitutes the wide-area communication network 9, for example, using optical fiber. As a result, when the mobile device 1 is online, the DKS3 can communicate data with the mobile device 1. Similarly, when the in-vehicle system 2 is online, the DKS3 also communicates data with the in-vehicle system 2.

[0080] Vehicle DB32 is a database where information about vehicles managed by the vehicle digital key system Sys is registered, and it stores information about the in-vehicle system 2. Information about the in-vehicle system 2 includes, for example, the vehicle ID of vehicle Hv, mounted sensor data, status data, user data, and encryption key.

[0081] The vehicle ID is a unique identification number assigned to each vehicle Hv. The mounted sensor data is data indicating the combination of authentication sensors 6x equipped on the vehicle Hv, in other words, the combination of authentication methods that the on-board system 2 / authentication ECU 4 can perform. Note that the on-board system 2 is a system centered around the authentication ECU 4. In the following explanation, "on-board system 2" can be appropriately replaced with "authentication ECU 4".

[0082] The status data includes information regarding whether the vehicle Hv is within cellular coverage. The status data also includes sensor status information indicating the state of the authentication sensor 6x on the vehicle Hv, i.e., whether it is functioning normally or malfunctioning. The status data includes information on the availability of each authentication method that the in-vehicle system 2 can implement. This authentication method availability information indicates whether the in-vehicle system 2 can actually use (implement) that authentication method, and may be updated in conjunction with the sensor status information.

[0083] Other status data may include elapsed parking time, remaining time until the in-vehicle system 2 goes online again, current location, interior temperature, battery level / fuel level, etc. The values ​​of the various items that make up the status data can be updated as needed through communication with the authentication ECU 4 or portable device 1, as will be explained below. The vehicle DB 32 may also store information such as the update date and time of various information.

[0084] User data is information about the user of the vehicle Hv, including, for example, user ID, password, contact information such as phone number, email address, and device ID. The user ID and password are a dataset used to authenticate the user. The user ID and password are registered by the user, for example, when creating an account.

[0085] The encryption key is generated, for example, when an account is created, and stored in the encryption key storage unit 321. The encryption key storage unit 321 is the area in the vehicle DB 32 where the encryption key is stored. The DKS3 also distributes the generated encryption key to the in-vehicle system 2 via cellular communication. As a result, the same encryption key corresponding to one user / one mobile device 1 is stored in both the DKS3 and the authentication ECU 4. Note that the means of sending the encryption key from the DKS3 to the authentication ECU 4 is not limited to cellular communication. The DKS3 may also distribute the encryption key to the authentication ECU 4 via the mobile device 1. Registration of the encryption key to the authentication ECU 4 may be performed using a dedicated registration tool handled at a dealer shop, etc.

[0086] The vehicle DB32 is implemented using a rewritable, non-volatile storage medium. The vehicle DB32 is configured to allow data writing, reading, and deletion by the server processor 301. The vehicle DB32 may be located on a separate server, physically independent of the DKS3. The DKS3 may also be implemented across multiple servers. The roles and functional assignments for each server can be changed as needed.

[0087] The data processing unit 30 includes a status management unit H1 and an authentication request response unit H2 as functional units, as shown in Figure 11.

[0088] The status management unit H1 updates the status data of the in-vehicle system 2 through communication with the in-vehicle system 2. For example, the status management unit H1 updates data indicating the status (on / off) of the driving power supply based on a report from the in-vehicle system 2. The status management unit H1 also updates sensor status information indicating the status (normal / abnormal) of each authentication sensor 6x based on a report from the in-vehicle system 2. For example, if the in-vehicle system 2 reports a malfunction of the camera 63, the authentication method using the camera 63 is set to unavailable. If the status management unit H1 receives a report from the in-vehicle system 2 that the authentication sensor 6x that was reported to be malfunctioning is functioning normally, it resets the authentication method using that authentication sensor 6x to available. In this way, the status management unit H1 plays a role in managing which authentication methods are available and which are unavailable among the authentication methods supported by the in-vehicle system 2, according to the status of the authentication sensors 6x provided by the in-vehicle system 2. Authentication methods for which the availability information is set to available correspond to available methods, and authentication methods for which the availability information is set to unavailable correspond to unavailable methods.

[0089] Furthermore, the status management unit H1 determines whether or not vehicle Hv is within cellular coverage and stores the result in vehicle DB32. For example, DKS3 periodically performs a communication check with the in-vehicle system 2. The interval for performing the communication check can be 10 seconds, 30 seconds, 1 minute, etc. If communication with the in-vehicle system 2 is impossible for a certain period of time (for example, 90 seconds) or more, the status management unit H1 determines that the in-vehicle system 2 is located outside cellular coverage. Alternatively, the status management unit H1 may determine whether or not the mobile device 1 is within cellular coverage using a similar method.

[0090] The authentication request response unit H2 is a functional block that generates an authentication package and a verification package based on the receipt of a code issuance request from the mobile device 1 and sends them to each device. The authentication request response unit H2 includes a selection unit H21, a sequence determination unit H22, a verification code generation unit H23, an encryption unit H24, and a distribution processing unit H25 as subfunctional blocks. The selection unit H21 selects the authentication method to be used for the actual authentication process from among the available authentication methods.

[0091] As mentioned above, the in-vehicle system 2 is configured, for example, to authenticate the user using three-factor authentication. In this case, the selection unit H21 selects three authentication methods to be used for three-factor authentication from among the available authentication methods, based on the priority set in advance for each authentication method. The priority for each authentication method may be configured to be changeable by the user. In this disclosure, the highest priority sensor is also referred to as the top-priority sensor. The top-priority sensor corresponds to the first authentication sensor. The authentication sensor 6x with the second highest priority is also referred to as the second-priority sensor. The second-priority sensor corresponds to the second authentication sensor. Authentication methods other than the adopted methods correspond to the unadopted methods. If the three-factor authentication consists of BLE authentication, NFC authentication, and image authentication, voice authentication may be an unadopted method.

[0092] If the number of available authentication methods is insufficient for the number of authentication steps, the selection unit H21 may select one authentication method multiple times. For example, if the only available authentication methods are BLE authentication and image authentication, either BLE authentication or image authentication may be selected twice.

[0093] The sequence determination unit H22 is a functional unit that determines the execution order of the authentication methods selected by the selection unit H21. The execution order may be determined according to the priority order mentioned above. The content of multi-factor authentication is determined through the cooperation of the selection unit H21 and the sequence determination unit H22. The sequence determination unit H22 may be integrated with the selection unit H21.

[0094] The verification code generation unit H23 issues verification codes used in each authentication step. Specifically, the verification code generation unit H23 creates verification codes for the first authentication step, the second authentication step, and the third authentication step. Each verification code has a different value when issued. The verification code can be, for example, the epoch seconds at the time of issuance, the count value of the number of issuances, or a random number. Furthermore, the verification code may be a value obtained by subtracting the number of issuances from a predetermined initial value. The verification code corresponds to the seed of the authentication code.

[0095] The encryption unit H24 is configured to encrypt the verification code generated by the verification code generation unit H23 using an encryption key. The verification code encrypted with the encryption key corresponds to the authentication code. The authentication code and verification code are equivalent to so-called disposable key codes (one-time keys) that are discarded after being used once.

[0096] The distribution processing unit H25 creates an authentication package and a verification package based on the data determined / created by the sub-function units described above. It then distributes the authentication package to the mobile device 1 and the verification package to the in-vehicle system 2. The verification package corresponds to the instruction set, particularly the instruction set for vehicles. The distribution processing unit H25 corresponds to the transmission processing unit.

[0097] In addition, the data processing unit 30 may have functions to perform new user registration, deletion, and modification of registration details based on data input from the network connection device 31. New user registration / deletion corresponds to account issuance / deletion. User operations / instructions related to new registration, deletion, and modification of registration details are obtained, for example, via the mobile device 1 and the network connection device 31.

[0098] <Regarding the operation of each device for vehicle unlocking> Here, the operation of the mobile device 1, DKS3, and authentication ECU4 when a user unlocks the vehicle Hv using the digital key app 104 will be explained using Figure 12. Note that the description of mobile device 1 as the implementing body in the following steps can be appropriately replaced with mobile control unit 10 / digital key app 104 / operation response unit F1 / code management unit F2 / authentication guidance unit F3 / authentication execution unit F4 / reporting unit F5. Also, the description of DKS3 can be replaced with data processing unit 30 / authentication request response unit H2 / selection unit H21 / sequence determination unit H22 / verification code generation unit H23 / encryption unit H24 / distribution processing unit H25. Furthermore, the description of authentication ECU4 can be replaced with authentication processor 41 / sensor control unit G1 / sensor diagnostic unit G2 / communication control unit G3 / authentication processing unit G4 / control request unit G5.

[0099] The sequence for unlocking using the digital key app 104 is triggered by user operation on the mobile device 1. When the user presses the operation start button B11 on the mobile device 1, the mobile device 1 sends a code issuance request to the DKS3 (S11). Step S11 corresponds to the step in which the mobile device 1 sends a code issuance request to the DKS3 based on user operation.

[0100] Based on receiving a code issuance request from the mobile device 1, DKS3 executes a sequence for generating authentication and verification packages. Specifically, it selects the authentication method (S12), determines the execution order (S13), and generates verification codes for each authentication step (S14). The verification codes for each authentication step generated in step S14 are encrypted by the encryption unit H24 and become authentication codes.

[0101] Step S15 is the step of sending a dataset containing the details of each authentication step determined in the above steps and the authentication code as an authentication package to the mobile device 1. Based on the receipt of the authentication package, the mobile device 1 starts the authentication guide. For example, it displays a guidance screen corresponding to the first authentication method.

[0102] Step S16 is the step of generating a verification package, which is a dataset containing the authentication method and verification code for each authentication step, and sending it to the vehicle Hv. The in-vehicle system 2 keeps the cellular communication unit 51 in standby mode and maintains an online state even when parked. Therefore, the in-vehicle system 2 can receive verification packages from DKS3 even when the vehicle Hv is parked and waiting. As mentioned above, the in-vehicle system 2 may be configured to be online intermittently while in standby mode. In that case, the in-vehicle system 2 can receive verification packages issued by DKS3 when it comes online.

[0103] When the authentication ECU 4 receives a verification package, it initiates a sequence of authentication processes (multi-factor authentication) based on the data shown in the package. In this disclosure, the authentication ECU 4 performs BLE authentication, NFC authentication, and image authentication as multi-factor authentication processes, but the content of the authentication process may be changed as appropriate depending on the situation and settings. In this disclosure, the nth authentication step (where n is a natural number) is also referred to as nth-level authentication. For example, first-level authentication refers to the first-level authentication process. In this disclosure, the authentication sensor 6x corresponding to nth-level authentication is also referred to as the nth sensor. For example, the first sensor refers to the authentication sensor 6x corresponding to first-level authentication. An authentication sensor 6x corresponding to a certain authentication method refers to a device for receiving / reading / listening to an authentication code transmitted / displayed / audio output from the mobile device 1.

[0104] If BLE authentication is set as the primary authentication, the authentication ECU 4 triggers the reception of the authentication package to activate the BLE communication unit 61 (S17) and perform BLE authentication (step S18). BLE authentication may include steps S40 to S44, as shown in Figure 13, for example. Step S40 is the step of establishing a BLE communication link with the mobile device 1. The detailed sequence for establishing the communication link may be carried out in accordance with the BLE standard.

[0105] S41 is the step in which the authentication ECU 4 sends a BLE signal to the mobile device 1 requesting the transmission of an authentication code. Based on receiving the code request from the authentication ECU 4, the mobile device 1 sends back the authentication code for BLE authentication received from the DKS 3 to the authentication ECU 4 (S42).

[0106] When the authentication ECU 4 receives an authentication code from the mobile device 1, it decrypts the code using a locally stored encryption key and generates a received code (S43). The matching unit G42 then compares the received code with the BLE authentication verification code received from the DKS3 (S44). If the two codes match as a result of this code comparison (matching) process, the authentication processing unit G4 considers the primary authentication to be successful. On the other hand, if the two do not match, the authentication processing unit G4 determines that the authentication has failed. This determination result is stored in memory 42 or the like and referenced in subsequent processing. Thus, BLE authentication may include a code request step (S41), a code return step (S42), and a code matching step (S44). When the BLE authentication process is complete, the authentication ECU 4 puts the BLE communication unit 61 into a sleep state (step S19).

[0107] Step S20 is the step of notifying DKS3 and mobile device 1 of the result of primary authentication. The notification to mobile device 1 may be performed via cellular communication. Mobile device 1 may also obtain the result of primary authentication from DKS3. DKS3 may receive the result of primary authentication from mobile device 1.

[0108] Upon receiving notification from the authentication ECU4, DKS3 updates the date and time at which it confirmed that the authentication sensor 6x (in this case, the BLE communication unit 61) for primary authentication was functioning correctly (S21). If DKS3 receives a notification indicating that BLE authentication has failed, it determines that there may be a malfunction in the BLE communication unit 61 and sets the BLE authentication availability information to unavailable for a predetermined period. The period for which the unavailable setting is maintained can be, for example, 5 minutes, 10 minutes, or 30 minutes.

[0109] Furthermore, the mobile device 1 controls the display screen based on notifications from the authentication ECU 4 (S22). For example, if it receives a notification of successful authentication, it displays a guide image for secondary authentication. Also, if the mobile device 1 receives a notification of authentication failure from the DKS3 / authentication ECU 4, it displays an image indicating that authentication has failed. If the authentication process fails, the mobile device 1 may also notify the DKS3 that there is a problem with the sensor used for primary authentication (e.g., the BLE communication unit).

[0110] If primary authentication (BLE authentication) fails, the authentication ECU4 will output a notification sound indicating the authentication failure from a speaker (not shown in the diagram) and then return to standby mode. Standby mode is the state before receiving the verification package.

[0111] If primary authentication (BLE authentication) is successful, the authentication ECU 4 performs the sequence for secondary authentication. For example, if NFC authentication is set as the secondary authentication, the authentication ECU 4 activates the NFC communication unit 62 (S23) and performs NFC authentication (S24). Like BLE authentication, NFC authentication may include a code request step, a code return step, and a code verification step. When the NFC authentication process is complete, the authentication ECU 4 puts the NFC communication unit 62 into sleep mode (S25).

[0112] Step S26 is the step of notifying DKS3 and mobile device 1 of the result of secondary authentication (NFC authentication). Upon receiving notification from authentication ECU 4, DKS3 updates the date and time at which it confirmed that the authentication sensor 6x (NFC communication unit 62) involved in secondary authentication is operating normally (S27). If DKS3 receives a notification indicating that NFC authentication has failed, it determines that there may be a malfunction in the NFC communication unit 62 and sets the NFC authentication availability information to unavailable for a predetermined period.

[0113] Furthermore, the mobile device 1 controls the display screen upon receiving notification of the secondary authentication result from the authentication ECU 4 (S28). For example, if it receives notification of successful authentication, it displays a guide image for tertiary authentication. If it receives notification of authentication failure, it displays an image indicating that authentication has failed. If secondary authentication fails, the authentication ECU 4, as with primary authentication failure, outputs a notification sound from its speaker indicating that authentication has failed and then returns to standby mode.

[0114] If secondary authentication is successful, the authentication ECU 4 performs the sequence for tertiary authentication. For example, if image authentication is set as the tertiary authentication, the authentication ECU 4 activates the camera 63 (S29) and performs image authentication (S30). Image authentication includes the steps of extracting a code image from the camera image, obtaining an authentication code by analyzing the code image, and comparing the received code obtained by decrypting the authentication code with a verification code. If a code image cannot be read after a predetermined time (e.g., 30 seconds) has elapsed since activating the camera 63, the authentication ECU 4 may determine that image authentication has failed. Once image authentication is complete, the authentication ECU 4 puts the camera 63 into sleep mode (S31).

[0115] S32 is a step in which the results of the third-level authentication (image authentication) are notified to DKS3 and the mobile device 1. Upon receiving notification from the authentication ECU 4, DKS3 updates the date and time at which it confirmed that the authentication sensor 6x (camera 63) for the third-level authentication is functioning correctly (S33). If DKS3 receives a notification indicating that image authentication has failed, it may determine that there is a malfunction in the camera 63 and set the image authentication availability information to unavailable for a predetermined period.

[0116] Furthermore, the mobile device 1 controls the display screen upon receiving notification of the result of the third-level authentication from the authentication ECU 4 (S34). For example, if it receives notification of successful third-level authentication, it may display an image indicating that multi-level authentication was successful. Also, if the mobile device 1 receives notification of authentication failure, it displays an image indicating that authentication failed. If the third-level authentication fails, the authentication ECU 4 outputs a notification sound from its speaker indicating that authentication failed, similar to the case of a first-level authentication failure, and then returns to standby mode.

[0117] Note that the content of the primary, secondary, and tertiary authentication may be voice authentication. If the tertiary authentication is set to voice authentication, the authentication ECU4 will activate microphone 64 based on the success of the secondary authentication, perform voice authentication, and then turn off microphone 64.

[0118] Based on the success of all authentication steps, the authentication ECU 4 performs control (in this case, unlocking) according to the user operation (S35). After unlocking is complete, the authentication ECU 4 notifies the DKS3 and the mobile device 1 that the specified control has been completed (S36). Based on this notification, the DKS3 updates the vehicle Hv status information, and the mobile device 1 switches its display screen. For example, an image indicating that unlocking was successful is displayed on the display 11.

[0119] Furthermore, the portable device 1 may display an unlocking complete button on the display 11, which is a button for registering that the vehicle Hv has been unlocked, based on a notification from the authentication ECU 4 or DKS3. The user may press the unlocking confirmation button when they have confirmed that the vehicle Hv has actually been unlocked. Based on the fact that the unlocking confirmation button has been pressed, the portable device 1 may send a confirmation signal to the DKS3. The confirmation signal is a signal that notifies the DKS3 that the user has confirmed that the vehicle Hv has been unlocked. Based on the receipt of the confirmation signal, the DKS3 may confirm the registration that the vehicle Hv is in an unlocked state.

[0120] <Supplementary information regarding authentication failures> Mobile device 1 may send a retry request based on a failure in verification at a certain authentication step. The retry request corresponds to a code issuance request that includes information indicating the failure method. The failure method is the authentication method corresponding to the authentication step in which the authentication error occurred. The retry request corresponds to an error message.

[0121] The mobile device 1 may automatically send a retry request based on an authentication error occurring during multi-factor authentication, or it may send one based on user input. For example, the mobile device 1 may display a retry button B41 on the display 11, as illustrated in Figure 14, for sending a retry request based on an authentication error occurring during multi-factor authentication. The mobile device 1 may also send a retry request based on the retry button B41 being pressed.

[0122] When DKS3 receives a retry request, it determines a new authentication procedure that does not use any failure methods other than those specified in the retry request. Specifically, DKS3 temporarily disables the failure methods and then determines a new three-step authentication procedure by selecting an authentication method for each step from the available authentication methods.

[0123] Figure 15 shows the processing flow corresponding to the above operation. Step S51 in Figure 15 is a step in which the mobile device 1 / authentication ECU 4 determines whether or not authentication in a certain step was successful, and step S52 is a step in which the mobile device 1 sends a retry request to DKS3 based on the occurrence of an authentication error. Step S53 is a step in which DKS3 registers the availability status of the authentication sensor 6x corresponding to the failure method as unavailable. In this disclosure, the authentication sensor 6x corresponding to the authentication method set to unavailable is also referred to as a faulty sensor. Conversely, the authentication sensor 6x corresponding to the available authentication method is also referred to as a healthy sensor. Step S54 is a step in which DKS3 re-determines the multi-step authentication procedure using the available authentication method / healthy sensor and redistributes the authentication package and verification package.

[0124] Note that depending on the number of authentication methods / authentication sensors 6x that are set to unavailable, it is possible that only one authentication method will be available. Even if only one authentication method is available, DKS3 may perform three-factor authentication by performing that authentication method three times. Multi-factor authentication may also involve performing the same authentication method multiple times. In that case, it is preferable that the verification code and authentication code are different for each authentication step.

[0125] <Effects of the above configuration> According to the above configuration, the authentication ECU 4 activates only the authentication sensor 6x corresponding to the next authentication method to be implemented from among the multiple types of authentication sensors 6x, and puts the other authentication sensors 6x into sleep mode. Furthermore, when the digital key application 104 is not accepting user input for control execution, each authentication sensor 6x is put into sleep mode. This configuration, which selectively activates the authentication sensors 6x necessary for user authentication, can reduce power consumption compared to a configuration in which each authentication sensor 6x is always running.

[0126] Furthermore, the authentication sensors 6x used in the second and subsequent authentication steps are activated only if the primary authentication is successful. If the primary authentication fails, the sensors for secondary and tertiary authentication are not activated. This configuration allows for even greater power savings.

[0127] Furthermore, the above configuration allows for user authentication using multiple authentication sensors 6x in sequence. This multi-factor authentication configuration, which verifies the legitimacy / authenticity of the user, enhances the security of the vehicle hybrid.

[0128] Furthermore, in the above configuration, DKS3 manages the status of the authentication sensors 6x and selects the method / sensor to be used for multi-factor authentication using the available authentication sensors 6x. This configuration reduces the risk of instructing the system to implement an authentication method using an unusable authentication sensor 6x, thereby reducing the risk of compromising user convenience.

[0129] The DKS3 described above can update information on unavailable authentication sensors 6x based on the results of the authentication process. For example, the DKS3 registers unavailable authentication sensors 6x / authentication methods based on data received from the mobile device 1. With this configuration, the DKS3 can detect malfunctions that are difficult for the sensor diagnostic unit G2 to detect. Malfunctions that are difficult for the sensor diagnostic unit G2 to detect include, for example, antenna damage, pairing failure, protocol incompatibility, lens contamination, and diaphragm damage.

[0130] <Supplementary information regarding operation when the vehicle is outside of cellular coverage> The authentication ECU4 may have pre-registered authentication procedures and verification codes for when the vehicle Hv is located outside the cellular network coverage area (i.e., for out-of-range use). For convenience, the pre-configured authentication procedure for out-of-range use will be referred to as the out-of-range authentication procedure.

[0131] The authentication procedure for out-of-range operation is set by DKS3 at a predetermined time. For example, when the in-vehicle system 2 is online, DKS3 redesigns the authentication procedure for out-of-range operation when there is a change in the combination of available authentication methods, and distributes it to the authentication ECU 4 as an out-of-range verification package. The out-of-range verification package includes a verification code for each authentication step. The out-of-range verification package may be stored in the vehicle memory unit 45 or the like.

[0132] Furthermore, the authentication ECU 4 may change its operation depending on whether it is outside the cellular coverage area, as shown in Figure 16. That is, if the vehicle Hv is parked within the cellular coverage area (S61 YES), the authentication ECU 4 waits for instructions from DKS3, i.e., the reception of a verification package (S69). In other words, if the vehicle Hv is parked within the cellular coverage area, the authentication ECU 4 keeps each authentication sensor 6x in a sleep state until it receives instructions from DKS3.

[0133] On the other hand, if the vehicle Hv from DKS3 is parked outside of cellular coverage (S61 NO), the authentication ECU4 intermittently activates the first sensor of the out-of-range authentication procedure (S62). The activation cycle of the first sensor can be set to 10 seconds, 30 seconds, 1 minute, etc.

[0134] Then, as a result of activating the first sensor, an authentication code is obtained from the mobile device 1, and if the primary authentication is successful (S63 YES), the processes for secondary and tertiary authentication are executed in order according to the authentication procedure for when the device is out of range (S64).

[0135] If DKS3 receives a code issuance request from mobile device 1 while the vehicle Hv is outside the cellular coverage area (Figure 17 S71 NO), it generates an out-of-coverage package, which is an authentication package corresponding to the out-of-coverage authentication procedure, and delivers it to mobile device 1 (S72). If DKS3 receives a code issuance request from mobile device 1 and the vehicle Hv is within the cellular coverage area (S71 YES), it generates an authentication package according to the availability information for each authentication method registered in the vehicle DB32 and delivers it to mobile device 1 (S72). Mobile device 1 can display an operation guidance image corresponding to the authentication procedure specified in the received authentication package. The out-of-coverage package can also be called an emergency authentication dataset or an emergency device instruction set. Here, "emergency" refers to the case where the in-vehicle system 2 is outside the cellular coverage area. The notation "out-of-coverage" can be read as "emergency."

[0136] The above configuration was created with the following problem in mind: When the vehicle Hv is outside of cellular coverage, the authentication ECU4 cannot receive the verification package from DKS3. Therefore, the authentication ECU4 cannot activate the first sensor, which is triggered by the reception of the verification package. To address this problem, with the above configuration, when the vehicle Hv is outside of cellular coverage, the first sensor operates intermittently, and primary authentication is attempted. Thus, even when the vehicle Hv is outside of cellular coverage, such as in an underground parking lot or tunnel without wireless equipment, the user can access the vehicle Hv using the digital key app 104.

[0137] Incidentally, since the user, and by extension the mobile device 1, may move with the vehicle Hv, if the vehicle Hv is located outside the cellular coverage area, it is highly likely that the mobile device 1 is also located outside the cellular coverage area. Therefore, when DKS3 sends an out-of-coverage verification package to the vehicle Hv, it may also send a corresponding out-of-coverage authentication package to the mobile device 1. The out-of-coverage authentication package is a dataset containing data indicating the authentication procedure when outside the cellular coverage area and authentication codes for each authentication step. The out-of-coverage authentication package may be stored in the mobile storage unit 105.

[0138] Furthermore, the authentication ECU 4 does not need to have received the out-of-range verification package before entering an out-of-range cellular area. The authentication ECU 4, acting as the sensor control unit G1, may intermittently operate one or more specific authentication sensors 6x when the vehicle Hv is parked outside the cellular area. With this configuration, the authentication ECU 4 may be able to receive the authentication code transmitted from the mobile device 1 even without the out-of-range verification package. The results of the authentication process and control performed when the vehicle Hv is outside the cellular area may be reported to the DKS 3 by the authentication ECU 4 when the vehicle Hv returns to the cellular area.

[0139] <Supplementary information regarding the conditions for activating the semi-priority sensor> Furthermore, the first and second sensors are determined according to a pre-set priority. Therefore, if no abnormality is detected in the highest priority sensor, the first sensor will basically remain the highest priority sensor. The same applies to the second sensor. Therefore, the authentication ECU4 described above may activate the secondary priority sensor if no abnormality is detected in the highest priority sensor, provided that authentication using the highest priority sensor is successful. In other words, if no abnormality is detected in the highest priority sensor as the first sensor, the authentication ECU4 described above will not activate the second sensor until at least the authentication process using the first sensor is successful. Of course, if an abnormality is detected in the highest priority sensor, the authentication ECU4 described above may activate the secondary priority sensor as the first sensor.

[0140] With such an authentication ECU 4, the frequency of activation of the secondary priority sensor will be lower than the activation frequency of the highest priority sensor. Therefore, even if the secondary priority sensor is an authentication sensor 6x with relatively high power consumption, such as a camera 63, the overall power consumption of the system can be suppressed. Conversely, the highest priority sensor may be activated more frequently than the other authentication sensors 6x. It is preferable to select an authentication sensor 6x with low power consumption required for activation and maintaining a standby state, such as a BLE communication unit 61, as the highest priority sensor. Alternatively, from the perspective of improving user convenience, the authentication sensor 6x with the shortest activation time may be set as the highest priority sensor.

[0141] While embodiments of the present disclosure have been described above, the present disclosure is not limited to the embodiments described above. Various modifications described below are also included within the technical scope of the present disclosure, and further modifications can be made in various ways without departing from the gist of the invention. For example, the various supplements and modifications described below can be combined as appropriate without causing any technical inconsistencies. In addition, components having the same function as those described above may be denoted by the same reference numerals, and their descriptions may be omitted. Also, if only a part of the configuration is referred to, the above description may be applied to the other parts.

[0142] <Example (1)> The above describes an configuration in which the authentication ECU 4 puts the BLE communication unit 61 into sleep mode when not performing BLE authentication, but it is not limited to this configuration. The authentication ECU 4 may keep the BLE communication unit 61 running even after the completion of BLE authentication, as a path for direct communication with the mobile device 1. For example, the authentication ECU 4 may activate the BLE communication unit 61 upon successful reception of the verification package / successful initial authentication for out-of-range use, and then keep the BLE communication unit 61 active until control is complete / user operation is finished. In this configuration, the authentication ECU 4 may directly notify the mobile device 1 of the results of each authentication step via BLE communication. With this configuration, direct communication between the mobile device 1 and the authentication ECU 4 becomes possible, thus reducing cellular communication traffic. Furthermore, even if the vehicle Hv is parked outside of cellular coverage, the authentication ECU 4 can still notify the mobile device 1 of the results of each authentication step.

[0143] <Example (2)> The number of authentication steps may be changed according to the security level set by the user. If the security level is set to 1 (low), the authentication ECU4 may perform unlocking and other controls using one-step / one-factor authentication. If the security level is set to 2 (medium), the authentication ECU4 may perform unlocking and other controls using two-step / two-factor authentication. If the security level is set to 3 (high), the authentication ECU4 may perform control using three-step or four-step authentication. The number of security levels is not limited to three; it may be two-step, four-step or more.

[0144] The security level may be set by the system administrator. If the vehicle Hv is a service vehicle such as a shared car or rental car, the security level may be set by the service provider / administrator. The number of authentication steps may also be changed depending on the control content. The number of authentication steps for unlocking may be 2, while the number of authentication steps for locking may be 1. Locking and unlocking may be configured to be performed using only BLE authentication. If the number of authentication steps for unlocking is 2 or less, one-factor or two-factor authentication may be performed in addition when switching on the driving power supply.

[0145] <Variation (3)> The authentication ECU 4 may be configured to perform cellular authentication, which involves sending and receiving authentication codes via cellular communication. In the above embodiment, a method using a code image as image authentication was described, but the content of the image authentication may also be a user's facial image. In other words, the image authentication may be equivalent to facial authentication. Of course, the authentication ECU 4 may support both code image-based authentication and facial image-based authentication. Voice authentication is also not limited to a method using code tones, but may be so-called voice authentication that uses the characteristics of the user's voice for authentication. The authentication ECU 4 may be configured to perform an authentication method that uses the user's biometric information without using an authentication code.

[0146] Furthermore, the in-vehicle system 2 and the authentication ECU 4 may support fingerprint authentication, vein authentication, and ear acoustic authentication. The authentication sensor 6x for fingerprint authentication is a fingerprint reader that reads fingerprints. The fingerprint reader may be of any type: capacitive, optical, or ultrasonic. The authentication sensor 6x for vein authentication is a so-called vein scanner / vein sensor, which is a device that reads the vein pattern of the hand or fingers using infrared light. The authentication sensor 6x for ear acoustic authentication is a hearable device / hearing device that is worn on the ear. The hearable device may transmit the wearer's authentication result to the authentication ECU 4 via BLE communication. The ear acoustic authentication result from the hearable device may be transferred to the in-vehicle system 2 via the mobile device 1.

[0147] The authentication ECU 4 may be configured to temporarily adopt another authentication sensor 6x as the first sensor if the BLE communication unit 61, which is the first sensor, is malfunctioning. If a malfunction is detected in the default first sensor, the DKS 3 may guide the mobile device 1 to use the authentication sensor 6x with the second highest priority.

[0148] <Example (4)> The above assumes that DKS3 issues the encryption key, but this is not the only option. The authentication ECU4 may also have the encryption key issuance function. In that case, the authentication ECU4 may upload the static encryption key to DKS3.

[0149] The above describes an embodiment in which DKS3 automatically designs multi-factor authentication, but the digital key application 104 may also determine the multi-factor authentication procedure based on user operation and send it to DKS3. With this configuration, multi-factor authentication can be performed in a procedure according to the user's preference. In addition, DKS3 and the authentication ECU 4 may have several authentication patterns with different combinations of authentication methods pre-registered by the user as multi-factor authentication configurations. DKS3 / authentication ECU 4 may be configured to adopt the second pattern if a malfunction is detected in any of the multiple authentication sensors 6x used in the first pattern.

[0150] <Variation (5)> The mobile device 1 may send a code issuance request when a BLE communication link is established with the in-vehicle system 2. The authentication ECU 4 may also send a code acquisition request via BLE communication to the mobile device 1 when it detects a user operation on the vehicle Hv while a BLE communication link with the mobile device 1 is established. The code acquisition request is a signal requesting that an authentication package be obtained from the DKS3. The mobile device 1 may be configured to send a code issuance request to the DKS3 based on receiving a code acquisition request from the authentication ECU 4. Accordingly, the authentication ECU 4 may be configured to download a verification package from the DKS3 corresponding to the BLE communication target when it detects a user operation on the vehicle Hv while a BLE communication link with the mobile device 1 is established.

[0151] <Vehicles to which this disclosure applies> A hybrid vehicle (HV) is, for example, a vehicle owned by an individual. Of course, a hybrid vehicle may also be a company car owned by a company or an official vehicle owned by a public institution. Furthermore, a hybrid vehicle may be a vehicle used for rental or sharing services. A hybrid vehicle is, for example, an electric vehicle, more specifically a plug-in hybrid vehicle. The concept of an electric vehicle includes not only electric vehicles but also fuel cell vehicles and hybrid vehicles. This disclosure is also applicable to engine-powered vehicles. This disclosure is not limited to four-wheeled vehicles, but can be installed on a variety of vehicles that can travel on roads, such as trailers, two-wheeled vehicles, and three-wheeled vehicles. Motorized bicycles can also be included in the category of two-wheeled vehicles.

[0152] <Additional remark (1)> This disclosure also includes the following technical ideas. <Technical philosophy 1> A lock control device used in connection with a first authentication sensor that acquires information for authenticating a user in a predetermined manner, and a second authentication sensor that acquires information for authenticating the user in a manner different from that of the first authentication sensor, An abnormality detection unit (G2) that detects an abnormality in the first authentication sensor, The system includes a control unit (G1) that controls the operation of the first authentication sensor and the second authentication sensor, The control unit, A lock control device configured to not activate the second authentication sensor until, if no abnormality is detected in the first authentication sensor, the authentication process using the first authentication sensor is successful.

[0153] <Technical philosophy 2> The lock control device according to Technical Concept 1, wherein the control unit activates the second authentication sensor when an abnormality is detected in the first authentication sensor, or when the authentication process using the first authentication sensor is successful.

[0154] <Technical philosophy 3> A lock control device according to Technical Concept 1 or 2, used in connection with a communication unit (51) for wireless connection to a wide-area communication network, If no command set is received from a predetermined server via the wide-area communication network, the first authentication sensor and the second authentication sensor are set to a power-saving state. A lock control device that restores the first authentication sensor from the power-saving state to the normal state based on receiving the command set from the server via the wide-area communication network.

[0155] <Technical philosophy 4> A lock control device described in any one of Technical Concepts 1 to 3, which is used in connection with a communication unit (51) for wireless connection to a wide-area communication network, The system includes a communication control unit (G3) that controls the operation of the communication unit and determines whether the communication unit is in a state where it can connect to the wide-area communication network based on the signal reception status of the communication unit. The control unit, If the communication control unit determines that it is possible to connect to the wide-area communication network, it operates the first authentication sensor based on the receipt of a command set from a predetermined server via the wide-area communication network, A control device that intermittently operates the first authentication sensor if the communication control unit determines that the first authentication sensor is unable to connect to the wide-area communication network.

[0156] <Technical philosophy 5> An in-vehicle device (4) configured to authenticate a person attempting to access the vehicle using at least one of multiple authentication methods, A portable device (1) which is an information processing terminal carried by the user of the aforementioned vehicle, A vehicle digital key system comprising the aforementioned portable device and a server (3) configured to communicate data with the in-vehicle device, The in-vehicle device includes a control unit (G1) that controls the operation of multiple authentication sensors (6x) corresponding to each of the multiple authentication methods, The mobile device includes an operation response unit (F1) that transmits an operation start signal, which is a signal for initiating authentication based on user operation, to the server. The aforementioned server, A status management unit (H1) collects information on the unusable authentication method (unavailable method) and the usable authentication method (usable method) through communication with the in-vehicle device or the portable device, Based on receiving the operation start signal from the mobile device, a selection unit (H21) selects an adopted authentication method from among the available methods, which is the authentication method to be actually used for the authentication process. The system includes a transmission processing unit (H25) that transmits a set of instructions containing information about at least one of the adopted methods selected by the selection unit to the in-vehicle device, The control unit, A vehicle digital key system configured to activate the authentication sensor corresponding to the adopted method shown in the instruction set, while not activating the authentication sensor corresponding to the non-adopted method, which is an authentication method that is not the adopted method.

[0157] <Technical philosophy 6> A digital key system for a vehicle according to technical concept 5, which authenticates the user based on the success of multi-stage authentication including multiple authentication steps, The server includes a sequence determination unit (H22) that determines the adopted method to be used in each of the multiple authentication steps that constitute the multi-factor authentication, The transmission processing unit transmits the instruction set indicating the adoption method to be used for each authentication step, determined by the sequence determination unit, to the in-vehicle device. The control unit is configured to activate the authentication sensor used in the first authentication step, while keeping the other authentication sensors inactive.

[0158] <Technical philosophy 7> The vehicle digital key system according to technical concept 6, wherein the control unit activates the authentication sensor used in the second authentication step based on the success of the first authentication step.

[0159] <Technical philosophy 8> Based on the failure of the authentication step using the first authentication sensor, which is one of the multiple authentication sensors, the portable device sends an error message to the server indicating an abnormality of the first authentication sensor. A digital key system for a vehicle according to technical idea 6 or 7, wherein the server is configured to set the authentication method using the first authentication sensor to the disabled method based on the receipt of the error message from the mobile device.

[0160] <Technical philosophy 9> Based on the failure of the authentication step using the first authentication sensor, which is one of the multiple authentication sensors, the portable device sends an error message to the server indicating an abnormality of the first authentication sensor. Based on receiving the error message from the mobile device, the server A vehicle digital key system according to technical concept 6 or 7, configured to transmit the set of instructions indicating the multi-step authentication procedure without using the first authentication sensor to the in-vehicle device.

[0161] <Technical Thought 10> The aforementioned server, Based on the communication status with the in-vehicle device, determine whether the in-vehicle device is in a state where it can communicate with the server. If the in-vehicle device is unable to communicate with the server, it will transmit an emergency authentication dataset showing a pre-configured authentication procedure to the mobile device. A vehicle digital key system according to any one of technical ideas 6 to 9, wherein the portable device is configured to display on a display (11) an image that guides the user through the authentication process based on the emergency authentication dataset.

[0162] <Technical Thought 11> The in-vehicle device includes a communication control unit (G3) that controls the operation of a communication unit (51) for wireless connection to a wide-area communication network, and determines whether the communication unit is in a state where it can connect to the wide-area communication network based on the signal reception status of the communication unit. The vehicle digital key system according to any one of technical concepts 6 to 10, wherein the control unit is configured to intermittently operate some or all of the multiple authentication sensors when the communication control unit determines that it is not possible to connect to the wide-area communication network.

[0163] <Additional remarks (2)> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowchart and the execution order of the processes can be changed as appropriate. Furthermore, the devices, systems, and methods described in this disclosure may be implemented by a dedicated computer comprising a processor programmed to execute one or more functions embodied by a computer program. The devices and methods described in this disclosure may be implemented using dedicated hardware logic circuits. The devices and methods described in this disclosure may be implemented by one or more dedicated computers comprising a combination of a processor that executes a computer program and one or more hardware logic circuits. As the processor (processing core), a CPU, MPU, GPU, DFP (Data Flow Processor), etc., can be used. Some or all of the functions of DKS3 / Certification ECU4 / Portable Device 1 may be implemented using an SoC (System-on-Chip), IC (Integrated Circuit), or FPGA (Field-Programmable Gate Array). The concept of IC also includes ASIC (Application Specific Integrated Circuit).

[0164] Furthermore, the computer program only needs to be stored on a computer-readable non-transitory tangible storage medium as instructions executed by the computer. Suitable storage media for the program include HDDs (Hard-disk drives), SSDs (Solid State Drives), flash memory, etc. The scope of this disclosure also includes the form of a program for causing the computer to function as DKS3 / Authentication ECU4 / Portable Device 1, and the non-transitory tangible storage medium such as semiconductor memory on which this program is stored. [Explanation of Symbols]

[0165] 1 Mobile device, 2 In-vehicle system, 3 DKS (server), 11 Display, 30 Data processing unit, 301 Server processor, 4 Authentication ECU (in-vehicle device), 41 Authentication processor, 51 Cellular communication unit (communication unit), 6x Authentication sensors, 61 BLE communication unit, 62 NFC communication unit, 63 Camera, 64 Microphone, F1 Operation response unit, F3 Operation guidance unit, G1 Sensor control unit (control unit), G2 Sensor diagnostic unit (anomaly detection unit), G3 Communication control unit, G4 Authentication processing unit, H1 Status management unit, H21 Selection unit, H22 Sequence determination unit, H25 Distribution processing unit (transmission processing unit)

Claims

1. A lock control device is used in connection with a first authentication sensor that acquires information for authenticating a user in a predetermined manner, and a second authentication sensor that acquires information for authenticating the user in a manner different from that of the first authentication sensor, and is also used in connection with a communication unit (51) for wireless connection to a wide-area communication network, An abnormality detection unit (G2) for detecting an abnormality in the first authentication sensor, A control unit (G1) that controls the operation of the first authentication sensor and the second authentication sensor, The system includes a communication control unit (G3) that controls the operation of the communication unit and determines whether the communication unit is in a state where it can connect to the wide-area communication network based on the signal reception status of the communication unit. The control unit, If no abnormality is detected in the first authentication sensor, the system is configured not to activate the second authentication sensor until the authentication process using the first authentication sensor is successful, and If the communication control unit determines that it is possible to connect to the wide-area communication network, it operates the first authentication sensor based on the receipt of a set of commands from a predetermined server via the wide-area communication network instructing the start of the process for authenticating the user, A lock control device that intermittently operates the first authentication sensor if the communication control unit determines that the first authentication sensor is unable to connect to the wide-area communication network.

2. A lock control device is used in connection with a first authentication sensor that acquires information for authenticating a user in a predetermined manner, and a second authentication sensor that acquires information for authenticating the user in a manner different from that of the first authentication sensor, and is also used in connection with a communication unit (51) for wireless connection to a wide-area communication network, An abnormality detection unit (G2) for detecting an abnormality in the first authentication sensor, The system includes a control unit (G1) that controls the operation of the first authentication sensor and the second authentication sensor, The control unit, If no abnormality is detected in the first authentication sensor, the system is configured not to activate the second authentication sensor until the authentication process using the first authentication sensor is successful, and If no instruction set has been received from a predetermined server via the wide-area communication network instructing the start of the process for authenticating the user and specifying the procedure for executing the authentication process, the first authentication sensor and the second authentication sensor are set to a power-saving state, A lock control device that, upon receiving the command set from the server via the wide-area communication network, maintains the second authentication sensor in the power-saving state while returning the first authentication sensor from the power-saving state to the normal state.

3. The lock control device according to claim 1 or 2, wherein the control unit activates the second authentication sensor when an abnormality is detected in the first authentication sensor, or when the authentication process using the first authentication sensor is successful.

4. A sensor diagnostic unit (G2) that communicates with the first authentication sensor and the second authentication sensor to determine whether the first authentication sensor and the second authentication sensor are functioning properly, The system further comprises a communication control unit (G3) that controls communication with the server via the communication unit, The lock control device according to claim 2, wherein the communication control unit is configured to transmit a sensor status report, which is a communication packet indicating whether or not the first authentication sensor and the second authentication sensor are functioning normally, to the server using the communication unit.

Images