Management system, vehicle management device, deletion management method, and program

Abstract

This system provides a management system that prevents the targeted digital key from being continuously deleted. [Solution] The management system deletes the target digital key from among multiple digital keys for the vehicle 20 when a specified condition is met. The management system does not delete the target digital key if a cancellation request to cancel the deletion of the target digital key is received from a device that has registered a digital key different from the target digital key during the specified period, and deletes the target digital key if no cancellation request is received from a device that has registered a digital key different from the target digital key during the specified period.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a management system, a vehicle management device, a deletion management method, and a program. BACKGROUND ART

[0002] Patent Document 1 describes a digital key management system. The management system manages a plurality of digital keys. Each digital key is registered to each of a plurality of devices. PRIOR ART DOCUMENT PATENT DOCUMENT

[0003] Patent Document 1 Japanese Unexamined Patent Application Publication No. 2024-001720 SUMMARY OF THE INVENTION PROBLEM TO BE SOLVED BY THE INVENTION

[0004] A management system such as that described in Patent Document 1 sometimes deletes a target digital key when a prescribed condition is satisfied. In order to cancel the deletion, if a cancellation request for canceling the deletion of the target digital key is received from a device in the management system, it is conceivable that the target digital key will not be deleted.

[0005] However, when a cancellation request is received from the device in which the target digital key is registered, if the management system does not delete the target digital key, there is a risk that the target digital key will remain undeleted. MEANS FOR SOLVING THE PROBLEM

[0006] A management system that solves the above problem is a management system that deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and if a cancellation request to cancel the deletion of the target digital key is received from a device that has a different digital key registered to it during a predetermined period, the target digital key is not deleted, and if no such cancellation request is received from a device that has a different digital key registered to it during the predetermined period, the target digital key is deleted.

[0007] A vehicle management device that solves the above problems is installed in a vehicle that can use multiple digital keys for the vehicle, and deletes a target digital key from among the multiple digital keys for the vehicle when predetermined conditions are met, wherein if a cancellation request to cancel the deletion of the target digital key is received from a device that has registered a digital key different from the target digital key during a predetermined period, the target digital key is not deleted, and if no such cancellation request is received from a device that has registered a digital key different from the target digital key during the predetermined period, the target digital key is deleted.

[0008] A deletion management method that solves the above problem is a deletion management method performed by a management system including a computer for deleting a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, wherein if a cancellation request to cancel the deletion of the target digital key is received from a device registered with a digital key different from the target digital key during a predetermined period, the target digital key is not deleted, and if no such cancellation request is received from a device registered with a digital key different from the target digital key during the predetermined period, the target digital key is deleted.

[0009] A program to solve the above problem is a program to be executed by a computer to delete a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, wherein the computer is instructed not to delete the target digital key if a cancellation request to cancel the deletion of the target digital key is received from a device that has a different digital key registered to it during a predetermined period, and to delete the target digital key if no such cancellation request is received from a device that has a different digital key registered to it during the predetermined period. [Effects of the Invention]

[0010] The above-mentioned management system, vehicle management device, deletion management method, and program can prevent the target digital key from being continuously deleted when a cancellation request is made. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a schematic diagram showing the management system of the first embodiment. [Figure 2] Figure 2 is a schematic diagram showing the owner key information of the first embodiment. [Figure 3] Figure 3 is a schematic diagram showing the share key information of the first embodiment. [Figure 4] Figure 4 is a schematic diagram showing the data in the database of the first embodiment. [Figure 5] Figure 5 is an explanatory diagram showing a series of processes performed by the management system when an owner key is registered in the first embodiment. [Figure 6] Figure 6 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in the first embodiment. [Figure 7] Figure 7 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in the first embodiment. [Figure 8]FIG. 8 is an explanatory diagram showing a series of deletion management processes performed by the management system according to the first embodiment. [Figure 9] FIG. 9 is a flowchart showing a series of processes for transmitting a cancel request performed by the device according to the first embodiment. [Figure 10] FIG. 10 is a flowchart showing detailed processing in the deletion request acceptance determination performed by the vehicle management apparatus according to the first embodiment. [Figure 11] FIG. 11 is a flowchart showing a series of processes in the transmission permission determination of an establishment notification performed by the vehicle management apparatus according to the second embodiment. [Figure 12] FIG. 12 is a flowchart showing a series of processes including permitting the generation of a deletion request performed by the management server according to the third embodiment. [Figure 13] FIG. 13 is an explanatory diagram showing a series of deletion management processes performed by the management system according to the fourth embodiment. [Figure 14] FIG. 14 is a flowchart showing a series of processes including permitting the deletion of authentication information performed by the vehicle management apparatus according to the fourth embodiment. DESCRIPTION OF EMBODIMENTS

[0012] <First Embodiment> Hereinafter, the management system 10 according to the first embodiment will be described with reference to the drawings. <Outline of Management System> As shown in FIG. 1, the management system 10 manages a plurality of digital keys available for a vehicle 20. For digital keys, there is a standard from the Car Connectivity Consortium (CCC). Matters concerning the digital key in the present embodiment are assumed to comply with the CCC, but the present invention is also applicable to standards and systems other than the CCC. The management system 10 includes the vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

[0013] A 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 is an abbreviation for Human Machine Interface. BLE is an abbreviation for Bluetooth Low Energy. UWB is an abbreviation for Ultra Wide Band. NFC is an abbreviation for Near Field Communication.

[0014] The communication module 21 communicates with a management server 70 via a wireless communication line. The HMI 22 includes an input device and a presentation device. The input device receives an operation from a user of the vehicle 20, and inputs a signal indicating the operation to the vehicle 20. The presentation device presents information to the user via images, sound, and the like. The presentation device is, for example, a monitor and a speaker.

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

[0016] The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages a plurality of digital keys for the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 includes an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. When executed by the execution device 27, the vehicle program PV causes the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating a digital key to enable control of the vehicle 20 by the digital key when the digital key is used. The authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU, that is, a processing circuit. The execution device 27 executes processing related to storage and deletion of the authentication information AT by executing the vehicle program PV.

[0017] When the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be controlled by the digital key. For example, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be unlocked. Alternatively, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be started.

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

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

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

[0021] 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. The execution device 36 is a CPU, or processing circuit.

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

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

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

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

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

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

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

[0029] 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 described later. Non-friend key KN is a share key KS registered based on a registration request D31 from friend device 51, as described later. In other words, non-friend key KN is a share key KS registered based on a registration request from share device 50, which is a device 30 different from owner device 40.

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

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

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

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

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

[0035] 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 of device 30 communicates with is different from the device server 60 that a second type of 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.

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

[0037] <Management Server> The management server 70 manages multiple 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 execution unit 71 is a CPU, i.e., a processing circuit. 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.

[0038] The storage device 72 stores the server program PS 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.

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

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

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

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

[0043] This section describes a state in which a digital key is registered for 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 for each of Devices 1 30A to Device 7 30G are referred to as Digital Key 1 DK1 to Digital Key 7 DK7.

