Management system, device, management server, and vehicle

Abstract

To suppress the occurrence of an event that a digital key cannot be registered when an owner tries to register the digital key.SOLUTION: The management system comprises a vehicle that stores information related to a digital key, a device that stores information related to a digital key registered for the vehicle, and a management server 70 that manages registration of the digital key. The digital key includes an owner key registered for an owner device 40 which is a device belonging to the owner of the vehicle and a share key registered for a share device which is a device different from the owner device. When the difference DF between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of information related to the digital key stored in the vehicle is less than or equal to the predetermined number PN, the share device restricts the request for registration of a new share key to the management server 70.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] The present invention relates to a management system, a device, a management server, and a vehicle. [Background technology]

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

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2024-1720 Summary of the Invention [Problem to be solved by the invention]

[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 a device on the management system that includes the owner device. In the management system, the owner device and a shared device that stores the key information of the shared key can request the registration of a new shared key.

[0005] In the management system, there is a limit to the amount of authentication information that a vehicle can store. As mentioned above, the shared key can be 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 registration will not be possible. [Means for solving the problem]

[0006] A management system for solving the above problems includes a vehicle that stores information about digital keys, a device that stores information about the digital keys registered to the vehicle, and a management server that manages the registration of the digital keys. The digital keys include an owner key registered to an owner device that belongs to the vehicle's owner, and a shared key registered to a shared device that is a device separate from the owner device. In the management system, when the difference between the maximum number of digital keys that can be registered to the vehicle and the amount of information about the digital keys stored in the vehicle falls below a predetermined number, the shared device restricts requests for registration of new shared keys from the management server.

[0007] The device for solving the above problem is the owner device among the devices included in the management system, and when the device receives a notification that the difference is equal to or less than the predetermined number, the owner device transmits a signal indicating a desire to transmit the stop request.

[0008] The device for solving the above problem is the owner device among the devices included in the management system, and when this device receives a notification that the difference is equal to or less than the predetermined number, it transmits a signal indicating that it wishes to stop the function of transmitting a request to register a new share key for the share device.

[0009] A device for solving the above problem functions as a shared device in a management system. The management system includes a vehicle that stores information about digital keys, a device that stores information about the digital keys registered to the vehicle, and a management server that manages the registration of the digital keys. The digital keys include an owner key registered for an owner device that belongs to the owner of the vehicle, and a shared key registered for a shared device that is a device separate from the owner device. When the difference between the maximum number of digital keys that can be registered for the vehicle and the amount of information about the digital keys stored in the vehicle falls below a predetermined number, the device restricts requests for registration of new shared keys from the management server.

[0010] The management server for solving the above problem is capable of communicating with a vehicle that stores information about a digital key and with a device that stores information about the digital key registered to the vehicle, and manages the registration of the digital key. The management server transmits restriction information to a shared device that is separate from an owner device that is a device belonging to the vehicle owner, to restrict requests to register a new digital key to the management server.

[0011] A vehicle that solves the above problem is capable of communicating with a device that stores information about a digital key and a management server that manages the registration of the digital key, and stores information about the digital key. The vehicle transmits restriction information to a shared device that is separate from an owner device that is the device belonging to the vehicle owner, to restrict requests to register new digital keys with the management server. [Effects of the Invention]

[0012] The above-described management system, device, management server, and vehicle can prevent the occurrence of an event in which the owner is unable to register a digital key when attempting to do so. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic diagram showing a management system according to the first embodiment. [Figure 2] FIG. 2 is a schematic diagram showing owner key information according to the first embodiment. [Figure 3] FIG. 3 is a schematic diagram showing the share key information of the first embodiment. [Figure 4] FIG. 4 is a schematic diagram showing data in the database of the first embodiment. [Figure 5] FIG. 5 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when an owner key is registered. [Figure 6] FIG. 6 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when a friend key is registered. [Figure 7] FIG. 7 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when a non-friend key is registered. [Figure 8] FIG. 8 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when a non-friend key is deleted in response to a request from a friend device. [Figure 9] FIG. 9 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when a non-friend key is deleted in response to a request from a non-friend device. [Figure 10] FIG. 10 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when a friend key is deleted in response to a request from the owner device. [Figure 11] FIG. 11 is an explanatory diagram showing a series of processes performed by the management system of the first embodiment when a friend key is deleted in response to a request from a friend device. [Figure 12] FIG. 12 is an explanatory diagram showing a series of processes executed by the management system of the first embodiment after the digital key is registered. [Figure 13]FIG. 13 is an explanatory diagram showing a series of processes executed by the management system of the first embodiment after the digital key is deleted. [Figure 14] FIG. 14 is a schematic diagram showing a vehicle in the management system of the second embodiment. [Figure 15] FIG. 15 is an explanatory diagram showing a series of processes executed by the management system of the second embodiment after the digital key is registered. [Figure 16] FIG. 16 is an explanatory diagram showing a series of processes executed by the management system of the second embodiment after a digital key is deleted. [Figure 17] FIG. 17 is an explanatory diagram showing a series of processes executed by the management system of the third embodiment after the digital key is registered. [Figure 18] FIG. 18 is an explanatory diagram showing a series of processes executed by the management system of the third embodiment after a digital key is deleted. [Figure 19] FIG. 19 is an explanatory diagram showing a series of processes executed by the management system of the fourth embodiment after the digital key is registered. [Figure 20] FIG. 20 is an explanatory diagram showing a series of processes executed by the management system of the fourth embodiment after a digital key is deleted. DETAILED DESCRIPTION OF THE INVENTION

[0014] (First embodiment) A first embodiment of the management system will be described below with reference to the drawings. <Outline of Management System 10> As shown in FIG. 1, a 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. There is a standard for digital keys, the Car Connectivity Consortium (CCC). Matters relating 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 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.

[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 communication with the device 30 using BLE communication. The UWB module 24 communicates with the device 30 using UWB communication. The UWB module 24 measures the distance between the device 30 and the vehicle 20. The NFC module 25 performs short-range communication with the device 30 using 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 and a storage device 28. The storage device 28 stores a vehicle program PV and authentication information AT. The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating the digital key so that the 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] Note that authenticating a digital key means enabling the vehicle 20 to be controlled by the digital key. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables the vehicle 20 to be unlocked. Also, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables 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, 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 communication with the vehicle 20 by BLE communication. The UWB module 34 performs short-range communication with the vehicle 20 by UWB communication. The NFC module 35 performs short-range communication with the vehicle 20 by 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 the functions of 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 the storage and deletion of 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. The owner device 40 belongs to the owner of the vehicle 20.

[0026] 2, the owner key information DKO has 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, the ID of the vehicle 20. The intra-device key identification information ST2 is used to manage the digital key within the device 30. The intra-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, which is the public key of the device 30. Note that 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, which is the public key of the vehicle 20. Authorization public key information ST8 indicates an already authorized vehicle public key PKV.

[0030] As shown in Fig. 1, the shared device 50 stores shared key information DKS indicating a shared key KS as key information DK. The shared device 50 is a device 30 separate from the owner device 40. The shared key KS is a digital key that can be registered in multiple numbers for one vehicle 20 when registering the digital key to enable use of the digital key. In other words, multiple shared keys KS can exist for one vehicle 20.

[0031] The multiple shared devices 50 include a friend device 51 and a non-friend device 52. The friend device 51 stores, as the shared key information DKS, friend key information DKF indicating a friend key KF. The non-friend device 52 stores, as the shared key information DKS, non-friend key information DKN indicating a non-friend key KN. In other words, the types of shared keys KS include a friend key KF and a non-friend key KN. The friend key KF is a shared key KS registered based on a registration request D21 directly from the owner device 40, as will be described later. The non-friend key KN is a shared key KS registered based on a registration request D31 from the friend device 51, as will be described later. In other words, the non-friend key KN is a shared key KS that is not a friend key KF, among the shared keys KS.

[0032] The state in which the digital key is registered means that the digital key is usable, i.e., the vehicle 20 stores the authentication information AT and the device 30 stores the key information DK.

[0033] There is an upper limit to the number of pieces of authentication information AT that can be stored in the vehicle 20. Therefore, there is a maximum number of digital keys that can be registered for the vehicle 20 in the management system 10.

[0034] As shown in Fig. 3, the shared key information DKS has 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 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 information obtained by excluding device public key information ST6 from the owner key structure information STO.

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

[0036] The signature information ATP1 indicates that the shared device 50 is a legitimate party with which the digital key is shared. For example, in the case of the friend device 51, it 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, which is indicated by the device public key information ATP6. Also, for example, in the case of the non-friend device 52, it 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, which is indicated by the device public key information ATP6.

[0037] 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. For example, it is set as an identifiable name for each shared device 50 by operation from the owner device 40.

[0038] 1, the device server 60 relays communication between the devices 30 and the management server 70. A device server 60 is provided for each type of device 30. That is, the device server 60 with which a first type of device 30 communicates is 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.

[0039] Any of the device servers 60 relays communication with the management server 70, so that different types of devices 30 can communicate with the management server 70 via the device servers 60. Note that only one device server 60 is shown in FIG.

[0040] <Administration Server 70> The management server 70 manages 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 device 71, a storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 is also capable of wireless communication with the communication module 21 of the vehicle 20.

[0041] The storage device 72 stores a server program PS, a count program PC, 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.

[0042] The count program PC is executed by the execution device 71 to cause the execution device 71 to count the number of pieces of authentication information AT stored in the vehicle 20 and to perform control according to the number. In the database DB, for each of a plurality of digital keys, the corresponding vehicle 20 and the registered device 30 are associated with each other. In the database DB, data DA 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 key information DK indicating the digital key. The management server 70 manages the digital keys by saving the data DA in the database DB.

[0043] As shown in Figure 4, the data DA for one vehicle 20 includes the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. Hierarchical rankings are determined based on the type of digital key. From top to bottom, the hierarchy is arranged as follows: owner key KO, friend key KF, and non-friend key KN. The higher the hierarchy, the greater the authority set.

[0044] 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 hierarchy, the greater the authority, and therefore, for example, 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.

[0045] Furthermore, for example, the higher the hierarchy, the greater the authority, and therefore the wider the controllable range of the vehicle 20. The controllable range of the vehicle 20 indicates, for example, the possible controls among the engine start control of the vehicle 20, the power on control of the vehicle 20, and the unlocking and locking control of 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 the unlocking and locking control of the doors of the vehicle 20. More specifically, the controllable range of the vehicle 20 that the friend key KF can control is the above-mentioned three controls, whereas the controllable range of the vehicle 20 that the non-friend key KN can control is only the unlocking and locking control of the doors of the vehicle 20.

[0046] 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 in the first device 30A to the seventh device 30G, respectively, are referred to as a first digital key to a seventh digital key.

[0047] In the data DA, the device 30 whose type of digital key is registered as the owner key KO 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.

[0048] In the data DA, the devices 30 whose digital key type is registered as a shared key KS are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. 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.

[0049] More specifically, in the data DA, the devices 30 whose digital key type is registered as a friend key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are friend devices 51. In the data DA, the devices 30 whose digital key type is registered as a non-friend key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

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

[0052] In the data DA, 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.

[0053] In the data DA, 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.

[0054] In the data DA, 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.

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

[0056] In this way, the data DA stores the devices 30 registered as digital keys. 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.

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

[0058] <Registering the Owner Key KO> 5, the management system 10 performs a series of processes to register the owner key KO. Among the devices 30 that do not store the key information DK indicating the owner key KO, the device 30 that is to be set as the owner device 40 is referred to as the first device 30A.

[0059] In the management system 10, when the owner key KO is registered, key information DK indicating the owner key KO is stored in the first device 30A. In the management system 10, when the owner key KO is registered, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. As a result, the first device 30A becomes the owner device 40. Note that when the owner key KO is registered, it is assumed that an application is 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 the process of 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] Thereafter, vehicle 20 receives pairing password PAS. After receiving pairing password PAS, vehicle 20 is set to pairing mode from HMI 22 and 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 a secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. Then, the first device 30A receives the generation data DC. Then, the first device 30A proceeds to step S14.

