Server, setting method, program, and system

Abstract

Provided are a server, a setting method, a program, and a system. A server processing circuit (71) manages a plurality of digital keys (KO, KF, KN) that can be used for a vehicle (20). A second digital key (KN) is generated (S41) on the basis of a first digital key (KF). The server processing circuit (71) sets (S103) an executable function range of the second digital key (KN) in accordance with a post-change executable function range of the first digital key (KF).

Description

Server, setting method, program, and system

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

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, an owner device, a shared device, and a management server. The owner device registers an owner key. An owner key is a digital key that can only exist once per vehicle. The shared device registers a shared key based on a registration request from the owner device. A single vehicle can have multiple shared keys.

[0003] The management server manages multiple digital keys, including, for example, an owner key and multiple shared keys. When a digital key is used, the vehicle authenticates the digital key and allows control of the vehicle, such as unlocking the vehicle.

[0004] JP 2024-001720 A

[0005] In a management system such as that described in the above document, it is conceivable that a new share key will be registered when a share key makes another registration request.

[0006] According to one aspect of the present disclosure, there is provided a server including a server processing circuit. The server processing circuit manages a plurality of digital keys available for a vehicle. The plurality of digital keys include a first digital key and a second digital key generated based on the first digital key. When the range of functions available for the first digital key is changed, the server processing circuit is configured to set the range of functions available for the second digital key according to the changed range of functions available for the first digital key.

[0007] According to another aspect of the present disclosure, there is provided a setting method. The setting method is executed by a server that manages a plurality of digital keys available for a vehicle. The plurality of digital keys include a first digital key and a second digital key generated based on the first digital key. The setting method includes a communication device of the server receiving information that a range of functions available for the first digital key has been changed, and, if the range of functions available for the first digital key has been changed, a processing circuit of the server setting a range of functions available for the second digital key according to the changed range of functions available for the first digital key.

[0008] According to yet another aspect of the present disclosure, there is provided a program or program product. The program or program product is stored in a storage device of a server that manages a plurality of digital keys available for vehicles. The plurality of digital keys include a first digital key and a second digital key generated based on the first digital key. When the range of functions available for the first digital key is changed, the program or program product causes a processing circuit of the server to execute a process for setting the range of functions available for the second digital key in accordance with the changed range of functions available for the first digital key.

[0009] According to yet another aspect of the present disclosure, there is provided a system including a vehicle having stored therein information related to a digital key, and a server that manages a plurality of digital keys that can be used for the vehicle. The plurality of digital keys include a first digital key and a second digital key generated based on the first digital key. When the range of functions that can be performed by the first digital key is changed, the system sets the range of functions that can be performed by the second digital key according to the changed range of functions that can be performed by the first digital key.

[0010] According to yet another aspect of the present disclosure, there is provided a system including a plurality of devices storing information about digital keys and a server managing the plurality of digital keys. The plurality of digital keys include a first digital key and a second digital key generated based on the first digital key. When the range of functions available for the first digital key is changed, the system sets the range of functions available for the second digital key according to the changed range of functions available for the first digital key.

[0011] The above-mentioned server, setting method, program, and system are configured so that when the range of functions that can be implemented by a digital key is changed, the range of functions that can be implemented by another digital key generated based on that digital key can be changed in accordance with the range of functions that can be implemented by the digital key after the change.

[0012] In a management system such as that described in the above document, it is conceivable that a new share key will be registered when a share key makes another registration request. This new share key is referred to as a non-friend key. In such a case, there may be a need to set the range of functions that the non-friend key can perform as a digital key based on the range of functions that the share key that requested the registration of the non-friend key can perform as a digital key (the range of functions that can be performed). Specifically, there may be a need to set the range of functions that the non-friend key can perform as a digital key narrower than the range of functions that the share key that requested the registration of the non-friend key can perform as a digital key. Here, it is conceivable that the range of functions that the share key can perform as a digital key will change. In such a case, there may be a desire to change the range of functions that the non-friend key can perform as a digital key in accordance with the change in the range of functions of the share key. The various configurations described above can meet this need.

[0013] 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 an owner key is registered. FIG. 6 is an explanatory diagram showing a series of processes performed by the management server when a friend key is registered. FIG. 7 is an explanatory diagram showing a series of processes performed by the management server when a non-friend key is registered. 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 process of FIG. 10. FIG. 12 is an explanatory diagram showing a continuation of the process of FIG. 11. FIG. 13 is an explanatory diagram showing a continuation of the process of FIG. 12. FIG. 14 is an explanatory diagram showing a series of processes performed by a management system including a management server of the second embodiment. FIG. 15 is an explanatory diagram showing a continuation of the processes of FIG. 14. FIG. 16 is an explanatory diagram showing a continuation of the processes of FIG. 15. FIG. 17 is an explanatory diagram showing a series of processes performed by a management system including a management server of a modified example of the second embodiment. FIG. 18 is an explanatory diagram showing a continuation of the processes of FIG. 17. FIG. 19 is an explanatory diagram showing a series of processes performed by a management system including a management server of a third embodiment. FIG. 20 is an explanatory diagram showing a continuation of the processes of FIG. 19. FIG. 21 is an explanatory diagram showing a continuation of the processes of FIG. 20. FIG. 22 is an explanatory diagram showing a continuation of the processes of FIG. 21. FIG. 23 is a schematic diagram showing the relationship between owner devices, friend devices, and non-friend devices. FIG. 24 is an explanatory diagram showing a series of processes performed by a management system including a management server of a modified example.

[0014] 1 to 13 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.

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

[0016] The communication module 21 communicates with the management server 70 via a wireless communication network. The communication module 21 constitutes at least a part of a vehicle communication device. 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.

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

[0018] 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 stores 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 used to authenticate 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.

[0019] Authenticating a 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.

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

[0021] The communication module 31 communicates with the device server 60 via a wireless communication line. The communication module 31 constitutes at least a part of a device communication apparatus. 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.

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

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

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

[0025] The multiple devices 30 include an owner device 40 and multiple shared devices 50. The owner device 40 stores 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.

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

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

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

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

[0030] 1, the share device 50 stores 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.

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

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

[0033] 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 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 key information DK indicating the non-friend key KN. 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 have the device 30 store the non-friend key information DKN, which is key information DK.

[0034] 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 stores authentication information AT, and the device 30 stores 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 stores 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 stores information related to the digital key.

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

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

[0037] The signature information ATP1 indicates that the shared device 50 is a legitimate target for sharing the digital key. For example, in the case of the 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, in the case of the 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.

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

[0039] The authority information ATP7 is information indicating the range of executable functions of the device 30 in which the authority information ATP7 is stored. The range of executable functions includes, for example, the number of share keys KS that can be requested for registration and the range of vehicle functions that can be implemented by digital key authentication. The range of executable vehicle functions 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 vehicle functions includes the above-described three controls (a) to (c), the range of executable vehicle functions is wider than, for example, if the range of executable vehicle functions includes only (c) door unlocking and locking control of the vehicle 20. More specifically, the range of executable vehicle functions of the friend device 51 includes the above-described three functions. On the other hand, the range of vehicle functions that the non-friend device 52 can perform includes two: (b) power-on control of the vehicle 20, and (c) unlocking and locking control of the doors of the vehicle 20.

[0040] 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 may be 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 may be 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 may be provided for each communication line used by the device 30. Since all device servers 60 relay communication with the management server 70, different types of devices 30 can communicate with the management server 70 via the device server 60. For convenience, only one device server 60 is illustrated in FIG. 1 .

[0041] <Management Server 70> The management server 70 manages the digital keys. 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 server communication module 73. The server communication module 73 communicates with the device server 60 via a wireless communication line. The server communication module 73 is also capable of wireless communication with the communication module 21 of the vehicle 20. The server communication module 73 constitutes at least a part of the server communication device.

[0042] The server storage device 72 stores a server program PS, a change program PM, and a database DB. The server program PS causes the server execution device 71 to execute various server processes, causing the server execution device 71 to register and delete digital keys from the database DB. The server execution device 71 is equipped with a server processing circuit. Details of the change program PM will be described later.

[0043] In the database DB, each of a plurality of digital keys is associated with a corresponding vehicle 20 and a registered device 30. The database DB is divided into data blocks DA for each vehicle 20. When a digital key has been registered, the management server 70 stores, in the data block DA, information indicating the device 30 that has stored key information DK indicating the digital key.

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

[0045] For example, a state in which digital keys are registered to seven devices 30 for one vehicle 20 will be described. 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.

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

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

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

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

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

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

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

[0053] In this way, the data block DA stores one or more devices 30 registered as various digital keys. When a device 30 is registered, the device 30 is associated with information indicating the device 30 that made the request that caused the registration. The data block DA also includes information indicating which digital key each digital key is registered under.

[0054] <Digital Key Registration> Next, a series of processes for registering various digital keys in the management system 10 will be described. The management system 10 registers digital keys by registering an owner key KO, a friend key KF, and a 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.

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

[0056] 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. This causes the first device 30A to become the owner device 40. When registering the owner key KO, it is assumed that the necessary applications are installed in the first device 30A.

[0057] 5, 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 processing in 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0070] 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. The second device 30B then proceeds to step S24.

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

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

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

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

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

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

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

[0078] Specifically, as part of the registration management, the management server 70 verifies that the friend key KF, which is the key to be tracked in the key track request D23, is not listed on the reject list. The reject list is a list of shared keys KS that include 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.

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

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

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

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

[0083] 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, the device 30 that will be registered as a non-friend device 52 in this series of processes is referred to as a third device 30C.

