Vehicle management device, vehicle, deletion program, and deletion method

Abstract

This vehicle management device provides a system that can properly delete owner keys, which are set to use a server contracted by the owner as the owner device. [Solution] The vehicle stores information about the owner key. When an operation is made to request the deletion of the owner key from the vehicle management device, the vehicle management device determines the type of owner device (S121). If the vehicle management device determines that the owner device is a portable device owned by the owner (S122: YES), it executes a first deletion flow to delete the information about the owner key after completing authentication of the fob key through communication with the vehicle's fob key (S123). If the vehicle management device determines that it is a server belonging to the owner (S122: NO), it executes a second deletion flow, which is a different deletion flow from the first deletion flow, and deletes the information about the owner key if certain conditions are met (S125).

Description

Technical Field

[0001] The present disclosure relates to a vehicle management device, a vehicle, a deletion program, and a deletion method.

Background Art

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, a plurality of devices, and a management server. The vehicle includes a vehicle management device that stores authentication information for authenticating a digital key. The device stores key information indicating the digital key. The management server is capable of communicating with the device and the vehicle, and manages registration of digital keys.

Prior Art Literature

Patent Literature

[0003]

Patent Literature 1

Summary of the Invention

Problem to be Solved by the Invention

[0004] There are two types of digital keys registered to devices. The first is an owner key registered to an owner device belonging to the owner of the vehicle. The second is a shared key registered to a device other than the owner device in response to a request from a device on the management system including the owner device.

[0005] Regarding the owner key, there are two cases: one where a portable device owned by the owner such as a smartphone is used as the owner device, and the other where a server contracted by the owner is used as the owner device.

[0006] A digital key can control a vehicle when the device stores key information identifying the digital key, and the vehicle management system stores authentication information for the digital key. The vehicle management system can delete a digital key from its management system in response to a user request to delete the digital key. Deleting a digital key means rendering the digital key unusable for vehicle control. When a user requests the deletion of a digital key, the vehicle management system deletes the digital key by deleting the authentication information for that digital key that it has stored.

[0007] When the vehicle management system deletes an owner key using a portable device as the owner device, it performs authentication using the owner's fob key when deleting the stored information about the owner key.

[0008] However, owner keys that use a server contracted by the owner as the owner device are not used for vehicle control, but only for the function of generating and managing share keys. Therefore, the same deletion flow as for owner keys that use a mobile device owned by the owner as the owner device may not be applicable. [Means for solving the problem]

[0009] A vehicle management device that solves the above problems is a vehicle management device installed in a vehicle controllable by a digital key, in a management system that manages digital keys registered for a device. This vehicle management device comprises a processing circuit and a storage device. The storage device stores information about the owner key, which is the digital key registered for the owner device, which is the device belonging to the owner of the vehicle. When an operation is made to the vehicle management device requesting the deletion of the owner key in the management system, the processing circuit determines the type of the owner device. If the processing circuit determines that the owner device is a portable device owned by the owner, it executes a first deletion flow to delete the information about the owner key after authentication of the fob key is completed through communication with the vehicle's fob key. If the processing circuit determines that the owner device is a server belonging to the owner and is the server that generates the digital key for that device in response to a request from another device, it executes a second deletion flow, which is different from the first deletion flow, and deletes the information about the owner key when certain conditions are met.

[0010] A vehicle that solves the above problems is equipped with a vehicle management device. The vehicle management device is a vehicle management device installed in a vehicle controllable by a digital key, in a management system that manages digital keys registered for a device. The vehicle management device comprises a processing circuit and a storage device. The storage device stores information about the owner key, which is the digital key registered for the owner device, which is the device belonging to the owner of the vehicle. When an operation is made to the vehicle management device requesting the deletion of the owner key in the management system, the processing circuit determines the type of the owner device. If the processing circuit determines that the owner device is a portable device owned by the owner, it executes a first deletion flow to delete the information about the owner key after authentication of the fob key is completed through communication with the vehicle's fob key. If the processing circuit determines that the owner device is a server belonging to the owner and is the server that generates the digital key for that device in response to a request from another device, it executes a second deletion flow, which is different from the first deletion flow, and deletes the information about the owner key when certain conditions are met.

[0011] The deletion program that solves the above problem is a deletion program executed by a processing circuit of a vehicle management device installed in a vehicle controllable by a digital key, in a management system that manages digital keys registered for a device. The vehicle management device stores information about the owner key, which is the digital key registered for the owner device, which is the device belonging to the owner of the vehicle. When an operation is made to the vehicle management device requesting the deletion of the owner key in the management system, the deletion program causes the processing circuit to determine the type of the owner device. If the deletion program determines that the owner device is a portable device owned by the owner, it causes the processing circuit to execute a first deletion flow that deletes the information about the owner key after authentication of the fob key is completed through communication with the vehicle's fob key. If the deletion program determines that the owner device is a server belonging to the owner and is the server that generates the digital key for that device in response to a request from another device, it causes the processing circuit to execute a second deletion flow that deletes the information about the owner key, which is a different processing flow from the first deletion flow and deletes the information about the owner key when certain conditions are met.

[0012] A deletion method that solves the above problem is a deletion method for deleting an owner key, which is a digital key registered for an owner device, which is a device belonging to the owner of the vehicle, in a management system that manages the digital key and includes a vehicle management device installed in a vehicle that can be controlled by a digital key registered for the device. The vehicle management device stores information about the owner key. This deletion method includes the step of the vehicle management device determining the type of owner device when an operation is made to the vehicle management device requesting the deletion of the owner key in the management system. If the vehicle management device determines that the owner device is a portable device owned by the owner, this deletion method includes the step of the vehicle management device executing a first deletion flow to delete the information about the owner key after authentication of the fob key through communication with the vehicle's fob key is completed. If the vehicle management device determines that the owner device is a server belonging to the owner and is a server that generates the digital key for that device in response to a request from another device, this deletion method includes the step of the vehicle management device executing a second deletion flow to delete the information about the owner key, which is a different processing flow from the first deletion flow and is subject to specific conditions. [Effects of the Invention]

[0013] The above-described vehicle management device, vehicle, deletion program, and deletion method can properly delete owner keys that use the server contracted by the owner as the owner device. [Brief explanation of the drawing]

