Management server, management system, deletion method, and deletion program product

Abstract

The invention relates to a management server, a management system, a deletion method, and a deletion program product. When the management server receives a deletion request specifying the registered shared key, the management server executes a deletion process in which the shared key is deleted from the shared key. And deleting the shared key registered in the target shared device in which the shared key specified in the received deletion request is registered and other shared devices in which the shared key is registered on the basis of the request from the target shared device.

Description

Technical Field

[0001] This disclosure relates to a management server, management system, deletion method, and deletion program product for managing digital keys. Background Technology

[0002] Japanese Patent Application Publication No. 2023-184349 discloses a technology for a digital key system that uses a smartphone or other device as a vehicle key. The digital key system allows the vehicle to store information related to the digital key. The digital key system also allows the device to store information related to the digital key. Therefore, a physical key is not required; the vehicle can be used simply by using the device registered as a digital key. Furthermore, the digital key system allows for the registration of another person's device as a digital key through communication between the device storing information related to the digital key and that device. Thus, the digital key system is configured to register another person's device as a digital key to the vehicle. In other words, the digital key system can generate new digital keys. The digital key system eliminates the need for the exchange of physical keys, allowing the vehicle to be lent to others.

[0003] When a vehicle is registered with many digital keys, users deleting multiple digital keys must select the keys to be deleted from among them individually. Therefore, deleting multiple digital keys is a heavy workload for users. Summary of the Invention

[0004] According to one aspect of this disclosure, a management server is provided, configured to manage multiple digital keys for a vehicle application, wherein the multiple digital keys include: an owner key registered for a device belonging to the owner of the vehicle, i.e., an owner device; and multiple shared keys registered for multiple shared devices, each of which is different from the owner device. The management server is configured to perform deletion processing upon receiving a deletion request, the deletion request specifying one of the multiple shared keys registered for one of the multiple shared devices, i.e., an object shared device. In the deletion processing, the shared key specified in the received deletion request and one of the multiple shared keys registered for other shared devices based on a request from the object shared device are deleted.

[0005] According to one aspect of this disclosure, a management system is provided, comprising a vehicle and a management server, the management server being configured to manage a plurality of digital keys applied to the vehicle, the plurality of digital keys including an owner key and a plurality of shared keys, the owner key being registered for a device belonging to the owner of the vehicle, i.e., an owner device, and the plurality of shared keys being registered for a plurality of shared devices, each of which is different from the owner device, wherein the management server is configured to perform deletion processing upon receiving a deletion request, the deletion request specifying one of the shared keys registered for one of the plurality of shared devices, i.e., an object shared device, in the deletion processing, deleting the shared key specified in the received deletion request and one of the shared keys registered for other shared devices based on a request from the object shared device.

[0006] According to one aspect of this disclosure, a deletion method is provided, performed by a management server configured to manage multiple digital keys for a vehicle application, wherein the multiple digital keys include: an owner key registered for a device belonging to the owner of the vehicle, i.e., an owner device; and multiple shared keys registered for multiple shared devices, each of which is different from the owner device. The deletion method includes generating a deletion instruction and performing deletion processing upon receiving a deletion request from the processing circuitry of the management server, wherein the deletion request specifies a shared key registered for one of the multiple shared devices, i.e., an object shared device, and the deletion instruction is an instruction to delete the shared key registered for the object shared device. In the deletion processing, the shared key specified in the received deletion request and one of the multiple shared keys registered for other shared devices based on a request from the object shared device are deleted.

[0007] According to one aspect of this disclosure, an uninstallation program product is provided, which causes the processing circuit to perform the uninstallation method described above. Attached Figure Description

[0008] Figure 1 It is a schematic diagram representing the management system.

[0009] Figure 2 It is a schematic diagram representing the owner's key information.

[0010] Figure 3 This is a diagram illustrating shared key information;

[0011] Figure 4 It is a schematic diagram representing the data in the database.

[0012] Figure 5 This is an illustration of the series of processes performed by the management system when registering the owner's key.

[0013] Figure 6 This is an illustration of a series of processes performed by the management system when registering friend keys.

[0014] Figure 7 This is an illustration of a series of processes performed by the management system when registering a non-friend key.

[0015] Figure 8 This is an illustration of a series of processes performed by the management system when a non-friend key is deleted based on a request from a friend's device.

[0016] Figure 9 This is an illustration of a series of processes performed by the management system when a non-friend key is deleted based on a request from a non-friend device.

[0017] Figure 10 This is an illustration of a series of processes performed by the management system when multiple shared keys are deleted based on a request from the owner's device.

[0018] Figure 11 This is a diagram illustrating the relationship between multiple shared devices.

[0019] Figure 12 It means in Figure 10 A flowchart of the processing flow executed by the management server.

[0020] Figure 13 This is an example of an image displayed to prompt the user to select a shared key as the object of protection.

[0021] Figure 14 It means Figure 10 A schematic diagram of the deletion process performed by the central management server.

[0022] Figure 15 This is a diagram illustrating the relationship between multiple shared devices in a change example. Detailed Implementation

[0023] The following is for reference Figures 1 to 14 The management system 10 of the implementation method will be described.

[0024] <Overview of Management System 10>

[0025] like Figure 1As shown, management server 70 is one of the devices constituting management system 10. Management server 70 manages information related to multiple digital keys that can be registered for vehicle 20. Regarding digital keys, there is the CCC (CarConnectivity Consortium) standard. Matters related to digital keys in this embodiment are based on CCC. Management system 10 includes vehicle 20, multiple devices 30, device server 60, and management server 70.

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

[0027] The communication module 21 communicates with the management server 70 via a wireless communication network. The HMI 22 includes an input device for accepting operations from the user of the vehicle 20 and a prompting device for providing information to the user through images and sounds. The prompting device may be, for example, a monitor and a speaker.

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

[0029] A vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages information related to the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. By executing the vehicle program PV, the execution device 27 stores and deletes the authentication information AT. The authentication information AT is information used to authenticate the digital key so that the vehicle 20 can be controlled via the digital key when it is used. The authentication information AT is set for each digital key to be authenticated. The execution device 27 is a CPU. The execution device 27 performs processing related to the storage and deletion of the authentication information AT by executing the vehicle program PV. The authentication information AT is information related to the digital key.

[0030] It should be noted that an authenticated digital key refers to a digital key that can be used to control vehicle 20. For example, when vehicle management device 26 authenticates the digital key, vehicle management device 26 can unlock vehicle 20. Additionally, for example, when vehicle management device 26 authenticates the digital key, vehicle management device 26 can start vehicle 20.

[0031] Device 30 is a portable 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 actuator 36, and a storage device 37.

[0032] The communication module 31 communicates with the device server 60 via a wireless communication line. The HMI 32 includes an input device for receiving user operations from the device 30 and a prompting device for providing information to the user through images and sounds. The prompting device may be, for example, a monitor and a speaker.

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

[0034] Storage device 37 stores device program PD and key information DK. The execution device 36 stores and deletes the key information DK by executing the device program PD. The key information DK represents information about a digital key; that is, the key information DK is information related to the digital key.

[0035] The device program (PD) includes, for example, a device application and a digital key framework. The device application is used to store and delete key information (DK). The digital key framework is a program that uses APIs prepared in the OS to provide pairing functionality for device 30 and sharing of digital keys. The execution device 36 performs the processing related to the storage and deletion of key information (DK) by executing the device program (PD).

[0036] Multiple devices 30 include owner device 40 and multiple shared devices 50. Owner device 40 is the device 30 belonging to the owner of vehicle 20. Owner device 40 stores owner key information DKO, representing owner key KO, as key information DK. Owner key information DKO is information associated with owner key KO. Only one owner key KO can be registered for each vehicle 20. Therefore, only one owner key KO exists for each vehicle 20.

[0037] like Figure 2As shown, 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 includes certificate information ST5, device public key information ST6, vehicle public key information ST7, and license public key information ST8.

[0038] Vehicle identification information ST1 is information used to identify the vehicle 20 that is the object of the digital key. For example, it is the ID of vehicle 20.

[0039] The in-device key identification information ST2 is used for the management of digital keys within device 30. ST2 is the information that enables the identification of digital keys within the application of device 30.

[0040] Digital key identification information ST3 is used to manage digital keys within the management server 70. Slot identification information ST4 is information that enables local identification of digital keys on device 30.

[0041] Certificate information ST5 represents the certificate proving the digital key. Device public key information ST6 represents the device public key PKD that serves as the public key for device 30. It should be noted that the device public key PKD in the owner key information DKO represents the public key of the owner device 40. Vehicle public key information ST7 represents the vehicle public key PKV that serves as the public key for vehicle 20. Licensed public key information ST8 represents the licensed vehicle public key PKV.

[0042] like Figure 1 As shown, the sharing device 50 stores shared key information DKS, representing a shared key KS, as key information DK. Shared key information DKS is information related to the shared key KS. Multiple shared keys KS can be registered for one vehicle 20, based on the registration of digital keys to enable the use of digital keys. That is, multiple shared keys KS can exist for one vehicle 20.

[0043] Multiple sharing devices 50 include friend devices 51 and non-friend devices 52. Friend device 51 stores friend key information DKF representing friend key KF as shared key information DKS. Friend key information DKF is information related to shared key KS. Non-friend device 52 stores non-friend key information DKN representing non-friend key KN as shared key information DKS. Non-friend key information DKN is information related to shared key KS. That is, the types of shared key KS include friend key KF and non-friend key KN.

[0044] As described later, the friend key KF is a shared key KS registered based on a registration request D21 directly from the owner device 40. Registration request D21 is a request for device 30 to store the friend key information DKF as key information DK. That is, registration request D21 is a request for other devices 30 to store information related to the new shared key KS.

[0045] The non-friend key KN is a shared key KS registered based on a registration request D31 from friend device 51, as described later. Registration request D31 is a request for device 30 to store the non-friend key information DKN as the new shared key information DKS. That is, registration request D31 is a request for other device 30 to store information related to the new shared key KS. The non-friend key KN is a shared key KS registered based on an indirect registration request from a sharing device 50 that is a device 30 different from the owner device 40.

[0046] It should be noted that registering a digital key means being able to use the digital key. Specifically, when a digital key is registered, vehicle 20 stores authentication information AT corresponding to the key information DK, and device 30 stores the key information DK corresponding to the authentication information AT. The authentication information AT is information related to the digital key. In other words, when a digital key is registered, vehicle 20 stores information related to the digital key. The key information DK is also information related to the digital key. In other words, when a digital key is registered, device 30 stores information related to the digital key. If the key information DK is related to a shared key KS, the authentication information AT corresponding to that key information DK is also related to the shared key KS.

[0047] like Figure 3 As shown, the shared key information (DKS) includes shared key structure information (STS) and authentication package (ATP). The shared key structure information (STS) contains vehicle identification information (ST1), in-device key identification information (ST2), digital key identification information (ST3), and slot identification information (ST4). The shared key structure information (STS) also contains certificate information (ST5), vehicle public key information (ST7), and license public key information (ST8). In other words, the shared key structure information (STS) is the information obtained by removing the device public key information (ST6) from the owner key structure information (STO).

[0048] The authentication package ATP contains signature information ATP1, password information ATP2, validity start information ATP3, validity period information ATP4, naming information ATP5, and device public key information ATP6.

