JP7456742B2 - 電子チケット管理方法及び電子チケット管理プログラム - Google Patents

Description

本発明は、電子チケット管理方法及び電子チケット管理プログラムに関する。

何等かのサービスを受けるために、予約手続きや購入手続き等を行ってチケットを入手し、サービスの提供を受ける際に当該チケットをサービス提供者に提示等することが行われている。このようなチケットは紙等により物理的に実現されることが多いが、近年では、電子データとして電磁的方法に実現されることもある。なお、電磁的方法に実現されたチケットのことを「電子チケット」と呼ぶこともある。

電子データはコピー等が容易であるため、適切な防止策が施されない場合、電子チケットは不正利用や不正取引等が行なわれ易いという課題がある。この課題に関連する従来技術として、例えば、特許文献１に記載されている技術や特許文献２に記載されている技術等がある。

特開２００２－１４９８８７号公報 特開２０１１－７６５２０号公報

ところで、紙等の物理的に実現されるチケットは様々な業者（例えば、チケット販売業者等）間で転々流通される可能性がある。これに対して、上記の従来技術では、電子チケットが様々業者間で転々流通されることは想定されていなかった。また、これらの業者の中には電子チケットの発行元との間に必ずしも信頼関係があるとは限らない業者が含まれている可能性があり、電子チケットの不正利用や不正取引等が行われる危険性がある。このため、電子チケットの自由な流通を実現しつつ、その不正利用や不正取引等を防止する仕組みが必要である。

本発明の実施形態は、上記の点に鑑みてなされたもので、電子チケットの自由な流通を実現すると共に、電子チケットの不正利用及び不正取引を防止することを目的とする。

上記目的を達成するため、本実施形態に係る電子チケット管理方法は、電子チケットの利用に応じてサービスを提供する提供者の提供者端末と、前記電子チケットを利用して前記サービスを享受する享受者の利用者端末と、前記電子チケットを販売又は転売する販売者の販売者端末とが含まれる電子チケット管理システムにおける電子チケット管理方法であって、前記提供者端末が、前記提供者を識別するアドレス値を所有者に指定したトークンで表される電子チケットを発行する発行手順と、前記利用者端末又は前記販売者端末が、前記享受者又は前記販売者を識別するアドレス値を新たな所有者に指定した第１のトランザクションをブロックチェーンネットワークに送信することで、前記電子チケットの所有権を前記享受者又は前記販売者に移転する移転手順と、前記利用者端末が、前記サービスの享受を受ける場合に、前記享受者が所有する電子チケットを利用済みとするための第２のトランザクションを前記ブロックチェーンネットワークに送信することで、前記電子チケットを利用する利用手順と、を有することを特徴とする。

電子チケットの自由な流通を実現すると共に、電子チケットの不正利用及び不正取引を防止することができる。

本実施形態に係る電子チケット管理システムの全体構成の一例を示す図である。 実施例１におけるチケット発行及びチケット購入の流れの一例を示す図（その１）である。 実施例１におけるチケット発行及びチケット購入の流れの一例を示す図（その２）である。 実施例１におけるチケット利用の流れの一例を示す図である。 実施例２におけるチケット利用の流れの一例を示す図（その１）である。 実施例２におけるチケット利用の流れの一例を示す図（その２）である。 実施例３におけるチケット発行及びチケット購入の流れの一例を示す図（その１）である。 実施例３におけるチケット発行及びチケット購入の流れの一例を示す図（その２）である。 実施例３におけるチケット利用の流れの一例を示す図（その１）である。 実施例３におけるチケット利用の流れの一例を示す図（その２）である。 二次元コード作成時におけるデータ圧縮の一例を説明するための図である。

以下、本発明の実施形態（以降、「本実施形態」とも表す。）について説明する。本実施形態では、電子チケットの自由な流通を実現すると共に、電子チケットの不正利用及び不正取引を防止することが可能な電子チケット管理システム１について説明する。なお、本実施形態では、電子チケットを単に「チケット」とも表す。

本実施形態に係る電子チケット管理システム１では、電子チケットの自由な流通と不正利用及び不正取引の防止とを実現するために、ブロックチェーン技術（又は「分散台帳技術」とも呼ばれる。）を利用したプラットフォームを用いる。ブロックチェーン技術を利用したプラットフォームの具体例としては、Ethereum（登録商標）が挙げられる。本実施形態に係る電子チケット管理システム１は、一例として、Ethereumを用いて実現されているものとする。ただし、これは一例であって、本実施形態に係る電子チケット管理システム１は、任意のブロックチェーン技術を利用したプラットフォーム（例えば、Hyperledger（登録商標） Fabric等）を用いて実現することが可能である。

ブロックチェーン技術の主な特徴としては、以下の（１）～（５）が挙げられる。

（１）システム（つまり、ブロックチェーン技術を利用したプラットフォームを用いて実現されたシステム）の利用者は、公開鍵暗号に基づいて生成可能なアドレス値と呼ばれる識別子で区別される。

（２）共有情報（つまり、システム内で共有される情報）の内容を更新するためには、トランザクションの作成及び送信する必要がある。なお、トランザクションの作成を「トランザクション発行」と呼ぶこともある。

（３）トランザクションには、秘密鍵に基づく電子署名を付加する必要がある。電子署名が付加されることにより、特定のトランザクションが、どのアドレス値の利用者によって作成されたのかを、システムの参加者全員により検証される。

（４）スマートコントラクトと呼ばれる仕組みを利用することができる。スマートコントラクトとは、トランザクションに対して共有情報をどのように更新するか（共有情報を更新しない場合も含む。）という手続きが定義されたプログラムであり、その手続きは事前にシステムの参加者全員で合意される必要がある。スマートコントラクトがデプロイ（つまり、利用可能な状態になる）された場合、当該スマートコントラクトにはアドレス値が付与される（なお、Hyperledger Fabricの場合はChaincode IDが付与される。）。

（５）有効なトランザクションをどの順でスマートコントラクトにより処理するかを、システムの参加者全員で最終的に合意を取ることが可能である。このため、或る程度の時間を掛けることで、システムの参加者全員が確実に同一の情報を共有することができる。なお、どの程度の時間を掛ける必要があるかは合意形成アルゴリズムによって異なるが、数秒から数十秒程度が一般的である。

上記の（１）～（５）の特徴により、ブロックチェーン技術を利用したプラットフォームを用いてシステムを実現することで、参加者間に必ずしも信頼関係があるとは限らない場合であっても、トランザクションの発行者を検証した上で、情報を共有することが可能になる。

ここで、Ethereumにおけるスマートコントラクトの規格の１つとして、ERC721と呼ばれる規格が知られている。ERC721はスマートコントラクト内で代替不可能なトークン（NFT：Non-Fungible Token）を扱えるようにした規格であり、ERC721を用いることでトークンの所有権等を管理することができるようになる。トークンには所有権を有するユーザ（以降、「所有者」とも表す。）を示すアドレス値を格納するためのデータ領域（以降、「所有者格納領域」とも表す。）があり、この所有者格納領域に格納されているアドレス値を書き換えるためには、現時点の所有者等が、新たな所有者を示すアドレス値を指定したトランザクションを発行及び送信する必要がある。所有者格納領域に格納されているアドレス値が、新たな所有者を示すアドレス値に書き換わることで、新たな所有者は所有権を獲得することなり、元の所有者は所有権を失うことなる。

そこで、本実施形態に係る電子チケット管理システム１では、ERC721に準拠したスマートコントラクトを利用して、電子チケットをトークンにより実現する。これにより、必ずしも互いに信頼関係があるとは限らない者の間における電子チケットの自由な流通を実現しつつ、電子チケットの二重譲渡等の不正取引を防止することが可能となる。また、電子チケットを利用する際にその所有権等をサービス提供者が確認することで、電子チケットの不正利用を防止することが可能になる。

