JP2022133057A - データ管理方法及びデータ管理プログラム - Google Patents

Abstract

【課題】ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止すること。【解決手段】一実施形態に係るデータ管理方法は、所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムにおけるデータ管理方法であって、前記利用者端末が、前記データを識別するデータＩＤと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている１つのアドレス値とを前記提供者端末に提示する提示手順と、前記提供者端末が、前記提示手順で提示されたデータＩＤとアドレス値とを用いて、前記データＩＤで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、を実行する。【選択図】図２

Description

本発明は、データ管理方法及びデータ管理プログラムに関する。

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

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

また、近年では、分散共有台帳等とも呼ばれるブロックチェーンを利用して電子チケットを実現する技術も存在する（例えば、非特許文献１）。この技術ではブロックチェーン上で電子チケットが管理されるため、電子チケットの自由な流通を実現しつつ、不正利用及び不正取引を防止することが可能になる。

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

ContractGate/Pass, インターネット＜ＵＲＬ：https://www.ntt-tx.co.jp/products/contractgate/pass.html＞

ブロックチェーンを利用した電子チケットでは、どのアドレス値を持つ利用者がどの電子チケットを所有し、またその電子チケットをどのように利用したかが分散共有台帳上に記録される。このため、氏名、住所、電話番号、クレジットカード番号等といった個人の特定につながる情報がアドレス値と紐づかないように管理する必要がある。しかしながら、その場合であっても、アドレス値で「名寄せ」することにより、個人の属性や行動傾向等といったパーソナルデータが漏洩する恐れがある。

例えば、平日にほぼ毎日、Ａバス停からＢバス停までの往復バスチケットを利用しているアドレス値があった場合、そのアドレス値を持つ利用者は、Ａバス停付近に住み、Ｂバス停付近に職場がある者であると推定される。また、そのアドレス値で、特定の店舗でのサービス利用チケットの購入や利用があると、その店舗を利用する者であると推定又は特定される。このように、アドレス値の「名寄せ」により、そのアドレス値を持つ利用者の自宅、職場、趣味、嗜好、行動範囲等といった属性や行動傾向が推定又は特定され得る。

更に、もし仮に、一旦個人が特定されると、そのアドレス値でのチケット所有や利用により様々なパーソナルデータが漏洩するリスクがより高くなる。

本発明の一実施形態は、上記の点に鑑みてなされたもので、ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止することを目的とする。

上記目的を達成するため、一実施形態に係るデータ管理方法は、所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムにおけるデータ管理方法であって、前記利用者端末が、前記データを識別するデータＩＤと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている１つのアドレス値とを前記提供者端末に提示する提示手順と、前記提供者端末が、前記提示手順で提示されたデータＩＤとアドレス値とを用いて、前記データＩＤで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、を実行する。

ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止することができる。

実施例１における電子チケット管理システムの全体構成の一例を示す図である。 実施例１の概要を説明するための図である。 実施例１におけるチケット利用端末の機能構成の一例を示す図である。 実施例１におけるチケット確認端末の機能構成の一例を示す図である。 実施例１におけるチケット利用の流れの一例を示すシーケンス図である。 実施例２における電子チケット管理システムの全体構成の一例を示す図である。 実施例２の概要を説明するための図である。 実施例２におけるチケット利用端末の機能構成の一例を示す図である。 実施例２における販売サーバの機能構成の一例を示す図である。 実施例２におけるチケット購入の流れの一例を示すシーケンス図である。

以下、本発明の実施形態（以降、「本実施形態」とも表す。）について説明する。本実施形態では、ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止することができる電子チケット管理システム１について説明する。この電子チケット管理システム１により、パーソナルデータの漏洩を防止しつつ、電子チケットの自由な流通と不正利用及び不正取引の防止とを両立させることが可能となる。なお、本実施形態では、電子チケットを単に「チケット」とも表す。ただし、「電子チケット」又は「チケット」は何等かのサービス（役務）や商品（情報等を含む）の提供や譲渡等を受けるためのデータの一例であって、本実施形態は電子チケット又はチケット以外にも、このようなデータに対して同様に適用可能である。

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

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

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

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

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

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

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

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

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

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

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

＜アドレス値の生成方法＞
ブロックチェーン技術では、基本的に、公開鍵暗号に基づいて利用者自身によりアドレス値が生成される。すなわち、利用者自身でまず秘密鍵を作成し、予め決められたアルゴリズムによってその秘密鍵と対になる公開鍵を作成する。ブロックチェーン技術におけるアドレス値は、この公開鍵に対応して決定される。上記の（２）及び（３）で説明したように、ブロックチェーン上の共有情報である電子チケットを更新するためのトランザクションには、当該秘密鍵に基づく電子署名を付加する必要である。このような秘密鍵の生成や電子署名の付加等といった機能を提供するソフトウェアは、一般には、ウォレットと呼ばれる。

