Vehicle management apparatus, management method, management program, and management system

Abstract

A vehicle (20) is configured to communicate with a plurality of devices (30) and a management server (70). The plurality of devices (30) include a shared device (50) that does not belong to an owner of the vehicle (20). A vehicle management apparatus (26) comprises: a storage unit (28) configured to store items of key-related information, which are items of information pertaining to a plurality of digital keys; and an execution unit (27). The execution unit (27) is configured to calculate the difference (DF) between the maximum number of digital keys that can be registered for the vehicle (20) and the number of items of key-related information stored in the storage unit (28). The execution unit (27) is configured so that when the difference (DF) is equal to or less than a prescribed number (PN), even if an item of key-related information corresponding to a new digital key for which the shared device (50) has requested registration is received from the management server (70), the storage unit (28) is prevented from storing the item of key-related information.

Description

Vehicle management device, management method, management program, and management system

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

[0002] Patent Document 1 describes a management system. The management system includes a vehicle management device mounted on a vehicle, multiple devices, and a management server. The vehicle management device stores authentication information, which is information for authenticating a digital key, when registering the digital key. The device stores key information indicating the digital key when registering the digital key. The management server is capable of communicating with the devices and the vehicle. The management server manages the registration of the digital key.

[0003] JP 2024-1720 A

[0004] There are two types of digital keys that can be registered to a device. The first is an owner key, which is registered to an owner device belonging to the vehicle owner. The second is a shared key, which is registered to a device other than the owner device upon request from one of the multiple devices included in the management system. The device that stores the key information of the shared key is the shared device. In the management system, the owner device and the shared device can request the registration of a new shared key.

[0005] In the management system, there is a limit to the number of pieces of authentication information that the vehicle management device can store. As mentioned above, the shared key is registered not only by the owner device but also by request from the shared device. Therefore, even if the owner tries to register a digital key, there is a risk that the registration will not be successful.

[0006] In a first aspect of the present disclosure, a vehicle management device is mounted on a vehicle. The vehicle is configured to communicate with a plurality of devices and a management server. Each of the plurality of devices is configured to store information indicating at least one of a plurality of digital keys. The management server is configured to manage the registration of the plurality of digital keys. The plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device. The vehicle management device includes a storage device configured to store key-related information, which is information about each of the plurality of digital keys, and an execution device. The execution device is configured to calculate a difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the storage device, and when the difference is equal to or less than a predetermined number, not store the key-related information in the storage device even if the shared device receives the key-related information corresponding to a new digital key whose registration has been requested from the management server.

[0007] In a second aspect of the present disclosure, a management method is executed by a vehicle management device mounted on a vehicle. The vehicle is configured to communicate with a plurality of devices and a management server. Each of the plurality of devices is configured to store information indicating at least one of a plurality of digital keys. The management server is configured to register the plurality of digital keys. The plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device. The vehicle management device includes a storage device configured to store key-related information, which is information about each of the plurality of digital keys. This management method includes calculating a difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the storage device, and, when the difference is equal to or less than a predetermined number, not storing the key-related information in the storage device even if the shared device receives the key-related information corresponding to a new digital key whose registration has been requested from the management server.

[0008] In a third aspect of the present disclosure, a management program is executed by a vehicle management device mounted on a vehicle. The vehicle is configured to communicate with a plurality of devices and a management server. Each of the plurality of devices is configured to store information indicating at least one of a plurality of digital keys. The management server is configured to register the plurality of digital keys. The plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device. The vehicle management device includes a storage device configured to store key-related information, which is information about each of the digital keys. The management program is configured to cause the vehicle management device to calculate a difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the storage device, and, when the difference is equal to or less than a predetermined number, not store the key-related information in the storage device even if the key-related information corresponding to a new digital key requested to be registered by the shared device is received from the management server.

