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

Description

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

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（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)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

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

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

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

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

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

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

ＡＰＩサーバ２６は、ＷｅｂＡＰＩが実装されており、他のゲームサーバのＡＰＩサーバとの間でＨＴＴＰに従った通信を行う。例えば、ＡＰＩサーバ２６は、ＨＴＴＰを利用して他のゲームサーバのＡＰＩサーバへ所定の処理に対するリクエストを行い、リクエストを受けたＡＰＩサーバが、その処理結果をリクエストの要請元のＡＰＩサーバ２６に対して返すように構成されている。本実施形態の場合、ＡＰＩサーバ２６は、特定のユーザの情報（例えば、後述する特典データ）を含むリクエストを、他のゲームサーバのＡＰＩサーバに対して行う。このリクエストを受けた他のゲームサーバでは、リクエストに含まれるユーザの情報に基づいて所定の処理を行う。
なお、図４では、ＡＰＩサーバ２６がゲームサーバ２０に組み込まれた場合について示しているが、ＡＰＩサーバ２６は、ゲームサーバ２０とは別体で構成してもよい。

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

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、ゲームキャラクタの画像が表示されるカードを使用するデジタルカードゲームを採り上げる。つまり、ゲームサーバ２０ａ，２０ｂ，…はそれぞれ、デジタルカードゲームであるゲームＡ，ゲームＢ，…をそれぞれ実行するものとする。

図６に、本実施形態のデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）において適用されるユーザデータベース３１の一例を示す。ユーザデータベース３１に含まれるデータは、ゲームサーバ２０によって逐次更新されうる。以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ（ユーザ識別情報）、あるいはユーザを特定するユーザ名ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。

・ユーザ名
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ユーザＩＤと同様に、複数のゲームＡ，Ｂ，Ｃ，…において同一のユーザは同一のユーザ名によって管理されてもよいし、ゲーム毎に異なるユーザ名が設定できるようにしてもよい。
・進行レベル
各ゲーム上のユーザの進行レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。経験値が所定値に達すると進行レベルが１つ上昇する。
・体力ポイント
本実施形態のゲームにおいて、後述するクエストを行う上で必要となるポイントである。体力ポイントは、クエストを行う度に低減し、所定の時間が経過する毎に回復（増加）する値である。
・経験値
本実施形態のゲームにおいて、後述するクエストを行う上で増加する値である。経験値が所定の値（例えば、１００）に達すると、進行レベルが１増加して経験値はリセットされる（つまりゼロになる）。
・仲間のユーザＩＤ
ユーザがゲーム上で仲間（後述する）の関係にあるユーザＩＤである。
・保有カード
保有カードは、ゲーム上でユーザが保有しているカードのデータ（例えばＣ１等のカードの種類を示す識別子など）である。各カードは、例えばゲーム内のバトル等で参照されるパラメータ（つまり、攻撃力と防御力等の能力値）が対応付けられてもよい。
・保有アイテム
保有アイテムは、ゲーム上でユーザが保有しているアイテムのデータ（例えばＱ３等のアイテムの種類を示す識別子など）である。

本実施形態の説明では、データベースサーバ３０ａ，３０ｂ，…がそれぞれ同一構成のユーザデータベース３１を備えており、ゲームＡ，ゲームＢ，…が後述するクエストを実行する機能を備えている場合を想定する。各ゲームの実行内容は全く異なる内容であってもよいが、後で明らかになるように、本実施形態では各ゲームの内容自体がさして重要な要素ではない。
本実施形態のゲームシステムでは、複数のゲームサーバ２０ａ，２０ｂ，２０ｃ，…が共通のプラットフォーム上に実装されており、複数のゲームＡ，Ｂ，Ｃ，…において同一のユーザは同一のユーザＩＤによって管理される場合を想定するが、このような場合に限られない。異なるゲーム間でのユーザＩＤの対応関係が各ゲームサーバ２０において既知であれば、同一のユーザでゲーム毎に異なるユーザＩＤを使用することもできる。

本実施形態では、例えば、ユーザがゲームＡ（第１ゲーム）をプレイするようにユーザを誘導する目的で、ユーザのゲームＡにおける実行状況に応じて、ユーザがゲームＢ（第２ゲーム）において受け取ることが可能な特典を付与する、ゲームＢとの連動キャンペーン（以下、適宜単に「連動キャンペーン」という。）がゲームＡにおいて行われる。この連動キャンペーンは、ユーザが早めにゲームＡをプレイするように促す目的で、期間限定で行われてもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうるが、例えば、後述するクエストの結果についての情報を含む。
また、ゲームデータベース３２は、上述した連動キャンペーンに関連して、プレゼントデータベースと特典管理データベースを記憶、更新する。より具体的には、上述したゲームＡとゲームＢの間の連動キャンペーンが行われる場合、少なくとも、データベースサーバ３０ａのゲームデータベース３２に特典管理データベースが設けられ、データベースサーバ３０ｂのゲームデータベース３２にプレゼントデータベースが設けられる。

プレゼントデータベースは、各ユーザ宛のプレゼントについての情報を記憶する。プレゼントは、ゲーム提供者から特典として付与されるカード、アイテム、又はポイント等や、例えば他のユーザ（仲間のユーザ等）からプレゼントあるいはトレードとして付与されるカード、アイテム等であってもよい。プレゼントデータベースのデータ構成例を図７に示す。図７に示すプレゼントデータベースは、ユーザＩＤごとに、プレゼントの発生原因についての情報と、プレゼント内容についての情報（例えば、ユーザに付与されるアイテムやカードなどを示す識別子）、及びユーザのプレゼントの受取状態を示すフラグ（１：受取済、０：受取未）を含む。

特典管理データベースは、ユーザごとに、上記連動キャンペーンにおいてユーザに付与する特典を管理するためデータベースである。特典管理データベースの構成例を図８に示す。図８に示す特典管理データベースでは、ユーザごとに、ゲームＢとの連動キャンペーンにおける複数の特典発生条件の各々について、特典発生条件（所定の条件）を満たしたか否かについての情報、及び、特典発生条件を満たした場合に、特典発生条件を満たしたことを示す情報（後述する特典データ；第１情報）がゲームサーバ２０ｂに送信済みであるか否かについての情報を管理する。例えば、図８に示す例では、特典発生条件を満たさない場合に「００」、特典発生条件を満たし、かつ後述する特典データが未送信である場合に「１０」、特典発生条件を満たし、かつ後述する特典データが送信済みである場合に「１１」の２ビットのデータが書き込まれる。

（５）本実施形態のゲーム
以下、本実施形態のゲームについて、図９〜１２を参照しながら説明する。

図９は、本実施形態のゲームＡにおいて、ゲームＢとの連動キャンペーンの内容を表示するときのウェブページの例を示す図ある。図１０は、ユーザがゲームＡを実行するときに表示されるウェブページの例を示す図である。図１１は、本実施形態のゲームＡにおいて、ゲームＢとの連動キャンペーンによる条件（特典発生条件）を達成したときに表示されるウェブページの例を示す図である。図１２は、本実施形態のゲームＢにおいて、ゲームＡを実行することによって得た特典を受け取るときに表示されるウェブページの例を示す図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

図９のウェブページＰ１ａは、本実施形態のゲームＡのトップページの一例であり、個々のユーザＩＤに応じて構成される。図９の例では、キャラクタ画像表示領域１０１、ユーザデータ表示領域１０２、及びメニュー表示領域１０３を含む。
キャラクタ画像表示領域１０１は、対象となるユーザＩＤのユーザデータに含まれる複数のカードに対応するキャラクタ画像のうちユーザによって予め指定されたキャラクタ画像が表示される領域である。

