JP2011110139A - サーバシステム、及びアイテム管理方法 - Google Patents

Abstract

【課題】アイテムのプレゼントを要素としたユーザ間のコミュニケーションを促進する。
【解決手段】イベントプレイに伴うアイテム付与に関して、ユーザ毎に、イベント固有の候補アイテム１４ａ〜１４ｅ内から出現率が他よりも特に高い優先獲得アイテムを設定する。そして、優先獲得アイテムとされる種類は、基準ユーザ２ａ及びそのフレンドユーザ２ｂ〜２ｅ内で分散するように設定される。結果として、イベントをプレイして付与されるアイテムの種類はユーザ毎に偏りが生じ、各ユーザは優先獲得アイテムを複数獲得し易いが非優先獲得アイテムを入手しづらくなり、ユーザ間のプレゼントを促すこととなる。
【選択図】図４

Description

本発明は、ユーザがゲームをプレイする端末装置が通信接続するサーバシステム等に関する。

ＲＰＧ（ロールプレイングゲーム）やアクションゲームなどでは、ゲーム進行とともに出現するアイテムを取得しつつ、そのアイテムを使ってゲームを楽しむのが一般的である。そして、オンラインゲームなどでは、自身が取得したアイテムを他ユーザにプレゼントするプレゼント機能、或いはギフト機能などと呼ばれる機能を備え、アイテムのプレゼントを要素としてユーザ間のコミュニケーションを促進するものも知られるようになった（例えば、特許文献１参照）。

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

ところで、アイテムをプレゼントする場合、同じ種類で複数保有しているアイテムはプレゼントし易いが、１つしかないアイテムをプレゼントする気にはなかなかなりにくいものである。その為、従来技術のように付与されるアイテムがランダムに選択されることを基本としている場合、１つしかないアイテムばかり保有することになったり、反対にどのユーザも同じようなアイテムを所有することになるケースが起こり、アイテムのプレゼントを要素としたコミュニケーションを阻害する要因となっていた。

本発明はこうした事情を鑑みてなされたものであり、より確実にアイテムのプレゼントを要素としてユーザ間のコミュニケーションを促進することを目的とする。

以上の課題を解決するための第１の形態は、ユーザがゲームをプレイする端末装置（例えば、図１の携帯型ゲーム装置１４００）が通信接続するサーバシステムであって、
所定のアイテム付与処理において付与される前記ゲームにおいて利用可能な付与アイテム（例えば図４の獲得アイテム１２）をユーザ別に固有に選定する付与アイテム選定手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、イベント管理部４２０、アイテム付与部４２２、図１７のステップＳ１３２）と、
前記アイテム付与処理の実行に応じて、対応するユーザに固有に選定された前記付与アイテムを当該ユーザに付与して当該ユーザの保有アイテムを更新記憶する保有アイテム記憶手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、イベント管理部４２０、アイテム付与部４２２、記憶部７００、セーブデータ７３０、図１２の保有アイテムリスト７３７、図１７のステップＳ１７２、Ｓ１７６）と、
各ユーザそれぞれのフレンドユーザを登録するフレンド登録手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、フレンド登録管理部４２６、記憶部７００、セーブデータ７３０、図１２のフレンドリスト７４０、図１６のステップＳ８８〜Ｓ９０）と、
前記端末装置或いはユーザ端末からのアイテム譲渡要求に応じて、当該ユーザと当該ユーザについて登録されたフレンドユーザとの間で、前記保有アイテム記憶手段に記憶された保有アイテムの譲渡を行い前記保有アイテム記憶手段の記憶内容を更新するアイテム譲渡手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、プレゼント制御部４３０、記憶部７００、セーブデータ７３０、図１２の保有アイテムリスト７３７、図１６のステップＳ１９０〜Ｓ１９２）と、を備えたサーバシステムである。

また、別形態として、ユーザがゲームをプレイする端末装置が通信接続するサーバシステムが実行するアイテム管理方法であって、
所定のアイテム付与処理において付与される前記ゲームにおいて利用可能な付与アイテムをユーザ別に固有に選定する付与アイテム選定ステップ（例えば、図１７のステップＳ１３２）と、
前記アイテム付与処理の実行に応じて、対応するユーザに固有に選定された前記付与アイテムを当該ユーザに付与して当該ユーザの保有アイテムとするアイテム付与ステップ例えば、図１７のステップＳ１７２、Ｓ１７６）と、
各ユーザそれぞれのフレンドユーザを登録するフレンド登録ステップ（例えば、図１６のステップＳ８８〜Ｓ９０）と、
前記端末装置或いはユーザ端末からのアイテム譲渡要求に応じて、当該ユーザと当該ユーザについて登録されたフレンドユーザとの間で保有アイテムの譲渡を行うアイテム譲渡ステップ（例えば、図１６のステップＳ１９０〜Ｓ１９２）と、を含むアイテム管理方法として実現することができる。

第１の形態によれば、各ユーザには付与されるアイテムの種類に偏りが設けられる。具体的には、各ユーザは、当該ユーザ固有に選定されたアイテムを獲得することができる。結果、各ユーザは自身に固有のアイテム以外を入手しようとすると、特定の友好関係登録を確立した他ユーザ（フレンドユーザ）との間で情報交換して、アイテム譲渡機能、つまりはアイテムプレゼント機能を利用して譲渡し合わねばならず、アイテムのプレゼントを要素としたユーザコミュニケーションを促進することとなる。

第２の形態は、前記付与アイテム選定手段が、一のユーザ及び当該一のユーザについて登録されたフレンドユーザのユーザ内で、付与アイテムの種類が分散するようにユーザ別に付与アイテムを選定する、第１の形態のサーバシステムである。

第２の形態によれば、第１の形態と同様の効果が得られるとともに、ユーザ毎に付与されるアイテムの種類の偏りが、一のユーザ及びそのユーザのフレンドユーザとの間で分散される。つまり、一のユーザにとってみれば、自身のフレンドユーザに問合せれば自分が入手しにくいアイテムを持っている確率が高いことになり、しかも各フレンドユーザ毎にアイテムの種類が異なる確率が高いことになる。
よって、誰彼構わずコミュニケーションするのではなく、友好関係にあるフレンドユーザとの間のコミュニケーションで欲しいアイテムを入手できるので、コミュニケーションすることへの心理的障壁を下げる、或いは、コミュニケーションを取る意欲をかき立てて、アイテムのプレゼントを要素としたユーザコミュニケーションをより一層促すことができる。

第３の形態は、前記フレンド登録手段により登録された各ユーザそれぞれのフレンドユーザについて当該ユーザとの間の友好度を可変に決定する友好度決定手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、アイテム付与部４２２、図１８のステップＳ１４４）を更に備え、
前記付与アイテム選定手段は、一のユーザのフレンドユーザ内における当該フレンドユーザの友好度の順位が所定順位以内のユーザ内で、付与アイテムの種類が分散するように付与アイテムを選定する、第１の形態のサーバシステムである。

第３の形態によれば、第１の形態と同様の効果が得られるとともに、ユーザ毎に付与されるアイテムの種類の偏りが、一のユーザ及びそのユーザのフレンドユーザとの間で分散される。しかもその分散は、フレンドユーザの友好度の順位が所定順位以内のユーザ内で行われる。一のユーザにとってみれば、自身のフレンドユーザのうち所定順位内のフレンドユーザに問合せれば自分が入手しにくいアイテムを持っている確率が高いことになり、しかもその所定順位内の各フレンドユーザ毎にアイテムの種類が異なる確率が高いことになる。
つまりは、より親しいフレンドユーザからコミュニケーションすれば比較的早く自分が欲しいアイテムを入手できる可能性が高くなる。よって、より一層コミュニケーションを取ろうとする際の心理的障壁を下げる、或いは、コミュニケーションを取ろうとする意欲をかき立てて、アイテムのプレゼントを要素としたユーザコミュニケーションを促進できる。

第４の形態は、前記フレンド登録手段により登録された各ユーザそれぞれのフレンドユーザについて当該ユーザとの間の友好度を可変に決定する友好度決定手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、アイテム付与部４２２、図１８のステップＳ１４４）と、
前記付与アイテム別に優先度を設定するアイテム優先度設定手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、アイテム付与部４２２、図１１の優先度７２０ｃ、図２３のステップＳ１５５）と、を更に備え、
前記付与アイテム選定手段は、一のユーザについて登録されたフレンドユーザそれぞれの付与アイテムを、当該一のユーザのフレンドユーザ内における当該フレンドユーザの友好度の順番と、前記アイテム優先度設定手段により設定された優先度とに基づいて選定する、第１又は第２の形態のサーバシステムである。

第４の形態によれば、第１又は第２の形態と同様の効果が得られるとともに、ユーザ毎に付与されるアイテムの種類の偏りが、一のユーザ及びそのユーザのフレンドユーザとの間で分散される。しかもその分散は、フレンドユーザの友好度の順位が所定順位以内のユーザ内で行われるうえに、アイテム別の優先度に基づいて行われる。ここで言う「優先度」は、ゲーム制作者サイドが予め決めた希少価値指数（所謂レア度）や重要度などの設定値、或いは各アイテムの有する能力設定に応じて求められる使用キャラクタ種類毎の有効度合などが該当する。

一のユーザにとってみれば、自身のフレンドユーザのうちの所定順位内のユーザに問合せれば自分が入手しにくいアイテムを持っている確率が高く、しかもその所定順位内の各フレンドユーザが優先度順に選ばれたアイテムを保有している確率が高いことになる。つまりは、より親しいフレンドユーザからコミュニケーションすれば比較的早く自分が欲しいアイテムを入手できる可能性が高くなる。よって、コミュニケーションを取る際の心理的障壁を下げる、或いはコミュニケーションを取ろうとする意欲をかき立てて、アイテムのプレゼントを要素としたユーザコミュニケーションを促進できる。