[0009] In a fourth aspect of the present disclosure, a management system includes a plurality of devices, each configured to store information indicating at least one of a plurality of digital keys; a management server configured to manage the registration of the plurality of digital keys; a vehicle configured to communicate with the plurality of devices and the management server; and a vehicle management device mounted on the vehicle and configured to store key-related information relating to each of the plurality of digital keys. The plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device. The vehicle management device is configured to calculate a difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the vehicle management device, and when the difference is equal to or less than a predetermined number, not to store the key-related information corresponding to a new digital key that the shared device has requested to be registered, even if the key-related information is received from the management server.

[0010] FIG. 1 is a schematic diagram showing a management system of an embodiment. FIG. 2 is a schematic diagram showing owner key information in the management system of FIG. 1. FIG. 3 is a schematic diagram showing share key information in the management system of FIG. 1. FIG. 4 is a schematic diagram showing data in a database in the management system of FIG. 1. FIG. 5 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when registering an owner key. FIG. 6 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when registering a friend key. FIG. 7 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when registering a non-friend key. FIG. 8 is an explanatory diagram showing a series of processes performed by the management system of FIG. 1 when authentication information for a non-friend key is sent to a vehicle. FIG. 9 is an image showing that a digital key cannot be registered and the reason for the registration failure.

[0011] An embodiment of a management system will be described below with reference to the drawings. <Outline of Management System 10> As shown in FIG. 1 , the management system 10 manages multiple digital keys that can be used for a vehicle 20. Regarding digital keys, there is a standard established by the Car Connectivity Consortium (CCC). The digital key-related aspects of this embodiment comply with the CCC. The management system 10 includes a vehicle 20, multiple devices 30, a device server 60, and a management server 70.

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

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

[0014] The BLE module 23 performs short-range wireless communication with the device 30 via BLE communication. The one or more UWB modules 24 communicate with the device 30 via UWB communication. The one or more UWB modules 24 measure 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.

[0015] 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, authentication information AT, and a count program PC.

[0016] The vehicle program PV, when executed by the execution device 27, causes the execution device 27 to store and delete authentication information AT. The authentication information AT is information for authenticating a digital key so that the vehicle 20 can be controlled using the digital key when it 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 authentication information AT. The count program PC is a management program. When executed by the execution device 27, the count program PC causes the execution device 27 to count the number of pieces of authentication information AT stored in the storage device 28. When executed by the execution device 27, the count program PC causes the execution device 27 to perform control according to the number of pieces of authentication information AT stored in the storage device 28.

[0017] 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. Also, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be started.

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

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

[0020] 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 communication with the vehicle 20 using NFC communication.

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

[0022] The device program PD includes, for example, a device application and a digital key framework. The device application is an application for storing and deleting key information DK. The digital key framework is a program that provides functions for pairing 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.

[0023] 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. The owner device 40 belongs to the owner of the vehicle 20.

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

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

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

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

[0028] As shown in Fig. 1, the share device 50 stores share key information DKS indicating a share key KS as key information DK. The share device 50 is a device 30 separate from the owner device 40. The 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.

[0029] 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 a friend key KF. The non-friend device 52 stores, as the share key information DKS, non-friend key information DKN indicating a 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 registration request D21 directly 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 a registration request D31 from another device 30, rather than a registration request D21 directly from the owner device 40. The non-friend key KN is a share key KS that is not a friend key KF.

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

[0031] There is an upper limit to the amount of authentication information AT that the vehicle 20 can store. In the management system 10, there is a maximum number of digital keys that can be registered for the vehicle 20. 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, intra-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The shared key structure information STS includes certificate information ST5, vehicle public key information ST7, and authorization 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.

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

[0033] The signature information ATP1 indicates that the share 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 owner signature information 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. Also, for example, in the case of the non-friend device 52, the signature information ATP1 indicates a signature by the friend device 51. The friend signature information 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.

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

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

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

[0037] <Management Server 70> The management server 70 is configured to manage the registration of digital keys. The management server 70 is capable of communicating with the vehicle 20 and multiple devices 30. The management server 70 includes an execution unit 71, which is a processing circuit, a storage unit 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 also capable of wireless communication with the communication module 21 of the vehicle 20.

