JP6524347B2

JP6524347B2 - 情報共有システム

Info

Publication number: JP6524347B2
Application number: JP2018521136A
Authority: JP
Inventors: 誠武宮; 岡田　隆; 岡田　　隆
Original assignee: SORAMITSU CO., LTD.
Current assignee: SORAMITSU CO., LTD.
Priority date: 2016-08-30
Filing date: 2017-08-30
Publication date: 2019-06-05
Anticipated expiration: 2037-08-30
Also published as: JPWO2018043599A1; EP3509006A1; WO2018043599A1; ES2906075T3; EP3509006A4; EP3509006B1

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)、端末Ｙ（１）は所定の手続きに従って（例えば、氏名や住所等が本人確認書類に記載の内容と合致しているか、記載住所と居住地は一致しているか、反社会的勢力との取引とは無関係であることを宣言することの確約書の要求等）口座開設の要件を満たすと判断できたとき、ユーザ用の口座を開設する。

また、端末Ｙ（１）は、開設した口座に対して秘密鍵（Ｓ₁）と公開鍵（Ｐ₁）の鍵ペアを作成し、公開鍵（Ｐ１）を用いてユーザＸの個人情報を暗号化して暗号データを生成すると、ネットワーク３に暗号データ及び公開鍵（Ｐ₁）を出力する。ネットワーク３に接続する端末Ｙ（１）以外の端末Ｙ（２）〜Ｙ（Ｎ）及び端末Ｚは、ネットワーク３上に出力されたユーザＸの個人情報の暗号データ及び公開鍵（Ｐ₁）を受け取り、詳細は後述するが、合意形成プロセスによって集団合意が得られた場合には、自己が管理する記憶媒体にその暗号データを公開鍵（Ｐ１）と対応づけて記憶する(204)。本実施形態においてネットワーク３にデータを出力するとは、図２に示す分散型台帳データベースにデータを渡す、即ち各端末Ｙ及び端末Ｚが各々の記憶媒体に格納するデータを受け取れる状態にすることをあらわしている（図４も同様）。

なお、端末Ｙ（１）が情報共有システム１０に参加し、ネットワーク上の承認グループ（すなわち、特許請求の範囲の「複数のコンピュータ」）の構成員となるために、あらかじめ承認グループの間で、公開鍵及び秘密鍵の鍵ペアを複数個取り決めている場合は、端末Ｙ（１）はユーザＸの口座開設の際に、複数個の中の一つのペアを公開鍵（Ｐ₁）及び秘密鍵（Ｓ₁）として使用するようにしてもよい。なお、ユーザＸに対する鍵ペアは１組であるとは限らず、一人のユーザが複数の鍵ペアを有することもある。
また、端末Ｚが、端末Ｙ（ｉ）（ｉ＝1，2，…）の公開鍵を記憶・管理している場合は、端末Ｙ（１）は端末Ｚから公開鍵（Ｐ₁）を受信するようにしてもよい。このとき、端末Ｚは、自己の記憶媒体内に公開鍵を記憶・管理することのみならず、クラウドサービスが利用可能な状況であればデータのクラウド型管理を行うようにしてもよい。

暗号データ及び公開鍵（Ｐ₁）は、端末Ｚ、及び銀行の端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…の各々に記憶されることが重要である。各々に記憶とは、基本的にはこれら全ての端末、若しくは所定の比率（様々な事情により一部の端末が記憶処理を実行できないことを考慮し、ほぼ全てに等しいとみなせる例えば９０％等の比率）以上の数の端末に記憶することを意味する。上述したとおり、第１の実施形態の場合、端末Ｙ（１）〜Ｙ（Ｎ）及び端末ＺによってＰ２Ｐ型分散型台帳技術が具現化されるため、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚへの記憶処理を行う。この場合、詳細は後述するが、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの各々で記憶する情報又はデータは、完全同一であることが必要である。

