Management server

Abstract

To provide a management server for reducing labor required for registration of a digital key of an owner who has acquired a plurality of vehicles.SOLUTION: The management server 70 manages information related to the digital key stored in the device 30. When the management server 70 receives the owner key registration request D21 from the owner devices 40, the management server 70 specifies the owner devices 40 and the vehicles 20A to 20D and transmits information on the digital keys of the vehicles 20A to 20D to the owner devices 40. Accordingly, the management server 70 causes the management system to start a process of generating a digital key for each of the vehicles 20A to 20D to be registered in the owner devices 40.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present invention relates to a management server. [Background technology]

[0002] Patent Document 1 describes a digital key management system. The management system includes a vehicle, multiple devices, and a management server. Information about the digital key is stored in the vehicle and the device, thereby registering the vehicle's digital key in the device. The management server is capable of communicating with the devices and the vehicle, and manages the registration of the digital key.

[0003] Patent Document 1 discloses a management system that registers an owner key, which is a digital key that is registered only once for a vehicle, from a device to which the owner key is registered, to a number of selected other devices. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2024-001720 Summary of the Invention [Problem to be solved by the invention]

[0005] An owner who acquires a new vehicle stores information about the owner key in a device belonging to the owner, and also stores information about the owner key in the acquired vehicle. When the owner key is authenticated 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 acquires multiple vehicles, it is time-consuming to repeat the owner key registration process for each vehicle. [Means for solving the problem]

[0006] A management server that solves the above-mentioned problems constitutes part of a vehicle digital key management system and manages information related to digital keys stored in devices. This management server includes an execution device and a communication device that communicates with an owner device, which is a device belonging to the owner of the vehicle, and the vehicle. Upon receiving a registration request requesting the start of the digital key registration process, the execution device of the management server identifies the owner device and multiple vehicles, sends information about the digital keys for each of the multiple vehicles to the owner device using the communication device, and causes the management system to start the process of generating the digital keys for each of the multiple vehicles to be registered to the owner device. [Effects of the Invention]

[0007] The management server described above can reduce the effort required for owners who have acquired multiple vehicles to register their digital keys. [Brief explanation of the drawings]

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

[0009] An embodiment of a management system including a management server will be described below with reference to FIGS. There are standards for digital keys set by the Car Connectivity Consortium (CCC). The digital key-related aspects of this embodiment comply with the CCC.

[0010] <Outline of Management System 10> 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.

