Management system, management server, deletion program, and deletion method

Abstract

This system provides a management system that can delete a target digital key at the time a request for deletion is made, even if the vehicle and target device are offline. [Solution] A digital key becomes controllable to the vehicle 20 when both the vehicle 20 and the device 30 have stored information about the digital key. When the management system 10 receives a request to delete a target digital key, it deletes the information about the target digital key stored in the target device by sending a deletion request to the target device and the vehicle 20. If both the target device and the vehicle 20 are unable to communicate when the management system 10 sends the deletion request, it resends the deletion request for the target digital key when at least one of the target device and the vehicle 20 becomes able to communicate.

Description

[Technical Field]

[0001] The present disclosure relates to a management system, a management server, a deletion program, and a deletion method. [Background Art]

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, a plurality of devices, and a management server. The vehicle includes a vehicle management device that stores authentication information for authenticating a digital key. The device stores key information representing a digital key. The management server is capable of communicating with the devices and the vehicle, and manages registration of digital keys. [Prior Art Literature] [Patent Literature]

[0003] [Patent Document 1] Japanese Unexamined Patent Publication No. 2024-001720 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] A device in the management system can request deletion of a digital key for another device. Deletion of a digital key as used herein refers to deleting at least one of information related to the digital key stored in the device and information related to the digital key stored in the vehicle. This disables control of the vehicle using the digital key.

[0005] After a device in the management system requests deletion of a digital key, the digital key is deleted when at least one of the device associated with the digital key and the vehicle receives the deletion request for the digital key via communication. Therefore, when both the vehicle and the shared device are offline, the digital key may not be deleted even if deletion of the digital key has been requested. [Means for solving the problem]

[0006] The management system that solves the above problem comprises a vehicle that stores information about multiple digital keys, a device that stores information about the digital keys registered for the vehicle, and a management server that manages the registration of the digital keys. The digital key becomes controllable to the vehicle when both the vehicle and the device store information about the digital key. When the management system receives a request to delete a target digital key, which is one of the multiple digital keys that is to be deleted, it sends a deletion request to the target device, which is the device that stores information about the target digital key, thereby deleting the information about the target digital key stored in the target device, and then sends the deletion request to the vehicle, thereby deleting the information about the target digital key stored in the vehicle. When the management system sends the deletion request, if both the target device and the vehicle are unable to communicate, it resends the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate.

[0007] The management server that solves the above problem is a management server that manages the registration of digital keys in a management system comprising a vehicle that stores information about multiple digital keys and a device that stores information about the digital keys registered for the vehicle. The digital key becomes controllable to the vehicle when both the vehicle and the device store information about the digital key. When the management server receives a request to delete a target digital key, which is one of the multiple digital keys that is to be deleted, it sends a deletion request to the target device, which is the device that stores information about the target digital key, thereby deleting the information about the target digital key stored in the target device, and then sends the deletion request to the vehicle, thereby deleting the information about the target digital key stored in the vehicle. When the management server sends the deletion request, if both the target device and the vehicle are unable to communicate, it resends the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate.

[0008] A deletion program that solves the above problem comprises a vehicle that stores information about multiple digital keys, a device that stores information about the digital keys registered for the vehicle, and a management server that manages the registration of the digital keys, wherein the vehicle becomes controllable when both the vehicle and the device store information about the digital key. The deletion program controls the management server in this management system. When a request is made to delete a target digital key, which is one of the multiple digital keys to be deleted, the deletion program sends a deletion request to the target device, which is the device that stores information about the target digital key, thereby causing the management server to delete the information about the target digital key stored in the target device. When a request is made to delete the target digital key, the deletion program sends the deletion request to the vehicle, thereby causing the management server to delete the information about the target digital key stored in the vehicle. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion program causes the management server to resend the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate.

[0009] A deletion method for solving the above problem comprises a vehicle that stores information about multiple digital keys, a device that stores information about the digital keys registered for the vehicle, and a management server that manages the registration of the digital keys, wherein the vehicle becomes controllable when both the vehicle and the device store information about the digital key, and the deletion method for deleting a target digital key, which is one of the multiple digital keys that is to be deleted, in a management system. This deletion method includes the step of the management server deleting the information about the target digital key stored by the target device by sending a deletion request to the target device, which is the device that stores information about the target digital key. This deletion method includes the step of the management server deleting the information about the target digital key stored by the vehicle by sending the deletion request to the vehicle. This deletion method includes the step of the management server resending the deletion request for the target digital key when both the target device and the vehicle are unable to communicate when the deletion request is sent, when at least one of the target device and the vehicle becomes able to communicate. [Effects of the Invention]

[0010] The above-described management system, management server, deletion program, and deletion method can delete the target digital key even if the vehicle and target device are offline at the time the deletion of the target digital key is requested. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a schematic diagram showing a management system of one embodiment. [Figure 2] Figure 2 is a schematic diagram showing the owner key information in Figure 1. [Figure 3] Figure 3 is a schematic diagram showing the share key information in Figure 1. [Figure 4]Figure 4 is a schematic diagram showing the data in the database shown in Figure 1. [Figure 5] Figure 5 is an explanatory diagram illustrating the series of processes performed by the management system shown in Figure 1 when an owner key is registered. [Figure 6] Figure 6 is an explanatory diagram illustrating the series of processes performed by the management system shown in Figure 1 when a friend key is registered. [Figure 7] Figure 7 is an explanatory diagram illustrating the series of processes performed by the management system shown in Figure 1 when a non-friend key is registered. [Figure 8] Figure 8 is an explanatory diagram illustrating the series of processes performed by the management system in Figure 1 when a non-friend key is deleted at the request of a friend device. [Figure 9] Figure 9 is an explanatory diagram illustrating the series of processes performed by the management system in Figure 1 when a non-friendly key is deleted at the request of a non-friendly device. [Figure 10] Figure 10 is an explanatory diagram illustrating the series of processes performed by the management system in Figure 1 when a friend key is deleted at the request of the owner device. [Figure 11] Figure 11 is an explanatory diagram illustrating the series of processes performed by the management system in Figure 1 when a friend key is deleted at the request of a friend device. [Figure 12] Figure 12 is an explanatory diagram illustrating the series of processes performed by the management system in Figure 1 when the non-friendly device and vehicle are in a state where communication is impossible. [Figure 13] Figure 13 is an explanatory diagram illustrating the series of processes that the management system in Figure 1 performs to delete a non-friend key when the non-friend device and vehicle are in a state where communication is impossible. [Figure 14] Figure 14 is a flowchart showing the sequence of actions performed when the non-friendly device in Figure 1 receives a delete request. [Figure 15] Figure 15 is a flowchart showing the sequence of processes that the vehicle in Figure 1 performs when it receives a deletion request. [Figure 16]FIG. 16 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a friend device and a vehicle are in a non-communicable state. [Figure 17] FIG. 17 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 to delete a friend key when a friend device and a vehicle are in a non-communicable state. [Figure 18] FIG. 18 is a flowchart showing a series of processes executed when the friend device of FIG. 1 receives a deletion request. [Figure 19] FIG. 19 is an explanatory diagram showing a series of processes performed by a management system according to a modified example to delete a non-friend key when a non-friend device and a vehicle are in a non-communicable state. [Figure 20] FIG. 20 is an explanatory diagram showing a series of processes performed by a management system according to a modified example to delete a friend key when a friend device and a vehicle are in a non-communicable state. DESCRIPTION OF EMBODIMENTS

[0012] Hereinafter, an embodiment of a management system will be described with reference to the drawings. <Outline of Management System 10> As shown in FIG. 1, a management system 10 manages a plurality of digital keys that can be used for a vehicle 20. In the present embodiment, the management system 10 is a system. For digital keys, there exists a standard established by the Car Connectivity Consortium (CCC). Matters related to the digital key according to the present embodiment comply with the CCC standard. The management system 10 includes a vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

[0013] Vehicle 20 includes a communication module 21, an HMI 22, a BLE module 23, a UWB module 24, an NFC module 25, and a vehicle management device 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.

[0014] 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.

[0015] The BLE module 23 communicates with the device 30 via BLE communication. The UWB module 24 communicates with the device 30 via UWB communication. The UWB module 24 measures the distance between the device 30 and the vehicle 20. The NFC module 25 communicates with the device 30 via NFC communication.

[0016] The vehicle management device 26 is installed in the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating a digital key in order to enable control of the vehicle 20 by using the digital key. Authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU. The execution device 27 executes processes related to the storage and deletion of authentication information AT by executing the vehicle program PV.

[0017] Authenticating a digital key means verifying whether the digital key is capable of legitimately controlling the vehicle 20. Authentication of the digital key is completed when it is determined that the digital key is capable of legitimately controlling the vehicle 20.

[0018] Vehicle 20 is made controllable by the digital key after the digital key authentication is complete. The digital key can control vehicle 20 while authentication is complete. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables unlocking of vehicle 20. Also, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables starting of vehicle 20.

[0019] When the device 30, described later, moves beyond a certain distance from the vehicle 20, the authentication status for the digital key registered to that device is reset. Both the device 30 and the vehicle 20 are aware of whether or not the digital key is in an authenticated state.

[0020] Device 30 is a mobile information terminal such as a smartphone. Device 30 includes a communication module 31, an HMI 32, a BLE module 33, a UWB module 34, an NFC module 35, an execution device 36, and a storage device 37.

[0021] The communication module 31 communicates with the device server 60 via a wireless communication line. The HMI 32 includes an input device that accepts user input for the device 30, 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.

[0022] The BLE module 33 communicates with the vehicle 20 via BLE communication. The UWB module 34 communicates with the vehicle 20 via UWB communication. The NFC module 35 communicates with the vehicle 20 via NFC communication.

[0023] The storage device 37 stores the device program PD and the key information DK. The device program PD is executed by the execution device 36, which in turn causes the execution device 36 to store and delete the key information DK. The key information DK is information that indicates a digital key.

[0024] The device program PD includes, 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 device 30 and sharing digital keys using APIs provided by the OS. The execution device 36 executes the device program PD to perform processes related to storing and deleting key information DK.

[0025] The multiple devices 30 include an owner device 40 and multiple share devices 50. The owner device 40 stores owner key information DKO, which indicates the owner key KO, as key information DK. Only one owner key KO can be registered for each vehicle 20. Therefore, there is only one owner key KO for each vehicle 20. The owner device 40 belongs to the owner of the vehicle 20.

[0026] As shown in Figure 2, the owner key information DKO has owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The owner key structure information STO also includes certificate information ST5, device public key information ST6, vehicle public key information ST7, and authorization public key information ST8.

[0027] Vehicle identification information ST1 is information that identifies the vehicle 20 to which the digital key is to be set. For example, it is the ID of vehicle 20. The in-device key identification information ST2 is used for managing digital keys within device 30. The in-device key identification information ST2 is information that allows for the identification of digital keys within the application of device 30.

[0028] Digital key identification information ST3 is used for managing digital keys within the management server 70. Slot identification information ST4 is information that allows the digital key to be identified locally on device 30.

[0029] Certificate information ST5 indicates the certificate that certifies the digital key. Device public key information ST6 indicates the device public key PKD, which is the public key of device 30. Note that the device public key PKD in owner key information DKO indicates the public key of owner device 40. Vehicle public key information ST7 indicates the vehicle public key PKV, which is the public key of vehicle 20. Authorized public key information ST8 indicates the vehicle public key PKV that has already been authorized.

[0030] As shown in Figure 1, the share device 50 stores share key information DKS, which indicates the share key KS, as key information DK. The share device 50 is a separate device 30 from the owner device 40. The share key KS is a digital key that can be registered multiple times for a single vehicle 20 in order to register the digital key in order to make the digital key usable. In other words, multiple share keys KS can exist for a single vehicle 20.

[0031] Multiple share devices 50 include friend devices 51 and non-friend devices 52. Friend device 51 stores friend key information DKF, which indicates friend key KF, as share key information DKS. Non-friend device 52 stores non-friend key information DKN, which indicates non-friend key KN, as share key information DKS. In other words, the types of share keys KS include friend key KF and non-friend key KN. Friend key KF is a share key KS registered based on a direct registration request D21 from owner device 40, as will be described later. Non-friend key KN is a share key KS registered based on a registration request D31 from friend device 51, as will be described later. In other words, non-friend key KN is a share key KS registered not based on a direct registration request D21 from owner device 40, but based on a registration request D31 from another device 30. To put it another way, non-friend key KN is a share key KS that is not friend key KF.

[0032] Furthermore, when a digital key is registered, it means that the digital key is usable. That is, when a digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. When a digital key is registered, the digital key becomes capable of controlling the vehicle 20.

[0033] As shown in Figure 3, the share key information DKS includes the share key structure information STS and the authentication package ATP. The share key structure information STS includes vehicle identification information ST1, device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The share key structure information STS also includes certificate information ST5, vehicle public key information ST7, and authorized public key information ST8. In other words, the share key structure information STS is the owner key structure information STO with the device public key information ST6 removed.

[0034] The authentication package ATP includes signature information ATP1, password information ATP2, activation start information ATP3, expiration information ATP4, name information ATP5, and device public key information ATP6.

[0035] Signature information ATP1 indicates that shared device 50 is a legitimate recipient of the digital key. For example, in the case of friend device 51, it indicates a signature by owner device 40. Owner signature information indicates that owner device 40 signed the device public key PKD of friend device 51, which is shown in device public key information ATP6. Also, for example, in the case of non-friend device 52, it indicates a signature by friend device 51. Friend signature information indicates that friend device 51 signed the device public key PKD of non-friend device 52, which is shown in device public key information ATP6.

[0036] Password information ATP2 indicates the pairing password PAS used when establishing a secure channel during pairing between the vehicle 20 and the owner device 40. Effective start information ATP3 indicates the earliest date and time when the share key KS can be used. Expiration date information ATP4 indicates the latest date and time when the share key KS can be used. Name information ATP5 indicates the name that identifies the share key KS. For example, it is set as an identifiable name for each share device 50 through an operation from the owner device 40.

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

[0038] Each device server 60 relays communication with the management server 70, allowing different types of devices 30 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 70> The management server 70 manages the registration of digital keys. The management server 70 can communicate with the vehicle 20 and multiple devices 30. The management server 70 comprises an execution unit 71, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 can also communicate wirelessly with the communication module 21 of the vehicle 20.

[0040] The storage device 72 stores the server program PS, the deletion program PC, and the database DB. The server program PS is executed by the execution device 71, causing the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB. The deletion program PC is executed by the execution device 71, causing the execution device 71 to delete digital keys in the management system 10. The deletion program PC causes the execution device 71 to implement the deletion method described below.

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

[0042] As shown in Figure 4, the data DA of a single vehicle 20 includes the type of digital key registered to that vehicle 20, the registered device 30, and the relationships between the registered devices 30. A hierarchy is established based on the type of digital key. From top to bottom in the hierarchy, the keys are Owner Key KO, Friend Key KF, and Non-Friend Key KN. Higher levels of the hierarchy grant greater authority.

[0043] Permissions include, for example, the number of shared keys KS that can be requested to be registered, and the range of vehicles 20 that can be controlled by digital key authentication. Higher levels of the hierarchy indicate greater permissions; for example, a higher number of shared keys KS that can be requested to be registered. More specifically, for example, the number of friend keys KF that an owner device 40 can request to be registered is greater than the number of non-friend keys KN that a friend device 51 can request to be registered.

