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

Abstract

【課題】ユーザに関係付けられた仲間等の他のユーザにプレゼントを行い易い環境をユーザに提供してプレゼントを促進する。
【解決手段】ゲーム管理装置は、ユーザの仲間を管理する仲間管理手段５１と、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段５２と、前記保有解除処理に対して報知条件を関係付ける条件関係付け手段５３と、保有解除処理のためのオブジェクトがユーザによって指定されたとき、仲間のゲーム情報に基づいて、報知条件を満たすか否かを判定する判定手段５４と、報知条件を満たすと判定されたときに、保有解除処理の実行前に、指定されたオブジェクトの仲間への有益性に関する情報をユーザに報知する報知手段５５と、を備えている。
【選択図】図１５

Description

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

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

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

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

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

従来のゲームシステムにおいて、ユーザが仲間に対してプレゼントを行う場合には、自分が保有しているアイテムの中から、自分が保有し続けたいものでなく、且つ、相手が欲しいと思うようなものを自分で探し出し、プレゼントの操作を行うという作業が発生する。このように、ユーザが仲間にプレゼントをするには、プレゼント対象のアイテムを探し出すという面倒な作業が必要であることから、プレゼントを積極的に行わないユーザも存在する。

本発明は、上記の問題に鑑みてなされたものであり、その目的は、ユーザと所定の関連付けがなされている仲間やグループ員などの他のユーザにプレゼントを行い易い環境をユーザに提供してプレゼントを促進することである。

１）本発明の一局面によるゲーム管理装置（1,2,101,102,301,302）は、ユーザに関係付けられた他のユーザを管理する管理手段（51）と、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段（52）と、前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付け手段（53）と、前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定手段（54）と、前記判定手段（54）によって前記報知条件を満たすと判定されたときに、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知手段（55）と、を備えている。

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

本ゲーム管理装置は、ユーザと所定の関連付けがなされている仲間やグループ員などの他のユーザを管理する管理手段を備えている。ここで、仲間とは、ゲーム内で構築されるユーザ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。なお、ユーザと関連付けがなされている他のユーザであれば、仲間という関係でなくてもよい。但し、以降の説明では、便宜上、「ユーザに関係付けられた他のユーザ」を、それを代表して「仲間」と記載する。

また、本ゲーム管理装置は、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段を備えている。保有解除処理の例としては、「売却処理」、「ミキサー処理」、「合体処理」等がある。「売却処理」とは、ユーザ保有のオブジェクト（アイテム等）を売却してゲーム内ポイント等に変換する処理である。「ミキサー処理」とは、ユーザが保有している複数の（例えば２つの）オブジェクトを、別の１つまたは複数のオブジェクトに交換する処理である。「合体処理」とは、ユーザが保有している特定のオブジェクト（選手カード等）を、他のオブジェクトと合体させることにより、他のオブジェクトのパラメータを変更させる（能力等の強化を図る）処理である。「売却処理」、「ミキサー処理」、「合体処理」の何れの処理でも、処理対象のオブジェクトのユーザの保有は解除される。なお、保有解除処理はこれらに限定されるものではなく、ユーザが保有しているオブジェクトの保有解除を伴う他の処理であってもよい。

そして、本構成では、保有解除処理のためのオブジェクトがユーザによって指定されたとき、保有解除処理の実行前に、指定されたオブジェクトの仲間への有益性に関する情報がユーザに報知される。例えば、ユーザが売却処理のために指定したオブジェクト（選手カード等）が、仲間にとって欲しいオブジェクトであるときに、その旨がユーザに報知される。これを実現するために、本ゲーム管理装置は、次に示す条件関係付け手段、判定手段および報知手段を備えている。

条件関係付け手段は、保有解除処理に対して、保有解除対象のオブジェクトの前記仲間への有益性に関する情報を報知するための報知条件に関する情報を関係付ける。例えば「売却処理」に対して、ユーザによって指定された「売却処理」のためのオブジェクトが、仲間が登録している欲しいものであるという条件が関係付けられる。また、例えば「ミキサー処理」に対して、ユーザによって指定された「ミキサー処理」のためのオブジェクトが、「仲間のチームの選手カード」且つ「レア度４以上」であるという条件が関係付けられる。報知条件としては、後述の８）〜１０）の構成に示すような条件、あるいはその他の任意の条件を設定可能である。

