In-vehicle device, control method, and program

Abstract

The present invention provides an in-vehicle device that can prevent information regarding digital keys usable under a contract from remaining stored after the contract has been terminated. [Solution] The storage device stores authentication information AT as information related to the vehicle's digital key. In step S21, the execution device obtains contract information CT from an external source indicating whether or not there is a contract to enable the use of the digital key. On the condition that the obtained contract information CT indicates that there is no contract (S22: YES), the execution device deletes the information related to the digital key stored in the storage device in step S26.

Description

Technical Field

[0001] The present invention relates to an in-vehicle device, a control method, and a program.

Background Art

[0002] Patent Document 1 describes a digital key system. The digital key system includes an in-vehicle device mounted on a vehicle and a device. The in-vehicle device stores information regarding a digital key for using the device as a digital key.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] A digital key system as described in Patent Document 1 may require a contract to enable the use of a digital key. In this case, when the state changes from having a contract to not having a contract, the in-vehicle device may keep the information regarding the digital key that can be used under the contract stored.

Means for Solving the Problems

[0005] An in-vehicle device for solving the above problems includes a storage device and an execution device. The storage device stores information regarding a digital key of a vehicle. The execution device acquires contract information indicating the presence or absence of a contract that enables the use of the digital key from the outside, and performs control to delete the information regarding the digital key stored in the storage device on the condition that the acquired contract information indicates that there is no contract.

[0006] A control method for solving the above problem is a control method executed by an in-vehicle device that stores information about a vehicle's digital key, wherein the in-vehicle device obtains contract information from an external source indicating whether or not there is a contract to enable the use of the digital key, and, on the condition that the obtained contract information indicates that there is no such contract, performs control to delete the stored information about the digital key.

[0007] The program for solving the above problem is a program to be executed by an in-vehicle device that stores information about the vehicle's digital key, and the program causes the in-vehicle device to obtain contract information from an external source indicating whether or not there is a contract that allows the digital key to be used, and to execute a control to delete the stored information about the digital key, provided that the obtained contract information indicates that there is no such contract. [Effects of the Invention]

[0008] Each of the above configurations can prevent information about the digital keys usable under the contract from remaining stored after the contract has been terminated. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a schematic diagram showing a management system of one embodiment. [Figure 2] Figure 2 is an explanatory diagram showing a series of processes performed by the management system of this embodiment in accordance with a deletion request. [Figure 3] Figure 3 is a flowchart showing the deletion control process performed by the digital key ECU in the same embodiment. [Figure 4] Figure 4 is a timing chart showing the storage status of each piece of information when the communication status between the vehicle and the management server in this embodiment is always within range. [Figure 5] Figure 5 is a timing chart showing the storage status of each piece of information when the communication status between the vehicle and the management server in this embodiment changes from outside the service area to within the service area. [Modes for carrying out the invention]

[0010] The following describes one embodiment of the in-vehicle device with reference to the drawings. First, the management system 10 will be described. <Overview of the management system> As shown in Figure 1, the management system 10 manages multiple digital keys available for the vehicle 20. Regarding digital keys, there is a standard set by the Car Connectivity Consortium (CCC). While the digital key aspects of this embodiment assume compliance with the CCC, they are also applicable to other standards and systems.

[0011] The management system 10 comprises a vehicle 20, multiple devices 40, a card key 51, a smart key (registered trademark) 52, a device server 60, and a management server 70. The devices 40 are used as digital keys.

[0012] Vehicle 20 includes a communication module 21, an HMI 22, a BLE module 23, a UWB module 24, an NFC module 25, and an in-vehicle device, a digital key ECU 26. HMI stands for Human Machine Interface. BLE stands for Bluetooth® Low Energy. UWB stands for Ultra Wide Band. NFC stands for Near Field Communication.

[0013] The communication module 21 communicates with the management server 70 via a wireless communication network. The HMI 22 includes an input device that accepts user input for the vehicle 20, and a presentation device that presents information to the user using images and sound, etc. The presentation device is, for example, a monitor and a speaker.

[0014] The BLE module 23 communicates with the device 40 via BLE communication. The UWB module 24 communicates with the device 40 via UWB communication. The UWB module 24 measures the distance between the device 40 and the vehicle 20.

