vehicle

Abstract

The present invention provides a vehicle in which the use of the vehicle by the user of the digital key outside of the usage period can be restricted compared to the usage period. [Solution] Vehicle 20 has a device that stores information about the digital key registered as the digital key. Vehicle 20 changes the range of functions that the digital key can perform during periods other than the usage period UT to a narrower range than the range of functions that the digital key can perform during the usage period UT (S60, S64).

Description

[Technical Field]

[0001] The present invention relates to vehicles. [Background Art]

[0002] Patent Literature 1 discloses a technology of a digital key system that uses a device such as a smartphone as a vehicle key. The digital key system causes a vehicle to store information related to a digital key. The digital key system causes a device to store information related to a digital key. This enables the vehicle to be used using the device registered as a digital key without requiring a vehicle-dedicated key. Further, in the digital key system, a registration request for causing another person's device to function as a digital key is made through communication between the device storing information related to the digital key and the other person's device. Accordingly, the digital key system is configured to be capable of registering the other person's device as a digital key in the vehicle. That is, a digital key can be used to newly generate another separate digital key. The digital key system allows the vehicle to be lent to another person without requiring the handover of a vehicle-dedicated key. [Prior Art Literature] [Patent Literature]

[0003] [Patent Literature 1] Japanese Unexamined Patent Application Publication No. 2024-001720 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] When lending a vehicle, there is a demand from the vehicle lender to restrict the period for which the borrower can use the vehicle. In the digital key system as described in Patent Literature 1, a borrower who has been lent the vehicle can use the vehicle without restriction by using the newly generated digital key. [Means for Solving the Problem]

[0005] A vehicle for solving the above problem is a vehicle in which a device that stores information about a digital key is registered as the digital key. The vehicle comprises a storage device that stores the range of functions of the vehicle that the digital key can perform, and a processing circuit. The processing circuit changes the range of functions of the vehicle that the digital key can perform during periods other than the usage period, which is the period during which the user of the digital key uses the vehicle, to a narrower range than the range of functions of the vehicle that the digital key can perform during the usage period. [Effects of the Invention]

[0006] The above-mentioned vehicles may have restrictions on the use of the vehicle by the digital key user outside of the usage period compared to the usage period. [Brief explanation of the drawing]

[0007] [Figure 1] Figure 1 is a schematic diagram showing the management system of the first embodiment. [Figure 2] Figure 2 is a schematic diagram showing the owner key information of the first embodiment. [Figure 3] Figure 3 is a schematic diagram showing the share key information of the first embodiment. [Figure 4] Figure 4 is a schematic diagram showing the data in the database of the first embodiment. [Figure 5] Figure 5 is an explanatory diagram showing a series of processes performed by the management system when an owner key is registered in the first embodiment. [Figure 6] Figure 6 is an explanatory diagram showing a series of processes performed by the management system when a friend key is registered in the first embodiment. [Figure 7] Figure 7 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is registered in the first embodiment. [Figure 8]Figure 8 is a flowchart showing a series of processes that change the range of vehicle functions that the digital key can perform in the vehicle of the first embodiment. [Figure 9] Figure 9 is an explanatory diagram illustrating the series of processes performed by the management system of the first embodiment to delete a digital key. [Figure 10] Figure 10 is a flowchart showing a series of processes by which the vehicle of the second embodiment changes the range of vehicle functions that can be performed by the digital key. [Figure 11] Figure 11 is an explanatory diagram illustrating a series of processes by which the vehicle of the third embodiment changes the range of vehicle functions that can be performed by the digital key. [Figure 12] Figure 12 is an explanatory diagram illustrating a series of processes by which the vehicle of the fourth embodiment changes the range of vehicle functions that can be performed by the digital key. [Figure 13] Figure 13 is a schematic diagram showing a specific region in the fifth embodiment. [Modes for carrying out the invention]

[0008] (First Embodiment) The management system comprising the vehicle 20 in the first embodiment will be described below with reference to Figures 1 to 9.

[0009] <Overview of Management System 10> As shown in Figure 1, the management server 70 is one of the devices that make up the management system 10. The management server 70 manages information about multiple digital keys that are registrable for the vehicle 20 by communicating with the vehicle 20 and multiple devices 30. Regarding digital keys, there is a standard set by the Car Connectivity Consortium (CCC). The matters concerning digital keys in this embodiment are assumed to comply with the CCC, but are applicable to standards and systems other than the CCC. The management system 10 comprises the vehicle 20, multiple devices 30, a device server 60, and a management server 70.

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

[0011] The communication module 21 communicates with the management server 70 via a wireless communication line. The HMI 22 includes an input device and a display device. The input device receives user inputs from the vehicle 20 and inputs signals indicating the inputs to the vehicle 20. The display device presents information to the user through images and sounds, etc. The display device is, for example, a monitor and a speaker.

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

[0013] The vehicle management device 26 is installed in the vehicle 20. The vehicle management device 26 manages multiple digital keys for 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 a digital key in order to enable control of the vehicle 20 by the digital key when using the digital key. Authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU, i.e., a processing circuit. The execution device 27 executes the processing related to the storage and deletion of authentication information AT by executing the vehicle program PV.

[0014] When the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables 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 unlocking of the vehicle 20. Further, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables starting of the vehicle 20.

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

[0016] The communication module 31 communicates with a device server 60 via a wireless communication line. The HMI 32 includes an input device and a presentation device. The input device receives an operation by a user of the device 30, and inputs a signal indicating the operation to the device 30. The presentation device presents information to the user by means of images, sounds, and the like. The presentation device is, for example, a monitor and a speaker.

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

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

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

[0020] The owner device 40 stores owner key information DKO, which indicates the owner key KO, as key information DK. Only one owner key KO can be registered for each vehicle 20. Therefore, there is only one owner key KO for each vehicle 20.

[0021] As shown in Figure 2, the owner key information DKO has owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The owner key structure information STO also includes certificate information ST5, device public key information ST6, vehicle public key information ST7, authorization public key information ST8, and authorization information ST9.

[0022] Vehicle identification information ST1 is information that identifies the vehicle 20 to which the digital key is to be set. For example, it is the ID of vehicle 20. The in-device key identification information ST2 is used for managing digital keys within device 30. The in-device key identification information ST2 is information that allows for the identification of digital keys within the application of device 30.

[0023] Digital key identification information ST3 is used for managing digital keys within the management server 70. Slot identification information ST4 is information that allows the digital key to be identified locally on device 30.

[0024] Certificate information ST5 indicates the certificate that certifies the digital key. Device public key information ST6 indicates the device public key PKD, which is the public key of device 30. Note that the device public key PKD in owner key information DKO indicates the public key of owner device 40. Vehicle public key information ST7 indicates the vehicle public key PKV, which is the public key of vehicle 20. Authorized public key information ST8 indicates the vehicle public key PKV that has already been authorized. Authority information ST9 indicates the range of functions that device 30, which stores the authority information ST9, can perform. The range of functions that can be performed will be described later.

[0025] As shown in Figure 1, the share device 50 stores share key information DKS, which indicates the share key KS, as key information DK. Share key information DKS is information about the share key KS. The share key KS is a digital key that can be registered multiple times for one vehicle 20 in order to register the digital key in order to make the digital key usable. In other words, multiple share keys KS can exist for one vehicle 20.

[0026] Multiple share devices 50 include friend devices 51 and non-friend devices 52. Friend device 51 stores friend key information DKF, which indicates friend key KF, as share key information DKS. Friend key information DKF is information about share key KS. Non-friend device 52 stores non-friend key information DKN, which indicates non-friend key KN, as share key information DKS. Non-friend key information DKN is information about share key KS. In other words, the types of share key KS include friend key KF and non-friend key KN.

