JP7448191B2 - データ管理システム - Google Patents

Description

本発明は、インターネット等のネットワークを介して機密情報、電子為替、付記電文、暗号資産、仮想通貨、電子通貨、有価証券等のデータ（以下、「管理対象データ」という）を、クラウドを構成する複数のサーバで安全に保存し、利用者が使用する情報処理端末からの要求に応じて、当該端末に管理対象データを適宜取得させることを可能にするためのシステム、方法、装置及びプログラムに関する。

具体的には、本発明は、利用者のスマートフォン、コンピュータ等の情報処理端末とインターネット等のネットワークを介して接続されたサーバ（以下、「コロニーサーバ」という）が、利用者の情報処理端末からアップロードされた管理対象データを、先頭から所定のサイズまでのデータを含む部分データと、それ以降のデータを含む本体データとに分割して、コロニーサーバとクローズドネットワークを介して接続されたサーバ（以下、「センターサーバ」という）に部分データを送信し、センターサーバは受信した部分データを暗号化して、ブロックチェーンの１ブロックとして記憶し、部分データのハッシュ値を所定の間隔で更新するとともに、本体データのハッシュ値を部分データのものと同じ値に更新することで、高度なセキュリティを実現しつつ、管理対象データを安全に流通させることを可能にする技術に関する。

例えば、金融商品等の取引は、従来、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきたが、近年、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって直接的な取引に代替する技術として、ブロックチェーンを用いた分散台帳技術がある。

分散台帳技術は、主に、分散台帳システムへの参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させることができる。また、分散台帳技術は、複数のトランザクションをブロックとしてまとめ、数珠つなぎにブロックチェーンと呼ばれる分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすることができる。さらに、分散台帳技術は、参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とする。

以上のような特徴から、ブロックチェーン等の分散台帳技術は、信頼できるデータの管理及び共有や、契約に基づく取引の執行及び管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）等の幅広い分野での応用が検討されている。その１つの応用例として、ビットコイン等の暗号資産の取引には、既にブロックチェーン等の分散台帳技術が実装されている。暗号資産は、仮想通貨とも呼ばれている。

スマートフォン等の情報処理端末を用いて、ネットワーク経由によるオンラインで、利用者が暗号資産（仮想通貨、種々の金融商品等）を売買する電子商取引では、その取引記録をブロックチェーン上に記録することができる。例えば、特開２０１９－１０６６３９号公報（特許文献１）には、上記のような電子商取引をブロックチェーン上で行うことが可能な電子商取引装置等が記載されており、ブロックチェーン上では、当事者間の信頼関係や第三者への信頼が存在しなくても、取引記録の改竄困難性などから、コンテンツの持ち逃げ等を防ぐことができる。

特開２０１９－１０６６３９号公報

上記のように、暗号資産の電子商取引は、ブロックチェーンを用いることで実現することができるが、ブロックチェーンでは、取引の公正性が、当該ブロックチェーンを構成する各ノードによって保証されるため、取引の内容が基本的に公開されるという性質が有るため、悪意のある者がブロックチェーンのシステム的な脆弱性を探すことは可能である。そして、脆弱性が見つかった場合に、その脆弱性を突いて不正アクセス等で意図しない第三者に暗号資産を流出させることは現実に起こり得るため、ブロックチェーンのセキュリティ対策が十分であるとはいえない。

また、ブロックチェーン上に記録される取引の公正性を保証するためには、コンピュータによって、ブロックチェーンにおける複数のブロックの各々が正しい記録であることを検証する検証作業が必要になる。例えば、ビットコインで採用されているプルーフオブワーク（ＰＯＷ）という仕組みでは、ブロックチェーンに新たなブロックを追加するために、ナンス（nonce）と呼ばれる値を総当たり式に変化させて、所定の条件を満たすハッシュ値（例えば、一定回数の「０」の連続から始まるハッシュ値）を算出するのに、コンピュータの膨大な計算が必要となり、その計算ために大量の電力が消費されることになる。

これらの課題を解決するために、本発明では、機密情報、電子為替、付記電文、暗号資産、仮想通貨、電子通貨、有価証券等の管理対象データをクラウド上で安全に保存し、オンラインで適宜利用者に配布するために、端末と、コロニーサーバと、センターサーバとを少なくとも備えるデータ管理システムを提供する。本発明に係るデータ管理システムにおいて、コロニーサーバが端末から受信した管理対象データを先頭から所定のサイズまでのデータを含む部分データを記憶し、センターサーバが所定のサイズ＋１以降のデータを含む本体データを記憶することで、管理対象データを部分データと本体データとに分散させて管理するだけでなく、不正アクセス等によってコロニーサーバから本体データが流出したとしても、そもそも本体データは、管理対象データの一部のデータでしかなく、本体データのみでは無価値なものであり、本体データのみからは、管理対象データを復元することができない。このように、本発明では、たとえコロニーサーバから本体データが不正に流出したとしても、実質的な被害を受けることのない堅牢なセキュリティを実現したデータ管理システム、方法、装置及びプログラム（以下、単に「データ管理システム等」ともという）を提供する。

また、本発明では、センターサーバは受信した部分データを暗号化して、ブロックチェーンの１ブロックとして記憶し、部分データのハッシュ値を所定の間隔で更新するとともに、コロニーサーバにおける本体データのハッシュ値を部分データのハッシュ値と同じ値に更新させることで、不正アクセス等によってコロニーサーバから本体データが流出した場合であっても、当該本体データと対となる部分データを含む暗号化キーを特定しようとしても、暗号化キーのハッシュ値は所定の間隔で更新されるため、不正に流出した本体データに含まれるハッシュ値に一致するハッシュ値を含む暗号化キーは存在しなくなり、不正に流出した本体データから管理対象データを復元することを不可能にするデータ管理システム等を提供する。

さらに、本発明では、センターサーバは、管理対象データの全体ではなく一部のデータである部分データのみをブロックチェーン上に記憶することができるため、比較的小さな記憶領域でブロックチェーンを管理することができ、センターサーバを政府や銀行等の信頼できる機関で運用することで、ブロックチェーンの公正性を保証する計算作業を簡略化もしくは省略することができるデータ管理システム等を提供する。

本発明に係るデータ管理システムの１つの実施形態として、
前記データ管理システムは、
端末と、
前記端末と第１のネットワークを介して接続されたコロニーサーバと、
前記コロニーサーバと第２のネットワークを介して接続されたセンターサーバと
を少なくとも備え、
前記端末は、管理対象データに関する要求を前記コロニーサーバに送信し、
前記コロニーサーバは、前記管理対象データに関する要求に応じて取得又は生成した管理対象データを、先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データを前記センターサーバに送信する分割送信部と、
前記センターサーバからハッシュ値を受け取り、前記本体データに関連付けて前記ハッシュ値を記憶する本体データ管理部と、
前記ハッシュ値を更新するハッシュ更新部と
を含み、
前記センターサーバは、前記部分データを少なくとも含む暗号化したデータである暗号化キーを生成し、前記暗号化キーと共に該暗号化キーを識別するための前記ハッシュ値を記憶する部分データ管理部と、
前記暗号化キーと共に記憶された前記ハッシュ値を前記コロニーサーバに送信するハッシュ通知部と、
前記ハッシュ値を用いて前記暗号化キーを識別して取得する暗号化キー取得部と
を含み、
前記ハッシュ通知部は、前記暗号化キーと共に記憶された前記ハッシュ値を、所定の間隔で、前記本体データに関連付けて記憶された前記ハッシュ値とは一致しない新たなハッシュ値に更新して、前記新たなハッシュ値を前記コロニーサーバに送信し、
前記ハッシュ更新部は、前記新たなハッシュ値を受け取り、前記本体データに関連付けて記憶された前記ハッシュ値を前記新たなハッシュ値に更新し、
前記暗号化キー取得部は、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記コロニーサーバからの前記新たなハッシュ値を含む、管理対象データに関する要求に応じて、前記新たなハッシュ値を用いて前記暗号化キーを識別して取得し、
前記部分データは、前記暗号化キーから復元され、
前記管理対象データは、前記部分データと前記本体データとを結合することで復元されることを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記部分データ管理部は、前記部分データの他に、前記管理対象データのファイル名及び時間の少なくとも一方を含めて、暗号化を行い、
前記暗号化キーは、前記部分データの他に、前記ファイル名及び前記時間の少なくとも一方を含むことを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記管理対象データに関する要求は、前記端末においてアップロードされた、前記管理対象に対応する管理対象データを含むことを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記管理対象データに関する要求は、前記コロニーサーバにおいて前記管理対象に対応する管理対象データを生成させる要求であることを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記所定のサイズは、前記管理対象データの先頭から３０バイト以下であることを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記所定の間隔は、２４時間以下の間隔であることを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記第１のネットワークはインターネットであり、前記第２のネットワークはクローズドネットワークであることを特徴とする。

本発明に係るデータ管理システムの好ましい実施形態として、
前記コロニーサーバの分割送信部は、前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを前記部分データとし、
前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを前記本体データとするように分割することを特徴とする。

本発明に係るデータ管理方法の１つの実施形態として、前記データ管理方法は、
端末と、
前記端末と第１のネットワークを介して接続されたコロニーサーバと、
前記コロニーサーバと第２のネットワークを介して接続されたセンターサーバと
を少なくとも備えたデータ管理システムによって実行されるデータ管理方法において、
前記端末が管理対象データに関する要求を前記コロニーサーバに送信するステップと、
前記コロニーサーバが前記管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データを前記センターサーバに送信するステップと、
前記センターサーバが、前記部分データを少なくとも含む暗号化したデータである暗号化キーを生成するステップと、
前記センターサーバが、前記暗号化キーと共に該暗号化キーを識別するためのハッシュ値を記憶するステップと、
前記センターサーバが、前記ハッシュ値を前記コロニーサーバに送信するステップと、
前記コロニーサーバが、前記本体データに関連付けて前記ハッシュ値を記憶するステップと
を含み、
前記センターサーバは、前記暗号化キーと共に記憶された前記ハッシュ値を、所定の間隔で、前記本体データに関連付けて記憶された前記ハッシュ値とは一致しない新たなハッシュ値に更新して、前記新たなハッシュ値を前記コロニーサーバに送信し、
前記コロニーサーバは、前記本体データに関連付けて記憶された前記ハッシュ値を、前記新たなハッシュ値に更新し、
前記センターサーバは、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記コロニーサーバからの前記新たなハッシュ値を含む、管理対象データに関する要求に応じて、前記新たなハッシュ値を用いて前記暗号化キーを識別して取得し、
前記部分データは、前記暗号化キーから復元され、
前記管理対象データは、前記部分データと前記本体データとを結合することで復元されることを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記センターサーバは、前記暗号化キーを生成するステップにおいて、前記部分データの他に、前記管理対象データのファイル名及び時間の少なくとも一方を含めて、暗号化を行い、
前記暗号化キーは、前記部分データの他に、前記ファイル名及び前記時間の少なくとも一方を含むことを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記管理対象データに関する要求は、前記端末においてアップロードされた、前記管理対象に対応する管理対象データを含むことを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記管理対象データに関する要求は、前記コロニーサーバにおいて前記管理対象に対応する管理対象データを生成させる要求であることを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記所定のサイズは、前記管理対象データの先頭から３０バイト以下であることを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記所定の間隔は、２４時間以下の間隔であることを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記第１のネットワークはインターネットであり、前記第２のネットワークはクローズドネットワークであることを特徴とする。

本発明に係るデータ管理方法の好ましい実施形態として、
前記コロニーサーバが前記管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データを前記センターサーバに送信するステップは、
前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを前記部分データとし、
前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを前記本体データとするように分割することを特徴とする。

本発明に係るコロニーサーバ装置の１つの実施形態として、前記コロニーサーバ装置は、
端末から管理対象データに関する要求を受け取る手段と、
前記管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データをセンターサーバ装置に送信する分割送信手段と、
前記センターサーバ装置から、前記部分データを少なくとも含む暗号化したデータである暗号化キーを識別するためのハッシュ値を受け取り、前記本体データに関連付けて前記ハッシュ値を記憶する本体データ管理手段と
を含み、
前記コロニーサーバ装置は、前記センターサーバ装置から、前記本体データに関連付けて記憶された前記ハッシュ値とは一致しない新たなハッシュ値を、所定の間隔で受信し、
前記コロニーサーバ装置は、前記本体データに関連付けて記憶された前記ハッシュ値を、前記所定の間隔で、前記新たなハッシュ値に更新し、
前記コロニーサーバ装置は、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記センターサーバ装置に前記新たなハッシュ値を用いて前記暗号化キーを識別させるために、前記新たなハッシュ値を含む、管理対象データに関する要求を前記センターサーバ装置に送信し、
前記部分データは、前記暗号化キーから復元され、
前記管理対象データは、前記部分データと前記本体データとを結合することで復元されることを特徴とする。

