Management server and notification program

Abstract

We provide a management server that can identify digital keys that have been requested to be deleted and are in a fade-out state. [Solution] When the management server 70 receives a deletion reservation D41, it stores the state of the third digital key DK3 to which the deletion reservation D41 was made as a fade-out state. The management server 70 sends a pending notification M41 to the first device 30A and the third device 30C, which belong to users other than the user of the second device 30B, the source of the deletion reservation D41. The pending notification M41 is a notification indicating that the state of the third digital key DK3 to which the deletion reservation D41 was made is a fade-out state.

Description

[Technical Field]

[0001] The present invention relates to a management server and a notification program. [Background Art]

[0002] Patent Document 1 discloses a technology for a digital key system that uses a device such as a smartphone as a vehicle key. The digital key system causes a vehicle to store information related to a digital key. The digital key system causes a device to store information related to a digital key. Accordingly, the vehicle can be used using the device registered as a digital key without requiring a vehicle-exclusive key. Furthermore, in the digital key system, a registration request for causing another person's device to function as a digital key is made through communication between the device storing information related to the digital key and the other person's device. Accordingly, the digital key system is configured to be capable of registering the other person's device as a digital key in the vehicle. That is, a new separate digital key can be generated from an existing digital key. The digital key system allows a user to lend the vehicle to another person without requiring the handover of a vehicle-exclusive key. [Prior Art Literature] [Patent Literature]

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

[0004] The digital key system described in Patent Document 1 may register multiple digital keys for the same vehicle. When a request is made to delete a digital key registered to a vehicle, the management server may delete the digital key if predetermined conditions are met. In this case, among the multiple users of the digital key system, users other than the user who requested the deletion of the digital key cannot be aware that there is a digital key that is in a state to be deleted, provided that the predetermined conditions are met. [Means for solving the problem]

[0005] The management server for solving the above problem is a management server that communicates with a vehicle and multiple devices and manages information about digital keys that are available for registration with the vehicle. The management server includes a processing circuit. When the processing circuit receives a deletion request from a device that stores information about the digital keys registered with the vehicle to delete a digital key registered with the same vehicle, it stores the state of the digital key to be deleted as a fade-out state in which the digital key will be deleted if a predetermined condition is met, and sends a pending notification to devices belonging to users other than the user of the device that sent the deletion request, among the multiple devices that store information about the digital keys registered with the same vehicle, indicating that the state of the digital key to be deleted is the fade-out state.

[0006] The notification program for solving the above problem is a notification program stored in the storage device of a device in a digital key system that stores information about digital keys that can be registered to a vehicle in multiple devices, and allows the multiple devices to function as digital keys registered to the vehicle, and is executed by the processing circuit of the device.When the device in which the notification program is stored in the storage device sends a deletion request to delete a digital key registered to the same vehicle that the device can use as a digital key, the notification program causes the processing circuit of the device to execute a process to send a pending notification to a device belonging to a user other than the user of the device that sent the deletion request, among the multiple devices that store information about digital keys registered to the same vehicle, indicating that the state of the digital key to be deleted is a fade-out state in which the digital key will be deleted if a predetermined condition is met.

[0007] The notification program for solving the above problem is a notification program stored in the storage device of a digital key system that causes multiple devices to store information about digital keys that can be registered to a vehicle, and to function as digital keys registered to the vehicle, and is executed by the processing circuit of the device. When the device in which the notification program is stored in the storage device receives a pending notification indicating that the state of the digital key of the device is a fade-out state in which the digital key will be deleted when a predetermined condition is met, the notification program causes the processing circuit of the device to execute a process to send the pending notification to a device belonging to a user other than the user of the device that sent the request to delete the digital key of the device, among the multiple devices that store information about digital keys registered to the same vehicle as the vehicle in which the device can be used as a digital key. [Effects of the Invention]

[0008] The management server and notification program described above can make users of devices other than the one that sent the deletion request aware of digital keys that have been requested to be deleted and are in a fade-out state. [Brief explanation of the drawing]

[0009] [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 configuration of the owner device, which is a virtual machine built on the server. [Figure 3] Figure 3 is a schematic diagram of the contract information stored in the management server's memory. [Figure 4] Figure 4 is a schematic diagram showing the owner key information of the first embodiment. [Figure 5] Figure 5 is a schematic diagram showing the share key information of the first embodiment. [Figure 6] Figure 6 is a schematic diagram showing the data in the database of the first embodiment. [Figure 7] Figure 7 is a sequence diagram of the owner key registration process when the owner device is a portable device. [Figure 8] Figure 8 is a sequence diagram of the owner key registration process when the owner device is a virtual device. [Figure 9] Figure 9 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 10] Figure 10 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 11] Figure 11 is an explanatory diagram illustrating a series of processes performed by the management system of the first embodiment to delete a digital key. [Figure 12] Figure 12 is a flowchart showing the series of processes performed by the management server in generating the pending notification shown in Figure 11. [Figure 13]FIG. 13 is an example of an image displayed on a device notified of a pending notification. [Figure 14] FIG. 14 is an explanatory diagram showing a series of processes performed by the management system in the deletion process shown in FIG. 11. [Figure 15] FIG. 15 is a schematic diagram showing a mode in which the management server according to a modification of the first embodiment transmits a notification. [Figure 16] FIG. 16 is an explanatory diagram showing a series of processes for deleting a digital key performed by the management system according to the second embodiment. [Figure 17] FIG. 17 is an example of an image displayed on a device notified of a confirmation request. [Figure 18] FIG. 18 is an explanatory diagram showing a continuation of the process of FIG. 16. [Figure 19] FIG. 19 is an explanatory diagram showing a series of processes for deleting a digital key performed by the management system according to the third embodiment. [Figure 20] FIG. 20 is a flowchart showing a series of processes performed by the management server in generating the pending notification shown in FIG. 19. [Figure 21] FIG. 21 is a schematic diagram showing the configuration of a friend device according to the fourth, fifth and ninth embodiments. [Figure 22] FIG. 22 is an explanatory diagram showing a series of processes for deleting a digital key performed by the management system according to the fourth embodiment. [Figure 23] FIG. 23 is a flowchart showing a series of processes that a notification program causes an execution device of a friend device to execute in generating the pending notification shown in FIG. 22. [Figure 24] FIG. 24 is a schematic diagram showing a mode in which a friend device according to a modification of the fourth embodiment transmits a notification. [Figure 25] FIG. 25 is an explanatory diagram showing a series of processes for deleting a digital key performed by the management system according to the fifth embodiment. [Figure 26] FIG. 26 is an explanatory diagram showing a continuation of the process of FIG. 25. [Figure 27] FIG. 27 is a schematic diagram showing the configuration of an owner device according to the sixth embodiment. [Figure 28] Figure 28 is an explanatory diagram illustrating a series of processes performed by the management system of the sixth embodiment to delete a digital key. [Figure 29] Figure 29 is a schematic diagram showing the configuration of the non-friendly device according to the seventh and eighth embodiments. [Figure 30] Figure 30 is an explanatory diagram illustrating a series of processes performed by the management system of the seventh embodiment to delete a digital key. [Figure 31] Figure 31 is a flowchart showing the series of processes that the notification program has the execution device of the non-friendly device perform in generating the pending notification shown in Figure 30. [Figure 32] Figure 32 is a schematic diagram showing how a non-friend device sends a notification in a modified example of the seventh embodiment. [Figure 33] Figure 33 is an explanatory diagram illustrating a series of processes performed by the management system of the eighth embodiment to delete a digital key. [Figure 34] Figure 34 is an explanatory diagram showing the continuation of the process shown in Figure 33. [Figure 35] Figure 35 is an explanatory diagram illustrating a series of processes performed by the management system of the ninth embodiment to delete a digital key. [Figure 36] Figure 36 is a flowchart showing the series of processes that the notification program has the execution device of the friend device perform in generating the pending notification shown in Figure 35. [Modes for carrying out the invention]

[0010] (First Embodiment) The management system equipped with the management server 70 in the first embodiment will be described below with reference to Figures 1 to 14.

[0011] <Overview of Management System 10> As shown in Figure 1, the management server 70 is one of the devices that make up the management system 10. The management server 70 manages information about multiple digital keys that are registrable for the vehicle 20 by communicating with the vehicle 20 and multiple devices 30. Regarding digital keys, there is a standard set by the Car Connectivity Consortium (CCC). The matters concerning digital keys in this embodiment are assumed to comply with the CCC, but are also applicable to standards and systems other than the CCC. The management system 10 comprises the vehicle 20, multiple devices 30, a device server 60, and a management server 70.

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

[0013] The communication module 21 communicates with the management server 70 via a wireless communication line. The HMI 22 includes an input device and a display device. The input device receives user inputs from the vehicle 20 and inputs signals indicating the inputs to the vehicle 20. The display device presents information to the user through images and sounds, etc. The display device is, for example, a monitor and a speaker.

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

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

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

[0017] 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. The execution device 36 is a processing circuit.

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

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

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

[0021] The device program PD includes, for example, a device application and a digital key framework. The device application is an application for storing and deleting key information DK. The digital key framework is a program that provides functions for pairing device 30 and sharing digital keys using APIs provided by the OS. The execution device 36 executes the device program PD to perform processes related to storing and deleting key information DK.

[0022] Multiple devices 30 include devices 30 that do not store key information DK. For example, devices 41, 42, and 43 are devices 30 that do not store key information DK. Multiple devices 30 include devices 30 that do not store device program PD. For example, devices 41, 42, and 43 are devices 30 that do not store device program PD.

[0023] Multiple devices 30 include multiple devices 40BO belonging to the owners of the vehicles 20, and multiple shared devices 50. Owner device 40 is one of the devices 40BO belonging to the owners of the vehicles 20. 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] The device 40BO belonging to the owner of vehicle 20 is not limited to owner device 40. For example, device 41 shown in Figure 1 is device 40BO belonging to the owner of vehicle 20. The device 40BO belonging to the owner of vehicle 20 is an information processing terminal owned by the owner of vehicle 20. An information processing terminal is, for example, a personal computer, a smartphone, a tablet, or a wearable device. Examples of wearable devices include a ring-type device worn on the wrist or a necklace-type device worn around the neck. Of the multiple shared devices 50, the shared device 50 owned by the owner of vehicle 20 is also a device 40BO belonging to the owner of vehicle 20. There is no limit to one device 40BO belonging to the owner of vehicle 20 other than owner device 40.

[0025] Device 40BO belonging to the owner of vehicle 20 does not need to store owner key information DKO. For example, device 41 does not store owner key information DKO. Device 40BO belonging to the owner of vehicle 20 does not need to store key information DK. For example, device 41 does not store key information DK. Device 40BO belonging to the owner of vehicle 20 does not need to store device program PD. For example, device 41 does not store device program PD.

[0026] Multiple devices 30 include not only personal devices such as smartphones, but also virtual machines built on server 80. Hereafter, the owner device 40, which is a personal device, will be referred to as mobile device 40M, and the owner device 40, which is a virtual machine, will be referred to as virtual device 40V.

[0027] As shown in Figure 2, the virtual device 40V comprises a communication module 31, an execution device 36, and a storage device 37. The communication module 31, execution device 36, and storage device 37 of the virtual device 40V can be a virtual device that uses a portion of the area of ​​the communication module 31, execution device 36, and storage device 37 of the server 80. The storage device 37 stores a device program PD and key information DK, similar to the mobile device 40M. The execution device 36 executes the device program PD to perform processing related to the storage and deletion of key information DK.

[0028] The virtual device 40V is device 40BO, which belongs to the owner of vehicle 20. For example, if a rental company and a sharing company are the owners of vehicle 20, device 40BO, which belongs to the owner of vehicle 20, may be the virtual device 40V.

[0029] As shown in Figure 3, the management server 70 stores contract information CI in the storage device 72. The contract information CI is stored in the storage device 72 when the owner completes the contract for the vehicle 20. The contract information CI includes classification information TI, which is information indicating whether the owner device 40 is a virtual device 40V or a portable device 40M. The contract information CI includes owner device identification information that identifies the owner device 40 and a vehicle ID that identifies the vehicle 20. When the owner device 40 is a virtual device 40V, the owner device identification information is information that identifies the virtual device 40V and the server 80 in which the virtual device 40V resides. This owner device identification information is, for example, the IP addresses of the virtual device 40V and server 80, and the authentication information of the certificate issued by server 80. When the owner device 40 is a portable device 40M, the owner device identification information is information that identifies the portable device 40M and the device server 60 to which the portable device 40M belongs. This owner device identification information includes, for example, the IP addresses of mobile device 40M and device server 60, and the serial code of the personal device that is mobile device 40M.

[0030] As shown in Figure 4, 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.

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

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

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

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

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

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

[0037] Friend device 51 is a device 51BF belonging to the user of friend device 51. A device 51BF belonging to the user of friend device 51 is an information processing terminal owned by the user of friend device 51. A device 51BF belonging to the user of friend device 51 does not have to store friend key information DKF. For example, device 42 does not store friend key information DKF. A device 51BF belonging to the user of friend device 51 does not have to store key information DK. For example, device 42 does not store key information DK. A device 51BF belonging to the user of friend device 51 does not have to store device program PD. For example, device 42 does not store device program PD. Note that there is not limited to one device 51BF belonging to the user of friend device 51 other than friend device 51.

[0038] A non-friendly device 52 is a device 52BNF belonging to the user of non-friendly device 52. A device 52BNF belonging to the user of non-friendly device 52 is an information processing terminal owned by the user of non-friendly device 52. A device 52BNF belonging to the user of non-friendly device 52 does not have to store non-friendly key information DKN. For example, device 43 does not store non-friendly key information DKN. A device 52BNF belonging to the user of non-friendly device 52 does not have to store key information DK. For example, device 43 does not store key information DK. A device 52BNF belonging to the user of non-friendly device 52 does not have to store device program PD. For example, device 43 does not store device program PD. Note that there is not limited to one device 52BNF belonging to the user of non-friendly device 52 other than non-friendly device 52.

[0039] As shown in Figure 5, the share key information DKS has a share key structure information STS and an 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.

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

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

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

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

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

[0045] <Management Server 70> 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 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.

[0046] The execution device 71 and the storage device 72 constitute the computer. The execution device 71 is the CPU, or processing circuit. The storage device 72 is memory. The storage device 72 stores the server program PS, the notification program PM, and the database DB.

[0047] The server program PS, when executed by the execution device 71, causes the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB. The server program PS also causes the execution device 71 to delete digital keys.

[0048] The notification program PM causes the execution device 71 to send a notification by executing it. 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.

[0049] <About Data DA> As shown in Figure 6, the data DA of a single vehicle 20 includes the type of digital key registered to the vehicle 20, the registered device 30, and the relationships between the registered devices 30. The relationships between the devices 30 are the relationships between the multiple digital keys registered to each device 30. A hierarchy of priority is determined by 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.

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

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

[0052] This section describes a state in which a digital key has been registered for 11 devices 30 for one vehicle 20. The 11 devices 30 are the first device 30A, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K.

[0053] The digital key registered in the first device 30A will be designated as the first digital key DK1. The digital key registered in the second device 30B will be designated as the second digital key DK2. The digital key registered in the third device 30C will be designated as the third digital key DK3. The digital key registered in the fourth device 30D will be designated as the fourth digital key DK4. The digital key registered in the fifth device 30E will be designated as the fifth digital key DK5. The digital key registered in the sixth device 30F will be designated as the sixth digital key DK6. The digital key registered in the seventh device 30G will be designated as the seventh digital key DK7. The digital key registered in the eighth device 30H will be designated as the eighth digital key DK8. The digital key registered in the ninth device 30I will be designated as the ninth digital key DK9. The digital key registered in the tenth device 30J will be designated as the tenth digital key DK10. The digital key registered in the eleventh device 30K will be designated as the eleventh digital key DK11.

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

[0055] 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, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K. In other words, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K are share devices 50. In other words, the second digital key DK2, the third digital key DK3, the fourth digital key DK4, the fifth digital key DK5, the sixth digital key DK6, the seventh digital key DK7, the eighth digital key DK8, the ninth digital key DK9, the tenth digital key DK10, and the eleventh digital key DK11 are all share keys KS.

[0056] More specifically, in the data DA, the devices 30 registered as digital key type 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 Device 51.

[0057] In the data DA, the devices 30 registered as having a digital key type of non-friendly key KN are the third device 30C, the fourth device 30D, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K. In other words, the third device 30C, the fourth device 30D, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K are non-friendly devices 52.

[0058] <Regarding direct lineage> 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. In this case, the second digital key DK2 is a digital key one generation later that is directly related to the first digital key DK1.

[0059] 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. In this case, the fifth digital key DK5 is a digital key one generation later that is directly related to the first digital key DK1.

[0060] In 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. In this case, the third digital key DK3 is a digital key one generation later, directly related to the second digital key DK2. The third digital key DK3 is a digital key two generations later, directly related to the first digital key DK1.

[0061] 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. In this case, the fourth digital key DK4 is a digital key one generation later, directly related to the second digital key DK2. The fourth digital key DK4 is a digital key two generations later, directly related to the first digital key DK1.

[0062] In the data DA, the relationship between the 6th device 30F and the 5th device 30E is such that the non-friendly key KN is registered in the 6th device 30F based on a registration request from the 5th device 30E. In other words, the 6th digital key DK6 is registered based on the 5th digital key DK5. In this case, the 6th digital key DK6 is a digital key one generation later, directly related to the 5th digital key DK5. The 6th digital key DK6 is a digital key two generations later, directly related to the 1st digital key DK1.

[0063] In the data DA, the relationship between the 7th device 30G and the 5th device 30E is such that a non-friendly key KN is registered in the 7th device 30G due to a registration request from the 5th device 30E. In other words, the 7th digital key DK7 is registered based on the 5th digital key DK5. In this case, the 7th digital key DK7 is a digital key one generation later, directly related to the 5th digital key DK5. The 7th digital key DK7 is a digital key two generations later, directly related to the 1st digital key DK1.

[0064] In the data DA, the relationship between the 8th device 30H and the 3rd device 30C is such that the non-friendly key KN is registered in the 8th device 30H based on a registration request from the 3rd device 30C. In other words, the 8th digital key DK8 is registered based on the 3rd digital key DK3. In this case, the 8th digital key DK8 is a digital key one generation later, directly related to the 3rd digital key DK3. The 8th digital key DK8 is a digital key two generations later, directly related to the 2nd digital key DK2. The 8th digital key DK8 is a digital key three generations later, directly related to the 1st digital key DK1.