第５の形態は、ユーザ間のコミュニケーションのための所定の通信制御処理を実行するコミュニケーション制御手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、ロビー管理部４２４、プレゼント制御部４３０、図１６のステップＳ１９０〜Ｓ１９２）と、
前記コミュニケーション制御手段による通信制御処理を介したユーザ間のコミュニケーション履歴を記憶するコミュニケーション履歴記憶手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、ロビー管理部４２４、記憶部７００、セーブデータ７３０、図１２のプレイ履歴７３８、フレンドリスト７４０の交友履歴７４０ｃ）と、を更に備え、
前記友好度決定手段は、ユーザと当該ユーザのフレンドユーザ間の前記コミュニケーション履歴を用いて、当該ユーザと当該フレンドユーザ間の友好度を決定する第３又は第４の形態のサーバシステムである。

第５の形態によれば、第３又は第４の形態のサーバシステムと同様の効果を発揮することができる。そして、フレンドユーザの友好度を実際のコミュニケーション履歴に基づいて決定できるので、より現在の友好関係の状態に沿った友好度を設定できる。

第６の形態は、前記付与アイテム選定手段が、高確率に付与アイテムとする優先アイテムをユーザ別に固有に選定する優先アイテム選定手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、アイテム付与部４２２、記憶部７００、イベント設定データ７１０、図１１の優先獲得アイテム設定データ７２２、図１８のステップＳ１４０〜Ｓ１４２）と、
ユーザそれぞれについて、選定された優先アイテム（例えば、図４の優先獲得アイテム）を他のアイテムに比べて高確率に当選するように抽選処理して当選したアイテムを当該ユーザの付与アイテムとして選定する抽選選定手段（例えば、図９のサーバ処理部４００、ゲーム管理部４１０、アイテム付与部４２２、図１７のステップＳ１７２）と、を有する第１〜第５の何れかの形態のサーバシステムである。

第６の形態によれば、第１〜第５の形態の何れかのサーバシステムと同様の効果を奏するとともに、各ユーザにそれぞれ固有のアイテムが他のアイテムよりも高確率で当選するようにできる。結果、各ユーザは自身に固有のアイテムを複数所有し易くなり、この固有のアイテムを他ユーザに譲渡する心理的障壁が低くなる。よって、より一層アイテムのプレゼントを要素としたユーザ間のコミュニケーションを促進できる。

第７の形態は、前記優先アイテム選定手段が、各ユーザについて、当該ユーザ及び当該ユーザについて登録されたフレンドユーザのユーザ内で、優先アイテムの種類を分散するように選定する処理を、同一のユーザに１以上の優先アイテムの選定を許容して実行し、
前記抽選選定手段は、各ユーザについて、当該ユーザについて選定された優先アイテム内から付与アイテムを選定するか否かの一次抽選と、当該一次抽選の抽選結果に従ったアイテム内から付与アイテムを選定する二次抽選とを実行して付与アイテムを選定する、第６の形態のサーバシステムである。

第７の形態によれば、第６の形態のサーバシステムと同様の効果が得られるとともに、同一のユーザに１以上の優先アイテムの選定を許容することができる。よって、プレゼントできるアイテムの種類が増えるので、より一層アイテムのプレゼントを要素としたコミュニケーションを促進できる。

オンラインゲームを実現するためのシステム構成例を示す図。 携帯型ゲーム装置の構成例を説明するための外観図。 オンラインゲームに係りユーザが利用できる機能を示す概念図。 オンラインゲームに係りユーザが利用できる機能を示す概念図。 優先獲得アイテムの出現確率について説明する図。 友好度の算出関数の傾向を説明するための図。 レンドユーザ数Ｙがイベントの候補アイテム数Ｘより大きい場合の優先獲得アイテムの設定方法の例を示す図。 既存の優先獲得アイテムの設定を引き継ぐ例を説明するための概念図。 サーバシステムの機能構成の一例を示す機能ブロック図。 イベント案内データのデータ構成例を示す図。 イベント設定データのデータ構成例を示す図。 セーブデータのデータ構成例を示す図。 携帯型ゲーム装置の機能構成の一例を示す機能ブロック図。 携帯型ゲーム装置における処理の流れを説明するためのフローチャート。 図１４より続くフローチャート。 サーバシステムにおける処理の流れを説明するためのフローチャート。 アイテム付与処理の流れを説明するためのフローチャート。 優先獲得アイテム設定処理の流れを説明するためのフローチャート。 複数の優先獲得アイテムの設定を許容する構成の概念図。 複数の優先獲得アイテムの設定を許容する構成における優先獲得アイテム設定処理（優先獲得アイテム設定処理Ｂ）の流れを説明するためのフローチャート。 数の優先獲得アイテムの設定を許容する構成におけるアイテム付与処理（アイテム付与処理Ｂ）の流れを説明するためのフローチャート。 候補アイテム設定データの変形例のデータ構成図。 優先獲得アイテム設定処理の変形例の流れを説明するためのフローチャート。 フレンドリスト保存処理の流れを説明するためのフローチャート。 システム構成の変形例を示す図。

では、本発明を適用した実施形態として、複数のユーザが共通の仮想世界を舞台としたゲームを楽しむオンラインゲームのサーバシステムを例に挙げて説明する。
尚、ここで言う「オンラインゲーム」とは、ユーザ間でゲーム進行をリアルタイムに共有するオンライン専用タイプ（例えば、ＭＭＯＲＰＧなど）は勿論、認証やゲーム開始及び終了時のセーブデータの送受信のためにオンラインするがゲーム進行中はオンラインを要しないタイプも含むものとする。

図１は、本実施形態におけるオンラインゲームを実現するためのシステム構成例を示す図である。本実施形態は、通信回線１を介して接続する複数の携帯型ゲーム装置１４００（図中では１４００（１）〜１４００（ｎ；自然数））と、サーバシステム１１００とによって構成されるシステムで実行される。

通信回線１は、データ授受が可能な通信路を意味する。すなわち、通信回線とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、複数のブレードサーバ１１０２を備えた筐体１１０４と、ブレードサーバ１１０２の管理操作に用いるキーボード１１０６及びディスプレイモニタ１１０８とを備える。ブレードサーバ１１０２は、ＣＰＵやＩ／Ｏモジュール、ＩＣメモリ、ハードディスク等のストレージなどを備え、一台のサーバコンピュータとして機能する。筐体１１０４には、各ブレードサーバ１１０２や、それらに電力を供給する電源モジュール、通信回線１に接続するための通信装置等を搭載する。
尚、サーバシステム１１００は、単独のサーバコンピュータにより実現される構成であっても良いのは勿論である。

本実施形態におけるサーバシステム１１００は、ユーザ登録してアカウント取得するための手続き機能や、登録ユーザの認証処理（所謂ログイン処理）、マルチプレイするための仲間を集うロビー機能、チャットやギフト、掲示板などのユーザ間のコミュニケーション機能を実現するコンピュータである。

携帯型ゲーム装置１４００は、サーバシステム１１００に対するクライアントマシン、端末装置に相当する電子装置であって、基本的には、一人一台を使用してゲームプレイするものとする。携帯型ゲーム装置１４００は、通信回線１を介してサーバシステム１１００や他の携帯型ゲーム装置１４００とデータ通信する機能を有し、サーバシステム１１００からダウンロードしたアプリケーションプログラムを実行可能なコンピュータである。本実施形態では、携帯型ゲーム装置１４００をクライアントマシンとしたが、例えばパソコン、家庭用据え置き型ゲーム装置、業務用ゲーム装置、アプリケーションプログラムを実行可能な携帯電話でも良い。

図２は、携帯型ゲーム装置１４００の構成例を説明するための外観図である。本実施形態における携帯型ゲーム装置１４００は、方向入力キー１４０２及びボタンスイッチ１４０４と、第１液晶ディスプレイ１４０６と、第２液晶ディスプレイ１４０８と、スピーカ１４１０と、制御ユニット１４５０とを、ヒンジ１４１４で開閉自在な折り畳み型の装置本体１４０１に備えている。そして、第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８の表示面上には、スタイラスペン１４１６などで触れることによって表示画面の任意位置を接触入力することのできるタッチパネル１４０７、１４０９がそれぞれ装着されている。

また、装置本体１４０１には、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１４４０からデータを読み書きできるメモリカード読取装置１４１８が備えられている。メモリカード１４４０には、携帯型ゲーム装置１４００の制御ユニット１４５０がゲームプレイに係る各種演算処理を実行するために必要なプログラムや各種設定データが記憶されている。またその他、装置本体１４０１には図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。

タッチパネル１４０７、１４０９は、表示画面を遮蔽することなくそれぞれ第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８の表示画面のほぼ全域を被い、プレーヤがスタイラスペン１４１６（或いは指など）で触れる接触操作を行うと、左上を原点とする直交座標系における接触位置座標を制御ユニット１４５０へ出力することができる。

制御ユニット１４５０は、ゲーム装置の制御基板に相当し、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ(Application Specific Integrated Circuit)、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリを搭載する。
また、制御ユニット１４５０は、無線通信モジュール１４１２や、第１液晶ディスプレイ１４０６及び第２液晶ディスプレイ１４０８のドライバ回路、タッチパネル１４０７及びタッチパネル１４０９のドライバ回路、方向入力キー１４０２及びボタンスイッチ１４０４からの信号を受信する回路、スピーカ１４１０へ音声信号を出力するためのアンプ回路、メモリカード読取装置１４１８への信号入出力回路といった所謂Ｉ／Ｆ回路（インターフェース回路）を搭載する。これら制御ユニット１４５０に搭載されている各要素は、それぞれバス回路を介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

そして制御ユニット１４５０は、メモリカード読取装置１４１８によってメモリカード１４４０に格納されているプログラムやデータを読み出したり、通信回線１を介してサーバシステム１１００からプログラムやデータをダウンロードして、搭載するＩＣメモリにこれらを一時記憶する。そして、読み出したプログラムを実行して演算処理を実行し、方向入力キー１４０２やボタンスイッチ１４０４、タッチパネル１４０７及び１４０９からの操作入力に応じて携帯型ゲーム装置１４００の各部を制御してゲームを実行する。

尚、液晶ディスプレイの数は２つに限らず３以上でも良い。或いは、１つのディスプレイを仮想的に切り分けて使用することで仮想的な複数ディスプレイとすることもできる。

