JP2020184675A - 情報管理システム、情報管理方法及び情報管理プログラム - Google Patents

Abstract

【課題】セキュリティ確保とプライバシー保護を両立させた、新規な情報管理システムを提供する。【解決手段】情報管理システムは、第１のノード１及び第２のノード２に格納されるブロックチェーン３を有する。第１のノード１および第２のノード２はそれぞれ、特徴データに基づき認証処理を実行する認証手段１０５、２０４を有する。第１のノード１は、第１の取引署名の生成及びブロックチェーン上の未決定ブロックへの追加を実行する第１の署名手段１０３を有する。第２のノード２は、認証処理の結果及び第１の取引署名に基づき、第２の取引署名の生成及び未決定ブロックへの追加を実行する第２の署名手段２０３を有する。第１のノード１は、第２の取引署名に基づき、未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新手段１０６を有する。【効果】ネットワーク上のトランザクション管理を個人認証に基づきセキュアに実現することができる。【選択図】図３

Description

本発明は、情報管理システム、情報管理方法及び情報管理プログラムに関する。

電子デバイス間のトランザクション管理を含む情報管理は、セキュリティ確保と、プライバシー保護と、が両立されることが好ましい。近年では、顔認証を含む生体認証等に基づくセキュアな情報管理が実現しているが、生体認証のための個人情報の取り扱いに関するプライバシー保護の観点の欠如が問題視されている。

また近年では、情報管理システムにおける改竄耐性を向上するためのソリューションとしてブロックチェーン技術が注目されており、経済価値を有するトークンの送受に限定されないような活用シーンの拡充が起きている。

ブロックチェーン技術の最たる利点の１つは、中央集権サーバに依存しない自由化された情報管理を実現し得る点である。そのため、ブロックチェーン技術の導入は、情報管理における生体認証のプライバシー保護を好適に実現し得る。

特許文献１では、識別子を、認証済み個人身元を有する個人に関連付けるステップと、ブロックチェーン上の認証アドレスを個人に割り当てるステップと、個人に関連付けられた識別子及び生体特徴データを対応する認証アドレスに記録するステップと、を少なくとも含むブロックチェーン上に認証アドレスを構築するための方法について、開示されている。

特許文献１に記載の発明は、ブロックチェーン上の情報管理のために生体特徴データが用いられているに過ぎず、トランザクション管理におけるプライバシー保護のために、ブロックチェーン及び生体認証が有機的に組み合わされているとは言い難い。

特開２０１９−５７２７１号公報

本発明は、上記のような実情に鑑みてなされたものであり、新規な情報管理を実現すること、を解決すべき課題とする。

上記課題を解決するために、本発明は、情報管理システムであって、第１及び第２のノードに格納されるブロックチェーンを有し、第１又は第２のノードは、特徴データに基づき認証処理を実行する認証手段を有し、第１のノードは、第１の取引署名の生成及びブロックチェーン上の未決定ブロックへの追加を実行する第１の署名手段を有し、第２のノードは、認証処理の結果及び第１の取引署名に基づき、第２の取引署名の生成及び未決定ブロックへの追加を実行する第２の署名手段を有し、第１のノードは、第２の取引署名に基づき、未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新手段を有する。本発明によると、ネットワーク上のトランザクション管理を個人認証に基づきセキュアにすることができる。

本発明の好ましい形態では、ブロックチェーンは、オブジェクト指向言語に基づき記述されるユーザ定義スキーマと対応し、ユーザ定義スキーマは、スマートコントラクト執行のためのユーザ定義スクリプトと、スマートコントラクト執行の結果を含むユーザ定義プロファイルと、を含み、ユーザ定義スクリプトのハッシュ値は、第１の取引署名の生成に用いられる。本発明によると、ネットワーク上で展開されるサービスに設計柔軟性を付与することができる。また、本発明によると、スマートコントラクト執行のためのユーザ定義スクリプトにおける悪意ある変更を未然に防ぐことができ得る。

本発明の好ましい形態では、ブロックチェーンは、少なくとも１つの第１のノードのそれぞれに固有なプライベートチェーンである。本発明によると、ネットワーク上に保存される情報に改竄耐性を付与することができる。

本発明の好ましい形態では、ブロックチェーンは、少なくとも第１の取引署名と、最終決定ブロックのハッシュ値と、を含む未決定ブロックを有し、最終決定ブロックは、第１及び第２の取引署名と、ハッシュ値と、を含む。本発明によると、ネットワーク上に保存される情報に改竄耐性を付与することができる。

本発明の好ましい形態では、認証手段は、認証処理に際し第１のノードにより新たに取得された特徴データに基づき、認証処理を実行する。本発明によると、オンサイトネットワーク上でブロックチェーン管理を実現することができる。

本発明の好ましい形態では、認証手段は、認証処理に際し第２のノードにより新たに取得された特徴データに基づき、認証処理を実行する。本発明によると、オンサイトネットワーク上でブロックチェーン管理を実現することができる。

本発明の好ましい形態では、特徴データは、顔データを含む生体データに基づく。本発明によると、ネットワーク上の個人認証をセキュアにすることができる。

本発明の好ましい形態では、第１の署名手段は、チェーン更新手段によるハッシュ化及びブロック生成を転機として、第１の取引署名の生成及び追加を実行する。本発明によると、ネットワーク上のブロックチェーン管理をユーザドリブンにすることができる。

本発明の好ましい形態では、第１のノードは、第１のノードと対応する端末署名及び特徴データを第２のノードに送信する登録手段をさらに有し、第２のノードは、端末署名に基づき特徴データを受け付け、特徴データに基づく特徴署名を第１のノードに送信する登録受付手段をさらに有し、認証手段は、第１のノードが特徴署名を有する場合、認証処理を実行する。本発明によると、ネットワーク上の個人認証をセキュアにすることができる。

本発明の好ましい形態では、第２のノードは、第１の取引署名に基づき第１のノードに取引要求を行う取引要求手段を有し、第１のノードは、認証処理の結果及び取引要求に基づき取引処理を実行する取引実行手段をさらに有する。本発明によると、ネットワーク上のトランザクション管理をセキュアにすることができる。

本発明の好ましい形態では、認証手段は、取引要求手段による取引要求を転機として第１又は第２のノードにより取得された特徴データに基づき、認証処理を実行し、第２の署名手段は、取引実行手段による取引処理の実行を転機として、第２の取引署名の生成及び追加を実行する。本発明によると、ネットワーク上のトランザクション管理をセキュアにすることができる。

本発明の好ましい形態では、第１のノードは、第１のノードと対応するブロックチェーンの少なくとも１つの検索及び指定を実行するチェーン指定手段をさらに有する。本発明によると、オンサイトネットワーク上でブロックチェーン管理を実現することができる。

本発明の好ましい形態では、認証手段、第１の署名手段、第２の署名手段及びチェーン更新手段の少なくとも１つは、近距離無線通信による相互接続が保持されている第１及び第２のノードに基づく。本発明によると、オンサイトネットワーク上でブロックチェーン管理を実現することができる。

本発明の好ましい形態では、ブロックチェーンは、メインチェーン上のブロックに格納されるサイドチェーンである。本発明によると、改竄耐性を有するコンソーシアム又はパブリックネットワークを基盤として、プライベートネットワーク上のトランザクション管理を実現することができる。

本発明の好ましい形態では、メインチェーン上のブロックは、特徴データを含む。本発明によると、改竄耐性を有するコンソーシアム又はパブリックネットワークにおいて、個人認証のための特徴データをセキュアに管理することができる。

上記課題を解決するために、本発明は、情報管理方法であって、第１のノードが有するコンピュータプロセッサに、特徴データに基づき認証処理を実行する認証ステップと、第１の取引署名の生成と、第２のノード及び第１のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名ステップと、第２のノードにより生成された第２の取引署名に基づき、未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新ステップと、を実行させる。

上記課題を解決するために、本発明は、情報管理方法であって、第２のノードが有するコンピュータプロセッサに、特徴データに基づき認証処理を実行する認証ステップと、認証処理の結果及び第１のノードにより生成された第１の取引署名に基づき、第２の取引署名の生成と、第１及び第２のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名ステップと、を実行させる。

上記課題を解決するために、本発明は、情報管理プログラムであって、第１のノードを、特徴データに基づき認証処理を実行する認証手段と、第１の取引署名の生成と、第２のノード及び第１のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名手段と、第２のノードと対応する秘密鍵に基づき生成された第２の取引署名に基づき、未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新手段と、として機能させる。

上記課題を解決するために、本発明は、情報管理プログラムであって、第２のノードを、特徴データに基づき認証処理を実行する認証手段と、第１のノードと対応する秘密鍵に基づき生成された第１の取引署名及び認証処理の結果に基づき、第２の取引署名の生成と、第１及び第２のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名手段と、として機能させる。