[0065] In the data DA, the relationship between the 9th device 30I and the 4th device 30D is such that the non-friendly key KN is registered in the 9th device 30I based on a registration request from the 4th device 30D. In other words, the 9th digital key DK9 is registered based on the 4th digital key DK4. In this case, the 9th digital key DK9 is a digital key one generation later, directly related to the 4th digital key DK4. The 9th digital key DK9 is a digital key two generations later, directly related to the 2nd digital key DK2. The 9th digital key DK9 is a digital key three generations later, directly related to the 1st digital key DK1.

[0066] In the data DA, the relationship between the 10th device 30J and the 6th device 30F is such that the non-friendly key KN is registered in the 10th device 30J based on a registration request from the 6th device 30F. In other words, the 10th digital key DK10 is registered based on the 6th digital key DK6. In this case, the 10th digital key DK10 is a digital key one generation later, directly related to the 6th digital key DK6. The 10th digital key DK10 is a digital key two generations later, directly related to the 5th digital key DK5. The 10th digital key DK10 is a digital key three generations later, directly related to the 1st digital key DK1.

[0067] In Data DA, the relationship between the 11th device 30K and the 7th device 30G is such that the non-friendly key KN is registered in the 11th device 30K based on a registration request from the 7th device 30G. In other words, the 11th digital key DK11 is registered based on the 7th digital key DK7. In this case, the 11th digital key DK11 is a digital key one generation later, directly related to the 7th digital key DK7. The 11th digital key DK11 is a digital key two generations later, directly related to the 5th digital key DK5. The 11th digital key DK11 is a digital key three generations later, directly related to the 1st digital key DK1.

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

[0069] All digital keys registered based on a request from the first digital key DK1 are digital keys that are one generation or more later than the first digital key DK1. In other words, in the relationship diagram shown in Figure 6, all digital keys other than the first digital key DK1 are digital keys that are one generation or more later and have a direct relationship with the first digital key DK1.

[0070] All digital keys registered based on a request from the second digital key DK2 are digital keys that are one generation or more later than the second digital key DK2. In other words, in the relationship diagram shown in Figure 6, the third digital key DK3, the fourth digital key DK4, the eighth digital key DK8, and the ninth digital key DK9 are digital keys that are one generation or more later and that are directly related to the second digital key DK2.

[0071] <Regarding the higher and lower levels of digital keys> The first digital key DK1 is a digital key that is higher in rank than digital keys registered based on a request from the first digital key DK1, and digital keys that are one generation or more later than the digital keys registered based on a request from the first digital key DK1. In other words, in the data DA shown in Figure 6, the first digital key DK1 is a digital key that is higher in rank than digital keys other than the first digital key DK1.

[0072] A digital key registered based on a request from the first digital key DK1 is a digital key that is higher in rank than a digital key that is one generation or more later than the digital key registered based on a request from the first digital key DK1. In other words, in the data DA shown in Figure 6, the second digital key DK2 and the fifth digital key DK5 are digital keys that are higher in rank than a digital key registered based on a request from the second digital key DK2 or the fifth digital key DK5. That is, the second digital key DK2 and the fifth digital key DK5 are digital keys that are higher in rank than the third digital key DK3, the fourth digital key DK4, the sixth digital key DK6, the seventh digital key DK7, the eighth digital key DK8, the ninth digital key DK9, the tenth digital key DK10, and the eleventh digital key DK11.

[0073] A digital key one generation later than a digital key registered based on a request from the first digital key DK1 is a higher-ranking digital key than a digital key two or more generations later than a digital key registered based on a request from the first digital key DK1. In other words, in the data DA shown in Figure 6, the third digital key DK3, the fourth digital key DK4, the sixth digital key DK6, and the seventh digital key DK7 are higher-ranking digital keys than the digital keys registered based on requests from the third digital key DK3, the fourth digital key DK4, the sixth digital key DK6, or the seventh digital key DK7. That is, the third digital key DK3, the fourth digital key DK4, the sixth digital key DK6, and the seventh digital key DK7 are higher-ranking digital keys than the eighth digital key DK8, the ninth digital key DK9, the tenth digital key DK10, and the eleventh digital key DK11.

[0074] For example, in the data DA shown in Figure 6, the digital keys directly related to the third digital key DK3 are the first digital key DK1, the second digital key DK2, and the eighth digital key DK8. For example, in the data DA shown in Figure 6, the digital keys higher than the third digital key DK3 are the first digital key DK1, the second digital key DK2, and the fifth digital key DK5. For example, in the data DA shown in Figure 6, the digital keys that are directly related to the third digital key DK3 and are also higher are the first digital key DK1 and the second digital key DK2.

[0075] <Digital Key Registration> Next, we will describe a 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 first describe the process by which the owner key KO is registered and activated on an individual device. Next, we will describe the process by which the owner key KO is registered and activated on a virtual machine. 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 will be referred to as the first device 30A. Note that when registering the owner key KO, it is assumed that the first device 30A has an application installed.

[0076] From this point forward, the processes executed by the execution device 27 of the vehicle 20 will be described as processes executed by the vehicle 20. The processes executed by the execution device 36 of the device 30 will be described as processes executed by the device 30. The processes executed by the execution device 71 of the management server 70 will be described as processes executed by the management server 70.

[0077] As shown in Figure 7, the following describes a series of processes by which the management system 10 registers the first device 30A as the owner key KO when the first device 30A is a personal device.

[0078] The management system 10 causes the first device 30A, which is a personal device, to store owner key information DKO, which is key information DK indicating the owner key KO. The management system 10 causes the vehicle 20 to store authentication information AT for authenticating the owner key KO. As a result, the first device 30A becomes the owner device 40, which is a portable device 40M. The portable device 40M activates the owner key KO using proximity communication with the vehicle 20.

[0079] As shown in Figure 7, when the management server 70 receives an owner key KO registration start request D11 from the first device 30A, the owner key KO registration process is started. The registration start request D11 contains information indicating that the first device 30A to which the owner key KO is to be registered is a personal device. For example, the registration start request D11 contains owner device identification information.

[0080] In step S11, the management server 70 generates a pairing password PAS to be used for pairing the first device 30A with the vehicle 20. The management server 70 transmits information indicating the pairing password PAS to the first device 30A. The management server 70 transmits information indicating the pairing password PAS to the vehicle 20.

[0081] After receiving the pairing password PAS, vehicle 20 is set to pairing mode by HMI 22 and waits in a state where it can receive the password from the first device 30A. Then, vehicle 20 proceeds to step S12.

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

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

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

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

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

[0087] When the first device 30A receives the completion notification M11, it 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.

[0088] When the management server 70 receives the key track request D12, it performs the process 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, which is a portable device 40M, as the device 30 registered as the owner key KO in the data DA of the vehicle 20 in the database DB. With this, the management system 10 completes the series of processes to register the first device 30A, which is a personal device, as the owner key KO. Note that the process from pairing in step S12 to the registration management of the owner key KO in step S19 constitutes the activation process when registering the owner key KO.

[0089] As shown in Figure 8, the following describes a series of processes by which the management system 10 registers the first device 30A as an owner key KO when the first device 30A is a virtual machine.

[0090] The management system 10 causes the first device 30A, which is a virtual machine, to store the owner key information DKO, which is key information DK indicating the owner key KO. The management system 10 causes the vehicle 20 to store authentication information AT for authenticating the owner key KO. As a result, the first device 30A becomes a virtual device 40V, which is the owner device 40. The virtual device 40V does not perform proximity communication with the vehicle 20, but activates the owner key KO using wireless communication.

[0091] As shown in Figure 8, when the management server 70 receives the owner key KO registration start request D311 from the first device 30A, the owner key KO registration process is started. The registration start request D311 contains information indicating that the first device 30A to which the owner key KO is registered is a virtual machine. For example, the registration start request D311 contains owner device identification information.

[0092] Upon receiving the registration start request D311, the management server 70 sends key generation information DKC to the virtual device 40V to generate the owner key KO. The key generation information DKC includes information corresponding to vehicle identification information ST1 and vehicle public key information ST7, which indicates the vehicle public key PKV. Upon receiving the key generation information DKC, the first device 30A proceeds to step S311.

[0093] In step S311, the first device 30A generates owner key information DKO, which indicates the owner key KO. Next, in step S312, the first device 30A stores the owner key information DKO. Subsequently, the first device 30A sends an authentication request D312 for the owner key KO to the management server 70, which includes owner key authentication information DKA, corresponding to certificate information ST5 and device public key information ST6, which indicates the device public key PKD, relating to the owner key KO.

[0094] Subsequently, the management server 70, having received the authentication request D312, sends a registration request D313 to the vehicle 20. The registration request D313 includes the owner key authentication information DKA. When vehicle 20 receives registration request D313, it performs the process in step S313. In step S313, vehicle 20 activates the equipment necessary for authenticating the owner key KO using the communication module 21. These devices are, for example, the communication module 21 and the digital key ECU provided in the vehicle management device 26. By activating these devices, vehicle 20 can wait for and perform digital key authentication using the communication module 21. After that, vehicle 20 verifies the owner key authentication information DKA. Once the verification of the information corresponding to the certificate information ST5 contained in the owner key authentication information DKA is complete, vehicle 20 proceeds to step S314.

[0095] In step S314, the vehicle 20 stores information corresponding to the device public key information ST6, which indicates the device public key PKD, as authentication information AT. Subsequently, the vehicle 20 sends an authentication completion notification D314 to the management server 70 using the communication module 21, indicating that the storage of the authentication information AT is complete.

[0096] When the management server 70 receives the authentication completion notification D314, it performs the process in step S315. In step S315, the management server 70 performs the registration management of the owner key KO. Specifically, it stores the first device 30A, which is a virtual device 40V, as the device 30 registered as the owner key KO in the data DA of the vehicle 20 in the database DB. With this, the management system 10 completes the series of processes to register the first device 30A, which is a virtual machine, as the owner key KO. Note that the process from the verification of the owner key authentication information DKA in step S313 to the registration management of the owner key KO in step S315 constitutes the activation process when registering the owner key KO.

[0097] <Registering a Friend Key> As shown in Figure 9, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0114] <Registering a non-friend key> As shown in Figure 10, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0131] Next, a series of processes for deleting a digital key in the management system 10 will be described. In this embodiment, the digital key to be deleted is the third digital key DK3 of the non-friend key KN. Therefore, a series of processes for deleting the third digital key DK3 will be described.

[0132] As shown in Figure 11, when an operation is performed in the second device 30B to request the deletion of the third digital key DK3, the second device 30B first performs the process in step S61. In step S61, the second device 30B generates a deletion reservation D41 for the third digital key DK3. The deletion reservation D41 is a request to delete the third digital key DK3 when the default condition RC is met. The deletion reservation D41 is a signal that reserves the deletion of the third digital key DK3. In other words, the deletion reservation D41 is a deletion request that causes the device 30, which stores information about the digital keys registered in the vehicle 20, to delete the digital keys registered in the vehicle 20.

[0133] The deletion reservation D41 includes a signal requesting the deletion of the third digital key DK3, digital key identification information ST3 indicating the third digital key DK3, and information indicating a default condition RC. The default condition RC is a condition necessary to delete the target digital key after receiving the deletion reservation D41. The default condition RC is predetermined. In the first embodiment, the default condition RC is that a predetermined fade-out period has elapsed since receiving the deletion reservation D41. The deletion reservation D41 includes information identifying the second device 30B that transmits the deletion reservation D41 to the management server 70. For example, the deletion reservation D41 includes name information ATP5, which is information identifying the second device 30B. The second device 30B then transmits the deletion reservation D41 to the management server 70.

[0134] Subsequently, when the management server 70 receives the deletion reservation D41 for the third digital key DK3, it performs the process in step S62. In step S62, the management server 70 stores the state of the third digital key DK3, which is the target of the deletion reservation D41, as a fade-out state in the database DB. The fade-out state is a state in which the third digital key DK3, which is the target of the deletion reservation D41, will be deleted if the default condition RC is met. The fade-out state is a state in which the deletion reservation D41 has been received, but the execution of the deletion is still pending. Subsequently, the management server 70 proceeds to step S63.

[0135] In step S63, the management server 70 generates a pending notification M41 indicating that the state of the digital key requested for deletion by the deletion reservation D41 is in the fade-out state. <Regarding the recipient of the pending notification M41> The management server 70 sends a pending notification M41 to device 30, which is directly related to the third digital key DK3 that has been scheduled for deletion D41 and stores information about higher-level digital keys. The management server 70 also sends a pending notification M41 to vehicle 20.

[0136] As shown in Figure 6, the digital keys that are directly related to and higher in rank than the third digital key DK3 are the first digital key DK1 and the second digital key DK2. The management server 70 sends a pending notification M41 to the first device 30A, which stores information about the first digital key DK1. The management server 70 also sends a pending notification M41 to the second device 30B, which stores information about the second digital key DK2.

[0137] The management server 70 also sends a pending notification M41 to the third device 30C, which stores information about the third digital key DK3 that has been scheduled for deletion D41. The first device 30A and the third device 30C are devices 30 belonging to users other than the user of the second device 30B, which is the source of the deletion reservation D41, among the multiple devices 30 that store information about the digital keys registered in the vehicle 20. In other words, the management server 70 sends a pending notification M41 to the devices 30 belonging to users other than the user of the second device 30B, which is the source of the deletion reservation D41, among the multiple devices 30 that store information about the digital keys registered in the vehicle 20.

[0138] The management server 70 transmits information indicating the device 30 that sent the deletion reservation D41, along with the pending notification M41. Specifically, the management server 70 transmits information identifying the second device 30B along with the pending notification M41. For example, the management server 70 transmits name information ATP5, which is the name that identifies the second digital key DK2 registered in the second device 30B, along with the pending notification M41.

[0139] <Changes to the information sent with the pending notification M41> The management server 70 is configured to change the information it sends with the pending notification M41 depending on whether the owner device 40 is a mobile device 40M or a virtual device 40V. When the management server 70 generates a pending notification M41, it performs a series of processes to determine whether or not to send information indicating the device that sent the deletion reservation D41 along with the pending notification M41.

[0140] As shown in Figure 12, when this series of processes is started, in step S90, the management server 70 obtains information indicating whether or not the owner device 40 is a virtual device 40V. Specifically, the management server 70 obtains classification information TI stored in the storage device 72. By referring to the classification information TI, the management server 70 determines whether or not the owner device 40 is a virtual device 40V. If the owner device 40 is not a virtual device 40V (step S90: NO), the management server 70 proceeds to step S91.

[0141] In step S91, the management server 70 decides to send information indicating the device that sent the deletion reservation D41, along with the pending notification M41, to the owner device 40. Specifically, the management server 70 decides to send name information ATP5, along with the pending notification M41, to the owner device 40. After that, the management server 70 completes the series of processes shown in Figure 12.

[0142] If the owner device 40 is virtual device 40V (step S90: YES), the management server 70 proceeds to step S92. In step S92, the management server 70 decides not to send information to the owner device 40 indicating the device that sent the deletion reservation D41. Specifically, the management server 70 decides to send only the pending notification M41 to the owner device 40. After that, the management server 70 completes the series of processes shown in Figure 12. After the series of processes shown in Figure 12 is completed, the management server 70 sends the pending notification M41 and the name information ATP5.

[0143] As shown in Figure 11, the management server 70 sends a pending notification M41 and name information ATP5 to the owner device 40, which is a mobile device 40M. The management server 70 also sends a pending notification M41 and name information ATP5 to the second device 30B. The management server 70 also sends a pending notification M41 and name information ATP5 to the device 30 that stores information about the digital key that has been reserved for deletion D41. That is, the management server 70 also sends a pending notification M41 and name information ATP5 to the third device 30C that stores information about the third digital key DK3. The management server 70 also sends a pending notification M41 and name information ATP5 to the vehicle 20. Note that if the owner device 40 shown in Figure 11 is a virtual device 40V, the management server 70 sends only the pending notification M41 to the owner device 40.

[0144] <Information indicating that the deletion of the digital key is pending> When the mobile device 40M receives the pending notification M41 and the name information ATP5, the mobile device 40M performs the process in step S64. In step S64, the mobile device 40M presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the subject of the deletion reservation D41, is pending.

[0145] As shown in Figure 13, the HMI22 of the mobile device 40M, which received the pending notification M41 and name information ATP5, displays the first notification image IM1. The first notification image IM1 is an example of an image indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, is pending. The first notification image IM1 includes a first partial image IP1 and a second partial image IP2. The first partial image IP1 shows that the status of the digital key requested for deletion by the deletion reservation D41 is in a fade-out state. The first partial image IP1 shows that the "third digital key" is in a fade-out state. The second partial image IP2 shows the device 30 that sent the deletion reservation D41. The second partial image IP2 shows "second device" as the device 30 that sent the deletion reservation D41. When the part of the first notification image IM1 that says "Confirm" is selected, the first notification image IM1 is hidden.

[0146] When the second device 30B receives the pending notification M41 and the name information ATP5, the second device 30B performs the process in step S65. In step S65, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, is pending. For example, the second device 30B displays an image on the HMI 32 indicating that the deletion of the third digital key DK3 is pending. Specifically, the second device 30B, having received the pending notification M41 and the name information ATP5, displays the first notification image IM1 shown in Figure 13 on the HMI 32.

[0147] When the third device 30C receives the pending notification M41 and the name information ATP5, the third device 30C performs the process in step S66. In step S66, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, is pending. For example, the third device 30C displays an image on the HMI 32 indicating that the deletion of the third digital key DK3 is pending. Specifically, the third device 30C, having received the pending notification M41 and the name information ATP5, displays the first notification image IM1 shown in Figure 13 on the HMI 32.

[0148] When vehicle 20 receives the pending notification M41 and the name information ATP5, vehicle 20 performs the process in step S67. In step S67, vehicle 20 presents information to HMI 22 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, is pending. Specifically, upon receiving the pending notification M41 and the name information ATP5, vehicle 20 displays the first notification image IM1 shown in Figure 13 to HMI 22.

