JP5891182B2 - ゲーム制御装置、プログラム、ゲームシステム - Google Patents

Description

本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）において、ゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、平成23年11月1日発行）、7-8頁

ところで、従来のゲームでは、ゲームを実行したユーザにポイントを付与し、ユーザが保有するポイントと引き換えにアイテムを付与することが行われる。すなわち、ユーザがポイントを入手対価としてアイテムを入手する行為が行われる。アイテムの入手対価に相当するポイントをユーザが保有していない場合、ユーザはアイテムを入手できないため、ゲームを実行して保有するポイントを増やす動機がユーザに与えられる。

しかし、アイテムを入手する機会が限られている場合、ユーザがアイテムを入手する機会を失すると、ユーザにゲームを実行する動機が与えられない。

本発明は上述した観点に鑑みてなされたもので、例えばアイテムを入手する機会が付与されたユーザが十分なポイントを有していない場合でも、ユーザにゲームを実行する動機を与えることができる、ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、オンラインシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
このゲーム制御装置は、
オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段（５２）、
選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段（５３）、
前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段（５４）、
前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段（５５）、
の各手段を備える。

本発明に係るゲーム制御装置は、ユーザが単独で使用するスタンドアローンのゲーム機であってもよいし、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよい。
本発明において「オブジェクト」とは、例えば、ゲーム上のキャラクタやアイテム等を含む。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
本発明において「ポイント」とは、ゲーム上でオブジェクトを入手する対価となるものである。ポイントは、例えば、ユーザがゲームを実行することでユーザに付与されてもよい。あるいは、ポイントは、ユーザがゲーム上で使用できる仮想通貨であってもよい。
このゲーム制御装置によれば、オブジェクトを入手する機会が付与されたユーザが十分なポイントを有していない場合でも、ユーザが入手希望オブジェクトとして登録しておくことができるため、登録した入手希望オブジェクトを入手するためにゲームを実行する動機をユーザに与えることができる。

上記ゲーム制御装置において、前記付与手段（５４）は、前記入手希望オブジェクトが登録された後、前記ユーザが前記入手希望オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記入手希望オブジェクトを前記ユーザに付与してもよい。
このゲーム制御装置によれば、オブジェクトを入手する機会が付与されたユーザが十分なポイントを有していない場合でも、その後十分なポイントを有する状態となった後にユーザが入手希望オブジェクトを入手することができるため、ユーザがポイントを増加させるためにゲームを実行する動機を与えることができる。

上記ゲーム制御装置において、前記入手希望オブジェクトが登録されてから所定期間の経過後、前記入手希望オブジェクトの登録を解除する解除手段（５６）を備えてもよい。
このゲーム制御装置によれば、入手希望オブジェクトの登録が所定期間の経過後に解除されるため、登録が解除される前にゲームを実行する動機をユーザに与えることができる。

上記ゲーム制御装置において、前記所定期間は、前記入手希望オブジェクトの入手対価に応じた長さの時間としてもよい。
入手希望オブジェクトの入手対価が高いほど、入手希望オブジェクトを入手するのにユーザが要するゲームの実行時間が長くなる。このため入手希望オブジェクトの入手対価に応じて入手希望オブジェクトを登録しておくことができる期間（以下、登録期間）の長さを変更することで、登録期間の長さを適切な値に設定することができる。例えば、登録期間が入手対価に対して短すぎるためにユーザが入手希望オブジェクトの入手を諦めることを回避することができる。

上記ゲーム制御装置において、前記入手希望オブジェクトの入手対価と前記ユーザの保有ポイントとの差額が減少したとき、前記所定期間を延長する延長手段（５８）を備えてもよい。
このゲーム制御装置によれば、ユーザがゲームを実行して保有するポイントを増やすことで、入手希望オブジェクトの入手対価とユーザの保有するポイントとの差額が減少し、登録期間が延長されるため、登録が解除されてアイテムを入手する機会を失することを回避するためにゲームを実行する動機をユーザに与えることができる。

上記ゲーム制御装置において、前記入手希望オブジェクトが登録された時からの時間に応じて、前記入手希望オブジェクトの入手対価を変動させる入手対価変動手段（５９）を備えてもよい。
このゲーム制御装置によれば、登録された時からの時間に応じて、入手希望オブジェクトの入手対価が変動するため、入手対価がより安い時期に入手希望オブジェクトを入手する目的でゲームを実行する動機をユーザに与えることができる。例えば、登録された時からの時間に応じて入手対価を増加させる場合には、より早い時期に入手希望オブジェクトの入手するためにゲームを実行する動機をユーザに与えることができる。
また、登録が解除されてユーザにポイントを払い戻す際に、利息を考慮して、登録された時からの時間に応じて減少させた入手対価に応じたポイントを払い戻すことができる。

上記ゲーム制御装置において、ゲームの実行に応じてユーザにポイントを付与するポイント付与手段（６０）を備え、前記入手希望オブジェクトが登録されている場合、前記ポイント付与手段（６０）は、前記ゲームの実行に応じてユーザに付与するポイントを変動させてもよい。
このゲーム制御装置によれば、入手希望オブジェクトが登録されている場合にゲームの実行に応じてユーザに付与するポイントを変動させることで、入手希望オブジェクトを入手するのにユーザが要するゲームの実行時間を変動させることができる。例えば、入手希望オブジェクトが登録されていない場合よりも登録されている場合にユーザに付与するポイントを多くすることで、ユーザが入手希望オブジェクトを入手するのに要するゲームの実行時間が短くなる。このため、十分なポイントを有していない場合でも、ユーザが積極的に入手希望オブジェクトを登録してゲームを実行する動機を与えることができる。
一方、利息分を考慮して、入手希望オブジェクトが登録されていない場合よりも登録されている場合にユーザに付与するポイントを少なくすることで、ユーザが入手希望オブジェクトを入手するのに要するゲームの実行時間を長くすることもできる。

上記ゲーム制御装置において、前記入手希望オブジェクトが登録されている場合、前記ユーザが他のオブジェクトを入手する機会を制限する第１制限手段（６１）を備えてもよい。
このゲーム制御装置によれば、入手希望オブジェクトが登録されている場合、ユーザに他のオブジェクトを入手する機会を付与しないことで、ユーザが無計画にオブジェクトを登録することを回避することができる。

上記ゲーム制御装置において、前記ユーザが前記入手希望オブジェクトを入手可能と判定されるまで、前記ユーザによる他のオブジェクトの入手のためのポイントの使用を制限する第２制限手段（６２）をさらに備えてもよい。
このゲーム制御装置によれば、ユーザが入手希望オブジェクトを入手可能と判定されるまで、ポイントを使用して他のオブジェクトを入手することができない。そのため、ユーザが入手希望オブジェクト以外の他のオブジェクトをさらに入手可能とするために、登録された入手希望オブジェクトの入手対価に相当するポイントが早く得られるようにゲームを実行することを動機付けられる。

上記ゲーム制御装置において、前記入手希望オブジェクトの登録の解除を前記ユーザから受け付ける受付手段（５７）を備えてもよい。
このゲーム制御装置によれば、例えば登録後に希望しなくなったときにユーザが入手希望オブジェクトの登録の解除をすることで、入手希望オブジェクトが登録されているときにユーザに課される制約（例えば、他のオブジェクトを入手不可能、ポイントの使用制限等）を解除することができる。

本発明の第２の観点は、ゲーム制御装置である。
このゲーム制御装置は、
オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段（５２）、
選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段（５３）、
前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段（５４）、
前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段（５５）、
前記入手希望オブジェクトが登録されてから所定期間の経過後、前記入手希望オブジェクトの登録を解除する解除手段（５６）、
前記入手希望オブジェクトが登録されている場合、前記ユーザが他のオブジェクトを入手する機会を制限する第１制限手段（６０）、
を備える、ゲーム制御装置。の各手段を備える。

本発明の第３の観点は、ゲーム制御方法である。
このゲーム制御方法は、オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付けるステップ、
選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定するステップ、
前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与するステップ、
前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録するステップ、
を含む。

本発明の第４の観点は、コンピュータに、
オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける機能、
選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する機能、
前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する機能、
前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する機能、
を実現するためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、光ディスク（ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第５の観点は、複数のユーザの通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含む、ゲームシステムである。
このゲームシステムは、
オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段（５２）、
選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段（５３）、
前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段（５４）、
前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段（５５）、
の各手段を、前記通信端末（１０）または前記サーバ（２０）のいずれか一方が備える。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定されるものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、アイテムを入手する機会が付与されたユーザが十分なポイントを有していない場合でも、ユーザにゲームを実行する動機を与えることができる。

実施形態のゲームシステムの基本構成を示す図。 通信端末の外観の例を示す図。 通信端末の構成を示すブロック図。 ゲームサーバの構成を示すブロック図。 データベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 モンスターカードデータベースの構成例を示す図。 登録テーブルの構成例を示す図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示されるウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例１のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例１のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例２のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例２のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例３のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例３のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例３のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例４のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例４のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例５のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例５のゲーム制御装置の主要な処理の一例を示すフローチャート。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明のゲームシステムの一実施形態について説明する。

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と有線又は無線で接続される。なお、ゲームサーバ２０とデータベースサーバ３０は、通信網ＮＷを介して接続してもよい。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０上でウェブページに対する操作を行うことにより、ゲームを実行する。

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

（２）通信端末の構成
図２及び図３を参照して通信端末１０について説明する。
図２は、通信端末１０の外観の例を示す図であって、（ａ）は、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、（ｂ）は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。そのようなプラグインの一例は、アドビシステムズ社（米国）によるフラッシュプレイヤである。あるいは、本実施形態でのＨＴＭＬデータを、動画及び音声の再生機能を備えたＨＴＭＬ５形式としてもよい。
なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０へ通知する。

ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ゲームサーバ２０から取得したＨＴＭＬデータを解釈して、画像処理部１４を介してウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、ウェブページの更新のために、その選択結果に応じたＨＴＴＰリクエストをゲームサーバ２０に送信する。

画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

通信端末１０が釦入力方式の通信端末（図２（ａ）に示す）である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２（ａ）に示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

通信端末１０がタッチパネル入力方式の通信端末（図２（ｂ）に示す）である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２（ｂ）に示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

通信端末１０に表示されるウェブページ上のメニューの選択は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、メニューの選択は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、指示入力部２５、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ゲームサーバ２０のウェブブラウザとの間でＨＴＴＰに従った通信を行う。例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、通信端末１０から受信したＨＴＴＰリクエスト（例えば、ウェブページ上でのユーザのハイパーリンクまたはメニューの選択結果を含む。）に基づいて所定のデータ処理や、演算処理を行い、その処理結果を含むＨＴＴＰレスポンスをゲームサーバ２０のウェブブラウザに返す。ＨＴＴＰレスポンスには、ウェブページを更新するためのＨＴＭＬデータが含まれる。また、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