ユーザデータ表示領域１０２は、対象となるユーザＩＤのユーザデータに含まれる、進行レベル、体力ポイント、カード、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域１０２内の「カード」には、ユーザの保有カードの枚数が表示される。また、図９に例示するように、カード数が「３／５０」と表記されている場合、ユーザの保有カードの枚数が３枚であり、最大で保有可能なカードの枚数が５０枚であることを示す。体力ポイントが「５０／５０」と表記されている場合、ユーザの現在の体力ポイントが５０であり、現時点でユーザの体力ポイントの最大値も５０であることを示す。ユーザデータ表示領域１０２内の「仲間」には、ユーザの仲間の数が表示される。図９に例示するように、仲間の数が「０／１０」と表記されている場合、ユーザの現在の仲間の数が０であり、現時点でユーザが登録可能な仲間の数が１０であることを示す。
図９に示すウェブページＰ１ａでは、処理対象のユーザがゲームＡを開始して間もなく、進行レベルがＬｖ１（初期値）である場合が想定されている。

メニュー表示領域１０３は、本実施形態のゲームＡに設けられる複数の機能に対応するメニューや、特定のイベント、キャンペーン等に対応するメニューを表示する領域である。ここでは、本実施形態のゲームＡに設けられる機能に対応するメニューの例として、メニューｍ１（「クエスト」）が表示される場合が示されているが、これに限定されるものではなく、他の処理を実行するメニューを適宜表示してよい。例えば、他のユーザとのカードを使用した対戦（バトル）を実行するための「バトル」のメニューを表示してもよい。
本実施形態のゲームＡでは、メニュー表示領域１０３において、他のゲームＢとの連動キャンペーンについてのウェブページ（以下、適宜「キャンペーンページ」という。）を表示するためのメニューｍ５（「ゲームＢとの連動キャンペーン」）が表示される。

図９のウェブページＰ１ａ上でメニューｍ５が選択操作されると、Ｐ２ａに示すようにウェブページが更新される。このウェブページＰ２ａには、他のゲームＢとの連動キャンペーンを案内する内容や、処理対象のユーザがゲームＢにおいて特典を受け取ることが可能である場合にはその特典の内容が表示されてもよい。
特典の内容として例示している「回復薬」は、ユーザの体力ポイントを最大値に増加させるためのゲーム上のアイテムである。後述するように、クエストの実行によって体力ポイントが低下していくため、回復薬を使用することによって短時間でより多くのクエストを実行でき、より先にゲームを進行させることができるようになる。「カードくじ券」は、例えば、ゲームＢにおいて、抽選によってカードのくじを引く機能が設けられている場合に、その機能を１回実行することを可能とするための券である。
図９に示すように、ウェブページＰ２ａには、ゲームＢへリンクするためのバナーｂ１（「ゲームＢへ！」）が表示されてもよい。図９のウェブページＰ２ａは、処理対象のユーザがゲームＢにおいて受け取り可能な特典がない場合のキャンペーンページである。

図１０のウェブページＰ１ａ上でメニューｍ１（「クエスト」）が選択操作されると、Ｐ３ａに示すようにウェブページが更新される。このウェブページＰ３ａには、ユーザが所定の領域（エリア）を探索するためのメニューｍ１０（「クエスト実行」）が含まれる。メニューｍ１０が選択操作されると、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３には、メニューｍ１１（「もう一度実行」）が表示され、探索が続行できるようになっている。メニューｍ１０又はメニューｍ１１が選択操作される度に一定の、あるいはランダムな増加量で達成率の値が増加し、達成率が１００％に達するとエリアの探索が終了して次のエリアに進むことができる。メニューｍ１０又はメニューｍ１１が選択操作される度に、ユーザの体力ポイントが所定量（図１０の例では、８）だけ消費され、ユーザの経験値が所定量（図１０の例では、８）だけ増加する。探索対象のエリアは、複数設けられてもよい。なお、クエスト処理では、メニューｍ１０又はメニューｍ１１が選択操作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されている様々なカードやアイテムをユーザが入手できるように構成してもよい。入手したカードやアイテムは、例えばウェブページの表示領域２０２に表示される。

クエストを実行する度に体力ポイントが所定量だけ消費（低下）するが、低下後のユーザが保持する体力ポイントを表示するポイント表示領域２０３が設けられている。例えばウェブページＰ３ａ→Ｐ４ａでは、体力ポイントが１００から９２に低下したことがわかる。ウェブページＰ４ａにおいてメニューｍ１１の選択操作を繰り返し行うと、経験値が所定値（例えば、１００）に達し、例えば進行レベルがＬｖ１からＬｖ２へ上昇する。その結果、例えばＰ５ａに示すようにウェブページが更新される。
なお、ウェブページＰ４ａにおいてメニューｍ１１の選択操作を繰り返し行うと、上述したように体力ポイントが低下していくが、体力ポイントが１回のクエストに要する体力（例えば８）よりも少なくなると、それ以上クエストの実行ができない状態となる。その場合、再びクエストを実行できるようになるには、時間の経過によって体力ポイントが回復（増加）するまで待機することが必要となる。

進行レベルがＬｖ２に昇格した後に、図１１のウェブページＰ１ａ上でメニューｍ５が選択操作されると、Ｐ６ａに示すようにウェブページ（キャンペーンページ）が更新される。このウェブページＰ６ａでは、図９のウェブページＰ２ａとは異なり、Ｌｖ２に昇格したことによる特典が受けられることを示すテキストを含む表示領域２０５が設けられる。

図１１のウェブページＰ６ａ上でバナーｂ１（「ゲームＢへ！」）を選択操作すると、図１２のＰ１ｂに示すように、処理対象のユーザのゲームＢのトップページが表示される。この例では、ゲームＢのトップページＰ１ｂの構成は、ゲームＡのトップページＰ１ａと同様の構成であるが、全く異なる構成であってもよい。本実施形態のゲームＢに設けられる機能に対応するメニューの例として、ゲームＡと同様に、クエストを実行するためのメニューｍ２１（「クエスト」）が表示される場合が示されている。
ゲームＢのトップページＰ１ｂには、ユーザに未だ受け取られていないプレゼントがある場合にメニューｍ２５（「プレゼントが届いています！！」）が表示される。メニューｍ２５を選択操作することにより、Ｐ２ｂに示すようにウェブページが更新されて、プレゼント一覧が表示される。プレゼント一覧では、処理対象のユーザ宛の各プレゼントについて、受け取るためのメニューｍ２７（「受け取る」）か、又は受取済みであることを示すテキスト（「受取済」）のいずれかが対応付けて表示される。ここでは、図１１のウェブページＰ６ａに示したように、ゲームＡにおける連動キャンペーンによって、処理対象のユーザがゲームＢで受け取り可能な特典（この例では、限定カード）がメニューｍ２７に対応付けられている場合を示している。
ウェブページＰ２ｂにおいてメニューｍ２７が選択操作されると、選択操作されたメニューｍ２７に対応するプレゼントをユーザが受け取ることができるように構成されている。

（６）ゲーム制御装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置が備える機能について説明する。
本実施形態では、例えば、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した実施形態のゲームが適用される場合を例として、図１３の機能ブロック図を参照してゲーム制御装置が備える機能とその実現方法について説明する。なお、図１３（ａ）は、ゲームＡを実行するゲームサーバ２０ａとデータベースサーバ３０ａによって実現される各機能の機能ブロックを示し、図１３（ｂ）は、ゲームＢを実行するゲームサーバ２０ｂとデータベースサーバ３０ｂによって実現される各機能の機能ブロックを示す。
なお、登録手段５１は、本発明に必須の構成要素ではなく、本実施形態のゲーム制御装置を好適にする構成要素である。

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

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