[0015] The NFC module 25 performs short-range communication with the device 40 via NFC communication. The NFC module 25 performs short-range communication with the card key 51 via NFC communication. The digital key ECU 26 is mounted on the vehicle 20. The digital key ECU 26 manages the digital keys of the vehicle 20. The digital key ECU 26 has an execution device 27 and a storage device 28. The storage device 28 stores authentication information AT as information regarding the digital key. The authentication information AT is information for authenticating the digital key in order to enable control of the vehicle 20 by the digital key when using the digital key. The authentication information AT is provided for each digital key to be authenticated.

[0016] Note that authenticating the digital key means enabling the vehicle 20 to be controlled by the digital key. For example, when the digital key ECU 26 authenticates the digital key, the digital key ECU 26 enables the vehicle 20 to be unlocked. Also, for example, when the digital key ECU 26 authenticates the digital key, the digital key ECU 26 enables the vehicle 20 to be started.

[0017] The storage device 28 stores various programs for performing processes related to the digital key. The execution device 27 is a CPU. The execution device 27 executes processes related to the digital key by executing various programs.

[0018] The storage device 28 stores a vehicle program PV. The vehicle program PV is a program for causing the execution device 27 to perform deletion control for deleting the authentication information AT when executed by the execution device 27. The execution device 27 performs deletion control for deleting the authentication information AT by executing the vehicle program PV.

[0019] Also, the storage device 28 stores various programs for performing processes related to the card key 51. The execution device 27 executes processes related to the card key 51 by executing various programs.

[0020] For example, when the NFC module 25 communicates with the card key 51 by holding the card key 51 near an antenna provided on the outer side of the NFC module 25, the execution device 27 determines that the authentication for the card key 51 is successful. Then, the execution device 27 enables the unlocking of the door of the vehicle 20.

[0021] Also for example, when the NFC module 25 communicates with the card key 51 by placing the card key 51 near an antenna provided at the driver's seat of the NFC module 25, the execution device 27 determines that the authentication for the card key 51 is successful. Then, the execution device 27 enables the starting of the vehicle 20.

[0022] The vehicle 20 has an LF module 31, an RF module 32, and a smart key ECU 33. LF is the abbreviation of Low Frequency. RF is the abbreviation of Radio Frequency.

[0023] The LF module 31 performs wireless communication with the smart key 52 using an LF signal. The RF module 32 performs wireless communication with the smart key 52 using an RF signal. The smart key ECU 33 controls the smart key 52 of the vehicle 20. The smart key ECU 33 has an execution device 34 and a storage device 35. The storage device 35 stores various programs related to the smart key 52. The execution device 34 executes the programs stored in the storage device 35 to perform processing related to the authentication of the smart key 52.

[0024] For example, when the outer handle of the vehicle 20 is operated, the execution device 34 transmits an LF signal from the LF module 31 to the smart key 52. ​​Upon receiving the LF signal, the smart key 52 transmits an RF signal, including an individually set authentication signal, to the RF module 32. Based on the authentication signal included in the RF signal received by the RF module 32 from the smart key 52, the smart key ECU 33 authenticates the smart key 52. ​​When the authentication signal acquired by the smart key ECU 33 matches a predetermined authentication signal, the smart key ECU 33 completes the authentication for the smart key 52. ​​The smart key ECU 33 then enables, for example, the unlocking of the vehicle 20's doors. Alternatively, the smart key ECU 33 enables the vehicle 20 to start.

[0025] Device 40 is a portable information terminal such as a smartphone. Device 40 includes a communication module 41, an HMI 42, a BLE module 43, a UWB module 44, an NFC module 45, an execution device 46, and a storage device 47.

[0026] The communication module 41 communicates with the device server 60 via a wireless communication network. The HMI 42 includes an input device that accepts user input for the device 40, and a presentation device that presents information to the user through images, sound, etc. The presentation device is, for example, a monitor and a speaker.

[0027] The BLE module 43 communicates with the vehicle 20 via BLE communication. The UWB module 44 communicates with the vehicle 20 via UWB communication. The NFC module 45 communicates with the vehicle 20 via NFC communication.

