Terminal device, method for generating certification information, verification method, and program

Abstract

To verify information on distribution objects by taking into account the relevance among distribution processes.SOLUTION: A terminal device uses first certification information for certifying a first distribution object to generate second certification information for certifying a second distribution object based on at least the first distribution object, and registers second verification information corresponding to the second certification information. Here, the second certification information includes at least information for specifying the first certification information. Alternatively, the first verification information corresponding to the first certification information is registered.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] This invention relates to a technology for verifying the accuracy of the distribution process, and more particularly to a technology for performing verification that takes into account the relationships within the distribution process. [Background technology]

[0002] The world is structured around the interconnectedness of goods (tangible or intangible) that are circulated. For example, in a supply chain, goods that have circulated from upstream are processed through combinations, additions, etc., and the resulting new goods circulate downstream. On the other hand, there is a need to verify the accuracy (authenticity) of information about the goods that have circulated (e.g., design information, bill of materials (BOM), inspection results, etc.). For example, if an attacker in the supply chain maliciously alters the information of a component in a product, it is necessary to detect the alteration, determine at what point in the supply chain the information was altered, and clarify the scope of responsibility.

[0003] One known mechanism for verifying the authenticity of information is VC (Verifiable Credentials) on a blockchain (BC) (see, for example, Non-Patent Document 1). By making the object of VC verification information about the circulating item, the accuracy of this information can be verified. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] Manu Sporny, Dave Longley, and David Chadwick, "W3C Recommendation: Verifiable Credentials Data Model v1.1", [online], March 3, 2022, [Retrieved August 28, 2023], Internet<https: / / www.w3.org / TR / vc-data-model / > [Overview of the project]

Problems to be Solved by the Invention

[0005] However, the conventional mechanism has a problem that it is impossible to verify information on distribution targets considering the relevance in the distribution process. For example, in the supply chain, new products are created by combinations, processing, etc. of the products that have been distributed, so it is necessary to perform verification considering the relevance of the products to be distributed. However, VCs are individually independent, and the relevance between VCs is not expressed. Also, although there is a mechanism called VP (Verifiable Presentation) that can present multiple VCs together (see, for example, 4.10 Presentations in Non-Patent Document 1), VP cannot express the hierarchical relevance in the distribution process. Such problems are not limited to the case of using VCs, but are common to the case of verifying the correctness of the distribution process.

[0006] The present invention provides a technique that enables verification of information on distribution targets considering the relevance in the distribution process.

Means for Solving the Problems

[0007] The terminal device uses first proof information for proving a first distribution target, generates second proof information for proving at least a second distribution target based on the first distribution target, and registers second verification information corresponding to the second proof information. Here, the second proof information includes at least information for specifying the first proof information. Also, first verification information corresponding to the first proof information is registered.

Effects of the Invention

[0008] This enables verification of information on distribution targets considering the relevance in the distribution process.

Brief Description of the Drawings

[0009] [Figure 1] FIG. 1 is a block diagram for exemplifying the functional configuration of the distribution target proof system according to the embodiment. [Figure 2] Figure 2 is a block diagram illustrating the functional configuration of the terminal device according to the embodiment. [Figure 3] Figure 3 is a flowchart illustrating the hierarchical VC issuance process of the embodiment. [Figure 4] Figure 4 is a flowchart illustrating the hierarchical VC verification process of the embodiment. [Figure 5] Figure 5 is a flowchart illustrating a hierarchical VC recursive verification using VC-i as an argument in the embodiment. [Figure 6] Figure 6A is a diagram illustrating the hierarchical VC issuance process of the embodiment. Figure 6B is a diagram illustrating the configuration of the certification information of the embodiment. [Figure 7] Figure 7A is a diagram illustrating a data registry on the blockchain according to the embodiment. Figure 7B is a diagram illustrating verification information according to the embodiment. [Figure 8] Figure 8 is a diagram illustrating the verification results of the embodiment. [Figure 9] Figure 9 is a diagram illustrating the hierarchical VC issuance process of the embodiment. [Figure 10] Figure 10 is a diagram illustrating the configuration of the certification information VC in the embodiment. [Figure 11] Figure 11 is a diagram illustrating the hierarchical VC issuance process of an embodiment. [Figure 12] Figure 12 is a diagram illustrating the verification results of the embodiment. [Figure 13] Figure 13 illustrates how fraudulent activity occurs in the hierarchical VC issuance process of the embodiment. [Figure 14] Figure 14 is a diagram illustrating the verification results when the fraudulent activity described in Figure 13 occurs. [Figure 15] Figure 15 illustrates how fraudulent activity occurs in the hierarchical VC issuance process of the embodiment. [Figure 16] Figure 16 is a diagram illustrating the verification results when the fraudulent activity described in Figure 15 occurs. [Figure 17]Figure 17 illustrates how fraudulent activity occurs in the hierarchical VC issuance process of the embodiment. [Figure 18] Figure 18 is a diagram illustrating the verification results when the fraudulent activity described in Figure 17 occurs. [Figure 19] Figure 19 is a diagram illustrating the verification results when the status of the verification information of the embodiment is set to invalid. [Figure 20] Figure 20A is a diagram illustrating a correctly performed hierarchical VC issuance process. Figure 20B is a diagram illustrating the verification results when the hierarchical VC issuance process shown in Figure 20A is performed. [Figure 21] Figure 21A is a diagram illustrating the hierarchical VC issuance process in which the fraudulent activity described in Figure 13 occurred. Figure 21B is a diagram illustrating the verification results when the hierarchical VC issuance process in Figure 21A was performed. [Figure 22] Figure 22A is a diagram illustrating the hierarchical VC issuance process in which the fraudulent activity described in Figure 15 occurred. Figure 22B is a diagram illustrating the verification results when the hierarchical VC issuance process in Figure 22A was performed. [Figure 23] Figure 23A is a diagram illustrating the hierarchical VC issuance process in which the fraudulent activity described in Figure 17 occurred. Figure 23B is a diagram illustrating the verification results when the hierarchical VC issuance process in Figure 23A was performed. [Figure 24] Figure 24A illustrates a scenario where the hierarchical VC issuance process was performed correctly, but the verification information status was later set to invalid. Figure 24B illustrates the verification result when the verification information status is set to invalid, as in Figure 24A. [Figure 25] Figure 25 is a diagram illustrating the hardware configuration of a terminal device. [Modes for carrying out the invention]

[0010] Embodiments of the present invention will be described below. [overview] First, we will describe the outline of the embodiment. In the embodiment described below, the terminal device uses first certification information to certify a first distribution object, generates second certification information to certify a second distribution object that is at least based on the first distribution object, and registers second verification information corresponding to the second certification information. Here, the second certification information includes at least information for identifying the first certification information. Also, the first verification information corresponding to the first certification information is registered. Here, the second distribution object is at least based on the first distribution object and has a relationship with the first distribution object in the distribution process. Also, the second certification information certifies such a second distribution object and includes at least information for identifying the first certification information for certifying the first distribution object. Furthermore, the first verification information corresponding to the first certification information is registered, and furthermore, the second verification information corresponding to the second certification information is registered. As a result, it is possible to verify whether the second certification information corresponds to the second verification information, and whether the first certification information corresponds to the first verification information.

[0011] Preferably, the first certification information includes a first identifier that identifies the recipient of the first distribution item, and the second certification information includes a second identifier that identifies at least one of the providers of the second distribution item, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information. In this case, it is possible to verify whether at least the first identifier corresponds to the second identifier. This makes it possible to verify whether the provider of the second distribution item, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information is the true recipient of the first distribution item. This further enables verification of information regarding distribution items, taking into account the relevance of the distribution process.

[0012] The first object of distribution is a tangible object, an intangible object, or a combination of a tangible and an intangible object that is an object of distribution. Examples of tangible objects of distribution include electronic devices, electronic components, materials, pharmaceuticals, clothing, bags, food products, and other products or distributed items. Examples of intangible objects of distribution include programs, image data, sound data, and other products or distributed items. The object of distribution may be free of charge or for a fee. The second object of distribution may be the first object of distribution itself, or it may be a modified version of the first object of distribution. A modified version of the first object of distribution may be an object that has been altered by modification, improvement, correction, deletion, etc., or it may be an object that has been combined with or added to the first object of distribution, or it may be an object that has been combined with or added to the first object of distribution and then modified by modification, improvement, correction, etc. Other objects may be objects of distribution other than the first object of distribution, or they may be tangible objects, intangible objects, or combinations of tangible and intangible objects that are not objects of distribution.

