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

Abstract

To provide a management server for reducing a load on a user in work for deleting a plurality of digital keys.SOLUTION: When receiving the deletion request D61 specifying the registered share key KS, the management server 70 executes a deletion process DEL for deleting the share key KS registered in the target share device in which the share key KS specified in the received deletion request D61 is registered and another share device 50 in which the share key KS is registered based on a request from the target share device.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present invention relates to a management server for managing digital keys, a management system, a method for deleting digital keys, and a deletion program. [Background technology]

[0002] Patent Document 1 discloses a digital key system technology that uses a device such as a smartphone as a vehicle key. The digital key system stores information about the digital key in the vehicle. The digital key system also stores information about the digital key in a device. This allows the vehicle to be used using the device registered as a digital key without the need for a physical key. Furthermore, the digital key system issues a registration request to enable another person's device to function as a digital key through communication between the device storing information about the digital key and the other person's device. This allows the other person's device to be registered as a digital key to the vehicle. In other words, the digital key can generate a new digital key. The digital key system also allows the vehicle to be loaned to another person without the need to exchange a physical key. [Prior art documents] [Patent documents]

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

[0004] When multiple digital keys are registered for a single vehicle, a user who wants to delete multiple digital keys must individually select each digital key to delete from the many digital keys. This places a heavy burden on the user, as it is a task to delete multiple digital keys. [Means for solving the problem]

[0005] The management server for solving the above problem is a management server that manages multiple digital keys that are usable for vehicles, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a share key registered for a share device that is a device other than the owner device. When the management server receives a deletion request that identifies the registered share key, it executes a deletion process that deletes the share key registered in a target share device to which the share key identified in the received deletion request is registered, and in another share device to which the share key is registered based on a request from the target share device.

[0006] A management system for solving the above problem includes a vehicle, a plurality of digital keys usable for the vehicle, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a share key registered for a share device that is a device separate from the owner device, and a management server that manages the plurality of digital keys. When the management server receives a deletion request that identifies a registered share key, the management system executes a deletion process to delete the share key registered in a target share device to which the share key identified in the received deletion request is registered, and in another share device to which the share key is registered based on a request from the target share device.

[0007] A digital key deletion method for solving the above problem is executed by a management server that manages multiple digital keys that can be used for a vehicle, including an owner key registered for an owner device that belongs to the vehicle owner and a share key registered for a share device that is a device other than the owner device. The digital key deletion method includes a step in which, upon receiving a deletion request that identifies the registered share key, a processing circuit of the management server generates a deletion command that instructs the management server to delete the registered share key. The digital key deletion method includes a step in which the processing circuit of the management server executes a deletion process to delete the share key registered in a target share device to which the share key identified in the received deletion request is registered and in another share device to which the share key is registered based on a request from the target share device.

[0008] The notification program for solving the above problem is a deletion program stored in a storage device of a management server that manages multiple digital keys that can be used for a vehicle, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle and a share key registered for a share device that is a device other than the owner device. When a deletion request specifying a registered share key is received, the deletion program causes a processing circuit of the management server to execute a process of generating a deletion command that commands the registered share key to be deleted. The deletion program causes the processing circuit of the management server to execute a deletion process that deletes the share key registered in a target share device in which the share key specified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device. [Effects of the Invention]

[0009] The management server, management system, digital key deletion method, and deletion program described above enable multiple digital keys to be deleted at once without the user having to individually select the digital keys they want to delete, thereby reducing the burden on the user in deleting multiple digital keys. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a schematic diagram showing a management system. [Figure 2] FIG. 2 is a schematic diagram showing owner key information. [Figure 3] FIG. 3 is a schematic diagram showing the share key information. [Figure 4] FIG. 4 is a schematic diagram showing the data in the database. [Figure 5] FIG. 5 is an explanatory diagram showing a series of processes performed by the management system when an owner key is registered. [Figure 6] FIG. 6 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered. [Figure 7] FIG. 7 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered. [Figure 8] FIG. 8 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a friend device. [Figure 9] FIG. 9 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a non-friend device. [Figure 10] FIG. 10 is an explanatory diagram showing a series of processes performed by the management system when multiple share keys are deleted in response to a request from the owner device. [Figure 11] FIG. 11 is a schematic diagram showing the relationship between a plurality of shared devices. [Figure 12] FIG. 12 is a flowchart showing the flow of the process executed by the management server in FIG. [Figure 13] FIG. 13 shows an example of an image displayed to prompt the user to select a share key to be protected. [Figure 14] FIG. 14 is a schematic diagram showing the deletion process executed by the management server in FIG. [Figure 15] FIG. 15 is a schematic diagram showing the relationship between a plurality of share devices in a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0011] A management system 10 according to an embodiment will be described below with reference to FIGS. <Outline of Management System 10> As shown in FIG. 1 , the management server 70 is one of the devices that make up the management system 10. The management server 70 manages information related to a plurality of digital keys that can be registered to a vehicle 20. There is a standard for digital keys, the Car Connectivity Consortium (CCC). Matters related to the digital keys in this embodiment comply with the CCC. The management system 10 includes the vehicle 20, a plurality of devices 30, a device server 60, and the management server 70.

[0012] The vehicle 20 has 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 network. The HMI 22 includes an input device that accepts operations by the user of the vehicle 20 and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

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

[0015] The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. The execution device 27 executes the vehicle program PV, causing the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating the digital key so that the vehicle 20 can be controlled using the digital key when the digital key is used. The authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU. The execution device 27 executes the vehicle program PV to perform processes related to the storage and deletion of the authentication information AT. The authentication information AT is information related to the digital key.

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

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

[0018] The communication module 31 communicates with the device server 60 via a wireless communication line. The HMI 32 includes an input device that accepts operations by the user of the device 30, and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

[0019] The BLE module 33 performs short-range communication with the vehicle 20 by BLE communication. The UWB module 34 performs short-range communication with the vehicle 20 by UWB communication. The NFC module 35 performs short-range communication with the vehicle 20 by NFC communication.

[0020] The storage device 37 stores a device program PD and key information DK. The device program PD is executed by the execution device 36, causing the execution device 36 to store and delete the key information DK. The key information DK is information indicating a digital key. In other words, the key information DK is information related to the 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 the functions of pairing devices 30 and sharing digital keys using APIs provided by the OS. The execution unit 36 ​​executes the device program PD to perform processes related to the storage and deletion of key information DK.

[0022] The multiple devices 30 include an owner device 40 and multiple shared devices 50. The owner device 40 is a device 30 that belongs to the owner of the vehicle 20. The owner device 40 stores owner key information DKO indicating the owner key KO as key information DK. The owner key information DKO is information related to the owner key KO. Only one owner key KO can be registered to one vehicle 20. Therefore, only one owner key KO exists for one vehicle 20.

[0023] 2, the owner key information DKO has owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, in-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 permission public key information ST8.

[0024] The vehicle identification information ST1 is information for identifying the vehicle 20 for which the digital key is to be set, for example, the ID of the vehicle 20. The intra-device key identification information ST2 is used to manage the digital key within the device 30. The intra-device key identification information ST2 is information that can identify the digital key within the application of the device 30.

[0025] The digital key identification information ST3 is used for managing the digital key in the management server 70. The slot identification information ST4 is information that can identify the digital key locally on the device 30.

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

[0027] As shown in FIG. 1, the shared device 50 stores shared key information DKS indicating a shared key KS as key information DK. The shared key information DKS is information related to the shared key KS. A shared key KS is a digital key that can be registered in multiple numbers for one vehicle 20 when registering the digital key to enable use of the digital key. In other words, multiple shared keys KS can exist for one vehicle 20.

[0028] The multiple share devices 50 include a friend device 51 and a non-friend device 52. The friend device 51 stores, as the share key information DKS, friend key information DKF indicating the friend key KF. The friend key information DKF is information related to the share key KS. The non-friend device 52 stores, as the share key information DKS, non-friend key information DKN indicating the non-friend key KN. The non-friend key information DKN is information related to the share key KS. In other words, the types of share key KS include the friend key KF and the non-friend key KN.

[0029] The friend key KF is a shared key KS registered based on a registration request D21 sent directly from the owner device 40, as will be described later. The registration request D21 is a request to store friend key information DKF, which is key information DK, in the device 30. In other words, the registration request D21 is a request to store information related to a new shared key KS in another device 30.

[0030] The non-friend key KN is a shared key KS registered based on a registration request D31 from a friend device 51, as will be described later. The registration request D31 is a request to store non-friend key information DKN, which is new shared key information DKS, in the device 30. In other words, the registration request D31 is a request to store information related to the new shared key KS in another device 30. The non-friend key KN is a shared key KS registered based on an indirect registration request from a shared device 50, which is a device 30 other than the owner device 40.

[0031] Note that a state in which a digital key is registered means that the digital key is usable. That is, when a digital key is registered, the vehicle 20 stores authentication information AT corresponding to the key information DK, and the device 30 stores key information DK corresponding to the authentication information AT. The authentication information AT is information related to the digital key. That is, when a digital key is registered, the vehicle 20 stores information related to the digital key. The key information DK is information related to the digital key. That is, when a digital key is registered, the device 30 stores information related to the digital key. If the key information DK is information related to the shared key KS, the authentication information AT corresponding to the key information DK is also information related to the shared key KS.

[0032] As shown in Fig. 3, the shared key information DKS has shared key structure information STS and an authentication package ATP. The shared key structure information STS includes vehicle identification information ST1, in-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The shared key structure information STS includes certificate information ST5, vehicle public key information ST7, and permission public key information ST8. In other words, the shared key structure information STS is information obtained by excluding device public key information ST6 from the owner key structure information STO.

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

[0034] The signature information ATP1 indicates that the shared device 50 is a legitimate party with which the digital key is shared. For example, in the case of the friend device 51, it indicates a signature by the owner device 40. The owner signature information indicates that the owner device 40 has signed the device public key PKD of the friend device 51, which is indicated by the device public key information ATP6. Also, for example, in the case of the non-friend device 52, it indicates a signature by the friend device 51. The friend signature information indicates that the friend device 51 has signed the device public key PKD of the non-friend device 52, which is indicated by the device public key information ATP6.

[0035] The password information ATP2 indicates the pairing password PAS used to establish a secure channel when pairing the vehicle 20 and the owner device 40. The validity start time information ATP3 indicates the earliest date and time at which the shared key KS can be used. The expiration date information ATP4 indicates the latest date and time at which the shared key KS can be used. The name information ATP5 indicates a name that identifies the shared device 50 that stores the shared key information DKS. For example, the name is set as an identifiable name for each shared device 50 by operation from the owner device 40.

