特開 2023-94491 サーバ、トークン配布システム、及びコンピュータ実装方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023094491

(43)【公開日】2023-07-05

(54)【発明の名称】サーバ、トークン配布システム、及びコンピュータ実装方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20230628BHJP

【ＦＩ】

G06F21/62 318

【審査請求】未請求

【請求項の数】15

【出願形態】ＯＬ

(21)【出願番号】P 2021210014

(22)【出願日】2021-12-23

(71)【出願人】

【識別番号】518003096

【氏名又は名称】Ｂａｃｏｏｒ ｄＡｐｐｓ株式会社

(71)【出願人】

【識別番号】320003367

【氏名又は名称】株式会社ＡＩ商事

(74)【代理人】

【識別番号】100111567

【弁理士】

【氏名又は名称】坂本 寛

(72)【発明者】

【氏名】春名 幸雄

(72)【発明者】

【氏名】竹内 仁

(57)【要約】

【課題】トークンの受け取りを希望するユーザが、ブロックチェーンアドレスを有していない場合であっても、少ない負担で、ユーザが、ブロックチェーンにおけるトークンを受け取れるようにする。
【解決手段】本開示のサーバは、ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンが送信されるように、前記ブロックチェーンを操作する、ことを備える処理を実行するよう構成されている。
【選択図】図５

【特許請求の範囲】

【請求項1】

ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、
前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、
受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンが送信されるように、前記ブロックチェーンを操作する、
ことを備える処理を実行するよう構成されている、サーバ。

【請求項2】

前記処理は、前記トークンリクエストの送信元である前記ユーザに割り当てられた割当済ブロックチェーンアドレスの有無を判定することを更に備え、
前記受信用ブロックチェーンアドレスを前記ユーザに割り当てることは、前記ユーザに割り当てられた前記割当済ブロックチェーンアドレスが無いと判定された場合に実行される、
請求項１に記載のサーバ。

【請求項3】

前記トークンリクエストは、第１コードを含み、
前記処理は、前記トークンリクエストの有効性を、前記第１コードを用いて判定することを更に備え、
前記受信用ブロックチェーンアドレスを前記ユーザに割り当てることは、前記トークンリクエストが有効であると判定された場合に実行される、
請求項１に記載のサーバ。

【請求項4】

前記トークンリクエストは、第１コードを含み、
前記処理は、
前記トークンリクエストの有効性を、前記第１コードを用いて判定し、
前記トークンリクエストの送信元である前記ユーザに割り当てられた割当済ブロックチェーンアドレスの有無を判定する、
ことを更に備え、
前記受信用ブロックチェーンアドレスを前記ユーザに割り当てることは、前記トークンリクエストが有効であると判定され、かつ、前記ユーザに割り当てられた前記割当済ブロックチェーンアドレスが無いと判定された場合に実行される、
請求項１に記載のサーバ。

【請求項5】

前記受信用ブロックチェーンアドレスを前記ユーザに割り当てることは、前記受信用ブロックチェーンアドレスを、前記サーバにおける前記ユーザのアカウントに割り当てることを含む、
請求項１から請求項４のいずれか１項に記載のサーバ。

【請求項6】

前記受信用ブロックチェーンアドレスを前記ユーザに割り当てることは、
前記サーバにおける前記ユーザのアカウントを生成し、
前記受信用ブロックチェーンアドレスを、生成された前記アカウントに割り当てる、
ことを含む、
請求項１から請求項４のいずれか１項に記載のサーバ。

【請求項7】

前記受信用ブロックチェーンアドレスを前記ユーザに割り当てることは、
予め発行された複数の割当候補ブロックチェーンアドレスから、前記ユーザに割り当てられる割当用ブロックチェーンアドレスを選択し、
前記割当用ブロックチェーンアドレスを、前記受信用ブロックチェーンアドレスとして、前記ユーザに割り当てる、
ことを含む、
請求項１から請求項６のいずれか１項に記載のサーバ。

【請求項8】

前記ブロックチェーンを操作することは、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンが送信されるように、前記トークンを送信するよう構成されたスマートコントラクトを呼び出すことを含む、
請求項１から請求項７のいずれか１項に記載のサーバ。

【請求項9】