判定手段は、保有解除処理のためのオブジェクトがユーザによって指定されたとき、仲間のゲーム情報に基づいて、保有解除処理に関係付けられた報知条件を満たすか否かを判定する。ここで、仲間のゲーム情報の一例としては、ユーザの仲間が予め登録している「欲しいもの」の情報が挙げられる。また、仲間のゲーム情報の他の例としては、仲間がゲーム開始時等に設定した自分のチーム（例えば野球ゲームであればプロ野球１２チームの何れか１つのチーム）の情報が挙げられる。その他、報知条件の判定において、様々な仲間のゲーム情報を参照することができる。

そして、報知手段は、判定手段によって報知条件を満たすと判定されたときに、保有解除処理の実行前に、指定されたオブジェクトの仲間への有益性に関する情報をユーザに報知する。例えば、ユーザが売却しようとしたオブジェクトを欲しいものに登録している仲間がいた場合（売却処理に関係付けられた報知条件を満たした場合）、その旨をユーザの端末装置の画面に表示させ、その仲間へのプレゼントを促す。なお、プレゼントの促しは必須ではなく、プレゼントするか否かの判断はユーザに委ねるようにしてもよい。

以上のように、本構成では、ユーザがオブジェクトの保有を解除しようとしたときに、当該オブジェクトを欲しがっている仲間がいること等、当該オブジェクトの仲間への有益性に関する情報がタイミングよくユーザに報知される。これにより、ユーザにとって保有を解除しようとしたオブジェクトが、仲間にとっては有益であることを、保有解除処理の実行前に気付かせることができる。よって、ユーザに対して、仲間への関心を喚起させ、オブジェクトの売却等を、仲間へのプレゼントに変更させることができる。換言すれば、ユーザは、仲間にプレゼントするオブジェクトを自らが探し出すという手間のかかる面倒な作業を行うことなく、ゲーム中に自分が手放そうとしたオブジェクトを、仲間へのプレゼント対象とする機会を得ることができる。本構成により、仲間にプレゼントを行い易い環境をユーザに提供してプレゼントを促進し、仲間同士のコミュニケーションの活性化を図ることができる。

２）上記の構成において、前記保有解除処理は複数存在し、前記条件関係付け手段（53）は、保有解除処理毎に、前記報知条件に関する情報を関係付けることが望ましい。

この構成によれば、保有解除処理には、「売却処理」、「ミキサー処理」、「合体処理」などの複数の処理が存在し、保有解除処理毎に異なる報知条件を関係付けることができる。保有解除処理の種類によって、異なる報知条件を関係付ける例を次に示す。

例えば「合体処理」については、ユーザが特定のオブジェクトを合体により強化したい（そのために被合体オブジェクトを手放す）という意図がある。このため、その被合体オブジェクトが仲間にとって有益ではあっても、その仲間にプレゼントすることは、自分が実行しようと思っていた強化を止めることにもなってしまうので、被合体オブジェクトのプレゼントをユーザがためらうことが想定される。

また、「ミキサー処理」については、交換によってユーザにとって望ましいオブジェクトが得られるかもしれないという期待をもって実行するものであるので、「合体処理」ほどではないものの、やはりユーザがプレゼントを控えたくなることが想定される。

一方、「売却処理」については、本来、ユーザが不要と判断したオブジェクトをゲーム内ポイントに変換するものであり、ゲーム内ポイントは他のオブジェクトの売却でも得られるものであるので、比較的、プレゼントに変更することに対して、心理的な障壁は低いと考えられる。

そこで、仲間にとって入手への期待度が特に大きいもの、例えば仲間が「欲しいもの」として登録しているようなものについては、「売却処理」、「ミキサー処理」、「合体処理」のいずれの実行前にも報知するものとし、これらの各処理にその報知条件を関係付ける。

また、仲間が欲しいであろうもの、例えば「仲間のチームの選手カード」であって「レア度が５段階の４以上」のものについては、「売却処理」、「ミキサー処理」の実行前にユーザに報知するものとし、これらの各処理にその報知条件を関係付ける。

また、仲間が欲しいかもしれないもの、例えば「仲間のチームの選手カード」であって「レア度が５段階の３」のものについては、「売却処理」の実行前にのみユーザに報知するものとし、当該処理にその報知条件を関係付ける。

以上のように、保有解除処理の種類によって、異なる報知条件を関係付けることにより、それぞれの保有解除処理に応じた適切な報知が行われ、さらに仲間にプレゼントを行い易い環境をユーザに提供できる。

３）上記の１）または２）の構成において、前記他のユーザに関するゲーム情報に基づいて定められた他のユーザの範囲毎に、前記報知条件に関する情報が関係付けられていることが望ましい。

