User terminal, user-side unit, and information management method

Abstract

The present invention comprises: an output request unit (111) which performs an output request and includes a user terminal DID of a user terminal in said request; a vehicle-related information acquisition unit (112) which acquires vehicle-related information and a vehicle DID which are output from a vehicle in response to the output request when an authentication is established using the user terminal DID included in the output request; a registration unit (113) which registers, in a DLT network, the user terminal DID and the acquired vehicle-related information and vehicle DID; a first VC acquisition unit (114) which acquires a vehicle-related information VC which is sent from the DLT network in relation to the registration and is linked to the vehicle DID and to the user terminal DID, said vehicle-related information VC including the vehicle-related information and a proof for verification; and a first VC storage unit (115) which stores the acquired vehicle-related information VC.

Description

User terminal, user unit, and information management method CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-097544 filed in Japan on June 17, 2024, and the contents of the original application are incorporated by reference in their entirety.

[0002] The present disclosure relates to a user terminal, a user-side unit, and an information management method.

[0003] Decentralized identity (DID), proposed by the World Wide Web Consortium, is a well-known technology for managing digital identities. DID attempts to distribute digital identities using a distributed ledger system such as a blockchain, allowing users to manage their own IDs. A DID is known as a key element of DID.

[0004] For example, Patent Document 1 discloses a method for authenticating a user attempting to log in to a platform using a DID. Patent Document 1 describes that, based on a target user's DID, a DID document associated with the target user's DID is obtained from a blockchain network, the target user's public key is obtained from the DID document, the target user's public key is used to verify the user signature, and it is verified whether the target user is the true owner of the target user's DID, thereby preventing theft or counterfeiting of digital IDs.

[0005] It is also known that by linking verifiable credentials (VC) to a DID, it is possible to prove that the VC is owned by an individual linked to the DID.

[0006] Japanese Patent Application Laid-Open No. 2021-111412

[0007] Using distributed ID technology, it is conceivable that a vehicle may provide its own vehicle data and the personal information of the owner user to a service provider to receive some kind of vehicle service. In this case, the vehicle may store a VC linked to the vehicle's DID, including vehicle data and personal information, and provide this VC to the service provider as needed to receive the vehicle service. However, if this VC is stored in the vehicle, there is a risk that personal information may be leaked from this VC if the vehicle is stolen or transferred and the owner of the vehicle changes, for example.

[0008] To address this issue, instead of sending the VC directly from the vehicle to the service provider, it is possible to send it via the user's terminal and store it in the user's terminal without leaving it in the vehicle. This reduces the risk of personal information leaking from the vehicle, since the VC is stored in the user's terminal even if the owner of the vehicle changes. On the other hand, sending it via the user's terminal could lead to the problem of a third party who is not the owner of the vehicle extracting the VC and storing it in their own terminal, resulting in the leakage of personal information.

[0009] One purpose of this disclosure is to provide a user terminal, a user unit, and an information management method that utilizes distributed ID technology to further reduce the leakage of personal information, even when vehicle services are provided using information provided from a vehicle via a user terminal.

[0010] The symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure.

[0011] In order to achieve the above object, the user terminal of the present disclosure is a user terminal carried by a user that can be used in a distributed ID system, and that verifies a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network, which is a network of nodes on the distributed ledger system, using distributed ID technology. The user terminal includes an output request unit that issues an output request to a vehicle, requesting that the vehicle output vehicle-related information, including vehicle information and personal information of the vehicle owner, by including a user terminal DID, which is a distributed identifier of the user terminal; and a user terminal that, in response to the output request from the output request unit, verifies the vehicle's authorized user information by using the user terminal DID included in the output request. the vehicle-related information acquisition unit that acquires vehicle-related information and a vehicle DID, which is a distributed identifier for the vehicle, that are output when authentication is successful as a user; a registration unit that registers the vehicle-related information and vehicle DID acquired by the vehicle-related information acquisition unit and the user terminal DID in a distributed ledger network; a first VC acquisition unit that acquires a vehicle-related information VC, which is a VC that includes the vehicle-related information and a proof for verification, linked to the vehicle DID and the user terminal DID, and is sent from the distributed ledger network in response to the registration of the vehicle-related information, vehicle DID, and user terminal DID from the registration unit; and a first VC storage unit that stores the vehicle-related information VC acquired by the first VC acquisition unit.

[0012] In order to achieve the above object, the information management method of the present disclosure is an information management method usable in a distributed ID system, which utilizes distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network, which is a network of nodes on the distributed ledger system, and includes an output request step executed by at least one of a processor and a circuit, of issuing an output request from a user terminal carried by a user to a vehicle, requesting output of vehicle-related information including vehicle information and personal information of the vehicle owner, the output request including a user terminal DID, which is a distributed identifier of the user terminal; The method includes a vehicle-related information acquisition step of acquiring vehicle-related information and a vehicle DID, which is a distributed identifier of the vehicle, that is output when authentication as a legitimate user of the vehicle is successful at the vehicle using the DID; a registration step of registering the vehicle-related information and vehicle DID acquired in the vehicle-related information acquisition step, and the user terminal DID, in a distributed ledger network; a first VC acquisition step of acquiring a vehicle-related information VC, which is a VC that includes the vehicle-related information and a proof for verification, linked to the vehicle DID and the user terminal DID, and is transmitted from the distributed ledger network in response to the registration of the vehicle-related information, vehicle DID, and user terminal DID in the registration step; and a first VC storage step of storing the vehicle-related information VC acquired in the first VC acquisition step.