本発明によると、ネットワーク上のトランザクション管理を個人認証に基づきセキュアにすることができる。また、本発明によると、個人認証に基づく最終決定（ファイナライズ）が行われるプライベートチェーンを用いるため、不特定多数による合意形成に基づくファイナライズが行われるパブリックチェーンと比較して高速かつ軽量なトランザクション管理を、優れたプライバシー保護と両立しながら、実現することができる、という更なる技術的効果を奏する。

本発明の一実施形態におけるハードウェア構成図である。 本発明の一実施形態におけるブロックチェーンを含むオンサイトネットワークの概要図である。 本発明の一実施形態における機能ブロック図である。 本発明の一実施形態におけるブロックチェーンのデータ構造を示す説明図である。 本発明の一実施形態における第１及び第２のノードを含むオンサイトネットワークの概要図である。 本発明の一実施形態における処理フローチャート図であり、（ａ）：第１又は第２のノードによる認証処理が行われる場合、（ｂ）：第１及び第２のノードによる認証処理が行われる場合である。 本発明の一実施形態における登録ステップを含む処理のシークエンス図である。 本発明の一実施形態におけるチェーン指定ステップ及び取引要求ステップを含む処理のシークエンス図である。 本発明の一実施形態における認証ステップ、取引実行ステップ及び第２の署名ステップを含む処理のシークエンス図である。 本発明の一実施形態における第１の署名ステップを含むチェーン更新ステップを示す処理のシークエンス図である。 本発明の一実施形態と対応する実施例であり、取引実行ステップにて決済が行われる場合の概要図である。 本発明の一実施形態におけるチェーン指定ステップ及び取引要求ステップを含む処理と対応する画面表示例である。 本発明の一実施形態における取引実行ステップ及び認証ステップを含む処理と対応する画面表示例である。 本発明の一実施形態におけるオンサイトネットワークの概要図である。 本発明の一実施形態におけるブロックチェーンの概要図である。

本発明の一実施形態では、情報管理システムの構成、動作などについて説明するが、同様の構成の方法、プログラム、記録媒体なども、同様の作用効果を奏する。例えば、情報管理システムにおける各手段のそれぞれと、情報管理方法における各ステップは同様の機能を発揮する。なお、プログラムは、記録媒体に記憶させてよい。当該記録媒体を用いれば、一例として、コンピュータ装置に当該プログラムをインストールすることができる。ここで、当該プログラムを記憶した記録媒体は、一例として、光ディスクやフラッシュメモリなどの、非一過性の記録媒体である。また、当該プログラムは、ソースコード又はバイナリを含み、適宜、暗号化される。

《実施形態１》
以下、図面を用いて、本発明の実施形態１に係る情報管理システムについて説明する。なお、以下に示す実施形態は本発明の一例であり、本発明を以下の実施形態に限定するものではなく、様々な構成を採用できる。また、本発明の一実施形態に係る情報管理システムの適用先である業態やサービスの種別に、制限はない。

〈ハードウェア構成〉
図１に示す通り、情報管理システムは、第１のノード１と、第２のノード２と、を含む。第１のノード１は、第１の演算装置１１と、第１の主記憶装置１２と、第１の補助記憶装置１３と、第１の入力装置１４と、第１の出力装置１５と、第１の通信装置１６と、第１の検出装置１７と、相互接続のための第１のバスインターフェースと、を含む。第２のノード２は、第２の演算装置２１と、第２の主記憶装置２２と、第２の補助記憶装置２３と、第２の入力装置２４と、第２の出力装置２５と、第２の通信装置２６と、第２の検出装置２７と、相互接続のための第２のバスインターフェースと、を含む。第１のノード１及び第２のノード２は、通信ネットワークＮＷを介して、相互通信できる。情報管理システムが有するハードウェア資源は、少なくとも、プログラムが有する機能を実現するために用いられる。

第１の演算装置１１及び第２の演算装置２１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を一例とするプロセッサコアを備える。

第１の主記憶装置１２及び第２の主記憶装置２２は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を一例とする揮発性デバイスを備える。第１の補助記憶装置１３及び第２の補助記憶装置２３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの不揮発性デバイスを備える。

第１の補助記憶装置１３及び第２の補助記憶装置２３は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と、プログラムと、に係るデータのそれぞれが格納される。第１の補助記憶装置１３及び／又は第２の補助記憶装置２３は、プライマリストレージ及び１以上のセカンダリストレージを備えてよい。第１の補助記憶装置１３及び第２の補助記憶装置２３のそれぞれは、第１のデータベースＤＢ１及び第２のデータベースＤＢ２と対応する。

第１のノード１及び／又は第２のノード２は、当該プロセッサコアやＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などが集約されたＳｏＣ（ＳｙｓｔｅｍーｏｎーＣｈｉｐ）を備えてよい。当該プロセッサコアを含むプロセッサは、プログラマブルデバイスであってよい。当該ＡＳＩＣは、例として、ハードウェアエンコーダ／デコーダなどのＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）やＭＬ（Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ）専用プロセッサを、指す。第１のノード１及び／又は第２のノード２は、揮発性を有するキャッシュ領域及び不揮発性を有するデータ領域を有するメモリデバイスを備えてよい。

第１の入力装置１４及び第２の入力装置２４は、情報管理システムに係るデータの入力処理のために用いられる。第１の入力装置１４及び第２の入力装置２４は、キーボード、タッチパネル及びマイクロフォンの少なくとも１つを含む。このとき、当該入力処理の方式に制限はない。

第１の出力装置１５及び第２の出力装置２５は、情報管理システムの表示処理のために用いられる。第１の出力装置１５及び第２の出力装置２５は、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）を一例とするディスプレイデバイスやプロジェクションデバイスなどの視覚表示装置と、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を一例とする、グラフィックコントローラと、を含む。当該グラフィックコントローラは、ＳｏＣに含まれてよい。第１の出力装置１５及び／又は第２の出力装置２５は、ヘッドマウントディスプレイを一例とする、身体の少なくとも一部に接触する装置であってよい。

第１の通信装置１６及び第２の通信装置２６は、好ましくは、近距離無線通信方式に基づく通信装置である。当該近距離無線通信方式は、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＺｉｇｂｅｅ（登録商標）を一例とする通信方式であり、プライベートネットワークの態様で通信ネットワークＮＷを形成する。このとき、第１の通信装置１６及び第２の通信装置２６のそれぞれは、通信可能距離Ｄ１及びＤ２のそれぞれと対応する。なお、実施形態１における通信ネットワークは、メッシュネットワークの態様で形成されてもよい。当該メッシュネットワークは、第１のノード１及び第２のノード２における通信ネットワークについて、他の第１のノード又は第２のノードを中継ノードとして、実現する。

第１の検出装置１７及び第２の検出装置２７は、後述する特徴データ１００４の決定のための検出データの取得を行う。特徴データ１００４が顔データである場合、第１の検出装置１７及び第２の検出装置２７はイメージセンサである。当該イメージセンサには、ＣＭＯＳイメージセンサや赤外線イメージセンサ等の慣用の装置が採用される。

なお、通信ネットワークＮＷは、光回線やＣＡＴＶ（Ｃｏｍｍｕｎｉｔｙ Ａｎｔｅｎｎａ Ｔｅｌｅｖｉｓｉｏｎ）回線などの有線回線や、外出体通信網、航空通信網、衛星通信網などの無線回線を利用でき、回線に応じて、適宜、パケット交換機を含む。

第１のノード１及び第２のノード２は、ラップトップコンピュータ、スマートフォン及びウェアラブルデバイスなどのデータ端末装置の態様をとる。１以上の第１のノード１のそれぞれは、当該１以上の第１のノード１のそれぞれが協調することで、当該１以上の第１のノード１の何れかに対するプログラムの導入を実現してよい。
なお、本発明の一実施形態における第１のノード１及び／又は第２のノード２は、例として一部のＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）機器のような、入力装置及び／又は出力装置を含まない構成としてもよい。このとき、入力装置及び／又は出力装置により実現される機能は、リモートコントロール等により適宜、代替される。

〈オンサイトネットワーク０〉
図２に示す通り、実施形態１における情報管理システムは、オンサイトネットワーク０の態様で把握することができる。オンサイトネットワーク０は、近距離無線通信に基づく相互通信が保持される（ペアリングされる）第１のノード１及び第２のノード２と、ブロックチェーン３と、を含む。本明細書中におけるオンサイトとは、例としてイベント会場内部等の「その場」を指し、第１のノード１及び第２のノード２を含むプライベートネットワーク自体を指す。

