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

Abstract

This system provides a management system that can prevent users of registered digital keys from becoming unable to use their vehicles. [Solution] When the management system deletes a target digital key from among multiple digital keys for the vehicle 20 when predetermined conditions are met, it performs a group deletion that deletes the digital keys registered based on the target digital key. The management system does not perform a group deletion if the digital keys registered based on the target digital key are authenticated by the vehicle 20, but performs a group deletion if the digital keys registered based on the target digital key are not authenticated by the vehicle 20.

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. The plurality of digital keys include a digital key and a digital key registered based on said digital key. [Prior Art Documents] [Patent Documents]

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

[0004] When deleting a target digital key upon satisfaction of a prescribed condition, a management system as described in Patent Document 1 may delete a digital key registered based on the target digital key.

[0005] In this case, when the target digital key is deleted, the digital key registered based on the target digital key is also deleted, whereby the user of the digital key registered based on the target digital key becomes unable to use the vehicle in any case. [Means for Solving the Problem]

[0006] A management system that solves the above problems is a management system that deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and deletes a group of digital keys registered based on the target digital key, wherein the group deletion is not performed if the digital key registered based on the target digital key is authenticated by the vehicle, and the group deletion is performed if the digital key registered based on the target digital key is not authenticated by the vehicle.

[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 when predetermined conditions are met, when deleting a target digital key from among the multiple digital keys for the vehicle, the vehicle management device performs a group deletion that deletes the digital keys registered based on the target digital key, wherein the group deletion is not performed when the digital key registered based on the target digital key is authenticated by the vehicle, and the group deletion is performed when the digital key registered based on the target digital key is not authenticated by the vehicle.

[0008] A deletion management method that solves the above problem is a deletion management method performed by a management system including a computer for performing group deletion, which deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and deletes the digital keys registered based on the target digital key, wherein the group deletion is not performed if the digital keys registered based on the target digital key are authenticated by the vehicle, and the group deletion is performed if the digital keys registered based on the target digital key are not authenticated by the vehicle.

[0009] A program to solve the above problem is a program to be executed by a computer that performs group deletion to delete a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and which deletes the digital keys registered based on the target digital key, and which executes the group deletion not to be performed when the digital keys registered based on the target digital key are authenticated by the vehicle, and to perform the group deletion when the digital keys registered based on the target digital key are not authenticated by the vehicle. [Effects of the Invention]

[0010] According to the above configuration, when the target digital key is deleted, digital keys registered based on the target digital key will not be deleted if the digital key is authenticated by the vehicle. The above management system, vehicle management device, deletion management method, and program can prevent users of digital keys registered based on the target digital key from being unable to use the vehicle. [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]FIG. 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 of the first embodiment. [Figure 9] FIG. 9 is a flowchart showing detailed processing in acceptance determination of a deletion request performed by the vehicle management device of the first embodiment. [Figure 10] FIG. 10 is a flowchart showing a series of processes in establishment notification transmission permission determination performed by the vehicle management device of the second embodiment. [Figure 11] FIG. 11 is a flowchart showing a series of processes for determining whether to transmit a forced acceptance request performed by the management server of the third embodiment. [Figure 12] FIG. 12 is a flowchart showing a series of processes including exclusion from deletion targets of group deletion performed by the management server of the fourth embodiment. [Figure 13] FIG. 13 is a flowchart showing a series of processes including permitting generation of a deletion request performed by the management server of the fifth embodiment. [Figure 14] FIG. 14 is an explanatory diagram showing a series of deletion management processes performed by the management system of the sixth embodiment. [Figure 15] FIG. 15 is a flowchart showing a series of processes including permission to delete authentication information performed by the vehicle management device of the sixth embodiment. DESCRIPTION OF EMBODIMENTS

[0012] <First Embodiment> Hereinafter, a 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. Regarding digital keys, there are standards established by the CCC (Car Connectivity Consortium). The matters related to the digital key in the present embodiment assume the case of conforming to 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] The 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 the 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 by means such as images and audio. The presentation device is, for example, a monitor and a speaker.

[0015] The BLE module 23 performs short-range communication with the device 30 via BLE communication. The UWB module 24 communicates with the device 30 via UWB. The UWB module 24 measures the 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 installed in the vehicle 20. The vehicle management device 26 manages multiple digital keys for the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating a digital key in order to enable control of the vehicle 20 by the digital key when using the digital key. Authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU, i.e., a processing circuit. The execution device 27 executes the processing related to the storage and deletion of 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 and a presentation device. The input device receives user input to the device 30 and inputs signals indicating the input. The presentation device presents information to the user through images, sounds, 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. The NFC module 35 communicates with the vehicle 20 via NFC.

