Vehicles and management servers

Abstract

The aim is to provide vehicles that reduce the likelihood of users experiencing inconvenience due to their devices suddenly becoming unusable as digital keys. [Solution] When the vehicle 20 receives a deletion operation via the user interface, which is an operation to delete a digital key registered in the vehicle 20, the vehicle 20 performs the operation to set the state of the digital key that has been deleted to a fade-out state in which the digital key is deleted when the default condition RC is met. When the default condition RC is met, the vehicle 20 performs the operation to delete the second information related to the digital key that has been set to the fade-out state, which is stored in the storage device.

Description

[[Technical Field]]

[0001] The present invention relates to a vehicle and a management server. [[Background Art]]

[0002] Patent Document 1 discloses a technology of a digital key system that uses a device such as a smartphone as a vehicle key. The digital key system causes a vehicle to store information related to a digital key. The digital key system causes a device to store information related to the digital key. This enables the vehicle to be used using the device registered as a digital key without requiring a vehicle-dedicated key. [[Prior Art Literature]] [[Patent Literature]]

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

[0004] When information related to a digital key stored in a vehicle is deleted, a device that stores information related to a digital key corresponding to the deleted information related to the digital key loses its function as a digital key.

[0005] When a digital key stored in a vehicle is deleted by operating a user interface provided on the vehicle, a user of a device that stores information related to the deleted digital key can no longer use the device as a digital key. When a digital key is deleted by another person, there is a risk that the vehicle may suddenly become unusable. [[Means for Solving the Problem]]

[0006] A vehicle for solving the above problem is capable of communicating with a device that stores first information relating to a digital key, and the device is registered as the digital key. The vehicle comprises a user interface that accepts operations from the user of the vehicle, a storage device that stores second information relating to the digital key corresponding to the first information stored in the device, and a processing circuit. When the user interface receives a deletion operation, which is an operation to delete the digital key registered in the vehicle, the processing circuit performs the following actions: sets the state of the digital key that has been deleted to a fade-out state in which the digital key is deleted when a predetermined condition is met; and deletes the second information relating to the digital key that is set to the fade-out state stored in the storage device when the predetermined condition is met.

[0007] A vehicle for solving the above problem is a vehicle that can communicate with a server that manages digital keys and a device that stores first information relating to the digital key, and the device is registered as the digital key, and comprises a user interface that accepts operations from the user of the vehicle, a storage device that stores second information relating to the digital key corresponding to the first information stored in the device, and a processing circuit, and when a deletion operation, which is an operation to delete the digital key registered in the vehicle, is received via the user interface, the processing circuit sends a deletion request to the server to delete the digital key registered in the vehicle, and after receiving a pending notification from the server indicating that the state of the digital key for which the deletion request has been made has been set to a fade-out state in which the digital key will be deleted if a default condition is met, the processing circuit deletes the second information relating to the digital key set to the fade-out state stored in the storage device when the default condition is met.

[0008] A management server for solving the above problems includes a device that stores first information relating to a digital key registered for a vehicle, and a vehicle that stores second information relating to the digital key corresponding to the first information. The management server is capable of communicating with the vehicle and manages the digital key, and comprises a communication module and a processing circuit. When the communication module receives a deletion request from the vehicle to delete the digital key registered for that vehicle, the processing circuit performs the following actions: setting the state of the digital key for which the deletion request has been made to a fade-out state in which the digital key is deleted when a predetermined condition is met; and deleting the digital key set to the fade-out state when the predetermined condition is met. [Effects of the Invention]

[0009] The above-mentioned vehicles and management servers can reduce the possibility of users experiencing inconvenience due to their devices suddenly becoming unusable as digital keys. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is a schematic diagram showing the management system of the first embodiment. [Figure 2] Figure 2 is a schematic diagram showing the management system of the first embodiment. [Figure 3] Figure 3 is a schematic diagram showing the owner key information of the first embodiment. [Figure 4] Figure 4 is a schematic diagram showing the share key information of the first embodiment. [Figure 5] Figure 5 is a schematic diagram showing the data in the database of the first embodiment. [Figure 6] Figure 6 is an explanatory diagram showing a series of processes performed by the management system when an owner key is registered in the first embodiment. [Figure 7] Figure 7 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 8]FIG. 8 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in the 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 based on the deletion reservation of the first embodiment. [Figure 10] FIG. 10 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the first embodiment. [Figure 11] FIG. 11 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the first embodiment. [Figure 12] FIG. 12 is a flowchart showing a confirmation process performed by the vehicle according to the first embodiment. [Figure 13] FIG. 13 is a schematic diagram showing a notification image according to the first embodiment. [Figure 14] FIG. 14 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the first embodiment. [Figure 15] FIG. 15 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the first embodiment. [Figure 16] FIG. 16 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the first embodiment. [Figure 17] FIG. 17 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the first embodiment. [Figure 18] FIG. 18 is an explanatory diagram showing a series of processes performed by the management system when receiving a deletion operation of a modification example of the first embodiment. [Figure 19] FIG. 19 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the second embodiment. [Figure 20] FIG. 20 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the second embodiment. [Figure 21] FIG. 21 is an explanatory diagram showing a series of processes performed by the management system when a deletion operation is received in the second embodiment. [Figure 22] FIG. 22 is a flowchart showing confirmation processing performed by the management system according to the second embodiment. [Figure 23] FIG. 23 is an explanatory diagram showing a series of processing performed by the management system when a deletion operation according to the second embodiment is accepted. [Figure 24] FIG. 24 is an explanatory diagram showing a series of processing performed by the management system when a deletion operation according to the second embodiment is accepted. [Figure 25] FIG. 25 is an explanatory diagram showing a series of processing performed by the management system when accepting a deletion request according to a modification of the second embodiment. [Figure 26] FIG. 26 is an explanatory diagram showing a series of processing performed by the management system when a deletion operation according to the third embodiment is accepted. [Figure 27] FIG. 27 is an explanatory diagram showing a series of processing performed by the management system when a deletion operation according to the third embodiment is accepted. [Figure 28] FIG. 28 is an explanatory diagram showing a series of processing performed by the management system when a deletion operation according to the third embodiment is accepted. [Figure 29] FIG. 29 is an explanatory diagram showing a series of processing performed by the management system when a deletion operation according to the third embodiment is accepted. [Figure 30] FIG. 30 is an explanatory diagram showing a series of processing performed by the management system when accepting a deletion request according to a modification of the third embodiment. DESCRIPTION OF EMBODIMENTS

[0011] (First Embodiment) Hereinafter, a management system including a vehicle 20 according to the first embodiment will be described with reference to the drawings.

[0012] <Outline of Management System 10> As shown in Figure 1, the management system 10 manages information about multiple digital keys that are registrable for the vehicle 20. Regarding digital keys, there is a standard set by the Car Connectivity Consortium (CCC). The matters concerning digital keys in this embodiment assume compliance with the CCC, but are applicable to standards and systems other than the CCC. The management system 10 comprises the vehicle 20, multiple devices 30, a device server 60, a management server 70, and a fob key 80 as shown in Figure 2.

[0013] As shown in Figure 1, the vehicle 20 includes a communication module 21, an HMI 22, a BLE module 23, a UWB module 24, an NFC module 25, and a vehicle management device 26. HMI stands for Human Machine Interface. BLE stands for Bluetooth Low Energy. UWB stands for Ultra Wide Band. NFC stands for Near Field Communication. The HMI 22 functions as a user interface that accepts operations from the user of the vehicle 20.

[0014] The communication module 21 communicates with the management server 70 via a wireless communication line. The HMI 22 includes an input device and a presentation device. The input device receives user inputs from the vehicle 20 and inputs signals indicating the inputs to the vehicle 20. The presentation device presents information to the user using images and sound, etc. The presentation device is, for example, a display and a speaker.

[0015] The BLE module 23 communicates with the device 30 via BLE communication. The UWB module 24 communicates with the device 30 via UWB communication. The UWB module 24 measures the distance between the device 30 and the vehicle 20. The NFC module 25 communicates with the device 30 via NFC communication.

[0016] The vehicle management device 26 is installed in the vehicle 20. The vehicle management device 26 manages multiple digital keys for 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. Authentication information AT is second information related to the digital key. By having the vehicle program PV executed by the execution device 27, the execution device 27 is made to store and delete the authentication information AT. Authentication information AT is information for authenticating a digital key in order to enable control of the vehicle 20 by the digital key when using the digital key. Authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU, i.e., a processing circuit. By executing the vehicle program PV, the execution device 27 performs processing related to the storage and deletion of authentication information AT.

[0017] When the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be controlled by the digital key. For example, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be unlocked. Alternatively, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be started.

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

[0019] The communication module 31 communicates with the device server 60 via a wireless communication line. The HMI 32 includes an input device and a presentation device. The input device receives user input to the device 30 and inputs signals indicating the input. The presentation device presents information to the user through images, sounds, etc. The presentation device is, for example, a display and a speaker.

[0020] The BLE module 33 communicates with the vehicle 20 via BLE communication. The UWB module 34 communicates with the vehicle 20 via UWB. The NFC module 35 communicates with the vehicle 20 via NFC.

[0021] The storage device 37 stores the device program PD and the 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 that indicates a digital key. The key information DK is the first information relating to the digital key.

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

[0023] The owner device 40 stores owner key information DKO, which indicates the owner key KO, as key information DK. Only one owner key KO can be registered for each vehicle 20. Therefore, there is only one owner key KO for each vehicle 20.

[0024] Vehicle 20 can also be operated by authentication using the fob key 80. The fob key 80 is a dedicated vehicle device that electronically authenticates and unlocks vehicle 20. As shown in Figure 2, the fob key 80 includes an execution device 81, a storage device 82, a BLE module 83, a UWB module 84, and an NFC module 85. The execution device 81 controls the operation of the fob key 80. The storage device 82 stores ID information INF. ID information INF is, for example, an ID code unique to the fob key 80. The storage device 28 of the vehicle 20 also stores ID information INF. The vehicle 20 obtains the ID information INF stored in the storage device 82 of the fob key 80 by communicating with the fob key 80 at close range. The vehicle 20 then determines whether the ID information INF obtained from the fob key 80 corresponds to the ID information INF stored in the storage device 28. If the ID information INF obtained from the fob key 80 corresponds to the ID information INF stored in the storage device 28, the vehicle 20 authenticates the fob key 80. After authenticating the fob key 80, the vehicle 20 becomes operable.

[0025] As shown in Figure 3, the owner key information DKO has owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, 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, authorization public key information ST8, and authorization information ST9.

[0026] Vehicle identification information ST1 is information that identifies the vehicle 20 to which the digital key is to be set. For example, it is the ID of vehicle 20. The in-device key identification information ST2 is used for managing digital keys within device 30. The in-device key identification information ST2 is information that allows for the identification of digital keys within the application of device 30.

[0027] Digital key identification information ST3 is used for managing digital keys within the management server 70. Slot identification information ST4 is information that allows the digital key to be identified locally on device 30.

[0028] Certificate information ST5 indicates the certificate that certifies the digital key. Device public key information ST6 indicates the device public key PKD, which is the public key of device 30. Note that the device public key PKD in owner key information DKO indicates the public key of owner device 40. Vehicle public key information ST7 indicates the vehicle public key PKV, which is the public key of vehicle 20. Authorized public key information ST8 indicates the vehicle public key PKV that has already been authorized. Authority information ST9 indicates the range of functions that device 30, which stores the authority information ST9, can perform. The range of functions that can be performed will be described later.

[0029] As shown in Figure 1, the share device 50 stores share key information DKS, which indicates the share key KS, as key information DK. Share key information DKS is information about the share key KS. The share key KS is a digital key that can be registered multiple times for one vehicle 20 in order to register the digital key in order to make the digital key usable. In other words, multiple share keys KS can exist for one vehicle 20.

[0030] Multiple share devices 50 include friend devices 51 and non-friend devices 52. Friend device 51 stores friend key information DKF, which indicates friend key KF, as share key information DKS. Friend key information DKF is information about share key KS. Non-friend device 52 stores non-friend key information DKN, which indicates non-friend key KN, as share key information DKS. Non-friend key information DKN is information about share key KS. In other words, the types of share key KS include friend key KF and non-friend key KN.

[0031] The friend key KF is a share key KS registered directly from the owner device 40 based on a registration request D21, as described later. The registration request D21 is a request to cause device 30 to store the friend key information DKF, which is the key information DK. In other words, the registration request D21 is a request to cause another device 30 to store information about a new share key KS.

[0032] The non-friend key KN is a share key KS registered based on a registration request D31 from the friend device 51, as described later. The registration request D31 is a request to cause device 30 to store the new share key information DKS, which is the non-friend key information DKN. In other words, the registration request D31 is a request to cause another device 30 to store information about the new share key KS. The non-friend key KN is a share key KS registered based on an indirect registration request from the share device 50, which is a device 30 different from the owner device 40.