ゲーム実行手段５２は、ゲームＡを実行する機能を備える。
本実施形態の場合、ゲームＡの実行は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することでなされる。このとき、ゲームサーバ２０ａのＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストによって要求される処理を実行し、その実行結果であるＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０へ返す。

ＨＴＴＰリクエストによって要求される処理の実行内容は、ゲームに設けられている機能によって異なるが、例えば以下のとおりである。
例えば図１０に関連付けて説明したクエストを実行する場合、ゲームサーバ２０ａのＣＰＵ２１は、ユーザによる所定の選択操作内容（例えば、メニューｍ１０又はｍ１１の選択操作結果）を含むＨＴＴＰリクエストを受信すると、処理対象のユーザの達成率、体力ポイント、及び経験値を更新する処理を行う。ゲームサーバ２０ａのＣＰＵ２１は、例えば、ユーザの達成率、体力ポイント、及び経験値のデータを、クエストの実行開始時（メニューｍ１の選択時）にデータベースサーバ３０ａからＲＡＭ２３に転送し、クエスト中はＲＡＭ２３内のデータに対して更新処理を行い、クエスト終了時に、ＲＡＭ２３内の更新後のデータをデータベースサーバ３０ａ内のデータに上書きする。
例えば他のユーザとの間でのカードを用いたバトルを実行する場合には、ゲームサーバ２０ａのＣＰＵ２１は、例えば、バトル対象となるユーザのバトルにおける使用カードのパラメータ（例えば、攻撃力及び防御力の値等）の値を比較し、その比較結果に基づいてバトルの勝敗を決定する。

判定手段５３は、処理対象のユーザによるゲームＡ（第１ゲーム）の実行状況、又は処理対象のユーザと他のユーザとのゲームＡにおける関係の程度が特典発生条件（所定の条件）を満たすか否かを判定する機能を備える。
特典発生条件は、特に限定されるものではないが、ユーザがゲームＡを遊んでみることを動機付けられる条件、つまりユーザをゲームＡに誘導できるような条件であることが好ましい。例えば、ユーザによる「ゲームＡの実行状況が特典発生条件を満たす」とは、ゲームＡの進行レベルやゲームＡの実行時間の総計等が所定の値を超える場合、あるいは判定対象のユーザがゲームＡに初めてアクセスするときにチュートリアルを表示させるときにはそのチュートリアルの表示又は処理が完了したことであってもよい。
ユーザと他のユーザとの「ゲームＡにおける関係の程度が特典発生条件を満たす」とは、例えば、ユーザの招待によって他のユーザがゲームＡに対してユーザ登録した場合、ゲームＡにおいてユーザと他のユーザが仲間の関係にある場合、あるいはゲームＡにおけるユーザと他のユーザの親密度が所定のレベル以上である場合などである。
なお、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。例えば、ユーザ間の挨拶メッセージの送信あるいは受信の頻度（挨拶頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが多いほど、親密度を高く設定される。

判定手段５３の機能は、以下のようにして実現することができる。ゲームサーバ２０ａのＣＰＵ２１は、ユーザの通信端末１０からＨＴＴＰリクエストを受信する度に、特典管理データベースにアクセスして、「００」（特典発生条件を満たさない）のデータが書き込まれている各特典発生条件を、処理対象となるユーザが満たすか否か判定する。特典発生条件についての判定処理は、対象となる特典発生条件ごとに異なるものであってよい。

例えば、処理対象のユーザの進行レベルの所定レベルに達したことを特典発生条件とする場合には、ゲームサーバ２０ａのＣＰＵ２１は、そのユーザのユーザデータにアクセスして進行レベルの値を読み出し、読み出した進行レベルの値が所定レベルと同じか、それ以上である場合には、特典発生条件を満たしたと判定する。
ゲームＡのチュートリアルがユーザの選択操作に応じて階層的に、あるいは段階的に表示される複数のウェブページによって構成されており、そのチュートリアルの処理が完了したことを特典発生条件とする場合には、ゲームサーバ２０ａのＣＰＵ２１は、チュートリアルを構成する複数のウェブページのうち最後に表示されるウェブページを表示するためのＨＴＭＬデータの通信端末１０宛の送信が完了した場合に、特典発生条件を満たしたと判定するようにしてもよい。
処理対象のユーザの招待によって他の１人のユーザが登録したことを特典発生条件とする場合には、例えば以下のように判定が行われる。このとき、ユーザが他のユーザによる招待に起因してゲームＡにユーザ登録するときには、ゲームサーバ２０ａのＣＰＵ２１は、招待したユーザと招待されたユーザを関連付けるデータを、例えばユーザデータに記憶しておき、そのデータを参照して特典発生条件を満たしたか否か判定する。

ゲームサーバ２０ａのＣＰＵ２１は、処理対象となるユーザが特典発生条件を満たすことになった場合には、特典管理データベースにおいて、その特典発生条件に対応するデータを「００」（特典発生条件を満たさない）から「１０」（特典発生条件を満たし、かつ後述する特典データが未送信）に書き換える。

提供手段５４は、判定手段５３により特典発生条件（所定の条件）を満たすと判定された場合に、処理対象のユーザについて特典発生条件を満たしたことを示す特典データ（第１情報）を、ゲームＢ（第２ゲーム）を実行するゲームサーバ２０ｂ（第２ゲーム制御装置）に提供する機能を備える。
提供手段５４の機能は、以下のようにして実現することができる。ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベースにアクセスして、「１０」（特典発生条件を満たし、かつ特典データが未送信）が書き込まれている特典発生条件に対応した特典データを生成し、ＲＡＭ２３内の特典データキュー（バッファ）に追加する（書き込む）。
ここで、特典データと特典データキューについて、図１４を参照して説明する。図１４は、特典データと特典データキューの構成例を示す図である。特典データは、ユーザＩＤ、対象ゲーム（特典の付与の対象となるゲームであり、本実施形態の例ではゲームＢ）、及び特典内容（対象ゲームであるゲームＢにおいて受け取ることができる特典の内容）から構成される。特典データキューは、複数の特典データを一時的に記憶させるためのＲＡＭ２３の所定領域のアドレス群によって構成されている。ＣＰＵ２１は、各アドレスに特典データを書き込み、送信対象の特典データを順次読み出していく。

ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベースを参照して、「１０」（特典発生条件を満たし、かつ後述する特典データが未送信）のデータに対応する、ユーザＩＤと特典発生条件に基づいて、特典データを生成して特典データキューに書き込む。
ゲームサーバ２０ａのＣＰＵ２１は、特典データキューから送信対象の特典データを読み出した後、その読み出した特典データを含むリクエストがゲームサーバ２０ｂのＡＰＩサーバ２６へ送信されるように、ＡＰＩサーバ２６を制御する。なお、ゲームサーバ２０ａのＡＰＩサーバ２６は、ゲームサーバ２０ｂのＡＰＩサーバ２６から、特典データの受信結果（受信成功、又は受信失敗）を含むレスポンスを受信する。
ゲームサーバ２０ａのＣＰＵ２１は、特典データの送信が完了すると、特典管理データベースにアクセスして、送信が完了した特典データに対応するデータを「１０」（特典発生条件を満たし、かつ特典データが未送信）から「１１」（特典発生条件を満たし、かつ特典データが送信済み）に書き換える。

