Digital key system for vehicle and method for managing digital key for vehicle

Abstract

To provide a vehicle digital key system, vehicle digital key management method, vehicle device, and mobile terminal that have higher security.SOLUTION: A server issues a service key for using a designated vehicle and a plurality of one-time authentication keys and delivers them to a mobile terminal based on a request from the mobile terminal. The one-time authentication keys are disposable authentication keys generated based on the service key, and have expiration dates set. The one-time authentication keys are consumed when a vehicle device authenticates the mobile terminal as a communication partner. The mobile terminal replaces the one-time authentication key held by itself as needed.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a technology for generating and distributing a digital key, which is key information for locking / unlocking a vehicle. [Background technology]

[0002] Patent Document 1-2 discloses a system that distributes key information issued by a vehicle administrator to a mobile terminal and an in-vehicle unit, which are devices carried by a user, and enables the mobile terminal to be used as an electronic key for the vehicle. As an example of the mobile terminal, a communication terminal capable of connecting to the Internet, such as a smartphone, is assumed. If a mobile terminal such as a smartphone can be used as a vehicle key in this way, the user will no longer need to carry a dedicated electronic key when using the vehicle, which is more convenient. Patent Document 1-2 also mentions a configuration in which the vehicle owner and other people (guests) have different vehicle use authorizations.

[0003] There are various methods for verifying the validity of a device connected to a vehicle. For example, Patent Document 3 discloses a method for authenticating a device connected to a vehicle using an authentication code generated by combining a variable code, which is a dynamically changed parameter, with fixed key information. The contents of these prior art documents can be incorporated by reference as explanations of technical elements in this specification. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6635102 [Patent Document 2] Special Publication No. 2019-536329 [Patent Document 3] Patent No. 6078686 Summary of the Invention [Problem to be solved by the invention]

[0005] In a system that enables the use of a vehicle using electrical key information, there is a demand for stronger security. One assumed configuration that meets this demand is a configuration in which a mobile terminal generates a one-time authentication key, which is a disposable authentication code, based on a unique service key, and uses the one-time authentication key to prove the legitimacy to a vehicle device. However, this assumed configuration increases the processing load of the mobile terminal. A variety of devices with different processing capabilities are assumed as mobile terminals. It is preferable to provide the functions of the mobile terminal as simply as possible so that it can operate even on devices with low computing capabilities.

[0006] As a further assumed configuration for simplifying the functions of the mobile terminal, a one-time authentication key generating function is provided in a server, and the mobile terminal acquires and uses the one-time authentication key from the server in real time when communicating with the vehicle. However, the mobile terminal is not always in a state where it can communicate. If the mobile terminal is out of communication range, it cannot acquire the one-time authentication key from the server, and the vehicle cannot be used. In other words, the convenience for the user may be reduced.

[0007] The present disclosure has been made based on the above considerations or viewpoints, and one of its purposes is to provide a vehicle digital key system and a vehicle digital key management method that can achieve both security and user convenience. Law The purpose is to provide. [Means for solving the problem]

[0008] Disclosed herein 1. The digital key system for a vehicle includes a vehicle device (4) that is mounted on a vehicle and used, a mobile terminal (1) that is an information processing terminal carried by a user, and a server (3) that generates a service key unique to each mobile terminal as key information for using the vehicle and distributes the service key directly or indirectly to each of the mobile terminal and the vehicle device, The vehicle device and the mobile terminal are configured to be able to communicate data with each other by short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, The server, based on a request from the mobile device, By combining different variable codes with the service key, multiple disposable keys with expiration dates can be obtained. Generate a one-time authentication key, Along with information showing the variation code The mobile device receives a one-time authentication key from the server. Also, information indicating the variable code used to generate the one-time authentication key. and storing the received message in a predetermined terminal side storage device (105). , Wa Based on the expiration date of each one-time authentication key, a part or all of the one-time authentication keys stored in the terminal side storage device are replaced. and transmitting a variable code to the vehicular device on condition that a short-range wireless communication link has been established between the vehicular device and the vehicular device. The vehicular device includes a vehicle-side storage device (45) for storing a service key for the portable terminal issued by the server, and generates a one-time authentication key by combining the service key for the portable terminal stored in the vehicle-side storage device with the variable code received from the portable terminal, and determines the authenticity of the portable terminal using the generated one-time authentication key. It is structured as follows. A second digital key system for a vehicle included in the present disclosure is a digital key system for a vehicle including a vehicle device (4) mounted on and used in a vehicle, a mobile terminal (1) which is an information processing terminal carried by a user, and a server (3) which generates a service key unique to each mobile terminal as key information for using the vehicle and distributes the service key directly or indirectly to each of the mobile terminal and the vehicle device, the vehicle device and the mobile terminal being configured to be able to communicate data with each other by short-range wireless communication which is wireless communication conforming to a predetermined short-range wireless communication standard, the server generating multiple disposable one-time authentication keys based on the service key based on a request from the mobile terminal and distributing them to the mobile terminal with a validity period, the mobile terminal transmitting the service key to the mobile terminal, and the server transmitting the service key to the mobile terminal. and replacing a part or all of the one-time authentication keys stored in the terminal-side storage device based on an expiration date for each one-time authentication key. The vehicle device is configured to obtain a plurality of one-time authentication keys issued to the mobile terminal from the mobile terminal or the server and store them in the vehicle-side storage device (45), exchange an adjustment message with the mobile terminal via short-range wireless communication to match a one-time authentication key to be used in the authentication process from among the plurality of one-time authentication keys issued by the server, and determine the authenticity of the mobile terminal by using the one-time authentication key identified based on the adjustment message.

[0009] According to the above configuration, a one-time authentication key generated based on a service key unique to each mobile terminal is used to authenticate the mobile terminal (and thus the user), thereby improving security compared to a configuration in which fixed key information is used to authenticate the mobile terminal. Furthermore, the mobile terminal is controlled to hold multiple one-time authentication keys. Therefore, even if the mobile terminal is in an environment in which it cannot communicate with the server, the risk that the user will not be able to use the vehicle can be reduced. In addition, according to the above configuration, the one-time authentication key held by the mobile terminal is periodically replaced based on the expiration date. According to this configuration, the valid one-time authentication key is changed over time, thereby further strengthening security.

[0010] In addition, 1. The vehicle digital key management method includes a mobile terminal (1) which is an information processing terminal carried by a user, The device is configured to be capable of mutual data communication with the mobile terminal through short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, and A vehicle digital key management method executed by a vehicle device (4) mounted on a vehicle and used in the vehicle, and a server (3) that generates a service key unique to each mobile terminal as key information for using the vehicle, comprising: The vehicle device includes a vehicle-side storage device (45) that holds a service key for the portable terminal, The server receives the service key of the mobile terminal based on the request from the mobile terminal. By combining multiple different variable codes, , It has an expiration date and Disposable Multiple Generate a one-time authentication key, Along with information showing the variation code Delivery to mobile devices , mobile The mobile device receives a one-time authentication key from the server. Also, information indicating the variable code used to generate the one-time authentication key.and storing the one-time authentication key in a predetermined terminal-side storage device (105); and the mobile terminal periodically replaces a part or all of the one-time authentication keys stored in the terminal-side storage device based on the expiration date of each one-time authentication key; transmitting a variation code to the vehicular device from the portable terminal on condition that a short-range wireless communication link is established between the portable terminal and the vehicular device; The vehicle device includes: generating a one-time authentication key by combining a service key of the portable terminal stored in the vehicle-side storage device with a variable code received from the portable terminal; The vehicle device includes: Generate and determining the authenticity of the portable terminal using the one-time authentication key. A second vehicle digital key management method included in the present disclosure is a vehicle digital key management method executed by a mobile terminal (1) which is an information processing terminal carried by a user, a vehicle device (4) which is configured to be capable of mutual data communication with the mobile terminal by short-range wireless communication which is wireless communication conforming to a predetermined short-range wireless communication standard and which is mounted on and used in a vehicle, and a server (3) which generates a service key unique to each mobile terminal as key information for using the vehicle, in which the server generates multiple disposable one-time authentication keys based on the service key of the mobile terminal in response to a request from the mobile terminal, and distributes the disposable one-time authentication keys with expiration dates to the mobile terminal, and the mobile terminal receives the one-time authentication keys from the server. the vehicle device receiving the one-time authentication keys issued to the portable terminal from the portable terminal or the server and storing them in a vehicle-side storage device (45); the vehicle device exchanging an adjustment message with the portable terminal via short-range wireless communication to match a one-time authentication key to be used for the authentication process from among the one-time authentication keys issued by the server; and the vehicle device determining the authenticity of the portable terminal by using the one-time authentication key identified based on the adjustment message.

[0011] According to the above method, security can be further strengthened by the same effect as that of a digital key system for a vehicle.

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

[0017] [Figure 1] FIG. 1 is a diagram showing an overall view of a digital key system for a vehicle. [Diagram 2] FIG. 2 is a block diagram showing a configuration of a mobile terminal. [Diagram 3] FIG. 4 is a functional block diagram of a terminal control unit. [Figure 4] FIG. 2 is a block diagram showing the configuration of a dedicated key. [Diagram 5] FIG. 2 is a block diagram showing the configuration of a digital key server. [Figure 6] FIG. 4 is a diagram illustrating an example of types of data stored in a vehicle database. [Figure 7] FIG. 4 is a diagram illustrating an example of types of data stored in a user database. [Figure 8] FIG. 2 is a functional block diagram of a data processing unit. [Figure 9] FIG. 2 is a diagram for explaining the relationship between a vehicle, an owner key, and a guest key. [Figure 10] FIG. 1 is a block diagram showing a configuration of an in-vehicle system. [Figure 11] FIG. 2 is a functional block diagram of an authentication ECU. [Figure 12] FIG. 2 is a diagram for explaining an overall picture of processing related to issuing and registering a service key. [Figure 13] FIG. 11 is a sequence diagram illustrating an owner key issuing process. [Figure 14] FIG. 4 is a sequence diagram for explaining a process for registering an owner key in a vehicle. [Figure 15] 13 is a diagram showing an example of a display screen of a mobile terminal for registering an owner key to a vehicle. FIG. [Figure 16] 6 is a diagram illustrating an example of a display screen of a portable terminal for communication connection with a vehicle. [Figure 17] FIG. 11 is a sequence diagram illustrating a guest key issuing process. [Figure 18] 13 is a diagram showing an example of information to be included in a guest key issue request signal. [Figure 19] 11 is a diagram showing an example of information to be included in a terminal registration package transmitted to a guest terminal. FIG. [Figure 20] FIG. 11 is a sequence diagram illustrating a process of registering a guest key in a vehicle. [Figure 21] FIG. 13 is a diagram showing an example of a display screen of a portable terminal for registering a guest key in a vehicle. [Figure 22] 5 is a flowchart for explaining an example of operation of the authentication ECU during parking. [Diagram 23] 10 is a sequence diagram showing an example of a process in which an authentication ECU authenticates a mobile terminal; [Figure 24] 11 is a sequence diagram showing another example of a process in which the authentication ECU authenticates a mobile terminal. FIG. [Diagram 25] 11 is a sequence diagram of a process in which a mobile terminal replenishes a one-time authentication key. FIG. [Figure 26] 11 is a sequence diagram of a process in which the mobile terminal replaces a one-time authentication key stored in a key information storage unit. FIG. [Figure 27]11 is a sequence diagram for explaining the correction of the ECU time and the deletion of the guest key based on the expiration date, which are performed by the authentication ECU. FIG. [Figure 28] FIG. 13 is a diagram for explaining an overall picture of a sequence for deleting a service key. [Figure 29] FIG. 11 is a sequence diagram showing the interaction between the mobile terminal and the DKS when deleting an owner key. [Diagram 30] 11 is a sequence diagram showing an interaction between an owner terminal and an authentication ECU when deleting an owner key. FIG. [Diagram 31] FIG. 11 is a sequence diagram showing the interaction between the mobile terminal and the DKS when deleting a guest key. [Diagram 32] FIG. 11 is a sequence diagram showing an interaction between a mobile terminal and an authentication ECU when deleting a guest key. [Diagram 33] FIG. 11 is a sequence diagram showing a process flow when deleting a service key via an in-vehicle HMI. [Diagram 34] 13 is a diagram for explaining an example of the operation of the DKS when an issue-related guest key is deleted. FIG. [Diagram 35] 11 is a flowchart for explaining the operation of the DKS when the model of the mobile terminal possessed by the owner is changed. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] The vehicle digital key system Sys of the present disclosure will be described below 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 2 by distributing a service key, which is an electronic key for using the vehicle Hv, to a mobile terminal 1. As shown in Fig. 1, the vehicle digital key system Sys includes a mobile terminal 1, a dedicated key 2, a digital key server (DKS: Digital Key Server) 3, and an in-vehicle system 7 mounted on the vehicle Hv. The in-vehicle system 7 includes an authentication ECU 4. ECU is an abbreviation for Electronic Control Unit and refers to an electronic control device.

[0019] <Introduction> In the following description, the vehicle Hv is, as an example, a vehicle owned by an individual. Of course, the vehicle Hv may be a company car owned by a company organization or an official vehicle owned by a public institution. Furthermore, the vehicle Hv may be a vehicle provided for a rental service (a so-called rental car) or a vehicle provided for a car sharing service (a so-called shared car). The vehicle Hv may be a vehicle provided for a passenger transportation service, such as a robot taxi.

[0020] The vehicle Hv is, for example, an engine vehicle. Of course, the vehicle Hv may be a hybrid vehicle or an electric vehicle. The engine vehicle here refers to a vehicle equipped with only an engine as a power source, and the hybrid vehicle refers to a vehicle equipped with an engine and a motor as a power source. The electric vehicle refers to a vehicle equipped with only a motor as a drive source. The power source for running in this disclosure is a power source for running the vehicle Hv, and refers to an ignition power source when the vehicle is an engine vehicle. When the vehicle Hv is an electric vehicle or a hybrid vehicle, the system main relay corresponds to the power source for running. The present disclosure is not limited to four-wheeled vehicles, and can be installed in various vehicles that can run on roads, such as trailers, two-wheeled vehicles, and three-wheeled vehicles. A motorized bicycle can also be included in two-wheeled vehicles.

[0021] In the following, the vehicle digital key system Sys will be described mainly for one vehicle Hv, but there may be multiple vehicles managed by the DKS 3. Also, one owner may own multiple vehicles Hv.

[0022] The term "user" in this disclosure refers to a user of the services provided by the vehicle digital key system Sys. A person who has created an account for using the services provided by the vehicle digital key system Sys, in other words, an owner of a mobile terminal 1 in which a digital key application 104 (described later) is installed, corresponds to a user.

[0023] Various sequence diagrams and flowcharts in the present disclosure are merely examples. The number of steps, processing order, execution conditions, etc. included in each sequence diagram / flowchart may be changed as appropriate.

[0024] <Overall Overview> The mobile terminal 1 is a general-purpose information processing terminal that can be owned / carried by each of multiple users. The mobile terminal 1a shown in Fig. 1 indicates the mobile terminal 1 owned by the owner of the vehicle Hv. The mobile terminal 1b is, for example, a mobile terminal 1 owned by the owner's family, and the mobile terminal 1c is a mobile terminal 1 owned by the owner's friend. A device ID, which is unique identification information for each mobile terminal 1, is assigned to each mobile terminal 1.

[0025] The device ID may be, for example, a device address or a universally unique identifier (UUID). A device address in Bluetooth (registered trademark) may be expressed in 48 bits. A UUID may be expressed in 128 bits. The device address may be a fixed public address or a random address. The public address corresponds to a Media Access Control (MAC) address in Ethernet (registered trademark). Alternatively, the device ID may be a random number determined when installing the digital key application 104 described later.

[0026] The mobile terminal 1 is configured to be able to communicate data with the DKS 3 via a wireless base station 8 and a wide area communication network 9. The wireless base station 8 shown in FIG. 1 may be, for example, a base station for cellular communication, or an access point for Wi-Fi (registered trademark). An access point is communication equipment that forms a wireless LAN (Local Area Network). The concept of an access point can include a router as well as a roadside device. The wide area communication network 9 is, for example, the Internet. For the equipment that forms the wide area communication network 9, the mobile terminal 1 corresponds to user equipment (UE: User Equipment).

[0027] Cellular communication refers to wireless communication conforming to standards such as 4G and 5G. Various standards such as IEEE802.11n, IEEE802.11ac, and IEEE802.11ax (so-called Wi-Fi6) can be adopted as Wi-Fi standards. In this disclosure, wireless communication conforming to the Wi-Fi (registered trademark) standard is also referred to as Wi-Fi communication. Communication between the mobile terminal 1 and the DKS 3 is performed by encrypted cellular communication or Wi-Fi communication.

[0028] The DKS 3 is a server arranged outside the vehicle Hv. The DKS 3 is configured to be connectable to a wide area communication network 9. The DKS 3 can communicate with the mobile terminal 1 via the wide area communication network 9. Based on a request from the mobile terminal 1, the DKS 3 issues a service key for using the vehicle Hv to a specific user.

