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

Abstract

【課題】ユーザが、仲間との間で頻繁な交流を避けつつ、仲間に対する関心あるいは興味を高めることができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供すること。
【解決手段】本発明のゲーム制御装置は、ユーザ間を関係付ける関係付け手段と、ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける受付手段と、第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する取得手段と、前記取得手段が前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する付与手段と、を備える。
【選択図】図１４

Description

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

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

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

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

上述したソーシャルゲームの提供者あるいは運営者にとって、ユーザ間の仲間関係が親密であるほど、ゲームコミュニティの活性化を図れ、結果的にユーザのゲーム離れを抑制できるという利点がある。しかしながら、ユーザから見ると、仲間に対して親近感は持ちながらも、仲間との間で頻繁な（あるいは、過度の）交流は避けたいという傾向があり、仲間関係がゲームコミュニティの活性化に十分に寄与していないという課題がある。

本発明は上述した観点に鑑みてなされたもので、ユーザが、仲間との間で頻繁な交流を避けつつ、仲間に対する関心あるいは興味を高めることができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、
ユーザ間を関係付ける関係付け手段と、
ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける受付手段と、
第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する取得手段と、
前記取得手段が前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する付与手段と、
を備えた、ゲーム制御装置である。

ここで、「イベント」とは、例えば、ゲーム内で定期、又は不定期に開始される参加型のゲームや、ウェブページ等の画像によって実現される催し物、行事等であってよい。

このゲーム制御装置では、第１のユーザは、イベントに参加の申し込みが受け付けられておらず、かつ第１のユーザと関係付けられているユーザ（以下、適宜「仲間」という。）を予め選択し、その後に、第１のユーザと選択された仲間とがそのイベントに対する参加の申し込みが受け付けられた場合に、第１のユーザに特典が付与される。つまり、第１のユーザは、イベントの参加の申し込みをすることについて、自らの仲間のうち選択した仲間と仮想的な約束を行い、約束が実現された場合に第１のユーザに対して特典が付与される構成となっている。このとき、第１のユーザと、選択された仲間との間では、現実的な約束とは違い、約束に当たっての何らかの交流を要さず、選択された仲間は、自らが第１のユーザに選択され仮想的な約束がなされたことについて認識しない。また、第１のユーザにとっては、仮想的な約束相手となる仲間について適切な選択を行って特典を得るべく、自らの仲間に対する興味あるいは意識付けが高くなる。例えば、イベントに参加する可能性が高い仲間を知るために、日頃から仲間に対する意識付けを高く保つようになる。よって、このゲーム制御装置によれば、特典を得ようとする射幸心に基づく仲間選択を介して、ユーザが仲間との間で頻繁な、また直接的な交流を避けつつも、仲間に対する関心あるいは興味を高めることができるようになる。

上記ゲーム制御装置において、前記第１のユーザと関係付けられた各ユーザの過去のイベントの参加の申し込み履歴、及び前記第１のユーザと前記各ユーザとの交流履歴の双方、又はいずれか一方を報知するためのデータを生成する生成手段、を備えてもよい。過去のイベントの参加の申し込み履歴や、各ユーザとの交流履歴が報知されると、それらの情報が仲間を選択するときの基となる情報となるため、第１のユーザに対して、仲間を選択する過程において仲間に対する興味をさらに持たせることができるようになる。また、過去のイベントの参加の申し込み履歴や、各ユーザとの交流履歴についての情報を基にして、イベントに参加する可能性が高い仲間を予想して当てることで特典を得る、という射幸心を第１のユーザに抱かせるようにすることができる。

上記ゲーム制御装置において、前記付与手段は、前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザによって選択されたユーザに対して特典を付与してもよい。第１のユーザによって選択されたユーザ、すなわち仮想的な約束の約束相手の仲間に対しても、仮想的な約束が実現したときに特典を付与することで、その仲間は、自分が約束相手にされていたことに加え、不意の特典を得られたことによって第１のユーザに対して親近感を持つようになる。

上記ゲーム制御装置において、前記付与手段は、前記第１のユーザによって選択されたユーザの数が多くなるにつれて、前記第１のユーザに対して付与する特典を少なくしてもよい。第１のユーザによって選択されたユーザの数が多くなる（つまり、仮想的な約束相手の仲間の数が多くなる）と、選択されたいずれかのユーザがイベントに参加の申し込みをする可能性が確率的に高くなる。そこで、選択されたユーザの数が多い場合には、約束が実現した（つまり、第１のユーザと、選択されたいずれかのユーザとのイベントに対する参加の申し込みを受け付けた）ときの特典を少なくすることで、第１のユーザに、闇雲に仲間の選択をするのではなく、注意深く仲間を選択することを動機付けることができる。

上記ゲーム制御装置において、前記付与手段は、前記第１のユーザと関係付けられたユーザ（仲間）の数が多いほど、特典を大きくしてもよい。関係付けられたユーザの数が多い場合には、多くの母集団の中からいずれかのユーザを選択することになるため、選択したユーザが実際にイベントの参加の申し込みを行う確率が相対的に低くなる。そこで、第１のユーザと関係付けられたユーザの数が多いほど、付与される特典を大きくすることで、関係付けられたユーザの数に関わらず、公平に（あるいは、特典の期待値が大きく変化しないように）特典を付与することができるようになる。また、関係付けられたユーザの数が多いほど、その中からユーザを選択することに第１のユーザにとって負担がより大きく生ずるため、その負担に応じた特典を付与することが好ましい。

上記ゲーム制御装置において、前記付与手段は、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みの受け付け時刻の時間差に応じて、前記第１のユーザに対して付与する特典、及び前記第１のユーザによって選択されたユーザに対して付与する特典の双方、又はいずれか一方を変化させてもよい。
例えば、上記時間差が短いほど、第１のユーザと選択されたユーザとの間で仮想的な約束がより高い精度で実現できたと考えることもできる。そのような場合に、例えば大きな特典を第１のユーザに付与してもよい。このような構成とすることで、第１のユーザは、自ら行った仮想的な約束がどの程度の精度で実現できたのか興味を持つようになり、イベントに対する関心を高く持つことができる。