[0044] 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 owner device 40. In other words, the first digital key DK1 is owner key KO.

[0045] 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 Share Devices 50. That is, the second digital key DK2 to the seventh digital key DK7 are all Share Key KS.

[0046] 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 third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are Non-Friend Devices 52.

[0047] In the 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 DK2 is registered based on the first digital key DK1. Therefore, the first device 30A is involved in the registration of the second digital key DK2. On the other hand, the third devices 30C to the seventh devices 30G are not involved in the registration of the second digital key DK2.

[0048] 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 DK5 is registered based on the first digital key DK1. Therefore, the first device 30A is involved in the registration of the fifth digital key DK5. On the other hand, the second devices 30B to the fourth devices 30D, the sixth device 30F, and the seventh device 30G are not involved in the registration of the fifth digital key DK5.

[0049] 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 DK3 is registered based on the second digital key DK2. Therefore, the first device 30A and the second device 30B are involved in the registration of the third digital key DK3. On the other hand, the fourth device 30D to the seventh device 30G are not involved in the registration of the third digital key DK3.

[0050] 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 DK4 is registered based on the second digital key DK2. Therefore, the first device 30A and the second device 30B are involved in the registration of the fourth digital key DK4. On the other hand, the third device 30C and the fifth devices 30E to the seventh devices 30G are not involved in the registration of the fourth digital key DK4.

[0051] In the data DA, the relationship between the 6th device 30F and the 5th device 30E is such that the non-friendly key KN is registered in the 6th device 30F based on a registration request from the 5th device 30E. In other words, the 6th digital key DK6 is registered based on the 5th digital key DK5. Therefore, the 1st device 30A and the 5th device 30E are involved in the registration of the 6th digital key DK6. On the other hand, the 2nd devices 30B to the 4th devices 30D and the 7th device 30G are not involved in the registration of the 6th digital key DK6.

[0052] In the 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 due to a registration request from the 5th device 30E. In other words, the 7th digital key DK7 is registered based on the 5th digital key DK5. Therefore, the 1st device 30A and the 5th device 30E are involved in the registration of the 7th digital key DK7. On the other hand, the 2nd devices 30B to the 4th devices 30D and the 6th device 30F are not involved in the registration of the 6th digital key DK6.

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

[0054] Device 30 can generate a reservation deletion request D41, described later, for the digital key involved in registration among multiple digital keys. The reservation deletion request D41 is a reservation deletion request that requests deletion when the specified condition RC is met.

[0055] For example, the first device 30A is involved in the registration of the second digital key DK2 to the seventh digital key DK7. Therefore, the first device 30A can generate reservation deletion requests D41 for the second digital key DK2 to the seventh digital key DK7. On the other hand, the first device 30A cannot generate a reservation deletion request D41 for the first digital key DK1.

[0056] The second device 30B is involved in the registration of the third digital key DK3 and the fourth digital key DK4. Therefore, the second device 30B can generate reservation deletion requests D41 for the third digital key DK3 and the fourth digital key DK4. On the other hand, the second device 30B is not involved in the registration of the first digital key DK1, the second digital key DK2, and the fifth digital key DK5 to the seventh digital key DK7. Therefore, the second device 30B cannot generate reservation deletion requests D41 for the first digital key DK1, the second digital key DK2, and the fifth digital key DK5 to the seventh digital key DK7.

[0057] <Digital Key Registration> Next, we will describe the series of registration 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 steps 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.

[0058] <Owner Key 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.

[0059] The management system 10 stores key information DK, which indicates the owner key KO, in the first device 30A upon registration of the owner key KO. The management system 10 also stores authentication information AT, which authenticates the owner key KO, in the vehicle 20 upon registration of the owner key KO. 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.

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

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

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

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

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

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

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

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

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

[0069] <Registering a Friend Key> As shown in Figure 6, the management system 10 performs a series of registration 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.

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

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

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

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

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

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

[0076] 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 operation performed. After that, the owner device 40 proceeds to step S26.

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

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

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

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

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

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

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

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

[0085] 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 presents an image indicating the registration of the friend key KF to the HMI 32. For example, the second device 30B displays an image indicating the registration of the friend key KF to the HMI 32. With this, the management system 10 completes the series of processes for registering the friend key KF.

[0086] <Registering a non-friend key> As shown in Figure 7, the management system 10 performs a series of registration processes to register the non-friendly key KN. Among 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.

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

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

[0089] 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 second device 30B downloads the share information SH2 from the URL link.

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

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

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

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

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

[0095] 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 S47.

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

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

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

[0099] 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 a 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 second device 30B.

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

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

[0102] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M33 to the second device 30B. Subsequently, when the second device 30B 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 on the HMI 32 indicating the completion of registration of the non-friendly key KN. With this, the management system 10 completes the series of processes for registering the non-friendly key KN.

[0103] <Deletion Management> Next, we will describe the deletion management for deleting the target digital key in the management system 10.

[0104] In this embodiment, the target digital key is the third digital key DK3 of the non-friend key KN. Therefore, a series of processes related to deletion management for deleting the third digital key DK3 will be described.

[0105] The following describes the sequence of events from the state in which the third digital key DK3 is registered to the state in which the third digital key DK3 is not registered. 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.

[0106] As shown in Figure 8, the management system 10 performs a series of processes when performing deletion management to delete the third digital key DK3 based on the reservation deletion request D41 from the first device 30A.

[0107] When an operation requesting the deletion of the third digital key DK3 is performed in the first device 30A, the first device 30A first performs the process in step S61. In step S61, a reserved deletion request D41 for the third digital key DK3 is generated. The reserved deletion request D41 is a request to delete the target digital key when a predetermined specified condition RC is met.

[0108] The reservation deletion request D41 includes a signal requesting the deletion of the third digital key DK3, digital key identification information ST3 indicating the third digital key DK3, and information indicating the predetermined condition RC. The predetermined condition RC is the condition necessary to delete the target digital key after receiving the reservation deletion request D41. The predetermined condition RC is that a digital key different from the target digital key, the third digital key DK3, among multiple digital keys for the vehicle 20 is authenticated by the vehicle 20. The first device 30A then sends the reservation deletion request D41 for the third digital key DK3 to the management server 70.

[0109] Subsequently, when the management server 70 receives the reservation deletion request D41 for the third digital key DK3, it performs the process in step S62. In step S62, the management server 70 generates a confirmation notification M41 to check for the presence of a cancellation request D51. The cancellation request D51 is a request to cancel the deletion of the target digital key in accordance with the reservation deletion request D41.

[0110] Then, the management server 70 sends confirmation notification M41 to the second device 30B. The second device 30B is the device 30 that was involved in the registration of the third device 30C, and is a different device 30 from the first device 30A that sent the reservation deletion request D41. Subsequently, the management server 70 sends the reservation deletion request D41 to the vehicle 20.