前記ブロックチェーンを操作することは、
第２コードを生成し、
前記第２コードを前記スマートコントラクトへ送信する、
ことを更に含み、
前記第２コードは、前記スマートコントラクトが、
送信すべきトークンを識別するため、
送信すべきトークンのタイプを識別するため、又は
送信のために生成すべきトークンのタイプを識別するため、に用いられる、
請求項８に記載のサーバ。

【請求項10】

ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、
前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、
受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンを送信する、
ことを備える処理を実行するよう構成されている、トークン配布システム。

【請求項11】

前記処理は、前記トークンリクエストを受信した後に、前記受信用ブロックチェーンアドレスへ送信するための前記トークンを生成することを更に備える、
請求項１０に記載のトークン配布システム。

【請求項12】

前記処理は、前記トークンリクエストを受信した後に、生成される前記トークンのタイプを決定することを更に備える、
請求項１１に記載のトークン配布システム。

【請求項13】

前記タイプは、ランダムに決定される
請求項１２に記載のトークン配布システム。

【請求項14】

トークン配布のため、コンピュータが実行するコンピュータ実装方法であって、
ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、
前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、
受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンを送信する、
ことを備える、コンピュータ実装方法。

【請求項15】

前記トークンリクエストを受信した後に、前記受信用ブロックチェーンアドレスへ送信するための前記トークンを生成することを更に備える、
請求項１４に記載のコンピュータ実装方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、サーバ、トークン配布システム、及びコンピュータ実装方法に関する。

【背景技術】

【0002】

特許文献１は、ブロックチェーンにおけるノンファンジブルトークンを、ユーザへ送信することを開示している。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２１－０８９６４０号公報

【発明の概要】

【0004】

ブロックチェーンにおいて送信されたトークンをユーザが受信するには、そのユーザは、ブロックチェーンアドレスを有している必要がある。ユーザがブロックチェーンアドレスを有していない場合、そのユーザへのトークン送信はできない。

【0005】

企業又は団体等が、キャンペーン等のために、ノンファンジブルトークン等のブロックチェーンにおけるトークンを、企業の顧客等のユーザへ広く配布したい場合がある。しかし、そのユーザが、ブロックチェーンアドレスを有していなければ、ユーザは、トークンを受け取ることができない。

【0006】

トークンを受け取るために、ブロックチェーンアドレスを取得する手続負担をユーザに課すと、トークンを広く配布することが困難になる。このため、例えば、トークンを広く配布することがキャンペーンの目的である場合、そのキャンペーンの目的が達成できなくなる。

【0007】

したがって、トークンの受け取りを希望するユーザが、ブロックチェーンアドレスを有していない場合であっても、少ない負担で、ユーザが、ブロックチェーンにおけるトークンを受け取れるようにすることが望まれる。

【0008】

本開示のある側面は、サーバである。開示のサーバは、ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンが送信されるように、前記ブロックチェーンを操作する、ことを備える処理を実行するよう構成されている。

【0009】

本開示の他の側面は、トークン配布システムである。開示のトークン配布システムは、ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンを送信する、ことを備える処理を実行するよう構成されている。

【0010】

本開示の他の側面は、コンピュータ実装方法である。開示の方法は、トークン配布のため、コンピュータが実行するコンピュータ実装方法であって、ブロックチェーンにおけるトークン送信を要求するトークンリクエストを、ユーザのクライアント端末から受信し、前記トークンリクエストを受信すると、前記トークンリクエストに応じて送信されるトークンを受信するための受信用ブロックチェーンアドレスを前記ユーザに割り当て、受信した前記トークンリクエストに応じて、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンを送信する、ことを備える。

【0011】

更なる詳細は、後述の実施形態として説明される。

【図面の簡単な説明】

【0012】

【図1】図１は、システムの構成図である。

【図2】図２は、サーバの構成図である。

【図3】図３は、ブロックチェーンのスマートコントラクト及びブロックチェーンアドレスを示す図である。

【図4】図４は、トークンの配布手順を示す図である。

【図5】図５は、トークン配布処理のフローチャートである。

【図6】図６は、ブロックチェーンアドレスの割り当てを示す概要図である。

【図7】図７は、第１送信処理のフローチャートである。

【図8】図８は、第１送信処理の概要図である。