ウォレットには、単に１組の秘密鍵・公開鍵（つまり、１つのアドレス値）を管理するだけなく、複数の組の秘密鍵・公開鍵（つまり、複数のアドレス値）を管理できるものもある。例えば、ＢＩＰ－０３２（https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki）として公開されているＨＤウォレット（階層的決定性ウォレット）呼ばれる仕組みがある。このＨＤウォレットの仕組みでは、まず、１つのマスター秘密鍵を作成し、そのマスター秘密鍵に基づいて階層的に秘密鍵を作成することができる。このため、階層的に作成された複数の秘密鍵の各々に対してその対となる公開鍵を作成することができるため、階層的に複数のアドレス値を管理することが可能となる。

ＨＤウォレットの仕組みでは、複数のアドレス値があったときに、マスター秘密鍵を知らない限り、それらのアドレス値が、同一のマスター秘密鍵から作成された秘密鍵と対になる公開鍵によって生成されたものであるか否かを確認することができない、という特徴がある。具体的には、例えば、アドレス値Ａ１とアドレス値Ａ２とがあったときに、アドレス値Ａ１とアドレス値Ａ２とが、同一のマスター秘密鍵から作成された秘密鍵と対になる公開鍵によって生成されたものであるか、異なるマスター秘密鍵から作成された秘密鍵と対になる公開鍵によって生成されたものであるかを確認することができない。

そこで、本実施形態に係る電子チケット管理システム１では、利用者は、ＨＤウォレット等の複数のアドレス値を管理可能なウォレットを用いて、複数のアドレス値を利用するものとする。これにより、アドレス値による「名寄せ」が困難となり、個人の属性や行動傾向等といったパーソナルデータの漏洩を防止することが可能になる。なお、ＨＤウォレットは一例であって、複数のアドレス値を管理可能なウォレットであれば、本実施形態は同様に適用可能である。また、例えば、１以上のアドレス値を管理可能なウォレットを複数使用して、各チケット利用者が複数のアドレス値を利用可能としてもよく、このような場合でも本実施形態は同様に適用可能である。

複数のアドレス値を管理可能なウォレットを用いて、どのようにアドレス値を管理するかは様々に考えられ、利用者の利便性や電子チケットの性質等を鑑みて任意に設定することが可能である。例えば、電子チケットの種類や目的等に応じてアドレス値を異ならせてもよいし、日や月、期間に応じてアドレス値を異ならせてもよいし、電子チケット毎にアドレス値を異ならせてもよい。

電子チケットの種類や目的等に応じてアドレス値を異ならせる具体例としては、例えば、コンサート鑑賞や映画鑑賞用の電子チケットと、交通機関を利用するための電子チケットとでアドレス値を異ならせる等が挙げられる。なお、これに加えて、例えば、一定期間の経過に伴って、それ以降に購入等した電子チケットに使用するアドレス値を異ならせてもよい。

ここで、例えば、ＨＤウォレットで２階層目の秘密鍵を生成する場合、m/i/j（ただし、ｉ及びｊは適当な数値）というパラメータを指定することができる。このため、例えば、日付毎にアドレス値を異ならせる場合、２０２１年１月１５日分の電子チケットに使用するアドレス値は、m/0/20210115をパラメータとして秘密鍵を生成し、この秘密鍵と対になる公開鍵から生成すればよい。同様に、電子チケットの種類や目的等に応じてアドレス値を異ならせる場合も、その種類や目的等に応じて異なるパラメータを指定すればよい。

なお、パラメータが同じであっても、マスター秘密鍵が異なる場合は、当然ながら異なる秘密鍵が生成され、その結果、アドレス値も異なる。また、上記では、簡単のため秘密鍵の階層構造が２階層である場合について説明したが、２階層に限られず、３階層以上であってもよい。

［実施例１］
以下、本実施形態の実施例１について説明する。実施例１では、各利用者（以下、「チケット利用者」ともいう。）は複数のアドレス値をウォレットで管理しており、これら複数のアドレス値を用いて電子チケットを購入等したものとし、それらの電子チケットを利用する場合について説明する。

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

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

チケット利用端末１０は、電子チケットを利用してサービスを享受するチケット利用者が使用する端末である。チケット利用者は、チケット利用端末１０を用いて電子チケットを利用し、サービスを享受することができる。チケット利用端末１０としては、例えば、スマートフォン、タブレット端末、携帯型ゲーム機器、ウェアラブルデバイス、ＰＣ（パーソナルコンピュータ）等の各種端末を用いることができる。ここで、チケット利用端末１０には複数のアドレス値を管理可能なウォレットがインストールされており、このウォレットによってチケット利用者が所有している電子チケット（つまり、当該チケット利用者のアドレス値が所有者格納領域に格納されている電子チケット）も管理されているものとする。

なお、複数のチケット利用端末１０の各々を区別する場合は、「チケット利用端末１０Ａ」、「チケット利用端末１０Ｂ」等と表記する。

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

なお、複数のチケット確認端末２０の各々を区別する場合は、「チケット確認端末２０Ａ」、「チケット確認端末２０Ｂ」等と表記する。

図１に示す電子チケット管理システム１の構成は一例であって、他の構成であってもよい。例えば、チケット確認端末２０は必ずしもサービス提供が使用する端末である必要はなく、サービス提供者から委託を受けた委託先、協力会社、関連会社等が使用する端末であってもよい。

