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

Description

本発明は、ユーザによるゲームの実行を制御する技術に関する。

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

上述したソーシャルゲームの一例として、非特許文献１に開示されているデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。この公知のデジタルカードゲームは、ユーザが様々なエリアを探索して新たなカードやアイテムを取得するクエスト処理を行うメニューが設けられている。このようなソーシャルゲームは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。
また、従来のソーシャルゲームでは、特定のアイテムを所定数取得することにより、ゲームを進行させ、あるいは所定の特典が得られるものも知られている。このゲームでは、他のユーザが保有する特定のアイテムを、当該他のユーザとの対戦に勝利することで獲得することができるようになっている。

アプリＳＴＹＬＥ Vol.2（株式会社イースト・プレス）、26-27頁

従来のソーシャルゲームでは、それぞれのユーザの保有する特定のアイテムをユーザ間の対戦によって奪い合う仕組みとなっているため、他のユーザと特定のアイテムを奪い合うことに抵抗を覚えるユーザや初心者のユーザなどは、特定のアイテムを所定数取得することが困難になる。このため、あらゆるユーザが、ゲームを進行させ、あるいは所定の特典を得ることができないことから、ゲームの興趣性が感じられないものとなっていた。また、従来のソーシャルゲームでは、ユーザの保有する特定のアイテムが奪われることを防ぐアイテムが存在するが、このアイテムを設定するためには煩雑かつ手間のかかる操作が必要であった。

本発明は上述した観点に鑑みてなされたもので、保有するアイテムが奪われることを容易に防止できるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付ける対応付け手段と、
第１のユーザによるゲーム上の対戦を実行する対戦実行手段と、
前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除する解除手段と、
前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限する制限手段と、
を備える。

ここで、「対応付ける」とは、例えば、ユーザ識別情報とアイテムに関する情報（例えば、アイテムの識別情報、パラメータ、個数など）とを連結する（リンクする）ことであってもよいし、ユーザ識別情報に対応付けられたアイテム用のデータファイルに対してアイテムに関する情報を記憶することであってもよいし、ユーザ識別情報に対応付けられたアイテムの個数を増加させることであってもよい。また、ユーザ識別情報及び／又はアイテムに関する情報は、外部の記憶装置に記憶されてもよい。さらに、ユーザ識別情報とアイテムに関する情報とを連結する情報（リンク情報）は、外部の記憶装置に記憶されてもよい。
また、「対応付けを解除する」とは、例えば、アイテムの識別情報とアイテムに関する情報（例えば、アイテムの識別情報、パラメータ、個数など）との連結（リンク）を断つことであってもよいし、アイテムの識別情報に対応付けられたアイテム用のデータファイルからアイテムに関する情報を消去することであってもよいし、アイテムの識別情報に対応付けられたアイテムの個数を減少させることであってもよい。また、ユーザ識別情報及び／又はアイテムに関する情報が外部の記憶装置に記憶されている場合には、ユーザ識別情報及び／又はアイテムに関する情報を当該記憶装置から消去することであってもよい。さらに、ユーザ識別情報とアイテムに関する情報とを連結する情報（リンク情報）が外部の記憶装置に記憶されている場合には、当該情報を当該記憶装置から消去することであってもよい。
さらに、「所定の条件」とは、例えば、所定の操作入力に関する情報が得られたときであってもよい。

このゲーム制御装置では、所定の条件を満たした場合には、所定期間の間、対戦の実行に基づいて第１のユーザのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが解除されない（第１のユーザの保有するアイテムが奪われない）。これにより、例えば、第１のユーザが他のユーザとの対戦に敗北した場合であっても、第１のユーザの保有するアイテムが奪われることを防ぐことができる。この場合、第１のユーザは、所定期間の間にアイテムを所定数取得することにより、ゲームを進行させ、あるいは所定の特典を得ることができる。したがって、あらゆるユーザが、ゲームを進行させ、あるいは所定の特典を得ることができるので、ゲームの興趣性を感じられるようになる。
また、所定の条件を満たした場合に第１のユーザの保有するアイテムが奪われないようにすることができるので、煩雑かつ手間のかかる操作が不要となる。したがって、アイテムが奪われることを容易に防ぐことができる。

上記ゲーム制御装置において、前記対戦実行手段は、ユーザが対戦相手となる他のユーザを選択することにより前記対戦を実行し、前記制限手段は、前記所定の条件を満たしたときに、前記第１のユーザが対戦相手として選択されることを所定期間制限してもよい。
このゲーム制御装置によれば、所定の条件を満たした場合、第１のユーザは、所定期間の間、対戦相手として選択されない。つまり、所定期間の間には、第１のユーザによる対戦が実行されないので、対戦の結果に基づいて、第１のユーザのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが解除されない。これにより、第１のユーザは、所定期間の間に、対戦に関わることなくアイテムを所定数取得することにより、ゲームを進行させ、あるいは所定の特典を得ることができる。これにより、ゲームの興趣性をさらに感じられるようになる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記制限手段は、前記第１のユーザに関係付けられたユーザ数が多いほど、前記所定期間を長くしてもよい。
このゲーム制御装置によれば、第１のユーザには、第１のユーザのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが対戦の結果に基づき解除されることを制限するというメリットが得られる期間をより長くするために、他のユーザと関係付けられる（仲間になる）ことが動機付けられる。このため、ゲームのコミュニティの活性化を図ることができ、ソーシャル性を高めることができる。

上記ゲーム制御装置において、前記制限手段は、前記第１のユーザに関係付けられたユーザのうち、前記所定の条件を満たした時点でログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が多いほど、前記所定期間を長くしてもよい。
このゲーム制御装置によれば、第１のユーザには、第１のユーザのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが対戦の結果に基づき解除されることを制限するというメリットが得られる期間をより長くするために、仲間のユーザと同時にログインすることが動機付けられる。このため、仲間のユーザとさらに関係性が高くなるような仕組みとすることができる。また、このような仕組みとすることで、ゲーム全体のアクセス数の向上に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。

