System, management server, vehicle management device, management method, and program

Abstract

To prevent a third digital key registered by a second device in which a second digital key is registered from being registered without being known by a first device in which a first digital key is registered.SOLUTION: The management system 10 includes an inquiring section 70CD and an executing section 70RA. The inquiring unit (70CD) is configured to inquire of the first apparatus whether to accept registration of a third digital key when the second apparatus newly registers the third digital key based on a request from the first apparatus in which the first digital key is registered. The executor 70RA executes the processing for registering the third digital key when the approval information is received, and does not execute the processing for registering the third digital key when the approval information is not received.SELECTED DRAWING: Figure 10

Description

[Technical Field]

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

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, an owner device, a shared device, and a management server. The owner device registers an owner key. An owner key is a digital key of which only one can exist per vehicle. The shared device registers a shared key based on a registration request from the owner device. A single vehicle can have multiple shared keys.

[0003] The management server manages multiple digital keys. When a vehicle uses a digital key, it authenticates the digital key and allows it to unlock the vehicle and perform other controls. [Prior art documents] [Patent documents]

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

[0005] In a management system such as that described in Patent Document 1, it is conceivable that a new share key can be registered by a share device making a further registration request. In such a case, if a share key is registered without the involvement of the owner device, there is a risk that a new share key may be registered without the knowledge of the user belonging to the owner device.

[0006] Furthermore, it is conceivable that a new share device to which a new share key has been registered may also register a new share key. In such a case, a new digital key may be registered without the user of the owner device or the user of a share device registered based on a registration request from the owner device being directly involved in the registration of the new share key. Therefore, users of devices that are not directly involved in the registration of the new digital key, such as users of these devices, may also want to know that a new digital key will be registered or want to control the registration of the new digital key. [Means for solving the problem]

[0007] In order to solve the above problem, the system is a system for managing multiple digital keys that can be used for a vehicle, and includes: an inquiry unit that, when a second device to which a second digital key is registered registers a third digital key based on a request from a first device to which a first digital key is registered, inquires of the first device whether or not to accept the registration of the third digital key; and an execution unit that executes registration processing for the third digital key if acceptance information indicating acceptance of the registration of the third digital key is received, and does not execute the registration processing if the acceptance information is not received.

[0008] In order to solve the above problem, the management server is a management server that manages multiple digital keys that can be used for vehicles, and is equipped with an inquiry unit that, when a second device to which a second digital key is registered based on a request from a first device to which a first digital key is registered newly registers a third digital key, inquires of the first device whether or not to agree to the registration of the third digital key, and an execution unit that executes the registration process of the third digital key if it receives consent information indicating that it agrees to the registration of the third digital key, and does not execute the registration process if it does not receive the consent information.

[0009] In order to solve the above problem, the vehicle management device is a vehicle management device that manages multiple digital keys that can be used for a vehicle, and is equipped with an inquiry unit that, when a second device to which a second digital key is registered based on a request from a first device to which a first digital key is registered newly registers a third digital key, inquires of the first device whether or not to agree to the registration of the third digital key, and an execution unit that executes the registration process of the third digital key if acceptance information indicating acceptance of the registration of the third digital key is received, and does not execute the registration process if the acceptance information is not received.

[0010] In order to solve the above problem, the management method is a management method performed by a system that manages multiple digital keys that can be used for a vehicle, and when a second device to which a second digital key is registered registers a new third digital key based on a request from a first device to which a first digital key is registered, the system inquires the first device whether or not to agree to the registration of the third digital key, and if consent information indicating consent to the registration of the third digital key is received, the system executes the registration process of the third digital key, and if the consent information is not received, the system does not execute the registration process.

[0011] In order to solve the above problem, the program is executed by a computer that manages multiple digital keys that can be used for a vehicle, and causes the computer to function as: an inquiry unit that, when a second device to which a second digital key is registered newly registers a third digital key based on a request from a first device to which a first digital key is registered, inquires of the first device whether or not to agree to the registration of the third digital key; and an execution unit that executes the registration process of the third digital key if consent information indicating consent to the registration of the third digital key is received, and does not execute the registration process if the consent information is not received. [Effects of the Invention]

[0012] Each of the above configurations can prevent the third digital key, which is registered by the second device to which the second digital key is registered, from being registered without the knowledge of the first device to which the first digital key is registered. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic diagram showing a management system according to the first embodiment. [Figure 2] FIG. 2 is a schematic diagram showing owner key information according to the first embodiment. [Figure 3] FIG. 3 is a schematic diagram showing the share key information of the first embodiment. [Figure 4] FIG. 4 is a schematic diagram showing data in the database of the first embodiment. [Figure 5] FIG. 5 is an explanatory diagram showing a series of processes performed by the management system when registering an owner key according to the first embodiment. [Figure 6] FIG. 6 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in the first embodiment. [Figure 7] FIG. 7 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in the first embodiment. [Figure 8] FIG. 8 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a friend device in the first embodiment. [Figure 9] FIG. 9 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a non-friend device in the first embodiment. [Figure 10] FIG. 10 is a schematic diagram showing an inquiry unit and an execution unit in the management system of the first embodiment. [Figure 11] FIG. 11 is a flowchart showing a series of processes performed by the query unit and the execution unit of the first embodiment. [Figure 12] FIG. 12 is a schematic diagram showing a vehicle according to the second embodiment. [Figure 13] FIG. 13 is a schematic diagram showing an inquiry unit and an execution unit in the management system of the second embodiment. [Figure 14] FIG. 14 is a flowchart showing a series of processes performed by the query unit and the execution unit of the second embodiment. [Figure 15] FIG. 15 is a schematic diagram showing a non-friend device according to the third embodiment. [Figure 16] FIG. 16 is a schematic diagram showing an inquiry unit and an execution unit in the management system of the third embodiment. [Figure 17] FIG. 17 is a flowchart showing a series of processes performed by the inquiry unit and the execution unit of the third embodiment. [Figure 18] FIG. 18 is a schematic diagram showing a friend device according to the fourth embodiment. [Figure 19] FIG. 19 is a schematic diagram showing an inquiry unit and an execution unit in the management system of the fourth embodiment. [Figure 20] FIG. 20 is a flowchart showing a series of processes performed by the inquiry unit and the execution unit of the fourth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] (First embodiment) The management system 10 according to the first embodiment will be described below with reference to the drawings. <Overview of the management system> As shown in FIG. 1, a management system 10 manages a plurality of digital keys that can be used for a vehicle 20. In this embodiment, the management system 10 is a system. There is a standard for digital keys, the Car Connectivity Consortium (CCC). Matters relating to the digital keys in this embodiment comply with the CCC. The management system 10 includes a vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

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

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

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

[0018] The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. The 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 processing related to the storage and deletion of the authentication information AT.

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

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

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

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

[0023] The storage device 37 stores a device program PD and key information DK. The device program PD is executed by the execution device 36, causing the execution device 36 to store and delete the key information DK. The key information DK is information indicating a digital key.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0037] 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 a first type of device 30 communicates is different from the device server 60 with which a 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.

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