図３に示す通り、オンサイトネットワーク０における第１のノード１及び第２のノード２は、それぞれ、第１のデータベースＤＢ１及び第２のデータベースＤＢ２のそれぞれを有する。さらに、第１のノード１及び第２のノード２には、ブロック群３０及びユーザ定義スキーマ３００１を含むブロックチェーン３が格納される。このとき、ブロックチェーン３に係る情報は、例として、第１のデータベースＤＢ１及び第２のデータベースＤＢ２に分散して保存されていると把握することができる。

〈第１のノード１〉
図３に示す通り、第１のノード１は、第１のデータベースＤＢ１、第１の入力手段１０１、第１の出力手段１０２、第１の署名手段１０３、登録手段１０４、第１の認証手段１０５、チェーン更新手段１０６及び取引実行手段１０７を少なくとも有する。

第１のデータベースＤＢ１は、第１の公開鍵１００１、第１の秘密鍵１００２、端末データ１００３、特徴データ１００４、属性データ１００５、端末署名１００６及び特徴署名２００３を有する。第１の公開鍵１００１は、第１の秘密鍵１００２と対応する。実施形態１における第１のデータベースＤＢ１は、好ましくは、ＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ）の態様をとる。

第１の入力手段１０１は、第１の入力装置１４に基づき、情報管理システムにおける第１のノード１を介した入力を行う。

第１の出力手段１０２は、第１の出力装置１５に基づき、情報管理システムにおける第１のノード１上の画面表示を含む表示処理を実行する。当該画面表示は、少なくとも、取引開始画面Ｗ４、認証画面Ｗ５及び取引完了画面Ｗ６に係る表示処理である。

第１の署名手段１０３は、第１の秘密鍵１００２に基づき第１の取引署名１００７を生成し、後述するブロックチェーン３上の未決定ブロック３３に格納する。また、第１の署名手段１０３は、端末データ１００３及び第１の秘密鍵１００２に基づき、端末署名１００６を生成する。

第１の取引署名１００７は、好ましくは、後述するユーザ定義スキーマ３００１に基づくハッシュ値にさらに基づき生成され、より好ましくは、後述するユーザ定義プロファイルのハッシュ値に基づき生成され、より好ましくは、後述するユーザ定義スクリプトのハッシュ値に基づき生成される。

登録手段１０４は、端末データ１００３、特徴データ１００４、属性データ１００５及び端末署名１００６を第２のノード２へ送信する。実施形態１における端末データ１００３は、例として、第１のノード１と対応する端末識別子である。また、実施形態１における属性データ１００５は、生年月日、性別等を含むユーザの個人情報である。登録手段１０４により第２のノード２へ送信される特徴データ１００４は、ハッシュ値の態様としてもよい。

第１の認証手段１０５は、特徴データ１００４に基づき認証処理を実行する。第１の認証手段１０５は、認証処理に際し第１のノード１により新たに取得された特徴データ１００４と、予め第１のデータベースＤＢ１に格納された特徴データ１００４と、に基づき、認証処理を実行する。

第１の認証手段１０５の一態様は、異なる２つの特徴データ１００４のそれぞれを示すＮ次元ベクトルデータに基づき類似度を決定する。当該類似度が所定の条件を満たす場合、認証処理は成功となる。当該類似度は、例として、当該Ｎ次元ベクトルデータが示すユークリッド距離又はコサイン類似度に基づき、決定される。

特徴データ１００４と対応するＮ次元ベクトルデータの次元数は、好ましくは４０９６以上であり、より好ましくは２０４８以上であり、より好ましくは１０２４以上であり、より好ましくは５１２以上であり、より好ましくは２５６以上であり、より好ましくは１２８以上である。

実施形態１における特徴データ１００４は、第１の検出装置１７により取得された検出データに対する特徴抽出を経て決定される。第１の認証手段１０５の一態様では、ＰＣＡ（主成分分析）モデルによる固有ベクトルの計算処理と、ＣＮＮ（畳み込みニューラルネットワーク）モデル等の深層学習モデルによる学習及び推論処理と、ＳＶＭ（サポートベクターマシン）等の決定木モデルによる学習及び分類処理と、ＨＯＧ（勾配方向ヒストグラム）による抽出処理と、を含む特徴抽出アルゴリズムの何れかが採用される。
上記アルゴリズムに限らず、慣用のアルゴリズムであれば、適宜、採用され得る。

実施形態１における特徴データ１００４は、好ましくは、顔データ、指紋データ、掌形データ、網膜データ、声紋データ、虹彩データ、静脈パターンデータ等を含む生体データに基づき、より好ましくは、顔データである。
第１の検出装置１７及び第２の検出装置２７は、当該生体データの種別に応じて、適宜、そのハードウェア構成は変更され得る。
なお、実施形態１では、異なる２以上の種別の生体データのそれぞれと対応する特徴データ１００４に基づき、第１の認証手段１０５による認証処理が複合的に行われる構成としてもよい。

なお、実施形態１における特徴データ１００４は、筆跡認証や歩容認証等のためのデータに基づいてもよく、個人から発せられる情報パターンであれば、適宜採用し得る。

チェーン更新手段１０６は、ブロックチェーン３上の未決定ブロック３３のハッシュ値を取得し、当該未決定ブロック３３を最終決定ブロック３２とし、さらに、チェーン更新手段１０６は、新たな未決定ブロック３３を生成し、当該新たな未決定ブロック３３に当該ハッシュ値を格納する。このとき、チェーン更新手段１０６は、新たな未決定ブロック３３上に第１の取引署名１００７を格納する。

実施形態１におけるハッシュ値や公開鍵や電子署名の生成のための一方向性変換は、ＲＳＡ方式、ＤＳＡ方式、Ｓｃｈｎｏｒｒ方式等の暗号化方式によって行われる構成が好ましい。当該ハッシュ値生成は、複数回の一方向性変換によって行われる構成としてもよいし、該一方向性変換を行う際に、乱数やメタデータを付加する構成としてもよい。また、上記の一方向性変換に応じて、署名検証等が適宜行われることは勿論である。
なお、本発明の一実施形態における電子署名は、ランポート署名であってよい。

取引実行手段１０７は、後述する取引要求手段２０６による取引要求を転機として、取引処理を実行する。このとき、ユーザ定義スキーマ３００１に含まれるユーザ定義スクリプトに基づき当該取引処理は実行される。また、取引実行手段１０７は、後述する取引用トークンに基づき当該取引処理を実行する。実施形態１における取引処理に係る情報は、ユーザ定義スキーマ３００１の少なくとも一部として扱われる。

〈第２のノード２〉
図３に示す通り、第２のノード２は、第２の入力手段２０１、第２の出力手段２０２、第２の署名手段２０３、第２の認証手段２０４、登録受付手段２０５、取引要求手段２０６及びチェーン指定手段２０７を少なくとも有する。

第２のデータベースＤＢ２は、第２の公開鍵２００１、第２の秘密鍵２００２、端末データ１００３、特徴データ１００４、属性データ１００５、端末署名１００６及び特徴署名２００３を有する。第２の公開鍵２００１は、第２の秘密鍵２００２と対応する。実施形態１における第２のデータベースＤＢ２は、第１のデータベースＤＢ１同様、好ましくはＫＶＳの態様をとる。また、第２のデータベースＤＢ２は、第１のデータベースＤＢ１に格納される各種情報の少なくとも１つのスナップショットデータを有してもよい。

第２の入力手段２０１は、第２の入力装置２４に基づき、情報管理システムにおける第２のノード２を介した入力を行う。

第２の出力手段２０２は、第２の出力装置２５に基づき、情報管理システムにおける第２のノード２上の画面表示を含む表示処理を実行する。当該画面表示は、少なくとも、チェーン指定画面Ｗ１に係る表示処理である。

第２の署名手段２０３は第２の秘密鍵２００２に基づき第２の取引署名２００４を生成し、後述するブロックチェーン３上の未決定ブロック３３に格納する。また、第２の署名手段２０３は、特徴データ１００４及び第２の秘密鍵２００２に基づき、特徴署名２００３を生成する。

第２の取引署名２００４は、好ましくは、ユーザ定義スキーマ３００１に基づくハッシュ値にさらに基づき生成され、より好ましくは、ユーザ定義プロファイルのハッシュ値に基づき生成され、より好ましくは、ユーザ定義スクリプトのハッシュ値に基づき生成される。

第２の認証手段２０４は、特徴データ１００４に基づき認証処理を実行する。第２の認証手段２０４は、認証処理に際し第２のノード２により新たに取得された特徴データ１００４と、予め第２のデータベースＤＢ２に格納された特徴データ１００４と、に基づき、認証処理を実行する。なお、第２の認証手段２０４が有する機能は、特に指定がない限り、第１の認証手段１０５と同一である。