[0027] The friend key KF is a share key KS registered directly from the owner device 40 based on a registration request D21, as described later. The registration request D21 is a request to cause device 30 to store the friend key information DKF, which is the key information DK. In other words, the registration request D21 is a request to cause another device 30 to store information about a new share key KS.

[0028] The non-friend key KN is a share key KS registered based on a registration request D31 from the friend device 51, as described later. The registration request D31 is a request to cause device 30 to store the new share key information DKS, which is the non-friend key information DKN. In other words, the registration request D31 is a request to cause another device 30 to store information about the new share key KS. The non-friend key KN is a share key KS registered based on an indirect registration request from the share device 50, which is a device 30 different from the owner device 40.

[0029] Furthermore, when a digital key is registered, it means that the digital key is usable. That is, when a digital key is registered, the vehicle 20 stores authentication information AT corresponding to key information DK, and the device 30 stores key information DK corresponding to authentication information AT. Authentication information AT is information about the digital key. That is, when a digital key is registered, the vehicle 20 stores information about the digital key. Key information DK is information about the digital key. That is, when a digital key is registered, the device 30 stores information about the digital key. If key information DK is information about a shared key KS, then the authentication information AT corresponding to that key information DK is also information about the shared key KS.

[0030] As shown in Figure 3, the share key information DKS has a share key structure information STS and an authentication package ATP. The share key structure information STS includes vehicle identification information ST1, device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The share key structure information STS also includes certificate information ST5, vehicle public key information ST7, and authorized public key information ST8. In other words, the share key structure information STS is the owner key structure information STO with the device public key information ST6 and authorization information ST9 removed.

[0031] The authentication package ATP includes signature information ATP1, password information ATP2, activation start information ATP3, expiration information ATP4, name information ATP5, device public key information ATP6, and authorization information ATP7.

[0032] Signature information ATP1 indicates that shared device 50 is a legitimate recipient of the digital key. For example, in the case of friend device 51, it indicates a signature by owner device 40. Owner signature information indicates that owner device 40 signed the device public key PKD of friend device 51, which is shown in device public key information ATP6. Also, for example, in the case of non-friend device 52, it indicates a signature by friend device 51. Friend signature information indicates that friend device 51 signed the device public key PKD of non-friend device 52, which is shown in device public key information ATP6.

[0033] Password information ATP2 indicates the pairing password PAS used when establishing a secure channel during pairing between the vehicle 20 and the owner device 40. Effective start information ATP3 indicates the earliest date and time when the share key KS can be used. Expiration date information ATP4 indicates the latest date and time when the share key KS can be used. Name information ATP5 indicates the name that identifies the share device 50 that stores the share key information DKS. For example, it is set as an identifiable name for each share device 50 by an operation from the owner device 40. Authorization information ATP7 is information that indicates the range of functions that the device 30 that stores the authorization information ATP7 can perform.

[0034] The range of functions that can be performed includes, for example, the number of Share Key KS registrations that can be requested, and the range of functions of the vehicle 20 that can be performed by digital key authentication. For example, the number of Friend Key KF registrations that an Owner Device 40 can request is greater than the number of Non-Friend Key KN registrations that a Friend Device 51 can request.

[0035] The range of functions that can be performed on the vehicle 20 is, for example, the possible controls among starting the vehicle 20's engine, turning on the vehicle 20's power, and unlocking and locking the vehicle 20's doors. For example, if the range of functions that can be performed on the vehicle 20 is the three controls described above, the range of functions that can be performed on the vehicle 20 is wider than if the range of functions that can be performed on the vehicle 20 is only unlocking and locking the vehicle 20's doors. More specifically, the range of functions that the friend device 51 can perform on the vehicle 20 is the three functions described above, while the range of functions that the non-friend device 52 can perform on the vehicle 20 is turning on the vehicle 20's power and unlocking and locking the vehicle 20's doors.

[0036] As shown in Figure 1, the device server 60 relays communication between the device 30 and the management server 70. A separate device server 60 is provided for each type of device 30. That is, the device server 60 that a first-type device 30 communicates with is different from the device server 60 that a second-type device 30 communicates with. Both device servers 60 relay communication with the management server 70, allowing devices 30 of different types to communicate with the management server 70 via the device server 60. Note that only one device server 60 is shown in Figure 1.

[0037] <Management Server 70> The management server 70 manages multiple digital keys. The management server 70 can communicate with the vehicle 20 and multiple devices 30. The management server 70 comprises an execution unit 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 can also communicate wirelessly with the communication module 21 of the vehicle 20.

[0038] The execution device 71 and the storage device 72 constitute a computer. The execution device 71 is the CPU, or processing circuit. The storage device 72 is memory. The storage device 72 stores the server program PS and the database DB.

[0039] The server program PS, when executed by the execution device 71, causes the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB. The server program PS also causes the execution device 71 to delete digital keys.

[0040] The database DB associates each of the multiple digital keys with the corresponding vehicle 20 and the registered device 30. The database DB is divided into data DA for each vehicle 20. When a digital key is registered, the management server 70 stores information in the data DA indicating the device 30 that stores the key information DK representing that digital key.

[0041] As shown in Figure 4, the data DA of a single vehicle 20 includes the type of digital key registered to the vehicle 20, the registered device 30, and the relationships between the registered devices 30. The relationships between the devices 30 are the relationships between the multiple digital keys registered to each device 30. A hierarchy of priority is determined by the type of digital key. From top to bottom in the hierarchy, the keys are Owner Key KO, Friend Key KF, and Non-Friend Key KN. Higher levels of the hierarchy grant greater authority.

[0042] Permissions include, for example, the number of shared keys KS that can be requested to be registered, and the range of vehicles 20 that can be controlled by digital key authentication. Higher levels of the hierarchy indicate greater permissions; for example, a higher number of shared keys KS that can be requested to be registered. More specifically, for example, the number of friend keys KF that an owner device 40 can request to be registered is greater than the number of non-friend keys KN that a friend device 51 can request to be registered.

[0043] Furthermore, for example, the higher the hierarchy, the greater the authority, and therefore the wider the control range of the controllable vehicle 20. The control range of the controllable vehicle 20 refers to the possible controls among, for example, engine start control of vehicle 20, power-on control of vehicle 20, and unlocking and locking control of vehicle 20. For example, if the control range of the controllable vehicle 20 includes the three controls mentioned above, the control range of the controllable vehicle 20 is wider than if the control range of the controllable vehicle 20 is limited to unlocking and locking the doors of vehicle 20. More specifically, the control range of vehicle 20 that can be controlled by friend key KF includes the three controls mentioned above, while the control range of vehicle 20 that can be controlled by non-friend key KN is limited to unlocking and locking the doors of vehicle 20.

[0044] This section describes a state in which a digital key is registered for seven devices 30 for one vehicle 20. The seven devices 30 are referred to as Device 1 30A to Device 7 30G. The digital keys registered for each of Devices 1 30A to Device 7 30G are referred to as Digital Key 1 DK1 to Digital Key 7 DK7.

[0045] In the data DA, device 30, which is registered as owner key KO, is the first device 30A. That is, the first device 30A is owner device 40. In other words, the first digital key DK1 is owner key KO.

[0046] In the data DA, the devices 30 registered with the digital key type as Share 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. In other words, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are Share Devices 50. That is, the second digital key DK2 to the seventh digital key DK7 are all Share Key KS.

[0047] More specifically, in the data DA, the devices 30 registered with the digital key type as Friend Key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are Friend Devices 51. In the data DA, the devices 30 registered with the digital key type as Non-Friend Key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are Non-Friend Devices 52.

[0048] 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 DK2 is registered based on the first digital key DK1.

[0049] 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 DK5 is registered based on the first digital key DK1.

[0050] In the data DA, the relationship between the third device 30C and the second device 30B is such that the non-friendly 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 DK3 is registered based on the second digital key DK2.