[0013] The first proof information may be any information that proves the existence of the first object in circulation. For example, the first proof information may prove information relating to the first object in circulation. The second proof information may be any information that proves the existence of the second object in circulation. For example, the second proof information may prove information relating to the second object in circulation. The first and second proof information may be, for example, VCs (verifiable credentials), but this is not limited to the present invention. The information for identifying the first proof information may be the first proof information itself, information that can recover the first proof information (for example, the ciphertext of the first proof information), or a link to obtain the first proof information (for example, an address).

[0014] The first verification information is information corresponding to the first proof information, and may be any information as long as it allows for verification of the authenticity of the first proof information. Similarly, the second verification information is information corresponding to the second proof information, and may be any information as long as it allows for verification of the authenticity of the second proof information. The first verification information may, for example, include the hash value of the first proof information or include the ciphertext of the first proof information. Similarly, the second verification information may, for example, include the hash value of the second proof information or include the ciphertext of the second proof information. The registration of the first and second verification information includes the process of storing the first and second verification information in a publicly accessible storage area. The publicly accessible storage area may be any area. For example, the publicly accessible storage area may be a globally accessible area. However, if the scope of distribution of the item to be distributed (for example, a region such as a country) is restricted, the publicly accessible storage area may be an area accessible within that scope of distribution. A specific example of a publicly accessible storage area is a storage area configured on a blockchain, for example, a Verifiable Data Registry on a blockchain. However, these are not limitations of the present invention.

[0015] The first recipient of the distributed goods may be a specific recipient or any recipient. If the first recipient of the distributed goods is a specific recipient, the first identifier is an identifier that identifies that specific recipient. If the first recipient of the distributed goods may be any of several specific recipients, the first identifier may be an array of identifiers that identify these several specific recipients. On the other hand, if the first recipient of the distributed goods is any recipient, the first identifier does not identify a specific recipient, but rather is an identifier that indicates that the goods will be provided to any recipient. Each of the identifiers that identify a specific recipient and the array of identifiers that identify several specific recipients may be, for example, globally unique. However, if the distribution scope of the distributed goods is limited, each of the identifiers that identify a specific recipient and the array of identifiers that identify several specific recipients may be unique within that distribution scope. Specific examples of identifiers that identify a specific recipient and arrays of identifiers that identify several specific recipients are DIDs (Decentralized Identifiers) (see, for example, Reference 1). Specific examples of identifiers that indicate that the goods will be provided to any recipient include "*", etc. However, these do not limit the present invention. Reference 1: Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, and Christopher Allen, "W3C Recommendation: Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations", [online], July 19, 2022, [Retrieved September 1, 2023], Internet<https: / / www.w3.org / TR / did-core / >

[0016] The second identifier may identify the provider of the second distribution item, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information, or a combination thereof. The second identifier may be, for example, globally unique. However, if the distribution scope of the distribution item is restricted, the second identifier may be unique within that distribution scope.

[0017] [First Embodiment] The first embodiment will be described below with reference to the drawings. In this embodiment, the object of distribution is a product and the identifier is DID (see, for example, Reference 1). However, these are not limitations of the present invention.

[0018] <Structure> As illustrated in Figure 1, the distribution target certification system 1 of this embodiment has terminal devices 11-1, ..., 11-N that are communicably connected to the cloud 12. Here, N is an integer of 2 or more. Terminal devices 11-n (where n=1, ..., N) are devices used by users 1000-n who handle products (distribution targets) Pn. In reality, the entities that handle product Pn are corporations or other legal entities, organizations such as various associations, members of corporations or various associations, or other individuals, and the entities that operate on terminal devices 11-n are employees of those companies, etc. However, for the sake of simplicity in the following explanation, the entities that handle product Pn and the entities that operate on terminal devices 11-n will be considered the same. The cloud 12 has a blockchain 120 implemented on it, and the blockchain 120 has a verifiable data registry 121. The cloud 12 is configured, for example, on the internet.

[0019] As illustrated in Figure 2, the terminal device 11-n in this embodiment includes a key information storage unit 111a-n, a certification information storage unit 111b-n, a verification result storage unit 111c-n, an input unit 112-n, a certification information generation unit 113-n, a verification unit 114-n, a verification result storage unit 115-n, a registration processing unit 116-n, and an output unit 117-n.

[0020] <Pre-processing> As a preprocessing step, the DID (User DID) of user 1000-n is stored in the certificate information storage unit 111b-n of terminal device 11-n (Figure 2) (see, for example, Reference 1). Furthermore, the User DID of user 1000-n may correspond to the user's address assigned to terminal device 11-n (user 1000-n). For example, the User DID (did) may be expressed using the user's blockchain address (BC Address) as follows. [Format]did:{methodName}:{ChainID or ChainName}:{BC Address} [Example] did:ethr:12345: 0x1234567890123456789012345678901234567890

[0021] Furthermore, the key information storage unit 111a-n of the terminal device 11-n (Figure 2) stores the private key SK-n for generating signatures (digital signatures). The private key SK-n is a private key issued to the terminal device 11-n and is, for example, a private key conforming to a public-key cryptography scheme. For example, the private key SK-n may correspond to the address of a user assigned to the terminal device 11-n. Note that a public key PK-n corresponding to the private key SK-n is required for signature verification. The public key PK-n corresponding to the private key SK-n is stored, for example, in the verifiable data registry 121 of the blockchain 120. However, if the public key PK-n can be identified from some information (for example, the message to be signed and the signature value), it is not necessary to store the public key PK-n in the verifiable data registry 121. For example, if the blockchain 120 conforms to the Ethereum scheme, the public key PK-n can be identified if the message to be signed and the signature value are available, so it is not necessary to store the public key PK-n in the verifiable data registry 121. Furthermore, if the public key PK-n obtained from the message to be signed and the signature value corresponds to the address of a user assigned to terminal device 11-n, signature verification can also be performed by checking the consistency between the user address calculated from the public key PK-n and the user address corresponding to the user DID of user 1000-n.

[0022] <Hierarchical VC Issuance Process> The hierarchical VC issuance process of this form will be explained using Figures 1 to 3, 6A, 6B, 7A, and 7B. In this form, a supply chain is assumed in which user 1000-n provides product Pn to downstream user 1000-ω(n). Here, n ∈ {1,…,N} and ω(n) ∈ {1,…,N}. User 1000-ω(n) may be a specific recipient or any recipient. The specific recipient may be singular or plural. An example of a specific recipient is the recipient of the product Pn that placed the order. An example of an arbitrary recipient is the recipient when product Pn is an OSS (Open Source Software) product or a mass-produced product. User 1000-n may (I) generate product Pn without using the product provided by the upstream user (upstream product) and provide it to the downstream user 1000-ω(n), or (II) the upstream users 1000-ρ1(n), ..., 1000-ρ θ(n) Products provided by (n) P-ρ1(n), ..., P-ρ θ(n) (n) may be used, and product Pn may be generated by processing such as combinations, additions, and modifications (including deletions) and provided to downstream users 1000-ω(n), or (III) upstream users 1000-ρ1(n), ..., 1000-ρ θ(n) Products provided by (n) P-ρ1(n), ..., P-ρ θ(n) (n) may be provided as is as product Pn to downstream users 1000-ω(n). Here, ρ1(n),…,ρ θ(n) (n) ∈ {1, ..., N}, where θ(n) is an integer 0 ≤ θ(n) ≤ N representing the number of upstream products used to generate product Pn. Note that θ(n) = 0 represents (I) the case where product Pn is generated without using upstream products. Furthermore, we will call the product Pn generated as in (I) and (II) a "new product," and the product Pn in (III) an "existing product." [Table 1]

[0023] In the hierarchical VC issuance process, the user 1000 - n who provides the product P - n to the downstream user 1000 - ω(n) uses the terminal device 11 - n to generate the proof information VC - n for proving the product P - n, and registers the verification information VI - n corresponding to the proof information VC - n in the verifiable data registry 121 of the blockchain 120. The hierarchical VC issuance process is executed, for example, every time the user 1000 - n provides the product P - n to the user 1000 - ω(n), and the obtained proof information VC - n is provided to the user 1000 - ω(n) together with the product P - n. The proof information VC - n may be provided online or may be provided stored in a recording medium. However, when the product P - n is provided to an arbitrary destination such as an OSS product, the hierarchical VC issuance process may be executed once before the start of the provision of the product P - n, and the proof information VC - n obtained thereby may be publicly disclosed online.