[0049] The signature information ATP1 indicates that the sharing device 50 is a legitimate object of the shared digital key. For example, in the case of a friend device 51, it represents the signature of the owner device 40. The owner signature information indicates that the owner device 40 signed the device public key PKD of friend device 51, as represented by the device public key information ATP6. Alternatively, for example, in the case of a non-friend device 52, it represents the signature of friend device 51. The friend signature information indicates that friend device 51 signed the device public key PKD of non-friend device 52, as represented by the device public key information ATP6.

[0050] Password information ATP2 indicates the pairing password PAS used when establishing a secure channel during pairing of vehicle 20 and owner device 40. Valid start information AT3 indicates the earliest date and time at which the shared key KS can be used. Validity period information AT4 indicates the latest date and time at which the shared key KS can be used. Naming information ATP5 indicates the name that identifies the shared device 50 storing the shared key information DKS. For example, a recognizable name is set for each shared device 50 through operations from owner device 40.

[0051] like Figure 1 As shown, device server 60 relays communication between device 30 and management server 70. Device server 60 is configured for each category of device 30. That is, the device server 60 communicating with devices of the first category is different from the device server 60 communicating with devices of the second category. Any device server 60 relays communication with management server 70, thus allowing devices of different categories to be relayed between device server 60 and management server 70. It should be noted that... Figure 1 The image shows only one device, server 60.

[0052] <Management Server 70>

[0053] The management server 70 manages the digital key. The management server 70 can communicate with the vehicle 20 and multiple devices 30. The management server 70 includes an execution device 71, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. Additionally, the communication module 73 can wirelessly communicate with the communication module 21 of the vehicle 20.

[0054] Storage device 72 stores a server program PS, a deletion program PM, and a database DB. The server program PS, executed by execution device 71, causes execution device 71 to register and delete digital keys in the database DB. The deletion program PM, executed by execution device 71, causes execution device 71 to perform the process of generating an instruction to delete the shared key KS. The execution device 71, by executing the deletion program PM, performs the process of deleting the shared key KS.

[0055] For each of the multiple digital keys, the database DB establishes a correspondence between 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 representing the device 30 that stores the key information DK representing that digital key.

[0056] Permissions include, for example, the number of shared keys KS that can be registered, and the control range of vehicle 20 that can be accessed through digital key authentication. Higher levels grant greater permissions, thus allowing for, for example, the registration of more shared keys KS. More specifically, for example, the owner device 40 can register more friend keys KF than the friend device 51 can register more non-friend keys KN.

[0057] Furthermore, for example, higher levels grant greater privileges, thus expanding the controllable range of vehicle 20. It should be noted that the controllable range of vehicle 20 includes, for example, the controllable starting control of vehicle 20's engine, the controllable power supply to vehicle 20, and the controllable unlocking and locking of vehicle 20's doors. For instance, when the controllable range of vehicle 20 includes all three of these controls, it represents a wider controllable range compared to when the controllable range of vehicle 20 is limited to unlocking and locking vehicle 20's doors. More specifically, the controllable range of vehicle 20 by the friend key KF includes all three of these controls, while the controllable range of vehicle 20 by the non-friend key KN is limited to unlocking and locking vehicle 20's doors.

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

[0059] For a vehicle 20, the following describes the status of seven devices 30 with registered digital keys. The seven devices 30 are: device 30A, device 30B, device 30C, device 30D, device 30E, device 30F, and device 30G. The digital key registered in device 30A is designated as the first digital key K1. The digital key registered in device 30B is designated as the second digital key K2. The digital key registered in device 30C is designated as the third digital key K3. The digital key registered in device 30D is designated as the fourth digital key K4. The digital key registered in device 30E is designated as the fifth digital key K5. The digital key registered in device 30F is designated as the sixth digital key K6. The digital key registered in device 30G is designated as the seventh digital key K7.

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

[0061] In data DA, the devices 30 registered as shared key KS are second device 30B, third device 30C, fourth device 30D, fifth device 30E, sixth device 30F, and seventh device 30G. That is, second device 30B, third device 30C, fourth device 30D, fifth device 30E, sixth device 30F, and seventh device 30G are shared devices 50. In other words, second digital key K2, third digital key K3, fourth digital key K4, fifth digital key K5, sixth digital key K6, and seventh digital key K7 are all shared keys KS.

[0062] More specifically, in the data DA, the devices 30 whose digital key type is registered 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 whose digital key type is registered 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.

[0063] In data DA, the relationship between the second device 30B and the first device 30A is based on a registration request from the first device 30A, resulting in the second device 30B having a friend key KF registered there. That is, the second digital key K2 is registered based on the first digital key K1.

[0064] In data DA, the relationship between the fifth device 30E and the first device 30A is based on a registration request from the first device 30A, and the fifth device 30E has a registered friend key KF. That is, the fifth digital key K5 is registered based on the first digital key K1.

[0065] In data DA, the relationship between the third device 30C and the second device 30B is based on a registration request from the second device 30B, and a non-friend key KN is registered in the third device 30C. That is, the third digital key K3 is registered based on the second digital key K2.

[0066] In data DA, the relationship between the fourth device 30D and the second device 30B is based on a registration request from the second device 30B, where a non-friend key KN is registered in the fourth device 30D. That is, the fourth digital key K4 is registered based on the second digital key K2.

[0067] In data DA, the relationship between the sixth device 30F and the fifth device 30E is based on a registration request from the fifth device 30E, and a non-friend key KN is registered in the sixth device 30F. That is, the sixth digital key K6 is registered based on the fifth digital key K5.

[0068] In data DA, the relationship between the seventh device 30G and the fifth device 30E is based on a registration request from the fifth device 30E, and a non-friend key KN is registered in the seventh device 30G. That is, the seventh digital key K7 is registered based on the fifth digital key K5.

[0069] Thus, the data DA stores the device 30 registered as a digital key. Additionally, when the device 30 is registered, information indicating the reason for the registration is associated with the device 30. Furthermore, the data DA also contains information indicating which digital key each digital key is registered on.

[0070] Digital Key Registration

[0071] Next, the series of processes for registering digital keys in the management system 10 will be described. The management system 10 registers the owner key KO, the friend key KF, and the non-friend key KN as digital keys. The following describes the series of processes from the state where no digital keys are registered to the state where digital keys are registered. In the following description, the processes executed by the execution device 27 of the vehicle management device 26 will be described as processes executed by the vehicle 20. In the following description, the processes executed by the execution device 36 will be described as processes executed by the device 30. In the following description, the processes executed by the execution device 71 will be described as processes executed by the management server 70.

[0072] <Registration of Owner's Key>

[0073] like Figure 5 As shown, the management system 10 performs a series of processes to register the owner key KO. It should be noted that the device 30 that does not store key information DK representing the owner key KO, which is the owner device 40, is designated as the first device 30A.

[0074] The management system 10 stores key information DK representing the owner key KO in the first device 30A through the registration of the owner key KO. The management system 10 also stores authentication information AT for authenticating the owner key KO in the vehicle 20 through the registration of the owner key KO. Thus, the first device 30A becomes the owner device 40. It should be noted that the registration of the owner key KO requires the first device 30A to have an application installed.

[0075] When the management server 70 receives the registration request D11 of the owner key KO from the first device 30A, the management server 70 first performs the processing in step S11. In step S11, the management server 70 generates a pairing password PAS. Afterwards, the management server 70 sends information representing the pairing password PAS to the vehicle 20 and the first device 30A.

[0076] Then, vehicle 20 receives the pairing password PAS. After receiving the pairing password PAS, if vehicle 20 is set to pairing mode from HMI 22, it will standby while being able to receive the password from the first device 30A. Then, vehicle 20 proceeds to step S12.

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

[0078] In step S13, vehicle 20 generates a vehicle public key PKV as the public key of vehicle 20 and a vehicle private key SKV as the private key of vehicle 20. Then, vehicle 20 sends generation data DC for generating the owner key KO to the first device 30A via a secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information representing the vehicle public key PKV. The first device 30A then receives the generation data DC. The first device 30A then proceeds to step S14.

[0079] In step S14, the first device 30A generates owner key information DKO representing the owner key KO. Then, the first device 30A causes the process to proceed to step S15.

[0080] In step S15, the first device 30A stores the owner key information DKO. Thus, the first device 30A becomes the owner device 40. That is, the registration request D11 is a request for device 30 to store the owner key information DKO as key information DK. Afterwards, the first device 30A sends certificate information ST5 related to the owner key KO and device public key information ST6 representing the device public key PKD to the vehicle 20.

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

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

[0083] Then, when the first device 30A receives the completion notification M11, the first device 30A performs the processing in step S18. In step S18, the first device 30A generates a key status update (track) request D12 for the owner key KO. The key status update request D12 is a signal to the management server 70 requesting an update to the database DB. Then, the first device 30A sends the key status update requests D12 for all keys KO to the management server 70 via the device server 60.

[0084] Then, upon receiving the key status update request D12, the management server 70 performs step S19. In step S19, the management server 70 performs registration management of the owner key KO. Specifically, in the vehicle 20 data DA in the database DB, the first device 30A is stored as the device 30 registered as the owner key KO. Thus, the management system 10 concludes the series of processes for the owner key KO.

[0085] <Registration of Friend Key KF>

[0086] like Figure 6 As shown, the management system 10 performs a series of processes to register friend keys (KF). It should be noted that the device 30 that has not stored friend key information (DKF) and has been designated as a friend device 51 through this series of processes is designated as the second device 30B.

[0087] In owner device 40, by performing the operation of requesting registration of friend key KF, owner device 40 first proceeds to step S21. In step S21, owner device 40 sends a registration request D21 for friend key KF to the relay server (not shown in the figure). Then, owner device 40 causes the process to proceed to step S22.

[0088] 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 stores the sharing information SH1 required to share the digital key. Then, the owner device 40 sends invitation information IV1 to the second device 30B.

[0089] Then, when the second device 30B receives the invitation information IV1, it performs the processing in step S23. In step S23, the second device 30B obtains the shared information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the shared information SH1 from the link source of the URL link.

[0090] The shared information SH1 includes, for example, shared key structure information STS, password information ATP2, validity start information AT3, validity period information ATP4, and naming information ATP5. It should be noted that the validity start information AT3, validity period information ATP4, and naming information ATP5 are set by the owner device 40. Afterwards, the second device 30B initiates the process to step S24.

[0091] In step S24, the second device 30B uses the shared information SH1 to generate an unsigned friend key information DKFN. The unsigned friend key information DKFN is a friend key information DKF without the signature information ATP1. Specifically, the second device 30B generates the information contained in the obtained shared information SH1 into the information of the unsigned friend key information DKFN. Then, the second device 30B sends a completion notification M21 indicating that the generated unsigned friend key information DKFN has been uploaded to the URL link, and a signature request D22 requesting a signature, to the owner device 40.

[0092] Then, 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 processing of step S25 by operating the owner device 40.

[0093] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 prompts the HMI 32 to display the obtained unsigned friend key information DKFN and accepts an operation indicating that the owner device 40 has user consent to the registration of friend key KF. Upon this operation, the owner device 40 obtains a signature based on the operation. Then, the owner device 40 proceeds to step S26.

[0094] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. Thus, the owner device 40 generates the friend key information DKF. Then, the owner device 40 uploads the generated friend key information DKF to the URL link, which serves as the invitation information IV1. Finally, the owner device 40 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.