[0038] The storage device 72 stores a server program PS and a database DB. When the server program PS is executed by the execution device 71, the execution device 71 registers a digital key in the database DB and deletes a digital key from the database DB.

[0039] 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, as the data DA, information indicating the device 30 that stores the key information DK indicating the digital key. The management server 70 manages the digital keys by saving the data DA in the database DB.

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

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

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

[0043] The following describes a state 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 to the first device 30A to the seventh device 30G are the first digital key to the seventh digital key, respectively.

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

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

[0046] 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 fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

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

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

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

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

[0052] 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 based on a registration request from the fifth device 30E. In other words, the seventh digital key is registered based on the fifth digital key.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0082] After completing the registration management, the management server 70 transmits a key track completion notification M23 to the second device 30B. After that, 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 on 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.

[0083] 7, the management system 10 performs a series of 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.

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

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

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

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

[0088] 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 unsigned non-friend key information DKNN includes the acquired share information SH2. 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.

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

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

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

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

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

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

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

[0096] 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 device 30 registered as the non-friend device 52 is the third device 30C. 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 friend device 51.

[0097] After completing the registration management, the management server 70 transmits a key track completion notification M33 to the third device 30C. After that, upon receiving the key track completion notification M33, the third device 30C performs processing in step S50. In the processing in step S50, 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.

[0098] After completing the registration management, the management server 70 transmits the authentication package ATP of the non-friend key information DKN and a storage request D34 requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 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.

[0099] Thereafter, when the vehicle 20 receives the authentication package ATP and the storage request D34, it performs the process of step S51. In step S51, the vehicle 20 checks the number of pieces of authentication information AT stored in itself.

[0100] As mentioned above, there is an upper limit to the number of pieces of authentication information AT that the vehicle 20 can store. In Figure 7, when the vehicle 20 receives the authentication package ATP for the non-friend key KN, it checks the number of pieces of authentication information AT that it has stored based on the count program PC. As will be described later, the vehicle 20 stores the authentication package ATP for the non-friend key KN as authentication information AT. When the vehicle 20 receives the authentication information AT for the non-friend key KN, it checks the number of pieces of authentication information AT that it has stored based on the count program PC.

[0101] After executing the process of step S51, the management system 10 executes a series of processes shown in Fig. 8. The series of processes shown in Fig. 8 will be described below. In Fig. 8, the vehicle 20 executes processes according to the number of pieces of authentication information AT stored in the vehicle 20 using the count program PC.

[0102] After confirming the number of pieces of authentication information AT stored in the vehicle 20, the vehicle 20 executes the process of step S60. In the process of step S60, the vehicle 20 calculates a difference DF. The difference DF is the difference between the maximum number of digital keys that can be registered to the vehicle 20 and the number of pieces of authentication information AT stored in the storage device 28. The authentication information AT is information related to the digital key, i.e., key-related information.

[0103] If the difference DF is greater than the predetermined number PN, the management system 10 performs the process of step S61. The predetermined number PN is a reference number for determining whether the number of pieces of authentication information AT stored in the storage device 28 is approaching an upper limit. The predetermined number PN is determined in advance by the user of the owner device 40, who is the owner of the vehicle 20. For example, the owner of the vehicle 20 specifies the predetermined number PN by operating the owner device 40. The vehicle 20 sets the predetermined number PN as specified by the owner device 40.

[0104] In step S61, the vehicle 20 stores the received authentication package ATP. The vehicle 20 stores the authentication package ATP as authentication information AT for authenticating the non-friend key KN. This completes the series of processes for registering the non-friend key KN in the management system 10.

[0105] If the difference DF is equal to or less than the predetermined number PN, the management system 10 performs the processes of steps S71 and S72. If the difference DF is equal to or less than the predetermined number PN, the vehicle 20 transmits a registration failure notification M41 to the third device 30C. The registration failure notification M41 is a signal indicating that the non-friend key KN requested to be registered cannot be registered. The registration failure notification M41 includes a notification indicating that the non-friend key KN requested to be registered cannot be registered because the difference DF is equal to or less than the predetermined number PN. The registration failure notification M41 notifies the vehicle 20 that a new non-friend key KN cannot be registered due to the number of pieces of authentication information AT stored in the vehicle 20. The vehicle 20 communicates with the third device 30C via the management server 70 and the device server 60.