[0024] Hereinafter, a specific example of the hierarchical VC issuance process is shown. Step S1121 - n: As illustrated in FIG. 3, the proof information VC - ρ1(n),..., VC - ρ θ(n) (n) (the first proof information) and other information info - n necessary for generating the proof information VC - n (the second proof information) are input to the input unit 112 - n of the terminal device 11 - n (FIG. 2) and stored in the proof information storage unit 111b - n. Here, the proof information VC - n is information for proving the product P - n (the second distribution target), and the proof information VC - ρ1(n),..., VC - ρ θ(n) (n) are information for proving the products P - ρ1(n),..., P - ρ θ(n) (n) upstream of the product P - n, respectively. Examples of the proof information VC - n, VC - ρ1(n),..., VC - ρ θ(n) (n) are VCs, but they may be other information. The proof information VC - ρ1(n),..., VC - ρ θ(n) (n) are input only when the product P - n is based on the upstream products P - ρ1(n),..., P - ρ θ(n) (n). That is, the proof information VC - ρ1(n),..., VC - ρ θ(n)(n) is entered only if product Pn is a new product of (II) or an existing product of (III). If product Pn is a new product of (I), the certification information VC-ρ1(n),…,VC-ρ θ(n) (n) is not entered. Note that the certification information VC-ρ1(n),…,VC-ρ θ(n) (n) are terminal devices 11-ρ1(n), ..., 11-ρ θ(n) (n) is generated, and products P-ρ1(n), ..., P-ρ θ(n) (n) is provided to user 1000-n. Information info-n includes, for example, information identifying the recipient of product Pn, the start date and time of the expiration date and time of the expiration date and time, the expiration date of the certification information, information identifying any certification target such as the configuration information and design information of product Pn (unique certification information), information identifying whether product Pn is a new product (I)(II) or an existing product (III), and information identifying whether product Pn is a product of (I)(II)(III). As mentioned above, the recipient of product Pn may be a specific recipient or any recipient. Note that the certification information VC-ρ1(n),...,VC-ρ θ(n) If (n) and information info-n are already stored in the certification information storage unit 111b-n, the processing in step S1121-n may be omitted.

[0025] Step S1131-n: The certification information generation unit 113-n generates the product Pn as product P-ρ1(n), ..., P-ρ θ(n) It is determined whether or not (n) is the same as (n). That is, it is determined whether or not product Pn is an existing product (III). The certification information generation unit 113-n may perform this determination using the information info-n stored in the certification information storage unit 111b-n, or it may perform this determination based on pre-set information. Here, product Pn is product P-ρ1(n),...,P-ρ θ(n) If it is not the same as (n), proceed to step S1132-n. On the other hand, product Pn is product P-ρ1(n),...,P-ρ θ(n) If it is the same as (n), proceed to step S1133-n.

[0026] Step S1132-n: The certification information generation unit 113-n issues a DID (product DID) that identifies product Pn (see, for example, Reference 1). For example, the certification information generation unit 113-n issues a product DID using a newly issued BC Address. Alternatively, product information for product Pn may be registered in the verifiable data registry 121 using the product DID of product Pn as the key. For example, the following product information may be registered. [Table 2] While registering product information is not mandatory, registering absolutely universal product information (product name, manufacturer DID, product name, etc.) in the verifiable data registry 121 and using it in the hierarchical VC verification described later can further enhance the reliability of the verification. Note that only those possessing the secret key SK-n corresponding to the product DID may be able to register the product information for the corresponding product Pn. The product DID of product Pn is stored in the certification information generation unit 113-n. Next, proceed to step S1133-n.