本発明に係るコロニーサーバ装置の好ましい実施形態として、
前記分割送信手段は、前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを前記部分データとし、
前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを前記本体データとするように分割することを特徴とする。

本発明に係るセンターサーバ装置の１つの実施形態として、前記センターサーバ装置は、
センターサーバ装置であって、
コロニーサーバ装置から、管理対象データの先頭から所定のサイズまでのデータを含む部分データを受け取る手段と、
前記部分データを少なくとも含む暗号化したデータである暗号化キーを生成し、前記暗号化キーと共に該暗号化キーを識別するためのハッシュ値を記憶する部分データ管理手段と、
前記暗号化キーと共に記憶された前記ハッシュ値を前記コロニーサーバ装置に送信するハッシュ通知手段と
を含み、
前記ハッシュ通知手段は、前記暗号化キーと共に記憶された前記ハッシュ値を、所定の間隔で、前記ハッシュ値とは一致しない新たなハッシュ値に更新して、前記新たなハッシュ値を前記コロニーサーバ装置に送信し、
前記センターサーバ装置は、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記コロニーサーバ装置からの前記新たなハッシュ値を含む、管理対象データに関する要求に応じて、前記新たなハッシュ値を用いて前記暗号化キーを識別し、
前記部分データは、前記暗号化キーから復元され、
前記管理対象データは、前記部分データと、前記管理対象データの先頭から前記所定のサイズ＋１以降のデータを含む本体データとを結合することで復元されることを特徴とする。

本発明に係るセンターサーバ装置の好ましい実施形態として、
前記部分データは、前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを含み、
前記本体データは、前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを含むことを特徴とする。

本発明に係るプログラムの１つの実施形態として、前記プログラムは、コンピュータによって実行されることで、前記コンピュータを前記コロニーサーバ装置の各手段として機能されることを特徴とする。

本発明に係るプログラムの１つの実施形態として、前記プログラムは、コンピュータによって実行されることで、前記コンピュータを前記センターサーバ装置の各手段として機能されることを特徴とする。

本発明に係るデータ管理システム、方法、装置及びプログラムは、コロニーサーバが端末から受信した管理対象データを先頭から所定のサイズまでのデータを含む部分データを記憶し、センターサーバが所定のサイズ＋１以降のデータを含む本体データを記憶することで、管理対象データを分散させて管理するだけでなく、不正アクセス等によってコロニーサーバから本体データが流出したとしても、そもそも本体データは、管理対象データの一部のデータでしかなく、本体データのみでは無価値なものであることから、不正アクセスに対して堅牢なセキュリティを実現することができる。

また、本発明に係るデータ管理システム等は、センターサーバの管理下にあるブロックチェーンにおける１ブロックに暗号化キーとして記憶した部分データのハッシュ値を、所定の間隔で更新するとともに、コロニーサーバにおける本体データのハッシュ値を部分データのハッシュ値と同じ値に更新させることで、不正アクセス等によってコロニーサーバから本体データが流出した場合であっても、不正に流出した本体データと対となる部分データを含む暗号化キーのハッシュ値は所定の間隔で更新されるため、当該本体データのハッシュ値に一致するハッシュ値を含む暗号化キーは存在しなくなり、不正に流出した本体データを解析しても、管理対象データを復元するために必要な暗号化キーにたどり着くことは困難となり、管理対象データを復元することは実質的に不可能にすることができる。

さらに、本発明に係るデータ管理システム等は、センターサーバは、管理対象データの全体ではなく一部のデータである部分データのみをブロックチェーン上に記憶することができるため、比較的小さな記憶領域でブロックチェーンを管理することができる。これにより、センターサーバでブロックチェーンに新たなブロックを形成する際等に、ハッシュ値の計算等は比較的小さな情報に基づいて行えることになるから、コンピュータにおける計算量を大幅に減らすことが期待できる。そして、センターサーバを政府や銀行等の信頼できる機関で運用することで、ブロックチェーンの公正性を保証する検証作業を簡略化もしくは省略することができ、コンピュータを用いた膨大な計算及びそれに伴う電力の消費を抑えることができる。

本発明の一実施形態に係るデータ管理システムの構成を示す概略構成図（システム構成図）である。 本発明の一実施形態に係るサーバ及び情報処理端末のハードウェア構成の一例を示す概略構成図（ブロック図）である。 本発明の一実施形態に係るセンターサーバ及びコロニーサーバの概略構成図（ブロック図）である。 センターサーバ及びコロニーサーバのデータ処理の手順の一例を示す図である。 コロニーサーバからセンターサーバへの管理対象データの登録処理の概要を示す図である。 センターサーバで管理されるブロックチェーンの基本的な構成の概要を示す概略図である。 管理対象データをセンターサーバに登録する処理の流れを示すシーケンス図である。 センターサーバから管理対象データを取得する処理の流れを示すシーケンス図である。 管理対象データを同じコロニーサーバに接続された端末間で譲渡する処理の流れを示すシーケンス図である。 管理対象データを異なるコロニーサーバに接続された端末間で譲渡する処理の流れを示すシーケンス図である。 管理対象データを異なるコロニーサーバに接続された端末間で譲渡する処理の流れを示すシーケンス図である。 銀行間の金融商品の取引に本発明に係るデータ管理システムを適用した例を示す図である。 イベント参加者への特典付与に本発明に係るデータ管理システムを適用した例を示す図である。 管理対象データを暗号化キーと本体データとに分割する処理の流れを示すデータ管理システム全体としてのフローチャートである。 センターサーバからアクセス可能なブロックチェーンにおける１ブロックと、コロニーサーバからアクセス可能な本体データとの関係を示す図である。 コロニーサーバにおいて独立して記憶される本体データの概要を示す図である。 センターサーバにおいてブロックチェーンに新たに暗号化キーを含むブロックを接続する処理の流れを示すフローチャートである。 センターサーバの管理下にあるブロックチェーンの構成を示す図である。 センターサーバのデータベースに記憶される各種情報の概要を示す図である。 コロニーサーバのデータベースに記憶される情報の概要を示す図である。 ブロックチェーンにおいて改ざんを検出した際の各ブロックの凍結及び修復の処理の概要を示す図である。 ブロックチェーンを監視して改ざんを検出した際の処理の流れを示すフローチャートである。 ブロックチェーンにおけるブロックを凍結する処理の流れを示すフローチャートである。 ブロックチェーンを修復する処理の流れを示すフローチャートである。

以下に図面を参照して、本発明の一実施形態について説明する。なお、実施の形態を説明するための全ての図において、同じものには原則として同一の符号を付し、その繰り返しの説明は省略する。本発明の個々の実施形態は、独立したものではなく、それぞれ組み合わせて適宜実施することができる。

図１は、本発明の一実施形態に係るデータ管理システムの構成を示すシステム構成図である。データ管理システムは、例示的に、センターサーバ１０と、コロニーサーバ２０と、情報処理端末３０とを含む。情報処理端末３０は、例えば、パーソナルコンピュータ、ノートパソコン、スマートフォン、携帯電話等のインターネットに接続可能な端末である。本発明に係るデータ管理システムは、有価物、機密情報、電子為替、付記電文等の電子的なデータを管理対象とする。ここでは、管理対象となる電子的なデータを管理対象データと呼ぶ。管理対象データは、本発明に係るデータ管理システムにおけるセンターサーバ１０、コロニーサーバ２０、及び情報処理端末３０の各記憶手段に記憶可能であり、必要に応じて送受信可能なデータである。なお、管理対象データは、本発明に係るデータ管理システムにおいて、電子的なデータとして取り扱い可能なデータであればどのような内容のデータでも良い。また、有価物とは、金銭上の価値があるものであり、例えば、暗号資産、仮想通貨、電子通貨、有価証券、機密情報等である。センターサーバ１０とコロニーサーバ２０とは、ネットワークＮ１を介して接続される。ネットワークＮ１は、例えば、専用回線で接続されたイントラネットであり、クローズドネットワークである。コロニーサーバ２０と情報処理端末３０とは、ネットワークＮ２を介して接続される。ネットワークＮ２は、例えば、インターネット等のオープンなネットワークである。ネットワークＮ１及びＮ２は、これに限定されるものではなく、要求されるセキュリティのレベル等に応じて、適宜、クローズドネットワークかオープンネットワークかを選択することができる。

情報処理端末３０は、例えば、インターネット等であるネットワークＮ２を介してコロニーサーバ２０にアクセスすることは可能であるが、センターサーバ１０とはクローズドネットワークであるネットワークＮ１を介して接続されていないため、直接的にアクセスすることはできない。センターサーバ１０にアクセスすることができるのは、ネットワークＮ２を介して接続されたコロニーサーバ２０のみである。図１に示す実施形態では、センターサーバ１０は、１台であるが複数台設けてもよい。

図２は、本発明の一実施形態に係るサーバ及び情報処理端末のハードウェア構成の一例を示すブロック図である。なお、図中では、センターサーバ１０のハードウェアに対応する符号には括弧を付すことなく記載し、コロニーサーバ２０及び情報処理端末３０のハードウェアに対応する符号には括弧を付して記載する。

センターサーバ１０は、例示的に、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等からなるメモリ１２と、バス１３と、入出力インターフェース１４と、入力部１５と、出力部１６と、記憶部１７と、通信部１８と、を備えている。

ＣＰＵ１１は、メモリ１２に記録されているプログラム、又は、記憶部２７からメモリ１２にロードされたプログラムにしたがって各種の処理を実行する。ＣＰＵ１１は、例えば、サーバ装置を本発明のセンターサーバとして機能させるためのプログラムを実行することができる。また、センターサーバの少なくとも一部の機能を、特定用途向け集積回路（ＡＳＩＣ）等でハードウェア的に実装することも可能である。本発明のその他のサーバ、情報処理端末についても同様である。

メモリ１２には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。ＣＰＵ１１及びメモリ１２は、バス１３を介して相互に接続されている。このバス１３には、入出力インターフェース１４も接続されている。入出力インターフェース１４には、入力部１５と、出力部１６と、記憶部１７と、通信部１８と、が接続されている。

入力部１５は、各種ボタン、タッチパネルあるいはマイク等で構成され、センターサーバ１０の管理者等の指示操作に応じて各種情報を入力する。なお、入力部１５は、センターサーバ１０の他の各部を収容する本体とは独立した、キーボードやマウス等の入力装置により実現されてもよい。

出力部１６は、ディスプレイやスピーカ等で構成されており、画像データや音声データを出力する。出力部１６が出力した画像データや音楽データは、ディスプレイやスピーカ等から、画像や音楽としてユーザが認識可能に出力される。

記憶部１７は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の半導体メモリで構成され、各種データを記憶する。

通信部１８は、他の装置との間で行う通信を実現する。例えば、通信部１８は、ネットワークＮ１を介して、コロニーサーバ２０との間で相互に通信を行う。

なお、センターサーバ１０には、不図示であるがドライブを必要に応じて適宜設けられる。ドライブには、例えば、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリ等から構成されるリムーバブルメディアが適宜装着される。リムーバブルメディアには、暗号資産取引を実行するためのプログラムや、テキストデータ、画像データ等の各種データが格納される。ドライブによってリムーバブルメディアから読み出されたプログラムや、画像データ等の各種のデータは、必要に応じて記憶部１７にインストールされる。

次に、コロニーサーバ２０のハードウェアの構成について説明する。コロニーサーバ２０は、図２に示すように、例示的に、ＣＰＵ２１と、メモリ２２と、バス２３と、入出力インターフェース２４と、入力部２５と、出力部２６と、記憶部２７と、通信部２８と、を備えている。これら各部は、上述のセンターサーバ１０が備える、符号のみが異なる同名の各部と同等の機能を有している。従って、重複する説明を省略する。情報処理端末３０についても同様である。なお、情報処理端末３０を、携帯型の装置として構成する場合には、情報処理端末３０が備える各ハードウェアと、ディスプレイやスピーカとを一体の装置として実現するようにしてもよい。

図３を参照してデータ管理システムを構成するセンターサーバ１０及びコロニーサーバ２０の機能的構成について説明する。図３は、本発明の一実施形態に係るセンターサーバ及びコロニーサーバのブロック図である。センターサーバ１０は、センターサーバ側のデータ管理のためのプログラムが実行された場合、ＣＰＵ１１において、部分データ管理部１１１と、ハッシュ通知部１１２と、暗号化キー取得部１１３が機能する。また、記憶部１７の一部の記憶領域には、コロニー情報記憶部１７１と、ユーザ情報記憶部１７２と、暗号化キー記憶部１７３とが設定される。コロニー情報記憶部１７１、ユーザ情報記憶部１７２及び暗号化キー記憶部１７３に記憶される情報の詳細は後述する。