[0013] According to the above configuration, in response to an output request, the vehicle-related information and the vehicle DID of the vehicle are acquired when the user is authenticated as the authorized user of the vehicle using the user terminal DID. This prevents user terminals other than the authorized user of the vehicle from acquiring the vehicle-related information from the vehicle. Furthermore, the user terminal registers the acquired vehicle-related information, the vehicle DID, and the user terminal DID in a distributed ledger network, and acquires from the distributed ledger network a vehicle-related information VC, which is a VC linked to the vehicle DID and the user terminal DID and includes the vehicle-related information and a proof for verification. Therefore, when the user terminal provides this vehicle-related information VC to a service provider, the service provider can use the distributed ledger network to verify that the vehicle-related information VC is linked to the authorized user of the vehicle, allowing the user terminal to receive vehicle services from the service provider. Furthermore, because the user terminal stores the vehicle-related information VC, it is possible to prevent personal information contained in the vehicle-related information VC from leaking from the vehicle even if the vehicle owner changes. As a result, even when vehicle services are provided using information provided from the vehicle via the user terminal using distributed ID technology, it is possible to further reduce the leakage of personal information.

[0014] To achieve the above object, the user-side unit of the present disclosure includes the above-mentioned user terminal and a vehicle-side device used in a vehicle.

[0015] According to the above configuration, since it includes the aforementioned user terminal, it is possible to further reduce the leakage of personal information even when vehicle services are provided using distributed ID technology and information provided from the vehicle via the user terminal.

[0016] Fig. 1 is a diagram showing an example of a schematic configuration of an authentication system; Fig. 2 is a diagram showing an example of a schematic configuration of a vehicle unit in embodiment 1; Fig. 3 is a diagram showing an example of a schematic configuration of a user terminal; Fig. 4 is a sequence diagram for explaining an example of data flow in an authentication system; Fig. 5 is a diagram showing an example of a schematic configuration of a vehicle unit in embodiment 2;

[0017] A number of embodiments for the purpose of disclosure will be described with reference to the drawings. For the sake of convenience, parts having the same functions as parts shown in the drawings used in the previous explanations in the number of embodiments will be given the same reference numerals, and their description may be omitted. For parts given the same reference numerals, the explanations in other embodiments may be referred to.

[0018] (First Embodiment) <Overview of Authentication System 1> Hereinafter, a first embodiment of the present disclosure will be described with reference to the drawings. The authentication system 1 shown in Fig. 1 uses distributed ID technology and verifiable credentials (VC) for authentication. As shown in Fig. 1, the authentication system 1 includes a user terminal 10, a vehicle 20, a service provider terminal 30, and a distributed ledger network (hereinafter referred to as DLT network) 40. The authentication system 1 corresponds to a distributed ID system.

[0019] Decentralized ID technology is a decentralized identity (ID) technology proposed by the World Wide Web Consortium (W3C). Decentralized ID technology is a technology that distributes and manages digital identities using a distributed ledger system such as a blockchain. In decentralized ID technology using VC, a certificate is used that provides a proof that guarantees the authenticity of the attribute information of an individual or other target. This certificate corresponds to the VC. A VC is also called a verifiable credential. In decentralized ID technology using VC, a decentralized identifier (hereinafter referred to as DID) assigned to each target is linked to the VC, making it possible to prove that the VC was issued to the target corresponding to the DID linked to the VC. Targets that have DIDs are not limited to individuals, but also include objects such as cars.

[0020] In distributed ID technology, a DID is associated one-to-one with a DID document that holds data related to the DID. Distributed ID technology has a mechanism for obtaining a DID document by resolving the DID. The DID is generated on the target side, but when the DID is registered, the DID and DID document are stored in the registry of the DLT network 40. Note that, to avoid overloading the capacity of the registry of the DLT network 40, the registry may store a link to the DID document. The following explanation uses an example in which the registry stores a link to the DID document. Registering a DID can utilize existing DID registration architecture. As an example, a DID can be registered in the DLT network 40 using a mechanism such as the Client-managed Secret Mode proposed by the Decentralized Identity Foundation (DIF).

[0021] A DID is an identifier having a format defined by the W3C. A DID includes a scheme, a DID method, and a method-specific identifier. Each element is separated by a colon. A scheme is a prefix indicating that a DID method, etc., follows. A DID method is a code that specifies the type of mechanism that operates the DID, in other words, how to interpret the identifier. DID method information can be used to identify how to obtain a DID document that indicates information associated with the DID. A DID method defines a registry, etc., where the DID is registered. A DID method may be any method. A method-specific identifier is assigned a unique value within the method. A DID subject is uniquely determined by the combination of the method-specific identifier and the DID method. A method-specific identifier may be generated differently for each DID method. A method-specific identifier may be generated using any method.

[0022] A DID document is serialized in JSON or JSON-LD format. A DID document includes a DID subject, DID controller, public key, public key type, and last update date. The DID subject indicates the entity that has the DID. The DID subject stores the DID itself. The DID controller represents the entity that has been granted permission to make changes to the DID document. The DID controller may be represented by the DID of the entity that has the permission to make changes. The public key is a verification key for authenticating the DID subject. The public key is paired with a private key. The public and private key pair can be generated using any method, such as RSA. The public key type indicates the type of public key. A DID document can be stored in a registry in encrypted format so that it can be restored using a predetermined function called a resolver. The resolver can vary depending on the DID method. Using a resolver to obtain information contained in a DID document associated with a DID is also called DID resolving. Note that obtaining a public key associated with a DID may also be included in one form of DID resolution.

[0023] In this embodiment, the user terminal 10, the vehicle 20, and the service provider terminal 30 are assumed to have a DID. Hereinafter, the DID of the user terminal 10 will be referred to as a user terminal DID. Hereinafter, the DID of the vehicle 20 will be referred to as a vehicle DID. Hereinafter, the DID of the service provider terminal 30 will be referred to as a provider terminal DID. Hereinafter, the description will continue assuming that the user terminal DID, vehicle DID, and provider terminal DID have all been registered in the DLT network 40. In other words, the registry of the DLT network 40 stores the user terminal DID, vehicle DID, and provider terminal DID, as well as links to DID documents associated with each DID.