[0149] Furthermore, the virtual device 40V may be configured to display information indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, is pending when it receives the pending notification M41. For example, the virtual device 40V may be equipped with a monitor that displays an image. In that case, the monitor of the virtual device 40V will display the first notification image IM1, excluding the second partial image IP2. Subsequently, the management server 70 proceeds to step S68 shown in Figure 11.

[0150] As shown in Figure 11, in step S68, the management server 70 confirms that the default condition RC is met. If the default condition RC is met, the management system 10 proceeds to the deletion process DP. The deletion process DP is a series of processes from step S69 to step S75 shown in Figure 14. That is, if the default condition RC is met, the management server 70 proceeds to step S69 shown in Figure 14.

[0151] As shown in Figure 14, in step S69, the management server 70 generates a deletion command D42 to delete the non-friend key information DKN that indicates the non-friend key KN targeted by the deletion reservation D41. The management server 70 then sends the deletion command D42 to the non-friend device 52.

[0152] Subsequently, when the non-friend device 52 receives the deletion command D42, it performs the process in step S70. In step S70, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion command D42. Then, the non-friend device 52 sends a deletion completion notification M42 to the management server 70, indicating that it has completed the deletion in accordance with the deletion command D42.

[0153] Subsequently, when the management server 70 receives the completion notification M42, the management server 70 performs the process in step S71. In step S71, the management server 70 stores the history of deleting the non-friend key information DKN on the non-friend device 52.

[0154] In step S72, the management server 70 generates a deletion command D43 for the authentication information AT. This deletion command D43 for the authentication information AT indicates a command to delete the authentication information AT used to authenticate the non-friend key KN that is the target of the deletion reservation D41. The management server 70 then sends the deletion command D43 to the vehicle 20.

[0155] Subsequently, when vehicle 20 receives the deletion command D43, vehicle 20 performs the process in step S73. In step S70, vehicle 20 deletes the authentication information AT for authenticating the non-friendly key KN that is the target of the deletion reservation D41, in accordance with the deletion command D43. That is, vehicle 20 deletes the authentication package ATP for the non-friendly key KN. After that, vehicle 20 sends a deletion completion notification M43 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion command D43.

[0156] Subsequently, when the management server 70 receives the completion notification M43, the management server 70 performs the process in step S74. In step S74, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the non-friend key KN that is to be deleted in this series of deletion processes in the vehicle 20. After that, the management server 70 proceeds to step S75.

[0157] In step S75, the management server 70 updates the database DB. Specifically, the management server 70 deletes the third device 30C, which has the third digital key DK3 that is the target of deletion in this series of processes, from the vehicle data DA of the vehicle 20 in the database DB. After that, the management server 70 proceeds to step S76 shown in Figure 11.

[0158] As shown in Figure 11, in step S76, the management server 70 sends a completion notification M44 to the mobile device 40M, the second device 30B, the third device 30C, and the vehicle 20. The completion notification M44 is a deletion completion notification indicating that the series of deletions of non-friend key KN in accordance with the deletion reservation D41 has been completed.

[0159] When the mobile device 40M receives the completion notification M44, the mobile device 40M performs the process in step S77. In step S77, the mobile device 40M presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, has been completed. For example, the mobile device 40M displays an image on the HMI 32 indicating that the deletion of the third digital key DK3 has been completed.

[0160] When the second device 30B receives the completion notification M44, the second device 30B performs the process in step S78. In step S78, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, has been completed. For example, the second device 30B displays an image on the HMI 32 indicating that the deletion of the third digital key DK3 has been completed.

[0161] When the third device 30C receives the completion notification M44, the third device 30C performs the process in step S79. In step S79, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D41, has been completed. For example, the third device 30C displays an image on the HMI 32 indicating that the deletion of the third digital key DK3 has been completed.

[0162] When vehicle 20 receives completion notification M44, vehicle 20 performs the process in step S80. In step S80, vehicle 20 presents information to HMI 32 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D41, has been completed. For example, vehicle 20 displays an image on HMI 22 indicating the completion of the deletion of the third digital key DK3. Subsequently, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0163] <Operation of the First Embodiment> The management server 70 of the management system 10 sends a pending notification M41 to the first device 30A and the third device 30C, indicating that the digital key for which a deletion request, or deletion reservation D41, has been made is in a fade-out state. The first device 30A and the third device 30C are devices 30 other than the second device 30B, which sent the deletion reservation D41, among a group of devices 30 that store information about the digital keys registered in the vehicle 20.

[0164] <Effects of the First Embodiment> (1-1) The management server 70 can make the user of device 30 other than the second device 30B that sent the deletion reservation D41 aware of the third digital key DK3, which has been scheduled for deletion D41 and is in a fade-out state.

[0165] (1-2) The user of the third device 30C, which stores information about the third digital key DK3, wants to know whether or not a deletion reservation D41 has been made for the third digital key DK3. The management server 70 sends a pending notification M41 to the third device 30C, which stores information about the third digital key DK3 for which a deletion reservation D41 has been made. This allows the management server 70 to make the user of the third device 30C, which stores information about the third digital key DK3 for which a deletion reservation D41 has been made, aware of the third digital key DK3 that has been faded out due to the deletion reservation D41.

[0166] (1-3) The management server 70 sends a pending notification M41 to the first device 30A, which has a direct relationship to the third digital key DK3 that has been scheduled for deletion D41 and stores information about the higher-level first digital key DK1. The user of device 30 that stores information about digital keys is likely to want to know whether a deletion reservation D41 has been made for a lower-level digital key that has a direct relationship to that digital key. The management server 70 can make the user of the first device 30A aware of the third digital key DK3, which has been scheduled for deletion D41 and is in a fade-out state. The first device 30A is device 30 that has a direct relationship to the third digital key DK3 and stores information about the higher-level first digital key DK1.

[0167] (1-4) The management server 70 sends a pending notification M41 to the owner device 40, which is a device belonging to the owner of the vehicle 20. The owner of the vehicle 20 is likely to want to know whether or not a deletion reservation D41 has been made for the digital key of the vehicle 20. The management server 70 can make the user of the owner device 40 aware of the third digital key DK3, which has a deletion reservation D41 made and is in a fade-out state.

[0168] (1-5) The management server 70 sends information indicating the second device 30B that sent the deletion reservation D41, along with the pending notification M41. The management server 70 can make the information indicating the second device 30B that sent the deletion reservation D41 known to users of devices 30 other than the second device 30B that sent the deletion reservation D41.

[0169] (1-6) The management server 70 modifies the information it sends depending on whether the owner device 40, which is a device 30 belonging to the owner of the vehicle 20, is a mobile device 40M or a virtual device 40V built on the server 80. Specifically, if the owner device 40 is a virtual device 40V, the management server 70 does not send information from the second device 30B that sent the deletion reservation D41 to the owner device 40. When the virtual device 40V receives information from the second device 30B, there may be no user to confirm that information. If there is no user to confirm that information, the information from the second device 30B that sent the deletion reservation D41 may become unnecessary information for the virtual device 40V. The management server 70 can prevent the virtual device 40V from receiving information that is unnecessary for the virtual device 40V.

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

[0171] The management server 70 may send a pending notification M41 to device 30 which stores information about digital keys that have a direct relationship to the third digital key DK3 for which a deletion reservation D41 has been made. For example, the management server 70 may send a pending notification M41 to the eighth device 30H which stores information about the eighth digital key DK8 that has a direct relationship to the third digital key DK3. Users of device 30 which stores information about digital keys are likely to want to know whether a deletion reservation D41 has been made for a digital key that has a direct relationship to that digital key. The management server 70 can make the user of the eighth device 30H aware of the third digital key DK3, which has a deletion reservation D41 made and is in a fade-out state. The eighth device 30H is device 30 which stores information about the eighth digital key DK8 that has a direct relationship to the third digital key DK3.

[0172] The management server 70 may send a pending notification M41 to device 30 that stores information about digital keys higher than the third digital key DK3 for which a deletion reservation D41 has been made. For example, the management server 70 may send a pending notification M41 to the fifth device 30E that stores information about the fifth digital key DK5, which is higher than the third digital key DK3. Users of device 30 that store information about digital keys are likely to want to know whether a deletion reservation D41 has been made for a digital key lower than the digital key in question. The management server 70 can make the user of the fifth device 30E, which stores information about the fifth digital key DK5, higher than the third digital key DK3, aware of the third digital key DK3, which has a deletion reservation D41 made and is in a fade-out state.

[0173] If the management server 70 sends a pending notification M41 to a device 30 belonging to a user other than the user of the second device 30B, which is the source of the deletion reservation D41, it does not need to send information indicating the second device 30B along with the pending notification M41.

[0174] The recipients to whom the management server 70 sends pending notification M41 can be changed as appropriate. For example, the management server 70 may exclude device 30, which stores information about the digital key for which deletion reservation D41 has been made, from the recipients of the pending notification M41 and send the pending notification M41. The management server 70 may also exclude owner device 40 from the recipients of the pending notification M41 and send the pending notification M41.

[0175] The management server 70 may send a pending notification M41 to any device 30 other than the device 30 that has a direct relationship with the third digital key DK3 for which deletion reservation D41 has been made and that stores information about the higher-level digital key.

[0176] As shown in Figure 15, the device 30 to which the management server 70 sends a pending notification M41 includes multiple friend devices 51. The device 30 to which the management server 70 sends a pending notification M41 includes multiple non-friend devices 52. The device 30 to which the management server 70 sends a pending notification M41 includes multiple devices 40BO belonging to the owner of the vehicle 20. The device 30 to which the management server 70 sends a pending notification M41 includes multiple devices 51BF belonging to the users of multiple friend devices 51 other than the second device 30B. The device 30 to which the management server 70 sends a pending notification M41 includes multiple devices 52BNF belonging to the users of multiple non-friend devices 52.

[0177] Even if the owner device 40 is a virtual device 40V, the management server 70 may send information to the owner device 40 indicating the second device 30B, which is the source of the deletion reservation D41, along with the pending notification M41.

[0178] (Second Embodiment) The management server 70 according to the second embodiment will be described below with reference to Figures 11, 14, and 16-18. The second embodiment will be described primarily for its differences from the first embodiment. In the second embodiment, the owner device 40 is a portable device 40M. In the second embodiment, the management server 70 sends a pending notification M51 along with a confirmation request D52, which will be described later, during a series of processes to delete a digital key. The following will focus on the differences compared to the first embodiment, and the same points will be simplified or omitted from the explanation.

[0179] As shown in Figure 16, when an operation is performed in the second device 30B to request the deletion of the third digital key DK3, the second device 30B first performs the process in step S110. In step S110, the second device 30B generates a deletion reservation D51 for the third digital key DK3. The deletion reservation D51 is a request to delete the third digital key DK3 when the default condition RC is met. Similar to the deletion reservation D41, the deletion reservation D51 is a signal that reserves the deletion of the third digital key DK3. The second device 30B sends the deletion reservation D51 to the management server 70.

[0180] Deletion reservation D51 includes a signal requesting the deletion of the third digital key DK3, digital key identification information ST3 indicating the third digital key DK3, and information indicating the default condition RC. When the management server 70 receives the deletion reservation D51, it performs the process in step S111. In step S111, the management server 70 stores in the database DB the state of the third digital key DK3, which is the target of the deletion reservation D41, as a fade-out state. After that, the management server 70 proceeds to step S112.

[0181] In step S112, the management server 70 generates a pending notification M51 indicating that the state of the digital key requested for deletion by the deletion reservation D51 is in a fade-out state. The pending notification M51 includes information identifying the second device 30B that sent the deletion reservation D51. Specifically, the pending notification M51 includes name information ATP5, which is the name that identifies the second digital key DK2 registered in the second device 30B.

[0182] Furthermore, the management server 70 generates a confirmation request D52 that prompts the user to choose whether or not to allow the deletion of the digital key for which deletion reservation D51 has been made. <Regarding the recipients of the pending notification M51 and the confirmation request D52> The management server 70 sends a pending notification M51 to the first device 30A and the second device 30B, which are directly related to the third digital key DK3 that has been scheduled for deletion D51 and which store information about higher-level digital keys. The management server 70 also sends a pending notification M51 to the third device 30C, which stores information about the third digital key DK3 that has been scheduled for deletion D51. The management server 70 also sends a pending notification M51 to the vehicle 20.

[0183] Furthermore, the management server 70 sends confirmation request D52 to the owner device 40, which is a device belonging to the owner of the vehicle 20. That is, the management server 70 sends the pending notification M51 and confirmation request D52 to the first device 30A. The first digital key DK1 is a digital key of higher rank than the third digital key DK3. That is, the management server 70 sends confirmation request D52 to the device 30, which stores information about digital keys of higher rank than the third digital key DK3, for which deletion reservation D51 has been made.

[0184] When the second device 30B receives the pending notification M51, the second device 30B performs the process in step S113. In step S113, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D51, is pending. Step S113 is the same as step S65 in the first embodiment, so a detailed explanation is omitted.

[0185] When the third device 30C receives the pending notification M51, the third device 30C performs the process in step S114. In step S114, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D51, is pending. Step S114 is the same as step S66 in the first embodiment, so a detailed explanation is omitted.

[0186] When vehicle 20 receives pending notification M51, vehicle 20 performs the process in step S115. In step S115, vehicle 20 presents information to HMI 22 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D51, is pending. Step S115 is identical to step S67 in the first embodiment, so a detailed explanation is omitted.

[0187] <Processing performed by mobile device 40M after receiving confirmation request D52> When the first device 30A, the mobile device 40M, receives the pending notification M51 and the confirmation request D52, the mobile device 40M performs the process in step S116. In step S116, the mobile device 40M presents an image to the HMI 32 that allows the user of the mobile device 40M to choose whether or not to allow the deletion of the third digital key DK3, which has been reserved for deletion D51.

[0188] As shown in Figure 17, the HMI 32 of the mobile device 40M, which has received the pending notification M51 and the confirmation request D52, displays the second notification image IM2. The second notification image IM2 is an example of an image that allows the user of the mobile device 40M to choose whether or not to allow the deletion of the third digital key DK3, which has been reserved for deletion D51.

[0189] The second notification image IM2 includes the third partial image IP3 and the fourth partial image IP4. The third partial image IP3 shows that the status of the digital key requested for deletion by deletion reservation D51 is in a fade-out state. The third partial image IP3 shows that the "third digital key" is in a fade-out state. The third partial image IP3 also shows the device 30 that sent the deletion reservation D51. The third partial image IP3 shows "second device" as the device 30 that sent the deletion reservation D51.

[0190] The fourth section of image IP4 displays a request to choose whether or not to allow the deletion of the digital key for which deletion reservation D51 has been made. The fourth section of image IP4 displays a request to choose whether or not to allow the deletion of the "third digital key".

[0191] For users of mobile devices 40M, select "YES" using the radio button if you want to allow the deletion of the "Third Digital Key". For users of mobile devices 40M, select "NO" using the radio button if you do not want to allow the deletion of the "Third Digital Key".

[0192] <Step S116: If YES> If the user of the mobile device 40M selects "YES" using the radio button shown in Figure 17 and then presses "OK" (step S116: YES), the mobile device 40M performs the process shown in step S120 in Figure 18. In the process of step S120, the mobile device 40M generates an authorization notification M52. The authorization notification M52 is a notification that authorizes the deletion of the third digital key DK3, which has a deletion reservation D51. The mobile device 40M sends the authorization notification M52 to the management server 70.

[0193] When the management server 70 receives the permission notification M52, it performs the process in step S121. In step S121, the management server 70 confirms that the default condition RC is met. If the default condition RC is met, the management system 10 proceeds to the deletion process DP. The deletion process DP is a series of processes from steps S69 to S75 shown in Figure 14. After completing the deletion process DP, the management system 10 executes a series of processes from steps S76 to S80 shown in Figure 11. After that, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0194] <Step S116: If NO> If the user of the mobile device 40M selects "NO" using the radio button shown in Figure 17 and then presses "OK" (step S116: NO), the mobile device 40M performs the process shown in step S122 in Figure 18. In the process of step S122, the mobile device 40M generates a rejection notification M53. The rejection notification M53 is a notification rejecting the deletion of the third digital key DK3 for which a deletion reservation D51 has been made. The mobile device 40M sends the rejection notification M53 to the management server 70.

[0195] When the management server 70 receives rejection notification M53, it performs the process in step S123. In step S123, the management server 70 cancels the fade-out state. After that, the management server 70 proceeds to step S124. If the management server 70 receives rejection notification M53, the management system 10 does not execute the deletion process DP to delete the third digital key DK3 for which deletion reservation D51 has been made.

[0196] In step S124, the management server 70 generates a release notification M54. The release notification M54 includes information indicating that the fade-out state of the third digital key DK3 has been released.

[0197] Subsequently, the management server 70 sends a release notification M54 to the multiple devices 30 and vehicles 20 that were the recipients of the pending notification M51 in step S112. Specifically, the management server 70 sends the release notification M54 to the mobile device 40M, the second device 30B, the third device 30C, and the vehicles 20.

[0198] When the mobile device 40M receives the release notification M54, the mobile device 40M performs the process in step S125. In step S125, the mobile device 40M presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D51, has been released. For example, the mobile device 40M displays an image on the HMI 32 indicating that the fade-out state of the third digital key DK3 has been released.

[0199] When the second device 30B receives the release notification M54, the second device 30B performs the process in step S126. In step S126, the second device 30B presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D51, has been released. For example, the second device 30B displays an image on the HMI 32 indicating that the fade-out state of the third digital key DK3 has been released.

[0200] When the third device 30C receives the release notification M54, the third device 30C performs the process in step S127. In step S127, the third device 30C presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D51, has been released. For example, the third device 30C displays an image on the HMI 32 indicating that the fade-out state of the third digital key DK3 has been released.

[0201] When vehicle 20 receives the release notification M54, vehicle 20 performs the process in step S128. In step S128, vehicle 20 presents information to HMI 22 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D51, has been released. For example, vehicle 20 displays an image on HMI 22 indicating that the fade-out state of the third digital key DK3 has been released. Subsequently, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0202] <Operation of the second embodiment> Even if the user of the second digital key DK2 wishes to delete the third digital key DK3, other digital key users may not wish to delete the third digital key DK3. The management server 70 sends a confirmation request D52 along with a pending notification M51 to the devices 30 that store information about the digital keys registered in the vehicle 20, excluding the second device 30B, and which belong to the users of the other devices 30. The second device 30B is the device 30 that sent the deletion reservation D51 to the management server 70. The confirmation request D52 is a request to allow or deny the deletion of the third digital key DK3.

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