[0095] Then, the second device 30B receives the completion notification M22. Next, the second device 30B proceeds to step S27. In step S27, the second device 30B stores the friend key information DKF by downloading it. Thus, the second device 30B becomes the friend device 51. Afterwards, the second device 30B proceeds to step S28.

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

[0097] Then, when the management server 70 receives the key status update request D23 from the friend key KF, the management server 70 performs step S29. In step S29, the management server 70 performs registration management of the friend key KF. The key status update request D23 is a request to make the vehicle 20 store new authentication information AT. That is, the key status update request D23 is a request to make the vehicle 20 store information related to the digital key.

[0098] Specifically, the management server 70 checks whether the friend key KF, which is the target of the key status update request D23, is listed on the rejection list. The rejection list represents a list containing the friend key KF and the shared key KS, which are not friend keys KN, and have received deletion requests. If the friend key KF is listed on the rejection list, the management server 70 sends a notification to the second device 30B that it cannot respond to the key status update request D23.

[0099] On the other hand, if the friend key KF that received the key status update request D23 is not listed on the rejection list, the management server 70 will register the friend key KF that received the key status update 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 based on the obtained friend key information DKF.

[0100] Subsequently, management server 70 sends the authentication packet ATP from the friend key information DKF and a storage request D24 requesting the storage of the authentication packet ATP to vehicle 20. That is, management server 70 sends the device public key information ST6 representing the device public key PKD of friend device 51 to vehicle 20. Additionally, management server 70 notifies vehicle 20 that the device public key PKD has been signed by owner device 40.

[0101] Subsequently, if vehicle 20 receives storage request D24 and authentication packet ATP from management server 70, it proceeds to step S30. In step S30, vehicle 20 stores the received authentication packet ATP as authentication information AT for authenticating friend key KF.

[0102] In addition, after completing the registration management, the management server 70 sends a key status update completion notification M23 to the second device 30B.

[0103] Then, upon receiving the key status update completion notification M23, the second device 30B performs step S31. In step S31, the second device 30B displays 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 that the registration of the friend key KF is complete on the HMI 32. Thus, the management system 10 concludes the series of processes for registering the friend key KF.

[0104] <Registration of Non-Friend Key KN>

[0105] like Figure 7 As shown, the management system 10 performs a series of registration processes to register non-friend key KN. It should be noted that in device 30 that does not store non-friend key information DKN, device 30 that is set as non-friend device 52 through this series of processes is set as third device 30C.

[0106] By performing the registration request for the non-friend key KN in the second device 30B, which acts as the friend device 51, the friend device 51 first proceeds to step S41. In step S41, the friend device 51 sends the registration request D31 for the non-friend key KN to the relay server (not shown in the figure). Afterwards, the friend device 51 proceeds to step S42.

[0107] In step S42, the friend device 51 obtains invitation information IV2 for sharing the digital key from the relay server. Invitation information IV2 is, for example, a URL link. The URL link stores the sharing information SH2 required to share the digital key. Then, the friend device 51 sends invitation information IV2 to the third device 30C.

[0108] Then, when the third device 30C receives the invitation information IV2, it performs step S43. In step S43, the third device 30C obtains the shared information SH2 based on the invitation information IV2. Specifically, the third device 30C downloads the shared information SH2 from the URL link.

[0109] The shared information SH2 includes, for example, shared key structure information STS, password information ATP2, validity start information AT3, validity period information ATP4, and naming information ATP5. It should be noted that the validity start information AT3, validity period information ATP4, and naming information ATP5 are set by the friend device 51. Then, the third device 30C causes the process to proceed to step S44.

[0110] In step S44, the third device 30C uses the shared information SH2 to generate unsigned non-friend key information DKNN. The unsigned non-friend key information DKNN is a non-friend key information DKN without signature information ATP1. Specifically, the third device 30C generates the information contained in the obtained shared information SH2 into the information of the unsigned non-friend key information DKNN. Then, the third device 30C sends a completion notification M31 indicating that the generated unsigned non-friend key information DKNN has been uploaded to the URL link, and a signature request D32 to the friend device 51.

[0111] Then, 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 processing in step S45 by operating the friend device 51.

[0112] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 prompts the HMI 32 with the obtained unsigned non-friend key information DKNN, and accepts an operation indicating that the user of the friend device 51 agrees to the generation of the non-friend key KN. When the operation is performed, the friend device 51 obtains a signature based on the operation performed. Afterwards, the friend device 51 proceeds to step S46.

[0113] In step S46, the friend device 51 adds signature information ATP1 to the unsigned non-friend key information DKNN. Thus, the friend device 51 generates non-friend key information DKN. Then, the friend device 51 uploads the generated non-friend key information DKN to the invitation information IV2, i.e., the URL link. Finally, the friend device 51 sends a completion notification M32 to the third device 30C, indicating that the upload of the completed non-friend key information DKN to the URL link is complete.

[0114] Then, the third device 30C receives the completion notification M32. Next, the third device 30C proceeds to step S47. In step S47, the third device 30C downloads and stores the non-friend key information DKN. Thus, the third device 30C becomes a non-friend device 52. Then, the third device 30C proceeds to step S48.

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

[0116] Then, when the management server 70 receives a key status update request D33 from a non-friend key KN, the management server 70 performs step S49. In step S49, the management server 70 performs registration management of the non-friend key KN.

[0117] Specifically, the management server 70 checks whether the non-friend key KN, which is the target of the key status update request D33, is listed on the rejection list. If the non-friend key KN is listed on the rejection list, the management server 70 sends a notification to the third device 30C that it cannot respond to the key status update request D33.

[0118] On the other hand, if the non-friend key KN is not listed on the rejection list, the management server 70 registers the non-friend key KN, which is the object of the key status update request D33, in the database DB. Specifically, the management server 70 stores the third device 30C as device 30 registered as a non-friend device 52 in the vehicle 20 data DA in the database DB. The management server 70 stores the relationship between the third device 30C and the friend device 51 with reference to the obtained non-friend key information DKN. Specifically, the management server 70 stores the third device 30C as device 30 with a non-friend key KN registered through the registration request D31 from the second device 30B.

[0119] Then, management server 70 sends the authentication packet ATP from the non-friend key information DKN and a storage request D34 requesting the storage of the authentication packet ATP to vehicle 20. That is, management server 70 sends the device public key information ST6 representing the device public key PKD of non-friend device 52 to vehicle 20. In addition, management server 70 notifies vehicle 20 that the device public key PKD has been signed by friend device 51.

[0120] Upon receiving the key status update request D33, the management server 70 sends a storage request D34 to the vehicle 20. This storage request D34 requests the storage of information related to the digital key, namely the authentication packet ATP. In other words, the key status update request D33 is a request for the vehicle 20 to store information related to the digital key.

[0121] Then, when vehicle 20 receives the authentication packet ATP and storage request D34, it proceeds to step S50. In step S50, vehicle 20 stores the received authentication packet ATP. That is, vehicle 20 stores the authentication packet ATP as authentication information AT used to authenticate the non-friend key KN.

[0122] In addition, after completing the registration management, the management server 70 sends a key status update completion notification M33 to the second device 30B.

[0123] Then, upon receiving the key status update completion notification M33, the third device 30C performs step S51. In step S51, the third device 30C displays information to the HMI 32 indicating that the registration of the non-friend key KN is complete. For example, the third device 30C displays an image indicating that the registration of the non-friend key KN is complete on the HMI 32. Thus, the management system 10 concludes the series of processes for registering the non-friend key KN.

[0124] <Delete non-friend key KN>

[0125] Next, the series of processes for deleting non-friend key KNs in the management system 10 will be explained. The following describes the series of processes from the state where a non-friend key KN is registered to the state where no non-friend key KN is registered. It should be noted that in the following explanation, the processes executed by execution device 27 will be described as processes executed by vehicle 20, the processes executed by execution device 36 will be described as processes executed by device 30, and the processes executed by execution device 71 will be described as processes executed by management server 70.

[0126] <Deletion of non-friend key KN based on deletion appointment D41 from friend device 51>

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

[0128] By performing a request to delete a non-friend key KN in the friend device 51, the friend device 51 first performs step S61. In step S61, a deletion reservation D41 for the non-friend key KN is generated. Deletion reservation D41 is a signal that reserves the deletion of the non-friend key KN.

[0129] The deletion reservation D41 includes a signal requesting the deletion of the non-friend key KN, digital key identification information ST3 representing the non-friend key KN, and information representing predetermined conditions RC. The predetermined conditions RC are the conditions required to initiate deletion upon receiving the deletion reservation D41. The predetermined conditions RC are predetermined. For example, the predetermined conditions RC are established after a predetermined fade-out period following the receipt of the deletion reservation D41. The deletion reservation D41 includes naming information ATP5, which identifies the friend device 51 that sent the deletion reservation D41 to the management server 70. Then, the friend device 51 sends the deletion reservation D41 for the non-friend key KN to the management server 70.

[0130] Then, when the management server 70 receives the deletion reservation D41 from the non-friend key KN, it performs step S62. In step S62, the management server 70 generates a reservation notification M41 indicating that the reservation is in progress, based on the deletion reservation D41. Then, the management server 70 sends the reservation notification M41 to the friend device 51.

[0131] Then, when the friend device 51 receives the reservation notification M41, the friend device 51 performs the processing in step S63. In step S63, the friend device 51 prompts the HMI 32 with information indicating that the deletion of the non-friend key KN, which is the object of the deletion reservation D41, is in reservation.

[0132] After the processing in step S62, the management server 70 proceeds to step S64. In step S64, the management server 70 stores the state of the non-friend key KN, which is the object of deletion appointment D41, as a fade-out state in the database DB. The fade-out state is a state in which the deletion execution is still retained even though deletion appointment D41 has been received. Then, the management server 70 causes the process to proceed to step S65.

[0133] In step S65, the management server 70 confirms that the predetermined condition RC is met. When the management server 70 confirms that the predetermined condition RC is met, the management server 70 causes the process to proceed to step S66.

[0134] In step S66, the management server 70 generates a deletion instruction D42 that deletes the non-friend key information DKN of the non-friend key KN representing the object of deletion reservation D41. Then, the management server 70 sends the deletion instruction D42 to the third device 30C, which is the non-friend device 52.

[0135] Then, when the non-friend device 52 receives the deletion instruction D42, it proceeds to step S67. In step S67, the non-friend device 52 deletes the non-friend key information DKN according to the deletion instruction D42. Then, the non-friend device 52 sends a deletion completion notification M42 to the management server 70, indicating that the deletion according to the deletion instruction D42 has been completed.

[0136] Then, when the management server 70 receives the completion notification M42, the management server 70 performs the processing in step S68. In step S68, the management server 70 stores and deletes the history of the non-friend key information DKN in the non-friend device 52. Then, the management server 70 causes the processing to proceed to step S69.

[0137] In step S69, the management server 70 generates a deletion instruction D43 for authentication information AT. This deletion instruction D43 represents a request to delete the authentication information AT of the non-friend key KN used to authenticate the deletion appointment D41. Then, the management server 70 sends the deletion instruction D43 to the vehicle 20.