[0014] [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 owner key information in Figure 1. [Figure 3] Figure 3 is a schematic diagram showing the share key information in Figure 1. [Figure 4]Figure 4 is a schematic diagram showing data in the database of Figure 1. [Figure 5] Figure 5 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when an owner key is registered. [Figure 6] Figure 6 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when a friend key is registered. [Figure 7] Figure 7 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when a non-friend key is registered. [Figure 8] Figure 8 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when a non-friend key is deleted in response to a request from a friend device. [Figure 9] Figure 9 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when a non-friend key is deleted in response to a request from a non-friend device. [Figure 10] Figure 10 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when a friend key is deleted in response to a request from an owner device. [Figure 11] Figure 11 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when a friend key is deleted in response to a request from a friend device. [Figure 12] Figure 12 is a flowchart showing a series of processes executed by the vehicle management apparatus of Figure 1 when determining a deletion flow to be executed. [Figure 13] Figure 13 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when an owner key registered for a portable device is deleted in response to a request based on an operation on a vehicle. [Figure 14] Figure 14 is a flowchart showing a series of processes in a first deletion flow executed by the vehicle management apparatus of Figure 1. [Figure 15] Figure 15 is an explanatory diagram showing a series of processes performed by the management system of Figure 1 when an owner key registered for an SBOD server is deleted in response to a request based on an operation on a vehicle. [Figure 16]FIG. 16 is a flowchart showing a sequence of processing in a second deletion flow executed by the vehicle management device of FIG. 1. [Figure 17] FIG. 17 is a flowchart showing a sequence of processing in a second deletion flow executed by the vehicle management device in the management system according to a first modification. [Figure 18] FIG. 18 is a flowchart showing a sequence of processing in a second deletion flow executed by the vehicle management device in the management system according to a second modification. DETAILED DESCRIPTION OF THE INVENTION

[0015] (First Embodiment) An embodiment of the management system will be described below with reference to the drawings. <Outline of Management System 10> As shown in FIG. 1, the management system 10 manages a plurality of digital keys usable for a vehicle 20. A standard from the Car Connectivity Consortium (CCC) exists for digital keys. Matters relating to the digital key of the present embodiment conform to CCC. The management system 10 includes the vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

[0016] 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 is an abbreviation for Human Machine Interface. BLE is an abbreviation for Bluetooth Low Energy. UWB is an abbreviation for Ultra Wide Band. NFC is an abbreviation for Near Field Communication.

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

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

[0019] The vehicle management device 26 is installed in the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The execution device 27 is a processing circuit. The storage device 28 stores a vehicle program PV, a deletion program PC, and authentication information AT.

[0020] The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store the authentication information AT. The deletion program PC is executed by the execution device 27, causing the execution device 27 to delete the authentication information AT. The deletion program PC causes the execution device 27 to implement the deletion method described below. The authentication information AT is information used to authenticate a digital key in order to enable control of the vehicle 20 using 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. The execution device 27 executes processing related to the storage of authentication information AT by executing the vehicle program PV. The execution device 27 executes processing related to the deletion of authentication information AT by executing the deletion program PC.

[0021] Authenticating a digital key means enabling the vehicle 20 to be controlled by that 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. Also, for example, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be started.

[0022] Device 30 is a portable device 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.

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

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

[0025] 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, which in turn causes the execution device 36 to store and delete the key information DK. The key information DK is information that indicates a digital key.

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

[0027] The multiple devices 30 include an owner device 40 and multiple share devices 50. 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. The owner device 40 belongs to the owner of the vehicle 20.

[0028] The owner device 40 may not be a portable device, but rather a server belonging to the owner of the vehicle 20. This server belongs to the owner based on a contract with the owner. As will be described later, the owner device 40 can generate share keys KS for other devices. In the management system 10, if the owner device 40 is a server, the owner device 40 is used not to control the vehicle 20, but to generate share keys KS for other devices in response to requests from those devices.

[0029] Hereafter, a server belonging to the owner will be referred to as an SBOD server. SBOD stands for Server Based Owner Device. If the owner device 40 is an SBOD server, the owner device 40 does not need to have a BLE module 33, a UWB module 34, and an NFC module 35.

[0030] As shown in Figure 2, 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, and authorization public key information ST8.

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

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

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

[0034] As shown in Figure 1, the share device 50 stores share key information DKS, which indicates the share key KS, as key information DK. The share device 50 is a separate device 30 from the owner device 40. The share key KS is a digital key that can be registered multiple times for a single 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 a single vehicle 20.

[0035] 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. Non-friend device 52 stores non-friend key information DKN, which indicates non-friend key KN, as share key information DKS. In other words, the types of share keys KS include friend key KF and non-friend key KN. Friend key KF is a share key KS registered based on a direct registration request D21 from owner device 40, as will be described later. Non-friend key KN is a share key KS registered based on a registration request D31 from friend device 51, as will be described later. In other words, non-friend key KN is a share key KS registered not based on a direct registration request D21 from owner device 40, but based on a registration request D31 from another device 30. To put it another way, non-friend key KN is a share key KS that is not friend key KF.

[0036] 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, and the device 30 stores key information DK. When a digital key is registered, the digital key becomes capable of controlling the vehicle 20.

[0037] As shown in Figure 3, the share key information DKS includes the share key structure information STS and the 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 removed.

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

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

[0040] 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 key KS. For example, it is set as an identifiable name for each share device 50 through an operation from the owner device 40.

[0041] 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. For example, "type" refers to the model of the device 30, and a separate device server 60 is provided for each model of the device 30. For example, "type" also refers to the communication line used by the device 30, and a separate device server 60 is provided for each communication line used by the device 30.

[0042] Each device server 60 relays communication with the management server 70, allowing different types of devices 30 to communicate with the management server 70 via the device server 60. Note that only one device server 60 is shown in Figure 1.

[0043] <Management Server 70> The management server 70 manages the registration of 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.

[0044] The storage device 72 stores the server program PS and the database DB. The server program PS is executed by the execution device 71, causing the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB.

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

[0046] As shown in Figure 4, 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. A hierarchy is established based on 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.

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

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

[0049] This section describes a state in which a digital key is registered to seven devices 30 for one vehicle 20. The seven devices 30 are referred to as Device 1 30A to Device 7 30G. The digital keys registered to each of Devices 1 30A to Device 7 30G are referred to as Digital Key 1 to Digital Key 7.

[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 the owner device 40. In other words, the first digital key is Owner Key KO.

[0051] In the data DA, the devices 30 registered with the digital key type as Share Key KS are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. In other words, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are all Share Devices 50. That is, the second to seventh digital keys are all Share Key KS.

[0052] More specifically, in the data DA, the devices 30 registered with the digital key type as Friend Key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are Friend Devices 51. In the data DA, the devices 30 registered with the digital key type as Non-Friend Key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are Non-Friend Devices 52.

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

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

[0055] In the 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 is registered based on the second digital key.

[0056] 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 is registered based on the second digital key.

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

[0058] In data DA, the relationship between the 7th device 30G and the 5th device 30E is such that the non-friendly key KN is registered in the 7th device 30G based on a registration request from the 5th device 30E. In other words, the 7th digital key is registered based on the 5th digital key.

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

[0060] <Digital Key Registration> Next, we will describe the series of 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 processes 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.

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

[0062] In the management system 10, upon registration of the owner key KO, key information DK indicating the owner key KO is stored in the first device 30A. In the management system 10, upon registration of the owner key KO, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. 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.

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

[0064] Subsequently, vehicle 20 receives the pairing password PAS. After vehicle 20 receives the pairing password PAS, it is set to pairing mode by HMI 22 and waits to receive the password from the first device 30A. Then, vehicle 20 proceeds to step S12.

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

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

[0067] 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, the device public key information ST6 indicating the device public key PKD, and the device information TD to the vehicle 20.

[0068] As mentioned earlier, there are two types of devices that can be the owner device 40: mobile devices and SBOD servers. Device information TD is information that indicates the type of owner device 40.

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

[0070] In step S17, the vehicle 20 stores the device public key information ST6, which indicates the device public key PKD, as authentication information AT. At this time, the vehicle 20 stores in the storage device 28 the authentication information AT, which includes information indicating the type of owner device 40 based on the device information TD. 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.

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

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

[0073] <Registering Friend Key KF> As shown in Figure 6, the management system 10 performs a series of 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.

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

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

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

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

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

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

[0080] 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 fact that the operation has been performed. After that, the owner device 40 proceeds to step S26.

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

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

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

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

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

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

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

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

[0089] 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 displays an image indicating the registration of the friend key KF on the HMI 32. With this, the management system 10 completes the series of processes for registering the friend key KF.

[0090] <Registering Non-Friend Keys (KN)> As shown in Figure 7, the management system 10 performs a series of processes to register the non-friendly key KN. Of 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.

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

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

[0093] 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 third device 30C downloads the share information SH2 from the URL link.

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

[0095] 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, to the friend device 51.

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

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

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

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

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

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

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

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

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

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

[0106] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M33 to the third device 30C. Subsequently, when the third device 30C 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 indicating the completion of registration of the non-friendly key KN on the HMI 32. With this, the management system 10 completes the series of processes for registering the non-friendly key KN.

[0107] <Deleting the digital key> Next, a series of processes for deleting a digital key in the management system 10 will be described. As mentioned earlier, when a digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. When a digital key is registered, the digital key can control the vehicle 20. If at least one of the authentication information AT stored in the vehicle 20 or the key information DK stored in the device 30 is deleted, the digital key will no longer be able to control the vehicle 20.

[0108] Deleting the digital key means deleting at least one of the authentication information AT stored in the vehicle 20 and the key information DK stored in the device 30, thereby rendering the vehicle 20 uncontrollable by the digital key.

[0109] <Deleting Non-Friend Keys (KN)> Next, we will describe a series of processes for deleting non-friendly keys (KN) in the management system 10. Below, we will describe the sequence of events from a state where non-friendly keys (KN) are registered to a state where non-friendly keys (KN) are not registered. In the following explanation, processes executed by the execution device 27 will be described as processes executed by the vehicle 20, processes executed by the execution device 36 will be described as processes executed by the device 30, and processes executed by the execution device 71 will be described as processes executed by the management server 70.

[0110] <Deletion of non-friend key KN at the request of friend device 51> As shown in Figure 8, the management system 10 performs a series of operations to delete the non-friend key KN based on the deletion reservation request D41 from the friend device 51.

[0111] 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 request D41 for the non-friend key KN is generated. The deletion reservation request D41 is a signal that requests the deletion of the non-friend key KN when the specified condition RC, described later, is met.

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

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

[0114] Subsequently, when the friend device 51 receives the deletion 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 non-friend key KN, which is the subject of the deletion reservation request D41, is pending deletion and will be deleted as soon as the specified condition RC is met.

[0115] 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 request D41 as a fade-out state. The fade-out state means that the deletion reservation request D41 has been received, but the execution of the deletion is still pending. After that, the management server 70 proceeds to step S65.

[0116] In step S65, the management server 70 confirms that the specified condition RC is met. Once the management server 70 confirms that the specified condition RC is met, the management server 70 proceeds to step S66.

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

[0118] Subsequently, when the non-friend device 52 receives the deletion request 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 request 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 request D42.

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

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

[0121] Subsequently, when vehicle 20 receives deletion request D43, vehicle 20 performs the process in step S70. In step S70, vehicle 20 deletes the authentication information AT used to authenticate the non-friendly key KN that is the target of deletion reservation request D41, in accordance with deletion request D43. That is, vehicle 20 deletes the authentication package ATP of 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 deletion request D43.

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

[0123] 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 20 data DA in the database DB. After that, the management server 70 sends a deletion completion notification M44 to the friend device 51, indicating that it has completed the series of deletions of the non-friend key KN in accordance with the deletion reservation request D41.

[0124] 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 was the target of the deletion reservation request 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.

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

[0126] When a predetermined operation is performed in the non-friend device 52 to request the deletion of the non-friend key KN, the non-friend device 52 first performs the process in step S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN according to a predetermined operation. After that, the non-friend device 52 sends a deletion completion notification M51 to the management server 70 indicating that the non-friend key information DKN has been deleted.

[0127] Subsequently, when the management server 70 receives the completion notification M51, the management server 70 performs the process in step S82. In step S82, the management server 70 stores the history of the deletion of the non-friend key information DKN on the non-friend device 52. Then, the management server 70 sends a completion notification M52 to the friend device 51 indicating that the deletion of the non-friend key information DKN has been completed.

[0128] Subsequently, when the friend device 51 receives the completion notification M52, the friend device 51 performs the process in step S83. In step S83, the friend device 51 presents information to the HMI 32 indicating that the deletion of the non-friend key information DKN of the non-friend device 52 is complete. For example, the friend device 51 displays an image on the HMI 32 indicating that the deletion of the non-friend key KN is complete.

[0129] After processing in step S82, the management server 70 performs the processing in step S84. In step S84, the management server 70 generates a deletion request D51 that requests the deletion of the authentication information AT used to authenticate the non-friend key information DKN, which was deleted in step S81. The management server 70 then sends the deletion request D51 to the vehicle 20.

[0130] Subsequently, when vehicle 20 receives deletion request D51, vehicle 20 performs the process in step S85. In step S85, vehicle 20 deletes the authentication information AT used to authenticate the non-friend key information DKN that was deleted in step S81, in accordance with deletion request D51. Then, vehicle 20 sends a completion notification M53 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with deletion request D51.

[0131] Subsequently, when the management server 70 receives the completion notification M53, the management server 70 performs the process in step S86. In step S86, the management server 70 stores the history of deleting the authentication information AT used to authenticate the non-friend key information DKN, which was deleted in step S81. After that, the management server 70 proceeds to step S87.

[0132] In step S87, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friendly device 52, which has the non-friendly key KN that is the target of this series of processes, from the vehicle 20 data DA in the database DB. With this, the management system 10 completes the series of processes for deleting the non-friendly key KN.

[0133] <Deleting Friend Key KF> Next, we will describe the series of processes for deleting the friend key KF in the management system 10. Below, we will describe the sequence of events from the state in which the friend key KF is registered to the state in which the friend key KF is not 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.

[0134] <Deletion of Friend Key KF at the request of Owner Device 40> As shown in Figure 10, the management system 10 performs a series of operations to delete the friend key KF based on the deletion reservation request D61 from the owner device 40.

[0135] When an operation is performed on the owner device 40 to request the deletion of friend key KF, the owner device 40 first performs the process in step S91. In step S91, a deletion reservation request D61 for friend key KF is generated. The deletion reservation request D61 is a request for deletion reservation. The deletion reservation request D61 is a signal that requests the deletion of friend key KF when the specified condition RC, described later, is met.

[0136] The deletion reservation request D61 includes a signal requesting the deletion of friend key KF, digital key identification information ST3 indicating friend key KF, and information indicating a predetermined condition RC. The predetermined condition RC is a condition necessary to start the deletion after receiving the deletion reservation request D61. The predetermined condition RC is predetermined. For example, the predetermined condition RC is that a predetermined fade-out period has elapsed since receiving the deletion reservation request D61. The owner device 40 then sends the deletion reservation request D61 for friend key KF to the management server 70.

[0137] Subsequently, when the management server 70 receives the deletion reservation request D61 for friend key KF, it performs the process in step S92. In step S92, the management server 70 generates a deletion pending notification M61 indicating that the deletion is pending in accordance with the deletion reservation request D61. The management server 70 then sends the deletion pending notification M61 to the owner device 40.

[0138] Subsequently, when the owner device 40 receives the deletion pending notification M61, the owner device 40 performs the process in step S93. In step S93, the owner device 40 presents information to the HMI 32 indicating that the friend key KF, which is the subject of the deletion reservation request D61, is pending deletion and will be deleted as soon as the specified condition RC is met.

[0139] After processing in step S92, the management server 70 proceeds to the processing in step S94. In step S94, the management server 70 stores in the database DB the state of friend key KF, which is the target of the deletion reservation request D61, as a fade-out state. The fade-out state means that the deletion reservation request D61 has been received, but the execution of the deletion is still pending. After that, the management server 70 proceeds to the processing in step S95.

[0140] In step S95, the management server 70 confirms that the specified condition RC is met. Once the management server 70 confirms that the specified condition RC is met, the management server 70 proceeds to step S96.

[0141] In step S96, the management server 70 generates a deletion request D62 that requests the deletion of the friend key information DKF, which indicates the friend key KF that is the target of the deletion reservation request D61. The management server 70 then sends the deletion request D62 to the friend device 51.

[0142] Subsequently, when the friend device 51 receives the deletion request D62, it performs the process in step S97. In step S97, the friend device 51 deletes the friend key information DKF in accordance with the deletion request D62. Then, the friend device 51 sends a deletion completion notification M62 to the management server 70, indicating that it has completed the deletion in accordance with the deletion request D62.

[0143] Subsequently, when the management server 70 receives the completion notification M62, the management server 70 performs the process in step S98. In step S98, the management server 70 stores the history of the deletion of the friend key information DKF on the friend device 51. After that, the management server 70 proceeds to step S99.

[0144] In step S99, the management server 70 generates a request D63 to delete authentication information AT. This request D63 to delete authentication information AT, which is used to authenticate the friend key KF that is the target of the deletion reservation request D61, is a request to delete the authentication information AT. The management server 70 then sends the deletion request D63 to the vehicle 20.

[0145] Subsequently, when vehicle 20 receives deletion request D63, vehicle 20 performs the process in step S100. In step S100, vehicle 20 deletes the authentication information AT used to authenticate the friend key KF that is the target of deletion reservation request D61, in accordance with deletion request D63. That is, vehicle 20 deletes the authentication package ATP for friend key KF. After that, vehicle 20 sends a deletion completion notification M63 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with deletion request D63.

[0146] Subsequently, when the management server 70 receives the completion notification M63, the management server 70 performs the process in step S101. In step S101, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the friend key KF, which is to be deleted in this series of deletion processes in the vehicle 20. After that, the management server 70 proceeds to step S102.

[0147] In step S102, the management server 70 updates the database DB. Specifically, the management server 70 deletes the friend device 51, which has the friend key KF 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 M64 to the owner device 40, indicating that it has completed the series of deletions of friend key KF in accordance with the deletion reservation request D61.

[0148] Subsequently, when the owner device 40 receives the completion notification M64, the owner device 40 performs the process in step S103. In step S103, the owner device 40 presents information to the HMI 32 indicating that the deletion of the friend key KF, which was the subject of the deletion reservation request D61, has been completed. For example, the owner device 40 displays an image on the HMI 32 indicating that the deletion of the friend key KF has been completed. After that, the management system 10 completes the series of processes for the deletion of the friend key KF.

[0149] <Deletion of Friend Key KF due to deletion operation on Friend Device 50> As shown in Figure 11, the management system 10 performs a series of operations to delete the friend key KF indicated by the friend key information DKF stored in the friend device 51, in response to a deletion operation on the friend device 51.

[0150] When a predetermined operation is performed on the friend device 51 to request the deletion of the friend key KF, the friend device 51 first performs the process in step S111. In step S111, the friend device 51 deletes the friend key information DKF according to a predetermined operation. After that, the friend device 51 sends a deletion completion notification M71 to the management server 70 indicating that the friend key information DKF has been deleted.

[0151] Subsequently, when the management server 70 receives the completion notification M71, the management server 70 performs the process in step S112. In step S112, the management server 70 stores the history of the deletion of the friend key information DKF on the friend device 51. Then, the management server 70 sends a completion notification M72 to the owner device 40 indicating that the deletion of the friend key information DKF has been completed.

[0152] Subsequently, when the owner device 40 receives the completion notification M72, the owner device 40 performs the process in step S113. In step S113, the owner device 40 presents information to the HMI 32 indicating that the deletion of the friend key information DKF of the friend device 51 is complete. For example, the owner device 40 displays an image on the HMI 32 indicating that the deletion of the friend key KF is complete.

[0153] After the processing in step S112, the management server 70 performs the processing in step S114. In step S114, the management server 70 generates a deletion request D71 that requests the deletion of the authentication information AT used to authenticate the friend key information DKF, which was deleted in step S111. The management server 70 then sends the deletion request D71 to the vehicle 20.

[0154] Subsequently, when vehicle 20 receives deletion request D71, vehicle 20 performs the process in step S115. In step S115, vehicle 20 deletes the authentication information AT used to authenticate the friend key information DKF that was deleted in step S111, in accordance with deletion request D71. Then, vehicle 20 sends a completion notification M73 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with deletion request D71.

[0155] Subsequently, when the management server 70 receives the completion notification M73, the management server 70 performs the process in step S116. In step S116, the management server 70 stores the history of deleting the authentication information AT used to authenticate the friend key information DKF, which was deleted in step S111. After that, the management server 70 proceeds to step S117.

[0156] In step S117, the management server 70 updates the database DB. Specifically, the management server 70 deletes the friend device 51, which has the friend key KF that is the target of this series of processes, from the vehicle data DA of the vehicle 20 in the database DB. With this, the management system 10 completes the series of processes for deleting the friend key KF.

[0157] <Deleting Owner Key KO> Next, we will describe the series of processes for deleting the owner key KO in the management system 10.

[0158] When deleting an owner key KO, the vehicle management device 26 deletes the authentication information AT for the owner key KO stored in the storage device 28. At this time, the vehicle 20 deletes the authentication information AT by executing a deletion flow, which is a series of processing steps for deleting the authentication information AT for the owner key KO. Depending on the type of owner device 40, the form of the deletion flow executed by the vehicle 20 changes.

[0159] The vehicle management device 26 executes a deletion flow determination process when deleting authentication information AT for the owner key KO. The deletion flow determination process is a process in which the vehicle 20 determines the deletion flow according to the type of owner device 40.

[0160] The following will first describe the deletion flow determination process performed by the vehicle management device 26, and then explain the manner in which the management system 10 deletes the owner key KO, divided into cases where the owner device 40 is a portable device and cases where it is an SBOD server.

[0161] <Deletion flow determination process type> Figure 12 shows the sequence of processes in the deletion flow determination process performed by the vehicle 20. The sequence of processes shown in Figure 12 is executed by the execution device 27, as instructed by the deletion program PC.

[0162] As shown in Figure 12, when the execution device 27 executes the deletion flow determination process, it first executes the process in step S121. In step S121, the execution device 27 determines the type of owner device 40. At this time, the execution device 27 checks the authentication information AT stored in the storage device 28. As mentioned above, the authentication information AT stored in the storage device 28 contains information indicating the type of owner device 40. In the process of step S121, the execution device 27 determines whether the owner device 40 is a portable device or an SBOD server by checking the information indicating the type of owner device 40.

[0163] After determining the type of owner device 40, the execution device 27 executes the process in step S122. In the process of step S122, the execution device 27 determines whether or not the owner device 40 is a portable device.

[0164] If the execution device 27 determines in step S121 that the owner device 40 is a portable device, it determines in step S122 that the owner device 40 is a portable device. If the execution device 27 determines that the owner device 40 is a portable device (step S122: YES), it proceeds to step S123.

[0165] In step S123, the execution device 27 determines to execute the first deletion flow. The first deletion flow will be described later. After that, the execution device 27 completes the series of processes shown in Figure 12.

[0166] If the execution device 27 determines in step S121 that the owner device 40 is an SBOD server, then in step S122, it determines that the owner device 40 is not a portable device. If the execution device 27 determines that the owner device 40 is not a portable device (step S122: NO), it proceeds to step S124.

[0167] In step S124, the execution device 27 determines whether or not a protection function is set for the owner key KO. The protection function is a function that restricts the deletion of authentication information AT for the owner key KO. The protection function can be set using specific equipment. For example, the protection function for the owner key KO can be set by rewriting the settings of the vehicle management device 26 using a computer owned by a dealer that performs ECU updates and reprogramming.

[0168] If the execution device 27 determines that the protection function is not set (step S124: NO), it proceeds to step S125. In step S125, the execution device 27 determines to execute the second deletion flow. The second deletion flow will be described later. After that, the execution device 27 terminates the series of processes shown in Figure 12.

[0169] If the execution device 27 determines that the protection function is set (step S124: YES), it proceeds to step S126. In step S126, the execution device 27 determines that it will not delete the authentication information AT for the owner key KO. In other words, the vehicle management device 26 will not delete the authentication information AT for the owner key KO if the owner device 40 is an SBOD server and the protection function is set for the owner key KO. After that, the execution device 27 completes the series of processes shown in Figure 12.

[0170] The following describes the sequence of events from the state in which the owner key KO is registered to the state in which the owner key KO is not 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.

[0171] <If owner device 40 is a portable device (up to step S132)> Figure 13 shows how the management system 10 deletes the owner key KO when the owner device 40 is a portable device. In the series of processes shown in Figure 13, the processes performed by the vehicle 20 are executed by the deletion program PC, which is then executed by the execution device 27.

[0172] As shown in Figure 13, the management system 10 performs a series of operations to delete the owner key KO based on a deletion request operation for the vehicle 20. A deletion request operation is an operation performed on the vehicle 20 to request the deletion of the owner key KO. The user performs the deletion request operation, for example, by operating the HMI 22.

[0173] When a deletion request operation is made to vehicle 20, vehicle 20 first executes the process in step S131. In step S131, vehicle 20 executes the deletion flow determination process. In step S131, vehicle 20 executes the series of processes shown in Figure 12. In Figure 13, the owner device 40 is a portable device. Therefore, in the deletion flow determination process in step S131, vehicle 20 determines to execute the first deletion flow.

[0174] Subsequently, vehicle 20 executes the process in step S132. In step S132, vehicle 20 executes the first deletion flow. <First Deletion Flow> Figure 14 shows the sequence of processes in the first deletion flow. In vehicle 20, the vehicle management device 26 executes the sequence of processes shown in Figure 14 in step S132 of Figure 13. The sequence of processes shown in Figure 14 is executed by the execution device 27 via the deletion program PC.

[0175] In the series of processes shown in Figure 14, the execution device 27 first executes the process in step S141. In step S141, the execution device 27 authenticates the fob key of the vehicle 20. At this time, the execution device 27 communicates with the fob key, for example, via NFC communication. The execution device 27 may also communicate with the fob key using RFID, for example. RFID stands for Radio Frequency Identification. The execution device 27 then completes the authentication of the fob key when it confirms through communication with the fob key that the communicated fob key is a fob key that can legitimately control the vehicle 20. In step S131, the number of fob keys that the execution device 27 authenticates is one.

[0176] Subsequently, the execution device 27 executes the process in step S142. In step S142, the execution device 27 determines whether or not the authentication of the fob key has been completed through the process in step S141.

[0177] If the execution device 27 determines that the authentication of the fob key is complete (step S142: YES), it proceeds to step S143. In step S143, the execution device 27 deletes the authentication information AT for the owner key KO. After that, the execution device 27 terminates the series of processes shown in Figure 14.

[0178] If the execution device 27 determines that the authentication of the fob key has not been completed (step S142: NO), it terminates the series of processes shown in Figure 14. <If owner device 40 is a portable device (from step S132 onwards)> In the first deletion flow, if the vehicle 20 deletes the authentication information AT for the owner key KO as a result of executing the process in step S143, it sends a deletion completion notification M81 to the management server 70 indicating that the owner key KO has been deleted.

[0179] Subsequently, when the management server 70 receives the completion notification M81, the management server 70 performs the process in step S133. In step S133, the management server 70 stores the history of the deletion of the authentication information AT for the owner key KO. After that, the management server 70 proceeds to step S134.

[0180] In step S134, the management server 70 generates a deletion request D81 requesting the deletion of the owner key information DKO. The management server 70 then sends the deletion request D81 to the owner device 40.

[0181] Subsequently, when the owner device 40 receives the deletion request D81, the owner device 40 performs the process in step S135. In step S135, the owner device 40 deletes the owner key information DKO in accordance with the deletion request D81. Then, the owner device 40 sends a completion notification M82 to the management server 70 indicating that it has completed the deletion of the owner key information DKO in accordance with the deletion request D81.

[0182] Subsequently, when the management server 70 receives the completion notification M82, the management server 70 performs the process in step S136. In step S136, the management server 70 stores the history of the deletion of the owner key information DKO on the owner device 40.

[0183] Subsequently, the management server 70 performs the process in step S137. In step S137, the management server 70 updates the database DB. Specifically, the management server 70 deletes the owner device 40 of the owner key KO, which is the target of this series of processes, from the vehicle data DA in the database DB. With this, the management system 10 completes the series of processes for deleting the owner key KO.

[0184] <If owner device 40 is the SBOD server (up to step S152)> Figure 15 shows how the management system 10 deletes the owner key KO when the owner device 40 is an SBOD server. In the series of processes shown in Figure 15, the processes performed by the vehicle 20 are executed by the deletion program PC on the execution device 27. Note that in Figure 15, the owner key KO does not have a protection function set.

[0185] As shown in Figure 15, the management system 10 performs a series of operations to delete the owner key KO based on a deletion request operation for the vehicle 20. When a deletion request operation is made to vehicle 20, vehicle 20 first executes the process in step S151. In step S151, vehicle 20 executes the deletion flow determination process. In step S151, vehicle 20 executes the series of processes shown in Figure 12. In Figure 15, the owner device 40 is an SBOD server and no protection function is set. Therefore, in the deletion flow determination process in step S151, vehicle 20 determines to execute the second deletion flow.

[0186] Subsequently, vehicle 20 executes the process in step S152. In step S152, vehicle 20 executes the second deletion flow. If the owner key KO has a protection function enabled, the vehicle 20 determines in step S151 that it will not delete the authentication information AT. Subsequently, the management system 10 terminates the series of processes shown in Figure 15 without executing any further processes.

[0187] <Second Deletion Flow> Figure 16 shows the sequence of processes in the second deletion flow. In vehicle 20, the vehicle management device 26 executes the sequence of processes shown in Figure 16 in step S152 of Figure 15. The sequence of processes shown in Figure 16 is executed by the execution device 27 via the deletion program PC.

[0188] In the series of processes shown in Figure 16, the execution device 27 first executes the process in step S161. In step S161, the execution device 27 checks the contract status between the owner and the SBOD server. At this time, the execution device 27 communicates with the SBOD server, which is the owner device 40, and inquires whether the contract between the SBOD server and the vehicle 20 has been terminated.

[0189] Subsequently, the execution device 27 executes the process in step S162. In step S162, the execution device 27 determines whether or not the contract between the owner and the SBOD server has been terminated.

[0190] The execution device 27 determines that the contract between the owner and the SBOD server has terminated when it confirms through the processing in step S161 that the contract between the owner and the SBOD server has terminated. If the execution device 27 determines that the contract between the owner and the SBOD server has terminated (step S162: YES), it proceeds to step S163. In the processing of step S163, the execution device 27 deletes the authentication information AT for the owner key KO. In this way, the vehicle management device 26 deletes the authentication information AT for the owner key KO when the condition that the contract between the owner and the SBOD server has terminated is met. After that, the execution device 27 terminates the series of processes shown in Figure 16.

[0191] The execution device 27 determines that the contract between the owner and the SBOD server has not terminated when it confirms through the processing in step S161 that the contract between the owner and the SBOD server has not terminated. If the execution device 27 determines that the contract between the owner and the SBOD server has not terminated (step S162: NO), it terminates the series of processes shown in Figure 16.

[0192] <If owner device 40 is the SBOD server (from step S152 onwards)> In the second deletion flow, if the vehicle 20 deletes the authentication information AT for the owner key KO as a result of executing the process in step S163, it sends a deletion completion notification M91 to the management server 70 indicating that the owner key KO has been deleted.

[0193] Subsequently, when the management server 70 receives the completion notification M91, the management server 70 performs the process in step S153. In step S153, the management server 70 stores the history of the deletion of the authentication information AT for the owner key KO. After that, the management server 70 proceeds to step S154.

[0194] In step S154, the management server 70 generates a deletion request D91 requesting the deletion of the owner key information DKO. The management server 70 then sends the deletion request D91 to the owner device 40.

[0195] Subsequently, when the owner device 40 receives the deletion request D91, the owner device 40 performs the process in step S155. In step S155, the owner device 40 deletes the owner key information DKO in accordance with the deletion request D91. Then, the owner device 40 sends a completion notification M92 to the management server 70 indicating that it has completed the deletion of the owner key information DKO in accordance with the deletion request D91.

[0196] Subsequently, when the management server 70 receives the completion notification M92, the management server 70 performs the process in step S156. In step S156, the management server 70 stores the history of the deletion of the owner key information DKO on the owner device 40.

[0197] Subsequently, the management server 70 performs the process in step S157. In step S157, the management server 70 updates the database DB. Specifically, the management server 70 deletes the owner device 40 of the owner key KO, which is the target of this series of processes, from the vehicle data DA in the database DB. With this, the management system 10 completes the series of processes for deleting the owner key KO.

[0198] <Operation of this embodiment> When the vehicle management device 26 deletes an owner key KO, which is set to the SBOD server (a server contracted by the owner) as the owner device 40, it performs a different deletion flow than when the owner device 40 is a portable device.

[0199] <Effects of this embodiment> (1) The vehicle management device 26 can appropriately delete the owner key KO, which has the owner device 40 set to the SBOD server contracted by the owner.

[0200] (2) The SBOD server belongs to the owner based on the contract with the owner. The execution device 27, which is a processing circuit, communicates with the SBOD server in the second deletion flow. The execution device 27 deletes the information related to the owner key KO, provided that it has confirmed through communication with the SBOD server that the contract between the SBOD server and the owner has ended.

[0201] When the owner device 40 is an SBOD server, there is a higher likelihood that users other than the owner will use the vehicle 20 compared to when the owner device 40 is a mobile device. Also, when the owner device 40 is an SBOD server, it is likely that many share keys KS will be generated. Therefore, when deleting an owner key KO when the owner device 40 is an SBOD server, the risk of the owner key KO being deleted without the owner's consent is higher than when the owner device 40 is a mobile device.

[0202] If the owner has terminated their contract with the SBOD server at the time a request for deletion of the owner key KO is made, there is a high probability that the request for deletion of the owner key KO is at the owner's discretion. The vehicle management device 26 deletes the owner key KO when it confirms that the contract between the SBOD server and the owner has terminated. This prevents the vehicle management device 26 from deleting the owner key KO without the owner's consent.

[0203] (3) The user can set a protection function that restricts the deletion of information related to the owner key KO by a specific device. The execution device 27, which is the processing circuit, will not delete information related to the owner key KO if the protection function is set.

[0204] When the protection function is set, the vehicle management device 26 does not delete the owner key KO that designates the SBOD server as the owner device 40. This prevents the vehicle management device 26 from deleting the owner key KO without the owner's consent.

[0205] (4) The information regarding the owner key KO stored in the storage device 28 includes information indicating the type of owner device 40. This allows the vehicle management device 26 to determine the type of owner device 40 based on the information regarding the owner key KO.

[0206] (5) When vehicle 20 deletes the owner key KO that designates the owner device 40 as the SBOD server contracted by the owner, it performs a different flow than when the owner device 40 is a portable device. This allows vehicle 20 to properly delete the owner key KO that designates the owner device 40 as the SBOD server contracted by the owner.

[0207] (6) The vehicle 20 is equipped with a vehicle management device 26. The SBOD server belongs to the owner based on a contract with the owner. In the vehicle management device 26, the execution device 27, which is a processing circuit, communicates with the SBOD server in the second deletion flow. In the vehicle management device 26, the execution device 27 deletes the information related to the owner key KO, provided that it has confirmed through communication with the SBOD server that the contract between the SBOD server and the owner has ended.

[0208] When the owner device 40 is an SBOD server, there is a higher likelihood that users other than the owner will use the vehicle 20 compared to when the owner device 40 is a mobile device. Also, when the owner device 40 is an SBOD server, it is likely that many share keys KS will be generated. Therefore, when deleting an owner key KO when the owner device 40 is an SBOD server, the risk of the owner key KO being deleted without the owner's consent is higher than when the owner device 40 is a mobile device.

[0209] If the owner has terminated their contract with the SBOD server at the time the deletion of the owner key KO is requested, there is a high probability that the request for deletion of the owner key KO is at the owner's discretion. Vehicle 20 deletes the owner key KO when it confirms that the contract between the SBOD server and the owner has terminated. This prevents vehicle 20 from deleting the owner key KO without the owner's consent.

[0210] (7) When the deletion program PC deletes the owner key KO, which is the SBOD server contracted by the owner, as the owner device 40, it performs a different flow than when the owner device 40 is a mobile device. This allows the deletion program PC to properly delete the owner key KO, which is the SBOD server contracted by the owner, as the owner device 40.

[0211] (8) The management system 10 includes a vehicle management device 26. The vehicle management device 26 is installed in a vehicle 20 that can be controlled by a digital key registered for a device 30. The management system 10 manages the digital key. The above deletion method is a deletion method for deleting an owner key KO, which is a digital key registered for an owner device 40, which is a device 30 belonging to the owner of the vehicle 20, in the management system 10. The vehicle management device 26 stores information about the owner key KO. The deletion method includes a step (step S121) in which the vehicle management device 26 determines the type of owner device 40 when an operation is made to the vehicle management device 26 requesting the deletion of the owner key KO in the management system 10. If the deletion method determines that the owner device 40 is a portable device owned by the owner (step S122: YES), the vehicle management device 26 includes a step (step S132) in which it executes a first deletion flow to delete the information about the owner key KO after authentication of the fob key is completed through communication with the fob key of the vehicle 20. The deletion method includes a step (step S152) in which the vehicle management device 26, when it determines that the owner device 40 is a server belonging to the owner and is a server that generates digital keys for said device in response to requests from other devices, executes a second deletion flow which is a different processing flow from the first deletion flow and deletes information related to the owner key KO if certain conditions are met.

[0212] The deletion method follows a different flow when deleting the owner key KO, which is set to the SBOD server (the server contracted by the owner) as owner device 40, compared to when owner device 40 is a mobile device. This ensures that the deletion method properly deletes the owner key KO, which is set to the SBOD server (the server contracted by the owner) as owner device 40.

[0213] (Other embodiments) The above embodiment can be implemented with the following modifications. The above embodiment and the following modifications can be combined with each other to the extent that they do not contradict each other technically.

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

[0215] • The matters concerning the digital key in the above embodiment 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.

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

[0217] Device 30 is not limited to a smartphone; it may also be a smartwatch. Furthermore, the friend device 51 may be included in a designated server. The share device 50 has the function of receiving the share key KS, as in the embodiment described above. A device 30 that has the function of receiving a digital key, like the share device 50, is sometimes called a receiver device.

[0218] In the above embodiment, 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 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.

[0219] The device server 60 does not need to be provided for each type of device 30. It is sufficient that multiple devices 30 and the management server 70 can communicate wirelessly. The device server 60 may be omitted. It is sufficient that multiple devices 30 and the management server 70 can communicate wirelessly directly.

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

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

[0222] <Information about various types of information> The authentication information AT is not limited to the examples of the above embodiments, as long as it is information used to authenticate a digital key when using the digital key. For example, the authentication information AT may be a common key shared between the vehicle management device 26 and the device 30. Alternatively, the authentication information AT may be a common secret key.

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

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

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

[0226] 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).

[0227] The series of processes for registering the owner key KO is not limited to the examples of the above embodiment. 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.

[0228] The series of processes for registering the friend key KF is not limited to the examples of the above embodiment. 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.

[0229] The series of processes for registering a non-friend key KN is not limited to the example of the embodiment 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.

[0230] 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). Non-friend device 52 may send a request to register a new non-friend key KN. In other words, share device 50 may send a request to register a new non-friend key KN, regardless of whether it is friend device 51 or non-friend device 52. In this case, management system 10 can register the new non-friend key KN by the series of processes shown in Figure 7.