[0033] Furthermore, when a digital key is registered, it means that the digital key is usable. That is, when a digital key is registered, the vehicle 20 stores authentication information AT corresponding to key information DK, and the device 30 stores key information DK corresponding to authentication information AT. Authentication information AT is information about the digital key. That is, when a digital key is registered, the vehicle 20 stores information about the digital key. Key information DK is information about the digital key. That is, when a digital key is registered, the device 30 stores information about the digital key. If key information DK is information about a shared key KS, then the authentication information AT corresponding to that key information DK is also information about the shared key KS.

[0034] As shown in Figure 4, the share key information DKS has a share key structure information STS and an authentication package ATP. The share key structure information STS includes vehicle identification information ST1, device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The share key structure information STS also includes certificate information ST5, vehicle public key information ST7, and authorized public key information ST8. In other words, the share key structure information STS is the owner key structure information STO with the device public key information ST6 and authorization information ST9 removed.

[0035] The authentication package ATP includes signature information ATP1, password information ATP2, activation start information ATP3, expiration information ATP4, name information ATP5, device public key information ATP6, and authorization information ATP7.

[0036] Signature information ATP1 indicates that shared device 50 is a legitimate recipient of the digital key. For example, in the case of friend device 51, it indicates a signature by owner device 40. Owner signature information indicates that owner device 40 signed the device public key PKD of friend device 51, which is shown in device public key information ATP6. Also, for example, in the case of non-friend device 52, it indicates a signature by friend device 51. Friend signature information indicates that friend device 51 signed the device public key PKD of non-friend device 52, which is shown in device public key information ATP6.

[0037] Password information ATP2 indicates the pairing password PAS used when establishing a secure channel during pairing between the vehicle 20 and the owner device 40. Effective start information ATP3 indicates the earliest date and time when the share key KS can be used. Expiration date information ATP4 indicates the latest date and time when the share key KS can be used. Name information ATP5 indicates the name that identifies the share device 50 that stores the share key information DKS. For example, it is set as an identifiable name for each share device 50 by an operation from the owner device 40. Authorization information ATP7 is information that indicates the range of functions that can be used when the device 30 that stores the authorization information ATP7 is authenticated.

[0038] The range of usable functions includes, for example, the number of Share Key KS registrations that can be requested, and the range of functions of the vehicles 20 that can be used by digital key authentication. For example, the number of Friend Key KF registrations that an Owner Device 40 can request is greater than the number of Non-Friend Key KN registrations that a Friend Device 51 can request.

[0039] The range of functions that can be used by the vehicle 20 is, for example, the possible controls among the following: engine start control of the vehicle 20, power-on control of the vehicle 20, and unlocking and locking control of the vehicle 20's doors. For example, if the range of functions that can be used by the vehicle 20 is the three controls described above, the range of functions that can be used by the vehicle 20 is wider than if the range of functions that can be used by the vehicle 20 is limited to unlocking and locking control of the vehicle 20's doors. More specifically, the range of functions that can be used by the friend device 51 is the three functions described above, while the range of functions that can be used by the non-friend device 52 is power-on control of the vehicle 20 and unlocking and locking control of the vehicle 20's doors.

[0040] As shown in Figure 1, the device server 60 relays communication between the device 30 and the management server 70. A separate device server 60 is provided for each type of device 30. That is, the device server 60 that a first-type device 30 communicates with is different from the device server 60 that a second-type device 30 communicates with. Both device servers 60 relay communication with the management server 70, allowing devices 30 of different types to communicate with the management server 70 via the device server 60. Note that only one device server 60 is shown in Figure 1.

[0041] <Management Server 70> The management server 70 manages multiple digital keys. The management server 70 can communicate with the vehicle 20 and multiple devices 30. The management server 70 comprises an execution unit 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 can also communicate wirelessly with the communication module 21 of the vehicle 20.

[0042] The execution device 71 and the storage device 72 constitute a computer. The execution device 71 is the CPU, or processing circuit. The storage device 72 is memory. The storage device 72 stores the server program PS and the database DB.

[0043] The server program PS, when executed by the execution device 71, causes the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB. The server program PS also causes the execution device 71 to delete digital keys.

[0044] The database DB associates each of the multiple digital keys with the corresponding vehicle 20 and the registered device 30. The database DB is divided into data DA for each vehicle 20. When a digital key is registered, the management server 70 stores information in the data DA indicating the device 30 that stores the key information DK representing that digital key.

[0045] <About Data DA> As shown in Figure 5, the data DA of a single vehicle 20 includes the type of digital key registered to that vehicle 20, the registered device 30, and the relationships between the registered devices 30. The relationships between the devices 30 are the relationships between the multiple digital keys registered to each device 30. A hierarchy of priority is determined by the type of digital key. From top to bottom in the hierarchy, the keys are Owner Key KO, Friend Key KF, and Non-Friend Key KN. Higher levels of the hierarchy grant greater authority.

[0046] Permissions include, for example, the number of shared keys KS that can be requested to be registered, and the range of vehicles 20 that can be controlled by digital key authentication. Higher levels of the hierarchy indicate greater permissions; for example, a higher number of shared keys KS that can be requested to be registered. More specifically, for example, the number of friend keys KF that an owner device 40 can request to be registered is greater than the number of non-friend keys KN that a friend device 51 can request to be registered.

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

[0048] This section describes a situation where a digital key has been registered for 11 devices 30 for a single vehicle 20. The 11 devices 30 are referred to as Device 1 30A to Device 11 30K.

[0049] The digital key registered in the first device 30A will be designated as the first digital key DK1. The digital key registered in the second device 30B will be designated as the second digital key DK2. The digital key registered in the third device 30C will be designated as the third digital key DK3. The digital key registered in the fourth device 30D will be designated as the fourth digital key DK4. The digital key registered in the fifth device 30E will be designated as the fifth digital key DK5. The digital key registered in the sixth device 30F will be designated as the sixth digital key DK6. The digital key registered in the seventh device 30G will be designated as the seventh digital key DK7. The digital key registered in the eighth device 30H will be designated as the eighth digital key DK8. The digital key registered in the ninth device 30I will be designated as the ninth digital key DK9. The digital key registered in the tenth device 30J will be designated as the tenth digital key DK10. The digital key registered in the eleventh device 30K will be designated as the eleventh digital key DK11.

[0050] In the data DA, device 30, which is registered as owner key KO, is the first device 30A. That is, the first device 30A is owner device 40. In other words, the first digital key DK1 is owner key KO.

[0051] In the Data DA, devices 30 registered with the digital key type as Share Key KS are the 2nd device 30B to the 11th device 30K. That is, the 2nd device 30B to the 11th device 30K are Share Device 50. In other words, the 2nd digital key DK2 to the 11th digital key DK11 are all Share Key KS.

[0052] More specifically, in the data DA, the devices 30 registered as digital key type 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 Device 51.

[0053] In the data DA, the devices 30 registered as having a digital key type of non-friendly key KN are the 3rd device 30C, the 4th device 30D, and the 6th device 30F to the 11th device 30K. In other words, the 3rd device 30C, the 4th device 30D, and the 6th device 30F to the 11th device 30K are non-friendly devices 52.

[0054] <Regarding direct lineage> 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 DK2 is registered based on the first digital key DK1. In this case, the second digital key DK2 is a digital key one generation later that is directly related to the first digital key DK1.

[0055] 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 DK5 is registered based on the first digital key DK1. In this case, the fifth digital key DK5 is a digital key one generation later that is directly related to the first digital key DK1.

[0056] In data DA, the relationship between the third device 30C and the second device 30B is such that the non-friendly 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 DK3 is registered based on the second digital key DK2. In this case, the third digital key DK3 is a digital key one generation later, directly related to the second digital key DK2. The third digital key DK3 is a digital key two generations later, directly related to the first digital key DK1.

[0057] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that the non-friendly 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 DK4 is registered based on the second digital key DK2. In this case, the fourth digital key DK4 is a digital key one generation later, directly related to the second digital key DK2. The fourth digital key DK4 is a digital key two generations later, directly related to the first digital key DK1.

[0058] In the data DA, the relationship between the 6th device 30F and the 5th device 30E is such that the non-friendly key KN is registered in the 6th device 30F based on a registration request from the 5th device 30E. In other words, the 6th digital key DK6 is registered based on the 5th digital key DK5. In this case, the 6th digital key DK6 is a digital key one generation later, directly related to the 5th digital key DK5. The 6th digital key DK6 is a digital key two generations later, directly related to the 1st digital key DK1.

[0059] In the data DA, the relationship between the 7th device 30G and the 5th device 30E is such that a non-friendly key KN is registered in the 7th device 30G due to a registration request from the 5th device 30E. In other words, the 7th digital key DK7 is registered based on the 5th digital key DK5. In this case, the 7th digital key DK7 is a digital key one generation later, directly related to the 5th digital key DK5. The 7th digital key DK7 is a digital key two generations later, directly related to the 1st digital key DK1.

[0060] In the data DA, the relationship between the 8th device 30H and the 3rd device 30C is such that the non-friendly key KN is registered in the 8th device 30H based on a registration request from the 3rd device 30C. In other words, the 8th digital key DK8 is registered based on the 3rd digital key DK3. In this case, the 8th digital key DK8 is a digital key one generation later, directly related to the 3rd digital key DK3. The 8th digital key DK8 is a digital key two generations later, directly related to the 2nd digital key DK2. The 8th digital key DK8 is a digital key three generations later, directly related to the 1st digital key DK1.

[0061] In the data DA, the relationship between the 9th device 30I and the 4th device 30D is such that the non-friendly key KN is registered in the 9th device 30I based on a registration request from the 4th device 30D. In other words, the 9th digital key DK9 is registered based on the 4th digital key DK4. In this case, the 9th digital key DK9 is a digital key one generation later, directly related to the 4th digital key DK4. The 9th digital key DK9 is a digital key two generations later, directly related to the 2nd digital key DK2. The 9th digital key DK9 is a digital key three generations later, directly related to the 1st digital key DK1.

[0062] In the data DA, the relationship between the 10th device 30J and the 6th device 30F is such that the non-friendly key KN is registered in the 10th device 30J based on a registration request from the 6th device 30F. In other words, the 10th digital key DK10 is registered based on the 6th digital key DK6. In this case, the 10th digital key DK10 is a digital key one generation later, directly related to the 6th digital key DK6. The 10th digital key DK10 is a digital key two generations later, directly related to the 5th digital key DK5. The 10th digital key DK10 is a digital key three generations later, directly related to the 1st digital key DK1.

[0063] In Data DA, the relationship between the 11th device 30K and the 7th device 30G is such that the non-friendly key KN is registered in the 11th device 30K based on a registration request from the 7th device 30G. In other words, the 11th digital key DK11 is registered based on the 7th digital key DK7. In this case, the 11th digital key DK11 is a digital key one generation later, directly related to the 7th digital key DK7. The 11th digital key DK11 is a digital key two generations later, directly related to the 5th digital key DK5. The 11th digital key DK11 is a digital key three generations later, directly related to the 1st digital key DK1.

[0064] Thus, the data DA stores the devices 30 that have been registered as digital keys. Furthermore, it associates information indicating the device 30 that made the request that triggered the registration of the device 30. The data DA also includes information indicating which digital key each digital key is based on.

[0065] All digital keys registered based on a request from the first digital key DK1 are digital keys that are one generation or more later than the first digital key DK1. In other words, in the relationship diagram shown in Figure 6, all digital keys other than the first digital key DK1 are digital keys that are one generation or more later and have a direct relationship with the first digital key DK1.

[0066] All digital keys registered based on a request from the second digital key DK2 are digital keys that are one generation or more later than the second digital key DK2. In other words, in the relationship diagram shown in Figure 6, the third digital key DK3, the fourth digital key DK4, the eighth digital key DK8, and the ninth digital key DK9 are digital keys that are one generation or more later and that are directly related to the second digital key DK2.

[0067] <Regarding the higher and lower levels of digital keys> The first digital key DK1 is a digital key that is higher in rank than digital keys registered based on a request from the first digital key DK1, and digital keys that are one generation or more later than the digital keys registered based on a request from the first digital key DK1. In other words, in the data DA shown in Figure 6, the first digital key DK1 is a digital key that is higher in rank than digital keys other than the first digital key DK1.

[0068] A digital key registered based on a request from the first digital key DK1 is a digital key that is higher in rank than digital keys that are one or more generations later than the digital key registered based on a request from the first digital key DK1. In other words, in the data DA shown in Figure 6, the second digital key DK2 and the fifth digital key DK5 are digital keys that are higher in rank than digital keys registered based on a request from the second digital key DK2 or the fifth digital key DK5. That is, the second digital key DK2 and the fifth digital key DK5 are digital keys that are higher in rank than the third digital key DK3, the fourth digital key DK4, and the sixth digital key DK6 to the eleventh digital key DK11.

