Vehicle

Abstract

The present application relates to a vehicle. A master key and a shareable key as digital keys of the vehicle are registered in the vehicle. When it is determined that a termination process has been executed in a case where the vehicle is in a stopped state at a termination position, when a digital key other than the registered shareable key is authenticated, the vehicle starts a deletion process for the shareable key registered in the vehicle. When it is determined that the termination process has not been executed in a case where the vehicle is in a stopped state at a termination position, even if a digital key other than the registered shareable key is authenticated for the vehicle, the vehicle does not delete the registered shareable key for which deletion is postponed.

Description

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Japanese Patent Application No. 2025-031974, filed on February 28, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure pertains to vehicles. Background Technology

[0004] JP2024-001720 A discloses a digital key management system. The management system includes a vehicle, multiple devices, and a management server. In the management system, information related to digital keys is stored in both the vehicle and the devices, enabling the registration of digital keys in the devices. The management server is capable of communicating with both the devices and the vehicle. The management server manages the registration of digital keys. The term "digital key" encompasses both owner keys and shareable keys. The vehicle can be unlocked, locked, and started using the digital key registered in the device.

[0005] In the aforementioned management system, a user can register multiple shareable keys associated with the same vehicle, all originating from the owner's key. On the other hand, when use of the vehicle via a shareable key has been terminated, or when a shareable key has been incorrectly registered, it is desirable that the shareable key be removed from the owner's key. However, if shareable keys can always be deleted, the user possessing that shareable key may be unable to use the vehicle during operation due to the deletion. Summary of the Invention

[0006] This invention is provided to introduce, in a simplified form, a series of concepts further described in the detailed embodiments. This invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0007] In a general sense, a vehicle is configured to allow the registration of multiple digital keys. The digital keys include a single owner's key registered in the vehicle and one or more shareable keys that can be registered in the vehicle. The vehicle includes an execution device, a storage device configured to store information related to the digital keys registered in the vehicle, and a communication device configured to communicate with a management server configured to manage the registration and deletion of digital keys and with the device configured to store information related to the digital keys. The one or more shareable keys are configured to allow setting a validity period for vehicle use for each shareable key. The execution device is configured to set a first grace period during which deletion of a registered shareable key is postponed when a deletion request for the registered shareable key is made based on the expiration of the validity period of the registered shareable key registered in the vehicle and for which a validity period has been set. The execution device is configured to determine, based on the vehicle's location information, whether a termination process allowing the initiation of the deletion process for the registered shareable key has already been executed while the vehicle is stopped at a predetermined location where the use of the vehicle is to be terminated. The execution device is configured to initiate a deletion process for the registered shareable key when it is determined that a termination process has already been performed while the vehicle is stopped at the termination position. The execution device is also configured not to delete a registered shareable key whose deletion is pending if a termination process has not yet been performed while the vehicle is not stopped at the termination position, even if a digital key other than the registered shareable key has been authenticated for the vehicle.

[0008] Other features and aspects will be apparent from the following detailed description, drawings and claims. Attached Figure Description

[0009] Figure 1 This is a schematic diagram illustrating a digital key management system according to an embodiment.

[0010] Figure 2 It is shown Figure 1 The diagram shows the configuration of the vehicle.

[0011] Figure 3 It is shown Figure 1 The diagram shows the configuration of the vehicle owner's equipment.

[0012] Figure 4 It is shown as in Figure 1 The diagram shows the configuration of the vehicle owner's device in a virtual machine implemented on the server.

[0013] Figure 5 yes Figure 1 The diagram shows the configuration of a friend's device.

[0014] Figure 6 It is shown Figure 1 The diagram shows the configuration of the guest equipment.

[0015] Figure 7 It is shown Figure 1 The diagram shows the configuration of the management server.

[0016] Figure 8 Is it showing stored Figure 3 The diagram shows the owner's key information in the owner's device.

[0017] Figure 9 Is it showing stored Figure 5 and Figure 6 A schematic diagram of the shareable key information in each of the shareable devices shown.

[0018] Figure 10 It is shown Figure 7 The diagram shows the data in the database of the management server.

[0019] Figure 11 When the vehicle owner's device is a portable information terminal, it is... Figure 1 The diagram shows the sequence of the vehicle owner key registration process executed by the management system.

[0020] Figure 12 When the vehicle owner's device is a virtual machine, it is... Figure 1 The diagram shows the sequence of the vehicle owner key registration process executed by the management system.

[0021] Figure 13 It is by Figure 1 The sequence diagram shown illustrates the friend key registration process executed by the management system.

[0022] Figure 14 It is by Figure 1 The diagram shows a sequence of events for the visitor key registration process performed by the management system.

[0023] Figure 15 It shows when Figure 1 The flowchart shows the process of deleting a vehicle that can be used with a shared key.

[0024] Figure 16 It shows when in Figure 1 The diagram shows a sequence of events in the management system when a first deletion request is made.

[0025] Figure 17 It shows when in Figure 1 The diagram shows a sequence of events in the management system when a second deletion request is made.

[0026] Figure 18 It shows when in Figure 1 The diagram shows the sequence of the process when a third deletion request is made in the management system.

[0027] Figure 19 It is shown Figure 1 A schematic diagram showing the positional relationship between the vehicle's return position and the permitted return position.

[0028] Figure 20 yes Figure 19 An enlarged schematic diagram of the area surrounding the return location shown.

[0029] Figure 21 It is shown Figure 15 The flowchart shows the details of the first deletion process.

[0030] Figure 22 It is shown Figure 15 The flowchart shows the details of the second deletion process.

[0031] Figure 23 It is shown Figure 15 The flowchart shows the details of the third deletion process.

[0032] Figure 24 It is shown in the form of Figure 1 The sequence diagram of the process executed by the management system for the deletion of the first shareable key, from the start of the process until immediately preceding the authentication of the second shareable key.

[0033] Figure 25 It is shown in the form of Figure 1 The sequence diagram of the process executed by the management system for the deletion of the first shareable key, from the authentication of the second shareable key until immediately preceding the transmission of the key deletion request.

[0034] Figure 26 It is shown in the form of Figure 1 The sequence diagram of the process executed by the management system for the deletion of the first shareable key, from the transmission of the key deletion request to the end of the process.

[0035] Figure 27 It shows when the vehicle is in Figure 22 The flowchart shown illustrates the process of performing an emergency deletion procedure during the phased exit period of the restriction.

[0036] Figure 28 It shows when in Figure 27 The diagram shown illustrates the movement of a key-shared vehicle during an emergency deletion process.

[0037] Throughout the accompanying drawings and detailed description, the same reference numerals refer to the same elements. The drawings may not be drawn to scale, and for clarity, illustration, and convenience, the relative dimensions, scale, and depiction of elements in the drawings may be exaggerated. Detailed Implementation

[0038] This specification provides a complete understanding of the described methods, apparatus, and / or systems. Modifications and equivalents of the described methods, apparatus, and / or systems will be readily apparent to those skilled in the art. The sequence of operations is exemplary and, as will be apparent to those skilled in the art, can be altered, except for operations that must occur in a specific order. Descriptions of functions and constructions well-known to those skilled in the art may be omitted.

[0039] Exemplary embodiments may take different forms and are not limited to the described examples. However, the described examples are thorough and complete and convey the full scope of this disclosure to those skilled in the art.

[0040] In this specification, "at least one of A and B" should be understood to mean "only A, only B, or both A and B".

[0041] Now refer to the appendix Figures 1 to 28 A digital key management system 10 according to an embodiment is described.

[0042] The standard for digital keys has been established by the Automotive Connectivity Consortium (CCC). The digital key functionality in this embodiment conforms to the standard established by the CCC.

[0043] Overview of Management System 10

[0044] like Figure 1 As shown, the management system 10 includes multiple vehicles 20, multiple devices 30, a device server 60, a management server 70, and a server 80. The vehicles 20, 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.

[0045] like Figure 2 As shown, each vehicle 20 includes a wireless communication device 21, a human-machine interface (HMI) 22, a Bluetooth Low Energy (BLE) module 23, an ultra-wideband (UWB) module 24, a near-field communication (NFC) module 25, and a vehicle management device 26.

[0046] Wireless communication device 21 communicates wirelessly with management server 70 via network 90. ​​HMI 22 includes input devices that receive input operations performed by the user of vehicle 20 and output devices that present information to the user. Output devices are, for example, monitors and speakers.

[0047] BLE module 23 performs short-range wireless communication with device 30 via BLE communication. UWB module 24 performs short-range wireless communication with device 30 via UWB communication. UWB module 24 measures the distance between device 30 and vehicle 20. NFC module 25 performs short-range wireless communication with device 30 via NFC communication. BLE module 23, UWB module 24, and NFC module 25 are all proximity communication devices. Vehicle management device 26 is installed on vehicle 20. Vehicle management device 26 manages the digital key of vehicle 20. Vehicle management device 26 is, for example, a digital key ECU. Vehicle management device 26 includes execution device 27 and storage device 28. Execution device 27 is a processing circuit including one or more processors that execute various processes according to a computer program (software). Storage device 28 stores vehicle program PV, authentication information AT, deletion program PE, device deletion information DE, and vehicle history information HC.

[0048] The vehicle program PV enables the execution device 27 to store and delete authentication information AT. Authentication information AT is information related to the digital key. Specifically, authentication information AT is information used to authenticate the digital key, enabling the digital key to control the vehicle 20 when it is used. Authentication information AT is provided for each digital key to be authenticated. The execution device 27 includes a CPU. The execution device 27 executes the vehicle program PV to perform processes related to the storage and deletion of authentication information AT.

[0049] The deletion procedure PE enables the execution device 27 to initiate the deletion of the digital key. The deletion procedure PE enables the execution device 27 to determine, based on device deletion information DE and vehicle history information HC, whether the authentication information AT stored in the vehicle 20 can be deleted. Device deletion information DE is information related to the conditions for deleting the digital key. Device deletion information DE includes, for example, a deletion flag EF indicating whether deletion of the authentication information AT associated with each digital key is permitted. Vehicle history information HC is information related to the usage status of the vehicle 20 when using the vehicle 20 with the aid of the digital key. Vehicle history information HC includes, for example, information related to the location information GL of the vehicle 20 at each point in time.

[0050] Vehicle 20 includes a locking mechanism 29A, an engine 29B, and a positioning device 29C. The locking mechanism 29A locks and unlocks the doors of vehicle 20. Engine 29B is an internal combustion engine. Vehicle 20 may include a hybrid powertrain instead of engine 29B. Positioning device 29C acquires the location information GL of vehicle 20 via wireless communication with satellites. Positioning device 29C acquires the location information GL of vehicle 20 using, for example, a Global Positioning System (GPS).

[0051] like Figure 1As shown, the multiple devices 30 include a vehicle owner device 40 and a shareable device 50. The shareable device 50 includes a friend device 51 and a guest device 52. The devices 30 include not only portable information terminals such as smartphones, but also virtual machines implemented on a server 80.

[0052] The vehicle owner device 40 can be a portable device 40M or a virtual device 40V. The portable device 40M is the vehicle owner device 40 functioning as a portable information terminal. The virtual device 40V is the vehicle owner device 40 functioning as a virtual machine.

[0053] like Figure 3 As shown, the portable 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 a network 90. ​​The HMI 32 includes an input device that receives input operations performed by a user of the portable device 40M and an output device that presents information to the user. Output devices may include, for example, a monitor and a speaker.