[0138] Subsequently, when vehicle 20 receives deletion instruction D43, vehicle 20 proceeds to step S70. In step S70, vehicle 20, according to deletion instruction D43, deletes the authentication information AT of the non-friend key KN used to authenticate the deletion reservation D41. That is, vehicle 20 deletes the authentication packet ATP of the non-friend key KN. Afterward, vehicle 20 sends a deletion completion notification M43 to management server 70, indicating that the deletion of the authentication information AT according to deletion instruction D43 has been completed.

[0139] Then, when the management server 70 receives the completion notification M43, the management server 70 performs the processing in step S71. In step S71, the management server 70 stores the history of the authentication information AT of the non-friend key KN used to authenticate the object deleted in the series of deletions related to this process in vehicle 20. Then, the management server 70 causes the process to proceed to step S72.

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

[0141] Then, when the friend device 51 receives the completion notification M44, the friend device 51 performs step S73. In step S73, the friend device 51 prompts the HMI 32 with information indicating that the deletion of the non-friend key KN, which is the object of the deletion reservation D41, has been completed. For example, the friend device 51 displays an image indicating that the deletion of the non-friend key KN has been completed on the HMI 32. After that, the management system 10 ends the series of processes related to the deletion of the non-friend key KN.

[0142] <Deleted non-friend key KN caused by deletion in non-friend device 52>

[0143] like Figure 9 As shown, due to the deletion operation in the non-friend device 52, the management system 10 performs a series of processes to delete the non-friend key KN represented by the non-friend key information DKN stored in the non-friend device 52.

[0144] By executing the prescribed operation of requesting the deletion of the non-friend key KN in the third device 30C, which is a non-friend device 52, the non-friend device 52 first performs step S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN according to the prescribed operation. Then, the non-friend device 52 sends a completion notification M51 to the management server 70 indicating that the deletion of the non-friend key information DKN is complete.

[0145] Then, when the management server 70 receives the completion notification M51, the management server 70 performs step S82. In step S82, the management server 70 stores the history of the deleted non-friend key information DKN in the non-friend device 52. Then, the management server 70 sends a completion notification M52 to the second device 30B, which is the friend device 51, indicating that the deletion of the non-friend key information DKN is complete.

[0146] Then, when the friend device 51 receives the completion notification M52, the friend device 51 performs the processing in step S83. In step S83, the friend device 51 prompts the HMI 32 with a message indicating that the deletion of the non-friend key information DKN of the non-friend device 52 has been completed. For example, the friend device 51 displays an image indicating that the deletion of the non-friend key KN has been completed on the HMI 32.

[0147] After the processing in step S82, the management server 70 proceeds to step S84. In step S84, the management server 70 generates a deletion instruction D51, which deletes the authentication information AT used to authenticate the non-friend key information DKN that was deleted in step S81. Then, the management server 70 sends the deletion instruction D51 to the vehicle 20.

[0148] Subsequently, when vehicle 20 receives deletion instruction D51, vehicle 20 proceeds to step S85. In step S85, vehicle 20, according to deletion instruction D51, deletes the authentication information AT used to authenticate the non-friend key information DKN deleted in step S81. Then, vehicle 20 sends a completion notification M53 to management server 70 indicating that the deletion of authentication information AT according to deletion instruction D51 is complete.

[0149] Then, when the management server 70 receives the completion notification M53, the management server 70 proceeds to step S86. In step S86, the management server 70 stores and deletes the history of the authentication information AT used to authenticate the non-friend key information DKN that was deleted in step S81. Then, the management server 70 proceeds to step S87.

[0150] In step S87, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52, which is the object of deletion in this series of processes, from the data DA of vehicle 20 in the database DB. Thus, the management system 10 concludes the series of processes related to the deletion of the non-friend key KN.

[0151] <Regarding the deletion of multiple shared keys KS based on deletion request D61>

[0152] like Figure 10 As shown, the management system 10 performs a series of processes to perform deletion processing DEL based on the shared key KS from the deletion request D61 from the first device 30A, which is the owner device 40. Figure 10 In the series of processes shown, the management system 10 deletes multiple shared keys KS based on deletion request D61.

[0153] By executing the operation of specifying and requesting the deletion of the registered shared key KS in the owner device 40, the owner device 40 first performs the processing of step S121. In step S121, a deletion request D61 is generated specifying the registered shared key KS. The deletion request D61 includes a signal requesting the deletion of the registered shared key KS and digital key identification information ST3 indicating the registered shared key KS. The deletion request D61 includes information identifying the owner device 40 that sent the deletion request D61 to the management server 70, namely the naming information ATP5. Then, the owner device 40 sends the deletion request D61 to the management server 70. Figure 10 In the series of processes shown, deletion request D61 is a signal requesting the deletion of the second digital key K2.

[0154] Then, when the management server 70 receives the deletion request D61 from the owner device 40, it performs step S122. In step S122, the management server 70 selects multiple shared devices 50 as the destination for the deletion instruction D62. The deletion instruction D62 is an instruction that causes the shared device 50 to delete the shared key KS registered in that shared device 50. Sending the deletion instruction D62 is one step in the deletion process DEL.

[0155] As the destination of the deletion instruction D62, the management server 70 selects the object shared device 50T that is registered with the shared key KS specified in the deletion request D61.

[0156] The shared key KS specified in deletion request D61 is the second digital key K2. The second digital key K2 is registered in the second device 30B. Therefore, as... Figure 11As shown, the second device 30B is the object sharing device 50T. The management server 70 selects the second device 30B, which is the object sharing device 50T, as the destination of the deletion instruction D62. In addition, as the destination of the deletion instruction D62, the management server 70 also selects a shared device 50 that has a shared key KS registered after the second digital key K2, which is directly related to the second digital key K2 registered on the second device 30B. The management server 70 selects the shared device 50 that has a shared key KS, which is directly related to the second digital key K2, by referring to the vehicle 20 data DA stored in the database DB of the management server 70.

[0157] It should be noted that when the management server 70 receives a deletion request D61 from a device 30 other than the owner device 40 or the vehicle 20, it will only select the object sharing device 50T as the destination of the deletion instruction D62. The following will explain the shared keys KS that are directly related to the second digital key K2 after the second digital key K2.

[0158] <Data on vehicle 20 stored in the database DB of management server 70>

[0159] Figure 11 This is data DA for a vehicle 20 stored in database DB on management server 70. For a vehicle 20, this describes the status of digital keys registered with 11 devices 30. The 11 devices 30 are: device 30A, device 30B, device 30C, device 30D, device 30E, device 30F, device 30G, device 30H, device 30I, device 30J, and device 30K.

[0160] The digital key registered in the first device 30A is designated as the first digital key K1. The storage device 37 of the first device 30A stores the first key information DK1. The digital key registered in the second device 30B is designated as the second digital key K2. The storage device 37 of the second device 30B stores the second key information DK2. The digital key registered in the third device 30C is designated as the third digital key K3. The storage device 37 of the third device 30C stores the third key information DK3. The digital key registered in the fourth device 30D is designated as the fourth digital key K4. The storage device 37 of the fourth device 30D stores the fourth key information DK4. The digital key registered in the fifth device 30E is designated as the fifth digital key K5. The storage device 37 of the fifth device 30E stores the fifth key information DK5. The digital key registered in the sixth device 30F is designated as the sixth digital key K6. The storage device 37 of the sixth device 30F stores the sixth key information DK6. The digital key registered in the seventh device 30G is designated as the seventh digital key K7. The storage device 37 of the seventh device 30G stores the seventh key information DK7. The digital key registered in the eighth device 30H is set as the eighth digital key K8. The storage device 37 of the eighth device 30H stores the eighth key information DK8. The digital key registered in the ninth device 30I is set as the ninth digital key K9. The storage device 37 of the ninth device 30I stores the ninth key information DK9. The digital key registered in the tenth device 30J is set as the tenth digital key K10. The storage device 37 of the tenth device 30J stores the tenth key information DK10. The digital key registered in the eleventh device 30K is set as the eleventh digital key K11. The storage device 37 of the eleventh device 30K stores the eleventh key information DK11.

[0161] <Types of Digital Keys>

[0162] In data DA, the device 30 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 K1 is the owner key KO.

[0163] In the data DA, the devices 30 registered as shared key KS are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K. That is, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K are shared devices 50.

[0164] The second digital key K2, the third digital key K3, the fourth digital key K4, the fifth digital key K5, the sixth digital key K6, the seventh digital key K7, the eighth digital key K8, the ninth digital key K9, the tenth digital key K10, and the eleventh digital key K11 are all shared keys KS.

[0165] The second key information DK2, the third key information DK3, the fourth key information DK4, the fifth key information DK5, the sixth key information DK6, the seventh key information DK7, the eighth key information DK8, the ninth key information DK9, the tenth key information DK10, and the eleventh key information DK11 are all shared key information DKS. More specifically, in the data DA, devices 30 registered as friend keys 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, devices 30 registered as non-friend keys KN are the third device 30C, the fourth device 30D, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K. That is, the third device 30C, the fourth device 30D, the sixth device 30F, the seventh device 30G, the eighth device 30H, the ninth device 30I, the tenth device 30J, and the eleventh device 30K are non-friend devices 52.

[0166] <Regarding the relationship between the 30 equipment units>

[0167] In data DA, the relationship between the second device 30B and the first device 30A is based on a registration request from the first device 30A, where a friend key KF is registered in the second device 30B. That is, the second digital key K2 is registered based on the first digital key K1. In this case, the second digital key K2 is a digital key that is a generation later than the first digital key K1 in a direct lineage.

[0168] In data DA, the relationship between the fifth device 30E and the first device 30A is based on a registration request from the first device 30A, whereby the fifth device 30E has a registered friend key KF. That is, the fifth digital key K5 is registered based on the first digital key K1. In this case, the fifth digital key K5 is a digital key that is a generation later than the first digital key K1 in a direct lineage.

[0169] In data DA, the relationship between the third device 30C and the second device 30B is based on a registration request from the second device 30B, where a non-friend key KN is registered in the third device 30C. That is, the third digital key K3 is registered based on the second digital key K2. In this case, the third digital key K3 is a digital key that is a direct descendant of the second digital key K2 (1 generation later). The third digital key K3 is also a digital key that is a direct descendant of the first digital key K1 (2 generations later).

[0170] In data DA, the relationship between the fourth device 30D and the second device 30B is based on a registration request from the second device 30B, where a non-friend key KN is registered on the fourth device 30D. That is, the fourth digital key K4 is registered based on the second digital key K2. In this case, the fourth digital key K4 is a digital key that is a direct descendant of the second digital key K2 for one generation. The fourth digital key K4 is also a digital key that is a direct descendant of the first digital key K1 for two generations.

[0171] In data DA, the relationship between the sixth device 30F and the fifth device 30E is based on a registration request from the fifth device 30E, where a non-friend key KN is registered on the sixth device 30F. That is, the sixth digital key K6 is registered based on the fifth digital key K5. In this case, the sixth digital key K6 is a digital key that is a direct descendant of the fifth digital key K5 for one generation. The sixth digital key K6 is also a digital key that is a direct descendant of the first digital key K1 for two generations.

[0172] In data DA, the relationship between the seventh device 30G and the fifth device 30E is based on a registration request from the fifth device 30E, where a non-friend key KN is registered in the seventh device 30G. That is, the seventh digital key K7 is registered based on the fifth digital key K5. In this case, the seventh digital key K7 is a digital key that is a direct descendant of the fifth digital key K5 for one generation. The seventh digital key K7 is also a digital key that is a direct descendant of the first digital key K1 for two generations.

