Vehicle

Abstract

To provide a car capable of performing validation processing of an owner key even in an virtual device where owner devices are constructed on a server.SOLUTION: The vehicle comprises a wireless communication device, a near field communication device, and an execution device configured to perform a digital key registration process. The vehicle receives the owner key registration request from the management server. When the received register request includes information indicating that the owner devices are the virtual device constructed on the server (S402: YES), the execution device in the vehicle performs an owner key validation process through wireless communication using the wireless communication device (S406, S407). When the received register request does not include the information indicating that the owner devices are the virtual device constructed on the server (S402: NO), the execution device in the vehicle performs an owner key validation process through proximity communication using the proximity communication device (S413, S414).SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001] The present invention relates to vehicles. [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 in which an owner device having an owner key registers a friend key to a plurality of friend devices selected on the device.

[0004] In this way, an owner device with an owner key registered has the ability to issue a friend key. The owner key is authenticated using proximity communication between the owner device and the vehicle. This authentication validates the owner key, allowing the owner device to be used as a digital key to unlock and start the vehicle and issue a friend key. [Prior art documents] [Patent documents]

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

[0006] Depending on the type of owner device, the activation method of authentication by proximity communication may not be suitable. [Means for solving the problem]

[0007] A vehicle that solves the above problem includes a wireless communication device that can communicate via a wireless communication network with a device in which a digital key can be registered and a management server that manages the digital key. The vehicle also includes a proximity communication device that can communicate with the device via proximity communication, and an execution device that performs digital key registration processing. Of the digital keys, the digital key that is registered to an owner device that belongs to the owner of the vehicle is an owner key. The vehicle receives an owner key registration request from the management server. If the received registration request includes information indicating that the owner device to which the owner key is to be registered is a virtual device built on the server, the execution device of the vehicle performs owner key activation processing via wireless communication using the wireless communication device. If the execution device of the vehicle receives a registration request from the management server that does not include information indicating that the owner device to which the owner key is to be registered is a virtual device built on the server, the execution device of the vehicle performs owner key activation processing via proximity communication. [Effects of the Invention]

[0008] According to the above vehicle, even if the owner device is a virtual device constructed on a server, the owner key can be validated. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a schematic diagram illustrating a digital key management system. [Figure 2] FIG. 2 is a schematic diagram illustrating a configuration of a management server. [Figure 3] FIG. 2 is a schematic diagram showing the configuration of an owner device that is a portable information terminal. [Figure 4] FIG. 1 is a schematic diagram illustrating the configuration of an owner device that is a virtual machine built on a server. [Figure 5] FIG. 2 is a schematic diagram illustrating a configuration of a friend device. [Figure 6] FIG. 1 is a schematic diagram illustrating the configuration of a non-friend device. [Figure 7] FIG. 1 is a schematic diagram showing the configuration of a vehicle. [Figure 8] FIG. 2 is a schematic diagram showing owner key information. [Figure 9] FIG. 2 is a schematic diagram showing data in a database of a management server. [Figure 10] FIG. 10 is a sequence diagram of an owner key registration process when the owner device is a mobile information terminal. [Figure 11] FIG. 10 is a sequence diagram of an owner key registration process when the owner device is a virtual machine. [Figure 12] 10 is a flowchart of a process executed by a management server in an owner key registration process. [Figure 13] 3 is a schematic diagram of contract information stored in a storage device of a management server. FIG. [Figure 14] 10 is a flowchart of a process executed by a vehicle that receives a request to register an owner key. DETAILED DESCRIPTION OF THE INVENTION

[0010] An embodiment of a management system including a vehicle 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.

[0011] <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, a management server 70, and a server 80. The plurality of vehicles 20, the plurality of devices 30, the device server 60, the management server 70, and the server 80 can communicate with each other via a network 90. ​​The network 90 is a wireless communication network.

[0012] 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 wireless communication device that wirelessly communicates with the device 30, the vehicle 20, and the server 80. The storage device 72 stores a server program PS, a startup program PB, and a database DB. When the execution device 71 executes the server program PS, the execution device 71 registers a digital key in the database DB and deletes the digital key from the database DB. When the execution device 71 executes the startup program PB, the execution device 71 generates and notifies the vehicle 20 of a command to activate the vehicle 20's equipment required for digital key authentication. 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 in which key information DK indicating the digital key is stored.

[0013] 1, 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 not only mobile information terminals such as smartphones, but also virtual machines built on a server 80. Hereinafter, the owner device 40 that is a mobile information terminal will be referred to as a mobile device 40M, and the owner device 40 that is a virtual machine will be referred to as a virtual device 40V.

[0014] 3, the mobile device 40M includes a communication module 31, an HMI 32, a BLE module 33, a UWB module 34, an NFC module 35, an execution device 36, and a storage device 37. HMI stands for Human Machine Interface. BLE stands for Bluetooth Low Energy. UWB stands for Ultra Wide Band. NFC stands for Near Field Communication.

[0015] The communication module 31 is a wireless communication device that performs wireless communication via the network 90. ​​The HMI 32 includes an input device that accepts operations by the user of the portable device 40M, and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

[0016] The BLE module 33 performs short-range communication with the vehicle 20 using BLE communication. The UWB module 34 performs short-range communication with the vehicle 20 using UWB communication. The NFC module 35 performs short-range communication with the vehicle 20 using NFC communication. The BLE module 33, the UWB module 34, and the NFC module 35 are all close-range communication devices.

[0017] The storage device 37 stores a device program PD and key information DK. The device program PD is executed by the execution device 36, causing the execution device 36 to store and delete the key information DK. The key information DK is information indicating a digital key.

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

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

[0020] 4, the virtual device 40V includes a communication module 31, an execution device 36, and a storage device 37. The communication module 31, execution device 36, and storage device 37 of the virtual device 40V can be virtual devices that use a portion of the area of ​​the communication module 31, execution device 36, and storage device 37 of the server 80. The storage device 37 stores a device program PD and key information DK, similar to the portable device 40M. The execution device 36 executes the device program PD to perform processes related to the storage and deletion of the key information DK.

[0021] 5 and 6, 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.

[0022] The friend device 51 included in the share device 50 is, for example, a mobile information terminal such as a smartphone. As shown in FIG. 5 , the friend device 51, like the mobile device 40M, includes a communication module 31, an HMI 32, a BLE module 33, a UWB module 34, an NFC module 35, an execution device 36, and a storage device 37. 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.

[0023] The non-friend device 52 included in the shared device 50 is, for example, a mobile information terminal such as a smartphone. As shown in FIG. 6 , the non-friend device 52, like the mobile device 40M, includes a communication module 31, an HMI 32, a BLE module 33, a UWB module 34, an NFC module 35, an execution device 36, and a storage device 37. The storage device 37 stores a device program PD, key information DK, and shared key information DKS. In the non-friend device 52, the key information DK is non-friend key information DKN indicating a non-friend key.

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

[0025] 7, the vehicle 20 includes a communication module 21, an HMI 22, a BLE module 23, a UWB module 24, an NFC module 25, and a vehicle management device 26. The communication module 21 is a wireless communication device that performs wireless communication with a management server 70 via a network 90. ​​The HMI 22 includes an input device that accepts operations by the user of the vehicle 20, and a presentation device that presents information to the user using images, audio, etc. The presentation device is, for example, a monitor and a speaker.

[0026] The BLE module 23 performs short-range communication with the device 30 via BLE communication. The UWB module 24 performs short-range communication with the device 30 via UWB communication. The UWB module 24 measures the distance between the device 30 and the vehicle 20. The NFC module 25 performs short-range communication with the device 30 via NFC communication. The BLE module 23, the UWB module 24, and the NFC module 25 are all near-field communication devices. 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.

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

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

[0029] 1 relays communication between devices 30, which are mobile information terminals, and a 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.

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

[0031] The portable device 40M and the virtual device 40V store owner key information DKO. As shown in Fig. 8, 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, and slot identification information ST4. The owner key structure information STO includes certificate information ST5, device public key information ST6, vehicle public key information ST7, and permission public key information ST8.

[0032] The vehicle identification information ST1 is information for identifying the vehicle 20 for which the digital key is to be set, for example, 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.

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

[0034] Certificate information ST5 indicates a certificate that certifies the digital key. Device public key information ST6 indicates a device public key PKD, which is the public key of the device 30. Note that the device public key PKD in the owner key information DKO indicates the public key of the owner device 40. Vehicle public key information ST7 indicates a vehicle public key PKV, which is the public key of the vehicle 20. Authorization public key information ST8 indicates a vehicle public key PKV that has already been authorized.

[0035] As shown in Figure 9, 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.

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

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

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

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

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

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

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

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

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

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

[0046] <Digital key registration> Next, a series of processes for registering a digital key 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 a digital key. First, a series of processes for registering and activating the owner key KO in the portable device 40M will be described below. Next, a series of processes for registering and activating the owner key KO in the virtual device 40V will be described below. In addition, hereinafter, the processing performed by the execution device 27 of the vehicle 20 will be described as processing performed by the vehicle 20. In addition, the processing performed by the execution device 36 of the portable device 40M and the virtual device 40V will be described as processing performed by the portable device 40M and the virtual device 40V. The processing performed by the execution device 71 of the management server 70 will be described as processing performed by the management server 70.

[0047] <Registering the owner key KO to the mobile device 40M> 10, the management system 10 performs a series of processes for registering the owner key KO in the portable device 40M. The portable device 40M, which is a conventional owner device 40, activates the owner key KO using proximity communication with the vehicle 20.

[0048] In the management system 10, by registering the owner key KO, owner key information DKO, which is key information DK indicating the owner key KO of the vehicle 20, is stored in the portable device 40M. 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 registered in the management server 70, the owner key KO is validated.

[0049] As shown in FIG. 10 , when the management server 70 receives a registration start request D11 for the owner key KO from the portable device 40M, the registration process for the owner key KO is started. The registration start request D11 includes owner device identification information, which will be described later. In step S111, the management server 70 generates a pairing password PAS used for pairing the portable device 40M and the vehicle 20. Thereafter, the management server 70 transmits information indicating the pairing password PAS to the portable device 40M using the communication module 73. The management server 70 transmits a registration request D12 including information indicating the pairing password PAS to the vehicle 20 using the communication module 73. In step S112, the vehicle 20 that has received the registration request D12 activates devices required for authenticating the owner key KO using a near-field communication device. These devices are, for example, the BLE module 23, the UWB module 24, the NFC module 25, and a digital key ECU provided in the vehicle management device 26. By activating these devices, the vehicle 20 can wait for and perform authentication of the digital key using the proximity communication device.

[0050] Next, in step S113, when the owner of the vehicle 20 approaches the vehicle 20 while holding the portable device 40M that has received the pairing password PAS, pairing between the vehicle 20 and the portable device 40M is performed using a proximity communication device. Pairing may be performed using at least one of the BLE module 23, the UWB module 24, and the NFC module 25. At this time, if authentication using the pairing password PAS possessed by the portable device 40M and the vehicle 20, respectively, is successful, pairing is completed. When pairing is completed, a secure channel for data communication is established between the vehicle 20 and the portable device 40M using the proximity communication device. Thereafter, the vehicle 20 proceeds to step S114. From this point on, communication between the vehicle 20 and the portable device 40M until the owner key KO is activated is performed using this secure channel.

[0051] In step S114, the vehicle 20 generates a vehicle public key PKV, which is the public key of the vehicle 20, and a vehicle private key SKV, which is the private key of the vehicle 20. Next, the vehicle 20 transmits generation data DC for generating an owner key KO to the portable device 40M via a secure channel. The generation data DC includes vehicle identification information ST1 and vehicle public key information ST7 indicating the vehicle public key PKV. Upon receiving the generation data DC, the portable device 40M proceeds to step S115.

[0052] In step S115, the portable device 40M generates owner key information DKO indicating the owner key KO. Next, in step S116, the portable device 40M stores the owner key information DKO. Thereafter, the portable device 40M transmits, to the vehicle 20, certificate information ST5 related to the owner key KO and device public key information ST6 indicating the device public key PKD.

[0053] When vehicle 20 receives certificate information ST5 and device public key information ST6, vehicle 20 performs the process of step S117. In step S117, vehicle 20 verifies certificate information ST5. When verification of certificate information ST5 is completed, vehicle 20 proceeds to the process of step S118.

[0054] In step S118, the vehicle 20 stores the device public key information ST6 indicating the device public key PKD as the authentication information AT. Then, the vehicle 20 transmits an authentication completion notification D13 to the portable device 40M indicating that the storage of the authentication information AT has been completed.

[0055] When the portable device 40M receives the authentication completion notification D13, the portable device 40M performs the process of step S119. In step S119, the portable device 40M generates a key track request D14 for the owner key KO. The key track request D14 is a signal requesting the management server 70 to update the database DB. Then, the portable device 40M transmits the key track request D14 for the owner key KO to the management server 70 via the device server 60.

[0056] When the management server 70 receives the key track request D14, it performs processing in step S120. In step S120, the management server 70 performs registration management of the owner key KO. Specifically, the management server 70 stores the portable device 40M as a device 30 in which the owner key KO is registered in the data DA of the vehicle 20 in the database DB. This completes the series of processes in the management system 10 for registering and activating the owner key KO in the portable device 40M. The process from pairing in step S113 to activation of the owner key KO in step S120 is the activation process when registering the owner key KO in the portable device 40M.

[0057] <Registering the owner key KO to the virtual device 40V> 11, the management system 10 performs a series of processes for registering the owner key KO in the virtual device 40V. The virtual device 40V, which is the owner device 40 constructed in the server 80, does not perform near-field communication with the vehicle 20, but activates the owner key KO using wireless communication.

[0058] In the management system 10, by registering the owner key KO, owner key information DKO, which is key information DK indicating the owner key KO of the vehicle 20, is stored in the virtual device 40V. 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 registered in the management server 70, the owner key KO is validated.

[0059] 11, when the management server 70 receives a registration start request D21 for the owner key KO from the virtual device 40V, the registration process for the owner key KO is started. Upon receiving the registration start request D21, the management server 70 transmits key generation information DKC for generating the owner key KO to the virtual device 40V. The registration start request D21 includes owner device identification information, which will be described later. The key generation information DKC includes information corresponding to vehicle identification information ST1 and vehicle public key information ST7 indicating the vehicle public key PKV. Upon receiving the key generation information DKC, the virtual device 40V advances the process to step S211.

[0060] In step S211, the virtual device 40V generates owner key information DKO indicating the owner key KO. Next, in step S212, the virtual device 40V stores the owner key information DKO. Thereafter, the virtual device 40V transmits to the management server 70 an authentication request D22 for the owner key KO, which includes certificate information ST5 related to the owner key KO and owner key authentication information DKA corresponding to device public key information ST6 indicating the device public key PKD.

[0061] Thereafter, the management server 70, which has received the authentication request D22, transmits a registration request D23 to the vehicle 20 using the communication module 73. The registration request D23 includes information indicating that the owner device 40 to which the owner key KO is to be registered is the virtual device 40V. For example, the registration request D23 includes owner device identification information. On the other hand, the above-mentioned registration request D12 does not include information indicating that the owner device 40 to which the owner key KO is to be registered is the virtual device 40V.

[0062] In step S213, the vehicle 20 that has received the registration request D23 activates the devices required to authenticate the owner key KO using the communication module 21. These devices are, for example, the communication module 21 and the digital key ECU provided in the vehicle management device 26. By activating these devices, the vehicle 20 can wait for and execute authentication of the digital key using the communication module 21.

[0063] Next, the management server 70 that sent the registration request D23 sends an authentication start request D24 for the owner key KO, including the owner key authentication information DKA, to the vehicle 20 using the communication module 73. Upon receiving the authentication start request D24, the vehicle 20 proceeds to step S214 and starts authenticating the owner key KO.

[0064] In step S214, vehicle 20 verifies owner key authentication information DKA. When verification of information included in owner key authentication information DKA and corresponding to certificate information ST5 is completed, vehicle 20 proceeds to step S215.

[0065] In step S215, vehicle 20 stores information corresponding to device public key information ST6 indicating device public key PKD as authentication information AT. After that, vehicle 20 transmits an authentication completion notification D25 indicating that storage of authentication information AT has been completed to management server 70 using communication module 21.

[0066] When the management server 70 receives the authentication completion notification D25, it performs processing of step S216. In step S216, the management server 70 performs registration management of the owner key KO. Specifically, the management server 70 stores the virtual device 40V as the device 30 in which the owner key KO is registered in the data DA of the vehicle 20 in the database DB. This causes the management system 10 to complete a series of processes for registering and activating the owner key KO in the virtual device 40V. The process from verifying the owner key authentication information DKA in step S214 to activating the owner key KO in step S216 is the activation process when registering the owner key KO in the virtual device 40V.

[0067] <Processing of the management server 70 that transmits a registration request> In the above-described process of registering the owner key KO to the owner device 40, the management server 70 changes the process depending on whether the owner device 40 is a portable device 40M or a virtual device 40V. These processes are performed by the execution unit 71 executing the startup program PB stored in the storage device 72 of the management server 70. This process is performed when the management server 70 receives a registration start request D11 or a registration start request D21 from the owner device 40.

[0068] 12 shows a flowchart of the processing executed by the management server 70. First, in step S301, the management server 70 refers to the classification information TI included in the contract information CI. The contract information CI is stored in the storage device 72 when the owner completes the contract for the vehicle 20. Therefore, when the management server 70 receives the registration start request D11 or the registration start request D21 from the owner device 40, the management server 70 has stored the contract information CI in the storage device 72.

[0069] As shown in FIG. 13 , the contract information CI includes classification information TI, which is information indicating whether the owner device 40 is a virtual device 40V or a portable device 40M. The contract information CI also includes owner device identification information for identifying the owner device 40 and a vehicle ID for identifying the vehicle 20. When the owner device 40 is a virtual device 40V, the owner device identification information is information for identifying the virtual device 40V and the server 80 in which the virtual device 40V exists in the network 90. ​​This owner device identification information is, for example, the IP addresses of the virtual device 40V and the server 80, or authentication information of a certificate issued by the server 80. When the owner device 40 is a portable device 40M, the owner device identification information is information for identifying the portable device 40M and the device server 60 to which the portable device 40M belongs in the network 90. ​​This over-device identification information is, for example, the IP addresses of the portable device 40M and the device server 60, or a serial code of the portable device 40M. The management server 70 refers to the classification information TI to obtain information on whether the owner device 40 is a virtual device 40V or a portable device 40M. Then, in step S302, the management server 70 determines whether the owner device 40 to register the owner key KO is a virtual device 40V. If the management server 70 determines in step S302 that the owner device 40 is a virtual device 40V (step S302: YES), the processing proceeds to step S303.

[0070] Next, in step S303, the management server 70 transmits an owner key KO registration request D23, which includes information indicating that the owner device 40 is a virtual device 40V, to the vehicle 20. Thereafter, in step S304, the management server 70 transmits an authentication start request D24 to the vehicle 20. As shown in Fig. 11 , when the management server 70 transmits the authentication start request D24 to the vehicle 20, authentication processing of the owner key KO in the vehicle 20 is started.

[0071] 12, in step S305, the management server 70 receives an authentication completion notification D25 from the vehicle 20. Then, upon receiving the authentication completion notification D25, the management server 70 proceeds to step S309. In step S309, the management server 70 performs registration management of the owner key KO, which corresponds to step S216 in FIG.

[0072] 12, when it is determined in step S302 that the owner device 40 is the portable device 40M (step S302: NO), the management server 70 proceeds to step S306. In step S306, the management server 70 transmits information indicating a pairing password PAS used for pairing using a proximity communication device to the portable device 40M. In step S307, the management server 70 transmits to the vehicle 20, using the communication module 73, a registration request D12 for the owner key K-O, which includes information indicating the pairing password PAS but does not include information indicating that the owner device 40 is a virtual device 40V. As shown in FIG. 10, after the management server 70 transmits the registration request D12 to the vehicle 20, pairing is performed between the vehicle 20 and the portable device 40M, and authentication processing for the owner key K-O is started.

[0073] 12, in step S308, the management server 70 receives the key track request D14 from the portable device 40M. Then, upon receiving the key track request D14, the management server 70 proceeds to step S309. In step S309, the management server 70 performs registration management of the owner key KO, which corresponds to step S120 in FIG.

[0074] As shown in FIG. 12, when the registration and management of the owner key KO is completed in step S309, the management server 70 ends the series of processes for registering the owner key KO. <Processing of the vehicle 20 that has received the registration request> In the above-described process of registering the owner key KO to the owner device 40, the vehicle 20 changes the process depending on whether the owner device 40 is the portable device 40M or the virtual device 40V.

[0075] 14 shows a flowchart of the process executed by the execution device 27 of the vehicle 20. This process is started when the vehicle 20 receives the registration request D12 or D23 from the management server 70.

[0076] In step S402, the vehicle 20 determines whether the owner device 40 to which the owner key KO is to be registered is a virtual device 40V. Specifically, the vehicle 20 determines that the owner device 40 is a virtual device 40V when the registration request D12 includes information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80. The registration request D12 does not include information indicating that the owner device 40 is a virtual device 40V. Therefore, when the vehicle 20 receives the registration request D12, the vehicle 20 determines that the owner device 40 is not a virtual device 40V. The registration request D23 includes information indicating that the owner device 40 is a virtual device 40V. Therefore, when the vehicle 20 receives the registration request D23, the vehicle 20 determines that the owner device 40 is a virtual device 40V.

[0077] If it is determined in step S402 that the owner device 40 is the virtual device 40V (step S402: YES), the vehicle 20 proceeds to step S403.

[0078] In step S403, the vehicle 20 starts up the equipment required for authentication using the communication module 21. This step corresponds to step S213 in FIG. 11. The vehicle 20 then proceeds to step S404 and waits for an authentication start request D24 from the management server 70. Then, in step S405, the vehicle 20 repeatedly executes the processes of steps S404 and S405 until the authentication start request D24 is received from the management server 70. In step S405, when the authentication start request D24 is received from the management server 70 (step S405: YES), the vehicle 20 proceeds to step S406.

[0079] In step S406, the vehicle 20 verifies the owner key authentication information DKA and stores the authentication information AT. This step corresponds to steps S214 and S215 in Fig. 11. Thereafter, in step S407, the vehicle 20 transmits an authentication completion notification D25 to the management server 70.

[0080] If it is determined in step S402 that the owner device 40 is not the virtual device 40V (step S402: NO), the vehicle 20 proceeds to step S408.

[0081] In step S408, the vehicle 20 waits for the switch of the vehicle 20 to be turned on. When the switch of the vehicle 20 is turned on, the system of the vehicle 20 starts up and the vehicle 20 begins to operate. The vehicle 20 repeatedly executes the processes of steps S408 and S409 until it is determined in step S409 that the switch of the vehicle 20 has been turned on. Then, when it is determined that the switch of the vehicle 20 has been turned on (step S409: YES), the vehicle 20 proceeds to the process of step S410.

[0082] In step S410, the vehicle 20 activates devices necessary for authentication using a proximity communication device. This step corresponds to step S112 in Fig. 10. When the activation of the above devices is completed, the vehicle 20 proceeds to step S411 and waits for pairing from the portable device 40M.

[0083] The vehicle 20 repeatedly executes the processes of steps S411 and S412 until it is determined in step S412 that pairing with the portable device 40M is completed. When it is determined that pairing is completed (step S412: YES), the vehicle 20 proceeds to the process of step S413.

[0084] In step S413, the vehicle 20 verifies the certificate information ST5 and stores the authentication information AT. This step corresponds to steps S117 and S118 in Fig. 10. Then, in step S414, the vehicle 20 transmits an authentication completion notification D13 to the portable device 40M.

[0085] When the process of either step S407 or step S414 is completed, the vehicle 20 ends the series of processes for registering the owner key KO. <Operation of this embodiment> If the owner device 40 is a virtual device 40V constructed on a server 80 connected to the network 90, the virtual device 40V cannot perform proximity communication with the vehicle 20. Therefore, the vehicle 20 cannot perform activation processing of the owner key KO using authentication through proximity communication. If the owner device 40 is a virtual device 40V, the vehicle 20 performs activation processing of the owner key KO through wireless communication using the communication module 21. If the owner device 40 is not a virtual device 40V, the vehicle 20 performs activation processing of the owner key KO through proximity communication.

[0086] <Effects of this embodiment> (1) According to the vehicle 20, even if the owner device 40 is a virtual device 40V constructed on the server 80, the owner key KO can be validated.

[0087] (2) Upon receiving the registration request D23 from the management server 70, the execution device 27 of the vehicle 20 activates the equipment used to activate the owner key KO via wireless communication. The registration request D23 includes information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80.

[0088] After receiving the registration request D23 including information indicating that the owner device 40 is a virtual device 40V, the vehicle 20 starts up the device used to activate the owner key KO via wireless communication. That is, when it is determined that activation is necessary, the vehicle 20 starts up the device used to activate the owner key KO via wireless communication.

[0089] According to the vehicle 20, power consumption can be reduced compared to when the device used for the validation process of the owner key KO via wireless communication is kept running and the vehicle 20 waits for the registration request D23 to be received.

[0090] (3) When the vehicle 20 receives the registration request D12 from the management server 70, the execution device 27 activates the proximity communication device and performs the activation process of the owner key KO through proximity communication. The registration request D12 does not include information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80.

[0091] If the owner device 40 is not a virtual device 40V on the server 80, the activation process can be performed by proximity communication with the vehicle 20 as in the conventional case. According to the vehicle 20, when the owner device 40 is not a virtual device 40V, the owner key KO can be activated by proximity communication in the conventional manner.

[0092] (4) After receiving the registration request D12 from the management server 70, the execution device 27 of the vehicle 20 activates the proximity communication device and performs the activation process of the owner key KO through proximity communication when the vehicle 20 is operating. The registration request D12 does not include information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80.

[0093] The activation process by proximity communication can be performed only when the owner device 40 is within the proximity communication range. When the vehicle 20 is operating, it is highly likely that the owner who possesses the owner device 40 is within the proximity communication range. The vehicle 20 activates the proximity communication device when the vehicle 20 is started and operating. In other words, the vehicle 20 activates the proximity communication device when it is highly likely that the owner who possesses the owner device 40 is within the proximity communication range.

[0094] According to the vehicle 20, power consumption can be reduced compared to when the proximity communication device is kept activated and the owner carrying the owner device 40 waits for the owner to enter a range where proximity communication can be performed.

[0095] (5) The execution device 27 of the vehicle 20 activates the NFC module 25 as a near-field communication device and performs the activation process of the owner key KO via NFC communication. The vehicle 20 can use NFC communication to perform activation processing of the owner key KO through near field communication.

[0096] (6) The execution device 27 of the vehicle 20 activates the UWB module 24 as a proximity communication device and performs the process of activating the owner key KO via UWB communication. The vehicle 20 can use UWB communication to perform the activation process of the owner key KO through near field communication.

[0097] (7) The execution device 27 of the vehicle 20 activates the BLE module 23 as a proximity communication device and performs the activation process of the owner key KO via BLE communication. The vehicle 20 can use BLE communication to perform the activation process of the owner key KO through proximity communication.

[0098] (8) The management server 70 constitutes part of a digital key system that activates digital keys using information about the digital keys stored in the vehicle 20 and information about the digital keys stored in the device 30, and manages the digital keys. Among the digital keys, the digital key registered in the owner device 40, which is the device 30 belonging to the owner of the vehicle 20, is the owner key KO. The management server 70 includes an execution device 71 and a communication module 73, which is a wireless communication device that communicates with the owner device 40 and the vehicle 20. The execution device 71 references classification information TI indicating whether the owner device 40 in which the owner key KO is to be registered is a virtual device 40V constructed on the server 80. The management server 70 determines whether the owner device 40 in which the owner key KO is to be registered is a virtual device 40V constructed on the server 80. If the management server 70 determines that the owner device 40 in which the owner key KO is to be registered is a virtual device 40V constructed on the server 80, it transmits a registration request D23 to the vehicle 20 using the communication module 73. The registration request D23 includes information indicating that the owner device 40 in which the owner key KO is to be registered is a virtual device 40V constructed on the server 80.

[0099] The management server 70 determines from the classification information TI whether the owner device 40 in which the owner key KO is to be registered is a virtual device 40V. If the owner device 40 is a virtual device 40V, the management server 70 transmits a registration request D23 including information indicating that the owner device 40 is a virtual device 40V to the vehicle 20. The management server 70 can inform the vehicle 20 that the owner device 40 in which the owner key KO is to be registered is a virtual device 40V.

[0100] (9) The execution device 71 of the management server 70 transmits to the vehicle 20 a registration request D23 including information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80. In this case, the management server 70 transmits to the vehicle 20, using the communication module 73, information regarding the owner key KO required for authenticating the owner key KO.

[0101] When the owner device 40 registering the owner key KO is a virtual device 40V, the management server 70 transmits to the vehicle 20 information about the owner key KO used to authenticate the owner key KO in the vehicle 20. According to the management server 70, when the owner device 40 is a virtual device 40V, the information necessary for authenticating the owner key KO can be transmitted to the vehicle 20 using the communication module 73.

[0102] (10) If the execution device 71 of the management server 70 determines that the owner device 40 to which the owner key KO is to be registered is not a virtual device 40V constructed on the server 80, it transmits a registration request D12 to the vehicle 20 using the communication module 73. The registration request D12 does not include information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80.

[0103] If the owner device 40 performing the registration process is not a virtual device 40V, the management server 70 transmits to the vehicle 20 a registration request D12 that does not include information indicating that the owner device 40 is a virtual device 40V. The management server 70 can inform the vehicle 20 that the owner device 40 to which the owner key KO of the vehicle 20 is to be registered is not a virtual device 40V.

[0104] (11) The execution device 71 of the management server 70 transmits to the vehicle 20 a registration request D12 that does not include information indicating that the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80. In this case, the management server 70 transmits to the vehicle 20, using the communication module 73, the registration request D12 that includes a pairing password PAS required for the activation process of the owner key KO through proximity communication between the owner device 40 and the vehicle 20. The management server 70 transmits to the owner device 40, using the communication module 73, the pairing password PAS required for the activation process of the owner key KO through proximity communication between the owner device 40 and the vehicle 20.

[0105] When the owner device 40 to which the owner key KO is registered is not a virtual device 40V, the management server 70 transmits a pairing password PAS to both the owner device 40 and the vehicle 20. The pairing password PAS is used for pairing the owner device 40 and the vehicle 20 in the process of activating the owner key KO through proximity communication. When the management server 70 pairs the owner device 40 and the vehicle 20, authentication of the owner key KO through proximity communication is initiated. In other words, when the owner device 40 is not a virtual device 40V, the management server 70 can transmit information required for authenticating the owner key KO using proximity communication to the owner device 40 and the vehicle 20.

[0106] (12) The management server 70 includes a storage device 72 that stores contract information CI, which includes classification information TI, information identifying the owner device 40, and information identifying the vehicle 20 belonging to the owner. The execution device 71 of the management server 70 references the contract information CI stored in the storage device 72 to acquire the classification information TI.

[0107] The management server 70 refers to the contract information CI to acquire the classification information TI. Therefore, the management server 70 can determine whether the owner device 40 is a virtual device 40V based on the contract information CI stored in the storage device 72.

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

[0109] The vehicle 20 uses the NFC module 25, the UWB module 24, and the BLE module 23 as proximity communication devices to authenticate the owner key KO. The vehicle 20 may use only one or two of the above proximity communication devices to authenticate the owner key KO. The vehicle 20 may also perform authentication by proximity communication using proximity communication devices other than those described above. For example, the vehicle 20 may perform authentication of the owner key KO using Wi-Fi communication. Of course, the above proximity communication devices may be combined with Wi-Fi communication to perform authentication of the owner key KO by proximity communication.

[0110] The management server 70 acquires the classification information TI by referencing the contract information CI stored in the storage device 72. The management server 70 may acquire the classification information TI without referencing the contract information CI. The execution device 71 of the management server 70 acquires the classification information TI by referencing the classification information TI included in the registration start requests D11 and D21 sent from the owner device 40 to the management server 70 to request the start of the registration process. The execution device 71 of the management server 70 can then determine whether the owner device 40 to which the owner key KO is to be registered is a virtual device 40V constructed on the server 80.

[0111] The management server 70 acquires the classification information TI included in the registration start requests D11 and D21. Therefore, the management server 70 can determine whether the owner device 40 is a virtual device 40V based on the registration start requests D11 and D21.

[0112] The management server 70 transmits the registration request D23, including information indicating that the owner device 40 is the virtual device 40V, to the vehicle 20 after the authentication request D22 in FIG. 11 and before the authentication start request D24. The management server 70 may transmit the registration request D23 to the vehicle 20 at a timing other than the above. For example, the management server 70 can transmit the registration request D23 immediately after the contract information CI of the vehicle 20 is written to the storage device 72. This management server 70 can notify the vehicle 20 whether the registration process of the owner key KO is for the virtual device 40V as the owner device 40 immediately after the contract information CI is stored. For example, the management server 70 can transmit the registration request D23 upon receiving the registration start request D21 from the virtual device 40V. This management server 70 can notify the vehicle 20 whether the registration process of the owner key KO is for the virtual device 40V as the owner device 40 when the management server 70 receives the registration start request D21 from the owner device 40.

[0113] The management server 70 transmits the registration request D12, which includes information indicating that the owner device 40 is the portable device 40M, at the same time as transmitting the pairing password PAS to the vehicle 20 in Fig. 10. The management server 70 may transmit the registration request D12 to the vehicle 20 at a timing other than the above. For example, the management server 70 may transmit the registration request D12 immediately after the contract information CI of the vehicle 20 is written to the storage device 72.

[0114] According to such a management server 70, immediately after the contract information CI is stored, it is possible to notify the vehicle 20 whether the registration process of the owner key KO is for the virtual device 40V as the owner device 40.

[0115] The management server 70 can transmit the registration request D12 upon receiving the registration start request D21 from the portable device 40M. When the management server 70 receives the registration start request D21 for the owner key KO from the owner device 40, the management server 70 can notify the vehicle 20 whether the registration process for the owner key KO is for the virtual device 40V as the owner device 40.

[0116] In addition to the above, the management server 70 can transmit the registration requests D12 and D23 to the vehicle at any timing before the authentication process for the owner key KO is started. 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.

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

[0118] The device 30 and the mobile device 40M, which are mobile information terminals, are not limited to smartphones and may be smart watches. The virtual device 40V may be configured to be included in a predetermined server such as the server 80. For example, the virtual device 40V may be included in the management server 70. Similarly, the friend device 51 may be included in a predetermined server.

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

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

[0121] 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 startup program PB. Alternatively, for example, 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.

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

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

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

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

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

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

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

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

[0130] [Appendix 1] A vehicle equipped with a wireless communication device capable of communicating with a device capable of registering a digital key and a management server that manages the digital key via a wireless communication network, a near-field communication device capable of communicating with the device via near-field communication, and an execution device that performs registration processing of the digital key, A vehicle in which, among the digital keys, the digital key registered to an owner device, which is a device belonging to the owner of the vehicle, is an owner key, and when a registration request for the owner key received from the management server includes information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, the execution device performs an activation process for the owner key by wireless communication using the wireless communication device, and when a registration request is received from the management server that does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, the execution device performs an activation process for the owner key by near-field communication.

[0131] [Supplementary Note 2] The execution device activates a device used for activating the owner key via wireless communication when the execution device receives from the management server the registration request including information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server. [Appendix 3] A vehicle as described in Appendix 1 or Appendix 2, in which when a registration request is received from the management server that does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, the execution device activates the near-field communication device and performs an activation process for the owner key through the near-field communication.

[0132] [Appendix 4] A vehicle as described in Appendix 3, in which, after receiving from the management server the registration request that does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, when the vehicle is operating, the execution device starts the near-field communication device and performs the activation process of the owner key through the near-field communication.

[0133] [Appendix 5] The vehicle described in Appendix 3 or Appendix 4, wherein the execution device activates an NFC module as the near-field communication device and performs activation processing of the owner key via NFC communication. [Supplementary Note 6] The vehicle according to any one of Supplementary Note 3 to Supplementary Note 5, wherein the execution device activates a UWB module as the near-field communication device and performs the activation process of the owner key by UWB communication.

[0134] [Supplementary Note 7] The vehicle according to any one of Supplementary Note 3 to Supplementary Note 6, wherein the execution device activates a BLE module as the proximity communication device and performs the activation process of the owner key through BLE communication.

[0135] [Appendix 8] A management server that configures a part of a digital key system that activates the digital key using information about the digital key stored in the vehicle and information about the digital key stored in the device, and manages the digital key; Among the digital keys, the digital key registered in an owner device that belongs to the owner of the vehicle is an owner key, and the system includes an execution device and a wireless communication device that communicates with the owner device and the vehicle, The execution device refers to classification information indicating whether the owner device in which the owner key is to be registered is a virtual device constructed on a server, and determines whether the owner device in which the owner key is to be registered is a virtual device constructed on a server.If the execution device determines that the owner device in which the owner key is to be registered is a virtual device constructed on a server, the execution device sends a registration request to the vehicle using the wireless communication device, the management server including information indicating that the owner device in which the owner key is to be registered is a virtual device constructed on a server.

[0136] [Supplementary Note 9] When the execution device transmits to the vehicle the registration request including information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on a server, the execution device transmits to the vehicle, using the wireless communication device, information about the owner key required for authenticating the owner key. [Appendix 10] A management server as described in Appendix 8 or Appendix 9, wherein if the execution device determines that the owner device to which the owner key is to be registered is not a virtual device constructed on a server, the execution device sends the registration request to the vehicle using the wireless communication device, the registration request not including information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on a server.

[0137] [Appendix 11] When the execution device sends the registration request to the vehicle that does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on a server, the execution device uses the wireless communication device to send to the vehicle the registration request that includes a pairing password required for activating the owner key through proximity communication between the owner device and the vehicle, and sends to the owner device using the wireless communication device the pairing password required for activating the owner key through proximity communication between the owner device and the vehicle.

[0138] [Supplementary Note 12] A storage device is provided in which contract information including the classification information, information identifying the owner device, and information identifying the vehicle belonging to the owner is stored; 12. The management server according to claim 8, wherein the execution device acquires the classification information by referring to the contract information stored in the storage device.

[0139] [Appendix 13] A management server described in any one of Appendices 8 to 11, in which the execution device refers to the classification information included in a registration start request that requests the start of the registration process sent from the owner device to the management server, and determines whether the owner device in which the owner key is to be registered is a virtual device constructed on the server. [Explanation of symbols]

[0140] 10...Management system 20...Vehicle 21...Communication module 23...BLE module 24...UWB module 25...NFC module 26...Vehicle management device 27...Execution device 28…Storage device 30…Devices 40...Owner device 40M…Mobile devices 40V...Virtual Device 70...Administration server 71...Execution device 72…Storage device 73...Communication module 80...Server 90…Network CI...Contract Information D12, D23...Registration request KF...Friend Key KN...Non-Friend Key KO…Owner key PAS...Pairing password TI…Classification information

Claims

1. a wireless communication device capable of communicating with a device capable of registering a digital key and a management server that manages the digital key via a wireless communication network; a proximity communication device capable of communicating with the device through proximity communication; an execution device that performs registration processing of the digital key, Among the digital keys, the digital key registered in an owner device that belongs to the owner of the vehicle is an owner key, when the owner key registration request received from the management server includes information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on a server, the execution device performs a process of validating the owner key by wireless communication using the wireless communication device; When the execution device receives the registration request from the management server, the registration request does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, the execution device performs a process to validate the owner key by near-field communication. vehicle.

2. The execution device When the registration request includes information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, the device used for the validation process of the owner key via wireless communication is started. The vehicle of claim 1 .

3. When the execution device receives the registration request from the management server, the registration request does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, the execution device activates the near-field communication device and performs a process to validate the owner key through the near-field communication. The vehicle of claim 1 .

4. After receiving the registration request from the management server, which does not include information indicating that the owner device to which the owner key is to be registered is a virtual device constructed on the server, when the vehicle is in operation, the execution device starts the near-field communication device and performs an activation process for the owner key through the near-field communication.

4. The vehicle of claim 3.

5. The execution device An NFC module is started as the near-field communication device, and the owner key is validated by NFC communication.

5. A vehicle according to claim 3 or claim 4.

6. The execution device A UW module is activated as the near-field communication device, and the owner key is validated by UW communication.

5. A vehicle according to claim 3 or claim 4.

7. The execution device The BLE module is activated as the near-field communication device, and the owner key is validated by BLE communication.

5. A vehicle according to claim 3 or claim 4.

Images