Management server

Abstract

A management server (70) constitutes part of a management system (10). The management server (70) manages information on digital keys stored in a device (30). The management server (70) comprises an execution apparatus (71) and a communication apparatus (73). The device (30) comprises an owner device (40) belonging to an owner of a plurality of vehicles (20). The communication apparatus (73) communicates with the owner device (40) and the plurality of vehicles (20). Upon receiving a registration request (D21) for requesting initiation of a digital key registration process, the execution apparatus (71) identifies the owner device (40) and the plurality of vehicles (20), transmits information on a digital key for each of the plurality of vehicles (20) to the owner device (40) through the communication apparatus (73), and causes the management system (10) to start the process of generating the digital key for each of the plurality of vehicles (20) to be registered in the owner device (40).

Description

Management Server

[0001] The present disclosure relates to a management server.

[0002] Patent Document 1 discloses a digital key management system. The management system includes a plurality of vehicles, a plurality of devices, and a management server. The management system registers the vehicle's digital key to the device by storing information about the digital key in the vehicle and the device. The management server is capable of communicating with the device and the vehicle. The management server manages the registration of the digital key.

[0003] Patent Literature 1 discloses a management system that registers digital keys to multiple devices selected on an owner device. The owner device has registered therein an owner key, which is the only digital key registered to a vehicle.

[0004] JP 2024-001720 A

[0005] Based on a request from an owner who has newly acquired a vehicle, the management system stores information about the owner key in a device belonging to the owner and also stores information about the owner key in the vehicle acquired by the owner. When the owner key is authenticated by the vehicle using the information stored in the device and the information stored in the vehicle, the owner key is activated. When the owner key is activated, registration of the owner key is complete. For an owner who has acquired multiple vehicles, it is time-consuming to repeat the owner key registration process for each vehicle.

[0006] According to one aspect of the present disclosure, a management server forms part of a management system configured to manage digital keys for a plurality of vehicles. The management server is configured to manage information about the digital keys stored in devices. The management server includes an execution device and a communication device. The devices include owner devices belonging to owners of the plurality of vehicles. The communication device is configured to communicate with the owner devices and the plurality of vehicles.

[0007] The execution device is configured to, upon receiving a registration request requesting the start of the digital key registration process, identify the owner device and the multiple vehicles, send information about the digital keys of each of the multiple vehicles to the owner device using the communication device, and cause the management system to start the process of generating the digital keys for each of the multiple vehicles to be registered in the owner device.

[0008] FIG. 1 is a schematic diagram showing a digital key management system according to an embodiment. FIG. 2 is a schematic diagram showing the configuration of the management server of FIG. 1. FIG. 3 is a schematic diagram showing the configuration of an owner device built on the server of FIG. 1. FIG. 4 is a schematic diagram showing the configuration of a friend device of FIG. 1. FIG. 5 is a schematic diagram showing the configuration of a non-friend device of FIG. 1. FIG. 6 is a schematic diagram showing the configuration of a vehicle of FIG. 1. FIG. 7 is a schematic diagram showing owner key information. FIG. 8 is a schematic diagram showing data contained in the database of the management server of FIG. 2. FIG. 9 is a sequence diagram showing the processing performed by the management system of FIG. 1 when registering owner keys to multiple vehicles. FIG. 10 is a schematic diagram showing contract information stored in the storage device of the management server of FIG. 2. FIG. 11 is a schematic diagram showing the contents of a registration processing completion notification sent from the management server to the owner device. FIG. 12 is a sequence diagram showing the processing performed by the management server of FIG. 1 when the management server starts owner key generation processing for each vehicle in the management system of FIG. 1. FIG. 13 is a sequence diagram showing the processing performed by the management server of FIG. 1 when sending an owner key registration completion notification for each vehicle in the management system of FIG. 1.

[0009] A management system including a management server according to one embodiment will be described below with reference to FIGS. 1 to 13. The Car Connectivity Consortium (CCC) has established standards for digital keys. The digital key aspects of this embodiment comply with the CCC.

[0010] 1 , the management system 10 includes a plurality of vehicles 20, a plurality of devices 30, a device server 60, and a management server 70. The plurality of vehicles 20, the plurality of devices 30, the device server 60, and the management server 70 can communicate with each other via a network 90. ​​The management system 10 manages the digital keys of the plurality of vehicles 20.

[0011] The management server 70 manages digital keys. As shown in FIG. 2 , the management server 70 includes an execution device 71, a storage device 72, and a communication module 73. The execution device 71 is a processing circuit including one or more processors that execute various processes according to a computer program (software). The communication module 73 is a communication device that communicates with the device 30 and the vehicle 20. The storage device 72 stores a server program PS, a notification program PN, and a database DB. When executed by the execution device 71, the server program PS causes the execution device 71 to register digital keys in the database DB and delete digital keys from the database DB. When executed by the execution device 71, the notification program PN causes the execution device 71 to notify the vehicle 20 and the device 30 of the progress and results of the digital key registration process. The data DA included in the database DB is separated by vehicle. When a digital key is registered, the management server 70 stores, as data DA, information indicating the device 30 that stores key information DK indicating the digital key.