センターサーバ１０の部分データ管理部１１１は、コロニーサーバ２０から送信させる管理対象データの一部のデータである部分データを暗号化し、暗号化した部分データを暗号化キーとして記憶したブロックを生成して、ブロックをブロックチェーンに追加することができる。また、部分データ管理部１１１は、部分データの他に、管理対象データのファイル名及び時間の少なくとも一方を含めて、暗号化を行ってもよく、暗号化キーには、部分データの他に、そのファイル名及び時間の少なくとも一方を含めてもよい。

ハッシュ通知部１１２は、所定の間隔で暗号化キーを記憶したブロックのブロックハッシュ値を、当該ブロックハッシュ値とは異なるハッシュ値に更新して、更新されたブロックハッシュ値を新たなハッシュ値としてコロニーサーバに送信することができる。所定の間隔は、２４時間以下の間隔とすることができ、例えば、１時間、６時間、１２時間、２４時間等を指定することができる。また、所定の間隔は、２４時間を超える時間を指定することもできる。

暗号化キー取得部１１３は、コロニーサーバ２０からの要求（管理対象データに関する要求）に含まれるハッシュ値に基づいて、暗号化キー記憶部１７３に記憶された暗号化キーを識別して、当該暗号化キーを取得することができる。例えば、暗号化キー取得部１１３は、所定の間隔で、暗号化キーと共に暗号化キー記憶部１７３に記憶されたハッシュ値が更新された場合には、コロニーサーバ２０からの新たなハッシュ値を含む、管理対象データに関する要求に応じて、当該新たなハッシュ値を用いて暗号化キー記憶部１７３から所望の暗号化キーを識別し、当該暗号化キーを取得することができる。

コロニーサーバ２０は、コロニーサーバ側のデータ管理のためのプログラムが実行された場合、ＣＰＵ２１において、分割送信部２１１と、本体データ管理部２１２と、ハッシュ更新部２１３とが機能する。また、記憶部２７の一部の記憶領域には、ハッシュ情報記憶部２７１と、本体データ記憶部２７２とが設定される。ハッシュ情報記憶部２７１及び本体データ記憶部２７２に記憶される情報の詳細は後述する。

コロニーサーバ２０の分割送信部２１１は、情報処理端末３０からの管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、所定のサイズ＋１以降のデータを含む本体データとに分割して、部分データをセンターサーバ１０に送信することができる。ここで、所定のサイズは、例えば、管理対象データの先頭から３０バイト以下とすることができる。所定のサイズは、これに限定されるものではなく、適宜設定することができる。

また、分割送信部２１１は、管理対象データを先頭から所定のサイズまでのデータに代えて、管理対象データの任意の一部分から所定のサイズのデータを部分データとし、先頭から所定のサイズ＋１以降のデータに代えて、管理対象データの任意の一部分（つまり、部分データ）以外の残余部分のデータを本体データとするように分割することもできる。

本体データ管理部２１２は、センターサーバ１０からブロックハッシュ値を受け取り、本体データに関連付けてブロックハッシュ値を本体データのハッシュ値としてハッシュ情報記憶部２７１に記憶することができる。また、本体データ管理部２１２は、情報処理端末３０からコロニーサーバ２０にアップロードされる管理対象データの本体データを本体データ記憶部２７２に記憶することができる。

ハッシュ更新部２１３は、センターサーバ１０のハッシュ通知部１１２から通知される新たなハッシュ値を受け取り、当該新たなハッシュ値で本体データに関連付けて記憶されたハッシュ値を更新することができる。新たなハッシュ値は、本体データに関連付けて既に記憶されているハッシュ値とは異なるハッシュ値である。

図４は、センターサーバ及びコロニーサーバのデータ処理の手順の一例を示す。はじめに、コロニーサーバ２０において、利用者の情報処理端末３０から管理対象データのアップロード（もしくは、コロニーサーバ２０において管理対象データの生成）を行い（ステップ１）、管理対象データを圧縮して（ステップ２）、管理対象データに相当する圧縮データの０と１のビット列を、ＭＩＭＥ（Multipurpose Internet Mail Extensions）に基づいて、１６進数のテキストデータに置き換える（ステップ３）。図４に示す一例では、管理対象データを圧縮しているが、これに限定されるものではなく、管理対象データを圧縮しなくてもよい。ＭＩＭＥは、インターネットの電子メールの規格を拡張して、さまざまな形式を扱えるようにした規格である。

次に、コロニーサーバ２０において、例えば、管理対象データに相当する１６進数テキストデータの先頭３０バイトを部分データとして切り取り（カットし）（ステップ４）、３１バイト以降のデータを本体データとしてデータベース（例えば、本体データ記憶部２７２）に登録（記憶）する（ステップ５）。

そして、部分データ（先頭３０バイトのデータ）は、コロニーサーバ２０から管理対象データの登録ファイル名と共に、センターサーバ１０に送信される。センターサーバ１０では、部分データ（先頭３０バイトのデータ）と管理対象データのファイル名を受信して（ステップ６）、それらに基づいて管理対象データの一部である部分データの暗号化を行う（ステップ７）。例えば、部分データを暗号化して暗号化キー（ＤＢＥＤ（Data Binary Encrypted Data）ともいう）を生成する。暗号化キー（ＤＢＥＤ）をブロックチェーン（又はブロックチェーンデータツリー（Block chain data tree））の１ブロックとして追加（登録）して（ステップ８）、ブロックチェーンハッシュ（Block chain hash）を生成、すなわち、ブロックチェーンに追加されたブロックのブロックハッシュ値を計算する（ステップ９）。最後に、センターサーバ１０からコロニーサーバ２０にブロックハッシュ値を送信して、コロニーサーバ２０において、バイナリラージオブジェクト（ＢＬＯＢ）として、バイナリーデータであるブロックハッシュ値をデータベース（例えば、ハッシュ情報記憶部２７１）に登録する（ステップ１０）。

図５は、コロニーサーバからセンターサーバへの管理対象データの登録処理の概要を示す。利用者Ｘ（ユーザＸ）は、情報処理端末３０Ｘを用いて、ネットワークＮ１を介して、コロニーサーバ２０にログインして管理対象データをコロニーサーバ２０にアップロードする。コロニーサーバ２０にアップロードされた管理対象データは、上述のとおり、ＭＩＭＥ（例えばＭＩＭＥ６４）に基づいて、例えば、ABCDEFG2345678等のように文字列化され、管理対象データを示すファイル名と共に次の処理に渡される。コロニーサーバ２０において、文字列化された管理対象データを先頭から所定のサイズまでの部分データ（例えば、ABC）と、所定のサイズ＋１以降の本体データ（例えば、DEFG2345678）とに分割して、部分データはファイル名と共に、ネットワークＮ２を介した暗号化通信により、センターサーバ１０に送信される。図４及び５に示す例では、文字列化された管理対象データの先頭から所定のサイズまでのデータを部分データとし、それ以降のデータを本体データとしているが、これに限定されるものではなく、部分データは、管理対象データを先頭から所定のサイズまでのデータに代えて、管理対象データの任意の一部分から所定のサイズのデータを含み、本体データは、所定のサイズ＋１以降のデータに代えて、管理対象データの任意の一部分以外の残余部分のデータを含むこともできる。

このように、本発明の一実施形態に係るデータ管理システムは、コロニーサーバ２０が情報処理端末３０から受信した管理対象データを先頭から所定のサイズまでのデータを含む部分データを記憶し、センターサーバ１０が所定のサイズ＋１以降のデータを含む本体データを記憶することで、管理対象データを分散させて管理するだけでなく、不正アクセス等によってコロニーサーバ２０から本体データが流出したとしても、そもそも本体データは、管理対象データの一部のデータでしかなく、本体データのみでは無価値なものであることから、不正アクセスに対して堅牢なセキュリティを実現することができる。

また、本発明の一実施形態に係るデータ管理システムは、センターサーバ１０は、管理対象データの全体ではなく一部のデータである部分データのみをブロックチェーン上に記憶することができるため、比較的小さな記憶領域でブロックチェーンを管理することができる。これにより、センターサーバ１０でブロックチェーンに新たなブロックを形成する際等に、ハッシュ値の計算等は比較的小さな情報に基づいて行えることになるから、センターサーバ１０等のコンピュータにおける計算量を大幅に減らすことが期待できる。そして、センターサーバ１０を政府や銀行等の信頼できる機関で運用することで、ブロックチェーンの公正性を保証する検証作業を簡略化もしくは省略することができ、コンピュータを用いた膨大な計算及びそれに伴う電力の消費を抑えることができる。

図６は、センターサーバで管理されるブロックチェーンの基本的な構成の概要を示す。ブロックチェーン１００の１つのブロック１０１Ａは、互いに異なる２つのブロックハッシュ値（Block Chain Hash(1)とBlock Chain Hash (2)、例えば、0xaa708c8c, 0x038b67cf）と、管理対象データの部分データを暗号化した暗号化キー（例えば、ddyymmSUGIURA100）とを含む。一方のブロックハッシュ値（Block Chain Hash (1)）は、前のブロックのブロックハッシュ値と同じハッシュ値であり、ハッシュ値が同じであることに基づいてブロック１０１Ａは前のブロックと結合される。同様に、他方のブロックハッシュ値（Block Chain Hash (2)）は、先のブロックハッシュ値と同じハッシュ値であり、ハッシュ値が同じであることに基づいて、ブロック１０１Ａは先のブロックとも結合される。

図７は、管理対象データをセンターサーバに登録する処理の流れを示すシーケンス図である。利用者は情報処理端末３０を用いて、例えばインターネットを介してコロニーサーバ２０にログイン（サインイン）してアクセスし（ステップＳ１０１）、コロニーサーバ２０は、利用者の情報処理端末３０を用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答を情報処理端末３０に送信する（ステップＳ１０２）。そして、利用者は、情報処理端末３０上で、管理対象データのアップロード又は管理対象データの生成リクエストを選択して（ステップＳ１０３）、コロニーサーバ２０に管理対象データをアップロードする、又は管理対象データの生成リクエストを送信する（ステップＳ１０４）。コロニーサーバ２０では、アップロード又は生成された管理対象データを、上述したとおり、圧縮、文字列化等の暗号化処理を行い、例えば、先頭から３０バイトまでの部分データと３１バイト以降の本体データとに分割して、先頭３０バイトの部分データをセンターサーバ１０に送信する（ステップＳ１０６）。

センターサーバ１０において、ブロックチェーンに追加するため１つのブロックを生成し（ステップＳ１０７）、先頭３０バイトの部分データの他に少なくとも管理対象データに関連する時間（例えば、アップロード日時、作成日時等）及び管理対象データに対応するファイル名の少なくとも一方を含めて暗号化を行い、部分データの他にファイル名及び時間（アップロード日時、作成日時等）の少なくとも一方を含む暗号化キーを生成する（ステップＳ１０８）。本実施例では、暗号化の際に、部分データの他に、時間、ファイル名を用いているが、これに限定されるものではなく、その他の文字列、データ等（例えば、利用者のログインＩＤ、パスワード）を用いることもできる。暗号化キーを復号化することで、暗号化キーに含まれる部分データを復元（抽出）することができる。

センターサーバ１０は、生成したブロックに暗号化キーを含めて、ブロックチェーンに当該ブロックを追加し（ステップＳ１０９）、追加されたブロックのブロックハッシュ値をコロニーサーバ２０に送信する（ステップＳ１１０）。コロニーサーバ２０において、受信したブロックハッシュ値を本体データとともにデータベース（本体データ記憶部２７２）に記憶して、部分データが欠落した管理対象データ（すなわち、本体データ）を生成する（ステップＳ１１１）。最後に、コロニーサーバ２０は、管理対象データの生成が完了した場合に、完了通知を情報処理端末３０に送信する（ステップＳ１１２）。

図８は、センターサーバから管理対象データを取得する処理の流れを示すシーケンス図である。利用者は情報処理端末３０を用いて、例えばインターネットを介してコロニーサーバ２０にログイン（サインイン）してアクセスし（ステップＳ２０１）、コロニーサーバ２０は、利用者の情報処理端末３０を用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答を情報処理端末３０に送信する（ステップＳ２０２）とともに、管理対象データ等の目録を送信する（ステップＳ２０３）。