[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 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 the execution device 71 executes the server program PS, it causes the execution device 71 to register a digital key in the database DB and delete a digital key from the database DB. When the execution device 71 executes the notification program PN, it 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 database DB has data DA separated for each vehicle. When a digital key is registered, the management server 70 stores, in the 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 a server will be referred to as virtual devices 30V.

[0013] 3 is a virtual device 30V constructed on a server 80. The owner device 40 includes an execution unit 36 ​​and a storage device 37. The storage device 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.

[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. Only one owner key KO can be registered for one vehicle 20. Therefore, only one owner key KO exists for one vehicle 20. The owner device 40 belongs to the owner of the vehicle 20.

[0016] 4 and 5, the shared device 50 stores shared key information DKS indicating a shared key KS as key information DK. The shared device 50 is a device 30 separate from the owner device 40. The shared key KS is a digital key that can be registered in multiple numbers for one vehicle 20 when registering the digital key to enable use of the digital key. In other words, multiple shared keys KS can exist 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 device 36, 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 that 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 device 36, 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 that indicates a non-friend key.

[0019] That is, the types of shared keys KS include friend keys KF and non-friend keys KN. A friend key KF is a shared key KS registered based on a registration request directly from the owner device 40, as will be described later. A non-friend key KN is a shared key KS registered based on a registration request from a friend device 51, as will be described later. That is, a non-friend key KN is a shared 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 shared key KS that is not a friend key KF, among shared keys KS.

[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 a 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 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] Note that when a digital key is registered, the digital key is enabled for use. That is, when a digital key is registered, the vehicle 20 stores authentication information AT, and the device 30 stores key information DK. In the vehicle 20, authenticating a digital key means enabling the vehicle 20 to be controlled using the digital key. For example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables the vehicle 20 to be unlocked. Also, for example, when the vehicle management device 26 authenticates the digital key, the vehicle management device 26 enables the vehicle 20 to be started. The digital key is validated by being authenticated.

[0023] 1 relays communication between the devices 30, which are portable devices, and the management server 70. A device server 60 is provided for each type of device 30. That is, the device server 60 with which a first type of device 30 communicates is different from the device server 60 with which a second type of device 30 communicates. For example, the type 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] Any of the device servers 60 relays communication with the management server 70, so that different types of devices 30 can communicate with the management server 70 via the device servers 60. Note that only one device server 60 is shown in FIG.

[0025] The owner device 40 stores owner key information DKO. As shown in Fig. 7, the owner key information DKO has 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 that identifies 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 intra-device key identification information ST2 is used to manage the digital key within the device 30. The intra-device key identification information ST2 is information that can identify the digital key within the application of the device 30. The digital key identification information ST3 is used to manage the digital key within the management server 70. The slot identification information ST4 is information that can identify the digital key locally on the device 30. The permission public key information ST5 indicates a vehicle public key that is the public key of the vehicle 20 that has already been authorized.

[0027] As shown in Figure 8, in the database DB of the management server 70, the data DA for one vehicle 20 includes the type of digital key registered to the vehicle 20, the registered devices 30, and the relationships between the registered devices 30. Hierarchical rankings are determined based on 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. The higher the hierarchy, the greater the authority set.

[0028] 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 hierarchy, the greater the authority, and therefore, for example, 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.

[0029] Furthermore, for example, the higher the hierarchy, the greater the authority, and therefore the wider the controllable range of the vehicle 20. The controllable range of the vehicle 20 indicates, for example, the possible controls among the engine start control of the vehicle 20, the power on control of the vehicle 20, and the unlocking and locking control of 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 the unlocking and locking control of the doors of the vehicle 20. More specifically, the controllable range of the vehicle 20 that the friend key KF can control is the above-mentioned three controls, whereas the controllable range of the vehicle 20 that the non-friend key KN can control is only the unlocking and locking control of the doors of the vehicle 20.

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

[0031] In the data 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.

[0032] In the data 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. 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, in the data DA, the devices 30 whose digital key type is registered as a friend key KF are the second device 30B and the fifth device 30E. That is, the second device 30B and the fifth device 30E are friend devices 51. In the data 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. 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] In the data DA, 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. In the data DA, 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] In the data DA, 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. In the data DA, 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] In the data DA, 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. In the data DA, 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 stores the device 30 registered as a digital key. In addition, when the device 30 is registered, information indicating the device 30 that made the request that caused the registration is linked to the data DA.

[0038] <Digital key registration> Next, a series of processes for registering digital keys in the management system 10 will be described. The management system 10 registers an owner key KO, a friend key KF, and a non-friend key KN to register digital keys. The following describes a 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. The following description is an example in which the owner device 40 is a virtual device 30V present 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 virtual device 30V will be described as processing executed by the virtual device 30V. The processing executed by the execution device 71 will be described as processing executed by the management server 70.

[0039] <Registering multiple owner keys> As shown in FIG. 9, the management system 10 performs a series of processes for registering the owner keys KO for 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 the virtual device 30V, which is the owner device 40. In the management system 10, authentication information AT for authenticating the owner key KO is stored in the vehicle 20. Then, the owner key KO is authenticated and validated, and the owner key KO is registered.

[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] 10, the management server 70 stores contract information CI in the storage device 72. The contract information CI includes a contract number that identifies the contract for the vehicle 20, a contractor ID that identifies the owner of the vehicle 20, owner device identification information that identifies the owner device 40, and a vehicle ID that identifies 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 that identifies the virtual device 30V and the server 80 on which the virtual device 30V exists in the network 90. ​​This owner device identification information is, for example, the IP addresses of the virtual device 30V and the server 80, and authentication information for a certificate issued by the server 80.

[0043] 9, the information identifying the contract information CI is, for example, contract identification information assigned to the contracts for the vehicles 20A to 20D, i.e., contract numbers. The information identifying the contract information CI is, for example, a list of identification information for the vehicles 20A to 20D, i.e., a list of the vehicle IDs of the vehicles 20A to 20D. Furthermore, the information identifying the contract information CI is, for example, contractor information identifying the owners of the 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 the information for identifying the contract information CI included in the registration request D21 received from the owner device 40. The management server 70 identifies the owner, the owner device 40 belonging to the owner, and the vehicles 20A to 20D by referring to the contract information CI corresponding to the registration request D21.

[0045] For example, when the management server 70 receives a contract number as information identifying the contract information CI, the management server 70 refers to the contract information CI corresponding to the contract number to identify the contractor ID, owner device identification information, and vehicle ID of each of the vehicles 20A to 20D.