上記ゲーム制御装置において、前記第１のユーザによって選択されるユーザの数を所定数以下に制限する制限手段、を備えてもよい。仮に、関係付けられたユーザ全員を選択することが可能である場合には、個々の仲間に対して関心を持たなくなる可能性があり、仲間に対する関心あるいは興味を高めるように機能しない虞がある。そこで、第１のユーザが選択するユーザの数を制限することで、第１のユーザは、ユーザの選択に注意深くなり、個々のユーザにより関心を持たせることができる。

前記制限手段を備えた場合において、前記所定数は、前記第１のユーザと関係付けられたユーザの数に対する所定の割合であってもよい。第１のユーザと関係付けられたユーザの数とは無関係に、前記所定数を絶対値として決めてしまうと、関係付けられたユーザの数が多い場合には、ユーザの選択の自由度が狭まってしまう場合がある。例えば、所定数が絶対値として「３」とした場合に、仲間の数が３人の第１のユーザと仲間の数が３０人の第１のユーザとでは、前者が全部の仲間を選択できるのに対し、後者は１割の仲間が選択できるに過ぎない。そこで、前記所定数を第１のユーザと関係付けられたユーザの数に対する所定の割合とすることで、関係付けられたユーザの数とは無関係に、ユーザの選択の自由度を設定することができるようになる。

本発明の第２の観点は、ゲーム制御装置におけるゲーム制御方法であって、
ユーザ間を関係付けるステップと、
ゲーム内のイベントに対するユーザの参加の申し込みを受け付けるステップと、
第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得するステップと、
前記取得するステップで前記ユーザ選択情報を取得した後に、前記受け付けるステップが、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与するステップと、
を備えた、ゲーム制御方法である。