[0012] The multiple devices 30 include an owner device 40 and multiple shared devices 50. The multiple shared devices 50 include a friend device 51 and a non-friend device 52. The devices 30 include both portable devices such as smartphones and virtual devices 30 constructed on a server. Hereinafter, the virtual devices 30 constructed on the server 80 will be referred to as virtual devices 30V.

[0013] 3 is a virtual device 30V. The owner device 40 includes an execution unit 36 ​​and a storage unit 37. The storage unit 37 stores a device program PD and key information DK.

[0014] 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 the functions of pairing devices 30 and sharing digital keys using APIs provided by the OS. The execution unit 36 ​​executes the device program PD to perform processes related to the storage and deletion of key information DK. The execution unit 36 ​​is a processing circuit including one or more processors that execute various processes according to computer programs (software).

[0015] The key information DK is information indicating a digital key. The owner device 40 stores owner key information DKO indicating an owner key KO as the key information DK. The owner key KO is a digital key, and only one owner key KO can be registered to one vehicle 20. Therefore, only one owner key KO exists for one vehicle 20. The owner device 40 is a device 30 that belongs to the owner of the vehicle 20.

[0016] 4 and 5, the share device 50 stores share key information DKS indicating a share key KS as key information DK. The share device 50 is a device 30 separate from the owner device 40. The share key KS is a digital key, and multiple share keys KS can be registered for one vehicle 20. In other words, multiple share keys KS can exist for one vehicle 20 so that multiple share keys KS can be used for one vehicle 20.

[0017] The friend device 51 included in the share device 50 is, for example, a portable device such as a smartphone. As shown in FIG. 4 , the friend device 51 includes a communication module 31, an execution unit 36 ​​which is a processing circuit, and a storage device 37. The communication module 31 communicates with the device server 60 via a wireless communication line. The storage device 37 stores a device program PD, key information DK, and share key information DKS. In the friend device 51, the key information DK is friend key information DKF which indicates a friend key.

[0018] The non-friend device 52 included in the share device 50 is, for example, a portable device such as a smartphone. As shown in FIG. 5 , the non-friend device 52 includes a communication module 31, an execution unit 36 ​​which is a processing circuit, and a storage device 37. The communication module 31 communicates with the device server 60 via a wireless communication line. The storage device 37 stores a device program PD, key information DK, and share key information DKS. In the non-friend device 52, the key information DK is non-friend key information DKN which indicates a non-friend key.

[0019] The types of share keys KS include a friend key KF and a non-friend key KN. The friend key KF is a share key KS registered based on a registration request directly from the owner device 40, as will be described later. The non-friend key KN is a share key KS registered based on a registration request from a friend device 51, as will be described later. The non-friend key KN is a share key KS registered based on a registration request from another device 30, rather than a registration request directly from the owner device 40. In other words, a non-friend key KN is a share key KS that is not a friend key KF.

[0020] As shown in FIG. 6 , the vehicle 20 has a communication module 21 and a vehicle management device 26. The communication module 21 communicates with the management server 70 via a wireless communication network. The vehicle management device 26 is mounted on the vehicle 20. The vehicle management device 26 manages the digital key of the vehicle 20. The vehicle management device 26 is, for example, a digital key ECU. The vehicle management device 26 has an execution device 27 and a storage device 28. The execution device 27 is a processing circuit including one or more processors that execute various processes according to a computer program (software). The storage device 28 stores a vehicle program PV and authentication information AT.

[0021] The vehicle program PV is executed by the execution device 27, causing the execution device 27 to store and delete authentication information AT. The authentication information AT is information related to the digital key. More specifically, the authentication information AT is information for authenticating the digital key so that the vehicle 20 can be controlled using the digital key when the digital key is used. The authentication information AT is provided for each digital key to be authenticated. The execution device 27 is a CPU. The execution device 27 executes the vehicle program PV to perform processes related to the storage and deletion of the authentication information AT.

[0022] The state in which the digital key is registered means that the digital key is usable. In the state in which the digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. When the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be controlled with the digital key. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be unlocked. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 allows the vehicle 20 to be started. The digital key is validated by being authenticated by the vehicle management device 26.