[0054] BLE module 33 performs short-range wireless communication with vehicle 20 via BLE communication. UWB module 34 performs short-range wireless communication with vehicle 20 via UWB communication. NFC module 35 performs short-range wireless communication with vehicle 20 via NFC communication. All three modules—BLE 33, UWB 34, and NFC 35—are proximity communication devices.

[0055] Storage device 37 stores device program PD and key information DK. Device program PD enables device 36 to store and delete key information DK. Key information DK is information indicating the digital key.

[0056] The device program PD includes, for example, a device application and a digital key framework. The device application is used to store and delete key information DK. The digital key framework is a program that provides pairing functionality for device 30 and sharing of digital keys using APIs prepared in the OS. The execution device 36 executes the device program PD to perform processes related to the storage and deletion of key information DK. The execution device 36 is a processing circuit that includes one or more processors that execute various processes according to a computer program (software).

[0057] Key information DK is information indicating the digital key. Owner device 40 stores owner key information DKO, which indicates the owner key KO as key information DK. Owner key KO is a digital key, and only one owner key KO can be registered for each vehicle 20. Therefore, only one owner key KO exists for a vehicle 20. Owner device 40 is the device 30 belonging to the owner of vehicle 20.

[0058] like Figure 4 As shown, the virtual device 40V includes 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 included in the virtual device 40V can be virtual components of designated areas of the wireless communication device 31, execution device 36, and storage device 37 using the server 80. The storage device 37 stores a device program PD, key information DK, and a list of shareable keys LS. The execution device 36 executes the device program PD to perform processes related to the storage and deletion of key information DK. The execution device 36 is a processing circuit that includes one or more processors that execute various processes according to a computer program (software). The virtual device 40V also stores owner key information DKO, indicating the owner key KO as key information DK, similar to the portable device 40M. The list of shareable keys LS will be described later.

[0059] like Figure 5 and Figure 6 As shown, each of the shareable devices 50 stores shareable key information DKS that indicates a shareable key KS as key information DK. The shareable device 50 is a device 30 other than the owner device 40. The shareable key KS is a digital key, and multiple shareable keys KS can be registered for each vehicle 20. That is, multiple shareable keys KS can be associated with a single vehicle 20, thus allowing multiple shareable keys KS to be used with the same vehicle 20.

[0060] The friend's device 51 included in the shareable device 50 is, for example, a portable information terminal such as a smartphone. Figure 5 As shown, the friend device 51, like the portable 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 as processing circuitry, and a storage device 37. The storage device 37 stores a device program PD, key information DK, and shareable key information DKS. In the friend device 51, the key information DK is the friend key information DKF indicating the friend key KF.

[0061] Guest device 52, included in the shareable device 50, is, for example, a portable information terminal such as a smartphone. Figure 6 As shown, the visitor device 52, like the portable 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 as processing circuitry, and a storage device 37. The storage device 37 stores the device program PD, key information DK, and shareable key information DKS. In the visitor device 52, the key information DK is the visitor key information DKN indicating the visitor key KN.

[0062] The types of shareable keys KS include friend keys KF and visitor keys KN. A friend key KF is a shareable key KS that has been registered based on a direct registration request D31 from the vehicle owner's device 40, as described later. A visitor key KN is a shareable key KS that has been registered based on a registration request D41 from a friend's device 51, as described later. A visitor key KN is a shareable key KS that has been registered based on a registration request D41 from another device 30 instead of a direct registration request D31 from the vehicle owner's device 40. In other words, a visitor key KN refers to a shareable key KS that is not a friend key KF.

[0063] Management server 70 manages digital keys. (For example...) Figure 7 As shown, the management server 70 includes an execution device 71, a storage device 72, and a wireless communication device 73. The execution device 71 is a processing circuit that includes one or more processors that execute various processes according to a computer program (software). The wireless communication device 73 communicates wirelessly with the device 30, the vehicle 20, and the server 80. The storage device 72 stores a server program PS, a time-segment management program PT, and a database DB. The server program PS causes the execution device 71 to register digital keys in the database DB and delete digital keys from the database DB. The time-segment management program PT causes the execution device 71 to manage the validity period VP of the shareable key KS, which will be described later.

[0064] Figure 1 The device server 60 shown relays communication between the device 30, which is a portable information terminal, and the management server 70. Figure 1 Only one device server 60 is shown. However, a separate device server 60 can be provided for each type of device 30. That is, the device server 60 used to communicate with the first type of device 30 can be different from the device server 60 used to communicate with the second type of device 30. For example, type can refer to the model of device 30, and a separate device server 60 can be provided for each model of device 30. In another example, type can refer to the communication line used by device 30, and a separate device server 60 can be provided for each type of communication line.

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

[0066] The registered state of the digital key refers to the state in which the digital key can be used. In the registered state, vehicle 20 stores authentication information AT, and device 30 stores key information DK. When vehicle management device 26 authenticates the digital key, it uses the authenticated digital key to enable control of vehicle 20. For example, during digital key authentication, vehicle management device 26 controls locking mechanism 29A to enable unlocking of vehicle 20. In another example, during digital key authentication, vehicle management device 26 controls engine 29B to enable starting of vehicle 20.

[0067] Configuration of information related to digital keys

[0068] like Figure 8 As shown, the Owner Key Information (DKO) includes the 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).

[0069] Vehicle identification information ST1 is information that identifies the vehicle 20 for which a digital key has been set. For example, vehicle identification information ST1 can be the ID of vehicle 20.

[0070] The device key identification information ST2 is used to manage the digital keys in device 30. The device key identification information ST2 is information that identifies the digital keys used in the application of device 30.

[0071] Digital key identification information ST3 is used for the management of digital keys in management server 70. Slot identification information ST4 is information that locally identifies the digital key within device 30.

[0072] Certificate information ST5 indicates the certificate for authenticating the digital key. Device public key information ST6 indicates the device public key PKD, which is the public key of device 30. The device public key PKD in the owner key information DKO indicates the public key of the owner device 40. Vehicle public key information ST7 indicates the vehicle public key PKV, which is the public key of vehicle 20. Authorized public key information ST8 indicates the authorized vehicle public key PKV.

[0073] like Figure 9As shown, the Shareable Key Information (DKS) includes Shareable Key Structure Information (STS) and Authentication Package (ATP). The Shareable 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 Shareable Key Structure Information (STS) includes Certificate Information (ST5), Vehicle Public Key Information (ST7), and Authorization Public Key Information (ST8). The Shareable Key Structure Information (STS) is obtained by removing Device Public Key Information (ST6) from the Owner Key Structure Information (STO).

[0074] The Authentication Package (ATP) includes signature information (ATP1), password information (ATP2), validity start time information (ATP3), validity end time information (ATP4), name information (ATP5), and device public key information (ATP6).

[0075] The signature information ATP1 indicates that the shareable device 50 is an authorized entity used to receive the digital key. For example, in the case of friend device 51, the signature information ATP1 indicates the signature of the owner device 40. The signature information ATP1 of friend device 51 indicates that the owner device 40 has signed the device public key PKD of friend device 51 as indicated by the device public key information ATP6. For example, in the case of guest device 52, the signature information ATP1 indicates the signature of friend device 51. The friend signature information indicates that friend device 51 has signed the device public key PKD of guest device 52 as indicated by the device public key information ATP6.

[0076] Password information ATP2 indicates the pairing password PAS used to establish a secure channel during pairing between vehicle 20 and owner equipment 40. Validity start time information ATP3 indicates the earliest date and time the shareable key KS becomes valid and available for use. Validity end time information ATP4 indicates the latest date and time the shareable key KS remains valid and available for use. Name information ATP5 indicates the name used to identify the shareable key KS. For example, name information ATP5 is set to the identifiable name of each of the shareable devices 50, for example, through operation from owner equipment 40.

[0077] Figure 7 The database DB shown includes the following information: for each digital key, a corresponding vehicle 20 is associated with a registered device 30. Data DA contained in the database DB is organized on a vehicle-by-vehicle basis. When a digital key is registered, the management server 70 stores information as data DA indicating the device 30 storing key information DK, which in turn indicates the digital key. The management server 70 manages the digital keys by storing information related to the digital keys as data DA in the database DB.

[0078] like Figure 10 As shown, the data DA of a vehicle 20 includes information related to the type of digital key registered in the vehicle 20, the registered device 30, and the relationship between the registered devices 30. Digital keys are categorized into multiple hierarchical levels according to their respective types. From highest to lowest in the hierarchy, digital keys are ordered as owner key KO, friend key KF, and visitor key KN. Digital keys at higher hierarchical levels are assigned greater permissions.

[0079] Permissions include, for example, the number of shareable keys KS that can be requested for registration, and the scope of control over vehicle 20 enabled through digital key authentication. Digital keys at higher levels are permitted to request registration of a larger number of shareable keys KS. Specifically, for example, the number of friend keys KF that owner device 40 is permitted to request for registration is greater than the number of visitor keys KN that friend device 51 is permitted to request for registration.

[0080] Furthermore, as the level of the digital key increases, the scope of control permitted over vehicle 20 also increases. The scope of control over vehicle 20 refers to a set of controllable functions, such as starting control of the engine 29B of vehicle 20, power control of vehicle 20, and unlocking and locking control of the door locking mechanism 29A of vehicle 20. For example, when the scope of control over vehicle 20 includes all three of the aforementioned functions, the scope of control is wider than when it only includes unlocking and locking control of the door locking mechanism 29A of vehicle 20. Specifically, the scope of control over vehicle 20 permitted by the friend key KF includes all three of the aforementioned functions, while the scope of control permitted by the visitor key KN is limited to unlocking and locking control of the door locking mechanism 29A of vehicle 20.

[0081] A scenario will now be described in which digital keys are registered for seven devices 30 for a vehicle 20. The seven devices 30 are devices 30A through 30G. The digital keys registered in devices 30A through 30G are keys 1 through 7 respectively.

[0082] The device 30 where the owner's key KO is registered as a digital key is the first device 30A. In other words, the first device 30A is the owner's device 40. Therefore, the first digital key is the owner's key KO.

[0083] The devices 30 that have the shared key KS registered as a digital key are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. 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 shared devices 50. In other words, all seven keys are shared keys KS.

[0084] Specifically, the friend key KF is registered as a shared key KS on devices 30, namely the second device 30B and the fifth device 30E. In other words, the second device 30B and the fifth device 30E are friend devices 51. The guest key KN is registered as a shared key KS on devices 30, namely the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. In other words, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are guest devices 52.

[0085] The relationships between the devices 30 included in the data DA will now be described. The relationship between the second device 30B and the first device 30A is such that a friend key KF has been registered in the second device 30B in response to a registration request from the first device 30A. In other words, the second digital key is registered based on the first digital key. The relationship between the fifth device 30E and the first device 30A is such that a friend key KF has been registered in the fifth device 30E in response to a registration request from the first device 30A. In other words, the fifth digital key is registered based on the first digital key.

[0086] The relationship between the third device 30C and the second device 30B ensures that a visitor key KN has been registered in the third device 30C in response to a registration request from the second device 30B. In other words, the third digital key is registered based on the second digital key. Similarly, in data DA, the relationship between the fourth device 30D and the second device 30B ensures that a visitor key KN has been registered in the fourth device 30D in response to a registration request from the second device 30B. In other words, the fourth digital key is registered based on the second digital key.