[0111] Subsequently, when vehicle 20 receives reservation deletion request D41, it proceeds to step S63. In step S63, vehicle 20 repeatedly performs fade-out checks until it determines that the specified condition RC has been met. In the fade-out check, vehicle 20 repeatedly determines whether or not the specified condition RC has been met. Specifically, vehicle 20 determines that the specified condition RC has been met when it authenticates a digital key different from the target digital key among multiple digital keys for vehicle 20. When vehicle 20 determines that the specified condition RC has been met, it proceeds to step S64.

[0112] In step S64, the vehicle 20 generates a confirmation notice M42 indicating that the specified condition RC has been met. Subsequently, the vehicle 20 sends the confirmation notice M42 to the management server 70. Subsequently, when the management server 70 receives the confirmation notification M42, the management server 70 sends the confirmation notification M41 to the second device 30B again. After that, the management server 70 performs the process in step S65. In step S65, the management server 70 generates a deletion request D42 to delete the authentication information AT of the target digital key. After the management server 70 generates the deletion request D42, the management server 70 sends the deletion request D42 to the vehicle 20.

[0113] Subsequently, when vehicle 20 receives the deletion request D42, vehicle 20 performs the process in step S66. In step S66, vehicle 20 determines whether to accept the deletion request D42. Details of the acceptance determination for the deletion request D42 will be described later. If vehicle 20 accepts the deletion request D42 in its acceptance determination, vehicle 20 proceeds to step S67.

[0114] In step S67, the vehicle 20 deletes the authentication information AT of the third digital key DK3 in accordance with the deletion request D42. As a result, the management system 10 deletes the third digital key DK3. Subsequently, the vehicle 20 sends a completion notification M43 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion request D42.

[0115] When the management server 70 receives the completion notification M43, the management server 70 performs the process in step S68. In step S68, the management server 70 generates a deletion request D43 to delete the key information DK of the target digital key. Specifically, the deletion request D43 is a request to delete the key information DK that indicates the third digital key DK3, which is the target digital key. After the management server 70 generates the deletion request D43, the management server 70 sends the deletion request D43 to the third device 30C.

[0116] When the third device 30C receives a deletion request D43, the third device 30C performs the process in step S69. In step S69, the third device 30C deletes the key information DK that indicates the digital key registered based on the target digital key, in accordance with the deletion request D43. Specifically, the third device 30C deletes the key information DK that indicates the third digital key DK3. In this embodiment, the key information DK that indicates the third digital key DK3 is the non-friend key information DKN.

[0117] After the management server 70 sends the deletion request D43, the management server 70 proceeds to step S70. In step S70, the management server 70 updates the database DB. Specifically, the management server 70 deletes the third device 30C from the vehicle 20 data DA in the database DB. After that, the management system 10 completes the series of processes for this deletion management.

[0118] <Cancellation Request> Next, we will explain the transmission of a cancellation request D51 by device 30, which receives the confirmation notice M41.

[0119] When device 30 receives the confirmation notice M41 sent from the management server 70, device 30 performs a series of processes to send a cancellation request D51. In this embodiment, since the second device 30B receives the confirmation notice M41, the second device 30B performs a series of processes to send a cancellation request D51.

[0120] As shown in Figure 9, upon receiving the confirmation notification M41, the execution device 36 first performs the process in step S71. In step S71, the execution device 36 displays an image on the HMI 32's display device to confirm whether or not a cancellation request D51 is required. This image includes, for example, an icon indicating that a cancellation request D51 is necessary. The execution device 36 then proceeds to step S72.

[0121] In step S72, the execution device 36 determines whether it has received an operation from the HMI 32's input device indicating that a cancellation request D51 is necessary. This operation is, for example, touching an icon that indicates that a cancellation request D51 is necessary.

[0122] When the HMI32 input device receives an operation indicating that a cancellation request D51 is required (S72: YES), the execution device 36 proceeds to step S73. In step S73, the execution device 36 generates a cancellation request D51. After that, the execution device 36 proceeds to step S74.

[0123] In step S74, the execution device 36 sends a cancellation request D51 to the management server 70. When the management server 70 receives the cancellation request D51, it sends the cancellation request D51 to the vehicle 20. After that, the execution device 36 proceeds to step S75.

[0124] In step S75, the execution device 36 hides the image used to check for the presence or absence of the cancellation request D51 that was being displayed. After that, the execution device 36 completes the series of processes required to send the current cancellation request D51.

[0125] On the other hand, if the HMI32 input device has not received an operation indicating that a cancellation request D51 is required (S72: NO), the execution device 36 proceeds to step S76.

[0126] In step S76, the execution device 36 determines whether a predetermined period P1 has elapsed since receiving the confirmation notice M41. If the predetermined period P1 has not elapsed (S76: NO), the execution device 36 returns to step S72.

[0127] On the other hand, when the predetermined period P1 has elapsed (S76: YES), the execution device 36 proceeds to step S75. Therefore, if a positive determination is made in step S76 and the processing in step S75 is performed, device 30 does not send a cancellation request D51 to the management server 70.

[0128] In this embodiment, of the multiple devices 30, only the device 30 that received the confirmation notification M41 is able to send the cancellation request D51. In other words, the management server 70 restricts the source of the cancellation request D51 by limiting the recipient of the confirmation notification M41 to only the second device 30B.

[0129] <Deletion Request Acceptance Decision> The details of the vehicle management device 26's decision to accept deletion request D43 will be explained below. As shown in Figure 10, when the execution device 27 starts the acceptance determination, the execution device 27 first performs the process in step S81. In step S81, the execution device 27 determines whether the vehicle 20 has received a cancellation request D51 from the second device 30B during the specified period RP. The specified period RP includes the period from when the vehicle 20 receives a reservation deletion request D41 until it receives a deletion request D42, and the period from when the specified condition RC is met until a predetermined period P1 has elapsed.

[0130] Specifically, the execution device 27 first waits until a predetermined period P1 has elapsed after the specified condition RC is met. Next, the execution device 27 determines whether the vehicle 20 has received a cancellation request D51 during the predetermined period RP. Then, the execution device 27 determines whether the device 30 that sent the cancellation request D51 is the second device 30B.

[0131] Furthermore, the second device 30B is different from the third device 30C on which the target digital key, the third digital key DK3, is registered. Also, the second device 30B is device 30 that was involved in the registration of the target digital key, the third digital key DK3. In addition, the second device 30B is different from the first device 30A that requested the reservation deletion request D41.

[0132] If vehicle 20 has not received a cancellation request D51 from the second device 30B to RP for the specified period (S81: NO), the execution device 27 proceeds to step S82. In step S82, the execution device 27 decides to accept the deletion request D42. As a result, the execution device 27 determines that it will delete the target digital key. After that, the execution device 27 terminates the series of processes for determining acceptance of the current deletion request D42.

[0133] Subsequently, the management system 10 deletes the target digital key by performing the processes from step S67 onwards in the series of deletion management processes shown in Figure 8. In other words, when the execution device 27 accepts the deletion request D42, the execution device 27 deletes the authentication information AT of the target digital key.