登録受付手段２０５は、登録手段１０４により送信された端末データ１００３、特徴データ１００４、属性データ１００５及び端末署名１００６を受け付け、第２のデータベースＤＢ２に格納する。このとき、第２の署名手段２０３により生成された特徴署名２００３を第１のノード１に送信する。

取引要求手段２０６は、第１のノード１に対し、取引処理と対応する取引要求を行う。このとき、ブロックチェーン３上の未決定ブロック３３内部の第１の取引署名１００７に基づき、当該取引要求は行われるが、詳細は後述する。

チェーン指定手段２０７は、通信ネットワークＮＷ内で相互通信可能な第１のノード１と当該第１のノード１と対応するブロックチェーン３と、を索出する。また、チェーン指定手段２０７は、索出されたブロックチェーン３の少なくとも１つを、画面表示を介した意思入力に基づき指定する。当該画面表示の詳細については、後述する。

本明細書中における第１の認証手段１０５及び第２の認証手段２０４は総じて認証手段と呼称される。また、第１の署名手段１０３及び第２の署名手段２０３は総じて署名手段と呼称される。

〈ブロックチェーン３（オンサイトチェーン）〉
図４に示す通り、実施形態１におけるブロックチェーン３におけるブロック群３０は、初期ブロック３１、最終決定ブロック３２及び未決定ブロック３３を有する。ユーザ定義スキーマ３００１は、ブロック群３０の各ブロックに対応もしくは格納される。なお、本明細書中におけるブロック群３０の各ブロックは、ブロックヘッダーの態様で扱われる。

実施形態１におけるブロックチェーン３は、決済鍵等、取引処理のための取引用トークンを適宜、有する構成が好ましい。なお、実施形態１におけるブロックチェーン３は、オンサイトネットワーク０上で管理されるため、オンサイトチェーンと呼称され得る。

〈ブロック群３０〉
初期ブロック３１は、第１のノード１により生成されたジェネシスブロックを指し、第１の公開鍵１００１、第１の取引署名１００７、第２の取引署名２００４、ユーザ定義スキーマ３００１及びタイムスタンプ３００２を有する。当該タイムスタンプ３００２は、初期ブロック３１の生成タイミングと対応してもよいし、各署名の生成タイミングと対応してもよい。

最終決定ブロック３２は、第１のノード１により最終決定（ファイナライズ）されたブロックを指し、第１の公開鍵１００１、第１の取引署名１００７、第２の取引署名２００４、ユーザ定義スキーマ３００１、タイムスタンプ３００２及びブロックのハッシュ値３００３を有する。タイムスタンプ３００２は、最終決定ブロック３２の生成タイミングと対応してもよいし、各署名の生成タイミングと対応してもよい。なお、ブロックのハッシュ値３００３におけるブロックとは、直前ブロックを指す。

本明細書中の直前ブロックとは、同一のブロックチェーン３上の生成順序における直前のブロックを指す。また、本明細書中の直前ブロックとは、同一のブロックチェーン３上の生成順序における直前のブロックを指す。また、ブロックのハッシュ値３００３は、一方向性関数に基づき直前ブロックをハッシュ化することで得られるハッシュ値である。

未決定ブロック３３は、第１のノード１により最終決定（ファイナライズ）されていないブロックを指し、ブロックのハッシュ値３００３、第１の公開鍵１００１、第１の取引署名１００７及びユーザ定義スキーマ３００１を少なくとも有する。

実施形態１におけるブロックチェーン３は、少なくとも、１の初期ブロック３１及び１の未決定ブロック３３を有すればよく、最終決定ブロック３２を含まない状態をとり得る。また、実施形態１におけるブロックチェーン３は、ブロックのハッシュ値３００３を含まない１の未決定ブロック３３を有する状態をとり得る。また、実施形態１におけるブロックチェーン３は、初期ブロック３１のみを有する状態をとり得る。

図５（ａ）に示す通り、オンサイトネットワーク０は固有な第１のノード１と、第２のノード２と、を含む。このとき、第１のノード１Ａ及び第１のノード１Ｂのそれぞれは、ブロックチェーン３Ａ及びブロックチェーン３Ｂのそれぞれと対応する。なお、オンサイトネットワーク０におけるブロックチェーン３の数に、特に制限はない。
なお、本明細書中の説明における固有な第１のノードとは、オンサイトネットワーク０に対して固有な第１のノード１を指す。

図５（ｂ）に示す通り、オンサイトネットワーク０は固有な第１のノード１と、１以上の第２のノード２と、を含む。このとき、ブロックチェーン３上のブロック群３０に含まれる各ブロックのそれぞれは、単一の第２のノード２と対応するとは限らず、図５（ｂ）で例示する通り、第２のノード２Ａ、第２のノード２Ｂ及び第２のノード２Ｃのそれぞれと対応し得る。このとき、各ブロックと対応する第２のノード２の第２の秘密鍵２００２に基づき、当該各ブロックにおける第２の取引署名２００４が生成されることは勿論である。なお、１のブロックチェーン３と対応する第２のノード２の数に、特に制限はない。

実施形態１におけるオンサイトネットワーク０では、第１のノード１、第２のノード２及びブロックチェーン３を含むプライベートネットワークではあるものの、固有な構成は第１のノード１及びブロックチェーン３に留まる。つまり、実施形態１におけるオンサイトネットワーク０は第２のノード２を変化し得るフレキシブルなプライベートネットワークである、と把握することができる。

〈ユーザ定義スキーマ３００１〉
ブロックチェーン３上のユーザ定義スキーマ３００１は、第１のノード１及び第２のノード２間で実行される取引処理と対応するユーザ定義プロファイル及びユーザ定義スクリプトを含む。
なお、本明細書中の説明におけるユーザとは、好ましくは、第１のノード１の所有者／管理者を指し、より好ましくは、第１のノード１又は第２のノード２の所有者／管理者を指す。

実施形態１におけるユーザ定義スキーマ３００１は、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔｉｖｅ Ｎｏｔａｔｉｏｎ）形式を一例とするオブジェクト指向言語に基づき記述される。このため、ユーザ定義スキーマ３００１にて取り扱われるデータ種は、少なくとも、文字列、数値、真偽値等である。

実施形態１におけるユーザ定義スキーマ３００１は、第１のノード１及び第２のノード２間で行われる処理ステータスを示す情報が状態として記述される構成としてもよい。

実施形態１におけるユーザ定義スキーマ３００１は、特徴データ１００４又はそのハッシュ値を有する構成としてもよい。このとき、当該特徴データ１００４が認証手段による認証処理のために利用され得ることは勿論である。また、ユーザ定義スキーマ３００１上で特徴データ１００４を管理する場合においても、登録手段１０４及び登録受付手段２０５による処理の少なくとも一部が要される構成をとり得ることは勿論である。

以下に、実施形態１におけるユーザ定義プロファイルの一例を示す。当該一例では、取引処理が決済処理である場合のユーザ定義プロファイルについて例示している。

｛
種別：ＰｏｔａｂｌｅＰａｙｍｅｎｔ，
請求者：ＡＢＣＤＥ，
ショップＩＤ：１２３４，
担当者： ＦＧＨＩＪ，
請求日：ＹＹＹＹ−ＭＭ−ＤＤ，
請求金額： ５０００，
内訳： 文具，
決済種別： 即時決済（クレジットライン），
決済結果： ＯＫ−０１０００，
クレジットライン
｛
限度額：３０，０００，
残高：５，０００，
移動種別：支払（限度額設定、チャージ、送金、入金），
移動日：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
｝
決済日：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
ＷＥＢログインＫＥＹ：ＡＢＣ…．，
会員ＩＤ：ＡＢＣ…．，
実行コード：ｆｕｎｃｔｉｏｎ｛｝，
第１の取引署名１００７：ＢＢＢＢ…，
承認コード： ａｂｃ１２３，
第１の取引署名１００７： ＸＸＸＸＸＸ，
状態：１
｝

上記の決済処理と対応するユーザ定義スキーマ３００１では、クレジットラインデータに限らず、クレジットカードデータが記述される構成としてもよい。また、決済処理を行うためのデータであれば慣用のデータが、ユーザ定義スキーマ３００１に記述され得る。具体的には、例として、暗号通貨のウォレットアドレス等である。

以下に、実施形態１におけるユーザ定義プロファイルの一例を示す。当該一例では、取引処理が資格提示処理である場合のユーザ定義プロファイルについて例示している。