[0036] As shown in Fig. 1, the device server 60 relays communication between the devices 30 and the management server 70. A device server 60 is provided for each type of device 30. That is, the device server 60 with which the first type of device 30 communicates is different from the device server 60 with which the second type of device 30 communicates. Each device server 60 relays communication with the management server 70, so that the different types of devices 30 can communicate with the management server 70 via the device server 60. Note that Fig. 1 illustrates only one device server 60.

[0037] <Administration Server 70> The management server 70 manages the digital key. The management server 70 is capable of communicating with the vehicle 20 and the multiple devices 30. The management server 70 includes an execution device 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 is also capable of wireless communication with the communication module 21 of the vehicle 20.

[0038] The storage device 72 stores a server program PS, a deletion program PM, and a database DB. When the server program PS is executed by the execution device 71, the execution device 71 registers a digital key in the database DB and deletes the digital key from the database DB. When the deletion program PM is executed by the execution device 71, the execution device 71 executes a process to generate a command to delete a share key KS. When the deletion program PM is executed by the execution device 71, the execution device 71 executes a process to delete a share key KS. When the execution device 71 executes the deletion program PM, the execution device 71 executes a process to generate a command to delete a share key KS. When the execution device 71 executes the deletion program PM, the execution device 71 executes a process to delete a share key KS.

[0039] In the database DB, for each of a plurality of digital keys, the corresponding vehicle 20 and the registered device 30 are associated with each other. In the database DB, data DA is separated for each vehicle 20. When a digital key is registered, the management server 70 stores, in the data DA, information indicating the device 30 that stores key information DK indicating the digital key.

[0040] The authority may be, for example, the number of share keys KS that can be requested to be registered, the range of control of the vehicle 20 that can be achieved by authenticating the digital key, etc. The higher the hierarchy, the greater the authority, and therefore, for example, the greater the number of share keys KS that can be requested to be registered. More specifically, for example, the number of friend keys KF that the owner device 40 can request to be registered is greater than the number of non-friend keys KN that the friend device 51 can request to be registered.

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

[0042] As shown in Figure 4, the data DA for one vehicle 20 includes the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. The hierarchy is determined by the type of digital key. From top to bottom, the hierarchy is arranged as follows: owner key KO, friend key KF, and non-friend key KN.

[0043] A state in which digital keys are registered to seven devices 30 for one vehicle 20 will be described. The seven devices 30 are a first device 30A, a second device 30B, a third device 30C, a fourth device 30D, a fifth device 30E, a sixth device 30F, and a seventh device 30G. The digital key registered to the first device 30A is referred to as a first digital key K1. The digital key registered to the second device 30B is referred to as a second digital key K2. The digital key registered to the third device 30C is referred to as a third digital key K3. The digital key registered to the fourth device 30D is referred to as a fourth digital key K4. The digital key registered to the fifth device 30E is referred to as a fifth digital key K5. The digital key registered to the sixth device 30F is referred to as a sixth digital key K6. The digital key registered to the seventh device 30G is referred to as a seventh digital key K7.

[0044] In the data DA, the device 30 whose digital key type is registered as the owner key KO is the first device 30A. That is, the first device 30A is the owner device 40. That is, the first digital key K1 is the owner key KO.

[0045] In the data DA, the devices 30 whose digital key type is registered as a shared key KS are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. That is, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are shared devices 50. That is, the second digital key K2, the third digital key K3, the fourth digital key K4, the fifth digital key K5, the sixth digital key K6, and the seventh digital key K7 are all shared keys KS.

[0046] More specifically, in the data DA, the devices 30 whose digital key type is registered as a friend key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are friend devices 51. In the data DA, the devices 30 whose digital key type is registered as a non-friend key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

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

[0049] In the data DA, the relationship between the third device 30C and the second device 30B is such that the non-friend 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 K3 is registered based on the second digital key K2.

[0050] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that the non-friend 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 K4 is registered based on the second digital key K2.

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

[0052] In the data DA, the relationship between the seventh device 30G and the fifth device 30E is such that the non-friend key KN is registered in the seventh device 30G based on a registration request from the fifth device 30E. In other words, the seventh digital key K7 is registered based on the fifth digital key K5.

[0053] In this way, the data DA stores the devices 30 registered as digital keys. When the device 30 is registered, the data DA is associated with information indicating the device 30 that made the request that caused the registration. The data DA also includes information indicating which digital key each digital key is registered under.

[0054] <Digital key registration> Next, a series of processes for registering digital keys in the management system 10 will be described. The management system 10 registers digital keys by registering an owner key KO, a friend key KF, and a non-friend key KN. The following describes the series of processes from when each digital key is not registered to when it is registered. In the following explanation, the process executed by the execution device 27 of the vehicle management device 26 will be described as the process executed by the vehicle 20. In the following explanation, the process executed by the execution device 36 will be described as the process executed by the device 30. In the following explanation, the process executed by the execution device 71 will be described as the process executed by the management server 70.

[0055] <Registering the owner key> 5, the management system 10 performs a series of processes to register the owner key KO. Among the devices 30 that do not store the key information DK indicating the owner key KO, the device 30 that is to be set as the owner device 40 is referred to as the first device 30A.

[0056] By registering the owner key KO, the management system 10 stores key information DK indicating the owner key KO in the first device 30A. By registering the owner key KO, the management system 10 stores authentication information AT for authenticating the owner key KO in the vehicle 20. As a result, the first device 30A becomes the owner device 40. Note that when registering the owner key KO, it is assumed that an application is installed in the first device 30A.

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

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

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

[0060] 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 transmits generation data DC for generating the owner key KO to the first device 30A via a secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. Then, the first device 30A receives the generation data DC. Then, the first device 30A proceeds to step S14.

[0061] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. After that, the first device 30A advances the process to step S15. In step S15, the first device 30A stores the owner key information DKO. As a result, the first device 30A becomes the owner device 40. That is, the registration request D11 is a request to store the owner key information DKO, which is the key information DK, in the device 30. Thereafter, the first device 30A transmits, to the vehicle 20, certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD.

[0062] Thereafter, when vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process of step S16. In step S16, vehicle 20 verifies certificate information ST5. Then, when the verification of certificate information ST5 is completed, vehicle 20 proceeds to the process of step S17.

[0063] In step S17, the vehicle 20 stores the device public key information ST6 indicating the device public key PKD as the authentication information AT. Then, the vehicle 20 transmits a completion notification M11 to the first device 30A indicating that the storage of the authentication information AT has been completed.

[0064] Thereafter, when the first device 30A receives the completion notification M11, the first device 30A performs the process of 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 requesting the management server 70 to update the database DB. Then, the first device 30A transmits the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0065] Thereafter, upon receiving the key track request D12, the management server 70 performs processing in step S19. In step S19, the management server 70 performs registration management of the owner key KO. Specifically, the management server 70 stores the first device 30A as the device 30 registered as the owner key KO in the data DA of the vehicle 20 in the database DB. This causes the management system 10 to complete the series of processes for the owner key KO.

[0066] <Friend Key KF Registration> 6, the management system 10 performs a series of processes to register a friend key KF. Among the devices 30 that do not store friend key information DKF, the device 30 that is designated as a friend device 51 through the series of processes is referred to as a second device 30B.

[0067] When an operation to request registration of a friend key KF is executed in the owner device 40, the owner device 40 first performs the process of step S21. In step S21, the owner device 40 transmits a friend key KF registration request D21 to a relay server (not shown). Thereafter, the owner device 40 proceeds to the process of step S22.

[0068] In step S22, the owner device 40 acquires invitation information IV1 for sharing the digital key from the relay server. The invitation information IV1 is, for example, a URL link. The URL link stores share information SH1 required for sharing the digital key. The owner device 40 then transmits the invitation information IV1 to the second device 30B.

[0069] After that, when the second device 30B receives the invitation information IV1, it performs the process of step S23. In step S23, the second device 30B acquires the share information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the share information SH1 from the link source of the URL link.

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

[0071] In step S24, the second device 30B uses the share information SH1 to generate unsigned friend key information DKFN. The unsigned friend key information DKFN is friend key information DKF that does not include signature information ATP1. Specifically, the second device 30B generates each piece of information included in the acquired share information SH1 as the unsigned friend key information DKFN. The second device 30B then transmits to the owner device 40 a completion notification M21 indicating that the generated unsigned friend key information DKFN has been uploaded to the URL link, and a signature request D22 requesting a signature.

[0072] Thereafter, 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 acquires the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process of step S25 in response to an operation of the owner device 40.

[0073] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 causes the HMI 32 to present the acquired unsigned friend key information DKFN, and accepts an operation by the user of the owner device 40 indicating consent to the registration of the friend key KF. When the operation is performed, the owner device 40 acquires a signature based on the operation. Thereafter, the owner device 40 proceeds to step S26.

[0074] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. As a result, the owner device 40 generates 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 transmits a completion notification M22 to the second device 30B, indicating that the completed friend key information DKF has been uploaded to the URL link.

[0075] Thereafter, the second device 30B receives the completion notification M22. Thereafter, the second device 30B performs the process of 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 a friend device 51. Thereafter, the second device 30B proceeds to the process of step S28.

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

[0077] Thereafter, when the management server 70 receives a key tracking request D23 for the friend key KF, the management server 70 performs processing in step S29. In step S29, the management server 70 performs registration management of the friend key KF. The key tracking request D23 is a request to store new authentication information AT in the vehicle 20. In other words, the key tracking request D23 is a request to store information about the digital key in the vehicle 20.

[0078] Specifically, the management server 70 verifies that the friend key KF that is the target of the key track request D23 is not on the reject list. The reject list is a list that indicates shared keys KS that include friend keys KF and non-friend keys KN for which a deletion request has already been received. If the friend key KF is on the reject list, the management server 70 sends a notification to the second device 30B that the key track request D23 cannot be fulfilled.

[0079] 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. In detail, the management server 70 stores the second device 30B as a device 30 registered as a friend device 51 in the data DA of the vehicle 20 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.

[0080] Thereafter, the management server 70 transmits the authentication package ATP of 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 transmits device public key information ST6 indicating 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 has been signed by the owner device 40.

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

[0082] After completing the registration management, the management server 70 transmits a key track completion notification M23 to the second device 30B. Thereafter, upon receiving the key track completion notification M23, the second device 30B performs the process of step S31. In the process of step S31, the second device 30B presents information indicating the completion of the registration of the friend key KF on the HMI 32. For example, the second device 30B displays an image indicating the completion of the registration of the friend key KF on the HMI 32. This causes the management system 10 to end the series of processes for registering the friend key KF.

[0083] <Registering a non-friend key KN> 7, the management system 10 performs a series of registration processes to register the non-friend key KN. Among the devices 30 that do not store the non-friend key information DKN, the device 30 that is designated as a non-friend device 52 by the series of processes is designated as a third device 30C.

[0084] When an operation to request registration of a non-friend key KN is executed in the second device 30B, which is the friend device 51, the friend device 51 first performs the process of step S41. In step S41, the friend device 51 transmits a registration request D31 of the non-friend key KN to a relay server (not shown). Thereafter, the friend device 51 proceeds to the process of step S42.