（４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース（ユーザＤＢ）３１と、ゲームデータベース（ゲームＤＢ）３２を備える。

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態のゲームの一例として、モンスターカード（以下適宜、単に「カード」という。）を用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、ユーザが、モンスターが描かれたデジタルカード（モンスターカード）を入手することによって自らのチーム（カードデッキ）を作り上げ、コンピュータ又は他のユーザのチームとバトルを行うように構成されている。なお、カードデッキは、一般的に複数のカードによって構成されている。
このゲームは、例えば、以下の処理を含む。
・クエスト処理：
少なくとも一枚のモンスターカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してモンスターカードを得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費する。
・対戦処理：
ユーザのチームと、コンピュータ又は他のユーザのチームとの間で対戦を行う処理である。ここで、コンピュータのチームとは、例えばＣＰＵ２１によって任意に抽出された複数のモンスターカードからなるチームである。対戦処理では、ユーザの入力に基づき、ユーザのチームとコンピュータのチームとの間で対戦を行うイベント（以下、ＣＯＭ対戦という。）、あるいはユーザのチームと他のユーザのチームとの間で対戦を行うイベント（以下、ユーザ間対戦という。）のいずれかが発生するようになっている。
・購入処理
カードを入手する機会をユーザに付与し、ユーザが入手を希望するカードを、ユーザがゲーム上で保有するポイント（後述する購入ポイント）と引き換えに付与する処理である。なお、ユーザが保有する購入ポイントがカードを購入するのに必要なポイント（以下、入手対価という）未満である場合、所定期間、カードを登録し、登録したユーザの購入ポイントの入手対価に対する不足ポイント（負の値）を管理する。ユーザがゲームを実行して購入ポイントを入手することで不足ポイントが０に到達すると、登録されたカード（登録カード）がユーザに付与される。なお、以下ではカードを入手する機会をユーザに付与する場合について説明するが、カードの代わりにアイテムを入手する機会をユーザに付与してもよい。

また、ここでは詳しく述べないが、本実施形態のゲームは、例えばユーザがゲーム上保有するモンスターカードにおいて、当該ユーザのチームに含まれるモンスターカードと、それ以外のモンスターカード（つまり、当該ユーザのチームに含まれないモンスターカード）との交替等を実行するための編成処理を含んでもよい。

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、進行レベル、体力ポイント、購入ポイント、仲間のユーザＩＤ、保有カード、アイテムの識別コードの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、クエスト処理が継続的に実行されることで、順次進行レベルが上がるように構成される。
・体力ポイント
体力ポイントは、ユーザがクエスト処理を行う際に消費するコストを示すパラメータであり、ユーザがクエスト処理を行うことで、体力ポイントは減少する。ユーザ毎に体力ポイントの上限値を定めてもよく、体力ポイントの上限値は、進行レベルが増加するにつれて増加するように設定されていてもよい。体力ポイントは、時間の経過によって上限値まで増加（回復）するように設定してもよい。
・購入ポイント
ユーザが、クエスト処理や対戦処理においてシステム又は他のユーザより取得したポイントである。このゲームでは、ユーザの購入ポイントと引き換えに、当該ユーザに対してゲーム上のカードやアイテムが付与されるようになっている。なお、一定額の課金と引き換えにシステムよりユーザに購入ポイントを付与してもよい。
・仲間のユーザＩＤ
例えば仲間になるための申請などを契機として、ユーザと関連付けられた他のユーザ（仲間）のユーザＩＤのリストである。
・保有カード、アイテムの識別コード
ユーザがゲーム上保有するモンスターカードやアイテム（体力ポイントを回復させる回復アイテム等）の識別コードである。識別コードに対応するモンスターカード等のデータの内容については後述する。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、例えば対戦結果についての情報（例えば勝敗等）などを含む。
また、ゲームデータベース３２は、上述した各種処理に関連して、モンスターカードデータベース、登録テーブルを記憶する。

モンスターカードデータベースは、本実施形態のゲームで用意される全てのモンスターカードの情報が記述されているデータベースである。
図７は、モンスターカードデータベースのデータ構成の一例を示す図である。図７に例示するモンスターカードデータベースは、モンスターカードの識別コード（図の例では、ＭＣ００１，ＭＣ００２，…）ごとに、対象となるモンスターカードの画像データ（画像）、対象となるモンスターの名前（モンスター名）、対象となるモンスターカードのパラメータ（図の例では、モンスターの能力を示す攻撃力や防御力及びレア度）、及びモンスターカードの入手対価の各項目のデータを含む。例えば、攻撃力や防御力などのパラメータが大きいほど、モンスターカードに対応するモンスターの対戦処理等における能力が高いことを示すように設定されてもよい。
また、レア度は、モンスターカードの希少価値の度合を示す値であり、例えば、その値が高い（つまり、希少価値が高い）ほど、ゲーム内で出現する確率が低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、能力の際立ったモンスターや人気のあるモンスターに対応するモンスターカードのレア度が高く（例えば、４あるいは５など）設定されてもよい。

図８は、購入処理に用いる登録テーブルのデータ構成の一例を示す図である。図８に例示する登録テーブルには、登録コードごとに、カードを登録したユーザのユーザＩＤ、登録カードの識別コード、登録時刻、登録有効期限が対応付けられている。登録テーブルには、購入処理においてカードを入手する機会をユーザに付与し、かつ、ユーザがカードを登録したとき、登録したユーザのユーザＩＤ、登録カードの識別コード、登録した時刻（登録時刻）、登録の有効期限（登録有効期限）が記録される。例えば、登録有効期限は、登録時刻から所定の時間を経過した後の時刻とすることができる。

（５）本実施形態のゲーム
以下、本実施形態のゲームについて、図９〜図１５を参照しながら説明する。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

図９のトップページＰ１は、モンスター画像表示領域１０１、ユーザデータ表示領域１０２及びメニュー表示領域１０３を含む。トップページＰ１は処理対象のユーザ毎に構成されるが、図１１のトップページＰ１は、処理対象のユーザが「Ａ」というユーザ（以下、「ユーザ：Ａ」と表記する。）である場合の例である。
モンスター画像表示領域１０１は、処理対象となるユーザのユーザデータベースに記録された識別コードに対応する複数のカードのうち、当該ユーザによって予め指定されたカードの画像が表示される領域である。ユーザデータ表示領域１０２は、処理対象となるユーザのユーザデータベースに記録された、進行レベル、体力ポイント等の各項目のデータ（図６参照）が表示される領域である。メニュー表示領域１０３には、本実施形態のゲームに設けられるイベント処理（クエスト処理、対戦処理）にそれぞれ対応するメニューｍ１（「クエスト」）、メニューｍ２（「対戦」）が含まれる。なお、メニュー表示領域１０３には、上述した編成処理に対応するメニューが含まれてもよい。
このトップページＰ１上で、メニューｍ１またはメニューｍ２が選択されることで、ゲームの実行が開始される。

〔クエスト処理〕
先ず、クエスト処理の一例を説明する。図９のトップページＰ１上でユーザ：Ａがメニューｍ１を選択すると、クエスト処理が開始され、Ｐ２に示すようにウェブページが更新される。ウェブページＰ２には、探索の対象となるエリアの進行度合いを示す達成率のゲージと、探索の対象となるエリアの探索処理を実行するための「クエスト実行」と表記されたメニューｍ１０と、１回の探索に要する体力ポイントの値、１回の探索で得られる経験値などが含まれる。
ユーザ：Ａがメニューｍ１０を選択する度に、所定の条件に沿った、あるいはランダムな増加量で達成率の値が増加する。そして、達成率が１００％に達すると、エリアの探索が終了して次のエリアに進むことができる。メニューｍ１０が選択される度に、ユーザ：Ａの体力ポイントが所定量（図９の例では、８）だけ消費される。探索対象のエリアは、複数設けられてもよい。
ウェブページＰ２においてメニューｍ１０の選択を繰り返し行うと、上述したように体力ポイントが低下していくが、体力ポイントが１回の探索に要する体力ポイント（例えば８）よりも少なくなると、それ以上探索の実行ができない状態となる。その場合、ユーザが再び探索を実行できるようになるには、時間の経過によって体力ポイントが回復（増加）するまで待機することが必要となる。
なお、クエスト処理では、メニューｍ１０が選択される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されているカードあるいはアイテムなどのオブジェクトや、購入ポイント、経験値等をユーザが入手できるように構成されている。メニューｍ１０が選択されたときにユーザがカードを入手したときは、例えばＰ３に示すように、入手したカードの情報を含むウェブページに更新される。あるいは、メニューｍ１０が選択されたときにユーザが購入ポイントを入手したときは、例えばＰ４に示すように、ユーザ：Ａが新たに入手した購入ポイント及び新たに入手した購入ポイントを加算した後のユーザ：Ａが保有する購入ポイントの情報を含むウェブページに更新される。
また、クエスト処理では、メニューｍ１０が選択される度に、所定の、あるいはランダムな確率で、ゲーム上の他のイベントに移行する機会を付与するように構成されている。例えば、メニューｍ１０が選択される度に、所定の、あるいはランダムな確率で、後述する対戦処理に移行するためのウェブページに更新されてもよいし、後述する購入処理に移行するためのウェブページ（例えば図１１のＰ７）に更新されてもよい。なお、以下の説明では、他のイベントとして購入処理に移行する場合について説明する。

〔対戦処理〕
次に、対戦処理の一例を説明する。図１０のトップページＰ１上でメニューｍ２が選択されると、対戦処理が開始され、Ｐ５に示すようにウェブページが更新される。ウェブページＰ５には、対戦相手：Ｅの画像とともに、対戦の実行を指示するための「対戦開始」と表記されたメニューｍ２０などが含まれる。ウェブページＰ５上でユーザ：Ａがメニューｍ２０（「対戦開始」）の選択を行うと、ユーザ：Ａのチームと対戦相手：Ｅのチームとの間で対戦が行われる。
なお、本実施例のように、ＣＰＵ２１によって所定の条件、又はランダムに対戦相手が決定されてもよいし、所定の条件、又はランダムに選出された複数の対戦相手からなるリストを表示し、ユーザがその中から対戦相手を選択できてもよい。また、対戦相手はコンピュータであってもよいし（ＣＯＭ対戦）、他のユーザであってもよい（ユーザ間対戦）。他のユーザはユーザ：Ａと関連付けられている仲間であってもよいし、ユーザと関連付けられていないユーザであってもよい。

対戦処理は、例えば、攻撃側のチームのカード情報、および、防御側のチームのカード情報に基づいて実施される。例えば、攻撃側のチームのカードの攻撃力の総和と、防御側のチームのカードの防御力の総和とを比較し、数字が大きい側を勝利、小さい側を敗北と決定することで、対戦処理を行うことができる。なお、対戦処理は攻撃力・防御力等のパラメータの総和の比較によるものに限らず、チームに設定されたカードの攻撃力・防御力を所定の計算式により変動させた上で比較し勝敗を決定してもよいし、パラメータの数値の大小に応じて勝つ確率を変動させた上で抽選処理を行い、勝敗を決定してもよい。