この構成によれば、同じ保有解除処理（例えば売却処理）に対して、他のユーザの範囲（以降、仲間の範囲と称することもある）毎に異なる報知条件を関係付けることができる。ここで、「仲間の範囲」は、例えば、後述する４）に示すように「ユーザとの親密度」、５）に示すように「仲間のゲーム内レベル」、６）に示すように「仲間のゲームへのアクセス頻度」等の「仲間に関するゲーム情報」に基づいて定めることができる。あるいは、「仲間の範囲」は、仲間のユーザＩＤやユーザ名等に基づいて定めることもできる。例えば、親密度が所定以上（例えば親友レベル以上）の仲間と、それよりも低い（例えば、知り合いレベル）の仲間とで、異なる報知条件を設定できる。

本構成により、保有解除処理の種類によって、異なる報知条件を関係付けるだけではなく、同じ保有解除処理に対して、仲間の範囲毎に異なる報知条件を関係付けることができるので、保有解除処理と仲間の範囲とに応じた適切な報知が行われ、さらに仲間にプレゼントを行い易い環境をユーザに提供できる。

４）上記の３）の構成において、関係付けられた２人のユーザに対して親密度を付与する親密度付与手段（58）をさらに備え、前記他のユーザの範囲は、ユーザとの親密度に基づいて定められていることが望ましい。

ここで、親密度とは、仲間関係が成立している２人のユーザの親密さを示すものであり、２人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。例えば、２人の親密度は、ゲーム内の交流の回数や頻度に基づいて設定できる。

ユーザにとっては、親密度が高い仲間ほど、プレゼントを贈る機会を増やすことが望ましい。本構成によれば、例えば、親密度が所定以上の仲間と、それよりも低い仲間とで、異なる報知条件を設定できる。一例を挙げると、親密度が５段階の３以上の仲間の範囲では、仲間が「欲しいもの」に登録しているもの、及び「仲間のチームの選手カード」であって「レア度が５段階の３以上」のものの何れについても、売却処理等の実行前にユーザに報知するように報知条件を設定する。一方、親密度が５段階の２以下の仲間の範囲では、仲間が「欲しいもの」に登録しているものだけを、売却処理等の実行前にユーザに報知するように報知条件を設定する。本構成により、仲間の親密度に応じた適切な報知が可能となる。

５）上記の３）または４）の構成において、前記他のユーザの範囲は、前記他のユーザのゲーム内レベルに基づいて定められていることが望ましい。

ここで、ゲーム内レベルとは、ゲームの進行度やゲームの習熟度を示す指標となるものであり、ゲームを進行させることにより向上したり、対戦ゲームで所定の勝利条件を満たすことにより向上したりする。

例えば、ゲーム内レベルの低い仲間（ゲームを開始して間もないような仲間等）については、レア度が高くないオブジェクトをプレゼントしても喜んでもらえるが、ゲーム内レベルの高い仲間については、レア度が高くないオブジェクトをプレゼントしてもあまり喜んでもらえない可能性が高い。そこで、仲間のゲーム内レベルに基づいて仲間の範囲を定め、仲間の範囲毎に、異なる報知条件を関係付ける。

一例を挙げると、ゲーム内レベルが３０以上の仲間の範囲では、「仲間のチームの選手カード」であって「レア度が５段階の４以上」のものについて、売却処理等の実行前にユーザに報知するように報知条件を設定する。一方、ゲーム内レベルが２９以下の仲間の範囲では、「仲間のチームの選手カード」であって「レア度が５段階の３」のものについて、売却処理等の実行前にユーザに報知するように報知条件を設定する。本構成により、仲間のゲーム内レベルに応じた適切な報知が可能となる。

６）上記の３）ないし５）の何れかの構成において、前記他のユーザの範囲は、前記他のユーザのゲームへのアクセス頻度に基づいて定められていることが望ましい。

ゲームへのアクセス頻度が高い仲間については、仲間同士でお互いにプレゼントを贈り合うことにより、コミュニケーションの活性化が図れる。一方、ゲームへのアクセス頻度が低い仲間については、あまりゲームを行っていないことから、そもそもプレゼントを贈る価値が低いと言える。そこで、仲間のゲームへのアクセス頻度に基づいて仲間の範囲を定め、仲間の範囲毎に、異なる報知条件を関係付ける。

