vehicle

Abstract

The system provides vehicles that prevent the vehicle from becoming unusable before reaching the destination by deleting the shared key while the vehicle is in use. [Solution] A vehicle 20A, on which a share key, which is a digital key for the vehicle, is registered, constitutes a digital key management system. If the execution device of vehicle 20A determines that the termination process was performed with vehicle 20A stopped at the return point SD (S213; YES), it starts a first deletion process that begins a normal fade-out period in which the first share key is deleted when a digital key other than the first share key is authenticated for vehicle 20A. If the execution device does not determine that the termination process was performed with vehicle 20A stopped at the return point SD (S211; NO, S216; YES), it executes a second deletion process that begins a restricted fade-out period in which the first share key is not deleted even if a digital key other than the first share key is authenticated for vehicle 20A.

Description

[[Technical Field]]

[0001] The present invention relates to a vehicle. [[Background Art]]

[0002] Patent Document 1 discloses a digital key management system. The management system comprises a vehicle, a plurality of devices, and a management server. The digital key for the vehicle is registered in the device by storing information related to the digital key in the vehicle and the device. The management server is capable of communicating with the devices and the vehicle, and manages registration of digital keys. Digital keys include an owner key and shared keys. The vehicle is unlocked, locked, and started by a digital key registered in a device. [[Prior Art Documents]] [[Patent Documents]]

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

[0004] In the management system described above, a plurality of shared keys can be collectively registered from the owner key for the same vehicle. On the other hand, when use of a vehicle by a shared key is terminated, or when a shared key is registered by mistake, it is desirable that the owner key can delete the relevant shared key. However, if shared keys can always be deleted, a user holding a shared key may become unable to use the vehicle during use due to deletion of the shared key. [[Means for Solving the Problem]]

[0005] A vehicle designed to solve the above problems constitutes a digital key management system. The digital keys are registered in this vehicle. The digital key management system manages the registration and deletion of the owner key, which is the digital key of the vehicle and is registered to the vehicle only once, and the share key, which is the digital key that can be registered to the vehicle multiple times.

[0006] This vehicle is equipped with an execution device. This vehicle is equipped with a storage device that stores information about the digital keys registered in the vehicle. This vehicle is equipped with a management server that manages the registration and deletion of the digital keys and a communication device that can communicate with the device that stores information about the digital keys.

[0007] The execution device of this vehicle shall, if a request to delete a share key for which an expiration period has been set for the use of the vehicle using the share key is made based on the expiration of the expiration period of the share key, provide a first grace period. The first grace period is a period during which the execution of the deletion of the share key is postponed.

[0008] The execution device of the vehicle determines, based on the location information of the vehicle, whether the termination process that permits the start of the share key deletion process was performed while the vehicle was stopped at the termination point, which is a predetermined point where the use of the vehicle ends.

[0009] The execution device of this vehicle determines that the termination process was performed while the vehicle was stopped at the termination point, and then starts the deletion process for the share key. If the execution device of this vehicle does not determine that the termination process was performed while the vehicle was stopped at the termination point, it will not delete the share key for which deletion has been postponed, even if a digital key other than the share key is authenticated to the vehicle. [Effects of the Invention]

[0010] According to the vehicle described above, deleting the shared key while the vehicle is in use can prevent the vehicle from becoming unusable before reaching the destination. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a schematic diagram showing a digital key management system according to one embodiment. [Figure 2] Figure 2 is a schematic diagram showing the vehicle configuration in the digital key management system shown in Figure 1. [Figure 3] Figure 3 is a schematic diagram showing the configuration of the owner device, which is a portable information terminal, in the digital key management system shown in Figure 1. [Figure 4] Figure 4 is a schematic diagram showing the configuration of the owner device, which is a virtual machine built on the server, in the digital key management system shown in Figure 1. [Figure 5] Figure 5 is a schematic diagram showing the configuration of the friend device in the digital key management system shown in Figure 1. [Figure 6] Figure 6 is a schematic diagram showing the configuration of non-friendly devices in the digital key management system of Figure 1. [Figure 7] Figure 7 is a schematic diagram showing the configuration of the management server in the digital key management system shown in Figure 1. [Figure 8] Figure 8 is a schematic diagram showing the owner key information in the digital key management system shown in Figure 1. [Figure 9] Figure 9 is a schematic diagram showing the share key information in the digital key management system shown in Figure 1. [Figure 10] Figure 10 is a schematic diagram showing the data in the management server database of Figure 7. [Figure 11] Figure 11 is a sequence diagram of the owner key registration process in the digital key management system shown in Figure 1, when the owner device is a personal digital assistant (PDA). [Figure 12]FIG. 12 is a sequence diagram illustrating owner key registration processing when the owner device is a virtual machine in the digital key management system of FIG. 1. [Figure 13] FIG. 13 is a sequence diagram illustrating friend key registration processing in the digital key management system of FIG. 1. [Figure 14] FIG. 14 is a sequence diagram illustrating non-friend key registration processing in the digital key management system of FIG. 1. [Figure 15] FIG. 15 is a flowchart illustrating processing when the vehicle of FIG. 1 selects a shared key deletion process. [Figure 16] FIG. 16 is a sequence diagram illustrating processing when a first deletion request is made in the digital key management system of FIG. 1. [Figure 17] FIG. 17 is a sequence diagram illustrating processing when a second deletion request is made in the digital key management system of FIG. 1. [Figure 18] FIG. 18 is a sequence diagram illustrating processing when a third deletion request is made in the digital key management system of FIG. 1. [Figure 19] FIG. 19 is a schematic diagram illustrating the positional relationship among the plurality of vehicles shown in FIG. 1, and return points and returnable points. [Figure 20] FIG. 20 is an enlarged schematic diagram of the vicinity of the return point shown in FIG. 19. [Figure 21] FIG. 21 is a flowchart illustrating processing when a vehicle executes the first deletion process shown in FIG. 15. [Figure 22] FIG. 22 is a flowchart illustrating processing when a vehicle executes the second deletion process shown in FIG. 15. [Figure 23] FIG. 23 is a flowchart illustrating processing when a vehicle executes the third deletion process shown in FIG. 15. [Figure 24] FIG. 24 is a sequence diagram illustrating processing from the start of processing to before authentication of a second shared key, in processing when a digital key management system deletes a first shared key. [Figure 25] Figure 25 is a sequence diagram showing the process from the authentication of the second share key to the time before the key deletion request is sent when the digital key management system deletes the first share key. [Figure 26] Figure 26 is a sequence diagram showing the process from sending a key deletion request to the end of the process when a digital key management system deletes the first share key. [Figure 27] Figure 27 is a flowchart showing the process when a vehicle performs an emergency deletion operation during the restriction fade-out period shown in Figure 22. [Figure 28] Figure 28 is a schematic diagram showing the movement of vehicles whose share keys are to be deleted in the emergency deletion process shown in Figure 27. [Modes for carrying out the invention]

[0012] Below, a management system 10, which is one embodiment of a management system including vehicles, will be described with reference to Figures 1 to 28. Regarding digital keys, there is a standard set by the Car Connectivity Consortium (CCC). The digital key aspects of this embodiment comply with the CCC standards.

[0013] <Overview of Management System 10> As shown in Figure 1, the management system 10 comprises multiple vehicles 20, multiple devices 30, a device server 60, a management server 70, and a server 80. The multiple vehicles 20, multiple devices 30, device server 60, management server 70, and server 80 can communicate with each other via a network 90. ​​The network 90 is a wireless communication network.

[0014] As shown in Figure 2, the vehicle 20 includes a wireless communication device 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.

[0015] The wireless communication device 21 communicates wirelessly with the management server 70 via the network 90. ​​The HMI 22 includes an input device that accepts user input for the vehicle 20, and a presentation device that presents information to the user using images and sound, etc. The presentation device is, for example, a monitor and a speaker.

[0016] 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. The BLE module 23, UWB module 24, and NFC module 25 are all proximity communication devices. The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The storage device 28 stores a vehicle program PV, authentication information AT, deletion program PE, device deletion information DE, and vehicle history information HC.

[0017] The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store and delete authentication information AT. Authentication information AT is information related to the digital key. More specifically, authentication information AT is information for authenticating the 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. The execution device 27 executes the processes related to storing and deleting authentication information AT by executing the vehicle program PV.

[0018] The deletion program PE causes the execution device 27 to manage the initiation of the digital key deletion by being executed by the execution device 27. Based on the device deletion information DE and the vehicle history information HC, the deletion program PE causes the execution device 27 to determine whether or not to delete the authentication information AT stored in the vehicle 20. The device deletion information DE is information regarding the conditions for deleting the digital key. The device deletion information DE includes, for example, a deletion flag EF that indicates whether or not to allow the deletion of the authentication information AT for each digital key. The vehicle history information HC is information regarding the usage status of the vehicle 20 while the vehicle 20 is being used with the digital key. The vehicle history information HC includes, for example, information regarding the location information GL of the vehicle 20 at each time point.

[0019] Vehicle 20 is equipped with a locking mechanism 29A, an engine 29B, and a positioning device 29C. The locking mechanism 29A locks and unlocks the doors of vehicle 20. The engine 29B is an internal combustion engine. Vehicle 20 may also be equipped with a hybrid mechanism instead of the engine 29B. The positioning device 29C obtains the position information GL of vehicle 20 by communicating with artificial satellites. The positioning device 29C obtains the position information GL of vehicle 20 using, for example, GPS. GPS stands for Global Positioning System.

[0020] As shown in Figure 1, the multiple devices 30 include an owner device 40 and multiple shared devices 50. The multiple shared devices 50 include friend devices 51 and non-friend devices 52. Device 30 includes not only mobile information terminals such as smartphones, but also virtual machines built on server 80.

[0021] The owner device 40 can be either a mobile device 40M or a virtual device 40V. The mobile device 40M is the owner device 40, which is a personal digital assistant (PDI). The virtual device 40V is the owner device 40, which is a virtual machine.

[0022] As shown in Figure 3, the mobile device 40M includes a wireless communication device 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 wireless communication device 31 performs wireless communication via the network 90. ​​The HMI 32 includes an input device that receives user input for the mobile device 40M, and a presentation device that presents information to the user through images and sound, etc. The presentation device is, for example, a monitor and a speaker.

