Management server, deletion management method, and program

Abstract

This system provides a management server that can prevent users of registered digital keys from being unable to use their vehicles. [Solution] The management server 70 manages multiple digital keys for the vehicle 20. When a predetermined condition is met, the management server 70 deletes the target digital key and the digital keys registered based on the target digital key from among the multiple digital keys, and when the predetermined condition is met, it registers a new digital key for the vehicle 20 on the device where the digital key registered based on the deleted target digital key was registered.

Description

[Technical Field]

[0001] The present disclosure relates to a management server, a deletion management method, and a program. [Background Art]

[0002] Patent Document 1 describes a digital key management server. The management server manages a plurality of digital keys. The plurality of digital keys include a digital key and a digital key registered based on said digital key. [Prior Art Document] [Patent Document]

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

[0004] When a management server as described in Patent Document 1 deletes a target digital key when a prescribed condition is satisfied, the management server may cause deletion of a digital key registered based on the target digital key.

[0005] In this case, the deletion of the digital key registered based on the target digital key results in the user of the digital key registered based on the target digital key being unable to use the vehicle. [Means for Solving the Problem]

[0006] The management server that solves the above problem is a management server that manages multiple digital keys for a vehicle, and when predetermined conditions are met, it deletes the target digital key and the digital key registered based on the target digital key from among the multiple digital keys, and when the predetermined conditions are met, it registers a new digital key for the vehicle on the device where the digital key registered based on the deleted target digital key was registered.

[0007] A deletion management method that solves the above problem is a deletion management method performed by a management server including a computer for managing multiple digital keys for a vehicle, which includes: deleting a target digital key and a digital key registered based on the target digital key from among the multiple digital keys when predetermined conditions are met; and registering a new digital key for the vehicle on the device where the digital key registered based on the deleted target digital key was registered when the predetermined conditions are met.

[0008] The program that solves the above problem is a program to be executed by a computer included in a management server that manages multiple digital keys for a vehicle, and which, when a predetermined condition is met on the computer, deletes the target digital key and the digital key registered based on the target digital key, and when the predetermined condition is met, registers a new digital key for the vehicle on the device where the digital key registered based on the deleted target digital key was registered. [Effects of the Invention]

[0009] According to the above configuration, even if a digital key registered based on the target digital key is deleted, a new digital key will be registered on the device where the target digital key was registered. Therefore, the above management server, deletion management method, and program can prevent the user of the digital key registered based on the target digital key from being unable to use the vehicle. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is a schematic diagram showing a management system of one embodiment. [Figure 2] Figure 2 is a schematic diagram showing the owner key information of the same embodiment. [Figure 3] Figure 3 is a schematic diagram showing the share key information of the embodiment. [Figure 4] Figure 4 is a schematic diagram showing the data in the database of the same embodiment. [Figure 5] Figure 5 is an explanatory diagram showing a series of processes performed by the management system when the owner key is registered in this embodiment. [Figure 6] Figure 6 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in this embodiment. [Figure 7] Figure 7 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in this embodiment. [Figure 8] Figure 8 is an explanatory diagram illustrating the series of deletion management processes performed by the management system of this embodiment. [Figure 9] Figure 9 is a flowchart showing the detailed process performed by the management server in this embodiment to determine whether or not an alternative registration has been made. [Figure 10] Figure 10 is an explanatory diagram showing a series of processes performed by the management system when there is an alternative registration in the same embodiment. [Figure 11] Figure 11 is an explanatory diagram showing a series of processes performed by the management system when there is no alternative registration in this embodiment. [Figure 12]FIG. 12 is a state diagram for explaining data in a state where the second digital key of the embodiment has been deleted. [Figure 13] FIG. 13 is a state diagram for explaining data in a state where the third digital key of the embodiment has been deleted and a new digital key has been registered in the third device. [Figure 14] FIG. 14 is a state diagram for explaining data when there is no alternative registration in the embodiment. MODE FOR CARRYING OUT THE INVENTION

[0011] <One Embodiment> Hereinafter, a management system 10 including a management server 70 according to one embodiment will be described with reference to the drawings.

[0012] <Outline of Management System> As shown in FIG. 1, the management system 10 manages a plurality of digital keys that can be used for a vehicle 20. For digital keys, there exists a standard from the Car Connectivity Consortium (CCC). Matters concerning the digital key of the present embodiment are assumed to conform to CCC, but the present invention can also be applied to standards and systems other than CCC. The management system 10 includes a vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

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