一例を挙げると、１週間に４日以上ゲームにアクセスする仲間の範囲では、仲間が「欲しいもの」に登録しているもの、及び「仲間のチームの選手カード」であって「レア度が５段階の３以上」のものの何れについても、売却処理等の実行前にユーザに報知するように報知条件を設定する。一方、前記よりも低いアクセス頻度の仲間の範囲では、仲間が「欲しいもの」に登録しているものだけを、売却処理等の実行前にユーザに報知するように報知条件を設定する。また、例えば、所定のアクセス頻度以下（例えば、１週間に１日以下）の仲間の範囲では、報知しないという条件を設定してもよい。本構成により、仲間のゲームへのアクセス頻度に応じた適切な報知が可能となる。

７）上記の１）ないし６）の何れかの構成において、関係付けられた２人のユーザに対して親密度を付与する親密度付与手段（58）をさらに備え、前記判定手段（54）は、前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、所定の親密度よりも高い他のユーザのゲーム情報に限定して、前記報知条件を満たすか否かを判定することが望ましい。

この構成によれば、報知対象の仲間を、所定の親密度（例えば５段階の２）よりも高い仲間に限定する。これは次の理由による。すなわち、仲間が多いユーザの場合、オブジェクトを手放そうとしたときに頻繁に報知が行われ、煩わしくなることもあり得る。そこで、所定の親密度よりも高い仲間のゲーム情報に限定して、報知条件を満たすか否かを判定し、処理負担の軽減を図ると共に、報知対象の仲間を所定の親密度以上の仲間に限定して報知の頻度を適正化し、報知による煩わしさを回避する。

８）上記の１）ないし７）の何れかの構成において、各ユーザからの要求に応じて、各ユーザの欲しいものを登録する欲しいもの登録手段（56）をさらに備え、前記報知条件には、ユーザによって指定された前記保有解除処理のためのオブジェクトが、前記他のユーザが登録している欲しいものであるという条件が含まれることが望ましい。

この構成によれば、各ユーザは、自分が欲しいもの（ユーザが保有できるキャラクタやアイテム等のオブジェクトで自分が欲しいもの）を登録することができる。そして、ユーザによって指定された保有解除処理のためのオブジェクトが、仲間が登録している欲しいものであった場合、その旨がユーザに報知される。これにより、ユーザにとって保有を解除しようとしたオブジェクトが、仲間の欲しいものであることを、保有解除処理の実行前に気付かせることができ、仲間へのプレゼントを促進することができる。

９）上記の１）ないし８）の何れかの構成において、前記オブジェクトには複数の属性のうちの何れか１つの属性が設定されており、各ユーザからの要求に応じて、前記複数の属性のうちの何れか１つの属性であって各ユーザが希望した属性を登録する属性登録手段（57）をさらに備え、前記報知条件には、ユーザによって指定された前記保有解除処理のためのオブジェクトが、前記属性登録手段（57）によって登録されている前記仲間が希望した属性と同じ属性を有するものであるという条件が含まれることが望ましい。

この構成によれば、オブジェクト（キャラクタやアイテム等）には、複数の属性のうちの何れか１つの属性が設定されている。一例を挙げると、野球を題材とした野球ゲームの各選手キャラクタには、複数のチームの属性（例えば、現実世界に存在する日本のプロ野球１２球団に対応する１２種類のチームの属性）のうちの何れか１つのチームの属性が設定されている。また、例えば、Ａ属性（Ａ属性はＢ属性に対する相性は良いがＣ属性に対する相性は悪い）、Ｂ属性（Ｂ属性はＣ属性に対する相性は良いがＡ属性に対する相性は悪い）、Ｃ属性（Ｃ属性はＡ属性に対する相性は良いがＢ属性に対する相性は悪い）という３種類の属性があり、キャラクタやアイテム等に、３種類の属性のうちの何れか１つの属性が設定されている。

各ユーザは、前記複数の属性のうちの何れか１つの属性であって希望した属性を登録することができる。そして、ユーザによって指定された保有解除処理のためのオブジェクトが、仲間が希望した属性と同じ属性を有するものであった場合、その旨がユーザに報知される。これにより、ユーザにとって保有を解除しようとしたオブジェクトが、仲間にとって有益であることを、保有解除処理の実行前に気付かせることができ、仲間へのプレゼントを促進することができる。

１０）上記の９）の構成において、前記オブジェクトには希少価値の高さを示す希少価値度が設定されており、前記報知条件には、ユーザによって指定された前記保有解除処理のためのオブジェクトの希少価値度が、所定の希少価値度であるという条件が含まれることが望ましい。

