Management server, management method, and program

Abstract

The management server determines whether or not to apply the designated condition in order to control the digital key to an unusable state according to the difference in how the vehicle is used based on the vehicle type.SOLUTION: The management server manages a plurality of digital keys for the vehicle. Based on the vehicle type TY, the management server determines whether or not to apply the prescribed condition RC to deletion of the digital key when a request to delete the digital key has been acquired. The management server controls the digital key to an unusable state in accordance with the determination result.SELECTED DRAWING: Figure 13

Description

[Technical Field]

[0001] The present invention relates to a management server, a management method, and a program. [Background technology]

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, multiple devices, and a management server. The digital key for the target vehicle is registered in the device. When the vehicle authenticates the digital key when using it, it allows control such as unlocking the vehicle. [Prior art documents] [Patent documents]

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

[0004] In managing digital keys, a management server such as that described in Patent Document 1 may manage a digital key in an unusable state when the digital key is deleted, provided that predetermined conditions are met. However, depending on how the vehicle is used, it may be desirable to manage the digital key in an unusable state when the digital key is deleted, regardless of the conditions. [Means for solving the problem]

[0005] In order to solve the above problem, the management server is a management server that manages multiple digital keys for vehicles, and when a request to delete the digital key is received, determines based on the type of vehicle whether or not specified conditions should be applied to the deletion of the digital key, and controls the digital key to an unusable state depending on the result of the determination.

[0006] In order to solve the above problem, the management method is a management method performed by a management server that manages digital keys for vehicles, and the management server determines, based on the type of vehicle, whether or not to apply specified conditions to the deletion of the digital key when it receives a request to delete the digital key, and controls the digital key to an unusable state depending on the result of the determination.

[0007] In order to solve the above problem, the program is a program to be executed by a management server, which is a computer that manages digital keys for vehicles, and causes the management server to determine, based on the type of vehicle, whether or not to apply specified conditions to the deletion of the digital key when a request to delete the digital key is received, and to control the digital key to an unusable state depending on the result of the determination. [Effects of the Invention]

[0008] In each of the above configurations, whether or not to apply the prescribed conditions for disabling the digital key can be adapted to the difference in the way the vehicle is used based on the type of vehicle. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a schematic diagram illustrating a management system according to an embodiment. [Figure 2] FIG. 2 is a schematic diagram showing owner key information according to the embodiment. [Figure 3] FIG. 3 is a schematic diagram showing the share key information of the embodiment. [Figure 4] FIG. 4 is a schematic diagram showing the relationship between data devices in the database of the embodiment. [Figure 5] FIG. 5 is a schematic diagram of information indicating vehicle types in the database of the embodiment. [Figure 6]FIG. 6 is an explanatory diagram showing a series of processes performed by the management system when registering an owner key according to the embodiment. [Figure 7] FIG. 7 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in the embodiment. [Figure 8] FIG. 8 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in the embodiment. [Figure 9] FIG. 9 is a schematic diagram showing a device whose device type is a server according to the embodiment. [Figure 10] FIG. 10 is an explanatory diagram showing a series of processes performed by the management system when an owner key is registered in a device whose device type is a server according to the embodiment. [Figure 11] FIG. 11 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in a device whose device type is a server in the embodiment. [Figure 12] FIG. 12 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 according to the embodiment. [Figure 13] FIG. 13 is a flowchart showing detailed processing of the fade-out determination performed by the management server of the embodiment. [Figure 14] FIG. 14 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 in the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] An embodiment of the management server will be described below with reference to the drawings. <Overview of the management system> As shown in FIG. 1, the management system 10 manages multiple digital keys that can be used for a target vehicle 20. There is a standard for digital keys, the Car Connectivity Consortium (CCC). Matters related to the digital keys in this embodiment are assumed to comply with the CCC, but can also be applied to standards and systems other than the CCC. The management system 10 includes multiple vehicles 20, multiple devices 30, a device server 60, and a management server 70. Note that FIG. 1 illustrates only one vehicle 20, and the other vehicles 20 are not illustrated.

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

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

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

[0014] 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 as information related to the digital key. The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating 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.

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

[0016] The device 30 is a portable device 30M or a predetermined server 30N. That is, the device type indicating the type of the device 30 includes the portable device 30M and the predetermined server 30N. In the example shown in FIG. 1, all the devices 30 are portable devices 30M.

[0017] The portable device 30M is, for example, a smartphone or a smart watch. The portable device 30M communicates with the vehicle 20 via short-range wireless communication. The mobile device 30M 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 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 as information related to the digital key. 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 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 functions for pairing the portable device 30M and sharing the digital key using an API provided in the OS. The execution unit 36 ​​executes the device program PD to perform processes related to storing and deleting the key information DK.

[0022] The multiple devices 30 include an owner device 40 and multiple shared devices 50. The owner device 40 stores owner key information DKO indicating an owner key KO as key information DK. 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 an already authorized vehicle public key PKV.

[0027] 1, the shared device 50 stores shared key information DKS indicating a shared key KS as key information DK. 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 shared devices 50 include a friend device 51 and a non-friend device 52. The friend device 51 stores, as the shared key information DKS, friend key information DKF indicating a friend key KF. The non-friend device 52 stores, as the shared key information DKS, non-friend key information DKN indicating a non-friend key KN. In other words, the types of shared keys KS include a friend key KF and a non-friend key KN. The friend key KF is a shared key KS registered based on a direct registration request D21 from the owner device 40, as will be described later. The non-friend key KN is a shared key KS registered based on a registration request D31 from the friend device 51, as will be described later. In other words, 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 different from the owner device 40.

[0029] The state in which the digital key is registered means that the digital key is usable, i.e., the vehicle 20 stores the authentication information AT and the device 30 stores the key information DK.

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

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

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

[0033] 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 key KS. For example, it is set as an identifiable name for each shared device 50 by operation from the owner device 40.