[0023] The BLE module 33 communicates with the vehicle 20 via BLE communication. The UWB module 34 communicates with the vehicle 20 via UWB communication. The NFC module 35 communicates with the vehicle 20 via NFC communication. The BLE module 33, UWB module 34, and NFC module 35 are all proximity communication devices.

[0024] The storage device 37 stores the device program PD and the key information DK. The device program PD is executed by the execution device 36, which in turn causes the execution device 36 to store and delete the key information DK. The key information DK is information that indicates a digital key.

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

[0026] Key information DK is information that indicates a digital key. 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. The owner device 40 belongs to the owner of the vehicle 20.

[0027] As shown in Figure 4, the virtual device 40V comprises a wireless communication device 31, an execution device 36, and a storage device 37. The wireless communication device 31, execution device 36, and storage device 37 of the virtual device 40V can be a virtual device that uses a portion of the area of ​​the wireless communication device 31, execution device 36, and storage device 37 of the server 80. The storage device 37 stores a device program PD, key information DK, and a share key list LS. The execution device 36 executes the device program PD to perform processing related to the storage and deletion of key information DK. The virtual device 40V, like the mobile device 40M, also stores owner key information DKO, which indicates the owner key KO, as key information DK. The share key list LS will be described later.

[0028] As shown in Figures 5 and 6, the share device 50 stores share key information DKS, which indicates the share key KS, as key information DK. The share device 50 is a separate device 30 from the owner device 40. The share key KS is a digital key that can be registered multiple times for a single 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 a single vehicle 20.

[0029] The friend device 51 included in the share device 50 is, for example, a mobile information terminal such as a smartphone. As shown in Figure 5, the friend device 51, like the mobile device 40M, includes a wireless communication device 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 storage device 37 stores a device program PD, key information DK, and share key information DKS. In the friend device 51, the key information DK is friend key information DKF, which indicates the friend key KF.

[0030] The non-friendly device 52 included in the shared device 50 is, for example, a mobile information terminal such as a smartphone. As shown in Figure 6, the non-friendly device 52, like the mobile device 40M, includes a wireless communication device 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 storage device 37 stores a device program PD, key information DK, and shared key information DKS. In the non-friendly device 52, the key information DK is non-friendly key information DKN, which indicates the non-friendly key KN.

[0031] In other words, the types of share keys KS include friend keys KF and non-friend keys KN. Friend keys KF are share keys KS registered based on a direct registration request D31 from the owner device 40, as will be described later. Non-friend keys KN are share keys KS registered based on a registration request D41 from a friend device 51, as will be described later. In other words, non-friend keys KN are share keys KS registered not based on a direct registration request D31 from the owner device 40, but on a registration request D41 from another device 30. To put it another way, non-friend keys KN are share keys KS that are not friend keys KF.

[0032] The management server 70 manages digital keys. As shown in Figure 7, the management server 70 comprises an execution device 71, a storage device 72, and a wireless communication device 73. The wireless communication device 73 is a wireless communication device that communicates wirelessly with device 30, vehicle 20, and server 80. The storage device 72 stores the server program PS, the period management program PT, and the database DB. The server program PS is executed by the execution device 71, causing the execution device 71 to register digital keys in the database DB and delete digital keys in the database DB. The period management program PT is executed by the execution device 71, causing the execution device 71 to manage the validity period VP of the share key KS, which will be described later.

[0033] The device server 60 shown in Figure 1 relays communication between the device 30, which is a portable information terminal, 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. For example, "type" refers to the model of the device 30, and a separate device server 60 is provided for each model of the device 30. For example, "type" also refers to the communication line used by the device 30, and a separate device server 60 is provided for each communication line used by the device 30.

[0034] Each device server 60 relays communication with the management server 70, allowing different types of devices 30 to communicate with the management server 70 via the device server 60. Note that only one device server 60 is shown in Figure 1.

[0035] In summary, when a digital key is registered, it is in a state where the digital key is usable. That is, when a digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. Authenticating a digital key in the vehicle 20 means enabling the vehicle 20 to be controlled by that digital key. For example, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 controls the lock mechanism 29A to enable unlocking of the vehicle 20. Alternatively, when the vehicle management device 26 authenticates a digital key, the vehicle management device 26 controls the engine 29B to enable starting of the vehicle 20.

[0036] <Structure of information related to digital keys> As shown in Figure 8, 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, and authorization public key information ST8.

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

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

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

[0040] As shown in Figure 9, the share key information DKS includes the share key structure information STS and the 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 removed.

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

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

[0043] 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 key KS. For example, it is set as an identifiable name for each share device 50 through an operation from the owner device 40.

[0044] The database DB shown in Figure 7 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. The management server 70 manages the digital keys by saving the data DA in the database DB.

[0045] As shown in Figure 10, the data DA of a single vehicle 20 includes the type of digital key registered to that vehicle 20, the registered device 30, and the relationships between the registered devices 30. A hierarchy is established based on 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.

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

[0047] 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, starting control of the vehicle 20's engine 29B, turning on the power of the vehicle 20, and unlocking and locking control of the vehicle 20's locking mechanism 29A. For example, if the control range of the controllable vehicle 20 is 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 only the unlocking and locking control of the vehicle 20's locking mechanism 29A. More specifically, the control range of the vehicle 20 that can be controlled by friend key KF is the three controls mentioned above, while the control range of the vehicle 20 that can be controlled by non-friend key KN is only the unlocking and locking control of the vehicle 20's locking mechanism 29A.

[0048] This section describes a state in which a digital key is registered to 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 to each of Devices 1 30A to Device 7 30G are referred to as Digital Key 1 to Digital Key 7.

[0049] 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 the owner device 40. In other words, the first digital key is Owner Key KO.

[0050] 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 all Share Devices 50. That is, the second to seventh digital keys are all Share Key KS.

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

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

[0053] In 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 is registered based on the second digital key. In 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 is registered based on the second digital key.

[0054] In data DA, the relationship between the 6th device 30F and the 5th device 30E is such that the non-friendly key KN is registered in the 6th device 30F based on a registration request from the 5th device 30E. In other words, the 6th digital key is registered based on the 5th digital key. In 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 based on a registration request from the 5th device 30E. In other words, the 7th digital key is registered based on the 5th digital key.

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

[0056] <Digital Key Registration> Next, a series of processes for registering digital keys in the management system 10 will be described. The management system 10 registers the owner key KO, the friend key KF, and the non-friend key KN as digital keys. Below, first, the series of processes for registering the owner key KO in the portable device 40M will be described. Next, the series of processes for registering the owner key KO in the virtual device 40V will be described. After that, the series of processes for registering the friend key KF in the second device 30B will be described. Finally, the series of processes for registering the non-friend key KN in the third device 30C will be described. From here on, processes executed by the execution device 27 of the vehicle 20 will be described as processes executed by the vehicle 20. Processes executed by the execution device 36 of the portable device 40M and the execution device 36 of the virtual device 40V will be described as processes executed by the portable device 40M and the virtual device 40V. Processes executed by the execution device 36 of the second device 30B and the execution device 36 of the third device 30C will be described as processes executed by the second device 30B and the third device 30C. The process executed by the execution device 71 of the management server 70 will be described as a process executed by the management server 70.

[0057] <Registering the owner key KO to a mobile device 40M> As shown in Figure 11, the management system 10 performs a series of processes to register the owner key KO with the mobile device 40M. The mobile device 40M registers the owner key KO with the vehicle 20 using proximity communication.

[0058] In the management system 10, upon registration of the owner key KO, the owner key information DKO, which is key information DK indicating the owner key KO of the vehicle 20, is stored in the mobile device 40M. In the management system 10, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. Once the owner key KO is authenticated and registered with the management server 70, it becomes possible to control the vehicle 20 using the owner key KO.

[0059] When the management server 70 receives the owner key KO registration start request D11 from the mobile device 40M, the owner key KO registration process is started. The registration start request D11 contains information indicating that the owner device 40 to which the owner key KO will be registered is the mobile device 40M.

[0060] In step S111, the management server 70 generates a pairing password PAS to be used for pairing the mobile device 40M with the vehicle 20. Subsequently, the management server 70 transmits information indicating the pairing password PAS to the mobile device 40M using the wireless communication device 73. The management server 70 transmits a registration request D12, which includes information indicating the pairing password PAS, to the vehicle 20 using the wireless communication device 73.

[0061] Upon receiving registration request D12, vehicle 20 activates the equipment necessary for authenticating the owner key KO using a proximity communication device in step S112. These devices include, for example, a BLE module 23, a UWB module 24, an NFC module 25, and the digital key ECU of the vehicle management device 26. By activating these devices, vehicle 20 becomes able to wait for and perform digital key authentication using a proximity communication device.

[0062] Next, in step S113, when the owner of vehicle 20 approaches vehicle 20 with a mobile device 40M that has received the pairing password PAS, pairing between vehicle 20 and mobile device 40M is performed using the proximity communication device. Pairing can be performed using at least one of the BLE module 23, UWB module 24, and NFC module 25. At this time, if authentication using the pairing password PAS held by both mobile device 40M and vehicle 20 is successful, pairing is completed. Once pairing is complete, a secure channel is established between vehicle 20 and mobile device 40M for data communication using the proximity communication device. After that, vehicle 20 proceeds to step S114. From this point onward, communication between vehicle 20 and mobile device 40M until the registration process of the owner key KO is completed is performed through this secure channel.

[0063] In step S114, 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. Next, the vehicle 20 sends generated data DC to the mobile device 40M via the secure channel to generate the owner key KO. The generated data DC includes vehicle identification information ST1 and vehicle public key information ST7, which indicates the vehicle public key PKV. Upon receiving the generated data DC, the mobile device 40M proceeds to step S115.

[0064] In step S115, the mobile device 40M generates owner key information DKO, which indicates the owner key KO. Next, in step S116, the mobile device 40M stores the owner key information DKO. Subsequently, the mobile device 40M sends certificate information ST5 related to the owner key KO and device public key information ST6, which indicates the device public key PKD, to the vehicle 20.

[0065] When vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process in step S117. In step S117, vehicle 20 verifies certificate information ST5. Once the verification of certificate information ST5 is complete, vehicle 20 proceeds to step S118.