通知手段５５は、判定手段５３により特典発生条件（所定の条件）を満たすと判定された場合に、ゲームＢ（第２ゲーム）において特典が付与されることをユーザに通知する機能を備える。
通知手段５５の機能の実現例を、図１５を参照して、以下説明する。図１５は、通信端末１０にキャンペーンページを表示させるためのシーケンスチャートの一例である。なお、図１５では、処理対象のユーザをユーザＵ１としている。
図１５において、ユーザＵ１がトップページ（例えば図１１のウェブページＰ１ａ）上でメニューｍ５が選択操作されたことを認識すると、通信端末１０は、その選択操作結果を含むＨＴＴＰリクエストをゲームサーバ２０ａへ送信する（ステップＳ１００）。ゲームサーバ２０ａのＣＰＵ２１は、受信したＨＴＭＬデータに基づいて、特典管理データベース（特典管理ＤＢ）から、ユーザＵ１のユーザＩＤの各特典発生条件に対応するデータを読み出す（ステップＳ１１０）。次いで、ＣＰＵ２１は、読み出したデータが示す、各特典発生条件が満たされたか否か、及び、特典データが送信済みか否かについての情報を基に、キャンペーンページの表示領域２０５に適切なテキストが含まれるようにＨＴＭＬデータを生成し（ステップＳ１２０）、ユーザＵ１の通信端末１０へ送信する（ステップＳ１３０）。通信端末１０は、受信したＨＴＭＬデータを解釈して、図１１のウェブページＰ６ａに示すようにキャンペーンページを表示する（ステップＳ１４０）。このキャンペーンページには、ユーザＵ１が特典発生条件を満たした場合に、ゲームＢにおいて付与される特典が表示されている。

登録手段６１及びゲーム実行手段６２はそれぞれ、登録手段５１及びゲーム実行手段５２に対応したゲームＢにおける同一の機能であり、その機能の実現方法についての重複説明は省略する。なお、前述したように、ゲーム実行手段６２によって実行されるゲームＢの内容は、ゲームＡとは異なっていてもよい。

付与手段６３は、特典データ（第１情報）に基づいて、ユーザに対してゲームＢ（第２ゲーム）上の特典を付与する機能を備える。
付与手段６３の機能は、以下のようにして実現することができる。ゲームサーバ２０ｂのＣＰＵ２１は、ＡＰＩサーバを介して特典データをゲームサーバ２０ａから受信すると、受信した特典データに基づいてプレゼントデータベースに新たなデータを書き込む。その場合、ＣＰＵ２１は、特典データに含まれるユーザＩＤに対応する「発生原因」の項目に、連動キャンペーンによる特典であることを示すコードを書き込み、「プレゼント内容」の項目に、特典データに含まれる特典の内容（例えば、カードの種類を示す識別子等）を書き込み、「受取状態」の項目に「０」（受取未）を書き込む。

ゲームサーバ２０ｂのＣＰＵ２１は、ゲームＢにおいてプレゼント一覧を表示するウェブページ（例えば、図１２のウェブページＰ２ｂ）において特典を受け取るための選択操作（例えば、メニューｍ２７に対する選択操作）を認識すると、特典の内容を処理対象のユーザと対応付ける処理を行う。例えば、特典の内容がカードである場合には、ゲームサーバ２０ｂのＣＰＵ２１は、処理対象のユーザのユーザデータにアクセスして、特典としてのカードを保有カードとして書き込む処理を行う。次いでＣＰＵ２１は、プレゼントデータベースにアクセスして、ユーザの受け取り対象（つまり、付与対象）の特典に対応する「受取状態」の項目を「０」（受取未）から「１」（受取済）に書き換える。
ゲームサーバ２０ｂのＣＰＵ２１は、特典を受け取るための選択操作（例えば、メニューｍ２７に対する選択操作）に応じたＨＴＭＬデータを生成して、ユーザの通信端末１０へ送信する。このＨＴＭＬデータによって表示されるウェブページ（図示せず）には、特典がユーザに付与されたことを示すテキストが表示されることが好ましい。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲームシステムにより行われる主要な処理のフローの一例について、図１６〜１８のシーケンスチャートを参照して説明する。なお、図１６及び図１７のシーケンスチャートは、ユーザがゲームＡにおいて、連動キャンペーンの特典発生条件の判定結果に基づく処理を示している。図１８のシーケンスチャートは、ユーザがゲームＡの連動キャンペーンの特典を、ゲームＢにおいて受け取る場合の処理を示している。
図１６〜１８では、処理対象のユーザをユーザＵ１としている。

図１６において、ユーザＵ１がゲームＡのウェブページ上で何らかの選択操作（例えば、クエストを実行する図１０のメニューｍ１０又はｍ１１の選択操作）を行うと、その選択操作結果を含むＨＴＴＰリクエストが通信端末１０からゲームサーバ２０ａに送信される（ステップＳ２００）。ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベースにアクセスして、「００」（特典発生条件を満たさない）のデータが書き込まれている各特典発生条件をユーザＵ１が満たすか否か判定する（ステップＳ２１０）。例えば、ゲームＡにおいて進行レベルがＬｖ２に達したことが特典発生条件である場合には、ゲームサーバ２０ａのＣＰＵ２１は、ユーザＵ１のユーザデータを参照してユーザＵ１の進行レベルがＬｖ２以上であるか否かを判定する。「００」のデータが書き込まれている特典発生条件を満たさない場合には（ステップＳ２１０：ＮＯ）、ステップＳ２７０へ進み、ステップＳ２００のＨＴＴＰリクエストに基づく処理結果を含むＨＴＭＬデータを生成する。
「００」のデータが書き込まれているいずれかの特典発生条件を満たす場合には（ステップＳ２１０：ＹＥＳ）、ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベース（特典管理ＤＢ）内の該当する特典発生条件のデータを「１０」（特典発生条件を満たし、かつ特典データが未送信）に書き換えることによって、特典管理データベースを更新する（ステップＳ２２０）。

次いでゲームサーバ２０ａのＣＰＵ２１は、再度特典管理データベースにアクセスして、「１０」（特典発生条件を満たし、かつ特典データが未送信）が書き込まれている特典発生条件に対応した特典データを生成し、ＲＡＭ２３内の特典データキューに追加する（ステップＳ２３０）。この特典データには、ユーザＵ１のユーザＩＤと、対象ゲームであるゲームＢでの特典内容とを含む。
ゲームサーバ２０ａのＣＰＵ２１は、ＲＡＭ２３内の特典データキューからユーザＵ１の特典データを読み出すと、その読み出した特典データを含むリクエストがゲームサーバ２０ｂのＡＰＩサーバ２６へ送信されるように、ＡＰＩサーバ２６を制御する（ステップＳ２４０）。なお、ゲームサーバ２０ａのＡＰＩサーバ２６は、ゲームサーバ２０ｂのＡＰＩサーバ２６から、特典データの受信結果（受信成功、又は受信失敗）を含むレスポンスを受信する。
ゲームサーバ２０ａのＣＰＵ２１は、特典データの送信が完了すると、特典管理データベースにアクセスして、送信が完了した特典データに対応するデータを「１０」（特典発生条件を満たし、かつ特典データが未送信）から「１１」（特典発生条件を満たし、かつ特典データが送信済み）に書き換えることによって、特典管理データベースを更新する（ステップＳ２５０）。

ゲームサーバ２０ｂのＣＰＵ２１は、ＡＰＩサーバを介して特典データを受信すると、受信した特典データに基づいてプレゼントデータベース（プレゼントＤＢ；図７参照）に新たなデータを書き込むことによって、プレゼントデータベースを更新する（ステップＳ２６０）。その場合、ゲームサーバ２０ｂのＣＰＵ２１は、特典データに含まれるユーザＩＤに対応する「発生原因」の項目に、連動キャンペーンによる特典であることを示すコードを書き込み、「プレゼント内容」の項目に、特典データに含まれる特典の内容（例えば、カードの種類を示す識別子等）を書き込み、「受取状態」の項目に「０」（受取未）を書き込む。