[0014] The communication module 21 communicates with the management server 70 via a wireless communication line. The HMI 22 includes an input device and a presentation device. The input device receives an operation by a user of the vehicle 20, and inputs a signal indicating the operation to the vehicle 20. The presentation device presents information to the user via images, audio, and the like. The presentation device is, for example, a monitor and a speaker.

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

[0016] The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages a plurality of digital keys for the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 includes an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. When executed by the execution device 27, the vehicle program PV causes the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating a digital key to enable control of the vehicle 20 by the digital key when the digital key is used. The authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU, that is, a processing circuit. The execution device 27 executes the vehicle program PV to perform processing related to storage and deletion of the authentication information AT.

[0017] When the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables the vehicle 20 to be controlled by that digital key. For example, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables unlocking of the vehicle 20. Further, for example, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 enables starting of the vehicle 20.

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

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

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

[0021] The storage device 37 stores the device program PD and the key information DK. The device program PD is executed by the execution device 36, 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.

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

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

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

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

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

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

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

[0029] 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 described later. Non-friend key KN is a share key KS registered based on a registration request D31 from friend device 51, as described later. In other words, non-friend key KN is a share key KS registered based on a registration request from share device 50, which is a device 30 different from owner device 40.

[0030] Furthermore, when a digital key is registered, it means that the digital key is usable. In other words, when a digital key is registered, the vehicle 20 stores the authentication information AT, and the device 30 stores the key information DK.

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

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

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

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

[0035] 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 of device 30 communicates with is different from the device server 60 that a second type of 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.

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

[0037] <Management Server> The management server 70 manages multiple digital keys. The management server 70 can communicate with the vehicle 20 and multiple devices 30. The management server 70 comprises an execution unit 71, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 can also communicate wirelessly with the communication module 21 of the vehicle 20.

[0038] The execution device 71 and the storage device 72 constitute the computer. The execution device 71 is the CPU, or processing circuit. The storage device 72 is memory. The storage device 72 stores the server program PS and the database DB. The server program PS causes the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB by executing it. The server program PS also causes the execution device 71 to delete digital keys by executing it.

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

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

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

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

[0043] This section describes a state in which a digital key is registered for 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 for each of Devices 1 30A to Device 7 30G are referred to as Digital Key 1 DK1 to Digital Key 7 DK7.

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

[0045] 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 Share Devices 50. That is, the second digital key DK2 to the seventh digital key DK7 are all Share Key KS.

[0046] 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 third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are Non-Friend Devices 52.

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

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

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

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

[0051] 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 DK6 is registered based on the fifth digital key DK5.

[0052] In the 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 as a result of a registration request from the 5th device 30E. In other words, the 7th digital key DK7 is registered based on the 5th digital key DK5.

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

[0054] The management server 70 manages and restricts the functions that use each digital key according to the relationships between multiple digital keys. For example, the management server 70 restricts the function of deleting a digital key to deleting other digital keys. The management server 70 determines whether to allow a request to perform each function received from device 30, based on the relationship between the digital key registered in the requesting device 30 and the digital key registered in the receiving device 30.

[0055] The management server 70 restricts and manages functions according to the relationships between multiple digital keys, allowing device 30 to perform a reserved deletion of the digital keys involved in registration using the reserved deletion request D41 described later. The reserved deletion request D41 indicates a request to delete the target digital key when the specified condition RC is met.

[0056] For example, the first device 30A can delete reservations for the second digital key DK2 to the seventh digital key DK7. On the other hand, the first device 30A cannot delete the reservation for the first digital key DK1.

[0057] The second device 30B can delete reservations for the third digital key DK3 and the fourth digital key DK4. On the other hand, the second device 30B cannot delete reservations for the first digital key DK1, the second digital key DK2, and the fifth digital key DK5 to the seventh digital key DK7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0104] <Deletion Management> Next, the series of processes for deletion management in the management system 10 will be described. Deletion management includes deleting the target digital key and the digital keys registered based on the target digital key, and registering a new digital key DKX.

[0105] In this embodiment, the target digital key is the second digital key DK2 of the friend key KF. Therefore, a series of processes related to deletion management for deleting the second digital key DK2 will be described.

[0106] The following describes the sequence of events from the state in which the second digital key DK2 is registered to the state in which the second digital key DK2 is not registered. In the following description, 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.

