Information processing method, information processing system, and program

Abstract

Transaction data that includes disclosure propriety information indicating whether the transaction data is to be disclosed to a device external to a distributed ledger system configured from a plurality of limited servers is stored in a distributed ledger held by the distributed ledger system (S801). The transaction data which is stored in the distributed ledger and for which the disclosure propriety information included in the transaction data indicates that the transaction data is to be disclosed to the device external to the distributed ledger system is stored in a storage unit that can be accessed by the device external to the distributed ledger system (S802).

Description

Information processing method, information processing system, and program

[0001] The present invention relates to an information processing method, an information processing system, and a program.

[0002] There is a technology that uses distributed ledgers to store information. Distributed ledgers include public ledgers (also called public chains), private ledgers (also called private chains), and consortium ledgers (also called consortium chains).

[0003] A technique relating to a method for storing automobile maintenance data using a consortium chain has been disclosed (see Patent Document 1).

[0004] Special Publication No. 2022-542134

[0005] If some of the information stored in a private or consortium ledger is made public, it can be difficult to prove the authenticity of that information.

[0006] Therefore, the present invention provides an information processing method, etc. that contributes to proving the authenticity of part of the information stored in a private ledger or consortium ledger when that part of the information is made public.

[0007] An information processing method according to one aspect of the present invention is an information processing method that stores transaction data in a distributed ledger held by a distributed ledger system consisting of a limited number of servers, the transaction data including disclosure information indicating whether the transaction data will be made public to a device external to the distributed ledger system, and stores the transaction data stored in the distributed ledger, the disclosure information included in the transaction data indicating that the transaction data will be made public to a device external to the distributed ledger system, in a storage unit accessible from the device external to the distributed ledger system.

[0008] These comprehensive or specific aspects may be realized as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, or may be realized as any combination of a system, an apparatus, an integrated circuit, a computer program, and a recording medium.

[0009] The present invention contributes to proving the authenticity of some information stored in a private or consortium ledger when that part of the information is made public.

[0010] 1 is a schematic diagram showing the overall configuration of an information processing system according to an embodiment. FIG. 1 is a block diagram showing the functional configuration of a ledger server according to an embodiment. FIG. 2 is an explanatory diagram showing the configuration of transaction data according to an embodiment. FIG. 3 is a block diagram showing the functional configuration of a management server according to an embodiment. FIG. 4 is a block diagram showing the functional configuration of a public server according to an embodiment. FIG. 5 is an explanatory diagram showing the data structure of a blockchain according to an embodiment. FIG. 6 is an explanatory diagram showing information stored in a memory unit of a public server according to an embodiment. FIG. 7 is a sequence diagram showing a first example of processing of an information processing system according to an embodiment. FIG. 8 is a flow diagram showing a first example of processing of a ledger server according to an embodiment. FIG. 9 is a flow diagram showing a first example of processing of a public server according to an embodiment. FIG. 10 is a flow diagram showing a second example of processing of a public server according to an embodiment. FIG. 11 is a flow diagram showing a first example of processing of a terminal according to an embodiment. FIG. 12 is a sequence diagram showing a second example of processing of an information processing system according to an embodiment. FIG. 13 is a sequence diagram showing a third example of processing of an information processing system according to an embodiment. FIG. 14 is an explanatory diagram showing a first modified example of approval information according to an embodiment. FIG. 15 is an explanatory diagram showing a second modified example of approval information according to an embodiment. FIG. 16 is an explanatory diagram showing a list of approvers stored in a memory unit of a public server according to an embodiment. FIG. 17 is a flow diagram showing a second example of processing of a terminal according to an embodiment. FIG. 1 is a flow diagram showing an example of processing of an information processing system in an embodiment; FIG. 2 is an explanatory diagram showing the data structure of a blockchain, which is an example of a distributed ledger; FIG. 3 is an explanatory diagram showing the data structure of transaction data; FIG. 4 is an explanatory diagram showing transaction data related to the execution of a smart contract; FIG. 5 is a flow diagram showing processing related to the execution of a smart contract; and FIG. 6 is an explanatory diagram showing the structures of an NFT and metadata.

[0011] (Findings that Form the Basis of the Present Invention) The present inventors have found the following problems with the technology relating to authentication of information, which is described in the "Background Art" section.

[0012] A public ledger is an open distributed ledger with no restrictions on participation. Information stored in the public ledger is visible to any device participating in the public ledger.

[0013] A private ledger is a distributed ledger in which participation is controlled by a single entity (also known as an administrator). Information stored in a private ledger is visible only to devices that participate in the private ledger, or in other words, only to devices that are authorized to participate by the administrator.

[0014] A consortium ledger is a distributed ledger in which participation is managed by multiple entities (also known as administrators). Information stored in the consortium ledger can be accessed by devices participating in the consortium ledger, or in other words, only by devices authorized by the administrator to participate.

[0015] If part of the information stored in the consortium ledger is made public (in other words, if only part of the information is made public and the rest is not), there is a problem that it is difficult for a device that obtains the made-public information to prove the authenticity of the information.

[0016] In general, the authenticity of information stored in a distributed ledger can be proven based on the fact that the hash value of a block stored in the distributed ledger is stored in another block consecutive to that block, and this relationship holds across multiple consecutive blocks. A device that acquires only a portion of the information stored in the consortium ledger cannot verify the hash values ​​across multiple consecutive blocks. Therefore, it is difficult for a device that acquires only a portion of the information stored in the consortium ledger to prove the authenticity of that information. The above explanation of the consortium ledger also applies to private ledgers.

[0017] Here, making information public means that general devices can access the information through the network, or in other words, it means that the server can transmit the information when it receives a request to obtain the information from a general device through the network.

[0018] Therefore, the present invention provides an information processing method, etc. that contributes to proving the authenticity of part of the information stored in a private ledger or consortium ledger when that part of the information is made public.

[0019] Below, examples of inventions that can be obtained from the disclosure of this specification will be given, and the effects and the like that can be obtained from these inventions will be explained.

[0020] (1) An information processing method comprising: storing transaction data in a distributed ledger held by a distributed ledger system consisting of a limited number of servers, the transaction data including disclosure information indicating whether the transaction data will be made public to a device external to the distributed ledger system; and storing the transaction data stored in the distributed ledger, the disclosure information included in the transaction data indicating that the transaction data will be made public to a device external to the distributed ledger system, in a memory unit accessible from the device external to the distributed ledger system.

[0021] According to the above aspect, transaction data stored in a distributed ledger (private ledger or consortium ledger) that includes disclosure information indicating that the transaction data will be disclosed to devices external to the distributed ledger system can be made accessible to external devices, i.e., made public. The server that owns the distributed ledger can determine whether the disclosed transaction data matches transaction data stored in the distributed ledger, and if they match, the authenticity of the disclosed transaction data can be proven. In this way, the above information processing method contributes to proving the authenticity of information stored in a private ledger or consortium ledger when that information is made public.

[0022] (2) An information processing method according to (1), wherein, when the transaction data is stored in the memory unit, positive information indicating that the first transaction data stored in the distributed ledger matches the second transaction data stored in the memory unit is associated with the second transaction data and stored in the memory unit.

[0023] According to the above aspect, the server that maintains the distributed ledger can make accessible to an external device, i.e., publish, affirmative information indicating that the published second transaction data matches the first transaction data stored in the distributed ledger. A device that obtains the published affirmative information can use the affirmative information to prove the authenticity of the published second transaction data. In this way, the above information processing method contributes to proving the authenticity of part of the information stored in a private ledger or a consortium ledger when that part of the information is made public.

[0024] (3) An information processing method according to (2), wherein, when the transaction data is stored in the memory unit, a first server among the plurality of servers determines whether the first transaction data read from the distributed ledger matches the second transaction data obtained from the memory unit, and if it determines that the first transaction data matches the second transaction data, generates the affirmative information, generates a first digital signature by the first server for the affirmative information, and stores the generated affirmative information and the first digital signature in the memory unit.

[0025] According to the above aspect, when the server that holds the distributed ledger determines that the published second transaction data matches the first transaction data stored in the distributed ledger, the server that holds the distributed ledger generates affirmative information and makes it accessible to an external device, i.e., publishes it, along with a digital signature. As a result, a device that obtains the published affirmative information can prove the authenticity of the published second transaction data based on the server that holds the distributed ledger determining that the published second transaction data matches the first transaction data stored in the distributed ledger. In this way, the above information processing method contributes to proving the authenticity of part of the information stored in a private ledger or a consortium ledger when that part of the information is made public.