ゲームサーバ２０ａのＣＰＵ２１は、ステップＳ２５０の後にステップＳ２７０へ進み、ステップＳ２００のＨＴＴＰリクエストに基づく処理結果を含むＨＴＭＬデータを生成し（ステップＳ２７０）、生成したＨＴＭＬデータをユーザＵ１の通信端末１０へ送信する（ステップＳ２８０）。ユーザＵ１の通信端末１０は、受信したＨＴＭＬデータを解釈してウェブページを表示する（ステップＳ２９０）。

以上が、ユーザがゲームＡにおいて連動キャンペーンの特典発生条件の判定結果に基づく処理であるが、特典データをゲームサーバ２０ａからゲームサーバ２０ｂへ送信するときに（ステップＳ２４０）、ゲームＢがメンテナンス中であるために、ゲームサーバ２０ｂが特典データを受信できない場合がある。「ゲームＢがメンテナンス中である」とは、例えば、ゲームＢを実行するプログラムを更新する場合等によって、一定時間の間、ゲームＢの実行についてのサービスが停止されている状況である。図１６のシーケンスチャートに対してゲームＢがメンテナンス中である場合を考慮した処理を図１７に示す。
図１７のシーケンスチャートは、図１６と比較してステップＳ２４０が異なる。ゲームＢがメンテナンス中である場合には、ゲームサーバ２０ａのＣＰＵ２１は、特典データの送信が完了するまで、一定時間毎に特典データの再送を繰り返す。ゲームサーバ２０ａのＣＰＵ２１は、ＡＰＩサーバ２６を介して受信成功の受信結果を取得するまで、特典データの再送を繰り返すようにする。

図１８では、ユーザＵ１がゲームＡにおいて特典発生条件を満たした後に、ユーザＵ１がゲームＢにログインした場合が想定される。
ゲームＢのトップページ（例えば、図１２のウェブページＰ１ｂ）上でユーザＵ１が、プレゼント一覧を表示するためのメニューの選択操作（例えば、メニューｍ２５に対する選択操作）を行うと、通信端末１０は、その選択操作結果を含むＨＴＴＰリクエストをゲームサーバ２０ｂへ送信する（ステップＳ３００）。ゲームサーバ２０ｂのＣＰＵ２１は、ＨＴＴＰリクエストを取得すると、プレゼントデータベース（プレゼントＤＢ）のユーザＵ１のデータを読み出し（ステップＳ３１０）、プレゼント一覧を含むＨＴＭＬデータを生成して（ステップＳ３２０）、ユーザＵ１の通信端末１０へ送信する（ステップＳ３３０）。ユーザＵ１の通信端末１０は、受信したＨＴＭＬデータを解釈してウェブページ（例えば、図１２のウェブページＰ２ｂ）を表示する（ステップＳ３４０）。

ユーザＵ１がステップＳ３４０で表示されたプレゼント一覧の中からいずれかの特典を受け取るための選択操作（例えば、メニューｍ２７に対する選択操作）を行うと、通信端末１０は、その選択操作結果を含むＨＴＴＰリクエストをゲームサーバ２０ｂへ送信する（ステップＳ３５０）。ゲームサーバ２０ｂのＣＰＵ２１は、ＨＴＴＰリクエストを取得すると、ユーザデータベース（ユーザＤＢ）とプレゼントデータベース（プレゼントＤＢ）を更新する（ステップＳ３６０）。例えば、特典の内容がカードである場合には、ゲームサーバ２０ｂのＣＰＵ２１は、処理対象のユーザのユーザデータにアクセスして、特典としてのカードを保有カードとして書き込む処理を行う。さらにゲームサーバ２０ｂのＣＰＵ２１は、プレゼントデータベースにアクセスして、ユーザＵ１の受け取り対象（つまり、付与対象）の特典に対応する「受取状態」の項目を「０」（受取未）から「１」（受取済）に書き換える。
ゲームサーバ２０ｂのＣＰＵ２１は、特典を受け取るための選択操作（例えば、メニューｍ２７に対する選択操作）に応じたＨＴＭＬデータを生成して（ステップＳ３７０）、ユーザＵ１の通信端末１０へ送信する（ステップＳ３８０）。ユーザＵ１の通信端末１０は、受信したＨＴＭＬデータを解釈してウェブページを表示する（ステップＳ３９０）。表示されるウェブページには、特典がユーザＵ１に付与されたことを示すテキストが表示されることが好ましい。

以上説明したように、本実施形態のゲーム制御装置では、ゲームＡ（第１ゲーム）においてユーザの実行状況が特典発生条件（所定の条件）を満たした場合に、そのユーザがゲームＢ（第２ゲーム）において特典が付与されるように構成されているため、ユーザは、ゲームＢで特典を得ることを目的としてゲームＡにおいて特典発生条件を満たすように、ゲームＡを第１ゲームを試してみることを動機付けられる。また、本実施形態のゲーム制御装置では、ユーザと他のユーザとのゲームＡ（第１ゲーム）における関係の程度が所定の条件を満たした場合に、そのユーザがゲームＢ（第２ゲーム）において特典が付与されるように構成されているため、ユーザは、ゲームＢで特典を得ることを目的として、他のユーザとのゲームＡにおける関係の程度が所定の条件を満たすようにゲームＡで他のユーザとの間で関係を築き、関係を強化することを動機付けられる。すなわち、本実施形態のゲーム制御装置によれば、例えば既に遊んでいるゲームＢで特典を獲得したいというユーザの願望を、ゲームＡを試してみようという動機付けに結び付けることができるため、ユーザをゲームＡに円滑に誘導することができる。特に、ゲームＢが周知のゲームであり、ゲームＡが新規のゲームである場合には、既にゲームＢを遊んでいるユーザの数が多数であるため、ゲームＡに誘導する上での効果が高い。

本実施形態で説明した連動キャンペーンによってゲームＢにおける特典を得るに当たって、ユーザは、ゲームＡ又はゲームＢで連動キャンペーンについてエントリーする手続きを設けることを要しない。特別な手続きを行うことなくゲームＡを開始し、特典発生条件を満たした場合には、仮にユーザが連動キャンペーンの存在を知らない場合であってもゲームＢにおける特典が付与される。

ゲームＡ（第１ゲーム）のユーザ登録者数（ユーザ登録済みのユーザ数）が、ゲームＢ（第２ゲーム）のユーザ登録者数よりも少ない場合には、本実施形態にて説明したように、提供手段５４は、特典データ（第１情報）を一時的に特典データキュー（バッファ）に記憶させ、特典データキュー内の特典データをゲームサーバ２０ｂ（第２ゲーム制御装置）へ送信し、当該送信が完了するまで特典データの再送を繰り返すことが好ましい。
ゲームＡのユーザ登録者数が、ゲームＢのユーザ登録者数よりも少ない場合、ゲームサーバ２０ａは、例えばメモリ容量や演算能力等の処理能力がゲームサーバ２０ｂよりも低いもので済む。つまり、ユーザ登録者数の増加に応じて装置の処理能力を高めていくのが合理的であるため、特にゲームＡが新規のゲームであってユーザへのサービスが開始されて間もない時期では、ゲームサーバ２０ａは比較的少量のユーザに対する処理能力を備えていればよい。
他方、従来であれば特定のゲームでユーザに特典を付与する場合、そのゲームを実行するゲーム制御装置が、ユーザごとに特典を付与するか否かについての条件を判定していた。しかしながら、本実施形態において、仮に、ゲームＢの多数のユーザ登録済みのユーザの各々について、特典発生条件を満たすか否かを判定するために、ゲームサーバ２０ｂから処理能力の低いゲームサーバ２０ａへアクセスを行うようにしたならば、ゲームＢのユーザ登録数が多いために、処理能力の低いゲームサーバ２０ａにおいて輻輳状態が発生する可能性がある。特にソーシャルゲームの場合には、数十万〜数百万人の登録者を擁するゲームがあるが、仮にそれがゲームＢであった場合に、その一部の登録者であってもゲームＡのゲームサーバ２０ａに特典発生条件を満足したか否かの確認を行なう操作を行えば、ゲームＡのゲームサーバ２０ａに過大な負荷がかかり、対応できない状態になることが想定される。そこで、ゲームサーバ２０ｂ側からゲームＡのゲームサーバ２０ａに対して特典発生条件を満足したか否かの確認を行うのではなく、本実施形態のゲームサーバ２０ａでは、特典発生条件を満たしたことを示す特典データを一時的にバッファに記憶させ、当該バッファ内の特典データをゲームサーバ２０ｂへ送信し、当該送信が完了するまで特典データの再送を繰り返すようにする。これによって、比較的少量のユーザ登録済みのユーザの各々について、処理能力の高いゲームサーバ２０ｂにアクセスする構成となるため、上記輻輳状態の発生を回避することができる。

