Server, setting method, and program

Abstract

Provided are a server (70), a setting method, and a program. A server processing circuit (71) manages a plurality of digital keys that can be used for a vehicle (20). A plurality of associated digital keys are associated with a first digital key (KN). An executable function range (ATP7) is set in the first digital key. An out-of-range operation (A) is not initially included in the executable function range (ATP7). When the out-of-range operation (A) is performed, the server processing circuit (71) transmits a confirmation request notification (M62, M72, M300) to at least one device (40, 30B) in which information relating to the associated digital keys is stored.

Description

Server, setting method, and program

[0001] The present disclosure relates to a server, a setting method, and a program.

[0002] Patent Literature 1 discloses a digital key system technology that uses a device such as a smartphone as a vehicle key. The digital key system stores information about the digital key in the vehicle. The digital key system also stores information about the digital key in the device. This allows the vehicle to be used using the device registered as a digital key without the need for a physical key. Furthermore, the digital key system communicates between the device storing the digital key information and another person's device to issue a registration request to enable the other person's device to function as a new digital key. This allows the other person's device to be registered as a digital key for the vehicle. In other words, the digital key can generate a new digital key. The digital key system also allows the vehicle to be loaned to another person without the need to exchange a physical key.

[0003] JP 2023-184349 A

[0004] Among devices functioning as a vehicle's digital key, there are devices that already store information about the vehicle's digital key, and this digital key may have been generated by the vehicle's owner making a registration request. Other devices may also store information about the vehicle's digital key that was generated by a person other than the vehicle's owner making a registration request. The user of a device that has stored information about the vehicle's digital key by a person other than the vehicle's owner making a registration request may not be acquainted with the vehicle's owner.

[0005] According to one aspect of the present disclosure, there is provided a server that manages a plurality of digital keys available for a vehicle, the plurality of digital keys including a first digital key and a plurality of digital keys associated with the first digital key, and when an operation that is not initially included in the range of executable functions of the first digital key is performed, the server transmits a confirmation request notification to at least one device that has stored information about the associated digital key.

[0006] According to another aspect of the present disclosure, there is provided a configuration method. The configuration method includes managing, by a server processing circuit of a server, a plurality of digital keys available for a vehicle. The plurality of digital keys include a first digital key and a plurality of associated digital keys associated with the first digital key. The first digital key has a range of executable functions. The server processing circuit receives a notification of an out-of-range operation, which is an operation not initially included in the range of executable functions. The server processing circuit transmits a confirmation request notification of the out-of-range operation to at least one associated storage device, which is at least one device that stores information about the associated digital key.

[0007] According to yet another aspect of the present disclosure, there is provided a program or program product for causing a server processing circuit of a server to execute a setting process. The setting process includes managing, by the server processing circuit, a plurality of digital keys available for a vehicle. The plurality of digital keys include a first digital key and a plurality of associated digital keys associated with the first digital key. The first digital key has a range of executable functions set thereto. The server processing circuit receives a notification of an out-of-range operation, which is an operation not initially included in the range of executable functions. The server processing circuit transmits a confirmation request notification of the out-of-range operation to at least one associated storage device, which is at least one device that stores information about the associated digital key.

[0008] According to yet another aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium storing a program or program product for executing a similar setting process. For example, a first device has stored therein information about a first digital key. A second device has stored therein information about a second digital key associated with the first digital key. A first user is a user of the first device and also uses a vehicle. A second user is a user of the second device. The server allows the second user to know how the first user is using the vehicle.

[0009] Regardless of whether the user who newly generated the digital key for the vehicle is the owner of the vehicle, the user who newly generated the digital key for the vehicle may have the following desire: The user who newly generated the digital key for the vehicle may wish to know the usage information of the vehicle by the user of the device that stores information about the newly generated digital key for the vehicle. The various configurations described above can meet this desire.

[0010] FIG. 1 is a schematic diagram showing a management system. FIG. 2 is a schematic diagram showing owner key information. FIG. 3 is a schematic diagram showing share key information. FIG. 4 is a schematic diagram showing data in a management server database. FIG. 5 is an explanatory diagram showing a series of processes performed by the management server when registering an owner key. FIG. 6 is an explanatory diagram showing a series of processes performed by the management server when registering a friend key. FIG. 7 is an explanatory diagram showing a series of processes performed by the management server when registering a non-friend key. FIG. 8 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a friend device. FIG. 9 is an explanatory diagram showing a series of processes performed by the management system when a non-friend key is deleted in response to a request from a non-friend device. FIG. 10 is an explanatory diagram showing a series of processes performed by a management system including the management server of the first embodiment. FIG. 11 is an explanatory diagram showing a continuation of the processing in FIG. 10 when the vehicle owner permits out-of-range operation A, which is not initially included in the authority information of the non-friend key. FIG. 12 is an explanatory diagram showing the continuation of the processing in the processing of FIG. 10 when the vehicle owner rejects out-of-range operation A that is not initially included in the authority information of the non-friend key. FIG. 13 is a diagram showing an example of an image displayed to prompt the user of the owner device to select whether to allow an operation that is not initially included in the authority information of the non-friend key. FIG. 14 is a diagram showing an example of an image displayed to prompt the user of the owner device to select whether to set an end condition. FIG. 15 is an explanatory diagram showing a series of processing performed by a management system including a management server of the second embodiment. FIG. 16 is an explanatory diagram showing the continuation of the processing in the processing of FIG. 15 when the vehicle owner accepts out-of-range operation A that is not initially included in the authority information of the non-friend key. FIG. 17 is an explanatory diagram showing the continuation of the processing in the processing of FIG. 15 when the vehicle owner rejects out-of-range operation A that is not initially included in the authority information of the non-friend key. FIG. 18 is an explanatory diagram showing a series of processing performed by a management system including a management server of the third embodiment.

[0011] 1 to 14 illustrate a first embodiment of a management server, a setting method, a setting process, a program, and a program product. <Outline of Management System 10> As shown in FIG. 1, a management server 70 is one of multiple devices that make up the management system 10. The management system 10 includes a vehicle 20, multiple devices 30, a device server 60, and a management server 70. The management server 70 is a server that manages multiple digital keys that can be used for the vehicle 20. There is a standard for digital keys, the Car Connectivity Consortium (CCC). Matters related to the digital keys in this embodiment comply with the CCC.

[0012] The vehicle 20 includes a communication module 21, a vehicle 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 (registered trademark) Low Energy. UWB stands for Ultra Wide Band. NFC stands for Near Field Communication.

[0013] The communication module 21 communicates with the management server 70 via a wireless communication network. The vehicle HMI 22 includes an input device that accepts operations by the user of the vehicle 20 and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

[0014] The BLE module 23 performs short-range communication with the device 30 using BLE communication. The UWB module 24 communicates with the device 30 using UWB communication. The UWB module 24 measures the distance between the device 30 and the vehicle 20. The NFC module 25 performs short-range communication with the device 30 using NFC communication.

[0015] The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a vehicle control circuit equipped with a digital key ECU. The vehicle management device 26 has a vehicle execution device 27 and a vehicle storage device 28. The vehicle storage device 28 has stored therein a vehicle program PV and authentication information AT. The vehicle program PV causes the vehicle execution device 27 to execute various vehicle processes, thereby causing the vehicle execution device 27 to store and delete the authentication information AT. The authentication information AT is information for authenticating the digital key so that the digital key can be used to control the vehicle 20. The authentication information AT is provided for each digital key to be authenticated. The vehicle execution device 27 is a vehicle processing circuit equipped with a CPU. The vehicle execution device 27 executes the vehicle program PV to perform processes related to the storage and deletion of the authentication information AT.

[0016] Authenticating the digital key means allowing the digital key to control the vehicle 20. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the digital key to unlock the vehicle 20. Also, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the digital key to start the vehicle 20.

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

[0018] The communication module 31 communicates with the device server 60 via a wireless communication line. The device HMI_32 includes an input device that accepts operations by the user of the device 30, and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

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

[0020] The device storage device 37 stores a device program PD and key information DK. The device program PD causes the device execution unit 36 ​​to execute various device processes, thereby causing the device execution unit 36 ​​to store and delete key information DK. The key information DK is information indicating a digital key.

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

[0022] The multiple devices 30 include an owner device 40 and multiple shared devices 50. The owner device 40 has stored therein owner key information DKO indicating an owner key KO as key information DK. Only one owner key KO can be registered to one vehicle 20. Therefore, only one owner key KO exists for one vehicle 20.

[0023] 2, the owner key information DKO includes owner key structure information STO. The owner key structure information STO includes vehicle identification information ST1, in-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The owner key structure information STO further includes certificate information ST5, device public key information ST6, vehicle public key information ST7, permission public key information ST8, and authority information ST9.

[0024] The vehicle identification information ST1 is information that identifies the vehicle 20 for which one or more digital keys are set. For example, the vehicle identification information ST1 is the ID of the vehicle 20. The in-device key identification information ST2 is used to manage the digital keys within the device 30. The in-device key identification information ST2 is information that allows the digital keys to be identified within the application of the device 30.

[0025] The digital key identification information ST3 is used for managing the digital key in the management server 70. The slot identification information ST4 is information that enables the device 30 to identify the digital key locally.

[0026] Certificate information ST5 indicates a certificate that certifies the digital key. Device public key information ST6 indicates a device public key PKD, which is the public key of the device 30. The device public key PKD in the owner key information DKO indicates the public key of the owner device 40. Vehicle public key information ST7 indicates a vehicle public key PKV, which is the public key of the vehicle 20. Authorization public key information ST8 indicates a vehicle public key PKV that has already been authorized. Authority information ST9 is information that indicates the range of executable functions of the device 30 that has stored the authority information ST9. The range of executable functions will be described later.

[0027] 1, the share device 50 has stored therein share key information DKS indicating a share key KS as key information DK. A share key KS is a digital key that can be registered in multiple numbers for one vehicle 20 in order to enable the use of the digital key. In other words, multiple share keys KS can exist for one vehicle 20.

[0028] The multiple share devices 50 include one or more friend devices 51 and one or more non-friend devices 52. The friend device 51 has stored friend key information DKF indicating the friend key KF as the share key information DKS. The non-friend device 52 has stored non-friend key information DKN indicating the non-friend key KN as the share key information DKS. In other words, the types of share keys KS include the friend key KF and the non-friend key KN.

[0029] The friend key KF is a share key KS registered based on a direct registration request D21 from the owner device 40, as will be described later. The friend key information DKF is key information DK indicating the friend key KF. The friend device 51 is a device 30 that has already stored key information DK indicating the friend key KF.

[0030] The non-friend key KN is a share key KS registered based on a registration request D31 from the friend device 51, as described below. The registration request D31 from the friend device 51 is not a registration request from the owner device 40, and is therefore a so-called indirect registration request. The non-friend key information DKN is key information DK indicating the non-friend key KN. The non-friend device 52 is a device 30 that has already stored the non-friend key information DKN. The non-friend key KN is a share key KS registered based on a registration request from the share device 50. The share device 50 is a device 30 separate from the owner device 40. The registration request from the share device 50 is a so-called indirect registration request. In other words, the registration request D31 is a request to store the non-friend key information DKN, which is key information DK, in the device 30.

[0031] The state in which the digital key has been registered means that the digital key is usable. In other words, in the state in which the digital key has been registered, the vehicle 20 has stored the authentication information AT, and the device 30 has stored the key information DK. The authentication information AT is information related to the digital key. In other words, in the state in which the digital key has been registered, the vehicle 20 has stored the information related to the digital key. The key information DK is information related to the digital key. In other words, in the state in which the digital key has been registered, the device 30 has stored the information related to the digital key.

[0032] As shown in Figure 3, the shared key information DKS includes shared key structure information STS and an authentication package ATP. The shared key structure information STS includes vehicle identification information ST1, in-device key identification information ST2, digital key identification information ST3, and slot identification information ST4. The shared key structure information STS 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 the owner key structure information STO minus the device public key information ST6 and authority information ST9.

[0033] The authentication package ATP includes signature information ATP1, password information ATP2, validity start time information ATP3, expiration date information ATP4, name information ATP5, device public key information ATP6, and authority information ATP7.

[0034] The signature information ATP1 indicates that the share device 50 is a legitimate target for sharing the digital key. For example, if the share device 50 is a friend device 51, the signature information ATP1 indicates a signature by the owner device 40. The owner signature information indicates that the owner device 40 has signed the device public key PKD of the friend device 51, which is indicated by the device public key information ATP6. Also, for example, if the share device 50 is a non-friend device 52, the signature information ATP1 indicates a signature by the friend device 51. The friend signature information indicates that the friend device 51 has signed the device public key PKD of the non-friend device 52, which is indicated by the device public key information ATP6.