[0023] The device server 60 shown in FIG. 1 relays communication between the devices 30, which are portable devices, and the management server 70. Only one device server 60 is shown in FIG. 1 . However, a device server 60 may be 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 refers to the model of the device 30, and a device server 60 is provided for each model of the device 30. For example, the type refers to the communication line used by the device 30, and a device server 60 is provided for each communication line used by the device 30.

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

[0025] The owner device 40 stores owner key information DKO. As shown in Fig. 7, 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, slot identification information ST4, and permission public key information ST5.

[0026] The vehicle identification information ST1 is identification information for identifying the vehicle 20 for which the digital key is to be 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 key within the device 30. The in-device key identification information ST2 is information for identifying the digital key within the application of the device 30.

[0027] The digital key identification information ST3 is information used for managing the digital key in the management server 70. The slot identification information ST4 is information for identifying the digital key locally on the device 30. The permission public key information ST5 is information indicating the vehicle public key, which is the public key of the vehicle 20 that has already been permitted.

[0028] As shown in Figure 8, in the database DB of the management server 70, the data DA for one vehicle 20 includes information about the type of digital key registered to that vehicle 20, the registered devices 30, and the relationships between the registered devices 30. The digital keys are divided into multiple hierarchies based on their type. From top to bottom, the hierarchies are arranged as follows: owner key KO, friend key KF, and non-friend key KN. The higher the hierarchical level of a digital key, the greater the authority set for that key.

[0029] The authority may be, for example, the number of share keys KS that can be requested to be registered, the range of control of the vehicle 20 that can be achieved by authenticating the digital key, etc. The higher the hierarchical level of the digital key, the greater the number of share keys KS that can be requested to be registered. More specifically, for example, the number of friend keys KF that the owner device 40 can request to be registered is greater than the number of non-friend keys KN that the friend device 51 can request to be registered.

[0030] Furthermore, for example, the higher the hierarchical level of a digital key, the wider the controllable range of the vehicle 20. The controllable range of the vehicle 20 indicates, for example, the possible controls among control of starting the engine of the vehicle 20, control of turning on the power of the vehicle 20, and control of unlocking and locking the doors of the vehicle 20. For example, if the controllable range of the vehicle 20 includes the above-mentioned three controls, the controllable range of the vehicle 20 is wider than if the controllable range of the vehicle 20 is only control of unlocking and locking the doors of the vehicle 20. More specifically, the controllable range of the vehicle 20 that can be controlled by the friend key KF is the above-mentioned three controls, while the controllable range of the vehicle 20 that can be controlled by the non-friend key KN is only control of unlocking and locking the doors of the vehicle 20.

[0031] The following describes a state in which digital keys are registered to seven devices 30 for one vehicle 20. The seven devices 30 are a first device 30A to a seventh device 30G.

[0032] The device 30 in which the owner key KO is registered as a digital key is the first device 30A. That is, the first device 30A is the owner device 40. The devices 30 in which the shared key KS is registered as a digital key are the second device 30B, the third device 30C, the fourth device 30D, the fifth device 30E, the sixth device 30F, and the seventh device 30G. That is, 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.

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

[0034] The relationships between the registered devices 30 included in the data DA will be described. The relationship between the second device 30B and the first device 30A is such that a friend key KF is registered in the second device 30B due to a registration request from the first device 30A. The relationship between the fifth device 30E and the first device 30A is such that a friend key KF is registered in the fifth device 30E due to a registration request from the first device 30A.

[0035] The relationship between the third device 30C and the second device 30B is such that a non-friend key KN is registered in the third device 30C due to a registration request from the second device 30B. The relationship between the fourth device 30D and the second device 30B is such that a non-friend key KN is registered in the fourth device 30D due to a registration request from the second device 30B.

[0036] The relationship between the sixth device 30F and the fifth device 30E is such that a non-friend key KN is registered in the sixth device 30F due to a registration request from the fifth device 30E. The relationship between the seventh device 30G and the fifth device 30E is such that a non-friend key KN is registered in the seventh device 30G due to a registration request from the fifth device 30E.

[0037] In this way, the data DA includes information about the device 30 in which the digital key is registered. The data DA associates the registered device 30 with information indicating the device 30 that made the request that caused the registration of the device 30.

[0038] <Digital Key Registration> Next, a series of processes for registering a digital key in the management system 10 will be described. Digital key registration includes registration of an owner key KO, registration of a friend key KF, and registration of a non-friend key KN. The following describes the series of processes until the owner key KO of each of the vehicles 20A to 20D is registered in the owner device 40 belonging to the owner who purchased the four vehicles 20A to 20D. In the following description, the owner device 40 is assumed to be a virtual device 30V existing on the server 80. Below, the processing executed by the execution device 27 will be described as processing executed by the vehicle 20. Furthermore, the processing executed by the execution device 36 of the owner device 40 will be described as processing executed by the owner device 40. The processing executed by the execution device 71 will be described as processing executed by the management server 70.