[0027] Step S1133-n: The certification information generation unit 113-n stores the information necessary for generating the main body VCbody-n of the certification information VC-n, which is stored in the certification information storage unit 111b-n (information info-n, certification information VC-ρ1(n), ..., VC-ρ θ(n) The main body VCbody-n is generated using (n), user DID, and product DID of product Pn. The information required to generate the main body VCbody-n includes information info-n and user DID, and the certification information storage unit 111b-n stores the certification information VC-ρ1(n),…,VC-ρ θ(n) If (n) is stored, further proof information VC-ρ1(n), ...,VC-ρ θ(n)(n) is included, and if the product DID of product Pn is stored in the certification information storage units 111b-n, then the product DID of product Pn is also included. The VCbody-n body of the certification information VC-n illustrated in Figure 6B includes, for example, a user DID (issue:userDID-n) 100a-n identifying user 1000-n who issued the certification information VC-n, an expiration start date and time (issuanceDate:XXXX) 100b-n for the certification information VC-n, an expiration end date and time (expirationDate:XXXX) 100c-n for the certification information VC-n, a product DID (id:productDID-n) 100d-n for product Pn, a user DID (issuedTo:userDID-ω(n)) 100e-n identifying user 1000-ω(n) who provided product Pn, originalInfo:product-n for product Pn 100f-n, and certification information VC-ρ1(n),…,VC-ρ θ(n) List of inheritance certificates to identify (n) (inheritances:[VC-ρ1(n),...,VC-ρ θ(n) (n)])100g-n is included. The issuer of the certification information VC-n is at least one of the providers or generators of product Pn or the registrant of the verification information VI-n corresponding to product Pn. The start date and time 100b-n of the validity period of the certification information VC-n may be a date and time based on the generation date and time of the main body VCbody-n (for example, the generation date and time of the main body VCbody-n, a date and time earlier than said generation date and time, or a date and time later than said generation date and time, etc.), or it may be a date and time specified in the information info-n. The end date and time of the validity period of the certification information VC-n is generally a date and time later than the start date and time 100b-n of the validity period of the certification information VC-n, and may be a date and time specified by the generation date and time of the main body VCbody-n and the information info-n, or it may be a date and time specified in the information info-n. As mentioned above, certification information VC-ρ1(n),...,VC-ρ θ(n) The information used to identify (n) is the proof information VC-ρ1(n), ...,VC-ρ θ(n) (n) itself may be the proof information VC-ρ1(n),…,VC-ρ θ(n) (n) is recoverable information (e.g., proof information VC-ρ1(n), ..., VC-ρθ(n) It may also be the ciphertext of (n). For example, the certificate information VC-ρ1(n),…,VC-ρ encoded and serialized using JWT (JSON Web Token), etc. θ(n) (n)) may also be the proof information VC-ρ1(n),…,VC-ρ θ(n) (n) may be a link destination from which it can be obtained (for example, a URI (Uniform Resource Identifier) ​​of external storage). However, the certification information VC-ρ1(n),...,VC-ρ θ(n) The information used to identify (n) is the proof information VC-ρ1(n), ...,VC-ρ θ(n) If (n) is a link destination from which it can be obtained, then the certification information VC-ρ1(n), ...,VC-ρ θ(n) To guarantee the authenticity of (n), the registered (recorded) certification information VC-ρ1(n), ...,VC-ρ θ(n) It is more preferable that the system be structured so that (n) is immutable (for example, IPFS (InterPlanetary File System) where the URI is determined by the hash value of the data to be stored). Also, the certification information VC-ρ1(n),...,VC-ρ θ(n) If (n) does not exist (i.e., product Pn is a new product of (I)), the inheritance proof information list 100g-n will be an empty array (inheritances:[]). Also, if product DID for product Pn does not exist (i.e., product Pn is an existing product of (III)), product DID 100d-n for product Pn will be the upstream products P-ρ1(n), ..., P-ρ θ(n) This will be the same as the product DID of (n). The user DID 100e-n of terminal device 11-ω(n) is the DID of the recipient of product Pn identified in information info-n. If the recipient of product Pn is an arbitrary recipient, the user DID 100e-n of terminal device 11-ω(n) will be an identifier indicating that it is provided to an arbitrary recipient (e.g., "*" (issuedTo:*)). [Table 3]

[0028] Furthermore, upstream products P-ρ1(n), ..., P-ρ θ(n) (n) corresponds to the "first circulating object," and the certification information VC-ρ1(n), ...,VC-ρ θ(n) (n) corresponds to "first certification information for proving the first object of distribution," product Pn may correspond to "second object of distribution based on at least the first object of distribution," and certification information VC-n may correspond to "second certification information for proving the second object of distribution." Certification information VC-ρ1(n),…,VC-ρ θ(n) (n) (First proof information) are, respectively, products P-ρ1(n), ..., P-ρ θ(n) User DID (issuedTo:userDID-n) 100e-ρ1(n), ..., 100e-ρ, which identifies user 1000-n, the recipient of (n) (the first distribution target). θ(n) (n)(first identifier) ​​or an identifier indicating that it will be provided to any recipient (e.g., "*") (first identifier). The certification information VC-n (second certification information) includes at least the certification information VC-ρ1(n), ..., VC-ρ θ(n) (n)Includes an inheritance certificate information list 100g-n (information) for identifying (n) (first certificate information). Furthermore, the certificate information VC-n (second certificate information) includes a user DID 100a-n (a second identifier that identifies at least one of the providers of the second distribution item, the generator of the second certificate information, or the registrant of the second verification information corresponding to the second certificate information) that identifies user 1000-n, who is the issuer of the certificate information VC-n.

[0029] Step S1134-n: The certification information generation unit 113-n extracts the secret key SK-n from the key information storage unit 111a-n, and uses the secret key SK-n to generate and attach the digital signature VCproof-n to the main body VCbody-n. For example, the certification information generation unit 113-n generates the hash value hash(VCbody-n) of the main body VCbody-n, generates a ciphertext for the hash value hash(VCbody-n) using the secret key SK-n, and uses this to create the digital signature VCproof-n. The certification information generation unit 113-n outputs the pair of the main body VCbody-n and the digital signature VCproof-n as certification information VC-n. The certification information VC-n is stored in the certification information storage unit 111b-n. The certification information VC-n stored in the certification information storage unit 111b-n is read when product Pn is provided and output from the output unit 117-n. The output certification information VC-n is provided to the recipient when product Pn is provided. Typically, the certification information VC-n is provided to the recipient after the verification information VI-n is registered in the verifiable data registry 121. The certification information VC-n may be provided to the recipient in plain text, or it may be provided encrypted (for example, encoded with JWT, etc., and serialized).

[0030] Step S1135-n: The registration processing unit 116-n extracts the certification information VC-n from the certification information storage unit 111b-n and registers (stores) the verification information VI-n corresponding to the certification information VC-n in the verifiable data registry 121 (Figure 7A) on the blockchain 120 of the cloud 12. The verification information VI-n includes, for example, the hash value of the certification information VC-n. For example, as illustrated in Figure 7B, verification information VI-n includes, for example, the hash value of the body VCbody-n of the certification information VC-n (key: hash(VCbody-n)) 101a-n, the user DID (issure: userDID-n) 101b-n that identifies the user 1000-n who issued the certification information VC-n, the product DID (id: productDID-n) 101c-n of the product Pn, the expiration date and time (issue date) of the certification information VC-n (issuanceDate: XXXX) 101d-n, the expiration date and time (expirationDate: XXXX) of the certification information VC-n (expirationDate: XXXX) 101e-n, and the status (status: XXXX) 101f-n that indicates the validity of the certification information VC-n. The user DID 101b-n, the product DID 101c-n of product Pn, the expiration start date and time 101d-n of certification information VC-n, and the expiration end date and time 101e-n of certification information VC-n are, for example, the user DID 100a-n, the product DID 100d-n of product Pn, the expiration start date and time 100b-n of certification information VC-n, and the expiration end date and time 100c-n of certification information VC-n, which are included in the body VCbody-n of certification information VC-n. The status 101f-n indicates whether certification information VC-n is valid (True) or invalid (False). The initial value of status 101f-n is valid (True). For example, user 1000-n, the issuer of certificate information VC-n, can use terminal device 11-n to access the verifiable data registry 121 and, at any time, switch the status 101f-n of certificate information VC-n registered in the verifiable data registry 121 to invalid (False). Verification information VI-n is registered in the verifiable data registry 121 on blockchain 120 using the hash value (key: hash(VC-n)) 101a-n as the key.For example, when registering and updating verification information VI-n (updating status 101f-n), the following restrictions are imposed on the verifiable data registry 121. When registering verification information VI-n: Registration is accepted only if the address corresponding to the user DID (issure:userDID-n) 101b-n of the entered verification information VI-n matches the address calculated from the signature value of the transaction for registering the information to the verifiable data registry 121 on blockchain 120. When updating verification information VI-n: An update of verification information VI-n is accepted only if the address calculated from the signature value of the transaction for updating the information to the verifiable data registry 121 on blockchain 120 matches the address corresponding to the user DID (issure:userDID-n) 101b-n of verification information VI-n on the verifiable data registry 121, which is identified using the hash value (key:hash(VC-n)) 101a-n as the key. For example, in updating verification information VI-n, the only updatable property is status 101f-n. However, this does not limit the present invention.

[0031] Furthermore, the verification information VI-n corresponding to the certification information VC-n is equivalent to the "second verification information corresponding to the second certification information" and is registered in the verifiable data registry 121. In addition, upstream products P-ρ1(n), ..., P-ρ of product Pn θ(n) (n) Proof information VC-ρ1(n), ...,VC-ρ θ(n) (n) may correspond to the "first proof information," and the proof information VC-ρ1(n), ...,VC-ρ θ(n) Verification information corresponding to (n) VI-ρ1(n), ..., VI-ρ θ(n) (n) may correspond to the "first verification information corresponding to the first proof information". Verification information VI-ρ1(n),…,VI-ρ θ(n) (n) (First Verification Information) is also registered in the verifiable data registry 121.

[0032] <Hierarchical VC Verification Process> The hierarchical VC verification process of this embodiment will be explained using Figures 1, 2, 4 to 8. The hierarchical VC verification process of this embodiment may be executed before the hierarchical VC issuance process, during the hierarchical VC issuance process, after the hierarchical VC issuance process, or at a timing unrelated to the hierarchical VC issuance process. Furthermore, the hierarchical VC verification process may be executed each time the hierarchical VC issuance process is performed, or it may not be executed. Furthermore, the hierarchical VC verification process may be executed on all terminal devices 11-1, ..., 11-N, or it may be executed on only one of the terminal devices 11-n (where n ∈ {1, ..., N}). Here, as an example, when terminal device 11-n performs the hierarchical VC issuance process, the proof information VC-i (where i ∈ {VC-ρ1(n), ..., VC-ρ θ(n) An example of executing a hierarchical VC verification process for}) is described below. However, this does not limit the present invention, and the terminal device 11-n may execute a hierarchical VC verification process for other proof information VC-m (where m∈{1,…,N}) at other times.

[0033] Step S1141-n: As illustrated in Figure 4, the verification unit 114-n of the terminal device 11-n (Figure 2) that performs hierarchical VC verification processing extracts the certification information VC-i that is the target of the hierarchical VC verification processing from the certification information storage unit 111b-n. The verification unit 114-n calls and performs <hierarchical VC recursive verification with certification information VC-i as an argument>, and the verification result storage unit 115-n stores the returned result as the verification result RE-i of the certification information VC-i in the verification result storage unit 111c-n.

[0034] As mentioned above, the proof information VC-i may correspond to "second proof information for proving a second object in circulation based on at least the first object in circulation." The verification result RE-i may correspond to "the verification result of the second proof information." Proof information VC-ρ1(i),...,VC-ρ θ(i) (i) (First proof information) refers to products P-ρ1(i), ..., P-ρ θ(i)(i) The user DID (issuedTo: userDID-i) 100e-ρ1(i), …, 100e-ρ that identifies the user 1000-i who is the recipient of (the first circulation target). θ(i) (i) May include an identifier (such as "*", etc.) (the first identifier) that indicates being provided to (the first identifier) or any recipient. The proof information VC-i (the second proof information) includes at least the proof information VC-ρ1(i), …, VC-ρ θ(i) (i) Includes the inheritance proof information list 100g-i (information) for specifying (the first proof information). Furthermore, the proof information VC-i (the second proof information) includes the user DID 100a-i (the second identifier that identifies at least one of the provider of the second circulation target or the generator of the second proof information or the registrant of the second verification information corresponding to the second proof information) that identifies the user 1000-i who is the issuer of the proof information VC-i. The verification information VI-i corresponding to the proof information VC-i corresponds to "the second verification information corresponding to the second proof information" and is registered in the verifiable data registry 121. Also, the proof information VC-ρ1(i), …, VC-ρ θ(i) (i) of the products P-ρ1(i), …, P-ρ θ(i) (i) upstream of the product P-i may correspond to "the first proof information", and the verification information VI-ρ1(i), …, VI-ρ θ(i) (i) may correspond to "the first verification information corresponding to the first proof information". The verification information VI-ρ1(i), …, VI-ρ θ(i) (i) (the first verification information) is also registered in the verifiable data registry 121. θ(i) (i)

[0035] Step S1142-n: The verification result RE-i of the proof information VC-i stored in the verification result storage unit 111c-n is sent to the output unit 117-n, and the output unit 117-n outputs the verification result of the proof information VC-i.

[0036] <Hierarchical VC recursive verification with VC-i as an argument (Step S1141-n)> Step S1141a-n: The verification unit 114-n obtains the certification information VC-i from the certification information storage unit 111b-n. If the certification information VC-i is encrypted, the verification unit 114-n decrypts (decodes) the ciphertext of the certification information VC-i to obtain the certification information VC-i.

[0037] Step S1141b-n: The verification unit 114-n initializes the verification result (e.g., verification result object) RE-i of the proof information VC-i. For example, the verification unit 114-n sets the initial value of the verification result of the proof information VC-i as follows. (1) Product DID (productDid): The DID of product Pi (2) Authenticity verification result (credentialExists): null (3) Expiration date verification result (isNotExpired): null (4) Status verification result (isNotRevoked): null (5) Issuer Signature Validation Result: null (6) Issuer validity verification result (issuerAuthorityValid): null (7) Product Information (productInfo): null (8) List of Inheritance Verification Results: [] Here, (1) Product DID is the field where the Product DID of the certification information VC-i (i.e., Product DID100d-i (credentialSubject.id) in Figure 6B) is set. (2) Authenticity Verification Result is the field where the verification result of whether or not the certification information VC-i is authentic is set. (3) Expiration Date Verification Result is the field where the verification result of whether or not the certification information VC-i is within its expiration date is set. (4) Status Verification Result is the field where the status of the verification information VI-i corresponding to the certification information VC-i is set to be valid or invalid. (5) Issuer Signature Value Verification Result is the field where the signature verification result of the certification information VC-i is set. (6) Issuer Legitimacy Verification Result is the field where the issuer of the certification information VC-i is set to be legitimate. The initial value for all of these is null. (7) Product Information is the field where product information for product Pi registered in the verifiable data registry 121 exists, and the initial value is null. (8) The list of inheritance proof information verification results is the list of proof information VC-ρ1(i), ..., VC-ρ identified in the inheritance proof information list of proof information VC-i. θ(i) This is the field where the verification result of (i) is set, and the initial value is an empty array (inheritances:[]).

[0038] Step S1141c-n: (a) The verification unit 114-n generates a hash value hash(VCbody-i) of the main body VCbody-i of the proof information VC-i. (b) The verification unit 114-n obtains verification information VI-i from the verifiable data registry 121 using the hash value hash(VCbody-i) as the key, and obtains the following information (Figure 7B). ·User DID(issure:userDID-i)101b-i Product DID (id:productDID-i) 101c-i • Expiration date and time (issuaiceDate:XXXX) 101d-i • Expiration Date (XXXX): 101e-i • Status (status:XXXX) 101f-i (c) The verification unit 114-n sets the following in each field (each property) of the verification result of the certification information VC-i. ·Authenticity Verification Result: If the verification information VI-i can be obtained from the verifiable data registry 121 using the hash value hash(VCbody-i) as the key in process (b), then True is assigned to (2) Authenticity Verification Result; otherwise, False is assigned to (2) Authenticity Verification Result (Authenticity Verification of Proof Information VI-i). This allows, for example, the proof information VC-i of product Pi and the proof information VC-ρ1(i), ..., VC-ρ contained in the proof information VC-i to be verified. θ(i) (i) can be verified to confirm that it was not tampered with. · Expiry Verification Result: If the date and time when the process in step S1141c-n is performed is greater than or equal to the date and time specified by the expiration start date and time 101d-i, and less than the date and time specified by the expiration end date and time 101e-i, then (3) True is assigned to the expiration verification result; otherwise, (3) False is assigned to the expiration verification result. Note that if verification information VI-i has not been obtained, then (3) False is assigned to the expiration verification result (validation of the expiration of verification information VI-i). This results in the certification information VC-i of product Pi and the certification information VC-ρ1(i), ..., VC-ρ contained in the certification information VC-i. θ(i) (i) can be verified to be within its validity period. • Status Verification Result: If the status represented in status 101f-i is valid, assign True to (4) Status Verification Result; otherwise, assign False to (4) Status Verification Result. Note that if verification information VI-i could not be obtained, assign False to (4) Status Verification Result (Status Verification of Verification Information VI-i). This will verify the certification information VC-i of product Pi and the certification information VC-ρ1(i),…,VC-ρ contained in certification information VC-i. θ(i) (i) can be determined to be valid or not. · Issuer signature value verification result: If the verification result of the digital signature VCproof-i on the main body VCbody-i of the certification information VC-i is correct, (5) True is substituted into Issuer signature value verification result; otherwise, (5) False is substituted into Issuer signature value verification result. The verification unit 114-n performs this signature verification using, for example, the public key PK-i obtained from the verifiable data registry 121 of the blockchain 120. However, if the public key PK-i can be identified from some information (for example, the main body VCbody-i and the digital signature VCproof-i), the verification unit 114-n may perform this signature verification using the identified public key PK-i. For example, if the public key PK-i corresponds to the address of a user assigned to the terminal device 11-i, as in the Ethereum method, this signature verification may be performed by checking the consistency between the user address calculated from the public key PK-i and the user address corresponding to user DID 101b-i (signature verification of verification information VI-i). • Product Information: If product information for product Pi can be retrieved from the verifiable data registry 121 using the product DID of product Pi as the key, assign it to (7) Product Information. If it cannot be retrieved, leave it as null or assign an empty object or empty string. Alternatively, if the retrieved product information for product Pi corresponds to the unique certification information 100f-i of product Pi in the verification information VI-i (for example, a match), assign True to (7) Product Information; otherwise, assign False to (7) Product Information.

[0039] In other words, the verification unit 114-n verifies at least whether the proof information VC-i (second proof information) corresponds to the verification information VI-i (second verification information).

[0040] Step S1141d-n: Verification unit 114-n is the inheritance certificate information list of certificate information VC-i (inheritances:[VC-ρ1(n),...,VC-ρ θ(n)(n)]) Determine whether the number of elements in 100g-i is one or more (θ(n)≧1. If the number of elements is one or more, proceed to step S1141e-n. On the other hand, if the number of elements is not one or more, (6) Substitute True into the Issuer validity verification result and proceed to step S1141f-n.

[0041] Step S1141e-n: Each element of the inheritance proof information list of VC-i is VC-j ∈ {VC-ρ1(i), ..., VC-ρ θ(i) (i)} Repeat the following steps S1141ea-n to S1141ed-n.

[0042] Step S1141ea-n: Verification unit 114-n is the proof information VC-j ∈ {VC-ρ1(i), ..., VC-ρ} which is an element of the inherited proof information list 100g-i of proof information VC-i. θ(i) (i)} is obtained. If the certification information VC-j is described in the certification information VC-i, the verification unit 114-n obtains the certification information VC-j from the certification information VC-i. If the link destination of element VC-j is described in the certification information VC-i, the verification unit 114-n obtains the certification information VC-j from that link destination. If the certification information VC-j is encrypted, the verification unit 114-n decrypts the ciphertext of the certification information VC-j and obtains the certification information VC-j.

[0043] Step S1141eb-n: The verification unit 114-n substitutes True into the (6) Issuer validity verification result when the user DID (first identifier) that identifies the user 1000-ω(j) who is the recipient of the product P-j represented by the user DID100e-j of the proof information VC-j matches the user DID (second identifier) that identifies the user 1000-i who is the issuer of the proof information VC-i represented by the user DID100a-i of the proof information VC-i, or when the proof information VC-j is an identifier (e.g., "*") indicating that the product P-j is provided to an arbitrary recipient, and substitutes False into the (6) Issuer validity verification result otherwise (validity verification of the proof information VC-i). That is, the verification unit 114-n verifies at least whether the first identifier corresponds to the second identifier. Thereby, it can be verified that the proof information VC-i of the product P-i and the proof information VC-ρ1(i), …, VC-ρ θ(i) (i) was properly issued

[0044] Step S1141ec-n: The verification unit 114-n calls and executes <hierarchical VC recursive verification with VC-j as an argument>. This process is the process in which i in <hierarchical VC recursive verification with VC-i as an argument> is replaced with j. That is, the verification unit 114-n verifies at least whether the first proof information corresponds to the first verification information.

[0045] Step S1141ed-n: The verification unit 114-n adds the verification result RE-j of the proof information VC-j returned by <hierarchical VC recursive verification with VC-j as an argument> to the (8) inheritance proof information verification result list of the proof information VC-i.

[0046] When the above step S1141e-n ends, the process proceeds to step S1141f-n. Step S1141f-n: The verification unit 114-n returns the verification result RE-i of the proof information VC-i to the caller of <hierarchical VC recursive verification with VC-i as an argument>.

[0047] Figure 8 shows an example of the verification result RE-i for the certification information VC-i. In this example, the verification result RE-i has the respective verification results substituted into the fields for Product DID (productDid) 102a-i, Authenticity Verification Result (credentialExists) 102b-i, Expiration Date Verification Result (isNotExpired) 102c-i, Status Verification Result (isNotRevoked) 102d-i, Issuer Signature Value Verification Result (issuerSignatureValid) 102e-i, Issuer Validity Verification Result (issuerAuthorityValid) 102f-i, and Product Information (productInfo) 102g-i. Furthermore, the inheritances verification result list (inheritances) 102h-i is recursively populated with the verification results RE-ρ1(i), RE-ρ2(i), RE-ρ3(i)… of the proof information VC-ρ1(i), VC-ρ2(i), VC-ρ3(i)… identified in the inheritances verification list 100g-i of proof information VC-i. For example, if there is proof information identified in the inheritances verification list 100g-ρ1(i) of proof information VC-ρ1(i), the verification result of that proof information is also populated with the inheritances verification result list (inheritances) 102h-i.

[0048] [Second Embodiment] In this embodiment, a specific example of the first embodiment is provided. <Hierarchical VC Issuance Process> Figure 9 illustrates an example of a hierarchical VC issuance process. The terminal device 11-1 of user 1000-1 handling product P-1 generates certification information VC-1 (Figure 3: steps S1121-1 to S1134-1), registers verification information VI-1 corresponding to the certification information VC-1 in the verifiable data registry 121 of blockchain 120 (Figure 3: step S1135-1), and provides the certification information VC-1 to user 1000-3 handling product P-3 together with product P-1. The certification information VC-1 includes a user DID (issuer: userDID-1) that identifies user 1000-1, the issuer of the certification information VC-1, and an identifier (issuedTo: *) that indicates that product P-1 is provided to any recipient.

[0049] The terminal device 11-2 of user 1000-2 handling product P-2 generates certification information VC-2 (Figure 3: steps S1121-2 to S1134-2), registers verification information VI-2 corresponding to the certification information VC-2 in the verifiable data registry 121 (Figure 3: step S1135-2), and provides the certification information VC-2 to user 1000-3 handling product P-3 together with product P-2. The certification information VC-2 includes a user DID (issuer:userDID-2) that identifies user 1000-2, the issuer of the certification information VC-2, and a user DID (issuedTo:userDID-3) that identifies user 1000-3, the recipient of product P-2.

[0050] The terminal device 11-3 of user 1000-3 handling product P-3 generates certification information VC-3 (Figure 3: steps S1121-3 to S1134-3), registers verification information VI-3 corresponding to the certification information VC-3 in the verifiable data registry 121 (Figure 3: step S1135-3), and provides the certification information VC-3 to user 1000-4 handling product P-4 together with product P-3. The certification information VC-3 includes certification information VC-1 and VC-2, a user DID (issuer:userDID-3) that identifies user 1000-3, the issuer of the certification information VC-3, and a user DID (issuedTo:userDID-4) that identifies user 1000-4, the recipient of product P-3.

[0051] The terminal device 11-4 of user 1000-4 handling product P-4 generates certification information VC-4 (Figure 3: steps S1121-4 to S1134-4), registers verification information VI-4 corresponding to the certification information VC-4 in the verifiable data registry 121 (Figure 3: step S1135-4), and provides the certification information VC-4 to user 1000-5 together with product P-5. The certification information VC-4 includes certification information VC-3, a user DID (issuer:userDID-4) that identifies user 1000-4, the issuer of the certification information VC-4, and a user DID (issuedTo:userDID-5) that identifies user 1000-5, the recipient of product P-4.

[0052] Figure 10 shows an example of certification information VC-n. The main body VCbody-n of the certification information VC-n exemplified in Figure 10 includes the user DID (issuer:did:ethr:12345:0x1234567890123456789012345678901234567890)100a-n, which identifies user 1000-n, the issuer of the certification information VC-n, and the expiration start date and time (issuanc eDate:2023-04-13T15:00:00.000Z)100b-n, Expiration Date and Time of Certificate Information VC-n (expirationDate:2023-12-31T15:00:00.000Z)100c-n, Product DID of Product Pn (id:did:ethr:12345:0x2345678901234567890123456789 It includes 012345678901)100d-n, user DID (issuedTo:did:ethr:12345:0x34567890123456789012345678901234567890123456789012)100e-n, product Pn's unique certification information (originalInfo:{.......})100f-n, and inheritance certification information list (inheritances:[eyJhbGciOiJFUzI1NksiLCJ0eXA…",“eyJhbGciOiJFUzI1NksiLCJ0eXAi…”])100g-n. The electronic signature VCproof-n of the certification information VC-n exemplified in Figure 10 is an electronic signature on this main body VCbody-n.

[0053] <Hierarchical VC Verification Process> Figure 11 illustrates an example of a hierarchical VC issuance process. Here, we describe an example in which user 1000-5 uses terminal device 11-5 to verify the certificate information VC-4.

[0054] The terminal device 11-5 of user 1000-5 generates a hash value hash(VCbody-4) of the main body VCbody-4 of the certification information VC-4, retrieves verification information VI-4 from the verifiable data registry 121 using the hash value hash(VCbody-4) as the key, performs at least the authenticity verification of the certification information VC-4, and assigns the result to the verification result (Figure 5: Steps S1141a-5 to S1141c-5). In addition, the terminal device 11-5 retrieves certification information VC-3 from the inherited certification information list of certification information VC-4, performs the validity verification of certification information VC-4 using "issuedTo:userDID-4" of certification information VC-3 and "issuer:userDID-4" of certification information VC-4, and assigns the result to the verification result. Through these steps, the verification result RE-4 of certification information VC-4 is obtained (Figure 5: Steps S1141d-5 to S1141e-5).

[0055] Next, terminal device 11-5 generates a hash value hash(VCbody-3) of the main body VCbody-3 of the certification information VC-3, retrieves verification information VI-3 from the verifiable data registry 121 using the hash value hash(VCbody-3) as the key, performs at least the authenticity verification of certification information VC-3, and assigns the result to the verification result (Figure 5: Steps S1141a-5 to S1141c-5). In addition, terminal device 11-5 retrieves certification information VC-1 and VC-2 from the inherited certification information list of certification information VC-3, performs the validity verification of certification information VC-3 using "issuedTo:*" from certification information VC-1, "issuedTo:userDID-3" from certification information VC-2, and "issuer:userDID-3" from certification information VC-3, and assigns the result to the verification result. These steps yield the verification result RE-3 of the proof information VC-3, and the verification result RE-3 is added to the inherited proof information verification result list of verification result RE-4 (Figure 5: Steps S1141d-5 to S1141e-5).

[0056] Next, terminal device 11-5 generates a hash value hash(VCbody-2) of the main body VCbody-2 of the certification information VC-2, retrieves verification information VI-2 from the verifiable data registry 121 using the hash value hash(VCbody-2) as the key, performs at least the authenticity verification of the certification information VC-2, and assigns the result to the verification result (Figure 5: Steps S1141a-5 to S1141c-5). Through these steps, the verification result RE-2 of the certification information VC-2 is obtained, and the verification result RE-2 is added to the inherited certification information verification result list of verification result RE-3 (Figure 5: Steps S1141d-5 to S1141e-5).

[0057] Next, terminal device 11-5 generates a hash value hash(VCbody-1) of the main body VCbody-1 of the certification information VC-1, retrieves verification information VI-1 from the verifiable data registry 121 using the hash value hash(VCbody-1) as the key, performs at least the authenticity verification of certification information VC-1, and substitutes the result into the verification result (Figure 5: Steps S1141a-5 to S1141c-5). Through these steps, verification result RE-1 of certification information VC-1 is obtained, and verification result RE-1 is added to the inherited certification information verification result list of verification result RE-3 (Figure 5: Steps S1141d-5 to S1141e-5). Through these steps, the final verification result RE-4 is obtained.

[0058] Figure 12 shows an example of verification result RE-i. In the example verification result RE-i shown in Figure 12, "did:ethr:12345:0xdddddddddddddddddddddddddddddddddddddddd" is assigned to product DID (productDid) 102a-i, "true" is assigned to authenticity verification result (credentialExists) 102b-i, "true" is assigned to expiration verification result (isNotExpired) 102c-i, "true" is assigned to status verification result (isNotRevoked) 102d-i, "true" is assigned to issuerSignatureValid verification result (issuerSignatureValid) 102e-i, "true" is assigned to issuerAuthorityValid verification result (issuerAuthorityValid) 102f-i, and "did": The following is assigned: "did:ethr:12345:0xdddddddddddddddddddddddddddddddddddddd","manufacture": "did:ethr:12345:0x4444444444444444444444444444444444444444","name": "package-04","metadata"", and the inheritance proof verification result list (inheritances) 102h-i is assigned: "[{RE-ρ1(i)},{RE-ρ2(i)},{RE-ρ3(i)} …]}".

