Server, in-vehicle device, vehicle, system, server management method, server program, in-vehicle device management method, and in-vehicle device program

Abstract

A management server (70) manages a plurality of digital keys that can be used for a vehicle (20). The management server (70) is provided with a transmission unit (70R). The transmission unit (70R) transmits, to the vehicle (20), restriction information (RI) pertaining to a third digital key generated on the basis of a second digital key when the second digital key is generated on the basis of a first digital key.

Description

Server, on-board device, vehicle, system, server management method, server program, on-board device management method, and on-board device program

[0001] The present disclosure relates to a server, an in-vehicle device, a vehicle, a system, a server management method, a server program, an in-vehicle device management method, and an in-vehicle device program.

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, an owner device, a shared device, and a management server. The owner device registers an owner key, which is a digital key of which only one can exist per vehicle. The shared device registers a shared key, which is a digital key of which multiple can exist per vehicle.

[0003] The management server manages multiple digital keys. When a vehicle uses a digital key, it authenticates the digital key and allows it to unlock the vehicle and perform other controls.

[0004] JP 2024-001720 A

[0005] In a management system such as that described in Patent Document 1, it is desirable to be able to register multiple digital keys to multiple devices as freely as possible under appropriate restrictions.

[0006] In a first aspect of the present disclosure, a server is configured to manage a plurality of digital keys available for a vehicle, and includes a transmitter configured to transmit, to the vehicle, restriction information about a third digital key generated based on a first digital key when the second digital key is generated based on the second digital key.

[0007] In a second aspect of the present disclosure, the in-vehicle device is an in-vehicle device mounted on a vehicle that can use multiple digital keys, and includes: a receiving unit configured to receive, from a server, restriction information regarding a third digital key that is generated based on a first digital key when a second digital key is generated based on the second digital key; and an executing unit configured to restrict, based on the restriction information, at least one of control of the vehicle when the third digital key is used and registration of the third digital key to the vehicle.

[0008] In a third aspect of the present disclosure, a system includes a vehicle that can use multiple digital keys and a server configured to manage the multiple digital keys, wherein the server includes a transmitter configured to transmit restriction information about a third digital key to the vehicle when a second digital key is generated based on the first digital key, and the vehicle includes a receiver configured to receive the restriction information, and an execution unit configured to restrict at least one of control of the vehicle when the third digital key is used and registration of the third digital key based on the restriction information.

[0009] In a fourth aspect of the present disclosure, a server management method is a management method performed by a server configured to manage a plurality of digital keys available for a vehicle, and includes, when a second digital key is generated based on a first digital key, transmitting restriction information about a third digital key generated based on the second digital key to the vehicle.

[0010] In a fifth aspect of the present disclosure, a server program is configured to cause a server that manages multiple digital keys available for a vehicle to, when a second digital key is generated based on a first digital key, transmit restriction information about a third digital key generated based on the second digital key to the vehicle.

[0011] In a sixth aspect of the present disclosure, a management method for an in-vehicle device is a management method performed by an in-vehicle device installed in a vehicle that can use multiple digital keys, and includes: when a second digital key is generated based on a first digital key, receiving restriction information from a server regarding a third digital key that is generated based on the second digital key; and, based on the restriction information, restricting at least one of control of the vehicle when the third digital key is used and registration of the third digital key to the vehicle.

[0012] In a seventh aspect of the present disclosure, a program of an in-vehicle device is configured to cause an in-vehicle device mounted on a vehicle capable of using multiple digital keys to receive, from a server, restriction information regarding a third digital key generated based on a first digital key when a second digital key is generated based on the second digital key, and to restrict at least one of control of the vehicle when the third digital key is used and registration of the third digital key to the vehicle based on the restriction information.

[0013] FIG. 1 is a schematic diagram showing a management system of an embodiment. FIG. 2 is a schematic diagram showing owner key information for an owner device of FIG. 1. FIG. 3 is a schematic diagram showing share key information for a share device of FIG. 1. FIG. 4 is a schematic diagram showing data in the database of FIG. 1. FIG. 5 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when an owner key is registered. FIG. 6 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a friend key is registered. FIG. 7 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a non-friend key is registered. FIG. 8 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a non-friend key is deleted in response to a request from a friend device. FIG. 9 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when a non-friend key is deleted in response to a request from a non-friend device. FIG. 10 is a schematic diagram showing functional units of the management system of FIG. 1. FIG. 11 is a schematic diagram showing constraint information included in the database of FIG. 1. FIG. 12 is a flowchart showing a series of processes related to transmission of constraint information performed by the management server of FIG. 1. Fig. 13 is a flowchart showing a series of processes when the vehicle management device of Fig. 1 registers a non-friend key based on the restriction information. Fig. 14 is a flowchart showing a series of processes when the vehicle management device of Fig. 1 authenticates a non-friend key based on the restriction information.

[0014] (One embodiment) A management system 10 in one embodiment will be described below with reference to the drawings. <Overview of the management system> As shown in FIG. 1 , the management system 10 manages a plurality of digital keys that can be used for a vehicle 20. In this embodiment, the management system 10 is a system. Regarding digital keys, there is a standard set by the Car Connectivity Consortium (CCC). Matters related to the digital keys in this embodiment comply with the CCC. The management system 10 includes a vehicle 20, a plurality of devices 30, a device server 60, and a management server 70.

[0015] The vehicle 20 can use multiple digital keys. The digital key is used when the user uses the digital key. The vehicle 20 has a communication module 21, an HMI 22, a BLE module 23, a UWB module 24, an NFC module 25, and a vehicle management device 26. HMI stands for Human Machine Interface. BLE stands for Bluetooth Low Energy. UWB stands for Ultra Wide Band. NFC stands for Near Field Communication. The vehicle 20 is equipped with an in-vehicle device 20A. The in-vehicle device 20A includes the communication module 21 and the vehicle management device 26.

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

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

[0018] The vehicle management device 26 is mounted 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 has an execution device 27, which is a processing circuit, and a storage device 28. The storage device 28 stores a vehicle program PV. The execution device 27 executes the vehicle program PV, causing the execution device 27 to store and delete authentication information AT. The storage device 28 is capable of storing a predetermined number of pieces of authentication information AT. The authentication information AT is information for authenticating the digital key so that the vehicle 20 can be controlled using the digital key when the digital key is used. The authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU. The execution device 27 executes the vehicle program PV to perform processing related to the storage and deletion of the authentication information AT.

[0019] When the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the digital key to be used to control the vehicle 20. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be unlocked. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be started.

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

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

[0022] The BLE module 33 performs short-range wireless communication with the vehicle 20 using BLE communication. The UWB module 34 communicates with the vehicle 20 using UWB communication. The NFC module 35 performs short-range wireless communication with the vehicle 20 using NFC communication.

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

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

[0025] The multiple devices 30 include an owner device 40 and multiple shared devices 50. The owner device 40 stores owner key information DKO indicating an owner key KO as key information DK. Only one owner key KO can be registered to one vehicle 20. Therefore, only one owner key KO exists for one vehicle 20.

[0026] 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 also includes certificate information ST5, device public key information ST6, vehicle public key information ST7, and permission public key information ST8.

[0027] The vehicle identification information ST1 is information for identifying the vehicle 20 for which the digital key is to be set. For example, it is the ID of the vehicle 20. The in-device key identification information ST2 is used for managing the digital key within the device 30. The in-device key identification information ST2 is information that can identify the digital key within the application of the device 30.