[0066] In step S118, 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 an authentication completion notification D13 to the mobile device 40M indicating that the storage of the authentication information AT is complete.

[0067] When the mobile device 40M receives the authentication completion notification D13, the mobile device 40M performs the process in step S119. In step S119, the mobile device 40M generates a key track request D14 for the owner key KO. The key track request D14 is a signal to the management server 70 requesting an update to the database DB. The mobile device 40M then sends the key track request D14 for the owner key KO to the management server 70 via the device server 60.

[0068] When the management server 70 receives the key track request D14, it performs the processing in step S120. In step S120, the management server 70 performs the registration management of the owner key KO. Specifically, it stores the mobile device 40M as the device 30 to which the owner key KO is registered in the data DA of the vehicle 20 in the database DB. With this, the management system 10 completes the series of processes to register the owner key KO in the mobile device 40M.

[0069] <Registering the owner key KO to virtual device 40V> As shown in Figure 12, the management system 10 performs a series of processes to register the owner key KO with the virtual device 40V. The virtual device 40V does not perform proximity communication with the vehicle 20, but registers the owner key KO using wireless communication.

[0070] In the management system 10, upon registration of the owner key KO, the owner key information DKO, which is key information DK indicating the owner key KO of the vehicle 20, is stored in the virtual device 40V. In the management system 10, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. Once the owner key KO is authenticated and registered with the management server 70, it becomes possible to control the vehicle 20 using the owner key KO.

[0071] When the management server 70 receives a registration start request D21 for the owner key KO from the virtual device 40V, the owner key KO registration process is started. Upon receiving the registration start request D21, the management server 70 sends key generation information DKC to the virtual device 40V to generate the owner key KO. The registration start request D21 contains information indicating that the owner device 40 to which the owner key KO will be registered is the virtual device 40V. The key generation information DKC contains information corresponding to vehicle identification information ST1 and vehicle public key information ST7, which indicates the vehicle public key PKV. Upon receiving the key generation information DKC, the virtual device 40V proceeds to step S121.

[0072] In step S121, the virtual device 40V generates owner key information DKO, which indicates the owner key KO. Next, in step S122, the virtual device 40V stores the owner key information DKO. Subsequently, the virtual device 40V sends an authentication request D22 for the owner key KO to the management server 70, which includes the owner key authentication information DKA, which corresponds to the certificate information ST5 and the device public key information ST6, which indicates the device public key PKD, relating to the owner key KO.

[0073] Subsequently, the management server 70, upon receiving the authentication request D22, sends a registration request D23 to the vehicle 20 using the wireless communication device 73. The registration request D23 includes information indicating that the owner device 40 to which the owner key KO is registered is a virtual device 40V. On the other hand, the aforementioned registration request D12 does not include information indicating that the owner device 40 to which the owner key KO is registered is a virtual device 40V.

[0074] Upon receiving registration request D23, vehicle 20 activates the equipment necessary for authenticating the owner key KO using the wireless communication device 21 in step S123. These devices include, for example, the wireless communication device 21 and the digital key ECU provided in the vehicle management device 26. By activating these devices, vehicle 20 becomes able to wait for and perform digital key authentication using the wireless communication device 21.

[0075] Next, the management server 70, which sent the registration request D23, sends an owner key KO authentication start request D24, which includes the owner key authentication information DKA, to the vehicle 20 using the wireless communication device 73. Upon receiving the authentication start request D24, the vehicle 20 proceeds to step S124 to start the authentication of the owner key KO.

[0076] In step S124, the vehicle 20 verifies the owner key authentication information DKA. Once the verification of the information corresponding to the certificate information ST5 contained in the owner key authentication information DKA is complete, the vehicle 20 proceeds to step S125.

[0077] In step S125, the vehicle 20 stores information corresponding to the device public key information ST6, which indicates the device public key PKD, as authentication information AT. Subsequently, the vehicle 20 sends an authentication completion notification D25 to the management server 70 using the wireless communication device 21, indicating that the storage of the authentication information AT is complete.

[0078] When the management server 70 receives the authentication completion notification D25, it performs the process in step S126. In step S126, the management server 70 performs the registration management of the owner key KO. Specifically, it stores the virtual device 40V as the device 30 to which the owner key KO is registered in the data DA of the vehicle 20 in the database DB. With this, the management system 10 completes the series of processes to register the owner key KO in the virtual device 40V.

[0079] <Registering Friend Key KF> As shown in Figure 13, the management system 10 performs a series of processes to register the friend key KF. When the owner device 40 is a virtual device 40V, the friend key KF registration process is as follows. Among 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.

[0080] When the virtual device 40V executes a process to request the registration of the friend key KF, the virtual device 40V first performs the process in step S131. In step S131, the virtual device 40V sends the friend key KF registration request D31 to a relay server (not shown in the diagram). After that, the virtual device 40V proceeds to step S132.

[0081] In step S132, the virtual device 40V 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 the share information SH1 necessary for sharing the digital key. The virtual device 40V then sends the invitation information IV1 to the second device 30B.

[0082] Subsequently, when the second device 30B receives the invitation information IV1, it performs the process in step S133. In step S133, 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.

[0083] 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 virtual device 40V. After that, the second device 30B proceeds to step S134.

[0084] In step S134, 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 D32A indicating that it has finished uploading the generated unsigned friend key information DKFN to a URL link, and a signature request D32B requesting a signature, to the virtual device 40V.

[0085] Subsequently, the virtual device 40V receives a completion notification D32A and a signature request D32B from the second device 30B. Upon receiving the completion notification D32A, the virtual device 40V obtains the unsigned friend key information DKFN. Upon receiving the signature request D32B, the owner device 40 performs the process in step S135.

[0086] In step S135, the virtual device 40V generates signature information ATP1. Specifically, the virtual device 40V generates signature information ATP1 after confirming that the acquired unsigned friend key information DKFN is correct. After that, the virtual device 40V proceeds to step S136.

[0087] In step S136, virtual device 40V adds signature information ATP1 to unsigned friend key information DKFN. This causes virtual device 40V to generate friend key information DKF. Then, virtual device 40V uploads the generated friend key information DKF to the URL link which is invitation information IV1. Finally, virtual device 40V sends completion notification D33 to second device 30B, indicating that the upload of the completed friend key information DKF to the URL link is complete.

[0088] Subsequently, the second device 30B obtains a completion notification D33. Then, the second device 30B performs the process in step S137. In step S137, 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 S138.

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

[0090] Subsequently, when the management server 70 receives the key track request D34 for the friend key KF, the management server 70 performs the process in step S139. In step S139, the management server 70 performs registration management for the friend key KF.

[0091] Specifically, the management server 70 verifies that the friend key KF, which is the target of keytrack request D34, 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 D34.

[0092] On the other hand, if the friend key KF that received the key track request D34 is not on the rejection list, the management server 70 registers the friend key KF that received the key track request D34 in the database DB. In other words, the management server 70 stores the friend key information DKF of the friend key KF that received the key track request D34 in the database DB. In this way, the management server 70 stores the second device 30B in the vehicle 20 data DA in the database DB as device 30 registered as friend device 51. The management server 70 stores the relationship between the second device 30B and the virtual device 40V by referring to the acquired friend key information DKF. Specifically, the management server 70 stores the second device 30B as device 30 having the friend key KF registered by the registration request D31 from the virtual device 40V.

[0093] Subsequently, the management server 70 sends the authentication package ATP from the friend key information DKF and a storage request D35 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 virtual device 40V.

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

[0095] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification D36 to the second device 30B. Subsequently, when the second device 30B receives the key track completion notification D36, it performs the process in step S141. In the process of step S141, 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 displays an image on the HMI 32 indicating that the registration of the friend key KF is complete. With this, the management system 10 completes the series of processes for registering the friend key KF.

[0096] Note that if the owner device 40 is a mobile device 40M, the processing in step S135 differs from the case where the owner device 40 is a virtual device 40V. When the owner device 40 is a mobile device 40M, the mobile device 40M generates signature information ATP1 as follows.

[0097] The mobile device 40M prompts the HMI 32 of the mobile device 40M to present the acquired unsigned friend key information DKFN, and accepts an operation indicating that the user of the mobile device 40M consents to the registration of the friend key KF. Once the operation is performed, the mobile device 40M obtains a signature based on the fact that the operation has been performed. Subsequently, the mobile device 40M proceeds to step S136.

[0098] <Registering Non-Friend Keys (KN)> As shown in Figure 14, the management system 10 performs a series of processes to register the non-friendly key KN. Of 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.

[0099] 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 S151. In step S151, the friend device 51 sends the non-friend key KN registration request D41 to a relay server (not shown in the figure). After that, the friend device 51 proceeds to step S152.

[0100] In step S152, 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.

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

[0102] 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 S154.

[0103] In step S154, 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 D42A indicating that it has finished uploading the generated unsigned non-friend key information DKNN to a URL link, and a signature request D42B requesting a signature, to the friend device 51.

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

[0105] In step S155, 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 S156.

[0106] In step S156, 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 D43 to the third device 30C indicating that it has finished uploading the completed non-friend key information DKN to the URL link.

[0107] Subsequently, when the third device 30C receives the completion notification D43, it performs the process in step S157. In step S157, 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. After that, the third device 30C proceeds to step S158.

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

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

[0110] Specifically, the management server 70 verifies that the non-friendly key KN, which is the target of keytrack request D44, 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 D44.

[0111] 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 D44 in the database DB. The management server 70 stores the non-friendly key information DKN of the non-friendly key KN that received the key track request D44 in the database DB. In this way, the management server 70 stores the third device 30C in the vehicle 20 data DA in the database DB as a 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 a device 30 having a non-friendly key KN registered by a registration request D41 from the friend device 51.

[0112] Subsequently, the management server 70 sends the authentication package ATP from the non-friendly key information DKN and a storage request D45 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.

[0113] Subsequently, when vehicle 20 receives the authentication package ATP and the storage request D45, it performs the process in step S160. In step S160, 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.

[0114] Furthermore, after completing registration management, the management server 70 sends a keytrack completion notification D46 to the third device 30C. Subsequently, when the third device 30C receives the key track completion notification D46, it performs the process in step S161. In the process of step S161, 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.