[0028] The storage device 47 stores key information DK as information related to the digital key. Key information DK is information that indicates the digital key. Key information DK is also information that makes device 40 available as a digital key.

[0029] The storage device 47 stores various programs for processing digital keys. The programs stored in the storage device 47 include, for example, a device application and a digital key framework. The device application is an application for storing and deleting key information DK. The digital key framework is a program that provides functions for pairing devices 40 and sharing digital keys using APIs provided by the OS. The execution device 46 executes the various programs stored in the storage device 47 to perform processing related to storing and deleting key information DK.

[0030] Multiple devices 40 include an owner device 40A and multiple share devices 40B. Note that in Figure 1, only one share device 40B is illustrated. The owner device 40A stores owner key information DKO, which indicates the owner key, as key information DK. Only one owner key can be registered for each vehicle 20. Therefore, there is only one owner key for each vehicle 20. The owner key information DKO is information that makes device 40 available as an owner device 40A.

[0031] The owner key information DKO includes, for example, vehicle information that identifies the target vehicle 20, identification information used for managing the digital key, certificate information that proves the digital key, public key information of the owner device 40A, and public key information of the vehicle 20. The device 40 that becomes the owner device 40A becomes the owner device 40A by pairing with the vehicle 20 and storing the owner key information DKO.

[0032] The share device 40B stores share key information DKS, which indicates the share key, as key information DK. A share key is a digital key that can be registered multiple times for a single vehicle 20 in order to register a digital key in order to enable the use of the digital key. In other words, multiple share keys can exist for a single vehicle 20.

[0033] The Share Key Information DKS is information that enables device 40 to be used as a shared device 40B. The Share Key Information DKS includes, for example, vehicle information that identifies the target vehicle 20, identification information used for managing the digital key, certificate information that certifies the digital key, and an authentication package from device 40 that authenticated the registration. The authentication package includes signature information, password information, effective start information, expiration information, and the public key information of shared device 40B.

[0034] Furthermore, device 40, which becomes shared device 40B, stores the share key information DKS when it is shared by owner device 40A. As a result, device 40 becomes shared device 40B.

[0035] In other words, a share key is a digital key that becomes usable when the owner device 40A shares the digital key. Therefore, a share key is a digital key that enables the use of a share device 40B that is different from the owner device 40A, assuming that the owner key is already registered.

[0036] Furthermore, when a digital key is registered, it means that the digital key is usable. In other words, when a digital key is registered, the vehicle 20 stores the authentication information AT, and the device 40 stores the key information DK.

[0037] The device server 60 relays communication between the device 40 and the management server 70. A separate device server 60 is provided for each type of device 40. That is, the device server 60 that a first-type device 40 communicates with is different from the device server 60 that a second-type device 40 communicates with. For example, "type" refers to the model of the device 40, and a separate device server 60 is provided for each model of the device 40. For example, "type" also refers to the communication line used by the device 40, and a separate device server 60 is provided for each communication line used by the device 40.

[0038] Each device server 60 relays communication with the management server 70, allowing different types of devices 40 to communicate with the management server 70 via the device server 60. Note that only one device server 60 is shown in Figure 1.

[0039] <Management Server> The management server 70 manages digital keys. The management server 70 can communicate with the vehicle 20 and multiple devices 40. The management server 70 comprises an execution device 71 and a storage device 72. The storage device 72 stores a server program PS, contract information CT, and a database DB. The server program PS is executed by the execution device 71, causing the execution device 71 to delete digital keys in the database DB.

[0040] Contract Information CT indicates whether the owner of vehicle 20 has a contract with a provider of digital key services. This contract allows the digital key to be used by subscribing to the digital key service.

[0041] The database DB associates each of the multiple digital keys with the corresponding vehicle 20 and the registered device 40. The database DB is divided into sections for each vehicle 20. When a digital key is registered, the management server 70 stores information in the data indicating the device 40 that stores the key information DK representing that digital key.

[0042] Next, a series of processes for deleting a digital key in the management system 10 will be described. When the management server 70 receives a change request D10, the management system 10 performs a series of processes for deleting the digital key. The change request D10 is a request to change the contract information CT from a state indicating that a contract exists to a state indicating that there is no contract. The change request D10 is obtained by the management server 70, for example, when the owner device 40A is operated.

