Vehicle

Abstract

A vehicle is configured to register a device as a digital key, the device being configured to store information related to the digital key. The vehicle is provided with a storage device configured to store a range of functions of the vehicle that the digital key can implement, and an execution device that changes the range of functions of the vehicle that the digital key can implement to a narrower range than the range of functions of the vehicle that the digital key can implement in a usage period of the digital key, the usage period being a period in which a user of the digital key uses the vehicle.

Description

Technical Field

[0001] This disclosure pertains to vehicles. Background Technology

[0002] Japanese Patent Application Publication No. 2024-001720 discloses a digital key management system that uses smartphones and other devices as vehicle keys. The management system stores information related to the digital key in both the vehicle and the device. This allows the vehicle to be used without a dedicated vehicle key, simply by using the device registered as the digital key. Within the management system, a device storing information related to the vehicle's digital key can make a registration request to allow another person's device to function as the vehicle's digital key. Thus, the management system is configured to allow the registration of another person's device as the vehicle's digital key. In other words, the management system can generate additional digital keys for the vehicle. Therefore, according to the management system, the vehicle can be lent to others without the need for the exchange of a dedicated vehicle key.

[0003] [The problem the invention aims to solve]

[0004] When lending a vehicle, there is an expectation that the user's use of the vehicle will be limited. In the management system described above, the user who lent the vehicle using the newly generated digital key can use the vehicle without restriction. Summary of the Invention

[0005] [Methods used to solve problems]

[0006] One aspect of this disclosure relates to a vehicle configured to register a device as a digital key, the device being configured to store information related to the digital key. The vehicle includes: a storage device configured to store a range of vehicle functions achievable by the digital key; and an execution device. The execution device is configured to change the range of vehicle functions achievable by the digital key during periods other than the usage period to a narrower range than the range of vehicle functions achievable by the digital key during the usage period, the usage period being the period during which the user of the digital key uses the vehicle. Attached Figure Description

[0007] Figure 1 This is a schematic diagram illustrating the digital key management system of the first embodiment.

[0008] Figure 2 It means stored in Figure 1 A schematic diagram of the owner's key information in the owner's device.

[0009] Figure 3 It means stored in Figure 1 A schematic diagram of shared key information.

[0010] Figure 4 It means Figure 1 A rough diagram of the data in the database of the management server.

[0011] Figure 5 It is about Figure 1 The sequence diagram of the owner key registration process performed by the management system.

[0012] Figure 6 It is about Figure 1 The sequence diagram shows the friend key registration process performed by the management system.

[0013] Figure 7 It is about Figure 1 The sequence diagram shows the process of registering non-friend keys in the management system.

[0014] Figure 8 It means Figure 1 The flowchart illustrates a series of processes that enable a vehicle's digital key to perform various functions.

[0015] Figure 9 It is about Figure 1 The timing diagram for the digital key deletion process performed by the management system.

[0016] Figure 10 This is a flowchart illustrating a series of processes that represent the range of vehicle functions that can be implemented by the vehicle change digital key according to the second embodiment.

[0017] Figure 11 This is a timing diagram showing a series of processes that represent the range of vehicle functions that can be implemented by the vehicle change digital key according to the third embodiment.

[0018] Figure 12 This is a timing diagram showing a series of processes that represent the range of vehicle functions that can be implemented by the vehicle change digital key according to the fourth embodiment.

[0019] Figure 13 This is a schematic diagram showing a specific area in the fifth embodiment. Detailed Implementation

[0020] (First Implementation)

[0021] The following is for reference Figures 1-9 The digital key management system of the vehicle 20 having the first embodiment will be described.

[0022] <Overview of Management System 10>

[0023] like Figure 1 As shown, management server 70 is one of the devices constituting management system 10. Management server 70 manages information related to multiple digital keys that can be registered to vehicle 20 by communicating with vehicle 20 and multiple devices 30. Regarding digital keys, there is a CCC (Car Connectivity Consortium) standard. Matters related to the digital keys in this embodiment are envisioned according to CCC, but standards and systems other than CCC can also be applied. Management system 10 includes vehicle 20, multiple devices 30, device server 60, and management server 70.

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

[0025] The communication module 21 communicates with the management server 70 via a wireless communication line. The HMI 22 includes an input device and a prompting device. The input device receives operations from the user of the vehicle 20 and inputs signals indicating the operation to the vehicle 20. The prompting device provides information to the user through images and sounds. The prompting device may be, for example, a monitor and a speaker.

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

[0027] A vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages information related to the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution unit 27 and a storage unit 28. The execution unit 27 is a processing circuit containing one or more processors that perform various processes according to a computer program (software). The storage unit 28 stores a vehicle program PV and authentication information AT. The vehicle program PV enables the execution unit 27 to store and delete the authentication information AT. The authentication information AT is information related to the digital key. More specifically, the authentication information AT is information used to authenticate the digital key in order to control the vehicle 20 using the digital key. The authentication information AT is set for each authenticated digital key. The execution unit 27 includes a CPU. The execution unit 27 executes the processing related to the storage and deletion of the authentication information AT by executing the vehicle program PV.

[0028] If the vehicle management device 26 authenticates the digital key, then the vehicle management device 26 can control the vehicle 20 through the digital key. For example, if the vehicle management device 26 authenticates the digital key, then the vehicle management device 26 can unlock the vehicle 20. Additionally, for example, if the vehicle management device 26 authenticates the digital key, then the vehicle management device 26 can start the vehicle 20.

[0029] Device 30 is a portable information terminal such as a smartphone. Device 30 includes a communication module 31, an HMI 32, a BLE module 33, a UWB module 34, an NFC module 35, an actuator 36, and a storage device 37.

[0030] The communication module 31 communicates with the device server 60 via a wireless communication line. The HMI 32 includes an input device and a prompting device. The input device receives user input signals to the device 30 upon receiving user input. The prompting device provides information to the user through images and sounds. The prompting device may be, for example, a monitor and a speaker.

[0031] BLE module 33 communicates wirelessly with vehicle 20 via BLE communication. UWB module 34 communicates wirelessly with vehicle 20 via UWB communication. NFC module 35 communicates wirelessly with vehicle 20 via NFC communication.

[0032] Storage device 37 stores device program PD and key information DK. The device program PD is executed by execution device 36, which in turn stores and deletes the key information DK. The key information DK represents information about a digital key.

[0033] 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 utilizes APIs prepared in the OS to provide pairing functionality for device 30 and sharing of digital keys. The execution device 36 performs processes related to the storage and deletion of key information (DK) by executing the device program (PD). The execution device 36 is a processing circuit that includes one or more processors that execute various processes according to computer programs (software).

[0034] Multiple devices 30 include an owner device 40 belonging to the owner of vehicle 20. Owner device 40 stores owner key information DKO as key information DK, representing the owner key KO. The owner key KO is a digital key, and only one owner key KO can be registered to vehicle 20. Therefore, only one owner key KO exists for each vehicle 20.

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

[0036] Vehicle identification information ST1 is information about the vehicle 20 that identifies the object set with the digital key, such as the ID of vehicle 20.

[0037] The in-device key identification information ST2 is used for the management of digital keys within device 30. ST2 is information used to identify digital keys within the application of device 30.

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

[0039] Certificate information ST5 represents the certificate proving the digital key. Device public key information ST6 represents the device public key PKD that serves as the public key for device 30. Additionally, the device public key PKD in the owner key information DKO represents the public key of the owner device 40. Vehicle public key information ST7 represents the vehicle public key PKV that serves as the public key for vehicle 20. Permission public key information ST8 represents the permitted vehicle public key PKV. Permission information ST9 indicates the scope of functions that device 30, storing this permission information ST9, can perform. The scope of functions that can be performed will be described later.

[0040] like Figure 1 As shown, the sharing device 50 stores shared key information DKS representing a shared key KS as key information DK. Shared key information DKS is information related to the shared key KS. The shared key KS is a digital key, and multiple shared keys KS can be registered for one vehicle 20. That is, in order to use multiple shared keys KS for one vehicle 20, multiple shared keys KS can exist for one vehicle 20.