この構成によれば、オブジェクト（キャラクタやアイテム等）には、希少価値の高さを示す希少価値度（前述のレア度）が設定されている。仲間の希望した属性のオブジェクトであっても、レア度の低いものは相手に喜ばれないことも多く、プレゼント対象として適さないこともある。そこで、本構成では、前述した仲間が希望した属性の条件に、レア度の条件を組み合わせて報知条件を設定する。例えば、ユーザによって指定された保有解除処理のためのオブジェクトが、「仲間のチーム（仲間の希望したチーム属性）の選手カード」であって「レア度が５段階の３以上」のものという条件を、報知条件とする。これにより、レア度を考慮した適切な報知が可能となる。

１１）本発明の他の一局面によるゲームシステムは、サーバ(1,2,101,102)と、当該サーバ(1,2,101,102)との間で通信を行う端末装置(3,301,302)と、を含むものであって、ユーザに関係付けられた他のユーザを管理する管理手段（51）、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段（52）、前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付け手段（53）、前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定手段（54）、前記判定手段（54）によって前記報知条件を満たすと判定されたときに、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知手段（55）、を前記サーバ(1,2,101,102)又は前記端末装置(3,301,302)のいずれか一方が備える。

１２）本発明の他の一局面によるゲーム管理方法は、ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、コンピュータが、ユーザに関係付けられた他のユーザを管理する管理ステップと、コンピュータが、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除ステップと、コンピュータが、前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付けステップと、前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、コンピュータが、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定ステップと、前記判定ステップによって前記報知条件を満たすと判定されたときに、コンピュータが、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知ステップと、を含む。

１３）本発明の他の一局面によるプログラムは、コンピュータを、ゲームを管理するゲーム管理装置（1,2,101,102,301,302）として動作させるためのプログラムであって、前記コンピュータを、ユーザに関係付けられた他のユーザを管理する管理手段（51）、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段（52）、前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付け手段（53）、前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定手段（54）、前記判定手段（54）によって前記報知条件を満たすと判定されたときに、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知手段（55）、として機能させるためのプログラムある。

本発明によれば、ユーザに関係付けられた仲間等の他のユーザにプレゼントを行い易い環境をユーザに提供してプレゼントを促進することができる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 ゲームのメイン画面の一例を示す説明図である。 指定されたカードを表示する画面の一例を示す説明図である。 売却処理前に表示される画面の一例を示す説明図である。 売却処理前に表示される報知情報を含む画面の一例を示す説明図である。 ミキサー処理前に表示される画面の一例を示す説明図である。 ミキサー処理前に表示される報知情報を含む画面の一例を示す説明図である。 ミキサー処理前に表示される報知情報を含む画面の他の例を示す説明図である。 合体処理前に表示される画面の一例を示す説明図である。 合体処理前に表示される報知情報を含む画面の一例を示す説明図である。 ゲーム管理装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザのゲームに関する情報の一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の一例を示す機能ブロック図である。 保有解除処理と報知条件とを関係付けた情報の一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の他の例を示す機能ブロック図である。 売却処理前に表示される報知情報を含む画面の他の例を示す説明図である。 ユーザが保有解除処理を行おうとした場合のゲームサーバの動作例を示すフローチャートである。 ゲーム管理装置の主要な機能的構成の他の例を示す機能ブロック図である。 親密度に基づいて仲間の範囲を定め、保有解除処理と報知条件とを関係付けた情報の一例を示す説明図である。 ゲームレベルに基づいて仲間の範囲を定め、保有解除処理と報知条件とを関係付けた情報の一例を示す説明図である。 親密度およびゲームレベルに基づいて仲間の範囲を定め、保有解除処理と報知条件とを関係付けた情報の一例を示す説明図である。 ゲームへのアクセス頻度に基づいて仲間の範囲を定め、保有解除処理と報知条件とを関係付けた情報の一例を示す説明図である。 個人を特定する情報等に基づいて仲間の範囲を定め、保有解除処理と報知条件とを関係付けた情報の一例を示す説明図である。 ユーザが報知条件を任意に設定する画面の一例を示す説明図である。 前記図２６の画面における設定例を示す説明図である。 ユーザが報知条件を任意に設定する画面の他の例を示す説明図である。 ユーザが報知条件を任意に設定する画面の他の例を示す説明図である。 ゲーム管理装置の主要な機能的構成の他の例を示す機能ブロック図である。 報知条件を自動設定するための画面の一例を示す説明図である。 報知条件が自動設定されたときに表示される画面例を示す説明図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。

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

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