[0024] In this embodiment, the vehicle 20 is owned by the user Us of the user terminal 10. The vehicle 20 has a vehicle DID as described above. The vehicle 20 includes a vehicle unit 200. Details of the vehicle unit 200 will be described later.

[0025] The service provider terminal 30 is a terminal of a service provider that provides information about vehicle services (hereinafter, service-related information). As described above, the service provider terminal 30 has a provider terminal DID. The service provider terminal 30 may be, for example, a server connected to a network. An example of a service provider is a used car appraisal service provider that appraise the selling price of used cars. In this case, the service-related information is the appraisal result. The appraisal result may include, in addition to the appraised selling price, appraisal items and evaluation results for each appraisal item. The following explanation will be continued using an example in which the service provider terminal 30 is a server of a used car appraisal service provider.

[0026] The DLT network 40 is a network of nodes on a distributed ledger system. The nodes of the DLT network 40 are computers such as servers. As an example, the DLT network 40 may be a blockchain network. The DLT network 40 includes the above-mentioned registry. The registry corresponds to a Verifiable Data Registry (VDR). The registry may be logical storage. The nodes of the DLT network 40 are mainly composed of computers equipped with, for example, a processor, volatile memory, non-volatile memory, I / O, and buses connecting these. In the nodes of the DLT network 40, at least some of the functions performed by a processor may be performed by a circuit. The circuit referred to here is a hardware circuit.

[0027] The user terminal 10 is a terminal carried by a user Us. The owner of the user terminal 10 is the user Us. Examples of the user terminal 10 include a multi-function mobile phone, a tablet terminal, a notebook PC, etc. The following explanation will be given using the example where the user terminal 10 is a multi-function mobile phone. The user terminal 10 is mainly composed of a computer including, for example, a processor, volatile memory, non-volatile memory, I / O, and a bus connecting these. Note that the user terminal 10 may have a circuit that performs at least some of the functions performed by the processor. The circuit referred to here is a hardware circuit. The configuration of the user terminal 10 will be described in detail later.

[0028] <General Configuration of Vehicle Unit 200> Next, the general configuration of the vehicle unit 200 will be described with reference to Fig. 2. As shown in Fig. 2, the vehicle unit 200 includes an authentication device 201, a near field communication module (hereinafter referred to as NFCM) 202, and a wide area communication module (hereinafter referred to as WFCM) 203.

[0029] The NFCM 202 is a communication module for performing short-range wireless communication. When a communication connection is established between the NFCM 202 and the user terminal 10, the NFCM 202 performs short-range wireless communication with the user terminal 10. The short-range wireless communication is, for example, wireless communication having a maximum communication range of several tens of meters. For example, wireless communication compliant with Bluetooth (registered trademark) Low Energy may be used as the short-range wireless communication.

[0030] The WFCM 203 transmits and receives information to and from a network external to the vehicle via wireless communication. That is, it performs wide-area communication. The WFCM 203 communicates with the DLT network 40.

[0031] The authentication device 201 is mainly composed of a computer including, for example, a processor, volatile memory, non-volatile memory, I / O, and a bus connecting these. Note that the authentication device 201 may have a circuit that performs at least some of the functions performed by the processor. The circuit referred to here is a hardware circuit. The authentication device 201 corresponds to a vehicle-side device. Furthermore, a configuration including the user terminal 10 and the authentication device 201 corresponds to a user-side unit. The configuration of the authentication device 201 will be described below.

[0032] Here, the schematic configuration of the authentication device 201 will be described with reference to FIG. 2. As shown in FIG. 2, the authentication device 201 includes functional blocks, such as a request receiving unit 211, a document request unit 212, a document acquisition unit 213, a first authentication unit 214, a vehicle-related information acquisition unit 215, and a first data output unit 216. All of the functions performed by the authentication device 201 may be realized by a processor executing software. Some or all of the functions performed by the authentication device 201 may be configured as hardware using one or more circuits, etc. Some or all of the functional blocks included in the authentication device 201 may be realized by a combination of a processor executing software and a hardware circuit.

[0033] The request receiving unit 211 receives an output request from the user terminal 10 requesting the output of vehicle-related information. The vehicle-related information may include vehicle information and personal information of the vehicle owner. In this embodiment, the vehicle information may be information necessary for appraisal in a used car appraisal service. For example, the vehicle information may include mileage, vehicle identification number, model year, grade, vehicle name, collision detection results, etc. For example, the personal information may include the location information history of the vehicle 20's GNSS (Global Navigation Satellite System) receiver, the user Us's credit card information, the user Us's address, etc. An example of a GNSS is GPS. The output request from the user terminal 10 includes the user terminal DID of the requesting user terminal 10 and a signature assigned using the user terminal 10's private key. The private key of the user terminal 10 is stored in a secure area of ​​the user terminal 10.

[0034] The request receiving unit 211 may receive an output request transmitted by short-range wireless communication, for example, via the NFCM 202. Note that the request receiving unit 211 may also be configured to receive an output request made by means other than short-range wireless communication. As an example, the output request may be made by presenting a two-dimensional code such as a QR code (registered trademark). In this case, a two-dimensional code indicating the content of the output request is generated in the user terminal 10 and displayed, for example, on a display of the user terminal 10. The request receiving unit 211 may receive the output request read by a reading device that reads this two-dimensional code. In this case, the vehicle unit 200 may include a two-dimensional code reading device.

[0035] The document request unit 212 transmits a request for a DID document (hereinafter referred to as a document request) linked to the user terminal DID included in the output request received by the request receiving unit 211 to the DLT network 40. This DID document is a DID document that includes a public key for authenticating the user Us, which is linked to the user terminal DID of the user terminal 10. The document request includes the user terminal DID included in the output request. In other words, the document request unit 212 transmits a document request including the user terminal DID to the DLT network 40. The document request unit 212 can transmit the document request to the DLT network 40 via the WFCM 203.