[0087] The relationship between the sixth device 30F and the fifth device 30E ensures that a visitor key KN has been registered in the sixth device 30F in response to a registration request from the fifth device 30E. In other words, the sixth digital key is registered based on the fifth digital key. The relationship between the seventh device 30G and the fifth device 30E ensures that a visitor key KN has been registered in the seventh device 30G in response to a registration request from the fifth device 30E. In other words, the seventh digital key is registered based on the fifth digital key.

[0088] As described above, the Data DA includes information related to the device 30 to which the digital key has been registered. In the Data DA, each registered device 30 is associated with information indicating the device 30 that initiated the registration request. The Data DA also includes information indicating the digital key on which the registration of each digital key is based.

[0089] Digital key registration

[0090] Next, a series of processes for registering digital keys in the management system 10 will be described. Digital key registration includes the registration of the owner key KO, the friend key KF, and the visitor key KN. 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. Subsequently, 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 visitor key KN in the third device 30C will be described. In the following description, the processes performed by the execution device 27 of the vehicle 20 are described as processes performed by the vehicle 20. The processes performed 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 performed by the portable device 40M and the virtual device 40V. The processes performed 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 performed 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.

[0091] Register the car owner's key in a portable device 40M KO

[0092] like Figure 11 As shown, the management system 10 executes a series of processes for registering the owner key KO of the vehicle 20 in the portable device 40M. The portable device 40M registers the owner key KO by using proximity communication with the vehicle 20.

[0093] In the management system 10, the owner key information DKO, which serves as the key information DK indicating the owner key KO of vehicle 20, is stored in the portable device 40M by registering the owner key KO. In the management system 10, the authentication information AT used to authenticate the owner key KO is stored in vehicle 20. When the owner key KO is authenticated by vehicle 20 and registered in the management server 70, the owner key KO can be used to control vehicle 20.

[0094] When the management server 70 receives a registration start request D11 for the owner key KO from the portable device 40M, the registration process for the owner key KO is initiated. The registration start request D11 includes information indicating that the owner device 40 to which the owner key KO is registered is the portable device 40M.

[0095] In step S111, the management server 70 generates a pairing password PAS for pairing the portable device 40M with the vehicle 20. Thereafter, the management server 70 sends information indicating the pairing password PAS to the portable device 40M using the wireless communication device 73. The management server 70 then uses the wireless communication device 73 to send a registration request D12 to the vehicle 20, including information indicating the pairing password PAS.

[0096] Upon receiving registration request D12, vehicle 20 activates the devices required 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 a digital key ECU included in the vehicle management device 26. By activating these devices, vehicle 20 is able to wait for and perform authentication of the digital key using the proximity communication device.

[0097] Next, in step S113, when the owner of vehicle 20 approaches vehicle 20 with a portable device 40M that has received the pairing password PAS, a proximity communication device is used to perform pairing between vehicle 20 and portable device 40M. The proximity communication device used for pairing can be at least one of BLE module 23, UWB module 24, and NFC module 25. At this time, pairing is completed when the authentication of portable device 40M relative to vehicle 20 is successful using the pairing password PAS of portable device 40M and vehicle 20. When pairing is complete, a secure channel for data communication between vehicle 20 and portable device 40M is established using the proximity communication device. Vehicle 20 then proceeds to step S114. From this point onward, communication between vehicle 20 and portable device 40M is conducted via this secure channel until the registration of the owner's key KO is completed.

[0098] In step S114, vehicle 20 generates a vehicle public key PKV, which serves as the public key of vehicle 20, and a vehicle private key SKV, which serves as the private key of vehicle 20. Next, vehicle 20 sends generation data DC, used to generate the owner key KO, to portable device 40M via a secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information ST7 indicating the vehicle public key PKV. Upon receiving the generation data DC, portable device 40M proceeds the process to step S115.

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

[0100] Upon receiving certificate information ST5 and device public key information ST6, vehicle 20 executes step S117. In step S117, vehicle 20 verifies certificate information ST5. When the verification of certificate information ST5 is complete, vehicle 20 proceeds to step S118.

[0101] In step S118, vehicle 20 stores the device public key information ST6, which indicates the device public key PKD, in storage device 28 as authentication information AT. Subsequently, vehicle 20 sends an authentication completion notification D13 to portable device 40M, indicating that the storage of authentication data AT has been completed.

[0102] Upon receiving the authentication completion notification D13, the portable device 40M executes step S119. In step S119, the portable device 40M generates a key status update request D14 for the vehicle owner key KO. The key status update request D14 is a signal used to request the management server 70 to update the database DB. The portable device 40M sends the key status update request D14 for the vehicle owner key KO to the management server 70 via the device server 60.

[0103] Upon receiving the key status update request D14, the management server 70 executes step S120. In step S120, the management server 70 performs registration management of the vehicle owner key KO. Specifically, the management server 70 stores in the database DB the fact that the device 30 in which the vehicle owner key KO is registered is a portable device 40M as data DA for the vehicle 20. As a result, the management system 10 terminates the series of processes used to register the vehicle owner key KO of the vehicle 20 in the portable device 40M.

[0104] Register the car owner's key in the virtual device 40V KO

[0105] like Figure 12 As shown, the management system 10 executes a series of processes for registering the owner key KO of vehicle 20 in the virtual device 40V. The virtual device 40V registers the owner key KO using wireless communication without performing proximity communication with vehicle 20.

[0106] In the management system 10, the owner key information DK, which serves as the key information for the owner key KO of vehicle 20, is stored in the virtual device 40V by registering the owner key KO. In the management system 10, the authentication information AT used to authenticate the owner key KO is stored in vehicle 20. When the owner key KO is authenticated by vehicle 20 and registered in the management server 70, the owner key KO can be used to control vehicle 20.

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

[0108] In step S121, the virtual device 40V generates owner key information DKO indicating 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. The authentication request D22 includes owner key authentication information DKA, and the owner key authentication information DKA includes information corresponding to certificate information ST5 associated with the owner key KO and device public key information ST6 indicating the device public key PKD.

[0109] Subsequently, upon receiving authentication request D22, management server 70 uses wireless communication device 73 to send registration request D23 to vehicle 20. 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.

[0110] Upon receiving registration request D23, vehicle 20 activates the devices required for authenticating the owner key KO using wireless communication device 21 in step S123. These devices include, for example, wireless communication device 21 and digital key ECU included in vehicle management device 26. By activating these devices, vehicle 20 is able to wait for and use wireless communication device 21 to perform authentication of the digital key.

[0111] Next, the management server 70, which has already sent registration request D23, uses wireless communication device 73 to send an authentication start request D24 to vehicle 20 for the owner key KO, which includes owner key authentication information DKA. Upon receiving authentication start request D24, vehicle 20 proceeds to step S124 to initiate authentication of the owner key KO.

[0112] In step S124, vehicle 20 verifies the owner key authentication information DKA. When the verification of the information corresponding to the certificate information ST5 included in the owner key authentication information DKA is completed, vehicle 20 proceeds the process to step S125.

[0113] In step S125, vehicle 20 stores the device public key information ST6 corresponding to the device public key PKD as authentication information AT. Subsequently, vehicle 20 uses wireless communication device 21 to send an authentication completion notification D25 to management server 70. The authentication completion notification D25 indicates that the storage of authentication information AT has been completed.

[0114] Upon receiving the authentication completion notification D25, the management server 70 executes step S126. In step S126, the management server 70 performs registration management for the vehicle owner key KO. Specifically, the management server 70 stores in the database DB the fact that the device 30 in which the vehicle owner key KO is registered is the virtual device 40V as data DA for the vehicle 20. As a result, the management system 10 terminates the series of processes used to register the vehicle owner key KO in the virtual device 40V.

[0115] Registration for Friend Key KF

[0116] like Figure 13 As shown, the management system 10 executes a series of processes to register the friend key KF. When the vehicle owner device 40 is a virtual device 40V, the friend key KF registration process is as follows. In the device 30 that does not store friend key information DKF, the management system 10 will designate the device 30 that is designated as friend device 51 as the second device 30B through this series of processes.

[0117] When the operation to request registration of the friend key KF is performed in the virtual device 40V, the virtual device 40V first executes the process of step S131. In step S131, the virtual device 40V sends a registration request D31 for the friend key to a relay server (not shown). After that, the virtual device 40V advances the process to step S132.

[0118] 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 sharing information SH1 required to share the digital key. The virtual device 40V then sends invitation information IV1 to the second device 30B.

[0119] Subsequently, upon receiving invitation information IV1, the second device 30B executes step S133. In step S133, the second device 30B obtains the shared information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the shared information SH1 from the source of the URL link.

[0120] The shared information SH1 includes, for example, shareable key structure information STS, password information ATP2, validity start time information ATP3, validity end time information ATP4, and name information ATP5. The validity start time information ATP3, validity end time information ATP4, and name information ATP5 are configured by the virtual device 40V. Thereafter, the second device 30B advances the process to step S134.

[0121] In step S134, the second device 30B generates an unsigned friend key information DKFN using the shared information SH1. The unsigned friend key information DKFN is a friend key information DKF without the signature information ATP1. Specifically, the second device 30B generates each piece of information contained in the acquired shared information SH1 as an individual element of the unsigned friend key information DKFN. Subsequently, the second device 30B sends a completion notification D32A to the virtual device 40V, indicating that the upload of the generated unsigned friend key information DKFN to the URL link has been completed. The second device 30B also sends a signature request D32B to the virtual device 40V.

[0122] 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 visitor friend information DKFN. Upon receiving the signature request D32B, the vehicle owner device 40 executes step S135.

[0123] In step S135, the virtual device 40V generates signature information ATP1. Specifically, the virtual device 40V generates signature information ATP1 after verifying that the obtained unsigned friend key information DKFN is correct. Afterward, the virtual device 40V proceeds the process to step S136.

[0124] In step S136, the virtual device 40V generates friend key information DKF by adding signature information ATP1 to unsigned friend key information DKFN. The virtual device 40V uploads the generated friend key information DKF to the URL link, which is invitation information IV1. The virtual device 40V sends a completion notification D33 to the second device 30B, indicating that the upload of the completed friend key information DKF to the URL link is complete.

[0125] Upon receiving the completion notification D33, the second device 30B executes step S137. In step S137, the second device 30B stores the friend key information DKF by downloading it. As a result, the second device 30B becomes the friend device 51. Afterward, the second device 30B advances the process to step S138.

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

[0127] Upon receiving a key status update request D34 for a friend's key KF, the management server 70 executes step S139. In step S139, the management server 70 performs registration management for the friend's key KF.

[0128] Specifically, management server 70 checks if the friend key KF, which is the subject of key status update request D34, is listed in the revocation list. The revocation list is a list indicating which shareable keys KS (including friend key KF and visitor key KN) have received deletion requests. If friend key KF is listed in the revocation list, management server 70 sends a notification to second device 30B indicating that it cannot respond to key status update request D34.

[0129] On the other hand, when a friend key KF that has received a key status update request D34 is not listed in the revocation list, the management server 70 registers the information of the friend key KF that has received the key status update request D34 in the database DB. The management server 70 stores the friend key information DKF of the friend key KF that has received the key status update request D34 in the database DB. The management server 70 stores information in the database DB indicating that the device 30 registered as friend device 51 is the second device 30B. The management server 70 stores the relationship between the second device 30B and the virtual device 40V by referring to the obtained friend key information DKF. Specifically, the management server 70 stores the fact that the second device 30B is a device 30 that has registered a friend key KF in response to the registration request D31 from the virtual device 40V.