[0026] (4) An information processing method according to (3), wherein when generating the positive information, the positive information is further linked to identification information that uniquely indicates a second server among the plurality of servers that is different from the first server.

[0027] According to the above aspect, because the affirmative information is generated by multiple servers, i.e., multiple parties, it can be shown that multiple servers have determined that the published second transaction data matches the first transaction data stored in the distributed ledger. The determination by multiple servers may be more reliable and appropriate than a determination by a single server. This contributes to appropriately verifying the authenticity of information stored in a private ledger or a consortium ledger when that information is made public.

[0028] (5) An information processing method described in (4), in which, when the second transaction data stored in the memory unit is acquired, the reliability of the second transaction data is calculated using the first digital signature and the identification information of the second server, which are linked to the positive information.

[0029] According to the above aspect, the degree of authenticity of the published second transaction data can be more easily obtained by calculating the reliability, which is the degree of authenticity of the published second transaction data, based on multiple servers, i.e., multiple parties, involved in generating the positive information. As a result, the above information processing method contributes to proving the authenticity of part of information stored in a private ledger or a consortium ledger when the part of the information is published.

[0030] (6) An information processing method according to (3), wherein, when generating the positive information, a second digital signature is further generated by a second server among the plurality of servers that is different from the first server, and when storing the positive information and the first digital signature in the memory unit, the second digital signature is stored in the memory unit together with the positive information and the first digital signature.

[0031] According to the above aspect, because the affirmative information is generated by multiple servers, i.e., multiple parties, it can be shown that multiple servers have determined that the published second transaction data matches the first transaction data stored in the distributed ledger. The determination by multiple servers may be more reliable and appropriate than a determination by a single server. This contributes to appropriately verifying the authenticity of information stored in a private ledger or a consortium ledger when that information is made public.

[0032] (7) An information processing method described in (6), in which, when the second transaction data stored in the memory unit is acquired, the reliability of the second transaction data is calculated using the first digital signature and the second digital signature linked to the positive information.

[0033] According to the above aspect, the degree of authenticity of the published second transaction data can be more easily obtained by calculating the reliability, which is the degree of authenticity of the published second transaction data, based on multiple servers, i.e., multiple parties, involved in generating the positive information. As a result, the above information processing method contributes to proving the authenticity of part of information stored in a private ledger or a consortium ledger when the part of the information is published.

[0034] (8) The information processing method described in (1), wherein, when the transaction data is stored in the memory unit, a first server among the plurality of servers determines whether the first transaction data, which is the transaction data stored in the distributed ledger, matches the second transaction data, which is the transaction data stored in the memory unit, and if it determines that the first transaction data does not match the second transaction data, generates negation information, which is information indicating that the first transaction data does not match the second transaction data, generates a first digital signature by the first server for the negation information, and stores the generated negation information and the first digital signature in the memory unit in association with the second transaction data.

[0035] According to the above aspect, if the server that holds the distributed ledger determines that the published second transaction data does not match the first transaction data stored in the distributed ledger, it can generate negation information and make it accessible to external devices, i.e., publish it, along with a digital signature. As a result, a device that obtains the published negation information can determine that the published second transaction data is not authentic based on the server that holds the distributed ledger determining that the published second transaction data does not match the first transaction data stored in the distributed ledger. In this way, the above information processing method contributes to proving the authenticity of part of the information stored in a private ledger or a consortium ledger when that part of the information is made public.

[0036] (9) An information processing method as described in (8), further comprising determining whether the quantity of the negative information stored in the memory unit exceeds a reference value, and if it is determined that the quantity of the negative information stored in the memory unit exceeds the reference value, acquiring the first transaction data and storing it in the memory unit as new second transaction data in place of the second transaction data stored in the memory unit.

[0037] According to the above aspect, the server that publishes the second transaction data can update the published second transaction data with new second transaction data in accordance with the amount of negative information. This contributes to the server publishing valid second transaction data. In this way, the information processing method contributes to updating a portion of the published information.

[0038] (10) An information processing method described in (9), wherein, when acquiring the first transaction data, the negative information generated by the first server including the first transaction data is acquired, and the first transaction data included in the acquired negative information is acquired.

[0039] According to the above aspect, the server that publishes the second transaction data can update the transaction data included in the negation information sent from the server that holds the distributed ledger as new second transaction data. This contributes to the server easily obtaining and publishing valid second transaction data. This contributes to more easily updating the part of information to be published.

[0040] (11) An information processing system comprising: a management server that stores transaction data in a distributed ledger held by a distributed ledger system consisting of a limited number of servers, the transaction data including disclosure information indicating whether the transaction data will be disclosed to devices external to the distributed ledger system; and a public server that stores the transaction data stored in the distributed ledger, the disclosure information included in the transaction data indicating that the transaction data will be disclosed to devices external to the distributed ledger system, in a memory unit accessible from the devices external to the distributed ledger system.

[0041] According to the above aspect, the same effects as those of the above information processing method are achieved.

[0042] (12) A program that causes at least one computer to execute the information processing method described in (1).

[0043] According to the above aspect, the same effects as those of the above information processing method are achieved.

[0044] These comprehensive or specific aspects may be realized as a system, an apparatus, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized as any combination of a system, an apparatus, an integrated circuit, a computer program, or a recording medium.

[0045] Hereinafter, the embodiments will be specifically described with reference to the drawings.

[0046] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present invention. Furthermore, among the components in the following embodiments, components that are not described in the independent claims that represent the highest concepts are described as optional components.

[0047] (Embodiment) In this embodiment, an information processing method and an information processing system that contribute to proving the authenticity of part of information stored in a private ledger or a consortium ledger when that part of information is made public will be described.

[0048] 1 is a schematic diagram showing the overall configuration of an information processing system 1 according to the present embodiment. The information processing system 1 is an example of a system that contributes to verifying the authenticity of part of information stored in a private ledger or a consortium ledger when that part of the information is made public.

[0049] 1 , the information processing system 1 includes a ledger system 10 and a public server 22. A terminal T1 is connected to the information processing system 1. The information processing system 1 may further include a terminal T1. Each of the above devices is connected to a network N and is capable of communicating via the network N.

[0050] The ledger system 10 is an information processing system that stores information using a distributed ledger. The ledger system 10 is also referred to as a distributed ledger system. Various data can be stored in the distributed ledger of the ledger system 10. The data stored in the distributed ledger of the ledger system 10 may be, for example, the generation history of various types of information and the transaction history of the above information. Furthermore, the above data may be the generation history of NFTs (Non-Fungible Tokens) associated with goods or services and the transaction history of the above NFTs.

[0051] The ledger system 10 can execute processes using smart contracts by using a distributed ledger. The ledger system 10 can generate various types of information or NFTs and realize transactions of various types of information or NFTs by using smart contract processes.

[0052] The ledger system 10 includes ledger servers 11, 12, and 13 (also referred to as ledger server 11, etc.) as a server group that holds a distributed ledger, and a management server 20. When at least one of the ledger servers included in the server group receives transaction data, the transaction data is shared by all ledger servers and stored in the distributed ledger. Note that the number of ledger servers 11, etc. is not limited to three, and may be two or more.

[0053] The ledger server 11 is a computer server that holds and manages the distributed ledger. The ledger server 11 holds the distributed ledger and updates it while synchronizing it with other ledger servers (specifically, ledger servers 12 and 13) and the management server 20.

[0054] The ledger servers 12 and 13 are similar to the ledger server 11 and operate independently of the ledger server 11 .

[0055] The management server 20 is a computer server that holds and manages the distributed ledger. The management server 20 holds the distributed ledger and updates it while synchronizing with the ledger server 11, etc. The management server 20 has at least the same functions as the ledger server 11, etc., as functions related to the distributed ledger. The management server 20 also has a function to place a copy of a portion of the information stored in the distributed ledger held by the ledger system 10 on the public server 22, contributing to the public disclosure of a portion of the information.

[0056] The public server 22 is a computer server that stores information and makes the stored information public. The public server 22 can acquire information provided by the management server 20 and make the information public to devices external to the ledger system 10 (e.g., terminal T1).

[0057] The terminal T1 is an information processing device used by a user, and can obtain information published by the public server 22 and present it to the user.

[0058] The terminal T1 includes a processor (e.g., a CPU (Central Processing Unit), hereinafter the same), a memory, a user interface (a display screen, a speaker, a touch panel, etc., hereinafter the same), and a communication interface, and can accept input of information using the user interface or the communication interface, and can generate, display, output audio, or transmit and receive information. The terminal T1 can be, for example, a personal computer, a tablet, or a smartphone.