上記ゲーム制御装置において、前記制限手段は、所定の操作入力に関する情報を取得した場合に、前記所定の条件を満たしたと判別してもよい。ここで、「所定の操作入力に関する情報」とは、ゲーム制御装置に対して直接操作入力されることにより得られる情報に限られず、例えば、ゲーム制御装置にアクセス可能な外部装置に対して操作入力されることにより得られる情報であってもよい。
このゲーム制御装置によれば、例えば、第１のユーザが所定の操作入力を行った場合に、第１のユーザは、第１のユーザのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが解除されることを所定期間制限することができるというメリットが得られる。つまり、第１のユーザは、所定の操作入力を行うことにより、メリットが得られる期間の開始タイミングを自ら設定することができる。これにより、第１のユーザにとって最適なタイミングでメリットが得られる仕組みとすることができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記制限手段は、前記第１のユーザに関係付けられたユーザのうち、ログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が所定値以上の場合に、前記所定の条件を満たしたと判別してもよい。
このゲーム制御装置によれば、第１のユーザに関係付けられたユーザ（仲間のユーザ）のうち、ログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が所定値以上の場合に、第１のユーザは、第１のユーザのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが解除されることを所定期間制限することができるというメリットが得られる。つまり、第１のユーザは、仲間のユーザと同時にログインすることにより、上記のメリットを自動的に享受することができる。これにより、第１のユーザは、仲間のユーザと同時にログインすることが動機付けられる。このため、仲間のユーザとさらに関係性が高くなるような仕組みとすることができる。また、このような仕組みとすることで、ゲーム全体のアクセス数の向上に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。

本発明の第２の観点は、ゲーム制御装置におけるゲーム制御方法であって、
ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付けるステップと、
第１のユーザによるゲーム上の対戦を実行するステップと、
前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除するステップと、
前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限するステップと、
を備える。

本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付ける機能、
第１のユーザによるゲーム上の対戦を実行する機能、
前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除する機能、及び
前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限する機能、
を実現させるためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付ける対応付け手段、
第１のユーザによるゲーム上の対戦を実行する対戦実行手段、
前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除する解除手段、
前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限する制限手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムよれば、保有するアイテムが奪われることを容易に防止することができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 バリア使用データのデータ構成例を示す図。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 ログデータのデータ構成例を示す図。 実現される機能の分担方法の変形例を示す図。

以下、本発明の実施形態について説明する。

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

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

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

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

ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

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

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

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

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

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

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

例えば、ＣＰＵ２１は、無線通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

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

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、本実施形態のゲームの一例として、女性戦士カードを用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、以下の処理を含む。
・クエスト処理：
自らのチームを作り上げていくためにゲーム上で設定されているエリアを探索して女性戦士カード（以下、単に「戦士カード」という。）を得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費する。なお、クエスト処理では、エリア探索中に宝石を取得することができる。
・バトル処理：
他のユーザのチームとバトルを行う処理である。このゲームでは、バトル処理を実行することで一定量の攻撃ポイント（後述する）を消費する。また、バトルに勝利した場合には、バトルの相手（対戦相手）となった他のユーザが保有する宝石を獲得することができる。
・バリア処理：
ユーザの保有する宝石が他のユーザに獲られることを所定期間防ぐための処理である。このゲームでは、バリア処理を実行するためには、所定数のバリアカードが必要となる。
上述したように、このゲームでは、クエスト処理、バトル処理の各処理の実行に伴ってゲーム上のポイントが消費される。
なお、本実施形態のゲームにおいて、アイテムは、ユーザがゲーム上で保有することができるオブジェクト（例えば、戦士カード）、ユーザがゲーム上で収集することが必要なオブジェクト（例えば、宝石）、ユーザがゲーム上で有利な効果を得られるオブジェクト（例えば、バリアカード）などを含む。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。例えば、クエスト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・体力ポイント
本実施形態のゲームにおいて、クエスト処理を実行する上で必要となるポイントである。体力ポイントは、クエスト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・攻撃ポイント
本実施形態のゲームにおいて、バトル処理を実行する上で必要となるポイントである。攻撃ポイントは、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復（増加）する値である。
・戦士数
ユーザが保有する戦士カードの数である。戦士数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
ユーザＩＤと関係付けられた他のユーザ（仲間のユーザ）のユーザＩＤのデータである。
・保有カードのパラメータ
ユーザが保有する戦士カードごとに、例えば、戦士カードの画像や、戦士カードの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）等が含まれる。
・宝石数
ユーザが保有する宝石の数である。本実施形態のゲームでは、ユーザが所定数（本実施形態の例では６つ）の宝石を獲得すると、当該ユーザに対して所定の特典が付与される。なお、所定数の宝石を獲得した場合には、例えば先のステージに進めるなどのように、ゲームを進行させるようにしてもよい。宝石数は、クエスト処理において宝石を獲得したり、バトル処理において他のユーザとのバトルに勝利することで増加し、ユーザが他のユーザとのバトルに敗北することにより減少する。なお、宝石数は、前記所定数に達すると０に初期化される。
・バリアカード数
ユーザが保有するバリアカードの数である。バリアカードは、ユーザの保有する宝石が他のユーザに獲られることを所定期間防ぐためのアイテムである。バリアカード数は、ユーザに対して定期的（例えば１日に１回）に所定数（例えば１枚）付与されることで増加し、バリア処理においてバリアカードを使用することで減少する。また、バリアカード数は、ユーザがバトルで所定回数（例えば５回）敗北するごとに、当該ユーザに対して所定数（例えば１枚）付与されることにより増加してもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、クエスト処理の進行状況を示す情報や、他のユーザとのバトル結果についての情報などを含む。

（５）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した女性戦士カードを用いたデジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図７を参照して説明する。図７は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図７の機能ブロック図において、対応付け手段５３、対戦実行手段５４、解除手段５５及び制限手段５６が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。
また、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。
なお、登録手段５１は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。

登録手段５１の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作、テキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えば、端末識別情報、ＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、所定のデフォルトのデータが記述された新規のユーザＩＤについてのユーザデータを、ユーザデータベース３１に格納する。

登録手段５１は、ユーザ同士を関係付ける機能を備えてもよい。具体的には、登録手段５１は、ユーザＩＤに基づく申請を契機として当該ユーザＩＤを他のユーザＩＤと関係付けて登録してもよい。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤを「仲間」として登録する。なお、以下の説明では、ユーザＩＤが仲間の関係にあることと、対応するユーザが仲間の関係にあることとは、同義である。ここで、登録手段５１は、本発明の「関係付け手段」の一例である。
この場合の登録手段５１は例えば、以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応する表示名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータにアクセスして、「仲間」の箇所（図６参照）にデータを書き込む。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られず、同一のゲーム上のステージを実行するユーザやバトルを行ったユーザを、ユーザとゲーム内で関係付けられたユーザ、つまり仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。

ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる。
また、ゲーム進行手段５２は、図８に示したように、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる機能を備える。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。