[0173] In data DA, the relationship between the eighth device 30H and the third device 30C is based on a registration request from the third device 30C, where a non-friend key KN is registered in the eighth device 30H. That is, the eighth digital key K8 is registered based on the third digital key K3. In this case, the eighth digital key K8 is a digital key that is a direct descendant of the third digital key K3 for one generation. The eighth digital key K8 is a digital key that is a direct descendant of the second digital key K2 for two generations. The eighth digital key K8 is a digital key that is a direct descendant of the first digital key K1 for three generations.

[0174] In data DA, the relationship between the ninth device 30I and the fourth device 30D is based on a registration request from the fourth device 30D, where a non-friend key KN is registered on the ninth device 30I. That is, the ninth digital key K9 is registered based on the fourth digital key K4. In this case, the ninth digital key K9 is a digital key that is a direct descendant of the fourth digital key K4 for one generation. The ninth digital key K9 is a digital key that is a direct descendant of the second digital key K2 for two generations. The ninth digital key K9 is a digital key that is a direct descendant of the first digital key K1 for three generations.

[0175] In data DA, the relationship between the tenth device 30J and the sixth device 30F is based on a registration request from the sixth device 30F, where a non-friend key KN is registered in the tenth device 30J. That is, the tenth digital key K10 is registered based on the sixth digital key K6. In this case, the tenth digital key K10 is a digital key that is a direct descendant of the sixth digital key K6 for one generation. The tenth digital key K10 is a digital key that is a direct descendant of the fifth digital key K5 for two generations. The tenth digital key K10 is a digital key that is a direct descendant of the first digital key K1 for three generations.

[0176] In data DA, the relationship between the eleventh device 30K and the seventh device 30G is based on a registration request from the seventh device 30G, where a non-friend key KN is registered in the eleventh device 30K. That is, the eleventh digital key K11 is registered based on the seventh digital key K7. In this case, the eleventh digital key K11 is a digital key that is directly related to the seventh digital key K7 by one generation. The eleventh digital key K11 is a digital key that is directly related to the fifth digital key K5 by two generations. The eleventh digital key K11 is a digital key that is directly related to the first digital key K1 by three generations.

[0177] <Regarding digital keys in direct family relationships>

[0178] All digital keys registered one generation or more after the digital key registered based on a request from the first digital key K1 are digital keys directly related to the first digital key K1. That is, in Figure 11 In the relationship diagram shown, digital keys other than the first digital key K1 are digital keys that are directly related to the first digital key K1 by at least one generation.

[0179] All digital keys registered one generation or more after the digital key registered based on a request from the second digital key K2 are digital keys that are directly related to the second digital key K2. That is, in Figure 11In the relationship diagram shown, the third digital key K3, the fourth digital key K4, the eighth digital key K8, and the ninth digital key K9 are digital keys that are one generation or more directly related to the second digital key K2.

[0180] As the destination of the deletion instruction D62, the management server 70 selects the shared device 50 that has a shared key KS registered after the second digital key K2, which is directly related to the second digital key K2. That is, the management server 70 selects the second device 30B, the third device 30C, the fourth device 30D, the eighth device 30H, and the ninth device 30I as the destinations for the deletion instruction D62. The shared key KS registered in the shared device 50 that becomes the destination of the deletion instruction D62 is the shared key KS that is the object of the deletion process DEL.

[0181] The third digital key K3 and the fourth digital key K4, registered based on a request from object-sharing device 50T, belong to the first generation, based on object-sharing device 50T. The eighth digital key K8 and the ninth digital key K9, registered based on requests from third device 30C and fourth device 30D, respectively, which have shared keys KS registered based on requests from object-sharing device 50T, belong to the second generation, based on object-sharing device 50T. Deletion process DEL includes deleting shared keys KS from the first generation and beyond that which are directly related to shared keys KS registered for object-sharing device 50T.

[0182] <Shared key KS set as a protected object>

[0183] The management system 10 is configured to individually designate shared keys KS as protected objects. The management server 70 does not send deletion instructions D62 to shared devices 50 that have shared keys KS designated as protected objects. That is, the management server 70 does not perform deletion processing DEL on shared keys KS designated as protected objects.

[0184] For example, a user of vehicle 20 can set the shared key KS as a protected object via HMI 22 of vehicle 20. For example, a user of owner device 40 can set the shared key KS as a protected object via HMI 32 of owner device 40. For example, a user of shared device 50 can set the shared key KS as a protected object via HMI 32 of shared device 50.

[0185] After selecting multiple shared devices 50 as the destinations for the deletion command D62, the management server 70 determines whether the shared key KS of the protected object is registered in each of the selected shared devices 50 as the destinations for the deletion command D62. Figure 12 The processing is shown.

[0186] exist Figure 12 In step S210 shown, the management server 70 determines whether the shared key KS of the protected object is registered in the shared device 50, which is selected as the destination of the deletion instruction D62.

[0187] If a shared device 50 selected as the destination for deletion instruction D62 has a shared key KS that is set as a protected object registered therein (step S210: Yes), the management server 70 proceeds to step S211. In step S211, the management server 70 excludes the shared device 50 with the shared key KS that is set as a protected object from the destinations of deletion instruction D62. Then, the management server 70 ends. Figure 12 The series of processes shown.

[0188] If the shared device 50, selected as the destination for deletion instruction D62, does not have a shared key KS set as a protected object registered (step S210: No), the management server 70 proceeds to step S212. In step S212, the management server 70 maintains the state of selecting the shared device 50 as the destination for deletion instruction D62. Then, the management server 70 ends. Figure 12 The series of processes shown.

[0189] Management server 70 executes the command once on each of the 50 shared devices selected as the destination for deletion command D62. Figure 12 After the processing shown, the process enters... Figure 10 The steps S123 are shown.

[0190] <Confirmation of the generation and transmission of request D63>

[0191] In step S123, the management server 70 generates a confirmation request D63. Confirmation request D63 is a request to set the shared key KS of the respondent as a protected object. Confirmation request D63 contains a list 81 of multiple shared keys KS that are the objects for which deletion processing DEL is performed. Specifically, it includes... Figure 13 The list 81 shows multiple shared keys KS registered to the shared device 50, which is the destination of the deletion instruction D62. The confirmation request D63 contains a request to set a shared key KS listed in list 81 as a protected object. The confirmation request D63 also contains digital key identification information ST3 corresponding to each shared key KS listed in list 81. The management server 70 sends the confirmation request D63 to the owner device 40, which is the source of the deletion request D61.

[0192] Then, if the owner device 40 receives the confirmation request D63, the owner device 40 performs... Figure 10 The process in step S124 is shown. In step S124, as... Figure 13 As shown, the owner device 40 displays a list 81 and an image of the shared key KS set as the protected object in the shared key KS listed in list 81 on the HMI 32.

[0193] Figure 13 This is an example of a list 81 displayed on the HMI 32 of the owner device 40 and an image of the shared key KS set as a protected object in the shared key KS listed in list 81.

[0194] The user of the owner device 40 follows the prompts given to the HMI 32 to select the shared key KS to be protected. Specifically, the user checks the horizontal checkbox CB for the shared key KS they want to protect in the list 81 displayed on the HMI 32. If the user wants to protect the second digital key K2, the user checks the first checkbox 82. If the user wants to protect the third digital key K3, the user checks the second checkbox 83. If the user wants to protect the fourth digital key K4, the user checks the third checkbox 84. If the user wants to protect the eighth digital key K8, the user checks the fourth checkbox 85. If the user wants to protect the ninth digital key K9, the user checks the fifth checkbox 86.

[0195] When the user presses "OK", the shared key KS with the corresponding checkbox CB checked is selected as the shared key KS set as the protected object. Then, the owner device 40 initiates processing. Figure 10 Step S125 is shown below. The following describes the case where the user of the owner device 40 selects the fourth digital key K4 as the protected object by checking the third checkbox 84.

[0196] In step S125, the owner device 40 generates a response notification M61. The response notification M61 contains digital key identification information ST3 representing the shared key KS selected as the protected object, as answered by the user of the owner device 40 in step S124. Specifically, the response notification M61 contains digital key identification information ST3 representing the fourth digital key K4. Then, the owner device 40 sends the response notification M61 to the management server 70.

[0197] Then, when the management server 70 receives the response notification M61, the management server 70 performs the processing in step S126. In step S126, based on the digital key identification information ST3 contained in the response notification M61, the management server 70 sets the fourth digital key K4 as the digital key of the protected object. The management server 70 excludes the fourth device 30D, which is registered with the fourth digital key K4 set as the protected object, from the destination of the deletion instruction D62. Then, the management server 70 determines the shared devices 50 other than the fourth device 30D among those selected as the destination of the deletion instruction D62 in step S122 as the destination of the deletion instruction D62. Specifically, the management server 70 determines the second device 30B, the third device 30C, the eighth device 30H, and the ninth device 30I as the destination of the deletion instruction D62. Then, the management server 70 causes the process to proceed to step S127.

[0198] <Generation of deletion command D62>

[0199] In step S127, the management server 70 generates a deletion instruction D62 to be sent to the second device 30B, the third device 30C, the eighth device 30H, and the ninth device 30I. Then, the management server 70 causes the process to proceed to step S128.

[0200] <Generation of deletion command D64>

[0201] In step S128, the management server 70 generates a deletion instruction D64, which deletes multiple authentication information AT representing the shared key KS specified in the deletion request D61, and the shared keys KS of subsequent generations directly related to the shared key. Specifically, the deletion instruction D64 includes the authentication information AT representing the second digital key K2 specified in the deletion request D61, and the authentication information AT representing the shared keys KS of subsequent generations directly related to the second digital key K2, namely the authentication information AT representing the third digital key K3, the authentication information AT representing the eighth digital key K8, and the authentication information AT representing the ninth digital key K9. It should be noted that the deletion instruction D64 does not include the information to delete the authentication information AT representing the digital key set as the protected object. That is, the deletion instruction D64 does not include the information to delete the authentication information AT representing the fourth digital key K4. After generating the deletion instruction D64, the management server 70 proceeds to step S129.

[0202] The authentication information AT represents information about the digital key. Therefore, the deletion instruction D64 is an instruction to delete all subsequent shared keys KS that are directly related to the shared key KS registered in the object sharing device 50T.

[0203] Sending the deletion command D62

[0204] In step S129, as Figure 14 As shown, the management server 70, acting as the deletion process DEL, sends the deletion command D62 to the second device 30B, the third device 30C, the eighth device 30H, and the ninth device 30I.

[0205] Subsequently, when the sharing device 50 receives the deletion instruction D62, it deletes the registered shared key KS according to the deletion instruction D62. Specifically, the second device 30B, which receives the deletion instruction D62, deletes the second key information DK2 stored in its storage device 37. The third device 30C, which receives the deletion instruction D62, deletes the third key information DK3 stored in its storage device 37. The eighth device 30H, which receives the deletion instruction D62, deletes the eighth key information DK8 stored in its storage device 37. The ninth device 30I, which receives the deletion instruction D62, deletes the ninth key information DK9 stored in its storage device 37. Afterward, each sharing device 50 sends a deletion completion notification to the management server 70 indicating that the deletion of the key information DK is complete.