[0231] In the above embodiment, when the friend device 51 deletes a non-friend key KN, it sends a deletion reservation request D41 to the management server 70, requesting that the non-friend key KN be deleted when the specified condition RC is met. On the other hand, the friend device 51 may also send a request to the management server 70 to delete the non-friend key KN regardless of the specified condition RC. Furthermore, the management server 70 may proceed with processing from step S62 onward based not only on the friend device 51's request to delete the non-friend key KN, but also on the owner device 40's request.

[0232] In the above embodiment, when the owner device 40 deletes the friend key KF, it sends a deletion reservation request D61 to the management server 70, requesting that the friend key KF be deleted when the specified condition RC is met. On the other hand, the owner device 40 may also send a request to the management server 70 to delete the friend key KF regardless of the specified condition RC.

[0233] In the above embodiment, the management server 70 receives the deletion reservation request D41, but the vehicle 20 may also receive the deletion reservation request D41. In this case, the vehicle 20 may determine whether the specified condition RC is met, and if the specified condition RC is met, it may delete the authentication information AT. After that, the vehicle 20 may send a notification to the management server 70 indicating that it has deleted the authentication information AT based on the deletion reservation request D41. After that, the management server 70 may update the database DB and send a deletion request D42 to the non-friendly device 52.

[0234] In the above embodiment, the management server 70 receives the deletion reservation request D61, but the vehicle 20 may also receive the deletion reservation request D61. In this case, the vehicle 20 may determine whether the specified condition RC is met, and if the specified condition RC is met, it may delete the authentication information AT. After that, the vehicle 20 may send a notification to the management server 70 indicating that it has deleted the authentication information AT based on the deletion reservation request D61. After that, the management server 70 may update the database DB and send a deletion request D62 to the friend device 51.