[0029] Further, the in-vehicle system 7 and the mobile terminal 1 are configured to be capable of short-distance wireless communication. Here, short-distance wireless communication refers to communication conforming to a predetermined short-distance wireless communication standard in which the actual communication distance is, for example, 5 m to 30 m, and at most about 100 m. As the short-distance wireless communication standard, for example, BLE (Bluetooth Low Energy), Bluetooth Classic, Wi-Fi (registered trademark), ZigBee (registered trademark), etc. can be adopted. As the short-distance wireless communication method, UWB-IR (Ultra Wide Band - Impulse Radio) can also be adopted. In this embodiment, as an example, the in-vehicle system 7 and the mobile terminal 1 are configured to be capable of BLE communication, which is wireless communication conforming to the BLE standard, and the operation of each part will be described. In the following, the description of BLE communication can be replaced with short-distance wireless communication. Details of the communication method related to communication connection and encrypted communication are implemented by a sequence defined in the BLE standard.

[0030] In the following, a case will be described in which the in-vehicle system 7 is set to act as a master in communication with the mobile terminal 1. The mobile terminal 1 acts as a slave. A slave in BLE communication is a device that transmits an advertising signal intermittently and transmits and receives data based on a request from the master. A slave is also called a peripheral. A master controls the communication connection state and communication timing with the slave. A master is also called a central. As another aspect, the mobile terminal 1 may be set to operate as a master in communication with the in-vehicle system 7.

[0031] The in-vehicle system 7 includes a BLE communication unit 57 for performing BLE communication and an authentication ECU 4. The authentication ECU 4 is one of the ECUs constituting the in-vehicle system 7. The authentication ECU 4 corresponds to a vehicle device. The authentication ECU 4 performs an automatic authentication process by wireless communication with a mobile terminal 1 having a service key. Then, on condition that the authentication is successful, a passive entry / passive start function is provided that performs vehicle control according to the position of the user relative to the vehicle Hv. The vehicle control here includes locking / unlocking the doors, turning the power on / off, starting the engine, and the like. Note that the mobile terminal 1 corresponds to the user, so authenticating the mobile terminal 1 corresponds to authenticating the user.

[0032] <Service key description> The service key differs for each mobile terminal 1. For example, the service key is a code that is determined according to the device ID and differs for each mobile terminal 1. The service key can be a string of alphanumeric characters having a predetermined number of characters. For example, the DKS3 adopts, as the service key, an output value obtained by adding a random number having a predetermined length to the device ID and inputting the resultant value into a predetermined hash function. As the hash function, various functions such as FNV132, FNV164, MD-5, SHA-1, SHA-256, and SHA-512 can be adopted. The function used to generate the service key can be appropriately selected according to the number of bits (output length) required as the service key.

[0033] The service key can be expressed as a bit string having a length of 8 bits or more. The longer the service key, the stronger its security is, which is preferable. The service key can be expressed as, for example, 16 bytes, 24 bytes, 27 bytes, etc. As an example, the service key is assumed to be composed of 24 bytes here. If the service key is configured to be 27 bytes or less, the service key can be accommodated in one BLE encrypted communication packet.

[0034] It is preferable that the service key has a different value for each combination of the vehicle Hv and the mobile terminal 1. For example, the service key may be the output value of a predetermined hash function whose input value is a combined value of the vehicle ID and the device ID. The vehicle ID is a unique identification number assigned to each vehicle. For example, the vehicle identification code (VIN: Vehicle Identification Number) can be used as the vehicle ID.

[0035] Furthermore, the service key may be an output value obtained by inputting data obtained by concatenating the vehicle ID and device ID with a value corresponding to the epoch seconds at which the issuance request was received into a predetermined hash function. Furthermore, it is not necessary to use a hash function to generate the service key. The service key may be a value obtained by multiplying, adding, or concatenating the device ID with the vehicle ID. Other materials such as a password set by the user may also be used as the material for the service key. For example, the service key may be a value obtained by inputting a password of a predetermined number of characters registered by the user into a predetermined hash function.

[0036] There are multiple types of service keys. Service keys can be broadly divided into owner keys and guest keys. An owner key is a service key issued to the owner of a vehicle Hv, and generally has all authority regarding the use of the vehicle Hv. The owner key has all authority regarding the use of the vehicle Hv, such as turning the driving power on and off, locking and unlocking the doors, and remote operation, and also has the authority to issue service keys for other users. Furthermore, an owner key is basically an unlimited service key with no expiration date set.

[0037] A guest key is a service key for guests, and is basically issued by the owner. Here, a guest refers to a user other than the owner. A guest key is a service key with more limited authority than an owner key, and an expiration date is also set.

[0038] More specifically, guest keys are divided into guest keys with issuance rights, which have the authority to issue other guest keys, and guest keys without issuance rights, which do not have the authority to issue other guest keys. As an example of a use case, a guest key with issuance rights may be issued to the owner's family upon request from the owner. Also, a guest key without issuance rights may be issued to the owner's friends / acquaintances.

[0039] Hereinafter, the portable terminal 1 possessed by the owner, in other words, the portable terminal 1 in which the owner key is stored, will be referred to as the owner terminal. The portable terminal 1 possessed by the guest, in other words, the portable terminal 1 in which the guest key is stored, will be referred to as the guest terminal. Furthermore, among the guest terminals, the portable terminal 1 to which a guest key with issuance authority has been granted will be referred to as the guest terminal with issuance authority, and the portable terminal 1 to which a guest key without issuance authority has been granted will be referred to as the guest terminal without issuance authority. In the example shown in FIG. 1, the portable terminal 1a corresponds to the owner terminal, and the portable terminal 1b corresponds to the guest terminal with issuance authority. Furthermore, the portable terminal 1c corresponds to the guest terminal without issuance authority.

[0040] If the owner terminal is regarded as a parent, the mobile terminal 1 having a guest key issued by the owner terminal corresponds to a child of the owner terminal. Also, the mobile terminal 1 having a guest key issued by a terminal with issuing authority corresponds to a grandchild of the owner terminal. The authority of each guest key is determined by the issuer. The authority of the guest key is set to be smaller (narrower) than that of the issuer. However, as another aspect, the vehicle digital key system Sys may be configured to be able to issue a guest key having the same authority as the issuer. The DKS3 issues a new guest key based on a request from the owner terminal or a guest terminal with issuing authority. The type and authority setting of the newly issued service key are specified by the issuer. For example, when the DKS3 issues a new guest key based on a request from the owner terminal, it determines whether the guest key is a guest key with issuing authority or a guest key without issuing authority based on a signal received from the owner terminal. Note that the guest key with issuing authority is restricted so that only a guest key without issuing authority can be issued.

[0041] <Mobile device configuration and functions> Here, the configuration / functions of the mobile terminal 1 will be described with reference to Fig. 2. For example, a smartphone, a tablet terminal, a wearable device, etc. can be adopted as the mobile terminal 1. A wearable device is a device that is worn on the user's body and can be of various shapes, such as a wristband type, a watch type, a finger ring type, a glasses type, or an earphone type.

[0042] The mobile terminal 1 includes a terminal control unit 10, a display 11, a touch panel 12, an inertial sensor 13, a biometric authentication device 14, a near-field communication unit 15, a BLE communication unit 16, a cellular communication unit 17, and a Wi-Fi communication unit 18.

[0043] The terminal control unit 10 is a module that controls the operation of the entire mobile terminal 1. The terminal control unit 10 is configured as a computer including, for example, a terminal processor 101, a RAM (Random Access Memory) 102, a storage 103, and the like. The terminal processor 101 is hardware (in other words, a calculation core) for arithmetic processing that is combined with the RAM 102. The terminal processor 101 is, for example, a CPU (Central Processing Unit). The terminal processor 101 can be called a user processor or a UE processor because it is a processor used in a device used by a user. The terminal processor 101 accesses the RAM 102 to execute various processes for realizing the functions of each functional unit described later. The RAM 102 is a volatile storage medium. The storage 103 is configured to include a non-volatile storage medium such as a flash memory.

[0044] The digital key application 104 is application software for securely performing user authentication, acquisition / storage of a service key, communication with the in-vehicle system 7, etc. The digital key application 104 is installed in the storage 103, for example.

[0045] The terminal control unit 10 is configured to be able to communicate with each of the display 11, the touch panel 12, the inertial sensor 13, the biometric authentication device 14, the near-field communication unit 15, the BLE communication unit 16, the cellular communication unit 17, and the Wi-Fi communication unit 18. The functions of the terminal control unit 10 will be described later.

[0046] The display 11 is, for example, a liquid crystal display or an organic EL display. The display 11 displays an image in response to an input signal from the terminal control unit 10. The touch panel 12 is a capacitive touch panel and is laminated on the display 11. The touch panel 12 and the display 11 correspond to an interface for a user to register key information in the mobile terminal 1 and pair the mobile terminal 1 with the in-vehicle system 7. The touch panel 12 is an input device. A signal output by the touch panel 12 corresponds to a user's operation on the mobile terminal 1. Hereinafter, the output signal of the touch panel 12 will also be referred to as an operation signal.

[0047] The inertial sensor 13 is a sensor that detects an inertial force acting on the portable terminal 1. An acceleration sensor or a gyro sensor corresponds to the inertial sensor 13. The output (detection data) of the inertial sensor 13 is input to the terminal control unit 10.

[0048] The biometric authentication device 14 is a device that authenticates a user using, for example, the user's fingerprint or face image. The biometric authentication device 14 may be a device that authenticates a user using a vein pattern of a hand or finger or an iris pattern. The biometric authentication device 14 may also be a device that performs authentication using characteristics of a spoken voice, such as a voiceprint. The user authentication result is provided to the terminal control unit 10.

[0049] The near-field communication unit 15 is a communication module for performing near-field communication, which is wireless communication conforming to the NFC (Near Field Communication) standard. The near-field communication here refers to communication in which the communicable distance is about several centimeters to several tens of centimeters. The near-field communication corresponds to a communication method in which the communicable distance is sufficiently shorter than that of BLE communication. The communication method in which the communicable distance is sufficiently shorter refers to a communication method in which the communication distance is one tenth or less. As a specific communication standard for realizing the near-field communication, various standards such as ISO / IEC 14443 and ISO / IEC 18092 can be adopted. The near-field communication may conform to the Type-F standard, or may conform to the Type-A or Type-B standard. The Type-F standard corresponds to the so-called FeliCa (registered trademark). In the mobile terminal 1, the near-field communication unit 15 is an optional element and may be omitted.

[0050] The BLE communication unit 16 is a communication module for performing BLE communication. The BLE communication units 16 and 57 correspond to short-range communication units. The cellular communication unit 17 is a communication module for performing cellular communication. The cellular communication unit 17 is a communication module in charge of a data link layer and a physical layer in a wireless communication protocol such as LTE. The cellular communication unit 17 provides the terminal control unit 10 with information indicating the connection status with the wireless base station 8, for example, whether or not it is outside the communication range.

[0051] The Wi-Fi communication unit 18 is configured to be capable of performing Wi-Fi communication. The Wi-Fi communication unit 18 is configured to be connectable to the wide area communication network 9 via an access point. Wi-Fi is a type of predetermined wireless LAN standard. Therefore, the Wi-Fi communication unit 18 corresponds to a wireless LAN module, which is a communication module for performing communication in accordance with the wireless LAN standard.

[0052] The various communication modules include an antenna capable of transmitting and receiving radio waves in a frequency band to be transmitted and received, a communication microcomputer that is a microcomputer that controls the communication, and a modulation and demodulation circuit. The mobile terminal 1 may be configured to be able to implement at least one of cellular communication and Wi-Fi communication as a means of communication with the DKS 3. The mobile terminal 1 does not need to include both the cellular communication unit 17 and the Wi-Fi communication unit 18. When the mobile terminal 1 is connected to the wide area communication network 9 through cellular communication or Wi-Fi communication, that is, in an online state, the terminal control unit 10 performs various data communications with the DKS 3. The data communications may be performed, for example, by encrypted communication using TLS (Transport Layer Security). The cellular communication unit 17 and the Wi-Fi communication unit 18 correspond to the net connection unit.

[0053] 3, the terminal control unit 10 has a service key management unit F1, a one-time authentication key management unit F2, and a vehicle response unit F3 as functional units that are realized when the terminal processor 101 executes the digital key application 104. The various functional units can be enabled when the digital key application 104 is authenticating a user.

[0054] User authentication (login) can be performed by inputting a specific user ID and password into the digital key application 104. User authentication may also be performed using the biometric authentication device 14. Since the digital key application 104 is a part of the vehicle digital key system Sys, a state in which a user is logged in to the digital key application 104 corresponds to a state in which a user is logged in to the vehicle digital key system Sys. The logged-in state is released when a specific expiration date has passed since the login, and the digital key application 104 transitions to a logged-off state in which the user must be re-authenticated.

[0055] The terminal control unit 10 also includes a terminal-side memory unit 105. The terminal-side memory unit 105 is a memory area in which various data used by the digital key application 104, such as a service key, is stored. The terminal-side memory unit 105 is realized using a memory area provided in the storage 103 or the RAM 102. The terminal-side memory unit 105 includes a key information memory unit M1 and a vehicle data temporary memory unit M2. The key information memory unit M1 is a memory area for storing a service key, a one-time authentication key described below, a user ID, and the like. The vehicle data temporary memory unit M2 is a memory area for temporarily storing data received from the DKS 3 to be transferred to the vehicle Hv. The terminal-side memory unit 105 corresponds to a terminal-side memory device.

[0056] The service key management unit F1 manages a service key for the user of the own terminal issued by the DKS3. In this disclosure, the own terminal refers to the mobile terminal 1 in which the own terminal is installed as viewed from the terminal control unit 10. The service key management unit F1 requests the issuance of a service key for the own terminal or deletes a service key for the own terminal based on an operation signal input from the touch panel 12. The service key for the own terminal corresponds to a service key for the user of the own terminal.

[0057] The service key management unit F1 acquires a service key for its own terminal from the DKS3 and stores it in the key information storage unit M1. When acquiring a service key, the service key management unit F1 acquires key-related information, which is additional information, along with the service key itself. Key-related information refers to, for example, a service key ID, expiration date, permission settings, type, etc. This information can be packaged and distributed as one data set.

[0058] The service key ID is a number for identifying the service key. For example, the service key ID is set to a unique value for each user. The service key ID may be a random number generated when an account is created. Even if the owner changes the model of the mobile terminal 1 and the value of the service key changes, the service key ID associated with the owner does not change. The service key ID may be set to a unique value according to the combination of the vehicle ID and the user ID.

[0059] The expiration date data indicates a predetermined value indicating an unlimited period or a period / date specified by the issuer. The authority setting data indicates the functions (i.e., the authority) permitted to the user of the terminal. The authority setting data indicates, for example, whether each door can be locked or unlocked, and whether the driving power can be turned on / off. The service key type indicates whether it is an owner key or a guest key. The type information may be integrated with the authority setting data.

[0060] The service key management unit F1 executes a process of acquiring a service key for its own terminal, displaying a status confirmation screen related to the service key for its own terminal, and deleting the service key for its own terminal. The status confirmation screen is a screen that shows the status of the service key for its own terminal. The status of the service key includes the expiration date, permission settings, and valid / invalid state. The status confirmation screen may include information about the name of the user corresponding to the issuer, etc.

[0061] The functions provided by the service key management unit F1 may differ depending on the type of service key assigned to the terminal itself, in other words, the authority setting of the service key. For example, the service key management unit F1 of the owner terminal is configured to be able to execute a process for issuing a guest key for a guest designated by the user and a process for deleting / temporarily invalidating the guest key. Note that, only in the owner terminal, the presence or absence of authority to issue a guest key can be specified as a type of authority setting when issuing a guest key. In addition, the service key management unit F1 of the owner terminal displays a screen showing a list of guests who hold a service key related to the vehicle Hv and the status of each guest key. The owner terminal may obtain and display information on the guest key from, for example, the DKS3. In addition, the service key management unit F1 of the owner terminal is configured to be able to execute a process for registering information on the owner key in the vehicle Hv using a predetermined data set obtained from the DKS3.

[0062] Furthermore, the service key management unit F1 provided in the terminal with issuing rights is configured to be capable of executing a process of issuing a new guest key without issuing rights to a guest designated by a user. Furthermore, the service key management unit F1 provided in the terminal with issuing rights is configured to be capable of checking the status of a guest key issued by itself, and deleting / invalidating the guest key. The service key management unit F1 of the terminal without issuing rights is configured to be capable of checking the status and deleting / invalidating the service key for its own terminal. Additionally, the service key management unit F1 of the guest terminal may check the expiration date of the service key for its own terminal based on expiration date data. Note that the expiration date check of the guest key may be performed by the DKS3.

