知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-07-23
(45)【発行日】2024-07-31
(54)【発明の名称】プログラムおよび情報処理システム
(51)【国際特許分類】
G06Q 20/38 20120101AFI20240724BHJP
【ＦＩ】
G06Q20/38
【請求項の数】
8
(21)【出願番号】P 2023191388
(22)【出願日】2023-11-09
【審査請求日】2024-02-09
【早期審査対象出願】
(73)【特許権者】
【識別番号】509070463
【氏名又は名称】株式会社コロプラ
(74)【代理人】
【識別番号】100104547
【弁理士】
【氏名又は名称】栗林 三男
(74)【代理人】
【識別番号】100206612
【弁理士】
【氏名又は名称】新田 修博
(74)【代理人】
【識別番号】100209749
【弁理士】
【氏名又は名称】栗林 和輝
(74)【代理人】
【識別番号】100217755
【弁理士】
【氏名又は名称】三浦 淳史
(72)【発明者】
【氏名】馬場 功淳
【審査官】永野 一郎
(56)【参考文献】
【文献】特開２０１４－０７４９６８（ＪＰ，Ａ）
【文献】特開２０２２－０９３８６４（ＪＰ，Ａ）
【文献】特許第７３２２３０７（ＪＰ，Ｂ１）
【文献】国際公開第２０２１／１４４８８８（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０２３／０２３０４５６（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
(57)【特許請求の範囲】
【請求項1】
コンピュータを、仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段と、
ユーザの前記操作に基づき、前記特定の処理の実行に係る仮想通貨の支払いについてのトランザクションを生成し、ブロックチェーンのネットワークに送信するトランザクション送信手段と、として機能させ、
前記実行手段は、前記特定の処理の実行に係る仮想通貨の支払いについてのトランザクションが格納されたブロックがブロックチェーンに追加されたか確認し、追加されたことが確認された場合に、前記特定の処理を決済の完了を待たずに実行する
プログラム。
【請求項2】
前記実行手段は、前記特定の処理に求められる量の前記仮想通貨を前記ユーザが保有しているか確認し、保有していることが確認された場合に、前記特定の処理を実行する請求項１に記載のプログラム。
【請求項3】
コンピュータを、決済が完了する前に前記特定の処理が実行され、その後決済が完了しなかった場合に、完了しなかった決済についての清算を、次回の前記特定の処理の実行の際に実行する清算手段として機能させる
請求項１に記載のプログラム。
【請求項4】
前記実行手段は、前記ユーザの信用度を示すパラメータが特定の条件を満たす場合に、前記操作がされた後、決済が完了する前に前記特定の処理を実行する請求項１に記載のプログラム。
【請求項5】
コンピュータを、決済が完了する前に前記特定の処理が実行され、その後決済が完了しなかった場合に、前記特定の処理の実行により前記ユーザが享受した利益の少なくとも一部を喪失させる喪失手段として機能させる
請求項１に記載のプログラム。
【請求項6】
前記実行手段は、前記仮想世界内の特定のオブジェクトを前記ユーザに取得させる処理であって、前記仮想通貨の支払いが求められる処理を、決済が完了した後に実行する請求項１に記載のプログラム。
【請求項7】
前記特定の処理は、前記仮想世界内の特定のオブジェクトのパラメータを変化させる処理であり、
前記実行手段は、前記特定のオブジェクトを前記ユーザに取得させる処理であって、前記仮想通貨の支払いが求められる処理を、決済が完了した後に実行する
請求項１～５のいずれか１項に記載のプログラム。
【請求項8】
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段と、
ユーザの前記操作に基づき、前記特定の処理の実行に係る仮想通貨の支払いについてのトランザクションを生成し、ブロックチェーンのネットワークに送信するトランザクション送信手段と、を備え、
前記実行手段は、前記特定の処理の実行に係る仮想通貨の支払いについてのトランザクションが格納されたブロックがブロックチェーンに追加されたか確認し、追加されたことが確認された場合に、前記特定の処理を決済の完了を待たずに実行する
情報処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラムおよび情報処理システムに関する。
【背景技術】
【0002】
従来より、ブロックチェーンを利用したゲームが知られている（例えば、非特許文献１参照）。この種のゲームにおいては、ゲームを進行させるために仮想通貨が必要な場合がある。
【先行技術文献】
【非特許文献】
【0003】
【文献】“STEPN(ステップン/ステプン)の始め方・将来性を徹底解説｜稼ぎ方/やり方やレベル上げの費用は？”、［online］、［令和５年１０月４日検索］、インターネット＜https://www.caica.jp/media/crypto/stepn-about/＞
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、ブロックチェーンで管理される仮想通貨を用いた取引は、決済の完了までに時間がかかる。具体的には、ブロックチェーンにおいては、取引に係る情報がブロックに格納されるが、フォーク等の発生により、生成されたブロックが破棄されることもあるところ、仮想通貨の取引所においては、特定の取引に係る情報が格納されたブロックの後に複数のブロックが繋がると取引が確定したとみなし、決済の完了としたりする。また、そもそもブロックの生成（換言すると、マイニング）にはある程度の時間を要するため、取引に係る情報が格納されたブロックがブロックチェーンに追加されるまでにも時間がかかる。
【0005】
このため、仮想世界における事象を発生させる処理であって仮想通貨の支払いが求められる処理を、決済の完了を待ってから行うと、処理の実行に係る操作をユーザが行ってから事象が発生するまでの間に時間がかかってしまうという問題があった。そして、このように、処理の実行に係る操作をユーザが行ってから事象が発生するまでの間に時間がかかってしまうと、仮想世界に係る体験の快適度が低下してしまうおそれがあった。
【0006】
本発明は、仮想世界に係る体験についての快適度を向上させることを目的とする。
【課題を解決するための手段】
【0007】
本開示に示す一実施形態によれば、
コンピュータを、
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段として機能させる
プログラムが提供される。
コンピュータを、
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段として機能させる
プログラムが提供される。
【発明の効果】
【0008】
本発明によれば、仮想世界に係る体験についての快適度を向上させることができる。
【図面の簡単な説明】
【0009】
【図1】ゲームシステムの概略構成を示す図である。
【図2】ゲームシステムの機能的構成を示すブロック図である。
【図3】マップを表示する画面の一例を示す図である。
【図4】ユーザが取得した山の一覧を表示する画面の一例を示す図である。
【図5】採掘を行う際のゲーム画面の一例を示す図である。
【図6】資産の獲得および消費の流れについて説明するための図である。
【図7】山の取得および採掘に係るタイムラインについて説明するための図である。
【図8】ピッケルの購入に係る画面の一例を示す図である。
【図9】ユーザが保有するピッケルの一覧を表示する画面の一例を示す図である。
【図10】山の生成および山で取得可能なアイテムの決定に係る処理の一例を示すフローチャートである。
【図11】山の取得および採掘に係る処理の一例を示すフローチャートである。
【図12】仮想通貨の支払いが求められる特定の処理を決済が完了する前に実行する流れの一例を示すフローチャートである。
【発明を実施するための形態】
【0010】
以下、図面を参照しながら本発明の実施形態について説明する。
【0011】
＜ゲームシステムのハードウェア構成＞
図１に示すように、本実施形態のゲームシステム１は、複数の端末装置１０と、サーバ２０と、ブロックチェーンシステム（換言すると、ブロックチェーンネットワーク）３とを備えている。また、ブロックチェーンシステム３は、複数のノード装置３０を備えている。
図１に示すように、本実施形態のゲームシステム１は、複数の端末装置１０と、サーバ２０と、ブロックチェーンシステム（換言すると、ブロックチェーンネットワーク）３とを備えている。また、ブロックチェーンシステム３は、複数のノード装置３０を備えている。
【0012】
端末装置１０とサーバ２０とブロックチェーンシステム３（換言すると、ノード装置３０）とは、ネットワーク２を介して互いに接続される。ネットワーク２は、例えば、インターネット、移動通信システム（例えば、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ（Long Term Evolution）等）、ＷｉＦｉ（Wireless Fidelity）、ブルートゥース（登録商標）、その他の通信回線、またはこれらの組み合わせ等のいずれによって構成されていてもよい。
【0013】
サーバ２０（換言すると、コンピュータ、情報処理装置）は、例えば、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってもよい。サーバ２０は、プロセッサ２１と、メモリ２２と、ストレージ２３と、通信ＩＦ（インターフェース）２４と、入出力ＩＦ２５と、を備える。サーバ２０が備えるこれらの構成は、通信バスによって互いに接続される。
【0014】
プロセッサ２１は、サーバ２０全体の動作を制御する。プロセッサ２１は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）およびＧＰＵ（Graphics Processing Unit）等を含み得る。プロセッサ２１は、ストレージ２３からプログラムを読み出し、メモリ２２に展開する。プロセッサ２１は、展開したプログラムを実行する。
【0015】
メモリ２２は、主記憶装置である。メモリ２２は、例えば、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置により構成される。メモリ２２は、プロセッサ２１がストレージ２３から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ２１に作業領域を提供する。メモリ２２は、プロセッサ２１がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
【0016】
なお、本実施形態においてプログラムとは、ゲームを端末装置１０により実現するプログラムであってもよい。また、当該プログラムは、当該ゲームを端末装置１０とサーバ２０との協働により実現するプログラムであってもよい。また、当該プログラムは、当該ゲームを端末装置１０とサーバ２０とブロックチェーンシステム３との協働により実現するプログラムであってもよい。なお、当該ゲームは、一例として、端末装置１０において起動されたブラウザ上で実行されるゲームであってもよい。また、各種データには、例えば、ユーザ情報およびゲーム情報などのゲームに関するデータ、および端末装置１０やサーバ２０等の各装置間で送受信される指示や通知が含まれる。
【0017】
ストレージ２３は、補助記憶装置である。ストレージ２３は、例えば、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置により構成される。ストレージ２３には、ゲームに関する各種データが格納される。
【0018】
通信ＩＦ２４は、サーバ２０と端末装置１０等との間におけるネットワークを介した各種データの送受信を制御する。また、通信ＩＦ２４は、サーバ２０とブロックチェーンシステム３（換言すると、ノード装置３０）との間におけるネットワークを介した各種データの送受信を制御する。
【0019】
入出力ＩＦ２５は、サーバ２０がデータの入力を受け付けるためのインターフェースであるとともに、サーバ２０がデータを出力するためのインターフェースである。入出力ＩＦ２５は、例えば、マウス、キーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
【0020】
端末装置１０（換言すると、コンピュータ、情報処理装置）は、例えば、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、タブレット型コンピュータ、パーソナルコンピュータ、ウェアラブル端末、またはゲーム装置等であってもよい。端末装置１０は、携帯端末であってもよい。端末装置１０は、ユーザがゲームを実行する際に可搬型の端末であってもよい。
【0021】
端末装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信ＩＦ１４と、入出力ＩＦ１５と、入力部１７と、表示部１８と、を備える。端末装置１０が備えるこれらの構成は、通信バスによって互いに接続される。
【0022】
プロセッサ１１は、端末装置１０全体の動作を制御する。プロセッサ１１は、ＣＰＵ、ＭＰＵおよびＧＰＵ等を含み得る。プロセッサ１１は、ストレージ１３からプログラムを読み出し、メモリ１２に展開する。プロセッサ１１は、展開したプログラムを実行する。
【0023】
メモリ１２は、主記憶装置である。メモリ１２は、例えば、ＲＯＭおよびＲＡＭ等の記憶装置により構成される。メモリ１２は、プロセッサ１１がストレージ１３から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１１に作業領域を提供する。メモリ１２は、プロセッサ１１がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
【0024】
ストレージ１３は、補助記憶装置である。ストレージ１３は、例えば、フラッシュメモリまたはＨＤＤ等の記憶装置により構成される。ストレージ１３には、ゲームに関する各種データが格納される。
【0025】
通信ＩＦ１４は、端末装置１０とサーバ２０等との間におけるネットワークを介した各種データの送受信を制御する。なお、通信ＩＦ１４は、端末装置１０とブロックチェーンシステム３（換言すると、ノード装置３０）との間におけるネットワークを介した各種データの送受信を制御してもよい。
【0026】
入出力ＩＦ１５は、端末装置１０がデータの入力を受け付けるためのインターフェースであるとともに、端末装置１０がデータを出力するためのインターフェースである。入出力ＩＦ１５は、例えばＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行うこととしてもよい。入出力ＩＦ１５は、入力部１７または表示部１８等を含み得る。
【0027】
入力部１７は、ユーザによる入力を受け付ける。入力部１７は、例えば、タッチパッドやマウス等のポインティングデバイスであってもよい。表示部１８は、画像を表示する。表示部１８は、例えば、液晶ディスプレイまたは有機ＥＬ（Electro-Luminescence）ディスプレイ等であってもよい。端末装置１０は、例えば、入力部１７と表示部１８とを組み合わせた電子部品であるタッチスクリーンを備えていてもよい。この場合、入力部１７は、ユーザの操作（例えば、タッチ操作、タップ操作、スライド操作、スワイプ操作、フリック操作、ピンチイン操作およびピンチアウト操作等）により入力面に対して入力された位置を検知し、検知した位置を示す情報を入力信号として送信する機能を有し得る。
【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】
表示制御部１１４は、仮想空間のうち、端末処理部１１３が規定する仮想カメラの視野の領域と、その領域に存在するオブジェクトとを描画した画像を生成し、表示部１８に表示させる。表示制御部１１４は、表示部１８に表示させる画像に対し、例えば、アイコン、ボタン、各種パラメータを示すメニュー等、ゲームの種々の操作に必要なＵＩ（User Interface）に関わるオブジェクトを重畳して描画することができる。
【0063】
なお、端末装置１０の制御部１１０は、サーバ２０から送られるオブジェクトのデータや、仮想空間上における各種オブジェクトの位置を示す情報等に基づいて、仮想空間にオブジェクトを配置し、仮想空間の所定領域を表示部１８に表示させてもよい。また、サーバ２０の制御部２１０が、仮想空間へのオブジェクトの配置や仮想カメラの制御を行い、表示部１８に表示させる画像を生成して端末装置１０に送信し、端末装置１０の制御部１１０は、当該画像を表示部１８に表示させてもよい。すなわち、ユーザの入力操作に基づくオブジェクトに関する制御や、仮想カメラの制御や、表示部１８に表示させる画像の生成等に係る各種処理は、サーバ２０で行われてもよく、端末装置１０で行われてもよい。
【0064】
ノード装置３０は、プロセッサ３１、メモリ３２、ストレージ３３、通信ＩＦ３４、および入出力ＩＦ３５等の協働によって、制御部３１０および記憶部３２０として機能する。記憶部３２０は、ゲームプログラムの一部を含むプログラムや、ブロックチェーンシステム３において用いられる分散型台帳等を記憶する。
【0065】
制御部３１０は、記憶部３２０に格納されたプログラムを実行することにより、ノード装置３０の動作を制御する。
【0066】
制御部３１０は、ユーザが各種アイテムや後述する特定トークンを取得（例えば、他のユーザあるいはゲームの運営者から取得（例えば、後述する採掘により取得））した際にサーバ２０から送信されるアイテムや特定トークンの保有に係る情報の登録要求を受信すると、当該情報を分散型台帳に登録する。制御部３１０は、例えば、サーバ２０または端末装置１０から送信されるアイテムや特定トークンの取引（換言すると、移譲）に関する情報に基づいて、各アイテムや特定トークンの取引履歴の情報を分散型台帳に登録してもよい。具体的には、分散型台帳には、ハッシュ値およびトランザクションを含む複数のブロックが記憶される。トランザクションは、例えば、アイテムや特定トークンの取引内容を示す情報であり得る。トランザクションは、例えば、移譲元を示すインプット情報と、移譲先を示すアウトプット情報とを含む。ハッシュ値は、一つ前のブロックに含まれる情報から算出され、分散型台帳には、ハッシュ値により各ブロックがチェーンのように繋がった状態でアイテムや特定トークンの取引履歴等が記憶される。このような取引履歴を各ノード装置３０の分散型台帳で管理すること等により、どのユーザがどのアイテムを保有しているかを示す情報や、どのユーザがどの程度の特定トークンを保有しているかを示す情報をブロックチェーン上に記憶することができる。なお、アイテム等の取引履歴ではなく、各ユーザのアイテム等の保有状態に関する情報を分散型台帳で管理することによりどのユーザがどのアイテムを保有しているかを示す情報等をブロックチェーン上に記憶するなどしてもよい。このように、本実施形態のゲームでは、アイテムや特定トークンの保有情報がブロックチェーン上に記憶される。なお、保有情報がブロックチェーン上に記憶されないアイテム等が存在してもよい。
【0067】
なお、図２に示す端末装置１０、サーバ２０およびノード装置３０の機能は一例にすぎない。端末装置１０、サーバ２０およびノード装置３０の各装置は、他の装置が備える機能の少なくとも一部を備えていてもよい。換言すると、本実施形態において端末装置１０が備える機能ブロックの一部または全部をサーバ２０あるいはノード装置３０が備えていてもよく、サーバ２０の備える機能ブロックの一部または全部を端末装置１０あるいはノード装置３０が備えていてもよく、ノード装置３０の備える機能ブロックの一部または全部を端末装置１０あるいはサーバ２０が備えていてもよい。また、端末装置１０、サーバ２０およびノード装置３０等の各装置は、一体の機器により実現されるものでなくてもよく、例えば、ネットワーク等を介して接続される複数の機器によって実現されてもよい。また、ゲームシステム１は、例えば、端末装置１０、サーバ２０またはノード装置３０を含んでいなくてもよい。
【0068】
＜本実施形態に係る処理＞
次に、本実施形態に係る処理について説明する。なお、本実施形態では、端末装置１０のプロセッサ１１、サーバ２０のプロセッサ２１、またはノード装置３０のプロセッサ３１が、ゲームシステム１に記憶されているプログラムを実行することによって、後述する各処理を行うものとして説明する。ただし、後述する処理であってプロセッサ１１が行う処理のうちの少なくとも一部を、プロセッサ１１とは別のプロセッサ（例えば、プロセッサ２１またはプロセッサ３１）が実行するようにしてもよい。また、後述する処理であってプロセッサ２１が行う処理のうちの少なくとも一部を、プロセッサ２１とは別のプロセッサ（例えば、プロセッサ１１またはプロセッサ３１）が実行するようにしてもよい。また、後述する処理であってプロセッサ３１が行う処理のうちの少なくとも一部を、プロセッサ３１とは別のプロセッサ（例えば、プロセッサ１１またはプロセッサ２１）が実行するようにしてもよい。換言すると、本実施形態においてプログラムを実行するコンピュータは、端末装置１０、サーバ２０およびノード装置３０のいずれであってもよく、また、複数の装置の組み合わせにより実現されてもよい。また、各種処理のうちの一部または全部がブロックチェーン上で実行されてもよい。
次に、本実施形態に係る処理について説明する。なお、本実施形態では、端末装置１０のプロセッサ１１、サーバ２０のプロセッサ２１、またはノード装置３０のプロセッサ３１が、ゲームシステム１に記憶されているプログラムを実行することによって、後述する各処理を行うものとして説明する。ただし、後述する処理であってプロセッサ１１が行う処理のうちの少なくとも一部を、プロセッサ１１とは別のプロセッサ（例えば、プロセッサ２１またはプロセッサ３１）が実行するようにしてもよい。また、後述する処理であってプロセッサ２１が行う処理のうちの少なくとも一部を、プロセッサ２１とは別のプロセッサ（例えば、プロセッサ１１またはプロセッサ３１）が実行するようにしてもよい。また、後述する処理であってプロセッサ３１が行う処理のうちの少なくとも一部を、プロセッサ３１とは別のプロセッサ（例えば、プロセッサ１１またはプロセッサ２１）が実行するようにしてもよい。換言すると、本実施形態においてプログラムを実行するコンピュータは、端末装置１０、サーバ２０およびノード装置３０のいずれであってもよく、また、複数の装置の組み合わせにより実現されてもよい。また、各種処理のうちの一部または全部がブロックチェーン上で実行されてもよい。
【0069】
ここで、本実施形態のゲームの概要について説明する。本実施形態のゲームには、ゲームに参加する複数のユーザ（具体的には、全ユーザ）の間で共通のマップ４０が存在する。マップ４０の一例を図３に示す。マップ４０には、複数の山が配置されている。図３に示すマップ４０では、山の位置が三角の記号で示されている。
【0070】
ユーザは、マップ４０から自分が採掘を行う山（換言すると、ゲームをプレイする仮想空間）を取得（換言すると、選択）する。山の取得は、例えば、以下のように行われる。例えば、端末装置１０の表示制御部１１４は、ユーザによる所定の入力操作に基づいて、図３に示すように、マップ４０（換言すると、ユーザが取得可能な山の一覧）を表示部１８に表示させる。そして、表示部１８に表示されるマップ４０上において、特定の山を選択すること（例えば、表示された特定の山に対するクリック操作）で当該特定の山を取得することができる。具体的には、例えば、表示制御部１１４は、マップ４０上に表示された山のうちの特定の山を選択する操作が行われると、選択した山を取得する操作を受け付ける取得ボタン４１を表示部１８に表示させる。そして、ゲーム制御部２１２は、取得ボタン４１に対する操作（例えば、クリック操作）に基づいて、ユーザが選択した山を当該ユーザに取得させる。
【0071】
また、ユーザは、自身が取得した山において所定のアイテムの採掘をすることが可能となっている。換言すると、ユーザは、山を取得すると、取得した山において採掘を行うゲームをプレイすることが可能となる。すなわち、本実施形態において、「特定の山の取得」は、「特定の山についての採掘を行う権利の取得」と言い換えることができ、さらに「特定の仮想空間でゲームをプレイする権利の取得」と言い換えることもできる。なお、ユーザが山を取得（換言すると、採掘を行う権利を取得）せずに、山での採掘を行うことが可能に構成されていてもよい。
【0072】
また、本実施形態のゲームでは、山での採掘に用いられるアイテムＡが用意されている。そして、採掘を行うためには、ユーザは、アイテムＡを持っている必要がある。換言すると、アイテムＡは、ゲームに参加するために必要なアイテムとなっている。本実施形態においては、アイテムＡは、ピッケルとなっている。なお、アイテムＡを持っていない場合、山の取得が行えないようになっていてもよい。本実施形態のゲームでは、特性の異なる複数種類のアイテムＡが用意されている。また、アイテムＡは、ＮＦＴ（Non-Fungible Token）化された状態を取り得るアイテムとなっている。ＮＦＴ化された状態とは、アイテムＡがユニークなものであることを証明する情報がブロックチェーン上に記憶された状態を意味する。換言すると、ＮＦＴ化された状態とは、アイテムＡに対応するＮＦＴが発行されブロックチェーンで管理されている状態を意味する。なお、以下では、対応するＮＦＴが発行されたアイテム等のデジタル資産のこともＮＦＴと呼ぶ。なお、本実施形態では、アイテムＡのＮＦＴ化（換言すると、アイテムＡの生成）は、ゲームの運営者が行うようになっており、ユーザが行うこと（換言すると、ユーザによるミント）はできないようになっている。換言すると、本実施形態のゲームにおいては、ＮＦＴ化されていない状態のアイテムＡをユーザが入手することはないようになっている。ただし、アイテムＡのＮＦＴ化をユーザが行うことが可能となっていてもよい。
【0073】
また、本実施形態のゲームでは、ユーザは、採掘によりアイテムＢおよびアイテムＣを取得可能となっている。詳細は後述するが、アイテムＢは、ＮＦＴ化された状態を取り得るアイテムとなっている。また、アイテムＣは、所定のトークンとの交換が可能なアイテムとなっている。以下では、アイテムＣとの交換により取得可能なトークンを「特定トークン」という。
【0074】
また、本実施形態のゲームでは、アイテムＢは、複数種類存在し、コレクション要素のあるアイテムとなっている。具体的には、アイテムＢは、ユーザが収集する宝石となっている。また、アイテムＣは、宝石とは異なる鉱物（以下、「輝石」という。）となっている。すなわち、本実施形態のゲームは、アイテムＡとしてのピッケルを用いて山での採掘を行い、アイテムＢとしての宝石やアイテムＣとしての輝石を取得するというゲーム性を有している。
【0075】
また、アイテムＣとの交換によって取得可能な特定トークンは、仮想通貨となっている。本実施形態のゲームでは、特定トークンは、アイテムＡのランクの上昇、アイテムＡのリペア（換言すると、修理）、およびアイテムＢのＮＦＴ化等に用いることが可能となっている。
【0076】
なお、ＮＦＴ化されているか否かに関わらず、各ユーザが保有するアイテムＡ、アイテムＢ、またはアイテムＣ等の資産は、ブロックチェーン（換言すると、分散型台帳）で管理されてもよい。
【0077】
所定のイベントとしての山での採掘は、例えば、以下のように行われる。例えば、端末装置１０の表示制御部１１４は、ユーザによる所定の入力操作に基づいて、図４に示すように、ユーザが取得した山の一覧４４を表示部１８に表示させる。なお、山の一覧４４は、ユーザが取得した山を表示部１８に表示されるマップ４０上で示すもの等であってもよい。また、表示制御部１１４は、表示部１８に表示されるユーザが取得した山（換言すると、一覧表示された山）のうちの特定の山を選択する操作が行われると、選択した山での採掘の開始に係る操作を受け付ける採掘開始ボタン４６を表示部１８に表示させる。そして、ゲーム制御部２１２は、採掘開始ボタン４６に対する操作（例えば、クリック操作）に基づいて、ユーザが選択した山での採掘を開始させる。
【0078】
ゲーム制御部２１２は、採掘開始ボタン４６に対する操作がされると、図５に示すように、仮想空間としての採掘を行う山３４にプレイヤキャラクタ３５を配置する。そして、ゲーム制御部２１２は、ユーザによる入力操作に基づいてプレイヤキャラクタ３５を動かす。すなわち、山３４はユーザがプレイヤキャラクタ３５を操作して所定のゲーム（具体的には採掘を行うゲーム、換言すると所定のインゲーム）をプレイ可能（換言すると、所定のイベントを実行可能）な仮想空間となっている。すなわち、特定の山３４での採掘の開始は、特定の仮想空間でのゲームのプレイの開始ともいえ、特定の仮想空間に入ることともいえる。ゲーム制御部２１２は、ユーザによる入力操作に基づいて、プレイヤキャラクタ３５を仮想空間内で移動させたり、プレイヤキャラクタ３５にピッケル３６を使用する動作（具体的には、ピッケル３６を振る操作）を行わせたりする。仮想空間内におけるプレイヤキャラクタ３５の操作方法は従来のアクションゲーム等と同様とすることができるが、例えば、以下のようにしてもよい。ゲーム制御部２１２は、キーボードの「Ｗ」「Ａ」「Ｓ」「Ｄ」キーに対する操作に基づいて、プレイヤキャラクタ３５を山３４の中で移動させてもよい。また、ゲーム制御部２１２は、キーボードのスペースキーに対する操作に基づいて、プレイヤキャラクタ３５にジャンプをさせてもよい。また、ゲーム制御部２１２は、マウスに対する左クリック操作に基づいて、プレイヤキャラクタ３５にピッケル３６を振って山３４を掘る採掘動作を行わせてもよい。
【0079】
山３４には、宝石や輝石が埋蔵（換言すると、配置）されている。そして、ユーザは自身の掘り出した（換言すると、発見した）宝石や輝石を獲得できる。すなわち、ゲーム制御部２１２は、ユーザの操作するプレイヤキャラクタ３５が宝石や輝石等のアイテムを掘り出すと、当該ユーザに掘り出されたアイテムを付与する（換言すると、取得させる）。
【0080】
なお、採掘は途中で中断することもできる。例えば、ゲーム制御部２１２は、ユーザによる所定のメニュー画面を開く操作および当該メニュー画面における山３４からの退出を指示する操作に基づいて、プレイヤキャラクタ３５を山３４から退出させる（換言すると、採掘を終了させる）。このとき、ゲーム制御部２１２は、採掘の進捗状態を記憶部２２０に記憶させる。そして、次に同じ山３４での採掘が開始される際には、ゲーム制御部２１２は、記憶された進捗状態を読み出し、採掘を続きから再開させる。すなわち、採掘を再開する際には、山３４の前回掘った部分については掘られた状態となり、山３４に埋蔵された宝石等のうち、前回掘り出された宝石等については掘り出された状態となる。換言すると、特定の仮想空間としての山３４は、当該特定の仮想空間から一度出て再度入る際には、前回入った際にユーザが与えた変化が反映された状態となる。換言すると、本実施形態では、特定の仮想空間でのゲームを中断し、途中から再開させることが可能となっている。
【0081】
また、ユーザは、自身が取得した山を任意に処分することができる。例えば、表示制御部１１４は、図４に示すように、表示部１８に表示されるユーザが取得した山（換言すると、一覧表示された山）のうちの特定の山を選択する操作が行われると、選択した山の処分に係る操作を受け付ける処分ボタン４７を表示部１８に表示させる。そして、ゲーム制御部２１２は、処分ボタン４７に対する操作（例えば、クリック操作）に基づいて、選択した山を処分（換言すると、選択した山について、ユーザの取得状態を解除）する。処分された山は、ユーザが取得した山の一覧４４から消え、その山での採掘が行えない状態となる。
【0082】
なお、本実施形態においては、採掘において使用するピッケルは、採掘開始ボタン４６に対する操作により採掘を開始する前に選択するようになっている。このようなピッケルの選択に係る操作は、従来のゲームにおける、使用する（換言すると、プレイヤキャラクタ３５に装備させる）武器を選択する操作と同様とすることができる。なお、使用するピッケルを採掘をしている最中に変更可能となっていてもよい。
【0083】
採掘に使用されるピッケルには耐久値が設定されており、採掘に使用するに従って耐久値が低下（例えば、耐久値「１００」から耐久値「０」に向かって低下）する。そして、耐久値が所定値（例えば、耐久値「０」）に達すると、ピッケルが使用できない状態になる。換言すると、耐久値が所定値に達したピッケルを使用しての採掘は行えないようになっている。
【0084】
また、操作受付部１１１は、ユーザによるピッケルの耐久値の回復（換言すると、アイテムＡのリペア）を指示する操作を受け付ける。そして、ゲーム制御部２１２は、当該操作に基づいて、ピッケルの耐久値を回復させる処理を行う。また、ピッケルの耐久値の回復には、所定量の特定トークンが必要となっており、当該操作によりピッケルの耐久値を回復させる際には、当該所定量の特定トークンが消費される。
【0085】
また、ピッケルにはランクが設定されている。なお、ランクとは所謂レベル等を含む。ピッケルのランクが上昇すると、ピッケルの所定のパラメータが変化する。具体的には、ピッケルのランクが上昇すると、宝石や輝石の取得のしやすさ（換言すると、採掘の効率）に影響する所定のパラメータが変化する。より具体的には、ピッケルのランクが上昇すると、ピッケルの振る速度に関するパラメータが変化しピッケルを振る速度が速くなる。これにより、採掘の速度が上昇するため、採掘の効率が上昇する。また、ピッケルのランクが上昇すると、耐久値の最大値が上昇する。これにより、耐久値を回復させることなく採掘を継続できる時間が延びるため、採掘の効率が上昇する。また、ピッケルのランクが上昇すると、ピッケルのパワーが上昇し、１回の振りで掘れる量（換言すると、１回の操作が山に対して与える影響量）等が上昇してもよい。これにより、採掘の速度が上昇するため、採掘の効率が上昇する。
【0086】
また、操作受付部１１１は、ピッケルのランクの上昇を指示する操作を受け付ける。そして、ゲーム制御部２１２は、当該操作に基づいて、ピッケルのランクを上昇させる処理を行う。また、ピッケルのランクの上昇には、所定量の特定トークンが必要となっており、当該操作によりピッケルのランクを上昇させる際には、当該所定量の特定トークンが消費される。
【0087】
なお、本実施形態のゲームでは、アイテムＡ、アイテムＢおよびアイテムＣとは異なる入手経路で入手可能なアイテムが用意されていてもよい。例えば、ゲーム内通貨（例えば、ブロックチェーンで管理されず、記憶部２２０等で管理されるユーザの保有資産）を使用してゲーム内で購入可能なアイテム（例えば、プレイヤキャラクタが装備可能なアイテム）等が存在してもよい。なお、当該ゲーム内通貨は、法定通貨を用いて購入可能なもの等であってもよい。
【0088】
また、本実施形態における各種アイテム（例えば、アイテムＡ、アイテムＢ、およびアイテムＣ）は、オブジェクトと読み替えてもよい。オブジェクトには、キャラクタやアイテム等が含まれる。すなわち、特定の仮想空間としての山でのゲームのプレイ（換言すると、イベントの実行）により付与されるアイテムＢやアイテムＣは、キャラクタ等であってもよい。
【0089】
なお、本実施形態では、マップは所定期間で（具体的には、１日１回）更新（換言すると、新たに生成）される。また、マップの更新に合わせて、取得可能な山も所定期間（具体的には、１日１回）で更新（換言すると、新たに生成）される。また、１つの山は、１人のユーザしか取得できないようになっており、あるユーザがある山（換言すると、当該ある山の採掘の権利）を取得すると、当該ある山を他のユーザが取得することはできないようになっている。換言すると、山の取得は早い者勝ちとなっている。なお、マップの更新や取得可能な山の更新とは、過去のマップや山が一新されるもの（換言すると、新しいマップや山が生成されるとともに過去のマップが無くなったり、過去の山が取得できなくなったりするもの）であってもよく、過去のマップが拡張されたり過去に生成された山に加えて新たな山が追加されるもの（換言すると、取得可能な山が増加するもの）等であってもよい。
【0090】
ここで、本実施形態のゲームにおける資産の獲得および消費の流れについて図６を参照しながら説明する。
【0091】
前述のように、本実施形態のゲームでは、ゲームに参加するためには、ユーザはピッケルを持っている必要がある。本実施形態では、ピッケルは、ゲーム内のマーケットプレイスでの購入が可能となっており、ユーザは、マーケットプレイスでピッケルを購入する。また、ピッケルは、特定トークンにより購入することが可能となっている。マーケットプレイスでの取引は、マーケット管理部２１４が管理する。具体的には、例えば、端末装置１０の操作受付部１１１は、ユーザが購入したいアイテムを選択する操作を受け付ける。そして、当該操作に関する情報が送受信部１１２，２１１を介してサーバ２０のマーケット管理部２１４に送られ、マーケット管理部２１４は、当該操作に基づいて、ユーザが選択したアイテムをユーザに渡すとともに、その対価を当該ユーザから当該アイテムを売った者に渡す処理を行う。
【0092】
次いで、ユーザは、取得したピッケルを使用して山での採掘を行う。採掘では、宝石および輝石を含む複数種類のアイテムの取得が可能となっている。
【0093】
ユーザが取得した輝石は、特定トークンと交換することが可能となっている。なお、輝石と特定トークンとの交換は、自動的に行われてもよく、ユーザによる交換を指示する操作に基づいて行われてもよい。すなわち、例えば、山から退出したタイミング等の特定のタイミングで、輝石が自動的に特定トークンに交換されてもよい。なお、本実施形態では、山での採掘により輝石がユーザに付与され、輝石が特定トークンと交換されるようになっているが、山での採掘により輝石に代えあるいは加え、特定トークンが直接ユーザに付与されるようになっていてもよい。
【0094】
本実施形態では、特定トークンは、ブロックチェーンで管理される仮想通貨となっている。特定トークンは、所定の取引所（例えば、分散型取引所）で他の仮想通貨と交換することが可能であってもよい。
【0095】
また、ユーザが取得した宝石は、ＮＦＴ化が可能となっている。すなわち、本実施形態では、宝石に対応するＮＦＴを発行し、ブロックチェーンで管理することが可能となっている。具体的には、端末装置１０の操作受付部１１１は、ユーザがゲーム内においてＮＦＴ化したい宝石を選択する操作を受け付けてもよい。そして、当該操作に関する情報が送受信部１１２，２１１を介してサーバ２０の資産管理部２１３に送られ、資産管理部２１３は、当該操作に基づいて、選択された宝石をＮＦＴ化する処理を行ってもよい。また、ＮＦＴ化には、手数料（例えば、所定量の特定トークン）が必要となっており、当該操作により宝石をＮＦＴ化する際には、当該手数料がユーザの保有資産から消費されるようになっていてもよい。また、ＮＦＴ化された宝石は、ゲーム内のマーケットプレイス等において売買することが可能となっていてもよい。換言すると、アイテムのＮＦＴ化とは、アイテムをマーケットプレイスでの売買が可能な状態にすることともいえる。具体的には、例えば、端末装置１０の操作受付部１１１は、ユーザが売りたい宝石（具体的には、ＮＦＴ化された宝石）を選択する操作を受け付けてもよい。そして、当該操作に関する情報が送受信部１１２，２１１を介してサーバ２０のマーケット管理部２１４に送られ、マーケット管理部２１４は、当該操作に基づいて、ユーザが選択した宝石を売りに出してもよい。そして、マーケット管理部２１４は、購入を希望する他のユーザがいる場合に、当該他のユーザに当該宝石を渡すとともに、その対価を当該他のユーザから当該宝石を売ったユーザに渡す処理を行ってもよい。換言すると、ＮＦＴ化されたアイテムＢは、他のユーザと取引することが可能であってもよい。
【0096】
また、宝石は、特定トークンと交換可能となっていてもよい。具体的には、端末装置１０の操作受付部１１１は、ユーザがゲーム内において特定トークンと交換したい宝石を選択する操作を受け付けてもよい。そして、当該操作に関する情報が送受信部１１２，２１１を介してサーバ２０に送られ、資産管理部２１３は、当該操作に基づいて、選択された宝石に換えて特定トークンをユーザに付与してもよい。換言すると、宝石は、ＮＦＴ化することと、特定トークンと交換することとが可能なアイテムであってもよい。なお、宝石と特定トークンとの交換は、宝石のＮＦＴ化前とＮＦＴ化後とのいずれか一方でのみ行えてもよく、両方で行えてもよい。
【0097】
ゲーム制御部２１２は、ユーザがプレイするゲームに関する制御を行う。ゲーム制御部２１２は、仮想空間管理部２３１および報酬付与部２３３を有する。また、仮想空間管理部２３１は、マップを作成するマップ作成処理、各山において取得可能なアイテム（換言すると、各仮想空間に配置されるアイテム）の概要を決定するアイテム概要決定処理、山を作成する仮想空間作成処理、および各山において取得可能なアイテムの詳細を決定するアイテム詳細決定処理を実行する。
【0098】
また、本実施形態における各種処理の中には、ランダム性を有する処理が存在する。本実施形態では、ランダム性を有する処理は、所定のシードを用いた演算を行うことにより実現される。当該所定のシードには、ブロックチェーン（例えば、ビットコインのブロックチェーン）を用いたシードと、後述する仮想空間ＩＤを用いたシードとが含まれるが、いずれか一方のみが含まれるなどしてもよい。具体的には、本実施形態では、ブロックチェーンを用いた２種類のシード（以下、それぞれ「ｓｅｅｄｈｌａｓｔ」、「ｓｅｅｄｈｆｉｒｓｔ」という。）と、仮想空間ＩＤを用いた１種類のシード（以下、「ｓｅｅｄｍｄｉｄ」という。）とが、用意されている。
【0099】
より具体的には、ブロックチェーンを用いたシードとしてのブロックチェーン（具体的には、例えば、ビットコインのブロックチェーン）のハッシュに関するシードと、仮想空間ＩＤに関するシードとが、ランダム性の実現に利用される。本実施形態では、任意の期間（例えば、１日）の最後のハッシュ（換言すると、最後に生成されたブロックのハッシュ値）であるｈａｓｈｌａｓｔ＿ｙｙｙｙｍｍｄｄと、ｈａｓｈｌａｓｔ＿ｙｙｙｙｍｍｄｄが生成された翌々日の最初のハッシュ（換言すると、最初に生成されたブロックのハッシュ値）であるｈａｓｈｆｉｒｓｔ＿ｙｙｙｙｍｍｄｄ＋２とが、ハッシュに関するシードとして用いられる。また、本実施形態では、仮想空間ＩＤが、仮想空間ＩＤに関するシードとして用いられる。すなわち、本実施形態では、ｓｅｅｄｈｌａｓｔ＝ｈａｓｈｌａｓｔ＿ｙｙｙｙｍｍｄｄであり、ｓｅｅｄｈｆｉｒｓｔ＝ｈａｓｈｆｉｒｓｔ＿ｙｙｙｙｍｍｄｄ＋２であり、ｓｅｅｄｍｄｉｄ＝仮想空間ＩＤとなっている。
【0100】
なお、本実施形態では、各種シードに基づいて、マップや各山において取得可能なアイテム等をランダムに決定するが、あるシードに基づいてマップや各種オブジェクト等の所定の事項についてランダムに決定する手法自体は周知であるため、説明を省略する。
【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】
次に、ピッケルのリペアに係る処理およびピッケルのランクの上昇に係る処理について説明する。ピッケルのリペアおよびランクの上昇は、例えば、以下のように行われる。例えば、端末装置１０の表示制御部１１４は、ユーザによる所定の入力操作に基づいて、図９に示すように、ユーザが保有するピッケルの一覧６４を表示部１８に表示させる。また、操作受付部１１１は、一覧表示されたピッケルの中から、特定のピッケルを選択する操作（例えば、特定のピッケルに対するクリック操作）を受け付ける。また、表示制御部１１４は、特定のピッケルが選択されると、選択されたピッケルに対する各種操作を受け付けるＵＩを表示部１８に表示させる。具体的には、表示制御部１１４は、当該ＵＩとして、ピッケルの耐久値の回復に係る操作を受け付けるリペアボタン６５、ピッケルのランクの上昇に係る操作を受け付けるアップグレードボタン６６、およびピッケルの売り出しに係る操作を受け付けるセルボタン６７を表示部１８に表示させる。なお、ピッケルの一覧６４を表示する画面においては、選択されたピッケルや、一覧表示されるピッケルについて、耐久値の残量を示す表示が表示されてもよい。図９に示す例においては、耐久値の残量を示す表示として残量を示すメーター６８が表示されているが、耐久値の残量を示す表示は、残量を示す数値等の表示であってもよい。
【0129】
端末装置の制御部１１０は、リペアボタン６５に対する操作（例えば、クリック操作）がされると、選択されたピッケルの耐久値の回復をサーバ２０に要求する。サーバ２０のゲーム制御部２１２は、当該要求に基づいて、選択されたピッケルの耐久値を回復させるとともに、ユーザに耐久値の回復の対価を支払わせる処理（換言すると、ユーザが保有する特定トークンを耐久値の回復の対価の分だけ減少させる処理）を実行する。すなわち、制御部２１０は、ユーザによる有償処理の実行に係る操作に基づき、有償処理としてのピッケルの耐久値を回復させる処理を実行する。
【0130】
また、端末装置の制御部１１０は、アップグレードボタン６６に対する操作（例えば、クリック操作）がされると、選択されたピッケルのランクの上昇をサーバ２０に要求する。サーバ２０のゲーム制御部２１２は、当該要求に基づいて、選択されたピッケルのランクを上昇させるとともに、ユーザにランクの上昇の対価を支払わせる処理（換言すると、ユーザが保有する特定トークンをランクの上昇の対価の分だけ減少させる処理）を実行する。すなわち、制御部２１０は、ユーザによる有償処理の実行に係る操作に基づき、有償処理としてのピッケルのランクを上昇させる処理を実行する。
【0131】
また、端末装置の制御部１１０は、セルボタン６７に対する操作（例えば、クリック操作）がされると、選択されたピッケルのマーケットプレイスへの出品をサーバ２０に要求する。サーバ２０のマーケット管理部２１４は、当該要求に基づいてユーザが選択したピッケルを売りに出し、これにより、購入を希望する他のユーザが当該ユーザから当該ピッケルを購入（例えば、特定トークンの支払いにより購入）することが可能となる。換言すると、出品されたピッケルは、他のユーザのショップ画面６０に表示されるようになる。
【0132】
なお、本実施形態においては、マーケットプレイスに出品されるピッケルには、ゲームの運営者が売るピッケルと他のユーザが売るピッケルとが存在する。すなわち、ユーザは、ピッケルをゲームの運営者から購入することと、他のユーザから購入することとが可能となっている。ピッケルをゲームの運営者から購入する場合、購入の対価はゲームの運営者に送金される。また、ピッケルを他のユーザから購入する場合、購入の対価は当該他のユーザに送金される。また、ピッケルの耐久値の回復の対価は、ゲームの運営者に送金される。また、ピッケルのランクの上昇の対価は、ゲームの運営者に送金される。
【0133】
ここで、決済の完了するタイミングと、有償処理が実行されるタイミングとの関係を説明する。
【0134】
制御部２１０は、ユーザによる有償処理の実行に係る操作がされると、有償処理に必要な対価の支払いに係るトランザクション（以下、「有償処理に係るトランザクション」という。）を生成し、ブロックチェーンシステム３のネットワークに送信し、ネットワーク全体（換言すると、複数（換言すると、全て）のノード装置３０）に共有させる。ブロックチェーンシステム３においては、有償処理に係るトランザクションを格納したブロックを生成するマイニングが行われ、マイニングにより生成されたブロックがブロックチェーンに追加される。これにより、有償処理に必要な対価が、ユーザから当該対価の受取人（例えば、ゲームの運営者等）に、送金される（換言すると、支払われる）。なお、有償処理に係るトランザクションには、送金元（例えば、ユーザ）、送金先（例えば、ゲームの運営者）、および送金額（換言すると、有償処理に必要な対価として支払う額）等の情報が含まれる。
【0135】
また、有償処理に必要な対価の支払い（換言すると、決済）は、ユーザによる有償処理の実行に係る操作がされた後、所定期間の経過後に完了する。制御部２１０は、有償処理に必要な対価の支払い（換言すると、決済）が完了したことを判定する。本実施形態においては、制御部２１０は、ユーザによる有償処理の実行に係る操作に基づき生成された、当該有償処理に係るトランザクションが格納されたブロックの後ろに所定数のブロックが繋がるのを待ってから、決済が完了したと判定する。例えば、制御部２１０は、当該有償処理に係るトランザクションが格納されたブロックの後ろに所定数のブロックが繋がったか確認し、繋がったことが確認された場合に決済が完了したと判定する（換言すると、完了したとみなす）。なお、制御部２１０は、ユーザによる有償処理の実行に係る操作に基づき、当該有償処理に係るトランザクションを生成した場合に、所定の基準時から（例えば、有償処理に係るトランザクションが生成されてから）一定時間が経過しても有償処理に係るトランザクションが格納されたブロックの後ろに所定数のブロックが繋がったことが確認できなかった場合、決済が完了しなかった（換言すると、決済に失敗した）と判定するなどしてもよい。なお、制御部２１０は、ユーザによる有償処理の実行に係る操作に基づき生成された、当該有償処理に係るトランザクションが格納されたブロックがブロックチェーンに追加されたか確認し、追加されたことが確認された場合に決済が完了したと判定するなどしてもよい。
【0136】
いずれにしても、ブロックチェーンで管理される仮想通貨の支払いには、支払いに係る操作（換言すると、有償処理の実行に係る操作）がされてから決済が完了するまでにある程度の時間がかかる。すなわち、ブロックチェーンで管理される仮想通貨の支払いには、当該支払いに係るトランザクションが格納されたブロックについてのマイニングが必要となるため、決済が完了するまでに、少なくとも当該マイニングに要する時間がかかることとなる。加えて、ブロックチェーンにおいて、当該ブロックの後ろに所定数のブロックが繋がるのを待つ場合においては、決済が完了するまでに更に時間がかかることとなる。
【0137】
このように、ブロックチェーンで管理される仮想通貨の支払いには、決済が完了するまでにある程度の時間がかかるため、有償処理を、決済の完了を待ってから行うこととすると、ユーザが有償処理の実行に係る操作を行ってから有償処理により仮想世界における所定の事象が発生するまでの間に時間がかかってしまうこととなる。そして、このように、ユーザが有償処理の実行に係る操作を行ってから事象が発生するまでの間に時間がかかってしまうと、仮想世界に係る体験についての快適度が低下してしまうおそれがある。具体的には、例えば、ピッケルの耐久値を回復させるべくリペアボタン６５に対する操作をしたにも関わらず、耐久値の回復に時間がかかってしまうと、当該ピッケルをすぐに使用することができず、ゲームの進行が阻害され、ゲームプレイの快適度が低下してしまうおそれがある。そこで、本実施形態においては、決済が完了する前に有償処理を実行することにより、快適なゲームプレイを実現している。
【0138】
制御部２１０は、有償処理のうちの少なくとも一部について、有償処理の実行に係るユーザの操作がされた後、決済が完了する前に有償処理を実行する。換言すると、制御部２１０は、有償処理のうちの少なくとも一部について、決済の完了を待たずに実行する。以下、決済の完了を待たずに実行される有償処理を「特定有償処理」という。特定有償処理には、例えば、リペアボタン６５に対する操作に基づいて実行されるピッケルの耐久値を回復させる処理が含まれる。
【0139】
本実施形態においては、制御部２１０は、ユーザによる特定有償処理の実行に係る操作に基づき生成された、当該特定有償処理に係るトランザクションが格納されたブロックが、ブロックチェーンに追加された場合に、当該特定有償処理を実行する。具体的には、制御部２１０は、当該特定有償処理に係るトランザクションが格納されたブロックがブロックチェーンに追加されたか否かを確認し、追加されたことが確認された場合に当該特定有償処理を実行する。換言すると、制御部２１０は、特定有償処理の実行に係る操作がされ、仮想通貨の支払いに係る情報が格納されたブロックがブロックチェーンに追加されたことを条件として特定有償処理を実行する。すなわち、本実施形態においては、特定有償処理に係るトランザクションが格納されたブロックの後ろに所定数のブロックが繋がるのを待って、当該特定有償処理に係る決済が完了となるところ、当該特定有償処理に係るトランザクションが格納されたブロックがブロックチェーンに追加されると、決済の完了を待たずに特定有償処理が実行される。なお、「特定有償処理に係るトランザクションが格納されたブロックがブロックチェーンに追加された場合に（あるいは追加されたことを条件として）特定有償処理を実行する」とは、少なくとも当該ブロックのブロックチェーンへの追加がされた後に特定有償処理を実行するものであればよく、例えば、当該ブロックのブロックチェーンへの追加がされた後、更に当該ブロックの後ろにいくつかのブロックが繋がったことを条件として特定有償処理を行うもの等を含み得る。
【0140】
すなわち、本実施形態においては、仮想世界における事象（換言すると、ゲーム内の事象）に関する処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理（換言すると、特定有償処理）が、当該特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行される。具体的には、特定有償処理としてのピッケルの耐久値を回復させる処理、換言するとピッケルの耐久値の回復という仮想世界における事象を発生させる処理が、ピッケルの耐久値の回復に係るユーザの操作がされた後、決済が完了する前に実行される。なお、特定有償処理には、ピッケルのランクを上昇させる処理、換言するとピッケルのランクの上昇という仮想世界における事象を発生させる処理が含まれてもよい。また、特定有償処理には、ピッケルの購入に係る処理、換言するとピッケルの取得という仮想世界における事象を発生させる処理が含まれてもよい。換言すると、特定有償処理は、仮想世界における所定のオブジェクト（例えば、ユーザが保有するオブジェクトまたは使用するオブジェクト等）に関連する処理であってもよい。また、当該所定のオブジェクトは、ピッケルに限らず、その他のアイテムや、プレイヤキャラクタ等の所定のキャラクタであってもよい。なお、本実施形態において「キャラクタ」とは、ユーザのアバターを含む。なお、特定有償処理には、全ての有償処理が含まれてもよい。また、特定有償処理の実行により発生する仮想世界における事象は、ゲームの進行においてユーザに有益な事象であってもよい。なお、ゲームの種類に関わらず、ゲーム内の事象は基本的に仮想世界における事象に含まれる。
【0141】
なお、制御部２１０は、特定有償処理の実行に係る操作がされたタイミングで当該特定有償処理を実行してもよい。また、制御部２１０は、特定有償処理に係るトランザクションを生成したタイミング（例えば、生成し、ブロックチェーンシステム３のネットワークに送信したタイミング）で当該特定有償処理を実行してもよい。また、制御部２１０は、特定有償処理の実行に係る操作がされた場合において、所定の基準時から一定時間の経過後に当該特定有償処理を実行してもよい。
【0142】
なお、「特定有償処理を、特定有償処理の実行に係る操作がされた後、決済が完了する前に実行する」とは、特定有償処理を必ず決済の完了前に実行するものであってもよく、特定有償処理を決済が完了した後に実行し得るものであってもよい。すなわち、例えば、特定有償処理の実行に係る操作がされた場合において、所定の基準時から一定時間の経過後に特定有償処理を実行する構成においては、マイニングにかかった時間と一定時間との関係によっては決済の完了後に特定有償処理が実行される場合が生じ得るが、「特定有償処理を、特定有償処理の実行に係る操作がされた後、決済が完了する前に実行する」とは、このように特定有償処理を決済が完了した後に実行し得るものであってもよい。
【0143】
また、制御部２１０は、特定有償処理に求められる量の仮想通貨をユーザが保有しているか確認し、保有していることが確認された場合に、特定有償処理を実行してもよい。すなわち、制御部２１０は、決済の完了までは待たないが、少なくとも特定有償処理に求められる量の仮想通貨を保有しているか否かは事前に確認した上で、特定有償処理を実行することとしてもよい。
【0144】
また、制御部２１０は、決済が完了する前に特定有償処理が実行され、その後決済が完了しなかった場合に、完了しなかった決済についての清算を、次回の特定有償処理の実行の際に実行してもよい。すなわち、例えば、決済が完了する前に特定有償処理が実行される構成においては、特定有償処理が実行されたにも関わらず、特定有償処理についての決済が完了しない場合が生じ得る。具体的には、ユーザによる不正やシステム側の不具合等により、決済が完了しない場合が生じ得る。そこで、制御部２１０は、何らかの理由により特定有償処理についての決済が完了しなかった場合（換言すると、対価の支払いが行われなかった場合）、次回の特定有償処理の実行の際に、決済が完了しなかった特定有償処理についての清算を実行してもよい。換言すると、制御部２１０は、次回の特定有償処理の実行の際に、決済が完了しなかった特定有償処理についての対価をユーザに支払わせてもよい。すなわち、制御部２１０は、次回の特定有償処理の実行に係る操作（例えば、リペアボタン６５に対する操作）が実行されると、決済が完了しなかった特定有償処理に係るトランザクション（具体的には、当該特定有償処理の対価の支払いに係るトランザクション）を生成し、決済が完了しなかった特定有償処理の対価をユーザに支払わせてもよい。このとき、制御部２１０は、当該ユーザの端末装置１０の制御部１１０に、清算を実行してもよいか（換言すると、決済が完了しなかった有償処理の対価の支払いを実行してもよいか）確認する表示を表示部１８に表示させるよう指示し、ユーザが清算の実行を承諾する操作を行ったことに基づいて清算を実行してもよい。
【0145】
また、制御部２１０は、完了しなかった決済についての清算を、次回の特定有償処理の実行の際に実行する場合に、当該次回の特定有償処理に係るトランザクションを生成し、当該次回の特定有償処理の対価もユーザに支払わせるが、当該次回の特定有償処理に係るトランザクションと、決済が完了しなかった特定有償処理に係るトランザクションとは、それぞれ別々のトランザクションとして生成されてもよく、１つのトランザクションとしてまとめられてもよい。また、制御部２１０は、当該次回の特定有償処理については、完了しなかった決済についての清算（換言すると、決済が完了しなかった特定有償処理の対価の支払い（換言すると、決済））が完了した後に（換言すると、完了したことを条件として）実行することとしてもよい。また、制御部２１０は、当該次回の特定有償処理については、当該次回の特定有償処理の対価の支払い（換言すると、決済）が完了した後に（換言すると、完了したことを条件として）実行することとしてもよい。
【0146】
換言すると、制御部２１０は、完了しなかった決済についての清算が完了するまで、次の特定有償処理を実行しないこととしてもよい。なお、当該清算は、次回の特定有償処理の実行に係る操作（例えば、リペアボタン６５に対する操作）とは異なる操作に基づいて実行されてもよい。例えば、当該清算は、特定有償処理の実行に係る操作とは独立した、清算を実行するための操作に基づいて実行されてもよい。
【0147】
また、制御部２１０は、ユーザの信用度を示すパラメータが特定の条件を満たす場合に、特定有償処理の実行に係る操作がされた後、決済が完了する前に特定有償処理を実行することとしてもよい。信用度を示すパラメータは、例えば、ユーザが行った取引の履歴（換言すると、実績）に係るパラメータであってもよい。取引の履歴に係るパラメータは、例えば、所定の期間内に行った取引についての取引金額の合計や、所定の期間内に行った取引の回数や、取引の実行に応じて上昇するユーザのランク等に係るパラメータであってもよい。ここで、所定の期間とは、例えば、ゲームを初めてプレイしてから現在までの期間であってもよく、現在から数日、数週間、あるいは数か月前までの期間等であってもよい。また、ここで取引とは、仮想通貨の支払い（例えば、正常に決済がされた支払い）と言い換えてもよい。また、取引とは、特定有償処理の実行と言い換えてもよい。また、信用度を示すパラメータは、所定の期間内におけるユーザの総プレイ時間や、所定のオブジェクト（例えば、ピッケルや、宝石や、山等）の保有数や、ゲームのプレイに応じて上昇するユーザのランク等に係るパラメータ等であってもよい。換言すると、信用度を示すパラメータは、ユーザのゲームプレイの実績に係るパラメータであってもよい。なお、ピッケルの保有数に係るパラメータ等の、仮想通貨を使用して取得可能なオブジェクトの保有数に係るパラメータは、取引の履歴に係るパラメータに含まれ得る。
【0148】
また、制御部２１０は、仮想世界における事象を発生させる処理であって、特定有償処理とは異なる処理であり、かつブロックチェーンで管理される仮想通貨の支払いが求められる第２の処理を、決済が完了した後に実行してもよい。換言すると、制御部２１０は、有償処理のうち、一部の処理については特定有償処理、換言すると第１の有償処理として決済の完了を待たずに実行し、他の一部の有償処理については第２の有償処理として決済の完了を待って（換言すると、決済が完了したことを条件として）実行することとしてもよい。例えば、ピッケルの耐久値を回復させる処理が第１の有償処理に含まれ、ピッケルをユーザに取得させる処理が第２の有償処理に含まれてもよい。また、有償処理（例えば、同種の有償処理）のうち、処理に要する金額（換言すると、仮想通貨の量）の小さい処理が第１の有償処理に含まれ、処理に要する金額の大きい処理が第２の有償処理に含まれてもよい。
【0149】
また、第１の有償処理は、重要度が相対的に低い処理であり、第２の有償処理は、重要度が相対的に高い処理であってもよい。ここで、重要度の高低は、例えば、処理に要する金額に応じて決まってもよく、ゲームの進行に対する影響度等に応じて決まってもよい。また、各処理について重要度の高低を示す情報が記憶部２２０に記憶され、制御部２１０は、有償処理を実行する場合に、決済の完了を待って処理を実行するか待たずに処理を実行するかを当該情報に基づいて決定してもよい。また、制御部２１０は、有償処理を実行する場合に、重要度の高低を決める所定のパラメータ（例えば、処理に要する金額等）が所定の基準値を超えているか否かを判定し、超えているか否かに応じて決済の完了を待って処理を実行するか待たずに処理を実行するかを決定してもよい。また、重要度の高低を判定するための情報が記憶されていなくてもよい。
【0150】
また、第１の有償処理は、第１の相手に対価を支払う処理であり、第２の有償処理は、第２の相手に対価を支払う処理であってもよい。例えば、制御部２１０は、送金先がゲームの運営者である所定の有償処理については決済の完了を待たずに実行し、送金先が他のユーザである所定の有償処理については決済の完了を待って実行することとしてもよい。具体的には、例えば、制御部２１０は、送金先がゲームの運営者であるピッケルの耐久値を回復させる処理については決済の完了を待たずに実行し、送金先が他のユーザである当該他のユーザからピッケル（あるいは宝石等）を購入する処理（換言すると、ピッケルを他のユーザから取得させる処理）については決済の完了を待って実行することとしてもよい。
【0151】
なお、ピッケルのリペアは、ピッケル毎ではなく、複数まとめて実行することが可能であってもよい。換言すると、有償処理には、複数のピッケルの耐久値を回復させる処理が含まれてもよい。例えば、表示制御部１１４は、図９に例示するユーザが保有するピッケルの一覧６４を表示する画面に、複数のピッケル（例えば、ユーザが保有する全てのピッケル）の耐久値の回復に係る操作を受け付けるリペアオールボタン６９を表示させてもよい。そして、操作受付部１１１は、リペアオールボタン６９に対する操作（例えば、クリック操作）を、ユーザが保有する複数のピッケルの耐久値の回復を指示する操作として受け付けてもよい。そして、ゲーム制御部２１２は、当該操作に基づいて、ユーザが保有するピッケル（具体的には、複数のピッケル）の耐久値を回復させる処理を行ってもよい。また、リペアオールボタン６９に対する操作に基づくピッケルの耐久値の回復（換言すると、複数のピッケルの耐久値を回復させる処理）には、リペアボタン６５に対する操作に基づくピッケルの耐久値の回復（換言すると、１つのピッケルの耐久値を回復させる処理）よりも多量の特定トークンが必要となっていてもよい。このような構成において、第１の有償処理には、リペアボタン６５に対する操作に基づいて実行されるピッケルの耐久値を回復させる処理が含まれ、第２の有償処理には、リペアオールボタン６９に対する操作に基づいて実行されるピッケルの耐久値を回復させる処理が含まれることとしてもよい。換言すると、制御部２１０は、特定のオブジェクトに係る有償処理のうち、第１の操作に基づく有償処理については決済の完了を待たずに実行し、第２の操作に基づく有償処理については決済の完了を待って実行することとしてもよい。また、制御部２１０は、特定のオブジェクトに係る有償処理のうち、第１の量の特定のオブジェクトに効果を発生させる有償処理については決済の完了を待たずに実行し、第１の量よりも多い第２の量の特定のオブジェクトに効果を発生させる有償処理については決済の完了を待って実行することとしてもよい。
【0152】
また、有償処理には、実行に係る操作がされてから実行されるまでの時間が相対的に長い有償処理と、相対的に短い有償処理とが含まれてもよい。ここで、実行されるまでの時間が相対的に長い有償処理および相対的に短い有償処理は、特定有償処理に含まれるものであってもよく、一部が特定有償処理に含まれないものであってもよい。例えば、制御部２１０は、処理に要する金額（換言すると、仮想通貨の量）が大きいほど、有償処理の実行に係る操作がされてから、有償処理が実行されるまでの時間を長くしてもよい。また、例えば、制御部２１０は、有償処理の種類に応じて、有償処理の実行に係る操作がされてから、有償処理が実行されるまでの時間を異ならせてもよい。また、制御部２１０は、重要度の高い処理ほど、有償処理の実行に係る操作がされてから、有償処理が実行されるまでの時間を長くしてもよい。具体的には、例えば、ピッケルの耐久値を回復させる処理が実行される場合について、処理に要する金額が大きい場合には処理に要する金額が小さい場合に比べ、処理が実行されるまでの時間が長くなっていてもよい。また、例えば、ピッケルをユーザに取得させる処理は、ピッケルの耐久値を回復させる処理に比べ、処理が実行されるまでの時間が長くなっていてもよい。ここで、処理が実行されるまでの時間はタイマー等によって管理されるものであってもよく、処理の実行契機によって決まるものであってもよい。例えば、制御部２１０は、有償処理を実行するまでの待ち時間を記憶部２２０内のタイマーによって管理し、ある有償処理については、所定の基準時から第１の規定時間（例えば、規定の分数）が経過したら実行し、別の有償処理については、所定の基準時から第１の規定時間よりも長い第２の規定時間が経過したら実行するなどしてもよい。また、例えば、制御部２１０は、ある有償処理については、当該ある有償処理に係るトランザクションが格納されたブロックがブロックチェーンに追加されたことを契機として実行し、別の有償処理については、当該別の有償処理に係るトランザクションが格納されたブロックの後ろに所定数のブロックが繋がったことを契機として実行することとし、結果として当該ある有償処理よりも当該別の有償処理の方が、実行されるまでの時間が長くなるようにしてもよい。
【0153】
また、制御部２１０は、決済の完了を待たずに特定有償処理を行う場合に、ユーザが保有する所定のオブジェクト（例えば、ピッケルや、宝石や、山等）を担保として設定し、決済が正常に完了しなかった場合には、担保として設定した所定のオブジェクトの利用を制限する処理を実行してもよい。ここで、利用を制限とは、例えば、売買（例えば、マーケットプレイスでの売買）を制限するものであってもよく、担保として設定した所定のオブジェクトを使用してのゲームの進行（例えば、担保として設定されたピッケルを使用した採掘等）を制限するものであってもよい。また、制御部２１０は、正常に完了しなかった決済についての清算が完了したことに基づいて利用の制限を解除してもよい。また、制御部２１０は、所定の期間が経過したことに基づいて利用の制限を解除してもよい。なお、担保として設定される所定のオブジェクトは、制御部２１０が、ユーザによる、自身の保有するオブジェクトの中から担保として設定するオブジェクトを選択する操作に基づいて決定することとしてもよく、ユーザの選択に基づかずに決定することとしてもよい。
【0154】
また、制御部２１０は、決済の完了を待たずに特定有償処理を行った場合において、その後決済が正常に完了しなかった場合には、特定有償処理により変化した事項について、特定有償処理を行う前の状態に戻す処理を行ってもよい。例えば、制御部２１０は、ピッケルの耐久値を回復させた場合において、当該耐久値の回復に係る決済が完了しなかった場合、ピッケルの耐久値を、回復させる前の状態に戻す処理を行ってもよい。また、制御部２１０は、決済の完了を待たずに特定有償処理を行った場合において、その後決済が正常に完了しなかった場合には、特定有償処理により変化した事項について、特定有償処理を行う前よりも不利な状態にする処理を行ってもよい。例えば、制御部２１０は、ピッケルの耐久値を回復させた場合において、当該耐久値の回復に係る決済が完了しなかった場合、ピッケルの耐久値を、回復させる前よりも低下した状態にする処理を行ってもよい。
【0155】
また、制御部２１０は、決済の完了を待たずに特定有償処理を行った場合において、その後決済が正常に完了しなかった場合には、特定有償処理の実行後に進行したゲームの進捗状態の少なくとも一部を、特定有償処理を行う前の状態に戻す処理を行ってもよい。例えば、制御部２１０は、ピッケルの耐久値を回復させた場合において、当該耐久値の回復に係る決済が完了しなかった場合、当該耐久値の回復後に採掘を行った山（例えば、当該ピッケルを使用して採掘を行った山）について、採掘の進捗状態を当該耐久値の回復を行う前の状態に戻す処理を行ってもよい。このとき、制御部２１０は、当該耐久値の回復後、採掘により取得したアイテム（例えば、宝石や輝石等）の少なくとも一部を、ユーザの保有資産から喪失させる処理を行ってもよい。
【0156】
換言すると、制御部２１０は、決済が完了する前に特定有償処理が実行され、その後決済が完了しなかった場合に、特定有償処理の実行によりユーザが享受した利益の少なくとも一部を喪失させる処理を行ってもよい。ここで、享受した利益には、例えば、耐久値の回復や、耐久値が回復したピッケルの使用によるゲームの進捗（例えば、採掘による仮想空間の状態の変化）や、耐久値が回復したピッケルの使用によるアイテムの取得等が含まれる。
【0157】
なお、ユーザが有償処理の実行に係る操作を行ってから有償処理の実行により所定の事象が発生するまでの間に時間がかかってしまうことによる問題を解決するための別の方法として、仮想通貨を、ゲーム内で使用可能な所定のポイント等に予め交換し、当該所定のポイントを使用して有償処理を実行するように構成することも考えられる。しかし、このような構成においては、仮想通貨を当該所定のポイントに交換する手間がかかったり、ユーザが管理する資産の種類が増えてしまうなどの理由により、ゲームプレイの快適度が低下してしまうおそれがある。これに対し、本実施形態の構成によれば、仮想通貨を直接利用して有償処理を実行することが可能となるため、より快適なゲームプレイを実現することができる。
【0158】
なお、本実施形態において、図３に例示するマップ４０を表示する画面、図４に例示するユーザが取得した山の一覧４４を表示する画面、図８に例示するショップ画面６０、および図９に例示するユーザが保有するピッケルの一覧６４を表示する画面等は、例えば、これらの各種画面の表示中等に表示される（換言すると、ゲーム画面に表示される）タブ等の所定のボタンに対するクリック操作等により表示されてもよい。すなわち、例えば、図９に例示する鉱山ボタン９１に対する操作に基づき、マップ４０を表示する画面や、取得した山の一覧４４を表示する画面が表示されてもよい。また、図９に例示するアイテムボタン９２に対する操作に基づき、保有するピッケルの一覧６４を表示する画面が表示されてもよい。また、図９に例示するショップボタン９３に対する操作に基づき、ショップ画面６０が表示されてもよい。また、図９に例示するホームボタン９４に対する操作に基づき、ホーム画面（図示せず）が表示されてもよい。また、図３および図４に例示するマップ表示ボタン９５およびマイ鉱山表示ボタン９６のそれぞれに対する操作に基づき、マップ４０（換言すると、取得可能な山の一覧）を表示する画面と取得した山の一覧４４を表示する画面とが切り替わるようになっていてもよい。
【0159】
なお、本実施形態においては、ピッケルの耐久値を回復させる処理や、ピッケルのランクを上昇させる処理や、ピッケルをユーザに取得させる処理等の各種有償処理は、採掘の実行中（換言すると、所定のインゲームのプレイ中）ではない所定の状況（換言すると、所定の仮想空間としての山に入っていない状況）において実行可能となっている。ただし、有償処理のうちの少なくとも一部が、採掘の実行中において、実行可能となっていてもよい。例えば、端末装置１０の表示制御部１１４は、採掘の実行中におけるユーザによる所定の入力操作に基づいて、メニュー画面を表示部１８に表示させる。また、当該メニュー画面には、ユーザが保有するピッケル（例えば、使用中のピッケル）の耐久値の回復に係る操作を受け付けるボタン（例えば、リペアボタン６５）が表示され、当該ボタンに対する操作がされると、制御部２１０は、ユーザが保有するピッケルの耐久値を回復させる処理を行う。なお、インゲームの実行中においてユーザの操作に基づき所定のメニュー画面を表示させることや、当該所定のメニュー画面における各種操作に基づき各種処理を行うことについては周知であるため、メニュ画面の図示等については省略する。
【0160】
（処理のフロー）
次に、ゲームシステム１が実行する処理の一例についてフローチャートを参照しながら説明する。まず、山の生成および山で取得可能なアイテムの決定に係る処理の一例を図１０に示すフローチャートを参照しながら説明する。
次に、ゲームシステム１が実行する処理の一例についてフローチャートを参照しながら説明する。まず、山の生成および山で取得可能なアイテムの決定に係る処理の一例を図１０に示すフローチャートを参照しながら説明する。
【0161】
仮想空間管理部２３１は、特定のブロックチェーンから、１日の最後に生成されたハッシュを取得する（ステップＳ１）。次いで、仮想空間管理部２３１は、取得したハッシュをシード（具体的には、ｓｅｅｄｈｌａｓｔ）として用いて演算を行いマップを作成する（ステップＳ２）。具体的には、仮想空間管理部２３１は、マップの地形およびマップにおける山の配置を決定するとともに、マップ内の各山に対して、各山を識別可能とする仮想空間ＩＤを付与する。
【0162】
次いで、仮想空間管理部２３１は、ステップＳ２で作成されたマップの各山について、取得可能なアイテムの概要を決定する（ステップＳ３）。具体的には、仮想空間管理部２３１は、ステップＳ１で取得したハッシュと、各ダンジョンの仮想空間ＩＤとをシード（具体的には、ｓｅｅｄｈｌａｓｔ、ｓｅｅｄｍｄｉｄ）として用いて演算を行い、各山について取得可能なアイテムの個数と、各アイテムのサイズの概要とを決定する。
【0163】
次いで、仮想空間管理部２３１は、ステップＳ３で概要が決定されたアイテムの取得可能な（換言すると、当該アイテムの配置された）山を作成する（ステップＳ４）。具体的には、仮想空間管理部２３１は、ステップＳ１で取得したハッシュと、各山の仮想空間ＩＤとをシード（具体的には、ｓｅｅｄｈｌａｓｔ、ｓｅｅｄｍｄｉｄ）として用いて演算を行い、山を作成する。
【0164】
次いで、仮想空間管理部２３１は、ステップＳ１で取得したハッシュの生成された日の翌々日最初に生成されたハッシュを取得する（ステップＳ５）。次いで、仮想空間管理部２３１は、ステップＳ２で作成されたマップの各山について、報酬の詳細を決定する（ステップＳ６）。具体的には、仮想空間管理部２３１は、ステップＳ５で取得したハッシュと、各山の仮想空間ＩＤとをシード（具体的には、ｓｅｅｄｈｆｉｒｓｔ、ｓｅｅｄｍｄｉｄ）として用いて演算を行い、各山で取得可能なアイテムとしてのアイテムＢの種類、サイズの詳細、形状、または質などを決定する。
【0165】
次に、山の取得および山での採掘に係る処理の一例を図１１に示すフローチャートを参照しながら説明する。
【0166】
端末装置１０の操作受付部１１１は、マップ内の複数の山の中から、採掘を行う山を取得する操作を受け付ける（ステップＳ１１）。換言すると、操作受付部１１１は、複数の山の中から特定の山を選択する操作を受け付ける。さらに換言すると、操作受付部１１１は、特定の仮想空間でのゲームプレイについての権利の取得に係る操作を受け付ける。
【0167】
採掘を行う山を取得する操作が行われると、ゲーム制御部２１２は、当該操作に基づいて、特定の山をユーザに付与する（ステップＳ１２）。換言すると、ゲーム制御部２１２は、ユーザの操作に基づいて、特定の仮想空間でのゲームプレイについての権利を当該ユーザに付与する。
【0168】
また、操作受付部１１１は、ユーザが取得した山について、山での採掘の開始を指示する操作を受け付ける（ステップＳ１３）。換言すると、操作受付部１１１は、ユーザによる、当該ユーザがゲームをプレイする権利を有する仮想空間でのゲームのプレイの開始を指示する操作を受け付ける。
【0169】
また、ゲーム制御部２１２は、ユーザによる山での採掘の開始を指示する操作に基づいて採掘を開始させる（ステップＳ１４）。換言すると、ゲーム制御部２１２は、ユーザによる特定の仮想空間でのゲームのプレイの開始を指示する操作に基づいて当該特定の仮想空間でのゲームのプレイを開始させる。なお、開始されるゲームは、ユーザがプレイヤキャラクタ等を操作して手動で進めるものであってもよく、ユーザの操作を介さずにゲーム制御部２１２が自動で進めるものであってもよい。具体的には、例えば、プレイヤキャラクタが自動で採掘を行い、プレイヤキャラクタが掘り出した宝石等がユーザに報酬として付与されるようになっていてもよい。また、当該ゲームを手動で進行させるか自動で進行させるかをユーザが選択可能となっていてもよい。
【0170】
次いで、報酬付与部２３３は、山での採掘に基づいて、ユーザに報酬を付与する（ステップＳ１５）。換言すると、報酬付与部２３３は、特定の仮想空間でのゲームのプレイに基づいて、ユーザに報酬を付与する。具体的には、報酬付与部２３３は、山での採掘に基づいて宝石や輝石をユーザに付与する。
【0171】
次に、仮想通貨の支払いが求められる特定の処理（換言すると、特定有償処理）を、当該特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する流れの一例を図１２に示すフローチャートを参照しながら説明する。
【0172】
端末装置１０の制御部１１０は、特定有償処理の実行に係る操作を受け付ける（ステップＳ２１）。具体的には、制御部１１０は、特定有償処理としてのピッケルの耐久値を回復させる処理の実行に係る操作として、リペアボタン６５に対する操作を受け付ける。
【0173】
次いで、端末装置１０の制御部１１０は、特定有償処理の実行に係る操作がされると、特定有償処理の実行の要求をサーバ２０に送信する（ステップＳ２２）。
【0174】
次いで、サーバ２０の制御部２１０は、端末装置１０から送信された特定有償処理の実行の要求に基づき（換言すると、特定有償処理の実行に係る操作に基づき）、特定有償処理に係るトランザクション（換言すると、特定有償処理に必要な対価の支払いに係るトランザクション）を生成する（ステップＳ２３）。また、制御部２１０は、生成されたトランザクションをブロックチェーンシステム３のネットワークに送信し、当該ネットワーク全体に共有させる（ステップＳ２４）。なお、トランザクションの生成および当該ネットワークへの送信は、端末装置１０の制御部１１０等が実行してもよい。
【0175】
次いで、ブロックチェーンシステム３は、マイニングを行い特定有償処理に係るトランザクションを格納したブロックを生成し、当該ブロックをブロックチェーンに追加する（ステップＳ２５）。
【0176】
次いで、制御部２１０は、特定有償処理に係るトランザクションを格納したブロックがブロックチェーンに追加されたか否かを判定する（ステップＳ２６）。そして、制御部２１０は、当該ブロックがブロックチェーンに追加されたことが確認されると（ステップＳ２６でＹＥＳ）、特定有償処理を実行する（ステップＳ２７）。一方、制御部２１０は、当該ブロックがブロックチェーンに追加されたことが確認されるまで、特定有償処理を実行しない。
【0177】
また、制御部２１０は、特定有償処理に係るトランザクションを格納したブロックの後ろに所定数のブロックが繋がったか否かを判定する（ステップＳ２８）。そして、制御部２１０は、特定有償処理に係るトランザクションを格納したブロックの後ろに所定数のブロックが繋がったことが確認されると（ステップＳ２８でＹＥＳ）、特定有償処理の実行に係る対価の支払いについての決済が完了したと判定する（ステップＳ２９）。なお、制御部２１０は、決済が完了すると、決済が完了したことを端末装置１０（換言すると、ユーザ）に通知してもよい。換言すると、端末装置１０の表示制御部１１４は、決済の完了後において、決済が完了したことを確認可能な画面を表示部１８に表示可能であってもよい。なお、制御部２１０は、決済が完了すると、決済が完了したことを示す情報（換言すると、フラグ）を記憶部２２０に記憶させる。
【0178】
なお、特定有償処理に係るトランザクションを格納したブロックがブロックチェーンに追加されたことを示す情報（換言すると、ステップＳ２６の判定に用いる情報）は、例えば、制御部２１０がブロックチェーンシステム３のサーバ等の当該情報を記憶した記憶部に所定のタイミングでアクセスするなどして取得することとしてもよく、当該ブロックがブロックチェーンに追加されると、ブロックチェーンシステム３から制御部２１０に送られることとしてもよい。また、特定有償処理に係るトランザクションを格納したブロックの後ろに所定数のブロックが繋がったことを示す情報（換言すると、ステップＳ２８の判定に用いる情報）は、例えば、制御部２１０がブロックチェーンシステム３のサーバ等の当該情報を記憶した記憶部に所定のタイミングでアクセスするなどして取得することとしてもよく、特定有償処理に係るトランザクションを格納したブロックの後ろに所定数のブロックが繋がると、ブロックチェーンシステム３から制御部２１０に送られることとしてもよい。
【0179】
なお、本実施形態においてブロックチェーンで管理されるアイテム、仮想通貨、トークン、および各種ロジック（換言すると、スマートコントラクト）等は、同一のブロックチェーンで管理されてもよく、一部が異なるブロックチェーンで管理されてもよい。また、各種処理に用いられるハッシュは、当該同一のブロックチェーンのハッシュであってもよく、他のブロックチェーンのハッシュであってもよい。なお、ブロックチェーンには、イーサリアムやビットコイン等の既存のものを用いてもよい。なお、アイテムＡやアイテムＢに対応するＮＦＴ（換言すると、ＮＦＴ化されたアイテムＡやアイテムＢ）は、発行されたブロックチェーンから他のブロックチェーンにブリッジすることが可能となっていてもよい。
【0180】
なお、本実施形態に係る各構成は、本実施形態に係るゲーム以外のコンテンツ（換言すると、サービス）に適用することもできる。
【0181】
なお、本発明は、上述した実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変形して実施できる。本発明はその発明の範囲内において、各構成要素の自由な組み合わせ、任意の構成要素の変形、または任意の構成要素の省略等が可能である。また、本明細書において説明した処理の流れはあくまで一例であり、各処理の順序や構成は異なるものであってもよい。また、本明細書において説明した各種判定処理等の各処理には存在しないものがあってもよい。換言すると、処理の流れや具体的な判定処理等は本明細書に例示したものと異なっていてもよい。
【0182】
＜付記＞
以上の実施形態で説明した事項は、以下の付記のようにも記載され得る。
以上の実施形態で説明した事項は、以下の付記のようにも記載され得る。
【0183】
（付記１）
コンピュータを、
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段（例えば、制御部２１０）として機能させる
プログラム。
このような構成によれば、仮想通貨の支払いが求められる特定の処理を、決済の完了を待たずに実行することが可能となるので、ユーザが操作を行ってから特定の処理が実行され仮想世界における事象が発生するまでの時間を短くし、仮想世界に係る体験についての快適度を向上させることができる。
コンピュータを、
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段（例えば、制御部２１０）として機能させる
プログラム。
このような構成によれば、仮想通貨の支払いが求められる特定の処理を、決済の完了を待たずに実行することが可能となるので、ユーザが操作を行ってから特定の処理が実行され仮想世界における事象が発生するまでの時間を短くし、仮想世界に係る体験についての快適度を向上させることができる。
【0184】
（付記２）
前記実行手段は、前記特定の処理に求められる量の前記仮想通貨を前記ユーザが保有しているか確認し、保有していることが確認された場合に、前記特定の処理を実行する
付記１に記載のプログラム。
このような構成によれば、特定の処理に求められる量の仮想通貨を保有しているか事前に確認した上で、特定の処理が実行されるので、ユーザが操作を行ってから仮想世界における事象が発生するまでの時間を短くしつつも、特定の処理に係る決済が完了しない確率を低減させることができる。
前記実行手段は、前記特定の処理に求められる量の前記仮想通貨を前記ユーザが保有しているか確認し、保有していることが確認された場合に、前記特定の処理を実行する
付記１に記載のプログラム。
このような構成によれば、特定の処理に求められる量の仮想通貨を保有しているか事前に確認した上で、特定の処理が実行されるので、ユーザが操作を行ってから仮想世界における事象が発生するまでの時間を短くしつつも、特定の処理に係る決済が完了しない確率を低減させることができる。
【0185】
（付記３）
前記実行手段は、前記特定の処理の対価の支払いに係る情報が格納されたブロックがブロックチェーンに追加された場合に、前記特定の処理を実行する
付記１に記載のプログラム。
当該ブロックが生成され、ブロックチェーンに追加されるということは、特定の処理の実行に係るユーザの操作が不正なものでなく、ユーザに支払いの意思がある可能性が高い。また、仮にフォーク等の発生により当該ブロックが破棄されたとしても、別のブロックにより正常に決済が完了する可能性が高い。したがって、このような構成によれば、決済が完了しない確率を大幅に低減させつつ、ユーザが操作を行ってから特定の処理が実行され仮想世界における事象が発生するまでの時間を短くすることができる。
前記実行手段は、前記特定の処理の対価の支払いに係る情報が格納されたブロックがブロックチェーンに追加された場合に、前記特定の処理を実行する
付記１に記載のプログラム。
当該ブロックが生成され、ブロックチェーンに追加されるということは、特定の処理の実行に係るユーザの操作が不正なものでなく、ユーザに支払いの意思がある可能性が高い。また、仮にフォーク等の発生により当該ブロックが破棄されたとしても、別のブロックにより正常に決済が完了する可能性が高い。したがって、このような構成によれば、決済が完了しない確率を大幅に低減させつつ、ユーザが操作を行ってから特定の処理が実行され仮想世界における事象が発生するまでの時間を短くすることができる。
【0186】
（付記４）
前記実行手段は、前記仮想世界における事象を発生させる処理であって、前記特定の処理とは異なる処理であり、かつ前記仮想通貨の支払いが求められる第２の処理を、決済が完了した後に実行する
付記１に記載のプログラム。
このような構成によれば、仮想世界における事象を発生させる処理であって仮想通貨の支払いが求められる複数の処理のうち、一部の処理についてはユーザの操作が実行されてから事象が発生するまでの時間を短くしてユーザの快適度を向上させつつも、処理だけが実行されて対価の回収ができなくなってしまうことを避けたい処理については決済を先に行い、対価の回収ができない事態の発生を防止することができる。
前記実行手段は、前記仮想世界における事象を発生させる処理であって、前記特定の処理とは異なる処理であり、かつ前記仮想通貨の支払いが求められる第２の処理を、決済が完了した後に実行する
付記１に記載のプログラム。
このような構成によれば、仮想世界における事象を発生させる処理であって仮想通貨の支払いが求められる複数の処理のうち、一部の処理についてはユーザの操作が実行されてから事象が発生するまでの時間を短くしてユーザの快適度を向上させつつも、処理だけが実行されて対価の回収ができなくなってしまうことを避けたい処理については決済を先に行い、対価の回収ができない事態の発生を防止することができる。
【0187】
（付記５）
コンピュータを、
決済が完了する前に前記特定の処理が実行され、その後決済が完了しなかった場合に、完了しなかった決済についての清算を、次回の前記特定の処理の実行の際に実行する清算手段（例えば、制御部２１０）として機能させる
付記１に記載のプログラム。
このような構成によれば、対価の支払いが無いまま特定の処理が次々と実行されてしまうことを防止することができる。
コンピュータを、
決済が完了する前に前記特定の処理が実行され、その後決済が完了しなかった場合に、完了しなかった決済についての清算を、次回の前記特定の処理の実行の際に実行する清算手段（例えば、制御部２１０）として機能させる
付記１に記載のプログラム。
このような構成によれば、対価の支払いが無いまま特定の処理が次々と実行されてしまうことを防止することができる。
【0188】
（付記６）
前記実行手段は、前記ユーザの信用度を示すパラメータが特定の条件を満たす場合に、前記操作がされた後、決済が完了する前に前記特定の処理を実行する
付記１に記載のプログラム。
このような構成によれば、決済の完了前に特定の処理を実行するか否かをユーザの信用度に応じて異ならせることができる。
前記実行手段は、前記ユーザの信用度を示すパラメータが特定の条件を満たす場合に、前記操作がされた後、決済が完了する前に前記特定の処理を実行する
付記１に記載のプログラム。
このような構成によれば、決済の完了前に特定の処理を実行するか否かをユーザの信用度に応じて異ならせることができる。
【0189】
（付記７）
コンピュータを、
決済が完了する前に前記特定の処理が実行され、その後決済が完了しなかった場合に、前記特定の処理の実行により前記ユーザが享受した利益の少なくとも一部を喪失させる喪失手段（例えば、制御部２１０）として機能させる
請求項１に記載のプログラム。
このような構成によれば、対価を支払っていないにも関わらずユーザが特定の処理の実行による利益を享受してしまうことを抑制することができる。
コンピュータを、
決済が完了する前に前記特定の処理が実行され、その後決済が完了しなかった場合に、前記特定の処理の実行により前記ユーザが享受した利益の少なくとも一部を喪失させる喪失手段（例えば、制御部２１０）として機能させる
請求項１に記載のプログラム。
このような構成によれば、対価を支払っていないにも関わらずユーザが特定の処理の実行による利益を享受してしまうことを抑制することができる。
【0190】
（付記８）
前記特定の処理は、前記仮想世界内の特定のオブジェクトのパラメータを変化させる処理である
付記１～７のいずれか１つに記載のプログラム。
このような構成によれば、ユーザが操作を行ってから仮想世界内のオブジェクトのパラメータに変化が生じるまでの時間を短くすることができる。
前記特定の処理は、前記仮想世界内の特定のオブジェクトのパラメータを変化させる処理である
付記１～７のいずれか１つに記載のプログラム。
このような構成によれば、ユーザが操作を行ってから仮想世界内のオブジェクトのパラメータに変化が生じるまでの時間を短くすることができる。
【0191】
（付記９）
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段（例えば、制御部２１０）を備える
情報処理システム。
このような構成によれば、付記１に記載のプログラムと同様の作用効果を奏することができる。
仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、前記特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段（例えば、制御部２１０）を備える
情報処理システム。
このような構成によれば、付記１に記載のプログラムと同様の作用効果を奏することができる。
【符号の説明】
【0192】
１ ゲームシステム、３ ブロックチェーンシステム、１０ 端末装置、１１ プロセッサ、１２ メモリ、１３ ストレージ、１４ 通信ＩＦ、１５ 入出力ＩＦ、１７ 入力部、１８ 表示部、２０ サーバ、２１ プロセッサ、２２ メモリ、２３ ストレージ、２４ 通信ＩＦ、２５ 入出力ＩＦ、３０ ノード装置、３１ プロセッサ、３２ メモリ、３３ ストレージ、３４ 通信ＩＦ、３５ 入出力ＩＦ、１１０ 制御部、１１１ 操作受付部、１１２ 送受信部、１１３ 端末処理部、１１４ 表示制御部、１２０ 記憶部、２１０ 制御部、２１１ 送受信部、２１２ ゲーム制御部、２１３ 資産管理部、２１４ マーケット管理部、２２０ 記憶部、２３１ 仮想空間管理部、２３３ 報酬付与部、３１０ 制御部、３２０ 記憶部
【要約】
【課題】仮想世界に係る体験についての快適度を向上させる。
【解決手段】プログラムは、コンピュータを、仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段として機能させる。
【選択図】図９
【解決手段】プログラムは、コンピュータを、仮想世界における事象を発生させる処理であって、ブロックチェーンで管理される仮想通貨の支払いが求められる特定の処理を、特定の処理の実行に係るユーザの操作がされた後、決済が完了する前に実行する実行手段として機能させる。
【選択図】図９
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】