Management server, management method, and program product

Abstract

The invention relates to a management server, a management method, and a program product. A management server manages a plurality of digital keys applicable to a vehicle. The plurality of digital keys include a target digital key and one or more registration participation digital keys that have participated in registration of the target digital key. A plurality of digital keys are respectively registered in a plurality of devices. The plurality of devices includes a participating device to which a predetermined one of the participating registration digital keys is registered. The management server determines whether to apply a prescribed condition to delete the target digital key based on a user attribute of the participating device, and sets the target digital key to an unavailable state according to a result of the determination.

Description

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Japanese Patent Application No. 2024-125149, filed on July 31, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to a management server, management method, and program product. Background Technology

[0004] Japanese Patent Publication No. 2024-001720 describes a digital key management system. This system includes a vehicle, multiple devices, and a management server. Multiple digital keys available to the vehicle are registered separately in the multiple devices. When a digital key is used, the vehicle verifies the key and allows controls such as unlocking the vehicle.

[0005] The management server described in the above disclosure manages multiple digital keys for the same vehicle in some cases. When managing a target digital key, the management server can set the target digital key to an unavailable state if the specified conditions for deleting the target digital key are met. However, depending on how the vehicle is used, it may be desirable to set the target digital key to an unavailable state regardless of whether the specified conditions for deleting the target digital key are met. Summary of the Invention

[0006] This invention is intended to present a series of concepts in a simplified form, which will also be described in the "Detailed Description" section below. This invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to assist in determining the scope of the claimed subject matter.

[0007] In general, the management server is configured to manage multiple digital keys applicable to the vehicle. These multiple digital keys include a target digital key and one or more participating registration digital keys that have already registered the target digital key. The multiple digital keys are registered separately on multiple devices. The multiple devices include participating devices that have registered a predetermined one of the participating registration digital keys. Based on the user attributes of the participating devices, the management server determines whether to apply prescribed conditions to delete the target digital key. The management server is also configured to set the target digital key to an unavailable state based on the determination result.

[0008] In another general aspect, a management method is executed by a management server configured to manage a plurality of digital keys applicable to a vehicle. The plurality of digital keys includes a target digital key and one or more participating registration digital keys that have participated in registration of the target digital key. The plurality of digital keys is respectively registered in a plurality of devices. The plurality of devices includes a participating device that has registered a predetermined one of the participating registration digital keys. The management method includes determining whether to apply a prescribed condition to delete the target digital key based on a user attribute of the participating device, and setting the target digital key to an unusable state according to a result of the determination.

[0009] In another general aspect, a program product is configured to be executed by a management server that is a computer configured to manage a plurality of digital keys applicable to a vehicle. The plurality of digital keys includes a target digital key and one or more participating registration digital keys that have participated in registration of the target digital key. The plurality of digital keys is respectively registered in a plurality of devices. The plurality of devices includes a participating device that has registered a predetermined one of the participating registration digital keys. The program product is configured to cause the management server to execute: determining whether to apply a prescribed condition to delete the target digital key based on a user attribute of the participating device, and setting the target digital key to an unusable state according to a result of the determination.

[0010] Other features and aspects will become apparent from the following detailed description, drawings and claims. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 is a schematic diagram illustrating a management system according to an embodiment.

[0012] Figure 2 is a schematic diagram illustrating Figure 1 owner key information of the owner device illustrated.

[0013] Figure 3 is a schematic diagram illustrating Figure 1 shareable key information of each shareable device in

[0014] Figure 4 is a schematic diagram illustrating Figure 1 device-to-device relationship of data in the database illustrated.

[0015] Figure 5 is a schematic diagram illustrating information indicating Figure 1 user attributes of data in the database illustrated.

[0016] Figure 6 is an explanatory diagram illustrating a series of processes executed by Figure 1 the management system illustrated when the owner key is registered.

[0017] Figure 7 is a sequence diagram showing a series of processes performed by the management system of Figure 1 when registering a friend key.

[0018] Figure 8 is a sequence diagram showing a series of processes performed by the management system of Figure 1 when registering a guest key.

[0019] Figure 9 is a schematic diagram showing a device as a server.

[0020] Figure 10 is a sequence diagram showing a series of processes performed by the management system shown in Figure 1 when an owner key is registered in a device as a server.

[0021] Figure 11 is a sequence diagram showing a series of processes performed by the management system shown in Figure 1 when a friend key is registered in a device as a server.

[0022] Figure 12 is a sequence diagram showing a series of processes performed by the management system of Figure 1 when a guest key is deleted in response to a request from a friend device.

[0023] Figure 13 is a flowchart showing detailed processes of a pending deletion determination made by the management server shown in Figure 1 .

[0024] Figure 14 is a sequence diagram showing a series of processes performed by the management system of Figure 1 when a guest key is deleted in response to a request from a guest device.

[0025] Throughout the drawings and detailed description, identical reference numbers refer to like elements. The drawings can not be to scale and the dimensions of the elements in the drawings can be exaggerated for clarity, illustration, and convenience. DETAILED DESCRIPTION

[0026] The present specification provides a comprehensive understanding of the method, device, and / or system. Modifications and equivalents of the method, device, and / or system can be understood by those skilled in the art. The sequence of operations is exemplary, and those skilled in the art can make changes other than the order of certain operations. Descriptions of functions and structures known to those skilled in the art can be omitted.

[0027] The exemplary embodiments can be, and are not limited to, being in different forms. However, the described examples are thorough and complete, and convey to one of ordinary skill in the art the full scope of the present disclosure.

[0028] In this specification, "at least one of A and B" should be understood as "only A, only B, or both A and B".

[0029] A management server 70 according to an embodiment will now be described with reference to the drawings.

[0030] Management system overview

[0031] As Figure 1 illustrated, a management system 10 manages a plurality of digital keys applicable to a target vehicle 20. Standards for digital keys have been established by the Car Connectivity Consortium (CCC). Aspects related to digital keys in this embodiment are based on compliance with the CCC standards. However, they are also applicable to standards and systems other than the CCC standards. The management system 10 includes a plurality of vehicles 20, a plurality of devices 30, a device server 60, and a management server 70. In Figure 1 only one vehicle 20 is shown, other vehicles 20 are not shown.

[0032] Each vehicle 20 includes a communication module 21, a human-machine interface (HMI) 22, a Bluetooth Low Energy (BLE) module 23, an Ultra-Wideband (UWB) module 24, a Near Field Communication (NFC) module 25, and a vehicle management device 26.

[0033] The communication module 21 communicates with the management server 70 via a wireless communication network. The HMI interface 22 includes an input device that experiences input operations performed by a user of the vehicle 20, and an output device for presenting information to the user. The output device is, for example, a monitor and a speaker.

[0034] The BLE module 23 communicates with the devices 30 via BLE communication for short-range wireless communication. The UWB module 24 communicates with the devices 30 via UWB communication. The UWB module 24 measures the distance between the devices 30 and the vehicle 20. The NFC module 25 communicates with the devices 30 via NFC communication for short-range wireless communication.

[0035] The vehicle management device 26 is installed on the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 includes an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT, which is information related to the digital key. The vehicle program PV is executed by the execution device 27 to cause the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating the digital key so that the digital key can be used to control the vehicle 20 when the digital key is used. Each digital key to be authenticated is provided with the authentication information AT. The execution device 27 is a CPU. The execution device 27 executes the vehicle program PV to perform a process related to storing and deleting the authentication information AT.

[0036] When the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables the vehicle 20 to be controlled using the authenticated digital key. For example, after the digital key is authenticated, the vehicle management device 26 enables the vehicle 20 to be unlocked. Also for example, after the digital key is authenticated, the vehicle management device 26 enables the vehicle 20 to be started.

[0037] The devices 30 include portable devices 30M and a specification server 30N. That is, the device types indicating the categories of each device 30 include the portable devices 30M and the specification server 30N. In the example shown, the devices 30 are all portable devices 30M. Figure 1 In the example shown, the devices 30 are all portable devices 30M.

[0038] The portable devices 30M are, for example, smartphones or smartwatches. The portable devices 30M perform short-range wireless communication with the vehicle 20.

[0039] Each portable device 30M includes a communication module 31, an HMI 32, a BLE module 33, a UWB module 34, an NFC module 35, an execution device 36, and a storage device 37.

[0040] The communication module 31 communicates with the device server 60 via a wireless communication line. The HMI 32 includes an input device that undergoes an input operation performed by a user of the device 30 and an output device for presenting information to the user. The output device is, for example, a monitor and a speaker.

[0041] The BLE module 33 performs short-range wireless communication with the vehicle 20 via a BLE communication. The UWB module 34 performs wireless communication with the vehicle 20 via a UWB communication. The NFC module 35 performs short-range wireless communication with the vehicle 20 via an NFC communication.

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

[0043] The device program PD includes, for example, a device application and a digital key framework. The device application is an application for storing and deleting the key information DK. The digital key framework is a program that provides a function of pairing and sharing a digital key of the portable device 30M by utilizing an API prepared in an OS. The execution device 36 executes the device program PD to execute a process related to storage and deletion of the key information DK.

[0044] The plurality of devices 30 includes the owner device 40 and the shareable device 50. The owner device 40 stores owner key information DKO indicating the owner key KO as the key information DK. Only one owner key KO is allowed to be registered in a single vehicle 20. Therefore, each vehicle 20 has only one owner key KO.

[0045] As shown in Figure 2 , the owner key information DKO includes owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, in-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The owner key structure information STO further includes certificate information ST5, device public key information ST6, vehicle public key information ST7, and authorized public key information ST8.

[0046] The vehicle identification information ST1 is information for identifying the vehicle 20 to which a digital key is assigned. For example, the vehicle identification information ST1 is an ID of the vehicle 20.

[0047] The in-device key identification information ST2 is used for management of the digital key within the device 30. The in-device key identification information ST2 is information for identifying the digital key in an application of the device 30.