[0063] The one-time authentication key management unit F2 obtains a one-time authentication key used for authentication processing with the vehicle Hv from the DKS3 and stores it in the key information storage unit M1. The one-time authentication key management unit F2 itself does not have a function for generating a one-time authentication key. With this configuration, the details of the method for generating the one-time authentication key can be kept confidential. This in turn improves the security performance of the vehicle digital key system Sys.

[0064] The one-time authentication key is a code obtained by combining a service key with a variable code (variable factor). The variable code is a different value for each issuance. The variable code can be, for example, epoch seconds, a count value of the number of issuances, or a random number. Furthermore, the variable code may be a value obtained by subtracting the number of issuances of the authentication key from a predetermined initial value. If the one-time authentication key is Ka, the service key is SK, the variable code is Cd, and the generation function of the one-time authentication key is G, the one-time authentication key can be expressed as Ka=G(SK,Cd). In this case, the generation function G is a function that takes two inputs, the service key and the variable code. The generation function G may be a function that takes one input value, and in that case, the one-time authentication key can be generated by, for example, Ka=G(SK+Cd). SK+Cd may be a code that simply connects (i.e., concatenates) the service key and the variable code, or may be a code obtained by adding the corresponding number sequences in the concept of binary or hexadecimal numbers.

[0065] If the first factor for generating the one-time authentication key is the service key, the variable code can be called the second factor for generating the one-time authentication key. The variable code is one of the authentication key generation factors. Furthermore, the one-time authentication key may be generated using a predetermined third factor in addition to the service key and the variable code. For example, the one-time authentication key may be generated by inputting a bit string obtained by combining a count value indicating the number of times the key has been issued, an ECU number, and a service key in a predetermined order into a predetermined function. The one-time authentication key is a so-called disposable authentication key that is discarded after being used once. It is preferable that the third factor is information that is registered in advance in the authentication ECU 4.

[0066] The one-time authentication key management unit F2 transmits a signal to the DKS3 at any time to request the delivery of one-time authentication keys so that a state in which a predetermined number or more of one-time authentication keys are stored in the key information storage unit M1 is maintained. For example, the one-time authentication key management unit F2 sets a replenishment necessity flag to ON based on the fact that the remaining number (Notk) of one-time authentication keys stored in the key information storage unit M1 is less than a predetermined replenishment threshold (ThRp). The one-time authentication key management unit F2 acquires a plurality of one-time authentication keys by communicating with the DKS3 based on the fact that the replenishment necessity flag is set to ON and that the unit is online. The replenishment threshold can be, for example, 150 or 300. The replenishment necessity flag is an optional element and may be omitted. The replenishment threshold ThRp may be 200, 400, or 500.

[0067] The one-time authentication key is set with an expiration date calculated from the date of issue. The expiration date can be set to, for example, one month, three months, or six months. The expiration date of the one-time authentication key is also set by the DKS 3. The DKS 3 may be configured to be able to change the length of the expiration date for the one-time authentication key based on an instruction operation by the owner. If the vehicle Hv is a rental car, the expiration date of the one-time authentication key can be set to correspond to the rental period. This technical idea can also be applied to setting the expiration date of a guest key.

[0068] The one-time authentication key management unit F2 checks the expiration dates of the one-time authentication keys stored in the key information storage unit M1 at a predetermined timing, and deletes the one-time authentication keys that have expired. The one-time authentication key expiration date check may be performed by the DKS3. If the remaining number of one-time authentication keys falls below the replenishment threshold as a result of deleting the expired one-time authentication key, a process for acquiring a one-time authentication key from the DKS3 is performed, such as setting a replenishment necessity flag to on.

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

[0070] In addition, the vehicle response unit F3 performs a process of relaying communication between the authentication ECU 4 and the DKS 3 based on a request from the authentication ECU 4. For example, the vehicle response unit F3 converts a time request signal received from the authentication ECU 4 by BLE communication into a format for cellular communication and transmits it to the DKS 3. In addition, the vehicle response unit F3 converts data for the authentication ECU 4 received from the DKS 3, such as server time information, into a format for BLE communication and transfers it to the authentication ECU 4.

[0071] In addition, the mobile terminal 1 may be configured to be able to execute authentication processing with the in-vehicle system 7 by near-field communication. The mobile terminal 1 may be configured to perform pairing related to BLE communication with the in-vehicle system 7 by near-field communication. Furthermore, the terminal control unit 10 may be configured to be able to display a vehicle status confirmation screen, which is a screen for confirming the status of the vehicle Hv, as a function of the digital key app 104. The vehicle status confirmation screen is a screen that shows the remaining amount of gasoline / battery, the open / closed state of each window and each door, the lock state, the temperature inside the vehicle, and the like. Furthermore, the terminal control unit 10 may be configured to be able to remotely operate a part of the electrical equipment equipped in the vehicle Hv. For example, it may be configured to be able to remotely operate the air conditioner on / off, the opening / closing of windows, the turning on / off of hazard lights, and the like. Note that the vehicle status confirmation and the contents that can be remotely operated may be changed according to the authority of the service key.

[0072] <About the configuration and functions of the dedicated keys> Here, the configuration and functions of the dedicated key 2 will be described with reference to FIG. 4. The dedicated key 2 is a dedicated electronic key for operating the vehicle Hv. The dedicated key 2 is provided to the owner together with the vehicle Hv when the vehicle Hv is purchased as proof of ownership of the vehicle Hv or as a physical master key. The dedicated key 2 is basically held by the owner. The dedicated key 2 can be understood as one of the accessories of the vehicle Hv. The dedicated key 2 can adopt various shapes such as a flat rectangular parallelepiped type, a flat ellipsoid type (a so-called fob type), a card type, etc. The dedicated key 2 can be called a vehicle portable device, a key fob, a key card, a card key, an access key, etc.

[0073] A dedicated key code, which is a predetermined code that certifies that it is a key for the vehicle Hv, is registered in the dedicated key 2. The dedicated key code is also registered in the authentication ECU 4. The dedicated key 2 is configured to be able to certify that a person attempting to access the vehicle Hv is the owner by communicating with the authentication ECU 4 in a predetermined procedure. Note that the dedicated key 2 is an optional element and may be omitted.

[0074] The dedicated key 2 includes a control circuit 20 and a near-field communication unit 21 as shown in FIG. 4. The control circuit 20 is a circuit that controls the operation of the dedicated key 2. The control circuit 20 is realized using an MCU (Micro Controller Unit) 201, a RAM 202, a flash memory 203, etc. The control circuit 20 may be realized using an MPU (Micro-Processing Unit) or an FPGA (Field-Programmable Gate Array) instead of the MCU. The dedicated key code described above is stored in the flash memory 203.

[0075] The near-field communication unit 21 is a communication module for performing near-field communication. The dedicated key 2 is configured as a passive wireless tag that functions by converting radio waves from a near-field communication unit 56 provided in the vehicle Hv, for example, into electric power. When the near-field communication unit 21 of the dedicated key 2 is communicatively connected to the near-field communication unit 56 provided in the vehicle Hv, the control circuit 20 returns a dedicated key code itself or a response code generated based on the dedicated key code in response to a request from the authentication ECU 4. The authentication ECU 4 can transition to a state where owner registration is possible based on the successful completion of the authentication process using the dedicated key code. In this way, the dedicated key 2 can function as a device for switching the authentication ECU 4 to a state where owner information can be registered.

[0076] <Regarding the Configuration and Function of the DKS> Here, the configuration and function of the DKS 3 will be described. As shown in FIG. 5, the DKS 3 includes a data processing unit 30, a network connection device 31, a vehicle DB 32, and a user DB 33. The DB in the member name is an abbreviation for Database (Database).

[0077] The data processing unit 30 is configured to execute various processes based on signals / data input from the network connection device 31. The data processing unit 30 is connected to the network connection device 31, the vehicle DB 32, and the user DB 33 so as to be able to communicate with each other. The data processing unit 30 is configured using a server processor 301, a RAM 302, and a storage 303. The server processor 301 is an arithmetic core that executes various arithmetic processes, and is realized using, for example, a CPU or a GPU. A predetermined digital key management program is stored in the storage 303. The server processor 301 executes the digital key management program to realize various functional units, which will be described later. The execution of the digital key management program by the server processor 301 corresponds to the execution of a vehicle digital key management method, which is a method corresponding to the program.

[0078] 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 be capable of intercommunicating with communication facilities constituting the wide area communication network 9, for example, using optical fibers. This allows the DKS 3 to communicate data with the mobile terminal 1 when the mobile terminal 1 is online.

[0079] The vehicle DB 32 is a database in which information about vehicles managed by the vehicle digital key system Sys is registered. As shown in Fig. 6, the vehicle DB 32 stores the vehicle ID for each vehicle in association with vehicle model information, owner information, and guest information. The vehicle model information includes information related to the vehicle model, year, grade, OS (Operating System), etc. of the target vehicle.

[0080] The vehicle model information may include the version of the software used in the authentication ECU 4, an ECU number, etc. The ECU number here is a number for distinguishing the authentication ECU 4 used in each of a plurality of vehicles, and is a number that differs for each authentication ECU 4. The manufacturing number of the authentication ECU 4, etc., can be used as the ECU number. By using the ECU number, the DKS 3 can execute data distribution targeted at a specific authentication ECU 4, even if the same model of authentication ECU 4 is installed in a plurality of vehicles Hv.

[0081] The owner information is information about the owner of the vehicle Hv, and includes, for example, a user ID, a telephone number as contact information, an email address, and a device ID. The guest information is information about a user (i.e., a guest) to whom a service key related to the vehicle Hv has been distributed. For example, the vehicle DB 32 registers a user ID for each guest as guest information about the vehicle Hv. Note that the vehicle DB 32 does not necessarily have to include guest information.

[0082] The user DB 33 is a database in which information about users is registered. As shown in FIG. 7, the user DB 33 stores user IDs, passwords, device IDs, key-related information, remarks, and the like as user data for each user. The user ID and password are a data set for authenticating a user. The user ID and password are registered by the user, for example, when creating an account. An account for using the service can be created via a dedicated web page or the digital key application 104. The device ID of the mobile terminal 1 possessed by the user can be registered, for example, by the DKS 3 communicating with the digital key application 104.

[0083] The key-related information includes, for example, target vehicle information, service key ID, service key, key attribute, authority setting, and owner key ID. The target vehicle information indicates the ID of a vehicle that can be used by the user. When the service key information for each vehicle is managed in the vehicle DB 32, the user DB 33 does not need to include target vehicle information as key-related information. The key type indicates, for example, whether it is an owner key or a guest key. The key type can also be interpreted as information indicating the user's attribute (owner / guest) for the target vehicle. As described above, the authority setting indicates the doors that can be locked and unlocked, whether the driving power is permitted to be turned on / off, and the like. The owner key ID indicates the service key ID of the owner of the target vehicle. The owner key ID corresponds to the owner key number. The owner key ID field in the owner's user data may be blank, or the owner's own service key ID may be registered.

[0084] In the remarks field, age, driving skill proficiency, etc. can be registered. The driving skill proficiency can be registered as to whether the driver is a beginner or not, for example, whether the driver has obtained a driver's license within the last year or not. In addition, the remarks field can also register an accident history, etc. This remarks information can be used as a calculation material for the usage fee, insurance premium, etc., if the service is applied to a car sharing service, etc.

[0085] Both the vehicle DB 32 and the user DB 33 are realized using a rewritable non-volatile storage medium. In addition, both the vehicle DB 32 and the user DB 33 are configured so that data can be written, read, deleted, etc. by the server processor 301. The vehicle DB 32 and the user DB 33 may be integrated. The above-mentioned database configuration is an example. The vehicle DB 32 and the user DB 33 do not need to hold all of the above-mentioned items. In addition, the vehicle DB 32 may be provided in a separate server. In the first place, the DKS3 of the present disclosure may be implemented by being divided into multiple servers. The division of roles / functional arrangement for each server can be changed as appropriate.

[0086] As shown in FIG. 8, the data processing unit 30 includes, as functional units, a user management unit G1, a user authentication unit G2, a service key issuing unit G3, a one-time authentication key issuing unit G4, a service key deletion unit G5, and a model change acceptance unit G6.

[0087] The user management unit G1 is configured to manage user information. For example, the user management unit G1 performs new user registration, deletion, and change of registered contents 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 change of registered contents are acquired via, for example, the mobile terminal 1 and the network connection device 31.

[0088] Hereinafter, signals corresponding to user operations / instructions to the vehicle digital key system Sys, such as creating or deleting an account, changing registered contents, and issuing / deleting / invalidating a service key, will be referred to simply as operation signals. Of course, the interface that directly accepts user operations is not limited to the mobile terminal 1. The DKS 3 can obtain the operation signals via a computer installed in an office or at home. In other words, the DKS 3 is configured to obtain the user operation signals via the digital key app 104 or a dedicated web page.

[0089] The user authentication unit G2 performs a process of authenticating the user based on a combination of the user ID and password. If the user authentication unit G2 determines that the authentication is successful, the service key issuing unit G3, the one-time authentication key issuing unit G4, the service key deletion unit G5, the model change acceptance unit G6, and the like perform processes according to an operation signal from the user or a request from the digital key application 104.

[0090] The service key issuing unit G3 issues a service key based on a user operation on the mobile terminal 1 etc. Specifically, based on a service key issuance request signal transmitted from an owner terminal or a guest terminal with issuing rights, it issues a service key according to the request content. The one-time authentication key issuing unit G4 issues a one-time authentication key for the requester based on a one-time authentication key issuance request signal transmitted from the mobile terminal 1. The service key deleting unit G5 deletes a specified service key based on a request from the mobile terminal 1. The model change accepting unit G6 is configured to accept a model change application and issue a service key according to a new device ID.

[0091] The one-time authentication key issuing unit G4, the service key deleting unit G5, and the model change accepting unit G6 will be described in detail later.

[0092] By being provided with the above functional units, the data processing unit 30 holds the correspondence between the owner and the guest for each vehicle managed by the system. For one vehicle, there is only one user who is the owner, but there can be multiple guests. The data processing unit 30 comprehensively manages information on one vehicle and the guests linked to the owner.

[0093] Fig. 9 conceptually illustrates the correspondence between the owner key and the guest key for one vehicle. The data processing unit 30 manages one vehicle and multiple guest keys linked to one owner key based on the service key ID of the owner key, i.e., the owner key ID. Note that Fig. 9 illustrates a case in which three guest keys have been issued for one vehicle. As described above, each guest key may have different authority settings and expiration dates.

[0094] <Configuration and Functions of In-Vehicle System 7> Here, a description will be given of the configuration and functions of the in-vehicle system 7. As shown in Fig. 10, the in-vehicle system 7 includes an authentication ECU 4, a display 51, an input device 52, a body ECU 53, a lock motor 54, a power supply ECU 55, a near-field communication unit 56, a BLE communication unit 57, and a cellular communication unit 58.

[0095] The authentication ECU 4 is connected to each of the display 51, the input device 52, the body ECU 53, the power supply ECU 55, the near-field communication unit 56, the BLE communication unit 57, and the cellular communication unit 58 via the in-vehicle network Nw or by a dedicated signal line so as to be able to communicate with each other. The body ECU 53 is connected to the lock motor 54 so as to be able to communicate with each other. The in-vehicle network Nw is a communication network built in the vehicle Hv. As a standard for the in-vehicle network Nw, various standards such as Controller Area Network (hereinafter, CAN: registered trademark), Ethernet (registered trademark), and FlexRay (registered trademark) can be adopted. Note that a part of the body ECU 53, etc. may be connected to the authentication ECU 4 by a dedicated line without going through the in-vehicle network Nw. The connection form between the devices can be changed as appropriate.

[0096] The authentication ECU 4 is an ECU that executes authentication processing of the portable terminal 1 in cooperation with the BLE communication unit 57 etc. Furthermore, the authentication ECU 4 executes predetermined vehicle control such as unlocking the doors and turning on the power for driving in cooperation with other ECUs, on the condition that authentication of the portable terminal 1 is successful. The authentication ECU 4 includes a vehicle control unit 40 as a core module that executes the above processing.

[0097] The authentication ECU 4 is realized by using a computer. That is, the authentication ECU 4 includes an authentication processor 41, a RAM 42, a storage 43, an I / O 44, and a bus line connecting these components. The authentication processor 41 is, for example, a CPU. The authentication processor 41 executes various processes for implementing the functions of each functional unit described later by accessing the RAM 42. The configuration including the authentication processor 41 and the RAM 42 corresponds to the vehicle control unit 40. The authentication processor 41 can also be called a vehicle processor in contrast to the server processor 301. The storage 43 stores a vehicle authentication program, which is a program related to the authentication process of a user (actually a mobile terminal) accessing the vehicle Hv. The storage 43 may also store an ECU number of the authentication ECU 4. The I / O 44 is a circuit module for communicating with other devices. The function of the authentication ECU 4 will be described in detail later.