｛
種別：ＰｏｔａｂｌｅＩｄｅｎｔｉｆｉｃａｔｉｏｎ，
資格：部長，
所属：ソフトウェア開発部，
氏名： ＡＢＣ ＤＥＦ，
生年月日：ＹＹＹＹ−ＭＭ−ＤＤ，
資格取得年月日：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
組織名：ＸＹＺ１，
組織ＩＤ：ＸＸＸＸ……，
証明年月日：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
有効期限：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
証明先：ＸＹＺ２，
ＷＥＢログインＫＥＹ：ＡＢＣ…．，
実行コード：ｆｕｎｃｔｉｏｎ｛｝，
第１の取引署名１００７：ＢＢＢＢ…，
状態：１
｝

上記の資格提示処理と対応するユーザ定義プロファイルでは、学位を証明するための公開鍵を外部ＵＲＬより取得するようなユーザ定義スクリプトと対応する構成としてもよい。

以下に、実施形態１におけるユーザ定義プロファイルの一例を示す。当該一例では、取引処理が貸借管理処理である場合のユーザ定義プロファイルについて例示している。

｛
種別：ＣａｒＲｅｎｔａｌ，
デジタル鍵：ＸＸＸＸ……，
出発地：Ｄｅｐａｒｔｕｒｅ，
出発地緯度経度：……．，
出発時間：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
到着地：Ａｒｒａｉｖａｌ，
到着地緯度経度：……．，
到着時間：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
貸出開始日：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
貸出終了日：ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ，
ＷＥＢログインＫＥＹ：ＡＢＣ…．，
実行コード：ｆｕｎｃｔｉｏｎ｛｝，
第１の取引署名１００７：ＢＢＢＢ…，
状態：１
｝

上記の貸借管理処理と対応するユーザ定義プロファイルでは、例として、貸し手である第１のノード１の所有者が借り手である第２のノード２の所有者に対して提供する自動車等のデジタル鍵が記述される。当該デジタル鍵にはチェックイン場所、有効期限などが登録されており、借り手はこれらの契約の範囲内において自動車等を使用することができる。なお、緯度経度に係るデータは、第１の検出装置１７又は第２の検出装置２７により取得されてもよいし、Ｗｉ−Ｆｉネットワークを含む通信ネットワークＮＷに基づき取得されてもよい。

〈ユーザ定義スクリプト〉
ユーザ定義スクリプトは、ユーザ定義スキーマ３００１に含まれるユーザ定義プロファイルに基づき取引処理を実行するためのコードであり、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語で記述される。

実施形態１における取引処理の実行はスマートコントラクトの態様で行われる。具体的には、例として、ユーザ定義スキーマ３００１上のクレジットラインデータが示す設定額に基づき、決済処理を含む取引処理の執行を判断する。

ユーザ定義スクリプトは、第１のデータベースＤＢ１及び第２のデータベースＤＢ２に格納されていないウェブサイト等へのアクセスが禁止される。このとき、当該アクセスが許可されるＵＲＬ等のリストを含む許可データが第２のノード２により提供されてもよい。なお、ユーザ定義スクリプトは、好ましくは、第１のノード１及び／又は第２のノード２上のサンドボックス環境で動作する。

ユーザ定義スクリプトは、取引処理の態様に応じて適宜、変更されることは勿論である。ここでの取引処理の態様は、例として、決済処理、ロック解除処理、資格提示処理、貸借管理処理等である。また、実施形態１におけるユーザ定義スクリプトは、ブロックチェーン３毎に任意に変更され得ることは勿論である。

ユーザ定義スクリプトは、第１の入力手段１０１又は第２の入力手段２０１により変更される。このとき、第１のノード又は第２のノードによる電子署名がユーザ定義スクリプトに追加されることで、ユーザ定義スクリプトの編集権限を管理する構成としてもよい。具体的には、ユーザ定義スクリプトの一機能として、所定の公開鍵を変更禁止の情報として対応付けることで、当該公開鍵と対応する電子署名を追加できなければユーザ定義スクリプトの変更を許可しない。当該電子署名は、第１のデータベースＤＢ１又は第２のデータベースＤＢ２上を含むオンサイトネットワーク０上の各種情報に基づき生成され得る。

なお、本明細書中で説明される各種データのそれぞれは、当該各種データのそれぞれに基づくハッシュ値を指す場合がある。

〈処理フローチャート／シークエンス〉
以下、実施形態１の情報管理システムにおける処理フローチャートを説明する。当該処理フローチャートは、１以上のステップの集合であり、各手段が有する機能の少なくとも一部に基づきステップのそれぞれが実現されることは勿論である。また、本明細書中で特段の指定が無い限り、当該処理フローチャートにおける各ステップは順不同である。
また、本発明の実施形態１におけるオンサイトネットワーク０は、ブロックチェーン３に基づくトランザクション管理であるため、当該各ステップが円環的に、繰り返し行われることは勿論である。

図６（ａ）に示す通り、情報管理システムに係る一連の処理の少なくとも一部は、チェーン指定手段２０７がブロックチェーン３を指定するチェーン指定ステップＳ１と、取引要求手段２０６により取引要求が実行される取引要求ステップＳ２と、第１の認証手段１０５又は第２の認証手段２０４が認証処理を実行する認証ステップＳ３と、取引実行手段１０７が取引処理を実行する取引実行ステップＳ４と、第２の署名手段２０３が第２の取引署名２００４の生成及びブロックチェーン３上への追加を実行する第２の署名ステップＳ５と、チェーン更新手段１０６が未決定ブロック３３の最終決定（ファイナライズ）及び新たな未決定ブロック３３の生成を実行するチェーン更新ステップＳ６と、を含む。

図６（ｂ）に示す通り、情報管理システムに係る一連の処理の内、認証ステップＳ３は、第１の認証手段１０５による認証処理を含む第１の認証ステップＳ３Ａと、第２の認証手段２０４による認証処理を含む第２の認証ステップＳ３Ｂと、を含む構成としてもよい。なお、認証ステップＳ３における特徴データ１００４の採集元は第１のノード１と対応するユーザであってもよいし、第２のノード２と対応するユーザであってもよい。

実施形態１におけるチェーン更新ステップＳ６は、好ましくは、第２の署名ステップＳ５以降に行われる。また、実施形態１における第２の署名ステップＳ５は、取引実行ステップＳ４以降に行われる。また、実施形態１における取引実行ステップＳ４は、好ましくは、取引要求ステップＳ２以降に行われる。また、実施形態１における取引要求ステップＳ２は、チェーン指定ステップＳ１以降に行われる。

以下、情報管理システムに係る一連の処理の詳細について、図８〜１１を用いて説明する。なお、実施形態１における登録ステップＳ０は、好ましくは、チェーン指定ステップＳ１以前に行われる。

〈登録ステップＳ０〉
図７に示す通り、登録ステップＳ０では特徴データ１００４の登録が行われる。まず、第１のノード１により、検出データの取得（検出処理）と、特徴データ１００４の決定と、が行われる（登録ステップＳ０Ａ）。このとき、第１の公開鍵１００１、特徴データ１００４、属性データ１００５及び端末署名１００６が第１のデータベースＤＢ１に格納される。次に、第１の公開鍵１００１、特徴データ１００４、属性データ１００５及び端末署名１００６が第２のノード２に送信され、第２のデータベースＤＢ２に格納される（登録ステップＳ０Ｂ）。次に、第１の公開鍵１００１に基づき、端末署名１００６の検証が行われる（登録ステップＳ０Ｃ）。端末署名１００６が検証失敗となった場合、登録ステップＳ０に係る処理は終了される。端末署名１００６が検証成功となった場合、第２のノード２により、特徴データ１００４に基づき特徴署名２００３が生成され、第１のノード１に送信される（登録ステップＳ０Ｄ）。

本明細書中における署名検証の失敗とは、署名対象の情報と、公開鍵に基づく電子署名の復号化により得られた情報と、の不一致を指す。また、署名検証の成功とは、署名対象の情報と、当該復号化により得られた情報と、の一致を指す。

実施形態１における登録ステップＳ０は、好ましくは、ブロックチェーン３上の初期ブロック３１の生成に先行して行われる。
なお、初期ブロック３１の生成後に、特徴データ１００４の変更・更新を目的として、再度、登録ステップＳ０が行われ得ることは勿論である。

〈チェーン指定ステップＳ１〉
図８に示す通り、チェーン指定ステップＳ１では、まず、第２のノード２がオンサイトネットワーク０において第１のノード１及びブロックチェーン３を検索する（チェーン指定ステップＳ１Ａ）。次に、検索されたブロックチェーン３の少なくとも１つが、画面表示等を介して指定される（チェーン指定ステップＳ１Ｂ）。