[0107] As shown in Figure 8, when an operation is performed in the first device 30A to request the deletion of the second digital key DK2, the first device 30A first performs the process in step S61. In step S61, a reserved deletion request D41 for the second digital key DK2 is generated. The reserved deletion request D41 is a request to delete the second digital key DK2 when the specified condition RC is met. In other words, the target digital key is the second digital key DK2.

[0108] The reservation deletion request D41 includes a signal requesting the deletion of the second digital key DK2, digital key identification information ST3 indicating the second digital key DK2, and information indicating the predetermined condition RC. The predetermined condition RC is the condition necessary to delete the target digital key after receiving the reservation deletion request D41. The predetermined condition RC is that a digital key different from the target digital key, the second digital key DK2, among multiple digital keys for the vehicle 20 is authenticated by the vehicle 20. The first device 30A then sends the reservation deletion request D41 for the second digital key DK2 to the management server 70.

[0109] Subsequently, when the management server 70 receives the reservation deletion request D41 for the second digital key DK2, it performs the process in step S62. In step S62, the management server 70 generates a deletion notification M41 indicating that deletion is in progress according to the reservation deletion request D41.

[0110] The management server 70 then sends a deletion notification M41 to the second device 30B, the third device 30C, and the fourth device 30D. The third device 30C and the fourth device 30D are non-friendly devices 52 to which the non-friendly key KN, registered based on the registration request from the second device 30B, is registered. Note that the fourth device 30D is not shown in Figure 8. Subsequently, the management server 70 sends a reservation deletion request D41 to the vehicle 20.

[0111] Subsequently, when vehicle 20 receives reservation deletion request D41, vehicle 20 performs the process in step S63. In step S63, vehicle 20 repeatedly performs fade-out checks until it determines that the specified condition RC has been met. In the fade-out check, vehicle 20 repeatedly determines whether or not the specified condition RC has been met. Specifically, vehicle 20 determines that the specified condition RC has been met when it authenticates a digital key different from the target digital key among multiple digital keys for vehicle 20. When vehicle 20 determines that the specified condition RC has been met, it proceeds to step S64.

[0112] In step S64, the vehicle 20 generates a confirmation notice M42 indicating that the specified condition RC has been met. Subsequently, the vehicle 20 sends the confirmation notice M42 to the management server 70. Subsequently, when the management server 70 receives the completion notification M42, the management server 70 performs the process in step S65. In step S65, the management server 70 determines whether or not there is an alternative registration.

[0113] <Determination of whether alternative registration is available> This section describes the details of the determination of whether or not an alternative registration is required by the management server 70. In step S65, the execution device 71 repeatedly performs a series of processes for determining whether or not an alternative registration exists, for a predetermined amount of time, at a predetermined interval.

[0114] As shown in Figure 9, when the execution device 71 starts a series of processes to determine whether or not an alternative registration has been made, the execution device 71 first performs the process in step S71. In step S71, the execution device 71 determines whether or not a new registration request D51 has been received. Note that in the process of step S65, a registration request D51 that has already been received is determined not to be a new registration request D51.

[0115] If the management server 70 has not received a new registration request D51 (S71: NO), the execution device 71 terminates this series of processes. On the other hand, if the management server 70 has received a new registration request D51 (S71: YES), the execution device 71 proceeds to step S72.

[0116] In step S72, the execution device 71 determines whether the device 30 that sent the new registration request D51 is the device 30 on which the digital key registered based on the digital key to be deleted is registered. Specifically, it determines whether the device 30 that sent the new registration request D51 is the third device 30C or the fourth device 30D. The third device 30C and the fourth device 30D are devices 30 that were registered based on the second digital key DK2.

[0117] If the device 30 that sends the new registration request D51 is the same device 30 that has a digital key registered based on the digital key to be deleted (S72: YES), the execution unit 71 proceeds to step S73.

[0118] In step S73, the execution device 71 accepts the new registration request D51 received in step S71. The execution device 71 then proceeds to step S74. In step S74, the execution device 71 determines that there is an alternative registration. Alternative registration is the registration of a new digital key DKX in place of the registered digital key. After that, the execution device 71 terminates this series of processes.

[0119] On the other hand, if the device 30 that sends the new registration request D51 is not the device 30 on which the digital key registered based on the digital key to be deleted is registered (S72:NO), the execution device 71 proceeds to step S75.