[0048] The digital key identification information ST3 is used for management of the digital key in the server 70. The slot identification information ST4 is information for locally identifying the digital key within the device 30.

[0049] The certificate information ST5 indicates a certificate for verifying a digital key. The device public key information ST6 indicates a device public key PKD, which is a public key of the device 30. The device public key PKD in the owner key information DKO indicates a public key of the owner device 40. The vehicle public key information ST7 indicates a vehicle public key PKV, which is a public key of the vehicle 20. The authorized public key information ST8 indicates a vehicle public key PKV that has been allowed.

[0050] AsFigure 1 As shown, each of the shareable devices 50 stores shareable key information DKS that indicates a shareable key KS as key information DK. When registering a digital key, multiple shareable keys KS can be registered in a vehicle 20 for use. That is, multiple shareable keys KS can be associated with a single vehicle 20.

[0051] The shareable device 50 includes a friend device 51 and a guest device 52. Friend device 51 stores friend key information DKF indicating a friend key KF as shareable key information DKS. Guest device 52 stores guest key information DKN indicating a guest key KN as shareable key information DKS. That is, the types of shareable keys KS include friend key KF and guest key KN. Friend key KF is a shareable key KS already registered based on a direct registration request D21 from owner device 40, as described below. Guest key KN is a shareable key KS already registered based on a registration request D31 from friend device 51, as described later. In other words, guest key KN is a shareable key KS registered based on an indirect registration request from shareable device 50, which is a device 30 different from owner device 40.

[0052] The digital key registration status refers to the state in which the digital key can be used. In the digital key registration status, vehicle 20 stores authentication information AT, and device 30 stores key information DK.

[0053] like Figure 3 As shown, the Shared Key Information (DKS) includes Shared Key Structure Information (STS) and Authentication Packet (ATP). The Shared Key Structure Information (STS) includes Vehicle Identification Information (ST1), Device Key Identification Information (ST2), Digital Key Identification Information (ST3), and Slot Identification Information (ST4). The Shared Key Structure Information (STS) also includes Certificate Information (ST5), Vehicle Public Key Information (ST7), and Authorized Public Key Information (ST8). In other words, the Shared Key Structure Information (STS) is obtained by removing the Device Public Key Information (ST6) from the Owner Key Structure Information (STO).

[0054] The Authentication Package (ATP) includes signature information (ATP1), password information (ATP2), validity start time information (ATP3), validity end time information (ATP4), name information (ATP5), and device public key information (ATP6).

[0055] The signature information ATP1 indicates that the shareable device 50 is an authorized entity for receiving the digital key. For example, in the case of friend device 51, the signature information ATP1 indicates the signature of the owner device 40. The signature information ATP1 of friend device 51 indicates that the owner device 40 has signed the device public key PKD of friend device 51 as indicated by the device public key information ATP6. Furthermore, for example, in the case of guest device 52, the signature information ATP1 indicates the signature of friend device 51. The signature information of guest device 52 indicates that friend device 51 has signed the device public key PKD of guest device 52 as indicated by the device public key information ATP6.

[0056] Password information ATP2 indicates the pairing password PAS used to establish a secure channel during pairing of vehicle 20 and owner device 40. Valid start time information ATP3 indicates the earliest date and time that the shareable key KS becomes effective and available. Valid end time information ATP4 indicates the latest date and time that the shareable key KS remains valid and available. Name information ATP5 indicates the name used to identify the shareable key KS. Name information ATP5 is, for example, a recognizable name set for each of the shareable devices 50 through operations from owner device 40.

[0057] like Figure 1 As shown, device server 60 relays communication between device 30 and management server 70. A device server 60 is provided for each type of device 30. Specifically, the device server 60 used to communicate with a first type of device 30 is different from the device server 60 used to communicate with a second type of device 30. For example, "type" can refer to the model of the device 30, and a separate device server 60 can be provided for each model of device 30. In another example, "type" can refer to the communication line used by the device 30, and a separate device server 60 can be provided for each type of communication line used by the device 30.

[0058] Each device server 60 relays communication between the device 30 and the management server 70. This allows different types of devices 30 to communicate with the management server 70 via the device server 60. Figure 1 Only one device server 60 is shown.

[0059] Management Server

[0060] Management server 70 is configured to manage multiple digital keys. As will be discussed below, the digital keys include the target digital key and participating digital keys that have already registered for the target digital key.

[0061] The management server 70 is capable of communicating with the vehicle 20 and the plurality of devices 30. The management server 70 includes an execution device 71 and a storage device 72. The storage device 72 stores a server program PS and a database DB. The server program PS is executed by the execution device 71 to cause the execution device 71 to register a digital key in the database DB, and delete a digital key from the database DB. In other words, the execution device 71 executes the server program PS, thereby causing the management server 70 to execute a management method.

[0062] The database DB includes information associated with the registered devices 30 for each of the digital keys, for the corresponding vehicle 20. The data DA included in the database DB provides a division of the vehicle 20. In a state where a digital key is registered, the database DB includes information indicating the device 30 storing the key information DK indicating the digital key, and information indicating the user attribute UA of each device 30.

[0063] As shown in FIG. 6, the data DA of one vehicle 20 includes information on the types of the digital keys registered in the vehicle 20, the registered devices 30, and the relationships among the registered devices 30. The digital keys are classified into a plurality of hierarchical levels according to their respective types. From the highest level to the lowest level, the digital keys are ordered as: the owner key KO, the friend key KF, and the guest key KN. The digital keys of a higher hierarchical level are assigned a greater authority. Figure 4

[0064] The authority includes, for example, the number of shareable keys KS that can be requested to be registered, and the range of control over the vehicle 20 by the digital key authentication. The digital keys of a higher hierarchical level are allowed to request registration of a greater number of shareable keys KS. Specifically, for example, the number of friend keys KF that the owner device 40 is allowed to request registration of is greater than the number of guest keys KN that the friend device 51 is allowed to request registration of. Each digital key is allowed to request deletion of the digital keys of a lower level than itself, but is not allowed to request deletion of the digital keys of a higher level than itself.

[0065] In addition, as the hierarchical level of the digital key increases, the range of control over the vehicle 20 that is allowed also increases. The range of control over the vehicle 20 refers to a set of controllable functions, such as engine start control of the vehicle 20, power on control of the vehicle 20, and door unlocking and locking control of the vehicle 20. For example, when the range of control includes all of the above three functions, its range of control is wider than when it includes only the door unlocking and locking control of the vehicle 20. Specifically, the range of control over the vehicle 20 allowed by the friend key KF includes all of the above three functions, whereas the range of control allowed by the temporary key KN is limited to only the door unlocking and locking control of the vehicle 20.

[0066] ​The state in which the digital keys are registered in the seven devices 30 of one vehicle 20 will now be described. The seven devices 30 are the first device 30A to the seventh device 30G, respectively. The digital keys registered in the first device 30A to the seventh device 30G, respectively, are the first key to the seventh key, respectively. These pieces of information are included in the data DA.

[0067] The device 30 in which the owner key KO is registered as the digital key is the first device 30A. In other words, the first device 30A is the owner device 40. That is, the first key is the owner key KO.

[0068] The devices 30 in which the shareable key KS is registered as the digital key are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. In other words, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are the shareable devices 50. In other words, the second key to the seventh key are all the shareable key KS.

[0069] Specifically, the devices 30 in which the friend key KF is registered as the shareable key KS are the second device 30B and the fifth device 30E. In other words, the second device 30B and the fifth device 30E are the friend devices 51. The devices 30 in which the guest key KN is registered as the shareable key KS are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. In other words, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are the guest devices 52.

[0070] The relationship between the registered devices 30 included in the data DA will now be described. The relationship between the second device 30B and the first device 30A is as follows: in response to a registration request from the first device 30A, the friend key KF has been registered in the second device 30B. In other words, the second key is registered based on the first key. Therefore, the first key participates in the registration of the second key. On the other hand, the third key to the seventh key do not participate in the registration of the second key.

[0071] The relationship between the fifth device 30E and the first device 30A is as follows: in response to a registration request from the first device 30A, the friend key KF has been registered in the fifth device 30E. In other words, the fifth key is registered based on the first key. Therefore, the first key participates in the registration of the fifth key. On the other hand, the second key to the fourth key, the sixth key, and the seventh key do not participate in the registration of the fifth key.

[0072] The relationship between the third device 30C and the second device 30B is as follows: in response to a registration request from the second device 30B, the guest key KN has been registered into the third device 30C. In other words, the third key is registered based on the second key. Thus, both the first key and the second key participate in the registration of the third key. On the other hand, the fourth key to the seventh key do not participate in the registration of the third key.

[0073] The relationship between the fourth device 30D and the second device 30B is as follows: in response to a registration request from the second device 30B, the guest key KN has been registered into the fourth device 30D. In other words, the fourth key is registered based on the second key. Thus, both the first key and the second key participate in the registration of the fourth key. On the other hand, the third key and the fifth key to the seventh key do not participate in the registration of the fourth key.

[0074] The relationship between the sixth device 30F and the fifth device 30E is as follows: in response to a registration request from the fifth device 30E, the guest key KN has been registered into the sixth device 30F. In other words, the sixth key is registered based on the fifth key. Thus, both the first key and the fifth key participate in the registration of the sixth key. On the other hand, the second key to the fourth key and the seventh key do not participate in the registration of the sixth key.

[0075] The relationship between the seventh device 30G and the fifth device 30E is as follows: in response to a registration request from the fifth device 30E, the guest key KN has been registered into the seventh device 30G. In other words, the seventh key is registered based on the fifth key. Thus, both the first key and the fifth key participate in the registration of the seventh key. On the other hand, the second key to the fourth key and the sixth key do not participate in the registration of the seventh key.

[0076] As described above, the data DA includes information about the devices 30 for which a digital key has been registered. In the data DA, each registered device 30 is associated with information indicating the device 30 that initiated the registration request. The data DA also includes information indicating the digital key on which each digital key registration is based. Furthermore, the data DA also includes information indicating which digital keys participate in the registration of each digital key.