次に、ユーザの携帯端末Ｘ（１）を認証するのに必要な鍵ペアが各銀行の端末Ｙで設定される処理を説明する。まず、携帯端末Ｘ（１）に所定のアプリケーション等をダウンロードさせる。ダウンロードしたアプリケーション等が携帯端末Ｘ（１）で登録されると、このアプリケーション等によってユーザ署名に用いる秘密鍵（Ｓ₂）、及び秘密鍵（Ｓ₂）に対応する公開鍵（Ｐ₂）の少なくとも１つの鍵ペア（Ｓ₂,Ｐ₂）が発行される。その後、携帯端末Ｘ（１）が公開鍵（Ｐ₂）をネットワーク１０に出力すると、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚは、このユーザ署名用の公開鍵（Ｐ₂）を受信して暗号データと対応させ、各自の記録媒体に登録する(205)。端末Ｚは、携帯端末Ｘ（１）を、すなわち当該ユーザＸを一意に識別する情報として公開鍵（Ｐ₂）を扱う旨の登録完了報告を、携帯端末Ｘ（１）に送信する(206)。携帯端末Ｘ（１）の認証は、そのユーザがこれまで口座開設したことがなければ初めての金融機関が個人認証すればよいが、すでに他の金融機関にも当該ユーザの口座が開設済みで個人認証しているのであれば、個人認証した複数の金融機関の何れかが行ってもよい。
なお、秘密鍵（Ｓ₂）は、携帯端末Ｘ（１）のメモリに保管されるが、ＩＤカード、ＳＩＭカード等への記憶も含む。

図３は、上述した情報のやり取りで行われる処理をフローチャートにして示している。図３を参照しながらあらためて処理の流れを確認すると、ユーザＸが携帯端末Ｘ（１）を介してＡ銀行の端末Ｙ（１）向けて口座開設要求を行うと（ステップS300）、携帯端末Ｘ（１）から入力されたユーザＸの個人情報が端末Ｙ（１）に提供される（ステップS301）。端末Ｙ（１）はこの個人情報（即ち、ユーザＸ自身）に関する少なくとも１つの鍵ペア（公開鍵Ｐ₁、秘密鍵Ｓ₁）を確認し（ステップS302）、公開鍵Ｐ₁を用いて個人情報を暗号化する（ステップS303）。なお、暗号アルゴリズムは任意の暗号アルゴリズムが適用し得るものであり、特に限定していない。

端末Ｙ（１）は、個人情報の暗号データ及び暗号に用いた公開鍵（Ｐ₁）をネットワーク３に出力する（ステップS304）。したがって、ネットワーク３上には、ユーザＸの個人情報そのもの（暗号化していないという意味）が流出されることはなく、常に“暗号データ”に変換されている。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれは、ネットワーク３上の個人情報の暗号データが記憶されるに値する“正しい”データであるかの処理結果に基づき、“正しい”データという集団合意が得られた場合は各自の記録媒体に格納する（ステップS305）。また、個人情報の暗号データは、公開鍵（Ｐ₁）と対応づけて記憶するのが望ましい。記憶されるに値する“正しい”データであるかの集団合意処理についての詳細は後述する。

なお、本実施形態においては、個人情報の暗号データがネットワーク３上に出力され、各端末Ｙ及び端末Ｚの記憶媒体に記憶されるとして説明しているが、暗号データ自体を必ずしも記憶しなければならないというものではない。個人情報の暗号データに代わりに、暗号データが保存されているリンク先情報（例えば、記憶領域をアクセスするためのＵＲＩ）や、具体的なアドレス情報を暗号化して各端末の記憶媒体に記憶してもよい。暗号データそのものを記憶しないことは、記憶媒体の省スペース化につながる。

端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの各記憶媒体に記憶される個人情報の暗号データの一例を図６に示す。これ以外に、リスク情報、信用情報、任意のディジタル資産に関する暗号データをあわせて記憶するようにしてもよい。
図６から明らかなように、端末Ｙ（１）等の記憶手段では、暗号化された状態で格納されているため、その内容を判読することができない。例えば、ユーザＸの氏名が“53F83EA7”であるので、誰の個人情報であるか、どのような内容の情報であるかは、端末Ｙ（１）を除けば、「複数のコンピュータ」である端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚでさえも、秘密鍵Ｓ₁を知らないので特定することができない。

金融機関はインターネットなどのパブリックネットワーク経由でアクセス可能な状態で個人情報が保管されることに極めて慎重な立場であるため、個人情報を誰もが容易に認識できる態様で保管することに否定的であろう。この点、本実施形態は暗号化データを保管するので、仮に個人情報や関連するリンク情報等に関する暗号データが流出しても、秘密鍵を保有していない限り個人情報が解読されることはなく、安全性が確保されている。