[0051] In the data DA, the relationship between the fourth device 30D and the second device 30B is such that the non-friendly 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 DK4 is registered based on the second digital key DK2.

[0052] In the data DA, the relationship between the sixth device 30F and the fifth device 30E is such that the non-friendly 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 DK6 is registered based on the fifth digital key DK5.

[0053] In the data DA, the relationship between the 7th device 30G and the 5th device 30E is such that the non-friendly key KN is registered in the 7th device 30G as a result of a registration request from the 5th device 30E. In other words, the 7th digital key DK7 is registered based on the 5th digital key DK5.

[0054] Thus, the data DA stores the devices 30 that have been registered as digital keys. Furthermore, it associates information indicating the device 30 that made the request that triggered the registration of the device 30. The data DA also includes information indicating which digital key each digital key is based on.

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

[0056] <Owner Key Registration> As shown in Figure 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 will be designated as the owner device 40 is designated as the first device 30A.

[0057] The management system 10 stores key information DK, which indicates the owner key KO, in the first device 30A upon registration of the owner key KO. The management system 10 also stores authentication information AT, which authenticates the owner key KO, in the vehicle 20 upon registration of the owner key KO. As a result, the first device 30A becomes the owner device 40. Note that the registration of the owner key KO is assumed to be performed on the first device 30A with the application installed.

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

[0059] Subsequently, vehicle 20 receives the pairing password PAS. After vehicle 20 receives the pairing password PAS, it is set to pairing mode by HMI 22 and waits to receive the password from the first device 30A. Then, vehicle 20 proceeds to step S12.

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

[0061] 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 sends generated data DC to the first device 30A via the secure channel to generate the owner key KO. The generated data DC includes vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. The first device 30A then receives the generated data DC. The first device 30A then proceeds to step S14.

[0062] In step S14, the first device 30A generates owner key information DKO, which indicates the owner key KO. Then, the first device 30A proceeds to step S15. In step S15, the first device 30A stores the owner key information DKO. This makes the first device 30A the owner device 40. Subsequently, the first device 30A transmits the certificate information ST5 related to the owner key KO and the device public key information ST6 indicating the device public key PKD to the vehicle 20.

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

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

[0065] Subsequently, when the first device 30A receives the completion notification M11, the first device 30A performs the process in 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 to the management server 70 requesting an update to the database DB. The first device 30A then sends the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0066] Subsequently, when the management server 70 receives the key track request D12, it performs the processing in step S19. In step S19, the management server 70 performs the registration management of the owner key KO. Specifically, it stores the first device 30A in the data DA of the vehicle 20 in the database DB as the device 30 registered as the owner key KO. With this, the management system 10 completes the series of processing for the owner key KO.

[0067] <Registering a Friend Key> As shown in Figure 6, the management system 10 performs a series of registration processes to register the friend key KF. Of the devices 30 that do not store the friend key information DKF, the device 30 that becomes a friend device 51 through this series of processes is designated as the second device 30B.

[0068] When the owner device 40 performs an operation to request the registration of the friend key KF, the owner device 40 first performs the process in step S21. In step S21, the owner device 40 sends the friend key KF registration request D21 to a relay server (not shown in the figure). After that, the owner device 40 proceeds to step S22.

[0069] In step S22, the owner device 40 obtains invitation information IV1 for sharing the digital key from the relay server. Invitation information IV1 is, for example, a URL link. The URL link contains share information SH1 necessary for sharing the digital key. The owner device 40 then sends the invitation information IV1 to the second device 30B.

[0070] Subsequently, when the second device 30B receives the invitation information IV1, it performs the process in step S23. In step S23, the second device 30B obtains the share information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the share information SH1 from the source of the URL link.

[0071] The share information SH1 includes, for example, share key structure information STS, password information ATP2, effective start information ATP3, expiration information ATP4, and name information ATP5. Note that the effective start information ATP3, expiration information ATP4, and name information ATP5 are set by the owner device 40. After that, the second device 30B proceeds to step S24.

[0072] In step S24, the second device 30B generates unsigned friend key information DKFN using the share information SH1. Unsigned friend key information DKFN is friend key information DKFN that does not have signature information ATP1. Specifically, the second device 30B generates each piece of information contained in the acquired share information SH1 as the pieces of information in the unsigned friend key information DKFN. Subsequently, the second device 30B sends a completion notification M21 indicating that the generated unsigned friend key information DKFN has been uploaded to a URL link, and a signature request D22 requesting a signature, to the owner device 40.

[0073] Subsequently, the owner device 40 receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 obtains the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process in step S25 by being operated.

[0074] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 prompts the HMI 32 to present the acquired unsigned friend key information DKFN and accepts an operation indicating consent to the registration of the friend key KF by the user of the owner device 40. Once the operation is performed, the owner device 40 obtains a signature based on the operation performed. After that, the owner device 40 proceeds to step S26.

[0075] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. This causes the owner device 40 to generate the 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 sends a completion notification M22 to the second device 30B indicating that the upload of the completed friend key information DKF to the URL link is complete.

[0076] Subsequently, the second device 30B receives a completion notification M22. Then, the second device 30B performs the process in 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 the friend device 51. Then, the second device 30B proceeds to step S28.

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

[0078] Subsequently, when the management server 70 receives the key track request D23 for the friend key KF, the management server 70 performs the process in step S29. In step S29, the management server 70 performs registration management for the friend key KF.

[0079] Specifically, the management server 70 verifies that the friend key KF, which is the target of keytrack request D23, is not on the rejection list. The rejection list is a list of share keys KS, including friend keys KF and non-friend keys KN for which a deletion request has already been received. If friend key KF is on the rejection list, the management server 70 sends a notification to the second device 30B that it cannot fulfill keytrack request D23.

[0080] On the other hand, if the friend key KF that received the key track request D23 is not on the rejection list, the management server 70 registers the friend key KF that received the key track request D23 in the database DB. Specifically, the management server 70 stores the second device 30B as device 30 registered as friend device 51 in the vehicle 20 data DA in the database DB. The management server 70 stores the relationship between the second device 30B and the owner device 40 by referring to the acquired friend key information DKF.

[0081] Subsequently, the management server 70 sends the authentication package ATP from 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 sends the device public key information ST6, which indicates 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 is signed by the owner device 40.

[0082] Subsequently, when vehicle 20 receives storage request D24 and authentication package ATP from management server 70, it performs the process in step S30. In step S30, vehicle 20 stores the received authentication package ATP as authentication information AT for authenticating friend key KF.

[0083] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M23 to the second device 30B. Subsequently, when the second device 30B receives the key track completion notification M23, it performs the process in step S31. In the process of step S31, the second device 30B presents information to the HMI 32 indicating that the registration of the friend key KF is complete. For example, the second device 30B presents an image indicating the registration of the friend key KF to the HMI 32. For example, the second device 30B displays an image indicating the registration of the friend key KF to the HMI 32. With this, the management system 10 completes the series of processes for registering the friend key KF.

[0084] <Registering a non-friend key> As shown in Figure 7, the management system 10 performs a series of registration processes to register the non-friendly key KN. Among the devices 30 that do not store the non-friendly key information DKN, the device 30 that becomes a non-friendly device 52 through this series of processes is designated as the third device 30C.

[0085] When an operation is performed in the friend device 51 to request the registration of a non-friend key KN, the friend device 51 first performs the process in step S41. In step S41, the friend device 51 sends the non-friend key KN registration request D31 to a relay server (not shown in the figure). After that, the friend device 51 proceeds to step S42.

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

[0087] Subsequently, when the third device 30C receives the invitation information IV2, it performs the process in step S43. In step S43, the third device 30C obtains the share information SH2 based on the invitation information IV2. Specifically, the second device 30B downloads the share information SH2 from the URL link.

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

