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

Abstract

A management system (10) includes a vehicle (20), a device (30), and a management server (70). A vehicle management device (26) of the vehicle (20) is configured to store information relating to a plurality of digital keys that can be registered with respect to the vehicle (20). The device (30) is configured to store information relating to the plurality of digital keys. The management server (70) is configured to manage the plurality of digital keys. The management system (10) is provided with a monitoring unit (70M). The monitoring unit (70M) is configured to perform monitoring control for causing the device (30) to be in a state of storing information relating to one of the first digital key and the second digital key, and storing information relating to the other digital key.

Description

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

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

[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 devices store 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.

[0004] JP 2024-001720 A

[0005] In a management system such as that described in Patent Document 1, a first digital key and a second digital key that can be used for the same vehicle may be registered for the same device. If both the first digital key and the second digital key are registered for the same vehicle, the device will need to store information about the unnecessary digital key, even though one of the digital keys would suffice.

[0006] In a first aspect of the present disclosure, a management system includes a vehicle having a vehicle management device configured to store information about a plurality of digital keys that can be registered to the vehicle, a device configured to store information about the plurality of digital keys, and a management server configured to manage the plurality of digital keys, wherein the plurality of digital keys include a first digital key and a second digital key, and the management system includes a monitoring unit configured to perform monitoring control to cause the device to store information about one of the first digital key and the second digital key, and not store information about the other digital key.

[0007] In a second aspect of the present disclosure, a management server is configured to manage a plurality of digital keys that can be registered to a vehicle, the plurality of digital keys including a first digital key and a second digital key that can be used by a device configured to store information about the plurality of digital keys, and the management server is equipped with a monitoring unit configured to perform monitoring control to cause the device to store information about one of the first digital key and the second digital key and not store information about the other digital key.

[0008] In a third aspect of the present disclosure, a vehicle management device is mounted on a vehicle and configured to store information regarding a plurality of digital keys that can be registered to the vehicle, wherein the plurality of digital keys include a first digital key and a second digital key that can be used by a device configured to store information regarding the plurality of digital keys, and the vehicle management device is equipped with a monitoring unit configured to perform monitoring control to cause the device to store information regarding one of the first digital key and the second digital key, and not store information regarding the other digital key.

[0009] In a fourth aspect of the present disclosure, a device is configured to store information regarding a plurality of digital keys that can be registered to a vehicle, the vehicle having a vehicle management device configured to store information regarding the plurality of digital keys, the plurality of digital keys including a first digital key and a second digital key, and a monitoring unit configured to perform monitoring control to cause the device to store information regarding one of the first digital key and the second digital key, and not store information regarding the other digital key.

[0010] FIG. 1 is a schematic diagram showing a management system of a first embodiment. FIG. 2 is a schematic diagram showing owner key information of an owner device of FIG. 1. FIG. 3 is a schematic diagram showing share key information of a share device of FIG. 1. FIG. 4 is a schematic diagram showing data in the database of FIG. 1. FIG. 5 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when an owner key is registered. FIG. 6 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a friend key is registered. FIG. 7 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a non-friend key is registered. FIG. 8 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a non-friend key is deleted in response to a request from a friend device. FIG. 9 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a non-friend key is deleted in response to a request from a non-friend device. FIG. 10 is a schematic diagram showing a monitoring unit in the management system of FIG. 1. FIG. 11 is a flowchart showing a series of processes performed by the monitoring unit of FIG. 10. FIG. 12 is a flowchart showing a series of processes performed by the monitoring unit of a second embodiment. FIG. 13 is a flowchart showing a series of processes performed by the monitoring unit of the third embodiment. FIG. 14 is a flowchart showing a series of processes performed by the monitoring unit of the fourth embodiment. FIG. 15 is a flowchart showing a series of processes performed by the monitoring unit of the fifth embodiment. FIG. 16 is a schematic diagram showing a vehicle of the sixth embodiment. FIG. 17 is a schematic diagram showing a monitoring unit in the management system of the sixth embodiment. FIG. 18 is a flowchart showing a series of processes performed by the monitoring unit of FIG. 17. FIG. 19 is a schematic diagram showing a non-friend device of the seventh embodiment. FIG. 20 is a schematic diagram showing a monitoring unit in the management system of the seventh embodiment. FIG. 21 is a flowchart showing a series of processes performed by the monitoring unit of FIG. 20. FIG. 22 is a schematic diagram showing an owner device of the eighth embodiment. FIG. 23 is a schematic diagram showing the monitoring unit in the management system of the eighth embodiment. FIG. 24 is a flowchart showing a series of processes performed by the monitoring unit of FIG. 23. FIG. 25 is a flowchart showing a series of processes performed by the monitoring unit of the ninth embodiment.

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

[0012] The vehicle 20 includes a communication module 21, an HMI 22, a BLE module 23, a UWB module 24, an NFC module 25, and a vehicle management device 26. HMI stands for Human Machine Interface. BLE stands for Bluetooth Low Energy. UWB stands for Ultra Wide Band. NFC stands for Near Field Communication.

[0013] The communication module 21 communicates with the management server 70 via a wireless communication network. The HMI 22 includes an input device that accepts operations by the user of the vehicle 20 and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

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

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

[0016] When the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the digital key to be used to control the vehicle 20. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be unlocked. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be started.

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

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

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

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

[0021] The device program PD includes, for example, a device application and a digital key framework. The device application is an application for storing and deleting key information DK. The digital key framework is a program that provides functions for pairing 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 storing and deleting key information DK.

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

[0023] 2, the owner key information DKO includes owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, in-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The owner key structure information STO also includes certificate information ST5, device public key information ST6, vehicle public key information ST7, and permission public key information ST8.

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

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

[0026] Certificate information ST5 indicates a certificate that certifies the digital key. Device public key information ST6 indicates a device public key PKD that is the public key of the device 30. 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 that is the public key of the vehicle 20. Authorization public key information ST8 indicates an already authorized vehicle public key PKV.

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

[0028] The multiple share devices 50 include a friend device 51 and a non-friend device 52. The friend device 51 stores, as the share key information DKS, friend key information DKF indicating the friend key KF. The non-friend device 52 stores, as the share key information DKS, non-friend key information DKN indicating the non-friend key KN. In other words, the types of share keys KS include a friend key KF and a non-friend key KN. The friend key KF is a share key KS registered based on a direct registration request D21 from the owner device 40, as described below. The non-friend key KN is a share key KS registered based on a registration request D31 from the friend device 51, as described below. In other words, the non-friend key KN is a share key KS registered based on an indirect registration request from a share device 50, which is a device 30 different from the owner device 40.

[0029] When a digital key is registered, the digital key is enabled for use, i.e., when the digital key is registered, the vehicle 20 stores the authentication information AT and the device 30 stores the key information DK.

[0030] As shown in Fig. 3, the shared key information DKS includes 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 also 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 the owner key structure information STO minus the device public key information ST6.

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

[0032] The signature information ATP1 indicates that the sharing device 50 is a legitimate target for sharing a digital key. For example, in the case of the friend device 51, the signature information ATP1 indicates a signature by the owner device 40. The signature information ATP1 in the case of the friend device 51 indicates that the owner device 40 has signed the device public key PKD of the friend device 51 indicated by the device public key information ATP6. For example, in the case of the non-friend device 52, the signature information ATP1 indicates a signature by the friend device 51. The signature information ATP1 in the case of the non-friend device 52 indicates that the friend device 51 has signed the device public key PKD of the non-friend device 52 indicated by the device public key information ATP6.

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

[0034] As shown in FIG. 1 , the device server 60 relays communication between the devices 30 and the management server 70. Only one device server 60 is illustrated in FIG. 1 . However, a device server 60 may be provided for each type of device 30. That is, the device server 60 with which a first type of device 30 communicates may be 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.

[0035] Each device server 60 relays communication between the corresponding device 30 and the management server 70. Different types of devices 30 can communicate with the management server 70 via the corresponding device server 60.

[0036] <Management Server> The management server 70 is configured to manage 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, which is a processing circuit, and a storage device 72. The storage device 72 stores a server program PS, a monitoring program PM, and a database DB. When the server program PS is executed by the execution device 71, the execution device 71 registers digital keys in the database DB and deletes digital keys from the database DB. Details of the monitoring program PM will be described later.

[0037] The database DB contains information associating, for each of a plurality of digital keys, the corresponding vehicle 20 with the registered device 30. The data DA contained in the database DB 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 the key information DK indicating the digital key.

[0038] As shown in Figure 4, the data DA for one vehicle 20 includes information about the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. Digital keys are divided into multiple hierarchies based on their type. From top to bottom, the hierarchy is divided into owner keys KO, friend keys KF, and non-friend keys KN. The higher the hierarchy, the greater the authority set for the digital key.

[0039] The authority may be, for example, the number of share keys KS that can be requested to be registered, the range of control of the vehicle 20 that can be achieved by authenticating the digital key, etc. The higher the hierarchical level of the digital key, 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.

[0040] For example, the higher the hierarchical level of a digital key, the wider the controllable range of the vehicle 20. The controllable range of the vehicle 20 indicates, for example, the possible controls among control of starting the engine of the vehicle 20, control of turning on the power of the vehicle 20, and control of unlocking and locking 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 control of unlocking and locking the doors of the vehicle 20. More specifically, the controllable range of the vehicle 20 that can be controlled by the friend key KF is the above-mentioned three controls, while the controllable range of the vehicle 20 that can be controlled by the non-friend key KN is only control of unlocking and locking the doors of the vehicle 20.

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

[0042] The device 30 in which the owner key KO is registered as a digital key is the first device 30A. That is, the first device 30A is the owner device 40. That is, the first key is the owner key KO.

[0043] The devices 30 in which the shared key KS is registered as a digital key are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. That is, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are shared devices 50. That is, the second key to the seventh key are all shared keys KS.

[0044] More specifically, the devices 30 in which the friend key KF is registered as the share key KS 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. The devices 30 in which the non-friend key KN is registered as the share key KS are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

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

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

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

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

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

[0051] In this way, the data DA includes information about the device 30 to which the digital key is registered. In the data DA, the registered device 30 is associated with information indicating the device 30 that made the request that caused the registration of the device 30. The data DA also includes information indicating which digital key each digital key is registered under.

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

[0053] 5, the management system 10 performs a series of processes to register the owner key KO. The following describes an example of registering the owner key KO for the first device 30A that does not store key information DK indicating the owner key KO.

[0054] By registering the owner key KO, the management system 10 causes the first device 30A to store key information DK indicating the owner key KO. By registering the owner key KO, the management system 10 causes the vehicle 20 to store authentication information AT for authenticating the owner key KO. As a result, the first device 30A is set as the owner device 40. When registering the owner key KO, necessary applications are pre-installed in the first device 30A.

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

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

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

[0058] 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 the secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. The first device 30A then receives the generation data DC. The first device 30A then proceeds to step S14.

[0059] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. Then, the first device 30A proceeds 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. Then, 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.

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

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

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

[0063] Thereafter, when the management server 70 receives the key track request D12, it 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, as data DA of the vehicle 20 in the database DB, that the device 30 in which the owner key KO is registered is the first device 30A. This causes the management system 10 to complete the series of processes for registering the owner key KO.

[0064] 6, the management system 10 performs a series of processes to register a friend key KF. Below, an example will be described in which the series of processes is used to register a friend key KF for a second device 30B that does not store friend key information DKF.

[0065] 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). Then, the owner device 40 proceeds to step S22.

