JP2014140571A - ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム - Google Patents

Abstract

【課題】ゲーム内の複数の処理に対するユーザの操作負担の軽減を図る。
【解決手段】ゲーム管理装置は、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段７１を備えている。前記自動処理は、自動売却処理、自動合体処理、自動プレゼント処理等、複数存在する。ゲーム管理装置は、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段７２と、ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段７３と、を備えている。
【選択図】図３３

Description

本発明は、ゲームを管理するゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムに関するものである。

従来から、インターネット上に設置されたゲームサーバに、ユーザの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、ユーザがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある。

また、インターネット等を介して共通のゲームをプレイするユーザ同士が、アイテム等を相手にプレゼントすることができるゲームシステムも提案されている（特許文献１および２参照）。

そして近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）のシステムに、前記ゲームシステムが組み込まれ、ＳＮＳのサービスの一つとして提供される、いわゆるソーシャルゲームが普及している。このようなソーシャルゲームにおいては、各ユーザがゲームサービスを利用している他のユーザと仲間になり、仲間同士でプレゼントのやり取りをする等、ユーザ同士が交流を行うことができるようになっている。

また、通常、ゲーム内には様々なゲームモードがあり、ユーザは、ゲーム内で入手したアイテムを売却してポイントを獲得したり、そのポイントを使用してアイテムを強化（例えば、アイテム同士を合体）したりすることもできる。

特開２００１−１２９２４０号公報 特開２０１１−１１０１３９号公報

上記のように、ゲーム内で入手したアイテムに対して、プレゼント、売却、強化等の複数の処理を実行することができるが、ユーザは実行する処理を選択し、その処理に応じた操作を、手間をかけて行う必要がある。

本発明は、上記に鑑みてなされたものであり、その目的は、ゲーム内の複数の処理に対するユーザの操作負担の軽減を図ることである。

１）本発明の一局面によるゲーム管理装置（1,2,102,302）は、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段（71）と、前記自動処理は複数存在し、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段（72）と、ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段（73）と、を備えている。

この構成のゲーム管理装置は、例えば各ユーザのゲーム端末（端末装置）と通信を行うことができるサーバなどの情報処理装置（コンピュータ）により構成することができる。あるいは、本ゲーム管理装置は、ゲーム端末としての情報処理装置により構成することもできる。あるいは、本ゲーム管理装置は、相互に通信する複数の情報処理装置（サーバ、ゲーム端末）により構成することもできる。

本ゲーム管理装置は、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段を備えている。ここで、自動処理の例としては、以下に示す自動売却処理、自動合体処理、自動プレゼント処理等がある。このように、自動処理は複数存在し、自動処理毎に、実行条件に関する情報が関係付けられている。すなわち、条件関係付け手段が自動処理と実行条件とを関係付けており、ユーザが入手したオブジェクトがどのような条件のものであれば、どの自動処理を実行するのかについての関係付け情報が、記憶装置に記憶されている。そして、ユーザがオブジェクトを入手した場合に、制御手段が、複数の自動処理のうち、実行条件を満たす自動処理を決定し、決定した自動処理を実行させる。

以下に、選手カードを用いた野球のデジタルカードゲームについての自動処理を例示する。なお、各選手カードには５段階のレア度（最低１〜最高５）の何れかが設定されているものとする。また、各選手カードには所属チーム（例えば、日本のプロ野球１２チームの何れか）が設定されているものとする。また、各ユーザも自分のチーム（前記１２チームの何れか）を持っているものとする。

（Ａ）自動売却処理・・・売却処理とは、ユーザ保有のオブジェクトをゲーム内で仮想的に売却して、ゲーム内ポイント、ゲーム内通貨等に変換する処理である。自動売却処理の例としては、ユーザが入手した選手カードが「レア度１」であれば、「チームを問わず（全チーム対象）」、売却してゲーム内ポイントに変換する。

（Ｂ）自動合体処理・・・合体処理とは、ユーザが保有している特定のオブジェクトを、他のオブジェクトと合体させることにより、他のオブジェクトのパラメータを変更させる（能力等の強化を図る）処理である。合体処理の実行には前記売却処理で得られるゲーム内ポイントを必要としてもよい。自動合体処理の例としては、ユーザが事前に強化対象の選手カードを設定しておく。そして、ユーザが入手した選手カードが強化対象の選手カードと「同じチーム」で、且つ「レア度２以下」であれば、自動的に強化対象の選手カードと入手した選手カードとの合体処理を実行する。

（Ｃ）自動プレゼント処理・・・プレゼント処理とは、ユーザが保有している特定のオブジェクトを、ユーザが他のユーザにプレゼントすることによってオブジェクトの所有者を変更する処理である。自動プレゼント処理の例としては、ユーザがプレゼントしたい他のユーザ（例えば仲間Ｂ）を設定しておく。そして、ユーザが入手した選手カードが、仲間Ｂと「同じチーム」で、且つ「レア度３」であれば、その選手カードを自動的に仲間Ｂにプレゼントする。

上記のように、自動処理毎に、それぞれの処理に応じた実行条件に関する情報が関係付けられている。各自動処理に関係付けられる実行条件は、ユーザが任意に設定することもできるし、初期設定（デフォルト）の条件を用いることもできる。例えば、前記（Ａ）〜（Ｃ）の各処理の説明の括弧「…」の中の条件は、初期設定（デフォルト）の条件とすることができる。また、ユーザが、随時、前記条件を任意に設定、変更することができるようにしてもよい。なお、上記では３つの自動処理を例示したが、２つ又は４つ以上の自動処理があってもよい。

ユーザが入手したオブジェクトが、複数の自動処理の条件を満たすこともあり得る。この場合、制御手段が、ランダムに実行する自動処理を決定してもよいし、後述するように予め設定されている優先度に基づいて実行する自動処理を決定してもよい。

なお、ユーザが入手したオブジェクトが、いずれの自動処理の条件も満たさなかった場合、自動処理は実行されることなく、そのオブジェクトはユーザの保有物となる。また、いずれの自動処理についても、それを採用するか否かはユーザが任意で選択できるようにしてもよい。

以上のように、本構成では、自動処理が複数存在し、自動処理毎に、実行条件に関する情報を関係付けるので、それぞれの自動処理に応じた適切な実行条件を任意に設定することができる。そして、ユーザがオブジェクトを入手した場合に、複数の自動処理の中から実行条件を満たす自動処理が決定されて実行されるので、複数の処理に対するユーザの操作負担が軽減される。

２）上記の構成において、前記複数の自動処理に対して、処理の優先順位を示す優先度を予め設定する優先度設定手段（74）をさらに備えていることが好ましい。

この構成によれば、各自動処理に優先度が定められる。そして、ユーザが入手したオブジェクトが各自動処理の対象となるか否かが、例えば制御手段により優先度順に判断される。一例を挙げると、前述の（Ａ）、（Ｂ）、（Ｃ）の自動処理について、この順に優先度が設定された場合、ユーザが入手したオブジェクトについて、（Ａ）→（Ｂ）→（Ｃ）の順に自動処理の対象となるか否かが判断される。そして、該当する自動処理があれば、その処理が実行される。なお、ユーザが入手したオブジェクトによっては、前記の（Ａ）および（Ｂ）の両方の自動処理の実行条件を満足する場合もあるが、より優先度の高い（Ａ）の自動処理の実行条件を満たせば、その段階で（Ａ）の自動処理が実行される。いずれの自動処理の条件も満たさなかった場合、自動処理は実行されることなく、ユーザが入手したオブジェクトは当該ユーザの保有物となる。なお、優先度の設定は、ユーザからの要求に応じて設定することもできるし、初期設定（デフォルト）の優先度を用いることもできる。

本構成により、複数ある自動処理に対してユーザが任意に優先順位をつけることができる。よって、例えば、ゲーム内ポイントが少なくなった場合は（Ａ）自動売却処理を最優先にしたり、他のユーザからプレゼントを貰った場合には（Ｃ）自動プレゼント処理を最優先にしたりできる。

３）上記２）の構成において、ユーザのゲーム状況に応じて、前記優先度を自動的に変更する優先度変更手段（75）をさらに備えることが好ましい。

ここで、ユーザのゲーム状況とは、ユーザが保有するゲーム内ポイント等の保有物の増減の状況、他のユーザからプレゼントを貰った後に返礼のプレゼントをしたか否かの状況等をいう。

例えば、ユーザが優先度を（Ｂ）自動合体処理→（Ａ）自動売却処理→（Ｃ）自動プレゼント処理と設定していても、ゲーム内ポイントが閾値未満になれば、優先度変更手段が優先度を自動的に変更し、例えば（Ａ）自動売却処理→（Ｂ）自動合体処理→（Ｃ）自動プレゼント処理とする。その後、（Ａ）自動売却処理が優先的に実行されたこと等によりゲーム内ポイントが所定値以上になれば、自動的に元のユーザ設定の優先度に戻る。優先度の自動変更の例は、後述の４）〜６）の構成でも説明する。

本構成により、ゲーム管理装置がユーザのゲーム状況に応じて、複数の自動処理に対する優先度を自動的に変更するので、ゲーム状況が変わる都度、ユーザが優先度を変更する操作を行う必要がなくなり、ユーザの操作負担の軽減を図ることができる。

４）上記３）の構成において、前記自動処理には、ユーザの保有物を消費する第１自動処理を含み、前記優先度変更手段（75）は、前記保有物の量が閾値未満の場合に、前記第１自動処理の優先度を、予め設定されている優先度よりも低下させることが好ましい。

ここで、ユーザの保有物とは、ユーザが保有するゲーム内ポイント、アイテム等を言う。また、第１自動処理とは、前述の（Ｂ）自動合体処理を含むが、それに限らない（合体という形態をとらなくてもよい）。例えば、ユーザが入手した選手キャラクタが練習相手となり、ユーザの保有する練習チケットアイテムを消費して、強化対象の選手キャラクタと練習を行うことにより、強化対象の選手キャラクタの能力パラメータを向上させる自動処理も、第１自動処理に含まれる。

本構成の優先度変更手段は、ユーザの保有物の量が閾値未満（閾値＝処理に必要な最低限度のポイントとした場合は、ポイント不足）となるゲーム状況になった場合に、第１自動処理の優先度を、予め設定されている優先度よりも低下させる。例えば、予め設定されている優先度を（Ｂ）自動合体処理→（Ａ）自動売却処理→（Ｃ）自動プレゼント処理とした場合に、（Ｂ）自動合体処理の優先度を２番目または最下位とし、（Ａ）自動売却処理を第１優先にシフトする。なお、ユーザの保有物の量が所定値以上になれば予め設定されている優先度に戻る構成としてもよい。

本構成により、保有物の消費を伴う第１自動処理がある場合に、その保有物が閾値未満になった状況では、当該処理の優先度が自動的に低下し、例えば保有物を増加させる自動処理が優先される状況を自動的に構築することができる。これにより、保有物の減少をユーザが把握して自動処理の優先度を変更する操作を行う必要がなくなり、ユーザの操作負担の軽減を図ることができる。

５）上記３）の構成において、前記自動処理には、ユーザの保有物を消費する第１自動処理と、ユーザが入手したオブジェクトを前記保有物に変換する第２自動処理と、を含み、前記優先度変更手段（75）は、前記保有物の量が第１閾値以上になるまでは、前記第２自動処理の優先度を前記第１自動処理の優先度よりも高くすると共に、前記保有物の量が前記第１閾値以上になった後、前記第１閾値以下の第２閾値よりも小さくなるまで、前記第１自動処理の優先度を前記第２自動処理の優先度よりも高くすることが好ましい。

ここで、前記第２自動処理とは、前述の（Ａ）自動売却処理を含むが、必ずしも売却という形態をとらなくてもよい。この構成によれば、第１自動処理（自動合体処理等）を実行するためにはポイント等の保有物が必要であり、この保有物は第２自動処理（自動売却処理等）によって獲得することができる。そこで、優先度変更手段は、保有物の量が第１閾値（例えば１００００ポイント）以上になるまでは、第２自動処理の優先度を第１自動処理の優先度よりも高くする。そして、第２自動処理が優先的に実行されたこと等により保有物の量が第１閾値以上になった後は、第１閾値以下の第２閾値よりも小さくなるまで（例えば１０００ポイントよりも小さくなるまで又はポイントが不足するまで）、第１自動処理の優先度を第２自動処理の優先度よりも高くする。そして、保有物が第２閾値未満になれば、再び、保有物の量が第１閾値以上になるまで、第２自動処理の優先度を第１自動処理の優先度よりも高くする。

ここで、第１閾値と第２閾値とを同じ値にすることもできるし、第１閾値よりも第２閾値を小さくし、ヒステリシス制御を行うこともできる。

本構成により、保有物を消費する第１自動処理と、保有物を獲得する第２自動処理との優先度を、保有物の増減によって自動的に切り替えることができる。これにより、保有物の増減をユーザが把握して自動処理の優先度を変更する操作を行う必要がなくなり、ユーザの操作負担の軽減を図ることができる。

６）上記３）ないし５）の何れかの構成において、前記自動処理には、第１のユーザが入手したオブジェクトを予め設定している第２のユーザにプレゼントする自動プレゼント処理を含み、前記優先度変更手段（75）は、第２のユーザから第１のユーザにプレゼントが行われた場合であって、第１のユーザから第２のユーザにプレゼントが行われなかった場合に、前記自動プレゼント処理の優先度を、予め設定されている優先度よりも高くすることが好ましい。

ここで、「プレゼント」とは、ユーザがゲーム内で所有しているものを、仮想的に他のユーザに与えること（または与えるもの）を言う。「プレゼント」を、「ギフト（を贈る）」、「贈り物（を贈る）」、「譲渡」等と表現してもよい。

例えば、第２のユーザからプレゼントを受け取った第１のユーザが、相手に返礼する適切なアイテムが手元にない等の理由により、後で返礼しようとすることもある。そこで、第２のユーザから第１のユーザにプレゼントが行われた場合であって、第１のユーザから第２のユーザに返礼のプレゼントが行われなかったという状況が発生した場合に、優先度変更手段は、第１のユーザが入手したオブジェクトを予め設定している第２のユーザにプレゼントする自動プレゼント処理の優先度を、予め設定されている優先度よりも高くし、早期に返礼が実行されるようにする。なお、第２のユーザへの返礼のプレゼントが実行された後には、予め設定されている優先度に戻る構成としてもよい。

本構成により、ユーザが返礼のプレゼントを行わなかった場合に、優先度を変更する操作を行わなくとも自動的に自動プレゼント処理の優先度が高められるので、ユーザの操作負担の軽減を図ることができる。

７）上記２）の構成において、同一の自動処理の実行回数が所定回数に到達した場合、当該自動処理の優先度を、予め設定されている優先度よりも低下させる優先度変更手段（75）をさらに備えていることが好ましい。

この構成によれば、基本的には予め設定されている優先度に従い自動処理が実行されるが、同一の自動処理の実行回数が所定回数（例えば１０回）に到達した場合には、当該自動処理の優先度が１段階または２段階以上低下する。ここで、同一の自動処理が連続して実行された回数が所定回数となった場合にその優先度を低下させてもよいし、同一の自動処理の累積の実行回数が所定回数となった場合にその優先度を低下させてもよい。

例えば、予め設定されている優先度を（Ａ）自動売却処理→（Ｂ）自動合体処理→（Ｃ）自動プレゼント処理とする。ここで、（Ａ）の実行回数が所定回数の１０回になれば、（Ａ）の優先度が例えば最下位に変更される。よって、次回のオブジェクト入手時には、第２優先の（Ｂ）が第１優先とみなされ、先ず（Ｂ）の実行条件を満たすかが判断される。ここで、（Ｂ）の実行条件を満たさなければ、次に（Ｃ）の実行条件を満たすかが判断され、その条件も満たさない場合に（Ａ）に戻って実行条件を満たすかが判断される。

本構成により、優先度をつけながらも、複数の自動処理が万遍なく行われるようにすることができる。

８）本発明の他の一局面によるゲームシステムは、サーバ（1,2,102）と、当該サーバ（1,2,102）との間で通信を行う端末装置（3,302）と、を含むものであって、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段（71）、前記自動処理は複数存在し、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段（72）、ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段（73）、を前記サーバ（1,2,102）又は前記端末装置（3,302）の何れか一方が備える。

９）本発明の他の一局面によるゲーム管理方法は、ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、コンピュータが、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理ステップと、前記自動処理は複数存在し、コンピュータが、自動処理毎に、実行条件に関する情報を関係付ける条件関係付けステップと、ユーザがオブジェクトを入手した場合に、コンピュータが、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御ステップと、を含む。

１０）本発明の他の一局面によるプログラムは、コンピュータを、ゲームを管理するゲーム管理装置（1,2,102,302）として動作させるためのプログラムであって、前記コンピュータを、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段（71）、前記自動処理は複数存在し、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段（72）、ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段（73）、として機能させるためのプログラムある。