[0034] 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. For example, the type refers to the model of the device 30, and a device server 60 is provided for each model of the device 30. For example, the type refers to the communication line used by the device 30, and a device server 60 is provided for each communication line used by the device 30.

[0035] Any of the device servers 60 relays communication with the management server 70, so that different types of devices 30 can communicate with the management server 70 via the device servers 60. Note that only one device server 60 is shown in FIG.

[0036] <Administration Server> The management server 70 manages digital keys. The management server 70 is capable of communicating with the vehicle 20 and multiple devices 30. The management server 70 includes an execution device 71 and a storage device 72. The storage device 72 stores a server program PS and a database DB. When the execution device 71 executes the server program PS, the execution device 71 registers digital keys in the database DB and deletes digital keys from the database DB. Therefore, when the execution device 71 executes the server program PS, the management server 70 performs the management method.

[0037] In the database DB, each of a plurality of digital keys is associated with a corresponding vehicle 20 and a registered device 30. In the database DB, data DA is separated for each vehicle 20. When a digital key is registered, the database DB includes information indicating the device 30 that stores key information DK indicating the digital key, and information indicating the vehicle type TY for each vehicle 20.

[0038] 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. Hierarchical rankings are determined based on 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. The higher the hierarchy, the greater the authority set.

[0039] 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. Also, for example, each digital key can request the deletion of a digital key that is lower in the hierarchy than itself, but cannot request the deletion of a digital key that is higher in the hierarchy than itself.

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

[0041] The following describes a state in which digital keys are registered to seven devices 30 for one vehicle 20. The seven devices 30 are a first device 30A to a seventh device 30G. The digital keys registered in the first device 30A to the seventh device 30G, respectively, are referred to as the first key to the seventh key.

[0042] In the data DA, the device 30 whose type of digital key 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 key is the owner key KO.

[0043] 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 key to the seventh key are all shared keys KS.

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

[0045] In the data DA, the relationship between the second device 30B and the first device 30A is such that a 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 key is registered based on the first key.

[0046] In the data DA, the relationship between the fifth device 30E and the first device 30A is such that a 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 key is registered based on the first key.

[0047] 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 key is registered based on the second key.

[0048] 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 key is registered based on the second key.

[0049] 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 key is registered based on the fifth key.

[0050] 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 due to a registration request from the fifth device 30E. In other words, the seventh key is registered based on the fifth key.

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

[0052] 5, the database DB includes, for each of a plurality of vehicles 20, information on the vehicle type TY indicating the type of the vehicle 20. The vehicle type TY indicates whether the vehicle is a rental vehicle used for a rental car service, a shared vehicle used for a car sharing service, or neither a rental vehicle nor a shared vehicle.

[0053] Specifically, in the example shown in FIG. 5, the vehicle type TY of the first vehicle 20A is a rental vehicle. The vehicle type TY of the second vehicle 20B is a rental vehicle. The vehicle type TY of the third vehicle 20C is a shared vehicle. The vehicle type TY of the fourth vehicle 20D is a shared vehicle. The vehicle type TY of the fifth vehicle 20E is a shared vehicle. The vehicle type TY of the sixth vehicle 20F is a shared vehicle. The vehicle type TY of the seventh vehicle 20G is neither a rental vehicle nor a shared vehicle.

[0054] <Digital key registration> Next, we will explain a series of processes for registering digital keys in the management system 10. The management system 10 registers digital keys by registering an owner key KO, a friend key KF, and a non-friend key KN.

[0055] First, a series of processes for registering a digital key when the device 30 is the portable device 30M will be described. Below, a series of flows from when each digital key is not registered to when the digital key is registered will be described. In the following description, the processes executed by the execution unit 27 will be described as processes executed by the vehicle 20, the processes executed by the execution unit 36 ​​will be described as processes executed by the device 30, and the processes executed by the execution unit 71 will be described as processes executed by the management server 70.

[0056] <Registering an owner key for mobile devices> 6, 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.

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

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

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

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

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

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

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

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

[0065] 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. The first device 30A then transmits the key track request D12 for the owner key KO and information indicating the vehicle type TY of the target vehicle 20 to the management server 70 via the device server 60. In the example shown in FIG. 6, the vehicle type TY of the target vehicle 20 is neither a rental vehicle nor a shared vehicle. In this embodiment, when the device 30 is a portable device 30M, the vehicle type TY of the target vehicle 20 is transmitted when transmitting the key track request D12 after generating the owner key information DKO.

[0066] 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. The management server 70 also stores in the database DB that the vehicle type TY of the target vehicle 20 is neither a rental vehicle nor a shared vehicle. This causes the management system 10 to end the series of processes for the owner key KO.

[0067] <Registering a friend key for mobile devices> 7, 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.

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

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

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

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

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

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

[0074] In step S25, the owner device 40 generates signature information ATP1. In detail, 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. Then, the owner device 40 proceeds to step S26.

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

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

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

[0078] Thereafter, when the management server 70 receives a key track request D23 for the friend key KF, the management server 70 performs the process of step S29. In step S29, the management server 70 performs registration management of the friend key KF.

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

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

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

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

[0083] 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 processing of step S31. In the processing of step S31, the second device 30B presents information indicating the completion of the registration of the friend key KF to the HMI 32. For example, the second device 30B presents an image indicating the completion of the registration of the friend key KF to 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.

[0084] <Registering a non-friend key for mobile devices> 8, the management system 10 performs a series of 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 referred to as a third device 30C.

[0085] When an operation to request registration of a non-friend key KN is executed in 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 second device 30B 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] <Device that is the given server> Next, a series of processes for registering a digital key when the device 30 is a predetermined server 30N will be described.

[0102] 9, the predetermined server 30N includes a communication module 31, an execution device 36, and a storage device 37. That is, the predetermined server 30N does not include an HMI 32, a BLE module 33, a UWB module 34, or an NFC module 35. Therefore, the predetermined server 30N does not communicate with the vehicle 20 via short-range wireless communication.