［ゲームの概要説明］
図３及び図４は、本実施形態のオンラインゲームに係りユーザが利用できる機能を示す概念図である。本実施形態では、ユーザは携帯型ゲーム装置１４００を使ってサーバシステム１１００にオンラインし、サーバシステム１１００により提供されるロビー機能で一緒にゲームを楽しむ他ユーザを見つけた後当該他ユーザとともに、或いは単独でメインゲームをプレイすることができる。メインゲームとしては、各ユーザ２ａ，２ｂがそれぞれのキャラクタ４ａ，４ｂを操作して、ファンタジックな仮想世界でモンスター６を倒すＲＰＧをプレイすることができる（Ｗ２）。勿論、メインゲームの種類はＲＰＧに限らず、シューティングや、アドベンチャー、育成ゲーム、フライトシミュレーションゲーム等でも良く、適宜設定して構わない。

また、ユーザは特に友好的と認めた他ユーザから識別情報（例えば、アカウント）を取得し所定のフレンド登録要請操作をすることで、当該他ユーザを自身のフレンドとしてグループ登録することができる（Ｗ４）。フレンド登録されたユーザをフレンドユーザと言う。図３の例ではユーザ２ａが、一緒にゲームプレイした他のユーザ２ｂを新規のフレンドユーザとして登録することを示している。

そして、ユーザは、フレンドユーザ２ｂ〜２ｅとはゲームプレイ以外にもチャットやゲーム中で使用するアイテム１０のプレゼントなどをしてコミュニケーションをすることができる（Ｗ６）。ここで言う「プレゼント」とは、保有するアイテムの譲渡であり、オリジナル所有権の移管や、複製の譲渡を含む意味である。

また、図４に示すように、本実施形態ではメインゲームのプレイとは別に期間限定のイベントとしてサブゲームがプレイ可能である（Ｗ８）。図４の例では、ユーザ２ａが自分のキャラクタ４ａを使って、ゲーム世界内に設けられた所定の狩り場で所定時間内で目標数の標的８を捕獲するサブゲームをプレイすることを示している。尚、イベントの内容はサブゲームに限らず、ゲーム世界内での花見や日食観測、ＮＰＣの演劇等の鑑賞会、所定動画の最後までの視聴などでも良いのは勿論である。

さて、イベント中又はイベント終了後、ユーザ２ａへイベントプレイの特典としてアイテムが付与される。付与されるアイテム、つまりユーザ側から言うところの獲得アイテム１２は、イベント毎に予め用意されている候補アイテム１４の中から抽選される。図４の例では、盾１４ａ、弓１４ｂ、矛１４ｃ、斧１４ｄ、刀１４ｅの５種類が候補アイテムとして予め用意されており、ゲーム制作者により前者ほど高い優先度というパラメータ値が設定されているものとする。

公知のゲームならば、イベントプレイしたユーザが誰かに関わらず、候補アイテム１４ａ〜１４ｅの中からアイテム毎に定められた所定の出現率（当選確率に同義）に従って抽選が実行されて何れかが選択されて付与される。従って、付与されるアイテムはその時々に応じてランダム的に出現するアイテムとされる。もし、候補アイテム１４内に意図的にレアアイテムが設定されている場合にはその出現率は特に低く設定されるかもしれない。
一方、本実施形態では、獲得アイテム１２として抽選されるアイテムの出現率は、レアアイテムを除いてユーザ毎に偏りが設けられている。換言すると、ユーザ毎に出現し易いアイテムが定められている。

具体的には、例えば、ある基準ユーザ２ａが初めてあるイベントをプレイすると、候補アイテム１４ａ〜１４ｅの何れかが選択されて、当該基準ユーザ２ａの優先獲得アイテムとして分類・設定され（図４の例では盾１４ａ）、それ以外のアイテム（図４の例では弓１４ｂ、矛１４ｃ、斧１４ｄ、刀１４ｅ）は非優先獲得アイテムと分類分けされる。
優先獲得アイテムの出現確率は、非優先獲得アイテムに比べて高く設定されている。例えば図５に示すように、優先獲得アイテムの出現確率は７５％、非優先獲得アイテムの出現確率は２５％といった具合である。図５の例では、非優先獲得アイテムが４つ有るので実際に非優先獲得アイテムの１つが獲得アイテムとして出現する確率は２５％の１／４で１アイテム当り１／１６の確率と言うことになる。勿論、この出現確率の割合は適宜設定可能であるが、優先獲得アイテムが非優先獲得アイテムより大きくなるように設定される。究極的には、優先獲得アイテムの出現確率を１００％とする構成も許容される。

さて、優先獲得アイテムは、基準ユーザ２ａのフレンドユーザ２ｂ〜２ｅについても同様に候補アイテムの中から何れかが設定される（図４参照）。その際、基準ユーザ２ａ及び各フレンドユーザ２ｂ〜２ｅの優先獲得アイテムとなるアイテム種類が分散するように設定される。換言すると、ユーザ別に固有に選定される優先獲得アイテムの種類が、一のユーザ及び当該一のユーザについて登録されたフレンドユーザのユーザ内で分散するように設定される。

より具体的には、フレンドユーザ２ｂ〜２ｅ毎に友好度を算出し、基準ユーザ２ａの優先獲得アイテムを除く候補アイテムを、その優先度順に１つずつ当該フレンドユーザの優先獲得アイテムとして設定する。つまり、友好度の順位が所定順位以内のフレンドユーザ内で優先獲得アイテムの種類が分散するように設定される。当然、各フレンドユーザについて見れば、それぞれの優先獲得アイテム以外の候補アイテムは非優先獲得アイテムに分類される。

ここで言う「友好度」とは、基準ユーザ２ａから見た当該フレンドユーザの親しさの度合いを示すパラメータ値である。本実施形態の友好度は、当該フレンドユーザと交わしたチャット回数やゲームプレイの回数、プレゼントを送ったり送られたりした回数、つまり交友回数Ｎと、前回交友してから現在までの経過時間ｔとに基づく所定の関数ｆ（Ｎ、ｔ）で求められ、０〜１００の範囲内の数値とされる。

関数ｆ（Ｎ、ｔ）は、図６（１）に示すように、当該フレンドユーザと交わしたチャット回数やゲームプレイの回数が多い程、プレゼントを送ったり送られたりした回数が多い程、つまり交友回数Ｎが多い程、友好度が大きくなるように算出される。また、図６（２）に示すように、前回の交友から現在までの経過時間が短いほど友好度が高くなるように算出される。つまり、より頻繁に交友関係が生まれるフレンドユーザほどより親しいと見なす。これら関数ｆの変数は、ユーザのプレイ履歴やアクセスログなどから取得することができる。
勿論、関数ｆの変数は、交友回数Ｎや経過時間ｔに限らず、フレンドユーザのプレーヤ技量を示すランクや使用するキャラクタの経験値、保有するアイテムの総数などを適宜含めることができる。

図７に示すように、もし、基準ユーザ２ａのフレンドユーザ数Ｙがイベントの候補アイテム数Ｘより大きい場合には、候補アイテム数Ｘを超えるフレンドユーザ２ｆについては、候補アイテム内から何れかのアイテムをランダム抽選して当該フレンドユーザの優先獲得アイテムとする。或いは、優先順の割り当てを友好度順に繰り返すとしても良い。
尚、ここで言う「ランダム抽選」は、乱数発生処理によって発生された乱数が所定の当選条件を満たすか否かで抽選結果を分岐する手法によって実現され、各抽選候補が少なくとも見かけ上は選択確率に偏りが生じないようにされている公知の乱数を利用した抽選処理に相当する。

また、図８に示すように、基準ユーザ２ａのフレンドユーザ（例えば２ｅ）が他基準ユーザ２ｇのフレンドユーザでもあって、既に他基準ユーザ２ｇの優先獲得アイテムを決定する際に、当該フレンドユーザ２ｅにも優先獲得アイテム（１４ｂ）が設定されている場合には（Ｗ１０）、既存の設定が基準ユーザ２ａを基準として見たコミュニティにおける優先獲得アイテムの設定においても引き継がれるものとする（Ｗ１２）。

このように、本実施形態では、基準ユーザ２ａがイベントプレイして獲得できるアイテムの種類には固有の偏りが設けられるので、プレイするほど同種のアイテムがどんどん貯まり易いことになる。一方で、基準ユーザ２ａのフレンドユーザ２ｂ〜２ｅは、基準ユーザ２ａがなかなか獲得できない他種のアイテムを優先獲得アイテムとしているので、彼らは基準ユーザ２ａが望む他種のアイテムを持っている可能性が高くなる。これは、フレンドユーザ２ｂ〜２ｅそれぞれから同コミュニティの他ユーザを見た場合にも、同様の事が言える。

従って、基準ユーザ２ａがイベントで出現するアイテムを全種揃えようとした場合、或いは獲得していないアイテムを手に入れようとした場合、同じイベントを何度も繰り返すよりも、フレンドユーザ２ｂ〜２ｅに声をかけて、相手が獲得しているであろうアイテムを譲って貰い、反対に自分が相手が持っていないアイテムを譲るように持ちかける方が遙かに早く目的を達することができることになる。このことは当該基準ユーザ２ａを基準に見たコミュニティのフレンドユーザ２ｂ〜２ｅそれぞれにとっても同様である。つまり、フレンドユーザ間での獲得したアイテムの情報交換や、アイテムのプレゼントの送り合いなどをネタとしたユーザ間のコミュニケーションを促すことができる。

［サーバシステムの機能ブロックの説明］
図９は、本実施形態におけるサーバシステム１１００の機能構成の一例を示す機能ブロック図である。サーバシステム１１００は、操作入力部１１０と、サーバ処理部４００と、画像表示部３６０と、通信部３７０と、記憶部７００とを備えるコンピュータシステムの一種である。

操作入力部１１０は、キーボードやボタンスイッチ、ジョイスティック、タッチパッド、トラックボール、などによって実現され、サーバ管理者によって為された各種の操作入力に応じて操作入力信号をサーバ処理部４００に出力する。図１では、キーボード１１０６がこれに該当する。

サーバ処理部４００は、例えばマイクロプロセッサ等の各種プロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１１０や記憶部７００をはじめサーバシステム１１００の各機能部との間でデータの入出力を行う。そして、所定のプログラムやデータ、操作入力部１１０からの操作入力信号に基づいて各種の演算処理を実行して、サーバシステム１１００の動作を制御する。

