登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される1以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザIDを割り当てて登録する登録手段と、前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの1つの階級を示す階級IDを当該ユーザのユーザIDに関連付けることにより階級を付与する階級付与手段と、グループを構成するユーザのユーザIDを追加する、固有のグループIDを有する1以上のグループテーブルを生成することにより、前記1以上のグループを生成するグループ生成手段と、前記登録されているユーザの各々を、同一の階級を示す階級IDが関連付けられているユーザIDを同一のグループテーブルに追加することによって、前記1以上のグループに分類する分類手段と、前記登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザIDに関連付けて管理するログイン管理手段と、を有し、前記分類手段は、ユーザIDに関連付けられている前記ログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザIDをグループテーブルに追加しないことにより、当該ユーザを前記リーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザIDに関連付け、前記階級付与手段は、前記フラグが関連付けられたユーザIDについて前記ログイン管理手段がログイン要求を受け付けた後に、前記予め定められた種類の階級のうちの最下位の階級を示す階級IDを当該ユーザIDに関連付けるともに、当該フラグの関連付けを削除することを特徴とするゲームシステム。前記リーグ戦は所定の開催期間をシーズンとして定義し、少なくとも最後に終了したシーズンのリーグ戦に参加していたユーザの各々について、当該最後に終了したシーズンのリーグ戦に参加していたことを示すフラグをユーザIDに関連付ける参加管理手段をさらに有し、前記登録手段は、ユーザの前記ユーザ管理データベースへの登録を時系列順に管理しており、前記分類手段は、各階級について、当該階級の階級IDが関連付けられたユーザIDの数が、当該階級について予め定められたグループ上限数のグループテーブルに追加できるユーザIDの数を超える場合、当該階級の階級IDが関連付けられたユーザIDのうち、前記最後に終了したシーズンのリーグ戦に参加していたことを示すフラグが関連付けられているユーザIDを優先的にグループテーブルに追加した後、前記最後に終了したシーズンのリーグ戦に参加していたことを示すフラグが関連付けられていないユーザIDを、前記ユーザ管理データベースに登録された順に当該グループテーブルに追加することを特徴とする請求項1に記載のゲームシステム。前記リーグ戦は、前記ゲームシステムが開催する公式リーグ戦と、前記登録されているユーザがホストとなって開催するオリジナルリーグ戦とがあり、前記階級付与手段は、前記公式リーグ戦に参加したユーザについては、前記公式リーグ戦の各グループにおけるユーザ同士の対戦の戦績に応じて決定される順位に基づいて、予め定められた順位のユーザのユーザIDに関連付けられた階級IDを異なる階級IDに変更し、前記オリジナルリーグ戦に参加したユーザについては、当該ユーザのユーザIDに関連付けられた階級IDの、前記オリジナルリーグ戦の各グループにおけるユーザ同士の対戦の戦績に基づく変更を行わないことを特徴とする請求項1または2に記載のゲームシステム。前記階級付与手段によるユーザIDに関連付けられた階級IDの変更が行われた結果、変更後の階級IDが関連付けられたユーザIDの数が、当該階級IDが示す階級について予め定められた前記公式リーグ戦におけるグループ上限数のグループテーブルに追加できるユーザIDの数を超える場合、当該グループ上限数を引き上げて前記公式リーグ戦を開催することを特徴とする請求項3に記載のゲームシステム。各階級IDが関連付けられたユーザIDの数が、当該階級IDが示す階級についての前記グループ上限数のグループテーブルに追加できるユーザIDの数を超える場合、一時的に当該グループ上限数を引き上げて前記公式リーグ戦を開催した後、前記階級付与手段は、前記グループ上限数を引き上げた階級の階級IDが関連付けられたユーザIDを追加したグループテーブルにおける階級IDを変更するユーザIDの数を増やすことにより、前記グループ上限数を引き上げた階級の階級IDが関連付けられたユーザIDの数を、引き上げる前のグループ上限数のグループテーブルに追加できるユーザIDの数にすることを特徴とする請求項4に記載のゲームシステム。登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される1以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムの制御方法であって、前記ゲームシステムの登録手段が、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザIDを割り当てて登録する登録工程と、前記ゲームシステムの階級付与手段が、前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの1つの階級を示す階級IDを当該ユーザのユーザIDに関連付けることにより階級を付与する階級付与工程と、前記ゲームシステムのグループ生成手段が、グループを構成するユーザのユーザIDを追加する、固有のグループIDを有する1以上のグループテーブルを生成することにより、前記1以上のグループを生成するグループ生成工程と、前記ゲームシステムの分類手段が、前記登録されているユーザの各々を、同一の階級を示す階級IDが関連付けられているユーザIDを同一のグループテーブルに追加することによって、前記1以上のグループに分類する分類工程と、前記ゲームシステムのログイン管理手段が、前記登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザIDに関連付けて管理するログイン管理工程と、有し、前記分類工程において前記分類手段は、ユーザIDに関連付けられている前記ログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザIDをグループテーブルに追加しないことにより、当該ユーザを前記リーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザIDに関連付け、前記階級付与工程において前記階級付与手段は、前記フラグが関連付けられたユーザIDについて前記ログイン管理手段がログイン要求を受け付けた後に、前記予め定められた種類の階級のうちの最下位の階級を示す階級IDを当該ユーザIDに関連付けるともに、当該フラグの関連付けを削除することを特徴とするゲームシステムの制御方法。コンピュータを、請求項1乃至5のいずれか1項に記載のゲームシステムの各手段として機能させるためのプログラム。登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される1以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、前記ゲームシステムは、表示手段に表示するユーザインタフェースにおいて登録要求を行なったユーザに割り当てられた、ユーザ管理データベースにおける固有のユーザIDを示すユーザID表示部と、前記登録要求を行なったユーザに付与された、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの1つの階級を示す階級表示部と、前記各グループに分類されたユーザのユーザIDを通知するグループメンバリストであって、前記登録されているユーザのうち、前記ゲームシステムに最後にログインした日時が、現在日時から所定期間以上前であるユーザのユーザIDを含まないグループメンバリストを表示するグループ表示部と、を有し、前記登録要求を行なったユーザが、前記ゲームシステムに最後にログインしてから前記所定期間以上経過後に再びログインした場合に、前記予め定められた種類の階級のうちの最下位の階級が前記階級表示部に表示されることを特徴とするゲームシステム。対戦型ゲームにおいて管理するユーザ数が増加した場合、1回のリーグ戦の開催期間が長期化してしまい、ユーザがゲームに飽きてしまう可能性がある。このため、リーグ戦の参加ユーザを、シーズンごとにランダムに複数のグループのいずれかに割り当て、対戦成績の順位付けをグループで完結させることで、1回のリーグ戦の開催期間を短縮することが好ましい。オンラインの対戦型ゲームでは、特許文献1のように、システムによってランダムに決定された見ず知らずのユーザと対戦を行うよりも、学校の友人や家族等、現実世界の知人であるユーザと対戦を行う方が、現実世界での友好関係の向上も見込まれるため好まれる。しかしながら、参加ユーザのグループ分けがランダムに行われる場合、必ずしも知人のユーザと同一のグループに振り分けされないため、ユーザの興趣をそいでしまう可能性があった。例えば、仲間内でリーグ戦の順位を競うことをユーザが所望したとしても、仲間内の各ユーザが別々のグループに割り当てられた場合は、グループごとの成績による相対的な順位での評価しかできないため、ユーザのリーグ戦への参加意欲を減退させてしまう可能性があった。オンラインゲームにおいてユーザ同士の交流関係を増進することは、より長期的な利用ユーザを増加させることにもつながるため、ユーザ間の交流を阻害しないグループ分けが考慮されることが望ましい。一方で、運営開始当初の参加ユーザの絶対数が少ない場合や、参加ユーザ数がグループ分けにおいて端数が生じうる場合等、1グループの参加ユーザ数が予め設定された定員に満たない場合は、NPCNonPlayerCharacterと呼ばれる仮想ユーザを参加させることにより、定員のユーザでリーグ戦を行うことができる。対戦型ゲームの場合、少なくとも一方にユーザが参加する対戦では、戦況を如何に魅力的に提示するかが重要であるため、詳細な戦況を生成する処理が実行される必要があるが、NPC同士の対戦については、大抵のユーザにとって当該対戦の戦況は興味のない情報であるため、詳細な戦況を生成する処理は省略することができる。しかしながら、上述したようにリーグ戦のグループ分けがランダムに行われる場合、例えばリーグ戦の全てのグループにおいてユーザとNPCとが存在するように振り分けされる可能性がある。この場合、戦況の生成処理が省略不可能なユーザ同士あるいはユーザ対NPCの対戦数が増加するため、対戦を管理するサーバの処理を軽減することができなかった。また、階級制度を導入した対戦ゲームにおいて、ゲームバランスのために各階級の上限ユーザ数を制限する場合、リーグ戦に長期間参加していないユーザが階級に参加対象として含まれてしまい、後からゲームを始めたユーザがリーグ戦に参加したとしても、人数制限によって昇格ができなくなってしまうことがあった。本発明は、上述の問題点の少なくともいずれかを解決することを目的とする。前述の目的の1つを達成するために、本発明の1つの態様のゲームシステムは、以下の構成を備える。登録されているユーザが参加するリーグ戦であって、登録されているユーザを、各グループが同一の階級に属するユーザで構成される1以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザIDを割り当てて登録する登録手段と、登録されているユーザの各々について、ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの1つの階級を示す階級IDを当該ユーザのユーザIDに関連付けることにより階級を付与する階級付与手段と、グループを構成するユーザのユーザIDを追加する、固有のグループIDを有する1以上のグループテーブルを生成することにより、1以上のグループを生成するグループ生成手段と、登録されているユーザの各々を、同一の階級を示す階級IDが関連付けられているユーザIDを同一のグループテーブルに追加することによって、1以上のグループに分類する分類手段と、登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザIDに関連付けて管理するログイン管理手段と、を有し、分類手段は、ユーザIDに関連付けられているログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザIDをグループテーブルに追加しないことにより、当該ユーザをリーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザIDに関連付け、階級付与手段は、フラグが関連付けられたユーザIDについてログイン管理手段がログイン要求を受け付けた後に、予め定められた種類の階級のうちの最下位の階級を示す階級IDを当該ユーザIDに関連付けるともに、当該フラグの関連付けを削除することを特徴とする。このような構成により本発明によれば、公平な階級制度を実現することが可能となる。[実施形態1]<ゲーム概要>本発明の1つの実施形態に係るゲームシステムは、各ユーザが予め登録した、複数のカードからなるデッキを用いたユーザ同士の対戦を実現する、シミュレーション型のオンライン対戦カードゲームを実行する。図1は、ユーザ同士が対戦する際の、各ユーザが所有する表示装置に表示される、対戦画面の画面構成を示している。対戦画面100は、対戦相手のユーザの手持ちカードが表示される相手エリア101、自身の手持ちカードが表示される自エリア102、及び各ユーザのカードが並べられ、カード毎に設定されたパラメータに応じて、カードに描かれたキャラクタ同士が戦闘を行う戦闘エリア103から構成される。相手エリア101及び自エリア102にはそれぞれ、ユーザの分身となるアバター104、対戦に使用するデッキを構成するカードがランダムに設定された順序で積み上げられたカード山105、戦闘エリア103に配置するカードの待機エリア106、使用不可能になったカードが配置される廃棄エリア107、アバター104の体力ゲージ等を含むゲージ108が含まれる。ユーザ同士の対戦は、各ユーザが自身のエリアのカード山105からカードを1枚ずつ取得するターン制で行われる。カード山105から取得されたカードは、待機エリア106に置かれた後、所定数のターンが経過後に戦闘エリア103に移動され、当該カードに描かれたキャラクタが戦闘可能な状態になる。なお、カード山105に積み上げられたカードは、次に取得されるカードがわからないよう、例えば裏返された状態で表示される。また、各カードには描かれたキャラクタに応じた待機時間ターン数が設定されており、待機エリア106に置かれてからカードに応じた待機時間の経過後に、当該カードは戦闘エリア103に移動される。カードが戦闘エリア103に移動されると、同じく戦闘エリア103に置かれている相手ユーザのカードとの間で、描かれているキャラクタ同士の戦闘イベントが実行される。当該キャラクタ同士の戦闘イベントの結果、体力がなくなったキャラクタのカードは、使用不可能な状態となり、廃棄エリア107に移動される。なお、戦闘エリア103に相手ユーザのカードが置かれていない場合は、戦闘エリア103に移動したカードに描かれたキャラクタの攻撃対象は、相手ユーザのアバター104となる。このように、ユーザ同士が戦闘エリア103にカードを出し合うことにより対戦は進行し、デッキのカードが全て廃棄エリア107に移動された、あるいはアバター104の体力ゲージが0になったユーザが当該対戦の敗者となる。<システム構成>上述のようなユーザ同士のオンライン対戦カードゲームのゲームプログラムを実行するゲームシステムのシステム構成について説明する。図2は、本実施形態のゲームシステムの例示的な構成を示している。本実施形態のゲームシステムでは、各ユーザが使用する例えばPC等のユーザ端末202aあるいはbは、ネットワーク203を介してゲームサーバ201に接続する。各ユーザは、ユーザ端末202上において、例えばインターネットブラウザを起動し、ゲームサーバ201が提供するURLにアクセスしてゲームサーバ201にログイン処理を行うことにより、上述したオンライン対戦カードゲームのサービスを利用することができる。ゲームサーバ201は、オンライン対戦カードゲームに登録しているユーザの管理、及びオンライン対戦カードゲームに係るゲームプログラムの実行を行う。ゲームサーバ201はゲームプログラムに従って、ユーザ端末202で実行されているブラウザにおいて所定の表示を行うようにネットワーク203を介して情報を出力する。ゲームサーバ201においてゲームプログラムを実行することにより、ユーザ端末202を使用する各ユーザのデッキ編成、及びユーザ同士の対戦を実現する。なお、ユーザ端末202の各々は、例えば表示装置及びポインティングデバイスを有するPCであってよい。ゲームサーバ201の機能構成ここで、ゲームサーバ201の機能構成について図3を用いて詳細に説明する。CPU301は、ゲームサーバ201が備える各ブロックの動作を制御する。具体的にはCPU301は、例えばROM302に記憶されている本実施形態のオンライン対戦カードゲームのゲームプログラムを読み出し、RAM303に展開して実行することにより、各ブロックの動作を制御する。ROM302は、不揮発性メモリであり、本実施形態のオンライン対戦カードゲームのゲームプログラムに加えて、例えば各ブロックの動作及びゲームプログラム上で用いる動作パラメータを記憶する。RAM303は、揮発性メモリであり、ゲームプログラムの展開領域としてだけでなく、例えば各ブロックの動作において出力された中間データの一時的な記憶領域としても用いられる。ネットワークI/F306は、ゲームサーバ201をネットワーク203に接続するためのインタフェースであり、所定のプロトコルに準拠した通信接続を実現する。ゲームサーバ201は、ネットワークI/F306を介してネットワーク203に接続されることにより、同じくネットワーク203に接続されているユーザ端末202からのログイン要求を受信する。またゲームサーバ201は、当該ゲームサーバ201にログインしたユーザ端末202との間で、ネットワークI/F306を介して情報の送受信を行う。例えば1人のユーザが使用するユーザ端末202に対してゲームサーバ201からの情報送信を行う場合は、まず当該ユーザがゲームサーバ201にログインした際に、使用しているユーザ端末202を特定するアドレス情報をCPU301が当該ユーザのユーザID各ユーザ固有の識別情報に関連付けて、後述するユーザ管理データベース304に記憶する。CPU301は、ゲームプログラムの実行において当該ユーザIDについて生成した情報を、当該ユーザIDに関連付けられたアドレス情報で定義された通信経路を用いてユーザ端末202に送信する。ユーザ管理データベース304は、上述したように、ゲームサーバ201にログインする全てのユーザについて、各ユーザに固有のユーザIDを割り当てて管理する。ユーザ管理データベース304において管理される情報ユーザデータは、ユーザIDに限らず、例えば図14aに示すように、各ユーザの階級を示す階級ID1402、各ユーザが所有するカードの情報1405及び作成したデッキの情報1406等のユーザ情報を含む。当該ユーザ情報は、それぞれのユーザIDに関連付けられて管理される。なお、ユーザ管理データベース304への新規ユーザの登録は、ユーザ端末202からのネットワーク203を介した登録要求がネットワークI/F306において受信された場合に、CPU301が行う。CPU301は、ネットワークI/F306において受信された登録要求に含まれる情報を取得し、当該登録要求を行なったユーザに対して固有のユーザIDを割り当てるとともに、例えばユーザ名1403や接続端末アドレス情報1404等の取得した情報を当該ユーザIDに関連付けて記憶する。なお、ユーザIDは、ユーザ管理データベース304への登録順の情報を含むようにCPU301が所定の規則に従って生成してもよいし、ユーザにより指定された文字列の情報を用いてもよい。ユーザにより指定された文字列の情報を用いる場合は、ユーザIDにはさらに、ユーザ管理データベース304の内部IDとして登録順を示すIDが割り当てられるものとする。カードデータベース305は、本実施形態のオンライン対戦カードゲームにおいて使用する全種類のカードの情報を管理する。カードは、各々異なるカードIDが割り当てられたカードデータとして管理される。例えば図14dに示すように、カードデータには、カードに描かれているキャラクタのキャラクタ名1441や、ゲーム上での当該キャラクタの攻撃力や防御力等のパラメータ1442の情報が含まれる。パラメータ1442は、それぞれのカードのカードID1440に関連付けられている。なお、上述した各ユーザの所有するカードの情報1405は、例えば全種類のカードIDに対して所有するか否かの論理型の情報、及び所有する枚数を示す情報等であり、ユーザIDに関連付けてユーザ管理データベース304に記憶される。また本実施形態のオンライン対戦カードゲームでは、ユーザは後述するゲームの種類ごとに、1以上のカードで構成されるデッキを編成することができる。デッキの情報1406は、ユーザIDに関連付けられてユーザ管理データベース304に管理される。ゲームの1つの種類について編成するデッキの情報は、当該ゲームの種類を示すゲームID、ユーザが管理するデッキを識別するデッキID、及びデッキを構成する1以上のカードのカードID等を有する。グラフィックデータベース307は、本実施形態のオンライン対戦カードゲームにおいて、ユーザ端末202の表示装置に表示するグラフィカルユーザインタフェースGUIを生成するデータ群を記憶する。CPU301は、ユーザ端末202におけるユーザ入力、及びゲームの進行に応じたGUIを生成するデータ群をグラフィックデータベース307より読み出し、ネットワークI/F306からネットワーク203を介して各ユーザのユーザ端末202に送信する。グループデータベース308は、本実施形態のオンライン対戦カードゲームにおいて、後述する公式リーグにおけるユーザ振り分け単位であるグループごとに作られたグループテーブルを管理する。グループテーブルには、グループに振り分けされたユーザのユーザIDが追加される。各グループテーブルは、例えば図14cのように、固有のグループID1430が割り当てられて管理される。本実施形態のオンライン対戦カードゲームでは、公式リーグに参加するユーザを、付与さえている後述の階級が同一であるユーザでグループが構成されるように振り分ける。このため各グループテーブルには、階級ID1431が含まれ、当該階級IDと同一の階級IDが付与されたユーザの情報1432、1433が含まれる。このように構成された本実施形態のゲームシステムにおいて、ユーザに提供されるゲーム及びその処理について、以下に説明する。<ゲーム種類>ユーザがゲームサーバ201にログインすると、図4に示すようなメニュータブを有する画面がユーザ端末202の表示装置に表示される。メニュータブ401a乃至dに示されるように、本実施形態のオンライン対戦カードゲームでは、ユーザに対し、フリーバトル401a、オリジナルリーグ401b、公式リーグ401c、迎撃戦401dの4つのゲームを提供する。提供されるゲームは、それぞれ以下のような特徴を有する。フリーバトル:ユーザが、現在ログインしている他のユーザの中から対戦ユーザを任意に選択し、当該対戦ユーザが予めフリーバトル用に設定したデッキと対戦を行うなお、フリーバトルに限りデッキ構築の手間を省くためにもオリジナルリーグ用又は公式リーグ用に設定したデッキで代用するようにしても良い。オリジナルリーグ:1人のユーザがホストとなり、ホストが設定したレギュレーションで複数のユーザの参加を募って開催するリーグ戦。公式リーグ:ゲームシステム上で開催される、ユーザの戦績によって順位付けを行う、公式リーグ用のデッキを編成済みの全ユーザが参加となるリーグ戦。リーグ戦の会期が長期化しないよう、全ユーザは1以上のグループに振り分けされて対戦を行う。迎撃戦:他のユーザにフリーバトルの対戦ユーザとして選択された際の対戦の内容及び結果の表示を行う。なお、本実施形態においてはリーグ戦とは、リーグ戦内の1グループに参加しているユーザ同士の総当たり戦を行うものとして説明するが、例えばトーナメント戦や、予め定められた会期内で実行可能な所定数の対戦を行うものであってもよい。<公式リーグ詳細>ここで、本発明に係る公式リーグの詳細について、以下に説明する。なお、以下の説明では便宜上、以下の定数を用いて説明する。各定数を示す情報は、ROM302あるいはRAM303に記憶されているものとする。参加上限数Umaxt:公式リーグに参加可能なユーザ数上限ユーザ数Ucmax:公式リーグの各階級について設定されたユーザの上限数グループ総数Gmax:公式リーグの各階級について設定されたグループ数階級実ユーザ数Uruser:公式リーグの各階級について、当該階級が付与されている実ユーザの数昇格順位Rup:公式リーグの各階級について設定された1つのグループから1つ上位の階級に昇格するユーザ順位の条件降格順位Rdown:公式リーグの各階級について設定された1つのグループから1つ下位の階級に降格するユーザ順位の条件昇格人数Uup:公式リーグの各階級について設定された1つのグループから1つ上位の階級に昇格するユーザの数残留人数Ustay:公式リーグの各階級について設定された1つのグループから同一の階級に残留するユーザの数降格人数Udown:公式リーグの各階級について設定された1つのグループから1つ下位の階級に降格するユーザの数非降格人数Undown:公式リーグの各階級について設定された1つのグループから1つ下位の階級に降格しないユーザの数昇格人数Uup残留人数Ustay昇格総人数Uupt:公式リーグの各階級から1つ上位の階級に昇格するユーザの総数残留総人数Ustayt:公式リーグの各階級に残留するユーザの総数降格総人数Udownt:公式リーグの各階級から1つ下位の階級に降格するユーザの総数非降格総人数Undownt:公式リーグの各階級から1つ下位の階級に降格しないユーザの総数昇格総人数Uupt残留総人数Ustayt振り分けグループ数Gruser:公式リーグの各階級について、実ユーザが振り分けされるグループの数上述したように公式リーグは、基本的には公式リーグ用のデッキを編成済みの全ユーザが参加対象者となる。例えば1人のユーザが公式リーグ用のデッキを編成済みであるか否かは、CPU301が、ユーザ管理データベース304に記憶されている当該ユーザのユーザIDを有するユーザデータを参照して判断する。具体的にはCPU301は、当該ユーザIDに関連付けられている編成デッキ情報1406に、公式リーグのゲームIDが含まれるデッキ情報が存在するか否かを判断する。公式リーグは、1つの会期としてシーズンという単位を設ける。シーズンの長さは、リーグ戦の1グループにおけるユーザの総当たり戦の実行に要する期間に応じて設定される。例えば1グループに16人のユーザが振り分けされ、1シーズンあたり1人のユーザについて3回対戦する総当たり戦を行う場合、シーズンの長さは16-1×3=45戦分の長さとなる。ユーザの順位付けは1シーズンの勝利数に応じてグループごとに行う。本実施形態では、公式リーグに参加している全ユーザに対してグループごとに順位付けを行い、グループ内の順位に応じて階級の昇格あるいは降格を行う。階級制度ここで、本実施形態のオンライン対戦カードゲームにおける、階級制度について説明する。公式リーグでは、同じようなレベル操作スキル、あるいはデッキ構成を有するユーザ同士を同一グループに振り分けることで、どちらかのユーザが有利に戦況を進めてしまうような対戦を回避する。このようにすることでユーザの興趣を長続きさせることができる。具体的にはCPU301は、グループへのユーザの振り分けを行う際にユーザ管理データベースに記憶されているユーザデータを参照し、同一の階級IDが関連付けられているユーザIDでグループを構成するように分類する。即ち、1つのグループには、同一の階級が付与されたユーザが分類される。階級の情報は、例えば新規ユーザがユーザ登録後、公式リーグ用のデッキを編成した際に当該ユーザに対して最初に付与される。このとき付与される階級は、予め定められた種類の階級のうちの最下位の階級である。CPU301は、当該最下位の階級を示す階級IDをユーザのユーザIDに関連付けてユーザ管理データベース304に記憶させる。本実施形態のオンライン対戦カードゲームでは、図5aに示すように5段階の階級が設けられている。各階級には上限ユーザ数Ucmax1、Ucmax2、Ucmax3、Ucmax4、及びUcmax5が設定されている。また、公式リーグの各グループに属するユーザは、1シーズン終了後のグループ内順位に応じて、階級の昇格あるいは降格が実行される。具体的には、階級の昇格あるいは降格の条件は階級のグループごとに例えば図5bのように定められており、各階級間では公式リーグの1シーズンごとに決められた人数のユーザの階級が変動する。例えば、階級の1つであるC3では、当該階級の1つのグループにおいて、1シーズン終了後の順位が1~3位の3名昇格人数Uupのユーザは1つ上の階級のC2に昇格する。また、順位が11~16位の6名降格人数Udownのユーザは1つ下の階級のC4に降格する。また、順位が4~10位の7名残留人数Ustayのユーザについては階級の変更はなく、階級C3に残留する。図示されるように、C3のグループ総数は1600であるため、1シーズン終了後にはC3全体で1600×3=4800人昇格総人数UuptのユーザがC2に昇格し、1600×6=9600人降格総人数UdowntのユーザがC4に降格することになる。なお、上述したオリジナルリーグは、公式リーグとは無関係に1人のユーザがホストとなって一部のユーザを対象に開催するものであるため、当該オリジナルリーグの対戦の戦績は階級の変動に用いられない。ボーナスマッチグループ内の総当たり戦による勝利数によって階級の昇格あるいは降格を行う場合、昇格あるいは降格の対象となる順位昇格順位Rup、降格順位Rdownに、勝利数が同数であるユーザが複数存在することが生じうる。これに対し、勝利数、及び引分数の各々について予め設定された係数を、それぞれの数に応じて加算して得られる点数勝ち点を用いることにより、同一の勝利数のユーザ間に点数の差をつけて、順位に差を付ける方法が考えられる。しかしながら、本実施形態のオンライン対戦カードゲームのようにターン制を有するゲームでは対戦結果が引き分けとなる可能性が低く、差がつかない可能性がある。本実施形態では、勝利数が同数のユーザが複数存在する場合に当該ユーザの順位に差が付くように、上述したグループに属するユーザの総当たり戦に加え、複数回のボーナスマッチを設ける。ボーナスマッチではユーザは、登録要求を受けずにゲームシステムが生成してユーザ管理データベース304に記憶した、NPCと呼ばれる仮想ユーザ以下、ボーナスNPCと対戦する。当該ボーナスマッチでユーザがボーナスNPCに勝利した場合、当該勝利はグループの総当たり戦における勝利数には影響しないが、上述した勝ち点に対して、一定の点数を加えるものとする。このようにすることで、総当たり戦の勝利数では階級の昇格あるいは降格を行うユーザが決定できない場合に、当該総当たり戦の戦績には無関係のボーナスマッチの対戦結果による勝ち点の加算を考慮して、同一の順位のユーザに差をつけることができる。なお、公式リーグにおける各ユーザの対戦の戦績の情報は、図14cに示すように、グループに参加する各ユーザのユーザIDに関連付けられてグループテーブルに含まれればよい。具体的にはグループテーブルに含まれる各ユーザの情報1432、1433には、ユーザのユーザID、公式リーグで使用するデッキ情報、勝利数、引分数、勝ち点、及びボーナスマッチでのボーナスNPCとの戦績が含まれる。なお、例えばゲームのシナリオに登場する重要キャラクタ等をボーナスNPCとして割り当てることにより、ユーザ同士の対戦だけでなく、ゲームの世界観をユーザに楽しませる効果も与えることができる。またボーナスマッチにユーザが勝利した場合に勝ち点に加えられる一定の点数は、総当たり戦の1つの対戦で勝利した場合に勝ち点に加えられる点数よりも大きくすることで、同一の順位のユーザがいた場合に差がつきやすくしてもよい。仮想ユーザの種類本実施形態のオンライン対戦カードゲームでは、ユーザ端末202からの登録要求を受けてユーザ管理データベース304に追加されたユーザ以下、実ユーザを公式リーグの1以上のグループに振り分ける。この結果、グループの実ユーザの数が定員に満たないグループが存在する場合には、CPU301は、仮想ユーザ以下、穴埋めNPCを追加することで当該グループを定員にする。なお、穴埋めNPCはボーナスNPCとは別に設けられているものとする。また、実ユーザと仮想ユーザとは、異なるルールで生成されたユーザIDが付与されてユーザ管理データベース304に管理される。実ユーザ及び仮想ユーザのいずれであるか否かは、CPU301が当該ユーザIDを参照することにより判別可能であるものとする。しかしながら、実ユーザと仮想ユーザとの区別はこれに限らず、例えばユーザ管理データベース304において実ユーザであるか否かを示す論理型の情報がユーザIDに関連付けられて記憶されることによって判別可能であってもよい。本実施形態のオンライン対戦カードゲームでは、図5bに示すように各階級について予め定められた固定数グループ総数Gmax1、Gmax2、Gmax3、Gmax4、及びGmax5のグループを毎シーズン作成してリーグ戦を開催する。公式リーグの1シーズンを開始する前に行われるグループ分けでは、実ユーザは付与されている階級について作成されるグループのうちのいずれかに振り分けされる。この結果、振り分けられた実ユーザの数が定員に満たないグループについては、定員になるまで穴埋めNPCが追加される。例えば、ある階級を示す階級IDが付与されている実ユーザをグループに振り分けるときを考える。このとき、1つのグループのグループテーブルに追加された実ユーザのユーザIDの数が、グループの定員例:16人に満たない数例:5人であった場合、当該グループテーブルにはユーザ数が定員になるまで、穴埋めNPCのユーザIDが追加される例:16ー5=11人。上述したように対戦型ゲームにおいては、実ユーザ同士の対戦及び実ユーザと仮想ユーザとの対戦は、詳細な戦況を生成する処理を実行する必要がある。本実施形態のオンライン対戦カードゲームでは、各階級において実ユーザが振り分けされるグループ数を制限して実ユーザの振り分けを行うことで、当該詳細な戦況を生成する処理の実行を最小限にしてサーバ負荷を軽減する。即ち、実ユーザが振り分けされないグループについては、詳細な戦況の生成処理の実行及びグループの戦績の通知を行う必要がない。このため、当該グループの対戦に係る戦況の生成処理は省略することができる。公式リーグ戦においてユーザ端末202の表示装置に表示される表示画面構成は、例えば図6のようになっている。図示されるように、公式リーグ戦における表示画面には、ユーザ端末202を使用するユーザが参加しているグループの詳細情報601、総当たり戦において次にユーザが対戦する相手ユーザの情報602、次に行われるグループ内の対戦情報603、及びグループに参加している全ユーザの現在のシーズンの戦績604が含まれる。このように、公式リーグに参加している各ユーザに対しては、当該ユーザが参加しているグループの情報のみが、公式リーグ戦における表示画面として提供される。即ち、ユーザが参加していないグループについてはユーザに通知しないことにより、グループの戦績を生成する処理を省略可能である。なお、図6に示されるようにシーズン戦績604には、グループに参加している全ユーザのユーザ名ユーザIDであってもよい、勝利数、勝率、勝ち点等の情報が、現在の順位に応じてリスト表示されている。当該リストにおいて、穴埋めNPCは例えばNPCと明示されることにより識別可能にされている。またグループの詳細情報601には、シーズン終了後に当該グループに参加しているユーザのうち、上位の階級に昇格するユーザ数及び下位の階級に降格するユーザ数の情報、及び当該グループに参加している実ユーザ数であるプレイ人数の情報が表示される。一方で、当該オンライン対戦カードゲームの運営開始直後は、昇格人数が限られているため、実ユーザは下位の階級に偏る。このとき、グループに昇格人数Uupと残留人数Udownの合計数非降格人数Undownを超える実ユーザがグループに振り分けた場合、シーズン終了後に階級が降格する実ユーザが存在することになる。例えば1グループが定員16人であり、階級C4のグループに実ユーザ48人を振り分ける場合、実ユーザが振り分けられる最小のグループ数は3となる。そして3つのグループに48人の実ユーザを振り分けてゲームを行うと、シーズン終了後には図5bに従って、各グループの11~16位の18人のユーザは降格することになる。即ち、上位の階級は上限ユーザ数となる実ユーザが存在しないにも関わらず、下位の階級に降格する実ユーザが存在するため、上位の階級に実ユーザが増加しづらい。つまり、実ユーザの中には上位の階級になかなか昇格できない実ユーザもおり、当該実ユーザのゲームへの参加意欲を削ぐことになってしまう。また、上位の階級に昇格した実ユーザも、対戦相手となる実ユーザが増加しにくく、決まった実ユーザあるいは穴埋めNPCとの対戦の機会が多いため、ゲームに飽きてしまう可能性がある。このため、本実施形態のオンライン対戦カードゲームでは階級の各々について、当該階級が付与された実ユーザの数が、シーズン終了後に当該階級から降格しない非降格総人数Undowntを超えるまでは、少なくとも1つのグループに降格人数Udownの穴埋めNPCを追加するものとする。例えば、上述したようにC3全体における非降格総人数Undownt3は、C3の上限ユーザ数Ucmax3から降格総人数Udownt3を減算した25600-9600=16000人となる。このため、本実施形態ではC3の階級IDが付与された実ユーザの数が16000人を超えるまでは、CPU301は1つのグループに降格人数Udown3に相当する6人の穴埋めNPCを少なくとも追加してグループ分けを行う。このときCPU301は、例えば穴埋めNPCは実ユーザとの対戦時には敗北するように戦況を生成するものとし、シーズン終了後には降格順位に実ユーザがならないようにしてもよい。即ち、CPU301は、当該階級が付与された実ユーザの数が当該階級の非降格人数Undownを超えるまでは、公式リーグの1つの階級における1つのグループに、非降格人数Undownずつ実ユーザを振り分けする。そして実ユーザが振り分けされたグループの各々には、グループのユーザ数が定員となるまで、少なくとも降格人数Udownの穴埋めNPCであって、実ユーザとの対戦に必ず敗北する穴埋めNPCを追加する。このようにすることで、階級が降格する実ユーザをなくし、かつ戦況を生成する必要があるグループ数を最小限にすることができる。また、1つの階級が付与された実ユーザの数が当該階級の非降格総人数Undowntを超えた場合は、当該階級のグループ総数Gmaxのグループに実ユーザの数を均等に振り分ける。さらに実ユーザが振り分けされたグループの各々には、グループのユーザ数が定員となるまで、実ユーザとの対戦に必ず敗北する穴埋めNPCを追加することで、少なくとも降格順位Rdownになる実ユーザの数を最小限にすることができる。なお、CPU301は、実ユーザとの対戦において穴埋めNPCを必ず敗北させるか否かを、階級ごとに判断するものとする。即ち、穴埋めNPCを必ず敗北させる処理は、当該処理が行われるグループの階級よりも上位の階級において、当該階級が付与された実ユーザの数が、例えば同階級の上限ユーザ数Ucmaxあるいは所定数に満たない場合に行われる処理であってよい。つまり、当該処理は上位の階級が付与された実ユーザの数を増やすための処理であり、上位の階級が付与された実ユーザの数が所望の数になった場合には停止してよい。具体的にはCPU301は、1つの階級について公式リーグの対戦の戦況を生成する処理を行う際に、当該階級よりも上位の階級が付与された実ユーザの人数の情報をユーザ管理データベース304から取得し、当該人数が各階級について予め設定された数に満たない場合にのみ、穴埋めNPCが必ず敗北するように戦況を生成するものとする。なお、穴埋めNPCやボーナスNPCの仮想ユーザは、所有するカードやデッキ構成等が各階級に応じて異なることが好ましい。即ち、階級が上位に行くほど仮想ユーザが所有するカードは、パラメータの平均値が高くなるように設定されるものとする。本実施形態のオンライン対戦カードゲームでは、各階級について一定数の穴埋めNPC及びボーナスNPCが用意されている。穴埋めNPC及びボーナスNPCは、実ユーザと同様にそれぞれ異なるユーザIDが割り当てられて、ユーザ管理データベース304に記憶されている。グループに含まれるユーザの総当たり戦では、同一のユーザIDを含めることは戦績の処理上不可能であるため、各階級のグループ分けにおいては、1つのグループ内に同一の穴埋めNPCが存在しないようにする必要がある。このため、1つの階級について用意する穴埋めNPCの数は、1つのグループに実ユーザが1人のみが振り分けられた場合であっても、当該グループに追加する穴埋めNPCについて、同一の穴埋めNPCが存在しない数であればよい。即ち、本実施形態のように1グループにおける実ユーザと穴埋めNPCの合計数が16人として設定されている場合は、各階級に用意される穴埋めNPCの数は、最低15人あればよい。なお、例えば最上位の階級のみ、グループ内だけでなく階級内でのユーザの順位付けを行って前ユーザに公表する場合は、最上位の階級用に用意する穴埋めNPCを、当該階級の上限ユーザ数分用意するようにすればよい。これは、実ユーザが最上位の階級に存在しない場合であっても、最上位の階級における順位付けを生成するためである。またボーナスNPCの数は、ゲームのシナリオに応じて決定されればよいが、例えばシーズン毎に異なるボーナスNPCとの対戦を行えるように、1回のシーズン中には用意されているボーナスNPCのうちの一部と対戦が組まれるようにしてもよい。公式リーググループ決定処理ここで、本実施形態のゲームシステムにおける、実ユーザが分類されるグループ数を考慮した、公式リーグにおける公式リーググループ決定処理について、図7のフローチャートを用いて説明する。当該フローチャートに対応する処理は、CPU301が、例えばROM302に記憶されている対応する処理プログラムを読み出し、RAM303に展開して実行することにより実現することができる。なお、本公式リーググループ決定処理は、公式リーグの1シーズンの開始前に実行されるものとして説明する。S701で、CPU301は、ROM302に記憶されている予め定められた種類の階級のうち、まだ実ユーザのグループ分けがなされていない1つの階級の階級IDを選択する。またCPU301は、選択した階級IDで示される階級について、公式リーグで設けるグループ総数Gmaxを示す情報、当該階級の1つのグループについて設定された非降格人数Undownを示す情報、及びシーズン終了後に当該階級から降格しない非降格総人数Undownt非降格人数Undown×グループ総数Gmax、あるいは昇格総人数Uupt残留総人数Ustaytを示す情報をROM302より取得する。S702で、CPU301は、S701で選択した階級IDで示される階級が付与された実ユーザの数階級実ユーザ数Uruserを取得する。具体的にはCPU301は、S701で選択した階級IDが関連付けられてユーザ管理データベース304に記憶されている実ユーザの数を計数し、階級実ユーザ数Uruserを示す情報を取得する。S703で、CPU301は、階級実ユーザ数Uruserがシーズン終了後に少なくともS701で取得した、当該階級から降格しない非降格総人数Undownt以下であるか否かを判断する。CPU301は、階級実ユーザ数Uruserが非降格総人数Undownt以下であると判断した場合は処理をS704に移し、非降格総人数Undowntより大きいと判断した場合は処理をS705に移す。S704で、CPU301は、選択した階級IDが示す階級が付与された実ユーザを振り分けるグループの数振り分けグループ数Gruserを算出する。具体的にはCPU301は階級実ユーザ数Uruserを各グループにおいて非降格人数Undownで除し、端数を切り上げることにより振り分けグループ数Gruserを算出する。またS703で、階級実ユーザ数Uruserが、選択した階級IDが示す階級から降格しない非降格総人数Undowntより大きいと判断した場合、CPU301はS705で、振り分けグループ数をS701で取得した当該階級について設けるグループ総数Gmaxに設定する。S706では、CPU301は、選択した階級IDが示す階級が付与された実ユーザを、予め定められた規則に従って、振り分けグループ数Gruserのグループに振り分けるグループ分類処理を実行する。なお、当該グループ分類処理の詳細については後述するが、階級実ユーザ数Uruserが非降格総人数Undownt以下である場合は、CPU301は1つのグループに振り分ける実ユーザの数が非降格人数Undownとなるように、順にグループを選択して実ユーザを振り分ける。また階級実ユーザ数Uruserが非降格総人数Undowntより大きい場合は、CPU301は各グループに振り分ける実ユーザの数が均等になるように振り分けを行う。即ち、1つのグループには非降格人数Undownの実ユーザが優先的に振り分けられる。S707で、CPU301は、ROM302に記憶されている予め定められた種類の階級の全てについて、実ユーザのグループ分けを行なったか否かを判断する。CPU301は、まだ実ユーザのグループ分けを行っていない階級がある場合は処理をS701に戻し、全ての階級について実ユーザのグループ分けが完了している場合は公式リーググループ決定処理を完了する。フレンド登録また、本実施形態のオンライン対戦カードゲームでは、ユーザ同士の交流を促進するためにフレンド登録機能を有し、フレンド登録を行なったユーザ同士は公式リーグ戦において同一のグループに振り分けされるようにグループ分類処理が行われる。ここで、ユーザ同士のフレンド登録を行う方法について、図を用いて説明する。例えばユーザAがユーザBをフレンドとして登録したい場合、ユーザAは、ユーザ検索画面においてユーザBを検索する、あるいはゲームシステムにログイン中のユーザの一覧リストの中からユーザBを選択することにより、図8aのようなユーザBの詳細画面に遷移する。そして当該画面においてフレンド登録ボタン801を選択することにより、ユーザBをフレンドとして登録することができる。フレンドとして登録されたユーザBは、例えば図8bに示されるようなユーザAに関する詳細情報を確認する画面におけるフレンドリスト領域802にフレンドアイコン803を用いて表示される。当該フレンド登録に係る処理は、例えば以下のようにCPU301によって処理される。CPU301は、ネットワークI/F306を介してユーザAのユーザ端末202からユーザBについてのフレンド登録要求を受信すると、ユーザ管理データベース304に記憶されている、ユーザAのユーザIDに関連付けられたフレンドテーブルの情報を読み出す。フレンドテーブルは、例えば図14bに示すようにユーザによってフレンド登録要求がなされたユーザのユーザIDが追加されたリストであり、CPU301は読み出したユーザAのユーザIDに関連付けられたフレンドテーブルに、ユーザBのユーザIDを追加して再びユーザ管理データベース304に記憶させることにより、ユーザAとユーザBとのフレンド関係を構築する。なお、本実施形態ではユーザからフレンド登録要求を受信した際に、当該ユーザIDに関連付けられたフレンドテーブルに被登録ユーザのユーザIDを追加するものとして説明するが、本発明のフレンド登録方法はこれに限られない。例えばCPU301は、ユーザAのユーザ端末202からユーザBのフレンド登録要求を受信した場合に、まずユーザBに対してユーザAのフレンド登録の承認の可否を要求し、ユーザBが当該承認を認可した際にユーザA及びユーザBそれぞれのユーザIDに関連付けられたフレンドテーブルに互いのユーザIDの情報を追加し、ユーザAとユーザBとの間にフレンド関係を構築する構成であってもよい。なお、CPU301は、ユーザ端末202よりユーザに関する詳細情報の表示要求を受信した場合は、まず当該ユーザのユーザIDに関連付けられているフレンドテーブルをユーザ管理データベース304より読み出す。そしてCPU301は、当該テーブルに含まれるユーザIDに関連付けられているグラフィック情報をグラフィックデータベース307より取得して、図8bのフレンドリスト領域802にフレンドアイコン803として描画するものとする。グループ分類処理ここで、任意のユーザと、当該ユーザとフレンド関係を有し、かつ当該ユーザと同一の階級を有するフレンドユーザとを同一のグループに分類する、上述した公式リーググループ決定処理におけるグループ分類処理について、図9のフローチャートを用いて詳細に説明する。なお、本グループ分類処理は、上述した公式リーググループ決定処理において呼び出される処理であるため、決定された実ユーザを分類するグループ数振り分けグループ数の情報に基づいて階級ごとに実行される。S901で、CPU301は、処理対象の階級IDが示す階級が付与された実ユーザの集合を、ユーザとフレンド関係を有するフレンドユーザが当該集合内に含まれるか否かによって2つの集合に分類する。具体的にはCPU301は、まず処理対象の階級IDが関連付けられている実ユーザのユーザIDをユーザ管理データベース304より読み出してRAM303の実ユーザリストに追加する。そしてCPU301は、当該実ユーザリストに追加されているユーザIDの各々について、当該ユーザIDに関連付けられているフレンドテーブルの情報をユーザ管理データベース304より読み出す。さらにフレンドテーブルと実ユーザリストの両方に含まれるユーザIDが存在する場合は、CPU301は当該両方に含まれるユーザIDと、フレンドテーブルが関連付けられているユーザIDとを、同じ階級内にフレンドユーザが存在する実ユーザのリストであるRAM303のリストAに追加するとともに、実ユーザリストからリストAに追加したユーザIDを削除する。このような処理を実ユーザリストに含まれるユーザIDの各々について繰り返し実行することにより、同じ階級内にフレンドユーザが存在する実ユーザのユーザIDをリストAに分離することができる。なお、本ステップの処理後の実ユーザリストは、同じ階級内にフレンドユーザが存在しない実ユーザのユーザIDのみが含まれるリストとなっている。以下の説明では、処理後の実ユーザリストをリストBとして説明する。S902で、CPU301は、リストAに含まれる実ユーザを、ユーザ関係を有するユーザの組に分類する。具体的にはCPU301は、リストAに含まれるユーザIDをランダムに選択し、当該ユーザIDとフレンド関係を有する、リストAに含まれるフレンドユーザのユーザIDのうちから、4人のフレンドユーザのユーザIDをランダムに選択する。なお、このときフレンド関係を有するフレンドユーザが4人に満たない場合は、CPU301はフレンド関係を有する全てのフレンドユーザのユーザIDを選択する。そしてCPU301は、当該ランダムに選択したユーザIDと、最大4人のフレンドユーザのユーザIDとを、フレンド関係を有する最大5人のユーザのユーザIDで構成される構造体としてRAM303のリストCに追加する。このとき、CPU301はリストAから当該構造体に含められたユーザIDを削除する。即ち、本ステップにおいてCPU301は、処理対象の階級における1つのグループについての非降格人数Undownの半数以下で構成される、フレンド関係を有するユーザの組を作る。本ステップでは、CPU301はこのような組分け処理を、リストAに含まれるユーザIDがなくなるまで、あるいはリストCに追加された構造体の数が振り分けグループ数Gruserの2倍になるまで繰り返す。なお、組分け処理を実行することにより、ランダムに選択したユーザについて、当該ユーザのフレンドユーザが既に組分けされており、リストAに含まれるフレンドユーザのユーザIDの数が0である場合がある。このような場合は当該選択したユーザに対して組分けを行うことができないため、CPU301は当該選択したユーザのユーザIDをリストBに移動するものとする。また、リストCに追加された構造体の数が振り分けグループ数Gruserの2倍になり組分け処理を停止した場合、CPU301はリストA似含まれる残りのユーザIDについては、リストBに移すものとする。S903で、CPU301は、処理対象の階級IDに関連付けて、振り分けグループ数Gruserのグループテーブルをグループデータベース308に作成する。このとき、作成された振り分けグループ数Gruserのグループテーブルは、それぞれ異なるグループIDが関連付けられ、独立して管理されるものとする。S904乃至S907の処理で、CPU301は、リストB及びリストCに含まれる実ユーザのユーザIDをグループテーブルに順に追加することで、S903でグループデータベース308に作成した振り分けグループ数Gruserのグループテーブルのそれぞれに非降格人数Undownの実ユーザを追加する。S904で、CPU301は、グループデータベース308に作成した振り分けグループ数のグループテーブルのうち、実ユーザのユーザIDをまだ追加していないグループテーブルを選択する。S905で、CPU301は、リストCから2つの構造体を読み出し、当該構造体に含まれるユーザIDの全てをS904で選択したグループテーブルに追加する。またCPU301は、読み出した2つの構造体をリストCから削除する。なお、リストCに1つの構造体しか存在しない場合は、CPU301は当該1つの構造体に含まれるユーザIDのみを選択したグループテーブルに追加するものとする。また、リストCに含まれる構造体が存在しない場合は、CPU301は本ステップの処理を行わずに、処理をS906に移す。S906で、CPU301は、選択中のグループテーブルに追加したユーザIDの数、即ちS905で読み出した2つの構造体に含まれていたユーザIDの数が非降格人数Undownと等しい否かを判断する。CPU301は、選択中のグループテーブルに追加したユーザIDの数が非降格人数Undownと等しいと判断した場合は処理をS907に移し、非降格人数Undownに満たないと判断した場合は処理をS906に移す。S906で、CPU301は、リストBに含まれるユーザIDをグループテーブルにランダムに選択して追加することで、選択中のグループテーブルに含まれるユーザIDの数を非降格人数Undownとする。このとき、CPU301は、S905と同様に、グループテーブルに追加したユーザIDをリストBから削除する。なお、本ステップにおいてリストBに含まれる全てのユーザIDを追加しても選択中のグループテーブルに含まれるユーザIDの数が非降格人数Undownに達しない場合は、CPU301は選択中のグループテーブルに当該全てのユーザIDを追加して処理をS907に移せばよい。また、リストBに含まれるユーザIDが存在しない場合は、CPU301は本ステップの処理を行わずに処理をS907に移す。S907で、CPU301は、グループデータベース308に作成した振り分けグループ数のグループテーブルの全てに、ユーザIDを追加したか否かを判断する。CPU301は、振り分けグループ数のグループテーブルの全てにユーザIDを追加したと判断した場合は処理をS908に移し、ユーザIDを追加していないグループテーブルが存在すると判断した場合は処理をS904に戻す。S908で、CPU301は、リストBに含まれるユーザIDが存在するか否かを判断する。即ち、本ステップにおいてCPU301は、処理対象の階級の実ユーザのうち、まだグループテーブルに追加されていないユーザIDが存在するか否かを判断する。CPU301は、リストBに含まれるユーザIDが存在すると判断した場合は処理をS909に移し、リストBに含まれるユーザIDは存在しないと判断した場合は処理をS910に移す。S909で、CPU301は、リストBに含まれるユーザIDを、グループデータベース308に作成された振り分けグループ数Gruserのグループテーブルに均等に配分して追加する。なお、リストBに含まれるユーザIDの数を振り分けグループ数Gruserで除した際に端数が存在する場合は当該配分は均等ではなく、端数分のグループは、他のグループよりもグループテーブルに追加されるユーザIDの数が多くなることは言うまでもない。S910で、CPU301は、グループデータベース308に作成された振り分けグループ数のグループテーブルの各々を参照し、追加した実ユーザのユーザIDがグループに含めるユーザの定員に満たない場合は、処理対象の階級IDに関連付けられている仮想ユーザのユーザIDをユーザ管理データベース304から読み出して追加して当該グループテーブルに含まれるユーザIDの数を定員数として、本グループ分類処理を完了する。このようにすることで、本実施形態のオンライン対戦カードゲームでは、公式リーグにおける実ユーザのグループ分類において、フレンド関係を有するユーザ同士が同一のグループに含まれるように実ユーザを分類することができる。なお、本実施形態では、フレンド関係を有するユーザの組を、非降格人数Undownの半数となるように組分けするものとして説明したが、本発明の実施はこれに限らず、組分けは任意の階級においてフレンド関係を有するユーザ同士が同一のグループに含まれるように行えばよい。また、このように公式リーグにおける実ユーザのグループ分類において、フレンド関係を有するユーザが同一グループに分類されていることは、例えば図6に示すように、ユーザ端末202の表示装置に表示される表示画面に含まれるフレンドリスト605において通知される。具体的には、フレンド関係を有するユーザのアイコンに対して参加通知606が付加されることによりユーザに通知されればよい。以上説明したように、本実施形態のゲームシステムは、交流のあるユーザと同一グループに割り当てられる確率を上昇させる、対戦リーグに係る処理負荷を軽減させることができる。具体的にはゲームシステムは、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザIDを割り当て、さらに予め定められた種類の階級のうちの1つの階級を示す階級IDを当該ユーザのユーザIDに関連付けることにより階級を付与する。また登録されているユーザのうち、第1のユーザのユーザ端末より、第2のユーザについてのフレンド登録要求を受け付け、第1のユーザ及び第2のユーザそれぞれのユーザIDに関連付けられたフレンドテーブルに互いのユーザIDを追加することにより、第1のユーザと第2のユーザとの間にフレンド関係を構築する。そして登録されているユーザを同一の階級に属する所定数のユーザで構成される1以上のグループテーブルに追加する際に、当該ユーザのユーザIDに関連付けられたフレンドテーブルに、当該ユーザIDに関連付けられた階級IDと同一の階級IDが関連付けられたユーザIDが存在する場合は、追加するユーザのユーザIDと当該同一の階級IDが関連付けられたユーザIDとを同一のグループテーブルに追加する。[実施形態2]上述した実施形態1のオンライン対戦カードゲームでは、公式リーグのシーズン終了後の各グループにおける戦績に応じて、実ユーザに付与されている階級の昇格あるいは降格が行われる。図5bに示したように、基本的には昇格及び降格が行われる2つの階級間において、上位の階級に昇格する実ユーザの合計数昇格総人数Uuptと、下位の階級に降格する実ユーザの合計数降格総人数Udowntとは等しくなるように設定される。しかしながら、ゲームサーバ201に高い処理負荷が与えられた場合等で想定外の処理が発生すると、1つの階級において上限ユーザ数を超える実ユーザが割り当てられてしまう可能性が考えられる。このような状況が発生した場合、上述したグループ分類時にゲームサーバ201がフリーズしてしまうこともあり得るため、本実施形態では当該状況を想定したエラー回避処理について説明する。<エラー回避処理>以下、本実施形態のゲームシステムにおける、1つの階級に上限ユーザ数を超える実ユーザが割り当てられた場合のエラー回避処理について、図10のフローチャートを用いて説明する。当該フローチャートに対応する処理は、CPU301が、例えばROM302に記憶されている対応する処理プログラムを読み出し、RAM303に展開して実行することにより実現することができる。なお、本エラー回避処理は、公式リーグのシーズン終了後に各グループにおける戦績に応じて階級変更処理を行う際に、1つの階級IDが関連付けられるユーザIDの数が当該階級IDが示す階級について予め定められたグループ総数Gmaxのグループテーブルに追加できるユーザIDの数上限ユーザ数Ucmaxを超えるとCPU301が判断した場合に実行されるものとする。S1001で、CPU301はまず、階級変更処理を行った場合に、階級について予め定められた上限ユーザ数Ucmaxを超える実ユーザのユーザIDに当該階級の階級IDが関連付けられる階級エラー階級を特定する。そして特定したエラー階級について、グループ総数Gmaxを一時的に引き上げる。このとき、一時的に引き上げるグループ総数G’maxは、引き上げ後のグループ総数G’maxのグループテーブルに追加できるユーザIDの数が、当該エラー階級の階級IDが関連付けられるユーザIDの数を超えるように設定される。S1002で、CPU301は、エラー階級から昇格及び降格可能な階級の各々ついて、各階級の上限ユーザ数Ucmaxと、階級変更処理後に当該階級が付与される実ユーザの数階級実ユーザ数Uruserとの差分の情報を取得し、階級変更処理後に階級実ユーザ数Uruser実ユーザが上限ユーザ数Ucmaxに満たない階級を把握する。具体的にはCPU301は、エラー階級例:C3の1つ上位例:C2及び1つ下位例:C4の階級のそれぞれについて、階級変更処理を行なった場合に当該階級の階級IDが関連付けられるユーザIDの数階級実ユーザ数Uruser2、Uruser4をユーザ管理データベース304より取得する。またこのときCPU301は、エラー階級の1つ上位及び1つ下位の階級のそれぞれについて上限ユーザ数Ucmax2、Ucmax4の情報をROM302より取得する。そしてCPU301は、エラー階級の1つ上位及び1つ下位の階級のそれぞれについて、上限ユーザ数から階級変更処理後の階級実ユーザ数を減算する。CPU301は当該減算結果が0より大きい階級、即ち階級変更処理後に実ユーザの数が上限ユーザ数に満たない階級が、エラー階級の1つ上位の階級、エラー階級の1つ下位の階級、及びエラー階級の1つ上位及び1つ下位の両方の階級、のいずれであるかを判断する。そしてCPU301は、階級変更処理後の階級実ユーザ数Uruserが上限ユーザ数Ucmaxに満たない階級がエラー階級の1つ上位の階級であると判断した場合は処理をS1003に移し、エラー階級の1つ下位の階級であると判断した場合は処理をS1004に移す。またCPU301は、階級変更処理後の階級実ユーザ数Uruserが上限ユーザ数Ucmaxに満たない階級がエラー階級の1つ上位及び1つ下位の階級の両方であると判断した場合は処理をS1005に移す。S1003で、CPU301は、次のシーズン終了後にエラー階級の1つ上位の階級に昇格する、エラー階級が付与された実ユーザの数を増加させる。具体的にはCPU301は、次のシーズン終了後には当該エラー階級の階級IDが割り当てられるユーザIDの数が引き上げ前の上限ユーザ数Ucmax3となるように、階級を昇格させる実ユーザの数昇格総人数Uuptを設定する。同様にS1004で、CPU301は、次のシーズン終了後にエラー階級の1つ下位の階級に降格する、エラー階級が付与された実ユーザの数を増加させる。具体的にはCPU301は、次のシーズン終了後には当該エラー階級の階級IDが割り当てられるユーザIDの数が引き上げ前の上限ユーザ数Ucmaxとなるように、階級を降格させる実ユーザの数降格総人数Udowntを設定する。またS1005で、CPU301は、次のシーズン終了後にエラー階級の1つ上位の階級に昇格する、及び1つ下位の階級に降格する、エラー階級が付与された実ユーザの数昇格総人数Uupt及び降格総人数Udowntを増加させる。具体的にはCPU301は、次のシーズン終了後にはエラー階級、当該エラー階級の1つ上位の階級、及び当該エラー階級の1つ下位の階級の階級IDが割り当てられるユーザIDの数階級実ユーザ数Uruser2、Uruser3、及びUruser4が、それぞれの階級にもともと割り当てられた上限ユーザ数Ucmax2、Ucmax3、及びUcmax4となるように、階級を昇格させるあるいは降格させる実ユーザの数を設定する。このように、1シーズンの終了時の階級変更処理を行う際に、1つの階級についての階級実ユーザ数Uruserが、当該階級について予め定められた上限ユーザ数Ucmaxを超える場合であっても、一時的に上限ユーザ数Ucmaxを引き上げることで、当該エラーを許容し、さらに階級の昇格及び降格を制御することで、次のシーズン終了後にエラーを修正する。なお、本実施形態では上述した処理は、上位及び下位の階級が存在するC2~C4に適用可能であることは容易に想像されよう。また、最上位である階級C1についても、上位の階級についての上限ユーザ数Ucmaxと階級実ユーザ数Uruserの比較の処理を除外すれば適用可能であることは理解されよう。即ち、C1については、CPU301はS1002の処理は省略してS1004に処理を移してもよい。また、最下位である階級C5については、公式リーグ用のデッキを編成したユーザが新たに追加される可能性があるため、公式リーグの実ユーザの振り分けを行う公式リーググループ決定処理の直前に以下のように処理すればよい。CPU301は、C5の階級IDが付与された階級実ユーザ数Uruser5と、1つ上位の階級に当たるC4の階級が付与された階級実ユーザ数Uruser4、及びそれぞれの階級の上限ユーザ数Ucmax4、Ucmax5の情報を、それぞれユーザ管理データベース304及びROM302より取得する。そしてCPU301は、C5において上限ユーザ数Ucmax5を超える実ユーザの数Uruser5-Ucmax5と、C4に追加可能な実ユーザの数Ucmax4-Uruser4とを比較する。このときUruser5-Ucmax5>Ucmax4-Uruser4である場合は、シーズン終了後にC5の階級実ユーザ数Uruser5を上限ユーザ数Ucmax5にすることができないため、CPU301はUruser5-Ucmax5-Ucmax4-Uruser4人のC5の実ユーザについては、シーズン終了後にユーザ数が定員に達したことを通知し、次のシーズンには振り分け対象としないようにすればよい。なお、本実施形態では、1つの階級についてユーザ上限数を超えるようなユーザIDに当該階級の階級IDが関連付けられるエラーが発生した場合に、次のシーズン終了後に当該エラーを修正する方法について説明したが、本発明の実施はこれに限らず、ユーザ上限数を永続的に引き上げられる構成にすることで、さらなるエラーを生じないようにしてもよい。[実施形態3]本実施形態及び上述した実施形態のオンライン対戦カードゲームは、ユーザが全ての対戦のためにゲームシステムにログインする必要がないよう、あるいはリーグ戦に参加する全てのユーザがログインしなくても進行するように、公式リーグの1シーズンに係る処理が自動的に開始される。ユーザ同士の対戦について生成される詳細な戦況は、対戦するユーザの各々が使用するデッキに応じて自動的に生成されるように構成されている。なお、上述したように公式リーグの1シーズンは、基本的には公式リーグ用のデッキを編成済みの全ユーザが参加対象者となる。しかしながら、このように自動的に進行するオンライン対戦カードゲームでは、長期間ログインしていないユーザも参加対象者として含まれるため、サービスを破綻させてしまう可能性がある。具体的には、実際にはサービスの利用意欲がないユーザのユーザIDの情報が公式リーグに自動的に登録されることにより、公式リーグに参加する実ユーザの数が公式リーグ全体の参加上限数Umaxtに到達してしまうことがあるため、新規のユーザは公式リーグに参加することができない可能性がある。本実施形態では、このように長期間ログインしていないユーザを強制的に排除することで、公式リーグに参加する実ユーザの数が公式リーグ全体の参加上限数Umaxtとなりにくくする方法について説明する。<長期未ログインユーザ排除処理>以下、本実施形態のゲームシステムにおける、公式リーグの参加対象者となるユーザのうち、長期間ログインしていないユーザを強制的に排除する長期未ログインユーザ排除処理について、図11のフローチャートを用いて説明する。当該フローチャートに対応する処理は、CPU301が、例えばROM302に記憶されている対応する処理プログラムを読み出し、RAM303に展開して実行することにより実現することができる。なお、本長期未ログインユーザ排除処理は、公式リーグの1シーズン終了後、次のシーズンに係る公式リーググループ決定処理を実行する前に行われるものとする。また、本実施形態ではネットワークI/F306を介してユーザ端末202よりユーザのログイン要求を受け付けた場合、CPU301はログイン要求を受け付けたユーザのユーザIDに関連付けて、最後にログイン要求を受け付けた日時の情報1408図14aをユーザ管理データベース304に記憶させるものとする。S1101で、CPU301は、公式リーグの参加対象者の全実ユーザのうち、1人の実ユーザのユーザIDを選択し、当該ユーザIDに関連付けられてユーザ管理データベース304に記憶されている、最後にログイン要求を受け付けた日時の情報が、現在日時から所定期間以上前の日時を示しているか否かを判断する。CPU301は、選択した実ユーザのユーザIDに関連付けられている、最後にログイン要求を受け付けた日時の情報が、現在日時から所定期間以上前の日時を示していると判断した場合は処理をS1102に移し、所定期間内の日時を示していると判断した場合は処理をS1103に移す。S1102で、CPU301は、選択したユーザIDで示される実ユーザを公式リーグに参加させないことを示す論理型のフラグ情報1409を、当該ユーザIDに関連付けてユーザ管理データベース304に記憶する。S1103で、CPU301は、公式リーグの参加対象者の全実ユーザのユーザIDに対して、最後にログイン要求を受け付けた日時に基づく、公式リーグへの参加可否の判断が完了したか否かを判断する。CPU301は、公式リーグの参加対象者の全実ユーザのユーザIDに対して公式リーグへの参加可否の判断が完了していると判断した場合は本長期未ログインユーザ排除処理を完了し、参加可否の判断が完了していないユーザIDが存在すると判断した場合は処理をS1101に戻す。本実施形態では、このように最後にログイン要求を受け付けた日時が現在日時から所定期間以上前である実ユーザについては、当該ユーザのユーザIDに公式リーグにさせないことを示すフラグ情報を関連付けることにより、上述した公式リーググループ決定処理及びグループ分類処理において、当該ユーザをグループテーブルに追加する対象から除外することができる。なお、公式リーグにさせないことを示すフラグ情報がユーザIDに関連付けられているユーザから、ネットワークI/F306を介して再度ログイン要求を受信した場合、CPU301は当該ユーザのユーザIDに関連付けられているフラグ情報を削除する。これにより当該ユーザは公式リーグに再度参加可能な状態となるが、公式リーグに参加不可能な状態にされる前に当該ユーザに付与されていた階級の情報は削除され、予め定められた種類の階級のうちの最下位の階級の階級IDが当該ユーザのユーザIDに関連付けられるものとする。これは、当該ユーザに付与されていた階級が付与された実ユーザの数が、既に当該階級について予め定められているユーザ上限数となっている可能性があるからである。なお、このときCPU301は、例えば図12に示すような最下位の階級が付与されたことを示す通知画面を当該ユーザのユーザ端末202の表示装置にさせればよい。[実施形態4]上述した実施形態1乃至3では、公式リーグ用のデッキを編成済みの全ユーザを公式リーグの参加対象者とするものとして説明したが、実施形態3で説明したように参加対象者となる実ユーザの数が公式リーグ全体の参加上限数Umaxtを超えた場合、公式リーグに参加できなくなる実ユーザが現れることになる。上述した実施形態1乃至3のようなオンライン対戦カードゲームでは、運営上、単発的な利用ユーザよりも長期的な利用ユーザを増加させることが好ましいが、以下のような場合、長期的な利用ユーザであっても、公式リーグに参加することができない状況になる可能性がある。例えば長期的な利用ユーザが、公式リーグ用に編成したデッキを一度削除することにより1度公式リーグから外れ、その後再度公式リーグ用のデッキを編成して公式リーグに参加しようとしても、公式リーグに参加しているユーザの数が公式リーグ全体の参加上限数に達していた場合、当該ユーザはサーバの増設が行われるまでは公式リーグに参加できなくなってしまう可能性がある。結果として、長期的な利用ユーザの興趣をそいでしまうことになる。本実施形態では、このような問題を解決するために、長期的な利用ユーザが公式リーグの参加対象者として選択されやすくする方法について説明する。参加対象決定処理以下、本実施形態のゲームシステムにおける、公式リーグの参加対象者となるユーザを決定する参加対象決定処理について、図13のフローチャートを用いて説明する。当該フローチャートに対応する処理は、CPU301が、例えばROM302に記憶されている対応する処理プログラムを読み出し、RAM303に展開して実行することにより実現することができる。なお、本参加対象決定処理は、上述した公式リーググループ決定処理を実行する前に行われるものとする。また、本実施形態ではCPU301は、最後に終了した公式リーグのシーズンに参加していたユーザの各々について、当該最後に終了したシーズンに参加していたことを示すフラグ情報1420をユーザIDに関連付けてユーザ管理データベース304に記憶するものとする。また、公式リーグ全体の参加上限数Umaxtは、各階級について予め定められている上限ユーザ数Ucmaxを足しあわせた数よりも小さい値例えば10万人等に設定されてもよいものとする。S1301で、CPU301は、ユーザ管理データベース304に記憶されている実ユーザのユーザIDのうち、当該ユーザIDに最後に終了したシーズンに参加していたことを示すフラグ情報が関連付けられているユーザIDを、まず次のシーズンの公式リーグへの参加対象者の実ユーザとして選択する。具体的にはCPU301は、最後に終了したシーズンに参加していたことを示すフラグ情報が関連付けられているユーザIDに対して、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報1411を関連付けてユーザ管理データベース304に記憶する。なお、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報は、次のシーズンが終了した際には、最後に終了したシーズンに参加していたことを示すフラグ情報として用いられてもよい。また本ステップは、上述した実施形態3の長期未ログインユーザ排除処理が実行された後に、公式リーグに参加させないことを示すフラグ情報が関連付けられていないユーザIDを対象としてもよい。S1302で、CPU301は、ユーザ管理データベース304を参照し、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザIDの数が、公式リーグ全体の参加上限数Umaxtより小さいか否かを判断する。CPU301は、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザIDの数が公式リーグ全体の参加上限数Umaxtより小さい場合は処理をS1303に移し、公式リーグ全体の参加上限数以上である場合は本参加対象者決定処理を完了する。S1303で、CPU301は、ユーザ管理データベース304に記憶されている、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられていない実ユーザのユーザIDのうち、当該ユーザIDのユーザ管理データベース304への登録順の情報が最も若い、即ち時系列順で最も古いユーザIDを選択する。なお、本ステップにおいて、既にS1304以降の処理を行うために選択したユーザIDについては選択対象外とし、選択対象のユーザIDが存在しない場合は本参加対象者決定処理を完了するものとする。S1304で、CPU301は、S1303で選択したユーザIDに関連付けられている階級IDをユーザ管理データベース304より取得する。そしてCPU301は、当該階級IDが関連付けられ、かつ次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザIDの数が、当該階級IDが示す階級について予め定められた上限ユーザ数Ucmaxを超えているか否かを判断する。即ち、CPU301は本ステップで、S1303で選択したユーザIDに関連付けられた階級のグループに、さらに実ユーザを加えられる空きが存在するか否かを判断する。CPU301は、選択したユーザIDに関連付けられた階級のグループに、さらに実ユーザを加えられる空きが存在すると判断した場合は処理をS1305に写、存在しないと判断した場合は処理をS1302に戻す。S1305で、CPU301は、S1303で選択したユーザIDに対して、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報を関連付けてユーザ管理データベース304に記憶し、処理をS1302に戻す。このようにすることで、長期的な利用ユーザであると思われる、登録要求がなされた日時が古いユーザを優先的に公式リーグへの参加対象者とすることができる。なお、上述した各実施形態の説明では、ネットワークを介して、カードを用いたユーザ同士の対戦を実現するゲームシステムについて説明したが、本発明のゲームシステムはこれに限られない。本発明の実施は、ユーザ同士の対戦を実現する形態としてリーグ戦を有する如何なるゲームシステムにおいても適用可能であることは容易に理解されよう。