[0039] <Registration of Multiple Owner Keys KO> As shown in FIG. 9, the management system 10 performs a series of processes for registering the owner keys KO in each of the vehicles 20A to 20D.

[0040] In the management system 10, by registering the owner key KO, key information DK indicating the owner key KO of each of the vehicles 20A to 20D is stored in a virtual device 30V, which is an owner device 40. In the management system 10, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. Then, when the owner key KO is authenticated and validated by the vehicle 20 and registered in the management server 70, the virtual device 30V is set as the owner device 40.

[0041] 9, the management server 70 receives a registration request D21 for the owner key KO from the owner device 40. The registration request D21 includes information for identifying the contract information CI for the vehicles 20A to 20D.

[0042] As shown in FIG. 10 , the management server 70 stores contract information CI in the storage device 72. The contract information CI includes a contract number for identifying the contract for the vehicle 20, a contractor ID for identifying the owner of the vehicle 20, owner device identification information for identifying the owner device 40, and a vehicle ID for identifying the vehicle 20. If a contract includes multiple vehicles 20, the contract information CI includes multiple vehicle IDs. When the owner device 40 is a virtual device 30V, the owner device identification information is information for identifying the virtual device 30V and the server 80 on which the virtual device 30V resides in the network 90. ​​This owner device identification information is, for example, the IP addresses of the virtual device 30V and the server 80, or authentication information stated in a certificate issued by the server 80.

[0043] 9, the information for identifying the contract information CI is, for example, contract identification information assigned to the contracts for vehicles 20A to 20D, i.e., contract numbers. The information for identifying the contract information CI is, for example, a list of identification information for vehicles 20A to 20D, i.e., a list of vehicle IDs assigned to vehicles 20A to 20D. Furthermore, the information for identifying the contract information CI is, for example, contractor information for identifying the owners of vehicles 20A to 20D, i.e., contractor IDs.

[0044] The management server 70 identifies the contract information CI corresponding to the registration request D21 from the contract information CI stored in the storage device 72, based on information for identifying the contract information CI included in the registration request D21 received from the owner device 40. By referencing the contract information CI corresponding to the registration request D21, the management server 70 identifies the owner, the owner device 40 belonging to the owner, and the vehicles 20A to 20D related to the registration request D21.

[0045] In one example, the management server 70 may receive a registration request D21 that includes a contract number as information for identifying the contract information CI. In this case, the management server 70 references the contract information CI corresponding to the contract number to identify the contractor ID, the owner device identification information, and the vehicle ID assigned to each of the vehicles 20A to 20D.

[0046] In another example, the management server 70 may receive a registration request D21 that includes a list of vehicle IDs assigned to the vehicles 20A to 20D as information for identifying the contract information CI. In this case, the management server 70 references the contract information CI corresponding to the combination of these vehicle IDs to identify the contractor ID, owner device identification information, and vehicle ID assigned to each of the vehicles 20A to 20D.

[0047] In yet another example, the management server 70 may receive a contractor ID as information for identifying the contract information CI. In this case, the management server 70 refers to the contract information CI corresponding to the contractor ID to identify the contractor ID, the owner device identification information, and the vehicle ID assigned to each of the vehicles 20A to 20D.

[0048] 9, upon receiving the registration request D21, the management server 70 transmits the key information DK for each of the vehicles 20A to 20D together to the owner device 40. The transmission of this key information DK corresponds to the transmission of a generation start notification to the owner device 40 informing the owner device 40 that the generation process for the owner key KO for each of the vehicles 20A to 20D has started.

[0049] When the owner device 40 receives the key information DK for the multiple vehicles 20, the process proceeds to step S121. In step S121, the owner device 40 generates owner key information DKO indicating the owner keys of the respective vehicles 20A to 20D based on the key information DK. After generating the owner key information DKO, the owner device 40 stores the owner key information DKO for each of the vehicles 20A to 20D in the storage device 37 in step S122.

[0050] The owner device 40 that has stored the owner key information DKO starts the authentication process of the owner key KO for each of the vehicles 20A to 20D. This authentication process starts when the owner device 40 transmits an authentication request D22 for the owner key KO to each of the vehicles 20. This authentication request D22 includes the owner key information DKO corresponding to each of the vehicles 20. Upon receiving the authentication request D22, the vehicle 20 proceeds to step S123 and starts authenticating the owner key KO.