[0077] In this way, the digital key includes a target digital key and a participating registration digital key that has participated in registration of the target digital key. The participating registration digital key includes a directly participating registration digital key that directly participates in registration of the target digital key and an indirectly participating registration digital key that indirectly participates in registration of the target digital key. The directly participating registration digital key is a digital key that serves as a basis for registration of the target digital key. The indirectly participating registration digital key is a digital key that serves as a basis for registration of a digital key that directly participates in registration of the target digital key. In the present embodiment, among the participating registration digital keys, a device to which the directly participating registration digital key is registered is referred to as a participating device.

[0078] As shown in Figure 5 , the data DA of each vehicle 20 includes information indicating the user attribute UA of each registered device 30. Specifically, the data DA includes information indicating whether the user attribute UA of each of the above-described first to seventh devices 30A to 30F indicates a specific business corporation that operates a specific business type. The specific business type is, for example, a car rental service or a car sharing service. That is, in the present embodiment, the information indicating the user attribute includes information indicating whether the user is a specific business operator and whether the user is a corporation.

[0079] In Figure 5 the example shown, the user attribute UA of the first device 30A indicates neither a specific operator nor a corporation. The user attribute UA of the second device 30B indicates both a specific operator and a corporation. The user attribute UA of the third device 30C indicates neither a specific operator nor a corporation. The user attribute UA of the fourth device 30D indicates neither a specific operator nor a corporation. The user attribute UA of the fifth device 30E indicates neither a specific operator nor a corporation. The user attribute UA of the sixth device 30F indicates neither a specific operator nor a corporation. The user attribute UA of the seventh device 30G indicates neither a specific operator nor a corporation.

[0080] Digital Key Registration

[0081] Next, a series of processes of registering a digital key in the management system 10 will be described. The registration of the digital key includes registration of the owner key KO, registration of the friend key KF, and registration of the visitor key KN.

[0082] First, a series of processes of registering a digital key when the device 30 is the portable device 30M will be described. The following description will explain the entire process from a state in which no digital key is registered to a state in which a digital key is registered. In the following description, the process performed by the execution device 27 will be described as a process performed by the vehicle 20. The process performed by the execution device 36 will be described as a process performed by the device 30. The process performed by the execution device 71 will be described as a process performed by the management server 70.

[0083] Registering an owner key in a portable device

[0084] As shown in FIG. 1, the management system 10 performs a series of processes to register the owner key KO. The following description will explain an example in which the owner key KO is registered to the first device 30A which does not store the key information DK indicating the owner key KO. Figure 6

[0085] The management system 10 stores the key information DK indicating the owner key KO in the first device 30A by registering the owner key KO. The management system 10 causes the vehicle 20 to store the authentication information AT for authenticating the owner key KO by registering the owner key KO. Thereby, the first device 30A is configured as the owner device 40. Before the owner key KO is registered, an application required for the registration is pre-installed on the first device 30A.

[0086] Upon receiving the registration request D11 of the owner key KO from the first device 30A or the like, the management server 70 performs the process of step S11. In step S11, the management server 70 generates the pairing password PAS. Then, the management server 70 transmits information indicating the pairing password PAS to the vehicle 20 and the first device 30A.

[0087] Subsequently, the vehicle 20 receives the pairing password PAS. Upon receiving the pairing password PAS, the vehicle 20 is set to a pairing mode via the HMI 22. Then, the vehicle 20 stands by in a state in which the password can be received from the first device 30A. Then, the vehicle 20 advances the process to step S12.

[0088] In step S12, the vehicle 20 performs pairing with the first device 30A. When the pairing is performed, the vehicle 20 establishes a secure channel for data transmission with the first device 30A. The pairing is performed using the pairing password PAS transmitted from the management server 70 to the vehicle 20 and the first device 30A. Upon completion of the pairing, the vehicle 20 advances the process to step S13.

[0089] ​In step S13, the vehicle 20 generates a vehicle public key PKV, which is a public key of the vehicle 20, and a vehicle secret key SKV, which is a secret key of the vehicle 20. Thereafter, the vehicle 20 transmits generation data DC for generating the owner key KO to the first device 30A via the secure channel. The generation data DC includes the vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. Then, the first device 30A receives the generation data DC. Thereafter, the first device 30A advances the process to step S14.

[0090] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. Thereafter, the first device 30A advances the process to step S15.

[0091] In step S15, the first device 30A stores the owner key information DKO. By this, the first device 30A is configured as the owner device 40. Subsequently, the first device 30A transmits certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD to the vehicle 20.

[0092] Thereafter, upon receiving the certificate information ST5 and the device public key information ST6, the vehicle 20 executes the process of step S16. In step S16, the vehicle 20 verifies the certificate information ST5. When the verification of the certificate information ST5 is completed, the vehicle 20 advances the process to step S17.

[0093] In step S17, the vehicle 20 stores the device public key information ST6 indicating the device public key PKD as the authentication data AT. Subsequently, the vehicle 20 transmits a completion notification M11 to the first device 30A, indicating that the storage of the authentication data AT has been completed.

[0094] Thereafter, upon receiving the completion notification M11, the first device 30A executes the process of step S18. In step S18, the first device 30A generates a key state update request D12 of the owner key KO. The key state update request D12 is a signal for requesting the management server 70 to update the database DB. The first device 30A transmits the key state update request D12 of the owner key KO and information indicating the user attribute UA of the first device 30A to the management server 70 via the device server 60. In Figure 6 In the example shown, the user attribute UA of the first device 30A does not indicate a specific business corporation.

[0095] Subsequently, upon receiving the key status update request D12, the management server 70 executes step S19. In step S19, the management server 70 performs registration management for the owner key KO. Specifically, the management server 70 stores the fact that the device 30 to which the owner key KO is registered is the first device 30A as data DA of vehicle 20 in the database DB. The management server 70 also stores the fact that the user attribute UA of the first device 30A is not a specific business entity as data DA of vehicle 20 in the database DB. Then, the management system 10 terminates the series of processes used to register the owner key KO.

[0096] Register a friend key on a portable device

[0097] like Figure 7 As shown, the management system 10 executes a series of procedures to register a friend key KF. The following describes an example of registering a friend key KF in a second device 30B that does not store friend key information DKF through this series of procedures.

[0098] When the operation to request the registration of the friend key KF is performed in the owner device 40, the owner device 40 first executes the process of step S21. In step S21, the owner device 40 transmits the registration request D21 for the friend key KF to the relay server (not shown). Afterwards, the owner device 40 proceeds the process to step S22.

[0099] In step S22, the owner device 40 obtains invitation information IV1 for sharing the digital key from the relay server. This invitation information IV1 is, for example, a URL link. The URL link contains sharing information SH1 necessary for sharing the digital key. Subsequently, the owner device 40 transmits the invitation information IV1 to the second device 30B.

[0100] Subsequently, upon receiving invitation information IV1, the second device 30B executes 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 source of the URL link.

[0101] The shared information SH1 includes, for example, shareable key structure information STS, password information ATP2, valid start time information ATP3, valid end time information ATP4, and name information ATP5. The valid start time information ATP3, valid end time information ATP4, and name information ATP5 are configured by the owner device 40. Subsequently, the second device 30B proceeds the process to step S24.

[0102] In step S24, the second device 30B generates unsigned friend key information DKFN by using the shared information SH1. The unsigned friend key information DKFN is friend key information DKF that does not have signature information ATP1. The unsigned friend key information DKFN includes the acquired shared information SH1. Thereafter, the second device 30B transmits a completion notification M21 to the owner device 40, indicating that uploading of the generated unsigned friend key information DKFN to the URL link has been completed. The second device 30B also transmits a signature request D22 to the owner device 40.

[0103] Subsequently, the owner device 40 receives the completion notification M21 and the signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 acquires the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 is operated to perform the process of step S25.

[0104] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 causes the HMI 32 to present the unsigned friend key information DKFN that has been acquired, and accepts an operation indicating that a user of the owner device 40 has agreed to register the friend key KF. Upon receiving the operation, the owner device 40 generates the signature information ATP1 based on the operation. Then, the owner device 40 advances the process to step S26.

[0105] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. The owner device 40 thereby generates the friend key information DKF. Thereafter, the owner device 40 uploads the generated friend key information DKF to the URL link, that is, the invitation information IV1. Then, the owner device 40 transmits a completion notification M22 to the second device 30B, indicating that uploading of the completed friend key information DKF to the URL link has been completed.

[0106] Thereafter, the second device 30B obtains the completion notification M22. Then, the second device 30B performs the process of step S27. In step S27, the second device 30B stores the friend key information DKF by downloading it. Thereby, the second device 30B is configured as the friend device 51. Thereafter, the second device 30B advances the process to step S28.

[0107] In step S28, the second device 30B generates a key state update request D23 of the friend key KF. Then, the second device 30B transmits the friend key information DKF, the key state update request D23 of the friend key KF, and information indicating the user attribute UA of the second device 30B to the management server 70. In Figure 7In the illustrated example, the user attribute UA of the second device 30B does not indicate a specific business entity.

[0108] Subsequently, upon receiving the key status update request D23 of the friend key KF, the management server 70 performs the process of step S29. In step S29, the management server 70 performs registration management of the friend key KF.

[0109] Specifically, the management server 70 checks whether the friend key KF targeted by the key status update request D23 is not listed in a revocation list. The revocation list is a list indicating the shareable keys KS including the friend key KF and the guest key KN for which a deletion request has been received. If the friend key KF is listed in the revocation list, the management server 70 transmits a notification to the second device 30B indicating that it cannot respond to the key status update request D23.

[0110] On the other hand, when the friend key KF having received the key status update request D23 is not listed in the revocation list, the management server 70 registers the friend key KF having received the key status update request D23 in the database DB. Specifically, the management server 70 stores the fact that the device 30 registered as the friend device 51 is the second device 30B in the data DA of the vehicle 20 in the database DB. The management server 70 stores the relationship between the second device 30B and the owner device 40 by referring to the acquired friend key information DKF. The management server 70 stores the fact that the user attribute UA of the second device 30B is not a specific business entity in the database DB as the data DA of the vehicle 20.

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

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