[0036] The DLT network 40 that receives this document request acquires the DID document linked to the user terminal DID included in the document request from the VDR. In this embodiment, the DLT network 40 acquires the DID document from the VDR linked to the DID document linked to the user terminal DID. The DLT network 40 then transmits the acquired DID document to the WFCM 203 of the vehicle 20 that made the document request.

[0037] The document acquisition unit 213 acquires the DID document transmitted from the DLT network 40 in response to the document request from the document request unit 212. The document acquisition unit 213 may acquire the DID document transmitted from the DLT network 40 via the WFCM 203.

[0038] The first authentication unit 214 extracts the public key included in the DID document acquired by the document acquisition unit 213. The first authentication unit 214 uses the public key included in the DID document acquired by the document acquisition unit 213 to authenticate that the user terminal 10 belongs to the authorized user Us. The authorized user may be a user who is permitted to output data from the vehicle 20 (hereinafter referred to as an authorized user). The authorized user may be, for example, the user Us who is the owner of the vehicle 20. An example of authenticating that the user terminal 10 belongs to the authorized user Us may be as follows: First, the signature included in the output request accepted by the request acceptance unit 211 is decrypted using the public key included in the DID document. If the decryption is successful, it is verified that the user terminal 10 belongs to the user Us. Next, if the user Us is registered as an authorized user in the vehicle 20, it is authenticated that the user terminal 10 belongs to the authorized user Us. The authorized user may be registered, for example, by storing the user terminal DID in advance in the non-volatile memory of the vehicle 20. Alternatively, this may be realized by including the vehicle DID of the vehicle 20 as an object that the DID controller has the authority to change in the user terminal DID included in the output request.

[0039] The vehicle-related information acquisition unit 215 acquires vehicle-related information. The vehicle-related information acquisition unit 215 may be configured to acquire vehicle information such as the vehicle identification number, model year, grade, and vehicle name that is stored in advance in a non-volatile memory of the vehicle. The vehicle-related information acquisition unit 215 may be configured to acquire mileage information from a meter ECU, for example. The vehicle-related information acquisition unit 215 may be configured to acquire collision detection results from an ECU related to collision detection, such as an airbag ECU. The vehicle-related information acquisition unit 215 may be configured to acquire credit card information from an ETC (registered trademark) in-vehicle unit, for example. The vehicle-related information acquisition unit 215 may be configured to acquire GPS history and address information from a navigation device, for example.

[0040] If the first authentication unit 214 can authenticate that the user terminal 10 belongs to a legitimate user, the first data output unit 216 outputs the vehicle-related information acquired by the vehicle-related information acquisition unit 215 and the vehicle DID of the vehicle 20 to the user terminal 10. The vehicle DID is assumed to be stored in advance in non-volatile memory of the vehicle 20. The first data output unit 216 simply reads this vehicle DID from the non-volatile memory and outputs it to the user terminal 10. On the other hand, if the first authentication unit 214 cannot authenticate that the user terminal 10 belongs to a legitimate user, the first data output unit 216 does not output the vehicle-related information and the vehicle DID to the user terminal 10.

[0041] <Overall Configuration of User Terminal 10> Next, the overall configuration of the user terminal 10 will be described with reference to Fig. 3. As shown in Fig. 3, the user terminal 10 includes a control unit 100, a near field communication module (hereinafter referred to as NFCM) 101, and a wide area communication module (hereinafter referred to as WFCM) 102.

[0042] The NFCM 101 is a communication module for performing short-range wireless communication. When a communication connection is established between the NFCM 101 and the NFCM 202 of the vehicle 20, the NFCM 101 performs the above-mentioned short-range wireless communication with the NFCM 202. The WFCM 102 performs the above-mentioned wide-area communication. The WFCM 102 communicates with the service provider terminal 30. The WFCM 102 communicates with the DLT network 40.

[0043] The control unit 100 is mainly composed of a computer including, for example, a processor, volatile memory, non-volatile memory, I / O, and a bus connecting these. Note that the control unit 100 may have a circuit that performs at least some of the functions of a processor. The circuit referred to here is a hardware circuit.

[0044] As shown in FIG. 3 , the control unit 100 includes, as functional blocks, an output request unit 111, a vehicle-related information acquisition unit 112, a registration unit 113, a first VC acquisition unit 114, a first VC storage unit 115, a VC transmission unit 116, a second VC acquisition unit 117, and a second VC storage unit 118. The execution of the processing of each functional block of the control unit 100 by a computer corresponds to the execution of an information management method. The control unit 100 may implement all of its functions by software execution by a processor. The control unit 100 may also implement some or all of its functions as hardware using one or more circuits, etc. The control unit 100 may implement some or all of its functional blocks by a combination of software execution by a processor and hardware circuits.

[0045] The output request unit 111 sends an output request to the vehicle 20 requesting the output of vehicle-related information, including the user terminal DID of the user terminal 10. As described above, the output request may be accompanied by a signature created using the private key of the user terminal 10. The output request may be made by various means. For example, the output request may be made by short-range wireless communication via the NFCM 101, as described above. For example, the output request may be made by presenting a two-dimensional code, as described above. The processing in this output request unit corresponds to an output request step.

[0046] In response to an output request from the output request unit 111, the vehicle-related information acquisition unit 112 acquires the vehicle-related information and the vehicle DID of the vehicle 20, which are output from the vehicle 20 when the above-mentioned authentication is successful in the vehicle 20. Since the vehicle-related information and the vehicle DID are not output when authentication is not successful, it is possible to prevent user terminals 10 other than the legitimate user Us of the vehicle 20 from acquiring the vehicle-related information from the vehicle 20. The vehicle-related information acquisition unit 112 may acquire the vehicle-related information and the vehicle DID output from the vehicle 20 via the NFCM 101. This processing by the vehicle-related information acquisition unit 112 corresponds to a vehicle-related information acquisition step.