[0059] <Example 1 of hierarchical VC verification results (Figures 13 and 14)> The following examples illustrate the results of hierarchical VC verification using a specific example of this configuration. As illustrated in Figure 13, in this example, user 1000-4 commits fraud during the hierarchical VC issuance process, creating a certificate information VC-3X by altering "originalInfo:product-3" in certificate information VC-3 to "originalInfo:product-3X", and generating certificate information VC-4 containing the fraudulent certificate information VC-3X. When hierarchical VC verification is performed on such certificate information VC-4, the authenticity verification result for certificate information VC-3X becomes False, as illustrated in Figure 14. This allows detection that some kind of fraud occurred with respect to certificate information VC-4 issued by user 1000-4.

[0060] <Example 2 of hierarchical VC verification results (Figures 15 and 16)> As illustrated in Figure 15, in this example, user 1000-X, who is different from user 1000-4, the original recipient of the original certification information VC-3, illegally obtained certification information VC-3 and generated certification information VC-4. Therefore, the user DID that identifies the issuer of certification information VC-4 is "issuer:userDID-X". When hierarchical VC verification is performed on such certification information VC-4, the validity verification result for certification information VC-4 becomes False, as illustrated in Figure 16. This allows detection that user 1000-X illegally used certification information VC-3.

[0061] <Example 3 of Hierarchical VC Verification Results (Figures 17 and 18)> As illustrated in Figure 17, in this example, user 1000-3 commits fraud during the hierarchical VC issuance process, altering "originalInfo:product-1" in certificate information VC-1 contained in certificate information VC-3 to "originalInfo:product-1X" to generate certificate information VC-1X, and generating certificate information VC-3 containing the fraudulent certificate information VC-1X. Furthermore, user 1000-X, who is different from user 1000-4, the intended recipient of the original certificate information VC-3, fraudulently obtains certificate information VC-3 and generates certificate information VC-4. Therefore, the user DID that identifies the issuer of certificate information VC-4 is "issuer:userDID-X". When hierarchical VC verification is performed on such certificate information VC-4, as illustrated in Figure 18, the validity verification result for certificate information VC-4 becomes False, and the authenticity verification result for certificate information VC-1X also becomes False. This makes it possible to detect if there was any fraudulent activity regarding the certificate information VC-3 issued by user 1000-3, or if user 1000-X misused the certificate information VC-3.