実施形態１におけるチェーン指定ステップＳ１では、第１のノード１及び／又はブロックチェーン３に関するユーザ定義プロファイルが検索条件として利用され得る。当該ユーザ定義プロファイルは、例として、第１のノード１及び第２のノード２の離間距離、第１のノード１と対応する端末データ１００３、ブロックチェーン３上のユーザ定義スキーマ３００１に含まれる情報等、である。

具体的には、ユーザ定義プロファイルにクレジットラインデータが含まれるか否か等、を検索条件とすることができる。また具体的には、クレジットラインデータに含まれる設定額データが所定値以上であるか否か等、を検索条件としてもよい。また具体的には、決済データに含まれる有効期限データが現在日時を超過しているか否か等、を検索条件としてもよい。

実施形態１における離間距離は、相互接続が保持される第１のノード１及び第２のノード２における近距離無線通信による通信距離評価に基づき推定されてよい。また、当該離間距離は、第２のノード２周辺に設置された１以上のビーコン端末に基づく屋内外の位置測位により推定されてもよい。当該離間距離の推定のための位置測位は、電波のみならず、音波又は可視光により行われる構成としてもよい。また、オブジェクト追跡を含む画像処理に基づき、当該離間距離が推定される構成としてもよい。

〈取引要求ステップＳ２〉
図８に示す通り、取引要求ステップＳ２では、まず、ブロックチェーン３上の第１の取引署名１００７が第１の公開鍵１００１に基づき検証される（取引要求ステップＳ２Ａ）。第１の取引署名１００７に関して検証失敗となった場合、取引要求ステップＳ２の処理は終了する。第１の取引署名１００７に関して検証成功となった場合、取引要求が第１のノード１へ送信される（取引要求ステップＳ２Ｂ）。

実施形態１における取引要求は、例えば決済処理の要求である場合、第２のノード２を所有する販売者ユーザと対応する口座情報の送信を含む構成としてもよい。当該口座情報は、第２のデータベースＤＢ２に予め格納されていてもよい。

〈認証ステップＳ３〉
図９に示す通り、実施形態１における認証ステップＳ３は、第１の認証手段１０５による第１の認証ステップＳ３Ａ及び／又は第２の認証手段２０４による第２の認証ステップＳ３Ｂに基づく。認証ステップＳ３では、まず、検出データが取得され特徴データ１００４が決定される。当該特徴データ１００４と、第１のノード１又は第２のノード２に予め格納された特徴データ１００４と、に基づき検証を行う（第１の認証ステップＳ３Ａ１又は第２の認証ステップＳ３Ｂ１）。特徴データ１００４が検証失敗となった場合、認証ステップＳ３の処理は終了する。

〈取引実行ステップＳ４〉
図９に示す通り、実施形態１における取引実行ステップＳ４は、認証ステップＳ３における特徴データ１００４が検証成功となった場合に行われる。取引実行ステップＳ４では、まず、取引処理が実行される（取引実行ステップＳ４Ａ）。

実施形態１における取引処理は、例として、ユーザ定義スキーマ３００１に含まれるユーザ定義プロファイル及びユーザ定義スクリプトに基づく決済処理等である。このとき、ブロックチェーン３上の取引用トークンに基づき取引処理が行われる構成としてもよい。次に、当該決済処理の結果をユーザ定義スキーマ３００１に反映させる（取引実行ステップＳ４Ｂ）。

〈第２の署名ステップＳ５〉
図９に示す通り、実施形態１における第２の署名ステップＳ５は、取引実行ステップＳ４と同様、認証ステップＳ３における特徴データ１００４が検証成功となった場合に行われる。第２の署名ステップＳ５では、まず、第２の取引署名２００４が生成される（第２の署名ステップＳ５Ａ）。次に、第２の取引署名２００４は、ブロックチェーン３上の未決定ブロック３３に格納される（第２の署名ステップＳ５Ｂ）。

〈チェーン更新ステップＳ６〉
図１０に示す通り、実施形態１におけるチェーン更新ステップＳ６では、まず、未決定ブロック３３における第２の取引署名２００４が検証される（チェーン更新ステップＳ６Ａ）。第２の取引署名２００４が検証失敗となった場合、チェーン更新ステップＳ６の処理は終了する。第２の取引署名２００４が検証成功となった場合、未決定ブロック３３をハッシュ化しブロックのハッシュ値３００３を取得する（チェーン更新ステップＳ６Ｂ）。次に、新たな未決定ブロック３３を生成する（チェーン更新ステップＳ６Ｃ）。次に、当該ブロックのハッシュ値３００３を新たな未決定ブロクに格納する（チェーン更新ステップＳ６Ｄ）。

〈第１の署名ステップＳ７〉
図１０に示す通り、実施形態１における第１の署名ステップＳ７では、まず、第１の取引署名１００７が生成される（第１の署名ステップＳ７Ａ）。次に、チェーン更新ステップＳ６で新たに生成された未決定ブロック３３へ、第１の取引署名１００７を格納する（第１の署名ステップＳ７Ｂ）。実施形態１における第１の署名ステップＳ７は、チェーン更新ステップＳ６に次いで行われる構成が好ましい。

以下、実施形態１のオンサイトネットワーク０に基づく決済処理を含む一実施例について説明する。

図１１（ａ）に示す通り、実施形態１に係る一実施例では、取引実行ステップＳ４において即時決済処理が行われる。このとき、第１のノード１の所有者である購入者ユーザと、第２のノード２の所有者である販売者ユーザとの間でサービス享受等を転機とする少額決済が行われているものと仮定する。当該取引実行ステップＳ４では、まず、第１のノード１が外部決済サービスに対して決済依頼を行う。次に、当該外部決済サービスが第２のノード２と対応する口座情報等に基づき、決済処理を行う。

図１１（ｂ）に示す通り、実施形態１に係る一実施例では、取引実行ステップＳ４においてユーザ定義スキーマ３００１上のクレジットラインデータに基づくデポジット決済処理が行われる。当該取引実行ステップＳ４では、外部決済サービスに対してクレジット与信設定を行い、ユーザ定義スキーマ３００１を更新する。図１１（ａ）に示す一実施例と同様、第２のノード２を有する販売者ユーザと対応する口座情報等に基づき、決済処理が行われる。外部決済サービスは、例として、保証会社が提供するサービスである。
なお、本発明の一実施形態における外部決済サービスに係る機能は、販売者ユーザが管理する構成としてもよい。具体的には、クレジット与信設定の受け付けを含むクレジットラインデータ又はクレジットカードデータの管理は、販売者ユーザにより行われる構成としてもよい。

本明細書中の説明における決済処理とは、当該外部決済サービスに対する決済依頼を含めた包括的な決済処理であることは勿論である。また、図１１（ａ）に示す一実施例は、クレジットカードデータに基づく決済処理であり、ユーザ定義スキーマ３００１も適宜、好適に決定される。

〈画面表示例〉
以下、実施形態１の情報管理システムにおける画面表示例について図１２及び図１３を用いて説明する。

図１２に示す通り、チェーン指定ステップＳ１において第２のノード２にてチェーン指定画面Ｗ１が表示処理される。チェーン指定画面Ｗ１Ａでは、チェーン検索意思入力部Ｗ１１とチェーン検索取消意思入力部Ｗ１２とが表示処理される。チェーン指定画面Ｗ１Ｂでは、チェーン検索意思入力部Ｗ１１が指定された場合、チェーン検索結果表示部Ｗ１３がさらに表示処理される。

チェーン検索結果表示部Ｗ１３は、ブロックチェーン３のそれぞれが、当該ブロックチェーン３と対応するユーザ定義スキーマ３００１、及び／又は、当該ブロックチェーン３と対応する第１のノード１の属性データ１００５に基づき表示処理される。具体的には、例として、属性データ１００５に含まれるユーザ名、性別、年齢等の個人情報に基づき、適宜、表示オブジェクトが決定される。また、例として、ユーザ定義スキーマ３００１に基づき表示オブジェクト、適宜、決定される。

図１２に示す通り、取引要求ステップＳ２において第２のノード２にて取引要求画面Ｗ２が表示処理される。取引要求画面Ｗ２Ａでは、チェーン検索結果表示部Ｗ１３におけるブロックチェーン３の少なくとも１つが指定された場合、チェーン情報表示部Ｗ２１、取引要求情報入力部Ｗ２２及び取引要求意思入力部Ｗ２３が表示処理される。チェーン情報表示部Ｗ２１では、チェーン検索結果表示部Ｗ１３における表示内容の少なくとも一部と、取引要求ステータスと、が表示処理される。