[0059] The distributed ledger held by the ledger system 10 is a consortium ledger, and this case will be described as an example. In this case, ledger servers 11, 12, and 13 (also referred to as ledger servers 11, etc.) correspond to multiple servers participating in the consortium ledger (in other words, permitted to participate) and thus correspond to multiple limited servers. Ledger servers 11, 12, and 13 may be ledger servers owned by different organizations. For example, ledger server 11 may be a ledger server owned by Company A, ledger server 12 may be a ledger server owned by Company B, and ledger server 13 may be a ledger server owned by Company C. If there are more than three ledger servers 11, etc., the organizations owning ledger servers 11, etc. may be referred to as Company D, Company E, Company F, Company G, etc.

[0060] In addition, the distributed ledger owned by the ledger system 10 may be a private ledger.

[0061] The management server 20 and the public server 22 may be configured as an information processing system 24. The information processing system 24 may be configured as two devices, such as the management server 20 and the public server 22, or may be configured as one device having the functions of both the management server 20 and the public server 22. The information processing system 24 may be configured by three or more devices having the functions of both the management server 20 and the public server 22.

[0062] Fig. 2 is a block diagram showing the functional configuration of the ledger server 11 in this embodiment. Fig. 3 is an explanatory diagram showing the configuration of transaction data in this embodiment.

[0063] The ledger server 11 is an information processing device that includes, as functional units, a communication unit 101, a ledger processing unit 102, an execution unit 103, and a storage unit 104. At least some of the functional units of the ledger server 11 are realized by a processor (e.g., a CPU) of the ledger server 11 executing a program using a memory.

[0064] The communication unit 101 is a communication interface communicatively connected to the network N. The communication unit 101 may be a communication interface of a wired communication standard (e.g., Ethernet (registered trademark) or the like), or may be a communication interface of a wireless communication standard (e.g., Wi-Fi (registered trademark) or the like, or a mobile communication system (3G (3rd Generation), 4G (4th Generation), 5G (5th Generation), or the like)). The communication unit 101 is used when the functional units included in the ledger server 11 communicate with other devices.

[0065] The ledger processing unit 102 performs processing related to the distributed ledger 111 and transaction data. When the ledger processing unit 102 receives transaction data to be stored in the distributed ledger 111, it verifies the digital signature included in the received transaction data and controls storage of successfully verified transaction data in the distributed ledger 111 held by the storage unit 104. When storing transaction data in the distributed ledger 111, the ledger processing unit 102 generates a block including the transaction data to be stored, and can control storage of the generated block in the distributed ledger 111 when consensus is reached between the ledger processing units 102 of other ledger servers (ledger servers 12 and 13) and the ledger processing unit 202 of the management server 20.

[0066] The transaction data stored in the distributed ledger 111 by the ledger processing unit 102 includes at least transaction data including disclosure permission information (described later).

[0067] The execution unit 103 executes information processing. The execution unit 103 can execute information processing by, for example, executing a smart contract using the distributed ledger 111. Note that when the execution unit 103 does not use a smart contract, it executes information processing according to normal program code.

[0068] As an example of the above information processing, the execution unit 103 may perform a process of determining the consistency between public transaction data stored and made public on the public server 22 and transaction data stored in the distributed ledger 111, and a process of generating information according to the determination result.

[0069] The storage unit 104 is a storage device that stores information. The storage unit 104 stores the distributed ledger 111. The storage unit 104 is realized by a non-volatile storage device (such as an SSD (Solid State Drive) or an HDD (Hard Disk Drive)).

[0070] The distributed ledger 111 stores data having a structure in which blocks, each including one or more pieces of transaction data, are linked in a chain. The one or more pieces of transaction data stored in the distributed ledger 111 include transaction data including the history of NFT generation or trading, contract code of a smart contract, transaction data including instructions for executing a smart contract, or transaction data including other information.

[0071] FIG. 3 shows the structure of transaction data 40, which is an example of transaction data stored in the distributed ledger 111. As shown in FIG. 3, the transaction data 40 has a data section 41 and a flag 42. The data section 41 is a section that contains the data body included in the transaction data 40. The flag 42 is information indicating whether the transaction data 40 will be made public (also referred to as disclosure information). The flag 42 can take on a value of 1 or 0, for example. For example, a value of 1 indicates that the transaction data 40 will be made public, and a value of 0 indicates that the transaction data 40 will not be made public. Note that the meaning indicated by the value of the flag 42 is not limited to the above. Furthermore, instead of the flag 42, information in a general format different from a flag may be used as the disclosure information.

[0072] FIG. 4 is a block diagram showing the functional configuration of the management server 20 in this embodiment.

[0073] The management server 20 is an information processing device that includes, as functional units, a communication unit 201, a ledger processing unit 202, an execution unit 203, and a storage unit 204. At least some of the functional units included in the management server 20 are realized by a processor (e.g., a CPU) included in the management server 20 executing a program using a memory.

[0074] The communication unit 201 is a communication interface that is communicatively connected to the network N. The communication unit 201 is similar to the communication unit 101 provided in the ledger server 11. The communication unit 201 is used when the functional units provided in the management server 20 communicate with other devices.

[0075] The ledger processing unit 202 performs processing related to the distributed ledger 211 and transaction data. The ledger processing unit 202 is similar to the ledger processing unit 102 provided in the ledger server 11.

[0076] The transaction data stored in the distributed ledger 211 by the ledger processing unit 202 includes at least transaction data including disclosure permission information (described later).

[0077] The execution unit 203 executes information processing. The execution unit 203 is similar to the execution unit 103 provided in the ledger server 11. The execution unit 203 can execute information processing by executing a smart contract using, for example, the distributed ledger 211. Note that when the execution unit 203 does not use a smart contract, it executes information processing according to normal program code.

[0078] As an example of the information processing, the execution unit 203 may execute a process of sending a copy of transaction data to the public server 22. Specifically, the execution unit 203 provides to the public server 22 transaction data stored in the distributed ledger 211, the transaction data containing disclosure information indicating that the transaction data will be disclosed to devices external to the ledger system 10. In this way, the execution unit 203 contributes to storing the transaction data in the storage unit 223 that is accessible from devices external to the ledger system 10.

[0079] The memory unit 204 is a storage device that stores information. The memory unit 204 stores a distributed ledger 211. The memory unit 204 is realized by a non-volatile storage device (such as an SSD or HDD). The distributed ledger 211 is similar to the distributed ledger 111. The structure of the transaction data stored in the distributed ledger 211 is as shown in FIG. 3.

[0080] FIG. 5 is a block diagram showing the functional configuration of the public server 22 in this embodiment.

[0081] 5, the public server 22 is an information processing device having, as functional units, a communication unit 221, a processing unit 222, and a storage unit 223. At least some of the functional units of the public server 22 are realized by a processor (e.g., a CPU) of the public server 22 executing a program using a memory.

[0082] The communication unit 221 is a communication interface that is communicatively connected to the network N. The communication unit 221 may be a communication interface based on a communication standard for wired communication (e.g., Ethernet (registered trademark) or the like), or may be a communication interface based on a communication standard for wireless communication (e.g., Wi-Fi or the like, or a mobile communication system). The communication unit 221 is used when the functional units included in the public server 22 communicate with other devices.

[0083] The processing unit 222 executes a process of acquiring and disclosing information (transaction data, approval information, or digital signature) to be disclosed to devices external to the ledger system 10. The processing unit 222 discloses the information to be disclosed to devices external to the ledger system 10 by storing it in the memory unit 223. Specifically, the processing unit 222 acquires, from the management server 20, transaction data stored in the distributed ledger 211, whose disclosure permission information included in the transaction data indicates that the transaction data will be disclosed to devices external to the ledger system 10, and stores the transaction data in the memory unit 223.

[0084] Furthermore, when the processing unit 222 receives access to information stored in the storage unit 223 via the network N, it reads out the information to be accessed and transmits it to the device that is the source of the access. The function of the processing unit 222 to receive access via the network N and to transmit a file in response to the access can be realized by well-known technology using HTTP (Hypertext Transfer Protocol) or the like.

[0085] It also receives denial information about the information stored in the storage unit 223 and performs counting processing etc. (described later).

[0086] The storage unit 223 is a storage device that stores information and is realized by a non-volatile storage device (such as a solid state drive (SSD) or a hard disk drive (HDD)).

[0087] The memory unit 223 stores information provided by the processing unit 222 to be made public to devices external to the ledger system 10 (specifically, public transaction data, approval information, denial information, etc.). When access to the information stored in the memory unit 223 is received via the network N, the processing unit 222 reads the information and transmits it to the device that is the source of the access. The memory unit 223 corresponds to a memory unit that can be accessed from devices external to the ledger system 10.