[0098] The display 51 is a device that displays images. For example, the display 51 may display an owner registration start screen, a service key deletion screen, and the like, based on an input from the authentication ECU 4. The owner registration start screen is an operation screen for starting the registration of an owner key, and may include, for example, a form for inputting an owner password. The service key deletion screen is a screen for deleting data of a service key designated by a user from the vehicle-side storage unit 45. The owner key data held by the authentication ECU 4 is also configured to be deletable via the service key deletion screen. The display 51 is, for example, a center display provided in the central area of ​​the instrument panel in the vehicle width direction. The display 51 may be a so-called meter display arranged in the area in front of the driver's seat.

[0099] The input device 52 is a device for receiving a user's instruction operation to the in-vehicle system 7, more specifically, the authentication ECU 4. For example, a touch panel laminated on the display 51 can be used as the input device 52. The input device 52 may be a mechanical switch provided on a steering wheel, an instrument panel, or the like. The input device 52 outputs an electric signal corresponding to an operation performed by the user on the device as an operation signal to the authentication ECU 4. The operation signal output by the input device 52 indicates the content of the user's operation. The display 51 and the input device 52 correspond to an interface for the user to register / delete a service key / change operation settings for the authentication ECU 4. The display 51 and the input device 52 are collectively referred to as an in-vehicle HMI 50. HMI is an abbreviation for Human Machine Interface.

[0100] The body ECU 53 is an ECU that controls body actuators based on requests from the authentication ECU 4 and operation signals from the user. The body ECU 53 is connected to various body actuators so as to be able to communicate with them. The body actuators here include lock motors 54 that constitute the lock mechanisms of the doors.

[0101] The power supply ECU 55 is an ECU that controls the on / off state of a power supply for running mounted on the vehicle Hv. For example, the power supply ECU 55 sets the power supply for running to on, for example, based on an instruction signal from the authentication ECU 4. If the vehicle Hv is an engine vehicle, the power supply ECU 55 starts the engine based on the instruction signal.

[0102] The near-field communication unit 56 is a communication module for performing near-field communication. The near-field communication unit 56 functions as a reader for receiving data from the dedicated key 2. The near-field communication unit 56 accesses the dedicated key 2 within a communication distance by near-field communication, and receives information related to owner verification, such as a dedicated key code or a response code based on the dedicated key code. The near-field communication unit 56 can perform near-field communication not only with the dedicated key 2, but also with various devices located within a communication range, such as the mobile terminal 1.

[0103] The near-field communication unit 56 may include, for example, a communication module for outside the vehicle and a module for inside the vehicle. The near-field communication unit 56 for outside the vehicle corresponds to a configuration for performing authentication for locking / unlocking control. The near-field communication unit 56 for inside the vehicle corresponds to a configuration for performing authentication for on / off control of the driving power source. The near-field communication unit 56 for outside the vehicle is provided, for example, near the outer door handle for the driver's seat. The vicinity of the outer door handle refers to, for example, within 0.2 m from the outer door handle. The vicinity of the outer door handle also includes the inside of the outer door handle. The near-field communication unit 56 for inside the vehicle is provided around the driver's seat in the vehicle cabin. For example, the near-field communication unit 56 for inside the vehicle is provided near the start button provided on the instrument panel. The near-field communication unit 56 for inside the vehicle may be built into the start button. Furthermore, the near-field communication unit 56 may be provided in the center console or the center of the instrument panel in the vehicle width direction.

[0104] The BLE communication unit 57 is a communication module for performing BLE communication. The BLE communication unit 57 is disposed, for example, in the center console, the ceiling of the vehicle interior, the upper end of the front / rear window, the C-pillar, etc. The cellular communication unit 58 is a communication module for performing cellular communication. The in-vehicle system 7 may include a module for Wi-Fi communication instead of the cellular communication unit 58 or in addition to the cellular communication unit 58.

[0105] The authentication ECU 4 executes processing related to user authentication by communicating with the DKS 3 and the portable terminal 1. More specifically, the communication between the authentication ECU 4 and the portable terminal 1 can be realized by cooperation between a BLE communication unit 16 included in the portable terminal 1 and a BLE communication unit 57 included in the in-vehicle system 7.

[0106] As shown in Fig. 11, the authentication ECU 4 has a user management unit H1 and an authentication processing unit H2 as functional units. These functional units are realized, for example, by the authentication processor 41 executing a vehicle authentication program. The authentication ECU 4 also has a vehicle-side memory unit 45 for storing the owner key and the like. The vehicle-side memory unit 45 is realized using a memory area provided in the storage 43 or the RAM 42. The vehicle-side memory unit 45 has an owner key memory unit 451 and a guest key memory unit 452.

[0107] The owner key storage unit 451 is a storage area for storing information related to the owner key. The guest key storage unit 452 is a storage area for storing information related to the guest key. The information related to the owner / guest key refers to the service key itself, as well as a service key ID, a user ID, a user name, and the like. The information related to the guest key also includes an expiration date and authority settings. The guest key storage unit 452 is configured to be able to store multiple guest keys, while the owner key storage unit 451 is configured to be able to store only one owner key. Therefore, registration of a new owner key involves the deletion of data of the old owner key. The vehicle-side storage unit 45 corresponds to a vehicle-side storage device.

[0108] The service key issued by the DKS3 is activated by being registered in the vehicle-side storage unit 45. In other words, on the condition that the service key for the user is stored in the vehicle-side storage unit 45, the user can use the vehicle Hv within the scope of the authority assigned to the service key.

[0109] The user management unit H1 is configured to manage users who can use the vehicle Hv, that is, the service keys stored in the vehicle-side storage unit 45. As described separately below, the user management unit H1 performs BLE communication with the mobile terminal 1 to acquire data related to the service key issued by the DKS3 via the mobile terminal 1 and store the data in the vehicle-side storage unit 45. In addition, the user management unit H1 acquires data for deleting a service key stored in the vehicle-side storage unit 45 via the mobile terminal 1, and deletes the data related to the target service key.

[0110] The authentication ECU 4 has an owner registration possible mode in which the registration of an owner key can be accepted, and an owner registration prohibited mode in which the owner registration is not accepted / rejected as an operation mode. The authentication ECU 4 basically operates in the owner registration prohibited mode. Therefore, the owner registration prohibited mode can be called a normal mode. The authentication ECU 4 temporarily transitions from the owner registration prohibited mode to the owner registration possible mode based on the input of a security release code, which will be described separately later.

[0111] The authentication processing unit H2 cooperates with the BLE communication unit 57 to perform a process of confirming (in other words, authenticating) that the communication partner is the mobile terminal 1 carried by the user of the vehicle Hv. The communication for authentication is performed in an encrypted form. The authentication method itself can be performed using various methods such as a challenge-response method. As an example in this embodiment, authentication is performed using a challenge-response method using a challenge code and a one-time authentication key. A detailed sequence of the authentication process will be described later. The authentication processing unit H2 includes a one-time authentication key generation unit H21 as a sub-functional unit that dynamically generates a one-time authentication key required for the authentication process. Note that the one-time authentication key generation unit H21 is an optional element and may be omitted.

[0112] The timing at which the authentication processing unit H2 performs the authentication processing may be, for example, the timing at which a communication connection is established between the BLE communication unit 57 and the mobile terminal 1. The authentication processing unit F4 may be configured to perform the authentication processing at a predetermined period while the BLE communication unit 57 and the mobile terminal 1 are connected for communication. Also, the authentication processing unit F4 may be configured to perform encrypted communication for the authentication processing, triggered by a predetermined user operation on the vehicle Hv.

[0113] Possible user operations that trigger the execution of the authentication process include pressing a door button / touching a door handle, pressing a start button, opening and closing a door, etc. The door button refers to a button provided on the door handle for locking and unlocking the door. Touching the door handle can be detected by a touch sensor provided on the door handle. The start button is a button provided inside the vehicle cabin, such as on the instrument panel, for switching on and off the power supply for driving.

[0114] <Owner key registration sequence> Here, an example of a sequence from issuance of an owner key to registration in a vehicle will be described with reference to Figures 12, 13, and 14. The sequence from issuance of an owner key to registration in a vehicle can be roughly divided into an issuance phase Ph1 and a vehicle registration phase Ph2, as shown in Figure 12.

[0115] The issuance phase Ph1 is a phase in which the DKS3 issues a service key based on a request from a user, or in reality, a key issuance request signal transmitted from the mobile terminal 1. The issued service key is distributed only to the mobile terminal 1. The service key issued by the DKS3 is not distributed directly to the vehicle Hv, but is registered to the vehicle Hv via the mobile terminal 1. The vehicle registration phase Ph2 is a phase in which information about the service key held by the mobile terminal 1 is registered to the vehicle Hv by BLE communication. The service key issued by the DKS3 is not actually usable, that is, is activated, until it is registered in the vehicle Hv. Therefore, the vehicle registration phase Ph2 can also be called an activation phase. It should be noted that the issuance to activation of not only the owner key but also the guest key includes the issuance phase Ph1 and the vehicle registration phase Ph2.

[0116] Fig. 13 is a sequence diagram showing interactions between devices corresponding to the owner key issuance phase. The owner key issuance sequence is executed by the owner terminal and the DKS 3. As shown in Fig. 13, the owner key issuance sequence includes steps S10 to S17.

[0117] Step S10 is a step in which the DKS 3 authenticates the user / portable terminal 1 and confirms that the communication partner is the owner / owner terminal. The authentication of the owner may be performed using a user ID and a password, or may be performed using biometric information. The authentication using biometric information may be performed by the biometric authentication device 14. Note that step S10 may also be a step in which the digital key application 104 of the portable terminal 1 authenticates the user.

[0118] Step S11 is a step in which the mobile terminal 1 as an owner terminal transmits a key issuance request signal based on a user's operation. The key issuance request signal transmitted here is a signal requesting the issuance of an owner key, and therefore can be called an owner key issuance request signal. The key issuance request signal includes information for the DKS3 to identify the request source, such as a device ID or a user ID. The key issuance request signal also includes the type of the service key to be issued. Note that, if the service key to be issued is a guest key, the key issuance request signal may additionally include information indicating the setting of authority and the setting of an expiration date. In addition, the key issuance request signal may include information on the target vehicle. However, since the information on the target vehicle can be identified by referring to the vehicle DB32 using a user ID or the like as a search key, it may not be included in the key issuance request signal.

[0119] In step S12, the DKS 3 generates a service key as an owner key and a service key ID based on the owner key issuance request signal acquired from the owner terminal. More specifically, the execution subject of step S12 is the service key issuing unit G3.

[0120] In step S13, the DKS3 creates a predetermined number of one-time authentication keys based on the service key generated in step S12. More specifically, the execution subject of step S13 is the one-time authentication key issuing unit G4. The initial issuance number, which is the number of one-time authentication keys generated when issuing a service key, is set to a predetermined amount larger than the replenishment threshold, for example, 300.

[0121] In step S14, the DKS3 transmits a terminal registration package, which is a data set including the various data generated in steps S12 and S13, to the owner terminal. The terminal registration package includes a service key, a service key ID, multiple one-time authentication keys, and a variable code used to generate each one-time authentication key. Each one-time authentication key is associated with the variable code used to generate the one-time authentication key. The data set including the multiple one-time authentication keys and the variable code may be transmitted as an authentication key package separately from the data set including the service key.

[0122] The terminal registration package may also include a terminal check code and an ECU number of the authentication ECU 4 mounted on the target vehicle. The terminal check code is a code for the mobile terminal 1, which is the receiving side, to verify the completeness of the data, the validity of the received data, and whether or not the data has been tampered with. The terminal check code may be a Hamming code or a hash value obtained by inputting the payload into a predetermined hash function. The terminal check code may be generated using an encryption key issued in advance as a key for encrypted communication between the DKS 3 and the mobile terminal 1.

[0123] In step S15, the mobile terminal 1 as the owner terminal receives the terminal registration package distributed from the DKS 3 and stores the contents in the key information storage unit M1. The service key management unit F1 verifies the validity of the received data using the above-mentioned terminal check code, and then stores the received service key and its related information in the key information storage unit M1.

[0124] In step S16, the DKS 3 transmits a vehicle registration package, which is a data set for registering owner information in the vehicle Hv, to the owner terminal. The vehicle registration package may include a vehicle check code in addition to a service key and a service key ID. The vehicle check code is a code for the authentication ECU 4, which is the final receiving device, to verify the completeness of the data, the validity of the received data, and the presence or absence of tampering. The vehicle check code may be a Hamming code or a hash value according to the payload, similar to the terminal check code. The vehicle check code may be generated using an encryption key issued in advance as a key for encrypted communication between the DKS 3 and the authentication ECU 4. The vehicle check code may also be generated based on an ECU number. The terminal check code may be added to the vehicle registration package. According to this configuration, the owner terminal, which is a relay of communication between the DKS 3 and the authentication ECU 4, can also verify the completeness, validity, etc. of the received vehicle registration package.

[0125] In step S17, the mobile terminal 1 as the owner terminal receives the vehicle registration package distributed from the DKS3 and stores the contents in the vehicle data temporary storage unit M2. The reception process may include a verification process using the terminal check code described above. In this embodiment, the vehicle registration package and the terminal registration package are transmitted separately, but the transmission mode of the various data is not limited to this. The vehicle registration package and the terminal registration package may be transmitted as a series of data. In this case, overlapping data may be omitted.

[0126] A sequence for registering the owner key in the vehicle Hv will be described with reference to Fig. 14. The sequence for registering the owner key in the vehicle Hv includes steps S20 to S29.

[0127] First, in the initial state (step S20) at the start of this sequence, the authentication ECU 4 operates in the owner registration prohibited mode (i.e., normal mode). Step S21 is a step in which a predetermined security deactivation tool or the DKS 3 inputs a predetermined security deactivation signal to the authentication ECU 4. The input of the security deactivation signal to the authentication ECU 4 using the security deactivation tool or the DKS 3 is executed by the owner or dealer staff.

[0128] The security deactivation signal is a signal including a security deactivation code. In one aspect, the security deactivation signal corresponds to a signal that certifies that the registrant is the owner himself / herself. The security deactivation signal corresponds to a signal for temporarily switching the authentication ECU from an owner registration prohibited mode (normal mode) to an owner registration permitted mode. Based on input of the security deactivation signal, the authentication ECU 4 transitions to the owner registration permitted mode (step S22). The security deactivation signal corresponds to an owner registration start signal.

[0129] The security release tool is, for example, the dedicated key 2. A dedicated key code can be used as the security release code. For example, the authentication ECU 4 may transition to the owner registration mode when the in-vehicle near-field communication unit 56 performs near-field communication with the dedicated key 2 and receives a dedicated key code. The authentication ECU 4 may be configured to transition to the owner registration mode on the condition that a predetermined password is input via the in-vehicle HMI 50 in addition to receiving the dedicated key code.

[0130] The security deactivation tool may be a dedicated tool managed by a dealer shop or the like. The communication method between the dedicated tool and the authentication ECU 4 may be near-field communication or wired communication using, for example, a USB cable. The security deactivation signal from the DKS 3 is received via the cellular communication unit 58. The DKS 3 transmits a security deactivation signal addressed to the vehicle Hv based on a request from the owner terminal or a request from a predetermined terminal provided in the dealer shop. According to this configuration, the owner or a staff member of the dealer shop can switch the authentication ECU 4 to an owner registration enabled mode by operating the owner terminal or a predetermined terminal provided in the dealer shop.

[0131] When the authentication ECU 4 transitions to the owner registration mode, in step S24a, the authentication ECU 4 sets the BLE communication unit 57 to a standby state at a predetermined scan interval and searches for the mobile terminal 1 (so-called scanning). The standby state here refers to a state in which an advertising signal can be received. In this embodiment, the authentication ECU 4 detects the mobile terminal 1 that exists around the vehicle using a passive scan method. As another aspect, the authentication ECU 4 may search for the mobile terminal 1 using an active scan method that involves transmitting a scan request.

[0132] On the other hand, when the owner terminal accepts an operation to start the owner key registration via the touch panel 12 (step S23), it transmits an advertisement for the owner key registration at a predetermined interval (step S24b). When the advertisement is received by the authentication ECU 4 via the BLE communication unit 57, the authentication ECU 4 and the mobile terminal 1 start communication for a communication connection (step S25). The operation to start the owner key registration is, for example, pressing the owner key registration start button B1 displayed on the display 11 as shown in FIG. 15. The operation to start the owner key registration may be input of a voice command instructing the start of the owner key registration.

[0133] When a connection for BLE communication with the authentication ECU 4 is established, the owner terminal displays, for example, a pairing confirmation screen shown in FIG. 16. The pairing confirmation screen includes, for example, buttons B2a and B2b for the user to select whether or not to execute pairing. When the owner terminal detects that the affirmative button B2a has been pressed based on a signal from the touch panel 12 (step S26), it executes pairing processing with the authentication ECU 4 (step S27). This enables encrypted data communication between the authentication ECU 4 and the owner terminal. The pairing processing here includes not only the exchange of encryption keys but also the storage of the encryption keys (so-called bonding).

