JP7455176B1 - プログラム、方法、情報処理装置、システム - Google Patents

Abstract

【課題】デッキを作成する興趣性を向上させる。
【解決手段】 プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムである。プログラムは、プロセッサに、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行させる。
【選択図】図２０

Description

本開示は、プログラム、方法、情報処理装置、システムに関する。

近年、デジタルカードを用いてプレイするデジタルＴＣＧ（Trading Card Game）が注目されている。

特開２０１３－０３４６２４号公報

デジタルＴＣＧでは、他プレイヤ又はＣＰＵと対戦するために、所有する複数のデジタルカードを組み合わせてデッキを構築する。強いデッキ、個性的なデッキ等、デッキを構築することは、ＴＣＧの楽しみの一つである。

特許文献１では、プレイヤがデッキを作成し、作成したデッキを、使用するゲーム毎に登録することは記載されている。しかしながら、特許文献１では、デッキを作成する興趣性を向上させることについては述べられていない。

本開示の目的は、デッキを作成する興趣性を向上させることである。

プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムである。プログラムは、プロセッサに、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行させる。

本開示によれば、デッキを作成する興趣性を向上させることができる。

本実施形態に係るＴＣＧの対戦を準備する局面を示す図である。 本実施形態に係るＴＣＧの対戦を開始しようとする局面を示す図である。 各ユーザがＴＣＧの対戦を進行させている局面を示す図である。 システム１の全体構成の例を示すブロック図である。 図４に示す端末装置１０の構成例を表すブロック図である。 サーバ２０の機能的な構成の例を示す図である。 カード情報１８２のデータ構造を示す図である。 デッキ情報１８３のデータ構造を示す図である。 ユーザ情報テーブル２０２１のデータ構造を示す図である。 カードマスタテーブル２０２２のデータ構造を示す図である。 デッキ情報テーブル２０２３のデータ構造を示す図である。 対戦情報テーブル２０２４のデータ構造を示す図である。 特典情報テーブル２０２５のデータ構造を示す図である。 端末装置１０に表示されるデッキ一覧の例を表す模式図である。 ディスプレイ１４１の表示例を表す模式図である。 端末装置１０に表示される、デッキ２の編集画面の例を表す模式図である。 ユーザがデッキを登録する際の端末装置１０とサーバ２０との動作の例を説明する図である。 ディスプレイ１４１の表示例を表す模式図である。 デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。 ディスプレイ１４１の表示例を表す模式図である。 ディスプレイ１４１の表示例を表す模式図である。 デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。 ディスプレイ１４１の表示例を表す模式図である。 デッキと、デッキの作成者とを対応付ける際のサーバ２０の動作の例を示すフローチャートである。 ディスプレイ１４１の表示例を表す模式図である。 デッキの対戦情報を管理する際の端末装置１０とサーバ２０との動作の例を説明する図である。 ディスプレイ１４１の表示例を表す模式図である。 コンピュータ９０の基本的なハードウェア構成を示すブロック図である。

以下、図面を参照しつつ、本開示の実施形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称及び機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

＜概略＞
本実施形態に係るプログラムは、プレイヤが作成したデッキが、初めて作成されたデッキであることを含む所定の条件を満たす場合、当該デッキを、当該デッキを初めて作成した第１プレイヤと関連付けて登録する。登録したデッキに関する情報は、第１プレイヤに関する情報を含み、第１プレイヤ、又は第１プレイヤ及びプレイヤからのアクセスにより公開される。

まず、本実施形態に係るＴＣＧの概要について説明する。次いで、カードの管理システムについて説明する。

＜０ ＴＣＧの概要＞
図１は、本実施形態に係るＴＣＧの対戦を準備する局面を示す図である。図２は、本実施形態に係るＴＣＧの対戦を開始しようとする局面を示す図である。図３は、各ユーザがＴＣＧの対戦を進行させている局面を示す図である。

ユーザは、プレイマット３０を配置し、ＴＣＧの対戦に使用するカードを組み合わせて構築したデッキを用い、ＴＣＧの対戦を行う。

＜０．１ プレイマット３０の構成＞
図１を参照して、各ユーザがＴＣＧの対戦で使用する各種用品について説明する。図１に示すように、ユーザ５Ａ（第１ユーザ）と、ユーザ５Ｂ（第２ユーザ）とが、ＴＣＧの対戦を開始するにあたり、ユーザ５Ａとユーザ５Ｂとの間にプレイマット３０を配置する。プレイマット３０は、デッキに含まれるカードを配置するためのものである。各ユーザは、プレイマット３０に山札等としてカードを配置し、山札からカードを手札に加えつつＴＣＧの対戦を進行させる。

プレイマット３０の構成について説明する。プレイマット３０は、例えば、カードを配置する位置が表されるマットを含む。プレイマット３０は、例えば、山札配置部３１Ａ及び山札配置部３１Ｂ（以下、「山札配置部３１」と総称することもある）と、準備カード配置部３２Ａ及び準備カード配置部３２Ｂ（以下、「準備カード配置部３２」と総称することもある）と、勝敗条件カード配置部３３Ａ及び勝敗条件カード配置部３３Ｂ（以下、「勝敗条件カード配置部３３」と総称することもある）と、バトルカード配置部３４Ａ及びバトルカード配置部３４Ｂ（以下、「バトルカード配置部３４」と総称することもある）と、消費カード配置部３５Ａ及び消費カード配置部３５Ｂ（以下、「消費カード配置部３５」と総称することもある）と、を含む。

図３示すように、ＴＣＧの対戦において、各ユーザは、山札からカードを手札に補充しつつ、カード同士のバトルを進行させる。図３の例では、ユーザ５Ａは、手札９３Ａ（図３の例では手札に２枚のカード）を有している。ユーザ５Ｂは、手札９３Ｂ（図３の例では手札に３枚のカード）を有している。

山札配置部３１は、各ユーザが所有するデッキを構成するカードのうちいずれかを、山札として配置するための領域である。山札配置部３１Ａは、ユーザ５Ａがカードを山札として配置するための領域である。山札配置部３１Ｂは、ユーザ５Ｂがカードを山札として配置するための領域である。

図２に示すように、各ユーザがＴＣＧの対戦を開始するにあたり、各ユーザは、デッキを構成するカードを混ぜ、カードを裏向きにして山札配置部３１に配置する。ユーザ５Ａは、山札配置部３１Ａにカードを山札９１Ａとして配置する。ユーザ５Ｂは、山札配置部３１Ｂにカードを山札９１Ｂとして配置する。

準備カード配置部３２は、対戦相手のカードと戦うことができるカードを準備するための領域である。各ユーザは、準備カード配置部３２に配置されているカードと、バトルカード配置部３４に配置されているカードとを入れ替えつつ、バトルカード配置部３４に配置されているカード同士を戦わせる。

図２に示すように、ＴＣＧの対戦を開始する前においては、準備カード配置部３２、バトルカード配置部３４にはカードは配置されていない。一方、図３に示すように、ＴＣＧの対戦が進行すると、各ユーザが準備カード配置部３２、バトルカード配置部３４にカードを配置し、バトルカード配置部３４にカード同士を戦わせる。各ユーザは山札から手札を補充しつつ、手札の中からバトルに使用するカードを準備カード配置部３２、バトルカード配置部３４に配置する。ユーザ５Ａは、準備カード配置部３２Ａにカードを配置する。ユーザ５Ｂは、準備カード配置部３２Ｂにカードを配置する。

勝敗条件カード配置部３３は、各プレイヤが勝利条件をどの程度満たしているかを示す領域である。本実施形態では、勝敗条件カード配置部３３に、各プレイヤが山札から所定枚数のカードを裏向きにして勝敗条件カード配置部３３に配置する。図２に示すように、ユーザ５Ａは、勝敗条件カード配置部３３Ａにカードを配置する。ユーザ５Ｂは、勝敗条件カード配置部３３Ｂにカードを配置する。

バトルカード配置部３４は、対戦相手のカードと戦うカードを配置するための領域である。ユーザ５Ａは、バトルカード配置部３４Ａにカードを配置する。ユーザ５Ｂは、バトルカード配置部３４Ｂにカードを配置する。本実施形態では、基本的には、バトルカード配置部３４Ａに配置されるカードと、バトルカード配置部３４Ｂに配置されるカードとが、各カードに設定される体力、攻撃力、カードに示されるキャラクタの属性、弱点の属性、その他のパラメータに基づいて戦う。バトルカード配置部３４に配置されているカードは、攻撃力・カードの属性・弱点等に応じたダメージが与えられ、与えられたダメージが体力から減らされていく。攻撃を受ける等によりカードに設定される体力が失われると、カードがバトルカード配置部３４から退場させられ、消費カード配置部３５に配置される。

消費カード配置部３５は、ＴＣＧの対戦で消費したカードを配置するための領域である。例えば、バトルで体力を失ったカード、効果を発動させたカード等が消費カード配置部３５に配置される。図３に示すように、ユーザ５Ａは、消費カード配置部３５Ａに、対戦で消費したカードを、カード９２Ａとして配置する。ユーザ５Ｂは、消費カード配置部３５Ｂに、対戦で消費したカードを、カード９２Ｂとして配置する。

消費カード配置部３５に配置されたカードは、所定のカードの効果を発動させることで、山札配置部３１、準備カード配置部３２、手札等に配置させることが可能である。プレイマット３０は、消費カード配置部３５の他に、対戦で消費したカードを配置するための領域をさらに有してもよい。当該領域を、例えば、第２消費カード配置部と称する。第２消費カード配置部に配置されたカードは、所定のカードの効果を発動させても、場に戻ってくることはない。なお、第２消費カード配置部に配置されたカードの枚数によって、所定の効果が発動するようにしてもよい。

＜０．２ ＴＣＧで使用するカードの種類＞
本実施形態のＴＣＧでは、カードの種類として、（ｉ）バトルに使用することができるキャラクタカードと、（ｉｉ）キャラクタカードに関連付けて使用する行動力カード（エネルギーカード）と、（ｉｉｉ）対戦中に特定の効果を発揮させる効果カード（サポートカード、グッズカード、スタジアムカード等）とがある。

（ｉ）キャラクタカードには、ユーザが山札からカードを引いて手札に加えると、準備カード配置部３２又はバトルカード配置部３４に配置することができるカード（「無条件カード」とも言う）と、特定の条件を満たすことにより、準備カード配置部３２又はバトルカード配置部３４に配置することができるカード（「条件付きカード」とも言う）とが含まれる。

（ｉＡ）例えば、条件付きカードは、条件付きカードに関連する無条件カードを配置することを条件として、配置することができる。例えば、キャラクタの進化になぞらえて、まず無条件カードをプレイマット３０に配置すること等により対戦相手のユーザに提示したうえで、当該無条件カードに関連する条件付きカードをプレイマット３０に配置する。このような条件付きカードは、無条件カードから進化させたものとして「進化キャラクタ」とも称されることがある。また、無条件カードは、「進化キャラクタ」を配置するための元となるキャラクタともいえるため、「たねキャラクタ」とも称されることがある。

（ｉＢ）例えば、条件付きカードは、特定のカードを消費して消費カード配置部３５に移動させることにより、準備カード配置部３２又はバトルカード配置部３４に配置できる。具体的には、特定のカードとして、プレイマット３０に配置されている無条件カードを消費して（消費カード配置部３５に移動させて）、条件付きカードを準備カード配置部３２又はバトルカード配置部３４に配置できる、としてもよい。