[0089] In step S44, the third device 30C generates unsigned non-friend key information DKNN using the share information SH2. Unsigned non-friend key information DKNN is non-friend key information DKNN that does not have signature information ATP1. Specifically, the third device 30C generates each piece of information contained in the acquired share information SH2 as the pieces of information in the unsigned non-friend key information DKNN. Subsequently, the third device 30C sends a completion notification M31 indicating that it has finished uploading the generated unsigned non-friend key information DKNN to a URL link, and a signature request D32 requesting a signature.

[0090] Subsequently, the friend device 51 receives a completion notification M31 and a signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 obtains the unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process in step S45 by being operated.

[0091] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 prompts the HMI 32 to present the acquired unsigned non-friend key information DKNN and accepts an operation indicating consent to the generation of the non-friend key KN by the user of the friend device 51. Once the operation is performed, the friend device 51 obtains a signature based on the fact that the operation has been performed. After that, the friend device 51 proceeds to step S46.

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

[0093] Subsequently, the third device 30C receives a completion notification M32. Then, the third device 30C performs the process in step S47. In step S47, the third device 30C downloads and stores the non-friendly key information DKN. As a result, the third device 30C becomes a non-friendly device 52. Then, the third device 30C proceeds to step S48.

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

[0095] Subsequently, when the management server 70 receives a key track request D33 for a non-friendly key KN, the management server 70 performs the process in step S49. In step S49, the management server 70 performs registration management for the non-friendly key KN.

[0096] Specifically, the management server 70 verifies that the non-friendly key KN, which is the target of keytrack request D33, is not on the rejection list. If the non-friendly key KN is on the rejection list, the management server 70 sends a notification to the third device 30C that it cannot fulfill keytrack request D33.

[0097] On the other hand, if the non-friendly key KN is not on the rejection list, the management server 70 registers the non-friendly key KN that is the target of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the vehicle 20 data DA in the database DB as device 30 registered as a non-friendly 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-friendly key information DKN. Specifically, the management server 70 stores the third device 30C as device 30 having a non-friendly key KN registered by the registration request D31 from the second device 30B.

[0098] Subsequently, the management server 70 sends the authentication package ATP from the non-friendly 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 sends the device public key information ST6, which indicates the device public key PKD of the non-friendly device 52, to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD has been signed by the friendly device 51.

[0099] Subsequently, when vehicle 20 receives the authentication package ATP and the storage request D34, it performs the process in step S50. In step S50, vehicle 20 stores the received authentication package ATP. That is, vehicle 20 stores the authentication package ATP as authentication information AT for authenticating the non-friend key KN.

[0100] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification M33 to the second device 30B. Subsequently, when the second device 30B receives the key track completion notification M33, it performs the process in step S51. In the process of step S51, the third device 30C presents information to the HMI 32 indicating the completion of registration of the non-friendly key KN. For example, the third device 30C displays an image on the HMI 32 indicating the completion of registration of the non-friendly key KN. With this, the management system 10 completes the series of processes for registering the non-friendly key KN.

[0101] <Changes to the range of vehicle 20 functions> The authentication information AT stored in the storage device 28 of the vehicle 20 contains the range of functions of the vehicle 20 that can be performed by the digital key. In other words, the storage device 28 of the vehicle 20 stores the range of functions of the vehicle 20 that can be performed by the digital key.

[0102] The range of functions of the vehicle 20 includes functions that are involved in the operation of the vehicle 20 and functions that are not involved in the operation of the vehicle 20. Functions that are involved in the operation of the vehicle 20 include, for example, power-on control of the vehicle 20, engine start control, and vehicle 20 starting control. Functions that are not involved in the operation of the vehicle 20 include, for example, unlocking and locking control of the vehicle 20's doors, and unlocking and locking control of only the vehicle 20's trunk space.

[0103] For example, if a rental company or a sharing company is the owner of vehicle 20, a usage period UT may be defined, which is the period during which a digital key user uses vehicle 20. Vehicle 20 changes the range of functions that the digital key can perform outside of the usage period UT to a narrower range than the range of functions that the digital key can perform during the usage period UT.

[0104] Vehicle 20 stores the start time UST, which is the time when the usage period UT begins. Vehicle 20 also stores the end time UET, which is the time when the usage period UT ends. Vehicle 20 determines that the usage period UT has ended when the usage end time UET arrives. Vehicle 20 determines that the usage period UT has started when the usage start time UST arrives.

[0105] Before starting to use the vehicle 20, if authentication is performed via short-range communication between the vehicle 20 and the device 30 that stores information about the second digital key DK2, the vehicle 20 performs the process shown in step S60 in Figure 8.

[0106] As shown in Figure 8, in step S60, the vehicle 20 changes the range of functions that the second digital key DK2 can perform to the range of functions that were available before use began. For example, the vehicle 20 changes the range of functions so that only the functions that are not involved in driving the vehicle 20 can be used, out of the functions that are involved in driving the vehicle 20 and the functions that are not involved in driving the vehicle 20. After that, the process proceeds to step S61.

[0107] In step S61, the vehicle 20 determines whether the current time is after the start time UST. If the current time is after the start time UST (step S61: YES), the vehicle 20 proceeds to step S62. If the current time is before the start time UST (step S61: NO), the vehicle 20 repeatedly executes the process in step S61.

[0108] In step S62, the vehicle 20 changes the scope of its functions to the scope of its functions for the usage period UT. For example, the vehicle 20 changes the scope of its functions so that it can use both functions that are involved in the operation of the vehicle 20 and functions that are not involved in the operation of the vehicle 20. After that, the process proceeds to step S63.

[0109] In step S63, the vehicle 20 determines whether the current time is after the end time UET. If the current time is after the end time UET (step S64: YES), the vehicle 20 proceeds to step S64. If the current time is before the end time UET (step S63: NO), the vehicle 20 repeatedly executes the process in step S63.

[0110] In step S64, the vehicle 20 changes the range of its functions to the range of functions that are in a fade-out state. For example, the vehicle 20 changes the range of its functions so that only the functions that are not involved in driving the vehicle 20 are available, out of the functions that are involved in driving the vehicle 20 and the functions that are not involved in driving the vehicle 20. The process then proceeds to step S65.

[0111] The fade-out state is a condition in which the second digital key DK2, whose usage period UT has ended, is deleted when the default condition is met. The default condition is that another digital key is authenticated by vehicle 20.

[0112] In step S65, the vehicle 20 determines whether another digital key has been authenticated by the vehicle 20. For example, if authentication has been performed between the vehicle 20 and the fifth device 30E which stores information about the fifth digital key DK5 (step S65: YES), the vehicle 20 proceeds to step S66. If the other digital key has not been authenticated by the vehicle 20 (step S65: NO), the vehicle 20 repeatedly performs the process in step S65.

[0113] In step S66, the vehicle 20 performs a process to delete the information related to the second digital key DK2, which is in a fade-out state. As a result, the user of the second device 30B, which stores information related to the second digital key DK2, will no longer be able to use the functions of the vehicle 20. After that, the vehicle 20 terminates this series of processes.

[0114] The process of deleting the information related to the second digital key DK2 shown in step S66 is a series of processes from step S70 to step S77 shown in Figure 9. As shown in Figure 9, vehicle 20, which has started the process of deleting information related to the second digital key DK2, performs the process in step S70. In step S70, vehicle 20 generates a deletion request D70 to delete the friend key information DKF that indicates the second digital key DK2. Then, vehicle 20 sends the deletion request D70 to the management server 70.

[0115] Subsequently, when the management server 70 receives the deletion request D70, it performs the process in step S71. In step S71, the management server 70 generates a deletion command D71 to delete the friend key information DKF stored in the second device 30B. The management server 70 then sends the deletion command D71 to the second device 30B.

[0116] Subsequently, when the second device 30B receives the deletion command D71, it performs the process in step S72. In step S72, the second device 30B deletes the friend key information DKF in accordance with the deletion command D71. Then, the second device 30B sends a deletion completion notification M71 to the management server 70, indicating that the deletion in accordance with the deletion command D71 has been completed.