[0064] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. After that, the first device 30A advances the process 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. Thereafter, 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, the vehicle 20 stores the device public key information ST6 indicating the device public key PKD as the authentication information AT. Then, the vehicle 20 transmits a completion notification M11 to the first device 30A indicating that the storage of the 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. Then, the first device 30A transmits the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0068] Thereafter, upon receiving the key track request D12, the management server 70 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 the first device 30A as the device 30 registered as the owner key KO in the data DA of the vehicle 20 in the database DB. This causes the management system 10 to complete the series of processes for the owner key KO.

[0069] <Friend Key KF Registration> 6, the management system 10 performs a series of processes to register a friend key KF. Among the devices 30 that do not store friend key information DKF, the device 30 that is designated as a friend device 51 through the series of processes is referred to as a second device 30B.

[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). Thereafter, the owner device 40 proceeds to the process of step S22.

[0071] In step S22, the owner device 40 acquires 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. Note that the validity start time information ATP3, expiration date information ATP4, and name information ATP5 are set by the owner device 40. Thereafter, the second device 30B proceeds to step S24.

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

[0075] Thereafter, the owner device 40 receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 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 unsigned 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 the operation is performed, the owner device 40 acquires a signature based on the operation. Thereafter, the owner device 40 proceeds to step S26.

[0077] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. As a result, the owner device 40 generates 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] Thereafter, the second device 30B receives the completion notification M22. Then, the second device 30B 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 becomes a friend device 51. Then, the second device 30B proceeds to the process of step S28.

[0079] In step S28, the second device 30B generates a key track request D23 for the friend key KF, and then 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 verifies 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 indicates shared keys KS that include friend keys KF and non-friend keys 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. In detail, the management server 70 stores the second device 30B as a device 30 registered as a friend device 51 in the data DA of the vehicle 20 in the database DB. The management server 70 stores the relationship between the second device 30B and the owner device 40 by referring to the acquired friend key information DKF.

[0083] Thereafter, the management server 70 transmits the authentication package ATP of 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 also 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, it 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 process of step S31. In the process 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 end the series of processes for registering the friend key KF.

[0086] <Registering a non-friend key KN> 7, the management system 10 performs a series of processes to register the non-friend key KN. Among the devices 30 that do not store the non-friend key information DKN, the device 30 that is designated as a non-friend device 52 by the series of processes is referred to as a third device 30C.

[0087] When an operation to request registration of a non-friend key KN is executed in 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). Thereafter, the friend device 51 proceeds to the process of step S42.

[0088] In step S42, the friend device 51 acquires 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 third device 30C 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. Note that the validity start time information ATP3, expiration date information ATP4, and name information ATP5 are set by the friend device 51. Thereafter, the third device 30C 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 include the signature information ATP1. Specifically, the third device 30C generates each piece of information included in the acquired share information SH2 as each piece of information in the unsigned non-friend key information DKNN. 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] Thereafter, the friend device 51 receives a completion notification M31 and a signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 acquires 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 unsigned 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 acquires a signature based on the operation. Thereafter, the friend device 51 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. As a result, the friend device 51 generates non-friend key information DKN. Thereafter, the friend device 51 uploads the generated non-friend key information DKN to the URL link, which is the invitation information IV2. Then, the friend device 51 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 becomes a non-friend device 52. The third device 30C then proceeds to the process of step S48.

[0096] In step S48, the third device 30C generates a key track request D33 for the non-friend key KN, and then 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 reject list. If the non-friend key KN is on the reject 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 subject of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the data DA of the vehicle 20 in the database DB as a 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 the third device 30C as a device 30 having the non-friend key KN registered in response to the registration request D31 from the friend device 51.

[0100] Thereafter, 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 also 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, it performs the process of step S50. In step S50, the vehicle 20 stores the received authentication package ATP. That is, the vehicle 20 stores the authentication package ATP as 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 third device 30C. Thereafter, upon receiving the key track completion notification M33, the third device 30C performs the process of step S51. In the process 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 end the series of processes for registering the non-friend key KN.

[0103] <Delete non-friend key KN> 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, and the process executed by the execution unit 71 will be described as a process executed by the management server 70.

[0104] <Deletion of non-friend key KN upon request from friend device 51> As shown in FIG. 8, the management system 10 performs a series of processes to delete the non-friend key KN based on the deletion reservation request D41 from the 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 deletion reservation request D41 for the non-friend key KN is generated. The deletion reservation request D41 is a signal requesting the deletion of the non-friend key KN when a specified condition RC, which will be described later, is satisfied.

[0106] The deletion reservation 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 the specified condition RC. The specified condition RC is a condition required to start deletion after receiving the deletion reservation request D41. The specified condition RC is predetermined. For example, the specified condition RC is that a predetermined fade-out period has elapsed since receiving the deletion reservation request D41. Then, the friend device 51 transmits the deletion reservation request D41 for the non-friend key KN to the management server 70.

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

[0108] Thereafter, when the friend device 51 receives the deletion pending 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 subject of the deletion reservation request D41 is on hold for deletion and will be deleted as soon as the specified condition RC is satisfied.