利用者は、情報処理端末３０の画面上に表示される管理対象データ等の目録から、所望の管理対象データの取得のために必要な項目を選択して（ステップＳ２０４）、情報処理端末３０は、利用者が選択した項目とともに、管理対象データの取得のリクエストをコロニーサーバ２０に送信する（ステップＳ２０５）。コロニーサーバ２０において、情報処理端末３０からのリクエストに基づいて、データベースからリクエストされた管理対象データ（に対応する本体データ）を特定して検証を行う（ステップＳ２０６）。検証の結果、問題なければ、管理対象データの３１バイト以降のデータである本体データを情報処理端末３０に送信する（ステップＳ２０７）とともに、本体データに関連付けて記憶されているブロックハッシュ値に基づいて、本体データに対応する部分データをセンターサーバ１０にリクエストする（ステップＳ２０８）。

センターサーバ１０は、リクエストに応じて、ブロックチェーンのブロックを検証し（ステップＳ２０９）、暗号化キーから管理対象データの先頭から３０バイトのデータである部分データを復元（復号）して、コロニーサーバ２０に送信する（ステップＳ２１０）。コロニーサーバ２０は受信した部分データを情報処理端末３０に送信し（ステップＳ２１１）、情報処理端末３０において、受信した部分データを本体データに結合して、管理対象データを生成する（ステップＳ２１２）。

図９は、管理対象データを同じコロニーサーバに接続された端末間で譲渡する処理の流れを示すシーケンス図である。同じコロニーサーバ２０に接続された情報処理端末３０Ｘの利用者Ｘから情報処理端末３０Ｙの利用者Ｙに管理対象データを譲渡する場合、利用者Ｘは情報処理端末３０Ｘを用いて、例えばインターネットを介してコロニーサーバ２０にログイン（サインイン）してアクセスし（ステップＳ３０１）、コロニーサーバ２０は、利用者の情報処理端末３０Ｘを用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答を情報処理端末３０Ｘに送信する（ステップＳ３０２）とともに、管理対象データ等の目録を送信する（ステップＳ３０３）。

利用者Ｘは、情報処理端末３０Ｘの画面上に表示される管理対象データ等の目録から、管理対象データの譲渡のために必要な項目を選択して（ステップＳ３０４）、譲渡先である利用者ＹのユーザＩＤを入力する（ステップＳ３０５）とともに、譲渡のリクエストをコロニーサーバ２０に送信する（ステップＳ３０６）。

コロニーサーバ２０は、譲渡先のユーザＩＤを検証し（ステップＳ３０７）、問題なければ、ダウンロードＵＲＬを生成し（ステップＳ３０８）、譲渡先の利用者Ｙのメールアドレスをセンターサーバ１０にリクエストして（ステップＳ３０９）、応答（ＯＫ）とともにメールアドレスを取得する（ステップＳ３１０）。コロニーサーバ２０は、取得したメールアドレス宛（情報処理端末３０Ｙ）にダウンロードＵＲＬを電子メールで通知する（ステップＳ３１１）。

譲渡先の利用者Ｙは、情報処理端末３０Ｙにおいて電子メールを確認し、ダウンロードＵＲＬを用いてコロニーサーバ２０にログインして、管理対象データの本体データである３１バイト以降のデータをダウンロードする（ステップＳ３１２）。コロニーサーバ２０は、本体データがダウンロードされると、当該本体データのブロックハッシュ値をセンターサーバ１０に送信する（ステップＳ３１３）。センターサーバ１０は、受信したハッシュ値に一致するハッシュ値を有するブロックをブロックチェーンから特定し、ブロックに含まれる管理対象データを検証する（ステップＳ３１４）。センターサーバ１０は、検証結果が正しい場合に、管理対象データの先頭３０バイトである部分データをコロニーサーバ２０に送信し（ステップＳ３１５）、コロニーサーバ２０は受信した部分データを情報処理端末３０Ｙに送信する（ステップＳ３１６）。最後に、情報処理端末３０Ｙにおいて、受信した部分データを本体データに結合して、管理対象データを復元（生成）する（ステップＳ３１７）。

図１０及び図１１は、管理対象データを異なるコロニーサーバに接続された端末間で譲渡する処理の流れを示すシーケンス図であり、図１０及び図１１にシーケンス図を合わせて、コロニーサーバ２０Ａ（コロニＡ）に接続された情報処理端末３０Ｘからコロニーサーバ２０Ｂ（コロニＢ）に接続された情報処理端末３０Ｙへの管理対象データを譲渡する処理の流れを示す。

まず、図１０を参照すると、利用者Ｘは情報処理端末３０Ｘを用いて、例えばインターネットを介してコロニーサーバ２０Ａにログイン（サインイン）してアクセスし（ステップＳ４０１）、コロニーサーバ２０は、利用者の情報処理端末３０Ｘを用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答（失敗した場合には、ログイン失敗（ＮＧ）の応答）を情報処理端末３０Ｘに送信する（ステップＳ４０２）とともに、管理対象データ等の目録を送信する（ステップＳ４０３）。

利用者Ｘは、情報処理端末３０Ｘの画面上に表示される管理対象データ等の目録から、管理対象データの譲渡のために必要な項目を選択して（ステップＳ４０４）、譲渡先である利用者ＹのユーザＩＤと、コロニーサーバ２０ＢのＩＤを指定する（ステップＳ４０５）とともに、譲渡のリクエストをコロニーサーバ２０Ａに送信する（ステップＳ４０６）。コロニーサーバ２０Ａは、リクエストされた管理対象データの本体データを特定し、本体データのブロックハッシュ値と譲渡先の利用者ＹのユーザＩＤとを含むリクエストをセンターサーバ１０に送信する（ステップＳ４０７）。

センターサーバ１０は、受信したユーザＩＤ及びブロックハッシュ値を検証し（ステップＳ４０８）、検証の結果正しければ、その旨の応答（ＯＫ）とともに譲渡先の利用者Ｙのメールアドレスをコロニーサーバ２０Ａに送信し（ステップＳ４０９）、コロニーサーバ２０は、管理対象データの譲渡を行うか否かの最終確認を情報処理端末３０Ｘに送信する（ステップＳ４１０）。情報処理端末３０Ｘは、譲渡の実行を承認する旨の応答（ＯＫ）ともに最終的な譲渡のリクエストをコロニーサーバ２０Ａに送信し（ステップＳ４１１）、コロニーサーバ２０Ａは、リクエストをセンターサーバ１０に送信する（ステップＳ４１２）。

センターサーバ１０は管理対象データの先頭３０バイトを含む部分データをコロニーサーバ２０Ｂに送信する（ステップＳ４１３）。ここで、図１１を参照すると、コロニーサーバ２０Ｂは、利用者Ｘからの管理対象データの譲渡がある旨の通知を、譲渡先の利用者Ｙは情報処理端末３０Ｙに通知する（ステップＳ４１４）。利用者Ｙは、情報処理端末３０Ｙの画面上に表示される通知等に応じて、情報処理端末３０Ｙからログインしてコロニーサーバ２０Ｂにアクセスして（ステップＳ４１５）、情報処理端末３０Ｙは、センターサーバ１０から送られてきた管理対象データの先頭３０バイトである部分データを受信する（ステップＳ４１６）。

図１０を再び参照すると、コロニーサーバ２０Ａはリクエストをセンターサーバ１０に送信した直後又は実質的には同時に、管理対象データの３１バイト以降のデータである本体データをダウンロードするためのＵＲＬを生成する（ステップＳ４１７）。図１１を参照すると、ダウンロードＵＲＬを生成した（ステップＳ４１７）後、コロニーサーバ２０Ａは、ダウンロードＵＲＬを電子メールで、情報処理端末３０Ｙに送信し（ステップＳ４１８）、譲渡先の利用者Ｙは、情報処理端末３０Ｙにおいて電子メールを確認し、ダウンロードＵＲＬを用いてコロニーサーバ２０Ａにログインして、管理対象データの本体データである３１バイト以降のデータをダウンロードする（ステップＳ４１９）。最後に、情報処理端末３０Ｙにおいて、受信した部分データを本体データに結合して、管理対象データを復元する（ステップＳ４２０）。

図１２は、銀行間の金融商品の取引に本発明に係るデータ管理システムを適用した例を示す図である。本発明のシステムは、例えば地方銀行Ａから地方銀行Ｂへの送金について、中央銀行（例えば、日本銀行）内の任意の複数の承認者による認証を簡便に行うことができる。複数の承認者で認証を行うことで、なりすましによる送金等を未然に防止することができる。銀行Ａから銀行Ｂへの送金（例えば、管理対象データとして電子通貨の送信）は、図７に示した、管理対象データをセンターサーバに登録する処理、図１０及び図１１に示した、管理対象データを異なるコロニーサーバに接続された端末間で譲渡する処理に基づいて実現することができる。

銀行Ａの担当者（送信者）は、銀行Ａサーバ（コロニーサーバＡ）に接続された端末を用いて、インターネット等の公衆回線を介して、銀行Ａサーバにログインしてアクセスし、銀行Ａサーバは、銀行Ａの担当者の端末を用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答を当該端末に送信する。そして、銀行Ａの担当者は、端末上で、管理対象データの一例である電子通貨のアップロード又は電子通貨の生成リクエストを選択して、銀行Ａサーバに電子通貨をアップロードする、又は電子通貨の生成リクエストを送信する。銀行Ａサーバでは、アップロード又は生成された電子通貨を、圧縮、文字列化等の暗号化処理を行い、例えば、先頭から３０バイトまでの部分データと３１バイト以降の本体データとに分割して、先頭３０バイトの部分データを、専用回線（クローズドネットワーク）を介して中央銀行サーバ（センターサーバ）に送信する（ステップ１）。

中央銀行サーバにおいて、先頭３０バイトの部分データをブロックチェーンに追加するため１つのブロックを生成し、先頭３０バイトの部分データの他に少なくとも管理対象データである電子通貨に関連する時間（例えば、アップロード日時、作成日時等）及び管理対象データである電子通貨に対応するファイル名の少なくとも一方を含めて暗号化を行い、部分データの他にファイル名及び時間（アップロード日時、作成日時等）の少なくとも一方を含む暗号化キーを生成する。中央銀行サーバは、生成したブロックに暗号化キーを含めて、ブロックチェーンに当該ブロックを追加し、追加されたブロックのブロックハッシュ値（図１２中の「＋ｈａｓｈ」）を銀行Ａサーバに送信する（ステップ２）。ブロックハッシュ値は、中央銀行サーバにおいて所定の間隔で更新され、銀行Ａサーバに送信される。

銀行Ａサーバにおいて、受信したブロックハッシュ値を本体データとともにデータベースに記憶して、部分データが欠落した電子通貨（すなわち、本体データ）を生成する。最後に、銀行Ａサーバは、電子通貨の登録（生成）が完了した場合に、完了通知を銀行Ａの担当者の端末に送信する。管理対象データである電子通貨は中央銀行サーバ登録時に、当該サーバ内のブロックチェーンへ永続的に管理登録されるため、送金リクエストは後日などの別タイミングとしても問題ない。

ここで、管理対象データである電子通貨の部分データ（例えば、先頭３０バイト）を含む暗号化キーは、電子通貨の本体データ（例えば、先頭３１バイト以降のデータ）を復元するための情報（以下、「復元情報」ともいう）である。つまり、復元情報（先頭３０バイトを含む暗号化キーに相当）は、所定のバイトのデータ列であるとすると、このデータを任意の人数分に分割して割符として使用することができる。復元情報である部分データを、任意の人数分に分割することを、ここでは割符化と呼ぶ。

割符化のアルゴリズム（処理手順）は、例えば、復元情報から３名分の割符を生成する場合に、まず、２つのランダムな所定のバイトのデータ列を割符として生成する。次に、２つの割符のデータ列を２進化し、最後に、２進化された２つの割符のデータ列の総和の下位１ビットが復元情報となるように、３つ目の割符のデータ列を生成する。例えば、３つの割符（割符１、割符２及び割符３）のデータ列が下記のような場合、各割符のデータ列の第１列目は、１，０，１なので、総和は１０（２進数）となり、下位１ビットは０であり、第２列目は、１，１，１なので、総和は１１となり、下位１ビットは１となる。
割符１ |1|1|1|0|0|0|0|1|0|0|0|0|1|0|1|1|0|1|1|0|0|0|0|1|
割符２ |0|1|0|0|1|0|1|0|1|0|0|0|0|0|0|1|0|1|0|0|1|0|1|1|
割符３ |1|1|0|0|1|0|1|0|1|1|1|0|1|0|0|0|0|1|0|0|1|0|0|1|
以上のような方法で、３つの割符を合わせることで、電子通貨を復元するための下記のような復元情報（暗号化キー）を生成することができる。
復元情報 |0|1|1|0|0|0|0|1|0|1|1|0|0|0|1|0|0|1|1|0|0|0|1|1|
このように、復元情報（暗号化キー）を割符として分割して管理することで、例えば、銀行Ａから銀行Ｂへの送金について、中央銀行内において複数の承認者にそれぞれ割符を持たせ、それらの割符を用いることで、金融取引の認証を簡便に行うことができる。また、複数の承認者になりすまして、違法に金融取引を実行することも事実上不可能である。