[0066] In step S22, the owner device 40 obtains 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.

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

[0068] 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. The validity start time information ATP3, expiration date information ATP4, and name information ATP5 are set by the owner device 40. The second device 30B then proceeds to step S24.

[0069] In step S24, the second device 30B uses the share information SH1 to generate signature-less friend key information DKFN. The signature-less friend key information DKFN is friend key information DKF that does not include signature information ATP1. The second device 30B then transmits to the owner device 40 a completion notification M21 indicating that the generated signature-less friend key information DKFN has been uploaded to the URL link, and a signature request D22 requesting a signature.

[0070] The owner device 40 then 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.

[0071] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 causes the HMI 32 to present the acquired signature-free 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 this operation is performed, the owner device 40 generates signature information ATP1 based on the operation. The owner device 40 then proceeds to step S26.

[0072] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. This causes the owner device 40 to generate 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.

[0073] The second device 30B then receives the completion notification M22. The second device 30B then 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 is set as a friend device 51. The second device 30B then proceeds to step S28.

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

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

[0076] Specifically, the management server 70 confirms 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 shows the share keys KS, including the friend key KF and the non-friend key 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 it cannot comply with the key track request D23.

[0077] 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. Specifically, the management server 70 stores, as data DA of the vehicle 20 in the database DB, that the device 30 registered as the friend device 51 is the second device 30B. 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.