[0028] The digital key identification information ST3 is used for managing the digital key in the management server 70. The slot identification information ST4 is information that can identify the digital key locally on the device 30.

[0029] Certificate information ST5 indicates a certificate that certifies the digital key. Device public key information ST6 indicates a device public key PKD that is the public key of the device 30. The device public key PKD in the owner key information DKO indicates the public key of the owner device 40. Vehicle public key information ST7 indicates a vehicle public key PKV that is the public key of the vehicle 20. Authorization public key information ST8 indicates an already authorized vehicle public key PKV.

[0030] 1, the share device 50 stores share key information DKS indicating a share key KS as key information DK. A share key KS is a digital key that can be registered in multiple numbers for one vehicle 20 in order to enable the use of the digital key. In other words, multiple share keys KS can exist for one vehicle 20.

[0031] The multiple share devices 50 include a friend device 51 and a non-friend device 52. The friend device 51 stores, as the share key information DKS, friend key information DKF indicating the friend key KF. The non-friend device 52 stores, as the share key information DKS, non-friend key information DKN indicating the non-friend key KN. In other words, the types of share keys KS include a friend key KF and a non-friend key KN. The friend key KF is a share key KS registered based on a direct registration request D21 from the owner device 40, as described below. The non-friend key KN is a share key KS registered based on a registration request D31 from the friend device 51, as described below. In other words, the non-friend key KN is a share key KS registered based on an indirect registration request from a share device 50, which is a device 30 different from the owner device 40.

[0032] When a digital key is registered, the digital key is enabled for use, i.e., when the digital key is registered, the vehicle 20 stores the authentication information AT and the device 30 stores the key information DK.

[0033] As shown in Fig. 3, the shared key information DKS includes shared key structure information STS and an authentication package ATP. The shared key structure information STS includes vehicle identification information ST1, in-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The shared key structure information STS also includes certificate information ST5, vehicle public key information ST7, and permission public key information ST8. In other words, the shared key structure information STS is the owner key structure information STO minus the device public key information ST6.

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

[0035] The signature information ATP1 indicates that the sharing device 50 is a legitimate target for sharing a digital key. For example, in the case of the friend device 51, the signature information ATP1 indicates a signature by the owner device 40. The signature information ATP1 in the case of the friend device 51 indicates that the owner device 40 has signed the device public key PKD of the friend device 51 indicated by the device public key information ATP6. For example, in the case of the non-friend device 52, the signature information ATP1 indicates a signature by the friend device 51. The signature information ATP1 in the case of the non-friend device 52 indicates that the friend device 51 has signed the device public key PKD of the non-friend device 52 indicated by the device public key information ATP6.

[0036] The password information ATP2 indicates the pairing password PAS used to establish a secure channel when pairing the vehicle 20 and the owner device 40. The validity start time information ATP3 indicates the earliest date and time at which the shared key KS can be used. The expiration date information ATP4 indicates the latest date and time at which the shared key KS can be used. The name information ATP5 indicates a name that identifies the shared key KS. The name information ATP5 is set to an identifiable name for each shared device 50, for example, by operation from the owner device 40.

[0037] As shown in FIG. 1 , the device server 60 relays communication between the devices 30 and the management server 70. Only one device server 60 is illustrated in FIG. 1 . However, a device server 60 may be provided for each type of device 30. That is, the device server 60 with which a first type of device 30 communicates may be different from the device server 60 with which a second type of device 30 communicates. For example, the type refers to the model of the device 30, and a device server 60 is provided for each model of the device 30. For example, the type refers to the communication line used by the device 30, and a device server 60 is provided for each communication line used by the device 30.

[0038] Each device server 60 relays communication between the corresponding device 30 and the management server 70. Different types of devices 30 can communicate with the management server 70 via the corresponding device server 60.

[0039] <Management Server> The management server 70 is configured to manage a plurality of digital keys that can be used for the vehicle 20. The management server 70 is capable of communicating with the vehicle 20 and a plurality of devices 30. The management server 70 includes an execution device 71, which is a processing circuit, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 is capable of wireless communication with the communication module 21 of the vehicle 20.

[0040] The storage device 72 stores a server program PS, a monitoring program PM, and a database DB. The server program PS, when executed by the execution device 71, causes the execution device 71 to register and delete digital keys in the database DB. Details of the monitoring program PM will be described later.

[0041] The database DB contains information associating, for each of a plurality of digital keys, the corresponding vehicle 20 with the registered device 30. The data DA contained in the database DB is separated for each vehicle 20. When a digital key is registered, the management server 70 stores, in the data DA, information indicating the device 30 that stores the key information DK indicating the digital key.

[0042] As shown in Figure 4, data DA for one vehicle 20 includes the types of digital keys registered to the vehicle 20, information about the registered devices 30, information about the relationships between the registered devices 30, and restriction information RI for each type of digital key. Digital keys are divided into multiple hierarchies based on their type. From top to bottom, the hierarchies are arranged as owner keys KO, friend keys KF, and non-friend keys KN. The higher the hierarchical level, the greater the authority set for the digital key.

[0043] The authority may be, for example, the number of share keys KS that can be requested to be registered, the range of control of the vehicle 20 that can be achieved by authenticating the digital key, etc. The higher the hierarchical level of the digital key, the greater the number of share keys KS that can be requested to be registered. More specifically, for example, the number of friend keys KF that the owner device 40 can request to be registered is greater than the number of non-friend keys KN that the friend device 51 can request to be registered.

[0044] For example, the higher the hierarchical level of a digital key, the wider the controllable range of the vehicle 20. The controllable range of the vehicle 20 indicates, for example, the possible controls among control of starting the engine of the vehicle 20, control of turning on the power of the vehicle 20, and control of unlocking and locking the doors of the vehicle 20. For example, if the controllable range of the vehicle 20 includes the above-mentioned three controls, the controllable range of the vehicle 20 is wider than if the controllable range of the vehicle 20 is only control of unlocking and locking the doors of the vehicle 20. More specifically, the controllable range of the vehicle 20 that can be controlled by the friend key KF is the above-mentioned three controls, while the controllable range of the vehicle 20 that can be controlled by the non-friend key KN is only control of unlocking and locking the doors of the vehicle 20.

[0045] A state will be described in which digital keys are registered to seven devices 30 for one vehicle 20. The seven devices 30 are a first device 30A to a seventh device 30G. The digital keys registered in the first device 30A to the seventh device 30G are a first digital key to a seventh digital key, respectively. This information is included in the data DA.

[0046] The device 30 in which the owner key KO is registered as a digital key is the first device 30A. That is, the first device 30A is the owner device 40. That is, the first digital key is the owner key KO.

[0047] The devices 30 in which the shared key KS is registered as a 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. That is, 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 shared devices 50. That is, the second digital key to the seventh digital key are all shared keys KS.

[0048] More specifically, the devices 30 in which the friend key KF is registered as the share key KS are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are friend devices 51. The devices 30 in which the non-friend key KN is registered as the share key KS are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

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

[0051] The relationship between the third device 30C and the second device 30B is such that the non-friend key KN is registered in the third device 30C based on a registration request from the second device 30B. In other words, the third digital key is registered based on the second digital key.

[0052] The relationship between the fourth device 30D and the second device 30B is such that the non-friend key KN is registered in the fourth device 30D based on a registration request from the second device 30B. In other words, the fourth digital key is registered based on the second digital key.

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