[0044] Furthermore, for example, the higher the hierarchy, the greater the authority, and therefore the wider the control range of the controllable vehicle 20. The control range of the controllable vehicle 20 refers to the possible controls among, for example, engine start control of vehicle 20, power-on control of vehicle 20, and unlocking and locking control of vehicle 20. For example, if the control range of the controllable vehicle 20 includes the three controls mentioned above, the control range of the controllable vehicle 20 is wider than if the control range of the controllable vehicle 20 is limited to unlocking and locking the doors of vehicle 20. More specifically, the control range of vehicle 20 that can be controlled by friend key KF includes the three controls mentioned above, while the control range of vehicle 20 that can be controlled by non-friend key KN is limited to unlocking and locking the doors of vehicle 20.

[0045] This section describes a state in which a digital key is registered to seven devices 30 for one vehicle 20. The seven devices 30 are referred to as Device 1 30A to Device 7 30G. The digital keys registered to each of Devices 1 30A to Device 7 30G are referred to as Digital Key 1 to Digital Key 7.

[0046] In the data DA, device 30, which is registered as Owner Key KO, is the first device 30A. That is, the first device 30A is the owner device 40. In other words, the first digital key is Owner Key KO.

[0047] In the data DA, the devices 30 registered with the digital key type as Share Key KS are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. In other words, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are all Share Devices 50. That is, the second to seventh digital keys are all Share Key KS.

[0048] More specifically, in the data DA, the devices 30 registered with the digital key type as Friend Key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are Friend Devices 51. In the data DA, the devices 30 registered with the digital key type as Non-Friend Key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are Non-Friend Devices 52.

[0049] In data DA, the relationship between the second device 30B and the first device 30A is such that the friend key KF is registered in the second device 30B based on a registration request from the first device 30A. In other words, the second digital key is registered based on the first digital key.

[0050] In the data DA, the relationship between the fifth device 30E and the first device 30A is such that the friend key KF is registered in the fifth device 30E based on a registration request from the first device 30A. In other words, the fifth digital key is registered based on the first digital key.

[0051] In the data DA, the relationship between the third device 30C and the second device 30B is such that the non-friendly key KN is registered in the third device 30C based on a registration request from the second device 30B. In other words, the third digital key is registered based on the second digital key.

[0052] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that the non-friendly key KN is registered in the fourth device 30D based on a registration request from the second device 30B. In other words, the fourth digital key is registered based on the second digital key.

[0053] In the data DA, the relationship between the sixth device 30F and the fifth device 30E is such that the non-friendly key KN is registered in the sixth device 30F based on a registration request from the fifth device 30E. In other words, the sixth digital key is registered based on the fifth digital key.

[0054] In data DA, the relationship between the 7th device 30G and the 5th device 30E is such that the non-friendly key KN is registered in the 7th device 30G based on a registration request from the 5th device 30E. In other words, the 7th digital key is registered based on the 5th digital key.

[0055] Thus, the data DA stores the devices 30 that have been registered as digital keys. Furthermore, it associates information indicating the device 30 that made the request that triggered the registration of the device 30. The data DA also includes information indicating which digital key each digital key is based on.

[0056] <Digital Key Registration> Next, we will describe the series of processes for registering digital keys in the management system 10. The management system 10 registers the owner key KO, the friend key KF, and the non-friend key KN as digital keys. Below, we will describe the sequence of processes from when each digital key is not registered to when it is registered. 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 36 will be described as processes executed by the device 30, and the processes executed by the execution device 71 will be described as processes executed by the management server 70.

[0057] <Owner Key KO Registration> As shown in Figure 5, the management system 10 performs a series of processes to register the owner key KO. Among the devices 30 that do not store the key information DK indicating the owner key KO, the device 30 that will be designated as the owner device 40 is designated as the first device 30A.

[0058] In the management system 10, upon registration of the owner key KO, key information DK indicating the owner key KO is stored in the first device 30A. In the management system 10, upon registration of the owner key KO, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. As a result, the first device 30A becomes the owner device 40. Note that the registration of the owner key KO is assumed to be performed on the first device 30A with the application installed.

[0059] When the management server 70 receives the owner key KO registration request D11 from the first device 30A or the like, the management server 70 first performs the process in step S11. In step S11, the management server 70 generates a pairing password PAS. Then, the management server 70 sends information indicating the pairing password PAS to the vehicle 20 and the first device 30A.

[0060] Subsequently, vehicle 20 receives the pairing password PAS. After vehicle 20 receives the pairing password PAS, it is set to pairing mode by HMI 22 and waits to receive the password from the first device 30A. Then, vehicle 20 proceeds to step S12.

[0061] In step S12, vehicle 20 pairs with the first device 30A. Once pairing is complete, vehicle 20 establishes a secure channel with the first device 30A for data communication. Pairing is performed using the pairing password PAS sent from the management server 70 to vehicle 20 and the first device 30A. Once pairing is complete, vehicle 20 proceeds to step S13.

[0062] In step S13, the vehicle 20 generates a vehicle public key PKV, which is the public key of the vehicle 20, and a vehicle private key SKV, which is the private key of the vehicle 20. Then, the vehicle 20 sends generated data DC to the first device 30A via the secure channel to generate the owner key KO. The generated data DC includes vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. The first device 30A then receives the generated data DC. The first device 30A then proceeds to step S14.

[0063] In step S14, the first device 30A generates owner key information DKO, which indicates the owner key KO. Then, the first device 30A proceeds to step S15. In step S15, the first device 30A stores the owner key information DKO. This makes the first device 30A the owner device 40. Subsequently, the first device 30A transmits the certificate information ST5 related to the owner key KO and the device public key information ST6 indicating the device public key PKD to the vehicle 20.

[0064] Subsequently, when vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process in step S16. In step S16, vehicle 20 verifies certificate information ST5. Once the verification of certificate information ST5 is complete, vehicle 20 proceeds to step S17.

[0065] In step S17, the vehicle 20 stores the device public key information ST6, which represents the device public key PKD, as authentication information AT. Subsequently, the vehicle 20 sends a completion notification M11 to the first device 30A indicating that the storage of the authentication information AT is complete.

[0066] Subsequently, when the first device 30A receives the completion notification M11, the first device 30A performs the process in step S18. In step S18, the first device 30A generates a key track request D12 for the owner key KO. The key track request D12 is a signal to the management server 70 requesting an update to the database DB. The first device 30A then sends the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0067] Subsequently, when the management server 70 receives the key track request D12, it performs the processing in step S19. In step S19, the management server 70 performs the registration management of the owner key KO. Specifically, it stores the first device 30A in the data DA of the vehicle 20 in the database DB as the device 30 registered as the owner key KO. With this, the management system 10 completes the series of processing for the owner key KO.

[0068] <Registering Friend Key KF> As shown in Figure 6, the management system 10 performs a series of processes to register the friend key KF. Of the devices 30 that do not store the friend key information DKF, the device 30 that becomes a friend device 51 through this series of processes is designated as the second device 30B.

[0069] When the owner device 40 performs an operation to request the registration of the friend key KF, the owner device 40 first performs the process in step S21. In step S21, the owner device 40 sends the friend key KF registration request D21 to a relay server (not shown in the figure). After that, the owner device 40 proceeds to step S22.

[0070] In step S22, the owner device 40 obtains invitation information IV1 for sharing the digital key from the relay server. Invitation information IV1 is, for example, a URL link. The URL link contains share information SH1 necessary for sharing the digital key. The owner device 40 then sends the invitation information IV1 to the second device 30B.

[0071] Subsequently, when the second device 30B receives the invitation information IV1, it performs the process in step S23. In step S23, the second device 30B obtains the share information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the share information SH1 from the source of the URL link.

[0072] The share information SH1 includes, for example, share key structure information STS, password information ATP2, effective start information ATP3, expiration information ATP4, and name information ATP5. Note that the effective start information ATP3, expiration information ATP4, and name information ATP5 are set by the owner device 40. After that, the second device 30B proceeds to step S24.

[0073] In step S24, the second device 30B generates unsigned friend key information DKFN using the share information SH1. Unsigned friend key information DKFN is friend key information DKFN that does not have signature information ATP1. Specifically, the second device 30B generates each piece of information contained in the acquired share information SH1 as the pieces of information in the unsigned friend key information DKFN. Subsequently, the second device 30B sends a completion notification M21 indicating that the generated unsigned friend key information DKFN has been uploaded to a URL link, and a signature request D22 requesting a signature, to the owner device 40.

[0074] Subsequently, the owner device 40 receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 obtains the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process in step S25 by being operated.

[0075] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 prompts the HMI 32 to present the acquired unsigned friend key information DKFN and accepts an operation indicating consent to the registration of the friend key KF by the user of the owner device 40. Once the operation is performed, the owner device 40 obtains a signature based on the fact that the operation has been performed. After that, the owner device 40 proceeds to step S26.

[0076] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. This causes the owner device 40 to generate the friend key information DKF. The owner device 40 then uploads the generated friend key information DKF to the URL link which is the invitation information IV1. The owner device 40 then sends a completion notification M22 to the second device 30B indicating that the upload of the completed friend key information DKF to the URL link is complete.

[0077] Subsequently, the second device 30B receives a completion notification M22. Then, the second device 30B performs the process in step S27. In step S27, the second device 30B downloads and stores the friend key information DKF. As a result, the second device 30B becomes the friend device 51. Then, the second device 30B proceeds to step S28.

[0078] In step S28, the second device 30B generates a key track request D23 for the friend key KF. The second device 30B then sends the friend key information DKF and the key track request D23 for the friend key KF to the management server 70.

[0079] Subsequently, when the management server 70 receives the key track request D23 for the friend key KF, the management server 70 performs the process in step S29. In step S29, the management server 70 performs registration management for the friend key KF.

[0080] Specifically, the management server 70 verifies that the friend key KF, which is the target of keytrack request D23, is not on the rejection list. The rejection list is a list of share keys KS, including friend keys KF and non-friend keys KN for which a deletion request has already been received. If friend key KF is on the rejection list, the management server 70 sends a notification to the second device 30B that it cannot fulfill keytrack request D23.

[0081] On the other hand, if the friend key KF that received the key track request D23 is not on the rejection list, the management server 70 registers the friend key KF that received the key track request D23 in the database DB. Specifically, the management server 70 stores the second device 30B as device 30 registered as friend device 51 in the vehicle 20 data DA in the database DB. The management server 70 stores the relationship between the second device 30B and the owner device 40 by referring to the acquired friend key information DKF.

[0082] Subsequently, the management server 70 sends the authentication package ATP from the friend key information DKF and a storage request D24 requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 sends the device public key information ST6, which indicates the device public key PKD of the friend device 51, to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD is signed by the owner device 40.

[0083] Subsequently, when vehicle 20 receives storage request D24 and authentication package ATP from management server 70, it performs the process in step S30. In step S30, vehicle 20 stores the received authentication package ATP as authentication information AT for authenticating friend key KF.

[0084] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M23 to the second device 30B. Subsequently, when the second device 30B receives the key track completion notification M23, it performs the process in step S31. In the process of step S31, the second device 30B presents information to the HMI 32 indicating that the registration of the friend key KF is complete. For example, the second device 30B displays an image indicating the registration of the friend key KF on the HMI 32. With this, the management system 10 completes the series of processes for registering the friend key KF.

[0085] <Registering Non-Friend Keys (KN)> As shown in Figure 7, the management system 10 performs a series of processes to register the non-friendly key KN. Of the devices 30 that do not store the non-friendly key information DKN, the device 30 that becomes a non-friendly device 52 through this series of processes is designated as the third device 30C.

[0086] When an operation is performed in the friend device 51 to request the registration of a non-friend key KN, the friend device 51 first performs the process in step S41. In step S41, the friend device 51 sends the non-friend key KN registration request D31 to a relay server (not shown in the figure). After that, the friend device 51 proceeds to step S42.

[0087] In step S42, the friend device 51 obtains invitation information IV2 for sharing the digital key from the relay server. The invitation information IV2 is, for example, a URL link. The URL link contains the share information SH2 necessary for sharing the digital key. The friend device 51 then sends the invitation information IV2 to the third device 30C.

[0088] Subsequently, when the third device 30C receives the invitation information IV2, it performs the process in step S43. In step S43, the third device 30C obtains the share information SH2 based on the invitation information IV2. Specifically, the third device 30C downloads the share information SH2 from the URL link.

[0089] The share information SH2 includes, for example, the share key structure information STS, password information ATP2, activation start information ATP3, expiration date information ATP4, and name information ATP5. Note that the activation start information ATP3, expiration date information ATP4, and name information ATP5 are set by the friend device 51. After that, the third device 30C proceeds to step S44.

[0090] In step S44, the third device 30C generates unsigned non-friend key information DKNN using the share information SH2. Unsigned non-friend key information DKNN is non-friend key information DKNN that does not have signature information ATP1. Specifically, the third device 30C generates each piece of information contained in the acquired share information SH2 as the pieces of information in the unsigned non-friend key information DKNN. Subsequently, the third device 30C sends a completion notification M31 indicating that it has finished uploading the generated unsigned non-friend key information DKNN to a URL link, and a signature request D32 requesting a signature, to the friend device 51.

[0091] Subsequently, the friend device 51 receives a completion notification M31 and a signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 obtains the unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process in step S45 by being operated.

[0092] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 prompts the HMI 32 to present the acquired unsigned non-friend key information DKNN and accepts an operation indicating consent to the generation of the non-friend key KN by the user of the friend device 51. Once the operation is performed, the friend device 51 obtains a signature based on the fact that the operation has been performed. After that, the friend device 51 proceeds to step S46.

[0093] In step S46, the friend device 51 adds the signature information ATP1 to the unsigned non-friend key information DKNN. This causes the friend device 51 to generate the non-friend key information DKN. The friend device 51 then uploads the generated non-friend key information DKN to the URL link which is the invitation information IV2. Finally, the friend device 51 sends a completion notification M32 to the third device 30C indicating that it has finished uploading the completed non-friend key information DKN to the URL link.

[0094] Subsequently, the third device 30C receives a completion notification M32. Then, the third device 30C performs the process in step S47. In step S47, the third device 30C downloads and stores the non-friendly key information DKN. As a result, the third device 30C becomes a non-friendly device 52. Then, the third device 30C proceeds to step S48.

[0095] In step S48, the third device 30C generates a key track request D33 for the non-friend key KN. The third device 30C then sends the non-friend key information DKN and the key track request D33 for the non-friend key KN to the management server 70.

[0096] Subsequently, when the management server 70 receives a key track request D33 for a non-friendly key KN, the management server 70 performs the process in step S49. In step S49, the management server 70 performs registration management for the non-friendly key KN.

[0097] Specifically, the management server 70 verifies that the non-friendly key KN, which is the target of keytrack request D33, is not on the rejection list. If the non-friendly key KN is on the rejection list, the management server 70 sends a notification to the third device 30C that it cannot fulfill keytrack request D33.

[0098] On the other hand, if the non-friendly key KN is not on the rejection list, the management server 70 registers the non-friendly key KN that is the target of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the vehicle 20 data DA in the database DB as device 30 registered as non-friendly device 52. The management server 70 stores the relationship between the third device 30C and the friend device 51 by referring to the acquired non-friendly key information DKN. Specifically, the management server 70 stores the third device 30C as device 30 having a non-friendly key KN registered by the registration request D31 from the friend device 51.