ステップS305までの処理によって、ユーザＸの個人情報が暗号化された状態で管理されたことになるが、第１の実施形態では、なりすましを防止するため、ユーザＸの本人の正当性を認証するための鍵を設定する処理を引き続き実行する。まず、「複数のコンピュータ」である端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの少なくとも１つ（ここでは、その１つのコンピュータが端末Ｚであるとする。）は、ユーザＸを署名するのに必要な鍵を生成する所定のアプリケーションをネットワーク３上からダウンロードするためのサイトやアプリケーションをユーザの携帯端末Ｘ（１）に所定のメッセージで表示させる（例えば、「個人認証のために電子署名用の鍵を設定する必要があります。下記サイトやアプリケーションに入り、鍵設定アプリケーションをダウンロードして下さい。」等）。ユーザＸは、このようなメッセージに従い自分の携帯端末Ｘ（１）にアプリケーションを登録し、少なくとも１つの鍵ペア（公開鍵Ｐ₂、秘密鍵Ｓ₂）を発行させる（ステップS306）。そして、秘密鍵Ｓ₂は携帯端末Ｘ（１）内で保管し、公開鍵Ｐ₂については端末Ｚに返送する（ステップS307）。端末Ｚは、送信された公開鍵Ｐ₂を、ユーザＸの公開鍵であることがわかるように、例えばテーブル形式で対応づけて登録しておく（ステップS308）。なお、端末Ｚは、ユーザＸの公開鍵Ｐ₂を共有するため、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…に送信し、端末Ｚと同じようなテーブル管理又は各端末に適した管理態様で保管するようにしてもよい。

なお、ステップS306〜S308に関するユーザ認証用鍵ペアの設定及び登録の処理を、本実施の形態のようにＡ銀行の口座開設時のときに同時に必ずしも実行しなければならないというものではない。後述するような他のＢ銀行への口座開設時に、ユーザの同意を求めた際、そのときに所定のアプリケーションをダウンロードして、少なくとも１つの鍵ペア（公開鍵Ｐ₂、秘密鍵Ｓ₂）を発行させる処理を実行したとしても問題はない。

・Ｂ銀行の口座開設
次に、ユーザＸがＡ銀行とは異なるＢ銀行にも口座を開設しようとするときの情報のやり取りを図４に、フローチャートを図５に示す。なお、Ｂ銀行に口座開設する時点でＡ銀行には口座が開設されており、図２及び図３を参照しながら説明したデータのやり取り及び処理手順によってユーザＸの個人情報や関連するリンク情報に関する暗号データが端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの記憶媒体に記憶されているとする。

従来は、ユーザＸがＢ銀行の口座を開設要求しようとすると、Ｂ銀行はＡ銀行と同様にユーザＸから個人情報を提供してもらうのがこれまでやり方であった。これに対し、本発明の場合、Ｂ銀行が口座開設に必要なユーザＸの個人情報は、ユーザＸから提供してもらうのではなく、既に個人情報が提供されているＡ銀行の協力の下、Ｂ銀行へ提供される。具体的には、ユーザＸからの口座開設要求を受けたＢ銀行の端末Ｙ（２）は、ネットワーク３上にユーザＸの個人情報の取得要求を出力する（図４の402、図５のステップS502）。このとき、ユーザＸが誰であるかを特定できる情報は暗号化されており、上述したように例えば、ユーザＸの氏名が“53F83EA7”である。個人情報の取得要求は、端末Ｙ（２）がユーザＸの個人情報の暗号データを解読するに必要な秘密鍵（Ｓ₃）とペアをなす公開鍵（Ｐ₃）を含んでいる（図４の403）。

ネットワーク３上に出力されたユーザＸの個人情報の取得要求に応答して、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの少なくとも１つ（ここでは、その１つのコンピュータが端末Ｚであるとする。）は、Ｂ銀行に個人情報を提供してもよいかの同意をユーザＸから得ることを試みる（図４の404，図５のステップS503）。なお、端末Ｚの代りに、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…の何れかであってもよい。