[0051] 9 shows an example in which the vehicle 20A completes the authentication process. In step S123a, the vehicle 20A receives the authentication request D22a and authenticates the owner key KOa based on the received owner key information DKOa for the vehicle 20A and the authentication information stored in the vehicle 20A. The "a" added to "authentication request D22a" is a subscript indicating that the authentication request D22a is the authentication request D22 for the vehicle 20A. The "a" added to "step S123a" is a subscript indicating that step S123a is the processing of step S123 for the vehicle 20A. The "a" added to "owner key information DKOa" is a subscript indicating that the owner key information DKOa is the owner key information DKO for the vehicle 20A. The "a" added to "owner key KOa" is a subscript indicating that the owner key KOa is the owner key KO of the vehicle 20A.

[0052] When the authentication of the owner key KOa is completed, the vehicle 20A stores authentication information ATa indicating the owner key information DKOa in step S124a. This validates the owner key KOa. The "a" added to "step S124a" is a subscript indicating that step S124a is the processing of step S124 for the vehicle 20A. The "a" added to "authentication information ATa" is a subscript indicating that the authentication information ATa is authentication information AT for the vehicle 20A.

[0053] Thereafter, the vehicle 20A transmits to the management server 70 an authentication completion notification D23a of the owner key KOa indicating that storage of the authentication information ATa has been completed. In this way, the generation process of the owner key KOa for the vehicle 20A is completed. The "a" added to the "authentication completion notification D23a" is a subscript indicating that the authentication completion notification D23a is the authentication completion notification D23 for the vehicle 20A.

[0054] 9 shows an example in which the vehicle 20D fails the authentication process. When the vehicle 20D receives an authentication request D22d for the owner key KOd for the vehicle 20D from the owner device 40 and fails the subsequent authentication process, the vehicle 20D transmits an authentication failure notification D24d for the owner key KOd to ​​the management server 70. This allows the management server 70 to understand that the authentication process for the owner key KOd for the vehicle 20D has failed, and therefore the generation process for the owner key KOd has failed. The "d" added to the "owner key KOd" is a subscript indicating that the owner key KOd is the owner key KO of the vehicle 20D. The "d" added to the "authentication request D22d" is a subscript indicating that the authentication request D22d is the authentication request D22 for the vehicle 20D. The "d" added to the "authentication failure notification D24d" is a subscript indicating that the authentication failure notification D24d is the authentication failure notification D24 for the vehicle 20D.

[0055] The authentication process ends when the management server 70 receives the authentication completion notification D23 or the authentication failure notification D24. The generation process ends when the authentication process ends.

[0056] Next, in the processing of step S125, the management server 70 registers and manages the four owner keys KO for which the generation processing has been completed. Specifically, as data DA for each of the vehicles 20A to 20D in the database DB, the management server 70 stores information that the device 30 in which the owner key KO is registered is the virtual device 30V. This completes the registration of the owner key KO in the management system 10. Thereafter, the management server 70 transmits a registration processing completion notification D25 of the owner key KO to the owner device 40, i.e., the virtual device 30V.

[0057] As shown in FIG. 11 , the registration process completion notification D25 notifies, in a single list, information regarding the success or failure of the registration process for multiple vehicles 20 for which the registration process was executed, i.e., whether registration was completed or failed. In other words, the completion of the registration process does not necessarily mean that registration was successful. Completion of registration or the completion of the registration process means that registration was successful. For example, if the registration of the owner key KO for vehicles 20A to 20C was successful but the registration of the owner key KO for vehicle 20D failed, the contents of the list included in the registration process completion notification D25 will be as shown in FIG. 11 . The vehicle ID "XXXX34" is the vehicle ID assigned to vehicle 20A. The vehicle ID "XXXX37" is the vehicle ID assigned to vehicle 20B. The vehicle ID "XXXX46" is the vehicle ID assigned to vehicle 20C. The vehicle ID "XXXX59" is the vehicle ID assigned to vehicle 20D. This completes the owner key KO registration process in the management system 10.

[0058] For example, the management server 70 determines that the generation process of the owner key KO for the vehicle 20 has failed as follows: When the management server 70 receives an authentication failure notification D24 from the vehicle 20, it determines that the generation process for the corresponding vehicle 20 has failed. If the management server 70 has not received either the authentication completion notification D23 or the authentication failure notification D24 from the vehicle 20 despite a predetermined time having elapsed since sending the generation start notification to the owner device 40, the management server 70 may determine that the generation process for the corresponding vehicle 20 has failed. The predetermined time can be set arbitrarily, taking into account the time normally required for the owner key generation process.

[0059] <Operation of this embodiment> Based on the information included in the registration request D21, the management server 70 identifies the contract information CI corresponding to the registration request D21 from the contract information CI stored in the storage device 72. By referencing the contract information CI corresponding to the registration request D21, the management server 70 identifies the owner, the owner device 40 belonging to the owner, and the vehicles 20A to 20D. Then, based on the single registration request D21, the management server 70 causes the management system 10 to start a process of generating digital keys for each of the vehicles 20A to 20D for the owner device 40.