[0062] <Example 3 of hierarchical VC verification results (Figure 19)> As illustrated in Figure 19, in this example, the hierarchical VC issuance process was performed correctly, but later the status of the certification information VC-1 was invalidated (False) by user 1000-1's terminal device 11-1. When hierarchical VC verification is performed on such certification information VC-4, the status verification result of certification information VC-1 becomes False.

[0063] <Timing of hierarchical VC verification> As mentioned above, hierarchical VC verification may be performed before the hierarchical VC issuance process, during the hierarchical VC issuance process, after the hierarchical VC issuance process, or at a time unrelated to the hierarchical VC issuance process. Furthermore, hierarchical VC verification may or may not be performed with each hierarchical VC issuance process. Figure 20A illustrates the process when hierarchical VC verification is performed with each hierarchical VC issuance process, as in the example in Figure 11. Figure 20B conceptually shows the verification results in this case. Note that if it simply says "true", it indicates that all verifications were successful.

[0064] <Example 1 of hierarchical VC verification results (Figures 13 and 14)> Figure 21A illustrates the process when the hierarchical VC verification process is executed each time a hierarchical VC is issued, as illustrated in Example 1 of the hierarchical VC verification results in Figures 13 and 14. Figure 21B conceptually shows the verification results in this case.

[0065] <Example 2 of hierarchical VC verification results (Figures 15 and 16)> Figure 22A illustrates the process in Example 2 of the hierarchical VC verification results illustrated in Figures 15 and 16, where the hierarchical VC verification process is executed each time a hierarchical VC is issued. Figure 22B conceptually shows the verification results in this case.