本発明によれば、ゲーム内の複数の処理に対するユーザの操作負担の軽減を図ることができる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 ゲームのメイン画面の一例を示す説明図である。 ユーザが入手したカードを表示する画面の一例を示す説明図である。 プレゼント画面の一例を示す説明図である。 自動プレゼント条件設定画面の一例を示す説明図である。 前記図７の画面中のプルダウンメニューの表示例を示す説明図である。 自動プレゼント条件設定画面の他の例を示す説明図である。 自動プレゼント条件設定画面の他の例を示す説明図である。 自動プレゼント条件設定画面の他の例を示す説明図である。 自動プレゼント条件設定画面の他の例を示す説明図である。 前記図１２の画面における設定例を示す説明図である。 仲間リスト画面の一例を示す説明図である。 ゲーム管理装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザのゲーム情報の一例を示す説明図である。 選手データベースの一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の一例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 親密度に基づいて仲間の範囲を設定した自動プレゼント条件の一例を示す説明図である。 ゲームレベルに基づいて仲間の範囲を設定した自動プレゼント条件の一例を示す説明図である。 ゲームへのアクセス頻度に基づいて仲間の範囲を設定した自動プレゼント条件の一例を示す説明図である。 親密度、ゲームレベルおよびゲームへのアクセス頻度を組み合わせて仲間の範囲を設定した自動プレゼント条件の一例を示す説明図である。 個人を特定する情報に基づいて仲間の範囲を設定した自動プレゼント条件の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 自動プレゼント処理を実行するゲームサーバの動作例を示すフローチャートである。 自動プレゼント処理実行時の報知画面の一例を示す説明図である。 自動プレゼント条件設定画面の他の例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 自動プレゼント条件を自動設定するための画面の一例を示す説明図である。 自動プレゼント条件が自動設定されたときに表示される画面例を示す説明図である。 ゲーム管理装置の主要な機能的構成の他の例を示す機能ブロック図である。 プレゼント対象の候補者を報知する画面の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 売却処理前に表示される画面の一例を示す説明図である。 自動売却条件設定画面の一例を示す説明図である。 合体処理前に表示される画面の一例を示す説明図である。 自動合成条件設定画面の一例を示す説明図である。 複数の自動処理に関係付けられた実行条件の一例を示す説明図である。 自動処理を実行するゲームサーバの動作例を示すフローチャートである。 自動売却処理実行時の報知画面の一例を示す説明図である。 自動合体処理実行時の報知画面の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 優先度設定画面の一例を示す説明図である。 優先度に基づいて自動処理を実行するゲームサーバの動作例を示すフローチャートである。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ユーザのゲーム状況に応じた優先度変更処理の一例を示すフローチャートである。 ユーザのゲーム状況に応じた優先度変更処理の他の例を示すフローチャートである。 ユーザのゲーム状況に応じた優先度変更処理の他の例を示すフローチャートである。 自動処理の実行回数に応じた優先度変更処理の一例を示すフローチャートである。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。

以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。

〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各ユーザの端末装置３とによって構成される。

本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成することができる。ゲームサーバ１は、ゲームサービスを受ける各ユーザの端末装置３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ２（記憶装置）に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。

ゲームサーバ１によるゲームサービスの提供の形態としては、ゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ１に実装されており、端末装置３でゲームを実行するのではなく、端末装置３でのゲーム操作入力に応じてゲームサーバ１でゲームを実行し、その実行結果を各ユーザの端末装置３に送信する形態がある。例えば、各ユーザの端末装置３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームをゲームサーバ１が提供する。あるいは、ゲームサーバ１でゲームを実行した結果のゲーム映像を、例えばストリーミング形式で端末装置３に送信する、いわゆるクラウドゲーミングのサービスをゲームサーバ１が提供する。

あるいは、後述するように、ゲーム実行プログラムの一部または全部をユーザの端末装置３側にインストールし、端末装置３においてもゲーム実行処理が行われるようなゲームシステムとすることもできる。

本実施の形態では、ゲームサーバ１によるゲームサービスの提供の一形態として、ブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、ユーザの端末装置３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置３をネットワーク４に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ１から提供されるゲームサービスを楽しむことができる。

このゲームシステムでは、ゲームサーバ１が、各ユーザの端末装置３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ１は、演算処理等の実行結果に基づいてデータベースサーバ２内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置３の画面に表示させるためのウェブページ情報（ゲーム画面データ）を各ユーザの端末装置３に送信する。

各ユーザの端末装置３には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ１から送信されたウェブページ情報を端末装置３の画面に表示することができるようになっている。この端末装置３としては、例えば、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータ（以下「ＰＣ」と呼称する）、タブレット型コンピュータ、通信機能を有するゲーム装置（据置型または携帯型のゲーム装置）または双方向の通信機能を備えた多機能型テレビジョン受像機（いわゆるスマートテレビ）など、ネットワーク４経由でゲームサーバ１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。

また、本実施の形態で提供されるゲームは、ユーザが、ゲームサービスを受けている他のユーザと交流を行いながらプレイすることができる、いわゆるソーシャルゲームの要素を有するものとすることができる。例えば、本実施の形態のゲームサーバ１およびデータベースサーバ２をソーシャルネットワーキングサービス（ＳＮＳ）のシステムに組み込むことによって、ＳＮＳのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにＳＮＳのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。

本実施の形態のゲーム管理装置は、ユーザが事前に設定したプレゼント候補のオブジェクト（キャラクタ、アイテム等）をゲーム内で入手した場合、そのオブジェクトが自動的に仲間にプレゼントされる。さらに、本ゲーム管理装置では、自動プレゼントの対象となる仲間の範囲を定めることができる。すなわち、仲間の範囲と、その範囲の仲間にプレゼントするオブジェクトの条件をユーザが事前に設定しておけば、条件を満たすオブジェクトの入手時に、手間を掛けることなく確実に、そのオブジェクトが自動的に前記範囲内の仲間にプレゼントされる。以下に、これを実現する本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。

〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。図２にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ（Central Processing Unit）１１と、主記憶装置としてのＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１７を介して相互に接続されている。なお、バスライン１７と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲームサーバ１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１７を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。

通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各ユーザの端末装置３との間の通信を制御する。また、通信制御部１５は、ネットワーク４に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ１をＳＮＳに組み込んだシステム構成とした場合、ゲームサーバ１の通信制御部１５は、ＳＮＳサーバとの間の通信を制御する。

入出力制御部１６は、データベースサーバ２と通信可能に接続されており、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。

データベースサーバ２は、ゲームサーバ１が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各ユーザを一意に識別する識別情報（ユーザＩＤ）と対応付けて、各ユーザの各種ゲーム情報（ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。

本実施の形態では、ゲーム管理装置がゲームサーバ１およびデータベースサーバ２から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ１にデータベースサーバ２の機能を持たせて、ゲーム管理装置をゲームサーバ１のみで構成することもできる。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、ユーザが端末装置３を操作してゲームサーバ１へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。

また、本ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザの端末装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。

次に、本実施の形態に係るゲームサーバ１にアクセスしてゲームサービスの提供を受けるユーザの端末装置３の構成を説明する。

〔端末装置の構成〕
ユーザが操作する端末装置３としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯端末を例示してその構成を説明する。なお、携帯端末以外の端末装置３についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯端末と同様である。

ウェブサイト閲覧機能等を有する携帯端末は、フィーチャーフォン（Feature phone）やスマートフォン（Smartphone）等とも呼称され、図３にその構成例を示している。同図に示すように、端末装置３は、主に、ＣＰＵ３１と、主記憶装置としてのＲＯＭ３２及びＲＡＭ３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１とを備えており、構成要素３１〜３４、３６および３９〜４１はバスライン４２を介して相互に接続されている。なお、バスライン４２と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置３全体の制御を行う。ＲＯＭ３２には、端末装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２または補助記憶装置３９からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ＨＴＭＬ等で記述されたゲーム画面データを表示するウェブブラウザは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。

画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイまたは有機ＬＥ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。

サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、端末装置３に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部３８は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。

補助記憶装置３９は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。

操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、端末装置３の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。

また、一般的な音声認識技術を利用して、音声入力部３７から入力された音声をＣＰＵ３１が解析し、各種入力を、音声により行うことができる構成としてもよい。

通信制御部４１は、通信インタフェース４１ａを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線ＬＡＮ接続機能、無線ＬＡＮや携帯電話回線網を介したインターネット接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信制御部４１は、ＣＰＵ３１からの命令に基づいて端末装置３を無線ＬＡＮやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ３１へ供給する。

なお、端末装置３には、その他にもＧＰＳ（Global Positioning System）信号受信回路、ＣＣＤ（Charge Coupled Device）イメージセンサ等の撮像装置（カメラ）、３軸加速度センサなどが備えられていてもよく、例えば、ＧＰＳ位置情報などをゲーム内で活用してもよい。

上記構成の端末装置３において、ゲームサービスを受けようとするユーザは、ウェブブラウザを立ち上げてゲームサーバ１が管理するゲームサイトにアクセスする入力操作を行う。このアクセスがゲームサーバ１に認証された場合、端末装置３の通信制御部４１がゲームサーバ１から送信されてくるＨＴＭＬ等で記述されたゲーム画面データを受信し、ＣＰＵ３１がウェブブラウザを実行してゲーム画面を表示部３５に表示させる。ここでユーザは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部４０を操作して選択入力する。この選択入力に応じてゲームサーバ１がゲームを進行させ、新たなゲーム画面データを端末装置３に送信する。そして、この新たなゲーム画面が端末装置３の表示部３５に表示され、以下、同様に、ユーザは、表示部３５に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ１が提供するゲームをプレイすることができるようになっている。

〔ゲームの説明〕
ゲーム管理装置によって提供されるゲームの例としては、サッカー、野球、テニス、アメリカンフットボール、バスケットボール、バレーボール、ゴルフ、ボクシング、競馬、カーレースなどを題材としたスポーツ・レースゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲーム、さらにはクイズゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、主に、ゲーム管理装置が野球ゲームを管理する例について、以下に説明する。

本実施の形態では、ユーザがゲーム内においてプロ野球（またはＭＬＢ）の実在選手に対応する選手キャラクタを所有し、当該選手キャラクタを用いて自分のチームをつくる野球ゲームを例に挙げる。

ユーザが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置３の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ１で管理されるとともに、ユーザの端末装置３の画面に表示される。また、選手キャラクタは、ゲーム内での試合等において、３次元コンピュータグラフィックスにより描写してもよい。また、ストリーミング形式等により、選手キャラクタやボールオブジェクト等を動画表示してもよい。ユーザは、ゲームを進行させながら選手カード（以下、単に「カード」と称す）を集め、自分だけのオリジナルチームを結成し、他のユーザと対戦することができる。ユーザはゲーム内の「オーダーモード」において、選手の打順およびポジションを設定できる。また、ユーザは、集めたカード同士を合体（合成）することによって、カードに表示されたキャラクタの能力を向上させる（すなわち、キャラクタを育成する）ことができ、より強いチーム作りを目指してゲームを楽しむ。

本実施の形態では、各カードには５段階のレア度（最低１〜最高５）の何れかが設定されている。また、各カードには選手の所属チーム（例えば、日本のプロ野球１２チームの何れか）が設定されている。また、後述するように、各ユーザは前記１２チームのうちの希望する何れか１つのチームを選択して、自分のチームとしている。

図４に、本ゲームのメイン画面（マイページ）の一例を示す。このメイン画面には、ユーザが所有するカードの中からリーダーとして選択された選手のカード２０１、ユーザのゲーム情報２０２（ユーザのレベル、各種ゲーム内ポイント、所有する選手キャラクタの数、仲間人数など）が表示される。カード２０１には、選手キャラクタの形態およびカードのレア度（希少価値の高さを星印の多さで示したもの）等が表記される。

本実施の形態のゲーム内ポイントとしては、行動ポイント、運営コスト、強化ポイント、抽選ポイントなどがある。行動ポイントは、ゲーム内エリア（ステージ）を探索して選手を仮想的にスカウトするという「スカウトモード」で使用されるゲーム進行用ポイントである。運営コストは、試合を運営する場合に必要なコストという位置付けで、他のユーザとゲーム内で試合を行う「試合モード」で使用されるポイントである。例えば、ゲーム中に消費されて減った行動ポイントや運営コストは、時間の経過により回復（例えば、３分経過毎に１ポイントずつ回復）するようにしたり、レベルアップ時または回復アイテムの使用により一気に回復するようにしたりできる。

強化ポイントは、ユーザが所有する複数のカードを合体（合成）することによってキャラクタを強化する「強化モード」で使用されるポイントである。この強化ポイントは、ユーザが保有するカードを売却する等によって獲得できる。抽選ポイントは、抽選でカードを獲得できる「抽選モード」で使用されるポイントである。この抽選ポイントは、ユーザが他のユーザとゲーム内で交流を行う等によって獲得できる。

また、メイン画面には、スカウト、試合、強化、抽選、オーダー、選手管理の各モードを選択するためのボタン群２０３も表示される。さらに、端末装置３の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、図示しない各種メニューボタン、システム運営者からのお知らせなど、様々な情報が表示されるようになっている。

本ゲームでは、ユーザが前述の「スカウトモード」または「抽選モード」を実行することによってカード（オブジェクト）を入手することができる。なお、ユーザがゲーム内で保持できるカードの枚数（選手数）には上限（例えば６０）を設けることができる。

また、本ゲームでは、ユーザが所持しているカードについて、「売却処理」、「合体処理」等を実行することができる。これらの各処理については後述する。

また、本ゲームでは、ユーザが所持しているカード等について、「プレゼント処理」を実行することができる。「プレゼント」とは、ユーザがゲーム内で所有しているものを、仮想的に他のユーザに与えること（または与えるもの）を言う。「プレゼント」を、「ギフト（を贈る）」、「贈り物（を贈る）」、「譲渡」等と表現してもよい。また、プレゼントが行われるユーザ間のゲーム内の仮想的な関係は特に問われない。例えば、ユーザ間の関係が、友人同士、同僚同士、家族同士、ボスと家来、上司と部下、先輩と後輩などであってもよく、何れの関係であっても一方から他方へアイテム等を与えることは、「プレゼント」に含まれる。本実施の形態では、ユーザが手動で仲間等にプレゼントを行うことも、予めプレゼントの条件を設定することによって自動でプレゼントを行うこともできる。

ユーザが手動で仲間にカードをプレゼントする場合の操作の一例を次に示す。ユーザが「抽選モード」等を実行することによってカードを入手した場合、図５に例示する画面に遷移し、入手したカード２１０およびカードの情報２１１が表示される。カードの情報２１１としては、選手名、所属チーム、ポジション、能力値などが含まれる。あるいは、図４のメイン画面において、選手管理ボタン２０３ａを押せば、図示しない選手管理画面に遷移し、ユーザが保持している選手のカード一覧が表示される。ここで、ユーザが特定のカードを指定（選択）すれば、図５の画面に遷移し、指定されたカード２１０およびカードの情報２１１が表示される。図５の画面には、売却ボタン２１２およびプレゼントボタン２１３等も表示される。売却ボタン２１２は、画面に表示されているカード２１０を売却するためのボタンである。また、プレゼントボタン２１３は、画面に表示されているカード２１０を他人へプレゼントするためのボタンである。

図５の画面でユーザが前記プレゼントボタン２１３を押せば、図示しないプレゼント画面に遷移し、仲間の一覧が表示される。ユーザが、仲間の中から贈る相手を指定すれば、図６のプレゼント画面に遷移する。この画面には、プレゼント対象のオブジェクトの表示領域２１８および贈る相手の表示領域２１９が設けられる。表示領域２１８には、プレゼント対象のカード２１０、そのカードの情報２１１、そのカードのユーザの所持数の情報２１４等が表示される。また、表示領域２１９には、贈る相手として選択した仲間の情報２１５（仲間のアバター、名前、レベル、チーム等）、その仲間に送るメッセージの入力領域２１６、贈るボタン２１７等が表示される。ここで、ユーザが贈るボタン２１７を押せば、表示されているカード２１０を仲間に贈ることができる。また、メッセージの入力領域２１６に任意のメッセージを入力している場合、プレゼントと併せてメッセージも相手に届けられる。この場合、ゲームサーバ１は、ユーザからプレゼントが届いた旨を仲間の端末装置３に報知する。

このように、ユーザが手動で仲間にプレゼントをするには、面倒な作業が必要である。これに対して、以下に説明する自動プレゼントは、プレゼント対象の仲間の範囲とその仲間にプレゼントするオブジェクトの条件とを予め設定しておくだけで、ゲームサーバ１が自動的にプレゼント処理を実行するので、ユーザの操作負担を大幅に軽減できる。

プレゼント対象の「仲間の範囲」は、「ユーザとの親密度」、「仲間のゲーム内レベル」、「仲間のゲームへのアクセス頻度」等の「仲間に関するゲーム情報」に基づいて定めることができる。あるいは、「仲間の範囲」は、仲間のユーザＩＤやユーザ名等の「個人を特定する情報」に基づいて定めることもできる。

先ず、「仲間の範囲」を、「ユーザとの親密度」に基づいて定める例について説明する。ここで、親密度とは、仲間関係が成立している２人のユーザの親密さを示すものであり、２人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。

例えば、２人の親密度は、ゲーム内の交流の回数や頻度に基づいて設定でき、ユーザが仲間と交流するほど、その仲間との親密度は高くなる。ゲーム内の交流の例としては、挨拶、メッセージ送信、プレゼント、対戦協力、チャットなどが挙げられるが、これに限らず、ゲームの種類や内容に応じて様々な交流を適用できる。ここで、挨拶とは、ボタンを押す等の簡単な操作だけでゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール（応援）を送る、ガッツ（やる気）を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。ゲームサーバ１は、仲間関係にある２人の親密度を、データベースサーバ２に記憶して管理している。例えば、親密度は、最低１〜最高５の５段階で表される。なお、親密度付与処理の詳細は後述する。

図７には、ユーザが親密度によって仲間の範囲を指定した上で、プレゼントするオブジェクトの条件を任意に設定するための自動プレゼント条件設定画面の一例を示す。この画面には、仲間指定領域２２１および条件設定領域２２２が設けられている。

