Management server, management method, and program

Abstract

The management server determines whether or not to apply the stipulated condition in order to control the target digital key to an unusable state, in accordance with the difference in how the vehicle is used based on the user attributes of the participating devices.SOLUTION: The management server manages a plurality of digital keys for the vehicle. The plurality of digital keys include a target digital key and a digital key involved in registration of the target digital key. The management server determines whether or not to apply the stipulated condition RC to the deletion of the target digital key on the basis of the user attribute UA of the participating device in which a predetermined one of the digital keys that participated in the registration of the target digital key is registered. The management server controls the target 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] A management server such as that described in Patent Document 1 may manage multiple digital keys for the same vehicle. In managing the target digital key, the management server may manage the target digital key in an unusable state if predetermined conditions are met in order to prevent the target digital key from being deleted. However, depending on how the vehicle is used, it may be desirable to manage the target digital key in an unusable state in order to prevent the target digital key from being deleted, regardless of the conditions. [Means for solving the problem]

[0005] The management server for solving the above problem is a management server that manages multiple digital keys for a vehicle, where the multiple digital keys include a target digital key and digital keys involved in the registration of the target digital key, and determines whether or not to apply specified conditions to the deletion of the target digital key based on the user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered, and controls the target digital key to an unusable state depending on the result of the determination.

[0006] A management method for solving the above problem is a management method performed by a management server that manages multiple digital keys for a vehicle, wherein the multiple digital keys include a target digital key and digital keys involved in the registration of the target digital key, and the management server determines whether to apply specified conditions to the deletion of the target digital key based on the user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered, and controls the target digital key to an unusable state depending on the result of the determination.

[0007] The program for solving the above problem is a program to be executed by a management server, which is a computer that manages multiple digital keys for a vehicle, where the multiple digital keys include a target digital key and digital keys involved in the registration of the target digital key, and causes the management server to determine whether or not specified conditions apply to the deletion of the target digital key based on the user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered, and to control the target digital key to an unusable state depending on the result of the determination. [Effects of the Invention]

[0008] Each of the above configurations can adapt whether or not to apply specified conditions to disable the target digital key depending on differences in how the vehicle is used based on the user attributes of the participating devices. [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 showing user attributes of data 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). The digital key-related matters of this embodiment are assumed to comply with the CCC, but are also applicable to standards and systems other than the CCC. The management system 10 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 a plurality of digital keys, which include the target digital key and digital keys involved in the registration of the target digital key, as will be described later.

[0037] 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 a digital key in the database DB and deletes a digital key from the database DB. Therefore, when the execution device 71 executes the server program PS, the management server 70 performs the management method.

[0038] In the database DB, for each of a plurality of digital keys, the corresponding vehicle 20 is associated with the 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 user attributes UA for each device 30.

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

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

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

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

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

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

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

[0046] 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. Therefore, the first key is involved in the registration of the second key. On the other hand, the third to seventh keys are not involved in the registration of the second key.

[0047] 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. That is, the fifth key is registered based on the first key. Therefore, the first key is involved in the registration of the fifth key. On the other hand, the second to fourth keys, the sixth key, and the seventh key are not involved in the registration of the fifth key.

[0048] In the data DA, the relationship between the third device 30C and the second device 30B is such that a 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. Therefore, the first key and the second key are involved in the registration of the third key. On the other hand, the fourth key to the seventh key are not involved in the registration of the third key.

[0049] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that a non-friend key KN is registered in the fourth device 30D based on a registration request from the second device 30B. That is, the fourth key is registered based on the second key. Therefore, the first key and the second key are involved in the registration of the fourth key. On the other hand, the third key and the fifth to seventh keys are not involved in the registration of the fourth key.

[0050] 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. That is, the sixth key is registered based on the fifth key. Therefore, the first key and the fifth key are involved in the registration of the sixth key. On the other hand, the second to fourth keys and the seventh key are not involved in the registration of the sixth key.

[0051] In the data DA, the relationship between the seventh device 30G and the fifth device 30E is such that a non-friend key KN is registered in the seventh device 30G due to a registration request from the fifth device 30E. That is, the seventh key is registered based on the fifth key. Therefore, the first key and the fifth key are involved in the registration of the seventh key. On the other hand, the second to fourth keys and the sixth key are not involved in the registration of the seventh key.