[0134] When the pairing process is completed and an encrypted communication link between the authentication ECU 4 and the owner terminal is established, the owner terminal transmits the vehicle registration package stored in the vehicle data temporary storage unit M2 to the authentication ECU 4 by BLE communication (step S28). The series of communications from steps S24a to S28 corresponds to communications for the authentication ECU 4 to obtain the owner key from the owner terminal.

[0135] When the authentication ECU 4 receives a vehicle registration package from the owner terminal through BLE communication, it stores key-related data included in the package in the vehicle-side storage unit 45. More specifically, it stores the received service key and service key ID in the owner key storage unit 451. This completes the vehicle registration of the owner key, and the owner key is activated.

[0136] The owner registration prohibition mode may be realized, for example, by refusing to receive or store a service key with owner authority, or by refusing the communication connection itself. As one aspect, the authentication ECU 4 may be configured to store a service key received through a communication link starting from an advertisement including a predetermined owner registration ID as an owner key in the owner key storage unit 451. In this case, the authentication ECU 4 ignores an advertisement including an owner registration ID in the owner registration prohibition mode, while performing a communication connection based on an advertisement including an owner registration ID in the owner registration mode. The owner registration ID is an ID indicating that the communication is for registering owner information, and can be expressed by a combination of three types of identifiers, such as UUID, Major, and Minor.

[0137] According to the above configuration, the owner key data is registered in the vehicle Hv only when a specific owner registration start signal is input, thereby providing higher security than a configuration in which the owner key can be registered at any time.

[0138] <Guest key registration sequence> Next, an example of a sequence from issuance of a guest key to registration of the guest key in a vehicle Hv will be described with reference to Figures 17, 18, 19, and 20. The sequence from issuance of a guest key to vehicle registration can also be divided into an issuance phase Ph1 and a vehicle registration phase Ph2.

[0139] Fig. 17 is a sequence diagram showing interactions of each device corresponding to guest key issuance phase Ph1. The guest key issuance sequence is executed by the owner terminal, the target guest terminal, and the DKS3. The target guest terminal refers to the mobile terminal 1 associated with the guest to which the service key is to be issued. As shown in Fig. 17, the guest key issuance sequence includes steps S30 to S37.

[0140] The guest terminal in the description of the guest key issuing and registration sequence in the vehicle refers to the target guest terminal. Note that although the following describes the case where the owner issues the guest key, the issuer of the guest key may also be a guest who has been granted a guest key with issuance rights. A guest who has been granted a guest key with issuance rights is also referred to as a guest with issuance rights. The terms "owner terminal" / "owner" in the description of guest key issuance etc. can be read as "guest terminal with issuance rights" / "guest with issuance rights."

[0141] Step S30 is a step in which the guest terminal transmits a guest key issuance request to the owner terminal based on the operation of a guest who desires to issue a service key. When the owner terminal receives the issuance request from the guest terminal, it transmits a guest key issuance request signal to the DKS3 (step S31). Although not shown in the figure, the guest key issuance sequence may also include a step in which the DKS3 authenticates a user as the owner. Also, step S30 is an optional element. Even if there is no issuance request from the guest terminal, the owner terminal may transmit a guest key issuance request signal for a specific guest based on the owner's operation. For example, the owner is configured to be able to issue a guest key to any guest by operating the owner terminal based on an exchange such as a telephone call / email with the guest.

[0142] The guest key issuance request signal includes data fields accommodating each of request source information, target vehicle information, target user ID, expiration date information, and authority setting information, as shown in FIG. 18, for example. The request source information is information indicating the source of the guest key issuance request, and may be, for example, the owner's user ID, a service key ID, or a device ID. The target vehicle ID is information for identifying a vehicle that can be used with a newly issued guest key, and indicates the vehicle ID of the vehicle Hv in this case. The target user ID is the user ID of the guest to whom the guest key is to be issued. Instead of the user ID, a device ID or the like may be adopted as the target user information. In the data field corresponding to the expiration date, a value corresponding to the period / date and time specified by the owner, or a predetermined value is input. The authority setting information indicates whether or not the guest key is issued, whether or not the driving power source is switched, and which doors can be locked and unlocked.

[0143] When the DKS3 receives a guest key issuance request signal from the owner terminal, it generates a service key and a service key ID for the target guest based on the received guest key issuance request signal in step S32. In step S33, the one-time authentication key issuing unit G4 of the DKS3 creates a predetermined number of one-time authentication keys based on the service key generated in step S32.

[0144] In step S34, the DKS3 transmits to the guest terminal a terminal registration package, which is a data set including the various data generated in steps S32 and S33. The terminal registration package for the guest key may include guest information in addition to basic information, as shown in FIG. 19, for example. The basic information has items that are generally similar to those of the package distributed when the owner key is issued. That is, the basic information includes a service key, a service key ID, a plurality of one-time authentication keys, and a variable code for each one-time authentication key. The guest information is additional information for the guest key. For example, the guest information includes issuer information, an owner key ID, target vehicle information, expiration date information, and authority setting information. The issuer information basically indicates the owner. However, if a newly issued guest key is generated based on a request from a guest terminal with issuing rights, the data field (column) of the issuer information may store information indicating the guest as the issuer. The terminal registration package may be configured to include only either the issuer information or the owner key ID. The terminal registration package sent to the guest terminal also includes a terminal check code and the like.

[0145] In step S35, the mobile terminal 1 as the guest terminal receives the terminal registration package distributed from the DKS3 and stores the contents in the key information storage unit M1. In step S36, the DKS3 transmits a vehicle registration package, which is a data set for registering guest key information in the vehicle Hv, to the guest terminal. The type of information contained in the vehicle registration package related to the guest key may be the same as that of the vehicle registration package transmitted in step S36. In step S37, the mobile terminal 1 as the guest terminal receives the vehicle registration package distributed from the DKS3 and stores the contents in the vehicle data temporary storage unit M2.

[0146] A sequence for the guest terminal to register the guest key received from the DKS3 in the vehicle Hv will be described with reference to the following FIG. 20. The sequence for registering the guest key in the vehicle Hv includes steps S40 to S47. It is assumed that the guest terminal is present in the vicinity of the vehicle Hv, more specifically, in a location where BLE communication is possible. The steps executed by the guest terminal are essentially executed by the terminal processor 101. Also, the steps executed by the authentication ECU 4 are essentially executed by the authentication processor 41.

[0147] First, in the initial state at the start of this sequence (step S40), the authentication ECU 4 is operating in normal mode. The authentication ECU 4 can register a guest key even in normal mode. Therefore, unlike the owner key registration sequence, the owner and guest do not need to change the operation mode of the authentication ECU 4 using a security release tool or the like. The authentication ECU 4 performs scanning at a predetermined scan interval even in normal mode (step S42a).

[0148] On the other hand, when the guest terminal receives a guest key registration start operation via the touch panel 12 (step S41), it transmits an advertisement for guest key registration at predetermined intervals (step S42b). When the advertisement is received by the authentication ECU 4 via the BLE communication unit 57, the authentication ECU 4 and the mobile terminal 1 start communication for communication connection (step S43). Note that the guest key registration start operation is, for example, pressing a guest key registration start button B3 displayed on the display 11 as shown in FIG. 21. The guest key registration start operation may be input of a predetermined voice phrase.

[0149] When a connection of BLE communication with the authentication ECU 4 is established, the guest terminal displays, for example, a pairing confirmation screen shown in Fig. 16. When the guest terminal detects that the affirmative button B2a has been pressed based on a signal from the touch panel 12 (step S44), it executes pairing processing with the authentication ECU 4 (step S45). This enables encrypted data communication between the authentication ECU 4 and the guest terminal.

[0150] When the pairing process is completed and an encrypted communication link is established between the authentication ECU 4 and the guest terminal, the guest terminal transmits the vehicle registration package stored in the vehicle data temporary storage unit M2 to the authentication ECU 4 via BLE communication (step S46).

[0151] When the authentication ECU 4 receives a vehicle registration package from the guest terminal through BLE communication, it stores key-related data included in the package in the vehicle-side storage unit 45. More specifically, it stores the received service key, service key ID, authority settings, expiration date, and the like in the guest key storage unit 452. This completes the registration of the guest key in the vehicle Hv, and the guest key is activated.

[0152] According to the above configuration, the owner terminal and the authentication ECU 4 do not need to be connected by BLE communication to activate the guest key. That is, the owner does not need to bring the owner terminal close to the vehicle Hv every time a guest key is issued. Therefore, according to the above configuration, the burden on the owner for activating the guest key can be reduced. In addition, in this embodiment, the authentication ECU 4 acquires and stores a vehicle registration package by BLE communication with the mobile terminal 1 regardless of the type of service key such as an owner key or a guest key. According to this configuration, the amount of data communication in the vehicle Hv can be reduced. Furthermore, even if the vehicle Hv is outside the communication range, such as an underground parking lot, the service key can be registered in the vehicle Hv as the user approaches. Of course, as another aspect, the authentication ECU 4 may acquire the vehicle registration package from the DKS 3 by cellular communication or Wi-Fi communication. Note that the configuration in which the service key is transmitted to the vehicle Hv via the mobile terminal 1 corresponds to the configuration in which the service key is indirectly distributed to the authentication ECU 4.

[0153] <Example of system operation when a user uses a vehicle> Here, the operation of the authentication ECU when a user uses the vehicle Hv will be described with reference to Figures 22 and 23. As a premise, the user described here is a person who carries a mobile terminal 1 in which a service key for the vehicle Hv is stored. In other words, the user here corresponds to an owner or a guest, and the mobile terminal 1 corresponds to an owner terminal or a guest terminal.

[0154] First, while the vehicle Hv is parked, the authentication ECU 4 periodically causes the BLE communication unit 57 to perform scanning to determine whether or not the mobile terminal 1 is present around the vehicle (step S51). The determination of whether or not the mobile terminal 1 is present around the vehicle is performed based on whether or not a BLE signal emitted from the mobile terminal 1, such as an advertisement, is received. If a BLE signal from the mobile terminal 1 is received (step S51 YES), communication is established with the mobile terminal 1 (step S52). On the other hand, if the mobile terminal 1 cannot be found as a result of scanning, this flow is terminated. When the flow is terminated, step S51 is executed again at a timing when a predetermined scan interval has elapsed. The flowchart shown in FIG. 22 can be repeatedly executed at a predetermined scan interval while the vehicle Hv is parked.

[0155] When the authentication ECU 4 is able to establish a communication connection with the portable terminal 1, the authentication ECU 4 executes an authentication process in step S53. The authentication process will be described later. When the authentication of the portable terminal 1 (and thus the user) is successful as a result of the authentication process (YES in step S54), the authentication ECU 4 transitions to a standby mode (step S55).

[0156] The standby mode corresponds to a state in which unlocking / locking, switching on / off of the driving power supply, etc. can be performed based on the user's operation on the door button, etc. In one aspect, the standby mode corresponds to a state in which the authentication processor 41 recognizes that the mobile terminal 1 / user having the service key is present around the vehicle. The surroundings of the vehicle include not only the outside of the vehicle but also the inside of the vehicle. In this embodiment, as an example, an expiration date is set for the determination result that the authentication is successful. The expiration date is set to, for example, 3 seconds, 5 seconds, 10 seconds, etc.

[0157] On the other hand, if the authentication of the mobile terminal 1 fails as a result of the authentication process (NO in step S54), this flow is terminated. If the authentication process fails, the in-vehicle equipment may be operated so that the user can recognize that the authentication has not been successful. For example, if the authentication process has not been successful, a predetermined authentication failure image may be displayed on the display 51, or a lighting device provided on the side mirror or the like may be turned on in a predetermined pattern. If the authentication process has failed, the authentication ECU 4 may transmit a predetermined control signal to the mobile terminal 1 by BLE communication to display an authentication failure screen on the display 11. The authentication ECU 4 may express the authentication failure by turning on a welcome light that emits light toward the road surface around the door in a predetermined pattern.

[0158] In step S56, the authentication processor 41 determines whether or not a user operation for using the vehicle Hv has been performed based on signals from the door button, touch sensor, start button, etc. A user operation for using the vehicle Hv refers to an action of trying to open the door, such as touching / grabbing the door handle. Pressing the start button also corresponds to a user operation for using the vehicle Hv.

[0159] When a signal corresponding to the user operation is input from the vehicle sensor (step S56: YES), the authentication processor 41 executes vehicle control according to the member operated by the user and the state of the vehicle Hv (step S57). For example, when the authentication processor 41 detects that the door button is pressed or the door handle is gripped while the vehicle Hv is locked, the authentication processor 41 unlocks the door. When the authentication processor 41 detects that the start button is pressed, the authentication processor 41 switches the power supply for driving from off to on or from on to off.

[0160] When actually performing vehicle control such as unlocking / locking the doors and turning on / off the driving power, not only the authentication result but also the estimated position of the mobile terminal 1, the authority of the service key, and the state of the vehicle Hv are referenced. If a predetermined control execution condition is not satisfied, the execution of vehicle control according to the user's operation may be canceled. Examples of cases in which the control execution condition is not satisfied include a case in which the authority set in the service key is insufficient, or a case in which the detected position of the mobile terminal 1 is more than 2 m away from the vehicle. The position of the mobile terminal 1 may be specified based on the reception status of a signal from the mobile terminal 1. Various indices such as reception strength, arrival direction of the signal, ToF (Time of Flight), and RTT (Round-Trip Time) can be used as materials for estimating the position of the mobile terminal 1.

[0161] On the other hand, if no user operation has been performed to use the vehicle Hv (step S56 NO), it is determined whether the authentication result has expired, that is, whether a predetermined time has passed since it was determined that the authentication was successful. If it is within the expiration date (step S58 NO), the standby mode is maintained. On the other hand, if the expiration date has expired, the authentication processor 41 executes communication for the authentication process again.

[0162] According to the above configuration, the user can access the vehicle Hv without operating the dedicated key 2 or the mobile terminal 1. In other words, a passive entry / passive start function is realized, which can improve user convenience.

[0163] <About authentication process> Here, a description will be given of a processing sequence in which the authentication ECU 4 authenticates the portable terminal 1. The authentication processing of the portable terminal 1 by the authentication ECU 4 includes, for example, steps S61 to S68 as shown in Fig. 23. Note that the authentication processing is executed on the premise that an encrypted communication link between the portable terminal 1 and the authentication ECU 4 has been established.

[0164] Step S61 is a step of transmitting a challenge code from the authentication ECU 4 to the mobile terminal 1. As the challenge code, a random number of a predetermined length generated using a random number table prepared in advance can be used. The challenge code may be a random number generated using time information (so-called system time) provided in the authentication ECU 4 as a SEED. The challenge code can be determined by various methods.

[0165] Step S62 is a step in which the portable terminal 1 generates a response code by combining an arbitrary one-time authentication key stored in the key information storage unit M1 with the received challenge code in a predetermined manner. Step S63 is a step in which the portable terminal 1 returns the response code generated in step S62 and a variable code corresponding to the one-time authentication key used to generate the response code together / separately to the authentication ECU 4. The variable code corresponding to a certain one-time authentication key refers to the variable code used to generate the one-time authentication key in the DKS3.

[0166] In step S64, the authentication ECU 4 generates a one-time authentication key by using the variable code received from the mobile terminal 1 and the service key corresponding to the communication partner stored in the vehicle-side storage unit 45 in a manner similar to that used by the one-time authentication key issuing unit G4 of the DKS 3. Here, the combination of the service key and variable code used by the authentication ECU 4 to generate the one-time authentication key is the same as the generation material of the one-time authentication key used by the mobile terminal 1 to generate the response code. Therefore, the one-time authentication key generated by the authentication ECU 4 in step S64 is the same as the one-time authentication key used by the mobile terminal 1 to generate the response code. Such step S64 corresponds to a process of restoring the one-time authentication key used by the mobile terminal 1 to generate the response code, based on the variable code received from the mobile terminal 1 and the service key of the mobile terminal 1 held by the authentication ECU 4 itself.

[0167] In step S65, the authentication ECU 4 generates a verification code based on the one-time authentication key generated in step S64 and the challenge code transmitted in step S61. The method of generating the verification code itself is the same as that of generating the response code. If the communication partner is a mobile terminal 1 that holds a service key registered in the vehicle-side storage unit 45, the verification code and the response code are expected to match. If the communication partner is an unregistered device, either no response code is returned or the response code and the verification code do not match. Therefore, the codes generated / received in the above manner function as information for verifying the legitimacy of the communication partner.

[0168] In step S66, the authentication ECU 4 compares the verification code generated in step S65 with the response code received from the mobile terminal 1 to determine the legitimacy of the communication partner. That is, if the two codes match, it is determined that the authentication is successful (step S67). On the other hand, if the two codes differ, it is determined that the authentication is unsuccessful (step S68). Note that if no response code is returned even after a predetermined response waiting time has elapsed since the transmission of the challenge code, the authentication ECU 4 may determine that the authentication is unsuccessful.