[0113] Upon completion of the registration management, the management server 70 transmits a completion notification M23 of the key status update to the second device 30B.

[0114] Subsequently, upon receiving the key status update completion notification M23, the second device 30B executes step S31. During step S31, the second device 30B presents information indicating the completion of friend key KF registration on the HMI 32. For example, the second device 30B presents an image indicating the completion of friend key KF registration on the HMI 32. Thus, the management system 10 terminates the series of processes used to register the friend key KF.

[0115] Register a guest key on a portable device

[0116] like Figure 8 As shown, the management system 10 performs a series of processes to register the guest key KN. The following describes an example of registering the guest key KF to a third device 30C that does not store guest key information DKN through this series of processes.

[0117] When a request to register a guest key KN is executed in friend device 51, friend device 51 first performs step S41. In step S41, friend device 51 transmits the registration request D31 for the guest key KN to the relay server (not shown). Afterward, friend device 51 proceeds to step S42.

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

[0119] Subsequently, upon receiving invitation information IV2, the third device 30C executes 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.

[0120] The shared information SH2 includes, for example, shareable key structure information STS, password information ATP2, valid start time information ATP3, valid end time information ATP4, and name information ATP5. The valid start time information ATP3, valid end time information ATP4, and name information ATP5 are configured by the friend device 51. Subsequently, the third device 30C advances the process to step S44.

[0121] In step S44, the third device 30C generates the unsigned guest key information DKNN using the shared information SH2. The unsigned guest key information DKNN is the guest key information DKN without the signature information ATP1. The unsigned guest key information DKNN includes the acquired shared information SH2. Subsequently, the third device 30C transmits the completion notification M31 to the friend device 51, indicating that uploading of the generated unsigned guest key information DKNN to the URL link has been completed. The third device 30C also transmits the signature request D32 to the friend device 51.

[0122] Subsequently, the friend device 51 receives the completion notification M31 and the signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 acquires the unsigned guest key information DKNN. Upon receiving the signature request D32, the friend device 51 is operated to execute the process of step S45.

[0123] In step S45, the friend device 51 generates the signature information ATP1. Specifically, the friend device 51 causes the HMI 32 to present the unsigned guest key information DKNN that has been acquired, and accepts an operation indicating that the user of the friend device 51 has agreed to register the guest key KN. Upon receiving the operation, the friend device 51 generates the signature information ATP1 based on the operation. Thereafter, the friend device 51 advances the process to step S46.

[0124] In step S46, the friend device 51 adds the signature information ATP1 to the unsigned guest key information DKNN. The friend device 51 thereby generates the guest key information DKN. Thereafter, the friend device 51 uploads the generated guest key information DKN to the URL link, that is, the invitation information IV2. Then, the friend device 51 transmits the completion notification M32 to the third device 30C, indicating that uploading of the completed guest key information DKN to the URL link has been completed.

[0125] Thereafter, the third device 30C obtains the completion notification M32. Then, the third device 30C executes the process of step S47. In step S47, the third device 30C downloads and stores the guest key information DKN. Thereby, the third device 30C is configured as the guest device 52. Thereafter, the third device 30C advances the process to step S47.

[0126] In step S48, the third device 30C generates a key state update request D33 for the guest key KN. The third device 30C transmits the guest key information DKN, the key state update request D33 for the guest key KN, and information indicating the user attribute UA of the third device 30C to the management server 70. In Figure 8 In the example shown, the user attribute UA of the third device 30C does not indicate a specific business entity.

[0127] Thereafter, upon receiving the key status update request D33 of the guest key KN, the management server 70 executes the process of step S49. In step S49, the management server 70 performs registration management on the guest key KN.

[0128] Specifically, the management server 70 checks whether the guest key KN targeted by the key status update request D33 is not listed in the revocation list. If the guest key KN is already listed in the revocation list, the management server 70 transmits a notification to the third device 30C indicating that it cannot respond to the key status update request D33.

[0129] On the other hand, if the guest key KN is not listed in the revocation list, the management server 70 registers the guest key KN targeted by the key status update request D33 in the database DB. Specifically, the management server 70 stores the fact that the device 30 registered as the guest device 52 is the third device 30C in the data DA of the vehicle 20 in the database DB. The management server 70 stores the relationship between the third device 30C and the friend device 51 by referring to the acquired guest key information DKN. Specifically, the management server 70 stores the fact that the third device 30C is a device 30 that registered the guest key KN in response to the registration request D31 from the second device 30B. The management server 70 stores the fact that the user attribute UA of the third device 30C is not a specific business entity in the database DB as the data DA of the vehicle 20.

[0130] Subsequently, the management server 70 transmits the authentication package ATP as part of the guest key information DKN to the vehicle 20 along with a storage request D34 requesting storage of the authentication package ATP. That is, the management server 70 transmits the device public key information ST6 indicating the device public key PKD of the guest device 52 to the vehicle 20. The management server 70 notifies the vehicle 20 that the device public key PKD has been signed by the friend device 51.

[0131] Subsequently, upon receiving the authentication package ATP and the storage request D34, the vehicle 20 executes the process of step S50. In step S50, the vehicle 20 stores the received authentication package ATP. This authentication package ATP is the authentication information AT for authenticating the guest key KN.

[0132] Upon completion of the registration management, the management server 70 transmits a completion notification M33 of the key status update to the second device 30B.

[0133] Subsequently, after receiving the completion notification M33 of the key state update, the second device 30B executes the process of Step S51. In the process of Step S51, the third device 30C presents information indicating completion of registration of the guest key KN on the HMI 32. For example, the third device 30C displays an image indicating completion of registration of the guest key KN on the HMI 32. Thereby, the management system 10 terminates the series of processes for registering the guest key KN.

[0134] Device as a provisioning server

[0135] Next, a series of processes for registering a digital key when the device 30 is the provisioning server 30N will be described.

[0136] As Figure 9 indicated, the provisioning server 30N includes the communication module 31, the execution device 36, and the storage device 37. In other words, the provisioning server 30N does not include the HMI 32, the BLE module 33, the UWB module 34, or the NFC module 35. Therefore, the provisioning server 30N does not execute short-range wireless communication with the vehicle 20.

[0137] Registering an owner key in a provisioning server

[0138] As Figure 10 indicated, the management system 10 executes a series of processes in order to register the owner key KO in the provisioning server 30N. When a specific operation is executed, the first device 30A transmits a registration request D11 of the owner key KO and a queue signal FL to the management server 70. Upon receiving the registration request D11 of the owner key KO and the queue signal FL, the management server 70 executes the process of Step S61. The queue signal FL is a signal indicating that there is a request for registration of a digital key from the device 30 that is the provisioning server 30N.

[0139] In Step S61, the management server 70 identifies generation data DC for generating the owner key KO. The generation data DC includes owner key information DKO. Upon receiving the queue signal FL, the management server 70 identifies the generation data DC for generating the owner key KO of the target vehicle 20 among the generation data DC of the plurality of vehicles 20 stored in advance. For example, when the user of the first device 30A subscribes to a contract to use the provisioning server 30N as the first device 30A, the management server 70 acquires the generation data DC for generating a digital key of the target vehicle 20 from an external server. Therefore, the management server 70 stores in advance the generation data DC for generating a digital key of the target vehicle 20. The generation data DC for generating a digital key includes generation data DC for generating each of the owner key KO and the shareable key KS. Then, the management server 70 transmits the identified generation data DC to the first device 30A.

[0140] Thereafter, upon receiving the generation data DC, the first device 30A executes the process of step S62. In step S62, the first device 30A generates the owner key information DKO using the generation data DC. Thereafter, the first device 30A advances the process to step S63.

[0141] In step S63, the first device 30A stores the owner key information DKO. By this, the first device 30A is configured as the owner device 40. Thereafter, the first device 30A transmits the key state update request D12 of the owner key KO and the information indicating the user attribute UA of the first device 30A to the management server 70. In Figure 10 In the example shown, the user attribute UA of the first device 30A indicates a certain business corporation.

[0142] Thereafter, upon receiving the key state update request D12, the management server 70 executes the process of step S64. In step S64, the management server 70 performs the registration management of the owner key KO. Specifically, the management server 70 stores, as the data DA of the vehicle 20, the fact that the device 30 to which the owner key KO is registered is the first device 30A in the database DB. The management server 70 stores, as the data DA of the vehicle 20, the fact that the user attribute UA of the first device 30A is a certain business corporation in the database DB. Subsequently, the management server 70 transmits the certificate information ST5 related to the owner key KO and the device public key information ST6 indicating the device public key PKD to the vehicle 20.

[0143] Thereafter, upon receiving the certificate information ST5 and the device public key information ST6, the vehicle 20 executes the process of step S65. In step S65, the vehicle 20 verifies the certificate information ST5. When the verification of the certificate information ST5 is completed, the vehicle 20 executes the process of step S66.

[0144] In step S66, the vehicle 20 stores the device public key information ST6 as the authentication information AT. By this, the management system 10 completes the series of processes of registering the owner key KO in the device 30 as the prescribed server 30N.

[0145] Registering a guest key in a prescribed server

[0146] As Figure 11 indicated, the management system 10 executes a series of processes so as to register the friend key KF in the prescribed server 30N. When the prescribed operation is executed, the owner device 40 transmits the registration request D21 of the friend key KF and the queue signal FL to the management server 70. Upon receiving the registration request D21 of the friend key KF and the queue signal FL from the owner device 40, the management server 70 executes the process of step S71.

[0147] In step S71, the management server 70 identifies the generation data DC for generating the friend key KF. The generation data DC includes the friend key information DKF. Upon receipt of the queue signal FL, the management server 70 identifies the generation data DC for generating the friend key KF of the target vehicle 20 among the generation data DC of the plurality of vehicles 20 stored in advance. Then, the management server 70 transmits the identified generation data DC to the second device 30B.