[0204] (2-1) When the management server 70 performs the deletion of the third digital key DK3, it can take into account the opinions of users who do not want the third digital key DK3 to be deleted. (2-2) The management server 70 sends confirmation request D52 to the first device 30A, which stores information about the first digital key DK1, which is higher in rank than the third digital key DK3, for which deletion reservation D51 has been made. Even if a user wishes to delete the third digital key DK3, the user of the first device 30A, which stores information about the first digital key DK1, which is higher in rank than the third digital key DK3, may not wish to delete the third digital key DK3. When the management server 70 executes the deletion of the third digital key DK3, it can take into account the opinion of the user of the first device 30A, which stores information about the first digital key DK1, which is higher in rank than the third digital key DK3.

[0205] (2-3) The management server 70 sends confirmation request D52 to the mobile device 40M. That is, the management server 70 sends confirmation request D52 to the owner device 40, which is the device 30 belonging to the owner of the vehicle 20. Even if a user wants to delete the third digital key DK3, the user of the owner device 40 may not want to delete the third digital key DK3. The management server 70 can take into account the opinion of the user of the owner device 40 when executing the deletion of the third digital key DK3.

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

[0207] The management server 70 may send a confirmation request D52 to a device 30 other than the device 30 that stores information about a digital key higher than the third digital key DK3 for which deletion reservation D51 has been made.

[0208] As shown in Figure 15, the device 30 to which the management server 70 sends confirmation request D52 includes multiple friend devices 51. The device 30 to which the management server 70 sends confirmation request D52 includes multiple non-friend devices 52. The device 30 to which the management server 70 sends confirmation request D52 includes multiple devices 40BO belonging to the owner of the vehicle 20. The device 30 to which the management server 70 sends confirmation request D52 includes multiple devices 51BF belonging to the users of the multiple friend devices 51. The device 30 to which the management server 70 sends confirmation request D52 includes multiple devices 52BNF belonging to the users of the multiple non-friend devices 52.

[0209] The destination to which the management server 70 sends the confirmation request D52 can be changed as appropriate. For example, the management server 70 may send the confirmation request D52 to device 30 which stores information about the digital key for which deletion reservation D51 has been made. The management server 70 may also send the confirmation request D52 to device 30 which stores information about digital keys that have a direct relationship to the digital key for which deletion reservation D51 has been made. The management server 70 does not have to send the confirmation request D52 to device 30 which stores information about digital keys that are higher in rank than the digital key for which deletion reservation D51 has been made. The management server 70 does not have to send the confirmation request D52 to owner device 40.

[0210] The management server 70 may send an acknowledgment request D52 to multiple devices 30. In this case, the conditions for releasing the fade-out state can be set as appropriate. For example, the management server 70 may set a condition to release the fade-out state if it receives a rejection notice M53 from all of the multiple devices 30 to which the acknowledgment request D52 was sent. For example, the management server 70 may set a condition to release the fade-out state if it receives a rejection notice M53 from more than half of the multiple devices 30 to which the acknowledgment request D52 was sent. For example, if the management server 70 has received an permission notice M52 from the device 30 that stores information about the highest-level digital key, it may set a condition so that it does not release the fade-out state even if it receives a rejection notice M53 from other devices 30.

[0211] (Third embodiment) The management server 70 according to the third embodiment will be described below with reference to Figures 11, 19, and 20. The third embodiment will be described mainly in terms of the differences from the first embodiment. In the third embodiment, the owner device 40 is a virtual device 40V. In the third embodiment, when a digital key for which deletion reservation D61 has been made is deleted, it is configured that digital keys lower in rank than the digital key for which deletion reservation D61 has been made are also deleted. In the third embodiment, if the owner device 40 is a virtual device 40V, the management server 70 does not send a pending notification M61 to the device 30 that stores information about digital keys lower in rank than the digital key for which deletion reservation D61 has been made when it receives a deletion reservation D61 from the owner device 40. The following will mainly describe the differences from the first embodiment, and the same points will be simplified or omitted.

[0212] As shown in Figure 19, when an operation is performed in the virtual device 40V to request the deletion of the second digital key DK2, the virtual device 40V first performs the process in step S140. In step S140, the virtual device 40V generates a deletion reservation D61 for the second digital key DK2. The deletion reservation D61 is a request to delete the second digital key DK2 when the default condition RC is met. The deletion reservation D61 is a signal that reserves the deletion of the second digital key DK2. The virtual device 40V sends the deletion reservation D61 to the management server 70.

[0213] The deletion reservation D61 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 a default condition RC. In the third embodiment, the default condition RC is that a predetermined fade-out period has elapsed since the receipt of the deletion reservation D61. The deletion reservation D61 includes information identifying whether the owner device 40 that transmits the deletion reservation D61 to the management server 70 is a virtual device 40V. For example, the deletion reservation D61 includes classification information TI.

[0214] Subsequently, when the management server 70 receives the deletion reservation D61, it performs the process in step S141. In step S141, the management server 70 stores in the database DB the state of the second digital key DK2, which is the target of the deletion reservation D61, as a fade-out state. After that, the management server 70 proceeds to step S142.

[0215] In step S142, the management server 70 generates a pending notification M61 indicating that the state of the digital key requested for deletion by the deletion reservation D61 is in a fade-out state. The pending notification M61 includes information identifying the virtual device 40V that sent the deletion reservation D61.

[0216] <Regarding the recipient of the pending notification M61> The management server 70 changes the destination of the pending notification M61 depending on whether or not it has received a deletion reservation D61 from the virtual device 40V. When the management server 70 generates a pending notification M61, it performs a series of processes to determine the destination of the pending notification M61.

[0217] As shown in Figure 20, once this series of processes begins, in step S93, the management server 70 obtains information indicating whether the owner device 40 that sent the deletion reservation D61 is a virtual device 40V. Specifically, the management server 70 obtains the classification information TI contained in the deletion reservation D61. By referring to the classification information TI, the management server 70 determines whether the owner device 40 that sent the deletion reservation D61 is a virtual device 40V. If the owner device 40 that sent the deletion reservation D61 is not a virtual device 40V (step S93: NO), the management server 70 proceeds to step S94.

[0218] In step S94, the management server 70 decides to send a pending notification M61 to the owner device 40. Furthermore, in step S94, the management server 70 decides to send a pending notification M61 to devices 30 belonging to users other than the user of the owner device 40 that sent the deletion reservation D61. After that, the management server 70 terminates the series of processes shown in Figure 20.

[0219] In other words, in step S94, the management server 70 decides to send a pending notification M61 to devices 30 that belong to users other than the user of the device 30 that sent the deletion reservation D61.

[0220] If the owner device 40 is virtual device 40V (step S93: YES), the management server 70 proceeds to step S95. In step S95, the management server 70 decides to send a pending notification M61 to the owner device 40. Furthermore, in step S95, the management server 70 decides not to send a pending notification M61 to any device 30 belonging to a user other than the user of the virtual device 40V that sent the deletion reservation D61, and which stores information about digital keys lower than the second digital key DK2.

[0221] In other words, in step S95, the management server 70 decides not to send a pending notification M61 to any device 30 belonging to a user other than the user of the device 30 that sent the deletion reservation D61, and which stores information about a digital key lower than the digital key for which the deletion reservation D61 was sent. After that, the management server 70 terminates the series of processes shown in Figure 20.

[0222] As shown in Figure 19, the owner device 40 in the third embodiment is a virtual device 40V. Therefore, the management server 70 sends a pending notification M61 to the virtual device 40V, the second device 30B, and the vehicle 20. The management server 70 does not send a pending notification M61 to the third device 30C, which stores information about the third digital key DK3 that is lower in rank than the second digital key DK2 for which a deletion reservation D61 has been made.

[0223] When virtual device 40V receives pending notification M61, virtual device 40V performs the process in step S143. In step S143, virtual device 40V presents information indicating that the deletion of the second digital key DK2, which is the target of deletion reservation D61, is pending. For example, if virtual device 40V is able to output an image to a monitor, it outputs an image to the monitor indicating that the deletion of the second digital key DK2 is pending.

[0224] When the second device 30B receives the pending notification M61, the second device 30B performs the process in step S144. In step S144, the second device 30B presents information to the HMI 32 indicating that the deletion of the second digital key DK2, which is the target of the deletion reservation D61, is pending. For example, the second device 30B displays an image on the HMI 32 indicating that the deletion of the second digital key DK2 is pending.

[0225] When vehicle 20 receives pending notification M61, vehicle 20 performs the process in step S145. In step S145, vehicle 20 presents information to HMI 22 indicating that the deletion of the second digital key DK2, which is the target of deletion reservation D61, is pending. For example, vehicle 20 displays an image on HMI 22 indicating that the deletion of the second digital key DK2 is pending. The management system 10 then deletes the second digital key DK2 by performing the same process as shown in Figure 11 from step S68 onwards. In this case, the deletion process DP is performed by the second device 30B, the management server 70, and vehicle 20. Subsequently, the management system 10 deletes the third digital key DK3 by performing the same process as shown in Figure 11 from step S68 onwards. In this case, the deletion process DP is performed by the third device 30C, the management server 70, and vehicle 20.

[0226] <Operation of the third embodiment> Examples of cases where the owner device 40 is a virtual device 40V include cases where a rental company or a sharing company is the owner of the vehicle 20. When a rental company or the like is the owner of the vehicle 20, the system may be configured so that when a digital key that has been scheduled for deletion D61 is deleted, lower-level digital keys are also deleted.

[0227] In this case, if a pending notification M61 is sent to the third device 30C, which stores information about the third digital key DK3, which is lower in rank than the second digital key DK2 for which deletion reservation D61 has been made, the user of the third device 30C will receive an unnecessary notification.

[0228] <Effects of the Third Embodiment> In the third embodiment, in addition to the effects shown in (1-1) and (1-3) of the first embodiment, the following further effects are achieved.

[0229] (3-1) When the second digital key DK2 is deleted, the management server 70 does not send a pending notification M61, which is unnecessary for the user of the third device 30C that stores information about the third digital key DK3. Therefore, the user of the third device 30C does not receive any unnecessary notifications.

[0230] <Example of modification of the third embodiment> The third embodiment described above can be implemented with the following modifications. The management server 70 does not need to send a pending notification M61 to the virtual device 40V.

[0231] (Fourth embodiment) The management system 10 according to the fourth embodiment will be described below with reference to Figures 11 and 21 to 23. In the fourth embodiment, the second device 30B, which is the friend device 51, sends a pending notification M71 and a completion notification M73. In the fourth embodiment, the second device 30B, which is the friend device 51, stores the contact information of the first device 30A and the third device 30C in the storage device 37. In the following, the differences from the first embodiment will be described in detail, and the same points will be simplified or omitted.

[0232] As shown in Figure 21, the storage device 37 of the second device 30B, which is the friend device 51, stores the notification program PM2. When the device 30 that stores the notification program PM2 sends a deletion reservation D71, the notification program PM2 causes the execution device 36 of the device 30 to execute a process to send a pending notification M71.

[0233] A series of processes for deleting a digital key in the management system 10 of the fourth embodiment will be described. In this embodiment, the digital key to be deleted is the third digital key DK3. Therefore, a series of processes for deleting the third digital key DK3 will be described.

[0234] As shown in Figure 22, when an operation is performed in the second device 30B to request the deletion of the third digital key DK3, the second device 30B first performs the process in step S150. In step S150, the second device 30B generates a deletion reservation D71 for the third digital key DK3. The deletion reservation D71 is a request to delete the third digital key DK3 when the default condition RC is met. The deletion reservation D71 is a signal that reserves the deletion of the third digital key DK3. In other words, the deletion reservation D71 is a deletion request that causes the device 30, which stores information about the digital keys registered in the vehicle 20, to delete the digital key registered in the vehicle 20.

[0235] The deletion reservation D71 includes a signal requesting the deletion of the third digital key DK3, digital key identification information ST3 indicating the third digital key DK3, and information indicating a default condition RC. In the fourth embodiment, the default condition RC is that a predetermined fade-out period has elapsed since the receipt of the deletion reservation D71. The deletion reservation D71 includes information identifying the second device 30B that transmits the deletion reservation D71 to the management server 70. When the second device 30B generates the deletion reservation D71, it proceeds to step S151.

[0236] In step S151, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D71, is pending. The second device 30B then proceeds to step S152.

[0237] In step S152, the second device 30B generates a pending notification M71 indicating that the state of the third digital key DK3, which is the target of the deletion reservation D71, is in a fade-out state.

[0238] <Regarding the recipient of the pending notification M71> The second device 30B has a direct relationship with the third digital key DK3, which has been scheduled for deletion D71, and sends a pending notification M71 to device 30, which stores information about the higher-level digital key. The second device 30B also sends a pending notification M71 to vehicle 20.

[0239] The digital keys that are directly related to and higher in rank than the third digital key DK3 are the first digital key DK1 and the second digital key DK2. The second device 30B sends a pending notification M71 to the first device 30A, which stores information about the first digital key DK1. The first device 30A is the owner device 40.

[0240] The second device 30B also sends a pending notification M71 to the third device 30C, which stores information about the third digital key DK3 that has been reserved for deletion D71. The first device 30A and the third device 30C are devices 30 belonging to users other than the user of the second device 30B, which is the source of the deletion reservation D71, among a plurality of devices 30 that store information about the digital keys registered in the vehicle 20. In other words, the second device 30B sends a pending notification M71 to the devices 30 belonging to users other than the user of the second device 30B, which is the source of the deletion reservation D71, among a plurality of devices 30 that store information about the digital keys registered in the vehicle 20.

[0241] The second device 30B transmits information indicating the device 30 that sent the deletion reservation D71, along with the pending notification M71. Specifically, the second device 30B transmits information identifying the second device 30B, along with the pending notification M71. For example, the second device 30B transmits name information ATP5, which is the name that identifies the second digital key DK2 registered in the second device 30B, along with the pending notification M71.

[0242] <Changes to the information sent with the pending notification M71> In the process of S152, the second device 30B is configured to change the information it sends with the pending notification M71 depending on whether the owner device 40 is a mobile device 40M or a virtual device 40V. In the process of S152, when the second device 30B generates the pending notification M71, it performs a series of processes to determine whether or not to send information indicating the device that will be the source of the deletion reservation D71 along with the pending notification M41, as shown in Figure 23.

[0243] As shown in Figure 23, when this series of processes is started, in step S96, the second device 30B obtains information indicating whether or not the owner device 40 is a virtual device 40V. Specifically, the second device 30B obtains classification information TI stored in the storage device 72 of the management server 70 from the management server 70. By referring to the classification information TI, the second device 30B determines whether or not the owner device 40 is a virtual device 40V. If the owner device 40 is not a virtual device 40V (step S96: NO), the second device 30B proceeds to step S97.

[0244] In step S97, the second device 30B decides to send to the owner device 40 information indicating the device that will send the deletion reservation D71, along with the pending notification M71. Specifically, the second device 30B decides to send to the owner device 40 name information ATP5, along with the pending notification M71.

[0245] In other words, the notification program PM2 instructs the second device 30B to send information indicating the device 30 that sent the deletion reservation D71, along with a pending notification M71, to devices 30 belonging to users other than the user of the device 30 that sent the deletion reservation D71. After that, the second device 30B completes the series of processes shown in Figure 23.

[0246] If the owner device 40 is a virtual device 40V (step S96: YES), the second device 30B proceeds to step S98. In step S98, the second device 30B decides to send a pending notification M71 to the owner device 40, excluding information indicating the device that is the source of the deletion reservation D71. Specifically, the management server 70 decides to send only the pending notification M71 to the owner device 40.

[0247] In other words, the notification program PM2 instructs the second device 30B to send a pending notification M71 to the virtual device 40V, excluding the information indicating the device 30 that sent the deletion reservation D71, from among the devices 30 belonging to users other than the user of the device 30 that sent the deletion reservation D71. After that, the second device 30B completes the series of processes shown in Figure 23.

[0248] After the series of processes shown in Figure 23 are completed, the second device 30B transmits the pending notification M71 and the name information ATP5 to the mobile device 40M, the third device 30C, and the vehicle 20.

[0249] As shown in Figure 22, the second device 30B sends a pending notification M71 and name information ATP5 to the owner device 40, which is a mobile device 40M. The second device 30B also sends a pending notification M71 and name information ATP5 to the third device 30C. The management server 70 also sends a pending notification M71 and name information ATP5 to the vehicle 20. Note that if the owner device 40 shown in Figure 11 is a virtual device 40V, the management server 70 sends only the pending notification M71 to the owner device 40.

[0250] When the mobile device 40M receives the pending notification M71 and the name information ATP5, the mobile device 40M performs the process of step S153. In step S153, the mobile device 40M presents, on the HMI 32, information indicating that deletion of the third digital key DK3, which is the target of the deletion reservation D41, is pending. Since step S153 is identical to step S64 in the first embodiment, a detailed description thereof will be omitted.

[0251] When the third device 30C receives the pending notification M71 and the name information ATP5, the third device 30C performs the process of step S154. In step S154, the third device 30C presents, on the HMI 32, information indicating that deletion of the third digital key DK3, which is the target of the deletion reservation D71, is pending. Since step S154 is identical to step S66 in the first embodiment, a detailed description thereof will be omitted.

[0252] When the vehicle 20 receives the pending notification M71 and the name information ATP5, the vehicle 20 performs the process of step S155. In step S155, the vehicle 20 presents, on the HMI 22, information indicating that deletion of the third digital key DK3, which is the target of the deletion reservation D71, is pending. Since step S155 is identical to step S67 in the first embodiment, a detailed description thereof will be omitted.

[0253] Note that the virtual device 40V may be configured to, when receiving the pending notification M71, present information indicating that deletion of the third digital key DK3, which is the target of the deletion reservation D71, is pending.

[0254] <Transmission of Deletion Reservation D71> After transmitting the pending notification M71, the second device 30B transmits the deletion reservation D71 to the management server 70. The second device 30B may transmit the pending notification M71 after transmitting the deletion reservation D71. The second device 30B may transmit the deletion reservation D71 and the pending notification M71 simultaneously. The management server 70 that has received the deletion reservation D71 performs step S156 shown in FIG. 22.