[0039] <Administration Server> The management server 70 manages the digital key. The management server 70 is capable of communicating with the vehicle 20 and the multiple devices 30. The management server 70 includes an execution device 71, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 is also capable of wireless communication with the communication module 21 of the vehicle 20.

[0040] The storage device 72 stores a server program PS, a consent program PCA, and a database DB. The server program PS is executed by the execution device 71, causing the execution device 71 to register a digital key in the database DB and delete a digital key from the database DB. Details of the consent program PCA will be described later.

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

[0042] As shown in Figure 4, the data DA for one vehicle 20 includes the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. 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.

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

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

[0045] 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 a first digital key to a seventh digital key.

[0046] 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 digital key is the owner key KO.

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

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

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

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

[0051] In the data DA, the relationship between the third device 30C and the second device 30B is such that the non-friend key KN is registered in the third device 30C based on a registration request from the second device 30B. In other words, the third digital key is registered based on the second digital key.

[0052] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that the non-friend key KN is registered in the fourth device 30D based on a registration request from the second device 30B. In other words, the fourth digital key is registered based on the second digital key.

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

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

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

[0056] <Digital key registration> Next, a series of registration processes for registering digital keys in the management system 10 will be described. The management system 10 registers the owner key KO, the friend key KF, and the non-friend key KN as digital key registrations. The following describes the series of processes from when each digital key is not registered to when it is registered. 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.

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

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

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

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

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

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

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

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

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

[0066] Thereafter, when the first device 30A receives the completion notification M11, the first device 30A performs the process of step S18. In step S18, the first device 30A generates a key track request D12 for the owner key KO. The key track request D12 is a signal requesting the management server 70 to update the database DB. Then, the first device 30A transmits the key track request D12 for the owner key KO to the management server 70 via the device server 60.

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

[0068] <Friend Key Registration> 6, the management system 10 performs a series of registration 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0090] 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 signature information ATP1. Specifically, the third device 30C generates each piece of information included in the acquired share information SH2 as the unsigned non-friend key information DKNN. The third device 30C then transmits 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.

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

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

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

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

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

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

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

[0098] On the other hand, if the non-friend key KN is not on the rejection list, the management server 70 registers the non-friend key KN that is the subject of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the data DA of the vehicle 20 in the database DB as a device 30 registered as a non-friend device 52. The management server 70 stores the relationship between the third device 30C and the friend device 51 by referring to the acquired non-friend key information DKN. Specifically, the management server 70 stores the third device 30C as a device 30 having the non-friend key KN registered in response to the registration request D31 from the second device 30B.

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

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

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

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

[0103] <Deleting a non-friend key in response to a deletion request from a friend device> As shown in FIG. 8, the management system 10 performs a series of processes to delete the non-friend key KN based on a reservation deletion request D41 from the friend device 51.

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

[0105] The reservation deletion request D41 includes a signal requesting deletion of the non-friend key KN, digital key identification information ST3 indicating the non-friend key KN, and information indicating the specified condition RC. The specified condition RC is a condition required to start deletion after receiving the reservation deletion request D41. The specified condition RC is predetermined. For example, the specified condition RC is that a predetermined fade-out period has elapsed since receiving the reservation deletion request D41. Then, the friend device 51 transmits the reservation deletion request D41 for the non-friend key KN to the management server 70.

[0106] Thereafter, upon receiving the reservation deletion request D41 for the non-friend key KN, the management server 70 performs processing in step S62. In step S62, the management server 70 generates a deletion in progress notification M41 indicating that the reservation is being deleted in accordance with the reservation deletion request D41. Then, the management server 70 transmits the deletion in progress notification M41 to the friend device 51.

[0107] Thereafter, when the friend device 51 receives the deletion in progress notification M41, the friend device 51 performs the process of step S63. In step S63, the friend device 51 presents to the HMI 32 information indicating that the non-friend key KN that is the target of the reservation deletion request D41 is being deleted.

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

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

[0110] In step S66, the management server 70 generates a deletion request D42 for deleting the non-friend key information DKN indicating the non-friend key KN that is the target of the reservation deletion request D41. Then, the management server 70 transmits the deletion request D42 to the non-friend device 52.

[0111] Thereafter, when the non-friend device 52 receives the deletion request D42, it performs processing in step S67. In step S67, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion request D42. Then, the non-friend device 52 transmits a deletion completion notification M42 to the management server 70, indicating that the deletion in accordance with the deletion request D42 has been completed.

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

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

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

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

[0116] In step S72, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN to be deleted in this series of processes from the data DA of the vehicle 20 in the database DB. Thereafter, the management server 70 transmits 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 reservation deletion request D41 has been completed.

[0117] Thereafter, when the friend device 51 receives the completion notification M44, the friend device 51 performs the process of step S73. In step S73, the friend device 51 presents, to the HMI 32, information indicating that the deletion of the non-friend key KN that is the subject of the reservation 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.

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

[0119] 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 S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN in accordance with the predetermined operation. Thereafter, the non-friend device 52 transmits a deletion completion notification M51 to the management server 70 indicating that the non-friend key information DKN has been deleted.

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

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

[0122] After processing step S82, the management server 70 performs processing step S84. In step S84, 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.

[0123] Thereafter, when the vehicle 20 receives the deletion request D51, the vehicle 20 performs the processing of step S85. In step S85, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN that was deleted in step S81 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.

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

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

[0126] Next, a series of processes in the management system 10 regarding whether to execute inquiry and registration processes for notifying the owner device 40 that a request for registration of a non-friend key KN has been made will be described.

[0127] 1, in the management server 70, the storage device 72 stores the consent program PCA. The consent program PCA is a program that, when executed by the execution device 71, causes the execution device 71, which is a computer, to function as a query unit 70CD and an execution unit 70RA.

[0128] As shown in Fig. 10, when the execution device 71 executes the consent program PCA, the execution device 71 functions as an inquiry unit 70CD and an execution unit 70RA. Therefore, in the first embodiment, the management server 70 has the inquiry unit 70CD and the execution unit 70RA. Also, the communication module 73 of the management server 70 functions as a receiving unit 70RE that receives the key track request D33. Therefore, the management server 70 has the receiving unit 70RE. Note that the management server 70 is an external server.

[0129] When the second device 30B newly registers a third digital key, the inquiry unit 70CD inquires of the first device 30A whether or not to approve the registration of the third digital key. The first device 30A is the device 30 in which the first digital key is registered. The second device 30B is the device 30 in which the second digital key is registered based on a request from the first device 30A.

[0130] Specifically, when the inquiry unit 70CD detects that there has been a request to register the non-friend key KN, it transmits to the owner device 40 a consent request CD requesting consent to the registration of the non-friend key KN.

[0131] When the execution unit 70RA receives consent information CI indicating consent to the registration of the third digital key, the execution unit 70RA executes the registration process of the third digital key. On the other hand, when the execution unit 70RA does not receive consent information CI, the execution unit 70RA does not execute the registration process of the third digital key.

[0132] Specifically, if the execution unit 70RA does not receive consent information CI indicating consent from the owner device 40, the execution unit 70RA does not cause the management system 10 to execute the registration process for the non-friend key KN. If the execution unit 70RA receives consent information CI from the owner device 40, the execution unit 70RA causes the management system 10 to execute the registration process for the non-friend key KN.