[0047] The registration unit 113 registers the vehicle-related information and vehicle DID acquired by the vehicle-related information acquisition unit 112, and the user terminal DID of the user terminal 10, in the DLT network 40. This registration corresponds to the registration of a VC. The registration unit 113 simply registers the VC by transmitting the vehicle-related information, vehicle DID, and user terminal DID to the DLT network 40 via the WFCM 102. In response to this, the DLT network 40 registers the VC by linking the vehicle-related information transmitted from the registration unit 113 with the vehicle DID and user terminal DID transmitted from the registration unit 113 and storing them in a registry. Furthermore, when the VC is registered, the DLT network 40 returns a VC (hereinafter referred to as the vehicle-related information VC) that includes the vehicle-related information and a proof for verification, linked to the vehicle DID and user terminal DID, to the user terminal 10. The proof of the vehicle-related information VC is, for example, a hash value generated from the vehicle-related information using a hash function. The hash function used to generate this proof may be linked to the vehicle-related information VC and managed by the DLT network 40. The processing in the registration unit 113 corresponds to the registration step.

[0048] According to the above configuration, when the user terminal 10 provides this vehicle-related information VC to a service provider, the service provider can use the DLT network 40 to verify that the vehicle-related information VC is linked to the legitimate user of the vehicle 20, and the user terminal 10 can receive vehicle services from the service provider terminal 30. In particular, because the vehicle-related information VC is linked to the vehicle DID and the user terminal DID, it can be identified that the vehicle-related information VC belongs to the legitimate user of the vehicle 20. Furthermore, because the proof included in the vehicle-related information VC is generated by the DLT network 40, it can also be verified that there has been no change to the vehicle-related information included in the vehicle-related information VC using this proof.

[0049] The first VC acquisition unit 114 acquires the vehicle-related information VC transmitted from the DLT network 40 in response to the VC registration. The first VC storage unit 115 stores the vehicle-related information VC acquired by the first VC acquisition unit 114. The non-volatile memory of the user terminal 10 may be used as the first VC storage unit 115. Note that the vehicle-related information VC is not transmitted from the user terminal 10 to the vehicle 20, and is not stored in the vehicle 20. This processing by the first VC acquisition unit 114 corresponds to the first VC acquisition step. Also, the processing of storing the vehicle-related information VC acquired by the first VC acquisition unit 114 corresponds to the first VC storage step.

[0050] According to the above configuration, the user terminal 10 stores the vehicle-related information VC. This makes it possible to prevent personal information contained in the vehicle-related information VC from leaking from the vehicle 20, even if the owner of the vehicle 20 changes. Furthermore, the following advantages are obtained compared to when the vehicle-related information VC is stored in the vehicle 20. These are described in detail below. When the vehicle-related information VC is stored in the vehicle 20, services using the vehicle-related information VC at the service provider terminal 30 can only be received when the vehicle 20 is online and can connect to the service provider terminal 30 via a network. In contrast, according to the configuration of this embodiment, the vehicle-related information VC is stored in the user terminal 10. Therefore, even if the vehicle 20 is not nearby, the user Us can use the user terminal 10 to receive services using the vehicle-related information VC at the service provider terminal 30 at any time. This further improves convenience for the user Us.

[0051] The configuration of this embodiment described so far makes it possible to further reduce the leakage of personal information, even when vehicle services are provided using information provided from the vehicle 20 via the user terminal 10 using distributed ID technology.

[0052] The VC transmission unit 116 transmits the vehicle-related information VC stored in the first VC storage unit 115 to the service provider terminal 30. For example, when the user terminal 10 receives an operation input from the user Us to use a used car appraisal service by the service provider terminal 30, the user terminal 10 may transmit the vehicle-related information VC to the service provider terminal 30. The VC transmission unit 116 may transmit the vehicle-related information VC to the service provider terminal 30 via the WFCM 102. Note that the VC transmission unit 116 may transmit the vehicle-related information VC in a format included in a VP (Verifiable Presentation).

[0053] The second VC acquisition unit 117 acquires service-related information VC transmitted from the service provider terminal 30 when the vehicle-related information VC transmitted from the VC transmission unit 116 can be verified by the DLT network 40. The service-related information VC is a VC including the service-related information and a proof for verification obtained from the DLT network 40 based on the service-related information provided by the service provider terminal 30 on the basis of the vehicle-related information included in the vehicle-related information VC. Note that being able to verify may be rephrased as "verification established." Not being able to verify may be rephrased as "verification not established."

[0054] When the service provider terminal 30 acquires the vehicle-related information VC transmitted from the user terminal 10, it transmits the vehicle-related information VC to the DLT network 40, causing the DLT network 40 to verify the vehicle-related information VC. The DLT network 40 performs verification using a proof included in the vehicle-related information VC. The verification may be performed, for example, as follows. The DLT network 40 generates a hash value from the vehicle-related information included in the vehicle-related information VC requested for verification, using a hash function managed in the DLT network 40 in association with the vehicle-related information VC. The verification may then be performed by determining whether the generated hash value matches a hash value corresponding to the proof of the vehicle-related information VC registered in the DLT network 40. The verification result of the vehicle-related information VC in the DLT network 40 is transmitted to the service provider terminal 30. If the verification result is successful, the service provider terminal 30 uses the vehicle-related information included in the vehicle-related information VC to generate service-related information to be provided based on the vehicle-related information. In the example of this embodiment, the service-related information is the appraisal result of the selling price of the vehicle 20. The service provider terminal 30 registers the generated service-related information in the DLT network 40. In this case, the service provider terminal 30 may register the service-related information by linking it to the provider terminal DID. After this registration, the DLT network 40 returns the service-related information VC, which is a VC linked to the provider terminal DID and includes the service-related information and a proof for verification, to the user terminal 10. Note that the service provider terminal 30 may transmit the service-related information VC in a format included in a VP. If the verification result is unsuccessful, the service provider terminal 30 does not generate service-related information based on the vehicle-related information.