なお、電子チケットの利用によって享受可能なサービスは特定のサービスに限定されず、任意のサービスに対して適用可能である。電子チケットの利用によって享受可能なサービスの典型的な例としては、コンサート鑑賞、映画鑑賞、遊園地や動物園等のテーマパークへの入場、テーマパークにおけるアトラクション体験、飲食店における飲食物の提供、交通機関（例えば、電車、バス、タクシー、飛行機等）の利用、デジタルコンテンツ（例えば、音楽ファイル、動画ファイル等）の提供等が挙げられる。また、電子チケットの利用によってサービスを享受する場合以外にも、例えば、電子チケットの利用によって、指定された物品（例えば、景品等）が引き渡される場合に対しても適用可能である。

＜電子チケット管理システム１の全体構成＞
本実施形態に係る電子チケット管理システム１の全体構成について、図１を参照しながら説明する。図１は、本実施形態に係る電子チケット管理システム１の全体構成の一例を示す図である。

図１に示すように、本実施形態に係る電子チケット管理システム１には、１以上のチケット利用端末１０と、１以上のチケット発行端末２０と、１以上のチケット確認端末３０と、１以上のチケット販売端末４０とが含まれる。また、これらの各端末はP2P（Peer to Peer）のブロックチェーンネットワーク５０を形成しているノードに接続されている。

チケット利用端末１０は、電子チケットを利用してサービスを享受するチケット利用者が使用する端末である。チケット利用者は、チケット利用端末１０を用いて、電子チケットを購入したり、電子チケットを利用したりすることができる。チケット利用端末１０としては、例えば、スマートフォン、タブレット端末、携帯型ゲーム機器、ウェアラブルデバイス、ＰＣ（パーソナルコンピュータ）等の各種端末を用いることができる。

ここで、チケット利用端末１０は、機能部として、利用処理部１０１を有する。利用処理部１０１は、例えば、チケット利用端末１０にインストールされた１以上のプログラムが、ＣＰＵ（Central Processing Unit）等のプロセッサに実行させる処理により実現される。

利用処理部１０１は、電子チケットの購入に関する処理や電子チケットの利用に関する処理を実行する。なお、電子チケットの購入とは、例えば、電子チケットの購入の申し込みやその代金の決済等により電子チケットの所有権を自身に移転させることである。また、電子チケットの利用とは、サービスを享受するために電子チケットをサービス提供者に提示等することである。

チケット発行端末２０は、電子チケットの発行や販売等を行うと共に、この電子チケットの利用と引き換えにサービスを提供するサービス提供者が使用する端末である。サービス提供者は、チケット発行端末２０を用いて、電子チケットの発行や販売を行うことができる。チケット発行端末２０としては、例えば、スマートフォン、タブレット端末、ＰＣ、汎用サーバ等の各種端末を用いることができる。

ここで、チケット発行端末２０は、機能部として、発行処理部２０１と、販売処理部２０２とを有する。これらの各機能部は、例えば、チケット発行端末２０にインストールされた１以上のプログラムがプロセッサに実行させる処理により実現される。

発行処理部２０１は、電子チケットの発行に関する処理を実行する。販売処理部２０２は、電子チケットの販売に関する処理を実行する。なお、電子チケットの発行とは新たな電子チケットを作成することである。また、電子チケットの販売とは、例えば、電子チケットの購入の申し込みやその代金の決済等に応じて、電子チケットの所有権を販売者から購入者に移転することである。

チケット確認端末３０は、サービス提供者が使用する端末である。サービス提供者は、チケット確認端末３０を用いて、チケット利用者が電子チケットを利用する際にその所有権等を確認することができる。チケット確認端末３０としては、例えば、スマートフォン、タブレット端末、ＰＣ等の各種端末を用いることができる。ただし、これに限られず、チケット確認端末３０は、例えば、サービスを提供する施設等の入口（例えば、テーマパークの入口、コンサート会場の入口、駅のホームへの入口等）に設置等されるゲート装置等であってもよい。

ここで、チケット確認端末３０は、機能部として、確認処理部３０１を有する。確認処理部３０１は、例えば、チケット確認端末３０にインストールされた１以上のプログラムがプロセッサに実行させる処理により実現される。

確認処理部３０１は、電子チケットの確認に関する処理を実行する。なお、電子チケットの確認とは、電子チケットが利用可能であるか否かを確認することであり、例えば、電子チケットの所有者の確認等が含まれる。ただし、電子チケットの所有者の確認以外にも、例えば、電子チケットの有効期限を過ぎていないか否かの確認等が含まれていてもよい。

チケット販売端末４０は、サービス提供者や他のチケット販売者から電子チケットを購入して、電子チケットの販売や転売等を行うチケット販売者が使用する端末である。チケット販売者は、チケット販売端末４０を用いて、電子チケットの販売（転売も含む。）を行うことができる。チケット販売端末４０としては、例えば、スマートフォン、タブレット端末、ＰＣ、汎用サーバ等の各種端末を用いることができる。なお、チケット販売者は電子チケットの販売や転売を行う不特定の事業者のことであり、サービス提供者との間で信頼関係があるとは限らない者（例えば、サービス提供者との間で何等の契約関係もないチケット転売業者等）も含み得るものとする。

ここで、チケット販売端末４０は、販売処理部４０１を有する。販売処理部４０１は、例えば、チケット販売端末４０にインストールされた１以上のプログラムがプロセッサに実行させる処理により実現される。

販売処理部４０１は、電子チケットの購入に関する処理や電子チケットの販売に関する処理を実行する。

なお、図１に示す電子チケット管理システム１の構成は一例であって、他の構成であってもよい。例えば、全ての電子チケットをサービス提供者が販売する場合には、チケット販売端末４０が含まれていなくてもよい。また、チケット発行端末２０は、発行処理部２０１を有する端末と、販売処理部２０２を有する端末とに分けられてもよい。

また、チケット発行端末２０及びチケット確認端末３０を使用するサービス提供者には、サービス提供者自身の他に、サービス提供者との間で契約を締結している等により相互に信頼関係を有する者が含まれていてもよい。具体的には、サービス提供者には、サービス提供者の代理人や委託先、協力会社、関連会社等が含まれていてもよい。

［実施例１］
以降では、実施例１について説明する。

＜実施例１におけるチケット発行及びチケット購入の流れ（その１）＞
まず、サービス提供者が電子チケットを発行し、この電子チケットをチケット利用者が購入する場合の流れについて、図２を参照しながら説明する。図２は、実施例１におけるチケット発行及びチケット購入の流れの一例を示す図（その１）である。

チケット発行端末２０の発行処理部２０１は、新たな電子チケットを発行する（ステップＳ１０１）。発行処理部２０１は、事前にデプロイされたERC721に準拠したスマートコントラクトにより、電子チケット（つまり、ERC721に準拠したトークン（NFT））を発行することができる。このとき、発行処理部２０１は、全ての電子チケットの所有者をサービス提供者とする（つまり、全ての電子チケットの所有者格納領域に、サービス提供者のアドレス値を格納する。）。これにより、所有者がサービス提供者の電子チケットが発行される。なお、電子チケットの総発行数は、サービス提供者により決められた任意の数とすればよい。

なお、上記のステップＳ１０１は、例えば、或る特定のサービスを享受するための電子チケットを発行する際に一度実行されればよい。また、例えば、他の特定のサービスを享受するための電子チケットを発行する際には、この電子チケットに対応するスマートコントラクトを作成し、再度、上記のステップＳ１０１を実行すればよい。