例えば、サーバ処理部４００は、ユーザ登録管理部４１２と、認証管理部４１４と、メインゲームプレイ管理部４１６と、イベント管理部４２０と、ロビー管理部４２４とを含む。

ユーザ登録管理部４１２は、新規の登録ユーザを受け付けて新たなアカウントを付与する新規ユーザ登録に関する処理を実行する。登録されたユーザの情報はユーザ登録データ７０６として記憶部７００に記憶される。ユーザ登録データ７０６には、公知のオンラインゲームにおけるユーザ登録と同様の情報が含まれる。

認証管理部４１４は、メインゲームやイベントのプレイや、ユーザコミュニケーション機能を利用するためのユーザ認証、所謂ログインの管理を実行する。こうした認証管理部４１４の機能は、公知のオンラインゲームにおける認証管理と同様にして実現できる。

メインゲームプレイ管理部４１６は、メインゲームのプレイに関する処理を実行する。例えば、ゲームプレイの舞台となる仮想空間の設定データや、登場するＮＰＣの設定データをメインゲームのプレイ要請を送信した携帯型ゲーム装置１４００へ送信する処理、ＮＰＣやゲーム世界の自動運行管理処理などを実行する。これらの諸機能は、公知のオンラインゲームと同様にして実現できる。また、メインゲームプレイ管理部４１６は、セーブデータ管理部４１８を有し、メインゲームのプレイ結果情報をユーザ毎のセーブデータ７３０として記憶部７００に記憶し管理する機能を実現する。

イベント管理部４２０は、イベントの実行に関する処理を行う。本実施形態では、イベントとして期間限定でプレイできるサブゲームをプレイ可能にする。具体的には、イベント参加要請を送信してきた携帯型ゲーム装置１４００へ、希望するイベントのプレイを可能にするための専用プログラムやデータを返信する。勿論、イベントがサブゲームではなく、メインゲームのゲーム世界での集会や鑑賞会などとして設定する場合には、専用プログラムの送信は行わなくても良く、オンラインゲームの形態に応じて適宜その処理内容を設定すると好適である。

また、イベント管理部４２０は、イベントプレイに伴いユーザにアイテムを付与するアイテム付与部４２２を含む。
アイテム付与部４２２は、優先獲得アイテムの設定に係る処理、優先獲得アイテムの設定に従って付与されるアイテムつまりは獲得アイテム１２を選定する処理、獲得アイテムをイベントプレイしたユーザの保有アイテムに追加する付与処理を実行する。

ロビー管理部４２４は、オンラインしたユーザ達が最初に行き、自由に集い自由に他ユーザとコミュニケーションする場、公知のオンラインゲームで言うところの所謂ロビー機能を実現するための処理を実行する。本実施形態のロビー管理部４２４は、具体的なユーザコミュニケーションのための機能として、フレンド登録管理部４２６と、チャット制御部４２８と、プレゼント制御部４３０とを含む。

フレンド登録管理部４２６は、ユーザの携帯型ゲーム装置１４００から所定のフレンド登録要請を受信すると、当該要請で指定された他ユーザを当該ユーザのフレンドユーザとして登録し管理する機能を実現する。

チャット制御部４２８は、ユーザ間のチャット機能を実現する。テキストチャットや音声チャットなどその形態は適宜設定すると良い。
また、プレゼント制御部４３０は、ユーザ間でのアイテムのプレゼント機能を実現する。ギフト機能やプレゼント機能などと呼ばれる公知のオンラインゲームにおける同様の機能によって実現され、他ユーザよりプレゼントされたアイテムを保有アイテムとして追加更新する機能を含む。

画像生成部４６０は、例えば、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、その制御プログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部４６０は、１フレーム時間（例えば１／６０秒）で１枚の３ＤＣＧ画像を生成し、生成した画像の画像信号を画像表示部３６０に出力する。

画像表示部３６０は、画像生成部４６０から入力される画像信号に基づいて各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。サーバシステム１１００の管理者が各種操作の際に様々な操作画面を表示する。図１では、ディスプレイモニタ１１０８がこれに該当する。

通信制御部４７０は、データ通信に係る各種処理を実行し、通信部３７０を介して外部装置とのデータのやりとりを実現する。

通信部３７０は、通信回線１と物理レベルで接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。

記憶部７００は、サーバ処理部４００にサーバシステム１１００を統合的に制御させるための諸機能を実現するためのプログラムや各種データ等を記憶する。また、サーバ処理部４００の作業領域として用いられ、サーバ処理部４００が各種プログラムに従って実行した演算結果や操作入力部１１０から入力される入力データ等を一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。

本実施形態では、記憶部７００は、サーバ処理部４００にサーバとしての基本的な機能を実現させるためのサーバプログラム７０１と、サーバ処理部４００にゲーム管理部４１０の諸機能を実現させるためのゲーム管理プログラム７０２と、メインゲーム設定データ７０４と、イベント案内データ７０８と、イベント設定データ７１０とを予め記憶している。この内、イベント案内データ７０８と、イベント設定データ７１０については、期間限定で使用されるので適宜、データの追加・修正・削除が行われる。

また、ゲーム管理に伴って生成され随時更新されるデータとして、ユーザ登録データ７０６と、セーブデータ７３０とを記憶する。その他、ゲーム管理に係り必要となる各種カウンタやタイマー、フラグなどの情報を適宜記憶することもできる。

メインゲーム設定データ７０４は、メインゲームの舞台となるゲーム空間を形成するための各種背景やキャラクタのモデルデータ、テクスチャデータ、モーションデータ、初期配置位置データ、アイテム設定データ７０５など、ゲームに登場する様々なものの設定データを格納する。
尚、アイテム設定データ７０５は、イベントプレイで付与されるアイテムの設定に関する情報も含む。よって、アイテム設定データ７０５は、イベントの開催に伴って適宜更新されるものとする。

ユーザ登録データ７０６は、認証に必要なアカウントやパスワードがユーザＩＤと対応づけて格納されている。公知のオンラインゲームのユーザ登録に関するデータと同様に実現できる。

イベント案内データ７０８は、期間限定で開催されるイベントを告知する情報を格納する。例えば、図１０に示すように、イベントＩＤ７０８ａと対応づけて、実施期間７０８ｂとイベントの概要を説明するテキスト等を含むイベント紹介データ７０８ｃが格納されている。イベント案内データ７０８は、ゲーム管理者によって適宜更新される。

本実施形態では、各イベントに固有の候補アイテム１４（図４参照）が設定されるので、例えば１つのイベントであるが実施期間７０８ｂを複数の副期間（例えば週単位）に分割し、副期間毎に異なる候補アイテム１４のセットを設定したい場合には、「山菜イベント（第１週）」「山菜イベント（第２週）」と言った具合に、名目上は一連の「山菜イベント」として扱いつつ、実質的なデータとしては異なるイベントとして管理すると好適である。

イベント設定データ７１０は、イベント別に設けられたデータセットである。例えば、図１１に示すように、イベントＩＤ７１２と、イベント実施期間７１４と、イベント実行プログラム７１６と、イベント用初期設定データ７１８と、候補アイテム設定データ７２０と、優先獲得アイテム設定データ７２２とを含む。

イベント実行プログラム７１６は、イベントとしてのサブゲームを実行させるための専用プログラムである。そして、サブゲームに登場する背景やキャラクタと言ったオブジェクトのモデルデータやテクスチャデータ、モーションデータ、配置位置データなどの各種設定データがイベント用初期設定データ７１８に格納されている。

候補アイテム設定データ７２０は、当該イベントをプレイした場合に付与されるアイテム（図４の獲得アイテム１２）となり得るアイテム（図４の候補アイテム１４相当）のアイテムＩＤ７２０ｂと、優先度７２０ｃとが対応づけて格納されている。アイテムＩＤ７２０ｂの示す具体的なアイテムの表示用モデルやテクスチャ、各種設定値などの詳細なデータは、アイテム設定データ７０５に格納されており、アイテムＩＤ７２０ｂを元に自在に参照可能となっている。

優先獲得アイテム設定データ７２２は、当該イベントにおける各ユーザの優先獲得アイテムの設定を格納する。つまり、各友好関係コミュニティにおける各候補アイテムの主要出現先の分散設定を格納する。
例えば、ユーザＩＤ７２２ａ毎に、優先獲得アイテムＩＤ７２２ｂを対応づけて格納する。優先獲得アイテムＩＤ７２２ｂには、候補アイテム設定データ７２０のアイテムＩＤ７２０ｂに含まれる少なくとも何れかの識別情報が格納される。

セーブデータ７３０は、ユーザ毎に１つ設けられるデータセットであって、対応するユーザの現在までのプレイデータが格納されている。例えば、図１２に示すように、ユーザＩＤ７３２と、プレーヤキャラクタＩＤ７３４と、ステータスデータ７３６と、プレイ履歴７３８と、フレンドリスト７４０とを含む。

ステータスデータ７３６は、プレーヤキャラクタの現在の状態に関する情報を格納する。例えば、ヒットポイントや所持金などの情報、保有アイテムリスト７３７、装備しているアイテムリスト、現在位置などが適宜含まれる。ステータスデータ７３６を読み出すことで、前回ログアウトした状態のプレーヤキャラクタを再現することができる。
尚、保有アイテムリスト７３７は、現在保有するアイテムのアイテムＩＤ７３７ａと対応づけて保有数７３７ｂを格納する。

プレイ履歴７３８は、ユーザの過去のメインゲームやイベントをプレイした履歴情報が格納されている。例えば、メインゲームをプレイした日時、そのときプレイを共にした他ユーザの識別情報、クリアしたイベントの識別情報などを格納している。プレイ履歴７３８を、ユーザ間のコミュニケーションに関する履歴情報を含む構成としても良い。

フレンドリスト７４０は、フレンドとしてグループ登録した他ユーザの登録情報と、登録された他ユーザ（フレンドユーザ）との交友記録を格納する。
例えば、フレンドユーザＩＤ７４０ａと対応づけて、登録日７４０ｂと、交友履歴７４０ｃとを対応づけて格納する。交友履歴７４０ｃには、例えば最終交友日時やプレゼント回数、チャット回数などが含まれる。勿論、交友履歴７４０ｃには適宜その他のパラメータを含めることもできる。