[0085] In step S42, the friend device 51 acquires 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 stores share information SH2 required for sharing the digital key. The friend device 51 then transmits the invitation information IV2 to the third device 30C.

[0086] After that, when the third device 30C receives the invitation information IV2, it performs the process of step S43. In step S43, the third device 30C acquires the share information SH2 based on the invitation information IV2. Specifically, the third device 30C downloads the share information SH2 from the URL link.

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

[0088] In step S44, the third device 30C uses the share information SH2 to generate unsigned non-friend key information DKNN. The unsigned non-friend key information DKNN is non-friend key information DKN that does not include the signature information ATP1. Specifically, the third device 30C generates each piece of information included in the acquired share information SH2 as each piece of information in the unsigned non-friend key information DKNN. The third device 30C then transmits to the friend device 51 a completion notification M31 indicating that the generated unsigned non-friend key information DKNN has been uploaded to the URL link, and a signature request D32 requesting a signature.

[0089] Thereafter, 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 acquires unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process of step S45 in response to an operation of the friend device 51.

[0090] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 causes the HMI 32 to present the acquired unsigned non-friend key information DKNN, and accepts an operation by the user of the friend device 51 indicating consent to the generation of the non-friend key KN. When the operation is performed, the friend device 51 acquires a signature based on the operation. Thereafter, the friend device 51 proceeds to step S46.

[0091] In step S46, the friend device 51 adds the signature information ATP1 to the unsigned non-friend key information DKNN. As a result, the friend device 51 generates non-friend key information DKN. Thereafter, the friend device 51 uploads the generated non-friend key information DKN to the URL link, which is the invitation information IV2. Then, the friend device 51 transmits a completion notification M32 to the third device 30C indicating that the completed non-friend key information DKN has been uploaded to the URL link.

[0092] The third device 30C then receives the completion notification M32. The third device 30C then performs the process of step S47. In step S47, the third device 30C downloads and stores the non-friend key information DKN. As a result, the third device 30C becomes a non-friend device 52. The third device 30C then proceeds to the process of step S48.

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

[0094] Thereafter, when the management server 70 receives a key track request D33 for the non-friend key KN, the management server 70 performs the process of step S49. In step S49, the management server 70 performs registration management of the non-friend key KN.

[0095] Specifically, the management server 70 confirms that the non-friend key KN that is the target of the key track request D33 is not on the reject list. If the non-friend key KN is on the reject list, the management server 70 sends a notification to the third device 30C that the key track request D33 cannot be fulfilled.

[0096] On the other hand, if the non-friend key KN is not on the rejection list, the management server 70 registers the non-friend key KN that is the subject of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the data DA of the vehicle 20 in the database DB as a device 30 registered as a non-friend 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-friend key information DKN. Specifically, the management server 70 stores the third device 30C as a device 30 having the non-friend key KN registered in response to the registration request D31 from the second device 30B.

[0097] Thereafter, the management server 70 transmits the authentication package ATP of the non-friend 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 transmits device public key information ST6 indicating the device public key PKD of the non-friend device 52 to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD is signed by the friend device 51.

[0098] Upon receiving the key track request D33, the management server 70 transmits a storage request D34 to the vehicle 20, requesting storage of the authentication package ATP, which is information about the digital key. In other words, the key track request D33 is a request to have the vehicle 20 store information about the digital key.

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

[0100] After completing the registration management, the management server 70 transmits a key track completion notification M33 to the second device 30B. Thereafter, upon receiving the key track completion notification M33, the third device 30C performs the process of step S51. In the process of step S51, the third device 30C presents information indicating the completion of registration of the non-friend key KN to the HMI 32. For example, the third device 30C displays an image indicating the completion of registration of the non-friend key KN on the HMI 32. This causes the management system 10 to end the series of processes for registering the non-friend key KN.

[0101] <Delete non-friend key KN> Next, a series of processes for deleting a non-friend key KN in the management system 10 will be described. Below, a series of flows from a state in which a non-friend key KN is registered to a state in which the non-friend key KN is not registered will be described. In the following explanation, the process executed by the execution unit 27 will be described as a process executed by the vehicle 20, the process executed by the execution unit 36 ​​will be described as a process executed by the device 30, and the process executed by the execution unit 71 will be described as a process executed by the management server 70.

[0102] <Deletion of non-friend key KN from friend device 51 by deletion reservation D41> As shown in FIG. 8, the management system 10 performs a series of processes to delete the non-friend key KN from the second device 30B, which is the friend device 51, based on the deletion reservation D41.

[0103] When an operation to request the deletion of the non-friend key KN is executed in the friend device 51, the friend device 51 first performs the process of step S61. In step S61, a deletion reservation D41 for the non-friend key KN is generated. The deletion reservation D41 is a signal that reserves the deletion of the non-friend key KN.

[0104] The deletion reservation D41 includes a signal requesting the deletion of the non-friend key KN, digital key identification information ST3 indicating the non-friend key KN, and information indicating a predetermined condition RC. The predetermined condition RC is a condition required to start the deletion after receiving the deletion reservation D41. The predetermined condition RC is determined in advance. For example, the predetermined condition RC is that a predetermined fade-out period has elapsed since the deletion reservation D41 was received. The deletion reservation D41 includes name information ATP5, which is information identifying the friend device 51 that transmits the deletion reservation D41 to the management server 70. The friend device 51 then transmits the deletion reservation D41 of the non-friend key KN to the management server 70.

[0105] Thereafter, when the management server 70 receives the deletion reservation D41 of the non-friend key KN, it performs the process of step S62. In step S62, the management server 70 generates a pending notification M41 indicating that the deletion reservation is pending in accordance with the deletion reservation D41. Then, the management server 70 transmits the pending notification M41 to the friend device 51.

[0106] Thereafter, when the friend device 51 receives the pending notification M41, the friend device 51 performs the process of step S63. In step S63, the friend device 51 displays, on the HMI 32, information indicating that the deletion of the non-friend key KN that is the target of the deletion reservation D41 is pending.

[0107] After the process of step S62, the management server 70 performs the process of step S64. In step S64, the management server 70 stores the state of the non-friend key KN that is the target of the deletion reservation D41 in the database DB as a fade-out state. The fade-out state is a state in which the deletion reservation D41 has been received but the execution of deletion is still pending. Thereafter, the management server 70 proceeds to the process of step S65.

[0108] In step S65, the management server 70 confirms that the predetermined condition RC is satisfied. If the management server 70 confirms that the predetermined condition RC is satisfied, the management server 70 advances the process to step S66.

[0109] In step S66, the management server 70 generates a deletion command D42 to delete the non-friend key information DKN indicating the non-friend key KN that is the target of the deletion reservation D41. Then, the management server 70 transmits the deletion command D42 to the third device 30C, which is the non-friend device 52.

[0110] Thereafter, when the non-friend device 52 receives the deletion command D42, it performs the processing of step S67. In step S67, 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 transmits a deletion completion notification M42 to the management server 70, indicating that the deletion in accordance with the deletion command D42 has been completed.

[0111] Thereafter, when the management server 70 receives the completion notification M42, the management server 70 performs the process of step S68. In step S68, the management server 70 stores the history of the deletion of the non-friend key information DKN in the non-friend device 52. Thereafter, the management server 70 proceeds to the process of step S69.

[0112] In step S69, the management server 70 generates a deletion command D43 for the authentication information AT. The deletion command D43 for the authentication information AT indicates a request to delete the authentication information AT for authenticating the non-friend key KN that is the target of the deletion reservation D41. The management server 70 then transmits the deletion command D43 to the vehicle 20.

[0113] Thereafter, when the vehicle 20 receives the deletion command D43, the vehicle 20 performs the processing of step S70. In step S70, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN that is the target of the deletion reservation D41 in accordance with the deletion command D43. That is, the vehicle 20 deletes the authentication package ATP of the non-friend key KN. The vehicle 20 then transmits a deletion completion notification M43 to the management server 70, indicating that the deletion of the authentication information AT in accordance with the deletion command D43 has been completed.

[0114] Thereafter, when the management server 70 receives the completion notification M43, the management server 70 performs the process of step S71. In step S71, the management server 70 stores the deletion history of the authentication information AT for authenticating the non-friend key KN to be deleted in the current series of deletion-related processes in the vehicle 20. Thereafter, the management server 70 proceeds to the process of step S72.

[0115] In step S72, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN to be deleted in this series of processes from the data DA of the vehicle 20 in the database DB. Thereafter, the management server 70 transmits to the friend device 51 a deletion completion notification M44 indicating that the series of deletions of the non-friend key KN in accordance with the deletion reservation D41 has been completed.

[0116] Thereafter, when the friend device 51 receives the completion notification M44, the friend device 51 performs the process of step S73. In step S73, the friend device 51 presents, to the HMI 32, information indicating that the deletion of the non-friend key KN that is the target of the deletion reservation D41 has been completed. For example, the friend device 51 displays, on the HMI 32, an image indicating that the deletion of the non-friend key KN has been completed. Thereafter, the management system 10 ends the series of processes for the deletion of this non-friend key KN.

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

[0118] When a predetermined operation requesting deletion of the non-friend key KN is executed in the third device 30C, which is the non-friend device 52, the non-friend device 52 first performs the processing of step S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN in accordance with the predetermined operation. Thereafter, the non-friend device 52 transmits a deletion completion notification M51 to the management server 70 indicating that the non-friend key information DKN has been deleted.

[0119] Thereafter, when the management server 70 receives the completion notification M51, the management server 70 performs the process of step S82. In step S82, the management server 70 stores the history of the deletion of the non-friend key information DKN in the non-friend device 52. Thereafter, the management server 70 transmits a deletion completion notification M52 to the second device 30B, which is the friend device 51, indicating that the non-friend key information DKN has been deleted.

[0120] Thereafter, when the friend device 51 receives the completion notification M52, the friend device 51 performs the process of step S83. In step S83, the friend device 51 presents, to the HMI 32, information indicating that the deletion of the non-friend key information DKN of the non-friend device 52 has been completed. For example, the friend device 51 displays, on the HMI 32, an image indicating that the deletion of the non-friend key KN has been completed.

[0121] After processing in step S82, the management server 70 performs processing in step S84. In step S84, the management server 70 generates a deletion command D51 to delete the authentication information AT for authenticating the non-friend key information DKN that was deleted in step S81. Then, the management server 70 transmits the deletion command D51 to the vehicle 20.

[0122] Thereafter, when vehicle 20 receives deletion command D51, vehicle 20 performs the processing of step S85. In step S85, vehicle 20 deletes authentication information AT for authenticating non-friend key information DKN that was deleted in step S81 in accordance with deletion command D51. Then, vehicle 20 transmits completion notification M53 to management server 70 indicating that deletion of authentication information AT in accordance with deletion command D51 has been completed.