[0120] In step S75, the execution device 71 rejects the new registration request D51 received in step S71. Subsequently, the execution device 71 determines that there is no alternative registration, rather than determining that there is an alternative registration. Then, the execution device 71 terminates this series of processes.

[0121] Then, if the execution device 71 repeatedly executes the series of processes for a specified time and the process in step S74 is performed at least once, the execution device 71 determines that there is an alternative registration. On the other hand, if the execution device 71 repeatedly executes the series of processes for a specified time and the process in step S74 is not performed even once, the execution device 71 determines that there is no alternative registration. As a result, the execution device 71 terminates the process in step S65.

[0122] <Deletion management when alternative registrations exist> If the management server 70 determines that there is an alternative registration, the management system 10 performs deletion management in the case of an alternative registration. In the following explanation, we will use the case where a new registration request D51 is received from the third device 30C as an example.

[0123] In deletion management when alternative registrations exist, the management server 70 executes the deletion of the target digital key when the specified condition RC is met. Specifically, the management server 70 generates and sends a request to delete the second digital key DK2.

[0124] In deletion management when alternative registrations exist, the management server 70 deletes the digital key registered to the device 30 that registers a new digital key DKX, along with the target digital key. Specifically, the management server 70 generates and sends a request to delete the third digital key DK3 without generating a request to delete the fourth digital key DK4.

[0125] In deletion management when an alternative registration exists, the management server 70, when the specified condition RC is met, executes a procedure to register a new digital key DKX on the device 30 where the digital key registered based on the target digital key to be deleted was registered. Specifically, the management server 70 sends a request to the third device 30C to register a new digital key DKX.

[0126] In other words, in the case of deletion management when there is an alternative registration, the management server 70 causes the third device 30C, which made a new registration request D51, to register the new digital key DKX. On the other hand, the management server 70 does not cause the fourth device 30D, which did not make a new registration request D51, to register the new digital key DKX.

[0127] The following section details the deletion management process when alternative registrations exist. As shown in Figure 10, if there is an alternative registration, the management server 70 first performs the process in step S81. In step S81, the management server 70 generates a deletion request D61. The deletion request D61 is a request to delete the authentication information AT used to authenticate the target digital key. Specifically, the deletion request D61 is a request to delete the authentication information AT of the second digital key DK2. After that, the management server 70 sends the deletion request D61 to the vehicle 20.

[0128] When vehicle 20 receives deletion request D61, vehicle 20 performs the process in step S82. In step S82, vehicle 20 deletes the authentication information AT of the second digital key DK2 in accordance with deletion request D61. After that, vehicle 20 sends completion notification M61 to management server 70. Completion notification M61 is a notification indicating that the deletion of the authentication information AT of the second digital key DK2 in accordance with deletion request D61 has been completed.

[0129] When the management server 70 receives the completion notification M61, the management server 70 performs the process in step S83. In step S83, the management server 70 generates deletion requests D62 and D63.

[0130] Deletion request D62 is a request to delete the key information DK that indicates the target digital key. Specifically, deletion request D62 is a request to delete the key information DK that indicates the second digital key DK2.

[0131] Deletion request D63 is a request to delete key information DK, which indicates a digital key registered with the device 30 that sent registration request D51. Specifically, deletion request D63 is a request to delete key information DK, which indicates a third digital key DK3.

[0132] Subsequently, the management server 70 sends the deletion request D62 to the device 30 that stores the key information DK indicating the target digital key. Specifically, the management server 70 sends the deletion request D62 to the second device 30B.

[0133] When the second device 30B receives the deletion request D62, the second device 30B performs the process in step S84. In step S84, the second device 30B deletes the friend key information DKF indicating the second digital key DK2 in accordance with the deletion request D62.

[0134] After the management server 70 sends deletion request D62 to the second device 30B, the management server 70 sends deletion request D63 to the device 30 that sent the registration request D51. Specifically, the management server 70 sends deletion request D63 to the third device 30C.

[0135] When the third device 30C receives the deletion request D63, the third device 30C performs the process in step S85. In step S85, the third device 30C deletes the non-friend key information DKN that indicates the third digital key DK3 in accordance with the deletion request D63.

[0136] After the management server 70 sends the deletion request D63, the management server 70 performs the process in step S86. In step S86, the management server 70 generates a registration request D64. The registration request D64 is a request to store key information DK which indicates a new digital key DKX that will be registered in place of the third digital key DK3 indicated by the key information DK to be deleted by the deletion request D63.