チケット利用端末１０の利用処理部１０１は、チケット発行端末２０に対して電子チケットの購入要求を行う（ステップＳ１０２）。電子チケットの購入要求は任意の方法で行なえばよいが、例えば、チケット利用端末１０が備えるＷｅｂブラウザや専用のチケット購入アプリケーション等を用いることで電子チケットの購入要求をチケット発行端末２０に対して送信すればよい。ただし、これは一例であって、必ずしもチケット利用端末１０が購入要求を行う必要はない。例えば、チケットセンター等の窓口において、チケット利用者がチケット販売者に対して電子チケットの購入申し込みを行い、これに対してチケット販売がチケット発行端末２０を操作することで電子チケットの購入要求が行われてもよい。

なお、チケット利用者の購入要求に対してチケット販売者がその承諾（及び、必要に応じて購入代金の決済等）を行った場合、電子チケットがチケット販売者からチケット利用者に販売されることになる（すなわち、チケット利用者は当該電子チケットを購入することになる。）。上記のステップＳ１０２で電子チケットが購入された場合、チケット発行端末２０は、この電子チケットを購入したチケット利用者のアドレス値（又は、アドレス値を特定するための情報）を取得する。このとき、チケット発行端末２０は、任意の方法でチケット利用者のアドレス値（又は、アドレス値を特定するための情報）を取得すればよい。例えば、チケット利用端末１０からチケット発行端末２０にアドレス値（又は、アドレス値を特定するための情報）が送信されてもよいし、チケット発行端末２０に対してアドレス値（又は、アドレス値を特定するための情報）の入力操作が行われてもよいし、メール等により事前又は事後にアドレス値（又は、アドレス値を特定するための情報）がチケット発行端末２０に通知されてもよい。チケット利用者のアドレス値を特定するための情報としては、アドレス値と対応付けられた任意の情報を用いることが可能であるが、例えば、メールアドレス、ユーザＩＤ、電話番号等を用いることが可能である。

チケット発行端末２０の販売処理部２０２は、電子チケットの所有権を移転させるためのトランザクション（以降、「チケット移転トランザクション」とも表す。）を作成する（ステップＳ１０３）。このチケット移転トランザクションは、電子チケット（つまり、トークン）の所有者格納領域に格納されているアドレス値を、新たな所有者のアドレス値に更新（書き換える）ためのトランザクションである。したがって、販売処理部２０２は、新たな所有者のアドレス値として、上記のステップＳ１０２で電子チケットを購入したチケット利用者のアドレス値を指定したチケット移転トランザクションを作成する。なお、このとき、販売処理部２０２は、サービス提供者の秘密鍵を用いてチケット移転トランザクションから電子署名を作成した上で、この電子署名をチケット移転トランザクションに付加する必要がある。

そして、チケット発行端末２０の販売処理部２０２は、上記のステップＳ１０３で作成したチケット移転トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ１０４）。チケット移転トランザクションがブロックチェーンネットワーク５０内に送信されることでチケット移転トランザクションが複数のノードで検証され、この検証に成功した場合は電子チケットの所有者格納領域に格納されているアドレス値が、新たな所有者のアドレス値に更新される。

これにより、チケット利用者は電子チケットの購入が完了する。なお、チケット移転トランザクションによって電子チケットの所有者格納領域に格納されているアドレス値が、新たな所有者のアドレス値に書き換えられるため、上述したように、チケット利用者は当該電子チケットの所有権を獲得する一方で、サービス提供者は当該電子チケットの所有権を失うことになる。

＜実施例１におけるチケット発行及びチケット購入の流れ（その２）＞
上記の図２ではチケット利用者がサービス提供者から直接電子チケットを購入する場合について説明したが、以降では、サービス提供者との間で信頼関係があるとは限らないチケット販売者から電子チケットを購入する場合の流れについて、図３を参照しながら説明する。図３は、実施例１におけるチケット発行及びチケット購入の流れの一例を示す図（その２）である。なお、図３では一例として、サービス提供者から電子チケットを購入したチケット販売者が、この電子チケットをチケット利用者に販売する場合について説明する。ただし、これに限られず、チケット販売者は、他のチケット販売者から購入した電子チケットをチケット利用者や更に他のチケット販売者に販売してもよい。

チケット発行端末２０の発行処理部２０１は、図２のステップＳ１０１と同様に、新たな電子チケットを発行する（ステップＳ２０１）。

チケット販売端末４０の販売処理部４０１は、チケット発行端末２０に対して電子チケットの購入要求を行う（ステップＳ２０２）。上述したように、電子チケットの購入要求は任意の方法で行なえばよい。なお、上記のステップＳ２０２で電子チケットが購入された場合、チケット発行端末２０は、図２のステップＳ１０２と同様に任意の方法で、この電子チケットを購入したチケット販売者のアドレス値（又は、アドレス値を特定するための情報）を取得する。

チケット発行端末２０の販売処理部２０２は、チケット移転トランザクションを作成する（ステップＳ２０３）。このとき、販売処理部２０２は、新たな所有者のアドレス値として、上記のステップＳ２０２で電子チケットを購入したチケット販売者のアドレス値を指定したチケット移転トランザクションを作成する。なお、このとき、販売処理部２０２は、サービス提供者の秘密鍵を用いてチケット移転トランザクションから電子署名を作成した上で、この電子署名をチケット移転トランザクションに付加する必要がある。

そして、チケット発行端末２０の販売処理部２０２は、図２のステップＳ１０４と同様に、上記のステップＳ２０３で作成したチケット移転トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ２０４）。これにより、チケット移転トランザクションの検証に成功した場合は電子チケットの所有者がチケット販売者に更新され、チケット販売者の電子チケット購入が完了する。

続いて、チケット利用端末１０の利用処理部１０１は、チケット販売端末４０に対して電子チケットの購入要求を行う（ステップＳ２０５）。上述したように、電子チケットの購入要求は任意の方法で行なえばよい。なお、上記のステップＳ２０５で電子チケットが購入された場合、チケット販売端末４０は、図２のステップＳ１０２と同様に任意の方法で、この電子チケットを購入したチケット利用者のアドレス値（又は、アドレス値を特定するための情報）を取得する。

チケット販売端末４０の販売処理部４０１は、チケット移転トランザクションを作成する（ステップＳ２０６）。このとき、販売処理部４０１は、新たな所有者のアドレス値として、上記のステップＳ２０５で電子チケットを購入したチケット利用者のアドレス値を指定したチケット移転トランザクションを作成する。なお、このとき、販売処理部４０１は、チケット販売者の秘密鍵を用いてチケット移転トランザクションから電子署名を作成した上で、この電子署名をチケット移転トランザクションに付加する必要がある。

そして、チケット販売端末４０の販売処理部４０１は、上記のステップＳ２０６で作成したチケット移転トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ２０７）。これにより、チケット移転トランザクションの検証に成功した場合は電子チケットの所有者がチケット利用者に更新され、チケット利用者の電子チケット購入が完了する。

このように、本実施形態に係る電子チケット管理システム１では、ERC721に準拠したトークンを電子チケットとして用いるため、仮にサービス提供者との間で必ずしも信頼関係があるとは限らないチケット販売者が電子チケットを流通させる場合であっても、電子チケットの不正コピーや二重譲渡等の不正取引を防止することができる。

＜実施例１におけるチケット利用の流れ＞
次に、チケット利用者がサービスを享受するために電子チケットを利用する場合の流れについて、図４を参照しながら説明する。図４は、実施例１におけるチケット利用の流れの一例を示す図である。