[0123] Thereafter, when the management server 70 receives the completion notification M53, the management server 70 performs the process of step S86. In step S86, the management server 70 stores the history of the deletion of the authentication information AT for authenticating the non-friend key information DKN that was completely deleted in step S81. Thereafter, the management server 70 proceeds to the process of step S87.

[0124] In step S87, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN to be deleted in this series of processes from the data DA of the vehicle 20 in the database DB. This causes the management system 10 to end the series of processes for deleting the non-friend key KN.

[0125] <Regarding the deletion of multiple shared keys KS based on deletion request D61> 10, the management system 10 performs a series of processes to perform a deletion process DEL of the shared keys KS based on a deletion request D61 from the first device 30A, which is the owner device 40. In the series of processes shown in Fig. 10, the management system 10 deletes multiple shared keys KS based on the deletion request D61.

[0126] When an operation to identify a registered shared key KS and request its deletion is executed in the owner device 40, the owner device 40 first performs the processing of step S121. In step S121, a deletion request D61 that identifies the registered shared key KS is generated. The deletion request D61 includes a signal requesting the deletion of the registered shared key KS and digital key identification information ST3 that indicates the registered shared key KS. The deletion request D61 includes name information ATP5 that is information that identifies the owner device 40 that sends the deletion request D61 to the management server 70. The owner device 40 then sends the deletion request D61 to the management server 70. In the series of processes shown in FIG. 10 , the deletion request D61 is a signal requesting the deletion of the second digital key K2.

[0127] Thereafter, when the management server 70 receives the deletion request D61 from the owner device 40, it performs the process of step S122. In step S122, the management server 70 selects multiple share devices 50 to which a deletion command D62 is to be sent. The deletion command D62 is a command to cause the share device 50 to which the deletion command D62 is sent to delete the share key KS registered in that share device 50. Sending the deletion command D62 is one of the deletion processes DEL.

[0128] The management server 70 selects the target share device 50T in which the share key KS specified in the deletion request D61 is registered as the share device 50 to which the deletion command D62 is to be sent.

[0129] The shared key KS identified in the deletion request D61 is the second digital key K2. The second digital key K2 is registered in the second device 30B. Therefore, as shown in FIG. 11 , the second device 30B is the target shared device 50T. The management server 70 selects the second device 30B, which is the target shared device 50T, as the shared device 50 to which the deletion command D62 is to be sent. In addition, the management server 70 also selects, as the shared device 50 to which the deletion command D62 is to be sent, a shared device 50 in which a shared key KS of a generation subsequent to the second digital key K2, which is in a direct lineage to the second digital key K2 registered in the second device 30B, is registered. The management server 70 selects a shared device 50 in which a shared key KS of a generation subsequent to the second digital key K2, which is in a direct lineage to the second digital key K2, is registered, by referring to the data DA of the vehicle 20 stored in the database DB of the management server 70.

[0130] When the management server 70 receives a deletion request D61 from a device 30 other than the owner device 40 or from the vehicle 20, the management server 70 selects only the target shared device 50T as the shared device 50 to which the deletion command D62 is to be sent. The following describes the shared keys KS of generations subsequent to the second digital key K2 that are in a direct lineage with the second digital key K2.

[0131] <Data DA of vehicle 20 stored in database DB of management server 70> 11 shows data DA for one vehicle 20 stored in database DB of management server 70. A state in which digital keys are registered to eleven devices 30 for one vehicle 20 will be described. The eleven devices 30 are a first device 30A, a second device 30B, a third device 30C, a fourth device 30D, a fifth device 30E, a sixth device 30F, a seventh device 30G, an eighth device 30H, a ninth device 30I, a tenth device 30J, and an eleventh device 30K.

[0132] The digital key registered in the first device 30A is referred to as the first digital key K1. The storage device 37 of the first device 30A stores first key information DK1. The digital key registered in the second device 30B is referred to as the second digital key K2. The storage device 37 of the second device 30B stores second key information DK2. The digital key registered in the third device 30C is referred to as the third digital key K3. The storage device 37 of the third device 30C stores the third key information DK3. The digital key registered in the fourth device 30D is referred to as the fourth digital key K4. The storage device 37 of the fourth device 30D stores the fourth key information DK4. The digital key registered in the fifth device 30E is referred to as the fifth digital key K5. The storage device 37 of the fifth device 30E stores the fifth key information DK5. The digital key registered in the sixth device 30F is referred to as the sixth digital key K6. The storage device 37 of the sixth device 30F stores sixth key information DK6. The digital key registered in the seventh device 30G is referred to as seventh digital key K7. The storage device 37 of the seventh device 30G stores seventh key information DK7. The digital key registered in the eighth device 30H is referred to as eighth digital key K8. The storage device 37 of the eighth device 30H stores eighth key information DK8. The digital key registered in the ninth device 30I is referred to as ninth digital key K9. The storage device 37 of the ninth device 30I stores ninth key information DK9. The digital key registered in the tenth device 30J is referred to as tenth digital key K10. The storage device 37 of the tenth device 30J stores tenth key information DK10. The digital key registered in the eleventh device 30K is referred to as eleventh digital key K11. The storage device 37 of the eleventh device 30K stores eleventh key information DK11.

[0133] <Type of digital key> In the data DA, the device 30 whose digital key type is registered as the owner key KO is the first device 30A. That is, the first device 30A is the owner device 40. That is, the first digital key K1 is the owner key KO.

[0134] In the data DA, the devices 30 whose digital key type is registered as a shared 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. That is, 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 shared devices 50.

[0135] The second digital key K2, the third digital key K3, the fourth digital key K4, the fifth digital key K5, the sixth digital key K6, the seventh digital key K7, the eighth digital key K8, the ninth digital key K9, the tenth digital key K10, and the eleventh digital key K11 are all shared keys KS.

[0136] The second key information DK2, the third key information DK3, the fourth key information DK4, the fifth key information DK5, the sixth key information DK6, the seventh key information DK7, the eighth key information DK8, the ninth key information DK9, the tenth key information DK10, and the eleventh key information DK11 are all shared key information DKS. More specifically, in the data DA, the devices 30 whose digital key type is registered as the friend key KF are the second device 30B and the fifth device 30E. In other words, the second device 30B and the fifth device 30E are friend devices 51. In the data DA, the devices 30 whose digital key type is registered as non-friend 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-friend devices 52.

[0137] <About the relationship between the 30 devices> 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 K2 is registered based on the first digital key K1. In this case, the second digital key K2 is a digital key one generation later that is in a direct lineage with the first digital key K1.

[0138] 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 K5 is registered based on the first digital key K1. In this case, the fifth digital key K5 is a digital key one generation later that is in a direct lineage with the first digital key K1.

[0139] In the data DA, the relationship between the third device 30C and the second device 30B is such that the non-friend key KN is registered in the third device 30C based on a registration request from the second device 30B. That is, the third digital key K3 is registered based on the second digital key K2. In this case, the third digital key K3 is a digital key one generation later that is in a direct lineage with the second digital key K2. The third digital key K3 is a digital key two generations later that is in a direct lineage with the first digital key K1.

[0140] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that the non-friend key KN is registered in the fourth device 30D based on a registration request from the second device 30B. That is, the fourth digital key K4 is registered based on the second digital key K2. In this case, the fourth digital key K4 is a digital key one generation later that is in a direct lineage with the second digital key K2. The fourth digital key K4 is a digital key two generations later that is in a direct lineage with the first digital key K1.

[0141] In the data DA, the relationship between the sixth device 30F and the fifth device 30E is such that the non-friend key KN is registered in the sixth device 30F based on a registration request from the fifth device 30E. In other words, the sixth digital key K6 is registered based on the fifth digital key K5. In this case, the sixth digital key K6 is a digital key one generation later that is in a direct lineage with the fifth digital key K5. The sixth digital key K6 is a digital key two generations later that is in a direct lineage with the first digital key K1.

[0142] In the data DA, the relationship between the seventh device 30G and the fifth device 30E is such that the non-friend key KN is registered in the seventh device 30G based on a registration request from the fifth device 30E. In other words, the seventh digital key K7 is registered based on the fifth digital key K5. In this case, the seventh digital key K7 is a digital key one generation later that is in a direct lineage with the fifth digital key K5. The seventh digital key K7 is a digital key two generations later that is in a direct lineage with the first digital key K1.

[0143] In the data DA, the relationship between the eighth device 30H and the third device 30C is such that the non-friend key KN is registered in the eighth device 30H based on a registration request from the third device 30C. In other words, the eighth digital key K8 is registered based on the third digital key K3. In this case, the eighth digital key K8 is a digital key one generation later that is in a direct lineage with the third digital key K3. The eighth digital key K8 is a digital key two generations later that is in a direct lineage with the second digital key K2. The eighth digital key K8 is a digital key three generations later that is in a direct lineage with the first digital key K1.

[0144] In the data DA, the relationship between the ninth device 30I and the fourth device 30D is such that the non-friend key KN is registered in the ninth device 30I based on a registration request from the fourth device 30D. In other words, the ninth digital key K9 is registered based on the fourth digital key K4. In this case, the ninth digital key K9 is a digital key one generation later that is in a direct lineage with the fourth digital key K4. The ninth digital key K9 is a digital key two generations later that is in a direct lineage with the second digital key K2. The ninth digital key K9 is a digital key three generations later that is in a direct lineage with the first digital key K1.

[0145] In the data DA, the relationship between the tenth device 30J and the sixth device 30F is such that the non-friend key KN is registered in the tenth device 30J based on a registration request from the sixth device 30F. In other words, the tenth digital key K10 is registered based on the sixth digital key K6. In this case, the tenth digital key K10 is a digital key one generation later that is in a direct lineage with the sixth digital key K6. The tenth digital key K10 is a digital key two generations later that is in a direct lineage with the fifth digital key K5. The tenth digital key K10 is a digital key three generations later that is in a direct lineage with the first digital key K1.

[0146] In the data DA, the relationship between the eleventh device 30K and the seventh device 30G is such that the non-friend key KN is registered in the eleventh device 30K based on a registration request from the seventh device 30G. In other words, the eleventh digital key K11 is registered based on the seventh digital key K7. In this case, the eleventh digital key K11 is a digital key one generation later that is in a direct lineage with the seventh digital key K7. The eleventh digital key K11 is a digital key two generations later that is in a direct lineage with the fifth digital key K5. The eleventh digital key K11 is a digital key three generations later that is in a direct lineage with the first digital key K1.

[0147] <Regarding direct-line related digital keys> All digital keys one generation or more later than the digital key registered based on the request from the first digital key K1 are digital keys that are in a direct lineage with the first digital key K1. In other words, in the relationship diagram shown in Fig. 11, all digital keys other than the first digital key K1 are digital keys one generation or more later that are in a direct lineage with the first digital key K1.