[0055] The above-described processing in the service provider terminal 30 may be executed by a control unit of the service provider terminal 30. The control unit of the service provider terminal 30 is mainly composed of a computer including, for example, a processor, a volatile memory, a non-volatile memory, an I / O, and a bus connecting these. The control unit of the service provider terminal 30 may be configured such that at least some of the functions performed by the processor are performed by a circuit. The circuit referred to here is a hardware circuit.

[0056] The second VC storage unit 118 stores the service-related information VC acquired by the second VC acquisition unit 117. The second VC storage unit 118 may be a non-volatile memory of the user terminal 10. Although the service-related information VC relates to services for the vehicle 20, it is not transmitted from the user terminal 10 to the vehicle 20 and is not stored in the vehicle 20. Since the user terminal 10 also stores the service-related information VC, even if the owner of the vehicle 20 changes, it is possible to prevent personal information about the user Us contained in the service-related information VC from leaking from the vehicle 20. Furthermore, by storing the service-related information VC in the user terminal 10, the user Us can receive services using the service-related information VC at any time, even if the vehicle 20 is not nearby. An example of a service provided using the service-related information VC is a used car purchase using the appraisal results of the selling price of the vehicle 20. This also improves convenience for the user Us.

[0057] <Data Flow in Authentication System 1> Here, an example of data flow in the authentication system 1 will be described using the sequence diagram of Fig. 4. The sequence diagram of Fig. 4 shows an example of data flow among the user terminal 10, the vehicle 20, the service provider terminal 30, and the DLT network 40. The sequence diagram of Fig. 4 will be described using an example in which the user Us of the user terminal 10 is an authorized user who is authorized to output data from the vehicle 20.

[0058] First, at t1, the output request unit 111 of the user terminal 10 makes the above-mentioned output request to the vehicle 20. At t2, the request receiving unit 211 of the vehicle 20 receives the output request. Then, the document request unit 212 of the vehicle 20 transmits to the DLT network 40 a document request for a DID document linked to the user terminal DID included in the output request.

[0059] At t3, the DLT network 40, which has received the document request, reads the DID document requested in the document request and transmits it to the vehicle 20. At t4, the document acquisition unit 213 of the vehicle 20 acquires the DID document transmitted from the DLT network 40. The first authentication unit 214 of the vehicle 20 then extracts the public key included in the acquired DID document and verifies the signature included in the output request received at t2. In this example embodiment, the user Us of the user terminal 10 is an authorized user who is permitted to output data from the vehicle 20, and therefore the first authentication unit 214 authenticates that the user terminal 10 belongs to the legitimate user Us.

[0060] At t5, the first data output unit 216 of the vehicle 20 outputs the vehicle-related information acquired by the vehicle-related information acquisition unit 215 and the vehicle DID of the vehicle 20 to the user terminal 10. At t6, the vehicle-related information acquisition unit 112 of the user terminal 10 acquires the vehicle-related information and vehicle DID output from the vehicle 20. Then, the registration unit 113 of the user terminal 10 registers the acquired vehicle-related information and vehicle DID, and the user terminal DID of the user terminal 10, in the DLT network 40.

[0061] At t7, the DLT network 40 associates the transmitted vehicle-related information with the transmitted vehicle DID and user terminal DID, stores the information in a registry, and registers the vehicle-related information VC. The registered vehicle-related information VC is then transmitted to the user terminal 10. At t8, the first VC acquisition unit 114 of the user terminal 10 acquires the vehicle-related information VC transmitted from the DLT network 40 and stores it in the first VC storage unit 115.

[0062] At t9, the VC sending unit 116 of the user terminal 10 sends the vehicle-related information VC stored in the first VC storage unit 115 to the service provider terminal 30. At t10, the service provider terminal 30 acquires the vehicle-related information VC sent from the user terminal 10. Then, the service provider terminal 30 sends the acquired vehicle-related information VC to the DLT network 40, causing the vehicle-related information VC to be verified.

[0063] At t11, the DLT network 40, the service provider terminal 30, acquires the vehicle-related information VC transmitted from the user terminal 10. Then, the DLT network 40 verifies the authenticity of the vehicle-related information VC using the proof included in the vehicle-related information VC and transmits the verification result to the service provider terminal 30. In the example of this embodiment, since the user terminal 10 of the user Us has registered the vehicle-related information VC, the verification of the vehicle-related information VC is successful.

[0064] At t12, the service provider terminal 30 receives a verification result indicating that the vehicle-related information VC has been verified, transmitted from the DLT network 40. Then, the service provider terminal 30 generates service-related information using the vehicle-related information included in the vehicle-related information VC, and registers the generated service-related information in the DLT network 40. In the registration, the service-related information may be registered in association with the provider terminal DID.

[0065] At t13, the DLT network 40 associates the transmitted service-related information with the transmitted provider terminal DID and stores it in a registry, thereby registering the service-related information VC. The registered service-related information VC is then transmitted to the service provider terminal 30. At t14, the service provider terminal 30 acquires the service-related information VC transmitted from the DLT network 40 and transmits it to the user terminal 10. At t15, the second VC acquisition unit 117 of the user terminal 10 acquires the service-related information VC transmitted from the service provider terminal 30 and stores it in the second VC storage unit 118.

[0066] (Embodiment 2) The configuration of the above-described embodiment is not limited to the above, and the following configuration of embodiment 2 may also be adopted. An example of the configuration of embodiment 2 will be described below with reference to the drawings. The authentication system 1 of embodiment 2 is similar to the authentication system 1 of embodiment 1, except that the vehicle 20 includes a vehicle unit 200a instead of the vehicle unit 200.

