Management system, management server, vehicle management device, and device

Abstract

To prevent a device from continuing to store both information about a first digital key and information about a second digital key.SOLUTION: The management system 10 includes a vehicle 20, a device 30, and a management server 70. The vehicle management device 26 of the vehicle 20 stores information relating to the digital key. The device 30 stores information related to a plurality of digital keys that can be registered in the vehicle 20. The management server 70 manages the first digital key and the second digital key as digital keys for the same vehicle 20. The management system 10 includes a monitoring unit 70M. The monitoring unit 70M performs control so that the devices 30 store information related to one of the first digital key and the second digital key for the same devices 30, and the devices 30 store information related to the other digital key.SELECTED DRAWING: Figure 10

Description

[Technical Field]

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

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, multiple devices, and a management server. The vehicle has a vehicle management device that stores information about the digital key. The device stores information about the digital key.

[0003] The management server manages multiple digital keys. When a digital key is used, the vehicle management device authenticates the digital key and then allows control of the vehicle, such as unlocking the vehicle. [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, a first digital key and a second digital key may be registered for the same device as digital keys for the same vehicle. Suppose a first digital key and a second digital key are registered for the same device for the same vehicle. In this case, even though one digital key is sufficient for the same device, the device ends up having to store information about the unnecessary digital keys. [Means for solving the problem]

[0006] In order to solve the above problem, the management system comprises a vehicle having a vehicle management device that stores information about digital keys, a device that stores information about the digital keys, multiple of which can be registered to the vehicle, and a management server that manages a first digital key and a second digital key for the same vehicle, and is equipped with a monitoring unit that controls the device to store information about one of the first digital key and the second digital key for the same device, and not store information about the other digital key.

[0007] In order to solve the above problem, the management server is a management server that manages a first digital key and a second digital key for a device that stores information about multiple digital keys that can be registered to a vehicle, and is equipped with a monitoring unit that controls the device to store information about one of the first digital key and the second digital key for the same device, and not store information about the other digital key.

[0008] In order to solve the above problem, the vehicle management device is a vehicle management device that is mounted on a vehicle and stores information about digital keys, and is equipped with a device that stores information about the digital keys, of which multiple registrations are possible, and a monitoring unit that controls the device to store information about one of a first digital key and a second digital key for the same vehicle, and not store information about the other digital key.

[0009] In order to solve the above problem, the device stores information about multiple digital keys that can be registered for a vehicle having a vehicle management device that stores information about the digital keys, and is equipped with a monitoring unit that controls the device to store information about one of a first digital key and a second digital key for the same device and the same vehicle, and does not store information about the other digital key. [Effects of the Invention]

[0010] In each of the above configurations, the monitoring unit can prevent the device from continuing to store both information related to the first digital key and information related to the second digital key. [Brief explanation of the drawings]

[0011] [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 a monitoring unit in the management system of the first embodiment. [Figure 11] FIG. 11 is a flowchart showing a series of processes performed by the monitoring unit of the first embodiment. [Figure 12] FIG. 12 is a flowchart showing a series of processes performed by the monitoring unit of the second embodiment. [Figure 13] FIG. 13 is a flowchart showing a series of processes performed by the monitoring unit of the third embodiment. [Figure 14] FIG. 14 is a flowchart showing a series of processes performed by the monitoring unit of the fourth embodiment. [Figure 15] FIG. 15 is a flowchart showing a series of processes performed by the monitoring unit of the fifth embodiment. [Figure 16] FIG. 16 is a schematic diagram showing a vehicle according to the sixth embodiment. [Figure 17] FIG. 17 is a schematic diagram showing a monitoring unit in the management system of the sixth embodiment. [Figure 18] FIG. 18 is a flowchart showing a series of processes performed by the monitoring unit of the sixth embodiment. [Figure 19] FIG. 19 is a schematic diagram showing a non-friend device according to the seventh embodiment. [Figure 20] FIG. 20 is a schematic diagram showing a monitoring unit in the management system of the seventh embodiment. [Figure 21] FIG. 21 is a flowchart showing a series of processes performed by the monitoring unit of the seventh embodiment. [Figure 22] FIG. 22 is a schematic diagram showing an owner device of the eighth embodiment. [Figure 23] FIG. 23 is a schematic diagram showing a monitoring unit in the management system of the eighth embodiment. [Figure 24] FIG. 24 is a flowchart showing a series of processes performed by the monitoring unit of the eighth embodiment. [Figure 25] FIG. 25 is a flowchart showing a series of processes performed by the monitoring unit of the ninth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] (First embodiment) A first embodiment of the management system will be described below with reference to the drawings. <Outline of the management system> As shown in FIG. 1, the management system 10 manages a plurality of digital keys that can be used for a vehicle 20. 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 the vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0037] <Administration Server> The management server 70 manages the digital keys. The management server 70 is capable of communicating with the vehicle 20 and multiple devices 30. The management server 70 includes an execution device 71 and a storage device 72. The storage device 72 stores a server program PS, a monitoring program PM, and a database DB. When executed by the execution device 71, the server program PS causes the execution device 71 to register digital keys in the database DB and delete digital keys from the database DB. Details of the monitoring program PM will be described later.

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

[0039] As shown in Figure 4, the data DA for one vehicle 20 includes the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. Hierarchical rankings are determined based on the type of digital key. From top to bottom, the hierarchy is arranged as follows: owner key KO, friend key KF, and non-friend key KN. The higher the hierarchy, the greater the authority set.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0053] <Digital key registration> Next, a series of processes for registering digital keys in the management system 10 will be described. The management system 10 registers digital keys by registering an owner key KO, a friend key KF, and a non-friend key KN. The following describes the series of processes from when each digital key is not registered to when it is registered. In the following 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 ​​as processes executed by the device 30, and the processes executed by the execution unit 71 as processes executed by the management server 70.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0123] <Monitoring control of the monitoring unit> Next, a control in the management system 10 for preventing multiple registrations of digital keys for the same vehicle 20 in the same device 30 will be described.

[0124] 1, in the management server 70, a storage device 72 stores a monitoring program PM. The monitoring program PM is executed by an execution device 71, causing the execution device 71 to function as a monitoring unit 70M.

[0125] 10, the execution device 71 executes the monitoring program PM, causing the execution device 71 to function as a monitoring unit 70M. Therefore, in the first embodiment, the management server 70 includes the monitoring unit 70M.

[0126] The monitoring unit 70M performs control to avoid or resolve a situation in which multiple digital keys for the same vehicle 20 are registered to the same device 30. One of the first digital key K1 and the second digital key K2 for the same device 30 is an allowed digital key KP that is allowed to be registered. The other of the first digital key K1 and the second digital key K2 for the same device 30 is an excluded digital key KR that is not allowed to be registered. Note that the first digital key K1 is a digital key whose registration was requested before the second digital key K2. In this embodiment, the type of the first digital key K1 and the type of the second digital key K2 are non-friend keys KN.

[0127] In the monitoring control of the monitoring unit 70M, the monitoring unit 70M causes the vehicle management device 26 to store information about the permitted digital keys KP and not store information about the rejected digital keys KR.

[0128] Specifically, the monitoring unit 70M causes the vehicle management device 26 to store the authentication information AT of the permitted digital key KP. The monitoring unit 70M causes the vehicle management device 26 to not store the authentication information AT of the excluded digital key KR.

[0129] The monitoring unit 70M causes the device 30 to store the key information DK of the permitted digital key KP, and the monitoring unit 70M causes the device 30 to not store the key information DK of the excluded digital key KR.

[0130] The monitoring unit 70M causes the data DA of the vehicle 20 in the database DB to store the device 30 with the registered permitted digital key KP. The monitoring unit 70M causes the data DA of the vehicle 20 in the database DB to store the device 30 with the registered excluded digital key KR. In this way, the monitoring unit 70M avoids or eliminates a situation in which multiple digital keys for the same vehicle 20 are registered in the same device 30.

[0131] Specifically, the execution device 71 starts execution of the monitoring program PM when it receives a key tracking request D33 for the second digital key K2. When the execution device 71 receives the key tracking request D33, it detects that registration of the second digital key K2 has been requested in the management system 10. That is, the monitoring unit 70M detects that registration of the second digital key K2 has been requested when the management server 70 receives the key tracking request D33 for the second digital key K2.

[0132] 11, when the execution device 71 starts executing the monitoring program PM, it first performs the processing of step S101. In step S101, the execution device 71 identifies the specific device 30X, which is the device 30 that transmitted the received key track request D33. Specifically, the execution device 71 identifies the specific device 30X by referring to the identification information indicating the transmission source device 30. Thereafter, the execution device 71 proceeds to the processing of step S102.

[0133] In step S102, the execution device 71 determines whether the first digital key K1 has already been registered for the specific device 30X. Specifically, the execution device 71 refers to the database DB to determine whether the data DA of the target vehicle 20 includes the specific device 30X as a device 30 having the first digital key K1.

[0134] When the data DA of the target vehicle 20 includes a specific device 30X, the specific device 30X stores first key information DK1, which is the key information DK of the first digital key K1. In this case, the vehicle management device 26 stores first authentication information AT1, which is the authentication information AT of the first digital key K1.

[0135] On the other hand, if the specific device 30X is not included in the data DA of the target vehicle 20, the specific device 30X does not store the first key information DK1. In this case, the vehicle management device 26 does not store the first authentication information AT1.

[0136] When the execution device 71 determines that the first digital key K1 is not registered for the specific device 30X (S102: NO), the execution device 71 proceeds to step S103.