対戦が終了すると、対戦の結果を通知するウェブページ（Ｐ６に例示するウェブページ）がユーザ：Ａの通信端末１０上に表示される。なお、ウェブページＰ６は、ユーザ：Ａが対戦に勝利した場合に通信端末１０の表示部１６に表示されるウェブページの一例を示している。このゲームでは、ユーザ：Ａが対戦相手：Ｅに勝利すると、所定量の購入ポイント（図１０の例では１０００）が特典としてユーザ：Ａに付与される。

〔購入処理〕
次に、購入処理の一例を説明する。クエスト処理において、ユーザ：Ａがメニューｍ１０を選択する度に、所定の、あるいはランダムな確率で、例えば図１１のＰ７に示すようにユーザが購入処理への移行を選択するウェブページに更新される。ウェブページＰ７には、通常の探索処理を実行するための「クエスト実行」と表記されたメニューｍ１０に加えて、購入処理へ移行するための「立ち寄る」と表記されたメニューｍ１１が含まれる。
ウェブページＰ７においてユーザがメニューｍ１１を選択すると、購入処理が開始され、例えば図１１のＰ８に示すようにウェブページが更新される。ウェブページＰ８は、ユーザ：Ａに入手する機会を与えられたカードに関する情報と、各カードをユーザ：Ａが選択するための「入手」と表記されたメニューｍ１２、ｍ１３を含む。ここで、ユーザ：Ａに入手する機会を与えられるカードは、他のユーザが売却したカードからＣＰＵ２１が選択してもよいし、モンスターカードデータベースから任意のカードをＣＰＵ２１が選択してもよい。
ウェブページＰ８において、ユーザ：Ａが例えばメニューｍ１２を選択すると、選択したカード：ｄｅｆの入手対価（必要ポイント）：１００００がユーザの購入ポイント：１２４３８から差し引かれると同時に、選択したカード：ｄｅｆがユーザ：Ａに付与される。
一方、ユーザ：Ａがメニューｍ１３を選択した場合、選択したカード：ａｂｃの入手対価（必要ポイント）：２００００はユーザ：Ａの購入ポイント：１２４３８を超えているため、選択したカード：ａｂｃはユーザ：Ａに付与されず、例えば図１２のＰ９に示すようにウェブページが更新される。ウェブページＰ９は、ユーザ：Ａが選択したカード：ａｂｃに関する情報、ユーザ：Ａの購入ポイントが入手対価に足りないことを示すテキスト（「ポイントが足りません」）、ユーザ：Ａが選択したカードを登録するための「登録する」と表記されたメニューｍ１４、ユーザ：Ａの購入ポイントを示すテキスト（「購入ポイント：１２４３８」）、ユーザ：Ａの購入ポイントのユーザが選択したカード：ａｂｃの入手対価に対する不足ポイントを示すテキスト（「購入ポイント：−７５６２」）を含む。なお、下向きの矢印（↓）は、ユーザ：Ａがメニューｍ１４を選択した場合、ユーザ：Ａのウェブページに表示されるポイントが、不足ポイントとなることを示している。
ウェブページＰ９において、ユーザ：Ａがメニューｍ１４を選択すると、例えば図１２のＰ１０に示すようにウェブページが更新される。ウェブページＰ１０は、ユーザ：Ａの登録カード：ａｂｃに関する情報、登録したことを示すテキスト（「登録しました」）、登録後のユーザ：Ａのウェブページに表示されるポイントを示すテキスト（「購入ポイント：−７５６２」）、現在時刻から登録有効期限までの時間を示すテキスト（「残り時間：２４：００」）を含む。ここで、登録後のユーザ：Ａのトップページに表示されるポイントは、ユーザ：Ａの購入ポイントの登録カード：ａｂｃの入手対価に対する不足ポイント（以下、「不足ポイント」という）である。

ユーザ：Ａがカード：ａｂｃを登録した状態では、ユーザ：Ａのトップページは、例えば図１３のＰ１１に示すように、カードを登録した状態であることを示す「カード登録中」と表記されたメニューｍ３を含む。また、トップページＰ１１は、ユーザ：Ａの購入ポイントの代わりに、不足ポイントを示すテキスト（「購入ポイント：−７５６２」）を含む。
トップページＰ１１において、ユーザ：Ａがメニューｍ３を選択すると、例えば図１３のＰ１２に示すように登録の確認・取消を行うウェブページに更新される。ウェブページＰ１２は、ユーザ：Ａの登録カード：ａｂｃに関する情報、不足ポイントを示すテキスト（「購入ポイント：−７５６２」）、現在時刻から登録有効期限までの時間を示すテキスト（「残り時間：０４：００」）、登録を取り消すための「登録取消」と表記されたメニューｍ３１、不足ポイントを示すテキスト（「購入ポイント：−７５６２」）、登録取消後のユーザ：Ａの購入ポイントを示すテキスト（「購入ポイント：１２４３８」）、登録取消により入手対価に相当する購入ポイントが払い戻されることを示すテキストが表示されることを示すテキスト（例えば、「ポイント差額は払い戻されます」等）、トップページに戻るための「戻る」と表記されたメニューｍ３２を含む。

〔登録カードがある場合におけるクエスト処理〕
トップページＰ１１において、ユーザ：Ａがメニューｍ１を選択し、クエスト処理においてユーザ：Ａに購入ポイントが付与された場合、図１４のＰ１３又はＰ１４に示すようにウェブページが更新される。ここで、ユーザ：Ａに購入ポイントが付与された後、ユーザ：Ａの購入ポイントがユーザ：Ａの登録カードの入手対価に足りない場合、ウェブページＰ１３に更新され、ユーザ：Ａの購入ポイントがユーザ：Ａの登録カードの入手対価を超えた場合、ウェブページＰ１４に更新される。
ウェブページＰ１３は、達成率のゲージ、メニューｍ１０、１回の探索に要する体力ポイントの値、１回の探索で得られる経験値、得られた購入ポイントとともに、登録を取り消すための「登録取消」と表記されたメニューｍ３３、更新された不足ポイントを示すテキスト（「ポイント：−６５６２」）を含む。ウェブページＰ１３において、ユーザ：Ａがメニューｍ３３を選択すると、例えば図１３のＰ１２に示すように登録の確認・取消を行うウェブページに更新される。
ウェブページＰ１４は、達成率のゲージ、メニューｍ１０、１回の探索に要する体力ポイントの値、１回の探索で得られる経験値、得られた購入ポイントとともに、登録カードを受け取るための「登録カードを受け取る」と表記されたメニューｍ３４、ユーザ：Ａの購入ポイントから登録カードの入手対価を差し引いたポイントを示すテキスト（「ポイント：４３８」）を含む。ウェブページＰ１４において、ユーザ：Ａがメニューｍ３４を選択すると、ユーザ：Ａは登録カードを入手し、対戦処理等、ゲームに使用可能な状態となる。

〔登録カードがある場合における対戦処理〕
トップページＰ１１において、ユーザ：Ａがメニューｍ２を選択し、対戦処理後、ユーザ：Ａに購入ポイントが付与された場合、図１５のＰ１５又はＰ１６に示すように対戦の結果を通知するウェブページに更新される。ここで、ユーザ：Ａに購入ポイントが付与された後、ユーザ：Ａの購入ポイントが登録カードの入手対価に足りない場合、ウェブページＰ１５に更新され、ユーザ：Ａの購入ポイントが登録カードの入手対価を超えた場合、ウェブページＰ１６に更新される。
ウェブページＰ１５は、対戦に勝利したことを表記するテキスト（「対戦に勝利しました！」）、ユーザ：Ａに付与された購入ポイント（「１０００購入ポイント獲得！」）とともに、更新された不足ポイントを示すテキスト（「ポイント：−６５６２」）、登録を取り消すための「登録取消」と表記されたメニューｍ３５を含む。ウェブページＰ１５において、ユーザ：Ａがメニューｍ３５を選択すると、例えば図１３のＰ１２に示すように登録の確認・取消を行うウェブページに更新される。
ウェブページＰ１６は、対戦に勝利したことを表記するテキスト（「対戦に勝利しました！」）、ユーザ：Ａに付与された購入ポイント（「１０００購入ポイント獲得！」）とともに、ユーザ：Ａの購入ポイントから登録カードの入手対価を差し引いたポイントを示すテキスト（「ポイント：４３８」）、登録カードを受け取るための「登録カードを受け取る」と表記されたメニューｍ３６を含む。ウェブページＰ１６において、ユーザ：Ａがメニューｍ３６を選択すると、ユーザ：Ａは登録カードを入手し、対戦処理等、ゲームに使用可能な状態となる。

（６）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１６を参照して説明する。図１６は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図１６の機能ブロック図において、選択手段５２、判定手段５３、付与手段５４、及び登録手段５５が本発明の主要な構成に対応している。その他の手段（つまり、実行手段５１、解除手段５６、受付手段５７）は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成要素である。

実行手段５１は、通信端末１０に対するユーザのウェブページ上の選択に応じてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスにより本実施形態のゲームを実行する機能を備える。
実行手段５１は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。

実行手段５１がクエスト処理を実行する機能は、例えば以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、トップページ（図９のＰ１に例示するウェブページ）上でメニューｍ１が選択されると、クエスト処理用のウェブページ（図９のＰ３、Ｐ４、図１１のＰ７に例示するウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。次に、ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）の選択結果を含むＨＴＴＰリクエストを受信すると、以下の一連の処理を行う。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する（減少させる）。次に、ＣＰＵ２１は、ユーザの達成率の値を所定量だけ増加させる。さらに、ＣＰＵ２１は、例えば、増加した達成率の値を含むＨＴＭＬデータを生成して、ユーザの通信端末１０へ送信する。このとき、ＣＰＵ２１は、達成率の値が１００％に達したと判断した場合には、探索対象を次のエリアに移行するように、ＨＴＭＬデータを生成する。
クエスト処理では、探索対象となるエリアごとに、１回の探索に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの進行レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。

クエスト処理において、ＣＰＵ２１は、メニューｍ１０に対する選択を認識すると、複数のカードの中から選択されたカードをユーザに付与すること、所定の購入ポイントをユーザに付与すること、ゲーム上の他のイベントに移行する機会を付与することを、所定の、あるいはランダムな確率で決定する。
ＣＰＵ２１は、カードを付与することを決定した場合、カードを入手したことを通知するウェブページＰ３を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。ＣＰＵ２１は、複数のカードの中から選択されたカードをユーザに付与することを決定した場合には、クエスト用に予め設けられた複数のカードの中から、ユーザに対して付与されるカードを選択する。次に、ＣＰＵ２１は、対象となるユーザＩＤのユーザデータベースに、選択したカードの識別コードを書き込む。また、ＣＰＵ２１は、クエスト処理において、カード以外の所定のアイテム等の識別コードを対象となるユーザＩＤのユーザデータベースに書き込んでもよい。
ＣＰＵ２１は、購入ポイントを付与することを決定した場合、購入ポイントを入手したことを通知するウェブページＰ４を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。ＣＰＵ２１は、購入ポイントをユーザに付与することを決定した場合には、ユーザデータベースにアクセスし、対象となるユーザＩＤの付与前の購入ポイントに、新たに付与した購入ポイントを加算した値を、付与後の購入ポイントとして「購入ポイント」の欄に書き込む。
ＣＰＵ２１は、ゲーム上の他のイベントに移行する機会を付与することを決定した場合、他のイベントに移行するメニューを含むウェブページのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。例えば、ＣＰＵ２１は、購入処理に移行する機会を付与することを決定した場合、図１１のＰ７に示すように購入処理へ移行するメニューｍ１１を含むウェブページのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。