[0117] Subsequently, when the management server 70 receives the completion notification M71, the management server 70 performs the process in step S73. In step S73, the management server 70 stores the history of the deletion of the friend key information DKF on the second device 30B.

[0118] In step S74, the management server 70 generates a deletion command D72 for the authentication information AT. This deletion command D72 for the authentication information AT indicates a command to delete the authentication information AT used to authenticate the second digital key DK2, which is the target of the deletion request D70. The management server 70 then sends the deletion command D72 to the vehicle 20.

[0119] Subsequently, when vehicle 20 receives the deletion command D72, vehicle 20 performs the process in step S75. In step S75, vehicle 20 deletes the authentication information AT used to authenticate the second digital key DK2, which is the target of the deletion request D70, in accordance with the deletion command D72. That is, vehicle 20 deletes the authentication package ATP of the second digital key DK2. After that, vehicle 20 sends a deletion completion notification M72 to the management server 70 indicating that it has completed the deletion of the authentication information AT in accordance with the deletion command D72.

[0120] Subsequently, when the management server 70 receives the completion notification M72, the management server 70 performs the process in step S76. In step S76, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the second digital key DK2, which is the target of deletion in this series of deletion processes in the vehicle 20. After that, the management server 70 proceeds to step S77.

[0121] In step S77, the management server 70 updates the database DB. Specifically, the management server 70 deletes the second device 30B, which has the second digital key DK2 that is the target of deletion in this series of processes, from the vehicle 20 data DA in the database DB.

[0122] <Operation of the First Embodiment> If the range of functions that the second digital key DK2 can perform on the vehicle 20 is narrowed, the use of the vehicle 20 by the user of the second device 30B that stores information about the second digital key DK2 will be restricted.

[0123] <Effects of the First Embodiment> (1-1) Vehicle 20 can restrict the use of vehicle 20 by the user of the second digital key DK2 during periods other than the usage period UT, compared to the usage period UT.

[0124] (1-2) The scope of functions of vehicle 20 includes functions that are involved in driving vehicle 20 and functions that are not involved in driving vehicle 20. Vehicle 20 changes the scope of functions so that, outside of the usage period UT, the user of the second digital key DK2 cannot use the functions that are involved in driving vehicle 20. There is a need for users to use functions that are not involved in driving vehicle 20 even outside of the usage period UT. On the other hand, there is a need to restrict the use of functions that are involved in driving vehicle 20 outside of the usage period UT. Vehicle 20 changes the scope of functions so that, outside of the usage period UT, the functions of vehicle 20 that are involved in driving vehicle 20 cannot be used. Vehicle 20 restricts the driving of vehicle 20 by the user of the second digital key DK2 outside of the usage period UT, and also allows the user of the second digital key DK2 to use functions that are not involved in driving vehicle 20 even outside of the usage period UT.

[0125] (1-3) Vehicle 20 stores the start time UST, which is the time when the usage period UT begins. When the start time UST arrives, it determines that the usage period UT has started. Vehicle 20 can determine that the usage period UT has started without any user operation of the second digital key DK2.

[0126] (1-4) Vehicle 20 stores the usage end time UET, which is the time when the usage period UT ends. When the usage end time UET arrives, it determines that the usage period UT has ended. Vehicle 20 can determine that the usage period UT has ended without any operation by the user of the second digital key DK2.

[0127] (Second Embodiment) The vehicle 20 according to the second embodiment will be described below with reference to Figure 10. The second embodiment will be described mainly in terms of the differences from the first embodiment. In the second embodiment, the vehicle 20 is equipped with an interface that allows the user of the vehicle 20 to operate it. Specifically, the vehicle 20 is equipped with an HMI 22 as the interface. The vehicle 20 determines that the usage period UT has started when an operation to start using the vehicle 20 is performed via the interface. The vehicle 20 determines that the usage period UT has ended when an operation to end the use of the vehicle 20 is performed via the interface. In the following, the differences from the first embodiment will be described mainly, and the same points will be simplified or omitted.

[0128] Before starting to use the vehicle 20, if authentication is performed via short-range communication between the vehicle 20 and the device 30 that stores information about the second digital key DK2, the vehicle 20 performs the process shown in step S80 of Figure 10.

[0129] In step S80, the vehicle 20 changes the range of functions that the second digital key DK2 can perform to the range of functions that were in use before the start of use. Step S80 is the same as step S60 in the first embodiment, so a detailed explanation is omitted. The process then proceeds to step S81.

[0130] In step S81, the vehicle 20 determines whether an operation to start using the vehicle 20 has been performed via the interface. Specifically, the vehicle 20 determines whether an operation to start using the vehicle 20 has been performed via the HMI 22. If the operation to start using the vehicle 20 has been performed (step S81: YES), the vehicle 20 proceeds to step S82. If the operation to start using the vehicle 20 has not been performed (step S81: NO), the vehicle 20 repeatedly executes the process in step S81.

[0131] In step S82, the vehicle 20 changes the scope of its functions to the scope of its functions during the usage period UT. Step S82 is the same as step S62 in the first embodiment, so a detailed explanation is omitted. After that, the vehicle 20 proceeds to step S83.

[0132] In step S83, the vehicle 20 determines whether an operation to terminate the use of the vehicle 20 has been performed via the interface. Specifically, the vehicle 20 determines whether an operation to terminate the use of the vehicle 20 has been performed via the HMI 22. If an operation to terminate the use of the vehicle 20 has been performed (step S83: YES), the vehicle 20 proceeds to step S84. If an operation to terminate the use of the vehicle 20 has not been performed (step S84: NO), the vehicle 20 repeatedly executes the process in step S83.

[0133] In step S84, the vehicle 20 changes the range of its functions to the range of functions in the fade-out state. Step S84 is the same as step S64 in the first embodiment, so a detailed explanation is omitted. After that, the vehicle 20 proceeds to step S85.

[0134] In step S85, the vehicle 20 determines whether another digital key has been authenticated by the vehicle 20. For example, if authentication has been performed between the vehicle 20 and the fifth device 30E which stores information about the fifth digital key DK5 (step S85: YES), the vehicle 20 proceeds to step S86. If the other digital key has not been authenticated by the vehicle 20 (step S85: NO), the vehicle 20 repeatedly performs the process in step S85.

[0135] In step S86, the vehicle 20 performs a process to delete information related to the second digital key DK2, which is in a fade-out state. Step S86 is identical to step S66 in the first embodiment, so a detailed explanation is omitted. After that, the vehicle 20 terminates this series of processes.

[0136] <Operation of the second embodiment> Vehicle 20 is equipped with an HMI 22 as an interface that can be operated by the user. Vehicle 20 determines that the usage period UT has started when an operation to start using Vehicle 20 is performed via the HMI 22. Vehicle 20 determines that the usage period UT has ended when an operation to end using Vehicle 20 is performed via the HMI 22.

[0137] <Effects of the second embodiment> In the second embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following further effects are achieved.

[0138] (2-1) The user can initiate the usage period UT of vehicle 20. (2-2) The user can terminate the usage period (UT) of vehicle 20. (Third embodiment) The vehicle 20 according to the third embodiment will be described below with reference to Figure 11. The third embodiment will be described mainly in terms of the differences from the first embodiment. In the third embodiment, the vehicle 20 determines that the usage period UT has started when it receives a usage start notification USN output from the device 30. The vehicle 20 determines that the usage period UT has ended when it receives a usage end notification UEN output from the device 30.