[0137] Furthermore, when the management server 70 generates registration request D64, it generates key information DK indicating a new digital key DKX. The share key structure information STS of the key information DK indicating the new digital key DKX is the same share key structure information STS included in the share key information DKS indicating the second digital key DK2. The authentication package ATP of the key information DK indicating the new digital key DKX is the same authentication package ATP included in the share key information DKS indicating the third digital key DK3.

[0138] When the third device 30C receives the registration request D64, the third device 30C performs the process in step S87. In step S87, the third device 30C stores key information DK indicating a new digital key DKX in accordance with the registration request D64.

[0139] After the management server 70 sends the registration request D64, the management server 70 performs the process in step S88. In step S88, the management server 70 updates the database DB. Specifically, the management server 70 updates the data DA to make the relationship between the new digital key DKX and the other digital keys the same as the relationship between the target digital key, the second digital key DK2, and the other digital keys.

[0140] Specifically, the data DA will be updated so that the relationship between the new digital key DKX and the fourth digital key DK4 is the same as the relationship between the second digital key DK2 and the fourth digital key DK4.

[0141] Furthermore, the management server 70 updates the data DA so that the permissions of the new digital key DKX are the same as those of the second digital key DK2. After that, the management system 10 completes the series of processes for deletion management in the case of alternative registrations.

[0142] <Deletion management when no alternative registration is available> If the management server 70 determines that there are no alternative registrations, the management system 10 performs deletion management for cases where there are no alternative registrations.

[0143] In the case of deletion management when no alternative registration is available, the management server 70 executes the deletion of the target digital key and all digital keys registered based on the target digital key when the specified condition RC is met.

[0144] As shown in Figure 11, if there is no alternative registration, the management server 70 first performs the process in step S91. In step S91, the management server 70 generates a deletion request D71. The deletion request D71 is a request to delete the authentication information AT for authenticating the target digital key and the authentication information AT for authenticating all digital keys registered based on the target digital key.

[0145] Specifically, deletion request D71 is a request to delete the authentication information AT used to authenticate the second digital key DK2, the authentication information AT used to authenticate the third digital key DK3, and the authentication information AT used to authenticate the fourth digital key DK4. Subsequently, the management server 70 sends deletion request D71 to the vehicle 20.

[0146] When vehicle 20 receives deletion request D71, vehicle 20 performs the process in step S92. In step S92, vehicle 20 deletes the authentication information AT for authenticating the target digital key and the authentication information AT for authenticating all digital keys registered based on the target digital key, in accordance with deletion request D71.

[0147] Specifically, vehicle 20 deletes the authentication information AT for authenticating the second digital key DK2, the authentication information AT for authenticating the third digital key DK3, and the authentication information AT for authenticating the fourth digital key DK4. After that, vehicle 20 sends a completion notification M71 to the management server 70. The completion notification M71 is a notification indicating that the deletion of the authentication information AT has been completed in accordance with the deletion request D71.

[0148] When the management server 70 receives the completion notification M71, the management server 70 performs the process in step S93. In step S93, the management server 70 generates a deletion request D72. The deletion request D72 is a request to delete the key information DK indicating the target digital key, and the key information DK indicating the digital keys registered based on the target digital key.

[0149] Specifically, deletion request D72 is a request to delete the key information DK indicating the second digital key DK2, the key information DK indicating the third digital key DK3, and the key information DK indicating the fourth digital key DK4. Subsequently, the management server 70 sends deletion request D72 to the second device 30B, the third device 30C, and the fourth device 30D.

[0150] When the second device 30B receives the deletion request D72, the second device 30B performs the process in step S94. In step S94, the second device 30B deletes the friend key information DKF indicating the second digital key DK2 in accordance with the deletion request D72.

[0151] When the third device 30C receives the deletion request D72, the third device 30C performs the process in step S95. In step S95, the third device 30C deletes the non-friend key information DKN indicating the third digital key DK3 in accordance with the deletion request D72.

[0152] Although not shown in the diagram, when the fourth device 30D receives a deletion request D72, the fourth device 30D deletes the non-friend key information DKN indicating the fourth digital key DK4 in accordance with the deletion request D72.