[0041] Multiple sharing devices 50 include friend devices 51 and non-friend devices 52. Friend device 51 stores friend key information DKF representing friend key KF, which serves as shared key information DKS. Friend key information DKF is information related to shared key KS. Non-friend device 52 stores non-friend key information DKN representing non-friend key KN, which serves as shared key information DKS. Non-friend key information DKN is information related to shared key KS. The types of shared key KS include friend key KF and non-friend key KN.

[0042] The friend key KF is a shared key KS registered based on a direct registration request D21 from the owner device 40, as described later. Registration request D21 is a request for device 30 to store the friend key information DKF as key information DK. Registration request D21 is also a request for other devices 30 to store information related to the new shared key KS.

[0043] A non-friend key KN is a shared key KS registered based on a registration request D31 from a friend device 51, as described later. Registration request D31 is a request on device 30 to store non-friend key information DKN as new shared key information DKS. Registration request D31 is also a request on other devices 30 to store information related to the new shared key KS. A non-friend key KN is a shared key KS registered based on an indirect registration request from a sharing device 50 that is a device 30 different from the owner device 40.

[0044] The state of having a registered digital key means that the digital key can be used. In this state, vehicle 20 stores authentication information AT corresponding to the key information DK, and device 30 stores the key information DK corresponding to the authentication information AT. The authentication information AT is information related to the digital key. In the state of having a registered digital key, vehicle 20 stores information related to the digital key. The key information DK is information related to the digital key. In the state of having a registered digital key, device 30 stores information related to the digital key. If the key information DK is related to a shared key KS, the authentication information AT corresponding to that key information DK is also related to the shared key KS.

[0045] like Figure 3 As shown, the shared key information (DKS) includes shared key structure information (STS) and authentication package (ATP). The shared 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 shared key structure information (STS) also includes certificate information (ST5), vehicle public key information (ST7), and permission public key information (ST8). In other words, the shared key structure information (STS) is obtained by removing the device public key information (ST6) and permission information (ST9) from the owner key structure information (STO).

[0046] The authentication package ATP contains signature information ATP1, password information ATP2, valid start time information ATP3, valid period information ATP4, name information ATP5, device public key information ATP6, and authorization information ATP7.

[0047] The signature information ATP1 is used to indicate that the sharing device 50 is a legitimate object of the shared digital key. For example, in the case of a friend device 51, the signature information ATP1 indicates a signature based on the owner device 40. The owner signature information indicates that the owner device 40 signed the device public key PKD of friend device 51, as represented by the device public key information ATP6. Alternatively, for example, in the case of a non-friend device 52, the signature information ATP1 indicates a signature based on friend device 51. The friend signature information indicates that friend device 51 signed the device public key PKD of non-friend device 52, as represented by the device public key information ATP6.

[0048] Password information ATP2 indicates the pairing password PAS used to establish a secure channel when vehicle 20 is paired with owner device 40. Valid start time information ATP3 indicates the earliest date and time that the shared key KS can be used. Valid expiration information ATP4 indicates the latest date and time that the shared key KS can be used. Name information ATP5 indicates the name that identifies the shared device 50 storing the shared key information DKS. For example, through an operation from owner device 40, name information ATP5 is set for each shared device 50 as the name that can identify the shared key KS. Permission information ATP7 is information used to indicate the scope of functions that the device 30 storing permission information ATP7 can perform.

[0049] The scope of functions that can be implemented includes, for example, the number of shared keys KS that can be requested for registration, and the scope of vehicle 20 functions that can be implemented through digital key authentication. For instance, the owner device 40 can request to register more friend keys KF than the friend device 51 can request to register more non-friend keys KN.

[0050] The range of functions that can be implemented for vehicle 20 includes, for example, possible controls among engine start control, power supply control, door unlocking control, and door locking control. For instance, when the range of functions that can be implemented for vehicle 20 includes the three controls mentioned above, the range of functions that can be implemented for vehicle 20 is wider than when the range of functions that can be implemented for vehicle 20 is limited to door unlocking and locking control. More specifically, the range of functions that the friend device 51 can implement for vehicle 20 includes the three functions mentioned above, while the range of functions that the non-friend device 52 can implement for vehicle 20 includes power supply control and door unlocking and locking control.

[0051] Figure 1 The device server 60 shown relays communication between device 30 and management server 70. Figure 1 Only one device server 60 is shown in the diagram. However, device server 60 can also be set up for each category of device 30. That is, the device server 60 communicating with devices 30 of the first category and the device server 60 communicating with devices 30 of the second category can be different. For example, the category refers to the model of device 30, and device server 60 is set up for each model of device 30. For example, the category refers to the communication line used by device 30, and device server 60 is set up for each communication line used by device 30.

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

[0053] <Management Server 70>

[0054] The management server 70 manages multiple digital keys. The management server 70 can communicate with the vehicle 20 and multiple devices 30. The management server 70 includes an execution device 71, a storage device 72, and a communication module 73. The execution device 71 is a processing circuit that includes one or more processors that perform various processes according to a computer program (software). The communication module 73 communicates with the device server 60 via a wireless communication line. Furthermore, the communication module 73 can wirelessly communicate with the communication module 21 of the vehicle 20.

[0055] Storage device 72 stores the server program PS and the database DB.

[0056] The server program PS causes the execution device 71 to register the digital key with the database DB and delete the digital key from the database DB.

[0057] The database DB contains information that establishes corresponding information for each of the multiple digital keys, specifying the vehicle 20 and the registered device 30. The data DA contained in the database DB is partitioned for each vehicle 20. When a digital key is registered, the management server 70 stores information as data DA representing the device 30 storing the key information DK that displays that digital key. The management server 70 manages the digital keys by storing information related to the digital keys in the database DB as data DA.

[0058] like Figure 4 As shown, the data DA of a vehicle 20 contains information related to the type of digital key registered to the vehicle 20, the registered device 30, and the relationship between the registered devices 30. Digital keys are hierarchically structured according to their type. From top to bottom, the hierarchy consists of the owner key KO, friend key KF, and non-friend key KN. Higher-level digital keys have greater permissions.

[0059] Permissions include, for example, the number of shared keys KS that can be registered, and the control range of vehicle 20 that becomes possible through digital key authentication. Higher-level digital keys can request the registration of more shared keys KS. More specifically, for example, owner device 40 can request the registration of more friend keys KF than friend device 51 can request the registration of more non-friend keys KN.

[0060] Furthermore, for example, the higher the level of the digital key, the wider the control range of the vehicle 20 it can control. The control range of the vehicle 20 it can control includes, for example, possible controls among starting the engine, turning on the power, unlocking and locking the doors. For instance, when the control range of the vehicle 20 includes all three of these controls, it has a wider control range compared to when the control range is limited to unlocking and locking the doors. More specifically, the friend key KF can control the vehicle 20 with all three of these controls, while the non-friend key KN can only control the vehicle 20 with unlocking and locking the doors.

[0061] For a vehicle 20, the status of digital keys registered for seven devices 30 is explained. The seven devices 30 are devices 1 through 7 (30A to 30G). Furthermore, the digital key registered for each of devices 30A through 30G is designated as digital key DK1 through digital key DK7.

[0062] Device 30, which is registered as a digital key with owner key KO, is the first device 30A. That is, the first device 30A is the owner device 40. That is, the first digital key DK1 is the owner key KO.

[0063] Device 30, which is registered as a digital key with a shared key KS, includes second device 30B, third device 30C, fourth device 30D, fifth device 30E, sixth device 30F, and seventh device 30G. That is, second device 30B, third device 30C, fourth device 30D, fifth device 30E, sixth device 30F, and seventh device 30G are shared devices 50. In other words, all digital keys from second key DK2 to seventh key DK7 are shared keys KS.

[0064] More specifically, the devices 30 registered with the shared key KS and the friend key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are friend devices 51. The devices 30 registered with the shared key KS and the non-friend key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. That is, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

[0065] The relationships between the registered devices 30 contained in data DA are explained. The relationship between the second device 30B and the first device 30A is a relationship where a friend key KF is registered in the second device 30B based on a registration request from the first device 30A. That is, the second digital key DK2 is registered based on the first digital key DK1.

[0066] The relationship between the fifth device 30E and the first device 30A is based on a registration request from the first device 30A, whereby a friend key KF is registered in the fifth device 30E. That is, the fifth digital key DK5 is registered based on the first digital key DK1.