[0078] Thereafter, the management server 70 transmits the authentication package ATP included in 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 notifies the vehicle 20 that the device public key PKD has been signed by the owner device 40.

[0079] Thereafter, when the vehicle 20 receives the storage request D24 and the authentication package ATP from the management server 70, the vehicle 20 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.

[0080] 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 complete the series of processes for registering the friend key KF.

[0081] 7, the management system 10 performs a series of processes to register a non-friend key KN. Below, an example will be described in which the series of processes is used to register a non-friend key KN for a third device 30C that does not store non-friend key information DKN.

[0082] When an operation to request registration of a non-friend key KN is executed on 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). Then, the friend device 51 proceeds to the process of step S42.

[0083] In step S42, the friend device 51 obtains 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.

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

[0085] 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. The validity start time information ATP3, expiration date information ATP4, and name information ATP5 are set by the friend device 51. The third device 30C then proceeds to step S44.

[0086] 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 have the signature information ATP1. 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.

[0087] The friend device 51 then 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 the 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.

[0088] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 causes the HMI 32 to present the acquired signature-less 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 generates signature information ATP1 based on the operation. The friend device 51 then proceeds to step S46.

[0089] In step S46, the friend device 51 adds the signature information ATP1 to the unsigned non-friend key information DKNN. This causes the friend device 51 to generate non-friend key information DKN. The friend device 51 then uploads the generated non-friend key information DKN to the URL link, which is the invitation information IV2. The friend device 51 then 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.

[0090] 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 is set as a non-friend device 52. The third device 30C then proceeds to step S47.

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

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

[0093] 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 rejection list. If the non-friend key KN is on the rejection list, the management server 70 sends a notification to the third device 30C that the key track request D33 cannot be fulfilled.

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

[0095] Thereafter, the management server 70 transmits the authentication package ATP included in 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 notifies the vehicle 20 that the device public key PKD is signed by the friend device 51.

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

[0097] After completing the registration management, the management server 70 transmits a key track completion notification M33 to the second device 30B. After that, upon receiving the key track completion notification M33, the second device 30B performs the processing of step S51. In the processing 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 complete the series of processes for registering the non-friend key KN.

[0098] <Deleting a Non-Friend Key> 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. The process executed by the execution unit 71 will be described as a process executed by the management server 70.

[0099] <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 a non-friend key KN in response to a reservation deletion request D41 from a friend device 51.

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

[0101] 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 a prescribed condition RC. The prescribed condition RC is a condition required to start deletion after receiving the reservation deletion request D41. The prescribed condition RC is predetermined. For example, the prescribed condition RC is that a predetermined fade-out period has elapsed since receiving the reservation deletion request D41. The friend device 51 then transmits the reservation deletion request D41 for the non-friend key KN to the management server 70.

[0102] Thereafter, when the management server 70 receives the reservation deletion request D41 for the non-friend key KN, it 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.

[0103] Thereafter, when the friend device 51 receives the deletion 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.

[0104] 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 as a fade-out state in the database DB. The fade-out state is a state after the reservation deletion request D41 has been received and the execution of deletion is still pending. Then, the management server 70 proceeds to the process of step S65.

[0105] 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 proceeds to step S66.

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

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

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