例えば、条件付きカードは、プレイマット３０にユーザが配置した単数又は複数のキャラクタカードと引き換えに、準備カード配置部３２又はバトルカード配置部３４に配置できる。例えば、各キャラクタカードに、カードに示されるキャラクタの攻撃力等の個々のパラメータとは別に、キャラクタの総合的な性能を示すパラメータ（例えば、進化レベルなど）が付されている場合に、ユーザが配置したキャラクタカードの進化レベルの値に対応した進化レベルを有する条件付きカードを配置してもよい。例えば、進化レベル１のキャラクタと進化レベル２のキャラクタとをプレイマット３０に配置した状態で、これらキャラクタのカードに重ねて（または、これらのキャラクタカードと引き換えに）、進化レベル３の条件付きカードを配置できる。

この他にも、条件付きカードにより定められる複数のキャラクタカードと引き換えに、当該条件付きカードをバトルに参加させることができる、としてもよい。このとき、キャラクタカードとは異なる後述する補助カードを消費して、条件付きカードをバトルに参加させることとしてもよい。例えば、補助カードに示される効果として、プレイマット３０のバトルカード配置部３４、消費カード配置部３５等にある特定の無条件カードと引き換えに、特定の条件付きカードをバトルに参加させられることが定められている。

（ｉＣ）これらカードには、上記キャラクタカード、後述する行動力カード、補助カードのうち複数を兼ねるものも含まれる。例えば、キャラクタカードとしても使用でき、補助カードとしても使用できる特殊なカードが含まれることとしてもよい。ユーザは、当該特殊なカードを、キャラクタカードを配置すべき位置(例えば準備カード配置部３２、バトルカード配置部３４)に配置した場合は、キャラクタカードとして使用することができる。

（ｉｉ）行動力カード（エネルギーカード）は、ユーザが山札からカードを引いて手札に加えたのち、キャラクタカードと関連付けてプレイマット３０に配置することにより、キャラクタカードに示される所定の行動を行うことを可能とするものである。行動力カードをキャラクタカードに関連付ける操作は、例えば、ユーザのターン中に行えることとしてもよい。例えば、プレイマット３０に配置されるキャラクタカードの近傍に行動力カードを配置することで、キャラクタカードに行動力カードを関連付けたとしてもよい。また、ターン中に行動力カードをキャラクタカードに関連付けられる回数は制限があってもよい。例えば、ユーザのターン中に１回、プレイマット３０に配置されるキャラクタカードのいずれかに、手札中の行動力カードを関連付けるよう配置することができる。例えば、キャラクタカードに、第１の攻撃アクションと、第２の攻撃アクションとが設定されているとする。第１の攻撃アクションは、キャラクタカードに１枚の行動力カードが関連付けられている場合に使用可能であり、第２の攻撃アクションは、１枚の行動力カードでは足りず２枚の行動力カードがキャラクタカードに関連付けられている場合に使用可能であるとしてもよい。

キャラクタカードがバトルにより体力値が尽きる等により、バトルカード配置部３４から退場することとなった場合、当該キャラクタカードに関連付けられている行動力カードを当該対戦中で使用不可とすることとしてもよい。また、当該キャラクタカードに関連付けられている行動力カードを消費カード配置部３５へ移動させてもよい。

（ｉｉｉ）対戦を補助する補助カードには、ユーザの手札にある限り、ユーザがターン中に何枚でも使用できるカード種と、ターン中に１枚だけ使用できるカード種とが含まれる。これら補助カードには、ユーザが補助カードの効果を使用することを宣言することで効果を発揮させるものも含まれる。

なお、補助カードとして、予めプレイマット３０の所定の位置（本実施形態では、当該所定の位置については図示していない）に、裏向きにするなどして配置したうえで、ユーザが補助カードの使用を発声等により宣言することで補助カードの効果を発揮させるものも含まれる。

＜０．３ ＴＣＧの対戦ルールの概要＞
以上のように、ＴＣＧの対戦で使用するプレイマット３０と、カードの種類とについて説明した。次に、ＴＣＧの対戦ルールについて詳細に説明する。

本実施形態に示すＴＣＧでは、上記のように、各ユーザがバトルカード配置部３４Ａ、バトルカード配置部３４Ｂに配置したカードに基づき攻撃または防御（バトル）を行ってＴＣＧの対戦を進行させるものとする。ＴＣＧの対戦は、ユーザがターン毎に交互に行動して進行するものとする。例えば、第１ユーザが行動した後にターンを終えると、第２ユーザのターンとなる。第２ユーザは自身のターンで行動し、行動が終了すると、第１ユーザのターンとなる。

各ユーザは、ターンが到来するごとに、山札から所定枚数のカードを引いて手札に加える。

各ユーザは、手札にあるカードのうち、対戦相手のユーザのカードへの攻撃または防御に使用するカード（キャラクタカード）の候補を準備カード配置部３２に配置する。

ユーザ５Ａは、準備カード配置部３２Ａに並べられたカードと、バトルカード配置部３４Ａに並べられたカードとを、ユーザ５Ａのターン中に入れ替えることができる。また、ユーザ５Ｂは、準備カード配置部３２Ａに並べられたカードと、バトルカード配置部３４Ａに並べられたカードとを、ユーザ５Ｂのターン中に入れ替えることができる。

勝敗条件カード配置部３３Ａと勝敗条件カード配置部３３Ｂとは、上記のように、それぞれのユーザが対戦に勝利する条件に対してどの程度の進捗があるかを各ユーザに通知するための領域である。ここで、ユーザが対戦に勝利する条件としては、例えば、勝敗条件カード配置部３３Ａ又は勝敗条件カード配置部３３Ｂに配置されるカードが全て回収されることとしてもよい。すなわち、勝敗条件カード配置部３３Ａ又は勝敗条件カード配置部３３Ｂのいずれかにおいて、全てのカードが回収されたことにより、勝敗が決することとしてもよい。

例えば、各ユーザが、ＴＣＧの対戦に先立ち、山札から勝敗条件カード配置部３３に所定枚数のカードを配置する。すなわち、ユーザ５Ａは、山札９１Ａから所定枚数のカードを抜き出して勝敗条件カード配置部３３Ａに配置する。ユーザ５Ｂは、山札９１Ｂから所定枚数のカードを抜き出して勝敗条件カード配置部３３Ｂに配置する。ユーザ５Ａとユーザ５Ｂとが、バトルカード配置部３４Ａに配置したキャラクタカードと、バトルカード配置部３４Ｂに配置したキャラクタカードとを対戦させ、キャラクタカードに設定される退場条件が満たされると（例えば、キャラクタカードに設定される体力値が、対戦相手のキャラクタカードに設定される攻撃力に基づき減算され、尽きた場合）、当該キャラクタカードのキャラクタが気絶したものとして、当該キャラクタカードを消費カード配置部３５（「トラッシュ」ともいう）へ移動させる。

これにより、バトルに勝利して対戦相手のキャラクタカードを退場させたユーザは、勝敗条件カード配置部３３Ａ又は勝敗条件カード配置部３３Ｂに配置されたカードを手札に加える。例えば、ユーザ５Ｂが、自身のターンでユーザ５Ａのキャラクタカードに攻撃をすることによりバトルカード配置部３４Ａに配置されるカードを退場させた場合、勝敗条件カード配置部３３Ｂに配置されるカードから所定枚数のカードを取って手札に加える。一方、ユーザ５Ａが、自身のターンでユーザ５Ｂのキャラクタカードに攻撃をすることによりバトルカード配置部３４Ｂに配置されるカードを退場させた場合、勝敗条件カード配置部３３Ａに配置されるカードから所定枚数のカードを取って手札に加える。これら操作を繰り返し、ユーザ５Ｂが勝敗条件カード配置部３３Ｂに配置されるカードを全て回収したとき、または、ユーザ５Ａが勝敗条件カード配置部３３Ａに配置されるカードを全て回収したときに、回収しきったユーザを、ＴＣＧの対戦に勝利したユーザと決定することとしてもよい。

なお、対戦の勝利条件としては、この他に、バトルカード配置部３４と準備カード配置部３２のいずれにもキャラクタカードがない場合に敗北する、としてもよい。また、対戦の勝利条件としては、各ユーザが自分のターンで山札配置部３１から山札を引けない場合に敗北する、としてもよい。

図１～図３では、ユーザ同士が対面してＴＣＧの対戦を行う例を説明している。しかしながら、ＴＣＧの対戦は、ユーザ同士が対面するものに限定されない。ユーザ同士がインターネットで接続し、相手の音声及び相手のカード配置等をインターネットを介して取得することで対戦を行ってもよい。具体的には、例えば、ユーザは、プレイマット３０における自身の領域をカメラ等で撮影しながら対戦を行う。撮影された画像は、リアルタイムで対戦相手へ送信される。ユーザは、対戦相手から送られてきた、対戦相手の領域についての画像を受信し、受信した画像をディスプレイに表示する。これにより、ユーザは、現実の自身のカードを扱いながら、画面越しに対戦相手のカードをリアルタイムに確認することが可能となる。このように、ユーザは、アナログカードを用いたＴＣＧの対戦をオンラインで実施してもよい。

カメラが複数ある場合、又は、カメラの視野角を調整可能なデバイスがある場合、ユーザの顔を撮影し、撮影した画像を対戦相手へ送信してもよい。こうすることで、対戦中の相手の表情を確認することが可能となるため、オンラインでのＴＣＧの対戦で、対面での対戦の満足度を得ることが可能となる。

＜１ システム全体の構成図＞
図４は、システム１の全体構成の例を示すブロック図である。図４に示すシステム１は、例えば、端末装置１０、及びサーバ２０を含む。端末装置１０、及びサーバ２０は、例えば、ネットワーク８０を介して通信接続する。

図４において、システム１が端末装置１０を３台含む例を示しているが、システム１に含まれる端末装置１０の数は、３台に限定されない。システム１に含まれる端末装置１０は、２台以下であってもよいし、４台以上であってもよい。

図４において、システム１がサーバ２０を１台含む例を示しているが、システム１に含まれるサーバ２０の数は、１台に限定されない。サーバ２０は、有する機能に応じ、複数のサーバから構成されていてもよい。また、サーバ２０は、例えば、複数の装置の集合体を１つのサーバとしてもよい。１つ又は複数のハードウェアに対して本実施形態に係るサーバ２０を実現することに要する複数の機能の配分の仕方は、各ハードウェアの処理能力及び／又はサーバ２０に求められる仕様等に鑑みて適宜決定することができる。

図４に示す端末装置１０は、例えば、デジタルＴＣＧをプレイするユーザが操作する情報処理装置である。端末装置１０は、例えば、スマートフォン、タブレット等の携帯端末により実現される。また、端末装置１０は、据え置き型のＰＣ（Personal Computer）、ラップトップＰＣ等により実現されてもよいし、ＨＭＤ（Head Mount Display）等のウェアラブル端末により実現されてもよい。

端末装置１０は、通信ＩＦ（Interface）１２と、入力装置１３と、出力装置１４と、メモリ１５と、ストレージ１６と、プロセッサ１９とを備える。入力装置１３は、ユーザからの入力操作を受け付けるための装置（例えば、タッチパネル、タッチパッド等）である。出力装置１４は、ユーザに対して情報を提示するための装置（ディスプレイ、スピーカー等）である。