[0099] Subsequently, the management server 70 sends the authentication package ATP from the non-friendly key information DKN and a storage request D34 requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 sends the device public key information ST6, which indicates the device public key PKD of the non-friendly device 52, to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD has been signed by the friendly device 51.

[0100] Subsequently, when vehicle 20 receives the authentication package ATP and the storage request D34, it performs the process in step S50. In step S50, vehicle 20 stores the received authentication package ATP. That is, vehicle 20 stores the authentication package ATP as authentication information AT for authenticating the non-friend key KN.

[0101] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M33 to the third device 30C. Subsequently, when the third device 30C receives the key track completion notification M33, it performs the process in step S51. In the process of step S51, the third device 30C presents information to the HMI 32 indicating the completion of registration of the non-friendly key KN. For example, the third device 30C displays an image indicating the completion of registration of the non-friendly key KN on the HMI 32. With this, the management system 10 completes the series of processes for registering the non-friendly key KN.

[0102] <Deleting the digital key> Next, a series of processes for deleting a digital key in the management system 10 will be described. As mentioned earlier, when a digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. When a digital key is registered, the digital key can control the vehicle 20. If at least one of the authentication information AT stored in the vehicle 20 or the key information DK stored in the device 30 is deleted, the digital key will no longer be able to control the vehicle 20.

[0103] Deleting a digital key means deleting at least one of the authentication information AT stored in the vehicle 20 and the key information DK stored in the device 30, thereby rendering the vehicle 20 uncontrollable by the digital key. In the series of processes for deleting the digital key described below, the management server 70 interacts with the vehicle 20 and the device 30 to delete the authentication information AT stored in the vehicle 20 and the key information DK stored in the device 30.

[0104] <Deleting Non-Friend Keys (KN)> This section describes a series of processes for deleting non-friendly keys (KN) in the management system 10. The following describes the sequence of events from a state where non-friendly keys (KN) are registered to a state where they are not registered. In the following description, processes executed by the execution device 27 are described as processes executed by the vehicle 20, processes executed by the execution device 36 are described as processes executed by the device 30, and processes executed by the execution device 71 are described as processes executed by the management server 70.

[0105] <Deletion of non-friend key KN at the request of friend device 51> As shown in Figure 8, the management system 10 performs a series of operations to delete the non-friend key KN based on the deletion reservation request D41 from the friend device 51. In the series of operations shown in Figure 8, the operations performed by the management server 70 are executed by the deletion program PC, which has the execution device 71 perform the operations.

[0106] When an operation is performed in the friend device 51 to request the deletion of the non-friend key KN, the friend device 51 first performs the process in step S61. In step S61, a deletion reservation request D41 for the non-friend key KN is generated. The deletion reservation request D41 is a signal that requests the deletion of the non-friend key KN when the specified condition RC, described later, is met.

[0107] The deletion reservation request D41 includes a signal requesting the deletion of the non-friend key KN and digital key identification information ST3 indicating the non-friend key KN. The friend device 51 then sends the deletion reservation request D41 for the non-friend key KN to the management server 70.

[0108] Subsequently, when the management server 70 receives a deletion reservation request D41 for non-friend key KN, it performs the process in step S62. In step S62, the management server 70 generates a deletion pending notification M41 indicating that the deletion is pending in accordance with the deletion reservation request D41. The management server 70 then sends the deletion pending notification M41 to the friend device 51.

[0109] Subsequently, when the friend device 51 receives the deletion pending notification M41, the friend device 51 performs the process in step S63. In step S63, the friend device 51 presents information to the HMI 32 indicating that the non-friend key KN, which is the subject of the deletion reservation request D41, is pending deletion and will be deleted as soon as the specified condition RC is met.

[0110] The specified condition RC is a condition required to start deletion after the deletion reservation request D41 has been sent. The specified condition RC is predetermined. In Figure 8, there are two specified condition RCs: one for the non-friendly device 52 and one for the vehicle 20. When at least one of the specified condition RCs, the non-friendly key KN that is the target of the deletion reservation request D41, is deleted.

[0111] After processing in step S62, the management server 70 performs the processing in step S64. In step S64, the management server 70 generates a deletion request D42 that requests the deletion of the non-friend key information DKN, which indicates the non-friend key KN that is the target of the deletion reservation request D41. The management server 70 then sends the deletion request D42 to the non-friend device 52.

[0112] Subsequently, when the non-friendly device 52 receives the deletion request D42, it sends a response notification M42 to the management server 70. The response notification M42 is a notification indicating that the non-friendly device 52 has received the deletion request D42.

[0113] Subsequently, the non-friendly device 52 performs the process in step S65. In step S65, the non-friendly device 52 stores in the storage device 37 the state of the non-friendly key KN, which is the target of the deletion reservation request D41, as a fade-out state. The fade-out state means that the deletion reservation request D41 has been sent, but the execution of the deletion is still pending.

[0114] After sending the deletion request D42, the management server 70 executes the process in step S66. In step S66, the management server 70 generates a deletion request D43 for the authentication information AT. This deletion request D43 for the authentication information AT indicates a request to delete the authentication information AT used to authenticate the non-friendly key KN that is the target of the deletion reservation request D41. The management server 70 then sends the deletion request D43 to the vehicle 20.

[0115] Subsequently, when vehicle 20 receives deletion request D43, vehicle 20 sends a response notification M43 to the management server 70. Response notification M43 is a notification indicating that vehicle 20 has received deletion request D43.

[0116] Subsequently, the vehicle 20 performs the process in step S67. In step S67, the vehicle 20 stores in the storage device 28 the state of the non-friend key KN, which is the target of the deletion reservation request D41, as a fade-out state.

[0117] For the non-friendly device 52, the specified condition RC is that a predetermined fade-out period has elapsed since the non-friendly device 52 received the deletion request. The fade-out period is, for example, 24 hours. After executing the process in step S65, the non-friendly device 52 executes the process in step S68 when the specified condition RC for the non-friendly device 52 is satisfied. In step S68, the non-friendly device 52 confirms that the specified condition RC is satisfied. Once the non-friendly device 52 confirms that the specified condition RC is satisfied, the non-friendly device 52 proceeds to step S69.

[0118] In step S69, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion request D42. The non-friend device 52 then sends a deletion completion notification M44 to the management server 70, indicating that it has completed the deletion in accordance with the deletion request D42.

[0119] The specified condition RC for vehicle 20 is that a predetermined fade-out period has elapsed since vehicle 20 received the deletion request. The fade-out period is, for example, 24 hours. After vehicle 20 has executed the process in step S67, it executes the process in step S70 when the specified condition RC for vehicle 20 is satisfied. In step S70, vehicle 20 confirms that the specified condition RC is satisfied. Once vehicle 20 confirms that the specified condition RC is satisfied, vehicle 20 proceeds to step S71.

[0120] In step S71, the vehicle 20 deletes the authentication information AT used to authenticate the non-friendly key KN that is the target of deletion reservation request D41, in accordance with deletion request D43. That is, the vehicle 20 deletes the authentication package ATP for the non-friendly key KN. Subsequently, the vehicle 20 sends a deletion completion notification M45 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with deletion request D43.

[0121] When the management server 70 receives a completion notification M44 from the non-friendly device 52, the management server 70 performs the process in step S72. In step S72, the management server 70 stores the history of the deletion of the non-friendly key information DKN in the non-friendly device 52.

[0122] When the management server 70 receives a completion notification M45 from the vehicle 20, the management server 70 performs the process in step S73. In step S73, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the non-friend key KN that is to be deleted in this series of deletion processes in the vehicle 20.

[0123] In Figure 8, the management server 70 receives the completion notification from the non-friendly device 52 before the vehicle 20, but it is also possible that the management server 70 receives the completion notification from the vehicle 20 first. In this case, the order in which the management server 70 executes the processes in step S72 and step S73 may be reversed.

[0124] After executing the processes in step S72 and step S73, the management server 70 executes the process in step S74. In step S74, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52, which has the non-friend key KN that is the target of deletion in this series of processes, from the vehicle data DA of the vehicle 20 in the database DB. Subsequently, the management server 70 sends a deletion completion notification M46 to the friend device 51, indicating that it has completed the deletion of the series of non-friend keys KN in accordance with the deletion reservation request D41.

[0125] Subsequently, when the friend device 51 receives the completion notification M46, the friend device 51 performs the process in step S75. In step S73, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key KN, which was the target of the deletion reservation request D41, has been completed. For example, the friend device 51 displays an image on the HMI 32 indicating that the deletion of the non-friend key KN has been completed. After that, the management system 10 completes the series of processes for the deletion of this non-friend key KN.

[0126] <Deletion of non-friend key KN due to deletion operation on non-friend device 52> As shown in Figure 9, the management system 10 performs a series of operations to delete the non-friend key KN indicated by the non-friend key information DKN stored in the non-friend device 52, in response to a deletion operation on the non-friend device 52.

[0127] When a predetermined operation is performed in the non-friend device 52 to request the deletion of the non-friend key KN, the non-friend device 52 first performs the process in step S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN according to a predetermined operation. After that, the non-friend device 52 sends a deletion completion notification M51 to the management server 70 indicating that the non-friend key information DKN has been deleted.

[0128] Subsequently, when the management server 70 receives the completion notification M51, the management server 70 performs the process in step S82. In step S82, the management server 70 stores the history of the deletion of the non-friend key information DKN on the non-friend device 52. Then, the management server 70 sends a completion notification M52 to the friend device 51 indicating that the deletion of the non-friend key information DKN has been completed.

[0129] Subsequently, when the friend device 51 receives the completion notification M52, the friend device 51 performs the process in step S83. In step S83, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key information DKN of the non-friend device 52 is complete. For example, the friend device 51 displays an image on the HMI 32 indicating that the deletion of the non-friend key KN is complete.

[0130] After processing in step S82, the management server 70 performs the processing in step S84. In step S84, the management server 70 generates a deletion request D51 that requests the deletion of the authentication information AT used to authenticate the non-friend key information DKN, which was deleted in step S81. The management server 70 then sends the deletion request D51 to the vehicle 20.

[0131] Subsequently, when vehicle 20 receives deletion request D51, vehicle 20 performs the process in step S85. In step S85, vehicle 20 deletes the authentication information AT used to authenticate the non-friend key information DKN that was deleted in step S81, in accordance with deletion request D51. Then, vehicle 20 sends a completion notification M53 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with deletion request D51.

[0132] Subsequently, when the management server 70 receives the completion notification M53, the management server 70 performs the process in step S86. In step S86, the management server 70 stores the history of deleting the authentication information AT used to authenticate the non-friend key information DKN, which was deleted in step S81. After that, the management server 70 proceeds to step S87.

[0133] In step S87, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friendly device 52, which has the non-friendly key KN that is the target of this series of processes, from the vehicle 20 data DA in the database DB. With this, the management system 10 completes the series of processes for deleting the non-friendly key KN.

[0134] <Deleting Friend Key KF> Next, we will describe the series of processes for deleting the friend key KF in the management system 10. Below, we will describe the sequence of events from the state in which the friend key KF is registered to the state in which the friend key KF is not registered. 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 36 will be described as processes executed by the device 30, and the processes executed by the execution device 71 will be described as processes executed by the management server 70.

[0135] <Deletion of Friend Key KF at the request of Owner Device 40> As shown in Figure 10, the management system 10 performs a series of operations to delete the friend key KF based on the deletion reservation request D61 from the owner device 40. In the series of operations shown in Figure 10, the operations performed by the management server 70 are executed by the deletion program PC, which has the execution device 71 perform the operations.

[0136] When an operation is performed on the owner device 40 to request the deletion of friend key KF, the owner device 40 first performs the process in step S91. In step S91, a deletion reservation request D61 for friend key KF is generated. The deletion reservation request D61 is a request for deletion reservation. The deletion reservation request D61 is a signal that requests the deletion of friend key KF when the specified condition RC, described later, is met.

[0137] The deletion reservation request D61 includes a signal requesting the deletion of friend key KF, and information indicating the digital key identification information ST3 that identifies friend key KF. The owner device 40 then sends the friend key KF deletion reservation request D61 to the management server 70.

[0138] Subsequently, when the management server 70 receives the deletion reservation request D61 for friend key KF, it performs the process in step S92. In step S92, the management server 70 generates a deletion pending notification M61 indicating that the deletion is pending in accordance with the deletion reservation request D61. The management server 70 then sends the deletion pending notification M61 to the owner device 40.

[0139] Subsequently, when the owner device 40 receives the deletion pending notification M61, the owner device 40 performs the process in step S93. In step S93, the owner device 40 presents information to the HMI 32 indicating that the friend key KF, which is the subject of the deletion reservation request D61, is pending deletion and will be deleted as soon as the specified condition RC is met.

[0140] The specified condition RC is a condition required to start deletion after the deletion reservation request D61 has been sent. The specified condition RC is predetermined. In Figure 10, there are two specified condition RCs: one for the friend device 51 and one for the vehicle 20. When at least one of the specified condition RCs, the friend key KF that is the target of the deletion reservation request D61, is deleted.

[0141] After processing in step S92, the management server 70 performs the processing in step S94. In step S94, the management server 70 generates a deletion request D62 that requests the deletion of the friend key information DKF, which indicates the friend key KF that is the target of the deletion reservation request D61. The management server 70 then sends the deletion request D62 to the friend device 51.

[0142] Subsequently, when the friend device 51 receives the deletion request D62, the friend device 51 sends a response notification M62 to the management server 70. The response notification M62 is a notification indicating that the friend device 51 has received the deletion request D62.

[0143] Subsequently, the friend device 51 performs the process in step S95. In step S95, the friend device 51 stores in the storage device 37 the state of the friend key KF, which is the target of the deletion reservation request D61, as a fade-out state. The fade-out state is a state in which the deletion reservation request D61 has been sent, but the execution of the deletion is still pending.

[0144] After sending the deletion request D62, the management server 70 executes the process in step S96. In step S96, the management server 70 generates a deletion request D63 for the authentication information AT. This deletion request D63 for the authentication information AT indicates a request to delete the authentication information AT used to authenticate the friend key KF that is the target of the deletion reservation request D61. The management server 70 then sends the deletion request D63 to the vehicle 20.

[0145] Subsequently, when vehicle 20 receives deletion request D63, vehicle 20 sends a response notification M63 to the management server 70. Response notification M63 is a notification indicating that vehicle 20 has received deletion request D63.

[0146] Subsequently, the vehicle 20 performs the process in step S97. In step S97, the vehicle 20 stores in the storage device 28 the state of the friend key KF, which is the target of the deletion reservation request D61, as a fade-out state.

[0147] For friend device 51, the specified condition RC is that a predetermined fade-out period has elapsed since friend device 51 received the deletion request. The fade-out period is, for example, 24 hours. After performing the processing in step S95, friend device 51 performs the processing in step S98 when the specified condition RC for friend device 51 is satisfied. In step S98, friend device 51 confirms that the specified condition RC is satisfied. Once friend device 51 confirms that the specified condition RC is satisfied, friend device 51 proceeds to step S99.

[0148] In step S99, the friend device 51 deletes the friend key information DKF in accordance with the deletion request D62. The friend device 51 then sends a deletion completion notification M64 to the management server 70, indicating that it has completed the deletion in accordance with the deletion request D62.

[0149] For vehicle 20, the specified condition RC is that a predetermined fade-out period has elapsed since vehicle 20 received the deletion request. The fade-out period is, for example, 24 hours. After vehicle 20 has executed the process in step S97, when the specified condition RC for vehicle 20 is satisfied, it executes the process in step S100. In step S100, vehicle 20 confirms that the specified condition RC is satisfied. Once it confirms that vehicle 20 has satisfied the specified condition RC, the management server 70 proceeds to step S101.