上記ゲーム制御装置において、特典発生条件は特に限定されるものではないが、図９のウェブページＰ２ａに例示したように、ユーザによるゲームＡ（第１ゲーム）の進行レベルが所定値に達することであることが好ましい。進行レベルを判定の基準とすることで、ユーザはゲームＢ（第２ゲーム）において特典を得るために、ゲームＡを進行させる上での定量的な目標を持つことができ、ゲームＡを試してみようという意識付けを明確にさせることができる。
なお、判定対象の進行レベルは、ゲームＡ自体の進行レベルに限られず、ゲームＡにおける特定のイベント（例えば、期間限定のゲーム内イベント）であってもよい。この場合、例えば、ゲームＡを遊んだことがあるがゲームＡ内の特定のイベントに参加していないユーザを、その特定のイベントに誘導することができる。

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

（８−１）変形例１
上述した実施形態において、ゲームＡ（第１ゲーム）のユーザ登録者数（ユーザ登録済みのユーザ数）が、ゲームＢ（第２ゲーム）のユーザ登録者数よりも少ない場合には、提供手段５４は、ユーザの入力を契機として、特典データ（第１情報）をゲームＢのゲームサーバ２０ｂ（第２ゲーム制御装置）に送信してもよい。
上述したように、ゲームＡ（第１ゲーム）のユーザ登録者数（ユーザ登録済みのユーザ数）が、ゲームＢ（第２ゲーム）のユーザ登録者数よりも少ない場合、ゲームＡのゲームサーバ２０ａは、例えばメモリ容量や演算能力等の処理能力がゲームＢのゲームサーバ２０ｂよりも低いもので済む。そして、ゲームＡのゲームサーバ２０ａは、特典発生条件を満たしたことを示す特典データを、ユーザの入力を契機としてゲームＢのゲームサーバ２０ｂに送信する。これによって、比較的少量のユーザ登録済みのユーザの各々について、処理能力の高いゲームＢのゲームサーバ２０ｂにアクセスする構成となるため、ゲームＡのゲームサーバ２０ａにおける輻輳状態の発生を回避することができる。

本変形例の実現例について、図１９及び図２０を参照して説明する。図１９は、実施形態の変形例において、ゲームＢとの連動キャンペーンの内容を表示するときのウェブページの例を示す図ある。図２０は、実施形態の変形例において、ユーザがゲームＡにおいて、連動キャンペーンの特典発生条件の判定結果に基づく処理を示すシーケンスチャートである。

本変形例では、図１９に示すように、ゲームＡのウェブページＰ１ａ上でメニューｍ５が選択操作されると、Ｐ２ａに示すようにウェブページが更新される。このウェブページＰ２ａの表示領域２０５には、既にユーザが満たした各特典発生条件について、特典データをゲームサーバ２０ｂへ送信済みである場合には「済み」というテキストが表示され、特典データをゲームサーバ２０ｂへ送信済みでない場合にはメニューｍ３０（「送信する」）が表示される。ウェブページＰ２ａにおいてメニューｍ３０が選択操作されると、特典データがゲームサーバ２０ｂへ送信され、送信が正常に完了すると、選択操作されたメニューｍ３０が「済み」というテキストに切り替わる。

図２０において、ユーザＵ１がゲームＡのウェブページ上で何らかの選択操作（例えば、クエストを実行する図１０のメニューｍ１０又はｍ１１の選択操作）を行うと、その選択操作結果を含むＨＴＴＰリクエストが通信端末１０からゲームサーバ２０ａに送信される（ステップＳ４００）。ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベースにアクセスして、「００」（特典発生条件を満たさない）のデータが書き込まれている各特典発生条件をユーザＵ１が満たすか否か判定する（ステップＳ４１０）。例えば、ゲームＡにおいて進行レベルがＬｖ２に達したことが特典発生条件である場合には、ゲームサーバ２０ａのＣＰＵ２１は、ユーザＵ１のユーザデータを参照してユーザＵ１の進行レベルがＬｖ２以上であるか否かを判定する。「００」のデータが書き込まれているいずれかの特典発生条件を満たす場合には（ステップＳ４１０：ＹＥＳ）、ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベース（特典管理ＤＢ）内の該当する特典発生条件のデータを「１０」（特典発生条件を満たし、かつ特典データが未送信）に書き換えることによって、特典管理データベースを更新する（ステップＳ４２０）。「００」のデータが書き込まれている特典発生条件を満たさない場合には（ステップＳ４１０：ＮＯ）、特典管理データベースを更新しない。
次いで、ゲームサーバ２０ａのＣＰＵ２１は、ステップＳ２００のＨＴＴＰリクエストに基づく処理結果を含むＨＴＭＬデータを生成し（ステップＳ４３０）、ユーザＵ１の通信端末１０へ送信する（ステップＳ４４０）。ユーザＵ１の通信端末１０は、受信したＨＴＭＬデータを解釈してウェブページを表示する（ステップＳ４５０）。

本変形例では、図１６に示した実施形態のシーケンスチャートとは異なり、特典発生条件を満たした場合に自動的に特典データが送信されない。つまり、特典発生条件を満たした時点では、特典管理データベースが更新されるに過ぎない。
特典発生条件を満たした後の任意のタイミングで、ユーザがキャンペーンページ（図１９のウェブページＰ２ａ）にアクセスして、既に満たしたいずれかの特典発生条件に対応するメニューｍ３０（「送信する」）を選択操作すると、通信端末１０は、その選択操作結果を含むＨＴＴＰリクエストをゲームサーバ２０ａへ送信する（ステップＳ４６０）。ＨＴＴＰリクエストを受信すると、ゲームサーバ２０ａのＣＰＵ２１は、特典管理データベースにアクセスして、「１０」（特典発生条件を満たし、かつ特典データが未送信）が書き込まれている特典発生条件に対応した特典データを生成する（ステップＳ４７０）。次いでゲームサーバ２０ａのＣＰＵ２１は、特典データを含むリクエストがゲームサーバ２０ｂのＡＰＩサーバ２６へ送信されるように、ＡＰＩサーバ２６を制御する（ステップＳ４８０）。なお、ゲームサーバ２０ａのＡＰＩサーバ２６は、ゲームサーバ２０ｂのＡＰＩサーバ２６から、特典データの受信結果（受信成功、又は受信失敗）を含むレスポンスを受信する。