[0134] On the other hand, as shown in Figure 10, when the vehicle 20 receives a cancellation request D51 from the second device 30B during the specified period (S81: YES), the execution device 27 proceeds to step S83. In step S83, the execution device 27 rejects the deletion request D42.

[0135] In this case, the execution device 27 does not perform the process in step S67 shown in Figure 8. Therefore, the execution device 27 does not delete the authentication information AT of the target digital key. In other words, because the execution device 27 rejects the deletion request D42, the management system 10 does not delete the target digital key.

[0136] After the execution device 27 rejects the deletion request D42, the execution device 27 proceeds to step S84. In step S84, the execution device 27 issues a rejection notification M51, ending the series of processes for determining whether to accept the deletion request D42.

[0137] In this way, the management system 10, which includes multiple computers, performs deletion management, and the management system 10 deletes the target digital key when the specified condition RC is met. The multiple computers are multiple execution devices 36, execution device 71, and execution device 27. In other words, the management system 10 performs the deletion management shown in Figure 8, thereby realizing a deletion management method in which the target digital key is deleted when the specified condition RC is met.

[0138] <Operation of the First Embodiment> As shown in Figure 8, when the vehicle management device 26 receives deletion request D42, the management system 10 deletes the target digital key. Thus, the management system 10 deletes the target digital key when the specified condition RC is met.

[0139] On the other hand, in the acceptance determination of deletion request D42 shown in Figure 10, if the vehicle management device 26 rejects deletion request D42 through the processing in step S83, the vehicle management device 26 does not delete the authentication information AT in accordance with deletion request D42. In other words, in this case, even if the specified condition RC is met, the management system 10 does not delete the target digital key.

[0140] Furthermore, in the acceptance determination of the deletion request D42, if the vehicle management device 26 rejects the deletion request D42 in the processing of step S83, the management server 70 does not receive the completion notification M43 shown in Figure 8. Therefore, the management server 70 does not send the deletion request D43, which is a request to delete the key information DK indicating the target digital key, to the second device 30B.

[0141] As a result, the management system 10 does not delete the key information DK that indicates the target digital key. In other words, since neither the authentication information AT nor the key information DK is deleted, the target digital key remains in a usable state, i.e., a registered state.

[0142] <Effects of the First Embodiment> (1-1) The management system 10 deletes the target digital key if no cancellation request D51 is received from a device 30 that has registered a digital key different from the target digital key during the specified period. On the other hand, the management system 10 does not delete the target digital key if a cancellation request D51 is received from a device 30 that has registered a digital key different from the target digital key during the specified period. Therefore, the management system 10 does not delete the target digital key based on a cancellation request D51 from the device 30 that has registered the target digital key. Thus, the management system 10 can prevent the target digital key from being deleted by an operation of the device 30 that has registered the target digital key.

[0143] (1-2) The second device 30B is a device 30 that has a second digital key DK2 registered that is different from the third digital key DK3 and was involved in the registration of the third digital key DK3. In other words, the management system 10 does not delete the target digital key if a cancellation request D51 is received from a device 30 that has a different digital key registered that is different from the device 30 on which the target digital key is registered and was involved in the registration of the target digital key.

[0144] On the other hand, the management system 10 deletes the target digital key even if a cancellation request D51 is made from a device 30 that is different from the third device 30C and is not involved in the registration of the third digital key DK3. Specifically, the management system 10 deletes the target digital key even if a cancellation request D51 is made from the fourth device 30D to the seventh device 30G. Therefore, it is possible to prevent the third digital key DK3 from being deleted by users of the fourth device 30D to the seventh device 30G, who are highly likely to be unaware of the registration history.

[0145] (1-3) The second device 30B is a different device 30 from the first device 30A that made the reservation deletion request D41. In other words, the management system 10 does not delete the target digital key if a cancellation request D51 is made from a device 30 that has a different digital key registered to it than the device 30 to which the target digital key is registered and has not made the reservation deletion request D41.

[0146] Therefore, the management system 10 can prevent the deletion of the target digital key if a cancellation request D51 is received from a user's device 30 that has not performed the operation to send a reservation deletion request D41.

[0147] (1-4) A reservation deletion request D41 can be made by the first device 30A or the second device 30B that was involved in the registration of the third digital key DK3. In other words, when a reservation deletion request D41 is made by a device 30 that was involved in the registration of the target digital key, the management system 10 deletes the target digital key when the specified condition RC is met. Therefore, deletion management is performed only by a cancellation request D51 from the first device 30A or the second device 30B, which are highly likely to know the history of the registration of the target digital key. Thus, it is possible to prevent the deletion of the third digital key DK3 by users of the fourth device 30D to the seventh device 30G, which are highly likely to not know the history of the registration.

[0148] (1-5) When the management server 70 receives the reservation deletion request D41, the management server 70 sends a confirmation notice M41 to the second device 30B. As a result, the user of the second device 30B can understand that the third digital key DK3 will be deleted when the specified condition RC is met.

[0149] (1-6) When the specified condition RC is met, the management server 70 sends a confirmation notice M41 to the second device 30B. As a result, the user of the second device 30B can understand that the third digital key DK3 will be deleted after a predetermined period P1 has elapsed.

[0150] (1-7) When the vehicle 20 is used as a rental car or shared car, the user switches, for example, from the user of the second device 30B to the user of the fifth device 30E. Here, the specified condition RC is that a digital key different from the target digital key among multiple digital keys is authenticated to the vehicle 20.

[0151] Therefore, when a new digital key is authenticated after the switch, the previous digital key is deleted. Specifically, when any of the 5th digital key DK5 to the 7th digital key DK7 is authenticated on vehicle 20, the previous 2nd digital key DK2 to the 4th digital key DK4 are deleted. This allows the management system 10 to delete the previous digital key in accordance with the timing of the user switch.

[0152] (1-8) The specified period RP includes the period from when the management server 70 receives the reservation deletion request D41 until the specified condition RC is met. Therefore, if a cancellation request D51 is made during the period from when the reservation deletion request D41 is received until the specified condition RC is met, the management system 10 will not delete the target digital key. Thus, a user of the second device 30B who is aware that a reservation deletion request D41 has been made can prevent the target digital key from being deleted by operating the second device 30B.

[0153] (1-9) If no cancellation request D51 is received from device 30 with a digital key different from the target digital key registered in RP during the specified period, the vehicle management device 26 accepts a deletion request D42. As a result, the vehicle management device 26 deletes the authentication information AT of the target digital key.

[0154] On the other hand, even if a cancellation request D51 is received from device 30 that has registered a digital key different from the target digital key during the specified period RP, the vehicle management device 26 does not delete the authentication information AT of the target digital key by rejecting the deletion request D42. Therefore, the authentication information AT of the digital key registered based on the target digital key is not deleted.

[0155] Therefore, even if the specified condition RC is met, the management system 10 can stop deleting the target digital key by having the vehicle management device 26 reject the deletion request D42.