[0148] All digital keys one generation or more later than the digital key registered based on the request from the second digital key K2 are digital keys that are in a direct lineage to the second digital key K2. In other words, in the relationship diagram shown in Fig. 11, the third digital key K3, the fourth digital key K4, the eighth digital key K8, and the ninth digital key K9 are digital keys one generation or more later that are in a direct lineage to the second digital key K2.

[0149] The management server 70 selects, as the destination of the deletion command D62, the share devices 50 in which the shared keys KS of the generation after the second digital key K2 that are in a direct lineage to the second digital key K2 are registered. That is, the management server 70 selects, as the destination of the deletion command D62, the second device 30B, the third device 30C, the fourth device 30D, the eighth device 30H, and the ninth device 30I. The shared keys KS registered in the share devices 50 that are the destination of the deletion command D62 are the shared keys KS that are the target of the deletion process DEL.

[0150] <Shared key KS set as the protection target> The management system 10 is configured to be able to set each share key KS as a protection target. The management server 70 does not send a deletion command D62 to a share device 50 in which a share key KS set as a protection target is registered. In other words, the management server 70 does not execute the deletion process DEL for a share key KS set as a protection target.

[0151] For example, a user of the vehicle 20 can set each of the share keys KS as a protection target via the HMI 22 of the vehicle 20. For example, a user of the owner device 40 can set each of the share keys KS as a protection target via the HMI 32 of the owner device 40. For example, a user of the share device 50 can set each of the share keys KS as a protection target via the HMI 32 of the share device 50.

[0152] After selecting multiple shared devices 50 to which the deletion command D62 is to be sent, the management server 70 performs the process shown in Figure 12 to determine whether the shared key KS to be protected is registered in each of the shared devices 50 selected as the destination of the deletion command D62.

[0153] In step S210 shown in FIG. 12, the management server 70 determines whether or not a share key KS to be protected is registered in the share device 50 selected as the destination of the deletion command D62.

[0154] If a share key KS that is set as a protection target is registered in the share device 50 selected as the destination of the deletion command D62 (step S210: YES), the management server 70 proceeds to step S211. In step S211, the management server 70 excludes the share device 50 in which the share key KS that is set as a protection target is registered from the destinations of the deletion command D62. Thereafter, the management server 70 ends the series of processes shown in FIG.

[0155] If the share key KS set as a protection target is not registered in the share device 50 selected as the destination of the deletion command D62 (step S210: NO), the management server 70 proceeds to step S212. In step S212, the management server 70 leaves the share device 50 selected as the destination of the deletion command D62. Thereafter, the management server 70 ends the series of processes shown in FIG.

[0156] After performing the process shown in FIG. 12 once for each of all the shared devices 50 selected as the destinations of the deletion command D62, the management server 70 proceeds to step S123 shown in FIG.

[0157] <Generating and sending confirmation request D63> In step S123, the management server 70 generates a confirmation request D63. The confirmation request D63 is a request for the share key KS to be protected. The confirmation request D63 includes a list 81 of multiple share keys KS to be subject to the deletion process DEL. Specifically, it includes the list 81 of multiple share keys KS registered in the share device 50 to which the deletion command D62 shown in FIG. 13 is to be sent. The confirmation request D63 includes a request for the share key KS to be protected, among the share keys KS listed in the list 81. The confirmation request D63 also includes digital key identification information ST3 corresponding to each share key KS listed in the list 81. The management server 70 transmits the confirmation request D63 to the owner device 40, which is the sender of the deletion request D61.

[0158] Thereafter, when the owner device 40 receives the confirmation request D63, the owner device 40 performs the process of step S124 shown in Fig. 10. In step S124, the owner device 40 displays on the HMI 32 a list 81 and an image that prompts the user to select the share keys KS to be protected from among the share keys KS listed in the list 81, as shown in Fig. 13.

[0159] FIG. 13 shows an example of a list 81 displayed on the HMI 32 of the owner device 40, and an image prompting the user to select the share keys KS to be protected from among the share keys KS listed in the list 81.

[0160] The user of the owner device 40 selects the share keys KS to be protected by following the instructions presented on the HMI 32. Specifically, the user checks the check box CB next to the share keys KS that they want to protect from among the share keys KS listed in the list 81 displayed on the HMI 32. If the user wants to protect the second digital key K2, the user checks the first check box 82. If the user wants to protect the third digital key K3, the user checks the second check box 83. If the user wants to protect the fourth digital key K4, the user checks the third check box 84. If the user wants to protect the eighth digital key K8, the user checks the fourth check box 85. If the user wants to protect the ninth digital key K9, the user checks the fifth check box 86.

[0161] When the user presses "OK", the share key KS whose corresponding check box CB is checked is selected as the share key KS to be protected. The owner device 40 then proceeds to step S125 shown in Fig. 10. Below, a case will be described in which the user of the owner device 40 checks the third check box 84, thereby selecting the fourth digital key K4 as the share key to be protected.

[0162] In step S125, the owner device 40 generates an answer notification M61. The answer notification M61 includes digital key identification information ST3 indicating the shared key KS selected as the target for protection and answered by the user of the owner device 40 in step S124. Specifically, the answer notification M61 includes digital key identification information ST3 indicating the fourth digital key K4. The owner device 40 then transmits the answer notification M61 to the management server 70.

[0163] Thereafter, when the management server 70 receives the answer notification M61, the management server 70 performs the process of step S126. In step S126, the management server 70 sets the fourth digital key K4 as a digital key to be protected based on the digital key identification information ST3 included in the answer notification M61. The management server 70 excludes the fourth device 30D, in which the fourth digital key K4 set as a digital key to be protected, from the destinations of the deletion command D62. Thereafter, the management server 70 determines, as the destinations of the deletion command D62, the share devices 50 other than the fourth device 30D, among the share devices 50 selected as the destinations of the deletion command D62 in step S122. Specifically, the management server 70 determines the second device 30B, the third device 30C, the eighth device 30H, and the ninth device 30I as the destinations of the deletion command D62. Thereafter, the management server 70 proceeds to the process of step S127.

[0164] <Generation of deletion command D62> In step S127, the management server 70 generates a deletion command D62 to be transmitted to the second device 30B, the third device 30C, the eighth device 30H, and the ninth device 301. Thereafter, the management server 70 proceeds to step S128.

[0165] <Generation of deletion command D64> In step S128, the management server 70 generates a deletion command D64 for deleting the authentication information AT indicating the shared key KS specified in the deletion request D61 and the multiple pieces of authentication information AT indicating the shared keys KS of subsequent generations that are in a direct lineage to the shared key. Specifically, the deletion command D64 includes information for deleting the authentication information AT indicating the second digital key K2 specified in the deletion request D61, and the authentication information AT indicating the third digital key K3, the eighth digital key K8, and the ninth digital key K9, which are pieces of authentication information AT indicating the shared keys KS of subsequent generations that are in a direct lineage to the second digital key K2. The deletion command D64 does not include information for deleting the authentication information AT indicating a digital key that is set as a digital key to be protected. In other words, the deletion command D64 does not include information for deleting the authentication information AT indicating the fourth digital key K4. After generating the deletion command D64, the management server 70 proceeds to step S129.

[0166] The authentication information AT is information indicating a digital key. Therefore, the deletion command D64 is a command to delete the shared keys KS of the generation after the shared key KS that is in a direct lineage relationship with the shared key KS registered in the target shared device 50T.

[0167] <Sending deletion command D62> In step S129, as shown in FIG. 14, the management server 70 transmits a deletion command D62 as a deletion process DEL to the second device 30B, the third device 30C, the eighth device 30H, and the ninth device 30I.

[0168] Thereafter, when the share device 50 receives the deletion command D62, the share device 50 deletes the registered share key KS in accordance with the deletion command D62. Specifically, upon receiving the deletion command D62, the second device 30B deletes the second key information DK2 stored in the storage device 37 of the second device 30B. Upon receiving the deletion command D62, the third device 30C deletes the third key information DK3 stored in the storage device 37 of the third device 30C. Upon receiving the deletion command D62, the eighth device 30H deletes the eighth key information DK8 stored in the storage device 37 of the eighth device 30H. Upon receiving the deletion command D62, the ninth device 30I deletes the ninth key information DK9 stored in the storage device 37 of the ninth device 30I. Thereafter, each share device 50 transmits a deletion completion notification indicating that the deletion of the key information DK has been completed to the management server 70.

[0169] Thereafter, when the management server 70 receives notification of the completion of the deletion, the management server 70 stores a history of the deletion of the key information DK in each shared device 50. Thereafter, the management server 70 advances the process to step S130 shown in FIG.

[0170] <Sending deletion command D64> In step S130, as shown in FIG. 14, the management server 70 transmits a deletion command D64 to the vehicle 20 as a deletion process DEL. Upon receiving the deletion command D64, the vehicle 20 deletes the plurality of pieces of authentication information AT in accordance with the deletion command D64. Thereafter, the vehicle 20 transmits a deletion completion notification to the management server 70, indicating that the deletion of the plurality of pieces of authentication information AT has been completed. Thereafter, when the management server 70 receives the deletion completion notification, the management server 70 stores a history of the deletion of the plurality of pieces of authentication information AT in the vehicle 20. Thereafter, the management server 70 proceeds to step S131 shown in FIG.

[0171] <Database update> 14, the management server 70 updates the database DB as a deletion process DEL. That is, the management server 70 deletes from the data DA of the vehicle 20 information indicating the shared device 50 in which the shared key KS specified in the deletion request D61 is registered and information indicating the shared devices 50 in which shared keys KS of generations subsequent to the specified shared key are registered that are in a direct lineage to the specified shared key. Specifically, the management server 70 deletes from the data DA of the vehicle 20 information indicating the second device 30B in which the second digital key K2 specified in the deletion request D61 is registered, information indicating the third device 30C in which the third digital key K3 is registered, information indicating the eighth device 30H in which the eighth digital key K8 is registered, and information indicating the ninth device 30I in which the ninth digital key K9 is registered, which are multiple shared devices 50 in which shared keys KS of generations subsequent to the second digital key K2 that are in a direct lineage to the second digital key K2 are registered. The management server 70 does not delete information indicating the shared device 50 in which the digital key to be protected is registered from the data DA of the vehicle 20. In other words, the management server 70 does not delete information indicating the fourth device 30D in which the fourth digital key K4 is registered from the data DA of the vehicle 20. Thereafter, the management system 10 ends the series of processes for deleting the multiple shared keys KS based on the deletion request D61.