（実施例１の概要）
本実施例の概要について、図２を参照しながら説明する。図２は、実施例１の概要を説明するための図である。

図２に示すように、ブロックチェーンネットワーク４０内の各ノードは、共有情報として電子チケット情報１０００を保持しているものとする。この電子チケット情報１０００は、電子チケットの識別子を示す「チケットＩＤ」と、この電子チケットの所有者を示す「アドレス値」と、この電子チケットの使用状態（例えば、電子チケットが使用済か否か等）を示す「状態」とが含まれるレコードで構成されている。

例えば、図２に示す例では、電子チケット情報１０００は、以下の８レコードで構成されている。

・チケットＩＤ「Park001」、アドレス値「ABC123」、状態「使用済」
・チケットＩＤ「Bus0303」、アドレス値「ABC123」、状態「未使用」
・チケットＩＤ「Park011」、アドレス値「134AAA」、状態「未使用」
・チケットＩＤ「Bus0311」、アドレス値「AB2322」、状態「未使用」
・チケットＩＤ「Park002」、アドレス値「13579F」、状態「使用済」
・チケットＩＤ「Bus0304」、アドレス値「13579F」、状態「未使用」
・チケットＩＤ「Park005」、アドレス値「2468AA」、状態「使用済」
・チケットＩＤ「Bus0308」、アドレス値「2468AA」、状態「未使用」
また、チケット利用者Ａが使用するチケット利用端末１０Ａでは、３つのアドレス値「134AAA」、「AB2322」及び「13579F」が管理されているものとする。この場合、チケット利用端末１０Ａでは、任意のタイミングで、電子チケット情報１０００を参照することで、以下の電子チケットが自アドレスによって所有されていることを管理できる。

・チケットＩＤ「Park011」、アドレス値「134AAA」
・チケットＩＤ「Bus0311」、アドレス値「AB2322」
・チケットＩＤ「Park002」、アドレス値「13579F」
・チケットＩＤ「Bus0304」、アドレス値「13579F」
これは、チケット利用者Ａは３つのアドレス値「134AAA」、「AB2322」及び「13579F」を少なくとも持っており、これらのアドレス値を用いて上記の４つのチケットＩＤの電子チケットを所有していることを意味している。

同様に、チケット利用者Ｂが使用するチケット利用端末１０Ｂでは、２つのアドレス値「ABC123」及び「2468AA」が管理されているものとする。この場合、チケット利用端末１０Ｂでは、任意のタイミングで、電子チケット情報１０００を参照することで、以下の電子チケットが自アドレスによって所有されていることを管理できる。

・チケットＩＤ「Park001」、アドレス値「ABC123」
・チケットＩＤ「Bus0303」、アドレス値「ABC123」
・チケットＩＤ「Park005」、アドレス値「2468AA」
・チケットＩＤ「Bus0308」、アドレス値「2468AA」
これは、チケット利用者Ｂは２つのアドレス値「ABC123」及び「2468AA」を少なくとも持っており、これらのアドレス値を用いて上記の４つのチケットＩＤの電子チケットを所有していることを意味している。

このとき、例えば、チケット利用者ＡがチケットＩＤ「Bus0304」の電子チケットを利用する場合、チケットＩＤ「Bus0304」及びアドレス値「13579F」をサービス提供者に提示する。この提示方法は任意の方法を採用することが可能であるが、図２に示す例では、アドレス値「13579F」に対応する秘密鍵を用いてチケットＩＤ「Bus0304」から電子署名を作成した上で、この電子署名をチケットＩＤ「Bus0304」に付加したデータの二次元コードをチケット利用端末１０Ａ上に表示することで提示している。これにより、チケット確認端末２０は、当該二次元コードをカメラ等で読み取ったデータからチケットＩＤ「Bus0304」及びアドレス値「13579F」を取得することができる。なお、アドレス値は、電子署名の検証に成功した公開鍵から得ることができる。

チケットＩＤ「Bus0304」及びアドレス値「13579F」を取得したチケット確認端末２０は、ブロックチェーンネットワーク４０上の電子チケット情報１０００を参照して、チケットＩＤ「Bus0304」の電子チケットの利用可否を検証し、その検証に成功した場合は状態を「使用済」に更新する。これにより、チケットＩＤ「Bus0304」の電子チケットが使用され、チケット利用者Ａはサービス（図２に示す例では、バスによる輸送サービス）を享受することが可能となる。なお、電子チケットの利用可否の検証とは、例えば、電子チケットの所有者格納領域に格納されているアドレス値が「13579F」であること、状態が「未使用」であること、等といった検証のことである。あるいは、電子チケットに有効期間が設定されている場合（これは、電子チケット情報１０００に対して、電子チケットの有効期間が格納されるカラムを追加することで実現できる）、その電子チケットが有効期間内であるか否かの検証を行ってもよい。また、有効期間内は回数に制限なく利用できる電子チケットの場合（例えば、交通機関の１日乗車券や再入場可能なテーマパークチケット等）は、有効期間の検証のみを実行し、使用済か否かの状態の検証を省略できるため、上記の状態を「使用済」に更新するという処理を省略してもよいし、上記の状態を「使用中」等といった値に更新してもよい。上記の状態を「使用中」に更新した場合は、電子チケットの有効期間が過ぎたと検証されたときに、「使用済」に更新される。