[0156] (1-10) When the vehicle management device 26 rejects the deletion request D42, the vehicle management device 26 sends a rejection notice M51 to the first device 30A, which is the device 30 that requested the reservation deletion request D41. Therefore, after operating the first device 30A and sending the reservation deletion request D41, the user of the first device 30A can find out that the deletion of the target digital key has been rejected.

[0157] <Second Embodiment> The management system 10 in the second embodiment will now be described with reference to the drawings. The main difference in the second embodiment compared to the first embodiment is that it performs a determination to allow the transmission of the completion notification M42 without performing an acceptance determination. In the following, the differences from the first embodiment will be explained in detail, and the explanation of the same points will be simplified or omitted.

[0158] <Determination of permission to send confirmation notice> After the vehicle management device 26 generates the completion notification M42 through the processing of step S64 in the series of deletion management processes, the execution device 27 performs a determination to allow the transmission of the completion notification M42 before sending the completion notification M42 to the management server 70.

[0159] As shown in Figure 11, when the execution device 27 starts the transmission permission determination, the execution device 27 first performs the process in step S91. In step S91, the execution device 27 determines whether the vehicle 20 received a cancellation request D51 during the specified period RP. The process in step S91 is the same as the process in step S81, so the details are omitted.

[0160] If vehicle 20 has not received a cancellation request D51 from the second device 30B to RP for the specified period (S91: NO), the execution device 27 proceeds to step S92. In step S92, the execution device 27 authorizes the transmission of the confirmation notice M42. After that, the execution device 27 completes the series of processes for determining whether to authorize the transmission of the confirmation notice M42.

[0161] Subsequently, the vehicle management device 26 sends a confirmation notification M42. Upon receiving the confirmation notification M42, the management server 70 sends a confirmation notification M41 to the second device 30B. The management system 10 then deletes the target digital key by performing the processes from step S65 onward in the series of deletion management processes.

[0162] On the other hand, when vehicle 20 receives a cancellation request D51 from the second device 30B during the specified period (S91: YES), the execution device 27 proceeds to step S93. In step S93, the execution device 27 stops sending the confirmation notification M42.

[0163] In this case, the management server 70 does not receive the confirmation notification M42. Therefore, the management system 10 does not generate a deletion request D42 in accordance with the confirmation notification M42. In other words, because the execution device 27 stops sending the confirmation notification M42, the management system 10 does not delete the target digital key.

[0164] After the execution device 27 cancels the transmission of the confirmation notification M42, the execution device 27 proceeds to step S94. In step S94, the execution device 27 sends a cancellation notification M61 to the device 30 that requested the reservation deletion request D41, indicating that it has canceled the transmission of the confirmation notification M42. The device 30 that requested the reservation deletion request D41 is the first device 30A. After that, the execution device 27 completes the series of processes for determining whether to grant the confirmation notification M42.

[0165] <Operation of the second embodiment> In the determination of whether to permit the transmission of the confirmation notice M42, if the vehicle management device 26 cancels the transmission of the confirmation notice M42 in the processing of step S93, the management server 70 does not receive the confirmation notice M42. Therefore, the management server 70 does not generate a deletion request D42, and thus does not send the deletion request D42 to the vehicle 20. As a result, the management server 70 does not allow the vehicle 20 to delete the authentication information AT of the target digital key. In other words, the management system 10 does not delete the target digital key.

[0166] <Effects of the second embodiment> In the second embodiment, in addition to the effects (1-1) to (1-8) of the first embodiment, the following further effects are achieved.

[0167] (2-1) If no cancellation request D51 is received from device 30 with a digital key different from the target digital key registered in RP during the specified period, the vehicle management device 26 authorizes the transmission of a confirmation notification M42. As a result, the management system 10 proceeds with a series of deletion management processes. Consequently, the management system 10 deletes the target digital key.

[0168] On the other hand, if a digital key registered based on the target digital key is authenticated by the vehicle 20, the vehicle management device 26 stops sending the authentication notification M42, thereby preventing the management server 70 from generating and sending a deletion request D43. As a result, the vehicle management device 26 does not delete the authentication information AT of the target digital key and the digital key registered based on the target digital key. Therefore, the authentication information AT of the target digital key is not deleted.

[0169] Therefore, in the deletion management performed by the management system 10, the management system 10 can stop deleting the target digital key by having the vehicle management device 26 stop sending the completion notification M42.

[0170] (2-2) When the vehicle management device 26 stops sending the confirmation notification M42, the vehicle management device 26 sends a cancellation notification M61 to the first device 30A, which is the device 30 that requested the reservation deletion request D41. Therefore, after operating the first device 30A and sending the reservation deletion request D41, the user of the first device 30A can find out that even though the specified condition RC is met, the deletion management in the management system 10 has been suspended for the target digital key.

[0171] <Third Embodiment> The management system 10 in the third embodiment will now be described with reference to the drawings. The fifth embodiment differs from the first embodiment mainly in that the vehicle 20 does not perform an acceptance determination, and the management server 70 performs a determination to permit the creation of the deletion request D42. In the following, the differences from the first embodiment will be explained in detail, and the same points will be simplified or omitted.

[0172] As shown in Figure 12, when the management server 70 receives the confirmation notification M42, the execution device 71 performs the process in step S101. In step S101, the execution device 71 determines whether the management server 70 received a cancellation request D51 from the second device 30B during the specified period RP. The process in step S101 is the same as the process in step S81 in the first embodiment, so the details are omitted.

[0173] If the management server 70 has not received a cancellation request D51 from the second device 30B (S101: NO), the execution device 71 proceeds to step S102. In step S102, the execution device 71 authorizes the generation of a deletion request D42. After that, the execution device 71 completes a series of processes to determine whether or not to generate the current deletion request D42.

[0174] Subsequently, the management server 70 performs a series of deletion management processes and sends the generated deletion request D42 to the vehicle 20. Then, the vehicle management device 26 deletes the authentication information AT of the target digital key according to the deletion request D42. As a result, the management system 10 deletes the target digital key.

[0175] On the other hand, as shown in Figure 12, when the management server 70 receives a cancellation request D51 from the second device 30B (S101: YES), the execution device 71 proceeds to step S103.

[0176] In step S103, the execution device 71 is prohibited from generating deletion request D42. In this case, the management server 70 does not generate deletion request D42 during deletion management. Therefore, because the vehicle 20 does not receive deletion request D42, the vehicle management device 26 does not delete the authentication information AT of the target digital key. As a result, the management system 10 does not delete the target digital key.

[0177] <Effects of the Third Embodiment> In addition to the effects (1-1) to (1-8) of the first embodiment, the management system 10 in the third embodiment provides the following further effects.

[0178] (3-1) When a cancellation request D51 is received, the management server 70 does not generate a deletion request D42 or send it to the vehicle 20. As a result, the vehicle 20 does not receive the deletion request D42, and the vehicle management device 26 does not delete the target digital key. Therefore, the management server 70 can prevent the deletion of the target digital key by not sending the deletion request D42. Thus, if there are multiple vehicles 20 that have already undergone deletion management, it is sufficient to change the management server 70 to perform the series of processes shown in Figure 12 without updating the vehicle management device 26 of each vehicle 20.