まず、チケット利用端末１０の利用処理部１０１は、電子チケットを利用済みにするためのトランザクション（以降、「チケット利用トランザクション」とも表す。）を作成する（ステップＳ３０１）。ここで、電子チケットが利用済みであるとは、チケット利用者が当該電子チケットを再度利用することができないことを意味する。したがって、電子チケットを利用済みとすることには、例えば、電子チケットの所有権をサービス提供者に移転すること、電子チケットを破棄（削除）すること、電子チケットに利用可否フラグが含まれる場合はその値を「利用不可」に更新すること、等が挙げられる。このとき、電子チケットを破棄（削除）すること及び電子チケットに含まれる利用可否フラグを「利用不可」に更新することは、電子チケットの償却と呼ばれてもよい。すなわち、電子チケットを利用済みとすることとは、電子チケットの所有権をサービス提供者等に移転すること又は電子チケットを償却することを意味する。なお、利用処理部１０１は、チケット利用者の秘密鍵を用いてチケット利用トランザクションから電子署名を作成した上で、この電子署名をチケット利用トランザクションに付加する必要がある。

ここで、上記のステップＳ３０１は、例えば、チケット利用者によってチケット利用端末１０を用いて電子チケットの利用開始操作が行われたことを契機として実行される。このような利用開始操作としては、例えば、Ｗｅｂブラウザや専用のチケット利用アプリケーション等における電子チケットの選択及び利用操作等が挙げられる。

次に、チケット利用端末１０の利用処理部１０１は、上記のステップＳ３０１で作成したチケット利用トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ３０２）。これにより、チケット利用トランザクションの検証に成功した場合は電子チケットの所有権が移転又は電子チケットが償却される。

そして、チケット利用端末１０の利用処理部１０１は、チケット利用をチケット確認端末３０に通知する（ステップＳ３０３）。チケット利用端末１０は、任意の方法でチケット利用をチケット確認端末３０に通知すればよい。例えば、任意の通信手段（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）や非接触型ＩＣカード等を介した近距離無線通信、インターネット等）により、電子チケットが利用されたことを示す情報をチケット確認端末３０に通知する。なお、このとき、電子チケットを識別する識別情報（例えば、トークンＩＤやチケット番号等）がチケット利用端末１０からチケット確認端末３０に通知される。以降では、一例として、電子チケットの識別情報はトークンＩＤであるものとする。

また、例えば、電子チケットが利用されたことを示す情報と当該電子チケットのトークンＩＤとを、チケット利用端末１０のディスプレイ上に表示してもよい。この場合、例えば、チケット利用端末１０のディスプレイ上に表示された情報が、チケット確認端末３０に入力されることでチケット利用が通知される。なお、この入力は、チケット確認端末３０のユーザの入力操作によって行われてもよいし、チケット確認端末３０が備える読取装置（例えば、カメラやスキャナ等）によって行われてもよい。

次に、チケット確認端末３０の確認処理部３０１は、上記のステップＳ３０３で利用が通知された電子チケット（つまり、トークン）をブロックチェーンネットワーク５０上で参照して、当該電子チケットに対応するサービスの提供可否を確認する（ステップＳ３０４）。電子チケットの参照は、この電子チケットのトークンＩＤをキーとして、ブロックチェーンネットワーク５０上のノードで共有されている電子チケットを検索することで行うことができる。

ここで、確認処理部３０１は、例えば、該当の電子チケット（つまり、上記のステップＳ３０３で利用が通知された電子チケット）が利用済みとなっているか否かを確認する。すなわち、確認処理部３０１は、該当の電子チケットの所有権がサービス提供者等に移転されているか又は該当の電子チケットが償却されているかを確認する。そして、確認処理部３０１は、利用済みとなっている場合にはサービス提供可とし、利用済みとなっていない場合にはサービス提供不可とすればよい。なお、電子チケットが利用済みとなっているか否か以外も、確認処理部３０１は、例えば、サービス提供に必要な各種条件（例えば、電子チケットの有効期限が過ぎていないか等）を満たしているか否かを確認してもよい。

なお、上記のステップＳ３０４で確認されたサービス提供可否は、例えば、チケット利用端末１０に通知されてもよい。又は、例えば、チケット確認端末３０がゲート装置である場合又はゲート装置と通信ネットワークを介して接続されている場合には、サービス提供可否に応じてゲートの開閉を制御する等してもよい。この他にも、サービス提供可否に応じて、サービスの提供を開始又は阻止するための種々の制御が行われてもよい。

これにより、上記のステップＳ３０４でサービス提供可であることが確認された場合には、チケット利用者に対してサービスが提供される。

［実施例２］
以降では、実施例２について説明する。実施例２では、チケット利用者が電子チケットを利用する際に、サービス提供者に二次元コード（例えば、ＱＲコード（登録商標）等）を提示することでサービスを享受する場合について説明する。

なお、実施例２では、主に、実施例１との相違点について説明し、実施例１と同一の構成要素についてはその説明を省略する。

＜実施例２におけるチケット利用の流れ（その１）＞
実施例１ではチケット利用端末１０がチケット利用トランザクションを作成及び送信したが、チケット利用端末１０の通信環境によってはチケット利用トランザクションを送信することができない場合がある。例えば、大規模なイベント会場等ではチケット利用端末１０の通信回線が混雑していて、チケット利用トランザクションを送信することができない場合がある。

そこで、チケット利用トランザクションが含まれる二次元コードをサービス提供者に提示することで電子チケットを利用し、この二次元コードを読み取ったチケット確認端末３０がチケット利用トランザクションを送信する。このチケット利用トランザクションのデータにはチケット利用端末１０でしか生成できないデータ（電子署名）が含まれている。そのため、このデータを読み取ったチケット確認端末３０は、このチケット利用トランザクションがブロックチェーンネットワーク５０で正しく処理されることをもって、データの提示者が電子チケットの所有者であることを確認することができる。

この場合の流れについて、図５を参照しながら説明する。図５は、実施例２におけるチケット利用の流れの一例を示す図（その１）である。なお、チケット確認端末３０はチケット利用端末１０とは異なる通信回線を利用しており、チケット利用トランザクションを送信することが可能な通信環境であるものとする。

まず、チケット利用端末１０の利用処理部１０１は、図４のステップＳ３０１と同様に、チケット利用トランザクションを作成する（ステップＳ４０１）。

次に、チケット利用端末１０の利用処理部１０１は、上記のステップＳ４０１で作成したチケット利用トランザクションが含まれる二次元コード（例えば、ＱＲコード等）を作成する（ステップＳ４０２）。すなわち、利用処理部１０１は、チケット利用トランザクションを二次元コードに変換（エンコード）する。

なお、二次元コードは一例であって、任意のコード（例えば、バーコード等）でもよい。また、二次元コード以外にも、チケット確認端末３０が所定の手段によりチケット利用トランザクションを取得することが可能な情報であれば、チケット利用トランザクションを任意の情報に変換してもよい。このような情報としては、例えば、音波、光の点滅、画像等が挙げられる。

次に、チケット利用端末１０の利用処理部１０１は、上記のステップＳ４０２で作成した二次元コードをチケット確認端末３０に提示する（ステップＳ４０３）。チケット利用端末１０は、例えば、二次元コードをディスプレイ上に表示することで二次元コードを提示すればよい。ただし、これ以外にも、例えば、二次元コードが印刷された紙等で提示されてもよい。

チケット確認端末３０の確認処理部３０１は、上記のステップＳ４０３で提示された二次元コードを、カメラ等で読み取る（ステップＳ４０４）。当該二次元コードを読み取ることで、確認処理部３０１は、当該二次元コードに含まれるチケット利用トランザクションを取得することができる。

なお、上記のステップＳ４０２～ステップＳ４０４では、二次元コードをチケット確認端末３０が読み取ることで、チケット利用トランザクションが取得されたが、これに限られない。チケット利用端末１０は、二次元コードを作成せずに、例えば、任意の通信手段（例えば、Ｂｌｕｅｔｏｏｔｈや非接触型ＩＣカード等を介した近距離無線通信、インターネット等）により、チケット利用トランザクションをチケット確認端末３０に送信してもよい。