[0235] As shown in Figure 9, when deleting a non-friendly device 52 due to an operation of the non-friendly device 52, a request to delete the non-friendly key KN may be sent to the management server 70 before the completion notification M51 sent to the management server 70. In this case, similar to the sequence of events shown in Figure 8, when the management server 70 receives the request, the management server 70 may send a request to delete the non-friendly key information DKN to the non-friendly device 52.

[0236] As shown in Figure 11, when deleting the friend device 51 due to an operation of the friend device 51, a request to delete the friend key KF may be sent to the management server 70 before the completion notification M71 sent to the management server 70. In this case, similar to the sequence of events shown in Figure 10, when the management server 70 receives the request, the management server 70 may send a request to the friend device 51 to delete the friend key information DKF.

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

[0238] The owner device 40 and the vehicle 20 may request the deletion of the non-friend key KN. Alternatively, for example, the management server 70 may generate a request to delete the non-friend key KN when certain conditions are met.

[0239] Vehicle 20 may request the deletion of Friend Key KF. Alternatively, for example, the management server 70 may generate a request to delete Friend Key KF when certain conditions are met. • In management system 10, it is not necessary to enable a protection function for the owner key KO.

[0240] In the management system 10 described above, the vehicle management device 26 executes the second deletion flow if the owner device 40 is an SBOD server. In the management system 10, the user may be able to choose whether to execute the first deletion flow or the second deletion flow when the owner device 40 is an SBOD server. For example, the vehicle management device 26 executes the first deletion flow by default when the owner device 40 is an SBOD server, but the setting may be changed to execute the second deletion flow by operation of a specific device.