[0088] 6 is an explanatory diagram showing the data structure of the blockchain 50 in this embodiment. The blockchain 50 is an example of the distributed ledger 111.

[0089] 6, the blockchain 50 includes blocks 51, 52, 53, and 54, which are part of a series of consecutive blocks. Note that there are consecutive blocks before the block 51, and there are consecutive blocks after the block 54.

[0090] Block 51 includes the hash value of the previous block, public transaction data A1, and private transaction data B1 and B2. Public transaction data A1 is transaction data for deploying smart contract L and includes the contract code of smart contract L.

[0091] Block 52 includes the hash value of the previous block 51, public transaction data A2, and private transaction data B3. Public transaction data A2 may be transaction data issued by user 1 that causes smart contract L to execute.

[0092] Block 53 includes the hash value of the previous block 52, public transaction data A3 and A4, and private transaction data B4. Public transaction data A3 is transaction data for deploying smart contract M and includes the contract code of smart contract M. Smart contract M may be a smart contract compliant with the ERC721 standard.

[0093] Block 54 includes the hash value of the previous block 53 and public transaction data A5 and A6. Public transaction data A5 is transaction data issued by user 2 that executes smart contract M and executes the NFT generation process. Public transaction data A6 is transaction data issued by user 2 that executes smart contract M and executes the NFT trading process.

[0094] FIG. 7 is an explanatory diagram showing information stored in the storage unit 223 of the public server 22 in this embodiment.

[0095] As shown in FIG. 7, the storage unit 223 may store transaction data 61, an approver list 62, and denial information 63.

[0096] The transaction data 61 stored in the memory unit 223 includes public transaction data A1, A2, A3, A4, A5, and A6. The public transaction data A1, A2, A3, A4, A5, and A6 are copies of the public transaction data with the same names shown in FIG. 6 and are provided by the management server 20.

[0097] Each of the public transaction data A1, A2, A3, A4, A5, and A6 stored in the memory unit 223 is stored in association with the transaction address of the public transaction data and the date and time when the public transaction data was blocked.

[0098] The transaction data 61 stored in the memory unit 223 may be classified into transaction data that does not use a smart contract, transaction data that uses smart contract L, and transaction data that uses smart contract M, or may be stored without being classified.

[0099] The approver list 62 stored in the storage unit 223 includes approval information 621 , 622 , and 623 generated by those who have approved the public transaction data stored in the storage unit 223 .

[0100] The approval information 621, 622, and 623 may be information indicating that the ledger server 11, etc. has determined that the public transaction data matches the transaction data stored in the distributed ledger 111. It can also be said that the approval information 621, 622, and 623 is information indicating that the ledger server 11, etc. has approved that the public transaction data matches the transaction data stored in the distributed ledger 111.

[0101] The approval information 621, 622, and 623 are stored by linking together the digital certificate of the approver associated with the approval information, the date and time when the approval associated with the approval information was made, and the digital signature of the approver associated with the approval information. The approval information is also referred to as affirmative information.

[0102] Specifically, the approval information 621 is approval information generated by the ledger server 11 (i.e., Company A) in response to the ledger server 11 determining that the public transaction data matches the transaction data stored in the distributed ledger 111 owned by the ledger server 11. Similarly, the approval information 622 is approval information generated by the ledger server 12 (i.e., Company B) in response to the ledger server 12 determining that the public transaction data matches the transaction data stored in the distributed ledger 111 owned by the ledger server 12. The approval information 623 is approval information generated by the ledger server 13 (i.e., Company C) in response to the ledger server 13 determining that the public transaction data matches the transaction data stored in the distributed ledger 111 owned by the ledger server 13.

[0103] The denial information 63 stored in the storage unit 223 includes denial information 631 generated by a party who denied the public transaction data stored in the storage unit 223. The denial information 631 includes the denial information of company D.

[0104] The denial information 63 stored in the storage unit 223 includes denial information 631 .

[0105] The denial information 631 may be information indicating that the ledger server 11 or the like has determined that the public transaction data does not match the transaction data stored in the distributed ledger 111. Note that the denial information 631 can also be information indicating that the ledger server 11 has denied that the public transaction data matches the transaction data stored in the distributed ledger 111 (in other words, that the ledger server 11 has not acknowledged that they match).

[0106] The denial information 631 is stored by linking together the digital certificate of the denial person associated with the denial information, the date and time the denial was made, and the digital signature of the denial person associated with the denial information. Note that denial information is also referred to as negation information.

[0107] The processing of the information processing system 1 configured as above will be described.

[0108] 8 is a sequence diagram showing a first example of the processing of the information processing system 1 according to this embodiment. FIG. 8 shows the processing of the information processing system 1 when transaction data is stored.

[0109] For the sake of convenience of explanation, among the ledger servers 11, etc., only ledger servers 11 and 12 are described, and the ledger server 13 is omitted. The ledger server 13 performs the same processing as the ledger server 12.

[0110] In step S101, the ledger server 11 generates transaction data and transmits the generated transaction data to the ledger server 11 etc. and the management server 20. The transaction data generated by the ledger server 11 has the configuration of transaction data 40 shown in Fig. 3. The data section 41 of the transaction data generated by the ledger server 11 can include various information, and the flag 42 includes disclosure information indicating whether the transaction data will be made public.

[0111] In step S102, the ledger servers 11 etc. and the management server 20 block the transaction data generated in step S101 and store them in the distributed ledger (the distributed ledger 111 and 211, respectively). At this time, the ledger servers 11 etc. and the management server 20 can generate blocks containing the transaction data, reach consensus on the generated blocks using a consensus algorithm, and store them in the distributed ledger.

[0112] In step S103, the management server 20 determines whether the transaction data included in the block stored in the distributed ledger 211 in step S102 is to be made public. Whether the transaction data is to be made public can be determined based on the flag 42 (i.e., disclosure information) included in the transaction data. If it is determined that the transaction data is to be made public (Yes in step S103), the process proceeds to step S104; if not (not shown), the series of processes shown in FIG. 8 ends. Note that the process when it is determined that the transaction data is not to be made public is not shown in the figure.

[0113] Here, a process to be performed when it is determined that the transaction data is to be made public will be described.

[0114] In step S104, the management server 20 generates transaction data that is a copy of the transaction data determined in step S104 to be made public, and transmits the generated transaction data to the public server 22. The public server 22 receives the transmitted transaction data. Note that only a portion of the information contained in the transaction data may be copied to generate transaction data that includes the portion of the information.

[0115] In step S105, the public server 22 stores the transaction data received in step S104 in the storage unit 223. Storing the transaction data in the storage unit 223 corresponds to making the transaction data public. The transaction data made public by the public server 22 is also referred to as public transaction data.

[0116] The transaction data stored in the distributed ledger in step S102 is said to "correspond" to the transaction data published in step S105. The transaction data published in step S105 is also said to "correspond" to the transaction data stored in the distributed ledger in step S102.

[0117] 9 is a flow diagram showing a first example of processing by the ledger server 11, etc., in this embodiment. The processing shown in Fig. 9 includes a process of determining whether the public transaction data is identical to the transaction data stored in the distributed ledger 111 after the public transaction data is made public, and a process of generating information according to the determination result.

[0118] Although the case where the ledger server 11 executes the process shown in FIG. 9 will be described, ledger servers other than the ledger server 11 among the ledger servers 11 and the like also execute the process shown in FIG.

[0119] In step S201, the execution unit 103 of the ledger server 11 acquires public transaction data from the public server 22. The acquired public transaction data may be the public transaction data that the public server 22 made public in step S105.

[0120] In step S202, the execution unit 103 determines whether the public transaction data acquired in step S201 matches the transaction data stored in the distributed ledger 111. If it is determined that the public transaction data matches the transaction data stored in the distributed ledger 111 (Yes in step S202), the process proceeds to step S203; otherwise (No in step S202), the process proceeds to step S211.

[0121] In step S203, the execution unit 103 generates approval information. The approval information may be information indicating that the ledger server 11 has determined that the public transaction data matches the transaction data stored in the distributed ledger 111.

[0122] In step S204, the execution unit 103 generates a digital signature for the approval information generated in step S203. The digital signature can be generated by encrypting a hash value of the approval information with the signature key (in other words, the private key) of the ledger server 11.

[0123] In step S205, the execution unit 103 transmits the approval information generated in step S203 and the digital signature generated in step S204 to the public server 22.

[0124] In step S211, the execution unit 103 generates denial information. The denial information may be information indicating that the ledger server 11 has determined that the public transaction data does not match the transaction data stored in the distributed ledger 111.