[0206] Then, when management server 70 receives the notification that the deletion is complete, management server 70 stores the history of the deleted key information DK in each shared device 50. Then, management server 70 initiates processing. Figure 10 The step S130 shown.

[0207] Sending the delete command D64

[0208] In step S130, as Figure 14 As shown, management server 70 sends deletion instruction D64 to vehicle 20 as a deletion process DEL. Upon receiving deletion instruction D64, vehicle 20 deletes multiple authentication information ATs according to the deletion instruction D64. Afterwards, vehicle 20 sends a deletion completion notification to management server 70 indicating that the deletion of multiple authentication information ATs is complete. Then, when management server 70 receives the deletion completion notification, management server 70 stores the history of the deleted authentication information ATs in vehicle 20. Then, management server 70 initiates processing... Figure 10 The step S131 shown.

[0209] <Database DB Update>

[0210] In step S131, as Figure 14As shown, the management server 70 updates the database DB as a deletion process DEL. That is, the management server 70 deletes from the vehicle 20's data DA the information of the shared device 50 registered with the shared key KS specified in the deletion request D61, and the information of shared devices 50 indicating that they are registered with subsequent generations of shared keys KS directly related to the shared key. Specifically, the management server 70 deletes from the vehicle 20's data DA the information of the second device 30B indicating that it is registered with the second digital key K2 specified in the deletion request D61, and the information of multiple shared devices 50 indicating that they are registered with subsequent generations of shared keys KS directly related to the second digital key K2, namely, the information of the third device 30C indicating that it is registered with the third digital key K3, the information of the eighth device 30H indicating that it is registered with the eighth digital key K8, and the information of the ninth device 30I indicating that it is registered with the ninth digital key K9. It should be noted that the management server 70 does not delete from the vehicle 20's data DA the information of shared devices 50 indicating that they are registered with digital keys for protected objects. That is, the management server 70 does not delete the information indicating that the fourth device 30D is registered with the fourth digital key K4 from the data DA of the vehicle 20. After that, the management system 10 ends a series of processes based on the deletion request D61 regarding the deletion of multiple shared keys KS.

[0211] <The function of this implementation method>

[0212] The user who sent deletion request D61 is highly likely to want to delete the shared key KS registered with the object sharing device 50T, in addition to the shared key KS registered with the object sharing device 50T. Upon receiving deletion request D61, the management server 70, as a deletion process DEL, sends deletion instruction D62 to the second device 30B, which is the object sharing device 50T. Furthermore, as a deletion process DEL, the management server 70 also sends deletion instruction D62 to other sharing devices 50 that have registered shared key KS based on requests from the object sharing device 50T, namely the third device 30C, the eighth device 30H, and the ninth device 30I.

[0213] Furthermore, as a deletion process DEL, the aforementioned management server 70 sends a deletion command D64 to vehicle 20. Further, as a deletion process DEL, the aforementioned management server 70 updates the data DA of vehicle 20 in the database DB.

[0214] <Effects of this implementation method>

[0215] (1) According to the management server 70 described above, multiple digital keys can be deleted at the same time even if the user does not select the digital key to be deleted individually. Therefore, the load on the user in the operation of deleting multiple digital keys is reduced.

[0216] (2) The management server 70 sends a deletion instruction D62 to the shared device 50 that has a direct lineage to the shared key KS registered on the object sharing device 50T, and to any subsequent generation of shared keys KS that are directly related to the shared key KS registered on the object sharing device 50T. The user who sent the deletion request D61 is highly likely to also want to delete the shared key KS from the shared device 50 that has a direct lineage to the shared key KS registered on the object sharing device 50T, and to any subsequent generation of shared keys KS that are directly related to the second digital key K2 registered on the second device 30B, which is the object sharing device 50T. This further reduces the burden on users who want to delete multiple shared keys KS.

[0217] (3) The management server 70 is configured to set a shared key KS as a protected object. The management server 70 does not send a deletion command D62 to the shared device 50 that has the shared key KS set as a protected object registered. That is, the management server 70 does not perform the deletion process DEL on the shared key KS set as a protected object. Users who have sent deletion requests D61 sometimes do not want to delete the shared key KS registered in other shared devices 50 based on requests from the object shared device 50T. By being able to set the shared key KS as a protected object, the management server 70 can protect the shared key KS from the effects of the deletion command D62.

[0218] (4) Upon receiving the deletion request D61, the aforementioned management server 70 sends a message to the owner device 40, which is the source of the deletion request D61. Figure 13 The list 81 shown represents the list of shared keys KS registered in the multiple shared devices 50 that are the destination of the deletion instruction D62. List 81 is a list of multiple shared keys KS that are the objects of the deletion process DEL. Thus, the management server 70 enables the user who sent the deletion request D61 to have access to the deleted shared keys KS.

[0219] (5) Upon receiving the deletion request D61, the aforementioned management server 70 causes the user who sent the deletion request D61 to reply that the page is located on [the specified location]. Figure 13The shared key KS in the list 81 shown is set as the protected object. Therefore, the management server 70 can reflect the user's intention to remove the shared key KS protected by deletion command D62 and determine the shared device 50 as the destination of deletion command D62.

[0220] (6) The aforementioned management server 70 sends a deletion instruction D62, which is a deletion process DEL, to the second device 30B (the object sharing device 50T) and other sharing devices 50 that have registered shared keys KS based on the request from the second device 30B, only when it receives a deletion request D61 from the owner device 40. If a user other than the user of the owner device 40 deletes multiple shared keys KS without restriction, it may hinder the use of the vehicle 20 that uses a digital key. The aforementioned management server 70 sends a deletion instruction D62 to multiple sharing devices 50 only when it receives a deletion request D61 from the owner device 40. The aforementioned management server 70 can prevent users other than the user of the owner device 40 from abusing the function of deleting multiple shared keys KS based on a single deletion request D61.

[0221] (7) The above-mentioned management system 10 includes: a vehicle 20; multiple digital keys that can be used relative to the vehicle 20, including an owner key KO registered for the owner device 40BO, which is the owner of the vehicle 20, and a shared key KS registered for a shared device 50, which is a device 30 different from the owner device 40; and a management server 70 for managing the multiple digital keys. When the management server 70 receives a deletion request D61 specifying a registered shared key KS, it executes a deletion process DEL, in which the shared key KS registered in the object shared device 50T, which is registered with the shared key KS specified in the received deletion request D61, and in other shared devices 50 that have registered shared keys KS based on requests from the object shared device 50T. With the above-mentioned management system 10, multiple digital keys can be deleted at the same time even if the user does not select the digital key to be deleted individually. Therefore, the above-mentioned management system 10 can reduce the load on the user in the operation of deleting multiple digital keys.

[0222] (8) The management server 70 manages multiple digital keys that can be used relative to the vehicle 20, including an owner key KO and a shared key KS. The owner key KO is registered for the device 30, i.e., owner device 40, belonging to the owner of the vehicle 20, and the shared key KS is registered for a shared device 50, which is a device 30 different from the owner device 40. The management server 70 includes an execution device 71 as a processing circuit. The method for deleting a digital key executed by the management server 70 includes, upon receiving a deletion request D61 specifying a registered shared key KS, the execution device 71 of the management server 70 generates an instruction to delete the registered shared key KS, i.e., a deletion instruction D62 (step S127). The method for deleting a digital key executed by the management server 70 includes, a step of generating a deletion instruction D64 (step S128), which is an instruction to delete a shared key KS that is directly related to the shared key KS specified in the received deletion request D61. The digital key deletion method executed by the management server 70 includes the execution device 71 of the management server 70 performing a deletion process DEL (steps S129, S130, and S131). In this deletion process DEL, the shared key KS registered in the object sharing device 50T (i.e., the second device 30B) that has the shared key KS specified in the received deletion request D61, and in other sharing devices 50 that have registered the shared key KS based on a request from the second device 30B, are deleted. By executing such a digital key deletion method, the management server 70 can delete multiple digital keys at once, even if the user does not individually select the digital key to be deleted. Therefore, the burden on the user in the operation of deleting multiple digital keys is reduced.

[0223] (9) The storage device 72 of the management server 70 stores a deletion program PM that causes the execution device 71 of the management server 70 to perform processing. When the management server 70 receives a deletion request D61 specifying a registered shared key KS, the deletion program PM causes the execution device 71 of the management server 70 to perform a process to generate a deletion instruction D62, which is an instruction to delete the registered shared key KS. The deletion program PM causes the execution device 71 of the management server 70 to perform a process to generate a deletion instruction D64, which is an instruction to delete the shared key KS that is directly related to the shared key KS specified in the received deletion request D61. The deletion procedure PM causes the execution device 71 of the management server 70 to execute the deletion process DEL. In this deletion process DEL, the shared key KS registered in the object shared device 50T (i.e., the second device 30B) that holds the shared key KS specified in the received deletion request D61, and in other shared devices 50 that hold the shared key KS based on a request from the second device 30B, are deleted. Therefore, even if the user does not individually select the digital key to be deleted, the management server 70 can delete multiple digital keys at once. This reduces the load on the user during the deletion of multiple digital keys.

[0224] <Example of Change>

[0225] This embodiment can be implemented by modification as follows. This embodiment and the following modifications can be combined with each other within the scope of technical inconsistency.

[0226] <Regarding the deletion process DEL>

[0227] In step S129, management server 70 performs the deletion process DEL, sending deletion command D62 to multiple shared devices 50. In step S130, management server 70 performs the deletion process DEL, sending deletion command D64 to vehicle 20. In step S131, management server 70 performs the deletion process DEL, updating the database DB stored by management server 70. Management server 70 can be configured to perform one or more of these three processes as deletion process DEL. For example, as deletion process DEL, management server 70 may only perform the process of sending deletion command D62 to multiple shared devices 50. As deletion process DEL, management server 70 may only perform the process of sending deletion command D64 to vehicle 20. As deletion process DEL, management server 70 may only perform the process of updating the database DB stored by management server 70.

[0228] By performing any one of steps S129, S130, and S131, the management server 70 can delete multiple digital keys at once, even if the user does not individually select the digital key to be deleted. Therefore, the load on the user during the deletion of multiple digital keys is reduced.

[0229] If the management server 70 does not perform step S129, it may also omit steps S126 and S127. If the management server 70 does not perform step S130, it may also omit step S128.

[0230] If the management server 70 does not perform step S129, as a process equivalent to step S122, the management server 70 may select a shared key KS that is a direct descendant of the shared key KS registered in the object sharing device 50T. That is, as a process equivalent to step S122, the management server 70 may also choose not to select the shared device 50 that has a shared key KS that is a direct descendant of the shared key KS registered in the object sharing device 50T.

[0231] List 81 is not limited to a list of multiple shared keys KS registered in the shared device 50 that becomes the destination of the deletion instruction D62. List 81 may simply list multiple shared keys KS that are objects of the deletion process DEL. For example, List 81 may simply list shared keys KS that are directly related to the shared key KS registered in the object shared device 50T.

[0232] <Regarding the source of request D61 to be deleted>

[0233] The source of deletion request D61 is not limited to the owner device 40. For example, the source of deletion request D61 could be vehicle 20. For example, the source of deletion request D61 could be shared device 50.