[0179] <Fourth Embodiment> The management system 10 in the fourth embodiment will now be described with reference to the drawings. The main difference in the fourth embodiment compared to the first embodiment is that the vehicle 20 does not make a determination to accept the establishment notification M42, but instead makes a determination to determine whether or not to delete the authentication information AT. In the following, the differences from the first embodiment will be explained in detail, and the same points will be simplified or omitted.

[0180] As shown in Figure 13, the management system 10 performs deletion management. In deletion management, the first device 30A performs the processing in step S61 and then sends a reserved deletion request D41 to the management server 70.

[0181] After performing the processing in step S62, the management server 70 sends a confirmation notice M41 to the second device 30B and the third device 30C. Subsequently, the management server 70 sends a reservation deletion request D41 to the vehicle 20. When the management server 70 sends the reservation deletion request D41 to the vehicle 20, it also sends information identifying the digital key to be deleted to the vehicle 20.

[0182] When vehicle 20 determines that the specified condition RC has been met by performing the process in step S63, vehicle 20 proceeds to step S111. In step S111, the vehicle 20 determines whether or not to delete the authentication information AT. Details of the determination of whether or not to delete the authentication information AT will be described later. If the vehicle 20 permits the deletion of the authentication information AT in step S111, the vehicle 20 proceeds to step S67. Since each process from step S67 onward is the same as in the first embodiment, a detailed explanation will be omitted.

[0183] In the fourth embodiment, when the management server 70 receives a cancellation request D51 from the device 30, it sends the cancellation request D51 along with information identifying the device 30 that made the request to the vehicle 20.

[0184] <Determination of whether authentication information can be deleted> This section explains the details of the determination made by the vehicle management device 26 regarding whether or not to delete the authentication information AT. As shown in Figure 14, when the vehicle management device 26 starts determining whether or not to delete the authentication information AT, the execution device 27 first performs the process in step S121.

[0185] In step S121, the execution device 27 determines whether the vehicle 20 received a cancellation request D51 during the specified period RP. Specifically, the execution device 27 first waits until a predetermined period P1 has elapsed after the specified condition RC has been met. Next, the execution device 27 determines whether or not the vehicle 20 has received a cancellation request D51 during the predetermined period RP.

[0186] Next, the execution device 27 refers to the information identifying the device 30 that requested the cancellation request D51, which was received along with the cancellation request D51. The execution device 27 determines whether the device 30 identified by the information identifying the device 30 that it referred to is the second device 30B.

[0187] If vehicle 20 has not received a cancellation request D51 from the second device 30B to RP during the specified period (S121: NO), the execution device 27 proceeds to step S122. In step S122, the execution device 27 authorizes the deletion of the authentication information AT of the third digital key DK3. Subsequently, the execution device 27 completes the series of processes for determining whether or not to delete the authentication information AT. After that, the management system 10 deletes the third digital key DK3 by performing the process in step S67 of the series of deletion management processes shown in Figure 13.

[0188] On the other hand, as shown in Figure 14, if vehicle 20 receives a cancellation request D51 from the second device 30B during the specified period (S121: YES), the execution device 27 proceeds to step S123. In step S123, the execution device 27 prohibits the deletion of the authentication information AT of the third digital key DK3.

[0189] In this case, the execution device 27 does not perform the process in step S67 shown in Figure 13. Therefore, because the execution device 27 does not delete the authentication information AT of the third digital key DK3, the management system 10 does not delete the third digital key DK3. Subsequently, the execution device 27 completes the series of processes in determining whether to permit the deletion of the authentication information AT in this case.

[0190] In the fourth embodiment, the execution device 27, which is a computer, executes the processes in steps S63, S111, and S67 by executing the vehicle program PV. This causes the execution device 27 to either not delete the target digital key or delete it when the specified condition RC is met. In other words, the vehicle program PV is a program that causes the execution device 27 to either not delete the target digital key or delete it when the specified condition RC is met, as requested by the device 30 that made the cancellation request D51.

[0191] <Fourth Embodiment> In addition to the effects (1-1) to (1-8) of the first embodiment, the management system 10 in the fourth embodiment provides the following further effects.

[0192] (4-1) After the specified condition RC is met by the fade-out determination, the vehicle management device 26 determines whether or not to delete the authentication information AT. If the deletion of the authentication information AT is permitted, in step S67, the vehicle management device 26 deletes the target digital key by deleting the authentication information AT. On the other hand, if there is a cancellation request D51 from the second device 30B, the vehicle management device 26 does not delete the target digital key by not deleting the authentication information AT. Therefore, in the fourth embodiment, after the vehicle 20 receives the reservation deletion request D41, the vehicle management device 26 determines whether or not to delete the target digital key simply by having the management server 70 relay the cancellation request D51. Furthermore, if the vehicle management device 26 determines to delete the target digital key, it deletes the target digital key. In other words, the vehicle management device 26 does not delete the third digital key DK3 if there is a cancellation request D51 from the second device 30B during the specified period RP, and deletes the third digital key DK3 if there is no cancellation request D51 from the second device 30B during the specified period RP. In this way, the vehicle management device 26 alone can manage the deletion of the third digital key DK3 based on whether or not it has received a cancellation request D51 from the second device 30B.

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

[0194] <Management System> 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.

[0195] A different ECU installed in a different vehicle 20 than the vehicle management device 26 may authenticate the digital key. • The matters concerning digital keys in each of the above embodiments do not have to comply with CCC.

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

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

[0198] In each of the embodiments described above, 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 to 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.

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

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

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

[0202] The management server 70 does not need to store a database DB. The management server 70 only needs to manage a 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.

[0203] The management system 10 does not necessarily have a management server 70. Therefore, the management system 10 only needs to perform the following: delete the target digital key, determine whether or not to delete the target digital key, and delete the target digital key. In the first embodiment, the management server 70 deletes the target digital key while the vehicle management device 26 determines whether or not to delete the target digital key and deletes the target digital key, but it is not limited to this.

[0204] For example, the vehicle management device 26 may perform the following actions: deleting the target digital key, deciding whether or not to delete the target digital key, and deleting the target digital key. In this case, the management system 10 may consist only of the vehicle management device 26. Alternatively, the management system 10 may consist of a management server 70 and multiple devices 30. Alternatively, the management system 10 may consist of a management server 70 and the vehicle management device 26.

[0205] Deleting a digital key means changing the state from one where it is usable to one where it is unusable. In each of the above embodiments, if either the authentication information AT or the key information DK for a single digital key is deleted, that digital key becomes unusable.

[0206] Therefore, deleting a digital key means deleting at least one of the following: authentication information AT, which is information about the digital key stored in the vehicle management device 26, and key information DK, which is information about the digital key stored in the device 30. If both authentication information AT and key information DK are to be deleted, the digital key will be deleted at the time one of them is deleted first.