[0133] The storage device 28 of the vehicle 20 functions as a storage unit 20M that stores the authentication information AT. Therefore, the vehicle 20 has the storage unit 20M as an authentication information storage unit. The storage device 72 of the management server 70 functions as a storage unit 70M that stores the database DB. Therefore, the management server 70 has the storage unit 70M as a database storage unit.

[0134] Specifically, the execution device 71 starts execution of the consent program PCA when it detects that registration of a non-friend key KN has been requested in the management system 10. When the execution device 71 receives the key track request D33, it detects that registration of a non-friend key KN has been requested in the management system 10. That is, the inquiry unit 70CD detects that there has been a request to register a non-friend key KN, which is a third digital key, when the receiving unit 70RE of the management server 70 receives the key track request D33 from the friend device 51, which is the second device 30B.

[0135] 11, when the execution device 71 starts executing the consent program PCA, it first performs the processing of step S101. In step S101, the execution device 71 identifies the owner device 40, which is the first device 30A to be the destination. Specifically, the execution device 71 first references the database DB to identify the vehicle 20 that is the target of the non-friend key KN of the key track request D33. Next, the execution device 71 references the data DA of the identified vehicle 20 to identify the device 30 that stores owner key information DKO indicating the owner key KO for the vehicle 20 as the owner device 40. After that, the execution device 71 proceeds to the processing of step S102.

[0136] In step S102, the executing device 71 transmits an acceptance request CD to the owner device 40. The acceptance request CD requests the destination owner device 40 to accept the request for registration of the non-friend key KN from the owner device 40. The owner device 40, upon receiving the acceptance request CD, displays the acceptance request CD on the HMI 32. When the owner device 40 accepts the acceptance request CD, the owner device 40 transmits acceptance information CI indicating acceptance to the management server 70. On the other hand, if the owner device 40 does not accept the acceptance request CD within a predetermined specified period PP, or if the owner device 40 accepts an operation not to accept, the owner device 40 transmits information indicating not to accept to the management server 70. The specified period PP is, for example, one day. After that, the executing device 71 proceeds to step S103.

[0137] In step S103, the executing device 71 determines whether or not it has received consent information CI from the owner device 40 within the specified period PP. Specifically, when the executing device 71 receives consent information CI from the owner device 40 within the specified period PP after starting the processing of step S104, the executing device 71 determines that it has received consent information CI. On the other hand, when the executing device 71 does not receive consent information CI within the specified period PP after starting the processing of step S104, or when it receives information indicating that it does not give consent, the executing device 71 determines that it has not received consent information CI.

[0138] When the executing device 71 receives the consent information CI from the owner device 40 within the specified period PP (S103: YES), the executing device 71 proceeds to step S104. In step S104, the executing device 71 determines to have the management system 10 execute the registration process of the non-friend key KN. Thereafter, the executing device 71 proceeds to step S105.

[0139] In step S105, the execution device 71 allows the non-friend key KN to be stored in the database DB. Specifically, in accordance with the key track request D33 for the non-friend key KN, the execution device 71 allows the specific device 30X to be stored as a non-friend device 52 for the non-friend key KN. As a result, the execution unit 70RA causes the management server 70 to allow the non-friend key KN to be registered in the database DB. Note that, once the execution device 71 allows the non-friend key KN to be stored in the database DB, the execution device 71 stores the specific device 30X as a non-friend device 52 through registration management of the non-friend key KN. That is, the execution unit 70RA stores the third digital key and the third device 30C in association with each other in the database DB during the registration process. After that, the execution device 71 proceeds to step S106.

[0140] In step S106, the execution device 71 allows the transmission of the authentication package ATP and storage request D34 for the non-friend key KN. As a result, the execution unit 70RA allows the management server 70 to send the authentication package ATP and storage request D34 for the non-friend key KN to the vehicle 20. When the execution device 71 allows the transmission of the authentication package ATP and storage request D34 for the non-friend key KN to the vehicle 20, the execution device 71 sends the authentication package ATP and storage request D34 for the non-friend key KN to the vehicle 20. When the vehicle 20 receives the authentication package ATP and storage request D34 for the non-friend key KN, the vehicle management device 26 stores the authentication package ATP for the non-friend key KN as authentication information AT. Thereafter, the execution device 71 terminates this series of processes.

[0141] On the other hand, if the executing device 71 does not receive consent information CI from the owner device 40 within the specified period PP (S103: NO), the executing device 71 proceeds to step S107.

[0142] In step S107, the execution device 71 determines not to allow the management system 10 to register the non-friend key KN. After that, the execution device 71 advances the process to step S108.

[0143] In step S108, the execution device 71 denies storage of the non-friend key KN in the database DB. That is, the execution device 71 does not allow storage of the non-friend key KN in the database DB. Specifically, even if a key track request D33 for the non-friend key KN is made, the execution device 71 does not allow storage of the specific device 30X as a non-friend device 52 for the non-friend key KN. As a result, the execution unit 70RA does not allow the management server 70 to register the non-friend key KN in the database DB. Note that if the execution device 71 does not allow storage of the non-friend key KN in the database DB, the execution device 71 will not store the specific device 30X as a non-friend device 52 through registration management of the non-friend key KN. Thereafter, the execution device 71 proceeds to step S109.

[0144] In step S109, the execution device 71 does not allow the transmission of the authentication package ATP and storage request D34 of the non-friend key KN. As a result, the execution unit 70RA does not allow the management server 70 to send the authentication package ATP and storage request D34 of the non-friend key KN to the vehicle 20. Note that if the execution device 71 does not allow the transmission of the authentication package ATP and storage request D34 of the non-friend key KN to the vehicle 20, the execution device 71 will not send the authentication package ATP and storage request D34 of the non-friend key KN to the vehicle 20. Therefore, the vehicle management device 26 will not store the authentication package ATP of the non-friend key KN as authentication information AT. Thereafter, the execution device 71 terminates this series of processes.

[0145] The management system 10 includes an inquiry unit 70CD and an execution unit 70RA, and thus performs a management method. In the management method, when the second device 30B newly registers a third digital key, the management system 10 inquires of the first device 30A as to whether or not to consent to the registration of the third digital key. In the management method, the management system 10 performs registration processing of the third digital key when consent information CI is received, and does not perform registration processing when consent information CI is not received.

[0146] <Operation of the First Embodiment> In the first embodiment, it is assumed that the management system 10 does not have the inquiry unit 70CD and the execution unit 70RA. In this case, in the series of processes for registering the non-friend key KN shown in Fig. 7, the owner device 40 cannot recognize that there has been a request to register the non-friend key KN. Therefore, there is a risk that a non-friend key KN that is contrary to the will of the owner of the owner device 40 will be registered.

[0147] In this regard, according to the first embodiment, the inquiry unit 70CD transmits an acceptance request CD to the owner device 40. When the execution unit 70RA receives acceptance information CI from the owner device 40, it allows the registration of the non-friend key KN. Therefore, the owner device 40 is involved in the series of processes when the non-friend key KN is registered.