[0234] The management server 70 may also be configured to, upon receiving a deletion request D61 from a shared device 50, execute a deletion process DEL if the shared key KS specified in the received deletion request D61 is directly related to the shared key KS registered in the shared device 50 that is the source of the deletion request D61, and is a subsequent generation of the shared key KS registered in the shared device 50 that is the source of the deletion request D61. In this deletion process DEL, the shared key KS registered in the object shared device 50T that has the shared key KS specified in the received deletion request D61, and in other shared devices 50 that have registered the shared key KS based on a request from the object shared device 50T, are deleted.

[0235] like Figure 11 As shown, the third digital key K3 registered in the third device 30C and the eighth digital key K8 registered in the eighth device 30H are shared keys KS that are directly related to the second digital key K2 registered in the second device 30B. The third digital key K3 and the eighth digital key K8 are digital keys that follow the second digital key K2. When the management server 70 receives a deletion request D61 from the second device 30B, and the shared key KS specified in the deletion request D61 is the third digital key K3, it will... Figure 10 In the process corresponding to step S122, the shared device 50, which sends the deletion instruction D62 as a deletion process DEL, selects the third device 30C and the eighth device 30H. Then, in the process corresponding to step S129, the management server 70 sends the deletion instruction D62 as a deletion process DEL to the third device 30C and the eighth device 30H. As a process corresponding to step 128, the management server 70 generates a deletion instruction D64, which includes authentication information AT representing the third digital key K3 and authentication information AT representing the eighth digital key K8. As a process corresponding to step 130, the management server 70 sends the deletion instruction D64 to the vehicle 20. As a process corresponding to step S131, the management server 70 deletes the information representing the third device 30C registered with the third digital key K3 and the information representing the eighth device 30H registered with the eighth digital key K8 from the data DA of the vehicle 20.

[0236] like Figure 11 As shown, the fifth device 30E is a shared device 50 that is not directly related to the second device 30B. When the management server 70 receives a deletion request D61 from the second device 30B, and the deletion request D61 specifies the fifth digital key K5, it will... Figure 10In the process corresponding to step S122, the fifth device 30E is not selected as the shared device 50 to send the deletion command D62. Then, the management server 70 does not generate the deletion command D62 in the process corresponding to step S127. The management server 70 does not generate the deletion command D64 in the process corresponding to step S128. The management server 70 does not send the deletion command D62 to the shared device 50 in the process corresponding to step S129. The management server 70 does not send the deletion command D64 to the vehicle 20 in the process corresponding to step S130. The management server 70 does not update the database DB in the process corresponding to step S131. That is, the management server 70 does not execute the deletion process DEL.

[0237] like Figure 11 As shown, the sixth device 30F is a shared device 50 that is directly related to the fifth device 30E. The fifth device 30E is a digital key of a generation higher than the sixth device 30F. When the management server 70 receives a deletion request D61 from the sixth device 30F, and the deletion request D61 specifies the fifth digital key K5, it will... Figure 10 In the process corresponding to step S122, the fifth device 30E is not selected as the shared device 50 to send the deletion command D62. Then, in the process corresponding to step S127, the management server 70 does not generate the deletion command D62. In the process corresponding to step S128, the management server 70 does not generate the deletion command D64. In the process corresponding to step S129, the management server 70 does not send the deletion command D62 to the shared device 50. In the process corresponding to step S130, the management server 70 does not send the deletion command D64 to the vehicle 20. In the process corresponding to step S131, the management server 70 does not update the database DB. That is, the management server 70 does not execute the deletion process DEL.

[0238] If a user of the sharing device 50 deletes a shared key KS that is not directly related to the shared key KS registered in the sharing device 50, it may prevent the use of the vehicle 20 using the digital key. Similarly, if a user of the sharing device 50 deletes a shared key KS that is older than the shared key KS registered in the sharing device 50, it may prevent the use of the vehicle 20 using the digital key.

[0239] The aforementioned management server 70 can reduce the possibility of hindering the use of the vehicle 20 that uses a digital key due to the abuse of the function of deleting multiple shared keys KS based on a deletion request D61 by the user of the shared device 50.

[0240] <Cases where multiple digital keys are registered in a shared device 50>

[0241] • In the management system 10, it is possible for multiple digital keys to be registered in a shared device 50. Figure 15 This is data DA of a vehicle 20 stored in database DB on management server 70. For example... Figure 15 As shown, a first non-friend key KN1 and a second non-friend key KN2 are registered in the twelfth device 30L. The storage device 37 of the twelfth device 30L stores first non-friend key information DKN1 representing the first non-friend key KN1. The storage device 37 of the twelfth device 30L stores second non-friend key information DKN2 representing the second non-friend key KN2. The first device 30A, the second device 30B, the third device 30C, the fifth device 30E, and the sixth device 30F... Figure 11 same.

[0242] The relationship between the twelfth device 30L and the third device 30C is based on a registration request from the third device 30C, whereby the twelfth device 30L has registered a first non-friend key KN1. That is, the first non-friend key KN1 is registered based on the third digital key K3. In this case, the first non-friend key KN1 is a digital key that is directly related to the third digital key K3 by one generation. The first non-friend key KN1 is a digital key that is directly related to the second digital key K2 by two generations. The first non-friend key KN1 is a digital key that is directly related to the first digital key K1 by three generations.

[0243] The relationship between the twelfth device 30L and the sixth device 30F is based on a registration request from the sixth device 30F, where the second non-friend key KN2 is registered in the twelfth device 30L. That is, the second non-friend key KN2 is registered based on the sixth digital key K6. In this case, the second non-friend key KN2 is a digital key that is one generation removed from the sixth digital key K6. The second non-friend key KN2 is a digital key that is one generation removed from the fifth digital key K5. The second non-friend key KN2 is a digital key that is three generations removed from the first digital key K1.

[0244] The following explains the case where the shared key KS specified in deletion request D61 is the second digital key K2. In this case, the management server 70... Figure 10In step S122, the shared device 50T, which serves as the destination for the deletion instruction D62, is the second device 30B, which is registered with the second digital key K2. In addition, the management server 70 also sets shared devices 50 that are registered with shared keys KS that are directly related to the second digital key K2. That is, the management server 70 sets the second device 30B, the third device 30C, and the twelfth device 30L as the destinations for the deletion instruction D62.

[0245] In this modified example, the deletion instruction D62 is an instruction to delete any shared key KS that is directly related to the shared key KS registered in the object sharing device 50T and is a successor to the shared key KS. That is, the deletion process DEL in this modified example is a process to delete any shared key KS that is directly related to the shared key KS registered in the object sharing device 50T and is a successor to the shared key KS.

[0246] Specifically, in this modified example, deletion instruction D62 is an instruction to delete the shared key KS that is directly related to the second digital key K2 registered in the second device 30B, which is the object sharing device 50T, and is a generation after the second digital key K2. Therefore, upon receiving deletion instruction D62, the twelfth device 30L deletes the shared key KS, i.e., the first non-friend key KN1, that is directly related to the second digital key K2 and is a generation after the second digital key K2. Specifically, the twelfth device 30L deletes the first non-friend key information DKN1 stored in the storage device 37 of the twelfth device 30L. The second non-friend key information DKN2 stored in the storage device 37 of the twelfth device 30L is not deleted by deletion instruction D62.

[0247] In the case where multiple shared keys KS are registered in a shared device 50, the aforementioned management server 70 can delete shared keys KS that are directly related to the shared key KS specified in the deletion request D61 and are subsequent generations of that shared key KS.

[0248] <Regarding Confirmation Request D63>

[0249] • Management server 70 can also, upon receiving deletion request D61, replace confirmation request D63 and only delete... Figure 13 List 81 shown is sent to the source of deletion request D61. Management server 70 may also choose not to send confirmation request D63 to the source of deletion request D61 upon receiving deletion request D61. Management server 70 may also choose not to generate confirmation request D63 upon receiving deletion request D61.

[0250] <Regarding the shared key KS set as a protected object>

[0251] • The management server may not be configured to be a shared key KS that can be set as a protected object.

[0252] <Regarding the checkboxes displayed in HMI32>

[0253] ·like Figure 13 As shown, a checkbox CB is displayed next to the shared key KS listed in list 81 on the HMI 32 of the owner device 40 after receiving confirmation request D63. By performing an operation in the owner device 40 specifying the registered shared key KS and requesting deletion, the owner device 40 generates a deletion request D61 specifying the registered shared key KS. Therefore, confirmation request D63 can also be configured such that the checkbox CB is not displayed next to the shared key KS specified in deletion request D61. For example, if the shared key KS specified in deletion request D61 is the second digital key K2, confirmation request D63 can also be configured such that... Figure 13 The first checkbox 82 is not displayed next to "Second Digital Key" in the list 81 shown.

[0254] <Management System 10>

[0255] Vehicle 20 may not include any of the BLE module 23, UWB module 24, and NFC module 25. Vehicle 20 can communicate with device 30 near range as long as it has at least one of these modules. Alternatively, vehicle 20 is not limited to these modules; it only needs to have a module for near range communication with device 30.

[0256] • The digital key-related matters in the above embodiments may also be not based on CCC.

[0257] The vehicle management device 26 can also be configured as a circuit including one or more processors that perform various processes according to a computer program (software). It should be noted that the vehicle management device 26 can also be configured as a circuit including one or more application-specific integrated circuits (ASICs) or combinations thereof that perform at least a portion of the various processes. The processor includes a CPU, RAM, ROM, and other memories. The memories store program code or instructions configured to cause the CPU to perform processes. Memory, i.e., computer-readable storage media, includes any available storage media accessible to general-purpose or special-purpose computers. This also applies to device 30 and management server 70.

[0258] • The vehicle management device 26 is not limited to the digital key ECU. For example, it could also be a central ECU that manages multiple ECUs of the vehicle 20.

[0259] • Device 30 is not limited to smartphones. It could also be a smartwatch. Additionally, device 30 could also be a designated server. In this case, the designated server could include device 30. For example, if the rental operator or sharing operator is the owner of vehicle 20, the owner's device 40 could also be included in the designated server. Furthermore, for example, a friend's device 51 could also be included in the designated server.

[0260] The device server 60 does not necessarily need to be configured for each category of device 30. As long as multiple devices 30 can communicate wirelessly with the management server 70, it is sufficient. Alternatively, the device server 60 can be omitted entirely; as long as multiple devices 30 can communicate directly with the management server 70, it is sufficient.

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

[0262] • Management server 70 may not store database DB. Management server 70 can be configured to use at least one digital key in management system 10, a combination of key information DK from management device 30 and authentication information AT from vehicle management device 26.

[0263] <Regarding various information>

[0264] The authentication information AT is not limited to the examples of the above embodiments, as long as it is used to authenticate the digital key when using the digital key. For example, the authentication information AT could also be a shared key common to the vehicle management device 26 and the device 30. Alternatively, the authentication information AT could also be a shared private key.

[0265] The structure of the information contained in the key information DK is not limited to the examples of the above embodiments. For example, the owner key information DKO may not have slot identification information ST4. Furthermore, the key information DK may also include information indicating the category of the digital key. The category of the digital key may, for example, indicate one of the owner key KO, friend key KF, and non-friend key KN.

[0266] • The database DB may also contain information indicating the category of device 30. The category of device 30 may be, for example, information indicating any of the following: smartphone, smartwatch, and server as specified in the above variation example.