［携帯型ゲーム装置の機能ブロックの説明］
図１３は、本実施形態における携帯型ゲーム装置１４００の機能構成の一例を示す機能ブロック図である。携帯型ゲーム装置１４００は、操作入力部１００と、ゲーム装置処理部２００と、音出力部３５０と、画像表示部３８０と、通信部３９０と、記憶部５００とを備える。

操作入力部１００は、ボタンスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサユニット、傾斜センサユニットなどによって実現され、プレーヤによって為された各種の操作入力に応じて操作入力信号をゲーム装置処理部２００に出力する。図２の方向入力キー１４０２やボタンスイッチ１４０４、タッチパネル１４０７，１４０９はこれに該当する。

ゲーム装置処理部２００は、例えばマイクロプロセッサ等の各種プロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００など各機能部との間でデータの入出力を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号に基づいて各種の演算処理を実行して、携帯型ゲーム装置１４００の動作を制御する。図２では、装置本体１４０１に内蔵された制御ユニット１４５０がこれに該当する。

そして、本実施形態のゲーム装置処理部２００は、ゲーム演算部２１０と、音声生成部２５０と、画像生成部２６０と、通信制御部２７０とを備える。ゲーム演算部２１０は更に、認証制御部２１２と、メインゲームプレイ制御部２１４と、フレンド登録制御部２１６と、イベントプレイ制御部２１８と、ユーザコミュニケーション制御部２２０とを含む。

認証制御部２１２は、メインゲームプレイやユーザコミュニケーションをするためにサーバシステム１１００にアクセスし、登録時に取得したアカウント等のユーザＩＤを用いた認証を行ってログインするまでに要する処理を行う。その際、例えば第１液晶ディスプレイ１４０６等にアカウントやパスワードの入力画面の表示をさせるとともに、ソフトウェアキーボードを表示させてタッチ操作によるテキスト入力を受け付けるといった処理を行う。

メインゲームプレイ制御部２１４は、サーバシステム１１００の提供するゲーム世界でメインゲームをプレイするための種々の処理を実行する。

イベントプレイ制御部２１８は、イベント案内の表示制御処理、参加を希望するイベントの選択処理、選択されたイベントへの参加要請をサーバシステム１１００へ送信する処理を実行する。そして、サーバシステム１１００から返信されたイベント実行プログラム５１８及びイベント用初期設定データ５２０を記憶部５００に記憶し、イベント実行プログラム５１８を実行して、携帯型ゲーム装置１４００にてイベントプレイを実現する。そして、イベントが終了したならばイベント終了信号をサーバシステム１１００に送信し、獲得アイテムが追加された最新の保有アイテムリストを受信して第１液晶ディスプレイ１４０６に表示させる処理を実行する。その他、イベントプレイに必要な処理を実行する。

ユーザコミュニケーション制御部２２０は、認証完了後、ロビーで他ユーザとチャットをしたり、他ユーザへプレゼントを贈るといったコミュニケーションをするための処理を実行する。また、ユーザコミュニケーション制御部２２０は、フレンド登録要請部２２２を含む。

フレンド登録要請部２２２は、所定のフレンド登録操作を検出して、サーバシステム１１００にフレンド登録要請を送信するための機能を実現する。フレンド登録操作としては、例えば新規登録したい他ユーザの識別情報の入力画面をソフトウェアキーボードとともに第１液晶ディスプレイ１４０６等に表示させるなどすると好適である。
これらユーザコミュニケーションに係る処理は、公知のオンラインゲームにおける同様の機能を適宜利用することで実現できる。

音生成部２５０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサやその制御プログラムによって実現され、ゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し音出力部３５０に出力する。

音出力部３５０は、音生成部２５０から入力される音信号に基づいて効果音やＢＧＭ等を音出力するための装置である。図２ではスピーカ１４１０がこれに該当する。

画像生成部２６０は、例えば、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、その制御プログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部２６０は、１フレーム時間（例えば１／６０秒）で１枚の３ＤＣＧ画像を生成し、生成した画像の画像信号を画像表示部３８０に出力する。

画像表示部３８０は、画像生成部２６０から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図２では第１液晶ディスプレイ１４０６や第２液晶ディスプレイ１４０８が該当する。

通信制御部２７０は、データ通信に係るデータ処理を実行し、通信部３９０を介して外部装置とのデータのやりとりを実現する。

通信部３９０は、通信回線１と物理レベルで接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２では無線通信モジュール１４１２がこれに該当する。

記憶部５００は、ゲーム装置処理部２００に携帯型ゲーム装置１４００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプログラム、各種データ等を記憶する。また、ゲーム装置処理部２００の作業領域として用いられ、ゲーム装置処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。

本実施形態では、記憶部５００は、システムプログラム５０１と、サーバシステム１１００にオンラインしてメインゲームを実行するための諸機能を実現させるためのゲームプログラム５０２と、端末用メインゲーム設定データ５０４とを予め記憶している。

また、記憶部５００は、ゲームの進行に伴って生成され随時更新されるデータとして、端末用セーブデータ５１０と、イベント実行プログラム５１８と、イベント用初期設定データ５２０とを記憶する。その他、ゲーム実行に係り必要となる各種カウンタやタイマー、フラグなどの情報を適宜記憶することもできる。

ゲームプログラム５０２は、それらを記憶したＣＤ−ＲＯＭやＤＶＤといった情報記憶媒体のパッケージ販売や通信回線１を介したダウンロードによって入手し、予め記憶させておく構成としても良い。
端末用メインゲーム設定データ５０４は、サーバシステム１１００のメインゲーム設定データ７０４の携帯型ゲーム装置１４００用の複製データである。
ここでは、詳細な説明は省略するが、ゲームプログラム５０２や端末用メインゲーム設定データ５０４は、公知のオンラインゲームと同様に認証時などの適当なタイミングで自動的にアップデートされるものとする。

端末用セーブデータ５１０は、サーバシステム１１００に記憶されている当該携帯型ゲーム装置１４００を使用するユーザに対応するセーブデータ７３０（図１２参照）の完全又は一部の複製データであり、認証時などの適当なタイミングで自動的にアップデートされる。端末用セーブデータ５１０には、少なくともフレンドリスト７４０の複製に当たる端末用フレンドリスト５１２と、保有アイテムリスト７３７の複製に当たる端末用保有アイテムリスト５１４を含む。

イベント実行プログラム５１８及びイベント用初期設定データ５２０は、イベント参加要請をした結果、サーバシステム１１００から返信された参加要請したイベントのプレイを携帯型ゲーム装置１４００で実現させるために必要なプログラムとデータである。

［処理の流れの説明］
次に、本実施形態における処理の流れについて説明する。先ず、図１４〜図１５を参照して、携帯型ゲーム装置１４００における処理の流れを説明する。ここで説明する一連の処理の流れは、ゲーム装置処理部２００がゲームプログラム５０２を実行することによって実現される。

ゲーム装置処理部２００は、先ず第１液晶ディスプレイ１４０６に認証画面とソフトウェアキーボードを表示させ、認証に必要なユーザＩＤ（登録時に取得したアカウントなど）やパスワードの入力処理を実行し（ステップＳ２）、ユーザＩＤ等が入力されるとサーバシステム１１００にアクセスし認証を要請する（ステップＳ４）。

サーバシステム１１００により無事認証が終了すると、入力したユーザＩＤに対応したセーブデータ７３０が返信されるので、ゲーム装置処理部２００はこれを記憶部５００に端末用セーブデータ５１０として記憶させる（ステップＳ６）。

次に、ゲーム装置処理部２００は、所定のメインゲームプレイ開始操作を検出したならば（ステップＳ１０のＹＥＳ）、メインゲームプレイ処理を実行する（ステップＳ１２）。本実施形態のメインゲームは、ＲＰＧタイプのミッション（例えば、ダンジョンの攻略、護衛任務、救出任務など）を複数の候補の中から選択して、一人参加又は複数のユーザがパーティを編成してプレイする。メインゲーム内では、各ユーザの使用キャラクタがゲーム中で取得した各種アイテムを使用しながらモンスターや、魔法使いなどの敵を倒し、罠をくぐり抜けるなどしてミッションを攻略する。こうしたメインゲームのプレイを通じて、ユーザは他ユーザと知り合い、メインゲームでの共同プレイ以外でも友好を深めたいと思えば、メインゲーム終了後、そうして知り合った他ユーザのアカウントなどの識別情報を所定のフレンド登録操作で入力すると、当該他ユーザをフレンドユーザとして登録することができる。

すなわち、ゲーム装置処理部２００は、メインゲーム終了後に所定のフレンド登録操作を検出すると（ステップＳ２０のＹＥＳ）、新規フレンド登録要請と、別途入力された新規登録する他ユーザの識別情報とをサーバシステム１１００に送信する（ステップＳ２２）。

サーバシステム１１００は、携帯型ゲーム装置１４００からの新規フレンド登録要請に応じて、対応するセーブデータ７３０のフレンドリスト７４０を更新し、更新された新たなフレンドリスト７４０を返信してくる。ゲーム装置処理部２００はこれを受信・取得し、端末用セーブデータ５１０の端末用フレンドリスト５１２として記憶させる（ステップＳ２４）。

また、ゲーム装置処理部２００では、期間限定で提供されるサブゲームとしてのイベントをプレイすることができる。その為、ゲーム装置処理部２００は所定のイベント案内閲覧操作の入力を検出したならば（ステップＳ３０のＹＥＳ）、サーバシステム１１００にイベント案内の情報を要求する（ステップＳ３２）。

サーバシステム１１００はイベント案内情報の要求を受信すると、送信元へイベント案内データ７０８を返信するので、ゲーム装置処理部２００はこれを受信・取得し、記憶部５００に一時的に記憶させる（ステップＳ３４）。そして、第１液晶ディスプレイ１４０６等に取得したイベント案内を表示させる（ステップＳ３６；図１５）。

本実施形態では、ユーザは、イベント案内の表示を参考にして、イベント参加操作をして希望する何れかのイベントへの開催中のイベントをプレイすることができる。
ゲーム装置処理部２００はイベント参加操作の入力を検出すると（ステップＳ４０のＹＥＳ）、選択されたイベントＩＤを含むイベント参加要請をサーバシステム１１００に送信する（ステップＳ４４）。