[0106] Upon receiving the registration failure notification M41, the third device 30C performs processing in step S71. In step S71, the third device 30C presents to the HMI 32 information indicating that the non-friend key KN is not registerable and information indicating the cause of the registration failure. The image shown in FIG. 9 indicates that the non-friend key KN is not registerable and the cause of the registration failure. For example, the third device 30C presents to the HMI 32 the image shown in FIG. 9. The third device 30C presents to the HMI 32 that the cause of the registration failure is the number of pieces of authentication information AT stored in the vehicle 20. In other words, the third device 30C informs the user of the third device 30C that a large number of digital keys have been registered to the vehicle 20.

[0107] If the difference DF is equal to or smaller than the predetermined number PN, the vehicle 20 transmits a registration failure notification M41 to the friend device 51. The vehicle 20 communicates with the friend device 51 via the management server 70 and the device server 60.

[0108] Upon receiving the registration failure notification M41, the friend device 51 performs processing in step S72. In step S72, the friend device 51 presents to the HMI 32 information indicating that the non-friend key KN is not registerable and information indicating the cause of the registration failure. For example, the friend device 51 presents to the HMI 32 the image shown in FIG. 9. The friend device 51 presents to the HMI 32 that the cause of the registration failure is the number of pieces of authentication information AT stored in the vehicle 20. In other words, the friend device 51 notifies the user of the friend device 51 that a large number of digital keys have been registered for the vehicle 20. This causes the management system 10 to end the series of processes performed when the difference DF is equal to or less than the predetermined number PN.

[0109] In this way, the vehicle 20 calculates the difference DF when it receives the authentication information AT. If the vehicle 20 receives an authentication package ATP for a new shared key KS from the management server 70 when the difference DF is equal to or less than the predetermined number PN, the vehicle 20 does not store the authentication package ATP as authentication information AT.

[0110] <Function of this embodiment> When the difference DF is equal to or less than a predetermined number PN, and the execution device 27 of the vehicle management device 26 receives from the management server 70 key-related information corresponding to the share key KS that the share device 50 has requested to be newly registered, the execution device 27 does not store the received key-related information in the storage device 28.

[0111] Advantages of this embodiment: (1) The vehicle management device 26 prevents the amount of stored key-related information from reaching the upper limit without the owner's knowledge. The vehicle management device 26 can reduce the occurrence of an event where the owner is unable to register a digital key when attempting to do so.

[0112] (2) The vehicle management device 26 receives authentication information AT used to authenticate the digital key as key-related information from the management server 70. This allows the vehicle management device 26 to prevent the number of pieces of authentication information AT stored therein from reaching an upper limit without the owner realizing it.

[0113] (3) The predetermined number PN is set by the owner. As a result, the vehicle management device 26 can prevent new authentication information AT of the share key KS from being stored in the storage device 28 once the number of authentication information AT stored in the storage device 28 reaches the number set by the owner.

[0114] (4) The vehicle management device 26 calculates the difference DF when it receives key-related information corresponding to a new digital key requested for registration by the shared device 50. The vehicle management device 26 calculates the difference DF each time it receives key-related information. If the difference DF is equal to or less than a predetermined number PN, the vehicle management device 26 does not store the received key-related information in the storage device 28.

[0115] When the vehicle management device 26 receives the authentication information AT of the new share key KS requested to be registered by the share device 50, the vehicle management device 26 checks the difference DF and determines whether or not to store the authentication information AT. This allows the vehicle management device 26 to restrict the storage of the authentication information AT of the new share key KS depending on the number of pieces of authentication information AT stored in the vehicle management device 26 itself.

[0116] (5) When the vehicle management device 26 does not store key-related information, it sends a notification to the other device 30 to which the new digital key is to be registered indicating that the new digital key will not be registered.