ゲーム進行手段５２によって通信端末１０に表示されるゲームのトップページの例を図８に示す。図８に示すトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８に例示されるトップページは、ユーザデータ表示領域、戦士画像表示領域、メニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル（レベル）、体力ポイント、攻撃ポイント、戦士数、仲間の数（仲間のユーザＩＤの数）、バリアカード数の各項目のデータ（図６参照）が表示される領域である。なお、図７において、戦士数の一例として「４０／６０」と表記されているが、これは、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。メニュー表示領域には、本実施形態のゲームに設けられる処理（クエスト処理、バトル処理、バリア処理）に対応したメニューとして、それぞれ「クエスト」、「バトル」、「バリア」と表記されたメニューｍ１，ｍ２，ｍ３が含まれる。
また、メニュー表示領域には、それぞれ宝石の形状を有する所定数（図７の例では６つ）のアイコンを表示するための表示領域１００が含まれてもよい。表示領域１００に含まれる各アイコンは、対象となるユーザＩＤのユーザデータに含まれる宝石数を表す（図７の例では４つ）ように構成されている。例えば、各アイコンは、宝石数に応じて、アイコンを形成する線の形状が変化（図７の例では破線から実線）するように構成されてもよいし、アイコンの形状や色彩などが変化するように構成されてもよい。これにより、ユーザは、宝石数が所定数に達するまでに取得すべき宝石数を容易に視認することができる。なお、宝石数は、ユーザデータ表示領域において、数値を用いて表示されてもよい。

例えば図８に示すトップページをユーザの通信端末１０に表示する場合、ゲーム進行手段５２の機能は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、戦士画像表示領域に表示すべき戦士カードの画像データを読み出す。次にＣＰＵ２１は、図８に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。
ＣＰＵ２１は、通信端末１０に表示されたメニューｍ１、ｍ２又はｍ３に対するユーザの選択操作に応じた処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。

ゲーム進行手段５２は、クエスト処理を実行する機能を備える。
［クエスト処理］
クエスト処理は、自らのチームを作り上げていくためにゲーム上で設定されているエリアを探索して戦士カードを得る処理である。
クエスト処理において、ゲーム進行手段５２は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図８のトップページ上でメニューｍ１が選択操作されると、図９のステップＳ１に示すウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ステップＳ１に示すウェブページには、探索の対象となるエリア（図９の例では、エリア１）の進行度合いを示す探索率のゲージ、探索処理を実行するための「探索する」と表記されたメニューｍ１０などが含まれる。
クエスト処理において、ユーザは、メニューｍ１０を選択操作する。この操作を契機として、探索の対象となるエリアについての探索が行われる。このとき、メニューｍ１０が選択操作されて探索が行われる度に、「探索率」（％）の値がランダムな増加量で増加する。上述したように、このゲームでは、１回の探索につき、所定量（例えば５ポイント）の体力ポイントが減少するように構成されている。探索が行われる（メニューｍ１０が選択操作される）度に、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する。また、ＣＰＵ２１は、探索が行われる度に、増加した探索率を含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。なお、ステップＳ１に示すウェブページは、１回の探索に要する体力ポイントの値が表示されるように構成されてもよい。

クエスト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、クエスト用に予め設けられた複数の戦士カードの中から抽選により選ばれた戦士カードをユーザに付与する（対応付ける）ことを、所定の、あるいはランダムな確率で決定する。また、ＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、所定の、あるいはランダムな確率で、ユーザに対して宝石を付与する（対応付ける）ことを決定する。さらに、ＣＰＵ２１は、戦士カード又は宝石を付与することを決定した場合、戦士カード又は宝石を獲得したことを表す情報を表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図９においてエリアの探索率が１００％に達すると、エリア９についての探索は終了し、探索対象は次のエリア（この場合、エリア１０）に移る。

クエスト処理では、探索対象となるエリアごとに、１回の探索処理に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索処理で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。
クエスト処理では、メニューｍ１０に対する選択操作を行う度に体力ポイントが減少していくため、クエスト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される体力ポイントがスカウトパートの実行前よりも減少されて表示されることになる。なお、体力ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）する。

対戦実行手段５４は、第１のユーザによるゲーム上のバトル（対戦）を実行する機能を備える。ここで、バトルの相手（対戦相手）は、他のユーザのチームであってもよいし、ＣＰＵ２１が任意に抽出した複数あるいは単一の戦士カードからなるチームであってもよい。なお、以下の説明では、「ユーザ間のバトル」と、ユーザが保有する戦士カード間での対戦を意味する「戦士カード間のバトル」とは同義である。
対戦実行手段５４は、バトル処理を実行する。

［バトル処理］
バトル処理は、ユーザが他のユーザのチームとバトルを行う処理である。本実施形態のゲームでは、ユーザがバトルに勝利した場合には、バトルの相手（対戦相手）となった他のユーザが保有する宝石を獲得することができる。
バトルを行う戦士カードは、ユーザが保有する戦士カードの中から自動的に選択されるか、ユーザの選択操作によって選択されてもよい。本実施形態のゲームでは、バトル処理を実行するには攻撃ポイントを必要とする。つまり、バトル処理の実行によって、ユーザＩＤに対応する攻撃ポイントの値が変化しうる。１回のバトルで必要となる（消費する）攻撃ポイントは、バトルを行う戦士カードによって定まる。例えば、各戦士カードに対して１回のバトルで必要となるコストが予め割り当てられており、そのコストの分だけ攻撃ポイントが消費される。攻撃ポイントは、例えば所定時間（例えば1分）が経過する度に１ポイントずつ回復（増加）する。

対戦実行手段５４の機能は、図１０を参照すると、例えば以下のとおり実現される。図１０は、バトル処理においてユーザの通信端末１０に表示される一連のウェブページを例示する図である。図１０では、バトル処理を実行するユーザが「ＸＹＺ」（以下、ユーザ：ＸＹＺと表記する。）であって、ユーザ：ＸＹＺの対戦相手となるユーザが「ＡＢＣ」（以下、ユーザ：ＡＢＣと表記する。）である場合を一例として説明する。

先ず、ユーザ：ＸＹＺの通信端末１０のトップページ上でメニューｍ２（図８参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＸＹＺの対戦相手の複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに決定する。このとき、ＣＰＵ２１は、ゲームデータベース３２にアクセスし、ゲームデータベース３２内のバリア使用データ（図１２に示す）に記録されたユーザＩＤを対戦相手の候補から除外する。なお、バリア使用データの詳細については後述する。また、対戦相手の候補の技能レベルは、メニューｍ２を選択操作したユーザ：ＸＹＺと同一の技能レベルであることが好ましい。さらに、対戦相手の候補は、ユーザＩＤに対応する宝石数が所定数に近い（本実施形態の例では、４つあるいは５つ）ユーザの中から決定されてもよい。