[0207] <Information about various types of information> The information regarding the digital key stored by the vehicle management device 26 is not limited to authentication information AT, but may be any information regarding the digital key. For example, the information regarding the digital key may be information that identifies the digital key.

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

[0209] The information regarding the digital key stored by the vehicle management device 26 may be different from or the same as the information regarding the digital key stored by the device 30, as in the above embodiment.

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

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

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

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

[0214] In a database, permissions do not have to be uniformly defined according to the type of digital key; they may be set for each digital key. Furthermore, permissions may not be defined at all in a database.

[0215] The series of processes for registering the owner key KO is not limited to the examples of the embodiments described above. 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.

[0216] The series of processes for registering the friend key KF is not limited to the examples of the embodiments described above. 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.

[0217] The series of processes for registering a non-friend key KN is not limited to the examples of the embodiments 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.

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

[0219] The target digital key is not limited to the second digital key DK2, which is the friend key KF. For example, if a new non-friend key KN is registered based on the third digital key DK3, as in the modification example above, the target digital key may also be the third digital key DK3.

[0220] <Reservation cancellation request> The reservation deletion request D41 may be generated on a device other than device 30. The management server 70 or the vehicle 20 may generate the reservation deletion request D41.

[0221] Device 30 may be able to generate a reservation deletion request D41 for digital keys among multiple digital keys that are not involved in registration. For example, the second device 30B may be able to generate a reservation deletion request D41 for the fifth digital key DK5.

[0222] <Regulations> The specified condition RC does not necessarily have to be that a digital key different from the target digital key among multiple digital keys is authenticated by the vehicle 20. For example, the specified condition RC may be that a predetermined amount of time has elapsed since the reservation deletion request D41 was received.

[0223] <Determination of whether or not to delete the target digital key> Whether or not to delete the target digital key is determined, for example, by the acceptance of the deletion request D42 in the first embodiment, by the permission to send the establishment notification M42 in the second embodiment, and by the permission to generate the deletion request D42 in the third embodiment. Whether or not to delete the target digital key can be determined by whether or not the device 30 requesting the cancellation request D51 is a different device 30 from the device 30 to which the target digital key is registered, regardless of the examples in each embodiment described above. In other words, the management system 10 can avoid deleting the target digital key by stopping either the transmission or generation of the signals that are communicated until the deletion of the target digital key in the deletion management is performed.

[0224] <Regulated period> The specified period RP is not limited to the examples of the above embodiment. For example, the specified period RP may be the period from when the management server 70 receives the reservation deletion request D41 until the specified condition RC is met. The specified period RP does not have to include the period from when the management server 70 receives the reservation deletion request D41 until the specified condition RC is met. For example, the specified period RP may be the period from when the target digital key is registered until the management server 70 receives the reservation deletion request D41.

[0225] <Device that initiated the cancellation request> The management system 10 may delete the target digital key if a digital key different from the target digital key is registered in the RP for a specified period and a cancellation request D51 is received from a device 30 that was involved in the registration of the target digital key. In other words, the device 30 that made the cancellation request D51 may be a device 30 that was not involved in the registration of the target digital key. Specifically, the device 30 that made the cancellation request D51 may be not only the second device 30B, but also any one of the first device 30A, the fourth device 30D to the seventh device 30E.

[0226] If a device 30 has a different digital key registered in the RP for a specified period and has not made a reservation deletion request D41, and a cancellation request D51 is made from that device, the target digital key may be deleted. In other words, the device 30 that made the cancellation request D51 may be the first device 30A that made the reservation deletion request D41.

[0227] The devices 30 capable of sending reservation deletion request D41 are not limited to those involved in the registration of the target digital key. Devices 30 not involved in the registration of the target digital key may also send reservation deletion request D41.

[0228] <Notification> When the vehicle management device 26 rejects the deletion request D42, it does not need to send a rejection notice M51. For example, in the first embodiment, the vehicle management device 26 may omit the processing in step S84 when determining whether to accept the deletion request D42.

[0229] When the vehicle management device 26 decides to stop sending the confirmation notice M42, it does not need to send the cancellation notice M61. For example, in the second embodiment, the vehicle management device 26 may omit the processing in step S94 when determining whether to allow the transmission of the confirmation notice M42.

[0230] The management server 70 may send confirmation notification M41 to the first device 30A and the third devices 30C through 7th devices 30G. When the management server 70 receives the reservation deletion request D41, the management server 70 does not need to send the confirmation notice M41 to the second device 30B.

[0231] When the specified condition RC is met, the management server 70 does not need to send the confirmation notice M41 to the second device 30B. [Note] The technical concepts that can be understood from the above embodiments and modified examples are described below.

[0232] [Note 1] A management system for deleting a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, wherein if a cancellation request to cancel the deletion of the target digital key is received from a device registered with a digital key different from the target digital key during a predetermined period, the target digital key is not deleted, and the target digital key is deleted if no such cancellation request is received from a device registered with a digital key different from the target digital key during the predetermined period.

[0233] [Note 2] The management system described in Note 1, which does not delete the target digital key if a digital key different from the target digital key is registered during the specified period and a cancellation request is made from the device involved in the registration of the target digital key.

[0234] [Note 3] A management system according to Note 1 or Note 2 that does not delete the target digital key when a cancellation request is made from a device that has registered a digital key different from the target digital key during the specified period and has not requested the deletion of the target digital key when the specified conditions are met.

[0235] [Note 4] The management system described in any one of Notes 1 to 3, which deletes the target digital key when the specified conditions are met, if a request to delete the target digital key is made from a device involved in the registration of the target digital key.

[0236] [Note 5] The management system according to any one of Notes 1 to 4, comprising a management server for managing the multiple digital keys, wherein when the management server receives a request to delete the target digital key when the specified conditions are met, the management server sends a confirmation notice to the device to which the digital key for the vehicle is registered, confirming whether or not the cancellation request exists.

[0237] [Note 6] The management system according to any one of Notes 1 to 5, comprising a management server for managing the multiple digital keys, wherein when the specified conditions are met, the management server sends a confirmation notice to the device on which the digital key for the vehicle is registered, confirming whether or not a cancellation request has been made.

[0238] [Note 7] The management system described in any one of Notes 1 to 6, wherein the specified condition is that a digital key different from the target digital key among the plurality of digital keys is authenticated by the vehicle.

[0239] [Note 8] A management system according to any one of Notes 1 to 7, comprising a management server for managing the plurality of digital keys, wherein the specified period includes the period from when the management server receives a request to delete the target digital key when the specified condition is met until the specified condition is met.

[0240] [Note 9] A management system according to any one of Notes 1 to 8, comprising a management server that manages the plurality of digital keys, and a vehicle management device installed in the vehicle that stores information about the target digital key, wherein the management server sends a request to the vehicle to delete information about the target digital key when the specified conditions are met, and when the vehicle receives the request to delete information about the target digital key, if there is a cancellation request, the vehicle management device refuses the request to delete the target digital key, thereby not deleting the target digital key.

