知財求人 - 知財ポータルサイト「IP Force」
▶ ｂａｃｏｏｒ ｄＡｐｐｓ株式会社の特許一覧 ▶ 株式会社ＡＩ商事の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023037442
(43)【公開日】2023-03-15
(54)【発明の名称】コンピュータ実装方法及びシステム
(51)【国際特許分類】
G06Q 20/38 20120101AFI20230308BHJP
G06Q 20/32 20120101ALI20230308BHJP
G06F 21/62 20130101ALI20230308BHJP
【ＦＩ】
G06Q20/38 310
G06Q20/32 330
G06F21/62 318
【審査請求】未請求
【請求項の数】16
【出願形態】ＯＬ
(21)【出願番号】P 2021144210
(22)【出願日】2021-09-03
(71)【出願人】
【識別番号】518003096
【氏名又は名称】Ｂａｃｏｏｒ ｄＡｐｐｓ株式会社
(71)【出願人】
【識別番号】320003367
【氏名又は名称】株式会社ＡＩ商事
(74)【代理人】
【識別番号】100111567
【弁理士】
【氏名又は名称】坂本 寛
(72)【発明者】
【氏名】春名 幸雄
(72)【発明者】
【氏名】竹内 仁
【テーマコード（参考）】
5L055
【Ｆターム（参考）】
5L055AA64
5L055AA71
(57)【要約】
【課題】スマートコントラクトの呼び出しのためにブロックチェーンへ送信されるデータを容易に取得できるようにする。
【解決手段】開示の方法は、コンピュータが実行するコンピュータ実装方法であって、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、前記第２データを前記装置へ与えることを備え、前記第１データは、前記装置が、前記装置の外部から取得したデータであり、前記第２データは、前記スマートコントラクトの呼び出しのために前記ブロックチェーンへ送信されるデータを含む。
【選択図】図８
【解決手段】開示の方法は、コンピュータが実行するコンピュータ実装方法であって、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、前記第２データを前記装置へ与えることを備え、前記第１データは、前記装置が、前記装置の外部から取得したデータであり、前記第２データは、前記スマートコントラクトの呼び出しのために前記ブロックチェーンへ送信されるデータを含む。
【選択図】図８
【特許請求の範囲】
【請求項1】
コンピュータが実行するコンピュータ実装方法であって、
ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、
前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、
前記第２データを前記装置へ与える
ことを備え、
前記第１データは、前記装置が、前記装置の外部から取得したデータであり、
前記第２データは、前記スマートコントラクトの呼び出しのために前記ブロックチェーンへ送信されるデータを含む
コンピュータ実装方法。
ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、
前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、
前記第２データを前記装置へ与える
ことを備え、
前記第１データは、前記装置が、前記装置の外部から取得したデータであり、
前記第２データは、前記スマートコントラクトの呼び出しのために前記ブロックチェーンへ送信されるデータを含む
コンピュータ実装方法。
【請求項2】
前記第２データは、前記第１データを用いたアクセス毎に異なるユニークデータとして発行される
請求項１に記載のコンピュータ実装方法。
請求項１に記載のコンピュータ実装方法。
【請求項3】
前記第２データは、前記スマートコントラクトの呼び出しのために用いることができる回数が制限されているデータを含む
請求項１又は２に記載のコンピュータ実装方法。
請求項１又は２に記載のコンピュータ実装方法。
【請求項4】
前記回数は、１回である
請求項３に記載のコンピュータ実装方法。
請求項３に記載のコンピュータ実装方法。
【請求項5】
前記第２データは、前記スマートコントラクトによって操作されるトークンに関するデータを含む
請求項１から請求項４のいずれか１項に記載のコンピュータ実装方法。
請求項１から請求項４のいずれか１項に記載のコンピュータ実装方法。
【請求項6】
前記トークンは、ノンファンジブルトークン及びファンジブルトークンの少なくともいずれか一方である
請求項５に記載のコンピュータ実装方法。
請求項５に記載のコンピュータ実装方法。
【請求項7】
前記第２データは、前記スマートコントラクトによって操作されるノンファンジブルトークンを識別するためのデータを含む
請求項１から請求項６のいずれか１項に記載のコンピュータ実装方法。
請求項１から請求項６のいずれか１項に記載のコンピュータ実装方法。
【請求項8】
前記第２データは、前記スマートコントラクトによって操作されるファンジブルトークンの数を識別するためのデータを含む
請求項１から請求項７のいずれか１項に記載のコンピュータ実装方法。
請求項１から請求項７のいずれか１項に記載のコンピュータ実装方法。
【請求項9】
呼び出された前記スマートコントラクトによって、トークンを送信する
ことを更に備え、
前記スマートコントラクトは、前記トークンに関する前記データに基づいて、送信すべきトークンを決定する
請求項５に記載のコンピュータ実装方法。
ことを更に備え、
前記スマートコントラクトは、前記トークンに関する前記データに基づいて、送信すべきトークンを決定する
請求項５に記載のコンピュータ実装方法。
【請求項10】
前記スマートコントラクトは、前記トークンに関する前記データに対応付けられた数のファンジブルトークンを送信する
請求項９に記載のコンピュータ実装方法。
請求項９に記載のコンピュータ実装方法。
【請求項11】
前記スマートコントラクトは、前記トークンに関する前記データに対応付けられたノンファンジブルトークンを送信する
請求項９又は請求項１０に記載のコンピュータ実装方法。
請求項９又は請求項１０に記載のコンピュータ実装方法。
【請求項12】
呼び出された前記スマートコントラクトによって、ファンジブルトークンを送信する
ことを更に備え、
前記スマートコントラクトは、前記トークンに関する前記データを受信すると、送信すべきファンジブルトークンの数を決定し、決定した数のファンジブルトークンを送信する
請求項５に記載のコンピュータ実装方法。
ことを更に備え、
前記スマートコントラクトは、前記トークンに関する前記データを受信すると、送信すべきファンジブルトークンの数を決定し、決定した数のファンジブルトークンを送信する
請求項５に記載のコンピュータ実装方法。
【請求項13】
呼び出された前記スマートコントラクトによって、ノンファンジブルトークンを送信する
ことを更に備え、
前記スマートコントラクトは、前記トークンに関する前記データを受信すると、送信すべきノンファンジブルトークンを生成し、生成したノンファンジブルトークンを送信する
請求項５に記載のコンピュータ実装方法。
ことを更に備え、
前記スマートコントラクトは、前記トークンに関する前記データを受信すると、送信すべきノンファンジブルトークンを生成し、生成したノンファンジブルトークンを送信する
請求項５に記載のコンピュータ実装方法。
【請求項14】
第１データを用いたアクセスを受け付けると、第２データの発行条件が満たされているかどうかを判定することを更に備え、
前記第２データは、前記発行条件が満たされている場合に、発行される
請求項１から請求項１３のいずれか１項に記載のコンピュータ実装方法。
前記第２データは、前記発行条件が満たされている場合に、発行される
請求項１から請求項１３のいずれか１項に記載のコンピュータ実装方法。
【請求項15】
前記発行条件が満たされているかどうかの判定は、前記装置から取得したデータに基づいて行われる
請求項１４に記載のコンピュータ実装方法。
請求項１４に記載のコンピュータ実装方法。
【請求項16】
ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、
前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、
前記第２データを前記装置へ与える、
ことを実行するよう構成されたサーバを備える
システム。
前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、
前記第２データを前記装置へ与える、
ことを実行するよう構成されたサーバを備える
システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、コンピュータ実装方法及びシステムに関する。
【背景技術】
【0002】
特許文献１は、ブロックチェーンのスマートコントラクトを開示している。スマートコントラクトは、自動取引等の処理をブロックチェーンにおいて実行する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０２１－８９６４０号公報
【発明の概要】
【0004】
ブロックチェーンの利用を図るためには、スマートコントラクトの呼び出しのためにブロックチェーンへ送信されるデータを容易に取得できることが望まれる。
【0005】
特に、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置が取得したデータが、スマートコントラクトの呼び出しのためにブロックチェーンへ送信されるデータではない場合であっても、当該装置が、スマートコントラクトの呼び出しのためにブロックチェーンへ送信されるデータを取得できることが望まれる。
【0006】
本開示のある側面は、コンピュータ実装方法である。開示の方法は、コンピュータが実行するコンピュータ実装方法であって、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、前記第２データを前記装置へ与えることを備え、前記第１データは、前記装置が、前記装置の外部から取得したデータであり、前記第２データは、前記スマートコントラクトの呼び出しのために前記ブロックチェーンへ送信されるデータを含む。
【0007】
本開示の他の側面は、システムである。開示のシステムは、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、前記第２データを前記装置へ与える、ことを実行するよう構成されたサーバを備える。
【0008】
更なる詳細は、後述の実施形態として説明される。
【図面の簡単な説明】
【0009】
【発明を実施するための形態】
【0010】
＜１．方法及びシステムの概要＞
【0011】
（１）実施形態に係る方法は、コンピュータが実行するコンピュータ実装方法であって、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、前記第２データを前記装置へ与えることを備え、前記第１データは、前記装置が、前記装置の外部から取得したデータであり、前記第２データは、前記スマートコントラクトの呼び出しのために前記ブロックチェーンへ送信されるデータを含む。前記第１データは、例えば、後述述のように近距離無線通信によって、外部から取得されるが、近距離無線通信以外の手段によって、取得されてもよい。
【0012】
（２）前記第２データは、前記第１データを用いたアクセス毎に異なるユニークデータとして発行されるのが好ましい。
【0013】
（３）前記第２データは、前記スマートコントラクトの呼び出しのために用いることができる回数が制限されているデータを含むのが好ましい。
【0014】
（４）前記回数は、１回であるのが好ましい。
【0015】
（５）前記第２データは、前記スマートコントラクトによって操作されるトークンに関するデータを含むのが好ましい。
【0016】
（６）前記トークンは、ノンファンジブルトークン及びファンジブルトークンの少なくともいずれか一方であるのが好ましい。
【0017】
（７）前記第２データは、前記スマートコントラクトによって操作されるノンファンジブルトークンを識別するためのデータを含むのが好ましい。
【0018】
（８）前記第２データは、前記スマートコントラクトによって操作されるファンジブルトークンの数を識別するためのデータを含むのが好ましい。
【0019】
（９）前記方法は、呼び出された前記スマートコントラクトによって、トークンを送信することを更に備え、前記スマートコントラクトは、前記トークンに関する前記データに基づいて、送信すべきトークンを決定するのが好ましい。
【0020】
（１０）前記スマートコントラクトは、前記トークンに関する前記データに対応付けられた数のファンジブルトークンを送信するのが好ましい。
【0021】
（１１）前記スマートコントラクトは、前記トークンに関する前記データに対応付けられたノンファンジブルトークンを送信するのが好ましい。
【0022】
（１２）前記方法は、呼び出された前記スマートコントラクトによって、ファンジブルトークンを送信することを更に備え、前記スマートコントラクトは、前記トークンに関する前記データを受信すると、送信すべきファンジブルトークンの数を決定し、決定した数のファンジブルトークンを送信するのが好ましい。
【0023】
（１３）前記方法は、呼び出された前記スマートコントラクトによって、ノンファンジブルトークンを送信することを更に備え、前記スマートコントラクトは、前記トークンに関する前記データを受信すると、送信すべきノンファンジブルトークンを生成し、生成したノンファンジブルトークンを送信するのが好ましい。
【0024】
（１４）前記方法は、第１データを用いたアクセスを受け付けると、第２データの発行条件が満たされているかどうかを判定することを更に備え、前記第２データは、前記発行条件が満たされている場合に、発行されるのが好ましい。
【0025】
（１５）前記発行条件が満たされているかどうかの判定は、前記装置から取得したデータに基づいて行われるのが好ましい。
【0026】
（１６）実施形態に係るシステムは、ブロックチェーンのスマートコントラクトの呼び出しに用いられる装置から、第１データを用いたアクセスを受け付け、前記第１データを用いたアクセスを受け付けると、前記第１データとは異なる第２データを発行し、前記第２データを前記装置へ与える、ことを実行するよう構成されたサーバを備えるのが好ましい。
【0027】
＜２．方法及びシステムの例＞
【0028】
図１は、実施形態に係るシステム１０の一例を示している。このシステム１０は、ブロックチェーン２０のスマートコントラクト２２を利用したシステムである。
【0029】
ブロックチェーン２０は、複数のコンピュータが相互に接続されたＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）のコンピュータネットワークシステムによって構成されている。
【0030】
ブロックチェーン２０においては、ブロックチェーンアドレス間で取引が可能である。取引のトランザクションは、ブロックチェーン２０の分散台帳に記録される。ブロックチェーンアドレスは、例えば、ブロックチェーン２０におけるユーザアカウント２５Ａ，２５Ｂを示す。例えば、あるユーザＵ１が、ブロックチェーン２０にアカウント２５Ａを有している場合、そのアカウントは、所定のブロックチェーンアドレスを有する。
【0031】
ブロックチェーン２０おいては、例えば、トークンの取引が可能である。ブロックチェーン２０において取引可能なトークンとしては、ファンジブルトークン（代替性トークン；Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ：ＦＴ）と、ノンファンジブルトークン（非代替性トークン；Ｎｏｎ-Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ：ＮＦＴ）と、がある。ファンジブルトークンは、例えば、イーサリアム（Ｅｔｈｅｒｅｕｍ）におけるイーサ（Ｅｔｈｅｒ）などの暗号通貨である。ファンジブルトークンは、企業又は個人によってブロックチェーンにおいて発行される独自ファンジブルトークンであってもよい。
【0032】
ノンファンジブルトークン（ＮＦＴ）は、ファンジブルトークン（ＦＴ）とは異なり、代替性を有さないトークンである。非代替性の確保のため、ＮＦＴは、ブロックチェーン２０において、他のＮＦＴとの区別を可能にするための固有の識別子を有する。以下では、この識別子をＮＦＴ識別子という。ＮＦＴ識別子は、例えば、ＮＦＴのためのブロックチェーンアドレス（コントラクトアドレス）に記録される。
【0033】
ブロックチェーン２０において、ユーザＵ１，Ｕ２が所有するＮＦＴ又はファンジブルトークンは、ユーザアカウント２５Ａ，２５Ｂに対応付けて記録される。
【0034】
ブロックチェーン２０は、スマートコントラクト２２を備える。スマートコントラクト２２は、ブロックチェーンにおいて実行可能に実装されたソフトウェア（コンピュータプログラム）によって構成されている。スマートコントラクト２２は、自動取引等の所定のプロトコルを自動的に実行する。
【0035】
前述のブロックチェーンアドレスは、スマートコントラクト２２のコントラクトアドレスを示すこともある。コントラクトアドレスは、スマートコントラクト２２が格納されているブロックチェーンアドレスである。
【0036】
ブロックチェーン２０においては、スマートコントラクト２２もＮＦＴ又はファンジブルトークンを所有できる。ブロックチェーン２０において、スマートコントラクト２２が所有するＮＦＴ又はファンジブルトークンは、スマートコントラクト２２のコントラクトアドレスに対応付けて記録される。
【0037】
スマートコントラクト２２によって実行される処理は、例えば、トークンの操作である。トークンの操作は、例えば、トークンの所有者変更である。トークンの所有者変更の操作は、トークンの送信とも呼ばれる。すなわち、トークンの所有者を第１ブロックチェーンアドレスから第２ブロックチェーンアドレスに変更することは、第１ブロックチェーンアドレスから第２ブロックチェーンアドレスへトークンを送信することもでもある。
【0038】
トークンの送信は、例えば、スマートコントラクト２２のコントラクトアドレスから、他のブロックチェーンアドレス（例えば、ユーザアカウント）へトークンを送信することである。
【0039】
なお、トークンの操作は、トークンの所有者変更（送信）に限られず、トークンに関する何らかの処理であれば足りる。
【0040】
スマートコントラクト２２は、例えば、スマートコントラクト２２外からの呼び出し操作によって呼び出されることで、スマートコントラクト２２による処理が実行される。スマートコントラクト２２は、例えば、ユーザのアカウント２５Ａ，２５Ｂから呼び出される。
【0041】
ユーザＵ１，Ｕ２の端末３１，３２は、スマートコントラクト２２の呼び出しに用いられ得る。すなわち、端末３１，３２は、ブロックチェーン２０のスマートコントラクト２２の呼び出しに用いられる装置である。
【0042】
端末３１，３２は、例えば、スマートフォンなどのハンドヘルド装置である。ユーザＵ１，Ｕ２の端末３１，３２は、例えば、スマートコントラクト２２の呼び出しのためのアプリケーションプログラムを利用することで、スマートコントラクト２２を呼び出す。スマートコントラクト２２の呼び出しのためのアプリケーションプログラムは、端末３１，３２上で動作するローカルアプリケーションプログラムであってもよいし、ＷＥＢサーバによって提供されるＷＥＢアプリケーションプログラムであってもよい。
【0043】
実施形態においては、スマートコントラクト２２の呼び出しに、近距離無線通信（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が使用され得る。近距離無線通信は、ＮＦＣ規格に従った通信であるのが好ましい。ＮＦＣは、例えば、１３．５６ＭＨｚ帯の周波数を使った無線通信である。近距離無線通信の通信距離は、１０ｃｍ以下であるのが好ましい。
【0044】
端末３１，３２は、近距離無線通信モジュール３１Ｄ，３２Ｄ（ＮＦＣモジュール３１Ｄ，３２Ｄ）を備えている。端末３１，３２は、他の近距離無線通信装置４０との間で、近距離無線通信を行うことができる。
【0045】
他の近距離無線通信装置４０は、例えば、近距離無線通信タグ４０（ＮＦＣタグ４０）である。ＮＦＣタグ４０は、近距離無線通信のためのＩＣタグであり、ＮＦＣ規格に準拠した通信を行う。ＮＦＣタグ４０は、電源不要である。
【0046】
図１に示すように、ＮＦＣタグ４０は、アンテナ４１と、アンテナ４１に接続された無線回路４２と、無線回路４２に接続されたコントローラ４３と、コントローラ４３に接続されたメモリ４４と、を備える。メモリ４４には、近距離無線通信によって送信される通信データ４６が保存されている。なお、通信データ４６は、図示しない書き込み装置によって、メモリ４４に書き込まれる。
【0047】
実施形態においては、ＮＦＣタグ４０（近距離無線通信をする装置（第１装置））から、端末３１，３２（スマートコントラクト２２の呼び出しに用いられる装置（第２装置））へ、通信データ４６が送信される。例えば、ユーザＵ１，Ｕ２が、端末３１，３２を、ＮＦＣタグ４０にかざすことで、近距離無線通信によって、通信データ４６が、端末３１，３２へ送信される。
【0048】
通信データ４６を受信した端末３１，３２は、受信した通信データ４６を利用して、スマートコントラクト２２の呼び出しをする。すなわち、実施形態においては、端末３１，３２が近距離無線通信を行って通信データ４６を受信すると（ステップＳ１１）、スマートコントラクト２２の呼び出し（ステップＳ１２）のための処理が開始される。つまり、実施形態においては、近距離無線通信が、スマートコントラクト２２の呼び出しのトリガになっている。なお、スマートコントラクト２２の呼び出しのための処理は、スマートコントラクト２２の呼び出しそのもののほか、スマートコントラクト２２の呼び出しのための準備をする処理を含み得る。
【0049】
通信データ４６は、スマートコントラクト２２の呼び出しのために用いられる第１データ１１０を含み得る。実施形態において、第１データ１１０は、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータである必要はなく、例えば、第１データ１１０は、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを取得するために用いられるデータであってもよい。すなわち、第１データは、スマートコントラクト２２の呼び出しのための準備をする処理において用いられるデータであってもよい。
【0050】
通信データ４６の送信のため、複数のＮＦＣタグ４０（近距離無線通信装置４０）が用いられてもよい。複数のＮＦＣタグ４０それぞれは、同一の通信データ４６を送信し得る。あるいは、複数のＮＦＣタグ４０が送信する通信データ４６は、同一の第１データ１１０を含み得る。
【0051】
図２から図４は、第１データ１１０を用いて、スマートコントラクト２２を呼び出す方法のいくつかの例を示している。図２は、呼び出す方法の第１例を示している。図２に示す第１例では、まず、第１データ取得器２０１によって、第１データ１１０が取得される（ステップＳ２１）。第１データ１１０の取得は、例えば、スマートコントラクト２２の呼び出しのためのトリガとされる。第１データ取得器２０１は、例えば、第１データ１１０を外部から取得するためのインタフェースを備えたコンピュータである。第１データ取得器２０１は、例えば、図１に示す端末３１，３２である。
【0052】
取得器２０１が取得した第１データ１１０は、第２データ１２０の発行に用いられ得る。第１データ１１０は、例えば、第２データ１２０を発行する第２データ発行器２０２へのアクセスに用いられてもよいし、第１データ１１０に対応付けられた第２データの取得に用いられてもよいし、第２データ１２０への変換に用いられてもよい。
【0053】
第２データ１２０は、第２データ発行器２０２によって発行され得る。第２データ発行器２０２は、例えば、第２データを発行するよう構成されたコンピュータである。第２データ発行器２０２は、第１データ取得器２０１とは異なるコンピュータであり得る。第２データ発行器２０２は、例えば、後述の第１サーバ５１（図６参照）である。
【0054】
第１データ取得器２０１は、第２データ発行器２０２にアクセスすることができる（ステップＳ２２）。第１データ１１０は、そのアクセスに用いられ得る。第１データ１１０は、そのアクセスによって第２データ発行器２０２へ送信され得る。
【0055】
第１データ１１０を用いたアクセスを受けた第２データ発行器２０２は、第２データ１２０を発行することができる。第２データ１２０は、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを含み得る。スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータは、発行器２０２によって発行されるため、第１データ１１０は、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを含んでいなくてもよい。
【0056】
第２データ発行器２０２は、あらかじめ設定された発行プロトコルに従って、第２データ１２０を発行し得る。発行プロトコルは、第２データ１２０の発行条件を含み得る。発行プロトコルは、発行条件に従って第２データ１２０を発行する工程を含み得る。第１データ１１０を用いたアクセスを受け付けた第２データ発行器２０２は、発行条件を満たさない場合には第２データ１２０を発行せず、発行条件を満たした場合に第２データ１２０を発行することができる。発行条件を設けることで、第２データ発行器２０２へのアクセスがあっても、第２データ１２０を発行しない、という対処が可能となる。
【0057】
例えば、同一ユーザＵ１，Ｕ２又は同一端末３１，３２に対する第２データ１２０の発行を１日あたり１回に制限したい場合、同一ユーザＵ１，Ｕ２又は同一端末３１，３２による第２データ発行器２０２へのアクセスが同日において無いことを発行条件にすることができる。
【0058】
発行プロトコルは、アクセスに用いられた第１データ１１０に対応する第２データ１２０を識別する工程を含み得る。この場合、アクセスに用いられた第１データ１１０に応じて、適切な第２データ１２０を発行することができる。例えば、アクセスに用いられ得る第１データ１１０が複数種類ある場合、アクセスに用いられた第１データ１１０の種類に対応する第２データ１２０を識別することで、第１データ１１０の種類に応じた、適切な第２データ１２０を発行することができる。
【0059】
発行プロトコルは、発行される第２データ１２０を、複数の第２データ候補の中から選択する工程を含み得る。選択は、所定のルールに従った選択でもよいし、ランダムな選択であってもよい。複数の第２データ候補は、それぞれ異なるユニークデータであるのが好ましい。第２データ発行器２０２は、一度に一つの第２データ１２０だけを発行してもよいし、一度に複数の第２データ１２０を発行してもよい。
【0060】
一例として、１種類の第１データ１１０に複数種類の第２データ候補が対応付けられている場合、第２データ発行器２０２は、アクセスに用いられた第１データ１１０に対応付けられた複数種類の第２データ候補の中から、発行される第２データ１２０を選択することができる。この場合、同じ種類の第１データ１１０を用いたアクセスが複数回あった場合、アクセス毎に異なる種類の第２データ１２０を発行することができる。つまり、第２データは、第１データ１１０を用いたアクセス毎に異なるユニークデータとして発行され得る。
【0061】
発行された第２データ１２０は、呼び出し器２０３に与えられる（ステップＳ２３）。呼び出し器２０３は、例えば、スマートコントラクト２２の呼び出しをするよう構成されたコンピュータである。呼び出し器２０３は、第１データ取得器２０１を構成するコンピュータと同じコンピュータであってもよいし、は第２データ発行器２０２を構成するコンピュータと同じコンピュータであってもよいし、他のコンピュータであってもよい。呼び出し器２０３としての機能は、複数のコンピュータの協調動作によって実現されてもよい。例えば、呼び出し器２０３は、端末３１と、端末３１がアクセスした他のコンピュータ（例えばサーバ５２）と、によって構成されてもよい。
【0062】
呼び出し器２０３は、スマートコントラクト２２の呼び出しをするために、ブロックチェーン２０へデータを送信するよう構成されている。呼び出し器２０３は、ブロックチェーン２０へ送信すべきデータを、第２データ１２０として、第２データ発行器２０２から取得する（ステップＳ２３）。呼び出し器２０３は、第２データ１２０に含まれるデータの一部又は全部を、ブロックチェーン２０へ送信する（ステップＳ２４）。
【0063】
呼び出し器２０３がブロックチェーン２０へ送信するデータは、例えば、スマートコントラクト２２に与えられるデータ（スマートコントラクト２２によって受信されるデータ）であり得る。スマートコントラクト２２に与えられるデータは、例えば、後述のトークンコードである。
【0064】
呼び出し器２０３がブロックチェーン２０へ送信するデータは、呼び出されたスマートコントラクト２２によって操作されるトークンに関するデータであり得る。スマートコントラクト２２によって操作されるトークンに関するデータは、例えば、後述のトークンコードである。
【0065】
呼び出し器２０３がブロックチェーン２０へ送信するデータは、呼び出すべきスマートコントラクト２２を識別するためのデータであり得る。呼び出すべきスマートコントラクト２２を識別するためのデータは、例えば、スマートコントラクト２２のコントラクトアドレスである。
【0066】
ブロックチェーンの利用を図るためには、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを容易に取得できることが望まれる。特に、ブロックチェーン２０のスマートコントラクト２２の呼び出しに用いられる装置が取得したデータが、スマートコントラクト２２の呼び出しのためにブロックチェーンへ送信されるデータではない場合であっても、当該装置が、スマートコントラクトの呼び出しのためにブロックチェーンへ送信されるデータを取得できることが望まれる。
【0067】
すなわち、図２に示す第１例によれば、第１データ１１０の取得をスマートコントラクト２２の呼び出しのトリガにする場合であっても、第１データ１１０は、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを含んでいなくてもよい。また、第１例によれば、第１データ１１０の取得をスマートコントラクト２２の呼び出しのトリガにしつつも、第１データ１１０とは異なる第２データ１２０を利用してスマートコントラクト２２を呼び出すことができる。
【0068】
図３は、呼び出す方法の第２例を示している。第２例に関し特に説明しない点については、図２に示す第１例と同様である。図３に示す第２例では、第１例とは異なり、第１データ１１０が、ブロックチェーン２０への送信に利用される。
【0069】
すなわち、第２例では、まず、第１データ取得器２０１によって、第１データ１１０が取得される（ステップＳ３１）。取得された第１データ１１０の一部又は全部が、呼び出し器２０３に与えられる（ステップＳ３２）。
【0070】
呼び出し器２０３は、ブロックチェーン２０へ送信すべきデータ（第１データ１１０の一部又は全部）を、第１データ取得器２０１から取得する（ステップＳ３２）。呼び出し器２０３は、取得したデータの一部又は全部を、ブロックチェーン２０へ送信する（ステップＳ３３）。
【0071】
呼び出し器２０３がブロックチェーン２０へ送信するデータは、例えば、スマートコントラクト２２に与えられるデータ（スマートコントラクト２２によって受信されるデータ）であり得る。呼び出し器２０３がブロックチェーン２０へ送信するデータは、呼び出されたスマートコントラクト２２によって操作されるトークンに関するデータであり得る。呼び出し器２０３がブロックチェーン２０へ送信するデータは、呼び出すべきスマートコントラクト２２を識別するためのデータであり得る。
【0072】
図３に示す第２例によれば、第１データ取得器２０１によって取得した第１データを、ブロックチェーン２０への送信に利用することができる。
【0073】
図４は、呼び出す方法の第３例を示している。第３例に関し特に説明しない点については、図２に示す第１例又は図３に示す第２例と同様である。図４に示す第３例では、第１データ１１０及び第２データ１２０の両方が、ブロックチェーン２０への送信に利用される。
【0074】
すなわち、第３例では、まず、第１データ取得器２０１によって、第１データ１１０が取得される（ステップＳ４１）。
【0075】
第１取得器２０１が取得した第１データ１１０は、第２データ発行器２０２による第２データ１２０の発行に用いられ得る。また、第１データ１１０は、呼び出し器２０３にも与えられ得る。
【0076】
第１データ取得器２０１は、第１データ１１０を用いて、第２データ発行器２０２にアクセスすることができる（ステップＳ４２）。第１データ１１０は、そのアクセスによって第２データ発行器２０２へ送信され得る。
【0077】
第１データ１１０を用いたアクセスを受けた第２データ発行器２０２は、第２データ１２０を発行することができる。
【0078】
発行された第２データ１２０は、呼び出し器２０３に与えられる（ステップＳ４３）。呼び出し器２０３は、ブロックチェーン２０へ送信すべきデータを、第２データ発行器２０２から取得する（ステップＳ４３）。また、呼び出し器２０３は、ブロックチェーン２０へ送信すべきデータを、第１データ取得器２０１からも取得し得る（ステップＳ４４）。
【0079】
呼び出し器２０３は、第１データ１１０に含まれるデータの一部又は全部、及び、第２データ１２０に含まれるデータの一部又は全部を、ブロックチェーン２０へ送信する（ステップＳ４５）。
【0080】
呼び出し器２０３がブロックチェーン２０へ送信するデータは、例えば、スマートコントラクト２２に与えられるデータ（スマートコントラクト２２によって受信されるデータ）であり得る。呼び出し器２０３がブロックチェーン２０へ送信するデータは、呼び出されたスマートコントラクト２２によって操作されるトークンに関するデータであり得る。呼び出し器２０３がブロックチェーン２０へ送信するデータは、呼び出すべきスマートコントラクト２２を識別するためのデータであり得る。
【0081】
図３に示す第２例によれば、第１データ取得器２０１によって取得した第１データを、ブロックチェーン２０への送信に利用することができるだけでなく、第２データ発行器２０２によって発行された第２データ１２０をも、ブロックチェーン２０への送信に利用することができる。
【0082】
図５は、呼び出しを受けるスマートコントラクト２２によって実行される処理の一例を示している。図５に示すスマートコントラクト２２は、スマートコントラクト２２のコントラクトアドレス２１から、スマートコントラクト２２を呼び出したユーザアカウント２５Ａ，２５Ｂへ、トークンを送信する処理を、ブロックチェーン２０を構成するコンピュータに実行させるよう構成されている。なお、スマートコントラクト２２のコントラクトアドレス２１は、呼び出されるスマートコントラクト２２を識別するために用いられ得る。
【0083】
図５に示すスマートコントラクト２２は、例えば、アカウント２５Ａ，２５Ｂから、呼び出される（ステップＳ５１）。呼び出しの際には、トークンコードＣ１，Ｃ２が、アカウント２５Ａ，２５Ｂからスマートコントラクト２２のコントラクトアドレス２１へ送信される。呼び出しの際には、呼び出されるスマートコントラクト２２を特定するため、スマートコントラクト２２のコントラクトアドレス２１も、アカウント２５Ａ，２５Ｂから送信され得る。図５に示すスマートコントラクト２２は、トークンコードを受信すると、それをトリガとして、トークンを送信するよう構成されている。
【0084】
ここでトークンコードは、スマートコントラクト２２による操作対象を識別するために用いられ得る。トークンコードは、例えば、スマートコントラクト２２によって操作されるノンファンジブルトークン（ＮＦＴ）を、スマートコントラクト２２が識別するために用いられ得る。例えば、スマートコントラクト２２は、受信したトークンコードＣ１を用いて、送信すべきＮＦＴを識別し、識別されたＮＦＴを送信することができる。
【0085】
また、トークンコードは、スマートコントラクト２２によって操作されるファンジブルトークン（ＦＴ）の数を、スマートコントラクト２２が識別するために用いられ得る。例えば、スマートコントラクト２２は、受信したトークンコードＣ２を用いて、送信すべきＦＴの数（トークン数）を識別し、識別された数のＦＴを送信することができる。
【0086】
トークンコードは、スマートコントラクト２２によって操作されるトークンの種類を識別するために用いられ得る。例えば、トークンコードは、スマートコントラクト２２によって操作されるトークンが、ノンファンジブルトークンであるか、ファンジブルトークンであるかを識別するために用いられ得る。また、複数種類のファンジブルトークンが存在する場合、トークンコードは、操作されるノンファンジブルトークンの種類を識別するために用いられ得る。
【0087】
スマートコントラクト２２は、受信したトークンコードＣ１，Ｃ２を用いた識別のため、トークンテーブル３１０を備え得る。トークンテーブル３１０は、トークンコードと、トークンコードによる識別内容と、を対応付けたデータである。トークンコードによる識別内容は、例えば、図５に示すように、トークン識別子又はトークンの数である。
【0088】
スマートコントラクト２２がトークンコードによって識別する内容（トークンコードによる識別内容）は、例えば、送信すべきノンファンジブルトークンの識別子（ＮＦＴ識別子）であり得る。また、トークンコードによる識別内容は、例えば、ファンジブルトークンの数であり得る。さらにまた、トークンコードによる識別内容は、ファンジブルトークンの種類及びそのファンジブルトークンの数であり得る。
【0089】
図５に示すトークンテーブル３１０においては、一例として、トークンコードＣ１には、ＮＦＴ識別子である「NFT_id01」が対応付けられている。また、トークンコードＣ２には、「10_tokens」が対応付けられている。ここで、「10_tokens」は、ある種類のファンジブルトークンの数が１０であることを示す。トークンコードＣ３には、「1_tokens」が対応付けられている。ここで、「1_tokens」は、ある種類のファンジブルトークンの数が１であることを示す。
【0090】
なお、スマートコントラクト２２は、トークンコードによって識別される操作対象（送信対象）であるトークン４１０，４２０，４３０，４５０を予め保有している。トークンコードを受信すると、保有しているトークン４１０，４２０，４３０，４５０の中から、操作対象（送信対象）であるトークンを識別し、識別されたトークンを送信する。
【0091】
スマートコントラクト２２は、例えば、アカウント２５Ａから、トークンコードＣ１を受信する（ステップＳ５１）。すると、スマートコントラクト２２は、テーブル３１０を参照し、トークンコードＣ１に対応する操作対象として、「NFT_id01」の識別子を有するノンファンジブルトークン４１０を識別する。そして、スマートコントラクト２２は、ノンファンジブルトークン４１０をアカウント２５Ａへ送信する（ステップＳ５２）。「NFT_id01」の識別子を有するノンファンジブルトークン４１０は、一つしか存在しないため、操作対象（送信対象）がノンファンジブルトークンである場合、ＮＦＴ識別子によって操作対象（送信対象）を識別することができる。
【0092】
また、スマートコントラクト２２は、例えば、アカウント２５Ｂから、トークンコードＣ２を受信する（ステップＳ５１）。すると、スマートコントラクト２２は、テーブル３１０を参照し、トークンコードＣ２に対応する操作対象として、「10_tokens」を識別する。すなわち、スマートコントラクト２２は、送信すべきノンファンジブルトークンの数が１０単位であることを識別する。そして、スマートコントラクト２２は、保有しているファンジブルトークン４５０の中から、識別された数（１０単位）のファンジブルトークンを、アカウント２５Ｂへ送信する（ステップＳ５２）。なお、ここでは、１個のファンジブルトークンを、１単位とする。
【0093】
ファンジブルトークンは、代替性を有し、一つ一つのトークンは、識別子を有しない。このため、スマートコントラクト２２は、トークンコードＣ２によって、個々のファンジブルトークンを識別するのではなく、送信すべきトークンの数を識別する。なお、スマートコントラクト２２が複数の種類のファンジブルトークンを扱える場合、スマートコントラクト２２は、トークンコードＣ２によって、送信すべきファンジブルトークンの種類をも識別してもよい。
【0094】
トークンコードＣ１，Ｃ２，Ｃ３は、スマートコントラクト２２以外は、操作対象（送信対象）であるトークンの種類又は数を識別できないよう構成されたデータであるのが好ましい。例えば、トークンコードＣ１，Ｃ２，Ｃ３は、一見無意味又はランダムに見える値を示すデータとして構成されているのが好ましい。
【0095】
また、トークンコードＣ１，Ｃ２，Ｃ３は、ユニークなコードであるのが好ましい。スマートコントラクト２２は、同一のトークンコードＣ１，Ｃ２，Ｃ３を所定回数以下（例えば、１回）しか受け付けないように構成されているのが好ましい。すなわち、トークンデータは、スマートコントラクト２２の呼び出しのために用いることができる回数が制限されているのが好ましい。この場合、トークンコードＣ１，Ｃ２，Ｃ３の使い回しが防止される。
【0096】
図５に示すスマートコントラクト２２は、ノンファンジブルトークン及びファンジブルトークンの両方の送信に対応しているが、ノンファンジブルトークンの送信だけに対応していてもよいし、ファンジブルトークンの送信だけに対応していてもよい。
【0097】
ここで、ノンファンジブルトークンに関してみると、トークンコードＣ１は、送信されるノンファンジブルトークンの識別子として機能している。ただし、図５に示すスマートコントラクト２２は、ブロックチェーン２０において記録されているノンファンジブルトークンの識別子（例えば、「NFT_id01」）そのものを受信して、送信すべきノンファンジブルトークンを識別しているわけではない。
【0098】
ここで、スマートコントラクト２２は、ブロックチェーンにおいて記録されているノンファンジブルトークンの識別子（例えば、「NFT_id01」）を受信すると、その識別子（「NFT_id01」）で示されるノンファンジブルトークンを送信するよう構成されていてもよい。
【0099】
しかし、ブロックチェーンにおいて記録されているノンファンジブルトークンの識別子（例えば、「NFT_id01」）とは異なる識別子であるトークンコードを利用することで、意図しないノンファンジブルトークンの送信を回避できる。つまり、ブロックチェーンにおいて記録されているノンファンジブルトークンの識別子（「NFT_id01」）が、ノンファンジブルトークンの送信に利用される場合、ブロックチェーンにおいて記録されているノンファンジブルトークンの識別子（「NFT_id01」）が、第三者に知得された場合、第三者は、その識別子（「NFT_id01」）を利用して、スマートコントラクト２２からノンファンジブルトークンを不正に取得することができる。
【0100】
これに対して、トークンコードを利用する場合、ブロックチェーンにおいて記録されているノンファンジブルトークンの識別子（「NFT_id01」）が、第三者に知得されても、第三者は、ノンファンジブルトークンを不正に取得することはできなくなる。
【0101】
また、ファンジブルトークンに関してみると、トークンコードＣ２，Ｃ３は、ファンジブルトークン一つ一つを区別するための識別子を有しないファンジブルトークンの識別子として機能している。例えば、１０単位のファンジブルトークンの送信を、例えば１００回に限ってスマートコントラクト２２に行わせる場合、１００個のユニークなトークンコードを用意すればよい。この場合、スマートコントラクト２２は、トークンコードを受信すると、１０単位のファンジブルトークンを送信する。この場合において、送信されるファンジブルトークンの合計は、１０００単位であり、１０００単位のファンジブルトークンそれぞれには識別子は存在しない。しかし、トークンコードは、ファンジブルトークンの１０単位毎の識別子として機能するため、実質的に、ファンジブルトークンを１０単位毎で、個別に扱うことが容易になる。
【0102】
また、トークンコードＣ２，Ｃ３のように、トークンコードＣ２，Ｃ３毎に、送信されるファンジブルトークンの数を異ならせることも可能になる。
【0103】
ここで、スマートコントラクト２２は、送信すべきファンジブルトークンの数を示すデータ（ファンジブルトークン要求）を受信すると、受信したデータで示される数のファンジブルトークンを送信するよう構成されていてもよい。しかし、その場合、送信すべきファンジブルトークンの数を示すデータ（ファンジブルトークン要求）が、適切なものであるかの保証がない。すなわち、ファンジブルトークン要求が適切なものであるかの保証がない。
【0104】
不適切なファンジブルトークン要求を許すと、第三者は、スマートコントラクト２２からノンファンジブルトークンを不正に取得できる。つまり、スマートコントラクト２２からファンジブルトークンが意図せず流出するおそれがある。
【0105】
これに対して、トークンコードＣ２，Ｃ３を利用する場合、トークンコードＣ２，Ｃ３を有しない者は、スマートコントラクト２２からファンジブルトークンを取得できないため、ファンジブルトークンの意図しない流出が防止される。また、トークンコードＣ２，Ｃ３を利用するばあい、スマートコントラクト２２によって送信されるファンジブルトークンの種類が第三者に知得されても、トークンコードを知らない第三者は、ファンジブルトークンを不正に取得することはできない。
【0106】
なお、図５に示すスマートコントラクト２２は、送信すべきノンファンジブルトークンを予め保有しているが、トークンコードを受信（ステップＳ５１）した後に、スマートコントラクト２２が、送信すべきノンファンジブルトークンを生成してもよい。すなわち、ＮＦＴに対応付けられたトークンコードは、特定のＮＦＴ識別子に予め対応付けられている必要はない。生成されるＮＦＴは、所定の生成ルールに基づいて生成されるか、あるいはランダムに生成されてもよい。
【0107】
また、ＮＦに対応付けられたトークンコードは、送信すべきトークンの数が予め対応付けられている必要はない。送信すべきトークンの数は、所定のルール又はランダムに決定されてもよい。
【0108】
図６は、実施形態に係るシステム１０を構成する要素の一例を示している。図６に示すシステム１０は、ネットワーク１５に接続されたサーバ５１，５２を備え得る。図６においては、サーバ５１，５２として、第１サーバ５１及び第２サーバ５２が設けられている。第１サーバ５１及び第２サーバ５２は、ネットワーク１５を介してブロックチェーンにアクセスし得る。なお、第１サーバ５１及び第２サーバは、それぞれ異なるコンピュータであってもよいし、同じコンピュータであってもよい。サーバ５１，５２は、管理者によって管理され得る。管理者は、近距離無線通信装置の設置者でもあり得る。管理者は、スマートコントラクト２２の管理者（作成者）でもあり得る。
【0109】
ユーザの端末３１，３２は、ネットワーク１５を介して、第１サーバ５１又は第２サーバ５２にアクセスし得る。端末３１，３２は、ネットワーク１５を介してブロックチェーンにアクセスし得る。システム１０は、ＮＦＣタグ４０を備え得る。
【0110】
端末３１は、例えば、スマートフォン又はタブレットなどのモバイルデバイスである。以下では、端末３１の構成に関して説明するが、端末３２も同様の構成であり得る。
【0111】
端末３１は、インターネットなどのネットワーク１５に接続可能である。ユーザ端末３１は、プロセッサ３１Ａ及び記憶装置３１Ｂを備えるコンピュータによって構成され得る。記憶装置３１Ｂは、プロセッサ３１Ａに接続されている。記憶装置３１Ｂは、例えば、一次記憶装置及び二次記憶装置を備える。一次記憶装置は、例えば、ＲＡＭである。二次記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ）又はソリッドステートドライブ（ＳＳＤ）である。記憶装置３１Ｂは、プロセッサ３１Ａによって実行されるコンピュータプログラム３１Ｃを備える。プロセッサ３１Ａは、記憶装置３１Ｂに格納されたコンピュータプログラム３１Ｃを読み出して実行する。コンピュータプログラム３１Ｃは、端末３１として機能するコンピュータによって実行される命令を示すプログラムコードを有する。
【0112】
コンピュータプログラム３１Ｃは、例えば、ブロックチェーン２０のユーザアカウントに格納されたトークンを端末３１に表示させるためのウォレットアプリケーションプログラムであり得る。アプリケーションプログラム３１Ｃは、トークンの保管、トークンの送信、及びトークンの受信のためのユーザ操作のための機能を提供し得る。アプリケーションプログラム３１Ｃは、スマートコントラクト２２の呼び出しのための機能を提供し得る。すなわち、プロセッサ３１Ａは、コンピュータプログラム３１Ｃを実行することで、スマートコントラクト２２の呼び出し処理３１Ｆを実行し得る。
【0113】
また、アプリケーションプログラム３１Ｃは、ＮＦＣモジュール３１Ｄによる近距離無線通信を介して、ＮＦＣタグ４０から、通信データ４６を受信するための機能を提供し得る。
【0114】
アプリケーションプログラム３１Ｃは、ブロックチェーン２０のアカウントのためのプライベートキー３１Ｅを、端末３１の記憶装置３１Ｂに保存する機能を提供し得る。プライベートキー３１Ｅは、ユーザＵ１のアカウント２５Ａに対応付けられている。プライベートキー３１Ｅは、ブロックチェーン２０における取引記録のデジタル署名などに用いられる。プライベートキー３１Ｅは、ブロックチェーン２０のアカウントに対応しているため、アカウントからスマートコントラクト２２を呼び出し、そのアカウントへトークンを送信してもらうためには、そのアカウントに対応したプライベートキー３１Ｅが必要となる。
【0115】
図７は、端末３１は、ＮＦＣタグ４０との間で、近距離無線通信をする例を示している。図７において、ＮＦＣタグ４０は、ポスター５００に取り付けられている。ポスター５００の表面５０１には、例えば、ユーザが、近距離無線通信を利用して、トークンを取得するための手順の説明が記載されている。
【0116】
表面５０１には、例えば、「ステップ１ アプリをダウンロード」と記載されているとともに、アプリケーションプログラム３１Ｃのダウンロードのための２次元コード５０１Ａが表示されている。さらに、表面５０１には、「ステップ２ アプリのホーム画面のＮＦＣをタップ」と記載されているとともに、アプリケーションプログラム３１Ｃのホーム画面を示す図５０１Ｂが表示されている。また、表面５０１には、「ステップ３ ここにスマートフォンをかざす」と記載されているとともに、端末３１，３２をかざすべき位置を示す目印５１０が表示されている。
【0117】
図８に示すように、ポスター５００の裏面５０２において、目印５１０に対応した位置には、ＮＦＣタグ４０が取り付けられている。ＮＦＣタグ４０は、例えば、貼り付けによってポスター５００に取り付けられている。
【0118】
例えば、ポスター５００を見たユーザＵ１は、必要に応じてアプリケーションプログラム３１Ｃをダウンロードし、インストールした上で、そのアプリケーションプログラム３１Ｃを起動する。ユーザＵ１は、アプリケーションプログラム３１Ｃのホーム画面に表示されたＮＦＣボタンをタップし、ＮＦＣモジュール３１Ｄによる近距離無線通信を開始させる。ユーザＵ１は、端末３１を目印５１０の近くにかざすことで、端末３１がＮＦＣタグ４０に近接し、近距離無線通信が行われる。近距離無線通信によって、ＮＦＣタグ４０に保存されている通信データ４６が、端末３１へ送信される（ステップＳ７１）。
【0119】
実施形態においては、近距離無線通信が行われたことをトリガとして、トークンを取得するための処理が行われる（ステップＳ７２）。トークンを取得するための処理は、スマートコントラクト２２を利用して行われる。端末３１は、近距離無線通信が行われたことをトリガとして、アプリケーションプログラム３１Ｃにおけるスマートコントラクト呼び出しのための処理を実行し得る。この処理が実行されることで、ユーザＵ１は、トークンを取得できる（ステップＳ７３）。
【0120】
なお、近距離無線通信によってＮＦＣタグ４０から送信される通信データ４６は、毎回、同じものでもよい。なお、ＮＦＣタグ４０に代えて、通信毎に異なる通信データ４６を送信し得る近距離無線通信装置４０が用いられてもよい。
【0121】
実施形態においては、ポスター５００に、近距離無線通信装置４０が取り付けられているため、ポスター５００を掲示した場所に来たユーザＵ１に限定して、トークンを配布することができる。したがって、トークン配布をポスター５００が掲示された場所へのユーザの誘因に利用できる。
【0122】
すなわち、データの秘匿性に優れた近距離無線通信を利用する場合、ユーザがトークンを入手するには、端末３１をＮＦＣタグに近づける必要がある。したがって、ユーザがトークンを入手するには、近距離無線通信装置４０に近づく、という行為が必要となるため、近距離無線通信装置４０が存在する位置へ、ユーザを誘引することができる。
【0123】
近距離無線通信は、データの秘匿性に優れているため、例えば、公衆の目の付きやすいところに近距離無線通信装置４０が設置されても、データが、第三者に拡散されるのを抑制できる。例えば、通信データ４６に相当するデータを、ポスター５００に記載しておいて、ポスター５００に記載されたデータを端末３１に入力させる場合、ポスター５００を撮影した画像が第三者に拡散されると、ポスター５００が掲示された場所に訪れていない第三者もデータを入手できる。一方、近距離無線通信を利用すると、近距離無線通信装置４０に近づいたユーザにだけトークンを取得させることが可能となる。
【0124】
また、多くのユーザが訪れる場所に近距離無線通信装置４０を設置しておくことで、近距離無線通信装置４０に近づいたユーザへ、トークンを配布することができる。この結果、多くのユーザにトークンを配布でき、トークンの利用を促進できる。
【0125】
トークンの効率的な配布ため、複数のポスター５００が用いられてもよい。この場合、ユーザは、いずれかの場所に掲示されたポスター５００の近距離無線通信装置４０から、通信データ４６を受信できる。複数の近距離無線通信装置４０は、同じ通信データ４６を送信するもので足りる。なお、複数の近距離無線通信装置４０が、互いに異なるデータを含む通信データ４６を送信する場合であっても、第１データ１１０は共通のデータでよい。互いに異なるデータは、例えば、近距離無線通信装置４０の識別子である。
【0126】
なお、近距離無線通信装置４０は、ポスター５００に取り付けられている必要はない。近距離無線通信装置４０は、その他の物（被取付体）に取り付けられていてもよい。近距離無線通信装置４０が取り付けられる物は、静止物である必要はなく、車両などの移動し得る物、又は移動し得る物に装着されるものであってもよい。また、近距離無線通信装置４０は、被取付体に取り付けられている必要はなく、単独で存在していてもよい。
【0127】
図７において、近距離無線通信装置４０から送信される通信データ４６は、前述の第１データ１１０を含み得る。図８は、第１データ１１０の例と、その第１データ１１０から、前述の第２データ１２０が発行される手順の例と、を示している。図８は、発行される第２データ１２０の例も示している。
【0128】
図８に示す第１データ１１０は、ユニフォームリソースアイデンティファイア（Uniform Resource Identifier；ＵＲＩ）である。ＵＲＩは、一例として、図８に示すユニフォームリソースロケータ（Uniform Resource Locator）である。以下では、第１データ１１０としてのＵＲＩを、第１ＵＲＩ１１０という。なお、ＵＲＩは、ユニフォームリソースネーム（Uniform Resource Name）であってもよい。
【0129】
第１ＵＲＩ１１０は、第１データ１１０を取得した端末３１が、ネットワーク１５を介して、第１サーバ５１にアクセスするために用いられる。図８に示すように、第１ＵＲＩ１１０は、スキーム１１１と、オーソリティ１１３と、を備える。スキーム１１１は、ＵＲＩ（ＵＲＬ）の先頭にあり、資源に到達するための手段を表す。スキーム１１１は、例えば、https:である。オーソリティ１１３は、スキーム１１１に後続して記述され、資源の場所などを示す。以下では、第１ＵＲＩ１１０のオーソリティ１１３を、第１オーソリティ１１３という。
【0130】
第１オーソリティ１１３は、例えば、第１ホスト１１３Ａと、指定データ１１３Ｂと、を備え得る。第１ホスト１１３Ａは、アクセス先である第１サーバ５１の名前（ドメイン名）を示す。指定データ１１３Ｂは、例えば、第１ホスト１１３Ａに後続して記述されたパス（path）である。図８に示す第１オーソリティ１１３おいて、指定データ１１３Ｂは、一例として、「ｃａｍｐａｉｎｇ／１」である。「ｃａｍｐａｉｎｇ／１」は、例えば、トークンをユーザに配布する第１キャンペーンを示し得る。
【0131】
なお、第１データ１１０は、第１サーバ５１へのアクセスに用いられるデータであれば足りる。第１データ１１０は、ＵＲＩ（ＵＲＬ）の形式で記述されていなくてもよい。例えば、第１データ１１０は、指定データ１１３Ｂだけから構成されていてもよい。端末３１が、第１サーバ５１の名前を把握している場合、第１ＵＲＩ１１０は、端末３１が取得した指定データ１１３Ｂを用いて、端末３１によって生成されてもよい。また、端末３１が取得する第１データは、端末３１から第１サーバ５１にアクセスしてサインインするための認証データ（例えば、ＩＤとパスワード）であってもよい。
【0132】
図８に示すように、まず、端末３１は、第１ＵＲＩ１１０を取得する（ステップＳ８１）。図８の端末３１は、図２の第１データ取得器２０１に相当し得る。第１ＵＲＩ１１０を読み取った端末３１は、第１ＵＲＩ１１０を読み取ったことをトリガとして、第１ＵＲＩ１１０を用いて第１サーバ５１へアクセスする（ステップＳ８２）。
【0133】
端末３１は、後述の発行条件判定（ステップＳ８４）に用いられるデータを、第１サーバへ送信する（ステップＳ８２）。発行条件判定に用いられるデータは、例えば、端末３１を有するユーザを識別するための情報（ユーザ情報）、端末３１を識別するための情報（端末情報）、時刻情報、及び、端末３１の位置情報の少なくとも一つ又はそれらの２以上の組み合わせである。ユーザ情報は、例えば、ブロックチェーン２０におけるユーザＵ１のアカウント２５Ａ（ブロックチェーンアドレス）である。端末情報は、例えば、端末３１のＭＡＣアドレスである。アクセスの時刻情報は、例えば、端末３１が第１データ１１０を取得した日及び時間である。端末３１の位置情報は、例えば、全球測位衛星システム（Global Navigation Satellite System；ＧＮＳＳ）を用いた衛星測位による位置情報である。衛星測定のため、端末３１,３２は、ＧＮＳＳ受信機を備え得る。
【0134】
端末３１の位置情報は、ＧＮＳＳによる位置情報に代えて、又は加えて、端末３１によるネットワーク１５へのアクセスから求まる位置情報であってもよい。ネットワーク１５へのアクセスから求まる位置情報は、例えば、モバイル通信ネットワークへのアクセスポイントである基地局の位置情報である。ネットワーク１５へのアクセスから求まる位置情報は、端末３１に割り当てられたＩＰアドレスを用いて求められる位置情報であってもよい。
【0135】
発行条件判定に用いられるデータは、第１ＵＲＩ１１０に付加されてもよい。また、発行条件判定に用いられるデータは、第１ＵＬＩ１１０を用いたアクセスによって端末３１と第１サーバ５１との接続が確立した後に、端末３１から第１サーバへ送信されてもよい。
【0136】
第１データ１１０を用いたアクセスを受け付けた第１サーバ５１は、第２データ１２０の発行処理（第２ＵＲＩ発行処理；図１０のＵＲＩ発行処理５１Ｇ）を実行する。第１サーバ５１は、図２の第２データ発行器２０２に相当し得る。
【0137】
図１０に示すように第１サーバ５１は、プロセッサ５１Ａ及び記憶装置５１Ｂを備えるコンピュータによって構成され得る。記憶装置５１Ｂは、プロセッサ５１Ａに接続されている。記憶装置５１Ｂは、例えば、一次記憶装置及び二次記憶装置を備える。一次記憶装置は、例えば、ＲＡＭである。二次記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ）又はソリッドステートドライブ（ＳＳＤ）である。記憶装置５１Ｂは、プロセッサ５１Ａによって実行されるコンピュータプログラム５１Ｃを備える。プロセッサ５１Ａは、記憶装置５１Ｂに格納されたコンピュータプログラム５１Ｃを読み出して実行する。コンピュータプログラム５１Ｃは、ＵＲＩ発行処理５１Ｇをコンピュータに実行させる命令を示すプログラムコードを有する。
【0138】
図８に戻り、発行処理５１Ｇにおいて、第１サーバ５１は、まず、発行条件判定に用いられるデータ（ユーザ情報又は端末情報等）を受信し、受信したデータを保存する（ステップＳ８３）。発行条件判定に用いられるデータは、そのデータを第１サーバ５１が受信した時刻とともに保存されてもよい。
【0139】
発行処理５１Ｇにおいて、第１サーバ５１は、受信したデータを用いて、発行条件判定をする(ステップＳ８４)。図１０に示すように、第１サーバ５１には、発行条件判定のための発行条件５１Ｄが予め設定されている。第１サーバ５１は、発行条件を満たさない場合には第２データ１２０を発行せず（ステップＳ８９）、発行条件を満たした場合に第２データ１２０を発行する（ステップＳ８５～Ｓ８７）。
【0140】
例えば、発行条件５１Ｄは、例えば、「同一ユーザに対するトークン送信は１日１回だけ」、「同一端末に対するトークン送信は１日１回だけ」、又は「第１データを取得した端末が所定の位置に存在すること」である。
【0141】
発行条件５１Ｄが「同一ユーザに対するトークン送信は１日１回だけ」である場合、第１サーバ５１は、受信したユーザ情報と、第１サーバ５１に保存されている過去のユーザ情報とを対比する。受信したユーザ情報によるアクセス記録が同日において既に存在するときには、発行条件を満たさないため、第１サーバ５１は、第２データ１２０を発行しない（ステップＳ８９）。
【0142】
受信したユーザ情報によるアクセス記録が存在しないか、または存在していても前日以前のアクセス記録であるときには、発行条件を満たすため、第１サーバ５１は、第２データ１２０を発行する（ステップＳ８５～Ｓ８７）。
【0143】
同様に、発行条件５１Ｄが「同一端末に対するトークン送信は１日１回だけ」である場合、受信した端末情報によるアクセス記録が存在しないか、または存在していても前日以前のアクセス記録であるときには、発行条件を満たすため、第１サーバ５１は、第２データ１２０を発行する（ステップＳ８５～Ｓ８７）。
【0144】
発行条件５１Ｄが「第１データを取得した端末が所定の位置に存在すること」である場合、受信した位置情報が、発行条件５１Ｄとして設定された所定の位置に合致に存在するときには、発行条件を満たすため、第１サーバ５１は、第２データ１２０を発行する（ステップＳ８５～Ｓ８７）。なお、位置は、広がりのある範囲を含む。
【0145】
「第１データを取得した端末が所定の位置に存在すること」という発行条件を設けることで、端末が所定の位置に存在するときだけ、第２データ１２０を発行できる。
【0146】
「第１データを取得した端末が所定の位置に存在すること」という発行条件の利用は、近距離無線通信の利用と併せることで、第１データ１１０を取得する端末の位置の制約をより確実にすることができる。
【0147】
近距離無線通信による位置の制約は、近距離無線通信装置４０と端末３１とが近いという相対的な位置の制約であるのに対して、端末３１の位置情報の利用は、端末３１の絶対的な位置の制約となる。
【0148】
絶対的な位置の制約は、例えば、近距離無線通信装置４０の盗難対策に活用できる。例えば、端末３１の絶対的な位置が、近距離無線通信装置４０の本来の設置場所から離れていれば、第２データ１２０を発行しないことで、盗難されて本来の設置場所とは異なる場所にある近距離無線通信装置４０の利用が防止される。
【0149】
ステップＳ８４の発行条件判定において、発行条件を満たすと判定された場合、第１サーバ５１は、トークンコードを選択する。トークンコードは、第２データ１２０を構成し得る。
【0150】
図１０に示すように、第１サーバ５１の記憶装置５１Ｂには、トークンコードリスト５１Ｅが保存されている。トークンコードリスト５１Ｅは、複数のトークンコードを有する。ここでは、複数のトークンコードは、それぞれ異なるユニークコードであるものとする。複数のトークンコードは、予め生成され、第１サーバ５１に保存されている。複数のトークンコードは、コード番号が一対一で対応付けられている。
【0151】
第１サーバ５１は、トークンコードリスト５１Ｅを参照し、発行すべき１又は複数のトークンコードを選択する（ステップＳ８５）。一つのトークンコードは、１回だけ発行されるのが好ましい。第１サーバ５１は、例えば、コード番号順に、トークンコードを発行することができる。
【0152】
例えば、第１ＵＲＩ１１０を用いた１回目のアクセスを第１サーバ５１が受け付け、そのアクセスが発行条件を満たす場合、コード番号が「１」であるトークンコード「qC2oFsNKrHimID6u」が発行される。また、第１ＵＲＩ１１０を用いた２回目のアクセスを第１サーバ５１が受け付け、そのアクセスが発行条件を満たす場合、コード番号が「２」であるトークンコード「FsNKrHimID67sj0」が発行される。同様に、第１ＵＲＩ１１０を用いた３回目のアクセスを第１サーバ５１が受け付け、そのアクセスが発行条件を満たす場合、コード番号が「３」であるトークンコード「FsNKrHimID67sj0」が発行される。第１サーバ５１は、保有するトークンコードの数に応じた回数のトークンコード発行をすることができる。
【0153】
なお、第１サーバ５１は、複数のトークンコードリスト５１Ｅを有することができる。例えば、管理者は、トークン配布のため、第１キャンペーンと、第１キャンペーンとは異なる第２のキャンペーンと、を企画することがある。この場合、第１キャンペーンで配布されるトークンと、第２キャンペーンで配布されるトークンと、を区別したいことがある。両キャンペーンで配布されるトークンを区別する場合、トークンコードも区別されるのが好ましい。トークンコードの区別のため、第１サーバ５１は、第１キャンペーン用のトークンコードリストと、第２キャンペーン用のトークンコードリストと、を有することができる。この場合、第１サーバ５１は、トークンコードの選択に先立って、トークンコードリストを選択することができる。
【0154】
第１データ１１０に含まれる指定データ１１３Ｂ（共通コード）は、トークンコードリスト５１Ｅを選択するために用いられ得る。トークンコードリスト５１Ｅが、例えば、第１キャンペーンのためのトークンコードリストである場合、第１サーバ５１は、指定データ１１３Ｂとして、第１キャンペーンを示すデータ（例えば、「campaign/1」）を受信すると、第１キャンペーンのためのトークンコードリスト５１Ｅを選択し、そのトークンコードリスト５１Ｅの中から、発行すべきトークンコードを選択することができる。
【0155】
第１サーバ５１は、選択したトークンコードを用いて、第２データ１２０を発行する（ステップＳ８６）。図８に示す第２データ１２０は、ユニフォームリソースアイデンティファイア（Uniform Resource Identifier；ＵＲＩ）である。ＵＲＩは、一例として、図８に示すユニフォームリソースロケータ（Uniform Resource Locator）である。以下では、第２データ１２０としてのＵＲＩを、第２ＵＲＩ１２０という。なお、ＵＲＩは、ユニフォームリソースネーム（Uniform Resource Name）であってもよい。
【0156】
第２ＵＲＩ１２０は、第１サーバ５１から、端末３１へ送信される（ステップＳ８７）。第２ＵＲＩ１２０は、第２ＵＲＩ１２０を取得した端末３１が、ネットワーク１５を介して、第２サーバ５２にアクセスするために用いられ得る。なお、第２ＵＲＩ１２０の発行条件を満たさない場合、第１サーバ５１は、エラーメッセージを端末３１へ送信する（ステップＳ８９）。
【0157】
図８に示すように、第２ＵＲＩ１２０は、スキーム１２１と、オーソリティ１２３と、を備える。スキーム１２１は、例えば、https:である。オーソリティ１２３は、スキーム１２１に後続して記述され、資源の場所などを示す。以下では、第２ＵＲＩ１２０のオーソリティ１２３を、第２オーソリティ１２３という。
【0158】
第２オーソリティ１２３は、例えば、第２ホスト１２３Ａと、コントラクト情報１２３Ｂと、トークンコード１２３Ｃと、を備え得る。第２ホスト１２３Ａは、アクセス先である第２サーバ５２の名前（ドメイン名）を示す。コントラクト情報１２３Ｂ及びトークンコード１２３Ｃは、例えば、第２ホスト１２３Ａに後続して記述されたパス（path）であり得る。図８に示す第２オーソリティ１２３おいて、コントラクト情報１２３Ｂは、一例として「ｒｅｃｅｉｖｅ－ｌｉｎｋ/」であり、トークンコード１２３Ｃは、一例として「ｑＣ2ｏＦｓＮＫｒＨｉｍＩＤ６ｕ」である。トークンコード１２３Ｃは、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信される。
【0159】
コントラクト情報１２３Ｂは、呼び出し対象を識別するために用いられ得る。呼び出し対象が、スマートコントラクト２２である場合、コントラクト情報１２３Ｂは、スマートコントラクト２２のコントラクトアドレス２１を含み得る。スマートコントラクト２２が呼び出される１又は複数の関数を有する場合、コントラクト情報１２３Ｂは、呼び出される関数名を更に含み得る。本実施形態においては、コントラクト情報１２３Ｂは、第２サーバ５２によって、呼び出し対象を識別するためにブロックチェーン２０へ送られるデータ（スマートコントラクト２２のコントラクトアドレスなど）に変換される。
【0160】
なお、第２データ１２０は、スマートコントラクト２２を呼び出すためにブロックチェーン２０へ送信されるデータを含んでいれば足りる。第２データ１２０は、ＵＲＩ（ＵＲＬ）の形式で記述されていなくてもよい。例えば、第２データ１２０は、トークンコード１２３Ｃだけから構成されていてもよい。端末３１が、第２サーバ５２の名前およびコントラクト情報１２３Ｂを把握している場合、トークンコード１２３Ｃを受信した端末３１が、第２ＵＲＩ１２０を生成してもよい。また、第２データ１２０は、第２ホスト１２３Ａを有さず、コントラクト情報１２３Ｂ及びトークンコード１２３Ｃを有するデータであってもよい。
【0161】
また、第２データ１２０は、コントラクト情報１２３Ｂのように、スマートコントラクト２２を呼び出すためにブロックチェーン２０へ送信されるデータに変換されるデータを含んでもよい。後述のように、コントラクト情報１２３Ｂは、第２サーバ５２によって、呼び出し対象を識別するためにブロックチェーン２０へ送られるデータ（スマートコントラクト２２のコントラクトアドレスなど）に変換される。
【0162】
図１１は、第１ＵＲＩ１１０から、第２ＵＲＩ１２０を生成するための手順の一例を示している。第２データの発行器として機能する第１サーバ５１（第２データ発行器２０２）は、第１ＵＲＩ１１０に含まれる指定データ１１３Ｂから、第２ＵＲＩ本体を生成する。第１サーバ５１は、第２ＵＲＩ本体の生成のため、ＵＲＩテーブル５１Ｆを有する。ＵＲＩテーブル５１Ｆは、図１０に示すように、指定データと、ＵＲＩ本体と、を対応付けて構成されている。
【0163】
例えば、ＵＲＩテーブル５１Ｆにおいて、第１キャンペーンを示す指定データ「ｃａｍｐａｉｇｎ／１」には、第２ＵＲＩ本体として「ｂｂｂ．．．.ｃｏｍ／ｒｅｃｅｉｖｅ－ｌｉｎｋ／」が対応付けられている。また、第２キャンペーンを示す指定データ「ｃａｍｐａｉｇｎ／２」には、第２ＵＲＩ本体として「ｂｂｂ．．．.ｃｏｍ／ｒｅｃｅｉｖｅ＿ＮＦＴ－ｌｉｎｋ／」が対応付けられている。第３キャンペーンを示す指定データ「ｃａｍｐａｉｇｎ／３」には、第２ＵＲＩ本体として「ｂｂｂ．．．.ｃｏｍ／ｒｅｃｅｉｖｅ＿ＦＴ－ｌｉｎｋ／」が対応付けられている。
【0164】
第１キャンペーンのための第２ＵＲＩ本体は、第１キャンペーンのためのコントラクト情報１２３Ｂとして、「ｒｅｃｅｉｖｅ－ｌｉｎｋ／」を有する。すなわち、指定データ「ｃａｍｐａｉｇｎ／１」には、コントラクト情報１２３Ｂとして、第１キャンペーンのための「ｒｅｃｅｉｖｅ－ｌｉｎｋ／」が対応付けられている。
【0165】
第２キャンペーンのための第２ＵＲＩ本体は、第２キャンペーンのためのコントラクト情報１２３Ｂとして、「ｒｅｃｅｉｖｅ＿ＮＦＴ－ｌｉｎｋ／」を有する。すなわち、指定データ「ｃａｍｐａｉｇｎ／２」には、コントラクト情報１２３Ｂとして、第２キャンペーンのための「ｒｅｃｅｉｖｅ＿ＮＦＴ－ｌｉｎｋ／」が対応付けられている。
【0166】
第３キャンペーンのための第２ＵＲＩ本体は、第３キャンペーンのためのコントラクト情報１２３Ｂとして、「ｒｅｃｅｉｖｅ＿ＦＴ－ｌｉｎｋ／」を有する。すなわち、指定データ「ｃａｍｐａｉｇｎ／３」には、コントラクト情報１２３Ｂとして、第３キャンペーンのための「ｒｅｃｅｉｖｅ＿ＦＴ－ｌｉｎｋ／」が対応付けられている。
【0167】
なお、本実施形態では、一例として、第１キャンペーンは、第１データ１１０を取得したユーザが、第１の種類のノンファンジブルトークン（ＮＦＴ）又は第２の種類のファンジブルトークン（ＮＦ）のいずれか一方を選択的に取得できるキャンペーンであるものとする。また、第２キャンペーンは、第１データ１１０を取得したユーザが、第１の種類とは異なる第３の種類のノンファンジブルトークン（ＮＦＴ）を取得できるキャンペーンであるものとする。さらに、第３キャンペーンは、第１データ１１０を取得したユーザが、第２の種類とは異なる第４の種類のファンジブルトークン（ＦＴ）を取得できるキャンペーンであるものとする。
【0168】
図１１に戻り、第１サーバ５１は、ＵＲＩテーブル５１Ｆを参照し、指定データ「ｃａｍｐａｉｇｎ／１」から、第２ＵＲＩ本体として「ｂｂｂ．．．.ｃｏｍ／ｒｅｃｅｉｖｅ－ｌｉｎｋ」を取得する。
【0169】
また、第１サーバ５１は、指定データ「ｃａｍｐａｉｇｎ／１」に対応付けられたトークンコードリスト５１Ｅを選択し、一つのトークンコードを決定する。ここでは、一例として、コード番号１のトークンコード「ｑＣ2ｏＦｓＮＫｒＨｉｍＩＤ６ｕ」が選択される。
【0170】
第１サーバ５１は、第２ＵＲＩ本体とトークンコードとを組み合わせて、第２ＵＲＩ１２０を生成する。例えば、第１サーバ５１は、第２ＵＲＩ本体に後続するパスの一部としてトークンコードを、第２ＵＲＩ本体に付加することができる。
【0171】
なお、キャンペーンが一つしかない場合など、第２ＵＲＬ本体が、第１ＵＲＩ１１０の内容にかかわらず、一つに決まる場合には、ＵＲＩテーブル５１Ｆを用いた第２ＵＲＩ本体の決定、及び、トークンコードリストの選択は、省略されてもよい。
【0172】
図９は、第２ＵＲＩ１２０を用いて、スマートコントラクト２２を呼び出す手順の一例を示している。スマートコントラクト２２を呼び出すため、端末３１は、第２ＵＲＩ１２０を用いて、第２サーバ５２へアクセスする（ステップＳ９１）。端末３１のアクセスを受けた第２サーバ５２は、端末３１のユーザのために、スマートコントラクト２２を呼び出す（ステップＳ９３）。呼び出されたスマートコントラクト２２は、トークン送信などの所定の処理を実行する（ステップＳ９４）。ここでの端末３１及び第２サーバ５２は、図２の呼び出し器２０３に相当し得る。
【0173】
第２サーバ５２は、スマートコントラクト２２の呼び出しに先立ってスマートコントラクト２２を呼び出すために必要なデータを取得することができる（ステップＳ９３）。スマートコントラクト２２を呼び出すために必要なデータは、例えば、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータである。
【0174】
第２サーバ５２は、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを、図１２に示すコントラクトテーブル５２Ｄを用いて取得することができる。
【0175】
図１２に示すように第２サーバ５２は、プロセッサ５２Ａ及び記憶装置５２Ｂを備えるコンピュータによって構成され得る。記憶装置５２Ｂは、プロセッサ５２Ａに接続されている。記憶装置５２Ｂは、例えば、一次記憶装置及び二次記憶装置を備える。一次記憶装置は、例えば、ＲＡＭである。二次記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ）又はソリッドステートドライブ（ＳＳＤ）である。記憶装置５２Ｂは、プロセッサ５２Ａによって実行されるコンピュータプログラム５２Ｃを備える。プロセッサ５２Ａは、記憶装置５２Ｂに格納されたコンピュータプログラム５２Ｃを読み出して実行する。コンピュータプログラム５２Ｃは、呼び出し処理５２Ｆをコンピュータに実行させる命令を示すプログラムコードを有する。
【0176】
記憶装置５２Ｂには、前述のコントラクトテーブル５２Ｄが保存されている。コントラクトテーブル５２Ｄは、コントラクト情報と、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるコントラクト呼び出しデータと、を対応付けて構成されている。コントラクト呼び出しデータは、例えば、呼び出されるスマートコントラクト２２のコントラクトアドレスを含む。コントラクト呼び出しデータは、呼び出されるスマートコントラクト２２の関数名を含んでもよい。
【0177】
図１２に示すコントラクトテーブル５２Ｄにおいては、一例として、第１キャンペーンのためのコントラクト情報：「ｒｅｃｅｉｖｅ－ｌｉｎｋ／」に、コントラクトアドレス「０ｘ８８８８」及び関数：Ｆ１が対応付けられている。コントラクトアドレス「０ｘ８８８」は、第１キャンペーンのために、トークンを送信するよう構成されたスマートコントラクトのコントラクトアドレスであるものとする。関数：Ｆ１は、コントラクトアドレス「０ｘ８８８８」に格納されたスマートコントラクト２２において、第１キャンペーンのためにトークンを送信するために呼び出される関数であるものとする。
【0178】
また、図１２に示すコントラクトテーブル５２Ｄにおいては、一例として、第２キャンペーンのためのコントラクト情報：「ｒｅｃｅｉｖｅ＿ＮＦＴ－ｌｉｎｋ／」に、コントラクトアドレス「０ｘ７７７７」及び関数：Ｆ２が対応付けられている。コントラクトアドレス「０ｘ７７７７」は、第２及び第３キャンペーンのために、トークンを送信するよう構成されたスマートコントラクトのコントラクトアドレスであるものとする。関数：Ｆ２は、コントラクトアドレス「０ｘ７７７７」に格納されたスマートコントラクトにおいて、第２キャンペーンのためにノンファンジブルトークン（ＮＦＴ）を送信するために呼び出される関数であるものとする。
【0179】
また、図１２に示すコントラクトテーブル５２Ｄにおいては、一例として、第３キャンペーンのためのコントラクト情報：「ｒｅｃｅｉｖｅ＿ＦＴ－ｌｉｎｋ／」に、コントラクトアドレス「０ｘ７７７７」及び関数：Ｆ３が対応付けられている。関数：Ｆ３は、コントラクトアドレス「０ｘ７７７７」に格納されたスマートコントラクトにおいて、第２キャンペーンのためにファンジブルトークン（ＦＴ）を送信するために呼び出される関数であるものとする。
【0180】
図１３は、コントラクト情報１２３Ｂから、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータを生成する手順の一例を示している。第２サーバ５２は、コントラクトテーブル５２Ｄを参照して、第２ＵＲＩ１２０に含まれるコントラクト情報１２３Ｂから、スマートコントラクト２２の呼び出しのためにブロックチェーン２０へ送信されるデータとして、コントラクトアドレス及び関数名を取得する。
【0181】
図１３では、一例として、コントラクト情報１２３Ｂとしての「ｒｅｃｅｉｖｅ－ｌｉｎｋ／」から、コントラクトアドレス「０ｘ８８８８」及び関数：Ｆ１が得られる。コントラクトアドレス「０ｘ８８８８」及び関数：Ｆ１は、呼び出し対象を示す情報として、ブロックチェーン２０へ送信される。
【0182】
なお、図９における第２サーバ５２によるスマートコントラクト２２の呼び出しは、端末３１によって行われてもよい。
【0183】
図１４は、スマートコントラクトの呼び出しのために、ブロックチェーン２０へ送信されるデータ１２５の一例を示している。なお、呼び出しは、ブロックチェーン２０においては、端末３１，３２のユーザのブロックチェーンアカウント２５Ａ，２５Ｂから送信されたものとして扱われる。
【0184】
データ１２５は、例えば、呼び出されるスマートコントラクトのコントラクトアドレスを含むことができる。例えば、呼び出されるスマートコントラクト２２Ａのコントラクトアドレスが、０ｘ８８８８であれば、データ１２５は、０ｘ８８８８を含むことができる。呼び出されるスマートコントラクト２２Ｂのコントラクトアドレスが、０ｘ７７７７であれば、データ１２５は、０ｘ７７７７を含むことができる。
【0185】
データ１２５は、例えば、呼び出されるスマートコントラクト２２Ａ，２２Ｂの関数名を含むことができる。例えば、呼び出される関数が、スマートコントラクト２２Ａの関数Ｆ１である場合、データ１２５は、関数名としてＦ１を含むことができる。呼び出される関数が、スマートコントラクト２２Ｂの関数Ｆ２である場合、データ１２５は、関数名としてＦ２を含むことができる。呼び出される関数が、スマートコントラクト２２Ｂの関数Ｆ３である場合、データ１２５は、関数名としてＦ３を含むことができる。
【0186】
データ１２５は、例えば、スマートコントラクト２２に与えられるトークンコードを含むことができる。スマートコントラクト２２は、トークンコードによって、操作すべきトークンを識別することができる。
【0187】
図１５は、図１４に示すスマートコントラクト２２Ａが、トークンコードによってトークンを識別し、識別されたトークンを送信する方法を示している。送信されるトークンの識別のため、スマートコントラクト２２は、トークンテーブル３１０を備える。トークンテーブル３１０は、ブロックチェーン２０においてスマートコントラクト２２を実行するコンピュータ（ブロックチェーンにおけるノード）の記憶装置に保存されている。
【0188】
図１５のトークンテーブル３１０は、図５に示したトークンテーブル３１０と同様のものでよい。図１５のトークンテーブル３１０では、より具体的に、トークンコード「qC2oFsNKrHimID6u」には、ノンファンジブルトークンの識別子「NFT_id04」が対応付けられている。また、トークンコード「FsNKrHimID67sj0」には、「5_tokens」及びノンファンジブルトークンの識別子「NFT_id05」が対応付けられている。ここで、「5_tokens」は、ある種類のファンジブルトークンの数が５であることを示す。トークンコード「Uwnvu7930s3hmvh」には、「5_tokens」が対応付けられている。
【0189】
また、図１５に示すトークンテーブル３１０は、第１キャンペーンのためのトークンコードから、第１キャンペーンにおいて送信されるトークンを識別するために用いられる。すなわち、図１５に示すトークンテーブル３１０は、第１キャンペーンのための第１関数Ｆ１（第１キャンペーン用のトークン送信関数）によって参照される。
【0190】
なお、スマートコントラクト２２Ａのコントラクトアドレス０ｘ８８８８には、第１キャンペーンにおいて送信されるトークンが格納されている。つまり、スマートコントラクト２２Ａは、第１キャンペーンにおいて送信されるトークンを予め所有している。
【0191】
スマートコントラクト２２Ａの第１関数Ｆ１は、呼び出されると同時にトークンコードを受信し得る。例えば、スマートコントラクト２２Ａの関数Ｆ１は、ユーザＵ１のブロックチェーンアカウントである０ｘ９９９９から、呼び出しを受ける（ステップＳ１５１）。この呼び出しの際に、関数Ｆ１は、トークンコード「qC2oFsNKrHimID6u」を受信する。関数Ｆ１は、トークンテーブル３１０を参照し、送信すべきトークンが、「NFT_id04」のＮＦＴ識別子を有するノンファンジブルトークン（ＮＦＴ）であることを識別する。関数Ｆ１は、「NFT_id04」のＮＦＴ識別子を有するＮＦＴを、呼び出し元である０ｘ９９９９へ送信する（ステップＳ１５２）。これにより、ユーザＵ１は、「NFT_id04」のＮＦＴ識別子を有するＮＦＴを取得できる。ユーザＵ１が取得したＮＦＴは、ユーザＵ１が有する端末３１に表示され得る。
【0192】
また、スマートコントラクト２２Ａの関数Ｆ１は、ユーザＵ２のブロックチェーンアカウントである０ｘ１１１１から、呼び出しを受けることができる（ステップＳ１５１）。この呼び出しの際に、関数Ｆ１は、トークンコード「FsNKrHimID67sj0」を受信する。関数Ｆ１は、トークンテーブル３１０を参照し、送信すべきトークンが、５単位のファンジブルトークン（ＦＴ）と「NFT_id05」のＮＦＴ識別子を有するノンファンジブルトークン（ＮＦＴ）であることを識別する。関数Ｆ１は、５単位のＦＴ及び「NFT_id04」のＮＦＴ識別子を有するＮＦＴを、呼び出し元である０ｘ１１１１へ送信する。これにより、ユーザＵ２は、５単位のＦＴ及び「NFT_id05」のＮＦＴ識別子を有するＮＦＴを取得できる。ユーザＵ２が取得したＮＦＴは、ユーザＵ２が有する端末３２に表示され得る。
【0193】
図１６は、第１データ１１０及び第２データ１２０を利用したスマートコントラクト２２Ａの呼び出しの一例を示している。本開示における技術を利用すると、複数の端末３１，３２，３３が外部から取得するデータ（第１データ１１０，指定データ１１３Ｂ）が、それぞれ同じデータであっても、複数の端末３１，３２，３３それぞれは、異なるトークンコードＣ１，Ｃ２，Ｃ３を取得することができる。つまり、まず、各端末３１，３２，３３は、共通のデータ１１３Ｂを取得する（ステップＳ１６１Ａ，Ｓ１６１Ｂ，Ｓ１６１Ｃ）。そして、端末３１は、共通のデータ１１３Ｂを用いて、第１サーバ５１からユニークな第１トークンコードＣ１を取得する（ステップＳ１６２Ａ）。また、端末３２は、共通のデータ１１３Ｂを用いて、第１サーバ５１からユニークな第２トークンコードＣ２を取得する（ステップＳ１６２Ｂ）。端末３３は、共通のデータ１１３Ｂを用いて、第１サーバ５１からユニークなトークンコードＣ３を取得する（ステップＳ１６２Ｃ）。各端末３１，３２，３３は、ユニークなトークンコードＣ１，Ｃ２，Ｃ３を用いて、スマートコントラクト２２を呼び出すことができる（ステップＳ１６３Ａ，Ｓ１６３Ｂ，Ｓ１６３Ｃ）。これにより、各端末３１，３２，３３のユーザは、トークンコードＣ１，Ｃ２，Ｃ３に対応するトークンを取得することができる。
【0194】
また、端末３１，３２，３３へ第１データ１１０（指定データ１１３Ｂ）を与え得る装置４０Ａ，４０Ｂが、複数設置される場合であっても、それらの装置４０Ａ，４０Ｂが端末３１，３２，３３へ送信する第１データ１１０（指定データ１１３Ｂ）は、全て共通のものであってもよい。データを共通にすることで、多くの装置４０Ａ，４０Ｂを準備するのが容易になる。そして、例えば、第１キャンペーンのために複数の装置４０Ａ，４０Ｂを設置することで、第１キャンペーンのためのトークンを効率的に配布できる。
【0195】
図１７は、第１データの他の例を示している。図１７に示す第１データ１３０は、図８に示す第２ＵＲＩ１２０と同様のデータである。図１７に示す例では、端末３１は、第１データ１３０として、図８の第２ＵＲＩに相当するデータを取得する（ステップＳ１７１）。このため、図１７に示す例では、第１サーバ５１による第２データ１２０の発行を省略できる。第１データ１３０としての第２ＵＲＩは、第２ＵＲＩを取得した端末３１が、ネットワーク１５を介して、第２サーバ５２にアクセスするために用いられ得る（図９参照）。したがって、図１７に示す例の場合においても、トークンコードを用いて、スマートコントラクト２２を呼び出すことができる。なお、第１データ１３０としての第２ＵＲＩに関し、特に説明しない点については、第２データ１２０としての第２ＵＲＩ（図８参照）と同様である。
【0196】
図１７に示す例の場合、第１データ１３０には、トークンコード１２３Ｃが含まれている。したがって、複数の異なるトークンコード１２３Ｃを配布したい場合、それぞれ異なるとトークンコード１２３Ｃを送信する複数のＮＦＣタグ４０（近距離無線通信装置４０）を用意すればよい。
【0197】
なお、図１７に示す端末３１は、第２サーバ５２を介さずに、ブロックチェーン２０のスマートコントラクト２２を呼び出してもよい。
【0198】
図１８は、図８及び図９に示す手順でトークンを配布する場合におけるシステム１０の事前設定を示している。なお、図８及び図９に示す手順は、第１データから第２データを発行するものであり図３に示す手順に相当する。
【0199】
まず、コンピュータによって、配布されるトークンのための複数のトークンコードを生成させる（ステップＳ１８１）。複数のトークンコードそれぞれは、ユニークなコードとして生成される。例えば、１００個のノンファンジブルトークン（ＮＦＴ）を配布したい場合、１００個のトークンコードが生成される。また、所定数のファンジブルトークン（ＦＴ）を１０００回配布したい場合、１０００個のトークンコードが生成される。
【0200】
配布されるトークンは、当該トークンを配布するスマートコントラクト２２のコントラクトアドレスに、預けられる（ステップＳ１８２）。預けられるトークンは、ノンファンジブルトークン（ＮＦＴ）であってもよいし、ファンジブルトークン（ＦＴ）であってもよいし、ＮＦＴ及びＮＴであってもよい。スマートコントラクト２２は、トークンを預かることにより、トークンを所有していることになる。スマートコントラクト２２は、所有しているトークンの中から、トークンコードに対応するトークンを送信する。
【0201】
管理者は、スマートコントラクト２２のコントラクトアドレスに、トークンテーブル３１０（図５，図１５参照）を書き込む（ステップＳ１８３）。トークンテーブル３１０は、ステップＳ１８１で生成したトークンコードと、ステップＳ１８２で預けたトークンとの対応を示す。
【0202】
管理者は、第１データ１１０として第１ＵＲＩ１１０（図８参照）を生成する（ステップＳ１８４）。第１ＵＲＩ１１０は、第１サーバ５１へアクセスするためのＵＲＩである。生成された第１ＵＲＩ１１０は、図示しない書き込み装置を用いて、１又は複数のＮＦＣタグ４０に書き込まれる（ステップＳ１８５）。これにより、ＮＦＣタグ４０は、第１ＵＲＩ１１０を近距離無線通信により送信することができる（図１，２，図７，図８参照）。ＮＦＣタグ４０は、それが使用される場所に設置される。
【0203】
管理者は、ステップＳ１８４で生成した第１ＵＲＩ１１０を用いてアクセスされる第１サーバに、トークンコードリスト５１Ｅ（図１０参照）を保存する（ステップＳ１８６）。トークンコードリスト５１Ｅは、ステップＳ１８１で生成したトークンコードの一覧である。
【0204】
【0205】
管理者は、第１ＵＲＩ１１０を用いてアクセスされる第１サーバ５１に、ＵＲＩテーブル５１Ｆ（図１０参照）を保存する（ステップＳ１８８）。ＵＲＩテーブル５１Ｆは、ステップＳ１８４で生成した第１ＵＲＩ１１０に含まれる指定データ１１３Ｂと、ステップＳ１８７で生成した第２ＵＲＩ本体と、の対応を示す。
【0206】
管理者は、第２ＵＲＩを用いてアクセスされる第２サーバ５２に、コントラクトテーブル５２Ｄ（図１２参照）を保存する（ステップＳ１８９）。コントラクトテーブル５２Ｄは、ステップＳ１８７で生成した第２ＵＲＩ本体に含まれるコントラクト情報１２３Ｂと、スマートコントラクト２２の呼び出しデータと、の対応を示す。
【0207】
図１９は、図１７及び図９に示す手順でトークンを配布する場合におけるシステム１０の事前設定を示している。なお、図１７及び図９に示す手順は、第２データの発行を伴わないものであり、図４に示す手順に相当する。なお、図１９において、図１８と共通するステップに関し、特に説明しない点については、図１８に関する説明が援用される。
【0208】
まず、コンピュータによって、配布されるトークンのための複数のトークンコードを生成させる（ステップＳ１９１）。このステップＳ１９１は、図１８のステップＳ１８１と共通する。
【0209】
配布されるトークンは、当該トークンを配布するスマートコントラクト２２のコントラクトアドレスに、預けられる（ステップＳ１９２）。このステップＳ１９２は、図１８のステップＳ１８２と共通する。
【0210】
【0211】
管理者は、第１データ１３０として第２ＵＲＩ（図１７参照）を生成する（ステップＳ１９４）。第２ＵＲＩ１３０は、第２サーバ５２へアクセスするためのＵＲＩである。生成された第２ＵＲＩ１３０は、図示しない書き込み装置を用いて、１又は複数のＮＦＣタグ４０に書き込まれる（ステップＳ１９５）。これにより、ＮＦＣタグ４０は、第２ＵＲＩ１３０を近距離無線通信により送信することができる（図１７参照）。ＮＦＣタグ４０は、それが使用される場所に設置される。
【0212】
管理者は、第２ＵＲＩを用いてアクセスされる第２サーバ５２に、コントラクトテーブル５２Ｄ（図１２参照）を保存する（ステップＳ１９６）。このステップＳ１９６は、図１８のステップＳ１８９と共通する。コントラクトテーブル５２Ｄは、ステップＳ１９４で生成した第２ＵＲＩに含まれるコントラクト情報１２３Ｂと、スマートコントラクト２２の呼び出しデータと、の対応を示す。
【0213】
図２０は、第１データの他の例を示している。図２０に示す第１データ１４０は、プライベートキー１４０である。プライベートキー１４０は、ブロックチェーン２０のアカウントに対応する。図６に示すプライベートキー３１Ｅは、ブロックチェーン２０を利用するための端末３１に格納されているが、図２０に示す例では、端末３１には、プライベートキーが格納されておらず、その代わりに、ＮＦＣタグ４０（近距離無線通信装置４０）に格納されている。図２０に示す例では、一例として、ＮＦＣタグ４０には、端末３１を有するユーザＵ１のアカウント２５Ａのためのプライベートキー１４０が格納されているものとする。
【0214】
図２０に示す例では、端末３１は、近距離無線通信を介して、第１データ１４０として、プライベートキー１４０を取得する（ステップＳ２０１）。送信されるプライベートキー１４０は暗号化されているのが好ましい。なお、プライベートキー１４０以外の他の第１データ１１０，１３０も暗号化されていてもよい。
【0215】
近距離無線通信によってプライベートキー１４０を取得した端末３１は、図６に示す端末３１のように、プライベートキーを有していることになる。プライベートキー１４０は、ユーザＵ１のアカウント２５Ａのブロックチェーンアドレスを生成できるため、端末３１からブロックチェーン２０における操作が可能となる。すなわち、ユーザＵ１のアカウントに対応するプライベートキー１４０を取得した端末３１を用いると、ユーザＵ１のアカウント２５Ａからのスマートコントラクト２２の呼び出しが可能となる。
【0216】
ここでは、ブロックチェーン２０のスマートコントラクト２２を呼び出すためのデータのうち、プライベートキー１４０以外のデータは、予め端末３１に設定されているものとする。端末３１は、プライベートキー１４０を取得したことをトリガとして、予め設定された呼び出しデータを取得し（ステップＳ２０２）、スマートコントラクト２２を呼び出す（ステップＳ２０３）。呼び出されたスマートコントラクト２２は、アカウント２５Ａへのトークン送信など、ブロックチェーン２０における所定の操作を実行する（ステップＳ２０４）。
【0217】
図２１は、第１データの他の例を示している。図２１に示す第１データ１５０は、ユーザコード１５０である。ここでは、近距離無線通信装置は、ＩＣカードとして構成されている。以下では、このＩＣカードを、ＮＦＣカード４０Ａという。ＮＦＣカード４０Ａは、一例として、支払い手段として用いられる。ここでは、ブロックチェーン２０におけるファンジブルトークンを、実店舗における支払いに用いるために、ＮＦＣカード４０Ａが利用され得る。ここで、ＮＦＣカード４０Ａは、プリペイドカードとして利用される。
【0218】
まず、ブロックチェーン２０のスマートコントラクト２２には、ユーザコードに対応する所定の数（例えば、１０００単位）のファンジブルトークンが預けられる（ステップＳ２１１）。預けられたファンジブルトークンの数が、ユーザコードにおけるファンジブルトークンの残高となる。ユーザコードは、ＮＦＣカード４０Ａに書き込まれる。ＮＦＣカード４０Ａは、ユーザＵ４に販売される。ユーザＵ４は例えば、現金決済、クレジットカード決済、電子マネー決済など、法定通貨による支払いで、ファンジブルトークンのプリペイドカードであるＮＦＣカード４０Ａを購入し得る。
【0219】
ＮＦＣカード４０Ａを入手したユーザＵ４は、ファンジブルトークンを利用可能な店舗において、ＮＦＣカード４０Ａを、支払いに利用し得る。まず、店舗の端末３５は、使用トークン数を取得する（ステップＳ２１２）。使用トークン数は、ユーザＵ４の購入した商品の代金（法定通貨での金額）に相当するファンジブルトークンの数である。使用トークン数は、所定の換算レートに基づいて求められる。使用トークン数は、端末３５によって計算されてもよいし、他の装置によって計算されてもよい。
【0220】
使用トークン数の支払いに同意したユーザＵ４は、ＮＦＣカード４０Ａを店舗の端末３５にかざす。これにより、ＮＦＣカード４０Ａから、端末３５へ、ユーザコードが、近距離無線通信によって送信される（ステップＳ２１３）。端末３５は、必要に応じて、ユーザコードを用いて、スマートコントラクト２２の呼び出しデータを取得する（ステップＳ２１４）。ここでの呼び出しデータは、例えば、端末３５が受信したユーザコードのために支払処理（トークン送信処理）を実行するスマートコントラクト２２を識別するためのデータである。呼び出しデータは、例えば、ユーザコードを用いて、外部のサーバから取得できる。
【0221】
端末３５は、例えば、使用トークン数及びユーザコードの送信とともに、スマートコントラクト２２を呼び出すことができる（ステップＳ２１５）。呼び出しは、例えば、ブロックチェーン２０における店舗アカウントから行われる。呼び出されたスマートコントラクト２２は、トークンコードが示すファンジブルトークン残高から、使用トークン数に応じたファンジブルトークンを、店舗アカウントへ送信する（ステップＳ２１６）。なお、ファンジブルトークン残高は、使用トークン数ほど減少する。
【0222】
以上によれば、ユーザＵ４自身は、支払い時において、ブロックチェーン２０を直接操作することなく、ブロックチェーン２０におけるファンジブルトークンを支払いに利用することができる。
【0223】
本発明は、上記実施形態に限定されるものではなく、様々な変形が可能である。
【0224】
＜３．付記＞
【0225】
本開示は、以下の内容を含む。
【0226】
［項１］トークンコードを、ブロックチェーンに実装されたスマートコントラクトが受信し、前記スマートコントラクトが、トークンコードに従って、前記スマートコントラクトが保有するトークンを操作する、ことを備える方法又はシステム。
【0227】
［項２］ブロックチェーンにおけるアカウントからトークンコードを受信したスマートコントラクトが、トークンコードに応じたトークンを、前記アカウントへ送信する、ことを備える方法又はシステム。
【0228】
［項３］トークンコードを受信したスマートコントラクトが、トークンコードに対応付けられた数のファンジブルトークンを、送信する、ことを備える方法又はシステム。
【0229】
［項４］スマートコントラクトが、トークンコードを受信すると、送信すべきファンジブルトークンの数を決定し、決定した数のファンジブルトークンを送信する、ことを備える方法又はシステム。
【0230】
［項５］トークンコードを受信したスマートコントラクトが、トークンコードに対応付けられたノンファンジブルトークンを、送信する、ことを備える方法又はシステム。
【0231】
［項６］スマートコントラクトが、トークンコードを受信すると、送信すべきノンファンジブルトークンを生成し、生成したノンファンジブルトークンを送信する、ことを備える方法又はシステム。
【符号の説明】
【0232】
１０ ：システム
１５ ：ネットワーク
２０ ：ブロックチェーン
２１ ：コントラクトアドレス
２２ ：スマートコントラクト
２２Ａ ：スマートコントラクト
２２Ｂ ：スマートコントラクト
２５Ａ ：ユーザアカウント
２５Ｂ ：ユーザアカウント
３１ ：端末
３１Ａ ：プロセッサ
３１Ｂ ：記憶装置
３１Ｃ ：コンピュータプログラム
３１Ｄ ：近距離無線通信モジュール
３１Ｅ ：プライベートキー
３１Ｆ ：呼び出し処理
３２ ：端末
３２Ｄ ：近距離無線通信モジュール
３３ ：端末
３５ ：端末
４０ ：近距離無線通信装置（ＮＦＣタグ）
４０Ａ ：ＮＦＣカード
４０Ｂ ：装置
４１ ：アンテナ
４２ ：無線回路
４３ ：コントローラ
４４ ：メモリ
４６ ：通信データ
５１ ：第１サーバ
５１Ａ ：プロセッサ
５１Ｂ ：記憶装置
５１Ｃ ：コンピュータプログラム
５１Ｄ ：発行条件
５１Ｅ ：トークンコードリスト
５１Ｆ ：ＵＲＩテーブル
５１Ｇ ：ＵＲＩ発行処理
５２ ：第２サーバ
５２Ａ ：プロセッサ
５２Ｂ ：記憶装置
５２Ｃ ：コンピュータプログラム
５２Ｄ ：コントラクトテーブル
５２Ｆ ：呼び出し処理
１１０ ：第１データ（第１ＵＲＩ）
１１１ ：スキーム
１１３ ：第１オーソリティ
１１３Ａ ：第１ホスト
１１３Ｂ ：指定データ
１２０ ：第２データ（第２ＵＲＩ）
１２１ ：スキーム
１２３ ：第２オーソリティ
１２３Ａ ：第２ホスト
１２３Ｂ ：コントラクト情報
１２３Ｃ ：トークンコード
１２５ ：データ
１３０ ：第１データ（第２ＵＲＩ）
１４０ ：第１データ（プライベートキー）
１５０ ：第１データ（ユーザコード）
２０１ ：第１データ取得器
２０２ ：第２データ発行器
２０３ ：呼び出し器
３１０ ：トークンテーブル
４１０ ：ノンファンジブルトークン
４２０ ：トークン
４３０ ：トークン
４５０ ：ファンジブルトークン
５００ ：ポスター
５０１ ：表面
５０１Ａ ：２次元コード
５０２ ：裏面
５１０ ：目印
Ｃ１ ：第１トークンコード
Ｃ２ ：第２トークンコード
Ｃ３ ：トークンコード
Ｆ１ ：第１関数
Ｆ２ ：関数
Ｆ３ ：関数
１５ ：ネットワーク
２０ ：ブロックチェーン
２１ ：コントラクトアドレス
２２ ：スマートコントラクト
２２Ａ ：スマートコントラクト
２２Ｂ ：スマートコントラクト
２５Ａ ：ユーザアカウント
２５Ｂ ：ユーザアカウント
３１ ：端末
３１Ａ ：プロセッサ
３１Ｂ ：記憶装置
３１Ｃ ：コンピュータプログラム
３１Ｄ ：近距離無線通信モジュール
３１Ｅ ：プライベートキー
３１Ｆ ：呼び出し処理
３２ ：端末
３２Ｄ ：近距離無線通信モジュール
３３ ：端末
３５ ：端末
４０ ：近距離無線通信装置（ＮＦＣタグ）
４０Ａ ：ＮＦＣカード
４０Ｂ ：装置
４１ ：アンテナ
４２ ：無線回路
４３ ：コントローラ
４４ ：メモリ
４６ ：通信データ
５１ ：第１サーバ
５１Ａ ：プロセッサ
５１Ｂ ：記憶装置
５１Ｃ ：コンピュータプログラム
５１Ｄ ：発行条件
５１Ｅ ：トークンコードリスト
５１Ｆ ：ＵＲＩテーブル
５１Ｇ ：ＵＲＩ発行処理
５２ ：第２サーバ
５２Ａ ：プロセッサ
５２Ｂ ：記憶装置
５２Ｃ ：コンピュータプログラム
５２Ｄ ：コントラクトテーブル
５２Ｆ ：呼び出し処理
１１０ ：第１データ（第１ＵＲＩ）
１１１ ：スキーム
１１３ ：第１オーソリティ
１１３Ａ ：第１ホスト
１１３Ｂ ：指定データ
１２０ ：第２データ（第２ＵＲＩ）
１２１ ：スキーム
１２３ ：第２オーソリティ
１２３Ａ ：第２ホスト
１２３Ｂ ：コントラクト情報
１２３Ｃ ：トークンコード
１２５ ：データ
１３０ ：第１データ（第２ＵＲＩ）
１４０ ：第１データ（プライベートキー）
１５０ ：第１データ（ユーザコード）
２０１ ：第１データ取得器
２０２ ：第２データ発行器
２０３ ：呼び出し器
３１０ ：トークンテーブル
４１０ ：ノンファンジブルトークン
４２０ ：トークン
４３０ ：トークン
４５０ ：ファンジブルトークン
５００ ：ポスター
５０１ ：表面
５０１Ａ ：２次元コード
５０２ ：裏面
５１０ ：目印
Ｃ１ ：第１トークンコード
Ｃ２ ：第２トークンコード
Ｃ３ ：トークンコード
Ｆ１ ：第１関数
Ｆ２ ：関数
Ｆ３ ：関数
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】