[0115] <Share key KS validity period VP> A validity period VP can be defined for each share key KS. The validity period VP can be determined for each share key KS based on the effective start information ATP3 and the expiration information ATP4 included in the authentication package ATP shown in Figure 9. The validity period VP is the period from the date and time indicated in the effective start information ATP3 to the date and time indicated in the expiration information ATP4. A user who has a share key KS for vehicle 20 can use vehicle 20 with that share key KS during the validity period VP.

[0116] <Share key KS fade-out period FO> A fade-out period FO can be defined for a share key KS. The fade-out period FO is a grace period during which the deletion of a share key KS is postponed until the default condition RC is met. A user who has a share key KS for vehicle 20 can continue to use vehicle 20 using that share key KS during the fade-out period FO until the default condition RC is met and the share key KS is deleted.

[0117] The default condition RC can be defined, for example, as requiring that a digital key other than the share key KS to be deleted be authenticated to vehicle 20. In this case, if a digital key other than the share key KS to be deleted is authenticated to vehicle 20 during the fade-out period FO, the vehicle 20 will delete that share key KS.

[0118] On the other hand, vehicle 20 may choose not to delete a share key KS during the fade-out period FO, even if a digital key other than the share key KS during the fade-out period FO is authenticated by vehicle 20. More specifically, vehicle 20 may use a deletion flag EF to pre-configure whether or not to delete a share key KS during the fade-out period FO when a digital key other than the share key KS during the fade-out period FO is authenticated by vehicle 20.

[0119] The deletion flag EF is one of the pieces of information contained in the device deletion information DE stored in the storage device 28. The deletion flag EF is set to either an allowed or prohibited state for each share key KS registered in the vehicle 20.

[0120] If the delete flag EF is set to allow, vehicle 20 will delete the share key KS if a digital key other than the share key KS authenticated by vehicle 20 during the fade-out period FO.

[0121] If the deletion flag EF is set to prohibited, vehicle 20 will not delete the share key KS even if a digital key other than the share key KS during the fade-out period FO is authenticated by vehicle 20. In this case, the share key KS will not be deleted and will remain in the fade-out period FO.

[0122] <Request for deletion of the first share key KSA> As shown in Figure 15, when vehicle 20A receives a deletion request RQ for the first share key KSA, it performs a process to select the processing to be executed based on the type of deletion request RQ. The processing shown in Figure 15 is the process that the deletion program PE instructs the execution device 27 of vehicle 20A to execute.

[0123] Vehicle 20A is one of several vehicles 20. Vehicle 20A is a shared car used, for example, in rental car or car-sharing services. Vehicle 20A has the following registered keys: first owner key KOV, first share key KSA, and second share key KSB.

[0124] The first owner key KOV is the owner key KO registered on the virtual device 40V built on server 80. The virtual device 40V is, for example, the owner device 40 belonging to a business operator that provides car rental or car sharing services.

[0125] The first share key KSA is the share key KS registered to the first share device 51A belonging to the first user UA. The first share key KSA is the friend key KF. The second share key KSB is the share key KS registered to the second share device 52B belonging to the second user UB. The second share key KSB is the non-friend key KN. The first share key KSA and the second share key KSB have an expiration period VP set for use in vehicle 20A.

[0126] In the following, the processes executed by the execution device 27 of vehicle 20A will be described as processes executed by vehicle 20A. When vehicle 20A receives a deletion request RQ for the first share key KSA from the management server 70, it starts the series of processes shown in Figure 15.

[0127] <Type of deletion request RQ> First, let's explain the deletion request RQ, which is the premise for the series of processes shown in Figure 15. A deletion request RQ is a signal that requests the vehicle 20A to delete the authentication information AT related to the first share key KSA. Deletion request RQs are divided into several types based on the device 30 that requested the deletion or the circumstances under which the deletion was requested. There are three types of deletion request RQs: the first deletion request RQ1, the second deletion request RQ2, and the third deletion request RQ3.

[0128] The first deletion request RQ1 is a deletion request RQ based on a request from the first share key KSA itself. The second deletion request RQ2 is a deletion request RQ based on the expiration of the validity period VP of the first share key KSA. The third deletion request RQ3 is a deletion request RQ based on a request from the first owner key KOV, which is a digital key other than the first share key KSA.

[0129] As shown in Figure 16, the management system 10 performs a series of processes to send a first deletion request RQ1 to the vehicle 20A. As shown in Figure 16, in step S311, the first share device 51A executes termination process TP based on the operation of the first user UA. Termination process TP authorizes the management server 70 to start the deletion process of the first share key KSA. After executing termination process TP, the first share device 51A sends a termination notification D51 to the management server 70 indicating that the use of vehicle 20A has ended.

[0130] When the management server 70 receives the termination notice D51, it executes the process in step S312. In step S312, the management server 70 generates a first deletion request RQ1 based on the termination notice D51.

[0131] The first deletion request RQ1 contains information indicating that the deletion request RQ was made from the first share key KSA and requests the deletion of the first share key KSA. Specifically, the first deletion request RQ1 includes digital key identification information ST3 indicating the first share key KSA as information indicating the digital key that made the deletion request RQ. The first deletion request RQ1 includes digital key identification information ST3 indicating the first share key KSA as information indicating the digital key for which the deletion of authentication information AT is requested. When the management server 70 generates the first deletion request RQ1, it sends the first deletion request RQ1 to the vehicle 20A.

[0132] Then, when vehicle 20A receives the first deletion request RQ1, in step S313, it starts the process shown in Figure 15. As shown in Figure 17, the management system 10 performs a series of processes to issue a second deletion request RQ2 to the vehicle 20A.

[0133] As shown in Figure 17, in step S321, the management server 70 confirms that the validity period VP of the first share key KSA has expired. Specifically, the period management program PT instructs the execution device 71 to obtain the expiration date information ATP4 of the first share key KSA from the database DB at predetermined intervals to confirm whether the validity period VP has expired. If the management server 70 confirms in step S321 that the validity period VP of the first share key KSA has expired, the management server 70 proceeds to step S322.

[0134] In step S322, the management server 70 generates a second deletion request RQ2. The second deletion request RQ2 contains information indicating that the deletion request RQ is requesting the deletion of the first share key KSA based on the expiration of the validity period VP of the first share key KSA. Specifically, the second deletion request RQ2 includes digital key identification information ST3 indicating the first share key KSA as information indicating the digital key for which the deletion of authentication information AT is requested. The second deletion request RQ2 includes the validity start information ATP3 and expiration information ATP4 of the first share key KSA as information indicating that the validity period VP of the first share key KSA has expired. Once the management server 70 generates the second deletion request RQ2, it sends the second deletion request RQ2 to the vehicle 20A.

[0135] Then, when vehicle 20A receives the second deletion request RQ2, in step S323, it starts the process shown in Figure 15. As shown in Figure 18, the management system 10 performs a series of processes to issue a third deletion request RQ3 to the vehicle 20A.

[0136] As shown in Figure 18, in step S331, the virtual device 40V generates a deletion reservation request D61. The deletion reservation request D61 requests the management server 70 to delete the first share key KSA. The deletion reservation request D61 includes information about the conditions for executing the deletion of the first share key KSA. This information about the conditions for executing the deletion is, for example, the date and time for deleting the first share key KSA. Subsequently, the virtual device 40V sends the deletion reservation request D61 to the management server 70.

[0137] When the management server 70 receives the deletion reservation request D61, it executes the process in step S332. In step S332, the management server 70 generates a third deletion request RQ3 based on the deletion reservation request D61. The third deletion request RQ3 contains information indicating that the deletion request RQ requests the deletion of the first share key KSA, which was performed from the first owner key KOV. Specifically, the third deletion request RQ3 includes digital key identification information ST3 indicating the first owner key KOV as information indicating the digital key that made the deletion request RQ. The third deletion request RQ3 includes digital key identification information ST3 indicating the first share key KSA as information indicating the digital key for which the deletion of authentication information AT is requested. The third deletion request RQ3 contains information about the conditions for performing the deletion of the first share key KSA. When the management server 70 generates the third deletion request RQ3, it sends the third deletion request RQ3 to the vehicle 20A.

[0138] Subsequently, when vehicle 20A receives the third deletion request RQ3, it starts the process shown in Figure 15 in step S333. <Selection of deletion process in vehicle 20A> Upon receiving any of the deletion requests RQ1, RQ2, or RQ3, vehicle 20A begins the process shown in Figure 15.

[0139] As shown in Figure 15, in step S211, the vehicle 20A determines whether the received deletion request RQ is the first deletion request RQ1. If the deletion request RQ is the first deletion request RQ1 (step S211; YES), the vehicle 20A proceeds to step S212. If the deletion request RQ is not the first deletion request RQ1 (step S211; NO), the vehicle 20A proceeds to step S216.

[0140] In step S212, vehicle 20A acquires its position information GL using positioning device 29C. Once vehicle 20A has acquired its position information GL, it proceeds to step S213.

[0141] In step S213, vehicle 20A determines whether the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD. If in step S213 it is determined that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD (step S213; YES), vehicle 20A proceeds to step S214. If in step S213 it is not determined that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD (step S213; NO), vehicle 20A proceeds to step S215.

[0142] Here, return point SD is a location predetermined as the point where the use of vehicle 20A ends. In other words, if return point SD is predetermined, return point SD corresponds to end point SE, which is the predetermined point where the use of vehicle 20A ends.

[0143] Figure 19 shows the positional relationship between the location information GL of vehicle 20A and the return point SD. Figure 19 also shows the usage area AR. The usage area AR indicates the geographical area where the use of vehicle 20A is permitted. The usage area AR is, for example, any city or town in Japan. For example, if the usage area AR is City T in Japan, the user is permitted to use vehicle 20A only within City T.

[0144] The return point SD for vehicle 20A is return spot SP6, indicated by a black circle in Figure 19. Users of vehicle 20A can freely use vehicle 20A within the usage area AR as long as it is within the validity period VP. Users of vehicle 20A must then arrive at return spot SP6, which is the return point SD, before the validity period VP ends, and end their use of vehicle 20A.