取引要求情報入力部Ｗ２２では、例えば取引実行ステップＳ４において決済処理が行われる場合、決済金額に係る情報の入力部が表示処理される。取引要求意思入力部Ｗ２３では、取引実行ステップＳ４で行われる取引処理の種別に応じた入力部が１以上、表示処理される。例として、図１２における取引要求意思入力部Ｗ２３は、即時決済処理、デポジッド決済処理及び後述する資格認証処理のそれぞれと対応する。

取引要求画面Ｗ２Ｂでは、取引要求意思入力部Ｗ２３が指定された場合の取引要求ステータスが表示処理される。取引要求画面Ｗ２Ｃでは、第１のノード１により取引処理が完了された場合の取引要求ステータスが表示処理される。

プロファイル表示部Ｗ３１では、ブロックチェーン３上のユーザ定義スキーマ３００１に基づき取引処理を示す表示内容が表示処理される。

ネットワーク状態表示部Ｗ３２では、オンサイトネットワーク０に係る情報として、例えば、第１のノード１及び第２のノード２の離間距離が表示処理される。プロファイル設定意思入力部Ｗ３３では、ユーザ定義スキーマ３００１に係る変更を行うための意思入力部が表示処理される。

実施形態１における離間距離の表示処理は、数値データとしての離間距離の表示処理に限らず、所定のしきい値を超過するか否かを示す表示処理としてもよい。このとき、当該しきい値は複数設定されてよく、複数のしきい値のそれぞれに応じて表示オブジェクトが適宜、決定される構成としてもよい。

プロファイル設定意思入力部Ｗ３３を介した意思入力を転機として、ユーザ定義スキーマ３００１が変更された場合、第１の署名手段１０３が再度、第１の取引署名１００７を生成し未決定ブロック３３に追加する構成が好ましい。このとき、第２のノード２による第１の取引署名１００７の検証が再度行われることは勿論である。

図１３に示す通り、第２のノード２によりブロックチェーン３が指定され取引要求が送信された場合、第１のノード１において取引開始画面Ｗ４Ａが表示処理される。取引開始画面Ｗ４Ａでは、取引開始意思入力部Ｗ４１及び取引取消意思入力部Ｗ４２が表示処理される。取引開始入力部は、例として、決済処理に係る意思入力として表示処理される。

図１３に示す通り、取引開始意思入力部Ｗ４１が指定された場合、第１のノード１又は第２のノード２は認証画面Ｗ５を一時的に表示処理する。この間、認証ステップＳ３が行われることは勿論である。

認証画面Ｗ５Ａ及び認証画面Ｗ５Ｂでは、取引処理に係る情報の他、認証ステータスと、認証取消意思入力部Ｗ５１と、が表示処理される。認証取消意思入力部Ｗ５１が指定された場合、第１のノード１又は第２のノード２は取引開始画面Ｗ４Ａに移行する。

図１３に示す通り、認証ステップＳ３における特徴データ１００４が検証成功となった場合、取引開始画面Ｗ４Ｂが表示処理される。取引開始画面Ｗ４Ｂでは、クレジットカード情報に係るカード決定意思入力部Ｗ４３及びカード変更意思入力部Ｗ４４が表示処理される。なお、カード変更意思入力部Ｗ４４の指定を転機とするカード変更処理が行われた場合、再度、取引開始画面Ｗ４Ｂが表示処理される。カード決定意思入力部Ｗ４３が指定された場合、第１のノード１に係る画面表示は、取引開始画面Ｗ４Ｃに移行する。取引開始画面Ｗ４Ｃにおける取引開始意思入力部Ｗ４１が指定された場合、最後に、取引完了画面Ｗ６が表示処理される。

《実施形態２》
以下、情報管理システムの実施形態２を説明する。
なお、実施形態２におけるハードウェア構成及び機能とそれらに対応する符号と、は特段の指定がない限り、実施形態１と同様である。

図１４に示す通り、実施形態２におけるオンサイトネットワーク０では、近距離無線通信に限らず、慣用の通信網を介して第１のノード１及び第２のノード２が相互接続される。実施形態２におけるオンサイトネットワーク０では、例として、第１のノード１及び第２のノード２間でウェブログイン認証が実現される。

実施形態２におけるウェブログイン認証では、取引実行ステップＳ４において、第１のノード１が、ログイン用の識別情報やパスワード等に基づくログイン署名を生成し第２のノード２へ送信する。次に、第２のノード２は、ログイン署名の検証を行う。このとき、検証成功だった場合に、第１のノード１によるログインを第２のノード２が許可する。

本発明の実施形態２によれば、ユーザ定義スキーマ３００１上に予め記述されたログイン用の識別情報やパスワードによる認証と、認証ステップＳ３による特徴データ１００４の認証と、による二段階認証を実現することができる。なお、ログイン用の識別情報やパスワード等は、ユーザ定義スキーマ３００１上で記述されてもよいし、取引用トークンとしてブロックチェーン３上に格納されてもよい。

《実施形態３》
以下、情報管理システムの実施形態２を説明する。
なお、実施形態３におけるハードウェア構成及び機能とそれらに対応する符号とは、特段の指定がない限り、実施形態１と同様である。

図１５に示す通り、実施形態３におけるブロックチェーン３は、メインチェーン３Ｘ上のブロックに格納されるサイドチェーンの態様をとる。このとき、メインチェーン３Ｘ上のブロックは、特徴データ１００４を含む。

メインチェーン３Ｘは、ブロックチェーンと同様、初期ブロック、最終決定ブロック及び未決定ブロックを有する。メインチェーン３Ｘに係るブロックの最終決定は、少なくとも１つの第２のノード２による合意形成によって行われる。その後、新たに未決定ブロックが第２のノード２により生成される。

メインチェーン３Ｘは、第１のノード及び／又は第２のノードによる署名生成／追加を転機として、ブロック最終決定／ブロック生成が行われてもよい。このとき、署名生成に用いられるハッシュ値等に、特に制限はない。

メインチェーン３Ｘ上の各ブロックには、トランザクションデータが格納される。当該トランザクションデータは、例として、電子チケットの所有権管理等のために用いられる。実施形態３におけるメインチェーン３Ｘは、任意の会場への入場券の管理を、その実施例として把握することができる。また、実施形態３におけるメインチェーン３Ｘは、任意の金額に係る利用券の管理を、その実施例として把握することができる。

実施形態３におけるブロックチェーン３上の初期ブロック（ジェネシスブロック）の生成は、例として、任意の会場への入場が完了した時点で実行される、と把握することができる。そして、当該任意の会場から退場された時点で、ブロックチェーン３を格納するメインチェーン上の未決定ブロックに係る最終決定が行われる、と把握することができる。このとき、当該任意の会場に係る入退場がメインチェーン３Ｘ上のトランザクションデータとして管理されることは勿論である。

メインチェーン３Ｘは、ブロックチェーン３上のユーザ定義スキーマ３００１を有してもよい。メインチェーン３Ｘ上の特徴データ１００４ならびにユーザ定義スキーマ３００１は、任意の会場への入場等を転機として、ブロックチェーン３上に格納される構成としてもよい。メインチェーン３Ｘは、第１のデータベース上の各種情報を格納し、ブロックの最終決定、ブロック生成、署名生成／追加のために利用してもよい。

本発明の実施形態３によれば、メインチェーン３Ｘ及びブロックチェーン３に基づくマルチチェーンの態様でトランザクション管理を実現することができ、悪意あるユーザによる不正なトランザクションを未然に防ぐことができ得る。

本発明によると、優れたプライバシー保護を実現可能な、かつ、簡易な情報管理ソリューションを提供することができる。