[0103] <Registering an owner key for a specific server> 10, the management system 10 performs a series of processes to register the owner key KO with a predetermined server 30N. When a predetermined operation is performed, the first device 30A transmits a registration request D11 for the owner key KO and a fleet signal FL to the management server 70. When the management server 70 receives the registration request D11 for the owner key KO and the fleet signal FL, the management server 70 first performs the process of step S61. The fleet signal FL is a signal indicating that a request to register a digital key has been made from the device 30, which is the predetermined server 30N.

[0104] In step S61, the management server 70 identifies the generation data DC for generating the owner key KO. The generation data DC includes each piece of information included in the owner key information DKO. When receiving the fleet signal FL, the management server 70 identifies the generation data DC for generating the owner key KO of the target vehicle 20 from the generation data DC for multiple vehicles 20 stored in advance. Note that the management server 70 acquires the generation data DC for generating a digital key for the target vehicle 20 from an external server when the user of the first device 30A signs a contract to use a specific server 30N as the first device 30A. As a result, the management server 70 pre-stores the generation data DC for generating the digital key of the target vehicle 20. The generation data DC for generating the digital key includes generation data DC for generating each of the owner key KO and the shared key KS. The management server 70 then transmits the identified generation data DC to the first device 30A.

[0105] Thereafter, when the first device 30A receives the generated data DC, the first device 30A performs the process of step S62. In step S62, the first device 30A generates owner key information DKO using the generated data DC. Then, the first device 30A proceeds to the process of step S63.

[0106] In step S63, the first device 30A stores the owner key information DKO. As a result, the first device 30A becomes the owner device 40. Then, the first device 30A transmits a key track request D12 for the owner key KO and information indicating the vehicle type TY of the target vehicle 20 to the management server 70. In the example shown in FIG. 10, the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle.

[0107] Thereafter, when the management server 70 receives the key track request D12, the management server 70 performs processing of step S64. In step S64, 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. The management server 70 also stores in the database DB that the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle. Thereafter, the management server 70 transmits certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD to the vehicle 20.

[0108] Thereafter, when vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process of step S65. In step S65, vehicle 20 verifies certificate information ST5. When verification of certificate information ST5 is completed, vehicle 20 performs the process of step S66.

[0109] In step S66, the vehicle 20 stores the device public key information ST6 as authentication information AT. This causes the management system 10 to end the series of processes for the owner key KO for the device 30 that is the predetermined server 30N.

[0110] <Registering a friend key for a specific server> 11, the management system 10 performs a series of processes to register a friend key KF with a predetermined server 30N. When a predetermined operation is performed, the owner device 40 transmits a friend key KF registration request D21 and a fleet signal FL to the management server 70. When the management server 70 receives the friend key KF registration request D21 and the fleet signal FL from the owner device 40, the management server 70 first performs the process of step S71.

[0111] In step S71, the management server 70 identifies the generation data DC for generating the friend key KF. The generation data DC includes each piece of information included in the friend key information DKF. When the fleet signal FL is received, the management server 70 identifies the generation data DC for generating the friend key KF of the target vehicle 20 from the generation data DC for multiple vehicles 20 stored in advance. Thereafter, the management server 70 transmits the identified generation data DC to the second device 30B.

[0112] Thereafter, when the second device 30B receives the generated data DC, the second device 30B performs the process of step S72. In step S72, the second device 30B generates friend key information DKF using the generated data DC. Thereafter, the second device 30B proceeds to the process of step S73.

[0113] In step S73, the second device 30B stores the friend key information DKF. As a result, the second device 30B becomes a friend device 51. The second device 30B then transmits a key track request D23 for the friend key KF and information indicating the vehicle type TY of the target vehicle 20 to the management server 70. In the example shown in FIG. 11, the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle.

[0114] Thereafter, when the management server 70 receives the key track request D23, the management server 70 performs the process of step S74. In step S74, the management server 70 performs registration management of the friend key KF.

[0115] Specifically, the management server 70 stores the second device 30B in the data DA of the vehicle 20 in the database DB as a device 30 registered as a friend key KF. The management server 70 also stores in the data DA information on the relationship between the second device 30B and the first device 30A, indicating that the second device 30B was registered based on a registration request from the first device 30A. Furthermore, the management server 70 stores in the database DB that the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle. Even if the management server 70 previously stored the vehicle type TY of the target vehicle 20 as neither a rental vehicle nor a shared vehicle when registering the owner key KO, it changes the vehicle type TY of the target vehicle 20 to a rental vehicle or a shared vehicle. The management server 70 then transmits a storage request D24 and an authentication package ATP to the vehicle 20.

[0116] Thereafter, when the management server 70 receives the storage request D24, it performs the process of step S75. In step S75, the management server 70 stores the authentication package ATP as authentication information AT in accordance with the storage request D24.

[0117] After the management server 70 transmits the storage request D24 and the authentication package ATP to the vehicle 20, the management server 70 transmits a completion notification M41 to the owner device 40. The completion notification M41 is a notification indicating that the registration of the friend key KF has been completed.

[0118] Thereafter, when the owner device 40 receives the completion notification M41, the owner device 40 performs the process of step S76. In step S76, the owner device 40 displays the completion of registration of the friend key KF on the HMI 32. This causes the management system 10 to end the series of processes for the friend key KF targeted at the device 30 that is the specified server 30N.

[0119] <Non-friend key deletion control> Next, we will explain the deletion control including a series of processes for deleting a non-friend key KN in the management system 10. The deletion control performed by the management server 70 includes a fade-out determination, which will be described later, sending a deletion request D42, sending a deletion request D43, and updating the database DB.

[0120] The following describes the process from when the non-friend key KN is registered to when the non-friend key KN is not registered. In the following description, the process executed by the execution unit 27 is described as the process executed by the vehicle 20, the process executed by the execution unit 36 ​​is described as the process executed by the device 30, and the process executed by the execution unit 71 is described as the process executed by the management server 70.

