Vehicle management device, management server, and management system

Abstract

To provide a vehicle management device capable of reducing a burden on a user when deleting information on a digital key.SOLUTION: The vehicle management device includes a storage device 28 that stores information relating to the digital key. When the vehicle management device receives new authentication information AT in a state where the number of pieces of authentication information AT stored in the storage device 28 has reached a predetermined number that can be stored, the vehicle management device deletes any piece of information on the digital key stored in the storage device 28.SELECTED DRAWING: Figure 10

Description

[Technical Field]

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

[0002] Patent Document 1 discloses a digital key system technology that uses a device such as a smartphone as a vehicle key. The digital key system stores information about the digital key in the vehicle. The digital key system also stores information about the digital key in a device. This allows the vehicle to be used using the device registered as a digital key without the need for a physical key. Furthermore, the digital key system issues a registration request to enable another person's device to function as a digital key through communication between the device storing information about the digital key and the other person's device. This allows the other person's device to be registered as a digital key to the vehicle. In other words, the digital key can generate a new digital key. The digital key system also allows the vehicle to be loaned to another person without the need to exchange a physical key. [Prior art documents] [Patent documents]

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

[0004] There is a limit to the amount of information related to digital keys that a vehicle can store. When the amount of information related to digital keys stored in a vehicle has reached the preset number that can be stored, in order to store new information related to digital keys in the vehicle, the user of the vehicle must select which information related to digital keys to delete from the information stored in the vehicle. [Means for solving the problem]

[0005] A vehicle management device for solving the above problem is mounted on a vehicle and includes a storage device that stores information about the digital key. When the number of pieces of information about the digital key stored in the storage device has reached a predetermined number that can be stored, and new information about the digital key is received, the vehicle management device deletes any of the pieces of information about the digital key stored in the storage device.

[0006] A management server for solving the above problem manages digital keys. The management server is capable of receiving a request to store information about the digital key in a vehicle. The management server is capable of determining whether the amount of information about the digital key stored in the vehicle has reached a predetermined number that the vehicle can store. When the management server receives the request for a vehicle whose amount of information about the digital key stored has reached the predetermined number, the management server transmits to the vehicle a command to delete any of the information about the digital key stored in the vehicle.

[0007] The management system for solving the above problem includes a vehicle management device mounted on a vehicle and a management server for managing digital keys. The vehicle includes a storage device. When the storage device has stored a predetermined number of pieces of information about the digital key and the management system receives new information about the digital key, the management system deletes any of the pieces of information about the digital key stored in the vehicle. [Effects of the Invention]

[0008] According to the vehicle management device, the user does not have to select which information about the digital key stored in the vehicle to delete, thereby reducing the burden on the user.

[0009] The management server eliminates the need for the user to select which information about the digital key stored in the vehicle to delete, thereby reducing the burden on the user. The management system described above relieves the user from having to select which pieces of information about the digital key stored in the vehicle to delete, thereby reducing the burden on the user. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a schematic diagram showing a management system according to the first embodiment. [Figure 2] FIG. 2 is a schematic diagram showing owner key information according to the first embodiment. [Figure 3] FIG. 3 is a schematic diagram showing the share key information of the first embodiment. [Figure 4] FIG. 4 is a schematic diagram showing data in the database of the first embodiment. [Figure 5] FIG. 5 is an explanatory diagram showing a series of processes performed by the management system when registering an owner key according to the first embodiment. [Figure 6] FIG. 6 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in the first embodiment. [Figure 7] FIG. 7 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in the first embodiment. [Figure 8] FIG. 8 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a friend device in the first embodiment. [Figure 9]FIG. 9 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a non-friend device in the first embodiment. [Figure 10] FIG. 10 is an explanatory diagram showing a series of processes performed by a management system including a vehicle equipped with the vehicle management device of the first embodiment and a management server. [Figure 11] FIG. 11 is a flowchart showing the flow of the process executed by the vehicle control device in FIG. 10 and FIG. [Figure 12] FIG. 12 is an explanatory diagram showing a series of processes performed by a management system including a vehicle equipped with a vehicle management device of the second embodiment and a management server. [Figure 13] FIG. 13 is an explanatory diagram showing a continuation of the processing of FIG. [Figure 14] FIG. 14 is an explanatory diagram showing a series of processes performed by a management system including a vehicle equipped with a vehicle management device of the third embodiment and a management server. [Figure 15] FIG. 15 is a flowchart showing the flow of the processing executed by the management server in FIGS. 14, 16, 18, and 20. In FIG. [Figure 16] FIG. 16 is an explanatory diagram showing a series of processes performed by a management system including a vehicle equipped with a vehicle management device of the fourth embodiment and a management server. [Figure 17] FIG. 17 is an explanatory diagram showing a continuation of the processing of FIG. [Figure 18] FIG. 18 is an explanatory diagram showing a series of processes performed by a management system including a vehicle equipped with a vehicle management device of the fifth embodiment and a management server. [Figure 19] FIG. 19 is an explanatory diagram showing a continuation of the processing of FIG. [Figure 20] FIG. 20 is an explanatory diagram showing a series of processes performed by a management system including a vehicle equipped with a vehicle management device of the modified example and a management server. [Figure 21] FIG. 21 is an explanatory diagram showing a series of processes for prompting the user to select whether or not to permit deletion of information related to the digital key. [Figure 22] FIG. 22 is a diagram showing an example of an image displayed to prompt the user to select whether or not to permit deletion of information related to the digital key. DETAILED DESCRIPTION OF THE INVENTION

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

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