[0067] <General Configuration of Vehicle Unit 200a> Here, the general configuration of the vehicle unit 200a will be described using Fig. 5. As shown in Fig. 5, the vehicle unit 200a includes an authentication device 201a, an NFCM 202, and a WFCM 203. The vehicle unit 200a is similar to the vehicle unit 200 of the first embodiment except that the vehicle unit 200a includes an authentication device 201a instead of the authentication device 201.

[0068] As shown in FIG. 5 , the authentication device 201a includes, as functional blocks, a request receiving unit 211, a second authentication unit 214a, a vehicle-related information acquisition unit 215, a second data output unit 216a, and an authentication information storage unit 217. The authentication device 201a includes the authentication information storage unit 217 instead of the document request unit 212 and the document acquisition unit 213. The authentication device 201a includes a second authentication unit 214a and a second data output unit 216a instead of the first authentication unit 214 and the first data output unit 216. Except for these points, the authentication device 201a is similar to the authentication device 201 of the first embodiment. The authentication device 201a also corresponds to a vehicle-side device. In addition, a configuration including the user terminal 10 and the authentication device 201a also corresponds to a user-side unit.

[0069] The authentication information storage unit 217 stores authentication information that can authenticate the user terminal 10 belonging to the authorized user Us, linked to the user terminal DID of the user terminal 10. For example, the authentication information may be a public key paired with the private key of the user terminal 10 for authenticating the user terminal DID of the user terminal 10. The following description will be given assuming that the authentication information is this public key. The public key of the user terminal DID may be registered in the authentication information storage unit 217, for example, at the time of purchasing the vehicle 20, using the user terminal 10 at a dealer. Alternatively, the authentication device 201a may include a document request unit 212 and a document acquisition unit 213, and the public key obtained when authentication is established through the processes of t2 to t4 in the first embodiment may be registered in the authentication information storage unit 217. In this case, subsequent authentications may be switched to the authentication described below, rather than through the processes of t2 to t4. The authentication information storage unit 217 may be a non-volatile memory of the authentication device 201a. To prevent the public key from being tampered with, it is preferable to store the public key in a secure area such as trusted storage.

[0070] The second authentication unit 214a authenticates that the user terminal 10 belongs to the legitimate user Us based on the user terminal DID included in the output request received by the request receiving unit 211. In other words, it authenticates that the user is the authorized user described above. If authentication information linked to the user terminal DID exists in the authentication information storage unit 217, the second authentication unit 214a authenticates that the user is the authorized user using the authentication information. In the example of this embodiment, the signature included in the output request received by the request receiving unit 211 is decrypted using the public key registered in the authentication information storage unit 217, and if decryption is successful, the user is authenticated as an authorized user.

[0071] The second data output unit 216a is similar to the first data output unit 216 of the first embodiment, except for some differences in processing. The following describes these differences. When the second authentication unit 214a is able to authenticate that the user terminal 10 belongs to the authorized user Us, the second data output unit 216a outputs the vehicle-related information acquired by the vehicle-related information acquisition unit 215 and the vehicle DID of the vehicle 20 to the user terminal 10. On the other hand, when the second authentication unit 214a is unable to authenticate that the user terminal 10 belongs to the authorized user, the second data output unit 216a does not output the vehicle-related information and the vehicle DID to the user terminal 10.

[0072] According to the above configuration, the public key of the user terminal DID registered in advance on the vehicle 20 side is used to authenticate whether the user terminal 10 belongs to a legitimate user. Therefore, it is not necessary to acquire the public key of the user terminal DID by connecting online to the DLT network 40 each time this authentication is performed. Therefore, this authentication can be performed even when the vehicle 20 is offline and not connected to the DLT network 40. As a result, convenience for the user Us is further improved.

[0073] The present disclosure is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also within the technical scope of the present disclosure. Furthermore, the control unit and method described in the present disclosure may be implemented by a special-purpose computer comprising a processor programmed to execute one or more functions embodied in a computer program. Alternatively, the apparatus and method described in the present disclosure may be implemented by a circuit. Alternatively, the apparatus and method described in the present disclosure may be implemented by one or more special-purpose computers configured by combining a processor executing a computer program with one or more circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium.

[0074] In this disclosure and claims, the term "processor" refers to one or more hardware processors configured to execute the processing defined by computer program code (i.e., one or more instructions of a computer program) included in a computer program by loading the code each time. In other words, a "processor" is a hardware device that executes one or more programmed processes. Therefore, computer program code can also be considered software that can define the processing of the processor depending on its content. For example, a "processor" may be a general-purpose or specific-purpose processor, such as a CPU, microprocessor, GPU, or DFP (Data Flow Processor), but is not limited to these.

[0075] In this disclosure and in the claims, the term "memory" refers to one or more hardware memories that are non-transitory tangible recording media configured to store computer program code and / or data accessible to a processor. The "memory" may be implemented using memory technologies such as SRAM, SDRAM, non-volatile / flash-type memory, or other types of memory. Computer program code constituting a program may be stored in the memory and executed by a processor to cause the processor to perform the various functions described above.

[0076] In this disclosure or in the claims, the term "circuit" refers to one or more hardware logic circuits configured to perform specific processing defined by a pre-designed circuit configuration. In other words (and in contrast to "processor"), a "circuit" in this disclosure or in the claims refers to a hardware device that performs specific processing based on a circuit configuration, rather than a software program such as a computer program code. For example, a "circuit" may include custom ICs such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array) designed using a Hardware Description Language (HDL). In other words, a "circuit" in this disclosure or in the claims includes all hardware circuits except a processor that executes processing by loading computer program code.