サーバ２０は、例えば、カードに関する情報及びデッキに関する情報を管理する情報処理装置である。

サーバ２０は、例えば、ネットワーク８０に接続されたコンピュータにより実現される。図４に示すように、サーバ２０は、通信ＩＦ２２と、入出力ＩＦ２３と、メモリ２５と、ストレージ２６と、プロセッサ２９とを備える。入出力ＩＦ２３は、ユーザからの入力操作を受け付けるための入力装置、及び、ユーザに対して情報を提示するための出力装置とのインタフェースとして機能する。

各情報処理装置は演算装置と記憶装置とを備えたコンピュータにより構成されている。コンピュータの基本ハードウェア構成及び、当該ハードウェア構成により実現されるコンピュータの基本機能構成は後述する。端末装置１０、及びサーバ２０のそれぞれについて、後述するコンピュータの基本ハードウェア構成及びコンピュータの基本機能構成と重複する説明は省略する。

＜１．１ 端末装置の構成＞
図５は、図４に示す端末装置１０の構成例を表すブロック図である。図５に示すように、端末装置１０は、通信部１２０と、入力装置１３と、出力装置１４と、音声処理部１７と、マイク１７１と、スピーカー１７２と、カメラ１６０と、位置情報センサ１５０と、記憶部１８０と、制御部１９０とを備える。端末装置１０に含まれる各ブロックは、例えば、バス等により電気的に接続される。

通信部１２０は、端末装置１０が他の装置と通信するための変復調処理等の処理を行う。通信部１２０は、制御部１９０で生成された信号に送信処理を施し、外部（例えば、サーバ２０）へ送信する。通信部１２０は、外部から受信した信号に受信処理を施し、制御部１９０へ出力する。

入力装置１３は、端末装置１０を操作するユーザが指示、又は情報を入力するための装置である。入力装置１３は、例えば、操作面へ触れることで指示が入力されるタッチ・センシティブ・デバイス１３１等により実現される。端末装置１０がＰＣ等である場合には、入力装置１３は、リーダー、キーボード、マウス等により実現されてもよい。入力装置１３は、ユーザから入力される指示を電気信号へ変換し、電気信号を制御部１９０へ出力する。なお、入力装置１３には、例えば、外部の入力機器から入力される電気信号を受け付ける受信ポートが含まれてもよい。

出力装置１４は、端末装置１０を操作するユーザへ情報を提示するための装置である。出力装置１４は、例えば、ディスプレイ１４１等により実現される。ディスプレイ１４１は、制御部１９０の制御に応じたデータを表示する。ディスプレイ１４１は、例えば、ＬＣＤ（Liquid Crystal Display）、又は有機ＥＬ（Electro-Luminescence）ディスプレイ等によって実現される。

音声処理部１７は、例えば、音声信号のデジタル－アナログ変換処理を行う。音声処理部１７は、マイク１７１から与えられる信号をデジタル信号に変換して、変換後の信号を制御部１９０へ与える。また、音声処理部１７は、音声信号をスピーカー１７２へ与える。音声処理部１７は、例えば音声処理用のプロセッサによって実現される。マイク１７１は、音声入力を受け付けて、当該音声入力に対応する音声信号を音声処理部１７へ与える。スピーカー１７２は、音声処理部１７から与えられる音声信号を音声に変換して当該音声を端末装置１０の外部へ出力する。

カメラ１６０は、受光素子により光を受光し、撮影信号として出力するためのデバイスである。

位置情報センサ１５０は、端末装置１０の位置を検出するセンサであり、例えばＧＰＳ（Global Positioning System）モジュールである。ＧＰＳモジュールは、衛星測位システムで用いられる受信装置である。衛星測位システムでは、少なくとも３個または４個の衛星からの信号を受信し、受信した信号に基づいて、ＧＰＳモジュールが搭載される端末装置１０の現在位置を検出する。位置情報センサ１５０は、端末装置１０が接続する無線基地局の位置から、端末装置１０の現在の位置を検出してもよい。

記憶部１８０は、例えば、メモリ１５、及びストレージ１６等により実現され、端末装置１０が使用するデータ、及びプログラムを記憶する。記憶部１８０は、例えば、ユーザ情報１８１、カード情報１８２、デッキ情報１８３を記憶する。

ユーザ情報１８１は、例えば、ＴＣＧをプレイするユーザに関する情報を含む。ユーザに関する情報には、例えば、ユーザＩＤ、ユーザの氏名、年齢、住所、生年月日、登録年月日、ユーザがフォローしている他ユーザに関する情報等が含まれる。

カード情報１８２は、例えば、カードに関する情報を含む。カード情報１８２は、ユーザが所有するカードに関する情報を含んでいてもよい。詳細は後述する。

デッキ情報１８３は、例えば、ユーザが構築したデッキに関する情報を含む。詳細は後述する。

制御部１９０は、プロセッサ１９が記憶部１８０に記憶されるプログラムを読み込み、プログラムに含まれる命令を実行することにより実現される。制御部１９０は、端末装置１０の動作を制御する。制御部１９０は、プログラムに従って動作することにより、操作受付部１９１、送受信部１９２、管理部１９３、表示制御部１９４、対戦処理部１９５としての機能を発揮する。

操作受付部１９１は、入力装置１３から入力される指示、又は情報を受け付けるための処理を行う。具体的には、例えば、操作受付部１９１は、タッチ・センシティブ・デバイス１３１等から入力される指示、又は情報を受け付ける。

また、操作受付部１９１は、カメラ１６０から入力される画像を受け付ける。具体的には、例えば、操作受付部１９１は、カメラ１６０により撮影された撮影データを受信する。

また、操作受付部１９１は、マイク１７１から入力される音声情報を受け付ける。具体的には、例えば、操作受付部１９１は、マイク１７１から入力され、音声処理部１７でデジタルデータに変換された音声データを受信する。

送受信部１９２は、端末装置１０が、サーバ２０等の外部の装置と、通信プロトコルに従ってデータを送受信するための処理を行う。具体的には、例えば、送受信部１９２は、ユーザから入力された指示、又は取得した種々の情報をサーバ２０へ送信する。また、送受信部１９２は、サーバ２０から提供される情報を受信する。サーバ２０から提供される情報は、例えば、新たにユーザが入手したカードに関する情報、又は、デッキに関する情報を含む。

管理部１９３は、記憶部１８０に記憶される、ユーザ情報１８１、カード情報１８２、デッキ情報１８３を管理する。例えば、管理部１９３は、ユーザに関する情報が編集されると、編集された情報をユーザ情報１８１に記憶する。また、管理部１９３は、カードに関する情報が更新されると、カード情報１８２を更新する。また、管理部１９３は、デッキに関する情報が更新されると、デッキ情報１８３を更新する。

表示制御部１９４は、ユーザに対して所定の画像を表示するため、出力装置１４を制御する。例えば、表示制御部１９４は、カード情報１８２で管理される情報と、デッキ情報１８３で管理される情報とに基づき、ユーザが所有しているカードの管理画面を表示するように、ディスプレイ１４１を制御する。また、表示制御部１９４は、デッキに関する情報を表示するように、ディスプレイ１４１を制御する。

対戦処理部１９５は、他デッキとの対戦処理を制御する。対戦は、例えば、以下の態様が想定される。
・デジタルカードで構築したデッキを用いたＣＰＵとの対戦
・デジタルカードで構築したデッキを用いた他プレイヤとの対戦
・アナログカードをカメラで読み込んで行う他プレイヤとの対戦
・大会での対戦

＜１．２ サーバの機能的な構成＞
図６は、サーバ２０の機能的な構成の例を示す図である。図６に示すように、サーバ２０は、通信部２０１と、記憶部２０２と、制御部２０３としての機能を発揮する。

通信部２０１は、サーバ２０が外部の装置と通信するための処理を行う。

記憶部２０２は、例えば、ユーザ情報テーブル２０２１、カードマスタテーブル２０２２、デッキ情報テーブル２０２３、対戦情報テーブル２０２４、特典情報テーブル２０２５を有する。

ユーザ情報テーブル２０２１は、例えば、ＴＣＧに関するサービスに登録しているユーザに関する情報を記憶するテーブルである。詳細は後述する。

カードマスタテーブル２０２２は、例えば、ユーザが入手可能なカードに関する情報を記憶するテーブルである。詳細は後述する。

デッキ情報テーブル２０２３は、例えば、ユーザにより登録されたデッキに関する情報を記憶するテーブルである。詳細は後述する。

対戦情報テーブル２０２４は、例えば、過去に実施された対戦に関する情報を記憶するテーブルである。詳細は後述する。

特典情報テーブル２０２５は、例えば、ユーザに付与する特典に関する情報（特典情報）を記憶するテーブルである。詳細は後述する。

制御部２０３は、プロセッサ２９が記憶部２０２に記憶されるプログラムを読み込み、プログラムに含まれる命令を実行することにより実現される。制御部２０３は、プログラムに従って動作することにより、受信制御モジュール２０３１、送信制御モジュール２０３２、管理モジュール２０３３、付与モジュール２０３４、対戦処理モジュール２０３５としての機能を発揮する。

受信制御モジュール２０３１は、サーバ２０が外部の装置から通信プロトコルに従って信号を受信する処理を制御する。

送信制御モジュール２０３２は、サーバ２０が外部の装置に対し通信プロトコルに従って信号を送信する処理を制御する。

管理モジュール２０３３は、記憶部２０２に記憶されるテーブルを管理する。具体的には、例えば、管理モジュール２０３３は、デッキに関する指示を受信すると、受信した指示に基づき、デッキ情報テーブル２０２３を更新する。また、管理モジュール２０３３は、対戦に関する情報を受信すると、受信した情報に基づき、デッキ情報テーブル２０２３、対戦情報テーブル２０２４を更新する。

付与モジュール２０３４は、ユーザに対し、特典を付与する。例えば、付与モジュール２０３４は、特典情報テーブル２０２５を参照し、条件を満たしたユーザに特典を付与する。

対戦処理モジュール２０３５は、ユーザ同士の対戦処理を制御する。例えば、対戦処理モジュール２０３５は、デジタルカードで構築したデッキを用いたプレイヤ同士の対戦を制御する。また、対戦処理モジュール２０３５は、例えば、アナログカードをカメラで読み込んで行うプレイヤ同士の対戦を制御する。

＜２ データ構造＞
図７、図８は、端末装置１０が記憶する情報のデータ構造を示す図である。なお、図７、図８は一例であり、記載されていないデータを除外するものではない。

図７は、カード情報１８２のデータ構造を示す図である。図７に示すカード情報１８２は、カードＩＤをキーとして、名称、種別、属性、カード情報、画像データ、枚数等のカラムを有するテーブルである。カード情報１８２は、これらの他に、全く同じカードに対してもカードを一意に特定するためのカード管理ＩＤ、レギュレーション、又はレアリティに関する情報等を有していてもよい。