[0125] In step S212, the execution unit 103 generates a digital signature for the denial information generated in step S211. The digital signature can be generated by encrypting a hash value of the denial information with the signature key (in other words, the private key) of the ledger server 11.

[0126] In step S213, the execution unit 103 transmits the denial information generated in step S211 and the digital signature generated in step S212 to the public server 22.

[0127] 10 is a flow diagram showing a first example of the process of the public server 22 in this embodiment. The process shown in FIG. 10 includes a process executed when the public server 22 receives approval information from the ledger server 11 or the like.

[0128] While the ledger server 11, etc. is executing the process shown in Fig. 9, the public server 22 is in a state of waiting to receive approval information or denial information for the public transaction data that has been made public, which is sent by the ledger server 11, etc. When the public server 22 receives approval information (see step S205) sent by the ledger server 11, etc., it executes the process shown in Fig. 10.

[0129] In step S301, the processing unit 222 of the public server 22 receives the approval information and the digital signature sent by the ledger server 11 or the like.

[0130] In step S302, the processing unit 222 verifies the digital signature received in step S301.

[0131] In step S303, the processing unit 222 determines whether the verification of the digital signature performed in step S302 was successful. If it is determined that the verification of the digital signature was successful (Yes in step S303), the processing unit 222 proceeds to step S304. If not (No in step S303), the processing unit 222 ends the series of processes shown in FIG. 10.

[0132] In step S304, the processing unit 222 updates the approver list. Specifically, the processing unit 222 updates the approver list by adding the approval information received in step S301 to the approver list.

[0133] In step S305, the processing unit 222 makes public the approver list updated in step S304. The approver list can be made public by storing the approver list in the storage unit 223. Making the approver list public corresponds to making public the approval information included in the approver list.

[0134] 11 is a flow diagram showing a second example of the process of the public server 22 in this embodiment. The process shown in FIG. 11 includes a process executed when the public server 22 receives denial information from the ledger server 11 or the like.

[0135] While the ledger server 11, etc. is executing the process shown in Fig. 9, the public server 22 is in a state of waiting to receive approval information or denial information for the public transaction data that has been made public, which is sent by the ledger server 11, etc. When the public server 22 receives denial information (see step S213) sent by the ledger server 11, etc., it executes the process shown in Fig. 11.

[0136] In step S401, the processing unit 222 of the public server 22 receives the denial information and the digital signature sent by the ledger server 11 or the like.

[0137] In step S402, the processing unit 222 verifies the digital signature received in step S401.

[0138] In step S403, the processing unit 222 determines whether the verification of the digital signature performed in step S402 was successful. If it is determined that the verification of the digital signature was successful (Yes in step S403), the processing unit 222 proceeds to step S404. If it is not successful (No in step S403), the processing unit 222 ends the series of processes shown in FIG. 11.

[0139] If it is determined in step S403 that the verification of the digital signature is successful, the processing unit 222 may store the denial information received in step S401 in the storage unit 223.

[0140] In step S404, the processing unit 222 counts the number of pieces of denial information received in step S401. Specifically, the processing unit 222 counts the number of pieces of denial information that have been received up to the present time for one piece of public transaction data from the ledger server 11, etc.

[0141] In step S405, the processing unit 222 determines whether the number of pieces of denial information counted in step S404 exceeds a threshold value. If it is determined that the number of pieces of denial information exceeds the threshold value (Yes in step S405), the processing proceeds to step S406, but if not (No in step S405), the processing shown in FIG. 11 ends.

[0142] The threshold value may be a predetermined value, for example, a value determined in advance according to the number of ledger servers 11, etc. (more specifically, 50%, 70%, 90%, or the like of the number of ledger servers 11, etc.).

[0143] In step S406, the processing unit 222 executes a process of modifying the public transaction data. For example, the processing unit 222 can modify the public transaction data by acquiring transaction data stored in the management server 20 that corresponds to the public transaction data, and storing the acquired transaction data in the storage unit 223 as new public transaction data instead of the public transaction data stored in the storage unit 223.

[0144] Furthermore, for example, the processing unit 222 may modify the public transaction data by acquiring transaction data stored in one of the distributed ledgers 111 of the ledger server 11, etc., and storing it in the storage unit 223 as new public transaction data instead of the public transaction data stored in the storage unit 223. In this case, when the ledger server 11, etc., generates denial information in advance, the processing unit 222 may generate denial information including the transaction data stored in the distributed ledger 111 and transmit it to the public server 22 (see steps S211 to S213). Upon receiving the transmitted denial information, the processing unit 222 of the public server 22 may modify the public transaction data by acquiring the transaction data included in the received denial information and storing it in the storage unit 223 as new public transaction data instead of the public transaction data stored in the storage unit 223.

[0145] 12 is a flow diagram showing a first example of processing by terminal T1 in this embodiment. The processing shown in Fig. 12 is processing in which a device that has acquired public transaction data from public server 22 determines the authenticity of the acquired public transaction data. Here, the processing in which terminal T1 acquires public transaction data from public server 22 and determines the authenticity of the acquired public transaction data will be described.

[0146] In step S501, terminal T1 acquires public transaction data and an approver list for the public transaction data from public server 22.

[0147] In step S502, terminal T1 verifies the digital signatures included in the approver list acquired in step S501. Terminal T1 verifies all digital signatures included in the approver list acquired in step S501.

[0148] In step S503, terminal T1 determines whether the verification of the digital signatures performed in step S502 was successful. Terminal T1 may determine that the verification of the digital signatures performed in step S502 was successful if the verification of all digital signatures performed in step S502 was successful. Terminal T1 may also determine that the verification of the digital signatures performed in step S502 was successful if the verification of a predetermined number or more of digital signatures performed in step S502 was successful. The predetermined number may be a value determined in advance depending on all digital signatures (more specifically, 50%, 70%, 90%, or the like of the number of all digital signatures). If terminal T1 determines that the verification of the digital signatures performed in step S503 was successful (Yes in step S503), it proceeds to step S504. If not (No in step S503), it proceeds to step S511.

[0149] In step S504, terminal T1 determines that the public transaction data is authentic. For example, terminal T1 may generate information indicating that the public transaction data is authentic and store the generated information in a storage device of terminal T1. Terminal T1 may also display the generated information on a display screen of terminal T1. Terminal T1 may also transmit the generated information to another device via network N, where it may be stored in a storage unit of the other device or displayed on a display screen of the other device.

[0150] In step S511, terminal T1 determines that the public transaction data is not authentic. For example, terminal T1 may generate information indicating that the public transaction data is not authentic and store the generated information in a storage device of terminal T1. Terminal T1 may also display the generated information on a display screen of terminal T1. Terminal T1 may also transmit the generated information to another device via network N, where it may be stored in a storage unit of the other device or displayed on a display screen of the other device.

[0151] Fig. 13 is a sequence diagram showing a second example of processing by the information processing system 1 according to this embodiment. The processing shown in Fig. 13 is performed when it is determined that the public transaction data published in step S105 of Fig. 8 matches the transaction data stored in the distributed ledger 111.

[0152] The ledger server 11 acquires public transaction data published by the public server 22 (step S601, corresponding to step S201) and determines whether the acquired public transaction data matches the transaction data stored in the distributed ledger 111 provided by the ledger server 11 (step S602, corresponding to step S202). If the ledger server 11 determines that the two transaction data match, it generates approval information and a digital signature (also simply referred to as a signature) and sends them to the public server 22 (step S603, corresponding to steps S203 to S205). Upon receiving the approval information and digital signature, the public server 22 updates and publishes the approver list using the received approval information and digital signature (step S604, corresponding to steps S304 to S305).

[0153] Similar to the process performed by the ledger server 11, the ledger server 12 acquires public transaction data published by the public server 22 (step S605, corresponding to step S201) and determines whether the acquired public transaction data matches the transaction data stored in the distributed ledger 111 provided by the ledger server 12 (step S606, corresponding to step S202). If the ledger server 12 determines that the two transaction data match, it generates approval information and a digital signature (also simply referred to as a signature) and sends them to the public server 22 (step S607, corresponding to steps S203 to S205). Upon receiving the approval information and digital signature, the public server 22 updates and publishes the approver list using the received approval information and digital signature (step S608, corresponding to steps S304 to S305).

[0154] Terminal T1 acquires the published public transaction data and the approver list (step S609), and determines the authenticity of the public transaction data using the acquired approver list (step S610).