[0069] A digital key one generation later than a digital key registered based on a request from the first digital key DK1 is a higher-ranking digital key than a digital key two or more generations later than a digital key registered based on a request from the first digital key DK1. In other words, in the data DA shown in Figure 6, the third digital key DK3 is a higher-ranking digital key than a digital key registered based on a request from the third digital key DK3, the fourth digital key DK4, the sixth digital key DK6, or the seventh digital key DK7. The same applies to the fourth digital key DK4, the sixth digital key DK6, and the seventh digital key DK7. That is, the third digital key DK3, the fourth digital key DK4, the sixth digital key DK6, and the seventh digital key DK7 are higher-ranking digital keys than the eighth digital key DK8 to the eleventh digital key DK11.

[0070] For example, in the data DA shown in Figure 6, the digital keys directly related to the third digital key DK3 are the first digital key DK1, the second digital key DK2, and the eighth digital key DK8. For example, in the data DA shown in Figure 6, the digital keys higher than the third digital key DK3 are the first digital key DK1, the second digital key DK2, and the fifth digital key DK5. For example, in the data DA shown in Figure 6, the digital keys that are directly related to the third digital key DK3 and are also higher are the first digital key DK1 and the second digital key DK2.

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

[0072] <Owner Key Registration> As shown in Figure 6, the management system 10 performs a series of processes to register the owner key KO. Among the devices 30 that do not store the key information DK indicating the owner key KO, the device 30 that will be designated as the owner device 40 is designated as the first device 30A.

[0073] The management system 10 stores key information DK, which indicates the owner key KO, in the first device 30A upon registration of the owner key KO. The management system 10 also stores authentication information AT, which authenticates the owner key KO, in the vehicle 20 upon registration of the owner key KO. As a result, the first device 30A becomes the owner device 40. Note that the registration of the owner key KO is assumed to be performed on the first device 30A with the application installed.

[0074] When the management server 70 receives the owner key KO registration request D11 from the first device 30A or the like, the management server 70 first performs the process in step S11. In step S11, the management server 70 generates a pairing password PAS. Then, the management server 70 sends information indicating the pairing password PAS to the vehicle 20 and the first device 30A.

[0075] Subsequently, vehicle 20 receives the pairing password PAS. After vehicle 20 receives the pairing password PAS, HMI22 sets it to pairing mode, and vehicle 20 waits in a state where it can receive the password from the first device 30A. After that, vehicle 20 proceeds to step S12.

[0076] In step S12, vehicle 20 pairs with the first device 30A. Once pairing is complete, vehicle 20 establishes a secure channel with the first device 30A for data communication. Pairing is performed using the pairing password PAS sent from the management server 70 to vehicle 20 and the first device 30A. Once pairing is complete, vehicle 20 proceeds to step S13.

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

[0078] In step S14, the first device 30A generates owner key information DKO, which indicates the owner key KO. Then, the first device 30A proceeds to step S15. In step S15, the first device 30A stores the owner key information DKO. This makes the first device 30A the owner device 40. Subsequently, the first device 30A transmits the certificate information ST5 related to the owner key KO and the device public key information ST6 indicating the device public key PKD to the vehicle 20.

[0079] Subsequently, when vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process in step S16. In step S16, vehicle 20 verifies certificate information ST5. Once the verification of certificate information ST5 is complete, vehicle 20 proceeds to step S17.

[0080] In step S17, the vehicle 20 stores the device public key information ST6, which represents the device public key PKD, as authentication information AT. Subsequently, the vehicle 20 sends a completion notification M11 to the first device 30A indicating that the storage of the authentication information AT is complete.

[0081] Subsequently, when the first device 30A receives the completion notification M11, the first device 30A performs the process in 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 to the management server 70 requesting an update to the database DB. The first device 30A then sends the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0082] Subsequently, when the management server 70 receives the key track request D12, it performs the processing in step S19. In step S19, the management server 70 performs the registration management of the owner key KO. Specifically, it stores the first device 30A in the data DA of the vehicle 20 in the database DB as the device 30 registered as the owner key KO. With this, the management system 10 completes the series of processing for the owner key KO.

[0083] <Registering a Friend Key> As shown in Figure 7, the management system 10 performs a series of registration processes to register the friend key KF. Of the devices 30 that do not store the friend key information DKF, the device 30 that becomes a friend device 51 through this series of processes is designated as the second device 30B.

[0084] When the owner device 40 performs an operation to request the registration of the friend key KF, the owner device 40 first performs the process in step S21. In step S21, the owner device 40 sends the friend key KF registration request D21 to a relay server (not shown in the figure). After that, the owner device 40 proceeds to step S22.

[0085] In step S22, the owner device 40 obtains invitation information IV1 for sharing the digital key from the relay server. Invitation information IV1 is, for example, a URL link. The URL link contains share information SH1 necessary for sharing the digital key. The owner device 40 then sends the invitation information IV1 to the second device 30B.

[0086] Subsequently, when the second device 30B receives the invitation information IV1, it performs the process in step S23. In step S23, the second device 30B obtains the share information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the share information SH1 from the source of the URL link.

[0087] The share information SH1 includes, for example, share key structure information STS, password information ATP2, effective start information ATP3, expiration information ATP4, and name information ATP5. Note that the effective start information ATP3, expiration information ATP4, and name information ATP5 are set by the owner device 40. After that, the second device 30B proceeds to step S24.

[0088] In step S24, the second device 30B generates unsigned friend key information DKFN using the share information SH1. Unsigned friend key information DKFN is friend key information DKFN that does not have signature information ATP1. Specifically, the second device 30B generates each piece of information contained in the acquired share information SH1 as the pieces of information in the unsigned friend key information DKFN. Subsequently, the second device 30B sends a completion notification M21 indicating that the generated unsigned friend key information DKFN has been uploaded to a URL link, and a signature request D22 requesting a signature, to the owner device 40.

[0089] Subsequently, 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 obtains the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process in step S25 by being operated.

[0090] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 prompts the HMI 32 to present the acquired unsigned friend key information DKFN and accepts an operation indicating consent to the registration of the friend key KF by the user of the owner device 40. Once the operation is performed, the owner device 40 obtains a signature based on the operation performed. After that, the owner device 40 proceeds to step S26.

[0091] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. This causes the owner device 40 to generate the 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 sends a completion notification M22 to the second device 30B indicating that the upload of the completed friend key information DKF to the URL link is complete.

[0092] Subsequently, the second device 30B receives a completion notification M22. Then, the second device 30B performs the process in 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 the friend device 51. Then, the second device 30B proceeds to step S28.

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

[0094] Subsequently, when the management server 70 receives the key track request D23 for the friend key KF, the management server 70 performs the process in step S29. In step S29, the management server 70 performs registration management for the friend key KF.

[0095] Specifically, the management server 70 verifies that the friend key KF, which is the target of keytrack request D23, is not on the rejection list. The rejection list is a list of share keys KS, including friend keys KF and non-friend keys KN for which a deletion request has already been received. If friend key KF is on the rejection list, the management server 70 sends a notification to the second device 30B that it cannot fulfill keytrack request D23.

[0096] On the other hand, if the friend key KF that received the key track request D23 is not on the rejection list, the management server 70 registers the friend key KF that received the key track request D23 in the database DB. Specifically, the management server 70 stores the second device 30B as device 30 registered as friend device 51 in the vehicle 20 data DA 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.

[0097] Subsequently, the management server 70 sends the authentication package ATP from 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 sends the device public key information ST6, which indicates 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 is signed by the owner device 40.

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

[0099] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M23 to the second device 30B. Subsequently, when the second device 30B receives the key track completion notification M23, it performs the process in step S31. In the process of step S31, the second device 30B presents information to the HMI 32 indicating that the registration of the friend key KF is complete. For example, the second device 30B presents an image indicating the registration of the friend key KF to the HMI 32. For example, the second device 30B displays an image indicating the registration of the friend key KF to the HMI 32. With this, the management system 10 completes the series of processes for registering the friend key KF.

[0100] As shown in Figure 8, the management system 10 performs a series of registration processes to register the non-friendly key KN. Among the devices 30 that do not store the non-friendly key information DKN, the device 30 that becomes a non-friendly device 52 through this series of processes is designated as the third device 30C.

[0101] When an operation is performed in the friend device 51 to request the registration of a non-friend key KN, the friend device 51 first performs the process in step S41. In step S41, the friend device 51 sends the non-friend key KN registration request D31 to a relay server (not shown in the figure). After that, the friend device 51 proceeds to step S42.

[0102] In step S42, the friend device 51 obtains invitation information IV2 for sharing the digital key from the relay server. The invitation information IV2 is, for example, a URL link. The URL link contains the share information SH2 necessary for sharing the digital key. The friend device 51 then sends the invitation information IV2 to the third device 30C.

[0103] Subsequently, when the third device 30C receives the invitation information IV2, it performs the process in step S43. In step S43, the third device 30C obtains the share information SH2 based on the invitation information IV2. Specifically, the second device 30B downloads the share information SH2 from the URL link.

[0104] The share information SH2 includes, for example, the share key structure information STS, password information ATP2, activation start information ATP3, expiration date information ATP4, and name information ATP5. Note that the activation start information ATP3, expiration date information ATP4, and name information ATP5 are set by the friend device 51. After that, the third device 30C proceeds to step S44.

[0105] In step S44, the third device 30C generates unsigned non-friend key information DKNN using the share information SH2. Unsigned non-friend key information DKNN is non-friend key information DKNN that does not have signature information ATP1. Specifically, the third device 30C generates each piece of information contained in the acquired share information SH2 as the pieces of information in the unsigned non-friend key information DKNN. Subsequently, the third device 30C sends a completion notification M31 indicating that it has finished uploading the generated unsigned non-friend key information DKNN to a URL link, and a signature request D32 requesting a signature.

[0106] Subsequently, 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 obtains the unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process in step S45 by being operated.

[0107] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 prompts the HMI 32 to present the acquired unsigned non-friend key information DKNN and accepts an operation indicating consent to the generation of the non-friend key KN by the user of the friend device 51. Once the operation is performed, the friend device 51 obtains a signature based on the fact that the operation has been performed. After that, the friend device 51 proceeds to step S46.

[0108] In step S46, the friend device 51 adds the signature information ATP1 to the unsigned non-friend key information DKNN. This causes the friend device 51 to generate the non-friend key information DKN. The friend device 51 then uploads the generated non-friend key information DKN to the URL link which is the invitation information IV2. Finally, the friend device 51 sends a completion notification M32 to the third device 30C indicating that it has finished uploading the completed non-friend key information DKN to the URL link.

[0109] Subsequently, the third device 30C receives a completion notification M32. Then, the third device 30C performs the process in step S47. In step S47, the third device 30C downloads and stores the non-friendly key information DKN. As a result, the third device 30C becomes a non-friendly device 52. Then, the third device 30C proceeds to step S48.

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

[0111] Subsequently, when the management server 70 receives a key track request D33 for a non-friendly key KN, the management server 70 performs the process in step S49. In step S49, the management server 70 performs registration management for the non-friendly key KN.

[0112] Specifically, the management server 70 verifies that the non-friendly key KN, which is the target of keytrack request D33, is not on the rejection list. If the non-friendly key KN is on the rejection list, the management server 70 sends a notification to the third device 30C that it cannot fulfill keytrack request D33.

[0113] On the other hand, if the non-friendly key KN is not on the rejection list, the management server 70 registers the non-friendly 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 vehicle 20 data DA in the database DB as device 30 registered as a non-friendly 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-friendly key information DKN. Specifically, the management server 70 stores the third device 30C as device 30 having a non-friendly key KN registered by the registration request D31 from the second device 30B.

[0114] Subsequently, the management server 70 sends the authentication package ATP from the non-friendly 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 sends the device public key information ST6, which indicates the device public key PKD of the non-friendly device 52, to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD has been signed by the friendly device 51.

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

[0116] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M33 to the second device 30B. Subsequently, when the second device 30B receives the key track completion notification M33, it performs the process in step S51. In the process of step S51, the third device 30C presents information to the HMI 32 indicating the completion of registration of the non-friendly key KN. For example, the third device 30C displays an image on the HMI 32 indicating the completion of registration of the non-friendly key KN. With this, the management system 10 completes the series of processes for registering the non-friendly key KN.

[0117] <Deletion of Non-Friend Key KN via Deletion Reservation D41 from Friend Device 51> Next, we will describe the series of processes for deleting non-friendly keys (KNs) in the management system 10. Below, we will describe the sequence of events from a state where non-friendly keys (KNs) are registered to a state where non-friendly keys (KNs) are not registered.

[0118] As shown in Figure 9, the management system 10 performs a series of operations to delete the non-friend key KN based on the deletion reservation D41 from the second device 30B, which is the friend device 51.

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

