WO2018043599A1 - 情報共有システム - Google Patents

情報共有システム Download PDF

Info

Publication number
WO2018043599A1
WO2018043599A1 PCT/JP2017/031251 JP2017031251W WO2018043599A1 WO 2018043599 A1 WO2018043599 A1 WO 2018043599A1 JP 2017031251 W JP2017031251 W JP 2017031251W WO 2018043599 A1 WO2018043599 A1 WO 2018043599A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
user information
information
data
encrypted data
Prior art date
Application number
PCT/JP2017/031251
Other languages
English (en)
French (fr)
Inventor
誠 武宮
岡田　隆
Original Assignee
ソラミツ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソラミツ株式会社 filed Critical ソラミツ株式会社
Priority to JP2018521136A priority Critical patent/JP6524347B2/ja
Priority to EP17846603.3A priority patent/EP3509006B1/en
Priority to ES17846603T priority patent/ES2906075T3/es
Publication of WO2018043599A1 publication Critical patent/WO2018043599A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it

Definitions

  • the present invention relates to a network system and a program related to information sharing that enables non-public information such as confidential information used in one transaction by an individual or a corporation to be used in other transactions.
  • the present invention relates to a technology that enables non-public information to be transmitted securely while maintaining the technical superiority of the distributed ledger technology.
  • DLT distributed ledger technology
  • Permissionless / Permissioned Permissionless / Permissioned
  • a typical example in which data is disclosed in a public permissionless transaction is a block chain for cryptocurrency (bitcoin) as described in Patent Document 1 above.
  • “Ripple” is intended for Permissioned transactions that limit network participation qualifications (particularly, data approvers), issuers of transactions, and those who read data from APIs to reliable node terminals.
  • "Or” Hyperledger ". For these, see below. https://ripple.com/files/ripple_consensus_whitepaper.pdf and http://www.linuxfoundation.org/news-media/announcements/2017/02/linux-foundation-s-hyperledger-project-announces-30-founding .
  • decentralized ledger technology is that a decentralized peer-to-peer (P2P) network is used without relying on specific server-dependent verification to determine the legitimacy of transactions and actions. It is that it is based.
  • P2P peer-to-peer
  • each terminal manages the same ledger rather than a specific server managing the ledger for transactions, etc. Only in the management configuration, it is recognized as a regular transaction to be added to each ledger. For example, even if a certain terminal is attacked and the distributed ledger held by that terminal is tampered with by an unauthorized person, if it does not match the ledger of another terminal participating in the approver group on the network, It will be rejected. Without agreement from a certain number of terminals participating in the approver group on the network, the integrity of the distributed ledger will be lacking and will not be recorded as legitimate data.
  • security management is distributed and reliability is improved.
  • the distributed ledger technology requires that the data held by each terminal be completely the same throughout the network, while maintaining the local circumstances at each terminal, that is, the existing system configuration, transaction processing procedure, and contents. It also has the flexibility of not requiring any changes. Accordingly, the distributed ledger technology has begun to attract attention as one of the excellent means as a means for distributing security and high reliability while maintaining the independence of each terminal.
  • an object of the present invention is to be able to share non-public information obtained from an individual or an organization through a network in a safe and reliable manner in order to solve the above-described various problems relating to information handling.
  • a program and a method for information sharing provide that at least a part of the user information is shared via a network from a computer having user information to a computer not having the user information.
  • Each of the computers receives the encrypted data and stores it in the respective storage media And a process of storing the same encrypted data among the plurality of computers, and an information sharing request from the second computer that does not hold the user information connected to the network to the plurality of computers.
  • the process of outputting the encrypted data of the information to the network, and the plurality of computers each created using the second public key Storing the encrypted data of the user information or the storage information of the user information, wherein the same encrypted data is stored among the plurality of computers, and the second computer And a process of decrypting the encrypted data of the user information using a secret key.
  • a process for confirming with a provider of the user information whether or not a second computer agrees to hold the user information is made to at least one of the plurality of computers. And executing the control so that the user information is encrypted using the second public key only when the consent is given, and the storage medium of each of the plurality of computers is the encrypted data. And storing the first public key and the second public key together with the consent data.
  • the first computer creates the encrypted data of the user information using the second public key in response to the information sharing request from the second computer
  • the first secret key is used.
  • the raw data of the user information held by the first computer is directly encrypted.
  • a computer when a computer (second computer) outputs a request for user information to a network, another computer (first computer) that has encrypted the user information
  • the user information is encrypted based on a public key that forms a key pair with a private key held or managed by the second computer (second computer), and the encrypted data is output to the network.
  • a certain computer that has requested user information can obtain desired user information by decrypting the encrypted data using its own secret key.
  • the encryption data of the user information output on the network or the storage destination of the encryption data is stored in time series as a completely identical history in each of a plurality of computers connected to the network as an approval group and matched. Is planned.
  • the present invention is a P2P type distributed ledger technology on the premise that all (or more than a predetermined ratio) of computers connected on the network as an approval group have the same history. Because the standard specifications are implemented, a low-cost system can be constructed. As a result, an information sharing system that operates for 24 hours can be realized.
  • the “user information” in the claims is personal information such as an address and a name, and personal information is shared between financial institutions when an individual opens an account with the financial institution. The case is taken as an example.
  • FIG. 1A to 1C show that the configuration of the information sharing system is realized with a plurality of variations.
  • terminals Y (1) to Y (N) of a plurality of financial institutions are connected to a network 10 such as the Internet, and the terminals Y (1) to Y (N) are “ This is a case of constituting "a plurality of computers". Therefore, the P2P type distributed ledger technology is realized between the terminals Y (1) to Y (N).
  • 1 (A) to 1 (C) the terminals surrounded by a dashed line indicate “a plurality of computers” described in the claims.
  • FIG. 1 (B) shows terminals Y (1) to Y (N) of each of a plurality of financial institutions and a third party position that is not included in the financial institutions (for example, financial services for the purpose of preventing the transfer of criminal proceeds).
  • a terminal Z (1) of an organization that supervises an organization or the like, a company that provides a service according to the present invention, etc. constitutes “a plurality of computers” in the claims. Therefore, the P2P type distributed ledger technology is realized between the terminals Y (1) to Y (N) and the terminal Z (1).
  • a feature of the network configuration shown in FIG. 1B is that “a plurality of computers” are configured including at least one terminal Z in addition to the financial institution terminals Y (1) to Y (N).
  • the terminal Z is not necessarily required to be single. Accordingly, there may be a plurality of terminals Z corresponding to two or more third-party organizations, and in the following description, it is described as one terminal Z.
  • FIG. 1C shows a case where “multiple computers” in the scope of the claims are configured by a plurality of the above-described terminals Z without including the terminals Y (1) to Y (N).
  • the financial institution terminals Y (1) to Y (N) are also connected to the network 10.
  • the terminals Z (1) to Z (N) implement the P2P type distributed ledger technology.
  • 1A to 1C are all P2P type networks, and there is no centralized terminal that controls the entire system. It can be said that the system configuration is similar to a mode in which a consortium in which there is no so-called manager is formed regarding activities on the network.
  • a predetermined execution program is installed in the terminals Y (1) to Y (N) and the terminal Z, and each process according to the present invention is executed in each terminal when the execution program is activated.
  • the execution program is such that the terminals Y (1) to Y (N) and the terminal Z can be downloaded from a predetermined site via a network, or installed from a CD or USB memory in which the execution program is stored. To do.
  • the first embodiment relates to an information sharing system 10 having the system configuration shown in FIG.
  • the terminal Y (1) corresponds to the bank A and the terminal Y (2) corresponds to the bank B
  • the user opens an account in the bank A and then tries to open an account in the bank B
  • the user Describes a mechanism by which personal information can be transmitted and shared to Bank B via the network 3 through the processing of the terminal Y (1) of Bank A without directly providing personal information such as address and name to Bank B.
  • the service provider that operates the information sharing system 10 corresponds to the terminal Z.
  • a mobile terminal X (1) such as a smartphone or tablet terminal
  • the information sharing system 10 The connection is assumed to be the portable terminal X (1).
  • a well-known computer terminal connected to the network 3 by wire or wireless may be a user terminal.
  • FIG. 2 is a diagram showing the exchange of information when user X first tries to open a bank A account before user B opens bank B.
  • the terminal Y (1) of the bank A permits the opening and Requesting the provision of personal information (202).
  • personal information is information such as name, address, date of birth, identity verification documents (driver's license, my number card, health and health book, etc.).
  • the terminal Y (1) follows a predetermined procedure (for example, whether the name, address, etc. match the contents described in the identification document) (E.g. requesting a commitment to declare that the address and place of residence are the same or unrelated to transactions with anti-social forces) Open.
  • the terminal Y (1) creates a key pair of the secret key (S 1 ) and the public key (P 1 ) for the opened account, and encrypts the personal information of the user X using the public key (P1).
  • the encrypted data and the public key (P 1 ) are output to the network 3.
  • the terminals Y (2) to Y (N) and the terminal Z other than the terminal Y (1) connected to the network 3 receive the encrypted data and the public key (P 1 ) of the personal information of the user X output on the network 3.
  • outputting data to the network 3 means passing data to the distributed ledger database shown in FIG. 2, that is, enabling each terminal Y and terminal Z to receive data stored in each storage medium. (The same applies to FIG. 4).
  • the terminal Y (1) uses the public key (P 1 ) and private key as one of the plural pairs when the user X opens an account. It may be used as (S 1 ). Note that the key pair for the user X is not necessarily one set, and one user may have a plurality of key pairs.
  • the terminal Z and each of the bank terminal Y (1), terminal Y (2), terminal Y (3) are stored in the terminal Z and each of the bank terminal Y (1), terminal Y (2), terminal Y (3).
  • Each storage is basically all of these terminals, or a predetermined ratio (considering that some terminals cannot execute storage processing due to various circumstances, for example, 90% etc. Ratio) means that the number of terminals is stored.
  • the terminals Y (1) to Y (N) and the terminal Z implement the P2P type distributed ledger technology, so the terminals Y (1) and Y (2) , Terminal Y (3)..., And terminal Z are stored.
  • the information or data stored in each of the terminal Y (1), the terminal Y (2), the terminal Y (3), and the terminal Z needs to be completely the same. .
  • a process of setting a key pair necessary for authenticating the user's mobile terminal X (1) at the terminal Y of each bank will be described.
  • a predetermined application or the like is downloaded to the mobile terminal X (1).
  • the downloaded application or the like is registered in the portable terminal X (1), at least the secret key (S 2 ) used for the user signature by this application or the like and the public key (P 2 ) corresponding to the secret key (S 2 )
  • One key pair (S 2 , P 2 ) is issued.
  • the portable terminal X (1) outputs the public key (P 2 ) to the network 10, the terminal Y (1), the terminal Y (2), the terminal Y (3),.
  • the public key (P 2 ) is received, associated with the encrypted data, and registered in its own recording medium (205).
  • the terminal Z transmits to the portable terminal X (1) a registration completion report indicating that the public key (P 2 ) is handled as information for uniquely identifying the portable terminal X (1), that is, the user X (206). .
  • the first financial institution may perform personal authentication, but the account of the user has already been opened in another financial institution If it is authenticated, any of a plurality of financial institutions that have been personally authenticated may be used.
  • the secret key (S 2 ) is stored in the memory of the portable terminal X (1), but includes storage in an ID card, a SIM card, and the like.
  • FIG. 3 is a flowchart showing the process performed by exchanging information as described above.
  • the mobile terminal X makes an account opening request to the terminal Y (1) of the A bank via the mobile terminal X (1) (step S300)
  • the mobile terminal X The personal information of the user X input from (1) is provided to the terminal Y (1) (step S301).
  • the terminal Y (1) confirms at least one key pair (public key P 1 , private key S 1 ) related to this personal information (that is, user X itself) (step S302), and uses the public key P 1 for personal information.
  • Is encrypted step S303).
  • any encryption algorithm can be used as the encryption algorithm, and is not particularly limited.
  • the terminal Y (1) outputs the encrypted data of personal information and the public key (P 1 ) used for encryption to the network 3 (step S304). Therefore, the personal information of the user X itself (meaning that it is not encrypted) is not leaked on the network 3 and is always converted to “encrypted data”. Processing of each terminal Y (1), terminal Y (2), terminal Y (3)..., And terminal Z is “correct” data worthy of storing encrypted data of personal information on the network 3 Based on the result, when a collective agreement of “correct” data is obtained, it is stored in its own recording medium (step S305). Also, it is desirable to store the encrypted data of the personal information in association with the public key (P 1 ). Details of the collective consensus process for determining whether the data is “correct” data worth being stored will be described later.
  • the encryption data of the personal information is described as being output on the network 3 and stored in the storage medium of each terminal Y and terminal Z.
  • the encryption data itself is not necessarily stored. It doesn't mean you can't be.
  • link destination information for example, URI for accessing the storage area
  • the encryption data is stored and specific address information are encrypted and stored in the storage medium of each terminal. May be. Not storing the encrypted data itself leads to space saving of the storage medium.
  • FIG. 6 shows an example of encrypted data of personal information stored in each storage medium of terminal Y (1), terminal Y (2), terminal Y (3)...
  • risk information, credit information, and encrypted data related to an arbitrary digital asset may be stored together.
  • the storage means such as the terminal Y (1) is stored in an encrypted state, its contents cannot be read.
  • the name of the user X is “53F83EA7”, who is the personal information and what kind of content is the terminal which is “a plurality of computers” except for the terminal Y (1).
  • Even Y (2), terminal Y (3)..., And terminal Z do not know the secret key S 1 and therefore cannot specify it.
  • the personal information of the user X is managed in an encrypted state, but in the first embodiment, the authenticity of the user X's identity is authenticated in order to prevent spoofing.
  • the processing for setting the key for the operation is continued. First, at least one of terminal Y (1), terminal Y (2), terminal Y (3),..., And terminal Z, which are “a plurality of computers” (here, that one computer is terminal Z). .) Displays a site or application for downloading a predetermined application for generating a key necessary for signing the user X from the network 3 on the user's portable terminal X (1) with a predetermined message (for example, , “It is necessary to set a key for electronic signature for personal authentication.
  • the user X registers an application in his / her portable terminal X (1) according to such a message, and issues at least one key pair (public key P 2 , secret key S 2 ) (step S306).
  • the secret key S 2 is stored in the portable terminal X (1), and the public key P 2 is returned to the terminal Z (step S307).
  • Terminal Z is a public key P 2 transmitted, as can be seen to be a public key of the user X, are registered for example in association with the form of a table (step S308). Since the terminal Z shares the public key P 2 of the user X, the terminal Z transmits to the terminal Y (1), terminal Y (2), terminal Y (3). You may make it store in the management aspect suitable for a terminal.
  • the user authentication key pair setting and registration processing relating to steps S306 to S308 does not necessarily have to be performed simultaneously with the opening of the bank A account as in this embodiment.
  • a predetermined application is downloaded at that time, and at least one key pair (public key P 2 , private key S 2 ) is obtained. There is no problem even if the process of issuing is executed.
  • FIG. 4 shows the exchange of information when the user X tries to open an account at Bank B different from Bank A
  • FIG. 5 shows a flowchart.
  • an account has been opened in A bank, and it relates to personal information of user X and related link information according to the data exchange and processing procedure described with reference to FIG. 2 and FIG. It is assumed that the encrypted data is stored in the storage medium of the terminal Y (1), the terminal Y (2), the terminal Y (3).
  • bank B has been provided with personal information from user X in the same manner as bank A.
  • the personal information of the user X necessary for the bank B to open an account is not provided by the user X, but with the cooperation of the bank A that has already provided personal information.
  • the terminal Y (2) of the bank B that has received the account opening request from the user X outputs a request for acquiring the personal information of the user X on the network 3 (402 in FIG. 4, step in FIG. 5). S502).
  • the personal information acquisition request includes the public key (P 3 ) paired with the private key (S 3 ) necessary for the terminal Y (2) to decrypt the encrypted data of the personal information of the user X (FIG. 4). 403).
  • the terminal Y (1), the terminal Y (2), the terminal Y (3) In response to the acquisition request of the personal information of the user X output on the network 3, at least one of the terminal Y (1), the terminal Y (2), the terminal Y (3).
  • the one computer is assumed to be the terminal Z.) tries to obtain an agreement from the user X about whether or not personal information may be provided to the bank B (404 in FIG. 4, step S503 in FIG. 5). Instead of the terminal Z, any one of the terminal Y (1), the terminal Y (2), the terminal Y (3),.
  • call mobile terminal X (1) To contact user X, call mobile terminal X (1) and confirm directly with user X or send a confirmation email to mobile terminal X (1).
  • the confirmation may be made by reading and transmitting the QR code (registered trademark) or the like on the application screen with the application of the portable terminal X (1).
  • the user X When the user X agrees, the user X is notified by electronic authentication using the secret key (S 2 ). Specifically, for example, the terminal Z transmits a random numerical value of an arbitrary length to the mobile terminal X (1) of the user X, and in response to this, the user X uses the random numerical value as a secret key (S 2 ) Create a signature. Since the terminal Z has registered the public key (P 2 ) that forms a key pair with the private key (S 2 ), the electronic signature is decrypted using this public key (P 2 ).
  • the terminal Z confirms whether or not the consent from the user X is obtained (405 in FIG. 4, step S504 in FIG. 5). Actually, for example, it may be determined whether or not “1” as data indicating consent is set in a predetermined parameter or flag value. If consent is not obtained (in the case of the above example, data other than “1” is set), the process of providing personal information to bank B is stopped (No in step S504 in FIG. 5). ). This is to prevent personal information from being passed without the user's permission. On the other hand, when the terminal Z receives the consent of the user X (Yes in step S504 in FIG. 5), the terminal Y (1), the terminal Y (2), the terminal Y (3)...
  • the user X is requested to encrypt the personal information of the user X using the public key (P 3 ) for the bank B (406 in FIG. 4, step S505 in FIG. 5).
  • the terminal Z transmits the received consent data to the terminal Y (1), the terminal Y (2), the terminal Y (3),... (2)
  • the agreement data is shared between the terminal Y (3).
  • Each of terminal Y (1), terminal Y (2), terminal Y (3)..., And terminal Z stores consent data in its own storage medium, and each terminal has the same data regarding consent.
  • the consent data may be stored in a storage medium together with encrypted data obtained by encrypting personal information and related link information. These data may be stored in chronological order from the old consent data, or may be stored in random order without being in chronological order.
  • the terminal Y (2) stores the encrypted data such as “53F83EA7” indicating the user X in its own storage medium, but has the secret key (S 1 ) to be decrypted. Not in. Even if each of the terminal Y (1), the terminal Y (2), the terminal Y (3)..., And the terminal Z tries to decrypt the encrypted data, the encrypted data related to “53F83EA7” can be decrypted. Only terminal Y (1) with S 1 ).
  • the terminal Y (2) that has requested acquisition of the personal information of the user X has a terminal that can decrypt the encrypted data using the secret key (S 1 ) and encrypt the data using the public key (P 3 ).
  • the terminal Y (1) is not identified.
  • the terminal Y (2) makes an acquisition request via the network 3, the terminal Y (2) waits for the encrypted data created by any of the “plural computers” participating in the information sharing system 10 to be output on the network 3. Become.
  • the terminal Y (1) reads out the encrypted data of “53f83ks7” specified in the acquisition request from its own storage medium (407 in FIG. 4, step S506 in FIG. 5). Instead of specifying the identification data “53F83EA7” of the user X regarding which encrypted data is the acquisition request, the terminal Y (1) can be used even when the public key (P 1 ) is specified in the acquisition request. Since the key pair of the public key (P 1 ) and the private key (S 1 ) is set / selected, the private key (S 1 ) that forms the key pair with the public key (P 1 ) Since the user can be identified, the encrypted data of the user X can be read.
  • the terminal Y (1) uses the public key (P 3 ) and again uses the user X's data.
  • Personal information is encrypted to be encrypted data for bank B (step S507 in FIG. 5).
  • terminal Y (1) uses the public key from the unencrypted personal information. (P 3 ) may be used for encryption.
  • the terminal Y (1) does not identify which terminal of the “plural computers” participating in the information sharing system 10 decrypts the encrypted data created using the public key (P 3 ). Not in.
  • the terminal Y (1) encrypts the personal information of the user X for the bank B by using the public key (P 3 ).
  • the public key (P 3 ) For example, when the bank C requests the personal information of the user X, too. This means that the encrypted personal data provided to the bank B is different from the encrypted personal data provided to the bank C. Therefore, encryption for C bank, different public keys (e.g., P 4) so that is used with the public key (P 3).
  • P 4 public keys
  • the terminal Y (1) outputs the encrypted data to the network in a situation in which the encrypted data created using the public key (P 3 ) is not known to which bank.
  • Each of terminal Y (1), terminal Y (2), terminal Y (3)..., And terminal Z is a predetermined that determines whether the data is “correct” data worth storing as encrypted data of personal information. If a collective agreement indicating that the data is “correct” is obtained based on the above calculation process, the data is stored in its own recording medium (step S509 in FIG. 5).
  • the encryption data of the personal information may be stored in association with the public key (P 3 ), or may be stored together with the consent data described above.
  • the encrypted data of the personal information that each of the terminal Y (1), the terminal Y (2), the terminal Y (3),...
  • the terminal Y (2) receives the encrypted personal data (409 in FIG. 4), and acquires the personal information of the user X by decrypting the encrypted personal data using the stored private key (S 3 ) ( Step S510 in FIG.
  • the encrypted data encrypted by the terminal Y (1) using the public key (P 3 ) is first transmitted to the terminal Z, and is directed from the terminal Z to the terminals Y (2), Y (3),. May be transferred.
  • Terminal Y (1) and terminal Y (2) a terminal that can create encrypted data for the bank C.
  • Which terminal is given priority may be set as a rule in advance. For example, both the terminal Y (1) and the terminal Y (2) create encrypted data for the bank C and adopt the one with the earlier timing to output to the network 10, or the randomly selected terminal For example, encryption processing may be executed. If two terminals Y (1) and Y (2) are applicable to the creation of encrypted data for bank C, even if one terminal becomes unavailable or has a poor communication, Since the terminal Y (2) can act on behalf of the terminal, it is possible to quickly respond to the request to the C bank.
  • the encrypted data of the personal information is transmitted from the terminal Y (1) to the terminal Y (2) by the above procedure, and the terminal Y (2) finally acquires the decrypted personal information.
  • consent and encryption data are held as the same history data in all of the “plural computers” participating in the information sharing system.
  • the information transfer side terminal and the transfer side terminal share the encrypted data, and other terminals not requesting the information do not dare to hold the encrypted data.
  • all of the “plural computers” participating in the information sharing system or a number of terminals having a predetermined ratio or more hold a series of data transmission / reception records on the network, and each of the data held by each terminal
  • This is a P2P type distributed recording with complete identity on the network, which requires that the transmission / reception records are always the same. This will be described after describing the second and third embodiments.
  • a terminal that has requested acquisition of personal information acquires encrypted data via the network without knowing which terminal created the encrypted data, and which terminal acquires the encrypted data.
  • the encrypted data is created and output on the network in a situation where the request is not known. That is, since the transmission source and the reception destination of the information to be transmitted are not known to each other, it plays a role as a so-called escrow.
  • escrow In the financial industry in particular, there is a request from the transferor that he / she does not want other banks to know that the user X has an account, and the transferor also knows to whom the information has passed. Since there is a situation unique to a financial institution where it is difficult to pursue responsibility when a problem occurs later, it can be said that the information sharing method of the present invention meets the need for confidentiality.
  • An example of the second embodiment has a configuration shown in FIG.
  • the difference from the first embodiment is that there is no terminal Z.
  • Each bank terminal Y (1), terminal Y (2), terminal Y (3),... Constitutes “a plurality of computers” and performs P2P type distributed recording.
  • any one of the terminal Y (1), the terminal Y (2), the terminal Y (3),... Of each bank plays the role of the terminal Z existing in the first embodiment.
  • Which terminal Y plays the role of the terminal Z may be defined as a rule in the execution program installed in each terminal Y. Others are the same as in the first embodiment.
  • An example of the third embodiment has a configuration shown in FIG.
  • the difference from the first embodiment and the second embodiment is that a plurality of terminals Z (Z (1), Z (2), Z (3),...) Constitute a “plurality of computers”, and P2P type That is, distributed recording is performed.
  • Each bank terminal Y (1), terminal Y (2), terminal Y (3),... Is connected to the network 10 but has only a function as a client.
  • the terminal that stores the public key and the encrypted data is the terminal Z (1), Z (2), Z ( 3).
  • the requesting terminal Y (2) simply receives the encrypted data created on the terminal Z side.
  • the configuration as in the third embodiment is assumed to be used when used as a test system for verifying the executability of the present invention. Moreover, when updating the program installed in the terminal Y (1), terminal Y (2), terminal Y (3), etc. of each bank in the first embodiment and the second embodiment, the updated program It is also effective when a problem is discovered in advance by starting it using the terminals Z (1), Z (2), Z (3),. Furthermore, it can be considered that a plurality of terminals not including bank-side terminals form a consortium that is a KYC center. Therefore, when it is desired to acquire personal information without directly involving each bank, the configuration of the third embodiment in which it is received from the KYC center may be adopted. Others are the same as in the first embodiment.
  • a centralized server controls instances and data on a network.
  • an accounting system of a financial institution centrally manages a book (ledger).
  • a distributed ledger management system is designed so that a plurality of terminals participating in the network have the same book, so that information is always shared.
  • nodes terminals
  • P2P type store data and the like in a distributed manner, but it is considered that the nodes can be classified into several types.
  • an index for classifying whether a node participates in a network, approves data, or the like is examined (Permissionless / Permissioned).
  • Permissionless type includes so-called virtual currency Bitcoin.
  • Bitcoin is publicly accessible and accessible to everyone. An unspecified number of nodes can participate on the network. Bitcoin maintains the robustness of the network by letting an unspecified number of nodes compete for computations under the rule of Proof of Work (POW).
  • POW Proof of Work
  • a narrowly defined block chain is included in the Permissionless type.
  • the definition of blockchain varies depending on the era or the person who uses it.For example, in the era when there was only virtual currency bitcoin, the blockchain refers to the blockchain of bitcoin. It was a thing. Since blockchain implementations other than Bitcoin have emerged as they are now, the definition of blockchains has been expanded and ambiguous depending on the contents of the implementation. Here, it is assumed that a narrowly defined block chain that is synonymous with Bitcoin is included in the Permissionless type.
  • Permissionless type a type in which a large number of unspecified nodes do not have to be trusted (and transactions are made public), such as Permissionless type, is actually a high hurdle. I can say that. Rather, financial institutions want to build a closed blockchain that does not refer to transactions from the outside by forming a network between limited financial institutions that can be trusted. This type of feature is a so-called consortium-type distributed ledger that needs to form a consensus among a limited number of participants.
  • the Permissioned type includes, for example, Hyper Ledger (see http://www.linuxfoundation.org/news-media/announcements/2017/02/linux-foundation-s-hyperledger-project-announces-30-founding). )
  • Ripple is included in the Permissioned type. This type of feature is characterized in that a node is formed by a limited number of reliable nodes, but the distributed ledger itself is public. (See https://ripple.com/files/ripple_consensus_whitepaper.pdf) Ripple is an electronic book that records accounts and balances, and anyone can view this book and see all transactions on the Ripple network. In addition, since there is a collective consensus (agreement) regarding changes in books between trusted permission-type nodes, there is no need for a Proof of Work (POW) calculation competition such as that executed by Bitcoin. In some cases, mutual approval is made between nodes.
  • POW Proof of Work
  • the present invention shows that the present invention can also be applied to a distributed ledger technology such as Ripple that publishes a ledger temporarily by combining the distributed ledger technology and encryption technology.
  • a distributed ledger technology such as Ripple that publishes a ledger temporarily by combining the distributed ledger technology and encryption technology.
  • Ripple that publishes a ledger temporarily by combining the distributed ledger technology and encryption technology.
  • it is a group that is restricted (Permissioned) only to trusted nodes, from the viewpoint of disclosure or nondisclosure of the ledger. Consensus is important.
  • the distributed ledger is a data structure on the assumption that a transaction including encrypted data must follow the previous transaction.
  • the database is updated at the loading timing for reading out data such as logout, etc. Tampering is performed. Even if a part of the data is rewritten conveniently, it will not be reconciled because it is not checked against a series of past transactions. Therefore, if historical data is constructed as a transaction consisting of a series of transactions from the past, data fraud can essentially not occur. Can be determined.
  • the terminals Y (2), Y (3),... Other than the terminal Y (1) are the same in their own storage media. Possesses encrypted data. Therefore, if all the encrypted data in the storage media such as terminal Y (1), terminal Y (2), terminal Y (3),... Will be generated.
  • Each terminal Y (and terminal Z) participating in the network determines the validity of the above-mentioned data, respectively, and finally the conclusion that “correct” is obtained.
  • the distributed ledger which is the storage medium of each terminal.
  • new encrypted data consistent with a transaction including encrypted data stored in the past and history data in which consents are sequentially continued are formed. It is common for encrypted data and consent to be combined into a block as a transaction when a predetermined amount of time or a predetermined quantity is reached (so-called block chain), but it is not necessarily included in the block. It's not something you have to keep together.
  • a method of recording directly in a distributed ledger may be used without grouping into blocks at predetermined intervals.
  • FIG. 7 is a flowchart showing a processing procedure.
  • the contents when each terminal shown in the first embodiment forms an agreement will be described.
  • verification of transaction legitimacy does not depend on a specific terminal, but is performed by each terminal of a decentralized P2P network. From the above, the terminal to be the leader terminal is appropriately selected, and the other terminal follows the conclusion made by the leader terminal.
  • the terminal Z is selected as the leader terminal.
  • Figure treatment 4 406 407 shows, since the terminal Y (1) receives a public key P 3 and encrypted data, the terminal Y (1) the public key P 3 that sent the (i) source (Ii) The public key P 3 of the terminal Y (1) and (iii) the encrypted data are transmitted as transaction data to the reader terminal Z (step S701). In addition, (iv) consent data may be included in the transaction data.
  • the leader terminal Z stores the transaction data from the terminal Y (1) in a predetermined buffer array.
  • the reason why the buffer array is used is that the transaction data is received from each terminal Y other than the terminal Y (1). That is, in FIG. 4, for convenience of explanation, only the terminal Y (1) and the terminal Y (2) are shown as bank terminals, but actually the terminal Y (1) and the terminal Y via the distributed ledger database are shown. (2) Transaction data similar to the exchanges between the other bank terminals Y is also performed. For this reason, the transaction data from the terminal Y other than the terminal Y (1) is transmitted to the leader terminal Z. When the leader terminal Z receives these transaction data, it sequentially stores them in the buffer array (step S702).
  • the leader terminal Z transmits a message instructing each terminal to execute a predetermined calculation regarding each transaction data in the buffer array (buf []).
  • Transaction data relating to the user X 1 is stored into the buffer array buf [1]
  • the transaction data relating to the user X 2 is assumed to be stored in the buffer array buf [2]
  • leader terminal Z is the transaction data relating to the user X 1 terminal Y (1) the execution for the verification, the terminal Y (2), the terminal Y (3), instructs the ..., terminal execution for verification of transaction data relating to the user X 2 Y (1) , Terminal Y (2), terminal Y (3),.
  • each of the terminal Y (1), the terminal Y (2), the terminal Y (3),... Receives the transaction data and temporarily stores it in its own storage medium (the temporary storage is the received transaction This means temporary storage because it may be discarded without storing data.)
  • Hash calculation is performed after confirming whether or not the data can be stored. Specifically, as shown in FIG. 8A, if the storage history immediately before receiving the transaction data buf [1] is state T, the transaction data buf [1] is confirmed without being discarded. As a result, the storage history changes to the state T + 1. Therefore, numerical values representing the state T and the state T + 1 are input to the hash function, and a hash value for the new state T + 1 is calculated.
  • SHA Secure Hash Algorithm
  • the sponge function can use a large sponge (internal state) to eliminate the need for a complicated compression function.
  • the sponge function “absorbs” input data at a certain rate and “cuts out” the hash data at the same rate. Specifically, for example, the internal state is initialized and the input data is divided into r bits that are units of block replacement, and then the exclusive OR (XOR) of the input data and the internal state for each r bits is taken. Perform block replacement with. This is repeated, but a hash value for obtaining the first n bits of the internal state after the last block replacement may be used.
  • SHA-3 Since r is always larger than the hash length (n bits), it is not necessary to perform further block replacement in the process of “cutout”. Further, even if the internal state to be held is slightly increased, it can be said that SHA-3 that uses a high-speed stirring function that basically uses a simple non-linear operation is significant. It is not always necessary to use SHA-3, and a hash function based on another algorithm may be used.
  • the storage history immediately before receiving buf [1] in the storage medium of terminal Y (2) has been altered. Since the state T representing the altered transaction data is not the original state T, the hash value for the new state T ′ calculated using the hash function is also different from the hash value obtained from the state T without alteration. Value.
  • Each of terminal Y (1), terminal Y (2), terminal Y (3),... Transmits the calculated hash value to reader terminal Z (step S704).
  • the hash calculation is also performed for the user X 2 and “APPROVE” and “hash value” are transmitted to the reader terminal Z.
  • “APPROVE” is a message that reports to the reader terminal Z that no trouble has occurred on the terminal side, such as receiving and temporarily storing transaction data.
  • the leader terminal Z checks whether there is a reply from a certain number of terminals or more and the same hash value. .
  • hash values must be the same unless transaction data stored in the storage medium of each terminal Y has been tampered with.
  • the leader terminal Z itself calculates the hash value in the same manner, and confirms whether or not the same hash value is obtained.
  • some random failures such as crash of each terminal Y, failure to receive transaction data from the leader terminal Z, and inability to return the calculation result actually occur.
  • the present invention follows the so-called Byzantine general problem, when the number of terminals of “multiple computers” connected to the network 3 is N, and the number of terminals that may return an unanswered or incorrect value is f. It is confirmed whether the “APPROVE” message is received from the terminal Y of 2f + 1 or more (step S705). If the same hash value is received from the terminal Y of f + 1 or more, the leader terminal Z decides to approve that the transaction data on which the calculation is based is valid (Yes in step S706). Step S708).
  • f is a value that adjusts the accuracy of approval, and the larger f is, the more the value does not agree with the total number of terminals, the more it is not approved.
  • step S705 if only “APPROVE” message less than 2f + 1 is returned to the number N of terminals of “multiple computers”, the leader terminal Z The transaction data is discarded (No in step S705, step S707). Furthermore, even if an “APPROVE” message of 2f + 1 or more is received, if the number that is the same hash value is less than f + 1, the transaction data is discarded (No in step S706, step S707).
  • the leader terminal Z decides to approve or discard the transaction data, it sends a message to each terminal Y (step S709). Receiving this, each terminal Y treats the transaction data, which has been undecided until now, as data to be stored only in the case of the message to be approved (step S710).
  • the leader terminal Z is not always the same terminal. Where it should be determined that the leader terminal is not legitimate transaction data, there is a possibility that a message is sent to each terminal Y if the legitimate transaction data is intentionally legitimate. There may be situations where it is not eligible as a terminal. For example, if a predetermined number of leader change requests are collected from each terminal Y such that it takes too much time to send a message indicating whether the transaction data is legitimate transaction data by the leader terminal, a new leader terminal is selected (step S711). The selection of a new leader terminal may be determined based on various criteria such as, for example, randomly determining the terminal Y, setting the order, or setting the terminal Y to have a short time until the calculation result is transmitted (step S712). . By not fixing the leader, you can deal with the artifacts inherent in the Byzantine Generals problem.
  • FIG. 8B is a diagram showing the concept of transaction data in the form of a block chain.
  • the contents of each block basically also includes the hash of the previous block, and depending on the algorithm, may also include the reader's digital signature (ie, the entire block is hashed and digitally signed). If there is no transaction data in the buffer array, the process returns to step S710 and the same processing is repeated.
  • the information sharing system implemented in a financial institution or the like as shown in the first or second embodiment described above is a P2P network that does not require a central management entity, and distributes data records by a plurality of nodes (terminals). .
  • nodes terminals
  • the entire system has fault tolerance so that a 24-hour operation system without downtime is realized. Since the data structure is extremely difficult to be tampered with by an unauthorized person, a highly secure system can be constructed at a low cost even if data is communicated over a public network.
  • the present invention is not necessarily limited to information sharing between financial institutions.
  • various fields such as medical care, communication, real estate, education, administration, logistics, insurance, voluntary contracts, Internet services, and sharing economy services are also included in the scope of the present invention. Therefore, when information sharing is performed without obtaining consent from the user X according to the field to which the present invention is applied, the information sharing confirmation process (404 and 405 in FIG. 4 and steps S503 and S504 in FIG. 5) is performed. It can be omitted. It may also be appropriate to generate blocks with blockchain-based proof-of-work (POW) calculations such as those done with bitcoin instead of collective consensus.
  • POW proof-of-work
  • the present invention relates to a program installed or loaded on a computer by downloading it through various recording media such as an optical disk such as a CD-ROM, a magnetic disk, or a semiconductor memory, or via a communication network, and the storage thereof.
  • recording media such as an optical disk such as a CD-ROM, a magnetic disk, or a semiconductor memory, or via a communication network, and the storage thereof.
  • the medium is included in the scope of the invention.
  • each terminal participating in the information sharing system via the network 3 is a computer connected to a network such as the Internet or a dedicated line.
  • a network such as the Internet or a dedicated line.
  • a personal computer PC
  • PDA personal digital assistant
  • a tablet a wearable terminal
  • An information sharing system is configured by setting a terminal connected to a network by wire or wirelessly and a mobile terminal so that they can communicate with each other.
  • the information sharing system is a P2P type system, but it is not necessarily a P2P type distributed ledger technology. You may comprise as a system linked with ASP (Application

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

個人又は組織から得られる非公開情報を安全且つ確実にネットワークを通じて共有できることを目的とする。 Ｐ２Ｐ型ネットワークの複数の端末のうちの端末１がユーザ情報の要求をネットワーク上に出力すると、ユーザ情報を暗号化したことのある端末２によって、ユーザ情報が端末１の秘密鍵と鍵ペアをなす公開鍵で暗号化され、端末１は自分が管理する秘密鍵を用いて暗号データを復号すれば所望のユーザ情報を得ることができる。ネットワーク上に出力されるユーザ情報の暗号データは、ネットワーク上に接続する複数の端末各々において完全同一で記憶されるため、仮に複数の端末に含まれる一の端末において、不正目的等でその暗号データが変更されたとしても、複数の端末に含まれる他の端末から得られる値に一致しなければその変更された暗号データは拒絶され得るので、本発明の情報共有は高いセキュリティを保証することができる。

Description

情報共有システム
　本発明は、個人又は法人が一の取引で用いた秘密情報などの非公開情報を、他の取引において活用できるようにする情報共有に関するネットワークシステム及びプログラムに関連し、特に、分散型台帳技術の利用により、分散型台帳技術の技術的優位性を維持しつつ、非公開情報がセキュアに伝達することを可能にする技術に関する。
　従来、個人が銀行又は証券会社等の金融機関に口座を開設する場合や、インターネットを介してネット業者から物品やサービス等を購入する際には、少なくとも氏名、住所、生年月日等を含む個人情報及びその証明書が要求される。この個人情報が悪用された場合、プライバシー侵害につながるのみならず経済的損失の可能性もあるため、秘密情報として扱っている企業も多い。例えば、個人ＸがＡ銀行に口座を開設するためＡ銀行へ身元確認を示す個人情報及び証明書を提供し、その後にＢ銀行にも口座を開設するときは、同じように個人情報及び証明書を提供する必要がある。したがって、個人は各金融機関に対して本人確認手続きをしなければならないという手間が生じていた。
特許第５８５８５０７号公報
　個人としては面倒な本人確認手続きをその都度行うことなく、上記の例であればＡ銀行での本人確認手続きで提供した個人情報等が、Ｂ銀行に対して活用できれば、１回の手続きで済むため効率がよい。しかしながら、昨今のネットワークインフラが拡充され、日常生活においてネットワーク経由で物やサービスを伝搬させることが広範囲にあたりまえに浸透しているにもかかわらず、この本人確認手続きに伴う個人情報等の取扱いはディジタル社会の進展とは無関係のまま変わらずに行われていた。
　その大きな理由は、金融機関は預金や有価証券などの重要な資産を預かるため個人情報に対しては最大の注意をもって取扱わなければならず、口座開設時にあたり個人に多少の不便さが生じるとしても慎重さを期すには必要不可欠なものであると考えているからである。
　また、不正利用を未然に防止する上でも身元確認が厳格になっている。すなわち、金融機関は、実在している個人若しくは会社が口座を開設しようとしているかを確認することによって、犯罪祖域やテロ機関等に関連する正体不明の口座が不正なマネーロンダリングに利用されてしまうことを防止するよう金融庁から通達されている。金融機関が、いわゆるＫＹＣ（Know Your Customer）と称される、新規口座を開く際に必要な書類手続き等を個人に要求しないことによって不正マネーロンダリングによる被害が生じれば、その金融機関は法令違反となって処罰の対象となりかねないからである。ＫＹＣは特に欧米の金融機関では厳格に運用されており、場合によってはサービスが利用できるまでに数週間を要したり、口座開設が拒否されることもある。
　各金融機関が本人確認手続きを要求する他の理由としては、ネットワーク通信の完璧性が保証されていないことも挙げられる。或る金融機関が、ネットワークを介して他の金融機関とデータ通信を自由に行う場合、通信経路途中でデータが盗まれたとしても問題が発生しないという高セキュリティ性が担保されていなければ、ネットワーク上に大切な個人情報を流すことができないのは当然である。一方で、どんなに堅牢なネットワーク構成を構築したと思っても、故意若しくは過失でデータがネットワーク通信上に流出したり、不正目的でデータの改ざんや漏洩があることを長期にわたり１００％防ぐことは誰も保証できない。むしろ、ネットワークを用いた情報の送受信においては、改ざんや漏洩等が不可避であることを想定しておくべきであって、そうなると金融機関等は大事な個人情報をネットワーク通信で流通させることについて非常に慎重にならざるをえなくなる。
　しかも、個人情報がセキュアにネットワーク通信することが実現できたとしても、特定の業界にあっては情報の送信元及び受信先が特定されないようにしたい要求がある。つまり、どこから情報をもらったのか、どこに情報が渡されたかが明らかになると、円滑な取引の遂行に差し障りとなったり、判明された送信元及び受信先が無断で他の目的に利用されたり、様々な責任追及のリスクとなりかねないからである。その一方で、個人情報保護法等の今後の検討事項に挙げられているように、秘匿状態でありながら、監査機関や警察等からの要請があった場合は、送信元及び受信先のつながりを追跡できるようにするというニーズもある。
　さらに挙げれば、各金融機関や各ネット業者が使用するシステムは、個人情報を共有するという前提で構築されてきておらず、データベースにおける個人情報の管理やアクセス方法がそれぞれ異なっている。したがって、各金融機関をネットワークで結合しようとしても、これまで各システムで実行されてきた過去の膨大な取引に不都合を生じさせずに各金融機関同士を連結させることは非常に困難を伴うのが通常である。事実、複数の銀行が経営統合する場合、それぞれの銀行システムの一体化には大変な手間と時間をかけた準備を行っている。
　ところで、最近は、主に金融関係の分野で分散型台帳技術（DLT, Distributed Ledger Technology)が注目をあびてきている。現時点で分散型台帳技術の正確な定義は確定していないが、台帳を承認する者がネットワークに接続する任意のノード端末にするか限定したノード端末にするか（Permissionless/Permissioned）を一つの指標として分類することができる。
　公開型のPermissionlessトランザクションで、特にデータの公開をしている典型例が、上記特許文献１に記載されているような暗号通貨（ビットコイン）のためのブロックチェーンである。これに対し、ネットワークの参加資格（特に、データ承認者）、取引を発行する者、ＡＰＩからデータを読み込む者を信頼性のあるノード端末に限定させたPermissionedトランザクションを対象としているのが、“Ripple”や“Hyperledger”と呼ばれている仕組みである。これらについては、下記を参照されたい。
https://ripple.com/files/ripple_consensus_whitepaper.pdf、及びhttp://www.linuxfoundation.org/news-media/announcements/2016/02/linux-foundation-s-hyperledger-project-announces-30-founding。
　分散型台帳技術の特徴の一つは、トランザクション及びアクションの正当性を決定する際に特定のサーバに依存した検証に依存することなく、非中央集権なピア・ツー・ピア（Ｐ２Ｐ）型ネットワークを基盤にしているという点である。特定のサーバがトランザクション等に関する台帳を統括して管理するのではなく、各端末が同一の台帳を管理することによって、新たなトランザクション等に対してどの台帳においても矛盾が生じないと認められた場合にのみ、各台帳に追加する正規なトランザクション等として認められるという管理構成をとる。例えば、或る端末が攻撃され、その端末が保有する分散型台帳が不正者によって改ざんされたとしても、ネットワーク上の承認者グループに参加する他の端末の台帳と整合しない場合は、改ざんトランザクションは拒絶されてしまう。ネットワーク上の承認者グループに参加する一定数以上の端末からの合意が得られなければ、分散型台帳の完全性の欠如となり、正規のデータとして記録されることはない。各端末のネットワーク接続をＰ２Ｐ型にすることにより、セキュリティ管理の分散化及び信頼性向上を図っているのである。
　このように分散型台帳技術は各端末が保有するデータがネットワーク全体で完全同一であることを求める一方で、各端末それぞれでのローカルな事情、即ち、既存のシステム構成やトランザクション処理手順や内容に対して何ら変更を要求するわけではない柔軟性をあわせ持っている。したがって、各端末の独立性を維持しながらセキュリティ性の分散化・高信頼性を図る一手段として、分散型台帳技術は優れた手段の一つとして注目され始めている。
　そこで、本発明は、情報の取扱いに関する上述した様々な課題を解決するべく、個人又は組織から得られる非公開情報を安全且つ確実にネットワークを通じて共有できることを目的とする。
　前記目的を達成するために本発明に係る情報共有のためのプログラム及び方法は、ユーザ情報を保有するコンピュータから前記ユーザ情報を保有しないコンピュータへ、前記ユーザ情報の少なくとも一部がネットワーク経由で共有されるようにする処理を、前記ネットワーク上に接続する複数のコンピュータに実行させるためのプログラムであって、前記ネットワークに接続するユーザ情報を保有する第一のコンピュータが、前記ユーザ情報に関し第一のコンピュータが保有する第１の秘密鍵に対応する第１の公開鍵を用いて前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化したとき、当該暗号データを前記ネットワークに出力する処理と、前記複数のコンピュータの各々が前記暗号データを受信し、各々の記憶媒体に記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、前記ネットワークに接続する前記ユーザ情報を保有しない第二のコンピュータから、前記複数のコンピュータに向けた情報共有要求であって、第二のコンピュータが保有する前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む前記情報取得要求を、前記ネットワークに出力する処理と、前記情報取得要求に応答し、第一のコンピュータが前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを、前記ネットワークに出力する処理と、前記複数のコンピュータの各々に、前記第２の公開鍵を用いて作成された前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、第二のコンピュータに、前記第２の秘密鍵を用いて前記ユーザ情報の暗号データを復号化させる処理とが実行されることを特徴とする。
　さらに、前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを前記複数のコンピュータ各々の記憶媒体に記憶させる処理を実行する前に、各コンピュータにおいて記憶媒体に既に記憶されているデータと、記憶しようとする新たな暗号データとを用いた所定の演算が実行され、演算値の一致が所定数以上のとき前記暗号データを追加的に記憶するように制御される。
　さらに、前記情報共有要求があったとき、第二のコンピュータが前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する処理を前記複数のコンピュータの少なくとも１つに実行させることを更に含み、前記同意がされたときに限り、前記ユーザ情報は前記第２の公開鍵を用いて暗号されるよう制御すること、前記複数のコンピュータ各々の記憶媒体は、前記暗号データを記憶するとき、前記第１の公開鍵及び第２の公開鍵、並びに前記同意のデータと共に記憶させる処理を更に含むことを特徴とする。
　さらにまた、第二のコンピュータからの情報共有要求に応答して第一のコンピュータが前記第２の公開鍵を用いて前記ユーザ情報の暗号データを作成する場合、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化する代わりに、第一のコンピュータが保有する前記ユーザ情報の生データを直接暗号処理することを特徴とする。
　本発明によれば、或るコンピュータ（第二のコンピュータ）がユーザ情報の要求をネットワーク上に出力すると、前記ユーザ情報を暗号化したことのある別のコンピュータ（第一のコンピュータ）が、当該或るコンピュータ（第二のコンピュータ）が保有又は管理する秘密鍵と鍵ペアをなす公開鍵を基にそのユーザ情報を暗号化してその暗号データをネットワーク上に出力する。このため、ユーザ情報の要求をした或るコンピュータ（第二のコンピュータ）は、自分の秘密鍵を用いて前記暗号データを復号すれば所望のユーザ情報を得ることができる。このとき、ネットワーク上に出力されるユーザ情報の暗号データ或いはその暗号データの保管先等は、承認グループとしてネットワーク上に接続する複数のコンピュータの各々において完全同一の履歴として時系列に保管されて整合が図られている。したがって、仮に複数のコンピュータに含まれる一のコンピュータが、不正目的等により暗号データが改ざんや消去されたとしても、複数のコンピュータに含まれる他のコンピュータ内の履歴と同じでなければ、その改ざんや消去された暗号データが正当なデータとして最終的に認められることはない。不正者が複数のコンピュータのすべてに対して暗号データの変更を一斉に実行することは実際上又は事実上不可能であることから、暗号データの改ざんリスクを無くすことが可能であり、本発明の情報共有は高いセキュリティを保証することができる。
　また、本発明におけるネットワーク上の複数のコンピュータはＰ２Ｐ型で通信を行うことから、一部のコンピュータがダウンしてもシステム全体がダウンすることを回避する耐障害性がある。従来のサーバ/クライアント型システムで耐障害性や冗長構成を保持しようとすればコスト高となり、しかも高度なシステム構築スキルを要求することになる。これに対し、本発明は、承認グループとしてネットワーク上に接続する複数のコンピュータのすべて（又は所定の比率以上の数）のコンピュータが同一の履歴を保有することを前提とするＰ２Ｐ型分散型台帳技術の標準仕様を実装するため、低コストなシステム構築をすることができる。その結果、２４時間稼働の情報共有システムを実現し得る。
本発明の情報共有方法を実際に実現するときの端末間の関係を示した図である。 図１Ａとは異なる端末間の関係により、本発明の情報共有方法を実現する一例を示した図である。 図１Ａ及び図１Ｂとは異なる端末間の関係により、本発明の情報共有方法を実現する一例を示した図である。 端末Ｙ（１）を有するＡ銀行に口座を開設しようとしたときの情報のやり取りを示した図である。 図２の情報のやり取りをフローチャートで示したときの図である。 端末Ｙ（２）を有するＢ銀行に口座を開設しようとしたときの情報のやり取りを示した図である。 端末Ｙ（２）を有するＢ銀行に口座を開設しようとしたときに行われる処理の流れを示すフローチャートである。 個人情報の暗号データを示す一例である。 合意形成の処理手順を示すフローチャートである。 分散型で記憶する取引データの内容及びブロックチェーンにしたデータ構造の一例を示した図である。
　以下に図面を参照しながら、本発明に係る情報共有方法又はそのプログラムに規定する各処理を実行する情報共有システムについて説明する。以下の実施の形態においては、特許請求の範囲の「ユーザ情報」が住所や氏名等の個人情報であり、個人が金融機関に口座を開設する際に個人情報が金融機関の間で共有されるケースを例にしている。
　図１（Ａ）～図１（Ｃ）は、情報共有システムの構成が複数のバリエーションで実現されることを示している。
　図１（Ａ）は、インターネット等のネットワーク１０に複数の金融機関それぞれの端末Ｙ（１）～Ｙ（Ｎ）が接続され、端末Ｙ（１）～Ｙ（Ｎ）が特許請求の範囲の「複数のコンピュータ」を構成する場合である。したがって、端末Ｙ（１）～Ｙ（Ｎ）間でＰ２Ｐ型分散型台帳技術が具現化されることになる。なお、図１（Ａ）～（Ｃ）において一点波線で囲った端末が、特許請求の範囲に記載する「複数のコンピュータ」を指す。
　図１（Ｂ）は、複数の金融機関それぞれの端末Ｙ（１）～Ｙ（Ｎ）と、金融機関に含まれない第三者的な立場（例えば、犯罪収益の移転を防止する目的で金融機関等を監督する組織体、本発明に係るサービスを提供する会社など）の端末Ｚ（１）とが特許請求の範囲の「複数のコンピュータ」を構成する場合である。したがって、端末Ｙ（１）～Ｙ（Ｎ）及び端末Ｚ（１）間で、Ｐ２Ｐ型分散型台帳技術が具現化されることになる。なお、図１（Ｂ）に示すネットワーク構成の特徴は、金融機関端末Ｙ（１）～Ｙ（Ｎ）以外に少なくとも１つの端末Ｚを含んで「複数のコンピュータ」が構成されることであって、端末Ｚが必ず単一であることを要求するものではない。したがって、２以上の第三者的な機関に対応して端末Ｚが複数であってもよく、下記の説明では一つの端末Ｚであるとして説明している。
　図１（Ｃ）は、端末Ｙ（１）～Ｙ（Ｎ）を含まず、もっぱら複数の上述した端末Ｚによって特許請求の範囲の「複数のコンピュータ」を構成する場合である。金融機関端末Ｙ（１）～Ｙ（Ｎ）もネットワーク１０に接続するが、Ｐ２Ｐ型分散型台帳技術を具現化するのは端末Ｚ（１）～Ｚ（Ｎ）の場合である。
　図１（Ａ）～図１（Ｃ）のいずれのシステム構成もＰ２Ｐ型ネットワークであって、いわゆる全体を制御する中央集権的な端末が存在しない。ネットワーク上の活動に関して、いわゆる管理者が不在のコンソーシアムが形成されている態様に近いシステム構成といえる。端末Ｙ（１）～Ｙ（Ｎ）及び端末Ｚには所定の実行プログラムがインストールされ、当該実行プログラムが起動することによって、本発明に係る各処理がそれぞれの端末で実行される。その実行プログラムは、端末Ｙ（１）～Ｙ（Ｎ）及び端末Ｚがネットワーク経由で所定のサイトからダウンロードできるようにしたり、或いは実行プログラムが格納されたＣＤやＵＳＢメモリなどからインストールされるものとする。
＜第１の実施形態＞
　第１の実施形態は、図１（Ｂ）に示すシステム構成の情報共有システム１０に関する。いま、端末Ｙ（１）がＡ銀行、端末Ｙ（２）がＢ銀行に対応しているとし、ユーザがＡ銀行に口座を開設した後、Ｂ銀行にも口座を開設しようとするとき、ユーザはＢ銀行に住所や氏名等の個人情報を直接提供することなく、Ａ銀行の端末Ｙ（１）の処理を通じてネットワーク３経由でＢ銀行へ個人情報が送信され共有できる仕組みを説明する。また、本実施形態では、情報共有システム１０を運営するサービス提供会社が端末Ｚに対応するとする。個人情報のユーザはスマートフォンやタブレット端末等の携帯端末Ｘ（１）を所持していることが一般的であること、また外出していても連絡が取りやすいという理由から、情報共有システム１０への関わりは携帯端末Ｘ（１）とする。なお、携帯端末Ｘ（１）に代わり、有線若しくは無線でネットワーク３に接続する周知のコンピュータ端末がユーザ端末であってもよい。
・Ａ銀行の口座開設
　図２は、ユーザＸがＢ銀行を開設する前に、まずＡ銀行の口座を開設しようとしたときの情報のやり取りを示した図である。図２に示すように、ユーザＸが携帯端末Ｘ（１）を通じてＡ銀行に対して口座開設の要求をしたとき(201)、Ａ銀行の端末Ｙ（１）は開設を許可し、ユーザに対して個人情報の提供を求める(202)。個人情報とは、氏名、住所、生年月日、本人確認書類（運転免許書、マイナンバーカード、健康保健書等）等の情報である。ユーザＸが個人情報を端末Ｙ（１）に送信すると(203)、端末Ｙ（１）は所定の手続きに従って（例えば、氏名や住所等が本人確認書類に記載の内容と合致しているか、記載住所と居住地は一致しているか、反社会的勢力との取引とは無関係であることを宣言することの確約書の要求等）口座開設の要件を満たすと判断できたとき、ユーザ用の口座を開設する。
　また、端末Ｙ（１）は、開設した口座に対して秘密鍵（Ｓ1）と公開鍵（Ｐ1）の鍵ペアを作成し、公開鍵（Ｐ１）を用いてユーザＸの個人情報を暗号化して暗号データを生成すると、ネットワーク３に暗号データ及び公開鍵（Ｐ1）を出力する。ネットワーク３に接続する端末Ｙ（１）以外の端末Ｙ（２）～Ｙ（Ｎ）及び端末Ｚは、ネットワーク３上に出力されたユーザＸの個人情報の暗号データ及び公開鍵（Ｐ1）を受け取り、詳細は後述するが、合意形成プロセスによって集団合意が得られた場合には、自己が管理する記憶媒体にその暗号データを公開鍵（Ｐ１）と対応づけて記憶する(204)。本実施形態においてネットワーク３にデータを出力するとは、図２に示す分散型台帳データベースにデータを渡す、即ち各端末Ｙ及び端末Ｚが各々の記憶媒体に格納するデータを受け取れる状態にすることをあらわしている（図４も同様）。
　なお、端末Ｙ（１）が情報共有システム１０に参加し、ネットワーク上の承認グループ（すなわち、特許請求の範囲の「複数のコンピュータ」）の構成員となるために、あらかじめ承認グループの間で、公開鍵及び秘密鍵の鍵ペアを複数個取り決めている場合は、端末Ｙ（１）はユーザＸの口座開設の際に、複数個の中の一つのペアを公開鍵（Ｐ1）及び秘密鍵（Ｓ1）として使用するようにしてもよい。なお、ユーザＸに対する鍵ペアは１組であるとは限らず、一人のユーザが複数の鍵ペアを有することもある。
　また、端末Ｚが、端末Ｙ（ｉ）（ｉ＝1，2，…）の公開鍵を記憶・管理している場合は、端末Ｙ（１）は端末Ｚから公開鍵（Ｐ1）を受信するようにしてもよい。このとき、端末Ｚは、自己の記憶媒体内に公開鍵を記憶・管理することのみならず、クラウドサービスが利用可能な状況であればデータのクラウド型管理を行うようにしてもよい。
　暗号データ及び公開鍵（Ｐ1）は、端末Ｚ、及び銀行の端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…の各々に記憶されることが重要である。各々に記憶とは、基本的にはこれら全ての端末、若しくは所定の比率（様々な事情により一部の端末が記憶処理を実行できないことを考慮し、ほぼ全てに等しいとみなせる例えば９０％等の比率）以上の数の端末に記憶することを意味する。上述したとおり、第１の実施形態の場合、端末Ｙ（１）～Ｙ（Ｎ）及び端末ＺによってＰ２Ｐ型分散型台帳技術が具現化されるため、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚへの記憶処理を行う。この場合、詳細は後述するが、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの各々で記憶する情報又はデータは、完全同一であることが必要である。
　次に、ユーザの携帯端末Ｘ（１）を認証するのに必要な鍵ペアが各銀行の端末Ｙで設定される処理を説明する。まず、携帯端末Ｘ（１）に所定のアプリケーション等をダウンロードさせる。ダウンロードしたアプリケーション等が携帯端末Ｘ（１）で登録されると、このアプリケーション等によってユーザ署名に用いる秘密鍵（Ｓ2）、及び秘密鍵（Ｓ2）に対応する公開鍵（Ｐ2）の少なくとも１つの鍵ペア（Ｓ2,Ｐ2）が発行される。その後、携帯端末Ｘ（１）が公開鍵（Ｐ2）をネットワーク１０に出力すると、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚは、このユーザ署名用の公開鍵（Ｐ2）を受信して暗号データと対応させ、各自の記録媒体に登録する(205)。端末Ｚは、携帯端末Ｘ（１）を、すなわち当該ユーザＸを一意に識別する情報として公開鍵（Ｐ2）を扱う旨の登録完了報告を、携帯端末Ｘ（１）に送信する(206)。携帯端末Ｘ（１）の認証は、そのユーザがこれまで口座開設したことがなければ初めての金融機関が個人認証すればよいが、すでに他の金融機関にも当該ユーザの口座が開設済みで個人認証しているのであれば、個人認証した複数の金融機関の何れかが行ってもよい。
　なお、秘密鍵（Ｓ2）は、携帯端末Ｘ（１）のメモリに保管されるが、ＩＤカード、ＳＩＭカード等への記憶も含む。
　図３は、上述した情報のやり取りで行われる処理をフローチャートにして示している。図３を参照しながらあらためて処理の流れを確認すると、ユーザＸが携帯端末Ｘ（１）を介してＡ銀行の端末Ｙ（１）向けて口座開設要求を行うと（ステップS300）、携帯端末Ｘ（１）から入力されたユーザＸの個人情報が端末Ｙ（１）に提供される（ステップS301）。端末Ｙ（１）はこの個人情報（即ち、ユーザＸ自身）に関する少なくとも１つの鍵ペア（公開鍵Ｐ1、秘密鍵Ｓ1）を確認し（ステップS302）、公開鍵Ｐ1を用いて個人情報を暗号化する（ステップS303）。なお、暗号アルゴリズムは任意の暗号アルゴリズムが適用し得るものであり、特に限定していない。
　端末Ｙ（１）は、個人情報の暗号データ及び暗号に用いた公開鍵（Ｐ1）をネットワーク３に出力する（ステップS304）。したがって、ネットワーク３上には、ユーザＸの個人情報そのもの（暗号化していないという意味）が流出されることはなく、常に“暗号データ”に変換されている。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれは、ネットワーク３上の個人情報の暗号データが記憶されるに値する“正しい”データであるかの処理結果に基づき、“正しい”データという集団合意が得られた場合は各自の記録媒体に格納する（ステップS305）。また、個人情報の暗号データは、公開鍵（Ｐ1）と対応づけて記憶するのが望ましい。記憶されるに値する“正しい”データであるかの集団合意処理についての詳細は後述する。
　なお、本実施形態においては、個人情報の暗号データがネットワーク３上に出力され、各端末Ｙ及び端末Ｚの記憶媒体に記憶されるとして説明しているが、暗号データ自体を必ずしも記憶しなければならないというものではない。個人情報の暗号データに代わりに、暗号データが保存されているリンク先情報（例えば、記憶領域をアクセスするためのＵＲＩ）や、具体的なアドレス情報を暗号化して各端末の記憶媒体に記憶してもよい。暗号データそのものを記憶しないことは、記憶媒体の省スペース化につながる。
　端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの各記憶媒体に記憶される個人情報の暗号データの一例を図６に示す。これ以外に、リスク情報、信用情報、任意のディジタル資産に関する暗号データをあわせて記憶するようにしてもよい。
　図６から明らかなように、端末Ｙ（１）等の記憶手段では、暗号化された状態で格納されているため、その内容を判読することができない。例えば、ユーザＸの氏名が“53F83EA7”であるので、誰の個人情報であるか、どのような内容の情報であるかは、端末Ｙ（１）を除けば、「複数のコンピュータ」である端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚでさえも、秘密鍵Ｓ1を知らないので特定することができない。
　金融機関はインターネットなどのパブリックネットワーク経由でアクセス可能な状態で個人情報が保管されることに極めて慎重な立場であるため、個人情報を誰もが容易に認識できる態様で保管することに否定的であろう。この点、本実施形態は暗号化データを保管するので、仮に個人情報や関連するリンク情報等に関する暗号データが流出しても、秘密鍵を保有していない限り個人情報が解読されることはなく、安全性が確保されている。
　ステップS305までの処理によって、ユーザＸの個人情報が暗号化された状態で管理されたことになるが、第１の実施形態では、なりすましを防止するため、ユーザＸの本人の正当性を認証するための鍵を設定する処理を引き続き実行する。まず、「複数のコンピュータ」である端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの少なくとも１つ（ここでは、その１つのコンピュータが端末Ｚであるとする。）は、ユーザＸを署名するのに必要な鍵を生成する所定のアプリケーションをネットワーク３上からダウンロードするためのサイトやアプリケーションをユーザの携帯端末Ｘ（１）に所定のメッセージで表示させる（例えば、「個人認証のために電子署名用の鍵を設定する必要があります。下記サイトやアプリケーションに入り、鍵設定アプリケーションをダウンロードして下さい。」等）。ユーザＸは、このようなメッセージに従い自分の携帯端末Ｘ（１）にアプリケーションを登録し、少なくとも１つの鍵ペア（公開鍵Ｐ2、秘密鍵Ｓ2）を発行させる（ステップS306）。そして、秘密鍵Ｓ2は携帯端末Ｘ（１）内で保管し、公開鍵Ｐ2については端末Ｚに返送する（ステップS307）。端末Ｚは、送信された公開鍵Ｐ2を、ユーザＸの公開鍵であることがわかるように、例えばテーブル形式で対応づけて登録しておく（ステップS308）。なお、端末Ｚは、ユーザＸの公開鍵Ｐ2を共有するため、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…に送信し、端末Ｚと同じようなテーブル管理又は各端末に適した管理態様で保管するようにしてもよい。
　なお、ステップS306～S308に関するユーザ認証用鍵ペアの設定及び登録の処理を、本実施の形態のようにＡ銀行の口座開設時のときに同時に必ずしも実行しなければならないというものではない。後述するような他のＢ銀行への口座開設時に、ユーザの同意を求めた際、そのときに所定のアプリケーションをダウンロードして、少なくとも１つの鍵ペア（公開鍵Ｐ2、秘密鍵Ｓ2）を発行させる処理を実行したとしても問題はない。
・Ｂ銀行の口座開設
　次に、ユーザＸがＡ銀行とは異なるＢ銀行にも口座を開設しようとするときの情報のやり取りを図４に、フローチャートを図５に示す。なお、Ｂ銀行に口座開設する時点でＡ銀行には口座が開設されており、図２及び図３を参照しながら説明したデータのやり取り及び処理手順によってユーザＸの個人情報や関連するリンク情報に関する暗号データが端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの記憶媒体に記憶されているとする。
　従来は、ユーザＸがＢ銀行の口座を開設要求しようとすると、Ｂ銀行はＡ銀行と同様にユーザＸから個人情報を提供してもらうのがこれまでやり方であった。これに対し、本発明の場合、Ｂ銀行が口座開設に必要なユーザＸの個人情報は、ユーザＸから提供してもらうのではなく、既に個人情報が提供されているＡ銀行の協力の下、Ｂ銀行へ提供される。具体的には、ユーザＸからの口座開設要求を受けたＢ銀行の端末Ｙ（２）は、ネットワーク３上にユーザＸの個人情報の取得要求を出力する（図４の402、図５のステップS502）。このとき、ユーザＸが誰であるかを特定できる情報は暗号化されており、上述したように例えば、ユーザＸの氏名が“53F83EA7”である。個人情報の取得要求は、端末Ｙ（２）がユーザＸの個人情報の暗号データを解読するに必要な秘密鍵（Ｓ3）とペアをなす公開鍵（Ｐ3）を含んでいる（図４の403）。
　ネットワーク３上に出力されたユーザＸの個人情報の取得要求に応答して、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの少なくとも１つ（ここでは、その１つのコンピュータが端末Ｚであるとする。）は、Ｂ銀行に個人情報を提供してもよいかの同意をユーザＸから得ることを試みる（図４の404，図５のステップS503）。なお、端末Ｚの代りに、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…の何れかであってもよい。
　ユーザＸへの連絡は、携帯端末Ｘ（１）に電話をして直接ユーザＸに確認したり、携帯端末Ｘ（１）に確認メールを送信する。あるいは、ユーザＸが端末Ｙ（２）上で口座開設要求した際、申込み画面のＱＲコード（登録商標）等を携帯端末Ｘ（１）のアプリで読み込み送信させることで確認をとる方法でもよい。
　ユーザＸが同意するときは秘密鍵（Ｓ2）を用いた電子認証によって知らせる。具体的には例えば、端末Ｚは任意の長さのランダム数値をユーザＸの携帯端末Ｘ（１）に送信し、これを受けてユーザＸはランダム数値を秘密鍵（Ｓ2）に用いて電子署名を作成する。端末Ｚは秘密鍵（Ｓ2）と鍵ペアをなす公開鍵（Ｐ2）を登録しているので、この公開鍵（Ｐ2）を使って電子署名を復号する。元のランダム数値に一致すれば、ユーザＸの公開鍵（Ｐ2）で復号できる暗号文（電子署名）を作成できるのは秘密鍵（Ｓ2）をもつユーザＸしかいないことから、ユーザＸ本人の同意であることが証明される。このように、電子署名を利用して不正な者がユーザＸになりすまして同意がなされることを排除する。
　端末Ｚは、ユーザＸからの同意が得られたかを確認する（図４の405，図５のステップS504）。実際には、例えば、所定のパラメータやフラグの値に、同意を示すデータとしての“１”が設定されているか等を判定すればよい。同意が得られなければ（上記例の場合でいえば、”１“以外のデータが設定されている）、Ｂ銀行に個人情報が提供される処理は中止される（図５のステップS504のNo）。ユーザＸの許可なしに個人情報が渡されることを防止するためである。一方、端末ＺがユーザＸの同意を受信した場合（図５のステップS504のYes）、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…（端末Ｚを含む）に向けて、ユーザＸの個人情報をＢ銀行用に公開鍵（Ｐ3）を用いて暗号化することを要求する（図４の406，図５のステップS505）。また、端末Ｚは、受信した同意データを端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…にも送信して、「複数のコンピュータ」である端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚ間でこの同意データが共有されるようにする。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれは同意データを各自の記憶媒体に格納し、各端末が同意に関する同一のデータを保有する。同意データは、個人情報や関連するリンク情報を暗号化した暗号データと一緒にして記憶媒体に格納してもよい。これらデータは古い同意データから順に時系列に記憶されることもあるし、時系列に沿わずにランダムな順で記憶されることもある。
　上述したように、Ａ銀行の口座開設の時、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのすべて若しくは所定の比率以上の数の端末は個人情報等の同一暗号データを共有しているので、端末Ｙ（２）は自分の記憶媒体にユーザＸを示す“53F83EA7”等の暗号データを記憶しているが、復号化する秘密鍵（Ｓ1）をもっていない。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれが暗号データの復号化を実行しようとしても、“53F83EA7”に関する暗号データを復号できるのは秘密鍵（Ｓ1）を有する端末Ｙ（１）のみである。ただし、ユーザＸの個人情報の取得要求をした端末Ｙ（２）は、秘密鍵（Ｓ1）によって暗号データを復号し更に公開鍵（Ｐ3）を使って暗号化する処理を行える端末が、端末Ｙ（１）であることを識別してはいない。端末Ｙ（２）は、ネットワーク３経由で取得要求をすると、情報共有システム１０に参加する「複数のコンピュータ」のいずれかによって作成される暗号データがネットワーク３上に出力されるのを待つことになる。
　端末Ｙ（１）は、自分の記憶媒体内から取得要求において指定されている“53f83ks7”の暗号データを読み出す（図４の407，図５のステップS506）。どの暗号データに関する取得要求かであるかに関してユーザＸの識別データ“53F83EA7”が指定されている代わりに、公開鍵（Ｐ1）が取得要求で指定されているときでも、端末Ｙ（１）は公開鍵（Ｐ1）及び秘密鍵（Ｓ1）の鍵ペアを設定/選択していることから、公開鍵（Ｐ1）と鍵ペアをなす秘密鍵（Ｓ1）を有しているのは自分であることを識別できるため、ユーザＸの暗号データを読み出すことが可能である。
　次に、端末Ｙ（１）は、ユーザＸの暗号データを、秘密鍵（Ｓ1）を用いて平文である個人情報に復号すると、さらに公開鍵（Ｐ3）を使用して再びユーザＸの個人情報を暗号化し、Ｂ銀行向けの暗号データにする（図５のステップS507）。或いは、Ａ銀行内の使用のためにユーザＸの暗号化していない個人情報がＡ銀行の内部ネットワークで保管されている場合には、端末Ｙ（１）はその暗号していない個人情報から公開鍵（Ｐ3）を使って暗号化することもある。
　ただし、端末Ｙ（１）は、公開鍵（Ｐ3）を使って作成する暗号データが、情報共有システム１０に参加する「複数のコンピュータ」のどの端末によって復号されるのかについては識別してはいない。
　ところで、端末Ｙ（１）は、公開鍵（Ｐ3）を使用してユーザＸの個人情報をＢ銀行向けに暗号化するが、これは、例えばＣ銀行もユーザＸの個人情報を要求したとき、Ｂ銀行に提供する暗号個人データと、Ｃ銀行に提供する暗号個人データとは異なるという意味である。したがって、Ｃ銀行向けの暗号は、公開鍵（Ｐ3）とは異なる公開鍵（例えば、Ｐ4）が使用されることになる。同一ユーザの個人情報であるが、データの要求元に応じてそれぞれ異なる暗号個人データを生成し送信するようにしているため、ネットワーク上のセキュリティ性が一層高まる。上述したように、端末Ｙ（１）は、公開鍵（Ｐ3）を用いて作成した暗号データがどの銀行向けの暗号化であることは分からない状況で、その暗号データをネットワーク上に出力する（図４の408、図５のステップS508）。そして、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれは、個人情報の暗号データとして記憶する価値がある“正しい”データであるかを判定する所定の演算処理に基づき、“正しい”データであるという集団合意が得られた場合は各自の記録媒体に格納する（図５のステップS509）。個人情報の暗号データを公開鍵（Ｐ3）と対応づけて記憶させてもよいし、上述した同意データと共に記憶させてもよい。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれが各自の記憶媒体に記憶する個人情報の暗号データは、同一のデータである。
　公開鍵（Ｐ3）とペアをなす秘密鍵（Ｓ3）を有するのは端末Ｙ（２）である。端末Ｙ（２）は、暗号個人データを受信し（図４の409）、保管してある秘密鍵（Ｓ3）を用いて暗号個人データを復号することでユーザＸの個人情報を取得する（図５のステップS510）。なお、端末Ｙ（１）が、公開鍵（Ｐ3）を使って暗号化した暗号データは、まず端末Ｚに送信され、端末Ｚから、端末Ｙ（２）、端末Ｙ（３）…に向けて転送するようにしてもよい。
　その後、ユーザＸが更に銀行Ｃにも口座開設しようとする場合、銀行Ａ及び銀行Ｂに個人情報が提供されていることから、Ｃ銀行向けの暗号データを作成することが可能になる端末は、端末Ｙ（１）及び端末Ｙ（２）である。どちらの端末が優先されるかは、あらかじめルールとして設定しておけばよい。例えば、端末Ｙ（１）及び端末Ｙ（２）のどちらもＣ銀行向けの暗号データを作成し、ネットワーク１０に出力するタイミングが早い方を採用したり、ランダムに選択したいずれか一つの端末に暗号処理を実行させたりする等が考えられる。２つの端末Ｙ（１）及び端末Ｙ（２）がＣ銀行向けの暗号データの作成に適用可能な場合、仮に一方の端末が利用不可能や通信不良であるという状況になったとしても、即座に端末Ｙ（２）が代行できるので、Ｃ銀行への要求に迅速に対応することが可能である。
　上述の手順により、端末Ｙ（１）から端末Ｙ（２）へ個人情報の暗号データが伝達され、最終的に端末Ｙ（２）は復号化した個人情報を取得することになる。このとき、情報共有システムに参加する「複数のコンピュータ」のすべてにおいて、同意や暗号データが同一の履歴データとして保有されるという点は、本発明の特徴の一つである。従来のシステムの場合、情報の譲渡側端末と譲受側端末とが暗号データを共有し、情報を要求していない他の端末が暗号データを敢えて保有することはない。本発明は、情報共有システムに参加する「複数のコンピュータ」のすべて若しくは所定の比率以上の数の端末が、ネットワーク上のデータの送受信記録を一連のものとして保有し、しかも各々で保有するデータの送受信記録が常に同一であることを要求するという、ネットワーク上での完全同一性があるＰ２Ｐ型分散記録である。これについては、第２の実施形態及び第３の実施形態を説明した後で述べる。
　また、本発明の更なる特徴の一つは、個人情報の取得要求をした端末は暗号データを作成したのがどの端末であるのかを知らずにネットワーク経由で暗号データを取得し、どの端末が取得要求をしているのか知らない状況で暗号化データを作成してネットワーク上に出力されるという点である。つまり、伝達される情報の送信元と受信先が互いに知られないので、いわゆるエスクロー(escrow)としての役割を果たしている。特に金融業界においては、ユーザＸの口座があることを他の銀行等に知られたくないという譲渡人側の要求があるとともに、譲受人側としても誰に情報が渡ったかが譲渡人側に知られると後に問題が発生したときに責任追求されて困るという金融機関ならでは事情があるので、本発明のような情報共有方法は秘匿性のニーズに合致しているといえる。
　一方で、法律上の要請から匿名性を認めず、情報漏洩に関連する事件等が発生した場合や金融機関の監査において情報共有の流れを確認する必要がある。本実施形態のように端末Ｚのような第三者的な機関が含まれている場合は、銀行等が拒否したとしても、端末Ｚの記録媒体の履歴をトレースして検証することができる。これは、誰から誰に個人情報が移動しているかが分かるようにするという、将来の個人情報保護法の動向に合致する。
　＜第２の実施形態＞
　第２の実施形態の一例が、図１（Ａ）に示す構成である。第１の実施形態と異なるのは、端末Ｚが存在しないことである。各銀行の端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…によって「複数のコンピュータ」が構成され、Ｐ２Ｐ型分散記録を行う。言い換えると、各銀行の端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…のいずれかが、第１の実施形態に存在する端末Ｚの役割を担っていることになる。どの端末Ｙが端末Ｚの役割をするかについては、各端末Ｙにインストールされる実行プログラムの中においてルールとして定義しておけばよい。その他については、第１の実施形態と同じである。
　＜第３の実施形態＞
　第３の実施形態の一例が、図１（Ｃ）に示す構成である。第１の実施形態及び第２の実施形態と異なるのは、複数の端末Ｚ（Ｚ（１）、Ｚ（２）、Ｚ（３）、…）によって「複数のコンピュータ」が構成され、Ｐ２Ｐ型分散記録を行っていることである。各銀行の端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…もネットワーク１０に接続するが、いわゆるクライントとしての機能しか有していない。例えば、銀行Ｂが個人情報を取得するために端末Ｙ（２）を通じてネットワークに要求を出したとき、公開鍵や暗号データを記憶する端末は、端末Ｚ（１）、Ｚ（２）、Ｚ（３）、…である。端末Ｚ側で作成された暗号データを要求元の端末Ｙ（２）が単に受信するという構成である。
　第３の実施形態のような構成は、本発明の実行性を検証するための試験用システムとして使用するとき等に使用することが想定される。また、第１の実施形態及び第２の実施形態における各銀行の端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…にインストールしたプログラムを更新しようという場合、更新後のプログラムを実際に配布する前に端末Ｚ（１）、Ｚ（２）、Ｚ（３）、…を用いて起動させてみることで、不具合を事前に発見するときにも有効である。さらには、銀行側端末を含まない複数の端末がＫＹＣセンターであるコンソーシアムを形成するとみなすことも可能である。そこで、各銀行を直接的に関与させずに個人情報を取得したい場合は、ＫＹＣセンターから受け取るという第３の実施形態の構成を採用すればよい。その他については、第１の実施形態と同じである。
＜分散型台帳技術（DLT）について＞
　本発明は、分散型台帳技術を用いた情報共有であることが特徴であるため、以降は、分散型台帳技術の概略を説明する。なお、本発明と直接関係のない分散型台帳技術の内容については省略する。
　従来の多くのシステムは、サーバを核とする中央集権型に構成され、ネットワーク上のインスタンスやデータを中央集権サーバがコントロールするような仕組みとなっている。例えば、金融機関の勘定系システムは帳簿（台帳）を集中管理している。一方、ネットワークに参加する複数の端末間で同じ帳簿をそれぞれ持ち合い、常に情報が共有されるようにしようとするのが分散型台帳管理システムである。
　近年、分散型台帳技術をソリューションとして提供する企業が出現している。いずれもＰ２Ｐ型でネットワーク接続するノード（端末）がデータ等を分散して保存するというのが共通する特徴であるが、いくつかのタイプに区分できると考えられている。本明細書では、区分するための一指標として、ノードがネットワークに参加したりデータを承認すること等に関して許可なしか/許可ありか（Permissionless/Permissioned）を検討する。
　Permissionless型に含まれるのが、いわゆる仮想通貨のビットコイン（Bitcoin）である。ビットコインは、トランザクションが公開され、誰もがアクセス可能である。そして、不特定多数のノードがネットワーク上で参加できる。ビットコインは、Proof of Work(POW)というルールの下、不特定多数のノードに計算競争を行わせることでネットワークの堅牢性を維持している。
　また、狭義のブロックチェーンもPermissionless型に含まれる。ブロックチェーンの定義は時代によって或いは使用する人によって様々に異なり、例えば、仮想通貨のビットコインしか存在しなかった時代は、ブロックチェーンはビットコインのブロックチェーンを指しており、ビットコインを言い換えただけのものであった。現在のようにビットコイン以外のブロックチェーン実装が出現してからは、その実装の内容によってブロックチェーンの定義が拡大し、且つ曖昧になっている。ここでは、ビットコインと同義とされる狭義のブロックチェーンは、Permissionless型に含まれるとする。
　金融機関は、Permissionless型のように、不特定多数のノードが信頼できなくてもよい（しかも、トランザクションが公開される）というタイプを基幹系システムで使用することは現実的にはハードルが高いと言えるであろう。むしろ金融機関は、限られた信用できる金融機関同士でネットワークを組み、外部からトランザクションなどが参照されることのない閉じたブロックチェーンを構築することを望むので、Permissioned型を志向すると思われる。このタイプの特徴は、限定された複数の参加者の中でコンセンサスを形成する必要があるいわゆるコンソーシアム型の分散型台帳である。Permissioned型には、例えば、Hyper Ledgerがある（http://www.linuxfoundation.org/news-media/announcements/2016/02/linux-foundation-s-hyperledger-project-announces-30-foundingを参照。）
　また、Permissioned型に含まれるとされるものとして、Rippleがある。このタイプの特徴は、限られた信頼のあるノードによってノードが形成されるのだが、分散台帳自体は公開されることに特徴がある。（https://ripple.com/files/ripple_consensus_whitepaper.pdf参照）
　Rippleは、アカウントと残高を記録する電子帳簿であり、誰でもこの帳簿を閲覧し、Rippleネットワーク上のすべての取引をみることができる。また、信頼があるPermissioned型ノード間で、帳簿の変更に関する集団的コンセンサス（合意）を行うことから、ビットコインで実行されるようなProof of Work(POW)の計算競争は不要であり、合意の際にはノード間の相互合意型で承認を行う。これにより、ビットコインの弱点であるスケーラビリティや消費電力の課題を克服し、ビットコインの場合平均１０分程度要していた決済を数秒で行うことができるとされている。高速で安全な分散型の取引決済を可能にしているのである。
　上述した本発明の実施形態が分散型台帳技術のどのタイプに適するかを検討してみると、金融機関に口座を開設するという態様では、少なくともノードの信用が保証されていることが必要になる。したがって、基本的には、Permissioned型が該当することになろう。
　なお、分散型台帳の仕組みにPermissionedではあるが台帳自体を公開してしまうことは、金融機関同士で使用するのは一見すると不適となる。しかしながら、本発明は、第１～第３の実施形態で示したとおり、「複数のコンピュータ」の間で送受信されるデータは個人情報という可読可能な生データではなく、暗号処理が施された暗号データである。したがって、台帳自体を公開しても、事実上個人情報そのものが理解される態様で一般に公開されたことにならない。本発明は、分散型台帳技術と暗号技術を組み合わせることによって、Rippleのような仮に台帳を公開するタイプの分散型台帳技術にも適用し得ることを示している。上述した第１～３の実施形態のような金融機関同士で個人情報を共有するという場合は、台帳の公開又は非公開性という観点よりも、信用できるノードにのみ限定（Permissioned）することによる集団的コンセンサス（合意）が重要となる。
　そこで、次に、ネットワークに接続する「複数のコンピュータ」間で行われる集団的コンセンサス（合意）について説明する。集団的コンセンサス（合意）は、いわゆる、よく知られたビザンチン将軍問題（Byzantine Generals Problem）に基づいている。これは、相互に通信しあう何らかの主体（将軍）グループにおいて、通信および個々の主体が故障または故意によって偽の情報を伝達する可能性がある場合に、“グループ全体として”正しい合意を形成できるかを問う問題ある。詳細は省略するが、重要なことは、グループ内の各主体はひとつの結論に合意しなければならないということで、或る端末の結論と、別の端末の結論が異なる合意を排除する。全員が同じ結論（本発明の場合、暗号データやユーザの同意を正しいものとして認めるか否か）を決めなければならない。
　また、分散型台帳は、暗号データ等を含むトランザクションが前回のトランザクションに続く構成になっていなければならないことを前提としたデータ構成である。悪意を有する者が或る銀行の端末Ｙ（１）内のデータに不正を企てる場合、ログアウト等のデータを読み込むローディングタイミングでデータベースの更新がされることを狙い、不正データの複製や記憶データの改ざんを実行したりする。仮に、一部分のデータを都合よく書き換えたとしても、過去の一連のトランザクションに照合しないことになるので辻褄があわなくなる。したがって、トランザクションが過去からの一連のトランザクションからなるものとして履歴データが構築されていれば、本質的にデータ不正は発生し得ないという理由から、辻褄のあわない箇所の有無によってデータの正当性を決定することができる。
　さらに、仮に、端末Ｙ（１）内のデータベース全体が不正者によって書き換えられたとしても、端末Ｙ（１）以外の端末Ｙ（２）、端末Ｙ（３）、…は各自の記憶媒体に同一の暗号データ等を保有している。したがって、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…という各記憶媒体内の暗号データ等をすべて同じように都合よく書き換えないと、辻褄のあわない箇所が発見されたという報告が発生することになる。
　ネットワークに参加する各端末Ｙ(及び端末Ｚ)、すなわち、特許請求の範囲の「複数のコンピュータ」は、上述したデータの正当性をそれぞれに決定し、最終的に“正しい”という結論が得られたときのみ、新規の同意又は暗号データ等を、各端末の記憶媒体である分散台帳に追加する。これにより、過去に記憶された暗号データ等を含むトランザクションと整合する新たな暗号データや同意が順次連続する履歴データが形成することになる。なお、暗号データ及び同意は、所定の時間分或いは所定の数量に達したときにトランザクションとしてブロックにまとめてから他のブロックに連結させることが一般的ではあるが（いわゆるブロックチェーン）、必ずしもブロックにまとめておかなければならないというものではない。所定の間隔でブロックにまとめることなく、分散型台帳に直接記録する方式であってもよい。
　次に、合意形成処理の具体的な内容の一例を示す。図７は、処理手順を示したフローチャートである。第１の実施形態に示す各端末が合意形成するときの内容を説明することとする。
　分散型台帳技術を利用する本発明は、取引の正当性の検証は特定の端末に依存することなく、非中央集権なＰ２Ｐ型ネットワークの各端末が関与して行うものであるが、端末の中からリーダー端末となるものが適宜選定され、そのリーダー端末が下す結論を他の端末が従うものである。ここでは、リーダー端末として端末Ｚが選定されているとする。
　図４の処理406、407が示すように、端末Ｙ（１）は公開鍵Ｐ3及び暗号データを受信するので、端末Ｙ（１）は、(i)送信元が送ってきた公開鍵Ｐ3、(ii)端末Ｙ（１）の公開鍵Ｐ3、(iii)暗号データを、取引データとしてリーダー端末Ｚに送信する（ステップS701）。その他、(iv)同意データが取引データに含まれていれもよい。
　リーダー端末Ｚは、端末Ｙ（１）からの取引データを所定のバッファ配列に格納する。ここで、バッファ配列としているのは、取引データは端末Ｙ（１）以外の他の各端末Ｙからも受信するからである。すなわち、図４では、説明の便宜上、銀行端末として端末Ｙ（１）及び端末Ｙ（２）のみを記載しているが、実際には分散型台帳データベースを介した端末Ｙ（１）及び端末Ｙ（２）間のやりとりと同様の取引データが、他の銀行端末Ｙ間でも行われている。このため、リーダー端末Ｚには、端末Ｙ（１）以外の端末Ｙからの取引データが送信されている。リーダー端末Ｚは、これらの取引データを受信すると順次バッファ配列に格納する（ステップS702）。
　次に、ステップS703で、リーダー端末Ｚは、バッファ配列（buf[]）内の各取引データに関し、所定の演算の実行を各端末に命令するメッセージを送信する。ユーザＸ1に関する取引データがバッファ配列buf[1]に格納され、ユーザＸ2に関する取引データがバッファ配列buf[2]に格納されているとすると、リーダー端末Ｚは、ユーザＸ1に関する取引データの検証のための演算実行を端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…に指示するとともに、ユーザＸ2に関する取引データの検証のための演算実行を端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…に指示する。
　指示を受けて、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…のそれぞれは、取引データを受信し各自の記憶媒体に仮記憶（仮記憶というのは、受信した取引データを記憶することなく最終的には破棄することがあるため、一時的な記憶という意味である。）できるか確認した上で、ハッシュ計算をする。具体的には、図８（Ａ）に示したように、buf[1]という取引データを受信する直前の記憶履歴を状態Tとすると、buf[1]という取引データが破棄することなく確定データとして記憶しようとすれば記憶履歴は状態T+1に変わることになる。そこで、状態T及び状態T+1をあらわす数値をハッシュ関数に入力して、新たな状態T+1に対するハッシュ値を計算する。
　本実施形態においては、既に知られたスポンジ関数を採用するＳＨＡ(Secure Hash Algorithm)-３を用いる。スポンジ関数は大きなスポンジ（内部状態）を用いて複雑な圧縮関数を不要にできるものであり、入力データを一定の割合でスポンジに「吸収」し、ハッシュ出力では同じ比率で「切り出し」ていく。具体的には例えば、内部状態を初期化し、入力データをブロック置換の単位であるｒビットに分割してから、ｒビットごとの入力データと内部状態の排他的得論理和（XOR）をとることでブロック置換を行う。これを繰り返していくが、最終ブロック置換後の内部状態の先頭のｎビットを求めるハッシュ値とすればよい。ｒは、ハッシュ長(nビット)より常に大きいので、「切り出し」の過程で更なるブロック置換をする必要がない。また、保持すべき内部状態が若干大きくなったとしても、基本的に単純な非線形演算を使用する高速な攪拌関数を使用するＳＨＡ－３の意義は大きいものといえる。
　なお、必ずしもＳＨＡ－３を使用しなくてはならないというものではなく、他のアルゴリズムに基づくハッシュ関数を使用してもよい。
　今、例えば端末Ｙ（２）の記憶媒体においてbuf[1]を受信する直前の記憶履歴が改ざんされていたとする。この改ざんされた取引データをあらわす状態Tは、本来の状態Tではないため、ハッシュ関数を用いて計算した新たな状態T’に対するハッシュ値も、改ざんのない状態Tから得られるハッシュ値とは異なる値である。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）、…のそれぞれは、計算したハッシュ値をリーダー端末Ｚに送信する（ステップS704）。同様に、ユーザＸ2に関してもハッシュ演算を実行して、「APPROVE」及び「ハッシュ値」をリーダー端末Ｚに送信する。ここで、「APPROVE」とは、取引データを受信して仮記憶できている等の端末側にトラブルが発生していないをリーダー端末Ｚに報告するメッセージである。
　リーダー端末Ｚは、所定数以上の端末Ｙから「APPROVE」メッセージ及び演算結果である「ハッシュ値」を受信すると、一定以上の端末数から返信があり且つ同じハッシュ値であるかを調べることを行う。
　明らかなように、各端末Ｙの記憶媒体に格納されている取引データが改ざんされていなければ、原理的にはハッシュ値が同じにならなくてはならない。リーダー端末Ｚ自身も同じようにハッシュ値を計算し、同一のハッシュ値になっているかを確認する。一方で、各端末Ｙがクラッシュ、リーダー端末Ｚから取引データの受信失敗、計算結果の返信不能など何らかの不作為障害が実際には発生する。さらに、リーダー端末Ｚから受信する取引データを不正に処理したり、応答する作為障害を端末Ｙが行う可能性も零ではない。そこで、本発明は、いわゆるビザンチン将軍問題にならい、ネットワーク３に接続する「複数のコンピュータ」の端末数がＮ、未応答若しくは間違った値を返信する可能性のある端末数がｆとするとき、2ｆ+1以上の端末Ｙから「APPROVE」メッセージを受信しているかを確認する（ステップS705）。そして、同じハッシュ値をｆ+1以上の端末Ｙから受信していれば、リーダー端末Ｚはその演算の基になっている取引データが正当であると承認することに決める（ステップS706のYes,ステップS708）。ｆは承認精度を調整する値となり、ｆを大きくするほど、全体の端末数に対する値の一致が高くなければ承認されなくなる。
　一方、グループ全体の一定割合に基づかない承認となることを防ぐため、「複数のコンピュータ」の端末数Ｎに対し、2ｆ+1に満たない「APPROVE」メッセージしか返信されなければ、リーダー端末Ｚはその取引データを破棄する（ステップS705のNo,ステップS707）。更に、2ｆ+1以上の「APPROVE」メッセージを受信したとしても、同じハッシュ値である数がｆ+1に満たなければ、その取引データを破棄する（ステップS706のNo,ステップS707）。
　リーダー端末Ｚは、取引データを承認するか或いは破棄するかを決定すると、各端末Ｙに対してメッセージ送信する（ステップS709）。これを受けて、各端末Ｙは、それまで記憶すべきか未確定にしていたその取引データを、承認するメッセージの場合にのみ記憶するデータであるという扱いにする（ステップS710）。
　また、本発明において、リーダー端末Ｚは常時同じ端末であるとは限らない。リーダー端末が本来は正当な取引データでないと決定すべきところ、意図的に正当な取引データであると各端末Ｙにメッセージを出してしまう恐れもあるし、そのような意図的操作はないがリーダー端末として適格ではないという状況もあり得る。例えば、リーダー端末による正当な取引データであるかのメッセージ送信に時間がかかり過ぎるといった各端末Ｙからリーダー交代のリクエストが所定数集まれば、新たなリーダー端末の選択を行う（ステップS711）。新たなリーダー端末の選択は、例えばランダムに端末Ｙを決定したり、順番制にしたり、演算結果を送信するまでの時間が短い端末Ｙにするなど、様々な基準で決めてよい（ステップS712）。リーダーを固定にしないようにすることで、ビザンチン将軍問題（Byzantine Generals Problem）に内在する、作為障害に対処することができる。
　そして、上記処理をバッファ配列にある取引データについて繰り返し行い、所定時間が経過した時点で（ステップS713）、承認された複数の取引データを一括してブロック化し、これまでのブロックにつなげる（ステップS714）。このようにして生成される一連のデータが、いわゆるブロックチェーンと称されているものである。図８（Ｂ）は、ブロックチェーン化した取引データの概念を示した図である。各ブロックの中身は基本的に前のブロックのハッシュも含み、さらにアルゴリズムによってはリーダーの電子署名も含み得る（つまり、ブロック全体をハッシュして、電子署名する）。バッファ配列にある取引データがなければ、ステップS710に戻り、同様の処理を繰り返す。
　以上説明してきた集団的コンセンサス（合意）のプロセスは、ビットコインに較べ短時間である。ビットコインの場合、ブロック内のハッシュ関数に関連する特定の値を変化させながら正しいブロックとして認められるブロックのみを、全探索・総当たりの演算処理によって発見する手法のため、ブロックチェーンに新たなブロックを追加するかを決定するのに平均１０分程要してしまう。一方、集団的コンセンサス（合意）のプロセスには数学的な計算が必要ないことから、現時点でおよそ５～１０秒ごとに行われると言われている。したがって、ネットワーク上に送出される暗号データ等を銀行等の各端末の台帳へ高速に追加できる。
　さらに、分散型台帳に記録される一連のデータ又はトランザクションは、過去の履歴記録が個人情報の伝達事実を示すための証拠となるので、後から記録の改ざんを行なったかのトレースが容易である。このため、分散型台帳管理プラットフォームR3Cordaと同等の機能として、第１の実施形態に示す端末Ｚのような監督組織体の外部機関が送信記録をチェックするのに好適な透明性が高いシステムを構築することができる。
　上述した第１～２の実施形態で示したような金融機関等に実装する情報共有システムは、中央管理主体を必要としないＰ２Ｐネットワークであって、複数のノード（端末）によってデータ記録を分散する。これにより、一部のノードがダウンしても、システム全体がダウンしない耐障害性を有するのであり、不稼働時間のない２４時間運用システムの構築を実現する。そして、不正者による改ざんが極めて困難なデータ構造なことからパブリックなネットワーク上でデータの通信がされていても、高いセキュリティ性のあるシステムを低コストで構築することが可能である。
　なお、上述した実施形態では、金融機関に口座を開設するときの個人情報の共有について説明してきたが、必ずしも金融機関同士の情報共有に限定されるものではない。例えば、医療、通信、不動産、教育、行政、物流、保険、任意の契約、インターネットサービス、シェアリングエコノミーサービスなど様々な分野についても本発明の範疇に含まれる。したがって、本発明が適用する分野に応じて、ユーザＸから同意を得ることなく情報の共有が行う場合は、情報共有の確認処理（図４の404，405及び図５のステップS503，S504）は省略され得る。また、集団的コンセンサス（合意）に代わりビットコインで行われるようなブロックチェーン・ベースのProof of Work(POW)の計算でブロックを生成することが適することもある。分散型台帳技術のいずれのタイプであっても、本発明による技術の適用が可能である。
　また、個人情報に限らず、デジタルアセットとして定義可能な情報（例えば、権利や価値記録）の共有を複数の機関又は組織で行う場合も本発明の技術的意義が発揮されることになろう。
　なお、本発明は、ＣＤ－ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードしたプログラム、及びこれら記憶媒体を発明の範疇として含む。
　さらに、ネットワーク３を介して情報共有システムに参加する各端末は、インターネットや専用線等のネットワークに接続されたコンピュータである。具体的には、例えばＰＣ（Personal Computer）、携帯電話やスマートフォン、ＰＤＡ（Personal Digital Assistants）、タブレット、ウェアラブル（Wearable）端末等が挙げられる。また、ユーザの携帯端末として、例えば携帯電話やスマートフォン、ＰＤＡ、タブレット、ウェアラブル端末等が挙げられる。ネットワークに有線又は無線で接続された端末及び携帯端末が互いに通信可能に設定されることにより、情報共有システムを構成する。また、上述した実施形態において情報共有システムはＰ２Ｐ型のシステムであるが、必ずしもＰ２Ｐ型の分散型台帳技術でなくいてもよい。ＡＳＰ（Application Service Provider）と連携するシステムとして構成されてもよい。
　３　ネットワーク

Claims (9)

  1. 　ユーザ情報を保有するコンピュータから、前記ユーザ情報を保有しないコンピュータへ、前記ユーザ情報の少なくとも一部がネットワーク経由で共有されるようにする処理を、前記ネットワークに接続する複数のコンピュータに実行させるためのプログラムであって、
    　前記ネットワークに接続するユーザ情報を保有する第一のコンピュータが、前記ユーザ情報に関し第一のコンピュータが保有する第１の秘密鍵に対応する第１の公開鍵を用いて前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化したとき、当該暗号データを前記ネットワークに出力する処理と、
    　前記複数のコンピュータの各々が前記暗号データを受信し、各々の記憶媒体に記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
    　前記ネットワークに接続する前記ユーザ情報を保有しない第二のコンピュータから、前記複数のコンピュータに向けた情報共有要求であって、第二のコンピュータが保有する前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む前記情報取得要求を、前記ネットワークに出力する処理と、
    　前記情報取得要求に応答し、第一のコンピュータが前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを、前記ネットワークに出力する処理と、
    　前記複数のコンピュータの各々に、前記第２の公開鍵を用いて作成された前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
    　第二のコンピュータに、前記第２の秘密鍵を用いて前記ユーザ情報の暗号データを復号化させる処理と、
    　が実行されるようにする、プログラム。
  2. 　前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを前記複数のコンピュータ各々の記憶媒体に記憶させる処理を実行する前に、各コンピュータにおいて記憶媒体に既に記憶されているデータと、記憶しようとする新たな暗号データとを用いた所定の演算が実行され、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶するように制御されている、請求項１に記載のプログラム。
  3. 　前記情報共有要求があったとき、第二のコンピュータが前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する処理を前記複数のコンピュータの少なくとも１つに実行させることを更に含み、前記同意がされたときに限り、前記ユーザ情報は前記第２の公開鍵を用いて暗号されるよう制御する、請求項１又は２に記載のプログラム。
  4. 　前記複数のコンピュータ各々の記憶媒体は、前記暗号データを記憶するとき、前記第１の公開鍵及び前記第２の公開鍵、並びに前記同意のデータの少なくとも何れかと共に記憶させる処理を更に含む、請求項３に記載のプログラム。
  5. 　第二のコンピュータからの情報共有要求に応答して第一のコンピュータが前記第２の公開鍵を用いて前記暗号データを作成する場合、前記第１の秘密鍵を用いて前記暗号データを復号化する代わりに、第一のコンピュータが保有する前記ユーザ情報の生データを直接暗号処理する、請求項１～４の何れか１項に記載のプログラム。
  6. 　ネットワークに接続する複数のコンピュータにより、ユーザ情報を保有するコンピュータから、前記ユーザ情報を保有しないコンピュータへ、前記ユーザ情報の少なくとも一部が共有されるようにする情報共有方法であって、
    　前記ネットワークに接続するユーザ情報を保有する第一のコンピュータが、前記ユーザ情報に関し第一のコンピュータが保有する第１の秘密鍵に対応する第１の公開鍵を用いて前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化したとき、当該暗号データを前記ネットワークに出力する処理と、
    　前記複数のコンピュータの各々が前記暗号データを受信し、各々の記憶媒体に記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
    　前記ネットワークに接続する前記ユーザ情報を保有しない第二のコンピュータから、前記複数のコンピュータに向けた情報共有要求であって、第二のコンピュータが保有する前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む前記情報取得要求を、前記ネットワークに出力する処理と、
    　前記情報取得要求に応答し、第一のコンピュータが、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを前記ネットワークに出力する処理と、
    　前記複数のコンピュータの各々が、前記第２の公開鍵を用いて作成された前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを記憶する処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
    　第二のコンピュータが、前記第２の秘密鍵を用いて前記ユーザ情報の暗号データを復号化する処理と、
    　が実行されるようにする、方法。
  7. 　前記複数のコンピュータの各々は、前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを各々の記憶媒体に記憶する処理を実行する前に、各自の記憶媒体に既に記憶されているデータと、記憶しようとする新たな前記ユーザ情報の暗号データとを用いた所定の演算を実行し、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶する、請求項６に記載の方法。
  8. 　前記情報共有要求があったとき、第二のコンピュータが前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する処理を前記複数のコンピュータの少なくとも１つが実行することを更に含み、前記同意がされたときに限り、前記ユーザ情報は前記第２の公開鍵を用いて暗号される、請求項６又は７に記載の方法。
  9. 　前記複数のコンピュータ各々の記憶媒体は、前記暗号データの記憶するとき前記第１の公開鍵及び前記第２の公開鍵、並びに前記同意のデータの少なくとも何れかと共に記憶する処理を更に含む、請求項８に記載の方法。
PCT/JP2017/031251 2016-08-30 2017-08-30 情報共有システム WO2018043599A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018521136A JP6524347B2 (ja) 2016-08-30 2017-08-30 情報共有システム
EP17846603.3A EP3509006B1 (en) 2016-08-30 2017-08-30 Information sharing system
ES17846603T ES2906075T3 (es) 2016-08-30 2017-08-30 Sistema de intercambio de información

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-167961 2016-08-30
JP2016167961 2016-08-30

Publications (1)

Publication Number Publication Date
WO2018043599A1 true WO2018043599A1 (ja) 2018-03-08

Family

ID=61301756

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/031251 WO2018043599A1 (ja) 2016-08-30 2017-08-30 情報共有システム

Country Status (4)

Country Link
EP (1) EP3509006B1 (ja)
JP (1) JP6524347B2 (ja)
ES (1) ES2906075T3 (ja)
WO (1) WO2018043599A1 (ja)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6438615B1 (ja) * 2018-03-29 2018-12-19 株式会社三井住友銀行 ブロックチェーン上での正誤判断・結果共有システム
JP2019219782A (ja) * 2018-06-18 2019-12-26 Ｎｅｃソリューションイノベータ株式会社 サービス提供システムおよびサービス提供方法
JP2019219780A (ja) * 2018-06-18 2019-12-26 Ｎｅｃソリューションイノベータ株式会社 個人情報管理システム、サービス提供システム、方法およびプログラム
KR102052835B1 (ko) * 2018-07-31 2020-01-08 중앙대학교 산학협력단 이중 지출 방지를 위한 수신자 지향 트랜잭션 검증 방법 및 장치
JP2020025232A (ja) * 2018-08-08 2020-02-13 株式会社ＤａｔａＳｉｇｎ パーソナルデータ管理システム
WO2020049656A1 (ja) * 2018-09-05 2020-03-12 学校法人法政大学 医療情報管理システム及びそれに用いるメンバー装置
JP6670976B1 (ja) * 2018-10-22 2020-03-25 力 松永 データ管理システムおよびデータ管理方法
JP2020048195A (ja) * 2018-09-18 2020-03-26 エヌエイチエヌ コーポレーション ブロックチェーンネットワークのノード間の合意をなす方法及び複数のノードの分散ネットワークで構成されたブロックチェーンシステム及びブロックチェーンシステムのプロセッサにより実行される複数のノード間の合意をなすための方法
JP2020064483A (ja) * 2018-10-18 2020-04-23 株式会社日立製作所 本人確認支援装置および本人確認支援方法
WO2020084718A1 (ja) * 2018-10-22 2020-04-30 力 松永 データ管理システムおよびデータ管理方法
JP2020092287A (ja) * 2018-12-03 2020-06-11 富士通株式会社 通信装置、通信方法、および通信プログラム
JP2020155801A (ja) * 2019-03-18 2020-09-24 株式会社野村総合研究所 情報管理システム及びその方法
JP2021099626A (ja) * 2019-12-20 2021-07-01 株式会社レシカ アンケートデータの管理・分析システム
JP2021525016A (ja) * 2018-05-23 2021-09-16 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ ブロックチェーン・ネットワークにおける自動コミット・トランザクション管理
CN113632413A (zh) * 2019-03-25 2021-11-09 美光科技公司 使用存储器作为区块链中的块
JP2022080961A (ja) * 2020-11-19 2022-05-31 三菱電機インフォメーションシステムズ株式会社 保険仲介装置、保険仲介方法、保険仲介プログラム及び保険仲介システム

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102020000B1 (ko) * 2018-10-31 2019-09-09 주식회사 스위클 사용증명방식 블록체인 기반의 일회용 개인키를 이용한 개인정보 제공 시스템 및 방법
WO2021075057A1 (en) * 2019-10-18 2021-04-22 Loch Energy, Ltd. Digital currency operation system and operation method using fully homological encryption scheme
CN111930847B (zh) * 2020-09-16 2021-01-08 深圳壹账通智能科技有限公司 基于区块链的数据处理方法、装置及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003233683A (ja) * 2002-02-13 2003-08-22 Ntt Data Corp 個人情報開示方法および個人情報開示システム
JP2004213461A (ja) * 2003-01-07 2004-07-29 Ntt Comware Corp 個人情報流通システム、及び個人情報流通方法
WO2016007904A1 (en) * 2014-07-11 2016-01-14 Ribbit.me! USA Inc. Distributed ledger protocol to incentivize transactional and non-transactional commerce
JP2016081134A (ja) * 2014-10-10 2016-05-16 山下　健一 広告閲覧促進システム、情報処理方法及びプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3973045B2 (ja) * 2005-06-14 2007-09-05 北陸日本電気ソフトウェア株式会社 プライバシー保護暗号化方法、プライバシー保護暗号化システムおよびプライバシー保護暗号化プログラム
JP5404501B2 (ja) * 2010-03-30 2014-02-05 日本電信電話株式会社 暗号化情報の有効期限延長システム、有効期限延長方法及びプログラム
CA2875823C (en) * 2012-06-29 2021-01-05 Id Dataweb, Inc. System and method for establishing and monetizing trusted identities in cyberspace with personal data service and user console
US9584492B2 (en) * 2014-06-23 2017-02-28 Vmware, Inc. Cryptographic proxy service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003233683A (ja) * 2002-02-13 2003-08-22 Ntt Data Corp 個人情報開示方法および個人情報開示システム
JP2004213461A (ja) * 2003-01-07 2004-07-29 Ntt Comware Corp 個人情報流通システム、及び個人情報流通方法
WO2016007904A1 (en) * 2014-07-11 2016-01-14 Ribbit.me! USA Inc. Distributed ledger protocol to incentivize transactional and non-transactional commerce
JP2016081134A (ja) * 2014-10-10 2016-05-16 山下　健一 広告閲覧促進システム、情報処理方法及びプログラム

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6438615B1 (ja) * 2018-03-29 2018-12-19 株式会社三井住友銀行 ブロックチェーン上での正誤判断・結果共有システム
JP2019176432A (ja) * 2018-03-29 2019-10-10 株式会社三井住友銀行 ブロックチェーン上での正誤判断・結果共有システム
JP2021525016A (ja) * 2018-05-23 2021-09-16 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ ブロックチェーン・ネットワークにおける自動コミット・トランザクション管理
JP7228322B2 (ja) 2018-05-23 2023-02-24 インターナショナル・ビジネス・マシーンズ・コーポレーション ブロックチェーン・ネットワークにおける自動コミット・トランザクション管理
JP2019219782A (ja) * 2018-06-18 2019-12-26 Ｎｅｃソリューションイノベータ株式会社 サービス提供システムおよびサービス提供方法
JP2019219780A (ja) * 2018-06-18 2019-12-26 Ｎｅｃソリューションイノベータ株式会社 個人情報管理システム、サービス提供システム、方法およびプログラム
KR102052835B1 (ko) * 2018-07-31 2020-01-08 중앙대학교 산학협력단 이중 지출 방지를 위한 수신자 지향 트랜잭션 검증 방법 및 장치
JP2020025232A (ja) * 2018-08-08 2020-02-13 株式会社ＤａｔａＳｉｇｎ パーソナルデータ管理システム
WO2020049656A1 (ja) * 2018-09-05 2020-03-12 学校法人法政大学 医療情報管理システム及びそれに用いるメンバー装置
JP2020048195A (ja) * 2018-09-18 2020-03-26 エヌエイチエヌ コーポレーション ブロックチェーンネットワークのノード間の合意をなす方法及び複数のノードの分散ネットワークで構成されたブロックチェーンシステム及びブロックチェーンシステムのプロセッサにより実行される複数のノード間の合意をなすための方法
JP6998348B2 (ja) 2018-09-18 2022-01-18 エヌエイチエヌ コーポレーション 複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法
JP2020064483A (ja) * 2018-10-18 2020-04-23 株式会社日立製作所 本人確認支援装置および本人確認支援方法
JP7090008B2 (ja) 2018-10-18 2022-06-23 株式会社日立製作所 本人確認支援装置および本人確認支援方法
JP6670976B1 (ja) * 2018-10-22 2020-03-25 力 松永 データ管理システムおよびデータ管理方法
WO2020084718A1 (ja) * 2018-10-22 2020-04-30 力 松永 データ管理システムおよびデータ管理方法
JP2020092287A (ja) * 2018-12-03 2020-06-11 富士通株式会社 通信装置、通信方法、および通信プログラム
JP7209518B2 (ja) 2018-12-03 2023-01-20 富士通株式会社 通信装置、通信方法、および通信プログラム
JP2020155801A (ja) * 2019-03-18 2020-09-24 株式会社野村総合研究所 情報管理システム及びその方法
CN111709047A (zh) * 2019-03-18 2020-09-25 株式会社野村综合研究所 信息管理系统及其方法
JP7235941B2 (ja) 2019-03-18 2023-03-09 株式会社野村総合研究所 情報管理システム及びその方法
CN111709047B (zh) * 2019-03-18 2023-09-08 株式会社野村综合研究所 信息管理系统及其方法
US11856085B2 (en) 2019-03-18 2023-12-26 Nomura Research Institute, Ltd. Information management system and method for the same
JP2022526936A (ja) * 2019-03-25 2022-05-27 マイクロン テクノロジー，インク． ブロックチェーンにおけるブロックとしてのメモリの使用
CN113632413A (zh) * 2019-03-25 2021-11-09 美光科技公司 使用存储器作为区块链中的块
JP2021099626A (ja) * 2019-12-20 2021-07-01 株式会社レシカ アンケートデータの管理・分析システム
JP2022080961A (ja) * 2020-11-19 2022-05-31 三菱電機インフォメーションシステムズ株式会社 保険仲介装置、保険仲介方法、保険仲介プログラム及び保険仲介システム
JP7291113B2 (ja) 2020-11-19 2023-06-14 三菱電機インフォメーションシステムズ株式会社 保険仲介装置、保険仲介方法、保険仲介プログラム及び保険仲介システム

Also Published As

Publication number Publication date
EP3509006A1 (en) 2019-07-10
JPWO2018043599A1 (ja) 2018-09-13
JP6524347B2 (ja) 2019-06-05
ES2906075T3 (es) 2022-04-13
EP3509006B1 (en) 2022-01-12
EP3509006A4 (en) 2020-04-15

Similar Documents

Publication Publication Date Title
WO2018043599A1 (ja) 情報共有システム
JP7350030B2 (ja) 複数のトランザクションをブロックチェーンに記録する方法及びシステム
US10673632B2 (en) Method for managing a trusted identity
US10949511B2 (en) Multicomputer processing for data authentication using a blockchain approach
US11799631B2 (en) Privacy optimized data mining system and methods
US20160162897A1 (en) System and method for user authentication using crypto-currency transactions as access tokens
CN110462621A (zh) 在区块链网络中管理敏感数据元素
CN109845220A (zh) 用于提供区块链参与者身份绑定的方法和装置
JP7114078B2 (ja) 電子認証方法及びプログラム
JP2005328574A (ja) キー寄託機能付き暗号システムおよび方法
KR102383099B1 (ko) 블록체인 기반의 did 서비스, ipfs 기반의 데이터 공유 기술, 및 개인키 분산 저장 기술이 결합된 비대면 대용량 문서 접근 블록체인 시스템
US20210365584A1 (en) Portable reputation brokering using linked blockchains and shared events
Bergquist Blockchain technology and smart contracts: privacy-preserving tools
CN112991045B (zh) 基于区块链的医疗健康消费融资方法、装置、设备及介质
US20230259899A1 (en) Method, participant unit, transaction register and payment system for managing transaction data sets
US20230360042A1 (en) Method, system, and computer-readable medium for secured multi-lateral data exchange over a computer network
Sahmim et al. Edge computing: smart identity wallet based architecture and user centric
JP6967211B1 (ja) 違法な取引を防止しつつ匿名ユーザの参加も許容する暗号資産の取引のための完全分散型ブロックチェーンシステム及びコンピュータープログラム
WO2021060340A1 (ja) 取引情報処理システム
Hardjono et al. Privacy-preserving claims exchange networks for virtual asset service providers
KR20210041984A (ko) Kyc 데이터와 생체인증정보를 보유한 스마트 디바이스를 활용한 블록체인 개인키 생성 방법
US20230267426A1 (en) Payment system, coin register, participant unit, transaction register, monitoring register and method for payment with electronic coin data sets
US20230091509A1 (en) Method for directly transmitting electronic coin datasets between terminals, payment system, protection system and monitoring entity
Nabih An Approach for Data Privacy Management for Banking Using Consortium Blockchain
Kathole et al. Leveraging Blockchain in Sharing and Managing Health Record Credential

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018521136

Country of ref document: JP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17846603

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017846603

Country of ref document: EP

Effective date: 20190401