[0148] Subsequently, upon receipt of the generation data DC, the second device 30B executes the process of step S72. In step S72, the second device 30B generates the owner key information DKF using the generation data DC. Thereafter, the second device 30B advances the process to step S73.

[0149] In step S73, the second device 30B stores the friend key information DKF. By this, the second device 30B is configured as the friend device 51. Thereafter, the second device 30B transmits to the management server 70 the key state update request D23 for the friend key KF and information indicating the user attribute UA of the second device 30B. In Figure 11 In the illustrated example, the user attribute UA of the second device 30B indicates a specific business corporation.

[0150] Thereafter, upon receipt of the key state update request D23, the management server 70 executes the process of step S74. In step S74, the management server 70 performs registration management of the friend key KF. Specifically, the management server 70 stores in the database DB the fact that the device 30 to which the friend key KF is registered is the second device 30B as the data DA of the vehicle 20. The management server 70 stores as the data DA the information indicating that the second device 30B has been registered based on the registration request from the first device 30A, that is, the information indicating the relationship between the second device 30B and the first device 30A. Further, the management server 70 also stores the fact that the user attribute UA of the second device 30B indicates a specific business corporation. Thereafter, the management server 70 transmits to the vehicle 20 the storage request D24 and the authentication package ATP.

[0151] Thereafter, upon receipt of the storage request D24, the management server 70 executes the process of step S75. In step S75, the management server 70 stores the authentication package ATP as the authentication information AT according to the storage request D24.

[0152] After transmitting the storage request D24 and the authentication package ATP to the vehicle 20, the management server 70 transmits the completion notification M41 to the owner device 40. The completion notification M41 is a notification indicating that the registration of the friend key KF has been completed.

[0153] Subsequently, upon receiving the completion notification M41, the owner device 40 executes step S76. In step S76, the owner device 40 displays on the HMI 32 that the friend key KF registration is complete. Thus, the management system 10 completes a series of processes for registering the friend key KF for the device 30, which acts as the designated server 30N.

[0154] Guest key deletion control

[0155] Next, the deletion control, which includes a series of processes for deleting the visitor key KN in the management system 10, will be described. The deletion control performed by the management server 70 includes the determination of pending deletions, the transmission of deletion request D42, the transmission of deletion request D43, and the updating of the database DB, which will be discussed below. In this embodiment, the management server 70 performs deletion control to determine whether to apply the prescribed condition RC to the deletion of the target digital key, and sets the target digital key to an unavailable state based on the determination result.

[0156] The following describes the entire process from the state where the guest key KN is registered to the state where the guest key KN is no longer registered. In the following description, the process executed by execution device 27 will be described as a process executed by vehicle 20. The process executed by execution device 36 will be described as a process executed by device 30. The process executed by execution device 71 will be described as a process executed by management server 70.

[0157] In response to a deletion request from a friend's device, delete the guest key.

[0158] like Figure 12 As shown, the management system 10 executes a series of procedures for deleting the guest key KN based on a deletion request D41 from a friend device 51, which acts as a designated server 30N. In this embodiment, the server program PS causes the management server 70, which acts as a computer, to perform the deletion control.

[0159] When the operation to request the deletion of the guest key KN is performed in the friend device 51, the friend device 51 first executes the process of step S81. In step S81, the friend device 51 generates a deletion request D41 for deleting the guest key KN.

[0160] The deletion request D41 includes a signal for requesting the deletion of the guest key KN and digital key identification information ST3 indicating the guest key KN. Then, the friend device 51 transmits the deletion request D41 of the guest key KN to the management server 70.

[0161] Thereafter, after receiving the deletion request D41 of the guest key KN, the management server 70 executes the process of step S82. In step S82, the management server 70 executes a pending deletion determination. The pending deletion determination is a process of determining whether the state of the guest key KN for which the deletion request D41 has been made will be set to a pending deletion state. The pending deletion state refers to a state when a request to acquire the deletion target shareable key KS is made and a predetermined prescribed condition RC has not been satisfied.

[0162] As shown in Figure 13 When the management server 70 starts the pending deletion determination, the management server 70 first executes the process of step S101. In step S101, the management server 70 identifies the second specific device 30Y. The second specific device 30Y is a device 30 that stores the shareable key information DKS indicating the shareable key KS to be deleted. In the present embodiment, the shareable key KS to be deleted is the target digital key, and the second specific device 30Y is the target device.

[0163] Specifically, the management server 70 identifies the second specific device 30Y by referring to the digital key identification information ST3 included in the deletion request D41 and the data DA of the target vehicle 20 in the database DB. For example, in the example shown in Figure 4 When the device 30 to which the guest key KN indicated by the digital key identification information ST3 is registered is the third device 30C, the management server 70 identifies the second specific device 30Y as the third device 30C. Thereafter, the management server 70 advances the process to step S102.

[0164] As shown in Figure 13 In step S102, the management server 70 identifies the first specific device 30X as a participating device. The first specific device 30X is a device 30 that is the transmission source of the request to register the shareable key KS to be deleted. In the present embodiment, the first specific device 30X is a participating device. The participating device refers to a device 30 to which the digital key directly participating in the registration of the shareable key KS to be deleted is registered.

[0165] Specifically, the management server 70 refers to the database DB to identify the device 30 that is the transmission source of the request to register the second specific device 30Y as the first specific device 30X. For example, in the example shown in Figure 4In the example shown, when the second specific device 30Y is the third device 30C, the management server 70 identifies the first specific device 30X as the second device 30B. Specifically, the management server 70 stores the relationship between the third device 30C and the second device 30B as part of the vehicle 20's data DA, indicating that the third device 30C was registered based on a registration request from the second device 30B. Therefore, by referring to this relationship, the management server 70 identifies the first specific device 30X as the second device 30B.

[0166] The shareable key KS to be deleted is a second digital key, and the digital key indicated by the key information DK stored in device 30, which is the source of the transmission request to register the shareable key KS to be deleted, is a first digital key. In this embodiment, the first digital key is the digital key registered in a first specific device 30X. The second digital key is the digital key registered in a second specific device 30Y based on the registration request from the first specific device 30X.

[0167] That is, the device 30 to which the second digital key is registered is the second specific device 30Y, and the device 30 to which the first digital key is registered is the first specific device 30X. Subsequently, the management server 70 proceeds the process to step S103.

[0168] like Figure 13 As shown, in step S103, the management server 70 identifies the user attribute UA of the first specific device 30X. Specifically, the management server 70 identifies the user attribute UA of the first specific device 30X by referring to the data DA of the target vehicle 20 in the database DB. For example, when the first specific device 30X is the second device 30B, the user attribute UA of the first specific device 30X indicates a specific business entity. The management server 70 then proceeds to step S104.

[0169] In step S104, the management server 70 determines whether the user attribute UA of the first specific device 30X indicates a specific business entity.

[0170] When the user attribute UA of the first specific device 30X does not indicate a specific business entity (S104: No), the management server 70 proceeds the process to step S105.

[0171] In step S105, the management server 70 determines the pending deletion status of the digital key to be deleted. That is, the management server 70 determines to apply the specified condition RC to the deletion of the target digital key. Then, the management server 70 proceeds to step S106.

[0172] In step S106, the management server 70 sets the status of the digital key to be deleted in the database DB to a pending deletion state. A pending deletion state means that a deletion request D41 has been received, but the deletion execution is still suspended. Subsequently, the management server 70 proceeds to step S107.

[0173] In step S107, the management server 70 determines whether a predetermined condition RC is met. The condition RC is a necessary condition to begin deletion after receiving the deletion request D41. The condition RC is predetermined. For example, the condition RC refers to a predetermined pending deletion period that has elapsed since receiving the deletion request D41. When it is determined that the condition RC is not met (S107: No), the management server 70 repeats step S107. When it is determined that the condition RC is met (S107: Yes), the management server 70 terminates the current pending deletion determination.

[0174] When the user attribute UA of the first specific device 30X indicates a specific business entity (S104: Yes), the management server 70 advances the process to step S108.

[0175] In step S108, the management server 70 determines not to set the status of the digital key to be deleted to a pending deletion state through pending deletion determination. That is, the management server 70 determines not to apply the specified condition RC to the deletion of the target digital key. Subsequently, the management server 70 terminates the current pending deletion determination. Therefore, the management server 70 terminates the pending deletion determination regardless of whether the specified condition RC is met.

[0176] like Figure 12 As shown, after the pending deletion determination is completed, the management server 70 proceeds the process to step S83. In step S83, the management server 70 generates a deletion request D42 for the guest key information DKN indicating the second digital key to be deleted. Then, the management server 70 transmits the deletion request D42 to the guest device 52, which is the second specific device 30Y. Therefore, after the management server 70 makes a positive determination on the pending deletion, when the specified condition RC is met, the management server 70 transmits the deletion request D42 to the second specific device 30Y, thereby setting the second digital key to be deleted to an unavailable state. In contrast, after the management server 70 makes a negative determination on the pending deletion, regardless of the specified condition RC, the management server 70 transmits the deletion request D42 to the second specific device 30Y, thereby setting the second digital key to be deleted to an unavailable state. That is, the management server 70 sets the second digital key to an unavailable state based on the result of the pending deletion determination.

[0177] Thereafter, the guest device 52 as the second specific device 30Y, upon receiving the deletion request D42, executes the process of step S84. In step S84, the guest device 52 as the second specific device 30Y deletes the guest key information DKN in accordance with the deletion request D42. In other words, the second specific device 30Y deletes the key information DK indicating the second digital key in accordance with the deletion request D42. Then, the guest device 52 as the second specific device 30Y transmits a deletion completion notification M42 to the management server 70, indicating that the deletion in accordance with the deletion request D42 has been completed.

