(57)【要約】      （修正有）【課題】改竄耐性と、即時性と、を有する電子チケット管理システムを提供する。【解決手段】電子チケット管理システムにおいて、ユーザ端末２と、ノード群５と、を備える。ユーザ端末は、ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録手段と、所有者署名を生成し、メインチェーン上のブロックに追加する取引申請手段と、を有する。ノード群は、管理者署名を生成しメインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認手段を有する。メインチェーンは、端末署名と、所有者署名と、管理者署名と、サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、サブチェーンは、取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有する。【選択図】図７
2020098632.tif 000002
【特許請求の範囲】
【請求項１】
電子チケット管理システムであって、
ユーザ端末と、ノード群と、を備え、
前記ユーザ端末は、ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録手段と、
所有者署名を生成し、前記メインチェーン上のブロックに追加する取引申請手段と、を有し、
前記ノード群は、管理者署名を生成し前記メインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認手段を有し、
前記メインチェーンは、前記端末署名と、前記所有者署名と、前記管理者署名と、前記サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、
前記サブチェーンは、前記取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有することを特徴とする電子チケット管理システム。
【請求項２】
前記取引承認手段は、前記メインチェーン上のブロックに前記管理者署名を追加し、該ブロックに基づきハッシュ値を生成し、該ハッシュ値を含むブロックを前記メインチェーン上に追加することを特徴とする請求項１に記載の電子チケット管理システム。
【請求項３】
前記取引承認手段は、前記サブチェーン上のブロックに前記取引承認者署名を追加し、
前記取引申請手段は、該取引承認者署名が追加された該ブロックに基づきハッシュ値を生成し、該ハッシュ値を含むブロックを前記サブチェーン上に追加することを特徴とする請求項１又は２に記載の電子チケット管理システム。
【請求項４】
前記取引承認手段は、電子チケットに係るイベント情報、日付情報及び座席情報の少なくとも１つを用いて生成されたハッシュ値に基づく電子チケット識別情報を生成し、前記メインチェーン及びサブチェーンに係る情報と、前記電子チケット識別情報と、を対応付けることを特徴とする請求項１〜３の何れかに記載の電子チケット管理システム。
【請求項５】
前記取引承認手段は、前記端末署名に係る復号化処理による署名検証の結果、及び／又は、前記所有者署名に係る復号化処理による署名検証の結果に基づき、前記管理者署名を生成することを特徴とする請求項１〜４の何れかに記載の電子チケット管理システム。
【請求項６】
前記取引承認手段は、前記端末署名に係る復号化処理による署名検証の結果、及び／又は、前記管理者署名に係る復号化処理による署名検証の結果に基づき、前記取引承認者署名を生成することを特徴とする請求項１〜５の何れかに記載の電子チケット管理システム。
【請求項７】
前記メインチェーンは、前記端末署名と、前記所有者署名と、前記管理者署名と、前記サブチェーン上のブロックと、ユーザ属性情報と、ユーザ公開鍵と、に基づくハッシュ値を含むブロックを有し、
前記端末登録手段は、ユーザ顔画像、ユーザ個人情報及びユーザ生体情報の少なくとも１つを含む前記ユーザ属性情報を、前記メインチェーン上のブロックに追加することを特徴とする請求項１〜６の何れかに記載の電子チケット管理システム。
【請求項８】
前記取引承認手段は、取引申請処理に係る意思入力を行ったユーザに対する位置認証処理、及び／又は、身元認証処理に基づき、前記取引承認者署名を生成することを特徴とする請求項１〜７の何れかに記載の電子チケット管理システム。
【請求項９】
前記位置認証処理は、前記ユーザ端末に係る信号受信履歴に基づき、行われることを特徴とする請求項８に記載の電子チケット管理システム。
【請求項１０】
前記信号受信履歴は、前記ノード群を介して無線通信により送受信される情報、又は、前記無線通信に係る信号強度に係る情報を示すことを特徴とする請求項９に記載の電子チケット管理システム。
【請求項１１】
前記無線通信は、電波、超音波及び可視光波の少なくとも１つを用いることを特徴とする請求項１０に記載の電子チケット管理システム。
【請求項１２】
前記身元認証処理は、前記ノード群により撮像処理されたユーザ顔画像と、前記メインチェーン上に追加されたユーザ顔画像と、の類似度検出処理に基づき、行われることを特徴とする請求項８〜１１の何れかに記載の電子チケット管理システム。
【請求項１３】
前記取引申請手段は、ユーザ秘密鍵の出力を転機として、取引申請処理に係る意思入力の受付と、前記メインチェーン及びサブチェーンに係る電子署名の生成と、前記メインチェーン及びサブチェーンに係るハッシュ値の生成と、を抑止することを特徴とする請求項１〜１２の何れかに記載の電子チケット管理システム。
【請求項１４】
前記取引申請手段は、前記メインチェーン上のブロックが、前記所有者署名を含み、前記管理者署名を含まない場合、前記サブチェーンに係る電子署名の生成と、ハッシュ値の生成と、を抑止することを特徴とする請求項１〜１３の何れかに記載の電子チケット管理システム。
【請求項１５】
前記取引属性情報は、電子チケットに対応付けられたイベント会場における、取引申請処理に係る意思入力を行ったユーザによる入退場履歴、又は、該ユーザによる決済履歴を示すことを特徴とする請求項１〜１４の何れかに記載の電子チケット管理システム。
【請求項１６】
前記ノード群は、前記管理者署名の生成を行う１以上のメインノードと、
前記取引承認者署名の生成を行う１以上のサブノードと、を備え、
１以上の前記メインノードは、パブリックネットワーク上に置かれ、
１以上の前記サブノードは、プライベートネットワーク上に置かれることを特徴とする請求項１〜１５の何れかに記載の電子チケット管理システム。
【請求項１７】
１以上の前記メインノードと、１以上の前記サブノードとは、前記プライベートネットワーク上で相互接続され、
前記プライベートネットワークは、メッシュネットワークであることを特徴とする請求項１６に記載の電子チケット管理システム。
【請求項１８】
電子チケット管理方法であって、
ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録ステップと、
所有者署名を生成し、前記メインチェーン上のブロックに追加する取引申請ステップと、
管理者署名を生成し前記メインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認ステップと、を有し、
前記メインチェーンは、前記端末署名と、前記所有者署名と、前記管理者署名と、前記サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、
前記サブチェーンは、前記取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有することを特徴とする電子チケット管理方法。
【請求項１９】
電子チケット管理プログラムであって、
コンピュータを、ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録手段と、
所有者署名を生成し、前記メインチェーン上のブロックに追加する取引申請手段と、
管理者署名を生成し前記メインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認手段と、として機能させ、
前記メインチェーンは、前記端末署名と、前記所有者署名と、前記管理者署名と、前記サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、
前記サブチェーンは、前記取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有することを特徴とする電子チケット管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子チケット管理システム、電子チケット管理方法及び電子チケット管理プログラムに関する。
【背景技術】
【０００２】
近年、イベント会場に係る入場チケットを、電子デバイス上で管理する試みが行われている。紙媒体によるチケット管理では転売防止の措置が困難であり、また、チケット価格の高騰も問題点として挙げられていることから、チケットに係る所有権を管理し転売を防止するチケット管理システムが求められている。
【０００３】
特許文献１では、少なくとも参加するイベントを特定する情報を含む電子チケットを売却するための売却依頼を、当該電子チケットを購入した第１の購入者から受け付ける売却依頼受付部と、当該売却依頼を受け付けた以降に、当該電子チケットの使用を制限するための情報を、当該電子チケットを認証する認証装置に送信する無効化部と、当該売却依頼を受け付けた以降に、当該電子チケットを購入する第２の購入者に対して、当該電子チケットを提示し電子チケットが販売された場合に、当該電子チケットに関する情報を、当該第２の購入者に送信する販売部と、当該電子チケットが販売された以降に、当該電子チケットの使用を可能とするための情報を、当該電子チケットを認証する認証装置に送信する有効化部と、を含む電子チケット販売装置に関する技術が報告されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１８−２６０７８
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しがしながら、チケット譲渡、イベント会場入場、及び、イベント会場内決済を含む電子チケット管理に係る処理が管理サーバ群により行われる場合、該処理に係る各種情報は、悪意あるユーザにより改竄される恐れがある。
【０００６】
電子チケット管理システムに係る改竄耐性は、ブロックチェーンを含むハッシュチェーンの導入により、向上できる。
【０００７】
ただし、チケット取引に係るブロックチェーン上の承認作業を、パブリックノード群による合意形成に基づいて行う場合、該取引に係る承認作業の即時性を保てず、チケット譲渡又は入場を、円滑に行うことができない恐れがある。
【０００８】
本発明は、上記のような実情に鑑みてなされたものであり、改竄耐性と、即時性と、を有する電子チケット管理システムの実現を、解決すべき課題とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明に係る電子チケット管理システムは、ユーザ端末と、ノード群と、を備え、
ユーザ端末は、ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録手段と、
所有者署名を生成し、メインチェーン上のブロックに追加する取引申請手段と、を有し、
ノード群は、管理者署名を生成しメインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認手段を有し、
メインチェーンは、端末署名と、所有者署名と、管理者署名と、サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、
サブチェーンは、取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有することを特徴とする。
【００１０】
このような構成とすることで、改竄耐性及び即時性を有する複数のプライベートチェーンに基づいて、電子チケット管理を行える。本発明に係るメインチェーンは、電子チケットに係る所有権、又は、保証金等のデポジット処理の管理の用に供される。また、本発明に係るサブチェーンは、該電子チケットに対応付けられたイベント会場への入場処理、又は、該イベント会場内の決済処理に係る管理の用に供される。
【００１１】
本発明の好ましい形態では、取引承認手段は、メインチェーン上のブロックに管理者署名を追加し、該ブロックに基づきハッシュ値を生成し、該ハッシュ値を含むブロックをメインチェーン上に追加することを特徴とする。
このような構成とすることで、チケット譲渡を含む電子商取引に係る履歴を、ハッシュチェーンの態様で、記録することができる。
【００１２】
本発明の好ましい形態では、取引承認手段は、サブチェーン上のブロックに取引承認者署名を追加し、
取引申請手段は、該取引承認者署名が追加された該ブロックに基づきハッシュ値を生成し、該ハッシュ値を含むブロックをサブチェーン上に追加することを特徴とする。
このような構成とすることで、チケット入場、又は、イベント会場内の決済処理を含む電子商取引に係る履歴を、ハッシュチェーンの態様で、記録することができる。また、ユーザ端末２によりサブチェーンのブロック生成が行われるため、該サブチェーンはユーザ端末２に対して永続化される。
【００１３】
本発明の好ましい形態では、取引承認手段は、電子チケットに係るイベント情報、日付情報及び座席情報の少なくとも１つを用いて生成されたハッシュ値に基づく電子チケット識別情報を生成し、メインチェーン及びサブチェーンに係る情報と、電子チケット識別情報と、を対応付けることを特徴とする。
このような構成とすることで、本発明に係るメインチェーン及びサブチェーン上のブロックが有する情報と、電子チケットと、を対応付けることができる。
【００１４】
本発明の好ましい形態では、取引承認手段は、端末署名に係る復号化処理による署名検証の結果、及び／又は、所有者署名に係る復号化処理による署名検証の結果に基づき、管理者署名を生成することを特徴とする。
このような構成とすることで、本発明に係るメインチェーン上の取引承認処理を、ユーザ端末及びチケット所有者に係る検証処理の結果に基づいて、行うことができる。
【００１５】
本発明の好ましい形態では、取引承認手段は、端末署名に係る復号化処理による署名検証の結果、及び／又は、管理者署名に係る復号化処理による署名検証の結果に基づき、取引承認者署名を生成することを特徴とする。
このような構成とすることで、本発明に係るサブチェーン上の取引承認処理を、ユーザ端末及びチケット所有者に係る検証処理の結果に基づいて、行うことができる。
【００１６】
本発明の好ましい形態では、メインチェーンは、端末署名と、所有者署名と、管理者署名と、サブチェーン上のブロックと、ユーザ属性情報と、ユーザ公開鍵と、に基づくハッシュ値を含むブロックを有し、
端末登録手段は、ユーザ顔画像、ユーザ個人情報及びユーザ生体情報の少なくとも１つを含むユーザ属性情報を、メインチェーン上のブロックに追加することを特徴とする。
このような構成とすることで、取引承認手段が管理者署名を生成する際にユーザ端末又はチケット所有者に係る検証処理の用に供される情報を、メインチェーン上に記録することができる。
【００１７】
本発明の好ましい形態では、取引承認手段は、取引申請処理に係る意思入力を行ったユーザに対する位置認証処理、及び／又は、身元認証処理に基づき、取引承認者署名を生成することを特徴とする。
このような構成とすることで、取引承認手段が取引承認者署名を生成しサブチェーン上に追加する際に行うチケット所有者に係る検証処理を、位置認証処理、及び／又は、身元認証処理に基づき行える。
【００１８】
本発明の好ましい形態では、位置認証処理は、ユーザ端末に係る信号受信履歴に基づき、行われることを特徴とする。
このような構成とすることで、屋内測位、又は、屋外測位においてユーザ端末が受信する種々の信号に基づき、該位置認証処理が行える。
【００１９】
本発明の好ましい形態では、信号受信履歴は、ノード群を介して無線通信により送受信される情報、又は、無線通信に係る信号強度に係る情報を示すことを特徴とする。
このような構成とすることで、屋内測位、又は、屋外測位においてユーザ端末が受信する種々の信号に係る情報又は信号強度に基づき、該位置認証処理が行える。
【００２０】
本発明の好ましい形態では、無線通信は、電波、超音波及び可視光波の少なくとも１つを用いることを特徴とする。
このような構成とすることで、屋内測位、又は、屋外測位における無線通信が、電波、超音波及び可視光波の組み合わせにより実施でき、イベント会場の電波遮断性等によらず、本発明に係る電子チケット管理システムが実現できる。
【００２１】
本発明の好ましい形態では、身元認証処理は、ノード群により撮像処理されたユーザ顔画像と、メインチェーン上に追加されたユーザ顔画像と、の類似度検出処理に基づき、行われることを特徴とする。
このような構成とすることで、顔認証による身元認証処理を行った上で、取引承認手段による取引承認者署名の生成と、サブチェーンへの取引承認者署名の追加を行える。
【００２２】
本発明の好ましい形態では、取引申請手段は、ユーザ秘密鍵の出力を転機として、取引申請処理に係る意思入力の受付と、メインチェーン及びサブチェーンに係る電子署名の生成と、メインチェーン及びサブチェーンに係るハッシュ値の生成と、を抑止することを特徴とする。
このような構成とすることで、サブチェーンに係る更新処理の抑止により、鍵流出に基づく不正なチケット入場を防止できる。
【００２３】
本発明の好ましい形態では、取引申請手段は、メインチェーン上のブロックが、所有者署名を含み、管理者署名を含まない場合、サブチェーンに係る電子署名の生成と、ハッシュ値の生成と、を抑止することを特徴とする。
このような構成とすることで、電子チケットの譲渡が完了していない場合、当該電子チケットを用いたイベント会場への入場等を含むサブチェーンの更新処理を抑止できる。
【００２４】
本発明の好ましい形態では、取引属性情報は、電子チケットに対応付けられたイベント会場における、取引申請処理に係る意思入力を行ったユーザによる入退場履歴、又は、該ユーザによる決済履歴を示すことを特徴とする。
このような構成とすることで、電子チケットに対応付けられたサブチェーンの更新処理により、イベント会場への入場、又は、イベント会場内の決済処理の管理を実施できる。
【００２５】
本発明の好ましい形態では、ノード群は、管理者署名の生成を行う１以上のメインノードと、
取引承認者署名の生成を行う１以上のサブノードと、を備え、
１以上のメインノードは、パブリックネットワーク上に置かれ、
１以上のサブノードは、プライベートネットワーク上に置かれることを特徴とする。
このような構成とすることで、電子チケットに対応付けられたイベント会場が電波遮断性を有する等の理由でパブリックネットワークへの接続が困難な場合、プライベートネットワークを介して電子チケット管理に係る処理が可能となる。
【００２６】
本発明の好ましい形態では、１以上のメインノードと、１以上のサブノードとは、プライベートネットワーク上で相互接続され、
プライベートネットワークは、メッシュネットワークであることを特徴とする。
このような構成とすることで、電子チケットに対応付けられたイベント会場が電波遮断性を有する等の理由でパブリックネットワークへの接続が困難な場合、プライベートネットワークを介して電子チケット管理に係る処理が可能となる。
【００２７】
本発明に係る電子チケット管理方法は、
ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録ステップと、
所有者署名を生成し、メインチェーン上のブロックに追加する取引申請ステップと、
管理者署名を生成しメインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認ステップと、を有し、
メインチェーンは、端末署名と、所有者署名と、管理者署名と、サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、
サブチェーンは、取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有することを特徴とする。
【００２８】
本発明に係る電子チケット管理プログラムは、
コンピュータを、ユーザ端末情報に基づいて端末署名を生成し、メインチェーン上のブロックに追加する端末登録手段と、
所有者署名を生成し、メインチェーン上のブロックに追加する取引申請手段と、
管理者署名を生成しメインチェーン上のブロックに追加し、取引承認者署名を生成しサブチェーン上のブロックに追加する取引承認手段と、として機能させ、
メインチェーンは、端末署名と、所有者署名と、管理者署名と、サブチェーン上のブロックと、に基づくハッシュ値を含むブロックを有し、
サブチェーンは、取引承認者署名と、取引属性情報と、に基づくハッシュ値を含むブロックを有することを特徴とする。
【発明の効果】
【００２９】
本発明によれば、改竄耐性と、即時性と、を有する電子チケット管理システムを、プライベートチェーンに基づいて実現できる。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施形態１に係る電子チケット管理システムの概要図である。
【図２】本発明の実施形態１における機能ブロック図及びハードウェア構成図である。
【図３】本発明の実施形態１におけるチケット譲渡プロセス及びチケット入場プロセスに係る処理フローチャートと、メインチェーン及びサブチェーンが有する情報を示す模式図である。
【図４】本発明の実施形態１におけるメインチェーン又はサブチェーンにおけるチェーン更新の概要を示す模式図である。
【図５】本発明の実施形態１における端末署名及び端末登録の処理フローチャートと、所有者署名及び譲受者署名の処理フローチャートを示す模式図である。
【図６】本発明の実施形態１における存在証明プロトコルに基づくユーザ検証処理の概要を示す模式図である。
【図７】本発明の実施形態２における機能ブロック図及びハードウェア構成図である。
【図８】本発明の実施形態３における決済保証プロセスに係る処理フローチャートと、メインチェーン及びサブチェーンが有する情報を示す模式図である。
【発明を実施するための形態】
【００３１】
＜実施形態１＞
以下、図面を用いて、本発明に係る電子チケット管理システム１の実施形態１について説明する。なお、以下に示す実施形態は本発明の一例であり、本発明を以下の実施形態に限定するものではなく、様々な構成を採用することもできる。
【００３２】
例えば、実施形態１では、電子チケット管理システム１の構成、動作などについて説明するが、同様の構成の方法、サーバ装置、コンピュータプログラム、記録媒体なども、同様の作用効果を奏することができる。
【００３３】
また、プログラムは、記録媒体に記憶させてもよい。この記録媒体を用いれば、例えばコンピュータにプログラムをインストールすることができる。ここで、プログラムを記憶した記録媒体は、例えばＣＤ−ＲＯＭ等の非一過性の記録媒体であっても良い。
【００３４】
実施形態１では、電子チケットに係る情報を、ノード群としての複数のコンピュータ装置１０と、１以上のユーザ端末２と、を用いて分散型データベースの態様で管理し（図１（ａ））、チケット譲渡に係る処理（図１（ｂ））と、チケット入場（図１（ｃ））に係る処理と、が行われる。チケット譲渡は、チケット所有権の移転を指す。
【００３５】
実施形態１では、ノード群が、１以上のメインノード３と、１以上のサブノード４と、を備える。このとき、ノード群は、メインノード３が有する機能又はサブノード４が有する機能を含まないコンピュータ装置１０を、含む構成としてもよい。
【００３６】
また、実施形態１では、ユーザによる意思入力は、ユーザ端末２に記憶したアプリケーションを用いて行う。電子チケット管理に係るユーザによる意思入力はこれに限らず、例えば、ユーザのメールアドレスに対して電子メールを送信する方法や、その他、ＳＭＳ等、種々の方法を利用することができる。
【００３７】
図２は、本発明の実施形態に係る電子チケット管理システム１の機能ブロック図及びハードウェア構成図の一部を示している。
【００３８】
図２（ａ）に示す通り。電子チケット管理システム１は、ユーザ端末２と、メインノード３と、サブノード４と、を備える。
【００３９】
ユーザ端末２及びメインノード３は、パブリックネットワークＮＷ１を介して、例えば、通信プロトコルにＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）等を用いてデータ通信ができる。なお、パブリックネットワークＮＷ１は、例えば、ＣＡＴＶ（Ｃｏｍｍｕｎｉｔｙ  Ａｎｔｅｎｎａ  Ｔｅｌｅｖｉｓｉｏｎ）回線や、移動体通信網等、種々の回線に基づく。
【００４０】
ユーザ端末２、メインノード３及びサブノード４は、プライベートネットワークＮＷ２を介して、相互通信が可能であることが好ましい。このとき、プライベートネットワークＮＷ２は、無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）等の短距離通信システムによるネットワーク構成となる。また、プライベートネットワークＮＷ２は、Ｐ２Ｐ（Ｐｅａｒ  ｔｏ  Ｐｅａｒ）通信に基づくメッシュネットワークの態様であってもよい。
【００４１】
図２（ｂ）は、ユーザ端末２のハードウェア構成の一例を示す図である。ユーザ端末２は、演算装置（ＣＰＵ２０１）と、主記憶装置（ＲＡＭ２０２）と、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、フラッシュメモリなどの補助記憶装置（記録装置２０３）と、パブリックネットワークＮＷ１及び／又はプライベートネットワークＮＷ２を介して通信を行う為のインタフェースである通信装置２０４と、入力装置２０５と、出力装置２０６と、を備えている。
【００４２】
記録装置２０３は、オペレーティングシステム２０７と、該システムと協調してその機能を発揮する電子チケット管理プログラム２０８等と、が記録されている。
【００４３】
実施形態１における、入力装置２０５は、タッチパネル等の入力デバイスとし、出力装置２０６は、ディスプレイ等の構成とすることが好ましい。
【００４４】
なお、実施形態１では、メインノード３及びサブノード４は、ユーザ端末２が有するハードウェア構成に加え、後述の存在証明プロトコルに基づくユーザ検証処理に供される種々のセンサーデバイスを備える構成であることが好ましい。このとき、ユーザ端末２、メインノード３及びサブノード４は、スマートフォン等の端末である構成としてもよい。
【００４５】
ユーザ端末２は、端末登録手段２１と、取引申請手段２２と、を有する。メインノード３は、端末承認手段３１と、取引承認手段３２と、を有する。サブノード４は、取引承認手段４１を有する。
【００４６】
実施形態１における譲渡依頼処理及び譲渡承認処理を含む、チケット譲渡プロセスは、メインチェーンＭ０上で行われる。
【００４７】
メインチェーンＭ０は、チケット譲渡プロセスに係る電子署名と、該電子署名と、公開鍵に係る情報と、チケット所有者に係る情報と、が暗号化されたハッシュ値ＭＨを有する。このとき、該ハッシュ値ＭＨは、メインチェーンＭ０における直前のブロックが有する情報が暗号化された、ハッシュ値ＭＨを指す。
【００４８】
メインチェーンＭ０上のブロックＢ０が有する電子署名は、ユーザ秘密鍵Ｋ２０とユーザ端末情報ＵＤとに基づいて生成された端末署名ＳＧＮ１と、ユーザ秘密鍵Ｋ２０とユーザ属性情報ＵＭの一部とに基づき生成された所有者署名ＳＧＮ２と、メインノード３が有する、譲受者に対応付けられたユーザ秘密鍵Ｋ２５とユーザ属性情報ＵＭとに基づいて生成された譲受者署名ＳＧＮ３と、メインノード３が有するメインノード秘密鍵Ｋ３０に基づき生成された管理者署名ＳＧＮ４と、を指す。
【００４９】
メインチェーンＭ０上のブロックＢ０が有するチケット所有者に係る情報は、ユーザ端末２が有するユーザ秘密鍵Ｋ２０に対応付けられたユーザ公開鍵Ｋ２１と、ユーザ顔画像ＵＦ、ユーザ個人情報ＵＰ及びユーザ生体情報ＵＢの少なくとも１つを含むユーザ属性情報ＵＭと、を指す。
【００５０】
なお、実施形態１における、メインチェーンＭ０上のファイナリティは、チェーン更新（ステップＭＸ）が完了する都度、得られ、追加ブロックＢ１の直前のブロックは、確定ブロックとして取り扱われる。
【００５１】
実施形態１における入場申請処理及び入場承認処理を含む、チケット入場プロセスは、サブチェーンＳ０上で行われる。
【００５２】
サブチェーンＳ０は、チケット入場プロセスに係る電子署名と、該電子署名と入退場情報ＥＴＲとが暗号化されたハッシュ値ＳＨと、を有する。このとき、該ハッシュ値ＳＨは、サブチェーンＳ０における直前のブロックを暗号化したハッシュ値ＳＨを指す。
【００５３】
サブチェーンＳ０上のブロックＢ０が有する電子署名は、サブノード４が有するサブノード秘密鍵Ｋ４０に基づき生成された、取引承認者署名ＳＧＮ５を指す。
【００５４】
なお、実施形態１における、サブチェーンＳ０上のファイナリティは、チェーン更新（ステップＳＸ）が完了する都度、得られ、追加ブロックＢ１の直前のブロックは、確定ブロックとして取り扱われる。
【００５５】
次に、実施形態１における取引申請手段２２、取引承認手段３２及び４１に係る機能について、チケット譲渡プロセス及びチケット入場プロセスに係る処理フローチャートを用いて説明する。
【００５６】
図３は、チケット譲渡プロセス及びチケット入場プロセスに係る処理フローチャート（図３（ａ））と、メインチェーンＭ０及びサブチェーンＳ０の模式図（図３（ｂ））と、を示している。
【００５７】
はじめに、チケット譲渡プロセスに係るメインチェーンＭ０上の処理フローチャートについて説明する。実施形態１において、メインチェーンＭ０は、各チケットに対応付けられており、チケット譲渡が行われる都度、メインチェーンＭ０の更新が行われる。
【００５８】
チケット譲渡プロセスでは、チケット譲渡に際し、チェーン更新（ステップＭＸ）の後、端末登録手段２１により、生成ブロックに対する端末署名ＳＧＮ１の追加が行われ、端末承認手段３１による端末承認処理が行われる（ステップＭ１０）。
【００５９】
次に、取引申請手段２２による所有者署名ＳＧＮ２の追加と、取引承認手段３２による譲受者署名ＳＧＮ３の追加と、が行われる（ステップＭ２０）。
【００６０】
次に、取引承認手段３２による管理者署名ＳＧＮ４の追加が行われる（ステップＭ３０）。
【００６１】
最後に、メインチェーンＭ０上の生成ブロック（ブロックＢ０）は暗号化され、ハッシュ値ＭＨが生成される（ステップＭＸ）。一連の手順は、電子チケットの譲渡が行われる都度、繰り返され、例えば、図３（ａ）における端末署名に係る処理（ステップＭ２０）は、ステップＭ２０Ａ、Ｍ２０Ｂと表記している。
【００６２】
図３（ｂ）が示す通り、メインチェーンＭ０は、前述の複数の電子署名と、直前のブロックが有するハッシュ値と、ユーザ公開鍵Ｋ２１と、ユーザ属性情報ＵＭ及びサブチェーンＳ０に係る情報と、を含む。このとき、メインチェーンＭ０は、電子チケット識別情報ＴＣＫに対応付けられている。
【００６３】
電子チケット識別情報ＴＣＫは、電子チケット管理システム１上のチケット重複を抑止するために、電子チケットに対して、個別に割り振られる。該電子チケット識別情報ＴＣＫは、該電子チケットに対応付けられた、イベント会場、開始時刻及び座席等に係る一意の情報の少なくとも１つに基づいて、一方向性変換により生成されたハッシュ値を含む。
【００６４】
実施形態１では、分散型Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ（分散型ＫＶＳ）の態様で、メインチェーンＭ０及びサブチェーンＳ０上のブロックＢ０に係る情報と、電子チケット識別情報ＴＣＫと、がデータベースＤＢ２、ＤＢ３及びＤＢ４に格納される構成が好ましい。このとき、該分散型ＫＶＳにおけるメインチェーンＭ０に係るＫｅｙは、該電子チケット識別情報ＴＣＫとなる。
【００６５】
なお、実施形態１における、データベースＤＢ２に格納されるメインチェーンＭ０及びサブチェーンＳ０上のブロックＢ０に係る情報は、データベースＤＢ２を有するユーザ端末２に対応付けられた電子チケットに係る情報である構成が好ましい。
【００６６】
次に、図３（ａ）に記載のチケット譲渡プロセスに係る各ステップの詳細を説明する。
【００６７】
図４は、メインチェーンＭ０の更新（ステップＭＸ）並びに、後述するサブチェーンＳ０の更新（ステップＳＸ）に係る処理フローチャート（図４（ａ））及びメインチェーンＭ０上のブロックが有する署名情報等の模式図（図４（ｂ））を示している。
【００６８】
図４（ａ）に示す通り、チェーン更新（ステップＭＸ）は、メインチェーンＭ０上のブロックＢ０の暗号化（ステップＭＸ１）と、ブロックＢ０の確定／追加ブロックＢ１の生成（ステップＭＸ２）と、の一連の処理手順により行われる。
【００６９】
取引承認手段３２は、メインチェーンＭ０上のブロックＢ０を一方向性関数Ｆ０に基づき暗号化し、ハッシュ値ＭＨを生成する（ステップＭＸ１）。
【００７０】
ハッシュ値生成に際し行われる一方向性変換は、ＲＳＡ方式、ＤＳＡ方式、Ｓｃｈｎｏｒｒ方式等の暗号化方式によって行われる構成が好ましい。該暗号化処理は、複数回の一方向性変換によって行われる構成としてもよいし、該一方向性変換を行う際に、乱数やメタデータを付加する構成としてもよい。
【００７１】
取引承認手段３２は、ハッシュ値ＭＨの生成（ステップＭＸ１）の後、追加ブロックＢ１の生成を行う（ステップＭＸ２）。該追加ブロックＢ１には、該ハッシュ値ＭＨが追加され、チェーン更新に係る処理（ステップＭＸ）は完了する。
【００７２】
図４（ｂ）に示す通り、チェーン更新（ステップＭＸ）におけるハッシュ値ＭＨは、メインチェーンＭ０上のブロックＢ０における、端末署名ＳＧＮ１、所有者署名ＳＧＮ２、譲受者署名ＳＧＮ３、管理者署名ＳＧＮ４、直前のブロックに係るハッシュ値ＭＨ、ユーザ属性情報ＵＭ、ユーザ公開鍵Ｋ２１及びサブチェーンＳ０上のブロックＢ０が、暗号化されることで生成される。このとき、サブチェーンＳ０上のブロックＢ０は、少なくとも、サブチェーンＳ０上のブロックが暗号化されたハッシュ値ＳＨ及び入退場情報ＥＴＲを含む。
【００７３】
一方向性関数Ｆ０に基づいて、前述のブロックＢ０に係る情報の暗号化により得られたハッシュ値ＭＨは、追加ブロックＢ１に追加される。このとき、サブチェーンＳ０上に係る情報も併せて追加ブロックＢ１に追加される構成が好ましい。
【００７４】
なお、取引承認手段３２は、メインチェーンＭ０におけるジェネシスブロックの生成を行う。該ジェネシスブロックには、少なくとも、該管理者署名ＳＧＮ４が暗号化されたハッシュ値ＭＨが追加される。
【００７５】
図５（ａ）は、端末登録／署名（ステップＭ１０）に係る処理フローチャートを示している。
【００７６】
ユーザ端末２において、ユーザ秘密鍵Ｋ２０及びユーザ公開鍵Ｋ２１が参照できない場合（ステップＭ１０１でＮｏ（Ｎ））、端末登録手段２１は、ユーザ秘密鍵Ｋ２０及びユーザ公開鍵Ｋ２１の生成を行う（ステップＭ１０２）。このとき、ユーザ秘密鍵Ｋ２０に係る生成は、乱数や、ユーザ操作により入力された文字列等に基づく構成が好ましい。ユーザ公開鍵Ｋ２１に係る生成は、該ユーザ秘密鍵Ｋ２０に基づいて行われることが好ましい。暗号化生成は、ステップＭＸと同様、暗号化方式の種類に、特に制限はない。
【００７７】
ユーザ秘密鍵Ｋ２０及びユーザ公開鍵Ｋ２１が参照できた場合（ステップＭ１０１でＹｅｓ（Ｙ））、ユーザ秘密鍵Ｋ２０及びユーザ公開鍵Ｋ２１の生成は行われない。
【００７８】
端末登録手段２１は、ユーザ秘密鍵Ｋ２０及びユーザ公開鍵Ｋ２１に係る処理（ステップＭ１０１、Ｍ１０２）の後、端末署名ＳＧＮ１の生成を行う（ステップＭ１０３）。
【００７９】
端末署名ＳＧＮ１の生成では、ユーザ秘密鍵Ｋ２０を用いて、少なくともユーザ端末情報ＵＤが一方向性変換される。なお、ユーザ端末情報ＵＤは、ユーザ端末２を識別するための端末識別子ＵＤＩＤや、電子チケット管理プログラム２０８に個別に割り振られたアプリケーション識別子ＵＡＩＤ等の情報である構成が好ましい。
【００８０】
また、端末署名ＳＧＮ１の生成／追加を行った後、ユーザは、身分証明情報ＩＤを含むユーザ個人情報ＵＰ、ユーザ顔画像ＵＦ及びユーザ生体情報ＵＢの少なくとも１つを含むユーザ属性情報ＵＭを、メインノード３及びサブノード４を含むノード群に対して、送信する（ステップＭ１０４）。送信された該ユーザ属性情報ＵＭは、逐次、格納される。
【００８１】
ユーザ属性情報ＵＭの送信（ステップＭ１０４）の後、端末登録手段２１は、メインチェーンＭ０上のブロックＢ０に対して、該ユーザ個人情報ＵＰ及び該ユーザ顔画像ＵＦに係るリンク等のリファレンス情報を、追加する。このとき、分散型ＫＶＳにおけるＶａｌｕｅとして、該リファレンス情報が格納される構成が好ましい。
【００８２】
端末承認手段３１は、追加された端末署名ＳＧＮ１及びユーザ属性情報ＵＭに係る署名検証を行う（ステップＭ１０５）。該検証では、ユーザ公開鍵Ｋ２１を用いて該端末署名ＳＧＮ１を復号化処理し、ユーザ端末情報ＵＤの妥当性が検証される。また、該検証では、ユーザの身分証明情報ＩＤの妥当性が検証される。該検証により妥当性が確認された場合、ユーザ端末２に対して妥当性確認の通知が行われる。該通知は、分散型ＫＶＳを介して行われてもよい。
【００８３】
なお、実施形態１において、端末署名ＳＧＮ１に係る復号化処理により、端末署名ＳＧＮ１及びユーザ端末２に係る妥当性が確認されることを転機として、端末承認手段３１は、管理者署名ＳＧＮ４を生成する構成としてもよい。
【００８４】
端末署名ＳＧＮ１及びユーザ属性情報ＵＭの妥当性に係る通知が行われることを転機として、端末登録手段２１は、メインチェーンＭ０上のブロックＢ０に対して、ユーザ公開鍵Ｋ２１を追加し、端末署名／登録（ステップＭ１０）を完了する。
【００８５】
図５（ｂ）は、所有者署名ＳＧＮ２及び譲受者署名ＳＧＮ３のメインチェーンＭ０上のブロックＢ０への追加（ステップＭ２０）に係る処理フローチャートを図示している。
【００８６】
チケット譲渡プロセスは、ユーザによる意思入力を転機として、開始される。取引申請手段２２は、まず、ユーザ端末２が有するユーザ秘密鍵Ｋ２０の書き出しに係る判定を行う（ステップＭ２０１）。ユーザ秘密鍵Ｋ２０の書き出しが行われていた場合（ステップＭ２０１でＹｅｓ（Ｙ））、ステップＭ２０１の直前の状態に遷移し、チケット譲渡プロセスに係るあらゆる意思入力の受付は、抑止される。
【００８７】
ユーザ秘密鍵Ｋ２０の書き出しが行われていない場合（ステップＭ２０１でＮｏ（Ｎ））、以降のステップに遷移して、チケットを保有するユーザ（以下、譲渡者とする）のユーザ端末２から、当該ユーザ又は他のユーザ（以下、譲受者とする）が保有する別のユーザ端末２に対して、チケット譲渡に係る処理が実行される。
【００８８】
取引申請手段２２は、ユーザ秘密鍵Ｋ２０に基づいて所有者署名ＳＧＮ２を生成する（ステップＭ２０２）。このとき、所有者署名ＳＧＮ２は、チケット譲渡先である譲受者に係る情報を含む取引内容が暗号化される構成が好ましい。
【００８９】
取引申請手段２２は、所有者署名ＳＧＮ２の生成（ステップＭ２０２）の後、メインチェーン上のブロックＢ０における端末署名ＳＧＮ１を含む電子署名の無効化処理を行う（ステップＭ２０３）。該無効化処理は、分散型ＫＶＳの更新により行われ、該無効化処理が行われた場合、分散型ＫＶＳを介してノード群へ通知される構成が好ましい。該無効化処理による、端末署名ＳＧＮ１の無効化は、後述のチケット入場プロセスに係る入場承認処理の抑止の用に供される。
【００９０】
所有者署名ＳＧＮ２に係る通知が行われた場合、取引承認手段３２は、チケット譲渡に係る譲受者の特定を行う（ステップＭ２０４）。該特定は、所有者署名ＳＧＮ２の復号処理により得られる取引内容に基づいて行われる構成が好ましい。このとき、該取引内容は、チケット譲渡に係る決済履歴を示す情報を含んでいてもよい。
【００９１】
取引承認手段３２は、メインチェーンＭ０上のブロックＢ０における端末署名ＳＧＮ１を含む電子署名の無効化処理に係る通知が行われることを転機として、譲受者署名ＳＧＮ３に係る生成／追加を行う（ステップＭ２０５）。このとき、譲受者署名ＳＧＮ３は、メインノード３が有するユーザ秘密鍵Ｋ２５に基づいて、ノード群により生成される。該ユーザ秘密鍵Ｋ２５は、電子チケット管理システム１における譲渡者及び譲受者が有するユーザ端末２に応じて個別に生成される。
【００９２】
なお、実施形態１では、ユーザ秘密鍵Ｋ２０及びユーザ公開鍵Ｋ２１が、譲受者が有するユーザ端末２において予め生成され、チケット譲渡プロセスの際に、譲受者による意思入力を転機として、該ユーザ秘密鍵Ｋ２０に基づいて、譲受者署名ＳＧＮ３が生成される構成としてもよい。このとき、該ユーザ秘密鍵Ｋ２０は、譲受者が有するユーザ端末２に係る端末署名／登録（ステップＭ１０）において生成されている構成が好ましい。
【００９３】
最後に、譲受者署名ＳＧＮ３に係る生成／追加に係る情報を、分散型ＫＶＳに適用し、譲受者署名ＳＧＮ３に係る通知を行い、所有者署名ＳＧＮ２及び譲受者署名ＳＧＮ３に係る処理（ステップＭ２０）を完了する。
【００９４】
取引承認手段３２は、少なくとも、端末署名ＳＧＮ１、所有者署名ＳＧＮ２及び譲受者署名ＳＧＮ３に基づいて、管理者署名ＳＧＮ４の生成と、メインチェーンＭ０上のブロックＢ０に対する管理者署名ＳＧＮ４の追加を行う（ステップＭ３０）。なお、管理者署名ＳＧＮ４は、メインノード秘密鍵Ｋ３０に基づき生成される。
【００９５】
取引承認手段３２は、ユーザ公開鍵Ｋ２１を用いた復号化処理を通じて、電子署名に係る検証を行い、承認作業を行う。該検証及び承認は、電子チケット管理システムの即時性を担保するために、１以上の限られた特定のノードのみで行われることが好ましい。
【００９６】
管理者署名ＳＧＮ４に係る承認は、メインチェーンＭ０上のハッシュ値の連続性に基づいて行われる。実施形態１における連続性とは、隣接するブロックにおけるハッシュ値を復号化処理した結果と、該ブロックが有する署名等と、の整合性を指す。
【００９７】
メインチェーンＭ０上で、連続性をもたない不正なハッシュ値、若しくは、妥当性が認められない不正な電子署名があった場合、取引承認手段３２は、メインチェーンＭ０上における承認を行わない。このとき、後述のチケット入場プロセスに係る取引承認者署名ＳＧＮ５の生成／追加を行う取引承認手段４１は、サブチェーンＳ０上における承認を行わない。これにより、該チェーンに対応付けられた、電子チケットに係る譲渡／入場を含む取引及び取引に係る意思入力の受付を抑止する。
【００９８】
次に、チケット入場プロセスに係るサブチェーンＳ０上の処理フローチャートについて説明する。実施形態１において、サブチェーンＳ０は、電子チケットに個別に対応付けられており、チケット入場が行われる都度、サブチェーンＳ０上のブロック追加を含むチェーン更新（ステップＳＸ）が行われる。
【００９９】
図３（ａ）に示す通り、サブチェーンＳ０に基づくチケット入場プロセスでは、まず、ユーザ操作による意思入力を転機として、取引申請手段２２による入場申請が行われる（ステップＳ１０）。
【０１００】
次に、入場申請を行ったユーザについて、存在証明プロトコルに基づく検証処理が行われる（ステップＳ２０）。該ユーザ検証処理では、ユーザに係る身元認証プロセスＡ１０及び位置認証プロセスＡ２０が行われる。
【０１０１】
取引承認手段４１は、存在証明プロトコルに基づくユーザ検証処理の結果に基づき、取引承認者署名ＳＧＮ５を生成し、サブチェーンＳ０上のブロックＢ０に追加する（ステップＳ３０）。最後に、サブチェーンＳ０のチェーン更新（ステップＳＸ）が行われることで、チケット入場プロセスは完了される。
【０１０２】
図４（ａ）に示す通り、サブチェーンＳ０のチェーン更新（ステップＳＸ）では、サブチェーンＳ０上のブロックＢ０の暗号化（ステップＳＸ１）と、ブロックＢ０の確定／追加ブロックＢ１の生成（ステップＳＸ２）と、の一連の処理が、取引申請手段２２により行われる。
【０１０３】
取引申請手段２２は、サブチェーンＳ０上のブロックＢ０を、一方向性関数Ｆ０に基づき暗号化し、ハッシュ値ＳＨを生成する（ステップＳＸ１）。
【０１０４】
取引申請手段２２は、ハッシュ値ＳＨの生成（ステップＳＸ１）の後、追加ブロックＢ１の生成を行う（ステップＳＸ２）。該追加ブロックＢ１には、該ハッシュ値ＳＨが追加され、チェーン更新（ステップＳＸ）は完了する。
【０１０５】
ハッシュ値ＳＨは、サブチェーンＳ０上のブロックＢ０における、取引承認者署名ＳＧＮ５と、直前のブロックに係るハッシュ値ＳＨ及び入退場情報ＥＴＲと、が暗号化されることで生成される。
【０１０６】
次に、図２（ａ）に記載のチケット入場プロセスに係る各ステップの詳細を説明する。
【０１０７】
取引申請手段２２は、ユーザ秘密鍵Ｋ２０の書き出しが行われていない場合、入場申請に係るユーザによる意思入力を受け付け、入場申請を開始する（ステップＳ１０）。該入場申請は、分散型ＫＶＳを介して、ノード群に通知される構成としてもよい。
【０１０８】
取引申請手段２２は、入場申請に係るユーザによる意思入力を受け付けることを転機として、身分証明情報ＩＤを示す内容物の提示を、該ユーザに対し指示する。このとき、サブノード４は、顔認証カメラＣＡＭを介し、該内容物を読み取る構成としてもよい。
【０１０９】
なお、実施形態１における、入場申請に係るユーザによる意思入力は、入力装置２０５を介して行われる。このとき、ジャイロセンサーを含むＭＥＭＳ（Ｍｉｃｒｏ  Ｅｌｅｃｔｒｏ  Ｍｅｃｈａｎｉｃａｌ  Ｓｙｓｔｅｍｓ）デバイスが、振動等の外力を検知することを転機として、該意思入力が行われる構成としてもよい。
【０１１０】
また、入場申請に係るユーザに依る意思表示として、ユーザ端末２上で二次元コードが表示処理される構成としてもよい。このとき、該二次元コードがノード群にスキャンされることを転機として、入場申請に係る意思入力が行われる構成としてもよい。
【０１１１】
取引承認手段４１は、入場申請に係る通知が行われることを転機として、該入場申請に対応付けられた電子チケットに係る端末署名ＳＧＮ１に係る妥当性検証を、分散型ＫＶＳの参照と、ユーザ公開鍵Ｋ２１に基づく復号化処理と、を通じ、行う。
【０１１２】
チケット入場プロセスにおいて入場申請を行う際に、端末署名ＳＧＮ１が無効化されている場合、以降のステップに移行しない。
【０１１３】
次に、チケット入場プロセスにおける、存在証明プロトコルに基づくユーザ検証処理（ステップＳ２０）について、図６を交え、説明する。
【０１１４】
図６は、実施形態１における存在証明プロトコルに基づくユーザ検証処理に係る模式図（図６（ａ））と、処理フローチャート（図６（ｂ））と、を示している。
【０１１５】
実施形態１における存在証明プロトコルに基づくユーザ検証処理は、図６（ｂ）に示す通り、顔認証を含む身元認証プロセスＡ１０と、測位による認証を含む位置認証プロセスＡ２０と、を含む。
【０１１６】
実施形態１における位置認証プロセスＡ２０に係る測位は、ユーザ端末２が有する信号受信履歴に基づいて、行われる。
【０１１７】
実施形態１における、メインノード３及びサブノード４は、存在証明プロトコルに基づくユーザ検証処理の用に供される、測位用デバイス及び／又は顔認証用デバイスを、ハードウェア構成に含んでいてもよい。
【０１１８】
ユーザ検証処理は、スマートフォンやタブレット等が有する、Ｂｌｕｅｔｏｏｔｈ  Ｌｏｗ  Ｅｎｅｒｇｙ（登録商標）を含むＢｌｕｅｔｏｏｔｈ（登録商標）通信や、イメージセンサー等による撮像結果に基づいて、行われる構成が好ましい。
【０１１９】
図６（ａ）に示す通り、位置認証プロセスＡ２０に係る測位は、１以上の一方向通信用ビーコンＢＣＮ、及び／又は、１以上の双方向通信用ルーターＲＴＲにより行われる。また、本人確認は、顔認証カメラＣＡＭにより撮像されたユーザ顔画像に基づき行われる。
【０１２０】
身元認証プロセスＡ１０では、顔認証カメラＣＡＭにより撮像されたユーザ顔画像と、メインチェーンＭ０上のブロックＢ０におけるユーザ属性情報ＵＭに含まれるユーザ顔画像ＵＦとの、類似度検出を、サブノード４に搭載されたＤＬＩＢ等の画像処理ライブラリを用いたストリーミング処理により行う。
【０１２１】
身元認証プロセスＡ１０では、さらに、取引承認手段４１が、提示されたユーザの身分証明情報ＩＤと、メインチェーンＭ０におけるブロックＢ０上のユーザ属性情報ＵＭに含まれるユーザ個人情報ＵＰと、を照合し、該身分証明情報ＩＤの妥当性検証を行う。
【０１２２】
身分証明情報ＩＤを示す内容物の提示において、該身分証明情報ＩＤを機械学習ライブラリにより読み取り、記載内容に基づくハッシュ値と、ユーザ個人情報ＵＰに基づくハッシュ値を照合し、身元認証プロセスＡ１０に係る本人確認を行う構成としてもよい。
【０１２３】
なお、身元認証プロセスＡ１０に係る本人確認は、指紋、声紋、虹彩及び静脈パターンの少なくとも１つを含む生体情報に基づいて行われる構成としてもよい。このとき、該生体情報のセンシングの用に供されるセンサーデバイスは、メインノード３、又は、サブノード４とネットワーク接続された状態で設置される。
【０１２４】
位置認証プロセスＡ２０において、ユーザ端末２は、会場内に設置された１以上の一方向通信用ビーコンＢＣＮより受け取った近距離無線信号に係るＲＳＳＩ（Ｒｅｃｅｉｖｅｄ  Ｓｉｇｎａｌ  Ｓｔｒｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ）値、及び／又は、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）に基づき、位置情報を取得する。
【０１２５】
取引申請手段２２は、一方向通信用ビーコンＢＣＮを介して受信した信号に基づく位置情報を暗号化することでハッシュ値を生成し、ノード群に送信する。このとき、該ハッシュ値は、サブチェーンＳ０における入退場情報ＥＴＲに含まれる構成としてもよい。取引承認手段４１は、該ハッシュ値に基づき、該位置情報の妥当性検証を行う。
【０１２６】
また、位置認証プロセスＡ２０において、ユーザ端末２は、双方向通信用ルーターＲＴＲを介して位置情報の取得を行う。このとき、双方向通信用ルーターＲＴＲが情報伝送の用に供する媒体は、ミリ波帯を含む電波のみならず、超音波、可視光波等を含む。
【０１２７】
イベント会場で実施されるイベント内容の多様性を鑑みれば、測位のための無線通信の用に供される媒体もまた、多様であることが望ましく、会場に設置される通信媒体の種別並びにその組み合わせに、特に制限はない。
【０１２８】
なお、実施形態１では、衛星通信によるＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）測位により、位置認証プロセスＡ２０が行われる構成としてもよい。
【０１２９】
取引申請手段２２は、双方向通信用ルーターＲＴＲを介した得られた位置情報に基づきハッシュ値を生成し、ノード群に送信する。このとき、該ハッシュ値は、サブチェーンＳ０における入退場情報ＥＴＲに含まれる構成としてもよい。取引承認手段４１は、該ハッシュ値に基づき、該位置情報の妥当性検証を行う。
【０１３０】
存在証明プロトコルに基づくユーザ検証処理に係る測位の用に供される一方向通信用ビーコンＢＣＮ及び双方向通信用ルーターＲＴＲと、顔認証の用に供される顔認証カメラＣＡＭとにより取得される情報は、電子チケットに対応付けられたイベント会場内のプライベートネットワークＮＷ２、又は、パブリックネットワークＮＷ１を介して伝送される。
【０１３１】
存在証明プロトコルに基づくユーザ検証処理に係る身元認証プロセスＡ１０及び位置認証プロセスＡ２０が行われる際、センサーデバイス群、ユーザ端末２及びサブノード４が、パブリックネットワークＮＷ１に接続されていない場合、プライベートネットワークＮＷ２を介して、分散型ＫＶＳの更新等を行うことが好ましい。
【０１３２】
実施形態１における、位置認証プロセスＡ２０に係る位置情報は、ユーザ端末２が有する信号受信履歴に基づき得られる移動経路に係る情報を、含む構成としてもよい。
【０１３３】
次に、チケット入場プロセスにおける、取引承認者署名ＳＧＮ５の生成／追加（ステップＳ３０）について説明する。
【０１３４】
取引承認手段４１は、存在証明プロトコルに基づくユーザ検証処理（ステップＳ２０）の結果に基づき、サブノード秘密鍵Ｋ４０を用いて取引承認者署名ＳＧＮ５を生成する。
【０１３５】
取引承認者署名ＳＧＮ５の生成に際し、取引承認手段４１は、少なくとも、存在証明プロトコルに基づくユーザ検証処理により得られた、ユーザ端末２の位置情報、及び／又は、顔画像に係る類似度検出結果に基づいて、ユーザの所在を判定し、取引承認者署名ＳＧＮ５を、サブチェーンＳ０上のブロックＢ０に追加する。
【０１３６】
実施形態１における、存在証明プロトコルに基づく検証処理によるチケット所有者の認証は、該検証の過程で得られる各種情報に対する重み付けを経て行われる構成としてもよい。例えば、重み付けされた各種情報に信頼度に係るパラメータを付与し、該パラメータの総和が、所定の閾値を上回った場合に、該検証による結果を正、つまり、イベント会場におけるチケット所有者の所在を認める。
【０１３７】
取引承認手段４１により、取引承認者署名ＳＧＮ５がサブチェーンＳ０上のブロックＢ０に追加されることを転機として、取引申請手段２２は、サブチェーンＳ０におけるブロック生成／追加を含む更新処理（ステップＳＸ）を行う。分散型ＫＶＳを通じて、サブノード４に該更新処理に係る通知が行われることで、チケット入場プロセスは完了し、ユーザに対する入場許可に係る情報が決定される。このとき、該決定に応じて、電子もぎりの態様で、ユーザによるイベント会場への入場を管理する構成としてもよい。
【０１３８】
サブチェーンＳ０上のチェーン更新（ステップＳＸ）において、取引申請手段２２は、入退場情報ＥＴＲの更新を行う。さらに、サブチェーンＳ０上のブロックＢ０に係る情報は、分散型ＫＶＳにおいて、入退場情報ＥＴＲをＫｅｙとして、サブチェーンＳ０上のブロックＢ０における電子署名又は存在証明プロトコルに基づくユーザ検証処理に係る各種情報をＶａｌｕｅとして、格納される。これにより、サブチェーンＳ０における、ブロック分岐を含むブロックの同時生成を抑止する。
【０１３９】
実施形態１における、チケット譲渡プロセス及びチケット入場プロセスは、１の電子チケットに対し、複数の入場者に係る情報を示す１のユーザが対応付けられる構成としてもよい。このとき、チケット入場プロセスにおける入場許可は、複数の入場者に対し個別に決定される。
【０１４０】
１の電子チケットに対し、複数の入場者に係る情報を示す１のユーザが対応付けられている場合、身元認証プロセスＡ１０に係る顔認証は、該複数の入場者の内の特定の入場者の顔画像を撮像し、ユーザ顔画像ＵＦとの類似度検出を行う構成が好ましい。このとき、端末登録／認証（ステップＭ１０）の際に、特定の入場者に係るユーザ顔画像ＵＦが登録される。
【０１４１】
実施形態１において、ユーザ秘密鍵Ｋ２０の書き出しは、該書き出しに係る意思入力を転機として、二次元コード、又は、文字コードの態様で、表示処理、又は、印刷処理される。
【０１４２】
ユーザ秘密鍵Ｋ２０が書き出された場合、異なるユーザ端末２に対し、該ユーザ秘密鍵Ｋ２０を入力し、再度、端末署名ＳＧＮ１に係る生成／追加（ステップＭ１０）を行い、端末承認手段３１による端末認証が完了することで、書き出される直前の該ユーザ秘密鍵Ｋ２０に対応付けられた電子チケットに係る譲渡／入場が可能となる。そのため、ユーザ属性情報ＵＭの登録を経て身元情報が登録されていない場合、実施形態１におけるユーザ秘密鍵Ｋ２０を用いた電子署名に基づく承認処理は、完了しない。
【０１４３】
実施形態１におけるサブチェーンＳ０上に係る更新処理は、ユーザによるイベント会場からの退場の際に行われる構成としてもよい。
【０１４４】
＜実施形態２＞
以下、本発明の実施形態２に係る電子チケット管理システム１について説明する。なお、実施形態１と同様の構成については、同様の符号を付してその説明を省略する。
【０１４５】
図７に示す通り、実施形態２におけるノード群５は、メインノード３及びサブノード４に係る機能を併せ持つ。また、データベースＤＢ５は、実施形態１におけるデータベースＤＢ３及びＤＢ４が有する各種情報を、有する。
【０１４６】
ノード群５は、パブリックネットワークＮＷ１に接続され、メインチェーンＭ０及びサブチェーンＳ０上のブロック生成／追加を含む、更新処理が即時、反映されることが好ましい。このとき、存在証明プロトコルに基づくユーザ検証処理に係るセンサーデバイス群は、該ノード群５のハードウェア構成に含まれてもよい。
【０１４７】
＜実施形態３＞
以下、本発明の実施形態３に係る電子チケット管理システム１について説明する。なお、実施形態１又は２と同様の構成については、同様の符号を付してその説明を省略する。
【０１４８】
実施形態３におけるメインチェーンＭ０及びサブチェーンＳ０は、決済保証プロセスの用に供される。本発明における決済保証プロセスとは、チケット入場に伴い、保証金をデポジットし、イベント会場内における少額決済に係る取引履歴を記録し、イベント会場からの退場を転機として、該取引履歴に基づき決済処理を行う、一連の処理を指す。なお、実施形態３における少額決済は、支払額が該保証金を上回らない決済を指す。
【０１４９】
決済保証プロセスにおける保証金のデポジットは、種々の法定通貨又は暗号通貨を用いた電子商取引に基づき行われる構成が好ましい。このとき、該電子商取引に用いられる通貨の種別に、特に制限はない。
【０１５０】
実施形態３では、メインチェーンＭ０は、デポジット処理が行われる都度、更新される構成が好ましい。
【０１５１】
実施形態３における決済保証プロセスは、メインチェーンＭ０上で、保証金のデポジット処理に係る承認を行うための、電子署名の生成等が行われ、サブチェーンＳ０上で、電子チケットに対応付けられたイベント会場内で行われる少額決済に係る取引履歴を管理するための、電子署名の生成等が行われる。
【０１５２】
実施形態３における電子チケット管理システム１に係るハードウェア構成図及び機能ブロック図は、実施形態１又は２と同様の構成を有する。
【０１５３】
図８は、実施形態３における決済保証プロセスに係る処理フローチャートと、メインチェーンＭ０及びサブチェーンＳ０が有する各種情報と、を図示している。
【０１５４】
図８（ａ）が示す通り、実施形態３におけるチェーン更新（ステップＭＸ）は、端末登録手段２１による端末署名／登録（ステップＭ１０）、取引申請手段２２による所有者署名の生成／追加（ステップＭ２１）及び取引承認手段３２による管理者署名の生成／追加（ステップＭ３０）を経て、行われる。
【０１５５】
実施形態３におけるチェーン更新（ステップＭＸ）は、実施形態１又は２におけるチェーン更新（ステップＭＸ）と同様の処理手順を経て行われる構成が好ましい。ただし、メインチェーンＭ０上のブロックＢ０が有する各種情報は、図８が示す構成に準拠する。
【０１５６】
実施形態３における所有者署名の生成／追加（ステップＭ２１）は、実施形態１又は２における所有者署名／譲受者署名の生成／追加（ステップＭ２０）に含まれる処理手順の内、譲受者署名ＳＧＮ３に係る処理手順を除外した、一連の処理手順を指す。ただし、所有者署名ＳＧＮ２の生成の際に、暗号化される取引内容は、前述のデポジットに係る電子商取引履歴を示す情報である構成が好ましい。
【０１５７】
実施形態３における管理者署名の生成／追加（ステップＭ３０）において、所有者署名ＳＧＮ２に係る復号化処理が行われた際、メインノード３は、所有者署名ＳＧＮ２に含まれる前述の電子商取引履歴に係る情報の妥当性を検証し、管理者署名ＳＧＮ４を生成する構成が好ましい。このとき、該電子商取引履歴に係る取引先が有する端末で生成された電子署名が、メインチェーンＭ０上のブロックＢ０に含まれる構成としてもよい。
【０１５８】
実施形態３において、サブチェーンＳ０は、イベント会場内でユーザによる少額決済が行われる都度、更新される構成が好ましい。
【０１５９】
実施形態３における、サブチェーンＳ０上のチェーン更新（ステップＳＸ）は、取引申請手段２２による決済申請（ステップＳ１０）、取引承認手段４１によるユーザ検証処理（ステップＳ２０）及び、取引承認手段４１による取引承認者署名ＳＧＮ５の生成／追加を経て行われる構成が好ましい。このとき、該チェーン更新（ステップＳＸ）は、取引申請手段２２により行われる。
【０１６０】
実施形態３における、決済申請に係るユーザ操作は、実施形態１又は２における入場申請に係るユーザ操作と同様の手順を有する構成が好ましい。このとき、取引申請手段２２が、二次元コード等の態様で、決済申請に係る情報を表示処理する構成としてもよい。
【０１６１】
実施形態３におけるメインチェーンＭ０上のブロックＢ０は、端末署名ＳＧＮ１と、所有者署名ＳＧＮ２と、管理者署名ＳＧＮ４と、ユーザ属性情報ＵＭと、ユーザ公開鍵Ｋ１１と、メインチェーンＭ０上のブロックが暗号化されたハッシュ値ＭＨと、サブチェーンＳ０上のブロックＢ０と、を有する。
【０１６２】
実施形態３におけるサブチェーンＳ０上のブロックＢ０は、サブノード秘密鍵Ｋ４０に基づいて生成される取引承認者署名ＳＧＮ５と、保証金情報ＤＰＴと、サブチェーンＳ０上のブロックが暗号化されたハッシュ値ＳＨと、を有する。該保証金情報ＤＰＴは、少額決済に係る取引履歴に基づいて算出された保証金残高に係る情報を示す。
【０１６３】
実施形態３におけるユーザ検証処理（ステップＳ２０）は、存在証明プロトコルに基づき行われる。実施形態３では、イベント会場内で行われる少額決済を簡便に管理するために、該ユーザ検証処理は、身元認証プロセスＡ１０及び位置認証プロセスＡ２０において検証される各種情報の内、少なくとも一部に基づいて行われる構成が好ましい。
【０１６４】
取引承認手段４１により、取引承認者署名ＳＧＮ５の生成／追加（ステップＳ３０）が行われる際、メインチェーンＭ０上のブロックＢ０が有する端末署名ＳＧＮ１と、サブチェーンＳ０上のブロックＢ０が有する保証金情報と、ハッシュ値ＳＨに対する復号化処理を経て得られた決済履歴に基づく構成が好ましい。
【０１６５】
実施形態３における、取引承認手段３２及び４１は、それぞれ、メインチェーンＭ０又はサブチェーンＳ０上のブロックＢ０が有するハッシュ値ＭＨ、ＳＨに係る連続性を検証し、電子署名の生成／追加に係る処理を行う。
【０１６６】
実施形態３において、取引承認手段３２は、ユーザがイベント会場から退場することを転機として、メインチェーンＭ０及びサブチェーンＳ０に係る更新処理を抑止する。このとき、取引承認手段３２は、該抑止を示す情報とメインノード秘密鍵Ｋ３０に基づき、管理者署名を生成する構成としてもよい。
【０１６７】
実施形態３において、少額決済に係る承認並びに取引履歴の格納の用に供されるサブチェーンＳ０上のブロックＢ０に係る情報は、実施形態１又は２のおけるサブチェーンＳ０上のブロックＢ０に含まれる構成としてもよい。このとき、メインチェーンＭ０上のブロックＢ０は、チケット譲渡プロセスに係る各種情報と、保証金に係る電子商取引履歴を示す各種情報と、を有する構成が好ましい。また、少額決済管理の用に供されるサブチェーンＳ０に係る情報と、入退場管理の用に供されるサブチェーンＳ０に係る情報とが、メインチェーンＭ０上のブロックに含まれる構成としてもよい。
【０１６８】
本発明によれば、複数のプライベートチェーンと、センサフュージョンと、に基づいて、改竄耐性と、即時性と、を有する電子チケット管理システムを、実現できる。
【０１６９】
本発明によれば、改札機等の大型装置を要さないチケット入場管理が可能となる。
【０１７０】
本発明によれば、ユーザによるイベント参加に係る、チケット購入／入場／会場内決済に係る処理を、改竄耐性と即時性とを有するプライベートチェーン上で管理することができ、好適なイベント運営に寄与できる。
【符号の説明】
【０１７１】
１  電子チケット管理システム
２  ユーザ端末
３  メインノード
４  サブノード
５  ノード群
１０  コンピュータ装置
２１  端末登録手段
２２  取引申請手段
３１  端末承認手段
３２  取引承認手段
４１  取引承認手段
ＮＷ１  パブリックネットワーク
ＮＷ２  プライベートネットワーク
ＤＢ２、ＤＢ３、ＤＢ４、ＤＢ５  データベース
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  記録装置
２０４  通信装置
２０５  入力装置
２０６  出力装置
２０７  オペレーティングシステム
２０８  電子チケット管理プログラム
Ｍ０  メインチェーン
Ｓ０  サブチェーン
ＳＧＮ１  端末署名
ＳＧＮ２  所有者署名
ＳＧＮ３  譲受者署名
ＳＧＮ４  管理者署名
ＳＧＮ５  取引承認者署名
Ｋ２０、Ｋ２５  ユーザ秘密鍵
Ｋ２１、Ｋ２６  ユーザ公開鍵
ＵＤ  ユーザ端末情報
ＵＤＩＤ  端末識別子
ＵＡＩＤ  アプリケーション識別子
ＵＭ  ユーザ属性情報
ＵＰ  ユーザ個人情報
ＵＦ  ユーザ顔画像
ＵＢ  ユーザ生体情報
Ｋ３０  メインノード秘密鍵
Ｋ３１  メインノード公開鍵
Ｋ４０  サブノード秘密鍵
Ｋ４１  サブノード公開鍵
ＭＨ、ＳＨ  ハッシュ値
Ｂ０  ブロック
Ｂ１  追加ブロック
Ｆ０  一方向性関数
ＴＣＫ  電子チケット識別情報
ＥＴＲ  入退場情報
ＤＰＴ  保証金情報
Ａ１０  身元認証プロセス
Ａ２０  位置認証プロセス
一方向通信用ビーコン  ＢＣＮ
双方向通信用ルーター  ＲＴＲ
顔認証カメラ  ＣＡＭ
身分証明情報  ＩＤ
【図１】
2020098632.tif 000003
【図２】
2020098632.tif 000004
【図３】
2020098632.tif 000005
【図４】
2020098632.tif 000006
【図５】
2020098632.tif 000007
【図６】
2020098632.tif 000008
【図７】
2020098632.tif 000009
【図８】
2020098632.tif 000010