仲間指定領域２２１では、親密度の範囲を指定するための入力部２２３・２２４が表示され、プルダウンメニューから親密度の値を選択して仲間の範囲を指定できる例を示している。例えば、入力部２２３で「３」を選択し、入力部２２４を空白（未選択）とした場合、「親密度３以上」を設定することができる。また、例えば、入力部２２３を空白とし、入力部２２４で「３」を選択した場合、「親密度３以下」を設定することができる。また、例えば、入力部２２３で「２」を選択し、入力部２２４で「４」を選択した場合、「親密度２〜４」を設定することができる。

なお、範囲指定の入力方法はこれに限定されるものではなく、例えば親密度の値を端末装置３におけるキー入力、音声入力（音声認識による入力）等により直接入力できるようにしてもよい。

また、条件設定領域２２２では、仲間指定領域２２１で指定した親密度の仲間にプレゼントするカードの条件を設定できる。例えば、条件設定領域２２２には、「自分のチーム以外の選手カード（レア度３以下）」、「レア度２以下の全ての選手カード」、「レア度３の全ての選手カード」等の条件項目が予め表示されている。そして、ユーザがチェックボックス等により条件項目を選択するだけで簡単に条件を設定できるようになっている。

また、条件設定領域２２２には、チームおよびレア度の条件を設定するための入力部２２５〜２２７（プルダウンメニュー）を設けてもよい。図８に入力部２２５〜２２７のプルダウンメニューの表示例を示す。カードのチーム条件を設定する入力部２２５には、「自分のチーム以外」、「相手のチーム」、「全てのチーム」、「セ・リーグ」、「パ・リーグ」および特定のチーム（プロ野球の１２チームの何れか）を指定できる選択肢が表示される。また、カードのレア度条件を設定する入力部２２６には、レア度１〜５の選択肢が表示される。また、入力部２２７には、「以上」、「以下」を指定できる選択肢が表示される。例えば、入力部２２６で「３」を選択し、且つ、入力部２２７で「以下」を選択すれば、レア度「３以下」を設定したことになる。このケースで、「以上」および「以下」のいずれも選択しない（空白とした）場合、レア度「３」を設定したことになる。

また、図７の自動プレゼント条件設定画面には設定ボタン２２８が設けられ、このボタンを押すことにより、ユーザの端末装置３から設定情報がゲームサーバ１に送信される。ゲームサーバ１では、前記設定情報を受信し、ユーザＩＤと対応付けて、プレゼント対象の仲間の範囲とその仲間にプレゼントするカードの条件とをデータベースサーバ２に記憶する。

上記のようにしてユーザが予め自動プレゼントの条件（仲間の範囲およびカード条件）を設定しておけば、その条件を満たすカードをユーザが入手した場合、ゲームサーバ１は、前記範囲内の仲間に当該カードを自動的にプレゼントする。該当する仲間が複数いる場合は、その中からランダムに選択した仲間にプレゼントしてもよいし、親密度の高い仲間から、順次、プレゼントしてもよい。

上記では、自動プレゼントのカード条件として、チームの条件およびレア度の条件を適用できる例を示したが、これに限定されるものではない。例えば、ポジション（投手、野手、一塁手、二塁手、…）の条件を、単独で、またはチーム、レア度等の条件と組み合わせて、適用できるようにしてもよい。例えば、カード条件として投手のポジションを設定すれば、ユーザが投手のカードを入手した場合に、当該カード条件と対応づけられている範囲の仲間に自動的にプレゼントされる。

また、「ユーザが入手したカードが、相手が保有していないカードの場合のみ、自動プレゼントする」という条件を、単独で、または他の条件と組み合わせて、適用できるようにしてもよい。これは、相手が既に保有しているカードと同じカードを贈っても、相手に喜んでもらえないこともあるので、ユーザが当該条件を任意に設定できるようにするものである。また、「ユーザが入手したカードが、相手が保有しているカードと同じカードの場合のみ、自動プレゼントする」という条件を、単独で、または他の条件と組み合わせて、適用できるようにしてもよい。これは、相手が手放すことなく保有しているカードは、相手の好みのカードであると考えて、ユーザが当該条件を任意に設定できるようにするものである。この条件設定により、相手がどのようなカードを所有しているかによって、自動プレゼント処理の実行の有無を切り替えることが可能となる。

また、「ユーザが入手したカードが、自分が保有しているカードと同じカードの場合のみ、自動プレゼントする」という条件を、単独で、または他の条件と組み合わせて、適用できるようにしてもよい。これは、自分が既に保有しているカードを重複して入手した場合、そのカードは自分では不要（またはそれほど重要でない）と考えて、ユーザが当該条件を任意に設定できるようにするものである。また、「ユーザが入手したカードが、自分が保有していないカードの場合のみ、自動プレゼントする」という条件を適用できるようにしてもよい。」これは、同じカードを集めているユーザが当該条件を任意に設定できるようにするものである。この条件設定により、ユーザ自身がどのようなカードを所有しているかによって、自動プレゼント処理の実行の有無を切り替えることが可能となる。

前記の自動プレゼント条件設定画面での操作により、異なる仲間の範囲には、異なるカードの条件を設定することができる。例えば、親密度が所定以上の仲間と、それよりも低い仲間とで、仲間にプレゼントするカードの条件を次のように異ならせることができる。すなわち、親密度が高い仲間には、親密度の低い仲間よりも、より良い（レア度の高い）カードが自動的にプレゼントされるようにすることができる。一例を挙げると、親密度が３以上の仲間の範囲に対しては、仲間にプレゼントするカードの条件を「レア度３の全ての選手カード」に設定する。一方、親密度が２以下の仲間の範囲に対しては、仲間にプレゼントするカードの条件を「レア度２以下の全ての選手カード」に設定する。これにより、仲間の親密度に応じた適切な自動プレゼントが可能となる。

次に、「仲間の範囲」を、「仲間のゲーム内レベル」に基づいて定める例について説明する。ここで、ゲーム内レベルとは、ゲームの進行度やゲームの習熟度を示す指標となるものであり、ゲームを進行させることにより向上したり、対戦ゲームで所定の勝利条件を満たすことにより向上したりする。本野球ゲームでは、ユーザがゲームを進行させる（例えば、スカウトモードを実行する）ことにより経験値が蓄積され、当該経験値が一定量に達することによりユーザのゲームレベルがアップするようになっている。なお、ゲーム内対戦の勝敗等によりゲームレベルが決定されるゲームでは、ユーザのゲームレベルは向上したり低下したりする。

また、本野球ゲームでは、複数のレベルのゲーム内リーグが存在する。例えば、最下位レベルの第１リーグから最上位レベルの第１０リーグまでの１０のゲーム内リーグが存在し、各ユーザのチームが何れかのゲーム内リーグに所属して、同一リーグの他のユーザのチームと自動で対戦を行う（これを「自動対戦」と称する）。また、この自動対戦の成績に応じて、異なるリーグに所属するユーザのチーム同士の入替戦が自動で実行され、ユーザのチームが所属するゲーム内リーグのレベルが変化する。よって、「仲間のゲーム内レベル」として、仲間のチームが所属するゲーム内リーグのレベルを用いることもできる。また、ゲーム内レベルを、ランク、グレード、段位等と称してもよい。

図９には、ユーザがゲームレベルによって仲間の範囲を指定した上で、プレゼントするカードの条件を任意に設定するための自動プレゼント条件設定画面の一例を示す。この画面では、仲間指定領域２２１にゲームレベルによって仲間の範囲を指定するための入力部２３１・２３２が表示され、ゲームレベルの値を端末装置３におけるキー入力、音声入力等により直接入力できる。なお、図７と同様に、プルダウンメニューからゲームレベルの値を選択して範囲指定できるようにしてもよい。その際、ゲームレベルの値は１単位でもよいが、入力時の判断を簡便に行えるようにするために１０単位にしてもよい（１０、２０、３０等）。また、条件設定領域２２２については、図７の画面と同様である。

図９の自動プレゼント条件設定画面での操作により、異なる仲間の範囲には、異なるカードの条件を設定することができる。例えば、ゲームレベルが所定以上の仲間と、それよりも低い仲間とで、仲間にプレゼントするカードの条件を異ならせることができる。ゲームレベルの低い仲間（ゲームを開始して間もないような仲間等）については、レア度が高くないカードをプレゼントしても喜んでもらえるが、ゲームレベルの高い仲間については、レア度が高くないカードをプレゼントしてもあまり喜んでもらえない可能性が高い。これは、レベルの高い仲間は、高いレア度のカードをすでに複数保有している場合が多く、保有していない高いレア度のカードは欲しいと思っても、低いレア度のカードには関心がないと考えられるためである。そこで、例えば、ゲームレベルが３０以上の仲間の範囲に対しては、仲間にプレゼントするカードの条件を「レア度３の全ての選手カード」に設定する。一方、ゲームレベルが２９以下の仲間の範囲に対しては、仲間にプレゼントするカードの条件を「レア度２以下の全ての選手カード」に設定する。これにより、仲間のゲームレベルに応じた適切な自動プレゼントが可能となる。

次に、「仲間の範囲」を、「仲間のゲームへのアクセス頻度」に基づいて定める例について説明する。ゲームへのアクセス頻度については、現在から遡る所定期間（例えば１週間）のゲームへのアクセス日数またはアクセス回数により表すことができる。あるいは、先週の（先月の）アクセス日数またはアクセス回数をアクセス頻度としてもよい。ユーザによっては、以前は頻繁にゲームをしていたが、最近は殆どゲームをしていないというユーザもある。よって、ゲームへのアクセス頻度は、最近のゲームへのアクセス頻度が反映されるように、例えば現在から遡る１週間または先週１週間のアクセス日数等とすることが好ましい。

なお、アクセス日数については、１日に１回以上ゲームサーバ１にアクセス（ログイン）した場合にゲームにアクセスした日としてカウントされる。ユーザのゲームへのアクセスは、アクセスログとして記録されている。よって、ゲームサーバ１は、各ユーザのアクセスログに基づいてアクセス頻度を取得できる。

図１０には、ユーザがゲームへのアクセス頻度によって仲間の範囲を指定した上で、プレゼントするカードの条件を任意に設定するための自動プレゼント条件設定画面の一例を示す。この画面では、仲間指定領域２２１にゲームへのアクセス頻度によって仲間の範囲を指定するための入力部２３３・２３４が表示され、アクセス頻度の値を端末装置３におけるキー入力、音声入力等により直接入力できる。なお、図７と同様に、プルダウンメニューからゲームレベルの値を選択して範囲指定できるようにしてもよい。また、条件設定領域２２２については、図７の画面と同様である。

図１０の自動プレゼント条件設定画面での操作により、異なる仲間の範囲には、異なるカードの条件を設定することができる。例えば、ゲームへのアクセス頻度が所定以上の仲間と、それよりも低い仲間とで、仲間にプレゼントするカードの条件を異ならせることができる。ゲームへのアクセス頻度が高い仲間については、仲間同士でお互いにプレゼントを贈り合うことにより、コミュニケーションの活性化が図れる。一方、ゲームへのアクセス頻度が低い仲間については、あまりゲームを行っていないことから、そもそもプレゼントを贈る価値が低いと言える。そこで、例えば、１週間に４日以上ゲームにアクセスする仲間の範囲に対しては、仲間にプレゼントするカードの条件を「レア度３の全ての選手カード」に設定する。一方、ゲームへのアクセスが１週間に３日以下の仲間の範囲に対しては、仲間にプレゼントするカードの条件を「レア度２以下の全ての選手カード」に設定する。

また、例えば、所定のアクセス頻度以下（例えば、１週間に１日以下）の仲間の範囲については、自動プレゼントの条件を設定しないことにより、自動プレゼントが実行されないようにすることも可能である。あるいは、所定のアクセス頻度以下の仲間の範囲については、自動プレゼントを実行しないという条件を設定してもよい。

本構成により、仲間のゲームへのアクセス頻度に応じた適切な自動プレゼントが可能となる。

なお、図７、図９および図１０では、それぞれ、親密度、ゲームレベル、ゲームへのアクセス頻度によって仲間の範囲を指定できる例を示したが、これらを組み合わせて仲間の範囲を指定できるようにしてもよい。例えば、図１１に示すように、仲間指定領域２２１に、親密度の範囲を指定するための入力部２２３・２２４、ゲームレベルの範囲を指定するための入力部２３１・２３２、およびゲームへのアクセス頻度の範囲を指定するための入力部２３３・２３４を設ける。この場合、例えばユーザが親密度の範囲のみ入力部２２３・２２４で指定し、その他の入力部については空欄にすれば、親密度だけで仲間の範囲を指定できる。また、例えばユーザが親密度の範囲を入力部２２３・２２４で指定すると共に、ゲームレベルの範囲を入力部２３１・２３２で指定すれば、親密度とゲームレベルを組み合わせて仲間の範囲を指定できる。この組み合わせは、ＡＮＤ条件またはＯＲ条件の何れにすることも可能である。また、ゲームへのアクセス頻度による仲間の範囲の指定も同様である。

次に、「仲間の範囲」を、仲間のユーザＩＤやユーザ名等の「個人を特定する情報」に基づいて定める例について説明する。この場合、ゲームサーバ１は、特定の仲間を指定したユーザからの要求に応じて、仲間の範囲を仲間のユーザＩＤ等に基づいて設定する。

図１２および図１３には、ユーザが仲間の範囲に含まれる特定の仲間を指定した上で、プレゼントするカードの条件を任意に設定するための自動プレゼント条件設定画面の一例を示す。図１２は自動プレゼント条件設定画面を開いた当初の状態の画面例、図１３はユーザによって特定の仲間を指定する入力が行われた後の画面例である。

図１２の画面の仲間指定領域２２１では、ユーザの全ての仲間の中から任意の仲間を１人以上選択できる。この仲間指定領域２２１には仲間リストボタン２３５が設けられており、当該ボタン２３５を押せば、端末装置３から仲間リスト要求がゲームサーバ１へ送信される。ゲームサーバ１は、ユーザの端末装置３からこの要求を受信して、当該ユーザの仲間リストを表示させる情報を端末装置３へ送信する。これにより端末装置３には、例えば図１４に示すような仲間リスト画面が表示され、任意の仲間を選択できるようになる。この仲間リスト画面には、ユーザの仲間のアバター、名前、レベル、チーム、リーダーに設定しているカード等の情報を含む仲間の一覧が表示される。なお、画面に表示しきれない仲間の情報については、画面をスクロールする又は仲間リストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。この仲間リスト画面で任意の仲間を選択（例えば、仲間のアバターまたは名前の部分をクリック）すれば、図１３に示すように自動プレゼント条件設定画面に戻り、選択した仲間の情報２３６（仲間のアバター、名前、レベル、チーム等）が画面に表示される。図１３の例では、ユーザが仲間Ｂおよび仲間Ｃを選択した例を示している。なお、１人の仲間だけを仲間の範囲として設定してもよいし、３人以上の仲間を選択して仲間の範囲（条件付けのグループ）を設定してもよい。

なお、仲間指定領域２２１にユーザＩＤを入力する領域を設け、ユーザが仲間のユーザＩＤを直接入力することによって、特定の仲間を指定するようにしてもよい。但し、一般的にユーザが自分の仲間のユーザＩＤを覚えていることは少ないので、前述のように、仲間リスト画面から特定の仲間を選択できるようにすることが望ましい。ユーザが仲間リスト画面から特定の仲間を選択した場合も、ゲームサーバ１では、その仲間のユーザＩＤに基づいてゲーム情報を管理しているので、ユーザが仲間のユーザＩＤを指定したことと実質的には同様である。

また、後述するように、ユーザが仲間の範囲として特定の仲間を指定しようとする場合に、ユーザの仲間のゲーム情報に基づいて、プレゼント対象の候補者となる仲間をユーザに報知するようにしてもよい。

また、条件設定領域２２２については、図７の画面と同様である。図１２および図１３の自動プレゼント条件設定画面での操作により、仲間の範囲に特定の仲間を指定し、仲間の範囲毎に異なるカードの条件を設定することができる。例えば、ユーザＡにとって、仲間Ｂおよび仲間Ｃは、お互いにレア度の高い相手チームの選手カードをプレゼントし合うような特別な仲間の場合、プレゼントするカードの条件として、例えば「仲間のチームでレア度４の選手カード」に設定する。また、仲間Ｄからはいつもレア度３のカードが贈られてくる場合、仲間の範囲として仲間Ｄを指定し、プレゼントするカードの条件として、例えば「レア度３の全ての選手カード」に設定する。本構成により、特定の仲間に対して適切なオブジェクトの条件を設定して自動でプレゼントすることが可能となる。

また、後述するように、仲間の範囲として特定の仲間が設定された場合、その仲間のゲーム情報に基づいて、その仲間にプレゼントするオブジェクトの条件をゲームサーバ１が自動的に設定するようにしてもよい。

〔ゲーム管理装置の機能的構成および動作〕
次に、上記のゲームを実現するゲーム管理装置の機能的構成の一例について説明する。図１５は、端末装置３と通信するゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の基本的な構成を示す機能ブロック図である。

本実施の形態に係るゲーム管理装置は、ユーザ情報記憶制御手段６０、受信手段６１、実行手段６２、画面生成手段６３、送信手段６４、アクセス管理手段６５および交流制御手段６６等を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