ここで、対戦実行手段５４は、ユーザ：ＸＹＺがバトルの相手（対戦相手）となる他のユーザを選択することによりバトルを実行する機能を備えてもよい。この場合、対戦実行手段５４の機能は、以下のとおり実現される。ＣＰＵ２１は、複数の対戦相手の候補を抽出すると、図１０のステップＳ２に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＸＹＺの通信端末１０宛に送信する。ステップＳ２のウェブページは、複数の対戦相手の候補のリストからいずれかの候補を対戦相手として選択可能に構成されている。複数の対戦相手の候補のリストからいずれかの候補（ここでは、ユーザ：ＡＢＣ）を選択する操作がユーザ：ＸＹＺによってなされると、ＣＰＵ２１は、図１０のステップＳ３に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＸＹＺの通信端末１０宛に送信する。ステップＳ３に示すウェブページには、対戦相手（ユーザ：ＡＢＣ）ととともにバトル開始の指示を促すメニューｍ１１などが含まれる。
なお、対戦実行手段５４は、例えばランダムあるいは所定の規則性に基づいて、対戦相手を決定してもよい。この場合、ＣＰＵ２１は、バリア使用データに記録されたユーザＩＤを除く一つのユーザＩＤを、ランダムあるいは所定の規則性に基づいて抽出し、抽出したユーザＩＤに対応するユーザを対戦相手として決定してもよい。

ここで、ユーザ：ＸＹＺがメニューｍ１１を選択すると、ＣＰＵ２１は対戦結果を決定する処理を行う。対戦結果を決定するに当たって、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、ユーザ：ＸＹＺのユーザＩＤに対応する攻撃ポイントがバトルの実行に必要とする所定量以上である場合に、攻撃ポイントからその所定量を減少させるとともに、ユーザ：ＸＹＺ及びユーザ：ＡＢＣの各々のユーザＩＤに対応付けられた複数の戦士カードの能力を示すパラメータを読み出す。そして、ＣＰＵ２１は、読み出したパラメータに基づいてユーザ間のバトルの結果を決定する。

バトルの結果の決定方法は、戦士カードのパラメータがその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦を行う２人のユーザが保有する複数の戦士カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、パラメータの合計値の差が大きいほど高い確率としてもよい。このとき、能力値を示すパラメータの項目が複数存在する場合には、各戦士カードのパラメータを代表する値として、各項目のパラメータの値に対して所定の重み付け（例えば、本実施形態のゲームの例では、「攻撃力」を０．４、「防御力」を０．２の重み付けにする等）をもって総合的な能力値を設定してもよい。また、バトルの結果は、戦士カードのパラメータに関係なく、所定の、あるいはランダムな確率で決定されてもよいし、所定の規則性に基づいて決定されてもよい。

対応付け手段５３は、ユーザのユーザＩＤ（ユーザ識別情報）と、ゲーム上のアイテムとを対応付ける機能を備える。ここで、「対応付ける」とは、例えば、ユーザＩＤとアイテムに関する情報（例えば、アイテムの識別情報、パラメータ、個数など）とを連結する（リンクする）ことであってもよいし、ユーザＩＤに対応付けられたアイテム用のデータファイルに対してアイテムに関する情報を記憶することであってもよいし、ユーザＩＤに対応付けられたアイテムの個数を増加させることであってもよい。また、ユーザＩＤ及び／又はアイテムに関する情報は、外部の記憶装置に記憶されてもよい。さらに、ユーザＩＤとアイテムに関する情報とを連結する情報（リンク情報）は、外部の記憶装置に記憶されてもよい。
また、対応付け手段５３が、ユーザのユーザＩＤ（ユーザ識別情報）と、ゲーム上のアイテムとを対応付ける契機は、例えば、ユーザがクエスト処理において戦士カード又は宝石を抽選により得た（発掘した）ときや、ユーザがバトル処理において他のユーザに勝利することにより宝石を獲得したときや、バリアカードが定期的にユーザに付与されるときなどである。

対応付け手段５３の機能は例えば、以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザＩＤに対応するユーザがゲーム上で利用可能に保有するアイテム（本実施形態のゲームでは、例えば、戦士カード、宝石、バリアカードなど）に関する情報を、当該ユーザＩＤのユーザデータに記憶、増加又は更新する。
ここで、上述したクエスト処理において、ユーザに戦士カード又は宝石を抽選により得た場合について説明する。ＣＰＵ２１は、メニューｍ１０に対するユーザの選択操作に基づいて、戦士カードをユーザに付与することを決定した場合には、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータに対して、新たな戦士カードのデータを追加して、戦士数の値を１だけ増加させる。また、ＣＰＵ２１は、メニューｍ１０に対するユーザの選択操作に基づいて、宝石をユーザに付与することを決定した場合には、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータに対して、宝石数の値を１だけ増加させる。
また、上述したバトル処理において、ユーザが他のユーザに勝利することにより宝石を獲得した場合について説明する。ここでは、ユーザ：ＸＹＺが、ユーザ：ＡＢＣとのバトルに勝利した場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザ：ＸＹＺのユーザＩＤに対応する宝石数を所定数（本実施形態の例では２つ）増やす。そして、ＣＰＵ２１は、図１０のステップＳ４に示すウェブページを表示するためのＨＴＭＬデータを生成してユーザ：ＸＹＺの通信端末１０宛に送信する。
さらに、バリアカードが定期的にユーザに付与される場合について説明する。ＣＰＵ２１は、所定の時刻（例えば午前９時）になると、ユーザデータベース３１にアクセスし、全てのユーザＩＤのユーザデータに対して、バリアカードの数を１だけ増加させる。

また、対応付け手段５３は、ユーザが所定数の宝石を取得した場合に、当該ユーザのユーザＩＤと特典とを対応付ける（つまり、ユーザに対して特典を付与する）機能を備えてもよい。
ここで、「特典」とは、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。さらに、「アイテム」とは、例えば、体力ポイントや攻撃ポイントなどを回復する回復薬や、戦士カードの能力を上昇させる薬品、武器あるいは防具などであってもよい。さらに、「ゲーム上の有利な効果」とは、例えば、アイテムを使用せずに戦士カードの能力値を上昇させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、「ゲーム上の有利な効果」とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作に応じて消費するゲーム上の各種ポイント（体力ポイント、攻撃ポイント）の消費量を通常よりも低減させることであってもよいし、ユーザが上記の各種ポイントを入手できることであってもよい。さらに、「ゲーム上の有利な効果」とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよい。