[0241] In the above embodiment, the authentication information AT stored by the vehicle management device 26 includes information indicating the type of owner device 40. The authentication information AT does not necessarily include information indicating the type of owner device 40. In the process of step S121 in Figure 12, the vehicle management device 26 may, for example, communicate with the owner device 40 and the management server 70, and query the type of owner device 40.

[0242] In the second deletion flow shown in Figure 16, the vehicle management device 26 deletes the authentication information AT for the owner key KO, provided that the contract between the owner and the SBOD server has been terminated. The manner in which the vehicle management device 26 executes the second deletion flow is not limited to the above embodiment.

[0243] Figure 17 shows the sequence of processes in the second deletion flow executed by the vehicle management device 26 in the management system 10 of the first modification example. In the management system 10 of the first modification example, the vehicle management device 26 executes the sequence of processes shown in Figure 17 instead of the sequence of processes shown in Figure 16 in step S152 of Figure 15. The sequence of processes shown in Figure 17 is executed by the execution device 27 via the deletion program PC.

[0244] In the series of processes shown in Figure 17, the execution device 27 first executes the process in step S171. In step S171, the execution device 27 performs identity verification processing. Identity verification processing is the process of confirming whether the person who performed the deletion request operation in Figure 15 is the owner himself.

[0245] The execution device 27 performs biometric authentication, such as fingerprinting, during the identity verification process. When biometric authentication is completed for the owner, the execution device 27 confirms that the person who made the deletion request is the owner himself. On the other hand, if biometric authentication is not completed for the owner within a certain period of time, the execution device 27 confirms that the person who made the deletion request is not the owner himself.