[0120] The deletion reservation D41 includes a signal requesting the deletion of a non-friend key KN, digital key identification information ST3 indicating the non-friend key KN, and information indicating a default condition RC. The default condition RC is the condition required to start the deletion after receiving the deletion reservation D41. The default condition RC is predetermined. The deletion reservation D41 includes name information ATP5, which is information identifying the friend device 51 that transmits the deletion reservation D41 to the management server 70. The friend device 51 then transmits the deletion reservation D41 of the non-friend key KN to the management server 70.

[0121] Subsequently, when the management server 70 receives the deletion reservation D41 for the non-friend key KN, it performs the process in step S62. In step S62, the management server 70 generates a pending notification M41 indicating that the deletion reservation D41 is pending. The management server 70 then sends the pending notification M41 to the friend device 51.

[0122] Subsequently, when the friend device 51 receives the pending notification M41, the friend device 51 performs the process in step S63. In step S63, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key KN, which is the target of the deletion reservation D41, is pending.

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

[0124] In step S65, the management server 70 verifies that the default condition RC is met. Once the management server 70 verifies that the default condition RC is met, the management server 70 proceeds to step S66.

[0125] In step S66, the management server 70 generates a deletion command D42 to delete the non-friend key information DKN, which indicates the non-friend key KN that is the target of the deletion reservation D41. The management server 70 then sends the deletion command D42 to the third device 30C, which is the non-friend device 52.

[0126] Subsequently, when the non-friend device 52 receives the deletion command D42, it performs the process in step S67. In step S67, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion command D42. Then, the non-friend device 52 sends a deletion completion notification M42 to the management server 70, indicating that it has completed the deletion in accordance with the deletion command D42.

[0127] Subsequently, when the management server 70 receives the completion notification M42, the management server 70 performs the process in step S68. In step S68, the management server 70 stores the history of deleting the non-friend key information DKN on the non-friend device 52. After that, the management server 70 proceeds to step S69.

[0128] In step S69, the management server 70 generates a deletion command D43 for the authentication information AT. This deletion command D43 for the authentication information AT indicates a request to delete the authentication information AT used to authenticate the non-friend key KN that is the target of the deletion reservation D41. The management server 70 then sends the deletion command D43 to the vehicle 20.

[0129] Subsequently, when vehicle 20 receives the deletion command D43, vehicle 20 performs the process in step S70. In step S70, vehicle 20 deletes the authentication information AT for authenticating the non-friendly key KN that is the target of the deletion reservation D41, in accordance with the deletion command D43. That is, vehicle 20 deletes the authentication package ATP for the non-friendly key KN. After that, vehicle 20 sends a deletion completion notification M43 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion command D43.

[0130] Subsequently, when the management server 70 receives the completion notification M43, the management server 70 performs the process in step S71. In step S71, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the non-friend key KN that is to be deleted in this series of deletion processes in the vehicle 20. After that, the management server 70 proceeds to step S72.

[0131] In step S72, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52, which has the non-friend key KN that is the target of deletion in this series of processes, from the vehicle data DA of the vehicle 20 in the database DB. After that, the management server 70 sends a deletion completion notification M44 to the friend device 51, indicating that the series of deletions of the non-friend key KN according to the deletion reservation D41 has been completed.

[0132] Subsequently, when the friend device 51 receives the completion notification M44, the friend device 51 performs the process in step S73. In step S73, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key KN, which is the target of the deletion reservation D41, has been completed. For example, the friend device 51 displays an image on the HMI 32 indicating that the deletion of the non-friend key KN has been completed. After that, the management system 10 completes the series of processes for the deletion of this non-friend key KN.

[0133] Next, we will describe the series of processes that occur when the management system 10 receives a default delete operation. The default delete operation is an operation that deletes all digital keys registered in the vehicle 20.

[0134] As shown in Figure 10, in step S80, a deletion operation is performed on the HMI22, which is the user interface of the vehicle 20, to delete all digital keys registered in the vehicle 20. When the vehicle 20 receives a deletion operation to delete all digital keys registered in the vehicle 20, it proceeds to step S81.

[0135] In step S81, the vehicle 20 determines whether the fob key 80 is authenticated by the vehicle 20. If the fob key 80 is not authenticated by the vehicle 20 (step S81: NO), the vehicle 20 proceeds to step S82 shown in Figure 11.

[0136] <Step S81: If NO> In step S82, the vehicle 20 generates a pending notification M50. The pending notification M50 is a notification indicating that the state of the digital key on which the deletion operation was performed will be set to a fade-out state in which the digital key will be deleted if the default condition RC is met. The pending notification M50 includes a condition for ending the fade-out state and completely deleting the digital key.

[0137] Vehicle 20 transmits a pending notification M50 to owner device 40 by controlling communication module 21. Vehicle 20 transmits a pending notification M50 to friend device 51 by controlling communication module 21. Figure 11 shows a second device 30B representing friend device 51. Vehicle 20 transmits a pending notification M50 to non-friend device 52 by controlling communication module 21. Figure 11 shows a third device 30C representing non-friend device 52. Vehicle 20 transmits a pending notification M50 to management server 70 by controlling communication module 21.

[0138] When the owner device 40 receives the pending notification M50, the owner device 40 performs the process in step S83. In step S83, the owner device 40 stores the fade-out state. After that, the owner device 40 proceeds to step S84.

[0139] In step S84, the owner device 40 displays a notification image IM on the HMI 32's display indicating that the digital key is in a fade-out state. As shown in Figure 13, the notification image IM includes an image showing the digital key in a fade-out state. Specifically, the notification image IM includes an image showing all the digital keys registered to the vehicle 20. For example, if the digital keys registered to the vehicle 20 are the first digital key DK1 to the third digital key DK3, the notification image IM includes images showing the strings "first digital key", "second digital key", and "third digital key".

[0140] The notification image IM includes an image indicating the conditions for ending the fade-out state and completely deleting the digital key. The conditions for ending the fade-out state and completely deleting the digital key are that the fob key 80 is authenticated with the vehicle 20, or that a new digital key is registered with the vehicle 20. When the user selects the part of the notification image IM that says "Confirm," the owner device 40 stops displaying the notification image IM on the HMI 32's display.

[0141] When the friend device 51 receives the pending notification M50, the friend device 51 performs the process in step S85. In step S85, the friend device 51 stores the fade-out state. Then, the friend device 51 proceeds to step S86. In step S86, the friend device 51 displays a notification image IM on its display indicating that the digital key is in the fade-out state.

[0142] When the non-friend device 52 receives the pending notification M50, the non-friend device 52 performs the process in step S87. In step S87, the non-friend device 52 stores the fade-out state. Then, the non-friend device 52 proceeds to step S88. In step S88, the non-friend device 52 displays a notification image IM on its display indicating that the digital key is in the fade-out state.

[0143] When the management server 70 receives the pending notification M50, the management server 70 performs the process in step S89. In step S89, the management server 70 stores the fade-out state.

[0144] After vehicle 20 sends a pending notification M50, vehicle 20 proceeds to step S90. In step S90, vehicle 20 sets the state of all digital keys registered to vehicle 20 to the fade-out state. Then, vehicle 20 proceeds to step S91. In step S91, vehicle 20 displays a notification image IM on its display indicating that the digital keys are in the fade-out state. Then, vehicle 20 proceeds to step S92. In step S92, vehicle 20 performs a confirmation process to confirm that the default condition RC is met.

[0145] <Confirmation process> As shown in Figure 12, when vehicle 20 starts the verification process, vehicle 20 first performs the process in step S2. In step S2, vehicle 20 determines whether or not the fob key 80 has been authenticated to vehicle 20. If the fob key 80 is authenticated to vehicle 20 (step S2: YES), vehicle 20 terminates the verification process shown in Figure 12. If the fob key 80 is not authenticated to vehicle 20 (step S2: NO), vehicle 20 proceeds to step S3. In step S3, vehicle 20 determines whether or not a new digital key has been registered to vehicle 20. If a new digital key has been registered to vehicle 20 (step S3: YES), vehicle 20 terminates the verification process shown in Figure 12. If a new digital key has not been registered to vehicle 20 (step S3: NO), vehicle 20 proceeds to step S2. In other words, vehicle 20 continues the verification process until the fob key 80 is authenticated to vehicle 20 or a new digital key is registered to vehicle 20. When vehicle 20 has finished the verification process, vehicle 20 proceeds to step S93 shown in Figure 14.

[0146] As shown in Figure 14, in step S93, the vehicle 20 confirms that the default condition RC is met. The vehicle 20 determines that the default condition RC is met when the fob key 80 is authenticated to the vehicle 20. The vehicle 20 also determines that the default condition RC is met when a new digital key is registered to the vehicle 20. If the default condition RC is met, the vehicle 20 proceeds to step S94.

[0147] In step S94, the vehicle 20 deletes the authentication information AT of digital keys that are set to the fade-out state from the authentication information AT of digital keys stored in the storage device 28. Authentication information AT is second information related to the digital key. Subsequently, the vehicle 20 sends a completion notification M51 to the management server 70 indicating that the authentication information AT has been deleted.

[0148] When the management server 70 receives the completion notification M51, the management server 70 performs the process in step S95. In step S95, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the digital key to be deleted in this series of deletion processes in the vehicle 20.

[0149] After vehicle 20 sends completion notification M51, vehicle 20 performs the process in step S96. In step S96, vehicle 20 generates deletion request D51. Deletion request D51 is a request to the management server 70 to delete information related to the digital key. Vehicle 20 sends deletion request D51 to the management server 70. The process then continues as shown in Figure 15.

[0150] As shown in Figure 15, when the management server 70 receives a deletion request D51, the management server 70 performs the process in step S97. In step S97, the management server 70 generates a deletion command D52 to delete the key information DK that indicates the digital key targeted by the deletion request D51. The key information DK is the first information relating to the digital key. The management server 70 then sends the deletion command D52 to the devices 30 that store the key information DK that indicates the digital key targeted by the deletion request D51. Specifically, the management server 70 sends the deletion command D52 to the first device 30A, the second device 30B, and the third device 30C.

[0151] When the third device 30C receives the deletion command D52, the third device 30C performs the process in step S98. In step S98, the third device 30C deletes the non-friend key information DKN in accordance with the deletion command D52. The non-friend key information DKN is the first information. Then, the third device 30C sends a deletion completion notification M52 to the management server 70, indicating that the deletion in accordance with the deletion command D52 has been completed.

[0152] When the second device 30B receives the deletion command D52, the second device 30B performs the process in step S99. In step S99, the second device 30B deletes the friend key information DKF in accordance with the deletion command D52. The friend key information DKF is the first information. Then, the second device 30B sends a deletion completion notification M53 to the management server 70, indicating that the deletion in accordance with the deletion command D52 has been completed.

[0153] When the first device 30A receives the deletion command D52, the first device 30A performs the process in step S98. In step S98, the first device 30A deletes the owner key information DKO in accordance with the deletion command D52. The owner key information DKO is the first information. Then, the first device 30A sends a deletion completion notification M54 to the management server 70, indicating that the deletion in accordance with the deletion command D52 has been completed.

[0154] When the management server 70 receives completion notifications from all devices 30 to which the deletion command D52 was sent, the management server 70 performs the process in step S101. That is, when the management server 70 receives completion notifications M52, M53, and M54, the management server 70 performs the process in step S101. In step S101, the management server 70 stores the history of the deletion of key information DK on the devices 30. After that, the management server 70 proceeds to step S102 shown in Figure 16.

[0155] As shown in Figure 16, in step S102, the management server 70 updates the database DB. Specifically, the management server 70 deletes the device 30, which has the digital key to be deleted in this series of processes, from the vehicle 20 data DA in the database DB. Subsequently, the management server 70 sends a deletion completion notification M55 to the first device 30A, the second device 30B, the third device 30C, and the vehicle 20, indicating that the series of deletions of the digital key in accordance with the deletion request D51 has been completed.

[0156] When the first device 30A receives the completion notification M55, the first device 30A performs the process in step S104. In step S104, the first device 30A presents information to the HMI 32 indicating that the deletion of all digital keys registered to the vehicle 20 has been completed. For example, the first device 30A displays an image on the HMI 32 indicating that the deletion of all digital keys that were set to fade-out has been completed.

[0157] When the second device 30B receives the completion notification M55, the second device 30B performs the process in step S105. In step S105, the second device 30B presents information to the HMI 32 indicating that the deletion of all digital keys registered to the vehicle 20 has been completed. For example, the second device 30B displays an image on the HMI 32 indicating that the deletion of all digital keys that were set to fade-out has been completed.

[0158] When the third device 30C receives the completion notification M55, the third device 30C performs the process in step S106. In step S106, the third device 30C presents information to the HMI 32 indicating that the deletion of all digital keys registered to the vehicle 20 has been completed. For example, the third device 30C displays an image on the HMI 32 indicating that the deletion of all digital keys that were set to fade-out has been completed.