[0109] 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 target of the reservation deletion request D41. The management server 70 then transmits the deletion request D43 to the vehicle 20.

[0110] Thereafter, when the vehicle 20 receives the deletion request D43, the vehicle 20 performs the processing of step S70. In step S70, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN that is the 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 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.

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

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

[0113] 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 information indicating that the deletion of the non-friend key KN, which is the target of the reservation deletion request D41, has been completed to the HMI 32. For example, the friend device 51 displays an image indicating the completion of the deletion of the non-friend key KN on the HMI 32. Thereafter, the management system 10 ends the series of processes for the deletion of the current non-friend key KN.

[0114] <Deletion of a non-friend key due to a deletion operation on a non-friend device> As shown in Figure 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 on the non-friend device 52.

[0115] 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 completion notification M51 indicating that the deletion of the non-friend key information DKN has been completed to the management server 70.

[0116] 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 completion notification M52 to the friend device 51, indicating that the deletion of the non-friend key information DKN has been completed.

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

[0118] After processing in step S82, the management server 70 performs processing in 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. The management server 70 then transmits the deletion request D51 to the vehicle 20.

[0119] 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 deleted in the processing of step S81 in accordance with the deletion request D51. The vehicle 20 then transmits to the management server 70 a completion notification M53 indicating that the deletion of the authentication information AT in accordance with the deletion request D51 has been completed.

[0120] 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 deleted in step S81. Thereafter, the management server 70 proceeds to the process of step S87.

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

[0122] <Monitoring Control of Monitoring Unit> Next, a description will be given of the control in the management system 10 for preventing multiple digital keys that can be used for the same vehicle 20 from being registered in the same device 30.

[0123] 1, in the management server 70, a storage device 72 stores a monitoring program PM. The monitoring program PM causes an execution device 71 to execute a series of processes, thereby causing the execution device 71 to function as a monitoring unit 70M.

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

[0125] The monitoring unit 70M performs control to avoid or resolve a situation in which multiple digital keys usable 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 a excluded digital key KR that is not allowed to be registered. 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.

[0126] In the monitoring control of the monitoring unit 70M, the monitoring unit 70M causes the vehicle management device 26 to be in a state in which information about the permitted digital keys KP is stored and information about the rejected digital keys KR is not stored.

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

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

[0129] The monitoring unit 70M changes the data DA of the vehicle 20 in the database DB to a state in which the device 30 to which the permitted digital key KP is registered is stored. The monitoring unit 70M changes the data DA of the vehicle 20 in the database DB to a state in which the device 30 to which the excluded digital key KR is registered is not stored. In this way, the monitoring unit 70M avoids or eliminates a state in which multiple digital keys usable for the same vehicle 20 are registered to the same device 30.

[0130] Specifically, the execution device 71 starts execution of the monitoring program PM when it receives the 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.

[0131] 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 referencing the identification information indicating the source device 30. Then, the execution device 71 proceeds to the processing of step S102.

[0132] 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 references the database DB to determine whether the data DA of the target vehicle 20 includes information indicating the specific device 30X as a device 30 having the first digital key K1.

[0133] If the data DA of the target vehicle 20 includes information identifying the 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.

[0134] On the other hand, if the data DA of the target vehicle 20 does not include information identifying the specific device 30X, 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.

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

[0136] 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 to which the second digital key K2 is registered. As a result, the monitoring unit 70M does not prevent the management server 70 from registering the second digital key K2 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 to which the second digital key K2, which is a non-friend key KN, is registered. Then, the execution device 71 proceeds to step S104.

[0137] In step S104, the execution device 71 allows the authentication package ATP and storage request D34 for the second digital key K2 to be sent to the vehicle 20. This prevents the monitoring unit 70M from preventing the management server 70 from sending the authentication package ATP and storage request D34 for the second digital key K2 to the vehicle 20. The execution device 71 transmits the authentication package ATP and storage request D34 for 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 for the second digital key K2 as second authentication information AT2. The second authentication information AT2 is the authentication information AT for the second digital key K2. The execution device 71 then proceeds to step S105.

[0138] In step S105, the execution device 71 allows the transmission of the completion notification M33. As a result, the monitoring unit 70M does not prevent the transmission of the completion notification M33 to the management server 70. The execution device 71 then terminates 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.

[0139] 11 , 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 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 rejected digital key KR.

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

[0141] In other words, the monitoring unit 70M does not cause 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 to 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 to which the second digital key K2 is registered. Thereafter, the execution device 71 proceeds to step S112.

[0142] In step S112, the execution device 71 refuses to send the authentication package ATP and storage request D34 for 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 for the second digital key K2 to the vehicle 20.

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

[0144] 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 sent to the specific device 30X, causing the specific device 30X to delete the stored second key information DK2.

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

[0146] 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. The executing device 71 then proceeds to step S115.

[0147] 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 satisfied. As a result, the executing device 71 sends a notification indicating that the key track request D33 cannot be satisfied to the specific device 30X, instead of the completion notification M33. Thereafter, the executing device 71 proceeds to step S116.

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

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