[0054] In the data DA, the relationship between the seventh device 30G and the fifth device 30E is such that the non-friend key KN is registered in the seventh device 30G due to a registration request from the fifth device 30E. In other words, the seventh digital key is registered based on the fifth digital key.

[0055] In this way, the data DA includes information about the device 30 to which the digital key is registered. When the device 30 is registered, information indicating the device 30 that made the request that caused the registration is linked to the device 30. The data DA also includes information indicating which digital key each digital key is registered under.

[0056] The data DA includes restriction information RI defined for each type of digital key. The restriction information RI for the owner key KO is defined as no restriction. Therefore, no restriction is imposed on the owner device 40. The restriction information RI for the friend key KF is defined as first restriction information RI1. Therefore, the restriction indicated by the first restriction information RI1 is imposed on the friend device 51. The restriction information RI for the non-friend key KN is defined as second restriction information RI2. Therefore, the restriction indicated by the second restriction information RI2 is imposed on the non-friend device 52. The restriction information RI will be described in detail below.

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

[0058] 5, the management system 10 performs a series of processes to register the owner key KO. The following describes an example of registering the owner key KO for the first device 30A that does not store key information DK indicating the owner key KO.

[0059] By registering the owner key KO, the management system 10 causes the first device 30A to store key information DK indicating the owner key KO. By registering the owner key KO, the management system 10 causes the vehicle 20 to store authentication information AT for authenticating the owner key KO. As a result, the first device 30A is set as the owner device 40. When registering the owner key KO, necessary applications are pre-installed in the first device 30A.

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

[0061] Then, vehicle 20 receives pairing password PAS. After receiving pairing password PAS, vehicle 20 is set to pairing mode via HMI 22. Vehicle 20 waits in a state in which it can receive a password from first device 30A. Then, vehicle 20 proceeds to step S12.

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

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

[0064] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. Then, the first device 30A proceeds to step S15. In step S15, the first device 30A stores the owner key information DKO. As a result, the first device 30A becomes the owner device 40. Then, the first device 30A transmits, to the vehicle 20, certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD.

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

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

[0067] Thereafter, when the first device 30A receives the completion notification M11, the first device 30A performs the process of step S18. In step S18, the first device 30A generates a key track request D12 for the owner key KO. The key track request D12 is a signal requesting the management server 70 to update the database DB. The first device 30A then transmits the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0068] Thereafter, when the management server 70 receives the key track request D12, it performs processing in step S19. In step S19, the management server 70 performs registration management of the owner key KO. Specifically, the management server 70 stores, as data DA of the vehicle 20 in the database DB, that the device 30 in which the owner key KO is registered is the first device 30A. This causes the management system 10 to complete the series of processes for registering the owner key KO.

[0069] 6, the management system 10 performs a series of processes to register a friend key KF. Below, an example will be described in which the series of processes is used to register a friend key KF for a second device 30B that does not store friend key information DKF.

[0070] When an operation to request registration of a friend key KF is executed in the owner device 40, the owner device 40 first performs the process of step S21. In step S21, the owner device 40 transmits a friend key KF registration request D21 to a relay server (not shown). Then, the owner device 40 proceeds to step S22.

[0071] In step S22, the owner device 40 obtains invitation information IV1 for sharing the digital key from the relay server. The invitation information IV1 is, for example, a URL link. The URL link stores share information SH1 required for sharing the digital key. The owner device 40 then transmits the invitation information IV1 to the second device 30B.

[0072] After that, when the second device 30B receives the invitation information IV1, it performs the process of step S23. In step S23, the second device 30B acquires the share information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the share information SH1 from the link source of the URL link.

[0073] The share information SH1 includes, for example, share key structure information STS, password information ATP2, validity start time information ATP3, expiration date information ATP4, and name information ATP5. The validity start time information ATP3, expiration date information ATP4, and name information ATP5 are set by the owner device 40. The second device 30B then proceeds to step S24.

[0074] In step S24, the second device 30B uses the share information SH1 to generate signature-less friend key information DKFN. The signature-less friend key information DKFN is friend key information DKF that does not include signature information ATP1. The second device 30B then transmits to the owner device 40 a completion notification M21 indicating that the generated signature-less friend key information DKFN has been uploaded to the URL link, and a signature request D22 requesting a signature.

[0075] The owner device 40 then receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 acquires the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process of step S25 in response to an operation of the owner device 40.

[0076] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 causes the HMI 32 to present the acquired signature-free friend key information DKFN and accepts an operation by the user of the owner device 40 indicating consent to the registration of the friend key KF. When this operation is performed, the owner device 40 generates signature information ATP1 based on the operation. The owner device 40 then proceeds to step S26.

[0077] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. This causes the owner device 40 to generate friend key information DKF. The owner device 40 then uploads the generated friend key information DKF to the URL link, which is the invitation information IV1. The owner device 40 then transmits a completion notification M22 to the second device 30B, indicating that the completed friend key information DKF has been uploaded to the URL link.

[0078] The second device 30B then receives the completion notification M22. The second device 30B then performs the process of step S27. In step S27, the second device 30B downloads and stores the friend key information DKF. As a result, the second device 30B is set as a friend device 51. The second device 30B then proceeds to step S28.

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

[0080] Thereafter, when the management server 70 receives a key track request D23 for 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.

[0081] Specifically, the management server 70 confirms that the friend key KF that is the target of the key track request D23 is not on the reject list. The reject list is a list that shows the share keys KS that include the friend key KF and the non-friend key KN for which a deletion request has already been received. If the friend key KF is on the reject list, the management server 70 sends a notification to the second device 30B that the key track request D23 cannot be fulfilled.

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

[0083] Thereafter, the management server 70 transmits the authentication package ATP included in the friend key information DKF, a storage request D24 requesting storage of the authentication package ATP, and the first constraint information RI1 to the vehicle 20. That is, the management server 70 transmits 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.

[0084] Thereafter, when the vehicle 20 receives 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 authentication information AT for authenticating the friend key KF.

[0085] After completing the registration management, the management server 70 transmits a key track completion notification M23 to the second device 30B. Thereafter, upon receiving the key track completion notification M23, the second device 30B performs the processing of step S31. In the processing of step S31, the second device 30B presents information indicating the completion of the registration of the friend key KF to the HMI 32. For example, the second device 30B presents an image indicating the completion of the registration of the friend key KF to the HMI 32. For example, the second device 30B displays an image indicating the completion of the registration of the friend key KF on the HMI 32. This causes the management system 10 to complete the series of processes for registering the friend key KF.

[0086] 7, the management system 10 performs a series of registration processes to register a non-friend key KN. Below, an example will be described in which the series of processes is used to register a non-friend key KN for a third device 30C that does not store non-friend key information DKN.

[0087] When an operation to request registration of a non-friend key KN is executed on the friend device 51, the friend device 51 first performs the process of step S41. In step S41, the friend device 51 transmits a registration request D31 of the non-friend key KN to a relay server (not shown). Then, the friend device 51 proceeds to the process of step S42.

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

[0089] After that, when the third device 30C receives the invitation information IV2, it performs the process of step S43. In step S43, the third device 30C acquires the share information SH2 based on the invitation information IV2. Specifically, the second device 30B downloads the share information SH2 from the URL link.

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