[0137] In step S103, the execution device 71 allows the second digital key K2 to be registered in the database DB. Specifically, in accordance with the key track request D33 for the second digital key K2, the execution device 71 allows the specific device 30X to be stored as a device 30 in which the second digital key K2 is registered. As a result, the monitoring unit 70M causes the management server 70 to allow the second digital key K2 to be registered in the database DB. Through registration management of the non-friend key KN, the execution device 71 stores the specific device 30X as a device 30 in which the second digital key K2, which is a non-friend key KN, is registered. Thereafter, the execution device 71 proceeds to step S104.

[0138] In step S104, the execution device 71 allows the authentication package ATP and storage request D34 of the second digital key K2 to be sent to the vehicle 20. As a result, the monitoring unit 70M allows the management server 70 to send the authentication package ATP and storage request D34 of the second digital key K2 to the vehicle 20. The execution device 71 transmits the authentication package ATP and storage request D34 of the second digital key K2 to the vehicle 20 through a registration process. When the vehicle 20 receives the storage request D34, the vehicle management device 26 stores the authentication package ATP of the second digital key K2 as second authentication information AT2. The second authentication information AT2 is the authentication information AT of the second digital key K2. The execution device 71 then proceeds to step S105.

[0139] In step S105, the executing device 71 allows the transmission of the completion notification M33. As a result, the monitoring unit 70M causes the management server 70 to allow the transmission of the completion notification M33. The executing device 71 then ends this series of processes. Therefore, when the monitoring unit 70M receives a key track request D33 for the second digital key K2 when the first digital key K1 has not been registered for the specific device 30X, the monitoring unit 70M allows the processes from step S49 onwards shown in FIG. 7.

[0140] 11, when the executing device 71 determines that the first digital key K1 is registered for the specific device 30X (S102: YES), the executing device 71 proceeds to step S111. In this case, the first key information DK1 is stored in the specific device 30X, the second key information DK2 is not stored in the specific device 30X, and registration of the second digital key K2 is requested. In the first embodiment, the first digital key K1 is the permitted digital key KP and the second digital key K2 is the excluded digital key KR.

[0141] In step S111, the execution device 71 rejects the registration of the second digital key K2 in the database DB. As a result, the execution device 71 does not store the specific device 30X in the database DB as a device 30 in which the second digital key K2, which is a non-friend key KN, is registered through the registration management of the non-friend key KN.

[0142] In other words, the monitoring unit 70M does not allow the management server 70 to register the second digital key K2 in the database DB. Therefore, the monitoring unit 70M does not cause the management server 70 to store the specific device 30X as a device 30 in which the second digital key K2 is registered. As a result, the monitoring unit 70M causes the management server 70 to enter a state in which the specific device 30X is not stored as a shared device 50 in which the second digital key K2 is registered. After that, the execution device 71 proceeds to step S112.

[0143] In step S112, the execution device 71 refuses to send the authentication package ATP and storage request D34 of the second digital key K2 to the vehicle 20. As a result, the execution device 71 does not send the authentication package ATP and storage request D34 of the second digital key K2 to the vehicle 20.

[0144] In other words, the monitoring unit 70M does not cause the management server 70 to send the authentication package ATP of the second digital key K2 and the storage request D34 to the vehicle 20. As a result, the monitoring unit 70M does not cause the vehicle management device 26 to store the second authentication information AT2, thereby causing the vehicle management device 26 to enter a state in which the vehicle management device 26 does not store the second authentication information AT2. Thereafter, the execution device 71 proceeds to step S113.

[0145] In step S113, a request D61 to delete the second key information DK2, which is the key information DK of the second digital key K2, is transmitted to the specific device 30X, causing the specific device 30X to delete the stored second key information DK2.

[0146] That is, the monitoring unit 70M causes the specific device 30X to delete the second key information DK2 stored in the specific device 30X. As a result, the monitoring unit 70M causes the vehicle management device 26 to enter a state in which the second key information DK2 is not stored in the vehicle management device 26. Thereafter, the execution device 71 proceeds to step S114.

[0147] In step S114, the executing device 71 refuses to send the completion notification M33. As a result, the monitoring unit 70M does not allow the management server 70 to send the completion notification M33. Therefore, the executing device 71 does not send the completion notification M33. After that, the executing device 71 proceeds to step S115.

[0148] In step S115, the executing device 71 causes the management server 70 to send a notification to the specific device 30X indicating that the key track request D33 cannot be fulfilled. As a result, the executing device 71 sends a notification indicating that the key track request D33 cannot be fulfilled to the specific device 30X, instead of the completion notification M33. Thereafter, the executing device 71 proceeds to step S116.

[0149] In step S116, the execution device 71 determines whether the first digital key K1 is managed as being in a fade-out state. That is, the execution device 71 determines whether the execution device 71 has stored the state of the first digital key K1 as being in a fade-out state because the execution device 71 has received the reservation deletion request D41 from the friend device 51, even though the first digital key K1 is registered.

[0150] If the first digital key K1 is in the fade-out state (S116: YES), the execution device 71 proceeds to step S117. In step S117, the execution device 71 cancels the fade-out state of the first digital key K1. Specifically, the execution device 71 stores the state of the first digital key K1 as not being in the fade-out state.

[0151] In other words, if the specified condition RC is not met, the monitoring unit 70M does not allow the management server 70 to send the deletion request D42, even if the specified condition RC is met later. In other words, even if the management server 70 acquires the reservation deletion request D41, the monitoring unit 70M does not allow the management server 70 to send the deletion request D42. As a result, the monitoring unit 70M places the first digital key K1 in a registered state. Specifically, the monitoring unit 70M places the specific device 30X in a state in which the specific device 30X stores the first key information DK1, which is the key information DK of the first digital key K1. The monitoring unit 70M places the specific device 30X in a state in which the first authentication information AT1 is stored. The monitoring unit 70M places the specific device 30X in a state in which the management server 70 stores the specific device 30X as a shared device 50 to which the first digital key K1 is registered. After that, the execution device 71 ends this series of processes.

[0152] On the other hand, if the first digital key K1 is not in the fade-out state (S116: NO), the execution device 71 ends the current series of processes. In this case, the monitoring unit 70M also causes the first digital key K1 to be registered in the management system 10.

[0153] <Operation of the First Embodiment> In the first embodiment, when the first digital key K1 is registered, the management server 70 stores the specific device 30X as the device 30 to which the first digital key K1 is registered. When the first digital key K1 is registered, the vehicle management device 26 stores the first authentication information AT1. When the first digital key K1 is registered, the specific device 30X stores the first digital key K1.

[0154] Here, it is assumed that the first digital key K1 is registered based on a registration request from the second device 30B, which is the friend device 51. The third device 30C is not aware that the first digital key K1 has been registered for the specific device 30X based on the registration request from the second device 30B. It is also assumed that, with the first digital key K1 registered, the series of processes shown in FIG. 7 related to the registration of the second digital key K2 is performed based on the registration request from the third device 30C, which is the friend device 51.

[0155] In this case, when the execution device 71 receives the key track request D33 for the second digital key K2, the specific device 30X stores the second key information DK2. Meanwhile, the management server 70 does not store the specific device 30X as a shared device 50 to which the second digital key K2 is registered. The vehicle management device 26 does not store the second authentication information AT2.

[0156] In the first embodiment, the monitoring unit 70M deletes the second key information DK2 stored in the specific device 30X. As a result, the monitoring unit 70M puts the specific device 30X in a state where the second key information DK2 is not stored.

[0157] The monitoring unit 70M does not cause the management server 70 to store the specific device 30X as a shared device 50 in which the second digital key K2 is registered. As a result, the monitoring unit 70M causes the management server 70 to enter a state in which the specific device 30X is not stored as a shared device 50 in which the second digital key K2 is registered.

[0158] The monitoring unit 70M does not allow the management server 70 to send the authentication package ATP of the second digital key K2 and the storage request D34 to the vehicle 20. As a result, the monitoring unit 70M causes the vehicle management device 26 to enter a state where the second authentication information AT2 is not stored.

[0159] <Effects of the first embodiment> (1-1) The monitoring unit 70M causes the specific device 30X to store the key information DK of the permitted digital key KP. The monitoring unit 70M causes the specific device 30X to not store the key information DK of the excluded digital key KR. This allows the management system 10 to avoid the specific device 30X continuing to store both the first key information DK1 and the second key information DK2.

[0160] (1-2) When the first key information DK1 is stored in the specific device 30X, the second key information DK2 is not stored in the specific device 30X, and registration of the second digital key K2 is requested, the monitoring unit 70M performs monitoring control. Therefore, when a situation arises in which both the first digital key K1 and the second digital key K2 can be registered, the monitoring unit 70M can perform monitoring control.

[0161] (1-3) The monitoring unit 70M sets the permitted digital key KP as the first digital key K1. The monitoring unit 70M sets the excluded digital key KR as the second digital key K2. Therefore, the monitoring unit 70M can avoid a situation where the already registered first digital key K1 remains registered while the second digital key K2 for which registration is requested is newly registered. Therefore, the specific device 30X can continue to use the already registered first digital key K1.

[0162] (1-4) When the management server 70 receives the reservation deletion request D41, it transmits a deletion request D42 to the specific device 30X to delete the first key information DK1 when the specified condition RC is met. When the monitoring unit 70M detects that registration of the second digital key K2 has been requested, even if the management server 70 has received the reservation deletion request D41, it cancels the fade-out state, thereby preventing the deletion request D42 from being sent to the specific device 30X. As a result, the monitoring unit 70M causes the specific device 30X to store the first key information DK1. Therefore, the management system 10 allows the specific device 30X to maintain the state in which it stores the first key information DK1.