[0159] When vehicle 20 receives completion notification M55, vehicle 20 performs the process in step S107. In step S107, the third device 30C presents information to HMI 22 indicating that the deletion of all digital keys registered in vehicle 20 that were set to fade-out status has been completed. For example, vehicle 20 displays an image on HMI 22 indicating that the deletion of all digital keys set to fade-out status has been completed. Subsequently, the management system 10 completes the series of processes for this default deletion operation.

[0160] <Step S81: If YES> If the fob key 80 is authenticated by the vehicle 20 (step S81: YES), the vehicle 20 proceeds to step S110 shown in Figure 17.

[0161] In step S110, similar to step S94 shown in Figure 14, the vehicle 20 deletes the authentication information AT for all digital keys stored in the storage device 28. Subsequently, the vehicle 20 sends a completion notification M51 to the management server 70 indicating that the authentication information AT stored in the storage device 28 has been deleted.

[0162] Upon receiving the completion notification M51, the management server 70 performs the process in step S111. Since the process in step S111 is the same as the process in step S95 shown in Figure 14, a detailed explanation is omitted.

[0163] After vehicle 20 sends completion notification M51, vehicle 20 performs the process in step S112. In step S112, similar to step S96 shown in Figure 14, vehicle 20 generates deletion request D51. Deletion request D51 is a request to the management server 70 to delete information related to the digital key. Vehicle 20 sends deletion request D51 to the management server 70. The process then continues as shown in Figure 15. The subsequent processing is the same as the processing from step S97 onwards when the fob key 80 is not authenticated by vehicle 20 (step S81: NO), so a detailed explanation is omitted.

[0164] <Operation of the First Embodiment> Vehicle 20 accepts a delete operation for the authentication information AT stored in the vehicle 20 via the HMI 22, which is the user interface of the vehicle 20. Authentication information AT is second information relating to the digital key. When vehicle 20 accepts a delete operation via the HMI 22, if the default condition RC is met, vehicle 20 deletes the authentication information AT. Therefore, until the default condition RC is met, device 30, which stores the key information DK corresponding to the authentication information AT stored in vehicle 20, functions as a digital key registered in vehicle 20. Key information DK is first information relating to the digital key.

[0165] <Effects of the First Embodiment> (1-1) When vehicle 20 receives a deletion operation via HMI 22, vehicle 20 sets the state of the deleted digital key to the fade-out state. Furthermore, if the default condition RC is met after setting the digital key to the fade-out state, vehicle 20 deletes the authentication information AT of the digital key set to the fade-out state. Therefore, by not deleting the authentication information AT until the default condition RC is met, vehicle 20 can reduce the possibility of causing inconvenience to the user by suddenly rendering the device 30 owned by the user unusable as a digital key.

[0166] (1-2) When the default deletion operation is performed to delete all digital keys registered in the vehicle 20, the execution device 27 sets the state of the deleted digital keys to the fade-out state. Once all digital keys set to the fade-out state are deleted, the vehicle 20 can no longer be used with the device 30 that was registered as a digital key. The vehicle 20 can reduce the possibility of causing inconvenience to the user by suddenly rendering all digital keys registered in the vehicle 20 unusable.

[0167] (1-3) Vehicle 20 can also be operated by authentication of the fob key 80. If the fob key 80 is authenticated by vehicle 20, vehicle 20 can be operated by the fob key 80 even if the digital key registered to vehicle 20 is deleted. If the fob key 80 is not authenticated by vehicle 20 and the digital key registered to vehicle 20 is deleted, the fob key 80 must be authenticated by vehicle 20 in order to operate vehicle 20. The execution device 27 sets the state of the deleted digital key to a fade-out state when the default deletion operation is performed while the fob key 80 is not authenticated by vehicle 20. Vehicle 20 can reduce the possibility that the digital key registered to vehicle 20 may suddenly become unusable when the fob key 80, which serves as a replacement for the digital key, is not authenticated by vehicle 20.

[0168] (1-4) The execution device 27 determines that the default condition RC has been met when the fob key 80 is authenticated to the vehicle 20. When the fob key 80 is authenticated to the vehicle 20, the vehicle 20 can be operated using the fob key 80 even if the digital key is deleted. Therefore, the execution device 27 determines that the default condition RC has been met when the fob key 80 is authenticated to the vehicle 20. In situations where the vehicle 20 cannot authenticate the fob key 80, which serves as a substitute for the digital key, the possibility of the digital key registered to the vehicle 20 suddenly becoming unusable can be reduced.

[0169] (1-5) The execution device 27 determines that the default condition RC is met when a new digital key is registered to the vehicle 20. When a new digital key is registered to the vehicle 20, the vehicle 20 can be operated with the new digital key even if the digital key that was registered before the new digital key was deleted. Therefore, the execution device 27 determines that the default condition RC is met when a new digital key is registered to the vehicle 20. The vehicle 20 can reduce the possibility that the digital key registered to the vehicle 20 will suddenly become unusable when no new digital key has been registered to the vehicle 20.

[0170] (1-6) The vehicle 20 is equipped with an HMI 22 as a display for displaying images. The execution device 27 displays a notification image IM on the display indicating that the digital key is in a fade-out state. The vehicle 20 can then present information about the digital key that is in a fade-out state to the passenger of the vehicle 20.

[0171] (1-7) The notification image IM includes conditions for ending the fade-out state and completely deleting the digital key. There is a need for the passengers of vehicle 20 to know the conditions under which the digital key will be deleted. The notification image IM includes conditions for completely deleting the digital key. Therefore, vehicle 20 can satisfy this need.

[0172] (1-8) The owner of vehicle 20 has a need to be aware of any deletion operations performed by operating the interface of vehicle 20. Vehicle 20 is equipped with a communication module 21. The execution device 27 controls the communication module 21 to send a pending notification M50 to the owner device 40 indicating that the digital key is in a fade-out state. This allows vehicle 20 to meet the needs of its owner.

[0173] (1-9) There is a need for digital key users to know whether the digital key registered in their device 30 is in a fade-out state. The vehicle 20 is equipped with a communication module 21. The execution device 27 controls the communication module 21 to send a pending notification M50 indicating that the digital key is entering a fade-out state to the device 30 which stores information about the digital key that is entering the fade-out state. In this way, the vehicle 20 can satisfy the needs of the digital key users.

[0174] (1-10) There is a need among digital key users to understand the conditions under which the digital key will be completely deleted. The pending notification M50 includes the conditions for completely deleting the digital key. Therefore, the above vehicle 20 can satisfy the needs of digital key users.

[0175] <Example of modification of the first embodiment> The first embodiment described above can be implemented with the following modifications. Vehicle 20 may perform the process in step S81 if it receives a deletion operation from a source other than HMI22 that deletes all digital keys registered to Vehicle 20.

[0176] As shown in Figure 18, in step S120, the owner device 40 performs a default deletion operation. The default deletion operation is an operation to delete all digital keys registered in the vehicle 20. After that, the owner device 40 proceeds to step S121. In step S121, the owner device 40 generates a deletion request D80 and sends the deletion request D80 to the vehicle 20. The deletion request D80 is a request to delete all digital keys registered in the vehicle 20. If the vehicle 20 receives the deletion request D80, it proceeds to step S81. The subsequent processing is the same as the processing from step S81 onwards in the first embodiment, so a detailed explanation is omitted. In this way, even when the default deletion operation is performed in the owner device 40, the execution device 27 can still perform the actions of setting the state of the digital keys to the fade-out state and deleting the second information when the default condition RC is met.

[0177] (Second Embodiment) The management system 10 according to the second embodiment will be described below with reference to Figures 19 to 24. The second embodiment will be described primarily in terms of the differences from the first embodiment. In the following, the differences from the first embodiment will be described in detail, and the same points will be simplified or omitted.

[0178] As shown in Figure 19, in step S130, a default deletion operation is performed on the HMI 22, which is the user interface of the vehicle 20. The default deletion operation is a deletion operation that deletes all digital keys registered in the vehicle 20. When the vehicle 20 receives a deletion operation that deletes all digital keys registered in the vehicle 20, it proceeds to step S131.

[0179] In step S131, vehicle 20 determines whether the fob key 80 is authenticated by vehicle 20. If the fob key 80 is not authenticated by vehicle 20 (step S131: NO), vehicle 20 proceeds to step S132 shown in Figure 20.

[0180] <Step S131: If NO> In step S132, the vehicle 20 generates a deletion request D60. The deletion request D60 is a request to the management server 70 to delete information related to the digital key. The vehicle 20 sends the deletion request D60 to the management server 70.

[0181] When the management server 70 receives the deletion request D60, the management server 70 performs the process in step S133. In step S133, the management server 70 sets the state of the deleted digital key to a fade-out state, where the digital key is deleted if the default condition RC is met. After that, the management server 70 proceeds to step S134.

[0182] In step S134, the vehicle 20 generates a pending notification M60. The pending notification M60 is a notification indicating that the state of the deleted digital key will be set to a fade-out state in which the digital key will be deleted if the default condition RC is met. The pending notification M60 includes a condition to terminate the fade-out state and completely delete the digital key.

[0183] The management server 70 transmits a pending notification M60 to the owner device 40 by controlling the communication module 73. The management server 70 transmits a pending notification M60 to the friend device 51 by controlling the communication module 73. Figure 20 shows the second device 30B representing the friend device 51. The management server 70 transmits a pending notification M60 to the non-friend device 52 by controlling the communication module 73. Figure 20 shows the third device 30C representing the non-friend device 52. The management server 70 transmits the pending notification M60 and the default condition RC to the vehicle 20 by controlling the communication module 73.

[0184] When the owner device 40 receives the pending notification M60, the owner device 40 performs the process in step S135. In step S135, the owner device 40 stores the fade-out state. After that, the owner device 40 proceeds to step S136.

[0185] In step S136, the owner device 40 displays a notification image IM on the HMI 32's display indicating that the digital key is in a fade-out state. Step S136 is identical to step S84 in the first embodiment, so a detailed explanation is omitted.

[0186] When the friend device 51 receives the pending notification M60, the friend device 51 performs the process in step S137. In step S137, the friend device 51 stores the fade-out state. Then, the friend device 51 proceeds to step S138. In step S138, the friend device 51 displays a notification image IM on the HMI 32's display indicating that the digital key is in the fade-out state.

[0187] When the non-friend device 52 receives the pending notification M60, the non-friend device 52 performs the process in step S139. In step S139, the non-friend device 52 stores the fade-out state. Then, the non-friend device 52 proceeds to step S140. In step S140, the non-friend device 52 displays a notification image IM on the HMI 32's display indicating that the digital key is in the fade-out state.

[0188] When vehicle 20 receives the pending notification M60 and the default condition RC, vehicle 20 performs the process in step S141. In step S141, vehicle 20 stores the fade-out state. Then, vehicle 20 proceeds to step S142. In step S142, vehicle 20 stores the default condition RC. Then, vehicle 20 proceeds to step S143. In step S143, vehicle 20 displays a notification image IM on the HMI22 display indicating that the digital key is in the fade-out state. The process then continues as shown in Figure 21.

[0189] <Processing performed by management server 70> As shown in Figure 21, after the vehicle 20 completes the process in step S143, the vehicle 20 and the management server 70 jointly perform the process in step S144. In step S144, the vehicle 20 and the management server 70 jointly perform the verification process.

[0190] As shown in Figure 22, when the vehicle 20 and the management server 70 start the verification process, the vehicle 20 first performs the process in step S5. In step S5, the vehicle 20 determines whether or not the fob key 80 has been authenticated with respect to the vehicle 20. The vehicle 20 then sends the determination result to the management server 70. If the fob key 80 has been authenticated with respect to the vehicle 20 (step S5: YES), the vehicle 20 and the management server 70 terminate the verification process shown in Figure 22. If the fob key 80 has not been authenticated with respect to the vehicle 20 (step S5: NO), that is, when the management server 70 receives a determination result indicating that the fob key 80 has not been authenticated with respect to the vehicle 20, the management server 70 proceeds to step S6. In step S6, the management server 70 determines whether or not a new digital key has been registered with the vehicle 20. The management server 70 then sends the determination result to the vehicle 20. If a new digital key is registered in vehicle 20 (step S6: YES), vehicle 20 and management server 70 terminate the verification process shown in Figure 22. If a new digital key is not registered in vehicle 20 (step S6: NO), that is, when vehicle 20 receives a determination result that a new digital key is not registered in vehicle 20, vehicle 20 performs the process in step S5 again. In other words, vehicle 20 and management server 70 continue the verification process until the fob key 80 is authenticated to vehicle 20 or a new digital key is registered in vehicle 20. Once the verification process is complete, management server 70 proceeds to step S146 shown in Figure 21.

[0191] As shown in Figure 21, in step S146, the management server 70 confirms that the default condition RC is met. The management server 70 determines that the default condition RC is met when the fob key 80 is authenticated to the vehicle 20. The management server 70 also determines that the default condition RC is met when a new digital key is registered to the vehicle 20. If the default condition RC is met, the management server 70 proceeds to step S148 shown in Figure 23.