【図9】図９は、第２送信処理のフローチャートである。

【発明を実施するための形態】

【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】

実施形態においては、一例として、トークンコード（例えば、qC2oFsNKrHimID6u）は、トークンコードを含むユニフォームリソースアイデンティファイア１２０（ＵＲＩ）を表す二次元コード６０の形式で、有形媒体１０１に印刷によって付される。ＵＲＩ１２０は、スキームと、オーソリティと、を備える。ここでのＵＲＩは、一例として、ユニフォームリソースロケータ（ＵＲＬ）である。スキームは、例えば、https:である。オーソリティは、スキームに後続して記述され、資源の場所などを示す。なお、ＵＲＩ１２０は、スキームを含んでいなくてもよい。なお、図１の有形媒体１０１は、人が読み取れる形式でトークコード（qC2oFsNKrHimID6u）を表したコード表示部１０１Ｂを備えている。

【0039】

実施形態において、オーソリティは、例えば、図１に示すＵＲＩ１２０のように、ＵＲＩ本体１２３Ａと、トークンコード１２３Ｃと、を備え得る。ＵＲＩ本体１２３Ａは、例えば、ホストを含む。ホストは、サーバ５１の名前（ドメイン名）を示す。トークンコード１２３Ｃは、例えば、ＵＲＩ本体１２３Ａに後続して記述されたパス（path）であり得る。なお、ＵＲＩ本体１２３Ａもパスを含んでもよい。図１に示すオーソリティおいて、ＵＲＩ本体１２３Ａは、一例として、「ａａａ．．．．ｃｏｍ」であり、トークンコード１２３Ｃは、一例として「ｑＣ2ｏＦｓＮＫｒＨｉｍＩＤ６ｕ」である。なお、クライアント端末３１が、ＵＲＩ本体１２３Ａを予め把握している場合には、二次元コード６０は、ＵＲＩ本体１２３Ａを含まず、トークンコード及びその他必要なデータだけを含んでもよい。

【0040】

クライアント端末３１は、例えば、クライアント端末３１が備えるカメラ（図示省略）によって、二次元コード６０を読み取ることで、ＵＲＩ１２０を取得する。すなわち、クライアント端末３１は、二次元コード６０を読み取ることで、トークンコード１２３Ｃを取得する。なお、クライアント端末３１によるトークンコードの取得は、人が読み取り可能に有形媒体１０１に付されたトークンコード１２３Ｃを、ユーザが、手動操作でクライアント端末３１へ入力することによって行われてもよい。クライアント端末３１は、ネットワーク１５又はその他の通信手段を介して、他の装置から、デジタルデータとしてトークンコード１２３Ｃを取得してもよい。

【0041】

トークン配布に利用されるブロックチェーン２０は、複数のコンピュータが相互に接続されたＰ２Ｐ（ピアーツーピア；Ｐｅｅｒ ｔｏ Ｐｅｅｒ）のコンピュータネットワークシステムによって構成されている。

【0042】

ブロックチェーン２０においては、ブロックチェーンアドレス間で取引が可能である。図３では、第１ブロックチェーンアドレス２５Ａ、第２ブロックチェーンアドレス２５Ｂ、及び第３ブロックチェーンアドレス２５Ｃが例示されている。一例として、第１ブロックチェーンアドレス２５Ａは、０ｘ１１１１１で表され、第２ブロックチェーンアドレス２５Ｂは、０ｘ３３３３３で表され、第３ブロックチェーンアドレス２５Ｃは、０ｘ５５５５５で表される。ブロックチェーンアドレス２５Ａ，２５Ｂ，２５Ｃは、例えば、ブロックチェーン２０におけるユーザアカウントを示す。ブロックチェーンアドレス２５Ａ，２５Ｂ，２５Ｃ及びブロックチェーン２０における取引のトランザクションは、ブロックチェーン２０の分散台帳に記録される。

【0043】

ブロックチェーン２０おいては、例えば、トークンの取引が可能である。ブロックチェーン２０において取引可能なトークンとしては、ファンジブルトークン（代替性トークン；Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ：ＦＴ）と、ノンファンジブルトークン（非代替性トークン；Ｎｏｎ-Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ：ＮＦＴ）と、がある。ファンジブルトークンは、例えば、イーサリアム（Ｅｔｈｅｒｅｕｍ）におけるイーサ（Ｅｔｈｅｒ）などの暗号通貨である。ファンジブルトークンは、企業又は個人によってブロックチェーンにおいて発行される独自ファンジブルトークンであってもよい。