[0046] For example, the following shows a case where the management server 70 receives a list of the vehicle IDs of the vehicles 20A to 20D as information for identifying the contract information CI. In this case, the management server 70 refers to the contract information CI corresponding to the combination of these vehicle IDs to identify the contractor ID, the owner device identification information, and the vehicle ID of each of the vehicles 20A to 20D.

[0047] For example, the following shows a case where the management server 70 receives, as information for identifying the contract information CI, a contractor ID that identifies the owner of the vehicle 20. In this case, the management server 70 refers to the contract information CI corresponding to the contractor ID, and identifies the contractor ID, the owner device identification information, and the vehicle ID of each of the vehicles 20A to 20D.

[0048] 9, upon receiving the registration request D21, the management server 70 transmits 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 a generation start notification that notifies the owner device 40 that the process of generating the owner key KO has started.

[0049] When the owner device 40 receives the key information DK for the plurality of vehicles 20, the process proceeds to step S121. In the process of 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 of the respective vehicles 20A to 20D in the storage device 37 in the process of 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 sends 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] FIG. 9 shows an example in which the vehicle 20A completes the authentication process. In step S123a, the vehicle 20A receives an authentication request D22a for the vehicle 20A 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] FIG. 9 also 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 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, resulting in a failure in the generation process. 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. Then, the generation process ends when the authentication process ends.

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

[0057] As shown in FIG. 11, the registration process completion notification D25 notifies information regarding the success or failure of the registration process for multiple vehicles 20 for which the registration process was executed, collectively in a single list. For example, if registration is successful for vehicles 20A to 20C but fails for vehicle 20D, the contents of the list in the registration process completion notification D25 will be as shown in FIG. 11. Vehicle ID "XXXX34" is the vehicle ID of vehicle 20A. Vehicle ID "XXXX37" is the vehicle ID of vehicle 20B. Vehicle ID "XXXX46" is the vehicle ID of vehicle 20C. Vehicle ID "XXXX59" is the vehicle ID of vehicle 20D. This completes the series of owner key KO registration processes in the management system 10.

[0058] For example, the management server 70 determines that the generation process of the owner key KO for a 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 has failed for the vehicle 20. The management server 70 also determines that the generation process has failed for a vehicle 20 for which neither the authentication completion notification D23 nor the authentication failure notification D24 has been received from the vehicle 20, even though a predetermined time has elapsed since the management server 70 sent a generation start notification to the owner device 40. The predetermined time can be set arbitrarily, taking into account the time required for a normal 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 processing to generate digital keys for each of the vehicles 20A to 20D for the owner device 40.

[0060] <Effects of this embodiment> (1) The management server 70 can reduce the time and effort required for owners who have acquired multiple vehicles 20 to register their digital keys.

[0061] (2) The contract information CI stored in the management server 70 includes contract identification information attached to the contracts for the multiple vehicles 20 belonging to the owner. The information for identifying the contract information CI received by the management server 70 is the contract identification information attached to the contracts for the multiple vehicles 20 belonging to the owner.

[0062] The management server 70 can identify the contract information CI based on the contract identification information attached to the contracts for the multiple vehicles 20 belonging to the owner. (3) The information for identifying the contract information CI received by the management server 70 is a list of identification information for a plurality of vehicles 20 belonging to the owner.

[0063] The management server 70 can identify the contract information CI based on a list of identification information of a plurality of vehicles 20 belonging to the owner. (4) The contract information CI stored in the management server 70 includes contractor information for identifying the owner, and the information for identifying the contract information CI received by the management server 70 is contractor information for identifying the owner.

[0064] The management server 70 can identify the contract information CI based on the contractor information that identifies the owner. (5) The execution unit 71 of the management server 70 uses the communication module 73 to send a generation start notification to the owner device 40 notifying that the generation process has started.

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

[0066] The management server 70 can notify the owner of the start of the generation process for all of the 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 notice to the owner device 40 notifying that the registration process has been completed.

[0067] 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 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 vehicles 20 belonging to the owner has been completed.

[0068] The management server 70 can notify the owner in a single notification that the digital key registration process for all of the vehicles 20 belonging to the owner has been completed. (9) The execution device 71 of the management server 70 transmits a completion notification to the owner device 40, which notification includes information on the success or failure of the registration process for each of the vehicles 20 belonging to the owner.