[0145] Figure 20 is a schematic diagram showing an enlarged view of the area around the return spot SP6 shown in Figure 19. As shown in Figure 20, a return parking area AP is provided around the return spot SP6. The return parking area AP is a site for parking vehicle 20A when the use of vehicle 20A ends. The return parking area AP is, for example, a parking space at a rental car shop. In a car-sharing service, the return parking area AP is a parking space provided at a car station. A car station is, for example, an unmanned facility equipped with multiple shared cars and the necessary equipment for users to start or end the use of shared cars.

[0146] As shown by the dashed circle in Figure 20, a returnable area A6 is set up around the return spot SP6. The returnable area A6 is virtually set as any area within a predetermined distance from the return spot SP6. As shown in Figure 20, the returnable area A6 is, for example, a circular area with a predetermined radius that covers the entire area of ​​the return parking lot AP at the return spot SP6.

[0147] In Figure 20, the location information GL of vehicle 20A, shown by a solid line, indicates that the vehicle is stopped within the return area A6 and in the corner of the return parking area AP. Thus, when the location information GL of vehicle 20A is located within a predetermined distance from the return spot SP6, it is determined that vehicle 20A is stopped at the return spot SP6.

[0148] In other words, in step S213 of Figure 15, vehicle 20A determines, based on its location information GL, whether the first deletion request RQ1 was made while vehicle 20A was stopped at the return spot SP6, which is the return point SD. If vehicle 20A's location information GL is within a predetermined distance from the return spot SP6, vehicle 20A determines that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD (step S213; YES). In step S213, if vehicle 20A's location information GL is not within a predetermined distance from the return spot SP6, vehicle 20A does not determine that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD (step S213; NO).

[0149] Subsequently, in step S214, vehicle 20A executes the first deletion process. The first deletion process is the deletion process of the first share key KSA performed by vehicle 20A when the deletion request RQ is the first deletion request RQ1, and the first deletion request RQ1 is made while vehicle 20A is stopped at the return point SD. Details of the first deletion process will be described later.

[0150] In step S215, vehicle 20A sends a termination failure notification to the management server 70. The termination failure notification contains information indicating that the termination process TP for vehicle 20A was not completed because it was determined that the first deletion request RQ1 was not performed while vehicle 20A was stopped at the return point SD. Upon receiving the termination failure notification, the management server 70 forwards a reprocessing request to the first share device 51A based on the notification. The reprocessing request is a notification to the first user UA to which the first share device 51A belongs, requesting that it confirm that vehicle 20A is stopped at the return point SD and then perform the termination process TP again.

[0151] In step S211, if it is determined that the deletion request RQ is not the first deletion request RQ1 (step S211; NO), the vehicle 20A executes the process in step S216. In step S216, the vehicle 20A determines whether the deletion request RQ is the second deletion request RQ2. In step S216, if it is determined that the deletion request RQ is the second deletion request RQ2 (step S216; YES), the vehicle 20A proceeds to step S217. In step S216, if it is determined that the deletion request RQ is not the second deletion request RQ2 (step S216; NO), the vehicle 20A proceeds to step S218.

[0152] In step S217, vehicle 20A performs a second deletion process. The second deletion process is the deletion process of the first share key KSA that vehicle 20A performs when the deletion request RQ is a second deletion request RQ2. Details of the second deletion process will be described later.

[0153] In step S218, vehicle 20A confirms that the deletion request RQ is the third deletion request RQ3. Then, vehicle 20A proceeds to step S219. In step S219, vehicle 20A performs the third deletion process. The third deletion process is the deletion process of the first share key KSA that vehicle 20A performs when the deletion request RQ is the third deletion request RQ3. Details of the third deletion process will be described later.

[0154] Vehicle 20A terminates the above series of processes after executing any of the processes in steps S214, S215, S217, and S219. <Deletion process for the first share key KSA> The following describes the first deletion process, the second deletion process, and the third deletion process shown in Figure 15 in order. In the following, the default condition RC for the end of the fade-out period FO is, as above, that a digital key other than the first share key KSA, which is the share key KS to be deleted, is authenticated by the vehicle 20A. In the following, the digital key other than the first share key KSA that is authenticated by the vehicle 20A will be described as the second share key KSB. The deletion flag EF is information indicating whether or not to allow the deletion of the first share key KSA during the fade-out period FO. As above, in the following, the process executed by the execution device 27 will be described as the process executed by the vehicle 20A.

[0155] <First Deletion Process> As shown in Figure 21, vehicle 20A executes the first deletion process. The first deletion process is initiated by vehicle 20A when step S214 is executed in the process shown in Figure 15.

[0156] First, in step S411, vehicle 20A sets the delete flag EF to allow. Next, in step S412, vehicle 20A starts the fade-out period FO for the first share key KSA. At this time, the deletion flag EF for the first share key KSA is set to permitted by the processing in step S411. During the fade-out period FO started in step S412, when the second share key KSB is authenticated by vehicle 20A, vehicle 20A ends the fade-out period FO for the first share key KSA and deletes the first share key KSA. Hereinafter, the fade-out period FO in which the deletion of the first share key KSA is performed when the second share key KSB is authenticated by vehicle 20A will be referred to as the normal fade-out period FN.

[0157] Vehicle 20A terminates the first deletion process after executing the process in step S412. The above-mentioned first deletion process is the deletion process and the process equivalent to the above deletion process described in the section on means for solving the problem.

[0158] In other words, if vehicle 20A determines that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD, it initiates the first deletion process for the first share key KSA. The first deletion process is the process of initiating a normal fade-out period FN to delete the first share key KSA when a second share key KSB, which is a digital key other than the first share key KSA, is authenticated to vehicle 20A. The normal fade-out period FN initiated in step S412 is the second grace period.

[0159] <Second Deletion Process> As shown in Figure 22, vehicle 20A executes the second deletion process. The second deletion process is initiated by vehicle 20A when step S217 is executed in the process shown in Figure 15.

[0160] First, in step S421, vehicle 20A sets the delete flag EF to prohibited. Next, in step S422, vehicle 20A starts the fade-out period FO for the first share key KSA. At this time, the deletion flag EF for the first share key KSA is set to prohibited by the processing in step S421. During the fade-out period FO that starts in step S422, vehicle 20A does not delete the first share key KSA even if the second share key KSB is authenticated to vehicle 20A, and continues the fade-out period FO. Hereinafter, the fade-out period FO in which vehicle 20A does not delete the first share key KSA even if the second share key KSB is authenticated to vehicle 20A will be referred to as the restricted fade-out period FR. The start date and time of the restricted fade-out period FR is set to coincide with the end date and time of the validity period VP of the first share key KSA.

[0161] Vehicle 20A completes the second deletion process after executing the process in step S422. In other words, if a second deletion request RQ2 is made, vehicle 20A will implement a restricted fade-out period FR. Vehicle 20A will begin the restricted fade-out period FR after the second deletion request RQ2 is made, that is, after the validity period VP of the first share key KSA has ended. The restricted fade-out period FR is the first grace period that delays the execution of the deletion of the first share key KSA.

[0162] When the second deletion process is performed, the first deletion request RQ1 has not been made to vehicle 20A. In other words, vehicle 20A executes the second deletion process to start the limited fade-out period FR if it has not determined that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD. If vehicle 20A has not determined that the first deletion request RQ1 was made while vehicle 20A was stopped at the return point SD, it will not delete the first share key KSA even if a digital key other than the first share key KSA is authenticated to vehicle 20A.

[0163] <Third Deletion Process> As shown in Figure 23, vehicle 20A executes the third deletion process. The third deletion process is initiated by vehicle 20A when step S219 is executed in the process shown in Figure 15.

[0164] First, in step S431, vehicle 20A sets the delete flag EF to allow. Next, in step S432, vehicle 20A starts the fade-out period FO for the first share key KSA. At this time, the deletion flag EF for the first share key KSA is set to permitted by the processing in step S431. During the fade-out period FO that starts in step S432, when the second share key KSB is authenticated by vehicle 20A, vehicle 20A ends the fade-out period FO for the first share key KSA and deletes the first share key KSA. In other words, the fade-out period FO that starts in step S432 is a normal fade-out period FN, similar to the first deletion process shown in Figure 21.

[0165] Vehicle 20A completes the third deletion process after executing the process in step S432. The normal fade-out period FN, which begins in step S432, is a third grace period that delays the execution of the deletion of the first share key KSA until the third deletion request RQ3 is made and the second share key KSB is authenticated.

[0166] <Deletion of the first share key KSA> As shown in Figures 24 to 26, the management system 10 performs a series of processes related to the deletion of the first share key KSA. In Figures 24 to 26, the first share key KSA is the share key KS to be deleted. In Figures 24 to 26, the second share key KSB is a digital key other than the first share key KSA that is authenticated for the vehicle 20A.

[0167] As shown in Figure 24, first, in step S511, vehicle 20A starts the fade-out period FO of the first share key KSA. This fade-out period FO includes either the normal fade-out period FN shown in Figures 21 and 23, or the limited fade-out period FR shown in Figure 22. When vehicle 20A starts either fade-out period FO, it sends a pending start notification D71 to the management server 70 indicating that the fade-out period FO of the first share key KSA has started.

[0168] When the management server 70 receives the pending notification D71, it performs the process in step S512. In step S512, the management server 70 generates a pending deletion notification D72 indicating that the first share key KSA is in the fade-out period FO, in accordance with the pending notification D71. The management server 70 then sends the pending deletion notification D72 to the first share device 51A.

[0169] Subsequently, when the first share device 51A receives the deletion pending notification D72, the first share device 51A performs the process in step S513. In step S513, the first share device 51A presents information to the HMI 32 indicating that the first share key KSA registered to it is in the fade-out period FO. At this time, the first share device 51A displays information to the HMI 32 indicating whether the fade-out period FO of the first share key KSA is the normal fade-out period FN or the restricted fade-out period FR. In other words, the first share device 51A displays information to the HMI 32 indicating whether the first share key KSA will be deleted if a digital key other than the first share key KSA is authenticated by the vehicle 20A.

[0170] After processing in step S512, the management server 70 performs the processing in step S514. In step S514, the management server 70 generates a pending deletion notification D73 indicating that the first share key KSA is in the fade-out period FO, in accordance with the pending start notification D71, similar to step S512. The management server 70 then sends the pending deletion notification D73 to the virtual device 40V.