[0060] <Advantages of this embodiment> (1) The management server 70 reduces the effort required for owners who have acquired multiple vehicles 20 to register digital keys.

[0061] (2) The contract information CI includes contract identification information attached to the contracts for the multiple vehicles 20 belonging to the owner. Information for identifying the contract information CI includes contract identification information attached to the contracts for the multiple vehicles 20 belonging to the owner.

[0062] The management server 70, which stores the contract information CI, receives information for identifying the contract information CI, i.e., contract identification information. Based on the received contract identification information, the management server 70 can identify the corresponding contract information CI from among the contract information CI stored therein.

[0063] (3) The information for identifying the contract information CI includes a list of identification information of the plurality of vehicles 20 belonging to the owner. The management server 70 can identify the corresponding contract information CI from among the stored contract information CI based on the list of identification information of the plurality of vehicles 20 belonging to the owner.

[0064] (4) The contract information CI includes contractor information for identifying the owner. The information for identifying the contract information CI includes contractor information for identifying the owner. The management server 70 can identify the corresponding contract information CI from among the contract information CI stored therein based on the contractor information for identifying the owner.

[0065] (5) The execution unit 71 of the management server 70 sends a generation start notification to the owner device 40, notifying that the generation process has started, using the communication module 73. The management server 70 can notify the owner that the digital key generation process has started.

[0066] (6) After the generation process has started for all of the multiple vehicles 20 belonging to the owner, the execution device 71 of the management server 70 sends a generation start notification to the owner device 40 indicating that the generation process has started for all of the multiple vehicles 20 belonging to the owner.

[0067] The management server 70 can notify the owner of the start of the generation process for all of the multiple vehicles 20 belonging to the owner in a single notification. (7) The execution unit 71 of the management server 70 uses the communication module 73 to send a registration completion notification to the owner device 40 notifying that the registration process has been completed.

[0068] The management server 70 can notify the owner of the completion of the digital key registration process. (8) After the digital key registration process for all of the multiple vehicles 20 belonging to the owner is completed, the execution device 71 of the management server 70 transmits a completion notification to the owner device 40. The completion notification is a notification indicating that the digital key registration process for all of the multiple vehicles 20 belonging to the owner is completed.

[0069] The management server 70 can notify the owner of the completion of the digital key registration process for all of the owner's vehicles 20 in a single notification. (9) The execution device 71 of the management server 70 transmits a completion notification to the owner device 40, including information on the success or failure of the registration process for each of the owner's vehicles 20.

[0070] The management server 70 can notify the owner of the completion of the digital key registration process for all of the multiple vehicles 20 belonging to the owner, and can also notify the owner of the success or failure of the registration process for each vehicle.

[0071] <Modifications> This embodiment can be modified as follows: This embodiment and the following modifications can be combined and implemented within the scope of technical compatibility.

[0072] The management server 70 transmits a generation start notification including key information DK for multiple vehicles 20 to the owner device 40. In response to this, the management server 70 may transmit a generation start notification including key information DK to the owner device 40 separately for each vehicle. For example, as shown in FIG. 12 , the management server 70 may start the owner key generation process for each vehicle by transmitting a generation start notification separately for each of vehicles 20A to 20D. When starting the owner key generation process for vehicle 20A, the management server 70 transmits a generation start notification including key information DKa for vehicle 20A to the owner device 40. The "a" added to "key information DKa" is a subscript indicating that the key information DKa is key information DK for vehicle 20A.

[0073] In this case, when the execution device 71 of the management server 70 starts the process of generating a digital key for each vehicle 20 , it sends a generation start notification to the owner device 40 separately for each vehicle 20 .

[0074] The management server 70 in the modified example can notify the owner of the start of the generation process for each of the multiple vehicles 20 separately for each vehicle 20. The above-described management server 70 transmits a registration process completion notification D25 for the owner key KO to the owner device 40 after the owner key registration process for all of the multiple vehicles 20 is completed. As shown in FIG. 13 , the management server 70 may transmit an owner key registration completion notification D26b for the vehicle 20B to the owner device 40 each time the owner key registration process for each vehicle 20 is completed. For example, if the registration of the owner key KOb for vehicle 20B is completed in step S125b, the management server 70 transmits a registration completion notification D26b for vehicle 20B to the owner device 40. The "b" added to "owner key KOb" is a subscript indicating that the owner key KO is the owner key for vehicle 20B. The "b" added to "step S125b" is a subscript indicating that step S125b is the process of step S125 for vehicle 20B. The "b" added to the "registration completion notification D26b" is a subscript indicating that the registration completion notification D26b is the registration completion notification D26 for the vehicle 20B.