[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 communication with the device 30 using BLE communication. The UWB module 24 communicates with the device 30 using UWB communication. The UWB module 24 measures the distance between the device 30 and the vehicle 20. The NFC module 25 performs short-range communication with the device 30 using NFC communication.

[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 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. The execution device 27 executes the vehicle program PV, causing the execution device 27 to store, delete, and replace 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, deletion, and replacement of the authentication information AT.

[0016] Note that authenticating a digital key means enabling the vehicle 20 to be controlled by the digital key. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables the vehicle 20 to be unlocked. Also, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables the vehicle 20 to be started.

[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, 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 communication with the vehicle 20 by BLE communication. The UWB module 34 performs short-range communication with the vehicle 20 by UWB communication. The NFC module 35 performs short-range communication with the vehicle 20 by NFC communication.

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

[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 the functions of pairing devices 30 and sharing digital keys using APIs provided by the OS. The execution unit 36 ​​executes the device program PD to perform processes related to the storage and deletion of key information DK.

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

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

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

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

[0026] Certificate information ST5 indicates a certificate that certifies the digital key. Device public key information ST6 indicates a device public key PKD, which is the public key of the device 30. Note that the device public key PKD in the owner key information DKO indicates the public key of the owner device 40. Vehicle public key information ST7 indicates a vehicle public key PKV, which is the public key of the vehicle 20. Authorization public key information ST8 indicates a vehicle public key PKV that has already been authorized.

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

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

[0029] Note that when a digital key is registered, the digital key is usable. That is, when a digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. The authentication information AT is information related to the digital key. That is, when a digital key is registered, the vehicle 20 stores information related to the digital key. The key information DK is information related to the digital key. That is, when a digital key is registered, the device 30 stores information related to the digital key.

[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, intra-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The shared key structure information STS includes certificate information ST5, vehicle public key information ST7, and permission public key information ST8. In other words, the shared key structure information STS is the owner key structure information STO minus 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 shared device 50 is a legitimate party with which the digital key is shared. For example, in the case of the friend device 51, it indicates a signature by the owner device 40. The owner signature information indicates that the owner device 40 has signed the device public key PKD of the friend device 51, which is indicated by the device public key information ATP6. Also, for example, in the case of the non-friend device 52, it indicates a signature by the friend device 51. The friend signature information indicates that the friend device 51 has signed the device public key PKD of the non-friend device 52, which is indicated by the device public key information ATP6.

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

[0034] As shown in FIG. 1, the device server 60 relays communication between the devices 30 and the management server 70. A device server 60 is provided for each type of device 30. That is, the device server 60 with which a first type of device 30 communicates is different from the device server 60 with which a second type of device 30 communicates. For example, the type refers to the model of the device 30, and a device server 60 is provided for each model of the device 30. For example, the type refers to the communication line used by the device 30, and a device server 60 is provided for each communication line used by the device 30. Each device server 60 relays communication with the management server 70, so that devices 30 of different types can communicate with the management server 70 via the device server 60. Note that FIG. 1 illustrates only one device server 60.

[0035] <Administration Server 70> The management server 70 is capable of communicating with the vehicle 20 and the multiple devices 30. The management server 70 includes an execution device 71, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 is also capable of wireless communication with the communication module 21 of the vehicle 20. The storage device 72 stores a server program PS, a replacement program PM, and a database DB. When the execution device 71 executes the server program PS, it causes the execution device 71 to register a digital key in the database DB and delete a digital key from the database DB. When the execution device 71 executes the replacement program PM, it causes the execution device 71 to send a command to the storage device 28 of the vehicle 20 to replace the authentication information AT. When the execution device 71 executes the replacement program PM, it causes the execution device 71 to perform processing related to the replacement of the authentication information AT.

[0036] In the database DB, data DA is separated for each vehicle 20. When a digital key is registered, the management server 70 stores, in the data DA, information indicating the device 30 that stores key information DK indicating the digital key.

[0037] As shown in Figure 4, the data DA for one vehicle 20 includes the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. The hierarchy is determined by the type of digital key. From top to bottom, the hierarchy is arranged as follows: owner key KO, friend key KF, and non-friend key KN.

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

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

[0040] A state in which digital keys are registered to seven devices 30 for one vehicle 20 will be described. The seven devices 30 are a first device 30A, a second device 30B, a third device 30C, a fourth device 30D, a fifth device 30E, a sixth device 30F, and a seventh device 30G. The digital key registered to the first device 30A is referred to as the first digital key. The digital key registered to the second device 30B is referred to as the second digital key. The digital key registered to the third device 30C is referred to as the third digital key. The digital key registered to the fourth device 30D is referred to as the fourth digital key. The digital key registered to the fifth device 30E is referred to as the fifth digital key. The digital key registered to the sixth device 30F is referred to as the sixth digital key. The digital key registered to the seventh device 30G is referred to as the seventh digital key.

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

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

[0043] More specifically, in the data DA, the devices 30 whose digital key type is registered as the friend key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are friend devices 51.

[0044] In the data DA, the devices 30 whose digital key type is registered as a non-friend key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. In other words, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

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

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

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

[0049] In the data DA, the relationship between the sixth device 30F and the fifth device 30E is such that the non-friend key KN is registered in the sixth device 30F based on a registration request from the fifth device 30E. In other words, the sixth digital key is generated based on the fifth digital 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 based on a registration request from the fifth device 30E. In other words, the seventh digital key is generated based on the fifth digital key.

[0051] In this way, the data DA stores the devices 30 registered as digital keys. When the device 30 is registered, the data DA is associated with information indicating the device 30 that made the request that caused the registration. The data DA also includes information indicating which digital key each digital key was generated based on.

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

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

[0054] By registering the owner key KO, the management system 10 stores key information DK indicating the owner key KO in the first device 30A. By registering the owner key KO, the management system 10 stores authentication information AT for authenticating the owner key KO in the vehicle 20. As a result, the first device 30A becomes the owner device 40. Note that when registering the owner key KO, it is assumed that an application is installed in the first device 30A.

[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 the process of step S11. In step S11, the management server 70 generates a pairing password PAS. Then, the management server 70 transmits information indicating the pairing password PAS to the vehicle 20 and the first device 30A.

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

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

[0059] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. After that, the first device 30A advances the process to step S15. In step S15, the first device 30A stores the owner key information DKO. As a result, the first device 30A becomes the owner device 40. That is, the registration request D11 is a request to store the owner key information DKO, which is the key information DK, in the device 30. Thereafter, the first device 30A transmits, to the vehicle 20, certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD.

[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, the vehicle 20 stores the device public key information ST6 indicating the device public key PKD as the authentication information AT. Then, the vehicle 20 transmits a completion notification M11 to the first device 30A indicating that the storage of the authentication information AT has been completed.

[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. Then, the first device 30A transmits the key track request D12 for the owner key KO to the management server 70 via the device server 60.

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

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

[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). Thereafter, the owner device 40 proceeds to the process of step S22.

[0066] In step S22, the owner device 40 acquires invitation information IV1 for sharing the digital key from the relay server. The invitation information IV1 is, for example, a URL link. The URL link stores share information SH1 required for sharing the digital key. The owner device 40 then transmits the invitation information IV1 to the second device 30B.

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

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

[0070] Thereafter, the owner device 40 receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 acquires the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process of step S25 in response to an operation of the owner device 40.

[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 unsigned friend key information DKFN, and accepts an operation by the user of the owner device 40 indicating consent to the registration of the friend key KF. When the operation is performed, the owner device 40 acquires a signature based on the operation. Thereafter, the owner device 40 proceeds to step S26.

[0072] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. As a result, the owner device 40 generates friend key information DKF. The owner device 40 then uploads the generated friend key information DKF to the URL link, which is the invitation information IV1. The owner device 40 then transmits a completion notification M22 to the second device 30B, indicating that the completed friend key information DKF has been uploaded to the URL link.

[0073] Thereafter, the second device 30B receives the completion notification M22. Thereafter, the second device 30B performs the process of step S27. In step S27, the second device 30B downloads and stores the friend key information DKF. As a result, the second device 30B becomes a friend device 51. Thereafter, the second device 30B proceeds to the process of step S28.

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

[0075] Thereafter, when the management server 70 receives a key track request D23 for the friend key KF, the management server 70 performs processing in step S29. In step S29, the management server 70 performs registration management of the friend key KF. The key track request D23 is a request to store new authentication information AT in the vehicle 20.

[0076] Specifically, the management server 70 verifies that the friend key KF that is the target of the key track request D23 is not on the reject list. The reject list is a list that indicates shared keys KS that include friend keys KF and non-friend keys KN for which a deletion request has already been received. If the friend key KF is on the reject list, the management server 70 sends a notification to the second device 30B that the key track request D23 cannot be fulfilled.

[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. In detail, the management server 70 stores the second device 30B as a device 30 registered as a friend device 51 in the data DA of the vehicle 20 in the database DB. The management server 70 stores the relationship between the second device 30B and the owner device 40 by referring to the acquired friend key information DKF.

[0078] Thereafter, the management server 70 transmits the authentication package ATP of the friend key information DKF and a storage request D24 requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 transmits device public key information ST6 indicating the device public key PKD of the friend device 51 to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD has been signed by the owner device 40.

[0079] Thereafter, when the vehicle 20 receives the storage request D24 and the authentication package ATP from the management server 70, it performs the process of step S30. In step S30, the vehicle 20 stores the received authentication package ATP as authentication information AT for authenticating the friend key KF.

[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 process of step S31. In the process of step S31, the second device 30B presents information indicating the completion of the registration of the friend key KF on the HMI 32. For example, the second device 30B displays an image indicating the completion of the registration of the friend key KF on the HMI 32. This causes the management system 10 to end the series of processes for registering the friend key KF.

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

[0082] When an operation to request registration of a non-friend key KN is executed in the friend device 51, the friend device 51 first performs the process of step S41. In step S41, the friend device 51 transmits a registration request D31 of the non-friend key KN to a relay server (not shown). Thereafter, the friend device 51 proceeds to the process of step S42.

[0083] In step S42, the friend device 51 acquires invitation information IV2 for sharing the digital key from the relay server. The invitation information IV2 is, for example, a URL link. The URL link stores share information SH2 required for sharing the digital key. The friend device 51 then transmits the invitation information IV2 to the third device 30C.

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

[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 include the signature information ATP1. Specifically, the third device 30C generates each piece of information included in the acquired share information SH2 as each piece of information in the unsigned non-friend key information DKNN. The third device 30C then transmits to the friend device 51 a completion notification M31 indicating that the generated unsigned non-friend key information DKNN has been uploaded to the URL link, and a signature request D32 requesting a signature.

[0087] Thereafter, the friend device 51 receives a completion notification M31 and a signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 acquires unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process of step S45 in response to an operation of the friend device 51.

[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 unsigned non-friend key information DKNN, and accepts an operation by the user of the friend device 51 indicating consent to the generation of the non-friend key KN. When the operation is performed, the friend device 51 acquires a signature based on the operation. Thereafter, the friend device 51 proceeds to step S46.

[0089] In step S46, the friend device 51 adds the signature information ATP1 to the unsigned non-friend key information DKNN. As a result, the friend device 51 generates non-friend key information DKN. Thereafter, the friend device 51 uploads the generated non-friend key information DKN to the URL link, which is the invitation information IV2. Then, the friend device 51 transmits a completion notification M32 to the third device 30C indicating that the completed non-friend key information DKN has been uploaded to the URL link.

[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 becomes a non-friend device 52. The third device 30C then proceeds to the process of step S48.

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

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

[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 subject of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the data DA of the vehicle 20 in the database DB as a device 30 registered as a non-friend device 52. The management server 70 stores the relationship between the third device 30C and the friend device 51 by referring to the acquired non-friend key information DKN. Specifically, the management server 70 stores the third device 30C as a device 30 having the non-friend key KN registered in response to the registration request D31 from the second device 30B.

[0095] Thereafter, the management server 70 transmits the authentication package ATP of the non-friend key information DKN and a storage request D34 requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 transmits device public key information ST6 indicating the device public key PKD of the non-friend device 52 to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD is signed by the friend device 51.

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

[0097] After completing the registration management, the management server 70 transmits a key track completion notification M33 to the second device 30B. Thereafter, upon receiving the key track completion notification M33, the second device 30B performs the process of step S51. In the process of step S51, the third device 30C presents information indicating the completion of registration of the non-friend key KN to the HMI 32. For example, the third device 30C displays an image indicating the completion of registration of the non-friend key KN on the HMI 32. This causes the management system 10 to end the series of processes for registering the non-friend key KN.

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

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

[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 deletion reservation D41 for the non-friend key KN is generated. The deletion reservation D41 is a command to reserve the deletion of the non-friend key KN.

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

[0102] Thereafter, when the management server 70 receives the deletion reservation D41 of the non-friend key KN, it performs the process of step S62. In step S62, the management server 70 generates a pending notification M41 indicating that the deletion reservation is pending in accordance with the deletion reservation D41. Then, the management server 70 transmits the pending notification M41 to the friend device 51.

[0103] Thereafter, when the friend device 51 receives the pending notification M41, the friend device 51 performs the process of step S63. In step S63, the friend device 51 displays, on the HMI 32, information indicating that the deletion of the non-friend key KN that is the target of the deletion reservation D41 is pending.

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

[0105] In step S65, the management server 70 confirms that the predetermined condition RC is satisfied. If the management server 70 confirms that the predetermined condition RC is satisfied, the management server 70 advances the process 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 deletion reservation 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 deletion reservation 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 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 target of the deletion reservation D41 in accordance with the deletion request D43. That is, the vehicle 20 deletes the authentication package ATP of the non-friend key KN. The vehicle 20 then transmits a deletion completion notification M43 to the management server 70, indicating that the deletion of the authentication information AT in accordance with the deletion request D43 has been completed.

[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 the process of 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 deletion completion notification M44 to the friend device 51, indicating that the series of deletions of the non-friend key KN in accordance with the deletion reservation 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, to the HMI 32, information indicating that the deletion of the non-friend key KN that is the target of the deletion reservation D41 has been completed. For example, the friend device 51 displays, on the HMI 32, an image indicating that the deletion of the non-friend key KN has been completed. Thereafter, the management system 10 ends the series of processes for the deletion of this non-friend key KN.

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

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

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

[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 step S82, the management server 70 performs processing step S84. In step S84, the management server 70 generates a deletion request D51 for deleting the authentication information AT for authenticating the non-friend key information DKN that was deleted in step S81. Then, the management server 70 transmits the deletion request D51 to the vehicle 20.

[0119] Thereafter, when vehicle 20 receives deletion request D51, vehicle 20 performs processing of step S85. In step S85, vehicle 20 deletes authentication information AT for authenticating non-friend key information DKN that was deleted in step S81 in accordance with deletion request D51. Then, vehicle 20 transmits completion notification M53 to management server 70 indicating that deletion of authentication information AT in accordance with 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 information DKN that was completely 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] <Replacement of authentication information AT by vehicle management device 26> There is a limit to the number of pieces of authentication information AT that can be stored in the storage device 28 of the vehicle 20. When the number of pieces of authentication information AT stored in the storage device 28 has reached a predetermined number that can be stored, the vehicle 20 receives new authentication information AT and stores the new authentication information AT in place of one of the pieces of authentication information AT stored in the storage device 28.

[0123] Specifically, when the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored, and the vehicle 20 receives new authentication information AT, the vehicle 20 deletes one of the pieces of authentication information AT stored in the storage device 28. Thereafter, the vehicle 20 stores the received authentication information AT in the storage device 28.

[0124] <Series of processes executed by the vehicle 20> Figure 10 is an explanatory diagram showing the flow of a series of processes performed by vehicle 20 in management system 10 when new authentication information AT is received when the number of authentication information AT stored in memory device 28 has reached the specified number that can be stored.

[0125] 1, in the vehicle 20, the storage device 28 stores a vehicle program PV. The execution device 27 executes the vehicle program PV stored in the storage device 28. In this way, the vehicle 20 executes a series of processes.

[0126] 10 is a device 30 that does not store non-friend key information DKN and that is designated as a non-friend device 52 by the series of processes. When an operation is executed in a friend device 51 (not shown) to request the third device 30C to register a non-friend key KN, the management system 10 performs the series of processes shown in FIG. 7 to register the non-friend key KN.

[0127] Step S101 shown in Fig. 10 is the same as step S47 shown in Fig. 7. After the processing of step S101, the third device 30C performs the processing of step S102. The processing of step S102 shown in Fig. 10 is the same as step S48 shown in Fig. 7. Then, the third device 30C transmits the non-friend key information DKN and a key track request D33 of the non-friend key KN to the management server 70.

[0128] Thereafter, when the management server 70 receives a key track request D33 for the non-friend key KN, the management server 70 performs processing of step S103. In step S103, similar to step S49 shown in FIG. 7, the management server 70 performs registration management of the non-friend key KN. As processing of step S103, the management server 70 transmits to the vehicle 20 the authentication package ATP of the non-friend key information DKN and a storage request D34 for storing the authentication package ATP. In addition, if there is a digital key stored as being in a faded-out state in the database DB for the vehicle 20, the management server 70 transmits information about the digital key that is in a faded-out state to the vehicle 20. If there is a digital key stored as being in a faded-out state in the database DB for the vehicle 20, the deletion reservation D41 remains unexecuted.

[0129] Thereafter, when the vehicle 20 receives the authentication package ATP and the storage request D34, the vehicle 20 performs the process of step S104. At this time, if there is a digital key stored as being in a faded-out state in the database DB for the vehicle 20, the vehicle 20 receives information about the digital key that is in a faded-out state.

[0130] <Select the authentication information AT to delete> In step S104, the vehicle 20 selects, from the authentication information AT stored in the storage device 28, authentication information AT to replace the authentication package ATP in the non-friend key information DKN of the third device 30C. That is, in step S104, the vehicle 20 selects, from the authentication information AT stored in the storage device 28, authentication information AT to be deleted. The process by which the vehicle 20 selects the authentication information AT will be described later. Once the vehicle 20 selects the authentication information AT to replace the authentication package ATP in the non-friend key information DKN of the third device 30C, the vehicle 20 performs the process of step S105.

[0131] 11 is a flowchart showing the process of selecting authentication information AT to replace the authentication package ATP in the non-friend key information DKN of the third device 30C, which is performed by the vehicle 20 in step S104. The vehicle 20 performs this series of processes as the process of step S104.

[0132] <Determining the fade-out state> 11, when this series of processes starts, the vehicle 20 determines in step S200 whether the deletion reservation D41 remains. The vehicle 20 determines that the deletion reservation D41 remains when the storage device 28 stores authentication information AT of a digital key in a faded-out state. If the deletion reservation D41 remains (step S200: YES), the vehicle 20 proceeds to step S210.

[0133] In step S210, the vehicle 20 determines whether multiple deletion reservations D41 remain. If the storage device 28 stores authentication information AT of multiple faded-out digital keys, the vehicle 20 determines that multiple deletion reservations D41 remain. If multiple deletion reservations D41 remain (step S210: YES), the vehicle 20 proceeds to step S220.

[0134] In step S220, the vehicle 20 deletes all authentication information AT for the faded-out digital keys stored in the storage device 28. As a result, the number of pieces of authentication information AT stored in the storage device 28 becomes less than the predetermined number that can be stored. The vehicle 20 then ends the series of processes shown in Figure 11. After completing the series of processes shown in Figure 11, the vehicle 20 performs the process of step S105 shown in Figure 10.

[0135] If the storage device 28 stores only one piece of authentication information AT for a faded-out digital key, that is, if there are no deletion reservations D41 remaining (step S210: NO), the vehicle management device 26 proceeds to step S230.

[0136] In step S230, the vehicle management device 26 selects the authentication information AT of the faded-out digital key as the authentication information AT to be deleted. After that, the vehicle 20 ends the series of processes shown in Fig. 11. After ending the series of processes shown in Fig. 11, the vehicle 20 performs the process of step S105 shown in Fig. 10.

[0137] In the process of step S200, if there is no deletion reservation D41 remaining (step S200: NO), the vehicle 20 proceeds to the process of step S240. <Determine whether or not there is authentication information AT selected as a protection target> The vehicle management device 26 is configured to be able to select authentication information AT to be protected from among the multiple pieces of authentication information AT stored in the storage device 28. For example, the user of the vehicle 20 can select each piece of authentication information AT stored in the storage device 28 as the piece to be protected via the HMI 22 of the vehicle 20. For example, the user of the vehicle 20 can select each piece of authentication information AT stored in the storage device 28 as the piece to be protected via the HMI 32 of the owner device 40. For example, the user of the vehicle 20 can select each piece of authentication information AT stored in the storage device 28 as the piece to be protected via the HMI 32 of the friend device 51. For example, the user of the vehicle 20 can select each piece of authentication information AT stored in the storage device 28 as the piece to be protected via the HMI 32 of the non-friend device 52.

[0138] In step S240, the vehicle 20 determines whether any authentication information AT stored in the storage device 28 has been selected as a protection target. If any authentication information AT has been selected as a protection target (step S240: YES), the vehicle 20 proceeds to step S250. In step S250, the vehicle 20 determines that, in subsequent processing, authentication information AT to be deleted will be selected from among the authentication information AT that has not been selected as a protection target. Thereafter, the vehicle 20 proceeds to step S260. If any authentication information AT has not been selected as a protection target (step S240: NO), the vehicle 20 proceeds to step S260.

[0139] <Determining whether priority is set for authentication information AT> The vehicle management device 26 is configured to be able to set priorities for the authentication information AT stored in the storage device 28. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the storage device 28 via the HMI 22 of the vehicle 20. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the storage device 28 via the HMI 32 of the owner device 40. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the storage device 28 via the HMI 32 of the friend device 51. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the storage device 28 via the HMI 32 of the non-friend device 52.

[0140] In step S260, vehicle 20 determines whether or not a priority has been set for the authentication information AT stored in storage device 28. If a priority has been set for the authentication information AT stored in storage device 28 (step S260: YES), vehicle 20 proceeds to step S270.

[0141] In step S270, vehicle 20 determines whether or not two or more pieces of authentication information AT with different priorities are stored in storage device 28. If storage device 28 stores two or more pieces of authentication information AT with different priorities (step S270: YES), vehicle 20 proceeds to step S280.

[0142] In step S280, the vehicle 20 selects the authentication information AT to be deleted based on the priority. For example, the vehicle 20 selects the authentication information AT with the lowest priority as the authentication information AT to be deleted. Thereafter, the vehicle 20 ends the series of processes shown in Fig. 11. After ending the series of processes shown in Fig. 11, the vehicle 20 performs the process of step S105 shown in Fig. 10.

[0143] In the process of step S260, if a priority has not been set for the authentication information AT stored in storage device 28 (step S260: NO), vehicle 20 proceeds to step S290. In the process of step S270, if storage device 28 does not store two or more pieces of authentication information AT with different priorities (step S270: NO), vehicle 20 proceeds to step S290.

[0144] <Determining whether authentication information AT of non-friend key KN is stored> In step S290, the vehicle 20 determines whether the authentication information AT of the non-friend key KN is stored in the storage device 28. If the authentication information AT of the non-friend key KN is stored in the storage device 28 (step S290: YES), the vehicle 20 proceeds to step S300.

[0145] In step S300, the vehicle management device 26 selects the authentication information AT corresponding to the non-friend key information DKN from the authentication information AT stored in the storage device 28 as the authentication information AT to be deleted. After that, the vehicle 20 ends the series of processes shown in Figure 11. After ending the series of processes shown in Figure 11, the vehicle 20 performs the process of step S105 shown in Figure 10.

[0146] In step S290, if the storage device 28 does not store authentication information AT for the non-friend key KN (step S290: NO), the vehicle 20 proceeds to step S310. In step S310, the vehicle 20 selects, from the authentication information AT stored in the storage device 28, the authentication information AT corresponding to the shared key information DKS with the oldest last used date as the authentication information AT to be deleted. Thereafter, the vehicle 20 ends the series of processes shown in Figure 11. After ending the series of processes shown in Figure 11, the vehicle 20 performs the process of step S105 shown in Figure 10.

[0147] <Replace authentication information AT> 10, the vehicle 20 stores the authentication package ATP of the non-friend key information DKN of the third device 30C in place of the authentication information AT stored in the storage device 28. Specifically, the vehicle 20 deletes the authentication information AT selected in step S105 from the storage device 28. Thereafter, the vehicle 20 stores the authentication package ATP of the non-friend key information DKN of the third device 30C as the authentication information AT for authenticating the non-friend key KN of the third device 30C.

[0148] When processing step S220 is performed, the vehicle 20 deletes all authentication information AT of the faded-out digital key stored in the storage device 28. As a result, in step S104, the number of pieces of authentication information AT stored in the storage device 28 becomes less than the predetermined number that can be stored. When processing step S105, if the number of pieces of authentication information AT stored in the storage device 28 has not reached the predetermined number that can be stored, the vehicle 20 does not delete the authentication information AT from the storage device 28 in step S105. In this case, the vehicle 20 stores the authentication package ATP of the non-friend key information DKN of the third device 30C as authentication information AT for authenticating the non-friend key KN of the third device 30C.

[0149] <Processing after replacing authentication information AT> After performing the process of step S105, the vehicle 20 proceeds to step S106. In step S106, the vehicle 20 generates a completion notification M61. The completion notification M61 includes a signal indicating that the authentication package ATP in the non-friend key information DKN of the third device 30C has been replaced with the authentication information AT stored in the storage device 28, which was selected by the vehicle management device 26 in step S104, and has been stored. The vehicle management device 26 transmits the completion notification M61 to the management server 70.

[0150] When the management server 70 receives the completion notification M61, the management server 70 performs the process of step S107. In step S107, the management server 70 generates a completion notification M62. The completion notification M62 includes information indicating that the storage device 28 has stored the authentication package ATP of the non-friend key information DKN of the third device 30C as authentication information AT for authenticating the non-friend key KN of the third device 30C. The management server 70 transmits the completion notification M62 to the third device 30C.

[0151] When the third device 30C receives the completion notification M62, the third device 30C performs the process of step S108. In step S108, the non-friend device 52 presents to the HMI 32 registration completion information indicating that the registration of the non-friend key KN of the third device 30C to the vehicle 20 has been completed. Thereafter, the management system 10 ends the series of processes for replacing the current authentication information AT.

[0152] <Operation of the First Embodiment> When the number of pieces of authentication information AT stored in the storage device 28 has reached a predetermined number and new authentication information AT is received, the vehicle management device 26 deletes one of the pieces of authentication information AT stored in the storage device 28 without user intervention. The authentication information AT is information related to the digital key.

[0153] <Effects of the first embodiment> (1-1) According to the vehicle management device 26, when storing new authentication information AT, the user of the vehicle 20 does not have to select which authentication information AT to delete from the authentication information AT stored in the vehicle 20. In other words, the vehicle management device 26 can reduce the burden on the user of the vehicle 20.

[0154] (1-2) The following describes a case where the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored, and a deletion reservation D41, which is a command to execute the deletion of the target authentication information AT when a predetermined condition RC is met, remains unexecuted. In this case, when the vehicle management device 26 receives new authentication information AT, it deletes the authentication information AT that is the target of the unexecuted deletion reservation D41 from the storage device 28. Thereafter, the vehicle management device 26 stores the new authentication information AT in the storage device 28. In other words, the vehicle management device 26 selects the authentication information AT for authenticating the digital key that is scheduled to be deleted as the authentication information to be deleted. This allows the vehicle management device 26 to store the new authentication information AT while still storing the authentication information AT for authenticating the digital key that is not scheduled to be deleted.

[0155] (1-3) The following describes a case where the number of pieces of authentication information AT stored in the storage device 28 has reached the preset number that can be stored, and multiple deletion reservations D41 remain unexecuted. In this case, when the vehicle management device 26 receives new authentication information AT, it deletes all of the authentication information AT that are the subject of the remaining unexecuted deletion reservations D41. Thereafter, the vehicle management device 26 stores the new authentication information AT in the storage device 28. This allows the vehicle management device 26 to store the received new authentication information AT, and also ensure that the storage device 28 has sufficient storage capacity to store further authentication information AT.

[0156] (1-4) The vehicle management device 26 is configured so that the user of the vehicle 20 can set priorities for the authentication information AT stored in the storage device 28. When the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored, the vehicle management device 26 selects the authentication information AT to be deleted from the storage device 28 based on the priority that has already been set. This allows the vehicle management device 26 to select the authentication information AT to be deleted from the storage device 28, reflecting the intention of the user who set the priority.

[0157] (1-5) The vehicle management device 26 is configured to be able to select authentication information AT to be protected from among the multiple pieces of authentication information AT stored in the storage device 28. When the vehicle management device 26 receives new authentication information AT, it deletes one of the multiple pieces of authentication information AT that has not been selected as a piece of authentication information to be protected. The vehicle management device 26 can set two levels of priority for the multiple pieces of authentication information AT stored in the storage device 28: authentication information AT that has been selected as a piece of authentication information to be protected, and authentication information AT that has not been selected as a piece of authentication information to be protected. The vehicle management device 26 can reflect the intentions of the user of the vehicle 20 by preventing the deletion of authentication information AT that has been selected as a piece of authentication information to be protected.

[0158] (1-6) The digital keys include a first digital key, a second digital key generated based on the first digital key, and a third digital key generated based on the second digital key. The first digital key is the owner key KO. The second digital key is the friend key KF. The third digital key is the non-friend key KN. The following describes a case where the storage device 28 stores authentication information AT for authenticating the friend key KF, which is the second digital key, and authentication information AT for authenticating the non-friend key KN, which is the third digital key, and the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored. In this case, when the vehicle management device 26 receives new authentication information AT, it deletes the authentication information AT corresponding to the non-friend key KN, which is the third digital key, from the authentication information AT stored in the storage device 28. This allows the vehicle management device 26 to protect the authentication information AT corresponding to the friend key KF registered based on the owner key KO. This allows the authentication information AT corresponding to the friend key KF to be replaced with new authentication information AT, thereby reducing the frequency with which the owner has to re-register the friend key KF.

[0159] (1-7) The management system 10 includes a vehicle management device 26 mounted on the vehicle 20 and a management server 70 that manages the digital key. The vehicle 20 includes a storage device 28. When the number of pieces of authentication information AT stored in the storage device 28 has reached a predetermined number that can be stored, and new authentication information AT is received, the management system 10 deletes one of the pieces of authentication information stored in the storage device 28 of the vehicle 20. According to the above management system 10, when the storage device 28 of the vehicle 20 stores new authentication information AT, the user of the vehicle 20 does not have to select which piece of authentication information AT to delete from the authentication information AT stored in the vehicle 20. In other words, the management system 10 can reduce the burden on the user of the vehicle 20.

[0160] <Modification of the first embodiment> The first embodiment can be modified as follows: The first embodiment described above and the following modifications of the first embodiment can be combined and implemented within the scope of technical compatibility.

[0161] The following describes a case where the vehicle 20 receives new authentication information AT when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, if the vehicle management device 26 can delete any of the pieces of authentication information AT stored in the storage device 28, the vehicle management device 26 does not need to store the new authentication information AT in the storage device 28.

[0162] The following describes a case where the vehicle 20 receives new authentication information AT when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, the vehicle management device 26 does not need to select the authentication information AT to delete if it is possible to delete any of the pieces of authentication information AT stored in the storage device 28. For example, the vehicle management device 26 may randomly delete the authentication information AT stored in the storage device 28.

[0163] The following describes the case where new authentication information AT is received when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, the vehicle management device 26 may be configured so that, as long as any piece of authentication information AT stored in the storage device 28 can be deleted, none of the pieces of authentication information AT stored in the storage device 28 can be selected as a target for protection.

[0164] The following describes the case where new authentication information AT is received when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, the vehicle management device 26 may be configured not to set a priority for the authentication information AT stored in the storage device 28, as long as it is possible to delete any of the pieces of authentication information AT stored in the storage device 28.

[0165] The following describes the case where new authentication information AT is received when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, the vehicle management device 26 does not need to delete all pieces of authentication information AT that are the subject of unexecuted deletion reservations D41, as long as it can delete any of the pieces of authentication information AT stored in the storage device 28.

[0166] The following describes the case where new authentication information AT is received when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, the vehicle management device 26 does not need to delete the authentication information AT that is the subject of an unexecuted deletion reservation D41, as long as it can delete any of the pieces of authentication information AT stored in the storage device 28.

[0167] The following describes the case where new authentication information AT is received when the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the preset number that can be stored. In this case, the vehicle management device 26 may delete the authentication information AT corresponding to the friend key KF, which is the second digital key, from the authentication information AT corresponding to the friend key KF, which is the second digital key, and the authentication information AT corresponding to the non-friend key KN, which is the third digital key.

[0168] The vehicle management device 26 may be configured to be able to set a priority for the authentication information AT that is the subject of an unexecuted deletion reservation D41 stored in the storage device 28. For example, the vehicle management device 26 may be configured to set a lower priority for the authentication information AT with a shorter remaining fade-out period. For example, the vehicle management device 26 may be configured to set a lower priority for the authentication information AT that entered the fade-out state earlier.

[0169] When the execution device 27 of the vehicle management device 26 executes the vehicle program PV to perform processing related to the replacement of the authentication information AT, the execution device 71 of the management server 70 does not need to execute the replacement program PM. When the execution device 27 of the vehicle management device 26 executes the vehicle program PV to perform processing related to the replacement of the authentication information AT, the storage device 72 of the management server 70 does not need to store the replacement program PM.

[0170] (Second embodiment) The vehicle management device 26 and management server 70 according to the second embodiment will be described below with reference to Figures 7, 12, and 13. The second embodiment will be described mainly focusing on the differences from the first embodiment.

[0171] The following describes the case where the vehicle management device 26 receives new authentication information AT when the number of pieces of authentication information AT stored in the storage device 28 has reached the preset number that can be stored. At this time, the vehicle management device 26 in the second embodiment deletes the new authentication information AT stored in the storage device 28 based on another registration request D31 from the device 30 that has made a registration request D31 to store the key information DK corresponding to the new authentication information AT in the device 30.

[0172] <Series of processes executed by the vehicle 20> Figure 12 is an explanatory diagram showing the flow of a series of processes performed by vehicle 20 in management system 10 when new authentication information AT is received when the number of authentication information AT stored in memory device 28 has reached the specified number that can be stored.

[0173] The second device 30B is a friend device 51 in which a friend key KF is registered based on a registration request D21 from the owner device 40. The fourth device 30D is a non-friend device 52 in which a non-friend key KN is registered based on a registration request D31 from the second device 30B. The third device 30C is a device 30 that does not store non-friend key information DKN and that is designated as a non-friend device 52 by this series of processes.

[0174] When an operation is executed in the second device 30B, which is the friend device 51, to request the third device 30C to register a non-friend key KN, the management system 10 performs a series of processes shown in Figure 7 to register the non-friend key KN.

[0175] 7, the management server 70 transmits the authentication package ATP of the non-friend key information DKN and a storage request D34 for storing the authentication package ATP to the vehicle 20. After that, when the vehicle 20 receives the authentication package ATP and the storage request D34, the vehicle 20 performs the processing of step S104 shown in FIG.

[0176] <Select the authentication information AT to delete and replace the authentication information AT> In step S104, similarly to the first embodiment, the vehicle 20 selects the authentication package ATP in the non-friend key information DKN of the third device 30C and the authentication information AT to be deleted from the authentication information AT stored in the storage device 28. Thereafter, the vehicle 20 performs the process of step S401.

[0177] In step S401, if the vehicle 20 has stored authentication information AT based on another registration request D31 from the second device 30B that made the registration request D31 to store the authentication information AT in the third device 30C, the vehicle 20 selects the authentication information AT as the authentication information AT to be deleted. The result of the selection made by the vehicle 20 in step S401 takes priority over the result of the selection made by the vehicle 20 in step S102.

[0178] The fourth device 30D is a non-friend device 52 in which a non-friend key KN has been registered based on a registration request D31 from the second device 30B. The vehicle 20 deletes the authentication information AT corresponding to the non-friend key information DKN indicating the non-friend key KN of the fourth device 30D. The vehicle 20 then stores the authentication package ATP of the non-friend key information DKN of the third device 30C.

[0179] That is, the vehicle 20 replaces the authentication package ATP in the non-friend key information DKN of the third device 30C with the authentication information AT of the non-friend key KN of the fourth device 30D and stores the replaced information. Thereafter, the vehicle 20 performs the process of step S402.

[0180] <Processing after replacing authentication information AT> In step S402, the vehicle management device 26 generates a completion notification M71. The completion notification M71 includes a signal indicating that the authentication information AT of the non-friend key KN of the third device 30C has been replaced with the authentication information AT of the non-friend key KN of the fourth device 30D and stored. The completion notification M71 includes a signal that causes the management server 70 to transmit to the third device 30C a signal indicating that the storage device 28 has stored the authentication information AT of the non-friend key KN of the third device 30C. The completion notification M71 includes a signal indicating that the authentication information AT of the non-friend key KN of the third device 30C has been replaced with the authentication information AT of the non-friend key KN of the fourth device 30D and stored. The completion notification M71 includes a signal that causes the management server 70 to transmit the signal to the fourth device 30D, the second device 30B, and the owner device 40. The vehicle management device 26 transmits the completion notification M71 to the management server 70.

[0181] When the management server 70 receives the completion notification M71, the management server 70 executes the process of step S403. In step S403, the management server 70 generates a completion notification M72. The completion notification M72 includes a signal indicating that the authentication information AT of the non-friend key KN of the third device 30C has been stored in the storage device 28. The management server 70 transmits the completion notification M72 to the third device 30C.

[0182] After the process of step S403, the management server 70 executes the process of step S404. In step S404, the management server 70 generates a replacement notification M73, a replacement notification M74, and a replacement notification M75. The replacement notification M73, the replacement notification M74, and the replacement notification M75 include signals indicating that the authentication information AT of the non-friend key KN of the third device 30C has been replaced with the authentication information AT of the non-friend key KN of the fourth device 30D and stored. The management server 70 transmits the replacement notification M73 to the fourth device 30D. The management server 70 transmits the replacement notification M74 to the second device 30B. The management server 70 transmits the replacement notification M75 to the owner device 40. The process continues in FIG. 14.

[0183] 13, when the third device 30C receives the completion notification M72, the third device 30C performs the process of step S405. In step S405, the third device 30C displays on the HMI 32 information indicating that the registration of the non-friend key KN of the third device 30C to the vehicle 20 has been completed.

[0184] When the fourth device 30D receives the replacement notification M73, the fourth device 30D performs the process of step S406. In step S406, the fourth device 30D presents to the HMI 32 information indicating that the storage device 28 has replaced and stored the authentication information AT of the non-friend key KN of the third device 30C with the authentication information AT of the non-friend key KN of the fourth device 30D.

[0185] When the second device 30B receives the replacement notification M74, the second device 30B performs the process of step S407. In step S407, the second device 30B presents to the HMI 32 information indicating that the storage device 28 has replaced and stored the authentication information AT of the non-friend key KN of the third device 30C with the authentication information AT of the non-friend key KN of the fourth device 30D.

[0186] When the owner device 40 receives the replacement notification M75, the owner device 40 performs the process of step S408. In step S408, the owner device 40 presents to the HMI 32 information indicating that the storage device 28 has replaced and stored the authentication information AT of the non-friend key KN of the third device 30C with the authentication information AT of the non-friend key KN of the fourth device 30D. Thereafter, the management system 10 ends the series of processes for replacing the authentication information AT this time.

[0187] <Operation of the Second Embodiment> When the vehicle management device 26 receives the authentication information AT corresponding to the key information DK of the third device 30C, the vehicle management device 26 deletes the authentication information AT corresponding to the key information DK of the third device 30C that is stored in the storage device 28 based on another registration request D31 from the second device 30B that made the registration request D31 corresponding to the authentication information AT corresponding to the key information DK of the third device 30C. Therefore, the authentication information AT stored in the storage device 28 based on the registration request D31 from a device other than the second device 30B and the authentication information AT stored in the storage device 28 based on the registration request D21 from the owner device 40 are not deleted.

[0188] <Effects of the second embodiment> (2-1) The vehicle management device 26 can prevent the authentication information AT already stored in the storage device 28 based on a registration request D31 from a device other than the second device 30B from being deleted due to the registration request D31 from the second device 30B. The vehicle management device 26 can prevent the authentication information AT already stored in the storage device 28 based on a registration request D21 from the owner device 40 from being deleted due to the registration request D31 from the second device 30B.

[0189] <Modification of the second embodiment> The second embodiment can be modified as follows: The second embodiment described above and the following modifications of the second embodiment can be combined and implemented as long as they are not technically inconsistent.

[0190] The following describes a case where, when the vehicle management device 26 receives new authentication information AT, it deletes the authentication information AT stored in the storage device 28 based on another registration request D31 from the device 30 that made the registration request D31 corresponding to the new authentication information AT. In this case, the vehicle management device 26 does not need to generate a signal indicating that the storage device 28 has stored the authentication information AT of the non-friend key KN of the third device 30C. Similarly, the vehicle management device 26 does not need to generate a signal indicating that the authentication package ATP of the non-friend key information DKN of the third device 30C has been replaced with the authentication information AT of the non-friend key KN of the fourth device 30D and stored.

[0191] The vehicle management device 26 may delete the new authentication information AT stored in the storage device 28 based on another registration request D21 from the owner device 40 that made the registration request D21 corresponding to the new authentication information AT.

[0192] (Third embodiment) The vehicle management device 26 and management server 70 according to the third embodiment will be described below with reference to Figures 1, 7, 14, and 15. The following describes a case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for that vehicle 20 has reached the preset number that can be stored. At this time, the management server 70 according to the third embodiment transmits to the vehicle 20 a command to store the new authentication information AT in place of any of the pieces of authentication information AT stored in the storage device 28.

[0193] Specifically, when the number of pieces of authentication information AT stored in the storage device 28 has reached the preset number that can be stored, and the management server 70 receives a request to store new authentication information AT for the vehicle 20, the management server 70 deletes one of the pieces of authentication information AT stored in the storage device 28. Thereafter, the management server 70 stores the received authentication information AT in the storage device 28.

[0194] <Series of processes executed by the management server 70> Figure 14 is an explanatory diagram showing the flow of a series of processes performed by the management server 70 in the management system 10 when new authentication information AT for the vehicle 20 is received when the number of authentication information AT stored in the memory device 28 of the vehicle 20 has reached the specified number that can be stored.

[0195] 1, in the management server 70, a storage device 72 stores a replacement program PM. An execution device 71 executes the replacement program PM stored in the storage device 72. In this way, the management server 70 executes a series of processes.

[0196] 14 is a device 30 that does not store non-friend key information DKN and that is designated as a non-friend device 52 by the series of processes. When an operation is executed in a friend device 51 (not shown) to request the third device 30C to register a non-friend key KN, the management system 10 performs the series of processes shown in FIG. 7 to register the non-friend key KN.

[0197] Step S501 shown in Figure 14 is similar to step S47 shown in Figure 7. After processing step S501, the third device 30C performs processing step S502. The processing step S502 shown in Figure 14 is similar to step S48 shown in Figure 7. In the processing step S502, the third device 30C transmits non-friend key information DKN and a key track request D33 for the non-friend key KN to the management server 70. The key track request D33 is a request to store new authentication information AT in the vehicle 20.

[0198] 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 S503. In step S503, the management server 70 performs registration management of the non-friend key KN. Specifically, the management server 70 checks whether 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.

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

[0200] The management server 70 of the third embodiment stores, as data DA of the vehicle 20 in the database DB, the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 and the number of pieces of authentication information AT that can be stored in the storage device 28 of the vehicle 20. In other words, the management server 70 can determine whether the number of pieces of authentication information AT stored in the vehicle 20 has reached the predetermined number that can be stored by the vehicle 20. In step S504, the management server 70 determines whether the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored.

[0201] If the management server 70 determines that the number of pieces of authentication information AT stored in the storage device 28 has not reached the predetermined number that the storage device 28 can store, the management server 70 transmits the authentication package ATP and a storage request D34 for storing the authentication package ATP to the vehicle 20. Thereafter, the management system 10 performs the processes from step S50 onwards shown in FIG.

[0202] If the management server 70 determines that the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the predetermined number that the storage device 28 can store, the management server 70 performs processing in step S505.

[0203] <Select the authentication information AT to delete> In step S505, the management server 70 selects the authentication information AT to be deleted from the authentication information AT stored in the storage device 28 of the vehicle 20.

[0204] 15 is a flowchart showing the process of selecting authentication information AT to be deleted, which is performed by the management server 70 in step S505. The management server 70 performs this series of processes as the process of step S505.

[0205] <Determining the fade-out state> 15, when this series of processes starts, in step S510, the management server 70 determines whether or not the deletion reservation D41 remains unexecuted. The management server 70 determines that the deletion reservation D41 remains unexecuted when authentication information AT of a faded-out digital key is stored in the storage device 28 of the vehicle 20. If the deletion reservation D41 remains unexecuted (step S510: YES), the management server 70 proceeds to step S511.

[0206] In step S511, the management server 70 determines whether multiple deletion reservations D41 remain unexecuted. The management server 70 determines that multiple deletion reservations D41 remain unexecuted when authentication information AT of multiple faded-out digital keys is stored in the storage device 28 of the vehicle 20. If multiple deletion reservations D41 remain unexecuted (step S511: YES), the management server 70 proceeds to step S512.

[0207] In step S512, the management server 70 generates a signal to cause the vehicle 20 to delete all authentication information AT of the faded-out digital key stored in the storage device 28 of the vehicle 20. That is, the management server 70 generates a signal to cause the vehicle 20 to delete all authentication information AT that is the subject of the remaining unexecuted deletion reservation D41 from the storage device 28 of the vehicle 20. The management server 70 then transmits the signal to the vehicle 20. The management server 70 then terminates the series of processes shown in FIG. 15. In response to the signal, the vehicle 20 deletes all authentication information AT of the faded-out digital key stored in the storage device 28 of the vehicle 20. As a result, the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 becomes less than the predetermined number that can be stored.

[0208] Thereafter, the management server 70 transmits the authentication package ATP of the non-friend key information DKN and a storage request D34 to store the authentication package ATP to the vehicle 20. The management server 70 transmits a key track completion notification M33 to the third device 30C. Having received the authentication package ATP of the non-friend key information DKN and the storage request D34 to store the authentication package ATP, the vehicle 20 performs the process of step S50 shown in FIG. 7. Having received the key track completion notification M33, the third device 30C performs the process of step S51 shown in FIG. 7. This causes the management system 10 to end the series of processes.

[0209] If the storage device 28 of the vehicle 20 stores only one piece of authentication information AT for a faded-out digital key, that is, if there are no multiple deletion reservations D41 remaining (step S511: NO), the management server 70 proceeds to step S513.

[0210] In step S513, the management server 70 selects the authentication information AT of the digital key in the fade-out state as the authentication information AT to be deleted. After that, the management server 70 ends the series of processes shown in FIG.

[0211] In the process of step S510, if there are no deletion reservations D41 remaining (step S510: NO), the management server 70 proceeds to the process of step S514. <Determine whether or not there is authentication information AT selected as a protection target> The management server 70 is configured to be able to select each of the multiple pieces of authentication information AT stored in the database DB as a target for protection. For example, the user of the vehicle 20 can select each of the pieces of authentication information AT stored in the database DB as a target for protection via the HMI 32 of the owner device 40. For example, the user of the vehicle 20 can select each of the pieces of authentication information AT stored in the database DB as a target for protection via the HMI 32 of the friend device 51. For example, the user of the vehicle 20 can select each of the pieces of authentication information AT stored in the database DB as a target for protection via the HMI 32 of the non-friend device 52.

[0212] In step S514, the management server 70 determines whether any authentication information AT selected as a target for protection exists among the authentication information AT stored in the storage device 28 of the vehicle 20. If any authentication information AT selected as a target for protection exists (step S514: YES), the management server 70 selects authentication information AT to be deleted from the authentication information AT that is not a target for protection in the subsequent processing. Thereafter, the management server 70 proceeds to step S516. If any authentication information AT selected as a target for protection exists among the authentication information AT stored in the storage device 28 of the vehicle 20 (step S514: NO), the management server 70 proceeds to step S516.

[0213] <Determining whether priority is set for authentication information AT> The management server 70 is configured to be able to set priorities for the authentication information AT stored in the database DB. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the database DB via the HMI 32 of the owner device 40. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the database DB via the HMI 32 of the friend device 51. For example, the user of the vehicle 20 can set priorities for each piece of authentication information AT stored in the database DB via the HMI 32 of the non-friend device 52.

[0214] In step S516, the management server 70 determines whether a priority has been set for the authentication information AT stored in the storage device 28 of the vehicle 20. If a priority has been set for the authentication information AT stored in the storage device 28 of the vehicle 20 (step S516: YES), the management server 70 proceeds to step S517.

[0215] In step S517, the management server 70 determines whether two or more pieces of authentication information AT with different priorities are stored in the storage device 28 of the vehicle 20. If the storage device 28 stores two or more pieces of authentication information AT with different priorities (step S517: YES), the management server 70 proceeds to step S518.

[0216] In step S518, the management server 70 selects the authentication information AT to be deleted based on the priority. For example, the management server 70 selects the authentication information AT with the lowest priority as the authentication information AT to be deleted. After that, the management server 70 ends the series of processes shown in FIG. 15.

[0217] In step S516, if a priority has not been set for the authentication information AT stored in the storage device 28 of the vehicle 20 (step S516: NO), the management server 70 proceeds to step S519. In step S517, if the storage device 28 does not store two or more pieces of authentication information AT with different priorities (step S517: NO), the management server 70 proceeds to step S519.

[0218] <Determining whether authentication information AT of non-friend key KN is stored> In step S519, the management server 70 determines whether the authentication information AT of the non-friend key KN is stored in the storage device 28 of the vehicle 20. If the authentication information AT of the non-friend key KN is stored in the storage device 28 of the vehicle 20 (step S519: YES), the management server 70 proceeds to step S520.

[0219] In step S520, the management server 70 selects the authentication information AT of the non-friend key KN as the authentication information AT to be deleted from the authentication information AT stored in the storage device 28. After that, the management server 70 ends the series of processes shown in FIG.

[0220] In step S519, if the storage device 28 does not store authentication information AT for the non-friend key KN (step S519: NO), the management server 70 proceeds to step S521. In step S521, the management server 70 selects, from the authentication information AT stored in the storage device 28, the authentication information AT for the shared key KS with the oldest last used date as the authentication information AT to be deleted. Thereafter, the management server 70 ends the series of processes shown in FIG.

[0221] <Replace authentication information AT> Thereafter, the management server 70 transmits to the vehicle 20 the authentication package ATP and a replacement request D81 for replacing the authentication package ATP with the authentication information AT selected by the management server 70 in step S505 and storing the same. The replacement request D81 includes an instruction for the vehicle 20 to delete the authentication information AT selected by the management server 70 in step S505 from the storage device 28, and an instruction for the vehicle 20 to store the authentication package ATP as the authentication information AT for authenticating the non-friend key KN of the third device 30C.

[0222] Upon receiving the authentication package ATP and the replacement request D81, the vehicle 20 performs the processing of step S506. In step S506, the vehicle 20 stores the authentication package ATP in place of the authentication information AT stored in the storage device 28. Specifically, the management server 70 deletes the authentication information AT selected by the management server 70 in step S505 from the storage device 28. Thereafter, the vehicle 20 stores the authentication package ATP as the authentication information AT for authenticating the non-friend key KN of the third device 30C.

[0223] After performing the process of step S505, the management server 70 proceeds to step S507. In step S507, the management server 70 generates a completion notification M81. The completion notification M81 includes a signal indicating that the vehicle 20 has replaced the authentication information AT stored in the storage device 28 with the authentication package ATP and stored it. The management server 70 transmits the completion notification M81 to the third device 30C.

[0224] When the third device 30C receives the completion notification M62, the third device 30C performs the process of step S508. In step S508, the third device 30C presents registration completion information indicating that the registration of the non-friend key KN has been completed to the HMI 32. Thereafter, the management system 10 ends the series of processes for replacing the current authentication information AT.

[0225] <Operation of the Third Embodiment> When the number of pieces of authentication information AT stored in the vehicle 20 has reached a predetermined number and new pieces of authentication information AT are received, the management server 70 transmits a command to delete one of the pieces of authentication information AT stored in the storage device 28 without user intervention. The authentication information AT is information related to the digital key.

[0226] <Effects of the third embodiment> (3-1) According to the management server 70, when new authentication information AT is stored in the vehicle 20, the user of the vehicle 20 does not have to select which authentication information AT to delete from the authentication information AT stored in the vehicle 20. In other words, the management server 70 can reduce the burden on the user of the vehicle 20.

[0227] (3-2) The management server 70 can receive a deletion reservation D41 that causes the vehicle 20 to delete the target authentication information AT when a predetermined condition RC is met. The management server 70 stores whether or not any pending deletion reservations D41 remain in the database DB for the vehicle 20. The following describes a case where the management server 70 receives a request to store new authentication information AT for the vehicle 20 when the number of pieces of authentication information AT stored in the database DB for the vehicle 20 has reached the predetermined number that can be stored. Unexecuted deletion reservations D41 remain in the database DB for the vehicle 20. In this case, the management server 70 transmits to the vehicle 20 a command to delete one of the pieces of authentication information AT that are the subject of the unexecuted deletion reservations D41. As a result, the management server 70 causes the vehicle 20 to store the new authentication information AT by replacing the authentication information AT that is the subject of the unexecuted deletion reservation D41 with the new authentication information AT. That is, the management server 70 selects the authentication information AT scheduled to be deleted as the authentication information to replace the new authentication information AT. The management server 70 can store the new authentication information AT while keeping the authentication information AT that is not scheduled to be deleted stored.

[0228] (3-3) The following describes a case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for the vehicle 20 has reached the preset number that can be stored. Multiple deletion reservations D41 remain unexecuted in the vehicle 20. At this time, the management server 70 transmits to the vehicle 20 a command to delete the authentication information AT, as well as all pieces of authentication information AT that are the subject of each of the multiple deletion reservations D41, and to store new authentication information AT corresponding to the request. The management server 70 causes the vehicle 20 to delete all pieces of authentication information AT that are the subject of each of the multiple deletion reservations D41. The management server 70 causes the vehicle 20 to store the new authentication information AT in the vehicle 20 and also causes the vehicle 20 to secure storage capacity for storing further authentication information AT.

[0229] (3-4) The management server 70 is configured to allow the user of the vehicle 20 to set priorities for the authentication information AT stored in the vehicle 20. When the management server 70 receives a request to register new authentication information AT for a vehicle 20 for which the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored, the management server 70 selects the authentication information AT to be deleted based on the priorities that have already been set. The management server 70 sends a command to the vehicle 20 to delete the authentication information AT selected by the management server 70. The management server 70 selects the authentication information AT to be deleted in accordance with the priorities that have already been stored. The management server 70 can select the authentication information AT to be deleted, reflecting the intention of the user who set the priorities.

[0230] (3-5) The management server 70 is configured to allow the user of the vehicle 20 to select authentication information AT to be protected from among the multiple pieces of authentication information AT stored in the vehicle 20. The management server 70 transmits to the vehicle 20 a command to delete any of the multiple pieces of authentication information AT that have not been selected as items to be protected. The management server 70 can set two levels of priority for the multiple pieces of authentication information AT stored in the vehicle 20: authentication information AT that has been selected as items to be protected, and authentication information AT that has not been selected as items to be protected. The management server 70 can reflect the user's intentions by preventing the deletion of authentication information AT that has been selected as items to be protected.

[0231] (3-6) The following describes the case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for that vehicle 20 has reached the preset number that can be stored. The storage device 28 stores authentication information AT for authenticating the friend key KF and authentication information AT for authenticating the non-friend key KN. At this time, the management server 70 sends a command to the vehicle 20 to delete the authentication information AT for authenticating the non-friend key KN. The management server 70 can protect the authentication information AT for authenticating the friend key KF registered by the owner of the vehicle 20. This can reduce the frequency of the owner having to re-register the friend key KF by deleting the authentication information AT for authenticating the friend key KF.

[0232] <Modification of the third embodiment> The third embodiment can be implemented with the following modifications: The third embodiment and the following modifications can be implemented in combination with each other within the scope of no technical contradiction.

[0233] The following describes the case where the management server 70 receives a request to store new authentication information AT for the vehicle 20 when the number of pieces of authentication information AT stored in the database DB for the vehicle 20 has reached the preset number that can be stored. At this time, if the management server 70 can cause the vehicle 20 to delete any of the pieces of authentication information AT stored in the vehicle 20, it does not need to select the authentication information AT to be deleted from the authentication information AT stored in the vehicle 20. For example, the management server 70 may send a command to the vehicle 20 to randomly delete any of the pieces of authentication information AT stored in the storage device 28 of the vehicle 20.

[0234] The following describes the case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for that vehicle 20 has reached the preset number that can be stored. In this case, the management server 70 does not need to be able to select the authentication information AT as the target for protection, as long as it can send a command to the vehicle 20 to delete any of the pieces of authentication information AT stored in the storage device 28.

[0235] The following describes the case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for that vehicle 20 has reached the preset number that can be stored. In this case, the management server 70 does not need to be able to set a priority for the authentication information AT, as long as it can send a command to the vehicle 20 to delete any of the pieces of authentication information AT stored in the storage device 28.

[0236] The following describes the case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for that vehicle 20 has reached the preset number that can be stored. In this case, the management server 70 does not need to cause the vehicle 20 to delete the authentication information AT that is the subject of an unexecuted deletion reservation D41, as long as the management server 70 can send a command to the vehicle 20 to delete any of the pieces of authentication information AT stored in the storage device 28.

[0237] The following describes the case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for the vehicle 20 has reached the preset number that can be stored. At this time, the management server 70 may cause the vehicle 20 to delete authentication information AT other than the authentication information AT that is the subject of an unexecuted deletion reservation D41.

[0238] The following describes the case where the management server 70 receives a request to store new authentication information AT for a vehicle 20 when the number of pieces of authentication information AT stored in the database DB for that vehicle 20 has reached the preset number that can be stored. The storage device 28 stores authentication information AT for authenticating the friend key KF and authentication information AT for authenticating the non-friend key KN. At this time, the management server 70 may cause the vehicle 20 to delete the authentication information AT for authenticating the friend key KF from the authentication information AT stored in the storage device 28.

[0239] The management server 70 may be configured to be able to set priorities for the authentication information AT that is the subject of an unexecuted deletion reservation D41 stored in the database DB for the vehicle 20. For example, the management server 70 may be configured to set a lower priority for the authentication information AT with a shorter remaining fade-out period. For example, the management server 70 may be configured to set a lower priority for the authentication information AT that entered the fade-out state earlier.

[0240] (Fourth embodiment) The vehicle management device 26 and management server 70 according to the fourth embodiment will be described below with reference to Fig. 7 and Fig. 14 to Fig. 17. The fourth embodiment will be described mainly focusing on the differences from the third embodiment.

[0241] The following describes a case where the management server 70 receives a request to store new authentication information AT for the vehicle 20 when the number of pieces of authentication information AT stored in the database DB for the vehicle 20 has reached the preset number that can be stored. At this time, the management server 70 transmits to the vehicle 20 a command to delete the authentication information AT stored in the storage device 28 based on another registration request D31 from the device 30 that has made a registration request D31 to store the key information DK corresponding to the new authentication information AT in the device 30.

[0242] <Series of processes executed by the management server 70> Figure 16 is an explanatory diagram showing the flow of a series of processes performed by the management server 70 in the management system 10 when the number of authentication information AT stored in the database DB for the vehicle 20 has reached the specified number that can be stored and the management server 70 receives a request to store new authentication information AT for the vehicle 20.

[0243] The second device 30B is a friend device 51 in which a friend key KF has been registered based on a registration request D21 from the owner device 40. The second device 30B stores friend key information DKF. The fourth device 30D is a non-friend device 52 in which a non-friend key KN has been registered based on a registration request D31 from the second device 30B, which is the friend device 51. The fourth device 30D stores non-friend key information DKN. The third device 30C is a device 30 that does not store non-friend key information DKN and that is designated as a non-friend device 52 by this series of processes.

[0244] When an operation is executed in the second device 30B, which is the friend device 51, to request the third device 30C to register a non-friend key KN, the management system 10 performs a series of processes shown in Figure 7 to register the non-friend key KN.

[0245] 7, 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.

[0246] When the management server 70 receives the key track request D33 for the non-friend key KN, the management server 70 performs the process of step S503 shown in Fig. 14. The process performed by the management server 70 in step S503 is the same as that in the third embodiment. Thereafter, the management server 70 performs the process of step S504 shown in Fig. 16. The process performed by the management server 70 in step S504 is the same as that in the third embodiment.

[0247] The management server 70 stores, as data DA of the vehicle 20 in the database DB, the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 and the number of pieces of authentication information AT that can be stored in the storage device 28 of the vehicle 20. In step S504, the management server 70 determines whether the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored.

[0248] The following describes a case where the management server 70 determines that the number of pieces of authentication information AT stored in the storage device 28 has not reached the predetermined number that can be stored by the storage device 28. In this case, the management server 70 transmits the authentication package ATP of the non-friend key information DKN of the third device 30C and a storage request D34 for storing the authentication package ATP to the vehicle 20. Thereafter, the management system 10 performs the processes from step S50 onwards shown in FIG.

[0249] The following describes a case where the management server 70 determines that the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the predetermined number that can be stored in the storage device 28. In this case, the management server 70 performs the processes from step S601 onwards shown in FIG.

[0250] In step S601, the management server 70 selects, from the authentication information AT stored in the storage device 28 of the vehicle 20, authentication information AT to replace the authentication package ATP. 15 is a flowchart showing the process of selecting authentication information AT to replace the authentication package ATP, which is performed by the management server 70 in step S601. The management server 70 performs a series of processes shown in FIG. 15 as the process of step S601, similar to step S505 in the third embodiment.

[0251] 15, the management server 70 determines whether the storage device 28 stores authentication information AT based on another registration request D31 from the second device 30B, which has made a registration request D31 to store key information DK in the third device 30C. If the storage device 28 stores the authentication information AT, the management server 70 selects the authentication information AT as the authentication information AT to be deleted. The result of this selection takes priority over the result of the selection by the series of processes shown in FIG. 15.

[0252] The fourth device 30D is a non-friend device 52 that stores non-friend key information DKN indicating the non-friend key KN based on a registration request D31 from the second device 30B. The storage device 28 of the vehicle 20 stores authentication information AT corresponding to the non-friend key information DKN stored in the fourth device 30D. The management server 70 selects the authentication information AT corresponding to the non-friend key information DKN stored in the fourth device 30D as the replacement authentication information AT.

[0253] The management server 70 transmits to the vehicle 20 the authentication package ATP and a replacement request D91, which is a command to replace the authentication package ATP with the authentication information AT corresponding to the non-friend key information DKN stored in the fourth device 30D and store the same. The replacement request D91 includes a command to delete the authentication information AT corresponding to the non-friend key information DKN stored in the fourth device 30D. The replacement request D91 includes a command to store the authentication package ATP from the non-friend key information DKN of the third device 30C.

[0254] Upon receiving the authentication package ATP and the replacement request D91, the vehicle 20 performs the process of step S602. In step S602, the vehicle 20 deletes the authentication information AT corresponding to the non-friend key information DKN stored in the fourth device 30D. Then, the vehicle 20 stores the authentication package ATP included in the non-friend key information DKN of the third device 30C. That is, the vehicle 20 replaces the authentication package ATP included in the non-friend key information DKN of the third device 30C with the authentication information AT corresponding to the non-friend key information DKN stored in the fourth device 30D and stores the replaced authentication package ATP.

[0255] <Processing after the vehicle 20 stores the authentication information AT> After the process of step S601, the management server 70 executes the process of step S603. In step S603, the management server 70 generates a completion notification M92. The completion notification M92 includes a signal indicating that the authentication information AT of the non-friend key information DKN of the third device 30C has been stored in the storage device 28. The management server 70 transmits the completion notification M92 to the third device 30C.

[0256] After the process of step S603, the management server 70 executes the process of step S604. In step S604, the management server 70 generates a replacement notification M93, a replacement notification M94, and a replacement notification M95. The replacement notification M93, the replacement notification M94, and the replacement notification M95 include signals indicating that the authentication information AT corresponding to the key information DK of the fourth device 30D has been replaced with the authentication package ATP of the key information DK of the third device 30C. The management server 70 transmits the replacement notification M93 to the fourth device 30D. The management server 70 transmits the replacement notification M94 to the second device 30B. The management server 70 transmits the replacement notification M95 to the owner device 40. After that, the process continues to FIG. 17.

[0257] 17, upon receiving the completion notification M92, the third device 30C performs the process of step S605. In step S605, the third device 30C presents to the HMI 32 a registration completion message indicating that the authentication package ATP of the key information DK of the third device 30C has been registered in the vehicle 20 as authentication information AT.

[0258] When the fourth device 30D receives the replacement notification M93, it performs the process of step S606. In step S606, the fourth device 30D presents to the HMI 32 information indicating that the authentication information AT corresponding to the key information DK of the fourth device 30D has been replaced with the authentication package ATP of the key information DK of the third device 30C.

[0259] Upon receiving the replacement notification M94, the second device 30B performs the process of step S607. In step S607, the second device 30B presents to the HMI 32 information indicating that the authentication information AT corresponding to the key information DK of the fourth device 30D has been replaced with the authentication package ATP of the key information DK of the third device 30C.

[0260] Upon receiving the replacement notification M95, the owner device 40 performs the process of step S608. In step S608, the owner device 40 presents to the HMI 32 information indicating that the authentication information AT corresponding to the key information DK of the fourth device 30D has been replaced with the authentication package ATP of the key information DK of the third device 30C. Thereafter, the management system 10 ends the series of processes for replacing the authentication information AT this time.

[0261] <Operation of the Fourth Embodiment> When the management server 70 receives new authentication information AT, it transmits to the vehicle 20 a command to delete the authentication information AT stored in the storage device 28 based on another registration request D31 from the second device 30B that made the registration request D31 corresponding to the authentication information AT. Therefore, the authentication information AT stored in the storage device 28 based on the registration request D31 from a device other than the second device 30B and the authentication information AT stored in the storage device 28 based on the registration request D21 from the owner device 40 are not deleted.

[0262] <Effects of the Fourth Embodiment> (4-1) The management server 70 can prevent the authentication information AT already stored in the storage device 28 based on a registration request D31 from a device other than the second device 30B from being deleted due to the registration request D31 from the second device 30B. The management server 70 can prevent the authentication information AT already stored in the storage device 28 based on the registration request D21 from the owner device 40 from being deleted due to the registration request D31 from the second device 30B.

[0263] (4-2) The following describes the case where the management server 70 transmits to the vehicle 20 a command to delete, together with new authentication information AT, one of the pieces of authentication information AT stored in the storage device 28. At this time, the management server 70 notifies the owner device 40 that the authentication information AT has been deleted from the vehicle 20. This allows the management server 70 to inform the owner of the vehicle 20 that one of the pieces of authentication information AT stored in the vehicle 20 has been deleted.

[0264] (4-3) The following describes the case where the management server 70 sends to the vehicle 20 a command to delete, together with new authentication information AT, any of the authentication information ATs stored in the storage device 28. At this time, the management server 70 notifies the sharing device 50 that made the registration request D31 corresponding to the authentication information AT to be deleted that the authentication information AT has been deleted. This allows the management server 70 to inform the user of the sharing device 50 that made the registration request D31 corresponding to the deleted authentication information AT that the authentication information AT has been deleted.

[0265] (4-4) The following describes the case where the management server 70 sends to the vehicle 20 a command to delete, along with new authentication information AT, any of the authentication information AT stored in the storage device 28. At this time, the management server 70 notifies the sharing device 50 that stores the key information DK corresponding to the deleted authentication information AT that the authentication information AT has been deleted. The device 30 that stores the key information DK corresponding to the deleted authentication information AT will no longer be able to use the vehicle 20. The management server 70 can notify the user of the sharing device 50 that the digital key registered to the sharing device 50 has become unusable. This allows the user to realize that the digital key is unusable before actually attempting to use the vehicle 20.

[0266] <Modification of the Fourth Embodiment> The above-described fourth embodiment can be modified and implemented as follows: The above-described fourth embodiment and the following modifications of the fourth embodiment can be implemented in combination with each other within the scope of technical compatibility.

[0267] The management server 70 may notify the owner device 40 of only the deleted authentication information AT. The management server 70 may not send a notification to the owner device 40. Even in these cases, the management server 70 can delete the authentication information AT without intervention by the user of the vehicle 20. Therefore, the management server 70 can reduce the burden on the user.

[0268] When the management server 70 deletes the authentication information AT, it does not have to send a notification to the shared device 50 that requested registration of the digital key corresponding to the authentication information AT. Even in this case, the management server 70 can delete the authentication information AT without intervention by the user of the vehicle 20. Therefore, the management server 70 can reduce the burden on the user.

[0269] The management server 70 does not have to send a notification to the shared device 50 whose authentication information AT is to be replaced. Even in this case, the management server 70 can delete the authentication information AT without intervention by the user of the vehicle 20. Therefore, the management server 70 can reduce the burden on the user.

[0270] When the management server 70 receives new authentication information AT, it may send a command to the vehicle 20 to delete the authentication information AT stored in the storage device 28 based on another registration request D21 made by the owner device 40 that made the registration request D21 corresponding to the authentication information AT.

[0271] (Fifth embodiment) A vehicle management device 26 and a management server 70 according to a fifth embodiment will be described below with reference to FIGS. 7, 15, 18, and 19. The fifth embodiment will be described, focusing on the differences from the third embodiment. In the fifth embodiment, the management server 70 stores digital keys in a database DB for a vehicle 20 in multiple fade-out states. The management server 70 according to the fifth embodiment transmits to the vehicle 20 a command to delete all pieces of authentication information AT that are the subject of multiple deletion reservations D41, new authentication information AT, and a command to store the new authentication information AT. At this time, the management server 70 notifies multiple shared devices that store key information DK corresponding to the authentication information AT that are the subject of multiple deletion reservations D41 that the authentication information AT corresponding to the key information DK has been deleted.

[0272] <Series of processes executed by the management server 70> 18, in step S700, the management server 70 stores that the friend key KF indicated by the friend key information DKF stored in the fifth device 30E is in a fade-out state. The management server 70 stores that the non-friend key KN indicated by the non-friend key information DKN stored in the sixth device 30F is in a fade-out state. The management server 70 in step S700 is in a state where multiple deletion reservations D41 remain unexecuted.

[0273] 18 is a device 30 that does not store non-friend key information DKN and that is designated as a non-friend device 52 by the series of processes. In the second device 30B, which is a friend device 51 (not shown), an operation is executed to request the third device 30C to register a non-friend key KN, and the management system 10 performs the series of processes shown in FIG.

[0274] Step S701 shown in Fig. 18 is similar to step S47 shown in Fig. 7. After the processing of step S701, the third device 30C performs the processing of step S702. The processing of step S702 shown in Fig. 18 is similar to step S48 shown in Fig. 7. In the processing of step S702, the third device 30C transmits non-friend key information DKN and a key track request D33 of the non-friend key KN to the management server 70.

[0275] 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 S703. In step S703, the management server 70 performs registration management of the non-friend key KN. Specifically, the management server 70 checks whether 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.

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

[0277] The management server 70 stores, as data DA of the vehicle 20 in the database DB, the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 and the number of pieces of authentication information AT that can be stored in the storage device 28 of the vehicle 20. In step S704, the management server 70 determines whether the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored.

[0278] If the management server 70 determines that the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has not reached the predetermined number that can be stored by the storage device 28, the management server 70 transmits the authentication package ATP and a storage request D34 to the vehicle 20. Thereafter, the management system 10 performs the processes from step S50 onwards shown in FIG.

[0279] If the management server 70 determines that the number of pieces of authentication information AT stored in the storage device 28 of the vehicle 20 has reached the predetermined number that the storage device 28 can store, the management server 70 performs processing in step S705.

[0280] In step S705, the management server 70 selects, from the authentication information AT stored in the storage device 28 of the vehicle 20, authentication information AT to replace the authentication package ATP. 15 is a flowchart showing the process of selecting authentication information AT to replace the authentication package ATP, which is performed by the management server 70 in step S705. The management server 70 performs this series of processes as the process of step S705.

[0281] 15, when this series of processes starts, in step S510, the management server 70 determines whether the deletion reservation D41 remains unexecuted. If authentication information AT of a faded-out digital key is stored in the storage device 28 of the vehicle 20, the management server 70 determines that the deletion reservation D41 remains unexecuted. The storage device 28 of the vehicle 20 stores, as faded-out digital keys, the friend key KF of the fifth device 30E, which is the friend device 51, and the non-friend key KN of the sixth device 30F, which is the non-friend device 52. In other words, the deletion reservation D41 remains unexecuted (step S510: YES). Therefore, the management server 70 proceeds to step S511.

[0282] In step S511, the management server 70 determines whether multiple deletion reservations D41 remain unexecuted. If authentication information AT of multiple faded-out digital keys is stored in the storage device 28 of the vehicle 20, the management server 70 determines that multiple deletion reservations D41 remain unexecuted. The storage device 28 of the vehicle 20 stores authentication information AT of faded-out digital keys: authentication information AT of the friend key KF of the fifth device 30E and authentication information AT of the non-friend key KN of the sixth device 30F. In other words, multiple deletion reservations D41 remain unexecuted (step S511: YES). Therefore, the management server 70 proceeds to step S512.

[0283] In step S512, the management server 70 generates a signal to cause the vehicle 20 to delete all authentication information AT of the faded-out digital key stored in the storage device 28 of the vehicle 20. That is, the management server 70 generates a signal to cause the vehicle 20 to delete all authentication information AT that is the subject of the remaining unexecuted deletion reservation D41 from the storage device 28 of the vehicle 20. The management server 70 generates a deletion request D101 shown in FIG. 18 as this signal. Thereafter, the management server 70 transmits the deletion request D101 to the vehicle 20. Thereafter, the management server 70 ends the series of processes shown in FIG. 15.

[0284] After completing the series of processes shown in Fig. 15, in step S705 shown in Fig. 18, the management server 70 generates a storage request D102. The storage request D102 is a signal for storing the authentication package ATP in the storage device 28 of the vehicle 20. The management server 70 transmits the storage request D102 and the authentication package ATP to the vehicle 20.

[0285] When the vehicle 20 receives the deletion request D101, it performs the process of step S706. In step S706, the vehicle 20 deletes all authentication information AT of the faded-out digital key stored in the storage device 28 in accordance with the deletion request D101. As a result, the number of pieces of authentication information AT stored in the storage device 28 becomes less than the predetermined number that can be stored. Thereafter, the vehicle 20 performs the process of step S707 shown in FIG. 19.

[0286] In step S707, the vehicle 20 stores the received authentication package ATP in accordance with the storage request D102. That is, the vehicle 20 stores the authentication package ATP as authentication information AT for authenticating the non-friend key KN.

[0287] <Processing after the vehicle 20 stores the authentication information AT> After the process of step S705, the management server 70 generates a key track completion notification M101 as the process of step S708, and transmits the key track completion notification M101 to the third device 30C.

[0288] When the third device 30C receives the key track completion notification M101, it performs the process of step S709. In the process of step S709, 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 presents an image indicating the completion of registration of the non-friend key KN to the HMI 32.

[0289] After the processing of step S708, the management server 70 generates a deletion notification M102 and a deletion notification M103 as processing of step S710. The deletion notification M102 is a notification indicating that the authentication information AT corresponding to the non-friend key information DKN of the sixth device 30F has been deleted from the vehicle 20. The deletion notification M103 is a notification indicating that the authentication information AT corresponding to the friend key information DKF of the fifth device 30E and the authentication information AT corresponding to the non-friend key information DKN of the sixth device 30F have been deleted from the vehicle 20. The management server 70 transmits the deletion notification M102 to the sixth device 30F. The management server 70 transmits the deletion notification M103 to the fifth device 30E.

[0290] When the sixth device 30F receives the deletion notification M102, the sixth device 30F executes the process of step S711 in accordance with the deletion notification M102. In step S711, the sixth device 30F deletes the non-friend key information DKN corresponding to the authentication information AT deleted by the vehicle 20 from the storage device 37 of the sixth device 30F.

[0291] In step S711, the sixth device 30F presents information indicating that the non-friend key information DKN has been deleted to the HMI 32. The sixth device 30F presents information indicating that the authentication information AT of the non-friend key information DKN of the sixth device 30F has been deleted from the storage device 28 of the vehicle 20 to the HMI 32.

[0292] When the fifth device 30E receives the deletion notification M103, the fifth device 30E executes the process of step S712 in accordance with the deletion notification M103. In step S712, the fifth device 30E deletes, from the storage device 37 of the fifth device 30E, the non-friend key information DKN corresponding to the authentication information AT deleted by the vehicle 20. The fifth device 30E presents to the HMI 32 information indicating that the non-friend key information DKN corresponding to the authentication information AT deleted by the vehicle 20 has been deleted from the storage device 37 of the fifth device 30E.

[0293] In step S712, the fifth device 30E presents to the HMI 32 information indicating that the authentication information AT corresponding to the friend key information DKF of the fifth device 30E has been deleted from the vehicle 20. The fifth device 30E presents to the HMI 32 information indicating that the authentication information AT corresponding to the non-friend key information DKN of the sixth device 30F has been deleted from the vehicle 20. Thereafter, the management system 10 ends the series of processes.

[0294] <Operation of the Fifth Embodiment> The shared device 50 that stores the key information DK corresponding to the deleted authentication information AT will no longer be able to use the vehicle 20.

[0295] <Effects of the Fifth Embodiment> (5-1) The management server 70 can notify the user of the shared device 50 that the digital key registered to the shared device 50 has become unusable. This allows the user of the shared device 50 to realize that the digital key has become unusable before actually attempting to use the vehicle.

[0296] <Modification of the fifth embodiment> The fifth embodiment can be modified as follows: The fifth embodiment described above and the following modifications of the fifth embodiment can be combined and implemented within the scope of technical compatibility.

[0297] When the execution device 71 of the management server 70 executes the replacement program PM to perform processing related to replacing the authentication information AT, the execution device 71 of the vehicle management device 26 does not need to execute processing related to replacing the authentication information AT in the vehicle program PV. When the execution device 71 of the management server 70 executes the replacement program PM to perform processing related to replacing the authentication information AT, the storage device 28 of the vehicle 20 does not need to store processing related to replacing the authentication information AT as the vehicle program PV.

[0298] <Other change examples> Other elements that can be modified in common to the above embodiments include the following: The following modifications can be implemented in combination with each other within the scope of technical compatibility.

[0299] The digital key-related matters in the above embodiments do not have to comply with the CCC. The series of processes, including the process of deleting authentication information AT when the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored, is not limited to the examples of the above-described embodiments. For example, the management server 70 shown in FIG. 20 is configured to select one of the pieces of authentication information AT stored in the storage device 28 as the authentication information AT to be deleted. The management server 70 does not determine whether the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored. The vehicle 20 shown in FIG. 20 is configured to determine whether the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored. The vehicle 20 does not select any piece of authentication information AT to be deleted from the authentication information AT stored in the storage device 28. The third device 30C shown in FIG. 20 is a device 30 that does not store non-friend key information DKN and is designated as a non-friend device 52 by the series of processes.

[0300] In response to an operation performed in the friend device 51 (not shown) requesting the third device 30C to register a non-friend key KN, the management system 10 performs a series of processes shown in FIG. 7 to register the non-friend key KN. Step S801 shown in FIG. 20 is similar to step S47 shown in FIG. 7. After the process of step S801, the third device 30C performs the process of step S802. The process of step S802 shown in FIG. 20 is similar to step S48 shown in FIG. 7. The process of step S803 shown in FIG. 20 is similar to step S48 shown in FIG. 7.

[0301] In the processing of step S803, the management server 70 transmits the authentication package ATP of the non-friend key information DKN and a storage request D34 for storing the authentication package ATP to the vehicle 20. Thereafter, when the vehicle 20 receives the authentication package ATP and the storage request D34, the vehicle 20 performs the processing of step S804.

[0302] In step S804, the vehicle 20 determines whether the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored. If the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored, the vehicle 20 generates an upper limit notification M111. The upper limit notification M111 includes a signal indicating that the number of pieces of authentication information AT stored in the storage device 28 has reached the predetermined number that can be stored. The vehicle 20 transmits the upper limit notification M111 to the management server 70. By receiving the upper limit notification M111, the management server 70 can determine whether the number of pieces of authentication information AT stored in the vehicle 20 has reached the predetermined number that can be stored in the vehicle 20.

[0303] Upon receiving the upper limit notification M111, the management server 70 executes the process of step S805. In step S805, the management server 70 executes the same process as step S505 shown in FIG. 14. As a result, the management server 70 selects the authentication information AT to be deleted. Thereafter, the management server 70 transmits a replacement request D111 shown in FIG. 10 to the vehicle 20.

[0304] Upon receiving the replacement request D111, the vehicle 20 performs the process of step S806. In the process of step S806, the vehicle 20 performs the same process as step S105 shown in Fig. 10. After performing the process of step S806, the vehicle 20 proceeds to the process of step S807 shown in Fig. 20.

[0305] In step S807, the vehicle 20 generates a completion notification M112. The completion notification M112 includes a signal indicating that the vehicle 20 has replaced the authentication package ATP in the non-friend key information DKN of the third device 30C with the authentication information AT selected by the management server 70 in step S805 and stored it in the storage device 28. In other words, the completion notification M112 includes information that the authentication information AT selected by the management server 70 in step S805 has been deleted. The vehicle 20 transmits the completion notification M112 to the management server 70. Upon receiving the completion notification M112, the management server 70 performs the processing of step S808.

[0306] In step S808, the management server 70 generates a completion notification M113. The completion notification M113 includes a signal indicating that the vehicle 20 has replaced the authentication information AT stored in the storage device 28 of the vehicle 20 with the authentication package ATP in the non-friend key information DKN of the third device 30C and stored it. In other words, the completion notification M113 includes information that the authentication information AT selected by the management server 70 in step S805 has been deleted. The management server 70 transmits the completion notification M113 to the third device 30C.

[0307] When the third device 30C receives the completion notification M113, the third device 30C performs the process of step S809. In step S809, the third device 30C presents to the HMI 32 registration completion information indicating that the registration of the non-friend key KN of the third device 30C to the vehicle 20 has been completed. Thereafter, the management system 10 ends the series of processes for replacing the current authentication information AT.

[0308] <Send confirmation notification M121> When the management system 10 selects authentication information AT to be deleted from the authentication information AT stored in the storage device 28, the management system 10 may confirm with the user of the owner device 40 whether or not to allow the deletion of the authentication information AT.

[0309] 21 is an explanatory diagram showing the flow of a series of processes executed by the vehicle 20 after the vehicle 20 selects authentication information AT to be deleted from the authentication information AT stored in the storage device 28 in the series of processes shown in FIG. 10. As shown in FIG. 1, in the vehicle 20, the storage device 28 stores a vehicle program PV. The execution device 27 executes the vehicle program PV stored in the storage device 28. This causes the vehicle 20 to execute a series of processes. The owner device 40 is the first device 30A that stores key information DK indicating the owner key KO through the series of processes shown in FIG. 5.

[0310] In step S104, vehicle 20 performs the same process as step S104 shown in Fig. 10. When vehicle 20 selects authentication information AT to be deleted, vehicle 20 performs the process of step S105.

[0311] In step S901, the vehicle 20 generates a confirmation request D121. The confirmation request D121 is a request to the user of the owner device 40 for permission to delete the authentication information AT selected by the vehicle 20 in step S104. The vehicle 20 transmits the confirmation request D121 and the name information ATP5 included in the authentication information AT selected by the vehicle 20 in step S104 to the management server 70.

[0312] The management server 70 is configured to be able to receive a confirmation request D121 from the vehicle 20. Upon receiving the confirmation request D121, the management server 70 performs processing of step S902. In step S902, the management server 70 generates a confirmation notification M121, which is a notification requesting permission to delete the authentication information AT, in accordance with the confirmation request D121. The confirmation notification M121 includes information for allowing the device 30 to set whether or not to permit deletion of the authentication information AT through operation of the device 30. The management server 70 transmits the name information ATP5 received from the vehicle 20 and the confirmation notification M121 to the owner device 40.

[0313] <Processing Performed by the Owner Device 40 After Receiving the Confirmation Notification M121> The owner device 40 is configured to be able to receive the confirmation notification M121 from the management server 70. When the owner device 40 receives the confirmation notification M121, the owner device 40 performs the process of step S903. In step S903, the owner device 40 presents an image on the HMI 32 that prompts the user of the owner device 40 to set whether or not to permit deletion of the authentication information AT.

[0314] 22 is an example of an image presented on the HMI 32 of the owner device 40 to ask the user of the owner device 40 whether or not to allow the deletion of the authentication information AT. The "Name Information" field shown in FIG. 22 displays the name information ATP5 that the owner device 40 received from the management server 70. The user of the owner device 40 follows the instructions presented on the HMI 32 and selects either "YES" or "NO" using the radio button to indicate whether or not to allow the deletion of the authentication information AT.

[0315] <Step S903: YES> If the user of the owner device 40 selects "YES" using the radio button and then presses "OK" (step S903: YES), the owner device 40 generates a permission notification M122. The permission notification M122 is a notification that permits the deletion of the authentication information AT. The owner device 40 transmits the permission notification M122 to the management server 70.

[0316] <Processing performed by the management system 10 after receiving the permission notification M122> When the management server 70 receives the permission notification M122, it performs the process of step S904. In step S904, the management server 70 generates a continuation request D122. The continuation request D122 includes a signal that permits the vehicle 20 to delete the authentication information AT. The management server 70 transmits the continuation request D122 to the vehicle 20.

[0317] When vehicle 20 receives continuation request D122, it performs the process of step S105. In step S105, vehicle 20 performs the same process as step S105 shown in Fig. 10. That is, vehicle 20 deletes the authentication information AT from storage device 28. Thereafter, management system 10 performs the processes from step S106 onwards shown in Fig. 10.

[0318] <Step S93: NO> 21, if the user of the owner device 40 selects "NO" shown in FIG. 22 using the radio button and then presses "OK" (step S903: NO), the owner device 40 generates a rejection notification M123. The rejection notification M123 is a notification that rejects the deletion of the authentication information AT. The owner device 40 transmits the rejection notification M123 to the management server 70.

[0319] <Processing performed by the management system 10 after receiving the rejection notification M123> When the management server 70 receives the rejection notification M123, it performs the process of step S905. In step S905, the management server 70 generates a cancellation request D123. The cancellation request D123 is a request to the vehicle 20 to cancel the deletion of the authentication information AT. The management server 70 transmits the cancellation request D123 to the vehicle 20.

[0320] When the vehicle 20 receives the cancellation request D123, it performs the process of step S906. In step S906, the vehicle 20 cancels the deletion of the authentication information AT. Thereafter, the management system 10 ends the series of processes without deleting the authentication information AT from the storage device 28. In this case, new authentication information AT is not stored in the storage device 28.

[0321] By executing this series of processes, the management system 10 can confirm with the user of the owner device 40 whether or not to permit deletion of the authentication information. The management server 70 may transmit the confirmation notification M121 to the shared device 50. For example, the management server 70 may transmit the confirmation notification M121 to the shared device 50 that stores the same name information ATP as the name information ATP5 received from the vehicle 20 in step S903. The management server 70 may transmit the confirmation notification M121 to the owner device 40 and the shared device 50.

[0322] <Registration of a new non-friend key KN by the non-friend device 52> 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 storing the share key KS 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.

[0323] For example, as shown in FIG. 4, the third device 30C, which is the non-friend device 52 that stores key information DK indicating the non-friend key KN of the vehicle 20, may transmit a request to register a new non-friend key KN for the vehicle 20. As a result, a new device 30 that stores the key information DK for the new non-friend key KN of the vehicle 20 is registered as the non-friend device 52. In this case, the second device 30B that stores friend key information DKF indicating the friend key KF is the device 30 that stores key information DK indicating the first digital key. In other words, the first digital key is not limited to the owner key KO. The third device 30C that stores non-friend key information DKN indicating the non-friend key KN to be registered based on the registration request D31 from the second device 30B is the device 30 that stores key information DK indicating the second digital key. The new device that stores the key information DK indicating the new non-friend key KN to be registered based on a registration request from the third device 30C is the device 30 that stores the key information DK indicating the third digital key.

[0324] The storage device 28 of the vehicle 20 stores authentication information AT for authenticating the friend key KF as authentication information AT for authenticating the first digital key. The storage device 28 of the vehicle 20 stores authentication information AT for authenticating the non-friend key KN as authentication information AT for authenticating the second digital key. The storage device 28 of the vehicle 20 stores authentication information AT for authenticating the new non-friend key KN as authentication information AT for authenticating the third digital key.

[0325] The following describes a vehicle 20 in which authentication information AT for authenticating a second digital key and authentication information AT for authenticating a third digital key are stored in the storage device 28, and the number of pieces of authentication information AT stored in the storage device 28 has reached a predetermined number that can be stored. When the vehicle 20 receives new authentication information AT, it may select the authentication information AT for authenticating the new non-friend key KN stored in the vehicle 20 as the authentication information AT to be deleted. When the management server 70 receives a request to store new authentication information AT in the vehicle 20, it may send a command to the vehicle 20 to delete the authentication information AT for authenticating the new non-friend key KN stored in the vehicle 20.

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

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

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

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

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

[0331] The management server 70 may be configured with multiple servers. For example, it may be configured with a server that stores the database DB and a server that executes a server program. Also, for example, it may be configured with a server that communicates with the vehicle 20 and a server that communicates with the device server 60, and these servers may be able to communicate with each other.

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

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

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

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

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

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

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

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

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

[0341] The types of digital keys do not have to include non-friend keys KN. In other words, in the management system 10, the shared keys KS may only be friend keys KF. <The process for deleting a digital key> In the above embodiments, the friend device 51 transmits the deletion reservation D41 to the management server 70 when deleting the non-friend key KN, but this does not have to be a reservation request. That is, the friend device 51 may transmit a request to delete the non-friend key KN to the management server 70 regardless of the predetermined condition RC. Furthermore, the management server 70 may proceed with the processing from step S62 onwards in response to a request to delete the non-friend key KN not only from the friend device 51 but also from the owner device 40.

[0342] The following describes a case where an operation to request deletion of a non-friend key KN is executed in the non-friend device 52. In this case, instead of the process in step S81 of FIG. 9, the non-friend device 52 may send a request to delete the non-friend key KN registered in the non-friend device 52 to the management server 70. Upon receiving the request, the management server 70 generates a request to delete the non-friend key information DKN, similar to step S66 shown in FIG. 8. The management server 70 then sends a request to delete the non-friend key information DKN to the non-friend device 52. Having received the request to delete the non-friend key information DKN, the non-friend device 52 deletes the non-friend key information DKN, similar to step S67 shown in FIG. 8. The non-friend device 52 then transmits a notification to the management server 70 indicating that the non-friend key information DKN has been deleted. After receiving the notification indicating that the non-friend device 52 has deleted the non-friend key information DKN, the management server 70 proceeds with the process from step S82 onwards shown in FIG. 9. The non-friend device 52 does not need to send a notification indicating that the non-friend key information DKN has been deleted to the management server 70. In this case, the management server 70 sends a request to the non-friend device 52 to delete the non-friend key information DKN, and then proceeds with the processing from step S82 onwards shown in Figure 9.

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

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

[0345] <Additional Notes> The technical ideas that can be understood from the above-described embodiment and modified examples will be described. [Appendix 1] A vehicle management device mounted on a vehicle, comprising a storage device for storing information relating to a digital key, wherein when the amount of information relating to the digital key stored in the storage device has reached a predetermined number that can be stored, and new information relating to the digital key is received, the vehicle management device deletes any of the information relating to the digital key stored in the storage device.

[0346] [Appendix 2] A vehicle management device as described in Appendix 1, which deletes information about a digital key that is the subject of an unexecuted deletion reservation when new information about the digital key is received while the number of information about the digital key stored in the storage device has reached the predetermined number that can be stored and a deletion reservation, which is a command to execute the deletion of information about the target digital key when a predetermined condition is met, remains unexecuted.

[0347] [Appendix 3] A vehicle management device as described in Appendix 1 or Appendix 2, wherein when the number of pieces of information about the digital key stored in the storage device has reached the predetermined number that can be stored and there are multiple unexecuted deletion reservations, which are commands to execute the deletion of information about the target digital key when a predetermined condition is met, and new information about the digital key is received, the vehicle management device deletes all of the information about the digital key that is the subject of the unexecuted deletion reservations.

[0348] [Appendix 4] A vehicle management device as described in any one of Appendices 1 to 3, which is configured to allow the user of the vehicle to set priorities for information regarding the digital key stored in the storage device, and when new information regarding the digital key is received when the number of information regarding the digital key stored in the storage device has reached the predetermined number that can be stored, selects information regarding the digital key to be deleted based on the priority that has already been set.

[0349] [Appendix 5] A vehicle management device as described in any one of Appendices 1 to 4, which is configured to enable selection of information regarding a digital key to be protected from information regarding a plurality of digital keys stored in the storage device, and when new information regarding a digital key is received, deletes any of the information regarding a plurality of digital keys that has not been selected as information to be protected.

[0350] [Appendix 6] The digital keys include a first digital key, a second digital key generated based on the first digital key, and a third digital key generated based on the second digital key, and the storage device stores information about the digital key corresponding to the second digital key and information about the digital key corresponding to the third digital key, and when the number of pieces of information about the digital keys stored in the storage device has reached the predetermined number that can be stored, the vehicle management device described in any one of Appendices 1 to 5 deletes the information about the digital key corresponding to the third digital key when new information about the digital key is received.

[0351] [Appendix 7] A vehicle management device as described in any one of Appendices 1 to 6, wherein when new information about the digital key is received when the number of pieces of information about the digital key stored in the storage device has reached the predetermined number that can be stored, the device deletes the information about the digital key stored in the storage device based on another registration request from a device that has made a registration request to store in the device information about the digital key corresponding to the newly received information about the digital key.

[0352] [Appendix 8] A management server that manages digital keys, is capable of receiving a request to store information about the digital key in a vehicle, is capable of determining whether the amount of information about the digital key stored in the vehicle has reached a predetermined number that the vehicle can store, and when the management server receives the request for a vehicle whose amount of information about the digital key has reached the predetermined number that the vehicle can store, sends the vehicle an instruction to delete any of the information about the digital key stored in the vehicle.

[0353] [Appendix 9] The management server described in Appendix 9 is capable of determining whether or not a deletion reservation remains unexecuted in the vehicle, which causes the vehicle to execute the deletion of information regarding the target digital key when a predetermined condition is met, and when the management server receives a request for a vehicle for which the number of stored information regarding the digital key has reached the predetermined number that can be stored and for which a deletion reservation remains unexecuted, sends to the vehicle an instruction to delete any of the information regarding the digital key that is the subject of the unexecuted deletion reservation.

[0354] [Appendix 10] A management server as described in Appendix 8 or Appendix 9, which is capable of determining whether there are any outstanding deletion reservations remaining in the vehicle that will cause the vehicle to execute the deletion of information regarding the target digital key when predetermined conditions are met, and when a request is received for a vehicle for which the number of information regarding the stored digital key has reached the predetermined number that can be stored and for which multiple deletion reservations remain outstanding, sends to the vehicle an instruction to delete all information regarding the digital keys that are the subject of each of the multiple deletion reservations.

[0355] [Appendix 11] A management server as described in any one of Appendices 8 to 10, configured to be able to grasp information about the digital keys stored in the vehicle, configured to allow the user of the vehicle to set priorities for information about the digital keys stored in the vehicle, and when receiving a request for a vehicle in which the number of pieces of information about the stored digital keys has reached the predetermined number that can be stored, sends to the vehicle an instruction to select information about the digital keys to be deleted based on the priority that has already been set.

[0356] [Appendix 12] A management server as described in any one of Appendices 8 to 11, configured to be able to select information about a digital key to be protected from information about a plurality of digital keys stored in the vehicle, and when a request is received for a vehicle in which the number of information about stored digital keys has reached the predetermined number that can be stored, the management server sends to the vehicle an instruction to delete any of the information about the plurality of digital keys that has not been selected as information to be protected.

[0357] [Supplementary Note 13] The digital keys include a first digital key, a second digital key generated based on the first digital key, and a third digital key generated based on the second digital key, and information about the digital key corresponding to the second digital key and information about the digital key corresponding to the third digital key are stored, and when the management server receives a request for a vehicle for which the number of pieces of information about the digital keys stored in the storage device has reached the predetermined number that can be stored, the management server sends to the vehicle an instruction to delete the information about the digital key corresponding to the third digital key stored in the vehicle.

[0358] [Appendix 14] The management server of claim 8, when receiving a request for a vehicle for which the number of stored information about the digital key has reached the predetermined number that can be stored, sends to the vehicle an instruction to delete information about the digital key stored based on another registration request by a device that made a registration request to store information about the digital key corresponding to the information about the digital key corresponding to the request in the device.

[0359] [Appendix 15] The digital key includes a first digital key, the first digital key being the only digital key that exists for the vehicle, and the management server described in any one of Appendices 8 to 14 notifies a device that stores information about a digital key corresponding to the first digital key that, when it sends a command to the vehicle to delete any of the information about the digital key stored in the vehicle, that any of the information about the digital key stored in the vehicle will be deleted from the vehicle.

[0360] [Appendix 16] A management server as described in any one of Appendices 8 to 15, which, when sending an instruction to the vehicle to delete any of the information relating to the digital keys stored in the vehicle, notifies a device that has made a registration request to store information relating to a digital key corresponding to the information relating to the digital key to be deleted in the device, that the information relating to the digital key will be deleted.

[0361] [Appendix 17] A management server as described in any one of Appendices 8 to 16, which, when sending an instruction to the vehicle to delete any of the information relating to the digital keys stored in the vehicle, notifies a device storing information relating to a digital key corresponding to the information relating to the digital key to be deleted that the information relating to the digital key will be deleted.

[0362] [Appendix 18] A management server as described in any one of Appendices 8 to 17, which, when sending an instruction to the vehicle to delete all information regarding the digital keys that are the subject of each of the multiple deletion reservations, notifies multiple devices that store information regarding the digital keys corresponding to the information regarding the digital keys that are the subject of each of the multiple deletion reservations that the information regarding the digital keys corresponding to the information regarding the digital keys will be deleted. [Explanation of symbols]

[0363] AT…Authentication information D11, D21, D31...Registration request D41...Deletion reservation DK...Key information RC...default conditions 10...Management system 20...Vehicle 26...Vehicle management device 28…Storage device 30…Devices 70...Administration server 72...Storage device

Claims

1. A vehicle management device mounted on a vehicle, a storage device that stores information about the digital key; When the number of pieces of information about the digital key stored in the storage device has reached a predetermined number that can be stored, and new pieces of information about the digital key are received, Delete any of the information about the digital key stored in the storage device. Vehicle management device.

2. When the number of pieces of information about the digital key stored in the storage device has reached the predetermined number that can be stored, and a deletion reservation, which is a command to execute deletion of the information about the target digital key when a predetermined condition is met, remains unexecuted, and new information about the digital key is received, Delete information about the digital key that is the subject of the pending deletion reservation. The vehicle management device according to claim 1 .

3. When the number of pieces of information about the digital key stored in the storage device has reached the predetermined number that can be stored, and there are a plurality of unexecuted deletion reservations, which are commands to execute the deletion of the pieces of information about the target digital key when a predetermined condition is met, and when new pieces of information about the digital key are received, Delete all information relating to the digital key that is the subject of the pending deletion reservation. The vehicle management device according to claim 1 .

4. The vehicle user is configured to be able to set a priority for the information about the digital key stored in the storage device, When the number of pieces of information about the digital key stored in the storage device has reached the predetermined number that can be stored, new pieces of information about the digital key are received, Select information about the digital key to be deleted based on the priority order that has already been set. The vehicle management device according to claim 1 .

5. The storage device is configured to be able to select information about the digital key to be protected from information about the plurality of digital keys stored in the storage device, When new information about the digital key is received, any of the information about the plurality of digital keys that is not selected as the object of protection is deleted. The vehicle management device according to claim 1 .

6. the digital keys include a first digital key, a second digital key generated based on the first digital key, and a third digital key generated based on the second digital key; When information on the digital key corresponding to the second digital key and information on the digital key corresponding to the third digital key are stored in the storage device and the number of pieces of information on the digital keys stored in the storage device has reached the predetermined number that can be stored, and new information on the digital key is received, Delete information about the digital key corresponding to the third digital key. The vehicle management device according to claim 1 .

7. When the number of pieces of information about the digital key stored in the storage device has reached the predetermined number that can be stored, new pieces of information about the digital key are received, The device stores information about a digital key corresponding to the newly received information about the digital key in the device. The device deletes the information about the digital key stored in the storage device based on another registration request from the device that made the registration request. The vehicle management device according to claim 1 .

8. A management server that manages digital keys, a request to store information about the digital key in the vehicle; It is possible to know whether the number of pieces of information about the digital key stored in the vehicle has reached a predetermined number that can be stored in the vehicle, When the request is received for the vehicle for which the number of stored pieces of information about the digital key has reached the predetermined number that can be stored, a command is sent to the vehicle to delete any of the pieces of information about the digital key stored in the vehicle. Management server.

9. It is possible to grasp whether there is an unexecuted deletion reservation remaining in the vehicle, which is to cause the vehicle to delete information related to the target digital key when a predetermined condition is met; When the number of stored pieces of information about the digital key has reached the predetermined number that can be stored and the request for the vehicle for which the deletion reservation remains outstanding is received, Sending a command to the vehicle to delete any of the information related to the digital key that is the subject of the pending deletion reservation. The management server according to claim 8.

10. It is possible to grasp whether there is an unexecuted deletion reservation remaining in the vehicle, which is to cause the vehicle to delete information related to the target digital key when a predetermined condition is met; When the request is received for the vehicle for which the number of stored information about the digital key has reached the predetermined number that can be stored and for which multiple deletion reservations remain unexecuted, A command is sent to the vehicle to delete all information relating to the digital keys that are the subject of each of the multiple deletion reservations. The management server according to claim 8.

11. The digital key is stored in the vehicle. A user of the vehicle can set a priority for information about the digital key stored in the vehicle, When the request is received for the vehicle for which the number of stored pieces of information about the digital keys has reached the predetermined number that can be stored, an instruction is sent to the vehicle to select pieces of information about the digital keys to be deleted based on the priority order that has already been set. The management server according to claim 8.

12. The digital key protection unit is configured to be able to select information about the digital key to be protected from information about the plurality of digital keys stored in the vehicle, When the request is received for the vehicle for which the number of stored pieces of information about the digital keys has reached the predetermined number that can be stored, a command is sent to the vehicle to delete any of the pieces of information about the plurality of digital keys that have not been selected as the object of protection. The management server according to claim 8.

13. the digital keys include a first digital key, a second digital key generated based on the first digital key, and a third digital key generated based on the second digital key; When the request is received for the vehicle in which information about the digital key corresponding to the second digital key and information about the digital key corresponding to the third digital key are stored and the number of pieces of information about the stored digital keys has reached the predetermined number that can be stored, Sending a command to the vehicle to delete information about the digital key corresponding to the third digital key stored in the vehicle. The management server according to claim 8.

14. When the request is received for the vehicle for which the number of stored pieces of information about the digital key has reached the predetermined number that can be stored, Send a command to the vehicle to cause the device to store information about the digital key corresponding to the request, and delete information about the digital key stored based on another registration request by the device that made the registration request. The management server according to claim 8.

15. The digital key includes a first digital key, and the first digital key is the only digital key that exists for the vehicle; When a command to delete any of the information about the digital key stored in the vehicle is transmitted to the vehicle, A notification is sent from the vehicle to a device storing information about a digital key corresponding to the first digital key, that any information about the digital key stored in the vehicle will be deleted. The management server according to claim 8.

16. When a command to delete any of the information about the digital key stored in the vehicle is transmitted to the vehicle, A device that has made a registration request to store information about a digital key corresponding to the information about the digital key to be deleted is notified that the information about the digital key will be deleted. The management server according to claim 8.

17. When a command to delete any of the information about the digital key stored in the vehicle is transmitted to the vehicle, Notifying a device storing information about a digital key corresponding to the information about the digital key to be deleted that the information about the digital key will be deleted. The management server according to claim 8.

18. When a command to delete all information related to the digital keys that are the subject of each of the multiple deletion reservations is transmitted to the vehicle, Notifying a plurality of devices storing information on digital keys corresponding to information on the digital keys targeted by each of the plurality of deletion reservations that the information on the digital keys corresponding to the information on the digital keys will be deleted. The management server according to claim 10.

19. a vehicle management device mounted on the vehicle; a management server that manages digital keys; A management system comprising: The vehicle is provided with a storage device, and when new information about the digital key is received in a state where the number of pieces of information about the digital key stored in the storage device has reached a predetermined number that can be stored, any of the pieces of information about the digital key stored in the vehicle is deleted. Management system.

Images