[0084] 7 , 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.

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

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

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

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

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

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

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

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

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

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

[0095] Specifically, as part of the registration management, the management server 70 checks whether the non-friend key KN, which is the key to be tracked in the key track request D33, is on the refusal list. If the non-friend key KN is on the refusal list, the management server 70 sends a notification to the third device 30C that the key track request D33 cannot be fulfilled.

[0096] On the other hand, if the non-friend key KN is not listed on the rejection list, the management server 70 registers the non-friend key KN, which is the track target key 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.

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

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

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

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

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

[0102] 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 to reserve the deletion of the non-friend key KN.

[0103] The deletion reservation D41 includes a signal for requesting 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 deletion after receiving the deletion reservation D41. The predetermined condition RC is predetermined. For example, the predetermined condition RC includes the lapse of a predetermined fade-out period after receiving the deletion reservation D41. The friend device 51 transmits the deletion reservation D41 of the non-friend key KN to the management server 70.

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

[0105] 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, which is the key to be deleted in the deletion reservation D41, is pending. For example, the friend device 51 displays, on the device HMI_32, an image indicating that the deletion of the non-friend key KN, which is the key to be deleted in the deletion reservation D41, is pending.

[0106] 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, which is the key to be deleted in 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.

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

[0108] 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 key to be deleted of the deletion reservation D41. The management server 70 transmits the deletion request D42 to the non-friend device 52.

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

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

[0111] 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, which is the key to be deleted in the deletion reservation D41, was authenticated. The management server 70 transmits the deletion request D43 to the vehicle 20.

[0112] 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 authenticating the non-friend key KN, which is the key to be deleted in the deletion reservation D41, 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.

[0113] 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 series of deletion-related processes in the vehicle 20. Thereafter, the management server 70 proceeds to the process of step S72.

[0114] 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 to the friend device 51 a deletion completion notification M44 indicating that the series of deletions of the non-friend key KN in accordance with the deletion reservation D41 have been completed.

[0115] After that, 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 information indicating that the deletion of the non-friend key KN, which is the key to be deleted in the deletion reservation D41, has been completed to the device HMI_32. Then, the management system 10 ends the series of processes for the deletion of the non-friend key KN.

[0116] <Deletion of non-friend key KN due to deletion in non-friend device 52> As shown in Figure 9, based on a deletion operation in the non-friend device 52, 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.

[0117] In the non-friend device 52, a predetermined operation is executed to request the deletion of the non-friend key KN, and 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 to the management server 70, indicating that the non-friend key information DKN has been deleted.

[0118] 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 to the friend device 51 a deletion completion notification M52 indicating that the non-friend key information DKN has been deleted.

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

[0120] 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 the non-friend key information DKN that has been deleted in step S81 was authenticated. The management server 70 transmits the deletion request D51 to the vehicle 20.

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

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

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

[0124] <Changing the authority information ATP7 by the management server 70 in the first embodiment> Next, a series of processes will be described that the management server 70 executes to change the authority information ATP7 of the friend key KF and the authority information ATP7 of the non-friend key KN in accordance with a request from the owner device 40. This series of processes includes a setting process or a setting method.