【0044】

ノンファンジブルトークン（ＮＦＴ）は、ファンジブルトークン（ＦＴ）とは異なり、代替性を有さないトークンである。非代替性の確保のため、ＮＦＴは、ブロックチェーン２０において、他のＮＦＴとの区別を可能にするための固有の識別子を有する。以下では、この識別子をＮＦＴ識別子という。

【0045】

実施形態に係るシステム１０は、ＮＦＴを配布してもよいし、ＦＴを配布してもよいし、ＮＦＴ及びＦＴの両方を配布してもよい。

【0046】

ブロックチェーン２０において、ユーザ所有するＮＦＴ又はＦＴは、ユーザが有するブロックチェーンアドレス２５Ａ，２５Ｂ，２５Ｃに対応付けて記録される。

【0047】

ブロックチェーン２０は、スマートコントラクト２２を備える。スマートコントラクト２２は、実施形態に係るシステム１０を構成し得る。スマートコントラクト２２は、ブロックチェーンにおいて実行可能に実装されたソフトウェア（コンピュータプログラム）によって構成されている。スマートコントラクト２２は、自動取引等の所定のプロトコルを自動的に実行する。

【0048】

スマートコントラクト２２は、トークン配布のため、サーバ５１と協働し得る。以下では、一例として、トークンの配布のために、ユーザから送信されたトークンリクエストを受信したサーバ５１が、スマートコントラクト２２を呼び出し、呼び出されたスマートコントラクト２２が、トークンをユーザへ送信する。

【0049】

前述のブロックチェーンアドレスは、スマートコントラクト２２のコントラクトアドレスを示すこともある。コントラクトアドレスは、スマートコントラクト２２が格納されているブロックチェーンアドレスである。

【0050】

ブロックチェーン２０においては、スマートコントラクト２２もＮＦＴ又はＦＴを所有できる。ブロックチェーン２０において、ユーザへの配布のためにスマートコントラクト２２が所有するＮＦＴ又はＦＴは、スマートコントラクト２２のコントラクトアドレスに対応付けて記録される。

【0051】

スマートコントラクト２２によって実行される処理は、例えば、トークンの操作である。トークンの操作は、例えば、トークンの所有者変更である。トークンの所有者変更の操作は、トークンの送信とも呼ばれる。すなわち、トークンの所有者を第１ブロックチェーンアドレス２５Ａから第２ブロックチェーンアドレス２５Ｂに変更することは、第１ブロックチェーンアドレス２５Ａから第２ブロックチェーンアドレス２５Ｂへトークンを送信することもでもある。

【0052】

トークンの送信は、例えば、スマートコントラクト２２のコントラクトアドレスから、他のブロックチェーンアドレス２５Ａ，２５Ｂ，２５Ｃへトークンを送信することであり得る。つまり、ユーザへのトークンの配布元は、スマートコントラクト２２であり得る。なお、ユーザへのトークンの配布元は、システム１０の管理者のブロックチェーンアドレスであってもよい。

【0053】

スマートコントラクト２２は、例えば、スマートコントラクト２２外からの呼び出し操作によって呼び出されることで、スマートコントラクト２２における処理２３，２４が実行される。スマートコントラクト２２は、例えば、システム１０の管理者のブロックチェーンアドレス又はユーザのブロックチェーンアドレス２５Ａ，２５Ｂ，２５Ｃから呼び出される。スマートコントラクト２２によって実行される処理２３，２４は、図３に示す第１送信処理２３又は第２送信処理２４を含み得る。なお、第１送信処理２３及び第２送信処理２４は、少なくともいずれか一方が実行されば足りる。

【0054】

図４は、クライアント端末３１におけるトークン取得のための大まかな手順の一例を示している。まず、企業のトークン配布キャンペーン等のため、トークンコードが多数のユーザへ配布される。トークンコードの配布方法の例は、前述のとおりであり、特に限定されない。各ユーザが取得するトークンコードは、それぞれ異なるユニークコードあり得る。

【0055】