ユーザ情報記憶制御手段６０は、各ユーザのゲームに関する情報をデータベースサーバ２に記憶して管理する。ユーザ情報記憶制御手段６０がデータベースサーバ２に記憶している、ユーザのゲームに関する情報であるユーザ情報データベースの一例（この例ではユーザＩＤ＝０００００１の１人分の情報）を、図１６に示す。

ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ユーザの基本情報、希望チーム、レベル情報、保有カード、保有ポイント、保有アイテム、仲間情報、アクセスログ、交流履歴、欲しい物の情報等を、データベースサーバ２の所定の記憶領域に記憶する。

ユーザの基本情報としては、ログインＩＤ、パスワード、ユーザ名（ゲーム内で使用するニックネーム等）等がある。ここで、ログインＩＤおよびパスワードは、各ユーザが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。ユーザ名は、ゲーム内で使用するニックネーム等である。

希望チームは、ユーザがゲームサービスを受けるための利用登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定したお気に入りチームの情報である。本実施の形態では、各ユーザが、複数のチーム（例えば、現実世界の日本のプロ野球１２チーム）のうちの希望する何れか１つのチームを登録することができる。

レベル情報には、前述したユーザのゲームレベル、ゲーム内リーグのレベル等がある。

保有カードの情報とは、ゲーム内でユーザが保有している選手キャラクタのカードの情報（選手ＩＤ、能力値等）である。また、図１７に例示するように、データベースサーバ２には、選手ＩＤと対応付けられて、選手キャラクタの名前、背番号、ポジション、所属チーム、初期能力値（未強化の値）、レア度、画像データなどが記憶された選手データベース（選手ＤＢ）が存在する。よって、ゲームサーバ１は、ユーザ情報記憶制御手段６０によって記憶されている選手ＩＤに基づいて、当該選手ＩＤに対応するカード（選手キャラクタ）に関する各種情報を、選手ＤＢから取得できるようになっている。

保有ポイントの情報は、ゲーム内でユーザが保有している各種ポイント（ポイントに準ずる値などを含む）およびアイテムの情報である。本実施の形態では、前述の経験値、強化ポイント、抽選ポイント、行動ポイント、運営コストなどが保有ポイントの情報に含まれる。また、アイテムには、前述の回復アイテムや選手キャラクタを強化するための強化アイテム等が含まれる。各アイテムにはそれらを一意に識別するアイテムＩＤが付されており、アイテムＩＤによって管理される。

また、仲間情報とは、ユーザに関係付けられた仲間の情報であり、ユーザＩＤと対応付けられて仲間のユーザＩＤがデータベースサーバ２に記憶される。また、アクセスログとは、ユーザの端末装置３がゲームサーバ１へアクセス（ログイン）した日時等の時間情報である。また、交流履歴とは、ユーザが他のユーザ（仲間等）にゲーム内で交流を行った履歴の情報である。この交流履歴には、交流の種類、相手、時間の情報が含まれる。交流の種類としては、挨拶、メッセージ送信、プレゼント、対戦協力、チャットなどがある。交流の相手の情報としては、相手のユーザＩＤが記憶される。

また、本ゲームでは、各ユーザが欲しいと思うカードやアイテムを欲しい物として登録できる。ユーザが登録した欲しい物の情報（選手ＩＤ等）も、ユーザＩＤと対応付けられてデータベースサーバ２に記憶される。

次に、図１５に示す受信手段６１、実行手段６２、画面生成手段６３、送信手段６４について説明する。受信手段６１および送信手段６４は、ゲームサーバ１のＣＰＵ１１および通信制御部１５により実現される機能である。

ユーザの端末装置３のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する入力の操作を行った場合、当該入力に関する情報（ゲーム画面のリクエスト等）が端末装置３のウェブブラウザによってゲームサーバ１へ送信される。ゲームサーバ１では、前記入力に関する情報を受信手段６１が受信したとき、実行手段６２が、当該情報に応じてユーザのゲームに関する情報を読み出して演算やデータ処理を行うことによってゲームを実行する。

例えば、試合モードで他のユーザのチームと対戦するという入力操作がユーザによって行われた場合を例に挙げると、実行手段６２は、対戦を行う両ユーザのユーザＩＤに対応した両チームの選手キャラクタ（試合に出場するキャラクタ）の情報をデータベースサーバ２から読み出す。そして、実行手段６２は、ＡＩ（Artificial Intelligence）プログラム等により、両チームの選手キャラクタの能力等のパラメータに基づいて、野球の試合のシミュレーションを実行し、試合の勝敗を決定する。

次に、画面生成手段６３について説明する。画面生成手段６３は、実行手段６２による実行結果に応じて、例えばＨＴＭＬデータからなるゲーム画面データを生成する。ＨＴＭＬデータには、データベースサーバ２から読み出されたキャラクタ等の画像データを含めてもよい。また、ＨＴＭＬデータには、端末装置３のウェブブラウザのプラグインによって動作するスクリプト（プログラム）が埋め込まれていてもよい。ゲームサーバ１から提供されたスクリプトが端末装置３で実行される場合は、端末装置３で表示されるゲーム画面を動画とすることも可能である。あるいは、画面生成手段６３は、ストリーミング形式の映像を生成してもよい。

また、送信手段６４は、画面生成手段６３により生成された画面データ（ＨＴＭＬデータ、ストリーミング形式の映像データ等）を、ゲーム画面のリクエストに対するレスポンスとして、または実行手段６２による実行結果として、ユーザの端末装置３へ送信する。このゲーム画面データを受信したユーザの端末装置３では、ウェブブラウザおよびそのプラグイン等によって表示部３５にゲーム画面が表示される。

次に、アクセス管理手段６５について説明する。アクセス管理手段６５は、ゲームサービスを受けようとするユーザが端末装置３を操作してゲームサーバ１にアクセス（ログイン）しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザＩＤと対応付けられたログインＩＤおよびパスワードに基づく認証がある。また、ユーザがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できるように、端末装置３である携帯電話やスマートフォンの個体識別番号（電話番号とは別の端末を一意に識別するための情報）、または契約者固有ＩＤ（端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないＩＤ）を利用した認証を行ってもよい。

次に、交流制御手段６６について説明する。交流制御手段６６は、ゲーム内で行われるユーザ同士の交流やコミュニケーションを実現するものである。交流制御手段６６は、ユーザの端末装置３から、他のユーザ（特に、仲間）に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該ユーザから当該他のユーザに対しての交流処理を実行する実行手段６２を制御する。交流処理には、例えば、挨拶、メッセージの伝達、プレゼント、対戦協力、チャットなどがある。

次に、図１８Ａの機能ブロック図を参照して、ゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能的構成について説明する。ゲーム管理装置としてのゲームサーバ１は、主に、仲間管理手段５１（管理手段）、設定手段５２および自動プレゼント手段５３を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

仲間管理手段５１は、ユーザに関係付けられた仲間（他のユーザ）を管理する機能を有する。あるユーザが他のユーザと仲間関係を構築するための一形態としては、２人のユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ１を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。その他の形態としては、既にゲームサービスに登録済みのユーザが、未登録のユーザをゲームに招待し、招待を受けたユーザがゲームサービスに登録した場合に、招待した側とされた側との２人のユーザを仲間同士とする形態もある。仲間管理手段５１は、図１６に例示するように、仲間関係にあるユーザ同士のユーザＩＤを関係付けてデータベースサーバ２に記憶し、仲間管理を行う。

設定手段５２は、ユーザからの要求に応じて、プレゼント対象の仲間の範囲および当該範囲内の仲間にプレゼントするオブジェクトの条件を予め設定する機能を有する。前述のように、仲間の範囲は、親密度、ゲーム内レベル、ゲームへのアクセス頻度、個人を特定する情報（仲間のユーザＩＤ等）などに基づいて設定できる。すなわち、ユーザの端末装置３に表示される図７、図９〜図１２等に示される自動プレゼント条件設定画面で、ユーザが仲間の範囲およびプレゼントするカードの条件を入力して設定ボタン２２８を押せば、端末装置３からは条件設定要求がゲームサーバ１へ送信される。これがユーザからの要求である。ゲームサーバ１の設定手段５２は、ユーザからの条件設定要求を受信し、ユーザが入力した仲間の範囲およびカードの条件を設定（登録）する。すなわち、ユーザＩＤと対応付けて、仲間の範囲および当該範囲内の仲間にプレゼントするカードの条件を、データベースサーバ２に記憶する。

図１９ないし図２３に、ユーザＩＤ＝０００００１のユーザＡが設定した自動プレゼント条件（仲間の範囲およびカードの条件）の一例を示す。図１９は、仲間の範囲を親密度に基づいて定めて自動プレゼント条件を設定した例である。ここで、ゲームサーバ１が親密度を付与する構成について以下に説明する。

図２４に示すように、ゲームサーバ１は親密度付与手段５４を備えている。この親密度付与手段５４は、仲間関係にある２人のユーザに対して親密度を付与する機能を有する。ゲームサーバ１は、仲間関係にある２人の親密度を、データベースサーバ２に記憶して管理している。以下に、親密度付与の具体例を挙げる。

親密度付与手段５４は、例えば、仲間同士の２人のユーザ間で交流処理が実行される毎に、所定値（例えば１ポイント）の親密ポイントを付与するようになっている。なお、交流の内容により付与する親密ポイントを変えてもよい。例えば、挨拶は１ポイント、メッセージ送信は２ポイント、プレゼントおよび対戦協力は３ポイント、チャットは４ポイント等としてもよい。なお、仲間同士の一方または両方の交流が所定期間（例えば１週間）途絶えた場合、２人の親密ポイントが所定ポイント（例えば３ポイント）減少するようにしてもよい。また、本実施の形態では、２人の親密ポイントに応じて、例えば５段階の親密度が設けられている。例えば、親密ポイントが０〜２４ポイントで親密度＝１（知り合い）、２５〜４９ポイントで親密度＝２（友人）、５０〜７４ポイントで親密度＝３（親友）、７５〜９９ポイントで親密度＝４（相棒）、１００ポイント以上で親密度＝５（盟友）となる。

前述のように、本ゲームでは、ユーザが他のユーザとゲーム内で交流（挨拶、プレゼント等）を行うことにより、抽選ポイントを獲得できる。そして、相手との親密度が高くなるほど、その相手との交流により獲得できる抽選ポイント（ゲーム内ポイント）は大きくなるというメリットを生じる。すなわち、ユーザが仲間にプレゼントを行えば、親密度が向上し、獲得できる抽選ポイントも大きくなるので、プレゼントを行うことに対してもより強い動機づけが与えられるはずである。しかしながら従来は、上記のようなメリットがあると分かっていても、プレゼントの操作（自分の手持ちカードの中から、あるいは新たなカードの入手毎に、不要なカードを決め、さらにそれを欲しがっていそうな仲間を想定した上で、その相手に不要カードをプレゼントするという操作）が手間であるがゆえに、プレゼント自体も積極的に行われないという傾向も見られた。この点、本実施の形態によれば、プレゼントを行うための事前の設定を行うだけで、あとは自動的にプレゼントが行われ、且つ、自動的にポイントも獲得されることになるので、ユーザにとって非常に有用な機能を提供することができる。

そして、本実施の形態では、仲間の範囲を親密度等に基づいて定めて、自動プレゼント条件をその範囲に適したものに設定できる。以下には、親密度に基づいて仲間の範囲を設定する具体例を示す。

一般的に、ユーザは、親密度が高い仲間ほど、相手の欲しがるカード（例えば、レア度の高いカード）をプレゼントして相手を喜ばせたいと考える。そこで、図１９では、親密度が３以上の仲間の範囲に「レア度３の全ての選手カード」の条件が対応付けられ、親密度が２以下の仲間の範囲に「レア度２以下の全ての選手カード」の条件が対応付けられた自動プレゼント条件の設定例を示している。

なお、図１９の例では、仲間の範囲を、親密度が３以上と２以下との２段階に分けた例を示したがこれに限定されない。例えば、仲間の範囲を、親密度１、２〜４、５の３段階に分けたり、親密度１、２、３、４、５の５段階に分けたりしてもよい。また、親密度５の仲間にだけ自動プレゼント条件を設定し、その他の親密度の仲間には自動プレゼント条件を設定しない（すなわち、自動プレゼントが実行されない）ようにしてもよい。

図２０は、仲間の範囲をゲームレベルに基づいて定めて自動プレゼント条件を設定した例である。前述のように、ゲームレベルが高い仲間には、レア度の低いカードをプレゼントしてもあまり喜んでもらえない可能性が高い。そこで、図２０では、ゲームレベルが３０以上の仲間の範囲に「レア度３の全ての選手カード」の条件が対応付けられ、ゲームレベルが２９以下の仲間の範囲に「レア度２以下の全ての選手カード」の条件が対応付けられた自動プレゼント条件の設定例を示している。

なお、図２０の例では、仲間の範囲を、レベル３０以上とレベル２９以下との２段階に分けた例を示したがこれに限定されない。例えば、仲間の範囲を、レベル９以下、１０〜２９、３０〜４９、５０以上の４段階に分ける等、仲間の範囲は任意に設定できる。そして、例えば、レベル９以下の仲間にはレア度１、レベル１０〜２９の仲間にはレア度２、レベル３０〜４９の仲間にはレア度３、レベル５０以上の仲間にはレア度４の各カードを自動的にプレゼントする条件を設定することができる。

図２１は、仲間の範囲をゲームへのアクセス頻度に基づいて定めて自動プレゼント条件を設定した例である。ゲームへのアクセス頻度が低い仲間にプレゼントを贈っても、その仲間はあまりゲームを行っていないので相手からプレゼントが返送されてくることも少ないと考えられる。逆に、ゲームへのアクセス頻度が高い仲間にプレゼントすれば、相手からもプレゼントが返ってくる可能性が前記の場合よりも高くなり、プレゼントのやり取りを通した良好な関係の構築に期待が持てる。そこで、図２１では、ゲームへのアクセス頻度が４日／週以上の仲間の範囲に「レア度３の全ての選手カード」の条件が対応付けられ、アクセス頻度が２日〜３日／週の仲間の範囲に「レア度２以下の全ての選手カード」の条件が対応付けられ、アクセス頻度が１日／週以下の仲間の範囲には自動プレゼント条件を設定していない例を示している。これは一例であり、仲間の範囲はユーザが任意に設定できる。

また、図２２には、親密度、ゲームレベル、ゲームへのアクセス頻度の３つをＡＮＤ条件によって組み合わせて仲間の範囲を設定した例を示している。この例では、親密度４以上、且つ、ゲームレベル１００以上、且つ、アクセス頻度５日／週の条件を満たす仲間に対して、「相手のチームでレア度４の選手カード」という条件を対応付けている。なお、ユーザにとっては、自分のチームのカード（特にレア度の高いもの）は貴重であるため、手放したくないと考えることも多い。そこで、プレゼントするカードの条件として「相手のチームのカード」という条件を設定した場合でも、ユーザ自身のチームのカードは自動プレゼントの条件から除外されるように、ユーザが任意に設定できるようにしてもよい。

このように、親密度、ゲームレベル、ゲームへのアクセス頻度等のゲーム情報を用いれば、個人を特定することなく仲間の範囲を設定できる。

一方、図２３には、仲間の範囲を、個人を特定する情報（仲間のユーザＩＤ）に基づいて定めて自動プレゼント条件を設定した例を示している。この例では、仲間の範囲が仲間ＢのユーザＩＤ＝０００００２および仲間ＣのユーザＩＤ＝０００００５によって定められ、当該仲間の範囲に「相手のチームでレア度４の選手カード」という条件が対応付けられている。また、ユーザＩＤ＝００００１０の仲間Ｄに対しては、「レア度３の全ての選手カード」という条件が対応付けられている。このように、ユーザが自動でプレゼントを贈りたい特定の仲間を指定して、任意のカード条件を設定できる。

上記のようにして行われた自動プレゼントの設定は、ユーザの任意でいつもで解除することができる。すなわち、ユーザが端末装置３で所定の解除操作を行えば、ユーザからの解除要求がゲームサーバ１へ送信される。ゲームサーバ１は、この解除要求に応じて、ユーザＩＤに対応づけて記憶されている自動プレゼントの設定情報を削除する、または、設定解除フラグを立てる。本実施の形態では、仲間の範囲を複数指定して、カード条件の異なる複数の自動プレゼントを設定できるが、全ての自動プレゼントの設定を一括して解除することもできるし、一部の設定のみを解除することもできる。

また、自動プレゼント手段５３は、前記のようにして設定された自動プレゼント条件を満たすオブジェクトをユーザが入手した場合、前記範囲内の仲間に当該オブジェクトを自動的にプレゼントする機能を有する。ここで、ゲームサーバ１による自動プレゼント処理の例を、図２５のフローチャートを参照しながら以下に説明する。

例えば、ユーザがスカウトモード、抽選モード等のゲームを実行し、新たにカードを入手した場合（Ｓ１でＹＥＳ）、ゲームサーバ１は、ユーザが予め設定している自動プレゼント条件を、データベースサーバ２から取得する（Ｓ２）。その後、ゲームサーバ１は、ユーザが入手したカードが、自動プレゼント条件を満たすか否かを判断する（Ｓ３）。

図１９ないし図２３に例示するように、ユーザＩＤと関連付けて設定されている自動プレゼント条件としては、仲間の範囲および当該範囲内の仲間にプレゼントするカードの条件が定められている。ここでは、図１９の自動プレゼント条件を適用する場合を例示する。