[0043] In the following explanation, the processes executed by the execution device 27 will be described as processes executed by the vehicle 20, the processes executed by the execution device 46 will be described as processes executed by the device 40, and the processes executed by the execution device 71 will be described as processes executed by the management server 70.

[0044] As shown in Figure 2, the management system 10 performs a series of operations to delete a registered digital key. When the management server 70 receives the change request D10, the management server 70 starts executing the server program PS. Once the management server 70 starts executing the server program PS, the management server 70 first performs the process in step S11.

[0045] In step S11, the management server 70 generates a deletion request for all key information DKs that indicate digital keys that are available through the contract information CT, which is the subject of the change request D10.

[0046] Specifically, the management server 70 identifies the owner key available through the contract indicated by the contract information CT, and the share key registered based on a registration request from the owner device 40A which stores the owner key information DKO indicating the said owner key. Next, the management server 70 generates a deletion request D11 to delete the identified owner key and a deletion request D12 to delete the identified share key.

[0047] Subsequently, the management server 70 sends a deletion request D11 to the owner device 40A. When the owner device 40A receives the deletion request D11, the owner device 40A performs the process in step S12.

[0048] In step S12, the owner device 40A deletes the owner key information DKO in accordance with the deletion request D11. As a result, the owner device 40A becomes unable to use the owner key.

[0049] After the management server 70 sends deletion request D11, the management server 70 sends deletion request D12 to the share device 40B. When the share device 40B receives deletion request D12, the share device 40B performs the process in step S13.

[0050] In step S13, the share device 40B deletes the share key information DKS in accordance with the deletion request D12. As a result, the share device 40B becomes unable to use the share key.

[0051] After the management server 70 sends the deletion request D12, the management server 70 proceeds to step S13. In step S13, the management server 70 stores the deletion history of key information DK in the database DB. After that, the management server 70 proceeds to step S14.

[0052] In step S14, the management server 70 generates a deletion request D13 for authentication information AT for authenticating the owner key identified in the process of step S11, and for authentication information AT for authenticating the share key identified in the process of step S11.

[0053] Subsequently, the management server 70 sends a deletion request D13 to the vehicle 20. When the vehicle 20 receives the deletion request D13, the vehicle 20 performs the process in step S15. In step S15, vehicle 20 deletes the authentication information AT in accordance with the deletion request D13. As a result, vehicle 20 becomes unable to authenticate the digital key.

[0054] Subsequently, vehicle 20 sends a completion notification M11 to the management server 70 indicating that the deletion of authentication information AT has been completed. When the management server 70 receives the completion notification M11, the management server 70 performs the process in step S16. In step S16, the management server 70 stores the deletion history of the authentication information AT in the database DB. After that, the management server 70 proceeds to step S17.

[0055] In step S17, the management server 70 updates the database DB. Specifically, the management server 70 deletes the information indicating the device 40 that stores the key information DK representing the digital key from the data for the target vehicle 20. After that, the management server 70 proceeds to step S18.

[0056] In step S18, the management server 70 changes the contract information CT to a state indicating that there is no contract. After that, the management server 70 terminates this series of processes. In this way, the management system 10 deletes information about digital keys that are available on the premise that the contract targeted by change request D10 exists. As a result, the management system 10 manages the system so that digital keys that are available on the premise that the contract targeted by change request D10 exists are unavailable.

[0057] <Vehicle Deletion Control> Next, we will explain the control for deleting authentication information AT in vehicle 20. When the communication status between the communication module 21 and the management server 70, which is an external server of the vehicle 20, changes from an area where communication is impossible to an area where communication is possible, the execution device 27 starts executing the vehicle program PV. However, the execution device 27 does not execute the vehicle program PV if the storage device 28 does not store the authentication information AT.

[0058] As shown in Figure 3, when the execution device 27 starts executing the vehicle program PV, the execution device 27 first performs the process in step S21. In step S21, the execution device 27 obtains contract information CT from the management server 70. Therefore, the execution device 27 obtains contract information CT when the communication status of the vehicle 20 with the outside world changes from outside the coverage area to within the coverage area.