サーバシステム１１００は、イベント参加要請信号を受信すると、要請されたイベントのイベント実行プログラム７１６と、イベント用初期設定データ７１８を返信する。ゲーム装置処理部２００はこれを受信し、記憶部５００にイベント実行プログラム５１８及びイベント用初期設定データ５２０として一時記憶させる（ステップＳ４６）。これでイベントプレイが可能になる。

ゲーム装置処理部２００は、イベント実行プログラム５１８を実行して、イベントプレイを実現する（ステップＳ４８）。そして、イベントが終了すると（ステップＳ５０のＹＥＳ）、イベント終了信号をサーバシステム１１００へ送信する（ステップＳ５２）。

サーバシステム１１００は、イベント終了信号を受信すると送信元のユーザに付与するアイテムを決定する。換言すると当該ユーザが獲得するアイテムを決定する。そして、当該ユーザのセーブデータ７３０の保有アイテムリスト７３７に追加して更新し、更新された保有アイテムリスト７３７を含むセーブデータ７３０を返信する。
ゲーム装置処理部２００は、返信されたセーブデータ７３０を含むセーブデータを受信し、端末用セーブデータ５１０を置き換える（ステップＳ５４）。この時、獲得したアイテムをユーザに通知すると好適である。

尚、ステップＳ４０にてイベント参加操作が検出されない場合には（ステップＳ４０のＮＯ）、ゲーム装置処理部２００はイベント案内表示中止操作の入力を検出するまでイベント開催案内を表示させるが（ステップＳ５６のＮＯ）、イベント案内表示中止操作の入力が検出されれば（ステップＳ５６のＹＥＳ）、イベント案内表示を中止する（ステップＳ５８）。

また本実施形態では、ユーザは、フレンドユーザ選択を含む所定のチャット開始操作を入力して、フレンドユーザとの間でチャットを楽しむことができる。
ゲーム装置処理部２００は所定のチャット開始操作の入力を検出したならば（ステップＳ６０のＹＥＳ）、チャット処理を開始し（ステップＳ６２）、所定のチャット終了操作を検出すれば（ステップＳ６４のＹＥＳ）チャットを終了させる（ステップＳ６６）。

また本実施形態では、ユーザは、プレゼント送り先とするフレンドユーザの指定や、プレゼントとする自身が所有しているアイテムの指定を含む所定のアイテムプレゼント操作を入力して、アイテムをプレゼントすることができる。
ゲーム装置処理部２００は所定のアイテムプレゼント操作の入力を検出すると（ステップＳ７０のＹＥＳ）、アイテムプレゼント操作時に入力された、プレゼントするアイテムの識別情報とプレゼント先のフレンドユーザの識別情報とを含むプレゼント要請信号をサーバシステム１１００へ送信する（ステップＳ７２）。

サーバシステム１１００はプレゼント要請信号を受信すると、プレゼント先のフレンドユーザの保有アイテムリスト７３７に同アイテムを追加してプレゼントが行われる。そして、プレゼント要請信号の送信元へプレゼント完了信号を送信する。ゲーム装置処理部２００は、このプレゼント完了信号を受信し、その旨第１液晶ディスプレイ１４０６へ表示するなどしてユーザへ通知する（ステップＳ７４）。

そして、ゲーム装置処理部２００は、所定のゲーム終了操作を検出しなければ（ステップＳ７６のＮＯ）、ステップＳ１０に移行して、上述の処理を繰り返す。
一方、ゲーム終了操作を検出した場合には（ステップＳ７６のＹＥＳ）、これら一連の処理を終了する。

図１６は、サーバシステム１１００における本実施形態に係る主たる処理の流れを説明するためのフローチャートである。ここで説明する一連の処理の流れは、サーバ処理部４００がゲーム管理プログラム７０２を実行することにより実現される。
尚、ここでは、ユーザが一緒にプレイする他ユーザを募るロビー機能や、チャット機能については、公知のオンラインゲームと同様に実現可能であるので、これらに関する記述は省略する。また、開催されるイベントの変更に伴うアイテム設定データ７０５やイベント案内データ７０８、イベント設定データ７１０の更新に関する処理の説明も省略するが、公知のオンラインゲームにおける設定データのアップデート作業と同様にして適宜実施されるものとする。

サーバ処理部４００は、携帯型ゲーム装置１４００から認証要請を受信すると（ステップＳ８０のＹＥＳ）、該当するユーザのセーブデータ７３０を抽出し（ステップＳ８２）、プレイ履歴７３８を更新する（ステップＳ８４）。そして、認証要請を送信した携帯型ゲーム装置１４００へ最新のセーブデータ７３０を返信制御する（ステップＳ８６）。ここで返信されるセーブデータ７３０の内容は、メインゲームの内容に応じて適宜設定すると良いが、少なくとも保有アイテムリスト７３７を含むステータスデータ７３６と、フレンドリスト７４０を返信することとする。

次に、サーバ処理部４００は、新規フレンド登録要請を受信した場合（ステップＳ８８のＹＥＳ）、受信した信号に含まれる新規登録する他ユーザの識別情報を元に、該当ユーザのフレンドリスト７４０に新たなフレンドユーザを登録し（ステップＳ９０）、更新されたフレンドリスト７４０を今回受信した新規フレンド登録要請の送信元の携帯型ゲーム装置１４００へ返信制御する（ステップＳ９２）。

また、イベント案内要求を受信した場合には（ステップＳ９４のＹＥＳ）、サーバ処理部４００は、イベント案内データ７０８をイベント案内要求の送信元の携帯型ゲーム装置１４００へ返信制御する（ステップＳ９６）。

携帯型ゲーム装置１４００では、返信されたイベント案内に基づいて、ユーザが参加したいイベントを選択するイベント参加操作をすると、今度はイベント参加要請が送信されてくる。

サーバ処理部４００は、このイベント参加要請を受信すると（ステップＳ９８のＹＥＳ）、参加要請されたイベントのイベント設定データ７１０を選択し、イベント実行プログラム７１６とイベント用初期設定データ７１８とを返信する（ステップＳ１００）。これにより、イベントへの参加を希望していたユーザはそれぞれの携帯型ゲーム装置１４００でイベントプレイをすることができるようになる。そして、イベントを終了すると携帯型ゲーム装置１４００はイベント終了信号を送ってくる。

サーバ処理部４００は、このイベント終了信号を受信すると（ステップＳ１０２のＹＥＳ）、アイテム付与処理を実行して、当該イベント終了信号に対応するイベントの候補アイテムの中から獲得アイテムを選択し、イベントを終了したユーザに付与する（ステップＳ１０４）。

図１７は、本実施形態におけるアイテム付与処理の流れを説明するためのフローチャートである。アイテム付与処理では先ず、サーバ処理部４００は今回終了したイベントのイベント設定データ７１０を参照し（ステップＳ１２０）、今回受信したイベント終了信号送信元の携帯型ゲーム装置１４００を使用するユーザがフレンド登録をしているかを判定する（ステップＳ１２２）。フレンドリスト７４０に１件も登録がなければ否定判定、１件でも登録があれば肯定判定する。

否定の場合には（ステップＳ１２２のＮＯ）、当該ユーザがどのアイテムを獲得しようとも、フレンドユーザとの交流には影響を与えないと判断されるので、サーバ処理部４００は候補アイテム設定データ７２０で設定されている候補アイテムの中から今回獲得するアイテムを抽選する（ステップＳ１２４）。この時の抽選は、特定のアイテムが優先的に抽選される必要はなく、所謂ランダム抽選で良い。
そして、抽選されたアイテムを該当ユーザの保有アイテムリスト７３７に追加し（ステップＳ１７６）、更新された保有アイテムリスト７３７をイベント終了信号の携帯型ゲーム装置１４００へ返信制御し（ステップＳ１７８）、アイテム付与処理を終了する。

一方、今回受信したイベント終了信号の送信元の携帯型ゲーム装置１４００を使用するユーザが、既に複数のフレンドユーザをフレンド登録している場合（ステップＳ１２２のＹＥＳ）、サーバ処理部４００は今回終了したイベントの優先獲得アイテム設定データ７２２を参照し、当該ユーザに対応する優先獲得アイテムＩＤ７２２ｂが登録されているかを判定する（ステップＳ１３０）。
そして、優先獲得アイテムＩＤ７２２ｂが登録されていなければ（ステップＳ１３０のＮＯ）、優先獲得アイテム設定処理を実行する（ステップＳ１３２）。

図１８は、本実施形態における優先獲得アイテム設定処理の流れを説明するためのフローチャートである。
同処理では先ず、今回イベント終了信号の送信元の携帯型ゲーム装置１４００を使うユーザの優先権獲得アイテムを設定する。すなわち、サーバ処理部４００は候補アイテム設定データ７２０で設定されているアイテムの中から何れかを選択し（ステップＳ１４０）、選択されたアイテムを当該ユーザの優先獲得アイテムとして優先獲得アイテム設定データ７２２に登録する（ステップＳ１４２）。ここでのアイテム選択方法は、設定されている全アイテムを対象にランダム抽選としても良いし、優先度上位所定範囲内からランダム抽選しても良い。

次に、サーバ処理部４００は当該ユーザのフレンドリスト７４０を参照して、登録されているフレンドユーザ毎に友好度の値を算出する（ステップＳ１４４）。本実施形態ではより頻繁にチャットしたりプレゼントをしているフレンドユーザほど友好度が高くなるように友好度を設定するので、例えばチャット回数とプレゼント授受回数の和から基礎値を求め、最近共同プレイしたりチャットしたりと言った交流した日までの間隔が近いほど大きく、遠い程小さくなる係数を乗じて最終的な友好度を算出する。勿論、友好度の算出式は、ユーザコミュニケーションの形態に応じて適宜設定可能である。

次に、サーバ処理部４００は、フレンドユーザそれぞれについて先に算出した友好度降順にループＡの処理を実行して、各フレンドユーザの優先獲得アイテムを設定する（ステップＳ１５０〜Ｓ１７０）。具体的には、ループＡでは先ず、今回終了したイベントの優先獲得アイテム設定データ７２２を参照して、処理対象フレンドユーザのユーザＩＤ７２２ａに対応する優先獲得アイテムＩＤ７２２ｂが登録されているかを判定する（ステップＳ１５２）。