[0148] <Effects of the first embodiment> (1-1) When the inquiry unit 70CD detects that there has been a request to register the third digital key, it sends an acceptance request CD to the first device 30A to inquire whether to accept the registration of the third digital key. If the execution unit 70RA subsequently does not receive acceptance information CI from the first device 30A, it does not allow the management system 10 to register the non-friend key KN, thereby not executing the registration process for the third digital key. On the other hand, when the execution unit 70RA receives acceptance information CI from the owner device 40, it allows the management system 10 to register the non-friend key KN, thereby executing the registration process for the third digital key. Therefore, by involving the owner device 40 in the series of processes for registering the non-friend key KN, the management system 10 can prevent the non-friend key KN from being registered against the will of the owner of the owner device 40.

[0149] (1-2) When the execution unit 70RA allows the management server 70 to register the non-friend key KN, which is the third digital key, the execution unit 70RA sends a storage request D34 to the vehicle 20. As a result, the vehicle 20 stores the authentication information AT of the non-friend key KN. Therefore, when the third device 30C stores the non-friend key information DKN and the vehicle 20 stores the authentication information AT, the management system 10 can enable the use of the non-friend key KN.

[0150] (1-3) When the execution unit 70RA does not allow the management server 70 to register the non-friend key KN, which is the third digital key, the execution unit 70RA does not send a storage request D34 to the vehicle 20. As a result, the vehicle 20 does not store the authentication information AT of the non-friend key KN, which is the third digital key. Therefore, although the third device 30C stores the non-friend key information DKN, the vehicle 20 does not store the authentication information AT, and the management system 10 does not enable the use of the non-friend key KN, which is the third digital key.

[0151] (1-4) When the execution unit 70RA allows the management server 70 to register the non-friend key KN, the execution unit 70RA stores in the database DB the non-friend key KN, which is the third digital key, in association with the third device 30C in which the third digital key is registered. Therefore, the management server 70 can update the database DB to store information about the non-friend device 52, which is the third device 30C in which the third digital key is registered.

[0152] (1-5) When the execution unit 70RA does not allow the management server 70 to register the non-friend key KN, the execution unit 70RA does not store, in the database DB, information indicating the shared device 50 that indicates the non-friend key KN that was not allowed to be registered. Therefore, the management server 70 can set the database DB to a state in which the non-friend device 52 is not stored.

[0153] (1-6) The management server 70 has an inquiry unit 70CD and an execution unit 70RA. Therefore, the inquiry unit 70CD and the execution unit 70RA can easily use information acquired by the management server 70. Furthermore, the inquiry unit 70CD and the execution unit 70RA can easily control the processing performed by the management server 70.

[0154] (1-7) When the inquiry unit 70CD receives the key track request D33, it detects that there has been a request to register the non-friend key KN. Therefore, in the series of processes shown in Figure 7, the inquiry unit 70CD can detect that there has been a request to register the non-friend key KN when the non-friend device 52 has stored the non-friend key information DKN but before the vehicle 20 has stored the authentication information AT.

[0155] (Second embodiment) The management system 10 according to the second embodiment will be described below with reference to the drawings. The second embodiment differs from the first embodiment in that the vehicle management device 26 of the vehicle 20 has a query unit 20CD and an execution unit 20RA. The following description will focus on the differences from the first embodiment, and the description of the same points will be simplified or omitted.

[0156] 12, the storage device 28 stores an approval program PCA2 in the second embodiment. The approval program PCA2 is a program that causes the vehicle management device 26, which is a computer, in the vehicle 20 to function as an inquiry unit 20CD and an execution unit 20RA.

[0157] 13, the execution device 27 executes the consent program PCA2, whereby the execution device 27 functions as an inquiry unit 20CD and an execution unit 20RA. Therefore, in the second embodiment, the vehicle 20 has the inquiry unit 20CD and the execution unit 20RA. Also, the communication module 21 of the vehicle 20 functions as a receiving unit 20RE that receives the storage request D34. Therefore, the vehicle 20 has the receiving unit 20RE.

[0158] The execution device 27 starts execution of the consent program PCA2 when it detects that registration of the non-friend key KN has been requested in the management system 10. When the execution device 27 receives the authentication package ATP and storage request D34 for the non-friend key KN, it detects that registration of the non-friend key KN has been requested in the management system 10. In other words, when the receiving unit 20RE receives the authentication package ATP and storage request D34 for the non-friend key KN, the inquiry unit 20CD detects that a request for registration of the non-friend key KN has been made.

[0159] 14, when the execution device 27 starts executing the consent program PCA2, the execution device 27 performs the processing of step S111. In step S111, the execution device 27 identifies the owner device 40 to which the consent request CD is to be sent. In the second embodiment, information for identifying the owner device 40 is added to the authentication package ATP. The execution device 27 identifies the owner device 40 identified by the information for identifying the owner device 40 as the owner device 40 to which the consent request CD is to be sent. After that, the execution device 27 proceeds to the processing of step S112.

[0160] In step S112, the executing device 27 transmits a consent request CD to the owner device 40. For example, the executing device 27 communicates with the owner device 40 via the management server 70 and the device server 60 using the communication module 21. That is, when the receiving unit 20RE receives the storage request D34, the inquiry unit 20CD inquires of the first device 30A whether or not to consent to the registration of the third digital key. Thereafter, the executing device 27 proceeds to step S113.

[0161] In step S113, the execution apparatus 27 determines whether or not consent information CI has been received within the specified period PP from the owner device 40. Step S113 is the same as step S103 in the first embodiment, and therefore a detailed description thereof will be omitted.

[0162] When the executing device 27 receives the consent information CI from the owner device 40 within the specified period PP (S113: YES), the executing device 27 proceeds to step S114. In step S114, the executing device 27 determines to allow the management system 10 to register the non-friend key KN. Thereafter, the executing device 27 proceeds to step S115.

[0163] In step S115, the execution device 27 allows the authentication information AT of the non-friend key KN to be stored. That is, the execution unit 20RA allows the vehicle 20 to register the non-friend key KN. Specifically, the execution unit 20RA allows the vehicle 20 to store the authentication information AT of the non-friend key KN. As a result, the execution device 27 stores the authentication information AT of the non-friend key KN in accordance with the storage request D34. Thereafter, the execution device 27 ends this series of processes.

[0164] On the other hand, if the execution device 27 does not receive consent information CI from the owner device 40 within the specified period PP (S113: NO), the execution device 27 proceeds to step S116. In step S116, the execution device 27 determines not to allow the management system 10 to register the non-friend key KN. Thereafter, the execution device 27 proceeds to step S117.

[0165] In step S117, the execution device 27 refuses to store the authentication information AT of the non-friend key KN. That is, the execution unit 20RA does not allow the vehicle 20 to register the non-friend key KN. Specifically, the execution unit 20RA does not allow the vehicle 20 to store the authentication information AT of the non-friend key KN. As a result, even if the execution device 27 receives the storage request D34, it does not store the authentication information AT of the non-friend key KN. Thereafter, the execution device 27 ends this series of processes.