同様に、例えば、チケット利用者ＢがチケットＩＤ「Bus0303」の電子チケットを利用する場合、チケットＩＤ「Bus0303」及びアドレス値「ABC123」をサービス提供者に提示する。そして、チケットＩＤ「Bus0303」及びアドレス値「ABC123」を取得したチケット確認端末２０は、ブロックチェーンネットワーク４０上の電子チケット情報１０００を参照して、電子チケットの利用可否を検証し、その検証に成功した場合は状態を「使用済」に更新する。これにより、チケットＩＤ「Bus0303」の電子チケットが使用され、チケット利用者Ｂはサービス（図２に示す例では、バスによる輸送サービス）を享受することが可能となる。なお、電子チケットの利用可否の検証とは、例えば、電子チケットの所有者格納領域に格納されているアドレス値が「ABC123」であること、状態が「未使用」であること、等といった検証のことである。電子チケットの有効期間が設定されている場合の検証等についても、上記と同様である。

このように、本実施例では、各チケット利用者は、複数のアドレス値を持つことが可能であり、これらのアドレス値を用いて電子チケットの所有することができる。また、上述したように、ＨＤウォレットの仕組みでは、マスター秘密鍵を知らない限り、複数のアドレス値が同一のマスター秘密鍵から得られたものであるか否かを確認することができないため、複数のアドレス値が同一のチケット利用者のものであるか否かを確認することはできない。上記の例では、アドレス値「13579F」を持つチケット利用者Ａと、アドレス値を「ABC123」を持つチケット利用者Ｂとが、別々に電子チケットを利用した例として記載したが、チケット確認端末２０（及び、これを保持しているサービス提供者）は、同一人物が別の機会に利用したのか、異なる人物が利用したのかを判別することができない。このため、アドレス値による「名寄せ」が困難となり、個人の属性や行動傾向等といったパーソナルデータの漏洩を防止することが可能になる。

なお、パーソナルデータの漏洩を効果的に防止するためには、一般に、各チケット利用者が多くのアドレス値を持ち、また何等の法則性なくアドレス値が電子チケットに用いられていることが好ましい。

（チケット利用端末１０の機能構成）
本実施例におけるチケット利用端末１０の機能構成について、図３を参照しながら説明する。図３は、実施例１におけるチケット利用端末１０の機能構成の一例を示す図である。

図３に示すように、本実施例におけるチケット利用端末１０は、チケット選択部１０１と、チケット提示部１０２と、記憶部１０３と、ウォレット１１０とを有する。チケット選択部１０１及びチケット提示部１０２は、例えば、チケット利用端末１０にインストールされた１以上のプログラムがＣＰＵ（Central Processing Unit）に実行させる処理により実現される。また、記憶部１０３は、例えば、各種記憶装置により実現される。

チケット選択部１０１は、ウォレット１１０で管理されている電子チケットの中から、チケット利用者が利用する電子チケットを選択する。

チケット提示部１０２は、チケット選択部１０１で選択された電子チケットのチケットＩＤ及びアドレス値を二次元コードにより提示する。

記憶部１０３は、ウォレット１１０で管理されている電子チケットのチケットＩＤとアドレス値を記憶する。

ウォレット１１０は、ＨＤウォレット等の複数のアドレス値を管理可能なウォレットであり、これらのアドレス値とそのアドレス値が所有者格納領域に格納されている電子チケットのチケットＩＤとを管理する。なお、ウォレット１１０は、ブロックチェーンネットワーク４０上の電子チケット情報１０００を参照して、自己が管理している電子チケットの状態等を確認することもできる。また、上述したように、ウォレット１１０は、アドレス値を生成することもできる。

（チケット確認端末２０の機能構成）
本実施例におけるチケット確認端末２０の機能構成について、図４を参照しながら説明する。図４は、実施例１におけるチケット確認端末２０の機能構成の一例を示す図である。

図４に示すように、本実施例におけるチケット確認端末２０は、チケット読取部２０１と、チケット検証部２０２と、チケット更新部２０３とを有する。これら各部は、例えば、チケット確認端末２０にインストールされた１以上のプログラムがＣＰＵに実行させる処理により実現される。

チケット読取部２０１は、チケット利用端末１０によって提示された二次元コードを読み取ることで、そのチケットＩＤ及びアドレス値を取得する。

チケット検証部２０２は、チケット読取部２０１が取得したチケットＩＤ及びアドレス値を用いて、ブロックチェーンネットワーク４０上の電子チケット情報１０００を参照し、電子チケットの利用可否を検証する。

チケット更新部２０３は、チケット検証部２０２によって電子チケットが利用可能であることが検証され、チケット利用者に対してサービスが提供された場合、当該電子チケットの状態を「使用済」に更新する。