ユーザＸへの連絡は、携帯端末Ｘ（１）に電話をして直接ユーザＸに確認したり、携帯端末Ｘ（１）に確認メールを送信する。あるいは、ユーザＸが端末Ｙ（２）上で口座開設要求した際、申込み画面のＱＲコード（登録商標）等を携帯端末Ｘ（１）のアプリで読み込み送信させることで確認をとる方法でもよい。

ユーザＸが同意するときは秘密鍵（Ｓ₂）を用いた電子認証によって知らせる。具体的には例えば、端末Ｚは任意の長さのランダム数値をユーザＸの携帯端末Ｘ（１）に送信し、これを受けてユーザＸはランダム数値を秘密鍵（Ｓ₂）に用いて電子署名を作成する。端末Ｚは秘密鍵（Ｓ₂）と鍵ペアをなす公開鍵（Ｐ₂）を登録しているので、この公開鍵（Ｐ₂）を使って電子署名を復号する。元のランダム数値に一致すれば、ユーザＸの公開鍵（Ｐ₂）で復号できる暗号文（電子署名）を作成できるのは秘密鍵（Ｓ₂）をもつユーザＸしかいないことから、ユーザＸ本人の同意であることが証明される。このように、電子署名を利用して不正な者がユーザＸになりすまして同意がなされることを排除する。

端末Ｚは、ユーザＸからの同意が得られたかを確認する（図４の405，図５のステップS504）。実際には、例えば、所定のパラメータやフラグの値に、同意を示すデータとしての“１”が設定されているか等を判定すればよい。同意が得られなければ（上記例の場合でいえば、”１“以外のデータが設定されている）、Ｂ銀行に個人情報が提供される処理は中止される（図５のステップS504のNo）。ユーザＸの許可なしに個人情報が渡されることを防止するためである。一方、端末ＺがユーザＸの同意を受信した場合（図５のステップS504のYes）、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…（端末Ｚを含む）に向けて、ユーザＸの個人情報をＢ銀行用に公開鍵（Ｐ₃）を用いて暗号化することを要求する（図４の406，図５のステップS505）。また、端末Ｚは、受信した同意データを端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…にも送信して、「複数のコンピュータ」である端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚ間でこの同意データが共有されるようにする。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれは同意データを各自の記憶媒体に格納し、各端末が同意に関する同一のデータを保有する。同意データは、個人情報や関連するリンク情報を暗号化した暗号データと一緒にして記憶媒体に格納してもよい。これらデータは古い同意データから順に時系列に記憶されることもあるし、時系列に沿わずにランダムな順で記憶されることもある。

上述したように、Ａ銀行の口座開設の時、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのすべて若しくは所定の比率以上の数の端末は個人情報等の同一暗号データを共有しているので、端末Ｙ（２）は自分の記憶媒体にユーザＸを示す“53F83EA7”等の暗号データを記憶しているが、復号化する秘密鍵（Ｓ₁）をもっていない。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれが暗号データの復号化を実行しようとしても、“53F83EA7”に関する暗号データを復号できるのは秘密鍵（Ｓ₁）を有する端末Ｙ（１）のみである。ただし、ユーザＸの個人情報の取得要求をした端末Ｙ（２）は、秘密鍵（Ｓ₁）によって暗号データを復号し更に公開鍵（Ｐ₃）を使って暗号化する処理を行える端末が、端末Ｙ（１）であることを識別してはいない。端末Ｙ（２）は、ネットワーク３経由で取得要求をすると、情報共有システム１０に参加する「複数のコンピュータ」のいずれかによって作成される暗号データがネットワーク３上に出力されるのを待つことになる。

端末Ｙ（１）は、自分の記憶媒体内から取得要求において指定されている“53f83ks7”の暗号データを読み出す（図４の407，図５のステップS506）。どの暗号データに関する取得要求かであるかに関してユーザＸの識別データ“53F83EA7”が指定されている代わりに、公開鍵（Ｐ₁）が取得要求で指定されているときでも、端末Ｙ（１）は公開鍵（Ｐ₁）及び秘密鍵（Ｓ₁）の鍵ペアを設定/選択していることから、公開鍵（Ｐ₁）と鍵ペアをなす秘密鍵（Ｓ₁）を有しているのは自分であることを識別できるため、ユーザＸの暗号データを読み出すことが可能である。