カードＩＤは、カードの種類を一意に識別するための識別子を記憶する項目である。本実施形態において、全く同じカードに対しては同一のカードＩＤが割り当てられている。同一の名称であっても、効果が異なるカード、レアリティが異なるカード、レギュレーションが異なるカードには、異なるカードＩＤが割り振られている。名称は、カードの名称を記憶する項目である。種別は、カードの種類を記憶する項目である。本実施形態において、カードの種類は、例えば、キャラクタ、エネルギー、サポート、グッズ、スタジアム等を含む。

属性は、キャラクタが属する性質を記憶する項目である。本実施形態において、属性は、例えば、炎、水、雷、草、超、鋼、悪、闘等を含む。属性には、相対すると有利になる属性、及び不利になる属性が存在する。カード情報は、カードの内容を説明する情報を記憶する項目である。カードの種別がキャラクタである場合、カード情報は、例えば、キャラクタの攻撃力、体力、技を出すのに必要なエネルギー量、逃げるのに必要なエネルギー量、弱点、抵抗力、キャラクタが有する特殊な特性等を含む。カードの種別がサポート、グッズ、スタジアムである場合、カード情報は、例えば、カードの使用要件、カード使用時に発生する効果等を含む。

画像データは、画像を記憶する項目である。画像データは、他の場所に配置された画像データファイルに対する参照情報（パス）を記憶するものとしてもよい。枚数は、ユーザが所持している、同一のカードＩＤが割り振られているカードの枚数を記憶する項目である。本実施形態において、同一の名称であっても、効果が異なるカードには、異なるカードＩＤが割り振られている。また、同一の名称であっても、レアリティが異なるカードには、異なるカードＩＤが割り振られている。また、同一の名称であっても、レギュレーションが異なるカードには、異なるカードＩＤが割り振られている。なお、所有しているカードがカード管理ＩＤによりそれぞれ一意に管理されている場合、枚数は管理されなくてもよい。

図８は、デッキ情報１８３のデータ構造を示す図である。図８に示すデッキ情報１８３は、デッキＩＤをキーとして、名称、編成カード、完成、更新日、登録情報等のカラムを有するテーブルである。デッキ情報１８３は、これらの他に、デッキの通称名称に関する情報、デッキの使用履歴、代表画像等を有していてもよい。デッキの通称名称は、例えば、デッキに用いられている特徴的なカードに基づいて付けられる、デッキの特徴を端的に表す、複数のユーザ間で共通の認識のもと付けられる名称である。代表画像は、例えば、デッキに編成されるカードのうち、ユーザにより指定されたカードについての画像である。代表画像は、例えば、カードの記載のうち、文章を除く、イラストに係る画像である。代表画像は、例えば、画素数を所定の数まで縮小させた画像、例えば、サムネイル画像である。

デッキＩＤは、デッキを一意に識別するための識別子を記憶する項目である。名称は、デッキの名称を記憶する項目である。名称は、例えば、デッキを編成するカードの一部に基づいて生成されたり、ユーザにより付けられる。編成カードは、デッキを編成するカードを記憶する項目である。編成カードでは、例えば、デッキを編成するカードのカードＩＤが記憶される。

完成は、デッキが完成しているか否かを記憶する項目である。本実施形態において、丸は、デッキが完成していることを表し、ばつは、デッキが完成していないことを表す。本実施形態において、デッキが完成しているとは、例えば、規定枚数のカードによりデッキを組み上げ、対戦に使用可能な状態となったことを表す。更新日は、デッキの構成を変更した日を記憶する項目である。更新日の算定において、一のデッキに採用されるカードを他のデッキで採用することも変更と扱ってもよい。登録情報は、サーバ２０に登録されているデッキとの係りを記憶する項目である。登録情報には、例えば、デッキがサーバ２０に登録されたときに発行されるデッキコードが記憶される。

デッキについてのレコードは、ユーザからの指示により、端末装置１０において新たなデッキが作成されたときに追加される。

図９～図１３は、サーバ２０が記憶する情報のデータ構造を示す図である。なお、図９～図１３は一例であり、記載されていないデータを除外するものではない。

図９は、ユーザ情報テーブル２０２１のデータ構造を示す図である。図９に示すユーザ情報テーブル２０２１は、ユーザＩＤをキーとして、氏名、年齢、住所、生年月日、登録年月日、フォロー等のカラムを有するテーブルである。ユーザ情報テーブル２０２１は、上記に限らず、熟練度等をカラムとして有してもよい。

ユーザＩＤは、ユーザを一意に識別するための識別子を記憶する項目である。氏名は、ユーザの氏名を記憶する項目である。年齢は、ユーザの年齢を記憶する項目である。住所は、ユーザが住んでいる場所を記憶する項目である。生年月日は、ユーザが生まれた日付を記憶する項目である。登録年月日は、ユーザがＴＣＧに係るサービスの利用を開始した日付を記憶する項目である。フォローは、ユーザがフォローしている他ユーザに関する情報を記憶する項目である。フォローは、例えば、ユーザがフォローしている他ユーザのユーザＩＤが記憶される。

ユーザ情報テーブル２０２１におけるレコードは、ユーザが新たに登録されると追加される。

図１０は、カードマスタテーブル２０２２のデータ構造を示す図である。図１０に示すカードマスタテーブル２０２２は、カードＩＤをキーとして、名称、種別、属性、カード情報、画像データ等のカラムを有するテーブルである。

カードＩＤは、カードの種類を一意に識別するための識別子を記憶する項目である。名称は、カードの名称を記憶する項目である。種別は、カードの種類を記憶する項目である。属性は、キャラクタが属する性質を記憶する項目である。カード情報は、カードの内容を説明する情報を記憶する項目である。画像データは、画像を記憶する項目である。

カードマスタテーブル２０２２におけるレコードは、例えば、カードが新たに発行されると追加される。

図１１は、デッキ情報テーブル２０２３のデータ構造を示す図である。図１１に示すデッキ情報テーブル２０２３は、デッキコードをキーとして、名称、作成者、作成日、編成カード、対戦情報、公開等のカラムを有するテーブルである。デッキ情報テーブル２０２３は、これらの他に、デッキの通称名称に関する情報、代表画像、登録者、閲覧回数、ユーザが登録を要求した日、デッキの使用が所定の条件を達成した日等を有していてもよい。登録者は、例えば、デッキを登録したユーザのうち、作成者ではないユーザを記憶する。つまり、登録者は、２番目以降にデッキを作成して登録したユーザのユーザＩＤを表す。また、登録者を区別可能な情報が含まれていてもよい。例えば、登録した順番を認識可能な番号が含まれていてもよい。つまり、作成者に「１」が付される場合、最初の登録者には「２」が付される。最初の登録者に「１」が付される場合には、次の登録者に「２」が付されてもよい。こうすることで、ユーザは、該当するデッキを使い始めた順序を把握することが可能となり、例えば、流行に先駆けたことを意識することが可能となる。閲覧回数は、例えば、デッキの内容を確認したユーザ数を記憶する。デッキ編成をコピーする機能をサーバ２０が提供している場合、コピーしたユーザの数を参照回数として記憶してもよい。

デッキコードは、登録されているデッキを一意に識別するための識別子を記憶する項目である。デッキコードは、ユーザから公開が要求されたデッキが新規なデッキである場合、管理モジュール２０３３により発行される。新規なデッキとは、例えば、デッキの少なくとも一部が既存のデッキと異なるデッキを表す。また、新規なデッキとは、例えば、全く同一の構成のデッキが存在しないデッキを表すと換言可能である。図１１に示すデッキコードは、例えば、図８に示すデッキＩＤとは異なる識別子となっている。図１１に示すデッキコードは、公開されているデッキを管理するものであり、図８に示すデッキＩＤは、自身のデッキを管理するためのものであるからである。

名称は、デッキの名称を記憶する項目である。名称はユーザにより付けられる。作成者は、デッキを最初に作成したユーザのユーザＩＤを記憶する項目である。作成日は、デッキが最初に作成された日付を記憶する項目である。編成カードは、デッキを編成するカードを記憶する項目である。編成カードでは、例えば、デッキを編成するカードのカードＩＤが記憶される。対戦情報は、デッキコードにより識別されるデッキを用いて実施した対戦に関する情報を記憶する項目である。対戦情報は、例えば、以下の情報を含む。
・対戦を識別するための対戦ＩＤ
・対戦の日時
・参加した大会
・大会の結果

公開は、デッキが他ユーザに公開されているか否かを記憶する項目である。本実施形態において、丸は、デッキが他ユーザに公開されていることを表し、ばつは、デッキが他ユーザに公開されていないことを表す。本実施形態において、デッキが公開されていないとは、自身のみが確認可能なことを意味する。

デッキ情報テーブル２０２３におけるレコードは、デッキが新たに登録されると追加される。

図１２は、対戦情報テーブル２０２４のデータ構造を示す図である。図１２に示す対戦情報テーブル２０２４は、対戦ＩＤをキーとして、日時、対戦者、デッキコード、勝者、対戦ログ情報、大会情報等のカラムを有するテーブルである。

対戦ＩＤは、対戦を一意に識別するための識別子を記憶する項目である。対戦ＩＤは、対戦に関する新たな情報が登録されると、管理モジュール２０３３により発行される。日時は、対戦が行われた日時を記憶する項目である。対戦者は、対戦を行ったプレイヤに関する情報を記憶する項目である。本実施形態では、例えば、対戦者には、対戦を行ったプレイヤ同士のユーザＩＤが記憶されている。

デッキコードは、対戦に用いられたデッキを識別するコードを記憶する項目である。本実施形態では、例えば、対戦を行ったプレイヤと、そのプレイヤが使用したデッキのデッキコードとが関連付けられている。なお、デッキコードは必ずしも記憶されていなくてもよい。つまり、デッキコードが登録されていなくてもよい。デッキコードが登録されていない場合、例えば、項目「デッキコード」には、デッキに含まれるカードの内容から判別される、デッキを表す情報が記憶されてもよい。このとき、例えば、管理モジュール２０３３は、デッキに含まれるカードに基づき、デッキを表す情報を作成し、作成した情報を項目「デッキコード」に記憶する。例えば、管理モジュール２０３３は、デッキに含まれる主要なカードの名称に基づき、デッキを表す情報を作成する。また、管理モジュール２０３３は、デッキに含まれるカードについての情報を項目「デッキコード」に記憶してもよい。

勝者は、対戦の勝者を記憶する項目である。対戦ログ情報は、対戦中にプレイヤが採用した手を記憶する項目である。具体的には、例えば、対戦ログ情報には、プレイヤが所定の配置部（山札又は勝敗条件カード等）からカードを引くこと、プレイヤが所定の配置部にカードを配置すること、プレイヤが所定のカードの効果を使用すること等が記憶される。対戦中にプレイヤが採用した手は、対戦中のデッキ回しと称してもよい。大会情報は、対戦に関する情報を記憶する項目である。例えば、大会情報には、対戦が行われた大会名、大会における対戦のラウンド数が含まれる。大会情報は、公式に開催された大会に関わらず、プライベートで開催された大会での対戦情報を含んでもよい。また、大会情報は、大会に限定されず、プライベートでの対戦での対戦情報を含んでもよい。

対戦情報テーブル２０２４におけるレコードは、対戦が新たに登録されると追加される。

図１３は、特典情報テーブル２０２５のデータ構造を示す図である。図１３に示す特典情報テーブル２０２５は、特典ＩＤをキーとして、特典内容、条件等のカラムを有するテーブルである。