ユーザのクライアント端末３１は、配布されたトークンコードを取得する（ステップＳ４１）。トークンコードは、例えば、トークンコードを含むＵＲＩ１２０の形式で取得される。ＵＲＩ１２０は、トークン配布システム１０へのアクセスに用いられる。クライアント端末３１は、例えば、クライアント端末にインストールされたウェブブラウザアプリケーションプログラム又はシステム１０へのアクセスのための専用アプリケーションプログラムを利用して、ＵＲＩ１２０へアクセスする。アクセスは、例えば、システム１０のサーバ５１によって受け付けられる。このアクセスによって、システム１０は、ユーザが取得したトークンコードを受信し得る。

【0056】

アクセスを受け付けたシステム１０は、クライアント端末３１のディスプレイに表示される第１画面表示３１Ａを、クライアント端末３１に提供する（ステップＳ４２）。第１画面表示３１Ａは、例えば、サーバ５１によって提供され得る。第１画面表示３１Ａは、例えば、ユーザが取得したトークンコードの表示３０１を有し得る。第１画面表示３１Ａは、トークンを取得するかどうかのユーザの意思確認のための操作部３０２を有し得る。操作部３０２は、例えば、グラフィカルユーザインターフェースとしてのボタン又はアイコンである。意思確認は、ユーザにブロックチェーンアドレスを割り当てることの意思確認でもあり得る。

【0057】

トークンコードを利用したトークンの受け取りを希望するユーザによって、操作部３０２が操作されると、クライアント端末３１から、トークン配布システム１０へ、第１トークンリクエストＲ１が送信される（ステップＳ４３）。第１トークンリクエストＲ１には、前述のトークンコードが対応付けられている。第１トークンリクエストＲ１に対応付けられたトークンコードは、第１トークンリクエストＲ１とともに送信されてもよいし、第１トークンリクエストＲ１よりも前又は後に送信されてもよい。第１トークンリクエストＲ１は、例えば、サーバ５１によって受信される。

【0058】

トークン配布システム１０は、第１トークンリクエストＲ１を送信したユーザのブロックチェーンアドレスへ、ＮＦＴ等のトークンを送信する。システム１０は、ユーザが受信したトークンをクライアント端末３１のディスプレイに表示させる第２画面表示３１Ｂを、クライアント端末３１に提供する（ステップＳ４４）。第２画面表示３１Ｂは、例えば、サーバ５１によって提供される。ユーザは、第２画面表示３１Ｂを参照することで、取得したトークンを閲覧することができる。ユーザは、取得したトークンを、他者へ譲渡、販売することができる。取得したトークンは、他のトークンとの交換に利用されてもよい。

【0059】

第２画面表示３１Ｂは、例えば、ユーザが有するＮＦＴの一覧の表示、及びユーザが有するＦＴの数量の表示の少なくともいずれか一方又は両方を有し得る。図４の第２画面表示３１Ｂは、ユーザが有するＮＦＴ一覧を示している。図４では、一例として、ブロックチェーンにおけるＮＦＴ識別子としてNft_id01を有し、シリアル番号012345を有するＮＦＴ５０１が示されている。

【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】

ステップＳ７１の決定は、スマートコントラクト２２が所有するＮＦＴの中からランダムに行われてもよいし、所定の規則に基づいて行われてもよいし、サーバ５１から送信された第２コードに基づいて決定されてもよい。サーバ５１は、必要に応じて、スマートコントラクト２２へ第２コードを送信することができる（ステップＳ７０）。第２コードは、スマートコントラクト２２が、送信すべきＮＦＴを識別するための情報を示す。例えば、第２コードは、送信すべきＮＦＴのＮＦＴ識別子（例えば、Nft_id01）、スマートコントラクト２２が送信すべきＮＦＴのＮＦＴ識別子を識別し得るその他のデータ（識別子）、又は、送信すべきＮＦＴのタイプを示すデータ、である。

【0087】

図８は、スマートコントラクト２２が第２コードを受信する例を示している。第２コードは、サーバ５１が、例えば、スマートコントラクト２２を呼び出す際に、サーバ５１からスマートコントラクト２２へ送信される（ステップＳ８１）。サーバ５１は、第２コードの送信に先立って、スマートコントラクト２２へ送信すべき第２コードを決定する。例えば、サーバ５１は、第１トークンリクエストＲ１を受信すると、第２コードを決定する。