[0139] Vehicle 20 is equipped with a communication device that enables communication with a device 30 that stores information about the digital key. Specifically, vehicle 20 is equipped with a BLE module 23, a UWB module 24, and an NFC module 25 as communication devices for short-range communication. Vehicle 20 receives a usage start notification USN and a usage end notification UEN from device 30 by at least one of the BLE communication, UWB communication, and NFC communication. The communication device used by vehicle 20 to receive the usage start notification USN from device 30 and the communication device used by vehicle 20 to receive the usage end notification UEN from device 30 may be different communication devices. In the following, the differences from the first embodiment will be described in detail, and the same points will be simplified or omitted from the explanation.

[0140] As shown in Figure 11, in step S90, the second device 30B, which stores information about the second digital key DK2, generates an authentication notification M90 for authentication via short-range communication. Subsequently, the second device 30B outputs the authentication notification M90 to the vehicle 20 using short-range communication.

[0141] In step S91, the vehicle 20 authenticates the received authentication notification M90. Subsequently, the vehicle 20 changes the range of functions that the second digital key DK2 can perform to the range of functions that existed before use began. Step S91 is the same as step S60 in the first embodiment, so a detailed explanation is omitted.

[0142] In step S92, the second device 30B generates a service activation notification USN. For example, the second device 30B generates a service activation notification USN when the user performs an operation to generate a service activation notification USN via the HMI 32 provided by the second device 30B. For example, the second device 30B may be configured to generate a service activation notification USN when the service activation time UST arrives. Subsequently, the second device 30B outputs the service activation notification USN to the vehicle 20 using short-range communication.

[0143] When vehicle 20 receives the usage start notification USN, it performs the process in step S93. In step S93, vehicle 20 determines that the usage period UT has started. That is, when vehicle 20 receives the usage start notification USN output from device 30, it determines that the usage period UT has started. In step S93, vehicle 20 changes the scope of its functions to the scope of the functions of the usage period UT. Step S93 is the same as step S62 in the first embodiment, so a detailed explanation is omitted.

[0144] In step S94, the second device 30B generates a usage termination notification UEN. For example, the second device 30B generates a usage termination notification UEN when the user performs an operation to generate a usage termination notification UEN via the HMI 32 provided in the second device 30B. For example, the second device 30B may be configured to generate a usage termination notification UEN when the usage termination time UET is reached. Subsequently, the second device 30B outputs the usage termination notification UEN to the vehicle 20 using short-range communication.

[0145] When vehicle 20 receives the usage termination notification UEN, it performs the process in step S95. In step S95, vehicle 20 determines that the usage period UT has ended. That is, when vehicle 20 receives the usage termination notification UEN output from device 30, it determines that the usage period UT has ended. In step S95, vehicle 20 changes the range of its functions to the range of functions in the fade-out state. Step S95 is the same as step S64 in the first embodiment, so a detailed explanation is omitted.

[0146] The fifth device 30E is a device 30 that stores information about the fifth digital key DK5. The fifth device 30E is a different device 30 from the second device 30B. In step S96, the fifth device 30E generates an authentication notice M91 for authentication by short-range communication. The fifth device 30E then outputs the authentication notice M91 to the vehicle 20 using short-range communication.

[0147] When the vehicle 20 receives the authentication notification M91 from the fifth device 30E, it performs the process in step S97. In step S97, the vehicle 20 performs the process of deleting the information related to the second digital key DK2, which is in a fade-out state. Step S97 is the same as step S66 in the first embodiment, so a detailed explanation is omitted. After that, the vehicle 20 proceeds to step S98.

[0148] In step S98, the vehicle 20 authenticates the received authentication notification M91. Subsequently, the vehicle 20 changes the range of functions that the fifth digital key DK5 can perform to the range of functions that existed before use began. Step S98 is identical to step S60 in the first embodiment, so a detailed explanation is omitted.

[0149] <Operation of the Third Embodiment> Vehicle 20 is equipped with a BLE module 23, a UWB module 24, and an NFC module 25 as communication devices that enable communication with the second device 30B. When Vehicle 20 receives a usage start notification USN output from the second device 30B, it determines that the usage period UT has started. When Vehicle 20 receives a usage end notification UEN output from the second device 30B, it determines that the usage period UT has ended.

[0150] <Effects of the Third Embodiment> In the third embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following further effects are achieved.

[0151] (3-1) The vehicle 20 can determine that the usage period UT has started based on the usage start notification USN output from the second device 30B. (3-2) The vehicle 20 can determine that the usage period UT has ended based on the usage termination notification UEN output from the second device 30B.

[0152] (Fourth embodiment) The vehicle 20 according to the fourth embodiment will be described below with reference to Figure 12. The fourth embodiment will be described mainly in terms of the differences from the third embodiment. In the fourth embodiment, the vehicle 20 determines that the usage period UT has started when it receives a usage start notification USN output from the management server 70. The vehicle 20 determines that the usage period UT has ended when it receives a usage end notification UEN output from the management server 70.

[0153] Vehicle 20 is equipped with a communication device that enables communication with the management server 70. Specifically, vehicle 20 is equipped with a communication module 21 as the communication device. Vehicle 20 receives a usage start notification USN and a usage end notification UEN from the management server 70 via the communication module 21. In the following, the differences from the first embodiment will be described in detail, and the same points will be simplified or omitted.

[0154] As shown in Figure 12, in step S100, the second device 30B, which stores information about the second digital key DK2, generates an authentication notification M100 for authentication via short-range communication. Subsequently, the second device 30B outputs the authentication notification M100 to the vehicle 20 using short-range communication.

[0155] In step S101, the vehicle 20 authenticates the received authentication notification M100. Subsequently, the vehicle 20 changes the range of functions that the second digital key DK2 can perform to the range of functions that existed before use began. Step S101 is the same as step S60 in the first embodiment, so a detailed explanation is omitted. After that, the vehicle 20 proceeds to step S102.

[0156] In step S102, the vehicle 20 generates an authentication notification M102 indicating that it has authenticated the second device 30B. Having generated the authentication notification M102, the vehicle 20 sends the generated authentication notification M102 to the management server 70 via the communication module 21.

[0157] Upon receiving the authentication notification M102, the management server 70 performs the process in step S103. In step S103, the management server 70 generates a usage start notification USN. Subsequently, the management server 70 uses the communication module 73 to output the usage start notification USN to the vehicle 20.

[0158] When vehicle 20 receives the usage start notification USN, it performs the processing in step S104. In step S104, vehicle 20 determines that the usage period UT has started. That is, when vehicle 20 receives the usage start notification USN output from the management server 70, it determines that the usage period UT has started. In step S104, vehicle 20 changes the scope of its functions to the scope of the functions of the usage period UT. Step S104 is the same as step S62 in the first embodiment, so a detailed explanation is omitted.

[0159] In step S105, the management server 70 generates a usage termination notification UEN. For example, the management server 70 generates a usage termination notification UEN when the usage termination time UET arrives. The management server 70 then uses the communication module 73 to output the usage termination notification UEN to the vehicle 20.

[0160] When vehicle 20 receives the usage termination notification UEN, it performs the process in step S106. In step S106, vehicle 20 determines that the usage period UT has ended. That is, when vehicle 20 receives the usage termination notification UEN output from the management server 70, it determines that the usage period UT has ended. In step S106, vehicle 20 changes the scope of its functions to the scope of functions in a fade-out state. Step S106 is the same as step S64 in the first embodiment, so a detailed explanation is omitted.

[0161] The subsequent processes are the same as in the third embodiment, so a detailed explanation is omitted. Specifically, step S107 in the fourth embodiment is the same as step S96 in the third embodiment, so a detailed explanation is omitted. Step S108 in the fourth embodiment is the same as step S97 in the third embodiment, so a detailed explanation is omitted. Step S109 in the fourth embodiment is the same as step S98 in the third embodiment, so a detailed explanation is omitted.