[0172] <Operation of this embodiment> It is highly likely that the user who sent the deletion request D61 wants to delete not only the share key KS registered in the target share device 50T, but also the share key KS registered based on a request from the target share device 50T. When the management server 70 receives the deletion request D61, it sends a deletion command D62 as a deletion process DEL to the second device 30B, which is the target share device 50T. Furthermore, the management server 70 also sends the deletion command D62 as a deletion process DEL to the third device 30C, eighth device 30H, and ninth device 30I, which are other share devices 50 in which the share key KS is registered based on the request from the target share device 50T.

[0173] Furthermore, as the deletion process DEL, the management server 70 transmits a deletion command D64 to the vehicle 20. Furthermore, as the deletion process DEL, the management server 70 updates the data DA of the vehicle 20 in the database DB.

[0174] <Effects of this embodiment> (1) The management server 70 allows a user to delete multiple digital keys at once without having to individually select the digital keys they want to delete. This reduces the burden on the user in deleting multiple digital keys.

[0175] (2) The management server 70 transmits the deletion command D62 to the share devices 50 in which share keys KS of a generation subsequent to the share key KS registered in the target share device 50T are registered, and which are in a direct lineage to the share key KS registered in the target share device 50T. The user who transmitted the deletion request D61 is likely to also wish to delete the share keys KS from the share devices 50 in which share keys KS of a generation subsequent to the share key KS registered in the target share device 50T are registered. The management server 70 transmits the deletion command D62 to the share devices 50 in which share keys KS of a generation subsequent to the second digital key K2, which are in a direct lineage to the second digital key K2 registered in the second device 30B, which is the target share device 50T, are registered. This further reduces the burden on a user who wishes to delete multiple share keys KS.

[0176] (3) The management server 70 is configured to be able to set a share key KS to be protected. The management server 70 does not send a deletion command D62 to a share device 50 in which a share key KS set as a share key to be protected is registered. In other words, the management server 70 does not execute a deletion process DEL on a share key KS set as a share key to be protected. A user who sent a deletion request D61 may not want to delete a share key KS registered in another share device 50 based on a request from the target share device 50T. By making it possible to set a share key KS to be protected, the management server 70 can protect the share key KS from the deletion command D62.

[0177] (4) When the management server 70 receives the deletion request D61, it transmits a list 81 of the shared keys KS registered in the multiple shared devices 50 that are the destinations of the deletion command D62 shown in Fig. 13 to the owner device 40 that is the sender of the deletion request D61. The list 81 is a list of the multiple shared keys KS that are the targets of the deletion process DEL. This allows the management server 70 to let the user who sent the deletion request D61 know the shared keys KS to be deleted.

[0178] (5) When the management server 70 receives the deletion request D61, it makes the user who sent the deletion request D61 respond with the share keys KS to be protected from among the share keys KS listed in the list 81 shown in Fig. 13. This allows the management server 70 to determine the share device 50 to which the deletion command D62 is to be sent, reflecting the intention of the user who responded with the share keys KS that they want to protect from the deletion command D62.

[0179] (6) Only when the management server 70 receives a deletion request D61 from the owner device 40, does it transmit a deletion command D62, which is a deletion process DEL, to the second device 30B, which is the target shared device 50T, and to another shared device 50 to which the shared key KS is registered based on the request from the second device 30B. If multiple shared keys KS are deleted without limit by a user other than the user of the owner device 40, this may cause problems in the operation of the vehicle 20 using the digital key. Only when the management server 70 receives a deletion request D61 from the owner device 40, does it transmit the deletion command D62 to multiple shared devices 50. The management server 70 can prevent users other than the user of the owner device 40 from misusing the function of deleting multiple shared keys KS based on a single deletion request D61.

[0180] (7) The management system 10 includes a vehicle 20, multiple digital keys usable for the vehicle 20, including an owner key KO registered for an owner device 40 (a device 40BO belonging to the owner of the vehicle 20) and a shared key KS registered for a shared device 50 (a device 30 separate from the owner device 40), and a management server 70 that manages the multiple digital keys. When the management server 70 receives a deletion request D61 identifying a registered shared key KS, the management server 70 executes a deletion process DEL to delete the shared key KS registered in the target shared device 50T to which the shared key KS identified in the received deletion request D61 is registered and in another shared device 50 to which the shared key KS is registered based on the request from the target shared device 50T. The management system 10 can delete multiple digital keys at once without the user having to individually select each digital key to be deleted. This reduces the burden on the user when deleting multiple digital keys.

[0181] (8) The management server 70 manages multiple digital keys that are usable for the vehicle 20 and include an owner key KO registered for an owner device 40, which is a device 30 belonging to the owner of the vehicle 20, and a shared key KS registered for a shared device 50, which is a device 30 different from the owner device 40. The management server 70 includes an execution device 71, which is a processing circuit. The digital key deletion method executed by the management server 70 includes, when a deletion request D61 specifying a registered shared key KS is received, a step (step S127) in which the execution device 71 of the management server 70 generates a deletion command D62 that is a command to delete the registered shared key KS. The digital key deletion method executed by the management server 70 includes a step (step S128) in which a deletion command D64 is a command to delete a shared key KS of a generation subsequent to the shared key KS that is in a direct lineage to the shared key KS specified in the received deletion request D61. The digital key deletion method executed by the management server 70 includes steps (steps S129, S130, and S131) ​​in which the execution device 71 of the management server 70 executes a deletion process DEL to delete the shared key KS registered in the second device 30B, which is the target shared device 50T to which the shared key KS specified in the received deletion request D61 is registered, and in another shared device 50 to which the shared key KS is registered based on the request from the second device 30B. By executing this digital key deletion method, the management server 70 can delete multiple digital keys at once without the user having to individually select each digital key to be deleted. This reduces the burden on the user when deleting multiple digital keys.

[0182] (9) The storage device 72 of the management server 70 stores a deletion program PM that causes the execution device 71 of the management server 70 to execute processing. When the management server 70 receives a deletion request D61 that identifies a registered share key KS, the deletion program PM causes the execution device 71 of the management server 70 to execute processing to generate a deletion command D62 that is a command to delete the registered share key KS. The deletion program PM causes the execution device 71 of the management server 70 to execute processing to generate a deletion command D64 that is a command to delete a share key KS of a generation subsequent to the share key KS that is in a direct lineage relationship with the share key KS identified in the received deletion request D61. The deletion program PM causes the execution device 71 of the management server 70 to execute a deletion process DEL that deletes the share keys KS registered in the second device 30B, which is the target share device 50T in which the share key KS identified in the received deletion request D61 is registered, and in another share device 50 in which the share key KS is registered based on a request from the second device 30B. This allows the management server 70 to delete multiple digital keys at once without the user having to individually select the digital keys they want to delete, thereby reducing the burden on the user in deleting multiple digital keys.

[0183] <Example of change> This embodiment can be modified as follows: This embodiment and the following modifications can be combined and implemented within the scope of technical compatibility.

[0184] <About the deletion process DEL> In step S129, the management server 70 performs a process of transmitting a deletion command D62 to the multiple shared devices 50 as the deletion process DEL. In step S130, the management server 70 performs a process of transmitting a deletion command D64 to the vehicle 20 as the deletion process DEL. In step S131, the management server 70 performs a process of updating the database DB stored in the management server 70 as the deletion process DEL. The management server 70 may be configured to perform one or more of these three processes as the deletion process DEL. For example, the management server 70 may only perform a process of transmitting the deletion command D62 to the multiple shared devices 50 as the deletion process DEL. The management server 70 may only perform a process of transmitting the deletion command D64 to the vehicle 20 as the deletion process DEL. The management server 70 may only perform a process of updating the database DB stored in the management server 70 as the deletion process DEL.

[0185] By having the management server 70 perform any one of steps S129, S130, and S131, multiple digital keys can be deleted at once without the user having to individually select the digital keys they want to delete, thereby reducing the burden on the user in deleting multiple digital keys.

[0186] If the management server 70 does not perform the process of step S129, the management server 70 does not need to perform the process of step S126 and the process of step S127. If the management server 70 does not perform the process of step S130, the management server 70 does not need to perform the process of step S128.

[0187] If the management server 70 does not perform the processing of step S129, the management server 70 may select a share key KS of a generation subsequent to the share key KS that has a direct relationship with the share key KS registered in the target share device 50T, as processing equivalent to step S122. In other words, the management server 70 does not need to select a share device 50 in which a share key KS of a generation subsequent to the share key KS that has a direct relationship with the share key KS registered in the target share device 50T has been registered, as processing equivalent to step S122.

[0188] The list 81 is not limited to a list of multiple share keys KS registered in the share device 50 to which the deletion command D62 is sent. The list 81 may contain multiple share keys KS that are the target of the deletion process DEL. For example, the list 81 may contain share keys KS of generations subsequent to the share key KS that is in a direct lineage relationship with the share key KS registered in the target share device 50T.

[0189] <About the sender of deletion request D61> The sender of the deletion request D61 is not limited to the owner device 40. For example, the sender of the deletion request D61 may be the vehicle 20. For example, the sender of the deletion request D61 may be the shared device 50.

[0190] When the management server 70 receives a deletion request D61 from a share device 50, if the share key KS specified in the received deletion request D61 is in a direct lineage with the share key KS registered in the share device 50 that is the sender of the deletion request D61 and is a share key KS of a generation later than the share key KS registered in the share device 50 that is the sender of the deletion request D61, the management server 70 may be configured to execute a deletion process DEL to delete the share key KS registered in the target share device 50T in which the share key KS specified in the received deletion request D61 is registered and in another share device 50 in which the share key KS is registered based on a request from the target share device 50T.

[0191] As shown in FIG. 11 , the third digital key K3 registered in the third device 30C and the eighth digital key K8 registered in the eighth device 30H are shared keys KS that are directly related to the second digital key K2 registered in the second device 30B. The third digital key K3 and the eighth digital key K8 are digital keys of generations subsequent to the second digital key K2. When the management server 70 receives a deletion request D61 from the second device 30B and the shared key KS identified in the deletion request D61 is the third digital key K3, the management server 70 selects the third device 30C and the eighth device 30H as the shared devices 50 to which a deletion command D62, which is a deletion process DEL, is to be transmitted in a process equivalent to step S122 shown in FIG. 10 . Thereafter, the management server 70 transmits the deletion command D62, which is a deletion process DEL, to the third device 30C and the eighth device 30H in a process equivalent to step S129. The management server 70 generates a deletion command D64 including information for deleting the authentication information AT indicating the third digital key K3 and the authentication information AT indicating the eighth digital key K8, in a process equivalent to step S128. The management server 70 transmits the deletion command D64 to the vehicle 20, in a process equivalent to step S130. The management server 70 deletes, from the data DA of the vehicle 20, information indicating the third device 30C in which the third digital key K3 is registered and information indicating the eighth device 30H in which the eighth digital key K8 is registered, in a process equivalent to step S131.