[0130] Subsequently, management server 70 sends the authentication packet ATP, which is part of the friend key information DKF, along with storage request D35 requesting storage of the authentication packet ATP to vehicle 20. That is, management server 70 sends the device public key information ST6, instructing friend device 51 to use its device public key PKD, to vehicle 20. Management server 70 notifies vehicle 20 that the device public key PKD has been signed by virtual device 40V.

[0131] Subsequently, upon receiving the storage request D35 and the authentication packet ATP from the management server 70, vehicle 20 executes step S140. In step S140, vehicle 20 stores the received authentication packet ATP as authentication information AT used to authenticate the friend key KF.

[0132] After completing the registration management, the management server 70 sends a key status update completion notification D36 to the second device 30B.

[0133] Upon receiving the key status update completion notification D36, the second device 30B executes step S141. During step S141, the second device 30B presents information indicating the completion of registration for the friend key KF on the HMI 32. For example, the second device 30B displays an image on the HMI 32 indicating the completion of registration for the friend key KF. As a result, the management system 10 terminates the series of processes used to register the friend key KF.

[0134] When the vehicle owner device 40 is a portable device 40M, the process in step S135 differs from the case when the vehicle owner device 40 is a virtual device 40V. In the case where the vehicle owner device 40 is a portable device 40M, the portable device 40M generates the signature information ATP1 in the following manner.

[0135] The vehicle owner device 40 causes the HMI 32 of the portable device 40M to present the obtained unsigned friend key information DKFN, and accepts an operation indicating that the user of the portable device 40M has agreed to register the friend key KF. Upon receiving this operation, the portable device 40M obtains a signature based on the operation. Thereafter, the portable device 40M advances the process to step S136.

[0136] Registration of visitor key KN

[0137] like Figure 14 As shown, the management system 10 performs a series of processes to register the visitor key KN. In the device 30 where the visitor key information DKN is not stored, the management system 10 designates the device 30 that is to be designated as the visitor device 52 through this series of processes as the third device 30C.

[0138] When the operation to request registration of the guest key KN is performed in the friend device 51, the friend device 51 first executes the process of step S151. In step S151, the friend device 51 sends a registration request D41 for the guest key KN to the relay server (not shown). After that, the friend device 51 advances the process to step S152.

[0139] In step S152, the friend device 51 obtains invitation information IV2 for sharing the digital key from the relay server. Invitation information IV2 is, for example, a URL link. The URL link contains sharing information SH2 required to share the digital key. Afterward, the friend device 51 sends invitation information IV2 to the third device 30C.

[0140] Subsequently, upon receiving invitation information IV2, the third device 30C executes step S153. In step S153, the third device 30C obtains the shared information SH2 based on the invitation information IV2. Specifically, the third device 30C downloads the shared information SH2 from the URL link.

[0141] The shared information SH2 includes, for example, shareable key structure information STS, password information ATP2, validity start time information ATP3, validity end time information ATP4, and name information ATP5. The validity start time information ATP3, validity end time information ATP4, and name information ATP5 are configured by the friend device 51. Thereafter, the third device 30C advances the process to step S154.

[0142] In step S154, the third device 30C uses the shared information SH2 to generate unsigned visitor key information DKNN. The unsigned visitor key information DKNN is a visitor key information DKN without signature information ATP1. Specifically, the third device 30C generates each piece of information included in the acquired shared information SH2 as each piece of information in the unsigned visitor key information DKNN. Subsequently, the third device 30C sends a completion notification D42A to the friend device 51, indicating that the upload of the generated unsigned visitor key information DKNN to the URL link has been completed. The third device 30C also sends a signature request D42B to the friend device 51.

[0143] 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 visitor key information DKNN. When the friend device 51 receives the signature request D42B, it is operated to execute the process of step S155.

[0144] In step S155, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 causes the HMI 32 to present the obtained unsigned guest key information DKNN and accepts an operation indicating that the user of the friend device 51 has agreed to register the guest key KN. Upon receiving this operation, the friend device 51 obtains a signature based on the operation. Afterward, the friend device 51 proceeds the process to step S156.

[0145] In step S156, the friend device 51 adds the signature information ATP1 to the unsigned visitor key information DKNN to generate visitor information DKN. The friend device 51 uploads the generated visitor key information DKN to the URL link, which is the invitation information IV2. The friend device 51 sends a completion notification D43 to the third device 30C, indicating that the upload of the completed visitor key information DKN to the URL link is complete.

[0146] Upon receiving the completion notification D43, the third device 30C executes step S157. In step S157, the third device 30C downloads and stores the visitor key information DKN. As a result, the third device 30C becomes the visitor device 52. Thereafter, the third device 30C advances the process to step S158.

[0147] In step S158, the third device 30C generates a key status update request D44 for the visitor key KN. The third device 30C sends the visitor key information DKN and the key status update request D44 for the visitor key KN to the management server 70.

[0148] Upon receiving a key status update request D44 for the visitor key KN, the management server 70 executes step S159. In step S159, the management server 70 performs registration management for the visitor key KN.

[0149] Specifically, the management server 70 verifies that the guest key KN, which is the subject of the key status update request D44, is not listed in the revocation list. If the guest key KN is listed in the revocation list, the management server 70 sends a notification to the third device 30C indicating that it cannot respond to the key status update request D44.

[0150] On the other hand, if the visitor key KN is not listed in the revocation list, the management server 70 registers the visitor key KN, which is the subject of the key status update request D44, into the database DB. The management server 70 stores the visitor key information DKN of the visitor key KF that has received the key status update request D44 in the database DB. The management server 70 stores in the database DB information indicating that the device 30 registered as visitor device 52 is a third device 30C. The management server 70 stores information indicating the relationship between the third device 30C and the friend device 51 by referring to the obtained visitor key information DKN. Specifically, the management server 70 stores the fact that the third device 30C is a device 30 that has a visitor key KN registered in response to the registration request D41 from the friend device 51.

[0151] Subsequently, management server 70 sends the authentication packet ATP, which is part of the guest key information DKN, along with a storage request D45 requesting the storage of the authentication packet ATP, to vehicle 20. That is, management server 70 sends the device public key information ST6, instructing guest device 52 to use its device public key PKD. Management server 70 then notifies vehicle 20 that the device public key PKD has been signed by guest device 51.

[0152] Subsequently, upon receiving the authentication packet ATP and storage request D45, vehicle 20 executes step S160. In step S160, vehicle 20 stores the received authentication packet ATP. That is, vehicle 20 stores the authentication packet ATP as authentication information AT used to authenticate the visitor key KN.

[0153] After completing the registration management, the management server 70 sends a key status update completion notification D46 to the third device 30C.

[0154] Upon receiving the key status update completion notification D46, the third device 30C executes step S161. During step S161, the third device 30C presents information indicating the completion of registration for the visitor key KN on the HMI 32. For example, the third device 30C displays an image on the HMI 32 indicating the completion of registration for the visitor key KN. As a result, the management system 10 terminates the series of processes used to register the visitor key KN.

[0155] Validity period of shared key KS (VP)

[0156] A validity period (VP) can be set for each shareable key (KS). Based on... Figure 9 The authentication package ATP shown includes validity start time information ATP3 and validity end time information ATP4, which determine the validity period VP for each shared key KS. The validity period VP is the period from the date and time indicated by the validity start time information ATP3 to the date and time indicated by the validity end time information ATP4. A user with a shared key KS of vehicle 20 can use vehicle 20 with the shared key KS during the validity period VP.

[0157] Gradual Exit Period of Shared Key KS FO

[0158] A gradual exit period FO can be defined for each shareable key KS. The gradual exit period FO is a grace period during which the deletion of the shareable key KS is postponed until the specified condition RC is met. Users of the shareable key KS of vehicle 20 can continue to use vehicle 20 with the shareable key KS during the gradual exit period FO until the specified condition RC is met, at which point the shareable key KS is deleted.

[0159] For example, the specified condition RC is for vehicle 20 to authenticate digital keys other than the shareable key KS to be deleted. In this case, when a digital key other than the shareable key KS in the phase-out period FO is authenticated by vehicle 20 during the phase-out period FO, vehicle 20 deletes the shareable key KS.

[0160] On the other hand, vehicle 20 can be configured not to delete the shareable key KS in the phase-out period FO even after authentication of the digital key other than the shareable key KS in the phase-out period FO. Specifically, when authenticating the digital key other than the shareable key KS in the phase-out period FO, vehicle 20 can use the deletion flag EF to pre-set whether to delete the shareable key KS in the phase-out period FO.

[0161] The deletion flag EF is a piece of information included in the device deletion information DE stored in storage device 28. For each shareable key KS registered in vehicle 20, the deletion flag EF is set to either an authorized or prohibited state.

[0162] When the deletion flag EF is set to the permitted state, vehicle 20 deletes the shared key KS in the phase-out period FO when the digital key other than the shared key KS in the phase-out period FO is authenticated by vehicle 20 during the phase-out period FO.

[0163] When the deletion flag EF is set to the prohibited state, even if a digital key other than the shareable key KS in the exit period FO is authenticated by vehicle 20 during the exit period FO, vehicle 20 will not delete the shareable key KS in the exit period FO. The shareable key KS in the exit period FO is not deleted and is maintained in the exit period FO.

[0164] RQ for the deletion request of the first shareable key KSA

[0165] like Figure 15 As shown, upon receiving a deletion request RQ for the first shareable key KSA, vehicle 20A performs a process of selecting the procedure to be executed based on the type of the deletion request RQ. Figure 15 The process shown is executed by the execution device 27 of vehicle 20A based on the deletion program PE.

[0166] Vehicle 20A is one of vehicles 20. Vehicle 20A is a shared vehicle used, for example, in a car rental service or car-sharing service. The first owner key KOV, the first shareable key KSA, and the second shareable key KSB are registered in vehicle 20A.

[0167] The first owner key (KOV) is a vehicle owner key registered in a virtual device (40V) implemented on server 80. The virtual device 40V is, for example, a vehicle owner device 40 owned by a commercial operator providing car rental or car-sharing services.

[0168] The first shareable key KSA is a shareable key KS registered in the first shareable device 51A belonging to the first user UA. The first shareable key KSA is a friend key KF. The second shareable key KSB is a shareable key KS registered in the second shareable device 52B belonging to the second user UB. The second shareable key KSB is a visitor key KN. The validity period VP for the use of vehicle 20A is set for each of the first shareable key KSA and the second shareable key KSB.

[0169] In the following description, the process executed by the execution device 27 of vehicle 20A is described as a process executed by vehicle 20A. Upon receiving a deletion request RQ for the first shared key KSA from the management server 70, vehicle 20A starts... Figure 15 The series of processes shown.

[0170] The type of delete request is RQ

[0171] First, the description will be in Figure 15 The deletion request (RQ) used in the series of processes shown is illustrated.

[0172] A deletion request (RQ) is a signal used to request vehicle 20A to delete authentication information AT associated with the first shared key KSA. Deletion request RQs are categorized into several types based on whether a device 30 has already requested deletion or if deletion has been requested. There are three types of deletion request RQs: First Deletion Request RQ1, Second Deletion Request RQ2, and Third Deletion Request RQ3.

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

