(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022133057
(43)【公開日】2022-09-13
(54)【発明の名称】データ管理方法及びデータ管理プログラム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20220906BHJP
G16Y 40/50 20200101ALI20220906BHJP
【FI】
G06Q50/10
G16Y40/50
【審査請求】未請求
【請求項の数】7
【出願形態】OL
(21)【出願番号】P 2021031880
(22)【出願日】2021-03-01
(71)【出願人】
【識別番号】000102717
【氏名又は名称】NTTテクノクロス株式会社
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(72)【発明者】
【氏名】宮崎 泰彦
(72)【発明者】
【氏名】滝江 勇介
(72)【発明者】
【氏名】深津 颯騎
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC11
(57)【要約】
【課題】ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止すること。
【解決手段】一実施形態に係るデータ管理方法は、所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムにおけるデータ管理方法であって、前記利用者端末が、前記データを識別するデータIDと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている1つのアドレス値とを前記提供者端末に提示する提示手順と、前記提供者端末が、前記提示手順で提示されたデータIDとアドレス値とを用いて、前記データIDで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、を実行する。
【選択図】
図2
【特許請求の範囲】
【請求項1】
所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムにおけるデータ管理方法であって、
前記利用者端末が、前記データを識別するデータIDと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている1つのアドレス値とを前記提供者端末に提示する提示手順と、
前記提供者端末が、前記提示手順で提示されたデータIDとアドレス値とを用いて、前記データIDで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、
を実行するデータ管理方法。
【請求項2】
前記提供者端末が、前記検証手順によって前記データが利用可能であることが検証された場合、単数又は複数のノード上で共有情報として管理されている前記データを再利用不可能な状態に更新する更新手順、を実行する、請求項1に記載のデータ管理方法。
【請求項3】
前記更新手順は、
前記データを再利用不可能な状態に更新するための第1の更新用データであって、更新対象のデータを識別するデータIDを指定した第1の更新用データを、前記単数又は複数のノードに送信することで、前記データを再利用不可能な状態に更新する、請求項2に記載のデータ管理方法。
【請求項4】
前記データを再利用不可能な状態に更新することには、前記データを使用済に更新する、前記データの所有権を前記提供者に移転する、前記データを削除する、ことが含まれる、請求項3に記載のデータ管理方法。
【請求項5】
前記データ管理システムには、前記データを販売する販売者の販売サーバが含まれ、
前記利用者端末が、前記データを購入する際に、前記複数のアドレス値のうちの1つ以上のアドレス値を前記販売サーバに通知する通知手順と、
前記販売サーバが、前記データに関する代金決済に応じて、前記データの所有者として設定されているアドレス値を、前記通知手順で前記利用者端末から通知されたアドレス値に更新することで、前記データの所有権を前記利用者に移転する移転手順と、
を実行する、請求項1に記載のデータ管理方法。
【請求項6】
前記移転手順は、
単数又は複数のノード上で共有情報として管理されている前記データのアドレス値を更新するための第2の更新用データであって、更新対象のデータを識別するデータIDと、前記通知手順で前記利用者端末から通知されたアドレス値を更新後のアドレス値として指定した第2の更新用データを、前記単数又は複数のノードに送信することで、前記データの所有者として設定されているアドレス値を、前記通知手順で前記利用者端末から通知されたアドレス値に更新する、請求項5に記載のデータ管理方法。
【請求項7】
所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムに用いられるデータ管理プログラムであって、
前記利用者端末が、前記データを識別するデータIDと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている1つのアドレス値とを前記提供者端末に提示する提示手順と、
前記提供者端末が、前記提示手順で提示されたデータIDとアドレス値とを用いて、前記データIDで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、
を実行させるデータ管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ管理方法及びデータ管理プログラムに関する。
【背景技術】
【0002】
何等かのサービスを受けるために、予約手続きや購入手続き等を行ってチケットを入手し、サービスの提供を受ける際に当該チケットをサービス提供者に提示等することが行われている。このようなチケットは紙等により物理的に実現されることが多いが、近年では、電子データとして電磁的方法に実現されることもある。なお、電磁的方法に実現されたチケットのことを「電子チケット」と呼ぶこともある。
【0003】
電子データはコピー等が容易であるため、適切な防止策が施されない場合、電子チケットは不正利用や不正取引等が行なわれ易いという課題がある。この課題に関連する従来技術として、例えば、特許文献1に記載されている技術や特許文献2に記載されている技術等がある。
【0004】
また、近年では、分散共有台帳等とも呼ばれるブロックチェーンを利用して電子チケットを実現する技術も存在する(例えば、非特許文献1)。この技術ではブロックチェーン上で電子チケットが管理されるため、電子チケットの自由な流通を実現しつつ、不正利用及び不正取引を防止することが可能になる。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2002-149887号公報
【特許文献2】特開2011-76520号公報
【非特許文献】
【0006】
【非特許文献1】ContractGate/Pass, インターネット<URL:https://www.ntt-tx.co.jp/products/contractgate/pass.html>
【発明の概要】
【発明が解決しようとする課題】
【0007】
ブロックチェーンを利用した電子チケットでは、どのアドレス値を持つ利用者がどの電子チケットを所有し、またその電子チケットをどのように利用したかが分散共有台帳上に記録される。このため、氏名、住所、電話番号、クレジットカード番号等といった個人の特定につながる情報がアドレス値と紐づかないように管理する必要がある。しかしながら、その場合であっても、アドレス値で「名寄せ」することにより、個人の属性や行動傾向等といったパーソナルデータが漏洩する恐れがある。
【0008】
例えば、平日にほぼ毎日、Aバス停からBバス停までの往復バスチケットを利用しているアドレス値があった場合、そのアドレス値を持つ利用者は、Aバス停付近に住み、Bバス停付近に職場がある者であると推定される。また、そのアドレス値で、特定の店舗でのサービス利用チケットの購入や利用があると、その店舗を利用する者であると推定又は特定される。このように、アドレス値の「名寄せ」により、そのアドレス値を持つ利用者の自宅、職場、趣味、嗜好、行動範囲等といった属性や行動傾向が推定又は特定され得る。
【0009】
更に、もし仮に、一旦個人が特定されると、そのアドレス値でのチケット所有や利用により様々なパーソナルデータが漏洩するリスクがより高くなる。
【0010】
本発明の一実施形態は、上記の点に鑑みてなされたもので、ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止することを目的とする。
【課題を解決するための手段】
【0011】
上記目的を達成するため、一実施形態に係るデータ管理方法は、所定のデータの利用に応じて役務又は商品を提供する提供者の提供者端末と、前記データを利用して前記役務又は商品の提供を受ける利用者の利用者端末とが含まれるデータ管理システムにおけるデータ管理方法であって、前記利用者端末が、前記データを識別するデータIDと、前記利用者が持つ複数のアドレス値のうち、前記データの所有者として設定されている1つのアドレス値とを前記提供者端末に提示する提示手順と、前記提供者端末が、前記提示手順で提示されたデータIDとアドレス値とを用いて、前記データIDで識別されるデータの所有者として前記アドレス値が設定されているか否かを含む利用可否を検証する検証手順と、を実行する。
【発明の効果】
【0012】
ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止することができる。
【図面の簡単な説明】
【0013】
【
図1】実施例1における電子チケット管理システムの全体構成の一例を示す図である。
【
図3】実施例1におけるチケット利用端末の機能構成の一例を示す図である。
【
図4】実施例1におけるチケット確認端末の機能構成の一例を示す図である。
【
図5】実施例1におけるチケット利用の流れの一例を示すシーケンス図である。
【
図6】実施例2における電子チケット管理システムの全体構成の一例を示す図である。
【
図8】実施例2におけるチケット利用端末の機能構成の一例を示す図である。
【
図9】実施例2における販売サーバの機能構成の一例を示す図である。
【
図10】実施例2におけるチケット購入の流れの一例を示すシーケンス図である。
【発明を実施するための形態】
【0014】
以下、本発明の実施形態(以降、「本実施形態」とも表す。)について説明する。本実施形態では、ブロックチェーン上で管理された電子チケットの利用に伴うパーソナルデータの漏洩を防止することができる電子チケット管理システム1について説明する。この電子チケット管理システム1により、パーソナルデータの漏洩を防止しつつ、電子チケットの自由な流通と不正利用及び不正取引の防止とを両立させることが可能となる。なお、本実施形態では、電子チケットを単に「チケット」とも表す。ただし、「電子チケット」又は「チケット」は何等かのサービス(役務)や商品(情報等を含む)の提供や譲渡等を受けるためのデータの一例であって、本実施形態は電子チケット又はチケット以外にも、このようなデータに対して同様に適用可能である。
【0015】
本実施形態に係る電子チケット管理システム1では、電子チケットの自由な流通と不正利用及び不正取引の防止とを実現するために、ブロックチェーン技術(又は「分散台帳技術」とも呼ばれる。)を利用したプラットフォームを用いる。ブロックチェーン技術を利用したプラットフォームの具体例としては、Ethereum(登録商標)が挙げられる。本実施形態に係る電子チケット管理システム1は、一例として、Ethereumを用いて実現されているものとする。ただし、これは一例であって、本実施形態に係る電子チケット管理システム1は、任意のブロックチェーン技術を利用したプラットフォーム(例えば、Hyperledger(登録商標) Fabric等)を用いて実現することが可能である。
【0016】
ブロックチェーン技術の主な特徴としては、以下の(1)~(5)が挙げられる。
【0017】
(1)システム(つまり、ブロックチェーン技術を利用したプラットフォームを用いて実現されたシステム)の利用者は、公開鍵暗号に基づいて生成可能なアドレス値と呼ばれる識別子で区別される。
【0018】
(2)共有情報(つまり、システム内で共有される情報)の内容を更新するためには、トランザクションを作成及び送信する必要がある。なお、トランザクションの作成を「トランザクション発行」と呼ぶこともある。
【0019】
(3)トランザクションには、秘密鍵に基づく電子署名を付加する必要がある。電子署名が付加されることにより、特定のトランザクションが、どのアドレス値の利用者によって作成されたのかを、システムの参加者全員により検証される。
【0020】
(4)スマートコントラクトと呼ばれる仕組みを利用することができる。スマートコントラクトとは、トランザクションに対して共有情報をどのように更新するか(共有情報を更新しない場合も含む。)という手続きが定義されたプログラムであり、その手続きは事前にシステムの参加者全員で合意される必要がある。スマートコントラクトがデプロイ(つまり、利用可能な状態になる)された場合、当該スマートコントラクトにはアドレス値が付与される(なお、Hyperledger Fabricの場合はChaincode IDが付与される。)。
【0021】
(5)有効なトランザクションをどの順でスマートコントラクトにより処理するかを、システムの参加者全員で最終的に合意を取ることが可能である。このため、或る程度の時間をかけることで、システムの参加者全員が確実に同一の情報を共有することができる。なお、どの程度の時間をかける必要があるかは合意形成アルゴリズムによって異なるが、数秒から数十秒程度が一般的である。
【0022】
上記の(1)~(5)の特徴により、ブロックチェーン技術を利用したプラットフォームを用いてシステムを実現することで、参加者間に必ずしも信頼関係があるとは限らない場合であっても、トランザクションの発行者を検証した上で、情報を共有することが可能になる。
【0023】
<電子チケットの実現方法>
ここで、Ethereumにおけるスマートコントラクトの規格の1つとして、ERC721と呼ばれる規格が知られている。ERC721はスマートコントラクト内で代替不可能なトークン(NFT:Non-Fungible Token)を扱えるようにした規格であり、ERC721を用いることでトークンの所有権等を管理することができるようになる。トークンには所有権を有するユーザ(以降、「所有者」とも表す。)を示すアドレス値を格納するためのデータ領域(以降、「所有者格納領域」とも表す。)があり、この所有者格納領域に格納されているアドレス値を書き換えるためには、現時点の所有者等が、新たな所有者を示すアドレス値を指定したトランザクションを発行及び送信する必要がある。所有者格納領域に格納されているアドレス値が、新たな所有者を示すアドレス値に書き換わることで、新たな所有者は所有権を獲得することなり、元の所有者は所有権を失うことなる。
【0024】
そこで、本実施形態に係る電子チケット管理システム1では、ERC721に準拠したスマートコントラクトを利用して、電子チケットをトークンにより実現する。これにより、必ずしも互いに信頼関係があるとは限らない者の間における電子チケットの自由な流通を実現しつつ、電子チケットの二重譲渡等の不正取引を防止することが可能となる。また、電子チケットを利用する際にその所有権等をサービス提供者が確認することで、電子チケットの不正利用を防止することが可能になる。
【0025】
なお、電子チケットの利用によって享受可能なサービスは特定のサービスに限定されず、任意のサービスに対して適用可能である。電子チケットの利用によって享受可能なサービスの典型的な例としては、コンサート鑑賞、映画鑑賞、遊園地や動物園等のテーマパークへの入場、テーマパークにおけるアトラクション体験、飲食店における飲食物の提供、交通機関(例えば、電車、バス、タクシー、飛行機等)の利用、デジタルコンテンツ(例えば、音楽ファイル、動画ファイル等)の提供等が挙げられる。また、電子チケットの利用によってサービスを享受する場合以外にも、例えば、電子チケットの利用によって、指定された物品(例えば、景品等)が引き渡される場合に対しても適用可能である。
【0026】
<アドレス値の生成方法>
ブロックチェーン技術では、基本的に、公開鍵暗号に基づいて利用者自身によりアドレス値が生成される。すなわち、利用者自身でまず秘密鍵を作成し、予め決められたアルゴリズムによってその秘密鍵と対になる公開鍵を作成する。ブロックチェーン技術におけるアドレス値は、この公開鍵に対応して決定される。上記の(2)及び(3)で説明したように、ブロックチェーン上の共有情報である電子チケットを更新するためのトランザクションには、当該秘密鍵に基づく電子署名を付加する必要である。このような秘密鍵の生成や電子署名の付加等といった機能を提供するソフトウェアは、一般には、ウォレットと呼ばれる。
【0027】
ウォレットには、単に1組の秘密鍵・公開鍵(つまり、1つのアドレス値)を管理するだけなく、複数の組の秘密鍵・公開鍵(つまり、複数のアドレス値)を管理できるものもある。例えば、BIP-032(https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)として公開されているHDウォレット(階層的決定性ウォレット)呼ばれる仕組みがある。このHDウォレットの仕組みでは、まず、1つのマスター秘密鍵を作成し、そのマスター秘密鍵に基づいて階層的に秘密鍵を作成することができる。このため、階層的に作成された複数の秘密鍵の各々に対してその対となる公開鍵を作成することができるため、階層的に複数のアドレス値を管理することが可能となる。
【0028】
HDウォレットの仕組みでは、複数のアドレス値があったときに、マスター秘密鍵を知らない限り、それらのアドレス値が、同一のマスター秘密鍵から作成された秘密鍵と対になる公開鍵によって生成されたものであるか否かを確認することができない、という特徴がある。具体的には、例えば、アドレス値A1とアドレス値A2とがあったときに、アドレス値A1とアドレス値A2とが、同一のマスター秘密鍵から作成された秘密鍵と対になる公開鍵によって生成されたものであるか、異なるマスター秘密鍵から作成された秘密鍵と対になる公開鍵によって生成されたものであるかを確認することができない。
【0029】
そこで、本実施形態に係る電子チケット管理システム1では、利用者は、HDウォレット等の複数のアドレス値を管理可能なウォレットを用いて、複数のアドレス値を利用するものとする。これにより、アドレス値による「名寄せ」が困難となり、個人の属性や行動傾向等といったパーソナルデータの漏洩を防止することが可能になる。なお、HDウォレットは一例であって、複数のアドレス値を管理可能なウォレットであれば、本実施形態は同様に適用可能である。また、例えば、1以上のアドレス値を管理可能なウォレットを複数使用して、各チケット利用者が複数のアドレス値を利用可能としてもよく、このような場合でも本実施形態は同様に適用可能である。
【0030】
複数のアドレス値を管理可能なウォレットを用いて、どのようにアドレス値を管理するかは様々に考えられ、利用者の利便性や電子チケットの性質等を鑑みて任意に設定することが可能である。例えば、電子チケットの種類や目的等に応じてアドレス値を異ならせてもよいし、日や月、期間に応じてアドレス値を異ならせてもよいし、電子チケット毎にアドレス値を異ならせてもよい。
【0031】
電子チケットの種類や目的等に応じてアドレス値を異ならせる具体例としては、例えば、コンサート鑑賞や映画鑑賞用の電子チケットと、交通機関を利用するための電子チケットとでアドレス値を異ならせる等が挙げられる。なお、これに加えて、例えば、一定期間の経過に伴って、それ以降に購入等した電子チケットに使用するアドレス値を異ならせてもよい。
【0032】
ここで、例えば、HDウォレットで2階層目の秘密鍵を生成する場合、m/i/j(ただし、i及びjは適当な数値)というパラメータを指定することができる。このため、例えば、日付毎にアドレス値を異ならせる場合、2021年1月15日分の電子チケットに使用するアドレス値は、m/0/20210115をパラメータとして秘密鍵を生成し、この秘密鍵と対になる公開鍵から生成すればよい。同様に、電子チケットの種類や目的等に応じてアドレス値を異ならせる場合も、その種類や目的等に応じて異なるパラメータを指定すればよい。
【0033】
なお、パラメータが同じであっても、マスター秘密鍵が異なる場合は、当然ながら異なる秘密鍵が生成され、その結果、アドレス値も異なる。また、上記では、簡単のため秘密鍵の階層構造が2階層である場合について説明したが、2階層に限られず、3階層以上であってもよい。
【0034】
[実施例1]
以下、本実施形態の実施例1について説明する。実施例1では、各利用者(以下、「チケット利用者」ともいう。)は複数のアドレス値をウォレットで管理しており、これら複数のアドレス値を用いて電子チケットを購入等したものとし、それらの電子チケットを利用する場合について説明する。
【0035】
(電子チケット管理システム1の全体構成)
実施例1における電子チケット管理システム1の全体構成について、
図1を参照しながら説明する。
図1は、実施例1における電子チケット管理システム1の全体構成の一例を示す図である。
【0036】
図1に示すように、本実施例における電子チケット管理システム1には、1以上のチケット利用端末10と、1以上のチケット確認端末20とが含まれる。また、これらの各端末は、P2P(Peer to Peer)接続された各ノード30によって形成されているブロックチェーンネットワーク40に接続されている。
【0037】
チケット利用端末10は、電子チケットを利用してサービスを享受するチケット利用者が使用する端末である。チケット利用者は、チケット利用端末10を用いて電子チケットを利用し、サービスを享受することができる。チケット利用端末10としては、例えば、スマートフォン、タブレット端末、携帯型ゲーム機器、ウェアラブルデバイス、PC(パーソナルコンピュータ)等の各種端末を用いることができる。ここで、チケット利用端末10には複数のアドレス値を管理可能なウォレットがインストールされており、このウォレットによってチケット利用者が所有している電子チケット(つまり、当該チケット利用者のアドレス値が所有者格納領域に格納されている電子チケット)も管理されているものとする。
【0038】
なお、複数のチケット利用端末10の各々を区別する場合は、「チケット利用端末10A」、「チケット利用端末10B」等と表記する。
【0039】
チケット確認端末20は、サービス提供者が使用する端末である。サービス提供者は、チケット確認端末20を用いて、チケット利用者が電子チケットを利用する際にその所有権等を確認することができる。チケット確認端末20としては、例えば、スマートフォン、タブレット端末、PC等の各種端末を用いることができる。ただし、これに限られず、チケット確認端末20は、例えば、サービスを提供する施設等の入口(例えば、テーマパークの入口、コンサート会場の入口、駅のホームへの入口等)に設置等されるゲート装置等であってもよいし、バスや電車等の車両の乗車口に設置されるゲート装置等であってもよい。これ以外にも、例えば、電子チケットの提示と引き換えに商品の提供を受けるためのレジスター等であってもよい。
【0040】
なお、複数のチケット確認端末20の各々を区別する場合は、「チケット確認端末20A」、「チケット確認端末20B」等と表記する。
【0041】
図1に示す電子チケット管理システム1の構成は一例であって、他の構成であってもよい。例えば、チケット確認端末20は必ずしもサービス提供が使用する端末である必要はなく、サービス提供者から委託を受けた委託先、協力会社、関連会社等が使用する端末であってもよい。
【0042】
(実施例1の概要)
本実施例の概要について、
図2を参照しながら説明する。
図2は、実施例1の概要を説明するための図である。
【0043】
図2に示すように、ブロックチェーンネットワーク40内の各ノードは、共有情報として電子チケット情報1000を保持しているものとする。この電子チケット情報1000は、電子チケットの識別子を示す「チケットID」と、この電子チケットの所有者を示す「アドレス値」と、この電子チケットの使用状態(例えば、電子チケットが使用済か否か等)を示す「状態」とが含まれるレコードで構成されている。
【0044】
例えば、
図2に示す例では、電子チケット情報1000は、以下の8レコードで構成されている。
【0045】
・チケットID「Park001」、アドレス値「ABC123」、状態「使用済」
・チケットID「Bus0303」、アドレス値「ABC123」、状態「未使用」
・チケットID「Park011」、アドレス値「134AAA」、状態「未使用」
・チケットID「Bus0311」、アドレス値「AB2322」、状態「未使用」
・チケットID「Park002」、アドレス値「13579F」、状態「使用済」
・チケットID「Bus0304」、アドレス値「13579F」、状態「未使用」
・チケットID「Park005」、アドレス値「2468AA」、状態「使用済」
・チケットID「Bus0308」、アドレス値「2468AA」、状態「未使用」
また、チケット利用者Aが使用するチケット利用端末10Aでは、3つのアドレス値「134AAA」、「AB2322」及び「13579F」が管理されているものとする。この場合、チケット利用端末10Aでは、任意のタイミングで、電子チケット情報1000を参照することで、以下の電子チケットが自アドレスによって所有されていることを管理できる。
【0046】
・チケットID「Park011」、アドレス値「134AAA」
・チケットID「Bus0311」、アドレス値「AB2322」
・チケットID「Park002」、アドレス値「13579F」
・チケットID「Bus0304」、アドレス値「13579F」
これは、チケット利用者Aは3つのアドレス値「134AAA」、「AB2322」及び「13579F」を少なくとも持っており、これらのアドレス値を用いて上記の4つのチケットIDの電子チケットを所有していることを意味している。
【0047】
同様に、チケット利用者Bが使用するチケット利用端末10Bでは、2つのアドレス値「ABC123」及び「2468AA」が管理されているものとする。この場合、チケット利用端末10Bでは、任意のタイミングで、電子チケット情報1000を参照することで、以下の電子チケットが自アドレスによって所有されていることを管理できる。
【0048】
・チケットID「Park001」、アドレス値「ABC123」
・チケットID「Bus0303」、アドレス値「ABC123」
・チケットID「Park005」、アドレス値「2468AA」
・チケットID「Bus0308」、アドレス値「2468AA」
これは、チケット利用者Bは2つのアドレス値「ABC123」及び「2468AA」を少なくとも持っており、これらのアドレス値を用いて上記の4つのチケットIDの電子チケットを所有していることを意味している。
【0049】
このとき、例えば、チケット利用者AがチケットID「Bus0304」の電子チケットを利用する場合、チケットID「Bus0304」及びアドレス値「13579F」をサービス提供者に提示する。この提示方法は任意の方法を採用することが可能であるが、
図2に示す例では、アドレス値「13579F」に対応する秘密鍵を用いてチケットID「Bus0304」から電子署名を作成した上で、この電子署名をチケットID「Bus0304」に付加したデータの二次元コードをチケット利用端末10A上に表示することで提示している。これにより、チケット確認端末20は、当該二次元コードをカメラ等で読み取ったデータからチケットID「Bus0304」及びアドレス値「13579F」を取得することができる。なお、アドレス値は、電子署名の検証に成功した公開鍵から得ることができる。
【0050】
チケットID「Bus0304」及びアドレス値「13579F」を取得したチケット確認端末20は、ブロックチェーンネットワーク40上の電子チケット情報1000を参照して、チケットID「Bus0304」の電子チケットの利用可否を検証し、その検証に成功した場合は状態を「使用済」に更新する。これにより、チケットID「Bus0304」の電子チケットが使用され、チケット利用者Aはサービス(
図2に示す例では、バスによる輸送サービス)を享受することが可能となる。なお、電子チケットの利用可否の検証とは、例えば、電子チケットの所有者格納領域に格納されているアドレス値が「13579F」であること、状態が「未使用」であること、等といった検証のことである。あるいは、電子チケットに有効期間が設定されている場合(これは、電子チケット情報1000に対して、電子チケットの有効期間が格納されるカラムを追加することで実現できる)、その電子チケットが有効期間内であるか否かの検証を行ってもよい。また、有効期間内は回数に制限なく利用できる電子チケットの場合(例えば、交通機関の1日乗車券や再入場可能なテーマパークチケット等)は、有効期間の検証のみを実行し、使用済か否かの状態の検証を省略できるため、上記の状態を「使用済」に更新するという処理を省略してもよいし、上記の状態を「使用中」等といった値に更新してもよい。上記の状態を「使用中」に更新した場合は、電子チケットの有効期間が過ぎたと検証されたときに、「使用済」に更新される。
【0051】
同様に、例えば、チケット利用者BがチケットID「Bus0303」の電子チケットを利用する場合、チケットID「Bus0303」及びアドレス値「ABC123」をサービス提供者に提示する。そして、チケットID「Bus0303」及びアドレス値「ABC123」を取得したチケット確認端末20は、ブロックチェーンネットワーク40上の電子チケット情報1000を参照して、電子チケットの利用可否を検証し、その検証に成功した場合は状態を「使用済」に更新する。これにより、チケットID「Bus0303」の電子チケットが使用され、チケット利用者Bはサービス(
図2に示す例では、バスによる輸送サービス)を享受することが可能となる。なお、電子チケットの利用可否の検証とは、例えば、電子チケットの所有者格納領域に格納されているアドレス値が「ABC123」であること、状態が「未使用」であること、等といった検証のことである。電子チケットの有効期間が設定されている場合の検証等についても、上記と同様である。
【0052】
このように、本実施例では、各チケット利用者は、複数のアドレス値を持つことが可能であり、これらのアドレス値を用いて電子チケットの所有することができる。また、上述したように、HDウォレットの仕組みでは、マスター秘密鍵を知らない限り、複数のアドレス値が同一のマスター秘密鍵から得られたものであるか否かを確認することができないため、複数のアドレス値が同一のチケット利用者のものであるか否かを確認することはできない。上記の例では、アドレス値「13579F」を持つチケット利用者Aと、アドレス値を「ABC123」を持つチケット利用者Bとが、別々に電子チケットを利用した例として記載したが、チケット確認端末20(及び、これを保持しているサービス提供者)は、同一人物が別の機会に利用したのか、異なる人物が利用したのかを判別することができない。このため、アドレス値による「名寄せ」が困難となり、個人の属性や行動傾向等といったパーソナルデータの漏洩を防止することが可能になる。
【0053】
なお、パーソナルデータの漏洩を効果的に防止するためには、一般に、各チケット利用者が多くのアドレス値を持ち、また何等の法則性なくアドレス値が電子チケットに用いられていることが好ましい。
【0054】
(チケット利用端末10の機能構成)
本実施例におけるチケット利用端末10の機能構成について、
図3を参照しながら説明する。
図3は、実施例1におけるチケット利用端末10の機能構成の一例を示す図である。
【0055】
図3に示すように、本実施例におけるチケット利用端末10は、チケット選択部101と、チケット提示部102と、記憶部103と、ウォレット110とを有する。チケット選択部101及びチケット提示部102は、例えば、チケット利用端末10にインストールされた1以上のプログラムがCPU(Central Processing Unit)に実行させる処理により実現される。また、記憶部103は、例えば、各種記憶装置により実現される。
【0056】
チケット選択部101は、ウォレット110で管理されている電子チケットの中から、チケット利用者が利用する電子チケットを選択する。
【0057】
チケット提示部102は、チケット選択部101で選択された電子チケットのチケットID及びアドレス値を二次元コードにより提示する。
【0058】
記憶部103は、ウォレット110で管理されている電子チケットのチケットIDとアドレス値を記憶する。
【0059】
ウォレット110は、HDウォレット等の複数のアドレス値を管理可能なウォレットであり、これらのアドレス値とそのアドレス値が所有者格納領域に格納されている電子チケットのチケットIDとを管理する。なお、ウォレット110は、ブロックチェーンネットワーク40上の電子チケット情報1000を参照して、自己が管理している電子チケットの状態等を確認することもできる。また、上述したように、ウォレット110は、アドレス値を生成することもできる。
【0060】
(チケット確認端末20の機能構成)
本実施例におけるチケット確認端末20の機能構成について、
図4を参照しながら説明する。
図4は、実施例1におけるチケット確認端末20の機能構成の一例を示す図である。
【0061】
図4に示すように、本実施例におけるチケット確認端末20は、チケット読取部201と、チケット検証部202と、チケット更新部203とを有する。これら各部は、例えば、チケット確認端末20にインストールされた1以上のプログラムがCPUに実行させる処理により実現される。
【0062】
チケット読取部201は、チケット利用端末10によって提示された二次元コードを読み取ることで、そのチケットID及びアドレス値を取得する。
【0063】
チケット検証部202は、チケット読取部201が取得したチケットID及びアドレス値を用いて、ブロックチェーンネットワーク40上の電子チケット情報1000を参照し、電子チケットの利用可否を検証する。
【0064】
チケット更新部203は、チケット検証部202によって電子チケットが利用可能であることが検証され、チケット利用者に対してサービスが提供された場合、当該電子チケットの状態を「使用済」に更新する。
【0065】
(チケット利用の流れ)
次に、本実施例におけるチケット利用の流れについて、
図5を参照しながら説明する。
図5は、実施例1におけるチケット利用の流れの一例を示すシーケンス図である。
【0066】
まず、チケット利用端末10のチケット選択部101は、ウォレット110で管理されている電子チケットの中から、チケット利用者が利用する電子チケットを選択する(ステップS101)。これは、例えば、ウォレット110で管理されている電子チケットの一覧の中から、チケット利用者が所望の電子チケットを選択する操作を行うことで実現される。
【0067】
次に、チケット利用端末10のチケット提示部102は、上記のステップS101で選択された電子チケットのチケットID及びアドレス値の二次元コードを作成する(ステップS102)。例えば、チケット提示部102は、当該アドレス値に対応する秘密鍵を用いて当該チケットIDから電子署名を作成した上で、この電子署名を当該チケットIDに付加したデータの二次元コードを作成する。
【0068】
次に、チケット利用端末10のチケット提示部102は、上記のステップS102で作成した二次元コードをディスプレイ上に表示することで、チケット確認端末20に提示する(ステップS103)。
【0069】
チケット確認端末20のチケット読取部201は、上記のステップS103で提示された二次元コードをカメラ等により読み取る(ステップS104)。これにより、チケット読取部201は、チケットIDと電子署名が得られ、更にこの電子署名を公開鍵で検証することでその公開鍵に対応するアドレス値が得られる。
【0070】
なお、上記のステップS102~ステップS103ではチケット利用端末10が二次元コードを提示したが、これは一例であって、これ以外の任意の方法でチケットID及びアドレス値をチケット確認端末20に提示してもよい。例えば、バーコード等の1次元コードによりチケットID及びアドレス値をチケット確認端末20に提示してもよいし、Bluetooth(登録商標)や非接触型ICカード等を介した近距離無線通信、インターネット等によりチケットID及びアドレス値をチケット確認端末20に提示してもよい。又は、例えば、音波、光の点滅、画像等によりチケットID及びアドレス値をチケット確認端末20に提示してもよい。
【0071】
次に、チケット確認端末20のチケット検証部202は、上記のステップS104で取得したチケットID及びアドレス値を用いて、ブロックチェーンネットワーク40上の電子チケット情報1000を参照し、電子チケットの利用可否を検証する(ステップS105)。すなわち、チケット検証部202は、ブロックチェーンネットワーク40上の電子チケット情報1000を参照して、上記のステップS104で取得したアドレス値と、当該チケットIDの電子チケットの所有者格納領域に格納されているアドレス値とが一致するか(つまり、当該電子チケットの所有権を有するか)、当該電子チケットの状態が「未使用」であるか、等を検証する。これ以外にも、上述したように、例えば、電子チケットに有効期間が設定されている場合はその有効期間内であるか否か等の検証を行ってもよい。
【0072】
なお、上記の検証結果は、チケット利用可否通知としてチケット利用端末10に通知されてもよい。
【0073】
上記のステップS105で検証に成功した場合は、チケット利用者に対してサービスが提供される。例えば、当該電子チケットがバスの乗車チケットである場合は、バスへの乗車が許可される。又は、例えば、当該電子チケットが駐車チケットである場合は、駐車場のゲートが開き、駐車が許可される。又は、例えば、当該電子チケットが商品の提供を受けるためのチケットである場合は、チケット利用者に商品が引き渡される。
【0074】
その後、チケット確認端末20のチケット更新部203は、上記のステップS104で取得したチケットIDの電子チケットの状態を「使用済」に更新するためのトランザクション(以下、「チケット利用トランザクション」ともいう。)を作成する(ステップS106)。なお、チケット利用トランザクションには、サービス提供者の秘密鍵を用いて作成された電子署名が付加される。
【0075】
そして、チケット確認端末20のチケット更新部203は、上記のステップS106で作成したチケット利用トランザクションをブロックチェーンネットワーク40に送信する(ステップS107)。これにより、このチケット利用トランザクションがブロックチェーンネットワーク40内の各ノード30で検証され、その検証に成功した場合は、当該電子チケットの状態が「使用済」に更新される。
【0076】
なお、上記のステップS106~ステップS107では電子チケットの状態を「使用済」に更新したが、これに限られず、チケット利用者が当該電子チケットを再度利用できないような状態すれば任意の方法を採用することができる。例えば、当該電子チケット自体を削除してもよいし、当該電子チケットの所有権をサービス提供者に移転するようにしてもよい。
【0077】
ここで、例えば、ERC721では電子チケット(トークン)を更新可能な者は、トークンの所有者(及び、承認されたアドレス値、現在の所有者から認証された者)に限られている。このため、電子チケットの所有者がチケット利用者である場合、通常は、サービス提供者がチケット利用トランザクションを作成及び送信して、当該電子チケットを更新することはできない。そこで、上記のステップS106~ステップS107でサービス提供者がチケット利用トランザクションを作成及び送信するには、このチケット利用トランザクションにより電子チケットの更新が可能なスマートコントラクトがデプロイされている必要がある。このようなスマートコントラクトは、例えば、電子チケットの所有権の移転であれば、transferFrom関数を修正することで実現することができる。より具体的には、transferFrom関数の実行条件文requireに対して、OR条件として、スマートコントラクトの管理者(サービス提供者)であれば真値を返す関数isContractOwer()を追加することが実現することができる。
【0078】
なお、上記のチケット利用トランザクションをチケット確認端末20が作成するのではなく、チケット利用端末10が作成し、例えば、二次元コードによりチケット確認端末20に提示してもよい。この場合、トークンの所有者であるチケット利用者によってチケット利用トランザクションが作成されているため、上記のスマートコントラクトの修正は不要である。
【0079】
[実施例2]
以下、本実施形態の実施例2について説明する。実施例1では各チケット利用者が予め電子チケットを購入済であるものとしたが、実際には、各チケット利用者は電子チケットを購入等する必要がある。この際、各チケット利用者は自身のアドレス値をチケット販売者に通知し、クレジットカード等の決済手段によりチケット代金を支払う必要がある。このため、例えば、同一のクレジットカードで決済することにより複数のアドレス値が同一のチケット利用者のものであることが特定されてしまう。一方で、アドレス値毎に決済手段を準備することは、アドレス値が多い場合には不可能である。
【0080】
このため、本実施例では、各チケット利用者は、自身が信頼するチケット販売者のみにアドレス値を通知し、電子チケットを購入する場合について説明する。ただし、本実施例では、各電子チケットの所有権はサービス提供者からチケット販売者に移転済であるものとする。チケット利用者が信頼するチケット販売者としては、例えば、サービス提供者から委託等を受けて電子チケットを販売する旅行代理店等が挙げられる。
【0081】
なお、本実施例では、実施例1との相違点について説明し、実施例1と同様の構成要素についてはその説明を省略している。
【0082】
(電子チケット管理システム1の全体構成)
実施例2における電子チケット管理システム1の全体構成について、
図6を参照しながら説明する。
図6は、実施例2における電子チケット管理システム1の全体構成の一例を示す図である。
【0083】
図6に示すように、本実施例における電子チケット管理システム1には、1以上の販売サーバ50が更に含まれる。販売サーバ50は、ブロックチェーンネットワーク40に接続されている。
【0084】
販売サーバ50は、各チケット利用者が信頼するチケット販売者が管理するサーバである。チケット販売者は、販売サーバ50により各チケット利用者に電子チケットを販売し、その所有権を当該チケット利用者に移転することができる。
【0085】
なお、
図6に示す例では、1つのチケット販売者のみが存在するが、複数のチケット販売者が存在してもよい。また、チケット利用者に応じて、当該チケット販売者が信頼するチケット販売者が異なっていてもよい。
【0086】
(実施例2の概要)
本実施例の概要について、
図7を参照しながら説明する。
図7は、実施例2の概要を説明するための図である。
【0087】
図7に示すように、販売サーバ50は、ユーザ管理情報2000を保持しているものとする。このユーザ管理情報2000は、販売サーバ50におけるチケット利用者の識別子を示す「ユーザID」と、このチケット利用者が決済に利用する「クレジットカード番号」と、このチケット利用者の利用する「アドレス値」とが含まれるレコードで構成されている。
【0088】
例えば、
図7に示す例では、ユーザ管理情報2000は、以下の5レコードで構成されている。
【0089】
・ユーザID「user001」、クレジットカード番号「xxxx-xxxx-xxxx-xxxx」、アドレス値「134AAA」
・ユーザID「user001」、クレジットカード番号「xxxx-xxxx-xxxx-xxxx」、アドレス値「AB2322」
・ユーザID「user001」、クレジットカード番号「xxxx-xxxx-xxxx-xxxx」、アドレス値「13579F」
・ユーザID「user002」、クレジットカード番号「yyyy-yyyy-yyyy-yyyy」、アドレス値「ABC123」
・ユーザID「user002」、クレジットカード番号「yyyy-yyyy-yyyy-yyyy」、アドレス値「2468AA」
これは、チケット利用者A(ユーザID「user001」)のクレジットカード番号は「xxxx-xxxx-xxxx-xxxx」であり、3つのアドレス値「134AAA」、「AB2322」及び「13579F」を持っていることを意味している。同様に、チケット利用者B(ユーザID「user002」)のクレジットカード番号は「yyyy-yyyy-yyyy-yyyy」であり、2つのアドレス値「ABC123」及び「2468AA」を持っていることを意味している。なお、チケット利用者A及びチケット利用者Bは、チケット販売者との間で事前にユーザ登録等を行って、ユーザIDの発行とクレジットカード番号の登録とが行われているものとしている。ただし、クレジットカード番号は決済に用いられる情報の一例であって、これに限られず、例えば、銀行口座番号や電子マネーの口座番号等の他の情報であってもよい。
【0090】
このとき、例えば、チケット利用者Aが或る電子チケットを購入する場合、自身のユーザIDとアドレス値を販売サーバ50に通知する。そして、販売サーバ50は、チケット利用者Aのクレジットカード番号で電子チケットの代金を決済した上で、当該電子チケットの所有者格納領域に格納されているアドレス値を、チケット利用者Aから通知されたアドレス値に更新する。これにより、当該電子チケットの所有権がチケット利用者Aに移転され、当該電子チケットのチケットIDがチケット利用者Aに通知される。なお、電子チケットのアドレス値を更新するには、販売サーバ50は、そのためのトランザクション(以下、「チケット移転トランザクション」ともいう。)を作成し、ブロックチェーンネットワーク40に送信する必要がある。
【0091】
同様に、例えば、チケット利用者Bが或る電子チケットを購入する場合、自身のユーザIDとアドレス値を販売サーバ50に通知する。そして、販売サーバ50は、チケット利用者Bのクレジットカード番号で電子チケットの代金を決済した上で、当該電子チケットの所有者格納領域に格納されているアドレス値を、チケット利用者Bから通知されたアドレス値に更新する。これにより、当該電子チケットの所有権がチケット利用者Bに移転され、当該電子チケットのチケットIDがチケット利用者Bに通知される。
【0092】
このように、本実施例では、各チケット利用者は、自身が信頼するチケット販売者に対してのみアドレス値を通知し、このチケット販売者から電子チケットを購入する。これにより、各電子チケット購入の際に同一の決済手段を用いたとしても、チケット利用者が信頼するチケット販売者以外の者は当該チケット利用者がどのアドレス値を持っているかを特定することができないため、実施例1で説明したパーソナルデータの漏洩防止を実現することが可能となる。
【0093】
(チケット利用端末10の機能構成)
本実施例におけるチケット利用端末10の機能構成について、
図8を参照しながら説明する。
図8は、実施例2におけるチケット利用端末10の機能構成の一例を示す図である。
【0094】
図8に示すように、本実施例におけるチケット利用端末10は、チケット購入部104を更に有する。チケット購入部104は、例えば、チケット利用端末10にインストールされた1以上のプログラムがCPUに実行させる処理により実現される。
【0095】
チケット購入部104は、電子チケットを購入する際に、ユーザIDとアドレス値とを販売サーバ50に通知する。なお、ユーザIDは、記憶部103に記憶されている。
【0096】
(販売サーバ50の機能構成)
本実施例における販売サーバ50の機能構成について、
図9を参照しながら説明する。
図9は、実施例2における販売サーバ50の機能構成の一例を示す図である。
【0097】
図9に示すように、本実施例における販売サーバ50は、決済部501と、チケット移転部502と、記憶部503とを有する。決済部501及びチケット移転部502は、例えば、販売サーバ50にインストールされた1以上のプログラムがCPUに実行させる処理により実現される。また、記憶部503は、例えば、各種記憶装置により実現される。
【0098】
決済部501は、チケット利用端末10から通知されたユーザIDに対応するクレジット番号を用いて、電子チケットの代金を決済する。
【0099】
チケット移転部502は、チケット利用端末10から通知されたアドレス値を用いて、チケット移転トランザクションを作成及び送信する。
【0100】
記憶部503は、ユーザ管理情報2000を記憶する。なお、記憶部503には、例えば、販売対象の電子チケットのチケットIDやそのチケット代等の情報も記憶されている
(チケット購入の流れ)
次に、本実施例におけるチケット購入の流れについて、
図10を参照しながら説明する。
図10は、実施例2におけるチケット購入の流れの一例を示すシーケンス図である。
【0101】
まず、チケット利用端末10のチケット購入部104は、電子チケットを購入する際に、ユーザID及びアドレス値が含まれる電子チケット購入要求を販売サーバ50に送信する(ステップS201)。これにより、ユーザID及びアドレス値が販売サーバ50に通知される。なお、電子チケット購入要求には、例えば、チケット利用者が購入を所望する電子チケットのチケットIDが含まれていてもよい。また、電子チケット購入要求に含まれるアドレス値は、記憶部103に予め記憶されているアドレス値であってもよいし、ウォレット110で新たに生成したアドレス値であってもよい。
【0102】
販売サーバ50の決済部501は、記憶部503に記憶されているユーザ管理情報2000を参照して、上記のステップS201で通知されたユーザIDに対応するクレジットカード番号によりチケット代を決済する(ステップS202)。
【0103】
販売サーバ50のチケット移転部502は、上記のステップS202の決済が完了すると、上記のステップS201で通知されたアドレス値を移転先として指定したチケット移転トランザクションを作成する(ステップS203)。このチケット移転トランザクションは、該当の電子チケットの所有者格納領域のアドレス値を、新たな所有者のアドレス値に更新するためのトランザクションである。なお、チケット移転トランザクションには、更新対象の電子チケットのチケットIDも指定される。また、チケット移転トランザクションには、チケット販売者の秘密鍵を用いて作成された電子署名が付加される。
【0104】
そして、販売サーバ50のチケット移転部502は、上記のステップS203で作成したチケット移転トランザクションをブロックチェーンネットワーク40に送信する(ステップS204)。これにより、該当の電子チケットの所有者格納領域のアドレス値が更新され、この電子チケットの所有権がチケット利用者に移転される。なお、当該電子チケットのチケットIDは、上記のステップS201で電子チケット購入要求を行ったチケット利用端末10に通知される。
【0105】
<まとめ>
以上のように、実施例1における電子チケット管理システム1では、HDウォレット等の複数のアドレス値を管理可能なウォレットを用いて、チケット利用端末10で複数のアドレス値を管理することができる。このため、ブロックチェーンネットワーク40上の共有情報(電子チケット情報1000)を第三者が参照しても、どのアドレス値がどのチケット利用者のものであるかを知ることができないため、アドレス値の「名寄せ」が困難になり、パーソナルデータの漏洩を防止することが可能となる。
【0106】
また、実施例2における電子チケット管理システム1では、各チケット利用者は自身が信頼するチケット販売者にのみ自身のアドレス値を通知し、電子チケットを購入することができる。これにより、電子チケットの購入に伴う決済手段をアドレス値毎に準備する必要がなく、例えば、1つの決済手段のみを用いた場合であっても、上記のパーソナルデータの漏洩防止を実現することが可能となる。
【0107】
なお、本実施形態では、ブロックチェーンネットワーク40上で共有情報として電子チケット情報1000が管理されている場合について説明したが、必ずしもこれに限られず、電子チケットの自由な流通と電子チケットの不正利用及び不正取引の防止とが実現されていれば、集中DB(データベース)によって電子チケット情報1000が管理されていてもよい。
【0108】
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。
【符号の説明】
【0109】
1 電子チケット管理システム
10 チケット利用端末
20 チケット確認端末
30 ノード
40 ブロックチェーンネットワーク
50 販売サーバ
101 チケット選択部
102 チケット提示部
103 記憶部
104 チケット購入部
110 ウォレット
201 チケット読取部
202 チケット検証部
203 チケット更新部
501 決済部
502 チケット移転部
503 記憶部