[0059] In detail, when the communication status is within range, the communication module 21 acquires contract information CT from the management server 70 at predetermined intervals. As a result, the communication module 21 stores information synchronized with the contract information CT stored in the storage device 72 of the management server 70. When the communication status changes from outside range to within range, the communication module 21 acquires contract information CT from the management server 70, thereby synchronizing the information stored in the communication module 21 with the latest contract information CT. In this state, the execution device 27 acquires contract information CT from the communication module 21, thereby acquiring information synchronized with the latest contract information CT stored in the storage device 72 of the management server 70. After that, the execution device 27 proceeds to step S22.

[0060] In step S22, the execution device 27 determines whether the acquired contract information CT indicates that there is no contract. Specifically, the execution device 27 determines that the acquired contract information CT indicates that there is no contract if it indicates the same contract as the one indicated by the contract information CT acquired before going out of range.

[0061] In other words, if the acquired contract information CT indicates that there are no contracts, the same as the one acquired last time, the execution device 27 makes an affirmative judgment. On the other hand, if the acquired contract information CT indicates that there are no contracts at all, or if the acquired contract information CT indicates that there are contracts different from the ones acquired last time, the execution device 27 makes a negative judgment. If the acquired contract information CT indicates that there are contracts (S22: NO), the execution device 27 terminates this series of processes. In other words, in this case, the execution device 27 does not delete the authentication information AT.

[0062] On the other hand, if the acquired contract information CT indicates that there is no contract (S22: YES), the execution device 27 proceeds to step S23. In step S23, the execution device 27 determines whether authentication was successful for the card key 51 or smart key 52, which are keys other than the digital key, when starting the vehicle 20.

[0063] In detail, when authentication for starting the vehicle 20 using the card key 51 is successful, or when authentication for starting the vehicle 20 using the smart key 52 is successful using the smart key ECU 33, the execution device 27 makes a positive determination regarding the process in step S23. After that, the execution device 27 proceeds to step S24.

[0064] In step S24, the execution device 27 increments a counter that counts the number of successful authentications SN when starting the vehicle 20 with a key other than the digital key. This counter is stored, for example, in the storage device 28. The execution device 27 then proceeds to step S25.

[0065] In step S25, the execution device 27 determines whether the number of successful occurrences SN is equal to the specified number RN. The specified number RN is two or more predetermined numbers determined by testing or simulation. The specified number RN is determined, for example, as the number of times it is expected that the user can continuously use the vehicle 20 using a different key. In this embodiment, the specified number RN is 2.

[0066] If the number of successful occurrences SN is less than the specified number RN (S25: NO), the execution device 27 returns to step S23. On the other hand, if the number of successful occurrences SN is equal to the specified number RN (S25: YES), the execution device 27 proceeds to step S26.

[0067] In step S26, the execution device 27 deletes the authentication information AT. Specifically, it deletes all the authentication information AT for multiple digital keys stored in the storage device 28. After that, the execution device 27 terminates this series of processes.

[0068] In this way, the execution device 27 deletes the authentication information AT in step S26, provided that the acquired contract information CT indicates the existence of a contract (S22: NO). Furthermore, the execution device 27 deletes the authentication information AT in step S26, provided that the number of successful transactions SN has reached the specified number RN (S25: YES). The execution device 27 executes a control method for deletion control by executing the vehicle program PV.

[0069] <Operation of the Embodiment> Next, the operation of this embodiment will be described in two cases: when the communication status between the vehicle 20 and the management server 70 is always within range, and when the communication status between the vehicle 20 and the management server 70 changes from outside the range to within range.

[0070] As shown in Figure 4, if the communication status between the communication module 21 and the management server 70 is always within range, at time t1, the management server 70 receives the change request D10. In this case, at time t1, the management system 10 starts a series of processes to delete the digital key shown in Figure 2.

[0071] When the management system 10 initiates a series of processes for deleting the digital key, at time t2, which is after time t1, the multiple devices 40 delete the key information DK in response to deletion requests D11 and D12 from the management server 70. Also at time t2, the vehicle 20 deletes the authentication information AT in response to deletion request D13 from the management server 70.