[0121] <Deleting a non-friend key upon a deletion request from a friend device> 12, the management system 10 performs a series of processes to delete a non-friend key KN based on a deletion request D41 from a friend device 51, which is a predetermined server 30N. In this embodiment, the server program PS is a program that causes the management server 70, which is a computer, to perform deletion control.

[0122] When an operation to request deletion of the non-friend key KN is executed in the friend device 51, the friend device 51 first performs the process of step S81. In step S81, a deletion request D41 is generated, which is a request to delete the non-friend key KN.

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

[0124] Thereafter, when the management server 70 receives a deletion request D41 for the non-friend key KN, it performs processing of step S82. In step S82, the management server 70 performs a fade-out determination. The fade-out determination is a process of determining whether or not to put the state of the non-friend key KN for which the deletion request D41 has been made into a fade-out state. The fade-out state is a state in which, after receiving a request to delete the target shared key KS, the shared key KS is made unusable when a predetermined specified condition RC is met, but the specified condition RC has not yet been met.

[0125] 13, when the management server 70 starts the fade-out determination, the management server 70 first performs the process of step S101. In step S101, the management server 70 identifies the target vehicle 20. The target vehicle 20 is the vehicle 20 in which the non-friend key KN that is the target of the deletion request D41 is registered.

[0126] Specifically, the management server 70 refers to the vehicle identification information ST1 included in the deletion request D41 to identify the target vehicle 20. After that, the management server 70 advances the process to step S102.

[0127] In step S102, the management server 70 identifies the vehicle type TY of the target vehicle 20. Specifically, the management server 70 refers to the database DB to identify the vehicle type TY of the target vehicle 20 identified in step S101. For example, when the target vehicle 20 is the first vehicle 20A, the management server 70 identifies the type of the vehicle 20 as a rental vehicle. Thereafter, the management server 70 proceeds to step S103.

[0128] In step S103, the management server 70 determines whether the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle. If the vehicle type TY of the target vehicle 20 is neither a rental vehicle nor a shared vehicle (S103: NO), the management server 70 proceeds to step S104. In step S104, the management server 70 determines that the state of the digital key to be deleted is to be faded out by a fade-out determination. In other words, when the management server 70 receives a deletion request for the digital key to be deleted, it determines that the specified condition RC is to be applied to the deletion of the digital key. Thereafter, the management server 70 proceeds to step S105.

[0129] In step S105, the management server 70 stores the state of the digital key to be deleted in the database DB as a fade-out state. The fade-out state is a state in which the deletion request D41 has been received but the execution of deletion is still pending. The management server 70 then proceeds to step S106.

[0130] In step S106, the management server 70 determines whether a predetermined prescribed condition RC is satisfied. The prescribed condition RC is a condition necessary to start deletion after receiving the deletion request D41. The prescribed condition RC is predetermined. For example, the prescribed condition RC is that a predetermined fade-out period has elapsed since receiving the deletion request D41. When the management server 70 determines that the prescribed condition RC is not satisfied (S106: NO), the management server 70 repeats the processing of step S106. On the other hand, when the management server 70 determines that the prescribed condition RC is satisfied (S106: YES), the management server 70 ends this fade-out determination.

[0131] Meanwhile, when the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle (S103: YES), the management server 70 advances the process to step S107. In step S107, the management server 70 determines that the digital key to be deleted is not in the fade-out state through the fade-out determination. The management server 70 then ends the current fade-out determination. Therefore, the management server 70 ends the fade-out determination regardless of whether the specified condition RC is satisfied.

[0132] As shown in FIG. 12, after completing the fade-out determination, the management server 70 proceeds to step S83. In step S83, the management server 70 generates a deletion request D42 for non-friend key information DKN indicating the non-friend key to be deleted. The management server 70 then transmits the deletion request D42 to the non-friend device 52 in which the non-friend key KN to be deleted is registered. Therefore, when the management server 70 makes a positive determination in the fade-out determination, the management server 70 transmits the deletion request D42 to the non-friend device 52 when the specified condition RC is satisfied. As a result, the management server 70 controls the non-friend key KN to be deleted so that it cannot be used. On the other hand, when the management server 70 makes a negative determination in the fade-out determination, the management server 70 transmits the deletion request D42 to the non-friend device 52 regardless of the specified condition RC, thereby controlling the non-friend key KN to be deleted so that it cannot be used. That is, the management server 70 controls the non-friend key KN to be deleted so that it cannot be used, depending on the result of the fade-out determination.

[0133] Thereafter, when the non-friend device 52 receives the deletion request D42, it performs processing in step S84. In step S84, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion request 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 request D42 has been completed.

[0134] Thereafter, when the management server 70 receives the completion notification M42, the management server 70 performs the process of step S85. In step S85, 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 S86.

[0135] In step S86, the management server 70 generates a deletion request D43 for the authentication information AT. The deletion request 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 subject of the deletion request D41. The management server 70 then transmits the deletion request D43 to the vehicle 20.

[0136] Thereafter, when the vehicle 20 receives the deletion request D43, the vehicle 20 performs the processing of step S87. In step S87, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN that is the subject of the deletion request D41 in accordance with the deletion request 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 request D43 has been completed.

[0137] Thereafter, when the management server 70 receives the completion notification M43, the management server 70 performs the process of step S88. In step S71, the management server 70 stores the history of the deletion 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 S89.

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

[0139] Thereafter, when the friend device 51 receives the completion notification M44, the friend device 51 performs the process of step S90. In step S90, 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 request 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.

[0140] <Deletion of non-friend keys due to deletion on non-friend devices> As shown in FIG. 14, 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.

[0141] When a predetermined operation requesting the deletion of the non-friend key KN is executed in the non-friend device 52, the non-friend device 52 first performs the processing of step S111. In step S111, 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.

[0142] Thereafter, when the management server 70 receives the completion notification M51, the management server 70 performs the process of step S112. In step S112, 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 friend device 51, indicating that the non-friend key information DKN has been deleted.