[0267] The structure of the data DA in the database DB is not limited to the examples of the above implementation methods. The database DB only needs to contain the information required for management by the management server 70 in the management system 10.

[0268]

[0269] The series of processes for registering the owner key KO is not limited to the examples of the above embodiments. For example, the owner device 40 may not perform pairing based on the process in step S12. The vehicle 20 and the first device 30A receive and transmit generated data DC and other information via the management server 70, thereby storing the owner key information DKO. The series of processes for registering the owner key KO can be appropriately modified according to the structure of the information contained in the owner key information DKO and the structure of the information contained in the authentication information AT.

[0270] The process of registering the friend key KF is not limited to the examples of the above embodiments. For example, the management server 70 can update the database DB through step S29 after sending the authentication packet ATP and storage request D24 to the vehicle 20. The process of registering the friend key KF can be appropriately modified according to the structure of the information contained in the friend key information DKF and the structure of the information contained in the authentication information AT.

[0271] The process for registering a non-friend key KN is not limited to the examples in the above embodiments. The process for registering a friend key KF and the order of the process can also be different. The process for registering a non-friend key KN can be appropriately modified according to 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.

[0272] • Alternatively, the types of digital keys may not include non-friend keys KN. That is, in the management system 10, the shared key KS may only be the friend key KF.

[0273]

[0274] In this embodiment, when the friend device 51 deletes the non-friend key KN, it sends a deletion reservation D41 to the management server 70, but it may not be a reservation request. That is, the friend device 51 may also send a request to delete the non-friend key KN to the management server 70 regardless of the predetermined condition RC. In addition, not only the friend device 51, but also the management server 70 may proceed to the processing after step S62 based on the request to delete the non-friend key KN from the owner device 40.

[0275] The following explains the case where an operation to request the deletion of the non-friend key KN is performed on a non-friend device 52. In this case, the non-friend device 52 can also replace... Figure 9 In step S81, the system sends a request to the management server 70 to delete the non-friend key KN registered in the non-friend device 52. Upon receiving this request, the management server 70... Figure 8 Similarly, in step S66, a request to delete the non-friend key information DKN is generated. Then, the management server 70 sends the request to delete the non-friend key information DKN to the non-friend device 52. Upon receiving the request to delete the non-friend key information DKN, the non-friend device 52... Figure 8 The step S67 shown similarly deletes the non-friend key information DKN. Then, the non-friend device 52 sends a notification to the management server 70 indicating that the non-friend key information DKN has been deleted. Upon receiving the notification that the non-friend device 52 has deleted the non-friend key information DKN, the management server 70 performs... Figure 9 The processing after step S82 is shown. The non-friend device 52 may also choose not to send a notification to the management server 70 indicating that the non-friend key information DKN has been deleted. In this case, after sending a request to the non-friend device 52 to delete the non-friend key information DKN, the management server 70 proceeds... Figure 9 The processing after step S82 shown.

[0276] • In either the case of deletion of a non-friend key KN due to an operation by friend device 51, or the case of deletion of a non-friend key KN due to an operation by non-friend device 52, a deletion reservation can be requested to the management server 70. In the case of deletion of a friend key KF due to an operation by owner device 40, a deletion reservation can also be requested to the management server 70. In the case of deletion of a non-friend key KN due to an operation by owner device 40, a deletion reservation can also be requested to the management server 70.

[0277] The management server 70 can also send a deletion instruction to the shared device 50 that has registered a shared key KS based on the request from the shared device 50T, provided that a reservation for deletion of the object shared device 50T is requested and predetermined conditions RC are met. The predetermined conditions RC can also be set individually for each of the multiple shared devices 50 that have registered a shared key KS based on the request from the object shared device 50T.

[0278] Owner device 40 and vehicle 20 can also request the deletion of non-friend key KN. Additionally, for example, management server 70 can generate a request to delete non-friend key KN.

[0279] • The sharing device 50 has the function of receiving the shared key KS as described in the above embodiment. Like the sharing device 50, the device 30, which has the function of receiving digital keys, is sometimes referred to as a receiving device.

[0280] The management server 70 includes a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM). The management server 70 performs software processing. However, this is merely an example. For instance, the management server 70 may also have dedicated hardware circuitry for processing at least a portion of the software processing performed in the above embodiments. The dedicated hardware circuitry is, for example, an ASIC (Application Specific Integrated Circuit). That is, the management server 70 can be any of the following structures (a) to (c): (a) The management server 70 has a processing device for executing all processing according to a program and a program storage device such as a ROM for storing the program. That is, the management server 70 has a software execution device. (b) The management server 70 has a processing device for executing a portion of the processing according to a program and a program storage device. Furthermore, the management server 70 has dedicated hardware circuitry for executing the remaining processing. (c) The management server 70 has dedicated hardware circuitry for executing all processing. Here, the software execution device and / or dedicated hardware circuitry may also be multiple. That is, the above-described processing can be executed by a processing circuit that includes at least one of a software execution device and a dedicated hardware circuit. The processing circuit may include multiple software execution devices and dedicated hardware circuits. The program storage device, i.e., computer-readable medium, includes all available media, i.e., storage devices, that can be accessed by a general-purpose or special-purpose computer. The program may also be stored in a computer-readable, non-volatile data storage medium, such as a CD-ROM, and distributed as a program product. The program may also be provided as a downloadable program product by an information provider connected to a network such as the Internet.

[0281] <Postscript>

[0282] The technical ideas that can be grasped based on the above implementation methods and variations are recorded.

[0283] [Postscript 1]

[0284] A deletion method is performed by a management server configured to manage multiple digital keys for a vehicle application, wherein the multiple digital keys include: an owner key registered for a device belonging to the owner of the vehicle, i.e., an owner device; and multiple shared keys registered for multiple shared devices, each of which is a different device from the owner device.

[0285] The deletion method includes generating a deletion instruction and performing deletion processing by the processing circuitry of the management server based solely on a deletion request received from the owner's device.

[0286] The deletion request specifies one of the shared keys registered with the object shared device, i.e., one of the shared keys among the multiple shared devices.

[0287] The deletion command is an instruction to delete the shared key registered for the shared device of the object.

[0288] In the deletion process, one of the shared keys specified in the received deletion request and the shared keys registered for other shared devices based on a request from the object sharing device is deleted.

[0289] [Postscript 2]

[0290] A deletion method is performed by a management server configured to manage multiple digital keys for a vehicle application, wherein the multiple digital keys include: an owner key registered for a device belonging to the owner of the vehicle, i.e., an owner device; and multiple shared keys registered for multiple shared devices, each of which is a different device from the owner device.

[0291] The deletion method includes receiving a deletion request specifying a shared key registered to one of the plurality of shared devices, i.e., an object shared device, and wherein the shared key specified in the received deletion request is directly related to the shared key registered in the shared device that is the source of the deletion request and is a subsequent generation of the shared key registered in the shared device that is the source of the deletion request; the processing circuit of the management server generates a deletion instruction and executes the deletion process.

[0292] The deletion command is an instruction to delete the shared key registered for the shared device of the object.

[0293] In the deletion process, one of the shared keys specified in the received deletion request and the shared keys registered for other shared devices based on a request from the object sharing device is deleted.

[0294] [Postscript 3]

[0295] A deletion method is performed by a management server configured to manage multiple digital keys for a vehicle application, wherein the multiple digital keys include: an owner key registered for a device belonging to the owner of the vehicle, i.e., an owner device; and multiple shared keys registered for multiple shared devices, each of which is a different device from the owner device.

[0296] The deletion method includes generating a deletion instruction and performing deletion processing based on the processing circuitry of the management server upon receiving a deletion request.

[0297] The deletion request specifies one of the shared keys registered with the object shared device, i.e., one of the shared keys among the multiple shared devices.

[0298] The deletion instruction is an instruction to delete all subsequent shared keys that are directly related to the shared key registered for the shared device for the object.

[0299] In the deletion process, one or more shared keys are deleted, including the shared key specified in the received deletion request and any subsequent generations of shared keys that are directly related to the shared key specified in the deletion request.

[0300] [Postscript 4]

[0301] A management server configured to perform the deletion method as described in any one of Annexes 1 to 3.

[0302] [Postscript 5]

[0303] An uninstallation program product, wherein the uninstallation program product causes the processing circuitry to perform an uninstallation method as described in any one of Annexes 1 to 3.

Claims

1. A management server configured to manage multiple digital keys for vehicle applications, wherein, The plurality of digital keys includes: Owner's key, registered for the device belonging to the owner of the vehicle, i.e., owner's device registration; and Multiple shared keys are registered separately for each shared device. The multiple shared devices are all different from the owner's devices. The management server is configured to perform deletion processing upon receiving a deletion request. The deletion request specifies one of the shared keys registered with the object shared device, i.e., one of the shared keys among the multiple shared devices. In the deletion process, one of the shared keys specified in the received deletion request and the shared keys registered for other shared devices based on a request from the object sharing device is deleted.

2. The management server according to claim 1, wherein, The shared key registered for the other shared device based on a request from the object-sharing device belongs to the first generation. The shared key registered based on a request from the other shared devices belongs to the second generation. The deletion process includes deleting the first-generation or later shared keys that are directly related to the shared key registered for the shared device for the object.

3. The management server according to claim 1 or 2, wherein, The management server is configured to set a shared key as a protected object from the plurality of shared keys, and is configured not to perform the deletion process for the shared key set as the protected object.

4. The management server according to any one of claims 1 to 3, wherein, The management server is configured to send a list of two or more shared keys that are the objects of the deletion process to the source of the deletion request upon receiving the deletion request.

5. The management server according to claim 3, wherein, Upon receiving the deletion request, a list of two or more shared keys from the plurality of shared keys that become the object of the deletion process is sent to the source of the deletion request. For the two or more shared keys listed in the list, the sending source responds to which one to set as the protected object.

6. A management system comprising vehicles and a management server, The management server is configured to manage multiple digital keys for the vehicle application. These digital keys include an owner key and multiple shared keys. The owner key is registered for a device belonging to the vehicle's owner, i.e., the owner device. The multiple shared keys are registered for multiple shared devices, each of which is different from the owner device. in, The management server is configured to perform deletion processing upon receiving a deletion request. The deletion request specifies one of the shared keys registered with the object shared device, i.e., one of the shared keys among the multiple shared devices. In the deletion process, one of the shared keys specified in the received deletion request and the shared keys registered for other shared devices based on a request from the object sharing device is deleted.

7. A deletion method, performed by a management server configured to manage multiple digital keys for a vehicle application, wherein, The plurality of digital keys includes: Owner's key, registered for the device belonging to the owner of the vehicle, i.e., owner's device registration; and Multiple shared keys are registered separately for each shared device. The multiple shared devices are all different from the owner's devices. The deletion method includes generating a deletion instruction and performing deletion processing based on the processing circuitry of the management server upon receiving a deletion request. The deletion request specifies one of the shared keys registered with the object shared device, i.e., one of the shared keys among the multiple shared devices. The deletion command is an instruction to delete the shared key registered for the shared device of the object. In the deletion process, one of the shared keys specified in the received deletion request and the shared keys registered for other shared devices based on a request from the object sharing device is deleted.

8. A uninstallation program product, wherein, The deletion program product causes the processing circuit to perform the deletion method of claim 7.

Images