[0166] <Operation of the Second Embodiment> In the second embodiment, when the execution unit 20RA receives consent information CI from the owner device 40, it allows the vehicle 20 to store the authentication information AT. In this case, when the vehicle 20 stores the authentication information AT, the non-friend key KN becomes usable. On the other hand, when the execution unit 20RA does not receive consent information CI from the owner device 40, it does not allow the vehicle 20 to store the authentication information AT. In this case, when the vehicle 20 does not store the authentication information AT, the non-friend key KN does not become usable.

[0167] <Effects of the second embodiment> According to the second embodiment, in addition to the effect (1-1) of the first embodiment, the following effect can be achieved.

[0168] (2-1) In the second embodiment, the vehicle 20 has an inquiry unit 20CD and an execution unit 20RA. Therefore, the inquiry unit 20CD and the execution unit 20RA can use information acquired by the vehicle 20. In addition, the execution unit 20RA can easily control the processing performed by the vehicle 20.

[0169] (2-2) When the inquiry unit 20CD receives the storage request D34, it detects that there has been a request to register the non-friend key KN. Therefore, the inquiry unit 20CD can detect that there has been a request to register the non-friend key KN when the vehicle 20 stores the authentication information AT in the series of processes shown in Figure 7.

[0170] (2-3) When the execution unit 20RA allows the vehicle 20 to register the non-friend key KN, which is the third digital key, the execution device 27 stores the authentication information AT of the non-friend key KN, which is the third digital key. Therefore, the vehicle 20 can be made to be able to use the third digital key.

[0171] (2-4) When the execution unit 20RA does not allow the vehicle 20 to register the non-friend key KN, which is the third digital key, the execution device 27 does not store the authentication information AT of the non-friend key KN, which is the third digital key. Therefore, the vehicle 20 can remain in a state where the third digital key cannot be used.

[0172] (Third embodiment) The management system 10 according to the third embodiment will be described below with reference to the drawings. The third embodiment differs from the first embodiment in that the non-friend device 52 has a query unit 30CD and an execution unit 30RA. The following description will focus on the differences from the first embodiment, and the description of the same points will be simplified or omitted.

[0173] As shown in Figure 15, the storage device 37 of the non-friend device 52 stores the consent program PCA3 of the third embodiment. The consent program PCA3 is a program that causes the execution device 36 of the non-friend device 52, which is a computer, to function as the inquiry unit 30CD and execution unit 30RA in the non-friend device 52. Note that, hereinafter, the execution device 36 of the non-friend device 52 will be referred to as the execution device 36N. Also, the storage device 37 of the non-friend device 52 will be referred to as the storage device 37N.

[0174] 16, when the execution device 36N executes the consent program PCA3, the execution device 36N functions as an inquiry unit 30CD and an execution unit 30RA. Therefore, in the third embodiment, the non-friend device 52 has an inquiry unit 30CD and an execution unit 30RA.

[0175] The execution device 36N starts execution of the consent program PCA3 when it detects that registration of a non-friend key KN has been requested in the management system 10. The execution device 36N detects that there has been a request to register a non-friend key KN when it acquires the non-friend key information DKN. That is, the inquiry unit 30CD detects that there has been a request to register a non-friend key KN by acquiring the non-friend key information DKN.

[0176] 17, when the execution device 36N starts executing the consent program PCA2, the execution device 36N first performs the processing of step S121. In step S121, the execution device 36N identifies the owner device 40 to be the destination. In the third embodiment, information identifying the owner device 40 is added to the shared key information DKS. The execution device 36N identifies the owner device 40 identified by the information identifying the owner device 40 as the destination owner device 40 to which the consent request CD is to be sent. Then, the execution device 36N proceeds to the processing of step S122.

[0177] In step S122, the executing device 36N transmits a consent request CD to the owner device 40. After that, the executing device 36N advances the process to step S123. In step S123, the executing device 36N determines whether or not consent information CI has been received within the specified period PP from the owner device 40. Step S123 is the same as step S103 in the first embodiment, and therefore a detailed description thereof will be omitted.

[0178] When the executing device 36N receives the consent information CI from the owner device 40 within the specified period PP (S123: YES), the executing device 36N proceeds to step S124. In step S124, the executing device 36N determines to allow the management system 10 to register the non-friend key KN. Thereafter, the executing device 36N proceeds to step S125.

[0179] In step S125, the execution device 36N allows the storage of the non-friend key information DKN. That is, the execution device 36N allows the non-friend device 52 to register the non-friend key KN. Specifically, the execution device 36N allows the storage of the non-friend key information DKN in accordance with the completion notification M32 of the non-friend key KN. As a result, the execution unit 30RA allows the non-friend device 52 to store the non-friend key information DKN. Note that, once the execution device 36N allows the storage of the non-friend key information DKN, it stores the non-friend key information DKN by processing in step S47. Thereafter, the execution device 36N proceeds to the processing at step S126.

[0180] In step S126, the execution device 36N allows the transmission of the key track request D33. As a result, the execution unit 70RA allows the non-friend device 52 to transmit the key track request D33 to the management server 70. When the execution device 36N allows the transmission of the key track request D33, the execution device 36N transmits the key track request D33 to the management server 70. Thereafter, the execution device 36N proceeds with this series of processes.

[0181] On the other hand, if the executing device 36N does not receive consent information CI from the owner device 40 within the specified period PP (S123: NO), the executing device 36N proceeds to step S127. In step S127, the executing device 36N determines not to allow the management system 10 to register the non-friend key KN. Thereafter, the executing device 36N proceeds to step S128.

[0182] In step S128, the execution device 36N rejects the storage of the non-friend key information DKN. That is, the execution device 36N does not allow the non-friend device 52 to register the non-friend key KN. Specifically, even if the execution device 36N receives the completion notification M32 of the non-friend key KN, the execution device 36N does not allow the non-friend key information DKN to be stored. As a result, the execution unit 30RA does not allow the non-friend device 52 to store the non-friend key information DKN. Note that if the execution device 36N does not allow the storage of the non-friend key information DKN, the execution device 36N does not perform the processing of step S47 and therefore does not store the non-friend key information DKN. Thereafter, the execution device 36N proceeds to step S129.

[0183] In step S129, the execution device 36N does not allow the transmission of the key track request D33. As a result, the execution unit 30RA does not allow the non-friend device 52 to send the key track request D33 to the management server 70. Note that if the execution device 36N does not allow the transmission of the key track request D33, the execution device 36N does not send the key track request D33 to the management server 70. Therefore, the management server 70 does not store information indicating the device 30 as the non-friend device 52 of the non-friend key KN according to the key track request D33.

[0184] <Operation of the Third Embodiment> In the third embodiment, when the execution unit 30RA receives consent information CI from the owner device 40, it allows the non-friend device 52 to store the non-friend key information DKN. In this case, when the non-friend device 52 stores the non-friend key information DKN, the non-friend device 52 becomes able to use the non-friend key KN. On the other hand, when the execution unit 30RA does not receive consent information CI from the owner device 40, it does not allow the non-friend device 52 to store the non-friend key information DKN. In this case, when the non-friend device 52 does not store the non-friend key information DKN, the non-friend key KN does not become able to be used.