[0192] As shown in FIG. 11 , the fifth device 30E is a shared device 50 that is not directly related to the second device 30B. When the management server 70 receives a deletion request D61 from the second device 30B and the fifth digital key K5 is identified in the deletion request D61, the management server 70 does not select the fifth device 30E as the shared device 50 to which the deletion command D62 is to be sent in processing corresponding to step S122 shown in FIG. 10 . Thereafter, the management server 70 does not generate a deletion command D62 in processing corresponding to step S127. The management server 70 does not generate a deletion command D64 in processing corresponding to step S128. The management server 70 does not transmit the deletion command D62 to the shared device 50 in processing corresponding to step S129. The management server 70 does not transmit the deletion command D64 to the vehicle 20 in processing corresponding to step S130. The management server 70 does not update the database DB in processing corresponding to step S131. That is, the management server 70 does not execute the deletion process DEL.

[0193] As shown in FIG. 11 , the sixth device 30F is a shared device 50 that is in a direct lineage relationship with the fifth device 30E. The fifth device 30E has a digital key of a generation higher than that of the sixth device 30F. When the management server 70 receives a deletion request D61 from the sixth device 30F and the fifth digital key K5 is identified in the deletion request D61, the management server 70 does not select the fifth device 30E as the shared device 50 to which the deletion command D62 is to be sent in a process corresponding to step S122 shown in FIG. 10 . Thereafter, the management server 70 does not generate a deletion command D62 in a process corresponding to step S127. The management server 70 does not generate a deletion command D64 in a process corresponding to step S128. The management server 70 does not transmit the deletion command D62 to the shared device 50 in a process corresponding to step S129. The management server 70 does not transmit the deletion command D64 to the vehicle 20 in a process corresponding to step S130. The management server 70 does not update the database DB in the process corresponding to step S131. That is, the management server 70 does not execute the deletion process DEL.

[0194] If a user of a shared device 50 deletes a shared key KS that is not directly related to the shared key KS registered in the shared device 50, this may cause problems with the use of the vehicle 20 using the digital key. Similarly, if a user of a shared device 50 deletes a shared key KS that is an older generation than the shared key KS registered in the shared device 50, this may cause problems with the use of the vehicle 20 using the digital key.

[0195] The management server 70 described above can reduce the possibility of the function of deleting multiple shared keys KS based on a single deletion request D61 being abused by the user of the shared device 50, causing problems with the use of the vehicle 20 using the digital key.

[0196] <When multiple digital keys are registered to one Share Device 50> In the management system 10, a situation may arise in which multiple digital keys are registered to one shared device 50. FIG. 15 shows data DA for one vehicle 20 stored in the database DB of the management server 70. As shown in FIG. 15, a first non-friend key KN1 and a second non-friend key KN2 are registered in the twelfth device 30L. The storage device 37 of the twelfth device 30L stores first non-friend key information DKN1 indicating the first non-friend key KN1. The storage device 37 of the twelfth device 30L stores second non-friend key information DKN2 indicating the second non-friend key KN2. The first device 30A, the second device 30B, the third device 30C, the fifth device 30E, and the sixth device 30F are the same as those shown in FIG. 11.

[0197] The relationship between the twelfth device 30L and the third device 30C is such that the first non-friend key KN1 is registered in the twelfth device 30L based on a registration request from the third device 30C. In other words, the first non-friend key KN1 is registered based on the third digital key K3. In this case, the first non-friend key KN1 is a digital key one generation later that is in a direct lineage with the third digital key K3. The first non-friend key KN1 is a digital key two generations later that is in a direct lineage with the second digital key K2. The first non-friend key KN1 is a digital key three generations later that is in a direct lineage with the first digital key K1.

[0198] The relationship between the twelfth device 30L and the sixth device 30F is such that the second non-friend key KN2 is registered in the twelfth device 30L based on a registration request from the sixth device 30F. In other words, the second non-friend key KN2 is registered based on the sixth digital key K6. In this case, the second non-friend key KN2 is a digital key one generation later that is in a direct lineage with the sixth digital key K6. The second non-friend key KN2 is a digital key one generation later that is in a direct lineage with the fifth digital key K5. The second non-friend key KN2 is a digital key three generations later that is in a direct lineage with the first digital key K1.

[0199] The following describes the case where the shared key KS specified in the deletion request D61 is the second digital key K2. In this case, in step S122 shown in FIG. 10 , the management server 70 selects the second device 30B in which the second digital key K2 is registered as the target shared device 50T to which the deletion command D62 is to be sent. In addition, the management server 70 also sets, as the shared device 50 to which the deletion command D62 is to be sent, a shared device 50 in which a shared key KS of a generation subsequent to the second digital key K2 that is in a direct lineage relationship with the second digital key K2 is registered. In other words, the management server 70 sets the second device 30B, the third device 30C, and the twelfth device 30L as the recipients of the deletion command D62.

[0200] The deletion command D62 in this modified example is a command to delete the share keys KS of the generation after the share key KS that is in a direct lineage relationship with the share key KS registered in the target share device 50T. In other words, the deletion process DEL in this modified example is a process to delete the share keys KS of the generation after the share key KS that is in a direct lineage relationship with the share key KS registered in the target share device 50T.

[0201] Specifically, the deletion command D62 in this modified example is a command to delete a shared key KS of a generation subsequent to the second digital key K2 that is in a direct lineage to the second digital key K2 registered in the second device 30B, which is the target shared device 50T. Therefore, upon receiving the deletion command D62, the twelfth device 30L deletes the first non-friend key KN1, which is a shared key KS of a generation subsequent to the second digital key K2 that is in a direct lineage to the second digital key K2. Specifically, the twelfth device 30L deletes the first non-friend key information DKN1 stored in the storage device 37 of the twelfth device 30L. The second non-friend key information DKN2 stored in the storage device 37 of the twelfth device 30L is not deleted by the deletion command D62.

[0202] When multiple share keys KS are registered in one share device 50, the management server 70 can delete the share keys KS that are in a direct relationship with the share key KS specified in the deletion request D61 and are of generations subsequent to the share key KS.

[0203] <Regarding confirmation request D63> When the management server 70 receives a deletion request D61, it may send only the list 81 shown in FIG. 13 to the sender of the deletion request D61 instead of the confirmation request D63. When the management server 70 receives a deletion request D61, it does not have to send the confirmation request D63 to the sender of the deletion request D61. When the management server 70 receives a deletion request D61, it does not have to generate the confirmation request D63.

[0204] <Regarding the shared key KS to be protected> · The management server does not have to be configured to be able to set the shared key KS to be protected.

[0205] <Regarding the check box CB displayed on the HMI32> · As shown in FIG. 13, a check box CB is displayed next to the shared key KS listed in the list 81 displayed on the HMI32 of the owner device 40 that has received the confirmation request D63. When an operation to identify and request deletion of the registered shared key KS is executed on the owner device 40, the owner device 40 generates a deletion request D61 that identifies the registered shared key KS. Therefore, the confirmation request D63 may be configured such that the check box CB is not displayed next to the shared key KS specified in the deletion request D61. For example, when the shared key KS specified in the deletion request D61 is the second digital key K2, the confirmation request D63 may be configured such that the first check box 82 is not displayed next to the "second digital key" in the list 81 shown in FIG. 13.

[0206] <Management system 10> · The vehicle 20 does not have to have a part of the BLE module 23, the UWB module 24, and the NFC module 25. If the vehicle 20 has at least one module, it can perform short-range communication with the device 30. Also, the vehicle 20 is not limited to these modules and may have a module that performs short-range communication with the device 30.

[0207] · Matters regarding the digital key in each of the above embodiments do not have to comply with CCC. <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). The vehicle management device 26 may also be configured as a circuit including one or more dedicated hardware circuits, such as an application-specific integrated circuit (ASIC), that execute at least some of the various processes, or a combination thereof. 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. The memory, i.e., computer-readable medium, includes any available medium that can be accessed by a general-purpose or dedicated computer. The same applies to the device 30 and the management server 70.

[0208] 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 the vehicle 20. The device 30 is not limited to a smartphone. It may be a smartwatch. The device 30 may also be a predetermined server. In this case, the predetermined server may include the device 30. For example, if a rental business or a sharing business is the owner of the vehicle 20, the owner device 40 may be included in the predetermined server. Also, for example, the friend device 51 may be included in the predetermined server.

[0209] The device server 60 does not have to be provided for each type of device 30. It is sufficient that multiple devices 30 and the management server 70 are capable of wireless communication. The device server 60 may be omitted. It is sufficient that multiple devices 30 and the management server 70 are capable of direct wireless communication.

[0210] The management server 70 may be configured with multiple servers. For example, it may be configured with a server that stores the database DB and a server that executes the server program PS. Alternatively, it may be configured with 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.

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

[0212] <Various information> The authentication information AT is not limited to the examples of the above embodiments, as long as it is information for authenticating the digital key when using the digital key. For example, the authentication information AT may be a common key shared by the vehicle management device 26 and the device 30. Also, for example, the authentication information AT may be a common secret key.

[0213] The configuration of the information included in the key information DK is not limited to the example in the above embodiment. For example, the owner key information DKO does not have to include the slot identification information ST4. Also, for example, the key information DK may include 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.

[0214] The database DB may include information indicating the type of the device 30. The type of the device 30 is information indicating, for example, a smartphone, a smartwatch, or a predetermined server as in the above-described modified example.

[0215] The structure of the data DA in the database DB is not limited to the examples in the above embodiments, as long as the database DB contains the information necessary for the management server 70 in the management system 10 to manage it.

[0216] <The process for registering a digital key> The series of processes for registering the owner key KO is not limited to the examples in the above embodiments. For example, the owner device 40 may store the owner key information DKO by transmitting and receiving information such as the generated data DC between the vehicle 20 and the first device 30A via the management server 70, even if pairing is not performed by the process of step S12. The series of processes for registering the owner key KO may be modified as appropriate to suit the structure of the information included in the owner key information DKO and the structure of the information included in the authentication information AT.

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

[0218] The series of processes for registering a non-friend key KN is not limited to the examples in the above embodiments. The order of the processes for registering a friend key KF may be different. The series of processes for registering a non-friend key KN may be modified as appropriate to suit 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.

[0219] The types of digital keys do not have to include non-friend keys KN. In other words, in the management system 10, the shared keys KS may only be friend keys KF. <The process for deleting a digital key> In this embodiment, when deleting the non-friend key KN, the friend device 51 transmits a deletion reservation D41 to the management server 70, but this does not have to be a reservation request. That is, the friend device 51 may transmit a request to delete the non-friend key KN to the management server 70 regardless of the predetermined condition RC. Furthermore, the management server 70 may proceed with the processing from step S62 onwards in response to a request to delete the non-friend key KN not only from the friend device 51 but also from the owner device 40.