[0069] The management server 70 can notify the owner of the completion of the digital key registration process for all of the vehicles 20 belonging to the owner, as well as information on the success or failure of the registration process for each vehicle.

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

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

[0072] In this case, the execution device 71 of the management server 70 transmits a generation start notification to the owner device 40 for each vehicle 20 when the digital key generation process starts. According to the management server 70, it is possible to notify the owner of each vehicle 20 of the start of the generation process for each vehicle 20.

[0073] After the owner key registration process for all of the vehicles 20 is completed, the management server 70 transmits a registration process completion notification D25 for the owner key KO to the owner device 40. As shown in FIG. 13 , each time the owner key registration process for any vehicle 20 is completed, the management server 70 can transmit a registration completion notification D26b for the vehicle 20 to the owner device 40. For example, if the registration of the owner key KOb for vehicle 20B in the management server 70 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 processing 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 vehicle 20B. Furthermore, the management server 70 may issue a registration processing completion notification D25 in addition to the above-mentioned registration completion notification D26 for each vehicle. That is, as shown in step S126 of FIG. 13, the management server 70 can issue the registration processing completion notification D25 after issuing the registration completion notification D26 for each vehicle and then completing the registration processing for all of the multiple vehicles 20A to 20D. When the registration processing for all of the multiple vehicles 20A to 20D is completed, the management server 70 tallies up in step S126 the success or failure of the registration processing, i.e., whether the owner key registration processing for each of the multiple vehicles 20A to 20D was completed or failed. Then, the management server 70 transmits to the owner device 40 an owner key registration process completion notification D25 notifying the owner device 40 that the owner key registration process for all of the plurality of vehicles 20A to 20D has been completed.

[0074] The execution device 71 of the management server 70 transmits a registration completion notification to the owner device 40 for each vehicle 20 when the digital key registration process is completed. The management server 70 can notify the owner of each vehicle 20 when the registration process for the digital keys of the vehicles 20 belonging to the owner has been completed.

[0075] Furthermore, in the above, if the registration of the owner key for any vehicle 20 fails, the management server 70 can transmit a registration failure notification to the owner device 40 instead of the registration completion notification D26.

[0076] In this way, the execution unit 71 of the management server 70 uses the communication module 73 to send a registration failure notice to the owner device 40 informing that the registration process has failed. Such a management server 70 can notify the owner of a failure in the digital key registration process.

[0077] The above registration failure notification can be sent for each vehicle, just like the above registration completion notification. The execution device 71 of the management server 70 may notify the owner device 40 of a registration failure for each vehicle 20 when the digital key registration process fails.

[0078] The management server 70 can notify the owner of each of the multiple vehicles 20 belonging to the owner of any failure in the registration process of the digital key for each of the vehicles 20 . The management server 70 transmits, as the registration process completion notification D25, a list that compiles information on whether the owner key registration for multiple vehicles 20 was completed or failed. On the other hand, the management server 70 may notify only that the registration process for all of the multiple vehicles 20A to 20D has been completed, without transmitting the above list, as the registration process completion notification D25. The management server 70 may transmit, in the above notification, a list that lists only the vehicles for which the registration process was completed. The management server 70 may transmit, in the above notification, a list that lists only the vehicles for which the registration process failed.

[0079] The owner key registration process for multiple vehicles 20 in the management system 10 described above illustrates an example in which the owner key is registered in a virtual device 30V stored in the server 80. However, the owner device 40 for registering the owner keys for multiple vehicles 20 belonging to the owner is not limited to the virtual device 30V. The owner device 40 for registering the owner key may be a portable device such as a smartphone. In this case, the registration sequence shown in FIG. 9 is partially modified as follows. Specifically, the management server 70 does not need to receive information 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, that includes information identifying the owner device 40 and information identifying the multiple vehicles 20 for which the owner key KO is to be registered. The information identifying the owner device 40 is, for example, the identification number and serial code of the smartphone or information on the device server 60 to which the smartphone belongs. The information identifying the multiple vehicles 20 belonging to the owner is, for example, the vehicle ID of 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 multiple vehicles 20 for which the owner key is to be registered. Then, the management server 70 collectively transmits key information DK for the multiple identified vehicles 20 to the portable device that is the owner device 40. At this time, the key information DK can be transmitted from the management server 70 to the owner device 40 via the device server 60 to which the owner device 40 belongs. In this way, 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.