[0169] According to the above configuration, the mobile terminal 1 and the user are authenticated using a one-time authentication key generated based on a service key unique to each mobile terminal 1. Therefore, security can be improved compared to a configuration in which the mobile terminal is authenticated using fixed key information. According to the above method, the information exchanged between the authentication ECU 4 and the mobile terminal 1 when generating a response code is a variable code and a challenge code. The one-time authentication key itself is not transmitted or received between the authentication ECU and the mobile terminal during authentication. A service key that is separately distributed in the service key issuance phase is required to generate the one-time authentication key, and the one-time authentication key cannot be restored by merely intercepting the variable code. Furthermore, the one-time authentication key used for authentication is changed every time. Therefore, according to the above method, it is possible to reduce the risk that an unrelated person will succeed in the authentication process illegally. The unrelated person here refers to a person to whom the service key of the vehicle Hv has not been granted.

[0170] The above-mentioned authentication sequence is an example, and is not limited thereto. The operation of each device may be designed so that the one-time authentication key used to generate the response code / verification code is the same in the mobile terminal 1 and the authentication ECU 4. For example, the authentication process may be performed according to the procedure shown in Fig. 24. That is, as another example, the authentication process may include steps S61a to S69a.

[0171] In addition, when the authentication processing pattern shown in FIG. 24 is adopted, it is assumed that the authentication ECU 4 and the mobile terminal 1 hold a common plurality of one-time authentication keys as a prerequisite configuration. For example, the authentication ECU 4 acquires the same one-time authentication key as that held by the mobile terminal 1 by receiving a data set including a plurality of one-time authentication keys as a vehicle registration package. In addition, when the one-time authentication keys stored in the vehicle-side storage unit 45 fall below a predetermined replenishment threshold, the authentication ECU 4 receives an unacquired one-time authentication key from the mobile terminal 1 on condition that the authentication of the mobile terminal 1 is successful. In this way, the authentication ECU 4 can replenish the one-time authentication keys stored in the vehicle-side storage unit 45. In addition, the mobile terminal 1 replenishes the one-time authentication keys by communication with the DKS 3 as necessary, as described later. The authentication ECU 4 may be configured to acquire the one-time authentication keys directly from the DKS 3. In addition, it is assumed that each one-time authentication key is assigned a number for identifying them.

[0172] Step S61a is a step in which the authentication ECU 4 transmits a key-in-use confirmation signal to the mobile terminal 1. The key-in-use confirmation signal is a signal inquiring about the number of a key to be used. The key to be used refers to a one-time authentication key to be used for generating a subsequent response code. The key-in-use confirmation signal corresponds to an adjustment message.

[0173] When the portable terminal 1 receives the key-to-be-used confirmation signal, in step S62a, the portable terminal 1 notifies the authentication ECU 4 of the number of the key to be used. Any method can be used to determine the key to be used. For example, the one-time authentication key held by the portable terminal 1 that has the smallest number is selected as the key to be used.

[0174] The mobile terminal 1 sequentially deletes expired one-time authentication keys according to the expiration date management of the one-time authentication keys described later. The authentication ECU 4 also performs the same expiration date management, but the time information of the authentication ECU 4 and the mobile terminal 1 do not necessarily match perfectly. In addition, the timing of performing the discard process of the one-time authentication key based on the expiration date may also differ. Due to these circumstances, the authentication ECU 4 does not necessarily hold the key to be used that the mobile terminal 1 holds.

[0175] If the authentication ECU 4 does not hold the planned-to-use key notified by the portable terminal 1, the authentication ECU 4 may request the portable terminal 1 to use another key. Steps S61a to S62a may be repeatedly performed until a one-time authentication key held by both the authentication ECU 4 and the portable terminal 1 is selected. In order to more efficiently reconcile the planned-to-use key, the key-to-use confirmation signal may include the numbers of multiple candidates selected randomly / according to a predetermined rule from among the one-time authentication keys held by the authentication ECU 4. The portable terminal 1 may be configured to select the planned-to-use key from among the multiple candidates randomly / according to a predetermined rule and respond.

[0176] In step S63a, the authentication ECU 4 transmits a challenge code, similar to step S61. In step S64a, the authentication ECU 4 generates a verification code based on a one-time authentication key corresponding to the number notified from the mobile terminal 1 as the key to be used, and the challenge code transmitted in step S63a. The one-time authentication key itself is the one-time authentication key stored in the vehicle-side storage unit 45.

[0177] Step S65a is a step in which the mobile terminal 1 generates a response code using a one-time authentication key corresponding to the number selected as the key to be used and the challenge code received from the authentication ECU 4. The one-time authentication key itself used to generate the response code is acquired in advance from the DKS 3 and stored in the terminal side storage unit 105. When the mobile terminal 1 completes the generation of the response code, it transmits the response code to the authentication ECU 4 in step S66a.

[0178] When the authentication ECU 4 receives the response code from the portable terminal 1, in step S67a, the authentication ECU 4 compares the response code with the verification code generated in step S65a to determine the validity of the communication partner. That is, if the two codes match, it is determined that the authentication has been successful (step S68a). On the other hand, if the two codes differ, it is determined that the authentication has failed (step S69a).

[0179] According to the above method, the information exchanged between the authentication ECU 4 and the mobile terminal 1 when generating the response code is the number of the key to be used and the challenge code, and the one-time authentication key itself is not transmitted or received by communication. The one-time authentication key cannot be restored by the key number alone. Therefore, similar to the above authentication method, the above method can reduce the risk that an unrelated person will succeed in the authentication process illegally. In the above example, the mobile terminal 1 notifies the authentication ECU 4 of the number of the key to be used before generating the response code, but the processing order is not limited to this. After generating the response code, the mobile terminal 1 may notify the authentication ECU 4 of the number of the one-time authentication key used to generate the response code.

[0180] <One-time authentication key replenishment sequence> Here, with reference to FIG. 25, the one-time authentication key replenishment process executed by the mobile terminal 1 will be described. The one-time authentication key replenishment process is a process of replenishing the one-time authentication key when it becomes less than a predetermined replenishment threshold ThRp. The one-time authentication key replenishment process includes steps S71 to S77 as shown in FIG. 25. The one-time authentication key replenishment process is periodically executed, for example, at a predetermined remaining number confirmation cycle. The one-time authentication key replenishment process may be executed on the condition that the mobile terminal 1 is in an online state. The one-time authentication key replenishment process may also be started based on, for example, receiving a remaining number confirmation instruction signal transmitted from the DKS3 or the user performing a predetermined remaining number confirmation operation. The one-time authentication key replenishment process may be executed as part of the stored authentication key update process described later. The reception of the remaining number confirmation instruction signal and the acceptance of the remaining number confirmation operation correspond to confirmation events.

[0181] The expression of the mobile terminal 1 as the execution entity of the one-time authentication key replenishment process can be understood as the terminal processor 101 / one-time authentication key management unit F2.

[0182] Step S71 is a step in which the mobile terminal 1 checks the remaining number (Notk) of the one-time authentication key stored in the terminal-side storage unit 105. Step S72 is a step in which the mobile terminal 1 determines whether or not the remaining number (Notk) of the one-time authentication key acquired in step S71 is less than a predetermined replenishment threshold (ThRp). If Notk < ThRp is satisfied, the mobile terminal 1 transmits an authentication key request signal to the DKS3 as step S73. The authentication key request signal is a signal requesting the distribution of the one-time authentication key. The authentication key request signal corresponds to a replenishment request signal. On the other hand, if Notk ≧ ThRp is satisfied, the mobile terminal 1 ends the sequence for replenishing the one-time authentication key.

[0183] Note that, as described above, the necessity for replenishing the one-time authentication key can be managed by a replenishment necessity flag. When Notk < ThRp is satisfied, the mobile terminal 1 sets the replenishment necessity flag to on. Also, when Notk ≧ ThRp is satisfied, the mobile terminal 1 sets the replenishment necessity flag to off. If the mobile terminal 1 is in an offline state, it maintains the state where the replenishment necessity flag is set to on, and thereafter, it can transmit an authentication key request signal based on becoming online.

[0184] When DKS3 receives an authentication key request signal from the mobile terminal 1, as step S74, it reads out the service key of the requester from the user DB33. Then, DKS3 generates a plurality of one-time authentication keys using the service key and a variable code generated randomly / according to a predetermined rule (step S75). The number of one-time authentication keys generated in step S75 may be a fixed number, or may be a value obtained by adding a predetermined value (for example, 100) to the difference between the replenishment threshold and the remaining number. The authentication key request signal may include information indicating the remaining number of one-time authentication keys in the mobile terminal 1 so that DKS3 can specify the required number of transmissions.

[0185] When the generation of the one-time authentication keys is completed, DKS3, as step S76, transmits an authentication key package toward the mobile terminal 1. The authentication key package is a data set in which a variable code is associated with each one-time authentication key. When the mobile terminal 1 receives the authentication key package from DKS3, it stores the data included therein in the terminal-side storage unit 105 (step S77).

[0186] According to the above configuration, the one-time authentication key held by the mobile terminal 1 is replenished whenever necessary when the one-time authentication key falls below a predetermined value. This reduces the risk that the one-time authentication key will run out and the user will be unable to use the vehicle Hv. The replenishment threshold is set to a sufficiently large value, for example, 100 or more. This setting reduces the risk that the one-time authentication key will run out while the user is outside the communication range, such as in a mountainous area. The digital key application 104 may be configured to allow the user to register any value as the replenishment threshold, as long as it is greater than a predetermined minimum value.

[0187] <One-time authentication key periodic update sequence> Here, the stored authentication key update process executed by the mobile terminal 1 will be described with reference to Fig. 26. The stored authentication key update process is a process for periodically replacing a part or all of the one-time authentication keys stored in the terminal side storage unit 105. The stored authentication key update process includes steps S81 to S83 as shown in Fig. 26. The stored authentication key update process is executed periodically, for example, at a predetermined replacement period. The stored authentication key update process may be executed on condition that the mobile terminal 1 is in an online state. The expression "the mobile terminal 1" as the executing entity of the processing steps constituting the stored authentication key update process can be interpreted as the terminal processor 101 / one-time authentication key management unit F2.

[0188] Step S81 is a step in which the mobile terminal 1 checks the expiration date of each one-time authentication key stored in the terminal side storage unit 105 based on the terminal time, which is time information held by the mobile terminal 1. The mobile terminal 1 deletes any one-time authentication key whose expiration date has expired (step S82). Note that checking the expiration date corresponds to comparing the date and time indicated as the expiration date with the current date and time. The terminal time is corrected as needed by communication with a predetermined server such as the DKS3.

[0189] Step S83 is a step in which the mobile terminal 1 executes a one-time authentication key replenishment process in cooperation with the DKS 3. The one-time authentication key replenishment process is as described above. Note that the replenishment process based on the expiration date may be configured to replenish the number of one-time authentication keys deleted in step S82, regardless of whether the remaining number (Notk) is less than the replenishment threshold (ThRp). For example, when the mobile terminal 1 deletes 20 one-time authentication keys in step S82, the mobile terminal 1 may transmit a signal requesting issuance of 20 one-time authentication keys as an authentication key request signal. The authentication key request signal may include information indicating the desired number of keys to be issued.

[0190] According to the above configuration, some or all of the one-time authentication keys stored in the mobile terminal 1 are periodically replaced based on their expiration dates. According to this configuration, the one-time authentication keys that can be used are changed over time. This makes it possible to further strengthen security.

[0191] <About updating the time information in certified ECUs> The authentication ECU 4 checks the expiration date of the guest key based on the ECU internal time, which is time information held by the authentication ECU 4. For this reason, it is preferable that the ECU internal time is synchronized with the time information of the DKS 3. Here, a process of correcting the ECU internal time so as to synchronize it with the time information of the DKS 3 and then expiring the guest key will be described with reference to FIG. 27. A series of sequences relating to the update of the ECU time information and the check of the expiration date of the guest key includes steps S91 to S97, as shown in FIG. 27. Note that at least the sequence relating to the update of the ECU internal time is executed on the condition that a BLE communication link is established between the authentication ECU 4 and the mobile terminal 1. The mobile terminal 1 here may be either an owner terminal or a guest terminal.

[0192] In step S91, the authentication ECU 4 transmits a time request signal to the mobile terminal 1. The time request signal is a signal that requests server time information, which is time information held by the DKS 3. The time request signal may include information indicating the request source, such as an ECU number or a vehicle ID.

[0193] When the mobile terminal 1 receives the time request signal from the authentication ECU 4 via BLE communication, in step S92, it generates a time request signal conforming to a format for cellular communication or Wi-Fi communication and transmits the signal to the DKS 3. Step S92 corresponds to a step of transferring data from the authentication ECU 4 to the DKS 3. Note that the time request signal transmitted from the mobile terminal 1 to the DKS 3 preferably includes information about the mobile terminal 1 so that the DKS 3 can identify the destination to which the server time information is to be returned.

[0194] When the DKS 3 receives a time request signal from the mobile terminal 1, it returns the server time information to the requesting mobile terminal 1 (step S93). In addition, the mobile terminal 1 transfers the server time information received from the DKS 3 to the authentication ECU 4 by BLE communication (step S94).

[0195] When the authentication ECU 4 receives the server time information from the mobile terminal 1, it corrects the ECU internal time using the server time information (step S95). The ECU internal time refers to the time information held by the authentication ECU 4. The data reception process in each device may include a process of verifying validity using a check code. If the result of the verification process using the check code indicates that the data is not valid, the request may be rejected. Steps S91 to S95 described above correspond to sequence Sq1 for updating the ECU time information.

[0196] For example, based on the correction of the ECU internal time, the authentication ECU 4 checks the expiration date of each guest key registered in the vehicle-side storage unit 45 using the corrected time information (step S96). Then, the authentication ECU 4 deletes the data of the expired guest key (step S97). Note that step S97 may be a process of invalidating the expired guest key by using a flag or the like while leaving the key data.

[0197] Steps S96 to S97 correspond to sequence Sq2 for checking the expiration date of the guest key. Sequence Sq1 for updating the ECU time information and sequence Sq2 for checking the expiration date of the guest key may be executed separately. Sequence Sq2 for checking the expiration date of the guest key may be executed at a predetermined cycle, not limited to when the ECU time information is updated. Also, the expiration date of the guest key may be checked based on the timing when the running power source is switched from on to off, or from off to on.

[0198] The time information stored in the authentication ECU 4 may differ from the actual time or the server time due to the accuracy of a clock oscillator included in the authentication ECU 4. With the above configuration, the ECU internal time is corrected every time a connection is made to the mobile terminal 1. This reduces the possibility that the authentication ECU 4 will delete / invalidate the guest key based on incorrect time information.

[0199] <About the owner key deletion process> When a vehicle Hv is bought, sold, or transferred, the owner of the vehicle Hv may change. When the owner changes, it is preferable to delete the service key and other information of the old owner. For this reason, the vehicle digital key system Sys must be configured to be able to delete not only the guest key but also the owner key information.

[0200] The DKS 3 of this embodiment is configured to be able to accept an owner key deletion request from both the owner terminal and the in-vehicle HMI. When the DKS 3 deletes the owner key based on an operation on the owner terminal, the entire process may include an in-terminal data deletion phase Ph3 and an in-vehicle data deletion phase Ph4, as shown in FIG. 28. The in-terminal data deletion phase Ph3 is a phase in which data of a service key (here, the owner key) designated from the mobile terminal 1 is deleted. The in-vehicle data deletion phase Ph4 is a phase in which a service key designated from the authentication ECU 4 is deleted. Here, the sequence when deleting the owner key based on an operation on the owner terminal will be described with reference to FIG. 29 and FIG. 30.

[0201] 29 is a sequence diagram showing interactions between devices corresponding to the intra-terminal data deletion phase Ph3. The sequence for deleting the owner key data from the mobile terminal 1 includes steps T10 to T18, as shown in FIG.

[0202] Step T10 is a step in which the DKS3 authenticates the user / mobile terminal 1, similar to step S10. Step T11 is a step in which the mobile terminal 1 as an owner terminal transmits an owner key deletion request signal based on a user's operation. The owner key deletion request signal includes information for the DKS3 to identify the request source, such as a device ID, a user ID, or a service key ID. The owner key deletion request signal may also include information such as a service key ID, an ECU number, or a vehicle ID as information for identifying the service key to be deleted. Assuming that one user is the owner of multiple vehicles, it is preferable that the owner key deletion request signal includes information for identifying the service key to be deleted.

[0203] When the DKS3 (service key deletion unit G5) receives an owner key deletion request signal from the owner terminal, it transmits a vehicle owner deletion package to the owner terminal in step T12. The vehicle owner deletion package is a data set for deleting data related to all service keys from the vehicle Hv. The vehicle owner deletion package may include a terminal check code and a vehicle check code. When the owner terminal receives the vehicle owner deletion package distributed from the DKS3, it verifies the validity of the package using the terminal check code and then stores the package in the vehicle data temporary storage unit M2 (step T13).