また、実行手段５１は、対戦処理を実行する機能を備える。この機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ウェブページＰ５上でメニューｍ２０（「対戦開始」）が選択されたことを認識すると、処理対象のユーザのチームと、対戦相手（他のユーザ又はコンピュータ）のチームとの対戦結果を決定する処理を行う。
対戦結果の決定方法は、各チームに含まれるカードのパラメータの値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦を行う２つのチームの各々に含まれる複数のカードのパラメータの値の合計を比較し、合計が大きな方のチームが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、パラメータの値の合計の差が大きいほど高い確率としてもよい。このとき、図７に示したように、パラメータの値を示す項目が複数（図７の例では、攻撃力と防御力の２つ）存在する場合には、各カードのパラメータの値を代表する値として、各項目の値に対して所定の重み付け（例えば、図７の例では、「攻撃力」を０．４、「防御力」を０．２の重み付けにする等）を行うことにより、総合的なパラメータの値を設定してもよい。
次に、ＣＰＵ２１は、対戦の結果を決定すると、対戦結果をユーザ：Ａに通知するウェブページ（例えば、ウェブページＰ６など）を表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。

選択手段５２は、カードを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するカードの選択を受け付ける機能を備える。なお、カードはオブジェクトの一例である。選択手段５２の機能は、例えば以下のとおり実現される。
ＣＰＵ２１は、通信端末１０から受信したＨＴＴＰリクエストにより購入処理へ移行するメニューｍ１１が選択されたことを認識すると、ユーザが選択可能な複数のカードの情報をモンスターカードデータベースから読み出し、図１１のＰ８に例示する購入処理用のウェブページのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。その後、ＣＰＵ２１は、通信端末１０から受信したＨＴＴＰリクエストによりユーザが選択したカードを認識する。

判定手段５３は、選択されたカードの入手対価と、ユーザがゲーム上で保有するポイント（購入ポイント）とを比較して、ユーザがカードを入手可能か否かを判定する機能を備える。判定手段５３の機能は、例えば以下のとおり実現される。
ＣＰＵ２１は、ＨＴＴＰリクエストに含まれる選択結果に基づいて、ユーザが選択したカードを認識すると、ユーザデータベースにアクセスし、ユーザＩＤに対応する「購入ポイント」（ユーザの購入ポイント）の値を読み出すとともに、モンスターカードデータベースにアクセスし、ユーザが入手を希望するカードの「入手対価」の値を読み出す。次に、ＣＰＵ２１は、ユーザの購入ポイントとユーザが入手を希望するカードの入手対価を比較し、購入ポイントが入手対価以上であれば、ユーザがカードを入手可能と判定する。一方、購入ポイントが入手対価未満であれば、ユーザがカードを入手不能と判定する。

付与手段５４は、ユーザがカードを入手可能と判定された場合に、入手対価に相当するポイントと引き換えにユーザにカードを付与する機能を備える。付与手段５４の機能は、例えば以下のとおり実現される。
ＣＰＵ２１は、ユーザがカードを入手可能と判定した場合、ユーザの購入ポイントからカードの入手対価を差し引いた値を求め、求めた値をユーザデータベースのユーザＩＤに対応する「購入ポイント」の欄に書き込み、同時に、カードの識別コードをユーザデータベースのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。

登録手段５５は、ユーザがカードを入手不能と判定された場合に、カードをユーザの入手希望カードとして登録する機能を備える。登録手段５５の機能は、例えば以下の通り実現される。
ＣＰＵ２１は、ユーザがカードを入手不能と判定した場合、ユーザのユーザＩＤ及びカードの識別コードを、登録時刻、登録有効期限とともに、図８に例示する登録テーブルに登録する。なお、登録時刻は入手不能と判定した時刻としてもよい。登録有効期限は登録時刻から所定時間（登録期間）後の時刻とすることができる。この登録期間は、登録カードの入手対価に応じた長さとしてもよい。登録カードの入手対価が高いほど、登録カードを入手するのにユーザが要するゲームの実行時間が長くなる。このため登録カードの入手対価に応じて登録カードの登録期間の長さを変更することで、登録期間の長さを適切な値に設定することができる。例えば、登録期間が入手対価に対して短すぎるためにユーザが登録カードの入手を諦めることを回避することができる。
例えば入手対価が高いカードが登録された場合には、より長い登録期間としてもよい。例えば、入手対価１００ポイント当たり６分の登録期間を設定してもよい。
また、図１２のＰ９に例示するウェブページにおいてユーザが登録をするための操作（メニューｍ１４の選択）をしたときに、ユーザのユーザＩＤ及びカードの識別コードを、登録時刻、登録有効期限とともに、図８に例示する登録テーブルに登録してもよい。この場合、メニューｍ１４が選択された時刻を登録時刻としてもよい。
同時に、ＣＰＵ２１は、ユーザの購入ポイントからカードの入手対価を差し引いた値を求め、求めた値をユーザデータベースのユーザＩＤに対応する「購入ポイント」の欄に書き込む。このとき、購入ポイントが入手対価未満であるため、「購入ポイント」の欄には負の値（不足ポイント）が書き込まれる。

解除手段５６は、登録有効期限の経過後、入手希望カードの登録を解除する機能を備える。解除手段５６の機能は、例えば以下の通り実現される。
ＣＰＵ２１は、ユーザがゲームにアクセスしたとき、登録テーブルを参照し、対応するユーザＩＤが登録テーブルに記録されている場合、現在時刻と、対応する登録コードの登録有効期限を比較する。現在時刻が登録有効期限よりも後であれば、ＣＰＵ２１は、モンスターカードデータベースにアクセスし、登録カードの「入手対価」の値を読み出す。次に、ＣＰＵ２１は、ユーザデータベースにアクセスし、「購入ポイント」の欄に書き込まれた不足ポイントに「入手対価」を加算した値をユーザＩＤに対応する「購入ポイント」の欄に書き込むことで、購入ポイントの払い戻しを行う。その後、ＣＰＵ２１は、登録テーブルから登録コードの情報を削除することで登録状態を解除する。
なお、ＣＰＵ２１は、ユーザが登録カードを入手可能と判定し、ユーザに登録カードを付与した場合も、付与した登録カードに対応する登録コードの情報を登録テーブルから削除する。
また、入手希望カードの登録の解除は、ユーザがゲームにアクセスしたときに限らず、例えば現在時刻が登録有効期限に達した順に、登録の解除を行ってもよい。

受付手段５７は、入手希望カードの登録の解除をユーザから受け付ける機能を備える。受付手段５７の機能は、例えば以下の通り実現される。
ＣＰＵ２１は、ユーザがゲームにアクセスしたとき、登録テーブルを参照し、対応するユーザＩＤが登録テーブルに記録されている場合、現在時刻と、対応する登録コードの登録有効期限を比較する。現在時刻が登録有効期限よりも前であれば、ＣＰＵ２１は、図１３のＰ１１に例示する、メニューｍ３を含むトップページのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。ユーザがメニューｍ３を選択した場合、ＣＰＵ２は、図１３のＰ１２に例示する、登録を取り消すためのメニューｍ３１（「登録取消」）を含むウェブページのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。通信端末１０からＨＴＴＰリクエストを受信することでメニューｍ３１が選択されたことを認識すると、ＣＰＵ２１は、モンスターカードデータベースにアクセスし、登録カードの「入手対価」の値を読み出す。次に、ＣＰＵ２１は、ユーザデータベースにアクセスし、「購入ポイント」の欄に書き込まれた「不足ポイント」に「入手対価」を加算した値をユーザＩＤに対応する「購入ポイント」の欄に書き込むことで、購入ポイントの払い戻しを行う。その後、ＣＰＵ２１は、登録テーブルから登録コードの情報を削除することで登録状態を解除する。

なお、登録コードの情報を削除することで登録状態を解除する代わりに、登録状態をフラグにより管理してもよい。例えば、登録が維持されている場合はフラグを「１」、登録が取り消された場合や登録有効期限を経過した場合にフラグを「０」とすることで、登録状態を管理しながら登録履歴を残すことができる。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１７〜図１９のフローチャートを参照して説明する。図１７は、本実施形態のゲームにおいてクエスト処理を行うときのフローチャートである。図１８は、本実施形態のゲームにおいて、対戦処理を行うときのフローチャートである。図１９は、本実施形態のゲームにおいて、購入処理を行うときのフローチャートである。
なお、図１７〜図１９のフローチャートにおける各処理の実行に伴って適宜、Ｐ１〜Ｐ１６の各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、煩雑とならないようにＨＴＭＬデータの送信処理をフローチャートには記載しない場合もある。フローチャート上で、ウェブページＰ１〜Ｐ１６の各々が表示されるタイミングは、Ｐ１〜Ｐ１６の符号で示してある。
なお、図１７〜図１９のフローチャートでは、ユーザ：Ａがゲームを実行する場合を一例として説明する。

〔クエスト処理〕
先ず図１７のフローチャートにおいて、ＣＰＵ２１は、ウェブページＰ２のメニューｍ１０（「クエスト実行」）が選択されたことを認識すると（ステップＳ１００：ＹＥＳ）、ＣＰＵ２１は、ユーザデータベースにアクセスしてユーザ：Ａの達成率、体力ポイント、経験値等を更新する（ステップＳ１０２）。次に、ＣＰＵ２１は、複数のモンスターカードの中から選択されたモンスターカードをユーザ：Ａに付与するか否か、購入ポイントをユーザ：Ａに付与するか否か、あるいは、購入処理に移行する機会を与えるか否かについて、所定の、あるいはランダムな確率で決定する（ステップＳ１０４）。ステップＳ１０４において、モンスターカードをユーザ：Ａに付与することを決定すると（ステップＳ１０４：カード付与）、ＣＰＵ２１は、ユーザ：Ａにモンスターカードを対応付ける付与する処理を行う（ステップＳ１０６）。この場合、ＣＰＵ２１は、モンスターカードデータベースにアクセスし、クエスト用に予め設けられた複数のモンスターカードの中から、付与されるモンスターカードの識別コードを選択する。次に、ＣＰＵ２１は、ユーザデータベースにアクセスして選択した識別コードをユーザ：ＡのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。その後、ＣＰＵ２１は、クエスト処理を終了する。