[0163] (1-5) The management server 70 has a monitoring unit 70M. Therefore, the monitoring unit 70M can monitor the registration status of the first digital key K1 and the second digital key K2 by referring to the database DB stored in the management server 70 and the signals received by the management server 70.

[0164] (1-6) In the above embodiment, the type of the first digital key K1 and the type of the second digital key K2 are non-friend keys KN. The non-friend keys KN are registered based on a registration request D31 from the friend device 51. Multiple friend devices 51 can be registered to one vehicle 20. Therefore, it is likely that multiple non-friend keys KN will be registered to the same device 30 due to registration requests D11 from different friend devices 51. Therefore, if the first digital key K1 and the second digital key K2 are non-friend keys KN, it is easier to obtain the effect of (1-1) by applying the present invention.

[0165] (Second embodiment) A second embodiment of the management system will be described below with reference to the drawings. The second embodiment differs from the first embodiment in the process for preventing the second key information DK2 from being stored. Specifically, in the series of processes shown in FIG. 7 , the management server 70 transmits a request to the third device 30C to store the non-friend key information DKN along with a completion notification M33. The third device 30C then performs step S47 after receiving the request to store the non-friend key information DKN from the management server 70. Furthermore, steps S121 to S124 are performed instead of steps S111 to S113. Furthermore, in the second embodiment, step S125 is performed. The following description will focus on the differences from the first embodiment, and descriptions of the same aspects will be simplified or omitted.

[0166] <Monitoring control of the monitoring unit> 12, when the execution device 71 starts execution of the monitoring program PM in the second embodiment, it first performs the processing of step S101. The processing of steps S101 to S105 is the same as that in the first embodiment, and therefore detailed description thereof will be omitted.

[0167] When the execution device 71 determines that the first digital key K1 is registered for the specific device 30X (S102: YES), the execution device 71 advances the process to step S121.

[0168] In step S121, the execution device 71 transmits a prohibition request D62 to the vehicle 20 to prohibit storage of the second authentication information AT2. Upon receiving the prohibition request D62, the vehicle 20 does not store the second authentication information AT2 even if it subsequently receives a storage request D34 for the second authentication information AT2. The execution device 71 then proceeds to step S122.

[0169] In step S122, the execution device 71 allows the second digital key K2 to be registered in the database DB. The process in step S122 is the same as the process in step S103. After that, the execution device 71 proceeds to step S123.

[0170] In step S123, the execution device 71 allows the authentication package ATP of the second digital key K2 and the storage request D34 to be transmitted to the vehicle 20. The process of step S123 is the same as the process of step S104. Thereafter, the execution device 71 proceeds to step S124.

[0171] In step S124, the executing device 71 transmits a prohibition request D74 to the specific device 30X to prohibit storage of the second key information DK2. As a result, the specific device 30X does not store the second key information DK2. Thereafter, the executing device 71 proceeds to step S114. The processes of steps S114 to S115 are the same as those in the first embodiment, and therefore detailed description will be omitted. Note that in the process of step S114, the executing device 71 does not transmit a request to store the second key information DK2 to the specific device 30X.

[0172] After the execution device 71 performs the process of step S115, the execution device 71 proceeds to step S125. In step S125, the execution device 71 deletes from the database DB information indicating the specific device 30X as the shared device 50 in which the second digital key K2 is registered. The execution device 71 then proceeds to step S116. The processes of steps S116 and S117 are the same as those in the first embodiment, and therefore detailed description thereof will be omitted. The execution device 71 then terminates the series of processes.

[0173] <Operation of the Second Embodiment> In the second embodiment, unlike the first embodiment, even when registration of the second digital key K2 is not permitted, the execution device 71 allows registration of the second digital key K2 in the database DB by processing in step S122. Furthermore, even when registration of the second digital key K2 is not permitted, the execution device 71 allows transmission of the authentication package ATP and storage request D34 for the second digital key K2 to the vehicle 20 by processing in step S123. Therefore, when the execution device 71 receives the key track request D33 for the second digital key K2, it performs the processing in step S49 of the series of processing shown in FIG. 7, followed by the processing of transmitting the authentication package ATP and storage request D34.

[0174] However, in the second embodiment, the execution device 71 transmits the prohibition request D62 to the vehicle 20 by the processing of step S121. Therefore, upon receiving the prohibition request D62, the vehicle management device 26 does not store the authentication package ATP as the second authentication information AT2 by the storage request D34.

[0175] In the second embodiment, the execution device 71 deletes the information indicating the specific device 30X as the non-friend device 52 of the second digital key K2 from the database DB through the process of step S124.

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

[0177] (2-1) The specific device 30X stores the non-friend key information DKN after receiving a request to store the non-friend key information DKN from the management server 70. According to the fourth embodiment, the monitoring unit 70M transmits a prohibition request D74 to the vehicle 20. Furthermore, the monitoring unit 70M does not transmit a request to store the non-friend key information DKN, which is the second key information DK2, to the specific device 30X. Therefore, the monitoring unit 70M does not cause the specific device 30X to store the second key information DK2. As a result, the monitoring unit 70M causes the specific device 30X to enter a state in which the second key information DK2 is not stored. In this case, the non-friend device 52, which is the specific device 30X, does not need to store the second key information DK2 in the first place.

[0178] (2-2) The monitoring unit 70M causes the management server 70 to delete information stored in the database DB that indicates the specific device 30X as a shared device 50 in which the second digital key K2 is registered. Therefore, by deleting the information once stored in the management server 70, the monitoring unit 70M causes the database DB to no longer store information that indicates the specific device 30X as a shared device 50 in which the second digital key K2 is registered. In other words, the management system 10 can prevent the management server 70 from continuing to store information that indicates the specific device 30X as a non-friend device 52 of the second digital key K2.

[0179] (Third embodiment) A third embodiment of the management system will be described below with reference to the drawings. In the third embodiment, the timing at which the execution device 71 executes the monitoring program PM is different from that in the first embodiment. Also, in the third embodiment, some of the processing performed by the monitoring unit 70M is different from that in the first embodiment. Specifically, in the third embodiment, monitoring control by the monitoring unit 70M is performed without the condition that registration of the second digital key K2 has been detected. Note that the following description will focus on the differences from the first embodiment, and explanations of the same points will be simplified or omitted.

[0180] <Monitoring control of the monitoring unit> In the third embodiment, the execution device 71 repeatedly executes the monitoring program PM in the third embodiment at predetermined intervals, which may be, for example, one day.

[0181] 13, when the execution device 71 starts executing the monitoring program PM, it first performs the processing of step S131. In step S131, the execution device 71 determines whether the first digital key K1 and the second digital key K2 are registered. Specifically, the execution device 71 refers to the database DB to determine whether the same specific device 30X for the target vehicle 20 is registered as the non-friend device 52 for the first digital key K1 and the non-friend device 52 for the second digital key K2.

[0182] If the first digital key K1 and the second digital key K2 are not registered (S131: NO), the execution device 71 ends the current series of processes. On the other hand, if the first digital key K1 and the second digital key K2 are registered (S131: YES), the execution device 71 proceeds to step S132.

[0183] In step S132, the execution device 71 transmits a deletion request D63 to the vehicle 20, requesting deletion of the second authentication information AT2. When the vehicle 20 receives the deletion request D63, the vehicle management device 26 deletes the stored second authentication information AT2. The execution device 71 then proceeds to step S133.

[0184] In step S133, the execution device 71 transmits a deletion request D64 to the specific device 30X, requesting deletion of the second key information DK2. Upon receiving the deletion request D64, the specific device 30X deletes the stored second key information DK2. The execution device 71 then proceeds to step S134.

[0185] In step S134, the execution device 71 deletes from the database DB information indicating the specific device 30X as the shared device 50 in which the second digital key K2 is registered. The execution device 71 then proceeds to step S116. The processes of steps S116 and S117 are the same as those in the first embodiment, and therefore detailed description thereof will be omitted. The execution device 71 then terminates the series of processes.

[0186] <Operation of the Third Embodiment> Unlike the first embodiment, the third embodiment is configured such that the second digital key K2 is registered in addition to the first digital key K1. Therefore, when the monitoring unit 70M starts functioning, the vehicle 20 stores the second authentication information AT2. The specific device 30X stores the second key information DK2. The management server 70 stores information indicating the specific device 30X as the non-friend device 52 of the second digital key K2.

[0187] The monitoring unit 70M then transmits a deletion request D63 for the second authentication information AT2 to the vehicle 20. The monitoring unit 70M transmits a deletion request D64 for the second key information DK2 to the specific device 30X. The monitoring unit 70M deletes the information indicating the specific device 30X as a non-friend device 52 for the second digital key K2 from the database DB.

[0188] <Effects of the third embodiment> According to the third embodiment, in addition to the effects (1-1) to (1-3) and (1-6) of the first embodiment and the effect (2-2) of the second embodiment, the following effect can be achieved.

[0189] (3-1) By sending the deletion request D64, the monitoring unit 70M causes the specific device 30X to delete the second key information DK2, thereby causing the specific device 30X to no longer store the second key information DK2. In other words, even if the specific device 30X once stores the first key information DK1 and the second key information DK2, the monitoring unit 70M causes the second key information DK2 to be deleted. This allows the management system 10 to prevent the specific device 30X from continuing to store the second key information DK2.