[0204] Furthermore, when a guest key has been issued for the vehicle Hv, the DKS3 transmits a guest key deletion command to the guest terminal based on an owner key deletion request signal from the owner terminal (step T14). When a guest key has been issued for the vehicle Hv, in other words, when a guest key exists that is linked to the owner key to be deleted. The guest key deletion command is a signal that instructs the guest terminal to delete data related to a service key for the vehicle Hv. The guest key deletion command includes information such as the service key ID to be deleted and a terminal check code. When the guest terminal receives the guest key deletion command, the guest terminal verifies the validity of the command using the terminal check code, and then deletes all data related to the specified service key from the key information storage unit M1 (step T15). In a more preferred embodiment, when the guest key deletion process is completed, the guest terminal reports this to the DKS3.

[0205] Based on the owner key deletion request signal from the owner terminal, the DKS3 transmits an owner key deletion command to the owner terminal (step T16). The owner key deletion command is a signal that instructs the owner terminal to delete data related to the service key for the vehicle Hv. The owner key deletion command includes information such as the service key ID to be deleted and the terminal check code. The owner key deletion command and the guest key deletion command are instruction commands for deleting a service key, i.e., they correspond to a type of service key deletion command.

[0206] When the owner terminal receives the owner key deletion command, it verifies its validity using the terminal check code, and then deletes all data related to the specified service key from the key information storage unit M1 (step T17). Note that the owner key deletion command does not affect the data stored in the vehicle data temporary storage unit M2. In other words, even if the owner terminal receives the owner key deletion command, it does not delete the vehicle owner deletion package stored in the vehicle data temporary storage unit M2, but leaves it for a predetermined period of time. In a more preferred embodiment, the owner terminal reports to the DKS3 when the owner key deletion process is completed.

[0207] For example, based on receiving a notification from the owner terminal and the guest terminal that the deletion of the service key has been completed, the DKS3 deletes the data related to the owner key requested to be deleted from the user DB 33 and the vehicle DB 32 (step T18). Note that the deletion of data in the server may be performed after receiving a report from the vehicle Hv that the deletion of data in the vehicle has also been completed. In this embodiment, the vehicle owner deletion package and the owner key deletion command are transmitted separately, but the manner in which the various data are transmitted is not limited to this. The vehicle owner deletion package and the owner key deletion command may be transmitted together as a series of data.

[0208] The sequence for deleting data related to the owner key from the vehicle Hv will be described with reference to the following Figure 30. Information related to the owner key also includes guest key data. The sequence for deleting data related to the owner key from the vehicle Hv includes steps T21 to T24. Unlike the owner key registration sequence, the authentication ECU 4 accepts an instruction to delete the owner key even in normal mode. The portable terminal 1 in the description of Figure 30 is the portable terminal 1 that holds the vehicle owner deletion package, and can be called the previous owner terminal.

[0209] When the mobile terminal 1 holding the vehicle owner deletion package enters the BLE communication range of the vehicle Hv, the authentication ECU 4 establishes a communication connection with the mobile terminal 1 via BLE (step T21), similar to when the mobile terminal 1 holds a service key. Then, encrypted communication is started (step T22). Based on the establishment of an encrypted communication link with the authentication ECU 4, the mobile terminal 1 transmits the vehicle owner deletion package for the vehicle Hv, which is stored in the vehicle data temporary storage unit M2 (step T23).

[0210] When the authentication ECU 4 receives the vehicle owner deletion package from the mobile terminal 1, it deletes data related to all service keys stored in the vehicle-side storage unit 45 based on the commands / programs included in the package. In this way, the owner terminal is configured to be able to delete the owner key from the authentication ECU 4 when a BLE communication link is established between the owner terminal and the authentication ECU 4.

[0211] The sequence including steps T11 to T13 may be executed in a state where the owner terminal is communicatively connected to the DKS 3. In this case, the vehicle owner deletion package acquired by the owner terminal from the DKS 3 may be promptly transferred to the authentication ECU 4 in step T23, and the owner key may also be deleted from the vehicle-side storage unit 45. When the authentication ECU 4 receives the vehicle owner deletion package, it may verify the validity of the received data based on a vehicle check code included in the received data, and then delete all the service key data.

[0212] <Guest key deletion process by owner authority> It is preferable that the owner is configured to be able to delete the guest key even within the expiration date based on a request from the guest, a violation of the terms of use, etc. Here, the flow of the process in which the DKS 3 deletes a specified guest key based on a request from the owner terminal will be described with reference to Figs. 31 and 32.

[0213] Similar to the owner key deletion, the guest key deletion process can be divided into phase Ph3 in which data related to the guest key is deleted from the portable terminal 1, and phase Ph4 in which the guest key data is deleted from the vehicle Hv. Fig. 31 is a sequence diagram showing interactions of each device corresponding to phase Ph3 in which the guest key data is deleted from the portable terminal 1. The sequence for deleting the guest key data from the portable terminal 1 includes steps T30 to T39b, as shown in Fig. 31.

[0214] Note that the device that accepts the owner's operations is not limited to the mobile terminal 1, and may be a desktop / notebook PC (laptop). The owner terminal in the following description may be a desktop / notebook PC operated by the owner.

[0215] Step T30 is a step in which the digital key application 104 in the owner terminal authenticates that the operator is the owner. The authentication method in the digital key application 104 may be a method using a password or a method using biometric information. Both the password and the biometric information may be used to verify whether or not the operator is the owner. Various methods such as two-step authentication can be adopted for user authentication.

[0216] Step T31 is a step in which the owner terminal displays a deletion target selection screen on the display 11 based on an operation signal input from the touch panel 12. The deletion target selection screen is a screen for selecting a guest key to be deleted or a guest corresponding thereto. The deletion target selection screen includes a list of guests or guest keys. The deletion target selection screen can also be called a guest list screen showing a list of guests or a guest deletion screen.

[0217] In step T32, the owner terminal identifies the guest key to be deleted based on a user operation on the deletion target selection screen indicated by the output signal of the touch panel 12. The user operation to select the guest key to be deleted corresponds to a deletion instruction operation. When the guest key to be deleted is selected by the owner, the owner terminal transmits a guest key deletion request signal for that guest key to the DKS3 (step T33). The guest key deletion request signal includes the service key ID or user ID of the guest key to be deleted as information for identifying the service key to be deleted. Note that the guest key deletion request signal may be a signal requesting the collective deletion of multiple guest keys. For example, the guest key deletion request signal may be a signal requesting the collective deletion of all guest keys linked to the owner key.

[0218] When the DKS3 receives the guest key deletion request signal, it transmits a guest key deletion command to the guest terminal associated with the guest key specified in the received signal (step T34). When the guest terminal receives the guest key deletion command, it verifies its validity using the terminal check code, and then deletes all data related to the specified service key from the key information storage unit M1 (step T35). The guest key deletion command corresponds to a deletion instruction signal. In a more preferred embodiment, the guest terminal reports to the DKS3 that the guest key deletion process is complete.

[0219] Step T36 is a step in which the DKS 3 notifies the owner terminal that the deletion of the guest key is complete. The DKS 3 may transmit the guest key deletion completion notification based on the completion of transmission of the guest key deletion command, or may transmit the guest key deletion after receiving a deletion completion report from the guest terminal.

[0220] When the owner terminal receives the guest key deletion completion notification from the DKS 3, it displays a deletion completion notification screen on the display 11 (step T37). The deletion completion notification screen may include the user name associated with the deleted guest key, and the like.

[0221] Furthermore, the DKS3 transmits a vehicle guest deletion package to the owner terminal and the guest terminal corresponding to the guest key set as the deletion target (steps T38a and T38b). When each device receives the vehicle guest deletion package, it stores it in the vehicle data temporary storage unit M2 (steps T39a and T39b). The vehicle guest deletion package corresponds to a deletion data set.

[0222] Next, a sequence for deleting data related to a guest key from the vehicle Hv will be described with reference to Fig. 32. The sequence for deleting data related to a guest key from the vehicle Hv includes steps T41 to T44. The guest terminal appearing in the sequence for deleting data related to a guest key from the vehicle Hv corresponds to a guest terminal that holds a vehicle guest deletion package.

[0223] When the mobile terminal 1 as an owner terminal or a guest terminal enters the BLE communication range of the vehicle Hv, the authentication ECU 4 establishes a communication connection with the mobile terminal 1 by BLE (step T41). Then, encrypted communication is started (step T42). Based on the establishment of an encrypted communication link with the authentication ECU 4, the mobile terminal 1 transmits a vehicle guest deletion package for the vehicle Hv stored in the vehicle data temporary storage unit M2 (step T43).

[0224] When the authentication ECU 4 receives a vehicle guest deletion package from the owner terminal / guest terminal, it deletes data related to the guest key designated for deletion from the vehicle-side memory unit 45 based on the instructions / programs contained in the package.

[0225] The sequence including steps T41 to T43 may be executed in a state where the owner terminal / guest terminal is communicatively connected to the DKS 3. Furthermore, when the authentication ECU 4 receives a vehicle guest deletion package, the authentication ECU 4 may execute deletion of all the service key data after verifying the validity of the received data based on a vehicle check code included in the received data.

[0226] According to the above configuration, the owner can delete any guest key at any time. Therefore, it is possible to stop the guest from using the vehicle Hv according to the usage status of the guest and the owner's convenience.

[0227] In addition, if the guest key is suddenly deleted while the guest is using the vehicle Hv, the guest may experience inconvenience. In particular, if the guest uses the vehicle Hv to move to a location away from the original storage location of the vehicle Hv, and the vehicle Hv suddenly becomes unusable, both the guest and the owner may experience inconvenience. For such reasons, a certain amount of time may be provided between the request for deletion of the guest key and the actual execution of the deletion process. The deletion of the guest key, etc. may be executed on the condition that the vehicle Hv is parked in a specified storage location. The DKS3 may display a screen on the corresponding guest terminal indicating that the owner has requested deletion of the guest key.

[0228] As described above, the owner terminal is configured to be able to accept an operation to selectively delete a guest key associated with a vehicle. On the other hand, it is configured to be unable to accept an operation to change only the settings related to the expiration date or authority without deleting the guest key. The DKS3 is also configured to be unable to change the authority settings and expiration date of an issued service key while leaving the service key in place. If the owner wants to change the authority settings or expiration date of a service key for a guest, the owner must first delete the guest key and then issue a guest key with the desired authority settings.

[0229] In the above, a case has been described in which the owner deletes a guest key by operating an owner terminal or the like, but the guest key can also be deleted by the guest's own operation. When the DKS3 deletes a guest key based on the guest's operation, it transmits a notification that the guest key has been deleted to the owner terminal linked to the guest key. Based on the notification, the owner terminal displays a guest deletion screen that includes, for example, the deleted guest key or its user name. Alternatively, based on the notification from the DKS3, it updates the status information for each guest.

[0230] <Service key deletion process using in-vehicle HMI> Here, a process flow for deleting a service key designated by a user based on a user operation on the in-vehicle HMI will be described with reference to FIG. 33. The sequence for deleting a service key designated by a user from the authentication ECU 4 and the associated mobile terminal 1 based on a user operation on the in-vehicle HMI includes steps T50 to T57 as shown in FIG. 33. As a premise, the DKS 3 is configured to be able to accept a request for deleting a service key according to the authority of the operator via the in-vehicle HMI. For example, when the operator of the in-vehicle HMI 50 is the owner, the authentication ECU 4 and the DKS 3 are configured to be able to accept a deletion instruction for not only the guest key but also the owner key via the in-vehicle HMI 50. Among the steps constituting FIG. 33, the steps executed by the authentication ECU 4 can be interpreted as being specifically executed by the authentication processor 41.

[0231] Step T50 is a step in which the authentication ECU 4 authenticates the user operating the in-vehicle HMI 50. As described above, various authentication methods can be adopted, such as a method involving password input or a method using biometric information. Step T50 can be understood as a step in which the operator of the in-vehicle HMI 50 is identified. Furthermore, the authentication of the user by the authentication ECU 4 may be performed by utilizing the authentication result of the portable terminal 1 by the authentication ECU 4. The authentication ECU 4 may consider the user corresponding to the portable terminal 1 as the communication partner as the operator of the in-vehicle HMI 50.

[0232] In step T51, the authentication ECU 4 displays a service key deletion screen on the display 51 based on an operation signal input from the input device 52. The service key deletion screen is a screen for selecting a service key ID or a user to be deleted. If the operator is recognized as the owner, the service key deletion screen is configured to allow the owner key to be selected as a deletion target. The service key deletion screen may include a list of service keys that can be deleted with the authority of the user as the operator, or a list of corresponding users.

[0233] In step T52, the authentication ECU 4 identifies the service key to be deleted based on a user operation on the service key deletion screen indicated by an output signal from the input device 52. Then, in step T53, the authentication ECU 4 deletes data related to the service key specified to be deleted from the vehicle-side storage unit 45. When the data deletion from the vehicle-side storage unit 45 is completed, the authentication ECU 4 displays a deletion completion screen (step T54). The deletion completion screen may include information such as a user name linked to the deleted service key. Note that displaying the deletion completion screen is an optional element and may be omitted.

[0234] When the authentication ECU 4 completes the deletion of the data related to the specified service key, it transmits a deletion completion notification signal indicating the completion of the service key deletion sequence to the DKS 3 in step T55. The deletion completion notification signal includes the ID of the deleted service key or the user ID corresponding thereto. If an owner key is specified as the target for deletion, all service keys are deleted from the vehicle-side storage unit 45 in step T53.

[0235] When the DKS 3 receives the deletion completion notification signal from the authentication ECU 4, it transmits a service key deletion command to the mobile terminal 1 linked to the service key specified in the received signal (step T56). If the owner key is deleted from the vehicle-side storage unit 45 based on an operation on the in-vehicle HMI 50, the DKS 3 transmits the service key deletion command to the owner terminal and all guest terminals linked to the owner terminal.

[0236] When the mobile terminal 1 receives the service key deletion command, it verifies the validity of the command using the terminal check code, and then deletes all data related to the specified service key from the key information storage unit M1 (step T57). In a more preferable embodiment, when the service key deletion process is completed, each mobile terminal 1 reports this fact to the DKS 3.

[0237] As described above, the owner can delete the service key of any guest even by using the in-vehicle HMI 50. Also, the owner can delete the owner key by using the in-vehicle HMI 50. In addition, instead of the owner, the staff at the dealership can execute the same deletion process by using the in-vehicle HMI 50.

[0238] Note that the authentication ECU 4 may be configured to execute the deletion process of the owner key using the in-vehicle HMI 50 on the condition that a security release signal is input from the security release tool or the DKS 3. According to such a configuration, the risk that the owner key and all guest keys associated therewith are deleted due to an operation mistake or an unauthorized operation can be reduced. The deletion of the owner key has a greater influence range than the deletion of the guest key. Therefore, the user authentication for deleting the owner key may be configured to be more advanced / complicated than the user authentication for deleting the guest key. For example, the number of steps of the user authentication for deleting the owner key may be set to be more than the number of steps of the user authentication when deleting the guest key.

[0239] Also, the DKS 3 transmits different data to the owner terminal according to whether the deletion operation of the owner key is performed via the in-vehicle HMI 50 as described above. For example, when the deletion operation of the owner key is performed on the owner terminal, the DKS 3 transmits the vehicle owner key deletion package to the owner terminal, while when the deletion operation of the owner key is performed on the in-vehicle HMI 50, the DKS 3 does not transmit the vehicle owner key deletion package. According to this configuration, the data communication volume of the owner terminal can be suppressed. Also, originally, when the deletion operation of the owner key is performed on the in-vehicle HMI 50, the authentication ECU 4 deletes all service keys without receiving the deletion data set from the DKS 3. That is, the communication volume of the DKS 3 itself can also be reduced.

[0240] <Supplement to the method for managing service keys by DKS> The DKS3 manages all guest keys associated with one owner key by the service key ID of the owner key. Even if the DKS3 deletes a guest key with issuance rights, as shown in FIG. 34, it does not delete the grandchild / third generation guest keys issued with the authority of the guest key with issuance rights. The grandchild / third generation guest keys remain as guest keys associated with the owner key. In FIG. 34, 1x indicates the owner key, 1y indicates the guest key with issuance rights, and 1z indicates the grandchild / third generation guest key. 1v is a guest key issued by the owner key, and it is optional whether or not it has issuance rights. For convenience, a group of guest keys associated with one owner key is also called a family. The service keys that make up a family are managed by the owner key ID.

[0241] Furthermore, the DKS3 is configured to be able to accept an application for changing the model of the mobile terminal 1 by the user. When the user changes the model, the device ID may change. However, the service key ID is not changed even when the model is changed. Since the family is formed by the service key ID of the owner key, even if the owner changes the model of the mobile terminal 1, the guest key is not affected and the family itself continues to exist. For example, even if the owner changes the model of the mobile terminal 1, only the device ID and service key of the owner terminal are changed. The same applies when the mobile terminal 1 of the guest having the issuing authority is changed. In other words, the vehicle digital key system Sys is configured not to affect other guest keys even if the mobile terminal 1 that issues the guest key is changed to another device.