[0178] Thereafter, upon receiving the completion notification M42, the management server 70 executes the process of step S85. In step S85, the management server 70 stores a deletion history of the guest key information DKN in the guest device 52 as the second specific device 30Y. Thereafter, the management server 70 advances the process to step S86.

[0179] In step S86, the management server 70 generates a deletion request D43 for the authentication information AT. The deletion request D43 for the authentication information AT indicates a request to delete the authentication information AT for authenticating the guest key KN that is the target of the deletion request D41, particularly the authentication information AT for authenticating the second digital key. Then, the management server 70 transmits the deletion request D43 to the vehicle 20.

[0180] Thereafter, upon receiving the deletion request D43, the vehicle 20 executes the process of step S87. In step S87, the vehicle 20 deletes the authentication information AT for authenticating the second digital key, that is, the guest key KN that is the target of the deletion request D41, in accordance with the deletion request D43. That is, the vehicle 20 deletes the authentication package ATP of the guest key KN as the second digital key. Thereafter, the vehicle 20 transmits a completion notification M43 to the management server 70, indicating that the deletion of the authentication information AT in accordance with the deletion request D43 has been completed.

[0181] Upon receiving the completion notification M43, the management server 70 executes the process of step S88. In step S71, the management server 70 stores a deletion history of the authentication information AT for authenticating the guest key KN to be deleted in the vehicle 20 in the current series of deletion processes in the vehicle 20. Thereafter, the management server 70 advances the process to step S89.

[0182] In step S89, the management server 70 updates the database DB. Specifically, the management server 70 removes the visitor device 52 to which the visitor key KN, which will be deleted in the current series of processes, is registered from the data DA of vehicle 20 in the database DB. In other words, the management server 70 removes the second specific device 30Y to which the second digital key is registered from the data DA of vehicle 20 in the database DB. Subsequently, the management server 70 transmits a completion notification M44 to the friend device 51, indicating that the series of deletions of the visitor key KN according to the deletion request D41 has been completed.

[0183] Subsequently, upon receiving the completion notification M44, the friend device 51 executes step S90. In step S90, the friend device 51 causes the HMI 32 to present information indicating that the deletion of the guest key KN, the target of the deletion request D41, has been completed. For example, the friend device 51 causes the HMI 32 to display an image indicating the completion of the deletion of the guest key KN. Afterward, the management system 10 terminates the current series of processes for deleting the guest key KN.

[0184] Delete the guest key via the delete function on the guest device.

[0185] like Figure 14 As shown, in response to a deletion operation on the visitor device 52, the management system 10 performs a series of procedures to delete the visitor key KN indicated by the visitor key information DKN stored in the visitor device 52.

[0186] When the prescribed operation for requesting the deletion of the visitor key KN is performed on the visitor device 52, the visitor device 52 first executes step S111. In step S111, the visitor device 52 deletes the visitor key information DKN according to the prescribed operation. Subsequently, the visitor device 52 transmits a completion notification M51 to the management server 70, indicating that the deletion of the visitor key information DKN has been completed.

[0187] Subsequently, upon receiving the completion notification M51, the management server 70 executes step S112. In step S112, the management server 70 stores the deletion history of the visitor key information DKN in the visitor device 52. Then, the management server 70 transmits the completion notification M52 to the visitor device 51, indicating that the deletion of the visitor key information DKN has been completed.

[0188] Subsequently, upon receiving the completion notification M52, the friend device 51 executes step S113. In step S113, the friend device 51 causes the HMI 32 to display information indicating that the deletion of the guest key information DKN of the guest device 52 has been completed. For example, the friend device 51 causes the HMI 32 to display an image indicating that the deletion of the guest key KN has been completed.

[0189] After the process of step S112, the management server 70 executes the process of step S114. In step S114, the management server 70 generates a deletion request D51 for deleting the authentication information AT for authenticating the guest key information DKN that has been deleted by the completion notification M51. Then, the management server 70 transmits the deletion request D51 to the vehicle 20.

[0190] Thereafter, upon receiving the deletion request D51, the vehicle 20 executes the process of step S115. In step S115, the vehicle 20 deletes the authentication information AT for authenticating the guest key KN that has been deleted in step S111, in accordance with the deletion request D51. Then, the vehicle 20 transmits a completion notification M53 to the management server 70, indicating that the deletion of the authentication information AT in accordance with the deletion request D51 has been completed.

[0191] Thereafter, upon receiving the completion notification M53, the management server 70 executes the process of step S116. In step S116, the management server 70 stores a deletion history of the authentication information AT for authenticating the guest key KN that has been deleted in step S111. Thereafter, the management server 70 advances the process to step S117.

[0192] In step S117, the management server 70 updates the database DB. Specifically, the management server 70 deletes the guest device 52 having the guest key KN to be deleted in the current series of processes, from the vehicle 20 data DA in the database DB. Thereby, the management system 10 terminates the current series of processes for deleting the guest key KN. That is, when the guest key KN is deleted in response to the deletion operation on the guest device 52 storing the guest key information DKN indicating the guest key KN to be deleted, the management server 70 does not execute the pending deletion determination.

[0193] Operation of the embodiment

[0194] In the above-described embodiment, in the case where the user attribute UA of the first specific device 30X is not a specific business entity, the likelihood that the vehicle 20 is used by the user of the first specific device 30X is high. On the other hand, in the case where the user attribute UA of the first specific device 30X indicates a specific business entity, the likelihood that the user of the first specific device 30X does not directly use the vehicle 20 but lends the vehicle 20 to another user and allows the user to use the vehicle 20 is high.

[0195] Advantages of the embodiment

[0196] (1) The management server 70 determines whether or not to apply the prescribed condition RC to the deletion of the digital key to be deleted, based on the user attribute UA of the participating device to which the digital key participating in the registration of the digital key to be deleted is registered. Then, the management server 70 sets the digital key to be deleted to the unusable state in accordance with the result of the determination. Thus, the management server 70 can determine whether or not to set the digital key to be deleted to the unusable state in accordance with the usage mode of the vehicle 20 based on the user attribute UA of the participating device.

[0197] (2) The digital key to be deleted is the second digital key. The digital key participating in the registration of the second digital key as the digital key to be deleted is the first digital key. Thus, the management server 70 determines whether or not to set the second digital key to the pending deletion state in accordance with the user attribute UA of the first specific device 30X. That is, the management server 70 determines whether or not to apply the prescribed condition RC to set the digital key to be deleted to the unusable state, based on the user attribute UA of the device 30 to which the digital key directly participating in the registration of the digital key to be deleted is registered. Thus, the management server 70 can determine whether or not to apply the prescribed condition RC based on the user attribute UA of the device considered to have a high degree of participation among the plurality of digital keys participating in the registration of the digital key to be deleted.

[0198] (3) In the deletion control, the management server 70 causes the second specific device 30Y to delete the key information DK indicating the second digital key stored in the second specific device 30Y, thereby setting the second digital key to the unusable state. Thus, by controlling the second specific device 30Y, the management server 70 can manage the second digital key in a state where the second digital key cannot be used in the second specific device 30Y.

[0199] (4) In the deletion control, the management server 70 transmits a deletion request D42 indicating the key information DK of the second digital key to the second specific device 30Y, thereby causing the second specific device 30Y to delete the key information DK indicating the second digital key. Thus, when the second specific device 30Y receives the deletion request D42, the management server 70 can delete the key information DK indicating the second digital key.

[0200] (5) In the deletion control, the management server 70 causes the vehicle management device 26 to delete the authentication information AT of the second digital key stored in the vehicle management device 26, thereby setting the second digital key to the unusable state. Thus, the management server 70 can manage the second digital key as the unusable state by controlling the vehicle management device 26.

[0201] (6) In the deletion control, the management server 70 transmits a deletion request D43 of the authentication information AT of the second digital key to the vehicle 20 to cause the vehicle management device 26 to delete the authentication information AT of the second digital key. When the authentication information AT is deleted from the vehicle management device 26, if an attempt is made to use the second digital key, the second digital key will not be authenticated, and thus the second digital key becomes unusable. Therefore, the management server 70 can set the second digital key to the unusable state by transmitting the deletion request D43 to the vehicle 20.

[0202] (7) When the user attribute UA of the first specific device 30X indicates a specific business entity, it is highly likely that the first digital key will not be used for boarding the vehicle 20 or the possibility of operating the vehicle 20. In this case, the second digital key registered based on the registration request from the first specific device 30X is likely to be a shareable key KS issued for personal lending by the user of the first specific device 30X to authorize the use of the vehicle 20. In such a case, the user of the second specific device 30Y changes at each predetermined period of time, as in the case of a car rental service or a car sharing service, and therefore, the device 30 as the second specific device 30Y also changes at each such cycle. If the second digital key is set to the unusable state when the prescribed condition RC is satisfied, the second digital key can continue to be used as the device 30 of the second specific device 30Y, thereby causing the risk that the next user can not be able to use the vehicle 20 promptly.

[0203] In this regard, when the user attribute UA of the first specific device 30X indicates a specific business entity, the management server 70 makes an affirmative determination in step S104, and determines not to set the second digital key to the pending deletion state in the process of step S108. In this case, the management server 70 sets the second digital key to the unusable state upon receiving the deletion request D41 of the second digital key regardless of the prescribed condition RC. Therefore, the management server 70 can prevent the vehicle 20 from being used by the device 30 of the second specific device 30Y for an excessively long period of time. Thereby, the management server 70 prevents the situation where a user other than the user of the second specific device 30Y cannot use the vehicle 20.

[0204] (8) When the user attribute UA of the first specific device 30X does not indicate a specific business entity, the first digital key will not be used to get on the vehicle 20 or the possibility of operating the vehicle 20 is low. In this case, the second digital key registered based on the registration request of the first specific device 30X is likely to be a shareable key KS issued for personal lending by the user of the first specific device 30X to authorize the use of the vehicle 20. In this case, the user of the second specific device 30Y can get on and start the vehicle 20 without a predetermined period of time, which is typical in car rental services and car sharing services. If the second digital key is set to the unusable state regardless of the prescribed condition RC, the vehicle 20 can suddenly become unusable in the case where the device 30 is already the second specific device 30Y.