[0190] Furthermore, according to the third embodiment, the relationship between the monitoring program PM and the server program PS is weaker than in the first and second embodiments. Specifically, the processing performed by executing the monitoring program PM differs in timing from the series of processing shown in Fig. 7. Therefore, it is easy to introduce an additional monitoring program PM into a management system 10 in which the series of processing shown in Fig. 7 is already performed by the server program PS.

[0191] (Fourth embodiment) A fourth embodiment of the management system will be described below with reference to the drawings. The fourth embodiment differs from the first embodiment in that the permitted digital key KP is the second digital key K2 and the excluded digital key KR is the first digital key K1. The following description will focus on the differences from the first embodiment, and the description of the same points will be simplified or omitted.

[0192] <Monitoring control of the monitoring unit> 14, when the execution device 71 starts execution of the monitoring program PM in the fourth embodiment, it first performs the processing of step S101. The processing of steps S101 and S102 is the same as in the first embodiment, and therefore detailed description thereof will be omitted.

[0193] When the execution device 71 determines that the first digital key K1 is registered for the specific device 30X (S102: YES), the execution device 71 advances the process to step S141.

[0194] In step S141, the execution device 71 transmits a deletion request D65 to the vehicle 20, which is a request to delete the first authentication information AT1. When the vehicle 20 receives the deletion request D65, the vehicle management device 26 deletes the stored first authentication information AT1. In other words, by processing step S141, the monitoring unit 70M causes the vehicle management device 26 to no longer store the first authentication information AT1. Note that in the fourth embodiment, the execution device 71 performs the processing of step S141 regardless of whether the first digital key K1 is in a fade-out state. In other words, the monitoring unit 70M causes the management server 70 to send the deletion request D65 even if the specified condition RC is not satisfied. The execution device 71 then proceeds to step S142.

[0195] In step S142, the execution device 71 transmits a deletion request D66 to the specific device 30X, which is a request to delete the first key information DK1. In the fourth embodiment, the execution device 71 performs the process of step S142 regardless of whether the first digital key K1 is in a fade-out state. Upon receiving the deletion request D66, the vehicle 20 deletes the stored first key information DK1. In other words, by performing the process of step S142, the monitoring unit 70M causes the specific device 30X to no longer store the first key information DK1. The execution device 71 then proceeds to step S143.

[0196] In step S143, the execution device 71 deletes from the database DB the information indicating the specific device 30X as the non-friend device 52 of the first digital key K1. That is, by the processing of step S143, the monitoring unit 70M causes the management server 70 to no longer store information indicating the specific device 30X as the device 30 in which the first digital key K1 is registered. Thereafter, the execution device 71 proceeds to step S144.

[0197] In step S144, the execution device 71 cancels the registration state of the first digital key K1 and transmits a notification M61 indicating that the deletion of the first digital key K1 has been completed to the specific device 30X. After that, the execution device 71 proceeds to step S145.

[0198] In step S145, the execution device 71 allows the second digital key K2 to be registered in the database DB. The process of step S145 is the same as the process of step S103 in the first embodiment. After that, the execution device 71 proceeds to step S146.

[0199] In step S146, the execution device 71 allows the authentication package ATP of the second digital key K2 and the storage request D34 to be transmitted to the vehicle 20. The processing of step S146 is the same as the processing of step S104 in the first embodiment. After that, the execution device 71 proceeds to step S147.

[0200] In step S147, the execution device 71 allows a completion notification M33 of the key track request D33 to be sent to the specific device 30X. The process of step S147 is the same as the process of step S104 in the first embodiment. Thereafter, the execution device 71 ends this series of processes.

[0201] Meanwhile, when the executing device 71 determines that the first digital key K1 is not registered for the specific device 30X (S102: NO), the executing device 71 proceeds to step S145. Therefore, the monitoring unit 70M allows the second digital key K2 to be registered by the processes of steps S145 to S147. As a result, the monitoring unit 70M proceeds with the process related to the registration of the second digital key K2 in accordance with the key track request D33 for the second digital key K2, thereby bringing the second digital key K2 into a registered state. After the executing device 71 performs the process of step S147, the executing device 71 ends this series of processes.

[0202] <Operation of the Fourth Embodiment> In the fourth embodiment, when the first digital key K1 is registered and the second digital key K2 is newly registered, the first digital key K1 is designated as the excluded digital key KR and the second digital key K2 is designated as the permitted digital key KP. Therefore, the management system 10 makes the second digital key K2 available for use in place of the first digital key K1, which is already available for use.

[0203] <Effects of the Fourth Embodiment> According to the fourth embodiment, in addition to the effects (1-1), (1-2), and (1-6) of the first embodiment, the following effects can be achieved.

[0204] (4-1) The monitoring unit 70M causes the specific device 30X to have no first key information DK1 stored therein. The monitoring unit 70M causes the specific device 30X to have the second key information DK2 stored therein. Therefore, the monitoring unit 70M causes the specific device 30X to have the new second key information DK2 stored therein, instead of the first key information DK1 already stored therein. Therefore, the specific device 30X and the vehicle 20 can use the second digital key K2 for which registration has been newly requested.

[0205] (4-2) The monitoring unit 70M transmits a deletion request D66 for the first key information DK1 to the specific device 30X regardless of whether the first digital key K1 is in a fade-out state. Therefore, even if the specified condition RC is not satisfied, the monitoring unit 70M causes the specific device 30X to delete the first key information DK1, thereby causing the specific device 30X to enter a state in which the first key information DK1 is not stored. Therefore, even if the specified condition RC continues to be unsatisfied, the management system 10 can prevent the specific device 30X from continuing to store both the first key information DK1 and the second key information DK2.

[0206] (Fifth embodiment) A fifth embodiment of the management system will be described below with reference to the drawings. The fifth embodiment differs from the fourth embodiment in the processing performed when the first digital key K1 is in a fade-out state. The following description will focus on the differences from the fourth embodiment, and the same descriptions will be simplified or omitted for the same points.

[0207] <Monitoring control of the monitoring unit> 15, when the execution device 71 starts execution of the monitoring program PM in the fifth embodiment, it first performs the processing of step S101. The processing of steps S101 and S102 is the same as that in the fourth embodiment, and therefore detailed description thereof will be omitted.

[0208] When the execution device 71 determines that the first digital key K1 is registered for the specific device 30X (S102: YES), the execution device 71 advances the process to step S151.

[0209] In step S151, the execution device 71 determines whether the first digital key K1 is managed in a fade-out state. The process of step S151 is the same as the process of step S116 in the first embodiment.

[0210] If the first digital key K1 is in the fade-out state (S151: YES), the execution unit 71 proceeds to step S152. In step S152, the execution unit 71 determines whether or not a prescribed condition RC is satisfied.

[0211] If the specified condition RC is not satisfied (S152: NO), the execution device 71 repeats the process of step S152. On the other hand, if the specified condition RC is satisfied (S152: YES), the execution device 71 proceeds to step S144. The processes of steps S144 to S147 are the same as those in the fourth embodiment, and therefore detailed explanations will be omitted. After the execution device 71 performs the process of step S147, the execution device 71 ends the current series of processes.

[0212] Meanwhile, when the first digital key K1 is not in the fade-out state (S151: NO), the execution device 71 proceeds to step S141. The processes of steps S141 to S143 are the same as those of the fourth embodiment, and therefore detailed description thereof will be omitted. After the execution device 71 performs step S143, the execution device 71 proceeds to step S144.

[0213] <Actions and Effects of Fifth Embodiment> According to the fifth embodiment, in addition to the effects (1-1), (1-2), and (1-6) of the first embodiment and the effect (4-1) of the fourth embodiment, the following effect can be achieved.

[0214] (5-1) When the first digital key K1 is in a fade-out state, the monitoring unit 70M determines whether the specified condition RC is satisfied. When the specified condition RC is satisfied, the management server 70 generates a deletion request D42 for the first key information DK1 in accordance with the reservation deletion request D41. The management server 70 then transmits the deletion request D42 to the specific device 30X. Therefore, when the first digital key K1 is in a fade-out state, the first key information DK1 is deleted from the specific device 30X by the series of processes shown in FIG. 8. Therefore, when the function of the monitoring unit 70M is added to the series of processes shown in FIG. 8, the monitoring unit 70M does not need to perform any additional processing.

[0215] (Sixth embodiment) A sixth embodiment of the management system will be described below with reference to the drawings. The sixth embodiment differs from the first embodiment in that the vehicle management device 26 of the vehicle 20 has a monitoring unit 20M. The following description will focus on the differences from the first embodiment, and descriptions of the same points will be simplified or omitted.

[0216] <Monitoring control of the monitoring unit> 16, the storage device 28 stores a monitoring program PM6 according to the sixth embodiment. The monitoring program PM6 is a program for realizing a monitoring unit 20M in the vehicle 20.

[0217] 17, the execution device 27 executes the monitoring program PM6, causing the execution device 27 to function as a monitoring unit 20M. Therefore, in the sixth embodiment, the vehicle 20 includes the monitoring unit 20M.

[0218] The execution device 27 starts execution of the monitoring program PM6 when it receives the authentication package ATP and storage request D34 for the second digital key K2. When it receives the authentication package ATP and storage request D34 for the second digital key K2, the execution device 27 detects that registration of the second digital key K2 is requested in the management system 10.

[0219] 18, when the execution device 27 starts executing the monitoring program PM6, it first performs the processing of step S161. In step S161, the execution device 27 identifies a specific device 30X, which is the device 30 for which the second digital key K2 is to be registered. In the sixth embodiment, information identifying the device 30 in which the second key information DK2 is registered is added to the authentication package ATP. In this case, the execution device 27 identifies the specific device 30X based on the added information identifying the device 30. Then, the execution device 27 proceeds to step S162.