ゲームサーバ２０ｂのＣＰＵ２１は、ＡＰＩサーバを介して特典データを受信すると、受信した特典データに基づいてプレゼントデータベース（プレゼントＤＢ；図７参照）に新たなデータを書き込むことによって、プレゼントデータベースを更新する（ステップＳ４９０）。その場合、ゲームサーバ２０ｂのＣＰＵ２１は、特典データに含まれるユーザＩＤに対応する「発生原因」の項目に、連動キャンペーンによる特典であることを示すコードを書き込み、「プレゼント内容」の項目に、特典データに含まれる特典の内容（例えば、カードの種類を示す識別子等）を書き込み、「受取状態」の項目に「０」（受取未）を書き込む。
ゲームサーバ２０ａのＣＰＵ２１は、特典データの送信が正常に終了すると、特典管理データベースにアクセスして、送信が完了した特典データに対応するデータを「１０」（特典発生条件を満たし、かつ特典データが未送信）から「１１」（特典発生条件を満たし、かつ特典データが送信済み）に書き換えることによって、特典管理データベースを更新する（ステップＳ５００）。ゲームサーバ２０ａのＣＰＵ２１は、ステップＳ４６０のＨＴＴＰリクエストに基づく処理結果を含むＨＴＭＬデータを生成し（ステップＳ５１０）、生成したＨＴＭＬデータをユーザＵ１の通信端末１０へ送信する（ステップＳ５２０）。ユーザＵ１の通信端末１０は、受信したＨＴＭＬデータを解釈してウェブページを表示する（ステップＳ５３０）。

（８−２）変形例２
上述した実施形態のゲーム制御装置において、提供手段５４は、複数のユーザについての特典データ（第１情報）を、所定時間毎に一斉送信してもよい。
上述した実施形態のゲーム制御装置では、判定手段５３により特典発生条件（所定の条件）を満たすと判定された場合に、直ちに特典データ（第１情報）を特典データキューに書き込み、ゲームサーバ２０ｂ（第２ゲーム制御装置）へ送信するため、ゲームサーバ２０ｂは、その都度特典データを受信し、受信した特典データに基づく処理（プレゼントデータベースへの書き込み等）が必要となる。これに対し、本変形例では、複数のユーザについての特典データを所定時間毎に一斉送信するため、ゲームサーバ２０ｂは、既知の時刻に複数の特典データをまとめて処理することが可能となり、定常的な負荷を減らすことができる。特典データを送信する時刻は、特に限定されないが、夜中等、定常的な負荷が低い時間帯（つまり、ユーザからのアクセスが比較的少ない時間帯）に設定することが好ましい。

本変形例の実現例について、図２１を参照して説明する。図２１は、実施形態の変形例において、ユーザがゲームＡにおいて、連動キャンペーンの特典発生条件の判定結果に基づく処理を示すシーケンスチャートである。なお、図２１において、図２０と同一の処理については同一の符号を付し、重複説明を行わない。
図２１において、ゲームＡのゲームサーバ２０ａのＣＰＵ２１は、例えば毎日所定時刻になると（ステップＳ６００：ＹＥＳ）、特典管理データベースにアクセスして、すべてのユーザを対象として、「１０」（特典発生条件を満たし、かつ特典データが未送信）が書き込まれている特典発生条件に対応した複数の特典データを生成する（ステップＳ６１０）。次いでゲームサーバ２０ａのＣＰＵ２１は、複数の特典データを含むリクエストがゲームサーバ２０ｂのＡＰＩサーバ２６へ送信されるように、ＡＰＩサーバ２６を制御する（ステップＳ６２０）。なお、ゲームサーバ２０ａのＡＰＩサーバ２６は、ゲームサーバ２０ｂのＡＰＩサーバ２６から、特典データの受信結果（受信成功、又は受信失敗）を含むレスポンスを受信する。
例えば、ステップＳ６００における所定時刻を毎日午前３時と午後３時に設定した場合には、午前３時から午後３時までの判定結果に基づいて午後３時に特典データが一斉に送信され、午後３時から次の午前３時までの判定結果に基づいて次の午前３時に特典データが一斉に送信されることになる。

ゲームサーバ２０ｂのＣＰＵ２１は、ＡＰＩサーバを介して複数の特典データを受信すると、受信した複数の特典データに基づいてプレゼントデータベース（プレゼントＤＢ；図７参照）に新たなデータを書き込むことによって、プレゼントデータベースを更新する（ステップＳ６３０）。ゲームサーバ２０ａのＣＰＵ２１は、複数の特典データの送信が正常に終了すると、特典管理データベースにアクセスして、送信が完了したすべての特典データに対応するデータを「１０」（特典発生条件を満たし、かつ特典データが未送信）から「１１」（特典発生条件を満たし、かつ特典データが送信済み）に書き換えることによって、特典管理データベースを更新する（ステップＳ６４０）。

（８−３）変形例３
上述した実施形態のゲーム制御装置において、ゲームＢにおいて付与される特典は、進行レベルが上昇するにつれて増加するものであってもよい。
この構成では、ゲームＡ（第１ゲーム）を進行させるほどユーザがゲームＢ（第２ゲーム）で得られる特典が増加するため、ゲームＢでより多くの特典を得ることを動機付けとして、ゲームＡに対するユーザの遊戯意欲をより一層高めることができるようになる。

本変形例を実現するために、ユーザのゲームＡの進行の程度とゲームＢの特典の対応関係は適宜設定されてよいが、一例を挙げれば以下のようにすることができる。
ゲームＡの進行の程度 ゲームＢにおける特典
チュートリアル終了 → 回復薬１個
進行レベルＬｖ２達成 → 回復薬２個
進行レベルＬｖ５達成 → 回復薬３個
進行レベルＬｖ８達成 → 回復薬４個

（８−４）変形例４
上述した実施形態のゲーム制御装置において、提供手段５４は、ユーザのゲームＢ（第２ゲーム）へのユーザ登録の有無とは無関係に、ゲームＡの特典データ（第１情報）をゲームサーバ２０ｂに提供し、通知手段５５は、ユーザのゲームＢ（第２ゲーム）へのユーザ登録の有無とは無関係に、ユーザに通知してもよい。
この構成では、ユーザがゲームＡについて特典発生条件を満たした時点で、そのユーザについてゲームＢへのユーザ登録が無い場合であっても、その後にゲームＢへのユーザ登録を済ませた場合には、ゲームＢにおいて特典がユーザに付与されるようになる。
本変形例を実現する場合、ゲームＢのゲームサーバ２０ｂのＣＰＵ２１は、受信した特典データに含まれるユーザＩＤに対応する、ゲームＢのユーザＩＤを認識できない場合（例えば、ゲームＢのユーザデータベースに、対応するユーザＩＤが存在しない場合）、プレゼントデータベースを更新することができないため、例えばデータベースサーバ３０ｂのゲームデータベース３２に特典データを記憶させておく。その後、ユーザがゲームＢにユーザ登録を行い、記憶させておいた特典データに含まれるユーザＩＤを認識できるようになったときに、ゲームサーバ２０ｂのＣＰＵ２１は、その特典データの内容をプレゼントデータベースに反映する。

（８−５）変形例５
上述した実施形態のゲーム制御装置において、判定手段５３は、ユーザの登録情報に基づいて、判定の対象となるユーザを制限してもよい。
判定の対象となるユーザが制限されることで、ゲームＡのゲームサーバ２０ａにおいて判定の処理負荷を低減させることができる。さらに、ユーザの制限がユーザの登録情報に基づいて行われるため、処理負荷を低減させつつ、対象とするユーザを効率的にゲームＡ（第１ゲーム）に誘導することができる。
本変形例を実現するために、ゲームサーバ２０ａは、ユーザの性別、年令、住所、職業、端末の個体識別情報、メールアドレスなどの登録情報を、ユーザ登録のときのユーザ入力によって取得するか、あるいは各ゲームサーバ２０の上位サーバ（例えば、ゲームのプラットフォームを提供する提供者のサーバ；図示せず）においてユーザの登録情報を記憶している場合には、その上位サーバからＡＰＩサーバ２６を介して登録情報を取得する。
ゲームサーバ２０ａのＣＰＵ２１は、登録情報に基づく既知のユーザ特定方法に従って、ユーザを特定する。ゲームサーバ２０ａのＣＰＵ２１は、ユーザのユーザ登録時に、ユーザ特定方法に従ってユーザを特定し、特定したユーザを特典管理データベースで管理するようにする。よって、管理対象でない（つまり、特定されなかった）ユーザは、特典発生条件を満たした場合でも、特典データが送信されることはなく、ゲームＢにおける特典が得られない。