[0117] The vehicle management device 26 does not store the authentication information AT of the new share key KS, but instead transmits a notification indicating that the share key KS will not be registered to the other device 30. This allows the vehicle management device 26 to notify the user of the other device 30 that the share key KS cannot be registered.

[0118] (6) The notification sent to the other device 30 includes a notification indicating that the reason the new digital key cannot be registered is the number of pieces of key-related information stored in the vehicle 20.

[0119] The vehicle management device 26 notifies the other device 30 that the reason it is not possible to register a new share key KS is that the number of pieces of authentication information AT stored in the vehicle 20 has increased. This allows the vehicle management device 26 to notify the user of the other device 30 of the reason why it is not possible to register a new share key KS. In response to this notification, the user of the other device 30 can ask the owner of the vehicle 20 to reduce the number of digital keys on the management system 10.

[0120] (7) When the vehicle management device 26 does not store key-related information, it sends a notification to the share device 50 that requested registration of a new digital key indicating that the new digital key will not be registered.

[0121] The vehicle management device 26 does not store the authentication information AT of the new share key KS, but instead transmits a notification indicating that the share key KS will not be registered to the share device 50 that requested the registration of the share key KS. This allows the vehicle management device 26 to notify the user of the share device 50 that requested the registration of the share key KS that the share key KS cannot be registered.

[0122] (8) The notification sent to the shared device 50 that requested the registration of a new digital key includes a notification indicating that the reason the new digital key could not be registered is the number of pieces of key-related information stored in the vehicle 20.

[0123] The vehicle management device 26 notifies the share device 50 that requested the registration of a new share key KS that the reason it cannot register a new share key KS is that the number of pieces of authentication information AT stored in the vehicle 20 has increased. This allows the vehicle management device 26 to notify the user of the share device 50 of the reason why it cannot register a new share key KS. In response to this notification, the user of the share device 50 can ask the owner of the vehicle 20 to reduce the number of digital keys on the management system 10.

[0124] (9) When the difference DF is equal to or less than the predetermined number PN, if the shared device 50 receives key-related information corresponding to a newly requested shared key KS from the management server 70, the management method does not store the received key-related information in the vehicle management device 26. This prevents the number of stored key-related information items from reaching the upper limit without the owner's knowledge. This management method prevents the owner from being unable to register a digital key when attempting to do so.

[0125] (10) When the difference DF is equal to or less than the predetermined number PN and the shared device 50 receives key-related information corresponding to a newly registered shared key KS from the management server 70, the count program PC does not store the key-related information in the vehicle management device 26. This prevents the number of stored key-related information items from reaching the upper limit without the owner's knowledge. This management program prevents the owner from being unable to register a digital key when attempting to do so.

[0126] (11) When the difference DF is equal to or less than the predetermined number PN and the management system 10 receives key-related information corresponding to a newly registered shared key KS from the management server 70, the management system 10 does not store the key-related information in the vehicle management device 26. This prevents the number of stored key-related information items from reaching the upper limit without the owner's knowledge. This management system 10 can prevent the owner from being unable to register a digital key when attempting to do so.

[0127] (12) In response to receiving a notification from the vehicle management device 26 indicating that the new digital key will not be registered, the other device 30 displays information indicating that the new digital key will not be registered.

[0128] The other device 30 displays information indicating that the share key KS will not be registered, which enables the management system 10 to notify the user of the other device 30 that the share key KS cannot be registered.

[0129] (13) In response to receiving the above notification from the vehicle management device 26, the other device 30 displays information indicating that the reason the new digital key cannot be registered is the number of key-related information items stored in the vehicle 20.

[0130] The management system 10 can notify the user of the other device 30 of the reason why the new share key KS cannot be registered. In response to this notification, the user of the other device 30 can ask the owner of the vehicle 20 to reduce the number of digital keys on the management system 10.

[0131] (14) In response to receiving a notification from the vehicle management device 26 indicating that a new digital key will not be registered, the share device 50 that requested the registration of a new digital key displays information indicating that a new digital key will not be registered.

[0132] The share device 50 that requested the registration of the share key KS displays information indicating that the registration of the share key KS will not be performed. This allows the management system 10 to notify the user who requested the registration of a new share key KS that the share key KS cannot be registered.