[0052] 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. Furthermore, the data DA also includes information indicating which digital key is involved in the registration of each digital key.

[0053] In this way, the multiple digital keys include the target digital key and digital keys involved in the registration of the target digital key. The digital keys involved in the registration of the target digital key include, among the multiple digital keys, digital keys that are directly involved in the registration of the target digital key and digital keys that are indirectly involved in the registration of the target digital key. The directly involved digital key is the digital key that is the basis for the registration of the target digital key. The indirectly involved digital keys include digital keys that are the basis for further registration of the digital key that is the basis for the registration of the target digital key. In this embodiment, the device in which the directly involved digital key, of the digital keys involved in the registration of the target, is registered is predetermined as the involved device.

[0054] As shown in Fig. 5, the data DA of one vehicle 20 includes information indicating the user attributes UA for each registered device 30. Specifically, the data DA includes information indicating whether the user attributes UA, which are the attributes of the users of each of the first device 30A to the seventh device 30F, are a specific business corporation that operates a specific business. The specific business is a rental car service or a car sharing service. In other words, in this embodiment, the information indicating the user attributes is information indicating whether the user is a specific business operator and whether the user is a corporation.

[0055] In the example shown in FIG. 5, the user attribute UA of the first device 30A is not a specific business operator and is not a corporation. The user attribute UA of the second device 30B is a specific business operator and is a corporation. The user attribute UA of the third device 30C is not a specific business operator and is not a corporation. The user attribute UA of the fourth device 30D is not a specific business operator and is not a corporation. The user attribute UA of the fifth device 30E is not a specific business operator and is not a corporation. The user attribute UA of the sixth device 30F is not a specific business operator and is not a corporation. The user attribute UA of the seventh device 30G is not a specific business operator and is not a corporation.

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

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

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

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

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

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

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

[0063] In step S13, the vehicle 20 generates a vehicle public key PKV, which is the public key of the vehicle 20, and a vehicle private key SKV, which is the private key of the vehicle 20. Then, the vehicle 20 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.

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

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

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

[0067] Thereafter, when the first device 30A receives the completion notification M11, the first device 30A performs the process of step S18. In step S18, the first device 30A generates a key track request D12 for the owner key KO. The key track request D12 is a signal requesting the management server 70 to update the database DB. Then, the first device 30A transmits the key track request D12 for the owner key KO and information indicating the user attribute UA of the first device 30A to the management server 70 via the device server 60. In the example shown in FIG. 6, the user attribute UA of the first device 30A is not a specific business corporation.

[0068] 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 a 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 data DA of the vehicle 20 in the database DB that the user attribute UA of the first device 30A is not a specific business corporation. This causes the management system 10 to end the series of processes for the owner key KO.

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

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

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

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

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

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

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

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

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

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

[0079] In step S28, the second device 30B generates a key track request D23 for the friend key KF. Then, the second device 30B transmits the friend key information DKF, the key track request D23 for the friend key KF, and information indicating the user attribute UA of the second device 30B to the management server 70. In the example shown in Fig. 7, the user attribute UA of the second device 30B is not a specific business corporation.

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

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

[0082] On the other hand, if the friend key KF that received the key track request D23 is not on the rejection list, the management server 70 registers the friend key KF that received the key track request D23 in the database DB. 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. In addition, the management server 70 stores, in the data DA of the vehicle 20 in the database DB, that the user attribute UA of the second device 30B is not a specific business corporation.

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

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

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

[0086] <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 designated as a third device 30C.

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

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

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

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

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

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

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

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

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

[0096] In step S48, the third device 30C generates a key track request D33 for the non-friend key KN. Then, the third device 30C transmits the non-friend key information DKN, the key track request D33 for the non-friend key KN, and information indicating the user attribute UA of the third device 30C to the management server 70. In the example shown in Fig. 8, the user attribute UA of the third device 30C is not a specific business corporation.

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

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

[0099] 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 target 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. Furthermore, the management server 70 stores in the data DA of the vehicle 20 in the database DB that the user attribute UA of the third device 30C is not a specific business corporation.

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

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

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

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

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

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

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

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