[0155] Fig. 14 is a sequence diagram showing a third example of processing by the information processing system 1 according to this embodiment. The processing shown in Fig. 14 is performed when, in determining whether the public transaction data published in step S105 of Fig. 8 matches the transaction data stored in the distributed ledger 111, it is determined that the two transaction data do not match. Note that, here, an example will be described in which the threshold for the number of denials is 1.5, which is 50% of the number of ledger servers 11, etc., which is 3.

[0156] The ledger server 11 acquires public transaction data published by the public server 22 (step S701, corresponding to step S201) and determines whether the acquired public transaction data matches the transaction data stored in the distributed ledger 111 provided by the ledger server 11 (step S702, corresponding to step S202). If the ledger server 11 determines that the two transaction data do not match, it generates denial information and a digital signature and sends them to the public server 22 (step S703, corresponding to steps S211 to S213). Upon receiving the denial information and the digital signature, the public server 22 counts the number of denial information received up to this point as 1 (step S704) and determines that the number of denial information received up to this point, 1, does not exceed the threshold value of 1 (step S705, corresponding to step S405).

[0157] Similar to the process performed by the ledger server 11, the ledger server 12 acquires public transaction data published by the public server 22 (step S706, corresponding to step S201) and determines whether the acquired public transaction data matches the transaction data stored in the distributed ledger 111 provided by the ledger server 12 (step S707, corresponding to step S202). If the ledger server 12 determines that the two transaction data do not match, it generates denial information and a digital signature and sends them to the public server 22 (step S708, corresponding to steps S211 to S213). Upon receiving the denial information and digital signature, the public server 22 counts the number of denial information pieces received to date as 2 (step S709) and determines that this number, 2, exceeds the threshold value of 1 (step S710, corresponding to step S405). The public server 22 then executes a process to modify the public transaction data (step S711, corresponding to step S406).

[0158] Modified examples of the approval information will be described below.

[0159] FIG. 15 is an explanatory diagram showing a first modified example of the approval information in this embodiment. The approval information shown in FIG. 15 is a first example of approval information generated by multiple parties. The approval information shown in FIG. 15 differs from the approval information shown in FIG. 7 in that information indicating the participants participating in the information processing system 1 is linked to the approval information. When the affirmative information is generated by multiple parties, it may indicate that multiple servers have determined that the public transaction data matches the transaction data stored in the distributed ledger 111. The fact that the above has been determined by multiple servers may be more reliable and appropriate than if the above has been determined by a single server.

[0160] The approval information shown in Figure 15 may be approval information generated by the ledger server 11 (in other words, Company A) in response to the ledger server 11 determining that the public transaction data matches the transaction data stored in the distributed ledger 111 owned by the ledger server 11.

[0161] Specifically, the approval information shown in Figure 15 is stored in memory unit 223, linked to the digital certificate of the approver related to the approval information, the date and time when approval related to the approval information was made, the digital signature of the approver related to the approval information, and information indicating the participants participating in information processing system 1.

[0162] The information indicating the participants participating in the information processing system 1 may be identification information (e.g., the product number of the device, or the MAC (Medium Access Control) address of the communication interface of the device) that uniquely indicates the ledger server owned by the participant participating in the information processing system 1. Note that the information indicating the participants participating in the information processing system 1 may also be information (e.g., "Company B") that indicates the organization that owns the device participating in the information processing system 1.

[0163] The multiple parties involved in the generation of the approval information shown in FIG. 15 are Company A, which is the approver, and participants (for example, "Company B").

[0164] FIG. 16 is an explanatory diagram showing a second modified example of the approval information in this embodiment. The approval information shown in FIG. 16 is a second example of approval information generated by multiple parties. The approval information shown in FIG. 16 differs from the approval information shown in FIG. 7 in that it includes approval information generated by multiple parties who approved the public transaction data. When the positive information is generated by multiple parties, it may indicate that multiple servers have determined that the public transaction data matches the transaction data stored in the distributed ledger 111. The above determination by multiple servers may be more reliable and appropriate than if the above determination were made by a single server.

[0165] The approval information shown in Figure 16 may be approval information generated by the ledger server 11 (in other words, Company A) and the ledger server 12 (in other words, Company B) in response to (a) the ledger server 11 determining that the public transaction data matches the transaction data stored in the distributed ledger 111 owned by the ledger server 11, and (b) the ledger server 12 determining that the public transaction data matches the transaction data stored in the distributed ledger 111 owned by the ledger server 12.

[0166] The approval information shown in FIG. 16 is stored in the storage unit 223 in association with the information of Company A and Company B, which are approvers related to the approval information.

[0167] The information of Company A, the approver linked to the approval information shown in Figure 16, includes the digital certificate of Company A, which is one of the approvers related to the approval information, the date and time when approval was given by Company A related to the approval information, and a digital signature by Company A, which is one of the approvers related to the approval information.

[0168] In addition, the information about Company B, the approver linked to the approval information shown in Figure 16, includes a digital certificate of Company B, which is one of the approvers related to the approval information, the date and time when approval was given by Company B related to the approval information, and a digital signature by Company B, which is one of the approvers related to the approval information.

[0169] The multiple parties involved in the generation of the approval information shown in FIG. 16 are the approvers, Company A and Company B.

[0170] If the authorization information is generated by multiple parties, the terminal T1 can use the authorization information to calculate the reliability of the public transaction data. The reliability of the public transaction data is an index indicating the degree to which the public transaction data is authentic.

[0171] The process in which terminal T1 calculates the reliability of public transaction data using approval information generated by multiple parties will be described with reference to FIGS. 17 and 18. FIG.

[0172] FIG. 17 is an explanatory diagram showing the approver list stored in the storage unit 223 of the public server 22 in this embodiment.

[0173] The approver list shown in Fig. 17 includes approval information 641, 642, 643, 644, and 645 that was generated with the involvement of multiple parties. Note that the multiple parties involved in generating the approval information may be, for example, the approvers and participants shown in Fig. 15, or the multiple approvers shown in Fig. 16.

[0174] Approval information 641 is approval information generated with the involvement of companies A and C. Approval information 642 is approval information generated with the involvement of companies A and B. Approval information 643 is approval information generated with the involvement of companies D and E. Approval information 644 is approval information generated with the involvement of companies E and F. Approval information 645 is approval information generated with the involvement of companies F and G.

[0175] 18 is a flow diagram showing a second example of the process performed by terminal T1 in this embodiment. In the process shown in FIG. 18, terminal T1 calculates the reliability of public transaction data using approval information generated by multiple parties.

[0176] In step S801, terminal T1 acquires public transaction data and an approver list for the public transaction data from public server 22. The acquired approver list includes multiple pieces of approval information generated by multiple parties, such as approval information 641 to 645 shown in Fig. 17. Each piece of approval information includes a digital signature.

[0177] In addition, if the approval information includes information indicating the participants along with the approver's digital signature (see Figure 15), terminal T1 can calculate the reliability of the public transaction data using Company A's digital signature and the participant's identification information linked to the approval information.

[0178] Furthermore, if the approval information includes the digital signatures of two parties (see Figure 16), terminal T1 can calculate the reliability of the public transaction data using the digital signatures of each of the two parties linked to the approval information.

[0179] In step S802, terminal T1 verifies the digital signatures included in the approver list acquired in step S801. Terminal T1 verifies all digital signatures included in the approver list acquired in step S801.

[0180] Terminal T1 may execute error processing if the verification of the digital signature is not successful.

[0181] As an error handling process, the terminal T1 may transmit control information for invalidating the digital signature that has failed verification to the public server 22. In this way, the terminal T1 contributes to invalidating the digital signature that has failed verification.

[0182] In addition, as an error processing method, terminal T1 may issue a warning to the ledger server that generated the digital signature that failed verification, or may publicly announce that the ledger server that generated the digital signature that failed verification is a server that poses a risk of fraud.

[0183] Furthermore, when the number of pieces of approval information does not meet the reference value, terminal T1 may, as an error process, transmit control information for invalidating public transaction data for which the number of pieces of approval information does not meet the reference value to public server 22. In this way, terminal T1 contributes to invalidating public transaction data for which the number of pieces of approval information does not meet the reference value.

[0184] In addition, if the number of pieces of approval information does not meet the standard value, terminal T1 may, as an error processing step, issue a warning to the ledger server 11, etc. participating in the information processing system 1, or may publish public transaction data in which the number of pieces of approval information does not meet the standard value as public transaction data that poses a risk of fraud.

[0185] In step S803, the terminal T1 calculates the trustworthiness of the public transaction data. The terminal T1 can output the calculated trustworthiness. The trustworthiness can be output, for example, by displaying the trustworthiness as an image on a display screen of the terminal T1, or by transmitting the trustworthiness as information to another device.