[0150] In other words, if the specified condition RC is not satisfied, the monitoring unit 70M does not cause the management server 70 to send the deletion request D42, even if the specified condition RC is subsequently satisfied. In other words, even if the management server 70 receives the reservation deletion request D41, the monitoring unit 70M does not cause the management server 70 to send the deletion request D42. As a result, the monitoring unit 70M causes the specific device 30X to be registered with the first digital key K1. Specifically, the monitoring unit 70M causes the specific device 30X to be stored with the first key information DK1, which is the key information DK of the first digital key K1. The monitoring unit 70M causes the vehicle 20 to be stored with the first authentication information AT1. The monitoring unit 70M causes the management server 70 to store the specific device 30X as a shared device 50 with the first digital key K1 registered. After that, the execution device 71 ends this series of processes.

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

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

[0153] Here, it is assumed that the first digital key K1 is registered to the specific device 30X based on a registration request from the second device 30B, which is the friend device 51. The third device 30C is unaware that the first digital key K1 has been registered to 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.

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

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

[0156] The monitoring unit 70M does not cause the management server 70 to store the specific device 30X as a shared device 50 to 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 to which the second digital key K2 is registered.

[0157] 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 in which the second authentication information AT2 is not stored.

[0158] Advantages 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 prevent the specific device 30X from continuing to store both the first key information DK1 and the second key information DK2.