肯定の場合には（ステップＳ１５２のＹＥＳ）、当該処理対象フレンドユーザについてのループＡの処理を終了する（ステップＳ１７０）。
否定の場合には（ステップＳ１５２のＮＯ）、サーバ処理部４００は優先獲得アイテム設定データ７２２を参照して、候補アイテム１４の内、今回受信したイベント終了信号の送信元の携帯型ゲーム装置１４００のユーザの優先獲得アイテム、或いは当該ユーザのフレンドユーザの優先獲得アイテムとして登録されていない「未登録の候補アイテム」を抽出する。つまり、誰の優先獲得アイテムにもされていない候補アイテムを抽出する。

そして、該当する「未登録の候補アイテム」が有れば（ステップＳ１５４のＹＥＳ）、それら未登録の候補アイテムの中で、最も優先度７２０ｃが大きい候補アイテムを選択し、これを現在処理対象としているフレンドユーザの優先候補アイテムとして登録し（ステップＳ１５６）、ループＡを終了する（ステップＳ１７０）。

もし、未登録の候補アイテムが無い場合には（ステップＳ１５４のＮＯ）、サーバ処理部４００は、候補アイテム設定データ７２０で用意されている候補アイテムの何れかのアイテムをランダム抽選し（ステップＳ１５８）、抽選された候補アイテムを、今回終了したイベントにおける処理対象フレンドユーザの優先獲得アイテムとして登録し（ステップＳ１６０）、ループＡを終了する（ステップＳ１７０）。

全てのフレンドユーザについてループＡを実行したならば、サーバ処理部４００は優先獲得アイテム設定処理を終了し、図１７のフローチャートに戻る。

次いで、サーバ処理部４００は、今回受信したイベント終了信号の送信元の携帯型ゲーム装置１４００のユーザについて獲得アイテムを抽選する（ステップＳ１７２）。ここでの抽選は、今回終了したイベントの候補アイテム全体を選択候補としつつも、当該ユーザの優先獲得アイテムが高確率で当選するように抽選する。

そして、抽選されたアイテムを今回の獲得アイテムとして、当該ユーザの保有アイテムリスト７３７に追加し（ステップＳ１７６）、更新された保有アイテムリスト７３７を今回イベント終了信号を送信してきた携帯型ゲーム装置１４００へ返信制御し（ステップＳ１７８）、アイテム付与処理を終了する。

尚、ステップＳ１３０において、既に今回イベント終了信号を送信してきた携帯型ゲーム装置１４００のユーザに対応する優先獲得アイテムが登録されている場合には（ステップＳ１３０のＹＥＳ）、サーバ処理部４００は優先獲得アイテム設定処理をスキップし、獲得アイテムの抽選処理（ステップＳ１７２）と、保有アイテムリスト７３７への追加処理（ステップＳ１７６）と、保有アイテムリスト７３７の返信制御を行って（ステップＳ１７８）、アイテム付与処理を終了する。

図１６のフローチャートに戻って、プレゼント要請信号を受信した場合（ステップＳ１９０のＹＥＳ）、サーバ処理部４００は当該プレゼント要請信号とともに受信したプレゼント先のフレンドユーザの識別情報と、プレゼントとされるアイテムの識別情報とに基づいて、プレゼント先のフレンドユーザの保有アイテムリスト７３７に、譲渡されるアイテムを追加登録する（ステップＳ１９２）。尚、この際、プレゼント側の保有アイテムリスト７３７からプレゼントとされたアイテムを削除する構成としても良いし、そのまま残して複製をプレゼントした事にしても良い。

次いで、サーバ処理部４００は、当該ユーザのプレイ履歴７３８とフレンドリスト７４０の交友履歴７４０ｃとを更新し（ステップＳ１９４）、プレゼント完了信号をプレゼント要請信号の送信元へ返信する（ステップＳ１９６）。
サーバ処理部４００は、こうした一連の処理を繰り返し実行する。

以上、本実施形態によれば、ある基準ユーザとそのフレンドユーザとに、獲得できるアイテムの種類に偏りを設けることができる。つまり、基準ユーザやフレンドユーザは特定のアイテムは取得できるが、他のユーザが持っているアイテムは取得しにくくなっている。結果、基準ユーザやそのフレンドユーザは、良く獲得できるアイテム以外のアイテムを揃えようとするならば積極的に友人にアイテムの譲渡を持ちかけなければならない。また、同じアイテムを複数持っていれば、友人からそのアイテムの譲渡が持ちかけられれば快くプレゼントする気になるであろう。もしかしたら、交換条件として新しい種類のアイテムをもらえるかもしれない。
このように、アイテムをネタとしたコミュニケーションが自から活発となり、ユーザ間のコミュニケーションを促す効果が得られる。

以上、本発明を適用した実施形態について説明したが、本発明の適用可能な実施形態はこれに限るものではなく、適宜構成要素の追加・省略・変更を加えることができる。

〔変形例１〕
例えば、上記実施形態では、各ユーザに設定され得る優先獲得アイテムを１つとして説明したが複数の設定を許容する構成とすることができる。例えば図１９に示すように、基準ユーザ２ａのフレンドユーザ２ｅが他基準ユーザ２ｇのフレンドユーザであって、既に他基準ユーザ２ｇに係りこのフレンドユーザ２ｅに優先獲得アイテム（１４ｂ）が設定されているとする。上記実施形態では、基準ユーザ２ａについて優先獲得アイテムを設定する際に、基準ユーザ２ａのフレンドユーザ毎の優先獲得アイテムを設定することとして説明したが、その際、既存の優先獲得アイテムが設定されている場合にはその設定が引き継がれることとした。しかし、引き継ぎをせず、その都度優先獲得アイテムを設定する構成としても良い。図１９の場合、フレンドユーザ２ｅは、弓１４ｂと矛１４ｃの２種類のアイテムが優先獲得アイテムに設定されることを示している。

図２０は、複数の優先獲得アイテムの設定を許容した場合の優先獲得アイテム設定処理（優先獲得アイテム設定処理Ｂ）の流れを説明するためのフローチャートである。同処理は、基本的には上述した実施形態の優先獲得アイテム設定処理と同様の流れを有するが、ステップＳ１５２を省略したところが異なる。この場合、今回イベント終了信号の送信元の携帯型ゲーム装置１４００でイベントに参加したユーザ（基準ユーザ）に当該イベントにおける優先獲得アイテムの登録がなされていなくて優先獲得アイテム設定処理Ｂが行われても、ステップＳ１５６又はＳ１５８が実行され、新たな優先獲得アイテムの設定が追加されることになる。つまり、上述した実施形態のように既存の優先獲得アイテムの設定を引き継ぐ処理を実行せず、優先獲得アイテムとして登録されるアイテムが複数存在することになる。

そして、この「優先獲得アイテムとして登録されるアイテムが複数存在し得る」点に対応して、本実施形態におけるアイテム付与処理も上述した実施形態と一部異なる。
具体的には、例えば図２１に示すように、本実施形態におけるアイテム付与処理（アイテム付与処理Ｂ）では、上述した実施形態におけるステップＳ１７２に代えて、サーバ処理部４００は、先ず今回獲得するアイテムを選択する分類が優先獲得アイテムと非優先獲得アイテムとのどちらからとするかを選ぶ１次抽選を行う（ステップＳ１７４ａ）。この１次抽選では、前者が高確率（例えば８０％）で当選するように偏差当選確率で抽選を行う。そして、１次抽選された分類に該当する候補アイテムの中から何れかをランダム抽選し（ステップＳ１７４ｂ）、これを今回の獲得アイテムとして登録する（ステップＳ１７６）。

〔変形例２〕
また、上述した実施形態では基準ユーザ２ａの優先獲得アイテムの選択をランダム抽選としたり、フレンドユーザ２ｂ〜２ｅへの優先獲得アイテムの設定をする際、予め候補アイテム１４毎に設けられた優先度順に割り振りをしたが、これに限るものではない。

例えば、図２２に示すように、候補アイテム設定データ７２０において、上述した実施形態における優先度７２０ｃに代えて、パラメータ値変更設定７２０ｅを設定するものとする。このパラメータ値変更設定７２０ｅは、メインゲームでユーザが使用できるキャラクタ４の種類（図２２中の「装甲兵」「突撃兵」「騎馬兵」・・・）毎に、そのアイテムを装備した場合に実施される内部パラメータ値の変更を定義する。つまりはアイテム効果が設定されているものとする。

その一方で、図２３の優先獲得アイテム設定処理Ｃのフローチャートに示すように、基本的には上述した実施形態の優先獲得アイテム設定処理と同様の流れを有するが、ステップＳ１４０に代えて、候補アイテム設定データ７２０で設定されている候補アイテムの中から、今回イベント終了信号を送信した携帯型ゲーム装置１４００のユーザの使用キャラクタにとって最も効果の低いアイテムを選択する（ステップＳ１４１）。
そして、ステップＳ１５４の次に、未登録の候補アイテム毎に基準ユーザの使用キャラクタにとって装備時に効果が高い順に高値の優先度を設定する処理を行う（ステップＳ１５５）。

こうした構成とすることで、イベントプレイに伴い付与されるアイテムは、ユーザにとってあまり価値のない固有のアイテムが偏って付与される一方、そのユーザのフレンドユーザには、そのユーザにとって価値あるアイテムが付与されることになり、ユーザ間のアイテム交換をネタとしたコミュニケーションがより積極的に行われる下地を作り出すことができる。

尚、ステップＳ１４１で選択されるアイテムは、必ずしも「最も」効果の低いものに限らず、効果降順に所定数上位を除いたアイテム（例えば、効果降順３番目以降のアイテム）からランダムに選択するとしても良い。

〔変形例３〕
また、上述した実施形態では、基準ユーザ２ａとそのフレンドユーザ２ｂ〜２ｅについて優先獲得アイテムを設定する際、その時々の最新のフレンドリスト７４０に基づくフレンドユーザを対象とする構成としているがこれに限るものではない。
例えば、図２４に示すフレンドリスト保存処理をサーバシステムにおける処理の流れ（図１６）の何処かに挿入し、優先獲得アイテムを設定する際に参照する専用のフレンドリスト（特定期間保存フレンドリスト）を、イベント開始前時点のフレンドリスト７４０を複製して一時記憶し、アイテム付与処理ではフレンドリスト７４０に代えて、この特定期間保存フレンドリストを参照する構成にすることもできる。