[0186] The reliability may be expressed, for example, as the ratio of the person who generated the approval information for the public transaction data to all the people participating in the information processing system 1. For example, in a case where ten companies, including seven companies A to G, participate in the information processing system 1, if terminal T1 acquires the approval information 641 to 645 shown in Fig. 17, the reliability of the public transaction data may be calculated as 7 / 10 (i.e., 0.7).

[0187] Furthermore, when calculating the ratio, terminal T1 may weight the ratio by taking into account the trustworthiness of the participant, where the trustworthiness of the participant is an index indicating the degree to which the public transaction data approved by the participant is authentic.

[0188] For example, terminal T1 may calculate a larger value as the reliability of an approver who has generated approval information from a relatively distant time in the past to the present. Terminal T1 may also calculate a smaller value as the reliability of an approver who has only generated approval information from a relatively recent time in the past to the present. In this case, terminal T1 may reduce or set to 0 the reliability of an approver who has not generated approval information within a recent predetermined period (e.g., one year) even if the approver has generated approval information from a relatively distant time in the past to the present.

[0189] Terminal T1 may also lower the trustworthiness of the approver who generated denial information for the public transaction data.

[0190] In addition, terminal T1 can analyze the relationships between multiple parties involved in the generation of approval information from the approver list, generate a graph representing the connections between the multiple parties, and use the generated graph to calculate the reliability of the public transaction data.

[0191] FIG. 19 is an explanatory diagram showing a graph illustrating a plurality of relationships in this embodiment.

[0192] In the graph shown in Fig. 19, each of the multiple parties involved in the creation of approval information is represented as a node of the graph, and the line segments connecting the multiple parties involved in the creation of each approval information are represented as edges. The two parties represented by the two nodes connected by an edge are multiple parties involved in the creation of one piece of approval information.

[0193] For example, approval information 641 generated by companies A and C is represented in Fig. 19 as an edge 701 connecting the node corresponding to company A with the node corresponding to company C. Other approval information 642, 643, 644, and 645 are similarly represented in Fig. 19 as edges 702, 703, 704, and 705.

[0194] Terminal T1 can also generate a cluster including a set of nodes connected by edges. In the example shown in Fig. 19, two clusters 711 and 712 are generated.

[0195] Using the graph shown in FIG. 19, the terminal T1 can calculate a larger value as the trustworthiness of a person corresponding to a node to which more edges are connected, for example.

[0196] Furthermore, the terminal T1 may analyze, for each cluster, the time when a person corresponding to a node included in the cluster generated approval information in the past, and calculate a larger value as the reliability of all persons included in the cluster, including those who have generated approval information from a relatively distant past time up to the present time.Also, the terminal T1 may calculate a smaller value as the reliability of all persons included in the cluster, including those who have only generated approval information from a relatively recent past time up to the present time.

[0197] In step S804, terminal T1 determines the authenticity of the public transaction data using the reliability of the public transaction data calculated in step S803. For example, if terminal T1 determines that the reliability is equal to or greater than a reference value, it can determine that the public transaction data is authentic, and if it determines that the reliability is less than the reference value, it can determine that the public transaction data is not authentic.

[0198] The processing of the information processing system 1 of this embodiment (in other words, the processing of the information processing system 24) can also be explained as follows.

[0199] FIG. 20 is a flow diagram showing an example of processing by the information processing system 1 in this embodiment.

[0200] In step S801, the management server 20 stores transaction data including disclosure information in the distributed ledger. More specifically, the management server 20 stores transaction data including disclosure information indicating whether the transaction data will be disclosed to devices external to the ledger system 10 in the distributed ledger held by the distributed ledger system consisting of a limited number of servers.

[0201] In step S802, the public server 22 stores the transaction data whose disclosure information indicates that the transaction data will be made public in a storage unit. More specifically, the public server 22 stores the transaction data stored in the distributed ledger in step S801, whose disclosure information indicates that the transaction data will be made public to devices external to the ledger system 10, in a storage unit accessible from devices external to the ledger system 10.

[0202] As a result, the information processing system 1 can make transaction data stored in a distributed ledger (private ledger or consortium ledger) accessible to external devices, i.e., make public, transaction data that includes disclosure information indicating that the transaction data will be disclosed to devices external to the distributed ledger system. The server that owns the distributed ledger can determine whether the disclosed transaction data matches transaction data stored in the distributed ledger, and if they match, the authenticity of the disclosed transaction data can be proven. In this way, the above information processing method contributes to proving the authenticity of part of the information stored in a private ledger or consortium ledger when that part is made public (Effect of Claim 1).

[0203] (Explanation of the Distributed Ledger System) The ledger system 10 (also called the distributed ledger system) described above will be explained in detail below.

[0204] A distributed ledger system is a system that stores and maintains information using P2P (peer-to-peer) network technology connected to multiple nodes. A node is an information processing device that performs predetermined processing by using a processor (e.g., a CPU) to execute a program using memory.

[0205] In a distributed ledger system, multiple nodes autonomously hold copies of information and keep them synchronized. This allows the system to properly store information while substantially preventing tampering, without using a privileged node (e.g., a centralized server or a server in a client-server model).

[0206] Furthermore, a device attempting to access the distributed ledger only needs to access one of the multiple nodes included in the distributed ledger system; in other words, there is no need to access a small number of devices, such as a centralized server. This avoids the concentration of communication or processing load on the centralized server, which can occur in a centralized system. This has the advantage that nodes do not require particularly high specifications for their resources (CPU, memory, etc.), and that communication lines connecting the nodes do not require particularly large communication capacities. This allows the distributed ledger system to be configured using general (or general-purpose) nodes or communication lines, which can contribute to reducing the required computer or communication resources and the costs required for nodes and communication lines.

[0207] Furthermore, a distributed ledger system can store information with high fault tolerance and can also access information with high fault tolerance. Generally, the multiple nodes included in a distributed ledger system are physically or network-distributedly located. If all of the multiple nodes included in a distributed ledger system stop, the distributed ledger system will stop. However, since it is rare for all of the multiple nodes that are physically or network-distributedly located to stop, the distributed ledger system rarely stops. This can be said to be an advantage over a centralized system, where if a centralized server stops, information cannot be stored or accessed.

[0208] With reference to Figures 21 to 25, we will explain the data structure of a distributed ledger, the execution of smart contracts, and the data structure of NFTs.

[0209] FIG. 21 is an explanatory diagram showing the data structure of a blockchain, which is an example of a distributed ledger.

[0210] A blockchain is a chain of blocks, which are units of record. Each block contains multiple transaction data and the hash value of the previous block.

[0211] FIG. 21 shows blocks B1, B2, and B3 included in the blockchain.

[0212] For example, block B2 contains the hash value of the previous block B1, which is calculated by performing a hash algorithm on the contents of block B1.

[0213] Furthermore, block B3 includes, as the hash value of block B2, a hash value calculated from multiple transaction data included in block B2 and the hash value of block B1.

[0214] In this way, a blockchain is structured so that blocks containing the contents of the previous block as a hash value are connected in a chain, which effectively prevents tampering with the recorded transaction data.

[0215] If past transaction data is changed (in other words, tampered with), the hash value of the block containing that transaction data will be different from the value before the change. In that case, to make the block containing the changed transaction data appear correct, all blocks after that block in the distributed ledger stored on multiple servers would have to be recreated, which is extremely difficult in reality. This feature makes it virtually impossible to tamper with transaction data contained in the blockchain.

[0216] When a node stores transaction data in a blockchain, it generates a block containing the transaction data to be stored and attempts to reach consensus on the generated block by executing processing based on a consensus algorithm with other nodes. Then, when consensus is reached, the node controls the storage of the block in the blockchain. This allows multiple nodes operating in an autonomous and decentralized manner to connect legitimate blocks to the blockchain. As a consensus algorithm, PBFT (Practical Byzantine Fault Tolerance), PoW (Proof of Work), PoS (Proof of Stake), or the like may be used. When Hyperledger Fabric is used as an example of a distributed ledger technology, a consensus algorithm does not need to be executed.

[0217] FIG. 22 is an explanatory diagram showing the data structure of transaction data.

[0218] The transaction data shown in Figure 22 includes a transaction body BP1 and a digital signature BP2 (also simply referred to as a signature). The transaction body BP1 is the data body included in the transaction data. The digital signature BP2 is generated by encrypting the hash value of the transaction body BP1 with the signature key (in other words, the private key) of the creator of the transaction data.