[0072] Subsequently, at time t3, which is after time t2, the management server 70 updates the contract information CT to indicate that there is no contract. Subsequently, at time t8, which is after time t3, the new owner of vehicle 20 enters into a new contract with the digital key service provider, and the management server 70 receives a request to update the contract information CT.

[0073] Subsequently, at time t9, which is after time t8, the management server 70 updates the contract information CT. This updates the contract information CT to indicate that there is a new contract. Subsequently, until pairing occurs from device 40, which will become owner device 40A, device 40 will not have the key information DK stored in it. Also, until pairing occurs from device 40, which will become owner device 40A, vehicle 20 will not have the authentication information AT stored in it.

[0074] As shown in Figure 5, if the communication status between the communication module 21 and the management server 70 is out of range, the management server 70 receives the change request D10 at time t1. In this case, at time t1, the management system 10 starts a series of processes to delete the digital key shown in Figure 2.

[0075] At time t2, which is after time t1, multiple devices 40 delete the key information DK in response to deletion requests D11 and D12 from the management server 70. On the other hand, at time t2, the vehicle 20 does not receive deletion request D13 from the management server 70, so the digital key ECU 26 remains stored with the authentication information AT.

[0076] Subsequently, at time t3, which is after time t2, the management server 70 updates the contract information CT to indicate that there is no contract. Subsequently, at time t5, which is after time t3, the communication status between the communication module 21 and the management server 70 is assumed to have changed from outside the service area to within the service area. In this case, at time t5, the execution device 27 starts the execution of the vehicle program PV, thereby initiating the series of processes shown in Figure 3.

[0077] Subsequently, at time t6, which is after time t5, the number of successful authentication attempts SN for starting vehicle 20 with a key other than the digital key reaches the specified number RN. In this case, at time t6, the execution device 27 deletes the authentication information AT. As a result, from time t6 onward, vehicle 20 no longer stores the authentication information AT.

[0078] <Effects of the Embodiment> (1) In deletion control, the execution device 27 deletes the authentication information AT as information related to the digital key, provided that the contract information CT indicates that there is no contract. Therefore, the digital key ECU 26 can prevent the authentication information AT of the digital key usable under the contract from remaining stored after the contract has been terminated.

[0079] (2) In deletion control, the execution device 27 deletes the authentication information AT on the condition that the contract information CT indicates that there is no contract, and that authentication for another key has been established. When authentication for a key other than the digital key is established, the other key is being used, so even if the digital key becomes unusable, the user can continue to use the vehicle 20 with the other key. Therefore, when the digital key ECU 26 deletes the authentication information AT of the digital key that is usable under the contract after the contract has been terminated, it is easier to avoid a situation where the user cannot continue to use the vehicle 20.

[0080] (3) In deletion control, the execution device 27 deletes the authentication information AT on the condition that, in addition to the contract information CT indicating that there is no contract, authentication for another key has been established a specified number of times RN, which is two or more times. When authentication for a key other than the digital key has been established a specified number of times RN, there is a high probability that the vehicle 20 can be used without difficulty, such as moving the vehicle 20, using that other key. Therefore, when the digital key ECU 26 deletes the authentication information AT of the digital key that is usable under the contract after the contract has been terminated, it is easier to avoid a situation where the vehicle 20 cannot be used continuously.

[0081] (4) In deletion control, the execution device 27 deletes the authentication information AT on the condition that, in addition to the contract information CT indicating that there is no contract, authentication for starting the vehicle 20 with a different key has been established a specified number of times RN. When authentication for starting the vehicle 20 with a key other than the digital key has been established a specified number of times RN, there is a high probability that the vehicle 20 can be started with that other key. Therefore, when deleting the authentication information AT of the digital key that can be used under the contract after the contract has been terminated, it is possible to avoid a situation where the vehicle 20 cannot be started.

[0082] (5) In deletion control, the execution device 27 acquires contract information CT when the communication status with the management server 70 changes from outside the service area to within the service area. Therefore, if the contract information CT is changed during the period when the communication status is outside the service area, the execution device 27 can delete the authentication information AT in accordance with the changed contract information CT.

[0083] (6) When the execution device 27 is within range of the management server 70 and receives a digital key deletion request D13 from the management server 70, it deletes the authentication information AT. Therefore, when the communication status is within range, the execution device 27 can delete the authentication information AT in accordance with the deletion request D13 from the management server 70.