[0075] Furthermore, the management server 70 may transmit a registration process completion notification D25 together with the registration completion notification D26 for each vehicle. That is, as shown in step S126 of FIG. 13 , the management server 70 may transmit the registration process completion notification D26 for each vehicle, and then transmit the registration process completion notification D25 after completing the registration process for all of the multiple vehicles 20A to 20D. When the registration process for all of the multiple vehicles 20A to 20D is completed, the management server 70 tallyes up the success or failure of the owner key registration process for all of the multiple vehicles 20A to 20D in step S126. Then, the management server 70 transmits a registration process completion notification D25 to the owner device 40 to notify that the registration process for all of the multiple vehicles 20A to 20D has been completed.

[0076] When the digital key registration process for each vehicle 20 is completed, the execution device 71 of the management server 70 transmits a registration completion notification to the owner device 40 separately for each vehicle 20 .

[0077] The management server 70 can notify the owner of the completion of the digital key registration process for each of the multiple vehicles 20 belonging to the owner, separately for each vehicle 20. Furthermore, in the above, if the owner key registration for any vehicle 20 fails, the management server 70 may send a registration failure notification to the owner device 40 instead of the registration completion notification D26.

[0078] The execution unit 71 of the management server 70 sends a registration failure notification to the owner device 40, notifying that the registration process has failed, using the communication module 73. The management server 70 of the modified example can notify the owner of the failure of the digital key registration process.

[0079] The registration failure notification may be sent to each vehicle 20, similar to the registration completion notification. When the digital key registration process for each of the multiple vehicles 20 fails, the execution device 71 of the management server 70 may send a registration failure notification to the owner device 40 separately for each vehicle 20.

[0080] In a modified example, the management server 70 notifies the owner of the failure of the digital key registration process for each of the multiple vehicles 20 belonging to the owner, separately for each vehicle 20. The management server 70 includes in the registration process completion notification D25 a list that consolidates information regarding the success or failure of the owner key registration for the multiple vehicles 20. Alternatively, the management server 70 may notify only that the registration process has been completed for all of the multiple vehicles 20A to 20D, without including the above list in the registration process completion notification D25. The management server 70 may include in the registration process completion notification D25 a list that lists only the vehicles for which the registration process has been completed. The management server 70 may include in the registration process completion notification D25 a list that lists only the vehicles for which the registration process has failed.

[0081] The above embodiment shows an example in which owner keys for multiple vehicles 20 are registered to a virtual device 30V present in the server 80. However, the owner device 40 that registers owner keys for multiple vehicles 20 belonging to the owner is not limited to the virtual device 30V.

[0082] The owner device 40 may be a portable device such as a smartphone. In this case, some of the processes in the registration sequence shown in FIG. 9 are modified as follows. Specifically, the management server 70 does not need to receive information for identifying the contract information CI from the owner device 40 and refer to the contract information CI. The management server 70 receives an owner key KO registration request D21 from the owner device 40, which is a portable device. The owner key KO registration request D21 includes information for identifying the owner device 40 and information for identifying the multiple vehicles 20 to which the owner key KO is to be registered. The information for identifying the owner device 40 is, for example, the smartphone's identification number and serial code, or information on the device server 60 to which the smartphone belongs. The information for identifying the multiple vehicles 20 belonging to the owner is, for example, a vehicle ID assigned to each of the multiple vehicles 20 belonging to the owner. Based on the above two types of identification information, the management server 70 identifies the owner device 40 and the multiple vehicles 20 to which the owner key is to be registered. The management server 70 then collectively transmits key information DK for the identified multiple vehicles 20 to the owner device 40, which is a portable device. At this time, the key information DK may be transmitted from the management server 70 to the owner device 40 via the device server 60 to which the owner device 40 belongs. Even if the owner device 40 is a portable device, the management server 70 can start the owner key registration process for multiple vehicles 20 belonging to the owner based on a single registration request.

[0083] The management server 70 identifies the multiple vehicles 20 belonging to the owner based on information for identifying the multiple vehicles 20 belonging to the owner, which is included in the registration request D21. The management server 70 identifies the owner device 40 based on information for identifying the owner device 40, which is included in the registration request D21. Then, the management server 70 causes the management system 10 to start a process for generating digital keys for the multiple vehicles 20 to the owner device 40 based on a single registration request D21.

[0084] The management server 70 of the modified example can reduce the time and effort required for owners who have acquired multiple vehicles 20 to register their digital keys. The vehicle management device 26 is not limited to a digital key ECU. For example, the vehicle management device 26 may be a central ECU that manages multiple ECUs in the vehicle 20.

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

[0086] The device 30, which is a portable device, is not limited to a smartphone. The device 30, which is a portable device, may be a smartwatch. The virtual device 30V may be configured to be included in a predetermined server such as the server 80. For example, the virtual device 30V may be included in the management server 70. Similarly, the friend device 51 may be included in a predetermined server.