[0067] The relationship between the third device 30C and the second device 30B is based on a registration request from the second device 30B, whereby a non-friend key KN is registered in the third device 30C. That is, the third digital key DK3 is registered based on the second digital key DK2.

[0068] The relationship between the fourth device 30D and the second device 30B is based on a registration request from the second device 30B, whereby a non-friend key KN is registered in the fourth device 30D. That is, the fourth digital key DK4 is registered based on the second digital key DK2.

[0069] The relationship between the sixth device 30F and the fifth device 30E is based on a registration request from the fifth device 30E, where a non-friend key KN is registered in the sixth device 30F. That is, the sixth digital key DK6 is registered based on the fifth digital key DK5.

[0070] The relationship between the seventh device 30G and the fifth device 30E arises from a registration request from the fifth device 30E, resulting in the registration of a non-friend key KN in the seventh device 30G. Specifically, the seventh digital key DK7 is registered based on the fifth digital key DK5.

[0071] Thus, the data DA contains information related to the device 30 registered with the digital key. The data DA associates information with the device 30 that initiated the request to register the device 30. The data DA also includes information indicating which digital key was used to register each digital key.

[0072] Digital Key Registration

[0073] Next, the registration process 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 non-friend key KN. The following describes the series of processes from the state where no digital keys are registered to the state where digital keys are registered. In the following description, the process executed by execution device 27 will be described as the process executed by vehicle 20, the process executed by execution device 36 will be described as the process executed by device 30, and the process executed by execution device 71 will be described as the process executed by management server 70.

[0074] <Registration of Owner's Key>

[0075] like Figure 5 As shown, the management system 10 performs a series of processes to register the owner key KO of the vehicle 20. Furthermore, the device 30 that does not store key information DK representing the owner key KO, which serves as the owner device 40, is designated as the first device 30A.

[0076] In the management system 10, the key information DK, i.e., the owner key information DKO, representing the owner key KO of vehicle 20, is stored in the first device 30A through the registration of the owner key KO. The management system 10 also stores authentication information AT for authenticating the owner key KO in vehicle 20. Furthermore, if the owner key KO is authenticated by vehicle 20 and registered with the management server 70, control of vehicle 20 using the owner key KO becomes possible. Registration of the owner key KO requires an application program to be installed in the first device 30A.

[0077] When the management server 70 receives the registration request D11 of the owner key KO from the first device 30A, the management server 70 first performs the processing in step S11. In step S11, the management server 70 generates a pairing password PAS. Afterwards, the management server 70 sends information representing the pairing password PAS to the vehicle 20 and the first device 30A.

[0078] After receiving the pairing password PAS, when the vehicle 20 is set to pairing mode from the HMI 22, it goes into standby mode while being able to receive the password from the first device 30A, and the process proceeds to step S12.

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

[0080] In step S13, 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. Then, vehicle 20 sends generation data DC, used to generate the owner key KO, to the first device 30A via a secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information ST7 representing the vehicle public key PKV. If the first device 30A receives the generation data DC, it proceeds to step S14.

[0081] In step S14, the first device 30A generates owner key information DKO representing the owner key KO. Then, the first device 30A causes the process to proceed to step S15.

[0082] In step S15, the first device 30A stores the owner key information DKO. Thus, the first device 30A becomes the owner device 40. Afterwards, the first device 30A sends the certificate information ST5 associated with the owner key KO and the device public key information ST6 representing the device public key PKD to the vehicle 20.

[0083] When vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 proceeds to step S16. In step S16, vehicle 20 verifies certificate information ST5. Then, when the verification of certificate information ST5 is complete, vehicle 20 proceeds to step S17.

[0084] In step S17, vehicle 20 stores the device public key information ST6, representing the device public key PKD, as authentication information AT in storage device 28. Afterward, vehicle 20 sends a completion notification M11 to the first device 30A indicating that the storage of authentication information AT is complete.

[0085] When the first device 30A receives the completion notification M11, the first device 30A proceeds to step S18. In step S18, the first device 30A generates a key tracking request D12 for the owner key KO. The key tracking request D12 is a signal requesting the management server 70 to update the database DB. The first device 30A sends the key tracking request D12 for the owner key KO to the management server 70 via the device server 60.

[0086] When the management server 70 receives the key tracking request D12, it proceeds to step S19. In step S19, the management server 70 performs registration management of the owner key KO. Specifically, as the data DA of vehicle 20 in the database DB, the management server 70 stores the device 30 registered with the owner key KO as the first device 30A. Thus, the management system 10 concludes the series of processes for registering the owner key KO of vehicle 20 with the first device 30A.

[0087] <Register for Friend Key>

[0088] like Figure 6 As shown, the management system 10 performs a series of registration processes to register friend keys (KF). Device 30 that has become a friend device 51 through this series of processes, and which does not store friend key information (DKF), is designated as the second device 30B.

[0089] In owner device 40, by executing the operation of requesting the registration of friend key KF, owner device 40 first performs step S21. In step S21, owner device 40 sends the registration request D21 of friend key KF to the relay server (not shown in the figure). Afterwards, owner device 40 causes the process to proceed to step S22.

[0090] In step S22, the owner device 40 obtains invitation information IV1 from the relay server, which serves as information for sharing the digital key. Invitation information IV1 is, for example, a URL link. The URL link stores the sharing information SH1 required for sharing the digital key. Afterwards, the owner device 40 sends invitation information IV1 to the second device 30B.

[0091] Upon receiving invitation information IV1, the second device 30B proceeds to step S23. In step S23, 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 link source of the URL.

[0092] The shared information SH1 includes, for example, shared key structure information STS, password information ATP2, effective start time information ATP3, validity period information ATP4, and name information ATP5. The effective start time information ATP3, validity period information ATP4, and name information ATP5 are set by the owner device 40. Then, the second device 30B causes the process to proceed to step S24.

[0093] In step S24, the second device 30B uses the shared information SH1 to generate unsigned friend key information DKFN. Unsigned friend key information DKFN is friend key information DKF without signature information ATP1. Specifically, the second device 30B generates the information contained in the obtained shared information SH1 into the information of the unsigned friend key information DKFN. Afterwards, the second device 30B sends a completion notification M21 and a signature request D22 to the owner device 40. The completion notification M21 indicates that the upload of the generated unsigned friend key information DKFN to the URL link has been completed.

[0094] Subsequently, the owner device 40 receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 obtains the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 proceeds to step S25.

[0095] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 prompts the HMI 32 with the obtained unsigned friend key information DKFN and accepts an operation indicating consent to the registration of the friend key KF by the user of the owner device 40. During this operation, the owner device 40 generates signature information ATP1 based on the operation performed. Afterwards, the owner device 40 proceeds to step S26.

[0096] In step S26, the owner device 40 generates friend key information DKF by adding signature information ATP1 to the unsigned friend key information DKFN. The owner device 40 uploads the generated friend key information DKF to the URL link that serves as invitation information IV1. The owner device 40 sends a completion notification M22 to the second device 30B, indicating that the upload of the generated friend key information DKF to the URL link has been completed.

[0097] If the second device 30B receives the completion notification M22, it proceeds to step S27. In step S27, the second device 30B downloads and stores the friend key information DKF. Thus, the second device 30B becomes the friend device 51. Afterwards, the second device 30B proceeds to step S28.

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

[0099] When the management server 70 receives a key tracking request D23 from a friend's key KF, the management server 70 proceeds to step S29. In step S29, the management server 70 performs registration management of the friend's key KF.

[0100] Specifically, management server 70 checks whether the friend key KF, which is the target of key tracking request D23, is listed on the rejection list. The rejection list contains friend keys KF that have received deletion requests and shared keys KS that are not friend keys KN. When friend key KF is listed on the rejection list, management server 70 sends a notification to second device 30B that it cannot respond to key tracking request D23.

[0101] On the other hand, if the friend key KF that received the key tracking request D23 is not registered in the rejection list, the management server 70 registers the information of the friend key KF that received the key tracking request D23 in the database DB. The management server 70 stores the friend key information DKF that received the friend key KF as data DA in the database DB. The management server 70 stores in the database DB that the device 30 registered as friend device 51 is the second device 30B as data DA. The management server 70 stores information indicating the relationship between the second device 30B and the owner device 40 with reference to the obtained friend key information DKF. Specifically, the management server 70 stores that the second device 30B is the device 30 that has the friend key KF registered according to the registration request D21 from the owner device 40.