[0125] The authority information ATP7 of the friend key KF indicates the range of functions that can be implemented by the friend key KF. Specifically, the authority information ATP7 of the friend key KF is information that indicates the range of vehicle functions that can be implemented by the friend device 51 that has stored the authority information ATP7, using the friend key KF. The vehicle functions that can be implemented by the friend device 51 using the friend key KF include (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. The management server 70 is configured to be able to change the range of functions that can be implemented by the friend key KF by changing the authority information ATP7 of the friend key KF. Specifically, the management server 70 changes the range of vehicle functions that can be implemented by the friend device 51 using the friend key KF by changing the authority information ATP7 stored in the friend device 51 that has stored the key information DK indicating the friend key KF.

[0126] The authority information ATP7 of the non-friend key KN indicates the range of functions that can be performed by the non-friend key KN. Specifically, the authority information ATP7 of the non-friend key KN is information that indicates the range of vehicle functions that can be performed by the non-friend device 52 that has stored the authority information ATP7 as the non-friend key KN. The vehicle functions that can be performed by the non-friend device 52 as the non-friend key KN include (b) power-on control of the vehicle 20 and (c) locking and unlocking control of the doors of the vehicle 20. The management server 70 is configured to be able to change the range of functions that can be performed by the non-friend key KN by changing the authority information ATP7 of the non-friend key KN. Specifically, the management server 70 changes the range of vehicle functions that can be performed by the non-friend device 52 as the non-friend key KN by changing the authority information ATP7 stored in the non-friend device 52.

[0127] 1, in management server 70, server storage device 72 stores change program PM as a change program product. Server execution device 71 executes change program PM stored in server storage device 72. In this way, management server 70 executes a setting process or setting method as a series of processes.

[0128] <Series of processes to be executed to change the authority information ATP7> Figure 10 shows the flow of a series of processes to be executed by the management server 70 to change the authority information ATP7 in the friend key KF in accordance with a request from the owner device 40. The owner device 40 shown in Figure 10 is the first device 30A that has already stored key information DK indicating the owner key KO through the series of processes shown in Figure 5. The owner key KO registered in the first device 30A is a third digital key.

[0129] The friend device 51 shown in Fig. 10 is the second device 30B that has already stored key information DK indicating the friend key KF through the series of processes shown in Fig. 6. The friend key KF registered in the second device 30B is a first digital key.

[0130] The non-friend device 52 shown in Fig. 10 is a third device 30C that has already stored key information DK indicating a non-friend key KN through the series of processes shown in Fig. 7. The non-friend key KN registered in the third device 30C is a second digital key.

[0131] The following relationship exists between the third device 30C, which has already registered the second digital key (non-friend key KN), and the second device 30B, which has already registered the first digital key (friend key KF): That is, based on a registration request from the second device 30B, the second digital key, which is the non-friend key KN, has been registered in the third device 30C. That is, the non-friend key KN, which is the second digital key, is generated based on the friend key KF, which is the first digital key. The following relationship exists between the second device 30B, which has already registered the first digital key (friend key KF), and the first device 30A, which has already registered the third digital key: That is, based on a registration request from the first device 30A, the friend key KN, which is the first digital key, has been registered in the second device 30B. That is, the friend key KF, which is the first digital key, is generated based on the owner key KO, which is the third digital key.

[0132] When a change request operation for the authority information ATP7 of the friend key KF is executed in the owner device 40, the owner device 40 first performs the process of step S91. In step S91, the owner device 40 generates a change request D61 for the authority information ATP7 of the first digital key, which is the friend key KF. The change request D61 requests a change to the authority information ATP7 of the first digital key, which is the friend key KF.

[0133] The change request D61 includes a signal requesting deletion of the friend key KF, digital key identification information ST3 indicating the friend key KF, and a signal requesting registration of the friend key KF after the range change. Here, the signal requesting registration of the friend key KF after the range change includes new authority information ATP7. Here, the new authority information ATP7 indicates (b) power-on control of the vehicle 20 and (c) door unlocking and locking control of the vehicle 20 as vehicle functions that the friend device 51 can perform. That is, the new authority information ATP7 indicates (b) power-on control of the vehicle 20 and (c) door unlocking and locking control of the vehicle 20 as vehicle functions that the first digital key (friend key KF) can perform. That is, (a) engine start control of the vehicle 20 has been removed from the vehicle functions that the friend device 51 could perform before the change.

[0134] When the management server 70 receives the change request D61, it performs the process of step S92. In step S92, the management server 70 generates a pending notification M61 indicating that the change is pending in accordance with the change request D61. The management server 70 transmits the pending notification M61 to the owner device 40.

[0135] Thereafter, when the owner device 40 receives the pending notification M61, the owner device 40 performs the process of step S93. In step S93, the owner device 40 presents to the device HMI_32 information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed based on the change request D61, is pending.

[0136] <Change reservation D100 and change reservation D101> After processing step S92, the management server 70 performs processing step S120. In step S120, the management server 70 generates a change reservation D100 for the friend key information DKF and a change reservation D101 for the non-friend key information DKN indicating the non-friend key KN. The friend key information DKF indicates the key to be changed by the change request D61. The change reservation D100 is a command to reserve a change to the friend key information DKF. The change reservation D101 is a command to reserve a change to the non-friend key information DKN. The management server 70 transmits the change reservation D100 to the friend device 51. The management server 70 transmits the change reservation D101 to the non-friend device 52.

[0137] When the friend device 51 receives the change reservation D100, it performs the process of step S121. In step S121, the friend device 51 presents, to the device HMI_32, information indicating that a change of the authority information ATP7 of the friend key KF has been reserved.

[0138] When the non-friend device 52 receives the change reservation D101, it performs the process of step S122. In step S122, the non-friend device 52 presents to the device HMI_32 information indicating that a change of the authority information ATP7 of the non-friend key KN has been reserved.

[0139] After processing step S120, the management server 70 performs processing step S123. In step S120, the management server 70 stores the state of the friend key KF, which is the key to be changed by the change reservation D100, in the database DB as a fade-out state. The fade-out state here means that while the change reservation D100 has been received, the execution of the change for the key to be changed is still pending. The management server 70 stores the state of the non-friend key KN, which is the key to be changed by the change reservation D101, in the database DB as a fade-out state. The fade-out state here means that while the change reservation D101 has been received, the execution of the change for the key to be changed is still pending. The management server 70 then proceeds to processing step S124.

[0140] In step S124, the management server 70 confirms that the default conditions RC are satisfied. The default conditions RC are conditions necessary to start changing the key to be changed after the change reservation D100 and the change reservation D101 are sent. The default conditions RC are determined in advance. For example, the default conditions RC include the elapse of a predetermined fade-out period after the change reservation D100 and the change reservation D101 are generated. When the management server 70 confirms that the default conditions RC are satisfied, the management server 70 proceeds to step S94.

[0141] <Deleting Friend Key Information DKF and Non-Friend Key Information DKN> After processing step S124, the management server 70 performs processing step S94. In step S94, the management server 70 generates a deletion request D62 for deleting the friend key information DKF indicating the friend key KF, and a deletion request D63 for deleting the non-friend key information DKN indicating the non-friend key KN. Here, the friend key KF is the key to be changed by the change request D61. The management server 70 transmits the deletion request D62 to the friend device 51. The management server 70 transmits the deletion request D63 to the non-friend device 52. The series of processes proceeds to FIG. 11 .

[0142] 11 , when the friend device 51 receives the deletion request D62, it performs processing in step S95. In step S95, the friend device 51 presents information indicating that the authority information ATP7 is being changed to the device HMI_32. For example, the friend device 51 displays an image indicating that the authority information ATP7 is being changed on the device HMI_32. After processing in step S95, the friend device 51 performs processing in step S96. In step S96, the friend device 51 deletes the friend key information DKF in accordance with the deletion request D62. The friend device 51 transmits a completion notification M62 to the management server 70 indicating that the deletion in accordance with the deletion request D62 has been completed.

[0143] When the non-friend device 52 receives the deletion request D63, it performs processing of step S97. In step S97, the non-friend device 52 presents information indicating that the authority information ATP7 is being changed to the device HMI_32. For example, the non-friend device 52 displays an image indicating that the authority information ATP7 is being changed on the device HMI_32. After processing of step S97, the non-friend device 52 performs processing of step S98. In step S98, the non-friend device 52 deletes the non-friend key information DKN in accordance with the deletion request D63. The non-friend device 52 transmits a completion notification M63 to the management server 70 indicating that the deletion in accordance with the deletion request D63 has been completed.

[0144] When management server 70 receives completion notification M62 and completion notification M63, management server 70 performs the process of step S99. In step S99, management server 70 stores deletion history indicating that friend key information DKF in friend device 51 and non-friend key information DKN in non-friend device 52 have been deleted. Thereafter, management server 70 proceeds to the process of step S100.

[0145] <Deleting the Authentication Information AT of the Friend Key KF and the Authentication Information AT of the Non-Friend Key KN> In step S100, the management server 70 generates a deletion request D64 for the authentication information AT of the friend key KF and a deletion request D65 for the authentication information AT of the non-friend key KN. The management server 70 transmits the deletion request D64 and the deletion request D65 to the vehicle 20. The series of processes continues in FIG. 12 .

[0146] 12 , when the vehicle 20 receives the deletion request D64 and the deletion request D65, the vehicle 20 performs the process of step S101. In step S101, the vehicle 20 deletes the authentication information AT of the friend key KF, which is the key to be deleted in the deletion request D64, and the authentication information AT of the non-friend key KN, which is the key to be deleted in the deletion request D65, in accordance with the deletion request D64 and the deletion request D65. Thereafter, the vehicle 20 transmits to the management server 70 a completion notification M64 indicating that the deletion of the authentication information AT of the friend key KF and the authentication information AT of the non-friend key KN has been completed.

[0147] When management server 70 receives completion notification M64, management server 70 performs processing in step S102. In step S102, management server 70 stores deletion history indicating that authentication information AT of friend key KF and authentication information AT of non-friend key KN in vehicle 20 have been deleted. Thereafter, management server 70 proceeds to processing in step S103.

[0148] <Generation of friend key information DKF after range change and non-friend key information DKN after range change> In step S103, the management server 70 generates friend key information DKF after the range of the authority information ATP7 has been changed and non-friend key information DKN after the range of the authority information ATP7 has been changed.

[0149] The management server 70 generates the friend key information DKF after the range change by adding up the authority information ATP7 included in the change request D61 and the information included in the friend key information DKF already stored in the database DB but other than the authority information ATP7.

[0150] When the range of executable vehicle functions of the friend device 51 is changed, the management server 70 sets the range of executable vehicle functions of the non-friend device 52 according to the changed range of vehicle functions that the friend device 51 can execute.

[0151] The authority information ATP7 included in the change request D61 shown in FIG. 10 indicates (b) power-on control of the vehicle 20 and (c) door unlocking and locking control of the vehicle 20 as the range of vehicle functions that the friend device 51 can perform. The management server 70 then sets the vehicle functions that the non-friend device 52 can perform to (c) door unlocking and locking control of the vehicle 20. Therefore, the management server 70 generates authority information ATP7 that indicates (c) door unlocking and locking control of the vehicle 20 as the vehicle functions that the non-friend device 52 can perform. That is, the authority information ATP7 indicates (c) door unlocking and locking control of the vehicle 20 as the vehicle functions that the second digital key (non-friend key KN) can perform. The management server 70 generates the range-changed non-friend key information DKN by combining the authority information ATP7 with information other than the authority information ATP7 that is included in the non-friend key information DKN stored in the database DB. As a result, the management server 70 sets the authority information ATP7, which is the range of vehicle functions that can be performed by the non-friend device 52, to a value narrower than the changed range of vehicle functions that can be performed by the friend device 51. Thereafter, the management server 70 proceeds to step S104 shown in FIG. 12 .

[0152] <Updating the Database DB> In step S104, the management server 70 updates the database DB. Specifically, the management server 70 deletes the authentication information AT of the friend key KF for the vehicle 20 and the authentication information AT of the non-friend key KN for the vehicle 20 from the data block DA of the vehicle 20 in the database DB. Here, the friend key KF is the target key for this series of processes. The management server 70 registers, in the data block DA of the vehicle 20 in the database DB, the authentication information AT included in the friend key information DKF after the range change generated by the management server 70 in step S103 and the authentication information AT included in the non-friend key information DKN after the range change. That is, the management server 70 stores the authority information ATP7 included in the change request D61 in the database DB.

[0153] <Transmission of key information DK and authentication package ATP> The management server 70 transmits friend key information DKF after the range change and a storage request D66 for storing the friend key information DKF after the range change to the friend device 51. The management server 70 transmits non-friend key information DKN after the range change and a storage request D67 for storing the non-friend key information DKN after the range change to the non-friend device 52. The management server 70 transmits the authentication package ATP included in the friend key information DKF after the range change and the authentication package ATP included in the non-friend key information DKN after the range change to the vehicle 20. The management server 70 transmits a storage request D68 to the vehicle 20 for storing the authentication package ATP included in the friend key information DKF after the range change and the authentication package ATP included in the non-friend key information DKN after the range change.

[0154] <Processing After Device 30 Receives Key Information DK> When the friend device 51 receives the friend key information DKF after the range change and the storage request D66, the friend device 51 performs the process of step S105. In step S105, the friend device 51 stores the friend key information DKF after the range change. That is, the management server 70 stores the authority information ATP7 in the friend key information DKF after the range change in the friend device 51, which is a shared device. As a result, the request to change the authority information ATP7 of the friend key KF made in the owner device 40 is reflected in the friend device 51. The series of processes is continued in FIG. 13 .

[0155] 13. In step S106, the friend device 51 presents information indicating that the change of the authority information ATP7 has been completed to the device HMI_32. For example, the friend device 51 displays an image indicating that the change of the authority information ATP7 has been completed on the device HMI_32. After the process of step S106, the friend device 51 transmits to the management server 70 a storage completion notification M65 indicating that the storage of the authority information ATP7 in accordance with the storage request D66 has been completed.

[0156] When the non-friend device 52 receives the non-friend key information DKN after the range change and the storage request D67, the non-friend device 52 performs the process of step S107. In step S107, the non-friend device 52 stores the non-friend key information DKN after the range change. That is, the management server 70 stores the authority information ATP7 in the non-friend key information DKN after the range change in the non-friend device 52, which is a shared device.

[0157] Thereafter, the non-friend device 52 performs the process of step S108. In step S108, the non-friend device 52 presents information indicating that the change of the authority information ATP7 has been completed to the device HMI_32. For example, the non-friend device 52 displays an image indicating that the change of the authority information ATP7 has been completed on the device HMI_32. After the process of step S108, the non-friend device 52 transmits to the management server 70 a storage completion notification M66 indicating that the storage of the authority information ATP7 in accordance with the storage request D67 has been completed.

[0158] <Processing After Vehicle 20 Receives Authentication Package ATP> When the vehicle 20 receives the authentication package ATP included in the friend key information DKF after the range change, the authentication package ATP included in the non-friend key information DKN after the range change, and the storage request D68, the vehicle 20 performs the process of step S109. In step S109, the vehicle 20 stores the authentication package ATP included in the friend key information DKF after the range change and the authentication package ATP included in the non-friend key information DKN after the range change. That is, the management server 70 stores the authority information ATP7 in the friend key information DKF after the range change and the authority information ATP7 in the non-friend key information DKN after the range change in the vehicle 20. As a result, the request to change the authority information ATP7 of the friend key KF made in the owner device 40 is reflected in the vehicle 20.

[0159] <Processing after the management server 70 receives the storage completion notification M65 and the storage completion notification M66> After receiving the storage completion notification M65 and the storage completion notification M66, the management server 70 performs the process of step S110. In the process of step S110, the management server 70 generates a completion notification M67 indicating that the change of the authority information ATP7 of the friend device 51, which is the key to be changed according to the change request D61, and the authority information ATP7 of the non-friend device 52 has been completed. The management server 70 transmits the completion notification M67 to the owner device 40.

[0160] When the owner device 40 receives the completion notification M67, the owner device 40 performs processing in step S111. In step S111, the owner device 40 presents to the device HMI_32 information indicating that the change to the authority information ATP7 of the first digital key, which is the friend key KF, has been completed, and information indicating that the change to the authority information ATP7 of the second digital key, which is the non-friend key KN, has been completed. Here, the friend key KF is the key to be changed in accordance with the change request D61. For example, the owner device 40 displays on the device HMI_32 an image indicating that the change to the authority information ATP7 of the first digital key, which is the friend key KF, has been completed, and that the change to the authority information ATP7 of the second digital key, which is the non-friend key KN, has been completed. Here, the friend key KF is the key to be changed in accordance with the change request D61. Thereafter, the management system 10 terminates the series of processes for changing the authority information ATP7 of the current first digital key, which is the friend key KF.

[0161] <Operation of the first embodiment> When the range of executable vehicle functions of the friend device 51 to which the first digital key (friend key KF) is registered is changed, the management server 70 changes the range of executable vehicle functions of the non-friend device 52 to which the second digital key (non-friend key KN) is registered.

[0162] <Effects of the first embodiment> (1-1) When the range of functions that can be performed by the first digital key (friend key KF) is changed, the management server 70 is able to change the range of functions that can be performed by the second digital key (non-friend key KN) that has already been generated based on the first digital key (friend key KF) in accordance with the range of functions that can be performed by the first digital key (friend key KF) after the change.

[0163] (1-2) When the range of executable vehicle functions of a friend device 51 to which a first digital key (friend key KF) is registered is changed, the management server 70 sets the range of executable functions of the non-friend device 52 to be narrower than the changed range of executable functions of the friend device 51. The non-friend device 52 had already registered a second digital key (non-friend key KN) based on the registration request D31 executed by the friend device 51 before the range of executable vehicle functions of the friend device 51 was changed. Therefore, the range of executable vehicle functions of the second digital key (non-friend key KN) registered by the friend device 51 is narrower than the range of executable vehicle functions of the first digital key (friend key KF) registered to the friend device 52. This allows the management server 70 to narrow the range of executable functions of the non-friend device 52 to which a second digital key (non-friend key KN) is registered to be narrower than the range of executable functions of the friend device 51 to which the first digital key (friend key KF) is registered.

[0164] (1-3) When a request is made to change the range of executable vehicle functions for the friend device 51 to which the first digital key (friend key KF) is registered, if the preset condition RC is met, the management server 70 sets the range of executable vehicle functions for the non-friend device 52 to which the second digital key (non-friend key KN) is registered, based on the changed range of vehicle functions for the friend device 51. On the other hand, if the preset condition RC is not met, the management server 70 does not change the range of executable vehicle functions for the non-friend device 52 to which the second digital key (non-friend key KN) is registered. In other words, when the range of executable functions for the first digital key (friend key KF) is changed, if the preset condition RC is met, the management server 70 sets the range of executable functions for the second digital key (non-friend key KN) based on the changed range of executable functions for the first digital key (friend key KF). On the other hand, if the preset condition RC is not met, the management server 70 does not change the range of executable functions for the second digital key (non-friend key KN). This enables the management server 70 to reduce the risk of inconvenience when a user of a non-friend device 52 to which a second digital key (non-friend key KN) has been registered operates the vehicle 20.

[0165] (1-4) As shown in FIG. 6 , the first digital key (friend key KF) is a digital key generated based on the third digital key, which is the owner key KO. The third digital key is registered in the owner device 40. As shown in FIGS. 10 to 12 , when the range of functions available for the first digital key (friend key KF) is changed, the management server 70 sets the range of functions available for the second digital key (non-friend key KN) to be narrower than the changed range of vehicle functions available for the first digital key (friend key KF). In other words, when the range of functions available for the first digital key (friend key KF) is changed, the management server 70 sets the range of functions available for the second digital key (non-friend key KN) so that it does not exceed the range of functions available for the first digital key (friend key KF). As a result, the range of executable vehicle functions of the second digital key (non-friend key KN) for which the registration request D21 has not been made by the owner device 40 is narrower than the range of executable vehicle functions of the first digital key (friend key KF) for which the registration request D21 has been made by the owner device 40. Therefore, the owner of the vehicle 20 can feel secure even when the user of the non-friend device 52 to which the second digital key (non-friend key KN) has been registered operates the vehicle 20.

[0166] (1-5) The management server 70 includes a server communication module 73, which is a communication device. The management server 70 includes a server execution device 71, which is a server processing circuit. The setting method executed by the management server 70 includes receiving, via the server communication module 73, a request to change the executable function range of the friend key KF, which is a first digital key (step S92). The setting method further includes, when the executable function range of the first digital key (friend key KF) is changed, setting, via the server execution device 71, the executable function range of the second digital key (non-friend key KN) in accordance with the changed executable function range of the first digital key (friend key KF) (steps S94, S100, and S103). By executing this setting method, when the executable function range of the first digital key (friend key KF) is changed, the management server 70 is able to change the executable function range of the second digital key (non-friend key KN) in accordance with the changed executable function range of the first digital key (friend key KF). The second digital key (non-friend key KN) was generated based on the first digital key (friend key KF).

[0167] (1-6) The server storage device 72 of the management server 70 stores a change program PM that causes the server execution device 71 to execute processing. When the range of functions that can be performed by the first digital key (friend key KF) is changed, the change program PM causes the server execution device 71 to execute processing that sets the range of functions that can be performed by the second digital key (non-friend key KN) in accordance with the changed range of functions that can be performed by the first digital key (friend key KF). This enables the management server 70 to change the range of functions that can be performed by the second digital key (non-friend key KN) in accordance with the changed range of functions that can be performed by the first digital key (friend key KF) in accordance with the changed range of functions that can be performed by the first digital key (friend key KF). The second digital key (non-friend key KN) is generated based on the first digital key (friend key KF).

[0168] <Modifications of 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.

[0169] The range of vehicle functions that can be performed by the non-friend device 52 that has stored the key information DK indicating the second digital key (non-friend key KN) may be configured to be changeable by the friend device 51 that made the registration request D31 for the second digital key (non-friend key KN). In this case, the friend device 51 may be configured to be able to change the range of vehicle functions that can be performed by the non-friend device 52 only within the range of vehicle functions that can be performed by the friend device 51.

[0170] The management server 70 may set the post-change range of vehicle functions that can be performed by the friend device 51 to be wider than the pre-change range of vehicle functions that can be performed by the friend device 51 .

[0171] The management server 70 may change the post-change range of vehicle functions that can be performed by the non-friend device 52 to be wider than the pre-change range of vehicle functions that can be performed by the non-friend device 52 .

[0172] The management server 70 may set the post-change range of vehicle functions that can be performed by the non-friend device 52 to be the same as the post-change range of vehicle functions that can be performed by the friend device 51 .

[0173] 14 to 16 explain the management server 70 according to the second embodiment. The second embodiment will be explained mainly with reference to the differences from the first embodiment. The management server 70 in the second embodiment changes the range of vehicle functions that can be performed by the digital key by changing the authority information ATP7 that indicates the range of vehicle functions that can be performed by the digital key.

[0174] 14 shows the flow of a series of processes executed by the management server 70 to change the authority information ATP7 in the friend key KF in response to a request from the owner device 40. Before executing this series of processes, the range of vehicle functions that the friend device 51 can perform includes (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. Before executing this series of processes, the range of vehicle functions that the non-friend device 52 can perform includes (b) power-on control of the vehicle 20, and (c) door unlocking and locking control of the vehicle 20. The owner device 40, friend device 51, non-friend device 52, and vehicle 20 are the same as in the first embodiment.

[0175] When a change request operation for the authority information ATP7 of the friend key KF is executed in the owner device 40, the owner device 40 first performs the process of step S91. In step S91, the owner device 40 generates a change request D61 for the authority information ATP7 of the friend key KF. The change request D61 requests a change to the authority information ATP7 of the friend key KF.

[0176] The change request D61 includes digital key identification information ST3 indicating the friend key KF and a change request signal for the authority information ATP7 of the friend key KF. The change request signal for the authority information ATP7 of the friend key KF indicates the following vehicle functions that the friend device 51 can perform: (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20.

[0177] When the management server 70 receives the change request D61, it performs the process of step S300. In step S300, the management server 70 generates a change-in-progress notification M300 indicating that a change will be made in accordance with the change request D61. The management server 70 transmits the change-in-progress notification M300 to the owner device 40.

[0178] Thereafter, when the owner device 40 receives the change-in-progress notification M300, the owner device 40 performs the process of step S301. In step S301, the owner device 40 presents, to the device HMI_32, information indicating that the authority information ATP7 of the friend key KF, which is the key to be changed according to the change request D61, is being changed.

[0179] After processing in step S300, management server 70 performs processing in step S201. In step S201, management server 70 generates a change request D71 requesting a change to authority information ATP7 in friend key information DKF, and a change request D72 requesting a change to authority information ATP7 in non-friend key information DKN.

[0180] The change request D71 includes a change request signal for the authority information ATP7 of the friend key KF. Similar to the change request D61, the change request signal for the authority information ATP7 of the friend key KF indicates the following vehicle functions that the friend device 51 can perform: (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20.

[0181] When the management server 70 receives a request to change the executable function range of the friend device 51 , it sets the executable function range of the non-friend device 52 to be narrower than the changed executable function range of the friend device 51 .

[0182] The change request signal for the authority information ATP7 of the friend key KF included in the change request D61 indicates that the vehicle functions that the friend device 51 can perform are (b) power-on control of the vehicle 20 and (c) unlocking and locking control of the doors of the vehicle 20. Therefore, the management server 70 generates a change request D72. The change request D72 includes a change request signal for the authority information ATP7 of the non-friend key KN. The change request signal for the authority information ATP7 of the non-friend key KN indicates that the vehicle functions that the non-friend device 52 can perform are (c) unlocking and locking control of the doors of the vehicle 20.

[0183] The management server 70 transmits a change request D71 to the friend device 51. The management server 70 transmits a change request D72 to the non-friend device 52. <Changing the authority information ATP7 in the device 30> When the friend device 51 receives the change request D71, it performs the process of step S202. In step S202, the friend device 51 presents information indicating that the authority information ATP7 is being changed to the device HMI_32. After the process of step S202, the friend device 51 performs the process of step S203. In step S203, the friend device 51 changes the authority information ATP7 in the friend key information DKF in accordance with the change request D71. The friend device 51 transmits a change completion notification M71 to the management server 70, indicating that the change in accordance with the change request D71 has been completed.

[0184] When the non-friend device 52 receives the change request D72, it performs processing in step S204. In step S204, the non-friend device 52 presents information indicating that the authority information ATP7 is being changed to the device HMI_32. After processing in step S204, the non-friend device 52 performs processing in step S205. In step S205, the non-friend device 52 changes the authority information ATP7 in the non-friend key information DKN in accordance with the change request D72. The non-friend device 52 transmits a change completion notification M72 to the management server 70 indicating that the change in accordance with the change request D72 has been completed. Processing then proceeds to FIG. 15 .

[0185] When the management server 70 receives the change completion notification M71 and the change completion notification M72, the management server 70 performs the process of step S206 shown in Fig. 15. In step S206, the management server 70 stores the change history of the changes made to the friend key information DKF in the friend device 51 and the non-friend key information DKN in the non-friend device 52. The management server 70 then proceeds to step S207.

[0186] In step S207, the management server 70 generates a change request D73 for the authority information ATP7 in the authentication information AT of the friend key KF and a change request D74 for the authority information ATP7 in the authentication information AT of the non-friend key KN. The management server 70 transmits the change request D73 and the change request D74 to the vehicle 20.

[0187] <Changing the authority information ATP7 in vehicle 20> When vehicle 20 receives change request D73 and change request D74, vehicle 20 performs the process of step S208. In step S208, vehicle 20 changes the authority information ATP7 in the authentication information AT of friend key KF, which is the key to be changed by change request D73, in accordance with change request D73. Vehicle 20 changes the authority information ATP7 in the authentication information AT of non-friend key KN, which is the key to be changed by change request D74, in accordance with change request D74. Thereafter, vehicle 20 transmits a change completion notification M73 to management server 70, indicating that the change of the authority information ATP7 in the authentication information AT of friend key KF and the authority information ATP7 in the authentication information AT of non-friend key KN has been completed.

[0188] When management server 70 receives change completion notification M73, management server 70 performs processing in step S209. In step S209, management server 70 stores a change history of changes made to authority information ATP7 in authentication information AT of friend key KF and authority information ATP7 in authentication information AT of non-friend key KN in vehicle 20. After processing in step S209, management server 70 proceeds to step S210 shown in FIG.

[0189] In step S210, the management server 70 updates the database DB. Specifically, the management server 70 changes the authority information ATP7 of the friend key KF, which is the key to be changed in this series of processes, and the authority information ATP7 of the non-friend key KN in the database DB for the vehicle 20. Thereafter, the management server 70 proceeds to step S211.

[0190] In step S211, the management server 70 generates a change completion notification M74 indicating that the change of the authority information ATP7 in the friend device 51, which is the key to be changed according to the change request D61, and the authority information ATP7 in the non-friend device 52 has been completed. Note that the target of the change request D61 was the authority information ATP7 in the friend device 51. The management server 70 generates a change completion notification M75 indicating that the change of the authority information ATP7 in the friend device 51 has been completed. The management server 70 generates a change completion notification M76 indicating that the change of the authority information ATP7 in the non-friend device 52 has been completed. The management server 70 transmits the change completion notification M74 to the owner device 40. The management server 70 transmits the change completion notification M75 to the friend device 51. The management server 70 transmits the change completion notification M76 to the non-friend device 52.

[0191] When the owner device 40 receives the change completion notification M74, the owner device 40 performs the process of step S212. In step S212, the owner device 40 presents to the device HMI_32 information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed in accordance with the change request D61, has been completed, and information indicating that the change of the authority information ATP7 of the non-friend key KN has been completed.

[0192] When the friend device 51 receives the change completion notification M75, the friend device 51 performs the process of step S213. In step S213, the friend device 51 presents, to the device HMI_32, information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed in accordance with the change request D61, has been completed.

[0193] When the non-friend device 52 receives the change completion notification M76, the non-friend device 52 performs the process of step S214. In step S214, the non-friend device 52 presents information indicating that the change of the authority information ATP7 of the non-friend key KN has been completed to the device HMI_32. Thereafter, the management system 10 ends the series of processes for the current change of the authority information ATP7 of the friend key KF.

[0194] <Function of the second embodiment> When the authority information ATP7 of the first digital key (friend key KF) registered in the friend device 51 is changed, the management server 70 changes the authority information ATP7 of the second digital key (non-friend key KN) registered in the non-friend device 52.

[0195] <Effects of the Second Embodiment> (2-1) When the range of functions that can be performed by the first digital key (friend key KF) is changed by changing the authority information ATP7 of the first digital key (friend key KF), the management server 70 performs the following process. In other words, the management server 70 is able to change the range of functions that can be performed by the second digital key (non-friend key KN) in accordance with the range of functions that can be performed by the first digital key (friend key KF) after the change. The second digital key (non-friend key KN) is generated based on the first digital key (friend key KF).

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

[0197] <Processing in the Case Where Only the Vehicle 20 Has Stored the Authority Information ATP7> The authority information ATP7 may be stored only by the vehicle 20. Figure 17 shows the flow of a series of processes that the management server 70 executes to change the authority information ATP7 in the friend key KF in response to a request from the owner device 40 in the case where only the vehicle 20 has stored the authority information ATP7. Before executing this series of processes, the range of vehicle functions that the friend device 51 can execute includes (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. Before executing this series of processes, the range of vehicle functions that the non-friend device 52 can execute includes (b) power-on control of the vehicle 20, and (c) door unlocking and locking control of the vehicle 20.

[0198] When a change request operation for the authority information ATP7 of the friend key KF is executed in the owner device 40, the owner device 40 first performs the process of step S91. In step S91, the owner device 40 generates a change request D61 for the authority information ATP7 of the friend key KF. The change request D61 requests a change to the authority information ATP7 in the authentication information AT of the friend key KF.

[0199] The change request D61 includes a change request signal for the authority information ATP7 of the friend key KF. The change request signal for the authority information ATP7 of the friend key KF indicates the following vehicle functions that the friend device 51 can perform: (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20.

[0200] When the management server 70 receives the change request D61, it performs the process of step S300. The process of step S300 is the same as in the second embodiment. After the process of step S300, when the owner device 40 receives the change notification M300, the owner device 40 performs the process of step S301. The process of step S301 is the same as in the second embodiment.

[0201] After processing step S300, the management server 70 performs processing step S207. In step S207, the management server 70 generates a change request D73 requesting a change to the authority information ATP7 of the friend key KF in the vehicle 20, and a change request D74 requesting a change to the authority information ATP7 of the non-friend key KN in the vehicle 20.

[0202] The change request D73 includes digital key identification information ST3 indicating the friend key KF and a change request signal for the authority information ATP7 in the authentication information AT of the friend key KF. Similar to the change request D61, the change request signal for the authority information ATP7 of the friend key KF indicates (b) power-on control of the vehicle 20 and (c) door unlocking and locking control of the vehicle 20 as vehicle functions that the friend device 51 can perform. The change request D74 includes a change request signal for the authority information ATP7 in the authentication information AT of the non-friend key KN. The change request signal for the authority information ATP7 of the non-friend key KN indicates (c) door unlocking and locking control of the vehicle 20 as vehicle functions that the non-friend device 52 can perform. The management server 70 transmits the change request D73 and the change request D74 to the vehicle 20.

[0203] <Changing the authority information ATP7 in vehicle 20> When vehicle 20 receives change request D73 and change request D74, vehicle 20 performs processing in step S208. In step S208, vehicle 20 changes the authority information ATP7 of friend key KF, which is the key to be changed by change request D73, in accordance with change request D73. Vehicle 20 changes the authority information ATP7 in the authentication information AT of non-friend key KN, which is the key to be changed by change request D74, in accordance with change request D74. Thereafter, vehicle 20 transmits a change completion notification M73 to management server 70, indicating that the change of the authority information ATP7 of friend key KF and the authority information ATP7 of non-friend key KN has been completed.

[0204] <Processing After Management Server 70 Receives Change Completion Notification M73> When the management server 70 receives the change completion notification M73, the management server 70 performs processing in step S209. In step S209, the management server 70 stores the change history of the changes made to the authority information ATP7 in the authentication information AT of the friend key KF and the authority information ATP7 in the authentication information AT of the non-friend key KN in the vehicle 20. Thereafter, the management server 70 proceeds to step S210 shown in FIG. 18 .

[0205] In step S210, the management server 70 updates the database DB. Specifically, the management server 70 changes the authority information ATP7 of the friend key KF and the authority information ATP7 of the non-friend key KN in the database DB for the vehicle 20. Here, the friend key KF is the key to be changed in this series of processes. Thereafter, the management server 70 proceeds to step S211.

[0206] In step S211, the management server 70 generates a change completion notification M74 indicating that the change of the authority information ATP7 in the friend device 51, which is the key to be changed in accordance with the change request D61, and the authority information ATP7 in the non-friend device 52 has been completed. The management server 70 generates a change completion notification M75 indicating that the change of the authority information ATP7 in the friend device 51 has been completed. The management server 70 generates a change completion notification M76 indicating that the change of the authority information ATP7 in the non-friend device 52 has been completed. The management server 70 transmits the change completion notification M74 to the owner device 40. The management server 70 transmits the change completion notification M75 to the friend device 51. The management server 70 transmits the change completion notification M76 to the non-friend device 52.

[0207] When the owner device 40 receives the change completion notification M74, the owner device 40 performs the process of step S212. In step S212, the owner device 40 presents to the device HMI_32 information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed in accordance with the change request D61, has been completed, and information indicating that the change of the authority information ATP7 of the non-friend key KN has been completed.

[0208] When the friend device 51 receives the change completion notification M75, the friend device 51 performs the process of step S213. In step S213, the friend device 51 presents, to the device HMI_32, information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed in accordance with the change request D61, has been completed.

[0209] When the non-friend device 52 receives the change completion notification M76, the non-friend device 52 performs the process of step S214. In step S214, the non-friend device 52 presents information indicating that the change of the authority information ATP7 of the non-friend key KN has been completed to the device HMI_32. Thereafter, the management system 10 ends the series of processes for the change of the authority information ATP7 of this friend key KF.

[0210] The management system 10 includes a vehicle 20 that stores information about digital keys, and a management server 70 that manages multiple digital keys that can be used for the vehicle 20. When the range of executable functions of the first digital key (friend key KF) stored in the vehicle 20 is changed, the management system 10 sets the range of executable functions of the second digital key (non-friend key KN) in accordance with the changed range of executable functions of the first digital key (friend key KF). When the range of executable functions of the first digital key (friend key KF) is changed by changing the authority information ATP7 of the first digital key (friend key KF) stored in the vehicle 20, the management system 10 is capable of changing the range of executable functions of the second digital key (non-friend key KN) generated based on the first digital key (friend key KF) in accordance with the changed range of executable functions of the first digital key (friend key KF).

[0211] 19 to 22 explain the management server 70 according to the third embodiment. The third embodiment will be explained mainly with reference to the differences from the second embodiment. When the management server 70 according to the third embodiment has received a request to change the executable function range of the first digital key (friend key KF), the management server 70 sets the post-change executable function range of the second digital key (non-friend key KN) generated based on the first digital key (friend key KF) to be narrower than the post-change executable function range of the first digital key (friend key KF).

[0212] 19 shows the flow of a series of processes executed by the management server 70 to change the authority information ATP7 in the friend key KF in response to a request from the owner device 40. Before executing this series of processes, the range of vehicle functions executable by the friend key KF includes (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. Before executing this series of processes, the range of vehicle functions executable by the non-friend device 52 includes (b) power-on control of the vehicle 20, and (c) door unlocking and locking control of the vehicle 20. The owner device 40 and the vehicle 20 are the same as in the second embodiment. The friend device 51 is the second device 30B in which friend key information DKF has been stored. The third device 30C and the fourth device 30D are devices 30 that do not store non-friend key information DKN and are newly registered as non-friend devices 52 in this series of processes.

[0213] <Registering the Non-Friend Key KN in the Third Device 30C> When an operation requesting registration of the non-friend key KN in the third device 30C is executed in the friend device 51, the friend device 51 first performs the process of step S41. Step S41 is the same as step S41 shown in FIG. 7 . In this series of processes, the friend device 51 performs the processes of steps S41, S42, S45, and S46 shown in FIG. 7 . In this series of processes, the third device 30C performs the processes of steps S43, S44, S47, S48, and S51. In this series of processes, the management server 70 performs the process of step S49. In this series of processes, the vehicle 20 performs the process of step S50. In FIG. 19 , steps S42 to S46 shown in FIG. 7 are omitted from illustration. Through these processes, the third device 30C is newly registered as a non-friend device 52.

[0214] 19 is completed, the range of vehicle functions that can be performed by the second device 30B, which is the friend device 51, includes (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. When the processing of step S51 shown in FIG. 19 is completed, the range of vehicle functions that can be performed by the third device 30C, which is the non-friend device 52, includes (b) power-on control of the vehicle 20 and (c) door unlocking control and door locking control of the vehicle 20.

[0215] <Execution of a change request operation on the authority information ATP7 of the friend key KF> In the third embodiment, similarly to the second embodiment, when a change request operation on the authority information ATP7 of the friend key KF is executed in the owner device 40, the owner device 40 performs the process of step S91 shown in Fig. 19. In step S91, the owner device 40 generates a change request D61 for the authority information ATP7 of the friend key KF. The change request D61 requests a change to the authority information ATP7 of the friend key KF.

[0216] The change request D61 includes digital key identification information ST3 indicating the friend key KF and a change request signal for the authority information ATP7 of the friend key KF. The signal for requesting the authority information ATP7 of the friend key KF indicates the following vehicle functions that the friend device 51 can perform: (b) power-on control of the vehicle 20, and (c) door unlocking and locking control of the vehicle 20. In other words, (a) engine start control of the vehicle 20 has been reduced. The series of processes continues in FIG. 20.

[0217] <Processing Performed by Management Server 70 After Receiving Change Request D61> When the management server 70 receives the change request D61, it performs the process of step S300 shown in FIG. 20. The process of step S300 is the same as in the second embodiment. After the process of step S300, when the owner device 40 receives a change-in-progress notification M300, the owner device 40 performs the process of step S301. The process of step S301 is the same as in the second embodiment.

[0218] 20, after the process of step S300, the management server 70 performs the process of step S401. In step S401, the management server 70 generates a change request D81.

[0219] The change request D81 includes a change request signal for the authority information ATP7 of the friend key KF. The change request signal for the authority information ATP7 of the friend key KF indicates the following vehicle functions that the friend device 51 can perform: (b) power-on control of the vehicle 20, and (c) door unlocking control and door locking control of the vehicle 20.

[0220] The change request D81 includes a signal for setting the range of executable functions of the device 30 to which the non-friend key KN is registered based on the registration request D31 executed by the friend device 51 that has received the change request D81 to be narrower than the range of executable functions of the friend device 51.

[0221] The change request D61 includes a change request signal for the authority information ATP7 of the friend key KF. This change request signal indicates that the friend device 51's post-change executable function range is (b) power-on control for the vehicle 20 and (c) door unlocking and locking control for the vehicle 20. The management server 70 generates a narrow setting signal for setting the executable function range of the next device 30 to a narrower range than the executable function range of the friend device 51 that has received the change request D81. In other words, the device 30 that has been registered with the non-friend key KN based on the registration request from the friend device 51 that has received the change request D81 has the narrower executable function range.

[0222] The narrow setting signal indicates that the range of vehicle functions that can be performed by the device 30 to which the non-friend key KN has been registered based on the registration request from the friend device 51 is (c) locking and unlocking control of the doors of the vehicle 20. The management server 70 transmits a change request D81 to the friend device 51.

[0223] <Processing Performed by the Friend Device 51 After Receiving the Change Request D81> As shown in FIG. 20 , when the friend device 51 receives the change request D81, it performs the process of step S202. The process of step S202 is the same as in the second embodiment. After the process of step S202, the friend device 51 performs the process of step S500. In step S500, the friend device 51 changes the authority information ATP7 in the friend key information DKF in accordance with the change request D81. As a result, the vehicle functions that the friend device 51 can perform become (b) power-on control of the vehicle 20 and (c) lock and unlock control of the doors of the vehicle 20. In accordance with the change request D81, the friend device 51 changes the range of vehicle functions that the friend device 51 can perform for the device 30 to which the non-friend key KN has been registered based on the registration request D31 executed by the friend device 51 to (c) lock and unlock control of the doors of the vehicle 20.

[0224] When the processing of step S500 is completed, the friend device 51 transmits a completion notification M81 to the management server 70. <Processing Performed by the Management Server 70 After Receiving the Completion Notification M81> When the management server 70 receives the completion notification M81, the management server 70 performs the processing of step S402. In step S402, the management server 70 stores a change history indicating that the friend key information DKF in the friend device 51 has been changed. Thereafter, the management server 70 proceeds to the processing of step S403.

[0225] In step S403, the management server 70 generates a change request D82 for the authority information ATP7 in the authentication information AT of the friend key KF. The management server 70 transmits the change request D82 to the vehicle 20. The series of processes continues in FIG. 21.

[0226] 21 , when the vehicle 20 receives the change request D82, the vehicle 20 performs the process of step S404. In step S404, the vehicle 20 changes the authority information ATP7 in the authentication information AT of the friend key KF, which is the key to be changed by the change request D82, in accordance with the change request D82. Thereafter, the vehicle 20 transmits a change completion notification M82 to the management server 70, indicating that the change of the authority information ATP7 in the authentication information AT of the friend key KF has been completed.

[0227] 21 , when the management server 70 receives the change completion notification M82, the management server 70 performs the process of step S405. In step S405, the management server 70 stores the change history that the authority information ATP7 in the authentication information AT of the friend key KF in the vehicle 20 has been changed. Thereafter, the management server 70 proceeds to step S406.

[0228] In step S406, the management server 70 updates the database DB. Specifically, the management server 70 changes the authority information ATP7 in the authentication information AT of the friend key KF for the vehicle 20 that is the target of the change in this series of processes, in the data block DA of the vehicle 20 in the database DB. Thereafter, the management server 70 proceeds to step S407.

[0229] In step S407, the management server 70 generates a change completion notification M83 indicating that the change of the authority information ATP7 in the friend device 51, which is the key to be changed in accordance with the change request D61, has been completed. The management server 70 generates a change completion notification M84 indicating that the change of the authority information ATP7 in the friend device 51 has been completed. The management server 70 transmits the change completion notification M83 to the owner device 40. The management server 70 transmits the change completion notification M84 to the friend device 51.

[0230] <Processing after the management server 70 transmits the change completion notification M83 and the change completion notification M84> When the owner device 40 receives the change completion notification M83, the owner device 40 performs the process of step S408. In step S408, the owner device 40 presents, to the device HMI_32, information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed in accordance with the change request D61, has been completed.

[0231] When the friend device 51 receives the change completion notification M84, the friend device 51 performs the process of step S409. In step S409, the friend device 51 presents to the device HMI_32 information indicating that the change of the authority information ATP7 of the friend key KF, which is the key to be changed according to the change request D61, has been completed. The series of processes is continued in FIG. 22.

[0232] <Registering the Non-Friend Key KN for the Fourth Device 30D> As shown in FIG. 22 , when an operation is executed in the friend device 51 after the change of the authority information ATP7 of the friend key KF has been completed to request registration of the non-friend key KN for the fourth device 30D, the friend device 51 performs processing in step S41 for the fourth device 30D. Step S41 is similar to step S41 shown in FIG. 7 . In this series of processing, the friend device 51 performs processing in steps S41, S42, S45, and S46 shown in FIG. 7 . However, steps S42 to S46 are not illustrated in FIG. 22 . In this series of processing, the fourth device 30D performs processing in steps S43, S44, S47, S48, and S51, similar to the third device 30C shown in FIG. 7 . Step S47 shown in FIG. 22 is similar to step S47 shown in FIG. 7 . Step S48 shown in Figure 22 is similar to step S48 shown in Figure 7. Step S51 shown in Figure 22 is similar to step S51 shown in Figure 7. In this series of processes, the management server 70 performs the process of step S49. Step S49 shown in Figure 22 is similar to step S49 shown in Figure 7. In this series of processes, the vehicle 20 performs the process of step S50. Step S50 shown in Figure 22 is similar to step S50 shown in Figure 7. As a result, the fourth device 30D becomes a non-friend device 52.

[0233] <Range of vehicle functions that can be performed by the fourth device 30D> The authority information ATP7 in the non-friend key information DKN stored in the fourth device 30D indicates (c) unlocking control and locking control of the doors of the vehicle 20 as the range of vehicle functions that can be performed by the fourth device 30D.

[0234] 22 is completed, the range of vehicle functions that the friend device 51 can perform includes (b) power-on control of the vehicle 20 and (c) lock and unlock control of the doors of the vehicle 20. When the process of step S51 shown in Fig. 22 is completed, the range of vehicle functions that the third device 30C, which is a non-friend device 52, can perform includes (b) power-on control of the vehicle 20 and (c) lock and unlock control of the doors of the vehicle 20. When the process of step S51 shown in Fig. 22 is completed, the range of vehicle functions that the fourth device 30D, which is a non-friend device 52, can perform includes only (c) lock and unlock control of the doors of the vehicle 20.

[0235] <Operation of the third embodiment> The management server 70 sets the range of functions that can be performed by the second digital key (non-friend key KN) generated based on the first digital key (friend key KF) to be narrower than the range of functions that can be performed by the first digital key (friend key KF).

[0236] <Effects of the third embodiment> (3-1) The management server 70 is able to set the range of vehicle functions that can be performed by the second digital key (non-friend key KN) to be narrower than the range of functions that can be performed by the first digital key (friend key KF) before the second digital key (non-friend key KN) is registered to the device 30.

[0237] <Other Modifications> Other common modifiable elements of the above embodiments include the following: The following modifications can be implemented in combination with each other as long as they are not technically inconsistent.

[0238] When the range of executable vehicle functions of the friend device 51 is changed, the series of processes for changing the range of executable vehicle functions of the non-friend device 52 is not limited to the examples in the above embodiments. For example, the management server 70 may update the database DB after step S110, which is the process of generating the completion notification M67 in FIG. 13 . The series of processes for changing the range of executable vehicle functions of the device 30 may be modified as appropriate to match the structure of the information included in the authority information ATP7.

[0239] The range of vehicle 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 have a function that permits only the unlocking control and the locking control of the trunk box in the vehicle 20.

[0240] The management server 70 may set the range of vehicle functions that the friend device 51 can implement using the friend key KF for each device 30. The second device 30B and the third device 30C shown in FIG. 4 are friend devices 51. The management server 70 may set the range of vehicle functions that the second device 30B can implement using the friend key KF and the range of vehicle functions that the third device 30C can implement using the friend key KF to be different ranges.

[0241] 23 is a schematic diagram showing another device 30 that made a request that caused the registration of a digital key when the digital key was registered in the device 30. The relationship between the second device 30B and the first device 30A is such that the friend key KF has been registered in the second device 30B based on the registration request from the first device 30A. The relationship between the fifth device 30E and the first device 30A is such that the friend key KF has been registered in the fifth device 30E based on the registration request from the first device 30A.

[0242] The relationship between the third device 30C and the second device 30B is such that the non-friend key KN has been registered in the third device 30C based on a registration request from the second device 30B. The relationship between the fourth device 30D and the second device 30B is such that the non-friend key KN has been registered in the fourth device 30D based on a registration request from the second device 30B. The relationship between the sixth device 30F and the fifth device 30E is such that the non-friend key KN has been registered in the sixth device 30F based on a registration request from the fifth device 30E. The relationship between the seventh device 30G and the fifth device 30E is such that the non-friend key KN has been registered in the seventh device 30G based on a registration request from the fifth device 30E. The relationship between the eighth device 30H and the third device 30C is such that the non-friend key KN has been registered in the eighth device 30H based on a registration request from the third device 30C.

[0243] That is, the non-friend device 52 may be able to transmit a request to register a new non-friend key KN. That is, regardless of whether the sharing device 50 that issues or receives the registration request is the friend device 51 or the non-friend device 52, the sharing device 50 may transmit a request to register a new non-friend key KN to another sharing device 50. In this case, the management system 10 may register the new non-friend key KN by the series of processes shown in FIG. 7.

[0244] When the range of executable vehicle functions of one friend device 51 is changed among the multiple friend devices 51, the management server 70 may change the range of executable vehicle functions of all non-friend devices 52. For example, when the management server 70 changes the range of executable functions of the second device 30B, it changes the range of executable functions of the third device 30C, the fourth device 30D, the sixth device 30F, the seventh device 30G, and the eighth device 30H.

[0245] When the range of executable functions of a friend device 51 is changed, the management server 70 may change the range of executable functions of a non-friend device 52 that has registered the non-friend key KN based on a registration request from the friend device 51. For example, when the management server 70 changes the range of executable vehicle functions of the second device 30B, which is the friend device 51, the management server 70 changes the range of vehicle functions that can be executed by each of the third device 30C and the fourth device 30D.

[0246] When the range of executable functions of a non-friend device 52 is changed, the management server 70 may change the range of executable functions of the non-friend device 52 to which the non-friend key KN has been registered based on a registration request from the non-friend device 52. For example, if the management server 70 changes the range of executable vehicle functions of the third device 30C, which is a non-friend device 52, the management server 70 changes the range of executable vehicle functions of the eighth device 30H. In this case, the second device 30B that has stored friend key information DKF indicating the friend key KF is a device 30 to which the third digital key has been registered. The third device 30C that has stored non-friend key information DKN indicating the non-friend key KN to be registered based on a registration request D31 from the second device 30B is a device 30 to which the first digital key (friend key KF) has been registered. The eighth device 30H, which has stored non-friend key information DKN indicating the non-friend key KN to be registered based on a registration request from the third device 30C, is a device 30 in which the second digital key (non-friend key KN) has been registered. When the range of functions that can be performed by the first digital key (friend key KF) is changed, the management server 70 is able to change the range of functions that can be performed by the second digital key (non-friend key KN) generated based on the first digital key (friend key KF) in accordance with the changed range of functions that can be performed by the first digital key (friend key KF).

[0247] When the range of executable vehicle functions of a friend device 51 is changed, the management server 70 may change the range of executable vehicle functions of a non-friend device 52 to which a non-friend key KN has been registered based on a registration request from the friend device 51. Furthermore, the management server 70 may also change the range of executable vehicle functions of another non-friend device 52 to which a different non-friend key KN has been registered based on a registration request from the non-friend device 52. For example, when the management server 70 changes the range of executable vehicle functions of the second device 30B, which is a friend device 51, it changes the range of executable vehicle functions of each of the third device 30C, the fourth device 30D, and the eighth device 30H. In other words, when the range of executable functions of a share key KS is changed, the management server 70 may set the range of executable functions of another share key KS registered by a request made by the share key KS according to the changed range. In other words, the second share key is registered by a registration request made by the first share key. When the range of functions that can be implemented by the first share key is changed, the server execution device 71 may be configured to set the range of functions that can be implemented by the second share key according to the range of functions that can be implemented by the first share key after the change.

[0248] <Modification of the management system 10> The authority information ATP7 may be stored only in the device 30. Fig. 24 shows the flow of a series of processes that the management server 70 executes to change the authority information ATP7 in the friend key KF in response to a request from the owner device 40 when the authority information ATP7 is stored only in the device 30. The management server 70 changes the range of functions of the device 30 that can be implemented by the digital key by changing the authority information ATP7 that indicates the range of functions of the device 30 that can be implemented by the digital key.

[0249] 24 , when an operation to request a change to the authority information ST9 in the owner key information DKO already stored in the owner device 40 is executed in the owner device 40, the owner device 40 first performs the process of step S500. In step S500, the owner device 40 changes the authority information ST9 in the owner key information DKO. For example, by changing the authority information ST9, the owner device 40 reduces the number of share keys KS that the owner device 40 can request to register. Thereafter, the owner device 40 performs the process of step S501. In step S501, the owner device 40 generates a change notification M400. The change notification M400 is a notification requesting the management server 70 to change the authority information ATP7 in the friend key information DKF already stored in the friend device 51. The notification requesting a change to the authority information ATP7 in the friend key information DKF includes information for increasing the number of share keys KS that the friend device 51 can request to register. Thereafter, the owner device 40 transmits a change notification M400 to the management server 70.

[0250] 24, upon receiving the change notification M400, the management server 70 performs processing in step S502. In step S502, the management server 70 generates a change request D400. The change request D400 includes a signal for increasing the number of share keys KS that the friend device 51 can request to register. The management server 70 transmits the change request D400 to the friend device 51.

[0251] When the friend device 51 receives the change request D400, it performs the process of step S503. In step S503, the friend device 51 presents information indicating that the authority information ATP7 is being changed to the device HMI_32. For example, the friend device 51 displays an image indicating that the authority information ATP7 is being changed on the device HMI_32. After the process of step S503, the friend device 51 performs the process of step S504.

[0252] 24, in step S504, the friend device 51 changes the authority information ATP7 of the friend key KF, which is the key to be changed according to the change request D400, in accordance with the change request D400. That is, the friend device 51 increases the number of share keys KS that the friend device 51 can request to register. Thereafter, the friend device 51 transmits a change completion notification M401 to the management server 70, indicating that the change of the authority information ATP7 of the friend key KF has been completed. Thereafter, the management system 10 ends this series of processes.

[0253] The management system 10 in Figure 24 above includes a plurality of devices 30, each of which stores information related to a digital key, and a management server 70 that manages the plurality of digital keys. The plurality of digital keys include an owner key KO, which is a first digital key, and a friend key KF, which is a second digital key generated based on the first digital key. The management system 10 is configured to be able to do the following when the permission information ATP7 in the owner key information DKO stored in the owner device 40 is changed, thereby changing the executable function range of the first digital key (owner key KO): That is, the executable function range of the second digital key (friend key KF) generated based on the first digital key (owner key KO) is set according to the changed executable function range of the first digital key (owner key KO).

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

[0255] The digital key-related aspects of the above embodiments do not necessarily comply with the CCC. The vehicle management device 26 may be configured as a circuit including one or more processors that execute various processes according to a computer program (software) or program product. The vehicle management device 26 may be configured as a circuit including one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs), or a combination thereof, that execute at least some of the various processes. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code, programs, program products, or instructions configured to cause the CPU to execute various processes. The memory, i.e., a non-transitory computer-readable storage medium, includes any available medium accessible by a general-purpose or dedicated computer. The same applies to the device 30 and the management server 70.

[0256] 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 collectively manages a plurality of ECUs included in the vehicle 20.

[0257] 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 owner of the vehicle 20, 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.

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

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

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

[0261] The share device 50 may have 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, may be called a receiver device.

[0262] <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. Also, for example, the authentication information AT may be a common secret key.

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

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

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

[0266] In the database DB, the authority information ATP7 does not have to be uniformly determined according to the type of digital key, but may be set for each digital key.Furthermore, the authority information ATP7 does not have to be determined in the database DB.

[0267] <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, even if pairing is not performed by the processing in step S12, 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. The processing for registering the owner key KO may be modified as appropriate to suit the information structure included in the owner key information DKO and the information structure included in the authentication information AT.

[0268] 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 to suit the structure of the information included in the friend key information DKF and the structure of the information included in the authentication information AT.

[0269] 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 modified as appropriate to fit the information structure contained in the non-friend key information DKN and the information structure contained in the authentication information AT.

[0270] 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. <Series of processes 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 friend device 51 may not necessarily request the deletion of the non-friend key KN; instead, the owner device 40 may request the deletion of the non-friend key KN, which causes the management server 70 to proceed with the processes from step S62 onwards.

[0271] The following describes a case where an operation requesting 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 shown in 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 shown in 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 a notification indicating that the non-friend key information DKN has been deleted from the non-friend device 52, the management server 70 proceeds with the processing from step S82 onwards shown in Fig. 9. However, the non-friend device 52 does not have 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. 9.

[0272] - A deletion reservation may be requested from the management server 70 in either the case where a non-friend key KN is deleted based on operation of the friend device 51 or the case where a non-friend key KN is deleted based on operation of the non-friend device 52.

[0273] 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 the deletion request for the non-friend key KN.

Claims

1. A server comprising a server processing circuit (71), the server processing circuit being configured to: manage a plurality of digital keys usable for a vehicle, the plurality of digital keys comprising a first digital key and a second digital key generated based on the first digital key; and, when the range of functions available for the first digital key is changed, set the range of functions available for the second digital key in accordance with the changed range of functions available for the first digital key.

2. The server according to claim 1, wherein the server processing circuit is configured to change the range of functions that can be performed by the second digital key by changing authority information that indicates the range of functions that can be performed by the second digital key.

3. The server of claim 2, wherein the server processing circuitry is configured to store the authorization information on the vehicle.

4. The server according to claim 2 or 3, wherein the server processing circuit is configured to store the authorization information indicating the range of functions that can be performed by the second digital key in a device that has information about the second digital key stored therein.

5. The server according to any one of claims 2 to 4, wherein the server processing circuitry is configured to store the authorization information indicating the range of functions that can be performed by the first digital key in a device that has information about the first digital key stored therein.

6. A server according to any one of claims 2 to 5, wherein the server processing circuitry is configured to store the authorization information.

7. A server according to any one of claims 1 to 6, wherein, when the range of functions that can be performed by the first digital key is changed, the server processing circuit is configured to set the range of functions that can be performed by the second digital key to be narrower than the range of functions that can be performed by the first digital key after the change.

8. The server according to claim 7, wherein, when the range of executable functions of the first digital key is changed, the server processing circuit is configured to set the range of executable functions of the second digital key after the change to be narrower than the range of executable functions of the second digital key before the change.

9. A server as claimed in any one of claims 1 to 8, wherein when the range of functions that can be performed by the first digital key is changed, the server processing circuit is configured to set the range of functions that can be performed by the second digital key in accordance with the changed range of functions that can be performed by the first digital key if a predetermined condition is met, but not to change the range of functions that can be performed by the second digital key if the predetermined condition is not met.

10. A server according to any one of claims 1 to 9, wherein the plurality of digital keys further comprises a third digital key, and the first digital key has been generated based on the third digital key.

11. A server as claimed in any one of claims 1 to 10, wherein the plurality of digital keys comprise a plurality of share keys that can be registered to the vehicle, the plurality of share keys comprising a first share key and a second share key that is registered in response to a registration request made by the first share key, and the server processing circuit is configured to, when the range of executable functions of the first share key is changed, set the range of executable functions of the second share key in accordance with the changed range of executable functions of the first share key.

12. A setting method comprising the steps of: managing a plurality of digital keys available for a vehicle by a server processing circuit of a server, the plurality of digital keys comprising a first digital key and a second digital key generated based on the first digital key; receiving, via a communication device of the server, information that the range of functions available for the first digital key has been changed; and, if the range of functions available for the first digital key has been changed, setting the range of functions available for the second digital key in accordance with the changed range of functions available for the first digital key.

13. A program stored in a server storage device to cause a server processing circuit to execute a setting process, the setting process comprising the steps of: 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 second digital key generated based on the first digital key; and, when the range of functions that can be performed by the first digital key is changed, setting the range of functions that can be performed by the second digital key in accordance with the changed range of functions that can be performed by the first digital key.

14. A system comprising: a vehicle having a vehicle processing circuit, the vehicle processing circuit having stored information about one or more digital keys, the digital keys including a first digital key and a second digital key generated based on the first digital key; and a server having a server processing circuit configured to manage a plurality of digital keys available for the vehicle, wherein at least one of the vehicle processing circuit or the server processing circuit is configured, when the range of executable functions of the first digital key is changed, to set the range of executable functions of the second digital key according to the changed range of executable functions of the first digital key.

15. A system comprising: a plurality of devices, each device having a device processing circuit and a device storage device, wherein the device storage device has stored information about one or more digital keys, the plurality of digital keys including a first digital key and a second digital key generated based on the first digital key; and a server having a server processing circuit configured to manage the plurality of digital keys, wherein at least one of the device processing circuit or the server processing circuit is configured to, when the range of executable functions of the first digital key is changed, set the range of executable functions of the second digital key according to the changed range of executable functions of the first digital key.

Images