次に、チケット確認端末３０の確認処理部３０１は、上記のステップＳ４０４で取得したチケット利用トランザクションに含まれるトークンＩＤを用いて、このトークンＩＤに対応する電子チケットをブロックチェーンネットワーク５０上で参照して、当該電子チケットに対応するサービスの提供可否を確認する（ステップＳ４０５）。本ステップでは、確認処理部３０１は、例えば、サービス提供に必要な各種条件（例えば、電子チケットの有効期限が過ぎていないか等）を満たしているか否かを確認する。

そして、確認処理部３０１は、サービス提供に必要な各種条件を満たしている場合にはサービス提供可とし、サービス提供に必要な各種条件を満たしていない場合にはサービス提供不可とすればよい。これにより、上記のステップＳ４０５でサービス提供可であることが確認された場合には、チケット利用者に対してサービスが提供される。

その後、チケット確認端末３０の確認処理部３０１は、上記のステップＳ４０４で取得したチケット利用トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ４０６）。これにより、チケット利用トランザクションの検証に成功した場合は電子チケットの所有権が移転又は電子チケットが償却される。

なお、上記のステップＳ４０６は、上記のステップＳ４０５の直後に実行されてもよいが、必ずしも直後に実行される必要はなく、上記のステップＳ４０５が実行された後の任意のタイミングで実行されればよい。一般に電子チケットの所有権の移転には数秒から数十秒程度の待ち時間が発生するため、上記のステップＳ４０６の実行タイミングを後にすることで、例えば、イベント会場やコンサート会場、映画館等の入口における待ち時間を軽減することができる。

＜実施例２におけるチケット利用の流れ（その２）＞
上記の図５ではチケット利用端末１０でチケット利用トランザクションを作成する場合について説明したが、トランザクションの送信には特別な条件が必要なことがある。例えば、Ethereumではトランザクションの送信に「ガス」と呼ばれる手数料が必要であり、この手数料を支払うためには仮想通貨「Eth」が必要である。このため、チケット利用者がガスを所持していない場合、チケット利用トランザクションを送信することができない。

そこで、チケット利用トランザクションをチケット確認端末３０で作成及び送信する場合の流れについて、図６を参照しながら説明する。図６は、実施例２におけるチケット利用の流れの一例を示す図（その２）である。

ただし、ERC721では電子チケット（トークン）を更新可能な者は、トークンの所有者（及び、承認されたアドレス値、現在の所有者から認証された者）に限られている。このため、電子チケットの所有者がチケット利用者である場合、サービス提供者がチケット利用トランザクションを作成及び送信して、当該電子チケットの所有権の移転や償却を行うことはできない。

そこで、以降では、スマートコントラクトの管理者（つまり、サービス提供者）であれば、チケット利用トランザクションにより電子チケットの所有権の移転や償却を行うことができるスマートコントラクトがデプロイされているものとする。このスマートコントラクトは、例えば、電子チケットの所有権の移転であれば、transferFrom関数を修正することで実現することができる。より具体的には、transferFrom関数の実行条件文requireに対して、ＯＲ条件として、スマートコントラクトの管理者であれば真値を返す関数isContractOwer()を追加することが実現することができる。電子チケットの償却についても同様に、スマートコントラクトの該当の関数の実行条件文に対して、ＯＲ条件として、関数isContractOwer()を追加することで実現することができる。

まず、チケット利用端末１０の利用処理部１０１は、チケット利用者の秘密鍵を用いて、このチケット利用者が利用する電子チケットのトークンＩＤから電子署名を作成した上で、この電子署名を当該トークンＩＤに付加したデータ（電子署名付きデータ）を作成する（ステップＳ５０１）。

次に、チケット利用端末１０の利用処理部１０１は、上記のステップＳ５０１で作成した電子署名付きデータが含まれる二次元コードを作成する（ステップＳ５０２）。すなわち、利用処理部１０１は、電子署名付きデータを二次元コードに変換する。

なお、図５のステップＳ４０２と同様に、電子署名付きデータは、任意のコードに変換されてもよいし、例えば、音波、光の点滅、画像等の任意の情報に変換されてもよい。

次に、チケット利用端末１０の利用処理部１０１は、上記のステップＳ５０２で作成した二次元コードをチケット確認端末３０に提示する（ステップＳ５０３）。チケット利用端末１０は、図５のステップＳ４０３と同様に、例えば、二次元コードをディスプレイ上に表示することで二次元コードを提示すればよい。

チケット確認端末３０の確認処理部３０１は、上記のステップＳ５０３で提示された二次元コードを、カメラ等で読み取る（ステップＳ５０４）。当該二次元コードを読み取ることで、確認処理部３０１は、当該二次元コードに含まれる電子署名付きデータを取得することができる。

なお、上記のステップＳ５０２～ステップＳ５０４では、二次元コードをチケット確認端末３０が読み取ることで、電子署名付きデータが取得されたが、これに限られない。チケット利用端末１０は、二次元コードを作成せずに、例えば、任意の通信手段により、電子署名付きデータをチケット確認端末３０に送信してもよい。

次に、チケット確認端末３０の確認処理部３０１は、上記のステップＳ５０４で取得した電子署名付きデータからトークンＩＤとチケット利用者のアドレス値とを取得し、これらのトークンＩＤ及びアドレス値を用いて、このトークンＩＤに対応する電子チケットをブロックチェーンネットワーク５０上で参照して、当該電子チケットに対応するサービスの提供可否を確認する（ステップＳ５０５）。本ステップでは、確認処理部３０１は、例えば、当該トークンＩＤに対応するブロックチェーンネットワーク５０上の電子チケットの所有者格納領域に格納されているアドレス値が、電子署名付きデータから取得したアドレス値と一致するか否かを確認する（つまり、当該電子チケットの所有者がチケット利用者であるか否かを確認する。）。なお、本ステップでは、当該電子チケットが利用済みとなっているか否かの確認は行われない。また、上記のアドレス値の一致確認に加えて、確認処理部３０１は、サービス提供に必要な各種条件を満たしているか否かを確認してもよい。

なお、チケット利用者のアドレス値は、電子署名付きデータに含まれる電子署名から取得することが可能である。すなわち、チケット利用者の公開鍵を用いて電子署名を検証した上で、この検証に成功した公開鍵に対応するアドレス値が、チケット利用者のアドレス値として取得される。

そして、確認処理部３０１は、上記のアドレス値が一致している場合にはサービス提供可とし、上記のアドレス値が一致していない場合にはサービス提供不可とすればよい。これにより、上記のステップＳ５０５でサービス提供可であることが確認された場合には、チケット利用者に対してサービスが提供される。

また、チケット確認端末３０の確認処理部３０１は、上記のステップＳ５０４で取得したトークンＩＤを用いて、チケット利用トランザクションを作成する（ステップＳ５０６）。すなわち、確認処理部３０１は、当該トークンＩＤの電子チケットの所有権をサービス提供者に移転させるためのチケット利用トランザクション又は当該トークンＩＤの電子チケットを償却（削除又は利用可否フラグを「利用不可」に更新）するためのチケット利用トランザクションを作成する。

その後、チケット確認端末３０の確認処理部３０１は、上記のステップＳ５０６で作成したチケット利用トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ５０７）。これにより、チケット利用トランザクションの検証に成功した場合は電子チケットの所有権が移転又は電子チケットが償却される。しかも、この場合、サービス提供者がチケット利用トランザクションを作成及び送信するため、例えば、チケット利用者はガスを消費することがない。このため、例えば、チケット利用者がガスを所持していない等の事由によって電子チケットが利用できないといった事態を防止することができる。