[0108] 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. Thereafter, the first device 30A transmits a key track request D12 for the owner key KO and information indicating the user attribute UA of the first device 30A to the management server 70. In the example shown in FIG. 10, the user attribute UA of the first device 30A is a specific business corporation.

[0109] 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 a 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 data DA of the vehicle 20 in the database DB, that the user attribute UA of the first device 30A is a specific business corporation. 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.

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

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

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

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

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

[0115] 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. Thereafter, the second device 30B transmits a key track request D23 for the friend key KF and information indicating the user attribute UA of the second device 30B to the management server 70. In the example shown in FIG. 11, the user attribute UA of the second device 30B is a specific business corporation.

[0116] Thereafter, when the management server 70 receives the key track request D23, the management server 70 performs processing of step S74. In step S74, the management server 70 performs registration management of the friend key KF. Specifically, the management server 70 stores the second device 30B as a device 30 registered as the friend key KF in the data DA of the vehicle 20 in the database DB. The management server 70 also stores 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, in the data DA. Furthermore, the management server 70 stores that the user attribute UA of the second device 30B is a specific business corporation. The management server 70 then transmits the storage request D24 and the authentication package ATP to the vehicle 20.

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

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

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

[0120] <Non-friend key deletion control> Next, we will explain deletion control, which includes 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. In this embodiment, the management server 70 performs deletion control to determine whether or not to apply a specified condition RC to the deletion of the target digital key, and, depending on the result of the determination, control the target digital key to an unusable state.

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

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

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

[0124] The deletion request D41 includes a signal requesting the deletion of the non-friend key KN 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.

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

[0126] 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 second specified device 30Y. The second specified device 30Y is a device 30 that stores shared key information DKS indicating the shared key KS to be deleted. In this embodiment, the shared key KS to be deleted is the target digital key, and the second specified device 30Y is the target device.

[0127] Specifically, the management server 70 identifies the second specified device 30Y by referring to the digital key identification information ST3 included in the deletion request D41 and the data DA of the target vehicle 20 in the database DB. For example, in the example shown in Fig. 4, when the device 30 to which the non-friend key KN indicated by the digital key identification information ST3 is registered is the third device 30C, the management server 70 identifies the second specified device 30Y as the third device 30C. Then, the management server 70 proceeds to step S102.

[0128] 13, in step S102, the management server 70 identifies a first specified device 30X, which is a participating device. The first specified device 30X is the device 30 that sent the request to register the shared key KS to be deleted. In this embodiment, the first specified device 30X is the participating device. The participating device is the device 30 in which a digital key that was directly involved in the registration of the shared key KS to be deleted is registered.

[0129] Specifically, the management server 70 refers to the database DB and identifies the device 30 that sent the request to register the second specified device 30Y as the first specified device 30X. For example, in the example shown in FIG. 4, when the second specified device 30Y is the third device 30C, the management server 70 identifies the first specified device 30X as the second device 30B. More specifically, the data DA of the vehicle 20 stores a relationship in which the third device 30C is registered due to a registration request from the second device 30B. Therefore, by referring to the relationship, the management server 70 identifies the first specified device 30X as the second device 30B.

[0130] The shared key KS to be deleted is the second digital key, and the digital key indicated by the key information DK stored in the device 30 that sent the request to register the shared key KS to be deleted is the first digital key. In this embodiment, the first digital key is a digital key registered in the first specified device 30X. The second digital key is a digital key registered in the second specified device 30Y based on a registration request from the first specified device 30X.

[0131] That is, the device 30 in which the second digital key is registered is the second specified device 30Y, and the device 30 in which the first digital key is registered is the first specified device 30X. After that, the management server 70 advances the process to step S103.

[0132] 13, in step S103, the management server 70 identifies the user attribute UA of the first specified device 30X. In detail, the management server 70 identifies the user attribute UA of the first specified device 30X by referring to the data DA of the target vehicle 20 in the database DB. For example, when the first specified device 30X is the second device 30B, the user attribute UA of the first specified device 30X is a specific business corporation. Thereafter, the management server 70 proceeds to step S104.

[0133] In step S104, the management server 70 determines whether the user attribute UA of the first specified device 30X is a specific business corporation. When the user attribute UA of the first specific device 30X is not a specific business corporation (S104: NO), the management server 70 advances the process to step S105.