[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 deletion reservation request D41 in the database DB as a fade-out state. The fade-out state is a state in which the deletion reservation request D41 has been received but the execution of deletion is still pending. Thereafter, 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 advances the process to step S66.

[0111] In step S66, the management server 70 generates a deletion request D42 requesting the deletion of the non-friend key information DKN indicating the non-friend key KN that is the target of the deletion reservation 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 subject of the deletion reservation 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 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 deletion reservation 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 deletion 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 the process of 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 deletion completion notification M44 to the friend device 51, indicating that the series of deletions of the non-friend key KN in accordance with the deletion reservation request D41 have 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, to the HMI 32, information indicating that the deletion of the non-friend key KN that is the subject of the deletion reservation request D41 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. Thereafter, the management system 10 ends the series of processes for the deletion of this non-friend key KN.

[0119] <Deletion of non-friend key KN due to deletion in non-friend device 52> As shown in FIG. 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 in 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 deletion completion notification M51 to the management server 70 indicating that the non-friend key information DKN has been deleted.

[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 a deletion completion notification M52 to the friend device 51, indicating that the non-friend key information DKN has been deleted.

[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 requesting deletion of the authentication information AT for authenticating the non-friend key information DKN that was deleted in step S81. Then, the management server 70 transmits the deletion request D51 to the vehicle 20.

[0124] Thereafter, when vehicle 20 receives deletion request D51, vehicle 20 performs processing of step S85. In step S85, vehicle 20 deletes authentication information AT for authenticating non-friend key information DKN that was deleted in step S81 in accordance with deletion request D51. Then, vehicle 20 transmits completion notification M53 to management server 70 indicating that deletion of authentication information AT in accordance with 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 information DKN that was completely 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] <Deletion of Friend Key KF> Next, a series of processes for deleting a friend key KF in the management system 10 will be described. The following describes the series of steps from when a friend key KF is registered to when a friend key KF is not registered. In the following description, 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, and the process executed by the execution unit 71 will be described as a process executed by the management server 70.

[0128] <Deleting the friend key KF upon request from the owner device 40> As shown in FIG. 10, the management system 10 performs a series of processes to delete the friend key KF based on the deletion reservation request D61 from the owner device 40.

[0129] When an operation to request the deletion of a friend key KF is executed in the owner device 40, the owner device 40 first performs the processing of step S91. In step S91, a deletion reservation request D61 for the friend key KF is generated. The deletion reservation request D61 is a request for a deletion reservation. The deletion reservation request D61 is a signal requesting the deletion of the friend key KF when a specified condition RC, which will be described later, is satisfied.

[0130] The deletion reservation request D61 includes a signal requesting deletion of the friend key KF, digital key identification information ST3 indicating the friend key KF, and information indicating the specified condition RC. The specified condition RC is a condition necessary to start deletion after receiving the deletion reservation request D61. The specified condition RC is predetermined. For example, the specified condition RC is that a predetermined fade-out period has elapsed since receiving the deletion reservation request D61. Then, the owner device 40 transmits the deletion reservation request D61 for the friend key KF to the management server 70.

[0131] Thereafter, upon receiving the friend key KF deletion reservation request D61, the management server 70 performs the process of step S92. In step S92, the management server 70 generates a deletion pending notification M61 indicating that deletion is pending in accordance with the deletion reservation request D61. The management server 70 then transmits the deletion pending notification M61 to the owner device 40.

[0132] Thereafter, when the owner device 40 receives the deletion pending notification M61, the owner device 40 performs the process of step S93. In step S93, the owner device 40 presents to the HMI 32 information indicating that the friend key KF that is the subject of the deletion reservation request D61 is on hold for deletion and will be deleted as soon as the specified condition RC is satisfied.

[0133] After processing step S92, the management server 70 performs processing step S94. In step S94, the management server 70 stores the state of the friend key KF that is the target of the deletion reservation request D61 in the database DB as a fade-out state. The fade-out state is a state in which the deletion reservation request D61 has been received but the execution of deletion is still pending. The management server 70 then proceeds to processing step S95.

[0134] In step S95, 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 advances the process to step S96.

[0135] In step S96, the management server 70 generates a deletion request D62 requesting the deletion of the friend key information DKF indicating the friend key KF that is the target of the deletion reservation request D61. Then, the management server 70 transmits the deletion request D62 to the friend device 51.

[0136] Thereafter, when the friend device 51 receives the deletion request D62, it performs the process of step S97. In step S97, the friend device 51 deletes the friend key information DKF in accordance with the deletion request D62. Then, the friend device 51 transmits a deletion completion notification M62 to the management server 70, indicating that the deletion in accordance with the deletion request D62 has been completed.

[0137] Thereafter, when the management server 70 receives the completion notification M62, the management server 70 performs the process of step S98. In step S98, the management server 70 stores the history of the deletion of the friend key information DKF in the friend device 51. Thereafter, the management server 70 proceeds to the process of step S99.

[0138] In step S99, the management server 70 generates a deletion request D63 for the authentication information AT. The deletion request D63 for the authentication information AT indicates a request to delete the authentication information AT for authenticating the friend key KF that is the target of the deletion reservation request D61. The management server 70 then transmits the deletion request D63 to the vehicle 20.

[0139] Thereafter, when vehicle 20 receives deletion request D63, vehicle 20 performs processing of step S100. In step S100, vehicle 20 deletes authentication information AT for authenticating the friend key KF that is the subject of deletion reservation request D61 in accordance with deletion request D63. That is, vehicle 20 deletes authentication package ATP of friend key KF. Then, vehicle 20 transmits deletion completion notification M63 to management server 70 indicating that deletion of authentication information AT in accordance with deletion request D63 has been completed.

[0140] Thereafter, when the management server 70 receives the completion notification M63, the management server 70 performs the process of step S101. In step S101, the management server 70 stores the history of the deletion of the authentication information AT for authenticating the friend key KF to be deleted in the current series of deletion-related processes in the vehicle 20. Thereafter, the management server 70 proceeds to the process of step S102.

[0141] In step S102, the management server 70 updates the database DB. Specifically, the management server 70 deletes the friend device 51 having the friend key KF 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 deletion completion notification M64 to the owner device 40, indicating that the series of deletions of the friend key KF in accordance with the deletion reservation request D61 has been completed.

[0142] Thereafter, when the owner device 40 receives the completion notification M64, the owner device 40 performs the process of step S103. In step S103, the owner device 40 presents to the HMI 32 information indicating that the deletion of the friend key KF that is the subject of the deletion reservation request D61 has been completed. For example, the owner device 40 displays an image indicating the completion of the deletion of the friend key KF on the HMI 32. Thereafter, the management system 10 ends the series of processes for the deletion of this friend key KF.

[0143] <Deletion of friend key KF due to deletion on friend device 50> As shown in FIG. 11, the management system 10 performs a series of processes in response to a deletion operation on the friend device 51 to delete the friend key KF indicated by the friend key information DKF stored in the friend device 51.

[0144] When a predetermined operation requesting the deletion of the friend key KF is executed in the friend device 51, the friend device 51 first performs the processing of step S111. In step S111, the friend device 51 deletes the friend key information DKF in accordance with the predetermined operation. Thereafter, the friend device 51 transmits a deletion completion notification M71 to the management server 70, indicating that the friend key information DKF has been deleted.

[0145] Thereafter, when the management server 70 receives the completion notification M71, the management server 70 performs the process of step S112. In step S112, the management server 70 stores the history of the deletion of the friend key information DKF in the friend device 51. Thereafter, the management server 70 transmits a deletion completion notification M72 to the owner device 40, indicating that the friend key information DKF has been deleted.

[0146] Thereafter, when the owner device 40 receives the completion notification M72, the owner device 40 performs the process of step S113. In step S113, the owner device 40 presents, to the HMI 32, information indicating that the deletion of the friend key information DKF of the friend device 51 has been completed. For example, the owner device 40 displays, on the HMI 32, an image indicating that the deletion of the friend key KF has been completed.

[0147] After processing step S112, the management server 70 performs processing step S114. In step S114, the management server 70 generates a deletion request D71 requesting deletion of the authentication information AT for authenticating the friend key information DKF that was deleted in step S111. Then, the management server 70 transmits the deletion request D71 to the vehicle 20.

[0148] Thereafter, when vehicle 20 receives deletion request D71, vehicle 20 performs the process of step S115. In step S115, vehicle 20 deletes authentication information AT for authenticating friend key information DKF that was deleted in step S111 in accordance with deletion request D71. Then, vehicle 20 transmits completion notification M73 to management server 70 indicating that deletion of authentication information AT in accordance with deletion request D71 has been completed.

[0149] Thereafter, when the management server 70 receives the completion notification M73, the management server 70 performs the process of step S116. In step S116, the management server 70 stores the history of the deletion of the authentication information AT for authenticating the friend key information DKF that was completely deleted in step S111. Thereafter, the management server 70 proceeds to the process of step S117.

[0150] In step S117, the management server 70 updates the database DB. Specifically, the management server 70 deletes the friend device 51 having the friend key KF 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 friend key KF.

[0151] <Counting by the management server 70> As mentioned above, there is an upper limit to the number of pieces of authentication information AT that the vehicle 20 can store. The management server 70 determines the number of pieces of authentication information AT stored in the vehicle 20 based on the counting program PC. Then, the management server 70 executes processing according to the number of pieces of authentication information AT stored in the vehicle 20 using the counting program PC. The specific processing executed by the management server 70 based on the counting program PC will be described below.

[0152] <Count executed after digital key is registered> After the share key KS is registered in the management system 10, the count program PC causes the management server 70 to count the number of pieces of authentication information AT stored in the vehicle 20. Below, a series of steps from the registration of the share key KS until the execution of processing according to the number of pieces of authentication information AT stored in the vehicle 20 will be described. In the following explanation, the processing executed by the execution unit 36 ​​will be described as processing executed by the device 30, and the processing executed by the execution unit 71 will be described as processing executed by the management server 70.

[0153] After the shared key KS is registered, the management system 10 performs a series of processes shown in Fig. 12. That is, the management system 10 performs a series of processes shown in Fig. 12 after executing a series of processes shown in Fig. 6 or Fig. 7.

[0154] After the digital key is registered, the management server 70 first performs the process of step S121. In step S121, the management server 70 checks the number of pieces of authentication information AT stored in the vehicle 20.

[0155] The management server 70 stores in data DA the types of digital keys registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. The number of pieces of authentication information AT stored in the vehicle 20 matches the number of digital keys registered to the vehicle 20. The number of pieces of authentication information AT stored in the vehicle 20 also matches the number of devices 30 that store key information DK. Therefore, the management server 70 can confirm the number of pieces of authentication information AT stored in the vehicle 20 by referring to the database DB. After confirming the number of pieces of authentication information AT stored in the vehicle 20, the management server 70 proceeds to step S122.

[0156] In step S122, the management server 70 calculates the difference DF. The difference DF is the difference between the maximum number that can be registered for the vehicle 20 and the number of pieces of authentication information AT, which is information related to digital keys, stored in the vehicle 20.

[0157] If the calculated difference DF is equal to or smaller than the predetermined number PN, the management server 70 performs the process of step S123. The predetermined number PN is a reference number for determining whether the number of pieces of authentication information AT stored in the vehicle 20 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 through the owner device 40. Note that if the calculated difference DF is larger than the predetermined number PN, the processes from step S123 onwards are not performed.

[0158] In step S123, the management server 70 generates a shortage notification M81. The shortage notification M81 is a signal notifying that the difference DF is equal to or less than a predetermined number PN. The shortage notification M81 includes information about the friend devices 51 registered in the vehicle 20. Having generated the shortage notification M81, the management server 70 transmits the shortage notification M81 to the owner device 40. Upon receiving the shortage notification M81, the owner device 40 performs the process of step S124.

[0159] In step S124, the owner device 40 presents information indicating that the difference DF is equal to or less than the predetermined number PN to the HMI 32. For example, the owner device 40 presents an image indicating that the difference DF is equal to or less than the predetermined number PN to the HMI 32. Thereafter, the owner device 40 proceeds to step S125.

[0160] In step S125, the owner device 40 confirms with the user of the owner device 40 whether or not the stop request D81 is to be transmitted. For example, the owner device 40 displays on the HMI 32 an image asking whether or not the user wishes to transmit the stop request D81.

[0161] If the user of the owner device 40 wishes to send the stop request D81, the owner device 40 proceeds to step S126. For example, if the owner device 40 receives an operation from the user of the owner device 40 agreeing to the sending of the stop request D81, the owner device 40 determines that the user of the owner device 40 wishes to send the stop request D81. Note that if the user of the owner device 40 does not wish to send the stop request D81, the processes from step S126 onwards are not performed.

[0162] In step S126, the owner device 40 checks the destination of the stop request D81. If there are multiple friend devices 51 that store the friend key information DKF in the management system 10, the owner device 40 prompts the user of the owner device 40 to select a friend device 51 to which the stop request D81 is to be sent. For example, the owner device 40 presents the friend devices 51 registered in the vehicle 20 to the HMI 32, and then accepts an operation to select a destination of the stop request D81 from the presented friend devices 51.

[0163] Note that the processes of step S125 and step S126 may be performed simultaneously. That is, the owner device 40 may determine that the user of the owner device 40 wishes to send the stop request D81 when the user of the owner device 40 selects a friend device 51 to which the stop request D81 is to be sent. On the other hand, the owner device 40 may determine that the user of the owner device 40 does not wish to send the stop request D81 when the user of the owner device 40 does not select a friend device 51 to which the stop request D81 is to be sent.

[0164] After the user of the owner device 40 selects the destination of the stop request D81, the owner device 40 proceeds to step S127. In step S127, the owner device 40 generates a transmission request D82. The transmission request D82 is a signal requesting transmission of the stop request D81. The transmission request D82 includes information indicating the destination of the stop request D81 selected by the user of the owner device 40 in step S126.

[0165] The owner device 40 that has generated the transmission request D82 transmits the transmission request D82 to the management server 70. Upon receiving the transmission request D82, the management server 70 performs the process of step S128.

[0166] In step S128, the management server 70 generates a stop request D81. The stop request D81 is a signal requesting the friend device 51 not to request the registration of a new non-friend key KN. Having generated the stop request D81, the management server 70 transmits the stop request D81 to the friend device 51. At this time, the management server 70 transmits the stop request D81 to the friend device 51 that was selected by the user of the owner device 40 in step S126 as the destination of the stop request D81. Upon receiving the stop request D81, the friend device 51 performs the process of step S129.

[0167] In step S129, the friend device 51 stores the stop request D81. The friend device 51 that has stored the stop request D81 stops the function of requesting registration of a new non-friend key KN for the non-friend device 52. In other words, even if the user of the friend device 51 performs an operation to send the registration request D31 for the non-friend key KN shown in step S41 in Fig. 7, the friend device 51 does not execute the processes from step S41 onwards shown in Fig. 7. As a result, the management system 10 ends the series of processes for counting after the digital key is registered.

[0168] In this way, when the difference DF is equal to or less than the predetermined number PN, the friend device 51 restricts a request to the management server 70 to register a new non-friend key KN. Then, the management server 70 transmits restriction information to the friend device 51 in order to restrict a request by the friend device 51 to register a new non-friend key KN. The restriction information is information for restricting a request by the share device 50 to register a new share key KS. In the first embodiment, the management server 70 transmits a stop request D81 as the restriction information.

[0169] <Count to be executed after the digital key is deleted> 12, when the share key KS is deleted in the management system 10 after the stop request D81 is stored, the count program PC causes the management server 70 to count the number of pieces of authentication information AT stored in the vehicle 20. Below, a series of flows for executing processing according to the number of pieces of authentication information AT stored in the vehicle 20 when the share key KS is deleted after the stop request D81 is stored will be described. Note that in the following explanation, the processing executed by the execution unit 36 ​​will be described as processing executed by the device 30, and the processing executed by the execution unit 71 will be described as processing executed by the management server 70.

[0170] When the share key KS is deleted after the stop request D81 is stored, the management system 10 performs the series of processes shown in Fig. 13. That is, the management system 10 performs the series of processes shown in Fig. 12, then performs the series of processes shown in any one of Figs. 8 to 11, and then performs the series of processes shown in Fig. 13.

[0171] The management server 70 first performs the process of step S131. In step S131, the management server 70 checks the number of pieces of authentication information AT stored in the vehicle 20. The manner in which the management server 70 checks the number of pieces of authentication information AT stored in the vehicle 20 is similar to the manner in step S121 of FIG.

[0172] The management server 70 performs the process of step S132 after confirming the number of pieces of authentication information AT stored in the vehicle 20. In step S132, the management server 70 calculates the difference DF.

[0173] If the calculated difference DF is greater than the predetermined number PN, the management server 70 performs the process of step S133. If the calculated difference DF is equal to or less than the predetermined number PN, the processes from step S133 onwards are not performed.

[0174] In step S133, the management server 70 generates a release request D91. The release request D91 is a signal requesting the friend device 51, which has stopped requesting registration of a new non-friend key KN due to the suspension request D81, to release the suspension of registration of a new non-friend key KN.

[0175] The management server 70 that generated the release request D91 transmits the release request D91 to the friend device 51. In the processing of Fig. 12, if the stop request D81 has been transmitted only to the friend device 51 selected by the user of the owner device 40, the management server 70 transmits the release request D91 only to the friend device 51 to which the stop request D81 has been transmitted. The friend device 51 that has received the release request D91 performs the processing of step S134.

[0176] In step S134, the friend device 51 stores the release request D91. Having stored the release request D91, the friend device 51 releases the suspension of the function of registering a new non-friend key KN for the non-friend device 52. In other words, by storing the release request D91, the friend device 51 becomes able to again execute the processes from step S41 onwards shown in Fig. 7 when the user performs an operation to send the registration request D31 for the non-friend key KN shown in step S41. This causes the management system 10 to end the series of processes for counting after the digital key has been deleted.

[0177] <Operation of the First Embodiment> When the vehicle 20 stores a large amount of information related to digital keys, the management system 10 will not register a new shared key KS in response to a request from the shared device 50.

[0178] <Effects of the first embodiment> (1-1) The management system 10 prevents the number of pieces of information about the digital key stored in the vehicle 20 from reaching an upper limit without the owner's knowledge. This prevents the management system 10 from causing an event where the owner is unable to register a digital key when attempting to do so.

[0179] (1-2) The predetermined number PN can be set by the owner. As a result, the management system 10 can prevent new shared keys KS from being registered once the number of pieces of authentication information AT stored in the vehicle 20 reaches the number set by the owner.

[0180] (1-3) In the management system 10, the management server 70 transmits restriction information to the share device 50 to restrict requests to register new share keys KS. This enables the management system 10 to restrict requests from the share device 50 to register new share keys KS.

[0181] (1-4) In the management system 10, when the difference DF is equal to or less than the predetermined number PN, the management server 70 transmits a stop request D81 as restriction information to prompt the user to stop requests to register new shared keys KS. In the management system 10, when the share device 50 receives the stop request D81, it stops the function of transmitting requests to register new shared keys KS.

[0182] In the management system 10, the management server 70 requests the share device 50 not to request registration of a new share key KS. In this way, the management system 10 can make the share device 50 understand that the difference DF is equal to or less than the predetermined number PN, and can prevent the share device 50 from requesting registration of a new share key KS.

[0183] (1-5) In the management system 10, when the differential DF is equal to or less than a predetermined number PN, the management server 70 notifies the owner device 40 that the differential DF is equal to or less than the predetermined number PN, and when the owner wishes to send a stop request D81, sends a stop request D81 to the shared device 50.

[0184] Even if the difference DF becomes equal to or less than the predetermined number PN, there are cases in which the vehicle 20 can store new authentication information AT. In the management system 10, the management server 70 confirms with the owner whether or not to send the stop request D81 before sending the stop request D81. As a result, the management system 10 can have the shared device 50 request the registration of a new shared key KS, even if the difference DF becomes equal to or less than the predetermined number PN, as long as the owner gives permission.

[0185] (1-6) The owner device 40 makes the owner determine whether or not it is necessary to send a stop request D81. As a result, even if the difference DF becomes equal to or less than the predetermined number PN, the owner device 40 can make the shared device 50 request the registration of a new shared key KS as long as the owner allows it.

[0186] (1-7) When the number of pieces of authentication information AT stored in the vehicle 20 is large, the share device 50 limits requests to register a new share key KS. This prevents the number of pieces of information related to digital keys stored in the vehicle 20 from reaching an upper limit without the owner realizing it. This allows the share device 50 to prevent the owner from being unable to register a digital key when attempting to do so.

[0187] (1-8) After restricting requests to register a new shared key KS to the management server 70, when the difference DF becomes larger than the predetermined number PN, the shared device 50 lifts the restriction on requests to register a new shared key KS to the management server 70. This allows the shared device 50 to request registration of a new shared key KS again when the amount of authentication information AT stored in the vehicle 20 decreases.

[0188] (1-9) The management server 70 limits requests from the shared device 50 to register a new shared key KS. In other words, when the vehicle 20 stores a large number of pieces of authentication information AT, the management server 70 prevents the shared device 50 from registering a new shared key KS. This prevents the amount of information related to digital keys stored in the vehicle 20 from reaching an upper limit without the owner realizing it. This allows the management server 70 to prevent the occurrence of an event in which the owner is unable to register a digital key when attempting to do so.

[0189] (1-10) When the difference DF between the maximum number of digital keys that can be registered for the vehicle 20 and the number of pieces of information related to the digital keys stored in the vehicle 20 becomes equal to or less than a predetermined number PN, the management server 70 sends a stop request D81 as restriction information to prompt the suspension of requests to register new digital keys.

[0190] When the difference DF is equal to or less than a predetermined number PN, the management server 70 requests the share device 50 not to request the registration of a new share key KS for another share device 50. In this way, the management server 70 can limit requests by the share device 50 to register a new share key KS.

[0191] (1-11) When the differential DF is equal to or less than the predetermined number PN, the management server 70 notifies the owner device 40 that the differential DF is equal to or less than the predetermined number PN, and when the owner wishes to send a stop request D81, the management server 70 sends a stop request D81 to the shared device 50.

[0192] Even if the difference DF becomes equal to or less than the predetermined number PN, there are cases in which the vehicle 20 can store new authentication information AT. Before transmitting the stop request D81, the management server 70 confirms with the owner whether or not to transmit the stop request D81. As a result, even if the difference DF becomes equal to or less than the predetermined number PN, the management server 70 can cause the shared device 50 to request registration of a new shared key KS as long as the owner gives permission.

[0193] (1-12) There are multiple shared devices 50. The management server 70 sends the stop request D81 to one of the multiple shared devices 50 to which the owner has requested to send the stop request D81.

[0194] It is conceivable that there are multiple share devices 50 in the management system 10. In such a case, the management server 70 sends the stop request D81 only to the share device 50 to which the owner wishes to send the stop request D81. This allows the management server 70 to prevent registration of the share key KS in response to a request from a device 30 selected by the owner, while continuing to allow registration of the share key KS in response to a request from a device 30 not selected by the owner.

[0195] (1-13) After transmitting the stop request D81, when the difference DF becomes larger than the predetermined number PN, the management server 70 transmits to the shared device 50 a release request D91 that permits a request to register a new digital key.

[0196] In the management system 10, the registration of a digital key may be deleted, reducing the number of pieces of authentication information AT stored in the vehicle 20. In such a case, the management server 70 transmits a cancellation request D91. This enables the management server 70 to make the shared device 50 request registration of a new shared key KS again.

[0197] (Second embodiment) A second embodiment of the management system will be described below with reference to the drawings. The second embodiment differs from the first embodiment in that the vehicle management device 26 of the vehicle 20 stores a counting program PC. The following description will focus on the differences from the first embodiment, and the same descriptions will be simplified or omitted for the same points.

[0198] <20 vehicle configurations> 14, the storage device 28 stores a counting program PC2 in the second embodiment. The counting program PC2 is executed by the execution device 27, causing the execution device 27 to count the number of pieces of authentication information AT stored in the vehicle 20 and perform control according to the number. In the second embodiment, since the vehicle 20 stores the counting program PC2, the management server 70 does not need to store the counting program PC.

[0199] <Counting by vehicle 20> Based on the count program PC2, the vehicle 20 determines the number of pieces of authentication information AT stored in the vehicle 20. Then, the vehicle 20 executes processing according to the number of pieces of authentication information AT stored in the vehicle 20, using the count program PC2. The specific processing executed by the vehicle 20 based on the count program PC2 will be described below.

[0200] <Count executed after digital key is registered> The count program PC2 causes the vehicle 20 to count the number of pieces of authentication information AT stored in itself after the share key KS is registered in the management system 10. Below, a series of steps from the registration of the share key KS until the execution of processing according to the number of pieces of authentication information AT stored in the vehicle 20 will be described. In the following explanation, the processing executed by the execution unit 36 ​​will be described as the processing executed by the device 30, and the processing executed by the execution unit 27 will be described as the processing executed by the vehicle 20.

[0201] After the share key KS is registered, the management system 10 performs a series of processes shown in Fig. 15. In the second embodiment, the series of processes shown in Fig. 15 is executed instead of the series of processes shown in Fig. 12. That is, the management system 10 performs the series of processes shown in Fig. 15 after executing the series of processes shown in Fig. 6 or 7. In Fig. 15, the vehicle 20 communicates with the owner device 40 and the friend device 51 via the management server 70 and the device server 60.

[0202] After the digital key is registered, the vehicle 20 first performs the process of step S141. In step S141, the vehicle 20 checks the number of pieces of authentication information AT stored in the vehicle 20. After checking the number of pieces of authentication information AT stored in the vehicle 20, the vehicle 20 performs the process of step S142. In step S142, the vehicle 20 calculates the difference DF.

[0203] If the calculated difference DF is equal to or smaller than the predetermined number PN, the vehicle 20 performs the process of step S143. If the calculated difference DF is larger than the predetermined number PN, the processes from step S143 onwards are not performed.

[0204] In step S143, the vehicle 20 generates a shortage notification M101. The shortage notification M101 is a signal notifying that the difference DF is equal to or less than a predetermined number PN. The shortage notification M101 includes information about the friend devices 51 registered in the vehicle 20.

[0205] The vehicle 20 that has generated the shortage notification M101 transmits the shortage notification M101 to the owner device 40. Upon receiving the shortage notification M101, the owner device 40 performs the process of step S144.

[0206] In step S144, the owner device 40 presents information indicating that the difference DF is equal to or smaller than the predetermined number PN to the HMI 32. After that, the owner device 40 advances the process to step S145.

[0207] In step S145, the owner device 40 confirms with the user of the owner device 40 whether or not it is necessary to send the stop request D101. If the user of the owner device 40 wishes to send the stop request D101, the owner device 40 proceeds to step S146. If the user of the owner device 40 does not wish to send the stop request D101, the processes from step S146 onwards are not performed.

[0208] In step S146, the owner device 40 checks the destination of the stop request D101. If there are multiple friend devices 51 that store the friend key information DKF in the management system 10, the owner device 40 prompts the user of the owner device 40 to select a friend device 51 to which the stop request D101 is to be sent.

[0209] After the user of the owner device 40 selects the destination of the stop request D101, the owner device 40 proceeds to step S147. In step S147, the owner device 40 generates a transmission request D102. The transmission request D102 is a signal requesting transmission of the stop request D101. The transmission request D102 includes information indicating the destination of the stop request D101 selected by the user of the owner device 40 in step S146.

[0210] The owner device 40 that generated the transmission request D102 transmits the transmission request D102 to the vehicle 20. Upon receiving the transmission request D102, the vehicle 20 performs the process of step S148.

[0211] In step S148, the vehicle 20 generates a stop request D101. The stop request D101 is a signal requesting the friend device 51 not to request the registration of a new non-friend key KN. Having generated the stop request D101, the vehicle 20 transmits the stop request D101 to the friend device 51. At this time, the vehicle 20 transmits the stop request D101 to the friend device 51 that was selected by the user of the owner device 40 in step S146 as the destination of the stop request D101. Upon receiving the stop request D101, the friend device 51 performs the process of step S149.

[0212] In step S149, the friend device 51 stores the stop request D101. The friend device 51 that has stored the stop request D101 stops the function of requesting registration of a new non-friend key KN for the non-friend device 52. This causes the management system 10 to end the series of processes for counting after the digital key is registered.

[0213] In this way, the vehicle 20 transmits restriction information to the friend device 51 in order to restrict requests for registration of a new non-friend key KN by the friend device 51. In the second embodiment, the vehicle 20 transmits a stop request D101 as the restriction information.

[0214] <Count to be executed after the digital key is deleted> 15, when the share key KS is deleted in the management system 10 after the stop request D101 is stored, the count program PC2 causes the vehicle 20 to count the number of pieces of authentication information AT stored in itself. Below, a series of flows when the vehicle 20 executes processing according to the number of pieces of authentication information AT stored when the share key KS is deleted after the stop request D101 is stored will be described. In the following explanation, the processing executed by the execution unit 36 ​​will be described as processing executed by the device 30, and the processing executed by the execution unit 27 will be described as processing executed by the vehicle 20.

[0215] After the stop request D101 is stored, the management system 10 performs the series of processes shown in Fig. 16 when the share key KS is deleted. In the second embodiment, the series of processes shown in Fig. 16 is executed instead of the series of processes shown in Fig. 13. That is, the management system 10 executes the series of processes shown in Fig. 15, then executes the series of processes shown in any one of Figs. 8 to 11, and then executes the series of processes shown in Fig. 16. In Fig. 16, the vehicle 20 is communicating with the friend device 51 via the management server 70 and the device server 60.

[0216] First, the vehicle 20 performs the process of step S151. In step S151, the vehicle 20 checks the number of pieces of authentication information AT stored in the vehicle 20. After confirming the number of pieces of authentication information AT stored in the vehicle 20, the process proceeds to step S152. In the process of step S152, the vehicle 20 calculates the difference DF.

[0217] If the calculated difference DF is greater than the predetermined number PN, the vehicle 20 performs the process of step S153. If the calculated difference DF is equal to or less than the predetermined number PN, the processes from step S153 onwards are not performed.

[0218] In step S153, the vehicle 20 generates a cancellation request D111. The cancellation request D111 is a signal requesting the friend device 51, which has stopped requesting registration of a new non-friend key KN due to the suspension request D101, to cancel the suspension of registration of a new non-friend key KN.

[0219] The vehicle 20 that generated the release request D111 transmits the release request D111 to the friend device 51. In the processing of Fig. 15 , if the stop request D101 has been transmitted only to the friend device 51 selected by the user of the owner device 40, the vehicle 20 transmits the release request D111 only to the friend device 51 to which the stop request D101 has been transmitted. The friend device 51 that has received the release request D111 performs the processing of step S154.

[0220] In step S154, the friend device 51 stores the release request D111. Having stored the release request D111, the friend device 51 releases the suspension of the function for registering a new non-friend key KN for the non-friend device 52. This causes the management system 10 to end the series of processes for counting after the digital key has been deleted.

[0221] <Actions and Effects of the Second Embodiment> (2-1) The management system 10 of the second embodiment has the effects (1-1) and (1-2) of the first embodiment.

[0222] (2-2) The owner device 40 of the second embodiment has the effect of (1-6) in the first embodiment. (2-3) The share device 50 of the second embodiment has the effects (1-7) and (1-8) of the first embodiment.

[0223] (2-4) In the management system 10, the vehicle 20 transmits restriction information to the share device 50 to restrict requests to register a new share key KS. This enables the management system 10 to restrict requests from the share device 50 to register a new share key KS.

[0224] (2-5) In the management system 10, when the difference DF is equal to or less than the predetermined number PN, the vehicle 20 transmits, as restriction information, a stop request D101 that prompts the vehicle 20 to stop requests to register new shared keys KS. In the management system 10, when the share device 50 receives the stop request D101, the share device 50 stops the function of transmitting requests to register new shared keys KS.

[0225] In the management system 10, the vehicle 20 requests the shared device 50 not to request registration of a new shared key KS. This enables the management system 10 to notify the shared device 50 that the difference DF is equal to or less than a predetermined number PN, and to prevent the shared device 50 from requesting registration of a new shared key KS.

[0226] (2-6) In the management system 10, when the difference DF is equal to or less than a predetermined number PN, the vehicle 20 notifies the owner device 40 that the difference DF is equal to or less than the predetermined number PN, and when the owner wishes to send a stop request D101, the vehicle 20 sends a stop request D101 to the shared device 50.

[0227] Even if the difference DF becomes equal to or less than the predetermined number PN, there are cases in which the vehicle 20 can store new authentication information AT. In the management system 10, before transmitting the stop request D101, the vehicle 20 confirms with the owner whether or not to transmit the stop request D101. As a result, the management system 10 can cause the shared device 50 to request registration of a new shared key KS, as long as the owner allows it, even if the difference DF becomes equal to or less than the predetermined number PN.

[0228] (2-7) The vehicle 20 limits requests from the share device 50 to register a new share key KS. In other words, the vehicle 20 prevents the share device 50 from registering a new share key KS when the vehicle 20 has a large amount of authentication information AT stored in itself. This prevents the vehicle 20 from reaching an upper limit on the amount of information related to digital keys stored in the vehicle 20 without the owner realizing it. This prevents the vehicle 20 from failing to register a digital key when the owner attempts to do so.

[0229] (2-8) When the difference DF between the maximum number of digital keys that can be registered to the vehicle 20 and the number of pieces of information related to the digital keys stored in the vehicle 20 becomes equal to or less than a predetermined number KN, the vehicle 20 transmits a stop request D101 as restriction information to prompt the vehicle 20 to stop requests to register new digital keys.

[0230] When the difference DF is equal to or less than the predetermined number PN, the vehicle 20 requests the share device 50 not to request registration of a new share key KS for the other share device 50. This allows the vehicle 20 to limit requests by the share device 50 to register a new share key KS.

[0231] (2-9) When the difference DF is equal to or less than the predetermined number PN, the vehicle 20 notifies the owner device 40 that the difference DF is equal to or less than the predetermined number PN, and when the owner wishes to send a stop request D101, the vehicle 20 sends a stop request D101 to the shared device 50.

[0232] Even if the difference DF becomes equal to or less than the predetermined number PN, there are cases in which the vehicle 20 can store new authentication information AT. Before transmitting the stop request D101, the vehicle 20 confirms with the owner whether or not to transmit the stop request D101. As a result, even if the difference DF becomes equal to or less than the predetermined number PN, the vehicle 20 can cause the shared device 50 to request registration of a new shared key KS as long as the owner gives permission.

[0233] (2-10) There are multiple shared devices 50. The vehicle 20 transmits the stop request D101 to one of the multiple shared devices 50 to which the owner has requested the transmission of the stop request D101.

[0234] When there are multiple shared devices 50, the vehicle 20 transmits the stop request D101 only to the shared devices 50 to which the owner wishes to transmit the stop request D101. This allows the vehicle 20 to prevent the registration of the shared key KS in response to a request from a device 30 selected by the owner, while continuing to allow the registration of the shared key KS in response to a request from a device 30 not selected by the owner.

[0235] (2-11) After transmitting the stop request D101, when the difference DF becomes larger than the predetermined number PN, the vehicle 20 transmits to the shared device 50 a release request D111 that permits a request to register a new digital key.

[0236] The vehicle 20 transmits a cancellation request D111 when the registration of the digital key is deleted and the number of pieces of authentication information AT stored in the vehicle 20 decreases, which enables the vehicle 20 to make the shared device 50 request registration of a new shared key KS again.

[0237] (Third embodiment) A third embodiment of the management system will be described below with reference to the drawings. The third embodiment differs from the first embodiment in that the friend device 51 calculates the difference DF. The following description will focus on the differences from the first embodiment, and descriptions of the same points will be simplified or omitted.

[0238] <Counting by the management server 70 of the third embodiment> The management server 70 determines the number of pieces of authentication information AT stored in the vehicle 20 based on the count program PC. After that, the friend device 51 calculates the difference DF, and the management system 10 executes processing according to the number of pieces of authentication information AT stored in the vehicle 20. The following describes specific processing executed by the management system 10 of the third embodiment.

[0239] <Count executed after digital key is registered> After the share key KS is registered, the management system 10 of the third embodiment counts the number of pieces of authentication information AT stored in the vehicle 20. Below, a series of steps will be described in the management system 10 of the third embodiment, from when the share key KS is registered until a process corresponding to the number of pieces of authentication information AT stored in the vehicle 20 is executed. In the following description, the process executed by the execution unit 36 ​​will be described as a process executed by the device 30, and the process executed by the execution unit 71 will be described as a process executed by the management server 70.

[0240] After the shared key KS is registered, the management system 10 performs a series of processes shown in Fig. 17. In the third embodiment, the series of processes shown in Fig. 17 is executed instead of the series of processes shown in Fig. 12. That is, the management system 10 performs the series of processes shown in Fig. 17 after executing the series of processes shown in Fig. 6 or Fig. 7.

[0241] After the digital key is registered, the management server 70 first performs the process of step S161. In step S161, the management server 70 checks the number of pieces of authentication information AT stored in the vehicle 20.

[0242] The management server 70 confirms the number of pieces of authentication information AT stored in the vehicle 20, and then transmits the number information M111. The number information M111 is information indicating the number of pieces of authentication information AT, which is information related to the digital key, stored in the vehicle 20.

[0243] After receiving the number information M111, the friend device 51 performs the process of step S162. In step S162, the friend device 51 calculates the difference DF. If the calculated difference DF is equal to or smaller than the predetermined number PN, the friend device 51 performs the process of step S163. If the calculated difference DF is larger than the predetermined number PN, the processes from step S163 onwards are not performed.

[0244] In step S163, the friend device 51 generates a shortage notification M112. The shortage notification M112 is a signal notifying that the difference DF is equal to or less than a predetermined number PN. The shortage notification M112 includes information about the friend device 51 registered in the vehicle 20.

[0245] The friend device 51 that generated the shortage notification M112 transmits the shortage notification M112 to the owner device 40. Upon receiving the shortage notification M112, the owner device 40 performs the process of step S164.

[0246] In step S164, the owner device 40 presents information indicating that the difference DF is equal to or smaller than the predetermined number PN to the HMI 32. After that, the owner device 40 advances the process to step S165.

[0247] In step S165, the owner device 40 confirms with the user of the owner device 40 whether or not it is necessary to send a request notification M113. The request notification M113 is a signal indicating that the owner wishes to stop the function of the shared device 50 to send a request to register a new shared key KS.

[0248] If the user of the owner device 40 desires to send the request notification M113, the owner device 40 proceeds to step S166. If the user of the owner device 40 does not desire to send the request notification M113, the processes from step S166 onwards are not performed.

[0249] In step S166, the owner device 40 generates a request notification M113. Having generated the request notification M113, the owner device 40 transmits the request notification M113 to the friend device 51. Upon receiving the request notification M113, the friend device 51 performs the process of step S167.

[0250] In step S167, the friend device 51 stops the function of requesting registration of a new non-friend key KN for the non-friend device 52. This causes the management system 10 to end the series of processes for counting after the digital key is registered.

[0251] In this way, the management server 70 transmits the number information M111 as restriction information in order to restrict requests from the friend device 51 for registration of a new non-friend key KN.

[0252] <Count to be executed after the digital key is deleted> In Figure 17, when the function requesting registration of a new non-friend key KN is stopped and the shared key KS is deleted, the management system 10 counts the number of pieces of authentication information AT stored in the vehicle 20. Below, we will explain the series of steps that are taken when processing is performed according to the number of pieces of authentication information AT stored in the vehicle 20 when the function requesting registration of a new non-friend key KN is stopped and the shared key KS is deleted. In the following explanation, the processing performed by the execution unit 36 ​​will be explained as processing performed by the device 30, and the processing performed by the execution unit 71 will be explained as processing performed by the management server 70.

[0253] The management system 10 performs a series of processes shown in Fig. 18 when a shared key KS is deleted after the function for requesting registration of a new non-friend key KN is stopped. In the third embodiment, a series of processes shown in Fig. 18 is executed instead of the series of processes shown in Fig. 13. That is, the management system 10 executes a series of processes shown in Fig. 17, then executes a series of processes shown in any one of Figs. 8 to 11, and then executes a series of processes shown in Fig. 18.

[0254] The management server 70 first performs the process of step S171. In step S171, the management server 70 checks the number of pieces of authentication information AT stored in the vehicle 20. The management server 70 transmits quantity information M121 after confirming the number of pieces of authentication information AT stored in the vehicle 20. The quantity information M121 is information indicating the number of pieces of authentication information AT, which is information related to the digital key, stored in the vehicle 20.

[0255] After receiving the number information M121, the friend device 51 performs the process of step S172. In the process of step S172, the friend device 51 calculates the difference DF.

[0256] If the calculated difference DF is greater than the predetermined number PN, the friend device 51 performs the process of step S173. If the calculated difference DF is equal to or less than the predetermined number PN, the processes from step S173 onwards are not performed.

[0257] In step S173, the friend device 51 releases the suspension of the function of registering a new non-friend key KN for the non-friend device 52. This causes the management system 10 to end the series of processes for counting after the digital key has been deleted.

[0258] <Actions and Effects of the Third Embodiment> (3-1) The management system 10 of the third embodiment has the advantages of (1-1) to (1-3) in the first embodiment.

[0259] (3-2) The share device 50 of the third embodiment has the effects (1-7) and (1-8) of the first embodiment. (3-3) The management server 70 of the third embodiment has the effect of (1-9) in the first embodiment.

[0260] (3-4) In the management system 10, the management server 70 transmits, as restriction information, number information M111 indicating the number of pieces of information related to digital keys stored in the vehicle 20. In the management system 10, when the shared device 50 receives the number information M111, it calculates the difference DF, and when the calculated difference DF is equal to or less than a predetermined number PN, it stops the function of transmitting a request to register a new shared key KS.

[0261] In the management system 10, after the share device 50 calculates the difference DF, it stops the function of requesting the registration of a new share key KS according to the calculated difference DF. This allows the management system 10 to limit requests by the share device 50 to register a new share key KS.

[0262] (3-5) In the management system 10, when the calculated difference DF is equal to or less than the predetermined number PN, the share device 50 notifies the owner device 40 that the difference DF is equal to or less than the predetermined number PN. In the management system 10, when the owner requests to stop the function of sending a request to register a new share key KS for the share device 50, the share device 50 stops the function of sending a request to register a new share key KS.

[0263] In the management system 10, the share device 50 stops the function of requesting registration of a new share key KS when the owner so desires. As a result, the share device 50 can request registration of a new share key KS as long as the owner allows it, even if the difference DF falls below the predetermined number PN.

[0264] (3-6) The owner device 40 allows the owner to determine whether or not to stop requests for registration of a new shared key KS from the shared device 50. As a result, even if the difference DF becomes equal to or less than the predetermined number PN, the owner device 40 can cause the shared device 50 to request registration of a new shared key KS as long as the owner allows it.

[0265] (3-7) When the share device 50 receives the quantity information M111 indicating the number of pieces of information related to the digital keys stored in the vehicle 20, the share device 50 calculates the difference DF based on the quantity information M111, and if the calculated difference DF is equal to or less than a predetermined number PN, the share device 50 stops the function of sending a request to register a new share key KS.

[0266] The share device 50 calculates the difference DF and suspends the function of requesting the registration of a new share key KS based on the calculated difference DF. This allows the share device 50 to restrict the function of requesting the registration of a new share key KS based on the difference DF.

[0267] (3-8) The management server 70 transmits, as restriction information, quantity information M111 indicating the number of pieces of information related to the digital keys stored in the vehicle 20 to the share device 50. This enables the management server 70 to restrict the share device 50 from requesting the registration of a new share key KS.

[0268] (Fourth embodiment) A fourth embodiment of the management system will be described below with reference to the drawings. The fourth embodiment differs from the second embodiment in that the friend device 51 calculates the difference DF. The following description will focus on the differences from the second embodiment, and descriptions of the same points will be simplified or omitted.

[0269] <Counting by the vehicle 20 of the fourth embodiment> The vehicle 20 determines the number of pieces of authentication information AT stored in itself based on the count program PC2. After that, the friend device 51 calculates the difference DF, and the management system 10 executes processing according to the number of pieces of authentication information AT stored in the vehicle 20. The following describes specific processing executed by the management system 10 of the fourth embodiment.

[0270] <Count executed after digital key is registered> The management system 10 of the fourth embodiment counts the number of pieces of authentication information AT stored in the vehicle 20 after the share key KS is registered. Below, a series of steps will be described in the management system 10 of the fourth embodiment, from when the share key KS is registered until a process corresponding to the number of pieces of authentication information AT stored in the vehicle 20 is executed. In the following description, the process executed by the execution unit 36 ​​will be described as the process executed by the device 30, and the process executed by the execution unit 27 will be described as the process executed by the vehicle 20.

[0271] After the shared key KS is registered, the management system 10 performs a series of processes shown in Fig. 19. In the fourth embodiment, the series of processes shown in Fig. 19 is executed instead of the series of processes shown in Fig. 15. That is, the management system 10 performs the series of processes shown in Fig. 19 after executing the series of processes shown in Fig. 6 or Fig. 7.

[0272] After the digital key is registered, the vehicle 20 first performs the process of step S181. In step S181, the vehicle 20 checks the number of pieces of authentication information AT stored in the vehicle 20. After checking the number of pieces of authentication information AT stored in the vehicle 20, the vehicle 20 transmits the number information M131. The number information M131 indicates the number of pieces of authentication information AT, which is information related to the digital key, stored in the vehicle 20.

[0273] After receiving the number information M131, the friend device 51 performs the process of step S182. In step S182, the friend device 51 calculates the difference DF. If the calculated difference DF is equal to or smaller than the predetermined number PN, the friend device 51 performs the process of step S183. If the calculated difference DF is larger than the predetermined number PN, the processes from step S183 onwards are not performed.

[0274] In step S183, the friend device 51 generates a shortage notification M132. The shortage notification M132 is a signal notifying that the difference DF is equal to or less than the predetermined number PN. The shortage notification M132 includes information about the friend device 51 registered in the vehicle 20.

[0275] The friend device 51 that generated the shortage notification M132 transmits the shortage notification M132 to the owner device 40. Upon receiving the shortage notification M132, the owner device 40 performs the process of step S184.

[0276] In step S184, the owner device 40 presents information indicating that the difference DF is equal to or smaller than the predetermined number PN to the HMI 32. After that, the owner device 40 advances the process to step S185.

[0277] In step S185, the owner device 40 confirms with the user of the owner device 40 whether or not it is necessary to send a request notification M133. The request notification M133 is a signal indicating that the owner wishes to stop the function of the shared device 50 to send a request to register a new shared key KS.

[0278] If the user of the owner device 40 desires to send the request notification M133, the owner device 40 proceeds to step S186. If the user of the owner device 40 does not desire to send the request notification M133, the processes from step S186 onwards are not performed.

[0279] In step S186, the owner device 40 generates a request notification M133. Having generated the request notification M133, the owner device 40 transmits the request notification M133 to the friend device 51. Upon receiving the request notification M133, the friend device 51 performs the process of step S187.

[0280] In step S187, the friend device 51 stops the function of requesting registration of a new non-friend key KN for the non-friend device 52. This causes the management system 10 to end the series of processes for counting after the digital key is registered.

[0281] In this way, the vehicle 20 transmits the number information M131 as restriction information in order to restrict requests from the friend device 51 to register a new non-friend key KN. <Count to be executed after the digital key is deleted> In Figure 19, when the function requesting registration of a new non-friend key KN is stopped and the shared key KS is deleted, the management system 10 counts the number of pieces of authentication information AT stored in the vehicle 20. Below, we will explain the series of steps that occur when the vehicle 20 executes processing according to the number of pieces of authentication information AT stored when the function requesting registration of a new non-friend key KN is stopped and the shared key KS is deleted. In the following explanation, the processing executed by the execution unit 36 ​​will be explained as processing executed by the device 30, and the processing executed by the execution unit 27 will be explained as processing executed by the vehicle 20.

[0282] The management system 10 performs a series of processes shown in Fig. 20 when a shared key KS is deleted after the function for requesting registration of a new non-friend key KN is stopped. In the fourth embodiment, the series of processes shown in Fig. 20 is executed instead of the series of processes shown in Fig. 16. That is, the management system 10 executes the series of processes shown in Fig. 19, then executes the series of processes shown in any one of Figs. 8 to 11, and then executes the series of processes shown in Fig. 20.

[0283] First, vehicle 20 performs the process of step S191. In step S191, vehicle 20 checks the number of pieces of authentication information AT stored in vehicle 20 itself. After checking the number of pieces of authentication information AT stored in the vehicle 20, the vehicle 20 transmits the number information M141. The number information M141 indicates the number of pieces of authentication information AT, which is information related to the digital key, stored in the vehicle 20.

[0284] After receiving the number information M141, the friend device 51 performs the process of step S192. In the process of step S192, the friend device 51 calculates the difference DF.

[0285] If the calculated difference DF is greater than the predetermined number PN, the friend device 51 performs the process of step S193. If the calculated difference DF is equal to or less than the predetermined number PN, the processes from step S193 onwards are not performed.

[0286] In step S193, the friend device 51 releases the suspension of the function of registering a new non-friend key KN for the non-friend device 52. This causes the management system 10 to end the series of processes for counting after the digital key has been deleted.

[0287] <Actions and Effects of the Fourth Embodiment> (4-1) The management system 10 of the fourth embodiment has the effects (1-1) and (1-2) of the first embodiment.

[0288] (4-2) The share device 50 of the fourth embodiment has the effects (1-7) and (1-8) of the first embodiment. (4-3) The management system 10 of the fourth embodiment has the effect of (2-4) in the second embodiment.

[0289] (4-4) The vehicle 20 of the fourth embodiment has the effect of (2-7) in the second embodiment. (4-5) The management system 10 of the fourth embodiment has the effect of (3-5) in the third embodiment.

[0290] (4-5) The owner device 40 of the fourth embodiment has the effect of (3-6) in the third embodiment. (4-6) The share device 50 of the fourth embodiment has the effect of (3-7) in the third embodiment.

[0291] (4-7) In the management system 10, the vehicle 20 transmits, as restriction information, number information M131 indicating the number of pieces of information related to digital keys stored in the vehicle 20. In the management system 10, when the share device 50 receives the number information M131, it calculates the difference DF, and when the calculated difference DF is equal to or less than a predetermined number PN, it stops the function of transmitting a request to register a new share key KS.

[0292] In the management system 10, after the share device 50 calculates the difference DF, it stops the function of requesting the registration of a new share key KS according to the calculated difference DF. This allows the management system 10 to limit requests by the share device 50 to register a new share key KS.

[0293] (4-8) The vehicle 20 transmits, as restriction information, quantity information M131 indicating the number of pieces of information related to the digital keys stored in the vehicle 20 to the share device 50. This allows the vehicle 20 to restrict the share device 50 from requesting the registration of a new share key KS.

[0294] (Other embodiments) The above-described embodiments can be modified as follows: The embodiments and the following modifications can be combined with each other within the scope of technical compatibility.

[0295] <Management System 10> The vehicle 20 may not have all 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. Furthermore, the vehicle 20 is not limited to these modules, and may have any module that performs short-range communication with the device 30.

[0296] 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, it may be a central ECU that manages multiple ECUs in the vehicle 20.

[0297] The vehicle management device 26 may be configured as a circuit including one or more processors that execute various processes according to a computer program (software). The vehicle management device 26 may also be configured as a circuit including one or more dedicated hardware circuits, such as an application-specific integrated circuit (ASIC), that execute at least some of the various processes, or a combination thereof. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to execute the processes. 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.

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

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

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

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

[0302] The management server 70 may be configured with multiple servers. For example, it may be configured with a server that stores the database DB and a server that executes the server program PS. Alternatively, it 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.

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

[0304] <Various information> 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.

[0305] The configuration of the information included in the key information DK is not limited to the example in the above embodiment. For example, the owner key information DKO does not have to include the slot identification information ST4. Also, for example, 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.

[0306] The database DB may include information indicating the type of the device 30. The type of the device 30 is information indicating, for example, a smartphone, a smartwatch, or a predetermined server as in the above-described modified example.

[0307] The structure of the data DA in the database DB is not limited to the examples in the above embodiments, as long as the database DB contains the information required for management by the management server 70 in the management system 10.

[0308] 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. Also, the authority may not be determined in the database DB.

[0309] <The process for registering a digital key> The series of processes 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 by the process of step S12. The series of processes 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.

[0310] 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 contained in the friend key information DKF and the structure of the information contained in the authentication information AT.

[0311] The series of processes for registering a non-friend key KN is not limited to the examples in the above embodiments. The order of the processes for registering a friend key KF may be different. The series of processes for registering a 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.

[0312] The types of digital keys do not have to include non-friend keys KN. In other words, in the management system 10, the shared keys KS may only be friend keys KF. <The process for deleting a digital key> In the above embodiments, when deleting the non-friend key KN, the friend device 51 transmits a deletion reservation request D41 to the management server 70, thereby requesting that the non-friend key KN be deleted when the specified condition RC is satisfied. On the other hand, the friend device 51 may transmit a request to delete the non-friend key KN to the management server 70 regardless of the specified condition RC. Furthermore, the management server 70 may proceed with the processing from step S62 onwards in response to a request to delete the non-friend key KN not only from the friend device 51 but also from the owner device 40.

[0313] In the above embodiments, when deleting a friend key KF, the owner device 40 requests that the friend key KF be deleted when the specified condition RC is met by sending a deletion reservation request D41 to the management server 70. However, the owner device 40 may also send a request to delete the friend key KF to the management server 70 regardless of the specified condition RC.

[0314] In each of the above embodiments, the management server 70 receives the deletion reservation request D41, but the deletion reservation request D41 may also be received by the vehicle 20. In this case, the vehicle 20 may determine whether the specified condition RC is met, and delete the authentication information AT when the specified condition RC is met. The vehicle 20 may then transmit to the management server 70 a notification indicating that the authentication information AT has been deleted based on the deletion reservation request D41. The management server 70 may then update the database DB and transmit a deletion request D42 to the non-friend device 52.

[0315] In each of the above embodiments, the management server 70 receives the deletion reservation request D61, but the deletion reservation request D61 may also be received by the vehicle 20. In this case, the vehicle 20 may determine whether the specified condition RC is met, and delete the authentication information AT when the specified condition RC is met. Thereafter, the vehicle 20 may transmit a notification to the management server 70 indicating that the authentication information AT has been deleted based on the deletion reservation request D61. Thereafter, the management server 70 may update the database DB and transmit a deletion request D62 to the friend device 51.

[0316] 9, when deleting a non-friend device 52 due to an operation on the non-friend device 52, a request to delete the non-friend key KN may be sent to the management server 70 before a completion notification M51 is sent to the management server 70. In this case, similar to the series of flows shown in FIG. 8, when the management server 70 receives the request, the management server 70 may send a request to delete the non-friend key information DKN to the non-friend device 52.

[0317] 11, when deleting a friend device 51 due to an operation on the friend device 51, a request to delete the friend key KF may be sent to the management server 70 before a completion notification M71 is sent to the management server 70. In this case, similar to the series of flows shown in FIG. 10, when the management server 70 receives the request, the management server 70 may send a request to delete the friend key information DKF to the friend device 51.

[0318] In both cases where a non-friend key KN is deleted due to operation of the friend device 51 and where a non-friend key KN is deleted due to operation of the non-friend device 52, a reservation for deletion may be requested from the management server 70.

[0319] The owner device 40 and the vehicle 20 may request the deletion of the non-friend key KN. Alternatively, for example, the management server 70 may generate a request to delete the non-friend key KN when a predetermined condition is satisfied.

[0320] The vehicle 20 may request the deletion of the friend key KF. Alternatively, for example, the management server 70 may generate a request to delete the friend key KF when a predetermined condition is met. <Process after registering the digital key> 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.

[0321] In this case, the stop request D81 or the stop request D101 may also be transmitted to the non-friend device 52. In this case, the release request D91 or the release request D111 may also be transmitted to the non-friend device 52. In this case, the number information M111, the number information M121, the number information M131, or the number information M141 may also be transmitted to the non-friend device 52.

[0322] In the first to fourth embodiments, the predetermined number PN is determined in advance by the owner of the vehicle 20. In the first to fourth embodiments, 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.

[0323] Furthermore, 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. Furthermore, for example, the predetermined number PN may be determined in advance by the provider of the vehicle 20 or the management server 70.

[0324] In the first embodiment, the management system 10 performs the series of processes shown in Fig. 12 after the shared key KS is registered, that is, after performing the series of processes shown in Fig. 6 or 7. The timing when the management system 10 performs the series of processes shown in Fig. 12 is not limited to after the shared key KS is registered.

[0325] For example, the management system 10 may perform the series of processes shown in Fig. 12 after receiving the key track request D23 and the friend key information DKF in Fig. 6 and before the management server 70 performs registration management of the friend key KF in step S29. Also, for example, the management system 10 may perform the series of processes shown in Fig. 12 after the management server 70 performs registration management of the friend key KF in step S29 in Fig. 6 and before sending the storage request D24 and the authentication package ATP. Also, for example, the management system 10 may perform the series of processes shown in Fig. 12 after the management server 70 performs registration management of the friend key KF in step S29 in Fig. 6 and before sending the completion notification M23.

[0326] For example, the management system 10 may perform the series of processes shown in Fig. 12 after receiving the key track request D33 and the non-friend key information DKN in Fig. 7 and before the management server 70 performs registration management of the non-friend key KN in step S49. Also, for example, the management system 10 may perform the series of processes shown in Fig. 12 after the management server 70 performs registration management of the non-friend key KN in step S49 in Fig. 7 and before sending the storage request D34 and the authentication package ATP. Also, for example, the management system 10 may perform the series of processes shown in Fig. 12 after the management server 70 performs registration management of the non-friend key KN in step S49 in Fig. 7 and before sending the completion notification M33.

[0327] For example, the management system 10 may periodically execute the series of processes shown in FIG. 12 regardless of whether or not the digital key has been registered. In the first embodiment, the management server 70 confirms with the owner whether or not to send the stop request D81 by sending a shortage notification M81 to the owner device 40 before sending the stop request D81, as shown in FIG. 12 . The management server 70 does not need to confirm with the owner whether or not to send the stop request D81 before sending the stop request D81. In this case, the management server 70 transmits the stop request D81 to the friend device 51, for example, without sending a shortage notification M81.

[0328] In the first embodiment, the management server 70 transmits the stop request D81 to the friend device 51 selected by the owner in step S125. On the other hand, the management server 70 does not have to allow the owner to select the destination of the stop request D81. In this case, the management server 70 transmits the stop request D81 to all friend devices 51.

[0329] 12 , after the owner device 40 transmits a transmission request D82 to the management server 70, the management server 70 transmits a stop request D81 to the friend device 51. On the other hand, the owner device 40 may transmit the stop request D81 directly to the friend device 51 without transmitting the transmission request D82 to the management server 70.

[0330] In the second embodiment, the management system 10 performs the series of processes shown in Fig. 15 after the shared key KS is registered, that is, after performing the series of processes shown in Fig. 6 or 7. The timing when the management system 10 performs the series of processes shown in Fig. 15 is not limited to after the shared key KS is registered.

[0331] For example, the management system 10 may perform a series of processes shown in FIG. 15 after the vehicle 20 receives the storage request D24 and the authentication package ATP in FIG. 6 and before storing the authentication package ATP in step S30.

[0332] For example, the management system 10 may perform a series of processes shown in FIG. 15 after the vehicle 20 receives the storage request D34 and the authentication package ATP in FIG. 7 and before storing the authentication package ATP in step S50.

[0333] For example, the management system 10 may periodically execute the series of processes shown in FIG. 12 regardless of whether or not the digital key has been registered. In the second embodiment, the vehicle 20 transmits a shortage notification M101 to the owner device 40 before transmitting the stop request D101 in FIG. 15 , thereby confirming with the owner whether or not to transmit the stop request D101. The vehicle 20 does not need to confirm with the owner whether or not to transmit the stop request D101 before transmitting the stop request D101. In this case, the vehicle 20 transmits the stop request D101 to the friend device 51, for example, without transmitting the shortage notification M101.

[0334] 15 , in the second embodiment, the vehicle 20 transmits the stop request D101 to the friend device 51 selected by the owner in step S145. On the other hand, the vehicle 20 does not have to allow the owner to select the destination of the stop request D101. In this case, the vehicle 20 transmits the stop request D101 to all friend devices 51.

[0335] 15 , after the owner device 40 transmits a transmission request D102 to the vehicle 20, the vehicle 20 transmits a stop request D101 to the friend device 51. Alternatively, the owner device 40 may transmit the stop request D101 directly to the friend device 51 without transmitting the transmission request D102 to the vehicle 20.

[0336] In the third embodiment, the management system 10 performs the series of processes shown in Fig. 17 after the shared key KS is registered, that is, after performing the series of processes shown in Fig. 6 or 7. The timing when the management system 10 performs the series of processes shown in Fig. 17 is not limited to after the shared key KS is registered.

[0337] For example, the management system 10 may perform the series of processes shown in Fig. 17 after receiving the key track request D23 and the friend key information DKF in Fig. 6 and before the management server 70 performs registration management of the friend key KF in step S29. Also, for example, the management system 10 may perform the series of processes shown in Fig. 17 after the management server 70 performs registration management of the friend key KF in step S29 in Fig. 6 and before sending the storage request D24 and the authentication package ATP. Also, for example, the management system 10 may perform the series of processes shown in Fig. 17 after the management server 70 performs registration management of the friend key KF in step S29 in Fig. 6 and before sending the completion notification M23.

[0338] For example, the management system 10 may perform the series of processes shown in Fig. 17 after receiving the key track request D33 and the non-friend key information DKN in Fig. 7 and before the management server 70 performs registration management of the non-friend key KN in step S49. Also, for example, the management system 10 may perform the series of processes shown in Fig. 17 after the management server 70 performs registration management of the non-friend key KN in step S49 in Fig. 7 and before sending the storage request D34 and the authentication package ATP. Also, for example, the management system 10 may perform the series of processes shown in Fig. 17 after the management server 70 performs registration management of the non-friend key KN in step S49 in Fig. 7 and before sending the completion notification M33.

[0339] For example, the management system 10 may periodically execute the series of processes shown in FIG. 17 regardless of whether or not the digital key has been registered. In the third embodiment, the share device 50 confirms with the owner whether or not it is necessary to suspend the function for requesting registration of a new shared key KS by transmitting a shortage notification M112 to the owner device 40 in FIG. 17 . The share device 50 does not need to confirm with the owner whether or not it is necessary to suspend the function for requesting registration of a new shared key KS. In this case, the share device 50, for example, suspends the function for requesting registration of a new shared key KS without transmitting the shortage notification M112.

[0340] In the third embodiment, the management server 70 transmits the number information M111. For example, the management server 70 may calculate the difference DF and then transmit the calculated difference DF to the sharing device 50. In this case, the sharing device 50 performs the processes from step S163 onward in accordance with the difference DF without calculating the difference DF itself.

[0341] In the fourth embodiment, the management system 10 performs the series of processes shown in Fig. 19 after the shared key KS is registered, that is, after performing the series of processes shown in Fig. 6 or 7. The timing when the management system 10 performs the series of processes shown in Fig. 19 is not limited to after the shared key KS is registered.

[0342] For example, the management system 10 may perform the series of processes shown in Fig. 19 after receiving the key track request D23 and the friend key information DKF in Fig. 6 and before the management server 70 performs registration management of the friend key KF in step S29. Also, for example, the management system 10 may perform the series of processes shown in Fig. 19 after the management server 70 performs registration management of the friend key KF in step S29 in Fig. 6 and before sending the storage request D24 and the authentication package ATP. Also, for example, the management system 10 may perform the series of processes shown in Fig. 19 after the management server 70 performs registration management of the friend key KF in step S29 in Fig. 6 and before sending the completion notification M23.

[0343] For example, the management system 10 may perform the series of processes shown in Fig. 19 after receiving the key track request D33 and the non-friend key information DKN in Fig. 7 and before the management server 70 performs registration management of the non-friend key KN in step S49. Also, for example, the management system 10 may perform the series of processes shown in Fig. 19 after the management server 70 performs registration management of the non-friend key KN in step S49 in Fig. 7 and before sending the storage request D34 and the authentication package ATP. Also, for example, the management system 10 may perform the series of processes shown in Fig. 19 after the management server 70 performs registration management of the non-friend key KN in step S49 in Fig. 7 and before sending the completion notification M33.

[0344] For example, the management system 10 may periodically execute the series of processes shown in FIG. 19 regardless of whether or not the digital key has been registered. In the fourth embodiment, the share device 50 confirms with the owner whether or not it is necessary to suspend the function for requesting registration of a new shared key KS by transmitting a shortage notification M132 to the owner device 40 in FIG. 19 . The share device 50 does not need to confirm with the owner whether or not it is necessary to suspend the function for requesting registration of a new shared key KS. In this case, the share device 50, for example, suspends the function for requesting registration of a new shared key KS without transmitting a shortage notification M132.

[0345] In the fourth embodiment, the vehicle 20 transmits the number information M131. For example, the vehicle 20 may calculate the difference DF and then transmit the calculated difference DF to the sharing device 50. In this case, the sharing device 50 performs the processes from step S183 onward in accordance with the difference DF without calculating the difference DF itself.

[0346] In the second and fourth embodiments, the vehicle 20 communicates with the plurality of devices 30 via the management server 70 and the device server 60. On the other hand, the vehicle 20 may communicate directly with the plurality of devices 30 via, for example, BLE communication or NFC communication. Also, for example, the vehicle 20 can communicate directly with the plurality of devices 30 via a wireless communication network, and may communicate directly with the plurality of devices 30 via a wireless communication network.

[0347] <Process after deleting the digital key> In the first embodiment, the management system 10 performs the series of processes shown in Fig. 13 after the shared key KS is deleted, that is, after performing the series of processes shown in any one of Figs. 8 to 11. The timing when the management system 10 performs the series of processes shown in Fig. 13 is not limited to after the shared key KS is deleted. For example, the management system 10 may periodically perform the series of processes shown in Fig. 13 after performing the series of processes shown in Fig. 12, regardless of whether the digital key has been deleted.

[0348] In the second embodiment, the management system 10 performs the series of processes shown in Fig. 16 after the shared key KS is deleted, that is, after performing the series of processes shown in any one of Figs. 8 to 11. The timing when the management system 10 performs the series of processes shown in Fig. 16 is not limited to after the shared key KS is deleted. For example, the management system 10 may periodically perform the series of processes shown in Fig. 16 after performing the series of processes shown in Fig. 15, regardless of whether the digital key has been deleted.

[0349] In the second embodiment, the vehicle 20 communicates with the plurality of devices 30 via the management server 70 and the device server 60 in Fig. 16. On the other hand, the vehicle 20 may communicate directly with the plurality of devices 30 via, for example, BLE communication or NFC communication in Fig. 16. Also, for example, the vehicle 20 can directly communicate with the plurality of devices 30 via a wireless communication network, and may directly communicate with the plurality of devices 30 via a wireless communication network in Fig. 16.

[0350] In the third embodiment, the management system 10 performs the series of processes shown in Fig. 18 after the shared key KS is deleted, that is, after performing the series of processes shown in any one of Figs. 8 to 11. The timing when the management system 10 performs the series of processes shown in Fig. 18 is not limited to after the shared key KS is deleted. For example, the management system 10 may periodically perform the series of processes shown in Fig. 18 after performing the series of processes shown in Fig. 17, regardless of whether the digital key has been deleted.

[0351] In the third embodiment, the management server 70 transmits the number information M121. For example, the management server 70 may calculate the difference DF and then transmit the calculated difference DF to the sharing device 50. In this case, the sharing device 50 performs the process of step S173 in accordance with the difference DF without calculating the difference DF itself.

[0352] In the fourth embodiment, the management system 10 performs the series of processes shown in Fig. 20 after the shared key KS is deleted, that is, after performing the series of processes shown in any one of Figs. 8 to 11. The timing when the management system 10 performs the series of processes shown in Fig. 20 is not limited to after the shared key KS is deleted. For example, the management system 10 may periodically perform the series of processes shown in Fig. 20 after performing the series of processes shown in Fig. 19, regardless of whether the digital key has been deleted.

[0353] In the fourth embodiment, the vehicle 20 transmits the number information M141. For example, the vehicle 20 may calculate the difference DF and then transmit the calculated difference DF to the sharing device 50. In this case, the sharing device 50 performs the process of step S193 in accordance with the difference DF without calculating the difference DF itself.

[0354] <Additional Notes> The technical concepts that can be understood from the above-described embodiments and modifications will be described below. [Appendix 1] A management system comprising a vehicle that stores information about digital keys, a device that stores information about the digital keys registered for the vehicle, and a management server that manages the registration of the digital keys, wherein the digital keys include an owner key that is registered for an owner device that belongs to the owner of the vehicle, and a share key that is registered for a share device that is a device separate from the owner device, and wherein when the difference between the maximum number of digital keys that can be registered for the vehicle and the amount of information about the digital keys stored in the vehicle falls below a predetermined number, the share device restricts requests for registration of new share keys to the management server.

[0355] [Supplementary Note 2] The management system according to Supplementary Note 1, wherein the predetermined number can be set by the owner. [Supplementary Note 3] The management system according to Supplementary Note 1 or Supplementary Note 2, wherein the management server transmits restriction information to the share device to restrict requests for registering new share keys.

[0356] [Appendix 4] A management system as described in Appendix 3, wherein when the difference is less than or equal to the predetermined number, the management server sends a stop request as the restriction information to prompt the user to stop requesting to register new share keys, and when the share device receives the stop request, the share device stops its function of sending requests to register new share keys.

[0357] [Appendix 5] A management system as described in Appendix 4, wherein the management server notifies the owner device that the difference is less than or equal to the specified number when the difference is less than or equal to the specified number, and sends the stop request to the shared device when the owner wishes to send the stop request.

[0358] [Appendix 6] The management system described in Appendix 3, wherein the management server transmits, as the restriction information, quantity information indicating the number of pieces of information relating to the digital key stored in the vehicle, and the share device, upon receiving the quantity information, calculates the difference and, when the calculated difference is equal to or less than the predetermined number, stops the function of transmitting a request to register a new share key.

[0359] [Appendix 7] A management system according to appendix 1 or 2, in which the vehicle transmits restriction information to the share device to restrict requests for registering new share keys. [Appendix 8] A management system as described in Appendix 7, in which the vehicle sends a stop request as the restriction information when the difference is less than or equal to the predetermined number, prompting the vehicle to stop requests to register new share keys, and when the share device receives the stop request, the share device stops its function of sending requests to register new share keys.

[0360] [Appendix 9] A management system as described in Appendix 8, in which the vehicle notifies the owner device that the difference is less than or equal to the predetermined number when the difference is less than or equal to the predetermined number, and sends the stop request to the share device when the owner wishes to send the stop request.

[0361] [Appendix 10] The vehicle transmits, as the restriction information, quantity information indicating the number of pieces of information relating to the digital key stored in the vehicle, and when the share device receives the quantity information, it calculates the difference and, when the calculated difference is equal to or less than the predetermined number, stops the function of transmitting a request to register a new share key.

[0362] [Appendix 11] A management system as described in Appendix 6 or Appendix 10, wherein the share device notifies the owner device that the calculated difference is less than or equal to the predetermined number when the calculated difference is less than or equal to the predetermined number, and when the owner wishes to stop the function of sending a request to register a new share key for the share device, stops the function of sending a request to register a new share key.

[0363] [Appendix 12] Among the devices provided in the management system described in Appendix 5 or Appendix 9, a device that is the owner device and transmits a signal indicating a desire to transmit the stop request when it receives a notification that the difference is less than or equal to the predetermined number.

[0364] [Appendix 13] Among the devices provided in the management system described in Appendix 11, the device is the owner device, and when it receives a notification that the difference is less than the predetermined number, it sends a signal indicating that it wishes to stop the function of sending a request to register a new share key for the share device. [Explanation of symbols]

[0365] 10...Management system 20...Vehicle 26...Vehicle management device 27...Execution device 28…Storage device 30…Devices 36...Execution device 37…Storage device 40...Owner device 50...Shared devices 51...Friend Device 52...Non-Friendly Device 60...Device Server 70...Administration server AT…Authentication information DF…Difference DK...Key information DKO…Owner key information DKS…Share Key Information KF...Friend Key KN...Non-Friend Key KO…Owner key KS...Share Key PC, PC2...Counting program PN...predetermined number

Claims

1. a vehicle that stores information about a digital key; a device that stores information about the digital keys registered for the vehicle; a management server that manages registration of the digital key; A management system comprising: The digital keys include an owner key registered for an owner device that is the device belonging to the owner of the vehicle, and a shared key registered for a shared device that is the device other than the owner device, When a difference between the maximum number of the digital keys that can be registered for the vehicle and the amount of information related to the digital keys stored in the vehicle becomes equal to or less than a predetermined number, the share device restricts requests to the management server for registering new share keys. Management system.

2. The predetermined number is configurable by the owner. The management system according to claim 1 .

3. The management server transmits restriction information to the share device to restrict requests for registering new share keys. The management system according to claim 1 .

4. when the difference is equal to or less than the predetermined number, the management server transmits, as the restriction information, a stop request that prompts the user to stop making requests to register new share keys; When the share device receives the stop request, the share device stops the function of transmitting a request for new registration of the share key. The management system according to claim 3 .

5. When the difference is equal to or less than the predetermined number, the management server notifies the owner device that the difference is equal to or less than the predetermined number, and when the owner desires to send the stop request, sends the stop request to the shared device. The management system according to claim 4.

6. the management server transmits, as the restriction information, number information indicating the number of pieces of information related to the digital key stored in the vehicle; When the share device receives the number information, it calculates the difference, and when the calculated difference is equal to or less than the predetermined number, it stops the function of transmitting a request to register a new share key. The management system according to claim 3 .

7. The vehicle transmits restriction information to the share device to restrict requests for registering new share keys. The management system according to claim 1 .

8. When the difference is equal to or less than the predetermined number, the vehicle transmits, as the restriction information, a stop request that prompts the vehicle to stop requesting registration of a new share key; When the share device receives the stop request, the share device stops the function of transmitting a request for new registration of the share key. The management system according to claim 7.

9. When the difference is equal to or less than the predetermined number, the vehicle notifies the owner device that the difference is equal to or less than the predetermined number, and when the owner desires to transmit the stop request, transmits the stop request to the share device. The management system according to claim 8.

10. the vehicle transmits, as the restriction information, number information indicating the number of pieces of information related to the digital key stored in the vehicle; When the share device receives the number information, it calculates the difference, and when the calculated difference is equal to or less than the predetermined number, it stops the function of transmitting a request to register a new share key. The management system according to claim 7.

11. When the calculated difference is equal to or less than the predetermined number, the share device notifies the owner device that the difference is equal to or less than the predetermined number, and when the owner requests that the share device stop the function of transmitting a request to register a new share key, the share device stops the function of transmitting a request to register a new share key. The management system according to claim 6 or 10.

12. The device is the owner device among the devices included in the management system according to claim 5 or claim 9, When receiving a notification that the difference is equal to or less than the predetermined number, a signal indicating a desire to transmit the stop request is transmitted. device.

13. The device is the owner device among the devices included in the management system according to claim 11, When receiving a notification that the difference is equal to or less than the predetermined number, a signal is transmitted to the share device requesting that the function of transmitting a request to register a new share key be stopped. device.

14. a vehicle that stores information about a digital key; a device that stores information about the digital key registered for the vehicle; and a management server that manages registration of the digital key; The digital key is a device that functions as a shared device in a management system in which an owner key is registered for an owner device that belongs to the owner of the vehicle, and a shared key is registered for a shared device that is a device different from the owner device, When the difference between the maximum number of the digital keys that can be registered for the vehicle and the amount of information related to the digital keys stored in the vehicle becomes equal to or less than a predetermined number, a request to register a new shared key to the management server is restricted. device.

15. When receiving number information indicating the number of pieces of information related to the digital keys stored in the vehicle, the difference is calculated based on the number information, and if the calculated difference is equal to or less than the predetermined number, the function of transmitting a request to register a new shared key is stopped.

15. The device of claim 14.

16. After restricting requests for new registration of the share key to the management server, when the difference becomes greater than the predetermined number, the restriction on requests for new registration of the share key to the management server is lifted.

16. A device according to claim 14 or claim 15.

17. a management server that can communicate with a vehicle that stores information about a digital key and a device that stores information about the digital key registered for the vehicle, and that manages registration of the digital key; The control server transmits restriction information to a shared device that is a device other than the owner device that belongs to the vehicle owner, for restricting requests to register a new digital key to the management server. Management server.

18. When the difference between the maximum number of the digital keys that can be registered for the vehicle and the number of pieces of information related to the digital keys stored in the vehicle becomes equal to or less than a predetermined number, a stop request is transmitted as the restriction information, which urges the user to stop requests to register new digital keys.

18. The management server of claim 17.

19. When the difference is equal to or less than the predetermined number, the owner device is notified that the difference is equal to or less than the predetermined number, and when the owner desires to transmit the stop request, the stop request is transmitted to the share device.

20. The management server of claim 18.

20. There are a plurality of said shared devices, The stop request is sent to the shared device to which the owner wishes to send the stop request, among the plurality of shared devices.

20. The management server of claim 19.

21. After transmitting the stop request, when the difference becomes greater than the predetermined number, a release request is transmitted to the shared device to permit a request for new registration of the digital key. The management server according to any one of claims 18 to 20.

22. As the restriction information, number information indicating the number of pieces of information related to the digital key stored in the vehicle is transmitted to the share device.

18. The management server of claim 17.

23. a vehicle that can communicate with a device that stores information about a digital key and a management server that manages registration of the digital key, and that stores information about the digital key; The vehicle owner may also have access to a shared device that is a device other than the owner device. The shared device may then have access to the management server and transmit restriction information to the management server to restrict requests for new registration of the digital key. vehicle.

24. When the difference between the maximum number of digital keys that can be registered for the vehicle and the number of pieces of information related to the digital keys stored in the vehicle becomes equal to or less than a predetermined number, a stop request is sent as the restriction information to stop requests to register new digital keys.

24. The vehicle of claim 23.

25. When the difference is equal to or less than the predetermined number, the owner device is notified that the difference is equal to or less than the predetermined number, and when the owner desires to transmit the stop request, the stop request is transmitted to the share device.

25. The vehicle of claim 24.

26. There are a plurality of said shared devices, The stop request is sent to the shared device to which the owner wishes to send the stop request, among the plurality of shared devices.

26. The vehicle of claim 25.

27. After transmitting the stop request, when the difference becomes greater than the predetermined number, a release request is transmitted to the shared device to permit a request for new registration of the digital key. The vehicle according to any one of claims 24 to 26.

28. As the restriction information, number information indicating the number of pieces of information related to the digital key stored in the vehicle is transmitted to the share device.

24. The vehicle of claim 23.

Images