[0255] In step S156, the management server 70 stores in the database DB the state of the third digital key DK3, which is the target of deletion reservation D71, as a fade-out state. The fade-out state is a state in which the third digital key DK3, the target of deletion reservation D71, will be deleted if the default condition RC is met. After that, the management server 70 proceeds to step S157.

[0256] In step S157, the management server 70 confirms that the default condition RC is met. If the default condition RC is met, the management system 10 proceeds to the deletion process DP. The deletion process DP is the same as the deletion process DP in the first embodiment, so a detailed explanation is omitted. After that, the management server 70 proceeds to step S158.

[0257] In step S158, the management server 70 generates a completion notification M72 indicating that it has completed the series of deletions of the third digital key DK3 in accordance with the deletion reservation D71. The management server 70 then sends the completion notification M72 to the second device 30B, which is the source of the deletion reservation D71.

[0258] When the second device 30B receives the completion notification M72, the second device 30B performs the process in step S159. In step S159, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D71, has been completed. Subsequently, the second device 30B proceeds to step S160.

[0259] In step S160, the second device 30B generates a deletion completion notification M73 indicating that it has completed the series of deletions of the third digital key DK3. The second device 30B sends the completion notification M73 to the mobile device 40M, which is the recipient of the pending notification M71, the third device 30C, and the vehicle 20.

[0260] When the mobile device 40M receives the completion notification M73, the mobile device 40M performs the process in step S161. In step S161, the mobile device 40M presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D71, has been completed. Step S161 is the same as step S77 in the first embodiment, so a detailed explanation is omitted.

[0261] When the third device 30C receives the completion notification M73, the third device 30C performs the process in step S162. In step S162, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D71, has been completed. Step S162 is the same as step S79 in the first embodiment, so a detailed explanation is omitted.

[0262] When vehicle 20 receives completion notification M73, vehicle 20 performs the process in step S163. In step S163, vehicle 20 presents information to HMI 32 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D71, has been completed. Step S163 is the same as step S80 in the first embodiment, so a detailed explanation is omitted. After that, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0263] <Operation of the 4th Embodiment> The second device 30B is the source of the deletion reservation D71. The notification program PM2 causes the execution device 36 of the second device 30B to send a pending notification M71 to the device 30 that stores information about another digital key registered in the vehicle 20 that the second device 30B can use as a digital key.

[0264] <Effects of the 4th Embodiment> (4-1) The notification program PM2 can make users of devices 30 other than the second device 30B that sent the deletion reservation D71 aware that the third digital key DK3 will be in a fade-out state due to the deletion reservation D71.

[0265] (4-2) The notification program PM2 causes the execution device 36 to execute a process to send a pending notification M71 to the third device 30C, which stores information about the third digital key DK3 for which a deletion reservation D71 has been made. The user of the third device 30C, which stores information about the third digital key DK3, wants to know whether or not a deletion reservation D71 has been made for the third digital key DK3. The notification program PM2 can make the user of the third device 30C, which stores information about the third digital key DK3, aware that a deletion reservation D71 has been made for the third digital key DK3.

[0266] (4-3) The notification program PM2 causes the execution device 36 to execute a process to send a pending notification M71 to the first device 30A, which stores information about the first digital key DK1, a digital key that is directly related to the third digital key DK3 to which the deletion reservation D71 is made. The user of device 30, which stores information about digital keys, is highly likely to want to know whether or not a deletion reservation D71 is made for a digital key that is directly related to the said digital key and is lower in rank. The notification program PM2 can make the user of the first device 30A aware that a deletion reservation D71 is made for the third digital key DK3. The first device 30A is device 30, which stores information about the first digital key DK1, a digital key that is directly related to the third digital key DK3 and is higher in rank.

[0267] (4-4) The notification program PM2 causes the execution device 36 to execute a process to send a pending notification M71 to the owner device 40, which is a device 30 belonging to the owner of the vehicle 20. The owner of the vehicle 20 is likely to want to know whether or not a deletion reservation D71 has been made for the digital key of the vehicle 20. The notification program PM2 can make the user of the owner device 40 aware that a deletion reservation D71 has been made for the third digital key DK3, which is the digital key of the vehicle 20.

[0268] (4-5) The notification program PM2 causes the execution device 36 to execute a process that sends information indicating the second device 30B, which is the source of the deletion reservation D71, along with the pending notification M71. The notification program PM2 makes the information indicating the second device 30B, which is the source of the deletion reservation D71, known to users of devices 30 other than the second device 30B.

[0269] (4-6) The notification program PM2 causes the execution device 36 to send information indicating the second device 30B, which is the source of the deletion reservation D71, along with the pending notification M71. If the owner device 40 is a virtual device 40V, the notification program PM2 causes the execution device 36 to send the pending notification M71 to the owner device 40, excluding the information indicating the second device 30B, which is the source of the deletion reservation D71. When the virtual device 40V receives information indicating the second device 30B, which is the source of the deletion reservation D71, there may be no user to confirm this information. If there is no user to confirm this information, the information indicating the second device 30B may become unnecessary information for the virtual device 40V. The notification program PM2 can prevent the virtual device 40V from receiving unnecessary information.

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

[0271] The notification program PM2 may instruct the execution device 36 to send a pending notification M71 to device 30 which stores information about digital keys that have a direct relationship to the third digital key DK3 for which a deletion reservation D71 is made. For example, the notification program PM2 may instruct the execution device 36 to send a pending notification M71 to the eighth device 30H which stores information about the eighth digital key DK8 that has a direct relationship to the third digital key DK3. The user of device 30 which stores information about digital keys is likely to want to know whether or not a deletion reservation D71 is made for a digital key that has a direct relationship to that digital key. The notification program PM2 can make the user of the eighth device 30H aware that a deletion reservation D71 is made for the third digital key DK3. The eighth device 30H is device 30 which stores information about the eighth digital key DK8 that has a direct relationship to the third digital key DK3.

[0272] The notification program PM2 may instruct the execution device 36 to send a pending notification M71 to the device 30 that stores information about a digital key higher than the third digital key DK3 to which a deletion reservation D71 has been made. For example, the notification program PM2 may instruct the execution device 36 to send a pending notification M71 to the fifth device 30E that stores information about the fifth digital key DK5, which is higher than the third digital key DK3. The user of the device 30 that stores information about digital keys is likely to want to know whether or not a deletion reservation D71 has been made for a digital key lower than the digital key in question. The notification program PM2 can make the user of the fifth device 30E, which stores information about the fifth digital key DK5, which is higher than the third digital key DK3 to which a deletion reservation D71 has been made, aware that a deletion reservation D71 has been made for the third digital key DK3.

[0273] ·If the notification program PM2 causes the execution device 36 to execute the process of transmitting the pending notification M71, it is not required to cause the execution device 36 to execute the process of transmitting information indicating the second device 30B, which is the transmission source of the deletion reservation D71, together with the pending notification M71.

[0274] ·The notification program PM2 can appropriately change the transmission destination for which the execution device 36 transmits the pending notification M71. For example, the notification program PM2 may cause the execution device 36 to execute a process of excluding the device 30 storing information related to the digital key for which deletion reservation D71 has been made from the transmission targets of the pending notification M71 and then transmitting the pending notification M71. The notification program PM2 may cause the execution device 36 to execute a process of excluding the owner device 40 from the transmission targets of the pending notification M71 and then transmitting the pending notification M71.

[0275] ·The notification program PM2 may cause the execution device 36 to execute a process of transmitting the pending notification M71 to a device 30 other than the first device 30A. As shown in FIG. 24, the devices 30 to which the second device 30B transmits the pending notification M71 include a plurality of friend devices 51. The devices 30 to which the second device 30B transmits the pending notification M71 include a plurality of non-friend devices 52. The devices 30 to which the second device 30B transmits the pending notification M71 include a plurality of devices 40BO belonging to the owner of the vehicle 20. The devices 30 to which the second device 30B transmits the pending notification M71 include a plurality of devices 51BF belonging to users of the plurality of friend devices 51. The devices 30 to which the second device 30B transmits the pending notification M71 include a plurality of devices 52BNF belonging to users of the plurality of non-friend devices 52.

[0276] ·The notification program PM2 may cause the execution device 36 to execute a process of transmitting information indicating the second device 30B, which is the transmission source of the deletion reservation D71, together with the pending notification M71 to the virtual device 40V.

[0277] (Fifth embodiment) The management system 10 according to the fifth embodiment will be described below with reference to Figures 11, 14, 17, 21, 25, and 26. The fifth embodiment will be described mainly in terms of the differences from the fourth embodiment. In the fifth embodiment, the owner device 40 is a mobile device 40M. In the fifth embodiment, the second device 30B, which is the friend device 51, sends a confirmation request D82 along with a pending notification M81 in a series of processes for deleting a digital key. The following will mainly describe the differences from the fourth embodiment, and the same points will be simplified or omitted.

[0278] As shown in Figure 21, the storage device 37 of the friend device 51 stores the notification program PM2. When the device 30 that stores the notification program PM2 sends a deletion reservation D81, the notification program PM2 causes the device 30 to execute the process of sending a pending notification M81 and a confirmation request D82.

[0279] As shown in Figure 25, when an operation is performed in the second device 30B to request the deletion of the third digital key DK3, the second device 30B first performs the process in step S170. In step S170, the second device 30B generates a deletion reservation D81 for the third digital key DK3. The deletion reservation D81 is a request to delete the third digital key DK3 when the default condition RC is met. The deletion reservation D81 is a signal that reserves the deletion of the third digital key DK3. In other words, the deletion reservation D81 is a deletion request that causes the device 30, which stores information about the digital keys registered in the vehicle 20, to delete the digital keys registered in the vehicle 20.

[0280] The deletion reservation D81 includes a signal requesting the deletion of the third digital key DK3, digital key identification information ST3 indicating the third digital key DK3, and information indicating the default condition RC. The deletion reservation D81 also includes information identifying the second device 30B that transmits the deletion reservation D81 to the management server 70. Once the second device 30B has generated the deletion reservation D81, it proceeds to step S171.

[0281] In step S171, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D81, is pending. The second device 30B then proceeds to step S172.

[0282] <Regarding the destinations of the pending notification M81 and the confirmation request D82> In step S172, the second device 30B generates a pending notification M81 indicating that the state of the digital key targeted by the deletion reservation D81 is in a fade-out state. Furthermore, the second device 30B generates a confirmation request D82 prompting the user to choose whether or not to allow the deletion of the digital key targeted by the deletion reservation D81.

[0283] The second device 30B sends a pending notification M81 to the first device 30A, which is directly related to the third digital key DK3 that is the target of the deletion reservation D81 and stores information about the higher-level digital key. The second device 30B also sends a pending notification M81 to the third device 30C, which stores information about the third digital key DK3 that is the target of the deletion reservation D81. The second device 30B also sends a pending notification M81 to the vehicle 20.

[0284] Furthermore, the second device 30B sends a confirmation request D82 to the owner device 40. That is, the second device 30B sends a pending notification M81 and a confirmation request D82 to the first device 30A. The first digital key DK1 is a digital key of higher rank than the third digital key DK3. That is, the second device 30B sends a confirmation request D82 to the device 30 which stores information about a digital key of higher rank than the third digital key DK3, which is the target of the deletion reservation D81.

[0285] When the third device 30C receives the pending notification M81, the third device 30C performs the process in step S173. In step S173, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D81, is pending. Step S173 is the same as step S66 in the first embodiment, so a detailed explanation is omitted.

[0286] When vehicle 20 receives pending notification M81, vehicle 20 performs the process in step S174. In step S174, vehicle 20 presents information to HMI 22 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D81, is pending. Step S174 is identical to step S67 in the first embodiment, so a detailed explanation is omitted.

[0287] The second device 30B sends a pending notification M81, and then sends a deletion reservation D81 to the management server 70. The second device 30B may also send a pending notification M81 after sending the deletion reservation D81. The second device 30B may send the deletion reservation D81 and the pending notification M81 simultaneously.

[0288] Upon receiving the deletion reservation D81, the management server 70 performs the process in step S175. In step S175, the management server 70 stores in the database DB the state of the third digital key DK3, which is the target of the deletion reservation D81, as a fade-out state. The fade-out state is a state in which the third digital key DK3, the target of the deletion reservation D81, will be deleted if the default condition RC is met.

[0289] <Processing performed by mobile device 40M after receiving confirmation request D82> When the first device 30A, the mobile device 40M, receives the pending notification M81 and the confirmation request D82, the mobile device 40M performs the process in step S176. In step S176, the mobile device 40M presents an image to the HMI 32 that allows the user of the mobile device 40M to choose whether or not to allow the deletion of the third digital key DK3, which has been reserved for deletion D81. Step S176 is the same as step S116 in the second embodiment, so a detailed explanation is omitted.

[0290] <Step S176: If YES> If the user of the mobile device 40M selects "YES" using the radio button shown in Figure 17 and then presses "OK" (step S176: YES), the mobile device 40M performs the process shown in step S178 in Figure 26. In the process of step S178, the mobile device 40M generates a permission notification M82. The permission notification M82 is a notification that permits the deletion of the third digital key DK3, which is the target of the deletion reservation D81. The mobile device 40M sends the permission notification M82 to the second device 30B.

[0291] When the second device 30B receives the authorization notification M82, it performs the process in step S179. In the process in step S179, the second device 30B generates an authorization notification M83. The authorization notification M83 is a notification that authorizes the deletion of the third digital key DK3, which is the target of the deletion reservation D81. The second device 30B sends the authorization notification M83 to the management server 70.

[0292] When the management server 70 receives the permission notification M83, it performs the process in step S180. In step S180, the management server 70 confirms that the default condition RC is met. If the default condition RC is met, the management system 10 proceeds to the deletion process DP. The deletion process DP is a series of processes from steps S69 to S75 shown in Figure 14. After completing the deletion process DP, the management system 10 executes a series of processes from steps S76 to S80 shown in Figure 11. After that, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0293] <Step S176: If NO> If the user of mobile device 40M selects "NO" using the radio button shown in Figure 17 and then presses "OK" (step S176: NO), mobile device 40M performs the process shown in step S181 in Figure 26. In the process of step S181, mobile device 40M generates a rejection notice M84. The rejection notice M84 is a notification rejecting the deletion of the third digital key DK3 for which deletion reservation D81 has been made. Mobile device 40M then sends the rejection notice M84 to the second device 30B.

[0294] When the second device 30B receives the rejection notice M84, it performs the process in step S182. In step S182, the second device 30B generates a rejection notice M85. The rejection notice M85 is a notification rejecting the deletion of the third digital key DK3, which is the target of the deletion reservation D81. The second device 30B sends the rejection notice M85 to the management server 70.

[0295] When the management server 70 receives rejection notification M85, it performs the process in step S183. In step S183, the management server 70 cancels the fade-out state. If the management server 70 receives rejection notification M85, the management system 10 does not perform the deletion process DP to delete the third digital key DK3, which is the target of the deletion reservation D81.

[0296] After sending a rejection notification M85 to the management server 70, the second device 30B proceeds to step S184. In step S184, the second device 30B presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D81, is released. Subsequently, the second device 30B proceeds to step S185.

[0297] In step S185, the second device 30B generates a release notification M86. The release notification M86 includes information indicating that the fade-out state of the third digital key DK3 is released. Subsequently, the second device 30B sends the release notification M86 to the multiple devices 30 and the vehicle 20 to which the pending notification M81 was sent in step S172 shown in Figure 25. Specifically, the second device 30B sends the release notification M86 to the mobile device 40M, the third device 30C, and the vehicle 20.

[0298] When the mobile device 40M receives the release notification M86, the mobile device 40M performs the process in step S186. In step S186, the mobile device 40M presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D81, is being released. For example, the mobile device 40M displays an image on the HMI 32 indicating that the fade-out state of the third digital key DK3 is being released.

[0299] When the third device 30C receives the release notification M86, the third device 30C performs the process in step S187. In step S187, the third device 30C presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D81, is being released. For example, the third device 30C displays an image on the HMI 32 indicating that the fade-out state of the third digital key DK3 is being released.

[0300] When vehicle 20 receives the release notification M86, vehicle 20 performs the process in step S188. In step S188, vehicle 20 presents information to HMI 22 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D81, is being released. For example, vehicle 20 displays an image on HMI 22 indicating that the fade-out state of the third digital key DK3 is being released. Subsequently, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0301] <Operation of the Fifth Embodiment> Even if the user of the second device 30B wishes to delete the third digital key DK3, other users may not wish to delete the third digital key DK3. The notification program PM2 causes the execution device 36 of the second device 30B to send a confirmation request D82, along with a pending notification M81, to the devices 30 belonging to users of devices 30 other than the second device 30B that sent the deletion reservation D81. The confirmation request D82 is a request to choose whether or not to allow the deletion of the third digital key DK3.

[0302] <Effects of the Fifth Embodiment> In the fifth embodiment, in addition to the effects (4-1) to (4-5) of the fourth embodiment, the following further effects are achieved.

[0303] (5-1) When the notification program PM2 causes the execution device 36 of the second device 30B to perform the process of deleting the third digital key DK3, it can take into account the opinions of users who do not want the third digital key DK3 to be deleted.

[0304] (5-2) The notification program PM2 causes the execution device 36 to execute a process to send a confirmation request D82 to the first device 30A which stores information about the first digital key DK1, which is higher in rank than the third digital key DK3, which is the target of the deletion reservation D81. Even if a user wants to delete the third digital key DK3, the user of device 30 which stores information about a digital key higher in rank than the third digital key DK3 may not want to delete the third digital key DK3. When the notification program PM2 causes the execution device 36 to execute the process to delete the third digital key DK3, it can take into account the opinion of the user of device 30 which stores information about the first digital key DK1, which is higher in rank than the third digital key DK3.

[0305] (5-3) The notification program PM2 causes the execution device 36 to send a confirmation request D82 to the owner device 40, which is a device 30 belonging to the owner of the vehicle 20. Even if a user wants to delete the digital key, the user of the owner device 40 may not want to delete the digital key. The notification program PM2 can take into account the opinion of the user of the owner device 40 when causing the execution device 36 to execute the process of deleting the digital key.

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