なお、上記のステップＳ５０６～ステップＳ５０７は、上記のステップＳ５０５の直後に実行されてもよいが、必ずしも直後に実行される必要はなく、上記のステップＳ５０５が実行された後の任意のタイミングで実行されればよい。

［実施例３］
以降では、実施例３について説明する。上記の図６で説明した実施例２におけるチケット利用の流れ（その２）では、スマートコントラクトの管理者（つまり、サービス提供者）であればチケット利用トランザクションにより電子チケットの所有権の移転や償却を無条件に行うことができる。そこで、実施例３では、電子チケットの所有者（つまり、チケット利用者）から秘密値が提示された場合のみ当該電子チケットの所有権の移転や償却を行うことができるようにする。秘密値とは、電子チケットの所有者により任意に決められた秘密の値（例えば、任意に決められた英数字の文字列）である。

このために、実施例３では、電子チケットには秘密値のハッシュ値が格納される領域（この領域を「ハッシュ値格納領域」とも表す。）が存在し、電子チケットのパラメータとして、秘密値のハッシュ値が当該ハッシュ値格納領域に格納されるものとする。また、これに伴い、例えば、transferFrom関数の引数には、このハッシュ値が追加される。

なお、実施例３では、主に、実施例２との相違点について説明し、実施例２と同一の構成要素についてはその説明を省略する。

＜実施例３におけるチケット発行及びチケット購入の流れ（その１）＞
まず、サービス提供者が電子チケットを発行し、この電子チケットをチケット利用者が購入する場合の流れについて、図７を参照しながら説明する。図７は、実施例３におけるチケット発行及びチケット購入の流れの一例を示す図（その１）である。

チケット発行端末２０の発行処理部２０１は、図２のステップＳ１０１と同様に、新たな電子チケットを発行する（ステップＳ６０１）。

チケット利用端末１０の利用処理部１０１は、チケット利用者が予め決めた秘密値からハッシュ値を計算する（ステップＳ６０２）。なお、ハッシュ値の計算に用いられるハッシュ関数は、例えば、スマートコントラクト毎に予め決められた共通のものを使用する。

次に、チケット利用端末１０の利用処理部１０１は、チケット発行端末２０に対して電子チケットの購入要求を行う（ステップＳ６０３）。このとき、利用処理部１０１は、上記のステップＳ６０２で計算されたハッシュ値を任意の方法でチケット発行端末２０に通知する。

なお、上述したように、電子チケットの購入要求は任意の方法で行なえばよい。また、上記のステップＳ６０３で電子チケットが購入された場合、チケット発行端末２０は、図２のステップＳ１０２と同様に任意の方法で、この電子チケットを購入したチケット利用者のアドレス値（又は、アドレス値を特定するための情報）を取得する。

チケット発行端末２０の販売処理部２０２は、電子チケットのハッシュ値格納領域に対して指定されたハッシュ値を格納すると共に電子チケットの所有権を移転させるためのトランザクション（以降、「パラメータ設定及びチケット移転トランザクション」とも表す。）を作成する（ステップＳ６０４）。ここで、販売処理部２０２は、電子チケットのハッシュ値格納領域に格納されるパラメータとして、上記のステップＳ６０３でチケット利用端末１０から通知されたハッシュ値を指定したパラメータ設定及びチケット移転トランザクションを作成する。なお、このとき、販売処理部２０２は、サービス提供者の秘密鍵を用いてパラメータ設定及びチケット移転トランザクションから電子署名を作成した上で、この電子署名をパラメータ設定及びチケット移転トランザクションに付加する必要がある。

そして、チケット発行端末２０の販売処理部２０２は、上記のステップＳ６０４で作成したパラメータ設定及びチケット移転トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ６０５）。これにより、パラメータ設定及びチケット移転トランザクションが複数のノードで検証され、この検証に成功した場合は電子チケットのハッシュ値格納領域に対して、チケット利用者の秘密値のハッシュ値が格納されると共に、電子チケットの所有権がチケット利用者に移転される。これにより、チケット利用者の電子チケット購入が完了する。上述したように、この電子チケットには、当該チケット利用者が決めた秘密値のハッシュ値が含まれている。

なお、電子チケットの所有者（つまり、チケット利用者）は、任意のタイミングで秘密値の変更及びそのハッシュ値の計算を行った上で、電子チケットのハッシュ値格納領域に対して指定されたハッシュ値を格納するためのトランザクション（以降、「パラメータ設定トランザクション」とも表す。）を作成及び送信することにより、当該電子チケットのハッシュ値格納領域に格納されているハッシュ値を変更することが可能である。

＜実施例３におけるチケット発行及びチケット購入の流れ（その２）＞
次に、チケット利用者がチケット販売者から電子チケットを購入する場合の流れについて、図８を参照しながら説明する。図８は、実施例３におけるチケット発行及びチケット購入の流れの一例を示す図（その２）である。なお、図８では一例として、サービス提供者から電子チケットを購入したチケット販売者が、この電子チケットをチケット利用者に販売する場合について説明する。ただし、これに限られず、チケット販売者は、他のチケット販売者から購入した電子チケットをチケット利用者や更に他のチケット販売者に販売してもよい。

チケット発行端末２０の発行処理部２０１は、図２のステップＳ１０１と同様に、新たな電子チケットを発行する（ステップＳ７０１）。

チケット販売端末４０の販売処理部４０１は、チケット販売者が予め決めた秘密値からハッシュ値を計算する（ステップＳ７０２）。

次に、チケット販売端末４０の販売処理部４０１は、チケット発行端末２０に対して電子チケットの購入要求を行う（ステップＳ７０３）。このとき、販売処理部４０１は、上記のステップＳ７０２で計算されたハッシュ値を任意の方法でチケット発行端末２０に通知する。

なお、上述したように、電子チケットの購入要求は任意の方法で行なえばよい。また、上記のステップＳ７０２で電子チケットが購入された場合、チケット発行端末２０は、図２のステップＳ１０２と同様に任意の方法で、この電子チケットを購入したチケット販売者のアドレス値（又は、アドレス値を特定するための情報）を取得する。

チケット発行端末２０の販売処理部２０２は、パラメータ設定及びチケット移転トランザクションを作成する（ステップＳ７０４）。ここで、販売処理部２０２は、電子チケットのハッシュ値格納領域に格納されるパラメータとして、上記のステップＳ７０３でチケット販売端末４０から通知されたハッシュ値を指定したパラメータ設定及びチケット移転トランザクションを作成する。なお、このとき、販売処理部２０２は、サービス提供者の秘密鍵を用いてパラメータ設定及びチケット移転トランザクションから電子署名を作成した上で、この電子署名をパラメータ設定及びチケット移転トランザクションに付加する必要がある。

そして、チケット発行端末２０の販売処理部２０２は、上記のステップＳ７０４で作成したパラメータ設定及びチケット移転トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ７０５）。これにより、パラメータ設定及びチケット移転トランザクションが複数のノードで検証され、この検証に成功した場合は電子チケットのハッシュ値格納領域に対して、チケット販売者の秘密値のハッシュ値が格納されると共に、電子チケットの所有権がチケット販売者に移転される。

続いて、チケット利用端末１０の利用処理部１０１は、チケット利用者が予め決めた秘密値からハッシュ値を計算する（ステップＳ７０６）。

次に、チケット利用端末１０の利用処理部１０１は、チケット販売端末４０に対して電子チケットの購入要求を行う（ステップＳ７０７）。このとき、利用処理部１０１は、上記のステップＳ７０６で計算されたハッシュ値を任意の方法でチケット販売端末４０に通知する。