[0133] (15) In response to receiving the above notification from the vehicle management device 26, the share device 50 that requested registration of a new digital key displays information indicating that the reason the new digital key cannot be registered is the number of key-related information items stored in the vehicle 20.

[0134] The management system 10 can notify the user who requested registration of the reason why the new share key KS cannot be registered. In response to this notification, the user who requested registration can ask the owner of the vehicle 20 to reduce the number of digital keys on the management system 10.

[0135] (Other Embodiments) This embodiment can be modified as follows: Each embodiment and the following modifications can be combined with each other to the extent that no technical contradiction occurs.

[0136] <Management System 10> 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 module, it can perform short-range 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 communication with the device 30.

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

[0138] In the above embodiment, the vehicle management device 26 includes an execution device 27, which is a processing circuit including one or more processors that execute various processes according to a computer program (software). However, the vehicle management device 26 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 vehicle management device 26 may include a 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 that can be accessed by a general-purpose or dedicated computer. The same applies to the device 30 and the management server 70.

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

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

[0141] In each of the above embodiments, the digital keys are arranged in a hierarchy of owner keys KO, friend keys KF, and non-friend keys KN in that order. The higher the hierarchy of the digital keys, the greater the authority. The digital keys do not necessarily have to be arranged in a hierarchy of greater authority. For example, the same level of authority may be set for the three hierarchies of the owner keys KO, friend keys KF, and non-friend keys KN.

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

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

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

[0145] <Various Information> The information related to the digital key stored in the vehicle 20 is not limited to the authentication information AT. The authentication information AT is not limited to the examples of the above embodiments, as long as it is information for authenticating the digital key when using the digital key. For example, the authentication information AT may be a common key shared by the vehicle management device 26 and the device 30. Also, for example, the authentication information AT may be a common secret key.

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

[0147] The database DB may include information indicating the type of the device 30. The type of the device 30 is information indicating, for example, one of a smartphone, a smartwatch, a predetermined server, and the like.

[0148] The structure of the data DA in the database DB is not limited to the examples in the above embodiments. The database DB only needs to include information necessary for management by the management server 70 in the management system 10.

[0149] In the database DB, the authority may be set for each digital key, rather than being uniformly determined according to the type of digital key. The authority may not be determined in the database DB.

[0150] <Processing for Registering a Digital Key> The processing for registering the owner key KO is not limited to the examples in the above embodiments. For example, the owner device 40 may store the owner key information DKO by transmitting and receiving information such as the generated data DC between the vehicle 20 and the first device 30A via the management server 70, even if pairing is not performed in the processing of step S12. The processing for registering the owner key KO may be modified as appropriate to suit the structure of the information included in the owner key information DKO and the structure of the information included in the authentication information AT.

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

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

[0153] The types of digital keys do not have to include the non-friend key KN. In other words, in the management system 10, the share key KS may only be the friend key KF. The non-friend device 52 may be able to send a request to register a new non-friend key KN. In other words, the share device 50 may send 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.

[0154] In this case, when the vehicle management device 26 receives the authentication package ATP of the non-friend key KN requested to be registered by the non-friend device 52, it checks the number of pieces of authentication information AT stored therein, as in Fig. 8. Then, the vehicle management device 26 executes processing based on the number of pieces of authentication information AT stored, based on the count program PC, as in Fig. 8. When the vehicle management device 26 receives the registration failure notification M41, it transmits the registration failure notification M41 to the third device 30C and the non-friend device 52 that requested registration of the non-friend key KN for the third device 30C.

[0155] In the above embodiment, the predetermined number PN is determined in advance by the owner of the vehicle 20. In the above embodiment, the owner of the vehicle 20 refers to the user of the owner device 40. The owner of the vehicle 20 is not limited to the user of the owner device 40. For example, a user of a shared device 50 who has been granted the same authority as the owner device 40 may determine the predetermined number PN as the owner of the vehicle 20.