特典ＩＤは、特典を一意に識別するための識別子を記憶する項目である。特典内容は、特典の内容を記憶する項目である。条件は、特典が付与される条件を記憶する項目である。

＜３ 動作＞
ユーザがデッキを構築し、構築したデッキを登録する際の端末装置１０と、サーバ２０との動作について説明する。

（デッキの構築）
ユーザは、端末装置１０を操作することで、カードを編集し、複数のデジタルカードから編成されるデッキを構築する。

ユーザは、端末装置１０に対し、自身が所有しているカードの一覧を表示するように指示を入力する。具体的には、例えば、ユーザは、端末装置１０にインストールされているデジタルＴＣＧに係るアプリを実行させる。ユーザは、立ち上げたアプリにおいて、所有するカードを表示させる指示を端末装置１０に入力する。端末装置１０の制御部１９０は、表示制御部１９４により、カード情報１８２、デッキ情報１８３に基づき、カードの一覧をディスプレイ１４１に表示する。

ユーザは、端末装置１０に対し、自身が所有しているデッキの一覧を表示するように指示を入力する。具体的には、例えば、ユーザは、カードの一覧表示において、デッキの一覧を表示させる指示を入力するための指示オブジェクトに接触する。表示制御部１９４は、デッキ情報１８３に基づき、デッキの一覧をディスプレイ１４１に表示する。なお、ユーザは、端末装置１０にインストールされているデジタルＴＣＧに係るアプリを立ち上げ、立ち上げたアプリにおいて、デッキを編集する指示を端末装置１０に入力してもよい。

図１４は、端末装置１０に表示されるデッキ一覧の例を表す模式図である。図１４において、表示制御部１９４は、領域１４１１と、領域１４１２とを表示する。領域１４１２は、領域１４１１で記載される表示条件に則った態様で、ユーザが所有するデッキを表示する領域である。

図１４に示す例では、領域１４１１に、表示条件として、表示順が表示されている。表示順は、順序の規則を表す。表示順は、例えば、番号順、名称順、更新日付順等のうちからユーザにより選択される。図１４に示す例では、「表示順：名称順」となっており、領域１４１２に、デッキが、名称の並び順で、配列されている。

領域１４１１には、検索ウィンドウ１４１１１が表示されている。ユーザは、所望のデッキがある場合、検索ウィンドウ１４１１１にキーワード等を入力し、所望のデッキを検索する。

ユーザがデッキを選択すると、表示制御部１９４は、ユーザにより選択されたデッキに対して実施可能な処理をディスプレイ１４１に表示する。

図１５は、ディスプレイ１４１の表示例を表す模式図である。図１５に示す例では、表示制御部１９４は、デッキに対する処理が選択可能にリスト状に表示されたウィンドウ１４１２１を表示する。表示制御部１９４は、ウィンドウ１４１２１に、デッキに対する処理として、例えば、編集、登録等を表示する。ユーザは、入力装置１３を操作することで、デッキに対する処理を選択する。

ユーザは、例えば、端末装置１０に対し、選択しているデッキの編集画面を表示するように指示を入力する。具体的には、例えば、ユーザは、図１５に示されるウィンドウ１４１２１において、「編集」を選択する。表示制御部１９４は、カード情報１８２、デッキ情報１８３に基づき、デッキの編集画面をディスプレイ１４１に表示する。

図１６は、端末装置１０に表示される、デッキ２の編集画面の例を表す模式図である。図１６では、デッキ２がユーザにより選択された場合の編集画面を示しているが、ユーザにより選択されるデッキはデッキ２に限定されない。図１６において、表示制御部１９４は、領域１４１１と、領域１４１３と、領域１４１４とを表示する。領域１４１３は、領域１４１１で記載される表示条件に則った態様で、デッキを構成しているカードを表示する領域である。領域１４１４は、領域１４１１で記載される表示条件に則った態様で、ユーザが所有するカードの一覧を表示する領域である。領域１４１４には、領域１４１３に表示されるカードと入れ替え可能にカードが表示される。領域１４１３に表示されるカードは、領域１４１４に表示されるカードと識別可能な態様で表示されてもよい。図１６に示す例では、領域１４１３に表示されるカードは、領域１４１４に表示されるカードよりも大きく表示されている。

図１６に示す例では、領域１４１１に、表示条件として、表示順が表示されている。表示順は、順序の規則を表す。表示順は、例えば、番号順、名称順、レアリティ順、取得日付順等のうちからユーザにより選択される。図１６に示す例では、「表示順：番号順」となっており、領域１４１３、１４１４に、カードが、カードＩＤの並び順で配列されている。

（デッキの登録）
ユーザは、端末装置１０を操作することで、構築したデッキを登録する。

図１７は、ユーザがデッキを登録する際の端末装置１０とサーバ２０との動作の例を説明する図である。

ユーザは、例えば、端末装置１０を操作して所望のデッキを選択し、選択しているデッキを登録するように指示を入力する。具体的には、例えば、ユーザは、図１５に示されるウィンドウ１４１２１において、「登録」を選択する。

端末装置１０は、ユーザにより「登録」が選択されると、表示制御部１９４により、デッキを登録することを確認するための画面を表示する。

図１８は、ディスプレイ１４１の表示例を表す模式図である。図１８に示す例では、表示制御部１９４は、デッキを登録することを確認するためのウィンドウ１４１２２を表示する。ウィンドウ１４１２２には、ユーザの意思を入力するためのボタン１４１２２１、１４１２２２が表示されている。デッキを登録することに間違いがない場合、ユーザは、Ｙｅｓボタン１４１２２１を押下する。本実施形態において、ボタン１４１２２１の押下が登録要求の入力を意味する。

ステップＳ１１において、端末装置１０は、操作受付部１９１により、ユーザから入力されたデッキの登録要求を受け付ける。端末装置１０は、送受信部１９２により、受け付けた登録要求をサーバ２０へ送信する。

ステップＳ１２において、サーバ２０は、ユーザからのデッキの登録要求に基づき、デッキを登録する。具体的には、例えば、サーバ２０の制御部２０３は、管理モジュール２０３３により、登録要求のあったデッキのうち、新しい編成のデッキのレコードをデッキ情報テーブル２０２３に作成する。

管理モジュール２０３３は、新たな編成のデッキと、当該デッキの作成者とを対応付ける。具体的には、例えば、管理モジュール２０３３は、デッキの作成者のユーザＩＤを、新たに作成したレコードの項目「作成者」に記憶する。

管理モジュール２０３３は、新規でないデッキに対する登録要求については、当該登録を要求したユーザと、登録が要求された既存のデッキとを関連付ける。例えば、管理モジュール２０３３は、登録が要求された既存のデッキについてのレコードの項目「登録者」に、登録を要求したユーザのユーザＩＤを記憶する。

ステップＳ１３において、管理モジュール２０３３は、登録したデッキの公開範囲を設定する。具体的には、管理モジュール２０３３は、例えば、デッキを登録したユーザに対し、登録したデッキを自身以外の他ユーザに公開するか否かを確認する。

管理モジュール２０３３は、ユーザが他ユーザにも公開することを望む場合、他ユーザからのアクセスが可能なようにデッキを管理する。例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３の項目「公開」に丸を記憶する。

管理モジュール２０３３は、ユーザが他ユーザへの公開を望まない場合、他ユーザからのアクセスができないようにデッキを管理する。例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３の項目「公開」にばつを記憶する。

ユーザ情報テーブル２０２１には、ユーザがフォローする他ユーザが登録されている。管理モジュール２０３３は、所定のユーザによりデッキが登録されると、当該ユーザをフォローしているユーザに対し、当該ユーザにより新たなデッキが登録されたことを通知してもよい。新たなデッキを構築することに長けたユーザが存在している。他ユーザは、このようなユーザをフォローすることで、現在のデッキのトレンドを把握することが可能となる。

（デッキの登録における詳細処理１）
図１７のステップＳ１２に示す制御部２０３の処理を詳細に説明する。

図１９は、デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。

ステップＳ２１において、サーバ２０の制御部２０３は、管理モジュール２０３３により、登録が要求されたデッキが新規のデッキであるか否かを判断する。具体的には、管理モジュール２０３３は、デッキを編成するカードの少なくとも一部のカードが、既存のデッキを編成するカードと異なるか否かを判断する。管理モジュール２０３３は、全く同一の構成のデッキが存在するか否かを判断してもよいし、構成の一致度合いが一定の条件を満たすデッキが存在するか否かを判断してもよい。以下は全く同一の構成のデッキが存在しない場合を例に説明する。

全く同一の構成のデッキが存在しない場合、管理モジュール２０３３は、登録要求があったデッキが新規のデッキであると判断し、処理をステップＳ２２へ移行させる。

ステップＳ２２において、管理モジュール２０３３は、デッキ情報テーブル２０２３に新たなレコードを作成し、作成したレコードにデッキコードを割り当てる。管理モジュール２０３３は、作成したレコードに、要求があったデッキに関する情報を記憶する。管理モジュール２０３３は、例えば、作成したレコードの名称、編成カードを、ユーザから入力される情報に基づいて記憶する。また、管理モジュール２０３３は、新たに作成したデッキレコードと、デッキの登録を要求してきたユーザとを対応付ける。すなわち、管理モジュール２０３３は、レコードにおける項目「作成者」に、デッキの登録を要求してきたユーザのユーザＩＤを記憶し、項目「作成日」に、新規であると判断した日付を記憶する。

ステップＳ２３において、送信制御モジュール２０３２は、登録が要求されたデッキが登録されたことを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、登録が要求されたデッキが登録されたことと、登録されたデッキのデッキコードとを、登録要求の要求元の端末装置１０へ送信する。

サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、デッキが登録されたことと共に、ユーザが作成者として対応付けられたことをディスプレイ１４１に表示する。表示制御部１９４は、登録を要求したデッキが新しい構成のデッキであるために登録されたという理由をディスプレイ１４１に表示してもよい。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードにデッキコードを関連付ける。これにより、表示制御部１９４は、記憶されているデッキがサーバ２０に登録されているデッキであることを表示することが可能となる。

図２０は、ディスプレイ１４１の表示例を表す模式図である。図２０に示す例では、表示制御部１９４は、デッキが登録され、ユーザが作成者として対応付けられたことを通知するためのウィンドウ１４１２３を表示する。なお、ウィンドウ１４１２３における現在形、又は過去形の表現には制限はない。ウィンドウ１４１２３には、通知を確認したことを入力するためのボタン１４１２３１が表示されている。通知内容を確認した場合、ユーザは、確認ボタン１４１２３１を押下する。

図１７のステップＳ１３において、端末装置１０は、登録されたデッキを他ユーザに公開するか否かの選択をユーザから受け付ける。具体的には、表示制御部１９４は、登録されたデッキを他ユーザに公開するか否かの選択を受け付けるための画像をディスプレイ１４１に表示する。

図２１は、ディスプレイ１４１の表示例を表す模式図である。例えば、図２０に示す画面においてユーザが確認ボタン１４１２３１を押下すると、表示制御部１９４は、他ユーザへの公開の選択を受け付けるためのウィンドウ１４１２４を表示する。ウィンドウ１４１２４には、ユーザの意思を入力するためのボタン１４１２４１、１４１２４２が表示されている。デッキを他ユーザにも公開する場合、ユーザは、Ｙｅｓボタン１４１２４１を押下する。送受信部１９２は、デッキの公開に関する指示をサーバ２０へ送信する。