[0205] In this regard, when the user attribute UA of the first specific device 30X does not indicate a specific business entity, the management server 70 makes a negative determination in step S104, and determines to set the second digital key to the pending deletion state in the process of step S105. In this case, after acquiring the deletion request D41 of the second digital key, the management server 70 sets the second digital key to the unusable state when the prescribed condition RC is satisfied. Therefore, the management server 70 prevents a situation in which the use of the vehicle 20 by the second specific device 30Y suddenly becomes inappropriate.

[0206] (9) The management server 70 performs the pending deletion determination when acquiring the deletion request D41 of the second digital key. Therefore, when it becomes necessary to perform the pending deletion determination, the management server 70 performs the pending deletion determination based on the user attribute UA of the first specific device 30X. Therefore, when the determination result is necessary, the management server 70 can perform the pending deletion determination.

[0207] Other Embodiments

[0208] The above-described embodiments can be modified as follows. The above-described embodiments can be combined with the following modifications if the combined modifications are technically consistent with each other.

[0209] The vehicle 20 can lack at least one of the BLE module 23, the UWB module 24, and the NFC module 25. As long as the vehicle 20 includes at least one module, it can perform short-range wireless communication with the device 30. The vehicle 20 can include a module other than the modules listed above as long as the module can perform short-range wireless communication with the device 30.

[0210] The digital key-related aspects in the above-described embodiments do not need to comply with the CCC standard.

[0211] The vehicle management device 26 is not limited to the digital key ECU. For example, the vehicle management device 26 can be a central ECU that centrally manages a plurality of ECUs included in the vehicle 20.

[0212] In the above-described embodiment, the management server 70 is provided with an execution device 71 that is processing circuitry including one or more processors for running computer programs (software) to execute various processes. However, the vehicle management device 26 can also be provided with processing circuitry including one or more special-purpose hardware circuits such as an application-specific integrated circuit (ASIC) that executes at least some of the processes. Alternatively, the management server 70 can also be provided with processing circuitry including a combination of one or more processors and one or more special-purpose hardware circuits. Each processor includes a CPU and a memory such as a RAM and a ROM. The memory stores program codes or commands configured to cause the CPU to execute the processes. The memory, that is, the computer-readable medium, includes any suitable medium that is accessible by a general-purpose or special-purpose computer. The same applies to the device 30 and the vehicle management device 26.

[0213] The plurality of devices 30 can all be portable devices 30M. That is, the device types can all be portable devices 30M. The portable devices 30M can provide a car rental service or a car sharing service.

[0214] The shareable device 50 has a function of receiving the shareable key KS as in the above-described embodiment. A device 30 capable of receiving a digital key such as the shareable device 50 can also be referred to as a receiving device.

[0215] It is not necessarily required to provide a separate device server 60 for each type of device 30. It is enough for the plurality of devices 30 and the management server 70 to communicate with each other wirelessly. The device server 60 can be omitted. The plurality of devices 30 and the management server 70 can directly communicate via wireless communication.

[0216] The management server 70 can include a plurality of servers. For example, the management server 70 can include a server that stores the database DB and a server that executes the server program PS. Further, for example, the management server 70 can include 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. Further, for example, when the type of the device 30 is the prescribed server 30N, the prescribed server 30N can be included in the servers that include the management server 70.

[0217] The management server 70 does not necessarily need to store the database DB. It is enough for the management server 70 to manage a combination of the key information DK of the device 30 that manages at least one digital key in the management system 10 and the authentication information AT of the vehicle management device 26.

[0218] Various types of information

[0219] The authentication information AT is not limited to the example of the above-described embodiment, but is information for authenticating the digital key when the digital key is used. For example, the authentication information AT can be a public key shared by the vehicle management device 26 and the device 30. Further, for example, the authentication information AT can be a shared secret key.

[0220] The configuration of the information included in the key information DK is not limited to the example of the above-described embodiment. For example, the owner key information DKO does not necessarily need to include the slot identification information ST4. Further, for example, the key information DK can include information indicating the type of the digital key. The type of the digital key is, for example, information indicating one of the owner key KO, the friend key KF, and the guest key KN.

[0221] The structure of the data DA in the database DB is not limited to the example of the above-described embodiment. The database DB can be modified as long as it includes information necessary for the management server 70 to perform management in the management system 10.

[0222] In the above-described embodiment, the digital keys are arranged in a hierarchy consisting of the owner key KO, the friend key KF, and the guest key KN in descending order, so that the digital keys of a higher hierarchy level are assigned a greater authority. However, the digital keys do not necessarily need to be configured so that a higher hierarchy level corresponds to a greater authority. For example, equal authorities can be assigned to the three hierarchy levels: the owner key KO, the friend key KF, and the guest key KN.

[0223] In the database DB, the authority does not necessarily need to be determined uniformly according to the type of the digital key, and can be set for each digital key. In the database DB, the authority does not necessarily need to be limited.

[0224] The information related to the digital key stored in the vehicle management device 26 is not limited to the authentication information AT, and can be any information related to the digital key. For example, the information related to the digital key can be information for identifying the digital key.

[0225] The information related to the digital key stored in the device 30 is not limited to the key information DK, and can be any information related to the digital key. For example, the information related to the digital key can be information for identifying the digital key.

[0226] The information related to the digital key stored in the vehicle management device 26 can be different from the information related to the digital key stored in the device 30 in the above-described embodiment, or can be the same.

[0227] A series of processes for registering a digital key

[0228] In a case where the owner device 40 is the portable device 30M, the series of processes for registering the owner key KO are not limited to those in the example of the above-described embodiment. For example, even if the pairing through the process of step S12 is not performed, the owner device 40 can store the owner key information DKO by transmitting and receiving information such as the generation data DC between the vehicle 20 and the first device 30A via the management server 70. The series of processes for registering the owner key KO can be appropriately modified to align with the structure of the information included in the owner key information DKO and the structure of the information included in the authentication information AT.

[0229] When the owner device 40 is the prescribed server 30N, the series of processes for registering the owner key KO are not limited to those in the example of the above-described embodiment. For example, the management server 70 can receive the registration request D11 and the queue signal FL for the owner key KO from a server different from the first device 30A.

[0230] When the friend device 51 is the portable device 30M, the series of processes for registering the friend key KF are not limited to those in the example of the above-described embodiment. For example, the management server 70 can update the database DB through the process of step S29 after transmitting the authentication package ATP and the storage request D24 to the vehicle 20. The series of processes for registering the friend key KF can be appropriately modified to align with the structure of the information included in the friend key information DKF and the structure of the information included in the authentication information AT.

[0231] When the friend device 51 is the portable device 30M, the series of processes for registering the friend key KF are not limited to those in the example of the above-described embodiment. For example, the management server 70 can generate the friend key information DKF.

[0232] When the friend device 51 is the portable device 30M, the series of processes for registering the visitor key KN are not limited to those in the example of the above-described embodiment. The order of the processes can be different from the series of processes for registering the friend key KF in the above-described embodiment. The series of processes for registering the visitor key KN can be appropriately modified to align with the structure of the information included in the visitor key information DKN and the structure of the information included in the authentication information AT.

[0233] The type of the digital key does not necessarily need to include the visitor key KN. In other words, in the management system 10, the shareable key KS can be only the friend key KF.

[0234] The visitor device 52 can be able to transmit the request to register the new visitor key KN. In other words, the sharable device 50 can transmit the request to register the new visitor key KN, regardless of whether the sharable device 50 is the friend device 51 or the visitor device 52. In this case, the management system 10 performs the registration of the new visitor key KN using the series of processes shown in Figure 7 The series of processes shown in

[0235] The device type of the visitor device 52 can be the prescribed server 30N. As in the above modification, when the visitor device 52 is able to transmit the request to register the new visitor key KN, the user of the visitor device 52 can lend out the vehicle 20 through a service such as car rental and car sharing. In this case, the device type of the visitor device 52 can be the prescribed server 30N.

[0236] Series of processes for deleting a digital key

[0237] As shown in Figure 14 When the visitor device 52 is deleted in response to the operation of the visitor device 52, the deletion request D41 for the visitor key KN can be transmitted to the management server 70 before the completion notification M51 is transmitted to the management server 70. In this case, as in the flow shown in Figure 12 When the visitor device 52 is deleted in response to the operation of the visitor device 52, the management server 70 can transmit the request to delete the visitor key information DKN to the visitor device 52 after receiving the deletion request D41. Further, the management server 70 can perform the pending deletion determination when the visitor device 52 is deleted in response to the operation of the visitor device 52.

[0238] In the case where the visitor key KN is deleted in response to the operation of the friend device 51, and in the case where the visitor key KN is deleted in response to the operation of the visitor device 52, the deletion request D41 can be sent to the management server 70.

[0239] The owner device 40 and the vehicle 20 can transmit the deletion request D41 for the visitor key KN to the management server 70. Further, for example, the management server 70 can generate the deletion request D41 for the visitor key KN when a prescribed condition is satisfied.

[0240] In the above embodiment, the management server 70 determines whether the prescribed condition RC is satisfied. However, the vehicle 20 or the visitor device 52 can determine whether the prescribed condition RC is satisfied. For example, if the prescribed condition RC is that the number of times the power of the vehicle 20 is turned on reaches a specified count, it is preferable that the vehicle 20 determines whether the prescribed condition RC is satisfied.

[0241] In the above embodiments, the participating device is a first specific device 30X, which is a device 30 to which the digital key was registered that directly participated in the registration of the digital key to be deleted. However, this disclosure is not limited thereto. The participating device may be a device 30 to which the digital key was registered that is indirectly related to the registration of the digital key to be deleted. For example, in Figure 4 In the scenario shown, if the third key is a key to be deleted, the first device 30A, to which the first key is registered, can be preset as a participating device. That is, the management server 70 can determine whether to apply the specified condition RC to the deletion of the guest key KN based on the user attribute UA of the owner device 40.