[0091] In step S44, the third device 30C uses the share information SH2 to generate unsigned non-friend key information DKNN. The unsigned non-friend key information DKNN is non-friend key information DKN that does not have the signature information ATP1. The third device 30C then transmits to the friend device 51 a completion notification M31 indicating that the generated unsigned non-friend key information DKNN has been uploaded to the URL link, and a signature request D32 requesting a signature.

[0092] The friend device 51 then receives a completion notification M31 and a signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 acquires the unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process of step S45 in response to an operation of the friend device 51.

[0093] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 causes the HMI 32 to present the acquired signature-less non-friend key information DKNN, and accepts an operation by the user of the friend device 51 indicating consent to the generation of the non-friend key KN. When the operation is performed, the friend device 51 generates signature information ATP1 based on the operation. The friend device 51 then proceeds to step S46.

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

[0095] The third device 30C then receives the completion notification M32. The third device 30C then performs the process of step S47. In step S47, the third device 30C downloads and stores the non-friend key information DKN. As a result, the third device 30C is set as a non-friend device 52. The third device 30C then proceeds to step S47.

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

[0097] Thereafter, when the management server 70 receives a key track request D33 for the non-friend key KN, the management server 70 performs the process of step S49. In step S49, the management server 70 performs registration management of the non-friend key KN.

[0098] Specifically, the management server 70 confirms that the non-friend key KN that is the target of the key track request D33 is not on the rejection list. If the non-friend key KN is on the rejection list, the management server 70 sends a notification to the third device 30C that the key track request D33 cannot be fulfilled.

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

[0100] Thereafter, the management server 70 transmits the authentication package ATP included in the non-friend key information DKN, a storage request D34 requesting storage of the authentication package ATP, and second constraint information RI2 to the vehicle 20. That is, the management server 70 transmits device public key information ST6 indicating the device public key PKD of the non-friend device 52 to the vehicle 20. The management server 70 notifies the vehicle 20 that the device public key PKD is signed by the friend device 51.

[0101] Thereafter, when the vehicle 20 receives the authentication package ATP and the storage request D34, the vehicle 20 performs the process of step S50. In step S50, the vehicle 20 stores the received authentication package ATP. The authentication package ATP is authentication information AT for authenticating the non-friend key KN.

[0102] After completing the registration management, the management server 70 transmits a key track completion notification M33 to the second device 30B. After that, upon receiving the key track completion notification M33, the second device 30B performs the processing of step S51. In the processing of step S51, the third device 30C presents information indicating the completion of registration of the non-friend key KN to the HMI 32. For example, the third device 30C displays an image indicating the completion of registration of the non-friend key KN on the HMI 32. This causes the management system 10 to complete the series of processes for registering the non-friend key KN.

[0103] <Deleting a Non-Friend Key> Next, a series of processes for deleting a non-friend key KN in the management system 10 will be described. Below, a series of flows from a state in which a non-friend key KN is registered to a state in which the non-friend key KN is not registered will be described. In the following explanation, the process executed by the execution unit 27 will be described as a process executed by the vehicle 20. The process executed by the execution unit 36 ​​will be described as a process executed by the device 30. The process executed by the execution unit 71 will be described as a process executed by the management server 70.

[0104] <Deleting a Non-Friend Key in Response to a Deletion Request from a Friend Device> As shown in FIG. 8, the management system 10 performs a series of processes to delete a non-friend key KN in response to a reservation deletion request D41 from a friend device 51.

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

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

[0107] Thereafter, when the management server 70 receives the reservation deletion request D41 for the non-friend key KN, it performs processing in step S62. In step S62, the management server 70 generates a deletion in progress notification M41 indicating that the reservation is being deleted in accordance with the reservation deletion request D41. Then, the management server 70 transmits the deletion in progress notification M41 to the friend device 51.

[0108] Thereafter, when the friend device 51 receives the deletion notification M41, the friend device 51 performs the process of step S63. In step S63, the friend device 51 presents to the HMI 32 information indicating that the non-friend key KN that is the target of the reservation deletion request D41 is being deleted.

[0109] After the process of step S62, the management server 70 performs the process of step S64. In step S64, the management server 70 stores the state of the non-friend key KN that is the target of the reservation deletion request D41 as a fade-out state in the database DB. The fade-out state is a state that occurs after the reservation deletion request D41 is received and execution of deletion is pending. Then, the management server 70 proceeds to the process of step S65.

[0110] In step S65, the management server 70 confirms that the prescribed condition RC is satisfied. If the management server 70 confirms that the prescribed condition RC is satisfied, the management server 70 proceeds to step S66.

[0111] In step S66, the management server 70 generates a deletion request D42 for deleting the non-friend key information DKN indicating the non-friend key KN that is the target of the reservation deletion request D41. Then, the management server 70 transmits the deletion request D42 to the non-friend device 52.

[0112] Thereafter, when the non-friend device 52 receives the deletion request D42, it performs processing in step S67. In step S67, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion request D42. Then, the non-friend device 52 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.

[0113] Thereafter, when the management server 70 receives the completion notification M42, the management server 70 performs the process of step S68. In step S68, the management server 70 stores the history of the deletion of the non-friend key information DKN in the non-friend device 52. Thereafter, the management server 70 proceeds to the process of step S69.

[0114] In step S69, 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 non-friend key KN that is the target of the reservation deletion request D41. The management server 70 then transmits the deletion request D43 to the vehicle 20.

[0115] Thereafter, when the vehicle 20 receives the deletion request D43, the vehicle 20 performs the processing of step S70. In step S70, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN that is the subject of the reservation deletion request D41 in accordance with the deletion request D43. That is, the vehicle 20 deletes the authentication package ATP of the non-friend key KN. The vehicle 20 then 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.

[0116] Thereafter, when the management server 70 receives the completion notification M43, the management server 70 performs the process of step S71. In step S71, the management server 70 stores the deletion history of the authentication information AT for authenticating the non-friend key KN to be deleted in the current series of deletion-related processes in the vehicle 20. Thereafter, the management server 70 proceeds to step S72.

[0117] In step S72, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN to be deleted in this series of processes from the data DA of the vehicle 20 in the database DB. Thereafter, the management server 70 transmits a completion notification M44 to the friend device 51, indicating that the series of deletions of the non-friend key KN in accordance with the reservation deletion request D41 has been completed.

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

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

[0120] When a predetermined operation requesting the deletion of the non-friend key KN is executed in the non-friend device 52, the non-friend device 52 first performs the processing of step S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN in accordance with the predetermined operation. Thereafter, the non-friend device 52 transmits a completion notification M51 indicating that the deletion of the non-friend key information DKN has been completed to the management server 70.

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

[0122] Thereafter, when the friend device 51 receives the completion notification M52, the friend device 51 performs the process of step S83. In step S83, the friend device 51 presents, to the HMI 32, information indicating that the deletion of the non-friend key information DKN of the non-friend device 52 has been completed. For example, the friend device 51 displays, on the HMI 32, an image indicating that the deletion of the non-friend key KN has been completed.

[0123] After processing in step S82, the management server 70 performs processing in step S84. In step S84, the management server 70 generates a deletion request D51 for deleting the authentication information AT for authenticating the non-friend key information DKN whose deletion has been completed in the completion notification M51. The management server 70 then transmits the deletion request D51 to the vehicle 20.