[0153] After the management server 70 sends the deletion request D72, the management server 70 performs the process in step S96. In step S96, the management server 70 updates the database DB. Specifically, the management server 70 deletes the second digital key DK2 to the fourth digital key DK4 and the second device 30B to the fourth device 30D from the data DA. After that, the management system 10 terminates the series of deletion management processes in the case where there are no alternative entries.

[0154] In this embodiment, the execution device 71 executes the server program PS to perform the processes in steps S81, S83, and S86, and to transmit the requests generated in each process. This causes the execution device 71 to execute the deletion management method. The server program PS is a program that instructs the execution device 71 to execute the deletion management method.

[0155] <Operation of the Embodiment> This section explains how the state of the data DA stored in the management server 70 changes as a result of the management system 10 performing deletion management.

[0156] As shown in Figure 12, the management system 10 deletes the key information DK indicating the second digital key DK2 in accordance with deletion request D62 or deletion request D72 in the deletion management. As a result, when data DA is updated, the second digital key DK2 is deleted.

[0157] As shown in Figure 13, when the management system 10 performs deletion management in the case of an alternative registration, the third digital key DK3 is deleted in accordance with deletion request D63. Subsequently, a new digital key DKX is registered in the third device 30C in accordance with registration request D64. The relationship between the new digital key DKX and the fourth digital key DK4 is the same as the relationship between the second digital key DK2 and the fourth digital key DK4. Furthermore, the authority of the new digital key DKX is the same as the authority of the second digital key DK2. Therefore, the deletion management in the case of an alternative registration updates the data DA as if the second digital key DK2 registered in the second device 30B had been replaced by the new digital key DKX registered in the third device 30C.

[0158] As shown in Figure 14, when the management system 10 performs deletion management in the event that there is no alternative registration, in accordance with the deletion request D73, the third digital key DK3 and the fourth digital key DK4 are deleted in addition to the second digital key DK2.

[0159] <Effects of the Embodiment> (1) When the specified condition RC is met, the management server 70 executes the deletion of the second digital key DK2 and the third digital key DK3. In the deletion management when there is an alternative registration, the management server 70 executes the registration of a new digital key DKX to the third device 30C where the third digital key DK3 was registered.

[0160] As a result, even if the third digital key DK3 is deleted, a new digital key DKX will be registered to the third device 30C. Therefore, the management server 70 can prevent the user of the third device 30C from being unable to use the vehicle 20.

[0161] (2) When the specified condition RC is met, the management server 70 deletes the second digital key DK2, but of the third digital key DK3 and fourth digital key DK4, it deletes the third digital key DK3 instead of the fourth digital key DK4. As a result, the management server 70 can prevent the user of the fourth device 30D from being unable to use the vehicle 20.

[0162] (3) The management server 70 does not allow the fourth device 30D, which has not made a new registration request D51, to register a new digital key DKX, and instead allows the third device 30C, which has made a new registration request D51, to register a new digital key DKX. This prevents the management server 70 from registering an excessive number of new digital keys DKX.

[0163] (4) The permissions of the new digital key DKX are the same as those of the second digital key DK2. Therefore, it is possible to prevent the vehicle 20 from becoming unusable as a result of the second digital key DK2 being deleted.

[0164] (5) The management server 70 restricts and manages the functions that use each digital key according to the relationships between the multiple digital keys. When a new digital key DKX is registered, the management server 70 updates the data DA to make the relationship between the fourth digital key DK4 and the new digital key DKX the same as the relationship between the fourth digital key DK4 and the second digital key DK2. Therefore, the management server 70 can continue to restrict the functions that use the fourth digital key DK4 even after the new digital key DKX is registered, just as it was when the second digital key DK2 was registered.

[0165] (6) When the vehicle 20 is used as a rental car or shared car, the user switches, for example, from the user of the second device 30B to the user of the fifth device 30E. Here, the specified condition RC is that a digital key different from the target digital key among the multiple digital keys is authenticated to the vehicle 20.

[0166] Therefore, when a new digital key is authenticated after the switch, the digital key that was used before the switch is deleted. Specifically, when any of the 5th digital key DK5 to the 7th digital key DK7 is authenticated on vehicle 20, the 2nd digital key DK2 to the 4th digital key DK4 used before the switch are deleted. This allows the management server 70 to delete the digital key used before the switch in accordance with the timing of the user switch.

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

[0168] <Management System> 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.

[0169] A different ECU installed in a different vehicle 20 than the vehicle management device 26 may authenticate the digital key. • The matters concerning digital keys in each of the above embodiments do not have to comply with CCC.

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

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

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

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

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