[0174] like Figure 16 As shown, the management system 10 executes a series of processes to send a first deletion request RQ1 to the vehicle 20A.

[0175] like Figure 16 As shown, in step S311, the first shareable device 51A executes the termination process TP based on an operation performed by the first user UA. The termination process TP authorizes the management server 70 to initiate the process of deleting the first shareable key KSA. In the termination process TP, the first shareable device 51A sends a use termination notification D51 to the management server 70, indicating that the use of vehicle 20A is to be terminated.

[0176] Upon receiving the termination notification D51, the management server 70 executes step S312. In step S312, the management server 70 generates a first deletion request RQ1 based on the termination notification D51.

[0177] The first deletion request RQ1 includes information indicating that the first shareable key KSA itself is requesting deletion of the first shareable key KSA. Specifically, the first deletion request RQ1 includes the digital key identification information ST3 of the first shareable key KSA as information indicating that a deletion request has been submitted. The first deletion request RQ1 includes the digital key identification information ST3 of the first shareable key KSA as information indicating that a request has been made to delete the authentication information AT. After generating the first deletion request RQ1, the management server 70 sends the first deletion request RQ1 to the vehicle 20A.

[0178] Upon receiving the first deletion request RQ1, vehicle 20A is started in step S313. Figure 15 The process shown is as follows.

[0179] like Figure 17 As shown, the management system 10 executes a series of processes to send a second deletion request RQ2 to vehicle 20A.

[0180] like Figure 17As shown, in step S321, the management server 70 verifies that the validity period VP of the first shared key KSA has expired. Specifically, the period management procedure PT causes the execution device 71 to retrieve the validity end time information ATP4 of the first shared key KSA from the database DB at specified time intervals and check whether the validity period VP has expired. In step S321, when the management server 70 verifies that the validity period VP of the first shared key KSA has expired, the management server 70 advances the process to step S322.

[0181] In step S322, the management server 70 generates a second deletion request RQ2. The second deletion request RQ2 includes information indicating that a request is being made to delete the first shared key KSA based on the expiration of its validity period VP. Specifically, the second deletion request RQ2 includes the digital key identification information ST3 of the first shared key KSA as information indicating the request to delete the authentication information AT. The second deletion request RQ2 includes the validity start time information ATP3 and validity end time information ATP4 of the first shared key KSA as information indicating that the validity period VP of the first shared key KSA has expired. After generating the second deletion request RQ2, the management server 70 sends the second deletion request RQ2 to the vehicle 20A.

[0182] Upon receiving the second deletion request RQ2, vehicle 20A is activated in step S323. Figure 15 The process shown is as follows.

[0183] like Figure 18 As shown, the management system 10 executes a series of processes to send a third deletion request RQ3 to vehicle 20A.

[0184] like Figure 18 As shown, 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 shared key KSA. The deletion reservation request D61 includes information about the conditions for deleting the first shared key KSA. This information includes, for example, the date and time when the first shared key KSA is deleted. Subsequently, the virtual device 40V sends the deletion reservation request D61 to the management server 70.

[0185] Upon receiving the deletion reservation request D61, the management server 70 executes 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 includes information indicating that the first owner key KOV requests the deletion of the first shareable key KSA. Specifically, the third deletion request RQ3 includes the digital key identification information ST3 of the first owner key KOV as information indicating that a deletion request has been submitted. The third deletion request RQ3 includes the digital key identification information ST3 of the first shareable key KSA as information indicating that a deletion request has been submitted. The third deletion request RQ3 includes information regarding the conditions for deleting the first shareable key KSA. After generating the third deletion request RQ3, the management server 70 sends the third deletion request RQ3 to vehicle 20A.

[0186] Subsequently, upon receiving the third deletion request RQ3, vehicle 20A is activated in step S333. Figure 15 The process shown is as follows.

[0187] Selection of the deletion process in vehicle 20A

[0188] Upon receiving a deletion request RQ that is any one of the first deletion request RQ1, the second deletion request RQ2, and the third deletion request RQ3, vehicle 20A starts. Figure 15 The process shown is as follows.

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

[0190] In step S212, vehicle 20A obtains its location information GL using positioning device 29C. After obtaining the location information GL, vehicle 20A proceeds to step S213.

[0191] In step S213, vehicle 20A determines whether the first deletion request RQ1 was received while vehicle 20A was stopped at the return position SD. If, in step S213, it is determined that the first deletion request RQ1 was received while vehicle 20A was stopped at the return position SD (step S213; Yes), vehicle 20A proceeds to step S214. If, in step S213, it is determined that the first deletion request RQ1 was not received while vehicle 20A was stopped at the return position SD (step S213; No), vehicle 20A proceeds to step S215.

[0192] The return position SD is a pre-determined location where the use of vehicle 20A is to be terminated. When the return position SD is set, it corresponds to the termination position SE, which is the designated point where the use of vehicle 20A is terminated.

[0193] Figure 19 The positional relationship between vehicle 20A and the return position SD is shown. Figure 19 The usage area AR is shown. The usage area AR indicates the geographical area in which the use of vehicle 20A is permitted. The usage area AR is, for example, a municipal authority in Japan. For instance, when the usage area AR is city T in Japan, the user is permitted to use vehicle 20A only within city T.

[0194] The return position SD of vehicle 20A is determined by Figure 19 The black circle in the diagram indicates the return point SP6. Users of vehicle 20A are free to use vehicle 20A within the usage area AR. Users of vehicle 20A must reach the return point SP6 (which serves as the return location SD) before the validity period VP expires, and then terminate their use of vehicle 20A.

[0195] Figure 20 yes Figure 19 An enlarged view of the area surrounding return point SP6 shown. Figure 20 As shown, the return parking access point (AP) is located around the return point SP6. The return parking access point (AP) is a place to park vehicle 20A when its use is terminated. The return parking access point (AP) is, for example, a parking space at a car rental shop. The return parking access point (AP) is a parking space located at a car-sharing station in a car-sharing service. A car-sharing station is, for example, an unmanned facility equipped with multiple shared cars and the equipment required for users to start or terminate their shared car use.

[0196] As by Figure 20 The circle indicated by the long dashed line and the two short dashed lines defines the permitted return area A6 as being defined around the return point SP6. The permitted return area A6 is actually defined as any area within a specified range from the return point SP6. Figure 20 As shown, the permitted return area A6 is, for example, a circular area with a radius of a specified distance, which covers the entire area of ​​the return parking lot AP at the return point SP6.

[0197] Depend on Figure 20 The solid line indicates that vehicle 20A is parked at the corner of the return parking lot AP within the permitted return area A6. Therefore, when vehicle 20A is within the specified distance from the return point SP6, vehicle 20A is determined to be parked at the return point SP6.

[0198] exist Figure 15 In step S213, vehicle 20A determines, based on its position information GL, whether it has already received the first deletion request RQ1 while vehicle 20A is stopped at return point SP6, which is the return position SD. When vehicle 20A is within a predetermined distance from return point SP6, vehicle 20A determines that it has already received the first deletion request RQ1 while vehicle 20A is stopped at return position SD (step S213; Yes). In step S213, when vehicle 20A is not within the predetermined distance from return point SP6, vehicle 20A determines that it has not yet received the first deletion request RQ1 while vehicle 20A is stopped at return position SD (step S213; No).

[0199] Subsequently, in step S214, vehicle 20A performs a first deletion process. The first deletion process is the process of deleting the first shareable key KSA executed by vehicle 20A when deletion request RQ is the first deletion request RQ1 and the first deletion request RQ1 is received while vehicle 20A is stopped at the return position SD. Details of the first deletion process will be described below.

[0200] In step S215, vehicle 20A sends a termination process failure notification to management server 70. The termination process failure notification includes information indicating that the termination process TP for vehicle 20A has not yet been completed, because it has been determined that the first deletion request RQ1 was not received while vehicle 20A was stopped at the return position SD. Upon receiving the termination process failure notification, management server 70 forwards a reprocessing request to the first shareable device 51A based on the notification. The reprocessing request is a notification requesting the first user UA, to which the first shareable device 51A belongs, to re-perform the operation to execute the termination process TP after verifying that vehicle 20A is stopped at the return position SD.

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

[0202] In step S217, vehicle 20A performs a second deletion process. When deletion request RQ is the second deletion request RQ2, the second deletion process is performed by vehicle 20A to delete the first shareable key KSA. The details of the second deletion process will be described below.

[0203] In step S218, vehicle 20A verifies that deletion request RQ is the third deletion request RQ3. Subsequently, vehicle 20A advances the process to step S219.

[0204] In step S219, vehicle 20A performs a third deletion procedure. When deletion request RQ is a third deletion request RQ3, the third deletion procedure is performed by vehicle 20A to delete the first shareable key KSA. The details of the third deletion procedure will be described below.

[0205] When any one of the processes S214, S215, S217 and S219 is executed, vehicle 20A ends the series of processes.

[0206] Deletion process for the first shareable key KSA

[0207] The following will describe in sequence. Figure 15 Each deletion process shown is a first deletion process, a second deletion process, and a third deletion process. In the following description, as described above, the specified condition RC for the expiration of the phase-out period FO is that a digital key other than the shared key KS to be deleted (i.e., a digital key other than the first shared key KSA) is authenticated by vehicle 20A. In the following text, the digital key other than the first shared key KSA authenticated by vehicle 20A will be referred to as the second shared key KSB. The deletion flag EF is information indicating whether the deletion of the first shared key KSA during the phase-out period FO is permitted. As described above, in the following description, the process executed by execution device 27 is described as a process executed by vehicle 20A.

[0208] First deletion process

[0209] like Figure 21As shown, vehicle 20A performs the first deletion process. When in Figure 15 When step S214 is executed in the process shown, the first deletion process is initiated by vehicle 20A.

[0210] First, in step S411, vehicle 20A sets the deletion flag EF to the permitted state.

[0211] Next, in step S412, vehicle 20A initiates the gradual exit period FO of the first shared key KSA. At this time, as a result of step S411, the deletion flag EF of the first shared key KSA has been set to the permitted state. During the gradual exit period FO initiated in step S412, when the second shared key KSB is authenticated by vehicle 20A, vehicle 20A terminates the gradual exit period FO of the first shared key KSA and performs the deletion of the first shared key KSA. In the following text, the gradual exit period FO during which the first shared key KSA is deleted when the second shared key KSB is authenticated by vehicle 20A will be referred to as the normal gradual exit period FN.

[0212] After executing step S412, vehicle 20A completes the first deletion process.

[0213] When the first deletion request RQ1 is received while vehicle 20A is parked at the return position SD, vehicle 20A initiates the first deletion process for the first shared key KSA. The first deletion process initiates a normal gradual exit period FN, during which the first shared key KSA is deleted when the second shared key KSB (which is a digital key other than the first shared key KSA) is authenticated for vehicle 20A. The normal gradual exit period FN initiated in step S412 is a second grace period.

[0214] Second deletion process

[0215] like Figure 22 As shown, vehicle 20A performs the second removal process. When in Figure 15 When step S217 is executed in the process shown, the second deletion process is initiated by vehicle 20A.

[0216] First, in step S421, vehicle 20A sets the deletion flag EF to a prohibited state.