[0124] Thereafter, when the vehicle 20 receives the deletion request D51, the vehicle 20 performs the processing of step S85. In step S85, the vehicle 20 deletes the authentication information AT for authenticating the non-friend key KN deleted in the processing of step S81 in accordance with the deletion request D51. The vehicle 20 then transmits to the management server 70 a completion notification M53 indicating that the deletion of the authentication information AT in accordance with the deletion request D51 has been completed.

[0125] Thereafter, when the management server 70 receives the completion notification M53, the management server 70 performs the process of step S86. In step S86, the management server 70 stores the history of the deletion of the authentication information AT for authenticating the non-friend key KN deleted in step S81. Thereafter, the management server 70 proceeds to the process of step S87.

[0126] In step S87, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN to be deleted in this series of processes from the data DA of the vehicle 20 in the database DB. This causes the management system 10 to end the series of processes for deleting the non-friend key KN.

[0127] <Functional Units of the Management System> Next, the functional units of the management system 10 will be described. As shown in Fig. 10, in the management system 10, the management server 70 has a transmitting unit 70S, a memory unit 70M, and a receiving unit 70R. The storage device 72 functions as the memory unit 70M. The memory unit 70M stores a database DB.

[0128] The execution device 71 functions as a receiver 70R. The receiver 70R receives a key track request from the device 30 via the communication module 73. The execution device 71 functions as a transmitter 70S. When a second digital key is generated based on the first digital key, the transmitter 70S transmits restriction information RI for a third digital key generated based on the second digital key to the vehicle 20. In particular, the transmitter 70S transmits authentication information AT and restriction information RI to the vehicle 20 in response to the receiver 70R receiving the key track request.

[0129] As shown in FIG. 1 , in the management server 70, the storage device 72 stores a constraint program PC. When the execution device 71 receives any of the key track request D12, key track request D23, and key track request D33, it executes the constraint program PC. The constraint program PC is a program that causes the execution device 71 to execute a series of processes, thereby causing the execution device 71 to function as a transmission unit 70S. The constraint program PC is a server program in this embodiment. By the management server 70 executing the constraint program PC, the management server 70 performs a server management method.

[0130] 10, in the management system 10, the in-vehicle device 20A includes a receiving unit 20R, a memory unit 20M, and an execution unit 20E. The memory device 28 functions as the memory unit 20M. The memory unit 20M stores authentication information AT.

[0131] The execution device 27 functions as the receiving unit 20R. The receiving unit 20R receives restriction information RI from the management server 70 via the communication module 21. The execution device 27 functions as the execution unit 20E. Based on the restriction information RI, the execution unit 20E restricts control of the vehicle 20 when the third digital key is used and restricts registration of the third digital key to the vehicle 20.

[0132] As shown in FIG. 1 , in the vehicle 20, the storage device 28 stores a vehicle program PV. The execution device 27 executes the vehicle program PV to function as the receiving unit 20R and the execution unit 20E. That is, the vehicle program PV is a program that causes the execution device 27 to function as the receiving unit 20R and the execution unit 20E. In this embodiment, the vehicle program PV is a program of the in-vehicle device 20A. By the in-vehicle device 20A executing the vehicle program PV, the in-vehicle device 20A performs the management method for the in-vehicle device 20A.

[0133] 11, the restrictions indicated by the restriction information RI include registration restrictions EM and usage restrictions UM. The registration restrictions EM are restrictions imposed on the vehicle management device 26 when registering a non-friend key KN. The registration restrictions EM include registration prohibitions RME and registration permitted items PME.

[0134] The registration prohibitions RME are prohibitions that the vehicle management device 26 must obscure when registering a non-friend key KN based on a registration request from a sharing device 50. The registration prohibitions RME include registering more non-friend keys KN than the upper limit number LM based on a registration request from the sharing device 50. The upper limit number LM is a value determined for each sharing device 50. For example, the upper limit number LM is determined as a predetermined value for each sharing device 50.

[0135] The registration allowance items PME are items that the vehicle management device 26 allows when registering a non-friend key KN based on a registration request from the sharing device 50. The registration allowance items PME include that a maximum number of non-friend keys KN up to the upper limit number LM may be registered based on a registration request from the sharing device 50.

[0136] The usage restrictions UM are restrictions that the vehicle management device 26 must adhere to when using the non-friend key KN based on a registration request from the share device 50. The usage restrictions UM include prohibited usage items RMU and permitted usage items PMU.

[0137] The prohibited items during use RMU are items that are prohibited by the vehicle management device 26 that stores the non-friend key information DKN indicating the non-friend key KN when using the non-friend key KN based on a registration request from the share device 50. The prohibited items during use RMU include the range of control of the vehicle 20 that cannot be permitted by the non-friend key KN. The range of control of the vehicle 20 that cannot be permitted by the non-friend key KN includes, for example, control of starting the engine of the vehicle 20, but does not include control of unlocking or locking the doors of the vehicle 20.

[0138] The usage allowance items PMU are items that are allowed by the vehicle management device 26 that stores the authentication information AT of the non-friend key KN when using the non-friend key KN based on a registration request from the share device 50. The usage allowance items PMU include the range of control of the vehicle 20 that can be permitted by the non-friend key KN. The range of control of the vehicle 20 that can be permitted by the non-friend key KN includes, for example, unlocking and locking control of the doors of the vehicle 20, but does not include starting control of the engine of the vehicle 20.

[0139] <Transmission of Restriction Information> Next, a series of processes related to the restriction information of the friend key KF in the management system 10 will be described.

[0140] 12, when the execution device 71 starts executing the restriction program PC, the execution device 71 first performs the processing of step S101. In step S101, the execution device 71 identifies the device 30 that sent the received key track request. As a result, the execution device 71 identifies the device 30 that stores key information DK indicating the digital key in the process related to the series of digital key registrations including the received key track request. The execution device 71 then proceeds to step S102. The digital key related to the key track request received by the execution device 71 is a specific share key KS.

[0141] In step S102, the execution device 71 determines whether the identified device 30 is a share device 50. If the identified device 30 is a share device 50 (S102: YES), the execution device 71 proceeds to step S103. The identified share device 50 is a specific share device. A specific share device is a share device 50 that stores share key information DKS indicating a specific share key KS.

[0142] In step S103, the execution device 71 identifies the restriction information RI to be transmitted to the vehicle 20. For example, the execution device 71 first references the identified share device 50 and the database DB. Next, the execution device 71 identifies whether the identified share device 50 is a friend device 51 or a non-friend device 52. Then, the execution device 71 identifies the restriction information RI associated with the type of the identified device 30.

[0143] The executing device 71 then proceeds to step S104. In step S104, the executing device 71 transmits the authentication package ATP and the storage request D24 to the vehicle 20, and also transmits the identified restriction information RI and information identifying the identified shared device 50 to the vehicle 20. Specifically, if the type of the identified device 30 is a friend device 51, the executing device 71 transmits first restriction information RI1 to the vehicle 20 as the restriction information RI. If the type of the identified device 30 is a non-friend device 52, the executing device 71 transmits second restriction information RI2 to the vehicle 20 as the restriction information RI. The executing device 71 then terminates this series of processes.

[0144] If the identified device 30 is not a shared device 50 (S102: NO), the execution device 71 ends the current series of processes. Therefore, if the type of the identified device 30 is the owner key KO, the execution device 71 does not transmit the restriction information RI to the vehicle 20. Thereafter, the execution device 71 ends the current series of processes.