[0156] The predetermined number PN does not have to be determined by the owner of the vehicle 20. For example, the predetermined number PN may be determined in advance by the user of the shared device 50, rather than by the owner of the vehicle 20. For example, the predetermined number PN may be determined in advance by the provider of the vehicle 20 or the management server 70.

[0157] In the above embodiment, the vehicle management device 26 calculates the difference DF when it receives the authentication package ATP of the non-friend key KN. The timing at which the vehicle management device 26 calculates the difference DF is not limited to the above embodiment.

[0158] For example, the vehicle management device 26 may calculate the difference DF after the digital key is registered in the management system 10. The vehicle management device 26 may also calculate the difference DF periodically, regardless of whether the digital key has been registered. In these cases, when the difference DF is equal to or less than the predetermined number PN, the vehicle management device 26 will not store the authentication package ATP for the shared key KS whose registration has been requested by the shared device 50, even if the authentication package ATP is received thereafter.

[0159] In the above embodiment, when the vehicle management device 26 does not store the authentication information AT, the vehicle management device 26 transmits a registration failure notification M41 to the third device 30C. The vehicle management device 26 does not have to transmit the registration failure notification M41 to the third device 30C.

[0160] The registration failure notification M41 does not have to include information indicating the reason why the non-friend key KN cannot be registered. In this case, the third device 30C does not display the reason why the registration cannot be performed. In the above embodiment, the vehicle management device 26 transmits the registration failure notification M41 to the friend device 51 when the authentication information AT is not stored. The vehicle management device 26 does not have to transmit the registration failure notification M41 to the friend device 51.

[0161] The registration failure notification M41 does not need to include information indicating the reason why the non-friend key KN cannot be registered. In this case, the friend device 51 does not display the reason why the registration cannot be performed. In the above embodiment, the vehicle 20 communicates with the multiple devices 30 via the management server 70 and the device server 60 in FIG. 8. The vehicle 20 may directly communicate with the multiple devices 30 in FIG. 8 through BLE communication or NFC communication, for example. For example, the vehicle 20 can directly communicate with the multiple devices 30 via a wireless communication network, and may directly communicate with the multiple devices 30 in FIG. 8 via a wireless communication network.

[0162] In the above embodiment, the vehicle management device 26 calculates the difference DF when it receives the authentication package ATP for the non-friend key KN. If the difference DF is equal to or less than a predetermined number PN, the vehicle management device 26 does not store the received authentication package ATP.

[0163] The vehicle management device 26 may store the authentication package ATP when it receives the authentication package ATP for the non-friend key KN, and then calculate the difference DF after storing the authentication package ATP. In this case, when the difference DF is equal to or less than the predetermined number PN minus 1, the vehicle management device 26 deletes the stored authentication package ATP and sends a registration failure notification M41 to the third device 30C and the friend device 51.

[0164] In this case as well, it is possible to realize a configuration in which the vehicle management device 26 does not store the authentication information AT of the new share key KS sent from the management server 70 when the difference DF is equal to or smaller than the predetermined number PN.

[0165] When the vehicle management device 26 receives authentication information AT for a new share key KS, the vehicle management device 26 may calculate the difference DF before storing the authentication information AT. If the difference DF is equal to or less than a predetermined number PN, the vehicle management device 26 may first store the authentication information AT for the new share key KS and then delete the stored authentication information AT.

Claims

1. A vehicle management device mounted on a vehicle, wherein the vehicle is configured to communicate with a plurality of devices and a management server, each of the plurality of devices is configured to store information indicating at least one of a plurality of digital keys, the management server is configured to manage the registration of the plurality of digital keys, the plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device, the vehicle management device comprising: a storage device configured to store key-related information, which is information about each of the plurality of digital keys; and an execution device, wherein the execution device is configured to calculate the difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the storage device, and when the difference is equal to or less than a predetermined number, not store the key-related information in the storage device even if the key-related information corresponding to a new digital key that the shared device has requested to be registered is received from the management server.

2. The vehicle management device according to claim 1, wherein the key-related information includes authentication information used to authenticate the corresponding digital key.