[0134] In step S105, the management server 70 determines that the digital key to be deleted should be put into the fade-out state based on the fade-out determination. That is, the management server 70 determines that the specified condition RC should be applied to the deletion of the digital key to be deleted. Then, the management server 70 proceeds to step S106.

[0135] In step S106, 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 S107.

[0136] In step S107, 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 (S107: NO), the management server 70 repeats the processing of step S107. On the other hand, when the management server 70 determines that the prescribed condition RC is satisfied (S107: YES), the management server 70 ends this fade-out determination.

[0137] Meanwhile, when the user attribute UA of the first specific device 30X is a specific business corporation (S104: YES), the management server 70 advances the process to step S108. In step S108, the management server 70 determines that the state of the digital key to be deleted will not be a fade-out state based on the fade-out determination. That is, the management server 70 determines that the specified condition RC will not be applied to the deletion of the digital key to be deleted. Thereafter, the management server 70 ends this fade-out determination. Therefore, the management server 70 ends the fade-out determination regardless of whether the specified condition RC is satisfied.

[0138] 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 the non-friend key information DKN indicating the second digital key to be deleted. The management server 70 then transmits the deletion request D42 to the non-friend device 52, which is the second specified device 30Y. Therefore, when the management server 70 makes a positive determination in the fade-out determination, the management server 70 controls the second digital key to be deleted to be unusable by transmitting the deletion request D42 to the second specified device 30Y when the specified condition RC is satisfied. On the other hand, when the management server 70 makes a negative determination in the fade-out determination, the management server 70 controls the second digital key to be deleted to be unusable by transmitting the deletion request D42 to the second specified device 30Y regardless of the specified condition RC. In other words, the management server 70 controls the second digital key to be deleted to be unusable depending on the result of the fade-out determination.

[0139] Thereafter, when the non-friend device 52, which is the second specified device 30Y, receives the deletion request D42, it performs processing in step S84. In step S84, the non-friend device 52, which is the second specified device 30Y, deletes the non-friend key information DKN in accordance with the deletion request D42. That is, the second specified device 30Y deletes the key information DK indicating the second digital key in accordance with the deletion request D42. Then, the non-friend device 52, which is the second specified device 30Y, 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.

[0140] 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, which is the second specified device 30Y. Thereafter, the management server 70 proceeds to the process of step S86.

[0141] 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, i.e., the second digital key, that is the subject of the deletion request D41. The management server 70 then transmits the deletion request D43 to the vehicle 20.

[0142] 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 second digital key, which is 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, which is the second digital key. 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.

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

[0144] 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 second specified device 30Y in which the second digital key 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.

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

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

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

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

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

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

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

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

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

[0154] <Operation of the embodiment> In the above embodiment, if the user attribute UA of the first specific device 30X is not a specific business corporation, there is a high probability that the vehicle 20 is being used by the user of the first specific device 30X. On the other hand, if the user attribute UA of the first specific device 30X is a specific business corporation, there is a high probability that the vehicle 20 is not being used directly by the user of the first specific device 30X, but rather that the user of the first specific device 30X is lending the vehicle 20 to another user for use.

[0155] <Effects of the embodiment> (1) The management server 70 determines whether to apply the specified conditions RC to the deletion of the digital key to be deleted based on the user attributes UA of the participating devices in which the digital keys involved in the registration of the digital key to be deleted are registered. Then, depending on the result of the determination, the management server 70 controls the digital key to be deleted so that it cannot be used. Therefore, the management server 70 can determine whether to apply the specified conditions RC to make the digital key to be deleted unusable based on differences in how the vehicle 20 is used, based on the user attributes UA of the participating devices.

[0156] (2) The digital key to be deleted is the second digital key. The digital key involved in the registration of the second digital key to be deleted is the first digital key. Therefore, the management server 70 determines whether to fade out the second digital key based on the user attribute UA of the first specified device 30X. That is, the management server 70 determines whether to apply the specified condition RC to disable the digital key to be deleted, based on the user attribute UA of the device 30 in which the digital key directly involved in the registration of the digital key to be deleted is registered. Therefore, the determination can be made based on the user attribute UA of the device that is expected to have the greatest degree of involvement among the multiple digital keys involved in the registration of the digital key to be deleted.