[0145] 13 , when the vehicle 20 receives the restriction information RI, the execution device 27 performs processing in step S111. In step S111, the execution device 27 associates the restriction information RI with information indicating the shared device 50 that has requested registration and the authentication information AT and stores them in the storage device 28. The execution device 27 then proceeds to step S112.

[0146] In step S112, the execution device 27 performs a process of restricting storage of the authentication information AT based on the registration constraints EM included in the constraint information RI stored in step S111. Specifically, upon receiving the storage request D34 and information identifying the identified shared device 50, the execution device 27 first identifies the constraint information RI associated with the shared device 50 identified by the information identifying the identified shared device 50. Next, the execution device 27 restricts storage of the authentication information AT based on the storage request D34 based on the registration constraints EM included in the identified constraint information RI. Specifically, the execution device 27 permits items included in the registration permitted items PME and prohibits items included in the registration prohibited items RME. Specifically, if the number of pieces of authentication information AT stored based on a registration request from the shared device 50 indicated by the information identifying the identified shared device 50 is equal to the allowable upper limit LM, the execution device 27 does not store the authentication information AT even when it receives the storage request D34. That is, even if the registration process for the third digital key is initiated, the execution unit 20E prohibits the registration of the third digital key to the vehicle 20. The execution unit 20E prohibits the storage of a number of pieces of authentication information AT exceeding the upper limit number LM. After the execution device 27 performs the process of limiting the storage of authentication information AT, the execution device 27 ends the current series of processes.

[0147] <Restrictions When a Non-Friend Key is Used> Next, the following describes how the vehicle management device 26 restricts the control of the vehicle 20 by authenticating the non-friend key KN.

[0148] 14, when the vehicle management device 26 authenticates the non-friend key KN based on short-range communication with the non-friend device 52, the execution device 27 performs processing in step S121. In step S121, the execution device 27 identifies the authentication information AT used when authenticating the non-friend key KN. Thereafter, the execution device 27 proceeds to step S122.

[0149] In step S122, the execution device 27 determines whether or not the identified authentication information AT is associated with restriction information RI. Specifically, the execution device 27 determines whether or not there is restriction information RI associated with the identified authentication information AT.

[0150] If the restriction information RI is linked to the identified authentication information AT (S122: YES), the execution device 27 proceeds to step S123. In step S123, the execution device 27 restricts the control content of the vehicle 20 based on the usage restrictions UM included in the restriction information RI linked to the identified authentication information AT. Specifically, the execution device 27 permits the items included in the usage restrictions PMU included in the restriction information RI linked to the identified authentication information AT, and prohibits the items included in the usage restrictions RMU included in the restriction information RI. Specifically, the execution device 27 permits the unlocking and locking of the doors of the vehicle 20, and prohibits the starting of the engine of the vehicle 20. After that, the execution device 27 ends the current series of processes.

[0151] On the other hand, if the restriction information RI is not linked to the identified authentication information AT (S122: NO), the execution device 27 ends the current series of processes. In this case, the execution device 27 does not restrict the control content of the vehicle 20.

[0152] According to the above embodiment, when registering a share key KS, which is a third digital key, the transmitter 70S of the management server 70 transmits restriction information RI to the vehicle 20 that stores authentication information AT for authenticating the share key KS. Upon receiving the restriction information RI, the vehicle management device 26 of the vehicle 20 restricts control of the vehicle 20 based on the restriction information RI.

[0153] <Effects of one embodiment> (1) According to the above embodiment, the transmitter 70S transmits the restriction information RI for the third digital key to the vehicle 20, thereby making it possible to set restrictions in advance on the third digital key that may be registered in the future.

[0154] (2) According to the above embodiment, the restriction information RI is used to restrict control of the vehicle 20 when the third digital key is used and to restrict registration of the third digital key. Therefore, the management system 10 can restrict control of the vehicle 20 when a third digital key that may be registered in the future is used and to restrict registration of the third digital key.

[0155] (3) According to the above embodiment, the transmission unit 70S transmits the restriction information RI to the vehicle 20 together with the authentication package ATP and the storage request D24. Therefore, the vehicle management device 26 can obtain the restriction information RI before the non-friend key KN that is the target of the restriction information RI is registered. The management server 70 may transmit the restriction information RI and the authentication package ATP to the vehicle 20 without transmitting the storage request D24. In this case, the vehicle 20 stores the authentication package ATP even without receiving the storage request D24.

[0156] (4) According to the above embodiment, the management server 70 includes a storage unit 70M and a receiving unit 70R. In response to the receiving unit 70R receiving a key track request, the transmitting unit 70S transmits the authentication package ATP, which is the authentication information AT, and the restriction information RI to the vehicle 20. Therefore, the transmitting unit 70S can transmit the restriction information RI to the vehicle 20 in conjunction with a series of registration processes.

[0157] (5) The in-vehicle device 20A includes a receiving unit 20R and an executing unit 20E. When the second digital key is generated based on the first digital key, the receiving unit 20R receives, from the management server 70, restriction information RI for the third digital key generated based on the second digital key. The executing unit 20E restricts control of the vehicle 20 when the third digital key is used and restricts registration of the third digital key to the vehicle 20 based on the restriction information RI. This prevents the in-vehicle device 20A from excessively permitting control of the vehicle 20 and registration of the third digital key to the vehicle 20 using the non-friend key KN, which is the third digital key.

[0158] (6) According to the above embodiment, the restriction information RI includes the registration restriction items EM. Therefore, the vehicle management device 26 of the vehicle 20 that receives the restriction information RI restricts control of the vehicle 20 based on the registration restriction items EM when registering the non-friend key KN. Therefore, the management system 10 can restrict the vehicle management device 26 from excessively allowing control of the vehicle 20 based on the registration restriction items EM when registering the non-friend key KN.

[0159] (7) According to the above embodiment, the registration restrictions EM include the registration prohibitions RME. The vehicle management device 26 of the vehicle 20 that receives the restriction information RI prohibits the control indicated by the registration prohibitions RME. Therefore, the management system 10 can prevent the vehicle management device 26 from performing the control indicated by the registration prohibitions RME.

[0160] (8) According to the above embodiment, the registration prohibition RME includes transmitting a request to register a non-friend key KN that exceeds the upper limit LM of the number of non-friend keys KN that can be registered. The vehicle management device 26 of the vehicle 20 that receives the restriction information RI can prevent the storage of authentication information AT for non-friend keys KN that exceeds the upper limit LM. That is, the execution unit 20E prohibits the storage of authentication information AT for a number of non-friend keys KN that exceeds the upper limit LM. As a result, the management system 10 can prevent the use of non-friend keys KN that exceed the upper limit LM.

[0161] (9) According to the above embodiment, the registration constraints EM include the registration allowances PME. The vehicle management device 26 of the vehicle 20 that receives the constraint information RI allows the control indicated by the registration allowances PME. Therefore, the management system 10 can prevent the vehicle 20 from prohibiting the control indicated by the registration allowances PME.

[0162] (10) According to the above embodiment, the registration allowance PME includes the ability to store authentication information AT for non-friend keys KN up to the upper limit number LM. Therefore, the management system 10 can prevent the vehicle management device 26 from being restricted from storing authentication information AT for non-friend keys KN up to the upper limit number LM.

[0163] (11) According to the above embodiment, the restriction information RI includes the usage restrictions UM. When the vehicle management device 26 of the vehicle 20 receives the restriction information RI and authenticates the non-friend key KN, it restricts control of the vehicle 20 based on the usage restrictions UM. Therefore, when the management system 10 authenticates the non-friend key KN, it can restrict the vehicle management device 26 from excessively allowing control of the vehicle 20 based on the usage restrictions UM.