[0242] The DKS 3 performs the owner terminal change process, for example, in the procedure shown in FIG. 35. The owner terminal change process is a process related to a model change of the owner terminal. As shown in FIG. 35, the owner terminal authentication process may include steps T61 to T68. The owner terminal change process is started based on the input of a signal corresponding to a request for a model change from the mobile terminal 1 or a PC. The terminal operated by the owner may be the old terminal, which is the mobile terminal 1 before the model change, or may be the new terminal, which is the mobile terminal 1 after the model change. In addition, the device for which the owner applies for a model change may be any terminal that can access the Internet, such as a desktop / laptop PC. It is assumed that the digital key application 104 is installed in the new terminal by a predetermined data transfer operation by the owner, and information such as a user ID is registered.

[0243] Step T61 is a step for authenticating that the operator / applicant is the owner. The method for authenticating that the operator is the owner is as described above. When the DKS3 authenticates that the operator is the owner, it refers to the user DB33 based on the user ID etc., and acquires the owner's old device ID and service key ID (step T62). The old device ID indicates the device ID of the old terminal. The DKS3 also acquires a new device ID, which is the device ID of the new terminal, by performing data communication with the new terminal (step T63). Step T64 is a step in which the DKS3 uses the new device ID to issue a new service key as the owner key. The specific method for generating the service key is as described above.

[0244] When the DKS3 generates a new owner key, it updates the registration contents of the user DB33 (step T65). For example, in the user data of the owner, the old owner key is deleted and a new owner key is registered. The old owner key is a service key that was used before the model change and is a service key based on the old device ID. In this embodiment, even if the device of the owner is changed, the service key ID of the owner is not changed and the previous ID is maintained, so that no special measures are required for the user data of the guest. As another aspect, when the service key ID is also changed, the DKS3 may replace the service key ID of the owner linked to the guest key with the new owner key ID. In addition, when the DKS3 generates a new owner key, it creates a predetermined number of one-time authentication keys corresponding to the new owner key.

[0245] Then, the DKS3 transmits a terminal key exchange package to the new terminal (step T66). The terminal key exchange package includes at least the new owner key. The terminal key exchange package may be a command / program for replacing the owner key stored in the key information storage unit M1 with the new owner key. The terminal key exchange package may include multiple one-time authentication keys corresponding to the new owner key and a variable code. In addition, the terminal key exchange package may include a terminal check code. A data set related to the one-time authentication key may be transmitted as an authentication key package separately from the terminal key exchange package.

[0246] When the mobile terminal 1 as the new terminal receives the terminal key exchange package from the DKS3, it verifies the validity of the data based on the terminal check code, and then stores the received data related to the new owner key in the key information storage unit M1. Specifically, the terminal processor 101 stores the service key as the received new owner key and multiple one-time authentication keys linked to the variable codes.

[0247] In addition, the DKS 3 transmits to the new terminal a vehicle key exchange package, which is a data set for registering data related to the new owner key in the authentication ECU 4. The vehicle key exchange package includes a service key as the new owner key and a vehicle check code. The vehicle key exchange package may be a command / program for replacing the owner key stored in the vehicle-side storage unit 45 with the new owner key.

[0248] When the mobile terminal 1 serving as the new terminal receives the vehicle key exchange package, it stores it in the vehicle data temporary storage unit M2. Then, based on the establishment of a BLE encryption communication link with the authentication ECU 4, it transfers the vehicle key exchange package to the authentication ECU 4. That is, the vehicle key exchange package is also distributed to the authentication ECU 4 via the mobile terminal 1 in the same way as the vehicle registration package.

[0249] When the authentication ECU 4 receives the vehicle key exchange package, it verifies the validity of the data based on the vehicle check code, and then stores the received data related to the new owner key in the vehicle-side storage unit 45. Specifically, the authentication processor 41 stores the received service key as the new owner key in the owner key storage unit 451. In addition, the authentication ECU 4 deletes the old owner key stored in the owner key storage unit 451. The service key ID is maintained even after the model change, so it may be reused without being deleted. Of course, the service key ID may also be deleted once and then newly registered.

[0250] In addition, when the authentication ECU 4 receives an operation to register an owner key while the owner key is stored in the owner key storage unit 451, the authentication ECU 4 may display a predetermined warning message on the display 11, 51. The warning message is, for example, a message indicating that the owner has already been registered. In addition, when the authentication ECU 4 receives an operation to register an owner key while the owner key is stored in the owner key storage unit 451, the authentication ECU 4 may display a screen on the display 11, 51 prompting the user to input a predetermined password. The password that is requested to be input here may be, for example, a password linked to the owner's user ID or a predetermined code for deleting the owner key.

[0251] Additionally, in step T68, the DKS 3 transmits a service key deletion command to the old terminal. As a result, if the old terminal maintains an online state, the service key is deleted from the old terminal. Note that step T68 is an optional element and may be omitted.

[0252] <Other supplementary information for the entire system> In the above, the vehicle Hv is assumed to be an individual owned vehicle, and the owner is also an individual, as an example, but the above vehicle digital key system Sys can also be applied to MaaS (Mobility as a Service). The owner may be, for example, a company / organization that provides a vehicle rental service or a sharing service. In this case, a staff member belonging to the company / organization as an operator may operate the owner terminal. The owner may own a large number of vehicles Hv, such as 50 or 100 vehicles. The service key ID of the owner may be common to multiple vehicles or may be different for each vehicle. The configuration of the DKS3 may be divided into a server that manages vehicle information and a server that manages service keys, depending on the type of business.

[0253] In the above embodiment, the authentication ECU 4 acquires data related to the registration / deletion of the service key from the mobile terminal 1, but the present invention is not limited to this. The authentication ECU 4 may be configured to receive various packages from the DKS 3 by cellular communication or Wi-Fi communication without going through the mobile terminal 1.

[0254] <Additional remarks (1)> The mobile terminal 1 described above is Transmitting an owner key issuance request signal to a server (3) that generates a service key for using a vehicle based on a user's operation, requesting the issuance of an owner key that is a service key for a vehicle owned by the user and that has authority as an owner; receiving an owner key from the server as a response from the server to the owner key issuance request signal; storing the received owner key in a predetermined terminal side storage device (105); It can be understood as a portable, general-purpose information processing terminal configured to execute the following, on condition that a short-range wireless communication communication link has been established with a vehicle device (4) installed in the vehicle: initiate communication for registering an owner key in the vehicle device.

[0255] The digital key application 104 can be understood as a computer program that causes a general-purpose computer to execute the program as the mobile terminal 1. In addition, the storage medium in which the digital key application 104 is stored corresponds to a storage medium in which an instruction set for operating a computer as the mobile terminal 1 is stored.

[0256] <Additional remarks (2)> The apparatus, systems, and techniques described herein may be implemented using a special purpose computer comprising a processor programmed to perform one or more functions embodied in a computer program. The apparatus and techniques described herein may also be implemented using special purpose hardware logic circuitry. The apparatus and techniques described herein may also be implemented using one or more special purpose computers comprising a processor executing a computer program in combination with one or more hardware logic circuits.

[0257] For example, some or all of the functions of the authentication processor may be realized as hardware. A form in which a certain function is realized as hardware includes a form in which it is realized using one or more ICs. A CPU, an MPU, a GPU, a DFP (Data Flow Processor), or the like may be adopted as a processor (computation core). Also, some or all of the functions of the authentication processor may be realized by combining multiple types of computation processing devices. Some or all of the functions of the authentication processor may be realized by using a system-on-chip (SoC), an FPGA, an ASIC, or the like. FPGA stands for Field-Programmable Gate Array. ASIC stands for Application Specific Integrated Circuit. The above supplementary explanation is similarly applicable to the terminal processor and the server processor. Also, the computer program may be stored in a computer-readable non-transitive tangible storage medium as instructions executed by a computer. As a storage medium for the program, a hard-disk drive (HDD), a solid-state drive (SSD), a flash memory, or the like may be adopted. [Explanation of symbols]

[0258] 1 Mobile terminal, 2 Dedicated key, 3 Digital key server (DKS), 4 Authentication ECU, 7 In-vehicle system, 10 Terminal control unit, 11 Display, 12 Touch panel (input device), 16-57 BLE communication unit (near-field communication unit), 17 Cellular communication unit (Internet connection unit), 18 Wi-Fi communication unit (Internet connection unit) 101 Terminal processor, 104 Digital key app, 105 Terminal side memory unit (Terminal side storage device), M1 Suspicious information memory unit, M2 Primary vehicle data memory unit, 20 Control circuit, 21-56 Near-field communication unit, 30 Data processing unit, 32 Vehicle database, 33 User database, 301 Server processor, 303 Storage, 40 Vehicle control unit, 41 Authentication processor, 45 Vehicle side memory unit (Vehicle side storage device), 451 Owner key memory unit, 452 Guest key memory unit, 50 In-vehicle HMI, 51 Display, 52 Input device.

Claims

1. A vehicle device (4) for use mounted on a vehicle; A portable terminal (1) which is an information processing terminal carried by a user; a server (3) that generates a service key unique to each of the mobile terminals as key information for using the vehicle, and distributes the service key directly or indirectly to each of the mobile terminals and the vehicle device, the vehicle device and the mobile terminal are configured to be able to communicate data with each other by short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, the server generates a plurality of one-time authentication keys, each of which has a validity period and is disposable, by combining the service key with a different variable code based on a request from the mobile terminal, and delivers the one-time authentication keys together with information indicating the variable code to the mobile terminal; The mobile terminal includes: receiving information indicating the variable code used in generating the one-time authentication key together with the one-time authentication key from the server, and storing the information in a predetermined terminal-side storage device (105); replacing a part or all of the one-time authentication keys stored in the terminal side storage device based on an expiration date of each one-time authentication key; transmitting the variable code to the vehicle device on condition that the short-range wireless communication link has been established between the vehicle device and the vehicle device; The vehicle device includes: a vehicle-side storage device (45) for storing the service key for the mobile terminal issued by the server, generating the one-time authentication key by combining the service key of the portable terminal stored in the vehicle-side storage device and the variable code received from the portable terminal; and determining the authenticity of the mobile terminal using the generated one-time authentication key.

2. A vehicle device (4) for use mounted on a vehicle; A portable terminal (1) which is an information processing terminal carried by a user; a server (3) that generates a service key unique to each of the mobile terminals as key information for using the vehicle, and distributes the service key directly or indirectly to each of the mobile terminals and the vehicle device, the vehicle device and the mobile terminal are configured to be able to communicate data with each other by short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, the server generates a plurality of disposable one-time authentication keys based on the service key in response to a request from the mobile terminal, and delivers the disposable one-time authentication keys to the mobile terminal with a validity period; The mobile terminal includes: receiving the one-time authentication key from the server and storing it in a predetermined terminal-side storage device (105); replacing a part or all of the one-time authentication keys stored in the terminal-side storage device based on the expiration date of each one-time authentication key; The vehicle device includes: acquiring the one-time authentication keys issued to the mobile terminal from the mobile terminal or the server and storing the one-time authentication keys in a vehicle-side storage device (45); exchanging an adjustment message with the portable terminal via the short-range wireless communication to match the one-time authentication key to be used in the authentication process among the plurality of one-time authentication keys issued by the server; and determining authenticity of the mobile terminal using the one-time authentication key identified based on the adjustment message.

3. 3. The digital key system for a vehicle according to claim 1, The mobile terminal includes: a determination as to whether or not the remaining number of the one-time authentication keys stored in the terminal-side storage device is less than a predetermined value is performed periodically or based on detection of an occurrence of a predetermined confirmation event, A digital key system for a vehicle configured to execute communication to obtain the one-time authentication key from the server if the system is able to access the Internet when it detects that the remaining number of the one-time authentication key is less than a predetermined value.

4. 4. A digital key system for a vehicle according to claim 1, The server, a database (33) in which information on an owner terminal, which is the mobile terminal possessed by the owner of the vehicle, is stored in association with information on an owner key, which is the service key for which the owner has authority; is configured to be able to issue a guest key, which is the service key for a guest who is a user other than the owner, based on receiving a predetermined guest key issuance request signal issued from the owner terminal; There are two types of guest keys: a guest key with issuance authority that has authority to issue other guest keys, and a guest key without issuance authority that does not have authority to issue other guest keys, A digital key system for a vehicle is configured to, when issuing the guest key based on a request from the owner terminal, determine whether the guest key is to be a guest key with issuance authority or a guest key without issuance authority based on a signal received from the owner terminal.

5. 5. The digital key system for a vehicle according to claim 4, The mobile terminal having the guest key with issuing authority or the owner terminal transmits, based on a user operation, a data set including setting information of an authority to be granted to the newly issued guest key as the guest key issuance request signal; The server issues the guest key having restrictions according to the setting information acquired from a source of the guest key issuance request.

6. 6. The digital key system for a vehicle according to claim 5, The owner terminal is configured to be able to accept an operation to selectively delete the guest key linked to the vehicle, but is configured not to accept an operation to change only the settings related to the expiration date or authority without deleting the guest key.

7. 7. A digital key system for a vehicle according to claim 4, The server, storing a plurality of the guest keys associated with one of the vehicles in the database in association with an owner key number which is an identification number associated with the owner key; A digital key system for a vehicle configured to manage the service key linked to one of the vehicles based on the owner key number.

8. 8. The digital key system for a vehicle according to claim 7, A digital key system for a vehicle, wherein when the server issues the guest key based on a request from the owner terminal, the server distributes the owner key number together with the guest key to the guest terminal, which is the mobile terminal corresponding to the guest key.

9. 9. The digital key system for a vehicle according to claim 7 or 8, The server, A configuration is provided in which the mobile terminal owned by the user can be changed, A digital key system for a vehicle configured such that the service key distributed to the guest linked to the owner is not deleted even if the mobile terminal possessed by the owner is changed.

10. 10. A digital key system for a vehicle according to claim 1, a guest key, which is a service key for a guest who is a user other than the owner of the vehicle, has an expiration date set thereto, the expiration date being specified by a source of a request for issuance of the guest key; The vehicle digital key system is configured such that the vehicle device automatically deletes information about the guest key that has expired.

11. 11. A digital key system for a vehicle according to claim 1, the vehicle device and the mobile terminal are configured to be able to communicate data with each other by short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, The server and the mobile terminal are configured to be able to communicate with each other via the Internet, The vehicle device includes: acquiring time information from the server via the portable terminal based on the establishment of the short-range wireless communication link with the portable terminal; and correcting an internal time, which is time information held in the vehicle device, using the acquired time information.

12. A portable terminal (1) which is an information processing terminal carried by a user; a vehicle device (4) configured to be capable of mutual data communication with the mobile terminal by short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, and mounted and used in a vehicle; a server (3) that generates a service key unique to each of the mobile terminals as key information for using the vehicle, the method comprising: the vehicle device includes a vehicle-side storage device (45) that stores the service key of the mobile terminal; the server generates a plurality of one-time authentication keys, each of which has a validity period and is disposable, by combining a plurality of different variable codes with the service key of the mobile terminal based on a request from the mobile terminal, and delivers the one-time authentication keys together with information indicating the variable codes to the mobile terminal; The mobile terminal receives, from the server, the one-time authentication key and information indicating the variable code used in generating the one-time authentication key, and stores the information in a predetermined terminal-side storage device (105); the mobile terminal periodically replaces a part or all of the one-time authentication keys stored in the terminal-side storage device based on an expiration date of each one-time authentication key; transmitting the variable code to the vehicular device, on condition that the short-range wireless communication link between the portable terminal and the vehicular device has been established; the vehicular device generates the one-time authentication key by combining the service key of the portable terminal stored in the vehicle-side storage device and the variable code received from the portable terminal; The vehicle device determines the authenticity of the mobile terminal using the generated one-time authentication key.

13. A portable terminal (1) which is an information processing terminal carried by a user; a vehicle device (4) configured to be capable of mutual data communication with the mobile terminal by short-range wireless communication that is wireless communication conforming to a predetermined short-range wireless communication standard, and mounted and used in a vehicle; a server (3) that generates a service key unique to each of the mobile terminals as key information for using the vehicle, the method comprising: the server generates a plurality of disposable one-time authentication keys based on the service key of the mobile terminal in response to a request from the mobile terminal, and delivers the disposable one-time authentication keys with expiration dates to the mobile terminal; The mobile terminal receives the one-time authentication key from the server and stores it in a predetermined terminal-side storage device (105); the mobile terminal periodically replaces a part or all of the one-time authentication keys stored in the terminal-side storage device based on an expiration date of each one-time authentication key; The vehicle device acquires the one-time authentication keys issued to the mobile terminal from the mobile terminal or the server, and stores the one-time authentication keys in a vehicle-side storage device (45); the vehicular device exchanging an adjustment message with the portable terminal via the short-range wireless communication for matching the one-time authentication key to be used in an authentication process among the plurality of one-time authentication keys issued by the server; The vehicle device determines the authenticity of the mobile terminal using the one-time authentication key identified based on the adjustment message.

Images