[0157] (3) In the deletion control, the management server 70 controls the second specified device 30Y to make the second digital key unusable by deleting the key information DK indicating the second digital key stored in the second specified device 30Y. Therefore, by controlling the second specified device 30Y, the management server 70 can manage the second specified device 30Y to make the second digital key unusable.

[0158] (4) In the deletion control, the management server 70 causes the second specified device 30Y to delete the key information DK indicating the second digital key by sending a deletion request D42 for the key information DK indicating the second digital key to the second specified device 30Y. Therefore, the management server 70 can cause the second specified device 30Y to delete the key information DK indicating the second digital key when the second specified device 30Y receives the deletion request D42.

[0159] (5) In the deletion control, the management server 70 controls the second digital key to be unusable by deleting the authentication information AT of the second digital key stored in the vehicle management device 26. Therefore, the management server 70 can manage the second digital key to be unusable by controlling the vehicle management device 26.

[0160] (6) In deletion control, the management server 70 causes the vehicle management device 26 to delete the authentication information AT of the second digital key by sending a deletion request D43 for the authentication information AT of the second digital key to the vehicle 20. When the authentication information AT is deleted from the vehicle management device 26, even if an attempt is made to use the second digital key, the second digital key will not be authenticated, and the second digital key will become unusable. Therefore, by sending the deletion request D43 to the vehicle 20, the management server 70 can manage the second digital key so that it cannot be used.

[0161] (7) When the user attribute UA of the first specified device 30X is a specific business corporation, the first digital key is likely not used to enter or drive the vehicle 20. In this case, the second digital key registered based on a registration request from the first specified device 30X is likely to be a shared key KS that is permitted to use the vehicle 20 through personal loan from the user of the first specified device 30X. In this case, the user of the second specified device 30Y changes every predetermined period, as in rental car services and car sharing services, and the device 30 that becomes the second specified device 30Y also changes every period. If the second digital key is made unusable when the specified condition RC is met, the second digital key will continue to be used by the device 30 that was the second specified device 30Y, which could prevent the next user from promptly using the vehicle 20.

[0162] In this regard, when the user attribute UA of the first specified device 30X is a specific business corporation, 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 S108. In this case, after receiving the deletion request D41 for the second digital key, the management server 70 makes the second digital key 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 device 30 that was the second specified device 30Y. As a result, the management server 70 can prevent a user other than the user of the second specified device 30Y from being unable to use the vehicle 20.

[0163] (8) When the user attribute UA of the first specified device 30X is not a specific business corporation, the first digital key is unlikely to be used to enter or drive the vehicle 20. In this case, the second digital key registered based on a registration request from the first specified device 30X is likely to be a shared key KS that is permitted to use the vehicle 20 through personal loan from the user of the first specified device 30X. In this case, the user of the second specified device 30Y may enter or drive the vehicle 20 without a predetermined period, such as in a rental car service or car sharing service. If the second digital key were rendered unusable regardless of the specified condition RC, the device 30 that was the second specified device 30Y may suddenly be unable to use the vehicle 20.

[0164] In this regard, when the user attribute UA of the first specified device 30X is not a specific business corporation, the management server 70 makes a negative determination in step S104 and determines to put the device into a fade-out state in the processing of step S105. In this case, the management server 70 puts the second digital key into an unusable state when the specified condition RC is satisfied after receiving the deletion request D41 for the second digital key. Therefore, the management server 70 can prevent the second specified device 30Y from suddenly becoming unable to use the vehicle 20.

[0165] (9) The management server 70 performs a fade-out determination when it receives a request D41 to delete the second digital key. Therefore, the management server 70 performs a fade-out determination based on the user attributes UA of the first specified device 30X when a fade-out determination is required. Therefore, the management server 70 can perform a fade-out determination when the result of the determination is required.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0188] The types of digital keys do not have to include non-friend keys KN. In other words, in the management system 10, the shared keys KS may only be friend keys KF. The 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.

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

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

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

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

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

[0194] In the above embodiment, the participating device is the first specified device 30X, which is the device 30 in which a digital key that was directly involved in the registration of the digital key to be deleted is registered. However, this is not limited to this. The participating device may also be the device 30 in which a digital key that was indirectly involved in the registration of the digital key to be deleted is registered. For example, in the example shown in FIG. 4, if the third key is to be deleted, the first device 30A in which the first key is registered may be pre-set as the participating device. In other words, the management server 70 may determine whether to apply the specified condition RC to the deletion of the non-friend key KN based on the user attribute UA of the owner device 40.