[0035] The password information ATP2 indicates the pairing password PAS used to establish a secure channel when pairing the vehicle 20 and the owner device 40. The validity start time information ATP3 indicates the earliest date and time at which the shared key KS can be used. The expiration date information ATP4 indicates the latest date and time at which the shared key KS can be used. The name information ATP5 indicates a name that identifies the shared key KS. For example, the name information ATP5 is set as an identifiable name for each shared device 50 by operation from the owner device 40.

[0036] The authority information ATP7 is information indicating the range of executable functions of the digital key. That is, the range of executable functions of the vehicle 20 includes, for example, the number of share keys KS that can be requested to be registered, the range of control of the vehicle 20 that can be performed by authenticating the digital key, and the like. Here, the range of executable functions of the vehicle 20 indicates, for example, the available controls among (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlocking and locking control of the vehicle 20. For example, if the range of executable functions of the vehicle 20 includes the above three controls, the range of executable functions of the vehicle 20 is wider than if the range of executable functions of the vehicle 20 includes only (c) door unlocking and locking control of the vehicle 20. More specifically, the range of functions of the vehicle 20 that can be performed by the friend key KF is the three controls mentioned above, while the range of functions of the vehicle 20 that can be performed by the non-friend key KN is two: (b) power-on control of the vehicle 20, and (c) unlocking and locking control of the doors of the vehicle 20.

[0037] In the first embodiment, the range of vehicle 20 functions that can be performed by the digital key is determined by the authority information ATP7 stored in the vehicle 20. The following describes a case where the authority information ATP7 stored in the device 30 that has stored key information DK indicating the digital key includes two functions: (b) power-on control, and (c) door unlocking and locking control. In this case, if the authority information ATP7 of the digital key stored in the vehicle 20 to which the digital key is registered includes (c) door unlocking and locking control, the digital key can perform (c) door unlocking and locking control for the vehicle 20. On the other hand, if the authority information ATP7 of the digital key stored in the vehicle 20 to which the digital key is registered includes (b) power-on control and (c) door unlocking and locking control, the digital key can perform (b) power-on control and (c) door unlocking and locking control for the vehicle 20. If the authority information ATP7 of the digital key stored in the vehicle 20 to which the digital key is registered has (a) engine start control of the vehicle 20, (b) power on control, and (c) door unlocking control and door locking control, the digital key can perform (a) engine start control of the vehicle 20, (b) power on control, and (c) door unlocking control and door locking control on the vehicle 20.

[0038] As shown in FIG. 1 , the device server 60 relays communication between the devices 30 and the management server 70. A device server 60 is provided for each type of device 30. That is, the device server 60 with which a first type of device 30 communicates is different from the device server 60 with which a second type of device 30 communicates. For example, the type of device 30 refers to the model of the device 30, and a device server 60 is provided for each model of the device 30. For example, the type of device 30 refers to the communication line used by the device 30, and a device server 60 is provided for each communication line used by the device 30. Since all device servers 60 relay communication with the management server 70, devices 30 of different types can communicate with the management server 70 via the device server 60. FIG. 1 illustrates only one device server 60.

[0039] <Management Server 70> The management server 70 is capable of communicating with the vehicle 20 and multiple devices 30. The management server 70 includes a server execution device 71, a server storage device 72, and a communication module 73. The communication module 73 communicates with the device server 60 via a wireless communication line. The communication module 73 is also capable of wireless communication with the communication module 21 of the vehicle 20. The server storage device 72 stores a server program PS, a confirmation program PM, and a database DB. The server program PS causes the server execution device 71 to execute various server processes, thereby causing the server execution device 71 to register digital keys in the database DB and delete digital keys from the database DB. The server execution device 71 includes a server processing circuit. Details of the confirmation program PM will be described later.

[0040] The database DB is divided into data blocks DA for each vehicle 20. When a digital key has been registered, the management server 70 has already stored, in the data block DA, information indicating the device 30 that stores the key information DK indicating the digital key.

[0041] As shown in Figure 4, a data block DA for one vehicle 20 includes the types of digital keys registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. The hierarchy of digital keys is determined by the type of digital key. From top to bottom, the hierarchy is arranged as follows: owner key KO, friend key KF, and non-friend key KN.

[0042] The following describes a state in which digital keys are registered to seven devices 30 for one vehicle 20. The seven devices 30 include a first device 30A, a second device 30B, a third device 30C, a fourth device 30D, a fifth device 30E, a sixth device 30F, and a seventh device 30G.

[0043] In the data block DA, the device 30 whose type of digital key is registered as the owner key KO is the first device 30A. In other words, the first device 30A is the owner device 40.

[0044] In data block DA, the devices 30 whose digital key type is registered as a shared key KS are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. In other words, the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G are shared devices 50.

[0045] More specifically, in the data block DA, the devices 30 whose digital key type is registered as the friend key KF are the second device 30B and the fifth device 30E. In other words, the second device 30B and the fifth device 30E are friend devices 51.

[0046] In the data block DA, the devices 30 whose digital key type is registered as a non-friend key KN are the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G. In other words, the third device 30C, the fourth device 30D, the sixth device 30F, and the seventh device 30G are non-friend devices 52.

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

[0048] In data block DA, the relationship between the third device 30C and the second device 30B is such that a non-friend key KN has been registered in the third device 30C based on a registration request from the second device 30B. In data block DA, the relationship between the fourth device 30D and the second device 30B is such that a non-friend key KN has been registered in the fourth device 30D based on a registration request from the second device 30B.

[0049] In data block DA, the relationship between the sixth device 30F and the fifth device 30E is such that a non-friend key KN has been registered in the sixth device 30F based on a registration request from the fifth device 30E. In data block DA, the relationship between the seventh device 30G and the fifth device 30E is such that a non-friend key KN has been registered in the seventh device 30G based on a registration request from the fifth device 30E.

[0050] In this way, the data block DA stores the devices 30 registered as digital keys. When the device 30 is registered, information indicating the device 30 that made the request that caused the registration is linked to the digital key. The data block DA also includes information indicating which digital key each digital key was registered under.

[0051] <Regarding Associated Digital Keys> In the embodiment, a first digital key is registered as a non-friend key KN in the third device 30C, a second digital key is registered as a friend key KF in the second device 30B, and a third digital key is registered as an owner key KO in the first device 30A.

[0052] The relationship between the third device 30C and the second device 30B is such that a first digital key (non-friend key KN) has been registered in the third device 30C based on a registration request from the second device 30B, which has already registered a second digital key (friend key KF). The second digital key (friend key KF) is a digital key that generated the first digital key (non-friend key KN). In other words, the second digital key (friend key KF) is a digital key that is one generation older than the first digital key (non-friend key KN).

[0053] The relationship between the second device 30B and the first device 30A is such that the second digital key (friend key KF) has been registered in the second device 30B based on a registration request from the first device 30A, which has already registered the third digital key (owner key KO). The third digital key (owner key KO) is a digital key that generated the second digital key (friend key KF). In other words, the third digital key (owner key KO) is a digital key that is one generation older than the second digital key (friend key KF).

[0054] The second digital key (friend key KF) that generated the first digital key (non-friend key KN) is a digital key that is already associated with the first digital key (non-friend key KN). The third digital key (owner key KO) that generated the second digital key (friend key KF) is a digital key that is already associated with the second digital key (friend key KF). The third digital key (owner key KO) that generated the second digital key (friend key KF) that is already associated with the first digital key (non-friend key KN) is also a digital key that is already associated with the first digital key (non-friend key KN). In other words, the third digital key (owner key KO) is a digital key that is two generations older than the first digital key (non-friend key KN).

[0055] When an existing digital key generates a new digital key, the existing digital key that generated the new digital key and the digital keys already associated with the existing digital key that generated the new digital key are all already associated with the generated new digital key. For example, when a first digital key (non-friend key KN) generates a new digital key, the first digital key (non-friend key KN), the second digital key (friend key KF), and the third digital key (owner key KO) are all digital keys already associated with the digital key newly generated by the first digital key (non-friend key KN). In other words, all digital keys one generation or more older than the digital key newly generated by the first digital key (non-friend key KN) are digital keys already associated with the digital key newly generated by the first digital key (non-friend key KN). In other words, in the relationship diagram shown in FIG. 4, digital keys one generation or more older that are directly related are digital keys already associated with the newly generated digital key.

[0056] A fourth digital key (non-friend key KN) is registered in the fourth device 30D. The relationship between the fourth device 30D and the second device 30B is such that the fourth digital key (non-friend key KN) has been registered in the fourth device 30D based on a registration request from the second device 30B, which has already registered the second digital key (friend key KF). The second digital key (friend key KF) is a digital key that generated the fourth digital key (non-friend key KN). In other words, the second digital key (friend key KF) is a digital key that is one generation older than the fourth digital key (non-friend key KN).

[0057] Between the third device 30C and the fourth device 30D, there is no relationship in which a digital key has been registered based on a registration request. For example, the first digital key (non-friend key KN) has not generated a second digital key (friend key KF) that has been associated with the fourth digital key (non-friend key KN). The fourth digital key (non-friend key KN) has not generated a second digital key (friend key KF) that has been associated with the first digital key (non-friend key KN). Therefore, the first digital key (non-friend key KN) and the fourth digital key (non-friend key KN) are digital keys that are not associated with each other.

[0058] Similarly, the first digital key (non-friend key KN) registered in the third device 30C and the digital key registered in the fifth device 30E are digital keys that are not associated with each other. The first digital key (non-friend key KN) registered in the third device 30C and the digital key registered in the sixth device 30F are digital keys that are not associated with each other. The first digital key (non-friend key KN) registered in the third device 30C and the digital key registered in the seventh device 30G are digital keys that are not associated with each other.

[0059] <Digital Key Registration> Next, a series of processes for registering one or more digital keys in the management system 10 will be described. The management system 10 registers at least one of the following digital keys: owner key KO, friend key KF, or non-friend key KN. The following describes the series of processes from an unregistered state to a registered state for various digital keys. In the following description, the processes executed by the vehicle execution unit 27 of the vehicle management device 26 will be described as processes executed by the vehicle 20. In the following description, the processes executed by the device execution unit 36 ​​will be described as processes executed by the device 30. In the following description, the processes executed by the server execution unit 71 will be described as processes executed by the management server 70.

[0060] 5, the management system 10 performs a series of processes to register the owner key KO. Among the devices 30 that do not store key information DK indicating the owner key KO, the device 30 that will be registered as the owner device 40 is referred to as a first device 30A.

[0061] The management system 10 stores key information DK indicating the owner key KO in the first device 30A to register the owner key KO. The management system 10 stores authentication information AT for authenticating the owner key KO in the vehicle 20 to register the owner key KO. As a result, the first device 30A becomes the owner device 40. When registering the owner key KO, it is assumed that the necessary applications are installed in the first device 30A.

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

[0063] The vehicle 20 then receives the pairing password PAS. After receiving the pairing password PAS, the vehicle 20 is set to pairing mode via the vehicle HMI 22 and waits in a state in which it can receive a password from the first device 30A. The vehicle 20 then proceeds to step S12.

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

[0065] In step S13, the vehicle 20 generates a vehicle public key PKV, which is the public key of the vehicle 20, and a vehicle private key SKV, which is the private key of the vehicle 20. Then, the vehicle 20 transmits generation data DC for generating the owner key KO to the first device 30A via the secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information indicating the vehicle public key PKV. The first device 30A then receives the generation data DC. The first device 30A then proceeds to step S14.

[0066] In step S14, the first device 30A generates owner key information DKO indicating the owner key KO. Then, the first device 30A proceeds to step S15. In step S15, the first device 30A stores the owner key information DKO. As a result, the first device 30A becomes the owner device 40. In other words, the registration request D11 is a request to have the device 30 store the owner key information DKO as key information DK. Then, the first device 30A transmits certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD to the vehicle 20.

[0067] Thereafter, when vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process of step S16. In step S16, vehicle 20 verifies certificate information ST5. When the verification of certificate information ST5 is completed, vehicle 20 proceeds to the process of step S17.

[0068] In step S17, vehicle 20 stores device public key information ST6 indicating device public key PKD as authentication information AT, and then transmits a completion notification M11 to first device 30A indicating that storage of authentication information AT has been completed.

[0069] Thereafter, when the first device 30A receives the completion notification M11, the first device 30A performs the process of step S18. In step S18, the first device 30A generates a key track request D12 for the owner key KO. The key track request D12 is a signal for requesting the management server 70 to update the database DB. The first device 30A transmits the key track request D12 for the owner key KO to the management server 70 via the device server 60.

[0070] Thereafter, upon receiving the key track request D12, the management server 70 performs processing in step S19. In step S19, the management server 70 performs registration management of the owner key KO. Specifically, the management server 70 stores the first device 30A as the device 30 registered as the owner key KO in the data block DA of the vehicle 20 in the database DB. This completes the series of processes for registering the owner key KO in the management system 10.

[0071] 6, the management system 10 performs a series of processes to register a friend key KF. Among the devices 30 that do not store friend key information DKF, a device 30 that will be registered as a friend device 51 through the series of processes is referred to as a second device 30B.

[0072] When an operation to request registration of a friend key KF is executed in the owner device 40, the owner device 40 first performs the process of step S21. In step S21, the owner device 40 transmits a friend key KF registration request D21 to a relay server (not shown). Thereafter, the owner device 40 proceeds to step S22.

[0073] In step S22, the owner device 40 obtains invitation information IV1 for sharing the digital key from the relay server. The invitation information IV1 is, for example, a URL link. The URL link stores share information SH1 required for sharing the digital key. The owner device 40 then transmits the invitation information IV1 to the second device 30B.

[0074] After that, when the second device 30B receives the invitation information IV1, it performs the process of step S23. In step S23, the second device 30B acquires the share information SH1 based on the invitation information IV1. Specifically, the second device 30B downloads the share information SH1 from the link source of the URL link.

[0075] The share information SH1 includes, for example, share key structure information STS, password information ATP2, validity start time information ATP3, expiration date information ATP4, and name information ATP5. The validity start time information ATP3, expiration date information ATP4, and name information ATP5 are set by the owner device 40. Thereafter, the second device 30B proceeds to step S24.

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

[0077] The owner device 40 then receives a completion notification M21 and a signature request D22 from the second device 30B. Upon receiving the completion notification M21, the owner device 40 acquires the unsigned friend key information DKFN. Upon receiving the signature request D22, the owner device 40 performs the process of step S25 in response to an operation of the owner device 40.

[0078] In step S25, the owner device 40 generates signature information ATP1. Specifically, the owner device 40 causes the device HMI_32 to present the acquired signature-free friend key information DKFN and accepts an operation indicating that the user of the owner device 40 agrees to the registration of the friend key KF. When the consent operation is performed, the owner device 40 acquires a signature based on the consent operation. The owner device 40 then proceeds to step S26.

[0079] In step S26, the owner device 40 adds the signature information ATP1 to the unsigned friend key information DKFN. This causes the owner device 40 to generate friend key information DKF. The owner device 40 then uploads the generated friend key information DKF to the URL link, which is the invitation information IV1. The owner device 40 then transmits a completion notification M22 to the second device 30B, indicating that the completed friend key information DKF has been uploaded to the URL link.

[0080] The second device 30B then receives the completion notification M22. The second device 30B then performs the process of step S27. In step S27, the second device 30B downloads and stores the friend key information DKF. As a result, the second device 30B becomes a friend device 51. The second device 30B then proceeds to step S28.

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

[0082] Thereafter, when the management server 70 receives a key track request D23 for the friend key KF, the management server 70 performs processing in step S29. In step S29, the management server 70 performs registration management of the friend key KF. The key track request D23 is a request to store new authentication information AT in the vehicle 20.

[0083] Specifically, as part of the registration management, the management server 70 verifies that the friend key KF that is the target of the key track request D23 is not listed on the reject list. The reject list is a list of share keys KS that have friend keys KF and non-friend keys KN for which a deletion request has already been received. If the friend key KF is listed on the reject list, the management server 70 sends a notification to the second device 30B that the key track request D23 cannot be fulfilled.

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

[0085] Thereafter, the management server 70 transmits the authentication package ATP included in the friend key information DKF and a storage request D24 for requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 transmits device public key information ST6 indicating the device public key PKD of the friend device 51 to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD has been signed by the owner device 40.

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

[0087] After completing the registration management, the management server 70 transmits a key track completion notification M23 to the second device 30B. After that, upon receiving the key track completion notification M23, the second device 30B performs the process of step S31. In the process of step S31, the second device 30B presents information indicating the completion of the registration of the friend key KF on the device HMI_32. For example, the second device 30B displays an image indicating the completion of the registration of the friend key KF on the device HMI_32. This causes the management system 10 to complete the series of processes for registering the friend key KF.

[0088] 7, the management system 10 performs a series of processes to register a non-friend key KN. Among the devices 30 that do not store non-friend key information DKN, a device 30 that will be registered as a non-friend device 52 through the series of processes is referred to as a third device 30C.

[0089] When an operation to request registration of a non-friend key KN is executed on the friend device 51, the friend device 51 first performs processing in step S41. In step S41, the friend device 51 transmits a registration request D31 of the non-friend key KN to a relay server (not shown). Thereafter, the friend device 51 proceeds to processing in step S42.

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

[0091] After that, when the third device 30C receives the invitation information IV2, it performs the process of step S43. In step S43, the third device 30C acquires the share information SH2 based on the invitation information IV2. Specifically, the second device 30B downloads the share information SH2 from the URL link.

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

[0093] In step S44, the third device 30C generates the unsigned non-friend key information DKNN using the share information SH2. The unsigned non-friend key information DKNN is non-friend key information DKN that does not have the signature information ATP1. Specifically, the third device 30C generates each piece of information included in the acquired share information SH2 as the unsigned non-friend key information DKNN. The third device 30C then transmits to the friend device 51 a completion notification M31 indicating that the generated unsigned non-friend key information DKNN has been uploaded to the URL link, and a signature request D32 requesting a signature.

[0094] Thereafter, the friend device 51 receives a completion notification M31 and a signature request D32 from the third device 30C. Upon receiving the completion notification M31, the friend device 51 acquires the unsigned non-friend key information DKNN. Upon receiving the signature request D32, the friend device 51 performs the process of step S45 in response to an operation of the friend device 51.

[0095] In step S45, the friend device 51 generates signature information ATP1. Specifically, the friend device 51 causes the device HMI_32 to present the acquired signature-free non-friend key information DKNN, and accepts an operation indicating that the user of the friend device 51 agrees to the generation of the non-friend key KN. When the agreement operation is performed, the friend device 51 acquires a signature based on the agreement operation. The friend device 51 then proceeds to step S46.

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

[0097] The third device 30C then receives the completion notification M32. The third device 30C then performs the process of step S47. In step S47, the third device 30C downloads and stores the non-friend key information DKN. As a result, the third device 30C becomes a non-friend device 52. The third device 30C then proceeds to the process of step S48.

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

[0099] Thereafter, when the management server 70 receives a key track request D33 for the non-friend key KN, the management server 70 performs the process of step S49. In step S49, the management server 70 performs registration management of the non-friend key KN.

[0100] Specifically, as part of the registration management, the management server 70 verifies that the non-friend key KN that is the target of the key track request D33 is not on the rejection list. If the non-friend key KN is on the rejection list, the management server 70 sends a notification to the third device 30C that the key track request D33 cannot be fulfilled.

[0101] On the other hand, if the non-friend key KN is not on the rejection list, the management server 70 registers the non-friend key KN that is the target of the key track request D33 in the database DB. Specifically, the management server 70 stores the third device 30C in the data block DA of the vehicle 20 in the database DB as a device 30 registered as a non-friend device 52. The management server 70 stores the relationship between the third device 30C and the friend device 51 by referring to the acquired non-friend key information DKN. Specifically, the management server 70 stores the third device 30C as a device 30 having the non-friend key KN registered in response to the registration request D31 from the second device 30B.

[0102] Thereafter, the management server 70 transmits the authentication package ATP included in the non-friend key information DKN and a storage request D34 for requesting storage of the authentication package ATP to the vehicle 20. That is, the management server 70 transmits device public key information ST6 indicating the device public key PKD of the non-friend device 52 to the vehicle 20. The management server 70 also notifies the vehicle 20 that the device public key PKD is signed by the friend device 51.

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

[0104] After completing the registration management, the management server 70 transmits a key track completion notification M33 to the second device 30B. After that, upon receiving the key track completion notification M33, the second device 30B performs processing in step S51. In the processing in step S51, the third device 30C presents information indicating the completion of registration of the non-friend key KN on the device HMI_32. For example, the third device 30C displays an image indicating the completion of registration of the non-friend key KN on the device HMI_32. This causes the management system 10 to complete the series of processes for registering the non-friend key KN.

[0105] <Deleting a Non-Friend Key KN> Next, a series of processes for deleting a non-friend key KN in the management system 10 will be described. Below, a series of flows from a state in which a non-friend key KN has been registered to a state in which the non-friend key KN is not registered will be described. In the following explanation, the processes executed by the vehicle execution unit 27 will be described as processes executed by the vehicle 20. Similarly, the processes executed by the device execution unit 36 ​​will be described as processes executed by the device 30, and the processes executed by the server execution unit 71 will be described as processes executed by the management server 70.

[0106] <Deletion of Non-Friend Key KN Based on Deletion Reservation D41 from Friend Device 51> As shown in FIG. 8, the management system 10 performs a series of processes to delete the non-friend key KN based on the deletion reservation D41 from the friend device 51.

[0107] When an operation to request the deletion of the non-friend key KN is executed in the friend device 51, the friend device 51 first performs the process of step S61. In step S61, a deletion reservation D41 for the non-friend key KN is generated. The deletion reservation D41 is a command for reserving the deletion of the non-friend key KN.

[0108] The deletion reservation D41 includes a signal for requesting the deletion of the non-friend key KN, digital key identification information ST3 indicating the non-friend key KN, and information indicating a predetermined condition RC. The predetermined condition RC is a condition required to start the deletion of the non-friend key KN after receiving the deletion reservation D41. The predetermined condition RC is predetermined. For example, the predetermined condition RC is that a predetermined fade-out period has elapsed since the deletion reservation D41 was received. The friend device 51 transmits the deletion reservation D41 of the non-friend key KN to the management server 70.

[0109] After that, when the management server 70 receives the deletion reservation D41 of the non-friend key KN, the management server 70 performs the process of step S62. In step S62, the management server 70 generates a pending notification M41 in accordance with the deletion reservation D41. The management server 70 transmits the pending notification M41 to the friend device 51.

[0110] Thereafter, when the friend device 51 receives the pending notification M41, the friend device 51 performs the process of step S63. In step S63, the friend device 51 presents, to the device HMI_32, information indicating that the deletion of the non-friend key KN that is the target of the deletion reservation D41 is pending.

[0111] After the process of step S62, the management server 70 performs the process of step S64. In step S64, the management server 70 stores the state of the non-friend key KN that is the target of the deletion reservation D41 in the database DB as a fade-out state. The fade-out state is a state in which the deletion reservation D41 has been received but the execution of deletion is still pending. The management server 70 then proceeds to the process of step S65.

[0112] In step S65, the management server 70 confirms that the predetermined condition RC is satisfied. If the management server 70 confirms that the predetermined condition RC is satisfied, the management server 70 proceeds to step S66.

[0113] In step S66, the management server 70 generates a deletion request D42 for deleting the non-friend key information DKN indicating the non-friend key KN that is the target of the deletion reservation D41. The management server 70 transmits the deletion request D42 to the non-friend device 52.

[0114] Thereafter, when the non-friend device 52 receives the deletion request D42, it performs the process of step S67. In step S67, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion request D42. The non-friend device 52 transmits a deletion completion notification M42 to the management server 70, indicating that the deletion in accordance with the deletion request D42 has been completed.

[0115] Thereafter, when the management server 70 receives the deletion completion notification M42, the management server 70 performs the process of step S68. In step S68, the management server 70 stores the history of the deletion of the non-friend key information DKN in the non-friend device 52. Thereafter, the management server 70 proceeds to the process of step S69.

[0116] In step S69, the management server 70 generates a deletion request D43 for the authentication information AT. The deletion request D43 for the authentication information AT indicates a request to delete the authentication information AT that was required when the non-friend key KN that is the subject of the deletion reservation D41 was authenticated. The management server 70 transmits the deletion request D43 to the vehicle 20.

[0117] Thereafter, when the vehicle 20 receives the deletion request D43, the vehicle 20 performs the process of step S70. In step S70, the vehicle 20 deletes the authentication information AT that was required when the non-friend key KN that is the subject of the deletion reservation D41 was authenticated in accordance with the deletion request D43. That is, the vehicle 20 deletes the authentication package ATP of the non-friend key KN. The vehicle 20 then transmits a deletion completion notification M43 to the management server 70, indicating that the deletion of the authentication information AT in accordance with the deletion request D43 has been completed.

[0118] Thereafter, when the management server 70 receives the deletion completion notification M43, the management server 70 performs the process of step S71. In step S71, the management server 70 stores the history of the deletion of the authentication information AT that was required to authenticate the non-friend key KN that is to be deleted in the current series of deletion-related processes in the vehicle 20. Thereafter, the management server 70 proceeds to the process of step S72.

[0119] In step S72, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN, which is the key to be deleted in this series of processes, from the data block DA of the vehicle 20 in the database DB. Thereafter, the management server 70 transmits a deletion completion notification M44 to the friend device 51, indicating that the series of deletions of the non-friend key KN in accordance with the deletion reservation D41 have been completed.

[0120] Thereafter, when the friend device 51 receives the deletion completion notification M44, the friend device 51 performs the process of step S73. In step S73, the friend device 51 presents, to the device HMI_32, information indicating that the deletion of the non-friend key KN, which is the target of the deletion reservation D41, has been completed. For example, the friend device 51 displays, on the device HMI_32, an image indicating that the deletion of the non-friend key KN has been completed. Thereafter, the management system 10 ends the series of processes for the deletion of this non-friend key KN.

[0121] <Deletion of non-friend key KN due to deletion in non-friend device 52> As shown in Figure 9, the management system 10 performs a series of processes to delete the non-friend key KN indicated by the non-friend key information DKN stored in the non-friend device 52 due to a deletion operation in the non-friend device 52.

[0122] When a predetermined operation requesting the deletion of the non-friend key KN is executed in the non-friend device 52, the non-friend device 52 first performs the process of step S81. In step S81, the non-friend device 52 deletes the non-friend key information DKN in accordance with the predetermined operation. Thereafter, the non-friend device 52 transmits a deletion completion notification M51 indicating that the non-friend key information DKN has been deleted to the management server 70.

[0123] Thereafter, when the management server 70 receives the deletion completion notification M51, the management server 70 performs processing in step S82. In step S82, the management server 70 stores the history of the deletion of the non-friend key information DKN in the non-friend device 52. Thereafter, the management server 70 transmits a deletion completion notification M52 to the friend device 51, indicating that the non-friend key information DKN has been deleted.

[0124] Thereafter, when the friend device 51 receives the deletion completion notification M52, the friend device 51 performs the process of step S83. In step S83, the friend device 51 presents, to the device HMI_32, information indicating that the deletion of the non-friend key information DKN of the non-friend device 52 has been completed. For example, the friend device 51 displays, on the device HMI_32, an image indicating that the deletion of the non-friend key KN has been completed.

[0125] After the process of step S82, the management server 70 performs the process of step S84. In step S84, the management server 70 generates a deletion request D51 for deleting the authentication information AT that was required when authenticating the non-friend key information DKN that has been deleted in step S81. The management server 70 transmits the deletion request D51 to the vehicle 20.

[0126] Thereafter, when vehicle 20 receives deletion request D51, vehicle 20 performs processing in step S85. In step S85, vehicle 20 deletes authentication information AT that was required to authenticate non-friend key information DKN that has been deleted in step S81 in accordance with deletion request D51. Vehicle 20 transmits deletion completion notification M53 to management server 70, indicating that deletion of authentication information AT in accordance with deletion request D51 has been completed.

[0127] Thereafter, when management server 70 receives deletion completion notification M53, management server 70 performs processing in step S86. In step S86, management server 70 stores the history of the deletion of authentication information AT that was necessary to authenticate non-friend key information DKN that has been deleted in step S81. Thereafter, management server 70 proceeds to processing in step S87.

[0128] In step S87, the management server 70 updates the database DB. Specifically, the management server 70 deletes the non-friend device 52 having the non-friend key KN, which is the key to be deleted in this series of processes, from the data block DA of the vehicle 20 in the database DB. This causes the management system 10 to end the series of processes for deleting the non-friend key KN.

[0129] <Generation of confirmation request notification M62 by management server 70 in first embodiment> A user of a non-friend device 52 may perform an out-of-range operation A on the vehicle 20 that is not initially included in the authority information ATP7 stored by the non-friend device 52. In the embodiment, the range of functions of the vehicle 20 that the non-friend device 52 can perform as the non-friend key KN, which are included in the authority information ATP7 of the non-friend key KN, includes two functions: (b) power-on control of the vehicle 20, and (c) locking and unlocking control of the doors of the vehicle 20. For example, (a) engine start control of the vehicle 20 is an out-of-range operation A that is not initially included in the authority information ATP7 stored by the non-friend device 52.

[0130] 10 is an explanatory diagram showing the flow of a series of processes executed by the management server 70 in the management system 10 when a user of the third device 30C, which is a non-friend device 52, performs an out-of-range operation A on the vehicle 20 that is not initially included in the authority information ATP7 in the non-friend key KN. As shown in FIG. 1, in the management server 70, the server storage device 72 has already stored a confirmation program PM. The server execution device 71 executes the confirmation program PM stored in the server storage device 72. This causes the management server 70 to execute a series of processes.

[0131] The owner device 40 is the first device 30A that has stored key information DK indicating the owner key KO through the series of processes shown in FIG. 5 . The owner key KO is registered in the first device 30A as the third digital key. The non-friend device 52 is the third device 30C that has stored key information DK indicating the non-friend key KN through the series of processes shown in FIG. 7 . The non-friend key KN is registered in the third device 30C as the first digital key. As described above, the third digital key (owner key KO) is an associated digital key that is associated with the first digital key (non-friend key KN). In other words, the owner device 40 is a device 30 that has stored information about the digital key associated with the first digital key (non-friend key KN). In other words, the owner device 40 is an association storage device.

[0132] When the user of the non-friend device 52 performs an out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, on the vehicle 20, the vehicle 20 performs the process of step S91. Below, a case will be described in which the user of the non-friend device 52 performs (a) engine start control of the vehicle 20 as the out-of-range operation A, which is not initially included in the authority information ATP7, on the vehicle 20.

[0133] In step S91, the vehicle 20 generates a first permission request notification M61 as a request notification. The first permission request notification M61 is a notification requesting permission for an out-of-range operation A that is not initially included in the authority information ATP7 in the non-friend key KN of the third device 30C when the out-of-range operation A is performed on the vehicle 20. The vehicle 20 transmits the first permission request notification M61 to the management server 70.

[0134] The management server 70 is configured to be able to receive a first permission request notification M61 from the vehicle 20. Upon receiving the first permission request notification M61, the management server 70 performs processing in step S92. In step S92, the management server 70 generates a confirmation request notification M62, which is a notification requesting permission for an out-of-range operation A not initially included in the authority information ATP7, in accordance with the first permission request notification M61. The confirmation request notification M62 includes information for setting, through operation of the owner device 40, whether or not to permit the out-of-range operation A not initially included in the authority information ATP7 in the non-friend key KN. The confirmation request notification M62 includes information for setting, through operation of the owner device 40, a predetermined termination condition EC, described below. The management server 70 transmits the confirmation request notification M62 as a confirmation notification to the owner device 40.

[0135] <Processing Performed by the Owner Device 40 After Receiving the Confirmation Request Notification M62> The owner device 40 is configured to be able to receive the confirmation request notification M62 from the management server 70. When the owner device 40 receives the confirmation request notification M62, the owner device 40 performs processing in step S93. In step S93, the owner device 40 presents, to the device HMI_32, an image that allows the user of the owner device 40 to set whether or not to permit the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN.

[0136] Figure 13 is an example of an image presented on the device HMI_32 of the owner device 40 to allow the user of the owner device 40 to set whether or not to allow out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN.

[0137] The user of the owner device 40 follows the guidance presented on the device HMI_32 and selects either "YES" or "NO" by operating a radio button for out-of-range operation A (a) "controlling the start of the engine of the vehicle 20." "YES" means that out-of-range operation A is permitted, while "NO" means that out-of-range operation A is rejected.

[0138] <Step S93: If the Out-of-Range Operation is YES> If the user of the owner device 40 selects "YES" by operating the radio button and then presses "OK" (step S93: YES), the owner device 40 performs the process of step S94 shown in Fig. 11. In the process of step S94, the owner device 40 presents, to the device HMI_32, an image that prompts the user to select whether or not to set an end condition EC for the permission of the out-of-range operation A.

[0139] <Presenting an image to allow the user to select whether or not to set the termination condition EC> Figure 14 shows an example of an image presented on the device HMI_32 of the owner device 40 in the processing of step S94 to allow the user of the owner device 40 to select whether or not to set the termination condition EC for allowing out-of-range operation A.

[0140] The user of the owner device 40 selects either "YES" or "NO" by operating a radio button according to the guidance presented on the device HMI_32 regarding whether or not to set the termination condition EC. If the user of the owner device 40 selects "YES" regarding the setting of the termination condition by operating a radio button, the user of the owner device 40 can select the termination condition EC by operating a radio button.

[0141] When the user of the owner device 40 operates the radio button to select "Until the vehicle 20 is powered off" as the termination condition and then presses "OK," "Until the vehicle 20 is powered off" is selected as the termination condition EC. When the user of the owner device 40 operates the radio button to select "Until YYYY / MM / DD," the user can input any date. When the user inputs any date in "Until YYYY / MM / DD" and then presses "OK," "Until YYYY / MM / DD," for which the user has already inputted any date, is selected as the termination condition EC. When the user of the owner device 40 operates the radio button to select "Until X number of engine starts," the user can input any natural number for "X" in "Until X number of engine starts." When the user inputs any natural number into "X" of "up to X number of engine starts" and then presses "OK", "up to X number of engine starts" is selected as the termination condition EC, for which the user has input any natural number into "X". When the user of the owner device 40 selects "NO" for setting the termination condition and then presses "OK", the termination condition EC is not set. Below, a case will be described where the user of the owner device 40 selects "until the power of the vehicle 20 is turned off" as the termination condition EC.

[0142] In step S94 shown in FIG. 11 , the owner device 40 generates a permission notification M63. The permission notification M63 is a notification permitting an out-of-range operation A that is not initially included in the authority information ATP7 for the non-friend key KN. The permission notification M63 includes "until the power of the vehicle 20 is turned off" as a default termination condition EC. If the termination condition EC is not set in the processing of step S94, the permission notification M63 does not include the termination condition EC. The owner device 40 transmits the permission notification M63 to the management server 70.

[0143] <Processing Performed by the Management Server 70 After Receiving the Permission Notification M63> When the management server 70 receives the permission notification M63, it performs the process of step S95. In step S95, the management server 70 generates a permission request D61. The permission request D61 includes a signal for adding the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN, to the authority information ATP7. The permission request D61 includes a signal for deleting the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN, from the authority information ATP7 when the predetermined termination condition EC included in the permission notification M63 is satisfied. The management server 70 transmits the permission request D61 to the vehicle 20. That is, when the predetermined termination condition EC is satisfied, the management server 70 transmits a signal to the vehicle 20 for prohibiting the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN. In other words, the permission request D61 includes a prohibition request to delete out-of-range operation A from the executable functional range (ATP7) of the first digital key (non-friend key KN) when a predetermined termination condition (EC) is met.

[0144] After transmitting the permission request D61 to the vehicle 20, the management server 70 performs processing in step S96. In step S96, the management server 70 generates a permission notification M64. The permission notification M64 includes information for causing the device HMI_32 to indicate that the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, has been permitted by the owner device 40. The permission notification M64 includes information for causing the non-friend device 52 to indicate to the device HMI_32 the default termination condition EC selected by the owner device 40. The management server 70 transmits the permission notification M64 to the non-friend device 52.

[0145] When the vehicle 20 receives the permission request D61, it performs the process of step S97. In step S97, the vehicle 20 changes the authority information ATP7 for the non-friend key KN that is already stored in the vehicle 20. Before receiving the permission request D61, the vehicle 20 stored the authority information ATP7 for the non-friend key KN with (b) power-on control for the vehicle 20 and (c) door unlocking control and door locking control for the vehicle 20. When the vehicle 20 receives the permission request D61, it adds the out-of-range operation A included in the permission request D61 to the authority information ATP7 for the non-friend key KN. That is, the vehicle 20 adds (a) engine start control for the vehicle 20 to the authority information ATP7 for the non-friend key KN. By the processing of step S97, the authority information ATP7 of the non-friend key KN is changed to include (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20. In other words, (a) engine start control of the vehicle 20 has been added to the authority information ATP7 of the non-friend key KN. This allows the user of the non-friend device 52 to perform out-of-range operation A on the vehicle 20, which was not initially included in the authority information ATP7 of the non-friend key KN at the start of this series of processing.

[0146] In the first embodiment, the vehicle 20 monitors whether or not a predetermined termination condition EC is satisfied. In step S97, the vehicle 20 starts monitoring whether or not the predetermined termination condition EC is satisfied.

[0147] When the non-friend device 52 receives the permission notification M64, it performs the process of step S98. In step S98, the non-friend device 52 presents to the device HMI_32 a notification indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, has been permitted by the owner device 40. The non-friend device 52 presents the predetermined termination condition EC to the device HMI_32.

[0148] <When Predetermined Termination Condition EC is Satisfied> When the power of the vehicle 20 is turned off, the vehicle 20 determines that the predetermined termination condition EC is satisfied. When the predetermined termination condition EC is satisfied, the vehicle 20 performs processing in step S99. In step S99, the vehicle 20 performs processing to prohibit the out-of-range operation A on the vehicle 20 by the user of the non-friend device 52 and processing to generate a prohibition establishment notification M65.

[0149] The vehicle 20 changes the authority information ATP7 already stored in the vehicle 20 as a process for prohibiting an out-of-range operation A on the vehicle 20 by the user of the non-friend device 52. Before the predetermined termination condition EC is satisfied, the vehicle 20 stores, as authority information ATP7, (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlocking control and locking control of the vehicle 20. When the predetermined termination condition EC is satisfied, the vehicle 20 deletes from the authority information ATP7 the out-of-range operation A that was added to the authority information ATP7 based on the permission request D61 and was not initially included in the authority information ATP7 of the non-friend key KN at the start of this series of processes. That is, the vehicle 20 deletes (a) engine start control of the vehicle 20 from the authority information ATP7. By processing step S99, the authority information ATP7 in the non-friend key KN is changed to include (b) power-on control for the vehicle 20 and (c) locking and unlocking control for the doors of the vehicle 20. As a result, the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN at the start of this series of processes, is prohibited for the user of the non-friend device 52.

[0150] The prohibition establishment notification M65 includes information indicating that, due to the establishment of the predetermined termination condition EC, the vehicle 20 has prohibited the user of the non-friend device 52 from performing the out-of-range operation A, which is not initially included in the authority information ATP7. The vehicle 20 transmits the prohibition establishment notification M65 to the management server 70.

[0151] When the management server 70 receives the prohibition establishment notification M65, it performs processing in step S100. In step S100, the management server 70 generates a prohibition notification M66. The prohibition notification M66 includes information indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, has been prohibited from being performed on the vehicle 20 because the predetermined termination condition EC has been established. The management server 70 transmits the prohibition notification M66 to the non-friend device 52.

[0152] When the non-friend device 52 receives the prohibition notification M66, it performs processing in step S101. In step S101, the non-friend device 52 presents to the device HMI_32 a notification indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN, is prohibited from being performed on the vehicle 20 because the predetermined termination condition EC has been satisfied. Thereafter, the management system 10 terminates the series of processes.

[0153] <Step S93: If NO for Out-of-Range Operation> In step S93 shown in FIG. 10, if the user of the owner device 40 operates the radio button to select “NO” shown in FIG. 13 and then presses “OK” (step S93: NO), the processing continues to FIG. 12.

[0154] 12 , the owner device 40 generates an out-of-range operation rejection notification M67. The out-of-range operation rejection notification M67 is a notification rejecting an out-of-range operation A that is not initially included in the authority information ATP7 for the non-friend key KN. The owner device 40 transmits the out-of-range operation rejection notification M67 to the management server 70.

[0155] <Processing Performed by Management Server 70 After Receiving Out-of-Range Operation Rejection Notification M67> As shown in FIG. 12 , upon receiving the out-of-range operation rejection notification M67, the management server 70 performs processing in step S102. In step S102, the management server 70 generates an out-of-range operation rejection notification M68. The out-of-range operation rejection notification M68 is a notification indicating that the owner device 40 has rejected the out-of-range operation A, which was not initially included in the authority information ATP7 for the non-friend key KN. The management server 70 transmits the out-of-range operation rejection notification M68 to the non-friend device 52.

[0156] When the non-friend device 52 receives the out-of-range operation refusal notification M68, it performs the process of step S103. In step S103, the non-friend device 52 presents to the device HMI_32 a notification indicating that the out-of-range operation A, which was not initially included in the authority information ATP7 in the non-friend key KN, has been rejected by the owner device 40. Thereafter, the management system 10 ends the series of processes.

[0157] <Operation of First Embodiment> A first digital key is registered as a non-friend key KN in the third device 30C, which is a non-friend device 52. The third device 30C is a device that has already stored information about the first digital key (non-friend key KN). In other words, the third device 30C is a first storage device.

[0158] A third digital key is registered as the owner key KO in the owner device 40. The third digital key (owner key KO) is an associated digital key that has been associated with the first digital key that has been associated with the non-friend key KN. In other words, the owner device 40 is a device 30 that has stored information about the digital key that has been associated with the first digital key (non-friend key KN). In other words, the owner device 40 is an association storage device.

[0159] When a user of a third device 30C that has registered a first digital key as a non-friend key KN performs an out-of-range operation A on a vehicle 20 that is not initially included in the authority information ATP7 for the non-friend key KN, the management server 70 sends a confirmation request notification M62 to the owner device 40.

[0160] <Effects of the first embodiment> (1-1) The management server 70 can allow the vehicle owner, who is the user of the owner device 40, to understand the usage status of the vehicle 20 by the user of the third device 30C to which the first digital key as a non-friend key KN has been registered.

[0161] Furthermore, the management server 70 can allow the vehicle owner to permit or deny the use of functions of the vehicle 20 by the user of the third device 30C to which the first digital key as the non-friend key KN is registered. This allows the management server 70 to convey the vehicle owner's intentions to the user of the third device 30C to which the first digital key (non-friend key KN) is registered.

[0162] (1-2) The management server 70 is configured to receive a first permission request notification M61 from the vehicle 20 when an out-of-range operation A that is not initially included in the authority information ATP7 for the first digital key serving as the non-friend key KN is performed on the vehicle 20. The first permission request notification M61 requests permission from the owner device 40 that has stored information about the digital key associated with the first digital key (non-friend key KN). Upon receiving the first permission request notification M61, the management server 70 transmits a confirmation request notification M62 to the owner device 40. This allows the management server 70 to inform the vehicle owner that the user of the third device 30C to which the first digital key (non-friend key KN) is registered has performed an out-of-range operation A that is not initially included in the authority information ATP7 of the non-friend device 52. Furthermore, when a user of a third device 30C to which a first digital key (non-friend key KN) has been registered performs an out-of-range operation A that is not initially included in the authority information ATP7, the management server 70 can allow the vehicle owner to permit or deny the user of the third device 30C to which a first digital key (non-friend key KN) has been registered from using the functions of the vehicle 20.

[0163] (1-3) Incidentally, a vehicle owner may wish to prohibit a user of a third device 30C, to which a first digital key has been registered as a non-friend key KN, from using a function of the vehicle 20 after initially permitting the use of the function. When the management server 70 receives a notification permitting an out-of-range operation A not initially included in the authorization information ATP7 from an owner device 40 that has stored information about a digital key associated with the first digital key (non-friend key KN), the management server 70 transmits a permission request D61 to the vehicle 20. The permission request D61 includes a signal for adding the out-of-range operation A not initially included in the authorization information ATP7 for the first digital key (non-friend key KN) to the authorization information ATP7. The permission request D61 includes a signal for deleting the out-of-range operation A not initially included in the authorization information ATP7 for the first digital key (non-friend key KN) from the authorization information ATP7 when a predetermined termination condition EC is satisfied. As a result, the management server 70 prohibits the out-of-range operation A, which is not initially included in the authority information ATP7 of the first digital key (non-friend key KN), from being performed on the vehicle 20 when the predetermined termination condition EC is met. This allows the management server 70 to reassure the vehicle owner, who is the user of the owner device 40 that has stored information about the digital key associated with the first digital key (non-friend key KN).

[0164] (1-4) The owner device 40 has stored information about the digital key associated with the first digital key as the non-friend key KN. The management server 70 transmits a confirmation request notification M62 to the owner device 40. The confirmation request notification M62 includes information for setting a predetermined termination condition EC through operation of the owner device 40.

[0165] The management server 70 sets the default termination condition EC in accordance with the information indicating the default termination condition EC received from the owner device 40. This enables the management server 70 to set the default termination condition EC in accordance with the intention of the vehicle owner who has received the confirmation request notification M62.

[0166] <Modifications of the First Embodiment> The above-described first embodiment can be modified and implemented as follows: The above-described first embodiment and the following modifications of the first embodiment can be implemented in combination with each other within a range that does not cause technical contradictions.

[0167] The management server 70 may send a notification including information for causing the owner device 40 to set a predetermined termination condition EC, as a notification separate from the confirmation request notification M62 shown in FIG.

[0168] 11, the management server 70 may transmit only a signal to the vehicle 20 for adding the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN, to the authority information ATP7. In this case, the management server 70 may transmit, as a request separate from the permission request D61, a signal to the vehicle 20 for deleting the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN, from the authority information ATP7 when a predetermined termination condition EC is met.

[0169] 11 , the non-friend device 52 may change the authority information ATP7 already stored in the non-friend device 52 to the authority information ATP7 already stored in the vehicle 20 in step S97. In this case, in step S96, the management server 70 transmits a signal to the non-friend device 52 to permit the out-of-range operation A not initially included in the authority information ATP7 of the non-friend key KN. When the non-friend device 52 receives the signal to permit the out-of-range operation A not initially included in the authority information ATP7 of the non-friend key KN, the non-friend device 52 changes the authority information ATP7 already stored in the non-friend device 52. Before receiving the above signal, the non-friend device 52 stores, as authority information ATP7, (b) power-on control for the vehicle 20 and (c) door unlocking control and door locking control for the vehicle 20. When the non-friend device 52 receives the above signal, it adds (a) engine start control of the vehicle 20 to the authority information ATP7 in the non-friend key KN. As a result, the authority information ATP7 already stored in the non-friend device 52 is changed to include (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20.

[0170] Below, a case will be described in which, in step S98, the management server 70 changes the authority information ATP7 already stored in the non-friend device 52 to the authority information ATP7 already stored in the vehicle 20 in step S97 in the same way. In this case, in step S101, the management server 70 changes the authority information ATP7 already stored in the non-friend device 52 to the authority information ATP7 already stored in the vehicle 20 in step S99 in the same way. In other words, the authority information ATP7 is restored to the original state.

[0171] In step S95, the management server 70 may change the authority information ATP7 for the non-friend key KN already stored in the database DB to the authority information ATP7 for the non-friend key KN already stored in the vehicle 20 in step S97. In step S100, the management server 70 may change the authority information ATP7 for the non-friend key KN already stored in the database DB to the authority information ATP7 for the non-friend key KN already stored in the vehicle 20 in step S99. In other words, the authority information ATP7 is restored to the original information.

[0172] When the predetermined termination condition EC is satisfied, the management server 70 may send to the vehicle 20, in addition to the permission request D61, a signal for causing the vehicle 20 to store the state of the non-friend key KN as a fade-out state. In this case, in step S99, the vehicle 20 performs a process of prohibiting an out-of-range operation A not initially included in the authority information ATP7 and a process of generating a prohibition establishment notification M65 after a predetermined fade-out period has elapsed. Here, the case where the predetermined termination condition EC is satisfied is not limited to the case where a predetermined fade-out period has elapsed. For example, the predetermined termination condition EC may also include the case where the vehicle 20 is located at a predetermined location. In this case, in step S99, the vehicle 20 performs a process of prohibiting an out-of-range operation A on the vehicle 20 by the user of the non-friend device 52 and a process of generating a prohibition establishment notification M65 after the vehicle 20 is located at the predetermined location. Here, the predetermined location includes, for example, a predetermined parking lot.

[0173] 1, 5, 7, and 13 to 17 explain a management server 70 according to a second embodiment. The second embodiment will be explained mainly focusing on the differences from the first embodiment. The management server 70 in the second embodiment is configured to be able to receive a second permission request notification M71 as a request notification from the third device 30C, which is a non-friend device 52. The second permission request notification M71 will be described later.

[0174] <Generation of confirmation request notification M72 by management server 70 in second embodiment> Figure 15 is an explanatory diagram showing the flow of a series of processes executed by management server 70 in management system 10 of the second embodiment. As shown in Figure 1, in the management server 70, the server storage device 72 has already stored a confirmation program PM. The server execution device 71 executes the confirmation program PM stored in the server storage device 72. This causes the management server 70 to execute a series of processes.

[0175] The owner device 40 is a first device 30A that has stored key information DK indicating an owner key KO through the series of processes shown in FIG. 5. The owner key KO is registered in the first device 30A as a third digital key. The non-friend device 52 is a third device 30C that has stored key information DK indicating a non-friend key KN through the series of processes shown in FIG. 7. The non-friend key KN is registered in the third device 30C as a first digital key. As described above, the third digital key (owner key KO) has been associated with the first digital key (non-friend key KN). In other words, the owner device 40 is a device 30 that has stored information regarding the digital key associated with the first digital key (non-friend key KN). In other words, the owner device 40 is an association storage device.

[0176] The following describes a case in which the non-friend device 52 executes an operation to request permission from the owner device 40 to perform an out-of-range operation A that is not initially included in the authority information ATP7 stored by the non-friend device 52. In this case, the non-friend device 52 performs the process of step S201 shown in FIG. 15 . In step S201, the non-friend device 52 generates a second permission request notification M71 as a request notification. The second permission request notification M71 is a notification requesting permission for the out-of-range operation A that is not initially included in the authority information ATP7 stored by the non-friend device 52. The following describes a case in which the user of the non-friend device 52 requests permission from the owner device 40 to perform (a) engine start control of the vehicle 20 as the out-of-range operation A that is not initially included in the authority information ATP7. The non-friend device 52 first transmits the second permission request notification M71 to the management server 70.

[0177] Upon receiving the second permission request notification M71, the management server 70 performs processing in step S202. In step S202, the management server 70 generates a confirmation request notification M72, which is a notification requesting permission to perform an out-of-range operation A not initially included in the authority information ATP7, in accordance with the second permission request notification M71. The confirmation request notification M72 includes information for setting, through operation of the owner device 40, whether or not to permit the out-of-range operation A not initially included in the authority information ATP7 in the non-friend key KN. The confirmation request notification M72 includes information for setting, through operation of the owner device 40, a predetermined termination condition EC, which will be described later. The management server 70 transmits the confirmation request notification M72 as a confirmation notification to the owner device 40.

[0178] <Processing Performed by the Owner Device 40 After Receiving the Confirmation Request Notification M72> The owner device 40 is configured to be able to receive the confirmation request notification M72 from the management server 70. When the owner device 40 receives the confirmation request notification M72, the owner device 40 performs processing in step S203. In step S203, similar to the processing in step S93 shown in Fig. 10 in the first embodiment, the owner device 40 presents the device HMI_32 with the image shown in Fig. 13 for allowing the user to set whether to permit the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN.

[0179] The user of the owner device 40 selects either "YES" or "NO" for out-of-range operation A by operating the radio button, following the instructions in the image shown in Figure 13 presented on the device HMI_32.

[0180] <Step S203: YES for Out-of-Range Operation> If the user of the owner device 40 selects "YES" (step S203: YES), the owner device 40 performs the process of step S204 shown in Fig. 16. In the process of step S204, similar to the process of step S94 shown in Fig. 11 in the first embodiment, the owner device 40 presents the image shown in Fig. 14 on the device HMI_32 to prompt the user to select whether to set an end condition EC for the permission of the out-of-range operation A. The user of the owner device 40 selects either "YES" or "NO" for whether to set an end condition EC, following the guidance shown in Fig. 14 presented on the device HMI_32.

[0181] In step S204, the owner device 40 generates a permission notification M73. The permission notification M73 is a notification permitting an out-of-range operation A that is not initially included in the authority information ATP7 for the non-friend key KN. If the user of the owner device 40 selects "YES" as to whether to set an end condition EC according to the guidance shown in FIG. 14 presented on the device HMI_32, the permission notification M73 includes the default end condition EC selected by the user of the owner device 40. If the user of the owner device 40 selects "NO" as to whether to set an end condition EC according to the guidance shown in FIG. 14 presented on the device HMI_32, the permission notification M73 does not include the default end condition EC. The owner device 40 transmits the permission notification M73 to the management server 70.

[0182] <Processing Performed by Management Server 70 After Receiving Permission Notification M73> When the management server 70 receives the permission notification M73, it performs the process of step S205 shown in FIG. 16. In step S205, the management server 70 generates a permission request D71. The permission request D71 includes a signal for adding the out-of-range operation A, which was not initially included in the authority information ATP7 for the non-friend key KN, to the authority information ATP7. The management server 70 transmits the permission request D71 to the vehicle 20.

[0183] In the second embodiment, the management server 70 monitors whether or not the predetermined termination condition EC is satisfied. In step S205, the management server 70 starts monitoring whether or not the predetermined termination condition EC is satisfied. On the other hand, in the first embodiment, as shown in step S97 of FIG. 11 , the vehicle 20 monitors whether or not the predetermined termination condition EC is satisfied.

[0184] After transmitting the permission request D71 to the vehicle 20, the management server 70 performs the process of step S206. In step S206, the management server 70 generates a permission notification M74. The permission notification M74 includes information for causing the device HMI_32 of the non-friend device 52 to indicate that the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, has been permitted by the owner device 40. The permission notification M74 includes information for causing the device HMI_32 of the non-friend device 52 to indicate the default termination condition EC selected by the owner device 40. The management server 70 transmits the permission notification M74 to the non-friend device 52.

[0185] When the vehicle 20 receives the permission request D71, it performs the process of step S207. In step S207, the vehicle 20 changes the authority information ATP7 for the non-friend key KN that is already stored in the vehicle 20. Before receiving the permission request D71, the vehicle 20 stored the authority information ATP7 for the non-friend key KN with (b) power-on control for the vehicle 20 and (c) door unlocking control and door locking control for the vehicle 20. When the vehicle 20 receives the permission request D71, it adds the out-of-range operation A included in the permission request D71 to the authority information ATP7 for the non-friend key KN. That is, the vehicle 20 adds (a) engine start control for the vehicle 20 to the authority information ATP7 for the non-friend key KN. By the processing of step S207, the authority information ATP7 of the non-friend key KN is changed to include (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20. This allows the user of the non-friend device 52 to perform out-of-range operation A on the vehicle 20, which was not initially included in the authority information ATP7 of the non-friend key KN at the start of this series of processing.

[0186] When the non-friend device 52 receives the permission notification M74, it performs the process of step S208. In step S208, the non-friend device 52 presents to the device HMI_32 a notification indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, has been permitted by the owner device 40. The non-friend device 52 presents to the device HMI_32 a predetermined termination condition EC.

[0187] <When the Predetermined Termination Condition EC is Satisfied> In the second embodiment, the management server 70 monitors whether the predetermined termination condition EC is satisfied. When the predetermined termination condition EC is satisfied, the management server 70 performs processing in step S209. In step S209, the management server 70 generates a prohibition request D72 and a prohibition notification M75. The prohibition request D72 includes a signal for deleting from the authority information ATP7 the out-of-range operation A that was not initially included in the authority information ATP7 for the non-friend key KN at the start of this series of processing. The out-of-range operation A was already added to the authority information ATP7 due to the permission request D71. The management server 70 transmits the prohibition request D72 to the vehicle 20. That is, when the predetermined termination condition EC is satisfied, the management server 70 transmits to the vehicle 20 a signal for prohibiting the out-of-range operation A that was not initially included in the authority information ATP7 for the non-friend key KN at the start of this series of processing.

[0188] The prohibition notification M75 includes information indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN at the start of this series of processes, is prohibited by the management server 70 from being performed on the vehicle 20 if a predetermined termination condition EC is met. The management server 70 transmits the prohibition notification M75 to the non-friend device 52.

[0189] When the vehicle 20 receives the prohibition request D72, it performs the process of step S210. In the process of step S210, the vehicle 20 modifies the authority information ATP7 already stored in the vehicle 20 as a process for prohibiting an out-of-range operation A on the vehicle 20 by the user of the non-friend device 52. Before the predetermined termination condition EC is satisfied, the vehicle 20 stores, as the authority information ATP7, (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlock control and lock control of the vehicle 20. When the vehicle 20 receives the prohibition request D72, it deletes the out-of-range operation A added based on the permission request D71 from the authority information ATP7. That is, the vehicle 20 deletes (a) engine start control of the vehicle 20 from the authority information ATP7. By the processing of step S210, the authority information ATP7 is changed to include (b) power-on control of the vehicle 20 and (c) door unlocking control and door locking control of the vehicle 20. As a result, the out-of-range operation A, which is not initially included in the authority information ATP7 of the non-friend key KN at the start of this series of processing, is prohibited for the user of the non-friend device 52.

[0190] When the non-friend device 52 receives the prohibition notification M75, it performs the process of step S211. In step S211, the non-friend device 52 presents to the device HMI_32 a notification indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 at the start of this series of processes, has been prohibited because the predetermined termination condition EC has been met. Thereafter, the management system 10 ends the series of processes.

[0191] <Step S203: NO for Out-of-Range Operation> In step S203, if the user of the owner device 40 selects "NO" shown in FIG. 13 by operating the radio button and then presses "OK" (step S203: NO), the owner device 40 generates an out-of-range operation rejection notification M76 shown in FIG. 17. The out-of-range operation rejection notification M76 is a notification rejecting the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN. The owner device 40 transmits the out-of-range operation rejection notification M76 to the management server 70.

[0192] <Processing Performed by Management Server 70 After Receiving Out-of-Range Operation Rejection Notification M76> When the management server 70 receives the out-of-range operation rejection notification M76, it performs the process of step S212. In step S212, the management server 70 generates an out-of-range operation rejection notification M77. The out-of-range operation rejection notification M77 is a notification indicating that the owner device 40 has rejected the out-of-range operation A, which was not initially included in the authority information ATP7 for the non-friend key KN. The management server 70 transmits the out-of-range operation rejection notification M77 to the non-friend device 52.

[0193] When the non-friend device 52 receives the out-of-range operation refusal notification M77, it performs the process of step S213. In step S213, the non-friend device 52 presents to the device HMI_32 a notification indicating that the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN, has been refused by the owner device 40. Thereafter, the management system 10 ends the series of processes.

[0194] <Operation of Second Embodiment> There is a possibility that the vehicle owner and the user of the non-friend device 52 are not acquainted with each other. Therefore, there is a possibility that the user of the non-friend device 52 is unable to contact the vehicle owner.

[0195] The third device 30C, which is a non-friend device 52, has registered therein a first digital key as a non-friend key KN. In other words, the third device 30C is a device 30 that has already stored information about the first digital key (non-friend key KN). In other words, the third device 30C is a first storage device.

[0196] A third digital key is registered in the owner device 40 as the owner key KO. The third digital key (owner key KO) is a digital key that has been associated with the first digital key that has been associated with the non-friend key KN. In other words, the owner device 40 is a device 30 that has stored information about the digital key that has been associated with the first digital key (non-friend key KN). In other words, the owner device 40 is an association storage device.

[0197] The third device 30C, which has already registered the first digital key as the non-friend key KN, transmits a second permission request notification M71 shown in Fig. 15 to the management server 70. Upon receiving the second permission request notification M71, the management server 70 transmits a confirmation request notification M72 to the owner device 40.

[0198] Advantages of the Second Embodiment (2-1) Even when the user of the third device 30C to which the first digital key (non-friend key KN) is registered is not operating the vehicle 20, the management server 70 can cause the vehicle owner, who is the user of the owner device 40, to permit or deny the out-of-range operation A, which is not initially included in the authority information ATP7 of the non-friend device 52, performed by the user of the third device 30C to which the first digital key (non-friend key KN) is registered. This improves convenience for the user of the third device 30C to which the first digital key (non-friend key KN) is registered.

[0199] <Modifications of Second Embodiment> The second embodiment can be modified as follows: The second embodiment and the following modifications of the second embodiment can be combined with each other to the extent that they are not technically inconsistent.

[0200] The management server 70 may send a notification including information for causing the owner device 40 to set a predetermined termination condition EC, as a notification separate from the confirmation request notification M72 shown in FIG.

[0201] The range of vehicle 20 functions that can be performed by a digital key may be determined by the authority information ATP7 stored in the device 30 that has stored the key information DK indicating the digital key. The following describes a case where the authority information ATP7 of the digital key stored in the vehicle 20 to which the digital key is registered includes (b) power-on control and (c) door unlocking and locking control. In this case, if the authority information ATP7 stored in the device 30 that has stored the key information DK indicating the digital key includes (c) door unlocking and locking control, the digital key can perform (c) door unlocking and locking control on the vehicle 20. If the authority information ATP7 stored in the device 30 that has stored the key information DK indicating the digital key includes (b) power-on control and (c) door unlocking control and locking control, the digital key can perform (b) power-on control and (c) door unlocking control and locking control for the vehicle 20. If the authority information ATP7 stored in the device 30 that has stored the key information DK indicating the digital key includes (a) vehicle 20 engine start control, (b) power-on control, and (c) door unlocking control and locking control, the digital key can perform (a) vehicle 20 engine start control, (b) power-on control, and (c) door unlocking control and locking control for the vehicle 20.

[0202] The following describes a case where the range of vehicle 20 functions that can be performed by a digital key is determined by the authority information ATP7 stored in the device 30 that has stored key information DK indicating the digital key. In this case, in step S206 shown in FIG. 16 , the management server 70 transmits a permission request D71, which is a signal for permitting an out-of-range operation A not initially included in the authority information ATP7 for the first digital key serving as the non-friend key KN, to the non-friend device 52, which is the third device 30C to which the first digital key (non-friend key KN) is registered. When the non-friend device 52 receives the signal for permitting the out-of-range operation A not initially included in the authority information ATP7 for the non-friend key KN, it changes the authority information ATP7 for the non-friend key KN stored in the non-friend device 52. Before receiving the above signal, the non-friend device 52 stores, as the authority information ATP7 for the non-friend key KN, (b) power-on control for the vehicle 20 and (c) door unlocking and locking control for the vehicle 20. When the non-friend device 52 receives the above signal, it adds (a) engine start control of the vehicle 20 to the authority information ATP7 of the non-friend key KN. As a result, the authority information ATP7 of the non-friend key KN already stored in the non-friend device 52 is changed to include (a) engine start control of the vehicle 20, (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20. In this case, the management server 70 does not need to send the permission request D71 to the vehicle 20. Below, a case will be described in which the management server 70 sends the permission request D71 to the non-friend device 52 in step S206. In this case, the management server 70 sends a prohibition request D72 to the non-friend device 52 in step S209. As a result, in step S211, the non-friend device 52 changes the authority information ATP7 stored in the non-friend device 52 in the same way as in step S210 in the second embodiment with the vehicle 20. That is, the non-friend device 52 deletes (a) the engine start control of the vehicle 20 from the authority information ATP7 stored in the non-friend device 52.As a result, when the predetermined termination condition EC is met, the management server 70 prohibits the out-of-range operation A, which is not initially included in the authority information ATP7 for the non-friend key KN, from being performed on the vehicle 20. This allows the management server 70 to reassure the vehicle owner, who is the user of the owner device 40 that has stored information about the digital key associated with the first digital key (non-friend key KN).

[0203] In step S205, the management server 70 may change the authority information ATP7 for the non-friend key KN already stored in the database DB in the same way as the authority information ATP7 for the non-friend key KN already stored in the vehicle 20 in step S207. In step S209, the management server 70 may change the authority information ATP7 for the non-friend key KN already stored in the database DB in the same way as the authority information ATP7 for the non-friend key KN already stored in the vehicle 20 in step S210.

[0204] When a predetermined termination condition EC is satisfied, the management server 70 may store the state of the non-friend key KN as a fade-out state. In this case, in step S209, the management server 70 generates a prohibition request D72 and a prohibition notification M75 after a predetermined fade-out period has elapsed. The case where the predetermined termination condition EC is satisfied is not limited to the case where a predetermined fade-out period has elapsed. For example, the predetermined termination condition EC may be the case where the vehicle 20 is located at a predetermined location. In this case, in step S99, the vehicle 20 generates the prohibition request D72 and the prohibition notification M75 after being located at the predetermined location. The predetermined location may include, for example, a predetermined parking lot.

[0205] 11 to 14 and 18 illustrate a management server 70 according to a third embodiment. The third embodiment will be described mainly with respect to differences from the first embodiment. The management server 70 according to the third embodiment is configured to be able to transmit a confirmation request notification M300 to the second device 30B, which is the friend device 51. The confirmation request notification M300 as a confirmation notification will be described later. In FIGS. 11 and 12 of the third embodiment, the second device 30B should be interpreted as being described instead of the owner device 40. In other words, in the third embodiment, the "second device 30B" is described instead of the "owner device 40" in FIGS. 11 and 12.

[0206] <Generation of confirmation request notification M300 by management server 70 in third embodiment> Figure 18 is an explanatory diagram showing the flow of a series of processes executed by management server 70 in management system 10 of the third embodiment. As shown in Figure 1, in management server 70, server storage device 72 has already stored a confirmation program PM. Server execution device 71 executes the confirmation program PM stored in server storage device 72. This causes management server 70 to execute a series of processes.

[0207] The friend device 51 is a second device 30B that has stored key information DK indicating a friend key KF through the series of processes shown in FIG. 6 . The friend key KF is registered in the second device 30B as a second digital key. The non-friend device 52 is a third device 30C that has stored key information DK indicating a non-friend key KN through the series of processes shown in FIG. 7 . The non-friend key KN is registered in the third device 30C as a first digital key. In other words, the second digital key as the friend key KF is a digital key generated from the first digital key as the non-friend key KN. In other words, the second digital key as the friend key KF is a digital key that has been associated with the first digital key as the non-friend key KN. The second device 30B is a device 30 that has stored information regarding a digital key (friend key KF) that has been associated with the first digital key (non-friend key KN). In other words, the second device 30B is an association storage device.

[0208] As shown in Figure 18, when a user of a third device 30C, which is a non-friend device, performs an out-of-range operation A on the vehicle 20 that is not initially included in the authority information ATP7 in the non-friend key KN, the vehicle 20 performs processing in step S91.

[0209] In step S91, the vehicle 20 generates a first permission request notification M61. The first permission request notification M61 is a notification requesting permission for an out-of-range operation A that is not initially included in the authority information ATP7 for the non-friend key KN registered in the third device 30C when the out-of-range operation A is performed on the vehicle 20. The vehicle 20 transmits the first permission request notification M61 to the management server 70.

[0210] The management server 70 is configured to be able to receive a first permission request notification M61 from the vehicle 20. Upon receiving the first permission request notification M61, the management server 70 performs processing in step S300. In step S300, the management server 70 generates a confirmation request notification M300, which is a notification requesting permission for an out-of-range operation A not initially included in the authority information ATP7, in accordance with the first permission request notification M61. The confirmation request notification M300 includes information for setting whether or not to permit the out-of-range operation A not initially included in the authority information ATP7 in the non-friend key KN through the operation of the second device 30B. The management server 70 transmits the confirmation request notification M300 to the second device 30B. That is, the management server 70 transmits the confirmation request notification M300 as a confirmation notification not to the owner device 40 but to the second device 30B.

[0211] <Processing Performed by Friend Device 51 After Receiving Confirmation Request Notification M300> The second device 30B is configured to be able to receive the confirmation request notification M300 from the management server 70. When the second device 30B receives the confirmation request notification M300, the second device 30B performs processing in step S301. In step S301, the second device 30B presents, on the device HMI_32, an image that allows the user of the second device 30B to set whether to permit the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN.

[0212] Figure 13 is an example of an image presented on the device HMI_32 of the second device 30B to allow the user of the second device 30B to set whether or not to allow out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN.

[0213] The user of the second device 30B follows the instructions presented on the device HMI_32 and selects either "YES" or "NO" by operating the radio button for out-of-range operation A (a) "Engine start control of vehicle 20."

[0214] <Step S301: If the Out-of-Range Operation is YES> The following description will be made with appropriate modifications to FIG. 11 . That is, the "owner device 40" in FIG. 11 can be read as the "second device 30B." When the user of the second device 30B selects "YES" by operating the radio button and then presses "OK" (step S301: YES), the second device 30B performs the process of step S94 shown in FIG. 11 . That is, while the owner device 40 performs the process of step S94 in the first embodiment, the second device 30B performs the process of step S94 shown in FIG. 11 in the third embodiment. In the process of step S94, the second device 30B presents, on the device HMI_32, an image that prompts the user of the second device 30B to select whether to set an end condition EC for the permission of the out-of-range operation A.

[0215] 14 shows an example of an image presented on the device HMI_32 of the second device 30B in the process of step S94. This image prompts the user of the second device 30B to select whether or not to set the termination condition EC for the permission of the out-of-range operation A.

[0216] The user of the second device 30B selects either "YES" or "NO" by operating a radio button regarding whether or not to set the termination condition EC, following the guidance presented on the device HMI_32. If the user of the second device 30B selects "YES" regarding the setting of the termination condition EC by operating the radio button, the user of the second device 30B can select the termination condition EC by operating the radio button.

[0217] In the third embodiment, in step S94 shown in FIG. 11 , the second device 30B, not the owner device 40, generates the permission notification M63. The permission notification M63 is a notification permitting the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN. The permission notification M63 includes "until the power of the vehicle 20 is turned off" as the default termination condition EC. If the termination condition EC is not set in the processing of step S94, the permission notification M63 does not include the termination condition EC. The second device 30B, not the owner device 40, transmits the permission notification M63 to the management server 70. The management system 10 then performs the series of processes shown in FIG. 11 .

[0218] <Step S301: If the answer is NO for out-of-range operation> In step S301 shown in FIG. 18, if the user of the second device 30B operates the radio button to select "NO" shown in FIG. 13 and then presses "OK" (step S301: NO), the processing continues to a flow similar to that in FIG. 12.

[0219] The second device 30B generates an out-of-range operation refusal notification M67, similar to the owner device 40 shown in Fig. 12 in the first embodiment. The out-of-range operation refusal notification M67 is a notification rejecting the out-of-range operation A, which is not initially included in the authority information ATP7 in the non-friend key KN. In the third embodiment, the second device 30B, rather than the owner device 40, transmits the out-of-range operation refusal notification M67 to the management server 70. Thereafter, the management system 10 performs a series of processes shown in Fig. 12.

[0220] <Operation of the Third Embodiment> A first digital key is registered as a non-friend key KN in the third device 30C, which is a non-friend device 52. The third device 30C is a device 30 that has already stored information about the first digital key (non-friend key KN). In other words, the third device 30C is a first storage device.

[0221] A second digital key is registered as a friend key KF in the second device 30B, which is the friend device 51. The second digital key (friend key KF) is a digital key generated from the first digital key, which is the non-friend key KN. In other words, the friend key KF is the first generated digital key. In other words, the second digital key (friend key KF) is a digital key that has been associated with the first digital key (non-friend key KN). The second device 30B is a device 30 that has stored information about the digital key (friend key KF) that has been associated with the first digital key (non-friend key KN). In other words, the second device 30B is an association storage device.

[0222] When a user of a third device 30C that has registered a first digital key as a non-friend key KN performs an out-of-range operation A on a vehicle 20 that is not initially included in the authority information ATP7 for the non-friend key KN, the management server 70 sends a confirmation request notification M300 to the second device 30B that is the friend key KF.

[0223] Advantages of the Third Embodiment The second device 30B has stored information about the second digital key serving as the friend key KF that generated the first digital key serving as the non-friend key KN. The management server 70 allows the user of the second device 30B to understand how the vehicle 20 is being used by the user of the third device 30C to which the first digital key (non-friend key KN) has been registered.

[0224] Furthermore, the management server 70 can allow the user of the second device 30B to permit or deny the use of functions of the vehicle 20 by the user of the third device 30C to which the first digital key as the non-friend key KN has been registered. The second digital key (friend key KF) is the friend key KF generated from the first digital key as the non-friend key KN. This allows the management server 70 to convey the intention of the user of the device 30 that has stored information about the second digital key (friend key KF) to the third device 30C to which the first digital key (non-friend key KN) has been registered.

[0225] <Modifications of the Third Embodiment> The third embodiment can be modified as follows: The third embodiment and the following modifications of the third embodiment can be combined and implemented within a range that does not cause technical contradictions.

[0226] The third embodiment is suitable for cases where the user who primarily drives the vehicle 20 is the user of the friend device 51. For example, if the vehicle owner is a rental or sharing business operator, the user who primarily drives the vehicle 20 is the user of the friend device 51 to which the friend key KF has been registered based on a registration request from the device 30 belonging to the vehicle owner. In this case, even if the user of a non-friend device 52 registered based on the registration request from the friend device 51 requests permission to use functions of the vehicle 20 from the vehicle owner, the intention of the user of the friend device 51 who primarily drives the vehicle 20 cannot be reflected in the permission request from the user of the non-friend device 52. In contrast, the management server 70 of the third embodiment can allow the user of the friend device 51 who primarily drives the vehicle 20 to permit or deny the user of the non-friend device 52 to use functions of the vehicle 20. This allows the management server 70 to convey the intention of the user of the friend device 51 who primarily drives the vehicle 20 to the user of the non-friend device 52.

[0227] The management server 70 only needs to transmit the confirmation request notification M300 to at least one device 30 that has stored information about the digital key associated with the first digital key as the non-friend key KN. The confirmation request notification M300 does not have to be transmitted to the second device 30B that has stored information about the second digital key (friend key KF) that generated the first digital key (non-friend key KN).

[0228] The management server 70 may transmit a confirmation request notification to two or more devices 30 that have stored information about the digital key associated with the first digital key as the non-friend key KN. For example, if the management server 70 has received a first request notification M60 from a non-friend device 52 that has registered the first digital key (non-friend key KN), the management server 70 may transmit a confirmation request notification to multiple devices 30 that have stored information about the digital key associated with the first digital key (non-friend key KN). Here, the multiple devices 30 include, for example, the second device 30B that is the friend device 51 and the first device 30A that is the owner device 40.

[0229] <Other Modifications> Other elements that can be modified in common to the above embodiments include the following: The following modifications can be implemented in combination with each other to the extent that they are not technically inconsistent.

[0230] The matters relating to the digital keys in the above embodiments do not have to comply with the CCC. The default termination condition EC does not have to be selectable by the owner device 40. For example, the management server 70 may be configured to set a specific condition as the default termination condition EC. In this case, the management server 70 may transmit a notification to the owner device 40 when the default termination condition EC is met, prompting the user to select only whether or not to prohibit the out-of-range operation A that is not initially included in the authority information ATP7 in the non-friend key KN.

[0231] The management server 70 does not have to be configured to be able to set the default termination condition EC. If the vehicle 20 has already stored the authority information ATP7, the management server 70 does not have to cause the non-friend device 52 to store the authority information ATP7.

[0232] If the non-friend device 52 has already stored the authority information ATP7, the management server 70 does not need to store the authority information ATP7 in the vehicle 20. The range of vehicle 20 functions that the device 30 can perform, as indicated in the authority information ATP7, is not limited to the functions described in the embodiment. For example, the authority information ATP7 may include a function that permits only the unlocking control and the locking control of the trunk box in the vehicle 20.

[0233] The management system 10 may be configured so that the authority information ATP7 stored in the device 30 that has stored the key information DK indicating the digital key matches the authority information ATP7 of the digital key stored in the vehicle 20.

[0234] 11 , the management server 70 may transmit a permission request D61 to the vehicle 20 and the non-friend device 52. In this case, the management server 70 transmits a signal to the non-friend device 52 to delete the out-of-range operation A added to the authority information ATP7 of the non-friend device 52 in step S101 shown in FIG.

[0235] 16 , the management server 70 may transmit a permission request D71 to the vehicle 20 and the non-friend device 52. In this case, the management server 70 transmits a prohibition request D72 to the vehicle 20 and the non-friend device 52 in step S209 shown in FIG.

[0236] <Registration of a new non-friend key KN by the non-friend device 52> The non-friend device 52 may be able to transmit a request for registering a new non-friend key KN. In other words, a share device 50 that has stored a share key KS may transmit a request for registering a new non-friend key KN, regardless of whether the share device 50 is a friend device 51 or a non-friend device 52. In this case, the management system 10 may register the new non-friend key KN by the series of processes shown in FIG. 7 .

[0237] 4 , the third device 30C, which is the non-friend device 52 that has stored therein the key information DK indicating the non-friend key KN of the vehicle 20, may transmit a request to register a new non-friend key KN of the vehicle 20. As a result, the new device 30 that has stored therein the key information DK of the new non-friend key KN of the vehicle 20 is registered as the non-friend device 52.

[0238] If the digital key registered in the new device 30 is considered to be the first digital key, the third device 30C is a device 30 in which the second digital key is registered. In this case, the second device 30B is a device 30 in which the third digital key is registered.

[0239] The management server 70 may send a notification to the second device 30B indicating that the new device 30 requests permission for an out-of-range operation A that is not initially included in the range of functions executable by the non-friend key KN of the vehicle 20. This allows the management server 70 to allow the user of the second device 30B that has stored information about the digital key associated with the first digital key to understand the usage status of the vehicle 20 by the user of the new device 30 to which the first digital key has been registered. Furthermore, the management server 70 can allow the user of the second device 30B that has stored information about the digital key associated with the first digital key to permit or deny the user of the new device 30 to use functions of the vehicle 20. This allows the management server 70 to convey the intention of the user of the second device 30B that has stored information about the digital key associated with the first digital key to the user of the new device 30 to which the first digital key has been registered.

[0240] The management server 70 may send a notification to the third device 30C requesting permission for an out-of-range operation A that is not initially included in the range of functions that the new device 30 can perform as a non-friend key KN of the vehicle 20. This allows the user of the third device 30C that has stored information about the digital key associated with the first digital key to understand the usage status of the vehicle 20 by the user of the new device 30 to which the first digital key has been registered. Furthermore, the management server 70 can allow the user of the third device 30C that has stored information about the digital key associated with the first digital key to permit or deny the user of the new device 30 to use functions of the vehicle 20. This allows the management server 70 to convey the intention of the user of the third device 30C that has stored information about the digital key associated with the first digital key to the user of the new device 30 to which the first digital key has been registered.

[0241] The management server 70 may send a notification to the first device 30A, which is the owner device 40, requesting permission for an out-of-range operation A that is not initially included in the range of functions that the new device 30 can perform as a non-friend key KN of the vehicle 20. This allows the management server 70 to allow the user of the first device 30A, which has stored information about the digital key associated with the first digital key, to understand the usage status of the vehicle 20 by the user of the new device 30, to which the first digital key has been registered. Furthermore, the management server 70 can allow the user of the first device 30A, which has stored information about the digital key associated with the first digital key, to permit or deny the user of the new device 30 to use functions of the vehicle 20. This allows the management server 70 to convey the intention of the user of the first device 30A, which has stored information about the digital key associated with the first digital key, to the user of the new device 30, to which the first digital key has been registered.

[0242] <Management System 10> The vehicle 20 does not need to have some of the BLE module 23, the UWB module 24, and / or the NFC module 25. As long as the vehicle 20 has at least one short-range communication module, it can perform short-range communication with the device 30. Furthermore, the vehicle 20 is not limited to having these communication modules, and it is sufficient if the vehicle 20 has a module that performs short-range communication with the device 30.

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

[0244] The vehicle management device 26 may be configured as a circuit having one or more processors that execute various processes according to a computer program (software) or program product. The vehicle management device 26 may be configured as a circuit having one or more dedicated hardware circuits, such as an application-specific integrated circuit (ASIC), or a combination thereof, that execute at least some of the various processes. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code, programs, program products, or instructions that cause the CPU to execute various processes. The memory, i.e., a non-transitory computer-readable storage medium, includes any available medium that can be accessed by a general-purpose or dedicated computer. The same applies to the device 30 and the management server 70.

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

[0246] In each of the above embodiments, the digital keys are arranged in a hierarchy of the owner key KO, friend key KF, and non-friend key KN from top to bottom, with the higher the hierarchy, the greater the authority. The higher the hierarchy of the digital keys, the greater the authority does not have to be. For example, the same authority level may be set for the three hierarchical levels of the owner key KO, friend key KF, and non-friend key KN.

[0247] The device server 60 does not have to be provided for each type of device 30. It is sufficient that multiple devices 30 and the management server 70 are capable of wireless communication. The device server 60 may be omitted. It is sufficient that multiple devices 30 and the management server 70 are capable of direct wireless communication.

[0248] The management server 70 may be configured with multiple servers. For example, the management server 70 may be configured with a server portion that stores the database DB and a server portion that executes the server program PS. Alternatively, for example, the management server 70 may be configured with a server portion that communicates with the vehicle 20 and a server portion that communicates with the device server 60, and these server portions may be capable of communicating with each other.

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

[0250] The share device 50 has a function to receive the share key KS, as in the above embodiment. A device 30 having a function to receive a digital key, such as the share device 50, is sometimes called a receiver device.

[0251] <Various Information> The authentication information AT may be any information for authenticating the digital key when it is used, and is not limited to the examples in the above embodiments. For example, the authentication information AT may be a common key shared by the vehicle management device 26 and the device 30. Alternatively, the authentication information AT may be a common secret key.

[0252] The information included in the key information DK is not limited to the configuration described in the above embodiment. For example, the owner key information DKO does not need to include the slot identification information ST4. Furthermore, the key information DK may include information indicating the type of digital key. The type of digital key is, for example, information indicating one of the owner key KO, friend key KF, and non-friend key KN.

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

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

[0255] <Processing for Registering a Digital Key> The processing for registering the owner key KO is not limited to the examples in the above embodiments. For example, the owner device 40 may store the owner key information DKO by transmitting and receiving information such as the generated data DC between the vehicle 20 and the first device 30A via the management server 70, even if pairing is not performed by the processing in step S12. The processing for registering the owner key KO may be modified as appropriate depending on the structure of the information included in the owner key information DKO and the structure of the information included in the authentication information AT.

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

[0257] The series of processes for registering a non-friend key KN is not limited to the examples in the above embodiments. The order of the series of processes for registering a non-friend key KN may be different from the order of the series of processes for registering a friend key KF. The series of processes for registering a non-friend key KN may be changed as appropriate depending on the structure of the information included in the non-friend key information DKN and the structure of the information included in the authentication information AT.

[0258] The types of digital keys do not have to include the non-friend key KN. In other words, in the management system 10, the share key KS may only be the friend key KF. <Processing for Deleting a Digital Key> In each of the above embodiments, the friend device 51 sends a deletion reservation D41 to the management server 70 when deleting the non-friend key KN, but it does not have to be a reservation. In other words, the friend device 51 may send a request to delete the non-friend key KN to the management server 70 regardless of the default condition RC. Furthermore, the deletion request does not necessarily have to be issued by the friend device 51; the management server 70 may proceed with the processing from step S62 onwards when the owner device 40 issues a request to delete the non-friend key KN.

[0259] The following describes a case where an operation to request deletion of a non-friend key KN is executed in the non-friend device 52. In this case, instead of the processing in step S81 of FIG. 9 , the non-friend device 52 may send a request to delete the non-friend key KN registered in the non-friend device 52 to the management server 70. Upon receiving the deletion request, the management server 70 generates a request to delete the non-friend key information DKN, similar to step S66 of FIG. 8 . Thereafter, the management server 70 sends a request to delete the non-friend key information DKN to the non-friend device 52. Having received the request to delete the non-friend key information DKN, the non-friend device 52 deletes the non-friend key information DKN, similar to step S67 of FIG. 8 . Thereafter, the non-friend device 52 sends a notification to the management server 70 indicating that the non-friend key information DKN has been deleted. After receiving the notification indicating that the non-friend key information DKN has been deleted in the non-friend device 52, the management server 70 proceeds with the processing from step S82 onward shown in FIG. 9 . The non-friend device 52 does not need to send a notification indicating that the non-friend key information DKN has been deleted to the management server 70. In this case, the management server 70 sends a request to the non-friend device 52 to delete the non-friend key information DKN, and then proceeds with the processing from step S82 onwards shown in FIG.

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

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

Claims

1. A server comprising a server processing circuit, the server processing circuit configured to manage a plurality of digital keys available for a vehicle, the plurality of digital keys comprising a first digital key and a plurality of associated digital keys associated with the first digital key, the first digital key having an executable function range set thereto, the server processing circuit configured to transmit a confirmation request notification to at least one associated storage device, the at least one device having information stored therein about the associated digital keys, when an out-of-range operation is performed that is not initially included in the executable function range.

2. The server of claim 1, wherein said server processing circuitry is configured to transmit said confirmation request notification to at least one of said associated storage devices upon receiving an authorization request notification.

3. The server of claim 2, wherein the server processing circuitry is configured to transmit the confirmation request notification to at least one of the associated storage devices upon receiving the authorization request notification from the vehicle.

4. The server of claim 2 or 3, wherein the server processing circuitry is configured to transmit the confirmation request notification to at least one of the associated storage devices when the authorization request notification is received from a first storage device that is a device that has information about the first digital key stored therein.

5. A server according to any one of claims 1 to 4, wherein the server processing circuit is configured to, when receiving a permission notification from the associated storage device that allows the out-of-range operation, send a permission request to add the out-of-range operation to the executable function range of the first digital key, and to send a prohibition request to delete the out-of-range operation from the executable function range of the first digital key when a predetermined termination condition is met.

6. The server of claim 5, wherein the server processing circuitry is configured to transmit the permission request and the prohibition request to the vehicle.

7. The server according to claim 5 or 6, wherein the server processing circuit is configured to transmit the permission request and the prohibition request to a first storage device that is a device that has information about the first digital key stored therein.

8. A server according to any one of claims 5 to 7, wherein the server processing circuit is configured to receive information indicating the termination condition from the associated storage device and to set the termination condition in accordance with the information indicating the termination condition.

9. A server according to any one of claims 1 to 8, wherein the plurality of associated digital keys includes a first generated digital key that is a digital key that generated the first digital key, and the server processing circuitry is configured to transmit the confirmation request notification to a device that has stored information about the first generated digital key.

10. A server according to any one of claims 1 to 9, wherein the plurality of associated digital keys includes an owner key, only one of which can be registered to the vehicle, and the server processing circuit is configured to transmit the confirmation request notification to a device that has stored information about the owner key.

11. A setting method comprising the steps of: managing, by a server processing circuit of a server, a plurality of digital keys available for a vehicle, the plurality of digital keys including a first digital key and a plurality of associated digital keys associated with the first digital key, the first digital key having a range of executable functions set thereto; receiving notification that an out-of-range operation has been performed, the operation being an operation not initially included in the range of executable functions; and sending a confirmation request notification for the out-of-range operation to at least one associated storage device, the at least one device having information about the associated digital keys stored therein.

12. A program that causes a server processing circuit of a server to execute a setting process, the setting process comprising: managing a plurality of digital keys that can be used for a vehicle, the plurality of digital keys comprising a first digital key and a plurality of associated digital keys that have been associated with the first digital key, the first digital key having a set operable function range that is a range of operable functions; receiving a notification that an out-of-range operation has been performed, which is an operation that is not initially included in the operable function range; and sending a confirmation request notification for the out-of-range operation to at least one associated storage device that is at least one device that has information about the associated digital keys stored therein.

Images