[0080] In this way, the management server 70 identifies the multiple vehicles 20 belonging to the owner based on the identification information of 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 the information 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 of generating digital keys for the multiple vehicles 20 for the owner device 40 based on a single registration request D21.

[0081] Such a management server 70 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, it may be a central ECU that manages multiple ECUs in the vehicle 20.

[0082] 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). The vehicle management device 26 may also be configured as a 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, or a combination thereof. 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 the 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.

[0083] The device 30, which is a mobile device, is not limited to a smartphone and may be a smart watch. 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.

[0084] Digital keys have a hierarchy of owner keys (KO), friend keys (KF), and non-friend keys (KN), with the higher the hierarchy, the greater the authority. Digital keys do not have to have greater authority the higher the hierarchy. For example, the same authority level may be set for the three hierarchies of owner keys (KO), friend keys (KF), and non-friend keys (KN).

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

[0086] The management server 70 may be configured with multiple servers. For example, it 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. Alternatively, it 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.

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

[0088] The authentication information AT is not limited to the examples of the above embodiments, 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.

[0089] The configuration of the information included in the key information DK is not limited to the example in the above embodiment. For example, the owner key information DKO does not have to include the slot identification information ST4. Also, for example, 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.

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

[0091] The structure of the data DA in the database DB is not limited to the examples in the above embodiments, as long as the database DB contains the information necessary for the management server 70 in the management system 10 to manage it.

[0092] In the database DB, the authority may be set for each digital key, rather than being uniformly determined according to the type of digital key. Also, the authority may not be determined in the database DB.

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

[0094] The digital key-related matters in the above embodiments do not have to comply with the CCC. <Technical philosophy> The technical ideas that can be understood from the above-described embodiment and modified examples will be described.

[0095] [Appendix 1] A management server that constitutes part of a vehicle digital key management system and manages information about the digital key stored in the device, an execution device; an owner device that is the device belonging to the owner of the vehicle; and a communication device that communicates with the vehicle; When the execution device receives a registration request requesting the start of the digital key registration process, the management server identifies the owner device and multiple vehicles, sends information about the digital keys for each of the multiple vehicles to the owner device using the communication device, and causes the management system to start the process of generating the digital keys for each of the multiple vehicles to be registered to the owner device.

[0096] [Appendix 2] A management server as described in Appendix 1, which includes a storage device storing contract information including information identifying the owner device belonging to the owner and information identifying the multiple vehicles belonging to the owner, and which, upon receiving a registration request including information identifying the contract information as the registration request, identifies the owner device and the multiple vehicles by referring to the contract information stored in the storage device, sends information regarding the digital keys for each of the multiple vehicles to the owner device using the communication device, and causes 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.

[0097] [Appendix 3] The contract information includes contract identification information attached to the contract for the plurality of vehicles, The management server according to claim 2, wherein the information identifying the contract information is contract identification information attached to a contract for the plurality of vehicles.

[0098] [Appendix 4] The management server according to appendix 2, wherein the information identifying the contract information is a list of identification information of the plurality of vehicles. [Appendix 5] The contract information includes contract holder information that identifies the owner, 3. The management server according to claim 2, wherein the information for identifying the contract information is contract holder information for identifying the owner.

[0099] [Appendix 6] The management server described in Appendix 1, which, when the executing device receives the registration request including information that identifies the owner device and identification information of the multiple vehicles belonging to the owner, identifies the owner device and the multiple vehicles, sends information about the digital keys of each of the multiple vehicles to the owner device using the communication device, and causes the management system to start the generation process of the digital keys of each of the multiple vehicles to be registered to the owner device.

[0100] [Supplementary Note 7] The management server according to any one of Supplementary Notes 1 to 6, wherein the execution device transmits a generation start notification to the owner device using the communication device, notifying that the generation process has started.

[0101] [Appendix 8] The management server according to Appendix 7, wherein the execution device sends the generation start notification to the owner device when the generation process of the digital key for each vehicle starts.

[0102] [Appendix 9] The management server described in Appendix 7, wherein the execution device sends 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 for all of the plurality of vehicles has started.

[0103] [Appendix 10] The management server according to any one of Appendices 1 to 9, wherein the execution device sends a registration completion notification to the owner device using the communication device, notifying that the registration process has been completed.

[0104] [Appendix 11] The management server according to Appendix 10, wherein the execution device sends the registration completion notification to the owner device when the registration process for the digital key for each vehicle is completed.