デッキの公開に関する指示を受信すると、サーバ２０は、管理モジュール２０３３により、公開に関する情報をデッキ情報テーブル２０２３の項目「公開」に記憶する。これにより、項目「公開」に丸が記憶される場合、他ユーザもデッキの編成、及び作成者を確認することが可能となる。一方、項目「公開」にばつが記憶される場合、作成者であるユーザだけがデッキの編成、及び作成者を確認することが可能となる。

ステップＳ２１において、登録が要求されたデッキが新規のデッキでない場合、管理モジュール２０３３は、処理をステップＳ２４へ移行させる。

ステップＳ２４において、管理モジュール２０３３は、例えば、既存のデッキに、登録を要求したユーザを関連付ける。具体的には、例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３を参照し、登録が要求されたデッキと同一のデッキを取得する。管理モジュール２０３３は、取得したデッキのレコードに、登録を要求したユーザのユーザＩＤを記憶する。これにより、登録を要求したユーザに対し、既存のデッキを関連付けることが可能となる。

ステップＳ２４において、送信制御モジュール２０３２は、登録が要求されたデッキが既に存在していることを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、同一のデッキが既に存在することと、既存のデッキのデッキコードとを登録要求の要求元の端末装置１０へ送信する。送信制御モジュール２０３２は、既存のデッキを作成したユーザのユーザＩＤを要求元の端末装置１０へ送信してもよい。これにより、デッキを作成したユーザの存在感が高まり、デッキを先に作成することの動機となり得る。

サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、デッキが既に存在していることをディスプレイ１４１に表示する。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードに、既存のデッキのデッキコードを関連付ける。これにより、表示制御部１９４は、記憶されているデッキがサーバ２０に登録されているデッキであることを表示することが可能となる。

なお、ステップＳ２４の処理は必須ではない。既存のデッキと、ユーザとの関連付けが不要である場合、ステップＳ２４の処理を実施しなくてもよい。つまり、既存のデッキと、ユーザとの関連付けが不要である場合、例えば、ステップＳ２１で、登録が要求されたデッキが新規のデッキでないと判断すると、送信制御モジュール２０３２は、デッキが既に存在していることを端末装置１０へ通知する。

（デッキの登録における詳細処理２）
図１７のステップＳ１２に示す制御部２０３の処理のその他の例を詳細に説明する。詳細処理１では、登録が要求されたデッキが新規である場合に、登録を要求したユーザを作成者としてデッキ情報と紐づけることを説明した。詳細処理２では、デッキの新規作成者として登録されるための条件が複数ある場合を説明する。

図２２は、デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。

ステップＳ３１において、サーバ２０の制御部２０３は、管理モジュール２０３３により、登録が要求されたデッキが新規のデッキであるか否かを判断する。全く同一の構成のデッキが存在しない場合、管理モジュール２０３３は、登録要求があったデッキが新規のデッキであると判断し、処理をステップＳ３２へ移行させる。

ステップＳ３２において、管理モジュール２０３３は、デッキ情報テーブル２０２３に新たなレコードを作成し、作成したレコードにデッキコードを割り当てる。管理モジュール２０３３は、作成したレコードに、要求があったデッキに関する情報を記憶する。管理モジュール２０３３は、例えば、作成したレコードの名称、編成カードを、ユーザから入力される情報に基づいて記憶する。図２２で説明するフローでは、図１９で説明するフローと異なり、管理モジュール２０３３は、ステップＳ３２において、新たに作成したデッキレコードの項目「作成者」と、項目「作成日」に情報を記憶しない。管理モジュール２０３３は、作成したレコードの所定の項目に、デッキの登録を要求してきたユーザに関する情報（例えば、ユーザＩＤ）を記憶する。こうすることで、管理モジュール２０３３は、デッキの登録要求を送信してきたユーザを記憶することが可能となる。

ステップＳ３３において、送信制御モジュール２０３２は、登録が要求されたデッキが登録されたことを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、登録が要求されたデッキが新規な構成のデッキであること、デッキを使用することで所定の要件を満たす場合、ユーザがデッキの作成者として対応付けられること、及び登録されたデッキのデッキコードを、登録要求の要求元の端末装置１０へ送信する。

サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、デッキが新しい編成であること、及び所定の要件を満たすとデッキの作成者としてデッキと対応付けられることをディスプレイ１４１に表示する。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードにデッキコードを関連付ける。これにより、表示制御部１９４は、記憶されているデッキがサーバ２０に登録されているデッキであり、所定の要件を満たすことで作成者として登録されることを表示することが可能となる。

図２３は、ディスプレイ１４１の表示例を表す模式図である。図２３に示す例では、表示制御部１９４は、デッキが新規のデッキであり、所定の要件を満たすとユーザが作成者として対応付けられることを通知するためのウィンドウ１４１２５を表示する。ウィンドウ１４１２５には、通知を確認したことを入力するためのボタンが表示されていてもよい。

ステップＳ３１において、登録が要求されたデッキが新規のデッキでない場合、管理モジュール２０３３は、処理をステップＳ２４へ移行させる。

図２４は、デッキと、デッキの作成者とを対応付ける際のサーバ２０の動作の例を示すフローチャートである。

ステップＳ４１において、管理モジュール２０３３は、新規のデッキについての使用の条件が満たされたか否かを判断する。具体的には、例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３を参照し、レコードは作成されているが、作成者が記憶されていないデッキについて、項目「対戦情報」の情報を読み出す。管理モジュール２０３３は、読み出した情報がデッキの使用についての所定の条件を満たすか否かを判断する。つまり、管理モジュール２０３３は、登録を要求してきたユーザがデッキを使用することで、所定の条件を満たしたか否かを判断する。本実施形態において、デッキの使用についての所定の条件とは、例えば、以下である。
・デッキを使用した対戦の回数が所定回数に達したこと
・デッキを使用した対戦の勝利数が所定回数に達したこと
・所定の対戦会でのデッキの使用登録
・所定の対戦会への出場回数が所定回数に達したこと
・所定の対戦会のエントリー回数が所定回数に達したこと
・所定の対戦会での所定順位の獲得
・デッキの公開後、登録を要求したユーザ以外のユーザがデッキを使用して上記の条件を達成したこと

読み出した情報がデッキの使用についての所定の条件を満たす場合、管理モジュール２０３３は、処理をステップＳ４２へ移行させる。

ステップＳ４２において、管理モジュール２０３３は、所定の使用条件を満たしたデッキについて、デッキ情報テーブル２０２３を更新する。具体的には、例えば、管理モジュール２０３３は、項目「対戦情報」の情報を読み出したレコードの項目「作成者」に、デッキを使用したユーザ、言い換えると、デッキを最初に作成したユーザのユーザＩＤを記憶する。つまり、管理モジュール２０３３は、所定の使用条件を満たしたデッキと、デッキの作成者とを対応付ける。

ステップＳ４３において、送信制御モジュール２０３２は、ユーザがデッキの作成者として登録されたことを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、ユーザがデッキの作成者として登録されたことと、作成者として登録されたデッキのデッキコードとを、デッキの登録要求の要求元の端末装置１０へ送信する。

サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、登録されているデッキに、ユーザが作成者として対応付けられたことをディスプレイ１４１に表示する。表示制御部１９４は、デッキの使用について満たした条件をディスプレイ１４１に表示してもよい。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードに、ユーザが作成者になったことを記憶する。これにより、表示制御部１９４は、記憶されているデッキがユーザにより初めて作成されたデッキであることを表示することが可能となる。

図２５は、ディスプレイ１４１の表示例を表す模式図である。図２５に示す例では、表示制御部１９４は、使用についての条件を満たしたことで、ユーザが作成者として対応付けられたことを通知するためのウィンドウ１４１２６を表示する。なお、ウィンドウ１４１２６における現在形、又は過去形の表現には制限はない。ウィンドウ１４１２６には、通知を確認したことを入力するためのボタン１４１２６１が表示されている。通知内容を確認した場合、ユーザは、確認ボタン１４１２６１を押下する。

図２５に示す画面においてユーザが確認ボタン１４１２６１を押下すると、表示制御部１９４は、例えば、他ユーザへの公開の選択を受け付けるためのウィンドウを表示する。

ステップＳ４１において、新規のデッキについての使用の条件が満たされていない場合、制御部２０３は、ステップＳ４１の処理を繰り返す。管理モジュール２０３３は、予め設定した期間において条件が満たされない場合、新規のデッキについてのレコードを削除してもよい。

（対戦情報テーブルの更新処理）
サーバ２０の制御部２０３は、管理モジュール２０３３により、デッキが対戦で使用された情報を管理する。

ユーザは、カード情報１８２で管理されているカードを組み合わせることでデッキを構築する。管理部１９３は、ユーザが構築したデッキに関する情報をデッキ情報１８３で管理している。

また、ユーザは、自身が構築したデッキをサーバ２０に登録している。具体的には、例えば、ユーザは、上記の「デッキの登録」で示すように端末装置１０を操作することで、自身が構築したデッキをサーバ２０に登録している。

図２６は、デッキの対戦情報を管理する際の端末装置１０とサーバ２０との動作の例を説明する図である。

ユーザは、対戦を開始する際に、端末装置１０を用いて、サーバ２０にアクセスする。端末装置１０は、サーバ２０で設定されている、対戦情報の登録フォームをディスプレイ１４１に表示する。ユーザは、ディスプレイ１４１に表示されるフォームを利用し、対戦に関する情報を入力する。対戦に関する情報は、例えば、対戦を実施する日時、対戦者、対戦で使用するデッキに関する情報、大会情報等である。ユーザは、対戦に関する情報を入力すると、対戦情報を登録する要求を端末装置１０に入力する。

ステップＳ５１において、端末装置１０は、操作受付部１９１により、ユーザから入力された対戦情報の登録要求を受け付ける。端末装置１０は、送受信部１９２により、入力された対戦情報と、登録要求とをサーバ２０へ送信する。

ステップＳ５２において、サーバ２０は、ユーザから入力された対戦情報に基づいて対戦情報テーブル２０２４を更新する。具体的には、例えば、管理モジュール２０３３は、対戦情報の登録要求がユーザから入力されると、対戦ＩＤを発行し、対戦情報テーブル２０２４に、発行した対戦ＩＤをキーとするレコードを作成する。管理モジュール２０３３は、作成したレコードの日時、対戦者、デッキコード、大会情報を、ユーザから入力される情報に基づいて記憶する。

日時、対戦者、大会情報は、大会の運営者により事前に入力されていてもよい。この場合、すでに対戦ＩＤは発行されており、対戦情報テーブル２０２４にレコードが作成されている。また、対戦で使用するデッキに関する情報は、ユーザにより事前に登録されてもよい。例えば、大会で利用する予定の複数のデッキが対戦の前に登録されており、ユーザは、対戦の開始時に、登録されているデッキのうちいずれかを選択してもよい。

