▶ ＳＵＳＨＩ ＴＯＰ ＭＡＲＫＥＴＩＮＧ株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2023-12-18
(45)【発行日】2023-12-26
(54)【発明の名称】トークン制御システム
(51)【国際特許分類】
H04L 9/32 20060101AFI20231219BHJP
G06F 21/10 20130101ALN20231219BHJP
【ＦＩ】
H04L9/32 200Z
G06F21/10
【請求項の数】
13
(21)【出願番号】P 2023567095
(86)(22)【出願日】2023-03-01
(86)【国際出願番号】 JP2023007679
【審査請求日】2023-10-31
(31)【優先権主張番号】P 2022032138
(32)【優先日】2022-03-02
(33)【優先権主張国・地域又は機関】JP
【権利譲渡・実施許諾】特許権者において、実施許諾の用意がある。
【早期審査対象出願】
(73)【特許権者】
【識別番号】522077328
【氏名又は名称】ＳＵＳＨＩ ＴＯＰ ＭＡＲＫＥＴＩＮＧ株式会社
(74)【代理人】
【識別番号】110002871
【氏名又は名称】弁理士法人坂本国際特許商標事務所
(72)【発明者】
【氏名】徳永 大輔
(72)【発明者】
【氏名】大塚 大輔
(72)【発明者】
【氏名】▲高▼橋 信行
(72)【発明者】
【氏名】鈴木 貴之
【審査官】吉田 歩
(56)【参考文献】
【文献】国際公開第２０２１／１１１６５３（ＷＯ，Ａ１）
【文献】特表２０２２－５１４４６６（ＪＰ，Ａ）
【文献】特開２０２０－１２７１０９（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ９／３２
Ｇ０６Ｆ ２１／１０
(57)【特許請求の範囲】
【請求項1】
複数の計算機で構成されるブロックチェーンネットワーク上で流通するトークンを制御するシステムであって、
前記トークンを管理し処理するトークン処理部と、
利用者端末からの指示によって前記トークン処理部にトークン制御情報を通知するとともに、前記トークン処理部からの結果を利用者端末に送信するトークン制御処理受付部と、
前記利用者端末に情報を配信する配信手段と、を有し、
前記配信手段は、前記利用者端末に配信する前記トークン制御情報の一部に乱数または所定のルールで設定された情報を設定し、
前記利用者端末は、前記トークン制御情報を、前記トークン制御処理受付部を介してまたは介さずに前記トークン処理部に通知し、
前記トークン制御処理受付部または前記トークン処理部は、前記利用者端末から受け取った前記トークン制御情報を、該トークン制御情報を送信した前記利用者端末に関する利用者情報と共に格納し、
前記トークン処理部は、前記配信手段によって前記トークン制御情報に設定された前記乱数または前記ルールで設定された情報を参照して、前記乱数または前記ルールで設定された情報を該トークン処理部が管理するトークンの特定情報として利用し、
前記トークン処理部は、前記トークン制御情報に格納された前記乱数または前記ルールによって設定された情報を加工することで該情報を一定の範囲に収める加工処理部を有し、
前記加工処理部は、前記乱数または所定のルールによって設定された情報を加工した第１の加工情報が前記トークン制御情報に格納された既存の情報と同じ情報であった場合、前記第１の加工情報をさらに加工して第２の加工情報にすることで、前記トークン制御情報を一定の範囲内に収めるとともに、前記第１の加工情報または前記第２の加工情報を、前記トークン処理部が管理するトークンを特定するための情報として利用し、前記特定されたトークンに対して制御を実施することを特徴とするトークン制御システム。
【請求項2】
前記トークン処理部は、前記加工処理部において情報を一定の範囲に収めると共に、該範囲をさらに分割して重みづけし、前記加工処理部において既存の情報と同じ情報になった場合において、前記加工処理部において前記分割して重みづけした範囲に収まるように再加工し、前記分割して重みづけした範囲に収まった情報をトークンを特定するための情報として利用し、特定されたトークンに対して制御を実施することを特徴とする請求項１に記載のトークン制御システム。
【請求項3】
前記トークン処理部は、前記加工処理部において情報を一定の範囲に収める際に、前記トークン制御情報に格納される付加情報を踏まえて情報を加工することを特徴とする請求項１に記載のトークン制御システム。
【請求項4】
前記トークン処理部は、前記加工処理部において、前記配信手段に応じて割り当て範囲および割り当て数を制御することを特徴とする請求項１に記載のトークン制御システム。
【請求項5】
前記トークン制御処理受付部または前記トークン処理部は、前記利用者端末が前記トークン制御情報を送信する際に、送信された日時および／または前記配信手段の組み合わせに応じて処理の受付可否、前記加工処理部の加工処理方法、前記範囲の分割範囲の重みづけを変更した上で、前記特定されたトークンに対して制御を実施することを特徴とする請求項２から請求項４のうちのいずれか１項に記載のトークン制御システム。
【請求項6】
前記加工処理部は、情報を一定の範囲に収める際に、前記トークン制御処理受付部、または前記トークン処理部が前記ブロックチェーンネットワーク上で稼働する乱数生成機能を呼び出して乱数を生成し、前記乱数または所定のルールで設定された情報と前記乱数を組み合わせて第３の加工情報を生成し、前記第３の加工情報を該加工処理部の入力として利用することを特徴とする請求項１に記載のトークン制御システム。
【請求項7】
複数の計算機で構成されるブロックチェーンネットワーク上で流通するトークンを制御するシステムであって、
前記トークンを管理し処理するトークン処理部と、
利用者端末からの指示によって前記トークン処理部にトークン制御情報を通知するとともに、前記トークン処理部からの結果を利用者端末に送信するトークン制御処理受付部と、
前記利用者端末に情報を配信する配信手段と、を有し、
前記配信手段は、前記利用者端末に配信する前記トークン制御情報の一部に乱数または所定のルールで設定された情報を設定し、
前記利用者端末は、前記トークン制御情報を、前記トークン制御処理受付部を介してまたは介さずに前記トークン処理部に通知し、
前記トークン制御処理受付部または前記トークン処理部は、前記利用者端末から受け取った前記トークン制御情報を、該トークン制御情報を送信した前記利用者端末に関する利用者情報と共に格納し、
前記トークン処理部は、前記配信手段によって前記トークン制御情報に設定された前記乱数または前記ルールで設定された情報を参照して、前記乱数または前記ルールで設定された情報を該トークン処理部が管理するトークンの特定情報として利用し、
前記配信手段は、前記トークン制御情報のうち、前記トークン処理部が利用する情報を暗号化して情報を作成し、前記トークン制御処理受付部または前記トークン処理部は復号用暗号鍵を保持し、前記復号用暗号鍵を使って復号して利用し、前記トークン処理部が復号する場合は公開鍵ペアの公開鍵を前記トークン処理部に登録することを特徴とするトークン制御システム。
【請求項8】
前記利用者端末は、前記トークン制御情報を前記トークン制御処理受付部または前記トークン処理部に送信する際に、前記利用者端末のみが利用することができる記憶部に前記ブロックチェーンネットワークで利用者を一意に特定するために必要な情報を自動で生成し、または前記記憶部に前記一意に特定する情報が格納されている場合はその情報を読み出し、前記生成した一意に特定する情報を設定した上で前記トークン制御情報を送信することを特徴とする請求項１に記載のトークン制御システム。
【請求項9】
前記利用者端末は、前記生成した一意に特定する情報を生成した時に、前記一意に生成した一意に特定する情報を復元するための情報を生成するとともに、利用者に提示して保管を指示する通知を行うことを特徴とする請求項８に記載のトークン制御システム。
【請求項10】
複数の計算機で構成されるブロックチェーンネットワーク上で流通するトークンを制御するシステムであって、
前記トークンを管理し処理するトークン処理部と、
利用者端末からの指示によって前記トークン処理部にトークン制御情報を通知するとともに、前記トークン処理部からの結果を利用者端末に送信するトークン制御処理受付部と、
前記利用者端末に情報を配信する配信手段と、を有し、
前記配信手段は、前記利用者端末に配信する前記トークン制御情報の一部に乱数または所定のルールで設定された情報を設定し、
前記利用者端末は、前記トークン制御情報を、前記トークン制御処理受付部を介してまたは介さずに前記トークン処理部に通知し、
前記トークン制御処理受付部または前記トークン処理部は、前記利用者端末から受け取った前記トークン制御情報を、該トークン制御情報を送信した前記利用者端末に関する利用者情報と共に格納し、
前記トークン処理部は、前記配信手段によって前記トークン制御情報に設定された前記乱数または前記ルールで設定された情報を参照して、前記乱数または前記ルールで設定された情報を該トークン処理部が管理するトークンの特定情報として利用し、
前記利用者端末は、前記トークン制御情報を前記トークン制御処理受付部または前記トークン処理部に送信する際に、前記利用者端末のみが利用することができる記憶部に前記ブロックチェーンネットワークで利用者を一意に特定するために必要な情報を自動で生成し、または前記記憶部に前記一意に特定する情報が格納されている場合はその情報を読み出し、前記生成した一意に特定する情報を設定した上で前記トークン制御情報を送信し、前記利用者端末は、前記生成した一意に特定する情報を生成した時に、前記一意に生成した一意に特定する情報を復元するための情報を生成するとともに、利用者に提示して保管を指示する通知を行うことを特徴とするトークン制御システム。
【請求項11】
前記利用者端末は、利用者が恒常的に利用する前記ブロックチェーンネットワークにおいて一意に特定する情報を入手した際に、前記利用者端末だけが利用することができる記憶部で管理している前記生成した一意に特定する情報を読み出し、前記トークン処理部で管理されている利用者に利用権限があるトークンを前記生成した一意に特定する情報から、前記恒常的に利用する一意に特定する情報に利用者情報の更新を指示するためのUIを提供し、前記UIの指示に応じて前記利用者情報を更新することを特徴とする請求項８から請求項１０のうちのいずれか１項に記載のトークン制御システム。
【請求項12】
複数の計算機で構成されるブロックチェーンネットワーク上で流通するトークンを制御するシステムであって、
前記トークンを管理し処理するトークン処理部と、
利用者端末からの指示によって前記トークン処理部にトークン制御情報を通知するとともに、前記トークン処理部からの結果を利用者端末に送信するトークン制御処理受付部と、
前記利用者端末に情報を配信する配信手段と、を有し、
前記配信手段は、前記利用者端末に配信する前記トークン制御情報の一部に乱数または所定のルールで設定された情報を設定し、
前記利用者端末は、前記トークン制御情報を、前記トークン制御処理受付部を介してまたは介さずに前記トークン処理部に通知し、
前記トークン制御処理受付部または前記トークン処理部は、前記利用者端末から受け取った前記トークン制御情報を、該トークン制御情報を送信した前記利用者端末に関する利用者情報と共に格納し、
前記トークン処理部は、前記配信手段によって前記トークン制御情報に設定された前記乱数または前記ルールで設定された情報を参照して、前記乱数または前記ルールで設定された情報を該トークン処理部が管理するトークンの特定情報として利用し、
前記利用者端末は、前記トークン制御情報を前記トークン制御処理受付部または前記トークン処理部に送信する際に、前記利用者端末のみが利用することができる記憶部に前記ブロックチェーンネットワークで利用者を一意に特定するために必要な情報を自動で生成し、または前記記憶部に前記一意に特定する情報が格納されている場合はその情報を読み出し、前記生成した一意に特定する情報を設定した上で前記トークン制御情報を送信し、
前記利用者端末は、前記ブロックチェーンネットワークに対する処理要求を前記利用者端末で保持する秘密鍵で署名し、前記トークン制御処理受付部に代理処理を依頼し、前記トークン制御処理受付部は前記ブロックチェーンネットワークに処理要求する際に必要となる手数料を利用者に代わって負担し、前記ブロックチェーンネットワークに処理を依頼することを特徴とするトークン制御システム。
【請求項13】
前記利用者端末は、前記トークン制御処理受付部が代理処理を実施する際に、前記トークン制御処理受付部に格納された前記トークン制御情報を参照し、前記トークン制御情報の内容に応じて代理処理の実施可否の判断、または代理処理実施時において追加処理すべき作業を確定したうえで前記ブロックチェーンネットワークに処理を依頼し、追加処理も含めて代理処理を実行または代理処理を実行しないことを特徴とする請求項１２に記載のトークン制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はブロックチェーン上で管理するトークンの発行方法及び制御方法に関する。
【背景技術】
【0002】
電子的かつ中央集権的な仕組みを持たずに価値を表現・移転させることができるビットコインが登場し、これを実現しているブロックチェーン技術が広く広まっている。ビットコインの概念やブロックチェーン技術の理解が進むと共にビットコイン以外に電子的に価値を表現する様々なコインが登場している。これらの価値を持つコインのことを、以下ではトークンと呼ぶ。ブロックチェーン技術の特徴から、発行されたトークンは改ざんすることが非常に困難という特徴を持つ。この特徴を活かし、画像、動画、音声などの様々な電子データの保有者をブロックチェーンに記録して保有者であることを保証・証明するという使い方が広まっている。このような用途で利用されるトークンをNon-Fungible Token(NFT)と呼ぶ。NFTのコンセプト自体は古くからあるが、2017年頃から少しずつ認知され始め、2021年には高額で取引されるものも出てきたこともあり、注目されている。NFTの具体的な利用方法として、無形資産の管理(特許文献1)や契約・ライセンス管理(特許文献2)などが検討されている。従来、権利保有者が中央管理していたシステムからブロックチェーンを活用した分散システムにすることで耐障害性を高めると共に、中央管理者が業務を遂行できなくなっても、問題なく記録済みの情報が利用できるという特徴を提供することができる。
【先行技術文献】
【特許文献】
【0003】
【文献】特許第6640320号
【文献】特開2020-68388号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
現時点ではNFTという技術自体が新しいものであり、その作成には専門家の知見が必要であると共に、利用者もブロックチェーンにおける取引方法を理解しないとNFTを入手すること自体が難しいという課題がある。
また、既存の仕組みでは開発済み、管理・運用済みの各種情報をトークンと紐づけることが前提になっている。サービスや販売方法によってはトークンを事前に生成して割り当てるといった利用方法も考えられるが、これらのシステムでは対応できない。
そこで本発明では、一般の利用者が簡単にNFTを受け取ることができる仕組みを用意する。具体的には、利用者が保有するスマートフォンやPCなどでQRコード、NFC、Bluetoothなどの様々な配信手段から情報を受け取り、その情報を元にNFTを発行または提供する。なお、これらの配信手段には事前にNFT受領に関する情報を設定する必要があるが、この作業はそれぞれの配信手段に応じて実施する必要がある。さらに、NFTが参照するコンテンツなどの情報が確定しないと配信手段に設定すべき情報を確定できないという問題も発生しうる。本発明では、配信手段に対する設定する作業をNFT側の開発作業と独立して進められるよう、乱数または事前に定義したルールで生成した識別子を利用する。
また、既存の仕組みでは開発済み、管理・運用済みの各種情報をトークンと紐づけることが前提になっている。サービスや販売方法によってはトークンを事前に生成して割り当てるといった利用方法も考えられるが、これらのシステムでは対応できない。
そこで本発明では、一般の利用者が簡単にNFTを受け取ることができる仕組みを用意する。具体的には、利用者が保有するスマートフォンやPCなどでQRコード、NFC、Bluetoothなどの様々な配信手段から情報を受け取り、その情報を元にNFTを発行または提供する。なお、これらの配信手段には事前にNFT受領に関する情報を設定する必要があるが、この作業はそれぞれの配信手段に応じて実施する必要がある。さらに、NFTが参照するコンテンツなどの情報が確定しないと配信手段に設定すべき情報を確定できないという問題も発生しうる。本発明では、配信手段に対する設定する作業をNFT側の開発作業と独立して進められるよう、乱数または事前に定義したルールで生成した識別子を利用する。
【課題を解決するための手段】
【0005】
開示の一態様は、複数の計算機で構成されるブロックチェーンネットワーク上で流通するトークンを制御するシステムであって、前記トークンを管理し処理するトークン処理部と、利用者端末からの指示によって前記トークン処理部にトークン制御情報を通知するとともに、前記トークン処理部からの結果を前記利用者端末に送信するトークン制御処理受付部と、前記利用者端末に情報を配信する配信手段と、を有し、前記配信手段は、前記利用者端末に配信する前記トークン制御情報の一部に乱数または所定のルールで設定された情報を設定し、前記利用者端末は、前記トークン制御情報を、前記トークン制御処理受付部を介してまたは介さずに前記トークン処理部に通知し、前記トークン制御処理受付部または前記トークン処理部は、利用者端末から受け取った前記トークン制御情報を、該トークン制御情報を送信した前記利用者端末に関する利用者情報と共に格納し、前記トークン処理部は、前記配信手段によって前記トークン制御情報に設定された前記乱数または前記ルールで設定された情報を参照して、前記乱数または前記ルールで設定された情報を該トークン処理部が管理するトークンの特定情報として利用することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記トークン制御情報に格納された前記乱数または前記ルールによって設定された情報を加工することで該情報を一定の範囲に収める情報加工処理部を有し、前記加工処理部は、前記乱数または所定のルールによって設定された情報を加工した第１の加工情報が前記トークン制御情報に格納された既存の情報と同じ情報であった場合、前記第１の加工情報をさらに加工して第２の加工情報にすることで、前記トークン制御情報を一定の範囲内に収めるとともに、前記第１の加工情報または前記第２の加工情報を、前記トークン処理部が管理するトークンを特定するための情報として利用し、前記特定されたトークンに対して制御を実施することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記加工処理部において情報を一定の範囲に収めると共に、該範囲をさらに分割して重みづけし、前記加工処理部において既存の情報と同じ情報になった場合において、前記加工処理部において前記分割して重みづけした範囲に収まるように再加工し、前記分割して重みづけした範囲に収まった情報をトークンを特定するための情報として利用し、特定されたトークンに対して制御を実施することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記加工処理部において情報を一定の範囲に収める際に、前記トークン制御情報に格納される付加情報を踏まえて情報を加工することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記加工処理部において、前記配信手段に応じて割り当て範囲および割り当て数を制御することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン制御処理部または前記トークン処理部は、前記利用者端末が前記トークン制御情報を送信する際に、送信された日時および／または前記配信手段の組み合わせに応じて処理の受付可否、前記加工処理部の加工処理方法、前記範囲の分割範囲の重みづけを変更した上で、前記特定されたトークンに対して制御を実施することを特徴とするトークン制御システムである。
開示の一態様として、前記情報加工処理部は、情報を一定の範囲に収める際に、前記トークン処理受付部、または前記トークン処理部が前記ブロックチェーンネットワーク上で稼働する乱数生成機能を呼び出して乱数を生成し、前記乱数または所定のルールで設定された情報と前記乱数を組み合わせて第３の加工情報を生成し、前記第３の加工情報を該情報加工処理部の入力として利用することを特徴とするトークン制御システムである。
開示の一態様として、前記配信手段は、前記トークン制御情報のうち、前記トークン処理部が利用する情報を暗号化して情報を作成し、前記トークン制御処理受付部または前記トークン処理部は復号用暗号鍵を保持し、前記復号用暗号鍵を使って復号して利用し、前記トークン処理部が復号する場合は公開鍵ペアの公開鍵を前記トークン処理部に登録することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記トークン制御情報を前記トークン制御処理受付部または前記トークン処理部に送信する際に、前記利用者端末のみが利用することができる記憶部に前記ブロックチェーンネットワークで利用者を一意に特定するために必要な情報を自動で生成し、または前記記憶部に前記一意に特定する情報が格納されている場合はその情報を読み出し、前記生成した一意に特定する情報を設定した上で前記トークン制御情報を送信することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記生成した一意に特定する情報を生成した時に、前記一意に生成した一意に特定する情報を復元するための情報を生成するとともに、利用者に提示して保管を指示する通知を行うことを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、利用者が恒常的に利用する前記ブロックチェーンネットワークにおいて一意に特定する情報を入手した際に、前記利用者端末だけが利用することができる記憶部で管理している前記生成した一意に特定する情報を読み出し、前記トークン処理部で管理されている利用者に利用権限があるトークンを前記生成した一意に特定する情報から、前記恒常的に利用する一意に特定する情報に利用者情報の更新を指示するためのUIを提供し、前記UIの指示に応じて前記利用者情報を更新することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記ブロックチェーンネットワークに対する処理要求を前記利用者端末で保持する秘密鍵で署名し、前記トークン制御処理受付部に代理処理を依頼し、前記トークン制御処理受付部は前記ブロックチェーンネットワークに処理要求する際に必要となる手数料を利用者に代わって負担し、前記ブロックチェーンネットワークに処理を依頼することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記トークン制御処理受付部が代理処理を実施する際に、前記トークン制御情報処理受付部に格納された前記トークン制御情報を参照し、前記トークン制御情報の内容に応じて代理処理の実施可否の判断、または代理処理実施時において追加処理すべき作業を確定したうえで前記ブロックチェーンネットワークに処理を依頼し、追加処理も含めて代理処理を実行または代理処理を実行しないことを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記トークン制御情報に格納された前記乱数または前記ルールによって設定された情報を加工することで該情報を一定の範囲に収める情報加工処理部を有し、前記加工処理部は、前記乱数または所定のルールによって設定された情報を加工した第１の加工情報が前記トークン制御情報に格納された既存の情報と同じ情報であった場合、前記第１の加工情報をさらに加工して第２の加工情報にすることで、前記トークン制御情報を一定の範囲内に収めるとともに、前記第１の加工情報または前記第２の加工情報を、前記トークン処理部が管理するトークンを特定するための情報として利用し、前記特定されたトークンに対して制御を実施することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記加工処理部において情報を一定の範囲に収めると共に、該範囲をさらに分割して重みづけし、前記加工処理部において既存の情報と同じ情報になった場合において、前記加工処理部において前記分割して重みづけした範囲に収まるように再加工し、前記分割して重みづけした範囲に収まった情報をトークンを特定するための情報として利用し、特定されたトークンに対して制御を実施することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記加工処理部において情報を一定の範囲に収める際に、前記トークン制御情報に格納される付加情報を踏まえて情報を加工することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン処理部は、前記加工処理部において、前記配信手段に応じて割り当て範囲および割り当て数を制御することを特徴とするトークン制御システムである。
開示の一態様として、前記トークン制御処理部または前記トークン処理部は、前記利用者端末が前記トークン制御情報を送信する際に、送信された日時および／または前記配信手段の組み合わせに応じて処理の受付可否、前記加工処理部の加工処理方法、前記範囲の分割範囲の重みづけを変更した上で、前記特定されたトークンに対して制御を実施することを特徴とするトークン制御システムである。
開示の一態様として、前記情報加工処理部は、情報を一定の範囲に収める際に、前記トークン処理受付部、または前記トークン処理部が前記ブロックチェーンネットワーク上で稼働する乱数生成機能を呼び出して乱数を生成し、前記乱数または所定のルールで設定された情報と前記乱数を組み合わせて第３の加工情報を生成し、前記第３の加工情報を該情報加工処理部の入力として利用することを特徴とするトークン制御システムである。
開示の一態様として、前記配信手段は、前記トークン制御情報のうち、前記トークン処理部が利用する情報を暗号化して情報を作成し、前記トークン制御処理受付部または前記トークン処理部は復号用暗号鍵を保持し、前記復号用暗号鍵を使って復号して利用し、前記トークン処理部が復号する場合は公開鍵ペアの公開鍵を前記トークン処理部に登録することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記トークン制御情報を前記トークン制御処理受付部または前記トークン処理部に送信する際に、前記利用者端末のみが利用することができる記憶部に前記ブロックチェーンネットワークで利用者を一意に特定するために必要な情報を自動で生成し、または前記記憶部に前記一意に特定する情報が格納されている場合はその情報を読み出し、前記生成した一意に特定する情報を設定した上で前記トークン制御情報を送信することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記生成した一意に特定する情報を生成した時に、前記一意に生成した一意に特定する情報を復元するための情報を生成するとともに、利用者に提示して保管を指示する通知を行うことを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、利用者が恒常的に利用する前記ブロックチェーンネットワークにおいて一意に特定する情報を入手した際に、前記利用者端末だけが利用することができる記憶部で管理している前記生成した一意に特定する情報を読み出し、前記トークン処理部で管理されている利用者に利用権限があるトークンを前記生成した一意に特定する情報から、前記恒常的に利用する一意に特定する情報に利用者情報の更新を指示するためのUIを提供し、前記UIの指示に応じて前記利用者情報を更新することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記ブロックチェーンネットワークに対する処理要求を前記利用者端末で保持する秘密鍵で署名し、前記トークン制御処理受付部に代理処理を依頼し、前記トークン制御処理受付部は前記ブロックチェーンネットワークに処理要求する際に必要となる手数料を利用者に代わって負担し、前記ブロックチェーンネットワークに処理を依頼することを特徴とするトークン制御システムである。
開示の一態様として、前記利用者端末は、前記トークン制御処理受付部が代理処理を実施する際に、前記トークン制御情報処理受付部に格納された前記トークン制御情報を参照し、前記トークン制御情報の内容に応じて代理処理の実施可否の判断、または代理処理実施時において追加処理すべき作業を確定したうえで前記ブロックチェーンネットワークに処理を依頼し、追加処理も含めて代理処理を実行または代理処理を実行しないことを特徴とするトークン制御システムである。
【発明の効果】
【0006】
本発明により、ブロックチェーンに不慣れな者であっても「QRコードを読むだけ」といったように多くの方が知っている方法でNFTを受け取ることができる。また、配信手段向けのデータ提供を開発と独立して実施できるため、NFT提供までに必要な期間を短縮することが可能になる。
【図面の簡単な説明】
【0007】
【発明を実施するための形態】
【0008】
以下、図面を用いて本発明の実施形態を説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。ただし、図面は模式的なものである。
【実施例1】
【0009】
図１は実施形態を実現するシステムの全体構成図である。ブロックチェーンネットワーク100は多数のコンピュータがお互いに接続されたネットワークであり、接続されている各コンピュータをノードと呼ぶ。各ノードは外部からブロックチェーンネットワーク100に通知された処理依頼を記録すると共に、利用者からの処理依頼に応じた処理を実行し、その結果をノードが管理しているストレージに記録する。処理依頼は各ノードに伝達され、それぞれのノードがその処理依頼に対して同じ処理を実行して出力を記録することにより、分散環境下においても各ノードが全く同じ情報を保持することを実現する。このブロックチェーン上で実行する処理のことをスマートコントラクトと言う。
スマートコントラクトは各ノードで実行されるコンピュータプログラムであり、処理依頼と同様、ブロックチェーンネットワーク100がプログラムの登録依頼を受けた後、それを各ノードに配布して登録する。トークン処理部200はスマートコントラクトであり、利用者からのリクエストに応じてトークンを制御する。本実施形態ではトークンの発行を例として説明する。
トークン制御処理受付部300はブロックチェーンネットワーク100とのやりとりを実施するサーバであり、利用者端末400からの要求を受けてトークン処理部200に依頼をし、その応答を利用者端末400に返す。利用者端末400は利用者が利用する情報処理装置であり、スマートフォンやPCなどがこれにあたる。配信手段A～配信手段C(500A～500C)は利用者に対してトークンに関する情報を提供するものである。具体的には、QRコード、NFC、Bluetooth、音声、画像など利用者端末と連携して各種データを提供するものである。なお、利用者がブロックチェーンネットワーク100と直接やり取りする場合、利用者の端末にはウォレットと呼ばれるブロックチェーンで利用する秘密鍵を管理するソフトウェアやハードウェアが利用される。利用者端末400にこれらがインストール済みであれば、トークン制御処理受付部300を介さずに直接利用者端末400からトークン処理部200に処理依頼を投げてもよい。本実施形態においては、多くの利用者がウォレットを保持していないことを想定し、トークン制御処理受付部300を使う例で説明する。
図２はブロックチェーンネットワーク100を構築する各ノードの構成図である。ノード端末110は通常のコンピュータであり、CPU120、メモリ130、ストレージ140、ストレージを接続するためのインタフェースであるストレージI/F 150、外部のキーボードやマウス、ディスプレイと接続するための入出力I/F 160、外部のコンピュータと接続してネットワークを構築するためのネットワークI/F 170で構成される。図示していないが、その他の演算処理部としてGPUやFPGAを持つものもあり、これらの機能部にマイニングなどのブロックチェーン運用に必要な処理をオフロードしているものもある。ノード端末110のストレージ140にブロックチェーンネットワークの情報が格納され、スマートコントラクトの処理はストレージ140からメモリ130に読みだされてCPU 120(場合によってはGPUやFPGA)で実行される。なお、トークン制御処理受付部300、利用者端末400も通常のコンピュータであり、ノード端末110と同様の構成である。
利用者にNFTなどのトークンを配信する際には、事前にトークンを作成する、またはリクエストに応じてトークンを作成する仕組みを準備する必要がある。その準備部分と実際に利用者がトークンを受け取るまでの処理を示したものが図３である。以下「NFTを新規に配布する」ものとして、この処理手順について説明する。
まず、NFTを配布するにあたり、NFTを管理・運用するためのスマートコントラクトを開発する必要がある(ステップS1000)。開発したものにバグなどがないことが確認できたら、ブロックチェーンネットワーク100に作成したスマートコントラクトを登録する(ステップS1010。ブロックチェーンネットワーク100、スマートコントラクトはこのフローに図示していない)。これと並行してNFTとして参照するコンテンツを作成し、スマートコントラクトに登録すべき情報を用意する(ステップS1020)。スマートコントラクトとコンテンツが準備できたら、その情報をスマートコントラクトに設定し、開発作業としては終了になる(ステップS1030)。なお、本実施形態ではスマートコントラクトをブロックチェーンネットワーク100に登録した後でコンテンツ情報を登録する形で説明したが、スマートコントラクト登録後にコンテンツ情報を設定するのではなく、全ての情報を用意してスマートコントラクトとしてコンテンツ情報も確定した上で登録する、という手順で進める場合もありうる。
本実施形態において特徴的なのは、スマートコントラクトやコンテンツの開発・作成と並行して配信手段の準備ができるところである。これを実現するのが設定情報生成処理(ステップS1100)である。ここでは、設定情報として十分な範囲を持った乱数を利用する。例えば、2の256乗の範囲の数値を乱数で割り振る、などである。設定できる空間が広ければ広いほど生成した乱数が一致する可能性は低くなる。配信手段によっては、印刷や専用デバイスにデータ書き込みなどの作業が必要になる。QRコードなどの配信手段で提供する情報とNFTで管理するID情報を1対1に対応させようとすると、NFT側の開発完了を待つ必要があるが、アクセスすべきサイトのURLなど一定の準備やルールが確定できれば、その後は乱数を使って自由に配信手段を生成することができる。こうして開発と独立で作業を進めることできるとともに、配信手段側の作業も機械的に実施することができる。または、乱数ではなく各配信手段に対して利用する数値範囲を割り当てて通番を振るというルールを定義してもよい。
例えば、QRコードは1から10000、NFCは10001から20000、という形で全て一意となるように番号を割り当てる。こうして生成した情報を配信手段に設定し(ステップS1110)、利用者に配布する(ステップS1120)。開発と配布を分離できることにより、事前販売も実現することができ、他の製品とのコラボレーションなどもやりやすくなる。配信手段から利用者端末に提供される情報が図４のトークン制御情報600である。ここでは、制御情報としてNFTの発行または配布で利用する乱数または事前定義した通番が設定され、付加情報としてNFT取得用のアクセス先URLなどが格納されることを想定している。付加情報はアクセス先URL以外ものが含まれてもよい。例えば、配信手段の種類や管理番号、販売開始日時、提供会社のURLなどである。
こうして、たとえば配信手段として印刷されたQRコードを利用者が受け取り、これをスマートフォンなどで読み込んでアクセス先の情報とNFT引き換え用として設定された乱数を取得する(ステップS1200)。次に利用者は取得したアクセス先に読み込んだ乱数を通知して、NFTの取得を要求する(ステップS1210)。なお、利用者がアクセス先に情報を通知する際は、利用者がNFTを受け取るための情報(パブリックブロックチェーンの場合、利用者のアドレスが相当する。以降、この情報をアドレスとして説明する。)なども送信する。
本実施形態ではアクセス先としてトークン制御処理受付部300が設定されるため、ここが利用者からのリクエストを受け付ける(ステップS1300)。図５はトークン制御処理受付部が受信した情報を格納する受信データ格納部700である。なお、送信者欄にはブロックチェーンネットワーク100で利用者のアドレスが格納されるが、必要であれば利用者のIPアドレスなどを格納して確実に個人または個人の利用者端末400を特定する情報を格納してもよい。また、トークン制御情報の付加情報の全体または一部が不要であればこれらを削除した上で受信データ格納部700のトークン制御情報欄に格納してもよい。
トークン制御処理受付部300は受信データの格納時に同じトークン制御情報を持つものがないかを確認し、既に登録済みであった場合はその配信手段の内容が利用済みであったことを利用者に伝え、処理を終了する。あるいは、「一人3個まで」というように同じ利用者が複数個持つことを許容する場合は、その数を超えていないかどうかをチェックして超えていれば処理を終了する。一利用者あたりの上限数のチェックはトークン制御処理受付部300でなく、スマートコントラクトでチェックしても構わない。チェックを実施して問題がなければそのまま受け取った情報を格納し、受信した情報を使ってNFTの発行または設定をスマートコントラクトに依頼する(ステップS1310。スマートコントラクトはこのフローに図示していない)。発行または設定のリクエストを受け取ったスマートコントラクトは、通知に不備がないことを確認した上で対象のNFTの保有者を利用者に変更する。または新規にNFTを発行して保有者を利用者に設定する。なお、NFTを管理・運用するスマートコントラクトはNFTのIDと保有者の情報を保持している。これがトークン管理情報800である。一番シンプルなやり方は、通知された乱数や通番をそのままIDとして設定し、そのIDに通知された利用者のアドレスを関連付けてトークン管理情報800に格納する方法である。スマートコントラクトの実装上の制約からとりうるIDの上限値はあるが、乱数や通番を割り当てる際にそのことを考慮して送信情報に設定する情報を定義すれば、この制約は回避できる。また、多くの場合、NFTは100個、10000個などの上限を設けている。この場合に対応する一例として、受け取った乱数の剰余を求めて対応する方法がある。例えば配布するNFTが100個なのであれば、受け取った乱数を100で割って、その余りをIDとして利用する。剰余を使うことで、どのような値が通知されても、一定範囲に収めることができる。しかし、この場合は後から通知された乱数の剰余を算出すると、利用済みのIDと同じ値になることが考えられる。この場合、算出した値の次の値をIDにするクローズドハッシュ法を使うなどの工夫で対応することができる。通番を割り振る際に個数上限を想定済みであれば、そのままその値をIDとして使えばよい。
さらに、NFTの発行数に制約をつけて流通数を少なくして希少性を出すという取り組みも行われている。本実施形態であれば、配信手段で提供する個数を制限することで実現できる。
別の実現方法として、IDの範囲により希少性を表現する場合も考えられる。例えば100個のNFTがあるが、1から10までのNFTの価値が高い(特別なコンテンツと関連付けるなど)という場合である。これも剰余で実現できるが、クローズドハッシュ法を使ったときに「剰余は10なのにずれて11になり価値の高いNFTがもらえない」ということが発生しうる。このような場合は単純にクローズドハッシュ法を使うのではなく、剰余が1から10になったものはこの範囲でクローズドハッシュ法を使う、とすれば対応できる。
ただ、本実施形態では複数の配信手段の利用を想定しているため、ある配信手段で価値の高いNFTを大量に配布してしまう可能性がある。配信手段によっては受信できる利用者が限られる場合もありえるため、配布の公平性も担保する必要がある。それを管理するのがトークン配布数管理900である。これは利用を想定している配信手段において、どのIDをどのくらい割り当てるかを管理する情報であり、最大割り当て数と配布開始後は実際に割り当てた数を管理するために利用する。スマートコントラクトで利用者を割り当てる際に、この情報も参照して、IDを割り当てる。ある配信手段で最大数を割り当てた後に通知された送信情報の剰余がその範囲となった場合にどのIDを割り当てるかは、開発者がそのNFTのコンセプトや運用ルールなどからスマートコントラクトに実装するものとする。ここでは単純にID範囲だけを定義したが、販売を開始してから1ヶ月以内、3ヶ月以内などの時間的な制約や、総受信数に対する統計値などを使ってもよいし、これらを組み合わせたルールを作成してもよい。
本実施形態では、「いずれかの配信手段から入手した情報を使ってNFTを取得する」場合についての説明であった。実際には同じ場所でNFT配布情報がQRコードと放送音声で提供されるなど複数の配信手段が利用される場合がある。この時、複数の配信手段によるトークン配布情報を送信した場合のみNFTを配布する、複数の配信手段を利用すると特別なNFTを配布するといった応用も考えることができる。このように複数の配信手段を組み合わせることで、送信情報や付加情報に追加情報を加えることなく、場所や時間に応じたNFT配布を実現できる。また、「QRコードを持っているだけでは配布しない」といった、ある程度のセキュリティ対策にもなりうる。
また、本例は「NFTの発行」処理を想定して説明したが、発行だけでなくNFTを含めたブロックチェーンネットワーク100上のトークンに対する処理の実施をこの仕組みで実現することができる。例えば、ゲームに利用されるNFTが「ある特定の日時にある場所に行けばパラメータが向上する」など、現実世界とNFT情報とを連携させるサービスを構築する際にも活用できる。
本実施形態では、利用者がトークン制御処理受付部300経由でトークン処理部200に処理を依頼する構成を例として説明しているが、利用者端末400にウォレットが搭載されるのが当たり前になった場合、利用者は直接トークン処理部200にトークン制御処理600を通知して処理を依頼する形になることが多いと考えられる。この場合、トークン制御処理受付部300にて管理している受信データ格納部700はスマートコントラクトであるトークン処理部200で管理することで本実施形態を実現できる。
スマートコントラクトは各ノードで実行されるコンピュータプログラムであり、処理依頼と同様、ブロックチェーンネットワーク100がプログラムの登録依頼を受けた後、それを各ノードに配布して登録する。トークン処理部200はスマートコントラクトであり、利用者からのリクエストに応じてトークンを制御する。本実施形態ではトークンの発行を例として説明する。
トークン制御処理受付部300はブロックチェーンネットワーク100とのやりとりを実施するサーバであり、利用者端末400からの要求を受けてトークン処理部200に依頼をし、その応答を利用者端末400に返す。利用者端末400は利用者が利用する情報処理装置であり、スマートフォンやPCなどがこれにあたる。配信手段A～配信手段C(500A～500C)は利用者に対してトークンに関する情報を提供するものである。具体的には、QRコード、NFC、Bluetooth、音声、画像など利用者端末と連携して各種データを提供するものである。なお、利用者がブロックチェーンネットワーク100と直接やり取りする場合、利用者の端末にはウォレットと呼ばれるブロックチェーンで利用する秘密鍵を管理するソフトウェアやハードウェアが利用される。利用者端末400にこれらがインストール済みであれば、トークン制御処理受付部300を介さずに直接利用者端末400からトークン処理部200に処理依頼を投げてもよい。本実施形態においては、多くの利用者がウォレットを保持していないことを想定し、トークン制御処理受付部300を使う例で説明する。
図２はブロックチェーンネットワーク100を構築する各ノードの構成図である。ノード端末110は通常のコンピュータであり、CPU120、メモリ130、ストレージ140、ストレージを接続するためのインタフェースであるストレージI/F 150、外部のキーボードやマウス、ディスプレイと接続するための入出力I/F 160、外部のコンピュータと接続してネットワークを構築するためのネットワークI/F 170で構成される。図示していないが、その他の演算処理部としてGPUやFPGAを持つものもあり、これらの機能部にマイニングなどのブロックチェーン運用に必要な処理をオフロードしているものもある。ノード端末110のストレージ140にブロックチェーンネットワークの情報が格納され、スマートコントラクトの処理はストレージ140からメモリ130に読みだされてCPU 120(場合によってはGPUやFPGA)で実行される。なお、トークン制御処理受付部300、利用者端末400も通常のコンピュータであり、ノード端末110と同様の構成である。
利用者にNFTなどのトークンを配信する際には、事前にトークンを作成する、またはリクエストに応じてトークンを作成する仕組みを準備する必要がある。その準備部分と実際に利用者がトークンを受け取るまでの処理を示したものが図３である。以下「NFTを新規に配布する」ものとして、この処理手順について説明する。
まず、NFTを配布するにあたり、NFTを管理・運用するためのスマートコントラクトを開発する必要がある(ステップS1000)。開発したものにバグなどがないことが確認できたら、ブロックチェーンネットワーク100に作成したスマートコントラクトを登録する(ステップS1010。ブロックチェーンネットワーク100、スマートコントラクトはこのフローに図示していない)。これと並行してNFTとして参照するコンテンツを作成し、スマートコントラクトに登録すべき情報を用意する(ステップS1020)。スマートコントラクトとコンテンツが準備できたら、その情報をスマートコントラクトに設定し、開発作業としては終了になる(ステップS1030)。なお、本実施形態ではスマートコントラクトをブロックチェーンネットワーク100に登録した後でコンテンツ情報を登録する形で説明したが、スマートコントラクト登録後にコンテンツ情報を設定するのではなく、全ての情報を用意してスマートコントラクトとしてコンテンツ情報も確定した上で登録する、という手順で進める場合もありうる。
本実施形態において特徴的なのは、スマートコントラクトやコンテンツの開発・作成と並行して配信手段の準備ができるところである。これを実現するのが設定情報生成処理(ステップS1100)である。ここでは、設定情報として十分な範囲を持った乱数を利用する。例えば、2の256乗の範囲の数値を乱数で割り振る、などである。設定できる空間が広ければ広いほど生成した乱数が一致する可能性は低くなる。配信手段によっては、印刷や専用デバイスにデータ書き込みなどの作業が必要になる。QRコードなどの配信手段で提供する情報とNFTで管理するID情報を1対1に対応させようとすると、NFT側の開発完了を待つ必要があるが、アクセスすべきサイトのURLなど一定の準備やルールが確定できれば、その後は乱数を使って自由に配信手段を生成することができる。こうして開発と独立で作業を進めることできるとともに、配信手段側の作業も機械的に実施することができる。または、乱数ではなく各配信手段に対して利用する数値範囲を割り当てて通番を振るというルールを定義してもよい。
例えば、QRコードは1から10000、NFCは10001から20000、という形で全て一意となるように番号を割り当てる。こうして生成した情報を配信手段に設定し(ステップS1110)、利用者に配布する(ステップS1120)。開発と配布を分離できることにより、事前販売も実現することができ、他の製品とのコラボレーションなどもやりやすくなる。配信手段から利用者端末に提供される情報が図４のトークン制御情報600である。ここでは、制御情報としてNFTの発行または配布で利用する乱数または事前定義した通番が設定され、付加情報としてNFT取得用のアクセス先URLなどが格納されることを想定している。付加情報はアクセス先URL以外ものが含まれてもよい。例えば、配信手段の種類や管理番号、販売開始日時、提供会社のURLなどである。
こうして、たとえば配信手段として印刷されたQRコードを利用者が受け取り、これをスマートフォンなどで読み込んでアクセス先の情報とNFT引き換え用として設定された乱数を取得する(ステップS1200)。次に利用者は取得したアクセス先に読み込んだ乱数を通知して、NFTの取得を要求する(ステップS1210)。なお、利用者がアクセス先に情報を通知する際は、利用者がNFTを受け取るための情報(パブリックブロックチェーンの場合、利用者のアドレスが相当する。以降、この情報をアドレスとして説明する。)なども送信する。
本実施形態ではアクセス先としてトークン制御処理受付部300が設定されるため、ここが利用者からのリクエストを受け付ける(ステップS1300)。図５はトークン制御処理受付部が受信した情報を格納する受信データ格納部700である。なお、送信者欄にはブロックチェーンネットワーク100で利用者のアドレスが格納されるが、必要であれば利用者のIPアドレスなどを格納して確実に個人または個人の利用者端末400を特定する情報を格納してもよい。また、トークン制御情報の付加情報の全体または一部が不要であればこれらを削除した上で受信データ格納部700のトークン制御情報欄に格納してもよい。
トークン制御処理受付部300は受信データの格納時に同じトークン制御情報を持つものがないかを確認し、既に登録済みであった場合はその配信手段の内容が利用済みであったことを利用者に伝え、処理を終了する。あるいは、「一人3個まで」というように同じ利用者が複数個持つことを許容する場合は、その数を超えていないかどうかをチェックして超えていれば処理を終了する。一利用者あたりの上限数のチェックはトークン制御処理受付部300でなく、スマートコントラクトでチェックしても構わない。チェックを実施して問題がなければそのまま受け取った情報を格納し、受信した情報を使ってNFTの発行または設定をスマートコントラクトに依頼する(ステップS1310。スマートコントラクトはこのフローに図示していない)。発行または設定のリクエストを受け取ったスマートコントラクトは、通知に不備がないことを確認した上で対象のNFTの保有者を利用者に変更する。または新規にNFTを発行して保有者を利用者に設定する。なお、NFTを管理・運用するスマートコントラクトはNFTのIDと保有者の情報を保持している。これがトークン管理情報800である。一番シンプルなやり方は、通知された乱数や通番をそのままIDとして設定し、そのIDに通知された利用者のアドレスを関連付けてトークン管理情報800に格納する方法である。スマートコントラクトの実装上の制約からとりうるIDの上限値はあるが、乱数や通番を割り当てる際にそのことを考慮して送信情報に設定する情報を定義すれば、この制約は回避できる。また、多くの場合、NFTは100個、10000個などの上限を設けている。この場合に対応する一例として、受け取った乱数の剰余を求めて対応する方法がある。例えば配布するNFTが100個なのであれば、受け取った乱数を100で割って、その余りをIDとして利用する。剰余を使うことで、どのような値が通知されても、一定範囲に収めることができる。しかし、この場合は後から通知された乱数の剰余を算出すると、利用済みのIDと同じ値になることが考えられる。この場合、算出した値の次の値をIDにするクローズドハッシュ法を使うなどの工夫で対応することができる。通番を割り振る際に個数上限を想定済みであれば、そのままその値をIDとして使えばよい。
さらに、NFTの発行数に制約をつけて流通数を少なくして希少性を出すという取り組みも行われている。本実施形態であれば、配信手段で提供する個数を制限することで実現できる。
別の実現方法として、IDの範囲により希少性を表現する場合も考えられる。例えば100個のNFTがあるが、1から10までのNFTの価値が高い(特別なコンテンツと関連付けるなど)という場合である。これも剰余で実現できるが、クローズドハッシュ法を使ったときに「剰余は10なのにずれて11になり価値の高いNFTがもらえない」ということが発生しうる。このような場合は単純にクローズドハッシュ法を使うのではなく、剰余が1から10になったものはこの範囲でクローズドハッシュ法を使う、とすれば対応できる。
ただ、本実施形態では複数の配信手段の利用を想定しているため、ある配信手段で価値の高いNFTを大量に配布してしまう可能性がある。配信手段によっては受信できる利用者が限られる場合もありえるため、配布の公平性も担保する必要がある。それを管理するのがトークン配布数管理900である。これは利用を想定している配信手段において、どのIDをどのくらい割り当てるかを管理する情報であり、最大割り当て数と配布開始後は実際に割り当てた数を管理するために利用する。スマートコントラクトで利用者を割り当てる際に、この情報も参照して、IDを割り当てる。ある配信手段で最大数を割り当てた後に通知された送信情報の剰余がその範囲となった場合にどのIDを割り当てるかは、開発者がそのNFTのコンセプトや運用ルールなどからスマートコントラクトに実装するものとする。ここでは単純にID範囲だけを定義したが、販売を開始してから1ヶ月以内、3ヶ月以内などの時間的な制約や、総受信数に対する統計値などを使ってもよいし、これらを組み合わせたルールを作成してもよい。
本実施形態では、「いずれかの配信手段から入手した情報を使ってNFTを取得する」場合についての説明であった。実際には同じ場所でNFT配布情報がQRコードと放送音声で提供されるなど複数の配信手段が利用される場合がある。この時、複数の配信手段によるトークン配布情報を送信した場合のみNFTを配布する、複数の配信手段を利用すると特別なNFTを配布するといった応用も考えることができる。このように複数の配信手段を組み合わせることで、送信情報や付加情報に追加情報を加えることなく、場所や時間に応じたNFT配布を実現できる。また、「QRコードを持っているだけでは配布しない」といった、ある程度のセキュリティ対策にもなりうる。
また、本例は「NFTの発行」処理を想定して説明したが、発行だけでなくNFTを含めたブロックチェーンネットワーク100上のトークンに対する処理の実施をこの仕組みで実現することができる。例えば、ゲームに利用されるNFTが「ある特定の日時にある場所に行けばパラメータが向上する」など、現実世界とNFT情報とを連携させるサービスを構築する際にも活用できる。
本実施形態では、利用者がトークン制御処理受付部300経由でトークン処理部200に処理を依頼する構成を例として説明しているが、利用者端末400にウォレットが搭載されるのが当たり前になった場合、利用者は直接トークン処理部200にトークン制御処理600を通知して処理を依頼する形になることが多いと考えられる。この場合、トークン制御処理受付部300にて管理している受信データ格納部700はスマートコントラクトであるトークン処理部200で管理することで本実施形態を実現できる。
【0010】
［実施形態２］
実施形態１の方法により、コンテンツ作成と独立して配布用情報を作成でき、様々な配布手段で事前に利用者にNFTなどのトークンを配布することができる。しかし、個数制限や高価値のトークン配布に配布手段を単純に利用すると悪用される恐れがある。例えばQRコードを利用する場合について考えると、QRコードの情報自体は誰でも受け取ることができて、その内容を簡単に確認することができる。つまり、アクセス先のURLなどの情報とID割り当てに利用する乱数や通番を利用者が簡単に知ることができる。また、QRコード作成ツールもWebなどで公開されているため、QRコードを受け取ると利用者側でオリジナルの情報を加工した上でトークン制御処理受付部300に処理を依頼することができてしまう。このため、「利用者が望むIDを持つトークンが取得できてしまう」「配布手段から情報を入手することなくいくらでもトークンが取得できてしまう」という大きく2つの課題がある。
「任意のIDのトークンが取得可能」については、受信側で乱数を加工することで対応できる。トークン制御処理受付部300が利用者からのリクエストを受け付けた(ステップS1300)際に、乱数を生成してこれと合成(XORするなど)して新しい情報を作成し、これをID割り当ての情報として利用する。乱数生成でなく、ソルト(任意の可変情報)と通知された情報からハッシュ値を求めてそれを割り当て情報として使ってもよい。利用者から通知された情報をそのまま使わないことで、この問題は対応できる。なお、ここではトークン制御処理受付部300で乱数作成＆合成またはハッシュ値作成する例を説明したが、同様の処理をスマートコントラクトで実施してもよい。通常、スマートコントラクトでは乱数を生成することはできないが、外部から信頼できる情報を提供するオラクルという仕組みがある。これを使って乱数を取得することでスマートコントラクトでも乱数を利用することができる。トークン制御処理受付部300はトークン提供者の管理下にあることが多いため、利用者から見える場所であるブロックチェーンネットワーク100上に情報を公開して公平性を提示するためにスマートコントラクトで実装するということはありえる。
後者の「利用者が任意個のトークンを取得できてしまう」ことはより大きな問題である。一利用者が複数個を発行または設定することを許容している場合でも、送信者情報としてブロックチェーンネットワーク100のアドレス情報しか保持していない場合、利用者はアドレスを自由に複数個作成することができるため、個数制限は制約として機能できない。この問題に対する1つの方法として、配布手段からトークン制御情報を受領する際に名前や住所、メールアドレスなどの利用者情報を収集し、利用者がトークン制御情報を利用する際に利用者情報も入力してもらうという形にすればこの問題に対応はできる。しかし、QRコードやNFCなどの配信手段だけでは利用者の詳細情報を取得することが実現できず、別のシステムが必要になるため運用も手間がかかる。また、利用者にとっても手間を強いられ、人によっては不必要に個人情報を提供するように感じる方も出てくるため、トークンを受け取ってもらえないという課題が生じる。本発明ではこの問題に対応するために配信手段で伝達するトークン制御情報を暗号化して提供することで対応する。手順自体は図３と同じであるが、一部処理が追加になる。その内容について、以下説明する。
まず、トークン制御情報600に格納する制御情報を暗号化するために、暗号鍵を用意する。ここでは公開鍵暗号を使う場合について説明するが、AESなどの共通鍵暗号を使う場合でも同様である。まずトークン提供者がトークン作成を実施する前に公開鍵ペアを作成する。秘密鍵はトークン提供者が管理すると共に安全に利用できる形でトークン制御処理受付部300に設定し、公開鍵を配信手段向けに情報設定作業を行う人に提供する。配信手段では乱数または通番生成に受け取った公開鍵を使って制御情報を暗号化する(ステップS1100)。なお、トークン制御情報600の付加情報はアクセス先のURLなどの情報を格納するため、利用者が情報を取得した際に読めるよう平文のままで情報を格納する。処理上、他に秘匿したい情報があれば、その部分も暗号化して格納してもよい。また、情報生成に利用する公開鍵は配信手段にトークン制御情報600を設定するものだけが利用し、他の作業者や外部に公開してはいけない。以降の処理は図３の通りだが、ステップS1300で利用者からトークン制御情報600を受け取ったトークン制御処理受付部300は、設定された秘密鍵を使って送信情報を復号して設定された乱数などを取得して以降の処理を実施する処理が追加になる。
このようにして、トークン制御情報600における制御情報を暗号化し、利用者には暗号に必要な鍵情報を公開しない仕組みを構築する。この仕組みにより、利用者がトークン制御情報600の情報を自由に変更することを防ぐことができ、「利用者が任意個のトークンを取得できてしまう」問題を解決することができる。
上記ではトークン制御処理受付部300にて秘密鍵を管理する方法について説明した。しかし、内部犯まで考慮すると秘密鍵を持ち続けることがリスクになる可能性もある。そこで、鍵をスマートコントラクトに持たせることで管理自体を容易にする方法について説明する。
鍵もデータなのでスマートコントラクトに鍵を持たせること自体は簡単である。しかし、スマートコントラクトはブロックチェーンネットワーク100にアクセスする者全員に公開される情報であるため、そのまま鍵を持たせるわけにはいかない。そこで、公開鍵暗号を利用する。公開鍵暗号の技術的特徴から、秘密鍵から公開鍵の導出は容易だが、公開鍵から秘密鍵の導出は莫大な計算時間がかかるため、現実的に不可能という特徴がある。この特徴を活かし「公開鍵」をスマートコントラクトに登録する。トークン制御情報600の暗号化処理は先ほどと同様である。トークン提供者が公開鍵ペアを生成し、「秘密鍵」を配信手段向けに情報設定作業を行う人に提供し、生成するトークン制御情報600をこの鍵で暗号化する。なお先ほどと同様、秘密鍵が漏洩することないよう作業しなければならない。全てのトークン制御情報600が作成できれば秘密鍵は不要になるため、破棄してもよい。将来的にコンテンツ追加などで同じ秘密鍵を利用する可能性がある場合は、トークン提供者がこれを厳密に管理しておく。また、この場合はトークン制御処理受付部300で復号できないので、暗号化されたデータと送信者の情報を受信データ格納部700に格納して管理する。トークン制御処理受付部300がスマートコントラクトに発行または設定を依頼(ステップS1310)した後、これを受け取ったスマートコントラクトは自身が持つ公開鍵で通知された情報を復号して利用する。このように、通常の公開鍵ペアの持ち方と逆の持たせ方をすることで、スマートコントラクトに登録した鍵情報で復号はできても暗号化できないことが担保できる。こうして、スマートコントラクトに鍵情報を登録しても安全にトークン制御情報600を利用することができる。
実施形態１の方法により、コンテンツ作成と独立して配布用情報を作成でき、様々な配布手段で事前に利用者にNFTなどのトークンを配布することができる。しかし、個数制限や高価値のトークン配布に配布手段を単純に利用すると悪用される恐れがある。例えばQRコードを利用する場合について考えると、QRコードの情報自体は誰でも受け取ることができて、その内容を簡単に確認することができる。つまり、アクセス先のURLなどの情報とID割り当てに利用する乱数や通番を利用者が簡単に知ることができる。また、QRコード作成ツールもWebなどで公開されているため、QRコードを受け取ると利用者側でオリジナルの情報を加工した上でトークン制御処理受付部300に処理を依頼することができてしまう。このため、「利用者が望むIDを持つトークンが取得できてしまう」「配布手段から情報を入手することなくいくらでもトークンが取得できてしまう」という大きく2つの課題がある。
「任意のIDのトークンが取得可能」については、受信側で乱数を加工することで対応できる。トークン制御処理受付部300が利用者からのリクエストを受け付けた(ステップS1300)際に、乱数を生成してこれと合成(XORするなど)して新しい情報を作成し、これをID割り当ての情報として利用する。乱数生成でなく、ソルト(任意の可変情報)と通知された情報からハッシュ値を求めてそれを割り当て情報として使ってもよい。利用者から通知された情報をそのまま使わないことで、この問題は対応できる。なお、ここではトークン制御処理受付部300で乱数作成＆合成またはハッシュ値作成する例を説明したが、同様の処理をスマートコントラクトで実施してもよい。通常、スマートコントラクトでは乱数を生成することはできないが、外部から信頼できる情報を提供するオラクルという仕組みがある。これを使って乱数を取得することでスマートコントラクトでも乱数を利用することができる。トークン制御処理受付部300はトークン提供者の管理下にあることが多いため、利用者から見える場所であるブロックチェーンネットワーク100上に情報を公開して公平性を提示するためにスマートコントラクトで実装するということはありえる。
後者の「利用者が任意個のトークンを取得できてしまう」ことはより大きな問題である。一利用者が複数個を発行または設定することを許容している場合でも、送信者情報としてブロックチェーンネットワーク100のアドレス情報しか保持していない場合、利用者はアドレスを自由に複数個作成することができるため、個数制限は制約として機能できない。この問題に対する1つの方法として、配布手段からトークン制御情報を受領する際に名前や住所、メールアドレスなどの利用者情報を収集し、利用者がトークン制御情報を利用する際に利用者情報も入力してもらうという形にすればこの問題に対応はできる。しかし、QRコードやNFCなどの配信手段だけでは利用者の詳細情報を取得することが実現できず、別のシステムが必要になるため運用も手間がかかる。また、利用者にとっても手間を強いられ、人によっては不必要に個人情報を提供するように感じる方も出てくるため、トークンを受け取ってもらえないという課題が生じる。本発明ではこの問題に対応するために配信手段で伝達するトークン制御情報を暗号化して提供することで対応する。手順自体は図３と同じであるが、一部処理が追加になる。その内容について、以下説明する。
まず、トークン制御情報600に格納する制御情報を暗号化するために、暗号鍵を用意する。ここでは公開鍵暗号を使う場合について説明するが、AESなどの共通鍵暗号を使う場合でも同様である。まずトークン提供者がトークン作成を実施する前に公開鍵ペアを作成する。秘密鍵はトークン提供者が管理すると共に安全に利用できる形でトークン制御処理受付部300に設定し、公開鍵を配信手段向けに情報設定作業を行う人に提供する。配信手段では乱数または通番生成に受け取った公開鍵を使って制御情報を暗号化する(ステップS1100)。なお、トークン制御情報600の付加情報はアクセス先のURLなどの情報を格納するため、利用者が情報を取得した際に読めるよう平文のままで情報を格納する。処理上、他に秘匿したい情報があれば、その部分も暗号化して格納してもよい。また、情報生成に利用する公開鍵は配信手段にトークン制御情報600を設定するものだけが利用し、他の作業者や外部に公開してはいけない。以降の処理は図３の通りだが、ステップS1300で利用者からトークン制御情報600を受け取ったトークン制御処理受付部300は、設定された秘密鍵を使って送信情報を復号して設定された乱数などを取得して以降の処理を実施する処理が追加になる。
このようにして、トークン制御情報600における制御情報を暗号化し、利用者には暗号に必要な鍵情報を公開しない仕組みを構築する。この仕組みにより、利用者がトークン制御情報600の情報を自由に変更することを防ぐことができ、「利用者が任意個のトークンを取得できてしまう」問題を解決することができる。
上記ではトークン制御処理受付部300にて秘密鍵を管理する方法について説明した。しかし、内部犯まで考慮すると秘密鍵を持ち続けることがリスクになる可能性もある。そこで、鍵をスマートコントラクトに持たせることで管理自体を容易にする方法について説明する。
鍵もデータなのでスマートコントラクトに鍵を持たせること自体は簡単である。しかし、スマートコントラクトはブロックチェーンネットワーク100にアクセスする者全員に公開される情報であるため、そのまま鍵を持たせるわけにはいかない。そこで、公開鍵暗号を利用する。公開鍵暗号の技術的特徴から、秘密鍵から公開鍵の導出は容易だが、公開鍵から秘密鍵の導出は莫大な計算時間がかかるため、現実的に不可能という特徴がある。この特徴を活かし「公開鍵」をスマートコントラクトに登録する。トークン制御情報600の暗号化処理は先ほどと同様である。トークン提供者が公開鍵ペアを生成し、「秘密鍵」を配信手段向けに情報設定作業を行う人に提供し、生成するトークン制御情報600をこの鍵で暗号化する。なお先ほどと同様、秘密鍵が漏洩することないよう作業しなければならない。全てのトークン制御情報600が作成できれば秘密鍵は不要になるため、破棄してもよい。将来的にコンテンツ追加などで同じ秘密鍵を利用する可能性がある場合は、トークン提供者がこれを厳密に管理しておく。また、この場合はトークン制御処理受付部300で復号できないので、暗号化されたデータと送信者の情報を受信データ格納部700に格納して管理する。トークン制御処理受付部300がスマートコントラクトに発行または設定を依頼(ステップS1310)した後、これを受け取ったスマートコントラクトは自身が持つ公開鍵で通知された情報を復号して利用する。このように、通常の公開鍵ペアの持ち方と逆の持たせ方をすることで、スマートコントラクトに登録した鍵情報で復号はできても暗号化できないことが担保できる。こうして、スマートコントラクトに鍵情報を登録しても安全にトークン制御情報600を利用することができる。
【0011】
［実施形態３］
利用者がNFTなどのトークンを受け取る際には、ブロックチェーンネットワーク100で利用者を一意に特定する情報が必要になる。Ethereumなどのパブリックブロックチェーンではユーザが管理している公開鍵ペアの公開鍵から生成したアドレスがこれに相当する。しかし、アドレスを持つためにはその元となる公開鍵ペアを管理するためのウォレットなどのアプリまたはハードウェアが必要になり、一般の利用者からは利用しづらいものになる。そこで、本例ではこの問題を解決する方法について説明する。
図３のステップS1200の受け取り処理にて、利用者は配信手段から情報を取得する。具体的にQRコードの場合で説明すると、配信手段はQRコードをユーザに提供する。この提供方法は人が紙を渡すのでも、会社などの入り口にQRコードを掲示しておくのでも、インターネット経由で配信するのでも、どのような形でもよい。ユーザはスマートフォンのカメラアプリやスキャナアプリを使ってQRコードを読み取る。アプリがこれを読み取るとURLを提示してアクセスするかどうかを確認し、「アクセスする」と指示した後、スマートフォンはブラウザを立ち上げてトークン制御情報600で指定されたURL先にアクセスする。
この時に、アクセス先であるトークン制御処理受付部300が用意しているページ内のJavaScriptなどのプログラムがユーザ用のアドレス作成の元になる公開鍵ペアを生成してブラウザのローカルストレージに格納する処理を実行する。こうして利用者は自身が意識することなくブロックチェーンネットワーク100で一意であるアドレス情報を取得することができる。また、ローカルストレージはそのスマートフォンのユーザしか利用できないため、比較的安全であるといえる。
ただ、ローカルストレージはユーザ操作により削除できてしまう。公開鍵ペア(特に秘密鍵)が削除されてしまうと、利用者に付与されたトークンの移動が永久に利用できなくなってしまう。それを回避するために公開鍵ペア作成後にそれら、またはそれらの生成に利用した情報をQRコード化してユーザに表示する。ユーザは表示された画面をキャプチャするなどしてブラウザのローカルストレージ以外の場所に保存しておく。この情報があれば、利用者はアクセス時に生成された公開鍵ペアをいつでも生成でき、付与されたトークンを無駄にすることがなくなる。なお、QRコードでなく、複数の単語など、生成した公開鍵ペアを復元できるものであればどのようなものでもよい。ブラウザのローカルストレージに格納する公開鍵ペアは、受け取り用の暫定情報ともいえる。このため、利用者が恒常的に利用するアドレスを入手した後、対象のトークンと恒常利用アドレスと復元情報、または対象のトークンと恒常利用アドレスとローカルストレージに格納した秘密鍵の情報トークン制御処理受付部300に提供することで、利用者のローカルストレージに格納したアドレスから恒常利用アドレスに対象トークンを送信する機能も提供する。この機能のUIイメージが図８である。「From」はローカルストレージに格納したアドレスであるため、自動的に設定される。「To」は利用者自身に入力してもらう。「To」はQRコードなどから読み取って設定してもよい。復元情報はここでは別ファイルとして保持されているものとしている。なお、このUIで秘密鍵またはこれの復元情報を送付することになるため、利用者に対して十分に注意するよう指示する必要がある。
また、ブロックチェーンネットワーク100に処理を依頼する場合は多くのブロックチェーンではガス代と呼ばれる手数料が発生する。このガス代は各ブロックチェーンにおいて基本となるトークンを使って支払う必要があるが、一般の利用者はガス代用のトークンを確保すること自体が難しい。そこで、利用者の公開鍵ペアを使ってブロックチェーンネットワーク100向けの処理を作成するが、依頼に必要なガス代はトークン制御処理受付部300が負担する方法を提供して対応する。利用者端末400はローカルストレージに格納した公開鍵ペアの秘密鍵を使い、自身が配信手段から受け取ったトークン制御情報600に署名して確実に使う旨をトークン制御処理受付部300通知することで、ガス代負担を依頼する。トークン制御処理受付部300では送信者情報と署名から確実に送信者を確認することができ、その確認によりガス代負担を許可する。また、この代理依頼を実行できるスマートコントラクトをブロックチェーンネットワーク100に準備しておき、トークン制御処理受付部300からはそのスマートコントラクトに処理を依頼することで、代理処理を実現する。このように、ブロックチェーンネットワーク100に対する処理をトークン制御処理受付部300に代理してもらうことにより、利用者はガス代を意識せずにブロックチェーンネットワーク100に処理を依頼することができる。上記で恒常的なアドレスに保有トークンを送信する方法についても説明したが、秘密鍵情報などを提供せず代理手段でも実現できる。大きく2通りあり、一つは利用者がローカルストレージに格納した公開鍵ペアのアドレスから自身が用意した恒常利用アドレスに対象トークンを送信する処理依頼を作成し、ローカルストレージの秘密鍵で署名してその実行をトークン制御処理受付部300に依頼する。もう一つは、トークン制御処理受付部300に対象トークンを操作する権限を付与する処理依頼を作成してローカルストレージに格納した秘密鍵で署名して、その実行をトークン制御処理受付部300に依頼する。いずれの場合も、リクエストを受け取ったトークン制御処理受付部300はガス代を設定した上で代理処理を実現するスマートコントラクトに処理を依頼して処理を完了させる。なお、トークン保管場所の変更をこれらの手段で実現する場合は、図８のUIには復元用情報の項目は不要であり、2通りの方法を提示して選択してもらう、システムとして2通りのうち片方を利用するよう実装し、UI上は選択肢をなくす、といった方法が考えられる。実際に代理処理をする場合、図５の受信データ格納部を参照して、要求者が正しいかどうかを確認した上でブロックチェーンネットワーク100に代理処理を依頼する。また、受信データ格納部の情報を参照して代理実行の可否を決定してもよい。例えば、QRコードは配布数が多いのでガス代は補助しないが音声経由でNFTを取得した人は許可する、NFCで取得した人で3日以内の実施であればガス代負担と将来ガス代として利用できる少額をプレゼントし、1ヶ月以内であればガス代負担のみ、それ以上は許可しないなどの制御をしてもよい。このような制御をすることで、特定の配信手段を重みづけることができ、NFTの配布方法のバリエーションを増やすことができる。
利用者がNFTなどのトークンを受け取る際には、ブロックチェーンネットワーク100で利用者を一意に特定する情報が必要になる。Ethereumなどのパブリックブロックチェーンではユーザが管理している公開鍵ペアの公開鍵から生成したアドレスがこれに相当する。しかし、アドレスを持つためにはその元となる公開鍵ペアを管理するためのウォレットなどのアプリまたはハードウェアが必要になり、一般の利用者からは利用しづらいものになる。そこで、本例ではこの問題を解決する方法について説明する。
図３のステップS1200の受け取り処理にて、利用者は配信手段から情報を取得する。具体的にQRコードの場合で説明すると、配信手段はQRコードをユーザに提供する。この提供方法は人が紙を渡すのでも、会社などの入り口にQRコードを掲示しておくのでも、インターネット経由で配信するのでも、どのような形でもよい。ユーザはスマートフォンのカメラアプリやスキャナアプリを使ってQRコードを読み取る。アプリがこれを読み取るとURLを提示してアクセスするかどうかを確認し、「アクセスする」と指示した後、スマートフォンはブラウザを立ち上げてトークン制御情報600で指定されたURL先にアクセスする。
この時に、アクセス先であるトークン制御処理受付部300が用意しているページ内のJavaScriptなどのプログラムがユーザ用のアドレス作成の元になる公開鍵ペアを生成してブラウザのローカルストレージに格納する処理を実行する。こうして利用者は自身が意識することなくブロックチェーンネットワーク100で一意であるアドレス情報を取得することができる。また、ローカルストレージはそのスマートフォンのユーザしか利用できないため、比較的安全であるといえる。
ただ、ローカルストレージはユーザ操作により削除できてしまう。公開鍵ペア(特に秘密鍵)が削除されてしまうと、利用者に付与されたトークンの移動が永久に利用できなくなってしまう。それを回避するために公開鍵ペア作成後にそれら、またはそれらの生成に利用した情報をQRコード化してユーザに表示する。ユーザは表示された画面をキャプチャするなどしてブラウザのローカルストレージ以外の場所に保存しておく。この情報があれば、利用者はアクセス時に生成された公開鍵ペアをいつでも生成でき、付与されたトークンを無駄にすることがなくなる。なお、QRコードでなく、複数の単語など、生成した公開鍵ペアを復元できるものであればどのようなものでもよい。ブラウザのローカルストレージに格納する公開鍵ペアは、受け取り用の暫定情報ともいえる。このため、利用者が恒常的に利用するアドレスを入手した後、対象のトークンと恒常利用アドレスと復元情報、または対象のトークンと恒常利用アドレスとローカルストレージに格納した秘密鍵の情報トークン制御処理受付部300に提供することで、利用者のローカルストレージに格納したアドレスから恒常利用アドレスに対象トークンを送信する機能も提供する。この機能のUIイメージが図８である。「From」はローカルストレージに格納したアドレスであるため、自動的に設定される。「To」は利用者自身に入力してもらう。「To」はQRコードなどから読み取って設定してもよい。復元情報はここでは別ファイルとして保持されているものとしている。なお、このUIで秘密鍵またはこれの復元情報を送付することになるため、利用者に対して十分に注意するよう指示する必要がある。
また、ブロックチェーンネットワーク100に処理を依頼する場合は多くのブロックチェーンではガス代と呼ばれる手数料が発生する。このガス代は各ブロックチェーンにおいて基本となるトークンを使って支払う必要があるが、一般の利用者はガス代用のトークンを確保すること自体が難しい。そこで、利用者の公開鍵ペアを使ってブロックチェーンネットワーク100向けの処理を作成するが、依頼に必要なガス代はトークン制御処理受付部300が負担する方法を提供して対応する。利用者端末400はローカルストレージに格納した公開鍵ペアの秘密鍵を使い、自身が配信手段から受け取ったトークン制御情報600に署名して確実に使う旨をトークン制御処理受付部300通知することで、ガス代負担を依頼する。トークン制御処理受付部300では送信者情報と署名から確実に送信者を確認することができ、その確認によりガス代負担を許可する。また、この代理依頼を実行できるスマートコントラクトをブロックチェーンネットワーク100に準備しておき、トークン制御処理受付部300からはそのスマートコントラクトに処理を依頼することで、代理処理を実現する。このように、ブロックチェーンネットワーク100に対する処理をトークン制御処理受付部300に代理してもらうことにより、利用者はガス代を意識せずにブロックチェーンネットワーク100に処理を依頼することができる。上記で恒常的なアドレスに保有トークンを送信する方法についても説明したが、秘密鍵情報などを提供せず代理手段でも実現できる。大きく2通りあり、一つは利用者がローカルストレージに格納した公開鍵ペアのアドレスから自身が用意した恒常利用アドレスに対象トークンを送信する処理依頼を作成し、ローカルストレージの秘密鍵で署名してその実行をトークン制御処理受付部300に依頼する。もう一つは、トークン制御処理受付部300に対象トークンを操作する権限を付与する処理依頼を作成してローカルストレージに格納した秘密鍵で署名して、その実行をトークン制御処理受付部300に依頼する。いずれの場合も、リクエストを受け取ったトークン制御処理受付部300はガス代を設定した上で代理処理を実現するスマートコントラクトに処理を依頼して処理を完了させる。なお、トークン保管場所の変更をこれらの手段で実現する場合は、図８のUIには復元用情報の項目は不要であり、2通りの方法を提示して選択してもらう、システムとして2通りのうち片方を利用するよう実装し、UI上は選択肢をなくす、といった方法が考えられる。実際に代理処理をする場合、図５の受信データ格納部を参照して、要求者が正しいかどうかを確認した上でブロックチェーンネットワーク100に代理処理を依頼する。また、受信データ格納部の情報を参照して代理実行の可否を決定してもよい。例えば、QRコードは配布数が多いのでガス代は補助しないが音声経由でNFTを取得した人は許可する、NFCで取得した人で3日以内の実施であればガス代負担と将来ガス代として利用できる少額をプレゼントし、1ヶ月以内であればガス代負担のみ、それ以上は許可しないなどの制御をしてもよい。このような制御をすることで、特定の配信手段を重みづけることができ、NFTの配布方法のバリエーションを増やすことができる。
【0012】
［その他の実施形態］
本発明は上述した開示によって説明したが、上述した開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなる。
本発明は上述した開示によって説明したが、上述した開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなる。
【符号の説明】
【0013】
100…ブロックチェーンネットワーク、600…トークン制御情報、700…受信データ格納部、800…トークン管理情報、900…トークン配布数管理、1000…トークン保管場所変更UI
【要約】
QRコードなど、一般利用者の方が利用しやすい手段を使ってトークンの配布・制御を実現する。また、配布手段として生成する情報にはトークン開発側の情報を使わないことにより、開発と配布準備を平行で実施でき、サービス展開までに必要な時間を短くすることができる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