[0185] <Effects of the third embodiment> According to the third embodiment, in addition to the effect (1-1) of the first embodiment, the following effect can be achieved.

[0186] (3-1) In the third embodiment, the non-friend device 52 has an inquiry unit 30CD and an execution unit 30RA. Therefore, the inquiry unit 30CD and the execution unit 30RA can use information acquired by the non-friend device 52. In addition, the execution unit 30RA can easily control the processing performed by the non-friend device 52.

[0187] (3-2) When the inquiry unit 30CD acquires the non-friend key information DKN, it detects that there has been a request to register the non-friend key KN. Therefore, during the series of processes shown in Figure 7, the inquiry unit 30CD can detect that there has been a request to register the non-friend key KN when the non-friend device 52 stores the non-friend key information DKN.

[0188] (3-3) When the execution unit 30RA allows the non-friend device 52 to register the non-friend key KN, the execution apparatus 36N stores the non-friend key information DKN. Therefore, the non-friend device 52 can be made to be able to use the non-friend key KN.

[0189] (3-4) When the execution unit 30RA does not allow the non-friend device 52 to register the non-friend key KN, the execution apparatus 36N does not store the non-friend key information DKN. Therefore, the non-friend device 52 can remain in a state where the non-friend key KN cannot be used.

[0190] (Fourth embodiment) The management system 10 according to the fourth embodiment will be described below with reference to the drawings. The fourth embodiment differs from the first embodiment in that the friend device 51 has a query unit 51CD and an execution unit 51RA. The following description will focus on the differences from the first embodiment, and the description of the same points will be simplified or omitted.

[0191] 18, the storage device 37 of the friend device 51 stores the consent program PCA4 of the fourth embodiment. The consent program PCA4 is a program that causes the execution device 36 of the friend device 51, which is a computer, to function as an inquiry unit 51CD and an execution unit 51RA. Note that, hereinafter, the execution device 36 of the friend device 51 will be referred to as the execution device 36F. Also, the storage device 37 of the friend device 51 will be referred to as the storage device 37N.

[0192] 19, when the execution device 36N executes the consent program PCA4, the execution device 36F functions as an inquiry unit 51CD and an execution unit 51RA. Therefore, in the fourth embodiment, the friend device 51 has an inquiry unit 51CD and an execution unit 51RA.

[0193] The execution unit 35F starts execution of the consent program PCA4 when it detects that registration of a non-friend key KN has been requested in the management system 10. The execution unit 36F detects that a request for registration of a non-friend key KN has been made when an operation requesting registration of a non-friend key KN is executed in the friend device 51. That is, when the inquiry unit 51CD receives a registration request D31 for a non-friend key KN, it detects that registration of a non-friend key KN has been requested.

[0194] 20, when the execution device 36F starts executing the consent program PCA4, the execution device 36F first performs the processing of step S131. In step S131, the execution device 36F identifies the owner device 40 to be the destination. In the fourth embodiment, the friend device 51 has information identifying the owner device 40 added to the friend key information DKF. The execution device 36F identifies the owner device 40 identified by the information identifying the owner device 40 as the destination owner device 40 to which the consent request CD is to be sent. The execution device 26F then proceeds to step S132.

[0195] In step S132, the executing device 36F transmits a consent request CD to the owner device 40. After that, the executing device 36F advances the process to step S133. In step S133, the execution device 36F determines whether or not consent information CI has been received within the specified period PP from the owner device 40. Step S133 is the same as step S103 in the first embodiment, and therefore a detailed description thereof will be omitted.

[0196] When the executing device 36F receives the consent information CI from the owner device 40 within the specified period PP (S133: YES), the executing device 36F proceeds to step S134. In step S134, the executing device 36F determines to allow the management system 10 to register the non-friend key KN. Thereafter, the executing device 36F proceeds to step S135.

[0197] In step S135, the execution device 36F allows the transmission of the invitation information IV2. That is, the execution device 36F allows the friend device 51 to register the non-friend key KN. As a result, the execution unit 51RA allows the non-friend device 52 to obtain the share information SH2 and to perform the subsequent registration process. Thereafter, the execution device 36F ends this series of processes.

[0198] On the other hand, if the executing device 36F does not receive the consent information CI from the owner device 40 within the specified period PP (S133: NO), the executing device 36F proceeds to step S136.

[0199] In step S136, the execution device 36F determines not to allow registration of the non-friend key KN in the management system 10. After that, the execution device 36F advances the process to step S137.

[0200] In step S137, the execution device 36F rejects the transmission of the invitation information IV2. That is, the execution device 36F does not allow the friend device 51 to register the non-friend key KN. Specifically, even if the execution device 36F has acquired the invitation information IV2, the execution device 36F does not allow the invitation information IV2 to be transmitted. As a result, the execution device 36F does not allow the non-friend device 52 to acquire the share information SH2. Furthermore, because the non-friend device 52 does not acquire the share information SH2, the management system 10 does not perform the processes from step S43 onwards in the registration process of the non-friend key KN. Thereafter, the execution device 36F ends this series of processes.

[0201] <Actions and Effects of the Fourth Embodiment> According to the fourth embodiment, in addition to the effect (1-1) of the first embodiment, the following effect can be achieved.

[0202] (4-1) In the fourth embodiment, the friend device 51 has an inquiry unit 51CD and an execution unit 51RA. Therefore, the inquiry unit 51CD and the execution unit 51RA can use information acquired by the friend device 51. In addition, the execution unit 51RA can easily control the processing performed by the friend device 51.

[0203] (4-2) When the inquiry unit 51CD acquires the non-friend key information DKN, it detects that there is a request to register the non-friend key KN. Therefore, when the friend device 51 accepts the registration request D31 of the non-friend key KN in the series of processes shown in FIG. 7, the inquiry unit 51CD transmits an approval request CD to the owner device 40.

[0204] (Other embodiments) The above-described embodiments can be modified as follows: The above-described embodiments and the following modifications can be combined with each other within the scope of technical compatibility.

[0205] 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 communication with the device 30. Furthermore, the vehicle 20 is not limited to these modules, and may have any module that performs short-range communication with the device 30. stomach.

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

[0207] The vehicle management device 26 may be configured as a circuit including one or more processors that execute various processes according to a computer program (software). The vehicle management device 26 may also be configured as a circuit including one or more dedicated hardware circuits, such as an application-specific integrated circuit (ASIC), that execute at least some of the various processes, or a combination thereof. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to execute the processes. The memory, i.e., computer-readable medium, includes any available medium that can be accessed by a general-purpose or dedicated computer. The same applies to the device 30 and the management server 70.

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

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

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

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

[0212] The management server 70 does not need to store the database DB. The management server 70 only needs to manage at least one digital key in the management system 10.

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

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

[0215] In each of the above embodiments, the first device corresponds to the owner device 40, the second device corresponds to the friend device 51, and the third device corresponds to the non-friend device 52. The first digital key corresponds to the owner key KO, the second digital key corresponds to the friend key KF, and the third digital key corresponds to the non-friend key KN.