[0066] <Example 3 of hierarchical VC verification results (Figures 17 and 18)> Figure 23A illustrates the process in Example 3 of the hierarchical VC verification results illustrated in Figures 17 and 18, where the hierarchical VC verification process is executed each time a hierarchical VC is issued. Figure 23B conceptually shows the verification results in this case.

[0067] <Example 3 of hierarchical VC verification results (Figure 19)> Figure 24A illustrates the process when the hierarchical VC verification process is executed each time a hierarchical VC is issued, as illustrated in Example 3 of the hierarchical VC verification results in Figure 19. Figure 24B conceptually shows the verification results in this case.

[0068] [Hardware configuration] In each embodiment, the terminal device 11-n is a device configured by a general-purpose or dedicated computer, for example, equipped with a processor (hardware processor) such as a CPU (central processing unit) and memory such as RAM (random-access memory) and ROM (read-only memory), executing a predetermined program. That is, the terminal device 11-n in each embodiment has, for example, a processing circuitry configured to implement each of its respective parts. This computer may have one processor and memory, or it may have multiple processors and memories. This program may be installed on the computer, or it may be pre-recorded in ROM, etc. Furthermore, some or all of the processing units may be configured using electronic circuits that realize processing functions independently, rather than electronic circuits that realize functional configuration by loading a program, such as a CPU. Also, the electronic circuits that constitute one device may include multiple CPUs.