[0162] <Operation of the 4th Embodiment> Vehicle 20 is equipped with a communication module 21 as a communication device that enables communication with the management server 70. When vehicle 20 receives a usage start notification USN output from the management server 70, it determines that the usage period UT has started. When vehicle 20 receives a usage end notification UEN output from the management server 70, it determines that the usage period UT has ended.

[0163] <Effects of the 4th Embodiment> In the fourth embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following further effects are achieved.

[0164] (4-1) Vehicle 20 can determine that the usage period UT has started based on the usage start notification USN output from the management server 70. (4-2) Vehicle 20 can determine that the usage period UT has ended based on the usage termination notification UEN output from the management server 70.

[0165] (Fifth embodiment) The vehicle 20 according to the fifth embodiment will be described below with reference to Figure 13. The fifth embodiment will be described primarily in terms of the differences from the first embodiment. In the following, the differences from the first embodiment will be described in detail, and the same points will be simplified or omitted.

[0166] In the fifth embodiment, the vehicle 20 obtains its current location. For example, the vehicle 20 may be configured to obtain its location from a device 30 authenticated by the vehicle 20. Specifically, the device 30 authenticated by the vehicle 20 obtains its own location information. The vehicle 20 obtains the location information obtained by the device 30 via short-range communication. The vehicle 20 considers the location of the device 30 to be the location of the vehicle 20. The vehicle 20 may also obtain its location from the management server 70 via the communication module 21.

[0167] For example, vehicle 20 may be configured to obtain its position from a location information acquisition system installed on vehicle 20. Examples of location information acquisition systems include GNSS (Global Navigation Satellite System), RTK (Real Time Kinematic), and LiDAR (Light Detection and Ranging). Vehicle 20 may also be configured to obtain its position from images of its surroundings captured by an external camera mounted on the vehicle 20.

[0168] During periods other than the usage period UT, if the vehicle 20 is located within a predetermined specific area SP, a portion of the vehicle 20's functions will be made available. During periods other than the usage period UT, if the vehicle 20 is located outside the specific area SP, the vehicle 20's functions will not be made available during those periods.

[0169] <Operation of the Fifth Embodiment> As shown in Figure 13, the designated area SP is the predetermined first parking lot PA1. The second parking lot PA2 is located outside the designated area SP.

[0170] If vehicle 20 is located in the second parking lot PA2 during a period other than the usage period UT of vehicle 20, vehicle 20 will not allow the user of the digital key authenticated to vehicle 20 to use vehicle 20's functions.

[0171] If vehicle 20 is located in parking lot PA1 outside of the vehicle usage period UT, vehicle 20 will make some of its functions available to the user of the digital key authenticated to vehicle 20. For example, vehicle 20 will allow the user of the digital key authenticated to vehicle 20 to use functions that do not involve driving vehicle 20.

[0172] Even outside of the designated usage period (UT), there is a need among users of vehicle 20 for the convenience of unlocking the vehicle's doors and loading / unloading goods in designated areas (SP), such as within a predetermined parking lot. On the other hand, there is a need among owners of vehicle 20 to prevent unlimited use of vehicle 20 outside of the designated usage period (UT).

[0173] <Effects of the Fifth Embodiment> In the fifth embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following further effects are achieved.

[0174] (5-1) Vehicle 20 can satisfy both the needs of the user of vehicle 20 and the needs of the owner of vehicle 20. <Example of modification of the fifth embodiment> The fifth embodiment described above can be implemented with the following modifications.

[0175] • Designated area SPs are not limited to Parking Lot 1 (PA1). Designated area SPs can be set in any area. <Example of changes> The following are some elements that can be modified in common with each of the above embodiments. The following examples of modifications can be combined with each other to the extent that they do not contradict each other technically.

[0176] <Changes to the scope of functionality> • Vehicle 20 may have its range of functions modified so that, outside of the usage period UT, both functions related to the operation of vehicle 20 and functions not related to the operation of vehicle 20 become unavailable.

[0177] The range of functions of the vehicle 20 before the start of the usage period UT, the range of functions of the vehicle 20 during the usage period UT, and the range of functions of the vehicle 20 after the end of the usage period UT may each be set to different ranges of functions.

[0178] <Usage period UT> The determination of whether the usage period UT has started and the determination of whether the usage period UT has ended in each embodiment can be combined as appropriate. For example, the vehicle 20 may determine that the usage period UT has started when the usage start time UST arrives, and the vehicle 20 may determine that the usage period UT has ended when an operation to terminate the use of the vehicle 20 is performed via the HMI 22. For example, the vehicle 20 may determine that the usage period UT has started when it receives the usage start notification USN output from the second device 30B, and determine that the usage period UT has ended when the usage end time UET arrives.

[0179] Vehicle 20 may store multiple conditions for determining when the usage period UT has started. Vehicle 20 may determine that the usage period UT has started when at least one of the multiple conditions for determining when the usage period UT has started is met. Vehicle 20 may determine that the usage period UT has started when all of the multiple conditions for determining when the usage period UT has started are met. Vehicle 20 may determine that the usage period UT has started when more than half of the multiple conditions for determining when the usage period UT has started are met.

[0180] Vehicle 20 may store multiple conditions for determining that the usage period UT has ended. Vehicle 20 may determine that the usage period UT has ended when at least one of the multiple conditions for determining that the usage period UT has ended is met. Vehicle 20 may determine that the usage period UT has ended when all of the multiple conditions for determining that the usage period UT has ended are met. Vehicle 20 may determine that the usage period UT has ended when more than half of the multiple conditions for determining that the usage period UT has ended are met.

[0181] <Authentication Notice M91> The other device 30 that sends the authentication notification M91 is not limited to the fifth device 30E. The other device 30 that sends the authentication notification M91 may be a friend device 51 other than the fifth device 30E. The other device 30 that sends the authentication notification M91 may be a non-friend device 52.

[0182] <Management System 10> Vehicle 20 does not necessarily have to have some of the BLE module 23, UWB module 24, and NFC module 25. Vehicle 20 can perform short-range communication with device 30 if it has at least one of these modules. Furthermore, vehicle 20 is not limited to these modules, and may have any module that can perform short-range communication with device 30.

[0183] A different ECU installed in a different vehicle 20 than the vehicle management device 26 may authenticate the digital key. • The matters concerning digital keys in each of the above embodiments do not have to comply with CCC.

[0184] 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 a vehicle 20. 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). Alternatively, the vehicle management device 26 may be configured as a circuit including one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs), or a combination thereof, that execute at least some of the various processes. 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. Memory, i.e., computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer. The same applies to device 30 and management server 70.

[0185] Device 30 is not limited to a smartphone. It may also be a smartwatch. Device 30 may also be a predetermined server. In this case, the predetermined server may contain Device 30. For example, if a rental company and a sharing company are the owners of the vehicle 20, the owner device 40 may be contained in the predetermined server. Also, for example, the friend device 51 may be contained in the predetermined server.

[0186] In each of the embodiments described above, the digital keys have a hierarchy in the order of owner key KO, friend key KF, and non-friend key KN, with higher levels of authority assigned to each key. However, the digital keys do not necessarily have to be configured so that higher levels of authority assign to each key. For example, the same level of authority may be assigned to all three levels: owner key KO, friend key KF, and non-friend key KN.

[0187] The share device 50 has the function of receiving the share key KS, as in the embodiment described above. A device 30 that has the function of receiving a digital key, like the share device 50, is sometimes called a receiver device.

[0188] The device server 60 does not need to be provided for each type of device 30. It is sufficient that multiple devices 30 and the management server 70 can communicate wirelessly. The device server 60 may be omitted. It is sufficient that multiple devices 30 and the management server 70 can communicate wirelessly directly.

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

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

[0191] Deleting a digital key means changing the state from one where it is usable to one where it is unusable. In each of the above embodiments, if either the authentication information AT or the key information DK for a single digital key is deleted, that digital key becomes unusable.