[0307] The notification program PM2 may cause the execution device 36 to execute a process to send a confirmation request D82 to a device 30 other than the device 30 that stores information about a digital key higher than the third digital key DK3 which is the target of the deletion reservation D81.

[0308] As shown in Figure 24, the device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D82 includes a plurality of friend devices 51. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D82 includes a plurality of non-friend devices 52. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D82 includes a plurality of devices 40BO belonging to the owner of the vehicle 20. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D82 includes a plurality of devices 51BF belonging to the users of the plurality of friend devices 51. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D82 includes a plurality of devices 52BNF belonging to the users of the plurality of non-friend devices 52.

[0309] The destination to which the notification program PM2 causes the execution device 36 to send the confirmation request D82 can be changed as appropriate. For example, the notification program PM2 may cause the execution device 36 to send the confirmation request D82 to the device 30 that stores information about the digital key that is the target of the deletion reservation D81. The notification program PM2 may cause the execution device 36 to send the confirmation request D82 to the device 30 that stores information about digital keys that have a direct relationship to the digital key that is the target of the deletion reservation D81. The notification program PM2 does not have to cause the execution device 36 to send the confirmation request D82 to the device 30 that stores information about digital keys that are higher in rank than the digital key that has been deleted by the deletion reservation D81. The notification program PM2 does not have to cause the execution device 36 to send the confirmation request D82 to the owner device 40.

[0310] The notification program PM2 may instruct the execution device 36 to send an acknowledgment request D82 to multiple devices 30. In this case, the conditions for the execution device 36 to send a rejection notification M85 to the management server 70 can be set as appropriate. In other words, the conditions for canceling the fade-out state can be set as appropriate. For example, the notification program PM2 may set a condition for the execution device 36 to send a rejection notification M85 to the management server 70 when the second device 30B receives a rejection notification M85 from all of the multiple devices 30 to which the acknowledgment request D82 was sent. For example, the notification program PM2 may set a condition for the execution device 36 to send a rejection notification M85 to the management server 70 when it receives a rejection notification M84 from more than half of the multiple devices 30 to which the acknowledgment request D82 was sent. For example, if the notification program PM2 receives an authorization notification M82 from device 30 that stores information about the highest-level digital key, it may set a condition to cause the execution device 36 to send an authorization notification M83 to the management server 70, even if it receives a rejection notification M84 from another device 30, so as not to cancel the fade-out state. For example, if the notification program PM2 receives a rejection notification M84 from at least one device 30, it may set a condition to cause the execution device 36 to send a rejection notification M85 to the management server 70, even if it receives an authorization notification M82 from another device 30.

[0311] (Sixth Embodiment) The management system 10 according to the sixth embodiment will be described below with reference to Figures 11, 27, and 28. The sixth embodiment will be described primarily in terms of the differences from the fourth embodiment. In the sixth embodiment, the owner device 40 is a virtual device 40V. In the sixth embodiment, when a digital key that has been reserved for deletion D91 is deleted, digital keys lower in rank than the digital key that has been reserved for deletion D91 are also deleted. In the following, the differences from the fourth embodiment will be described primarily, and the same points will be simplified or omitted.

[0312] As shown in Figure 27, the storage device 37 of the owner device 40 stores the notification program PM2. When a device 30 that stores the notification program PM2 sends a deletion reservation D91, the notification program PM2 executes a process to exclude devices 30 that store information about digital keys lower than the digital key targeted by the deletion reservation D91 from the targets for sending the pending notification M91, and then sends the pending notification M91.

[0313] As shown in Figure 28, when an operation is performed in the virtual device 40V to request the deletion of the second digital key DK2, the virtual device 40V first performs the process in step S200. In step S200, the virtual device 40V generates a deletion reservation D91 for the second digital key DK2. Since the deletion reservation D91 is the same as the deletion reservation D61 in the third embodiment, a detailed explanation is omitted. After generating the deletion reservation D91, the virtual device 40V proceeds to step S202.

[0314] In step S202, the virtual device 40V generates a pending notification M91 indicating that the state of the second digital key DK2, which is the target of the deletion reservation D91, will be in a fade-out state.

[0315] <Regarding the recipient of the pending notification M91> Virtual device 40V sends a pending notification M91, excluding device 30, which stores information about digital keys lower than the second digital key DK2 that is subject to deletion reservation D91, from the list of recipients of the pending notification M91. Virtual device 40V also sends a pending notification M91 to vehicle 20.

[0316] As shown in Figure 28, the virtual device 40V sends a pending notification M91 to the second device 30B, which stores information about the second digital key DK2. The virtual device 40V also sends a pending notification M91 to the vehicle 20. The virtual device 40V does not send a pending notification M91 to the third device 30C, which stores information about the third digital key DK3, which is lower in rank than the second digital key DK2.

[0317] When the second device 30B receives the pending notification M91, the second device 30B performs the process in step S203. In step S203, the second device 30B presents information to the HMI 32 indicating that the deletion of the second digital key DK2, which is the subject of the pending notification M91, is pending. Step S203 is the same as step S144 in the third embodiment, so a detailed explanation is omitted.

[0318] When vehicle 20 receives pending notification M91, vehicle 20 performs the process in step S204. In step S204, vehicle 20 presents information to HMI 22 indicating that the deletion of the second digital key DK2, which is the target of deletion reservation D91, is pending. Step S204 is identical to step S145 in the third embodiment, so a detailed explanation is omitted.

[0319] <Sending deletion reservation D91> The virtual device 40V sends a pending notification M91, and then sends a deletion reservation D91 to the management server 70. The virtual device 40V may also send a pending notification M91 after sending the deletion reservation D91. The virtual device 40V may send the deletion reservation D91 and the pending notification M91 simultaneously. Upon receiving the deletion reservation D91, the management server 70 performs the process in step S205. In step S141, the management server 70 stores the state of the second digital key DK2, which is the target of the deletion reservation D91, as a fade-out state in the database DB. Subsequently, the management system 10 deletes the second digital key DK2 by performing the same process as the process from step S68 onwards shown in Figure 11. In this case, the deletion process DP is performed by the second device 30B, the management server 70, and the vehicle 20. Subsequently, the management system 10 deletes the third digital key DK3 by performing the same process as the process from step S68 onwards shown in Figure 11. In this case, the deletion process DP is performed by the third device 30C, the management server 70, and the vehicle 20.

[0320] <Operation of the 6th Embodiment> Examples of cases where the owner device 40 is a virtual device 40V include cases where a rental company or a sharing company is the owner of the vehicle 20. When a rental company or the like is the owner of the vehicle 20, the system may be configured so that when the digital key targeted by deletion reservation D91 is deleted, lower-level digital keys are also deleted.

[0321] In this case, if a pending notification M91 is sent to the third device 30C, which stores information about the third digital key DK3, which is lower in rank than the second digital key DK2 targeted by the deletion reservation D91, the user of the third device 30C will receive an unnecessary notification.

[0322] <Effects of the 6th Embodiment> In the sixth embodiment, in addition to the effects of (4-1) and (4-3) of the fourth embodiment, the following further effects are achieved.

[0323] (6-1) The notification program PM2 causes the execution device 36 of the virtual device 40V to send pending notifications M91, excluding notifications that are unnecessary for the user of the third device 30C, which stores information about the third digital key DK3. As a result, the user of the third device 30C does not receive any unnecessary notifications.

[0324] (Seventh Embodiment) The management system 10 according to the seventh embodiment will be described below with reference to Figures 29 to 31. In the seventh embodiment, the third device 30C, which is the target of the deletion reservation D101, sends a pending notification M102 and a completion notification M104. In the seventh embodiment, the third device 30C stores the contact information of the first device 30A and the second device 30B in the storage device 37. In the following, the differences from the first embodiment will be described in detail, and the same points will be simplified or omitted.

[0325] As shown in Figure 29, the storage device 37 of the non-friendly device 52, which is the target of the deletion reservation D101, stores the notification program PM2. When the device 30 that stores the notification program PM2 receives a pending notification M101, the execution device 36 causes the device 30 to send a pending notification M102.

[0326] A series of processes for deleting a digital key in the management system 10 of the seventh embodiment will be described. In this embodiment, the digital key to be deleted is the third digital key DK3. Therefore, a series of processes for deleting the third digital key DK3 will be described.

[0327] As shown in Figure 30, when an operation is performed in the second device 30B to request the deletion of the third digital key DK3, the second device 30B first performs the process in step S210. In step S210, the second device 30B generates a deletion reservation D101 for the third digital key DK3. Since the deletion reservation D101 is the same as the deletion reservation D41 in the first embodiment, a detailed explanation is omitted. The second device 30B sends the deletion reservation D101 to the management server 70.

[0328] Subsequently, when the management server 70 receives the deletion reservation D101 for the third digital key DK3, it performs the process in step S211. Since step S211 is the same as step S62 in the first embodiment, a detailed explanation is omitted. After that, the management server 70 proceeds to step S212.

[0329] In step S212, the management server 70 generates a pending notification M101 indicating that the state of the digital key requested for deletion by deletion reservation D101 is in a fade-out state.

[0330] <Regarding the recipient of the pending notification M101> The management server 70 sends a pending notification M101 to the third device 30C, which stores information about the third digital key DK3 that has been scheduled for deletion D101. The third device 30C is a non-friendly device 52. The management server 70 also sends a pending notification M101 to the second device 30B, which is the source of the deletion reservation D101.

[0331] The management server 70 transmits information indicating the device 30 that sent the deletion reservation D101, along with the pending notification M101. Specifically, the management server 70 transmits information identifying the second device 30B along with the pending notification M101. For example, the management server 70 transmits name information ATP5, which is the name that identifies the second digital key DK2 registered in the second device 30B, along with the pending notification M101.

[0332] When the second device 30B receives the pending notification M101, the second device 30B performs the process in step S213. In step S213, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, is pending. Step S213 is the same as step S65 in the first embodiment, so a detailed explanation is omitted.

[0333] When the third device 30C receives the pending notification M101, the third device 30C performs the process in step S214. In step S214, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, is pending. Step S214 is the same as step S66 in the first embodiment, so a detailed explanation is omitted. After that, the third device 30C proceeds to step S215.

[0334] <Regarding the recipient of the pending notification M102> In step S215, the third device 30C generates a pending notification M102 indicating that the state of the digital key requested for deletion by the deletion reservation D101 is in a fade-out state.

[0335] Furthermore, in step S215, the third device 30C, which has received the pending notification M101, executes the process of sending a pending notification M102 to a device 30 that belongs to a user other than the user of the second device 30B, which is the source of the deletion reservation D101, among the multiple devices 30 that store information about the digital key registered in the vehicle 20.

[0336] Specifically, the third device 30C sends a pending notification M102 to the first device 30A, which stores information about the first digital key DK1. The third device 30C also sends a pending notification M102 to the vehicle 20.

[0337] The third device 30C transmits information indicating the device 30 that sent the deletion reservation D101, along with the pending notification M102. Specifically, the third device 30C transmits information identifying the second device 30B, along with the pending notification M102. For example, the third device 30C transmits name information ATP5, which is the name that identifies the second digital key DK2 registered in the second device 30B, along with the pending notification M102.

[0338] <Changes to the information sent with the pending notification M102> The third device 30C is configured to change the information it sends with the pending notification M102 depending on whether the owner device 40 is a mobile device 40M or a virtual device 40V. When the third device 30C generates a pending notification M102, it performs a series of processes to determine whether or not to send information indicating the device that sent the deletion reservation D101 along with the pending notification M102.

[0339] As shown in Figure 31, when this series of processes is started, in step S99, the third device 30C obtains information indicating whether or not the owner device 40 is a virtual device 40V. Specifically, the third device 30C obtains classification information TI stored in the storage device 72 of the management server 70 from the management server 70. By referring to the classification information TI, the third device 30C determines whether or not the owner device 40 is a virtual device 40V. If the owner device 40 is not a virtual device 40V (step S99: NO), the third device 30C proceeds to step S100.

[0340] In step S100, the third device 30C decides to send to the owner device 40 information indicating the device that sent the deletion reservation D101, along with the pending notification M102. Specifically, the third device 30C decides to send to the owner device 40 name information ATP5, along with the pending notification M102.

[0341] In other words, the notification program PM2 instructs the third device 30C to send information indicating the device 30 that sent the deletion reservation D101, along with a pending notification M102, to devices 30 belonging to users other than the user of the device 30 that sent the deletion reservation D101. After that, the third device 30C completes the series of processes shown in Figure 31.

[0342] If the owner device 40 is a virtual device 40V (step S99: YES), the third device 30C proceeds to step S101. In step S101, the third device 30C decides to send a pending notification M102 to the owner device 40, excluding information indicating the device that sent the deletion reservation D101. Specifically, the third device 30C decides to send only the pending notification M102 to the owner device 40.

[0343] In other words, the notification program PM2 instructs the third device 30C to send a pending notification M102 to the virtual device 40V, excluding the information indicating the device 30 that sent the deletion reservation D101, from among the devices 30 belonging to users other than the user of the device 30 that sent the deletion reservation D101. After that, the third device 30C completes the series of processes shown in Figure 31.

[0344] After the series of processes shown in Figure 31 are completed, the third device 30C sends a pending notification M102 and name information ATP5. As shown in Figure 30, the third device 30C sends a pending notification M102 and name information ATP5 to the owner device 40, which is a mobile device 40M. The third device 30C also sends a pending notification M102 and name information ATP5 to the vehicle 20. However, if the owner device 40 shown in Figure 30 is a virtual device 40V, the third device 30C sends only the pending notification M102 to the owner device 40.

[0345] When the mobile device 40M receives the pending notification M102 and the name information ATP5, the mobile device 40M performs the process in step S216. In step S216, the mobile device 40M presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, is pending. Step S216 is identical to step S64 in the first embodiment, so a detailed explanation is omitted.

[0346] When vehicle 20 receives the pending notification M102 and the name information ATP5, vehicle 20 performs the process in step S217. In step S217, vehicle 20 presents information to HMI22 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, is pending. Step S217 is identical to step S67 in the first embodiment, so a detailed explanation is omitted.

[0347] Furthermore, the virtual device 40V may be configured to display information indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, is pending when it receives the pending notification M102.

[0348] After sending the pending notification M101, the management server 70 proceeds to step S218. In step S218, the management server 70 confirms that the default condition RC is met. If the default condition RC is met, the management system 10 proceeds to the deletion process DP. The deletion process DP is the same as the deletion process DP in the first embodiment, so a detailed explanation is omitted. After that, the management server 70 proceeds to step S219.

[0349] In step S219, the management server 70 generates a completion notification M103 indicating that it has completed the series of deletions of the third digital key DK3 in accordance with the deletion reservation D101. The management server 70 then sends the completion notification M103 to the third device 30C, which was storing information about the third digital key DK3 that was scheduled for deletion D101.

[0350] When the third device 30C receives the completion notification M103, the third device 30C performs the process in step S220. In step S220, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, has been completed. Step S220 is the same as step S79 in the first embodiment, so a detailed explanation is omitted. After that, the third device 30C proceeds to step S221.

[0351] <Sending completion notification M104> In step S221, the third device 30C generates a deletion completion notification M104 indicating that it has completed the series of deletions of the third digital key DK3 in accordance with the deletion reservation D101. The third device 30C then transmits the completion notification M104 to the mobile device 40M, the second device 30B, and the vehicle 20.

[0352] When the mobile device 40M receives the completion notification M104, the mobile device 40M performs the process in step S222. In step S222, the mobile device 40M presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, has been completed. Step S222 is the same as step S77 in the first embodiment, so a detailed explanation is omitted.

[0353] When the second device 30B receives the completion notification M104, the second device 30B performs the process in step S223. In step S223, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D101, has been completed. Step S223 is the same as step S78 in the first embodiment, so a detailed explanation is omitted.

[0354] When vehicle 20 receives completion notification M104, vehicle 20 performs the process in step S224. In step S224, vehicle 20 presents information to HMI 32 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D101, has been completed. Step S224 is the same as step S80 in the first embodiment, so a detailed explanation is omitted. Subsequently, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0355] <Operation of the 7th Embodiment> The third device 30C stores information about the third digital key DK3 for which deletion reservation D101 has been made. The notification program PM2 causes the execution device 36 of the third device 30C to execute the process of sending a pending notification M102 to the first device 30A. The first device 30A is a device 30 that stores information about digital keys other than the third digital key DK3 registered in the vehicle 20, and belongs to a user other than the user of the second device 30B that sent the deletion reservation D101.

[0356] <Effects of the 7th Embodiment> (7-1) The notification program PM2 can make the user of device 30 other than the second device 30B that sent the deletion reservation D101 aware that the third digital key DK3 will be in a fade-out state due to the deletion reservation D101.

[0357] (7-2) The notification program PM2 causes the execution device 36 to execute a process to send a pending notification M102 to the first device 30A, which stores information about the first digital key DK1, a digital key that is directly related to the third digital key DK3 for which a deletion reservation D101 has been made. The user of device 30, which stores information about digital keys, is highly likely to want to know whether or not a deletion reservation D101 has been made for a digital key that is directly related to the said digital key and is lower in rank. The notification program PM2 makes the user of the first device 30A aware that a deletion reservation D101 has been made for the third digital key DK3. The first device 30A is device 30, which stores information about the first digital key DK1, a digital key that is directly related to the third digital key DK3 and is higher in rank.

[0358] (7-3) The notification program PM2 causes the execution device 36 to execute a process to send a pending notification M102 to the owner device 40, which is a device 30 belonging to the owner of the vehicle 20. The owner of the vehicle 20 is likely to want to know whether or not a deletion reservation D101 has been made for the digital key of the vehicle 20. The notification program PM2 can make the user of the owner device 40 aware that a deletion reservation D101 has been made for the third digital key DK3, which is the digital key of the vehicle 20.

[0359] (7-4) The notification program PM2 causes the execution device 36 to execute a process that sends information indicating the second device 30B, which is the source of the deletion reservation D101, along with the pending notification M102. The notification program PM2 makes the information indicating the second device 30B, which is the source of the deletion reservation D101, known to users of devices 30 other than the second device 30B.