例えば、ユーザが入手したカードがレア度３のカードであった場合、親密度３以上の仲間にプレゼントする条件を満たす（Ｓ３でＹＥＳ）。よって、この場合、ゲームサーバ１は、ユーザが入手したカードを、ユーザによるプレゼント操作を伴うことなく、親密度３以上の仲間の何れかにプレゼントする自動プレゼント処理を実行する（Ｓ４）。もし、親密度３以上の仲間が複数いる場合は、ゲームサーバ１がその中からランダムに選択した仲間に自動的にプレゼントする。あるいは、ユーザがレア度３のカードを入手する毎に、親密度３以上の仲間の範囲の中の親密度の高い仲間から、順次、自動的にプレゼントする。すなわち、レア度３のカードを最初に入手した場合は親密度の最も高い仲間にプレゼントし、その次にそのカードを入手した場合は親密度が２番目に高い仲間にプレゼントする。このように、親密度の高い仲間から、順次、プレゼントし、親密度３以上の仲間の全員にプレゼントし終わったら、再度、親密度の最も高い仲間に戻ってプレゼントする。

また、例えば、ユーザが入手したカードがレア度１または２のカードであった場合、図１９の自動プレゼント条件によれば、親密度２以下の仲間にプレゼントする条件を満たす（Ｓ３でＹＥＳ）。よって、この場合も、前記と同様に、ゲームサーバ１は、ユーザが入手したカードを、親密度２以下の仲間の何れかにプレゼントする自動プレゼント処理を実行する（Ｓ４）。この場合、ゲームサーバ１は、プレゼント先の仲間に対して、ユーザからプレゼントが届いた旨を通知する。

自動プレゼント処理が実行された場合、ゲームサーバ１は、その旨をユーザに報知する（Ｓ５）。例えば、ゲームサーバ１は、図２６に示す報知画面を生成し、ユーザの端末装置３に送信する。この報知画面には、報知内容を表示する領域２４０、プレゼントしたオブジェクトを表示する領域２４１、プレゼントした相手を表示する領域２４２、メッセージ送信領域２４３などが設けられる。領域２４０には、例えば「あなたが入手したカードを仲間に自動的にプレゼントしました。」というテキストが表示される。領域２４１には、プレゼントしたカード２４６およびカードの情報２４７（選手名、所属チーム、ポジション、能力値等）が表示される。領域２４２にはプレゼント先の仲間のアバター、名前、レベル、チーム、リーダーに設定しているカード等が表示される。

メッセージ送信領域２４３には、自動でプレゼントした仲間に送るためのメッセージ入力部２４４および送信ボタン２４５が表示される。ここで、ユーザがメッセージ入力部２４４に任意のメッセージを入力して送信ボタン２４５を押せば、ゲームサーバ１がそのメッセージを、自動でプレゼントした仲間に届ける。なお、メッセージ送信領域２４３は省略することもできる。また、画面内の閉じるボタン２４８を押せば、報知画面を閉じて元のゲーム画面に戻ることができる。

一方、図２５のステップＳ３において、ユーザが入手したカードが自動プレゼント条件を満たさなかった場合（Ｓ３でＮＯ）、自動プレゼント処理が実行されることなく図２５の処理を終了する。この場合、ユーザが入手したカードは、ユーザ自身の所有物となる。

以上のように、本実施の形態のゲーム管理装置は、図１８Ａに示す仲間管理手段５１、設定手段５２および自動プレゼント手段５３等を備えている構成であり、仲間の範囲を限定し、その範囲の仲間に適した自動プレゼント条件の設定が可能である。これにより、ユーザは、仲間の範囲に応じた適切なカード（オブジェクト）をプレゼント候補として予め設定しておけば、当該カードの入手時に、手間を掛けることなく確実に、その範囲の仲間にプレゼントすることができる。本構成により、プレゼントを通して、仲間同士の交流を深めることができる。

ところで、図２６の画面では、仲間に自動プレゼントが実行された後に、その仲間にユーザがメッセージを送信できる構成について説明したが、自動プレゼントと同時に送信される任意のメッセージを、ユーザが予め設定できるようにしてもよい。例えば、図２７に示すように、自動プレゼント条件設定画面にメッセージ入力部２２９を設ける。ユーザは、自動プレゼント条件（仲間の範囲およびその範囲の仲間にプレゼントするカードの条件）を指定すると共に、メッセージ入力部２２９に任意のメッセージを入力した上で、設定ボタン２２８を押す。これにより、ユーザの端末装置３からは、入力したメッセージを含んだ条件設定要求がゲームサーバ１へ送信される。ゲームサーバ１の設定手段５２は、ユーザからの条件設定要求を受信し、ユーザが入力した仲間の範囲、カードの条件、およびメッセージを設定（登録）する。すなわち、ユーザＩＤと対応付けて、仲間の範囲、当該範囲内の仲間にプレゼントするカードの条件、および自動プレゼント時に自動送信するメッセージを、データベースサーバ２に記憶する。これにより、ゲームサーバ１は、自動プレゼントを実行する際、予め設定されているメッセージを、プレゼント先の相手に自動送信する。この構成により、ユーザは、予めメッセージを設定しておけば、手間を掛けることなく、自動プレゼントと同時に相手にメッセージを送ることができる。

なお、自動プレゼントのたびにいつも同じメッセージが送信されるのを回避するため、ユーザが予め複数のメッセージを設定できるようにしてもよい。この場合、ゲームサーバ１は、自動プレゼントを実行する毎に、設定されている複数のメッセージからランダムに選択したメッセージを相手に送信する。あるいは、ゲームサーバ１は、設定されている複数のメッセージに所定の順番を付けて、自動プレゼントを実行する毎に、その順番に従って送信するメッセージを順次変更する。

ところで、ユーザがプレゼントの対象となる仲間の範囲を定めて、自動プレゼントの設定を行っても、その範囲に含まれる仲間の中には、ゲームへの関心がかなり希薄になったり、ゲームを止めてしまったりする者もいる。あるいは、自動プレゼントを設定した時点で、既にゲームを止めている者が仲間の範囲に含まれている可能性もある。そこで、一旦、自動プレゼントが設定された仲間であっても、ゲームへの関心がかなり希薄又はゲームを止めた仲間を、自動プレゼントの対象から除外する構成について以下に説明する。この構成のゲームサーバ１は、図１８Ｂに示すように、除外手段５０を備えている。

除外手段５０は、自動プレゼントの対象となる仲間の範囲に含まれる者であっても、ゲームへのアクセス頻度が所定値以下、またはゲームへの非アクセス期間が所定期間以上になった者を、自動プレゼントの設定対象から自動的に除外する機能を有する。ここで、「仲間のゲームへのアクセス頻度が所定値以下」とは、所定期間（例えば先月１か月間、あるいは現在から遡る１か月間）の仲間のゲームへのアクセス日数が所定日数（例えば３日）以下となる場合が挙げられる。仲間のゲームへのアクセス頻度が所定値（３日／月）以下の場合、その仲間についてはゲームへの関心がかなり希薄である、またはゲームを止めてしまったと判断できる。なお、アクセス頻度に関する前記所定値は、「３日／月」に限定されるものではなく、例えば「７日／２か月」としてもよく、任意の値を設定できる。

また、「ゲームへの非アクセス期間が所定期間（例えば３０日間）以上」になった仲間についても、ゲームへの関心がかなり希薄である、またはゲームを止めてしまったと判断できる。ゲームへの非アクセス期間に関する前記所定期間も、３０日間に限定されるものではなく、例えば２週間としてもよく、任意の期間を設定できる。

なお、「ゲームへのアクセス頻度が所定値以下」、または「ゲームへの非アクセス期間が所定期間以上」の判断に際しては、自動プレゼントの設定が行われた時点以降の仲間のゲームへのアクセスを対象としてもよいが、それ以前のゲームへのアクセスを対象とすることもできる。これは、自動プレゼントの設定が行われた時点で、既に、ゲームへの関心がかなり希薄になっていたり、ゲームを止めていたりする可能性もあるためである。

例えば、ゲームサーバ１は、毎日（または１週間に１回等でもよい）、決まった時刻（例えば午前０時）に、ユーザＡが設定した自動プレゼントの対象となる仲間の範囲（図１９〜図２３参照）に含まれる仲間に対して、次の処理を実行する。すなわち、ゲームサーバ１は、前記仲間のアクセスログ（図１６参照）に基づいて、ゲームへのアクセス頻度が所定値以下、またはゲームへの非アクセス期間が所定期間以上になっている除外対象の仲間が存在するか否かを判断する。ここで、除外対象の仲間が存在する場合には、除外手段５０が、その仲間を、自動プレゼントの設定対象から自動的に除外する。例えば、除外手段５０は、除外対象の仲間に対する自動プレゼントの設定を、自動的に解除する。具体例を以下に説明する。

先ず、図２３に示す自動プレゼント条件が設定されている場合を例に挙げて説明する。ユーザＩＤ＝００００１０（仲間Ｄ）が除外対象と判断された場合、除外手段５０は、当該仲間に対して設定されている自動プレゼント条件を自動的に解除する（設定情報を消去する又は消去フラグを立てる）。また、仲間の範囲に含まれるユーザＩＤ＝０００００２（仲間Ｂ）およびユーザＩＤ＝０００００５（仲間Ｃ）のうち仲間Ｃのみが除外対象と判断された場合、除外手段５０は、仲間の範囲からユーザＩＤ＝０００００５のみを消去する（または消去フラグを立てる）。

次に、図１９に示す自動プレゼント条件が設定されている場合を例に挙げて説明する。
例えば、親密度≧３の仲間の範囲に含まれるユーザＩＤ＝００００１０（仲間Ｄ）が除外対象と判断された場合、除外手段５０は、当該仲間の範囲から、ユーザＩＤ＝００００１０を除外する。この場合、仲間の範囲は親密度によって定められているので、仲間の範囲から仲間Ｄを除外するために、除外手段５０は、例えば自動プレゼントの非対象者の情報としてユーザＩＤ＝００００１０をデータベースサーバ２に記憶し、仲間Ｄを自動プレゼントの非対象者として管理する。また、図２０〜図２２に示すように仲間の範囲がゲームレベル、ゲームへのアクセス頻度等によって定められている場合も同様である。

本構成により、ゲームへの関心がかなり希薄又はゲームを止めた仲間、すなわちプレゼントを贈る価値の低い（又はない）仲間に対して、自動プレゼントが実行されることを回避することができる。また、そのような仲間に対する自動プレゼントの解除操作をユーザが行う必要がなくなり、ユーザの操作の手間を省くことができる。

また、除外手段５０が、前述の除外対象の仲間を、自動プレゼントの設定対象から自動的に除外した場合、その旨をその理由と共にユーザに報知することが好ましい。例えば、ユーザＡの端末装置３がゲームにアクセスしたとき、ゲームサーバ１は、「仲間Ｄは３０日以上ゲームにアクセスしなかったため、自動プレゼントの対象から除外しました。」等のメッセージを含む報知画面を生成し、ユーザＡの端末装置３へ送信する。

また、自動プレゼントの設定対象となった仲間について、その仲間のゲーム情報（親密度、ゲームレベル、ゲームへのアクセス頻度等）が変動することにより、自動プレゼント設定の対象が変わる（その仲間が自動プレゼントの設定対象から外れる、またはその仲間が含まれる仲間の範囲が変化して自動プレゼント条件が変わる）ことがある。この場合、ゲームサーバ１は、ユーザにその旨の報知（アラート）を行う報知手段を備えていることが好ましい。この報知により、仲間のゲーム情報の変動に伴い、一旦設定した自動プレゼントの対象が変わったことをユーザに認識させ、その仲間に対する自動プレゼントの条件を見直す機会を与えることができる。以下に、具体例を説明する。

例えば、図１９に示すように、「親密度≧３」の仲間の範囲に「レア度３の全ての選手カード」というカード条件を対応付けた自動プレゼント条件を、ユーザＡが設定したとする。この自動プレゼント条件が設定された当初は、「親密度３」の仲間Ｃが自動プレゼントの設定対象であったが、仲間ＣがユーザＡとあまり交流しなかったこと等により、親密度が２に低下した場合を想定する。この場合、仲間Ｃは、「親密度≧３」の仲間の範囲から外れる。もしも、「親密度≦２」の仲間の範囲に対して自動プレゼント条件が設定されていなかった場合、仲間Ｃは自動プレゼントの設定対象から外れてしまうことになる。また、図１９に示すように「親密度≦２」の仲間の範囲に対して「レア度２以下の全ての選手カード」という自動プレゼント条件が設定されている場合でも、仲間の範囲の変化に伴って自動プレゼント条件が変わってしまう。この場合、ゲームサーバ１の報知手段は、例えば「仲間Ｃとの親密度が２に低下したため、仲間Ｃは自動プレゼントの対象から外れてしまいました（または、仲間Ｃに対するプレゼントの条件が変わってしまいました）。」というメッセージを表示する報知画面を生成し、ユーザＡの端末装置３に送信する。

また、上記報知の際、ゲームサーバ１は、（ａ）仲間Ｃに対して元の自動プレゼント条件を適用する、（ｂ）仲間Ｃに対する自動プレゼント条件を再設定する、（ｃ）仲間Ｃに対する自動プレゼントを解除する、等の選択肢をユーザＡに提示してもよい。ユーザＡが前記（ａ）の選択肢を選んだ場合、ゲームサーバ１は、「親密度≧３」の仲間の範囲から外れたにも関わらず、仲間Ｃに対して元の自動プレゼント条件「レア度３の全ての選手カード」をそのまま設定する。このように、元の自動プレゼント条件をそのまま適用可能とする理由は、仲間との親密度（又は仲間のゲームレベル等）が低くなった場合に、プレゼントを止めてしまったり、プレゼントの内容を下げたりするというのは行い難い場合もあるためである。また、ユーザＡが前記（ｂ）の選択肢を選んだ場合、例えば図１３の自動プレゼント条件設定画面で、仲間の範囲として仲間Ｃのみが指定されている画面に遷移し、ユーザＡが仲間Ｃに対して任意の自動プレゼント条件を再設定できるようにする。

上記の説明では、仲間の親密度が低下して自動プレゼント設定の対象が変わる例を示したが、仲間の親密度が向上して自動プレゼント設定の対象が変わる場合も同様である。また、自動プレゼントの設定対象となった仲間のゲームレベル、ゲームへのアクセス頻度等のゲーム情報が変動することにより、自動プレゼント設定の対象が変わる場合も同様である。

次に、仲間の範囲としてユーザが特定の仲間を指定した場合、ゲームサーバ１がその仲間に対する自動プレゼント条件を自動的に設定する構成について説明する。この構成のゲームサーバ１は、図２８に示すように、自動設定手段５５を備えている。この自動設定手段５５は、ユーザが指定した個人を特定する情報に基づいて、仲間の範囲として特定の仲間が設定された場合、当該特定の仲間のゲーム情報に基づいて、当該特定の仲間にプレゼントするオブジェクトの条件を自動的に設定する機能を有する。

ここでは、図２９に示す自動プレゼント条件の自動設定画面において、ユーザが特定の仲間を選択するだけで、自動設定手段５５がプレゼントされるカードの条件を自動設定する例について説明する。図２９の画面には、仲間指定領域２５１が設けられている。この仲間指定領域２５１の仲間リストボタン２３５を押せば、図１４の仲間リスト画面に遷移し、ここで特定の仲間を指定すれば、ユーザの端末装置３からはその操作情報（指定された仲間のユーザＩＤを含む）がゲームサーバ１へ送信される。この操作情報に応じて、自動設定手段５５は指定された仲間のゲーム情報をデータベースサーバ２から取得し、仲間のゲーム情報に基づいて自動プレゼント条件を自動的に設定する。

例えば、自動設定手段５５は、指定された仲間のチームの選手で所定のレア度（レア度３、レア度４等）というプレゼントするカードの条件を自動的に設定する。この場合、自動設定手段５５は、仲間のゲームレベル、仲間の親密度、仲間のゲームへのアクセス頻度等の仲間のゲーム情報に基づいて、適切な報知条件を設定することができる。例えば、その仲間のゲーム内レベル、親密度またはゲームへのアクセス頻度が閾値以上の場合には、プレゼントするカードの条件をレア度４とし、閾値未満の場合はレア度３とする。

あるいは指定された仲間が設定しているチームオーダ（カードのデッキ）において弱いポジションがある（所定のレア度以上または所定の能力値以上の選手がいないポジションがある）場合には、そのポジションの選手カードで所定のレア度（例えばレア度４）というガードの条件を自動的に設定する。一例を挙げると、仲間のチームオーダに含まれる投手キャラクタにレア度４以上のものがない場合、仲間のチームの投手カードでレア度４以上というカードの条件を自動設定する。

自動設定手段５５は、自動設定した自動プレゼント条件に関する情報を、ユーザＩＤと対応付けてデータベースサーバ２に記憶する。

自動プレゼント条件が自動設定された場合、ゲームサーバ１は、例えば図３０に例示する画面を端末装置３へ送信し、自動設定された条件をユーザに通知することが好ましい。図３０の画面の仲間指定領域２５１には、ユーザによって指定された仲間の情報２５２（アバター、名前、レベル、チーム等）が表示される。なお、図示しない仲間変更ボタンを設けて、指定する仲間を変更することができるようにしてもよい。また、画面には、自動設定されたカード条件に関する情報の表示領域２５３が設けられる。この表示領域２５３には、自動設定されたカード条件２５４、了解ボタン２５５、条件変更ボタン２５６等が表示される。図３０では、仲間Ｂを指定したことにより、「仲間のチームの投手カード（レア度４）」というカード条件２５４が自動設定された例を示している。ここで了解ボタン２７５を押せば、図３０の画面が閉じられ、図４のメイン画面に遷移する、または図２９の画面に戻る。一方、ユーザが自動設定された条件を変更したいと考えた場合、条件変更ボタン２５６を押すことにより、ユーザが任意の条件を設定することもできる。