（チケット利用の流れ）
次に、本実施例におけるチケット利用の流れについて、図５を参照しながら説明する。図５は、実施例１におけるチケット利用の流れの一例を示すシーケンス図である。

まず、チケット利用端末１０のチケット選択部１０１は、ウォレット１１０で管理されている電子チケットの中から、チケット利用者が利用する電子チケットを選択する（ステップＳ１０１）。これは、例えば、ウォレット１１０で管理されている電子チケットの一覧の中から、チケット利用者が所望の電子チケットを選択する操作を行うことで実現される。

次に、チケット利用端末１０のチケット提示部１０２は、上記のステップＳ１０１で選択された電子チケットのチケットＩＤ及びアドレス値の二次元コードを作成する（ステップＳ１０２）。例えば、チケット提示部１０２は、当該アドレス値に対応する秘密鍵を用いて当該チケットＩＤから電子署名を作成した上で、この電子署名を当該チケットＩＤに付加したデータの二次元コードを作成する。

次に、チケット利用端末１０のチケット提示部１０２は、上記のステップＳ１０２で作成した二次元コードをディスプレイ上に表示することで、チケット確認端末２０に提示する（ステップＳ１０３）。

チケット確認端末２０のチケット読取部２０１は、上記のステップＳ１０３で提示された二次元コードをカメラ等により読み取る（ステップＳ１０４）。これにより、チケット読取部２０１は、チケットＩＤと電子署名が得られ、更にこの電子署名を公開鍵で検証することでその公開鍵に対応するアドレス値が得られる。

なお、上記のステップＳ１０２～ステップＳ１０３ではチケット利用端末１０が二次元コードを提示したが、これは一例であって、これ以外の任意の方法でチケットＩＤ及びアドレス値をチケット確認端末２０に提示してもよい。例えば、バーコード等の１次元コードによりチケットＩＤ及びアドレス値をチケット確認端末２０に提示してもよいし、Ｂｌｕｅｔｏｏｔｈ（登録商標）や非接触型ＩＣカード等を介した近距離無線通信、インターネット等によりチケットＩＤ及びアドレス値をチケット確認端末２０に提示してもよい。又は、例えば、音波、光の点滅、画像等によりチケットＩＤ及びアドレス値をチケット確認端末２０に提示してもよい。

次に、チケット確認端末２０のチケット検証部２０２は、上記のステップＳ１０４で取得したチケットＩＤ及びアドレス値を用いて、ブロックチェーンネットワーク４０上の電子チケット情報１０００を参照し、電子チケットの利用可否を検証する（ステップＳ１０５）。すなわち、チケット検証部２０２は、ブロックチェーンネットワーク４０上の電子チケット情報１０００を参照して、上記のステップＳ１０４で取得したアドレス値と、当該チケットＩＤの電子チケットの所有者格納領域に格納されているアドレス値とが一致するか（つまり、当該電子チケットの所有権を有するか）、当該電子チケットの状態が「未使用」であるか、等を検証する。これ以外にも、上述したように、例えば、電子チケットに有効期間が設定されている場合はその有効期間内であるか否か等の検証を行ってもよい。

なお、上記の検証結果は、チケット利用可否通知としてチケット利用端末１０に通知されてもよい。

上記のステップＳ１０５で検証に成功した場合は、チケット利用者に対してサービスが提供される。例えば、当該電子チケットがバスの乗車チケットである場合は、バスへの乗車が許可される。又は、例えば、当該電子チケットが駐車チケットである場合は、駐車場のゲートが開き、駐車が許可される。又は、例えば、当該電子チケットが商品の提供を受けるためのチケットである場合は、チケット利用者に商品が引き渡される。

その後、チケット確認端末２０のチケット更新部２０３は、上記のステップＳ１０４で取得したチケットＩＤの電子チケットの状態を「使用済」に更新するためのトランザクション（以下、「チケット利用トランザクション」ともいう。）を作成する（ステップＳ１０６）。なお、チケット利用トランザクションには、サービス提供者の秘密鍵を用いて作成された電子署名が付加される。

そして、チケット確認端末２０のチケット更新部２０３は、上記のステップＳ１０６で作成したチケット利用トランザクションをブロックチェーンネットワーク４０に送信する（ステップＳ１０７）。これにより、このチケット利用トランザクションがブロックチェーンネットワーク４０内の各ノード３０で検証され、その検証に成功した場合は、当該電子チケットの状態が「使用済」に更新される。

なお、上記のステップＳ１０６～ステップＳ１０７では電子チケットの状態を「使用済」に更新したが、これに限られず、チケット利用者が当該電子チケットを再度利用できないような状態すれば任意の方法を採用することができる。例えば、当該電子チケット自体を削除してもよいし、当該電子チケットの所有権をサービス提供者に移転するようにしてもよい。