[0164] (12) According to the above embodiment, the usage restrictions UM include the usage prohibitions RMU. The vehicle management device 26 of the vehicle 20 that receives the restriction information RI prohibits the control indicated by the usage prohibitions RMU. Therefore, the management system 10 can prevent the vehicle management device 26 from performing the control indicated by the usage prohibitions RMU.

[0165] (13) According to the above embodiment, the prohibited items RMU during use do not include the unlocking and locking control of the doors of the vehicle 20, but include the starting control of the engine of the vehicle 20. Therefore, when the vehicle management device 26 of the vehicle 20 receives the restriction information RI and authenticates the non-friend key KN, it prohibits the starting control of the engine of the vehicle 20, but does not have to prohibit the unlocking and locking control of the doors of the vehicle 20.

[0166] (14) According to the above embodiment, the usage restrictions UM include the usage allowances PMU. The vehicle management device 26 of the vehicle 20 that receives the restriction information RI allows the control indicated by the usage allowances PMU. Therefore, the management system 10 can prevent the vehicle management device 26 from prohibiting the control indicated by the usage allowances PMU.

[0167] (15) According to the above embodiment, the usage allowance items PMU do not include engine start control of the vehicle 20, but include unlocking and locking control of the doors of the vehicle 20. Therefore, when the vehicle management device 26 of the vehicle 20 receives the restriction information RI and authenticates the non-friend key KN, it prohibits engine start control of the vehicle 20, but does not have to prohibit unlocking and locking control of the doors of the vehicle 20.

[0168] (Other Embodiments) The above embodiment can be modified as follows: The above embodiment and the following modifications can be combined with each other within the scope of technical compatibility.

[0169] The vehicle 20 does not need to have some of the BLE module 23, the UWB module 24, and the NFC module 25. As long as the vehicle 20 has at least one of these modules, it can perform short-range wireless communication with the device 30. The vehicle 20 is not limited to these modules, and it is sufficient that the vehicle 20 has a module that performs short-range wireless communication with the device 30.

[0170] The digital key-related matters in the above embodiments do not have to comply with the CCC. The vehicle management device 26 is not limited to a digital key ECU. For example, the vehicle management device 26 may be a central ECU that manages multiple ECUs in the vehicle 20.

[0171] In the above embodiment, the management server 70 includes an execution device 71, which is a processing circuit including one or more processors that execute various processes according to a computer program (software). However, the management server 70 may also include a processing circuit including one or more dedicated hardware circuits, such as an application-specific integrated circuit (ASIC), that executes at least some of the various processes. Alternatively, the management server 70 may include a processing circuit including a combination of one or more processors and one or more dedicated hardware circuits. The processor includes a CPU and memory, such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to execute processes. The memory, i.e., computer-readable medium, includes any available medium accessible by a general-purpose or dedicated computer. The same applies to the device 30 and the vehicle management device 26.

[0172] The device 30 is not limited to a smartphone. The device 30 may be a smartwatch. The device 30 may be a predetermined server. In this case, the predetermined server may include the device 30. For example, if a rental business operator or a sharing business operator is the owner of the vehicle 20, the owner device 40 may be included in the predetermined server. For example, the friend device 51 may be included in the predetermined server.

[0173] In each of the above embodiments, digital keys are arranged in a hierarchy of owner keys KO, friend keys KF, and non-friend keys KN, with the higher the hierarchy, the greater the authority assigned to the digital key. Digital keys do not necessarily have to be set so that the higher the hierarchy, the greater the authority assigned to the key. For example, the same authority may be assigned to the three hierarchical levels of the owner keys KO, friend keys KF, and non-friend keys KN.

[0174] The share device 50 has a function to receive the share key KS as in the above embodiment. A device 30 having a function to receive a digital key, such as the share device 50, is sometimes called a receiver device.

[0175] The device server 60 does not have to be provided for each type of device 30. It is sufficient that multiple devices 30 and the management server 70 are capable of wireless communication. The device server 60 may be omitted. It is sufficient that multiple devices 30 and the management server 70 are capable of direct wireless communication.

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

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

[0178] <Usage Restrictions> The items indicated by the usage restrictions are not limited to those in the above embodiment. For example, the usage restrictions may include a restriction on the maximum speed that the vehicle 20 can output. For example, the usage restrictions may include a restriction on the power, such as torque or acceleration, that the vehicle 20 can output. For example, the usage restrictions may include a restriction on the audio volume that the vehicle 20 can output. For example, the usage restrictions may include at least one of a restriction on the geographical area in which the vehicle 20 can be used, a restriction on available multimedia functions, a restriction on communication, such as the amount and speed of communication by the communication module 21, a restriction on disabling various safety functions of the vehicle 20, and a restriction on disabling the rear doors and trunk of the vehicle 20.

[0179] The prohibited items RMU during use are not limited to the examples in the above embodiment. For example, the prohibited items RMU during use may include at least one of the following: control of an air conditioner of the vehicle 20, control of charging the battery of the vehicle 20, and control of opening and closing the power windows of the vehicle 20.

[0180] The usage permission items PMU are not limited to the examples in the above embodiment. For example, the usage permission items PMU may include at least one of the following: control of an air conditioner of the vehicle 20, control of charging the battery of the vehicle 20, and control of opening and closing the power windows of the vehicle 20.

[0181] The usage restrictions UM may include only one of the usage prohibitions RMU and usage permits PMU. For example, if the usage restrictions UM include only the usage prohibitions RMU, it may be specified that all items not included in the usage prohibitions RMU are permitted.

[0182] <Registration Restrictions> The upper limit number LM may be a value determined for the entire management system 10. The registration prohibitions RME are not limited to the example described in the above embodiment. For example, the registration permits PME may include a condition that permits storing authentication information AT of a non-friend key KN intended for a specific device 30 when a predetermined condition is met. For example, the condition may be that the specific device 30 is registered in a predetermined server in advance. The registration prohibitions RME may include a condition that prohibits setting a validity period exceeding the upper limit of the validity period of the third digital key, the share key KS. For example, setting a third digital key, the share key KS, beyond a predetermined period or expiration date may be prohibited.

[0183] The registration permitted items PME are not limited to the example in the above embodiment. The registration permitted items PME may be any items that are not included in the registration prohibited items RME. For example, in accordance with a modified example of the registration prohibited items RME, the registration permitted items PME may include an item that allows the storage of authentication information AT of a non-friend key KN intended for a specific device 30 if predetermined conditions are met.

[0184] The registration constraints EM may include only the items in either the registration prohibitions RME or the registration allowances PME. For example, if the registration constraints EM include only the usage prohibitions RMU, it may be specified that all items not included in the usage prohibitions RMU are allowed.

[0185] <Restriction Information> The management server 70 may transmit the restriction information RI to the vehicle 20 at a different timing from the storage request D34. For example, the management server 70 may transmit the restriction information RI after transmitting the storage request D24. For example, if the management server 70 transmits the restriction information RI before transmitting the storage request D34, it can restrict control of the vehicle 20 based on the registration restrictions EM. The management server 70 may also transmit the restriction information RI after transmitting the storage request D34. Even in this case, it is possible to restrict control of the vehicle 20 based on the usage restrictions UM.