[0143] Thereafter, when the friend device 51 receives the completion notification M52, the friend device 51 performs the process of step S113. In step S113, 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.

[0144] After processing step S112, the management server 70 performs processing step S114. In step S114, the management server 70 generates a deletion request D51 for deleting the authentication information AT for authenticating the non-friend key information DKN whose deletion has been completed in the completion notification M51. Then, the management server 70 transmits the deletion request D51 to the vehicle 20.

[0145] Thereafter, when the vehicle 20 receives the deletion request D51, the vehicle 20 performs the processing of step S115. In step S115, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN that was deleted in step S111 in accordance with the deletion request D51. The vehicle 20 then transmits a completion notification M53 to the management server 70 indicating that the deletion of the authentication information AT in accordance with the deletion request D51 has been completed.

[0146] Thereafter, when the management server 70 receives the completion notification M53, the management server 70 performs the process of step S116. In step S116, the management server 70 stores the history of the deletion of the authentication information AT for authenticating the non-friend key KN that was completely deleted in step S111. Thereafter, the management server 70 proceeds to the process of step S117.

[0147] In step S117, 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 this time. In other words, when deleting the non-friend key KN due to a deletion operation in the non-friend device 52 that stores non-friend key information DKN indicating the non-friend key KN to be deleted, the management server 70 does not perform a fade-out determination.

[0148] <Operation of the embodiment> In the above embodiment, if the vehicle type TY of the target vehicle 20 is neither a rental vehicle nor a shared vehicle, there is a high probability that the vehicle 20 is being used by the owner himself. On the other hand, if the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle, there is a high probability that the vehicle 20 is not being used directly by the owner, but that the owner is lending the vehicle 20 to other users for use through a rental car service or a car sharing service. In this case, the share key KS is registered in the device 30 of the user who will use the vehicle 20 for a predetermined period of time.

[0149] <Effects of the embodiment> (1) The management server 70 determines whether to put the digital key to be deleted into a fade-out state based on the vehicle type TY of the target vehicle 20. Then, when the management server 70 receives a deletion request D41, it controls the non-friend key KN to be deleted into an unusable state based on the result of the fade-out determination. That is, when the management server 70 receives a deletion request D41 for the digital key to be deleted, it determines whether to apply the specified condition RC to the deletion of the digital key based on the vehicle type TY of the target vehicle 20. Furthermore, the management server 70 controls the digital key into an unusable state based on the result of the determination. Therefore, the management server 70 can determine whether to apply the specified condition RC to control the non-friend key KN into an unusable state based on the difference in how the vehicle 20 is used based on the vehicle type TY of the target vehicle 20.

[0150] (2) In the deletion control, the management server 70 controls the non-friend key KN to be deleted so that the non-friend key KN to be deleted cannot be used by deleting the key information DK indicating the non-friend key KN to be deleted. Therefore, the management server 70 can easily make the user of the device 30 to which the digital key to be deleted is registered recognize that the non-friend key KN to be deleted cannot be used on the device 30.

[0151] (3) In the deletion control, the management server 70 sends a deletion request D42 to the non-friend device 52 in which the non-friend key KN to be deleted is registered. This causes the management server 70 to cause the non-friend device 52 to delete the non-friend key information DKN indicating the non-friend key KN to be deleted. Therefore, when the device 30 in which the digital key to be deleted is registered receives the deletion request D42, the management server 70 causes the device 30 to delete the key information DK indicating the digital key to be deleted.

[0152] (4) In the deletion control, the management server 70 controls the non-friend key KN to be deleted so that it cannot be used by deleting the authentication information AT of the non-friend key KN to be deleted stored in the vehicle management device 26. Therefore, by controlling the vehicle management device 26, the management server 70 can manage the digital key to be deleted so that it cannot be used.

[0153] (5) In deletion control, the management server 70 causes the vehicle management device 26 to delete the authentication information AT of the non-friend key KN to be deleted by sending a deletion request D43 for the authentication information AT of the non-friend key KN to be deleted to the vehicle 20. When the authentication information AT is deleted from the vehicle management device 26, the digital key will not be authenticated even if the user attempts to use it, and the user will no longer be able to use the digital key to be deleted. Therefore, by sending the deletion request D43 to the vehicle 20, the management server 70 can manage the digital key to be deleted so that it cannot be used.

[0154] (6) If the vehicle type TY of the vehicle 20 to be deleted is a rental vehicle or a shared vehicle, there is a high probability that the vehicle 20 is not used directly by the owner, but is instead lent to another user who uses a rental car service or car sharing service. In this case, the user of the shared device 50 to which the non-friend key KN as the shared key KS to be deleted is registered changes every predetermined period of time for the rental car service or car sharing service. Therefore, the shared device 50 to which the shared key KS to be deleted is registered also changes every period of time. Suppose that the shared key KS to be deleted is made unusable when the specified condition RC is met. In this case, the vehicle 20 may continue to be used by the shared device 50 to which the shared key KS to be deleted is registered, which may prevent the next user from using the vehicle 20 promptly.

[0155] In this regard, when the target vehicle 20 is a rental vehicle, the management server 70 makes a positive determination in step S104 and determines not to put the vehicle 20 into a fade-out state in the processing of step S107. In this case, after receiving the deletion request D41 for the non-friend key KN, the management server 70 makes the non-friend key KN to be deleted unusable regardless of the specified condition RC. Therefore, the management server 70 can prevent the vehicle 20 from being used for an excessively long period of time by the shared device 50 to which the shared key KS to be deleted is registered. As a result, the management server 70 can prevent other users from being unable to use the vehicle 20.

[0156] (7) When the target vehicle 20 is neither a rental vehicle nor a shared vehicle, the vehicle 20 is likely to be used by the owner himself / herself. In this case, the shared key KS of the vehicle 20 is likely to be a digital key that has been personally loaned and authorized to use the vehicle 20. In this case, the user of the shared device 50 may board and drive the vehicle 20 without a predetermined period of time, as in rental car services and car sharing services. If the shared key KS is made unusable regardless of the specified condition RC, the user of the shared device 50 to which the shared key KS to be deleted is registered may suddenly be unable to use the vehicle 20.