本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（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 (13)

1. ユーザに関係付けられた他のユーザを管理する管理手段と、
   ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段と、
   前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付け手段と、
   前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定手段と、
   前記判定手段によって前記報知条件を満たすと判定されたときに、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知手段と、を備えているゲーム管理装置。
2. 前記保有解除処理は複数存在し、前記条件関係付け手段は、保有解除処理毎に、前記報知条件に関する情報を関係付ける請求項１に記載のゲーム管理装置。
3. 前記他のユーザに関するゲーム情報に基づいて定められた他のユーザの範囲毎に、前記報知条件に関する情報が関係付けられている請求項１または２に記載のゲーム管理装置。
4. 関係付けられた２人のユーザに対して親密度を付与する親密度付与手段をさらに備え、
   前記他のユーザの範囲は、ユーザとの親密度に基づいて定められている請求項３に記載のゲーム管理装置。
5. 前記他のユーザの範囲は、前記他のユーザのゲーム内レベルに基づいて定められている請求項３または４に記載のゲーム管理装置。
6. 前記他のユーザの範囲は、前記他のユーザのゲームへのアクセス頻度に基づいて定められている請求項３ないし５の何れか１項に記載のゲーム管理装置。
7. 関係付けられた２人のユーザに対して親密度を付与する親密度付与手段をさらに備え、
   前記判定手段は、前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、所定の親密度よりも高い他のユーザのゲーム情報に限定して、前記報知条件を満たすか否かを判定する請求項１ないし６の何れか１項に記載のゲーム管理装置。
8. 各ユーザからの要求に応じて、各ユーザの欲しいものを登録する欲しいもの登録手段をさらに備え、
   前記報知条件には、ユーザによって指定された前記保有解除処理のためのオブジェクトが、前記他のユーザが登録している欲しいものであるという条件が含まれる請求項１ないし７の何れか１項に記載のゲーム管理装置。
9. 前記オブジェクトには複数の属性のうちの何れか１つの属性が設定されており、
   各ユーザからの要求に応じて、前記複数の属性のうちの何れか１つの属性であって各ユーザが希望した属性を登録する属性登録手段をさらに備え、
   前記報知条件には、ユーザによって指定された前記保有解除処理のためのオブジェクトが、前記属性登録手段によって登録されている前記他のユーザが希望した属性と同じ属性を有するものであるという条件が含まれる請求項１ないし８の何れか１項に記載のゲーム管理装置。
10. 前記オブジェクトには希少価値の高さを示す希少価値度が設定されており、
    前記報知条件には、ユーザによって指定された前記保有解除処理のためのオブジェクトの希少価値度が、所定の希少価値度であるという条件が含まれる請求項９に記載のゲーム管理装置。
11. サーバと、当該サーバとの間で通信を行う端末装置と、を含むゲームシステムであって、
    ユーザに関係付けられた他のユーザを管理する管理手段、
    ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段、
    前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付け手段、
    前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定手段、
    前記判定手段によって前記報知条件を満たすと判定されたときに、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知手段、を前記サーバ又は前記端末装置のいずれか一方が備えるゲームシステム。
12. ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、
    コンピュータが、ユーザに関係付けられた他のユーザを管理する管理ステップと、
    コンピュータが、ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除ステップと、
    コンピュータが、前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付けステップと、
    前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、コンピュータが、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定ステップと、
    前記判定ステップによって前記報知条件を満たすと判定されたときに、コンピュータが、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知ステップと、を含むゲーム管理方法。
13. コンピュータを、ゲームを管理するゲーム管理装置として動作させるためのプログラムであって、
    前記コンピュータを、
    ユーザに関係付けられた他のユーザを管理する管理手段、
    ユーザからの保有解除要求に応じて、当該ユーザが保有しているオブジェクトの保有解除処理を実行する解除手段、
    前記保有解除処理に対して、保有解除対象のオブジェクトの前記他のユーザへの有益性に関する情報を報知するための報知条件に関する情報を関係付ける条件関係付け手段、
    前記保有解除処理のためのオブジェクトがユーザによって指定されたとき、前記他のユーザのゲーム情報に基づいて、前記報知条件を満たすか否かを判定する判定手段、
    前記判定手段によって前記報知条件を満たすと判定されたときに、前記保有解除処理の実行前に、指定された前記オブジェクトの前記他のユーザへの有益性に関する情報をユーザに報知する報知手段、
    として機能させるためのプログラム。
    
    

Images