[0217] Next, in step S422, vehicle 20A initiates the phase-out period FO of the first shared key KSA. At this time, as a result of the process in step S421, the deletion flag EF of the first shared key KSA has been set to a disabled state. During the phase-out period FO initiated in step S422, even if the second shared key KSB is authenticated by vehicle 20A, vehicle 20A does not delete the first shared key KSA and continues the phase-out period FO. In the following text, this specific type of phase-out period FO will be referred to as the restricted phase-out period FR. During the restricted phase-out period FR, even if the second shared key KSB is authenticated for vehicle 20A, vehicle 20A does not delete the first shared key KSA. The start date and time of the restricted phase-out period FR are set to coincide with the expiration date and time of the validity period VP of the first shared key KSA.

[0218] After performing step S422, vehicle 20A completes the second deletion process.

[0219] Upon receiving the second deletion request RQ2, vehicle 20A sets a restricted gradual exit period FR. After receiving the second deletion request RQ2, i.e., after the validity period VP of the first shared key KSA expires, vehicle 20A initiates the restricted gradual exit period FR. The restricted gradual exit period FR is a first grace period during which the deletion of the first shared key KSA is postponed.

[0220] When the second deletion process is executed, vehicle 20A does not receive the first deletion request RQ1. When it is determined that the first deletion request RQ1 has not been received while vehicle 20A is stopped at the return position SD, vehicle 20A executes the second deletion process during the start restriction phase-out period FR. When it is determined that the first deletion request RQ1 has not been received while vehicle 20A is stopped at the return position SD, vehicle 20A does not delete the first shared key KSA, even if a digital key other than the first shared key KSA is authenticated for vehicle 20A.

[0221] Third deletion process

[0222] like Figure 23 As shown, vehicle 20A performs the third deletion process. When in Figure 15 When step S219 is executed in the process shown, the third deletion process is initiated by vehicle 20A.

[0223] First, in step S431, vehicle 20A sets the deletion flag EF to the permitted state.

[0224] Next, in step S432, vehicle 20A initiates the gradual exit period FO of the first shared key KSA. At this time, as a result of step S431, the deletion flag EF of the first shared key KSA has been set to the permitted state. During the gradual exit period FO initiated in step S432, when the second shared key KSB is authenticated by vehicle 20A, vehicle 20A terminates the gradual exit period FO of the first shared key KSA and performs the deletion of the first shared key KSA. The gradual exit period FO initiated in step S432 is as follows: Figure 21 The normal gradual exit period FN in the first deletion process shown.

[0225] After performing step S432, vehicle 20A completes the third deletion process.

[0226] The normal gradual exit period FN initiated in step S432 is the third grace period, during which the deletion of the first shared key KSA is postponed until the second shared key KSB is authenticated after the third deletion request RQ3 is received.

[0227] Deletion of the first shareable key KSA

[0228] like Figures 24 to 26 As shown, the management system 10 performs a series of processes related to the deletion of the first shareable key KSA. Similarly, in Figures 24 to 26 In the context, the first shareable key KSA is the shareable key KS to be deleted. Similarly, in... Figures 24 to 26 In this context, the second shareable key KSB is a digital key that is certified for vehicle 20A and is separate from the first shareable key KSA.

[0229] like Figure 24 As shown, firstly, in step S511, vehicle 20A initiates the gradual exit period FO of the first shared key KSA. The gradual exit period FO includes... Figure 21 and Figure 23 The normal gradual exit period FN shown in the figure Figure 22 The restriction is shown in the gradual exit period FR. When vehicle 20A initiates any of the gradual exit periods FO, vehicle 20A sends a deletion pending start notification D71 to management server 70 indicating that the gradual exit period FO of the first shared key KSA has been initiated.

[0230] Upon receiving the deletion pending initiation notification D71, the management server 70 executes step S512. In step S512, the management server 70 generates a deletion pending notification D72 based on the deletion pending initiation notification D71, indicating that the first shareable key KSA is in a phased exit period FO. Then, the management server 70 sends the deletion pending notification D72 to the first shareable device 51A.

[0231] Subsequently, when the first shareable device 51A receives the deletion pending notification D72, the first shareable device 51A executes step S513. In step S513, the first shareable device 51A causes the HMI 32 to display information indicating that the first shareable key KSA registered in the first shareable device 51A is in a phase-out period FO. At this time, the first shareable device 51A displays information on the HMI 32 indicating whether the phase-out period FO of the first shareable key KSA is a normal phase-out period FN or a restricted phase-out period FR. In other words, when a digital key other than the first shareable key KSA is authenticated by the vehicle 20A, the first shareable device 51A displays information on the HMI 32 indicating whether the first shareable key KSA should be deleted.

[0232] Following step S512, management server 70 executes step S514. As in step S512, in step S514, management server 70 generates a delete pending notification D73 based on the delete pending initiation notification D71, indicating that the first shared key KSA is in the phase-out period FO. Management server 70 sends the delete pending notification D73 to virtual device 40V.

[0233] When the virtual device 40V receives the deletion pending notification D73, the virtual device 40V executes step S515. In step S515, the virtual device 40V updates the shareable key list LS to store information indicating that the first shareable key KSA is in the phase-out period FO.

[0234] The Shareable Key List LS is a list of information stored in storage device 37 of the virtual device 40V. The Shareable Key List LS includes information related to each Shareable Key KS registered based on each owner key KO registered in the virtual device 40V. The Shareable Key List LS includes, for example, information related to the validity period VP and the phase-out period FO of each Shareable Key KS.

[0235] The virtual device 40V references the information included in the pending deletion notification D73 and obtains information indicating whether the phase-out period FO of the first shared key KSA is a normal phase-out period FN or a restricted phase-out period FR. The virtual device 40V stores the information indicating whether the phase-out period FO of the first shared key KSA is a normal phase-out period FN or a restricted phase-out period FR in the information about the first shared key KSA in the shared key list LS.

[0236] like Figure 25 As shown, when the second shareable key KSB is authenticated by vehicle 20A, vehicle 20A initiates step S516.

[0237] In step S516, vehicle 20A verifies that the specified condition RC is met. In other words, vehicle 20A verifies that the second shareable key KSB, which is different from the first shareable key KSA, has been authenticated by vehicle 20A. When vehicle 20A verifies that the second shareable key KSB has been authenticated, vehicle 20A advances the process to step S517.

[0238] In step S517, vehicle 20A checks the deletion flag EF of the first shared key KSA using the reference device deletion information DE. When it is verified that the first shared key KSA is in the normal exit phase FN where the deletion flag EF is set to the permitted state, vehicle 20A proceeds the process to step S518. When it is verified that the first shared key KSA is in the restricted exit phase FR where the deletion flag EF is set to the prohibited state, vehicle 20A stops the process in step S517. Even if vehicle 20A stops the process in step S517, the user can continue to use vehicle 20A using the second shared key KSB without any problems. Subsequently, when a digital key other than the first shared key KSA is authenticated by vehicle 20A again, vehicle 20A restarts the process in step S516.

[0239] In step S518, vehicle 20A terminates the phased exit period FO of the first shared key KSA. This phased exit period FO is the normal phased exit period FN. When the phased exit period FO expires, vehicle 20A advances the process to step S519.

[0240] In step S519, vehicle 20A deletes the authentication information AT used to authenticate the first shared key KSA. That is, vehicle 20A deletes the authentication packet ATP of the first shared key KSA.

[0241] In step S520, vehicle 20A generates a key deletion request D74 to request the deletion of the friend key information DKF of the first shareable key KSA. In addition to requesting the deletion of the friend key information DKF of the first shareable key KSA, key deletion request D74 also includes information indicating that the deletion of authentication information AT associated with the first shareable key KSA has been completed. Subsequently, vehicle 20A sends key deletion request D74 to management server 70.

[0242] Upon receiving a key deletion request D74, the management server 70 initiates step S521. In step S521, the management server 70 stores the history of deletions of authentication information AT used to authenticate the first shareable key KSA in vehicle 20A. Afterward, the management server 70 proceeds the process to step S522.

[0243] In step S522, the management server 70 generates a key deletion request D75 that requests the deletion of the friend key information DKF of the first shareable key KSA.

[0244] Then, as Figure 26 As shown, the management server 70 sends a key deletion request D75 to the first shareable device 51A.

[0245] Subsequently, upon receiving the key deletion request D75, the first shareable device 51A executes step S523. In step S523, in response to the key deletion request D75, the first shareable device 51A deletes the friend key information DKF of the first shareable key KSA. The first shareable device 51A sends a deletion completion notification D76 to the management server 70, indicating that the deletion according to the key deletion request D75 has been completed.

[0246] Subsequently, upon receiving the deletion completion notification D76, the management server 70 executes step S524. In step S524, the management server 70 stores the deletion history of friend key information DKF associated with the first shareable key KSA in the first shareable device 51A. Afterward, the management server 70 proceeds to step S525.

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

[0248] Upon receiving the deletion completion notification D77, the virtual device 40V executes step S526. In step S526, the virtual device 40V stores information indicating the completion of the deletion of the first shared key KSA in the storage device 37. Specifically, the virtual device 40V updates the information related to the first shared key KSA in the shared key list LS. In this way, the management system 10 concludes the series of processes for deleting the first shared key KSA.

[0249] Emergency deletion process for the first shareable key KSA (EU)

[0250] like Figure 27 As shown, vehicle 20A performs a series of procedures for performing an emergency deletion procedure EU on the first shareable key KSA. Figure 27 The process shown is performed by vehicle 20A at prescribed time intervals based on the deletion procedure PE during the restricted gradual exit period FR. As described above, in the following description, the process performed by execution device 27 is described as a process performed by vehicle 20A.

[0251] exist Figure 27 In this context, the first shared key KSA is in the restricted exit period FR. In other words, due to the expiration of the validity period VP, the first shared key KSA is in a state following the execution of the second deletion process.

[0252] First, in step S611, vehicle 20A acquires the elapsed time OT for the first shareable key KSA. The elapsed time OT is the amount of time elapsed since the start of the restricted exit period FR. Specifically, the elapsed time OT is the amount of time elapsed from the start date and time of the restricted exit period FR. After acquiring the elapsed time OT, vehicle 20A proceeds the process to step S612.

[0253] In step S612, vehicle 20A determines whether the elapsed time OT is greater than or equal to a predetermined time. When it is determined in step S612 that the elapsed time OT is greater than or equal to the predetermined time (step S612; Yes), vehicle 20A advances the process to step S613. When it is determined in step S612 that the elapsed time OT is not greater than or equal to the predetermined time (step S612; No), vehicle 20A temporarily terminates the series of processes.

[0254] Next, in step S613, vehicle 20A acquires its driving history. Based on the location information GL of vehicle 20A at the corresponding time included in the vehicle history information HC, vehicle 20A acquires the changes in its position as its driving history. Vehicle 20A then proceeds to step S614.

[0255] In step S614, vehicle 20A determines whether its position is moving away from the return position SD based on its driving history.

[0256] In step S614, when vehicle 20A determines that its position is moving away from the return position SD (step S614; Yes), vehicle 20A proceeds the process to step S615. In step S614, when vehicle 20A determines that its position is not moving away from the return position SD (step S614; No), vehicle 20A temporarily terminates the series of processes.

[0257] Figure 28 The position of vehicle 20A at time t is shown when the elapsed time OT becomes greater than or equal to the specified time. Figure 28 The arrow CA shown represents the travel path of vehicle 20A based on its historical location information GL. Arrow CA indicates the change in vehicle 20A's location from the start date and time of the restricted exit period FR to time t. For example, when vehicle 20A's location is as follows... Figure 28 When the movement indicated by arrow CA in the diagram occurs, vehicle 20A determines that its position is moving away from the return position SD.