[0216] As in the above modified example, assume that a new non-friend key KN is registered based on a registration request from the non-friend device 52. In this case, there is a new non-friend device 52 that stores non-friend key information DKN indicating the new non-friend key KN. In this modified example, the first device may correspond to the friend device 51, the second device may correspond to the non-friend device 52, and the third device may correspond to the new non-friend device 52. The first digital key may correspond to the friend key KF, the second digital key may correspond to the non-friend key KN, and the third digital key may correspond to the new non-friend key KN.

[0217] In the first embodiment, the inquiry unit 70CD may detect that there has been a request to register a non-friend key KN, regardless of whether or not the key track request D33 has been received. For example, the inquiry unit 70CD may detect that there has been a request to register a non-friend key KN by separately acquiring a signal indicating that registration has been requested from the friend device 51 or the third device 30C.

[0218] In the first embodiment, when the execution unit 70RA does not allow the management server 70 to register the non-friend key KN, the management server 70 may store information indicating the shared device 50 that indicates the non-friend key KN in the database DB. In this case, after detecting a state in which the authentication information AT of the non-friend key KN is not stored in the vehicle 20, the management server 70 may delete the information indicating the shared device 50 that indicates the non-friend key KN from the database DB.

[0219] In the first embodiment, when the execution unit 70RA does not allow the management server 70 to register the non-friend key KN, the management server 70 may send a storage request D34 to the vehicle 20. In this case, the management server 70 may send a request to the vehicle 20 to delete the authentication information AT stored by the storage request D34. The management server 70 may cause the vehicle management device 26 to eliminate the state in which the authentication information AT of the target non-friend key KN is stored.

[0220] When the execution unit 70RA causes the management server 70 to permit registration of a non-friend key KN, the management server 70 does not have to store in the database DB information indicating the shared device 50 that indicates the non-friend key KN that has been permitted to be registered. Even in this case, if the vehicle management device 26 stores the authentication information AT of the non-friend key KN and the non-friend device 52 stores the non-friend key information DKN, the non-friend key KN is in a usable state.

[0221] The method for permitting registration of the non-friend key KN is not limited to the example in the first embodiment. For example, when not permitting registration of the non-friend key KN, the execution unit 70RA may send a request to the vehicle 20 to delete the authentication information AT that has been stored. In this case, when permitting registration of the non-friend key KN, the execution unit 70RA does not need to send a request to the vehicle 20 to delete the authentication information AT that has been stored.

[0222] The execution unit 70RA may allow the registration of the non-friend key KN after transmitting the storage request D34. In this case, the execution unit 70RA does not need to transmit the storage request D34 when the registration of the non-friend key KN is allowed.

[0223] In the second embodiment, the inquiry unit 20CD may detect that a request for registration of the non-friend key KN has been made without receiving the storage request D34. For example, the inquiry unit 20CD may detect that a request for registration of the non-friend key KN has been made by separately acquiring a signal indicating that registration has been requested from the friend device 51 or the third device 30C.

[0224] The method for permitting registration of the non-friend key KN is not limited to the example in the second embodiment. For example, when not permitting registration of the non-friend key KN, the execution unit 20RA may delete the authentication information AT once stored. In this case, when permitting registration of the non-friend key KN, the execution unit 20RA does not need to delete the authentication information AT once stored.

[0225] The execution unit 20RA may allow the registration of the non-friend key KN after receiving the storage request D34. In this case, when the execution unit 20RA allows the vehicle 20 to register the non-friend key KN, the vehicle management device 26 does not need to store the authentication information AT again in accordance with the storage request D34.

[0226] When the execution unit 20RA does not allow the vehicle 20 to register the non-friend key KN, the vehicle management device 26 may store the authentication information AT of the non-friend key KN if it has received the storage request D34. In this case, when the execution unit 20RA does not allow the registration of the non-friend key KN, it simply causes the vehicle management device 26 to delete the authentication information AT of the target non-friend key KN.

[0227] In the third embodiment, the owner device 40 may have the inquiry unit 30CD and the execution unit 30RA. For example, when the friend device 51 has the inquiry unit 30CD, the inquiry unit 30CD may detect that there is a request to register the non-friend key KN when the non-friend key information DKN is generated.

[0228] In the third embodiment, the inquiry unit 30CD may detect that a request for registration of a non-friend key KN has been made, without acquiring the non-friend key information DKN. For example, the inquiry unit 30CD may detect that a request for registration of a non-friend key KN has been made by separately acquiring a signal indicating that registration has been requested from the friend device 51 or the like. For example, the inquiry unit 30CD may detect that a request for registration of a non-friend key KN has been made by acquiring invitation information IV2.

[0229] The method for permitting registration of a non-friend key KN is not limited to the example in the third embodiment. For example, when not permitting registration of a non-friend key KN, the execution unit 20RA may delete the non-friend key information DKN that has been stored. In this case, when permitting registration of a non-friend key KN, the execution unit 20RA does not need to delete the non-friend key information DKN that has been stored.

[0230] When the execution unit 30RA allows the non-friend device 52 to register the non-friend key KN, the non-friend device 52 does not have to send the key track request D33 to the management server 70. In this case, the non-friend device 52 only needs to be able to store the authentication information AT by receiving the storage request D34 from the vehicle 20. For example, the non-friend device 52 may separately send the authentication package ATP and the storage request D34 to the vehicle 20.

[0231] When the execution unit 30RA does not allow the non-friend device 52 to register the non-friend key KN, the non-friend device 52 may send a key track request D33 to the management server 70. In this case, the execution unit 30RA may delete the non-friend key information DKN. The execution unit 30RA may also send a completion notification M51 indicating that the deletion of the non-friend key information DKN has been completed.

[0232] In each of the above embodiments, the execution unit does not need to store the third digital key and the third device 30C in association with each other in the database DB during the registration process. In other words, the execution unit does not need to update the database DB.

[0233] In the second embodiment, a device included in the vehicle 20 other than the vehicle management device 26 may have the query unit and the execution unit. In the second embodiment, it is sufficient that the vehicle 20 has the query unit and the execution unit.

[0234] The timing at which the inquiry unit inquires of the first device 30A about whether or not to accept the registration of the third digital key is not limited to the examples in the above embodiments. The inquiry unit may make an inquiry when a new third digital key is to be registered.

[0235] The method by which the inquiry unit inquires of the first device 30A about whether to accept the registration of the third digital key is not limited to sending the consent request CD in the above embodiments. The inquiry unit may also make the inquiry by sending a predetermined message.

[0236] In the above embodiments, the query unit and the execution unit do not have to be included in the same device. For example, the management server 70 may have the query unit 70CD, and the vehicle management device 26 may have the execution unit 70RA.

[0237] The query unit and the execution unit may be included in devices different from the management server 70, the vehicle management device 26, and the shared device 50. For example, in the first embodiment, the external server is the management server 70, but the external server may be a server different from the management server 70.

[0238] The storage unit 70M that stores the database DB does not have to be provided in the management server 70. If the management system 10 has the storage unit 70M, for example, the vehicle management device 26 or the device 30 may have the storage unit 70M.

[0239] The management system 10 does not need to have other functional units as long as it has at least an inquiry unit and an execution unit. Furthermore, the system is not limited to one that includes the vehicle 20, the device 30, and the management server 70 as the management system 10. For example, the system may be a computer that includes an inquiry unit and an execution unit.