銀行Ａサーバに接続された銀行Ａの担当者（送信者）の端末から、銀行Ｂサーバに接続された銀行Ｂの担当者（受信者）の端末に管理対象データの一例である電子通貨を譲渡（送金）する場合、銀行Ａの担当者（送信者）は、端末を用いて、例えばインターネット等の公衆回線を介して銀行Ａサーバにログイン（サインイン）してアクセスし、銀行Ａサーバは、銀行Ａの担当者（送信者）の端末を用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答を当該端末に送信するとともに、電子通貨等の目録を送信する。

銀行Ａの担当者（送信者）は、端末の画面上に表示される電子通貨等の目録から、電子通貨の譲渡のために必要な項目を選択して、送金先である銀行Ｂサーバ（コロニーサーバＢ）のアドレス等の識別情報（ＩＤ）と、担当者（受信者）のユーザＩＤを入力するとともに、送信のリクエストを銀行Ａサーバに送信する。

銀行Ａサーバは、リクエストされた電子通貨の本体データを特定し、本体データのブロックハッシュ値と送金先の銀行Ｂの担当者のユーザＩＤとを含むリクエストを中央銀行サーバに送信する。中央銀行サーバは、受信したユーザＩＤ及びブロックハッシュ値を検証し、検証の結果正しければ、その旨の応答（ＯＫ）とともに送金先の銀行Ｂの担当者のメールアドレスを銀行Ａサーバに送信し、銀行Ａサーバは、電子通貨の送金を行うか否かの最終確認を銀行Ａの担当者の端末に送信する。

銀行Ａの担当者は、送金の実行を承認する場合に、端末から承認する旨の応答を行うとともに最終的な送金のリクエストを銀行Ａサーバに送信し、銀行Ａサーバは、電子通貨の送金先の受信者のユーザＩＤを検証し、問題なければ、ダウンロードＵＲＬを生成し、送金先の銀行Ｂの担当者（受信者）のメールアドレスを中央銀行サーバにリクエストして、応答（ＯＫ）とともにメールアドレスを取得する。銀行Ａサーバは、取得したメールアドレス宛（銀行Ｂの担当者の端末宛）にダウンロードＵＲＬを電子メールで通知する（ステップ３）。また、このとき、中央銀行サーバは電子通貨の先頭３０バイトを含む部分データを銀行Ｂサーバに送信する。銀行Ｂサーバは、銀行Ａの担当者からの電子通貨の送金がある旨の通知を、送金先の銀行Ｂの担当者の端末に通知する。

銀行Ｂの担当者（受信者）は、端末において電子メールを確認し、ダウンロードＵＲＬを用いて、インターネット等の公衆回線を介して銀行Ａサーバにログインして、ダウンロードを要求する（ステップ４）。銀行Ａサーバは、要求に応じて、管理対象データである電子通貨の本体データ（３１バイト以降のデータ）をダウンロード可能にし、銀行Ｂの担当者の端末は本体データをダウンロードすることができる（ステップ５）。

また、銀行Ｂサーバは、銀行Ａの担当者からの電子通貨の送金がある旨の通知を、送金先の担当者の端末に通知する。銀行Ｂの担当者は、端末から銀行Ｂサーバにアクセスし、銀行Ｂサーバは、中央銀行サーバから送られてきた電子通貨の先頭３０バイトである部分データを含む暗号化キー（復元情報）を、専用回線を介して取得する（ステップ６）。銀行Ｂの担当者（受信者）の端末は、インターネット等の公衆回線を介して、暗号化キーをダウンロードすることができる（ステップ７）。そして、銀行Ｂの担当者の端末によって、暗号化キーに含まれる部分データと本体データとを結合することで、電子通貨が復元される。これにより、銀行Ａから銀行Ｂへの送金が完了する。

このように、銀行Ｂの担当者は、メール等の任意の通知を受け、コロニーサーバである銀行Ｂサーバへログインを行い、電子通貨の部分データを含む暗号化キーを取得することで、部分データが欠けている電子通貨を、完全な電子通貨へと復元（復号）を行うことができる。この際、銀行Ｂサーバでは復元処理を行わず、銀行Ｂの担当者の端末のＷｅｂブラウザ上で復元処理のリクエストを受け付け、端末において復元処理を実行することができる。本発明の一実施形態に係るデータ管理システムの本スキームにおいて、コロニーサーバ（銀行Ｂサーバ）上では、テンポラリとしての実体は生成されないため、不正にアクセスされることはない。なお、各サーバ上ではごくわずかのキャッシュが残るため、取引工程に応じて適切なデータ抹消が行われるように構成することもできる。

図１３は、イベント参加者への特典付与に本発明に係るデータ管理システムを適用した例を示す図である。本発明のシステムは、予め決められた場所に行くことで、クーポン、ポイント等の特典が付与されるようなイベントにも、応用することができる。例えば、電車に乗車して予め決められた駅で降車することで、キャラクタのスタンプ等の特典を得ることができるスタンプラリーのようなイベントにも応用することができ、また、電車の車両の混雑度に応じて、乗客を混雑している車両から空いている車両に誘導し、実際に混んでいる車両から空いている車両に移動した乗客に特典を付与する仕組みにも応用することができる。さらに、予め指定されたイベント会場に来場することで特典を付与し、イベント会場において指示された特定場所に行くことで、特典を付与するような仕組みにも本発明のシステムを応用することができる。

例えば、特典に相当する電子データ（以下、「特典データ」という）を受け取る側のスマートフォン等の携帯端末において、マイク等で音を聞き取り、特定の音の周波数に応答して、特典付与のリクエストを携帯端末からコロニーサーバに送信して、特典データの取得を実行することができる。特定の場所を識別できるのであれば、マイク等で音を聞き取る代わりに、携帯端末のＧＰＳ情報でもよい。

また、電車の混雑緩和に応用した例として、乗車中に、電車内に流れる案内音声等の特定の音（音の周波数）に応じて、乗客の携帯端末に特典データを取得させるように、携帯端末に通知して特典データの取得を促すことができる。このような特典付与の仕組みにより、電車において混雑している車両から、空いている車両に乗客を移動させるために、空いている車両の車内で、特典データの取得を可能とする案内音声等の特定の音を流すようにすることで、乗客の移動を促すことができる。

また、イベント会場の特定の場所で、特典データの取得を可能とする案内音声、広告等の特定の音を流すことで、イベント参加者を移動させることもできる。本システムをイベントに応用した場合、図１３を参照して説明すると、イベント運営者（送信者）は、イベント運営サーバＡ（コロニーサーバＡ）に接続された端末を用いて、インターネット等の公衆回線を介して、イベント運営サーバＡにログインしてアクセスし、イベント運営サーバＡは、イベント運営者の端末を用いたログインが成功した場合に、ログイン成功（ＯＫ）の応答を当該端末に送信する。そして、イベント運営者は、端末上で、管理対象データの一例である特典データのアップロード又は特典データの生成リクエストを選択して、イベント運営サーバＡに特典データをアップロードする、又は特典データの生成リクエストを送信する。イベント運営サーバＡでは、アップロード又は生成された特典データを、圧縮、文字列化等の暗号化処理を行い、例えば、先頭から３０バイトまでの部分データと３１バイト以降の本体データとに分割して、先頭３０バイトの部分データを、専用回線（クローズドネットワーク）を介してセンターサーバに送信する（ステップ１）。

センターサーバにおいて、先頭３０バイトの部分データをブロックチェーンに追加するため１つのブロックを生成し、先頭３０バイトの部分データの他に少なくとも管理対象データである特典データに関連する時間（例えば、アップロード日時、作成日時等）及び管理対象データである特典データに対応するファイル名の少なくとも一方を含めて暗号化を行い、部分データの他にファイル名及び時間（アップロード日時、作成日時等）の少なくとも一方を含む暗号化キーを生成する。センターサーバは、生成したブロックに暗号化キーを含めて、ブロックチェーンに当該ブロックを追加し、追加されたブロックのブロックハッシュ値（図１３中の「＋Ｈａｓｈ」）をイベント運営サーバＡに送信する（ステップ２）。ブロックハッシュ値は、センターサーバにおいて所定の間隔で更新され、イベント運営サーバＡに送信される。

イベント運営サーバＡにおいて、受信したブロックハッシュ値を本体データとともにデータベースに記憶して、部分データが欠落した特典データ（すなわち、本体データ）を生成する。最後に、イベント運営サーバＡは、特典データの登録（生成）が完了した場合に、完了通知をイベント運営者の端末に送信する。特典データはセンターサーバ登録時に、当該サーバ内のブロックチェーンへ永続的に管理登録されるため、特典付与のリクエストは後日などの別タイミングとしても問題ない。

イベント運営サーバＡに接続されたイベント運営者の端末から、イベント運営サーバＢ（コロニーサーバＢ）に接続されたイベント参加者（受信者）の端末に特典データを譲渡する（特典を付与する）場合、イベント参加者の携帯端末が、予め決められた場所に移動したことに起因して、すなわち、予め決められた場所に移動したことをトリガーとして、特典付与のために特典データの本体データ及び部分データを含む暗号化キーを、各サーバ（イベント運営サーバＡ及びＢ）に要求することができる（ステップ３からステップ７）。

イベントの一例として、電車に乗って決められた駅に設置されたスタンプを集めるといったスタンプラリーの例を挙げる。イベント参加者が、電車に乗車して予め決められた駅で降車することで、キャラクタの電子的なスタンプやポイント等の特典を得ることができるように、降車駅の位置情報と実質的に一致する位置に、イベント参加者の携帯端末が移動したこと、又は、降車駅で流れる音声案内当の音の特定の周波数を携帯端末のマイク等で集音したことをトリガーとして、特典付与のリクエストを各サーバ（イベント運営サーバＡ及びＢ）に送信することができる。

また、このようなイベントに限らず、同様の方法で、電車の混雑緩和にも応用することができる。例えば、電車において混雑している車両から、混雑していない車両に移動することを乗客に促すために、イベント運営サーバＡ（又はイベント運営サーバＢ）は、特定の車両（混雑していない車両）に移動することで、特典が付与される旨の通知を乗客の携帯端末に通知することができる。混雑していない車両の車内では、特典データの取得を可能とする案内音声等の音の特定の周波数を流し、乗客が混雑していない車両に移動すると、当該特定の周波数をその乗客の携帯端末のマイク等で集音したことをトリガーとして、特典付与のリクエストを各サーバに送信することができる（イベント運営サーバＡ及びＢ）。

イベント参加者への特典付与の流れの各ステップ（ステップ３からステップ７）は、図１３に示されるように、イベント参加者が指定された場所（例えば、イベント会場）に移動して、イベント参加者の携帯端末のＧＰＳ等の位置情報がその場所を示したことをトリガーとして、又は指定された場所でスピーカ等から流れる音を携帯端末のマイク等で集音し、集音した音の特定の周波数をトリガーとして、特典データの本体データを要求する（ステップ３）。イベント運営サーバＡは、特典データの送信先のイベント参加者（受信者）のユーザＩＤを検証し、問題なければ、ダウンロードＵＲＬを生成し、送信先のイベント参加者（受信者）のメールアドレスをセンターサーバにリクエストして、応答（ＯＫ）とともにメールアドレスを取得する。イベント運営サーバＡは、取得したメールアドレス宛（イベント参加者の端末宛）にダウンロードＵＲＬを電子メールで通知する（ステップ４）。また、このとき、センターサーバは特典データの先頭３０バイトを含む部分データをイベント運営サーバＢに送信する。イベント運営サーバＢは、イベント運営者からの特典付与がある旨の通知を、送信先のイベント参加者の携帯端末に通知する。

イベント参加者（受信者）は、携帯端末において電子メールを確認し、ダウンロードＵＲＬを用いて、インターネット等の公衆回線を介してイベント運営サーバＡにログインして、ダウンロードを要求する（ステップ５）。イベント運営サーバＡは、要求に応じて、管理対象データである特典データの本体データ（３１バイト以降のデータ）をダウンロード可能にし、イベント参加者の携帯端末は本体データをダウンロードすることができる（ステップ６）。