次に、端末Ｙ（１）は、ユーザＸの暗号データを、秘密鍵（Ｓ₁）を用いて平文である個人情報に復号すると、さらに公開鍵（Ｐ₃）を使用して再びユーザＸの個人情報を暗号化し、Ｂ銀行向けの暗号データにする（図５のステップS507）。或いは、Ａ銀行内の使用のためにユーザＸの暗号化していない個人情報がＡ銀行の内部ネットワークで保管されている場合には、端末Ｙ（１）はその暗号していない個人情報から公開鍵（Ｐ₃）を使って暗号化することもある。
ただし、端末Ｙ（１）は、公開鍵（Ｐ₃）を使って作成する暗号データが、情報共有システム１０に参加する「複数のコンピュータ」のどの端末によって復号されるのかについては識別してはいない。

ところで、端末Ｙ（１）は、公開鍵（Ｐ₃）を使用してユーザＸの個人情報をＢ銀行向けに暗号化するが、これは、例えばＣ銀行もユーザＸの個人情報を要求したとき、Ｂ銀行に提供する暗号個人データと、Ｃ銀行に提供する暗号個人データとは異なるという意味である。したがって、Ｃ銀行向けの暗号は、公開鍵（Ｐ₃）とは異なる公開鍵（例えば、Ｐ₄）が使用されることになる。同一ユーザの個人情報であるが、データの要求元に応じてそれぞれ異なる暗号個人データを生成し送信するようにしているため、ネットワーク上のセキュリティ性が一層高まる。上述したように、端末Ｙ（１）は、公開鍵（Ｐ₃）を用いて作成した暗号データがどの銀行向けの暗号化であることは分からない状況で、その暗号データをネットワーク上に出力する（図４の408、図５のステップS508）。そして、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれは、個人情報の暗号データとして記憶する価値がある“正しい”データであるかを判定する所定の演算処理に基づき、“正しい”データであるという集団合意が得られた場合は各自の記録媒体に格納する（図５のステップS509）。個人情報の暗号データを公開鍵（Ｐ₃）と対応づけて記憶させてもよいし、上述した同意データと共に記憶させてもよい。端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚのそれぞれが各自の記憶媒体に記憶する個人情報の暗号データは、同一のデータである。

公開鍵（Ｐ₃）とペアをなす秘密鍵（Ｓ₃）を有するのは端末Ｙ（２）である。端末Ｙ（２）は、暗号個人データを受信し（図４の409）、保管してある秘密鍵（Ｓ₃）を用いて暗号個人データを復号することでユーザＸの個人情報を取得する（図５のステップS510）。なお、端末Ｙ（１）が、公開鍵（Ｐ₃）を使って暗号化した暗号データは、まず端末Ｚに送信され、端末Ｚから、端末Ｙ（２）、端末Ｙ（３）…に向けて転送するようにしてもよい。

その後、ユーザＸが更に銀行Ｃにも口座開設しようとする場合、銀行Ａ及び銀行Ｂに個人情報が提供されていることから、Ｃ銀行向けの暗号データを作成することが可能になる端末は、端末Ｙ（１）及び端末Ｙ（２）である。どちらの端末が優先されるかは、あらかじめルールとして設定しておけばよい。例えば、端末Ｙ（１）及び端末Ｙ（２）のどちらもＣ銀行向けの暗号データを作成し、ネットワーク１０に出力するタイミングが早い方を採用したり、ランダムに選択したいずれか一つの端末に暗号処理を実行させたりする等が考えられる。２つの端末Ｙ（１）及び端末Ｙ（２）がＣ銀行向けの暗号データの作成に適用可能な場合、仮に一方の端末が利用不可能や通信不良であるという状況になったとしても、即座に端末Ｙ（２）が代行できるので、Ｃ銀行への要求に迅速に対応することが可能である。

上述の手順により、端末Ｙ（１）から端末Ｙ（２）へ個人情報の暗号データが伝達され、最終的に端末Ｙ（２）は復号化した個人情報を取得することになる。このとき、情報共有システムに参加する「複数のコンピュータ」のすべてにおいて、同意や暗号データが同一の履歴データとして保有されるという点は、本発明の特徴の一つである。従来のシステムの場合、情報の譲渡側端末と譲受側端末とが暗号データを共有し、情報を要求していない他の端末が暗号データを敢えて保有することはない。本発明は、情報共有システムに参加する「複数のコンピュータ」のすべて若しくは所定の比率以上の数の端末が、ネットワーク上のデータの送受信記録を一連のものとして保有し、しかも各々で保有するデータの送受信記録が常に同一であることを要求するという、ネットワーク上での完全同一性があるＰ２Ｐ型分散記録である。これについては、第２の実施形態及び第３の実施形態を説明した後で述べる。