[0150] In step S101, the vehicle 20 deletes the authentication information AT used to authenticate the friend key KF, which is the target of the deletion reservation request D61, in accordance with the deletion request D63. That is, the vehicle 20 deletes the authentication package ATP for the friend key KF. Subsequently, the vehicle 20 sends a deletion completion notification M65 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion request D63.

[0151] When the management server 70 receives a completion notification M64 from the friend device 51, the management server 70 performs the process in step S102. In step S102, the management server 70 stores the history of the deletion of the friend key information DKF on the friend device 51.

[0152] When the management server 70 receives a completion notification M65 from the vehicle 20, the management server 70 performs the process in step S103. In step S103, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the friend key KF that is to be deleted in this series of deletion processes in the vehicle 20.

[0153] In Figure 10, the management server 70 receives the completion notification from the friend device 51 before the vehicle 20, but it is also possible that the management server 70 receives the completion notification from the vehicle 20 first. In this case, the order in which the management server 70 executes the process in step S102 and the process in step S103 may be reversed.

[0154] After executing the processes in step S102 and step S103, the management server 70 executes the process in step S104. In step S104, the management server 70 updates the database DB. Specifically, the management server 70 deletes the friend device 51 having the friend key KF, which is the target of deletion in this series of processes, from the vehicle data DA of the vehicle 20 in the database DB. Subsequently, the management server 70 sends a deletion completion notification M66 to the owner device 40 indicating that it has completed the series of deletions of friend key KF in accordance with the deletion reservation request D61.

[0155] Subsequently, when the owner device 40 receives the completion notification M66, the owner device 40 performs the process in step S105. In step S105, the owner device 40 presents information to the HMI 32 indicating that the deletion of the friend key KF, which was the subject of the deletion reservation request D61, has been completed. For example, the owner device 40 displays an image on the HMI 32 indicating that the deletion of the friend key KF has been completed. After that, the management system 10 completes the series of processes for the deletion of the friend key KF.

[0156] <Deletion of Friend Key KF due to deletion operation on Friend Device 50> As shown in Figure 11, the management system 10 performs a series of operations to delete the friend key KF indicated by the friend key information DKF stored in the friend device 51, in response to a deletion operation on the friend device 51.

[0157] When a predetermined operation is performed on the friend device 51 to request the deletion of the friend key KF, the friend device 51 first performs the process in step S111. In step S111, the friend device 51 deletes the friend key information DKF according to a predetermined operation. After that, the friend device 51 sends a deletion completion notification M71 to the management server 70 indicating that the friend key information DKF has been deleted.

[0158] Subsequently, when the management server 70 receives the completion notification M71, the management server 70 performs the process in step S112. In step S112, the management server 70 stores the history of the deletion of the friend key information DKF on the friend device 51. Then, the management server 70 sends a completion notification M72 to the owner device 40 indicating that the deletion of the friend key information DKF has been completed.

[0159] Subsequently, when the owner device 40 receives the completion notification M72, the owner device 40 performs the process in step S113. In step S113, the owner device 40 presents information to the HMI 32 indicating that the deletion of the friend key information DKF of the friend device 51 is complete. For example, the owner device 40 displays an image on the HMI 32 indicating that the deletion of the friend key KF is complete.

[0160] After the processing in step S112, the management server 70 performs the processing in step S114. In step S114, the management server 70 generates a deletion request D71 that requests the deletion of the authentication information AT used to authenticate the friend key information DKF, which was deleted in step S111. The management server 70 then sends the deletion request D71 to the vehicle 20.

[0161] Subsequently, when vehicle 20 receives deletion request D71, vehicle 20 performs the process in step S115. In step S115, vehicle 20 deletes the authentication information AT used to authenticate the friend key information DKF that was deleted in step S111, in accordance with deletion request D71. Then, vehicle 20 sends a completion notification M73 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with deletion request D71.

[0162] Subsequently, when the management server 70 receives the completion notification M73, the management server 70 performs the process in step S116. In step S116, the management server 70 stores the history of deleting the authentication information AT used to authenticate the friend key information DKF, which was deleted in step S111. After that, the management server 70 proceeds to step S117.

[0163] In step S117, the management server 70 updates the database DB. Specifically, the management server 70 deletes the friend device 51, which has the friend key KF that is the target of this series of processes, from the vehicle data DA of the vehicle 20 in the database DB. With this, the management system 10 completes the series of processes for deleting the friend key KF.

[0164] <Deletion of digital keys when management system 10 is unable to communicate> As shown in Figure 8, when a non-friend key KN is to be deleted at the request of the friend device 51, the management server 70 sends a deletion request D42 to the non-friend device 52. Upon receiving the deletion request D42, the non-friend device 52 deletes the non-friend key information DKN for the non-friend key KN that is being requested to be deleted.

[0165] As shown in Figure 8, when a non-friend key KN is to be deleted at the request of the friend device 51, the management server 70 sends a deletion request D43 to the vehicle 20. Upon receiving the deletion request D43, the vehicle 20 deletes the authentication information AT for the non-friend key KN that is being requested to be deleted.

[0166] As shown in Figure 10, when a friend key KF is to be deleted at the request of the owner device 40, the management server 70 sends a deletion request D62 to the friend device 51. Upon receiving the deletion request D62, the friend device 51 deletes the friend key information DKF for the friend key KF that is being requested to be deleted.

[0167] As shown in Figure 10, when the friend key KF is to be deleted at the request of the owner device 40, the management server 70 sends a deletion request D63 to the vehicle 20. Upon receiving the deletion request D63, the vehicle 20 deletes the authentication information AT for the friend key KF that is being requested to be deleted.

[0168] Thus, in the management system 10, when a digital key is to be deleted, the management server 70 sends a deletion request to the vehicle 20 and the device 30. Upon receiving the deletion request, the vehicle 20 deletes the authentication information AT, and the device 30, upon receiving the deletion request, deletes the key information DK.

[0169] As mentioned above, if either the authentication information AT stored in the vehicle 20 or the key information DK stored in the device 30 is deleted, the digital key will no longer be able to control the vehicle 20.

[0170] In some cases, such as when both the vehicle 20 and the device 30 are in a location where radio waves cannot reach them, the management system 10 may perceive that both the vehicle 20 and the device 30 are unable to communicate. In this case, even if the deletion of the digital key is requested, the device 30 and the vehicle 20 cannot receive the deletion request from the management server 70, and therefore the digital key is not deleted in the management system 10.

[0171] In this situation, the management server 70 takes action to delete the digital key. <Deleting non-friend keys (KN) in situations where communication is impossible> The following describes a series of processes executed by the management system 10 when the vehicle 20 and the non-friend device 52 are unable to communicate, and the friend device 51 requests the deletion of the non-friend key KN. In the following description, the processes executed by the execution device 27 are described as processes executed by the vehicle 20, the processes executed by the execution device 36 are described as processes executed by the device 30, and the processes executed by the execution device 71 are described as processes executed by the management server 70. Furthermore, in the following description, the processes executed by the management server 70 are executed by the deletion program PC, which instructs the execution device 71 to execute them.

[0172] <Detection of communication failure by management server 70> Figure 12 shows how the management server 70 detects that both the vehicle 20 and the non-friendly device 52 are unable to communicate.

[0173] As shown in Figure 12, the process from when the friend device 51 generates the delete reservation request D41 until the friend device 51 displays "deletion pending" is the same as the process from steps S61 to S63 in Figure 8.

[0174] In Figure 12, the management server 70 executes the process in step S62 and then the process in step S64, similar to Figure 8. In step S64, the management server 70 generates a deletion request D42 for the non-friendly key information DKN. This process is the same as the process in step S64 in Figure 8. Subsequently, the management server 70 sends the deletion request D42 to the non-friendly device 52.

[0175] As shown in Figure 12, the management server 70 executes the process in step S64, and then the process in step S66. In step S66, the management server 70 generates a deletion request D43 for the authentication information AT. This process is the same as the process in step S66 in Figure 8. Subsequently, the management server 70 sends the deletion request D43 to the vehicle 20.

[0176] In Figure 12, the non-friendly device 52 is in a state where communication is impossible, and therefore does not receive the deletion request D42. Consequently, in Figure 12, unlike in Figure 8, the non-friendly device 52 does not receive the deletion request D42 and does not execute the processes in steps S65, S68, and S69.

[0177] As shown in Figure 8, when the non-friendly device 52 receives a deletion request D42, it sends a response notification M42 to the management server 70. In Figure 12, the non-friendly device 52 does not receive a deletion request D42, and therefore does not send a response notification M42 to the management server 70.

[0178] If the management server 70 does not receive a response notification M42 from the non-friendly device 52 after a certain period of time has elapsed since sending the deletion request D42, it executes the process in step S121. In step S121, the management server 70 determines that the non-friendly device 52 is in a state where communication is impossible.

[0179] In Figure 12, vehicle 20 is in a state where communication is impossible, and therefore does not receive deletion request D43. Consequently, in Figure 12, unlike in Figure 8, vehicle 20 does not receive deletion request D43 and does not execute the processes in steps S67, S70, and S71.

[0180] As shown in Figure 8, when vehicle 20 receives deletion request D43, vehicle 20 sends a response notification M43 to the management server 70. In Figure 12, vehicle 20 does not receive deletion request D43, and therefore does not send a response notification M43 to the management server 70.

[0181] If the management server 70 does not receive a response notification M43 from the vehicle 20 after a certain period of time has elapsed since sending the deletion request D43, it executes the process in step S122. In step S122, the management server 70 determines that the vehicle 20 is in a state where communication is impossible. This completes the series of processes shown in Figure 12.

[0182] The management server 70 detects that both the vehicle 20 and the non-friendly device 52 are unable to communicate by executing the processes in step S121 and step S122.

[0183] <Processing performed after a communication failure is detected (up to step S133)> Figure 13 shows an example of a series of processes that the management system 10 executes after the management server 70 detects that both the vehicle 20 and the non-friendly device 52 are unable to communicate. The management system 10 executes the series of processes shown in Figure 12, and then executes the series of processes shown in Figure 13.

[0184] After detecting that both the vehicle 20 and the non-friendly device 52 are unable to communicate, the management server 70 first executes the process in step S131. In step S131, the management server 70 generates a deletion request D81. Deletion request D81 is a request that adds information to the deletion request D42 in Figure 12, indicating that the request was sent again because the non-friendly device 52 was unable to communicate. Deletion request D81 includes information indicating the time when deletion request D42 was sent in Figure 12.

[0185] Next, the management server 70 executes the process in step S132. In step S132, the management server 70 generates a deletion request D82. Deletion request D82 is a request that adds information to the deletion request D43 in Figure 12, indicating that the request was sent again because the vehicle 20 was in a state where communication was impossible. Deletion request D82 includes information indicating the time when deletion request D43 was sent in Figure 12.

[0186] As shown in Figure 13, after executing the process in step S131, the management server 70 repeatedly sends deletion requests D81 to the non-friendly device 52. When the non-friendly device 52 returns to a communicable state from a non-communication state, it becomes able to receive the deletion requests sent from the management server 70. The management server 70 continues to send deletion requests D81 until the non-friendly device 52 returns to a communicable state.

[0187] As shown in Figure 13, after executing the process in step S132, the management server 70 repeatedly sends deletion requests D82 to the vehicle 20. When the vehicle 20 returns to a state where it can communicate after being unable to communicate, it will be able to receive the deletion requests sent from the management server 70. The management server 70 continues to send deletion requests D82 until the vehicle 20 returns to a state where it can communicate.

[0188] In Figure 13, the non-friend device 52 returns to a communicable state before the vehicle 20 and receives the deletion request D81. Upon receiving the deletion request D81, the non-friend device 52 sends a response notification M81 to the management server 70. The response notification M81 is a notification indicating that the non-friend device 52 has received the deletion request D81. When the management server 70 receives the response notification M81, it stops sending the deletion request D81.

[0189] Upon receiving the deletion request D81, the non-friend device 52 executes the process in step S133. In step S133, the non-friend device 52 executes the recovery deletion process. The recovery deletion process executed by the non-friend device 52 is a process in which the timing of deleting the non-friend key information DKN changes depending on the circumstances when the non-friend device 52 received the deletion request D81.

[0190] <Flowchart of the deletion process performed by Non-Friendly Device 52 upon recovery> Figure 14 shows the process by which the non-friendly device 52 performs the recovery deletion process. In step S133 of Figure 13, the non-friendly device 52 performs the series of processes shown in Figure 14.

[0191] As shown in Figure 14, the non-friendly device 52 first performs the process in step S141. In the process of step S141, the non-friendly device 52 determines whether a fade-out period has elapsed between the time the first deletion request was sent to the non-friendly device 52 and the time the non-friendly device 52 receives the deletion request D81.

[0192] Deletion request D42 is the first deletion request sent to the non-friendly device 52 by the management system 10. In the processing of step S141, the non-friendly device 52 determines whether the period from when deletion request D42 is sent until when the non-friendly device 52 receives deletion request D81 is longer than the fade-out period. At this time, the non-friendly device 52 makes the determination based on the information included in deletion request D81 that indicates the time when deletion request D42 was sent.

[0193] The non-friendly device 52 determines that the fade-out period has not elapsed if it determines that the period from when the deletion request D42 is sent until when the non-friendly device 52 receives the deletion request D81 is less than or equal to the length of the fade-out period. If the non-friendly device 52 determines that the fade-out period has not elapsed (step S141: NO), it proceeds to step S144. In step S144, the non-friendly device 52 stores the fade-out state. This process is the same as the process that the non-friendly device 52 performs in step S65 of Figure 8.

[0194] After executing the process in step S144, the non-friendly device 52 executes the process in step S145 when the specified condition RC is met. At this time, the non-friendly device 52 determines that the specified condition RC is met when the fade-out period has elapsed since the deletion request D42 was sent. In step S145, the non-friendly device 52 confirms that the specified condition RC is met.

[0195] After executing the process in step S145, the non-friendly device 52 executes the process in step S146. In step S146, the non-friendly device 52 deletes the non-friendly key information DKN. This process is the same as the process executed by the non-friendly device 52 in step S69 in Figure 8. After that, the non-friendly device 52 terminates the series of processes shown in Figure 14.

[0196] The non-friendly device 52 determines that the fade-out period has elapsed if it determines that the period from when the delete request D42 is sent until when the non-friendly device 52 receives the delete request D81 is longer than the fade-out period. If the non-friendly device 52 determines that the fade-out period has elapsed (step S141: YES), it proceeds to step S142.

[0197] In step S142, the non-friend device 52 determines whether the owner of the target digital key is currently using the vehicle 20. The target digital key is the digital key to be deleted. In the series of processes shown in Figures 12 and 13, the target digital key is the non-friend key KN targeted by the deletion reservation request D41. The device 30 that stores the key information DK of the target digital key is the target device. In the series of processes shown in Figures 12 and 13, the target device is the non-friend device 52.

[0198] As mentioned above, the digital key can control the vehicle 20 while authentication is complete. The non-friend device 52 determines that the owner of the digital key is using the vehicle 20 when the non-friend key KN registered for it is in an authenticated state.

[0199] If the non-friend device 52 determines that the owner of the target digital key is not using the vehicle 20 (step S142: NO), it proceeds to step S146. As mentioned above, in step S146, the non-friend device 52 deletes the non-friend key information DKN. After that, the non-friend device 52 terminates the series of processes shown in Figure 14.