なお、上述したように、電子チケットの購入要求は任意の方法で行なえばよい。また、上記のステップＳ７０７で電子チケットが購入された場合、チケット販売端末４０は、図２のステップＳ１０２と同様に任意の方法で、この電子チケットを購入したチケット利用者のアドレス値（又は、アドレス値を特定するための情報）を取得する。

チケット販売端末４０の販売処理部４０１は、パラメータ設定及びチケット移転トランザクションを作成する（ステップＳ７０８）。ここで、販売処理部４０１は、電子チケットのハッシュ値格納領域に格納されるパラメータとして、上記のステップＳ７０７でチケット利用端末１０から通知されたハッシュ値を指定したパラメータ設定及びチケット移転トランザクションを作成する。なお、このとき、販売処理部４０１は、チケット販売者の秘密鍵を用いてパラメータ設定トランザクションから電子署名を作成した上で、この電子署名をパラメータ設定及びチケット移転トランザクションに付加する必要がある。

そして、チケット販売端末４０の販売処理部４０１は、上記のステップＳ７０８で作成したパラメータ設定及びチケット移転トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ７０９）。これにより、パラメータ設定及びチケット移転トランザクションが複数のノードで検証され、この検証に成功した場合は電子チケットのハッシュ値格納領域に対して、チケット利用者の秘密値のハッシュ値が格納されると共に、電子チケットの所有権がチケット利用者に移転される。これにより、チケット利用者の電子チケット購入が完了する。上述したように、この電子チケットには、当該チケット利用者が決めた秘密値のハッシュ値が含まれている。

なお、電子チケットの所有者（つまり、チケット販売者又はチケット利用者）は、任意のタイミングで秘密値の変更及びそのハッシュ値の計算を行った上で、このハッシュ値を指定したパラメータ設定トランザクションを作成及び送信することにより、当該電子チケットのハッシュ値格納領域に格納されているハッシュ値を変更することが可能である。

＜実施例３におけるチケット利用の流れ（その１）＞
次に、秘密値を考慮して、上記の図６で説明したチケット利用を行う場合の流れについて、図９を参照しながら説明する。図９は、実施例３におけるチケット利用の流れの一例を示す図（その１）である。

まず、チケット利用端末１０の利用処理部１０１は、チケット利用者が購入した電子チケットのトークンＩＤと当該チケット利用者の秘密値とが含まれる二次元コードを作成する（ステップＳ８０１）。すなわち、利用処理部１０１は、トークンＩＤと秘密値とを二次元コードに変換する。

なお、図６のステップＳ５０２と同様に、トークンＩＤと秘密値とは、任意のコードに変換されてもよいし、例えば、音波、光の点滅、画像等の任意の情報に変換されてもよい。

次に、チケット利用端末１０の利用処理部１０１は、図６のステップＳ５０３と同様に、上記のステップＳ８０１で作成した二次元コードをチケット確認端末３０に提示する（ステップＳ８０２）。

チケット確認端末３０の確認処理部３０１は、上記のステップＳ８０２で提示された二次元コードを、カメラ等で読み取る（ステップＳ８０３）。当該二次元コードを読み取ることで、確認処理部３０１は、当該二次元コードに含まれるトークンＩＤと秘密値とを取得することができる。

なお、上記のステップＳ８０１～ステップＳ８０３では、二次元コードをチケット確認端末３０が読み取ることで、トークンＩＤと秘密値とが取得されたが、これに限られない。チケット利用端末１０は、二次元コードを作成せずに、例えば、任意の通信手段により、トークンＩＤと秘密値とをチケット確認端末３０に送信してもよい。

次に、チケット確認端末３０の確認処理部３０１は、図６のステップＳ５０５と同様に、二次元コードから取得したトークンＩＤとチケット利用者のアドレス値とを用いて、このトークンＩＤに対応する電子チケットをブロックチェーンネットワーク５０上で参照して、当該電子チケットに対応するサービスの提供可否を確認する（ステップＳ８０４）。

次に、チケット確認端末３０の確認処理部３０１は、二次元コードから取得したトークンＩＤに対応する電子チケットに含まれるハッシュ値を取得する（ステップＳ８０５）。

次に、チケット確認端末３０の確認処理部３０１は、上記のステップＳ８０５で取得したハッシュ値と、二次元コードから取得したハッシュ値とを比較して、これらのハッシュ値が一致するか否かを判定する（ステップＳ８０６）。このステップＳ８０６でハッシュ値が一致すると判定された場合、チケット利用者に対してサービスが提供される。なお、このサービス提供は、上記のステップＳ８０４が実行された後に行われてもよいし、後述するステップＳ８０８が実行された後に行われてもよい。

そして、上記のステップＳ８０５でハッシュ値が一致すると判定された場合は、チケット確認端末３０の確認処理部３０１は、上記のステップＳ８０３で取得したトークンＩＤと秘密値とを用いて、チケット利用トランザクションを作成する（ステップＳ８０７）。すなわち、確認処理部３０１は、当該トークンＩＤの電子チケットの所有権をサービス提供者に移転させるためのチケット利用トランザクション又は当該トークンＩＤの電子チケットを償却（削除又は利用可否フラグを「利用不可」に更新）するためのチケット利用トランザクションを作成する。ここで、このチケット利用トランザクションには、トークンＩＤと秘密値とが指定される。

その後、チケット確認端末３０の確認処理部３０１は、上記のステップＳ８０７で作成したチケット利用トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ８０８）。これにより、チケット利用トランザクションの検証に成功した場合は電子チケットの所有権が移転又は電子チケットが償却される。これにより、例えば、電子チケットの所有者であるチケット利用者が正しい秘密値を提示した場合のみ、電子チケットを利用済みとさせることが可能となる。

ここで、例えば、電子チケットの所有権の移転であれば、スマートコントラクトのtransferFrom関数の実行条件文requireに対して、ＯＲ条件として、「isContractOwer()、かつ、checkSecretWord(tokenId, secretWord)」を追加することで実現することができる。checkSecretWord(tokenId, secretWord)は、tokenIdが示すトークンＩＤに対応する電子データに含まれるハッシュ値と、secretWordが示す秘密値のハッシュ値とが一致する場合に真値を返す関数である。また、電子チケットの償却についても同様に、スマートコントラクトの該当の関数の実行条件文に対して、ＯＲ条件として、「isContractOwer()、かつ、checkSecretWord(tokenId, secretWord)」を追加することで実現することができる。なお、秘密値のハッシュ値を計算するためのハッシュ関数は、例えば、スマートコントラクト毎に予め決められた共通のものを使用する。

なお、上記のステップＳ８０７～ステップＳ８０８は、上記のステップＳ８０６の直後に実行されてもよいが、必ずしも直後に実行される必要はなく、上記のステップＳ８０６が実行された後の任意のタイミングで実行されればよい。ただし、チケット利用者から提示された秘密値が正しい場合のみサービスを提供するようにするためには、上記のステップＳ８０７～ステップＳ８０８は、上記のステップＳ８０６の直後かつサービスが提供される前に実行されることが好ましい。

また、上記の図９では、電子チケットに含まれるハッシュ値と、上記のステップＳ８０３で取得した秘密値のハッシュ値とが一致するか否かをチケット確認端末３０で検証したが（上記のステップＳ８０６）、この検証はブロックチェーンネットワーク５０で行われてもよい（例えば、ブロックチェーンネットワーク５０のノードのうち、チケット確認端末３０以外のノードで検証する等）。この場合、当該検証は、例えば、上記のステップＳ８０６で実行されてもよいし、上記のステップＳ８０８のチケット利用トランザクションの送信前に実行してもよい。なお、チケット利用トランザクションの送信前に当該検証が実行される場合、当該検証に失敗したときには当該チケット利用トランザクションが破棄されればよい。