また、イベント運営サーバＢは、イベント運営者からの特典付与がある旨の通知を、送信先のイベント参加者の携帯端末に通知する。イベント参加者は、携帯端末からイベント運営サーバＢにアクセスし、イベント運営サーバＢは、センターサーバから送られてきた特典データの先頭３０バイトである部分データを含む暗号化キー（復元情報）を、専用回線を介して取得する（ステップ８）。イベント参加者の携帯端末は、インターネット等の公衆回線を介して、暗号化キーをダウンロードすることができる（ステップ９）。そして、イベント参加者の携帯端末によって、暗号化キーに含まれる部分データと本体データとを結合することで、特典データが復元されることで、イベント参加者に特典付与が行われる。これにより、イベント運営者からイベントへの特典付与が完了する。

このように、イベント参加者は、メール等の任意の通知を受け、コロニーサーバであるイベント運営サーバＢへログインを行い、特典データの部分データを含む暗号化キーを取得することで、部分データが欠けている特典データを、完全な特典データへと復元（復号）を行うことができる。この際、イベント運営サーバＢでは復元処理を行わず、イベント参加者のＷｅｂブラウザ上で復元処理のリクエストを受け付け、携帯端末において復元処理を実行することができる。本発明の一実施形態に係るデータ管理システムの本スキームにおいて、コロニーサーバ（イベント運営サーバＢ）上では、テンポラリとしての実体は生成されないため、不正にアクセスされることはない。なお、各サーバ上ではごくわずかのキャッシュが残るため、取引工程に応じて適切なデータ抹消が行われるように構成することもできる。

図１３に示した１つの実施例では、イベント参加者への特典付与に、図１０及び図１１に示したセンターサーバに接続された２つのコロニーサーバを用いた管理対象データの譲渡（他コロニーの場合）の方法を応用しているが、これに限定されるものではなく、図９に示したセンターサーバに接続された１つのコロニーサーバを用いた管理対象データの譲渡（自コロニーの場合）の方法を応用してもよい。

また、本発明のデータ管理システムは、図１２及び図１３に示した実施例に限定されるものではなく、音楽、映画、書籍等の著作物の電子データの転送にも使用することができ、映画や音楽配信のプラットホームとして応用することができる。

本発明は、図１に示した一実施形態に係るデータ管理システムにおいて、上述したとおり、コロニーサーバ２０と情報処理端末３０との間の通信は、インターネット等のオープンなネットワークが利用される。一方で、携帯電話などの無線局の急速な増加や無線通信の高速化に伴い、周波数の需要が増大しており、携帯電話等の通信量は更に増大となることが予想される。このため、電波の割当てや周波数の再編を行い、周波数のひっ迫状況を緩和し、新たな周波数需要に的確に対応することが求められている。１つの対応策となり得る第５世代移動通信システム（５Ｇ）は、超高速、低遅延、多数接続等がシステム要件とされ、その実現に向けた研究開発が世界各国で進められている。特に、従来の移動通信システムと異なり、IoT の基盤となることが期待されており、膨大な数の端末が基地局に接続されるとともに、多種多様なサービスが提供されることが見込まれている。

このような状況下において、本発明は、第５世代移動通信システム（５Ｇ）に基づいた通信を行う場合に、携帯電話等での電波（周波数）の有効利用に寄与することができる。例えば、図１２及び図１３に示した実施例のように、本発明のデータ管理システムは、管理対象データを部分データと本体データとに分割して、部分データを暗号化した暗号化キーをセンターサーバで管理し、本体データをコロニーサーバで管理する。コロニーサーバと情報処理端末との通信は、５Ｇを利用したインターネット回線を介して行うことができるが、部分データを含む暗号化キーは、そもそも僅かなサイズ（例えば、管理対象データの先頭３０バイト）となので、通信回線をひっぱくするものでなく、通信回線をひっぱくする可能性がある大きなサイズの本体データは、転送先の情報処理端末への送信が急ぎでない場合には、通信回線が空いているときに、自動的に、コロニーサーバから本体データをダウンロードするようにしてもよい。これにより、本発明は電波（周波数）の有効理由に寄与することができる。

図１４は、管理対象データを暗号化キーと本体データとに分割する処理の流れを示すデータ管理システム全体としてのフローチャートである。機密情報、電子為替、付記電文、暗号資産、仮想通貨、電子通貨、有価証券等の電子的なデータを扱う場合に、情報処理端末３０は、当該電子的なデータを管理対象データとしてコロニーサーバ２０にアップロードして（ステップＳ５０１）、コロニーサーバ２０において管理対象データの暗号化を行う（ステップＳ５０２）。例えば、ＡＥＳ暗号化（ＡＥＳ－２５６－ＣＢＣ）を用いることができる。また、管理対象データの暗号化については、図４及び図５に示すように圧縮、ＭＩＭＥを用いた方法でもよく、その他の暗号化方法でもよい。

コロニーサーバ２０は、暗号化した管理対象データを、所定のサイズの部分データと、当該部分データ以外の残りのデータを含む本体データとに分離する（ステップＳ５０３）。例えば、部分データを暗号化した管理対象データの先頭から３０バイトまでのデータとし、本体データを３１バイト以降から最後までのデータとすることができるが、これに限定されるものではない。

センターサーバ１０側では、部分データ（例えば、先頭３０バイトのデータ）を保存するためのブロックチェーンの１ブロックを生成し（ステップＳ５０４）、部分データを含む暗号化キーを生成し（ステップＳ５０５）、生成された現在のブロックハッシュ値をコロニーサーバ２０に通知する（ステップＳ５０６）。コロニーサーバ２０側では、データベース（ハッシュ情報記憶部２７１）にハッシュ値を格納する（ステップＳ５０７）。データ管理システムで生成される部分データを含むブロックチェーン及び本体データの詳細は、図１５から図１６に示す。

図１５は、センターサーバからアクセス可能なブロックチェーンにおける１ブロックと、コロニーサーバからアクセス可能な本体データとの関係を示す。また、図１６は、コロニーサーバにおいて独立して記憶される本体データの概要を示す。ブロックチェーン１００の概要は、図６に示したが、図１５においてより具体的に示すと、センターサーバ１０のデータベース（暗号化キー記憶部１７３）に記憶されるブロックチェーン１００の１つのブロック１０１Ａには、例えば、少なくとも前のブロックのハッシュ値１０２Ａと、現在のブロックのハッシュ値１０４Ａと、暗号化キー１０５Ａとを含む。ハッシュ値１０２Ａ及び１０４Ａは、例えば６４バイトのデータとすることができる。現在のブロックのハッシュ値１０４Ａは、センターサーバ１０によって、所定の間隔で新たなハッシュ値に更新される。暗号化キー１０５は、更新されることなく固定されたデータである。暗号化キー１０５は、例えば、管理対象データのファイル名と、取引又はファイル作成等の日時と、先頭から３０バイトのデータとを含み、それらを暗号化したデータである。なお、ブロック１０１Ａには、ブロック１０１Ａを識別するための情報として４バイトのファイルＩＤを含めることができる。

図１５及び図１６を参照すると、コロニーサーバ２０のデータベース（本体データ記憶部２７２）には、データブロック群２００が格納される。データブロック群２００に含まれる複数のデータブロック２０１Ａから２０１Ｄは、ブロックチェーンを構成するものではなく互いに独立して記憶される。

１つのデータブロック２０１Ａには、例えば、少なくとも現在のブロックのハッシュ値２０４Ａと、本体データ２０５Ａとを含む。ハッシュ値２０４Ａは、例えば６４バイトのデータとすることができる。本体データ２０５Ａは、例えば、管理対象データの３１バイト以降のデータであり、必要に応じて、管理対象データのファイル名、利用者のユーザＩＤを適宜含めることができる。なお、データブロック２０１Ａには、データブロック２０１Ａを識別するための情報として４バイトのファイルＩＤを含めることができる。

センターサーバ１０は、現在のブロックのハッシュ値１０４Ａを所定の間隔で更新して、コロニーサーバ２０に通知する。所定の間隔は、２４時間以下で１時間、２時間、３時間、４時間、５時間、６時間の間隔としても良いし、２４時間よりも大きい間隔にしてもよい。コロニーサーバ２０は、センターサーバ１０からの通知を受け取り、ハッシュ値１０４Ａと同じ値に、ハッシュ値２０４Ａに更新することで、あたかも、ブロックチェーンにおいて暗号化キー１０５Ａを含むブロックのハッシュ値１０４Ａと、本体データ２０５Ａを含むハッシュ値２０４Ａとがリンクして更新しているように動作する。このような動作を本発明においては、代謝とも表現する。つまり、ハッシュ値１０４Ａとハッシュ値２０４Ａとが、所定の間隔で更新することを、リンクしながら代謝ともいう。

このように、本発明に係るデータ管理システムは、管理対象データを部分データと本体データとに分けて管理し、センターサーバ１０の管理下にあるブロックチェーン１００における１ブロックに暗号化キーとして記憶した部分データに対応するハッシュ値を、所定の間隔で更新するとともに、コロニーサーバ２０における本体データに対応するハッシュ値を、部分データに対応するハッシュ値と同じ値に更新させること（つまり、リンクしながら代謝させること）で、不正アクセス等によってコロニーサーバ２０から本体データが流出した場合であっても、不正に流出した本体データと対となる部分データを含む暗号化キーのハッシュ値は所定の間隔で更新されるため、当該本体データのハッシュ値に一致するハッシュ値を含む暗号化キーは存在しなくなり、不正に流出した本体データを解析しても、管理対象データを復元するために必要な暗号化キーにたどり着くことは困難となり、管理対象データを復元することは実質的に不可能にすることができる。

本発明の一実施形態に係るデータ管理システムは、機密情報、電子為替、付記電文、暗号資産、仮想通貨、電子通貨、有価証券等の電子データを管理対象データとすることができ、取り扱う電子データの内容には実質的な制限がない。本発明に係るデータ管理システムにおける送信側では、送信するデータは種類及びサイズに可能な限り制限が無く、センターサーバで管理するデータは可能な限り少容量であり、また、送信するデータは本体データ（一部欠落させたデータ）と部分データ（欠落部分）とに分割され、それぞれ別のネットワークを利用して送受信され、インターネット等の公衆回線を介して送受信中のデータは本体データ（部分データを除いた管理対象データ）であり、本体データをハッキングされても、一部欠落させたデータであるから実害はないといった特徴を有する。一方、本発明に係るデータ管理システムにおける受信側では、受信する部分データを含む暗号化キーは可能な限り少容量であり、受信予定の本体データを事前にダウンロードすることができ、本体データとは別のネットワークを介して受信した暗号化キーを用いて本体データから管理対象データを端末で復元することができるため、送受信中の本体データ又は部分データを含む暗号化キーを、別々にハッキングされても実害はないといった特徴を有する。

図１７は、センターサーバにおいてブロックチェーンに新たに暗号化キーを含むブロックを接続する処理の流れを示すフローチャートである。図１７に示すフローチャートは、例えば、図７に示したように、情報処理端末３０からコロニーサーバ２０を介してセンターサーバ１０に管理対象データの１つのである電子通貨データを登録する際の処理の流れに対応する。

コロニーサーバ２０は、情報処理端末３０等から、管理対象データの登録や生成等、管理対象データへのアクセスあると（ステップＳ６０１）、センターサーバ１０にその旨を通知し（ステップＳ６０２）、センターサーバ１０ではブロックチェーン１００のブロックの検証が行われる（ステップＳ６０２）。センターサーバ１０は、ブロックチェーン１００における複数のブロックの各々について有効か無効かを示す有効フラグを各ブロックに関連付けて記憶する。ブロックチェーン１００の現在のブロック（例えば、末尾のブロック）に対応する有効フラグをチェックして（ステップ、Ｓ６０４）、有効でない場合（ステップＳ６０４のＮＯ）には、エラーメッセージ等の通知処理を実行する（ステップＳ６１２）。

ブロックチェーン１００の現在のブロック（末尾のブロック）に対応する有効フラグが有効を示す場合（例えば、ステップＳ６０４のＹＥＳ）には、センターサーバ１０において、ブロックチェーン１００に新たに追加するためのブロックを生成する（ステップＳ６０５）。そして、センターサーバ１０は、ブロックチェーン１００に新たに生成したブロック（新ブロック）を接続するために、新ブロックに管理対象データの部分データ（例えば、先頭から３０バイト）を格納する（ステップＳ６０６）。さらに、センターサーバ１０は、いままで有効フラグが有効であったブロック（旧ブロック）の有効フラグを、無効を示す値に変更して（ステップＳ６０７）、ブロックチェーン１００に新ブロックを追加する（ステップＳ６０８）。具体的には、ブロックチェーン１００において、旧ブロックに新ブロックを接続する。