[0157] In this regard, when the vehicle type TY of the target vehicle 20 is neither a rental vehicle nor a shared vehicle, the management server 70 makes a negative determination in step S103 and determines to enter a fade-out state in the processing of step S105. In this case, when the specified condition RC is met after receiving the deletion request D41 for the shared key KS, the management server 70 makes the shared key KS to be deleted unusable. Therefore, the management server 70 can prevent the user of the shared device 50 to which the shared key KS to be deleted is registered from suddenly becoming unable to use the vehicle 20.

[0158] (8) The management server 70 performs a fade-out determination when it receives a deletion request D41 for the non-friend key KN to be deleted. Therefore, the management server 70 performs a fade-out determination based on the vehicle type TY of the target vehicle 20 when a fade-out determination becomes necessary. Therefore, the management server 70 can perform a fade-out determination when the result of the determination is necessary.

[0159] <Other embodiments> The above embodiment can be modified as follows: The above embodiment and the following modifications can be combined with each other within the scope of technical compatibility.

[0160] The vehicle 20 may not have all of the BLE module 23, the UWB module 24, and the NFC module 25. As long as the vehicle 20 has at least one module, it can perform short-range wireless communication with the device 30. Furthermore, the vehicle 20 is not limited to these modules, and may have any module that performs short-range wireless communication with the device 30.

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

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

[0163] The plurality of devices 30 may all be portable devices 30M. That is, the device type may all be portable devices 30M. Furthermore, the portable devices 30M may provide a rental car service or a car sharing service.

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

[0165] A 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.

[0166] 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. Alternatively, for example, when the type of the device 30 is a predetermined server 30N, the predetermined server 30N may be included in a server that includes the management server 70.

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

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

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

[0170] 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 required for management by the management server 70 in the management system 10.

[0171] In each of the above embodiments, digital keys have a hierarchy arranged in the order of owner key KO, friend key KF, and non-friend key KN, with the higher the hierarchy, the greater the authority. Digital keys do not necessarily have to be set so that the higher the hierarchy, the greater the authority. For example, the same authority level may be set for the three hierarchical levels of owner key KO, friend key KF, and non-friend key KN.

[0172] In the database DB, the authority may be set for each digital key, rather than being uniformly determined according to the type of digital key. Also, the authority may not be determined in the database DB.

[0173] The information about the digital key stored in the vehicle management device 26 is not limited to the authentication information AT, and may be any information about the digital key. For example, the information about the digital key may be information that identifies the digital key.

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

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

[0176] <The process for registering a digital key> When the owner device 40 is the portable device 30M, the series of processes for registering the owner key KO is not limited to the example of the above embodiment. 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.

[0177] When the owner device 40 is a predetermined server 30N, the series of processes for registering the owner key KO is not limited to the example of the above embodiment. For example, the management server 70 may receive the owner key KO registration request D11 and the fleet signal FL from a server other than the first device 30A.

[0178] If the friend device 51 is a portable device 30M, the series of processes for registering the friend key KF is not limited to the example of the above embodiment. 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 included in the friend key information DKF and the structure of the information included in the authentication information AT.

[0179] When the friend device 51 is the portable device 30M, the series of processes for registering the friend key KF is not limited to the example in the above embodiment. For example, the management server 70 may create the friend key information DKF.

[0180] When the friend device 51 is a portable device 30M, the series of processes for registering the non-friend key KN is not limited to the examples in the above embodiments. The order of the processes may be different from the series of processes for registering the friend key KF. The series of processes for registering the non-friend key KN may be modified as appropriate to suit the structure of the information included in the non-friend key information DKN and the structure of the information included in the authentication information AT.

[0181] The types of digital keys do not have to include non-friend keys KN. That is, in the management system 10, the share keys KS may only be friend keys KF. The digital key to be deleted may be either a friend key KF or an owner key KO. In the above embodiment, the digital key to be deleted in response to a deletion request is a share key KS.

[0182] The non-friend device 52 may be able to transmit a request to register a new non-friend key KN. In other words, the share device 50 may transmit a request to register a new non-friend key KN regardless of whether it is a friend device 51 or a non-friend device 52. In this case, the management system 10 may register the new non-friend key KN by the series of processes shown in FIG. 7.

[0183] The device type of the non-friend device 52 may be a predetermined server 30N. As in the above-described modified example, if the non-friend device 52 can send a request to register a new non-friend key KN, the user of the non-friend device 52 may rent out the vehicle 20, such as in a car rental service or a car sharing service. In this case, the device type of the non-friend device 52 may be a predetermined server 30N.

[0184] <The process for deleting a digital key> 14, when deleting a non-friend device 52 due to an operation of the non-friend device 52, a deletion request D41 for the non-friend key KN may be sent to the management server 70 before a completion notification M51 is sent to the management server 70. In this case, similar to the series of flows shown in Fig. 12, when the management server 70 receives the deletion request D41, the management server 70 may send a request to delete the non-friend key information DKN to the non-friend device 52. When deleting a non-friend device 52 due to an operation of the non-friend device 52, the management server 70 may also perform a fade-out determination.

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

[0186] The owner device 40 and the vehicle 20 may transmit a deletion request D41 for the non-friend key KN to the management server 70. Alternatively, for example, the management server 70 may generate the deletion request D41 for the non-friend key KN when a predetermined condition is satisfied.

[0187] In the above embodiment, the management server 70 determines whether the specified condition RC is satisfied, but the management server 70 may determine whether the vehicle 20 or the non-friend device 52 satisfies the specified condition RC. For example, if the specified condition RC is that the number of operations to turn on the vehicle 20 reaches a specified number, it is preferable to determine whether the vehicle 20 satisfies the specified condition RC.