[0258] Next, in step S615, vehicle 20A waits for its operation to be terminated. Termination of vehicle 20A's operation means, for example, the user stopping the engine 29B of vehicle 20A. Termination of vehicle 20A's operation can also mean, for example, the user stopping the engine 29B of vehicle 20A and operating the locking mechanism 29A from outside vehicle 20A to lock vehicle 20A. When it is verified that vehicle 20A's operation has been terminated, vehicle 20A advances the process to step S616.

[0259] In step S616, vehicle 20A initiates the emergency removal process EU. That is, vehicle 20A initiates the emergency removal process EU in response to the termination of its operation. Afterward, vehicle 20A proceeds the process to step S617.

[0260] In step S617, vehicle 20A performs the deletion of the first shareable key KSA in the emergency deletion process EU. Specifically, vehicle 20A deletes the authentication information AT associated with the first shareable key KSA registered in vehicle 20A. Upon completion of the deletion of the authentication information AT associated with the first shareable key KSA, vehicle 20A advances the process to step S618.

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

[0262] During the execution of step S618, vehicle 20A terminates a series of processes related to the emergency deletion process EU. As described above, when the elapsed time OT is greater than or equal to a predetermined time and the position of vehicle 20A moves away from the return position SD, vehicle 20A then initiates the emergency deletion process EU in response to the next termination operation of vehicle 20A. This emergency deletion process EU deletes the first shared key KSA.

[0263] Operation of this embodiment

[0264] If a grace period is provided during which the deletion of the first shared key KSA, whose validity period VP has expired, is postponed, then the first user UA can continue to use vehicle 20A via the first shared key KSA even after the validity period VP has expired. However, if during this grace period, a second shared key KSB, which is a digital key other than the first shared key KSA, is authenticated by vehicle 20A and thus the deletion of the first shared key KSA is performed, then the first user UA will no longer be able to use vehicle 20A via the first shared key KSA.

[0265] Vehicle 20A determines, based on location information GL, whether it has already stopped at the return position SD (which is the termination position SE) and executes the first deletion request RQ1 based on the termination procedure TP. When the execution device 27 determines that the first deletion request RQ1 has been issued while vehicle 20A is stopped at the return position SD, the use of vehicle 20A has been terminated. Conversely, when the execution device 27 determines that the first deletion request RQ1 has not been issued while vehicle 20A is not stopped at the return position SD, vehicle 20A is still being used. Even if the second shareable key KSB (which is a digital key different from the first shareable key KSA) is authenticated by vehicle 20A while the use of vehicle 20A has not been terminated, vehicle 20A does not delete the first shareable key KSA, which is in the restricted exit period FR. Even after the validity period VP has expired, vehicle 20A allows the first user UA to continue using vehicle 20A via the first shareable key KSA until the termination procedure TP is executed at the return position SD.

[0266] Advantages of this embodiment

[0267] (1) The first shareable key KSA is deleted while vehicle 20A is in use. Therefore, it is possible to prevent the first user UA from becoming unusable vehicle 20A before reaching the destination.

[0268] (2) The execution device 27 is configured to determine that the vehicle 20A stops at the return position SD when the position information GL of the vehicle 20A indicates that the vehicle 20A is within a specified distance from the return position SD.

[0269] If vehicle 20A is within the specified distance from the return position SD, the use of vehicle 20A can be terminated even if vehicle 20A is parked far away from the return position SD.

[0270] (3) The first deletion process starts normally and gradually exits the period FN, during which the first shared key KSA is deleted when the second shared key KSB (which is a digital key other than the first shared key KSA) is authenticated for vehicle 20A.

[0271] Even after the first user UA has executed the termination process TP, the first user UA can continue to use vehicle 20A through the first shared key KSA until the second shared key KSB is authenticated by vehicle 20A.

[0272] (4) The execution device 27 is configured to set a normal phase-out period FN when it receives a deletion request RQ generated based on a request from the first owner key KOV, which is a digital key other than the first shareable key KSA. The normal phase-out period FN is a period during which the deletion of the first shareable key KSA is postponed until the second shareable key KSB (which is a digital key other than the first shareable key KSA) is authenticated for vehicle 20A after receiving the third deletion request RQ3.

[0273] Even after vehicle 20A receives a third deletion request RQ3 generated based on a request from another digital key, vehicle 20A can still be used by using the first shared key KSA until vehicle 20A authenticates the second shared key KSB, which is a digital key other than the first shared key KSA.

[0274] Even when a third deletion request RQ3, generated based on a request from another digital key, is received, vehicle 20A is prevented from immediately becoming unusable.

[0275] (5) The execution device 27 is configured to initiate an emergency deletion process EU for deleting the first shared key KSA in response to the next termination of the operation of vehicle 20A when the elapsed time OT, which is the time elapsed since the start of the phased exit period FR from the restriction, becomes greater than or equal to a predetermined time.

[0276] If the elapsed time OT is greater than or equal to the specified time, the use of the first shared key KSA for vehicle 20A continues even after the specified time has elapsed beyond the validity period VP. When the elapsed time OT becomes greater than or equal to the specified time, vehicle 20A deletes the first shared key KSA in response to the termination of operation of vehicle 20A. In this way, subsequent use of vehicle 20A via the first shared key KSA is disabled.

[0277] As described above, the use of vehicle 20A can be restricted using the first shareable key KSA whose validity period VP has expired.

[0278] (6) The execution device 27 is configured to initiate an emergency deletion process EU in response to the termination of the operation of vehicle 20A when the elapsed time OT is greater than or equal to a predetermined time and the position of vehicle 20A is moving away from the return position SD.

[0279] Even if the elapsed time OT is greater than or equal to the specified time and vehicle 20A is moving away from the return position SD, the first user UA is highly likely not to intend to return to vehicle 20A.

[0280] When there is a high probability that the first user UA does not intend to return vehicle 20A, vehicle 20A can be restricted from use via the first shareable key KSA.

[0281] Revise

[0282] The above embodiments can be modified as follows. The above embodiments and the following modifications can be combined, as long as the combined modifications remain technically consistent with each other.

[0283] In the above embodiment, the termination position SE is the return position SD, which is predetermined as the point where the use of vehicle 20A is to be terminated. The termination position SE can be configured such that the user of vehicle 20 can select a point from a plurality of candidate points.

[0284] like Figure 19 As shown, five permitted return locations SC are set in the usage area AR: return point SP1, return point SP2, return point SP3, return point SP4, and return point SP5. The permitted return locations SC are candidate locations where the user can terminate the use of vehicle 20. Figure 19The vehicle 20B shown is a vehicle 20 with an undetermined termination position SE. The user of vehicle 20B can select any of the five permitted return positions SC as the termination position SE. For example, as by Figure 19 As indicated by the arrow in the image, the user of vehicle 20B can select return point SP2 as the termination position SE.

[0285] When there are multiple permitted return locations SC where the use of vehicle 20B can be terminated, the termination location SE is one of the permitted return locations SC. Even when there are multiple candidates for the termination location SE, vehicle 20A will still achieve the advantage (1). Vehicle 20B corresponds to, for example, a rental car or shared car vehicle that allows one-way use and return at different locations.

[0286] When vehicle 20A is within a predetermined distance from the return position SD, vehicle 20A determines that it is stopped at the return position SD. The actuator 27 of vehicle 20A can be configured to determine that vehicle 20A is stopped at the return position SD after a predetermined time or longer.

[0287] For example, when vehicle 20A is within a specified distance from return position SD and vehicle 20A remains at return position SD for a specified time or longer, the modified vehicle 20A can be determined to be at return position SD.

[0288] Depend on Figure 20 The long dashed line and short dashed line indicate that vehicle 20A has been temporarily stopped in the parking lot AP for less than the prescribed time. In this case, the modified vehicle 20A is determined to be not in a stopped state. For example, when the modified vehicle 20A is in the parking lot AP... Figure 20 When a vehicle stops at the location indicated by the solid line in the diagram for a specified time or longer, vehicle 20A determines that vehicle 20A is in a stopped state.

[0289] The modified vehicle 20A can more accurately determine when the first user UA will terminate the use of vehicle 20A.

[0290] exist Figure 27 The conditions for initiating the emergency deletion process EU for a vehicle are not limited to those described above. A vehicle can be configured to initiate the emergency deletion process EU in response to the termination of vehicle operation when the elapsed time OT is greater than or equal to a specified time and the vehicle is located at a distance greater than or equal to a specified distance from the return position SD. Figure 28 Four vehicles 20 are shown that initiate the emergency removal process EU under conditions different from those of vehicle 20A in the above embodiment: vehicle 20C, vehicle 20D, vehicle 20E, and vehicle 20F. Figure 28The position of the corresponding vehicle 20 at time t is shown when the elapsed time OT of the first shareable key KSA becomes greater than or equal to a predetermined time.

[0291] The modified vehicle is, for example, Figure 28 The vehicle 20C is shown. The termination position SE of vehicle 20C is the return point SP6, which is the return position SD. Figure 28 The long and short dashed lines in the diagram indicate the position of the circle CC, which is far from the return point SP6 as specified. Vehicle 20C is outside the circle CC. That is, vehicle 20C is located at a distance greater than or equal to the specified distance from the return position SD. When this condition is met, vehicle 20C initiates the emergency removal process EU.

[0292] Even if the elapsed time OT is greater than or equal to the specified time and vehicle 20C is located at a distance greater than or equal to the specified distance from the return position SD, there is a high probability that the first user UA does not intend to return to vehicle 20C. When there is a high probability that the first user UA does not intend to return to vehicle 20C, the use of vehicle 20C via the first shareable key KSA can be restricted.

[0293] The vehicle can be configured to initiate an emergency deletion process EU in response to the termination of the vehicle's operation when the elapsed time OT is greater than or equal to a specified time and the vehicle has passed through multiple return permission positions SC.

[0294] The modified vehicle is, for example, Figure 28 The vehicle 20D is shown. The termination position SE of vehicle 20D is one of five permitted return positions SC. Arrow CD indicates the travel path of vehicle 20D from the start date and time of the restricted exit period FR to time t. Figure 28 As indicated by arrow CD, vehicle 20D passes through three permitted return positions SC: return point SP1, return point SP2, and return point SP5. When these conditions are met, vehicle 20D initiates the emergency removal process EU.

[0295] Even if the elapsed time OT is greater than or equal to the specified time and vehicle 20D has passed through multiple return permission positions SC, there is a high probability that the first user UA does not intend to return vehicle 20D. When there is a high probability that the first user UA does not intend to return vehicle 20D, the use of vehicle 20D via the first shareable key KSA can be restricted.

[0296] The vehicle can be configured to initiate an emergency removal procedure EU in response to the termination of vehicle operation when the vehicle is moving away from the termination position SE, provided that the elapsed time OT is greater than or equal to a predetermined time and any of the permitted return positions SC are designated as the termination position SE. The vehicle will return to any of the permitted positions SC designated as the termination position SE after the start of the restricted gradual exit period FR.