[0171] When virtual device 40V receives deletion pending notification D73, virtual device 40V performs the process in step S515. In step S515, virtual device 40V updates the share key list LS to remember that the first share key KSA is in the fade-out period FO.

[0172] The share key list LS is list information stored in the storage device 37 of the virtual device 40V. The share key list LS contains information about each share key KS registered based on each owner key KO registered in the virtual device 40V. For example, the share key list LS contains information about the validity period VP and fade-out period FO of each share key KS.

[0173] Virtual device 40V obtains information indicating whether the fade-out period FO of the first share key KSA is the normal fade-out period FN or the restricted fade-out period FR by referring to the information contained in the pending deletion notification D73. Virtual device 40V stores in the information for the first share key KSA in the share key list LS information indicating whether the fade-out period FO of the first share key KSA is the normal fade-out period FN or the restricted fade-out period FR.

[0174] Subsequently, as shown in Figure 25, once the second share key KSB is authenticated by the vehicle 20A, the vehicle 20A begins processing in step S516. In step S516, vehicle 20A confirms that the default condition RC has been met. That is, it confirms that a second share key KSB, which is different from the first share key KSA, has been authenticated to vehicle 20A. Once vehicle 20A confirms that the second share key KSB has been authenticated to vehicle 20A, it proceeds to step S517.

[0175] In step S517, vehicle 20A refers to the device deletion information DE to check the deletion flag EF for the first share key KSA. If vehicle 20A confirms that the first share key KSA is in the normal fade-out period FN with the deletion flag EF set to permitted, it proceeds to step S518. If vehicle 20A confirms that the first share key KSA is in the restricted fade-out period FR with the deletion flag EF set to prohibited, it terminates the process in step S517. Even if vehicle 20A terminates the process in step S517, the use of vehicle 20A with the second share key KSB can be performed without any problems. Subsequently, if a digital key other than the first share key KSA is authenticated by vehicle 20A again, vehicle 20A will start the process in step S516 again.

[0176] In step S518, vehicle 20A terminates the fade-out period FO of the first share key KSA. This fade-out period FO is normally the fade-out period FN. Once the fade-out period FO is terminated, vehicle 20A proceeds to step S519.

[0177] In step S519, vehicle 20A deletes the authentication information AT for authenticating the first share key KSA. That is, vehicle 20A deletes the authentication package ATP for the first share key KSA.

[0178] In step S520, vehicle 20A generates a key deletion request D74 requesting the deletion of the friend key information DKF of the first share key KSA. The key deletion request D74 includes information indicating that the deletion of the friend key information DKF of the first share key KSA is requested, as well as information indicating that the deletion of the authentication information AT related to the first share key KSA has been completed. Subsequently, vehicle 20A sends the key deletion request D74 to the management server 70.

[0179] When the management server 70 receives the key deletion request D74, it starts processing in step S521. In step S521, the management server 70 stores the history of the deletion of the authentication information AT used to authenticate the first share key KSA in vehicle 20A. After that, the management server 70 proceeds to step S522.

[0180] In step S522, the management server 70 generates a key deletion request D75 that requests the deletion of the friend key information DKF, which indicates the first share key KSA. Then, as shown in Figure 26, the management server 70 sends a key deletion request D75 to the first share device 51A.

[0181] Subsequently, when the first share device 51A receives the key deletion request D75, it performs the process in step S523. In step S523, the first share device 51A deletes the friend key information DKF, which indicates the first share key KSA, in accordance with the key deletion request D75. Then, the first share device 51A sends a deletion completion notification D76 to the management server 70, indicating that it has completed the deletion in accordance with the key deletion request D75.

[0182] Subsequently, when the management server 70 receives the deletion completion notification D76, the management server 70 performs the process in step S524. In step S524, the management server 70 stores the history of the deletion of the friend key information DKF related to the first share key KSA on the first share device 51A. After that, the management server 70 proceeds to step S525.

[0183] In step S525, the management server 70 updates the database DB. Specifically, the management server 70 deletes the first share device 51A, which has the first share key KSA, from the data DA of vehicle 20A in the database DB. Subsequently, the management server 70 sends a deletion completion notification D77 to the virtual device 40V indicating that the deletion of the first share key KSA based on the deletion request RQ has been completed.

[0184] Subsequently, when the virtual device 40V receives the deletion completion notification D77, the virtual device 40V performs the process in step S526. In step S526, the virtual device 40V stores information in the storage device 37 indicating that the deletion of the first share key KSA has been completed. Specifically, the virtual device 40V updates the information regarding the first share key KSA in the share key list LS. In this way, the management system 10 completes the series of processes for the deletion of the first share key KSA.

[0185] <Emergency Deletion Process for the First Share Key KSA in the EU> As shown in Figure 27, vehicle 20A performs a series of processes when performing an emergency deletion process EU on the first share key KSA. The processes shown in Figure 27 are processes that vehicle 20A performs at predetermined intervals during the limited fade-out period FR based on the deletion program PE. As before, processes performed by the execution device 27 will be described below as processes performed by vehicle 20A.

[0186] In Figure 27, the first share key KSA is in the limit fade-out period FR. In other words, the first share key KSA is in the state after the second deletion process has been executed due to the expiration of the validity period VP.

[0187] First, in step S611, vehicle 20A obtains the excess time OT for the first share key KSA. The excess time OT is the elapsed time from the start of the limited fade-out period FR. Specifically, the excess time OT is the elapsed time from the start date and time of the limited fade-out period FR. Once the excess time OT is obtained, vehicle 20A proceeds to step S612.

[0188] In step S612, vehicle 20A determines whether the excess time OT is equal to or greater than a predetermined time. If it is determined in step S612 that the excess time OT is equal to or greater than a predetermined time (step S612; YES), vehicle 20A proceeds to step S613. If it is not determined in step S612 that the excess time OT is equal to or greater than a predetermined time (step S612; NO), vehicle 20A terminates the series of processes.

[0189] Next, in step S613, vehicle 20A acquires its driving history. Based on the location information GL of vehicle 20A at each time point, which is included in the vehicle history information HC, vehicle 20A acquires the progression of the location information GL of vehicle 20A as its driving history. After that, vehicle 20A proceeds to step S614.

[0190] In step S614, the vehicle 20A determines, based on its driving history, whether its location information GL is moving away from the return point SD. In step S614, if vehicle 20A determines that its position information GL is moving away from the return point SD (step S614; YES), vehicle 20A proceeds to step S615. In step S614, if vehicle 20A does not determine that its position information GL is moving away from the return point SD (step S614; NO), vehicle 20A terminates the series of processes.

[0191] Figure 28 shows the location information GL of vehicle 20A at time t when the excess time OT exceeds the predetermined time. The arrow CA shown in Figure 28 indicates the trajectory of vehicle 20A's location information GL based on the history of vehicle 20A's location information GL. The arrow CA shows the transition of vehicle 20A's location information GL from the start date and time of the limited fade-out period FR to time t. For example, when vehicle 20A's location information GL moves as shown by arrow CA in Figure 28, it is determined that vehicle 20A's location information GL is moving away from the return point SD.

[0192] Next, in step S615, vehicle 20A waits for the operation of vehicle 20A to end. The operation of vehicle 20A to end means, for example, that the user stops the engine 29B of vehicle 20A. The operation of vehicle 20A to end means, for example, that the user stops the engine 29B of vehicle 20A and locks vehicle 20A by operating the locking mechanism 29A from the outside of vehicle 20A. Once vehicle 20A confirms that the operation of vehicle 20A has ended, the process proceeds to step S616.

[0193] In step S616, vehicle 20A initiates emergency deletion process EU. That is, vehicle 20A initiates emergency deletion process EU when its operation ends. After that, vehicle 20A proceeds to step S617.

[0194] In step S617, vehicle 20A performs the deletion of the first share key KSA in the emergency deletion process EU. Specifically, vehicle 20A deletes the authentication information AT related to the first share key KSA registered to vehicle 20A. Once vehicle 20A has completed the deletion of the authentication information AT related to the first share key KSA, it proceeds to step S618.

[0195] In step S618, vehicle 20A sends an emergency deletion completion notification to the management server 70. The emergency deletion completion notification includes information indicating that the authentication information AT relating to the first share key KSA has been deleted by the emergency deletion process EU.

[0196] As described above, once the process in step S618 is executed, vehicle 20A terminates the series of processes related to the emergency deletion process. As described above, when the excess time OT exceeds the predetermined time, and the location information GL of vehicle 20A moves away from the return point SD, vehicle 20A then initiates the emergency deletion process EU to delete the first share key KSA, triggered by the termination of vehicle 20A's operation.

[0197] <Operation of this embodiment> If a grace period is provided to allow for the deletion of the first share key KSA after its validity period VP has expired, then vehicle 20A can be used with the first share key KSA even after the validity period VP has expired. However, if the deletion of the first share key KSA is performed during the grace period because the second share key KSB, which is a digital key other than the first share key KSA, is authenticated by vehicle 20A, then it becomes impossible to use vehicle 20A with the first share key KSA.

[0198] Based on the location information GL, the vehicle 20A determines whether the first deletion request RQ1 based on the termination process TP was made while the vehicle 20A was stopped at the return point SD, which is the termination point SE. If the execution device 27 determines that the first deletion request RQ1 was made while the vehicle 20A was stopped at the return point SD, then the use of the vehicle 20A is terminated. On the other hand, if the execution device 27 does not determine that the first deletion request RQ1 was made while the vehicle 20A was stopped at the return point SD, then the vehicle 20A is still being used. If the use of the vehicle 20A is not terminated, the vehicle 20A will not delete the first share key KSA during the restriction fade-out period FR, even if the second share key KSB, which is a different digital key from the first share key KSA, is authenticated by the vehicle 20A. Even after the expiration of the validity period VP, the vehicle 20A allows the first user UA to continue using the vehicle 20A using the first share key KSA until the termination process TP is performed at the return point SD.

[0199] <Effects of this embodiment> (1) According to vehicle 20A, the first share key KSA is deleted while vehicle 20A is in use, which prevents vehicle 20A from becoming unusable before reaching the destination.