ステップＳ１０４において、購入ポイントをユーザ：Ａに付与することを決定すると（ステップＳ１０４：ポイント付与）、ＣＰＵ２１は、ユーザ：Ａに購入ポイントを付与する処理を行う（ステップＳ１０８）。この場合、ＣＰＵ２１は、ユーザデータベースにアクセスし、対象となるユーザＩＤの付与前の購入ポイントに、新たに付与した購入ポイントを加算した値を、付与後の購入ポイントとして「購入ポイント」の欄に書き込む。次に、ＣＰＵ２１は、ユーザ：Ａに登録カードがあるか否かを判定する（ステップＳ１１０）。具体的には、ユーザ：ＡのユーザＩＤが登録テーブルに登録されており、かつ現在時刻が登録期間内であれば、ユーザ：Ａに登録カードがあると判定する。一方、ユーザ：ＡのユーザＩＤが登録テーブルに登録されていない場合、ユーザ：Ａに登録カードがないと判定する。また、ユーザ：ＡのユーザＩＤが登録テーブルに登録されているが現在時刻が登録期間内でない場合も、ユーザ：Ａに登録カードがないと判定する。ユーザ：Ａに登録カードがないと判定した場合（ステップＳ１１０：ＮＯ）、ＣＰＵ２１は、クエスト処理を終了する。
ユーザ：Ａに登録カードがあると判定した場合（ステップＳ１１０：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが、登録カードの入手対価以上であるか否かを判定する（ステップＳ１１２）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄の値を読み出すとともに、モンスターカードデータベースにアクセスし、登録カードの識別コードに対応する「入手対価」の欄の値を読み出し、購入ポイントと入手対価を比較する。
購入ポイントが入手対価以上であると判定した場合（ステップＳ１１２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードの受取操作を行ったか否かを判定する（ステップＳ１１４）。具体的には、ＣＰＵ２１は、ウェブページＰ１４において、メニューｍ３４が選択されたか否かを判定する。ユーザ：Ａが登録カードの受取操作を行わない場合（ステップＳ１１４：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
ユーザ：Ａが登録カードの受取操作を行った場合（ステップＳ１１４：ＹＥＳ）、ＣＰＵ２１は、登録カードをユーザ：Ａに付与する（ステップＳ１１６）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：Ａの購入ポイントからカードの入手対価を差し引いた値を、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込み、同時に、登録カードの識別コードをユーザ：ＡのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。その後、ＣＰＵ２１は登録テーブルから登録コードの情報を削除し、クエスト処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ１１２：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ１１８）。具体的には、ＣＰＵ２１は、ウェブページＰ１３において、メニューｍ３３が選択されたか否かを判定する。ユーザ：Ａが登録取消操作をしない場合（ステップＳ１１８：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ１１８：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ１２０）、クエスト処理を終了する。具体的には、ウェブページＰ１２においてメニューｍ３１が選択されたか否かを判定する。メニューｍ３１が選択されたことを認識すると、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込まれた不足ポイントに、登録カードの入手対価を加算した値をユーザＩＤに対応する「購入ポイント」の欄に書き込む。その後、ＣＰＵ２１は、登録テーブルから登録コードの情報を削除することで登録を解除し、登録解除処理を終了する。一方、メニューｍ３１以外が選択された場合や、メニューｍ３１が選択されずに所定時間経過した場合には、登録解除処理をせずにクエスト処理を終了する。

ステップＳ１０４において、購入処理に移行する機会をユーザ：Ａに付与することを決定すると（ステップＳ１０４：購入機会付与）、ＣＰＵ２１は、ウェブページＰ７においてメニューｍ１１が選択されたか否かを判定する（ステップＳ１２２）。メニューｍ１１以外が選択された場合や、メニューｍ１１が選択されずに所定時間経過した場合（ステップＳ１２２：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
メニューｍ１１が選択された場合（ステップＳ１２２：ＹＥＳ）、ＣＰＵ２１は後述する購入処理を行い（ステップＳ１２４）、クエスト処理を終了する。
なお、ＣＰＵ２１は、ウェブページＰ３、Ｐ４、Ｐ７においてメニューｍ１０が選択された場合、ステップＳ１００から再びクエスト処理を開始する。また、メニューｍ１０が選択されずに所定時間経過した場合や、メニューｍ１０以外が選択された場合（ステップＳ１００：ＮＯ）、クエスト処理を終了してもよい。
また、ＣＰＵ２１は、ステップＳ１０４の処理において、ユーザ：Ａに対してカード以外の所定のアイテムを、所定の、あるいはランダムな確率で付与するか否かについて決定してもよい。あるいは、ＣＰＵ２１は、ステップＳ１０４の処理において、カード付与、ポイント付与、購入機会付与のいずれも決定せずに、クエスト処理を終了してもよい。

〔対戦処理〕
次に、図１８を参照して、対戦処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、ウェブページＰ５上でメニューｍ２０（「対戦開始」）が選択されたことを認識すると（ステップＳ２００：ＹＥＳ）、処理対象のユーザ（ここでは、ユーザ：Ａ）のチームと、対戦相手（コンピュータ又は他のユーザ）のチームとの対戦結果を決定する処理を行う（ステップＳ２０２）。

ユーザ：Ａが対戦に敗北した場合（ステップＳ２０２：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａに対して購入ポイントを減算する処理を行い（ステップＳ２０４）、対戦処理を終了する。ここで、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：Ａが敗北した場合、ユーザデータベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する購入ポイントの値を所定値（例えば１０００）だけ減少させる。なお、ＣＰＵ２１は、ユーザ間対戦においてユーザ：Ａが敗北した場合、ユーザデータベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する購入ポイントの値を所定値（例えば１０００）だけ減少させると同時に、対戦相手のユーザＩＤに対応する購入ポイントの値を所定値（例えば１０００）だけ増加させる。

ユーザ：Ａが対戦に勝利した場合（ステップＳ２０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａに対して購入ポイントを加算する処理を行う（ステップＳ２０６）。ここで、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：Ａが勝利した場合、ユーザデータベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する購入ポイントの値を所定値（例えば１０００）だけ増加させる。なお、ＣＰＵ２１は、ユーザ間対戦においてユーザ：Ａが勝利した場合、ユーザデータベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する購入ポイントの値を所定値（例えば１０００）だけ増加させると同時に、対戦相手のユーザＩＤに対応する購入ポイントの値を所定値（例えば１０００）だけ減少させる。
次に、ＣＰＵ２１は、ユーザ：Ａに登録カードがあるか否かを判定する（ステップＳ２０８）。具体的には、ユーザ：ＡのユーザＩＤが登録テーブルに登録されており、かつ現在時刻が登録期間内であれば、ユーザ：Ａに登録カードがあると判定する。一方、ユーザ：ＡのユーザＩＤが登録テーブルに登録されていない場合、ユーザ：Ａに登録カードがないと判定する。また、ユーザ：ＡのユーザＩＤが登録テーブルに登録されているが現在時刻が登録期間内でない場合も、ユーザ：Ａに登録カードがないと判定する。ユーザ：Ａに登録カードがないと判定した場合（ステップＳ２０８：ＮＯ）、ＣＰＵ２１は、対戦処理を終了する。
ユーザ：Ａに登録カードがあると判定した場合（ステップＳ２０８：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが、登録カードの入手対価以上であるか否かを判定する（ステップＳ２１０）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄の値を読み出すとともに、モンスターカードデータベースにアクセスし、登録カードの識別コードに対応する「入手対価」の欄の値を読み出し、購入ポイントと入手対価を比較する。
購入ポイントが入手対価以上であると判定した場合（ステップＳ２１０：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードの受取操作を行ったか否かを判定する（ステップＳ２１２）。具体的には、ＣＰＵ２１は、ウェブページＰ１６において、メニューｍ３６が選択されたか否かを判定する。ユーザ：Ａが登録カードの受取操作を行わない場合（ステップＳ２１２：ＮＯ）、ＣＰＵ２１は対戦処理を終了する。
ユーザ：Ａが登録カードの受取操作を行った場合（ステップＳ２１２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードをユーザ：Ａに付与する（ステップＳ２１４）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：Ａの購入ポイントから登録カードの入手対価を差し引いた値を、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込み、同時に、登録カードの識別コードをユーザ：ＡのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。その後、ＣＰＵ２１は登録テーブルから登録コードの情報を削除し、対戦処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ２１０：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ２１６）。具体的には、ＣＰＵ２１は、ウェブページＰ１５において、メニューｍ３５が選択されたか否かを判定する。ユーザ：Ａが登録取消操作をしない場合（ステップＳ２１６：ＮＯ）、ＣＰＵ２１は対戦処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ２１６：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ２１８）、対戦処理を終了する。具体的には、ウェブページＰ１２においてメニューｍ３１が選択されたか否かを判定する。メニューｍ３１が選択されたことを認識すると、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込まれた不足ポイントに、登録カードの入手対価を加算した値をユーザＩＤに対応する「購入ポイント」の欄に書き込む。その後、ＣＰＵ２１は、登録テーブルから登録コードの情報を削除することで登録を解除し、登録解除処理を終了する。一方、メニューｍ３１以外が選択された場合や、メニューｍ３１が選択されずに所定時間経過した場合には、登録解除処理をせずに対戦処理を終了する。
なお、ＣＰＵ２１は、ウェブページＰ５上でメニューｍ２０（「対戦開始」）が選択されない状態で所定時間経過した場合や、メニューｍ２０以外が選択された場合、対戦処理を終了してもよい（ステップＳ２００：ＮＯ）。

〔購入処理〕
次に、図１９を参照して、購入処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、ウェブページＰ７でメニューｍ１１（「立ち寄る」）が選択されたことを認識すると、ユーザ：Ａが選択可能な複数のカード（出品カード）を決定し（ステップＳ３００）、Ｐ８に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。次に、ＣＰＵ２１は、ウェブページＰ８においてユーザ：Ａがいずれかの出品カードを選択したか否かを判定する（ステップＳ３０２）。具体的には、ＣＰＵ２１は、出品カードに対応するメニューｍ１２、ｍ１３（「入手」）が選択されたか否かを判定する。ユーザ：Ａがいずれの出品カードも選択しない場合（ステップＳ３０２：ＮＯ）、ＣＰＵ２１は、購入処理を終了する。
ユーザ：Ａがいずれかの出品カードを選択した場合（ステップＳ３０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが選択されたカード（選択カード）の入手対価以上であるか否かを判定する（ステップＳ３０４）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄の値を読み出すとともに、モンスターカードデータベースにアクセスし、選択されたカードの識別コードに対応する「入手対価」の欄の値を読み出し、購入ポイントと入手対価を比較する。
購入ポイントが入手対価以上であると判定した場合（ステップＳ３０４：ＹＥＳ）、ＣＰＵ２１は、選択カードをユーザ：Ａに付与する（ステップＳ３０６）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：Ａの購入ポイントから選択カードの入手対価を差し引いた値を、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込み、同時に、選択カードの識別コードをユーザ：ＡのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。その後、ＣＰＵ２１は購入処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ３０４：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録操作をしたか否かを判定する（ステップＳ３０８）。具体的には、ＣＰＵ２１は、ウェブページＰ９において、メニューｍ１４が選択されたか否かを判定する。ユーザ：Ａが登録操作をしない場合（ステップＳ３０８：ＮＯ）、ＣＰＵ２１は購入処理を終了する。
ユーザ：Ａが登録操作をした場合（ステップＳ３０８：ＹＥＳ）、ＣＰＵ２１は、登録処理を行い（ステップＳ３１０）、購入処理を終了する。具体的には、ＣＰＵ２１は、ユーザ：ＡのユーザＩＤ及び選択カードの識別コードを図８に例示する登録テーブルに登録するとともに、現在時刻を登録時刻として、現在時刻から所定時間（登録期間）後の時刻を登録有効期限として、登録テーブルに登録する。なお、登録処理において、選択カードの入手対価に応じてＣＰＵ２１が登録期間を決定してもよい。
例えば入手対価が高い選択カードが登録された場合には、より長い登録期間としてもよい。
なお、ステップＳ３０８を省略し、ステップＳ３０４において購入ポイントが入手対価未満であると判定された場合に、ユーザ：Ａの選択によらずに登録処理を行ってもよい。