[0220] In step S162, the execution device 27 determines whether the first digital key K1 has already been registered for the specific device 30X. Specifically, the execution device 27 determines whether the information identifying the device 30, which is added to the authentication package ATP in the authentication information AT stored in the storage device 28, is the specific device 30X.

[0221] When the execution unit 27 determines that the first digital key K1 is not registered for the specific device 30X (S162: NO), the execution unit 27 proceeds to step S163.

[0222] In step S163, the execution device 27 permits the storage of the second authentication information AT2. Accordingly, the execution device 27 stores the authentication package ATP of the second digital key K2 as the second authentication information AT2 in accordance with the storage request D34. That is, the monitoring unit 20M causes the vehicle management device 26 to store the second authentication information AT2. Thereafter, the execution device 27 ends this series of processes.

[0223] On the other hand, when the execution device 27 determines that the first digital key K1 is registered for the specific device 30X (S162: YES), the execution device 27 proceeds to step S164.

[0224] In step S164, the execution device 27 refuses to store the second authentication information AT2. As a result, the execution device 27 does not store the second authentication information AT2 in accordance with the storage request D34. In other words, the monitoring unit 20M causes the vehicle management device 26 to enter a state in which the second authentication information AT2 is not stored. Thereafter, the execution device 27 proceeds to step S165.

[0225] In step S165, the execution device 27 transmits a notification M71 to the management server 70 indicating that the storage request D34 cannot be fulfilled. Upon receiving the notification M71, the management server 70 transmits notifications indicating that the key track request D33 cannot be fulfilled to the specific device 30X that transmitted the key track request D33 and to the friend device 51 that transmitted the registration request D31 to the specific device 30X. The execution device 27 then proceeds to step S166.

[0226] In step S166, the execution device 27 transmits a deletion request D67 to the specific device 30X, requesting deletion of the second key information DK2. Upon receiving the deletion request D67, the specific device 30X deletes the second key information DK2. That is, the monitoring unit 20M causes the specific device 30X to enter a state in which the second key information DK2 is not stored. Thereafter, the execution device 27 proceeds to step S167.

[0227] In step S167, the execution device 27 transmits a deletion request D68 to the management server 70, requesting that the second digital key K2 be deleted from the database DB. Upon receiving the deletion request D68, the management server 70 deletes the second digital key K2 from the database DB. That is, the monitoring unit 20M causes the management server 70 to delete from the database DB information indicating the specific device 30X as the shared device 50 in which the second digital key K2 is registered. Thereafter, the execution device 27 ends this series of processes. Note that by not deleting the first authentication information AT1, the execution device 27 keeps the first authentication information AT1 stored.

[0228] <Actions and Effects of the Sixth Embodiment> According to the sixth embodiment, in addition to the effects (1-1), (1-3), and (1-6) of the first embodiment and the effect (2-2) of the second embodiment, the following effect can be achieved.

[0229] (6-1) In the sixth embodiment, the vehicle management device 26 of the vehicle 20 has a monitoring unit 20M. Therefore, the monitoring unit 20M performs processing based on information stored in the storage device 28. Therefore, the monitoring unit 20M can use the information stored in the vehicle 20 to cause the second key information DK2 to be stored in an unstored state.

[0230] (Seventh embodiment) A seventh embodiment of the management system will be described below with reference to the drawings. The seventh embodiment differs from the first embodiment in that the non-friend device 52 has a monitoring unit 52M. The following description will focus on the differences from the first embodiment, and descriptions of the same points will be simplified or omitted.

[0231] <Monitoring control of the monitoring unit> 19, the storage device 37 of the non-friend device 52 stores a monitoring program PM7 in the seventh embodiment. The monitoring program PM7 is a program for realizing a monitoring unit 52M 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.

[0232] 20, the execution device 36N executes the monitoring program PM7, causing the execution device 36N to function as a monitoring unit 52M. Therefore, in the sixth embodiment, the non-friend device 52 has the monitoring unit 52M. In other words, the shared device 50 has the monitoring unit 52M.

[0233] The execution device 36N starts execution of the monitoring program PM7 when it generates unsigned non-friend key information DKNN for the second digital key K2. When the execution device 36N generates the unsigned non-friend key information DKNN, it detects that registration of the second digital key K2 is requested in the management system 10.

[0234] As shown in FIG. 21, when the execution device 36N starts executing the monitoring program PM7, it first performs the process of step S171. In step S171, the execution device 36N determines whether the first digital key K1 is registered. Specifically, the execution device 36N determines whether the first key information DK1 is already stored in the storage device 37N. In more detail, the execution device 36N first references the key information DK stored in the storage device 37N. Next, the execution device 36N determines whether the vehicle identification information ST1 included in the key information DK is the same as the vehicle identification information ST1 included in the unsigned non-friend key information DKNN of the second digital key K2.

[0235] When the execution device 36N determines that the first digital key K1 is not registered (S171: NO), the execution device 36N advances the process to step S172. In step S172, the execution device 36N allows the transmission of the completion notification M31 and the signature request D32. As a result, the execution device 36N proceeds with the process following the process of step S44 shown in FIG. 7. As a result, the monitoring unit 52M causes the vehicle administration device 26 to store the second authentication information AT2. As shown in FIG. 19, the execution device 36N then ends this series of processes.

[0236] On the other hand, when the execution device 36N determines that the first digital key K1 is registered (S171: YES), the execution device 36N advances the process to step S173. In step S173, the execution device 36N refuses to send the completion notification M31 and the signature request D32. As a result, the execution device 36N does not allow the processing subsequent to step S44 shown in FIG. 7 to proceed. As a result, the monitoring unit 52M does not allow the specific device 30X to acquire the second key information DK2. As a result, the monitoring unit 52M causes the specific device 30X to not store the second key information DK2. Furthermore, the monitoring unit 52M does not allow the management server 70 to acquire the second key information DK2. As a result, the monitoring unit 52M does not cause the management server 70 to store information indicating the specific device 30X as a shared device 50 in which the second digital key K2 is registered in the database DB. Furthermore, the monitoring unit 52M does not allow the vehicle 20 to acquire the storage request D34 and the authentication package ATP. As a result, the monitoring unit 52M causes the vehicle management device 26 to not store the second authentication information AT2. Thereafter, the execution unit 36N advances the process to step S174.

[0237] In step S174, the execution device 36N transmits a notification M81 indicating that the second key information DK2 cannot be stored to the friend device 51 that generated the registration request D31 for the second digital key K2. Then, the execution device 36N ends this series of processes.

[0238] <Operation of Seventh Embodiment> 7, the friend device 51 performs the processes from step S45 onward, causing the non-friend device 52 to register the second key information DK2 in step S47. Then, the management server 70 performs registration management of the second digital key K2 in step S49, thereby registering the second digital key K2 as the non-friend device 52 in the database DB. Then, the vehicle 20 stores the authentication package ATP as second authentication information AT2 in step S50.

[0239] However, as shown in FIG. 21 , when the execution device 36N performs the processes of steps S173 and S174, the friend device 51 that generated the registration request D31 for the second digital key K2 does not perform the process subsequent to step S44. As a result, the management system 10 does not proceed with the subsequent processes. That is, by not performing the process of step S47, the non-friend device 52 does not store the second key information DK2. As a result, the monitoring unit 52M can prevent the non-friend device 52 from storing the second key information DK2. Furthermore, by not performing the process of step S49, the management server 70 does not store the non-friend device 52, including the execution device 36N, as a non-friend device 52 for the second digital key K2. Furthermore, the vehicle 20 does not store the second authentication information AT2. As a result, the monitoring unit 52M can prevent the vehicle 20 from storing the second authentication information AT2.

[0240] <Effects of the Seventh Embodiment> According to the seventh embodiment, in addition to the effects (1-1), (1-3), and (1-6) of the first embodiment, the following effects can be achieved.

[0241] (7-1) In the seventh embodiment, the non-friend device 52 has a monitoring unit 52M. Therefore, the monitoring unit 52M performs processing based on information stored in the storage device 37N. Therefore, the monitoring unit 52M can use the information stored in the non-friend device 52 to cause the non-friend device 52 to enter a state in which the second key information DK2 is not stored.

[0242] In particular, in the seventh embodiment, in the processing flow of the management system 10 shown in Fig. 7, the non-friend device 52 can detect that registration of the second digital key K2 has been requested after the friend device 51 has generated the registration request D31 for the second digital key K2. Therefore, the monitoring unit 52M performs processing midway through the series of processes of the management system 10 shown in Fig. 7, thereby preventing the management system 10 from performing subsequent processes. As a result, the monitoring unit 52M can prevent the non-friend device 52 from storing the second key information DK2 in the first place.

[0243] (Eighth embodiment) An eighth embodiment of the management system will be described below with reference to the drawings. The eighth embodiment differs from the first embodiment in that the owner device 40 has a monitoring unit 40M. The following description will focus on the differences from the first embodiment, and descriptions of the same points will be simplified or omitted.

[0244] In the eighth embodiment, after the processing of step S49 shown in FIG. 7, the management server 70 transmits a completion notification M33 to the owner device 40 in addition to the third device 30C. The management server 70 transmits information for identifying the non-friend device 52 to the owner device 40 along with the completion notification M33. Therefore, the owner device 40 receives a notification that the key track request for all shared keys KS of the target vehicle 20 has been completed.