ここで、例えば、ERC721では電子チケット（トークン）を更新可能な者は、トークンの所有者（及び、承認されたアドレス値、現在の所有者から認証された者）に限られている。このため、電子チケットの所有者がチケット利用者である場合、通常は、サービス提供者がチケット利用トランザクションを作成及び送信して、当該電子チケットを更新することはできない。そこで、上記のステップＳ１０６～ステップＳ１０７でサービス提供者がチケット利用トランザクションを作成及び送信するには、このチケット利用トランザクションにより電子チケットの更新が可能なスマートコントラクトがデプロイされている必要がある。このようなスマートコントラクトは、例えば、電子チケットの所有権の移転であれば、transferFrom関数を修正することで実現することができる。より具体的には、transferFrom関数の実行条件文requireに対して、ＯＲ条件として、スマートコントラクトの管理者（サービス提供者）であれば真値を返す関数isContractOwer()を追加することが実現することができる。

なお、上記のチケット利用トランザクションをチケット確認端末２０が作成するのではなく、チケット利用端末１０が作成し、例えば、二次元コードによりチケット確認端末２０に提示してもよい。この場合、トークンの所有者であるチケット利用者によってチケット利用トランザクションが作成されているため、上記のスマートコントラクトの修正は不要である。

［実施例２］
以下、本実施形態の実施例２について説明する。実施例１では各チケット利用者が予め電子チケットを購入済であるものとしたが、実際には、各チケット利用者は電子チケットを購入等する必要がある。この際、各チケット利用者は自身のアドレス値をチケット販売者に通知し、クレジットカード等の決済手段によりチケット代金を支払う必要がある。このため、例えば、同一のクレジットカードで決済することにより複数のアドレス値が同一のチケット利用者のものであることが特定されてしまう。一方で、アドレス値毎に決済手段を準備することは、アドレス値が多い場合には不可能である。

このため、本実施例では、各チケット利用者は、自身が信頼するチケット販売者のみにアドレス値を通知し、電子チケットを購入する場合について説明する。ただし、本実施例では、各電子チケットの所有権はサービス提供者からチケット販売者に移転済であるものとする。チケット利用者が信頼するチケット販売者としては、例えば、サービス提供者から委託等を受けて電子チケットを販売する旅行代理店等が挙げられる。

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

（電子チケット管理システム１の全体構成）
実施例２における電子チケット管理システム１の全体構成について、図６を参照しながら説明する。図６は、実施例２における電子チケット管理システム１の全体構成の一例を示す図である。

図６に示すように、本実施例における電子チケット管理システム１には、１以上の販売サーバ５０が更に含まれる。販売サーバ５０は、ブロックチェーンネットワーク４０に接続されている。

販売サーバ５０は、各チケット利用者が信頼するチケット販売者が管理するサーバである。チケット販売者は、販売サーバ５０により各チケット利用者に電子チケットを販売し、その所有権を当該チケット利用者に移転することができる。

なお、図６に示す例では、１つのチケット販売者のみが存在するが、複数のチケット販売者が存在してもよい。また、チケット利用者に応じて、当該チケット販売者が信頼するチケット販売者が異なっていてもよい。

（実施例２の概要）
本実施例の概要について、図７を参照しながら説明する。図７は、実施例２の概要を説明するための図である。

図７に示すように、販売サーバ５０は、ユーザ管理情報２０００を保持しているものとする。このユーザ管理情報２０００は、販売サーバ５０におけるチケット利用者の識別子を示す「ユーザＩＤ」と、このチケット利用者が決済に利用する「クレジットカード番号」と、このチケット利用者の利用する「アドレス値」とが含まれるレコードで構成されている。

例えば、図７に示す例では、ユーザ管理情報２０００は、以下の５レコードで構成されている。

・ユーザＩＤ「user001」、クレジットカード番号「xxxx-xxxx-xxxx-xxxx」、アドレス値「134AAA」
・ユーザＩＤ「user001」、クレジットカード番号「xxxx-xxxx-xxxx-xxxx」、アドレス値「AB2322」
・ユーザＩＤ「user001」、クレジットカード番号「xxxx-xxxx-xxxx-xxxx」、アドレス値「13579F」
・ユーザＩＤ「user002」、クレジットカード番号「yyyy-yyyy-yyyy-yyyy」、アドレス値「ABC123」
・ユーザＩＤ「user002」、クレジットカード番号「yyyy-yyyy-yyyy-yyyy」、アドレス値「2468AA」
これは、チケット利用者Ａ（ユーザＩＤ「user001」）のクレジットカード番号は「xxxx-xxxx-xxxx-xxxx」であり、３つのアドレス値「134AAA」、「AB2322」及び「13579F」を持っていることを意味している。同様に、チケット利用者Ｂ（ユーザＩＤ「user002」）のクレジットカード番号は「yyyy-yyyy-yyyy-yyyy」であり、２つのアドレス値「ABC123」及び「2468AA」を持っていることを意味している。なお、チケット利用者Ａ及びチケット利用者Ｂは、チケット販売者との間で事前にユーザ登録等を行って、ユーザＩＤの発行とクレジットカード番号の登録とが行われているものとしている。ただし、クレジットカード番号は決済に用いられる情報の一例であって、これに限られず、例えば、銀行口座番号や電子マネーの口座番号等の他の情報であってもよい。