以上説明したように、このゲーム制御装置では、カードを入手する機会が付与されたユーザが十分なポイントを有していない場合でも、ユーザがカードを登録しておくことができるため、登録カードを入手するためにゲームを実行する動機をユーザに与えることができる。
また、カードを入手する機会が付与されたユーザが十分な購入ポイントを有していない場合でも、その後十分な購入ポイントを有する状態となった後にユーザが登録カードを入手することができるため、ユーザが購入ポイントを増加させるためにゲームを実行する動機付けとなる。
また、カードの登録が所定期間の経過後に解除される場合、登録が解除される前にゲームを実行する動機をユーザに与えることができる。なお、本発明はこれに限らず、登録有効期限を設けなくてもよい。
また、クエスト処理や対戦処理等のゲームを実行するウェブページや、ユーザのトップページに、登録の確認・取消を行うウェブページへ遷移するショートカットメニューを設ける場合、ユーザはいつでも登録の取消を行い、他のカードを入手可能な状態とすることができる。なお、本発明はこれに限らず、ユーザによる登録の取消を可能としなくてもよい。

上記実施形態において、カードに複数種類の属性を設定するとともに、ウェブページＰ５においてユーザがメニューｍ１１を選択した後、購入処理においてユーザが入手を希望するカードの属性を選択するウェブページに更新されるようにしてもよい。また、ウェブページＰ５においてユーザがメニューｍ１１を選択した後、購入処理においてユーザが選択可能なカードの枚数や、その中に含まれる希少度（レア度）が高いカードの枚数を示すテキスト等を含むウェブページに更新されるようにしてもよい。

上記実施形態において、登録有効期限を経過して登録がキャンセルされた場合等、ユーザの操作によらずに登録が解除された場合、その後、ユーザに登録がキャンセルされたことを提示してもよい。
上記実施形態において、ゲームデータベース３２に登録テーブルを記憶させていたが、ゲームサーバ２０のＲＡＭ２３や外部の記憶装置に登録テーブルを記憶させてもよい。

（８）変形例
以下、上述した実施形態の変形例について説明する。

（８−１）変形例１
本変形例に係るゲーム制御装置の機能ブロック図を、図２０に示す。図２０に示すように、本変形例では、図１６の機能ブロック図と比較して、延長手段５８が追加された点で異なる。
延長手段５８は、入手希望カードの入手対価とユーザの保有ポイントとの差額が減少したとき、登録時刻から登録有効期限までの所定期間（登録期間）を延長する機能を備える。延長手段５８の機能は、例えば以下のとおり実現される。
ユーザに登録カードがある場合において、クエスト処理や対戦処理等、ゲームの実行に応じてユーザに購入ポイントを付与するとき、ＣＰＵ２１は、ユーザデータベースにアクセスし、対象となるユーザＩＤの付与前の購入ポイントに、新たに付与した購入ポイントを加算した値を、付与後の購入ポイントとして「購入ポイント」の欄に書き込む。
次に、ＣＰＵ２１は、モンスターカードデータベースにアクセスし、登録カードの識別コードに対応する「入手対価」の欄の値を読み出し、購入ポイントと入手対価を比較する。そして、購入ポイントが入手対価未満であると判定した場合、ＣＰＵ２１は、登録期間を延長する。

具体的には、ＣＰＵ２１は、ユーザに購入ポイントを付与するとき、登録期間の延長時間の長さを決定し、延長後の登録有効期限を算出して登録テーブルに書き込む。このとき、既に書き込まれている登録有効期限を削除して、延長後の登録有効期限を書き込んでもよい。あるいは、延長前の登録を解除するとともに、延長後の登録有効期限について新たな登録として登録テーブルに書き込んでもよい。
また、ＣＰＵ２１は、ユーザに新たに購入ポイントが付与される度に、所定の時間、例えば３分、登録期間を延長してもよい。あるいは、ＣＰＵ２１は、ユーザに新たに付与された購入ポイントに応じて登録期間の延長時間の長さを決定してもよい。例えば、ユーザに新たに付与された購入ポイント１００ポイントにつき、延長時間を３分としてもよい。

図２１は本変形例における、購入ポイントの付与処理を行うときのフローチャートの一例である。ユーザに購入ポイントが付与されると、ＣＰＵ２１は、ユーザ：Ａの付与後の購入ポイントが登録カードの入手対価以上であるか否かを判定する（ステップＳ４００）。
購入ポイントが入手対価以上であると判定した場合（ステップＳ４００：ＹＥＳ）、ＣＰＵ２１は、ＣＰＵ２１は、ユーザ：Ａが登録カードの受取操作を行ったか否かを判定する（ステップＳ４０２）。ユーザ：Ａが登録カードの受取操作を行わない場合（ステップＳ４０２：ＮＯ）、ＣＰＵ２１は付与処理を終了する。
ユーザ：Ａが登録カードの受取操作を行った場合（ステップＳ４０２：ＹＥＳ）、ＣＰＵ２１は、登録カードをユーザ：Ａに付与する（ステップＳ４０４）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：Ａの購入ポイントから登録したカードの入手対価を差し引いた値を、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込み、同時に、登録カードの識別コードをユーザ：ＡのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。その後、ＣＰＵ２１は付与処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ４００：ＮＯ）、ＣＰＵ２１は、登録期間の延長処理を行う（ステップＳ４０６）。例えば、ＣＰＵ２１は、付与された購入ポイントに応じて登録期間の延長時間の長さを決定し、延長後の登録有効期限を算出して登録テーブルに書き込む。次に、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ４０８）。ユーザ：Ａが登録取消操作をしない場合（ステップＳ４０８：ＮＯ）、ＣＰＵ２１は付与処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ４０８：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ４１０）、付与処理を終了する。

本変形例においては、ユーザがゲームを実行して購入ポイントを少しでも増やすことで、登録期間が延長されるため、登録が解除されてアイテムを入手する機会を失うことを回避するためにユーザがゲームを実行する動機を与えることができる。

（８−２）変形例２
本変形例に係るゲーム制御装置の機能ブロック図を、図２２に示す。図２２に示すように、本変形例では、図１６の機能ブロック図と比較して、入手対価変動手段５９が追加された点で異なる。

入手対価変動手段５９は、登録時刻からの時間に応じて、登録カードの入手対価を変動させる機能を備える。入手対価変動手段５９の機能は、例えば以下のとおり実現される。
ユーザに登録カードがある場合において、クエスト処理や対戦処理等、ゲームの実行に応じてユーザに購入ポイントを付与した後、ユーザの購入ポイントと登録カードの入手対価を比較する前に、ＣＰＵ２１は、購入ポイントとの比較対象となる入手対価を、登録時刻から現在時刻までの時間に応じて増加させた値（割増入手対価）とする。例えば、登録カードの入手対価に、登録時刻から現在時刻までの時間に所定の割合（利率）を乗じた値（利息）を加算した値を割増入手対価としてもよい。
あるいは、登録カードの入手対価に、登録時刻から現在時刻までの時間１分当たり１ポイントを加算した値を割増入手対価としてもよい。

図２３は本変形例における、購入ポイントの付与処理を行うときのフローチャートの一例である。ユーザに購入ポイントが付与されると、ＣＰＵ２１は、割増入手対価を算定する（ステップＳ５００）。次に、ＣＰＵ２１は、ユーザ：Ａの付与後の購入ポイントが登録カードの割増入手対価以上であるか否かを判定する（ステップＳ５０２）。
購入ポイントが割増入手対価以上であると判定した場合（ステップＳ５０２：ＹＥＳ）、ＣＰＵ２１は、ＣＰＵ２１は、ユーザ：Ａが登録したカードの受取操作を行ったか否かを判定する（ステップＳ５０４）。ユーザ：Ａが登録したカードの受取操作を行わない場合（ステップＳ５０４：ＮＯ）、ＣＰＵ２１は付与処理を終了する。
ユーザ：Ａが登録したカードの受取操作を行った場合（ステップＳ５０４：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録したカードをユーザ：Ａに付与する（ステップＳ５０６）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：Ａの購入ポイントから登録したカードの割増入手対価を差し引いた値を、ユーザ：ＡのユーザＩＤに対応する「購入ポイント」の欄に書き込み、同時に、登録したカードの識別コードをユーザ：ＡのユーザＩＤの「保有カード、アイテムの識別コード」の欄に書き込む。その後、ＣＰＵ２１は付与処理を終了する。
購入ポイントが割増入手対価未満であると判定した場合（ステップＳ５０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ５０８）。ユーザ：Ａが登録取消操作をしない場合（ステップＳ５０８：ＮＯ）、ＣＰＵ２１は付与処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ５０８：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ５１０）、付与処理を終了する。

本変形例においては、登録時刻からの時間に応じて、登録カードの入手対価を変動させるため、入手対価がより安い時期に登録カードを入手する目的でユーザがゲームを実行する動機を与えることができる。例えば、利息分を考慮して登録時刻から現在時刻までの時間に応じて割増入手対価を増加させる場合には、より早い時期に入手希望カードを入手するためにゲームを実行する動機をユーザに与えることができる。
なお、上記変形例においては、登録時刻から現在時刻までの時間に応じて登録カードの入手対価を増加させる例について説明したが、登録時刻から現在時刻までの時間に応じて登録カードの入手対価を減少させてもよい。
例えば、登録の解除を受け付けた場合、利息分を考慮して、登録の解除を受け付けた時刻（受付時刻）により、登録カードの入手対価を減少させた値（割引入手対価）を購入ポイントとして払い戻してもよい。例えば、モンスターカードデータベースから読み出した登録カードの「入手対価」に、登録時刻から受付時刻までの時間に所定の割合（利率）を乗じた値（利息）を差し引いた入手対価（割引入手対価）をユーザに払い戻してもよい。