[0200] (2) The execution device 27 determines that the vehicle 20A is stopped at the return point SD when the location information GL of the vehicle 20A is located within a predetermined distance from the return point SD. According to vehicle 20A, as long as it is within a predetermined distance from the return point SD, the use of vehicle 20A can be terminated even if vehicle 20A is stopped at a location far from the return point SD.

[0201] (3) The first deletion process is the process of deleting the first share key KSA when the second share key KSB, which is a digital key other than the first share key KSA, is authenticated for vehicle 20A, and the normal fade-out period FN is initiated.

[0202] According to vehicle 20A, even after the first user UA has performed the termination process TP, vehicle 20A can be used again using the first share key KSA until the second share key KSB, which is a digital key other than the first share key KSA, is authenticated by vehicle 20A.

[0203] (4) If the execution device 27 receives a deletion request RQ based on a request from the first owner key KOV, which is a digital key other than the first share key KSA, it will normally provide a fade-out period FN. The normal fade-out period FN is a period during which the execution of the deletion of the first share key KSA is delayed from the time the third deletion request RQ3 is made until the second share key KSB, which is a digital key other than the first share key KSA, is authenticated for the vehicle 20A.

[0204] Even after a third deletion request RQ3 is made based on a request from another digital key, vehicle 20A can continue to be used with the first share key KSA until a second share key KSB, which is a digital key other than the first share key KSA, is authenticated for vehicle 20A.

[0205] According to vehicle 20A, if a third deletion request RQ3 is made based on a request from another digital key, it is possible to prevent vehicle 20A from immediately becoming unusable. (5) When the excess time OT, which is the elapsed time from the start of the limited fade-out period FR, exceeds a predetermined time, the execution device 27 starts an emergency deletion process EU to delete the first share key KSA, triggered by the next termination of operation of the vehicle 20A.

[0206] If the excess time (OT) exceeds the predetermined time, the use of vehicle 20A using the first share key (KSA) continues even though the predetermined time has elapsed since the end of the validity period (VP). When the excess time (OT) of vehicle 20A exceeds the predetermined time, the first share key (KSA) is deleted upon the termination of vehicle 20A's operation. In this way, vehicle 20A becomes unable to be used with the first share key (KSA) thereafter.

[0207] According to vehicle 20A, the use of vehicle 20A with the first share key KSA whose validity period VP has expired can be restricted. (6) The execution device 27 starts the emergency deletion process EU when the excess time OT is equal to or greater than the predetermined time, and the location information GL of the vehicle 20A is moving away from the return point SD.

[0208] If the overtime time (OT) exceeds the specified time, and the vehicle is moving away from the return point (SD), it is highly likely that the first user (UA) has no intention of returning vehicle 20A. According to vehicle 20A, if there is a high probability that the first user UA has no intention of returning vehicle 20A, the use of vehicle 20A using the first share key KSA can be restricted.

[0209] <Example of changes> This embodiment can be implemented with the following modifications. This embodiment and the following modifications can be combined with each other to the extent that they do not contradict each other technically.

[0210] Vehicle 20A has designated return point SD as the end point SE, which is predetermined as the point where the use of vehicle 20A will end. The end point SE may be selected by the user of vehicle 20 from among several candidate locations.

[0211] As shown in Figure 19, the usage area AR has five return points SC: return spots SP1, SP2, SP3, SP4, and SP5. The return points SC are candidate locations where the user can end their use of the vehicle 20. The vehicle 20B shown in Figure 19 is a vehicle 20 for which no end point SE has been predetermined. The user of vehicle 20B can select any of the five return points SC as their end point SE. For example, as indicated by the arrow in Figure 19, the user of vehicle 20B can select return spot SP2 as their end point SE.

[0212] In other words, if there are multiple returnable points SC where the vehicle 20B can be returned, then the end point SE is one of the returnable points SC. According to the vehicle 20B, the effect of (1) can be achieved even if there are multiple candidates for the end point SE. The vehicle 20B is equivalent to, for example, a rental car or shared car that can be used for one-way or one-way rentals.

[0213] Vehicle 20A is determined to be stopped at the return point SD when its location information GL is within a predetermined distance from the return point SD. The execution device 27 of vehicle 20A may also determine that vehicle 20A is stopped at the return point SD when its location information GL has been stopped at the return point SD for a predetermined time or longer.

[0214] For example, in the modified example, vehicle 20A may be determined to be stopped at the return point SD if its location information GL is within a predetermined distance from the return point SD, and the location information GL of vehicle 20A has been stopped at the return point SD for a predetermined time or longer.

[0215] In Figure 20, the vehicle 20A shown by the dashed line indicates that the vehicle 20A is temporarily stopped in the return parking area AP for less than the predetermined time. In such a case, the modified example does not determine that the vehicle 20A is stopped. In the modified example, the vehicle 20A is determined to be stopped if it is stopped for a predetermined time or longer, for example, at the position shown by the solid line in Figure 20.

[0216] According to the modified example of vehicle 20A, it is possible to more accurately determine that vehicle 20A is about to cease use. In Figure 27, the conditions under which vehicle 20A initiates the emergency deletion process EU are not limited to those described above. Vehicle 20A may initiate the emergency deletion process EU when the excess time OT is equal to or greater than a predetermined time, and the location information GL of vehicle 20A is greater than or equal to a predetermined distance from the return point SD. Figure 28 shows four vehicles 20: vehicles 20C, 20D, 20E, and 20F, which initiate the emergency deletion process EU based on conditions different from those of vehicle 20A. Figure 28 shows the location information GL of each vehicle 20 at time t when the excess time OT for the first share key KSA becomes equal to or greater than a predetermined time.

[0217] In this modification example, vehicle 20A is, for example, vehicle 20C shown in Figure 28. The end point SE of vehicle 20C is the return spot SP6, which is the return point SD. The circle CC shown by the dashed line in Figure 28 indicates a location a predetermined distance away from the return spot SP6. The location information GL of vehicle 20C is located outside of circle CC. In other words, the location information GL of vehicle 20C is more than the predetermined distance away from the return point SD. When these conditions are met, vehicle 20C initiates the emergency deletion process EU.

[0218] If the excess time OT exceeds the predetermined time, and the vehicle 20C is located more than the predetermined distance from the return point SD, it is highly likely that the first user UA has no intention of returning the vehicle 20C. According to the vehicle 20C, if it is highly likely that the first user UA has no intention of returning the vehicle 20C, the use of the vehicle 20C using the first share key KSA can be restricted.

[0219] Vehicle 20A may initiate emergency deletion processing EU when the excess time OT exceeds a predetermined time and the vehicle 20A's location information GL passes through multiple returnable locations SC. Vehicle 20A in this modification example is, for example, vehicle 20D shown in Figure 28. The end point SE of vehicle 20D is one of the five returnable points SC. Arrow CD shows the trajectory of vehicle 20D's location information GL from the start date and time of the restricted fade-out period FR to time t. As shown by arrow CD in Figure 28, vehicle 20D's location information GL passes through three returnable points SC: return spot SP1, return spot SP2, and return spot SP5. When these conditions are met, vehicle 20D initiates emergency deletion process EU.

[0220] If the excess time OT exceeds the predetermined time, and the vehicle has passed through multiple returnable points SC, it is highly likely that the first user UA has no intention of returning vehicle 20D. According to vehicle 20D, if it is highly likely that the first user UA has no intention of returning vehicle 20D, the use of vehicle 20D using the first share key KSA can be restricted.

[0221] Vehicle 20A may initiate emergency deletion processing EU when the vehicle's location information GL moves away from the end point SE, provided that the excess time OT is equal to or greater than the predetermined time and one of the returnable locations SC is designated as the end point SE. Vehicle 20A designates one of the returnable locations SC as the end point SE after the start of the limited fade-out period FR.

[0222] Vehicle 20A in this modification example is, for example, vehicle 20E shown in Figure 28. The end point SE of vehicle 20E is return spot SP4. Return spot SP4 is designated by vehicle 20E as the end point SE from among the five returnable locations SC after the start of the restricted fade-out period FR. The arrow CE shows the trajectory of vehicle 20E's location information GL from the start date and time of the restricted fade-out period FR to time t. Vehicle 20E's location information GL is moving away from return spot SP4, which was designated as the end point SE. When these conditions are met, vehicle 20E initiates emergency deletion process EU.

[0223] If the excess time OT exceeds the predetermined time, and the vehicle is moving away from the designated return point SC, it is highly likely that the first user UA has no intention of returning vehicle 20E. According to vehicle 20E, if it is highly likely that the first user UA has no intention of returning vehicle 20E, the use of vehicle 20E using the first share key KSA can be restricted.

[0224] Vehicle 20A may be configured to perform emergency deletion process EU when the overtime time OT is greater than or equal to a predetermined time, and the location information GL of vehicle 20A is outside the usage area AR, which is the area in which vehicle 20A is permitted to use.

[0225] In this modification example, vehicle 20A is, for example, vehicle 20F shown in Figure 28. As shown in Figure 28, the location information GL of vehicle 20F is located outside the usage area AR. When these conditions are met, vehicle 20F initiates emergency deletion process EU.

[0226] If vehicle 20F is located outside the usage area AR where vehicle 20F is permitted to be used, it is highly likely that the first user UA has no intention of returning vehicle 20F. According to vehicle 20F, if it is highly likely that the first user UA has no intention of returning vehicle 20F, the use of vehicle 20F using the first share key KSA can be restricted.

[0227] Furthermore, vehicle 20A may be configured to initiate emergency deletion process EU when the excess time OT exceeds a predetermined time. The first owner key KOV is registered to virtual device 40V. The first owner key KOV may also be the owner key KO registered to mobile device 40M. In other words, the first share key KSA may be the share key KS registered based on the owner key KO registered to mobile device 40M.

[0228] The first share key KSA does not have to be a friend key KF. The first share key KSA may be a non-friend key KN registered based on the friend key KF. The second share key KSB does not have to be a non-friend key KN. The second share key KSB may also be a friend key KF. Furthermore, any digital key other than the first share key KSA that is authenticated for vehicle 20A may be the first owner key KOV.