[0105] [Appendix 12] The management server according to any one of Appendices 1 to 11, wherein the execution device uses the communication device to notify the owner device of a registration failure notification that the registration process has failed.

[0106] [Appendix 13] The management server according to Appendix 12, wherein the execution device notifies the owner device of the registration failure notification for each vehicle when the registration process for the digital key fails.

[0107] [Appendix 14] A management server as described in any one of Appendices 1 to 13, wherein the execution device sends a completion notification to the owner device indicating that the registration process of the digital keys for all of the plurality of vehicles has been completed after the registration process of the digital keys for all of the plurality of vehicles has been completed.

[0108] [Appendix 15] The management server according to Appendix 14, wherein the execution device transmits the completion notification to the owner device, the completion notification including information on the success or failure of the registration process for each of the plurality of vehicles. [Explanation of symbols]

[0109] 10...management system, 20, 20A, 20B, 20C, 20D...vehicle, 26...vehicle management device, 27...execution device, 28...storage device, 30...device, 30V...virtual device, 36...execution device, 37...storage device, 40...owner device, 50...shared device, 51...friend device, 52...non-friend device, 60...device server, 70...management server, 71...execution device, 72...storage device, 73...communication module, 80...server, 90...network, AT...authentication information, CI...contract information, DK...key information, DKO...owner key information, DKS...shared key information, KF...friend key, KN...non-friend key, KO...owner key, KS...shared key, PN...notification program

Claims

1. a management server that constitutes part of a vehicle digital key management system and manages information related to the digital key stored in the device; an execution device; an owner device that is the device belonging to an owner of the vehicle and a communication device that communicates with the vehicle; The execution device: Upon receiving a registration request requesting the start of the digital key registration process, Identifying the owner device and a plurality of vehicles, transmitting information about the digital keys of the respective vehicles to the owner device using the communication device, and causing the management system to start a process of generating the digital keys of the respective vehicles to be registered in the owner device. Management server.

2. a storage device storing contract information including information identifying the owner device belonging to the owner and information identifying the plurality of vehicles belonging to the owner; The execution device: Upon receiving the registration request including information identifying the contract information as the registration request, The owner device and the plurality of vehicles are identified by referring to the contract information stored in the storage device, and information regarding the digital keys of the plurality of vehicles is transmitted to the owner device using the communication device, and the management system is caused to start the process of generating the digital keys of the plurality of vehicles to be registered in the owner device. The management server according to claim 1 .

3. the contract information includes contract identification information attached to the contracts for the plurality of vehicles, The information for identifying the contract information is contract identification information attached to the contract for the plurality of vehicles. The management server according to claim 2 .

4. The information for identifying the contract information is a list of identification information of the plurality of vehicles. The management server according to claim 2 .

5. The contract information includes contract holder information that identifies the owner, The information for identifying the contract information is contract holder information for identifying the owner. The management server according to claim 2 .

6. The execution device: Upon receiving the registration request including information for identifying the owner device and identification information of the plurality of vehicles belonging to the owner, Identifying the owner device and the plurality of vehicles, transmitting information about the digital keys of the respective vehicles to the owner device using the communication device, and causing the management system to start the process of generating the digital keys of the respective vehicles to be registered in the owner device. The management server according to claim 1 .

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

8. The execution device transmits the generation start notification to the owner device when the generation process of the digital key for each vehicle starts. The management server according to claim 7.

9. After the generation process for all of the plurality of vehicles has started, the execution device transmits the generation start notification to the owner device, the notification indicating that the generation process for all of the plurality of vehicles has started. The management server according to claim 7.

10. The execution device transmits a registration completion notification to the owner device using the communication device, notifying that the registration process has been completed. The management server according to any one of claims 1 to 6.

11. The execution device transmits the registration completion notification to the owner device when the registration process of the digital key for each vehicle is completed. The management server according to claim 10.

12. The execution device sends a registration failure notification to the owner device using the communication device, notifying that the registration process has failed. The management server according to any one of claims 1 to 6.

13. The execution device notifies the owner device of the registration failure notification for each vehicle when the registration process of the digital key fails. The management server according to claim 12.

14. After the registration process for the digital keys for the plurality of vehicles is completed, the execution device transmits a completion notification to the owner device indicating that the registration process for the digital keys for all of the plurality of vehicles has been completed. The management server according to any one of claims 1 to 6.

15. The execution device transmits the completion notification, which includes information on the success or failure of the registration process for each of the plurality of vehicles, to the owner device. The management server of claim 14.

Images