（８−３）変形例３
本変形例に係るゲーム制御装置の機能ブロック図を、図２４に示す。図２４に示すように、本変形例では、図１６の機能ブロック図と比較して、ポイント付与手段６０が追加された点で異なる。

ポイント付与手段６０は、ゲームの実行に応じてユーザにポイントを付与するとともに、入手希望カードが登録されている場合、ゲームの実行に応じてユーザに付与するポイントを変動させる機能を備える。ポイント付与手段６０の機能は、例えば以下のとおり実現される。
ユーザに登録カードがある場合において、クエスト処理や対戦処理等、ゲームの実行に応じてユーザに購入ポイントを付与するとき、ＣＰＵ２１は、登録カードがない場合とは異なる値の購入ポイント（割増購入ポイント）をユーザに付与する。例えば、登録カードがある場合は、登録カードがない場合の購入ポイントよりも（例えば１０％）多い割増購入ポイントをユーザに付与してもよい。

図２５は、本変形例のゲームにおいてクエスト処理を行うときのフローチャートである。なお、図１７のフローチャートと同様のステップについては、説明を一部割愛する。
先ず図２５のフローチャートにおいて、トップページＰ１上でメニューｍ１（「クエスト」）が選択されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図９のＰ２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）が選択されたことを認識すると（ステップＳ６００：ＹＥＳ）、ＣＰＵ２１は、ユーザデータベースにアクセスしてユーザ：Ａの達成率、体力ポイント、経験値等を更新する（ステップＳ６０２）。次に、ＣＰＵ２１は、複数のモンスターカードの中から選択されたモンスターカードをユーザ：Ａに付与するか否か、購入ポイントをユーザ：Ａに付与するか否か、あるいは、購入処理に移行する機会を与えるか否かについて、所定の、あるいはランダムな確率で決定する（ステップＳ６０４）。ステップＳ６０４において、モンスターカードをユーザ：Ａに付与することを決定すると（ステップＳ６０４：カード付与）、ＣＰＵ２１は、ユーザ：Ａにモンスターカードを対応付ける付与する処理を行い（ステップＳ６０６）、クエスト処理を終了する。

ステップＳ６０４において、購入ポイントをユーザ：Ａに付与することを決定すると（ステップＳ１０４：ポイント付与）、ＣＰＵ２１は、ユーザ：Ａに登録カードがあるか否かを判定する（ステップＳ６０８）。ユーザ：Ａに登録カードがないと判定した場合（ステップＳ６０８：ＮＯ）、ＣＰＵ２１は、通常の購入ポイントをユーザ：Ａに付与する処理を行い（ステップＳ６１０）。クエスト処理を終了する。
一方、ユーザ：Ａに登録カードがあると判定した場合（ステップＳ６０８：ＹＥＳ）、ＣＰＵ２１は、通常の購入ポイントよりも多い割増購入ポイントをユーザ：Ａに付与する処理を行う（ステップＳ６１２）。この場合、ＣＰＵ２１は、ユーザ：Ａに付与する割増購入ポイントを算出するとともに、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する付与前の購入ポイントに、付与する割増購入ポイントを加算した値を、「購入ポイント」の欄に書き込む。
次に、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが、ユーザ：Ａの登録カードの入手対価以上であるか否かを判定する（ステップＳ６１４）。
購入ポイントが入手対価以上であると判定した場合（ステップＳ６１４：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードの受取操作を行ったか否かを判定する（ステップＳ６１６）。ユーザ：Ａが登録カードの受取操作を行わない場合（ステップＳ６１６：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
ユーザ：Ａが登録カードの受取操作を行った場合（ステップＳ６１６：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードをユーザ：Ａに付与し（ステップＳ６１８）、クエスト処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ６１４：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ６２０）。ユーザ：Ａが登録取消操作をしない場合（ステップＳ６２０：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ６２０：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ６２２）、クエスト処理を終了する。

ステップＳ６０４において、購入処理に移行する機会をユーザ：Ａに付与することを決定すると（ステップＳ６０４：購入機会付与）、ＣＰＵ２１は、ウェブページＰ７においてメニューｍ１１が選択されたか否かを判定する（ステップＳ６２４）。メニューｍ１１以外が選択された場合や、メニューｍ１１が選択されずに所定時間経過した場合（ステップＳ６２４：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
メニューｍ１１が選択された場合（ステップＳ６２４：ＹＥＳ）、ＣＰＵ２１は購入処理を行い（ステップＳ６２６）、クエスト処理を終了する。
なお、ＣＰＵ２１は、ウェブページＰ３、Ｐ４、Ｐ７においてメニューｍ１０が選択された場合、ステップＳ６００から再びクエスト処理を開始する。また、メニューｍ１０が選択されずに所定時間経過した場合や、メニューｍ１０以外が選択された場合（ステップＳ６００：ＮＯ）、クエスト処理を終了してもよい。

図２６は、本変形例のゲームにおいて対戦処理を行うときのフローチャートである。なお、図１８のフローチャートと同様のステップについては、説明を一部割愛する。
ＣＰＵ２１は、トップページＰ１上でメニューｍ２（「対戦」）が選択されたことを認識すると、Ｐ５に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。
ＣＰＵ２１は、ウェブページＰ４上でメニューｍ２０（「対戦開始」）が選択されたことを認識すると（ステップＳ７００：ＹＥＳ）、処理対象のユーザ（ここでは、ユーザ：Ａ）のチームと、対戦相手（コンピュータ又は他のユーザ）のチームとの対戦結果を決定する処理を行う（ステップＳ７０２）。

ユーザ：Ａが対戦に敗北した場合（ステップＳ７０２：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａに対して購入ポイントを減算する処理を行い（ステップＳ７０４）、対戦処理を終了する。
ユーザ：Ａが対戦に勝利した場合（ステップＳ７０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａに登録カードがあるか否かを判定する（ステップＳ７０６）。ユーザ：Ａに登録カードがないと判定した場合（ステップＳ７０６：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａに対して通常の購入ポイントを加算する処理を行い（ステップＳ７０８）、対戦処理を終了する。
ユーザ：Ａに登録カードがあると判定した場合（ステップＳ７０６：ＹＥＳ）、ＣＰＵ２１は、通常の購入ポイントよりも多い割増購入ポイントをユーザ：Ａに付与する処理を行う（ステップＳ７１０）。この場合、ＣＰＵ２１は、ユーザ：Ａに付与する割増購入ポイントを算出するとともに、ユーザデータベースにアクセスし、ユーザ:ＡのユーザＩＤに対応する付与前の購入ポイントに、割増購入ポイントを加算した値を、付与後の購入ポイントとして「購入ポイント」の欄に書き込む。

次に、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが、ユーザ：Ａの登録カードの入手対価以上であるか否かを判定する（ステップＳ７１２）。購入ポイントが入手対価以上であると判定した場合（ステップＳ７１２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードの受取操作を行ったか否かを判定する（ステップＳ７１４）。ユーザ：Ａが登録カードの受取操作を行わない場合（ステップＳ７１４：ＮＯ）、ＣＰＵ２１は対戦処理を終了する。
ユーザ：Ａが登録カードの受取操作を行った場合（ステップＳ７１４：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードをユーザ：Ａに付与し（ステップＳ７１６）、対戦処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ７１２：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ７１８）。ユーザ：Ａが登録取消操作をしない場合（ステップＳ７１８：ＮＯ）、ＣＰＵ２１は対戦処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ７１８：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ７２０）、対戦処理を終了する。
なお、ＣＰＵ２１は、ウェブページＰ５上でメニューｍ２０（「対戦開始」）が選択されない状態で所定時間経過した場合や、メニューｍ２０以外が選択された場合、対戦処理を終了してもよい（ステップＳ７００：ＮＯ）。

本変形例においては、入手希望カードが登録されていない場合と登録されている場合とでユーザに付与するポイントを変動させることで、入手希望カードを入手するのにユーザが要するゲームの実行時間を変動させることができる。
例えば、入手希望カードが登録されていない場合よりも登録されている場合にユーザに付与するポイントを多くすることで、ユーザが入手希望カードを入手するのに要するゲームの実行時間が短くなる。このため、十分なポイントを有していない場合でも、ユーザが積極的に入手希望カードを登録してゲームを実行する動機を与えることができる。
一方、利息分を考慮して、入手希望カードが登録されていない場合よりも登録されている場合にユーザに付与するポイントを少なくすることで、ユーザが入手希望カードを入手するのに要するゲームの実行時間を長くすることもできる。

（８−４）変形例４
本変形例に係るゲーム制御装置の機能ブロック図を、図２７に示す。図２７に示すように、本変形例では、図１６の機能ブロック図と比較して、第１制限手段６１が追加された点で異なる。
第１制限手段６１は、入手希望カードが登録されている場合、ユーザが他のカードを入手する機会を制限する機能を備える。第１制限手段６１の機能は、例えば以下のとおり実現される。
クエスト処理や対戦処理等のゲームの実行において、所定の確率でユーザにカードを入手する機会を付与する場合において、ＣＰＵ２１がユーザに登録カードがあるか否かを判定する。そして、登録カードがあると判定した場合は、ユーザにカードを入手する機会を付与する確率をゼロ、又は、登録カードがない場合よりも低い確率とする。

図２８は、本変形例のゲームにおいてクエスト処理を行うときのフローチャートである。なお、図１７のフローチャートと同様のステップについては、説明を一部割愛する。
先ず図２８のフローチャートにおいて、トップページＰ１上でメニューｍ１（「クエスト」）が選択されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図９のＰ２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）が選択されたことを認識すると（ステップＳ８００：ＹＥＳ）、ＣＰＵ２１は、ユーザデータベースにアクセスしてユーザ：Ａの達成率、体力ポイント、経験値等を更新する（ステップＳ８０２）。次に、ＣＰＵ２１は、ユーザ：Ａに登録カードがあるか否かを判定する（ステップＳ８０４）。
次に、ＣＰＵ２１は、複数のモンスターカードの中から選択されたモンスターカードをユーザ：Ａに付与するか否か、購入ポイントをユーザ：Ａに付与するか否か、あるいは、購入処理に移行する機会を与えるか否かについて、所定の、あるいはランダムな確率で決定する（ステップＳ８０６）。ここで、ステップＳ８０４において、ユーザ：Ａに登録カードがあると判定された場合、ＣＰＵ２１は、購入処理に移行する機会をユーザに付与する確率を例えばゼロとする。すなわち、ユーザ：Ａに登録カードがある場合、ＣＰＵ２１は、ユーザ：Ａに購入処理においてカードを入手する機会を与えない。

ステップＳ８０６において、モンスターカードをユーザ：Ａに付与することを決定すると（ステップＳ８０６：カード付与）、ＣＰＵ２１は、ユーザ：Ａにモンスターカードを対応付ける付与する処理を行い（ステップＳ８０８）、クエスト処理を終了する。