[0175] The functions using each digital key managed by the management server 70 according to the relationships between multiple digital keys are not limited to sending reservation deletion requests D41. For example, it may be a restriction on the types of digital keys displayed on the HMI 32 of the device 30 to which each digital key is registered. Alternatively, it may be a restriction on deletion requests.

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

[0177] The management server 70 may be configured as a circuit including one or more processors that execute various processes according to a computer program (software). Alternatively, the management server 70 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, or computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer. The same applies to the vehicle management device 26 and the device 30.

[0178] Deleting a digital key means changing the state from one where it is usable to one where it is unusable. In each of the above embodiments, if either the authentication information AT or the key information DK for a single digital key is deleted, that digital key becomes unusable.

[0179] Therefore, deleting a digital key means deleting at least one of the following: authentication information AT, which is information about the digital key stored in the vehicle management device 26, and key information DK, which is information about the digital key stored in the device 30. If both authentication information AT and key information DK are to be deleted, the digital key will be deleted at the time one of them is deleted first.

[0180] <Information about various types of information> The information regarding the digital key stored by the vehicle management device 26 is not limited to authentication information AT, but may be any information regarding the digital key. For example, the information regarding the digital key may be information that identifies the digital key.

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

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

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

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

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

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

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

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

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

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

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

[0192] The target digital key is not limited to the second digital key DK2, which is the friend key KF. For example, if a new non-friend key KN is registered based on the third digital key DK3, as in the modification example above, the target digital key may also be the third digital key DK3.

[0193] Multiple digital keys for vehicle 20 do not necessarily include multiple digital keys registered based on the target digital key. For example, the fourth digital key DK4 does not need to be registered.

[0194] <Reservation cancellation request> The entity that generates the reservation deletion request D41 is not limited to device 30. The management server 70 or vehicle 20 may also generate the reservation deletion request D41.

[0195] Device 30 may be able to generate a reservation deletion request D41 for digital keys among multiple digital keys that are not involved in registration. For example, the second device 30B may be able to generate a reservation deletion request D41 for the fifth digital key DK5.

[0196] <Fade-out detection> The specified condition RC does not necessarily have to be that a digital key different from the target digital key among multiple digital keys is authenticated by the vehicle 20. For example, the specified condition RC may be that a predetermined amount of time has elapsed since the reservation deletion request D41 was received.

[0197] <Deletion management when alternative registrations exist> The target digital keys are not limited to digital keys registered with device 30 that have received a new registration request D51. For example, they may be predetermined before the management server 70 receives the reservation deletion request D41.

[0198] When the specified condition RC is met and the target digital key is to be deleted, the digital key registered on device 30 that does not register a new digital key DKX among the multiple digital keys registered based on the target digital key does not need to be deleted. In other words, when the management server 70 deletes the second digital key DK2, it may also delete the fourth digital key DK4.

[0199] The management server 70 may cause a device 30 that has not requested registration of a new digital key DKX to register a new digital key DKX. That is, when a request for registration of a new digital key DKX is received, the management server 70 may delete the third digital key DK3 and the fourth digital key DK4, and cause the third device 30C and the fourth device 30D to register a new digital key DKX.

[0200] The management server 70 may perform step S81 after steps S83 and S86 in the series of processes shown in Figure 10. That is, the management server 70 may delete the authentication information AT after deleting and registering the key information DK.

[0201] <Data Update> The permissions of a new digital key DKX do not have to be the same as those of the target digital key. In other words, the permissions of a new digital key DKX do not have to be the same as those of the second digital key DK2. For example, the permissions of a new digital key DKX may be the same as those of the owner key KO, or the permissions of a new digital key DKX may be the same as those of the third digital key DK3.

[0202] When the management server 70 registers a new digital key DKX, it does not need to update the data DA to make the relationship between the fourth digital key DK4 and the new digital key DKX the same as the relationship between the fourth digital key DK4 and the second digital key DK2.

[0203] The storage device 72 does not need to store data DA indicating the relationships between multiple digital keys. The management server 70 does not need to restrict and manage the functions using each digital key according to the relationships between multiple digital keys.

[0204] [Note] The technical concepts that can be understood from the above embodiments and modified examples are described below. [Note 1] A management server for managing multiple digital keys for a vehicle, which, when predetermined conditions are met, deletes a target digital key and a digital key registered based on the target digital key, and when the predetermined conditions are met, causes a new digital key for the vehicle to be registered on the device where the deleted digital key registered based on the target digital key was registered.