[0069] Figure 25 is a block diagram illustrating the hardware configuration of the terminal device 11-n in each embodiment. As illustrated in Figure 25, the terminal device 11-n in this example has a CPU (Central Processing Unit) 10a, an input unit 10b, an output unit 10c, a RAM (Random Access Memory) 10d, a ROM (Read Only Memory) 10e, an auxiliary storage device 10f, a communication unit 10h, and a bus 10g. The CPU 10a in this example has a control unit 10aa, an arithmetic unit 10ab, and a register 10ac, and performs various arithmetic processing according to various programs loaded into the register 10ac. The input unit 10b is an input terminal, keyboard, mouse, touch panel, etc., to which data is input. The output unit 10c is an output terminal, display, etc., to which data is output. The communication unit 10h is a LAN card, etc., controlled by the CPU 10a which has loaded a predetermined program. Furthermore, RAM 10d is an SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), etc., and has a program area 10da where a predetermined program is stored and a data area 10db where various data is stored. Furthermore, auxiliary storage device 10f is, for example, a hard disk, MO (Magneto-Optical disc), semiconductor memory, etc., and has a program area 10fa where a predetermined program is stored and a data area 10fb where various data is stored. Furthermore, bus 10g connects CPU 10a, input unit 10b, output unit 10c, RAM 10d, ROM 10e, and auxiliary storage device 10f so that information can be exchanged. CPU 10a writes the program stored in the program area 10fa of auxiliary storage device 10f to the program area 10da of RAM 10d according to the loaded OS (Operating System) program. Similarly, CPU 10a writes various data stored in the data area 10fb of auxiliary storage device 10f to the data area 10db of RAM 10d. Then, the address on RAM10d where this program and data are written is stored in register 10ac of CPU10a.The control unit 10aa of the CPU 10a sequentially reads these addresses stored in register 10ac, reads programs and data from the area on RAM 10d indicated by the read addresses, sequentially has the arithmetic unit 10ab execute the calculations indicated by the programs, and stores the calculation results in register 10ac. This configuration realizes the functional configuration of the terminal device 11-n.

[0070] The above-mentioned program can be recorded on a computer-readable recording medium. Examples of computer-readable recording media are non-transitory recording media. Examples of such recording media include magnetic recording devices, optical discs, magneto-optical recording media, and semiconductor memory.

[0071] The distribution of this program can be carried out, for example, by selling, transferring, or lending portable recording media such as DVDs or CD-ROMs on which the program is recorded. Furthermore, the program may be distributed by storing it in the storage device of a server computer and transferring it from the server computer to other computers via a network. As described above, a computer executing such a program may, for example, first store the program recorded on the portable recording media or the program transferred from the server computer in its own storage device. Then, when processing is to be executed, this computer reads the program stored in its own storage device and executes the processing according to the program it reads. Alternatively, as another form of execution of this program, the computer may directly read the program from the portable recording media and execute the processing according to that program, or it may sequentially execute the processing according to the program received each time a program is transferred to this computer from the server computer. Furthermore, the above processing may be executed by a so-called ASP (Application Service Provider) type service, which does not transfer the program from the server computer to this computer, but realizes the processing function only by issuing execution instructions and obtaining results. Furthermore, the term "program" in this form includes information used for processing by an electronic computer that is equivalent to a program (data, etc., that is not a direct instruction to the computer but has the property of defining the computer's processing).

[0072] In this example, the device is configured by executing a predetermined program on a computer; however, at least a portion of these processes may be implemented in hardware.

[0073] [Differentiation] It should be noted that the present invention is not limited to the embodiments described above. For example, at least one of the following may be omitted from the main body VCbody-n of the certification information VC-n (Figure 6B): the start date and time of the expiration of the certification information VC-n (issuanceDate:XXXX) 100b-n, the end date and time of the expiration of the certification information VC-n (expirationDate:XXXX) 100c-n, or the unique certification information of product Pn (originalInfo:product-n) 100f-n. Also, at least one of the following may be omitted from the verification information VI-n (Figure 7B): the start date and time of the expiration of the certification information VC-n (issue date) (issuanceDate:XXXX) 101d-n, the end date and time of the expiration of the certification information VC-n (expirationDate:XXXX) 101e-n, or the status representing the validity of the certification information VC-n (status:XXXX) 101f-n. Furthermore, at least one of the aforementioned expiration verification, status verification, signature verification, or legitimacy verification may be omitted. In that case, these verification results will also be omitted from the verification results.

[0074] Information stored in the verifiable data registry 121 on the cloud 12 may also be stored on the server.

[0075] Furthermore, in the above embodiment, if verification information VI-i can be obtained from the verifiable data registry 121 using the hash value hash(VCbody-i) as the key in the process of step S1141c-n(b), then the authenticity verification result is True, i.e., it is determined that the proof information VC-i is authentic. However, this does not limit the present invention, and as long as it is possible to verify whether or not the proof information VC-i corresponds to the verification information VI-i, the authenticity of the proof information VC-i can be determined by other methods. For example, the proof information VC-i and the verification information VI-i can be compared, and if they match, the proof information VC-i can be determined to be authentic; if they do not match, the proof information VC-i can be determined to be inauthentic. Alternatively, for example, the function value of the proof information VC-i and the function value of the verification information VI-i can be compared, and if they match, the proof information VC-i can be determined to be authentic; if they do not match, the proof information VC-i can be determined to be inauthentic.

[0076] Furthermore, the various processes described above may not only be executed in chronological order as described, but may also be executed in parallel or individually as needed, depending on the processing capacity of the device performing the processes. It goes without saying that other modifications can be made as appropriate without departing from the spirit of the present invention. [Explanation of Symbols]

[0077] 11 Terminal device 113 Certification Information Generation Unit 114 Verification Department 115 Verification Result Storage Unit 12 Cloud 121 Verifiable Data Registry

Claims

1. A certification information generation unit that generates a second certification information for proving a second distribution target based on at least the first distribution target, using first certification information for proving a first distribution target, It includes a registration processing unit that registers second verification information corresponding to the second certification information, The second certification information includes at least information for identifying the first certification information, The first verification information corresponding to the first certification information is registered, The first certification information includes a first identifier that identifies a legitimate recipient of the first distribution item, which is set when the first certification information is generated by at least one of the providers of the first distribution item, the generator of the first certification information, or the registrant of the first verification information corresponding to the first certification information. The second certification information includes a second identifier that identifies at least one of the providers of the second distribution subject, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information, The terminal device comprises a certification information generation unit which generates main body information which includes information for identifying the first certification information which includes the first identifier, and a terminal device which generates the second certification information by attaching an electronic signature to the main body information.

2. A verification unit that verifies second proof information to prove that a second distribution object is based on at least a first distribution object, A verification result storage unit for storing the verification results of the second proof information, It has, The second certification information includes at least information for identifying the first certification information for certifying the first object of circulation, At least the first verification information corresponding to the first certification information and the second verification information corresponding to the second certification information are registered in an external storage area. The first certification information includes a first identifier that identifies a legitimate recipient of the first distribution item, which is set when the first certification information is generated by at least one of the providers of the first distribution item, the generator of the first certification information, or the registrant of the first verification information corresponding to the first certification information. The second certification information includes a second identifier that identifies at least one of the providers of the second distribution subject, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information, The verification unit is a terminal device that verifies at least whether the second certification information corresponds to the second verification information, whether the first certification information corresponds to the first verification information, and whether the first identifier corresponds to the second identifier.

3. A method for generating certification information using a terminal device, A certification information generation step in which a certification information generation unit generates a second certification information for proving a second distribution object based on at least the first distribution object, using first certification information for proving a first distribution object, The registration processing unit includes a registration processing step of registering second verification information corresponding to the second certification information, The second certification information includes at least information for identifying the first certification information, The first verification information corresponding to the first certification information is registered, The first certification information includes a first identifier that identifies a legitimate recipient of the first distribution item, which is set when the first certification information is generated by at least one of the providers of the first distribution item, the generator of the first certification information, or the registrant of the first verification information corresponding to the first certification information. The second certification information includes a second identifier that identifies at least one of the providers of the second distribution subject, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information, A method for generating certification information, wherein the certification information generation step is to generate body information including information for identifying the first certification information including the first identifier, and to generate the second certification information by attaching an electronic signature to the body information.

4. A verification method using terminal equipment, The verification step involves the verification unit verifying second proof information to prove that the second distribution object is based at least on the first distribution object, The verification result storage unit includes a verification result storage step for storing the verification results of the second proof information, The second certification information includes at least information for identifying the first certification information for certifying the first object of circulation, At least the first verification information corresponding to the first certification information and the second verification information corresponding to the second certification information are registered in an external storage area. The first certification information includes a first identifier that identifies a legitimate recipient of the first distribution item, which is set when the first certification information is generated by at least one of the providers of the first distribution item, the generator of the first certification information, or the registrant of the first verification information corresponding to the first certification information. The second certification information includes a second identifier that identifies at least one of the providers of the second distribution subject, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information, Verification method, wherein the verification step comprises at least the steps of verifying whether the second proof information corresponds to the second verification information, verifying whether the first proof information corresponds to the first verification information, and verifying whether the first identifier corresponds to the second identifier.

5. A program for causing a computer to function as a terminal device according to claim 1 or 2.

Images