ステップＳ５３において、管理モジュール２０３３は、デッキ情報テーブル２０２３を更新する。具体的には、管理モジュール２０３３は、デッキコードにより識別されるデッキのレコードの項目「対戦情報」に、対戦に関する情報、例えば、対戦ＩＤを記憶する。デッキが使用される対戦に関する情報は、参加した大会に関する情報、参加した大会の結果に関する情報等を含んでもよい。対戦情報は、対戦回数が増えると、記憶する情報が増える。これにより、デッキがどの対戦で利用されたかを把握することが可能となる。

サーバ２０は、デッキ情報テーブル２０２３で管理される情報を端末装置１０へ送信してもよい。具体的には、例えば、対戦情報テーブル２０２４の項目「対戦情報」に新たに対戦ＩＤが記憶された場合、管理モジュール２０３３は、新たに記憶された対戦ＩＤと、デッキに関連付けられているユーザＩＤとを読み出す。送信制御モジュール２０３２は、読み出した対戦ＩＤを、ユーザＩＤにより識別されるユーザが所有する端末装置１０へ送信する。

端末装置１０は、サーバ２０から送信される情報を受信し、受信した情報に基づき、デッキ情報１８３を更新する。具体的には、例えば、端末装置１０は、管理部１９３により、デッキコードにより特定されるレコードの項目「対戦情報」に、サーバ２０から受信した対戦情報、例えば、対戦ＩＤを記憶する。これにより、表示制御部１９４は、ユーザに対し、デッキを使用した情報を表示することが可能となる。

対戦が開始されると、制御部２０３は、対戦処理モジュール２０３５により、プレイヤ同士の対戦処理を制御する。対戦処理モジュール２０３５は、対戦中にプレイヤが採用した手に関する情報を記憶部２０２に記憶する。管理モジュール２０３３は、対戦中にプレイヤが採用した手に関する情報を、対戦情報テーブル２０２４に対戦ログ情報として記憶する。対戦処理モジュール２０３５は、対戦が終了すると、対戦に勝ったプレイヤを勝者として認定する。管理モジュール２０３３は、勝者を対戦情報テーブル２０２４に記憶する。

（特典付与処理）
付与モジュール２０３４は、特典情報テーブル２０２５に基づき、ユーザに特典を付与する。

具体的には、例えば、付与モジュール２０３４は、デッキに関する情報が、特典情報テーブル２０２５で設定される条件を充足するか否かを判断する。特典情報テーブル２０２５で設定される条件は、例えば、以下である。
・登録されているデッキが他ユーザに貢献した度合が所定の条件を満たしていること
・ユーザが他ユーザに貢献した度合が所定の条件を満たしている

具体的には、例えば、付与モジュール２０３４は、特典情報テーブル２０２５に基づき、登録されているデッキが他ユーザに貢献した度合が所定値に達した場合、デッキを最初に作成したユーザ（作成者として登録されているユーザ）に特典を付与する。デッキが他ユーザに貢献した度合は、例えば、他ユーザがデッキを閲覧した閲覧回数、他ユーザがデッキを参照した参照回数、他ユーザがデッキを登録した登録回数、他ユーザがデッキを使用した使用回数等を含む。

また、付与モジュール２０３４は、特典情報テーブル２０２５に基づき、ユーザが他ユーザに貢献した度合が所定値に達した場合、当該ユーザに特典を付与する。ユーザが他ユーザに貢献した度合は、例えば、新規のデッキを作成した回数、他ユーザからフォローされている人数等を含む。

特典情報テーブル２０２５において、条件毎に所定の特典内容が設定されている。特典内容は、例えば、以下である。
・カードの提供
・オリジナルカードを作成できる権利の付与
・カードの抽選権の付与
・対戦における有利な効果
・カードの抽選における有利な効果

サーバ２０は、登録されているデッキが他ユーザに貢献した度合を、ユーザ又は他ユーザに提示してもよい。具体的には、送信制御モジュール２０３２は、ユーザ又は他ユーザからの要求に応じ、登録されているデッキが他ユーザに貢献した度合に関する情報を要求元の端末装置１０へ送信する。端末装置１０は、受信した情報に基づき、貢献した度合をディスプレイ１４１に表示させる。これによりユーザは、特典を付与されるまでの貢献度を把握することが可能となる。また、他ユーザは、どれほど他者に役立っているデッキかを認識することが可能となる。

また、サーバ２０は、ユーザが他ユーザに貢献した度合を、ユーザ又は他ユーザに提示してもよい。具体的には、送信制御モジュール２０３２は、ユーザ又は他ユーザからの要求に応じ、ユーザが他ユーザに貢献した度合に関する情報を要求元の端末装置１０へ送信する。端末装置１０は、受信した情報に基づき、貢献した度合をディスプレイ１４１に表示させる。これによりユーザは、特典を付与されるまでの貢献度を把握することが可能となる。また、他ユーザは、どれほど効果的なデッキを作成しているユーザかを認識することが可能となる。

（デッキ情報の表示）
端末装置１０は、ユーザからの指示に応じ、サーバ２０で登録されているデッキの一覧を表示する。端末装置１０の制御部１９０は、表示制御部１９４により、デッキ情報テーブル２０２３に基づき、登録されているデッキの一覧をディスプレイ１４１に表示する。

図２７は、ディスプレイ１４１の表示例を表す模式図である。図２７において、表示制御部１９４は、領域１４１１と、領域１４１３とを表示する。領域１４１１は、表示条件等を記載する領域である。領域１４１３は、領域１４１１で記載される表示条件に則った態様で、登録されているデッキを表示する領域である。

図２７に示す例では、領域１４１１に、表示条件として、表示順が表示されている。表示順は、順序の規則を表す。表示順は、例えば、番号順、名称順、レアリティ順、取得日付順等のうちからユーザにより選択される。表示順は、ユーザからの指示に基づき、例えば、番号順から、名称順、レアリティ順、取得日付順等に切り替えることが可能である。図２７に示す例では、「表示順：名称順」となっており、領域１４１３に、デッキが、デッキの名称の並び順で配列されている。

表示制御部１９４は、領域１４１３に表示されるデッキがユーザにより選択されると、選択されたデッキを構築するカードの一覧をディスプレイ１４１に表示する。

以上のように、上記実施形態では、サーバ２０の制御部２０３は、受信制御モジュール２０３１により、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付ける。制御部２０３は、管理モジュール２０３３により、登録を要求されたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断する。管理モジュール２０３３は、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録する。管理モジュール２０３３は、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含める。これにより、初めて作成されたデッキであることを含む所定の条件を満たしたデッキが、作成者と共に登録される。このため、プレイヤは自身の名前がデッキと共に登録されるように、デッキの作成に励むようになる。

したがって、本実施形態に係るプログラムによれば、プレイヤがデッキを作成する興趣性を向上させることができる。

また、上記実施形態では、管理モジュール２０３３は、所定の条件に、初めて作成されたデッキの使用に関する条件を含む。これにより、デッキを作成したのみでは、プレイヤが登録されず、作成したデッキを実際に使用した場合にプレイヤが登録されるようになる。このため、デッキを登録させることのみを目的としてデッキを作成した場合には、プレイヤが登録されない。つまり、実際に使用され得る、他プレイヤにとって価値のあるデッキの情報がプレイヤと共に登録されることになる。

また、上記実施形態では、管理モジュール２０３３は、初めて作成されたデッキの使用に関する条件に、デッキが使用された対戦の回数、デッキが使用された対戦の勝利数、所定の対戦会へのデッキのエントリー回数、又は所定の対戦会でのデッキを使用した第１プレイヤの所定順位の獲得を少なくとも含む。これにより、実用性のある使用条件を満たした場合に、デッキと共にプレイヤが登録されるようになる。

また、上記実施形態では、管理モジュール２０３３は、所定のプレイヤにより作成されたデッキが登録されると、当該プレイヤが作成したデッキが新たに登録されたことを他プレイヤに通知する。これにより、新たなデッキを作成することに長けたプレイヤ、又は有名なプレイヤが作成するデッキを追跡することが可能となり、デッキ作成のトレンドを把握することが可能となる。

また、上記実施形態では、付与モジュール２０３４は、登録されたデッキが第２プレイヤ（他プレイヤ）に貢献した度合に基づいて第１プレイヤ（デッキの作成者）に特典を付与する。これにより、他プレイヤに役に立つデッキを作成する動機となり得る。

また、上記実施形態では、付与モジュール２０３４は、第１プレイヤ（デッキの作成者）が第２プレイヤ（他プレイヤ）に貢献した度合に基づいて第１プレイヤに特典を付与する。これにより、新たなデッキを多く作成した第１プレイヤは特典を受けることが可能となり、デッキを作成する動機となり得る。

＜変形例＞
上記実施形態では、ユーザ情報テーブル２０２１、カードマスタテーブル２０２２、デッキ情報テーブル２０２３、対戦情報テーブル２０２４、特典情報テーブル２０２５がサーバ２０に記憶される場合を説明した。しかしながら、これらのテーブルで記憶される情報は、サーバ２０に記憶されていなくてもよい。例えば、少なくともデッキ情報テーブル２０２３で記憶されるデッキ情報は、Ｐ２Ｐのコンピュータネットワークにより形成されるブロックチェーン（分散型台帳）に記憶されてもよい。

このとき、デジタルカードのそれぞれは、ノンファンジブルトークン（ＮＦＴ）としてブロックチェーンにおいて取引される。上記実施形態において、ＮＦＴには、例えば、ＮＦＴを識別するための固有の識別子（ＮＦＴ－ＩＤ）が割り当てられる。なお、デッキのそれぞれがＮＦＴとしてブロックチェーンにおいて取引されてもよい。

ＮＦＴに対する取引は、例えば、ブロックチェーンに実装されるスマートコントラクトにより実行される。ＮＦＴについての取引履歴はトランザクションとしてブロックチェーンに記憶される。これにより、ＮＦＴの所有者の履歴がブロックチェーンに記憶される。

また、ＮＦＴの使用に関する管理は、例えば、ブロックチェーンに実装されるスマートコントラクトにより実行される。ＮＦＴの使用履歴は、トランザクションとしてブロックチェーンに記憶される。これにより、ＮＦＴを対戦で使用した履歴がブロックチェーンに記憶される。

また、デッキを作成したことによる特典の付与は、例えば、ブロックチェーンに実装されるスマートコントラクトにより実行される。これにより、デッキの作成に関する履歴が所定の要件を満たすと、デッキの作成者に所定の特典が付与される。

このように、サーバ２０の制御部２０３は、管理モジュール２０３３により、デッキに関する情報を、コンピュータネットワークにより形成される分散型台帳に記憶する。つまり、デッキを構築する複数のデジタルカードに関する情報と、第１プレイヤに関する情報とを分散型台帳に記憶する。なお、端末装置１０の制御部１９０が、管理部１９３により、デッキに関する情報を、コンピュータネットワークにより形成される分散型台帳に記憶してもよい。これにより、デッキをＮＦＴとして扱うことが可能となる。また、新規に作成されるデッキについて公明な記録を残すことが可能となる。

上記実施形態では、サーバ２０が対戦情報テーブル２０２４を記憶している場合を説明した。ユーザ自身の対戦情報は、端末装置１０の記憶部１８０に記憶されてもよい。管理部１９３は、記憶部１８０に記憶される対戦情報に基づき、デッキ情報１８３における対戦情報を更新してもよい。送受信部１９２は、デッキ情報１８３が更新されると、デッキに関する情報をサーバ２０へ送信する。サーバ２０の管理モジュール２０３３は、端末装置１０から送信された情報に基づき、デッキ情報テーブル２０２３を更新する。これにより、端末装置１０において、対戦情報を把握することが可能となる。

