知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024167620
(43)【公開日】2024-12-04
(54)【発明の名称】プログラム、トレード処理方法、及びトレードシステム
(51)【国際特許分類】
A63F 13/79 20140101AFI20241127BHJP
G06Q 50/10 20120101ALI20241127BHJP
A63F 13/69 20140101ALI20241127BHJP
【ＦＩ】
A63F13/79 520
G06Q50/10
A63F13/79
A63F13/69
【審査請求】有
【請求項の数】13
【出願形態】ＯＬ
(21)【出願番号】P 2023083823
(22)【出願日】2023-05-22
(71)【出願人】
【識別番号】506113602
【氏名又は名称】株式会社コナミデジタルエンタテインメント
(74)【代理人】
【識別番号】100161207
【弁理士】
【氏名又は名称】西澤 和純
(74)【代理人】
【識別番号】100175824
【弁理士】
【氏名又は名称】小林 淳一
(72)【発明者】
【氏名】城石 啓太
【テーマコード（参考）】
5L049
5L050
【Ｆターム（参考）】
5L049CC18
5L050CC18
(57)【要約】
【課題】ゲームにおけるトレードを促進すること。
【解決手段】プログラムは、複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理を実行するプログラムであって、コンピュータに、ユーザによるアイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、第１ユーザが所有しているアイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、を実行させる。
【選択図】図１
【解決手段】プログラムは、複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理を実行するプログラムであって、コンピュータに、ユーザによるアイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、第１ユーザが所有しているアイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、を実行させる。
【選択図】図１
【特許請求の範囲】
【請求項1】
複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理を実行するプログラムであって、
コンピュータに、
ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、
第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、
を実行させるためのプログラム。
コンピュータに、
ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、
第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、
を実行させるためのプログラム。
【請求項2】
前記報酬の内容は、前記報酬が付与されるタイミングによって可変である、
請求項１に記載のプログラム。
請求項１に記載のプログラム。
【請求項3】
前記アイテムの所有状況は、前記アイテムの所有数であり、
前記報酬を付与するステップにおいて、ユーザによる前記アイテムの所有数に応じた第１報酬を定期的にユーザに付与する、
請求項１に記載のプログラム。
前記報酬を付与するステップにおいて、ユーザによる前記アイテムの所有数に応じた第１報酬を定期的にユーザに付与する、
請求項１に記載のプログラム。
【請求項4】
前記報酬を付与するステップにおいて、ユーザによる前記アイテムの所有数が所定の閾値を超えることに応じて前記第１報酬を変更する、
請求項３に記載のプログラム。
請求項３に記載のプログラム。
【請求項5】
前記アイテムには対応するゲームがあり、
前記アイテムの所有状況は、同一のゲームに対応する前記アイテムの所有数であり、
前記アイテムの所有状況に応じて付与される前記第１報酬は、前記アイテムに対応するゲーム内において利用可能である、
請求項３に記載のプログラム。
前記アイテムの所有状況は、同一のゲームに対応する前記アイテムの所有数であり、
前記アイテムの所有状況に応じて付与される前記第１報酬は、前記アイテムに対応するゲーム内において利用可能である、
請求項３に記載のプログラム。
【請求項6】
同一のゲームに対応する前記アイテムには、前記アイテムごとに個別に設定された個別情報が関連付けられており、
前記コンピュータに、
前記アイテムに設定された個別情報に基づいて前記第１報酬とは別に第２報酬を付与するステップ、
を実行させる請求項５に記載のプログラム。
前記コンピュータに、
前記アイテムに設定された個別情報に基づいて前記第１報酬とは別に第２報酬を付与するステップ、
を実行させる請求項５に記載のプログラム。
【請求項7】
同一のゲームに対応する前記アイテムには、前記アイテムごとに個別に設定された個別情報が関連付けられており、
前記報酬を付与するステップにおいて、前記アイテムに設定された個別情報に基づいて前記第１報酬を付与する、
請求項５に記載のプログラム。
前記報酬を付与するステップにおいて、前記アイテムに設定された個別情報に基づいて前記第１報酬を付与する、
請求項５に記載のプログラム。
【請求項8】
前記所定額は、トレード元のユーザまたはトレード先のユーザによってきめられた額である、
請求項１に記載のプログラム。
請求項１に記載のプログラム。
【請求項9】
前記アイテムは、ＮＦＴ（Ｎｏｎ－Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ）である、
請求項１に記載のプログラム。
請求項１に記載のプログラム。
【請求項10】
前記アイテムは、前記ゲーム内において直接的な利用ができない、
請求項１に記載のプログラム。
請求項１に記載のプログラム。
【請求項11】
前記アイテムには、前記報酬の内容ごとに異なるアイテムが含まれる、
請求項１に記載のプログラム。
請求項１に記載のプログラム。
【請求項12】
複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理方法であって、
ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、
第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、
を含むトレード処理方法。
ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、
第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、
を含むトレード処理方法。
【請求項13】
複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理を実行するトレードシステムであって、
ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与する報酬付与部と、
第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするトレード部と、
を備えるトレードシステム。
ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与する報酬付与部と、
第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするトレード部と、
を備えるトレードシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラム、トレード処理方法、及びトレードシステムに関する。
【背景技術】
【0002】
ゲームの仕様において、他のユーザとアイテムなどをトレードすることができるものがある（例えば、特許文献１参照）。トレードは、ゲーム内で利用するキャラクタやアイテムなどを、他のユーザとゲーム内通貨などと交換するものであり、ゲームを有利に進めるための手段の一つであると同時にトレードそのものもゲームにおける魅力の一つである。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１４－００８２７７号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、トレードの対象となるキャラクタやアイテムなどは、やがてトレードされなくなってしまうことが起こり得る。例えば、ゲーム内の特定のミッション（例えば特定の敵ボスを倒すこと）を達成するために有用なキャラクタやアイテムは、そのミッションを多くのユーザが達成した状況となると、そのキャラクタやアイテムの需要が減少し、やがてはトレード対象とならなくなってしまう。そのため、ゲームにおける魅力の一つであるトレードが、あまり活発に行われないということが生じていた。
【0005】
本発明のいくつかの態様は、ゲームにおけるトレードを促進することができるプログラム、トレード処理方法、及びトレードシステムを提供することを目的の一つとする。
【0006】
また、本発明の他の態様は、後述する実施形態に記載した作用効果を奏することを可能にするプログラム、トレード処理方法、及びトレードシステムを提供することを目的の一つとする。
【課題を解決するための手段】
【0007】
上述した課題を解決するために、本発明の一態様は、複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理を実行するプログラムであって、コンピュータに、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、を実行させるためのプログラムである。
【0008】
また、本発明の一態様は、複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理方法であって、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与するステップと、第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするステップと、を含むトレード処理方法である。
【0009】
また、本発明の一態様は、複数のユーザのそれぞれに対応する端末装置と通信して、各ユーザが所有しているアイテムをユーザ間でトレードするトレード処理を実行するトレードシステムであって、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬を定期的に付与する報酬付与部と、第１ユーザが所有している前記アイテムと第２ユーザが所有している所定額の通貨とをトレードするトレード部と、を備えるトレードシステムである。
【図面の簡単な説明】
【0010】
【図1】第１の実施形態に係るトレードシステムの概略構成の一例を示すシステム図。
【図2】第１の実施形態に係る優待券アイテムの画像イメージ例を示す図。
【図3】第１の実施形態に係る報酬テーブルの一例を示す図。
【図4】第１の実施形態に係る報酬テーブルの別の例を示す図。
【図5】第１の実施形態に係る報酬付与タイミングの一例を示す図。
【図6】第１の実施形態に係るサブ報酬の報酬テーブルの一例を示す図。
【図7】第１の実施形態に係るコンピュータの概略構成の一例を示すブロック図。
【図8】第１の実施形態に係るトレードサーバの機能構成の一例を示すブロック図。
【図9】第１の実施形態に係るトレード処理の一例を示すフローチャート。
【図10】第１の実施形態に係るトレード処理の別の例を示すフローチャート。
【図11】第１の実施形態に係る報酬付与処理の一例を示すフローチャート。
【図12】第２の実施形態に係るトレードサーバの機能構成の一例を示すブロック図。
【図13】第２の実施形態に係る報酬倍率テーブルの一例を示す図。
【図14】第２の実施形態に係る報酬付与処理の一例を示すフローチャート。
【図15】第２の実施形態に係るミッションの達成状況の一例を示す図。
【発明を実施するための形態】
【0011】
以下、本発明の一実施形態について、図面を参照して説明する。
[第１の実施形態]
〔システム構成及び概要〕
まず、本発明の第１の実施形態に係るトレードシステムの構成と概要を説明する。
図１は、本実施形態に係るトレードシステムの概略構成の一例を示すシステム図である。
[第１の実施形態]
〔システム構成及び概要〕
まず、本発明の第１の実施形態に係るトレードシステムの構成と概要を説明する。
図１は、本実施形態に係るトレードシステムの概略構成の一例を示すシステム図である。
【0012】
ゲームサーバ２０は、ゲームサービスごとに対応して存在しており、各ゲームの処理を実行する端末装置１０と通信しながら、各ユーザが端末装置１０でプレイするゲームの進行などを管理する。図示する例では、ゲームＡとゲームＢの２種類のゲームサービスを例として示しているが、３種類以上のゲームサービスとしても良いし、１種類のゲームサービスとしても良い。
【0013】
この図において、ゲームサーバ２０Ａは、ゲームＡのゲームサービスに対応し、ゲームＡをプレイする複数の端末装置１０Ａと通信しながら、各ユーザが端末装置１０Ａでプレイするゲームの進行などを管理する。また、ゲームサーバ２０Ｂは、ゲームＢのゲームサービスに対応し、ゲームＢをプレイする複数の端末装置１０Ｂと通信しながら、各ユーザが端末装置１０Ｂでプレイするゲームの進行などを管理する。なお、この図では、ゲームＡをプレイする端末装置１０ＡとゲームＢをプレイする端末装置１０Ｂとをそれぞれ２台示しているが、台数は特に限定されるものではない。
【0014】
トレードサーバ３０は、ゲームサーバ２０とは独立したサーバで、各ゲームに関連するアイテムをユーザ間などでトレードするための機能を有する。トレードサーバ３０は、ブロックチェーンシステムを利用したトレードサービスの一部として機能し、トレードサーバ３０上での取引（トランザクション）の履歴が複数のデバイスに複製されて保存される（分散台帳）。取引は、スマートコントラクトによって実行されても良い。
【0015】
ここで、トレード可能なアイテムは、各ゲームに関連するアイテムであるが、ゲーム内で直接的に利用するものではない。このアイテムは、ユーザがトレードシステム１の運営側から購入したり、他のユーザとトレードしたりすることにより所有することができる。そして、ユーザのアイテムの所有状況（例えば、所有数など）に応じて、ゲーム内で利用可能な報酬が定期的に付与される。
【0016】
端末装置１０は、例えばスマートフォンまたはタブレット型のＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などのユーザ端末である。例えば、端末装置１０は、端末装置１０内のブラウザや専用のゲームアプリケーションを利用してゲームサーバ２０と通信し、各ゲームサービスのゲーム処理を実行する。また、端末装置１０は、端末装置１０内のブラウザや専用のトレードアプリケーションを利用してゲームサーバ２０を介さずにトレードサーバ３０と通信し、アイテム等のトレードを実行することもできる。
【0017】
この図では、ゲームサーバ２０Ａと通信してゲームＡのゲームサービスのゲーム処理を実行する端末装置１０を端末装置１０Ａ、ゲームサーバ２０Ｂと通信してゲームＢのゲームサービスのゲーム処理を実行する端末装置１０を端末装置１０Ｂ、ゲームＡ及びゲームＢのゲームサービスを利用していない端末装置１０を端末装置１０Ｃとして示している。なお、各端末装置１０は、いずれの用途としても利用可能である。
【0018】
なお、端末装置１０は、ノート型のＰＣ、デスクトップ型のＰＣ、端末装置などであっても良い。
【0019】
端末装置１０と、ゲームサーバ２０と、トレードサーバ３０とのそれぞれの通信は、ネットワークを介して行われる。ネットワークとは、例えば、インターネットや、携帯電話網、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）網、専用通信回線網、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ；公衆交換電話網）などのいずれか、またはこれらの組み合わせによって構成される通信ネットワークである。
【0020】
（アイテムの所有情報の管理）
ユーザが所有するトレード可能なアイテムの所有情報は、トレードサーバ３０でのみ管理される。ここでのユーザとは、ゲームのユーザ（プレイヤ）を指すものではなく、トレードシステム１のトレードサービスを利用するユーザのことを指す。トレード可能なアイテムは、トレードサーバ３０のみで管理されるアイテムであるため、ゲーム内で利用されるゲーム要素のアイテムは含まれない。つまり、トレードサーバ３０は、ゲーム内で利用されるゲーム要素（ゲームキャラクタ、ゲームアイテム、抽選券など）を管理するのではなく、ゲーム内では直接的に利用されないトレード対象のアイテム（トレード可能なアイテム）を管理する。例えば、トレードサーバ３０は、トレード用のユーザＩＤ（識別情報）と、購入またはトレードによって所有しているアイテムに関する情報とを関連付けてユーザの所有情報として管理する。
ユーザが所有するトレード可能なアイテムの所有情報は、トレードサーバ３０でのみ管理される。ここでのユーザとは、ゲームのユーザ（プレイヤ）を指すものではなく、トレードシステム１のトレードサービスを利用するユーザのことを指す。トレード可能なアイテムは、トレードサーバ３０のみで管理されるアイテムであるため、ゲーム内で利用されるゲーム要素のアイテムは含まれない。つまり、トレードサーバ３０は、ゲーム内で利用されるゲーム要素（ゲームキャラクタ、ゲームアイテム、抽選券など）を管理するのではなく、ゲーム内では直接的に利用されないトレード対象のアイテム（トレード可能なアイテム）を管理する。例えば、トレードサーバ３０は、トレード用のユーザＩＤ（識別情報）と、購入またはトレードによって所有しているアイテムに関する情報とを関連付けてユーザの所有情報として管理する。
【0021】
この管理方法であれば、必ずしも関連するゲームのアカウントを必要としないため、そのゲームをプレイしているプレイヤでなくともトレードすることができる。ここでは、トレードシステム１においてトレード対象となるアイテムのことを、「優待券アイテム」と称する。
【0022】
〔優待券アイテムの仕様〕
図２は、本実施形態に係る優待券アイテムの画像イメージ例を示す図である。ユーザは、端末装置１０を操作することによりトレードサーバ３０にアクセスして、図２に示す画像イメージで表示されるような優待券アイテムを運営から購入したり他のユーザとトレードしたりすることによって入手し、所有することができる。
図２は、本実施形態に係る優待券アイテムの画像イメージ例を示す図である。ユーザは、端末装置１０を操作することによりトレードサーバ３０にアクセスして、図２に示す画像イメージで表示されるような優待券アイテムを運営から購入したり他のユーザとトレードしたりすることによって入手し、所有することができる。
【0023】
ユーザ間のトレードは、売却側（トレード元）か購入側（トレード先）の少なくとも一方が購入金額等を決めて行われる。例えば、売却側が売却金額を設定し、それに合意するユーザが購入者となること、或いはオークションなど購入側が購入金額を決める場合がある。また、売却側と購入側の双方が売却金額および購入金額を決め、その金額の条件が合えばトレードが成立する方法としてもよい。
【0024】
優待券アイテムは、付与される報酬が利用可能なゲームごとに対応して用意されている。図２に示す優待券アイテムは、「ゲームＡ用」と記載されており、ゲームＡに対応した優待券アイテムであることを示している。このゲームＡに対応した優待券アイテムは、ゲームＡ内で利用可能な報酬が定期的に付与されるアイテムであって、ゲームＡ以外のゲームとの関連性は無い。例えば、ゲームＢに対応した優待券アイテムには、「ゲームＢ用」と記載されている。
【0025】
また、この図に示す優待券アイテムにおいて「１０枚」と記載されているのは、この優待券アイテムが１０枚分の優待券アイテムであることを示している。他にも１枚、５枚、２０枚分の優待券アイテムがあっても良い。また、右下の数字「Ｎｏ．００１０５５」は、シリアルナンバーであり、優待券アイテムごとに個別に設定されたユニークな数値（個別情報）である。このシリアルナンバーに関しては後述する。
【0026】
このような優待券アイテムのユーザによる所有状況（例えば、合計の所有枚数）に応じて、当該ユーザに対して報酬（メイン報酬）が定期的に付与される。例えば、所有枚数に応じて付与される報酬（報酬の内容）は、図３に示す報酬テーブルのように設定されている。
【0027】
〔報酬について〕
図３は、本実施形態に係る報酬テーブルの一例を示す図である。図示する報酬テーブルには、優待券アイテムの所有枚数と優待券アイテムの所有枚数に応じて付与される報酬とが関連付けられて設定されている。トレードサーバ３０は、この報酬テーブルを参照して、ユーザによる優待券アイテムの所有枚数に応じて報酬を付与する。
図３は、本実施形態に係る報酬テーブルの一例を示す図である。図示する報酬テーブルには、優待券アイテムの所有枚数と優待券アイテムの所有枚数に応じて付与される報酬とが関連付けられて設定されている。トレードサーバ３０は、この報酬テーブルを参照して、ユーザによる優待券アイテムの所有枚数に応じて報酬を付与する。
【0028】
図示する例では、優待券アイテムに対応するゲーム（以下、「対応ゲーム」と称する）内で利用可能なゲーム要素が報酬として設定されている。例えば、図２に示すゲームＡ用の優待券アイテムの報酬テーブルには、ゲームＡで利用可能なゲーム要素（「１００ポイント回復アイテム」、「強化アイテム」、「抽選キャラクタ」など）が報酬として設定されている。
【0029】
「１００ポイント回復アイテム」は、対応ゲーム内のミッションを実行するために必要なポイントを１００ポイント回復するアイテムである。「強化アイテム」は、対応ゲームのキャラクタの能力値などを増加させるためのアイテムである。「強化アイテム（小）」より「強化アイテム（大）」の方が大きい効果を有する（増加させる値が大きい）。「抽選キャラクタ」は、対応ゲーム内で利用可能なキャラクタを、予め決められた母集団から抽選によって決定する。「抽選キャラクタ（低レア）」より「抽選キャラクタ（高レア）」の方が母集団に含まれるキャラクタの希少度が高く且つ能力値も高い。
【0030】
ここでは、優待券アイテムの所有枚数「１～５枚」には、「１００ポイント回復アイテム×１」の報酬が付与されるように設定されている。つまり、トレードサーバ３０は、ユーザによる優待券アイテムの所有枚数が「１～５枚」の場合には、１個の「１００ポイント回復アイテム」を報酬として付与する。また、優待券アイテムの所有枚数「６～１０枚」には、上記（「１００ポイント回復アイテム×１」）に加え「強化アイテム（小）×１」の報酬が付与されるように設定されている。つまり、トレードサーバ３０は、ユーザによる優待券アイテムの所有枚数が５枚を超えて「６～１０枚」の場合には、１個の「１００ポイント回復アイテム」および１個の「強化アイテム（小）」を報酬として付与する。同様に、トレードサーバ３０は、ユーザによる優待券アイテムの所有枚数が１０枚を超えて「１１～２０枚」の場合には、上記（１個の「１００ポイント回復アイテム」および１個の「強化アイテム（小）」）に加え１個の「強化アイテム（大）」を報酬として付与する。
【0031】
このように、トレードサーバ３０は、ユーザによる優待券アイテムの所有枚数が所定の閾値（図３に示す報酬テーブルの例では、５枚、１０枚、２０枚、５０枚、１００枚、２００枚、４００枚、・・・）を超えることに応じて報酬を変更する。なお、報酬を変更する閾値および変更する報酬の内容は任意に設定できるが、閾値を超える度に（即ち、所有枚数が多いほど）、多くの報酬または価値の高い報酬が得られるようになる。
【0032】
報酬を付与する場合、トレードサーバ３０は、付与する報酬の情報（以下、「報酬付与情報」と称する）を対応ゲームのゲームサーバ２０へ通知することで、対応ゲーム内でユーザが利用可能になる。例えば、トレードサーバ３０は、ユーザが対応ゲームをプレイするために登録しているゲームアカウント（対応ゲーム内でのユーザの識別情報）を管理しており、ゲームアカウントと報酬を示す情報とを関連付けて報酬付与情報として対応ゲームのゲームサーバ２０へ送信する。ゲームサーバ２０は、報酬付与情報に基づいて、付与された報酬をゲーム内で利用可能に設定する。
【0033】
なお、報酬の内容は、上記に限らず任意であるが、対応ゲーム内で利用可能なアイテムやポイント、キャラクタなど、ユーザ（プレイヤ）がゲームを進める上で有利になり得るものである。
【0034】
また、図３に示す例では、所有枚数に応じて報酬が決められているが、図４に示すように、所有枚数に応じて用意された複数の報酬の中からユーザによって選択可能であっても良い。図４は、本実施形態に係る報酬テーブルの別の例を示す図である。この図４に示す例では、所有枚数ごとに２種類の報酬が関連付けられて設定されている。例えば、優待券アイテムの所有枚数「１～５枚」には、「１００ポイント回復アイテム×１」と「強化アイテム（小）×１」との２種類の報酬が設定されており、ユーザは、いずれか一方の報酬を選択して取得できる。
【0035】
このような所有枚数に応じた報酬付与が、定期的に行われる。例えば、トレードサーバ３０は、毎月１日の午前０時の時点といったように毎月１回、各ユーザの優待券アイテムの所有状況を参照して報酬の内容を決定して付与しても良い。なお、報酬の付与タイミングは毎月以外にも毎週や各月などであっても良いし、タイミングによって報酬内容が変更されても良い。例えば、毎週付与される報酬の内容は図３に示す報酬テーブルで決定されるが、毎月第１週の報酬のみ図３に示す報酬テーブルとは異なる報酬テーブル（例えば、図３より全体的に価値が高い報酬内容の報酬テーブル）によって報酬の内容が決定されても良い。
【0036】
図５は、本実施形態に係る報酬付与タイミングの一例を示す図である。この図に示す例では、報酬付与タイミングは毎週月曜日であるが、実線の丸を付けている第１週の月曜日は高価値の報酬、それ以外の破線の丸を付けている週の月曜日は通常の価値の報酬が付与される。例えば、このような報酬付与タイミングを予め特定してユーザに通知しておくことで、ユーザに対してトレードを行うことを促進する契機とすることができる。
【0037】
なお、優待券アイテムは、ゲーム内で利用するアイテムやキャラクタなどのゲーム要素とは異なり、これ自体、基本的にゲーム内において直接的な利用機会は無いものである。優待券アイテムを売買してもゲームにおいての優劣情報などには直接影響することは無いため、優待券アイテムは比較的に安易にトレードをし易いものとなる。
【0038】
なお、このような優待券アイテムは、最初はトレードサーバ３０で発行され、ユーザに販売される。その後はトレードサーバ３０を介してユーザ間でトレードされることになる。また、このような優待券アイテムは、ＮＦＴ（Ｎｏｎ Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ）であることが望ましい。ＮＦＴであれば、不正なコピーを抑制でき、優待券アイテムの価値を維持しやすくなる。
【0039】
〔サブ報酬について〕
上述した報酬は、純粋に所有枚数のみに応じて報酬の内容が決定されるものであるが、それとは別に優待券アイテム個別に報酬付与の機会を設けても良い。以下では、上記の図３または図４に示す報酬テーブルを用いて所有枚数に応じて付与する報酬のことを「メイン報酬」とし、メイン報酬とは別に優待券アイテム個別に報酬付与の機会を設けられている報酬のことを「サブ報酬」として区別して記載する。
上述した報酬は、純粋に所有枚数のみに応じて報酬の内容が決定されるものであるが、それとは別に優待券アイテム個別に報酬付与の機会を設けても良い。以下では、上記の図３または図４に示す報酬テーブルを用いて所有枚数に応じて付与する報酬のことを「メイン報酬」とし、メイン報酬とは別に優待券アイテム個別に報酬付与の機会を設けられている報酬のことを「サブ報酬」として区別して記載する。
【0040】
例えば優待券アイテムには、個別に設定された個別情報（パラメータ等）あり、この個別情報を利用してサブ報酬が付与される。例えば、メイン報酬は図３または図４に示すような報酬であるが、サブ報酬はメイン報酬と比して比較的価値の低い報酬であることが望ましい。
【0041】
一例として、図２に示すように、優待券アイテムにはシリアルナンバーが表示されている。前述したように、このシリアルナンバーは、優待券アイテムごとに付されたユニークな個別情報であり、同一のゲームに対応する優待券アイテムであっても優待券アイテムごとに異なる番号となる。トレードサーバ３０は、このシリアルナンバーを利用してサブ報酬を付与する。
【0042】
シリアルナンバーの利用の仕方は任意であるが、例えば、トレードサーバ３０は、シリアルナンバーの下一桁が特定の数字（例えば、「３」）である優待券アイテムを所有しているユーザに対してサブ報酬を付与しても良い。この場合、サブ報酬の付与対象となるシリアルナンバーの下一桁の数字は予め決められていても良いし、報酬付与のタイミングで抽選によって決められても良い。予め決められている場合には、下一桁の数字は、例えば０～９のいずれかの数字に固定されていても良いし、月ごとにその月の数（５月なら５）などであっても良い。なお、下一桁に限らず、下二桁、下三桁などとしても良い。
【0043】
また、所有している複数の優待券アイテムのシリアルナンバーが特定の数字の組み合わせとなる場合にサブ報酬を付与する仕様としても良い。例えば、トレードサーバ３０は、下二桁が「２６」の優待券アイテムと「４１」の優待券アイテムとの両方を所有しているユーザに対してサブ報酬を付与しても良い。この場合も下二桁の数字は、予め固定の数字に決められていても良いし、抽選などによって決められても良い。
【0044】
また、トレードサーバ３０は、シリアルナンバーが特定の数字の組み合わせとなる優待券アイテムを複数所有しているユーザに対しては、付与するサブ報酬を増加しても良い。
図６は、本実施形態に係るサブ報酬の報酬テーブルの一例を示す図である。この図に示す例では、特定の数字の組み合わせの所有数（所有組数）が増加することによって報酬の内容が指数関数的に増加している。例えば、トレードサーバ３０は、所有組数が１組の場合には２個の「１０ポイント回復アイテム」、所有組数が２組の場合には４個の「１０ポイント回復アイテム」、所有組数が３組の場合には８個の「１０ポイント回復アイテム」、所有組数が４組の場合には１６個の「１０ポイント回復アイテム」をそれぞれサブ報酬として付与する。
図６は、本実施形態に係るサブ報酬の報酬テーブルの一例を示す図である。この図に示す例では、特定の数字の組み合わせの所有数（所有組数）が増加することによって報酬の内容が指数関数的に増加している。例えば、トレードサーバ３０は、所有組数が１組の場合には２個の「１０ポイント回復アイテム」、所有組数が２組の場合には４個の「１０ポイント回復アイテム」、所有組数が３組の場合には８個の「１０ポイント回復アイテム」、所有組数が４組の場合には１６個の「１０ポイント回復アイテム」をそれぞれサブ報酬として付与する。
【0045】
このようにすることで、同一のゲームに対応する優待券アイテムであっても、同一の下二桁のシリアルナンバーの優待券アイテムを数多く所有していた方が多くのサブ報酬が付与されるため有利となる。よって、同一の下二桁のシリアルナンバーの優待券アイテムの収集意欲をユーザに持たせることができる。
【0046】
なお、上記例では同一の下二桁のシリアルナンバーの優待券アイテムを数多く所有していた方が多くのサブ報酬が付与される例を説明したが、同一の下二桁のシリアルナンバーの優待券アイテムを数多く所有していた方が価値の高いサブ報酬が得られるようにしてもよい。
【0047】
また、上記ではサブ報酬に利用する個別情報としてシリアルナンバーを利用する例を説明したが、シリアルナンバー以外にもスートなどのマークを優待券アイテムに付けて分類し、これを利用するようにしても良い。例えば、今月のサブ報酬はスートがハートで、かつ、シリアルナンバーの下一桁が３のもの、などとしても良い。また、野球ゲームやサッカーゲームでの選手のキャラクタを優待券アイテムに表示する場合、その選手の背番号などを利用しても良いし、所属チームのチーム名などを利用しても良い。
【0048】
また、サブ報酬の付与タイミングは、任意に設定することができるが、例えば、図５などを参照して説明したメイン報酬の付与タイミングと同じタイミングとしても良いし、メイン報酬の付与タイミングとは異なるタイミングとしても良い。
【0049】
また、サブ報酬は、付与回数または付与期間が制限されていても良い。例えば、メイン報酬の付与タイミングを毎週月曜日（１回／週）としたときに、サブ報酬の付与回数は３回までなどとしてもよい。この付与回数または付与期間は、優待券アイテムの所有者がトレードなどによって変更されるとリセットされ、再び３回まで報酬が付与されるようにしても良い。このようにすることで優待券アイテムのトレードを促進することができる。
【0050】
なお、図５に示す報酬付与タイミングの例において、メイン報酬の付与タイミングは第１週の月曜日（実線の丸を付けている部分）或いは毎月１日とし、サブ報酬の付与タイミングは第１週以外の週の月曜日（破線の丸を付けている部分）などとしても良い。
【0051】
シリアルナンバーは、基本的には、ユーザによって最初に運営から購入された時点でその優待券アイテムに付されるが、予めシリアルナンバーを付した優待券アイテムを用意しておいても良い。予めシリアルナンバーを付した優待券アイテムを用意しておく場合には、ユーザがシリアルナンバーを確認して購入できるようシリアルナンバーを提示しても良く、ユーザが購入する優待券アイテムを複数の優待券アイテム（のシリアルナンバー）の中から選択可能であっても良い。これにより、ユーザは、特定の組合せとなるシリアルナンバーの優待券アイテムを選択して購入することができる。
【0052】
以下、本実施形態に係るトレードシステム１の各部の構成について詳しく説明する。
〔ハードウェア構成〕
まず、本実施形態に係るトレードシステム１の各部のハードウェア構成について説明する。図７は、本実施形態に係るコンピュータの概略構成の一例を示すブロック図である。
例えば、図１に示す端末装置１０、ゲームサーバ２０、およびトレードサーバ３０のそれぞれは、図示するコンピュータ１００が備える各構成の一部又は全部を備えている。
〔ハードウェア構成〕
まず、本実施形態に係るトレードシステム１の各部のハードウェア構成について説明する。図７は、本実施形態に係るコンピュータの概略構成の一例を示すブロック図である。
例えば、図１に示す端末装置１０、ゲームサーバ２０、およびトレードサーバ３０のそれぞれは、図示するコンピュータ１００が備える各構成の一部又は全部を備えている。
【0053】
コンピュータ１００は、ハードウェア構成として、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２と、ＲＯＭ（Ｒｅｓａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３と、記憶装置１０４と、通信部１０５と、入力部１０６と、出力部１０７とを備えている。
【0054】
ＣＰＵ１０１は、ＲＯＭ１０３または記憶装置１０４に記憶されているプログラムを実行することにより各種の処理を実行するプロセッサである。
【0055】
ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムの読み込み領域として、又は、当該プログラムによる処理に使用するデータを書き込む作業領域として利用される。
【0056】
ＲＯＭ１０３は、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒy）やフラッシュＲＯＭなどの電気的に書き換え可能な不揮発性メモリで構成される。例えば、ＲＯＭ１０３には、システムプログラム、各種処理を実行するプログラムなどの少なくとも一部が記憶されている。
【0057】
記憶装置１０４は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、などを含んで構成される。例えば、記憶装置１０４には、システムプログラム、各種処理を実行するプログラムなどの少なくとも一部が記憶されてもよい。また、記憶装置１０４には、各種処理において必要なデータや取得するデータなどが記憶される。
【0058】
通信部１０５は、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）または有線ＬＡＮによりネットワークに接続して、他の機器や装置とデータ通信を行う。また、通信部１０５は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などのインターフェースを備えて周辺機器類とデータ通信を行ってもよい。
【0059】
入力部１０６は、例えば、キーボード、タッチパッド、タッチパネル、操作ボタン、マイクロフォン、カメラなどのいずれかの入力デバイスを備えている。
【0060】
出力部１０７は、液晶ディスプレイ、有機ＥＬディスプレイなどの表示部やスピーカなどの出力デバイスなどを備えている。なお、出力部１０７（例えば、表示部やスピーカなど）は、外付けの出力機器として接続されるものであっても良い。
【0061】
次に、トレードシステム１が備えるトレードサーバ３０の機能構成について説明する。
〔トレードサーバの機能構成〕
図８は、本実施形態に係るトレードサーバ３０の機能構成の一例を示すブロック図である。トレードサーバ３０は、ユーザ情報記憶部３１と、所有情報記憶部３２と、報酬情報記憶部３３と、アイテム付与部３４と、トレード部３５と、報酬付与部３６と、報酬変更部３７とを備えている。例えば、ユーザ情報記憶部３１と、所有情報記憶部３２と、報酬情報記憶部３３とは、図７の記憶装置１０４において各種情報を記憶する機能構成である。また、アイテム付与部３４と、トレード部３５と、報酬付与部３６と、報酬変更部３７とは、図７のＣＰＵ１０１がプログラムを実行することによる実現される機能構成である。
〔トレードサーバの機能構成〕
図８は、本実施形態に係るトレードサーバ３０の機能構成の一例を示すブロック図である。トレードサーバ３０は、ユーザ情報記憶部３１と、所有情報記憶部３２と、報酬情報記憶部３３と、アイテム付与部３４と、トレード部３５と、報酬付与部３６と、報酬変更部３７とを備えている。例えば、ユーザ情報記憶部３１と、所有情報記憶部３２と、報酬情報記憶部３３とは、図７の記憶装置１０４において各種情報を記憶する機能構成である。また、アイテム付与部３４と、トレード部３５と、報酬付与部３６と、報酬変更部３７とは、図７のＣＰＵ１０１がプログラムを実行することによる実現される機能構成である。
【0062】
ユーザ情報記憶部３１は、トレード用のユーザＩＤ（識別情報）を含むユーザ情報を記憶する。トレード用のユーザＩＤは、トレードシステム１においてユーザを特定するために必要な識別情報であり、トレードシステム１を利用開始する際のサインインでユーザが登録した情報に基づいて生成される。また、ユーザ情報記憶部３１は、トレード用のユーザＩＤと、ユーザがプレイしているゲームのゲームアカウントとを関連付けてユーザ情報として記憶する。このゲームアカウントは、ユーザに報酬を付与する際に使用される。
【0063】
なお、トレード用のユーザＩＤに関連付けられているゲームアカウントは、ユーザがプレイしている（ゲームサーバ２０にプレイヤとして登録している）ゲームのゲームアカウントのみであって、ユーザがプレイしたことのない（ゲームサーバ２０にプレイヤとして登録していない）ゲームのゲームアカウントは当然関連付けられていない。ゲームアカウントが１つも関連付けられていなくともトレード用のユーザＩＤさえあれば、優待券アイテムのトレードは可能である。ゲームアカウントを取得した後に優待券アイテムの所有状況（例えば、所有枚数）に応じて報酬が付与されるようになる。
【0064】
所有情報記憶部３２は、トレード用のユーザＩＤと、ユーザが購入またはトレードによって所有している優待券アイテムに関するアイテム情報とを関連付けてユーザの所有情報として記憶する。アイテム情報には、優待券アイテムのアイテムＩＤ（識別情報）が少なくとも含まれており、その他に、その優待券アイテムの枚数、シリアルナンバーなどの個別情報などが含まれても良い。なお、アイテムＩＤがシリアルナンバーであってもよい。
【0065】
報酬情報記憶部３３は、優待券アイテムの所有状況（例えば、所有枚数）に応じて付与されるメイン報酬に関する報酬情報、およびメイン報酬とは別に付与されるサブ報酬に関する報酬情報を記憶する。例えば、報酬情報記憶部３３は、メイン報酬に関する報酬情報として、図３または図４に示すメイン報酬の報酬テーブルを記憶する。また、報酬情報記憶部３３は、サブ報酬に関する報酬情報として、図６に示すサブ報酬の報酬テーブルを記憶する。また、報酬情報記憶部３３は、例えば、図５を参照して説明した報酬付与タイミングを示す付与タイミング情報を記憶する。
【0066】
アイテム付与部３４は、ユーザがトレードシステム１の運営から購入した優待券アイテムをユーザに付与する。例えば、アイテム付与部３４は、ユーザがトレードシステム１の運営から購入した優待券アイテムのアイテム情報とトレード用のユーザＩＤとを関連付けて、ユーザの所有情報として所有情報記憶部３２に記憶させる。これにより、トレードサーバ３０は、ユーザが運営から購入した優待券アイテムをユーザが所有する優待券アイテムとして管理する。
【0067】
トレード部３５は、複数のユーザのそれぞれに対応する端末装置１０と通信部１０５を介して通信し、各ユーザが所有している優待券アイテムをユーザ間でトレードするトレード処理を実行する。例えば、トレード部３５は、売却側（トレード元）のユーザが所有している優待券アイテムと購入側（トレード先）のユーザが所有している所定額の通貨とをトレードする。通貨は、ゲーム外で流通している通貨であり、法定通貨や暗号資産などを含む。また、これらの通貨と交換されたＷｅｂマネーや電子マネーなどであっても良い。また、上記の所定額は、売却側のユーザによって決められた売却金額であっても良いし、購入側のユーザによって決められた購入金額であってもよい。或いは、トレード部３５は、売却側と購入側の双方が売却金額および購入金額を決め、その金額の条件が合えばトレード処理を実行しても良い。
【0068】
トレード部３５は、トレード処理において、所有情報記憶部３２に記憶されている売却側のユーザの所有情報と購入側のユーザの所有情報とを変更する。具体的には、トレード部３５は、トレード対象の優待券アイテムのアイテム情報の関連付け先を、売却側のユーザのユーザＩＤから購入側のユーザのユーザＩＤに変更する。
【0069】
報酬付与部３６は、ユーザが所有する優待券アイテムに基づいて、上述したメイン報酬及びサブ報酬を付与する報酬付与処理を実行する。報酬付与部３６は、ユーザによる優待券アイテムの所有状況に応じて、対応ゲーム内で利用可能なメイン報酬を定期的に付与する。例えば、報酬付与部３６は、所有情報記憶部３２に記憶されている各ユーザの所有情報を参照し、各ユーザによる優待券アイテムの所有枚数（対応ゲームごとの所有枚数）を定期的に確認し、各ユーザによる優待券アイテムの所有枚数に応じたメイン報酬を定期的にユーザに付与する。
【0070】
例えば、報酬付与部３６は、報酬情報記憶部３３に記憶されている報酬テーブル（例えば、図３参照）を参照して、ユーザによる優待券アイテムの所有枚数が所定の閾値を超えることに応じて、多くの報酬または価値の高い報酬が得られるようにメイン報酬を変更して付与する。
【0071】
また、報酬付与部３６は、優待券アイテムに設定された個別情報（例えば、シリアルナンバー）に基づいて、メイン報酬とは別にサブ報酬を付与する。例えば、報酬付与部３６は、報酬情報記憶部３３に記憶されているサブ報酬の報酬テーブルを参照して、シリアルナンバーが特定の数字の組み合わせとなる優待券アイテムの所有数（所有組数）に応じて、所有組数が増加することに応じて、多くの報酬が得られるようにサブ報酬を付与する。なお、報酬付与部３６は、所有組数が増加することに応じて、価値の高い報酬が得られるようにサブ報酬を付与してもよい。
【0072】
報酬付与部３６は、報酬（メイン報酬およびサブ報酬）を付与する場合には、ユーザ情報記憶部３１に記憶されているユーザ情報を参照して、付与するユーザのゲームアカウントと報酬を示す情報とを関連付けて報酬付与情報として対応ゲームのゲームサーバ２０へ送信する。
【0073】
なお、メイン報酬およびサブ報酬の内容は、報酬の付与タイミングによって可変であってもよい。報酬変更部３７は、ゲームのアップデートに従って、新規のゲーム要素またはゲーム内での利用価値が高くなったゲーム要素などに報酬の内容を変更してもよい。
【0074】
例えば、報酬変更部３７は、ゲームの運営側からのトリガに応じて報酬の内容を変更する。具体的には、報酬変更部３７は、ゲームサーバ２０から報酬テーブル（図３または図４参照）の更新データを取得し、報酬情報記憶部３３に記憶されている報酬テーブルを、取得した更新データで更新してもよい。これにより、メイン報酬およびサブ報酬の価値を保つことができるため、優待券アイテムのトレードを促進できる。なお、報酬変更部３７は、ゲームサーバ２０以外から報酬テーブルの更新データを取得してもよい。例えば、ゲームの運営側がゲーム外でゲームに関する情報を提供するサーバをゲームサーバ２０以外に有してもよく、報酬変更部３７は、当該ゲーム外でゲームに関する情報を提供するサーバから報酬テーブルの更新データを取得してもよい。また、複数のゲームの運営会社が共同でゲームに関する情報を提供するサーバを有してもよく、報酬変更部３７は、当該複数のゲームの運営会社が共同で有しているサーバから報酬テーブルの更新データを取得してもよい。
【0075】
〔トレード処理の動作〕
次に、トレードシステム１においてユーザ間で優待券アイテムをトレードするトレード処理の動作について説明する。
図９は、本実施形態に係るトレード処理の一例を示すフローチャートである。
次に、トレードシステム１においてユーザ間で優待券アイテムをトレードするトレード処理の動作について説明する。
図９は、本実施形態に係るトレード処理の一例を示すフローチャートである。
【0076】
売却側（トレード元）のユーザの端末装置１０－１は、ユーザが所有している優待券アイテムの中からユーザ操作によりトレード対象の優待券アイテムを選択する。例えば、端末装置１０－１は、トレードサーバ３０の所有情報記憶部３２記憶されている所有情報からユーザが所有している優待券アイテムの一覧を取得し、トレード対象の優待券アイテムを選択可能な選択画面を表示する。そして、端末装置１０－１は、選択画面に対するユーザ操作によりトレード対象の優待券アイテムを選択する（ステップＳ１０１）。
【0077】
次に、端末装置１０－１は、トレード対象の優待券アイテムの売買金額（ここでは、売却金額）の入力を受け付ける（ステップＳ１０３）。例えば、端末装置１０－１は、売却金額の入力を受け付ける入力画面を表示し、入力画面に対するユーザ操作により売却金額の入力を受け付ける。
【0078】
端末装置１０－１は、ステップＳ１０１でトレード対象の優待券アイテムが選択され、ステップＳ１０３で売却金額が入力されると、選択された優待券アイテムのアイテム情報と売却金額と売却側のユーザＩＤとを含む出品情報を生成してトレードサーバ３０へ送信し、トレード対象の優待券アイテムを出品する（ステップＳ１０５）。
【0079】
トレードサーバ３０は、端末装置１０－１から出品情報を取得すると、複数のユーザのそれぞれから取得した出品情報のリストに加えて更新する（ステップＳ３０１）。
【0080】
購入側（トレード先）のユーザの端末装置１０－２は、トレードサーバ３０から出品情報のリストを取得する（ステップＳ１１１）。例えば、端末装置１０－２は、取得した出品情報のリストに基づいて、各ユーザによってトレード対象として出品されている優待券アイテムと売却金額とを関連付けて表示する。
【0081】
端末装置１０－２は、出品されている優待券アイテム（出品アイテム）の中からユーザが購入したい優待券アイテム（購入アイテム）を、ユーザ操作に基づいて選択する（ステップＳ１１３）。
【0082】
端末装置１０－２は、ステップＳ１１３で購入アイテムが選択されると、選択された購入アイテム（優待券アイテム）のアイテム情報と購入側のユーザＩＤとを含む購入申請情報を生成してトレードサーバ３０へ送信し、購入の申し込みをする（ステップＳ１１７）。
【0083】
トレードサーバ３０は、端末装置１０－２から購入申請情報を取得すると、ステップＳ１１３で選択された購入アイテム（優待券アイテム）と購入側のユーザが所有している所定額の通貨（売却金額に相当する通貨）とをトレードするトレード処理を実行する（ステップＳ３０３）。例えば、トレードサーバ３０は、所有情報記憶部３２に記憶されている所有情報において、購入アイテム（優待券アイテム）のアイテム情報の関連付け先を、売却側のユーザのユーザＩＤから購入側のユーザのユーザＩＤに変更する。
【0084】
なお、トレードサーバ３０は、端末装置１０－２から購入申請情報を取得すると、購入の申し込みがあったことを売却側のユーザの端末装置１０－１へ通知し、売却の許可をとった上でトレード処理を実行してもよい。
【0085】
図１０は、本実施形態に係るトレード処理の別の例を示すフローチャートである。図９に示すトレード処理の例では売却側のユーザが売買金額（売却金額）を決めたが、図１０に示すトレード処理は、購入側のユーザが売買金額（購入金額）を決める例を示している。なお、この図１０において、図９の各部に対応する処理には同一の符号を付している。
【0086】
売却側（トレード元）のユーザの端末装置１０－１は、ユーザが所有している優待券アイテムの中からユーザ操作によりトレード対象の優待券アイテムを選択する。例えば、端末装置１０－１は、トレードサーバ３０の所有情報記憶部３２記憶されている所有情報からユーザが所有している優待券アイテムの一覧を取得し、トレード対象の優待券アイテムを選択可能な選択画面を表示する。そして、端末装置１０－１は、選択画面に対するユーザ操作によりトレード対象の優待券アイテムを選択する（ステップＳ１０１）。
【0087】
端末装置１０－１は、ステップＳ１０１でトレード対象の優待券アイテムが選択されると、選択された優待券アイテムのアイテム情報と売却側のユーザＩＤとを含む出品情報を生成してトレードサーバ３０へ送信し、トレード対象の優待券アイテムを出品する（ステップＳ１０５）。
【0088】
トレードサーバ３０は、端末装置１０－１から出品情報を取得すると、複数のユーザのそれぞれから取得した出品情報のリストに加えて更新する（ステップＳ３０１）。
【0089】
購入側（トレード先）のユーザの端末装置１０－２は、トレードサーバ３０から出品情報のリストを取得する（ステップＳ１１１）。例えば、端末装置１０－２は、取得した出品情報のリストに基づいて、各ユーザによってトレード対象として出品されている優待券アイテムを表示する。
【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】
付記Ａ７の構成によれば、ユーザが所有するアイテム（例えば、優待券アイテム）の個別情報（例えば、シリアルナンバー）によって付与する第１報酬（例えば、メイン報酬）を異ならせることができるため、例えば特定の個別情報のアイテムを所有したいといったユーザの要求によってトレードを促進することができる。
【0193】
（付記Ａ８）また、本発明の一態様は、付記Ａ１に記載のプログラムであって、前記所定額は、トレード元（例えば、売却側）のユーザまたはトレード先（例えば、購入側）のユーザによってきめられた額である。
【0194】
付記Ａ８の構成によれば、トレード対象のアイテム（例えば、優待券アイテム）をトレードする際に、トレード元（例えば、売却側）またはトレード先（例えば、購入側）のユーザにとっての価値に応じた売買金額でトレードすることができる。
【0195】
（付記Ａ９）また、本発明の一態様は、付記Ａ１に記載のプログラムであって、前記アイテム（例えば、優待券アイテム）は、ＮＦＴ（Ｎｏｎ－Ｆｕｎｇｉｂｌｅ Ｔｏｋｅｎ）である。
【0196】
付記Ａ９の構成によれば、トレード対象のアイテム（例えば、優待券アイテム）の不正なコピーを抑制でき、優待券アイテムの価値を維持しやすくすることができる。
【0197】
（付記Ａ１０）また、本発明の一態様は、付記Ａ１に記載のプログラムであって、前記アイテム（例えば、優待券アイテム）は、前記ゲーム内において直接的な利用ができない。
【0198】
付記Ａ１０の構成によれば、トレード対象のアイテム（例えば、優待券アイテム）についてはゲーム内の需要に左右されることがなく、価値を維持できる。
【0199】
（付記Ａ１１）また、本発明の一態様は、付記Ａ１に記載のプログラムであって、前記アイテム（例えば、優待券アイテム）には、前記報酬の内容ごとに異なるアイテムが含まれる。例えば、報酬として回復アイテムが付与される優待券アイテム、強化アイテムが付与される優待券アイテム、抽選券が付与される優待券アイテムなどがあっても良い。
【0200】
付記Ａ１１の構成によれば、ユーザが取得したい報酬が付与されるアイテム（例えば、優待券アイテム）を所有したいといったユーザの要求によってトレードを促進することができる。
【0201】
（付記Ａ１２）また、本発明の一態様に係るトレード処理方法は、複数のユーザのそれぞれに対応する端末装置（１０）と通信して、各ユーザが所有しているアイテム（例えば、優待券アイテム）をユーザ間でトレードするトレード処理方法であって、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬（例えば、メイン報酬）を定期的に付与するステップ（Ｓ３１５）と、第１ユーザ（例えば、売却側ユーザ）が所有している前記アイテムと第２ユーザ（例えば、購入側ユーザ）が所有している所定額（売買金額）の通貨とをトレードするステップ（Ｓ３０３）と、を含む。
【0202】
付記Ａ１２の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0203】
（付記Ａ１３）また、本発明の一態様に係るトレードシステム（１）は、複数のユーザのそれぞれに対応する端末装置（１０）と通信して、各ユーザが所有しているアイテム（例えば、優待券アイテム）をユーザ間でトレードするトレード処理を実行するトレードシステムであって、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬（例えば、メイン報酬）を定期的に付与する報酬付与部（３６、Ｓ３１５）と、第１ユーザ（例えば、売却側ユーザ）が所有している前記アイテムと第２ユーザ（例えば、購入側ユーザ）が所有している所定額の通貨とをトレードするトレード部（３５、Ｓ３０３）と、を備える。
【0204】
付記Ａ１３の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0205】
［付記Ｂ］
以上の記載から本発明は例えば以下のようにも把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。
以上の記載から本発明は例えば以下のようにも把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。
【0206】
（付記Ｂ１）本発明の一態様に係るトレードシステム（１）は、複数のユーザのそれぞれに対応する端末装置（１０）と通信して、各ユーザが所有しているアイテム（例えば、優待券アイテム）をユーザ間でトレードするトレード処理を実行するトレードシステムであって、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬（例えば、メイン報酬）を定期的に付与する報酬付与部（３６、Ｓ３２９）と、第１ユーザ（例えば、売却側ユーザ）が所有しているアイテムと第２ユーザ（例えば、購入側ユーザ）が所有している所定額の通貨とをトレードするトレード部（３５、Ｓ３０３）と、前記アイテムに関連付けられているゲームのゲーム状況を取得するゲーム状況取得部（３８、Ｓ３２５）と、前記ゲーム状況に応じて前記報酬の内容を変更する報酬変更部（３７、Ｓ３２７）と、を備える。
【0207】
付記Ｂ１の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲームのゲーム状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0208】
（付記Ｂ２）また、本発明の一態様は、付記Ｂ１に記載のトレードシステム（１）であって、前記ゲーム状況は、前記ゲームに参加しているユーザの数についての情報に基づく。
【0209】
付記Ｂ２の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲームへのユーザの参加状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0210】
（付記Ｂ３）また、本発明の一態様は、付記Ｂ１に記載のトレードシステム（１）であって、前記ゲーム状況は、前記ゲーム内で販売されているゲーム要素がユーザにより購入された数または金額についての情報に基づく。ゲーム要素とは、ゲーム内で利用可能なゲームキャラクタ、回復アイテムなどのゲームアイテム、ゲームキャラクタまたはゲームアイテムの抽選券（抽選（ガチャ）の実行権利、有償通貨）などである。
【0211】
付記Ｂ３の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲーム内で販売されているゲーム要素の購入状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0212】
（付記Ｂ４）また、本発明の一態様は、付記Ｂ１に記載のトレードシステム（１）であって、前記アイテム（例えば、優待券アイテム）には対応するゲームがあり、前記ゲーム状況は、ゲーム要素がユーザ間で取引された回数または金額についての情報に基づく。
【0213】
付記Ｂ４の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲーム内におけるゲーム要素の取引状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0214】
（付記Ｂ５）また、本発明の一態様は、付記Ｂ１に記載のトレードシステム（１）であって、前記ゲーム状況は、前記ゲームの進捗についての情報に基づく。前記ゲームの進捗とは、例えばゲーム内でプレイヤが遂行するミッションの達成状況などである。
【0215】
付記Ｂ５の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲームの進捗状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0216】
（付記Ｂ６）また、本発明の一態様は、付記Ｂ２から付記Ｂ５のいずれか一項に記載のトレードシステム（１）であって、前記ゲーム状況は、前記ゲームに関する情報の時間経過に伴う変化（例えば、前月比）に基づく。ゲームに関する情報の時間経過に伴う変化とは、例えばゲームの参加人数の変化、ゲーム要素がユーザにより購入された数または金額の変化、ゲーム要素がユーザ間で取引された回数または金額の変化、ミッションの達成状況の変化などである。
【0217】
付記Ｂ６の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲームに関する情報の時間経過に伴う変化に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0218】
（付記Ｂ７）また、本発明の一態様は、付記Ｂ１に記載のトレードシステム（１）であって、前記ゲーム状況取得部は、前記ゲーム状況を管理するゲームサーバ（２０）から前記ゲーム状況を取得する。
【0219】
付記Ｂ７の構成によれば、トレード対象のアイテム（例えば、優待券アイテム）に対応する複数のゲームのゲーム状況を管理して、各ゲームのゲーム状況に応じて報酬の内容を変更することができる。
【0220】
（付記Ｂ８）また、本発明の一態様に係るトレード処理方法は、複数のユーザのそれぞれに対応する端末装置（１０）と通信して、各ユーザが所有しているアイテム（例えば、優待券アイテム）をユーザ間でトレードするトレード処理方法であって、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬（例えば、メイン報酬）を定期的に付与するステップ（Ｓ３１５）と、第１ユーザ（例えば、売却側ユーザ）が所有しているアイテムと第２ユーザ（例えば、購入側ユーザ）が所有している所定額の通貨とをトレードするステップ（Ｓ３０３）と、前記アイテムに関連付けられているゲームのゲーム状況を取得するステップ（Ｓ３２５）と、前記ゲーム状況に応じて前記報酬の内容を変更するステップ（Ｓ３２７）と、を含む。
【0221】
付記Ｂ８の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲームのゲーム状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【0222】
（付記Ｂ９）また、本発明の一態様に係るプログラムは、複数のユーザのそれぞれに対応する端末装置（１０）と通信して、各ユーザが所有しているアイテム（例えば、優待券アイテム）をユーザ間でトレードするトレード処理を実行するプログラムであって、コンピュータに、ユーザによる前記アイテムの所有状況に応じて、ゲーム内で利用可能な報酬（例えば、メイン報酬）を定期的に付与するステップ（Ｓ３１５）と、第１ユーザ（例えば、売却側ユーザ）が所有しているアイテムと第２ユーザ（例えば、購入側ユーザ）が所有している所定額の通貨とをトレードするステップ（Ｓ３０３）と、前記アイテムに関連付けられているゲームのゲーム状況を取得するステップ（Ｓ３２５）と、前記ゲーム状況に応じて前記報酬の内容を変更するステップ（Ｓ３２７）と、を実行させる。
【0223】
付記Ｂ９の構成によれば、ユーザによるアイテム（例えば、優待券アイテム）の所有状況に応じてゲーム内で利用可能な報酬を定期的（例えば、毎月、毎週など）に付与するとともに、付与する報酬の内容を当該ゲームのゲーム状況に応じて変更するため、ユーザがアイテムをトレードして所有することの価値が維持され、ゲームにおけるトレードを促進することができる。
【符号の説明】
【0224】
１ トレードシステム、１０ 端末装置、２０ ゲームサーバ、３０，３０Ａ トレードサーバ、３１ ユーザ情報記憶部、３２ 所有情報記憶部、３３ 報酬情報記憶部、３４ アイテム付与部、３５ トレード部、３６ 報酬付与部、３７ 報酬変更部、３８ ゲーム状況取得部、１００ コンピュータ、１０１ ＣＰＵ、１０２ ＲＡＭ、１０３ ＲＯＭ、１０４ 記憶装置、１０５ 通信部、１０６ 入力部、１０７ 出力部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】