[0245] 8, the management server 70 transmits a completion notification M44 to the owner device 40 in addition to the friend device 51. After the processing of step S82 shown in FIG. 9, the management server 70 transmits a completion notification M52 to the owner device 40 in addition to the friend device 51.

[0246] <Monitoring control of the monitoring unit> 22, the storage device 37 of the owner device 40 stores a monitoring program PM8 according to the eighth embodiment. In the following, the execution device 36 of the owner device 40 will be referred to as the execution device 36O. The storage device 37 of the owner device 40 will be referred to as the storage device 37O.

[0247] 23, the execution device 36O executes the monitoring program PM8 in the eighth embodiment, causing the execution device 36O to function as a monitoring unit 40M. Therefore, in the eighth embodiment, the owner device 40 has the monitoring unit 40M.

[0248] The execution device 36O starts execution of the monitoring program PM8 when it receives a completion notification M33 for the first digital key K1 for the target vehicle 20 and then receives a completion notification M33 for the second digital key K2 for the same vehicle 20. When the execution device 36O receives the completion notification M33 for the second digital key K2, it detects that the management system 10 is requesting registration of the second digital key K2.

[0249] 24, when the execution device 36O starts executing the monitoring program PM8, it first performs the processing of step S181. In step S181, the execution device 36O identifies the specific device 30X that stores the second key information DK2. Specifically, the execution device 36O identifies the specific device 30X by referring to information that identifies the non-friend device 52 that was acquired together with the completion notification M33 of the second digital key K2. Then, the execution device 36O proceeds to the processing of step S182.

[0250] In step S182, the execution device 36O determines whether the first digital key K1 has been deleted in the management system 10. Specifically, the execution device 36O determines whether the completion notification M44 or the completion notification M52 for the first digital key K1 has been acquired.

[0251] If the first digital key K1 has been deleted from the management system 10 (S182: YES), the execution device 36O ends the current series of processes. On the other hand, if the first digital key K1 has not been deleted from the management system 10 (S182: NO), the execution device 36O proceeds to step S183.

[0252] In step S183, the execution device 36O transmits a deletion request D71 to the vehicle 20, requesting deletion of the second authentication information AT2. Upon receiving the deletion request D71, the vehicle 20 deletes the second authentication information AT2. This causes the monitoring unit 40M to cause the vehicle management device 26 to no longer store the second authentication information AT2. The execution device 36O then proceeds to step S184.

[0253] In step S184, the execution device 36O transmits a deletion request D72 to the non-friend device 52, requesting deletion of the second key information DK2. The specific device 30X, which is a non-friend device 52 that receives the deletion request D72, deletes the second key information DK2. This causes the monitoring unit 40M to cause the specific device 30X to no longer store the second key information DK2. The execution device 36O then proceeds to step S185.

[0254] In step S185, the execution device 36O transmits a deletion request D73 to the management server 70, requesting that the second digital key K2 be deleted from the database DB. Upon receiving the deletion request D73, the management server 70 deletes from the database DB the information indicating the specific device 30X as the non-friend device 52 of the second digital key K2. As a result, the monitoring unit 40M causes the management server 70 to no longer store information indicating the specific device 30X as the shared device 50 in which the second digital key K2 is registered. The execution device 36O then terminates this series of processes.

[0255] <Actions and Effects of Eighth Embodiment> According to the eighth embodiment, in addition to the effects (1-1), (1-3), and (1-6) of the first embodiment, the following effects can be achieved.

[0256] (8-1) In the eighth embodiment, the owner device 40 has a monitoring unit 40M. Therefore, the monitoring unit 40M performs processing based on information acquired by the owner device 40. Therefore, the monitoring unit 40M can use the information acquired by the owner device 40 to cause the specific device 30X to not store the second key information DK2.

[0257] In particular, in the eighth embodiment, in the processing flow of the management system 10 shown in FIG. 7, the owner device 40 receives a completion notification M33 indicating that a series of processes has been completed. Therefore, the owner device 40 can recognize that various information has been stored as a result of each process of the management system 10 shown in FIG. 7. Therefore, after the owner device 40 recognizes that the first digital key K1 and the second digital key K2 are registered, the owner device 40 deletes the second key information DK2. As a result, the monitoring unit 40M can cause the specific device 30X to no longer store the second key information DK2.

[0258] (Ninth embodiment) A ninth embodiment of the management system will be described below with reference to the drawings. The ninth embodiment differs from the third embodiment in that it determines which of the first digital key K1 and the second digital key K2 is the permitted digital key KP and which is the excluded digital key KR. The following will focus on the differences from the third embodiment, and explanations of the same points will be simplified or omitted. Note that the following will be described using an example in which both the first digital key K1 and the second digital key K2 are shared keys KS.

[0259] <Monitoring control of the monitoring unit> In the ninth embodiment, the execution device 71 repeatedly executes the monitoring program PM in the ninth embodiment at predetermined regular intervals. The regular interval is, for example, one day. The storage device 72 stores information indicating predetermined priorities. The priorities are used to select a digital key to be an allowed digital key KP from among the first digital key K1 and the second digital key K2. Therefore, when selecting an allowed digital key KP, the execution device 71 selects a digital key with a high priority.

[0260] In the information indicating the priority order, the owner key KO has a higher priority than the friend key KF in terms of the type of digital key. Also, in the information indicating the priority order, the friend key KF has a higher priority than the non-friend key KN. Also, in the information indicating the priority order, when the digital keys are of the same type, the digital key whose registration is requested later has a higher priority than the digital key whose registration is requested earlier. In other words, when the type of the first digital key K1 is the same as the type of the second digital key K2, the second digital key K2 has a higher priority than the first digital key K1.

[0261] 25, when the execution device 71 starts executing the monitoring program PM, it first performs the processing of step S191. In step S191, the execution device 71 determines whether the first digital key K1 and the second digital key K2 are registered. Specifically, the execution device 71 refers to the database DB and determines whether the same specific device 30X for the target vehicle 20 is registered as the device 30 in which the first digital key K1 is registered and the device 30 in which the second digital key K2 is registered.

[0262] If the first digital key K1 and the second digital key K2 are not registered (S191: NO), the execution device 71 ends the current series of processes. On the other hand, if the first digital key K1 and the second digital key K2 are registered (S191: YES), the execution device 71 proceeds to step S192.

[0263] In step S192, the execution device 71 determines whether the first digital key K1 is a friend key KF. Specifically, the execution device 71 refers to the database DB to determine whether the specific device 30X is registered as a friend device 51 for the target vehicle 20.

[0264] If the first digital key K1 is the friend key KF (S192: YES), the execution device 71 proceeds to step S193. In step S193, the execution device 71 determines whether the second digital key K2 is the friend key KF. Specifically, the execution device 71 refers to the database DB to determine whether the specific device 30X is registered as a friend device 51 for the target vehicle 20.

[0265] If the second digital key K2 is the friend key KF (S193: YES), the execution device 71 proceeds to step S194. In step S194, the execution device 71 selects the first digital key K1 as the excluded digital key KR. Then, the execution device 71 proceeds to step S195.

[0266] In step S195, the execution device 71 selects the second digital key K2 as the allowed digital key KP. In this way, through the processes of steps S194 and S195, the execution device 71 selects the allowed digital key KP and the excluded digital key KR in accordance with the priority of whether registration has been requested first. Thereafter, the execution device 71 proceeds to step S196.

[0267] In step S196, the executing device 71 performs a first control. In the first control, the executing device 71 transmits a request to delete the first authentication information AT1 to the vehicle 20. In the first control, the executing device 71 transmits a request to delete the first key information DK1 to the specific device 30X that stores the first key information DK1. In the first control, the executing device 71 deletes information indicating the specific device 30X as the shared device 50 in which the first digital key K1 is registered from the database DB. On the other hand, in the first control, the executing device 71 does not transmit a request to delete the second authentication information AT2 to the vehicle 20. In the first control, the executing device 71 transmits a request to delete the second key information DK2 to the specific device 30X in which the second key information DK2 is registered. In the first control, the executing device 71 does not delete information indicating the specific device 30X as the shared device 50 in which the second digital key K2 is registered from the database DB. Thereafter, the execution unit 71 ends the current series of processes.

[0268] On the other hand, if the second digital key K2 is not the friend key KF (S193: NO), the execution device 71 proceeds to step S197. In step S197, the execution device 71 selects the first digital key K1 as the allowed digital key KP. Thereafter, the execution device 71 proceeds to step S198.

[0269] In step S198, the execution device 71 selects the second digital key K2 as the excluded digital key KR. In this way, the execution device 71 selects the allowed digital keys KP and the excluded digital keys KR in accordance with the priority order based on the type of digital key through the processes of steps S197 and S198. Thereafter, the execution device 71 proceeds to step S199.

[0270] In step S199, the executing device 71 performs a second control. In the second control, the executing device 71 transmits a request to delete the second authentication information AT2 to the vehicle 20. In the second control, the executing device 71 transmits a request to delete the second key information DK2 to the specific device 30X that stores the second key information DK2. In the second control, the executing device 71 deletes information indicating the specific device 30X as the shared device 50 in which the second digital key K2 is registered from the database DB. On the other hand, in the second control, the executing device 71 does not transmit a request to delete the first authentication information AT1 to the vehicle 20. In the second control, the executing device 71 transmits a request to delete the first key information DK1 to the specific device 30X in which the first key information DK1 is registered. In the second control, the executing device 71 does not delete information indicating the specific device 30X as the shared device 50 in which the first digital key K1 is registered from the database DB. Thereafter, the execution unit 71 ends the current series of processes.