自動設定手段５５を備えた構成により、ユーザが特定の仲間を指定するだけで、自動設定手段５５がその仲間のゲーム情報を分析し、適切なプレゼント対象のカード条件を自動的に設定するので、ユーザの操作負担を軽減することができる。

次に、ゲームサーバ１が、プレゼント対象の候補者となる仲間をユーザに報知する構成について説明する。この構成のゲームサーバ１は、図３１に示すように、候補者報知手段５６を備えている。この候補者報知手段５６は、ユーザに関係付けられた仲間のゲーム情報（例えば、プレゼント履歴、交流履歴等）に基づいて、プレゼント対象の候補者となる仲間を抽出してユーザに報知する機能を有する。

一例を挙げると、ユーザに対して頻繁にプレゼントを贈ってくれたり、挨拶やメッセージ等を送ってくれたりする仲間をプレゼント対象の候補者として抽出し、ユーザのゲーム画面に表示する。また、その中でも、最近（例えば、直近の２週間）よくユーザに対してアクセス（プレゼント、挨拶等）してくれる仲間を優先してプレゼント対象の候補者として抽出することが好ましい。かつてはよくプレゼントを贈ってくれたが、現在は殆ど贈ってくれない仲間や、途中でゲームを止めてしまった仲間もいるからである。

プレゼント対象の候補者を抽出する処理例を次に示す。ゲームサーバ１は、現在から遡る所定期間（例えば２週間）に、所定回数（例えば、３回）以上、ユーザにプレゼントを贈った仲間を、プレゼント対象の候補者として抽出する。或いは、ゲームサーバ１は、現在から遡る所定期間（例えば２週間）に、所定回数（例えば、１０回）以上、ユーザに対して交流を行った仲間を、プレゼント対象の候補者として抽出する。ここで、交流には、挨拶、メッセージ送信、プレゼント、対戦協力、チャットなどを含めることができる。また、これに限らず、ゲームの種類や内容に応じて様々な交流を適用できる。図１６に示すように、各ユーザのゲーム情報としての交流の履歴は、ユーザＩＤと対応付けてデータベースサーバ２に記憶されている。よって、ユーザの仲間の交流履歴に基づいて、現在から遡る所定期間内に、仲間がユーザに対して、何回、プレゼント等の交流を行ったかが分かる。

図３２に、プレゼント対象の候補者を報知する画面例を示す。この画面は、例えば、図１３または図２９の自動プレゼント条件を設定するための画面で、仲間リストボタン２３５を押した後に表示される仲間リスト画面である。なお、自動プレゼント条件を設定する場合だけではなく、ユーザが手動で仲間にプレゼントを行う操作をする場合にも、図３２の仲間リストを表示してもよい。

図３２の仲間リストでは、ゲームサーバ１が抽出したプレゼント対象の候補者に対して、「プレゼント対象候補」のラベル２６１を表示してユーザに報知する。この例では、現在から遡る２週間以内に、３回以上、ユーザにプレゼントをした仲間に対して、前記ラベル２６１が表示されている。また、仲間リストには、現在から遡る所定期間（例えば２週間）に、仲間がユーザにプレゼントした（または、交流した）回数の情報２６２が表示される。この回数の情報２６２の表示は、省略することもできる。

また、仲間リストの表示の優先度に関し、ユーザにプレゼントした回数が多い仲間ほど優先度を高くする（上位に表示される）ようにすることが好ましい。

ユーザによくプレゼントを贈ってくれる仲間がいても、いざその仲間を自動プレゼントの対象となる特定の仲間として指定しようとしても、ユーザがその仲間の名前等を思い出せないこともある。しかし、本構成により、よくプレゼントを贈ってくれている仲間等がプレゼント対象の候補者として報知されることにより、ユーザは円滑に特定の仲間を指定することができるようになる。

次に、自動プレゼントが行われる期間を限定できる構成について説明する。前述したように、一旦、自動プレゼントが設定された仲間であっても、ゲームへの関心がかなり希薄又はゲームを止めた仲間を、自動プレゼントの対象から除外する構成をとることができるが、これ以外に、下記のような構成とすることもできる。すなわち、ユーザからの要求に基づいて自動プレゼント条件が設定された後、延々とプレゼントを自動的に贈るのではなく、自動プレゼント条件が設定されてから所定期間（例えば１週間、１か月等）のみ、条件を満たす対象カードの入手時に自動プレゼントが実行されるよう限定するのである。これによって、マンネリ感を無くすことができる。この構成のゲームサーバ１は、自動プレゼント条件設定後、予め定められた所定期間（自動プレゼント期間）が経過すれば、自動プレゼント条件の設定を自動的に解除する。ここで、自動プレゼント期間は、ユーザが任意の期間を指定することができるようにしてもよいし、ゲームサーバ１において予め初期設定されているデフォルトの期間を使用することもできる。例えば、ユーザが自動プレゼント条件を設定する際に、自動プレゼント期間を１週間等に限定する操作を行えば、その操作に応じてゲームサーバ１が、自動プレゼントの設定日時、自動プレゼント期間（または自動プレゼントの解除予定日時）等の情報を、ユーザＩＤと対応付けて記憶装置（データベースサーバ２等）に記憶し、自動プレゼント期間を管理する。あるいは、ユーザが自動プレゼント期間を限定する操作を行わなくとも、ゲームサーバ１が自動プレゼント期間を自動的に設定し、その期間の経過後に、自動プレゼント条件の設定を自動的に解除するようにしてもよい。

自動プレゼントが行われる期間を限定するか否かをユーザが任意に設定できる場合、次のこともできる。すなわち、ある仲間の範囲に対する自動プレゼント条件については自動プレゼントが行われる期間を限定し、別の仲間の範囲に対する自動プレゼント条件については自動プレゼントが行われる期間を限定しないということも可能である。また、ある仲間の範囲に対する自動プレゼント条件については自動プレゼント期間を１週間に限定し、別の仲間の範囲に対する自動プレゼント条件については自動プレゼント期間を１か月に限定するということも可能である。

また、自動プレゼント期間の経過により自動プレゼント条件の設定が解除された場合、ゲームサーバ１がその旨をユーザに報知し、ユーザに自動プレゼント期間の再設定（実質的な自動プレゼント期間の延長）を行うか否かを問い合わせてもよい。なお、上記の構成は、前述した、仲間のアクセス日数やアクセス頻度に基づき自動プレゼントを解除する構成と併用してもよい。すなわち、本構成のように、基本的には１か月経過すれば自動プレゼントは解除されるものとするが、その１か月が経過するまでの間で、プレゼント対象の仲間のゲームへのアクセスが例えば２週間ない、といった場合には１か月を待たずに自動プレゼントを解除してもよい。つまり、自動プレゼントの固定的な解除期間（前記自動プレゼント期間）を設けつつ、仲間のアクセス頻度を優先的に見て解除の判断を行うのである。

〔ゲーム管理装置の他の構成例〕
ゲーム管理装置の他の構成例を、図３３の機能ブロック図等を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。

先ず、本実施の形態のゲーム管理装置の概略構成を説明する。前述の実施の形態では、主に自動プレゼント処理について説明したが、本実施の形態では、ユーザが入手したオブジェクトに対する自動処理が複数存在する。例えば、前述の「自動プレゼント処理」の他に、後述する「自動売却処理」、「自動合体処理」等がある。なお、自動処理については、ゲームの種類・内容に応じて様々なものが適用できる。そして、本実施の形態では、ユーザが、各自動処理の実行条件を、それぞれ独立して任意に設定することができる。よって、それぞれの自動処理に応じた適切な実行条件を設定可能である。なお、各自動処理の実行条件とし、初期設定（デフォルト）の条件を用いることもできる。そして、自動処理毎に、実行条件に関する情報が関係付けられ、ユーザがオブジェクトを入手した場合に、複数の自動処理の中から実行条件を満たす自動処理が決定されて実行される。これにより、複数の処理に対するユーザの操作負担の軽減を図ることができる。以下に、これを実現する本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。

図３３に示すように、ゲームサーバ１は、主に、自動処理手段７１、条件関係付け手段７２および制御手段７３を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

自動処理手段７１は、ユーザが入手したオブジェクト（カード等）に対して所定の自動処理を実行する機能を有する。前述のように、自動処理は複数存在し、本実施の形態では、「自動売却処理」、「自動合体処理」、「自動プレゼント処理」の３つの自動処理が存在する場合について説明する。自動処理手段７１は、自動売却処理を実行する自動売却手段７１ａ、自動合体処理を実行する自動合体手段７１ｂ、および自動プレゼント処理を実行する自動プレゼント手段７１ｃを備えている。

自動プレゼント手段７１ｃについては、前述の自動プレゼント手段５３を適用することができる。よって、自動プレゼント手段７１ｃの詳細な説明は省略する。

なお、前述の自動プレゼント手段５３では、仲間の範囲によって自動プレゼント条件を異ならせることができる構成について説明したが、本実施の形態の自動プレゼント手段７１ｃでは、仲間の範囲を定めることなく、全ての仲間に共通の自動プレゼント条件（実行条件）を設定してもよい。例えば、「レア度２以下の全ての選手カード」という自動プレゼント条件を、ユーザの全ての仲間に共通の条件としてもよい。この場合の自動プレゼント処理については、全ての仲間の中からランダムに選択した仲間にプレゼントしてもよいし、親密度の高い仲間から、順次、プレゼントしてもよい。

次に、「自動売却処理」について説明する。売却処理とは、ユーザ保有のオブジェクト（カード、アイテム等）を、ゲーム内で仮想的に売却して、ゲーム内ポイント、ゲーム内通貨等に変換する処理である。本ゲームでは、ユーザが入手したカードについて、ユーザが手動で売却処理を実行することも、予め実行条件（売却対象のカード条件）を設定することによって自動で売却処理を実行することもできる。

ユーザが手動でカードを売却する操作の一例を次に示す。ユーザが「抽選モード」等を実行することによってカードを入手した場合、図５に例示する画面に遷移し、入手したカード２１０およびカードの情報２１１が表示される。ここで、ユーザが売却ボタン２１２を押せば、図３４に例示する画面に遷移する。図３４の画面は、売却処理の実行前に表示される画面であり、表示されているカード２１０を売却した場合に獲得できる強化ポイントの情報２６３および売却処理を実行するための売却実行ボタン２６４が表示される。ここで、ユーザが売却実行ボタン２６４を押せば、ゲームサーバ１が、画面に表示されているカード２１０の売却処理を実行する。この売却処理が実行された場合、表示されているカード２１０はユーザの所有するカードから除外され、その対価としての強化ポイントがユーザの所有ポイントとして加算される。なお、売却対象のカードのレア度、能力値に応じて、対価としての強化ポイントは変動する。

このように、ユーザが手動でカードを売却するには、面倒な作業が必要である。これに対して、以下に説明する自動売却処理は、売却処理に対する実行条件を予め設定しておくだけで、ゲームサーバ１が自動的に売却処理を実行するので、ユーザの操作負担を大幅に軽減できる。

図３５には、ユーザが売却するオブジェクトの条件を任意に設定するための自動売却条件設定画面の一例を示す。この画面には、例えば「レア度１の全ての選手カード」、「レア度２以下の全ての選手カード」等の条件項目が予め表示されている。そして、ユーザがチェックボックス等により条件項目を選択するだけで簡単に、売却するカードの条件を設定できるようになっている。また、画面には、図８と同様に、チームおよびレア度の条件を設定するための入力部２２５〜２２７（プルダウンメニュー）を設けてもよい。プルダウンメニューに表示される選択肢は、設定対象の条件に応じて適宜変更可能である。入力方法はこれに限定されるものではなく、例えば、チームおよびレア度の条件を、端末装置３におけるキー入力、音声入力等により直接入力できるようにしてもよい。

また、自動売却条件設定画面には設定ボタン２２８が設けられ、このボタンを押すことにより、ユーザの端末装置３から設定情報がゲームサーバ１に送信される。ゲームサーバ１では、前記設定情報を受信し、ユーザＩＤと対応付けて、自動売却処理の実行条件をデータベースサーバ２に記憶する。

上記のようにしてユーザが予め実行条件（売却対象のカード条件）を設定しておけば、その条件を満たすカードをユーザが入手した場合、自動売却手段７１ａは、そのカードを自動的に売却する。

次に、「自動合体処理」について説明する。合体処理とは、ユーザが保有している特定のオブジェクトを、他のオブジェクトと合体させることにより、他のオブジェクトのパラメータを変更させる（能力等の強化を図る）処理である。合体処理の実行には前記売却処理で得られるゲーム内ポイント等を必要としてもよい。本実施の形態のゲームでは、ユーザが保有しているカードの中から強化対象カードを１枚指定すると共に、その強化対象カードと合体する強化素材カードを１枚以上指定し、合体処理を実行する。合体処理により、強化素材カードの能力に応じて、強化対象カードの能力が向上すると共に、ユーザが保有していた強化素材カードの保有は解除される。この「合体処理」の実行には、ユーザが保有している強化ポイントが必要である。強化ポイントの必要量は一定としてもよいし、強化対象および／または強化素材のレア度、能力等に応じて可変としてもよい。

本ゲームでは、ユーザが入手したカードについて、ユーザが手動で合体処理を実行することも、事前に実行条件（強化素材カードの条件等）を設定することによって自動で合体処理を実行することもできる。

ユーザが手動でカード同士を合体する操作の一例を次に示す。図４のメイン画面において、強化ボタン２０３ｂを押せば、強化モード画面に遷移し、ユーザが保持しているカードの中から、１枚の強化対象カードと、１枚または複数枚の強化素材カードを指定できる。図３６には、ユーザによって、１枚の強化対象カード２７１と、１枚の強化素材カード２７２とが指定された場合の強化モード画面の例を示す。この画面において、ユーザが合体実行ボタン２７３を押すことによって、強化対象カード２７１と強化素材カード２７２との合体処理が実行され、強化素材カード２７２が失われる代わりに、強化素材カード２７２の能力に応じて強化対象カード２７１の能力が向上する。

このように、ユーザが手動でカードを合体するには、面倒な作業が必要である。これに対して、以下に説明する自動合体処理は、合体処理に対する実行条件を予め設定しておくだけで、ゲームサーバ１が自動的に合体処理を実行するので、ユーザの操作負担を大幅に軽減できる。

図３７には、ユーザが自動合体処理の実行条件を任意に設定するための自動合体条件設定画面の一例を示す。この画面には、強化対象カードを指定するための領域２８１と、強化素材カードの条件を設定するための領域２８２とが設けられる。例えば、領域２８１をタップ（またはクリック）すれば、ユーザが保有しているカード一覧が表示され、その中からユーザが任意のカードを強化対象カードとして指定できる。ユーザが指定した強化対象カード２７１は、領域２８１に表示される。なお、既に強化対象になっているカードがある場合、そのカードが領域２８１に表示されるようにしてもよい。また、領域２８１に設けられたカード変更ボタン２８３を押せば、ユーザが保有しているカード一覧が表示され、強化対象カードを改めて設定することもできる。

強化素材カードの条件を設定するための領域２８２には、例えば「強化対象と同じチーム且つレア度３以下」、「レア度２以下の全ての選手カード」等の条件項目が予め表示されている。そして、ユーザがチェックボックス等により条件項目を選択するだけで簡単に、強化素材カードの条件を設定できるようになっている。また、画面には、図８と同様に、チームおよびレア度の条件を設定するための入力部２２５〜２２７（プルダウンメニュー）を設けてもよい。プルダウンメニューに表示される選択肢は、設定対象の条件に応じて適宜変更可能である。入力方法はこれに限定されるものではなく、例えば、チームおよびレア度の条件を、端末装置３におけるキー入力、音声入力等により直接入力できるようにしてもよい。

また、強化対象カードと強化素材カードとが、同じチーム、同じポジション、同じ選手等の所定条件を満たす場合、所定条件を満たさない場合と比べて強化対象カードの能力向上率（パラメータの変化率）が大きくなるようにしてもよい。この場合、強化素材カードの条件として、チームおよびレア度以外にも、「強化対象と同じポジション」、「強化対象と同じ選手」等の条件を設定できるようにしてもよい。

また、自動合体条件設定画面には設定ボタン２２８が設けられ、このボタンを押すことにより、ユーザの端末装置３から設定情報がゲームサーバ１に送信される。ゲームサーバ１では、前記設定情報を受信し、ユーザＩＤと対応付けて、自動合体処理の実行条件をデータベースサーバ２に記憶する。

上記のようにしてユーザが予め実行条件（強化素材のカード条件）を設定しておけば、その条件を満たすカードをユーザが入手した場合、自動合体手段７１ｂは、そのカードを事前に指定されている強化対象カードと自動的に合体する。

次に、図３３の条件関係付け手段７２について説明する。この条件関係付け手段７２は、複数ある自動処理毎に、実行条件に関する情報を関係付ける機能を有する。すなわち、条件関係付け手段７２は、ユーザからの要求に応じて、ある自動処理の実行条件が設定された場合、その自動処理と関係付けて実行条件に関する情報をデータベースサーバ２に記憶する。あるいは、ユーザは、各自動処理に初期設定されているデフォルトの実行条件を適用することを選択することもできる。ある自動処理についてデフォルトの実行条件が適用された場合、条件関係付け手段７２は、その自動処理と関係付けてデフォルトの実行条件に関する情報をデータベースサーバ２に記憶する。