[0192] Therefore, deleting a digital key means deleting at least one of the following: authentication information AT, which is information about the digital key stored in the vehicle management device 26, and key information DK, which is information about the digital key stored in the device 30. If both authentication information AT and key information DK are to be deleted, the digital key will be deleted at the time one of them is deleted first.

[0193] <Information about various types of information> The information regarding the digital key stored by the vehicle management device 26 is not limited to authentication information AT, but may be any information regarding the digital key. For example, the information regarding the digital key may be information that identifies the digital key.

[0194] The information about the digital key stored by device 30 is not limited to key information DK, but can be any information about the digital key. For example, the information about the digital key may be information that identifies the digital key.

[0195] The information regarding the digital key stored by the vehicle management device 26 may be different from or the same as the information regarding the digital key stored by the device 30, as in the above embodiment.

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

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

[0198] The database DB may include information indicating the type of device 30. The type of device 30 is information indicating one of the following, for example, a smartphone, a smartwatch, and a predetermined server as in the modified example above.

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

[0200] In a database (DB), privileges are not uniformly defined according to the type of digital key, but may be set for each digital key. Furthermore, privileges may not be defined at all in a database (DB).

[0201] The series of processes for registering the owner key KO is not limited to the examples of the embodiments described above. For example, even if pairing is not performed by the process in step S12, the owner device 40 may store the owner key information DKO by having the vehicle 20 and the first device 30A send and receive information such as generated data DC via the management server 70. The series of processes for registering the owner key KO may be modified as appropriate to match the structure of the information contained in the owner key information DKO and the structure of the information contained in the authentication information AT.

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

[0203] The series of processes for registering a non-friend key KN is not limited to the examples of the embodiments described above. The order of the processes may differ from the series of processes for registering a friend key KF. The series of processes for registering a non-friend key KN may be modified as appropriate to match 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.

[0204] The types of digital keys do not necessarily include non-friend keys (KN). In other words, in the management system 10, the share key KS may consist only of friend keys (KF). In this case, the target digital key may be an owner key (KO), and the digital key registered based on the target digital key may be a friend key (KF).

[0205] Non-friend device 52 may send a request to register for a new non-friend key KN. In other words, share device 50 may send a request to register for a new non-friend key KN, regardless of whether it is friend device 51 or non-friend device 52.

[0206] <Note> The technical concepts that can be understood from the above embodiments and modified examples are described below. [Note 1] A vehicle in which a device that stores information relating to a digital key is registered as the digital key, comprising a storage device that stores the range of functions of the vehicle that the digital key can perform, and a processing circuit, wherein the processing circuit changes the range of functions of the vehicle that the digital key can perform during periods other than the usage period, which is the period during which the user of the digital key uses the vehicle, to a range narrower than the range of functions of the vehicle that the digital key can perform during the usage period.

[0207] [Note 2] A vehicle as described in Note 1 that stores the end time of use, which is the time when the usage period ends, and determines that the usage period has ended when the end time of use arrives. [Note 3] A vehicle according to Note 1 or Note 2, which is equipped with an interface that allows the user to perform operations, and which determines that the usage period has ended when an operation to terminate the use of the vehicle is performed via the interface.

[0208] [Note 4] A vehicle as described in any one of Notes 1 to 3, which is equipped with a communication device that is capable of communicating with the device, and which determines that the usage period has ended when it receives a usage termination notice output from the device.

[0209] [Note 5] A vehicle as described in any one of Notes 1 to 4, which is equipped with a communication device that is able to communicate with a management server that manages the digital key, and which determines that the usage period has ended when it receives a usage termination notice output from the management server.

[0210] [Note 6] A vehicle described in any one of Notes 1 to 5 that stores the start time of use, which is the time when the usage period begins, and determines that the usage period has begun when the start time of use arrives.

[0211] [Note 7] A vehicle according to any one of Notes 1 to 6, which is equipped with an interface that allows the user to operate the vehicle, and which determines that the usage period has started when an operation to start using the vehicle is performed via the interface.

[0212] [Note 8] A vehicle as described in any one of Notes 1 to 7, which is equipped with a communication device that is capable of communicating with the device, and which determines that the usage period has started when it receives a usage start notification output from the device.

[0213] [Note 9] A vehicle as described in any one of Notes 1 to 8, which is equipped with a communication device that is able to communicate with a management server that manages the digital key, and which determines that the usage period has started when it receives a usage start notification output from the management server.

[0214] [Note 10] The scope of the functions includes functions that are involved in driving the vehicle and functions that are not involved in driving the vehicle, and the processing circuit modifies the scope of the functions of the vehicle such that the user cannot use the functions that are involved in driving the vehicle during periods other than the usage period, as described in any one of Notes 1 to 9.

[0215] [Note 11] A vehicle described in any one of Notes 1 to 10, which is capable of obtaining the current location of the vehicle, and which, during periods other than the usage period, allows the use of a portion of the scope of the function if the location is within a predetermined specific area, and does not allow the use of the function during periods other than the usage period if the location is outside the specific area.

[0216] [Note 12] The aforementioned specific area is a designated parking area for vehicles as described in Note 11. [Explanation of symbols]

[0217] 20... Vehicles 27… Execution device 28…Storage device 30…Device 70... Management Server SP...Specific area UT…Usage period USN…Usage start notification UST…Usage start time UEN... Service termination notice UET…End time

Claims

1. A vehicle in which a device that stores information about a digital key is registered as the digital key, A storage device that stores the range of vehicle functions that the digital key can perform, A processing circuit is provided, The processing circuit modifies the range of vehicle functions that the digital key can perform during periods other than the usage period, which is the period during which the user of the digital key uses the vehicle, to a narrower range than the range of vehicle functions that the digital key can perform during the usage period. vehicle.

2. The system stores the end time of use, which is the time when the aforementioned usage period ends. When the aforementioned usage end time arrives, it is determined that the aforementioned usage period has ended. The vehicle according to claim 1.

3. It is equipped with an interface that allows the aforementioned user to perform operations, When an operation to terminate the use of the vehicle is performed via the interface, it is determined that the usage period has ended. The vehicle according to claim 1.

4. The device includes a communication device that is capable of communicating with the aforementioned device, When a usage termination notice is received from the aforementioned device, it is determined that the usage period has ended. The vehicle according to claim 1.

5. The system includes a communication device that is capable of communicating with a management server that manages the aforementioned digital keys, When a usage termination notice is received from the management server, it is determined that the usage period has ended. The vehicle according to claim 1.

6. The system stores the start time, which is the time when the aforementioned usage period begins. When the aforementioned start time for use arrives, it is determined that the aforementioned period of use has begun. The vehicle according to claim 1.

7. It is equipped with an interface that allows the aforementioned user to perform operations, The usage period is determined to have started when an operation to initiate use of the vehicle is performed via the interface. The vehicle according to claim 1.

8. The device includes a communication device that is capable of communicating with the aforementioned device, When a notification of commencement of use is received from the aforementioned device, it is determined that the usage period has commenced. The vehicle according to claim 1.

9. The system includes a communication device that is capable of communicating with a management server that manages the aforementioned digital keys, When a notification of commencement of use is received from the management server, it is determined that the usage period has commenced. The vehicle according to claim 1.

10. The scope of the aforementioned functions includes functions that are involved in driving the vehicle and functions that are not involved in driving the vehicle. The processing circuit modifies the range of the vehicle's functions so that the user cannot use the vehicle's driving functions during periods other than the usage period. The vehicle according to claim 1.

11. The current position of the aforementioned vehicle can be obtained, During periods other than the aforementioned usage period, If the aforementioned location is within a predetermined specific area, a portion of the scope of the aforementioned functions will be made available, If the location is outside the specified area, the function will not be made available during periods other than the usage period. The vehicle according to claim 1.

12. The aforementioned specific area is a predetermined parking area. The vehicle according to claim 11.

Images