[0084] On the other hand, when the communication status with the management server 70 is outside the service area, the deletion request D13 from the management server 70 cannot be obtained, and therefore the authentication information AT cannot be deleted according to the deletion request D13. In this regard, with the above configuration, when the communication status with the management server 70 changes from outside the service area to within the service area, the execution device 27 obtains the contract information CT. Then, the execution device 27 deletes the authentication information AT on the condition that the obtained contract information CT indicates that there is no contract. Therefore, even if the execution device 27 cannot delete the authentication information AT because it cannot obtain the deletion request D13 from the management server 70 during the period when the communication status is outside the service area, the execution device 27 can delete the authentication information AT when the communication status changes from outside the service area to within the service area.

[0085] <Example of changes> The above embodiment can be implemented with the following modifications. The above embodiment and the following modifications can be combined with each other to the extent that they do not contradict each other technically.

[0086] Vehicle 20 does not necessarily have to have some of the BLE module 23, UWB module 24, and NFC module 25. Vehicle 20 can perform short-range wireless communication with device 40 if it has at least one of these modules. Furthermore, vehicle 20 is not limited to these modules, and may have any module that performs short-range wireless communication with device 40.

[0087] • The matters concerning digital keys in each of the above embodiments do not have to comply with CCC. The series of processes performed by the management system 10 to delete registered digital keys are not limited to the examples of the above embodiment. For example, the management server 70 may send deletion request D13 before sending deletion requests D11 and D12. Then, after obtaining completion notification M11, the management server 70 may perform the process in step S17 before sending deletion requests D11 and D12. In this way, the management system 10 may delete the authentication information AT and then delete the key information DK.

[0088] The in-vehicle device is not limited to the digital key ECU 26. For example, the in-vehicle device may be a central ECU that manages multiple ECUs in the vehicle 20. Alternatively, the in-vehicle device may be an ECU that includes the digital key ECU 26 and the smart key ECU 33.

[0089] The digital key ECU 26 may be configured as a circuit including one or more processors that perform various processes according to a computer program (software). Alternatively, the digital key ECU 26 may be configured as a circuit including one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs), or a combination thereof, that perform at least some of the various processes. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to perform the processes. Memory, i.e., computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer. The same applies to the smart key ECU 33, device 40, and management server 70.

[0090] The share device 40B has the function of receiving a share key, as in the embodiment described above. A device 40 that has the function of receiving a digital key, like the share device 40B, is sometimes called a receiver device.

[0091] • A device server 60 does not need to be provided for each type of device 40. It is sufficient that multiple devices 40 and the management server 70 can communicate wirelessly. The device server 60 may be omitted. It is sufficient that multiple devices 40 and the management server 70 can communicate directly wirelessly.

[0092] The management server 70 may consist of multiple servers. For example, it may consist of a server that stores a database DB and a server that executes the server program PS. Alternatively, it may consist of a server that communicates with the vehicle 20 and a server that communicates with the device server 60, and these servers may be able to communicate with each other.

[0093] The management server 70 does not necessarily have to store a database DB. For example, the management server 70 may manage a combination of key information DK of device 40 and authentication information AT of digital key ECU 26 for one digital key in the management system 10. Alternatively, for example, the management server 70 may store only contract information CT.

[0094] <Information about various types of information> The authentication information AT is not limited to the examples of the above embodiments, as long as it is information used to authenticate the digital key when using the digital key. For example, the authentication information AT may be a common key shared between the digital key ECU26 and the device 40. Alternatively, the authentication information AT may be a common secret key.

[0095] The structure of the information included in the key information DK is not limited to the examples of the embodiments described above. For example, the owner key information DKO may contain information indicating the type of digital key. The type of digital key is, for example, information indicating one of the owner key and share key.

[0096] The digital key information stored in the digital key ECU26 is not limited to authentication information AT; any information related to the digital key is acceptable. For example, the digital key information may be information that identifies the digital key.

[0097] The information about the digital key stored by device 40 is not limited to key information DK, but can be any information about the digital key. For example, the information about the digital key may be information that identifies the digital key.