[0192] As shown in Figure 23, in step S148, the management server 70 generates a deletion command D61 to delete the key information DK that indicates the digital key targeted by the deletion request D60. The key information DK is the first information relating to the digital key. The management server 70 then sends the deletion command D61 to the devices 30 that store the key information DK that indicates the digital key targeted by the deletion request D60. Specifically, the management server 70 sends the deletion command D61 to the first device 30A, the second device 30B, and the third device 30C.

[0193] When the third device 30C receives the deletion command D61, the third device 30C performs the process in step S149. In step S149, the third device 30C deletes the non-friend key information DKN in accordance with the deletion command D61. The non-friend key information DKN is the first information. Then, the third device 30C sends a deletion completion notification M61 to the management server 70, indicating that the deletion in accordance with the deletion command D61 has been completed.

[0194] When the second device 30B receives the deletion command D61, the second device 30B performs the process in step S150. In step S150, the second device 30B deletes the friend key information DKF in accordance with the deletion command D61. The friend key information DKF is the first information. Then, the second device 30B sends a deletion completion notification M62 to the management server 70, indicating that the deletion in accordance with the deletion command D61 has been completed.

[0195] When the first device 30A receives the deletion command D61, the first device 30A performs the process in step S151. In step S151, the first device 30A deletes the owner key information DKO in accordance with the deletion command D61. The owner key information DKO is the first information. Then, the first device 30A sends a deletion completion notification M63 to the management server 70, indicating that the deletion in accordance with the deletion command D61 has been completed.

[0196] <Processing performed by vehicle 20> As shown in Figure 21, once the verification process in step S144 is completed, the vehicle 20 proceeds to step S147.

[0197] In step S147, the vehicle 20 confirms that the default condition RC is met. The vehicle 20 determines that the default condition RC is met when the fob key 80 is authenticated to the vehicle 20. The vehicle 20 also determines that the default condition RC is met when a new digital key is registered to the vehicle 20. If the default condition RC is met, the vehicle 20 proceeds to step S152 shown in Figure 23.

[0198] In step S152, the vehicle 20 deletes all digital key authentication information AT stored in the storage device 28 that are set to the fade-out state. Authentication information AT is secondary information related to the digital key. Subsequently, the vehicle 20 sends a completion notification M64 to the management server 70 indicating that the authentication information AT has been deleted.

[0199] <Processing performed by the management server 70 after receiving the completion notification> When the management server 70 receives completion notifications from all devices 30 to which the deletion command D61 was sent, and also receives completion notification M64 from the vehicle 20, the management server 70 performs the process in step S153. That is, when the management server 70 receives completion notifications M61, M62, M63, and M64, the management server 70 performs the process in step S153. In step S153, the management server 70 stores the history of the deletion of key information DK on device 30. After that, the management server 70 proceeds to step S102 shown in Figure 16. The subsequent processing is the same as the processing from step S102 onwards in the first embodiment, so a detailed explanation is omitted.

[0200] <Step S131: If YES> As shown in Figure 24, if the fob key 80 is authenticated by the vehicle 20 (step S131: YES), the vehicle 20 proceeds to step S160.

[0201] In step S160, the vehicle 20 generates a deletion request D60 and an authentication notification M65. The deletion request D60 is a request to delete all digital keys registered in the vehicle 20. The authentication notification M65 is a notification indicating that the fob key 80 has been authenticated by the vehicle 20. Subsequently, the vehicle 20 sends the deletion request D60 and the authentication notification M65 to the management server 70.

[0202] When the management server 70 receives the deletion request D60 and the authentication notification M65, the management server 70 performs the series of processes shown in Figure 23. Also, after the vehicle 20 sends the deletion request D60 and the authentication notification M65, the vehicle 20 performs the process shown in step S152 of Figure 23.

[0203] <Operation of the second embodiment> When the default condition RC is met, the vehicle 20 deletes the authentication information AT stored in the vehicle 20's storage device 28. Therefore, until the default condition RC is met, the device 30 that stores the key information DK corresponding to the authentication information AT stored in the vehicle 20 functions as a digital key registered in the vehicle 20.

[0204] <Effects of the second embodiment> According to the second embodiment, in addition to the effects (1-2) to (1-7) of the first embodiment, the following effects are achieved.

[0205] (2-1) When vehicle 20 receives a deletion request via HMI 22, vehicle 20 sends a deletion request D60 to the management server 70. After vehicle 20 receives a pending notification M60 from the management server 70, if the default condition RC is met, it deletes the authentication information AT of the target digital key. Therefore, by not deleting the authentication information AT until the default condition RC is met, vehicle 20 can reduce the possibility of causing inconvenience to the user by suddenly rendering the device 30 owned by the user unusable as a digital key.

[0206] (2-2) The owner of vehicle 20 has a need to be aware of any deletion operations performed by operating the interface of vehicle 20. The management server 70 sends a pending notification M60 to the owner device 40 indicating that the digital key is in a fade-out state. This allows the management system 10 to meet the needs of the owner of vehicle 20.

[0207] (2-3) Digital key users have a need to know whether the digital key registered to their device 30 is in a fade-out state. The management server 70 sends a pending notification M60 indicating that the digital key is about to enter a fade-out state to the device 30 which stores information about the digital key that is about to enter a fade-out state. This allows the management system 10 to meet the needs of the digital key users.

[0208] (2-4) There is a need among digital key users to know the conditions under which the digital key will be completely deleted. The pending notification M60 includes the conditions for completely deleting the digital key. Therefore, the management system 10 can meet the needs of digital key users.

[0209] <Example of modification of the second embodiment> The second embodiment described above can be implemented with the following modifications. Vehicle 20 may perform the process in step S131 if it receives a deletion operation from a source other than HMI22 that deletes all digital keys registered to Vehicle 20.

[0210] As shown in Figure 25, in step S170, the owner device 40 performs a default deletion operation. The default deletion operation is an operation to delete all digital keys registered in the vehicle 20. After that, the owner device 40 proceeds to step S171. In step S171, the owner device 40 generates a deletion request D90 and sends the deletion request D90 to the vehicle 20. The deletion request D90 is a request to delete all digital keys registered in the vehicle 20. If the vehicle 20 receives the deletion request D90, it proceeds to step S131. The subsequent processing is the same as the processing from step S131 onwards in the second embodiment, so a detailed explanation is omitted. In this way, even when the default deletion operation is performed in the owner device 40, the execution device 27 can still send a deletion request D60 to the management server 70 and delete the second information if the default condition RC is met.

[0211] (Third embodiment) The management server 70 according to the third embodiment will be described below with reference to Figures 26 to 29. The third embodiment will be described primarily in terms of the differences from the first embodiment. In the following, the differences from the first embodiment will be the main focus of the description, and the same points will be simplified or omitted.

[0212] As shown in Figure 26, in step S170, a default deletion operation is performed on the HMI 22, which is the user interface of the vehicle 20. The default deletion operation is a deletion operation that deletes all digital keys registered in the vehicle 20. When the vehicle 20 receives a deletion operation that deletes all digital keys registered in the vehicle 20, it proceeds to step S171.

[0213] In step S171, vehicle 20 generates a deletion request D70. Deletion request D70 is a request to the management server 70 to delete all digital keys registered in vehicle 20. Subsequently, vehicle 20 sends deletion request D70 to the management server 70.

[0214] When the management server 70 receives the deletion request D70, the management server 70 performs the process of step S172. In step S172, the management server 70 determines whether the fob key 80 is authenticated by the vehicle 20. For example, the vehicle 20 transmits information indicating whether the fob key 80 has been authenticated for the vehicle 20 to the management server 70. Next, the management server 70 receives, from the vehicle 20, the information indicating whether the fob key 80 has been authenticated for the vehicle 20. Then, the management server 70 determines, based on the received information, whether the fob key 80 has been authenticated for the vehicle 20.

[0215] <When S172: NO> When the fob key 80 is not authenticated for the vehicle 20 (S172: NO), the management server 70 advances the process to step S173.

[0216] As shown in Fig. 27, in step S173, the management server 70 sets the state of the deleted digital key to a fade-out state in which the digital key is deleted when a predetermined condition RC is satisfied. Thereafter, the management server 70 advances the process to step S174.

[0217] In step S174, the management server 70 generates a pending notification M70. The pending notification M70 is a notification indicating that the state of the deleted digital key is set to a fade-out state in which the digital key is deleted when a predetermined condition RC is satisfied. The pending notification M70 includes a condition for terminating the fade-out state and completely deleting the digital key.

[0218] Subsequently, the management server 70 transmits a pending notification M70 to the owner device 40 by controlling the communication module 73. The management server 70 transmits a pending notification M70 to the friend device 51 by controlling the communication module 73. Figure 27 shows the second device 30B representing the friend device 51. The management server 70 transmits a pending notification M70 to the non-friend device 52 by controlling the communication module 73. Figure 27 shows the third device 30C representing the non-friend device 52. The management server 70 transmits a pending notification M70 to the vehicle 20 by controlling the communication module 73.

[0219] When the owner device 40 receives the pending notification M70, the owner device 40 performs the process in step S175. In step S175, the owner device 40 stores the fade-out state. After that, the owner device 40 proceeds to step S176.

[0220] In step S176, the owner device 40 displays a notification image IM on the HMI 32's display indicating that the digital key is in a fade-out state. Step S176 is identical to step S84 in the first embodiment, so a detailed explanation is omitted.

[0221] When the friend device 51 receives the pending notification M70, the friend device 51 performs the process in step S177. In step S177, the friend device 51 stores the fade-out state. Then, the friend device 51 proceeds to step S178. In step S178, the friend device 51 displays a notification image IM on the HMI 32's display indicating that the digital key is in the fade-out state.

[0222] When the non-friend device 52 receives the pending notification M70, the non-friend device 52 performs the process in step S179. In step S179, the non-friend device 52 stores the fade-out state. Then, the non-friend device 52 proceeds to step S180. In step S180, the non-friend device 52 displays a notification image IM on the HMI 32's display indicating that the digital key is in the fade-out state.

[0223] When vehicle 20 receives the pending notification M70, vehicle 20 performs the process in step S181. In step S181, vehicle 20 stores the fade-out state. Then, vehicle 20 proceeds to step S182. In step S182, vehicle 20 displays a notification image IM on the HMI22 display indicating that the digital key is in the fade-out state.

[0224] After the management server 70 sends a pending notification M70, the management server 70 performs the process in step S183. In step S183, the management server 70 performs a confirmation process. The process in step S183 is the same as the process in step S92 in the first embodiment, so the details are omitted. The communication module 73 obtains information from the vehicle 20 indicating whether or not the fob key 80 has been authenticated by the vehicle 20. The communication module 73 also obtains information indicating whether or not a new digital key has been registered in the vehicle 20.

[0225] The management server 70 determines whether the fob key 80 has been authenticated with respect to the vehicle 20, based on information received from the vehicle 20 indicating whether the fob key 80 has been authenticated. The management server 70 also determines whether a new digital key has been registered with the vehicle 20, based on information indicating whether a new digital key has been registered with the vehicle 20. After the management server 70 has completed the process in step S183, the management server 70 proceeds to step S184.

[0226] In step S184, the management server 70 confirms that the default condition RC is met. The management server 70 determines that the default condition RC is met if the fob key 80 is authenticated to the vehicle 20. The management server 70 also determines that the default condition RC is met if a new digital key is registered to the vehicle 20. If the default condition RC is met, the management server 70 proceeds to step S185.

[0227] In step S185, the management server 70 generates a deletion command D71 that deletes the key information DK, which indicates the digital key targeted by the deletion request D70. The key information DK is the first information relating to the digital key.

[0228] As shown in Figure 28, after the management server 70 has completed the process in step S185, the management server 70 sends a deletion command D61 to the device 30 that stores key information DK indicating the digital key targeted by the deletion request D70. Specifically, the management server 70 sends the deletion command D71 to the first device 30A, the second device 30B, and the third device 30C.

[0229] When the third device 30C receives the deletion command D71, the third device 30C performs the process in step S186. In step S186, the third device 30C deletes the non-friend key information DKN in accordance with the deletion command D71. The non-friend key information DKN is the first information. Then, the third device 30C sends a deletion completion notification M71 to the management server 70, indicating that the deletion in accordance with the deletion command D71 has been completed.

[0230] When the second device 30B receives the deletion command D71, the second device 30B performs the process in step S187. In step S187, the second device 30B deletes the friend key information DKF in accordance with the deletion command D71. The friend key information DKF is the first information. Then, the second device 30B sends a deletion completion notification M72 to the management server 70, indicating that the deletion in accordance with the deletion command D71 has been completed.