[0297] The modified vehicle is, for example, Figure 28 The vehicle 20E is shown in the diagram. The termination position SE of vehicle 20E is the return point SP4. After the start of the restricted exit period FR, vehicle 20E designates return point SP4 as the termination position SE from one of the five returnable positions SC. Arrow CE indicates the travel path of vehicle 20E from the start date and time of the restricted exit period FR to time t. Vehicle 20E is moving away from the return point SP4, which is designated as the termination position SE. When such conditions are met, vehicle 20E initiates the emergency removal procedure EU.

[0298] Even if the elapsed time OT is greater than or equal to the specified time and vehicle 20E is moving away from the designated return permitted position SC, there is a high probability that the first user UA does not intend to return to vehicle 20E. When there is a high probability that the first user UA does not intend to return to vehicle 20E, the use of vehicle 20E via the first shareable key KSA can be restricted.

[0299] The vehicle can be configured to perform an emergency deletion procedure (EU) in response to the termination of vehicle operation when the elapsed time (OT) is greater than or equal to a specified time and the vehicle is located outside the permitted use area (AR).

[0300] The modified vehicle is, for example, Figure 28 The vehicle shown is 20F. (As shown) Figure 28 As shown, vehicle 20F is located outside the use area AR. When such conditions are met, vehicle 20F initiates the emergency removal procedure EU.

[0301] If vehicle 20F is located outside the permitted use area AR, there is a high probability that the first user UA does not intend to return to vehicle 20F. When there is a high probability that the first user UA does not intend to return to vehicle 20F, access to vehicle 20F via the first shareable key KSA can be restricted.

[0302] Vehicle 20A can be configured to initiate an emergency deletion process EU in response to the termination of vehicle operation when the elapsed time OT is greater than or equal to a specified time.

[0303] In the above embodiment, the first owner key KOV is registered in the virtual device 40V. The first owner key KOV can be an owner key KO registered in the portable device 40M. In other words, the first shareable key KSA can be a shareable key KS registered based on the owner key KO registered in the portable device 40M.

[0304] The first shareable key KSA does not necessarily need to be a friend's key KF. The first shareable key KSA can be a guest key KN registered based on a friend's key KF.

[0305] The second shareable key KSB does not necessarily need to be a visitor key KN. The second shareable key KSB can be a friend key KF. The digital key other than the first shareable key KSA, which must be certified by vehicle 20A, can be the first owner key KOV.

[0306] In the above embodiments, the first deletion process is the process of initiating a normal gradual exit period FN. The first deletion process can also be the process of deleting the first shareable key KSA without initiating a normal gradual exit period FN. In this case, when by executing... Figure 15 When step S214 is initiated as shown, the vehicle 20A immediately deletes the authentication information AT associated with the first shareable key KSA.

[0307] Vehicle 20A can initiate a gradual exit from the restriction period FR during the third deletion process, as in the second deletion process. Specifically, in Figure 23 After setting the deletion flag EF to the prohibited state in step S431, vehicle 20A can... Figure 23 In step S432, the phased exit period FR is initiated. In this case, even during the phased exit period FO based on the third deletion request RQ3, the first shareable key KSA of vehicle 20A is not deleted until the use of vehicle 20A ends.

[0308] Even when the deletion request RQ is the third deletion request RQ3, the modified vehicle 20A will still achieve the advantages (1).

[0309] The use of regional ARs is not limited to municipalities within Japan. Regional ARs can be set at the prefecture level. Regional ARs can be set at the country level. Regional ARs can also be set to a given geographical region consisting of multiple countries.

[0310] The vehicle management device 26 is not limited to the digital key ECU. The vehicle management device 26 may be, for example, a central ECU that integrates and manages multiple ECUs included in the vehicle 20.

[0311] In the above embodiments, the vehicle management device 26 is provided with an execution device 27, which is a processing circuit including one or more processors that run computer programs (software) to perform various processes. However, the vehicle management device 26 may be provided with a processing circuit including one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs) that execute at least some of the processes. Alternatively, the vehicle management device 26 may be provided with a processing circuit including a combination of one or more processors and one or more dedicated hardware circuits. Each processor includes a CPU and a memory such as RAM and ROM. The memory stores program code or commands configured to cause the CPU to execute processes. The memory (i.e., computer-readable medium) includes any available medium that can be accessed by a general-purpose or special-purpose computer. This also applies to the device 30 and the management server 70.

[0312] Device 30 and portable device 40M, as portable information terminals, are not limited to smartphones. Device 30 and portable device 40M can be smartwatches.

[0313] Virtual device 40V can be included in a designated server, such as server 80. For example, virtual device 40V can be included in management server 70. Similarly, friend device 51 can be included in a designated server.

[0314] In the above embodiment, the digital keys are arranged in a hierarchical structure consisting of the owner key KO, friend key KF, and visitor key KN in descending order, such that digital keys at higher levels are assigned greater permissions. However, digital keys do not necessarily need to be configured so that higher levels correspond to greater permissions. For example, equal permissions can be assigned to the three levels: owner key KO, friend key KF, and visitor key KN.

[0315] It is not necessary to provide a separate device server 60 for each type of device 30. It is sufficient for multiple devices 30 and the management server 70 to communicate wirelessly with each other. The device server 60 can be omitted from the management system 10. In the management system 10, it is sufficient for multiple devices 30 and the management server 70 to communicate directly via wireless communication.

[0316] Management server 70 may include multiple servers. For example, management server may include a server storing database DB, a server executing server program PS, and a server executing time management program PT. Furthermore, management server 70 may include, for example, a server communicating with vehicle 20 and a server communicating with device server 60, and these servers may communicate with each other.

[0317] Management server 70 does not necessarily need to store database DB. For a digital key in system 10, management server 70 only needs to manage a combination of key information DK from device 30 and authentication information AT from vehicle management device 26.

[0318] The authentication information AT is not limited to the examples in the above embodiments, as long as it is information used to authenticate the digital key when using the digital key. For example, the authentication information AT could be a common key shared by vehicle management device 26 and device 30. Furthermore, for example, the verification information AT could be a shared secret key.

[0319] The configuration of information included in the key information DK is not limited to the examples of the above embodiments. For example, the owner key information DKO does not necessarily need to include slot identification information ST4. In another example, the key information DK may include information indicating the type of digital key. Information indicating the type of digital key includes, for example, information indicating one of the owner key KO, friend key KF, and visitor key KN.

[0320] The management system 10 may include information in the database DB indicating the type of device 30. The type of device 30 may be, for example, information indicating any of the following: smartphone, smartwatch, server, etc.

[0321] The structure of the data DA in the database DB is not limited to the example in the above embodiment. The database DB can be modified as long as it includes the information required for the management server 70 to perform management in the management system 10.

[0322] In a database (DB), it's not always necessary to uniformly determine permissions based on the type of digital key; permissions can be set for each digital key. In the database (DB), it's not always necessary to define permissions for each digital key.

[0323] The shareable device 50 has the function of receiving the shareable key KS as described in the above embodiment. The device 30 capable of receiving the digital key (such as the shareable device 50) can be referred to as the receiver device.

[0324] The digital key-related aspects in the above embodiments do not need to comply with the CCC standard.

[0325] Various changes in form and detail may be made to the foregoing examples without departing from the spirit and scope of the claims and their equivalents. These examples are for descriptive purposes only and not for limiting purposes. The description of features in each example should be considered applicable to similar features or aspects in other examples. Suitable results may be achieved if the sequence is performed in a different order, and / or if the components in the described system, architecture, device, or circuit are combined differently, and / or replaced or supplemented by other components or their equivalents. The scope of this disclosure is not limited by the detailed description but by the claims and their equivalents. All variations within the scope of the claims and their equivalents are included in this disclosure.

Claims

1. A vehicle configured to allow multiple digital keys to be registered in the vehicle, the digital keys including a single owner key registered in the vehicle and one or more shareable keys that can be registered in the vehicle, the vehicle comprising: Execution device; A storage device configured to store information relating to the digital key registered in the vehicle; as well as A communication device configured to communicate with a management server configured to manage the registration and deletion of the digital key, and the communication device configured to communicate with a device configured to store information related to the digital key. in, The one or more shareable keys are configured such that: each shareable key can be set with a validity period for use of the vehicle, and The execution device is configured as follows: When a deletion request is made for a registered shareable key based on the expiration of the validity period of the registered shareable key registered in the vehicle and for which the validity period has been set, a first grace period is set during which the deletion of the registered shareable key is postponed. Based on the vehicle's location information, it is determined whether the vehicle, which is in a stopped state at the termination location, has undergone a termination process. This termination process is used to allow the initiation of a deletion process for the registered shareable key. The termination location is a designated location where the use of the vehicle is to be terminated. When it is determined that the vehicle, which is stopped at the termination position, has completed the termination process, the deletion process for the registered shareable key is initiated, and When it is determined that the vehicle, which is in a stopped state at the termination position, has not yet performed the termination process, the registered shared key, which has been postponed for deletion, is not deleted even if a digital key other than the registered shared key has been authenticated for the vehicle.

2. The vehicle according to claim 1, wherein, The termination position is a return position that is predetermined as the location where the use of the vehicle is to be terminated.

3. The vehicle according to claim 1, wherein, The termination position is any one of a plurality of permitted return positions that are predetermined as positions where the use of the vehicle is permitted to be terminated.

4. The vehicle according to claim 1, wherein, The execution device is configured to determine that the vehicle is stopped at the termination position when the vehicle is within a predetermined distance from the termination position.

5. The vehicle according to claim 1, wherein, The execution device is configured to determine that the vehicle is in a stopped state at the termination position when the vehicle has been stopped at the termination position for a predetermined time or longer.

6. The vehicle according to claim 1, wherein, The deletion process is the initiation of a second grace period, during which, when a digital key other than the registered shareable key is authenticated for the vehicle, the registered shareable key is deleted.

7. The vehicle according to claim 1, wherein, The execution device is configured to: when the deletion request is made based on a request from a digital key other than the registered shareable key, set a third grace period during which the deletion of the registered shareable key is postponed from the time the deletion request is made until the digital key other than the registered shareable key is authenticated for the vehicle.

8. The vehicle according to any one of claims 1 to 7, wherein, The execution device is configured to initiate an emergency deletion process for deleting the registered shareable key upon subsequent termination of operation of the vehicle when deletion initiation conditions are met. The deletion initiation conditions include a condition that elapsed time becomes greater than or equal to a predetermined time, the elapsed time being the amount of time elapsed from the start of the first grace period.

9. The vehicle according to claim 8, wherein, The execution device is configured to initiate the emergency deletion process when the elapsed time is greater than or equal to the predetermined time and the vehicle is located at a distance greater than or equal to the predetermined distance from the termination position.

10. The vehicle according to claim 8, wherein, The execution device is configured to initiate the emergency deletion process when the elapsed time is greater than or equal to the predetermined time and the vehicle is moving away from the termination position.

11. The vehicle according to claim 8, wherein, The execution device is configured to initiate the emergency deletion process when the elapsed time is greater than or equal to the predetermined time and the vehicle has passed through multiple permitted return locations for terminating use of the vehicle.

12. The vehicle according to claim 8, wherein, From a plurality of permitted return locations, the termination location is specified, and The execution device is configured to initiate the emergency deletion process when the elapsed time is greater than or equal to the predetermined time and the vehicle is moving away from the termination position after the first grace period has been initiated.

13. The vehicle according to claim 8, wherein, The execution device is configured to perform the emergency deletion process when the elapsed time is greater than or equal to the predetermined time and the vehicle is located outside the permitted area for use of the vehicle.

Images