[0102] Subsequently, management server 70 sends the authentication packet ATP from the friend key information DKF and a storage request D24 requesting the storage of the authentication packet ATP to vehicle 20. That is, management server 70 sends device public key information ST6 representing the device public key PKD of friend device 51 to vehicle 20. Management server 70 notifies vehicle 20 that the owner device 40 has signed the device public key PKD.

[0103] When vehicle 20 receives storage request D24 and authentication packet ATP from management server 70, it proceeds to step S30. In step S30, vehicle 20 stores the received authentication packet ATP as authentication information AT for authenticating friend key KF.

[0104] After completing the registration management, the management server 70 sends a key tracking completion notification M23 to the second device 30B.

[0105] Upon receiving the key tracking completion notification M23, the second device 30B performs step S31. In step S31, the second device 30B prompts the HMI 32 to display information indicating the completion of friend key KF registration. For example, the second device 30B displays an image indicating the completion of friend key KF registration on the HMI 32. Thus, the management system 10 concludes the series of processes for friend key KF registration.

[0106] Registration with a non-friend key

[0107] like Figure 7 As shown, the management system 10 performs a series of registration processes to register non-friend key KN. Device 30, which has not stored non-friend key information DKN and has been designated as a non-friend device 52 through this series of processes, is designated as a third device 30C.

[0108] By performing the operation of requesting registration of a non-friend key KN in the friend device 51, the friend device 51 first proceeds to step S41. In step S41, the friend device 51 sends the registration request D31 for the non-friend key KN to the relay server (not shown in the figure). Then, the friend device 51 proceeds to step S42.

[0109] In step S42, the friend device 51 obtains invitation information IV2 from the relay server, which serves as information for sharing the digital key. Invitation information IV2 is, for example, a URL link. The URL link stores the sharing information SH2 required for sharing the digital key. The friend device 51 then sends invitation information IV2 to the third device 30C.

[0110] Upon receiving invitation information IV2, the third device 30C performs step S43. In step S43, the third device 30C obtains the shared information SH2 based on the invitation information IV2. Specifically, the second device 30B downloads the shared information SH2 from the URL link.

[0111] The shared information SH2 includes, for example, shared key structure information STS, password information ATP2, valid start time information ATP3, validity period information ATP4, and name information ATP5. The valid start time information ATP3, validity period information ATP4, and name information ATP5 are set by the friend device 51. Then, the third device 30C causes the process to proceed to step S44.

[0112] In step S44, the third device 30C uses the shared information SH2 to generate unsigned non-friend key information DKNN. The unsigned non-friend key information DKNN is a non-friend key information DKN without signature information ATP1. Specifically, the third device 30C generates the information contained in the obtained shared information SH2 into the information of the unsigned non-friend key information DKNN. Afterwards, the third device 30C sends a completion notification M31 and a signature request D32, whereby the notification M31 indicates that the upload of the generated unsigned non-friend key information DKNN to the URL link has been completed.

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

[0114] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 prompts the HMI 32 with the obtained unsigned non-friend key information DKNN, and accepts an operation performed by the user of the friend device 51 indicating agreement to the generation of the non-friend key KN. When the operation is performed, the friend device 51 obtains a signature based on the operation. Afterwards, the friend device 51 proceeds to step S46.

[0115] In step S46, the friend device 51 generates non-friend key information DKN by adding signature information ATP1 to unsigned non-friend key information DKNN. The friend device 51 uploads the generated non-friend key information DKN to the URL link, which serves as invitation information IV2. The friend device 51 sends a completion notification M32 to the third device 30C, indicating that the uploading of the generated non-friend key information DKN to the URL link has been completed.

[0116] Upon receiving the completion notification M32, the third device 30C proceeds to step S47. In step S47, the third device 30C downloads and stores the non-friend key information DKN. Thus, the third device 30C becomes a non-friend device 52. Afterwards, the third device 30C proceeds to step S48.

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

[0118] When the management server 70 receives a key tracking request D33 from a non-friend key KN, the management server 70 proceeds to step S49. In step S49, the management server 70 performs registration management for the non-friend key KN.

[0119] Specifically, the management server 70 confirms that the non-friend key KN, which is the object of the key tracking request D33, is not registered in the rejection list. If the non-friend key KN is registered in the rejection list, the management server 70 sends a notification to the third device 30C that it cannot respond to the key tracking request D33.

[0120] On the other hand, if the non-friend key KN is not registered in the rejection list, the management server 70 registers the information of the non-friend key KN, which is the object of the key tracking request D33, in the database DB. The management server 70 stores the non-friend key information DNK of the non-friend key KN that received the key tracking request D33 as data DA in the database DB. The management server 70 stores in the database DB that the device 30 registered as a non-friend device 52 is a third device 30C as data DA. The management server 70 stores the relationship between the third device 30C and the friend device 51 with reference to the obtained non-friend key information DKN. Specifically, the management server 70 stores that the third device 30C is a device 30 that has a non-friend key KN registered according to the registration request D31 from the friend device 51.

[0121] Subsequently, management server 70 sends the authentication packet ATP from the non-friend key information DKN and a storage request D34 requesting the storage of the authentication packet ATP to vehicle 20. That is, management server 70 sends device public key information ST6 representing the device public key PKD of non-friend device 52 to vehicle 20. Management server 70 notifies vehicle 20 that the signature of friend device 51 has been made in the device public key PKD.

[0122] Subsequently, when vehicle 20 receives the authentication packet ATP and storage request D34, it proceeds to step S50. In step S50, 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 non-friend key KN.

[0123] After completing the registration management, the management server 70 sends a key tracking completion notification M33 to the second device 30B.

[0124] When the second device 30B receives the key tracking completion notification M33, it performs step S51. In step S51, the third device 30C displays a message on the HMI 32 indicating that the registration of the non-friend key KN is complete. For example, the third device 30C displays an image indicating that the registration of the non-friend key KN is complete on the HMI 32. Thus, the management system 10 concludes the series of processes for registering the non-friend key KN.

[0125] <Changes in the scope of vehicle 20's functions>

[0126] The authentication information AT stored in the storage device 28 of vehicle 20 contains the range of functions of vehicle 20 that can be implemented by the digital key. That is, the storage device 28 of vehicle 20 stores the range of functions of vehicle 20 that can be implemented by the digital key.

[0127] The functions of vehicle 20 include functions that involve driving vehicle 20 and functions that do not involve driving vehicle 20. Functions that involve driving vehicle 20 include, for example, controlling the power supply of vehicle 20, controlling the engine start, and controlling the vehicle 20 to start. Functions that do not involve driving vehicle 20 include, for example, controlling the unlocking and locking of vehicle 20's doors, and controlling the unlocking and locking of vehicle 20's trunk space only.

[0128] For example, when the rental operator or sharing operator is the owner of vehicle 20, sometimes a period during which the digital key user can use vehicle 20 is specified, namely the usage period UT. During the period outside the usage period UT, the range of functions of vehicle 20 that the digital key can perform will be narrowed compared to the range of functions of vehicle 20 that the digital key can perform during the usage period UT.

[0129] Storage device 28 stores the start time of the utilization period UT, i.e., the utilization start time UST. Storage device 28 stores the end time of the utilization period UT, i.e., the utilization end time UET.

[0130] When the utilization end time UET is reached, the execution device 27 determines that the utilization period UT has ended. When the utilization start time UST is reached, the execution device 27 determines that the utilization period UT has started. In the following description, the processing performed by the execution device 27 will be described as the processing performed by the vehicle 20.

[0131] If, before the use of vehicle 20 begins, authentication is performed between vehicle 20 and device 30 storing information related to the second digital key DK2, then vehicle 20 will... Figure 8 The process shown in step S60.

[0132] like Figure 8 As shown, in step S60, vehicle 20 changes the range of functions of vehicle 20 that can be implemented by the second digital key DK2 back to the range of functions before use. For example, vehicle 20 changes the range of functions of vehicle 20 in such a way that it can only use functions that involve driving vehicle 20 and functions that do not involve driving vehicle 20. After that, vehicle 20 causes the process to proceed to step S61.

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