[0231] When the first device 30A receives the deletion command D71, the first device 30A performs the process of step S188. In step S188, the first device 30A deletes the owner key information DKO in accordance with the deletion command D71. The owner key information DKO is first information. Then, the first device 30A transmits a completion notification M73 of deletion completion indicating that deletion according to the deletion command D71 has been completed, to the management server 70.

[0232] When the management server 70 receives completion notifications from all the devices 30 that are destinations of the deletion command D61, the management server 70 performs the process of step S189. In step S189, the management server 70 generates a deletion command D72 for deleting the authentication information AT of the digital key that is the target of the deletion request D70. Thereafter, the management server 70 transmits the deletion command D72 to the vehicle 20.

[0233] When the vehicle 20 receives the deletion command D72, the vehicle 20 performs the process of step S190. In step S190, the vehicle 20 deletes all pieces of digital key authentication information AT that are set to a fade-out state, from among the pieces of digital key authentication information AT stored in the storage device 28. The authentication information AT is second information related to the digital key. Thereafter, the vehicle 20 transmits a completion notification M74 of deletion completion indicating that deletion according to the deletion command D72 has been completed, to the management server 70.

[0234] When the management server 70 receives the completion notification M74, the management server 70 performs the process of step S191. Since the process of step S191 is the same as the process of step S153 in the second embodiment, a detailed description is omitted.

[0235] <When S172: YES> As shown in FIG. 29, when the fob key 80 is authenticated by the vehicle 20 (step S172: YES), the vehicle 20 advances the process to step S200 shown in FIG. 29.

[0236] In step S200, the management server 70 generates a deletion command D71 to delete the key information DK that indicates the digital key targeted by the deletion request D70. The key information DK is the first piece of information relating to the digital key. Subsequently, the management server 70 proceeds to the series of processes shown in Figure 28.

[0237] <Operation of the Third Embodiment> When the management server 70 receives a deletion request D70, it sets the state of the digital key to which the deletion request D70 was made to a fade-out state, and then deletes the digital key if the default condition RC is met. Therefore, the digital key remains active and is not deleted until the default condition RC is met.

[0238] <Effects of the Third Embodiment> According to the third embodiment, in addition to the effects (2-2) to (2-4) of the second embodiment, the following effects are achieved.

[0239] (3-1) When the communication module 73 receives a deletion request D70, the execution device 71 sets the state of the digital key for which the deletion request D70 was made to a fade-out state. The execution device 71 also deletes the digital key for which the deletion request D70 was made if the default condition RC is met. Therefore, by not deleting the digital key until the default condition RC is met, the management server 70 can reduce the possibility that the user may feel uncomfortable because the device 30 owned by the user suddenly becomes unusable due to the digital key.

[0240] (3-2) When the default deletion operation is performed to delete all digital keys registered to the vehicle 20, the execution device 71 sets the state of the deleted digital keys to the fade-out state. Once all digital keys set to the fade-out state are deleted, the vehicle 20 can no longer be used with the device 30 that was registered as a digital key. In this regard, according to the management server 70, digital keys are not deleted until the default condition RC is met. Therefore, the management server 70 can reduce the possibility that users may feel inconvenienced by all digital keys registered to the vehicle 20 suddenly becoming unusable.

[0241] (3-3) If the fob key 80 is authenticated by the vehicle 20, the vehicle 20 can be operated using the fob key 80 even if the digital key registered in the vehicle 20 is deleted. If the fob key 80 is not authenticated by the vehicle 20 and the digital key registered in the vehicle 20 is deleted, the fob key 80 must be authenticated by the vehicle 20 in order to operate the vehicle 20. If the fob key 80 is not authenticated by the vehicle 20 and a deletion request D70 is received, the execution device 71 sets the state of the deleted digital key to a fade-out state. Therefore, the management server 70 can reduce the possibility that the digital key registered in the vehicle 20 may suddenly become unusable if the fob key 80, which serves as a substitute for the digital key, is not authenticated by the vehicle 20.

[0242] (3-4) If the fob key 80 is authenticated to the vehicle 20, the vehicle 20 can be operated using the fob key 80 even if the digital key is deleted. Therefore, the execution device 27 determines that the predetermined condition RC is met when the fob key 80 is authenticated to the vehicle 20. In situations where the vehicle 20 cannot authenticate the fob key 80, which serves as a substitute for the digital key, the possibility of the digital key registered to the vehicle 20 suddenly becoming unusable can be reduced.

[0243] (3-5) When a new digital key is registered to the vehicle 20, the vehicle 20 can be operated with the new digital key even if the digital key that was registered before the new digital key was registered is deleted. Therefore, the execution device 71 determines that the predetermined condition RC is met when a new digital key is registered to the vehicle 20. The vehicle 20 can reduce the possibility that the digital key registered to the vehicle 20 will suddenly become unusable when no new digital key has been registered to the vehicle 20.

[0244] (3-6) The pending notification M70 includes conditions for completely removing the digital key from the fade-out state. Therefore, the vehicle 20 and device 30 may include an image in the notification image IM that they display when they receive the pending notification M70 that shows the conditions for completely removing the digital key.

[0245] <Example of modification of the third embodiment> The third embodiment described above can be implemented with the following modifications. The management server 70 may perform the process in step S172 if it receives a deletion operation from a source other than the vehicle 20 that deletes all digital keys registered in the vehicle 20.

[0246] As shown in Figure 30, in step S210, the owner device 40 performs a default deletion operation. After that, the owner device 40 proceeds to step S211. In step S211, the owner device 40 generates a deletion request D100 and sends a deletion request D90 to the management server 70. The deletion request D90 is a request to delete all digital keys registered in the vehicle 20. When the management server 70 receives the deletion request D100, it proceeds to step S172. The subsequent processing is the same as the processing from step S172 onwards in the second embodiment, so a detailed explanation is omitted. In this way, when the owner device 40 receives the deletion request D100, the execution device 71 can be configured to set the state of the digital key to a fade-out state and delete the digital key if the default condition RC is met.

[0247] <Other examples of changes> Each of the above embodiments can be implemented with the following modifications. Each of the above embodiments and the following modifications can be combined with each other to the extent that they do not contradict each other technically.

[0248] <Management System 10> Vehicle 20 does not necessarily have to have some of the BLE module 23, UWB module 24, and NFC module 25. Vehicle 20 can perform short-range communication with device 30 if it has at least one of these modules. Furthermore, vehicle 20 is not limited to these modules, and may have any module that can perform short-range communication with device 30.

[0249] Vehicle 20 does not necessarily have to be operable by authentication of the fob key 80. A different ECU installed in a different vehicle 20 than the vehicle management device 26 may authenticate the digital key.

[0250] • The matters concerning digital keys in each of the above embodiments do not have to comply with CCC. The vehicle management device 26 is not limited to a digital key ECU. For example, it may be a central ECU that manages multiple ECUs in a vehicle 20.

[0251] 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). Alternatively, the vehicle management device 26 may be configured as a circuit including one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs), or a combination thereof, that execute at least some of the various processes. 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. Memory, i.e., computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer. The same applies to device 30 and management server 70.

[0252] Device 30 is not limited to a smartphone. It may also be a smartwatch. Device 30 may also be a predetermined server. In this case, the predetermined server may contain Device 30. For example, if a rental company and a sharing company are the owners of the vehicle 20, the owner device 40 may be contained in the predetermined server. Also, for example, the friend device 51 may be contained in the predetermined server.

[0253] In each of the embodiments described above, the digital keys have a hierarchy in the order of owner key KO, friend key KF, and non-friend key KN, with higher levels of authority assigned to each key. However, the digital keys do not necessarily have to be configured so that higher levels of authority assign to each key. For example, the same level of authority may be assigned to all three levels: owner key KO, friend key KF, and non-friend key KN.

[0254] ·The sharing device 50 has a function of receiving the sharing key KS as in the above embodiment. Like the sharing device 50, the device 30 having a function of receiving a digital key may be referred to as a receiver device.

[0255] ·The device server 60 does not need to be provided for each type of the device 30. It is only required that a plurality of devices 30 and the management server 70 are capable of wireless communication. The device server 60 may be omitted. It is only required that a plurality of devices 30 and the management server 70 can directly perform wireless communication with each other.

[0256] ·The management server 70 may be configured by a plurality of servers. For example, the management server 70 may be configured by a server that stores the database DB and a server that executes the server program PS. Further, for example, the management server 70 may be configured by a server that communicates with the vehicle 20 and a server that communicates with the device server 60, and these servers may be capable of communicating with each other. ·The management server 70 does not need to store the database DB. It is only required that the management server 70 manages, 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.

[0258] ·Deleting a digital key means changing the digital key from a usable state to an unusable state. In each of the above embodiments, when either one of the authentication information AT and the key information DK is deleted for one digital key, the digital key becomes an unusable state.

[0259] Therefore, "deleting the digital key" refers to deleting at least one of authentication information AT, which is information related to the digital key stored by the vehicle management device 26, and key information DK, which is information related to the digital key stored by the device 30. When both the authentication information AT and the key information DK are deleted, the digital key is deleted at the timing when either one of them is deleted first.

[0260] <On Various Types of Information> ·The information related to the digital key stored by the vehicle management device 26 is not limited to the authentication information AT, and may be any information related to the digital key. For example, the information related to the digital key may be information for identifying the digital key.

[0261] ·The information related to the digital key stored by the device 30 is not limited to the key information DK, and may be any information related to the digital key. For example, the information related to the digital key may be information for identifying the digital key.

[0262] ·The information related to the digital key stored by the vehicle management device 26 may be different from or the same as the information related to the digital key stored by the device 30 as in the above embodiment.

[0263] ·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 the digital key is used. For example, the authentication information AT may be a common key shared between the vehicle management device 26 and the device 30. Further, for example, the authentication information AT may be a common secret key.

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

[0265] The database DB may include information indicating the type of device 30. The type of device 30 is information indicating one of the following, for example, a smartphone, a smartwatch, and a predetermined server as in the modified example above.

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

[0267] In a database (DB), privileges are not uniformly defined according to the type of digital key, but may be set for each digital key. Furthermore, privileges may not be defined at all in a database (DB).

[0268] The series of processes for registering the owner key KO is not limited to the examples of the embodiments described above. For example, even if pairing is not performed by the process in step S12, the owner device 40 may store the owner key information DKO by having the vehicle 20 and the first device 30A send and receive information such as generated data DC via the management server 70. The series of processes for registering the owner key KO may be modified as appropriate to match the structure of the information contained in the owner key information DKO and the structure of the information contained in the authentication information AT.

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

[0270] The series of processes for registering a non-friend key KN is not limited to the examples of the embodiments described above. The order of the processes may differ from the series of processes for registering a friend key KF. The series of processes for registering a non-friend key KN may be modified as appropriate to match 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.

[0271] The types of digital keys do not necessarily include non-friend keys (KN). In other words, in the management system 10, the share key KS may consist only of friend keys (KF). In this case, the target digital key may be an owner key (KO), and the digital key registered based on the target digital key may be a friend key (KF).

[0272] Non-friend device 52 may send a request to register for a new non-friend key KN. In other words, share device 50 may send a request to register for a new non-friend key KN, regardless of whether it is friend device 51 or non-friend device 52.

[0273] If a new digital key is registered, some digital keys do not need to be deleted so that the use of the new digital key can continue. For example, if a new digital key is registered based on a registration request from the eighth device 30H, the digital keys that are directly related to the new digital key do not need to be deleted. In this case, in the first embodiment, the vehicle 20 does not need to delete the first digital key DK1, the second digital key DK2, the third digital key DK3, and the eighth digital key DK8.

[0274] In the first embodiment, if a deletion operation is performed while the fob key 80 is authenticated by the vehicle 20, the vehicle 20 may set the state of the digital key that was deleted to a fade-out state. In the second embodiment, if a deletion operation is performed while the fob key 80 is authenticated by the vehicle 20, the vehicle 20 may send a deletion request D60 to the management server 70. In the third embodiment, if a deletion request D70 is received while the fob key 80 is authenticated by the vehicle 20, the management server 70 may set the state of the digital key targeted by the deletion request D70 to a fade-out state.

[0275] The deletion operation may be an operation that deletes some of the digital keys registered in the vehicle 20. In this case, for example, in the first embodiment, the vehicle 20 does not delete the authentication information AT of the digital keys that are not to be deleted, and generates a deletion request D51 to generate a deletion command D52 to delete only the digital keys that are not to be deleted.

[0276] The default condition RC is not limited to the examples of the above embodiments. The default condition RC does not necessarily include the case when the fob key 80 has been authenticated with respect to the vehicle 20. The default condition RC does not necessarily include the case when a new digital key has been registered with the vehicle 20. The default condition RC may include, for example, the vehicle 20 being powered on again with a mechanical key.

[0277] Vehicle 20 does not have to display pending notifications M50, M60, or M70 on the HMI22 display. Vehicle 20 does not have to include an image representing each pending notification in the notification image IM, and vehicle 20 does not have to display the notification image IM.

