(57)【要約】【課題】高い消失・改ざん耐性を保ちつつ指定された範囲でデータの共有を可能とする管理を実現する分散データ管理システムおよびそのプログラムを提供する。【解決手段】本発明の分散データ管理システムは、複数のブロック4bがつながれるブロックチェーン4がコンピュータ1a、1b、1cに格納され、ブロック4bに格納される情報は、複数のアクセスレベルl1〜lmに分割され、かつアクセスレベルl1〜lmに応じた異なる第１の鍵pkl1〜pklmによって暗号化されている。  また、ブロック4bへの情報の登録に際して用いられる再暗号化鍵rklxay、rkux1yは、第１の鍵pkl1〜pklmと前記登録を行うノードがもつ第２の鍵pku1-nのとの間で決められていることが好ましい。【選択図】図２
2020129760.tif 000002
【特許請求の範囲】
【請求項１】
複数のブロックがつながれるブロックチェーンがコンピュータに格納され、
前記ブロックに格納される情報は、
複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている
ことを特徴とする分散データ管理システム。
【請求項２】
請求項１に記載の分散データ管理システムにおいて、
前記ブロックへの情報の登録に際して用いられる再暗号化鍵は、前記第１の鍵と前記登録を行うノードがもつ第２の鍵のとの間で決められている
ことを特徴とする分散データ管理システム。
【請求項３】
請求項２に記載の分散データ管理システムにおいて、
前記再暗号化鍵は、前記第１の鍵と前記第２の鍵とのマトリクスの形で格納されている
ことを特徴とする分散データ管理システム。
【請求項４】
請求項１から請求項３のうちの何れか一項に記載の分散データ管理システムにおいて、
前記ブロックの情報は、ノードまたは参照ノードがもつアクセスレベルの第４の鍵で復号化される
ことを特徴とする分散データ管理システム。
【請求項５】
請求項１から請求項４のうちの何れか一項に記載の分散データ管理システムにおいて、
前記ブロックへの情報の登録に用いるハッシュ値の情報は、最高のアクセスレベルの前記第１の鍵によって暗号化されている
ことを特徴とする分散データ管理システム。
【請求項６】
複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンと、
前記ブロックチェーンに情報を登録する複数のノードと、
前記ノードが前記ブロックに情報を登録する際に前記ノードに第２の鍵を与える認証局と、
前記第１の鍵と前記第２の鍵との間の再暗号化鍵の情報が格納され前記ブロックへの情報の登録の認証を行うプロキシサーバの機能とを備え、
前記複数のノードと、前記プロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードと、前記認証局とはネットワークを介して接続されている
ことを特徴とする分散データ管理システム。
【請求項７】
請求項６に記載の分散データ管理システムにおいて、
前記ブロックチェーンへの前記ノードによる情報の登録に際して、
前記認証局は、前記ノードに前記第２の鍵を与え、
前記ノードは、前記第２の鍵で暗号化したデータを前記プロキシサーバに送って認証要求を行い、ハッシュ値の情報を前記ブロックチェーンから取り出して暗号化して前記プロキシサーバに送り第１の認証を受け、前記ハッシュ値から新しいハッシュ値を計算し、暗号化した前記新しいハッシュ値の情報を前記プロキシサーバに送り第２の認証を受け、暗号化した前記新しいハッシュ値とともに情報を前記ブロックチェーンに登録し、
前記プロキシサーバは、前記ノードによる前記ブロックチェーンへの情報の登録に際して、前記ノードからの前記第２の鍵で暗号化したデータの情報を受けて前記ノードの認証を行い、前記第１の認証と前記第２の認証とを前記再暗号化鍵の情報を用いて行う
ことを特徴とする分散データ管理システム。
【請求項８】
ノードを備え、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンが格納されるとともに、前記第１の鍵と第２の鍵との間の再暗号化鍵の情報が格納される分散データ管理システムのプログラムであって、
ノードが前記第２の鍵で暗号化したデータを送って認証要求が行われる第１のステップと、
前記第２の鍵で暗号化したデータを受けて前記ノードの認証が行われる第２のステップと、
前記ノードは、暗号化したハッシュ値の情報を送る第３ステップと、
前記暗号化したハッシュ値の情報を受けて、前記再暗号化鍵の情報を用いて情報の正当性の認証が行われる第４のステップと、
前記ノードは、前記情報の正当性の認証許可情報を受け、暗号化した新しいハッシュ値とともに情報を前記ブロックチェーンに登録する第５のステップとを
実行させるための分散データ管理システムのプログラム。
【請求項９】
請求項８に記載の分散データ管理システムのプログラムにおいて、
前記第３ステップと前記第４のステップは、
前記ノードが、ハッシュ値の情報を前記ブロックチェーンから取り出して暗号化して送るステップと、
暗号化した前記ハッシュ値の情報を受けて、前記再暗号化鍵の情報を用いて第１の認証を行うステップと、
前記ノードは、前記ハッシュ値から新しいハッシュ値を計算し、新しいハッシュ値の情報を暗号化して送るステップと、
暗号化した前記新しいハッシュ値の情報を受けて、前記再暗号化鍵の情報を用いて第２の認証を行うステップとを有している
ことを特徴とする分散データ管理システムのプログラム。
【請求項１０】
請求項８または請求項９に記載の分散データ管理システムのプログラムにおいて、
前記再暗号化鍵は、前記第１の鍵と前記第２の鍵とのマトリクスの形で格納されている
ことを特徴とする分散データ管理システムのプログラム。
【請求項１１】
請求項８から請求項１０のうちの何れか一項に記載の分散データ管理システムのプログラムにおいて、
前記ハッシュ値の情報は、最高のアクセスレベルの前記第１の鍵によって暗号化されている
ことを特徴とする分散データ管理システムのプログラム。
【請求項１２】
請求項８から請求項１１のうちの何れか一項に記載の分散データ管理システムのプログラムにおいて、
前記分散データ管理システムは、さらにデータ参照ノードを備え、
前記ノードまたは前記データ参照ノードが、自身が有するアクセスレベルの第４の鍵を用いて前記ブロックに格納される情報を復号化するステップを
実行させるための分散データ管理システムのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散データ管理システムおよびそのプログラムに関する。
【背景技術】
【０００２】
IoT等のスマート社会の実現においては、電子化された医療・健康・介護等の情報の有効利用は重要な課題である。各個人の医療・健康・介護等に関する情報は、単一の医療機関からだけでなく、複数の病院、クリニック、薬局、さらには普段の生活における生理計測データも統合して蓄積して有効に活用することが望まれる。
【０００３】
そこで、個々の医療機関における診療に関する履歴は、従来の紙やフィルムといった物理媒体での蓄積から、電子カルテ等の形で電子化された蓄積への移行が進んでいる。電子化することで、保存のためのコストが下がり、検索の機能等により利用の効率も向上している。さらに、蓄積された医療情報をコンピュータで解析することによる医療改善等に向けた二次利用も始まっている。
【０００４】
しかし、医療・健康・介護等に関する情報はプライバシーに関わる情報を多く含むことから、蓄積や活用する上でセキュリティを保つことが重要である。さらに、情報の消失や改ざん耐性が高い管理の実現が望まれる。
【０００５】
そのため、その具体的な管理手段は未だ明確になっていない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2018-166000号公報（図1〜図3、段落0021〜0027等）
【特許文献２】特開2018-147016号公報（図2、段落0017〜0032等）
【特許文献３】特表2008-509634号公報（図1(a)〜(d)、段落0010〜0015等）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、昨今、ブロックチェーンの技術が医療・健康・介護等に関する情報の蓄積に適合しているのではと注目されつつある。
ブロックチェーン技術は、元々は仮想通貨の実現のために提案された技術である。取引（トランザクション）を記録した台帳を、一台のホストコンピュータで管理して保持するのではなく、複数のコンピュータに重複した形で分散して保持する。
【０００８】
そして、分散した重複データの間の矛盾がないことを確認することで、一部のコンピュータへの攻撃によるデータの消失や改ざんを防いでいる。複数のトランザクションをブロックとしてまとめ、その内容を数値（ハッシュ値）にマッピングする。そして、時系列でブロックをチェーンとしてつなげて、前のブロックのハッシュ値を木構造化した情報（Merkle Tree）として次のブロックが持つ。これにより、分散したMerkle Tree間の矛盾の発生から、トランザクションの消失や改ざんを検出可能としている。
【０００９】
仮想通貨のブロックチェーンでは、この無矛盾性を確認してブロックをチェーンにつなげる処理（PoW: Proof of Work）に工夫をして報酬をつけ、多数の作業者（マイナー）の中で早い者勝ちとすることで、多数が行う時間制約の中で不正なチェーンができないようにしている。つまり、ビットコインのブロックチェーンでは、不正防止のために「誰がどんな取引をしたのか」といったトランザクションの内容を多数の作業者が見ることが前提となっている。このため、情報開示範囲の考慮が必要な処理にはそのまま適用できない。
【００１０】
イーサリアム、ネム、リップル等の仮想通貨では、PoW の代わりに、無矛盾性確認のやり方を変えたPoS (Proof of Stake)、PoI (Proof of Importance)、PoC (Proof of Consensus) といった手法も使われているが、いずれもトランザクションの内容は秘匿化されてはいない。これらの仮想通貨のブロックチェーンは、不特定多数の利用者を想定するためパブリックチェーンと呼ばれるが、利用者を限定したプライベートチェーンも提案、実現されている。
【００１１】
しかし、多人数の生理計測データや多数の機関からの医療情報収集を想定すると、利用者限定のプライベートチェーンは向かない。一方、パブリックチェーンで秘匿性を確保するために、ゼロ知識証明を使ったzk-SNARKが提案されている。しかし、zk-SNARKでは、全ての情報が秘匿化されてしまい、蓄積された情報の解析等を考えた場合には、やはりそのまま適用することはできない。
【００１２】
上述のブロックチェーンに係る技術として、特許文献1〜3がある。
特許文献１には、上位ネットワークと下位ネットワークとをブロックチェーンで管理し、ネットワークそのものを階層化することが記載されている。
【００１３】
特許文献2には、ハッシュ値の扱いと管理方法について記載されている。詳細には、階層化された管理単位に対応する複数のブロックチェーンとし、階層毎にブロックチェーンをもつこととしている
特許文献3には、暗号のやりとり方法が記載されている。暗号化されたメディアストリームを復号する際にインデックスを利用するというもので、特定の人だけがブロックを繋げることが記載されている。
【００１４】
しかし、特許文献１〜3は、ブロックチェーンに置かれた情報を指定する範囲で共有できない。
【００１５】
本発明は上記実状に鑑み創案されたものであり、高い消失・改ざん耐性を保持しつつ指定する範囲でデータの共有を可能とする管理を実現する分散データ管理システムおよびそのプログラムの提供を目的とする。
【課題を解決するための手段】
【００１６】
前記課題を解決するため、第１の本発明の分散データ管理システムは、複数のブロックがつながれるブロックチェーンがコンピュータに格納され、前記ブロックに格納される情報は、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている。
【００１７】
第２の本発明の分散データ管理システムは、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンと、前記ブロックチェーンに情報を登録する複数のノードと、前記ノードが前記ブロックに情報を登録する際に前記ノードに第２の鍵を与える認証局と、前記第１の鍵と前記第２の鍵との間の再暗号化鍵の情報が格納され前記ブロックへの情報の登録の認証を行うプロキシサーバの機能とを備え、前記複数のノードと、前記プロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードと、前記認証局と、前記認証局とはネットワークを介して接続されている。
【００１８】
第３の本発明の分散データ管理システムは、ノードを備え、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンが格納されるとともに、前記第１の鍵と第２の鍵との間の再暗号化鍵の情報が格納される分散データ管理システムのプログラムであって、ノードが前記第２の鍵で暗号化したデータを送って認証要求が行われる第１のステップと、前記第２の鍵で暗号化したデータを受けて前記ノードの認証が行われる第２のステップと、前記ノードは、暗号化したハッシュ値の情報を送る第３ステップと、前記暗号化したハッシュ値の情報を受けて、前記再暗号化鍵の情報を用いて情報の正当性の認証が行われる第４のステップと、前記ノードは、前記情報の正当性の認証許可情報を受け、暗号化した新しいハッシュ値とともに情報を前記ブロックチェーンに登録する第５のステップとを実行させている。
【発明の効果】
【００１９】
本発明によれば、高い消失・改ざん耐性を保持しつつ指定する範囲でデータの共有を可能とする管理を実現する分散データ管理システムおよびそのプログラムを実現できる。
【図面の簡単な説明】
【００２０】
【図１】本発明に係る実施形態の分散データ管理システムの構成の模式図。
【図２】実施形態の分散データ管理システムの機能の模式ブロック図。
【図３】登録・利用ノードの利用者の各公開鍵と 、ブロックが分割されたレベル1〜レベルmの各公開鍵との間の再暗号化鍵のマトリクスを示す図。
【図４】ブロックが分割されたレベル1〜レベルmの各公開鍵と 、登録・利用ノードの利用者の各公開鍵との間の再暗号化鍵のマトリクスを示す図。
【図５】ブロックが分割されたレベル1〜レベルmの各公開鍵と 、データ解析ノードの解析者の各公開鍵との間の解析者用の再暗号化鍵のマトリクスを示す図。
【図６】分散データ管理システムの登録処理における認証処理のシーケンス図。
【図７】分散データ管理システムの登録処理における血圧と体重とを登録するための処理のシーケンス図。
【図８】分散データ管理システムの登録処理におけるハッシュ値から新しいハッシュ値の計算と暗号化処理のシーケンス図。
【図９】データ解析者がデータ解析ノードを用いてブロックチェーンのブロックのデータを参照する参照処理のシーケンス図。
【図１０】利用者が登録・利用ノードを用いてブロックチェーンのブロックのデータを参照する参照処理のシーケンス図。
【図１１】変形例の分散データ管理システムの機能を示す模式ブロック図。
【図１２】本発明の実施例1の分散データ管理システムの構成の模式図。
【図１３】本発明の実施例1の分散データ管理システムの機能の模式ブロック図。
【図１４】実施形態2の分散データ管理システムの構成の一例を示す模式図。
【図１５】実施形態2の他例の分散データ管理システムの構成を示す模式図。
【図１６】分散データ管理システムのデータ構造を示す図。
【図１７】分散データ管理システムの機能の概要を示す図。
【図１８】ユーザ登録処理のフロー図。
【図１９】ユーザ削除処理のフロー図。
【図２０】情報登録処理のフロー図。
【図２１】復号化処理のフロー図。
【発明を実施するための形態】
【００２１】
以下、本発明の実施形態について、適宜図面を参照しながら詳細に説明する。
本発明の分散データ管理システムは、データ蓄積システムのセキュリティ管理に用いるブロックチェーンの認証にレベル付けを加えることにより、アプリケーションに適した形で消失・改ざん耐性を保持しつつ指定された範囲でデータの共有を可能とする管理を実現している。
【００２２】
具体的には、本発明はデータ蓄積システムのパブリックブロックチェーンの技術に下記1)〜5)の仕組みを取り入れることによって、消失や改竄への耐性を持ちつつ、開示可能な範囲に応じて情報を提供する分散データ管理を実現する。
なお、ブロックチェーンとは、ハッシュポインタを使用し改竄検出が容易なデータ構造を持ち，且つ，当該データをネットワーク上に分散する多数のノードに保持させることで，高可用性及びデータ同一性等を実現する技術と定義されている。（日本ブロックチェーン協会. http://jba-web.jp/.）
【００２３】
1) データが蓄積されるブロックの中身をアクセスレベル（プライバシーレベル）で分割して鍵を変えて暗号化
2) 二次利用データ解析者が復号できるアクセスレベルを設定
3) 再暗号化鍵をプロキシサーバで２つのマトリクスの形で持つ
4) ブロックへの接続認証を最高アクセスレベル（例．本人または医療関係者）のみで持つ
5) ブロックの認証に必要なMerkle Treeの情報を最高アクセスレベルで暗号化
上記のような構成にすることにより、メディカルデータ、センサデータなどをレベルによって指定された範囲の人（ここでは、本人と医療関係者）によってブロックチェーンを繋げること、レベルによって指定された範囲の人とデータの解析が可能となる。
【００２４】
その結果、セキュリティレベル（アクセスレベル）やデータ改ざん耐性を確保しつつ、データ解析結果の報告、アラート情報を出す等の充実したヘルスケアサポートが実現できる。
図1に、本発明に係る実施形態の分散データ管理システムSの構成を模式図に示す。
実施形態の分散データ管理システムSは、Internet10 に接続されたノード（1a、1b、1c）、プロキシサーバ2、および認証局3を備えて構成されている。なお、ネットワークはInternet10 以外のネットワークでもよい。また、プロキシサーバ2 の機能は、ノード内に実現されていてもよい。
【００２５】
ノード（1a、1b、1c）、プロキシサーバ2、および認証局3は全て、プロセス処理能力を持つコンピュータで構成される。
すなわち、ノード（1a、1b、1c）、プロキシサーバ2、および認証局3は、それぞれCPU、記憶装置、入・出力装置を有している。ノード（1a、1b、1c）、プロキシサーバ2、および認証局3は、それぞれのCPUでプログラムを実行することで、それぞれの機能が実現される。
【００２６】
ノード（1a、1b、1c）は、それぞれ同じブロックチェーン4に複数のデータを蓄積する。
ノード（1a、1b、1c）は、データを登録・利用する登録・利用ノード1a、データを蓄積するデータ蓄積ノード1b、およびデータを解析するデータ解析ノード1cの3種類を想定する。登録・利用ノード1a、データ蓄積ノード1b、およびデータ解析ノード1cには、分散データ管理システムSのプログラム（ソフトウェア）が格納されている。
【００２７】
図2に、実施形態の分散データ管理システムSの機能を模式ブロック図に示す。
登録・利用ノード1aは、ブロックチェーン4を構築し、蓄積し、利用する。登録・利用ノード1aは、例えば、患者のパソコン、携帯端末、高機能ヘルスメータ、高機能血圧測定装置等、医者、看護師、医療従事者等のパソコンである。
【００２８】
蓄積ノード1bは、ブロックチェーン4を蓄積する。蓄積ノード1bは、例えば、当該分散データ管理システムSの管理者が管理するデータサーバである。
データ解析ノード1cは、登録・利用ノード1aで構築されたブロックチェーンを蓄積し、解析するノードである。データ解析ノード1cは、例えば、医療情報の解析、クリニカルパスの抽出等を行うデータ二次利用者のパソコンである。
【００２９】
ブロックチェーン4は、登録・利用ノード1a内で複製される。複製されたブロックチェーン4は、登録・利用ノード1a、蓄積ノード1b、データ解析ノード1cに蓄積される。
登録・利用ノード1aでブロックチェーン4を蓄積する際、プライバシー保護のプライバシーレベルによってブロック4bの内部を分割している。ここで、プライバシーレベル1を最高とする。
【００３０】
図2では、ブロック4bをプライバシーレベル1〜プライバシーレベルmまでに分割した場合を示している。
そして、それぞれのブロック4bの分割した部分に対してプロキシ再暗号化可能な暗号（例えばBBS暗号）の公開鍵を切り替えて暗号化を行い、ブロック4bをブロックチェーン4につないで蓄積する。
【００３１】
＜分散データ管理システムSの手続き＞
以下、分散データ管理システムSの手続きを述べる。
なお、文Tの暗号鍵kxによる暗号化はenc(T, kx)と表し、この暗号化により生成される暗号文はc(T, kx)と表す。また、暗号文c(T, kx)の暗号鍵kyによる復号化はdec(c(T, kx), ky)と表す。公開鍵はpkxと表し、秘密鍵はskxと表す。
【００３２】
公開鍵pkxで暗号化された暗号文c(T, pkx)から再暗号化鍵rkxyでの再暗号化はreenc(c(T, kx), rkxy)で表す。
【００３３】
図２において、登録・利用ノード1aのユーザuxは公開鍵pkuxをもち、秘密鍵skuxをもつ。ブロックチェーン４のブロック４ｂに蓄積された情報は、プライバシーレベル1〜mに分割され、プライバシーレベル別の公開鍵pkl1〜pklmで暗号化されている。
データ解析ノード1cのユーザazは公開鍵pkazをもち、秘密鍵skazをもつ。
【００３４】
認証局3は、予め、プライバシーレベルl1〜lmそれぞれに対する公開鍵と秘密鍵のペア (pkl1, skl1), …, (pklm, sklm) と、登録・利用ノード1aの各利用者 u1 〜unに対する公開鍵と秘密鍵のペア (pku1, sku1), …, (pkun, skun)を作成する。
【００３５】
図３に、登録・利用ノード1aの利用者u1〜unの各公開鍵pku1-nと 、ブロック４ｂが分割されたプライバシーレベル1〜mの各公開鍵pkl1-m との間の再暗号化鍵のマトリクスRKulを示す。
また、認証局3は、図３に示す登録・利用ノード1aの利用者u1〜unの各公開鍵pku1-nと 、ブロック４ｂが分割されたレベル1〜レベルmの各公開鍵pkl1-m の間の再暗号化鍵のマトリクスRKulを作成する。
【００３６】
ここで、再暗号化鍵のマトリクスRKulのx列目、y行目の要素RKul[x,y]は、利用者uｘの公開鍵pkuxからプライバシーレベルｙの公開鍵pklyへの再暗号化鍵rkux1yに対応する。
【００３７】
図４に、ブロック４ｂが分割されたプライバシーレベル1〜レベルmの各公開鍵pkl1-m と 、登録・利用ノード1aの利用者u1〜unの各公開鍵pku1-nとの間の再暗号化鍵のマトリクスRKluを示す。
認証局3は、図４に示すブロック４ｂが分割されたプライバシーレベル1〜レベルmの各公開鍵pkl1-m と 、登録・利用ノード1aの利用者u1〜nの各公開鍵pku1-nとの間の再暗号化鍵のマトリクスRKluを作成する。
【００３８】
ここで、再暗号化鍵のマトリクスRKluのx列目、y行目の要素RKlu[x,y]は、プライバシーレベルｘの公開鍵pklxから利用者ｙの公開鍵pkuyへの再暗号化鍵rklxuyに対応している。
【００３９】
図５に、ブロック４ｂが分割されたプライバシーレベル1〜mの各公開鍵pkl1-m と 、データ解析ノード1cの解析者1〜qの各公開鍵pka1-qとの間の解析者用の再暗号化鍵のマトリクスRKlaを示す。
認証局3は、図５に示すブロック４ｂが分割されたプライバシーレベル1〜mの各公開鍵pkl1-m と 、データ解析ノード1cのデータ解析者1〜qの各公開鍵pka1-qとの間のデータ解析者用の再暗号化鍵のマトリクスRKlaを作成する。
【００４０】
ここで、再暗号化鍵のマトリクスRKlaのx列目、y行目の要素RKl [x,y]は、プライバシーレベルｘの公開鍵pklxから解析者ｙの公開鍵pkuyへの再暗号化鍵rklxayに対応している。
解析者用のマトリクスRKlaはRKluと同様であるが、プライバシーレベル1〜mのうちの許可されるレベル以下の行だけを持ち、それより上のプライバシーレベルの行は持たない。図５に示す解析者用のマトリクスRKlaの例ではl1の行を持たない例を示している。
【００４１】
図２に示すように、プロキシサーバ2は、認証局3から登録・利用ノード1aの利用者u1〜unの各公開鍵pku1-n（pku1〜pkun）、ブロック４ｂが分割されたレベル1〜レベルmの各公開鍵pkl1-m（pkl1 〜pklm）、 データ解析ノード1cの解析者1〜qの各公開鍵pka1-q（pka1〜pkaq）を受け取り、保持する。また、プロキシサーバ2は、認証局3から、再暗号化鍵の２つのマトリクスRKul、RKluと、マトリクスRKlaを受け取り、保持する。また、プロキシサーバ2は、利用者の役割情報を持つ。利用者の役割情報とは、利用者が患者、医者、データ解析者等の属性情報を意味する。
【００４２】
なお、プロキシサーバ2は信頼できると仮定するが、プロキシサーバ2から公開鍵pku1-n、pkl1-m、pka1-qや再暗号化鍵のマトリクスRKul、RKlu、RKlaが流出しても、プライバシーレベル１〜mの秘密鍵skl1-m（skl1〜sklm）、利用者u1〜利用者unの秘密鍵sku1-n（sku1〜skun）を持たない者には復号化することはできない。
【００４３】
＜分散データ管理システムSの登録処理＞
次に、分散データ管理システムSの登録処理について説明する。
図6〜図8に、分散データ管理システムSの登録処理における認証処理のシーケンス図を示す。
【００４４】
図6、下記の図7、図8に示す分散データ管理システムSの登録処理は、登録・利用ノード1a、プロキシサーバ2、および認証局3のそれぞれに格納されるソフトウェア（プログラム）によって行われる。
利用者 ux が登録・利用ノード1a（図1参照）で分散データ管理システムSにログインして鍵を要求すると（図６のステップS100）、利用者 ux が操作する登録・利用ノード1aは、認証局3のサーバから公開鍵と秘密鍵(pkux, skux)を受け取る（ステップS101）。
【００４５】
登録・利用ノード1aは、以下のようにして、まず予めプロキシサーバ2の認証を受ける。
【００４６】
＜登録・利用ノード1aに対する認証＞
認証のための一つの方法としては、登録・利用ノード1aがプロキシサーバ2に認証要求を利用者 ux の公開鍵pkuxとともに送る（ステップS102）。すると、プロキシサーバ2側で乱数Aを生成し保持する（ステップS103）。乱数Aを送られた公開鍵pkuxで暗号化してc(A, pkux)を生成し（ステップS104）、利用者 uxの登録・利用ノード1aに返す（ステップS105）。
【００４７】
利用者uxの登録・利用ノード1aでは、自分の持つ秘密鍵skuxでc(A, pkux)を復号化して、Aを得る（ステップS106）。
そして、例えばA+1を計算して、秘密鍵skuxでA+1を暗号化してc(A+1, skux) を生成する（ステップS107）。そして、登録・利用ノード1aは、c(A+1, skux) をプロキシサーバ2に送る（ステップS108）。
【００４８】
プロキシサーバ2では、c(A+1, skux)を公開鍵pkuxで復号化してA+1を得て、保持していたAとの間で整合性を確認することで、登録・利用ノード1aの認証を行うことができる（ステップS109）。
なお、上述以外の方法で認証を行うことも可能である。
【００４９】
＜血圧値Bと体重値Wの登録＞
図7に、分散データ管理システムSの登録処理における血圧値Bと体重値Wとを登録するための処理のシーケンス図を示す。
次に、利用者 ux が血圧値B（タイプT1）のデータを登録・利用ノード1aでブロックチェーン4に格納したい場合、利用者 ux は、登録・利用ノード1aに血圧 (T1)に 血圧値Bを入力する（図7のステップS110）。
【００５０】
登録・利用ノード1aはBを公開鍵pkuxで暗号化してc(B, pkux)を生成する（ステップS111）。
そして、登録・利用ノード1aは設定したいプライバシーレベルL2とA+2の情報とともに、秘密鍵skuxで暗号化してc((c(B, pkux), L2, A+2), skux)を生成する（ステップS112）。そして、登録・利用ノード1aはc((c(B, pkux), L2, A+2), skux)をプロキシサーバ2に送る（ステップS113）。
【００５１】
プロキシサーバ2では、利用者 ux の公開鍵pkuxを使ってc((c(B, pkux), L2, A+2), skux)を復号化して(c(B, pkux), L2, A+2)を得、A+2の整合性を確認する（ステップS114）。
プロキシサーバ2は、L2(プライバシーレベル2)という指定に従ってRKul[x,2]（利用者 ux のプライバシーレベル2）の再暗号化鍵を用いて再暗号化を行い、c(B, pkl2)を生成する（ステップS115）。
【００５２】
そして、プロキシサーバ2は、c(B, pkl2)を利用者 uxの登録・利用ノード1aに送り返す（ステップS116）。
利用者 uxの登録・利用ノード1aは受け取ったc(B, pkl2)を記憶媒体に保持する（ステップS117）。
【００５３】
引き続き、利用者 ux が体重値WのデータをプライバシーレベルL3でブロックチェーン4に格納したい場合、利用者 ux は登録・利用ノード1aに体重(T2)に体重値Wを入力する（ステップS118）。
そして、登録・利用ノード1aは公開鍵pkuxで体重値Wを暗号化してc(W, pkux)を生成する（ステップS119）。
【００５４】
登録・利用ノード1aは、プライバシーレベルL3とA+3の情報とともに秘密鍵skuxで暗号化してc((c(W, pkux), L3, A+3), skux)を生成する（ステップS120）。
そして、登録・利用ノード1aは、c((c(W, pkux), L3, A+3), skux)をプロキシサーバ2に送る（ステップS121）。プロキシサーバ2では、利用者 ux の公開鍵pkuxを使って復号化して(c(W, pkux), L3, A+3)を得る。プロキシサーバ2は、(c(W, pkux), L3, A+3)で保持していたA+2と、A+3の整合性を確認する（ステップS122）。
【００５５】
その後、プロキシサーバ2は、プライバシーレベルL3の指定に従ってRKul[x,3]の再暗号化鍵を用いて再暗号化を行い、c(W, pkl3)を生成する（ステップS123）。
そして、プロキシサーバ2は、c(W, pkl3)を利用者 uxの登録・利用ノード1aに送り返す（ステップS124）。
【００５６】
利用者 uxの登録・利用ノード1aは受け取ったc(W, pkl3)を記憶媒体に保持する。
【００５７】
＜新しいハッシュ値の計算と暗号化処理＞
図8に、分散データ管理システムSの登録処理におけるハッシュ値から新しいハッシュ値の計算と暗号化処理のシーケンス図を示す。ハッシュ値の処理は、これとは別に、ブロックチェーンのツール等で提供されているものを利用することも可能である。
登録・利用ノード1aで保持するc(B, pkl2)、c(W, pkl3)等をブロックチェーン4に登録するためには、ブロックチェーン4の最新のブロック4b1（図２参照）に格納されたハッシュ情報が必要となる。
【００５８】
このため、利用者 ux の登録・利用ノード1aは、ブロックチェーン4の最新のブロック4b1のトップのプライバシーレベルL1の公開鍵pkl1で暗号化されたハッシュ情報c(Hj, pkl1)を取り出す（ステップS126）。
登録・利用ノード1aは、ハッシュ情報c(Hj, pkl1)と、L1とA+4を自身の秘密鍵skuxで暗号化し、c((c(Hj, pkl1), L1, A+4), skux)を生成する（ステップS127）。
【００５９】
そして、登録・利用ノード1aは、c((c(Hj, pkl1), L1, A+4), skux)をプロキシサーバ2に送る（ステップS128）。
プロキシサーバ2では、利用者 ux の公開鍵pkuxによってc((c(Hj, pkl1), L1, A+4), skux)を復号化し、(c(Hj, pkl1), L1, A+4)を得て、保持していたA+3と、A+4の整合性を確認する（ステップS129）。
【００６０】
プロキシサーバ2は、A+4の整合性を確認後、プライバシーレベルL1の指定に従ってRKlu[1,x]の再暗号化鍵を用いてc(Hj, pkl1)から、c(Hj, pkux)に再暗号化する（ステップS130）。そして、プロキシサーバ2は、利用者 uxの登録・利用ノード1aにc(Hj, pkux)を返す（ステップS131）。
【００６１】
利用者 ux の登録・利用ノード1aは、利用者 uxの秘密鍵skuxを用いてc(Hj, pkux)を復号化して現在のハッシュ値Hjを取り出す（ステップS132）。そして、登録・利用ノード1aは、現在のハッシュ値Hjを用いて新しいハッシュ値Hj+1を計算して生成する（ステップS133）。
【００６２】
次に、登録・利用ノード1aは、利用者 uxの公開鍵pkuxを用いて新しいハッシュ値Hj+1を暗号化してc(Hj+1, pkux)を生成する（ステップS134）。そして、登録・利用ノード1aは、c(Hj+1, pkux)と、新しいハッシュ値Hj+1が格納されるプライバシーレベルL1とA+5を利用者 uxの秘密鍵skuxで暗号化して、c((c(Hj+1, pkux), L1, A+5), skux)を生成する（ステップS135）。登録・利用ノード1aは、c((c(Hj+1, pkux), L1, A+5), skux)をプロキシサーバ2に送る（ステップS136）。
【００６３】
プロキシサーバ2では、利用者 uxの公開鍵pkuxによって、c((c(Hj+1, pkux), L1, A+5), skux)を復号化し、(c(Hj+1, pkux), L1, A+5)を得、保持していたA+4と、A+5の整合性を確認する（ステップS137）。
その後、プロキシサーバ2は、登録・利用ノード1aからのプライバシーレベルL1の指定に従ってRKul[x,1]の再暗号化鍵を用いてc(Hj+1, pkux)から再暗号化して、c(Hj+1, pkl1)を生成する（ステップS138）。そして、プロキシサーバ2は、c(Hj+1, pkl1)を利用者 uxの登録・利用ノード1aに返す（ステップS139）。
【００６４】
利用者 uxの登録・利用ノード1aは、受け取ったc(Hj+1, pkl1)を、タイプT1、T2に相当する保持したc(B, pkl2)およびc(W, pkl3)からの[T1, c(B, pkl2)]、[T2, c(W, pkl3)] とともに、ブロック4bを構成し、ブロック4bのIDの IDk と一緒にブロックチェーン4に接続する（ステップS140）。
【００６５】
＜データ解析者a1〜 aqのデータ参照の処理＞
次に、データ解析者a1〜 aqのブロックチェーン4のブロック4bのデータを参照する処理について説明する。
【００６６】
図2に示すように、データ解析者a〜aqのデータ解析ノード1cにも暗号化されたブロックチェーン4が保持（格納）される。
しかし、データ解析者a〜aqの各データ解析ノード1cは、データ解析者用の再暗号化鍵のマトリクスRKla（図５参照）の構成から、指定されたプライバシーレベルLより上位に対応する 再暗号化鍵RKla[L,x] を持たないため、指定されたプライバシーレベルのLRK2a[L,x]以下のプライバシーレベルしか再暗号化できない。つまりデータ解析者a〜aqは、指定されたプライバシーレベルL以下のブロック4bのデータしか秘密鍵で平文に復号できず、参照できない。
【００６７】
加えて、データ解析者a〜aqのデータ解析ノード1cは、トップレベルのプライバシーレベルで暗号化されたハッシュ情報は再暗号できないため、データ解析者a〜aqは整合性を持った新たなブロック4bをブロックチェーン4につなげることができない。
【００６８】
以下、データ解析者azがブロックチェーン4のブロック4bのデータを参照する処理を説明する。
ここで、データ解析者azは、プライバシーレベルL3以下は許可されているものの、プライバシーレベルL2以上は許可されていないものとする。
【００６９】
図9に、データ解析者azがデータ解析ノード1cを用いてブロックチェーン4のブロック4bのデータを参照する参照処理のシーケンス図を示す。
分散データ管理システムSの参照処理は、データ解析ノード1c、プロキシサーバ2、および認証局3のそれぞれに格納されるソフトウェア（プログラム）によって行われる。
【００７０】
データ解析者ａz がデータ解析ノード1cで分散データ管理システムSにログインして鍵を要求すると（図9のステップS200）、データ解析者ａzが操作するデータ解析ノード1cは、認証局3のサーバから公開鍵と秘密鍵(pkaz, skaz)を受け取る（ステップS201）。
【００７１】
データ解析ノード1cは、以下のようにして、まず予めプロキシサーバ2の認証を受ける。
認証のための一つの方法としては、データ解析ノード1cがプロキシサーバ2に認証要求をデータ解析者ａzの公開鍵pkazとともに送る（ステップS202）。すると、プロキシサーバ2側で乱数Aを生成し保持する（ステップS203）。乱数Aを送られた公開鍵pkazで暗号化してc(A, pkaz)を生成し（ステップS204）、  データ解析者ａzのデータ解析ノード1cに返す（ステップS205）。
【００７２】
データ解析ノード1cでは、データ解析者ａzが持つ秘密鍵skazでc(A, pkaz)を復号化して（ステップS206）、Aを得る。そして、例えばA+1を計算して、秘密鍵skazでA+1を暗号化してc(A+1, skaz) を生成する（ステップS207）。そして、データ解析ノード1cは、c(A+1, skaz) をプロキシサーバ2に送る（ステップS208）。
【００７３】
プロキシサーバ2では、c(A+1, skaz)を公開鍵pkazで復号化してA+1を得て、保持していたAとの間で整合性を確認することで認証を行うことができる（ステップS209）。
なお、上述以外の方法で利用者であるデータ解析ノード1cの認証を行うことも可能である。
【００７４】
続いて、データ解析者ａzがブロック4b（IDk ）の体重値W(T2)を参照する処理を説明する。
【００７５】
データ解析者ａzがブロック4b（IDk ）の体重(T2)をデータ解析ノード1cに入力して要求する（図９のステップS210）。データ解析ノード1cは、IDkとT2を用いて、ブロックチェーン4から[T2, L3, c(W, pkl3)] を取り出す（ステップS211）。そして、データ解析ノード1cは、(c(W, pkl3), L3, A+2)を秘密鍵 skazで暗号化してc((c(W, pkl3), L3, A+2), skaz) をプロキシサーバ2に送る（ステップS212）。プロキシサーバ2は、c((c(W, pkl3), L3, A+2), skaz)を公開鍵pkazで復号化して(c(W, pkl3), L3, A+2)を得、保持していたAと、A+2の正当性を確認して認証を行う（ステップS213）。
【００７６】
プロキシサーバ2はRKla [z,3]を用いて(c(W, pkl3)を再暗号化reenc(c(W, pkl3), RKla [z,3]) して、c(W, pkaz)を得る（ステップS214）。そして、プロキシサーバ2は、c(W, pkaz)をデータ解析ノード1cに送る（ステップS215）。
【００７７】
データ解析ノード1cは、データ解析者ａzの秘密鍵 skazでc(W, pkaz)を複合化してW（体重）を得る（ステップS216）。
続いて、データ解析者ａzがブロック4b（IDk ）の血圧値B (T1)を参照する処理を説明する。
【００７８】
データ解析者ａzがブロック4b（IDk ）の血圧値B (T1)をデータ解析ノード1cに入力して要求する（図9のステップS217）。データ解析ノード1cは、IDkとT1を用いて、ブロックチェーン4から[T1, L2, c(B, pkl2)] を取り出す（ステップS218）。そして、データ解析ノード1cは、(c(B, pkl2), L2, A+3)を、データ解析者ａzの秘密鍵 skazで暗号化してc(c(B, pkl2), L2, A+3), skaz) をプロキシサーバ2に送る（ステップS219）。プロキシサーバ2は、c(c(B, pkl2), L2, A+3), skaz)を、データ解析者ａzの公開鍵pkazで復号化して(c(B, pkl2), L2, A+3)を得、保持していたA+2と、A+3の正当性を確認して認証を行う（ステップS220）。
【００７９】
プロキシサーバ2は再暗号化を試みるが、データ解析者ａzは、プライバシーレベルL2以上は許可されていないのでRKla [z,2]が無いため、再暗号化できない（ステップS221）。そのため、データ解析者ａzのデータ解析ノード1cには、プロキシサーバ2からNG情報が送られ（ステップS222）、データ解析者ａzのデータ解析ノード1cは、アクセス不可能なプライバシーレベルL2以上の 情報(血圧値B)は取得不可となる（ステップS223）。
【００８０】
＜利用者 uyのデータ参照の処理＞
次に、利用者 uyがブロックチェーン4のブロック4bのデータを参照する際の参照処理について説明する。
図10に、利用者 uxが登録・利用ノード1aを用いてブロックチェーン4のブロック4bのデータを参照する参照処理のシーケンス図を示す。
【００８１】
分散データ管理システムSの参照処理は、登録・利用ノード1a、プロキシサーバ2、および認証局3のそれぞれに格納されるソフトウェア（プログラム）によって行われる。
利用者 uxが登録・利用ノード1aで分散データ管理システムSにログインして鍵を要求すると（図9のステップS300）、登録・利用ノード1aは、認証局3のサーバから公開鍵と秘密鍵(pkuy, skuy)を受け取る（ステップS301）。
【００８２】
登録・利用ノード1aは、以下のようにして、まず予めプロキシサーバ2の認証を受ける。
認証のための一つの方法としては、登録・利用ノード1aがプロキシサーバ2に認証要求を利用者 uxの公開鍵pkuyとともに送る（ステップS302）。すると、プロキシサーバ2側で乱数Aを生成し保持する（ステップS303）。そして、乱数Aを送られた公開鍵pkuyで暗号化してc(A, pkuyz)を生成し（ステップS304）、利用者 ux  の登録・利用ノード1aに返す（ステップS305）。
【００８３】
利用者 uxの登録・利用ノード1aでは、自分の持つ秘密鍵skuyでc(A, pkuy)を復号化して（ステップS306）、Aを得る。そして、例えばA+1を計算して、秘密鍵skuyでA+1を暗号化してc(A+1, skuy) を生成する（ステップS307）。そして、登録・利用ノード1aは、c(A+1, skuy) をプロキシサーバ2に送る（ステップS308）。
【００８４】
プロキシサーバ2では、c(A+1, skuy)を公開鍵pkuyで復号化してA+1を得て、保持していたAとの間で整合性を確認することで認証を行うことができる（ステップS309）。
なお、上述以外の方法で認証を行うことも可能である。
【００８５】
続いて、利用者 uxがブロック4bのIDk の体重(T2)を参照する処理を説明する。
次に、利用者 uxがブロック4bのIDk の体重(T2)を登録・利用ノード1aに入力して要求する（図９のステップS310）。データ解析ノード1cは、IDkとT2を用いて、ブロックチェーン4から[T2, L3, c(W, pkl3)] を取り出す（ステップS311）。そして、登録・利用ノード1aは、(c(W, pkl3), L3, A+2)を秘密鍵 skuyで暗号化してc((c(W, pkl3), L3, A+2), skuy) をプロキシサーバ2に送る（ステップS312）。プロキシサーバ2は、c((c(W, pkl3), L3, A+2), skuy)を、利用者 uxの公開鍵pkuyで復号化して(c(W, pkl3), L3, A+2)を得、保持していたA+1との間でA+2の正当性を確認して認証を行う（ステップS313）。
【００８６】
プロキシサーバ2はRKlu [ｙ,3]を用いて(c(W, pkl3))を再暗号化reenc(c(W, pkl3), RKlu [y,3]) して、c(W, pkuy)を得る（ステップS314）。そして、プロキシサーバ2は、c(W, pkuy)を登録・利用ノード1aに送る（ステップS315）。
【００８７】
登録・利用ノード1aは、利用者 uxの秘密鍵 skuyでc(W, pkuy)を復号化して体重値W(T2)を得る（ステップS316）。
続いて、利用者 uxがブロック4b（IDk ）の血圧値B (T1)を参照する処理を説明する。
【００８８】
次に、利用者 uxがブロック4bのIDk の血圧値B (T1)を登録・利用ノード1aに入力して要求する（図10のステップS317）。登録・利用ノード1aは、IDkとT1を用いて、ブロックチェーン4から[T1, L2, c(B, pkl2)] を取り出す（ステップS318）。そして、登録・利用ノード1aは、(c(B, pkl2), L2, A+3)を秘密鍵 skuyで暗号化してc(c(B, pkl2), L2, A+3), skuy) をプロキシサーバ2に送る（ステップS319）。プロキシサーバ2は、c(c(B, pkl2), L2, A+3), skuy)を公開鍵pkuyで復号化して(c(B, pkl2), L2, A+3)を得、保持していたA+2との間でA+3の正当性を確認して認証を行う（ステップS320）。
【００８９】
プロキシサーバ2はRKlu [y,2]で再暗号化を試み、reenc(c(B, pkl2), RKlu [y,2])から c(B, pkuy)を得る（ステップS321）。そして、 プロキシサーバ2は、c(B, pkuy)を登録・利用ノード1aに送る（ステップS322）。登録・利用ノード1aは、c(B, pkuy)を秘密鍵skuyを使って復号化し、血圧値B (T1)を得る（ステップS323）。
【００９０】
＜分散データ管理システムSによる効果＞
従来、ブロックチェーン技術を用いて医療情報を蓄積するアプローチは、消失・改竄を防ぐことが可能なために既に注目を集めている。しかしながら、これまでのところ二次利用を考慮しつつもプライバシーを適切に保護する手法は提案されていない。つまり、本人（患者）、医療従事者、医療情報の二次利用データ解析者、運用管理者という異なる役割に対して、情報の消失、改竄、漏洩を防いで開示範囲を調整する手法は、必要性が高いにも関わらずまだ実現されていない。
【００９１】
そこで、本分散データ管理システムSは、複数のプライバシーレベルl1〜lmに分割され、かつプライバシーレベルl1〜lmに応じた異なる公開鍵pkl1〜pklm（第１の鍵）によって暗号化されている情報が格納される複数のブロック4bがつながれるブロックチェーン4と、ブロックチェーン4に情報を登録する複数のノード（1a）と、ノード（1a）がブロック4bに情報を登録する際にノード（1a）に公開鍵pku1-n第２の鍵（公開鍵pku1-n）を与える認証局3と、第１の鍵公開鍵pkl1〜pklmと第２の鍵（公開鍵pku1-n）との間の再暗号化鍵rklxay、rkux1yの情報が格納されブロック4bへの情報の登録の認証を行うプロキシサーバ2とを備えている。ここで、複数のノード（1a、）と、プロキシサーバ2と、認証局3とはInternet（ネットワーク）10を介して接続されている。
【００９２】
そのため、分散データ管理システムSでは、例えば、複数の機関の医療履歴や個人の生理計測データをブロックチェーン4に安全に蓄積し、プライバシーに応じたプライバシーレベルに従って、二次利用等に利用することができる。
【００９３】
つまり、ブロック4ｂに格納される情報は、複数のプライバシーLに分割され、かつプライバシーレベル Lに応じた異なる第１の鍵（pkl1〜pklm）によって暗号化されている。
また、本分散データ管理システムSにより、医療情報の消失や改竄、漏洩を防いで医療履歴や個人の生理計測データを分散して蓄積できる。
【００９４】
具体的には、ブロック4ｂへの情報の登録に際して用いられる再暗号化鍵rklxay、rkux1yは、第１の鍵（pkl1〜pklm）と登録を行う登録・利用ノード1aがもつ第２の鍵pku1-nのとの間で決められている。加えて、情報の改竄、漏洩を防ぐため、ブロック4ｂへの情報の登録に用いるハッシュ値Hj、Hj+1の情報は、最高のアクセスレベルの第１の鍵（pkl）によって暗号化されている。
【００９５】
また、第１の鍵（pkl1〜pklm）と前記第２の鍵pku1-nとがマトリクスの形で格納されるので、処理が容易である。
加えて、二次データ解析者に、プライバシーレベルに従って適切なレベルのデータを提供することが可能になる。
【００９６】
具体的には、ブロック4bの情報は、利用者または二次データ解析者がもつアクセスレベルの第４の鍵 （秘密鍵skaz）で復号化される。
そのため、データ解析による医療の発展に寄与できる。
【００９７】
＜変形例＞
図１１に、変形例の分散データ管理システムSAの機能の模式ブロック図を示す。
変形例の分散データ管理システムSAは、実施形態1（図2参照）のブロックチェーン4のブロック4bに格納されるデータを、図11に示すデータサーバ11に格納する構成としたものである。
データサーバ11は、格納するデータの改ざん防止、消失防止の機能を具備しているものが望ましい。
その他の構成は、実施形態1の分散データ管理システムSと同様であるから、同様な構成要素には同一の符号を付して示し、詳細な説明は省略する。
【００９８】
変形例の分散データ管理システムSAは、Internet10 に接続されたノード（1a、1b、1c）、プロキシサーバ2、認証局3、およびデーダサーバ11を備えて構成されている。なお、ネットワークはInternet10 以外のネットワークでもよい。
ノード（1a、1b、1c）に格納されるブロックチェーン24のブロック24bは、プライバシーレベル1〜mに分割されている。そして、ブロック24bには、データの所在を示すポインタｐ1〜ｐmがプライバシーレベル1〜m別の公開鍵pkl1〜pklmで暗号化されて格納されている。
【００９９】
デーダサーバ11には、プライバシーレベル1〜m別のデータd1〜dmがそれぞれポインタp1〜pmが示すプライバシーレベル1〜m別に分割されて格納されている。データd1〜dmは、それぞれプライバシーレベル1〜m別の公開鍵pkl1〜pklmで暗号化されている。
【０１００】
上記構成により、データd1〜dmが登録される際には、データd1〜dmがそれぞれデーダサーバ11にプライバシーレベル1〜m別の公開鍵pkl1〜pklmで暗号化され格納される。そして、登録されるデータd1〜dmのそれぞれの所在を示すポインタp1〜pmが暗号化されてブロックチェーン24のブロック24bにプライバシーレベル1〜m別に分割され格納される。
【０１０１】
一方、登録されたデータd1〜dmを参照する際には、ブロックチェーン24のブロック24bのポインタｐ1〜ｐmを介在して、デーダサーバ11のデータd1〜dmにアクセスされる。
変形例によれば、分散データ管理システムSAの製作の多様化に寄与できる。
【０１０２】
＜実施例＞
本発明の実施例として考えられるものの一つとしては、医療における電子カルテの分散蓄積とその二次利用、健康に関する生理計測データの分散蓄積とその二次利用、あるいは電子カルテと生理計測データを組み合わせた分散蓄積とその二次利用等が考えられる。
【０１０３】
電子カルテの利用は、様々な医療機関で進んでおり、異なる病院やクリニック、薬局等の医療情報を統合することで、重複した検査の削減や、副作用のある薬剤の同時投薬の回避が容易になる。
さらに、IoT技術の進歩と健康に関する関心の高まりから、各個人の日々の生活の中で計測される体重、血圧、体温等々の生理計測データを、ネットワークを介して収集することが可能になっている。さらに、異なる医療機関、薬局等の医療情報と、日々の生理計測データとを組み合わせることで、健康管理や高齢者の介護に適用することが考えられている。
【０１０４】
その際に、それらの電子カルテや生理計測データの二次利用として、それらのデータを統合して解析することが重要となる。本発明は、そのような状況に適しており、活用できる。
【０１０５】
図12に、本発明の実施例1の分散データ管理システムS1の構成を模式図に示す。
例えば、実施例1の分散データ管理システムS1は、インターネット10を介して、高機能ヘルスメータ5、高機能血圧計6、携帯端末7、パソコン8、クラウドストレージサーバ9、データ解析ノード11c、プロキシサーバ12、および認証局13が接続されている。
【０１０６】
分散データ管理システムS1では、インターネット10に接続したデータ収集が可能な高機能ヘルスメータ5や、高機能血圧計6の情報、あるいはスマートフォンのような携帯端末7による歩数情報等を、個人のパソコン8にインターネット10 等を介して集積する。そして、パソコン8から本実施形態のブロックチェーン4に集積した情報を、任意のタイミング（例えば、情報を取得した都度や１日に1回等）で、実施形態で説明したブロックチェーン4に登録する。
【０１０７】
こうして、高機能ヘルスメータ5、高機能血圧計6、携帯端末7の各情報をブロックチェーン4の形で自分のパソコン8やクラウドストレージ9、あるいは病院、データ解析者のコンピュータのデータ解析ノード11c等に格納（保持）する。
その際、上述の実施形態により、本人である患者あるいは医療従事者、医療情報の二次利用データ解析者、分散データ管理システムS1の運用管理者等が適切な範囲の登録されたデータを見ることができる。例えば、患者の氏名、連絡先等は最上位のプライバシーレベルとし、患者本人と医療従事者しか見ることができない。
【０１０８】
一方、例えば、プライバシーレベルの設定により、患者を匿名化したIDや処置履歴、生理計測データは、患者本人、医療従事者、二次利用のためのデータ解析者には見ることができるが、他の患者、運用管理者、第三者からは見ることができないようにする。
【０１０９】
また、運用管理者はブロック４ｂのリンク情報だけは見ることができる、といった公開範囲の調整をプライバシーレベルの設定により行うことができる。
【０１１０】
図１３に、本発明の実施例1の分散データ管理システムS1の機能を模式ブロック図に示す。
プロキシサーバ12は、患者、医療従事者等の利用者u１〜uｎ（u1, …, un）、二次利用データ解析者a１〜a１ｑ（a1, …, aq）、運用管理者等の各人の役割の情報と、利用者u１〜uｎの公開鍵pku1-n（pku1〜pkun）、プライバシーレベルの 公開鍵pkl1-m（ pkl1〜pklm）、 二次利用データ解析者a１〜aｑの公開鍵pka1-q（pka1〜pkaq）と、再暗号化鍵の２つのマトリクスRKul、RKluと、データ参照用の再暗号化鍵のマトリクスRKlaを認証局13から受け取り、記憶媒体に保持する。
【０１１１】
例えば、患者である利用者uxのネットワーク（インターネット10）に接続された高機能血圧計6で測定した血圧値B1や高機能ヘルスメータ5で測定した体重値W1をブロック14bとしてブロックチェーン14に繋げて蓄積する。
【０１１２】
そのために、利用者uxのパソコン8は予めプロキシサーバ12で認証を行った後、利用者uxである患者の公開鍵pkuで血圧値B1や体重値W1を暗号化して、プロキシサーバ12に送る。プロキシサーバ12では、再暗号化鍵のマトリクスRKulの再暗号化鍵を用いて、それぞれの対応するプライバシーレベル（例えば、血圧値B1はプライバシーレベルL2、体重値W1はプライバシーレベルL3など）の各公開鍵（pkl2, pkl3）に再暗号化して利用者uxのパソコン8に戻す。
【０１１３】
利用者uxのパソコン8は、対応するブロックチェーン14の先頭のブロック14bのトップのプライバシーレベルL1の公開鍵pkl1で暗号化されたハッシュ情報（Hj）を取り出し、プロキシサーバ12に送る。プロキシサーバ12は、RKluの再暗号化鍵を用いて利用者uxの公開鍵kuxに再暗号化し、利用者uxのパソコン8に戻す。
【０１１４】
さらに、利用者uxのパソコン8では、利用者uxのパソコン8が持つ秘密鍵skuxで平文に戻し、現在のハッシュ値Hjに基づき新しいハッシュ値Hj+1を計算する。
そして、利用者uxのパソコン8は、新しいハッシュ値Hj+1を公開鍵pkuxで暗号化し、プロキシサーバ12に送る。プロキシサーバ12では、マトリックスRKulの再暗号化鍵を用いて、トップのプライバシーレベルL1の公開鍵pkl1に再暗号化し、暗号化された血圧値B1や体重値W1と一緒にブロック14bとして、ブロックチェーン14に接続する。
【０１１５】
インターネット10等のネットワークに接続された個々の高機能血圧計6や高機能ヘルスメータ5に本実施形態の手法を搭載することで、直接高機能血圧計6や高機能ヘルスメータ5からブロックチェーン14に繋げることも、個人のパソコン8で一回データをまとめて、まとめた形にして、パソコン8でブロックチェーン14に繋げることも可能である。
【０１１６】
医者、看護師、薬剤師といった医療従事者uyが、患者uxの電子カルテの情報をブロックチェーン14に登録する際も、患者uxの秘密鍵skuxの入ったICカード等を用いて、上記と同様の手順で登録することができる。
一方、二次利用データ解析者az、運用管理者は、トップのプライバシーレベルL1に対応する再暗号化鍵を持たないため、ハッシュ情報を取り出すことができず、ブロックチェーン14に登録することはできないが、対応するプライバシーレベルの情報はマトリクスRKlaの再暗号化鍵を用いた再暗号化で得ることができる。
【０１１７】
対応する秘密鍵の保持者のみが復号化できるため、患者ux、医療従事者uy、二次利用データ解析者az、運用管理者以外の秘密鍵を持たない者には秘匿性が保たれる。さらにブロックチェーン技術により消失、改竄からも保護される。
【０１１８】
＜＜実施形態2＞＞
図14に、実施形態2の分散データ管理システムS2の構成の一例の模式図を示す。
分散データ管理システムS2は、パソコン等の端末21、携帯端末22、高機能血圧計23や高機能ヘルスメータ24がインターネット10で接続されている。
【０１１９】
実施形態2では、ソフトウェアの一例として、Hyperledger Fabric（登録商標）を用いるものとして説明する。なお、Hyperledger Fabric（登録商標）とは、2015 年12 月にLinux Fundation によって開始されたオープンソースのブロックチェーンプラットフォームのHyperledgerのプロジェクトの1 つである。
【０１２０】
分散データ管理システムS2は、インターネット10のネットワークを使用している。なお、ネットワークは、インターネット10以外でもよい。
端末21、携帯端末22には、分散データ管理システムS2のソフトウェアがインストールされている。
なお、端末21、携帯端末22がインターネット10で接続されたサーバ（図示せず）に格納される分散データ管理システムS2のソフトウェアにアクセスする構成としてもよい。
【０１２１】
Application26は、Hyperledger Fabric（登録商標）が提供するオープンソースをカスタマイズしたものである。
分散データ管理システムS2は、Hyperledger Fabric（登録商標）におけるComposerの機能であるPlaygroundを使用する。Playgroundは、Hyperledger Fabric（登録商標）が提供する入出力インターフェースのツールである。本構成の場合、クラウド上でファイル作成や動作テストを行えるが他のノード、例えば、端末21、携帯端末22とは共有はしていない。
【０１２２】
医師Aや解析者B、患者は、端末21、携帯端末22を操作して、Cardと称されるIDを入力することで、分散データ管理システムS2にアクセスされる。
端末21や携帯端末22には、実施形態１と同様なブロックチェーン4が格納されている。なお、前記した変形例（図11参照）に示すように、ブロックチェーン24のブロック24bにポインタp1〜pmを格納し、デーダサーバ11にポインタp1〜pmが示すデータd1〜dmを格納する構成としてもよい。
【０１２３】
端末21や携帯端末22の入出データは、Playgroundを介して、Application26とやり取りされる。Application26は、Playgroundおよび鍵生成局25と情報の入出力を行う。
【０１２４】
鍵生成局25はブロックチェーンと別のサーバに保管されており、ユーザの共有台帳（ブロック）には記録されない。鍵生成局25は、信頼できる第三者であり、ユーザのID とともにユーザの秘密鍵，公開鍵および再暗号化鍵が保管されている。
なお、鍵生成局25は、耐改竄性、耐漏洩性等の信頼性が高い機密保護を行えれば、ソフトウェアとして分散データ管理システムS2のソフトウェアに組み込む構成としてもよい。
【０１２５】
図15に、実施形態2の他例の分散データ管理システムS2Aの構成の模式図を示す。
実施形態2の他例の分散データ管理システムS2Aは、Localareaネットワーク上で稼動するシステムである。
分散データ管理システムS2Aは、パソコン等の端末21a、携帯端末22a、高機能血圧計23aや高機能ヘルスメータ24aがHyperledger Fabric（登録商標）のネットワーク20aで接続されている。
【０１２６】
分散データ管理システムS2Aは、Hyperledger Fabric（登録商標）のネットワーク20aを使用し、ファイルをネットワーク20aに展開する。
パソコン等の端末21a、携帯端末22aには、分散データ管理システムS2Aのソフトウェアがインストールされている。なお、端末21a、携帯端末22aがネットワーク20aで接続されたサーバ（図示せず）に格納される分散データ管理システムS2Aのソフトウェアにアクセスする構成としてもよい。
Application26は、Hyperledger Fabric（登録商標）が提供するオープンソースをカスタマイズしたものである。
【０１２７】
分散データ管理システムS2Aは、Hyperledger Fabric（登録商標）におけるComposerの機能であるREST-serverを使用する。REST-serverは、Hyperledger Fabric（登録商標）が提供する入出力インターフェースツールである。本構成の場合、Cardと称されるIDを用いて他のノードの端末21a、携帯端末22aからもアクセスやデータの共有が可能である。
なお、他例の分散データ管理システムS2Aでは、Hyperledger Fabric（登録商標）のPlaygroundやCLIといったコンポーネントも使用できる。
【０１２８】
医師Aや解析者B、患者は、Cardと称されるIDを端末21a、携帯端末22aに入力することで、分散データ管理システムS2Aにアクセスできる。
端末21aや携帯端末22aには、実施形態１と同様なブロックチェーン4（図2参照）が格納されている。なお、前記した変形例（図11参照）に示すように、ブロックチェーン24のブロック24bにポインタp1〜pmを格納し、デーダサーバ11にポインタp1〜pmが示すデータd1〜dmを格納する構成としてもよい。
【０１２９】
端末21aや携帯端末22aの入出力データは、REST-serverを介して、Application26とやり取りされる。Application26は、鍵生成局25と情報の入出力を行う。
【０１３０】
＜データ構造＞
図16に、分散データ管理システムS2、S2Aのデータ構造を示す。
実施形態2のモデルファイルに記述するデータは大きくParticipants とAssets の2 種類に分かれる。Participants にはユーザといったAssets を操作する主体の定義がなされている。Assetsには、例えば医療情報のようなモノの定義がなされている。
【０１３１】
分散データ管理システムS2、S2Aのデータとして、下記がある。
クライアント側のデータとして、分散データ管理システムS2、S2Aにログインするユーザに、ID(25ａ)が付与される。各ID(25ａ)には、秘密鍵25b、公開鍵25c、再暗号化鍵25dが紐つけられている。
【０１３２】
Participantsのデータとして、大きく分けて、人と役割がある。
人のデータとして、上記のID(25ａ)があり、名前25eと役割25fとが紐つけられている。なお、図16の(*) 印が書かれている要素はそのデータにおける識別子である。
役割のデータとして、医師25g、解析者25h、患者25iがある。
【０１３３】
Assetsとして下記のデータが定義される。
暗号化するデータとして、日付け25j、プライバシーレベル25k、タイプ25l、説明25mがある。タイプ25lは、例えば血圧、体重等が挙げられる。説明25mには何が入力されて暗号化されたか記載される。
【０１３４】
再暗号化鍵のデータとして、人のID(25ａ)とID(25ａ)の公開鍵からプライバシーレベル25kのl2の公開鍵への再暗号化鍵25nがある。また、プライバシーレベル25kのl2の公開鍵からID(25ａ)の公開鍵への再暗号化鍵25oがあり、ID(25ａ)からプライバシーレベル25kのl3への再暗号化鍵25pがある。また、プライバシーレベル25kのl3からID(25ａ)への再暗号化鍵25qがある。
【０１３５】
プライバシーレベルのデータとして、プライバシーレベル1のl1(25r)、プライバシーレベル2のl2(25s)、プライバシーレベル3のl3(25t)がある。
図17に、実施形態2の分散データ管理システムS2、S2Aの機能の概要を示す。
分散データ管理システムS2、S2Aの機能は、上述の分散データ管理システムS2、S2Aのソフトウェアにより具現化される。
【０１３６】
＜医師Aの情報d1の登録＞
医師A(25g1)が端末21等で情報d1を入力すると、情報d1は、Application26により数値情報d2に数値化される（図17のステップS401）。続いて、Application26は鍵生成局25から医師A(25g1)の公開鍵pkAを受け取る（ステップS402）。Application26は公開鍵pkAで数値情報d2を暗号化する（ステップS403）。
【０１３７】
続いて、仮想的なサーバであるチェーンコード27が鍵生成局25から医師A(25g1)の公開鍵をプライバシーレベルl2の公開鍵に再暗号化する再暗号化鍵rkA→l2を受け取る（ステップS404）。チェーンコード27は、再暗号化鍵rkA→l2を用いて数値情報d2を再暗号化して再暗号化情報d3を生成する（ステップS405）。
次に、チェーンコード27によりブロックチェーン4のブロック4bが生成され、再暗号化情報d3は、当該ブロック4bにおけるプライバシーレベルl2に登録される（ステップS406）。
【０１３８】
＜医師Bの再暗号化情報d3の参照＞
続いて、医師B(25g2)がブロック4bに格納される再暗号化情報d3を参照する処理を説明する。
まず、医師B(25g2)の端末21等での指示入力に従って、チェーンコード27がブロック4bに格納される再暗号化情報d3をリードする（図17のステップS501）。
【０１３９】
続いて、チェーンコード27は鍵生成局25から、プライバシーレベルl2の公開鍵から医師B(25g2)の公開鍵に再暗号化する再暗号化鍵rkl2→Bを要求して受け取り（ステップS502）、再暗号化情報d3を再暗号化鍵rkl2→Bで再暗号化して再暗号化情報d4を生成する（ステップS503）。
【０１４０】
続いて、Application26は、鍵生成局25から医師B(25g1)の秘密鍵skBを受け取る（ステップS504）。Application26は、医師B(25g1)の秘密鍵skBで再暗号化情報d4を復号化して復号化情報d5を生成し（ステップS505）、医師B(25g2)に出力する（ステップS506）。
【０１４１】
＜解析者Cの再暗号化情報d3の参照＞
続いて、解析者C (25h)がブロック4bに格納される再暗号化情報d3を参照する処理を説明する。
解析者C (25h)の端末21等での指示入力に従って、チェーンコード27がブロック4bに格納される再暗号化情報d3をリードする（図17のステップS601）。
【０１４２】
次に、チェーンコード27は、鍵生成局25に、プライバシーレベルl2の公開鍵から解析者C (25h)の公開鍵に再暗号化する再暗号化鍵rkl2→Cを要求するが、再暗号化鍵rkl2→Cはないため、再暗号化情報d3を再暗号化できない(ステップS602）。そのため、Application26は、鍵生成局25から受け取った解析者C (25h)の秘密鍵skCで再暗号化情報d3は復号化できない(ステップS603）。従って、解析者C (25h)はプライバシーレベル2の再暗号化情報d3を参照できない。
【０１４３】
＜トランザクション＞
次に、分散データ管理システムS2、S2Aのソフトウェアで行われるトランザクションを説明する。
【０１４４】
＜ユーザ登録処理＞
ユーザ登録処理は以下のように行われる。
図18に、ユーザ登録処理のフロー図を示す。
Application26は、登録するユーザの鍵の作成を鍵生成局25に要求する(図18のステップS11)。
【０１４５】
続いて、Application26は、登録するユーザをParticipantのPerson(図16参照)としてブロックチェーン上にユーザ登録を行う(ステップS12)。
続いて、Application26は、鍵生成局25から再暗号化鍵を取得しブロックチェーン上にAssetのReencKeyn(図16参照)として保存する(ステップS13)。なお、ユーザは、ユーザ登録時に鍵生成局25から予め秘密鍵、公開鍵を受け取る。
【０１４６】
＜ユーザ削除処理＞
図19に、ユーザ削除処理のフロー図を示す。
ユーザ削除処理は、分散データ管理システムS2、S2Aの管理者のみが実行可能である。
ユーザ削除処理は以下のように行われる。
【０１４７】
Application26は、図16に示すParticipantのPersonからユーザ情報を削除する(図19のステップS21)。
続いて、鍵生成局25が削除するユーザの鍵の情報を、削除する(ステップS22)。
【０１４８】
＜情報登録処理＞
図20に、情報登録処理のフロー図を示す。
例えば、医療情報の登録処理は以下のように行われる。
ユーザが例えば端末21（図14参照）で情報登録を行うと入力すると、端末21の画面は医療情報の登録フォームに移動する(図20のステップS31)。
続いて、Application26は、図17に示すように、鍵生成局25から公開鍵を取得し登録情報を暗号化する (ステップS32)。
【０１４９】
続いて、チェーンコード27は、暗号化した登録情報を取得し、ユーザの公開鍵からプライバシーレベルの公開鍵に再暗号化する再暗号化鍵で再暗号化する (ステップS33)。
続いて、チェーンコード27は、再暗号化した登録情報をブロックチェーン4に記録する。
【０１５０】
＜復号化処理＞
図21に、復号化処理のフロー図を示す。
ブロックチェーン4のブロック4bに格納される登録情報の復号化処理は以下のように行われる。
【０１５１】
図17に示すように、チェーンコード27は、ブロック4bに格納される登録情報を取得し、プライバシーレベル25kの公開鍵からユーザの公開鍵への再暗号化鍵で再暗号化を施す(図21のステップS41)。
そして、チェーンコード27は、再暗号化したデータをApplication26に送信する(ステップS42)。
【０１５２】
Application26は、鍵生成局25からユーザの秘密鍵を取得し、再暗号化したデータを当該秘密鍵で復号化する(ステップS43)。
以上が、復号化処理である。
【０１５３】
ここで、実施形態2においては、プライバシーレベル１の情報は、登録者が本人の公開鍵で暗号化してブロック4bに登録し、自身の秘密鍵でしか復号化できない構成とすることもできる。なお、実施形態1においても、プライバシーレベル１の情報は、登録者が本人の公開鍵で暗号化してブロック4bに登録し、自身の秘密鍵でしか復号化できない構成としてもよい。
【０１５４】
なお、ハッシュ値の情報は、ユーザのIDで取得できるように制限をかけてもよい。例えば、図16に示す医師25g、患者25iのIDに対してのみ、ハッシュ値を取得できるように構成してもよい。
【０１５５】
上記構成によれば、プロキシサーバをプロキシサーバ機能に代替し、分散データ管理システムS2、S2Aを構築できる。
【０１５６】
＜＜その他の実施例＞＞
1．前記実施例では、分散データ管理システムSを医療情報の蓄積、参照に用いる場合を例示したが、他の分野に用いてもよい。
【０１５７】
2．前記実施形態1、2、変形例、実施例は、本発明の一例を示したものであり、特許請求の範囲に記載した本発明の範囲内で様々な具体的形態、変形形態が可能である。
【符号の説明】
【０１５８】
1a    登録・利用ノード（コンピュータ、ノード）
1b    蓄積ノード（コンピュータ、ノード）
1c、11c  データ解析ノード（コンピュータ、参照ノード、ノード）
2、12  プロキシサーバ
3、13  認証局
4、14  ブロックチェーン
4b    ブロック
10    Internet（ネットワーク）
Hj    現在のハッシュ値（ハッシュ値）
Hj+1  新しいハッシュ値（ハッシュ値）
l1〜lm  プライバシーレベル（アクセスレベル）
pkl1  レベル1の公開鍵（最高のアクセスレベルの第１の鍵）
pkl1〜pklm  プライバシーレベルの公開鍵（第１の鍵）
pku1-n  公開鍵（第２の鍵）
rklxay、rkux1y  再暗号化鍵
RKul、RKlu  マトリクス
S      分散データ管理システム
skaz、skux、skuy  秘密鍵（第４の鍵）
【図１】
2020129760.tif 000003
【図２】
2020129760.tif 000004
【図３】
2020129760.tif 000005
【図４】
2020129760.tif 000006
【図５】
2020129760.tif 000007
【図６】
2020129760.tif 000008
【図７】
2020129760.tif 000009
【図８】
2020129760.tif 000010
【図９】
2020129760.tif 000011
【図１０】
2020129760.tif 000012
【図１１】
2020129760.tif 000013
【図１２】
2020129760.tif 000014
【図１３】
2020129760.tif 000015
【図１４】
2020129760.tif 000016
【図１５】
2020129760.tif 000017
【図１６】
2020129760.tif 000018
【図１７】
2020129760.tif 000019
【図１８】
2020129760.tif 000020
【図１９】
2020129760.tif 000021
【図２０】
2020129760.tif 000022
【図２１】
2020129760.tif 000023