[0200] Thus, under certain conditions, the non-friend device 52 deletes the non-friend key information DKN after receiving a deletion request, without waiting for the fade-out period to elapse. If the non-friendly device 52 determines that the owner of the target digital key is using the vehicle 20 (step S142: YES), it proceeds to step S143. In step S143, the non-friendly device 52 confirms that the engine of the vehicle 20 is stopped. For example, the non-friendly device 52 communicates with the vehicle 20 via BLE communication and, as a result of the communication, confirms that the engine is stopped when it receives a message from the vehicle 20 indicating that the engine is stopped.

[0201] After executing the process in step S143, the non-friend device 52 executes the process in step S146. As mentioned above, in step S146, the non-friend device 52 deletes the non-friend key information DKN. After that, the non-friend device 52 terminates the series of processes shown in Figure 14.

[0202] Thus, even if the non-friend device 52 determines in step S141 that the fade-out period has elapsed, if the owner of the target digital key is using the vehicle 20, it will not delete the non-friend key information DKN until the engine is stopped.

[0203] <Processing performed after a communication failure is detected (up to step S135)> As shown in Figure 13, after the non-friend device 52 performs the process in step S133, it sends a deletion completion notification M82 to the management server 70 indicating that it has completed the deletion in accordance with the deletion request D81.

[0204] When the management server 70 receives a completion notification M82 from the non-friendly device 52, the management server 70 performs the process in step S134. In step S134, the management server 70 stores the history of the deletion of the non-friendly key information DKN in the non-friendly device 52. This process is the same as the process in step S72 in Figure 8.

[0205] Even after receiving a response notification M81 from the non-friendly device 52, the management server 70 continues to send deletion requests D82 to the vehicle 20. In Figure 13, vehicle 20 returns to a communicative state after the non-friend device 52 returns to a communicative state, and also receives deletion request D82. Upon receiving deletion request D82, vehicle 20 sends a response notification M83 to the management server 70. Response notification M83 is a notification indicating that vehicle 20 has received deletion request D82. When the management server 70 receives response notification M83, it stops sending deletion request D82.

[0206] Upon receiving deletion request D82, vehicle 20 executes the process in step S135. In step S135, vehicle 20 executes the recovery deletion process. The recovery deletion process executed by vehicle 20 is a process in which the timing of deletion of authentication information AT changes depending on the circumstances when vehicle 20 receives deletion request D82.

[0207] <Flowchart of the deletion process performed by vehicle 20 upon recovery> Figure 15 shows the process by which vehicle 20 performs the deletion process upon recovery. In step S135 of Figure 13, vehicle 20 performs the series of processes shown in Figure 15.

[0208] As shown in Figure 15, the vehicle 20 first executes the process in step S151. In the process of step S151, the vehicle 20 determines whether a fade-out period has elapsed between the time the initial deletion request was sent to the vehicle 20 and the time the vehicle 20 receives the deletion request D82.

[0209] Deletion request D43 is the first deletion request sent to vehicle 20 by the management system 10. In the processing of step S151, vehicle 20 determines whether the period from when deletion request D43 is sent until when vehicle 20 receives deletion request D82 is longer than the fade-out period. At this time, vehicle 20 makes the determination based on the information included in deletion request D82 that indicates the time when deletion request D43 was sent.

[0210] Vehicle 20 determines that the fade-out period has not elapsed if it determines that the period from when deletion request D43 is sent until when vehicle 20 receives deletion request D82 is less than or equal to the length of the fade-out period. If vehicle 20 determines that the fade-out period has not elapsed (step S151: NO), it proceeds to step S154. In step S154, vehicle 20 stores the fade-out state. This process is the same as the process that vehicle 20 performs in step S67 in Figure 8.

[0211] After the vehicle 20 has executed the process in step S154, it executes the process in step S155 when the specified condition RC is met. At this time, the vehicle 20 determines that the specified condition RC is met when the fade-out period has elapsed since the deletion request D43 was sent. In step S155, the vehicle 20 confirms that the specified condition RC is met.

[0212] After performing the process in step S155, vehicle 20 performs the process in step S156. In step S156, vehicle 20 deletes the authentication information AT. This process is the same as the process performed by vehicle 20 in step S71 in Figure 8. After that, vehicle 20 completes the series of processes shown in Figure 15.

[0213] Vehicle 20 determines that the fade-out period has elapsed if it determines that the period from when deletion request D43 is sent until when vehicle 20 receives deletion request D82 is longer than the fade-out period. If vehicle 20 determines that the fade-out period has elapsed (step S151: YES), it proceeds to step S152.

[0214] In step S152, the vehicle 20 determines whether the owner of the target digital key is currently using the vehicle 20. As mentioned earlier, the digital key can control the vehicle 20 while authentication is complete. The vehicle 20 determines that the owner of the digital key in question is using the vehicle 20 if the non-friend key KN that is being requested to be deleted is in an authenticated state.

[0215] If vehicle 20 determines that the owner of the target digital key is not currently using vehicle 20 (step S152: NO), it proceeds to step S156. As mentioned above, in step S156, vehicle 20 deletes the authentication information AT. After that, vehicle 20 completes the series of processes shown in Figure 15.

[0216] Thus, under certain conditions, vehicle 20 deletes the authentication information AT after receiving a deletion request without waiting for the fade-out period to elapse. If vehicle 20 determines that the owner of the target digital key is currently using vehicle 20 (step S152: YES), the process proceeds to step S153. In step S153, vehicle 20 confirms that the engine of vehicle 20 is stopped.

[0217] After performing the process in step S153, vehicle 20 performs the process in step S156. As mentioned above, in step S156, vehicle 20 deletes the authentication information AT. After that, vehicle 20 completes the series of processes shown in Figure 15.

[0218] Thus, even if vehicle 20 determines in step S151 that the fade-out period has elapsed, if the owner of the target digital key is using vehicle 20, the authentication information AT will not be deleted until the engine is stopped.

[0219] <Processing executed after a communication failure is detected (from step S135 onwards)> As shown in Figure 13, after the vehicle 20 has performed the process in step S135, it sends a deletion completion notification M84 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion request D82.

[0220] When the management server 70 receives a completion notification M84 from the vehicle 20, the management server 70 performs the process in step S136. In step S136, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the non-friend key KN that is to be deleted in this series of deletion processes in the vehicle 20. This process is the same as the process in step S73 in Figure 8.

[0221] After performing the processes in step S134 and step S136, the management server 70 performs the process in step S137. In step S137, the management server 70 updates the database DB. This process is the same as the process performed by the management server 70 in step S74 in Figure 8. Subsequently, the management server 70 sends a deletion completion notification M85 to the friend device 51, indicating that it has completed the deletion of a series of non-friend keys KN in accordance with the deletion reservation request D41.

[0222] Subsequently, when the friend device 51 receives the completion notification M85, the friend device 51 performs the process in step S138. In step S138, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key KN, which is the target of the deletion reservation request D41, has been completed. This process is the same as the process performed by the friend device 51 in step S75 of Figure 8. After that, the management system 10 completes the series of processes for the deletion of the non-friend key KN.

[0223] In Figure 13, the non-friendly device 52 returns to a communicative state and receives deletion request D81 before the vehicle 20. On the other hand, it is also possible that the vehicle 20 returns to a communicative state and receives deletion request D82 before the non-friendly device 52. In this case, the order in which the management server 70 executes the processes in step S134 and step S136 may be reversed.

[0224] Furthermore, in Figure 13, the management server 70 continues to send the deletion request D82 even after receiving the completion notification M82 from the non-friendly device 52. In the management system 10, after either the vehicle 20 or the non-friendly device 52 receives a deletion request, it is possible that the other device may return to a state where it can communicate before the completion notification is sent based on the received deletion request.

[0225] <Deleting Friend Key KF in situations where communication is impossible> The following describes a series of processes that the management system 10 executes when the owner device 40 requests the deletion of the friend key KF while the vehicle 20 and friend device 51 are unable to communicate. In the following description, the processes executed by the execution device 27 are described as processes executed by the vehicle 20, the processes executed by the execution device 36 are described as processes executed by the device 30, and the processes executed by the execution device 71 are described as processes executed by the management server 70. Furthermore, in the following description, the processes executed by the management server 70 are executed by the deletion program PC, which instructs the execution device 71 to execute them.

[0226] <Detection of communication failure by management server 70> Figure 16 shows how the management server 70 detects that both the vehicle 20 and the friend device 51 are unable to communicate.

[0227] As shown in Figure 16, the process from when the owner device 40 generates the delete reservation request D61 until the owner device 40 displays "deletion pending" is the same as the process from steps S91 to S93 in Figure 10.

[0228] In Figure 16, the management server 70 executes the process in step S92 and then the process in step S94, similar to Figure 10. In step S94, the management server 70 generates a deletion request D62 for the friend key information DKF. This process is the same as the process in step S94 in Figure 10. Subsequently, the management server 70 sends the deletion request D62 to the friend device 51.

[0229] As shown in Figure 16, the management server 70 executes the process in step S94, and then the process in step S96. In step S96, the management server 70 generates a deletion request D63 for the authentication information AT. This process is the same as the process in step S96 in Figure 10. Subsequently, the management server 70 sends the deletion request D63 to the vehicle 20.

[0230] In Figure 16, the friend device 51 is in a state where communication is impossible, and therefore does not receive the deletion request D62. For this reason, unlike in Figure 10, the friend device 51 does not receive the deletion request D62 and does not execute steps S95, S98, and S99 in Figure 16.

[0231] As shown in Figure 10, when the friend device 51 receives a deletion request D62, the friend device 51 sends a response notification M62 to the management server 70. In Figure 16, the friend device 51 does not receive a deletion request D62, and therefore does not send a response notification M62 to the management server 70.

[0232] If the management server 70 does not receive a response notification M62 from the friend device 51 after a certain period of time has elapsed since sending the deletion request D62, it executes the process in step S161. In step S161, the management server 70 determines that the friend device 51 is in a state where communication is impossible.

[0233] In Figure 16, vehicle 20 is in a state where communication is impossible, and therefore does not receive the deletion request D63. Consequently, in Figure 16, unlike in Figure 10, vehicle 20 does not receive the deletion request D63 and does not execute the processes in steps S97, S100, and S101.

[0234] As shown in Figure 10, when vehicle 20 receives deletion request D63, vehicle 20 sends a response notification M63 to the management server 70. In Figure 16, vehicle 20 does not receive deletion request D63, and therefore does not send a response notification M63 to the management server 70.

[0235] If the management server 70 does not receive a response notification M63 from the vehicle 20 after a certain period of time has elapsed since sending the deletion request D63, it executes the process in step S162. In step S162, the management server 70 determines that the vehicle 20 is in a state where communication is impossible. This completes the series of processes shown in Figure 16.

[0236] The management server 70 detects that both the vehicle 20 and the non-friendly device 52 are unable to communicate by executing the processes in step S161 and step S162.

[0237] <Processing executed after a communication failure is detected (up to step S173)> Figure 17 shows an example of a series of processes that the management system 10 executes after the management server 70 detects that both the vehicle 20 and the friend device 51 are unable to communicate. The management system 10 executes the series of processes shown in Figure 16, and then executes the series of processes shown in Figure 17.

[0238] After detecting that both the vehicle 20 and the friend device 51 are unable to communicate, the management server 70 first executes the process in step S171. In step S171, the management server 70 generates a deletion request D91. Deletion request D91 is a request that adds information to the deletion request D62 in Figure 16, indicating that the request was sent again because the friend device 51 was unable to communicate. Deletion request D91 includes information indicating the time when deletion request D62 was sent in Figure 16.

[0239] Next, the management server 70 executes the process in step S172. In step S172, the management server 70 generates a deletion request D92. Deletion request D92 is a request that adds information to the deletion request D63 in Figure 16, indicating that the request was sent again because the vehicle 20 was in a state where communication was impossible. Deletion request D92 includes information indicating the time when deletion request D63 was sent in Figure 16.

[0240] As shown in Figure 17, after executing the process in step S171, the management server 70 repeatedly sends deletion request D91 to the friend device 51. When the friend device 51 returns to a state where it can communicate after being unable to communicate, it becomes able to receive the deletion request sent from the management server 70. The management server 70 continues to send deletion request D91 until the friend device 51 returns to a state where it can communicate.

[0241] As shown in Figure 17, after executing the process in step S172, the management server 70 repeatedly sends deletion requests D92 to the vehicle 20. When the vehicle 20 returns to a state where it can communicate after being unable to communicate, it will be able to receive the deletion requests sent from the management server 70. The management server 70 continues to send deletion requests D92 until the vehicle 20 returns to a state where it can communicate.

[0242] In Figure 17, the friend device 51 returns to a communicable state before the vehicle 20 and receives the deletion request D91. Upon receiving the deletion request D91, the friend device 51 sends a response notification M91 to the management server 70. The response notification M91 is a notification indicating that the friend device 51 has received the deletion request D91. When the management server 70 receives the response notification M91, it stops sending the deletion request D91.

[0243] Upon receiving the deletion request D91, the friend device 51 executes the process in step S173. In step S173, the friend device 51 performs a recovery deletion process. The recovery deletion process performed by the friend device 51 is a deletion process in which the timing of deleting the friend key information DKF changes depending on the circumstances when the friend device 51 receives the deletion request D91.

[0244] <Flowchart of the deletion process performed by Friend Device 51 upon recovery> Figure 18 shows the process by which the friend device 51 performs the deletion process upon recovery. In step S173 of Figure 17, the friend device 51 performs the series of processes shown in Figure 18.

[0245] As shown in Figure 18, the friend device 51 first executes the process in step S181. In the process of step S181, the friend device 51 determines whether a fade-out period has elapsed between the time the first delete request was sent to the friend device 51 and the time the friend device 51 receives the delete request D91.

[0246] Deletion request D62 is the first deletion request sent to the friend device 51 by the management system 10. In the processing of step S181, the friend device 51 determines whether the period from when deletion request D62 is sent until when the friend device 51 receives deletion request D91 is longer than the fade-out period. At this time, the friend device 51 makes the determination based on the information included in deletion request D91 that indicates the time when deletion request D62 was sent.

[0247] Friend device 51 determines that the fade-out period has not elapsed if it determines that the period from when deletion request D62 is sent until when friend device 51 receives deletion request D91 is less than or equal to the length of the fade-out period. If friend device 51 determines that the fade-out period has not elapsed (step S181: NO), it proceeds to step S184. In step S184, friend device 51 stores the fade-out state. This process is the same as the process that friend device 51 performs in step S95 of Figure 10.

[0248] After the non-friend device 52 has executed the process in step S184, it executes the process in step S185 when the specified condition RC is met. At this time, the friend device 51 determines that the specified condition RC is met when the fade-out period has elapsed since the deletion request D62 was sent. In step S185, the friend device 51 confirms that the specified condition RC is met.

[0249] After executing the process in step S185, the friend device 51 executes the process in step S186. In step S186, the friend device 51 deletes the friend key information DKF. This process is the same as the process executed by the friend device 51 in step S99 in Figure 10. After that, the friend device 51 completes the series of processes shown in Figure 18.

[0250] The friend device 51 determines that the fade-out period has elapsed if it determines that the period from when the delete request D62 is sent until when the friend device 51 receives the delete request D91 is longer than the fade-out period. If the friend device 51 determines that the fade-out period has elapsed (step S181: YES), it proceeds to step S182.