このとき、例えば、チケット利用者Ａが或る電子チケットを購入する場合、自身のユーザＩＤとアドレス値を販売サーバ５０に通知する。そして、販売サーバ５０は、チケット利用者Ａのクレジットカード番号で電子チケットの代金を決済した上で、当該電子チケットの所有者格納領域に格納されているアドレス値を、チケット利用者Ａから通知されたアドレス値に更新する。これにより、当該電子チケットの所有権がチケット利用者Ａに移転され、当該電子チケットのチケットＩＤがチケット利用者Ａに通知される。なお、電子チケットのアドレス値を更新するには、販売サーバ５０は、そのためのトランザクション（以下、「チケット移転トランザクション」ともいう。）を作成し、ブロックチェーンネットワーク４０に送信する必要がある。

同様に、例えば、チケット利用者Ｂが或る電子チケットを購入する場合、自身のユーザＩＤとアドレス値を販売サーバ５０に通知する。そして、販売サーバ５０は、チケット利用者Ｂのクレジットカード番号で電子チケットの代金を決済した上で、当該電子チケットの所有者格納領域に格納されているアドレス値を、チケット利用者Ｂから通知されたアドレス値に更新する。これにより、当該電子チケットの所有権がチケット利用者Ｂに移転され、当該電子チケットのチケットＩＤがチケット利用者Ｂに通知される。

このように、本実施例では、各チケット利用者は、自身が信頼するチケット販売者に対してのみアドレス値を通知し、このチケット販売者から電子チケットを購入する。これにより、各電子チケット購入の際に同一の決済手段を用いたとしても、チケット利用者が信頼するチケット販売者以外の者は当該チケット利用者がどのアドレス値を持っているかを特定することができないため、実施例１で説明したパーソナルデータの漏洩防止を実現することが可能となる。

（チケット利用端末１０の機能構成）
本実施例におけるチケット利用端末１０の機能構成について、図８を参照しながら説明する。図８は、実施例２におけるチケット利用端末１０の機能構成の一例を示す図である。

図８に示すように、本実施例におけるチケット利用端末１０は、チケット購入部１０４を更に有する。チケット購入部１０４は、例えば、チケット利用端末１０にインストールされた１以上のプログラムがＣＰＵに実行させる処理により実現される。

チケット購入部１０４は、電子チケットを購入する際に、ユーザＩＤとアドレス値とを販売サーバ５０に通知する。なお、ユーザＩＤは、記憶部１０３に記憶されている。

（販売サーバ５０の機能構成）
本実施例における販売サーバ５０の機能構成について、図９を参照しながら説明する。図９は、実施例２における販売サーバ５０の機能構成の一例を示す図である。

図９に示すように、本実施例における販売サーバ５０は、決済部５０１と、チケット移転部５０２と、記憶部５０３とを有する。決済部５０１及びチケット移転部５０２は、例えば、販売サーバ５０にインストールされた１以上のプログラムがＣＰＵに実行させる処理により実現される。また、記憶部５０３は、例えば、各種記憶装置により実現される。

決済部５０１は、チケット利用端末１０から通知されたユーザＩＤに対応するクレジット番号を用いて、電子チケットの代金を決済する。

チケット移転部５０２は、チケット利用端末１０から通知されたアドレス値を用いて、チケット移転トランザクションを作成及び送信する。

記憶部５０３は、ユーザ管理情報２０００を記憶する。なお、記憶部５０３には、例えば、販売対象の電子チケットのチケットＩＤやそのチケット代等の情報も記憶されている
（チケット購入の流れ）
次に、本実施例におけるチケット購入の流れについて、図１０を参照しながら説明する。図１０は、実施例２におけるチケット購入の流れの一例を示すシーケンス図である。

まず、チケット利用端末１０のチケット購入部１０４は、電子チケットを購入する際に、ユーザＩＤ及びアドレス値が含まれる電子チケット購入要求を販売サーバ５０に送信する（ステップＳ２０１）。これにより、ユーザＩＤ及びアドレス値が販売サーバ５０に通知される。なお、電子チケット購入要求には、例えば、チケット利用者が購入を所望する電子チケットのチケットＩＤが含まれていてもよい。また、電子チケット購入要求に含まれるアドレス値は、記憶部１０３に予め記憶されているアドレス値であってもよいし、ウォレット１１０で新たに生成したアドレス値であってもよい。

販売サーバ５０の決済部５０１は、記憶部５０３に記憶されているユーザ管理情報２０００を参照して、上記のステップＳ２０１で通知されたユーザＩＤに対応するクレジットカード番号によりチケット代を決済する（ステップＳ２０２）。

販売サーバ５０のチケット移転部５０２は、上記のステップＳ２０２の決済が完了すると、上記のステップＳ２０１で通知されたアドレス値を移転先として指定したチケット移転トランザクションを作成する（ステップＳ２０３）。このチケット移転トランザクションは、該当の電子チケットの所有者格納領域のアドレス値を、新たな所有者のアドレス値に更新するためのトランザクションである。なお、チケット移転トランザクションには、更新対象の電子チケットのチケットＩＤも指定される。また、チケット移転トランザクションには、チケット販売者の秘密鍵を用いて作成された電子署名が付加される。