[0134] In step S62, vehicle 20 changes the scope of its functions to the scope of functions used during the UT period. For example, vehicle 20 changes the scope of its functions in a way that allows it to simultaneously utilize functions involved in driving vehicle 20 and functions not involved in driving vehicle 20. Then, vehicle 20 causes the process to proceed to step S63.

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

[0136] In step S64, vehicle 20 changes the scope of its functions to the scope of functions in a fade-out state. For example, vehicle 20 changes the scope of its functions in such a way that it can utilize only the functions that participate in driving vehicle 20 and the functions that do not participate in driving vehicle 20. Then, vehicle 20 causes the process to proceed to step S65.

[0137] It should be noted that the fade-out state is the deletion of the state of the second digital key DK2 whose usage period has ended, provided certain conditions are met. These conditions include, for example, other digital keys being authenticated by vehicle 20.

[0138] In step S65, vehicle 20 determines whether other digital keys have been authenticated by vehicle 20. For example, if authentication has been performed between vehicle 20 and a fifth device 30E storing information related to the fifth digital key DK5 (step S65: Yes), vehicle 20 proceeds to step S66. If other digital keys have not been authenticated by vehicle 20 (step S65: No), vehicle 20 repeatedly executes the process of step S65.

[0139] In step S66, vehicle 20 performs a process to delete information related to the second digital key DK2, which has become faded out. As a result, the user of the second device 30B, which stores information related to the second digital key DK2, cannot utilize the functions of vehicle 20. Afterwards, vehicle 20 terminates this series of processes.

[0140] The process of deleting information related to the second digital key DK2 shown in step S66 is... Figure 9 The series of processes shown in steps S70 to S77.

[0141] like Figure 9 As shown, vehicle 20, which has begun the process of deleting information related to the second digital key DK2, proceeds to step S70. In step S70, if vehicle 20 generates a deletion request D70 to delete the friend key information DKF representing the second digital key DK2, it sends the generated deletion request D70 to the management server 70.

[0142] When the management server 70 receives the deletion request D70, it proceeds to step S71. In step S71, the management server 70 generates a deletion instruction D71. The deletion instruction D71 is an instruction to delete the friend key information DKF stored on the second device 30B. The management server 70 sends the deletion instruction D71 to the second device 30B.

[0143] When the second device 30B receives the deletion command D71, it proceeds to step S72. In step S72, the second device 30B deletes the friend key information DKF according to the deletion command D71. Furthermore, the second device 30B sends a completion notification M71 to the management server 70, indicating that the deletion according to the deletion command D71 has been completed.

[0144] When management server 70 receives completion notification M71, management server 70 proceeds to step S73. In step S73, management server 70 stores the history of the deleted friend key information DKF in the second device 30B. Afterwards, management server 70 proceeds to step S74.

[0145] In step S74, the management server 70 generates a deletion instruction D72 for authentication information AT. This deletion instruction D72 deletes the authentication information AT used to authenticate the second digital key DK2, which is the object of the deletion request D70. The management server 70 sends the deletion instruction D72 to the vehicle 20.

[0146] When vehicle 20 receives deletion instruction D72, it proceeds to step S75. In step S75, vehicle 20, according to deletion instruction D72, deletes the authentication information AT used to authenticate the second digital key DK2, which is the object of deletion request D70. That is, vehicle 20 deletes the authentication packet ATP of the second digital key DK2 stored in database DB. Afterward, vehicle 20 sends a completion notification M72 to management server 70, which indicates that the deletion of authentication information AT according to deletion instruction D72 has been completed.

[0147] Upon receiving the completion notification M72, the management server 70 proceeds to step S76. In step S76, the management server 70 stores the history of deleting authentication information AT, which is used to authenticate the second digital key DK2, the object of deletion in the series of deletion-related processes in the vehicle 20. Afterwards, the management server 70 proceeds to step S77.

[0148] In step S77, the management server 70 updates the database DB. Specifically, the management server 70 deletes information related to the second device 30B, which has the second digital key DK2 as the deletion object in this series of processes, from the data DA of vehicle 20 in the database DB.

[0149] <The Role of the First Implementation Method>

[0150] When the range of functions of vehicle 20 that can be implemented by the second digital key DK2 is narrowed, the user of the second device 30B, which stores information related to the second digital key DK2, is restricted from using vehicle 20.

[0151] <Effects of the First Implementation Method>

[0152] (1-1) Vehicle 20 can restrict the use of vehicle 20 by the user of the second digital key DK2 during the period outside the period of use UT compared to the period of use UT.

[0153] (1-2) The scope of functions of vehicle 20 includes functions for driving vehicle 20 and functions for not driving vehicle 20. Outside of the usage period UT, the scope of functions of vehicle 20 cannot be changed by the user of the second digital key DK2 in a way that prevents them from using the functions for driving vehicle 20. Even outside of the usage period UT, there is a demand from users who wish to use the functions for not driving vehicle 20. On the other hand, outside of the usage period UT, there is a demand to restrict the use of functions for driving vehicle 20. Outside of the usage period UT, the scope of functions of vehicle 20 cannot be changed by the user of the second digital key DK2 in a way that prevents them from using the functions for driving vehicle 20. Vehicle 20 can restrict the user of the second digital key DK2 from driving vehicle 20 outside of the usage period UT, and even outside of the usage period UT, the user of the second digital key DK2 can use the functions for not driving vehicle 20.

[0154] (1-3) Vehicle 20 stores the start time of the utilization period UT, i.e., the utilization start time UST. When the utilization start time UST is reached, it is determined that the utilization period UT has started. Vehicle 20 can determine that the utilization period UT has started without the operation of the user of the second digital key DK2.

[0155] (1-4) Vehicle 20 stores the time when the usage period UT ends, i.e., the usage end time UET. When the usage end time UET is reached, it is determined that the usage period UT has ended. Vehicle 20 can determine that the usage period UT has ended without the operation of the user of the second digital key DK2.

[0156] (Second Implementation)

[0157] The following is for reference Figure 10The vehicle 20 according to the second embodiment will be described. In the second embodiment, the description will focus on the differences from the first embodiment. In the second embodiment, the vehicle 20 has an interface that can be operated by a user of the vehicle 20. Specifically, the vehicle 20 has an HMI 22 as the interface. When the vehicle 20 performs an operation to start using the vehicle 20 via the interface, it is determined that the utilization period UT has started. When the vehicle 20 performs an operation to end using the vehicle 20 via the interface, it is determined that the utilization period UT has ended. Hereinafter, the description will focus on the differences from the first embodiment; for points that are the same, the description will be simplified or omitted.

[0158] Before using vehicle 20, if authentication based on short-range wireless communication is performed between vehicle 20 and device 30 storing information related to the second digital key DK2, then vehicle 20 will... Figure 10 The process shown in step S80.

[0159] In step S80, the vehicle 20 changes the range of functions that the second digital key DK2 can implement to the range of functions it had before it was first used. Step S80 and Figure 8 The steps shown in step S60 are the same, so detailed explanations are omitted. Afterwards, vehicle 20 initiates the process in step S81.

[0160] In step S81, vehicle 20 determines whether an operation to start utilizing vehicle 20 has been performed via the interface. Specifically, vehicle 20 determines whether an operation to start utilizing vehicle 20 has been performed via HMI 22. If an operation to start utilizing vehicle 20 has been performed (step S81: Yes), vehicle 20 proceeds to step S82. If an operation to start utilizing vehicle 20 has not been performed (step S81: No), vehicle 20 repeatedly executes the process of step S81.

[0161] In step S82, vehicle 20 changes the scope of its function to the scope of the function of UT during the utilization period. Step S82 and Figure 8 The steps shown in step S62 are the same, so detailed explanations are omitted. Afterwards, vehicle 20 initiates the process in step S83.

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

[0163] In step S84, vehicle 20 changes the range of its functions to the range of functions in the fade-out state. Step S84 and Figure 8 The steps shown in step S64 are the same, so detailed explanations are omitted. Afterwards, vehicle 20 initiates the process in step S85.

[0164] In step S85, vehicle 20 determines whether other digital keys have been authenticated by vehicle 20. For example, if authentication has been performed between vehicle 20 and a fifth device 30E storing information related to the fifth digital key DK5 (step S85: Yes), vehicle 20 proceeds to step S86. If other digital keys have not been authenticated by vehicle 20 (step S85: No), vehicle 20 repeatedly executes the process of step S85.