[0229] The first deletion process is the process that normally initiates the fade-out period FN. The first deletion process may also be a process that deletes the first share key KSA without initiating the fade-out period FN. In this case, when vehicle 20A initiates the first deletion process by executing step S214 shown in Figure 15, it immediately deletes the authentication information AT related to the first share key KSA.

[0230] Vehicle 20A may also start a restricted fade-out period FR in the third deletion process, similar to the second deletion process. That is, after setting the deletion flag EF to prohibited in step S431 of Figure 23, vehicle 20A may start a restricted fade-out period FR in step S432 of Figure 23. In this case, even during the fade-out period FO based on the third deletion request RQ3, vehicle 20A will not delete the first share key KSA until the use of vehicle 20A ends.

[0231] According to the example vehicle 20A, even if the deletion request RQ is the third deletion request RQ3, the effect of (1) can be achieved. • The AR usage area is not limited to municipalities within Japan. The AR usage area may be set at the prefectural level. The AR usage area may be set at the national level. The AR usage area may be set as a certain geographical area composed of multiple countries.

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

[0233] The personal digital assistant devices (PADs) Device 30 and PAD 40M are not limited to smartphones. They may also be smartwatches. The virtual device 40V can be configured to be included in a predetermined server, such as server 80. For example, the virtual device 40V may be included in the management server 70. Similarly, the friend device 51 may be included in a predetermined server.

[0234] Digital keys have a hierarchy consisting of Owner Key (KO), Friend Key (KF), and Non-Friend Key (KN), with higher levels granting greater privileges. However, digital keys do not necessarily have to have higher privileges at higher levels. For example, the same level of privileges may be set for all three levels: Owner Key (KO), Friend Key (KF), and Non-Friend Key (KN).

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

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

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

[0238] The authentication information AT is not limited to the examples of the above embodiment, 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, for example, the authentication information AT may be a common secret key.

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

[0240] The database (DB) may include information indicating the type of device 30. The type of device 30 may be, for example, information indicating one of the following: smartphone, smartwatch, and server.

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

[0242] In a database, permissions do not have to be uniformly defined according to the type of digital key; they may be set for each digital key. Furthermore, permissions may not be defined at all in a database.

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

[0244] • The matters concerning the digital key in the above embodiment do not have to comply with CCC. <Note> The technical concepts that can be understood from the above embodiments and modified examples are described below.

[0245] [Note 1] A digital key for a vehicle, comprising an owner key which is a digital key that is registered to the vehicle only once, and a share key which is a digital key that can be registered to the vehicle multiple times, comprising a digital key management system that manages the registration and deletion of the digital key for the vehicle, The system comprises an execution device, a storage device that stores information about the digital key registered in the vehicle, a management server that manages the registration and deletion of the digital key, and a communication device that can communicate with a device that stores information about the digital key. The execution device, when a request to delete a share key for which an expiration period has been set for the use of the vehicle using the share key is made based on the expiration of the expiration period of the share key, provides a first grace period to postpone the execution of the deletion of the share key, and the execution device determines, based on the location information of the vehicle, whether the termination process that permits the start of the share key deletion process was performed when the vehicle was stopped at a predetermined termination point which is the point where the use of the vehicle ends, The execution device, if it determines that the termination process was performed with the vehicle stopped at the termination point, starts the deletion process for the share key; if it does not determine that the termination process was performed with the vehicle stopped at the termination point, the vehicle does not delete the share key for which deletion has been postponed, even if a digital key other than the share key is authenticated to the vehicle.

[0246] [Note 2] The aforementioned end point is the vehicle specified in Note 1, which is the return point where the use of the vehicle ends, if such a return point has been predetermined. [Note 3] If there are multiple return locations where the use of the vehicle can be terminated, the termination location is one of the return locations specified in Note 1 or Note 2.

[0247] [Note 4] The execution device determines that the vehicle is stopped at the end point when the vehicle's location information is within a predetermined distance from the end point, according to any one of Notes 1 to 3.

[0248] [Note 5] The execution device determines that the vehicle is stopped at the end point when the vehicle's location information indicates that it has been stopped at the end point for a predetermined time or longer, according to any one of Notes 1 to 4.

[0249] [Note 6] The deletion process is a process that initiates a second grace period when a digital key other than the said share key is authenticated for the vehicle, and applies to any vehicle described in any one of Notes 1 to 5.

[0250] [Note 7] The vehicle described in any one of Notes 1 to 6, wherein the execution device provides a third grace period, from the time the deletion request is made until the digital key other than the share key is authenticated to the vehicle, in which case the execution device will not execute the deletion of the share key.

[0251] [Supplementary Note 8] The vehicle according to any one of Supplementary Notes 1 to 7, wherein when an excess time, which is an elapsed time from the start of the first grace period, reaches or exceeds a predetermined time, the execution device starts emergency deletion processing for deleting the share key triggered by the next end of operation of the vehicle.

[0252] [Supplementary Note 9] The vehicle according to Supplementary Note 8, wherein the execution device starts the emergency deletion processing when the excess time is equal to or longer than the predetermined time and position information of the vehicle is separated from the end point by a predetermined distance or more.

[0253] [Supplementary Note 10] The vehicle according to Supplementary Note 8 or 9, wherein the execution device starts the emergency deletion processing when the excess time is equal to or longer than the predetermined time and position information of the vehicle is moving away from the end point.

[0254] [Supplementary Note 11] The vehicle according to any one of Supplementary Notes 8 to 10, wherein the execution device starts the emergency deletion processing when the excess time is equal to or longer than the predetermined time and position information of the vehicle passes a plurality of returnable points that are points at which use of the vehicle can be ended.

[0255] [Supplementary Note 12] The vehicle according to any one of Supplementary Notes 8 to 11, wherein, in a case where the excess time is equal to or longer than the predetermined time, and after the start of the first grace period, any one of returnable points that are points at which use of the vehicle can be ended is designated as the end point, the execution device starts the emergency deletion processing when position information of the vehicle is moving away from the end point.

[0256] [Supplementary Note 13] The vehicle according to any one of Supplementary Notes 8 to 12, wherein the execution device executes the emergency deletion processing when the excess time is equal to or longer than the predetermined time and position information of the vehicle is outside a use area that is an area where use of the vehicle is permitted. Description of Reference Signs

[0257] 10…Management system 20, 20A, 20B, 20C, 20D, 20E, 20F… Vehicles 21… Wireless communication device 27… Execution device 28…Storage device 30…Device 70... Management Server 90…Network A6…Returnable area AR… Usage Area DK...Key Information EU… Emergency Deletion Process FN…Normal fade-out period FR... Restriction fade-out period GL…location information KO... Owner Key KOV…First Owner Key KS... Share Key KSA…1st Share Key KSB...2nd Share Key OT…Overtime RQ... Deletion request RQ1…First Deletion Request RQ2...Second deletion request RQ3... Third deletion request SC… Returnable locations SD... Return location SE... End point TP... Termination process VP... Validity period

Claims

1. A digital key management system is configured to manage the registration and deletion of a digital key for a vehicle, which is an owner key, which is a digital key that is registered to only one vehicle, and a share key, which is a digital key that can be registered to multiple vehicles, and the vehicle to which the digital key is registered, The system comprises an execution device, a storage device that stores information about the digital key registered in the vehicle, a management server that manages the registration and deletion of the digital key, and a communication device that can communicate with a device that stores information about the digital key. If the execution device receives a request to delete a share key for which an expiration period has been set for the use of the vehicle using the share key, based on the expiration of the expiration period of the share key, it shall provide a first grace period to postpone the execution of the deletion of the share key. The execution device determines, based on the location information of the vehicle, whether the termination process that permits the start of the share key deletion process was performed while the vehicle was stopped at the termination point, which is a predetermined point where the use of the vehicle ends. The execution device is If it is determined that the termination process was performed while the vehicle was stopped at the termination point, the deletion process for the share key will be initiated. If the termination process is not determined to have been performed while the vehicle was stopped at the termination point, the share key that has been granted a grace period for deletion will not be deleted, even if a digital key other than the share key is authenticated for the vehicle. vehicle.

2. The aforementioned termination point is the return point, if a return point is predetermined as the point where the use of the vehicle ends. The vehicle according to claim 1.

3. If there are multiple return locations where the vehicle can be returned, the end location is one of the return locations. The vehicle according to claim 1.

4. The execution device determines that the vehicle is stopped at the end point when the vehicle's location information is within a predetermined distance from the end point. The vehicle according to claim 1.

5. The execution device determines that the vehicle is stopped at the end point when the vehicle's location information indicates that it has been stopped at the end point for a predetermined time or longer. The vehicle according to claim 1.

6. The aforementioned deletion process is a process that initiates a second grace period, which deletes the share key when a digital key other than the share key is authenticated for the vehicle in question. The vehicle according to claim 1.

7. The execution device, if the deletion request is made based on a request from a digital key other than the share key, provides a third grace period during which it will postpone the deletion of the share key from the time the deletion request is made until the digital key other than the share key is authenticated for the vehicle. The vehicle according to claim 1.

8. When the excess time, which is the elapsed time from the start of the first grace period, exceeds a predetermined time, the execution device will initiate an emergency deletion process to delete the share key, triggered by the vehicle's operation ending. The vehicle according to any one of claims 1 to 7.

9. The execution device starts the emergency deletion process when the excess time is equal to or greater than a predetermined time, and the vehicle's location information is greater than or equal to a predetermined distance from the termination point. The vehicle according to claim 8.

10. The execution device starts the emergency deletion process when the excess time exceeds a predetermined time and the vehicle's location information moves away from the termination point. The vehicle according to claim 8.

11. The execution device starts the emergency deletion process when the excess time exceeds a predetermined time and the vehicle's location information passes through multiple returnable locations where the vehicle can be returned. The vehicle according to claim 8.

12. The execution device starts the emergency deletion process when the excess time exceeds a predetermined time, and after the start of the first grace period, it designates one of the returnable locations where the vehicle can be used to end its use as the termination point, and the vehicle's location information moves away from the termination point. The vehicle according to claim 8.

13. The execution device executes the emergency deletion process when the excess time exceeds a predetermined time and the vehicle's location information is outside the usage area, which is the area where the vehicle's use is permitted. The vehicle according to claim 8.

Images