[0278] In each embodiment, the pending notifications M50, M60, and M70 do not necessarily include conditions for ending the fade-out state and completely deleting the digital key.

[0279] •In the first embodiment, the vehicle 20 does not need to transmit the pending notification M50 to the owner device 40, and does not need to transmit the pending notification M50 to the sharing device 50. •In the second embodiment, the management server 70 does not need to transmit the pending notification M70 to the vehicle 20. Furthermore, the management server 70 does not need to transmit the pending notification M70 to each device 30.

[0280] •In the second embodiment, the vehicle 20 may transmit the pending notification M70 to the owner device 40, and may transmit the pending notification M70 to the sharing device 50. For example, the management server 70 may transmit the pending notification M70 only to the vehicle 20, and thereafter, the vehicle 20 may transmit the received pending notification M70 to each device 30.

[0281] <Supplementary Notes> The technical ideas that can be grasped from the above embodiments and modified examples are described below. [Supplementary Note 1] A vehicle that is communicable with a device storing first information relating to a digital key, the device is registered as the digital key in the vehicle, the vehicle comprising: a user interface that accepts an operation from a user of the vehicle; a storage device that stores second information relating to the digital key corresponding to the first information stored in the device; and a processing circuit, wherein when a deletion operation, which is an operation to delete the digital key registered in the vehicle, is accepted via the user interface, the processing circuit executes: setting a state of the digital key subjected to the deletion operation to a fade-out state in which the digital key is deleted when a predetermined condition is satisfied; and deleting, when the predetermined condition is satisfied, the second information relating to the digital key set to the fade-out state stored in the storage device.

[0282] [Supplementary Note 2] The vehicle according to Supplementary Note 1, wherein the deletion operation is an operation to delete all of the digital keys registered in the vehicle. [Note 3] The vehicle can also be operated by authentication of a fob key, and if the deletion operation is performed while the fob key is not authenticated to the vehicle, the processing circuit sets the state of the digital key that has been deleted to the fade-out state, as described in Note 1 or Note 2.

[0283] [Note 4] The vehicle can also be operated by authentication of the fob key, and when the fob key is authenticated for the vehicle, the processing circuit determines that the predetermined conditions have been met, as described in any one of Notes 1 to 3.

[0284] [Note 5] A vehicle described in any one of Notes 1 to 4, in which the processing circuit determines that the predetermined conditions have been met when a new digital key is registered for the vehicle. [Note 6] A vehicle according to any one of Notes 1 to 5, comprising a display for displaying an image, wherein the processing circuit displays a pending notification on the display indicating that the state of the digital key that has been deleted has been set to the fade-out state.

[0285] [Note 7] The pending notification is for the vehicle described in Note 7, which includes the condition that the fade-out state ends and the digital key is completely deleted. [Note 8] A vehicle according to any one of Notes 1 to 7, comprising a communication module, wherein the processing circuit controls the communication module to send a pending notification to the owner device indicating that the state of the digital key that has been deleted has been set to the fade-out state.

[0286] [Note 9] A vehicle according to any one of Notes 1 to 8, comprising a communication module, wherein the processing circuit controls the communication module to transmit a pending notification to a device storing information about the digital key set to the fade-out state, indicating that the state of the digital key that has been deleted has been set to the fade-out state.

[0287] [Note 10] The pending notification is for any vehicle described in any one of Notes 6 to 9, which includes the conditions for ending the fade-out state and completely deleting the digital key. [Note 11] A vehicle that can communicate with a server that manages digital keys and a device that stores first information relating to the digital key, and the device is registered as the digital key, and comprises a user interface that accepts operations from the user of the vehicle, a storage device that stores second information relating to the digital key corresponding to the first information stored in the device, and a processing circuit, wherein when a deletion operation is received via the user interface, which is an operation to delete the digital key registered in the vehicle, the processing circuit sends a deletion request to the server to delete the digital key registered in the vehicle, and after receiving a pending notification from the server indicating that the state of the digital key for which the deletion request has been made has been set to a fade-out state in which the digital key will be deleted if a default condition is met, the processing circuit deletes the second information relating to the digital key set to the fade-out state stored in the storage device if the default condition is met.

[0288] [Note 12] The vehicle described in Note 12, wherein the deletion operation is an operation to delete all of the digital keys registered in the vehicle. [Note 13] The vehicle can also be operated by authentication of a fob key, and if the deletion operation is performed while the fob key is not authenticated to the vehicle, the processing circuit sets the state of the digital key that has been deleted to the fade-out state, as described in Note 11 or Note 12.

[0289] [Note 14] The vehicle can also be operated by authentication of the fob key, and when the fob key is authenticated for the vehicle, the processing circuit determines that the predetermined condition has been met, as described in any one of Notes 11 to 13.

[0290] [Note 15] A vehicle described in any one of Notes 11 to 14, in which the processing circuit determines that the predetermined conditions have been met when a new digital key is registered for the vehicle. [Note 16] A vehicle according to any one of Notes 11 to 15, comprising a display for displaying an image, wherein the processing circuit displays on the display a pending notification indicating that the state of the digital key that has been deleted has been set to the fade-out state.

[0291] [Note 17] The pending notification is for the vehicle described in Note 16, which includes the condition that the fade-out state ends and the digital key is completely deleted. [Note 18] The pending notification is for a vehicle as described in either Note 16 or Note 17, which includes the condition that the fade-out state ends and the digital key is completely deleted.

[0292] [Note 19] A management server that is able to communicate with a vehicle and stores a device that stores first information relating to a digital key registered for a vehicle, and second information relating to the digital key corresponding to the first information, and manages the digital key, comprising a communication module and a processing circuit, wherein when the communication module receives a deletion request from the vehicle to delete the digital key registered for the vehicle, the processing circuit executes the following: setting the state of the digital key for which the deletion request has been made to a fade-out state in which the digital key is deleted when a predetermined condition is met, and deleting the digital key set to the fade-out state when the predetermined condition is met.

[0293] [Note 20] The deletion request is a request to delete all of the digital keys registered in the vehicle, as described in Note 19, from the management server. [Note 21] The vehicle can also be operated by authentication of a fob key, and the communication module obtains information indicating whether or not the fob key has been authenticated by the vehicle, and when the fob key is not authenticated by the vehicle and the deletion request is received, the processing circuit sets the state of the digital key for which the deletion request has been made to the fade-out state, as described in Note 19 or Note 20.

[0294] [Note 22] The vehicle can also be operated by authentication of a fob key, the communication module obtains information indicating whether or not the fob key has been authenticated by the vehicle, and the processing circuit determines that the predetermined condition has been met when the fob key has been authenticated by the vehicle, as described in any one of Notes 19 to 21.

[0295] [Note 23] The management server described in any one of Notes 19 to 22, wherein the communication module acquires information indicating whether or not a new digital key has been registered to the vehicle, and the processing circuit determines that the predetermined condition has been met when a new digital key has been registered to the vehicle.

[0296] [Note 24] The management server according to any one of Notes 19 to 23, wherein the processing circuit controls the communication module to send a pending notification to the vehicle indicating that the digital key is in the fade-out state.

[0297] [Note 25] The management server according to any one of Notes 19 to 24, wherein the processing circuit controls the communication module to send a pending notification to the owner device indicating that the digital key is in the fade-out state.

[0298] [Note 26] The management server according to any one of Notes 19 to 25, wherein the processing circuit controls the communication module to send a pending notification indicating that the digital key is in the fade-out state to the device that stores information about the digital key set to the fade-out state.

[0299] [Note 27] The pending notification is a management server as described in any one of Notes 19 to 26, which includes a condition for ending the fade-out state and completely deleting the digital key. [Explanation of symbols]

[0300] 10…Management System 20... Vehicles 21…Communication module 28…Storage device 30…Device 40… Owner devices 70... Management Server 72...Storage device 73…Communication module 80... Fobkey RC…Default condition

Claims

1. A vehicle that can communicate with a device that stores first information relating to a digital key, and the device is registered as the digital key, A user interface that accepts operations from the user of the aforementioned vehicle, A storage device that stores second information relating to the digital key corresponding to the first information stored in the device, A processing circuit is provided, When a deletion operation is received via the user interface, which is an operation to delete the digital key registered in the vehicle, The processing circuit described above The state of the digital key that has undergone the aforementioned deletion operation is set to a fade-out state in which the digital key is deleted when a default condition is met, If the aforementioned default condition is met, delete the second information relating to the digital key that is set to the fade-out state and stored in the storage device. vehicle.

2. A vehicle that is able to communicate with a server that manages digital keys and a device that stores first information relating to the digital keys, and in which the device is registered as the digital key, A user interface that accepts operations from the user of the aforementioned vehicle, A storage device that stores second information relating to the digital key corresponding to the first information stored in the device, A processing circuit is provided, When a deletion operation is received via the user interface, which is an operation to delete the digital key registered in the vehicle, The processing circuit described above Sending a deletion request to the server to delete the digital key registered to the vehicle, After receiving a pending notification from the server indicating that the state of the digital key for which the deletion request has been made has been set to a fade-out state in which the digital key will be deleted if the default condition is met, the second information relating to the digital key set to the fade-out state stored in the storage device is deleted if the default condition is met. vehicle.

3. The aforementioned deletion operation is an operation to delete all of the digital keys registered to the vehicle. The vehicle according to claim 1 or claim 2.

4. The vehicle can also be operated by authentication using the fob key. If the deletion operation is performed while the fob key is not authenticated for the vehicle, The processing circuit described above The state of the digital key that has undergone the deletion operation is set to the fade-out state. The vehicle according to claim 1.

5. The vehicle can also be operated by authentication using the fob key. When the fob key is authenticated for the vehicle, The processing circuit described above It is determined that the aforementioned default conditions have been met. The vehicle according to claim 1 or claim 2.

6. When a new digital key is registered to the vehicle, The processing circuit described above It is determined that the aforementioned default conditions have been met. The vehicle according to claim 1 or claim 2.

7. Equipped with a display that shows images, The processing circuit described above The display shows a pending notification indicating that the state of the digital key that has been deleted has been set to the fade-out state. The vehicle according to claim 1 or claim 2.

8. The pending notification includes conditions for ending the fade-out state and completely deleting the digital key. The vehicle according to claim 7.

9. Equipped with a communication module, The processing circuit controls the communication module, A pending notification is sent to the owner device indicating that the state of the digital key, which has undergone the deletion operation, has been set to the fade-out state. The vehicle according to claim 1.

10. The pending notification includes conditions for ending the fade-out state and completely deleting the digital key. The vehicle according to claim 9.

11. Equipped with a communication module, The processing circuit controls the communication module, A pending notification indicating that the state of the digital key on which the deletion operation was performed has been set to the fade-out state is sent to the device that stores information about the digital key set to the fade-out state. The vehicle according to claim 1.

12. The pending notification includes conditions for ending the fade-out state and completely deleting the digital key. The vehicle according to claim 11.

13. A device that stores first information relating to a digital key registered for a vehicle, and a management server that is communicable to the vehicle and stores second information relating to the digital key corresponding to the first information, and manages the digital key, Communication module and Equipped with a processing circuit, When the communication module receives a deletion request from the vehicle to delete the digital key registered in the vehicle, The processing circuit described above The state of the digital key for which the deletion request has been made is set to a fade-out state in which the digital key is deleted when the default conditions are met, If the aforementioned default condition is met, the following actions are performed: delete the digital key that has been set to the fade-out state. Management server.

14. The aforementioned deletion request is a request to delete all of the digital keys registered to the vehicle. The management server according to claim 13.

15. The aforementioned vehicle can also be operated by authentication using a fob key. The communication module obtains information indicating whether the fob key is authenticated by the vehicle, If the fob key is not authenticated by the vehicle and the deletion request is received, The processing circuit described above The state of the digital key for which the deletion request has been made is set to the fade-out state. The management server according to claim 13.

16. The aforementioned vehicle can also be operated by authentication using a fob key. The communication module obtains information indicating whether the fob key is authenticated by the vehicle, The processing circuit described above When the fob key is authenticated for the vehicle, It is determined that the aforementioned default conditions have been met. The management server according to claim 13.

17. The communication module acquires information indicating whether or not a new digital key has been registered in the vehicle. The processing circuit When a new digital key is registered to the vehicle, It is determined that the aforementioned default conditions have been met. The management server according to claim 13.

18. The processing circuit controls the communication module, The digital key sends a pending notification to the vehicle indicating that it is in the fade-out state. The management server according to claim 13.

19. The processing circuit controls the communication module, A pending notification indicating that the digital key is in the fade-out state is sent to the owner device. The management server according to claim 13.

20. The processing circuit controls the communication module, A pending notification indicating that the digital key is in the fade-out state is sent to the device that stores information about the digital key set to the fade-out state. The management server according to claim 13.

21. The pending notification includes conditions for ending the fade-out state and completely deleting the digital key. The management server according to any one of claims 18 to 20.

Images