[0165] In step S86, vehicle 20 performs the process of deleting information related to the second digital key DK2 becoming faded out. Step S86 and Figure 8 The steps shown in step S66 are the same, so detailed explanations are omitted. Afterwards, vehicle 20 completes this series of processes.

[0166] <Function of the Second Implementation Method>

[0167] Vehicle 20 has an HMI 22 as an interface that can be operated by a user. When vehicle 20 performs an operation to start using vehicle 20 via HMI 22, it is determined that the usage period UT has started. When vehicle 20 performs an operation to end using vehicle 20 via HMI 22, it is determined that the usage period UT has ended.

[0168] <Effects of the Second Implementation>

[0169] In the second embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following effects are also achieved.

[0170] (2-1) Vehicle 20 enables the user to begin using UT during the period.

[0171] (2-2) Vehicle 20 enables the user to terminate the use period UT.

[0172] (Third Implementation)

[0173] The following is for reference Figure 11 The vehicle 20 according to the third embodiment will be described. In the third embodiment, the description will focus on the differences from the first embodiment. In the third embodiment, when the vehicle 20 receives the utilization start notification USN output from the slave device 30, it determines that the utilization period UT has started. When the vehicle 20 receives the utilization end notification UEN output from the slave device 30, it determines that the utilization period UT has ended.

[0174] Vehicle 20 is equipped with a communication device capable of wirelessly communicating with device 30, which stores information related to a digital key. Specifically, vehicle 20 is equipped with a BLE module 23, a UWB module 24, and an NFC module 25 as communication devices for short-range wireless communication. Vehicle 20 receives a Usage Start Notification (USN) and a Usage End Notification (UEN) from device 30 via at least one of BLE communication, UWB communication, and NFC communication. The communication device used by vehicle 20 to receive the Usage Start Notification (USN) from device 30 and the communication device used by vehicle 20 to receive the UEN from device 30 may be different from each other. Hereinafter, the description will focus on the points that differ from the first embodiment; for points that are the same, the description will be simplified or omitted.

[0175] like Figure 11 As shown, in step S90, the second device 30B, which stores information related to the second digital key DK2, generates an authentication notification M90 for authentication based on short-range wireless communication. Then, the second device 30B uses short-range wireless communication to output the authentication notification M90 to the vehicle 20.

[0176] In step S91, vehicle 20 authenticates the received authentication notification M90. Afterwards, vehicle 20 changes the scope of functions that the second digital key DK2 can implement back to the scope of functions it had before use. Step S91 and... Figure 8 The steps shown in step S60 are the same, so detailed explanations are omitted.

[0177] In step S92, the second device 30B generates a Start of Use Notification (USN). For example, the second device 30B generates the USN when the user performs the operation to generate the USN via its HMI 32. Alternatively, the second device 30B may be configured to generate the USN when the start of use time (UST) is reached. Afterward, the second device 30B outputs the USN to the vehicle 20 using near-field communication.

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

[0179] In step S94, the second device 30B generates a usage end notification UEN. For example, the second device 30B generates the usage end notification UEN when it has performed the operation of generating the usage end notification UEN from the user via its HMI 32. Alternatively, the second device 30B may be configured to generate the usage end notification UEN when the usage end time UET occurs. Afterwards, the second device 30B outputs the usage end notification UEN to the vehicle 20 using short-range wireless communication.

[0180] When vehicle 20 receives the end-of-use notification UEN, it proceeds to step S95. In step S95, vehicle 20 determines that the use period UT has ended. That is, vehicle 20 determines that the use period UT has ended upon receiving the end-of-use notification UEN from device 30. In step S95, vehicle 20 changes the scope of its functions to the scope of functions in the fade-out state. Step S95 and... Figure 8 The steps shown in step S64 are the same, so detailed explanations are omitted.

[0181] The fifth device 30E is a device 30 that stores information related to the fifth digital key DK5. The fifth device 30E is a device 30 other than the second device 30B. In step S96, the fifth device 30E generates an authentication notification M91 for authentication based on short-range wireless communication. Then, the fifth device 30E outputs the authentication notification M91 to the vehicle 20 using short-range wireless communication.

[0182] When vehicle 20 receives authentication notification M91 from fifth device 30E, it proceeds to step S97. In step S97, vehicle 20 performs the process of deleting information related to the second digital key DK2, which has become faded out. Step S97 and Figure 8 The steps shown in step S66 are the same, so detailed explanations are omitted. Afterwards, vehicle 20 initiates the process in step S98.

[0183] In step S98, vehicle 20 authenticates the received authentication notification M91. Afterwards, vehicle 20 changes the scope of functions that the fifth digital key DK5 can implement back to the scope of functions it had before use. Step S98 and... Figure 8 The steps shown in step S60 are the same, so detailed explanations are omitted.

[0184] <The Role of the Third Implementation Method>

[0185] Vehicle 20 is equipped with a BLE module 23, a UWB module 24, and an NFC module 25 as a communication device capable of wirelessly communicating with the second device 30B. When vehicle 20 receives a utilization start notification (USN) from the second device 30B, it determines that the utilization period (UT) has started. When vehicle 20 receives a utilization end notification (UEN) from the second device 30B, it determines that the utilization period (UT) has ended.

[0186] <Effects of the Third Implementation Method>

[0187] In the third embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following effects are also achieved.

[0188] (3-1) Vehicle 20 can determine that the utilization period UT has started based on the utilization start notification USN output from the second device 30B.

[0189] (3-2) Vehicle 20 can determine that the utilization period UT has ended based on the utilization end notification UEN output from the second device 30B.

[0190] (Fourth Implementation)

[0191] The following is for reference Figure 12 The vehicle 20 according to the fourth embodiment will be described. In the fourth embodiment, the description will focus on the differences from the third embodiment. In the fourth embodiment, when the vehicle 20 receives the utilization start notification USN output from the management server 70, it determines that the utilization period UT has started. When the vehicle 20 receives the utilization end notification UEN output from the management server 70, it determines that the utilization period UT has ended.

[0192] Vehicle 20 is equipped with a communication device capable of wirelessly communicating with management server 70. Specifically, vehicle 20 is equipped with communication module 21 as a communication device. Vehicle 20 receives utilization start notification USN and utilization end notification UEN from management server 70 via communication module 21. Hereinafter, the description will focus on the points that differ from other embodiments, and the description of the same points will be simplified or omitted.

[0193] like Figure 12 As shown, in step S100, the second device 30B, which stores information related to the second digital key DK2, generates an authentication notification M100 for authentication based on short-range wireless communication. Then, the second device 30B outputs the authentication notification M100 to the vehicle 20 using short-range wireless communication.

[0194] In step S101, vehicle 20 authenticates the received authentication notification M100. Afterwards, vehicle 20 changes the scope of functions that the second digital key DK2 can implement back to the scope of functions it had before use. Step S101 and... Figure 8 The steps shown in step S60 are the same, so detailed explanations are omitted. Afterwards, vehicle 20 initiates the process at step S102.

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

[0196] Upon receiving the authentication notification M102, the management server 70 proceeds to step S103. In step S103, the management server 70 generates a utilization start notification (USN). Then, the management server 70 uses the communication module 73 to output the utilization start notification (USN) to the vehicle 20.

[0197] When vehicle 20 receives the utilization start notification USN, it proceeds to step S104. In step S104, vehicle 20 determines that the utilization period UT has started. That is, when vehicle 20 receives the utilization start notification USN output from management server 70, it determines that the utilization period UT has started. In step S104, vehicle 20 changes the scope of its functions to the scope of the functions during the utilization period UT. Step S104 and... Figure 8 The steps shown in step S62 are the same, so detailed explanations are omitted.

[0198] In step S105, the management server 70 generates a utilization end notification UEN. For example, the management server 70 generates the utilization end notification UEN when the utilization end time UET is reached. Afterwards, the management server 70 uses the communication module 73 to output the utilization end notification UEN to the vehicle 20.