また、本発明の更なる特徴の一つは、個人情報の取得要求をした端末は暗号データを作成したのがどの端末であるのかを知らずにネットワーク経由で暗号データを取得し、どの端末が取得要求をしているのか知らない状況で暗号化データを作成してネットワーク上に出力されるという点である。つまり、伝達される情報の送信元と受信先が互いに知られないので、いわゆるエスクロー(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が示すように、端末Ｙ（１）は公開鍵Ｐ₃及び暗号データを受信するので、端末Ｙ（１）は、(i)送信元が送ってきた公開鍵Ｐ₃、(ii)端末Ｙ（１）の公開鍵Ｐ₃、(iii)暗号データを、取引データとしてリーダー端末Ｚに送信する（ステップS701）。その他、(iv)同意データが取引データに含まれていれもよい。

リーダー端末Ｚは、端末Ｙ（１）からの取引データを所定のバッファ配列に格納する。ここで、バッファ配列としているのは、取引データは端末Ｙ（１）以外の他の各端末Ｙからも受信するからである。すなわち、図４では、説明の便宜上、銀行端末として端末Ｙ（１）及び端末Ｙ（２）のみを記載しているが、実際には分散型台帳データベースを介した端末Ｙ（１）及び端末Ｙ（２）間のやりとりと同様の取引データが、他の銀行端末Ｙ間でも行われている。このため、リーダー端末Ｚには、端末Ｙ（１）以外の端末Ｙからの取引データが送信されている。リーダー端末Ｚは、これらの取引データを受信すると順次バッファ配列に格納する（ステップS702）。

次に、ステップS703で、リーダー端末Ｚは、バッファ配列（buf[]）内の各取引データに関し、所定の演算の実行を各端末に命令するメッセージを送信する。ユーザＸ₁に関する取引データがバッファ配列buf[1]に格納され、ユーザＸ₂に関する取引データがバッファ配列buf[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）。同様に、ユーザＸ₂に関してもハッシュ演算を実行して、「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

ユーザ情報を保有するコンピュータから、前記ユーザ情報を保有しないコンピュータへ、前記ユーザ情報の少なくとも一部がネットワーク経由で共有されるようにする処理を、前記ネットワークに接続する複数のコンピュータが協働して行うための各コンピュータのプログラムであって、
前記ネットワークに接続し、前記ユーザ情報を保有する第一のコンピュータのプログラムが、第一のコンピュータに、前記ユーザ情報に関し第一のコンピュータが保有する第１の秘密鍵に対応する第１の公開鍵を用いて前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化させて暗号データを作成し、前記暗号データを前記ネットワークに出力させる処理と、
前記複数のコンピュータの各コンピュータが前記暗号データを受信し、各々の記憶媒体に記憶する処理であって、各コンピュータのプログラムがそのコンピュータに、前記複数のコンピュータ間で同一の暗号データを記憶させる当該処理と、
前記ネットワークに接続し、前記ユーザ情報を保有しない第二のコンピュータから、前記複数のコンピュータに向けた情報取得要求であって、第二のコンピュータのプログラムが第二のコンピュータに、第二のコンピュータが保有する前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む前記情報取得要求を、前記ネットワークに出力させる処理と、
前記情報取得要求に応答し、第一のコンピュータのプログラムが第一のコンピュータに、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化させ、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを、前記ネットワークに出力させる処理と、
前記複数のコンピュータの各コンピュータのプログラムが、そのコンピュータに、前記第２の公開鍵を用いて作成された前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
第二のコンピュータのプログラムが第二のコンピュータに、前記第２の秘密鍵を用いて前記ユーザ情報の暗号データを復号化させる処理と、
を実行させるための、プログラム。
前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを前記複数のコンピュータ各々の記憶媒体に記憶させる処理の実行前に、各コンピュータのプログラムは、そのコンピュータにおいて記憶媒体に既に記憶されているデータと、記憶しようとする新たな暗号データとを用いた所定の演算を実行させ、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶するように制御されている、請求項１に記載のプログラム。
前記情報取得要求があったとき、第二のコンピュータが前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する処理を前記複数のコンピュータの少なくとも１つに実行させることを更に含み、前記同意がされたときに限り、第一のコンピュータのプログラムは第一のコンピュータに、前記ユーザ情報を前記第２の公開鍵を用いて暗号させるよう制御する、請求項１又は２に記載のプログラム。
前記複数のコンピュータ各々の記憶媒体が前記暗号データを記憶するとき、各コンピュータのプログラムはそのコンピュータに、前記第１の公開鍵及び前記第２の公開鍵、並びに前記同意のデータの少なくとも何れかと共に記憶させる、請求項３に記載のプログラム。
第二のコンピュータからの情報取得要求に応答して第一のコンピュータが前記第２の公開鍵を用いて前記暗号データを作成する場合、第一のコンピュータのプログラムは第一のコンピュータに、前記第１の秘密鍵を用いて前記暗号データを復号化する代わりに、第一のコンピュータが保有する前記ユーザ情報の生データを直接暗号処理させる、請求項１〜４の何れか１項に記載のプログラム。
ネットワークに接続する複数のコンピュータにより、ユーザ情報を保有するコンピュータから、前記ユーザ情報を保有しないコンピュータへ、前記ユーザ情報の少なくとも一部を共有する情報共有方法であって、
前記ネットワークに接続し、前記ユーザ情報を保有する第一のコンピュータが、前記ユーザ情報に関し第一のコンピュータが保有する第１の秘密鍵に対応する第１の公開鍵を用いて前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化して暗号データを作成したとき、前記暗号データを前記ネットワークに出力する処理と、
前記複数のコンピュータの各々が前記暗号データを受信し、各々の記憶媒体に記憶させる処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
前記ネットワークに接続し、前記ユーザ情報を保有しない第二のコンピュータから、前記複数のコンピュータに向けた情報取得要求であって、第二のコンピュータが保有する前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む前記情報取得要求を、前記ネットワークに出力する処理と、
前記情報取得要求に応答し、第一のコンピュータが、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを前記ネットワークに出力する処理と、
前記複数のコンピュータの各々が、前記第２の公開鍵を用いて作成された前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを記憶する処理であって、前記複数のコンピュータ間で同一の暗号データが記憶される当該処理と、
第二のコンピュータが、前記第２の秘密鍵を用いて前記ユーザ情報の暗号データを復号化する処理と、
を実行する、方法。
前記複数のコンピュータの各々は、前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを各々の記憶媒体に記憶する処理を実行する前に、各自の記憶媒体に既に記憶されているデータと、記憶しようとする新たな前記ユーザ情報の暗号データとを用いた所定の演算を実行し、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶する、請求項６に記載の方法。
前記情報取得要求があったとき、第二のコンピュータが前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する処理を前記複数のコンピュータの少なくとも１つが実行することを更に含み、前記同意がされたときに限り、前記ユーザ情報は前記第２の公開鍵を用いて暗号される、請求項６又は７に記載の方法。
前記複数のコンピュータ各々の記憶媒体は、前記暗号データの記憶するとき前記第１の公開鍵及び前記第２の公開鍵、並びに前記同意のデータの少なくとも何れかと共に記憶する処理を更に含む、請求項８に記載の方法。
ユーザ情報を保有するコンピュータから、前記ユーザ情報を保有しないコンピュータへ、前記ユーザ情報の少なくとも一部がネットワーク経由で共有されるようにするために複数のコンピュータによる協働処理が行われるシステムであって、
前記ネットワークに接続し、前記ユーザ情報を保有する第一のコンピュータは、前記ユーザ情報に関し第一のコンピュータが保有する第１の秘密鍵に対応する第１の公開鍵を用いて前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化して暗号データを作成し、前記暗号データを前記ネットワークに出力し、
前記ネットワークに接続する前記複数のコンピュータの各コンピュータが前記暗号データを受信して各々の記憶媒体に記憶し、その結果、前記複数のコンピュータ間で同一の暗号データが記憶され、
前記ネットワークに接続し、前記ユーザ情報を保有しない第二のコンピュータは、前記複数のコンピュータに向けて、第二のコンピュータが保有する前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む情報取得要求を前記ネットワークに出力し、
前記情報取得要求に応答した第一のコンピュータは、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを、前記ネットワークに出力し、前記ネットワークに接続する前記複数のコンピュータの各コンピュータは、前記第２の公開鍵を用いて作成された前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを記憶し、その結果、前記複数のコンピュータ間で同一の暗号データが記憶され、
第二のコンピュータは、前記第２の秘密鍵を用いて前記ユーザ情報の暗号データを復号化する、システム。
前記複数のコンピュータ各々が、前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを各自の記憶媒体に記憶する前に、各コンピュータの記憶媒体に既に記憶されているデータと、記憶しようとする新たな暗号データとを用いた所定の演算を実行し、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶する、請求項１０に記載のシステム。
前記複数のコンピュータの少なくとも１つは、前記情報取得要求があったときに、第二のコンピュータが前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する命令を実行し、前記同意の返信を受信したときに限り、第一のコンピュータに対して、前記ユーザ情報を前記第２の公開鍵を用いて暗号させる、請求項１０又は１１に記載のシステム。
ユーザ情報の少なくとも一部をネットワーク経由で提供する第一の装置であって、
第一の装置が保有又は管理する前記ユーザ情報の第１の秘密鍵に対応した第１の公開鍵を用いて、前記ユーザ情報又は前記ユーザ情報の格納先情報を暗号化して暗号データを作成する手段と、
前記暗号データを前記ネットワークに出力する手段と、
前記ネットワークに接続する複数の装置が、前記暗号データを受信して各々の記憶媒体に当該暗号データを記憶し、前記ユーザ情報を保有しない第二の装置が前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む情報取得要求を前記ネットワークに出力したことに応答して、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを暗号化する手段と、を備え、
前記第二の装置が前記ネットワークから受信した前記暗号データを前記第２の秘密鍵を用いて復号化することで、前記第二の装置が前記ユーザ情報を取得することを可能にする、第一の装置。
前記複数の装置の各々が、前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを各自の記憶媒体に記憶する前に、各装置の記憶媒体に既に記憶されているデータと、記憶しようとする新たな暗号データとを用いた所定の演算を実行し、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶するよう制御されている、請求項１３に記載の第一の装置。
前記複数の装置の少なくとも１つは、前記情報取得要求があったときに、第二の装置が前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する命令を実行し、前記複数の装置の少なくとも１つから前記同意の返信を受信したときに限り、前記ユーザ情報を前記第２の公開鍵を用いて暗号する、請求項１３又は１４に記載の第一の装置。
第一の装置が保有又は管理するユーザ情報をネットワークを介して取得する第二の装置であって、
前記ユーザ情報に関する第１の秘密鍵に対応する第１の公開鍵を用いて、第一の装置が作成した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データが前記ネットワーク上に出力されたことに応答して、前記ネットワークに接続する複数の装置が前記暗号データを受信して各自の記憶媒体に記憶した場合に、第二の装置が前記ユーザ情報に関する第２の秘密鍵に対応する第２の公開鍵を含む情報取得要求を前記ネットワークに出力する手段と、
前記情報取得要求に応答して第一の装置が、前記第１の秘密鍵を用いて前記ユーザ情報の暗号データを復号化し、更に前記第２の公開鍵を用いて再び暗号化した前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを前記ネットワークに出力した場合、前記暗号データを前記第２の秘密鍵を用いて復号化する手段と、を備え、
前記復号化により前記ユーザ情報を取得できる、第二の装置。
前記複数の装置の各々が、前記ユーザ情報又は前記ユーザ情報の格納先情報の暗号データを各自の記憶媒体に記憶する前に、各装置の記憶媒体に既に記憶されているデータと、記憶しようとする新たな暗号データとを用いた所定の演算を実行し、演算値の一致が所定数又は所定の比率以上のとき前記暗号データを追加的に記憶するよう制御されている、請求項１６に記載の第二の装置。
前記複数の装置の少なくとも１つは、前記情報取得要求があったときに、第二の装置が前記ユーザ情報を保有することに同意するか否かを前記ユーザ情報の提供者に確認する命令を実行し、前記同意の返信を受信したときに限り、第一の装置に対して、前記ユーザ情報を前記第２の公開鍵を用いて暗号させるよう制御されている、請求項１６又は１７に記載の第二の装置。