[0246] In the identity verification process, the execution device 27 sends a message with a link to the owner device 40, for example, via SMS. SMS stands for Short Message Service. The execution device 27 then verifies that the person who made the deletion request is the owner themselves if the link in the message is clicked. On the other hand, the execution device 27 verifies that the person who made the deletion request is not the owner themselves if the link in the message is not clicked within a certain period of time.

[0247] Subsequently, the execution device 27 executes the process in step S172. In step S172, the execution device 27 determines whether or not the person who performed the deletion request operation was the owner himself.

[0248] The execution device 27 determines that the deletion request was made by the owner himself when it confirms through the processing in step S171 that the owner himself made the deletion request. If the execution device 27 determines that the owner himself made the deletion request (step S172: YES), it proceeds to step S173. In the processing of step S173, the execution device 27 deletes the authentication information AT for the owner key KO. In this way, the vehicle management device 26 deletes the authentication information AT for the owner key KO on the condition that it has confirmed that the owner himself made the operation requesting the deletion of the owner key KO. After that, the execution device 27 terminates the series of processes shown in Figure 17.

[0249] If the execution device 27 confirms through the process in step S171 that the person who made the deletion request was not the owner, it determines that the person who made the deletion request was not the owner. If the execution device 27 determines that the person who made the deletion request was not the owner (step S172: NO), it terminates the series of processes shown in Figure 17.