[0199] When vehicle 20 receives the End of Use Notification UEN, it proceeds to step S106. In step S106, vehicle 20 determines that the usage period UT has ended. That is, when vehicle 20 receives the End of Use Notification UEN output from management server 70, it determines that the usage period UT has ended. In step S106, vehicle 20 changes the scope of its functions to the scope of functions in the fade-out state. Step S106 and... Figure 8 The steps shown in step S64 are the same, so detailed explanations are omitted.

[0200] The subsequent processing is the same as in the third embodiment, therefore detailed descriptions are omitted. Specifically, Figure 12 The steps S107 shown are Figure 11 The steps shown in step S96 are the same, so detailed explanations are omitted. Figure 12 The steps S108 shown are Figure 11 The steps shown in step S97 are the same, so detailed explanations are omitted. Figure 12 The steps S109 and S109 shown are Figure 11 The steps shown in step S98 are the same, so detailed explanations are omitted.

[0201] <Function of the Fourth Implementation Method>

[0202] Vehicle 20 is equipped with a communication module 21 as a communication device capable of wirelessly communicating with management server 70. When vehicle 20 receives a utilization start notification (USN) from management server 70, it determines that the utilization period (UT) has started. When vehicle 20 receives a utilization end notification (UEN) from management server 70, it determines that the utilization period (UT) has ended.

[0203] <Effects of the Fourth Implementation>

[0204] In the fourth embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following effects are also achieved.

[0205] (4-1) Vehicle 20 can determine that the utilization period UT has started based on the utilization start notification from the management server 70 output to the USN.

[0206] (4-2) Vehicle 20 can determine that the utilization period UT has ended based on the utilization end notification UEN output from the management server 70.

[0207] (Fifth Implementation)

[0208] The following is for reference Figure 13 The vehicle 20 according to the fifth embodiment will be described. In the fifth embodiment, the description will focus on the differences from the first embodiment. Hereinafter, the description will focus on the differences from the first embodiment, and the same points will be simplified or omitted.

[0209] In the fifth embodiment, vehicle 20 obtains its current location. For example, vehicle 20 may also obtain its location from a device 30 authenticated by vehicle 20. Specifically, the device 30 authenticated by vehicle 20 obtains its location information. Vehicle 20 obtains the location information obtained by device 30 via near-field wireless communication. Vehicle 20 considers the location of device 30 as its own location. Vehicle 20 may also obtain its location from management server 70 via communication module 21.

[0210] For example, vehicle 20 can also be configured to obtain its position from a location information acquisition system provided by vehicle 20. Such a location information acquisition system could be GNSS (Global Navigation Satellite System), RTK (Real-Time Kinematic), or LiDAR (Light Detection and Ranging). Vehicle 20 can also be configured to obtain its position from images of its surroundings captured by external cameras mounted on vehicle 20.

[0211] If vehicle 20 is located within a predetermined specific area SP during a period other than the utilization period UT, it can utilize a portion of the range of functions of vehicle 20. If vehicle 20 is located outside the specific area SP during a period other than the utilization period UT, it will not utilize the functions of vehicle 20.

[0212] <Function of the Fifth Implementation Method>

[0213] like Figure 13 As shown, the specific area SP is the predetermined first parking lot PA1. The second parking lot PA2 is located outside the specific area SP.

[0214] During periods other than the usage period of vehicle 20 (UT), if vehicle 20 is located in the second parking lot PA2, vehicle 20 will not allow the user of the digital key authenticated by vehicle 20 to use the functions of vehicle 20.

[0215] When vehicle 20 is located within the first parking lot PA1 outside of the period of use of vehicle 20 (UT), vehicle 20 enables users of the digital key authenticated by vehicle 20 to utilize a portion of the functions of vehicle 20. For example, vehicle 20 enables users of the digital key authenticated by vehicle 20 to utilize functions that do not involve driving vehicle 20.

[0216] Even outside the usage period UT, there are users who require the convenience of unlocking the doors of vehicle 20 in specific areas SP, such as designated parking lots, to load and unload goods. On the other hand, outside the usage period UT, there are owners of vehicle 20 who do not wish to use vehicle 20 indefinitely.

[0217] <Effects of the Fifth Implementation Method>

[0218] In the fifth embodiment, in addition to the effects shown in (1-1) and (1-2) of the first embodiment, the following effects are also achieved.

[0219] (5-1) Vehicle 20 can simultaneously meet the needs of the users of vehicle 20 and the needs of the owners of vehicle 20.

[0220] <Example of a modification to the fifth implementation>

[0221] The fifth embodiment described above can be modified and implemented as follows.

[0222] The specific area SP is not limited to the first parking lot PA1. The specific area SP can be set to any area.

[0223] <Example of Change>

[0224] As elements that can be modified together in the above embodiments, the following elements exist. The following modification examples can be combined with each other to be implemented within the scope of technical non-contradiction.

[0225] <Changes in the scope of functionality> Vehicle 20 may also change the scope of its functions during periods other than the usage period UT, such that neither the functions of driving vehicle 20 nor the functions of not driving vehicle 20 are available.

[0226] The range of functions of vehicle 20 before the start of the utilization period UT, the range of functions of vehicle 20 during the utilization period UT, and the range of functions of vehicle 20 after the end of the utilization period UT can also be set to different ranges of functions.

[0227] <Usage Period UT> The determination of whether the utilization period UT has started and the determination of whether the utilization period UT has ended in each implementation can be appropriately combined. For example, vehicle 20 may determine that the utilization period UT has started when the utilization start time UST is reached, and determine that the utilization period UT has ended when the operation to end the utilization of vehicle 20 is performed via HMI 22. For example, vehicle 20 may also determine that the utilization period UT has started when it receives the utilization start notification USN output from the second device 30B, and determine that the utilization period UT has ended when the utilization end time UET is reached.

[0228] The storage device 28 of vehicle 20 may also store multiple conditions for determining that the utilization period UT has started. The execution device 27 of vehicle 20 may also determine that the utilization period UT has started when at least one of the multiple conditions is met. The execution device 27 of vehicle 20 may also determine that the utilization period UT has started when all of the multiple conditions are met. The execution device 27 of vehicle 20 may also determine that the utilization period UT has started when more than half of the multiple conditions are met.

[0229] The storage device 28 of vehicle 20 may also store multiple conditions for determining that the utilization period UT has ended. The execution device 27 of vehicle 20 may also determine that the utilization period UT has ended when at least one of the multiple conditions for determining that the utilization period UT has ended is met. The execution device 27 of vehicle 20 may also determine that the utilization period UT has ended when all of the multiple conditions for determining that the utilization period UT has ended are met. The execution device 27 of vehicle 20 may also determine that the utilization period UT has ended when more than half of the multiple conditions for determining that the utilization period UT has ended are met.

[0230] <Certification Notification M91>

[0231] Other devices 30 that send authentication notifications to M91 are not limited to the fifth device 30E. Other devices 30 that send authentication notifications to M91 can also be friend devices 51 other than the fifth device 30E. Other devices 30 that send authentication notifications to M91 can also be non-friend devices 52.

[0232] <Management System 10> Vehicle 20 may or may not include any of the BLE module 23, UWB module 24, and NFC module 25. Vehicle 20 can communicate wirelessly with device 30 as long as it has at least one of these modules. Alternatively, vehicle 20 is not limited to these modules; it only needs to have a module for short-range wireless communication with device 30.

[0233] It could also be a digital key for ECU authentication that is different from the vehicle management device 26 among the multiple ECUs of the vehicle 20.

[0234] Matters related to the digital keys in the above embodiments may also be exempt from CCC regulations.

[0235] The vehicle management device 26 is not limited to the digital key ECU. For example, the vehicle management device 26 can also be a central ECU that uniformly manages multiple ECUs of the vehicle 20.

[0236] In the above embodiment, the vehicle management device 26 includes an execution device 27, which is a processing circuit including one or more processors that perform various processes according to a computer program (software). However, the execution device 27 may also be a processing circuit including one or more dedicated hardware circuits such as application-specific integrated circuits (ASICs) that perform at least a portion of the various processes. Alternatively, the execution device 27 may also be a processing circuit including a combination of one or more processors and one or more dedicated hardware circuits. The processor includes a CPU and memories such as RAM and ROM. The memories store program code or instructions configured to cause the CPU to perform processes. Memory, i.e., computer-readable media, includes all available media that can be accessed by a general-purpose or special-purpose computer. The same applies to the execution device 36 of the device 30 and the execution device 71 of the management server 70.