[0186] The non-friend device 52 may be able to transmit a request to register a new non-friend key KN. In other words, the share device 50 may transmit a request to register a new non-friend key KN regardless of whether it is a friend device 51 or a non-friend device 52. In this case, the management system 10 may register the new non-friend key KN by the series of processes shown in FIG. 7 .

[0187] In this case, the restriction information RI for the non-friend key KN registered based on a registration request from the friend device 51 may prohibit more items than the second restriction information RI2 for the non-friend key KN registered based on a registration request from the non-friend device 52.

[0188] As in the above modified example, the non-friend device 52 may not be able to send a request to register a new non-friend key KN. In this case, the management server 70 may not store the second constraint information RI2, and the management server 70 may not need to send the second constraint information RI2 to the vehicle 20. In other words, the management server 70 may send the constraint information RI to the vehicle 20 only when registering a friend key KF.

[0189] In each of the above embodiments, the first device corresponds to the owner device 40, the second device corresponds to the friend device 51, and the third device corresponds to the non-friend device 52. The first digital key corresponds to the owner key KO, the second digital key corresponds to the friend key KF, and the third digital key corresponds to the non-friend key KN.

[0190] As in the above modified example, assume that a new non-friend key KN is registered based on a registration request from the non-friend device 52. In this case, there is a new non-friend device 52 that stores non-friend key information DKN indicating the new non-friend key KN. In this modified example, the first device may correspond to the friend device 51, the second device may correspond to the non-friend device 52, and the third device may correspond to the new non-friend device 52. The first digital key may correspond to the friend key KF, the second digital key may correspond to the non-friend key KN, and the third digital key may correspond to the new non-friend key KN.

[0191] In the above embodiment, the restriction information RI differed depending on the type of share key KS, but the restriction information RI may be the same regardless of the type of share key KS. The restriction information RI may differ for each share key KS regardless of the type of share key KS. For example, the restriction information RI may be set in advance for each share key KS from the owner device 40.

[0192] The restriction information RI may include deletion restrictions. The deletion restrictions are restrictions imposed on the vehicle management device 26 storing the authentication information AT of the non-friend key KN when deleting the non-friend key KN based on a registration request from the sharing device 50. For example, the deletion restrictions may include a restriction indicating that deletion is permitted even if the specified condition RC is not met when a deletion request is received from the sharing device 50 that requested the registration. This restriction restricts a reservation deletion request D41 from the sharing device 50. For example, the deletion restrictions may include a restriction prohibiting a deletion request from a non-friend device 52 storing the non-friend key information DKN. This restriction restricts the vehicle management device 26 from deleting the non-friend key KN itself. In this case, even if the vehicle management device 26 receives a request from the non-friend device 52 to delete the authentication information AT of the non-friend key KN stored therein, the vehicle management device 26 rejects the request and retains the authentication information AT.

[0193] The constraint information RI may be information indicating the constraints of the non-friend key KN to be registered based on a request for registration of the target shared device. For example, the constraint information RI may include information indicating at least one of the registration constraints EM, the usage constraints UM, and the deletion constraints of the modified example described above.

[0194] - Based on the restriction information RI, the execution unit 20E only needs to impose one of the following restrictions: restricting the control of the vehicle 20 when the third digital key is used, and restricting the registration of the third digital key to the vehicle 20.

[0195] The management system 10 only needs to include at least the vehicle 20 and the management server 70. The management server 70 only needs to include at least the transmission unit 20S, and does not need to include any other functional units. Furthermore, the in-vehicle device 20A only needs to include at least the reception unit 20R and the execution unit 20E, and does not need to include any other functional units.

Claims

1. A server configured to manage a plurality of digital keys available for a vehicle, the server comprising: a transmitter configured to transmit, when a second digital key is generated based on a first digital key, restriction information for a third digital key generated based on the second digital key to the vehicle.

2. The server according to claim 1, wherein the restriction information is information used to restrict at least one of the control of the vehicle when the third digital key is used and the registration of the third digital key.

3. The server according to claim 1, wherein the transmission unit transmits the restriction information to the vehicle together with authentication information for authenticating the second digital key.

4. A server as described in claim 3, comprising: a memory unit configured to store a database in which the vehicle and a device to which each of the multiple digital keys is registered are associated; and a receiving unit configured to receive a key track request requesting an update of the database, wherein the transmitting unit is configured to transmit the authentication information and the restriction information to the vehicle in response to the receiving unit receiving the key track request.

5. An on-board device mounted on a vehicle capable of using multiple digital keys, comprising: a receiving unit configured to receive, when a second digital key is generated based on a first digital key, restriction information for a third digital key generated based on the second digital key from a server; and an executing unit configured to restrict, based on the restriction information, at least one of control of the vehicle when the third digital key is used and registration of the third digital key to the vehicle.

6. The in-vehicle device according to claim 5, wherein if the restriction information includes a registration prohibition that prohibits the registration of the third digital key to the vehicle, the execution unit is configured to prohibit the registration of the third digital key to the vehicle.

7. An in-vehicle device as described in claim 5 or claim 6, comprising a memory unit configured to store authentication information for authenticating each of the plurality of digital keys, the restriction information including information regarding an upper limit number of the digital keys that can be registered to the vehicle, and the execution unit configured to prohibit the storage of a number of the authentication information exceeding the upper limit number in the memory unit when the receiving unit receives the restriction information.

8. The vehicle-mounted device according to any one of claims 5 to 8, wherein the restriction information includes prohibitions relating to controls that are prohibited from being executed in the vehicle when the third digital key is used, and when the receiving unit receives the restriction information and the third digital key is used, the executing unit is configured to prohibit the control of the vehicle indicated by the prohibitions.

9. The in-vehicle device according to claim 8, wherein the prohibited actions do not include unlocking or locking the doors of the vehicle, but include starting control of the engine of the vehicle, as controls that are prohibited from being executed in the vehicle.

10. A vehicle equipped with the on-board device according to claim 5.

11. A system comprising: a vehicle capable of using multiple digital keys; and a server configured to manage the multiple digital keys, wherein the server comprises a transmitter configured to transmit, when a second digital key is generated based on a first digital key, restriction information regarding a third digital key to be registered based on the second digital key to the vehicle; and the vehicle comprises: a receiver configured to receive the restriction information; and an execution unit configured to restrict at least one of control of the vehicle when the third digital key is used and registration of the third digital key based on the restriction information.

12. A management method performed by a server configured to manage a plurality of digital keys available for a vehicle, the method including, when a second digital key is generated based on a first digital key, transmitting restriction information about a third digital key generated based on the second digital key to the vehicle.

13. A server program configured to cause a server that manages multiple digital keys available for vehicles to transmit, to the vehicle, restriction information about a third digital key that is generated based on a first digital key when a second digital key is generated based on the second digital key.

14. A management method performed by an on-board device installed in a vehicle capable of using multiple digital keys, the method comprising: when a second digital key is generated based on a first digital key, receiving restriction information from a server regarding a third digital key generated based on the second digital key; and, based on the restriction information, restricting at least one of control of the vehicle when the third digital key is used and registration of the third digital key to the vehicle.

15. A program for an onboard device mounted on a vehicle capable of using multiple digital keys, configured to cause the device to receive, from a server, restriction information regarding a third digital key generated based on a first digital key when a second digital key is generated based on the second digital key, and to restrict at least one of control of the vehicle when the third digital key is used and registration of the third digital key to the vehicle based on the restriction information.

Images