その後、センターサーバ１０は、管理対象データの部分データ（例えば、先頭３０バイトのデータ）の追加が完了した旨とともに、新ブロックのブロックハッシュ値を、コロニーサーバ２０に通知する（ステップＳ６０９）。コロニーサーバ２０では、管理対象データの本体データ（例えば、３１バイト以降のデータ）に対応するハッシュ値を、センターサーバ１０から通知された新ブロックのハッシュ値に更新する（ステップＳ６１０）。コロニーサーバ２０は、センターサーバ１０への電子通貨の登録が成功したか否かをチェックし（ステップＳ６１０）、成功した場合（ステップＳ６１１のＹＥＳ）には処理を終了し、失敗した場合（ステップＳ６１１のＮＯ）にはエラーメッセージ等の通知処理を実行する（ステップＳ６１２）。

図１８は、センターサーバの管理下にあるブロックチェーンの構成を示す。ブロックチェーン１００における１つのブロック１０１Ａは、基本的には、図１７に示す構成と同様であり、直前のブロックのハッシュ値１０２Ａと、現在のブロックのハッシュ値１０４Ａと、暗号化キー１０５Ａとを含む。その他のブロック１０１Ｂ、１０１Ｃについても同様である。ブロック１０１Ａ、１０１Ｂ及び１０１Ｃの各々には、ナンス１０３Ａ、１０３Ｂ及び１０３Ｃが含まれ、例えば、プルーフオブワークと同様の手法により、次のブロックをつなげるためのハッシュ値の計算に用いることができる。センターサーバ１０が１台の場合には、ブロックチェーンの検証を省略できるため、ナンスを使用する必要がないが、本発明の別の実施形態として、データ管理システムが複数のセンターサーバ１０を備え、ブロックチェーン１００が複数のセンターサーバ１０の管理下にある場合には、各センターサーバ１０において、ブロックチェーンの検証を行い、新たなブロックを追加するために、ナンスを使用することができる。

ブロックチェーン１００において、ブロック１０１Ａとブロック１０１Ｂとは、ハッシュ値１０４Ａとハッシュ値１０２Ｂとが同じ値であることで結合され、ブロック１０１Ｂとブロック１０１Ｃとは、ハッシュ値１０４Ｂとハッシュ値１０２Ｃとが同じ値であることで結合される。

図１９は、センターサーバのデータベースに記憶される各種情報の概要を示す。センターサーバ１０のデータベースとして、例えば、図２に示すように、コロニー情報を記憶するためのコロニー情報記憶部１７１と、ユーザ情報を記憶するためのユーザ情報記憶部１７２と、図１８に示したようなブロックチェーン１００を記憶するための暗号化キー記憶部１７３とを備える。図１９（ａ）に示すコロニー情報は、例えば、コロニー情報記憶部１７１に記憶される。コロニー情報としては、例えば、センターサーバ１０に接続される１以上のコロニーサーバ２０のコロニーサーバＩＤと、コロニーサーバ２０に情報処理端末３０からログインする利用者のユーザＩＤと、コロニーサーバＩＤ及びユーザＩＤが有効（TRUE）であるか、いずれか一方が無効（FALSE）であるかを示す有効フラグとを含む。例えば、センターサーバ１０は、コロニー情報記憶部１７１に記憶されたコロニー情報を参照して、有効フラグに基づいて有効なコロニーサーバＩＤ及びユーザＩＤを特定することができる。

図１９（ｂ）に示すユーザ情報は、例えば、ユーザ情報記憶部１７２に記憶される。ユーザ情報としては、例えば、本発明に係るデータ管理システムの利用者のユーザＩＤと、メールアドレスと、ユーザＩＤ及びメールアドレスが有効（TRUE）であるか、いずれか一方が無効（FALSE）であるかを示す有効フラグとを含む。例えば、センターサーバ１０は、ユーザ情報記憶部１７２に記憶されたユーザ情報を参照して、有効フラグに基づいて有効なユーザＩＤ及びメールアドレスを特定することができる。なお、本実施形態では、コロニー情報記憶部１７１に記憶されるコロニー情報及びユーザ情報記憶部１７２に記憶されるユーザ情報は、暗号化キー記憶部１７３に記憶されるブロックチェーン１００に関連するデータとは独立して、別のデータとして記憶される。

図２０は、コロニーサーバのデータベースに記憶される情報の概要を示す。コロニーサーバ２０のデータベースとして、例えば、図３に示すように、ハッシュ情報を記憶するためのハッシュ情報記憶部２７１と、図１６に示したような本体データのデータブロック群２００を記憶するための本体データ記憶部２７２とを備える。図２０に示すハッシュ情報は、例えば、ハッシュ情報記憶部２７１に記憶される。ハッシュ情報としては、例えば、ユーザＩＤと、本体データを保存するデータブロックのブロックハッシュ（例えば、６４バイトのデータ）と、管理対象データの取引日時（年／月／日／時：分：秒（YYYY/MM/DD/HH:MM:SS））と、少なくともブロックハッシュ値が有効（TRUE）であるか、無効（FALSE）であるかを示す有効フラグとを含む。例えば、コロニーサーバ２０は、ハッシュ情報記憶部２７１に記憶されたハッシュ情報を参照して、有効フラグに基づいて有効なハッシュ値か否かを判断することができる。

センターサーバ１０には、ブロックチェーンの改ざんを監視するための監視ボットと、ブロックチェーンを修復するための修復ボットとを備えることができる。ボットとは、一定のタスクや処理を自動化するためのアプリケーションやプログラムのことである。図２１は、例示的に、複数のブロック３０１Ａから３０１Ｄが連結されたブロックチェーン３００に対する、監視ボット及び修復ボットの処理の概要を示す。つまり、図２１は、ブロックチェーンにおいて改ざんを検出した際の各ブロックの凍結及び修復の処理の概要を示す。図２１にブロックチェーンの一例として示したブロックチェーン３００は、図１８に示したブロックチェーン１００と基本的には同じ構造を有するブロックチェーンである。

監視ボットは、センターサーバ１０の管理下にあるブロックチェーン３００の常時監視を行うことができる。例えば、監視ボットが、ブロックチェーン３００において、ブロック３０１Ｂに改ざん（不正な改変等）を見つけた場合には、センターサーバ１０又は監視ボットは、例えば、ブロック３０１Ｂに対応するフラグを無効にすることでブロック３０１Ｂを無効化するとともに、ブロック３０１Ｂ以降のブロック、つまり、ブロック３０１Ｂに連結されたブロック３０１Ｃ、ブロック３０１Ｃに連結されたブロック３０１Ｄも同様に無効化する。このようにブロックを無効化することを、ここではブロックを凍結するともいう。

不正改ざんが見つかったことに応じて、不正改ざんブロック以降のブロックを凍結した後、修復ボットによって、ブロックチェーン３００の修復処理が実行される。修復ボットは、センターサーバ１０の管理下にあるブロックチェーン３００とは独立して管理された帳簿データベース（図示せず）を参照して、正しい取引記録に基づいて、改ざんされたブロック３０１Ｂ以降のブロックを復元するために、ブロックの修正を行う。例えば、銀行等の金融機関において、センターサーバ１０を運用する場合には、センターサーバ１０とは、完全に独立したサーバの帳簿データベースによって管理対象データの取引記録が格納されている。この帳簿データベースを参照することで、センターサーバ１０の管理下にあるブロックチェーン３００を復元することができる。

図２１に示す修復処理の例では、修復ボットにより、帳簿データベースを参照して修復されたブロック３０２Ｂが生成され、ブロック３０１Ａのハッシュ値を書き換えて、ブロック３０２Ｂのハッシュ値をブロック３０１Ａのハッシュ値と同じにすることで、ブロック３０１Ａに、ブロック３０２Ｂを結合する。同様に、ブロック３０２Ｃは、修復ボットにより、帳簿データベースを参照して修復されたブロックであり、ブロック３０２Ｃのハッシュ値をブロック３０２Ｂのハッシュ値と同じにすることで、ブロック３０２Ｂに、ブロック３０２Ｃを結合する。ブロック３０２Ｄについても同様である。

修正ボットの修正中に、新しい取引があった場合、例えば、ブロック３０２Ｂが修正された後に、新たな取引があると、ブロック３０２Ｂとブロック３０２Ｃとの間に、新たなブロック３０３Ａが挟み込まれる。つまり、ブロック３０２Ｂが修正された後に、新たな取引記録を格納するブロック３０３Ａが生成されて、ブロック３０３Ａのハッシュ値を、修正されたブロック３０２Ｂのハッシュ値と同じにすることで、ブロック３０２Ｂにブロック３０３Ａが連結される。同様に、ブロック３０３Ａにブロック３０２Ｃが連結され、ブロック３０２Ｃにブロック３０２Ｄが連結される。

図２２は、ブロックチェーンを監視して改ざんを検出した際の処理の流れを示すフローチャートである。監視ボットは、例えば、センターサーバ１０に少なくとも一時的に常駐して、ブロックチェーン（例えば、ブロックチェーン１００）を常時監視する処理を実行する（ステップＳ７０１）。監視によってブロックチェーンにおけるブロックに改ざん（不正な改変等）が見つかったか否かをチェックし（ステップＳ７０２）、見つからない場合（ステップＳ７０２のＮＯ）には、監視処理（ステップＳ７０１）を続行する。改ざんが見つかった場合（ステップＳ７０２のＹＥＳ）には、図２１に示したように、監視ボット又はセンターサーバ１０が、不正に改ざんされたブロックを凍結する処理を実行する（ステップＳ７０３）。そして、ブロックチェーンの構成をチェックした（ステップＳ７０４）後、改ざんされたブロック以降に連結されたブロックも同様に凍結処理を実行する（ステップＳ７０５）。

ブロックチェーンの改ざんブロックを凍結した後、センターサーバ１０は、管理者にメールを送信し（ステップＳ７０６）、メール送信が成功したか否かをチェックし（ステップＳ７０７）、失敗した場合（ステップＳ７０７のＮＯ）には、メールの送信を再度実行する（ステップＳ７０６）。メールの送信が成功した場合（ステップＳ７０７のＹＥＳ）には、ブロックチェーンの凍結の影響がおよぶコロニーサーバ２０の各々の管理者にメールを送信する（ステップＳ７０８）。

各コロニーサーバ２０の管理者へのメールの送信が成功したか否かをチェックし（ステップＳ７０９）、成功した場合（ステップＳ７０９のＹＥＳ）には、処理を終了する。メール送信が失敗した場合（ステップＳ７０９のＮＯ）には、センターサーバ１０の管理者にメールを送信してその旨を連絡して（ステップＳ７１０）、メール送信が失敗したコロニーサーバの管理者へのメール送信をリトライする（ステップＳ７０８）。

図２３は、ブロックチェーンにおけるブロックを凍結する処理の流れを示すフローチャートである。図２２に示すフローチャートとは別の実施形態である。利用者が手動でブロックチェーンのブロックに対応するデータを取得するか、又はボットの代謝処理（更新されたハッシュ値を通知する処理）等の際にブロックチェーンのブロックに対応するデータにアクセスする（ステップＳ８０１）。当該データに対応する保存されたファイルのハッシュ値を比較して（ステップＳ８０２）、改ざんされていないか否かをチェックする（ステップＳ８０３）。改ざんされていない場合（ステップＳ８０３のＹＥＳ）には、正常に処理を終了し、改ざんされている場合（ステップＳ８０３のＮＯ）には、センターサーバ１０から利用者（及び管理者）のメールアドレスを取得し（ステップＳ８０４）、利用者及びコロニーサーバ管理者宛にメール送信を行い、メール送信が成功したか否かをチェックする（ステップＳ８０５）。メール送信が成功した場合（ステップＳ８０５のＹＥＳ）には、該当するデータを凍結する（つまり、そのデータが無効であることを示すために、そのデータに関連する有効または無効を示すフラグをオフする）（ステップＳ８０６）。メール送信が失敗した場合（ステップＳ８０５のＮＯ）には、再度メールの送信を行ってメールの送信状況をチェックする（ステップＳ８０５）。

図２４は、ブロックチェーンを修復する処理の流れを示すフローチャートである。ブロックチェーンの凍結処理後に、センターサーバ１０において、コロニーサーバ２０から管理対象データの部分データとともに新たにブロックを追加する指示を受け（ステップＳ９０１）、ブロックチェーンの末尾が凍結状態か否かをチェックする（ステップＳ９０２）。チェーンの末尾が凍結状態にない場合（ステップＳ９０２のＮＯ）には、ステップＳ９０５に進む。ブロックチェーンの末尾が凍結状態にある場合（ステップＳ９０２のＹＥＳ）には、ブロックチェーンを辿り凍結されていないブロックを探す（ステップＳ９０３）。凍結されていないブロックを見つけると、凍結されていないブロックに新たなブロックを連結することで、チェーンを分岐させる（ステップＳ９０４）。そして、コロニーサーバ２０から受け取った部分データを含む暗号化キーを生成して（ステップＳ９０５）、暗号化キーを格納してブロックチェーンの生成を行う（ステップＳ９０６）。最後に、センターサーバ１０は、図７に示す管理対象データの登録の処理と同様に、コロニーサーバ２０に生成したブロックのハッシュ値を通知する（ステップＳ９０７）