[0271] Meanwhile, when the first digital key K1 is not the friend key KF (S192: NO), the execution device 71 proceeds to step S201. In step S201, the execution device 71 determines whether the second digital key K2 is the friend key KF.

[0272] If the second digital key K2 is the friend key KF (S201: YES), the execution device 71 proceeds to step S202. In step S202, the execution device 71 selects the first digital key K1 as the excluded digital key KR. Then, the execution device 71 proceeds to step S203.

[0273] In step S203, the execution device 71 selects the second digital key K2 as the allowed digital key KP. In this way, the execution device 71 selects the allowed digital keys KP and the excluded digital keys KR in accordance with the priority order based on the type of digital key through the processing of steps S202 and S203. Thereafter, the execution device 71 proceeds to step S204.

[0274] In step S204, the execution device 71 performs a first control. Since the first control is the same as the process in step S196, a detailed description thereof will be omitted. Thereafter, the execution device 71 ends this series of processes.

[0275] On the other hand, if the second digital key K2 is not the friend key KF (S201: NO), the execution device 71 proceeds to step S205. In step S205, the execution device 71 selects the first digital key K1 as the excluded digital key KR. Then, the execution device 71 proceeds to step S206.

[0276] In step S206, the execution device 71 selects the second digital key K2 as the allowed digital key KP. In this way, through the processes of steps S205 and S206, the execution device 71 selects the allowed digital key KP and the excluded digital key KR in accordance with the priority of whether registration has been requested first. Thereafter, the execution device 71 proceeds to step S207.

[0277] In step S207, the execution device 71 performs a first control. Since the first control is the same as the process in step S196, a detailed description thereof will be omitted. Thereafter, the execution device 71 ends this series of processes.

[0278] <Actions and Effects of the Ninth Embodiment> According to the ninth embodiment, in addition to the effects (1-1) and (1-5) of the first embodiment, the effect (2-2) of the second embodiment, and the effect (3-1) of the third embodiment, the following effect can be achieved.

[0279] (9-1) The monitoring unit 70M selects an allowed digital key KP and a rejected digital key KR from among the first digital key K1 and the second digital key K2 in accordance with a predetermined priority order. Then, the monitoring unit 70M transmits a request to delete the key information DK of the selected rejected digital key KR to the specific device 30X. As a result, the monitoring unit 70M eliminates the state in which the specific device 30X stores the key information DK of the selected rejected digital key KR. Thus, the monitoring unit 70M can select an allowed digital key KP and a rejected digital key KR in accordance with the priority order.

[0280] (9-2) The monitoring unit 70M selects an allowed digital key KP and a excluded digital key KR based on the type of the first digital key K1 and the type of the second digital key K2. When the type of the first digital key K1 is a friend key KF and the type of the second digital key K2 is a non-friend key KN, the monitoring unit 70M selects the first digital key K1 as the allowed digital key KP. Therefore, the specific device 30X can continue to use the first digital key K1 registered in response to the registration request D21 from the owner device 40.

[0281] (9-3) The monitoring unit 70M selects an allowed digital key KP and a rejected digital key KR from the first digital key K1 and the second digital key K2 based on the level of authority. In the ninth embodiment, when the type of the digital key is a friend key KF, the authority is set to be greater than when the type of the digital key is a non-friend key KN. Therefore, when one of the first digital key K1 and the second digital key K2 is a friend key KF and the other is a non-friend key KN, the monitoring unit 70M selects the friend key KF as the allowed digital key KP. Therefore, the specific device 30X can continue to use the digital key with greater authority.

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

[0283] <Management system> 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0302] The series of processes for registering a non-friend key KN is not limited to the examples in the above embodiments. The order of the processes for registering a friend key KF may be different. The series of processes for registering a non-friend key KN may be modified as appropriate to suit the structure of the information contained in the non-friend key information DKN and the structure of the information contained in the authentication information AT.

[0303] The types of digital keys do not have to include the non-friend key KN. In other words, in the management system 10, the shared key KS may only be the friend key KF. In this case, in the seventh embodiment, the friend device 51 may have the monitoring unit 52M.

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

[0305] 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 key corresponds to the owner key KO, the second key corresponds to the friend key KF, and the third key corresponds to the non-friend key KN.

[0306] 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 key may correspond to the friend key KF, the second key may correspond to the non-friend key KN, and the third key may correspond to the new non-friend key KN.

[0307] <The process for deleting a digital key> In the above embodiments, when deleting the non-friend key KN, the friend device 51 transmits a reservation deletion request D41 to the management server 70. However, this does not have to be a reservation request. That is, the friend device 51 may transmit a request to delete the non-friend key KN to the management server 70 regardless of the specified condition RC. Furthermore, the management server 70 may proceed with the processing from step S62 onward in response to a request to delete the non-friend key KN not only from the friend device 51 but also from the owner device 40.

[0308] In each of the above embodiments, the management server 70 receives the reservation deletion request D41, but the vehicle 20 may also receive the reservation deletion request D41. In this case, the vehicle 20 may determine whether the specified condition RC is met, and delete the authentication information AT when the specified condition RC is met. The vehicle 20 may then transmit a notification to the management server 70 indicating that the authentication information AT has been deleted based on the reservation deletion request D41. The management server 70 may then update the database DB and transmit a deletion request D42 to the non-friend device 52.

[0309] 8, when deleting a non-friend device 52 due to an operation on the non-friend device 52, a request to delete the non-friend key KN may be sent to the management server 70 before a completion notification M51 is sent to the management server 70. In this case, similar to the series of flows shown in FIG. 7, when the management server 70 receives the request, the management server 70 may send a request to delete the non-friend key information DKN to the non-friend device 52.

[0310] In both cases where the non-friend key KN is deleted due to operation of the friend device 51 and where the non-friend key KN is deleted due to operation of the non-friend device 52, the management server 70 may be requested to delete the reservation.

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

[0312] <Monitoring section> The first digital key K1 and the second digital key K2 do not have to be non-friend keys KN. For example, the first digital key K1 and the second digital key K2 may be friend keys KF, or one may be an owner key KO and the other a shared key KS.

[0313] In the first embodiment, the monitoring unit 70M detects that registration of the second digital key K2 is requested by the key tracking request D33, but the signal used to detect that registration of the second digital key K2 is requested is not limited to this. For example, the monitoring unit 70M may detect that registration of the second digital key K2 is requested by separately acquiring a signal indicating that registration has been requested from the friend device 51 or the third device 30C. This also applies to the other embodiments. For example, in the seventh embodiment, the monitoring unit 52M may detect that registration of the second digital key K2 is requested when the monitoring unit 52M receives a completion notification M32 for the second digital key K2. For example, in the seventh embodiment, the monitoring unit 52M may detect that registration of the second digital key K2 is requested when the monitoring unit 52M stores the second key information DK2.

[0314] In the first embodiment, the management system 10 may further include a monitoring device having a monitoring unit 70M. It is sufficient that the management system 10 includes the monitoring unit 70M. In the sixth embodiment, the monitoring unit 20M may be included in a device other than the vehicle management device 26 included in the vehicle 20. In the sixth embodiment, it is sufficient that the vehicle 20 includes the monitoring unit 20M.

[0315] In the first embodiment, the monitoring unit 70M may omit the processing of step S112. That is, the monitoring unit 70M may allow the vehicle administration device 26 to store the second authentication information AT2. The monitoring unit 70M may at least cause the specific device 30X to not store the second key information DK2. Similarly, in other embodiments, the monitoring unit may perform control to cause the specific device 30X to store one of the first key information DK1 and the second key information DK2, and not store the other key information DK.

[0316] In the ninth embodiment, when the digital keys are of the same type, the monitoring unit 70M may select the allowed digital key KP and the excluded digital key KR based on the authority. For example, as in the above-mentioned modified example, the authority is not uniformly determined according to the type of digital key, but is set for each digital key. In this case, when the first digital key K1 and the second digital key K2 are both non-friend keys KN, the monitoring unit 70M may select the digital key with the greater authority as the allowed digital key KP. Furthermore, the monitoring unit 70M does not have to select the allowed digital key KP and the excluded digital key KR based on the type of digital key.

[0317] In the ninth embodiment, as in the modified example described above, it is assumed that the database DB does not have a defined authority. In this case, the monitoring unit 70M does not need to select the permitted digital keys KP and the rejected digital keys KR based on the authority.

[0318] In the ninth embodiment, the order of priority may be determined such that the digital key that is registered first is the allowed digital key KP, or the digital key whose registration is requested last is the allowed digital key KP. That is, the monitoring unit 70M may perform the first control when the second digital key K2 is the allowed digital key KP in the manner of any of the first to third embodiments. Furthermore, the monitoring unit 70M may perform the second control when the first digital key K1 is the allowed digital key KP in the manner of any of the fourth and fifth embodiments.

[0319] In the second embodiment, the management server 70 does not need to send the prohibition request D74. In this case, if the management server 70 does not send a request to store the second key information DK2 to the specific device 30X, the specific device 30X will not store the second key information DK2. In other words, the monitoring unit 70M may cause the management server 70 to not send a request to store the second key information DK2, thereby causing the specific device 30X to not store the second key information DK2.