[0250] In this case, the execution device 27, which is the processing circuit, performs a check in the second deletion flow to confirm whether the person requesting the deletion of the owner key KO is the owner himself. The execution device 27 deletes the information related to the owner key KO, provided that it has confirmed that the person requesting the deletion of the owner key KO is the owner himself.

[0251] The vehicle management device 26 verifies whether the request for deletion of the owner key KO was made by the owner themselves when a request for deletion of the owner key KO is received. This allows the vehicle management device 26 to prevent the deletion of the owner key KO without the owner's consent.

[0252] In this case, the vehicle 20 is equipped with a vehicle management device 26. In the vehicle management device 26, the execution device 27, which is a processing circuit, performs a check in the second deletion flow to confirm whether the person requesting the deletion of the owner key KO is the owner himself. The execution device 27 deletes the information related to the owner key KO, provided that it has confirmed that the person requesting the deletion of the owner key KO is the owner himself.

[0253] When a request is made to delete the owner key KO, vehicle 20 verifies whether the request is made by the owner themselves. This prevents vehicle 20 from deleting the owner key KO without the owner's consent.

[0254] Figure 18 shows the sequence of processes in the second deletion flow executed by the vehicle management device 26 in the management system 10 of the second modification example. In the management system 10 of the second modification example, the vehicle management device 26 executes the sequence of processes shown in Figure 18 instead of the sequence of processes shown in Figure 16 in step S152 of Figure 15. The sequence of processes shown in Figure 18 is executed by the execution device 27 via the deletion program PC.

[0255] In the series of processes shown in Figure 18, the execution device 27 first executes the process in step S181. In step S181, the execution device 27 authenticates multiple fob keys.

[0256] At this time, the execution device 27 communicates with the fob key, for example, via NFC communication. The execution device 27 may also communicate with the fob key using RFID, for example. The execution device 27 completes the authentication of the fob key when it confirms through communication with the fob key that the communicated fob key is a fob key that can legitimately control the vehicle 20.

[0257] In step S181, the execution device 27 performs fob key authentication in this manner for multiple fob keys. Subsequently, the execution device 27 executes the process in step S182. In step S182, the execution device 27 determines whether or not the authentication of the multiple fob keys has been completed through the process in step S181.

[0258] In step S182, if the execution device 27 determines that authentication of multiple fob keys has been completed through the processing in step S181 (step S182: YES), it proceeds to step S183. In the processing of step S183, the execution device 27 deletes the authentication information AT for the owner key KO. In this way, the vehicle management device 26 deletes the authentication information AT for the owner key KO on the condition that authentication of multiple fob keys has been completed. After that, the execution device 27 terminates the series of processes shown in Figure 17.

[0259] In the first deletion flow shown in Figure 14, the execution device 27 deletes the authentication information AT for the owner key KO when authentication for one fob key is completed. In other words, in the second deletion flow shown in Figure 18, the condition for deleting the authentication information AT for the owner key KO is that authentication for more fob keys than required in the first deletion flow has been completed.

[0260] If the execution device 27 determines through the processing in step S181 that authentication of multiple fob keys has not been completed (step S182: NO), it terminates the series of processes shown in Figure 18.

[0261] In this case, the execution device 27, which is the processing circuit, performs communication with multiple fob keys in the second deletion flow. The execution device 27 deletes the information related to the owner key KO, provided that authentication has been completed for more fob keys than the number required in the first deletion flow as a result of the communication.