[0360] (7-5) The notification program PM2 instructs the execution device 36 to send information indicating the second device 30B, the source of the deletion reservation D101, along with the pending notification M102. If the owner device 40 is a virtual device 40V, the notification program PM2 instructs the execution device 36 to send the pending notification M101 to the owner device 40, excluding the information indicating the second device 30B, the source of the deletion reservation D101. When the virtual device 40V receives information indicating the second device 30B, the source of the deletion reservation D101, there may be no user to confirm this information. If there is no user to confirm this information, the information indicating the second device 30B may become unnecessary information for the virtual device 40V. The notification program PM2 can prevent the virtual device 40V from receiving unnecessary information.

[0361] <Example of modification of the 7th embodiment> The seventh embodiment described above can be implemented with the following modifications. The modifications to the seventh embodiment described above and the following examples of modifications to the seventh embodiment can be combined with each other to the extent that they do not contradict each other technically.

[0362] The notification program PM2 may instruct the execution device 36 to send a pending notification M102 to device 30 which stores information about digital keys that have a direct relationship to the third digital key DK3 for which a deletion reservation D101 has been made. For example, the notification program PM2 may instruct the execution device 36 to send a pending notification M102 to the eighth device 30H which stores information about the eighth digital key DK8 that has a direct relationship to the third digital key DK3. The user of device 30 which stores information about digital keys is likely to want to know whether or not a deletion reservation D101 has been made for a digital key that has a direct relationship to that digital key. The notification program PM2 can make the user of the eighth device 30H aware that a deletion reservation D101 has been made for the third digital key DK3. The eighth device 30H is device 30 which stores information about the eighth digital key DK8 that has a direct relationship to the third digital key DK3.

[0363] The notification program PM2 may instruct the execution device 36 to send a pending notification M102 to a device 30 that stores information about a digital key higher than the third digital key DK3 to which a deletion reservation D101 has been made. For example, the notification program PM2 may instruct the execution device 36 to send a pending notification M102 to a fifth device 30E that stores information about a fifth digital key DK5 higher than the third digital key DK3. The user of device 30 that stores information about digital keys is likely to want to know whether a deletion reservation D101 has been made for a digital key lower than the digital key in question. The notification program PM2 can make the user of the fifth device 30E aware that a deletion reservation D101 has been made for the third digital key DK3. The fifth device 30E is device 30 that stores information about a fifth digital key DK5 higher than the third digital key DK3.

[0364] If the notification program PM2 causes the execution device 36 to perform the process of sending the pending notification M102, it does not need to cause the execution device 36 to perform the process of sending information indicating the second device 30B, which is the source of the deletion reservation D101, along with the pending notification M102.

[0365] The notification program PM2 can appropriately change the destination to which the execution device 36 sends the pending notification M102. For example, the notification program PM2 may instruct the execution device 36 to exclude the owner device 40 from the recipients of the pending notification M102 and then send the pending notification M102.

[0366] The notification program PM2 may cause the execution device 36 to execute a process to send a pending notification M102 to devices 30 other than the first device 30A. As shown in Figure 32, the devices 30 to which the third device 30C sends the pending notification M102 include multiple friend devices 51. The devices 30 to which the third device 30C sends the pending notification M102 include multiple non-friend devices 52. The devices 30 to which the third device 30C sends the pending notification M102 include multiple devices 40BO belonging to the owner of the vehicle 20. The devices 30 to which the third device 30C sends the pending notification M102 include multiple devices 51BF belonging to the users of the multiple friend devices 51. The devices 30 to which the third device 30C sends the pending notification M102 include multiple devices 52BNF belonging to the users of the multiple non-friend devices 52.

[0367] The notification program PM2 may instruct the execution device 36 to send information indicating the second device 30B, which is the source of the deletion reservation D101, along with the pending notification M102, to the virtual device 40V.

[0368] (Eighth embodiment) The management system 10 according to the eighth embodiment will be described below with reference to Figures 11, 17, 29, 33, and 34. The eighth embodiment will be described primarily for its differences from the seventh embodiment. In the eighth embodiment, the owner device 40 is a portable device 40M. In the eighth embodiment, the third device 30C, which is a non-friend device 52, sends a confirmation request D112 along with a pending notification M112 in a series of processes for deleting a digital key. The following will focus on the differences from the seventh embodiment, and the same points will be simplified or omitted from the explanation.

[0369] As shown in Figure 29, the storage device 37 of the non-friendly device 52 stores the notification program PM2. When the device 30 that stores the notification program PM2 sends a pending notification M112, the notification program PM2 causes the device 30 to execute a process to send a confirmation request D112 along with the pending notification M112.

[0370] As shown in Figure 33, when an operation is performed in the second device 30B to request the deletion of the third digital key DK3, the second device 30B first performs the process in step S230. In step S230, the second device 30B generates a deletion reservation D111 for the third digital key DK3. The deletion reservation D111 is a request to delete the third digital key DK3 when the default condition RC is met. The deletion reservation D111 is a signal that reserves the deletion of the third digital key DK3. In other words, the deletion reservation D111 is a deletion request that causes the device 30, which stores information about the digital keys registered in the vehicle 20, to delete the digital key registered in the vehicle 20.

[0371] The deletion reservation D111 includes a signal requesting the deletion of the third digital key DK3, digital key identification information ST3 indicating the third digital key DK3, and information indicating the default condition RC. The deletion reservation D111 also includes information identifying the second device 30B that transmits the deletion reservation D111 to the management server 70. The second device 30B transmits the deletion reservation D111 to the management server 70.

[0372] Upon receiving the deletion reservation D111, the management server 70 performs the process in step S231. In step S231, the management server 70 stores in the database DB the state of the third digital key DK3, which is the target of the deletion reservation D81, as a fade-out state. After that, the management server 70 proceeds to step S232.

[0373] In step S232, the management server 70 generates a pending notification M111 indicating that the state of the digital key requested for deletion by the deletion reservation D111 is in a fade-out state. The pending notification M111 includes information identifying the second device 30B that sent the deletion reservation D111. Specifically, the pending notification M111 includes name information ATP5, which is the name that identifies the second digital key DK2 registered in the second device 30B.

[0374] <Regarding the recipient of the pending notification M111> The management server 70 sends a pending notification M111 to the third device 30C, which stores information about the third digital key DK3 that has been scheduled for deletion D111. The management server 70 also sends a pending notification M111 to the second device 30B, which is the source of the deletion reservation D111.

[0375] When the second device 30B receives the pending notification M111, the second device 30B performs the process in step S233. In step S233, the second device 30B presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D111, is pending. Step S223 is the same as step S65 in the first embodiment, so a detailed explanation is omitted.

[0376] When the third device 30C receives the pending notification M111, the third device 30C performs the process in step S234. In step S234, the third device 30C presents information to the HMI 32 indicating that the deletion of the third digital key DK3, which is the target of the deletion reservation D111, is pending. Step S234 is the same as step S66 in the first embodiment, so a detailed explanation is omitted. After that, the third device 30C proceeds to step S235.

[0377] <Regarding the destinations of the pending notification M112 and the confirmation request D112> In step S235, the third device 30C generates a pending notification M112 indicating that the state of the digital key subject to deletion reservation D111 is in a fade-out state. Furthermore, the third device 30C generates a confirmation request D112 prompting the user to choose whether or not to allow the deletion of the digital key subject to deletion reservation D111.

[0378] The third device 30C executes the process of sending a pending notification M102 to a device 30 that belongs to a user other than the user of the second device 30B, which is the source of the deletion reservation D111, among the multiple devices 30 that store information about the digital key registered in the vehicle 20.

[0379] Specifically, the third device 30C sends a pending notification M112 to the first device 30A, which stores information about the first digital key DK1. The third device 30C also sends a pending notification M112 to the vehicle 20.

[0380] Furthermore, the third device 30C sends a confirmation request D112 along with the pending notification M112 to the owner device 40. That is, the third device 30C sends the pending notification M112 and the confirmation request D112 to the first device 30A. The first digital key DK1 is a digital key of higher rank than the third digital key DK3. That is, the third device 30C sends the confirmation request D112 to the device 30 which stores information about a digital key of higher rank than the third digital key DK3, which is the target of the deletion reservation D111.

[0381] When vehicle 20 receives pending notification M112, vehicle 20 performs the process in step S236. In step S236, vehicle 20 presents information to HMI 22 indicating that the deletion of the third digital key DK3, which is the target of deletion reservation D111, is pending. Step S236 is identical to step S67 in the first embodiment, so a detailed explanation is omitted.

[0382] <Processing performed by mobile device 40M after receiving confirmation request D112> When the mobile device 40M, which is the first device 30A, receives the pending notification M112 and the confirmation request D112, the mobile device 40M performs the process in step S237. In step S236, the mobile device 40M presents an image to the HMI 32 that allows the user of the mobile device 40M to choose whether or not to allow the deletion of the third digital key DK3, which has been reserved for deletion D111. Since step S236 is the same as step S116 in the second embodiment, a detailed explanation is omitted.

[0383] <Step S237: If YES> If the user of the mobile device 40M selects "YES" using the radio button shown in Figure 17 and then presses "OK" (step S237: YES), the mobile device 40M performs the process shown in step S238 in Figure 34. In the process of step S238, the mobile device 40M generates a permission notification M113. The permission notification M113 is a notification that permits the deletion of the third digital key DK3, which is the target of the deletion reservation D111. The mobile device 40M sends the permission notification M113 to the third device 30C.

[0384] When the third device 30C receives the permission notification M113, it performs the process in step S239. In the process in step S239, the third device 30C generates the permission notification M114. The permission notification M114 is a notification that permits the deletion of the third digital key DK3, which is the target of the deletion reservation D111. The third device 30C sends the permission notification M114 to the management server 70.

[0385] When the management server 70 receives the permission notification M114, it performs the process in step S240. In step S240, the management server 70 confirms that the default condition RC is met. If the default condition RC is met, the management system 10 proceeds to the deletion process DP. The deletion process DP is a series of processes from steps S69 to S75 shown in Figure 14. After completing the deletion process DP, the management system 10 executes a series of processes from steps S76 to S80 shown in Figure 11. After that, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0386] <Step S237: If NO> If the user of mobile device 40M selects "NO" using the radio button shown in Figure 17 and then presses "OK" (step S237: NO), mobile device 40M performs the process shown in step S241 in Figure 34. In the process of step S241, mobile device 40M generates a rejection notice M115. The rejection notice M115 is a notification rejecting the deletion of the third digital key DK3, which has a deletion reservation D81. Mobile device 40M sends the rejection notice M115 to the third device 30C.

[0387] When the third device 30C receives rejection notification M115, it performs the process in step S242. In step S242, the third device 30C generates rejection notification M116. Rejection notification M116 is a notification rejecting the deletion of the third digital key DK3, which is the target of deletion reservation D111. The third device 30C sends rejection notification M116 to the management server 70. In other words, when the third device 30C receives rejection notification M115, it does not execute the process to delete the third digital key DK3, which is the target of deletion reservation D111.

[0388] When the management server 70 receives rejection notification M116, it performs the process in step S243. In step S243, the management server 70 cancels the fade-out state. If the management server 70 receives rejection notification M116, the management system 10 does not perform the deletion process DP to delete the third digital key DK3 which is the target of the deletion reservation D111.

[0389] After sending a rejection notification M116 to the management server 70, the third device 30C proceeds to step S244. In step S244, the third device 30C presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D111, has been released. Subsequently, the third device 30C proceeds to step S245.

[0390] In step S245, the third device 30C generates a release notification M117. The release notification M117 includes information indicating that the fade-out state of the third digital key DK3 is released. Subsequently, the third device 30C sends a release notification M86 to the multiple devices 30 and the vehicle 20 to which the pending notification M112 was sent in the processing of step S235. Specifically, the third device 30C sends the release notification M117 to the mobile device 40M and the vehicle 20. Furthermore, the third device 30C also sends the release notification M117 to the second device 30B.

[0391] When the mobile device 40M receives the release notification M117, the mobile device 40M performs the process in step S246. In step S246, the mobile device 40M presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D111, is released. Step S246 is identical to step S186 in the fifth embodiment, so a detailed explanation is omitted.

[0392] When the second device 30B receives the release notification M117, the second device 30B performs the process in step S247. In step S247, the second device 30B presents information to the HMI 32 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D111, is being released. For example, the second device 30B displays an image to the HMI 32 indicating that the fade-out state of the third digital key DK3 is being released.

[0393] When vehicle 20 receives the release notification M117, vehicle 20 performs the process in step S248. In step S248, vehicle 20 presents information to HMI 22 indicating that the fade-out state of the third digital key DK3, which is the target of the deletion reservation D111, is being released. Step S248 is identical to step S188 in the fifth embodiment, so a detailed explanation is omitted. Subsequently, the management system 10 completes the series of processes for the deletion of the third digital key DK3.

[0394] <Operation of the 8th Embodiment> Even if the user of the second device 30B wishes to delete the third digital key DK3, other users may not wish to delete the third digital key DK3. The notification program PM2 causes the execution device 36 of the third device 30C to send a confirmation request D112 along with a pending notification M112 to the device 30 belonging to the user of the device 30 other than the second device 30B that sent the deletion reservation D111. The confirmation request D112 is a request to allow or deny the deletion of the third digital key DK3.

[0395] <Effects of the 8th Embodiment> In the eighth embodiment, in addition to the effects (7-1) to (7-5) of the seventh embodiment, the following further effects are achieved.

[0396] (8-1) When the process of deleting the third digital key DK3 is executed, the notification program PM2 can reflect the opinions of users who do not want the third digital key DK3 to be deleted.

[0397] (8-2) The notification program PM2 causes the execution device 36 to execute a process to send a confirmation request D112 to the first device 30A which stores information about the first digital key DK1 which is higher in rank than the third digital key DK3 which is the target of the deletion reservation D111. Even if a user wants to delete the third digital key DK3, the user of device 30 which stores information about a digital key higher in rank than the third digital key DK3 may not want the third digital key DK3 to be deleted. When the process to delete the third digital key DK3 is executed, the notification program PM2 can reflect the opinion of the user of device 30 which stores information about the first digital key DK1 which is higher in rank than the third digital key DK3.

[0398] (8-3) The notification program PM2 causes the execution device 36 to execute a process to send a confirmation request D112 to the owner device 40, which is a device 30 belonging to the owner of the vehicle 20. Even if a user wants to delete the digital key, the user of the owner device 40 may not want to delete the digital key. The notification program PM2 can reflect the opinion of the user of the owner device 40 when the process to delete the digital key is executed.

[0399] <Example of modification of the 8th embodiment> The eighth embodiment described above can be implemented with the following modifications. The modifications to the fifth embodiment described above and the eighth embodiment described below can be combined with each other to the extent that they do not contradict each other technically.

[0400] The notification program PM2 may cause the execution device 36 to execute a process to send a confirmation request D112 to a device 30 other than the device 30 that stores information about a digital key higher than the third digital key DK3 which is the target of the deletion reservation D111.

[0401] As shown in Figure 32, the device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D112 includes a plurality of friend devices 51. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D112 includes a plurality of non-friend devices 52. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D112 includes a plurality of devices 40BO belonging to the owner of the vehicle 20. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D112 includes a plurality of devices 51BF belonging to the users of the plurality of friend devices 51. The device 30 to which the notification program PM2 causes the execution device 36 to send confirmation request D112 includes a plurality of devices 52BNF belonging to the users of the plurality of non-friend devices 52.

[0402] The destination to which the notification program PM2 causes the execution device 36 to send the confirmation request D112 can be changed as appropriate. For example, the notification program PM2 may cause the execution device 36 to send the confirmation request D112 to device 30 which stores information about digital keys that have a direct relationship to the digital key that is the target of the deletion reservation D111. The notification program PM2 does not have to cause the execution device 36 to send the confirmation request D112 to device 30 which stores information about digital keys that are higher in rank than the digital key that has been subject to the deletion reservation D111. The notification program PM2 does not have to cause the execution device 36 to send the confirmation request D112 to owner device 40.

[0403] The notification program PM2 may instruct the execution device 36 to send an acknowledgment request D112 to multiple devices 30. In this case, the conditions for the execution device 36 to send a rejection notification M116 to the management server 70 can be set as appropriate. In other words, the conditions for canceling the fade-out state can be set as appropriate. For example, the notification program PM2 may set a condition for the execution device 36 to send a rejection notification M116 to the management server 70 when the third device 30C receives a rejection notification M115 from all of the multiple devices 30 to which the acknowledgment request D112 was sent. For example, the notification program PM2 may set a condition for the execution device 36 to send a rejection notification M116 to the management server 70 when it receives a rejection notification M115 from more than half of the multiple devices 30 to which the acknowledgment request D112 was sent. For example, if the notification program PM2 receives an authorization notification M113 from device 30 that stores information about the highest-level digital key, it may set a condition to cause the execution device 36 to send an authorization notification M114 to the management server 70, even if it receives a rejection notification M115 from another device 30, so as not to cancel the fade-out state. For example, if the notification program PM2 receives a rejection notification M115 from at least one device 30, it may set a condition to cause the execution device 36 to send a rejection notification M116 to the management server 70, even if it receives an authorization notification M113 from another device 30.

[0404] (Ninth Embodiment) The management system 10 according to the ninth embodiment will be described below with reference to Figures 11, 21, 35, and 36. The ninth embodiment will be described primarily for its differences from the sixth embodiment. In the ninth embodiment, the owner device 40 is a virtual device 40V. In the ninth embodiment, when a digital key that has been reserved for deletion D121 is deleted, digital keys lower in rank than the digital key that has been reserved for deletion D121 are also deleted. The following will focus on the differences from the sixth embodiment, and the same points will be simplified or omitted.

[0405] As shown in Figure 21, the storage device 37 of the friend device 51 stores the notification program PM2. When the device 30 that stores the notification program PM2 receives a pending notification M121, the notification program PM2 executes a process to exclude devices 30 that store information on digital keys lower than the digital key targeted by the deletion reservation D121 from the targets for sending the pending notification M122, and then sends the pending notification M122.

[0406] As shown in Figure 35, when an operation is performed in the virtual device 40V to request the deletion of the second digital key DK2, the virtual device 40V first performs the process in step S250. In step S250, the virtual device 40V generates a deletion reservation D121 for the second digital key DK2. Since the deletion reservation D121 is the same as the deletion reservation D61 in the third embodiment, a detailed explanation is omitted. The virtual device 40V sends the deletion reservation D121 to the management server 70.