ステップＳ８０６において、購入ポイントをユーザ：Ａに付与することを決定すると（ステップＳ８０６：ポイント付与）、ＣＰＵ２１は、購入ポイントをユーザ：Ａに付与する処理を行う（ステップＳ８１０）。その後、ユーザ：Ａに登録カードがないと判定した場合（ステップＳ８１２：ＮＯ）、ＣＰＵ２１は、クエスト処理を終了する。
一方、ユーザ：Ａに登録カードがあると判定した場合（ステップＳ８１２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが、ユーザ：Ａの登録カードの入手対価以上であるか否かを判定する（ステップＳ８１４）。
購入ポイントが入手対価以上であると判定した場合（ステップＳ８１４：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａが登録カードの受取操作を行ったか否かを判定する（ステップＳ８１６）。ユーザ：Ａが登録カードの受取操作を行わない場合（ステップＳ８１６：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
ユーザ：Ａが登録カードの受取操作を行った場合（ステップＳ８１６：ＹＥＳ）、ＣＰＵ２１は、登録カードをユーザ：Ａに付与し（ステップＳ８１８）、クエスト処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ８１４：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録取消操作をしたか否かを判定する（ステップＳ８２０）。ユーザ：Ａが登録取消操作をしない場合（ステップＳ８２０：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
ユーザ：Ａが登録取消操作をした場合（ステップＳ８２０：ＹＥＳ）、ＣＰＵ２１は、登録解除処理を行い（ステップＳ８２２）、クエスト処理を終了する。

ステップＳ８０６において、購入処理に移行する機会をユーザ：Ａに付与することを決定した場合（ステップＳ８０６：購入機会付与）、ＣＰＵ２１は、ウェブページＰ７においてメニューｍ１１が選択されたか否かを判定する（ステップＳ８２４）。なお、ステップＳ８０４において、ユーザ：Ａに登録カードがあると判定された場合、購入処理に移行することはない。
メニューｍ１１以外が選択された場合や、メニューｍ１１が選択されずに所定時間経過した場合（ステップＳ８２４：ＮＯ）、ＣＰＵ２１はクエスト処理を終了する。
メニューｍ１１が選択された場合（ステップＳ８２４：ＹＥＳ）、ＣＰＵ２１は購入処理を行い（ステップＳ８２６）、クエスト処理を終了する。
なお、ＣＰＵ２１は、ウェブページＰ３、Ｐ４、Ｐ７においてメニューｍ１０が選択された場合、ステップＳ６００から再びクエスト処理を開始する。また、メニューｍ１０が選択されずに所定時間経過した場合や、メニューｍ１０以外が選択された場合（ステップＳ６００：ＮＯ）、クエスト処理を終了してもよい。

本変形例においては、入手希望カードが登録されている場合、ユーザに他のカードを入手する機会を付与しないため、ユーザが無計画にカードを登録することを回避することができる。

（８−５）変形例５
本変形例に係るゲーム制御装置の機能ブロック図を、図２９に示す。図２９に示すように、本変形例では、図１６の機能ブロック図と比較して、第２制限手段６２が追加された点で異なる。
第２制限手段６２は、ユーザが前記入手希望カードを入手可能と判定されるまで、前記ユーザによる他のカードの入手のためのポイントの使用を制限する機能を備える。第２制限手段６２の機能は、例えば以下のとおり実現される。
ユーザにカードを入手する機会が付与されたとき、ＣＰＵ２１は、ユーザに登録カードがあるか否かを判定する。そして、登録カードがある場合、ＣＰＵ２１は、ユーザによるカードの入手のためのポイントの使用を制限する。例えば、ユーザに登録カードがある場合、ＣＰＵ２１は、ユーザによる入手希望カードの選択を制限することで、ユーザによるカードの入手のためのポイントの使用を制限してもよい。

図３０は、本変形例のゲームにおいて購入処理を行うときのフローチャートである。なお、図１９のフローチャートと同様のステップについては、説明を一部割愛する。
ＣＰＵ２１は、ウェブページＰ７でメニューｍ１１（「立ち寄る」）が選択されたことを認識すると、ユーザ：Ａが選択可能な複数のカード（出品カード）を決定する（ステップＳ９００）。
次に、ＣＰＵ２１は、ユーザ：Ａに登録カードがあるか否かを判定する（ステップＳ９０２）。ユーザ：Ａに登録カードがあると判定した場合（ステップＳ９０２：ＹＥＳ）、ＣＰＵ２１は、出品カードの選択ができないことをユーザ：Ａに通知し（ステップＳ９０４）、購入処理を終了する。例えば、ＣＰＵ２１は、ウェブページＰ８におけるメニューｍ１２、ｍ１３の代わりに、出品カードを選択できないことを示すテキスト（「入手できません」等）を含むウェブページ（出品カードの選択を制限するウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信することで、ユーザ：Ａが出品カードの選択ができないことを通知してもよい。なお、図示しないが、出品カードの選択ができないことを通知するウェブページは、登録取消操作を行うためのウェブページへのショートカットメニューを含んでいてもよい。

ユーザ：Ａに登録カードがない場合（ステップＳ９０２：ＮＯ）、ＣＰＵ２１は、ウェブページＰ８においてユーザ：Ａがいずれかの出品カードを選択したか否かを判定する（ステップＳ９０６）。ユーザ：Ａがいずれの出品カードも選択しない場合（ステップＳ９０６：ＮＯ）、ＣＰＵ２１は、購入処理を終了する。
ユーザ：Ａがいずれかの出品カードを選択した場合（ステップＳ９０６：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａの購入ポイントが選択カードの入手対価以上であるか否かを判定する（ステップＳ９０８）。購入ポイントが入手対価以上であると判定した場合（ステップＳ９０８：ＹＥＳ）、ＣＰＵ２１は、選択カードをユーザ：Ａに付与し（ステップＳ９１０）、ＣＰＵ２１は購入処理を終了する。
購入ポイントが入手対価未満であると判定した場合（ステップＳ９０８：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａが登録操作をしたか否かを判定する（ステップＳ９１２）。ユーザ：Ａが登録操作をしない場合（ステップＳ９１２：ＮＯ）、ＣＰＵ２１は購入処理を終了する。
ユーザ：Ａが登録操作をした場合（ステップＳ９１２：ＹＥＳ）、ＣＰＵ２１は、登録処理を行い（ステップＳ９１４）、購入処理を終了する。

本変形例においては、ユーザが登録カードを入手可能と判定されるまで、ポイントを使用して他のカードを入手することができないため、ユーザが他のカードをさらに入手可能とするためにゲームを実行して購入ポイントを増加させる動機付けとなる。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。

本発明に係るゲーム制御装置は、ユーザが単独で使用するスタンドアローンのゲーム機であってもよいし、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよい。
上述した各実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、選択手段５２、判定手段５３、付与手段５４、登録手段５５、解除手段５６の各機能を実現する構成としたが、この構成に限られない。これらの少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記各実施形態に記載したようにして通信端末１０によっても一部の機能を実現できる。例えば、図３１（ａ），（ｂ）に、図１６に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。また、上述した各実施形態では、各種データ（例えば、モンスターカードデータベース、ユーザ毎の登録テーブルなど）をデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、その一部を通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…実行手段
５２…選択手段
５３…判定手段
５４…付与手段
５５…登録手段
５６…解除手段
５７…受付手段
５８…延長手段
５９…入手対価変動手段
６０…ポイント付与手段
６１…第１制限手段
６２…第２制限手段

Claims (13)

1. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
   選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
   前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
   前記入手希望オブジェクトが登録された後、前記ユーザが前記入手希望オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記入手希望オブジェクトを付与する付与手段、
   前記入手対価に相当するポイントと前記ユーザがゲーム上で保有するポイントとの差である不足ポイントを示す画像を表示するための情報を前記ユーザに提供する提供手段、
   を備えたゲーム制御装置。
2. 前記提供手段によって提供された情報に基づく画像に対して入力された前記ユーザの入力情報に基づいて、前記入手希望オブジェクトの登録を解除する解除手段をさらに備えた、請求項１に記載されたゲーム制御装置。
3. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
   選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
   前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段、
   前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
   前記入手希望オブジェクトが登録されている場合、前記ユーザが他のオブジェクトを入手する機会を制限する第１制限手段、
   を備えたゲーム制御装置。
4. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
   選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
   前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段、
   前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
   前記ユーザが前記入手希望オブジェクトを入手可能と判定されるまで、前記ユーザによる他のオブジェクトの入手のためのポイントの使用を制限する第２制限手段、
   を備えたゲーム制御装置。
5. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
   選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
   前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段、
   前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
   前記入手希望オブジェクトが登録されてから所定期間の経過後、前記入手希望オブジェクトの登録を解除する解除手段、
   を備えたゲーム制御装置。
6. 前記所定期間は、前記入手希望オブジェクトの入手対価に応じた長さの時間である、請求項５に記載のゲーム制御装置。
7. 前記入手希望オブジェクトの入手対価と前記ユーザの保有ポイントとの差額が減少したとき、前記所定期間を延長する延長手段を備える、請求項５または６に記載のゲーム制御装置。
8. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
   選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
   前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段、
   前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
   前記入手希望オブジェクトが登録された時からの時間に応じて、前記入手希望オブジェクトの入手対価を変動させる入手対価変動手段、
   を備えたゲーム制御装置。
9. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
   選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
   前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段、
   前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
   前記入手希望オブジェクトが登録されている場合、前記ゲームの実行に応じてユーザに付与するポイントを変動させるポイント付与手段、
   を備えたゲーム制御装置。
10. オブジェクトを入手する機会がユーザに付与されたとき、ユーザの入力情報に基づいてユーザが入手を希望するオブジェクトの選択を受け付ける選択手段、
    選択されたオブジェクトの入手対価と、前記ユーザがゲーム上で保有するポイントとを比較して、前記ユーザが前記オブジェクトを入手可能か否かを判定する判定手段、
    前記ユーザが前記オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記ユーザに前記オブジェクトを付与する付与手段、
    前記ユーザが前記オブジェクトを入手不能と判定された場合に、前記オブジェクトを前記ユーザの入手希望オブジェクトとして登録する登録手段、
    前記入手希望オブジェクトが登録されてから所定期間の経過後、前記入手希望オブジェクトの登録を解除する解除手段、
    前記入手希望オブジェクトが登録されている場合、前記ユーザが他のオブジェクトを入手する機会を制限する第１制限手段、
    を備える、ゲーム制御装置。
11. 前記付与手段は、前記入手希望オブジェクトが登録された後、前記ユーザが前記入手希望オブジェクトを入手可能と判定された場合に、前記入手対価に相当するポイントと引き換えに前記入手希望オブジェクトを前記ユーザに付与する、請求項１〜１０のいずれかに記載のゲーム制御装置。
12. コンピュータを、請求項１〜１１のいずれかに記載のゲーム制御装置の各手段として機能させるためのプログラム。
13. 複数のユーザの通信端末と、当該通信端末からアクセスされるサーバとを含む、ゲームシステムであって、
    請求項１〜１１のいずれかに記載のゲーム制御装置の各手段を、前記通信端末または前記サーバのいずれか一方が備えた、ゲームシステム。

Images