[0262] A user who possesses many fob keys is highly likely to be the owner of the vehicle 20. In the second deletion flow, the vehicle management device 26 deletes the owner key KO when authentication is completed for a larger number of fob keys than in the first deletion flow. This allows the vehicle management device 26 to suppress deletion of the owner key KO that is not performed in accordance with the owner's will.

[0263] In this case, the vehicle 20 includes a vehicle management device 26. In the vehicle management device 26, an execution device 27, which is a processing circuit, performs communication with a plurality of fob keys in the second deletion flow. The execution device 27 executes deletion of information related to the owner key KO on the condition that authentication is completed for more fob keys than the number required in the first deletion flow, as a result of the communication.

[0264] A user who possesses many fob keys is highly likely to be the owner of the vehicle 20. In the second deletion flow, the vehicle 20 deletes the owner key KO when authentication is completed for a larger number of fob keys than in the first deletion flow. This allows the vehicle 20 to suppress deletion of the owner key KO that is not performed in accordance with the owner's will.

[0265] In the first deletion flow shown in FIG. 14, it is also conceivable that the execution device 27 deletes the authentication information AT for the owner key KO when authentication of a plurality of fob keys is completed. In this case, in the management system 10 according to the second modification, the vehicle management device 26 deletes the authentication information AT for the owner key KO on condition that authentication is completed for a larger number of fob keys than the number of fob keys required in the first deletion flow.

[0266] [Supplementary Note] The technical ideas that can be grasped from the above embodiment and modifications are described below. [Supplementary Note 1] A vehicle management device mounted in a vehicle controllable by said digital key in a management system that manages a digital key registered for a device, comprising: a processing circuit; and a storage device, wherein said storage device stores information relating to an owner key that is said digital key registered for an owner device that is said device belonging to an owner of said vehicle, and when an operation requesting deletion of said owner key in said management system is performed on said vehicle management device, said processing circuit: determines a type of said owner device; executes a first deletion flow of deleting information relating to said owner key after authentication of a fob key through communication with the fob key of said vehicle is completed, when it is determined that said owner device is a portable device owned by said owner; and executes a second deletion flow that is a deletion flow different from said first deletion flow and deletes information relating to said owner key when a specific condition is satisfied, when it is determined that said owner device is a server belonging to said owner and said server generates said digital key for another device in response to a request from said device.

[0267] [Supplementary Note 2] The vehicle management device according to Supplementary Note 1, wherein said server belongs to said owner based on a contract with said owner, and in said second deletion flow, said processing circuit: communicates with said server; and deletes information relating to said owner key on condition that it is confirmed through communication with said server that the contract between said server and said owner has been terminated.

[0268] [Supplementary Note 3] The vehicle management device according to Supplementary Note 1 or 2, wherein in said second deletion flow, said processing circuit: confirms for said owner whether or not the operation requesting deletion of said owner key is performed by the owner himself / herself; and deletes information relating to said owner key on condition that it is confirmed that the operation requesting deletion of said owner key is performed by the owner himself / herself.

[0269] [Note 4] The vehicle management device according to any one of Notes 1 to 3, wherein the processing circuit communicates with a plurality of fob keys in the second deletion flow and deletes the owner key information on the condition that, as a result of the communication, authentication is completed for more fob keys than the number required in the first deletion flow.

[0270] [Note 5] A vehicle management device according to any one of Notes 1 to 4, wherein a protection function can be set by a specific device to restrict the deletion of information related to the owner key, and the processing circuit does not delete information related to the owner key when the protection function is set.

[0271] [Note 6] The vehicle management device according to any one of Notes 1 to 5, wherein the information relating to the owner key stored in the storage device includes information indicating the type of the owner device.

[0272] [Note 7] A vehicle equipped with a vehicle management device as described in any one of Notes 1 to 6. [Explanation of symbols]

[0273] 10…Management System 20... Vehicles 26... Vehicle management system 27… Execution device 28…Storage device 29…Display section 30…Device 36…Execution device 37…Storage device 40… Owner devices 50… Shared devices 51... Friend Device 52... Non-Friendly Devices 60…Device Server 70... Management Server AT... Authentication information DK...Key Information DKO... Owner Key Information DKS... Share Key Information KF...Friend Key KN... Non-Friend Key KO... Owner Key KS... Share Key PC...delete program

Claims

1. In a management system for managing digital keys registered for a device, the vehicle management device is installed in a vehicle that can be controlled by the said digital key, It comprises a processing circuit and a memory device. The storage device stores information regarding the owner key, which is the digital key registered for the owner device, which is the device belonging to the owner of the vehicle. The aforementioned processing circuit is When an operation is performed on the vehicle management device to request the deletion of the owner key in the management system, the type of the owner device is determined, When the owner device is determined to be a portable device owned by the owner, after authentication of the fob key is completed through communication with the vehicle's fob key, a first deletion flow is executed to delete the information related to the owner key. If it is determined that the owner device is a server belonging to the owner and is the server that generates the digital key for that device in response to a request from another device, then a second deletion flow is executed, which is a different deletion flow from the first deletion flow and deletes the information related to the owner key when certain conditions are met. Vehicle management system.

2. The aforementioned server belongs to the aforementioned owner based on the agreement with the aforementioned owner, In the second deletion flow, the processing circuit To communicate with the aforementioned server, On the condition that communication with the server confirms that the contract between the server and the owner has ended, the following actions are taken: delete the information related to the owner key. The vehicle management device according to claim 1.

3. In the second deletion flow, the processing circuit is configured as follows: To verify whether the person performing the operation requesting the deletion of the owner key is the owner himself, The information related to the owner key will be deleted, provided that it is confirmed that the person who requested the deletion of the owner key was the owner himself. The vehicle management device according to claim 1.

4. In the second deletion flow, the processing circuit is configured as follows: Communicating with multiple of the aforementioned fob keys, Based on the results of the communication, if authentication is completed for more fob keys than the number required in the first deletion flow, the information regarding the owner key is deleted. The vehicle management device according to claim 1.

5. A protection function can be configured using a specific device to restrict the deletion of information related to the owner key. The processing circuit does not delete the information related to the owner key if the protection function is set. A vehicle management device according to any one of claims 1 to 4.

6. The information regarding the owner key stored in the storage device includes information indicating the type of the owner device. A vehicle management device according to any one of claims 1 to 4.

7. A vehicle equipped with a vehicle management device according to any one of claims 1 to 4.

8. In a management system for managing digital keys registered for a device, the deletion program is executed by the processing circuit of a vehicle management device installed in a vehicle controllable by the said digital key. The vehicle management device stores information regarding the owner key, which is the digital key registered for the owner device, which is the device belonging to the owner of the vehicle. When an operation is performed on the vehicle management device to request the deletion of the owner key in the management system, the type of the owner device is determined, When the owner device is determined to be a portable device owned by the owner, after authentication of the fob key is completed through communication with the vehicle's fob key, a first deletion flow is executed to delete the information related to the owner key. If the system determines that the owner device is a server belonging to the owner and that it generates the digital key for that device in response to a request from another device, the system will instruct the processing circuit to execute a second deletion flow, which is a different processing flow from the first deletion flow and deletes the information related to the owner key when certain conditions are met. Deletion program.

9. A vehicle management device installed in a vehicle that can be controlled by a digital key registered for a device, and a management system for managing said digital keys, wherein the deletion method is for deleting an owner key, which is a digital key registered for an owner device, which is a device belonging to the owner of the vehicle. The vehicle management device stores information related to the owner key, When an operation is performed on the vehicle management device to request the deletion of the owner key in the management system, the vehicle management device performs the step of determining the type of the owner device, When the owner device is determined to be a portable device owned by the owner, the vehicle management device performs a first deletion flow to delete the information related to the owner key after authentication of the fob key is completed through communication with the vehicle's fob key. When the vehicle management device determines that the owner device is a server belonging to the owner and is the server that generates the digital key for that device in response to a request from another device, the vehicle management device executes a second deletion flow which is a different processing flow from the first deletion flow and deletes the information related to the owner key when certain conditions are met, including How to delete.

Images