[0242] When multiple digital keys are registered for a digital key to be deleted, the user of device 30 to which the digital key to be deleted is registered can pre-select which digital key is associated with the participating device. For example, when a digital key to be deleted is registered, device 30 to which the digital key to be deleted is registered can display a screen prompting the user to select one of the associated digital keys registered to device 30 as the participating device.

[0243] The exact time point for determining the pending deletion status

[0244] The timing of the management server 70's execution of the pending deletion determination is not limited to the time when the deletion request D41 for the second digital key is received. For example, the management server 70 may execute the pending deletion determination when registering the second digital key.

[0245] Specifically, in execution Figure 11 Following step S74, the management server 70 can execute steps S101 to S105 and step S108. When executing step S105, the management server 70 stores information in the database DB indicating that the second digital key is set to a pending deletion state. When executing step S108, the management server 70 stores information in the database DB indicating that the second digital key is not set to a pending deletion state.

[0246] When management server 70 receives deletion request D41 for the second digital key, if database DB stores information indicating that the second digital key is set to a pending deletion status, management server 70 can set the second digital key to an unavailable status if the specified condition RC is met. Conversely, if management server 70 receives deletion request D41 for the second digital key, and database DB stores information indicating that the second digital key is not set to a pending deletion status, management server 70 can set the second digital key to an unavailable status regardless of the specified condition RC.

[0247] In this way, when the second digital key is registered, the management server 70 can determine whether to set the second digital key to the pending deletion state. That is, the management server 70 can perform the pending deletion determination in advance before obtaining the deletion request D41 for the second digital key. Therefore, after obtaining the deletion request D41 for the second digital key, the management server 70 can have already recognized the result of the deletion request determination.

[0248] User attribute

[0249] In the above-described embodiment, the user attribute UA indicates whether the user is a specific business corporation. However, the user attribute UA is not limited thereto. For example, the user attribute UA can simply indicate whether the user is a specific business operator. In this case, it is enough that the management server 70 performs the pending deletion determination based on whether the user attribute UA of the first specific device 30X indicates the specific business operator.

[0250] Further, the user attribute UA can simply indicate whether the user is a corporation. In this case, it is enough that the management server 70 performs the pending deletion determination based on whether the user attribute of the first specific device 30X is a corporation.

[0251] Further, for example, the user attribute UA can simply indicate whether the device type is a device 30 that performs short-range wireless communication. In this case, it is enough that the management server 70 performs the pending deletion determination based on whether the device type of the first specific device 30X is a device that performs short-range wireless communication.

[0252] At least, it is enough that the management server 70 performs the pending deletion determination based on the user attribute UA of the first specific device 30X. Therefore, the result of the pending deletion determination of the management server 70 can be opposite to the result in the example described in the above-described embodiment.

[0253] The management server 70 can store the user attribute UA regardless of the information indicating the user attribute UA received from the device 30. For example, the management server 70 can determine the user attribute UA depending on whether the fleet signal FL is received from the same device 30 before performing the registration management. Specifically, in a case where the fleet signal FL is received from the same device 30 before performing the registration management, the management server 70 can determine that the user attribute UA of the device 30 indicates the specific business corporation. In a case where the fleet signal FL is not received from the same device 30 before performing the registration management, the management server 70 can determine that the user attribute UA of the device 30 is not the specific business corporation.

[0254] In the above-described embodiment, the management server 70 identifies the user attribute UA by referring to the database DB stored in the storage device 72, but can identify the user attribute UA without using the database DB. For example, when the process of Step S103 is executed, the management server 70 can obtain information indicating the user attribute UA of the first specific device 30X from the first specific device 30X by communicating with the first specific device 30X. Then, the management server 70 can execute the pending deletion determination based on the obtained user attribute UA.

[0255] Method for setting the second digital key to an unusable state

[0256] The method for the management server 70 to set the second digital key to an unusable state is not limited to the above-described embodiment. For example, the management server 70 can transmit a prohibition request to prohibit the use of the authentication information AT of the second digital key to the vehicle management device 26, and the vehicle management device 26 that has received the prohibition request can prohibit the use of the authentication information AT of the second digital key.

[0257] The method for the management server 70 to cause the second specific device 30Y to delete the key information DK indicating the second digital key is not limited to the transmission of the deletion request D42. For example, the management server 70 can periodically transmit a continuation request to cause the second specific device 30Y to continue storing the key information DK indicating the second digital key. In this case, by stopping the transmission of the continuation request, the management server 70 can cause the second specific device 30Y to delete the key information DK indicating the second digital key.

[0258] The management server 70 does not necessarily need to cause the second specific device 30Y to delete the key information DK indicating the second digital key. For example, the management server 70 can set the second digital key to an unusable state by simply causing the second specific device 30Y to delete the authentication information AT of the second digital key to be deleted.

[0259] The method for the management server 70 to cause the vehicle management device 26 to delete the authentication information AT of the second digital key is not limited to the transmission of the deletion request D43. For example, the management server 70 can periodically transmit a continuation request to cause the vehicle management device 26 to continue storing the authentication information AT of the second digital key. In this case, by stopping the transmission of the continuation request, the management server 70 can cause the vehicle management device 26 to delete the authentication information AT of the second digital key.

[0260] The management server 70 does not necessarily need to cause the vehicle management device 26 to delete the authentication information AT of the second digital key. For example, the management server 70 can set the second digital key to an unusable state by simply causing the vehicle management device 26 to delete the key information DK indicating the second digital key to be deleted.

[0261] Various changes can be made to the above-described examples without departing from the spirit and scope of the claims and their equivalents. The above-described examples are merely illustrative, and not restrictive, of the present disclosure. The features described in each example should be viewed as being applicable to similar features or aspects in other examples. Suitable results can be achieved if the described sequences are performed in a different order, and / or if components in the described systems, architectures, devices, or circuitries are combined in a different manner, and / or replaced or supplemented by other components or equivalents thereof. The scope of the disclosure is not limited by the detailed description, but is instead defined by the claims and their equivalents. All variations within the scope of the claims and their equivalents are encompassed by the disclosure.

Claims

1. A management server configured to manage multiple digital keys applicable to a vehicle, wherein, The plurality of digital keys includes a target digital key and one or more participating registration digital keys that have already participated in the registration of the target digital key. The multiple digital keys are registered in multiple devices respectively. The plurality of devices includes the participating devices to which a predetermined participating registration digital key is registered. The management server is configured to perform: Based on the user attributes of the participating devices, determine whether to apply the specified conditions to the deletion of the target digital key; as well as Based on the determined result, the target digital key is set to an unavailable state.

2. The management server according to claim 1, wherein, The plurality of digital keys include: The first digital key registered in the first specific device; and The second digital key registered in the second specific device based on the registration request from the first specific device. The target digital key is the second digital key, and The digital key used for registration is the first digital key.

3. The management server according to claim 1, wherein, The plurality of devices includes the target device to which the target digital key is registered, and The management server is configured to cause the target device to delete information related to the target digital key stored in the target device, thereby setting the target digital key to an unavailable state.

4. The management server according to claim 3, wherein, The management server is configured as follows: The information associated with the target digital key is deleted by transmitting a request to the target device to delete the information associated with the target digital key.

5. The management server according to claim 1, wherein, The management server is configured as follows: The information related to the target digital key stored in the vehicle's vehicle management device is deleted, thereby setting the target digital key to an unavailable state.

6. The management server according to claim 5, wherein, The management server is configured as follows: The information associated with the target digital key is deleted by transmitting a request to the vehicle to delete the information associated with the target digital key.

7. The management server according to claim 1, wherein, The management server is configured as follows: When the user attribute indication of the participating device is a specific business operator who lent the vehicle, it is determined that the prescribed conditions will not be applied to the deletion of the target digital key.

8. The management server according to claim 1, wherein, The management server is configured as follows: When the user attributes of the participating device do not indicate that the user is a specific business operator who lent the vehicle, the specified conditions are determined to be applied to the deletion of the target digital key.

9. The management server according to claim 1, wherein, The management server is configured as follows: When the user attribute indication of the participating device is a legal entity, it is determined that the specified conditions will not be applied to the deletion of the target digital key.

10. The management server according to claim 1, wherein, The management server is configured as follows: When the user attributes of the participating device do not indicate that it is a legal entity, it is determined that the specified conditions will be applied to the deletion of the target digital key.

11. The management server according to claim 1, wherein, The management server is configured as follows: When a request is received to delete the target digital key, it is determined whether the prescribed conditions should be applied.

12. The management server according to claim 1, wherein, The management server is configured to: when registering the target digital key, determine whether to apply the specified conditions, and The management server is configured to set the target digital key to an unavailable state when a request for deletion of the target digital key is received.

13. A management method performed by a management server, said management server being configured to manage a plurality of digital keys applicable to a vehicle, wherein, The plurality of digital keys includes a target digital key and one or more participating registration digital keys that have already participated in the registration of the target digital key. The multiple digital keys are registered in multiple devices respectively. The plurality of devices includes the participating devices to which a predetermined participating registration digital key is registered, and The management method includes: Based on the user attributes of the participating devices, determine whether to apply specified conditions to the deletion of the target digital key; and Based on the determined result, the target digital key is set to an unavailable state.

14. A program product configured to be executed by a management server, the management server being a computer configured to manage multiple digital keys applicable to a vehicle, wherein, The plurality of digital keys includes a target digital key and one or more participating registration digital keys that have already participated in the registration of the target digital key. The multiple digital keys are registered in multiple devices respectively. The plurality of devices includes the participating devices to which a predetermined participating registration digital key is registered, and The program product is configured to cause the management server to execute: Based on the user attributes of the participating devices, determine whether to apply the specified conditions to the deletion of the target digital key; as well as Based on the determined result, the target digital key is set to an unavailable state.

Images