この場合における対応付け手段５３の機能は、以下のようにして実現できる。なお、ユーザに対して付与する特典の内容については、予めＲＯＭ２２やＲＡＭ２３などに記録されているものとする。ゲームサーバ２０のＣＰＵ２１は、ユーザのユーザＩＤに対応する宝石数が所定数（本実施形態の例では６つ）に達したことを認識すると、当該ユーザに対して特典を付与する処理を行う。例えば、特典の一例として戦士カードをユーザに付与する場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける戦士数及び保有カードのデータを書き換える処理（戦士数を増加させるとともに、戦士カードの画像及びパラメータ等を追記する処理）を行ってよい。

解除手段５５は、バトル処理において、バトル（対戦）の結果に基づき、バトルに敗北したユーザ（第１のユーザ）のユーザＩＤ（ユーザ識別情報）と当該ユーザの保有するアイテムとの対応付けを解除する機能を備える。
ここで、「バトルの結果」は、勝利、敗北、引き分け、得点、失点あるいは得失点差など如何なる結果であってもよい。また、「対応付けを解除する」とは、例えば、ユーザＩＤとアイテムに関する情報（例えば、アイテムの識別情報、パラメータ、個数など）との連結（リンク）を断つことであってもよいし、ユーザＩＤに対応付けられたアイテム用のデータファイルからアイテムに関する情報を消去することであってもよいし、ユーザＩＤに対応付けられたアイテムの個数を減少させることであってもよい。また、ユーザＩＤ及び／又はアイテムに関する情報が外部の記憶装置に記憶されている場合には、ユーザＩＤ及び／又はアイテムに関する情報を当該記憶装置から消去することであってもよい。さらに、ユーザＩＤとアイテムに関する情報とを連結する情報（リンク情報）が外部の記憶装置に記憶されている場合には、当該情報を当該記憶装置から消去することであってもよい。
解除手段５５の機能は例えば、以下のように実現される。ここでは、ユーザ：ＡＢＣが、ユーザ：ＸＹＺとのバトルに敗北した場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２にアクセスし、ゲームデータベース３２内のバリア使用データを参照する。ＣＰＵ２１は、バリア使用データ内にユーザ：ＡＢＣのユーザＩＤが記録されていない場合には、ユーザデータベース３１にアクセスし、ユーザ：ＡＢＣのユーザＩＤに対応する宝石数を所定数（本実施形態の例では１つ）減らす。なお、ＣＰＵ２１は、バリア使用データ内にユーザ：ＡＢＣのユーザＩＤが記録されている場合には、ユーザ：ＡＢＣのユーザＩＤに対応する宝石数の値を減らさない。そして、ＣＰＵ２１は、図１０のステップＳ５に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＡＢＣの通信端末１０宛に送信する。
なお、バトルに勝利したユーザが獲得する宝石数は、バトルに敗北したユーザが失う宝石数と同一であってもよいし、異なっていてもよい。

制限手段５６は、ユーザ：ＡＢＣのユーザＩＤ（ユーザ識別情報）とユーザ：ＡＢＣの保有する宝石（アイテム）との対応付けがバトル（対戦）の結果に基づき解除されること（つまり、ユーザ：ＡＢＣの保有する宝石が獲られること）を、所定の条件を満たしたときに所定期間制限する機能を備える。ここで、「所定の条件」とは、例えば、所定の操作入力に関する情報が得られたときであってもよい。
制限手段５６は、バリア処理を実行する。

［バリア処理］
バリア処理は、自ら保有する宝石が他のユーザに獲られることを所定期間防ぐための処理である。
このゲームでは、バリア処理を実行するためには、所定数（例えば１枚）のバリアカードが必要となる。以下では、バリア処理を実行するユーザがユーザ：ＡＢＣ（第１のユーザ）である場合を一例として説明する。

なお、制限手段５６は、所定の条件を満たしたときに、ユーザ：ＡＢＣが対戦相手として選択されることを所定期間制限してもよい。例えば、所定の条件を満たした場合、ユーザ：ＡＢＣは、所定期間の間、対戦相手として選択されない。つまり、所定期間の間には、ユーザ：ＡＢＣによるバトルが実行されないので、対戦の結果に基づいて、ユーザ：ＡＢＣのユーザＩＤとユーザ：ＡＢＣの保有する宝石との対応付けが解除されない。これにより、ユーザ：ＡＢＣは、所定期間の間に、バトルに関わることなく宝石を所定数取得することにより、ゲームを進行させ、あるいは所定の特典を得ることができる。これにより、ゲームの興趣性をさらに感じられるようになる。

また、制限手段５６は、所定の操作入力に関する情報を取得した場合に、所定の条件を満たしたと判別してもよい。ここで、「所定の操作入力に関する情報」とは、ゲーム制御装置に対して直接操作入力されることにより得られる情報に限られず、例えば、ゲーム制御装置にアクセス可能な外部装置に対して操作入力されることにより得られる情報であってもよい。例えば、ユーザ：ＡＢＣが所定の操作入力を行った場合に、ユーザ：ＡＢＣは、ユーザ：ＡＢＣのユーザＩＤとユーザ：ＡＢＣの保有する宝石との対応付けが解除されることを所定期間制限することができるというメリットが得られる。つまり、ユーザ：ＡＢＣは、所定の操作入力を行うことにより、メリットが得られる期間の開始タイミングを自ら設定することができる。これにより、ユーザ：ＡＢＣにとって最適なタイミングでメリットが得られる仕組みとすることができる。

制限手段５６の機能は、以下のようにして実現できる。先ず、ユーザ：ＡＢＣの通信端末１０のトップページ上でメニューｍ３（図８参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、図１１のステップＳ６に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する。ステップＳ６に示すウェブページには、バリアカードの使用の指示を促すメニューｍ１２などが含まれる。ここで、ユーザ：ＡＢＣがメニューｍ１２を選択すると、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、ユーザ：ＡＢＣのユーザＩＤに対応するバリアカード数がバリア処理の実行に必要とする所定量（本実施形態の例では１枚）以上である場合に、バリアカード数からその所定量を減少させる。
そして、ＣＰＵ２１は、アイテム解除に対する制限処理を行う。具体的に説明すると、ＣＰＵ２１は、バリアカードを使用したユーザ（ユーザ：ＡＢＣ）のユーザＩＤと、使用時刻（メニューｍ１２が選択操作されたときの日時）と、効果時間とを、ゲームデータベース３２内のバリア使用データに記録する。図１２にバリア使用データの構成例を示す。図１２に示すように、バリア使用データは、バリアカードを使用したユーザ（ユーザＩＤ）ごとに、バリアカードの使用時刻及び効果時間などが記述されるデータである。ここで、効果時間は、任意に設定することができ、例えば、ユーザＩＤごとに一定の時間（図１２の例では３分）であってもよいし、ユーザＩＤごとに異なる時間であってもよい。また、効果時間は、本発明の「所定期間」の一例である。また、ＣＰＵ２１は、所定の間隔（例えば１分ごと）にバリア使用データを参照し、バリア使用データ内のレコード（ユーザＩＤ、使用時刻、効果時間など）のうち、使用時刻からの経過時間が効果時間を超えたレコードを消去する。