[0251] In step S182, the friend device 51 determines whether the owner of the target digital key is currently using the vehicle 20. The target digital key is the digital key to be deleted. In the series of processes shown in Figures 16 and 17, the target digital key is the friend key KF targeted by the deletion reservation request D61. The device 30 that stores the key information DK of the target digital key is the target device. In the series of processes shown in Figures 16 and 17, the target device is the friend device 51.

[0252] As mentioned earlier, the digital key can control the vehicle 20 while authentication is complete. The friend device 51 determines that the owner of the digital key is using the vehicle 20 when the friend key KF registered for it is in an authenticated state.

[0253] If the friend device 51 determines that the owner of the target digital key is not currently using the vehicle 20 (step S182: NO), it proceeds to step S186. As mentioned above, in step S186, the friend device 51 deletes the friend key information DKF. After that, the friend device 51 completes the series of processes shown in Figure 18.

[0254] Thus, under certain conditions, the friend device 51 deletes the friend key information DKF after receiving a delete request without waiting for the fade-out period to elapse. If the friend device 51 determines that the owner of the target digital key is using the vehicle 20 (step S182: YES), it proceeds to step S183. In step S183, the friend device 51 confirms that the engine of the vehicle 20 is stopped. For example, the friend device 51 communicates with the vehicle 20 via BLE communication and, as a result of the communication, confirms that the engine is stopped when it receives a message from the vehicle 20 indicating that the engine is stopped.

[0255] After executing the process in step S183, the friend device 51 executes the process in step S186. As mentioned above, in step S186, the friend device 51 deletes the friend key information DKF. After that, the friend device 51 completes the series of processes shown in Figure 18.

[0256] Thus, even if the friend device 51 determines in step S181 that the fade-out period has elapsed, if the owner of the target digital key is using the vehicle 20, it will not delete the non-friend key information DKN until the engine is stopped.

[0257] <Processing executed after a communication failure is detected (up to step S175)> As shown in Figure 17, after the friend device 51 has performed the process in step S173, it sends a deletion completion notification M92 to the management server 70 indicating that it has completed the deletion in accordance with the deletion request D91.

[0258] When the management server 70 receives a completion notification M92 from the friend device 51, the management server 70 performs the process in step S174. In step S174, the management server 70 stores the history of the deletion of the friend key information DKF on the friend device 51. This process is the same as the process in step S102 in Figure 10.

[0259] Even after receiving a response notification M91 from the friend device 51, the management server 70 continues to send deletion requests D92 to the vehicle 20. In Figure 17, vehicle 20 returns to a communicative state after the friend device 51 returns to a communicative state, and also receives deletion request D92. Upon receiving deletion request D92, vehicle 20 sends a response notification M93 to the management server 70. Response notification M93 is a notification indicating that vehicle 20 has received deletion request D92. When the management server 70 receives response notification M93, it stops sending deletion request D92.

[0260] Upon receiving deletion request D92, vehicle 20 executes the process in step S175. In step S175, vehicle 20 executes a recovery deletion process. The recovery deletion process executed by vehicle 20 is a deletion process in which the timing of the deletion of authentication information AT changes depending on the circumstances when vehicle 20 received deletion request D92.

[0261] <Flowchart of the deletion process performed by vehicle 20 upon recovery> In step S175, the vehicle 20 performs the recovery deletion process in the manner described in Figure 15. Below, the recovery deletion process performed by the vehicle 20 when deleting the friend key KF will be explained with reference to Figure 15.

[0262] As shown in Figure 15, the vehicle 20 first executes the process in step S151. In the process of step S151, the vehicle 20 determines whether a fade-out period has elapsed between the time the initial deletion request was sent to the vehicle 20 and the time the vehicle 20 receives the deletion request D92.

[0263] Deletion request D63 is the first deletion request sent to vehicle 20 by the management system 10. In the processing of step S151, vehicle 20 determines whether the period from when deletion request D63 is sent until when vehicle 20 receives deletion request D92 is longer than the fade-out period. At this time, vehicle 20 makes the determination based on the information included in deletion request D92 that indicates the time when deletion request D63 was sent.

[0264] Vehicle 20 determines that the fade-out period has not elapsed if it determines that the period from when deletion request D63 is sent until when vehicle 20 receives deletion request D92 is less than or equal to the length of the fade-out period. If vehicle 20 determines that the fade-out period has not elapsed (step S151: NO), it proceeds to step S154. In step S154, vehicle 20 stores the fade-out state. This process is the same as the process that vehicle 20 performs in step S97 of Figure 10.

[0265] After executing the process of step S154, the vehicle 20 executes the process of step S155 when a predetermined condition RC is satisfied. At this time, the vehicle 20 determines that the predetermined condition RC is satisfied when a fade-out period has elapsed since the deletion request D63 was transmitted. In step S155, the vehicle 20 confirms that the predetermined condition RC is satisfied.

[0266] After executing the process of step S155, the vehicle 20 executes the process of step S156. In step S156, the vehicle 20 deletes the authentication information AT. This process is the same as the process executed by the vehicle 20 in step S101 of FIG. 10. Thereafter, the vehicle 20 ends the series of processes shown in FIG. 15.

[0267] If the vehicle 20 determines that the period from when the deletion request D63 is transmitted to when the vehicle 20 receives the deletion request D92 is longer than the fade-out period, the vehicle 20 determines that the fade-out period has elapsed. If the vehicle 20 determines that the fade-out period has elapsed (step S151: YES), the vehicle 20 advances the process to step S152.

[0268] In the process of step S152, the vehicle 20 determines whether or not the owner of the target digital key is using the vehicle 20. As described above, the digital key can control the vehicle 20 while authentication is completed. When the friend key KF requested to be deleted is in an authentication-completed state, the vehicle 20 determines that the owner of the target digital key is using the vehicle 20.

[0269] If the vehicle 20 determines that the owner of the target digital key is not using the vehicle 20 (step S152: NO), the vehicle 20 advances the process to step S156. As described above, in step S156, the vehicle 20 deletes the authentication information AT. Thereafter, the vehicle 20 ends the series of processes shown in FIG. 15.

[0270] Thus, under certain conditions, vehicle 20 deletes the authentication information AT after receiving a deletion request without waiting for the fade-out period to elapse. If vehicle 20 determines that the owner of the target digital key is currently using vehicle 20 (step S152: YES), the process proceeds to step S153. In step S153, vehicle 20 confirms that the engine of vehicle 20 is stopped.

[0271] After performing the process in step S153, vehicle 20 performs the process in step S156. As mentioned above, in step S156, vehicle 20 deletes the authentication information AT. After that, vehicle 20 completes the series of processes shown in Figure 15.

[0272] <Processing executed after a communication failure is detected (from step S175 onwards)> As shown in Figure 17, after the vehicle 20 has performed the process in step S175, it sends a deletion completion notification M94 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion request D92.

[0273] When the management server 70 receives a completion notification M94 from the vehicle 20, the management server 70 performs the process in step S176. In step S176, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the friend key KF that is to be deleted in this series of deletion processes in the vehicle 20. This process is the same as the process in step S103 in Figure 10.

[0274] After performing the processes in step S174 and step S176, the management server 70 performs the process in step S177. In step S177, the management server 70 updates the database DB. This process is the same as the process performed by the management server 70 in step S104 in Figure 10. Subsequently, the management server 70 sends a deletion completion notification M95 to the owner device 40, indicating that it has completed the series of deletions of friend key KF in accordance with the deletion reservation request D61.

[0275] Subsequently, when the owner device 40 receives the completion notification M95, the owner device 40 performs the process in step S178. In step S178, the owner device 40 presents information to the HMI 32 indicating that the deletion of friend key KF, which is the target of the deletion reservation request D61, has been completed. This process is the same as the process performed by the owner device 40 in step S105 of Figure 10. After that, the management system 10 completes the series of processes for the deletion of friend key KF.

[0276] In Figure 17, the friend device 51 returns to a communicable state and receives deletion request D91 before the vehicle 20. On the other hand, it is also possible that the vehicle 20 returns to a communicable state and receives deletion request D92 before the friend device 51. In this case, the order in which the management server 70 executes the processes in step S174 and step S176 may be reversed.

[0277] Furthermore, in Figure 17, the management server 70 continues to send the deletion request D92 even after receiving the completion notification M92 from the friend device 51. In the management system 10, after either the vehicle 20 or the friend device 51 receives a deletion request, it is possible that the other device may return to a state where it can communicate before the completion notification is sent based on the received deletion request.

[0278] <Operation of this embodiment> When the management system 10 receives a request to delete the target digital key, if both the vehicle 20 and the target device are unable to communicate, it waits until communication becomes possible with at least one of the vehicle 20 and the target device before sending the deletion request.

[0279] <Effects of this embodiment> (1) The management system 10 can delete the target digital key when a request for deletion of the target digital key is made, even if the vehicle 20 and the target device are offline.

[0280] (2) If the management system 10 sends a deletion request and both the target device and the vehicle 20 are unable to communicate, the management system 10 will repeatedly send deletion requests to the target device until the target device becomes able to communicate.

[0281] The management system 10 continues to send delete requests until the target device comes back online. This allows the management system 10 to receive the delete requests when the target device comes back online.

[0282] (3) If the management system 10 sends a deletion request and both the target device and the vehicle 20 are unable to communicate, the management system 10 will repeatedly send the deletion request to the vehicle 20 until the vehicle 20 becomes able to communicate.

[0283] The management system 10 continues to send deletion requests until the vehicle 20 comes back online. This allows the management system 10 to receive the deletion requests when the vehicle 20 comes back online.

[0284] (4) In the management system 10, the vehicle 20 and the target device delete the information about the target digital key that they have stored after receiving a deletion request and after the fade-out period has elapsed. In the management system 10, when the vehicle 20 and the target device receive a deletion request after they have transitioned from a state where communication is impossible to a state where communication is possible, if the period from when the deletion request is first sent until when the vehicle 20 receives the deletion request is longer than the fade-out period, the vehicle 20 deletes the information about the target digital key that it has stored, regardless of whether the fade-out period has elapsed after receiving the deletion request.

[0285] In the management system 10, the vehicle 20 and the target device will, in principle, not delete the information related to the target digital key even if a deletion request is received, until the fade-out period has elapsed. If a deletion request is sent after the vehicle 20 or the target device has returned to the online environment, the information related to the target digital key may not be deleted even if the information would have been deleted after the fade-out period had elapsed if the vehicle 20 or the target device had been online from the beginning. In the management system 10, if a deletion request is received after the vehicle 20 or the target device has returned to the online environment, the information related to the target digital key will be deleted regardless of whether the fade-out period has elapsed or not. This allows the management system 10 to suppress the effective extension of the fade-out period.

[0286] (5) When a deletion request is received by the vehicle 20 after it has transitioned from a state where communication is impossible to a state where communication is possible, even if the period from when the deletion request is first sent to when the vehicle 20 receives the deletion request is longer than the fade-out period, if the owner of the target digital key is using the vehicle 20, the vehicle 20 will not delete the information it stores about the target digital key until the engine of the vehicle 20 stops running.

[0287] If the target digital key is suddenly deleted while the owner of the target digital key is using the vehicle 20, the owner will suddenly be unable to use the vehicle 20. The management system 10, when the owner of the target digital key is using the vehicle 20, waits for the engine to stop running before deleting the information related to the target digital key. In this way, the management system 10 can prevent the situation in which the target digital key is suddenly deleted while the owner of the target digital key is using the vehicle 20.

[0288] (6) When requested to delete the target digital key, if the management server 70 is unable to communicate with both the vehicle 20 and the target device, it waits until communication becomes possible with at least one of the vehicle 20 and the target device, and then transmits the deletion request. This enables the management server 70 to delete the target digital key even if both the vehicle 20 and the target device are offline at the timing when the deletion of the target digital key is requested.

[0289] (7) When transmitting the deletion request, if both the target device and the vehicle 20 are in an uncommunicable state, the management server 70 repeatedly transmits the deletion request to the target device until the target device enters a communicable state.

[0290] The management server 70 continues transmitting the deletion request until the target device returns to online. This enables the management server 70 to transmit the deletion request when the target device returns to online.

[0291] (8) When transmitting the deletion request, if both the target device and the vehicle 20 are in an uncommunicable state, the management server 70 repeatedly transmits the deletion request to the vehicle 20 until the vehicle 20 enters a communicable state.

[0292] The management server 70 continues transmitting the deletion request until the vehicle 20 returns to online. This enables the management server 70 to transmit the deletion request when the vehicle 20 returns to online.

[0293] (9) When requested to delete the target digital key, if the deletion program PC is unable to communicate with both the vehicle 20 and the target device, it waits until communication becomes possible with at least one of the vehicle 20 and the target device, and then transmits the deletion request. This enables the deletion program PC to delete the target digital key even if both the vehicle 20 and the target device are offline at the timing when the deletion of the target digital key is requested.

[0294] (10) The deletion method is a method for deleting a target digital key, which is a digital key to be deleted from among a plurality of digital keys, in a management system 10 comprising a vehicle 20, a device 30, and a management server 70. The vehicle 20 stores information about a plurality of digital keys. The device 30 stores information about digital keys registered for the vehicle 20. The management server 70 manages the registration of digital keys. A digital key becomes controllable by the vehicle 20 when both the vehicle 20 and the device 30 store information about that digital key. The deletion method includes the step of the management server 70 deleting the information about the target digital key stored by the target device, which is the device 30 that stores information about the target digital key (steps S69, S99). The deletion method also includes the step of the management server 70 deleting the information about the target digital key stored by the vehicle 20, which is the vehicle 20 (steps S71, S101). The deletion method includes the step, if both the target device and the vehicle 20 are unable to communicate when the deletion request is sent, the management server 70 resends the deletion request for the target digital key when at least one of the target device and the vehicle 20 becomes able to communicate (deletion requests D81 and D82 in Figure 13 and D91 and D92 in Figure 17).

[0295] The deletion method, when a request is made to delete the target digital key, waits until communication becomes possible with at least one of the vehicle 20 or the target device before sending the deletion request. This allows the deletion method to delete the target digital key even if the vehicle 20 and the target device are offline at the time the request is made.

[0296] (Other embodiments) 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.

[0297] <Management System 10> 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 communication with device 30 if it has at least one of these modules. Furthermore, vehicle 20 is not limited to these modules, and may have any module that can perform short-range communication with device 30.

[0298] • The matters concerning the digital key in the above embodiment do not have to comply with CCC. The vehicle management device 26 is not limited to a digital key ECU. For example, it may be a central ECU that manages multiple ECUs in a vehicle 20.

[0299] The vehicle management device 26 may be configured as a circuit including one or more processors that execute various processes according to a computer program (software). Alternatively, the vehicle management device 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 execute 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 execute 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 device 30 and management server 70.

[0300] Device 30 is not limited to a smartphone. It may also be a smartwatch. Device 30 may also be a predetermined server. In this case, the predetermined server may contain Device 30. For example, if a rental company and a sharing company are the owners of the vehicle 20, the owner device 40 may be contained in the predetermined server. Also, for example, the friend device 51 may be contained in the predetermined server.

[0301] The share device 50 has the function of receiving the share key KS, as in the embodiment described above. A device 30 that has the function of receiving a digital key, like the share device 50, is sometimes called a receiver device.