[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 pairing functionality for device 30 and digital key sharing functionality using APIs provided by the OS. The execution device 36 executes the device program PD to perform processing 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 the digital key to be identified 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, the vehicle 20 stores the authentication information AT, and the device 30 stores the 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.

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

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

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

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

[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 as a result of 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.

[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 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 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 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 in the management system 10, which includes group deletion, where the digital key registered based on a registration request from the device 30 to which the digital key was registered, is deleted when deleting the target digital key.

[0104] In this embodiment, the target digital key is the second digital key DK2 of the friend key KF. Therefore, a series of processes related to deletion management for deleting the second digital key DK2 will be described. In group deletion, when the management system 10 deletes the second digital key DK2, it also deletes the third digital key DK3 and the fourth digital key DK4, which were registered based on a registration request from the second device 30B where the second digital key DK2 was registered.

[0105] The following describes the sequence of events from the state in which the second digital key DK2 is registered to the state in which the second digital key DK2 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] <Overview of deletion management, including group deletion> As shown in Figure 8, when the management system 10 deletes the second digital key DK2 based on the reservation deletion request D41 from the first device 30A, it performs a series of processes to delete the third digital key DK3 and the fourth digital key DK4 as part of a group deletion.

[0107] When an operation is performed in the first device 30A to request the deletion of the second digital key DK2, the first device 30A first performs the process in step S61. In step S61, a reserved deletion request D41 for the second digital key DK2 is generated. The reserved deletion request D41 is a request for reserved deletion.

[0108] The reservation deletion request D41 includes a signal requesting the deletion of the second digital key DK2, digital key identification information ST3 indicating the second digital key DK2, 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 second digital key DK2, 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 second digital key DK2 to the management server 70.

[0109] Subsequently, when the management server 70 receives the reservation deletion request D41 for the second digital key DK2, it performs the process in step S62. In step S62, the management server 70 generates a deletion notification M41 indicating that deletion is in progress according to the reservation deletion request D41.

[0110] The management server 70 then sends a deletion notification M41 to the second device 30B, the third device 30C, and the fourth device 30D. The third device 30C and the fourth device 30D are non-friendly devices 52 to which the non-friendly key KN, registered based on the registration request from the second device 30B, is registered. Note that the fourth device 30D is not shown in Figure 8. Subsequently, the management server 70 sends a reservation deletion request D41 to the vehicle 20.

[0111] Subsequently, when vehicle 20 receives reservation deletion request D41, vehicle 20 performs the process in 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 performs the process in step S65. In step S65, the management server 70 generates a deletion request D42. The deletion request D42 is a request to delete the authentication information AT of the target digital key and the authentication information AT of the digital key that was registered based on a registration request from the device 30 where the target digital key was registered.

[0113] Specifically, deletion request D42 includes a request to delete the authentication information AT of the target digital key, the second digital key DK2. Deletion request D42 includes a request to delete the authentication information AT of the third digital key DK3, which was registered based on the target digital key. Deletion request D42 includes a request to delete the authentication information AT of the fourth digital key DK4, which was registered based on the target digital key. After the management server 70 generates deletion request D42, the management server 70 sends deletion request D42 to the vehicle 20.

[0114] 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. When vehicle 20 determines that it accepts the deletion request D42, that is, that it will perform group deletion, vehicle 20 proceeds to step S67.

[0115] In step S67, vehicle 20 deletes the authentication information AT of the second digital key DK2, the authentication information AT of the third digital key DK3, and the authentication information AT of the fourth digital key DK4 in accordance with the deletion request D42. In other words, in step S67, vehicle 20 performs group deletion. After that, vehicle 20 sends a completion notification M43 to the management server 70. The completion notification M43 indicates that the deletion of the authentication information AT in accordance with the deletion request D42 has been completed.

[0116] 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. The deletion request D43 is a request to delete the key information DK of the target digital key and the key information DK of the digital key that was registered based on a registration request from the device 30 where the target digital key was registered.

[0117] Specifically, deletion request D43 includes a request to delete key information DK, which indicates the target digital key, the second digital key DK2. Deletion request D43 includes a request to delete authentication information AT of the third digital key DK3, which was registered based on the target digital key. Deletion request D43 includes a request to delete authentication information AT of the fourth digital key DK4, which was registered based on the target digital key. After the management server 70 generates deletion request D43, the management server 70 sends deletion request D43 to the second device 30B, the third device 30C, and the fourth device 30D.

[0118] When the second device 30B receives the deletion request D43, the second device 30B performs the process in step S69. In step S69, the second device 30B deletes the key information DK indicating the second digital key DK2 in accordance with the deletion request D43. In this embodiment, the key information DK indicating the second digital key DK2 is the friend key information DKF.

[0119] When the third device 30C receives a deletion request D43, the third device 30C performs the process in step S70. In step S70, 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.

[0120] Similar to the third device 30C, when the fourth device 30D receives a deletion request D43, the fourth device 30D performs the process in step S70. In step S70, the fourth device 30D 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 fourth device 30D deletes the key information DK that indicates the fourth digital key DK4. In this embodiment, the key information DK that indicates the fourth digital key DK4 is the non-friend key information DKN.

[0121] After the management server 70 sends the deletion request D43, the management server 70 proceeds to step S71. In step S71, the management server 70 updates the database DB. Specifically, the management server 70 deletes the second device 30B, the third device 30C, and the fourth device 30D 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.

[0122] <Deletion Request Acceptance Decision> The details of the vehicle management device 26's decision to accept deletion request D42 will be explained below. As shown in Figure 9, 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 digital key registered based on the target digital key has been authenticated by the vehicle 20. In detail, the execution device 27 determines whether the digital key registered based on the target digital key has been authenticated by the vehicle 20 between the time the vehicle 20 receives the reservation deletion request D41 and the time it receives the deletion request D42.

[0123] Specifically, the target digital key is the second digital key DK2. The digital keys registered based on the target digital key are the third digital key DK3 and the fourth digital key DK4.

[0124] Therefore, if at least one of the third digital key DK3 and the fourth digital key DK4 is authenticated by the vehicle 20, the execution device 27 makes an affirmative determination in step S81. On the other hand, if neither of the third digital key DK3 nor the fourth digital key DK4 is authenticated by the vehicle 20, the execution device 27 makes a negative determination in step S81.

[0125] If the digital key registered based on the target digital key is not authenticated by the vehicle 20 (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 perform group deletion. After that, the execution device 27 terminates the series of processes for determining acceptance of the current deletion request D42.

[0126] Subsequently, the management system 10 deletes the target digital key and the digital keys registered based on 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, the execution device 27 performs group deletion by accepting deletion request D42, which includes a request to delete the target digital key.

[0127] On the other hand, as shown in Figure 9, when the digital key registered based on the target digital key is authenticated by the vehicle 20 (S81: YES), the execution device 27 proceeds to step S83. In step S83, the execution device 27 rejects the deletion request D42.

[0128] As a result, if the execution device 27 only performs the processing in step S83, the execution device 27 will not delete the authentication information AT in step S67 shown in Figure 8. In other words, in this case, the management system 10 will not delete the group.

[0129] Therefore, the management system 10 does not delete the target digital key and the digital keys registered based on the target digital key in accordance with the deletion request D42. In other words, the execution device 27 does not delete the group by rejecting the deletion request D42.

[0130] 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 sends a rejection notice M51 to the device 30 that requested the deletion of the target digital key. The rejection notice M51 indicates that the deletion of the target digital key is rejected because the specified condition RC has been met. The device 30 that requested the deletion of the target digital key is the first device 30A.

[0131] In other words, when the execution device 27 rejects the deletion request D42, it sends a rejection notice M51 to the requesting device 30 that requested the deletion of the target digital key. The reserved deletion request D41 is a request to delete the target digital key when the specified condition RC is met. After that, the execution device 27 proceeds to step S85.

[0132] In step S85, the execution device 27 determines whether the use of the authenticated digital key has been completed. The use of the authenticated digital key is completed when the vehicle 20 authenticates the digital key and then, again, the vehicle 20 becomes uncontrollable by that digital key.

[0133] For example, after the vehicle 20 can be unlocked using the authenticated digital key, and after the vehicle 20 is locked while stationary, the use of the digital key is completed after a predetermined amount of time has elapsed.

[0134] For example, after the vehicle 20 can be started using the authenticated digital key, and after the vehicle 20 is locked while stopped, the use of the digital key is completed after a predetermined amount of time has elapsed.

[0135] On the other hand, if the vehicle 20 becomes controllable with the authenticated digital key, but is still under control, or if a predetermined amount of time has not elapsed after control has ended, the use of the digital key is not considered complete.

[0136] If the execution device 27 determines that the use of the authenticated digital key is not yet complete (S85: NO), the execution device 27 repeats the process in step S85. On the other hand, if the execution device 27 determines that the use of the authenticated digital key is complete (S85: YES), the execution device 27 releases the rejection of the deletion request D42 and proceeds to step S86.

[0137] In step S86, the execution device 27 sends a release notification M52 to the management server 70 and the device 30 that requested the deletion of the target digital key, indicating that it is releasing the rejection of the deletion request D42. This device 30 is the first device 30A.

[0138] In other words, when the execution device 27 releases its refusal to delete the target digital key, it sends a release notification M52 to the management server 70 and the first device 30A. After that, the execution device 27 proceeds to step S87.

[0139] In step S87, the execution device 27 repeatedly starts performing the fade-out check until it determines that the specified condition RC has been met again. After that, the execution device 27 proceeds to step S88.

[0140] In step S88, the execution device 27 determines whether the specified condition RC is met by performing a fade-out check. If the specified condition RC is not met (S88: NO), the execution device 27 repeats the process in step S88. On the other hand, if the specified condition RC is met (S88: YES), the execution device 27 proceeds to step S89.

[0141] In step S89, the execution device 27 sends a confirmation notification M42 to the management server 70. This completes the series of processes required to determine whether to accept the deletion request D42.

[0142] In this way, the management system 10, which includes multiple computers, performs deletion management, and the management system 10 performs group deletion. The multiple computers are multiple execution devices 36, 71, and 27. In other words, the management system 10 performs the deletion management shown in Figure 8, thereby realizing a deletion management method that performs group deletion.

[0143] <Operation of the First Embodiment> When the vehicle management device 26 receives a deletion request D42, the management system 10 performs a group deletion using the deletion management shown in Figure 8. As a result, when the management system 10 deletes the target digital key, it also deletes the digital keys registered based on that target digital key.

[0144] In detail, in the acceptance determination shown in Figure 9, if the vehicle management device 26 rejects the deletion request D42 in the processing of step S83, the vehicle management device 26 does not delete the authentication information AT in accordance with the deletion request D42. In other words, in this case, the management system 10 does not delete the group.

[0145] In the acceptance determination, 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 to the device 30, which is a request to delete the key information DK indicating the target digital key and the key information DK indicating the digital keys registered based on the target digital key. As a result, the management system 10 does not delete the key information DK indicating the target digital key and the key information DK indicating the digital keys registered based on the target digital key.

[0146] In other words, since neither the authentication information AT nor the key information DK is deleted, the target digital key and the digital keys registered based on that target digital key remain in a usable state, i.e., registered state.

[0147] Subsequently, when the specified condition RC is met, the vehicle management device 26 sends a meeting notification M42 to the management server 70. When the management server 70 receives the meeting notification M42, the management server 70 repeats the process shown in step S68 in Figure 8. After that, the management server 70 sends a deletion request D42 to the vehicle 20 again. When the vehicle 20 receives the deletion request D42, the vehicle management device 26 repeats the series of processes shown in Figure 9.

[0148] Subsequently, in the acceptance determination shown in Figure 9, if the digital key registered based on the target digital key is not authenticated (S81: NO), in step S82, the vehicle management device 26 accepts the deletion request D42. When the vehicle management device 26 accepts the deletion request D42, the management server 70 proceeds with the processing from step S67 onwards, as shown in Figure 8.

[0149] In this case, the vehicle management device 26 deletes the authentication information AT in accordance with the deletion request D42 by processing step S67 shown in Figure 8. In other words, when the vehicle management device 26 accepts the deletion request D42, the management system 10 performs group deletion.

[0150] In this way, the management system 10 does not delete the group if the digital key registered based on the target digital key is authenticated by the vehicle 20. On the other hand, the management system 10 deletes the group if the digital key registered based on the target digital key is not authenticated by the vehicle 20.

[0151] <Effects of the First Embodiment> (1-1) The management system 10 does not delete the group when a digital key registered based on the target digital key is authenticated by the vehicle 20. Therefore, when the target digital key is deleted, the digital keys registered based on the target digital key that are to be deleted will not be deleted when the digital keys are authenticated by the vehicle 20. Thus, the management system 10 can prevent the user of the digital key registered based on the target digital key from being unable to use the vehicle 20.

[0152] (1-2) 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 the multiple digital keys is authenticated to the vehicle 20.

[0153] 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 to the 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.

[0154] (1-3) If a digital key registered based on the target digital key is not authenticated by the vehicle 20, the vehicle management device 26 accepts the deletion request D42 and deletes the authentication information AT of the digital key to be deleted by group deletion. Specifically, when the vehicle management device 26 deletes the authentication information AT of the target digital key, the vehicle management device 26 deletes the authentication information AT of the digital key registered based on the target digital key.

[0155] On the other hand, if a digital key registered based on the target digital key is authenticated by vehicle 20, the vehicle management device 26 does not delete the authentication information AT of the digital key that would otherwise be deleted by group deletion 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.

[0156] Therefore, in the deletion management performed by the management system 10, if the vehicle management device 26 rejects the deletion request D42, the management system 10 can stop deleting the target digital key and the digital keys registered based on the target digital key.

[0157] (1-4) 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 made the request for deletion of the target digital key. 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.

[0158] (1-5) After the vehicle management device 26 rejects the deletion request D42, when the use of the authenticated digital key is complete, the vehicle management device 26 releases its rejection of the deletion request D42. Therefore, the management system 10 can prevent the target digital key from being deleted when the vehicle 20 receives the deletion request D42 again after the use of the authenticated digital key is complete.

[0159] (1-6) When the vehicle management device 26 lifts its rejection of the deletion request D42, it sends a lifting notification M52 to the first device 30A, which was the source of the request to delete the target digital key. This allows the user of the first device 30A to know that the rejection of the deletion of the target digital key has been lifted after it was initially rejected.

[0160] (1-7) After the vehicle management device 26 has released its rejection of the deletion request D42, the vehicle management device 26 restarts the determination of whether the specified condition RC has been met. Therefore, after the use of the authenticated digital key is completed, when a digital key different from both the target digital key and the digital keys registered based on the target digital key is authenticated, the vehicle management device 26 sends a confirmation notification M42 to the management server 70. As a result, the management system 10 can delete the target digital key and the digital keys registered based on the target digital key without the management server 70 having to receive the reservation deletion request D41 again.

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

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

[0163] As shown in Figure 10, 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 digital key registered based on the target digital key has been authenticated by the vehicle 20. In detail, the execution device 27 determines whether the digital key registered based on the target digital key has been authenticated by the vehicle 20 between the time the vehicle 20 receives the reservation deletion request D41 and the time the completion notification M42 is generated.

[0164] Specifically, the target digital key is the second digital key DK2. The digital keys registered based on the target digital key are the third digital key DK3 and the fourth digital key DK4.

[0165] Therefore, if at least one of the third digital key DK3 and the fourth digital key DK4 is authenticated by the vehicle 20, the execution device 27 makes an affirmative determination in step S91. On the other hand, if neither of the third digital key DK3 nor the fourth digital key DK4 is authenticated by the vehicle 20, the execution device 27 makes a negative determination in step S91.

[0166] If the digital key registered based on the target digital key is not authenticated by the vehicle 20 (S91: NO), the execution device 27 proceeds to step S92. In step S92, the execution device 27 authorizes the transmission of the authentication notification M42. After that, the execution device 27 terminates the series of processes for determining whether to authorize the transmission of the authentication notification M42.

[0167] Subsequently, the management system 10 deletes the target digital key and the digital keys registered based on the target digital key by performing the processes from step S65 onward in the series of deletion management processes shown in Figure 8.

[0168] On the other hand, as shown in Figure 10, when the digital key registered based on the target digital key is authenticated by the vehicle 20 (S91: YES), the execution device 27 proceeds to step S93. In step S93, the execution device 27 stops sending the confirmation notification M42.

[0169] As a result, if the execution device 27 only performs the processing in step S93, the management server 70 will not receive the success notification M42 in the subsequent series of deletion management processes shown in Figure 8. Therefore, the management system 10 will not generate the deletion request D42 in accordance with the success notification M42. In other words, the execution device 27 will not delete the target digital key and the digital keys registered based on the target digital key by ceasing to send the success notification M42.

[0170] After the execution device 27 cancels sending 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 deletion of the target digital key, indicating that it has canceled sending the confirmation notification M42. The device 30 that requested the deletion of the target digital key is the first device 30A.

[0171] In other words, when the execution device 27 cancels sending the confirmation notification M42, the execution device 27 sends a cancellation notification M61 to the requesting device 30 that requested the deletion of the target digital key. Note that the reserved deletion request D41 is a request to delete the target digital key when the specified condition RC is met. After that, the execution device 27 proceeds to step S95.

[0172] In step S95, the execution device 27 determines whether the use of the authenticated digital key has been completed. The use of the authenticated digital key is completed when the vehicle 20 authenticates the digital key and then, again, the vehicle 20 becomes uncontrollable by that digital key.

[0173] If the execution device 27 determines that the use of the authenticated digital key is not yet complete (S95: NO), the execution device 27 repeats the process in step S95. On the other hand, if the execution device 27 determines that the use of the authenticated digital key is complete (S95: YES), the execution device 27 cancels the transmission of the completion notification M42 and proceeds to step S96.

[0174] In step S96, the execution device 27 sends a cancellation notice M62 to the management server 70 and the device 30 that requested the deletion of the target digital key, indicating that it is canceling the suspension of transmission of the confirmation notice M42. This device 30 is the first device 30A.

[0175] In other words, when the execution device 27 cancels the transmission of the confirmation notification M42, the execution device 27 sends a cancellation notification M62 to the management server 70 and the first device 30A. After that, the execution device 27 proceeds to step S97.

[0176] In step S97, the execution device 27 begins repeatedly performing the fade-out check until it determines that the specified condition RC has been met again. After that, the execution device 27 proceeds to step S98.

[0177] In step S98, the execution device 27 determines whether the specified condition RC is met by performing a fade-out check. If the specified condition RC is not met (S98: NO), the execution device 27 repeats the process in step S98. On the other hand, if the specified condition RC is met (S98: YES), the execution device 27 proceeds to step S99.

[0178] In step S99, the execution device 27 sends the success notification M42 to the management server 70. After that, the execution device 27 completes a series of processes to determine whether to approve the success notification M42.

[0179] <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 shown in Figure 8. Therefore, the management server 70 does not generate and 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 and the authentication information AT of the digital key registered based on the target digital key.

[0180] Furthermore, the management server 70 does not send a deletion request D43 to the device 30, which is a request to delete the key information DK indicating the target digital key and the key information DK indicating the digital keys registered based on the target digital key. As a result, the management server 70 does not cause the device 30 to delete the key information DK indicating the target digital key and the key information DK indicating the digital keys registered based on the target digital key.

[0181] In other words, since neither the authentication information AT nor the key information DK is deleted, the target digital key and the digital keys registered based on that target digital key remain in a usable state, i.e., registered state.

[0182] Subsequently, when the specified condition RC is met, the vehicle management device 26 sends a meeting notification M42 to the management server 70. When the management server 70 receives the meeting notification M42, the management server 70 performs the process shown in step S65 in Figure 8. When the vehicle 20 receives a deletion request D43, the vehicle 20 performs the process shown in step S67. After the process in step S67, the vehicle 20 sends a completion notification M43 to the management server 70. Subsequently, the management server 70 proceeds with the processes shown in step S68 and later in Figure 8.

[0183] In this case, the vehicle management device 26 deletes the authentication information AT in accordance with the deletion request D42 by processing step S67 shown in Figure 8. In other words, when the vehicle management device 26 accepts the deletion request D42, the management system 10 performs group deletion.

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

[0185] (2-1) If the digital key registered based on the target digital key is not authenticated by the vehicle 20, the vehicle management device 26 authorizes the transmission of the confirmation notification M42, and the management system 10 proceeds with a series of deletion management processes. As a result, the management system 10 deletes the group.

[0186] 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 confirmation 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, and the management system 10 does not delete the group. Therefore, the authentication information AT of the digital key registered based on the target digital key is not deleted.

[0187] Therefore, in the deletion management performed by the management system 10, the vehicle management device 26 can stop sending the confirmation notification M42, thereby allowing the management system 10 to stop deleting the target digital key and the digital keys registered based on the target digital key.

[0188] (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 deletion of the target digital key. 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.

[0189] (2-3) After the vehicle management device 26 stops sending the confirmation notification M42, when the use of the authenticated digital key is completed, the vehicle management device 26 cancels the suspension of sending the confirmation notification M42. Therefore, when the specified condition RC is met after the use of the authenticated digital key is completed, the management system 10 can avoid the target digital key not being deleted.

[0190] (2-4) When the vehicle management device 26 cancels the transmission of the confirmation notification M42, it sends a cancellation notification M62 to the first device 30A, which is the device 30 that requested the deletion of the target digital key. This allows the user of the first device 30A to know that the deletion management in the management system 10 has stopped and will resume.

[0191] (2-5) After the vehicle management device 26 has released the suspension of transmission of the confirmation notification M42, the vehicle management device 26 restarts the determination of whether the specified condition RC has been met. Therefore, after the use of the authenticated digital key is completed, when a digital key different from the target digital key and the digital keys registered based on the target digital key is authenticated, the vehicle management device 26 sends the confirmation notification M42 to the management server 70. As a result, the management server 70 can delete the target digital key and the digital keys registered based on the target digital key without having to receive the reservation deletion request D41 again.

[0192] <Third Embodiment> The management system 10 in the third embodiment will now be described with reference to the drawings. The main difference in the third embodiment compared to the first embodiment is that the management system 10 does not delete the target digital key on the condition that the management server 70 receives a deletion prohibition request D71. In the following, the differences from the first embodiment will be the main focus of the explanation, and the same points will be simplified or omitted.

[0193] In the third embodiment, after the device 30 to which the digital key registered based on the target digital key is registered receives the deletion notification M41, the device 30 can send a deletion prohibition request D71 to the management server 70 within a predetermined time. The deletion prohibition request D71 indicates that the vehicle 20 requests acceptance of the deletion request D42, regardless of whether the digital key registered based on the target digital key is authenticated or not.

[0194] As shown in Figure 11, after the management server 70 sends a deletion notification M41, the execution device 71 performs the process in step S101 when it receives a completion notification M42. In step S101, the execution device 71 determines whether or not it received a deletion prohibition request D71 between the time it sent the deletion notification M41 and the time it received the completion notification M42.

[0195] When the management server 70 receives the deletion prohibition request D71 (S101: YES), the execution device 71 proceeds to step S102. In step S102, the execution device 71 authorizes the generation of the deletion request D42. As a result, the execution device 71 sends the deletion request D42 to the vehicle 20 through the process shown in step S65 in Figure 8. After that, the execution device 71 terminates this series of processes.

[0196] Furthermore, if vehicle 20 receives only the deletion request D42 and not the compulsory acceptance request D72 described later, vehicle management device 26 performs the process shown in step S81 in Figure 9. If vehicle management device 26 makes a positive determination in step S81, vehicle management device 26 performs the process shown in step S83. In other words, provided that management server 70 receives the deletion prohibition request D71, if the digital key registered based on the target digital key is authenticated, management system 10 does not delete the target digital key.

[0197] On the other hand, as shown in Figure 11, if the management server 70 has not received the deletion prohibition request D71 (S101: NO), the execution device 71 proceeds to step S103. In step S103, the execution device 71 generates a forced acceptance request D72 and sends the generated forced acceptance request D72 to the vehicle 20.

[0198] The compulsory acceptance request D72 forces the vehicle 20 to accept the deletion request D42, regardless of whether the digital key registered based on the target digital key has been authenticated. The execution device 71 then proceeds to step S102. Therefore, if the processing in step S102 is executed after step S103, the management server 70 sends the compulsory acceptance request D72 and the deletion request D42 to the vehicle 20.

[0199] When vehicle 20 receives a deletion request D42 along with a compulsory acceptance request D72, the vehicle management device 26 performs the processing in step S82 regardless of the determination result in step S81 in the series of processes shown in Figure 9. That is, the vehicle management device 26 accepts the deletion request D42 regardless of whether the digital key registered based on the target digital key is authenticated or not. Therefore, when the management server 70 has not received a deletion prohibition request D71, the management system 10 performs group deletion even if the digital key registered based on the target digital key is authenticated.

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

[0201] (3-1) Provided that the management server 70 has received a deletion prohibition request D71, the management system 10 will not delete the target digital key if the digital key registered based on the target digital key is authenticated by the vehicle 20. When no deletion prohibition request D71 is sent to the management server 70 from any of the devices 30 to which the digital key registered based on the target digital key is registered, there is a high probability that the digital keys registered on these devices 30 can be deleted. Therefore, by making an acceptance decision, the management system 10 can avoid unnecessarily delaying the timing of deletion of digital keys that can be deleted.

[0202] <Fourth Embodiment> The management system 10 in the fourth embodiment will now be described with reference to the drawings. The fourth embodiment differs from the third embodiment in that a management exclusion notice M81 is sent from the device 30 to the management server 70 instead of a deletion prohibition request D71. Also, in the fourth embodiment, whether or not the management system 10 deletes the target digital key when deleting it through deletion management depends on whether or not the management server 70 has received the management exclusion notice M81.

[0203] In the fourth embodiment, after a device 30 registered with a digital key based on the target digital key receives a deletion notification M41, the device 30 can send a management exclusion notification M81 to the management server 70 within a predetermined time. The management exclusion notification M81 indicates that it is possible to exclude the device from management for group deletion. In other words, the management exclusion notification M81 is a notification that allows the target digital key to be deleted before the timing at which it is deleted by group deletion.

[0204] When the management server 70 receives the exclusion notice M81, the management server 70 determines whether or not to include it in the deletion management. The determination of whether or not to include it in the deletion management is whether or not it is a digital key that will be deleted from the group among the digital keys registered based on the target digital key. Specifically, the determination of whether or not to include it in the deletion management is whether or not it will be deleted by the deletion request D42 that deletes the authentication information AT.

[0205] As shown in Figure 12, after the management server 70 sends a deletion notification M41 by the process of step S62 shown in Figure 8, it performs the process of step S111. In the process of step S111, the execution device 71 determines whether or not it has received a management exclusion notification M81 from the third device 30C or the fourth device 30D.

[0206] When the execution device 71 receives the management exclusion notice M81 (S111:YES), the execution device 71 proceeds to step S112. In step S112, the execution device 71 sends an immediate deletion request D81 to the vehicle 20 regarding the digital key registered in the device 30 that sent the management exclusion notice M81.

[0207] For example, in step S111, when the management server 70 receives an exclusion notice M81 from the fourth device 30D, the execution device 71 sends an immediate deletion request D81 for the fourth digital key DK4 to the vehicle 20.

[0208] The immediate deletion request D81 indicates that the authentication information AT that authenticates the digital key to be immediately deleted is to be deleted, regardless of whether the digital key registered based on the target digital key has been authenticated by the vehicle 20 and whether the specified condition RC has been met. After the execution device 71 sends the immediate deletion request D81, the execution device 71 proceeds to step S113.

[0209] In step S113, the execution device 71 excludes the digital keys to be immediately deleted from the group deletion target. As a result, in the series of deletion management processes shown in Figure 8, the execution device 71 does not include the digital keys to be immediately deleted when deleting the target digital keys.

[0210] For example, in step S113, when the execution device 71 removes the fourth digital key DK4 from the scope of deletion management, the execution device 71 will delete only the third digital key DK3 when deleting the second digital key DK2. After that, the execution device 71 proceeds to step S114.

[0211] If the execution device 71 does not receive the management exclusion notice M81 (S111: NO), the execution device 71 proceeds to step S114 without performing the processing in steps S112 and S113.

[0212] In step S114, the execution device 71 determines whether or not it has received the success notification M42. If the execution device 71 has not received the success notification M42 (S114: NO), the execution device 71 returns to step S111.

[0213] On the other hand, when the execution device 71 receives the confirmation notification M42 (S114: YES), the execution device 71 proceeds to step S115. In step S115, the execution device 71 is authorized to generate the deletion request D42. The deletion request D42 is sent to the vehicle 20 by the process in step S65 shown in Figure 8. After that, the execution device 71 terminates this series of processes.

[0214] Furthermore, when vehicle 20 receives an immediate deletion request D81, vehicle management device 26 deletes the authentication information AT indicating the digital key to be immediately deleted. In particular, vehicle management device 26 deletes the authentication information AT indicating the digital key to be immediately deleted regardless of whether the digital key registered based on the target digital key has been authenticated by vehicle 20, and regardless of whether the specified condition RC has been met.

[0215] In this embodiment, the management server 70 generates a deletion request D43 for the digital keys to be immediately deleted during the process of step S68 shown in Figure 8. As a result, with respect to the authentication information AT, after the authentication information AT that authenticates the digital keys to be immediately deleted is deleted, the authentication information AT that authenticates the digital keys to be managed for deletion after acceptance is deleted. Subsequently, with respect to the key information DK, a deletion request D43 is sent from the management server 70 to each device 30 at the same time.

[0216] <Effects of the 4th Embodiment> In addition to the effects (1-1) to (1-7) of the first embodiment, the management system 10 in the fourth embodiment provides the following further effects.

[0217] (4-1) When the management server 70 receives the management exclusion notice M81, it excludes the digital key registered on the device 30 that sent the management exclusion notice M81 from the scope of deletion management. As a result, the management system 10 deletes the digital key registered on the device 30 that sent the management exclusion notice M81, regardless of whether the digital key registered based on the target digital key has been authenticated by the vehicle 20. Therefore, the management system 10 can prevent excessive delays in deletion of digital keys registered on the device 30 that sent the management exclusion notice M81, which are permitted to be deleted, by performing group deletions.

[0218] (4-2) When the management server 70 receives the management exclusion notice M81, it excludes the digital key registered on the device 30 that sent the management exclusion notice M81 from the scope of deletion management. The management system 10 then immediately deletes the authentication information AT indicating the digital key to be deleted, regardless of whether the digital key registered based on the target digital key has been authenticated by the vehicle 20, and regardless of whether the specified condition RC has been met. Therefore, the management system 10 can prevent a delay in the timing of deletion of digital keys registered on the device 30 that sent the management exclusion notice M81, which are permitted to be deleted, until the specified condition RC is met.

[0219] <Fifth Embodiment> The management system 10 in the fifth embodiment will now be described with reference to the drawings. The main difference in the fifth embodiment compared to the first embodiment is 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.

[0220] In the fifth embodiment, during the series of deletion management processes shown in Figure 8, when the management server 70 receives the establishment notification M42 from the vehicle 20, the management server 70 receives information from the vehicle 20 that identifies the authenticated digital key.

[0221] As shown in Figure 13, when the management server 70 receives the confirmation notification M42 along with information identifying the authenticated digital key, the execution device 71 performs the process in step S121. In step S121, the execution device 71 determines whether the authenticated digital key is a digital key registered based on the target digital key. Specifically, the execution device 71 refers to the database DB and determines whether the authenticated digital key is included in the digital keys registered based on the target digital key of the reservation deletion request D41.

[0222] If the authenticated digital key is a digital key registered based on the target digital key (S121: YES), the execution device 71 proceeds to step S122. In step S122, the execution device 71 sends a reservation deletion request D41 to the vehicle 20. As a result, the management server 70 terminates this series of processes. In other words, the management server 70 does not allow the generation of a deletion request D42 in the determination of whether or not to delete the authentication information AT in this case. Consequently, the management system 10 does not perform the group deletion in step S67.

[0223] After the reservation deletion request D41 is sent to the vehicle 20 in step S122, when the vehicle 20 receives the reservation deletion request D41, the vehicle management device 26 performs the process in step S63 again. If it determines that the specified condition RC has been met again, the vehicle management device 26 sends the confirmation notification M42 and information identifying the authenticated digital key to the management server 70.

[0224] Subsequently, when the management server 70 receives the confirmation notification M42 and the authenticated digital key, the execution device 71 performs the process of step S121 again. In this way, through the processes of steps S121 and S122, the management server 70 does not generate a deletion request D42, but instead resends the reservation deletion request D41, causing the vehicle 20 to repeat the processes of steps S63 and S64 shown in Figure 8.

[0225] On the other hand, if the authenticated digital key is not a digital key registered based on the target digital key (S121:NO), the execution device 71 proceeds to step S123.

[0226] In step S123, the execution device 71 authorizes the generation of the deletion request D42. This terminates the current series of processes for the execution device 71. Once the execution device 71 authorizes the generation of the deletion request D42 in step S123, the execution device 71 performs the process in step S65. Subsequently, the management system 10 performs the group deletion by carrying out the processes from step S65 onward.

[0227] <Effects of the Fifth Embodiment> In addition to the effects (1-1) to (1-2) of the first embodiment, the management system 10 in the fifth embodiment provides the following further effects.

[0228] (5-1) The management server 70 determines whether the authenticated digital key is a digital key registered based on the target digital key. When the management server 70 determines that the authenticated digital key is a digital key registered based on the target digital key, that is, when the digital key registered based on the target digital key is authenticated by the vehicle 20, the management system 10 deletes the group. On the other hand, when the management server 70 determines that the authenticated digital key is not a digital key registered based on the target digital key, the management system 10 does not delete the group. That is, when the digital key registered based on the target digital key is not authenticated by the vehicle 20, the management system 10 does not delete the group.

[0229] In this way, the management server 70 determines whether or not to delete the group. Therefore, even if the vehicle management device 26 simply deletes the authentication information AT in accordance with the deletion request D42, the management system 10 can manage whether or not to delete the group depending on the timing of when the management server 70 sends the deletion request D42.

[0230] <Sixth Embodiment> The management system 10 in the sixth embodiment will now be described with reference to the drawings. The main difference in the sixth 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 explained in a simplified or omitted manner.

[0231] As shown in Figure 14, the management system 10 performs deletion management, including group deletion. In the deletion management process, the first device 30A sends a reserved deletion request D41 to the management server 70 after performing the processing in step S61.

[0232] After performing the processing in step S62, the management server 70 sends a deletion notification 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 to the vehicle 20 information identifying the digital key to be deleted by group deletion.

[0233] When vehicle 20 determines that the specified condition RC has been met by performing the process in step S63, vehicle 20 proceeds to step S131. In step S131, 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 determines in step S131 to permit the deletion of the authentication information AT, that is, to delete the group, the vehicle 20 proceeds to step S67. Since the processes from step S67 onward are the same as in the first embodiment, a detailed explanation will be omitted.

[0234] <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 15, 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 S141.

[0235] In step S141, the execution device 27 determines whether the digital key registered based on the target digital key has been authenticated by the vehicle 20. More specifically, the execution device 27 determines whether the digital key registered based on the target digital key has been authenticated by the vehicle 20 between the time the vehicle 20 receives the reservation deletion request D41 and the specified condition RC is met.

[0236] Specifically, the target digital key is the second digital key DK2. The digital keys registered based on the target digital key are the third digital key DK3 and the fourth digital key DK4.

[0237] Therefore, if at least one of the third digital key DK3 and the fourth digital key DK4 is authenticated by the vehicle 20, the execution device 27 makes an affirmative determination in step S91. On the other hand, if neither of the third digital key DK3 nor the fourth digital key DK4 is authenticated by the vehicle 20, the execution device 27 makes a negative determination in step S91.

[0238] If the digital key registered based on the target digital key is not authenticated by the vehicle 20 (S141: NO), the execution device 27 proceeds to step S142. In step S142, the execution device 27 authorizes the deletion of the authentication information AT. After that, the execution device 27 completes the series of processes for determining whether or not to delete the authentication information AT. Subsequently, the management system 10 performs the group deletion by performing the process in step S67 of the series of deletion management processes shown in Figure 14.

[0239] On the other hand, as shown in Figure 15, when the digital key registered based on the target digital key is authenticated by the vehicle 20 (S141: YES), the execution device 27 proceeds to step S143. In step S143, the execution device 27 prohibits the deletion of the authentication information AT.

[0240] As a result, if the execution device 27 only performs the processing in step S143, the management system 10 will not delete the authentication information AT in the subsequent series of deletion management processes shown in Figure 14. Therefore, the management system 10 will not delete the group. In other words, because the execution device 27 does not delete the authentication information AT, it does not delete the target digital key and the digital keys registered based on the target digital key.

[0241] After the execution device 27 prohibits the deletion of the authentication information AT, the execution device 27 proceeds to step S144. In step S144, the execution device 27 determines whether the use of the authenticated digital key has been completed. The use of the authenticated digital key is completed when the vehicle 20 authenticates the digital key and then, again, the vehicle 20 becomes uncontrollable by that digital key.

[0242] If the execution device 27 determines that the use of the authenticated digital key is not yet complete (S144: NO), the execution device 27 repeats the process in step S144. On the other hand, if the execution device 27 determines that the use of the authenticated digital key is complete (S144: YES), the execution device 27 proceeds to step S145.

[0243] In step S145, the execution device 27 starts repeatedly performing the fade-out determination until it determines that the specified condition RC has been met. After that, the execution device 27 proceeds to step S146.

[0244] In step S146, the execution device 27 determines whether the specified condition RC is met by performing a fade-out check. If the specified condition RC is not met (S146: NO), the execution device 27 repeats the process in step S146.

[0245] When the specified condition RC is met (S146: YES), the execution device 27 proceeds to step S147. In step S147, the execution device 27 permits the deletion of the authentication information AT. After that, the execution device 27 terminates the series of processes for determining whether to permit the deletion of the authentication information AT.

[0246] In the sixth embodiment, the execution device 27, which is a computer, performs group deletion by executing the vehicle program PV, thereby executing the processes in steps S65, S131, and S67. In other words, the vehicle program PV is a program that causes the execution device 27 to perform group deletion.

[0247] <Sixth Embodiment> In addition to the effects (1-1) to (1-2) of the first embodiment, the management system 10 in the sixth embodiment provides the following further effects.

[0248] (6-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 group by deleting the authentication information AT. Therefore, in the sixth embodiment, after the vehicle 20 receives the reservation deletion request D41, the vehicle management device 26 determines whether or not to delete the group and then deletes the group without communicating with the management server 70. Thus, the vehicle management device 26 alone can manage group deletion.

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

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

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

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

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

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

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

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

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

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

[0259] The management system 10 only needs to perform group deletion. Therefore, the management system 10 does not need to have a management server 70. The management system 10 only needs to perform the following: cause group deletion, determine whether or not to delete the group, and delete the group. In the first embodiment, the management server 70 causes group deletion, while the vehicle management device 26 determines whether or not to delete the group and deletes the group, but it is not limited to this.

[0260] For example, the vehicle management device 26 may perform the actions of causing a group to be deleted, deciding whether or not to delete the group, and actually deleting the group. 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.

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

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

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

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

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

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

[0267] • The configuration of information included in key information DK is not limited to the example of the above embodiment. For example, owner key information DKO does not need to include slot identification information ST4. Further, for example, key information DK may include information indicating the type of a digital key. The type of the digital key is information indicating, for example, one of an owner key KO, a friend key KF, and a non-friend key KN.

[0268] • Database DB may include information indicating the type of device 30. The type of device 30 is information indicating, for example, any one of a smartphone, a smartwatch, and a predetermined server as in the above-described modification.

[0269] • The structure of data DA in database DB is not limited to the examples of the above respective embodiments. The database DB only needs to include information necessary for management by the management server 70 in the management system 10.

[0270] • In database DB, authorities are not uniformly defined according to the type of digital key, and may be set for each digital key. Further, no authority may be defined in database DB.

[0271] <Series of processes for registering digital key> • The series of processes for registering owner key KO is not limited to the examples of the above respective embodiments. For example, even if pairing through the process of step S12 is not performed, owner device 40 may cause vehicle 20 and first device 30A to transmit and receive information such as generated data DC via management server 70, thereby storing owner key information DKO. The series of processes for registering owner key KO may be modified appropriately in accordance with the structure of information included in owner key information DKO and the structure of information included in authentication information AT.

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

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

[0274] 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). In this case, the target digital key may be an owner key (KO), and the digital key registered based on the target digital key may be a friend key (KF).

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

[0276] 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. Also, for example, the target digital key may be the owner key KO.

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

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

[0279] <Fade-out detection> 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.

[0280] <Determination of whether or not to delete the group> Whether or not to delete a group is determined, for example, in the first embodiment by the acceptance of the deletion request D42, in the second embodiment by the permission to send the establishment notification M42, and in the fifth embodiment by the permission to generate the deletion request D42. Regardless of the examples in each embodiment above, whether or not to delete a group can be determined by whether or not the digital key registered based on the target digital key has been authenticated by the vehicle 20. In other words, the management system 10 can avoid deleting a group by stopping the transmission and generation of signals that are communicated until the group deletion in the deletion management is performed.

[0281] <Deletion Request Acceptance Decision> After the vehicle management device 26 releases its rejection of the deletion request D42, the vehicle management device 26 does not need to start determining whether the specified condition RC has been met. For example, in the first embodiment, the series of processes shown in Figure 8 may start from step S61 when the owner device 40 generates the reservation deletion request D41 again.

[0282] When the vehicle management device 26 has released its decision to reject the deletion request D42, it does not need to send a release notification M52. In other words, in the first embodiment, the vehicle management device 26 may omit the processing in step S86 when determining whether to accept the deletion request D42.

[0283] When the use of the digital key registered based on the target digital key is completed, the vehicle management device 26 does not have to release the rejection of the deletion request D42. For example, in the first embodiment, after processing in step S84, the vehicle management device 26 does not have to delete the group in response to the reservation deletion request D41 by completing the series of processes shown in Figure 9.

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

[0285] <Determination of permission to send confirmation notice> When the vehicle management device 26 cancels the suspension of sending the confirmation notification M42, the vehicle management device 26 does not need to start determining whether the specified condition RC has been met. For example, in the second embodiment, the series of processes shown in Figure 8 may start from step S61 when the owner device 40 generates a reservation deletion request D41 again.

[0286] When the vehicle management device 26 releases the suspension of sending the confirmation notice M42, the vehicle management device 26 does not need to send the release notice M62. In other words, in the second embodiment, the vehicle management device 26 may omit the processing in step S96 when determining whether to allow the sending of the confirmation notice M42.

[0287] When the use of the digital key registered based on the target digital key is completed, the vehicle management device 26 does not need to cancel the suspension of sending the completion notification M42. For example, in the second embodiment, after processing in step S94, the vehicle management device 26 does not need to delete the group in response to the reservation deletion request D41 by terminating the series of processes shown in Figure 10.

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

[0289] <Delete Group> In the third embodiment, the management system 10 performs group deletion on the condition that it receives a deletion prohibition request D71, but the conditions for performing group deletion are not limited to this. For example, when a digital key is registered based on the target digital key, the user may set whether or not to perform group deletion. In this case, the management system 10 may perform group deletion on the additional condition that it has been set to perform group deletion.

[0290] In the fourth embodiment, the management system 10 deletes the digital keys excluded from the digital keys to be deleted by group deletion, regardless of whether the digital key registered based on the target digital key has been authenticated by the vehicle 20. In this case, the management system 10 may delete the digital keys excluded from the digital keys to be deleted by group deletion when the specified condition RC is met.

[0291] ·When the management server 70 receives the management exclusion notification M81, it is not required to exclude the digital key to be immediately deleted from the deletion targets of the group deletion. In the fourth embodiment, the management system 10 may omit the process of step S113.

[0292] ·In each of the above embodiments, in the group deletion, the management system 10 may delete the key information DK of the target digital key and the key information DK of a digital key registered based on the target digital key.

[0293] Further, for example, in the group deletion, the management system 10 may delete the authentication information AT of the target digital key, and also delete the key information DK of a digital key registered based on the target digital key.

[0294] [Supplementary Note] The technical ideas that can be grasped from the above embodiments and modified examples are described below. [Supplementary Note 1] A management system that performs group deletion for deleting a digital key registered based on a target digital key when deleting the target digital key among a plurality of digital keys for a vehicle when a predetermined condition is satisfied, wherein the management system does not perform the group deletion when the digital key registered based on the target digital key has been authenticated by the vehicle, and performs the group deletion when the digital key registered based on the target digital key has not been authenticated by the vehicle.

[0295] [Supplementary Note 2] The management system according to Supplementary Note 1, wherein the predetermined condition is that a digital key different from the target digital key among the plurality of digital keys is authenticated by the vehicle.

[0296] [Note 3] The management system according to Note 1 or Note 2, 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 plurality of digital keys, wherein when the specified conditions are met, the management server sends a request to the vehicle to delete information about the digital keys to be deleted by the group deletion, and if the digital key registered based on the target digital key is not authenticated by the vehicle, the vehicle management device accepts the request to delete information about the digital keys to be deleted by the group deletion and performs the group deletion, and if the digital key registered based on the target digital key is authenticated by the vehicle, the vehicle management device rejects the request to delete information about the digital keys to be deleted by the group deletion that was received before the use of the digital key was completed and does not perform the group deletion.

[0297] [Note 4] The management system according to Note 3, wherein when the vehicle management device refuses a request to delete the information relating to the target digital key, the vehicle management device sends a notification to the device that made the request to delete the information relating to the target digital key indicating that the request to delete the information relating to the target digital key has been refused.

[0298] [Note 5] The management system according to Note 3 or Note 4, wherein when the use of a digital key registered based on the target digital key is completed, the vehicle management device releases the restriction on refusing a request to delete information related to the target digital key.

[0299] [Note 6] The management system described in Note 5, wherein when the vehicle management device has released its restriction on refusing the request to delete the information related to the target digital key, it sends a notification to the device that made the request to delete the information related to the target digital key indicating that the restriction has been released.

[0300] [Note 7] The management system according to Note 5 or Note 6, wherein after the vehicle management device has released its refusal to refuse a request to delete information regarding a digital key registered based on the target digital key, the vehicle management device begins to determine whether the specified conditions have been met.

[0301] [Note 8] The management system according to Note 1, 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 plurality of digital keys, wherein when the specified conditions are met, the vehicle management device sends a notification to the management server indicating that the specified conditions have been met, and when the management server receives the notification indicating that the specified conditions have been met, the management server sends a request to the vehicle to delete the information about the digital keys to be deleted by the group deletion, thereby performing the group deletion, and when a digital key registered based on the target digital key is authenticated by the vehicle, the vehicle management device stops sending a notification to the management server indicating that the specified conditions have been met, thereby not performing the group deletion, until the use of the digital key registered based on a registration request from the device on which the target digital key is registered is completed.

[0302] [Note 9] The management system according to Note 8, wherein when the vehicle management device stops transmitting a notification indicating that the specified conditions have been met, the vehicle management device transmits a notification to the device that requested the deletion of the information regarding the target digital key indicating that it has stopped transmitting a notification indicating that the specified conditions have been met.

[0303] [Note 10] The management system described in Note 8 or Note 9, wherein when the use of a digital key registered based on the aforementioned target digital key is completed, the vehicle management device releases the suspension of sending a notification indicating that the aforementioned specified conditions have been met.

[0304] [Note 11] The management system according to Note 10, wherein when the vehicle management device lifts the suspension of sending a notification indicating that the specified conditions have been met, the vehicle management device sends a notification to the device that requested the deletion of the information regarding the target digital key indicating that the suspension of sending a notification indicating that the specified conditions have been met is lifted.

[0305] [Note 12] The management system according to Note 10 or Note 11, wherein when the vehicle management device releases the suspension of transmitting a notification indicating that the specified conditions have been met, the vehicle management device starts determining whether or not the specified conditions have been met.

[0306] [Note 13] A management system according to any one of Notes 1 to 12, comprising a management server for managing the multiple digital keys, wherein when the management server receives a notification from a device on which a digital key registered based on the target digital key is registered, indicating that the deletion of the digital key is permitted, the digital key registered on the device that sent the notification indicating that the deletion of the digital key is permitted is excluded from the digital keys to be deleted by the group deletion.

[0307] [Note 14] The management system described in Note 13, which deletes digital keys that have been excluded from the digital keys to be deleted by the group deletion, regardless of whether the digital key registered based on the target digital key has been authenticated by the vehicle and regardless of whether the specified conditions have been met.

[0308] [Note 15] A management system according to any one of Notes 1 to 14, comprising a management server for managing the multiple digital keys, wherein the management server does not perform the group deletion when a digital key registered based on a registration request from the target digital key is authenticated by the vehicle, provided that the management server receives a request from a device on which a digital key registered based on the target digital key is registered to prohibit the deletion of the target digital key. [Explanation of Symbols]

[0309] 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 RC…Specified conditions

Claims

1. A management system that deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and which deletes a group of digital keys registered based on the target digital key, If the digital key registered based on the aforementioned target digital key is authenticated by the vehicle, the group deletion will not be performed. The group deletion is performed if the digital key registered based on the aforementioned target digital key is not authenticated by the vehicle. Management system.

2. 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.

3. The system comprises a management server that manages the plurality of digital keys, and a vehicle management device installed in the vehicle that stores information about the plurality of digital keys. When the aforementioned conditions are met, the management server sends a request to the vehicle to delete the information regarding the digital key to be deleted by the group deletion. If the digital key registered based on the aforementioned target digital key is not authenticated by the vehicle, the vehicle management device accepts a request to delete information related to the digital key to be deleted by the group deletion, and performs the group deletion. If a digital key registered based on the aforementioned target digital key is authenticated by the vehicle, the vehicle management device will not perform the group deletion by refusing to delete the information regarding the digital key to be deleted by the group deletion that was received before the use of the digital key was completed. The management system according to claim 1.

4. When the vehicle management device rejects the request to delete the information related to the target digital key, the vehicle management device sends a notification to the device that made the request to delete the information related to the target digital key indicating that the request to delete the information related to the target digital key has been rejected. The management system according to claim 3.

5. When the use of the digital key registered based on the aforementioned target digital key is completed, the vehicle management device releases its restriction on rejecting the request to delete information related to the aforementioned target digital key. The management system according to claim 3.

6. When the vehicle management device lifts its restriction on rejecting a request to delete information related to the target digital key, it sends a notification to the device that made the request to delete the information related to the target digital key indicating that the restriction has been lifted. The management system according to claim 5.

7. After the vehicle management device has released its refusal to reject the request to delete the information regarding the digital key registered based on the target digital key, the vehicle management device begins to determine whether the specified conditions have been met. The management system according to claim 5.

8. The system comprises a management server that manages the plurality of digital keys, and a vehicle management device installed in the vehicle that stores information about the plurality of digital keys. When the aforementioned conditions are met, the vehicle management device sends a notification to the management server indicating that the aforementioned conditions have been met. When the management server receives a notification indicating that the specified conditions have been met, the management server performs the group deletion by sending a request to the vehicle to delete the information regarding the digital key to be deleted by the group deletion. If a digital key registered based on the aforementioned target digital key is authenticated by the vehicle, the vehicle management device will not delete the group by ceasing to send a notification to the management server indicating that the specified conditions have been met, until the use of the digital key registered based on a registration request from the device on which the target digital key was registered is completed. The management system according to claim 1.

9. When the vehicle management device stops sending a notification indicating that the specified conditions have been met, the vehicle management device sends a notification to the device that requested the deletion of the information regarding the target digital key indicating that it has stopped sending notifications indicating that the specified conditions have been met. The management system according to claim 8.

10. When the use of the digital key registered based on the aforementioned target digital key is completed, the vehicle management device will release the suspension of sending the notification indicating that the aforementioned specified conditions have been met. The management system according to claim 8.

11. When the vehicle management device resumes sending notifications indicating that the specified conditions have been met, the vehicle management device sends a notification to the device that requested the deletion of the information regarding the target digital key indicating that it has resumed sending notifications indicating that the specified conditions have been met. The management system according to claim 10.

12. When the vehicle management device resumes sending notifications indicating that the specified conditions have been met, the vehicle management device begins determining whether or not the specified conditions have been met. The management system according to claim 10.

13. It includes a management server that manages the aforementioned multiple digital keys, When the management server receives a notification from a device where a digital key registered based on the target digital key is registered, indicating that the deletion of the digital key is permitted, the management server excludes the digital key registered on the device that sent the notification indicating permission for the deletion of the digital key from the digital keys to be deleted by the group deletion. The management system according to claim 1.

14. Regardless of whether the digital key registered based on the aforementioned target digital key has been authenticated by the vehicle, and regardless of whether the aforementioned specified conditions have been met, the digital keys excluded from the digital keys to be deleted by the group deletion will be deleted. The management system according to claim 13.

15. It includes a management server that manages the aforementioned multiple digital keys, The management server will not delete the group if the digital key registered based on the registration request from the target digital key is authenticated by the vehicle, provided that the management server receives a request from the device where the digital key registered based on the target digital key is registered to prohibit the deletion of the target digital key. The management system according to claim 1.

16. The vehicle is equipped with multiple digital keys that can be used for the vehicle, A vehicle management device that, when a predetermined set of conditions is met, deletes a target digital key from among multiple digital keys for the vehicle, and performs a group deletion that deletes the digital keys registered based on the target digital key, If the digital key registered based on the aforementioned target digital key is authenticated by the vehicle, the group deletion will not be performed. The group deletion is performed if the digital key registered based on the aforementioned target digital key is not authenticated by the vehicle. Vehicle management system.

17. A deletion management method performed by a management system including a computer for group deletion, which deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and which deletes digital keys registered based on the target digital key, If the digital key registered based on the aforementioned target digital key is authenticated by the vehicle, the group deletion will not be performed. The group deletion is performed if the digital key registered based on the aforementioned target digital key is not authenticated by the vehicle. Deletion management method.

18. A program to be executed by a computer included in a management system that performs group deletion, which deletes a target digital key from among multiple digital keys for a vehicle when predetermined conditions are met, and which deletes the digital keys registered based on the target digital key, To the aforementioned computer, The system is configured to perform the following actions: if the digital key registered based on the target digital key is authenticated by the vehicle, the group deletion will not be performed; however, if the digital key registered based on the target digital key is not authenticated by the vehicle, the group deletion will be performed. program.

Images