[0098] The information about the digital key stored in the digital key ECU26 may be different from or the same as the information about the digital key stored in the device 40, as in the above embodiment.

[0099] <Deletion control> The execution device 27 may perform deletion control at predetermined intervals even when the communication status is within range. This allows the execution device 27 to delete the authentication information AT even when the communication status is within range, provided that the contract information CT indicates that there is no contract. In this case, the execution device 27 does not have to delete the authentication information AT when it receives a deletion request D13 from the management server 70 while the communication status with the management server 70 is within range.

[0100] The timing at which the execution device 27 acquires contract information CT is not limited to the example of the above embodiment. For example, the execution device 27 may acquire contract information CT at a predetermined interval when the communication status is within range.

[0101] The execution device 27 does not have to use the fact that authentication for starting the vehicle 20 with a different key has been completed a specified number of times (RN) as a condition for deleting the authentication information AT. For example, the execution device 27 may also count up the number of successful authentications (SN) when authentication is completed for purposes other than starting the vehicle 20 with a different key. Authentication for purposes other than starting the vehicle 20 includes, for example, authentication when unlocking the doors of the vehicle 20 and authentication when locking the doors of the vehicle 20. Therefore, the execution device 27 may also use the fact that authentication not limited to starting the vehicle 20 with a different key has been completed a specified number of times (RN) as a condition for deleting the authentication information AT.

[0102] The execution device 27 does not have to use the fact that authentication for another key has been successful a specified number of times (RN) as a condition for deleting the authentication information AT. For example, the execution device 27 may use the fact that authentication for another key has been successful once as a condition for deleting the authentication information AT. In this case, the execution device 27 can omit the processing in steps S24 and S25 in the control device.

[0103] The execution device 27 may delete the authentication information AT regardless of whether authentication for another key is successful. The condition for the execution device 27 to delete the authentication information AT is at least that the acquired contract information CT indicates that there is no contract. [Explanation of symbols]

[0104] 10…Management System 20... Vehicles 21…Communication module 26…Digital Key ECU 27… Execution device 28…Storage device 40…Devices 70... Management Server AT... Authentication information CT... Contract Information RN... stipulated number of times SN...Number of times it was achieved

Claims

1. It comprises a storage device and an execution device, The aforementioned storage device stores information related to the vehicle's digital key. The execution device obtains contract information from an external source indicating whether or not there is a contract that allows the use of the digital key, and, on the condition that the obtained contract information indicates that there is no such contract, performs control to delete the information regarding the digital key stored in the storage device. In-vehicle device.

2. The execution device, in the control, deletes the information related to the digital key on the following conditions: the acquired contract information indicates that there is no contract, and authentication for a key other than the digital key has been established in the vehicle. The in-vehicle device according to claim 1.

3. The execution device deletes the information related to the digital key in the control operation, provided that the acquired contract information indicates that there is no contract and that authentication for a key other than the digital key has been completed a specified number of times (two or more times) in the vehicle. The in-vehicle device according to claim 2.

4. The execution device deletes the information related to the digital key in the control operation, provided that the acquired contract information indicates that there is no contract, and that authentication for starting the vehicle using a key other than the digital key has been completed a specified number of times (two or more times). The in-vehicle device according to claim 3.

5. The execution device acquires the contract information when the communication status of the vehicle with the external server changes from an area where communication is impossible to an area where communication is possible. The in-vehicle device according to any one of claims 1 to 4.

6. When the execution device receives a request from a server outside the vehicle to delete information about the digital key while the communication state is within the range, it deletes the information about the digital key stored in the storage device. The in-vehicle device according to claim 5.

7. A control method performed by an in-vehicle device that stores information regarding the vehicle's digital key, The in-vehicle device obtains contract information from an external source indicating whether or not there is a contract to enable the use of the digital key, and, on the condition that the obtained contract information indicates that there is no such contract, performs control to delete the stored information related to the digital key. Control method.

8. A program to be executed by an in-vehicle device that stores information about the vehicle's digital key, The in-vehicle device is instructed to obtain contract information from an external source indicating whether or not there is a contract to enable the use of the digital key, and to execute a control to delete the stored information related to the digital key, provided that the obtained contract information indicates that there is no such contract. program.

Images