なお、ユーザ：ＡＢＣのユーザＩＤがバリア使用データに記録されている間、他のユーザ（例えば、ユーザ：ＸＹＺ）が自らの通信端末１０上でメニューｍ２（図８参照）の選択操作を行うと、ＣＰＵ２１は、図１１のステップＳ７に示すウェブページを表示するためのＨＴＭＬデータを生成してユーザ：ＸＹＺの通信端末１０宛に送信する。上述したように、バトル処理において対戦相手の候補を決定する際、ＣＰＵ２１は、ゲームデータベース３２にアクセスし、ゲームデータベース３２内のバリア使用データに記録されたユーザＩＤを対戦相手の候補から除外する。つまり、ユーザ：ＡＢＣのユーザＩＤがバリア使用データに記録されている間（バリアカードの使用時刻から効果時間が経過するまでの間）、ユーザ：ＡＢＣは対戦相手の候補に含まれない。このため、図１１のステップＳ７に示すウェブページには、ユーザ：ＡＢＣに関する情報が含まれない。この場合、ユーザ：ＡＢＣは対戦相手として選択されないので、ユーザ：ＡＢＣの保有する宝石が、バトルの実行によって他のユーザに獲られない。

なお、上述した例において、ユーザ：ＸＹＺが図１０のステップＳ２に示すウェブページ上でユーザ：ＡＢＣを選択してからバトルの結果が決定されるまでの間に、ユーザ：ＡＢＣが図１１のステップＳ６に示すウェブページ上でメニューｍ１２を選択操作することにより、バリアカードが使用される場合が考えられる。この場合には、ＣＰＵ２１は、バトルの結果を決定した後にバリア使用データを参照し、バリア使用データ内にユーザ：ＡＢＣのユーザＩＤが記録されている場合には、ユーザ：ＡＢＣのユーザＩＤに対応する宝石数の値を減らさない。一方、ＣＰＵ２１は、ユーザ：ＸＹＺのユーザＩＤに対応する宝石数を所定数（本実施形態の例では２つ）増やす。

（６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１３のフローチャートを参照して説明する。図１３のフローチャートは、対応付け手段５３、対戦実行手段５４及び解除手段５５がバトル処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。ここでは、バトル処理を実行するユーザがユーザ：ＸＹＺ、ユーザ：ＸＹＺの対戦相手となるユーザがユーザ：ＡＢＣである場合を一例として説明する。

先ず、ユーザ：ＸＹＺの通信端末１０上には、図８に示すトップページが表示されていることとする。トップページ上でメニューｍ２（図８参照）が選択操作されると（ステップＳ１００：ＹＥＳ）、ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＸＹＺの対戦相手の複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに決定する（ステップＳ１１０）。このとき、ＣＰＵ２１は、ゲームデータベース３２にアクセスし、ゲームデータベース３２内のバリア使用データ（図１２に示す）に記録されたユーザＩＤを対戦相手の候補から除外する。つまり、バリア使用データに記録されたユーザＩＤに対応するユーザ（バリアカードを使用してから効果時間を経過していないユーザ）は、対戦相手の候補に含まれないので、対戦相手として選択されない。このため、バリア使用データに記録されたユーザＩＤに対応する宝石数は、効果期間の間、バトルが実行されることによって減少しない。

ＣＰＵ２１は、複数の対戦相手の候補を抽出すると、図１０のステップＳ２に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ１２０）。ステップＳ２のウェブページは、複数の対戦相手の候補のリストからいずれかの候補を対戦相手として選択可能に構成されている。複数の対戦相手の候補のリストからいずれかの候補（ここでは、ユーザ：ＡＢＣ）を選択する操作がユーザ：ＸＹＺによってなされると（ステップＳ１３０：ＹＥＳ）、ＣＰＵ２１は、図１０のステップＳ３に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ１４０）。ステップＳ３に示すウェブページには、対戦相手（ユーザ：ＡＢＣ）ととともにバトル開始の指示を促すメニューｍ１１などが含まれる。
なお、ステップＳ１３０の処理において、対戦相手が選択されずに所定時間経過すると（ステップＳ１３０：ＮＯ）、ＣＰＵ２１は、ステップＳ１００の処理に移行する。

ユーザ：ＸＹＺがメニューｍ１１を選択すると（ステップＳ１５０：ＹＥＳ）、ＣＰＵ２１はバトルの結果（対戦結果）を決定する処理を行う（ステップＳ１６０）。対戦結果を決定するに当たって、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、ユーザ：ＸＹＺのユーザＩＤに対応する攻撃ポイントがバトルの実行に必要とする所定量以上である場合に、攻撃ポイントからその所定量を減少させるとともに、ユーザ：ＸＹＺ及びユーザ：ＡＢＣの各々のユーザＩＤに対応付けられた複数の戦士カードの能力を示すパラメータを読み出す。そして、ＣＰＵ２１は、読み出したパラメータに基づいてユーザ間のバトルの結果を決定する。以下では、ユーザ：ＸＹＺが、ユーザ：ＡＢＣとのバトルに勝利した場合を一例として説明する。
なお、ステップＳ１５０の処理において、メニューｍ１１が選択されずに所定時間経過すると（ステップＳ１５０：ＮＯ）、ＣＰＵ２１は、ステップＳ１００の処理に移行する。

ＣＰＵ２１は、バトルの結果を決定すると、バトルの結果に基づき、アイテムの対応付け処理及びアイテムの解除処理を行う（ステップＳ１７０）。先ず、アイテムの対応付け処理について説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザ：ＸＹＺのユーザＩＤに対応する宝石数を所定数（本実施形態の例では２つ）増やす。次に、アイテムの解除処理について説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザ：ＡＢＣのユーザＩＤに対応する宝石数を所定数（本実施形態の例では１つ）減らす。
そして、ＣＰＵ２１は、図１０のステップＳ４に示すウェブページを表示するためのＨＴＭＬデータを生成してユーザ：ＸＹＺの通信端末１０宛に送信する。また、ＣＰＵ２１は、図１０のステップＳ５に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ１８０）。