3. The vehicle management device according to claim 1 or 2, wherein the execution device is configured to set the predetermined number in response to a command from the owner device.

4. A vehicle management device as described in any one of claims 1 to 3, wherein the execution device is configured to calculate the difference at the time when the execution device receives the key-related information corresponding to the new digital key that the share device has requested to be registered.

5. A vehicle management device as described in any one of claims 1 to 4, wherein the share device is configured to request that the new digital key be registered in another device, and the execution device is configured to, when the key-related information corresponding to the new digital key is not stored in the storage device, send a notification to the other device indicating that the new digital key will not be registered.

6. The vehicle management device according to claim 5, wherein the notification includes a notification indicating that the reason the new digital key cannot be registered is the number of pieces of key-related information stored in the vehicle.

7. A vehicle management device as described in any one of claims 1 to 4, wherein the share device is configured to request that the new digital key be registered in another device, and the execution device is configured to, when the key-related information corresponding to the new digital key is not stored in the storage device, send a notification to the share device indicating that the new digital key will not be registered.

8. The vehicle management device according to claim 7, wherein the notification includes a notification indicating that the reason the new digital key was not registered is due to the number of pieces of key-related information stored in the vehicle.

9. A management method executed by a vehicle management device mounted on a vehicle, wherein the vehicle is configured to communicate with a plurality of devices and a management server, each of the plurality of devices is configured to store information indicating at least one of a plurality of digital keys, the management server is configured to manage the registration of the plurality of digital keys, the plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device, the vehicle management device has a storage device configured to store key-related information that is information about each of the plurality of digital keys, the management method comprising: calculating a difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the storage device; and when the difference is equal to or less than a predetermined number, not storing the key-related information in the storage device even if the key-related information corresponding to a new digital key that the shared device has requested to be registered is received from the management server.

10. A management program executed by a vehicle management device mounted on a vehicle, wherein the vehicle is configured to communicate with a plurality of devices and a management server, each of the plurality of devices is configured to store information indicating at least one of a plurality of digital keys, the management server is configured to manage the registration of the plurality of digital keys, the plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device, the vehicle management device has a storage device configured to store key-related information that is information about each of the digital keys, and the management program is configured to cause the vehicle management device to calculate the difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the storage device, and when the difference is less than a predetermined number, not store the key-related information in the storage device even if the key-related information corresponding to a new digital key that the shared device has requested to be registered is received from the management server.

11. A management system comprising: a plurality of devices each configured to store information indicating at least one of a plurality of digital keys; a management server configured to manage the registration of the plurality of digital keys; a vehicle configured to communicate with the plurality of devices and the management server; and a vehicle management device mounted on the vehicle and configured to store key-related information that is information regarding each of the plurality of digital keys, wherein the plurality of devices include an owner device belonging to the owner of the vehicle and a shared device that is a device different from the owner device, and the vehicle management device is configured to calculate the difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of key-related information stored in the vehicle management device, and when the difference becomes equal to or less than a predetermined number, not store the key-related information even if the shared device receives from the management server the key-related information corresponding to a new digital key that it has requested to register.

12. The management system of claim 11, wherein the share device is configured to request that the new digital key be registered in another device; the vehicle management device is configured, when it does not store the key-related information corresponding to the new digital key, to send a notification to the other device indicating that the new digital key will not be registered; and the other device is configured, in response to receiving the notification, to display the content of the notification.

13. The management system according to claim 12, wherein the notification includes a notification indicating that the reason the new digital key was not registered is due to the number of pieces of key-related information stored in the vehicle.

14. A management system as claimed in any one of claims 11 to 13, wherein the share device is configured to request that the new digital key be registered in another device; the vehicle management device is configured, when it does not store the key-related information corresponding to the new digital key, to send a notification to the share device indicating that the new digital key will not be registered; and the share device is configured, in response to receiving the notification, to display information indicating that the new digital key will not be registered.

15. The management system according to claim 14, wherein the notification includes a notification indicating that the reason the new digital key was not registered is due to the number of pieces of key-related information stored in the vehicle.

Images