[0240] (Additional notes) The technical concepts that can be understood from the above-described embodiments and modifications will be described below. [Appendix 1] A system for managing multiple digital keys that can be used for a vehicle, the system comprising: an inquiry unit that, when a second device to which a second digital key is registered based on a request from a first device to which a first digital key is registered newly registers a third digital key, inquires of the first device whether or not to accept the registration of the third digital key; and an execution unit that executes the registration process of the third digital key if it receives acceptance information indicating acceptance of the registration of the third digital key, and does not execute the registration process if it does not receive the acceptance information.

[0241] [Appendix 2] The system described in Appendix 1, wherein the vehicle has an authentication information storage unit that stores authentication information for authenticating the third digital key when using the third digital key, and the execution unit sends a storage request to the vehicle requesting storage of the authentication information during the registration process.

[0242] [Appendix 3] The system described in Appendix 1 or Appendix 2 includes a database storage unit that stores a database in which, for each of the multiple digital keys, the corresponding vehicle and the registered device are associated, and the execution unit stores the third digital key and the third device to which the third digital key is registered in the database in association with each other during the registration process.

[0243] [Appendix 4] The system described in Appendix 3, wherein when a key track request requesting an update of the database is received from the second device, the inquiry unit inquires of the first device whether or not to agree to the registration of the third digital key.

[0244] [Supplementary Note 5] The system according to any one of Supplementary Note 1 to Supplementary Note 4, wherein an external server outside the vehicle includes the query unit and the execution unit. [Appendix 6] The vehicle includes an authentication information storage unit that stores authentication information for authenticating the third digital key when the third digital key is used, and a receiving unit that receives a storage request requesting storage of the authentication information, and the inquiry unit, when the receiving unit receives the storage request, inquires of the first device whether or not to agree to registration of the third digital key. The system described in any one of Appendices 1 to 3.

[0245] [Appendix 7] The system described in Appendix 6, wherein the execution unit is provided in the vehicle, and when the consent information is received, the execution unit stores the authentication information in the authentication information storage unit in accordance with the storage request.

[0246] [Appendix 8] The system described in Appendix 7, wherein if the consent information is not received, the execution unit does not store the authentication information in the authentication information storage unit even if the storage request is received.

[0247] [Supplementary Note 9] The system according to any one of Supplementary Notes 1 to 3, wherein the second device comprises the inquiry unit and the execution unit. [Appendix 10] The system described in Appendix 9, wherein when the second device accepts a request to register the third digital key, the inquiry unit inquires of the first device whether or not to agree to the registration of the third digital key. [Explanation of symbols]

[0248] 10...Management system 20...Vehicle 20CD…Inquiry Department 20M…Storage section 20RA…Executive Department 20RE...Receiver 26...Vehicle management device 27...Execution device 28…Storage device 30…Devices 30A...First device 30B...Second device 30C...Third device 30CD…Inquiry Department 30RA…Executive Department 40...Owner device 50...Shared devices 51...Friend Device 51CD…Inquiry Department 51RA…Executive Department 52...Non-Friendly Device 60...Device Server 70...Administration server 70CD…Inquiry Department 70M…Storage section 70RA…Executive Department 70RE...Receiver AT…Authentication information CD…Consent request CI…Consent information DB...database DKN...Non-Friend Key Information DKO…Owner key information DKS…Share Key Information KN...Non-Friend Key KO…Owner key KS...Share Key PCA, PCA2, PCA3...Acceptance Program

Claims

1. A system for managing multiple digital keys available for a vehicle, comprising: an inquiry unit that, when a second device to which a second digital key is registered newly registers a third digital key based on a request from a first device to which a first digital key is registered, inquires of the first device whether or not to approve the registration of the third digital key; an execution unit that executes registration processing of the third digital key when consent information indicating consent to registration of the third digital key is received, and does not execute the registration processing when the consent information is not received. system.

2. the vehicle has a storage unit that stores authentication information for authenticating the third digital key when the third digital key is used; The execution unit transmits a storage request to the vehicle to request storage of the authentication information in the registration process. The system of claim 1 .

3. a storage unit that stores a database in which the corresponding vehicle and a registered device are associated with each of the plurality of digital keys; The execution unit stores the third digital key and the third device in which the third digital key is registered in the database in association with each other during the registration process. The system of claim 1 .

4. When a key track request for updating the database is received from the second device, the inquiry unit inquires of the first device whether or not to approve registration of the third digital key. The system of claim 3.

5. An external server located outside the vehicle includes the query unit and the execution unit. The system of claim 1 .

6. The vehicle is a storage unit that stores authentication information for authenticating the third digital key when the third digital key is used; a receiving unit that receives a storage request for requesting storage of the authentication information, The inquiry unit inquires of the first device whether or not to accept registration of the third digital key when the receiving unit receives the storage request. The system of claim 1 .

7. the execution unit is provided in the vehicle, When the approval information is received, the execution unit stores the authentication information in the storage unit in accordance with the storage request. The system of claim 6.

8. If the consent information is not received, the execution unit does not store the authentication information in the storage unit even if the storage request is received. The system of claim 7.

9. The second device includes the inquiry unit and the execution unit. The system of claim 1 .

10. When the second device receives a request to register the third digital key, the inquiry unit inquires of the first device whether or not to accept the registration of the third digital key. The system of claim 9.

11. A management server that manages a plurality of digital keys that can be used for a vehicle, an inquiry unit that, when a second device to which a second digital key is registered newly registers a third digital key based on a request from a first device to which a first digital key is registered, inquires of the first device whether or not to approve the registration of the third digital key; an execution unit that executes registration processing of the third digital key when consent information indicating consent to registration of the third digital key is received, and does not execute the registration processing when the consent information is not received. Management server.

12. A vehicle management device that manages a plurality of digital keys that can be used for a vehicle, an inquiry unit that, when a second device to which a second digital key is registered newly registers a third digital key based on a request from a first device to which a first digital key is registered, inquires of the first device whether or not to approve the registration of the third digital key; an execution unit that executes registration processing of the third digital key when consent information indicating consent to registration of the third digital key is received, and does not execute the registration processing when the consent information is not received. Vehicle management device.

13. A management method performed by a system that manages multiple digital keys that can be used for a vehicle, comprising: The system comprises: a second device to which a second digital key is registered, inquiring of whether or not to approve the registration of a third digital key, when registering a new third digital key based on a request from a first device to which a first digital key is registered; When consent information indicating consent to the registration of the third digital key is received, the registration process of the third digital key is executed, and when the consent information is not received, the registration process is not executed. Management method.

14. A program executed by a computer that manages a plurality of digital keys that can be used for a vehicle, The computer an inquiry unit that, when a second device to which a second digital key is registered newly registers a third digital key based on a request from a first device to which a first digital key is registered, inquires of the first device whether or not to approve the registration of the third digital key; and an execution unit that executes the registration process of the third digital key when consent information indicating consent to the registration of the third digital key is received, and does not execute the registration process when the consent information is not received. program.

Images