次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１４のフローチャートを参照して説明する。図１４のフローチャートは、主として制限手段５６によって実行される処理である。

先ず、ユーザ：ＡＢＣの通信端末１０のトップページ上でメニューｍ３（図８参照）の選択操作がなされ（ステップＳ２００：ＹＥＳ）、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、図１１のステップＳ６に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ２１０）。ステップＳ６に示すウェブページには、バリアカードの使用の指示を促すメニューｍ１２などが含まれる。ここで、ユーザ：ＡＢＣがメニューｍ１２を選択すると（ステップＳ２２０：ＹＥＳ）、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、ユーザ：ＡＢＣのユーザＩＤに対応するバリアカード数がバリア処理の実行に必要とする所定量（本実施形態の例では１枚）以上である場合に、バリアカード数からその所定量を減少させる。
そして、ＣＰＵ２１は、アイテム解除に対する制限処理を行う（ステップＳ２３０）。具体的に説明すると、ＣＰＵ２１は、バリアカードを使用したユーザ（ユーザ：ＡＢＣ）のユーザＩＤと、使用時刻（メニューｍ１２が選択操作されたときの日時）と、効果時間とを、ゲームデータベース３２内のバリア使用データに記録する。

上述したように、実施形態のゲーム制御装置によれば、所定の条件を満たした場合には、所定期間の間、バトルの実行に基づいてユーザ：ＡＢＣのユーザＩＤとユーザ：ＡＢＣの保有する宝石との対応付けが解除されない（つまり、ユーザ：ＡＢＣの保有する宝石が奪われない）。これにより、例えば、ユーザ：ＡＢＣがユーザ：ＸＹＺとのバトルに敗北した場合であっても、ユーザ：ＡＢＣの保有する宝石がユーザ：ＸＹＺに奪われることを防ぐことができる。この場合、ユーザ：ＡＢＣは、所定期間の間に宝石を所定数取得することにより、ゲームを進行させ、あるいは所定の特典を得ることができる。したがって、あらゆるユーザが、ゲームを進行させ、あるいは所定の特典を得ることができるので、ゲームの興趣性を感じられるようになる。
また、所定の条件を満たした場合にユーザ：ＡＢＣの保有する宝石が奪われないようにすることができるので、煩雑かつ手間のかかる操作が不要となる。したがって、宝石が奪われることを容易に防ぐことができる。

（７）変形例
（７−１）変形例１
上記実施形態において、ユーザ同士を関係付ける登録手段５１（関係付け手段）を備え、制限手段５６は、ユーザ（第１のユーザ）の仲間のユーザ（関係付けられたユーザ）数が多いほど、バリアの効果時間（所定期間）を長くしてもよい。
この場合、ユーザには、バリアの効果時間をより長くするために、他のユーザと仲間になる（関係付けられる）ことが動機付けられる。このため、ゲームのコミュニティの活性化を図ることができ、ソーシャル性を高めることができる。

本変形例における制限手段５６の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１４に示したフローのステップＳ２４０の処理において、ユーザデータベース３１にアクセスし、バリアカードを使用した（ステップＳ２３０においてメニューｍ１２の選択操作を行った）ユーザのユーザＩＤに対応する仲間のユーザＩＤの数を算出する。そして、ＣＰＵ２１は、仲間のユーザＩＤを１つ当たり１分としてバリアの効果時間をもとめ、バリア使用データに記憶すればよい。この場合、仲間のユーザ数が５名であればバリアの効果時間は５分となり、仲間のユーザ数が１０名であればバリアの効果時間は１０分となる。なお、バリアの効果時間は、仲間のユーザ数に応じて段階的に変動するように設定されてもよい。例えば、仲間のユーザ数が５名以下の場合には、バリアの効果時間を５分とし、仲間のユーザ数が６名以上１０名以下の場合には、バリアの効果時間を１０分としてもよい。また、バリアの効果時間は、所定の演算式等を用いて、仲間のユーザ数を当該演算式に当てはめることで求められてもよい。

（７−２）変形例２
上記実施形態において、制限手段５６は、ユーザ（第１のユーザ）の仲間のユーザ（関係付けられたユーザ）のうち、所定の条件を満たした時点でログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が多いほど、バリアの効果時間（所定期間）を長くしてもよい。
ここで、「ログイン」には、パスワードや個体識別番号等、認証に必要な情報を通信端末１０から送信してアクセスする場合や、ゲーム上の操作入力に関する情報を通信端末１０から送信してウェブページの更新を要求することによりアクセスする場合（例えばＨＴＴＰリクエストを送信する場合）などが含まれてもよい。
この場合、ユーザには、バリアの効果時間をより長くするために、仲間のユーザと同時にログインすることが動機付けられる。このため、仲間のユーザとさらに関係性が高くなるような仕組みとすることができる。また、このような仕組みとすることで、ゲーム全体のアクセス数の向上に寄与でき、この結果、ゲームのコミュニティの活性化を図ることができ、ソーシャル性を高めることができる。

本変形例において、制限手段５６は、ユーザのログインに関する情報を取得する機能を備えてもよい。この場合、制限手段５６の機能は以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザＩＤに基づく所定の情報を受信すると、ログインに関する情報をゲームデータベース３２内のログデータに記録する。図１５にログデータの構成例を示す。図１５に示すように、ログデータは、ユーザＩＤ、ログインの時刻の情報が、ログインがあった時刻の順に記述されたデータである。例えば、ＣＰＵ２１は、図８に示すトップページを表示するためのＨＴＭＬデータの送信要求を受信したときに、ユーザＩＤ及びアクセスの時刻の情報をログデータに記録してもよいし、図８に示すトップページを表示するためのＨＴＭＬデータの送信要求に先立って、パスワードや個体識別番号等、認証に必要な情報などを携帯端末１０から受信したときに、ユーザＩＤ及びアクセスの時刻の情報をログデータに記録してもよい。

また、制限手段５６は、ログデータに基づいて、ユーザ（第１のユーザ）の仲間のユーザ（関係付けられたユーザ）のうち、所定の条件を満たした時点でログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数を算出する機能を備える。この場合、制限手段５６の機能は、以下の通り実現することができる。ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２にアクセスしてログデータを参照して、ユーザがメニューｍ１２（図１１のステップＳ６参照）を選択操作した（所定の条件を満たした）時刻を基準としてログインしている仲間のユーザ数を算出する。あるいは、ＣＰＵ２１は、ゲームデータベース３２にアクセスしてログデータを参照して、ユーザがメニューｍ１２（図１１のステップＳ６参照）を選択操作した（所定の条件を満たした）時刻を基準として所定時間内にアクセスしている仲間のユーザ数を算出する。なお、ＣＰＵ２１は、仲間のユーザを判別するために対象となるユーザのユーザデータを参照する。