＜実施例３におけるチケット利用の流れ（その２）＞
上記の図７又は図８では電子チケットを購入する際に、チケットを購入する者（サービス利用者又はチケット販売者）は、チケットを販売する者（サービス提供者又はチケット販売者）に対してハッシュ値を提示しているが、この提示は行われなくもよい。この場合、チケット利用者が購入した電子チケットのハッシュ値格納領域にはハッシュ値が含まれていないことになる。以降では、このような電子チケットをチケット利用者が利用する場合の流れについて、図１０を参照しながら説明する。図１０は、実施例３におけるチケット利用の流れの一例を示す図（その２）である。

まず、チケット利用端末１０の利用処理部１０１は、チケット利用者が予め決めた秘密値からハッシュ値を計算する（ステップＳ９０１）。なお、ハッシュ値の計算に用いられるハッシュ関数は、例えば、スマートコントラクト毎に予め決められた共通のものを使用する。

次に、チケット利用端末１０の利用処理部１０１は、チケット利用者が購入した電子チケットのハッシュ値格納領域に対して上記のステップＳ９０１で計算されたハッシュ値を格納するためのパラメータ設定トランザクションを作成する（ステップＳ９０２）。

そして、チケット利用端末１０の利用処理部１０１は、上記のステップＳ９０２で作成したパラメータ設定トランザクションをブロックチェーンネットワーク５０内に送信する（ステップＳ９０３）。これにより、パラメータ設定トランザクションが複数のノードで検証され、この検証に成功した場合は当該電子チケットのハッシュ値格納領域に対して、上記のステップＳ９０１で計算されたハッシュ値が格納される。

次に、チケット利用端末１０の利用処理部１０１は、当該電子チケットのトークンＩＤと当該チケット利用者の秘密値とが含まれる二次元コードを作成する（ステップＳ９０４）。

以降のステップＳ９０５～ステップＳ９１１は、図９のステップＳ８０２～ステップＳ８０８とそれぞれ同様であるため、その説明を省略する。

このように、実施例３では、ハッシュ値が含まれない電子チケットをチケット利用者が購入した上で、当該電子チケットの利用前に、秘密値からハッシュ値を計算して当該電子チケットに当該ハッシュ値を格納してもよい。

＜データ圧縮について＞
ここで、二次元コード（例えば、ＱＲコード）に含まれる情報のデータ量が多い場合、チケット確認端末３０がカメラ等で読み取る際に、その読み取り精度が低下することがある。そこで、二次元コードに含まれる情報のデータ量を圧縮する場合について説明する。

例えば、図６のステップＳ５０２で電子署名付きデータから二次元コードを作成する場合、この電子署名付きデータは、Ethereumの標準的なフォーマットでは、例えば、図１１（ａ）に示す形式となる。このうち、messageはトークンＩＤを表し、signatureは電子署名を表すが、電子署名の検証に必要な情報はこの２つのみである。すなわち、図１１（ａ）に示す各情報のうち、messageHash, v, r, sは電子署名の検証に不要な情報である。そこで、これらの情報を削除すると共に、特にデータ量が多いsignatureを圧縮することでデータ量を削減することができる。

messageHash, v, r, sを削除すると共に、signatureの情報を所定の圧縮方式（例えば、base91）でエンコードした電子署名付きデータを図１１（ｂ）に示す。なお、図１１（ｂ）では、messageをm, signatureをsで表している。

これにより、二次元コードに含まれる情報のデータ量を削減することができるため、チケット確認端末３０での読み取り精度の低下を防止することができる。なお、チケット確認端末３０では、二次元コードから読み取った電子署名をデコードする必要がある。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更、組み合わせ等が可能である。

１ 電子チケット管理システム
１０ チケット利用端末
２０ チケット発行端末
３０ チケット確認端末
４０ チケット販売端末
５０ ブロックチェーンネットワーク
１０１ 利用処理部
２０１ 発行処理部
２０２ 販売処理部
３０１ 確認処理部
４０１ 販売処理部

Claims (5)

1. 電子チケットの利用に応じてサービスを提供する提供者の提供者端末と、前記電子チケットを利用して前記サービスを享受する享受者の利用者端末と、前記電子チケットを販売又は転売する販売者の販売者端末とが含まれる電子チケット管理システムにおける電子チケット管理方法であって、
   前記提供者端末が、前記提供者を識別するアドレス値を所有者に指定したトークンで表される電子チケットを発行する発行手順と、
   前記提供者端末又は前記販売者端末が、前記享受者又は前記販売者を識別するアドレス値を新たな所有者に指定し、かつ、前記享受者又は前記販売者が予め決めた秘密値から計算されるハッシュ値を更に指定した第１のトランザクションをブロックチェーンネットワークに送信することで、前記ハッシュ値が含まれる前記電子チケットの所有権を前記享受者又は前記販売者に移転する移転手順と、
   前記提供者端末が、前記利用者端末から取得した識別子によって識別される電子チケットに含まれるハッシュ値と、前記利用者端末から取得した秘密値から計算されるハッシュ値とが一致する場合、前記サービスを提供するサービス提供手順と、
   前記提供者端末が、前記享受者が所有する電子チケットを利用済みとするための第２のトランザクションを前記ブロックチェーンネットワークに送信することで、前記電子チケットを利用済とするチケット更新手順と、
   を有する電子チケット管理方法。
2. 電子チケットの利用に応じてサービスを提供する提供者の提供者端末と、前記電子チケットを利用して前記サービスを享受する享受者の利用者端末と、前記電子チケットを販売又は転売する販売者の販売者端末とが含まれる電子チケット管理システムにおける電子チケット管理方法であって、
   前記提供者端末が、前記提供者を識別するアドレス値を所有者に指定したトークンで表される電子チケットを発行する発行手順と、
   前記提供者端末又は前記販売者端末が、前記享受者又は前記販売者を識別するアドレス値を新たな所有者に指定し、かつ、前記享受者又は前記販売者が予め決めた秘密値から計算されるハッシュ値を更に指定した第１のトランザクションをブロックチェーンネットワークに送信することで、前記ハッシュ値が含まれる前記電子チケットの所有権を前記享受者又は前記販売者に移転する移転手順と、
   前記提供者端末が、前記サービスを提供する場合に、前記享受者が所有する電子チケットを利用済みとするための第２のトランザクションを前記ブロックチェーンネットワークに送信することで、前記電子チケットを利用済とするチケット更新手順と、
   を有し、
   前記第２のトランザクションは、
   前記利用者端末から取得した識別子によって識別される電子チケットに含まれるハッシュ値と、前記利用者端末から取得した秘密値から計算されるハッシュ値とが一致しない場合には、前記電子チケットを利用済みとしない、ことを特徴とする電子チケット管理方法。
3. 電子チケットを利用済みとすることには、前記電子チケットの所有権を前記提供者に移転することが含まれ、
   前記第２のトランザクションは、前記提供者を識別するアドレス値を新たな所有者に指定することで、前記享受者が所有する電子チケットの所有権を移転させるためのトランザクションである、ことを特徴とする請求項１又は２に記載の電子チケット管理方法。
4. 電子チケットを利用済みとすることには、前記電子チケットに含まれるフラグの値を、前記電子チケットが利用済みであることを示す値に更新すること、及び、前記電子チケットを削除することが含まれ、
   前記第２のトランザクションは、前記電子チケットに含まれるフラグの値を利用済みであることを示す値に更新するためのトランザクション、又は、前記電子チケットを削除するためのトランザクションである、ことを特徴とする請求項１又は２に記載の電子チケット管理方法。
5. 請求項１乃至４の何れか一項に記載の電子チケット管理方法における各手順をコンピュータに実行させるための電子チケット管理プログラム。

Images