[0220] The following describes a case where an operation to request deletion of a non-friend key KN is executed in the non-friend device 52. In this case, instead of the process in step S81 of FIG. 9, the non-friend device 52 may send a request to delete the non-friend key KN registered in the non-friend device 52 to the management server 70. Upon receiving the request, the management server 70 generates a request to delete the non-friend key information DKN, similar to step S66 shown in FIG. 8. The management server 70 then sends a request to delete the non-friend key information DKN to the non-friend device 52. Having received the request to delete the non-friend key information DKN, the non-friend device 52 deletes the non-friend key information DKN, similar to step S67 shown in FIG. 8. The non-friend device 52 then transmits a notification to the management server 70 indicating that the non-friend key information DKN has been deleted. After receiving the notification indicating that the non-friend device 52 has deleted the non-friend key information DKN, the management server 70 proceeds with the process from step S82 onwards shown in FIG. 9. The non-friend device 52 does not need to send a notification indicating that the non-friend key information DKN has been deleted to the management server 70. In this case, the management server 70 sends a request to the non-friend device 52 to delete the non-friend key information DKN, and then proceeds with the processing from step S82 onwards shown in Figure 9.

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

[0222] When a deletion reservation is requested for the target share device 50T, the management server 70 may send a deletion command to the share device 50 in which the share key KS is registered based on the request from the target share device 50T if a predetermined condition RC is satisfied. The predetermined condition RC may be set individually for each of the multiple share devices 50 in which the share key KS is registered based on the request from the target share device 50T.

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

[0224] The share device 50 has a function to receive the share key KS as in the above embodiment. A device 30 having a function to receive a digital key, such as the share device 50, is sometimes called a receiver device.

[0225] <Additional Notes> The technical ideas that can be understood from the above-described embodiment and modified examples will be described. [Appendix 1] A management server that manages multiple digital keys, including an owner key that is a digital key that can be used for a vehicle and is registered for an owner device that is a device belonging to the owner of the vehicle, and a share key that is registered for a share device that is a device other than the owner device, and when the management server receives a deletion request that identifies a registered share key, it executes a deletion process to delete the share key registered in a target share device in which the share key identified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device.

[0226] [Appendix 2] A management server that manages multiple digital keys, including an owner key that is a digital key that can be used for a vehicle and is registered for an owner device that is a device belonging to the owner of the vehicle, and a share key that is registered for a share device that is a device other than the owner device, and only when the management server receives a deletion request from the owner device that identifies the registered share key, performs a deletion process to delete the share key registered in the target share device in which the share key identified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device.

[0227] [Appendix 3] A management server that manages multiple digital keys that can be used for a vehicle, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a share key registered for a share device that is a device other than the owner device, wherein the management server receives a deletion request from the share device that identifies the registered share key, and if the share key identified in the received deletion request is in a direct lineage with the share key registered in the share device that sent the deletion request and is a share key of a generation later than the share key registered in the share device that sent the deletion request, executes a deletion process to delete the share key registered in the target share device in which the share key identified in the received deletion request is registered and in another share device in which the share key is registered based on a request from the target share device.

[0228] [Appendix 4] A management server that manages multiple digital keys, including an owner key that is a digital key that can be used for a vehicle and is registered for an owner device that is a device belonging to the owner of the vehicle, and a share key that is registered for a share device that is a device other than the owner device, and when it receives a deletion request that identifies a registered share key, it executes a deletion process to delete the share key of the generation after the share key that is in a direct lineage to the share key registered in the target share device, which is registered with the target share device in which the share key identified in the received deletion request is registered, and another share device in which the share key is registered based on a request from the target share device.

[0229] [Appendix 5] A management server described in any one of Appendices 1 to 4, which also performs the deletion process on the share key registered in the share device in which a share key of a generation subsequent to the share key registered in the target share device that is in a direct lineage relationship with the share key registered in the target share device is registered.

[0230] [Appendix 6] A management server described in any one of Appendices 1 to 5, configured to be able to set the share key to be protected, and not to perform the deletion process on the share key that is set as the target of protection.

[0231] [Appendix 7] A management server according to any one of Appendices 1 to 6, which, when receiving the deletion request, sends a list of the multiple shared keys that are subject to the deletion process to the sender of the deletion request.

[0232] [Appendix 8] The management server described in Appendix 6, when receiving the deletion request, sends a list of multiple share keys that are subject to the deletion process to the sender of the deletion request, and has the sender respond with the share key that is to be protected from among the share keys listed in the list.

[0233] [Appendix 9] A method for deleting a digital key executed by a management server that manages multiple digital keys, including an owner key that is usable for a vehicle and is registered for an owner device that is a device belonging to the owner of the vehicle, and a share key that is registered for a share device that is a device other than the owner device, the method including: a step in which a processing circuit of the management server generates a deletion command that is a command to delete the registered share key only when a deletion request that identifies the registered share key is received from the owner device; and a step in which a deletion process is executed to delete the share key registered in a target share device in which the share key identified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device.

[0234] [Appendix 10] A method for deleting a digital key executed by a management server that manages multiple digital keys that can be used for a vehicle, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a share key registered for a share device that is a device other than the owner device. The method includes the steps of: receiving a deletion request from the share device that identifies the registered share key; if the share key identified in the received deletion request is in a direct lineage with the share key registered in the share device that is the sender of the deletion request and is a share key of a generation subsequent to the share key registered in the share device that is the sender of the deletion request, a processing circuit of the management server generates a deletion command that is an instruction to delete the registered share key; and executing a deletion process to delete the share key registered in a target share device in which the share key identified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device.

[0235] [Appendix 11] A method for deleting a digital key executed by a management server that manages multiple digital keys, including an owner key that is usable for a vehicle and is registered for an owner device that is a device belonging to the owner of the vehicle, and a share key that is registered for a share device that is a device other than the owner device, the method including: when a deletion request specifying a registered share key is received, a processing circuit of the management server generates a deletion command that instructs the management server to delete a share key of a generation subsequent to the share key that is in a direct lineage to the share key specified in the received deletion request; and a deletion process that deletes a share key of a generation subsequent to the share key that is in a direct lineage to the share key specified in the deletion request, which is registered in a target share device in which the share key specified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device.

[0236] [Appendix 12] A deletion program stored in a storage device of a management server that manages multiple digital keys, including digital keys that can be used for a vehicle and are registered for an owner device that is a device belonging to the owner of the vehicle, and a share key that is registered for a share device that is a device other than the owner device, and the deletion program causes a processing circuit of the management server to execute a process of generating a deletion command that is a command to delete a registered share key only when a deletion request that identifies the registered share key is received from the owner device, and a deletion process that deletes the share key registered in a target share device in which the share key identified in the received deletion request is registered, and in another share device in which the share key is registered based on a request from the target share device.

[0237] [Appendix 13] A deletion program stored in a storage device of a management server that manages multiple digital keys that can be used for a vehicle, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a share key registered for a share device that is a device other than the owner device. The deletion program receives a deletion request from the share device that identifies the registered share key, and if the share key identified in the received deletion request is in a direct lineage with the share key registered in the share device that sent the deletion request and is a share key of a generation later than the share key registered in the share device that sent the deletion request, generates a deletion command that is an instruction to delete the registered share key, and causes a processing circuit of the management server to execute a deletion process that deletes the share key registered in a target share device in which the share key identified in the received deletion request is registered and in another share device in which the share key is registered based on a request from the target share device.

[0238] [Appendix 14] A deletion program stored in a storage device of a management server that manages multiple digital keys, including digital keys that can be used for a vehicle and are registered for an owner device that is a device belonging to the owner of the vehicle, and shared keys that are registered for shared devices that are devices other than the owner device.The deletion program causes a processing circuit of the management server to execute, when a deletion request specifying a registered shared key is received, a process of generating a deletion command that is a command to delete a shared key of a generation subsequent to the shared key that is in a direct lineage to the shared key specified in the received deletion request, and a deletion process of deleting a shared key of a generation subsequent to the shared key that is in a direct lineage to the shared key specified in the deletion request, which is registered in a target shared device in which the shared key specified in the received deletion request is registered, and in another shared device in which the shared key is registered based on a request from the target shared device. [Explanation of symbols]

[0239] 20...Vehicle 30…Devices 40...Owner device 50...Shared devices 50T...Target shared device 70...Administration server 71...Execution device 72…Storage device 73...Communication module 81...List D61...Deletion request D62, D64...Deletion orders DEL...Delete process KO…Owner key KS...Share Key PM...Deletion program

Claims

1. A management server that manages a plurality of digital keys that are usable for a vehicle, including an owner key registered for an owner device that is a device belonging to an owner of the vehicle, and a shared key registered for a shared device that is a device other than the owner device, When a deletion request specifying the registered shared key is received, a target share device to which the share key specified in the received deletion request is registered; and another share device to which the share key is registered based on a request from the target share device; Execute the deletion process to delete the shared key registered in Management server.

2. The deletion process is also performed on the share key registered in the target share device in which a share key of a generation subsequent to the share key in the direct line relationship with the share key registered in the target share device is registered. The management server according to claim 1 .

3. The shared key to be protected can be set, and the deletion process is not executed for the shared key that is set as the protected target. The management server according to claim 1 .

4. When the deletion request is received, A list of the plurality of shared keys to be deleted is transmitted to the sender of the deletion request. The management server according to claim 1 .

5. When the deletion request is received, To the sender of the deletion request, Transmitting a list of the plurality of shared keys to be subject to the deletion process, The share key to be protected is selected from the share keys listed in the list. The management server according to claim 3 .

6. Vehicles and A plurality of digital keys usable for the vehicle, including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a shared key registered for a shared device that is a device other than the owner device; a management server that manages the plurality of digital keys; A management system comprising: When the management server receives a deletion request that identifies the registered share key, a target share device to which the share key specified in the received deletion request is registered; and another share device to which the share key is registered based on a request from the target share device; Execute the deletion process to delete the shared key registered in Management system.

7. A method for deleting a digital key executed by a management server that manages multiple digital keys that are usable for a vehicle, the digital keys including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a shared key registered for a shared device that is a device other than the owner device, When a deletion request specifying the registered shared key is received, a step in which a processing circuit of the management server generates a deletion command that is a command to delete the registered share key; and executing a deletion process to delete the share key registered in a target share device to which the share key specified in the received deletion request is registered, and in another share device to which the share key is registered based on a request from the target share device. How to delete a digital key.

8. a deletion program stored in a storage device of a management server that manages a plurality of digital keys that are usable for a vehicle, the digital keys including an owner key registered for an owner device that is a device belonging to the owner of the vehicle, and a shared key registered for a shared device that is a device other than the owner device; When a deletion request specifying the registered shared key is received, a process of generating a deletion command that instructs the registered share key to be deleted; and causing a processing circuit of the management server to execute a deletion process for deleting the share key registered in a target share device in which the share key specified in the received deletion request is registered and in another share device in which the share key is registered based on a request from the target share device. Remove program.

Images