[0241] [Note 10] The management system according to Note 9, wherein when the vehicle management device rejects the request to delete the target digital key, the vehicle management device sends a rejection notice indicating that it rejects the request to delete the target digital key to the device that sent the request to delete the target digital key when the specified conditions are met.

[0242] [Note 11] A management system according to any one of Notes 1 to 8, comprising: a management server for managing the plurality of digital keys; and a vehicle management device installed in the vehicle and storing information relating to the target digital key, wherein the vehicle management device sends a confirmation notification to the management server indicating that the specified conditions have been met when the specified conditions are met; the management server, upon receiving the confirmation notification, sends a request to the vehicle to delete the information relating to the target digital key; and when the vehicle receives the request to delete the information relating to the target digital key, the vehicle management device deletes the target digital key by accepting the request to delete the target digital key; and the vehicle management device does not delete the target digital key by ceasing to send the confirmation notification to the management server when a cancellation request is made.

[0243] [Note 12] The management system according to Note 11, wherein when the vehicle management device stops sending the confirmation notification to the management server, the vehicle management device sends a notification to the device that sent the request to delete the target digital key when the specified conditions are met, indicating that it has stopped sending the confirmation notification.

[0244] [Note 13] A management system according to any one of Notes 1 to 8, comprising: a management server that manages the plurality of digital keys; and a vehicle management device installed in the vehicle that stores information about the target digital key, wherein the management server sends a request to the vehicle to delete information about the target digital key when the specified conditions are met; when the vehicle receives the request to delete information about the target digital key, the vehicle management device deletes the information about the target digital key, thereby deleting the target digital key; and the management server does not delete the target digital key when a cancellation request is made, by not sending a request to the vehicle management device to delete information about the target digital key. [Explanation of Symbols]

[0245] 10…Management System 20... Vehicles 26... Vehicle management system 27… Execution device 30…Device 36…Execution device 40… Owner devices 50… Shared devices 51... Friend Device 52... Non-Friendly Devices 70... Management Server 71…Execution device D51... Cancellation request M41…Confirmation notification M42…Notification of establishment M51... Rejection Notice RC…Specified conditions RP…Specified period

Claims

1. A management system that deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, If a cancellation request to cancel the deletion of the target digital key is received from a device that has a different digital key registered to it, within a predetermined period, the target digital key will not be deleted. If no cancellation request is received from a device registered with a digital key different from the target digital key during the specified period, the target digital key will be deleted. Management system.

2. If a digital key different from the target digital key is registered during the specified period and a cancellation request is received from the device involved in the registration of the target digital key, the target digital key will not be deleted. The management system according to claim 1.

3. If a cancellation request is received from a device that has registered a digital key different from the target digital key during the specified period and has not requested the deletion of the target digital key when the specified conditions are met, the target digital key will not be deleted. The management system according to claim 1.

4. When the aforementioned conditions are met, a request to delete the target digital key is made from the device involved in registering the target digital key, and the target digital key is deleted when the aforementioned conditions are met. The management system according to claim 1.

5. It includes a management server that manages the aforementioned multiple digital keys, When the management server receives a request to delete the target digital key when the specified conditions are met, the management server sends a confirmation notice to the device to which the digital key for the vehicle is registered, to confirm whether or not a cancellation request exists. The management system according to claim 1.

6. It includes a management server that manages the aforementioned multiple digital keys, When the aforementioned conditions are met, the management server sends a confirmation notice to the device on which the digital key for the vehicle is registered, to confirm whether or not the cancellation request exists. The management system according to claim 1.

7. The aforementioned condition is that a digital key different from the target digital key among the multiple digital keys is authenticated by the vehicle. The management system according to claim 1.

8. It includes a management server that manages the aforementioned multiple digital keys, The aforementioned specified period includes the period from when the management server receives a request to delete the target digital key when the aforementioned specified conditions are met until the aforementioned specified conditions are met. The management system according to claim 1.

9. The system comprises a management server that manages the aforementioned multiple digital keys, and a vehicle management device that is installed in the vehicle and stores information about the target digital key. The management server, when the specified conditions are met, sends a request to the vehicle to delete the information related to the target digital key. When the vehicle receives a request to delete information related to the target digital key, and a cancellation request is made, the vehicle management device will not delete the target digital key by rejecting the request to delete the target digital key. The management system according to claim 1.

10. When the vehicle management device rejects the request to delete the target digital key, the vehicle management device sends a rejection notice indicating that it rejects the request to delete the target digital key to the device that sent the request to delete the target digital key when the specified conditions are met. The management system according to claim 9.

11. The system comprises a management server that manages the aforementioned multiple digital keys, and a vehicle management device that is installed in the vehicle and stores information about the target digital key. The vehicle management device sends a notification to the management server indicating that the specified conditions have been met when those conditions are met. When the management server receives the confirmation notification, it sends a request to the vehicle to delete the information related to the target digital key. When the vehicle receives a request to delete information related to the target digital key, the vehicle management device deletes the target digital key by accepting the request to delete the target digital key. The vehicle management device, upon receiving the cancellation request, refrains from sending the confirmation notification to the management server, thereby preventing the deletion of the digital key in question. The management system according to claim 1.

12. When the vehicle management device stops sending the confirmation notification to the management server, the vehicle management device sends a notification to the device that sent the request to delete the target digital key when the specified conditions are met, informing it that it has stopped sending the confirmation notification. The management system according to claim 11.

13. The system comprises a management server that manages the aforementioned multiple digital keys, and a vehicle management device that is installed in the vehicle and stores information about the target digital key. The management server, when the specified conditions are met, sends a request to the vehicle to delete the information related to the target digital key. When the vehicle receives a request to delete information related to the target digital key, the vehicle management device deletes the target digital key by deleting the information related to the target digital key. When the cancellation request is received, the management server does not delete the target digital key by not sending a request to the vehicle management device to delete the information related to the target digital key. The management system according to claim 1.

14. The vehicle is equipped with multiple digital keys that can be used for the vehicle, A vehicle management device that deletes a target digital key from among multiple digital keys for the vehicle when predetermined conditions are met, If a cancellation request to cancel the deletion of the target digital key is received from a device that has a different digital key registered to it, within a predetermined period, the target digital key will not be deleted. If no cancellation request is received from a device registered with a digital key different from the target digital key during the specified period, the target digital key will be deleted. Vehicle management system.

15. A deletion management method performed by a management system including a computer for deleting a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, If a cancellation request to cancel the deletion of the target digital key is received from a device that has a different digital key registered to it, within a predetermined period, the target digital key will not be deleted. If no cancellation request is received from a device registered with a digital key different from the target digital key during the specified period, the target digital key will be deleted. Deletion management method.

16. A program that causes a computer to execute when predetermined conditions are met, which deletes a target digital key from among multiple digital keys for a vehicle. To the aforementioned computer, If a cancellation request to cancel the deletion of the target digital key is received from a device registered with a digital key different from the target digital key during a predetermined period, the target digital key will not be deleted. If no such cancellation request is received from a device registered with a digital key different from the target digital key during the predetermined period, the target digital key will be deleted. program.

Images