図３８に、ユーザＩＤ＝０００００１のユーザＡが設定した各自動処理の実行条件の一例を示す。この例では、自動売却処理に対して、「レア度３以下の全ての選手カード」という実行条件が関係付けられている。また、自動合体処理に対して、「強化対象カード＝０００７」および強化素材のカード条件「強化対象と同じチーム且つレア度３以下」という実行条件が関係付けられている。また、自動プレゼント処理に対して、プレゼント対象の仲間の範囲「ユーザＩＤ＝０００００２」およびプレゼントするカードの条件「相手のチーム且つレア度３」という実行条件が関係付けられている。さらに、自動プレゼント処理については、プレゼント対象の仲間の範囲「ユーザＩＤ＝００００１０」およびプレゼントするカードの条件「レア度２以下の全ての選手カード」という実行条件も関係付けられている。

なお、図３８の例では、各自動処理に対して優先度が設定されている好ましい形態を示しているが、優先度の設定は必須ではなく省略することもできる。優先度については後述する。

このように、ユーザＩＤと対応づけて、複数の自動処理と、それぞれの実行条件とを関係付けた情報が、データベースサーバ２に記憶されている。ユーザは、各自動処理に、任意の条件を設定できる。また、いずれの自動処理についても、それを採用するか否かはユーザの任意で選択できる。例えば、自動売却処理および自動合体処理は実行されるが、自動プレゼント処理は実行されないようにしてもよい。ある自動処理を採用しない場合、その自動処理には実行条件が関係付けられない（例えば、実行条件欄を空白とする又は実行条件の有効／無効を切り替えるフラグを無効に設定してもよい）。

次に、図３３の制御手段７３について説明する。この制御手段７３は、ユーザがカードを入手した場合に、複数の自動処理のうち、実行条件を満たす特定の自動処理を決定し、決定した自動処理を実行させる機能を有する。ユーザが入手したカードが、複数の自動処理の条件を満たすこともあり得る。この場合、制御手段７３が、実行する自動処理をランダムに決定してもよいし、予め設定されている優先度に基づいて実行する自動処理を決定してもよい。

ここで、ゲームサーバ１による自動処理の例を、図３９のフローチャートを参照しながら以下に説明する。例えば、ユーザＡがスカウトモード、抽選モード等のゲームを実行し、新たにカードを入手した場合（Ｓ１１でＹＥＳ）、ゲームサーバ１は、ユーザＡが予め設定している自動処理の実行条件（図３８参照）を、データベースサーバ２から取得する（Ｓ１２）。その後、ゲームサーバ１は、ユーザＡが入手したカードが、複数の自動処理の実行条件の何れかを満足するか否かを判断する（Ｓ１３）。

例えば、ユーザＡが入手したカードが、「チームＴ」で「レア度３」のカードであったものとする。また、図３８に示す自動処理の実行条件を適用するものとする。この場合、自動売却処理については、実行条件「レア度３以下の全ての選手カード」を満たす。また、自動合体処理については、強化対象カード「選手ＩＤ＝０００７」の所属チームが「チームＴ」の場合のみ、実行条件「強化対象と同じチーム且つレア度３以下」を満たす。「選手ＩＤ＝０００７」の所属チームは、選手データベース（図１７参照）より取得できる。また、自動プレゼント処理については、プレゼント対象の仲間「ユーザＩＤ＝０００００２」の希望チームが「チームＴ」の場合のみ、実行条件「相手のチーム且つレア度３」を満たす。「ユーザＩＤ＝０００００２」の希望チームは、ユーザ情報データベース（図１６参照）より取得できる。

ステップＳ１３において、複数の自動処理の実行条件の何れかを満足する場合（Ｓ１３でＹＥＳ）、ゲームサーバ１は、実行する自動処理を決定する（Ｓ１４）。ここで、１つの自動処理の実行条件のみ満たしている場合は、それが実行する自動処理として決定される。また、複数の自動処理の実行条件を満たしている場合、ゲームサーバ１は、その中の１つの自動処理を例えばランダムに決定する。あるいは、ゲームサーバ１は、予め設定されている各自動処理の優先度に基づいて、より優先度の高い自動処理を実行対象として決定してもよい。

その後、ゲームサーバ１は、ステップＳ１４で決定された自動処理を実行する（Ｓ１５）。実行された自動処理が自動売却処理の場合、ゲームサーバ１は、ユーザが入手したカードを売却して強化ポイントに変換する。この場合、ユーザが入手したカードがユーザの保有カードとはならず、強化ポイントが加算されるように、ユーザ情報データベースが更新される。また、実行された自動処理が自動合体処理の場合、ゲームサーバ１は、ユーザが入手したカード（強化素材）を予め設定されている強化対象カードに合成し、強化対象カードの能力値を向上させる。この場合、所定の演出表示（動画表示等）が行われるようにしてもよい。自動合体処理が実行された場合、ユーザが入手したカードがユーザの保有カードとはならず、強化対象カードの能力値が合体後の値に更新される。また、実行された自動処理が自動プレゼント処理の場合、ゲームサーバ１は、ユーザが入手したカードを、予め設定されているプレゼント対象の仲間に贈る。この場合、ユーザが入手したカードがユーザの保有カードとはならず、プレゼント先の仲間の保有カードとなるようにユーザ情報データベースが更新される。なお、仲間がプレゼントの受領操作をすることによって、プレゼントされたカードが仲間の保有カードとなるようにしてもよい。

自動処理が実行された場合、ゲームサーバ１は、その旨をユーザに報知する（Ｓ１６）。例えば、自動プレゼント処理が実行された場合、前述のように、ゲームサーバ１は、図２６に例示する報知画面を生成し、ユーザの端末装置３に送信する。また、自動売却処理が実行された場合、ゲームサーバ１は、図４０に例示する報知画面をユーザの端末装置３に送信する。この報知画面には、売却したカード２８５および売却により増加した所持ポイントの情報２８６等が表示される。また、自動合成処理が実行された場合、ゲームサーバ１は、図４１に例示する報知画面をユーザの端末装置３に送信する。この報知画面には、ユーザが入手して強化素材として使われたカード２８７、自動合体処理により消費された強化ポイントの情報２８９、強化対象カードの能力向上の情報２９０等が表示される。

一方、図３９のステップＳ１３において、ユーザが入手したカードが何れの自動処理の実行条件も満たさなかった場合（Ｓ１３でＮＯ）、自動処理が実行されることなく図３９の処理を終了する。この場合、ユーザが入手したカードは、ユーザ自身の所有物となる。

以上のように、本実施の形態のゲーム管理装置は、図３３に示す自動処理手段７１、条件関係付け手段７２および制御手段７３等を備えている構成であり、複数存在する自動処理毎に、実行条件を関係付けるので、それぞれの自動処理に応じた適切な実行条件を任意に設定することができる。そして、ユーザがオブジェクトを入手した場合に、複数の自動処理の中から実行条件を満たす特定の自動処理が決定されて実行されるので、複数の処理に対するユーザの操作負担が軽減される。

次に、各自動処理に優先度を設定する構成について説明する。この構成のゲームサーバ１は、図４２に示すように、優先度設定手段７４を備えている。この優先度設定手段７４は、前記複数の自動処理に対して、処理の優先順位を示す優先度を予め設定する機能を有する。ここで、各自動処理の優先度は、ユーザからの要求に応じて設定することもできるし、初期設定（デフォルト）の優先度を用いることもできる。

ユーザが任意に優先度を定めるための優先度設定画面の一例を、図４３に示す。この画面には、優先度設定領域２９１および設定ボタン２９２が表示される。優先度設定領域２９１では、「自動売却処理」、「自動合体処理」、「自動プレゼント処理」を優先度の高い順に並べることによって優先度を設定できる。例えば、各自動処理の表示をドラッグしてドロップすれば並び順を変更できる。また、例えば、各自動処理の表示をダブルクリック（ダブルタップ）すれば、その自動処理に設定されている現在の実行条件を確認・変更できるようにしてもよい。この画面で設定ボタン２９２を押せば、ユーザの端末装置３から設定情報がゲームサーバ１に送信される。ゲームサーバ１では、前記設定情報を受信し、ユーザＩＤと対応付けて、各自動処理の優先度をデータベースサーバ２に記憶する（図３８参照）。このように、本実施の形態では、複数ある自動処理に対して、ユーザが任意に優先順位をつけることができる。

本実施の形態の制御手段７３は、ユーザが入手したカードが各自動処理の対象となるか否かを、優先度順に判断する。一例を挙げると、（Ａ）自動売却処理、（Ｂ）自動合体処理、（Ｃ）自動プレゼント処理とし、この順に優先度が予め設定されているものとする。この場合、ユーザが入手したカードについて、（Ａ）→（Ｂ）→（Ｃ）の順に自動処理の対象となるか否かが判断される。そして、該当する自動処理があれば、その処理が実行される。なお、ユーザが入手したカードによっては、前記の（Ａ）および（Ｂ）の両方の自動処理の実行条件を満足する場合もあるが、より優先度の高い（Ａ）の自動処理の実行条件を満たせば、その段階で（Ａ）の自動処理が実行される。いずれの自動処理の条件も満たさなかった場合、自動処理は実行されることなく、ユーザが入手したカードは当該ユーザの保有物となる。

図４４のフローチャートは、優先度に基づいて自動処理を実行するゲームサーバの動作例を示している。ここでは、優先度を変数ｎとした処理フローを例示する。

ユーザがカードを入手した場合（Ｓ２１でＹＥＳ）、変数ｎを「１」に初期化する（Ｓ２２）。その後、ゲームサーバ１は、ユーザＩＤに対応付けられた複数の自動処理の実行条件（図３８参照）の中から、第１優先の自動処理の実行条件を取得する（Ｓ２３）。そして、ゲームサーバ１は、ユーザが入手したカードが、前記実行条件を満たすか否かを判断する（Ｓ２４）。ここで、実行条件を満たす場合（Ｓ２４でＹＥＳ）、第１優先の自動処理を実行し（Ｓ２５）、その旨をユーザに報知する（Ｓ２６）。

一方、ステップＳ２４で実行条件を満たさなかった場合（Ｓ２４でＮＯ）、変数ｎがインクリメントされて、ｎ＝２となる（Ｓ２７）。その後、変数ｎが３よりも大きいか否かが判断される（Ｓ２８）。このステップＳ２８は、３つある自動処理の全てについての判断が行われたか否かを判定するためのステップである。ｎ＝２の場合（Ｓ２８でＮＯ）、ステップＳ２３に戻って、ゲームサーバ１は第２優先の自動処理の実行条件を取得する。そして、ゲームサーバ１は、ユーザが入手したカードが、前記実行条件を満たすか否かを判断する（Ｓ２４）。ここで、実行条件を満たす場合（Ｓ２４でＹＥＳ）、第２優先の自動処理を実行し（Ｓ２５）、その旨をユーザに報知する（Ｓ２６）。

一方、第２優先の自動処理の実行条件も満たさなかった場合（Ｓ２４でＮＯ）、変数ｎがインクリメントされて、ｎ＝３となる（Ｓ２７）。ｎ＝３の場合（Ｓ２８でＮＯ）、ステップＳ２３に戻って、ゲームサーバ１は第３優先の自動処理の実行条件を取得する。そして、ゲームサーバ１は、ユーザが入手したカードが、前記実行条件を満たすか否かを判断する（Ｓ２４）。ここで、実行条件を満たす場合（Ｓ２４でＹＥＳ）、第３優先の自動処理を実行し（Ｓ２５）、その旨をユーザに報知する（Ｓ２６）。

一方、第３優先の自動処理の実行条件も満たさなかった場合（Ｓ２４でＮＯ）、変数ｎがインクリメントされて、ｎ＝４となる（Ｓ２７）。ｎ＝４の場合（Ｓ２８でＹＥＳ）、自動処理が実行されることなく図４４の処理を終了する。この場合、ユーザが入手したカードは、ユーザ自身の所有物となる。

なお、この例では自動処理が３つの場合を例示したが、自動処理が２つ又は４つ以上であってもよい。

次に、各自動処理に設定された優先度を自動的に変更する構成について説明する。この構成のゲームサーバ１は、図４５に示すように、優先度変更手段７５を備えている。この優先度変更手段７５は、ユーザのゲーム状況に応じて、前記優先度を自動的に変更する機能を有する。ここで、ユーザのゲーム状況とは、ユーザが保有するゲーム内ポイント等の保有物の増減の状況、他のユーザからプレゼントを貰った後に返礼のプレゼントをしたか否かの状況等をいう。

本構成により、ユーザのゲーム状況に応じて、複数の自動処理に対する優先度が自動的に変更されるので、ゲーム状況が変わる都度、ユーザが優先度を変更する操作を行う必要がなくなり、ユーザの操作負担の軽減を図ることができる。以下に、優先度を自動的に変更する具体例について説明する。

先ず、複数の自動処理の中に、ユーザの保有物（ゲーム内ポイント、アイテム等）を消費する第１自動処理を含む場合について説明する。本実施の形態では、強化ポイントを消費してカード同士を合体させる自動合体処理が、第１自動処理に該当する。

第１自動処理は、自動合体処理に限定されない（合体という形態をとらなくてもよい）。例えば、ユーザが入手した選手キャラクタが練習相手となり、ユーザの保有する練習チケットアイテムを消費して、強化対象の選手キャラクタと練習を行うことにより、強化対象の選手キャラクタの能力パラメータを向上させる自動処理も、第１自動処理に含まれる。第１自動処理には、ユーザの保有物を消費する様々な自動処理が含まれるが、ここでは、第１自動処理を自動合体処理として説明する。

本実施の形態の優先度変更手段７５は、ユーザが保有する強化ポイントの量が閾値未満の場合に、自動合体処理の優先度を、予め設定されている優先度よりも低下させる。ここで、閾値を、自動合体処理に必要な最低限度の値とすることができる。この場合、強化ポイントの量が閾値未満になれば、ポイント不足で自動合体処理が実行できないゲーム状況になる。なお、閾値を、最低限度の値よりも大きくし、ポイント不足になる前に、自動合体処理の優先度を、予め設定されている優先度よりも低下させてもよい。

図４６のフローチャートに、ユーザのゲーム状況（保有ポイントの増減）に応じた優先度変更処理の一例を示す。例えば、ユーザが優先度を、自動合体処理→自動売却処理→自動プレゼント処理に設定しているものとする。ここで、ユーザが保有する強化ポイントが閾値である１０００ポイント未満になれば（Ｓ３１でＹＥＳ）、優先度変更手段７５が、例えば自動合体処理の優先度を最下位に変更する（Ｓ３２）。すなわち、優先度は、自動売却処理→自動プレゼント処理→自動合体処理となる。なお、自動合体処理の優先度を１段階だけ下げて、自動売却処理→自動合体処理→自動プレゼント処理としてもよい。

なお、優先度変更手段７５は、優先度を自動的に変更した場合、後で元に戻すことが出来るように、元のユーザ設定の優先度の情報を記憶装置に記憶する。

その後、ユーザが保有する強化ポイントが、例えば１００００ポイント以上になり（Ｓ３３でＹＥＳ）、強化ポイントを消費する自動合体処理を、余裕をもって実行できるようになれば、優先度変更手段７５は、自動的に元のユーザ設定の優先度に戻す（Ｓ３４）。

本構成により、保有ポイント（保有物）の消費を伴う自動合体処理がある場合に、その保有ポイントが閾値未満になった状況で自動合体処理の優先度が自動的に低下し、例えば保有ポイントを増加させる自動売却処理が優先される状況を自動的に構築することができる。これにより、保有ポイントの減少をユーザが把握して自動処理の優先度を変更する操作を行う必要がなくなり、ユーザの操作負担の軽減を図ることができる。

次に、複数の自動処理の中に、ユーザの保有物（ポイント等）を消費する第１自動処理と、ユーザが入手したオブジェクトを第１自動処理で使用される保有物に変換する第２自動処理と、を含む場合について説明する。本実施の形態では、強化ポイントを消費してカード同士を合体させる自動合体処理が、第１自動処理に該当する。また、ユーザが入手したカードを売却して強化ポイントに変換する自動売却処理が、第２自動処理に該当する。なお、第２自動処理は、自動売却処理に限定されない（売却という形態をとらなくてもよい）。ここでは、第１自動処理を自動合体処理、第２自動処理を自動売却処理として説明する。

本実施の形態の優先度変更手段７５は、ユーザの保有する強化ポイントの量に応じて、図４７のフローチャートに例示する優先度の変更処理を自動的に行う。すなわち、優先度変更手段７５は、ユーザが保有する強化ポイントの量が第１閾値（例えば１００００ポイント）以上になるまでは、自動売却処理の優先度を自動合体処理の優先度よりも高くする（Ｓ４１）。これにより、ユーザが保有する強化ポイントがまだ少ないうちは、自動売却処理を優先させて強化ポイントが蓄積され易くする。

さらに、優先度変更手段７５は、ユーザが保有する強化ポイントの量が第１閾値（１００００ポイント）以上になった後（Ｓ４２でＹＥＳ）、第１閾値以下の第２閾値（例えば１０００ポイント）よりも小さくなるまで、自動合体処理の優先度を自動売却処理の優先度よりも高くする（Ｓ４３）。これにより、強化ポイントがある程度蓄積された後はそれを消費する自動合体処理を優先させ、選手カードの強化が行われ易くする。

また、優先度変更手段７５は、ユーザが保有する強化ポイントの量が第２閾値（１０００ポイント）よりも小さくなった場合（Ｓ４４でＹＥＳ）、ステップＳ４１に戻り、再び自動売却処理の優先度を自動合体処理の優先度よりも高くする。