[0205] [Note 2] The plurality of digital keys include a plurality of digital keys registered based on the target digital key, and when the specified conditions are met and the target digital key is deleted, the management server described in Note 1 deletes the digital keys registered on the device that does not allow the new digital key to be registered, among the plurality of digital keys registered based on the target digital key, but deletes the digital keys registered on the device that does allow the new digital key to be registered.

[0206] [Note 3] The management server described in Note 1 or Note 2, wherein the plurality of digital keys include a plurality of digital keys registered based on the target digital key, and does not allow devices that have not requested the registration of a new digital key to register the new digital key, but does allow devices that have requested the registration of a new digital key to register the new digital key.

[0207] [Note 4] The authority of the new digital key is the same as that of the management server specified in any one of Notes 1 to 3. [Note 5] A management server according to any one of Notes 1 to 4, which is equipped with a storage device that stores data indicating the relationships between the multiple digital keys, and which restricts and manages the functions using each digital key according to the relationships between the multiple digital keys, wherein the multiple digital keys include multiple digital keys registered based on the target digital key, and when registering a new digital key, updates the data so that the relationship between the new digital key and the digital key registered on a device that does not allow the new digital key to be registered among the multiple digital keys registered based on the target digital key is the same as the relationship between the digital key registered on a device that does not allow the new digital key to be registered and the target digital key.

[0208] [Note 6] The management server described in any one of Notes 1 to 5, wherein the specified condition is that a digital key different from the target digital key among the plurality of digital keys is authenticated by the vehicle. [Explanation of symbols]

[0209] 10…Management System 20... Vehicles 30…Device 70... Management Server 71…Execution device 72...Storage device DA...Data DK...Key Information DKX... New Digital Key RC…Specified conditions

Claims

1. A management server that manages multiple digital keys for a vehicle, When predetermined conditions are met, the target digital key among the multiple digital keys and the digital keys registered based on the target digital key are deleted. When the aforementioned specified conditions are met, the device on which the digital key registered based on the deleted target digital key was registered will be made to register a new digital key for the vehicle, and execute Management server.

2. The aforementioned multiple digital keys include multiple digital keys registered based on the aforementioned target digital key, When the aforementioned specified conditions are met and the target digital key is to be deleted, the digital keys registered on the device that does not allow the new digital key to be registered will not be deleted, while the digital keys registered on the device that does allow the new digital key to be registered will be deleted. The management server according to claim 1.

3. The aforementioned multiple digital keys include multiple digital keys registered based on the aforementioned target digital key, Devices that have not requested registration of the new digital key will not be allowed to register the new digital key, while devices that have requested registration of the new digital key will be allowed to register the new digital key. The management server according to claim 1.

4. The permissions of the new digital key are the same as those of the original digital key. The management server according to claim 1.

5. It is equipped with a storage device that stores data indicating the relationships between the aforementioned multiple digital keys, Depending on the relationships between the aforementioned multiple digital keys, the functions using each digital key are restricted and managed accordingly. The aforementioned multiple digital keys include multiple digital keys registered based on the aforementioned target digital key, When registering the aforementioned new digital key, The relationship between the digital key registered on the device that does not allow the new digital key to be registered, and the new digital key, is updated in the data to be the same as the relationship between the digital key registered on the device that does not allow the new digital key to be registered, and the digital key, based on the aforementioned target digital key. The management server according to claim 1.

6. The aforementioned condition is that a digital key different from the target digital key among the multiple digital keys is authenticated by the vehicle. The management server according to claim 1.

7. A deletion management method performed by a management server, which includes a computer for managing multiple digital keys for a vehicle, When predetermined conditions are met, the target digital key among the multiple digital keys and the digital keys registered based on the target digital key are deleted. This includes registering a new digital key for the vehicle on the device where the digital key registered based on the target digital key that was deleted when the aforementioned specified conditions were met was registered. Deletion management method.

8. A program to be executed on a computer included in a management server that manages multiple digital keys for a vehicle, To the aforementioned computer When predetermined conditions are met, the target digital key among the multiple digital keys and the digital keys registered based on the target digital key are deleted. When the aforementioned conditions are met, the device that was previously registered with the digital key based on the deleted target digital key will be made to register a new digital key for the vehicle. program.

Images