【0088】

第２コードは、トークンコード（第１コード）に基づいて決定されてもよいし、トークンコード（第１コード）とは無関係に決定されてもよい。第２コードが第１コードに基づいて決定される場合、ユーザに送信されるトークンは、ユーザに配布された第１コードによって決定されることになる。第２コードを第１コードに基づいて決定するには、例えば、サーバ５１が、第１コードと第２コードとが対応付けられたテーブルを有しておき、そのテーブルを参照することで、サーバ５１が受信した第１コードから第２コードを求めればよい。また、第２コードは、第１コードと同じでもよい。

【0089】

第２コードが第１コードとは無関係に決定される場合、第１コードは専ら第１トークンリクエストＲ１の有効性に用いられる。第１コードに基づいて第１トークンリクエストＲ１が有効であると判定された場合、サーバ５１が、独自に第２コードを決定することができる。

【0090】

第２コードがＮＦＴ識別子である場合、サーバ５１は、スマートコントラクト２２が有するＮＦＴのＮＦＴ識別子を有するＮＦＴリスト５１Ｇ（図２参照）を参照し、第２コードとなるＮＦＴ識別子を決定することができる。サーバ５１は、ＮＦＴリストに含まれるＮＦＴ識別子のうち、ＮＦＴが未送信であるものを適宜選択する。選択されるＮＦＴ識別子は、１つでもよいし、複数でもよい。ここでのＮＦＴ識別子は、ブロックチェーン２０におけるＮＦＴ識別子（例えば、Nft_id01）であってもよいし、スマートコントラクト２２が、ブロックチェーン２０におけるＮＦＴ識別子（例えば、Nft_id01）を識別するためのその他の識別子であってもよい。

【0091】

第２コードがＮＦＴのタイプを示すデータである場合、サーバ５１は、ＮＦＴのタイプの一覧を示すＮＦＴタイプリスト５１Ｈ（図２参照）を参照し、第２コードとなるＮＦＴタイプを決定することができる。サーバ５１は、ＮＦＴのタイプをランダム又は所定の規則に従って決定できる。サーバ５１は、第１コードに基づいて、第２コードとなるＮＦＴタイプを決定してもよい。

【0092】

ここで、「タイプ」とは、トークンの種類をいう。ＦＴのタイプは、ＦＴの名称によって区別され得る。ＮＦＴのタイプは、２以上のＮＦＴが共通して有する性質によって区別され得る。例えば、２以上のＮＦＴが同じ画像を共通して有している場合、それらのＮＦＴは同じタイプになり得る。「タイプ」は、スマートコントラクト２２によって識別され得るものであれば、特に限定されない。スマートコントラクト２２は、例えば、ＮＦＴタイプを示す第２コードを受信すると、第２コードが示すＮＦＴタイプを有するＮＦＴを、送信すべきＮＦＴとして決定することができる。

【0093】

図２に示すＮＦＴタイプリスト５１Ｈでは、一例として、「ＴｙｐｅＡ」、「ＴｙｐｅＢ」、「ＴｙｐｅＣ」の３つが格納されている。例えば、ＴｙｐｅＡは、あるスポーツ選手Ｐ１の画像を持つＮＦＴのタイプである。ＴｙｐｅＢは、他のスポーツ選手Ｐ２の画像を持つＮＦＴのタイプである。ＴｙｐｅＣは、さらに他のスポーツ選手Ｐ３の画像を持つＮＦＴのタイプである。なお、同一の画像を持つなどの同一タイプのＮＦＴは、そのＮＦＴに付されたシリアル番号（図４参照）によって、区別され得る。

【0094】

第２コードを受信したスマートコントラクト２２は、第２コードに基づいて決定されたＮＦＴを、指定された送信先である第１ブロックチェーンアドレス２５Ａへ送信する（ステップＳ８２）。なお、スマートコントラクト２２への第２コードの送信は、スマートコントラクト２２へ、トークン送信を要求するトークンリクエストともいえる。したがって、第２コードの送信は、第２トークンリクエストの送信ともいえる。

【0095】