なお、前記第２閾値は、自動合体処理に必要な最低限度の値としてもよいし、それよりも大きい値としてもよい。また、図４７の例では、第１閾値よりも第２閾値を小さくし、ヒステリシス制御を行うようにしているが、第１閾値と第２閾値とを同じ値にすることもできる。

本構成により、保有ポイント（保有物）の消費を伴う自動合体処理と、ポイントを獲得することができる自動売却処理との優先度を、保有ポイントの増減によって自動的に切り替えることができる。これにより、保有ポイントの増減をユーザが把握して自動処理の優先度を変更する操作を行う必要がなくなり、ユーザの操作負担の軽減を図ることができる。

次に、複数の自動処理の中に、自動プレゼント処理を含む場合について説明する。例えば、第２のユーザからプレゼントを受け取った第１のユーザが、相手に返礼する適切なカードが手元にない等の理由により、後で返礼しようとすることもある。ここでは、第１のユーザをユーザＡ、第２のユーザをユーザＡの仲間Ｂとして説明する。ユーザＡが、仲間Ｂをプレゼント対象の仲間の範囲とする自動プレゼント処理の実行条件を設定している場合（図３８参照）、本実施の形態の優先度変更手段７５は、次のように動作する。すなわち、優先度変更手段７５は、仲間ＢからユーザＡにプレゼントが行われた場合であって、ユーザＡから仲間Ｂにプレゼントが行われなかった場合に、自動プレゼント処理を、予め設定されている優先度よりも高くする。これにより、ユーザＡから仲間Ｂに、早期に返礼のプレゼントが行われるようになる。

図４８のフローチャートに、ユーザＡのゲーム状況（プレゼントのやり取り）に応じた優先度変更処理の一例を示す。ここでは、ユーザＡが仲間Ｂからプレゼントを受け取った場合を例に挙げる。

ゲームサーバ１は、ユーザＡが仲間Ｂからカード等のプレゼントを受領した後（Ｓ５１でＹＥＳ）、仲間Ｂに対して返礼のプレゼントをしたか否かを判定する（Ｓ５２）。「ユーザＡが仲間Ｂに返礼のプレゼントをしなかった」と判定する例を、下記（ａ）〜（ｃ）に示す。

（ａ）仲間ＢからユーザＡにプレゼントが行われたときに、ユーザＡが受領操作をすることによってはじめて、プレゼントされたアイテム等がユーザＡの所有となる形態（受領操作要の形態）のプレゼントについては、ユーザＡが受領操作を行ったときに返礼のプレゼントの操作をしなかったことをもって判定する。

（ｂ）仲間ＢからユーザＡにプレゼントが行われたときに、プレゼントされたアイテム等が直ちにユーザＡの所有となる形態（受領操作不要の形態）のプレゼントについては、ユーザＡがプレゼントを受け取った事実を画面上で確認したときに、返礼のプレゼントの操作をすることなく当該画面を終了（または他の画面へ遷移）したことをもって判定する。

（ｃ）仲間ＢからユーザＡにプレゼントが行われたときから所定時間（例えば２４時間）以内にユーザＡから仲間Ｂに返礼のプレゼントが行われなかったことをもって判定する（受領操作要および不要の何れの形態にも適用可）。

ステップＳ５２において、ゲームサーバ１は、ユーザＡが仲間Ｂに返礼のプレゼントをしなかったと判定した場合（Ｓ５２でＮＯ）、仲間Ｂをプレゼント対象とする自動プレゼント処理の実行条件が設定されているか否かを判断する（Ｓ５３）。この判断は、ユーザＡのユーザＩＤと対応付けて記憶されている、図３８の自動処理の実行条件の設定情報を確認することにより可能である。図３８の例では、仲間Ｂ（ユーザＩＤ＝０００００２）をプレゼント対象の仲間の範囲とする実行条件が設定されているので、ステップＳ５３はＹＥＳとなる。

ステップＳ５３でＹＥＳの場合、自動プレゼント処理の優先度を最上位に変更する（Ｓ５４）。なお、自動プレゼント処理の優先度は、予め設定されている優先度よりも高くすればよいので、必ずしも最上位にしなくてもよい。ただし、返礼のプレゼントは出来るだけ早期に行われる方がよいので、自動プレゼント処理の優先度を最上位にすることが好ましい。

ところで、図３８の自動プレゼント処理の実行条件としては、仲間Ｂ（ユーザＩＤ＝０００００２）をプレゼント対象とする「相手のチーム且つレア度３」という条件と、仲間Ｃ（ユーザＩＤ＝００００１０）をプレゼント対象とする「レア度２以下の全ての選手カード」という異なる複数の条件が設定されている。この場合、返礼対象となるのは、仲間Ｂだけである。よって、仲間Ｂをプレゼント対象とする自動プレゼント処理の優先度のみを、予め設定されている優先度よりも高くし、仲間Ｂをプレゼント対象としない自動プレゼント処理の優先度を高くしないことも可能である。例えば、予め設定されている優先度を、自動売却処理→自動合体処理→自動プレゼント処理とする。これを優先度変更後は、自動プレゼント処理（仲間Ｂを対象）→自動売却処理→自動合体処理→自動プレゼント処理（仲間Ｃを対象）とする。

ステップＳ５４の後、ユーザＡから仲間Ｂへのプレゼントが実行された場合（Ｓ５５でＹＥＳ）、ゲームサーバ１は、自動的に元のユーザ設定の優先度に戻す（Ｓ５６）。ここで、ユーザＡから仲間Ｂへのプレゼントは、自動プレゼント処理によるものであってもよいし、ユーザの手動操作によるものであってもよい。

一方、ステップＳ５２において、ユーザＡが仲間Ｂに返礼のプレゼントをした場合（Ｓ５２でＹＥＳ）、またはステップＳ５３において仲間Ｂをプレゼント対象とする自動プレゼント処理の実行条件が設定されていない場合（Ｓ５３でＮＯ）、優先度を変更することなく処理を終了する。

本実施の形態の構成により、ユーザが返礼のプレゼントを行わなかった場合に、優先度を変更する操作を行わなくとも自動的に自動プレゼント処理の優先度が高められるので、ユーザの操作負担の軽減を図ることができる。

次に、複数の自動処理に優先度をつけながらも、各自動処理が万遍なく行われるようにする構成について説明する。この構成の優先度変更手段７５は、同一の自動処理の実行回数が所定回数に到達した場合、当該自動処理の優先度を、予め設定されている優先度よりも低下させる機能を有する。一例を以下に説明する。

例えば、（Ａ）自動売却処理→（Ｂ）自動合体処理→（Ｃ）自動プレゼント処理の順に、優先度が予め設定されているものとする。ユーザがカードを入手した場合、基本的には、図４４の処理フローに基づき、予め設定されている優先度の順に自動処理の実行条件を満たすか否かが判断され、条件を満たす自動処理が実行される。ここで、例えば（Ａ）の実行回数が所定回数（例えば１０回）に到達すれば、（Ａ）の優先度を１段階以上低下させる。例えば（Ａ）の優先度を最下位とする。よって、次回、ユーザがカードを入手した場合には、第２優先の（Ｂ）が第１優先とみなされ、先ず（Ｂ）の実行条件を満たすかが判断される。ここで、（Ｂ）の実行条件を満たさなければ、次に（Ｃ）の実行条件を満たすかが判断され、その条件も満たさない場合に（Ａ）に戻って実行条件を満たすかが判断される。

図４９のフローチャートに、自動処理の実行回数に応じた優先度変更処理の一例を示す。

ゲームサーバ１は、ユーザのゲーム中に実行される各自動処理（自動売却処理、自動合体処理、自動プレゼント処理等）の実行回数の情報を、ユーザＩＤと対応づけて、記憶装置（データベースサーバ２等）に記憶して管理している。ゲームサーバ１は、先ず、各自動処理の実行回数を初期化する（Ｓ７１）。この初期化により、各自動処理の実行回数は「０」に設定される。

その後、ユーザが入手したカードに対して、何れかの自動処理が実行された場合（Ｓ７２でＹＥＳ）、ゲームサーバ１は、実行された自動処理の実行回数をインクリメントする（Ｓ７３）。そして、ゲームサーバ１は、その自動処理の実行回数が１０回に到達したか否かを判断する（Ｓ７４）。自動処理の実行回数が１０回に到達していない場合（Ｓ７４でＮＯ）、ステップＳ７２に戻って、次に何れかの自動処理が実行されるまで待機する。

一方、自動処理の実行回数が１０回に到達した場合（Ｓ７４でＹＥＳ）、ゲームサーバ１は、その自動処理の優先度を最下位に変更する（Ｓ７５）。また、ゲームサーバ１は、その自動処理の実行回数を初期化し（Ｓ７６）、ステップＳ７２に戻って、次に何れかの自動処理が実行されるまで待機する。

この処理フローにより、実行回数が１０回に到達した自動処理の優先度が最下位に変更され、その他の自動処理の優先度が繰り上げられる。これを繰り返すことにより、各自動処理の優先度が順次入れ替わり、複数の自動処理が万遍なく行われ易くなる。

ところで、上記では、同一の自動処理の実行回数が所定回数に到達した場合、その自動処理の優先度を自動的に低下させる構成について説明したが、次のようにしてもよい。すなわち、同一の自動処理の実行回数が所定回数に到達した場合には、ゲームサーバ１がユーザにその旨を報知する。例えば、ゲームサーバ１が報知画面を生成してユーザの端末装置３に送信する。また、この報知の際、ゲームサーバ１は自動処理の優先度および／または自動処理の実行条件をそのまま継続するか否かをユーザに問い合わせてもよい。

すなわち、ある自動処理の実行回数が所定回数に到達したことを契機として、ユーザにその旨を報知することによって、自動処理の設定を見直す機会を与える。ユーザは、自動処理をそのまま継続したり、自動処理の実行条件を変更したり、各自動処理の優先度を変更したり、あるいは今後の自動処理を中止したりすることができる。

〔ゲームシステムの他の構成例〕
前述の各実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各ユーザの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであり、サーバ（ゲームサーバ１およびデータベースサーバ２）によってゲーム管理装置を構成する例である。この構成は、前述のように、ブラウザゲーム、ソーシャルゲーム、クラウドゲーミング等のサービスをユーザに提供するのに適した構成であるが、ゲーム管理装置の構成はこれに限定されない。

例えば、ゲームサーバ１が、各ユーザのゲーム情報を管理し、ゲーム内でのユーザ間の交流等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置側にて行われるゲームシステムにも適用できる。

すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置が、インターネット通信、無線ＬＡＮ通信、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信、または有線ＬＡＮ通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。

そして、サーバと端末装置とは互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信制御部等を備えた情報処理装置（コンピュータ）であって、同様のハード構成を有する。よって、サーバと端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、サーバ又は端末装置の何れか一方が備えていればよい。すなわち、ゲーム管理装置は、互いに通信して各種データの送受を行うサーバおよび端末装置に設けられる構成とすることができ、前述の実施の形態と同様の作用効果を奏する。

例えば、図１８Ａではゲームサーバ１が、仲間管理手段５１、設定手段５２および自動プレゼント手段５３を備えていたが、図５０に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図５０に示すサーバのハード構成は、図２に示したゲームサーバ１と同様であり、端末装置のハード構成は、図３に示した端末装置３と同様である。図５０には、サーバ１０１に仲間管理手段５１を設けると共に、端末装置３０１に設定手段５２および自動プレゼント手段５３を設ける構成例を示している。なお、図５０はゲームシステムの構成の一例であり、他の構成も可能である。

また、図５１に示すように、端末装置３０１が、仲間管理手段５１、設定手段５２および自動プレゼント手段５３を備えている構成とすることもできる。すなわち、ゲーム管理装置をゲーム端末である端末装置３０１それ自体に実装することができ、この場合も前述の実施の形態と同様の作用効果を奏する。この場合、サーバ１０１が、各ユーザのゲーム情報を管理したり、端末装置３０１間で行われる挨拶やメッセージの送受等のサービスをユーザに提供したりするが、その他の処理は全て端末装置３０１側で実行されるようにすることができる。あるいは、各ユーザのゲーム情報の管理も、各ユーザの端末装置３０１側で行うこともできる。

同様に、図３３ではゲームサーバ１が、自動処理手段７１、条件関係付け手段７２および制御手段７３を備えていたが、図５２に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。図５２には、サーバ１０２に条件関係付け手段７２および制御手段７３を設けると共に、端末装置３０２に自動処理手段７１を設ける構成例を示している。なお、図５２はゲームシステムの構成の一例であり、他の構成も可能である。また、図５３に示すように、端末装置３０２が、自動処理手段７１、条件関係付け手段７２および制御手段７３を備えている構成とすることもできる。この場合も前述の実施の形態と同様の作用効果を奏する。

また、前述の親密度付与手段５４、自動設定手段５５、候補者報知手段５６、優先度設定手段７４、優先度変更手段７５等についても、サーバ側だけではなく、端末装置（ゲーム端末）側に設けることもできる。

〔その他の実施の形態〕
前記の実施の形態では、ユーザと関連付けがなされている他のユーザを仲間とする例を示したが、ユーザと関連付けがなされている他のユーザであれば、仲間という関係でなくても本発明を適用できる。

また、各種情報を記憶装置に記憶する記憶制御機能を有する構成（ユーザ情報記憶制御手段６０など）に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム管理装置（またはゲームシステム）の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ１が有するＲＡＭ１３や補助記憶装置１４、データベースサーバ２、端末装置３が有するＲＡＭ３３や補助記憶装置３９、あるいはゲーム管理装置や端末装置とは別構成のファイルサーバ（オンラインストレージ）等であってもよい。

また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。

また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてサーバ、端末装置（ゲーム端末）のＣＰＵにより実行される。また、プログラムをサーバ等に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。

１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
４ ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
５０ 除外手段
５１ 仲間管理手段（管理手段）
５２ 設定手段
５３ 自動プレゼント手段
５４ 親密度付与手段
５５ 自動設定手段
５６ 候補者報知手段
７１ 自動処理手段
７１ａ 自動売却手段
７１ｂ 自動合体手段
７１ｃ 自動プレゼント手段
７２ 条件関係付け手段
７３ 制御手段
７４ 優先度設定手段
７５ 優先度変更手段
１０１、１０２ サーバ（ゲーム管理装置、ゲームシステム）
３０１、３０２ 端末装置（ゲーム管理装置、ゲームシステム）

Claims (10)

1. ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段と、
   前記自動処理は複数存在し、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段と、
   ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段と、を備えているゲーム管理装置。
2. 前記複数の自動処理に対して、処理の優先順位を示す優先度を予め設定する優先度設定手段をさらに備えている請求項１に記載のゲーム管理装置。
3. ユーザのゲーム状況に応じて、前記優先度を自動的に変更する優先度変更手段をさらに備える請求項２に記載のゲーム管理装置。
4. 前記自動処理には、ユーザの保有物を消費する第１自動処理を含み、
   前記優先度変更手段は、前記保有物の量が閾値未満の場合に、前記第１自動処理の優先度を、予め設定されている優先度よりも低下させる請求項３に記載のゲーム管理装置。
5. 前記自動処理には、
   ユーザの保有物を消費する第１自動処理と、
   ユーザが入手したオブジェクトを前記保有物に変換する第２自動処理と、
   を含み、
   前記優先度変更手段は、前記保有物の量が第１閾値以上になるまでは、前記第２自動処理の優先度を前記第１自動処理の優先度よりも高くすると共に、前記保有物の量が前記第１閾値以上になった後、前記第１閾値以下の第２閾値よりも小さくなるまで、前記第１自動処理の優先度を前記第２自動処理の優先度よりも高くする請求項３に記載のゲーム管理装置。
6. 前記自動処理には、第１のユーザが入手したオブジェクトを予め設定している第２のユーザにプレゼントする自動プレゼント処理を含み、
   前記優先度変更手段は、第２のユーザから第１のユーザにプレゼントが行われた場合であって、第１のユーザから第２のユーザにプレゼントが行われなかった場合に、前記自動プレゼント処理の優先度を、予め設定されている優先度よりも高くする請求項３ないし５の何れか１項に記載のゲーム管理装置。
7. 同一の自動処理の実行回数が所定回数に到達した場合、当該自動処理の優先度を、予め設定されている優先度よりも低下させる優先度変更手段をさらに備えている請求項２に記載のゲーム管理装置。
8. サーバと、当該サーバとの間で通信を行う端末装置と、を含むゲームシステムであって、
   ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段、
   前記自動処理は複数存在し、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段、
   ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段、を前記サーバ又は前記端末装置の何れか一方が備えるゲームシステム。
9. ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、
   コンピュータが、ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理ステップと、
   前記自動処理は複数存在し、コンピュータが、自動処理毎に、実行条件に関する情報を関係付ける条件関係付けステップと、
   ユーザがオブジェクトを入手した場合に、コンピュータが、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御ステップと、を含むゲーム管理方法。
10. コンピュータを、ゲームを管理するゲーム管理装置として動作させるためのプログラムであって、
    前記コンピュータを、
    ユーザが入手したオブジェクトに対して所定の自動処理を実行する自動処理手段、
    前記自動処理は複数存在し、自動処理毎に、実行条件に関する情報を関係付ける条件関係付け手段、
    ユーザがオブジェクトを入手した場合に、前記複数の自動処理のうち、前記実行条件を満たす自動処理を決定し、決定した自動処理を実行させる制御手段、
    として機能させるためのプログラム。
    
    

Images