[0237] Device 30 is not limited to smartphones. It could also be a smartwatch. Additionally, device 30 could also be a designated server. In this case, the designated server could also include device 30. For example, if the rental operator or sharing operator is the owner of vehicle 20, the owner's device 40 could also be included in the designated server. Furthermore, for example, a friend's device 51 could also be included in the designated server.

[0238] In the above embodiments, the digital key has a hierarchy arranged in the order of owner key KO, friend key KF, and non-friend key KN. The higher the level of the digital key, the greater the permissions are set. However, the digital key may not be configured so that higher levels necessarily have greater permissions. For example, the owner key KO, friend key KF, and non-friend key KN may be assigned the same level of permissions.

[0239] The shared device 50, as described in the above embodiment, has the function of accepting a shared key KS. The device 30, which, like the shared device 50, has the function of accepting a digital key, is sometimes referred to as a receiving device.

[0240] Device server 60 does not need to be configured for each category of device 30. It is sufficient that multiple devices 30 can communicate wirelessly with management server 70. Alternatively, device server 60 can be omitted from management system 10. In management system 10, it is sufficient that multiple devices 30 can directly communicate wirelessly with management server 70.

[0241] The management server 70 can also consist of multiple servers. For example, the management server can consist of a server that stores the database DB and a server that executes the server program PS. Alternatively, the management server 70 can also consist of a server that communicates with the vehicle 20 and a server that communicates with the equipment server 60, and these servers can communicate with each other.

[0242] Management server 70 may not store database DB. Management server 70 can be configured to use at least one digital key in management system 10, and the combination of key information DK from management device 30 and authentication information AT from vehicle management device 26.

[0243] Deleting a digital key refers to changing a digital key from a usable state to an unusable state. In the above embodiments, if either the authentication information AT or the key information DK is deleted from a digital key, the digital key becomes unusable.

[0244] Therefore, deleting a digital key refers to deleting at least one of the information related to the digital key stored in the vehicle management device 26, namely the authentication information AT, and the information related to the digital key stored in the device 30, namely the key information DK. It should be noted that if both the authentication information AT and the key information DK are deleted, the digital key is deleted first, following the deletion of either the authentication information AT or the key information DK.

[0245] <Regarding various information> The information related to the digital key stored in the vehicle management device 26 is not limited to authentication information AT; any information related to the digital key is acceptable. For example, information related to the digital key could also be information that identifies the digital key.

[0246] The information related to the digital key stored in device 30 is not limited to the key information DK; any information related to the digital key is acceptable. For example, the information related to the digital key could also be information that identifies the digital key.

[0247] The information related to the digital key stored in the vehicle management device 26 and the information related to the digital key stored in the device 30 can be different or the same as described in the above embodiments.

[0248] The authentication information AT is not limited to the examples of the above embodiments, as long as it is used to authenticate the digital key when using the digital key. For example, the authentication information AT could also be a shared key used by the vehicle management device 26 and the device 30. Alternatively, the authentication information AT could also be a shared private key.

[0249] The structure of the information contained in the key information DK is not limited to the examples of the above embodiments. For example, the owner key information DKO may not have slot identification information ST4. Additionally, the key information DK may also include information indicating the category of the digital key. Information indicating the category of the digital key may, for example, indicate one of the owner key KO, friend key KF, and non-friend key KN.

[0250] The management system 10 may also include information representing the category of device 30 in the database DB. This information representing the category of device 30 may include, for example, information representing any of the following: smartphone, smartwatch, or server as specified in the aforementioned variation example.

[0251] The structure of the data DA in the database DB is not limited to the examples of the above implementation methods. The database DB only needs to contain the information required by the management server 70 in the management system 10 for management purposes.

[0252] In a database (DB), permissions can be set for each digital key, rather than being uniquely determined by the category of the digital key. Alternatively, permissions for a digital key can be undefined within the database (DB).

[0253] The series of processes for registering the owner key KO is not limited to the examples of the above embodiments. For example, even without pairing based on the process in step S12, the owner device 40 can store the owner key information DKO by receiving and transmitting information such as generated data DC from the vehicle 20 and the first device 30A via the management server 70. The series of processes for registering the owner key KO can be appropriately modified to be consistent with the structure of the information contained in the owner key information DKO and the structure of the information contained in the authentication information AT.

[0254] The series of processes for registering a friend key KF is not limited to the examples of the above embodiments. For example, after sending the authentication packet ATP and storage request D24 to vehicle 20, the management server 70 can also update the database DB through the process of step S29. The series of processes for registering a friend key KF can be appropriately modified to be consistent with the structure of the information contained in the friend key information DKF and the structure of the information contained in the authentication information AT.

[0255] The process for registering a non-friend key KN is not limited to the examples of the above implementation methods. The process for registering a friend key KF and the order of the process can also be different. The process for registering a non-friend key KN can be appropriately modified to be consistent with the structure of the information contained in the non-friend key information DKN and the structure of the information contained in the authentication information AT.

[0256] The types of digital keys may also exclude non-friend keys KN. That is, in the management system 10, the shared key KS may only be a friend key KF. In this case, it is also possible that the object's digital key is the owner key KO, and the digital key registered based on the object's digital key is the friend key KF.

[0257] Non-friend device 52 can also send a registration request for a new non-friend key KN. That is, shared device 50 can also send a registration request for a new non-friend key KN regardless of whether it is a friend device 51 or a non-friend device 52.

Claims

1. A vehicle configured to register a device as a digital key, said device being configured to store information associated with the digital key, wherein, The vehicle has the following features: Storage device, configured to store the range of functions of the vehicle that can be implemented by the digital key; and Actuating device, The actuator is configured to change the range of vehicle functions that the digital key can perform during periods other than the usage period to a narrower range than the range of vehicle functions that the digital key can perform during the usage period, which is the period during which the user of the digital key uses the vehicle.

2. The vehicle according to claim 1, wherein, The storage device stores a usage end time, which is the time when the usage period ends. The execution device is configured to determine that the utilization period has ended when the utilization ends.

3. The vehicle according to claim 1, wherein, The vehicle has an interface configured to be operated by the user. The actuator is configured to determine that the utilization period has ended when an operation to terminate the utilization of the vehicle is performed via the interface.

4. The vehicle according to claim 1, wherein, The vehicle is equipped with a communication device configured to communicate with the equipment. The execution device is configured to determine that the utilization period has ended when it receives a utilization end notification output from the device.

5. The vehicle according to claim 1, wherein, The vehicle is equipped with a communication device configured to communicate with a management server, the management server being configured to manage the digital key. The execution device is configured to determine that the utilization period has ended upon receiving a utilization end notification output from the management server.

6. The vehicle according to claim 1, wherein, The storage device stores the start time of use, which is the time at which the use period begins. The actuator is configured to determine that the utilization period has started when the utilization begins.

7. The vehicle according to claim 1, wherein, The vehicle has an interface configured to be operated by the user. The actuator is configured to determine that the utilization period has started when an operation to start the utilization of the vehicle is performed via the interface.

8. The vehicle according to claim 1, wherein, The vehicle is equipped with a communication device configured to communicate with the equipment. The execution device is configured to determine that the utilization period has started when it receives a utilization start notification output from the device.

9. The vehicle according to claim 1, wherein, The vehicle is equipped with a communication device configured to communicate with a management server, the management server being configured to manage the digital key. The execution device is configured to determine that the utilization period has started when it receives a utilization start notification output from the management server.

10. The vehicle according to claim 1, wherein, The scope of the vehicle's functions includes functions that involve driving the vehicle and functions that do not involve driving the vehicle. The actuator is configured to change the range of the vehicle's functions during periods outside of the usage period in a manner in which the user cannot utilize the functions for driving the vehicle.

11. The vehicle according to claim 1, wherein, The actuator is configured such that, Outside of the stated utilization period, when the vehicle is located within a predetermined specific area, a portion of the range of functions of the vehicle can be utilized. Furthermore, the vehicle's functions are not used during periods other than the stated utilization period, when the vehicle is located outside the stated specific area.

12. The vehicle according to claim 11, wherein, The specific area is a pre-determined parking lot.

Images