[0302] In the above embodiment, the digital keys have a hierarchy in the order of owner key KO, friend key KF, and non-friend key KN, with higher levels of authority assigned to each key. However, the digital keys do not necessarily have to be configured so that higher levels of authority assign each key. For example, the same level of authority may be assigned to all three levels: owner key KO, friend key KF, and non-friend key KN.

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

[0304] 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.

[0305] The management server 70 does not need to store a database DB. The management server 70 only needs to manage the combination of the key information DK of the device 30 and the authentication information AT of the vehicle management device 26 for at least one digital key in the management system 10.

[0306] <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 a digital key when using the digital key. For example, the authentication information AT may be a common key shared between the vehicle management device 26 and the device 30. Alternatively, the authentication information AT may be a common secret key.

[0307] The structure of the information included in the key information DK is not limited to the examples of the above embodiment. For example, the owner key information DKO does not have to have the slot identification information ST4. Also, for example, the key information DK may have information indicating the type of digital key. The type of digital key is, for example, information indicating one of the owner key KO, friend key KF, and non-friend key KN.

[0308] The database DB may include information indicating the type of device 30. The type of device 30 is information indicating one of the following, for example, a smartphone, a smartwatch, and a predetermined server as in the modified example above.

[0309] The structure of the data DA in the database DB is not limited to the examples of the embodiments described above. The database DB only needs to contain the information necessary for the management server 70 to manage in the management system 10.

[0310] In a database (DB), privileges are not uniformly defined according to the type of digital key, but may be set for each digital key. Furthermore, privileges may not be defined at all in a database (DB).

[0311] The series of processes for registering the owner key KO is not limited to the examples of the above embodiment. For example, even if pairing is not performed by the process in step S12, the owner device 40 may store the owner key information DKO by having the vehicle 20 and the first device 30A send and receive information such as generated data DC via the management server 70. The series of processes for registering the owner key KO may be modified as appropriate to match the structure of the information contained in the owner key information DKO and the structure of the information contained in the authentication information AT.

[0312] The series of processes for registering the friend key KF is not limited to the examples of the above embodiment. For example, the management server 70 may update the database DB by the process in step S29 after sending the authentication package ATP and storage request D24 to the vehicle 20. The series of processes for registering the friend key KF may be modified as appropriate to match the structure of the information contained in the friend key information DKF and the structure of the information contained in the authentication information AT.

[0313] The series of processes for registering a non-friend key KN is not limited to the example of the embodiment described above. The order of the processes may differ from the series of processes for registering a friend key KF. The series of processes for registering a non-friend key KN may be modified as appropriate to match the structure of the information contained in the non-friend key information DKN and the structure of the information contained in the authentication information AT.

[0314] The types of digital keys do not necessarily include non-friend keys (KN). In other words, in the management system 10, the share key (KS) may consist only of friend keys (KF). Non-friend device 52 may send a request to register a new non-friend key KN. In other words, share device 50 may send a request to register a new non-friend key KN, regardless of whether it is friend device 51 or non-friend device 52. In this case, management system 10 can register the new non-friend key KN by the series of processes shown in Figure 7.

[0315] In the above embodiment, when the friend device 51 deletes a non-friend key KN, it sends a deletion reservation request D41 to the management server 70, requesting that the non-friend key KN be deleted when the specified condition RC is met. On the other hand, the friend device 51 may also send a request to the management server 70 to delete the non-friend key KN regardless of the specified condition RC. Furthermore, the management server 70 may proceed with processing from step S62 onward based not only on the friend device 51's request to delete the non-friend key KN, but also on the owner device 40's request.

[0316] In the above embodiment, when the owner device 40 deletes the friend key KF, it sends a deletion reservation request D61 to the management server 70, requesting that the friend key KF be deleted when the specified condition RC is met. On the other hand, the owner device 40 may also send a request to the management server 70 to delete the friend key KF regardless of the specified condition RC.

[0317] As shown in Figure 9, when deleting a non-friendly device 52 due to an operation of the non-friendly device 52, a request to delete the non-friendly key KN may be sent to the management server 70 before the completion notification M51 sent to the management server 70. In this case, similar to the sequence of events shown in Figure 8, when the management server 70 receives the request, the management server 70 may send a request to delete the non-friendly key information DKN to the non-friendly device 52.

[0318] As shown in Figure 11, when deleting the friend device 51 due to an operation of the friend device 51, a request to delete the friend key KF may be sent to the management server 70 before the completion notification M71 sent to the management server 70. In this case, similar to the sequence of events shown in Figure 10, when the management server 70 receives the request, the management server 70 may send a request to the friend device 51 to delete the friend key information DKF.

[0319] In both cases where a non-friend key KN is deleted due to an operation of friend device 51, and where a non-friend key KN is deleted due to an operation of non-friend device 52, a reservation for deletion may be requested from the management server 70.

[0320] The owner device 40 and the vehicle 20 may request the deletion of the non-friend key KN. Alternatively, for example, the management server 70 may generate a request to delete the non-friend key KN when certain conditions are met.

[0321] Vehicle 20 may request the deletion of Friend Key KF. Alternatively, for example, the management server 70 may generate a request to delete Friend Key KF when certain conditions are met. When Friend Device 51 requests the deletion of Non-Friend Key KN, Friend Device 51 sends a deletion reservation request D41 to Management Server 70, and Management Server 70 sends a deletion request to Vehicle 20 and Non-Friend Device 52. Friend Device 51 may also directly send a deletion request to Vehicle 20 and Non-Friend Device 52. In this case, if both Vehicle 20 and Non-Friend Device 52 are unable to communicate, Friend Device 51 repeatedly sends the deletion request.

[0322] When the owner device 40 requests the deletion of the friend key KF, the owner device 40 sends a deletion reservation request D61 to the management server 70, and the management server 70 sends a deletion request to the vehicle 20 and the friend device 51. The owner device 40 may also send the deletion request directly to the vehicle 20 and the friend device 51. In this case, if both the vehicle 20 and the friend device 51 are unable to communicate, the owner device 40 repeatedly sends the deletion request.

[0323] In Figure 14, if the period between the initial transmission of a deletion request and the receipt of the deletion request by the non-friend device 52 is longer than the fade-out period, the non-friend device 52 will delete the non-friend key information DKN without waiting for the fade-out period to elapse. Even if the period between the initial transmission of a deletion request and the receipt of the deletion request is longer than the fade-out period, the non-friend device 52 may wait for the fade-out period to elapse after receiving the deletion request before deleting the non-friend key information DKN.

[0324] In Figure 18, if the period between the initial deletion request being sent and the friend device 51 receiving the deletion request is longer than the fade-out period, the friend device 51 will delete the friend key information DKF without waiting for the fade-out period to elapse. Even if the period between the initial deletion request being sent and the friend device 51 receiving the deletion request is longer than the fade-out period, the friend device 51 may wait for the fade-out period to elapse after receiving the deletion request before deleting the friend key information DKF.

[0325] In Figure 15, if the period between the initial transmission of a deletion request and the vehicle 20 receiving the deletion request is longer than the fade-out period, the vehicle 20 will delete the authentication information AT without waiting for the fade-out period to elapse. On the other hand, even if the period between the initial transmission of a deletion request and the vehicle 20 receiving the deletion request is longer than the fade-out period, the vehicle 20 may wait for the fade-out period to elapse after receiving the deletion request before deleting the authentication information AT.

[0326] In Figure 14, the non-friend device 52 deletes the non-friend key information DKN after waiting for the engine to stop if the owner of the non-friend key KN is using the vehicle 20. The non-friend device 52 may delete the non-friend key information DKN without waiting for the engine to stop, even if the owner of the non-friend key KN is using the vehicle 20.

[0327] In Figure 18, if the owner of the friend key KF is using the vehicle 20, the friend device 51 waits for the engine to stop before deleting the friend key information DKF. The friend device 51 may delete the friend key information DKF without waiting for the engine to stop, even if the owner of the friend key KF is using the vehicle 20.

[0328] In Figure 15, if the owner of the target digital key is using the vehicle 20, the vehicle 20 waits for the engine to stop before deleting the authentication information AT for the target digital key. The vehicle 20 may delete the authentication information AT for the target digital key without waiting for the engine to stop, even if the owner of the target digital key is using the vehicle 20.

[0329] In Figures 8 and 13, the non-friendly device 52 sends a response notification when it receives a deletion request. The non-friendly device 52 does not have to send a response notification. In this case, in Figure 12, the management server 70 determines that the non-friendly device 52 is in a state where communication is impossible if it does not receive a completion notification M44 after a certain period of time has elapsed since sending the deletion request D42. Also, in Figure 13, the management server 70 stops sending the deletion request D81 when it receives the completion notification M82.

[0330] In Figures 10 and 17, the friend device 51 sends a response notification when it receives a delete request. The friend device 51 does not have to send a response notification. In this case, in Figure 16, the management server 70 determines that the friend device 51 is in a state where communication is impossible if it does not receive a completion notification M64 after a certain period of time has elapsed since sending the delete request D62. Also, in Figure 17, the management server 70 stops sending the delete request D91 when it receives the completion notification M92.

[0331] In Figures 8, 10, 13, and 17, vehicle 20 sends a response notification when it receives a deletion request. Vehicle 20 does not have to send a response notification. In this case, as shown in Figure 12, the management server 70 determines that the vehicle 20 is in a state where communication is impossible if it does not receive a completion notification M45 even after a certain period of time has elapsed since sending the deletion request D43. Also, as shown in Figure 13, the management server 70 stops sending the deletion request D82 when it receives the completion notification M84.

[0332] In this case, as shown in Figure 16, the management server 70 determines that the vehicle 20 is in a state where communication is impossible if it does not receive a completion notification M65 even after a certain period of time has elapsed since sending the deletion request D63. Also, as shown in Figure 17, the management server 70 stops sending the deletion request D92 when it receives the completion notification M94.

[0333] In the above embodiment, the management server 70 repeatedly sends deletion requests to the vehicle 20 and the target device when the vehicle 20 and the target device are unable to communicate. The manner in which the management server 70 sends deletion requests when the vehicle 20 and the target device are unable to communicate is not limited to the above embodiment.

[0334] Figure 19 shows an example of a series of processes executed by the management system 10 in the modified management system 10 after the management server 70 detects that both the vehicle 20 and the non-friend device 52 are unable to communicate. In Figure 19, the friend device 51 requests the deletion of the non-friend key KN. After executing the series of processes shown in Figure 12, the modified management system 10 executes the series of processes shown in Figure 19 instead of the series of processes shown in Figure 13. In the following description, 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 36 will be described as processes executed by the device 30, and the processes executed by the execution device 71 will be described as processes executed by the management server 70. Also, in the following description, the processes executed by the management server 70 are executed by the deletion program PC, which causes the execution device 71 to execute them.

[0335] In Figure 19, the non-friendly device 52 returns to a communicative state before the vehicle 20. The non-friendly device 52, having returned to a communicative state, sends a return notification M101 to the management server 70. The return notification M101 indicates that the non-friendly device 52 has returned to a communicative state from a non-communicative state.

[0336] Upon receiving the recovery notification M101, the management server 70 executes the process in step S191. In step S191, the management server 70 generates a deletion request D101. Deletion request D101 is a request that adds information to the deletion request D42 in Figure 12, indicating that the request was sent again because the non-friendly device 52 was in a state where communication was impossible. Deletion request D101 includes information indicating the time when deletion request D42 was sent in Figure 12. Subsequently, the management server 70 sends the generated deletion request D191 to the non-friendly device 52.

[0337] Upon receiving the deletion request D101, the non-friendly device 52 executes the process in step S192. In step S192, the non-friendly device 52 performs the recovery deletion process in the manner shown in Figure 14. Subsequently, the non-friendly device 52 sends a deletion completion notification M102 to the management server 70 indicating that the deletion in accordance with the deletion request D101 has been completed.

[0338] When the management server 70 receives a completion notification M102 from the non-friendly device 52, the management server 70 performs the process in step S193. In step S193, the management server 70 stores the history of the deletion of the non-friendly key information DKN in the non-friendly device 52. This process is the same as the process in step S72 in Figure 8.

[0339] In Figure 19, vehicle 20 returns to a communicative state after the non-friendly device 52 returns to a communicative state. Vehicle 20, having returned to a communicative state, sends a return notification M103 to the management server 70. The return notification M103 indicates that vehicle 20 has returned from a non-communicative state to a communicative state.

[0340] Upon receiving the recovery notification M103, the management server 70 executes the process in step S194. In step S194, the management server 70 generates a deletion request D102. Deletion request D102 is a request that adds information to the deletion request D43 in Figure 12, indicating that the request was sent again because the vehicle 20 was in a state where communication was impossible. Deletion request D102 includes information indicating the time when deletion request D43 was sent in Figure 12.

[0341] Upon receiving the deletion request D103, vehicle 20 executes the process in step S195. In step S195, vehicle 20 executes the recovery deletion process in the manner shown in Figure 15. Subsequently, vehicle 20 sends a deletion completion notification M104 to the management server 70 indicating that the deletion in accordance with the deletion request D102 has been completed.

[0342] When the management server 70 receives a completion notification M104 from the vehicle 20, the management server 70 performs the process in step S196. In step S196, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the non-friend key KN that is to be deleted in this series of deletion processes in the vehicle 20. This process is the same as the process in step S73 in Figure 8.

[0343] After executing the processes in step S193 and step S196, the management server 70 executes the process in step S197. In step S197, the management server 70 updates the database DB. This process is the same as the process executed by the management server 70 in step S74 in Figure 8. Subsequently, the management server 70 sends a deletion completion notification M105 to the friend device 51, indicating that it has completed the deletion of a series of non-friend keys KN in accordance with the deletion reservation request D41.

[0344] Subsequently, when the friend device 51 receives the completion notification M105, the friend device 51 performs the process in step S198. In step S198, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key KN, which is the target of the deletion reservation request D41, has been completed. This process is the same as the process performed by the friend device 51 in step S75 of Figure 8. After that, the management system 10 completes the series of processes for the deletion of the non-friend key KN.

[0345] In Figure 19, the non-friendly device 52 returns to a communicative state before the vehicle 20. On the other hand, it is also possible that the vehicle 20 returns to a communicative state before the non-friendly device 52. In this case, the order in which the management server 70 executes the processes in step S193 and step S196 may be reversed.

[0346] Figure 20 shows an example of a series of processes executed by the management system 10 in the modified management system 10 after the management server 70 detects that both the vehicle 20 and the friend device 51 are unable to communicate. In Figure 20, the owner device 40 is requested to delete the friend key KF. The modified management system 10 executes the series of processes shown in Figure 16, and then executes the series of processes shown in Figure 20 instead of the series of processes shown in Figure 17. In the following description, 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 36 will be described as processes executed by the device 30, and the processes executed by the execution device 71 will be described as processes executed by the management server 70. Also, in the following description, the processes executed by the management server 70 are executed by the deletion program PC, which causes the execution device 71 to execute them.

[0347] In Figure 20, the friend device 51 returns to a communicable state before the vehicle 20. The friend device 51, having returned to a communicable state, sends a return notification M111 to the management server 70. The return notification M111 indicates that the friend device 51 has returned to a communicable state from a state where it could not communicate.

[0348] Upon receiving the recovery notification M111, the management server 70 executes the process in step S201. In step S201, the management server 70 generates a deletion request D111. Deletion request D111 is a request that adds information to the deletion request D62 in Figure 16, indicating that the request was sent again because the friend device 51 was in a state where communication was impossible. Deletion request D111 includes information indicating the time when deletion request D62 was sent in Figure 16. Subsequently, the management server 70 sends the generated deletion request D111 to the friend device 51.