上記実施形態では、デッキが新しいと、当該デッキに関する情報がデッキ情報テーブル２０２３に記憶されるようにしている。しかしながら、デッキが新しいとの条件のみを満たす場合において、デッキに関する情報がデッキ情報テーブル２０２３に記憶されないようにしてもよい。例えば、管理モジュール２０３３は、デッキが新しく、かつ、デッキがその他の条件を満たした場合に、デッキ情報テーブル２０２３に情報を記憶するようにしてもよい。この場合、例えば、管理モジュール２０３３は、新しいと判断したデッキに関する情報を、デッキ情報テーブル２０２３以外の所定の記憶領域に記憶し、例えば、デッキの使用に関する条件を満たした場合に、デッキ情報テーブル２０２３に情報を記憶する。

上記実施形態では、デッキを最初に登録したユーザが作成者として登録される場合を説明した。しかしながら、作成者として登録されるのは、デッキを最初に登録したユーザのみに限定されない。例えば、管理モジュール２０３３は、作成者として登録するユーザに幅を持たせてもよい。つまり、最初にデッキを登録したユーザに加え、早期にデッキの強さに気が付き、何らかの形で名声を得たユーザも作成者として登録してもよい。こうすると、「作成者」は、自身で名声を取得した者であり、「登録者」は、「作成者」の知恵からの恩恵を得た者と区分することが可能である。具体的には、例えば、管理モジュール２０３３は、デッキについて登録を申請してきた先着Ｘ人のユーザを作成者としても登録する。また、管理モジュール２０３３は、デッキについて登録を申請してきたユーザのうち、先に申請してきた上位Ｘ％のユーザを作成者としてもよい。

＜４ コンピュータの基本ハードウェア構成＞
図２８は、コンピュータ９０の基本的なハードウェア構成を示すブロック図である。コンピュータ９０は、プロセッサ９１、主記憶装置９２、補助記憶装置９３、通信ＩＦ９９（インタフェース、Interface）を少なくとも備える。これらはバスにより相互に電気的に接続される。

プロセッサ９１とは、プログラムに記述された命令セットを実行するためのハードウェアである。プロセッサ９１は、演算装置、レジスタ、周辺回路等から構成される。

主記憶装置９２とは、プログラム、及びプログラム等で処理されるデータ等を一時的に記憶するためのものである。例えば、ＤＲＡＭ（Dynamic Random Access Memory）等の揮発性のメモリである。

補助記憶装置９３とは、データ及びプログラムを保存するための記憶装置である。例えば、フラッシュメモリ、ＨＤＤ（Hard Disc Drive）、光磁気ディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等である。

通信ＩＦ９９とは、有線又は無線の通信規格を用いて、他のコンピュータとネットワークを介して通信するための信号を入出力するためのインタフェースである。

ネットワークは、インターネット、ＬＡＮ、無線基地局等によって構築される各種移動通信システム等で構成される。例えば、ネットワークには、３Ｇ、４Ｇ、５Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えば、Ｗｉ－Ｆｉ（登録商標））等が含まれる。無線で接続する場合、通信プロトコルとして例えば、Ｚ－Ｗａｖｅ（登録商標）、ＺｉｇＢｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等が含まれる。有線で接続する場合は、ネットワークには、ＵＳＢ（Universal Serial Bus）ケーブル等により直接接続するものも含む。

なお、各ハードウェア構成の全部または一部を複数のコンピュータ９０に分散して設け、ネットワークを介して相互に接続することによりコンピュータ９０を仮想的に実現することができる。このように、コンピュータ９０は、単一の筐体、ケースに収納されたコンピュータ９０だけでなく、仮想化されたコンピュータシステムも含む概念である。

＜コンピュータ９０の基本機能構成＞
図２８に示すコンピュータ９０の基本ハードウェア構成により実現されるコンピュータの機能構成を説明する。コンピュータは、制御部、記憶部、通信部の機能ユニットを少なくとも備える。

なお、コンピュータ９０が備える機能ユニットは、それぞれの機能ユニットの全部または一部を、ネットワークで相互に接続された複数のコンピュータ９０に分散して設けても実現することができる。コンピュータ９０は、単一のコンピュータ９０だけでなく、仮想化されたコンピュータシステムも含む概念である。

制御部は、プロセッサ９１が補助記憶装置９３に記憶された各種プログラムを読み出して主記憶装置９２に展開し、当該プログラムに従って処理を実行することにより実現される。制御部は、プログラムの種類に応じて様々な情報処理を行う機能ユニットを実現することができる。これにより、コンピュータは情報処理を行う情報処理装置として実現される。

記憶部は、主記憶装置９２、補助記憶装置９３により実現される。記憶部は、データ、各種プログラム、各種データベースを記憶する。また、プロセッサ９１は、プログラムに従って記憶部に対応する記憶領域を主記憶装置９２または補助記憶装置９３に確保することができる。また、制御部は、各種プログラムに従ってプロセッサ９１に、記憶部に記憶されたデータの追加、更新、削除処理を実行させることができる。

データベースは、リレーショナルデータベースを指し、行と列によって構造的に規定された表形式のテーブルと呼ばれるデータ集合を、互いに関連づけて管理するためのものである。データベースでは、表をテーブル、表の列をカラム、表の行をレコードと呼ぶ。リレーショナルデータベースでは、テーブル同士の関係を設定し、関連づけることができる。

通常、各テーブルにはレコードを一意に特定するためのキーとなるカラムが設定されるが、カラムへのキーの設定は必須ではない。制御部は、各種プログラムに従ってプロセッサ９１に、記憶部に記憶された特定のテーブルにレコードを追加、削除、更新を実行させることができる。

通信部は、通信ＩＦ９９により実現される。通信部は、ネットワークを介して他のコンピュータ９０と通信を行う機能を実現する。通信部は、他のコンピュータ９０から送信された情報を受信し、制御部へ入力することができる。制御部は、各種プログラムに従ってプロセッサ９１に、受信した情報に対する情報処理を実行させることができる。また、通信部は、制御部から出力された情報を他のコンピュータ９０へ送信することができる。

以上、本開示のいくつかの実施形態を説明したが、これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものとする。

＜付記＞
以上の各実施形態で説明した事項を以下に付記する。
（付記１）
プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、プログラムは、プロセッサに、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行させるプログラム。
（付記２）
判断するステップにおいて、所定の条件は、初めて作成されたデッキの使用に関する条件を含む（付記１）に記載のプログラム。
（付記３）
初めて作成されたデッキの使用に関する条件は、デッキが使用された対戦の回数、デッキが使用された対戦の勝利数、所定の対戦会へのデッキのエントリー回数、又は所定の対戦会でのデッキを使用した第１プレイヤの所定順位の獲得の少なくともいずれか一つの条件を含む（付記２）に記載のプログラム。
（付記４）
登録するステップにおいて、デッキを構築する複数のデジタルカードに関する情報と第１プレイヤに関する情報とを、コンピュータネットワークにより形成される分散型台帳に記憶する（付記１）乃至（付記３）のいずれかに記載のプログラム。
（付記５）
所定のプレイヤにより作成されたデッキが登録されると、プレイヤが作成したデッキが新たに登録されたことを他プレイヤに通知するステップをプロセッサに実行させる（付記１）乃至（付記４）のいずれかに記載のプログラム。
（付記６）
登録されたデッキが第２プレイヤに貢献した度合に基づいて第１プレイヤに特典を付与するステップをプロセッサに実行させる（付記１）乃至（付記５）のいずれかに記載のプログラム。
（付記７）
第１プレイヤが第２プレイヤに貢献した度合に基づいて第１プレイヤに特典を付与するステップをプロセッサに実行させる（付記１）乃至（付記６）のいずれかに記載のプログラム。
（付記８）
プロセッサと、メモリとを備えるコンピュータに実行される方法であって、プロセッサが、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行する方法。
（付記９）
制御部と、記憶部とを備える情報処理装置であって、制御部が、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行する情報処理装置。
（付記１０）
第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付ける手段と、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録する手段と、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含める手段とを具備するシステム。

１…システム
１０…端末装置
１２…通信ＩＦ
１２０…通信部
１３…入力装置
１３１…タッチ・センシティブ・デバイス
１４…出力装置
１４１…ディスプレイ
１５…メモリ
１５０…位置情報センサ
１６…ストレージ
１６０…カメラ
１７…音声処理部
１７１…マイク
１７２…スピーカー
１８０…記憶部
１９…プロセッサ
１９０…制御部
２０…サーバ

Claims (10)

1. プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、前記プログラムは、前記プロセッサに、
   第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、
   登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであるか否か判断するステップと、
   初めて作成されたデッキである場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録するステップと、
   登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを初めて作成したプレイヤとして、前記第１プレイヤに関する情報を含めるステップと
   を実行させるプログラム。
2. 前記判断するステップにおいて、前記デッキが、初めて作成されたデッキであり、かつ、デッキの使用についての所定の条件を満たすか否かを判断し、
   前記登録するステップにおいて、初めて作成されたデッキであり、かつ、前記所定の条件を満たすデッキである場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録する請求項１記載のプログラム。
3. 前記デッキの使用についての所定の条件は、前記デッキが使用された対戦の回数、前記デッキが使用された対戦の勝利数、所定の対戦会への前記デッキのエントリー回数、又は所定の対戦会での前記デッキを使用した前記第１プレイヤの所定順位の獲得の少なくともいずれか一つの条件を含む請求項２記載のプログラム。
4. 前記登録するステップにおいて、前記デッキを構築する複数のデジタルカードに関する情報と前記第１プレイヤに関する情報とを、コンピュータネットワークにより形成される分散型台帳に記憶する請求項１記載のプログラム。
5. 所定のプレイヤにより作成されたデッキが登録されると、前記プレイヤが作成したデッキが新たに登録されたことを他プレイヤに通知するステップを前記プロセッサに実行させる請求項１記載のプログラム。
6. 登録されたデッキが前記第２プレイヤに貢献した度合に基づいて前記第１プレイヤに特典を付与するステップを前記プロセッサに実行させる請求項１記載のプログラム。
7. 前記第１プレイヤが前記第２プレイヤに貢献した度合に基づいて前記第１プレイヤに特典を付与するステップを前記プロセッサに実行させる請求項１記載のプログラム。
8. プロセッサと、メモリとを備えるコンピュータに実行される方法であって、前記プロセッサが、
   第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、
   登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであるか否か判断するステップと、
   初めて作成されたデッキである場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録するステップと、
   登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを初めて作成したプレイヤとして、前記第１プレイヤに関する情報を含めるステップと
   を実行する方法。
9. 制御部と、記憶部とを備える情報処理装置であって、前記制御部が、
   第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、
   登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであるか否か判断するステップと、
   初めて作成されたデッキである場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録するステップと、
   登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを初めて作成したプレイヤとして、前記第１プレイヤに関する情報を含めるステップと
   を実行する情報処理装置。
10. 第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付ける手段と、
    登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであるか否か判断する手段と、
    初めて作成されたデッキである場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録する手段と、
    登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを初めて作成したプレイヤとして、前記第１プレイヤに関する情報を含める手段と
    を具備するシステム。