本変形例における制限手段５６の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１４に示したフローのステップＳ２４０の処理において、ユーザデータベース３１にアクセスし、バリアカードを使用した（ステップＳ２３０においてメニューｍ１２の選択操作を行った）ユーザのユーザＩＤに対応する仲間のユーザＩＤのうち、メニューｍ１２を選択操作した時刻を基準としてログインしている仲間のユーザ数、あるいはメニューｍ１２を選択操作した時刻を基準として所定時間内にログインしている仲間のユーザ数を算出する。そして、ＣＰＵ２１は、仲間のユーザＩＤを１つ当たり１分としてバリアの効果時間をもとめ、バリア使用データに記憶すればよい。この場合、算出された仲間のユーザ数が５名であればバリアの効果時間は５分となり、仲間のユーザ数が１０名であればバリアの効果時間は１０分となる。なお、バリアの効果時間は、仲間のユーザ数に応じて段階的に変動するように設定されてもよい。例えば、仲間のユーザ数が５名以下の場合には、バリアの効果時間を５分とし、仲間のユーザ数が６名以上１０名以下の場合には、バリアの効果時間を１０分としてもよい。また、バリアの効果時間は、所定の演算式等を用いて、仲間のユーザ数を当該演算式に当てはめることで求められてもよい。

（７−３）変形例３
上記実施形態において、ユーザ同士を関係付ける登録手段５１（関係付け手段）を備え、制限手段５６は、ユーザ（第１のユーザ）の仲間のユーザ（関係付けられたユーザ）のうち、ログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が所定値以上の場合に、所定の条件を満たしたと判別してもよい。
ここで、「ログイン」には、パスワードや個体識別番号等、認証に必要な情報を通信端末１０から送信してアクセスする場合や、ゲーム上の操作入力に関する情報を通信端末１０から送信してウェブページの更新を要求することによりアクセスする場合（例えばＨＴＴＰリクエストを送信する場合）などが含まれてもよい。
これにより、ユーザの仲間のユーザのうち、ログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が所定値以上の場合に、当該ユーザは、自らのユーザ識別情報と第１のユーザの保有するアイテムとの対応付けが解除されることを所定期間制限することができるというメリットが得られる。つまり、第１のユーザは、仲間のユーザと同時にログインすることにより、上記のメリットを自動的に享受することができる。これにより、第１のユーザは、仲間のユーザと同時にログインすることが動機付けられる。このため、仲間のユーザとさらに関係性が高くなるような仕組みとすることができる。また、このような仕組みとすることで、ゲーム全体のアクセス数の向上に寄与でき、この結果、ゲームのコミュニティの活性化、ソーシャル性を高めることができる。

この場合、ＣＰＵ２１は、例えば、図８に示したトップページのメニューｍ３が選択操作されると、図１５に示すログデータを参照して、ユーザのユーザＩＤに対応する仲間のユーザＩＤのうち、メニューｍ３を選択操作した時刻を基準としてログインしている仲間のユーザ数、あるいはメニューｍ３を選択操作した時刻を基準として所定時間内にログインしている仲間のユーザ数を算出する。そして、ＣＰＵ２１は、仲間のユーザ数が所定値以上の場合に、図１２に示すバリア使用データにユーザＩＤ（メニューｍ３を選択操作したユーザのユーザＩＤ）、使用時刻（メニューｍ３を選択操作した日時）、効果時間を記憶すればよい。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。

例えば、上述した実施形態では、適用されるゲームが女性戦士カードを用いたデジタルカードゲームである場合を想定したが、対戦によってアイテムを獲得可能に構成されているゲームであれば、ゲームの種別は如何なるものでもよい。例えば、野球やサッカーなどの競技形式のデジタルカードゲームにおいて、試合に勝利した場合に対戦相手の保有する特定のアイテムを獲得することができるようにしてもよい。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、対応付け手段５３、対戦実行手段５４、解除手段５５、及び制限手段５６の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。例えば、図１６（ａ），（ｂ）には、図７に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。なお、上述した実施形態では、各種データ（例えば、バリア使用データやログデータなど）をデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム進行手段
５３…対応付け手段
５４…対戦実行手段
５５…解除手段
５６…制限手段

Claims (9)

1. ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付ける対応付け手段と、
   第１のユーザによるゲーム上の対戦を実行する対戦実行手段と、
   前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除する解除手段と、
   前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限する制限手段と、
   を備えた、ゲーム制御装置。
2. 前記対戦実行手段は、ユーザが対戦相手となる他のユーザを選択することにより前記対戦を実行し、
   前記制限手段は、前記所定の条件を満たしたときに、前記第１のユーザが対戦相手として選択されることを所定期間制限することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. ユーザ同士を関係付ける関係付け手段を備え、
   前記制限手段は、前記第１のユーザに関係付けられたユーザ数が多いほど、前記所定期間を長くすることを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記制限手段は、前記第１のユーザに関係付けられたユーザのうち、前記所定の条件を満たした時点でログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が多いほど、前記所定期間を長くすることを特徴とする、
   請求項３に記載されたゲーム制御装置。
5. 前記制限手段は、所定の操作入力に関する情報を取得した場合に、前記所定の条件を満たしたと判別することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. ユーザ同士を関係付ける関係付け手段を備え、
   前記制限手段は、前記第１のユーザに関係付けられたユーザのうち、ログインしているユーザ数、あるいはログインしてからの経過時間が所定時間以内のユーザ数が所定値以上の場合に、前記所定の条件を満たしたと判別することを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. ゲーム制御装置におけるゲーム制御方法であって、
   ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付けるステップと、
   第１のユーザによるゲーム上の対戦を実行するステップと、
   前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除するステップと、
   前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限するステップと、
   を備えた、ゲーム制御方法。
8. ゲームの実行を制御するために、コンピュータに、
   ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付ける機能、
   第１のユーザによるゲーム上の対戦を実行する機能、
   前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除する機能、及び
   前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限する機能、
   を実現させるためのプログラム。
9. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
   ユーザのユーザ識別情報と、ゲーム上のアイテムとを対応付ける対応付け手段、
   第１のユーザによるゲーム上の対戦を実行する対戦実行手段、
   前記対戦の結果に基づき、前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けを解除する解除手段、
   前記第１のユーザのユーザ識別情報と前記第１のユーザの保有するアイテムとの対応付けが前記対戦の結果に基づき解除されることを、所定の条件を満たしたときに所定期間制限する制限手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。

Images