本発明に係るデータ管理システム等は、インターネット等のネットワークを介して暗号資産、仮想通貨、電子通貨、有価証券等の管理対象データを、クラウドを構成する複数のサーバで安全に保存し、利用者が使用する情報処理端末からの要求に応じて、当該端末に管理対象データを適宜取得させるような電子商取引などに利用可能である。

１０ ：センターサーバ
１１ ：ＣＰＵ
１２ ：メモリ
１３ ：バス
１４ ：入出力インターフェース
１５ ：入力部
１６ ：出力部
１７ ：記憶部
１８ ：通信部
２０ ：コロニーサーバ
２０Ａ ：コロニーサーバ
２０Ｂ ：コロニーサーバ
２１ ：ＣＰＵ
２２ ：メモリ
２３ ：バス
２４ ：入出力インターフェース
２５ ：入力部
２６ ：出力部
２７ ：記憶部
２８ ：通信部
３０ ：情報処理端末
３０Ｘ ：情報処理端末
３０Ｙ ：情報処理端末
１００ ：ブロックチェーン
１０１Ａ ：ブロック
１０１Ｂ ：ブロック
１０１Ｃ ：ブロック
１０２Ａ ：ハッシュ値
１０２Ｂ ：ハッシュ値
１０２Ｃ ：ハッシュ値
１０３Ａ ：ナンス
１０３Ｂ ：ナンス
１０４Ａ ：ハッシュ値
１０４Ｂ ：ハッシュ値
１０５ ：暗号化キー
１０５Ａ ：暗号化キー
１１１ ：部分データ管理部
１１２ ：ハッシュ通知部
１１３ ：暗号化キー取得部
１７１ ：コロニー情報記憶部
１７２ ：ユーザ情報記憶部
１７３ ：暗号化キー記憶部
２００ ：データブロック群
２０１Ａ ：データブロック
２０４Ａ ：ハッシュ値
２０５Ａ ：本体データ
２１１ ：分割送信部
２１２ ：本体データ管理部
２１３ ：ハッシュ更新部
２７１ ：ハッシュ情報記憶部
２７２ ：本体データ記憶部
３００ ：ブロックチェーン
Ｎ１ ：ネットワーク
Ｎ２ ：ネットワーク
Ｘ ：利用者
Ｙ ：利用者

Claims (22)

1. 端末と、
   前記端末と第１のネットワークを介して接続されたコロニーサーバと、
   前記コロニーサーバと第２のネットワークを介して接続されたセンターサーバと
   を少なくとも備え、
   前記端末は、管理対象データに関する要求を前記コロニーサーバに送信し、
   前記コロニーサーバは、前記管理対象データに関する要求に応じて取得又は生成した管理対象データを、先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データを前記センターサーバに送信する分割送信部と、
   前記センターサーバからハッシュ値を受け取り、前記本体データに関連付けて前記ハッシュ値を記憶する本体データ管理部と、
   前記ハッシュ値を更新するハッシュ更新部と
   を含み、
   前記センターサーバは、前記部分データを少なくとも含む暗号化したデータである暗号化キーを生成し、前記暗号化キーと共に該暗号化キーを識別するための前記ハッシュ値を記憶する部分データ管理部と、
   前記暗号化キーと共に記憶された前記ハッシュ値を前記コロニーサーバに送信するハッシュ通知部と、
   前記ハッシュ値を用いて前記暗号化キーを識別して取得する暗号化キー取得部と
   を含み、
   前記ハッシュ通知部は、前記暗号化キーと共に記憶された前記ハッシュ値を、所定の間隔で、前記本体データに関連付けて記憶された前記ハッシュ値とは一致しない新たなハッシュ値に更新して、前記新たなハッシュ値を前記コロニーサーバに送信し、
   前記ハッシュ更新部は、前記新たなハッシュ値を受け取り、前記本体データに関連付けて記憶された前記ハッシュ値を前記新たなハッシュ値に更新し、
   前記暗号化キー取得部は、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記コロニーサーバからの前記新たなハッシュ値を含む、管理対象データに関する要求に応じて、前記新たなハッシュ値を用いて前記暗号化キーを識別して取得し、
   前記部分データは、前記暗号化キーから復元され、
   前記管理対象データは、前記部分データと前記本体データとを結合することで復元される、
   データ管理システム。
2. 前記部分データ管理部は、前記部分データの他に、前記管理対象データのファイル名及び時間の少なくとも一方を含めて、暗号化を行い、
   前記暗号化キーは、前記部分データの他に、前記ファイル名及び前記時間の少なくとも一方を含む、
   請求項１に記載のデータ管理システム。
3. 前記管理対象データに関する要求は、前記端末においてアップロードされた、前記管理対象に対応する管理対象データを含む、
   請求項１又は２に記載のデータ管理システム。
4. 前記管理対象データに関する要求は、前記コロニーサーバにおいて前記管理対象に対応する管理対象データを生成させる要求である、
   請求項１又は２に記載のデータ管理システム。
5. 前記所定のサイズは、前記管理対象データの先頭から３０バイト以下である、
   請求項１から４のいずれか１項に記載のデータ管理システム。
6. 前記所定の間隔は、２４時間以下の間隔である、
   請求項１から５のいずれか１項に記載のデータ管理システム。
7. 前記第１のネットワークはインターネットであり、前記第２のネットワークはクローズドネットワークである、
   請求項１から６のいずれか１項に記載のデータ管理システム。
8. 前記コロニーサーバの分割送信部は、前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを前記部分データとし、
   前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを前記本体データとするように分割する、
   請求項１から７のいずれか１項に記載のデータ管理システム。
9. 端末と、
   前記端末と第１のネットワークを介して接続されたコロニーサーバと、
   前記コロニーサーバと第２のネットワークを介して接続されたセンターサーバと
   を少なくとも備えたデータ管理システムによって実行されるデータ管理方法において、
   前記端末が管理対象データに関する要求を前記コロニーサーバに送信するステップと、
   前記コロニーサーバが前記管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データを前記センターサーバに送信するステップと、
   前記センターサーバが、前記部分データを少なくとも含む暗号化したデータである暗号化キーを生成するステップと、
   前記センターサーバが、前記暗号化キーと共に該暗号化キーを識別するためのハッシュ値を記憶するステップと、
   前記センターサーバが、前記ハッシュ値を前記コロニーサーバに送信するステップと、
   前記コロニーサーバが、前記本体データに関連付けて前記ハッシュ値を記憶するステップと
   を含み、
   前記センターサーバは、前記暗号化キーと共に記憶された前記ハッシュ値を、所定の間隔で、前記本体データに関連付けて記憶された前記ハッシュ値とは一致しない新たなハッシュ値に更新して、前記新たなハッシュ値を前記コロニーサーバに送信し、
   前記コロニーサーバは、前記本体データに関連付けて記憶された前記ハッシュ値を、前記新たなハッシュ値に更新し、
   前記センターサーバは、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記コロニーサーバからの前記新たなハッシュ値を含む、管理対象データに関する要求に応じて、前記新たなハッシュ値を用いて前記暗号化キーを識別して取得し、
   前記部分データは、前記暗号化キーから復元され、
   前記管理対象データは、前記部分データと前記本体データとを結合することで復元される、
   データ管理方法。
10. 前記センターサーバは、前記暗号化キーを生成するステップにおいて、前記部分データの他に、前記管理対象データのファイル名及び時間の少なくとも一方を含めて、暗号化を行い、
    前記暗号化キーは、前記部分データの他に、前記ファイル名及び前記時間の少なくとも一方を含む、
    請求項９に記載のデータ管理方法。
11. 前記管理対象データに関する要求は、前記端末においてアップロードされた、前記管理対象に対応する管理対象データを含む、
    請求項９又は１０に記載のデータ管理方法。
12. 前記管理対象データに関する要求は、前記コロニーサーバにおいて前記管理対象に対応する管理対象データを生成させる要求である、
    請求項９又は１０に記載のデータ管理方法。
13. 前記所定のサイズは、前記管理対象データの先頭から３０バイト以下である、
    請求項９から１２のいずれか１項に記載のデータ管理方法。
14. 前記所定の間隔は、２４時間以下の間隔である、
    請求項９から１３のいずれか１項に記載のデータ管理方法。
15. 前記第１のネットワークはインターネットであり、前記第２のネットワークはクローズドネットワークである、
    請求項９から１４のいずれか１項に記載のデータ管理方法。
16. 前記コロニーサーバが前記管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データを前記センターサーバに送信するステップは、
    前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを前記部分データとし、
    前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを前記本体データとするように分割する、
    請求項９から１５のいずれか１項に記載のデータ管理方法。
17. コロニーサーバ装置であって、
    端末から管理対象データに関する要求を受け取る手段と、
    前記管理対象データに関する要求に応じて取得又は生成した管理対象データを先頭から所定のサイズまでのデータを含む部分データと、前記所定のサイズ＋１以降のデータを含む本体データとに分割して、前記部分データをセンターサーバ装置に送信する分割送信手段と、
    前記センターサーバ装置から、前記部分データを少なくとも含む暗号化したデータである暗号化キーを識別するためのハッシュ値を受け取り、前記本体データに関連付けて前記ハッシュ値を記憶する本体データ管理手段と
    を含み、
    前記コロニーサーバ装置は、前記センターサーバ装置から、前記本体データに関連付けて記憶された前記ハッシュ値とは一致しない新たなハッシュ値を、所定の間隔で受信し、
    前記コロニーサーバ装置は、前記本体データに関連付けて記憶された前記ハッシュ値を、前記所定の間隔で、前記新たなハッシュ値に更新し、
    前記コロニーサーバ装置は、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記センターサーバ装置に前記新たなハッシュ値を用いて前記暗号化キーを識別させるために、前記新たなハッシュ値を含む、管理対象データに関する取引要求を前記センターサーバ装置に送信し、
    前記部分データは、前記暗号化キーから復元され、
    前記管理対象データは、前記部分データと前記本体データとを結合することで復元される、
    コロニーサーバ装置。
18. 前記分割送信手段は、前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを前記部分データとし、
    前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを前記本体データとするように分割する、
    請求項１７に記載のコロニーサーバ装置。
19. センターサーバ装置であって、
    コロニーサーバ装置から、管理対象データの先頭から所定のサイズまでのデータを含む部分データを受け取る手段と、
    前記部分データを少なくとも含む暗号化したデータである暗号化キーを生成し、前記暗号化キーと共に該暗号化キーを識別するためのハッシュ値を記憶する部分データ管理手段と、
    前記暗号化キーと共に記憶された前記ハッシュ値を前記コロニーサーバ装置に送信するハッシュ通知手段と
    を含み、
    前記ハッシュ通知手段は、前記暗号化キーと共に記憶された前記ハッシュ値を、所定の間隔で、前記ハッシュ値とは一致しない新たなハッシュ値に更新して、前記新たなハッシュ値を前記コロニーサーバ装置に送信し、
    前記センターサーバ装置は、前記暗号化キーと共に記憶された前記ハッシュ値が更新された場合には、前記コロニーサーバ装置からの前記新たなハッシュ値を含む、管理対象データに関する要求に応じて、前記新たなハッシュ値を用いて前記暗号化キーを識別し、
    前記部分データは、前記暗号化キーから復元され、
    前記管理対象データは、前記部分データと、前記管理対象データの先頭から前記所定のサイズ＋１以降のデータを含む本体データとを結合することで復元される、
    センターサーバ装置。
20. 前記部分データは、前記管理対象データを先頭から所定のサイズまでのデータに代えて、前記管理対象データの任意の一部分から所定のサイズのデータを含み、
    前記本体データは、前記所定のサイズ＋１以降のデータに代えて、前記管理対象データの前記任意の一部分以外の残余部分のデータを含む、
    請求項１９に記載のセンターサーバ装置。
21. コンピュータによって実行されることで、前記コンピュータを請求項１７又は１８に記載のコロニーサーバ装置の各手段として機能されるプログラム。
22. コンピュータによって実行されることで、前記コンピュータを請求項１９又は２０に記載のセンターサーバ装置の各手段として機能させるプログラム。

Images