[0349] Upon receiving the deletion request D111, the friend device 51 executes the process in step S202. In step S202, the friend device 51 executes the recovery deletion process in the manner shown in Figure 18. Subsequently, the friend device 51 sends a deletion completion notification M112 to the management server 70 indicating that the deletion in accordance with the deletion request D111 has been completed.

[0350] When the management server 70 receives a completion notification M102 from the friend device 51, the management server 70 performs the process in step S203. In step S203, the management server 70 stores the history of the deletion of the friend key information DKF on the friend device 51. This process is the same as the process in step S102 in Figure 10.

[0351] In Figure 20, vehicle 20 returns to a communicative state after the friend device 51 returns to a communicative state. Vehicle 20, having returned to a communicative state, sends a return notification M113 to the management server 70. The return notification M113 indicates that vehicle 20 has returned to a communicative state from a state where it could not communicate.

[0352] Upon receiving the recovery notification M113, the management server 70 executes the process in step S204. In step S204, the management server 70 generates a deletion request D112. Deletion request D112 is a request that adds information to the deletion request D63 in Figure 16, indicating that the request was sent again because the vehicle 20 was in a state where communication was impossible. Deletion request D112 includes information indicating the time when deletion request D63 was sent in Figure 16. Subsequently, the management server 70 sends the generated deletion request D112 to the vehicle 20.

[0353] Upon receiving the deletion request D112, vehicle 20 executes the process in step S205. In step S205, vehicle 20 executes the recovery deletion process in the manner shown in Figure 15. Subsequently, vehicle 20 sends a deletion completion notification M114 to the management server 70 indicating that the deletion in accordance with the deletion request D112 has been completed.

[0354] When the management server 70 receives the completion notification M114 from the vehicle 20, the management server 70 performs the process in step S206. In step S206, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the friend key KF that is to be deleted in this series of deletion processes in the vehicle 20. This process is the same as the process in step S103 in Figure 10.

[0355] After performing the processes in step S203 and step S206, the management server 70 performs the process in step S207. In step S207, the management server 70 updates the database DB. This process is the same as the process performed by the management server 70 in step S104 in Figure 10. Subsequently, the management server 70 sends a deletion completion notification M115 to the owner device 40, indicating that it has completed the series of deletions of friend key KF in accordance with the deletion reservation request D61.

[0356] Subsequently, when the owner device 40 receives the completion notification M115, the owner device 40 performs the process in step S208. In step S208, the owner device 40 presents information to the HMI 32 indicating that the deletion of friend key KF, which is the target of the deletion reservation request D61, has been completed. This process is the same as the process performed by the owner device 40 in step S105 of Figure 10. After that, the management system 10 completes the series of processes for the deletion of friend key KF.

[0357] In Figure 20, the friend device 51 returns to a communicable state before the vehicle 20. On the other hand, it is also possible that the vehicle 20 returns to a communicable state before the friend device 51. In this case, the order in which the management server 70 executes the processes in step S203 and step S206 may be reversed.

[0358] In this case, when the target device returns from a state where it could not communicate to a state where it could communicate, it sends a recovery notification indicating that it has returned to a state where it could communicate. When the target device sends the recovery notification, the management system 10 sends a deletion request to the target device.

[0359] When the management system 10 receives a recovery notification from the target device indicating that it has become able to communicate again, it sends a deletion request to the target device again. This allows the management system 10 to send a deletion request when the target device returns to a state where it can communicate again.

[0360] In this case, when vehicle 20 returns to a state where it can communicate after being unable to communicate, it sends a recovery notification indicating that it has returned to a state where it can communicate. When vehicle 20 sends the recovery notification, management system 10 sends a deletion request to vehicle 20.

[0361] When the management system 10 receives a recovery notification from the vehicle 20 indicating that it has become communicable, it sends another deletion request to the vehicle 20. This allows the management system 10 to send a deletion request when the vehicle 20 returns to a communicable state.

[0362] In this case, when the target device returns to a state where it can communicate after being unable to communicate, it sends a recovery notification indicating that it has returned to a state where it can communicate. When the management server 70 receives the recovery notification from the target device, it sends a deletion request to the target device.

[0363] When the management server 70 receives a recovery notification from the target device indicating that it has become communicable, it sends another deletion request to the target device. This allows the management server 70 to send a deletion request when the target device returns to a communicable state.

[0364] When vehicle 20 returns to a state where it can communicate after being unable to communicate, it sends a recovery notification indicating that it has returned to a state where it can communicate. When the management server 70 receives the recovery notification from vehicle 20, it sends a deletion request to vehicle 20.

[0365] When the management server 70 receives a recovery notification from the vehicle 20 indicating that it has become able to communicate, it sends another deletion request to the vehicle 20. This allows the management server 70 to send a deletion request when the vehicle 20 returns to a state where it can communicate.

[0366] In Figure 19, instead of the management server 70, the friend device 51 may receive the return notification M101 from the non-friend device 52. In this case, the friend device 51 generates a deletion request D101 and sends it to the non-friend device 52.

[0367] In Figure 19, the friend device 51 may receive the return notification M103 from the vehicle 20 instead of the management server 70. In this case, the friend device 51 generates a deletion request D102 and sends it to the vehicle 20.

[0368] In Figure 20, the owner device 40 may receive the return notification M111 from the friend device 51, rather than the management server 70. In this case, the owner device 40 generates a delete request D111 and sends it to the friend device 51.

[0369] In Figure 20, the owner device 40 may receive the return notification M113 from the vehicle 20 instead of the management server 70. In this case, the owner device 40 generates a deletion request D112 and sends it to the vehicle 20.

[0370] The management server 70 may repeatedly send a deletion request to the vehicle 20 when the vehicle 20 and the target device are unable to communicate, and may also send a deletion request to the target device when it receives a recovery notification from the target device.

[0371] [Note] The technical concepts that can be understood from the above embodiments and modified examples are described below. [Note 1] A management system comprising a vehicle that stores information about multiple digital keys, a device that stores information about the digital keys registered for the vehicle, and a management server that manages the registration of the digital keys, wherein the vehicle becomes controllable when both the vehicle and the device store information about the digital key, and when a request is made to delete a target digital key which is one of the multiple digital keys that is to be deleted, the management system sends a deletion request to the target device which is the device that stores information about the target digital key, thereby deleting the information about the target digital key stored by the target device, and sends the deletion request to the vehicle, thereby deleting the information about the target digital key stored by the vehicle, and when both the target device and the vehicle are unable to communicate when the deletion request is sent, the management system resends the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate.

[0372] [Note 2] The management system according to Note 1, which, when the deletion request is sent, repeatedly sends the deletion request to the target device until the target device becomes able to communicate, if both the target device and the vehicle are in a state where communication is impossible.

[0373] [Note 3] The management system according to Note 1 or Note 2, which, when the deletion request is sent, repeatedly sends the deletion request to the vehicle until the vehicle becomes able to communicate, if both the target device and the vehicle are in a state where communication is impossible.

[0374] [Note 4] The management system described in any one of Notes 1 to 3, wherein when the target device changes from a state where it is unable to communicate to a state where it is able to communicate, it sends a recovery notification indicating that it has become able to communicate, and when the target device sends the recovery notification, it sends the deletion request to the target device.

[0375] [Note 5] The management system described in any one of Notes 1 to 4, wherein the vehicle transmits a recovery notification indicating that it has become able to communicate when it has gone from being unable to communicate to being able to communicate, and transmits the deletion request to the vehicle when the vehicle transmits the recovery notification.

[0376] [Note 6] The management system described in any one of Notes 1 to 5 wherein the vehicle and the target device delete the information about the target digital key they store after a fade-out period has elapsed following the receipt of the deletion request, and when the vehicle becomes able to communicate after being unable to communicate, if the period from when the deletion request was first sent until the vehicle receives the deletion request is longer than the fade-out period, the vehicle deletes the information about the target digital key it stores after receiving the deletion request, regardless of whether the fade-out period has elapsed or not.

[0377] [Note 7] The management system described in Note 6, wherein when the vehicle and the target device receive the deletion request after becoming able to communicate from a state where communication was impossible, even if the period from when the deletion request was first sent until the vehicle receives the deletion request is longer than the fade-out period, if the owner of the target digital key is using the vehicle, the vehicle will not delete the information it stores about the target digital key until the vehicle's engine stops running.

[0378] [Note 8] A management system comprising a vehicle that stores information about multiple digital keys, and a device that stores information about the digital keys registered for the vehicle, wherein the management server manages the registration of the digital keys, and the digital key becomes controllable when both the vehicle and the device store information about the digital key, and when a request is made to delete a target digital key which is one of the multiple digital keys that is to be deleted, the management server sends a deletion request to the target device which is the device that stores information about the target digital key, thereby deleting the information about the target digital key stored by the target device, and sends the deletion request to the vehicle, thereby deleting the information about the target digital key stored by the vehicle, and if both the target device and the vehicle are unable to communicate when the deletion request is sent, the management server resends the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate.

[0379] [Note 9] If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the management server described in Note 8 repeatedly sends the deletion request to the target device until the target device becomes able to communicate.

[0380] [Note 10] If, when the deletion request is sent, both the target device and the vehicle are in a state where communication is impossible, the management server described in Note 8 or Note 9 repeatedly sends the deletion request to the vehicle until the vehicle becomes able to communicate.

[0381] [Note 11] The management server described in any one of Notes 8 to 10 sends a recovery notification indicating that the target device has become able to communicate when it has gone from being unable to communicate to being able to communicate, and when it receives the recovery notification from the target device, it sends the deletion request to the target device.

[0382] [Note 12] The vehicle sends a recovery notification indicating that it has become able to communicate when it has gone from being unable to communicate to being able to communicate, and the management server described in any one of Notes 8 to 11 sends the deletion request to the vehicle when it receives the recovery notification from the vehicle. [Explanation of symbols]

[0383] 10…Management System 20... Vehicles 26... Vehicle management system 27… Execution device 28…Storage device 29…Display section 30…Device 36…Execution device 37…Storage device 40… Owner devices 50… Shared devices 51... Friend Device 52... Non-Friendly Devices 60…Device Server 70... Management Server AT... Authentication information DK...Key Information DKO... Owner Key Information DKS... Share Key Information KF...Friend Key KN... Non-Friend Key KO... Owner Key KS... Share Key PC...delete program

Claims

1. A vehicle that stores information about multiple digital keys, A device that stores information regarding the digital key registered for the said vehicle, A management server that manages the registration of the aforementioned digital key, It is a management system equipped with, The digital key becomes controllable when both the vehicle and the device store information related to the digital key. When a request is made to delete a target digital key, which is one of the multiple digital keys that is to be deleted, By sending a deletion request to the target device, which is the device that stores information about the target digital key, the information about the target digital key stored in the target device is deleted. By transmitting the deletion request to the vehicle, the information regarding the target digital key stored in the vehicle is deleted. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion request for the target digital key will be resent when at least one of the target device and the vehicle becomes able to communicate. Management system.

2. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion request will be repeatedly sent to the target device until the target device becomes able to communicate. The management system according to claim 1.

3. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion request will be repeatedly sent to the vehicle until the vehicle becomes able to communicate. The management system according to claim 1.

4. When the aforementioned target device changes from a state where it cannot communicate to a state where it can communicate, it sends a recovery notification indicating that it has become able to communicate. When the target device sends the recovery notification, the delete request is sent to the target device. The management system according to claim 1.

5. When the vehicle changes from a state where communication is impossible to a state where communication is possible, it sends a recovery notification indicating that it has become possible to communicate. When the vehicle sends the return notification, the delete request is sent to the vehicle. The management system according to claim 1.

6. The aforementioned vehicle and the aforementioned target device are, After receiving the aforementioned deletion request, the system deletes the information it has stored regarding the target digital key after the fade-out period has elapsed. When the system receives the deletion request after transitioning from a communication-unavailable state to a communication-enabled state, if the period between the initial transmission of the deletion request and the system receiving the deletion request is longer than the fade-out period, the system will delete the information regarding the target digital key that it has stored, regardless of whether the fade-out period has elapsed after receiving the deletion request. A management system according to any one of claims 1 to 5.

7. The aforementioned vehicle and the aforementioned target device are, When the deletion request is received after the system has transitioned from a communication-disabled state to a communication-enabled state, even if the period between the initial transmission of the deletion request and the system receiving the deletion request is longer than the fade-out period, if the owner of the target digital key is using the vehicle, the system will not delete the information it stores about the target digital key until the vehicle's engine stops running. The management system according to claim 6.

8. A vehicle that stores information about multiple digital keys, A device that stores information regarding the digital key registered for the said vehicle, In a management system comprising the above, the management server manages the registration of the digital key, The digital key becomes controllable when both the vehicle and the device store information related to the digital key. When a request is made to delete a target digital key, which is one of the multiple digital keys that is to be deleted, By sending a deletion request to the target device, which is the device that stores information about the target digital key, the information about the target digital key stored in the target device is deleted. By transmitting the deletion request to the vehicle, the information regarding the target digital key stored in the vehicle is deleted. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion request for the target digital key will be resent when at least one of the target device and the vehicle becomes able to communicate. Management server.

9. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion request will be repeatedly sent to the target device until the target device becomes able to communicate. The management server according to claim 8.

10. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the deletion request will be repeatedly sent to the vehicle until the vehicle becomes able to communicate. The management server according to claim 8.

11. The aforementioned target device sends a recovery notification indicating that it has become able to communicate when it changes from an uncommunicable state to a communicable state. When the recovery notification is received from the target device, the delete request is sent to the target device. The management server according to claim 8.

12. The aforementioned vehicle sends a recovery notification indicating that it has become able to communicate when it returns to a state where it is able to communicate. When the return notification is received from the vehicle, the deletion request is sent to the vehicle. The management server according to claim 8.

13. A vehicle that stores information about multiple digital keys, A device that stores information regarding the digital key registered for the said vehicle, The system includes a management server that manages the registration of the aforementioned digital keys, The digital key is a deletion program that controls the management server in a management system where the vehicle becomes controllable when both the vehicle and the device store information related to the digital key. When a request is made to delete a target digital key, which is one of the multiple digital keys to be deleted, a deletion request is sent to the target device, which is the device that stores information about the target digital key, thereby deleting the information about the target digital key stored in the target device. When a request is made to delete the target digital key, the vehicle is deleted by sending the deletion request to the vehicle, thereby deleting the information about the target digital key stored in the vehicle. If, when the deletion request is sent, both the target device and the vehicle are unable to communicate, the management server will be instructed to resend the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate. Deletion program.

14. A vehicle that stores information about multiple digital keys, A device that stores information regarding the digital key registered for the said vehicle, The system includes a management server that manages the registration of the aforementioned digital keys, The aforementioned digital key is a deletion method for deleting a target digital key, which is the digital key to be deleted, from among a plurality of digital keys, in a management system in which the vehicle becomes controllable when both the vehicle and the device store information about the digital key. The management server sends a deletion request to the target device, which is the device that stores information about the target digital key, thereby deleting the information about the target digital key stored by the target device. The management server sends the deletion request to the vehicle, thereby deleting the information regarding the target digital key stored in the vehicle. The process includes: if both the target device and the vehicle are unable to communicate when the deletion request is sent, the management server resends the deletion request for the target digital key when at least one of the target device and the vehicle becomes able to communicate. How to delete.

Images