[0077] In the present disclosure or claims, the expression "at least one of a processor and a circuit" should be interpreted as a disjunction (logical OR), and not as at least one processor and at least one circuit. Therefore, in the present disclosure or claims, "at least one of a processor and a circuit" includes cases where only a circuit performs all functions. Also, in the present disclosure or claims, "at least one of a processor and a circuit" includes cases where only a processor performs all functions. In the present disclosure or claims, "at least one of a processor and a circuit" includes cases where a circuit performs some functions and a processor performs the remaining functions.

Claims

1. A user terminal carried by a user that can be used in a distributed ID system (1) that verifies a verifiable credential, VC, linked to a distributed identifier, DID, in a distributed ledger network (40), which is a network of nodes on the distributed ledger system, using distributed ID technology, comprising: an output request unit (111) that issues an output request to a vehicle, requesting that the vehicle output vehicle-related information, including vehicle information and personal information of the vehicle owner, by including a user terminal DID, which is the distributed identifier of the user terminal; a vehicle-related information acquisition unit (112) that acquires, in response to the output request from the output request unit, the vehicle-related information and the vehicle DID, which is the distributed identifier of the vehicle, output when authentication as a legitimate user of the vehicle is established in the vehicle using the user terminal DID included in the output request; and a registration unit (113) that registers the vehicle-related information, the vehicle DID, and the user terminal DID acquired by the vehicle-related information acquisition unit in the distributed ledger network. a first VC acquisition unit (114) that acquires a vehicle-related information VC, which is the VC that includes the vehicle-related information and a proof for verification, linked to the vehicle DID and the user terminal DID, and is transmitted from the distributed ledger network in response to registration of the vehicle-related information, the vehicle DID, and the user terminal DID from the registration unit; and a first VC storage unit (115) that stores the vehicle-related information VC acquired by the first VC acquisition unit.

2. A user terminal according to claim 1, further comprising: a VC sending unit (116) that sends the vehicle-related information VC stored in the first VC storage unit to a service provider terminal (30), which is a terminal of a service provider that provides service-related information, which is information about services for the vehicle, based on the vehicle-related information; a second VC acquisition unit (117) that acquires a service-related information VC, which is sent from the service provider terminal when the vehicle-related information VC can be verified on the distributed ledger network using the proof included in the vehicle-related information VC, and which includes the service-related information obtained from the distributed ledger network based on the service-related information provided by the service provider terminal based on the vehicle-related information included in the vehicle-related information VC, and a proof for verification; and a second VC storage unit (118) that stores the service-related information VC acquired by the second VC acquisition unit.

3. A user unit comprising: a user terminal (10) according to claim 1 or 2; and a vehicle-side device (201, 201a) used in a vehicle.

4. A user-side unit according to claim 3, wherein the vehicle-side device (201) comprises: a request receiving unit (211) that receives an output request from the user terminal requesting output of vehicle-related information including a user terminal DID, which is a distributed identifier of the user terminal, and personal information of the owner of the vehicle; a document request unit (212) that sends the user terminal DID included in the output request received by the request receiving unit to the distributed ledger network, thereby requesting a DID document that is linked to the user terminal DID and includes a public key for authenticating the user, a document acquisition unit (213) that acquires the DID document sent from the distributed ledger network in response to the request from the document request unit; and a first authentication unit (214) that authenticates that the user terminal belongs to a legitimate user by using the public key included in the DID document acquired by the document acquisition unit. A user side unit comprising a first data output unit (216) that outputs the vehicle-related information and a vehicle DID, which is a distributed identifier of the vehicle, to the user terminal if the first authentication unit can authenticate that the user terminal belongs to a legitimate user, and does not output the vehicle-related information and the vehicle DID to the user terminal if the first authentication unit cannot authenticate that the user terminal belongs to a legitimate user.

5. A user-side unit according to claim 3, wherein the vehicle-side device (201a) comprises: a request receiving unit (211) that receives an output request from the user terminal requesting output of vehicle-related information including a user terminal DID, which is a distributed identifier of the user terminal, and personal information of the owner of the vehicle; an authentication information storage unit (217) that stores authentication information that can authenticate the user terminal as belonging to a legitimate user in advance, linked to the user terminal DID; and a second authentication unit (214a) that, based on the user terminal DID included in the output request received by the request receiving unit, uses the authentication information if the authentication information linked to the user terminal DID exists in the authentication information storage unit to authenticate that the user terminal belongs to a legitimate user. A user side unit comprising a second data output unit (216a) that outputs the vehicle-related information and a vehicle DID, which is a distributed identifier of the vehicle, to the user terminal if the second authentication unit can authenticate that the user terminal belongs to a legitimate user, and does not output the vehicle-related information and the vehicle DID to the user terminal if the second authentication unit cannot authenticate that the user terminal belongs to a legitimate user.

6. An information management method usable in a distributed ID system (1), which uses distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network (40), which is a network of nodes on the distributed ledger system, comprising: an output request step executed by at least one of a processor and a circuit, in which a user terminal (10) carried by a user issues an output request to a vehicle (20) requesting output of vehicle-related information including information about the vehicle and personal information of the owner of the vehicle, the output request including the user terminal DID, which is the distributed identifier of the user terminal; a vehicle-related information acquisition step, in response to the output request in the output request step, acquiring the vehicle-related information and the vehicle DID, which is the distributed identifier of the vehicle, when authentication as a legitimate user of the vehicle is established in the vehicle using the user terminal DID included in the output request; and a registration step, in which the vehicle-related information, the vehicle DID, and the user terminal DID acquired in the vehicle-related information acquisition step are registered in the distributed ledger network. an information management method including: a first VC acquisition step of acquiring a vehicle-related information VC, which is the VC that includes the vehicle-related information and a proof for verification, linked to the vehicle DID and the user terminal DID, and is transmitted from the distributed ledger network in response to the registration of the vehicle-related information, the vehicle DID, and the user terminal DID in the registration step; and a first VC storage step of storing the vehicle-related information VC acquired in the first VC acquisition step.

Images