具体的には、フレンドリスト保存処理は、イベント設定データ７１０を参照して、実施開始条件を満たすイベントの有無を判定する（ステップＳ２００）。もし、肯定ならば（ステップＳ２００のＹＥＳ）、サーバ処理部４００は該当するイベントのイベントＩＤ７１２（図１１参照）と対応づけてその時点における全ユーザのフレンドリスト７４０を複製し、「特定期間保存フレンドリスト」として記憶部７００に保存する（ステップＳ２０２）。そして、もし実施終了条件を満たすイベントが有れば（ステップＳ２０４のＹＥＳ）、サーバ処理部４００は該当するイベントに対応づけられて保存されていた特定期間保存フレンドリストを削除する（ステップＳ２０６）。

〔変形例４〕
また、上述した実施形態ではメインゲームからユーザコミュニケーションまでを１つのサーバシステム１１００が提供する構成としたがこれに限るものではない。
例えば、図２５に示すように、ユーザ登録やメインゲームのゲームプレイ、イベントプレイ、及びプレゼント機能に関するサーバ機能をゲームサーバシステム１１１０にて実現し、プレゼント機能を除くユーザコミュニケーションに係るサーバ機能をＳＮＳ（Social Networking Site）サーバシステム１１２０にて実現する構成とすることができる。つまり、ゲームサーバシステム１１１０とＳＮＳサーバシステム１１２０とを合わせて、上述した実施形態におけるゲームサーバシステム１１００相当とすることができる。

ゲームサーバシステム１１１０及びＳＮＳサーバシステム１１２０は、ともに上述した実施形態のサーバシステム１１００と同様のハードウェアにより実現されるが、受け持つサーバ機能が異なる。
ユーザは、携帯型ゲーム装置１４００でゲームサーバシステム１１１０にアクセスしてメインゲームやイベントプレイを楽しむことができる。そして、ウェブブラウザ機能を備えた携帯電話機１５００などでＳＮＳサーバシステム１１２０にアクセスして、フレンド登録した他ユーザとチャットを楽しむことができる。

ゲームサーバシステム１１１０は、ユーザ登録時にユーザから提供を受ける情報に、ＳＮＳサーバシステム１１２０にユーザに代わってアクセスするための情報（例えば、アクセスＩＤ７７２やパスワード等）を登録情報として含めることとする。
そして、ゲームサーバシステム１１１０は、アイテム付与処理を実行する場合に、アクセスＩＤ７７２をもとにして、アイテムを付与するユーザのフレンドリストをＳＮＳサーバシステム１１２０が保有するユーザ登録データ７７０に含まれるフレンドリスト７７４を取得する構成とする。

〔その他の変形例〕
また、上記実施形態では、イベントプレイをアイテム付与の条件としているが、アイテム付与の条件はイベントプレイに限定されるものではない。例えば、特定のウェブサイトの閲覧や、ウェブマガジンの配信、食玩におまけとして付属するカードなどによって取得した識別コードを入力することをアイテム付与の条件とすることができる。その場合、機能構成上はアイテム付与部４２２はイベント管理部４２０の外に存在することとなる（図９参照）。

また、上述した実施形態では、フレンド登録機能や、チャット機能、プレゼント機能をメインゲームプレイ外のロビー機能の一部として実現しているが、公知のオンラインゲームと同様にして、メインゲーム内で実行可能な構成としても良いのは勿論である。その場合、機能構成上はフレンド登録管理部４２６、チャット制御部４２８、プレゼント制御部４３０は、メインゲームプレイ管理部４１６内に存在することとなる（図９参照）。

また、上述した実施形態では、フレンドユーザ数Ｙがイベント固有の候補アイテム数Ｘより大きい場合について説明したが、「イベント固有の候補アイテム数Ｘ≧フレンドユーザ数Ｙ」であっても良い（図７参照）。更には、「イベント固有の候補アイテム数Ｘ≧全ユーザ数」であっても良い。この場合、ユーザ毎に固有の優先獲得アイテムを設定することが可能となる。つまり、フレンド登録されたユーザ数に応じて入手可能になるアイテム数が増えるので、フレンド登録を促進させ、より多くのユーザ間でのコミュニケーションを促進できる。

１ 通信回線
２ ユーザ
２ａ 基準ユーザ
２ｂ〜２ｅ フレンドユーザ
４ａ、４ｂ キャラクタ
６ モンスター
１２ 優先獲得アイテム
１４（１４ａ〜４ｅ） 候補アイテム
１００ 操作入力部
２００ ゲーム装置処理部
２１０ ゲーム演算部
２１４ メインゲームプレイ制御部
２１８ イベントプレイ制御部
２２０ ユーザコミュニケーション制御部
４００ サーバ処理部
４１０ ゲーム管理部
４１２ ユーザ登録管理部
４１４ 認証管理部
４１６ メインゲームプレイ管理部
４１８ セーブデータ管理部
４２０ イベント管理部
４２２ アイテム付与部
４２４ ロビー管理部
４２６ フレンド登録管理部
４３０ プレゼント制御部
５００ 記憶部
５０２ ゲームプログラム
５０４ 端末用メインゲーム設定データ
５１０ 端末用セーブデータ
５１８ イベント実行プログラム
５２０ イベント用初期設定データ
１１００ サーバシステム
１１０２ ブレードサーバ
１１１０ ゲームサーバシステム
１１２０ ＳＮＳサーバシステム
１４００ 携帯型ゲーム装置

Claims (8)

1. ユーザがゲームをプレイする端末装置が通信接続するサーバシステムであって、
   所定のアイテム付与処理において付与される前記ゲームにおいて利用可能な付与アイテムをユーザ別に固有に選定する付与アイテム選定手段と、
   前記アイテム付与処理の実行に応じて、対応するユーザに固有に選定された前記付与アイテムを当該ユーザに付与して当該ユーザの保有アイテムを更新記憶する保有アイテム記憶手段と、
   各ユーザそれぞれのフレンドユーザを登録するフレンド登録手段と、
   前記端末装置或いはユーザ端末からのアイテム譲渡要求に応じて、当該ユーザと当該ユーザについて登録されたフレンドユーザとの間で、前記保有アイテム記憶手段に記憶された保有アイテムの譲渡を行い前記保有アイテム記憶手段の記憶内容を更新するアイテム譲渡手段と、
   を備えたサーバシステム。
2. 前記付与アイテム選定手段は、一のユーザ及び当該一のユーザについて登録されたフレンドユーザのユーザ内で、付与アイテムの種類が分散するようにユーザ別に付与アイテムを選定する、
   請求項１に記載のサーバシステム。
3. 前記フレンド登録手段により登録された各ユーザそれぞれのフレンドユーザについて当該ユーザとの間の友好度を可変に決定する友好度決定手段を更に備え、
   前記付与アイテム選定手段は、一のユーザのフレンドユーザ内における当該フレンドユーザの友好度の順位が所定順位以内のユーザ内で、付与アイテムの種類が分散するように付与アイテムを選定する、
   請求項１に記載のサーバシステム。
4. 前記フレンド登録手段により登録された各ユーザそれぞれのフレンドユーザについて当該ユーザとの間の友好度を可変に決定する友好度決定手段と、
   前記付与アイテム別に優先度を設定するアイテム優先度設定手段と、
   を更に備え、
   前記付与アイテム選定手段は、一のユーザについて登録されたフレンドユーザそれぞれの付与アイテムを、当該一のユーザのフレンドユーザ内における当該フレンドユーザの友好度の順番と、前記アイテム優先度設定手段により設定された優先度とに基づいて選定する、
   請求項１又は２に記載のサーバシステム。
5. ユーザ間のコミュニケーションのための所定の通信制御処理を実行するコミュニケーション制御手段と、
   前記コミュニケーション制御手段による通信制御処理を介したユーザ間のコミュニケーション履歴を記憶するコミュニケーション履歴記憶手段と、
   を更に備え、
   前記友好度決定手段は、ユーザと当該ユーザのフレンドユーザ間の前記コミュニケーション履歴を用いて、当該ユーザと当該フレンドユーザ間の友好度を決定する、
   請求項３又は４に記載のサーバシステム。
6. 前記付与アイテム選定手段は、
   高確率に付与アイテムとする優先アイテムをユーザ別に固有に選定する優先アイテム選定手段と、
   ユーザそれぞれについて、選定された優先アイテムを他のアイテムに比べて高確率に当選するように抽選処理して当選したアイテムを当該ユーザの付与アイテムとして選定する抽選選定手段と、
   を有する請求項１〜５の何れか一項に記載のサーバシステム。
7. 前記優先アイテム選定手段は、各ユーザについて、当該ユーザ及び当該ユーザについて登録されたフレンドユーザのユーザ内で、優先アイテムの種類を分散するように選定する処理を、同一のユーザに１以上の優先アイテムの選定を許容して実行し、
   前記抽選選定手段は、各ユーザについて、当該ユーザについて選定された優先アイテム内から付与アイテムを選定するか否かの一次抽選と、当該一次抽選の抽選結果に従ったアイテム内から付与アイテムを選定する二次抽選とを実行して付与アイテムを選定する、
   請求項６に記載のサーバシステム。
8. ユーザがゲームをプレイする端末装置が通信接続するサーバシステムが実行するアイテム管理方法であって、
   所定のアイテム付与処理において付与される前記ゲームにおいて利用可能な付与アイテムをユーザ別に固有に選定する付与アイテム選定ステップと、
   前記アイテム付与処理の実行に応じて、対応するユーザに固有に選定された前記付与アイテムを当該ユーザに付与して当該ユーザの保有アイテムとするアイテム付与ステップと、
   各ユーザそれぞれのフレンドユーザを登録するフレンド登録ステップと、
   前記端末装置或いはユーザ端末からのアイテム譲渡要求に応じて、当該ユーザと当該ユーザについて登録されたフレンドユーザとの間で保有アイテムの譲渡を行うアイテム譲渡ステップと、
   を含むアイテム管理方法。

Images