本変形例において、ユーザの登録情報は、ユーザの性別又は年令であることが好ましい。つまり、上記既知のユーザ特定方法を、ユーザの登録情報がユーザの性別又は年令の少なくともいずれかが一定の基準を満たすようにユーザを特定する方法とする。
例えば、ユーザの特定方法は、ユーザの性別が女性であることを条件としてユーザを特定する方法とすることができる。ゲームＡ（第１ゲーム）が女性向けのゲームである場合、女性のユーザの方が男性のユーザよりもゲームＡを試してみようとする意識が高いと考えられる。この場合、登録情報に基づいて、判定の対象となるユーザを女性に限定することで、判定の処理負荷を低減させつつ、ゲームＡの対象となる女性ユーザを効率的にゲームＡに誘導することができるようになる。また、ゲームＡ（第１ゲーム）に登場するキャラクタが動物や昆虫等である場合に、判定の対象となるユーザを中学生以下（中学生相当の年令以下）に限定するようにしてもよい。

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

上述した各実施形態では、ユーザによる通信端末に対する所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。

上述した実施形態では、ゲームサーバ２０間の通信や、ゲームサーバ２０と上位サーバの間の通信がＷｅｂＡＰＩによるＨＴＴＰを利用して行われる場合について説明したが、これに限られない。公知の有線又は無線の通信プロトコルを適宜利用してよい。

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

上述した各実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図１３（ａ）に示す各機能を実現する構成としたが、この構成に限られない。これらの手段のうち少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。図２２（ａ），（ｂ）には、本実施形態のゲーム制御装置の各機能（図１３（ａ）に示す各機能）について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間の分担例を示す。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム実行手段
５３…判定手段
５４…提供手段
５５…通知手段
６１…登録手段
６２…ゲーム実行手段
６３…付与手段

Claims (11)

1. 第１ゲームを実行する実行手段と、
   ユーザによる前記第１ゲームの実行状況、又は前記ユーザと他のユーザとの前記第１ゲームにおける関係の程度が所定の条件を満たすか否かを判定する判定手段と、
   前記判定手段により前記所定の条件を満たすと判定された場合に、前記ユーザについて前記所定の条件を満たしたことを示す第１情報を、第２ゲームを実行する第２ゲーム制御装置に提供する提供手段と、
   前記判定手段により前記所定の条件を満たすと判定された場合に、前記第２ゲームにおいて特典が付与されることを前記ユーザに通知する通知手段と、
   を備え、
   前記判定手段は、ユーザの登録情報に基づいて、判定の対象となるユーザを制限することを特徴とする、
   ゲーム制御装置。
2. 前記第１ゲーム及び前記第２ゲームは、ユーザ登録の完了後にユーザが実行可能となるゲームであって、前記第１ゲームにおいてユーザ登録済みのユーザ数が、前記第２ゲームにおいてユーザ登録済みのユーザ数よりも少なく、
   前記提供手段は、前記第１情報を一時的にバッファに記憶させ、当該バッファ内の前記第１情報を前記第２ゲーム制御装置宛に送信し、当該送信が完了するまで前記第１情報の再送を繰り返すことを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記第１ゲーム及び前記第２ゲームは、ユーザ登録の完了後にユーザが実行可能となるゲームであって、前記第１ゲームにおいてユーザ登録済みのユーザ数が、前記第２ゲームにおいてユーザ登録済みのユーザ数よりも少なく、
   前記提供手段は、前記ユーザの入力を契機として、前記第１情報を前記第２ゲーム制御装置に送信することを特徴とする、
   請求項１に記載されたゲーム制御装置。
4. 前記提供手段は、複数のユーザについての前記第１情報を、所定時間毎に一斉送信することを特徴とする、
   請求項１に記載されたゲーム制御装置。
5. 前記所定の条件は、前記ユーザによる前記第１ゲーム、又は第１ゲームについての特定のイベントの進行の程度を示すレベルが所定値に達することであることを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記特典は、前記レベルが上昇するにつれて増加することを特徴とする、
   請求項５に記載されたゲーム制御装置。
7. 前記第１ゲーム及び前記第２ゲームは、ユーザ登録の完了後にユーザが実行可能となるゲームであって、
   前記提供手段は、前記ユーザの前記第２ゲームへのユーザ登録の有無とは無関係に、前記第１情報を提供し、
   前記通知手段は、前記ユーザの前記第２ゲームへのユーザ登録の有無とは無関係に、前記ユーザに通知することを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. 前記登録情報は、ユーザの性別又は年令であることを特徴とする、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. コンピュータに、
   第１ゲームを実行する機能、
   ユーザによる前記第１ゲームの実行状況、又は前記ユーザと他のユーザとの前記第１ゲームにおける関係の程度が所定の条件を満たすか否かを判定する機能、
   前記所定の条件を満たすと判定された場合に、前記ユーザについて前記所定の条件を満たしたことを示す第１情報を、第２ゲームを実行する第２ゲーム制御装置に提供する機能、及び、
   前記所定の条件を満たすと判定された場合に、前記第２ゲームにおいて特典が付与されることを前記ユーザに通知する機能、
   を実現させるためのプログラムであって、
   前記判定する機能は、ユーザの登録情報に基づいて、判定の対象となるユーザを制限することを特徴とする、プログラム。
10. 通信端末からのアクセスに応じて第１ゲームを実行する第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行する第２サーバとの間のゲーム制御方法であって、
    第１サーバが、ユーザによる前記第１ゲームの実行状況、又は前記ユーザと他のユーザとの前記第１ゲームにおける関係の程度が所定の条件を満たすか否かを判定するステップと、
    第１サーバが、前記所定の条件を満たすと判定された場合に、前記ユーザについて前記所定の条件を満たしたことを示す第１情報を、第２サーバに提供するステップと、
    第１サーバが、前記所定の条件を満たすと判定された場合に、前記第２ゲームにおいて特典が付与されることを前記ユーザに通知するステップと、
    第２サーバが、前記第１情報に基づいて、前記ユーザに対して前記第２ゲーム上の特典を付与するステップと、
    を含み、
    前記判定するステップは、ユーザの登録情報に基づいて、判定の対象となるユーザを制限することを特徴とする、ゲーム制御方法。
11. 通信端末からのアクセスに応じて第１ゲームを実行する第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行する第２サーバと、を含むゲームシステムであって、
    第１サーバは、
    ユーザによる前記第１ゲームの実行状況、又は前記ユーザと他のユーザとの前記第１ゲームにおける関係の程度が所定の条件を満たすか否かを判定する判定手段と、
    前記判定手段により前記所定の条件を満たすと判定された場合に、前記ユーザについて前記所定の条件を満たしたことを示す第１情報を、第２サーバに提供する提供手段と、
    前記判定手段により前記所定の条件を満たすと判定された場合に、前記第２ゲームにおいて特典が付与されることを前記ユーザに通知する通知手段と、を備え、
    第２サーバは、
    前記第１情報に基づいて、前記ユーザに対して前記第２ゲーム上の特典を付与する付与手段、を備え、
    前記判定手段は、ユーザの登録情報に基づいて、判定の対象となるユーザを制限することを特徴とする、ゲームシステム。

Images