[0320] (Additional notes) The technical concepts that can be understood from the above-described embodiments and modifications will be described below. [Appendix 1] A management system comprising: a vehicle having a vehicle management device that stores information about digital keys; a device that stores information about the digital keys, multiple of which can be registered to the vehicle; and a management server that manages a first digital key and a second digital key for the same vehicle, wherein the management system comprises a monitoring unit that controls the device to store information about one of the first digital key and the second digital key for the same device, and not store information about the other digital key.

[0321] [Appendix 2] A management system as described in Appendix 1, wherein the monitoring unit performs the control when information about the first digital key is stored in the device, information about the second digital key is not stored in the device, and registration of the second digital key is requested.

[0322] [Appendix 3] The management system described in Appendix 2, wherein one of the first digital key and the second digital key is the first digital key, and the other of the first digital key and the second digital key is the second digital key.

[0323] [Appendix 4] In the management system described in Appendix 3, when the management server receives a reservation deletion request to delete information about the first digital key when a predetermined condition is met, the management server sends a deletion request to the vehicle, which is a request to delete information about the first digital key when the predetermined condition is met, and when the monitoring unit detects that registration of the second digital key has been requested, even if the management server receives the reservation deletion request, the control does not cause the management server to send the deletion request, thereby causing the device to store information about the first digital key.

[0324] [Appendix 5] A management system as described in Appendix 3 or Appendix 4, in which, during the control, the monitoring unit prevents the device from storing information regarding the second digital key, thereby causing the device to enter a state in which information regarding the second digital key is not stored.

[0325] [Appendix 6] The management system described in Appendix 1, wherein when information regarding the first digital key and information regarding the second digital key are stored in the device, the control includes the monitoring unit causing the device to delete information regarding the second digital key, thereby causing the device to no longer store information regarding the second digital key.

[0326] [Appendix 7] The management system described in Appendix 2, wherein one of the first digital key and the second digital key is the second digital key, and the other of the first digital key and the second digital key is the first digital key.

[0327] [Appendix 8] A management system as described in Appendix 7, in which the management server receives a reservation deletion request to delete information about the first digital key when a predetermined specified condition is met, the management server sends a deletion request to the device when the specified condition is met, which is a request to delete information about the first digital key, and the monitoring unit controls the device to store information about the second digital key in accordance with the request to register the second digital key, thereby causing the device to store information about the second digital key, and allows the management server to send the deletion request, thereby causing the device to not store information about the first digital key.

[0328] [Appendix 9] The management system described in Appendix 7, wherein when the management server receives a reservation deletion request to delete information about the first digital key when a predetermined specified condition is met, the management server sends a deletion request to the device, which is a request to delete information about the first digital key when the specified condition is met, and the monitoring unit stores information about the second digital key in the device in accordance with the request to register the second digital key, thereby causing the information about the second digital key to be stored in the vehicle, and even if the specified condition is not met, causes the management server to send the deletion request to the device, thereby causing the device to not store information about the first digital key.

[0329] [Supplementary Note 10] The management system according to any one of Supplementary Note 1 to Supplementary Note 9, wherein the management server has the monitoring unit. [Supplementary Note 11] The management system according to any one of Supplementary Note 1 to Supplementary Note 9, wherein the vehicle has the monitoring unit.

[0330] [Supplementary Note 12] The management system according to any one of Supplementary Note 1 to Supplementary Note 9, wherein the device has the monitoring unit. [Appendix 13] A management system according to any one of Appendices 1 to 9, comprising an owner device that stores information regarding an owner key that can only be registered once for the same vehicle as the digital key, and the owner device has the monitoring unit.

[0331] [Appendix 14] In the control, the monitoring unit selects, from among the first digital key and the second digital key, in accordance with a predetermined priority order, an allowed digital key for which the device will store information about the digital key and an excluded digital key for which the device will not store information about the digital key, and causes the device to store information about the allowed digital key and not store information about the excluded digital key. This is a management system described in Appendix 1 or Appendix 2.

[0332] [Appendix 15] The management system described in Appendix 14, wherein the types of the multiple digital keys include an owner key, only one of which can be registered to the same vehicle, a friend key registered based on the owner key, and a non-friend key registered based on the friend key, and when the type of the first digital key is the friend key and the type of the second digital key is the non-friend key, the monitoring unit selects the first digital key as the allowed digital key.

[0333] [Appendix 16] The management system according to Appendix 14, wherein the monitoring unit selects, as the allowed digital key, the digital key with the broader scope of authority from the first digital key and the second digital key. [Explanation of symbols]

[0334] 10...Management system 20...Vehicle 20M…Monitoring department 26...Vehicle management device 27...Execution device 28…Storage device 30…Devices 36, 36N, 36O...Execution device 37, 37N, 37O…Storage device 40...Owner device 40M…Monitoring department 50...Shared devices 51...Friend Device 52...Non-Friendly Device 52M…Monitoring department 60...Device Server 70...Administration server 70M…Monitoring department AT…Authentication information AT1...First authentication information AT2...Second authentication information DKO…Owner key information DKS…Share Key Information DK1...First key information DK2...Second key information K1...1st digital key K2: Second digital key KF...Friend Key KN...Non-Friend Key KO…Owner key KP...Permitted digital key KR…eliminate digital key KS...Share Key PM, PM6, PM7…Monitoring program RC…Specified conditions

Claims

1. a vehicle having a vehicle management device that stores information about the digital key; a device that stores information about the digital key, a plurality of which can be registered to the vehicle; a management server that manages a first digital key and a second digital key for the same vehicle, a monitoring unit that performs control so that the device stores information about one of the first digital key and the second digital key for the same device, and does not store information about the other digital key; Management system.

2. If information about the first digital key is stored on the device, information about the second digital key is not stored on the device, and registration of the second digital key is requested, The monitoring unit performs the control. The management system according to claim 1 .

3. one of the first digital key and the second digital key is the first digital key, The other of the first digital key and the second digital key is the second digital key. The management system according to claim 2 .

4. When the management server receives a reservation deletion request for deleting information about the first digital key when a predetermined condition is met, the management server transmits a deletion request to the vehicle when the predetermined condition is met, the deletion request being a request for deleting information about the first digital key; When the monitoring unit detects that registration of the second digital key is requested, even if the management server has acquired the reservation deletion request, the control unit does not cause the management server to send the deletion request, thereby causing the device to store information about the first digital key. The management system according to claim 3 .

5. In the control, the monitoring unit prevents the device from storing information about the second digital key, thereby causing the device to enter a state in which information about the second digital key is not stored. The management system according to claim 3 or 4.

6. When information about the first digital key and information about the second digital key are stored in the device, In the control, the monitoring unit causes the device to delete information related to the second digital key, thereby causing the device to enter a state in which information related to the second digital key is not stored. The management system according to claim 1 .

7. one of the first digital key and the second digital key is the second digital key; The other of the first digital key and the second digital key is the first digital key. The management system according to claim 2 .

8. When the management server receives a reservation deletion request for deleting information about the first digital key when a predetermined condition is met, the management server transmits a deletion request to the device when the predetermined condition is met, the deletion request being a request for deleting information about the first digital key; The monitoring unit In the control, storing information about the second digital key in the device in accordance with the request for registration of the second digital key, thereby causing the device to store information about the second digital key; By allowing the management server to send the deletion request, the device is put into a state where it does not store information about the first digital key. The management system according to claim 7.

9. When the management server receives a reservation deletion request for deleting information about the first digital key when a predetermined condition is met, the management server transmits a deletion request to the device when the predetermined condition is met, the deletion request being a request for deleting information about the first digital key; The monitoring unit storing information about the second digital key in the device in response to a request to register the second digital key, thereby causing information about the second digital key to be stored in the vehicle; Even if the specified condition is not met, the management server transmits the deletion request to the device, thereby causing the device to no longer store information about the first digital key. The management system according to claim 7.

10. The management server has the monitoring unit. The management system according to claim 1 .

11. The vehicle has the monitoring unit. The management system according to claim 1 .

12. The device has the monitoring unit. The management system according to claim 1 .

13. an owner device that stores information about an owner key that can be registered as the digital key to the same vehicle, and The owner device has the monitoring unit. The management system according to claim 1 .

14. In the control, the monitoring unit selecting, from the first digital key and the second digital key, an allowed digital key to be stored in the device and an excluded digital key to be not stored in the device, in accordance with a predetermined priority order; The device stores information about the permitted digital keys and does not store information about the excluded digital keys. The management system according to claim 1 or 2.

15. The types of the plurality of digital keys include an owner key, only one of which can be registered to the same vehicle, a friend key registered based on the owner key, and a non-friend key registered based on the friend key, When the type of the first digital key is the friend key and the type of the second digital key is the non-friend key, The monitoring unit selects the first digital key as the allowed digital key. The management system of claim 14.

16. The monitoring unit selects, as the permitted digital key, the digital key having a larger range of authority from the first digital key and the second digital key. The management system of claim 14.

17. A management server that manages a first digital key and a second digital key for a device that stores information about a plurality of digital keys that can be registered to a vehicle, a monitoring unit that performs control so that the device stores information about one of the first digital key and the second digital key for the same device, and does not store information about the other digital key; Management server.

18. A vehicle management device that is mounted on a vehicle and stores information about a digital key, The device stores information about the digital keys, which can be registered in plurality, and includes a monitoring unit that controls the device to store information about one of a first digital key and a second digital key for the same vehicle, and not store information about the other digital key. Vehicle management device.

19. A device for storing information about a plurality of digital keys that can be registered for a vehicle having a vehicle management device that stores information about the digital keys, The device includes a monitoring unit that performs control to store information about one of a first digital key and a second digital key for the same device and the same vehicle, and not store information about the other digital key. device.

Images