[0188] <Timing for determining whether to enter fade-out state> The timing when the management server 70 performs the fade-out determination is not limited to when it receives the deletion request D41 for the digital key to be deleted. For example, the management server 70 may perform the fade-out determination when registering the digital key.

[0189] 11, the management server 70 may perform the processes of steps S101 to S104 and step S107. When the management server 70 performs the process of step S104, the management server 70 stores in the database DB information indicating that the target digital key is to be put into a fade-out state. When the management server 70 performs the process of step S107, the management server 70 stores in the database DB information indicating that the target digital key is not to be put into a fade-out state.

[0190] When the management server 70 receives a deletion request D41 for the target digital key, if information for putting the digital key into a fade-out state is stored in the database DB, the management server 70 can make the target digital key unusable when the specified condition RC is met. On the other hand, when the management server 70 receives a deletion request D41 for the target digital key, if information for not putting the digital key into a fade-out state is stored in the database DB, the management server 70 can make the target digital key unusable regardless of the specified condition RC.

[0191] In this case, the management server 70 determines whether to put the target digital key into a fade-out state when the target digital key is registered, thereby making a determination in advance before receiving the deletion request D41 for the digital key to be deleted. Thus, when the deletion request D41 for the target digital key is received, the management server 70 can already grasp the result of the determination.

[0192] <Vehicle type> In the above embodiment, the vehicle type TY indicates whether the vehicle is a rental vehicle, a shared vehicle, or neither a rental vehicle nor a shared vehicle. However, the vehicle type TY is not limited to this. For example, the vehicle type TY may indicate only whether the vehicle is a rental vehicle. In this case, the management server 70 may perform a fade-out determination based on whether the vehicle type TY of the target vehicle 20 is a rental vehicle.

[0193] Furthermore, for example, the vehicle type TY may indicate only whether or not the vehicle is a shared vehicle. In this case, the management server 70 may perform a fade-out determination based on whether or not the vehicle type TY is a shared vehicle.

[0194] Furthermore, for example, the vehicle type TY is not limited to a rental vehicle or a shared vehicle, and may indicate whether the vehicle is used by different users for each predetermined period. The management server 70 may make a fade-out determination based on the vehicle type TY of the target vehicle 20. Therefore, the result of the fade-out determination by the management server 70 may be the opposite of the result in the example of the above embodiment.

[0195] The management server 70 may store the vehicle type TY regardless of the information indicating the vehicle type TY received from the device 30. For example, the management server 70 may acquire information indicating the vehicle type TY from the vehicle 20 when a predetermined operation is performed on the vehicle 20. Alternatively, for example, the management server 70 may determine the vehicle type TY based on whether or not a fleet signal FL has been received from the same device 30 before performing registration management. Specifically, if the management server 70 has received a fleet signal FL from the device 30 to which a digital key for the target vehicle 20 is to be registered before performing registration management, the management server 70 may determine that the vehicle type TY of the target vehicle 20 is a rental vehicle or a shared vehicle.

[0196] In the above embodiment, one vehicle 20 is associated with one vehicle type TY, but this is not limited to this. For one vehicle 20, a vehicle type TY may be associated with each digital key among multiple digital keys for the vehicle 20 or with each device to which the digital key is registered. For example, in the example shown in FIG. 5 , the vehicle type TY for the first device 30A to the fourth device 30D may not be a rental vehicle or a shared vehicle, while the vehicle type TY for the fifth device 30E to the seventh device 30G may be a rental vehicle or a shared vehicle. Among the first device 30A to the seventh device 30G, only the device type of the fifth device 30E is a predetermined server 30N. In this case, the users of the first device 30A to the fourth device 30D do not use the target vehicle 20 as a rental vehicle or a shared vehicle. On the other hand, if the user of the fifth device 30E uses a rental car service or a car sharing service, the users of the sixth device 30F and the seventh device 30G use the target vehicle 20 as a rental vehicle or a shared vehicle. In such a case, it is preferable that the vehicle type TY corresponds to each digital key or each device to which the digital key is registered.

[0197] In the above embodiment, the management server 70 identifies the vehicle type TY by referring to the database DB stored in the storage device 72. However, the vehicle type TY may be identified without using the database DB. For example, when performing step S103, the management server 70 may communicate with the target vehicle 20 to acquire information indicating the vehicle type TY from the vehicle 20. The management server 70 may then make a fade-out determination based on the acquired vehicle type TY.

[0198] <How to disable it> The method by which the management server 70 makes the digital key to be deleted unusable is not limited to the above embodiment. For example, the management server 70 may send a prohibition request to the vehicle management device 26 prohibiting the use of the authentication information AT of the digital key to be deleted, and the vehicle management device 26, upon receiving the prohibition request, may prohibit the use of the authentication information AT of the digital key to be deleted.

[0199] The method by which the management server 70 deletes the key information DK indicating the digital key to be deleted is not limited to sending the deletion request D42. For example, the management server 70 may periodically send a continuation request to the device 30 to continue storing the key information DK indicating the digital key, causing the device 30 to continue storing the key information DK indicating the digital key. In this case, the management server 70 may delete the key information DK indicating the digital key to be deleted by not sending the continuation request.

[0200] The management server 70 does not have to delete the key information DK indicating the digital key to be deleted. For example, the management server 70 may make the digital key to be deleted unusable by only deleting the authentication information AT of the digital key to be deleted.

[0201] The method by which the management server 70 deletes the authentication information AT of the digital key to be deleted is not limited to sending the deletion request D43. For example, the management server 70 may periodically send a continuation request to continue storing the authentication information AT of the digital key, causing the vehicle management device 26 to continue storing the authentication information AT of the digital key. In this case, the management server 70 may delete the authentication information AT of the digital key to be deleted by not sending the continuation request.

[0202] The management server 70 does not have to delete the authentication information AT of the digital key to be deleted. For example, the management server 70 may simply delete the key information DK indicating the digital key to be deleted, thereby rendering the digital key to be deleted unusable.