第２コードがＮＦＴ識別子である場合、スマートコントラクト２２は、送信すべきＮＦＴをＮＦＴ識別子に基づいて一意に決定できる。第２コードがＮＦＴタイプである場合、スマートコントラクト２２は、第２コードが示すＮＦＴタイプを有する複数のＮＦＴの中から、適宜選択した１又は複数のＮＦＴを、送信すべきＮＦＴとして決定することができる。なお、送信すべきトークンが、ＦＴである場合、スマートコントラクト２２は、第２コードに応じて、送信すべきＦＴの数量を決定してもよい。

【0096】

図９は、トークン送信のための第２送信処理２４（図３参照）を示している。第１送信処理２３では、予め発行されたＮＦＴが送信されるが、第２送信処理２４では、送信の必要が生じてからＮＦＴが生成させ、生成されたＮＦＴが送信される。第１送信処理２３では、送信に備えて、多数のＮＦＴを在庫として、システム１０が予め保有している必要がある。在庫としてのＮＦＴを保有する場合、在庫管理が煩雑となる。例えば、在庫となるＮＦＴが少ないと在庫切れのおそれがある。逆に、在庫切れを回避しようとすると、システム１０の管理者は、予め膨大な数のＮＦＴを予め生成しておいて、スマートコントラクト２２等に格納しておく必要がある。システムに在庫となるＮＦＴを多く保有させる場合、システム１０の管理者は、膨大な数のＮＦＴを予め生成する作業負担を負うことになる。これに対して、第２送信処理２４では、トークンリクエストを受けてからＮＦＴが生成されるため、トークンリクエストを受信する前の時点においては、ＮＦＴを非保有でよい。すなわち、システム１０は、送信すべきＮＦＴの在庫を保有する必要がない。

【0097】

システム１０が、複数のタイプのＮＦＴを配布・提供するよう構成されている場合、ＮＦＴのタイプ毎に多数のＮＦＴを予め準備する必要が生じる。しかし、第２送信処理２４では、第２コードによって、生成すべきＮＦＴのタイプが識別されるため、適切なタイプのＮＦＴを生成して、送信することができる。したがって、ＮＦＴのタイプ毎に多数のＮＦＴを予め準備する必要がない。

【0098】

図９に示す第２送信処理２４では、スマートコントラクト２２は、ＮＦＴのタイプを示す第２コードを受信すると、第２コードが示すタイプのＮＦＴを生成し（ステップＳ９１）、生成したＮＦＴを指定された送信先へ送信する（ステップＳ９２）。なお、ＮＦＴの生成は、外部の装置（例えば、サーバ５１又は他のサーバ）によって行われてもよい。スマートコントラクト２２は、外部の装置にＮＦＴの生成を委ね、外部の装置によって生成されたＮＦＴを送信してもよい。

【0099】

サーバ５１は、スマートコントラクト２２へ第２コードを送信するため、送信すべき第２コードを決定する（ステップＳ９２）。サーバ５１は、ＮＦＴのタイプの一覧を示すＮＦＴタイプリスト５１Ｈ（図２参照）を参照し、第２コードとなる１又は複数のＮＦＴタイプを決定することができる。サーバ５１は、ＮＦＴタイプリスト５１Ｈの中から、ＮＦＴタイプをランダム又は所定の規則に従って決定できる。サーバ５１は、第１コードに基づいて、第２コードとなるＮＦＴタイプを決定してもよい。

【0100】

スマートコントラクト２２は、第２コードを受信すると、受信した第２コードに基づいて、生成すべきＮＦＴタイプを識別する。ＮＦＴの生成のため、タイプ毎に、ＮＦＴ化されるデータが予め用意されている。ＮＦＴ化されるデータは、例えば、画像データである。ＮＦＴの生成は、第２コードに基づいて識別されたタイプに対応するデータを、ＮＦＴ化することによって行われる。同じタイプ又は同じデータを有するＮＦＴを区別するため、ＮＦＴには、シリアル番号（図４参照）が付与され得る。

【0101】