[0407] Subsequently, when the management server 70 receives the deletion reservation D121, it performs the process in step S251. In step S251, the management server 70 stores in the database DB the state of the second digital key DK2, which is the target of the deletion reservation D121, as a fade-out state. After that, the management server 70 proceeds to step S252.

[0408] In step S252, the management server 70 generates a pending notification M121 indicating that the state of the digital key requested for deletion by the deletion reservation D121 is in the fade-out state.

[0409] The management server 70 sends a pending notification M121 to the virtual device 40V. The management server 70 also sends a pending notification M121 to the second device 30B, which stores information about the second digital key DK2 that has been reserved for deletion D121. The second device 30B is the friend device 51.

[0410] When the virtual device 40V receives the pending notification M121, the virtual device 40V performs the process in step S253. In step S253, the virtual device 40V presents information indicating that the deletion of the second digital key DK2, which is the target of the deletion reservation D121, is pending. Step S253 is identical to step S143 in the third embodiment, so a detailed explanation is omitted.

[0411] When the second device 30B receives the pending notification M121, the second device 30B performs the process in step S254. In step S254, the second device 30B presents information to the HMI 32 indicating that the deletion of the second digital key DK2, which is the target of the deletion reservation D121, is pending. Step S254 is the same as step S144 in the third embodiment, so a detailed explanation is omitted. After that, the second device 30B proceeds to step S255.

[0412] In step S255, the second device 30B generates a pending notification M122 indicating that the state of the digital key requested for deletion by the deletion reservation D121 is in a fade-out state.

[0413] <Regarding the recipient of the pending notification M122> The second device 30B changes the destination of the pending notification M122 depending on whether the owner device 40 is a virtual device 40V or not. When the second device 30B generates a pending notification M122, it performs a series of processes to determine the destination of the pending notification M122.

[0414] As shown in Figure 36, when this series of processes is started, in step S102, the second device 30B obtains information indicating whether or not the owner device 40 is a virtual device 40V. Specifically, the second device 30B obtains classification information TI stored in the storage device 72 of the management server 70 from the management server 70. By referring to the classification information TI, the second device 30B determines whether or not the owner device 40 is a virtual device 40V. If the owner device 40 is not a virtual device 40V (step S102: NO), the second device 30B proceeds to step S103.

[0415] In step S103, the second device 30B decides to send a pending notification M122 to devices 30 belonging to users other than the owner device 40 that sent the deletion reservation D121.

[0416] In other words, the notification program PM2 instructs the second device 30B to send a pending notification M122 to devices 30 belonging to users other than the user of the owner device 40 that sent the deletion reservation D121. After that, the second device 30B completes the series of processes shown in Figure 36.

[0417] If the owner device 40 is the virtual device 40V (step S102: YES), the second device 30B proceeds to step S104. In step S104, the second device 30B decides to send the pending notification M122 to devices 30 belonging to users other than the owner device 40 that sent the deletion reservation D122, and which store information about digital keys lower than the second digital key DK2.

[0418] In other words, the notification program PM2 instructs the second device 30B to exclude devices 30 belonging to users other than the owner device 40 that sent the deletion reservation D121, and which store information about digital keys lower than the second digital key DK2, from the target for sending the pending notification M122, and then to send the pending notification M122. After that, the second device 30B completes the series of processes shown in Figure 36.

[0419] As shown in Figure 35, the owner device 40 in the ninth embodiment is a virtual device 40V. Therefore, the second device 30B sends a pending notification M122 to the vehicle 20. The second device 30B does not send a pending notification M122 to the third device 30C, which stores information about the third digital key DK3 that is lower in rank than the second digital key DK2 that has been reserved for deletion D121.

[0420] When vehicle 20 receives pending notification M122, vehicle 20 performs the process in step S256. In step S256, vehicle 20 presents information to HMI 22 indicating that the deletion of the third digital key DK3 is pending. Step S256 is identical to step S145 in the third embodiment, so a detailed explanation is omitted.

[0421] Subsequently, the management system 10 deletes the second digital key DK2 by performing the same processing as shown in step S68 and later in Figure 11. In this case, the deletion process DP is performed by the second device 30B, the management server 70, and the vehicle 20. Subsequently, the management system 10 deletes the third digital key DK3 by performing the same processing as shown in step S68 and later in Figure 11. In this case, the deletion process DP is performed by the third device 30C, the management server 70, and the vehicle 20.

[0422] <Operation of the 9th Embodiment> Examples of cases where the owner device 40 is a virtual device 40V include cases where a rental company or a sharing company is the owner of the vehicle 20. When a rental company or the like is the owner of the vehicle 20, the system may be configured so that when the digital key targeted by deletion reservation D121 is deleted, lower-level digital keys are also deleted.

[0423] In this case, if a pending notification M122 is sent to the third device 30C, which stores information about the third digital key DK3, which is lower in rank than the second digital key DK2 for which deletion reservation D121 has been made, the user of the third device 30C will receive an unnecessary notification.

[0424] <Effects of the 9th Embodiment> In the ninth embodiment, in addition to the effects (7-1) and (7-3) of the seventh embodiment, the following further effects are achieved.

[0425] (9-1) When the notification program PM2 receives a pending notification M121, it instructs the execution device 36 to send a pending notification M122, excluding notifications that are unnecessary for the user. As a result, the user does not receive any unnecessary notifications.

[0426] <Other examples of changes> Other elements that can be modified in common with each of the above embodiments are as follows. The following examples of modifications can be combined with each other to the extent that they do not contradict each other technically.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0449] 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).

[0450] 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 10.

[0451] <Note> The technical concepts that can be understood from the above embodiments and modified examples are described below. [Note 1] A management server that communicates with a vehicle and multiple devices and manages information about digital keys that are available for registration with the vehicle, and comprises a processing circuit, wherein when the processing circuit receives a deletion request from a device that stores information about the digital keys registered with the vehicle to delete a digital key registered with the same vehicle as the vehicle, it stores the state of the digital key to be deleted as a fade-out state in which the digital key will be deleted if a predetermined condition is met, and sends a pending notification to a device belonging to a user other than the user of the device that sent the deletion request, among the multiple devices that store information about the digital keys registered with the same vehicle, indicating that the state of the digital key to be deleted is the fade-out state.

[0452] [Note 2] The management server described in Note 1, which sends the pending notification to the device that stores the information regarding the digital key for which deletion has been requested. [Note 3] The management server described in Note 1 or Note 2 that sends the pending notification to a device that stores information about digital keys that have a direct relationship to the digital key for which deletion has been requested.

[0453] [Note 4] A management server described in any one of Notes 1 to 3 that sends the pending notification to a device that stores information about a digital key higher than the digital key for which deletion has been requested.

[0454] [Note 5] A management server described in any one of Notes 1 to 4 that sends the pending notification to the owner device, which is a device belonging to the owner of the vehicle. [Note 6] A management server described in any one of Notes 1 to 5 that sends information indicating the device that sent the deletion request along with the pending notification.

[0455] [Note 7] A management server as described in any one of Notes 1 to 6 that, along with the pending notification, sends a confirmation request to allow the user to choose whether or not to permit the deletion of the digital key that has been requested to be deleted, and if it receives a rejection notification from the device to which the confirmation request was sent refusing to perform the deletion of the digital key that has been requested to be deleted, does not perform the process of deleting the digital key that has been requested to be deleted.

[0456] [Note 8] A management server as described in any one of Notes 1 to 7, which transmits the confirmation request to a device that stores information about a digital key higher in rank than the digital key that was requested to be deleted.

[0457] [Note 9] A management server as described in any one of Notes 1 to 8, which transmits the confirmation request to the owner device, which is a device belonging to the owner of the vehicle. [Note 10] A management server described in any one of Notes 1 to 9, configured to change the information transmitted when the owner device, which is a device belonging to the owner of the vehicle, is a personal device, or when the owner device is a virtual device built on a server.

[0458] [Note 11] The management server as described in Note 10, which does not send information about the device that sent the deletion request to the owner device if the owner device is a virtual device built on the server.

[0459] [Note 12] If the owner device is the virtual device configured on the server, the management server according to Note 10 or Note 11 does not send the pending notification to a device that stores information about a digital key lower than the digital key being deleted when it receives the deletion request from the owner device.

[0460] [Note 13] A notification program stored in the storage device of a digital key system in which multiple devices store information about digital keys that can be registered to a vehicle, and the multiple devices function as digital keys registered to the vehicle, and which is executed by the processing circuit of the device, wherein when the device in which the notification program is stored in the storage device sends a deletion request to delete a digital key registered to the same vehicle that the device can use as a digital key, the notification program causes the processing circuit of the device to execute a process to send a pending notification to the devices belonging to users other than the user of the device that sent the deletion request, among the multiple devices that store information about digital keys registered to the same vehicle, indicating that the state of the digital key to be deleted is a fade-out state in which the digital key will be deleted if a predetermined condition is met.

[0461] [Note 14] A notification program stored in the storage device of a device and executed by the processing circuit of the device in a digital key system in which multiple devices store information about digital keys that can be registered to a vehicle, and the multiple devices function as digital keys registered to the vehicle, wherein when the device in which the notification program is stored in the storage device receives a pending notification indicating that the state of the digital key of the device is a fade-out state in which the digital key will be deleted when a predetermined condition is met, the notification program causes the processing circuit of the device to execute a process to send the pending notification to a device belonging to a user other than the user of the device that sent the request to delete the digital key of the device, among the multiple devices that store information about digital keys registered to the same vehicle as the vehicle in which the device can be used as the digital key.

[0462] [Note 15] The notification program described in Note 13, which causes the processing circuit to execute the process of sending the pending notification to a device that stores information regarding the digital key that has been requested to be deleted.

[0463] [Note 16] The notification program described in Note 13 or Note 14, which causes the processing circuit to execute the process of sending the pending notification to a device that stores information about a digital key that has a direct relationship with the digital key that has been requested to be deleted.

[0464] [Note 17] A notification program according to any one of Notes 13 to 16 that causes the processing circuit to execute a process to send the pending notification to a device that stores information about a digital key higher than the digital key that was requested to be deleted.

[0465] [Note 18] A notification program described in any one of Notes 13 to 17 that causes the processing circuit to execute a process to send the pending notification to the owner device, which is a device belonging to the owner of the vehicle.

[0466] [Note 19] A notification program described in any one of Notes 13 to 18 that causes the processing circuit to perform a process of transmitting information indicating the device that sent the deletion request, along with the pending notification.

[0467] [Note 20] A notification program as described in any one of Notes 13 to 19, which causes the processing circuit to execute a process to send a confirmation request to the processing circuit, along with the pending notification, to allow or deny the deletion of the digital key that has been requested to be deleted, and if a rejection notification is received from the device to which the confirmation request was sent, refusing to execute the deletion of the digital key that has been requested to be deleted, the program does not execute the process to delete the digital key that has been requested to be deleted.

[0468] [Note 21] The notification program described in Note 20, which causes the processing circuit to perform the process of sending the confirmation request to a device that stores information about a digital key higher than the digital key that was requested to be deleted.

[0469] [Note 22] The notification program described in Note 20 or Note 21, which causes the processing circuit to execute a process of sending the confirmation request to an owner device which is a device belonging to the owner of the vehicle.

[0470] [Note 23] If the owner device, which is a device belonging to the owner of the vehicle, is a virtual device built on a server, the notification program described in any one of Notes 13 to 22 causes the owner device's processing circuit to execute a process to exclude devices that store information about digital keys lower than the digital key being deleted from the targets for sending the pending notification and to send the pending notification.

[0471] [Note 24] If the owner device, which is a device belonging to the owner of the vehicle, is a virtual device built on a server, the notification program described in any one of Notes 14 to 23 causes the processing circuit to execute a process to exclude devices that store information about digital keys lower than the digital key that was requested to be deleted from the targets for sending the pending notification and to send the pending notification.

[0472] [Note 25] A notification program as described in any one of Notes 19 to 24, which causes the processing circuit to execute a process to send information indicating the device that sent the deletion request along with the pending notification, and if the owner device, which is a device belonging to the owner of the vehicle, is a virtual device configured on the server, causes the processing circuit to execute a process to send the pending notification to the owner device, excluding the information of the device that sent the deletion request. [Explanation of Symbols]

[0473] 20... Vehicles 30…Device 37, 72…Storage device 40… Owner devices 70... Management Server 40V...Virtual device D52, D82, D112…Confirmation request M41, M51, M61, M71, M81, M91, M102, M112, M122…Pending notification M53, M85, M116… Rejection Notice PM2... Notification Program RC…Default condition

Claims

1. A management server that communicates with a vehicle and multiple devices and manages information regarding digital keys that can be registered with the vehicle. It includes a processing circuit, and the processing circuit is When the device storing information about the digital key registered in the vehicle receives a deletion request to delete a digital key registered in the same vehicle as the vehicle, The state of the digital key for which deletion has been requested is stored as a fade-out state in which the digital key is deleted when the default conditions are met, To perform the following actions: Send a pending notification to a device belonging to a user other than the user of the device that sent the deletion request, among the multiple devices that store information about the digital keys registered in the same vehicle, indicating that the state of the digital key to be deleted is the fade-out state. Management server.

2. The pending notification is sent to the device that stores information regarding the digital key for which deletion has been requested. The management server according to claim 1.

3. The pending notification is sent to the device that stores information about digital keys that have a direct relationship to the digital key that has been requested to be deleted. The management server according to claim 1.

4. Send the pending notification to the device that stores information about a digital key higher than the digital key that was requested to be deleted. The management server according to claim 3.

5. The pending notification is sent to the owner device, which is a device belonging to the owner of the vehicle. The management server according to claim 4.

6. Along with the pending notification, information indicating the device that sent the deletion request will be sent. A management server according to any one of claims 1 to 5.

7. Along with the pending notification, a confirmation request is sent asking the user whether or not to allow the deletion of the digital key that was requested to be deleted. If a rejection notice is received from the device to which the confirmation request was sent, refusing to delete the requested digital key, the process of deleting the requested digital key will not be executed. The management server according to claim 1.

8. The aforementioned confirmation request is sent to a device that stores information about a digital key higher in rank than the digital key being requested to be deleted. The management server according to claim 7.

9. The aforementioned confirmation request is sent to the owner device, which is a device belonging to the owner of the vehicle. The management server according to claim 8.

10. The information transmitted is configured to change depending on whether the owner device, which belongs to the owner of the vehicle, is a personal device or a virtual device built on a server. The management server according to claim 1.

11. If the owner device is the virtual device built on the server, then the information of the device that sent the deletion request will not be sent to the owner device. The management server according to claim 10.

12. If the owner device is the virtual device configured on the server, When the owner device receives the deletion request, it does not send the pending notification to a device that stores information about a digital key lower than the digital key being deleted. The management server according to claim 10.

13. A notification program stored in the storage device of a digital key system that allows multiple devices to store information about digital keys that can be registered with a vehicle, and which allows the multiple devices to function as digital keys registered with the vehicle, and which is executed by the processing circuit of the device. When the device in which the notification program is stored in the storage device sends a deletion request to delete a digital key registered to the same vehicle that the device can use as the digital key, The processing circuit of the device, Among the multiple devices that store information about digital keys registered in the same vehicle, the device belonging to a user other than the user of the device that sent the deletion request executes a process to send a pending notification indicating that the state of the digital key to be deleted will be a fade-out state in which the digital key will be deleted if the default conditions are met. Notification program.

14. A notification program stored in the storage device of a digital key system that allows multiple devices to store information about digital keys that can be registered with a vehicle, and which allows the multiple devices to function as digital keys registered with the vehicle, and which is executed by the processing circuit of the device. When the device in which the notification program is stored in the storage device receives a pending notification indicating that the state of the digital key on the device is in a fade-out state where the digital key will be deleted if a predetermined condition is met, The processing circuit of the device, The process of sending the pending notification to a device belonging to a user other than the user of the device that sent the request to delete the digital key, among the multiple devices that store information about digital keys registered to the same vehicle as the vehicle that the device can use as the digital key. Notification program.

15. The processing circuit, The process of sending the pending notification to the device that stores the information regarding the digital key to be deleted is initiated. The notification program according to claim 13.

16. The processing circuit, The process of sending the pending notification to a device that stores information about digital keys directly related to the digital key being requested to be deleted is initiated. The notification program according to claim 13 or claim 14.

17. The processing circuit, The process of sending the pending notification to a device that stores information about a digital key higher than the digital key being requested to be deleted is initiated. The notification program according to claim 16.

18. The processing circuit, The process of sending the pending notification to the owner device, which is a device belonging to the owner of the vehicle, is executed. The notification program according to claim 17.

19. The processing circuit, Along with the pending notification, the system will execute a process to send information indicating the device that sent the deletion request. The notification program according to claim 13 or claim 14.

20. The processing circuit, Along with the pending notification, the system executes a process to send a confirmation request asking whether or not to allow the deletion of the digital key that was requested to be deleted. If a rejection notice is received from the device to which the confirmation request was sent, refusing to perform the deletion of the requested digital key, the process of deleting the requested digital key will not be executed. The notification program according to claim 13 or claim 14.

21. The processing circuit, This process causes the device to send the aforementioned confirmation request to a device that stores information about a digital key higher than the digital key being deleted. The notification program according to claim 20.

22. The processing circuit, This process causes the aforementioned confirmation request to be sent to the owner device, which is a device belonging to the owner of the vehicle. The notification program according to claim 21.

23. If the owner device, which belongs to the owner of the aforementioned vehicle, is a virtual device built on a server, When the owner device sends the deletion request, The processing circuit of the owner device, The process of sending the pending notification is executed while excluding devices that store information about digital keys lower in rank than the digital key that was requested to be deleted from the list of recipients of the pending notification. The notification program according to claim 13.

24. If the owner device, which belongs to the owner of the aforementioned vehicle, is a virtual device built on a server, The processing circuit, When the pending notification is received, the system executes a process to exclude devices that store information about digital keys lower in rank than the digital key that was requested to be deleted from the list of recipients of the pending notification, and then proceed to send the pending notification. The notification program according to claim 14.

25. The processing circuit, Along with the pending notification, the process is executed to send information indicating the device that sent the deletion request. If the owner device, which belongs to the owner of the vehicle, is a virtual device configured on a server, The processing circuit, The process is executed to send the pending notification to the owner device, excluding the information of the device that sent the deletion request. The notification program according to claim 19.

Images