[0203] (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 for vehicles, which, when it receives a request to delete the digital key based on the type of vehicle, determines whether or not to apply specified conditions to the deletion of the digital key, and controls the digital key to an unusable state depending on the result of the determination.

[0204] [Appendix 2] When controlling the digital key to an unusable state, the management server described in Appendix 1 controls the digital key to an unusable state by deleting information about the digital key stored in the device to which the digital key is registered.

[0205] [Appendix 3] When controlling the digital key to an unusable state, the management server described in Appendix 2 deletes information about the digital key by sending a request to the device to delete information about the digital key.

[0206] [Appendix 4] When controlling the digital key to an unusable state, the management server described in any one of Appendices 1 to 3 controls the digital key to an unusable state by deleting information about the digital key stored in the vehicle management device of the vehicle.

[0207] [Appendix 5] When controlling the digital key to an unusable state, the management server described in Appendix 4 deletes information about the digital key by sending a request to the vehicle to delete information about the digital key.

[0208] [Appendix 6] The multiple digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle, and when determining whether to apply the specified conditions, if the type of vehicle is a rental vehicle used for a rental car service, the management server described in any one of Appendices 1 to 5 determines that the specified conditions do not apply to the deletion of the share key when a request to delete the share key is received.

[0209] [Appendix 7] The multiple digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle, and when determining whether to apply the specified conditions, the management server described in any one of Appendices 1 to 6 determines that the specified conditions should be applied to the deletion of the share key when a request to delete the share key is received if the type of vehicle is not a rental vehicle used for a rental car service.

[0210] [Appendix 8] The multiple digital keys include an owner key, of which only one can be registered to the vehicle, and a share key, of which multiple can be registered to the vehicle, and when determining whether to apply the specified conditions, if the type of vehicle is a shared vehicle used in a car sharing service, the management server described in any one of Appendices 1 to 5 determines that the specified conditions do not apply to the deletion of the share key when a request to delete the share key is received.

[0211] [Appendix 9] The multiple digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle, and when determining whether to apply the specified conditions, if the type of vehicle is not a share vehicle used for a car sharing service, and when a request to delete the share key is received, the management server described in any one of Appendices 1 to 6 and Appendices 8 determines not to apply the specified conditions to the deletion of the share key.

[0212] [Supplementary Note 10] The management server according to any one of Supplementary Notes 1 to 9, which determines whether or not to apply the specified condition when a request to delete the digital key is received. [Appendix 11] A management server according to any one of Appendices 1 to 9, which determines whether or not the specified conditions apply when registering the digital key, and controls the digital key to an unusable state when a request to delete the digital key is received. [Explanation of symbols]

[0213] 10...Management system 20...Vehicle 26...Vehicle management device 27...Execution device 28…Storage device 30…Devices 36...Execution device 37…Storage device 40...Owner device 50...Shared devices 51...Friend Device 52...Non-Friendly Device 60...Device Server 70...Administration server AT…Authentication information DKO…Owner key information DKS…Share Key Information KF...Friend Key KN...Non-Friend Key KO…Owner key KS...Share Key RC…Specified conditions TY...Vehicle type

Claims

1. A management server that manages a plurality of digital keys for a vehicle, determining whether to apply a prescribed condition to the deletion of the digital key when a request to delete the digital key is received based on the vehicle type; and controlling the digital key to be in an unusable state according to the result of the determination. Management server.

2. When the digital key is controlled to be unusable, information about the digital key stored in a device to which the digital key is registered is deleted, thereby controlling the digital key to be unusable. The management server according to claim 1 .

3. When the digital key is controlled to be in an unusable state, a request to delete information about the digital key is sent to the device, thereby causing the device to delete information about the digital key. The management server according to claim 2 .

4. When the digital key is controlled to be unusable, the digital key is controlled to be unusable by deleting information about the digital key stored in the vehicle management device of the vehicle. The management server according to claim 1 .

5. When the digital key is controlled to be in an unusable state, a request to delete information about the digital key is transmitted to the vehicle, thereby deleting the information about the digital key. The management server according to claim 4.

6. The plurality of digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle; When determining whether or not to apply the specified condition, if the type of the vehicle is a rental vehicle used for a rental car service, and a request to delete the share key is received, it is determined that the specified condition does not apply to the deletion of the share key. The management server according to claim 1 .

7. The plurality of digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle; When determining whether or not to apply the specified condition, if the type of the vehicle is not a rental vehicle used for a rental car service, and a request to delete the share key is received, it is determined that the specified condition is applied to the deletion of the share key. The management server according to claim 1 .

8. The plurality of digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle; When determining whether or not to apply the specified condition, if the type of the vehicle is a shared vehicle used in a car sharing service, and a request to delete the share key is received, it is determined that the specified condition is not applied to the deletion of the share key. The management server according to claim 1 .

9. The plurality of digital keys include an owner key, only one of which can be registered to the vehicle, and a share key, multiple of which can be registered to the vehicle; When determining whether or not to apply the specified condition, if the type of the vehicle is not a shared vehicle used for a car sharing service, and a request to delete the share key is received, it is determined that the specified condition is not applied to the deletion of the share key. The management server according to claim 1 .

10. When a request to delete the digital key is received, it is determined whether the specified condition is applied. The management server according to claim 1 .

11. determining whether the specified condition applies when registering the digital key; When a request to delete the digital key is received, the digital key is controlled to be in an unusable state. The management server according to claim 1 .

12. A management method performed by a management server that manages digital keys for vehicles, comprising: The management server determining whether to apply a prescribed condition to the deletion of the digital key when a request to delete the digital key is received based on the vehicle type; and controlling the digital key to be in an unusable state according to the result of the determination. Management method.

13. A program to be executed by a management server, which is a computer that manages digital keys for vehicles, The management server, determining whether to apply a prescribed condition to the deletion of the digital key when a request to delete the digital key is received based on the vehicle type; and a program for executing the control to render the digital key unusable depending on the result of the determination.

Images