[0195] Note that, when there are multiple digital keys involved in the registration of the digital key to be deleted, the user of the device 30 in which the digital key to be deleted is registered may select in advance which digital key to select as the participating device. For example, when the digital key to be deleted is registered, the device 30 in which the digital key to be deleted is registered may display a screen for selecting which device 30 in which the digital key is registered should be set as the participating device, and the user may select it.

[0196] <Timing for determining whether to enter fade-out state> The timing at which the management server 70 performs the fade-out determination is not limited to when the deletion request D41 for the second digital key is received. For example, the management server 70 may perform the fade-out determination when registering the second digital key.

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

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

[0199] In this case, the management server 70 determines whether to put the second digital key into a fade-out state when the second digital key is registered, thereby making a determination in advance before receiving the second digital key deletion request D41. Therefore, the management server 70 can already know the result of the determination when receiving the second digital key deletion request D41.

[0200] <User attributes> In the above embodiment, the user attribute UA indicates whether the user is a specific business corporation. However, the user attribute UA is not limited to this. For example, the user attribute UA may indicate only whether the user is a specific business. In this case, the management server 70 may perform a fade-out determination based on whether the user attribute UA of the first specific device 30X indicates a specific business.

[0201] Furthermore, for example, the user attribute UA may indicate only whether or not the user is a corporation. In this case, the management server 70 may perform a fade-out determination based on whether or not the user attribute of the first specified device 30X is a corporation.

[0202] Furthermore, for example, the user attribute UA may indicate only whether the device type is a device 30 that performs short-range wireless communication. In this case, the management server 70 may perform a fade-out determination based on whether the device type of the first specified device 30X is a device that performs short-range wireless communication.

[0203] At least, the management server 70 needs to perform the fade-out determination based on the user attribute UA of the first specific device 30X. Therefore, the result of the fade-out determination by the management server 70 may be the opposite result to the result in the example of the above embodiment.

[0204] The management server 70 may store the user attribute UA without relying on information indicating the user attribute UA received from the device 30. For example, the management server 70 may determine the user attribute UA 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 same device 30 before performing registration management, the management server 70 may determine that the user attribute UA of the device 30 is a specific business corporation. Furthermore, if the management server 70 has not received a fleet signal FL from the same device 30 before performing registration management, the management server 70 may determine that the user attribute UA of the device 30 is not a specific business corporation.

[0205] In the above embodiment, the management server 70 identifies the user attributes UA by referring to the database DB stored in the storage device 72. However, the management server 70 may identify the user attributes UA without using the database DB. For example, when performing step S103, the management server 70 may communicate with the first specified device 30X to acquire information indicating the user attributes UA of the first specified device 30X from the first specified device 30X. Then, the management server 70 may make a fade-out determination based on the acquired user attributes UA.

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

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

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

[0209] The method by which the management server 70 deletes the authentication information AT of the second digital key 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 second digital key, causing the vehicle management device 26 to continue storing the authentication information AT of the second digital key. In this case, the management server 70 may delete the authentication information AT of the second digital key by not sending the continuation request.

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

[0211] (Additional notes) The technical concepts that can be understood from the above-described embodiments and modifications will be described below. [Appendix 1] A management server that manages multiple digital keys for a vehicle, the multiple digital keys including a target digital key and digital keys involved in the registration of the target digital key, and the management server determines whether or not specified conditions apply to the deletion of the target digital key based on the user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered, and controls the target digital key to an unusable state depending on the result of the determination.

[0212] [Appendix 2] A management server as described in Appendix 1, wherein the plurality of digital keys include a first digital key registered in a first specified device as a digital key for the vehicle, and a second digital key registered in a second specified device as a digital key for the vehicle based on a registration request from the first specified device, and the target digital key is the second digital key, and the digital key involved in the registration of the target digital key is the first digital key.

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

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

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

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

[0217] [Appendix 7] When determining whether or not to apply the specified conditions, the management server described in any one of Appendices 1 to 6 determines that the specified conditions do not apply to the deletion of the target digital key when the user attribute of the involved device is a specific business operator that rents out the vehicle.