本発明の第３の観点は、ユーザの操作によるゲームの実行を制御するために、コンピュータに、
ユーザ間を関係付ける機能、
ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける機能、
第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する機能、及び
前記取得する機能により前記ユーザ選択情報を取得した後に、前記受け付ける機能が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、ユーザによって操作される通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲームシステムであって、
ユーザ間を関係付ける関係付け手段、
ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける受付手段、
第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する取得手段、及び
前記取得手段が前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する付与手段
の各手段を、前記通信端末又は前記ゲーム制御装置のいずれか一方が備えた、
ゲームシステムである。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザが、仲間との間で頻繁な交流を避けつつ、仲間に対する関心あるいは興味を高めることができ、ひいてはゲームコミュニティの活性化を図ることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 実施形態のデータベースサーバに含まれるユーザデータベースの構成例を示す図。 約束相手データのデータ構成例を示す図。 イベント管理データのデータ構成例を示す図。 実施形態のゲームのウェブページの一例を示す図。 実施形態のゲームのウェブページの一例を示す図。 実施形態のゲームのウェブページの一例を示す図。 実施形態のゲームのウェブページの一例を示す図。 実施形態のゲームのウェブページの一例を示す図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の処理の一例を示すフローチャート。 実施形態のゲーム制御装置の処理の一例を示すフローチャート。 実施形態のゲーム制御装置の処理の一例を示すフローチャート。 実施形態の変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 履歴データのデータ構成例を示す図。 実施形態のゲームのウェブページの一変形例を示す図。 実施形態の変形例のゲーム制御装置において、約束相手の数と特典との対応関係の一例を示す図。 実施形態の別の変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

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

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(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）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、野球形式のデジタルカードゲームを採り上げる。
野球形式のデジタルカードゲーム（以下、適宜単に「本実施形態のゲーム」という。）は、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦をする、あるいは技能レベルごとの野球のリーグ戦を戦うように構成されているゲームである。本実施形態のゲームには、自らのチームを作り上げていくために選手カードを探索するスカウト処理や、抽選によって選手カードを入手することを可能とする抽選処理、あるいは２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理等が設けられている。
本実施形態のゲームに実装されている各機能については、後述する。

図６に、上述した本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザを識別するための情報であるユーザＩＤごとに、ユーザ名／表示画像、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・行動ポイント
上記本実施形態のゲームにおいて、例えばユーザによるゲーム上のスカウトを行う上で必要となるポイントである。行動ポイントの値は、スカウトを行うことで低減し、所定の時間が経過する毎に回復（増加）する。
・運営ポイント
上記本実施形態のゲームにおいて、例えばユーザによるゲーム上の対戦を行う上で必要となるポイントである。運営ポイントの値は、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復（増加）する。
・強化ポイント
上記本実施形態のゲームにおいて、例えばユーザによる選手カードの強化を行う上で必要となるポイントである。強化ポイントの値は、選手カードの強化を行うことで低減し、他のユーザとの対戦で勝利するか、あるいは所定の時間が経過する毎に回復（増加）する。
・エールポイント
上記本実施形態のゲームにおいて、仲間のユーザへ応援メッセージを送信することでユーザが取得するポイントである。なお、後記するように、このポイントを所定量、消費することで、選手カードを獲得できる抽選を行うことができる。この抽選においては、種々の能力レベルの選手カードを獲得できる。入手困難な高能力のレアカードも、低い確率であるが、獲得できる場合がある。
・選手数
ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値（例えば、６０）は予め規定されている。
・仲間
対象とするユーザＩＤの仲間である他のユーザＩＤのデータである。
・保有カードの画像データ
上記本実施形態のゲームの場合、保有カードの画像データは、ユーザが保有する選手カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータには、選手カードの能力値を示すデータが含まれる。例えば、図６に示すように、パラメータの項目として「打力」，「走力」，「守備力」等の各々の各能力値が含まれてもよい。図６の例では、能力値は０〜１０００の範囲の値であって、能力値が大きい値であるほど能力が高いことを示している。図６では、能力の指標としての項目として、「打力」，「走力」，「守備力」を例示しているが、選手が投手であれば別の項目、例えば「球速」，「制球力」，「スタミナ」等としてもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されるゲームの設定についての情報や、ゲームの結果に関する情報を記憶、更新する。ゲーム結果に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲーム結果に関する情報は、異なるユーザＩＤ同士の対戦の結果（スコア等）、特定の技能レベルの複数のユーザＩＤの間のリーグ戦の結果（スコア、ランキング等）などを含む。

本実施形態のゲームは、後述するように、ユーザがイベントに対して参加の申し込みをすることについて自らの仲間と仮想的な約束をすることができるように構成されているが、この構成を実現するために、ゲームデータベース３２は、約束相手データと、イベント管理データとを記憶する。約束相手データとイベント管理データのデータ構成例を、それぞれ図７と図８に示す。図７に示すように、約束相手データは、ユーザごとに、対象となるイベントと、そのイベントについて仮想的な約束をした仲間（約束相手）とが対応付けて記述されているデータである。図８に示すように、イベント管理データは、イベントごとに、そのイベントに対して参加の申し込みをしたユーザのユーザＩＤと、参加申し込み日時と、イベントの結果（例えば、対応するユーザのイベントでの成績等のゲームの結果を表すデータ）とを対応付けるデータである。

（５）本実施形態のゲーム
次に、本実施形態のゲームについて、図９〜１３を参照して説明する。図９〜図１３は、それぞれ、ゲームを実行中にユーザの通信端末１０に表示される一連のウェブページの例を示す図である。
図９は、ゲームのトップページであるウェブページＰ１を示す図である。このウェブページＰ１は、個々のユーザＩＤごとに構成される。図９に例示されるトップページは、ユーザ名（図９では、ＫＮＭ）のほか、ユーザデータ表示領域、選手画像表示領域、メニュー表示領域、及び期間限定イベント案内領域を含む。

ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、Ｘ／Ｙの形式で表記されているポイントまたは数は、Ｘがユーザの保有するポイントまたは数であり、Ｙがそのポイントまたは数の最大値であることを示す。例えば、選手数が「４０／６０」と表記されていれば、ユーザが保有する選手カードの数が４０であり、最大で保有可能な選手カードの数が６０であることを示す。

選手画像表示領域は、ユーザによって予め選択された選手カードの画像データが表示される領域である。
メニュー表示領域は、本実施形態のゲームに設けられる複数の処理（スカウト処理、強化処理、試合処理、抽選処理、オーダー処理）に対応したメニューとして、「スカウト」、「強化」、「試合」、「抽選」、「オーダー」の各メニューｍ１〜ｍ５が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。なお、オーダー処理は、ユーザの指示の下、選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行する処理である。

各メニューの処理の概略は、以下のとおりである。
・スカウト処理：
自らのチームを作り上げていくために選手カードを探索する処理である。スカウトを実行することで行動ポイントは消費するが、強化ポイントは増加する。所定のメニューを選択操作する度に、所定の、あるいはランダムな確率で選手カードが発掘され、その選手カードがユーザに付与される。
・強化処理：
強化ポイントを消費することで、２枚以上の選手カードを一体化して特定の選手カードのパラメータを上昇させる処理である。
・試合処理：
他のユーザのチームと野球の試合を行う処理である。試合を行うことで運営ポイントは消費するが、試合に勝利すれば強化ポイントが例えば一定量増加する。
・抽選処理：
一定量のエールポイントを消費し、あるいはゲーム上のアイテムとしての抽選券を使用して抽選によって選手カードを入手する処理である。
・オーダー処理：
ユーザが選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行するための処理である。

期間限定イベント案内領域には、不定期に開催される期間限定イベントに対する案内を事前に行うために設けられている領域である。期間限定イベント案内領域には、期間限定イベントを案内するテキスト（図９では、「予告：〜期間限定」のテキスト）と、「仲間と約束する」と表記されたメニューｍ１０とが表示される。
このゲームでは、開始前のイベント（図９の例では、期間限定イベントＩＶ２０）に対して、ユーザが自らの仲間を選択してその仲間と仮想的な約束ができるように構成されている。ユーザは、仮想的な約束を一方的に行い、従って仮想的な約束相手となる仲間のユーザは、自らが約束相手となっていることを認識することはない。なお、メニューｍ１０は、対象となる期間限定イベントＩＶ２０が開始されるまで表示される。

仮想的な約束を行うためのメニューｍ１０が選択操作されると、図１０のＰ２に示すようにウェブページが更新される。ウェブページＰ２には、約束相手を選択するために仲間の一覧が表示される。図１０のウェブページＰ２には一部の仲間のみが表示されているが、ユーザによるスクロール操作によってユーザの仲間のすべてが閲覧でき、選択対象とすることができる。ウェブページＰ２において、ユーザが例えばユーザ名：ＧＩＰのユーザを選択する操作を行った場合には、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３では、ウェブページＰ２で選択した仲間と仮想的な約束が行われたことを示すテキストとともに、他の仲間と仮想的な約束を行うためのメニューｍ１１が表示される。

期間限定イベントＩＶ２０が開始されると、トップページ上の期間限定イベント案内領域内の表示が図１１のウェブページＰ４に示すように更新される。つまり、期間限定イベント案内領域には、「イベントＩＶ２０に参加する」と表記されたメニューｍ２０が表示される。ウェブページＰ４でメニューｍ２０が選択操作されると、例えば図１２のＰ５に示すようにイベントの内容を表示するウェブページに更新される。本実施形態では、イベントの内容は特に問わないが、ウェブページＰ５に示す例では、イベントＩＶ２０は、ユーザに「野球クイズ」を実行させ、一定の条件を満たすユーザに対して所定の特典（図１２では、「１０回抽選券」）を付与するように構成されているイベントである。この野球クイズの例では、クイズの問題Ｑ１，Ｑ２，…は、「ａ」と表記されたメニューｍａ、又は「ｂ」と表記されたメニューｍｂのいずれかをユーザが選択操作する二者択一形式の問題が想定されている。

再び、トップページ（図１３のＰ６）に戻り、ユーザ：ＫＮＭの約束相手であるユーザ：ＧＩＰが同じイベントＩＶ２０に参加の申し込みを行った（つまり、約束相手もメニューｍ２０の選択操作を行った）場合には、仮想的な約束が守られた（実現された）ものとして、ユーザ：ＫＮＭに対して所定の特典（図１３の例では、一定量のエールポイント）が付与される。つまり、ユーザ（図の例では、ＫＮＭ）が仲間である他のユーザ（図の例では、ＧＩＰ）を選択し、特定のイベントにおいて仮想的な約束をした場合に、ユーザ：ＫＮＭとユーザ：ＧＩＰが共に、その特定のイベントに対して参加の申し込みをしたときには、仮想的な約束が守られたものとしてユーザ：ＫＮＭに対して所定の特典が付与される仕組みとなっている。

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

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

関係付け手段５２は、異なるユーザ間を関係付ける機能を備える。つまり、関係付け手段５２は、例えばユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤとを関係付けて記録する。すなわち、関係付け手段５２は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として記録する。
関係付け手段５２の機能は例えば、以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（仲間申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されてもよい。
ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するウェブページを表示するためのＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータ（相手のユーザＩＤ）を書き込む。なお、ＣＰＵ２１は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザによる所定の操作を契機として、両者を仲間として登録しても良い。

ゲーム進行手段５３は、ユーザが本実施形態のゲームを実行するに当たって、ユーザのログイン時の認証処理を実行する機能を備える。
このゲーム進行手段５３の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。

ゲーム進行手段５３は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる機能を備える。
ゲーム進行手段５３を実現するに当たり、ゲームサーバ２０のＣＰＵ２１は、図９に示したように、ウェブページ上に表示される各メニューに、ゲームを進行させるためのいずれかの処理が予め割り当てるようにしてＨＴＭＬデータを生成する。このとき、ＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。
ＣＰＵ２１は、通信端末１０においてウェブページ上のメニュー（メニューｍ１〜ｍ５のいずれか）が選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。具体的には、ＣＰＵ２１は、メニューｍ１〜ｍ５にそれぞれ対応するスカウト処理、強化処理、試合処理、抽選処理、オーダー処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるようにして、階層的に各処理が実行される。

・スカウト処理：
ＣＰＵ２１は、ウェブページ上の所定のメニューが選択操作されたことを認識する度に、所定の、あるいはランダムな確率で選手カードを発掘し、その選手カードをユーザに付与するスカウト処理を行う。ＣＰＵ２１は、スカウト処理を実行することで、ユーザデータにアクセスして、対象となる行動ポイントを減少させ、かつ強化ポイントを増加させる。なお、十分な量の行動ポイントをユーザが所持していない場合にはスカウトは実行されない。ＣＰＵ２１は、一定時間が経過する度に行動ポイントを増加（回復）させる。

・強化処理：
ＣＰＵ２１は、例えば一定量の強化ポイントを消費することで、２枚以上の選手カードを一体化して特定の選手カードのパラメータを上昇させる処理を行う。このとき、例えば、２枚以上の選手カードのパラメータを加算、あるいは所定の重み付けをもって加算する処理が行われる。

・試合処理：
ＣＰＵ２１は、例えば試合処理を実行することを望むユーザの操作を契機として、試合処理を実行する。試合処理は、そのユーザに対して対戦相手を選択可能にするウェブページを表示するためのＨＴＭＬデータの送信処理、対戦相手の選択結果に基づくユーザ間の対戦処理を含む。ＣＰＵ２１は、試合処理の実行に応じて、試合処理の実行の操作を行ったユーザの運営ポイントを一定量減少させるが、試合に勝利すれば強化ポイントを例えば一定量増加させる。なお、試合の勝敗、あるいは勝敗の確率は、例えば、対戦相手となるユーザ同士が保有する一定数の選手カード（チーム内の選手カード）のパラメータの積算値の大小に応じて決定されてよい。

・抽選処理：
ＣＰＵ２１は、ユーザによる所定の選択操作を契機として、そのユーザの一定量のエールポイントを消費させるか、あるいはそのユーザが保持するゲーム上のアイテムとしての抽選券を使用することによって、抽選によって選手カードを入手する抽選処理を行う。抽選処理は、好ましくは、選手カードを抽選箱の中から１枚を取り出す（引く）演出を経て実行される。抽選によって出現する選手カードは基本的にランダムであるが、レア度の高い選手カードが抽選で出現する確率は非常に低く設定されている。

・オーダー処理：
ＣＰＵ２１は、ユーザによる所定の指示操作に応じて、ユーザの手持ちの選手カードに基づいて、試合処理を実行するときのチームのオーダーの入れ替え、控えの選手カードとの交替等を実行する。

受付手段５４は、ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける機能を備える。受付手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ゲーム内のイベントに対してユーザによって参加の申し込みのためのメニュー（例えば、図１１のウェブページＰ４ではメニューｍ２０）の選択操作がされたことを認識すると、ゲームデータベース３２にアクセスして、イベント管理データの申し込み対象のイベントのデータに、そのユーザのユーザＩＤと、参加申し込み日時（つまり、参加の申し込みのためのメニューの選択操作を認識した時刻）とを書き込む。

取得手段５５は、第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する機能を備える。言い換えれば、取得手段５５の機能は、ユーザが特定のイベントに参加する仮想的な約束を行う仲間を特定する情報を取得する機能である。取得手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ゲーム内のイベントを対象として仲間と仮想的な約束を行うユーザの適切な操作（例えば、図９，図１０のウェブページＰ１，Ｐ３のメニューｍ１０，ｍ１１の選択操作、及びウェブページＰ２の約束相手の選択操作）を認識すると、ユーザ選択情報として、選択した約束相手についての情報を含むＨＴＴＰリクエストを受信する。ＣＰＵ２１は、そのＨＴＴＰリクエストを受信すると、ゲームデータベース３２にアクセスして、約束相手データの仮想的な約束を行うユーザのユーザＩＤのデータに、対象となるイベントと、約束相手のデータ（ユーザ名あるいはユーザＩＤ等）とを対応付けて書き込む。

特典付与手段５６は、取得手段５５がユーザ選択情報を取得した後に、受付手段５４が、特定のイベントについて仮想的な約束を行ったユーザ（「第１のユーザ」という。）、及び第１のユーザによって選択された第１のユーザの仲間のイベントに対する参加の申し込みを受け付けた場合には、第１のユーザに対して特典を付与する機能を備える。
特典付与手段５６の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２にアクセスして、対象となるイベントについて、第１のユーザ（例えば図７では、ユーザ名：ＫＮＭのユーザ）とその約束相手の情報（例えば図７では、イベントＩＶ２０についてユーザ名：ＧＩＰ，ＳＥＬのユーザ）とを対にして読み出す。つまり、ユーザ名として、（ＫＮＭ，ＧＩＰ）、（ＫＮＭ，ＳＥＬ）がそれぞれ１組のユーザとして読み出される。次にＣＰＵ２１は、イベント管理データを参照し、読み出した１組のユーザが、対象となるイベント（この例では、イベントＩＶ２０）において共に参加の申し込みがされているかチェックする。例えば（ＫＮＭ，ＧＩＰ）の１組のユーザの場合、ＣＰＵ２１は、ユーザ名：ＫＮＭとユーザ名：ＧＩＰに対応するユーザＩＤが共にイベントＩＶ２０のイベント管理データのユーザＩＤとして書き込まれているかチェックする。その結果、１組のユーザが共に、対象となるイベントに参加している場合には、仮想的な約束を行ったユーザ（第１のユーザ；図７の例では、ユーザ名：ＫＮＭのユーザ）に対して特典を付与する処理を行う。

なお、特定のユーザ（図７の例では、ユーザ名：ＫＮＭのユーザ）の約束相手が複数存在するときに、約束が実現された約束相手の数が複数存在する場合が想定されるが、このような場合に付与される特典は、約束が実現された約束相手の数に関わらず一定であってもよいし、その数に応じて変動させてもよい。

付与される特典は、ゲーム上で利用可能なポイント（例えば、エールポイント）やゲーム上のアイテム等、如何なるものでもよい。例えば特典としてユーザにエールポイントが付与される場合、ＣＰＵ２１は、そのユーザのユーザデータにアクセスして、エールポイントの値に対して、付与されたエールポイントの分を加算する処理を行う。その他、特典の別のバリエーションとして、エールポイントを消費して行う選手カード等の抽選の際、希少度の高い選手カードを入手できる確率を所定期間、上昇させるという構成をとることもできる。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
以下、図１５〜１７のフローチャートを参照して、本実施形態のゲーム制御装置の主要な処理について説明する。図１５は、仮想的な約束を行うための約束処理を示すフローチャートである。図１６は、イベントに対する参加申し込み処理を示すフローチャートである。図１７は、仮想的な約束が実現したユーザに対して特典を付与する特典付与処理を示すフローチャートである。なお、図１５〜１７のフローチャートにおける各処理の実行に伴って適宜、ウェブページＰ１〜Ｐ６の各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、煩雑とならないようにＨＴＭＬデータの送信処理をフローチャートには記載していない。フローチャート上で、ウェブページＰ１〜Ｐ６が表示されるタイミングは、Ｐ１〜Ｐ６の符号で示してある。

先ず図１５に示す約束処理は、対象となるイベントがまだ開始されていないタイミングで実行される。先ずゲームサーバ２０のＣＰＵ２１は、ウェブページＰ１（図９）において、特定のイベント（例えばイベントＩＶ２０）において仲間と仮想的な約束をするためのメニューｍ１０が選択操作されたことを認識すると（ステップＳ１００：ＹＥＳ）、対象となるユーザのユーザデータを参照して、そのユーザの仲間のユーザＩＤを読み出し、仲間の一覧を含むウェブページＰ２を表示するためのＨＴＭＬデータを通信端末１０宛に送信する（ステップＳ１０２）。ＣＰＵ２１は、ウェブページＰ２上でいずれかの仲間の選択操作を認識すると（ステップＳ１０４：ＹＥＳ）、選択された仲間についての情報を基に、ゲームデータベース３２に含まれる約束相手データを更新する（ステップＳ１０６）。例えば、処理対象のユーザがユーザ名：ＫＮＭであり、約束相手の仲間がユーザ名：ＧＩＰである場合には、図７に例示するように約束相手データに書き込みが行われる。その後、通信端末１０に表示されるウェブページはＰ３に示すように、選択された約束相手を確認するウェブページに更新される。ＣＰＵ２１は、このウェブページＰ３においてメニューｍ１１が選択操作されたことを認識すると（ステップＳ１０８：ＹＥＳ）、新たな約束相手を選択するためのウェブページＰ２を表示するためのＨＴＭＬデータを通信端末１０宛に送信する。複数の約束相手が選択される場合には、その都度、ステップＳ１０８からステップＳ１０２に戻り、それによって、ウェブページが、Ｐ２→Ｐ３→Ｐ２→Ｐ３→…というように切り替わって表示され、約束相手データが逐次更新される。

図１６に示すイベントに対する参加申し込み処理は、対象となるイベントが開始された後のタイミングで実行される。先ずゲームサーバ２０のＣＰＵ２１は、ウェブページＰ４（図１１）において、特定のイベント（例えばイベントＩＶ２０）に参加の申し込みをするためのメニューｍ２０が選択操作されたことを認識すると（ステップＳ２００：ＹＥＳ）、イベントに対して参加の申し込みをしたユーザのユーザＩＤと、参加申し込み日時とを、ゲームデータベース３２内のイベント管理データに記録する（ステップＳ２０２）。

図１７に示す特典付与処理は、対象となるイベントが開始された後のタイミングで実行される。先ずゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２にアクセスして、対象となるイベントについて、処理対象のユーザ（例えば図７では、ユーザ名：ＫＮＭのユーザ）の約束相手データを参照して、約束相手がいるか否か判定し、約束相手がいると判断した場合には（ステップＳ３００：ＹＥＳ）、約束相手同士の１組のユーザを順に読み出す（ステップＳ３０２）。図７に示した例では、処理対象となるユーザ（ユーザ名：ＫＮＭ）には特定のイベントＩＶ２０について少なくとも２名の仲間の約束相手（ユーザ名：ＧＩＰ，ＳＥＬのユーザ）が存在するため、ＣＰＵ２１は、（ＫＮＭ，ＧＩＰ）、（ＫＮＭ，ＳＥＬ）のそれぞれ１組のユーザを順に約束相手データから読み出す。これらの１組のユーザが共にイベントに参加申し込み済みか否かについて、イベント管理データを参照して判定する（ステップＳ３０４）。そして、ＣＰＵ２１は、いずれかの１組のユーザが共にイベントに参加申し込み済みである場合には（ステップＳ３０４：ＹＥＳ）、処理対象のユーザ（例えば図７では、ユーザ名：ＫＮＭのユーザ）に対して所定の特典を付与する処理を行う（ステップＳ３０６）。

上述したように、このゲーム制御装置によれば、ユーザ（第１のユーザ）が特定のイベントについて、未だそのイベントに参加の申し込みを受け付けていない仲間を選択した後に、第１のユーザ及びその仲間のイベントに対する参加の申し込みを受け付けた場合には、第１のユーザに対して特典を付与するようにする。つまり、第１のユーザは、イベントの参加の申し込みをすることについて、自らの仲間のうち選択した仲間と仮想的な約束を行い、約束が実現された場合に第１のユーザに対して特典が付与される構成となっている。このとき、第１のユーザと、選択された仲間との間では、現実的な約束とは違い、約束に当たっての何らかの交流を要さず、選択された仲間は、自らが第１のユーザに選択され仮想的な約束がなされたことについて認識しない。また、第１のユーザにとっては、仮想的な約束相手となる仲間について適切な選択を行って特典を得るべく、自らの仲間に対する興味あるいは意識付けが高くなる。例えば、イベントに参加する可能性が高い仲間を知るために、日頃から仲間に対する意識付けを高く保つようになる。よって、このゲーム制御装置によれば、特典を得ようとする射幸心に基づく仲間選択を介して、ユーザが仲間との間で頻繁な、また直接的な交流を避けつつも、仲間に対する関心あるいは興味を高めることができるようになる。

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

（８−１）変形例１
本変形例の機能ブロック図を図１８に示す。図１８に示す機能ブロック図は、図１４のもの比べて、生成手段５７が追加された点で異なる。
生成手段５７は、ユーザ（第１のユーザ）の各仲間の過去のイベントの参加の申し込み履歴、及び第１のユーザと各仲間との交流履歴の双方、又はいずれか一方を報知するためのデータを生成する機能を備える。過去のイベントの参加の申し込み履歴や、第１のユーザの各仲間との交流履歴が報知されると、それらの情報が仲間を選択するときの基となる情報となるため、第１のユーザに対して、仲間を選択する過程において仲間に対する興味をさらに持たせることができるようになる。また、過去のイベントの参加の申し込み履歴や、各仲間との交流履歴についての情報を基にして、イベントに参加する可能性が高い仲間を予想して当てることで特典を得る、という射幸心を第１のユーザに抱かせるようにすることができる。

生成手段５７の機能は、以下のようにして実現できる。ゲームデータベース３２は、ユーザごとに、過去のイベントの参加申し込み履歴や、仲間との交流履歴を記録する履歴データを備える。図１９に履歴データのデータ構成例を示す。図１９に例示する履歴データには、過去のイベントの参加申し込み履歴として、イベントを特定するコード（例えば、ＩＶ１等）と、ユーザのイベントの結果（例えば、イベントにおけるユーザの成績、ゲーム結果等）とを含み、交流履歴として、仲間間のエール頻度（応援メッセージの送受信の頻度）と、プレゼント回数（仲間間でのプレゼントの受け渡し回数）と、対戦回数（仲間間で試合を行った回数）とを含む。ＣＰＵ２１は、イベントが行われる度に、各ユーザがそのイベントに参加した場合には、履歴データにアクセスしてイベントとそのイベントの結果を書き込む。ＣＰＵ２１は、仲間間で交流が行われた場合には、履歴データの交流履歴の項目（エール頻度等）のデータを更新する。

本変形例では、ＣＰＵ２１は、図９のウェブページＰ１においてメニューｍ１０が選択操作されたことを認識すると、ウェブページＰ２に代えて、図２０に示すウェブページＰ２ａを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。このＨＴＭＬデータを生成するに当たって、ＣＰＵ２１は、ゲームデータベース３２内の履歴データを参照して、対象となるユーザ（第１のユーザ）の仲間についての過去のイベントの参加の申し込み履歴や、第１のユーザの各仲間との交流履歴を読み出す。ウェブページＰ２ａでは、読み出した交流履歴の内容が第１のユーザの仲間ごとに表示される。なお、ウェブページＰ２ａの交流履歴において、エール頻度の記号（Ａ，Ｂ等）は、頻度の大きさ（レベル）を一定の基準で分類した記号である。なお、ウェブページＰ２ａでは、過去のイベントの参加の申し込み履歴と交流履歴の双方を表示する例を示したが、いずれか一方を表示してもよい。

（８−２）変形例２
上記実施形態のゲーム制御装置において、特典付与手段５６は、ユーザ（第１のユーザ）による仲間の選択結果（ユーザ選択情報）を取得手段５５が取得した後に、受付手段５４が、第１のユーザ、及び第１のユーザによって選択された仲間のイベントに対する参加の申し込みを受け付けた場合には、第１のユーザによって選択された仲間に対して特典を付与してもよい。第１のユーザによって選択された仲間、すなわち仮想的な約束の約束相手の仲間に対しても、約束が実現したときに特典を付与することで、その仲間は、自分が約束相手にされていたことに加え、不意の特典を得られたことによって第１のユーザに対して親近感を持つようになる。
本変形例は、特典付与手段５６が第１のユーザに対して特典を付与したのと同様にして実現できる。つまり、約束相手データから読み出された１組のユーザが共に対象となるイベントに参加している場合には、仮想的な約束を行ったユーザ（第１のユーザ）によって選択された仲間に対して特典を付与する処理を行う。付与される特典は、ゲーム上で利用可能なポイント（例えば、エールポイント）やゲーム上のアイテム等、如何なるものでもよい。例えば特典として選択された仲間にエールポイントが付与される場合、ＣＰＵ２１は、選択された仲間のユーザデータにアクセスして、エールポイントの値に対して、付与されたエールポイントの分を加算する処理を行う。

（８−３）変形例３
上記実施形態のゲーム制御装置において、特典付与手段５６は、ユーザ（第１のユーザ）によって選択された仲間の数が多くなるにつれて、第１のユーザに対して付与する特典を少なくしてもよい。第１のユーザによって選択された仲間の数が多くなる（つまり、仮想的な約束相手の仲間の数が多くなる）と、選択されたいずれかの仲間がイベントに参加の申し込みをする可能性が確率的に高くなる。そこで、選択された仲間の数が多い場合には、仮想的な約束が実現したときの特典を少なくすることで、第１のユーザに、闇雲に仲間の選択をするのではなく、注意深く仲間を選択することを動機付けることができる。
本変形例は、以下のようにして実現できる。例えば、第１のユーザが仮想的な約束を行った仲間（約束相手）の数と、特典との関係を示す対応データを予め、例えばＲＯＭ２２に記憶しておく。そして、ＣＰＵ２１は、特典を決定するに当たって、ユーザデータに記述されている仲間のユーザＩＤの数（つまり、仲間の数）と、約束相手データを参照して得られた約束相手の数と、ＲＯＭ２２内の対応データとを参照して、特典を決定する。例えば、一例としてエールポイントを付与する場合、約束相手の数が１、２、３、４である場合に、それぞれ付与する特典（エールポイント）を４０００ｐｔ、３０００ｐｔ、２０００ｐｔ、１０００ｐｔ（ｐｔ：ポイント）となるように、つまり概ね反比例の関係となるように対応データが構成される。

（８−４）変形例４
上記実施形態のゲーム制御装置において、特典付与手段５６は、ユーザ（第１のユーザ）の仲間の数が多いほど、特典を大きくしてもよい。仲間の数が多い場合には、多くの母集団の中からいずれかの仲間を選択することになるため、選択した仲間が実際にイベントの参加の申し込みを行う確率が相対的に低くなる。そこで、第１のユーザの仲間の数が多いほど、付与される特典を大きくすることで、仲間の数に関わらず、公平に（あるいは、特典の期待値が大きく変化しないように）特典を付与することができるようになる。また、仲間の数が多いほど、その中から仲間を選択することに第１のユーザにとって負担がより大きく生ずるため、その負担に応じた特典を付与することが好ましい。
本変形例は、例えば、以下のようにして実現できる。例えば、第１のユーザの仲間の数と、第１のユーザが仮想的な約束を行った仲間（約束相手）の数と、特典との関係を示す対応データを予め、例えばＲＯＭ２２に記憶しておく。そして、ＣＰＵ２１は、特典を決定するに当たって、ユーザデータに記述されている仲間のユーザＩＤの数（つまり、仲間の数）と、ＲＯＭ２２内の対応データとを参照して、特典を決定する。例えば、図２１に、本変形例の対応データの構成例を示す。図２１に示すように、この対応データでは、仲間の数が多くなるにつれて、約束相手の数が同一であれば特典が増加するように構成されている。なお、図２１は、変形例３と変形例４を組み合わせた対応データの一例であるが、仲間の数と特典の関係のみが定義されていてもよい。

（８−５）変形例５
上記実施形態のゲーム制御装置において、特典付与手段５６は、ユーザ（第１のユーザ）、及び第１のユーザによって選択された仲間のイベントに対する参加の申し込みの受け付け時刻の時間差に応じて、第１のユーザに対して付与する特典、及び第１のユーザによって選択された仲間に対して付与する特典の双方、又はいずれか一方を変化させてもよい。
例えば、上記時間差が短いほど、第１のユーザと選択された仲間との間で仮想的な約束がより高い精度で実現できたと考えることもできる。そのような場合に、例えば大きな特典を第１のユーザに付与してもよい。このような構成とすることで、第１のユーザは、自ら行った仮想的な約束がどの程度の精度で実現できたのか興味を持つようになり、イベントに対する関心を高く持つことができる。
本変形例は、例えば上記時間差は、例えばＣＰＵ２１に内蔵されているタイマで計測できる。例えばＲＯＭ２２に、時間差と特典との対応データを設定しておく。ＣＰＵ２１は、その対応データを参照して、計測された時間差に応じた特典を読み出す処理を行う。あるいは、時間差と特典の大きさの関係を示す関数が予め定義されていてもよく、その場合にＣＰＵ２１は、計測した時間差に基づき特典を算出する処理を行う。

（８−６）変形例６
本変形例の機能ブロック図を図２２に示す。図２２に示す機能ブロック図は、図１４のもの比べて、制限手段５８が追加された点で異なる。
制限手段５８は、ユーザ（第１のユーザ）によって選択される仲間の数を所定数以下に制限する機能を備える。仮に、第１のユーザが仲間全員を選択することが可能である場合には、個々の仲間に対して関心を持たなくなる可能性があり、仲間に対する関心あるいは興味を高めるように機能しない虞がある。そこで、第１のユーザが選択する仲間の数を制限することで、第１のユーザは、ユーザの選択に注意深くなり、個々のユーザにより関心を持たせることができる。
本変形例は、例えば、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図１０のウェブページＰ３におけるメニューｍ１１が選択操作されたことを認識する度に、カウンタをインクリメントする処理を行う。そして、ＣＰＵ２１は、逐次そのカウンタのカウント値を参照し、選択された仲間の数が所定数に達したと判断した場合には、新たな仲間との仮想的な約束を禁止する。例えば所定数が５名である場合には、「約束相手が５名になりました。これ以上の仲間と約束できません。」などのテキストを含み、かつメニューｍ１１を含まないＨＴＭＬデータを第１のユーザの通信端末１０宛に送信する。

（８−７）変形例７
変形例６に示したように、制限手段５８を備えた場合において、約束相手の数を制限するための所定数は、第１のユーザの仲間の数に対する所定の割合であってもよい。第１のユーザの仲間の数とは無関係に、上記所定数を絶対値として決めてしまうと、仲間の数が多い場合には、ユーザの選択の自由度が狭まってしまう場合がある。例えば、所定数が絶対値として「３」とした場合に、仲間の数が３人の第１のユーザと仲間の数が３０人の第１のユーザとでは、前者が全部の仲間を選択できるのに対し、後者は１割の仲間が選択できるに過ぎない。そこで、上記所定数を第１のユーザの仲間の数に対する所定の割合とすることで、仲間の数とは無関係に、ユーザの選択の自由度を設定することができるようになる。
本変形例では、ＣＰＵ２１は、第１のユーザのユーザデータの仲間のユーザＩＤの数によって仲間の数を算出し、その仲間の数の所定の割合によって、約束相手の数を制限するための所定数を決定する。カウンタの値が所定数に達した後の処理は、変形例６と同様である。

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

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

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、関係付け手段５２、ゲーム進行手段５３、受付手段５４、取得手段５５、特典付与手段５６、生成手段５７、及び制限手段５８の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。なお、上述した実施形態では、約束相手データとイベント管理データを、データベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、通信端末１０内に記憶する構成としてもよい。その場合には、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置内に記憶する構成としてもよい。図２３（ａ），（ｂ）には、本実施形態のゲーム制御装置の各機能（図１４に示す各機能）について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間の分担例を示す。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…関係付け手段
５３…ゲーム進行手段
５４…受付手段
５５…取得手段
５６…特典付与手段
５７…生成手段
５８…制限手段

本発明の第４の観点は、ユーザによって操作される通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するサーバと、を含むゲームシステムであって、
ユーザ間を関係付ける関係付け手段、
ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける受付手段、
第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する取得手段、及び
前記取得手段が前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する付与手段
の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
ゲームシステムである。

本発明の第２の観点は、ゲーム制御装置におけるゲーム制御方法であって、
前記ゲーム制御装置が備える関係付け手段がユーザ間を関係付けるステップと、
前記ゲーム制御装置が備える受付手段がゲーム内のイベントに対するユーザの参加の申し込みを受け付けるステップと、
前記ゲーム制御装置が備える取得手段が第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得するステップと、
前記取得するステップで前記ユーザ選択情報を取得した後に、前記受け付けるステップにおいて、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みが受け付けられた場合には、前記ゲーム制御装置が備える付与手段が前記第１のユーザに対して特典を付与するステップと、
を備えた、ゲーム制御方法である。

Claims (11)

1. ユーザ間を関係付ける関係付け手段と、
   ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける受付手段と、
   第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する取得手段と、
   前記取得手段が前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する付与手段と、
   を備えた、ゲーム制御装置。
2. 前記第１のユーザと関係付けられた各ユーザの過去のイベントの参加の申し込み履歴、及び前記第１のユーザと前記各ユーザとの交流履歴の双方、又はいずれか一方を報知するためのデータを生成する生成手段、を備えたことを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記付与手段は、前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザによって選択されたユーザに対して特典を付与することを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記付与手段は、前記第１のユーザによって選択されたユーザの数が多くなるにつれて、前記第１のユーザに対して付与する特典を少なくすることを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記付与手段は、前記第１のユーザと関係付けられたユーザの数が多いほど、特典を大きくすることを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記付与手段は、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みの受け付け時刻の時間差に応じて、前記第１のユーザに対して付与する特典、及び前記第１のユーザによって選択されたユーザに対して付与する特典の双方、又はいずれか一方を変化させることを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記第１のユーザによって選択されるユーザの数を所定数以下に制限する制限手段、を備えたことを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. 前記所定数は、前記第１のユーザと関係付けられたユーザの数に対する所定の割合であることを特徴とする、
   請求項７に記載されたゲーム制御装置。
9. ゲーム制御装置におけるゲーム制御方法であって、
   ユーザ間を関係付けるステップと、
   ゲーム内のイベントに対するユーザの参加の申し込みを受け付けるステップと、
   第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得するステップと、
   前記取得するステップで前記ユーザ選択情報を取得した後に、前記受け付けるステップが、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与するステップと、
   を備えた、ゲーム制御方法。
10. ユーザの操作によるゲームの実行を制御するために、コンピュータに、
    ユーザ間を関係付ける機能、
    ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける機能、
    第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する機能、及び
    前記取得する機能により前記ユーザ選択情報を取得した後に、前記受け付ける機能が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する機能、
    を実現させるためのプログラム。
11. ユーザによって操作される通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲームシステムであって、
    ユーザ間を関係付ける関係付け手段、
    ゲーム内のイベントに対するユーザの参加の申し込みを受け付ける受付手段、
    第１のユーザと関係付けられたユーザの中から、第１のユーザによって選択されたユーザを示すユーザ選択情報を取得する取得手段、及び
    前記取得手段が前記ユーザ選択情報を取得した後に、前記受付手段が、前記第１のユーザ、及び前記第１のユーザによって選択されたユーザの前記イベントに対する参加の申し込みを受け付けた場合には、前記第１のユーザに対して特典を付与する付与手段
    の各手段を、前記通信端末又は前記ゲーム制御装置のいずれか一方が備えた、
    ゲームシステム。

Images