[0219] A node that receives transaction data can verify that the transaction body BP1 is legitimate (in other words, that it has not been tampered with) using the digital signature BP2 included in the transaction data. This makes it virtually impossible to tamper with the data included in the transaction body BP1. Furthermore, by storing successfully verified transaction data in the blockchain, the legitimacy of the transaction data stored in the blockchain can be maintained.

[0220] As described above, transaction data included in the blockchain is stored in a chain using the hash values ​​of the transaction data and the hash values ​​of the blocks. This allows the transaction data included in the blockchain to be stored and maintained substantially without being tampered with. This is an advantage over databases or distributed databases that simply store a collection of data.

[0221] Fig. 23 is an explanatory diagram showing transaction data related to the execution of a smart contract. Fig. 24 is a flow diagram showing processing related to the execution of a smart contract.

[0222] A series of processes related to the execution of a smart contract using a distributed ledger will be described with reference to Figures 23 and 24.

[0223] In step SB1, the node stores transaction data B11, including contract code B12 that describes the processing of the smart contract, in the distributed ledger B10. For example, the node acquires transaction data B11 by receiving the transaction data B11 from an information processing device via communication or by the node itself generating the transaction data B11, and stores the acquired transaction data B11 in the distributed ledger B10. Step SB1 is performed before executing the smart contract.

[0224] In step SB2, the node stores transaction data B15, including instructions B16 for executing the smart contract, in the distributed ledger B10. For example, the node receives transaction data B15 from an information processing device via communication and stores the received transaction data B15 in the distributed ledger B10.

[0225] In step SB3, in response to the transaction data B15 including the instruction B16 being stored in the distributed ledger B10 in step SB2, the node reads the contract code B12 from the distributed ledger B10 and executes processing based on the contract code B12. The results of the processing may be included in the transaction data and stored in the distributed ledger B10.

[0226] Through the above series of processes, when the distributed ledger system receives transaction data B15 including instructions B16 for executing a smart contract, it automatically (i.e., without manual intervention) executes the processing in accordance with the instructions B16, enabling highly efficient (i.e., high speed or short processing time). Achieving highly efficient processing has the effect of reducing power consumption. Furthermore, since no manual intervention is required, it is possible to prevent human tampering with information, fraud, or human error. Furthermore, since the results of the processing thus executed are stored in the blockchain, it is virtually impossible to tamper with the results of the processing.

[0227] FIG. 25 is an explanatory diagram showing the structure of an NFT and metadata. An NFT is a token stored in a distributed ledger and is a unique token (in other words, a non-fungible token). NFTs are standardized, for example, as ERC (Ethereum Request for Comments) 721, but are not limited to this. NFTs may conform to a different standard or may be non-standard (for example, proprietary to an organization). While ERC 721 is a standard for unique tokens, the NFTs described herein do not necessarily have to be unique tokens.

[0228] 25 shows transaction data B21 stored in the distributed ledger. The transaction data B21 stores an NFT. The NFT includes a token ID (i.e., identification information that can uniquely identify the NFT) and a metadata uniform resource identifier (URI).

[0229] The NFT has metadata. The metadata may be located in a location accessible via a network (e.g., storage device B22). A metadata URI indicating the location of the metadata may be calculated using the NFT's token ID and a predetermined base URI.

[0230] The information managed as an NFT may be included in the transaction data B21 or in the metadata. Including the information managed as an NFT in the metadata has the advantage of reducing the amount of information included in the transaction data B21 (in other words, the information included in the blockchain). In this case, it can be said that the metadata contains the actual information managed as an NFT. When an image is managed as an NFT, a URL indicating the image data of the image may be managed as an NFT.

[0231] In the above-described embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. Here, the software that realizes the information processing device of the above-described embodiments is the following program.

[0232] In other words, this program causes a computer to execute an information processing method executed by a server of a ledger system equipped with a distributed ledger, the information processing method comprising: receiving from a terminal a request for access to information contained in metadata stored in a storage device, the metadata being metadata of an NFT (Non-Fungible Token) corresponding to an item or service stored in the distributed ledger; determining whether to permit the access request from the terminal in accordance with predetermined access control information indicating whether to permit the request for access to the information for each first category of information type contained in the metadata and for each second category of person requesting access to the information; and controlling the access to be made if it is determined that the access request is permitted.

[0233] Although the information processing method according to one or more aspects has been described based on the embodiments, the present invention is not limited to these embodiments. As long as it does not deviate from the spirit of the present invention, various modifications conceivable by those skilled in the art to the present embodiments, or forms constructed by combining components of different embodiments, may also be included within the scope of one or more aspects.

[0234] The present invention can be used in systems with multiple distributed ledgers.

[0235] 1, 24 Information processing system 10 Ledger system 11, 12, 13 Ledger server 20 Management server 22 Public server 40, 61, B11, B15, B21 Transaction data 41 Data section 42 Flag 50 Blockchain 51, 52, 53, 54, B1, B2, B3 Block 62 Approval list 63, 631 Denial information 101, 201, 221 Communication section 102, 202 Ledger processing section 103, 203 Execution section 104, 204, 223 Memory section 222 Processing section 111, 211, B10 Distributed ledger 621, 622, 623, 641, 642, 643, 644, 645 Approval information 701, 702, 703, 704, 705 Edges 711, 712 Clusters B12 Contract code B16 Instruction B22 Storage device BP1 Transaction body BP2 Digital signature N Network T1 Terminal

Claims

1. An information processing method comprising: storing transaction data in a distributed ledger held by a distributed ledger system consisting of a limited number of servers, the transaction data including disclosure information indicating whether the transaction data will be made public to devices external to the distributed ledger system; and storing the transaction data stored in the distributed ledger, the disclosure information included in the transaction data indicating that the transaction data will be made public to devices external to the distributed ledger system, in a memory unit accessible from the devices external to the distributed ledger system.

2. The information processing method according to claim 1, wherein, when the transaction data is stored in the storage unit, affirmative information indicating that the first transaction data stored in the distributed ledger matches the second transaction data stored in the storage unit is stored in the storage unit in association with the second transaction data.

3. The information processing method according to claim 2, wherein, when the transaction data is stored in the memory unit, a first server among the plurality of servers determines whether the first transaction data read from the distributed ledger matches the second transaction data obtained from the memory unit, generates the affirmative information if it determines that the first transaction data matches the second transaction data, generates a first digital signature by the first server for the affirmative information, and stores the generated affirmative information and the first digital signature in the memory unit.

4. An information processing method as described in claim 3, wherein when generating the positive information, the positive information is further linked to identification information that uniquely indicates a second server among the plurality of servers that is different from the first server.

5. The information processing method according to claim 4, wherein when the second transaction data stored in the memory unit is acquired, the reliability of the second transaction data is calculated using the first digital signature and the identification information of the second server, which are linked to the affirmative information.

6. An information processing method as described in claim 3, wherein, when generating the positive information, a second digital signature is further generated by a second server among the plurality of servers that is different from the first server, and when storing the positive information and the first digital signature in the memory unit, the second digital signature is stored in the memory unit together with the positive information and the first digital signature.

7. The information processing method according to claim 6, wherein, when the second transaction data stored in the memory unit is acquired, the reliability of the second transaction data is calculated using the first digital signature and the second digital signature linked to the affirmative information.

8. The information processing method according to claim 1, wherein, when the transaction data is stored in the memory unit, a first server among the plurality of servers determines whether the first transaction data stored in the distributed ledger matches the second transaction data stored in the memory unit; if it determines that the first transaction data does not match the second transaction data, it generates negation information indicating that the first transaction data does not match the second transaction data; generates a first digital signature by the first server for the negation information; and stores the generated negation information and the first digital signature in the memory unit in association with the second transaction data.

9. An information processing method as described in claim 8, further comprising: determining whether or not the quantity of the negative information stored in the memory unit exceeds a reference value; and, if it is determined that the quantity of the negative information stored in the memory unit exceeds the reference value, acquiring the first transaction data and storing it in the memory unit as new second transaction data in place of the second transaction data stored in the memory unit.

10. An information processing method as described in claim 9, wherein when acquiring the first transaction data, the negative information generated by the first server including the first transaction data is acquired, and the first transaction data included in the acquired negative information is acquired.

11. An information processing system comprising: an administrative server that stores transaction data in a distributed ledger held by a distributed ledger system consisting of a limited number of servers, the transaction data including disclosure information indicating whether the transaction data will be made public to devices external to the distributed ledger system; and a public server that stores the transaction data stored in the distributed ledger, the disclosure information included in the transaction data indicating that the transaction data will be made public to devices external to the distributed ledger system, in a memory unit accessible from the devices external to the distributed ledger system.

12. A program for causing at least one computer to execute the information processing method according to claim 1.

Images