ＮＦＴ化のために、一つのタイプに対応するデータは、１つでもよいが、複数であるのが好ましい。例えば、ある一人のスポーツ選手Ｐ１が一つのタイプである場合、そのスポーツ選手の複数の異なる画像データが用意されているのが好ましい。この場合、受信した第２コードに基づいて、生成すべきＮＦＴタイプがスポーツ選手Ｐ１であると識別されると、更に、そのスポーツ選手Ｐ１の複数の異なる画像データの中から、ＮＦＴ化される画像データが決定される。ＮＦＴ化される画像データの決定は、ランダムに行われてもよいし、所定のルールに基づいて行われてもよい。また、第２コードは、生成すべきＮＦＴタイプ及びＮＦＴ化される画像データの両方を示してもよく、この場合、ＮＦＴ化される画像データは、第２コードに基づいて決定される。

【0102】

本発明は、上記実施形態に限定されるものではなく、様々な変形が可能である。

【0103】

＜３．付記＞
本開示は、以下の事項も含む。

【0104】

［項１］
トークンリクエストを、ユーザのクライアント端末から受信し、
前記トークンリクエストを受信すると、前記ユーザに割り当てられた前記受信用ブロックチェーンアドレスへ前記トークンを送信する、
ことを備える処理を実行するよう構成されている、トークン配布システム又はその方法。

【0105】

前記の項１によれば、トーク配布システムは、送信すべきノンファンジブルトークンを予め在庫として保有する必要がない。

【0106】

［項２］
トークンリクエストを、ユーザのクライアント端末から受信し、
前記トークンリクエストの有効性を判定し、前記トークンリクエストが有効であると判定されると、ノンファンジブルトークンを生成し、
生成した前記ノンファンジブルトークンを、前記ユーザのブロックチェーンアドレスへ送信する
ことを備える処理を実行するよう構成されている、トークン配布システム又はその方法。

【0107】

前記の項２によれば、有効なトークンリクエストを受信すると、ノンファンジブルトークンが生成され、送信される。

【0108】

［項３］
コードを、ユーザのクライアント端末から受信し、
前記コードの有効性を判定し、前記コードが有効であると判定されると、ノンファンジブルトークンを生成し、
生成した前記ノンファンジブルトークンを、前記ユーザのブロックチェーンアドレスへ送信する
ことを備える処理を実行するよう構成されている、トークン配布システム又はその方法。

【0109】

前記の項３によれば、有効なコードを受信すると、ノンファンジブルトークンが生成され、送信される。

【0110】

［項４］
既存ユーザアカウントに対して、ブロックチェーンアドレスを割り当てるためのユーザ操作を、ユーザのクライアント端末から受け付け、
前記ユーザ操作を受け付けると、ブロックチェーンアドレスを、前記既存ユーザアカウントに割り当てる
ことを備える処理を実行するよう構成されているトークン配布システム又はその方法。

【0111】

前記の項４によれば、既存ユーザアカウントにブロックチェーンアドレスを割り当てることができる。

【符号の説明】

【0112】

１０ ：トークン配布システム
１５ ：ネットワーク
２０ ：ブロックチェーン
２２ ：スマートコントラクト
２３ ：第１送信処理
２４ ：第２送信処理
２５Ａ ：第１ブロックチェーンアドレス
２５Ｂ ：第２ブロックチェーンアドレス
２５Ｃ ：第３ブロックチェーンアドレス
３１ ：クライアント端末
３１Ａ ：第１画面表示
３１Ｂ ：第２画面表示
５１ ：トークンリクエスト受付サーバ
５１Ａ ：プロセッサ
５１Ｂ ：記憶装置
５１Ｃ ：コンピュータプログラム
５１Ｄ ：判定条件
５１Ｅ ：コードリスト
５１Ｆ ：ブロックチェーンアドレスリスト
５１Ｇ ：ＮＦＴリスト
５１Ｈ ：ＮＦＴタイプリスト
５１Ｋ ：トークン配布処理
６０ ：二次元コード
１０１ ：有形媒体
１０１Ｂ ：コード表示部
１２０ ：ユニフォームリソースアイデンティファイア
１２０ ：ＵＲＩ
１２３Ａ ：ＵＲＩ本体
１２３Ｃ ：トークンコード
３０１ ：表示
３０２ ：操作部
５００ ：ユーザアカウント
５０１ ：ＮＦＴ
５０２ ：ＮＦＴ
５０３ ：ＮＦＴ
Ｒ１ ：第１トークンリクエスト

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】