[0087] In the above embodiment, the digital keys are arranged in a hierarchy of owner key KO, friend key KF, and non-friend key KN, with the higher the hierarchy, the greater the authority assigned to the digital key. The digital keys do not necessarily have to be set so that the higher the hierarchy, the greater the authority assigned to the digital key. For example, the same authority may be assigned to the three hierarchical levels of the owner key KO, friend key KF, and non-friend key KN.

[0088] A device server 60 does not need to be provided for each type of device 30. It is sufficient that multiple devices 30 and the management server 70 are capable of wireless communication. The device server 60 may be omitted from the management system 10. It is sufficient that multiple devices 30 and the management server 70 are capable of direct wireless communication in the management system 10.

[0089] The management server 70 may be configured with multiple servers. For example, the management server 70 may be configured with a server that stores the database DB, a server that executes the server program PS, and a server that executes the notification program PN. For example, the management server 70 may be configured with a server that communicates with the vehicle 20 and a server that communicates with the device server 60, and these servers may be able to communicate with each other.

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

[0091] The authentication information AT is not limited to the example of the above embodiment as long as it is information for authenticating the digital key when using the digital key. 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.

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

[0093] 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 server, and the like.

[0094] The structure of the data DA included in the database DB is not limited to the examples in the above embodiments. The database DB may include information necessary for management by the management server 70 in the management system 10.

[0095] In the database DB, authority may be set for each digital key, rather than being uniformly determined according to the type of digital key. Authority for digital keys does not have to be determined in the database DB.

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

[0097] The digital key-related matters in the above embodiment do not have to comply with the CCC.

Claims

1. A management server that forms part of a management system configured to manage digital keys for multiple vehicles and is configured to manage information related to the digital keys stored in devices, comprising: an execution unit; and a communication unit, wherein the devices include owner devices belonging to owners of the multiple vehicles, and the communication unit is configured to communicate with the owner devices and the multiple vehicles, and upon receiving a registration request requesting the start of a registration process for the digital keys, the execution unit is configured to: identify the owner devices and the multiple vehicles, send information related to the digital keys for each of the multiple vehicles to the owner devices using the communication unit, and cause the management system to start a process for generating the digital keys for each of the multiple vehicles to be registered in the owner devices.

2. A management server as described in claim 1, comprising a storage device in which contract information including information for identifying the owner device and information for identifying the plurality of vehicles is stored, the registration request includes information for identifying the contract information, and the execution device is configured to identify the owner device and the plurality of vehicles by referring to the contract information stored in the storage device.

3. The management server described in claim 2, wherein the contract information includes contract identification information attached to the contract for the plurality of vehicles, and the information for identifying the contract information includes contract identification information attached to the contract for the plurality of vehicles.

4. The management server according to claim 2, wherein the information for identifying the contract information includes a list of identification information assigned to each of the plurality of vehicles.

5. The management server according to claim 2, wherein the contract information includes contractor information for identifying the owner, and the information for identifying the contract information includes contractor information for identifying the owner.

6. The management server according to claim 1, wherein the registration request includes information for identifying the owner device and identification information assigned to each of the plurality of vehicles.

7. A management server according to any one of claims 1 to 6, wherein the execution device is configured to send a generation start notification to the owner device using the communication device, notifying that the generation process has started.

8. The management server according to claim 7, wherein the execution device is configured to transmit the generation start notification to the owner device separately for each vehicle when the generation process is started for each of the plurality of vehicles.

9. The management server of claim 7, wherein the execution device is configured to send the generation start notification to the owner device indicating that the generation process has started for all of the plurality of vehicles after the generation process has started for all of the plurality of vehicles.

10. A management server as described in any one of claims 1 to 9, wherein the execution device is configured to send a registration completion notification to the owner device using the communication device, notifying that the registration process has been completed.

11. The management server of claim 10, wherein the execution device is configured to transmit the registration completion notification to the owner device separately for each of the plurality of vehicles when the registration process is completed for each of the plurality of vehicles.

12. A management server as described in any one of claims 1 to 11, wherein the execution device is configured to send a registration failure notification to the owner device using the communication device, notifying that the registration process has failed.

13. The management server of claim 12, wherein the execution device is configured to send the registration failure notification to the owner device separately for each of the plurality of vehicles when the registration process fails for each of the plurality of vehicles.

14. A management server as described in any one of claims 1 to 13, wherein the execution device is configured to send a completion notification to the owner device indicating that the registration process for all of the plurality of vehicles has been completed after the registration process for all of the plurality of vehicles has been completed.

15. The management server according to claim 14, wherein the completion notification includes information on the success or failure of the registration process for each of the plurality of vehicles.

Images