０ オンサイトネットワーク
１、１Ａ、１Ｂ 第１のノード
２、２Ａ、２Ｂ、２Ｃ 第２のノード
３、３Ａ、３Ｂ ブロックチェーン
１１ 第１の演算装置
１２ 第１の主記憶装置
１３ 第１の補助記憶装置
１４ 第１の入力装置
１５ 第１の出力装置
１６ 第１の通信装置
１７ 第１の検出装置
２１ 第２の演算装置
２２ 第２の主記憶装置
２３ 第２の補助記憶装置
２４ 第２の入力装置
２５ 第２の出力装置
２６ 第２の通信装置
２７ 第２の検出装置
３０ ブロック群
３１ 初期ブロック
３２ 最終決定ブロック
３３ 未決定ブロック
３Ｘ メインチェーン
１０１ 第１の入力手段
１０２ 第１の出力手段
１０３ 第１の署名手段
１０４ 登録手段
１０５ 第１の認証手段
１０６ チェーン更新手段
１０７ 取引実行手段
２０１ 第２の入力手段
２０２ 第２の出力手段
２０３ 第２の署名手段
２０４ 第２の認証手段
２０５ 登録受付手段
２０６ 取引要求手段
２０７ チェーン指定手段
１００１ 第１の公開鍵
１００２ 第１の秘密鍵
１００３ 端末データ
１００４ 特徴データ
１００５ 属性データ
１００６ 端末署名
１００７ 第１の取引署名
２００１ 第２の公開鍵
２００２ 第２の秘密鍵
２００３ 特徴署名
２００４ 第２の取引署名
３００１ ユーザ定義スキーマ
３００２ タイムスタンプ
３００３ ブロックのハッシュ値
ＤＢ１ 第１のデータベース
ＤＢ２ 第２のデータベース
ＮＷ 通信ネットワーク
Ｓ０、Ｓ０Ａ、Ｓ０Ｂ、Ｓ０Ｃ、Ｓ０Ｄ 登録ステップ
Ｓ１、Ｓ１Ａ、Ｓ１Ｂ チェーン指定ステップ
Ｓ２、Ｓ２Ａ、Ｓ２Ｂ 取引要求ステップ
Ｓ３ 認証ステップ
Ｓ３Ａ、Ｓ３Ａ１ 第１の認証ステップ
Ｓ３Ｂ、Ｓ３Ｂ１ 第２の認証ステップ
Ｓ４、Ｓ４Ａ、Ｓ４Ｂ 取引実行ステップ
Ｓ５、Ｓ５Ａ 第２の署名ステップ
Ｓ６、Ｓ６Ａ、Ｓ６Ｂ、Ｓ６Ｃ、Ｓ６Ｄ チェーン更新ステップ
Ｓ７、Ｓ７Ａ、Ｓ７Ｂ 第１の署名ステップ
Ｄ１、Ｄ２ 通信可能距離
Ｗ１、Ｗ１Ａ、Ｗ１Ｂ チェーン指定画面
Ｗ２、Ｗ２Ａ、Ｗ２Ｂ、Ｗ２Ｃ 取引要求画面
Ｗ３ 待機画面
Ｗ４、Ｗ４Ａ、Ｗ４Ｂ、Ｗ４Ｃ 取引開始画面
Ｗ５、Ｗ５Ａ、Ｗ５Ｂ 認証画面
Ｗ６ 取引完了画面
Ｗ１１ チェーン検索意思入力部
Ｗ１２ チェーン検索取消意思入力部
Ｗ１３ チェーン検索結果表示部
Ｗ２１ チェーン情報表示部
Ｗ２２ 取引要求情報入力部
Ｗ２３ 取引要求意思入力部
Ｗ３１ プロファイル表示部
Ｗ３２ ネットワーク状態表示部
Ｗ３３ プロファイル設定意思入力部
Ｗ４１ 取引開始意思入力部
Ｗ４２ 取引取消意思入力部
Ｗ４３ カード決定意思入力部
Ｗ４４ カード変更意思入力部
Ｗ５１ 認証取消意思入力部

Claims (19)

1. 情報管理システムであって、
   第１及び第２のノードに格納されるブロックチェーンを有し、
   前記第１又は第２のノードは、特徴データに基づき認証処理を実行する認証手段を有し、
   前記第１のノードは、第１の取引署名の生成及び前記ブロックチェーン上の未決定ブロックへの追加を実行する第１の署名手段を有し、
   前記第２のノードは、前記認証処理の結果及び第１の取引署名に基づき、第２の取引署名の生成及び前記未決定ブロックへの追加を実行する第２の署名手段を有し、
   前記第１のノードは、前記第２の取引署名に基づき、前記未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新手段を有する、
   情報管理システム。
2. 前記ブロックチェーンは、オブジェクト指向言語に基づき記述されるユーザ定義スキーマと対応し、
   前記ユーザ定義スキーマは、スマートコントラクト執行のためのユーザ定義スクリプトと、前記スマートコントラクト執行の結果を含むユーザ定義プロファイルと、を含み、
   前記ユーザ定義スクリプトのハッシュ値は、前記第１の取引署名の生成に用いられる、
   請求項１に記載の情報管理システム。
3. 前記ブロックチェーンは、少なくとも１つの前記第１のノードのそれぞれに固有なプライベートチェーンである、
   請求項１から２の何れかに記載の情報管理システム。
4. 前記ブロックチェーンは、少なくとも前記第１の取引署名と、最終決定ブロックのハッシュ値と、を含む未決定ブロックを有し、
   前記最終決定ブロックは、前記第１及び第２の取引署名と、直前の前記最終決定ブロックのハッシュ値と、を含む、
   請求項１から３の何れかに記載の情報管理システム。
5. 前記認証手段は、前記認証処理に際し前記第１のノードにより新たに取得された前記特徴データに基づき、前記認証処理を実行する、
   請求項１から４の何れかに記載の情報管理システム。
6. 前記認証手段は、前記認証処理に際し前記第２のノードにより新たに取得された前記特徴データに基づき、前記認証処理を実行する、
   請求項１から５の何れかに記載の情報管理システム。
7. 前記特徴データは、顔データを含む生体データに基づく、
   請求項１から６の何れかに記載の情報管理システム。
8. 前記第１の署名手段は、前記チェーン更新手段による前記ハッシュ化及びブロック生成を転機として、前記第１の取引署名の生成及び追加を実行する、
   請求項１から７の何れかに記載の情報管理システム。
9. 前記第１のノードは、前記第１のノードと対応する端末署名及び前記特徴データを前記第２のノードに送信する登録手段をさらに有し、
   前記第２のノードは、前記端末署名に基づき前記特徴データを受け付け、前記特徴データに基づく特徴署名を前記第１のノードに送信する登録受付手段をさらに有し、
   前記認証手段は、前記第１のノードが前記特徴署名を有する場合、前記認証処理を実行する、
   請求項１から８の何れかに記載の情報管理システム。
10. 前記第２のノードは、前記第１の取引署名に基づき前記第１のノードに取引要求を行う取引要求手段を有し、
    前記第１のノードは、前記認証処理の結果及び取引要求に基づき取引処理を実行する取引実行手段をさらに有する、
    請求項１から９の何れかに記載の情報管理システム。
11. 前記認証手段は、前記取引要求手段による前記取引要求を転機として前記第１又は第２のノードにより取得された前記特徴データに基づき、前記認証処理を実行し、
    前記第２の署名手段は、前記取引実行手段による取引処理の実行を転機として、前記第２の取引署名の生成及び追加を実行する、
    請求項１０に記載の情報管理システム。
12. 前記第１のノードは、前記第１のノードと対応する前記ブロックチェーンの少なくとも１つの検索及び指定を実行するチェーン指定手段をさらに有する、
    請求項１から１１の何れかに記載の情報管理システム。
13. 前記認証手段、前記第１の署名手段、前記第２の署名手段及び前記チェーン更新手段の少なくとも１つは、近距離無線通信による相互接続が保持されている前記第１及び第２のノードに基づく
    請求項１から１２の何れかに記載の情報管理システム。
14. 前記ブロックチェーンは、メインチェーン上のブロックに格納されるサイドチェーンである、
    請求項１から１３の何れかに記載の情報管理システム。
15. 前記メインチェーン上のブロックは、前記特徴データを含む、
    請求項１４に記載の情報管理システム。
16. 情報管理方法であって、第１のノードが有するコンピュータプロセッサに、
    特徴データに基づき認証処理を実行する認証ステップと、
    第１の取引署名の生成と、第２のノード及び前記第１のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名ステップと、
    前記第２のノードにより生成された第２の取引署名に基づき、前記未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新ステップと、を実行させる、
    情報管理方法。
17. 情報管理方法であって、第２のノードが有するコンピュータプロセッサに、
    特徴データに基づき認証処理を実行する認証ステップと、
    前記認証処理の結果及び第１のノードにより生成された第１の取引署名に基づき、
    第２の取引署名の生成と、前記第１及び第２のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名ステップと、を実行させる、
    情報管理方法。
18. 情報管理プログラムであって、第１のノードを、
    特徴データに基づき認証処理を実行する認証手段と、
    第１の取引署名の生成と、第２のノード及び前記第１のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名手段と、
    前記第２のノードと対応する秘密鍵に基づき生成された第２の取引署名に基づき、前記未決定ブロックのハッシュ化及びブロック生成を実行するチェーン更新手段と、として機能させる、
    情報管理プログラム。
19. 情報管理プログラムであって、第２のノードを、
    特徴データに基づき認証処理を実行する認証手段と、
    第１のノードと対応する秘密鍵に基づき生成された第１の取引署名及び前記認証処理の結果に基づき、
    第２の取引署名の生成と、前記第１及び第２のノードに格納されるブロックチェーン上の未決定ブロックへの追加と、を実行する署名手段と、として機能させる、
    情報管理プログラム。