そして、販売サーバ５０のチケット移転部５０２は、上記のステップＳ２０３で作成したチケット移転トランザクションをブロックチェーンネットワーク４０に送信する（ステップＳ２０４）。これにより、該当の電子チケットの所有者格納領域のアドレス値が更新され、この電子チケットの所有権がチケット利用者に移転される。なお、当該電子チケットのチケットＩＤは、上記のステップＳ２０１で電子チケット購入要求を行ったチケット利用端末１０に通知される。

＜まとめ＞
以上のように、実施例１における電子チケット管理システム１では、ＨＤウォレット等の複数のアドレス値を管理可能なウォレットを用いて、チケット利用端末１０で複数のアドレス値を管理することができる。このため、ブロックチェーンネットワーク４０上の共有情報（電子チケット情報１０００）を第三者が参照しても、どのアドレス値がどのチケット利用者のものであるかを知ることができないため、アドレス値の「名寄せ」が困難になり、パーソナルデータの漏洩を防止することが可能となる。

また、実施例２における電子チケット管理システム１では、各チケット利用者は自身が信頼するチケット販売者にのみ自身のアドレス値を通知し、電子チケットを購入することができる。これにより、電子チケットの購入に伴う決済手段をアドレス値毎に準備する必要がなく、例えば、１つの決済手段のみを用いた場合であっても、上記のパーソナルデータの漏洩防止を実現することが可能となる。

なお、本実施形態では、ブロックチェーンネットワーク４０上で共有情報として電子チケット情報１０００が管理されている場合について説明したが、必ずしもこれに限られず、電子チケットの自由な流通と電子チケットの不正利用及び不正取引の防止とが実現されていれば、集中ＤＢ（データベース）によって電子チケット情報１０００が管理されていてもよい。

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

１ 電子チケット管理システム
１０ チケット利用端末
２０ チケット確認端末
３０ ノード
４０ ブロックチェーンネットワーク
５０ 販売サーバ
１０１ チケット選択部
１０２ チケット提示部
１０３ 記憶部
１０４ チケット購入部
１１０ ウォレット
２０１ チケット読取部
２０２ チケット検証部
２０３ チケット更新部
５０１ 決済部
５０２ チケット移転部
５０３ 記憶部

Claims (7)

1. 所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムにおけるデータ管理方法であって、
   前記利用者端末が、前記データを識別するデータＩＤと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている１つのアドレス値とを前記提供者端末に提示する提示手順と、
   前記提供者端末が、前記提示手順で提示されたデータＩＤとアドレス値とを用いて、前記データＩＤで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、
   を実行するデータ管理方法。
2. 前記提供者端末が、前記検証手順によって前記データが利用可能であることが検証された場合、単数又は複数のノード上で共有情報として管理されている前記データを再利用不可能な状態に更新する更新手順、を実行する、請求項１に記載のデータ管理方法。
3. 前記更新手順は、
   前記データを再利用不可能な状態に更新するための第１の更新用データであって、更新対象のデータを識別するデータＩＤを指定した第１の更新用データを、前記単数又は複数のノードに送信することで、前記データを再利用不可能な状態に更新する、請求項２に記載のデータ管理方法。
4. 前記データを再利用不可能な状態に更新することには、前記データを使用済に更新する、前記データの所有権を前記提供者に移転する、前記データを削除する、ことが含まれる、請求項３に記載のデータ管理方法。
5. 前記データ管理システムには、前記データを販売する販売者の販売サーバが含まれ、
   前記利用者端末が、前記データを購入する際に、前記複数のアドレス値のうちの１つ以上のアドレス値を前記販売サーバに通知する通知手順と、
   前記販売サーバが、前記データに関する代金決済に応じて、前記データの所有者として設定されているアドレス値を、前記通知手順で前記利用者端末から通知されたアドレス値に更新することで、前記データの所有権を前記利用者に移転する移転手順と、
   を実行する、請求項１に記載のデータ管理方法。
6. 前記移転手順は、
   単数又は複数のノード上で共有情報として管理されている前記データのアドレス値を更新するための第２の更新用データであって、更新対象のデータを識別するデータＩＤと、前記通知手順で前記利用者端末から通知されたアドレス値を更新後のアドレス値として指定した第２の更新用データを、前記単数又は複数のノードに送信することで、前記データの所有者として設定されているアドレス値を、前記通知手順で前記利用者端末から通知されたアドレス値に更新する、請求項５に記載のデータ管理方法。
7. 所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムに用いられるデータ管理プログラムであって、
   前記利用者端末が、前記データを識別するデータＩＤと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている１つのアドレス値とを前記提供者端末に提示する提示手順と、
   前記提供者端末が、前記提示手順で提示されたデータＩＤとアドレス値とを用いて、前記データＩＤで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、
   を実行させるデータ管理プログラム。

Images