[0218] [Appendix 8] When determining whether or not to apply the specified conditions, the management server described in any one of Appendices 1 to 7 determines that the specified conditions should be applied to the deletion of the target digital key when the user attributes of the involved device are not the specific business operator that rents out the vehicle.

[0219] [Appendix 9] A management server described in any one of Appendices 1 to 7, which, when determining whether or not to apply the specified conditions, determines that the specified conditions do not apply to the deletion of the target digital key when the user attribute of the involved device is a corporation.

[0220] [Appendix 10] A management server described in any one of Appendices 1 to 7 and Appendix 9, which, when determining whether or not to apply the specified conditions, determines that the specified conditions should be applied to the deletion of the target digital key when the user attribute of the involved device is not a corporation.

[0221] [Supplementary Note 11] The management server according to any one of Supplementary Note 1 to Supplementary Note 10, which determines whether or not to apply the specified condition when a request to delete the target digital key is received.

[0222] [Appendix 12] A management server according to any one of Appendices 1 to 10, which determines whether or not the specified conditions apply when registering the target digital key, and controls the target digital key to an unusable state when a request to delete the target digital key is received. [Explanation of symbols]

[0223] 10...Management system 20...Vehicle 26...Vehicle management device 27...Execution device 28…Storage device 30…Devices 30M…Mobile device 30N...predetermined server 30X...First specified device 30Y...Second specified device 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 UA: User Attributes

Claims

1. A management server that manages a plurality of digital keys for a vehicle, the plurality of digital keys include a target digital key and digital keys that participated in the registration of the target digital key; determining whether or not to apply a specified condition to the deletion of the target digital key based on user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered; and controlling the target digital key to an unusable state according to the result of the determination. Management server.

2. the plurality of digital keys include a first digital key registered in a first specific device as a digital key for the vehicle, and a second digital key registered in a second specific device as a digital key for the vehicle based on a registration request from the first specific device; the target digital key is the second digital key; The digital key involved in the registration of the target digital key is the first digital key. The management server according to claim 1 .

3. When controlling the target digital key to an unusable state, information about the target digital key stored in the target device to which the target digital key is registered is deleted, thereby controlling the target digital key to an unusable state. The management server according to claim 1 .

4. When the target digital key is controlled to be in an unusable state, a request for deleting information about the target digital key is sent to the target device, thereby deleting information about the target digital key. The management server according to claim 3 .

5. When controlling the target digital key to an unusable state, the target digital key is controlled to an unusable state by deleting information about the target digital key stored in the vehicle management device of the vehicle. The management server according to claim 1 .

6. When the target digital key is controlled to be unusable, a request to delete information about the target digital key is sent to the vehicle, thereby deleting the information about the target digital key. The management server according to claim 5 .

7. When determining whether to apply the specified condition, if the user attribute of the participating device is a specific business that rents out the vehicle, it is determined that the specified condition does not apply to the deletion of the target digital key. The management server according to claim 1 .

8. When determining whether to apply the specified condition, if the user attribute of the participating device is not a specific business operator that rents out the vehicle, it is determined that the specified condition is applied to the deletion of the target digital key. The management server according to claim 1 .

9. When determining whether to apply the specified condition, if the user attribute of the participating device is a corporation, it is determined that the specified condition does not apply to the deletion of the target digital key. The management server according to claim 1 .

10. When determining whether to apply the specified condition, if the user attribute of the participating device is not a corporation, it is determined that the specified condition is applied to the deletion of the target digital key. The management server according to claim 1 .

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

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

13. A management method performed by a management server that manages multiple digital keys for a vehicle, comprising: the plurality of digital keys include a target digital key and digital keys that participated in the registration of the target digital key; The management server determining whether or not to apply a specified condition to the deletion of the target digital key based on user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered; and controlling the target digital key to an unusable state according to the result of the determination. Management method.

14. A program to be executed by a management server, which is a computer that manages multiple digital keys for vehicles, the plurality of digital keys include a target digital key and digital keys that participated in the registration of the target digital key; The management server, determining whether or not to apply a specified condition to the deletion of the target digital key based on user attributes of a participating device to which a predetermined one of the digital keys involved in the registration of the target digital key is registered; and a program for executing the control to render the target digital key unusable depending on the result of the determination.

Images