[0159] (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.

[0160] (1-3) The monitoring unit 70M selects the permitted digital key KP as the first digital key K1. The monitoring unit 70M selects the excluded digital key KR as the second digital key K2. Therefore, the monitoring unit 70M can prevent the specific device 30X from registering the second digital key K2, for which registration is requested, while the first digital key K1 is already registered. Therefore, the specific device 30X can continue to use the already registered first digital key K1.

[0161] (1-4) After receiving the reservation deletion request D41, the management server 70 sends 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, the monitoring unit 70M 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 continue to store the first key information DK1.

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

[0163] (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 achieve the effect of (1-1) by applying the present invention.

[0164] 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 specific device 30X from storing the second key information DK2. 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. Steps S121 to S124 are performed instead of steps S111 to S113. 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.

[0165] 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 in the first embodiment, and therefore detailed description thereof will be omitted.

[0166] 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 proceeds to step S121.

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

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

[0169] In step S123, the execution device 71 allows the authentication package ATP for 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. After that, the execution device 71 proceeds to step S124.

[0170] 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. The executing device 71 then proceeds to step S114. The processes of steps S114 to S115 are the same as those in the first embodiment, and therefore detailed description thereof will be omitted. 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.

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

[0172] <Operation of Second Embodiment> In the second embodiment, unlike the first embodiment, even when the second digital key K2 is not registered, the execution device 71 allows the second digital key K2 to be registered in the database DB through the process of step S122. Even when the second digital key K2 is not registered, the execution device 71 allows the authentication package ATP and storage request D34 of the second digital key K2 to be transmitted to the vehicle 20 through the process of step S123. Therefore, when the execution device 71 receives the key track request D33 for the second digital key K2, it performs the process of step S49 of the series of processes shown in FIG. 7 and the subsequent process of transmitting the authentication package ATP and storage request D34.

[0173] However, in the second embodiment, the execution device 71 transmits the prohibition request D62 to the vehicle 20 by the process 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.

[0174] 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 processing of step S124.

[0175] <Effects of 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 effects can be achieved.

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

[0177] (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 management server 70 to return to a state in which information indicating the specific device 30X as a shared device 50 in which the second digital key K2 is registered is no longer stored in the database DB. In other words, the management system 10 can prevent the management server 70 from continuing to store information indicating the specific device 30X as a non-friend device 52 of the second digital key K2.

[0178] Third Embodiment A third embodiment of the management system will now be described with reference to the drawings. In the third embodiment, the timing at which the execution device 71 executes the monitoring program PM differs from that of the first embodiment. In the third embodiment, some of the processing performed by the monitoring unit 70M differs from that of 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. The following description will focus on the differences from the first embodiment, and the same points will be simplified or omitted.

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

[0180] 13 , when the execution device 71 starts executing the monitoring program PM, it first performs the process 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 references 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.

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

[0182] In step S132, the execution device 71 transmits a deletion request D63 requesting deletion of the second authentication information AT2 to the vehicle 20. 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.

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

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

[0185] <Operation of the Third Embodiment> In the third embodiment, unlike the first embodiment, when the execution device 71 starts a series of processes, the second digital key K2 is also 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.

[0186] The monitoring unit 70M then transmits a deletion request D63 for the second authentication information AT2 to the vehicle 20. The monitoring unit 70M then 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 the non-friend device 52 for the second digital key K2 from the database DB.

[0187] <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 effects can be achieved.

[0188] (3-1) By sending a 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 enter a state in which the second key information DK2 is not stored. In other words, even if the specific device 30X once enters a state in which the first key information DK1 and the second key information DK2 are stored, 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.

[0189] 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 executed in accordance with the monitoring program PM is performed at a different timing from the series of processing shown in Fig. 7. Therefore, it is easy to introduce the 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.

[0190] (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 descriptions of the same points will be simplified or omitted.

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

[0192] 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 proceeds to step S141.

[0193] 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 enter a state in which the first authentication information AT1 is not stored. 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.

[0194] In step S142, the execution device 71 transmits a deletion request D66 to the specific device 30X, requesting that the first key information DK1 be deleted. 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.

[0195] In step S143, the executing 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 store no information indicating the specific device 30X as the device 30 to which the first digital key K1 is registered. Thereafter, the executing device 71 proceeds to step S144.

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

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

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

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

[0200] However, 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 specific device 30X to enter a state in which the second digital key K2 is registered by performing steps S145 to S147. As a result, the monitoring unit 70M proceeds with the registration process for the second digital key K2 in accordance with the key track request D33 for the second digital key K2, thereby placing the specific device 30X in a state in which the second digital key K2 is registered. After the executing device 71 performs step S147, the executing device 71 terminates this series of processes.

[0201] In the fourth embodiment, when the first digital key K1 is registered and the second digital key K2 is newly registered in the specific device 30X, the management system 10 sets the first digital key K1 to the excluded digital key KR and the second digital key K2 to the permitted digital key KP. Therefore, the management system 10 sets the specific device 30X to a state in which the second digital key K2 can be newly used in place of the first digital key K1, which is already available.

[0202] <Effects of 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.

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

[0204] (4-2) The monitoring unit 70M sends 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, 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 even if the specified condition RC continues to be unsatisfied.

[0205] 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 descriptions of the same aspects will be simplified or omitted.

[0206] 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 in the fourth embodiment, and therefore detailed description thereof will be omitted.

[0207] 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 proceeds to step S151.

[0208] In step S151, the execution unit 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.

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

[0210] If the prescribed condition RC is not satisfied (S152: NO), the execution device 71 repeats the process of step S152. On the other hand, if the prescribed 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.

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

[0212] <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 effects can be achieved.

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

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

[0215] 16, the storage device 28 stores a monitoring program PM6 according to the sixth embodiment. The monitoring program PM6 is a program for realizing the monitoring unit 20M in the vehicle 20.

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

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

[0218] 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 to which the second digital key K2 is to be registered. In the sixth embodiment, information identifying the device 30 to 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. The execution device 27 then proceeds to step S162.

[0219] In step S162, the execution unit 27 determines whether the first digital key K1 has already been registered for the specific device 30X. Specifically, the execution unit 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.

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

[0221] In step S163, the execution device 27 allows the second authentication information AT2 to be stored. In response to the storage request D34, the execution device 27 stores the authentication package ATP of the second digital key K2 as the second authentication information AT2. In other words, the monitoring unit 20M causes the vehicle management device 26 to store the second authentication information AT2. The execution device 27 then terminates this series of processes.

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

[0223] 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. The execution device 27 then proceeds to step S165.

[0224] In step S165, the execution device 27 transmits a notification M71 indicating that the storage request D34 cannot be fulfilled to the management server 70. 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.

[0225] 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. The execution device 27 then proceeds to step S167.

[0226] In step S167, the execution device 27 sends a deletion request D68 to the management server 70, requesting the deletion of the second digital key K2 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. The execution device 27 then terminates this series of processes. By not deleting the first authentication information AT1, the execution device 27 causes the first authentication information AT1 to remain stored.

[0227] <Actions and Effects of 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 effects can be achieved.

[0228] (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 specific device 30X to not store the second key information DK2.

[0229] 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 includes 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.

[0230] <Monitoring Control of the Monitoring Unit> As shown in Fig. 19, the storage device 37 of the non-friend device 52 stores the monitoring program PM7 in the seventh embodiment. The monitoring program PM7 is a program for realizing the monitoring unit 52M in the non-friend device 52. Hereinafter, the execution device 36 of the non-friend device 52 will be referred to as the execution device 36N. The storage device 37 of the non-friend device 52 will be referred to as the storage device 37N.

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

[0232] The execution unit 36N starts execution of the monitoring program PM7 when it generates the unsigned non-friend key information DKNN for the second digital key K2. When the execution unit 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.

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

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

[0235] On the other hand, when the executing device 36N determines that the first digital key K1 is registered (S171: YES), the executing device 36N proceeds to step S173. In step S173, the executing device 36N refuses to send the completion notification M31 and the signature request D32. As a result, the executing device 36N does not proceed with the processing subsequent to step S44 shown in FIG. 7 . 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 enter a state in which the second key information DK2 is not stored. 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, in the database DB, information indicating the specific device 30X as a shared device 50 in which the second digital key K2 is registered. 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 enter a state in which the second authentication information AT2 is not stored. The execution device 36N then proceeds to step S174.

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

[0237] 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, in step S49, the management server 70 registers and manages the second digital key K2, and stores in the database DB that the device 30 in which the second digital key K2 is registered is the non-friend device 52 that stores the second key information DK2. Then, in step S50, the vehicle 20 stores the authentication package ATP as second authentication information AT2.

[0238] 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 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. By not performing the process of step S49, the management server 70 does not remember that the non-friend device 52 to which the second digital key K2 is registered is a non-friend device 52 including the execution device 36N. 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.

[0239] <Effects of 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.

[0240] (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 the 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.

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

[0242] 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 includes 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.

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

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

[0245] 22, the storage device 37 of the owner device 40 stores a monitoring program PM8 according to the eighth embodiment. Hereinafter, 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.

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

[0247] 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 registration of the second digital key K2 has been requested in the management system 10.

[0248] 24, when the execution device 36O starts execution of 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 referencing information that identifies the non-friend device 52 acquired together with the completion notification M33 of the second digital key K2. The execution device 36O then proceeds to the processing of step S182.

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

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

[0251] In step S183, the executing 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 place the vehicle management device 26 in a state where the second authentication information AT2 is not stored. The executing device 36O then proceeds to step S184.

[0252] In step S184, the execution device 36O sends 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. As a result, the monitoring unit 40M causes the specific device 30X to enter a state in which the second key information DK2 is not stored. The execution device 36O then proceeds to step S185.

[0253] In step S185, the executing device 36O sends 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 enter a state in which it does not store information indicating the specific device 30X as the shared device 50 to which the second digital key K2 is registered. The executing device 36O then terminates this series of processes.

[0254] <Operations 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.

[0255] (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 put the specific device 30X into a state in which the second key information DK2 is not stored.

[0256] 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 determining 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.

[0257] Ninth Embodiment A ninth embodiment of a 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 description will focus on the differences from the third embodiment, and descriptions of the same points will be simplified or omitted. The following description will be given taking as an example a case where both the first digital key K1 and the second digital key K2 are share keys KS.

[0258] <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 intervals. The predetermined interval is, for example, one day. The storage device 72 stores information indicating predetermined priorities. The priorities are used to select the digital key to be set as the allowed digital key KP from among the first digital key K1 and the second digital key K2. The execution device 71 selects the digital key set with the highest priority as the allowed digital key KP.

[0259] In the information indicating the priority order, with respect to the type of digital key, the owner key KO has a higher priority than the friend key KF. In the information indicating the priority order, the friend key KF has a higher priority than the non-friend key KN. 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 priority of the second digital key K2 is higher than the priority of the first digital key K1.

[0260] 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 references the database DB to determine whether the same specific device 30X for the target vehicle 20 is registered as the device 30 to which the first digital key K1 is registered and the device 30 to which the second digital key K2 is registered.

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

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

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

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

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

[0266] 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 to 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 to 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 to which the second digital key K2 is registered from the database DB. Thereafter, the execution unit 71 ends the current series of processes.

[0267] 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. Then, the execution device 71 proceeds to step S198.

[0268] 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 key KP and the excluded digital key 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.

[0269] 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 to 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 to 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 to which the first digital key K1 is registered from the database DB. Thereafter, the execution unit 71 ends the current series of processes.

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

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

[0272] 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 key KP and the excluded digital key KR in accordance with the priority order based on the type of digital key through the processes of steps S202 and S203. Thereafter, the execution device 71 proceeds to step S204.

[0273] 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. After that, the execution device 71 ends the current series of processes.

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

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

[0276] 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 the current series of processes.

[0277] <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 effects can be achieved.

[0278] (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.

[0279] (9-2) The monitoring unit 70M selects the allowed digital key KP and the 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 the friend key KF and the type of the second digital key K2 is the 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.

[0280] (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 digital key is a friend key KF, the authority is set to be greater than when the type of 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.

[0281] (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.

[0282] <Management System> The vehicle 20 does not need to have some of the BLE module 23, the UWB module 24, and the NFC module 25. As long as the vehicle 20 has at least one of these modules, it can perform short-range wireless communication with the device 30. The vehicle 20 is not limited to these modules, and it is sufficient if it has a module that performs short-range wireless communication with the device 30.

[0283] 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, the vehicle management device 26 may be a central ECU that manages multiple ECUs in the vehicle 20.

[0284] In each of the above embodiments, the management server 70 includes an execution device 71, which is a processing circuit including one or more processors that execute various processes according to a computer program (software). However, the management server 70 may also include a processing circuit including one or more dedicated hardware circuits, such as an application-specific integrated circuit (ASIC), that executes at least some of the various processes. Alternatively, the management server 70 may include a processing circuit including a combination of one or more processors and one or more dedicated hardware circuits. 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 processes. The memory, i.e., computer-readable medium, includes any available medium accessible by a general-purpose or dedicated computer. The same applies to the device 30 and the vehicle management device 26.

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

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

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

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

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

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

[0291] <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 for identifying the digital key.

[0292] The information about the digital key stored in the device 30 is not limited to the key information DK, and may be any information about the digital key. For example, the information about the digital key may be information for identifying the digital key.

[0293] 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 as the information about the digital key stored in the device 30.

[0294] 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. For example, the authentication information AT may be a common secret key.

[0295] The information structure included in the key information DK is not limited to the example described in the above embodiment. For example, the owner key information DKO does not need to include the slot identification information ST4. 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.

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

[0297] The structure of the data DA in the database DB is not limited to the examples in the above embodiments. The database DB only needs to include information necessary for management by the management server 70 in the management system 10.

[0298] 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. The authority may not be determined in the database DB.

[0299] <Processing for Registering a Digital Key> The processing 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 in the processing of step S12. The processing 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.

[0300] 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 included in the friend key information DKF and the structure of the information included in the authentication information AT.

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

[0302] The types of digital keys do not have to include the non-friend key KN. In other words, in the management system 10, the share 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.

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

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

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

[0306] <Processing for Deleting a Digital Key> In the above embodiments, when deleting a non-friend key KN, the friend device 51 sends a reservation deletion request D41 to the management server 70. However, the request does not have to be a reservation request. That is, the friend device 51 may send a request to delete the non-friend key KN to the management server 70 regardless of the specified condition RC. In response to the request to delete the non-friend key KN not only from the friend device 51 but also from the owner device 40, the management server 70 may proceed with the processing from step S62 onwards.

[0307] In each of the above embodiments, the management server 70 receives the reservation deletion request D41. However, the vehicle 20 may 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.

[0308] 8, when deleting a non-friend device 52 due to an operation of 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.

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

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

[0311] <Monitoring Unit> 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 share key KS.

[0312] In the first embodiment, the monitoring unit 70M detected that registration of the second digital key K2 was requested by the key tracking request D33. However, the signal used to detect that registration of the second digital key K2 was requested is not limited to this. For example, the monitoring unit 70M may detect that registration of the second digital key K2 was requested by separately acquiring a signal indicating that registration was requested from the friend device 51 or the third device 30C. This also applies to other embodiments. For example, in the seventh embodiment, the monitoring unit 52M may detect that registration of the second digital key K2 was requested when the monitoring unit 52M received 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 was requested when the monitoring unit 52M stored the second key information DK2.

[0313] 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 has the monitoring unit 70M. In the sixth embodiment, a device different from the vehicle management device 26 included in the vehicle 20 may have the monitoring unit 20M. In the sixth embodiment, it is sufficient that the vehicle 20 has the monitoring unit 20M.

[0314] In the first embodiment, the monitoring unit 70M may omit the process 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 be in a state in which the second key information DK2 is not stored. Similarly, in other embodiments, the monitoring unit may perform monitoring control to cause the specific device 30X to be in a state in which one of the first key information DK1 and the second key information DK2 is stored and the other key information DK is not stored.

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

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

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

[0318] 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 specific device 30X to not store the second key information DK2 by not causing the management server 70 to send a request to store the second key information DK2.

Claims

a vehicle having a vehicle management device configured to store information regarding a plurality of digital keys that can be registered to the vehicle; a device configured to store information about a plurality of said digital keys; a management server configured to manage a plurality of said digital keys, the plurality of digital keys include a first digital key and a second digital key; a monitoring unit configured to perform monitoring control to cause the device to store information about one of the first digital key and the second digital key, and not store information about the other digital key; Management system. 　 If 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, The monitoring unit is configured to perform the monitoring control. The management system according to claim 1 . 　 the one digital key of the first digital key and the second digital key is the first digital key, The other digital key of the first digital key and the second digital key is the second digital key. The management system according to claim 2 . 　 the management server is configured to, when receiving a reservation deletion request requesting deletion of a reservation for information related to the first digital key, transmit a deletion request to the vehicle when a predetermined condition is met, the deletion request being a request to delete information related to 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 monitoring control is configured to prevent the management server from sending the deletion request, thereby causing the device to store information about the first digital key. The management system according to claim 3 . 　 In the monitoring control, the monitoring unit is configured to prevent 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. 　 When information about the first digital key and information about the second digital key are stored in the device, In the monitoring control, the monitoring unit is configured to cause 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 . 　 the one digital key of the first digital key and the second digital key is the second digital key, The other digital key of the first digital key and the second digital key is the first digital key. The management system according to claim 2 . 　 the management server is configured to, when receiving a reservation deletion request for requesting deletion of a reservation for information related to the first digital key, transmit to the device a deletion request, the deletion request being a request for deleting information related to the first digital key, when a predetermined specified condition is met; In the monitoring control, the monitoring unit causing 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 allowing the management server to send the deletion request, thereby causing the device to have no information about the first digital key stored therein. The management system according to claim 7. 　 the management server is configured to, when receiving a reservation deletion request for requesting deletion of a reservation for information related to the first digital key, transmit to the device a deletion request, the deletion request being a request for deleting information related to the first digital key, when a predetermined specified condition is met; The monitoring unit causing 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; Even if the specified condition is not met, the management server is caused to send the deletion request to the device, thereby causing the device to store no information about the first digital key. The management system according to claim 7. 　 The management server has the monitoring unit. The management system according to any one of claims 1 to 9. 　 The vehicle has the monitoring unit. The management system according to any one of claims 1 to 9. 　 The device has the monitoring unit. The management system according to any one of claims 1 to 9. 　 The plurality of digital keys include an owner key, only one of which can be registered to the vehicle; further comprising an owner device that stores information about the owner key; The owner device has the monitoring unit. The management system according to any one of claims 1 to 9. 　 In the monitoring control, the monitoring unit selecting an allowed digital key and an excluded digital key from among the first digital key and the second digital key in accordance with a predetermined priority order; and causing the device to store information about the permitted digital keys and not store information about the excluded digital keys. 　 The management system according to claim 1 or 2. 　 The types of the plurality of digital keys include an owner key, only one of which can be registered to the 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 is configured to select the first digital key as the allowed digital key. The management system of claim 14. 　 The monitoring unit is configured to select, as the allowed 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. 　 a management server configured to manage a plurality of digital keys that can be registered to a vehicle, the plurality of digital keys including a first digital key and a second digital key that can be used by a device configured to store information about the plurality of digital keys; a monitoring unit configured to perform monitoring control to cause the device to store information about one of the first digital key and the second digital key, and not store information about the other digital key; Management server. 　 A vehicle management device mounted on a vehicle and configured to store information about a plurality of digital keys that can be registered to the vehicle, the plurality of digital keys including a first digital key and a second digital key that can be used by a device configured to store information about the plurality of digital keys; a monitoring unit configured to perform monitoring control to cause the device to store information about one of the first digital key and the second digital key, and not store information about the other digital key; Vehicle management device. 　 A device configured to store information regarding a plurality of digital keys that can be registered to a vehicle, the vehicle having a vehicle management device configured to store information regarding the plurality of digital keys, the plurality of digital keys including a first digital key and a second digital key; a monitoring unit configured to perform monitoring control to cause the device to store information about one of the first digital key and the second digital key, and not store information about the other digital key; device.

Images