▶ 任天堂株式会社の特許一覧 ▶ 株式会社ポケモンの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-16
(45)【発行日】2024-01-24
(54)【発明の名称】情報処理システム、サーバ、および、情報処理方法
(51)【国際特許分類】
A63F 13/79 20140101AFI20240117BHJP
A63F 13/35 20140101ALI20240117BHJP
A63F 13/30 20140101ALI20240117BHJP
【ＦＩ】
A63F13/79
A63F13/35
A63F13/79 500
A63F13/30
【請求項の数】
36
(21)【出願番号】P 2021208274
(22)【出願日】2021-12-22
(65)【公開番号】P2023092952
(43)【公開日】2023-07-04
【審査請求日】2022-09-30
(73)【特許権者】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(73)【特許権者】
【識別番号】504440133
【氏名又は名称】株式会社ポケモン
(74)【代理人】
【識別番号】100158780
【弁理士】
【氏名又は名称】寺本 亮
(74)【代理人】
【識別番号】100121359
【弁理士】
【氏名又は名称】小沢 昌弘
(72)【発明者】
【氏名】三木 紳ノ介
(72)【発明者】
【氏名】大塚 紀孝
(72)【発明者】
【氏名】清水 一人
(72)【発明者】
【氏名】田口 幸次郎
【審査官】佐々木 祐
(56)【参考文献】
【文献】[デス・ストランディング]荷物を紛失する距離は何m？どれくらい離れても大丈夫なのか？，嗜む程にゲームを味わう[online]，2019年11月14日，[2023年10月11日検索], https://www.light-gamer.com/entry/inspect-lostdistance-deathstranding，特に本文を参照
【文献】デスストランディングのゲームシステム，ゲーム攻略マン[online]，2020年12月06日，[2023年10月11日検索], https://web.archive.org/web/20201206112800/https://dswiipspwikips3.jp/death-stranding/contents/game-system.html，特に「オンライン要素のシステム」を参照。（なお、ＵＲＬの「20201206112800」から読み取れる協定世界時2020年12月6日11時28分00秒に相当する日本標準時2020年12月6日20時28分00秒には当該ウェブページが公開されていたといえる。）
【文献】今日からはじめるグラブル第8回「マルチバトル」，GRANBLUE FANTASY[online]，2017年09月05日，[2023年10月12日検索], https://granbluefantasy.jp/kyogra/?archive=011，特に「他の騎空士さんのマルチバトルに参加しよう！」を参照
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ａ６３Ｆ １３／００ － １３／９８
Ａ６３Ｆ ９／２４
(57)【特許請求の範囲】
【請求項1】
複数の情報処理装置と、サーバとを少なくとも含む情報処理システムであって、前記情報処理装置はそれぞれ、
プレイヤの操作入力に基づいて仮想空間内においてプレイヤキャラクタを制御するゲーム処理を実行し、
ゲーム中において第１イベントが発生した場合、
前記プレイヤキャラクタの所有物が失われる状態に設定し、
当該第１イベントが発生した前記仮想空間内の位置に基づいて設定される位置情報と、前記プレイヤに関するプレイヤ情報とを少なくとも含む第１イベントデータを前記サーバへ送信し、
他の情報処理装置から送信された他のプレイヤの前記第１イベントデータに基づいた前記位置情報と前記プレイヤ情報を少なくとも含む第２イベントデータを前記サーバから受信し、
前記第２イベントデータに含まれる前記位置情報に基づいて設定される前記仮想空間内の位置において、前記プレイヤの操作に基づいて第２イベントを発生させることが可能となるよう設定し、
前記第２イベントが発生したことに基づいて、当該第２イベントが発生したことを示す第３イベントデータを前記サーバへ送信し、
前記サーバは、
前記情報処理装置から受信した前記第１イベントデータ毎に、前記位置情報と、前記プレイヤ情報と、前記第２イベントについて発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶し、
前記情報処理装置から前記第３イベントデータを受信した場合に、前記イベント管理データの前記イベント状況情報を発生済となるよう更新し、
前記イベント状況情報が発生済を示す少なくともいずれかの前記イベント管理データを第２記憶領域にさらに記憶し、
前記情報処理装置から前記第２イベントデータの受信要求があった場合に、少なくとも１つの前記第２イベントデータを前記情報処理装置へ送信し、
前記少なくとも１つの前記第２イベントデータは、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す前記イベント管理データに基づく前記第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、前記第２記憶領域に記憶された前記イベント管理データに基づく前記第２イベントデータを含み、
前記情報処理装置はさらに、
前記第１イベントデータを送信済の場合において、前記サーバと通信を行い、当該第１イベントデータに関する前記イベント管理データにおいて前記イベント状況情報が発生済を示す場合、前記所有物の少なくとも一部について、失われる状態を元に戻す処理を行う、情報処理システム。
【請求項2】
前記サーバはさらに、前記情報処理装置が送信した前記第１イベントデータに対応する第２イベントが発生済となったことを通知する通信を当該情報処理装置へ行った後、当該第１イベントデータに関するイベント管理データを前記第１記憶領域から削除する、請求項１に記載の情報処理システム。
【請求項3】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、少なくとも所定数の前記第２イベントデータを当該情報処理装置へ送信する、請求項１または請求項２に記載の情報処理システム。
【請求項4】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関する前記イベント管理データが前記第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する当該イベント管理データに基づく前記第２イベントデータを含む前記少なくとも１つの前記第２イベントデータを当該情報処理装置へ送信する、請求項１から請求項３のいずれか１項に記載の情報処理システム。
【請求項5】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関する前記イベント管理データが前記第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する前記第２イベントデータを最大で第１の数、および、当該フレンド登録済のプレイヤとは異なるプレイヤに関する前記第２イベントデータを第２の数、前記情報処理装置へ送信する、請求項４に記載の情報処理システム。
【請求項6】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す複数の前記イベント管理データからランダムに選出された少なくとも１つのイベント管理データに基づく前記第２イベントデータを前記情報処理装置に送信する、請求項１から請求項５のいずれか１項に記載の情報処理システム。
【請求項7】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す複数の前記イベント管理データから、前記サーバに記憶された順が古い順に選出された、少なくとも１つの前記第２イベントデータを前記情報処理装置へ送信する、請求項１から請求項５のいずれか１項に記載の情報処理システム。
【請求項8】
前記イベント管理データには、前記第２イベントを発生させたプレイヤに関する情報がさらに含まれ、前記サーバは、
最初に前記第３イベントデータを前記サーバへ送信した前記情報処理装置のプレイヤに関する情報を、前記第２イベントを発生させたプレイヤに関する情報として記憶する、請求項１から請求項７のいずれか１項に記載の情報処理システム。
【請求項9】
前記第２イベントデータには、前記イベント状況情報がさらに含まれ、前記情報処理装置は、前記第２イベントが発生した場合であって、当該第２イベントに関連付けられる前記第２イベントデータの前記イベント状況情報が未発生を示す場合に、前記第３イベントデータを前記サーバへ送信する、請求項１から請求項８のいずれか１項に記載の情報処理システム。
【請求項10】
前記第１イベントは、前記プレイヤキャラクタが前記所有物を紛失するイベントである、請求項１から請求項９のいずれか１項に記載の情報処理システム。
【請求項11】
前記第２イベントは、前記情報処理装置が受信した前記第２イベントデータに含まれる前記位置情報が示す前記仮想空間内の位置において、当該情報処理装置に対応する前記プレイヤキャラクタが、当該第２イベントデータに関する前記他のプレイヤのプレイヤキャラクタが紛失した所有物を拾得するイベントである、請求項１０に記載の情報処理システム。
【請求項12】
前記第１イベントは、前記ゲーム中において、前記プレイヤキャラクタに設定された体力が失われたときに発生する、請求項１から請求項１１のいずれか１項に記載の情報処理システム。
【請求項13】
ゲーム処理を実行する複数の情報処理装置と通信を行うサーバであって、ゲーム中において第１イベントが発生した仮想空間内の位置に基づいて設定される位置情報と、当該ゲームのプレイヤに関するプレイヤ情報とを少なくとも含む第１イベントデータを少なくともいずれかの前記情報処理装置から受信し、
前記情報処理装置から受信した前記第１イベントデータ毎に、前記位置情報と、前記プレイヤ情報と、当該第１イベントが発生した前記情報処理装置とは異なる他の前記情報処理装置において当該第１イベントに関して発生する第２イベントが発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶し、
前記情報処理装置から要求があった場合に、前記イベント管理データに基づいた前記位置情報と前記プレイヤ情報とを少なくとも含む、少なくとも１つの第２イベントデータを前記情報処理装置へ送信し、
前記情報処理装置において実行されるゲームにおいて、前記第２イベントデータに含まれる前記位置情報に基づいて設定される前記仮想空間内の位置において前記第２イベントが発生したことを示す第３イベントデータを当該情報処理装置から受信し、当該第３イベントデータを受信した場合に、前記イベント管理データの前記イベント状況情報を発生済となるよう更新し、
前記イベント状況情報が発生済を示す少なくともいずれかの前記イベント管理データを第２記憶領域にさらに記憶し、
前記第１イベントデータを送信済の前記情報処理装置と通信を行い、当該第１イベントデータに関する前記イベント管理データにおいて前記イベント状況情報が発生済であるか否かの情報を少なくとも送信し、
前記少なくとも１つの前記第２イベントデータは、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す前記イベント管理データに基づく前記第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、前記第２記憶領域に記憶された前記イベント管理データに基づく前記第２イベントデータを含む、サーバ。
【請求項14】
前記サーバはさらに、前記情報処理装置が送信した前記第１イベントデータに対応する第２イベントが発生済となったことを通知する通信を当該情報処理装置へ行った後、当該第１イベントデータに関するイベント管理データを前記第１記憶領域から削除する、請求項１３に記載のサーバ。
【請求項15】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、少なくとも所定数の前記第２イベントデータを当該情報処理装置へ送信する、請求項１３または請求項１４に記載のサーバ。
【請求項16】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関する前記イベント管理データが前記第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する当該イベント管理データに基づく前記第２イベントデータを含む前記少なくとも１つの前記第２イベントデータを当該情報処理装置へ送信する、請求項１３から請求項１５のいずれか１項に記載のサーバ。
【請求項17】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関する前記イベント管理データが前記第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する前記第２イベントデータを最大で第１の数、および、当該フレンド登録済のプレイヤとは異なるプレイヤに関する前記第２イベントデータを第２の数、前記情報処理装置へ送信する、請求項１６に記載のサーバ。
【請求項18】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す複数の前記イベント管理データからランダムに選出された少なくとも１つのイベント管理データに基づく前記第２イベントデータを前記情報処理装置に送信する、請求項１３から請求項１７のいずれか１項に記載のサーバ。
【請求項19】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す複数の前記イベント管理データから、前記サーバに記憶された順が古い順に選出された、少なくとも１つの前記第２イベントデータを前記情報処理装置へ送信する、請求項１３から請求項１７のいずれか１項に記載のサーバ。
【請求項20】
前記イベント管理データには、前記第２イベントを発生させたプレイヤに関する情報がさらに含まれ、前記サーバは、
最初に前記第３イベントデータを前記サーバへ送信した前記情報処理装置のプレイヤに関する情報を、前記第２イベントを発生させたプレイヤに関する情報として記憶する、請求項１３から請求項１９のいずれか１項に記載のサーバ。
【請求項21】
前記第２イベントデータには、前記イベント状況情報がさらに含まれる、前記サーバは、前記情報処理装置において前記第２イベントが発生した場合であって、当該第２イベントに関連付けられる前記第２イベントデータの前記イベント状況情報が未発生を示す場合に、前記第３イベントデータを当該情報処理装置から受信する、請求項１３から請求項２０のいずれか１項に記載のサーバ。
【請求項22】
前記第１イベントは、前記プレイヤの操作入力に基づいて制御されるプレイヤキャラクタが所有物を紛失するイベントである、請求項１３から請求項２１のいずれか１項に記載のサーバ。
【請求項23】
前記第２イベントは、前記情報処理装置が受信した前記第２イベントデータに含まれる前記位置情報が示す前記仮想空間内の位置において、当該情報処理装置に対応する前記プレイヤキャラクタが、当該第２イベントデータに関する前記他のプレイヤのプレイヤキャラクタが紛失した所有物を拾得するイベントである、請求項２２に記載のサーバ。
【請求項24】
前記第１イベントは、前記ゲーム中において、前記プレイヤの操作入力に基づいて制御されるプレイヤキャラクタに設定された体力が失われたときに発生する、請求項１３から請求項２３のいずれか１項に記載のサーバ。
【請求項25】
複数の情報処理装置と、サーバとを少なくとも含む情報処理システムにおいて実行される情報処理方法であって、前記情報処理装置はそれぞれ、
プレイヤの操作入力に基づいて仮想空間内においてプレイヤキャラクタを制御するゲーム処理を実行し、
ゲーム中において第１イベントが発生した場合、
前記プレイヤキャラクタの所有物が失われる状態に設定し、
当該第１イベントが発生した前記仮想空間内の位置に基づいて設定される位置情報と、前記プレイヤに関するプレイヤ情報とを少なくとも含む第１イベントデータを前記サーバへ送信し、
他の情報処理装置から送信された他のプレイヤの前記第１イベントデータに基づいた前記位置情報と前記プレイヤ情報を少なくとも含む第２イベントデータを前記サーバから受信し、
前記第２イベントデータに含まれる前記位置情報に基づいて設定される前記仮想空間内の位置において、前記プレイヤの操作に基づいて第２イベントを発生させることが可能となるよう設定し、
前記第２イベントが発生したことに基づいて、当該第２イベントが発生したことを示す第３イベントデータを前記サーバへ送信し、
前記サーバは、
前記情報処理装置から受信した前記第１イベントデータ毎に、前記位置情報と、前記プレイヤ情報と、前記第２イベントについて発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶し、
前記情報処理装置から前記第３イベントデータを受信した場合に、前記イベント管理データの前記イベント状況情報を発生済となるよう更新し、
前記イベント状況情報が発生済を示す少なくともいずれかの前記イベント管理データを第２記憶領域にさらに記憶し、
前記情報処理装置から前記第２イベントデータの受信要求があった場合に、少なくとも１つの前記第２イベントデータを前記情報処理装置へ送信し、
前記少なくとも１つの前記第２イベントデータは、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す前記イベント管理データに基づく前記第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、前記第２記憶領域に記憶された前記イベント管理データに基づく前記第２イベントデータを含み、
前記情報処理装置はさらに、
前記第１イベントデータを送信済の場合において、前記サーバと通信を行い、当該第１イベントデータに関する前記イベント管理データにおいて前記イベント状況情報が発生済を示す場合、前記所有物の少なくとも一部について、失われる状態を元に戻す処理を行う、情報処理方法。
【請求項26】
前記サーバはさらに、前記情報処理装置が送信した前記第１イベントデータに対応する第２イベントが発生済となったことを通知する通信を当該情報処理装置へ行った後、当該第１イベントデータに関するイベント管理データを前記第１記憶領域から削除する、請求項２５に記載の情報処理方法。
【請求項27】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、少なくとも所定数の前記第２イベントデータを当該情報処理装置へ送信する、請求項２５または請求項２６に記載の情報処理方法。
【請求項28】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関する前記イベント管理データが前記第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する当該イベント管理データに基づく前記第２イベントデータを含む前記少なくとも１つの前記第２イベントデータを当該情報処理装置へ送信する、請求項２５から請求項２７のいずれか１項に記載の情報処理方法。
【請求項29】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関する前記イベント管理データが前記第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する前記第２イベントデータを最大で第１の数、および、当該フレンド登録済のプレイヤとは異なるプレイヤに関する前記第２イベントデータを第２の数、前記情報処理装置へ送信する、請求項２８に記載の情報処理方法。
【請求項30】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す複数の前記イベント管理データからランダムに選出された少なくとも１つのイベント管理データに基づく前記第２イベントデータを前記情報処理装置に送信する、請求項２５から請求項２９のいずれか１項に記載の情報処理方法。
【請求項31】
前記サーバは、前記第２イベントデータを受信する旨の要求が前記情報処理装置からあった場合に、前記第１記憶領域に記憶された、前記イベント状況情報が未発生を示す複数の前記イベント管理データから、前記サーバに記憶された順が古い順に選出された、少なくとも１つの前記第２イベントデータを前記情報処理装置へ送信する、請求項２５から請求項２９のいずれか１項に記載の情報処理方法。
【請求項32】
前記イベント管理データには、前記第２イベントを発生させたプレイヤに関する情報がさらに含まれ、前記サーバは、
最初に前記第３イベントデータを前記サーバへ送信した前記情報処理装置のプレイヤに関する情報を、前記第２イベントを発生させたプレイヤに関する情報として記憶する、請求項２５から請求項３１のいずれか１項に記載の情報処理方法。
【請求項33】
前記第２イベントデータには、前記イベント状況情報がさらに含まれ、前記情報処理装置は、前記第２イベントが発生した場合であって、当該第２イベントに関連付けられる前記第２イベントデータの前記イベント状況情報が未発生を示す場合に、前記第３イベントデータを前記サーバへ送信する、請求項２５から請求項３２のいずれか１項に記載の情報処理方法。
【請求項34】
前記第１イベントは、前記プレイヤキャラクタが前記所有物を紛失するイベントである、請求項２５から請求項３３のいずれか１項に記載の情報処理方法。
【請求項35】
前記第２イベントは、前記情報処理装置が受信した前記第２イベントデータに含まれる前記位置情報が示す前記仮想空間内の位置において、当該情報処理装置に対応する前記プレイヤキャラクタが、当該第２イベントデータに関する前記他のプレイヤのプレイヤキャラクタが紛失した所有物を拾得するイベントである、請求項３４に記載の情報処理方法。
【請求項36】
前記第１イベントは、前記ゲーム中において、前記プレイヤキャラクタに設定された体力が失われたときに発生する、請求項２５から請求項３５のいずれか１項に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置とサーバとの間でゲームに関する通信を行う情報処理システム、サーバ、および、情報処理方法に関する。
【背景技術】
【0002】
従来、ゲーム装置で実行される第１ゲームにおいてプレイヤキャラクタが倒された場合に、第１ゲームとは別の第２ゲームにおいて、当該第１ゲームのセーブデータに基づいてゲームを行うことで、当該プレイヤキャラクタを救助することができるゲームシステムがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００７－１３５７９１号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のゲームシステムにおいては、２つのゲーム間でのやり取り（上記の例では、他のゲームに対して救助をすること）を高い頻度で行いたい場合に機会が不足するおそれがある。
【0005】
それ故、本発明の目的は、ゲーム間でのやり取りを行う機会をプレイヤに対して効果的に与えることができる情報処理システム、サーバ、および、情報処理方法を提供することである。
【課題を解決するための手段】
【0006】
上記の課題を解決すべく、本発明は、以下の（１）～（１２）の構成を採用した。
【0007】
（１）
本発明の一例は、複数の情報処理装置と、サーバとを少なくとも含む情報処理システムである。情報処理装置はそれぞれ、プレイヤの操作入力に基づいて仮想空間内においてプレイヤキャラクタを制御するゲーム処理を実行する。ゲーム中において第１イベントが発生した場合、情報処理装置はそれぞれ、プレイヤキャラクタの所有物が失われる状態に設定し、当該第１イベントが発生した仮想空間内の位置に基づいて設定される位置情報と、プレイヤに関するプレイヤ情報とを少なくとも含む第１イベントデータをサーバへ送信する。情報処理装置はそれぞれ、他の情報処理装置から送信された他のプレイヤの第１イベントデータに基づいた位置情報とプレイヤ情報を少なくとも含む第２イベントデータをサーバから受信する。情報処理装置はそれぞれ、第２イベントデータに含まれる位置情報に基づいて設定される仮想空間内の位置において、プレイヤの操作に基づいて第２イベントを発生させることが可能となるよう設定する。情報処理装置はそれぞれ、第２イベントが発生したことに基づいて、当該第２イベントが発生したことを示す第３イベントデータをサーバへ送信する。サーバは、情報処理装置から受信した第１イベントデータ毎に、位置情報と、プレイヤ情報と、第２イベントについて発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶する。サーバは、情報処理装置から第３イベントデータを受信した場合に、イベント管理データのイベント状況情報を発生済となるよう更新する。サーバは、イベント状況情報が発生済を示す少なくともいずれかのイベント管理データを第２記憶領域にさらに記憶する。サーバは、情報処理装置から第２イベントデータの受信要求があった場合に、少なくとも１つの第２イベントデータを情報処理装置へ送信する。少なくとも１つの第２イベントデータは、第１記憶領域に記憶された、イベント状況情報が未発生を示すイベント管理データに基づく第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、第２記憶領域に記憶されたイベント管理データに基づく第２イベントデータを含む。情報処理装置はさらに、第１イベントデータを送信済の場合において、サーバと通信を行い、当該第１イベントデータに関するイベント管理データにおいてイベント状況情報が発生済を示す場合、所有物の少なくとも一部について、失われる状態を元に戻す処理を行う。
本発明の一例は、複数の情報処理装置と、サーバとを少なくとも含む情報処理システムである。情報処理装置はそれぞれ、プレイヤの操作入力に基づいて仮想空間内においてプレイヤキャラクタを制御するゲーム処理を実行する。ゲーム中において第１イベントが発生した場合、情報処理装置はそれぞれ、プレイヤキャラクタの所有物が失われる状態に設定し、当該第１イベントが発生した仮想空間内の位置に基づいて設定される位置情報と、プレイヤに関するプレイヤ情報とを少なくとも含む第１イベントデータをサーバへ送信する。情報処理装置はそれぞれ、他の情報処理装置から送信された他のプレイヤの第１イベントデータに基づいた位置情報とプレイヤ情報を少なくとも含む第２イベントデータをサーバから受信する。情報処理装置はそれぞれ、第２イベントデータに含まれる位置情報に基づいて設定される仮想空間内の位置において、プレイヤの操作に基づいて第２イベントを発生させることが可能となるよう設定する。情報処理装置はそれぞれ、第２イベントが発生したことに基づいて、当該第２イベントが発生したことを示す第３イベントデータをサーバへ送信する。サーバは、情報処理装置から受信した第１イベントデータ毎に、位置情報と、プレイヤ情報と、第２イベントについて発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶する。サーバは、情報処理装置から第３イベントデータを受信した場合に、イベント管理データのイベント状況情報を発生済となるよう更新する。サーバは、イベント状況情報が発生済を示す少なくともいずれかのイベント管理データを第２記憶領域にさらに記憶する。サーバは、情報処理装置から第２イベントデータの受信要求があった場合に、少なくとも１つの第２イベントデータを情報処理装置へ送信する。少なくとも１つの第２イベントデータは、第１記憶領域に記憶された、イベント状況情報が未発生を示すイベント管理データに基づく第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、第２記憶領域に記憶されたイベント管理データに基づく第２イベントデータを含む。情報処理装置はさらに、第１イベントデータを送信済の場合において、サーバと通信を行い、当該第１イベントデータに関するイベント管理データにおいてイベント状況情報が発生済を示す場合、所有物の少なくとも一部について、失われる状態を元に戻す処理を行う。
【0008】
上記（１）の構成によれば、第１イベントに対応する第２イベントが行われる機会を確保することができ、ゲーム間でのやり取りを行う機会をプレイヤに対して効果的に与えることができる。
【0009】
（２）
サーバはさらに、情報処理装置が送信した第１イベントデータに対応する第２イベントが発生済となったことを通知する通信を当該情報処理装置へ行った後、当該第１イベントデータに関するイベント管理データを第１記憶領域から削除してもよい。
サーバはさらに、情報処理装置が送信した第１イベントデータに対応する第２イベントが発生済となったことを通知する通信を当該情報処理装置へ行った後、当該第１イベントデータに関するイベント管理データを第１記憶領域から削除してもよい。
【0010】
上記（２）の構成によれば、第１記憶領域に記憶されるイベント管理データのデータ量を抑制することができる。
【0011】
（３）
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合に、少なくとも所定数の第２イベントデータを当該情報処理装置へ送信してもよい。
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合に、少なくとも所定数の第２イベントデータを当該情報処理装置へ送信してもよい。
【0012】
上記（３）の構成によれば、情報処理装置は複数の第２イベントデータを用いてゲームを行うことができる。
【0013】
（４）
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関するイベント管理データが第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する当該イベント管理データに基づく第２イベントデータを含む少なくとも１つの第２イベントデータを当該情報処理装置へ送信してもよい。
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関するイベント管理データが第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する当該イベント管理データに基づく第２イベントデータを含む少なくとも１つの第２イベントデータを当該情報処理装置へ送信してもよい。
【0014】
上記（４）の構成によれば、第１イベントが発生したゲームのプレイヤのフレンドであるプレイヤに対して、当該第１イベントに対応する第２イベントを行う機会を与えやすくすることができる。
【0015】
（５）
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関するイベント管理データが第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する第２イベントデータを最大で第１の数、および、当該フレンド登録済のプレイヤとは異なるプレイヤに関する第２イベントデータを第２の数、情報処理装置へ送信してもよい。
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合であって、当該情報処理装置のプレイヤとの間でフレンド登録済のプレイヤに関するイベント管理データが第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する第２イベントデータを最大で第１の数、および、当該フレンド登録済のプレイヤとは異なるプレイヤに関する第２イベントデータを第２の数、情報処理装置へ送信してもよい。
【0016】
上記（５）の構成によれば、プレイヤに対して、当該プレイヤのフレンドのプレイヤによる第１イベントに対する第２イベントを行う機会を与えることができるとともに、フレンドのプレイヤがいない場合であっても、一定数の第２イベントデータを情報処理装置へ送信して第２イベントを行う機会を与えやすくすることができる。
【0017】
（６）
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合に、第１記憶領域に記憶された、イベント状況情報が未発生を示す複数のイベント管理データからランダムに選出された少なくとも１つのイベント管理データに基づく第２イベントデータを情報処理装置に送信してもよい。
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合に、第１記憶領域に記憶された、イベント状況情報が未発生を示す複数のイベント管理データからランダムに選出された少なくとも１つのイベント管理データに基づく第２イベントデータを情報処理装置に送信してもよい。
【0018】
上記（６）の構成によれば、第２イベントが未発生である第１イベントについて第２イベントを発生させる機会を確保することができる。
【0019】
（７）
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合に、第１記憶領域に記憶された、イベント状況情報が未発生を示す複数のイベント管理データから、サーバに記憶された順が古い順に選出された、少なくとも１つの第２イベントデータを情報処理装置へ送信してもよい。
サーバは、第２イベントデータを受信する旨の要求が情報処理装置からあった場合に、第１記憶領域に記憶された、イベント状況情報が未発生を示す複数のイベント管理データから、サーバに記憶された順が古い順に選出された、少なくとも１つの第２イベントデータを情報処理装置へ送信してもよい。
【0020】
上記（７）の構成によれば、発生してからの時間が長い第１イベントについて第２イベントが行われやすくすることができる。
【0021】
（８）
イベント管理データには、第２イベントを発生させたプレイヤに関する情報がさらに含まれてもよい。サーバは、最初に第３イベントデータをサーバへ送信した情報処理装置のプレイヤに関する情報を、第２イベントを発生させたプレイヤに関する情報として記憶してもよい。
イベント管理データには、第２イベントを発生させたプレイヤに関する情報がさらに含まれてもよい。サーバは、最初に第３イベントデータをサーバへ送信した情報処理装置のプレイヤに関する情報を、第２イベントを発生させたプレイヤに関する情報として記憶してもよい。
【0022】
上記（８）の構成によれば、情報処理システムは、１つの第１イベントに対する第２イベントを複数のプレイヤに行わせることができるとともに、第１イベントに対して最初に第２イベントを行ったプレイヤに関する情報を記憶することができる。
【0023】
（９）
第２イベントデータには、イベント状況情報がさらに含まれてもよい。情報処理装置は、第２イベントが発生した場合であって、当該第２イベントに関連付けられる第２イベントデータのイベント状況情報が未発生を示す場合に、第３イベントデータをサーバへ送信してもよい。
第２イベントデータには、イベント状況情報がさらに含まれてもよい。情報処理装置は、第２イベントが発生した場合であって、当該第２イベントに関連付けられる第２イベントデータのイベント状況情報が未発生を示す場合に、第３イベントデータをサーバへ送信してもよい。
【0024】
上記（９）の構成によれば、第２イベントが発生した場合であっても、当該第２イベントに関連付けられる第２イベントデータのイベント状況情報が発生済を示す場合には、第３イベントデータのサーバへの送信が行われないので、情報処理装置からサーバへの通信量を低減することができる。
【0025】
（１０）
第１イベントは、プレイヤキャラクタが所有物を紛失するイベントであってもよい。
第１イベントは、プレイヤキャラクタが所有物を紛失するイベントであってもよい。
【0026】
上記（１０）の構成によれば、プレイヤキャラクタが所有物を紛失するイベントについて、ゲーム間でのやり取りを行う機会をプレイヤに対して効果的に与えることができる。
【0027】
（１１）
第２イベントは、情報処理装置が受信した第２イベントデータに含まれる位置情報が示す仮想空間内の位置において、当該情報処理装置に対応するプレイヤキャラクタが、当該第２イベントデータに関する他のプレイヤのプレイヤキャラクタが紛失した所有物を拾得するイベントであってもよい。
第２イベントは、情報処理装置が受信した第２イベントデータに含まれる位置情報が示す仮想空間内の位置において、当該情報処理装置に対応するプレイヤキャラクタが、当該第２イベントデータに関する他のプレイヤのプレイヤキャラクタが紛失した所有物を拾得するイベントであってもよい。
【0028】
上記（１１）の構成によれば、あるプレイヤキャラクタが所有物を紛失するイベントに対して、他のプレイヤキャラクタがその所有物を拾得するイベントを行うことで、プレイヤ同士が協力するゲームを提供することができる。
【0029】
（１２）
第１イベントは、ゲーム中において、プレイヤキャラクタに設定された体力が失われたときに発生してもよい。
第１イベントは、ゲーム中において、プレイヤキャラクタに設定された体力が失われたときに発生してもよい。
【0030】
上記（１２）の構成によれば、プレイヤキャラクタに設定された体力が失われる第１イベントが発生しづらいゲームにおいても、第２イベントが情報処理装置において行われる機会を増やすことができる。
【0031】
なお、本発明の別の一例は、上記（１）～（１２）における情報処理装置またはサーバであってもよい。また、本発明の別の一例は、上記（１）～（１２）において実行される処理の全部または一部をコンピュータに実行させる情報処理プログラム（例えば、ゲームプログラム）であってもよい。また、本発明の別の一例は、上記（１）～（１２）における処理を情報処理システムによって実行する情報処理方法（例えば、ゲーム処理方法）であってもよい。
【発明の効果】
【0032】
上記情報処理システム、サーバ、および、情報処理方法によれば、ゲーム間でのやり取りを行う機会をプレイヤに対して効果的に与えることができる。
【図面の簡単な説明】
【0033】
【図1】本体装置に左コントローラおよび右コントローラを装着した状態の一例を示す図
【図2】本体装置から左コントローラおよび右コントローラをそれぞれ外した状態の一例を示す図
【図3】本体装置の一例を示す六面図
【図4】左コントローラの一例を示す六面図
【図5】右コントローラの一例を示す六面図
【図6】本体装置の内部構成の一例を示すブロック図
【図7】本体装置と左コントローラおよび右コントローラとの内部構成の一例を示すブロック図
【図9】サーバの構成の一例を示すブロック図
【図10】ゲームにおいて紛失されたアイテムが回収される流れの一例を示す図
【図11】紛失イベントが発生してから、アイテムが回収されるまでの処理の流れの一例を示す図
【図12】イベント管理データの一例を示す図
【図13】サーバにおいてイベント管理データを記憶する記憶領域の一例を示す図
【図14】他紛失イベントデータの生成方法の一例を示す図
【図15】ゲームシステムにおける情報処理に用いられる各種データの一例を示す図
【図16】ゲームシステムによって実行されるゲーム処理である端末処理の流れの一例を示すフローチャート
【図17】ゲームシステムによって実行されるゲーム処理である端末処理の流れの一例を示すフローチャート
【図18】サーバによって実行されるサーバ処理の流れの一例を示すフローチャート
【発明を実施するための形態】
【0034】
［１．ゲームシステムの構成］
以下、本実施形態の一例に係るゲームシステムについて説明する。本実施形態におけるゲームシステム１の一例は、本体装置（情報処理装置；本実施形態ではゲーム装置本体として機能する）２と左コントローラ３および右コントローラ４とを含む。本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能である。つまり、ゲームシステム１は、左コントローラ３および右コントローラ４をそれぞれ本体装置２に装着して一体化された装置として利用できる。また、ゲームシステム１は、本体装置２と左コントローラ３および右コントローラ４とを別体として利用することもできる（図２参照）。以下では、本実施形態のゲームシステム１のハードウェア構成について説明し、その後に本実施形態のゲームシステム１の制御について説明する。
以下、本実施形態の一例に係るゲームシステムについて説明する。本実施形態におけるゲームシステム１の一例は、本体装置（情報処理装置；本実施形態ではゲーム装置本体として機能する）２と左コントローラ３および右コントローラ４とを含む。本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能である。つまり、ゲームシステム１は、左コントローラ３および右コントローラ４をそれぞれ本体装置２に装着して一体化された装置として利用できる。また、ゲームシステム１は、本体装置２と左コントローラ３および右コントローラ４とを別体として利用することもできる（図２参照）。以下では、本実施形態のゲームシステム１のハードウェア構成について説明し、その後に本実施形態のゲームシステム１の制御について説明する。
【0035】
図１は、本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図である。図１に示すように、左コントローラ３および右コントローラ４は、それぞれ本体装置２に装着されて一体化されている。本体装置２は、ゲームシステム１における各種の処理（例えば、ゲーム処理）を実行する装置である。本体装置２は、ディスプレイ１２を備える。左コントローラ３および右コントローラ４は、ユーザが入力を行うための操作部を備える装置である。
【0036】
図２は、本体装置２から左コントローラ３および右コントローラ４をそれぞれ外した状態の一例を示す図である。図１および図２に示すように、左コントローラ３および右コントローラ４は、本体装置２に着脱可能である。なお、以下において、左コントローラ３および右コントローラ４の総称として「コントローラ」と記載することがある。
【0037】
図３は、本体装置２の一例を示す六面図である。図３に示すように、本体装置２は、略板状のハウジング１１を備える。本実施形態において、ハウジング１１の主面（換言すれば、表側の面、すなわち、ディスプレイ１２が設けられる面）は、大略的には矩形形状である。
【0038】
なお、ハウジング１１の形状および大きさは、任意である。一例として、ハウジング１１は、携帯可能な大きさであってよい。また、本体装置２単体または本体装置２に左コントローラ３および右コントローラ４が装着された一体型装置は、携帯型装置となってもよい。また、本体装置２または一体型装置が手持ち型の装置となってもよい。また、本体装置２または一体型装置が可搬型装置となってもよい。
【0039】
図３に示すように、本体装置２は、ハウジング１１の主面に設けられるディスプレイ１２を備える。ディスプレイ１２は、本体装置２が生成した画像を表示する。本実施形態においては、ディスプレイ１２は、液晶表示装置（ＬＣＤ）とする。ただし、ディスプレイ１２は任意の種類の表示装置であってよい。
【0040】
また、本体装置２は、ディスプレイ１２の画面上にタッチパネル１３を備える。本実施形態においては、タッチパネル１３は、マルチタッチ入力が可能な方式（例えば、静電容量方式）のものである。ただし、タッチパネル１３は、任意の種類のものであってよく、例えば、シングルタッチ入力が可能な方式（例えば、抵抗膜方式）のものであってもよい。
【0041】
本体装置２は、ハウジング１１の内部においてスピーカ（すなわち、図６に示すスピーカ８８）を備えている。図３に示すように、ハウジング１１の主面には、スピーカ孔１１ａおよび１１ｂが形成される。そして、スピーカ８８の出力音は、これらのスピーカ孔１１ａおよび１１ｂからそれぞれ出力される。
【0042】
また、本体装置２は、本体装置２が左コントローラ３と有線通信を行うための端子である左側端子１７と、本体装置２が右コントローラ４と有線通信を行うための右側端子２１を備える。
【0043】
図３に示すように、本体装置２は、スロット２３を備える。スロット２３は、ハウジング１１の上側面に設けられる。スロット２３は、所定の種類の記憶媒体を装着可能な形状を有する。所定の種類の記憶媒体は、例えば、ゲームシステム１およびそれと同種の情報処理装置に専用の記憶媒体（例えば、専用メモリカード）である。所定の種類の記憶媒体は、例えば、本体装置２で利用されるデータ（例えば、アプリケーションのセーブデータ等）、および／または、本体装置２で実行されるプログラム（例えば、アプリケーションのプログラム等）を記憶するために用いられる。また、本体装置２は、電源ボタン２８を備える。
【0044】
本体装置２は、下側端子２７を備える。下側端子２７は、本体装置２がクレードルと通信を行うための端子である。本実施形態において、下側端子２７は、ＵＳＢコネクタ（より具体的には、メス側コネクタ）である。上記一体型装置または本体装置２単体をクレードルに載置した場合、ゲームシステム１は、本体装置２が生成して出力する画像を据置型モニタに表示することができる。また、本実施形態においては、クレードルは、載置された上記一体型装置または本体装置２単体を充電する機能を有する。また、クレードルは、ハブ装置（具体的には、ＵＳＢハブ）の機能を有する。
【0045】
図４は、左コントローラ３の一例を示す六面図である。図４に示すように、左コントローラ３は、ハウジング３１を備える。本実施形態においては、ハウジング３１は、縦長の形状、すなわち、上下方向（すなわち、図１および図４に示すｙ軸方向）に長い形状である。左コントローラ３は、本体装置２から外された状態において、縦長となる向きで把持されることも可能である。ハウジング３１は、縦長となる向きで把持される場合に片手、特に左手で把持可能な形状および大きさをしている。また、左コントローラ３は、横長となる向きで把持されることも可能である。左コントローラ３が横長となる向きで把持される場合には、両手で把持されるようにしてもよい。
【0046】
左コントローラ３は、アナログスティック３２を備える。図４に示すように、アナログスティック３２は、ハウジング３１の主面に設けられる。アナログスティック３２は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、アナログスティック３２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。なお、左コントローラ３は、方向入力部として、アナログスティックに代えて、十字キーまたはスライド入力が可能なスライドスティック等を備えるようにしてもよい。また、本実施形態においては、アナログスティック３２を押下する入力が可能である。
【0047】
左コントローラ３は、各種操作ボタンを備える。左コントローラ３は、ハウジング３１の主面上に４つの操作ボタン３３～３６（具体的には、右方向ボタン３３、下方向ボタン３４、上方向ボタン３５、および左方向ボタン３６）を備える。さらに、左コントローラ３は、録画ボタン３７および－（マイナス）ボタン４７を備える。左コントローラ３は、ハウジング３１の側面の左上に第１Ｌボタン３８およびＺＬボタン３９を備える。また、左コントローラ３は、ハウジング３１の側面の、本体装置２に装着される際に装着される側の面に第２Ｌボタン４３および第２Ｒボタン４４を備える。これらの操作ボタンは、本体装置２で実行される各種プログラム（例えば、ＯＳプログラムやアプリケーションプログラム）に応じた指示を行うために用いられる。
【0048】
また、左コントローラ３は、左コントローラ３が本体装置２と有線通信を行うための端子４２を備える。
【0049】
図５は、右コントローラ４の一例を示す六面図である。図５に示すように、右コントローラ４は、ハウジング５１を備える。本実施形態においては、ハウジング５１は、縦長の形状、すなわち、上下方向に長い形状である。右コントローラ４は、本体装置２から外された状態において、縦長となる向きで把持されることも可能である。ハウジング５１は、縦長となる向きで把持される場合に片手、特に右手で把持可能な形状および大きさをしている。また、右コントローラ４は、横長となる向きで把持されることも可能である。右コントローラ４が横長となる向きで把持される場合には、両手で把持されるようにしてもよい。
【0050】
右コントローラ４は、左コントローラ３と同様、方向入力部としてアナログスティック５２を備える。本実施形態においては、アナログスティック５２は、左コントローラ３のアナログスティック３２と同じ構成である。また、右コントローラ４は、アナログスティックに代えて、十字キーまたはスライド入力が可能なスライドスティック等を備えるようにしてもよい。また、右コントローラ４は、左コントローラ３と同様、ハウジング５１の主面上に４つの操作ボタン５３～５６（具体的には、Ａボタン５３、Ｂボタン５４、Ｘボタン５５、およびＹボタン５６）を備える。さらに、右コントローラ４は、＋（プラス）ボタン５７およびホームボタン５８を備える。また、右コントローラ４は、ハウジング５１の側面の右上に第１Ｒボタン６０およびＺＲボタン６１を備える。また、右コントローラ４は、左コントローラ３と同様、第２Ｌボタン６５および第２Ｒボタン６６を備える。
【0051】
また、右コントローラ４は、右コントローラ４が本体装置２と有線通信を行うための端子６４を備える。
【0052】
図６は、本体装置２の内部構成の一例を示すブロック図である。本体装置２は、図３に示す構成の他、図６に示す各構成要素８１～８５、８７、８８、９１、９７、および９８を備える。これらの構成要素８１～８５、８７、８８、９１、９７、および９８のいくつかは、電子部品として電子回路基板上に実装されてハウジング１１内に収納されてもよい。
【0053】
本体装置２は、プロセッサ８１を備える。プロセッサ８１は、本体装置２において実行される各種の情報処理を実行する情報処理部であって、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ８１は、記憶部（具体的には、フラッシュメモリ８４等の内部記憶媒体、あるいは、スロット２３に装着される外部記憶媒体等）に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。
【0054】
本体装置２は、自身に内蔵される内部記憶媒体の一例として、フラッシュメモリ８４およびＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８５を備える。フラッシュメモリ８４およびＤＲＡＭ８５は、プロセッサ８１に接続される。フラッシュメモリ８４は、主に、本体装置２に保存される各種のデータ（プログラムであってもよい）を記憶するために用いられるメモリである。ＤＲＡＭ８５は、情報処理において用いられる各種のデータを一時的に記憶するために用いられるメモリである。
【0055】
本体装置２は、スロットインターフェース（以下、「Ｉ／Ｆ」と略記する。）９１を備える。スロットＩ／Ｆ９１は、プロセッサ８１に接続される。スロットＩ／Ｆ９１は、スロット２３に接続され、スロット２３に装着された所定の種類の記憶媒体（例えば、専用メモリカード）に対するデータの読み出しおよび書き込みを、プロセッサ８１の指示に応じて行う。
【0056】
プロセッサ８１は、フラッシュメモリ８４およびＤＲＡＭ８５、ならびに上記各記憶媒体との間でデータを適宜読み出したり書き込んだりして、上記の情報処理を実行する。
【0057】
本体装置２は、ネットワーク通信部８２を備える。ネットワーク通信部８２は、プロセッサ８１に接続される。ネットワーク通信部８２は、ネットワークを介して外部の装置と通信（具体的には、無線通信）を行う。本実施形態においては、ネットワーク通信部８２は、第１の通信態様としてＷｉ－Ｆｉの規格に準拠した方式により、無線ＬＡＮに接続して外部装置と通信を行う。また、ネットワーク通信部８２は、第２の通信態様として所定の通信方式（例えば、独自プロトコルによる通信や、赤外線通信）により、同種の他の本体装置２との間で無線通信を行う。なお、上記第２の通信態様による無線通信は、閉ざされたローカルネットワークエリア内に配置された他の本体装置２との間で無線通信可能であり、複数の本体装置２の間で直接通信することによってデータが送受信される、いわゆる「ローカル通信」を可能とする機能を実現する。
【0058】
本体装置２は、コントローラ通信部８３を備える。コントローラ通信部８３は、プロセッサ８１に接続される。コントローラ通信部８３は、左コントローラ３および／または右コントローラ４と無線通信を行う。本体装置２と左コントローラ３および右コントローラ４との通信方式は任意であるが、本実施形態においては、コントローラ通信部８３は、左コントローラ３との間および右コントローラ４との間で、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った通信を行う。
【0059】
プロセッサ８１は、上述の左側端子１７、右側端子２１、および下側端子２７に接続される。プロセッサ８１は、左コントローラ３と有線通信を行う場合、左側端子１７を介して左コントローラ３へデータを送信するとともに、左側端子１７を介して左コントローラ３から操作データを受信する。また、プロセッサ８１は、右コントローラ４と有線通信を行う場合、右側端子２１を介して右コントローラ４へデータを送信するとともに、右側端子２１を介して右コントローラ４から操作データを受信する。また、プロセッサ８１は、クレードルと通信を行う場合、下側端子２７を介してクレードルへデータを送信する。このように、本実施形態においては、本体装置２は、左コントローラ３および右コントローラ４との間で、それぞれ有線通信と無線通信との両方を行うことができる。また、左コントローラ３および右コントローラ４が本体装置２に装着された一体型装置または本体装置２単体がクレードルに装着された場合、本体装置２は、クレードルを介してデータ（例えば、画像データや音声データ）を据置型モニタ等に出力することができる。
【0060】
ここで、本体装置２は、複数の左コントローラ３と同時に（換言すれば、並行して）通信を行うことができる。また、本体装置２は、複数の右コントローラ４と同時に（換言すれば、並行して）通信を行うことができる。したがって、複数のユーザは、左コントローラ３および右コントローラ４のセットをそれぞれ用いて、本体装置２に対する入力を同時に行うことができる。一例として、第１ユーザが左コントローラ３および右コントローラ４の第１セットを用いて本体装置２に対して入力を行うと同時に、第２ユーザが左コントローラ３および右コントローラ４の第２セットを用いて本体装置２に対して入力を行うことが可能となる。
【0061】
また、ディスプレイ１２は、プロセッサ８１に接続される。プロセッサ８１は、（例えば、上記の情報処理の実行によって）生成した画像および／または外部から取得した画像をディスプレイ１２に表示する。
【0062】
本体装置２は、コーデック回路８７およびスピーカ（具体的には、左スピーカおよび右スピーカ）８８を備える。コーデック回路８７は、スピーカ８８および音声入出力端子２５に接続されるとともに、プロセッサ８１に接続される。コーデック回路８７は、スピーカ８８および音声入出力端子２５に対する音声データの入出力を制御する回路である。
【0063】
本体装置２は、電力制御部９７およびバッテリ９８を備える。電力制御部９７は、バッテリ９８およびプロセッサ８１に接続される。また、図示しないが、電力制御部９７は、本体装置２の各部（具体的には、バッテリ９８の電力の給電を受ける各部、左側端子１７、および右側端子２１）に接続される。電力制御部９７は、プロセッサ８１からの指令に基づいて、バッテリ９８から上記各部への電力供給を制御する。
【0064】
また、バッテリ９８は、下側端子２７に接続される。外部の充電装置（例えば、クレードル）が下側端子２７に接続され、下側端子２７を介して本体装置２に電力が供給される場合、供給された電力がバッテリ９８に充電される。
【0065】
【0066】
左コントローラ３は、本体装置２との間で通信を行う通信制御部１０１を備える。図７に示すように、通信制御部１０１は、端子４２を含む各構成要素に接続される。本実施形態においては、通信制御部１０１は、端子４２を介した有線通信と、端子４２を介さない無線通信との両方で本体装置２と通信を行うことが可能である。通信制御部１０１は、左コントローラ３が本体装置２に対して行う通信方法を制御する。すなわち、左コントローラ３が本体装置２に装着されている場合、通信制御部１０１は、端子４２を介して本体装置２と通信を行う。また、左コントローラ３が本体装置２から外されている場合、通信制御部１０１は、本体装置２（具体的には、コントローラ通信部８３）との間で無線通信を行う。コントローラ通信部８３と通信制御部１０１との間の無線通信は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）の規格に従って行われる。
【0067】
また、左コントローラ３は、例えばフラッシュメモリ等のメモリ１０２を備える。通信制御部１０１は、例えばマイコン（マイクロプロセッサとも言う）で構成され、メモリ１０２に記憶されるファームウェアを実行することによって各種の処理を実行する。
【0068】
左コントローラ３は、各ボタン１０３（具体的には、ボタン３３～３９、４３、４４、および４７）を備える。また、左コントローラ３は、アナログスティック（図７では「スティック」と記載する）３２を備える。各ボタン１０３およびアナログスティック３２は、自身に対して行われた操作に関する情報を、適宜のタイミングで繰り返し通信制御部１０１へ出力する。
【0069】
通信制御部１０１は、各入力部（具体的には、各ボタン１０３、および、アナログスティック３２）から、入力に関する情報（具体的には、操作に関する情報、またはセンサによる検出結果）を取得する。通信制御部１０１は、取得した情報（または取得した情報に所定の加工を行った情報）を含む操作データを本体装置２へ送信する。なお、操作データは、所定時間に１回の割合で繰り返し送信される。なお、入力に関する情報が本体装置２へ送信される間隔は、各入力部について同じであってもよいし、同じでなくてもよい。
【0070】
上記操作データが本体装置２へ送信されることによって、本体装置２は、左コントローラ３に対して行われた入力を得ることができる。すなわち、本体装置２は、各ボタン１０３およびアナログスティック３２に対する操作を、操作データに基づいて判別することができる。
【0071】
左コントローラ３は、電力供給部１０８を備える。本実施形態において、電力供給部１０８は、バッテリおよび電力制御回路を有する。図示しないが、電力制御回路は、バッテリに接続されるとともに、左コントローラ３の各部（具体的には、バッテリの電力の給電を受ける各部）に接続される。
【0072】
図７に示すように、右コントローラ４は、本体装置２との間で通信を行う通信制御部１１１を備える。また、右コントローラ４は、通信制御部１１１に接続されるメモリ１１２を備える。通信制御部１１１は、端子６４を含む各構成要素に接続される。通信制御部１１１およびメモリ１１２は、左コントローラ３の通信制御部１０１およびメモリ１０２と同様の機能を有する。したがって、通信制御部１１１は、端子６４を介した有線通信と、端子６４を介さない無線通信（具体的には、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った通信）との両方で本体装置２と通信を行うことが可能であり、右コントローラ４が本体装置２に対して行う通信方法を制御する。
【0073】
右コントローラ４は、左コントローラ３の各入力部と同様の各入力部を備える。具体的には、各ボタン１１３、および、アナログスティック５２を備える。これらの各入力部については、左コントローラ３の各入力部と同様の機能を有し、同様に動作する。
【0074】
右コントローラ４は、電力供給部１１８を備える。電力供給部１１８は、左コントローラ３の電力供給部１０８と同様の機能を有し、同様に動作する。
【0075】
［２．情報処理システムの構成］
図８は、図１に示すゲームシステムを含む情報処理システムの構成の一例を示すブロック図である。図８に示すように、本実施形態における情報処理システムは、上述のゲームシステム１であって、異なるユーザによって使用される複数のゲームシステム（図８においては、ゲームシステム１ａおよび１ｂを例示している）を含む。以下では、情報処理システムに含まれる複数のゲームシステムのうちの任意の１つのゲームシステムを「ゲームシステム１」と記載することがある。なお、情報処理システムに含まれる上記複数のゲームシステムのうちには、ゲームシステム１とは異なる種類の情報処理装置が含まれていてもよく、ゲームシステム１と、当該異なる種類の情報処理装置との間で、後述するゲーム処理（図１０および図１１参照）が実行されてもよい。
図８は、図１に示すゲームシステムを含む情報処理システムの構成の一例を示すブロック図である。図８に示すように、本実施形態における情報処理システムは、上述のゲームシステム１であって、異なるユーザによって使用される複数のゲームシステム（図８においては、ゲームシステム１ａおよび１ｂを例示している）を含む。以下では、情報処理システムに含まれる複数のゲームシステムのうちの任意の１つのゲームシステムを「ゲームシステム１」と記載することがある。なお、情報処理システムに含まれる上記複数のゲームシステムのうちには、ゲームシステム１とは異なる種類の情報処理装置が含まれていてもよく、ゲームシステム１と、当該異なる種類の情報処理装置との間で、後述するゲーム処理（図１０および図１１参照）が実行されてもよい。
【0076】
図８に示すように、情報処理システムは、各ゲームシステムと通信可能なサーバ２０１を含む。本実施形態においては、ゲームシステム１およびサーバ２０１は、インターネットおよび／またはモバイル通信網等のネットワーク２０２に接続可能である。ゲームシステム１およびサーバ２０１は、ネットワーク２０２を介して互いに通信可能である。
【0077】
ここで、本明細書では、「サーバ」とは、１つの情報処理装置（すなわち、サーバ装置）を指す他、そのサーバの機能が複数のサーバ装置によって実現される場合にはサーバ装置群（すなわち、サーバシステム）全体を指す意味である。つまり、「サーバ」とは、サーバ装置であってもよいし、サーバシステムであってもよい。なお、サーバシステムに複数の情報処理装置が含まれる場合、各情報処理装置は、同じ場所に配置されてもよいし、異なる場所に配置されてもよい。なお、本実施形態におけるサーバ２０１のハードウェア構成は、従来のサーバのためのハードウェア構成と同様であってもよい。
【0078】
図９は、サーバ２０１の構成の一例を示すブロック図である。図９に示すサーバ２０１が備える各構成は、１以上の情報処理装置によって実現される。図９に示すように、サーバ２０１は、処理部２１１および記憶部２１２を備える。処理部２１１は、サーバ２０１の各部１２～１５に電気的に接続される。処理部２１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、換言すれば、プロセッサ）およびメモリを有する。サーバ２０１においては、ＣＰＵがメモリを用いて、記憶部２１２に記憶されたプログラムを実行することによって各種の情報処理が実行される。記憶部２１２は、処理部２１１がアクセス可能な任意の記憶装置（記憶媒体とも言う）である。記憶部２１２は、処理部２１１において実行されるプログラム、処理部２１１による情報処理に用いられるデータ、および、当該情報処理によって得られたデータ等を記憶する。本実施形態においては、記憶部２１２は、ゲームシステム１において実行されるゲーム処理のためにサーバ側で実行されるゲーム処理のためのプログラムを少なくとも記憶する。
【0079】
サーバ２０１は、通信部２１３を備える。通信部２１３は、ネットワーク２０２に接続し、ネットワーク２０２を介して他の装置（例えば、ゲームシステム１）と通信を行う機能を有する。処理部２１１は、通信部２１３を用いて、上記他の装置へ情報を送信したり、上記他の装置から情報を受信したりする。また、サーバ２０１は、入出力インターフェースとして、入力部２１４および表示部２１５を備える。
【0080】
［３．情報処理システムにおける処理の概要］
次に、図１０～図１４を参照して、図９に示す情報処理システムにおいて実行される処理の概要について説明する。本実施形態においては、ゲームシステム１は、プレイヤ（ユーザとも言う）によって操作されるプレイヤキャラクタがゲーム空間に登場するゲームを実行する。なお、上記ゲームの内容は任意であり、上記ゲームにおいては、プレイヤキャラクタは、ゲーム空間におけるゲームフィールド上をプレイヤによる操作に応じて移動する。本実施形態においては、上記の複数のゲームシステムのうち、あるゲームシステムにおいて実行される第１のゲームにおいて、当該第１のゲームのプレイヤキャラクタがアイテムを紛失する（落とすとも言う）場合がある。この場合、他のゲームシステムにおいて実行される第２のゲームにおいて、当該第２のゲームのプレイヤキャラクタが上記のアイテムを拾うことで、当該アイテムが回収される（すなわち、アイテムが第１のゲームのプレイヤキャラクタの元に戻る）処理が実行される。以下、この処理について説明する。
次に、図１０～図１４を参照して、図９に示す情報処理システムにおいて実行される処理の概要について説明する。本実施形態においては、ゲームシステム１は、プレイヤ（ユーザとも言う）によって操作されるプレイヤキャラクタがゲーム空間に登場するゲームを実行する。なお、上記ゲームの内容は任意であり、上記ゲームにおいては、プレイヤキャラクタは、ゲーム空間におけるゲームフィールド上をプレイヤによる操作に応じて移動する。本実施形態においては、上記の複数のゲームシステムのうち、あるゲームシステムにおいて実行される第１のゲームにおいて、当該第１のゲームのプレイヤキャラクタがアイテムを紛失する（落とすとも言う）場合がある。この場合、他のゲームシステムにおいて実行される第２のゲームにおいて、当該第２のゲームのプレイヤキャラクタが上記のアイテムを拾うことで、当該アイテムが回収される（すなわち、アイテムが第１のゲームのプレイヤキャラクタの元に戻る）処理が実行される。以下、この処理について説明する。
【0081】
図１０は、ゲームにおいて紛失されたアイテムが回収される流れの一例を示す図である。図１０においては、複数のゲームシステムのうち、１つのゲームシステム（例えば、ゲームシステム１ａ）において、プレイヤキャラクタＡが登場する第１のゲームが実行され、他の１つのゲームシステム（例えば、ゲームシステム１ｂ）において、プレイヤキャラクタＢが登場する第２ゲームが実行される場合を例として説明する。
【0082】
本実施形態においては、上記の第１のゲームと第２のゲームは、ゲームシステムにおいて実行されるゲームプログラムとしては同じまたは同種のゲームであり、互いに異なるプレイヤによって行われるゲームである。第１のゲームと第２のゲームは、同じまたは同種のゲームプログラムによるゲームであって、ゲーム内における状況（例えば、各キャラクタの状態やゲームのストーリーの進行状況）が異なっているゲームと言うこともできる。第１のゲームと第２のゲームは、同じまたは同種のゲームプログラムによるゲームであって、セーブデータが異なるゲームと言うこともできる。なお、上記「同種のゲーム」とは、例えば、ゲームプログラムのバージョンが異なる２つのゲームや、ゲームフィールドは同じであるものの、登場するキャラクタの一部やストーリーの一部が異なる２つのゲーム等である。なお、他の実施形態においては、第１のゲームと第２のゲームは、異なる種類のゲームであってもよい。
【0083】
本実施形態においては、ゲーム中において所定のイベント発生条件が満たされた場合に、フィールド上においてプレイヤキャラクタが倒されることがある。このイベント発生条件は、例えば、プレイヤキャラクタが敵キャラクタの攻撃を受けた結果、プレイヤキャラクタの体力が０になったことである。図１０に示す例においては、第１のゲームにおいてプレイヤキャラクタＡが倒されたものとする。
【0084】
上記のようにプレイヤキャラクタが倒された場合、プレイヤキャラクタは、所有しているアイテムを紛失する（図１０に示す場面（ａ））。以下では、プレイヤキャラクタがアイテムを紛失するゲームイベントを「紛失イベント」と呼ぶ。図１０に示すゲーム画像２２１は、紛失イベントが発生したときのゲーム画像の一例である。紛失イベントが発生した場合、ゲームシステム１は、プレイヤキャラクタが倒されたことと、プレイヤキャラクタがアイテムを落とした（すなわち、紛失した）こととを通知する表示を行う。なお、本実施形態においては、ゲーム設定上、紛失イベントによってプレイヤキャラクタはアイテムをゲームフィールドに落としたと表現されるものとするが、実際には第１のゲームにおいては（プレイヤキャラクタが紛失イベントの発生位置に行っても）当該アイテムを拾得することはできず、第１のゲームとは異なる第２のゲームにおいて当該アイテムを拾得することができる。ただし、他の実施形態においては、第１のゲームにおいても、紛失イベントの発生位置に行くことで、プレイヤキャラクタが自身が落としたアイテムを拾得することができるようにしてもよい。
【0085】
図１０において、第１のゲームにおいて紛失イベントが発生したことを示す情報は、ゲームシステム１ａからサーバ２０１へ送信され、サーバ２０１から他のゲームシステム（ここでは、第２のゲームが実行されるゲームシステム１ｂ）へ送信される。第２のゲームにおいては、プレイヤキャラクタＢは、第１のゲームにおいてプレイヤキャラクタＡがアイテムを落とした位置（つまり、紛失イベントが発生した位置）に行くことで、プレイヤキャラクタＡの落とし物（すなわち、アイテム）を拾うことができる（図１０に示す場面（ｂ））。以下では、プレイヤキャラクタが他のプレイヤキャラクタの落とし物を拾うゲームイベントを「拾得イベント」と呼ぶ。図１０に示すゲーム画像２２２は、拾得イベントが発生したときのゲーム画像の一例である。拾得イベントが発生した場合、ゲームシステム１は、プレイヤキャラクタが落とし物を拾ったことと、落とし主であるプレイヤキャラクタ（ここでは、プレイヤキャラクタＡ）の元へ落とし物が送られたこととを通知する表示を行う。
【0086】
図１０において、第２のゲームにおいて拾得イベントが発生したことを示す情報は、ゲームシステム１ｂからサーバ２０１へ送信され、サーバ２０１から、第１のゲームが実行されるゲームシステム１ａへ送信される。これによって、第１のゲームにおいては、紛失イベントによって消失された落とし物が回収される、すなわち、消失したアイテムがプレイヤキャラクタＡの元に戻る（図１０に示す場面（ｃ））。図１０に示すゲーム画像２２３は、落とし物が回収されたときのゲーム画像の一例である。落とし物が回収される場合、ゲームシステム１は、落とし物が戻って来たことと、落とし物を拾った拾い主のプレイヤキャラクタ（ここでは、プレイヤキャラクタＢ）とを通知する表示を行う。
【0087】
以上のようにして、本実施形態においては、ゲームにおいてプレイヤキャラクタが倒されて紛失イベントが発生した場合であっても、他のゲームにおいて他のプレイヤキャラクタによって拾得イベントが発生したことによって、プレイヤキャラクタは、紛失イベントによって失われたアイテムを取り戻すことができる。また、プレイヤキャラクタは、他のゲームにおける他のプレイヤキャラクタによって紛失イベントが発生した場合には、拾得イベントを行うことで当該他のプレイヤキャラクタを助けることができる。このように、本実施形態におけるゲームにおいては、紛失イベントおよび拾得イベントを通じて非同期的に他のプレイヤキャラクタと協力してゲームを進行させることができる。
【0088】
図１１は、紛失イベントが発生してから、アイテムが回収されるまでの処理の流れの一例を示す図である。なお、図１１においては、ゲームシステム１ａにおけるゲームにおいて紛失イベントが発生し、ゲームシステム１ｂにおけるゲームにおいて拾得イベントが発生する場合を例として説明する。
【0089】
図１１においてまず、ゲームシステム１ａにおいてイベント発生条件が満たされると、紛失イベントが発生する（ステップＳ１）。すなわち、ゲームシステム１ａは、プレイヤキャラクタが所有するアイテムを消失させる。本実施形態においては、ゲームシステム１ａは、予め定められたルールに基づいて、プレイヤキャラクタが所有する全てのアイテムのうちから、いくつかのアイテムを消失させる。上記のルールは任意である。例えば、ゲームシステム１ａは、ゲームのストーリーの進行に必要となるアイテム、あるいは、貴重なアイテム（例えば、入手数が限られているアイテム）については、紛失イベントが発生しても消失させないようにしてもよい。また、上記のルールとして、プレイヤキャラクタが所有する全てのアイテムのうちから、ランダムに選出されたいくつかのアイテムを消失させるルールが用いられてもよい。
【0090】
なお、本実施形態においては、紛失イベントが発生した場合、プレイヤキャラクタはゲームフィールドにおける所定の位置（例えば、拠点の位置）に戻されてゲームが再開される。ただし、紛失イベントが発生した場合におけるゲームの再開方法は任意である。例えば、他の実施形態においては、紛失イベントが発生した位置からゲームが再開されてもよい。
【0091】
次に、ゲームシステム１ａは、自機で紛失イベントが発生したことを示す自紛失イベントデータを生成して、サーバ２０１へ送信する（ステップＳ２）。本実施形態においては、自紛失イベントデータは、位置情報、日時情報、代表アイテム情報、種類数情報、および、落とし主情報を含む。
【0092】
位置情報は、ゲームフィールド上において紛失イベントが発生した位置（プレイヤキャラクタがアイテムを落とした位置とも言える）を示す。日時情報は、紛失イベントが発生した日時を示す。
【0093】
代表アイテム情報は、紛失イベントによって消失されたアイテムのうちで代表となるアイテムを示す。なお、代表となるアイテムの決定方法は任意である。例えば、ゲームシステムは、アイテムの種類毎に優先順位を設定しておき、紛失イベントによって消失されたアイテムのうちで、この優先順位が最も高いアイテムを代表アイテムとしてもよい。種類数情報は、紛失イベントによって消失されたアイテムの種類数を示す。このように、本実施形態においては、代表アイテム情報および種類数情報といった、紛失イベントによって消失されたアイテムの概要を示す情報がサーバ２０１および他のゲームシステムへ送信され、消失された全てのアイテムを示す情報は自紛失イベントデータには含まれない。これによって、ゲームシステムとサーバ２０１との間における通信量の低減を図ることができる。なお、紛失イベントによって消失された全てのアイテムを示すデータは、紛失イベントが発生したゲームシステム１ａにおいて記憶される。例えば、ゲームシステム１ａは、上記アイテムを示すデータを、紛失イベントを特定可能な情報（例えば、紛失イベントが発生した日時および／または位置の情報）に関連付けて記憶しておく。
【0094】
落とし主情報は、紛失イベントによってアイテムを紛失したプレイヤキャラクタ（すなわち、落とし主のプレイヤキャラクタ）を示す。なお、落とし主情報は、紛失イベントが発生したゲームシステム１ａのユーザの名前を示すものであってもよい。
【0095】
本実施形態においては、ゲームシステム１ａは、紛失イベントが発生してすぐに自紛失イベントデータを送信するのではなく、紛失イベントが発生した後で、予め定められた送信条件が満たされたことに応じて、自紛失イベントデータを送信する。具体的には、本実施形態においては、ゲームシステム１ａは、紛失イベントが発生してから所定の待機時間が経過したことを条件として、自紛失イベントデータを送信する。上記待機時間は、例えば、３０分から２４時間の間で、予め定められたルールに従って決定される。ゲームシステム１ａは、紛失イベントが発生してから上記待機時間が経過した後で、かつ、ゲームの実行中においてゲームシステム１ａがサーバ２０１と通信可能となったタイミングで、自紛失イベントデータをサーバ２０１へ送信する。ここで、仮に紛失イベントの直後に自紛失イベントデータが送信されるとすれば、紛失イベントの発生からすぐに拾得イベントが発生する結果、消失されたアイテムがすぐに戻って来てしまう可能性がある。このとき、紛失イベントの意味が小さくなり、ゲームの興趣性が低下するおそれがある。これに対して、本実施形態においては、少なくとも待機時間が経過するまでは自紛失イベントデータが送信されないので、紛失イベントの直後に拾得イベントが発生することを防止することができる。
【0096】
なお、上記送信条件の内容は任意であり、本実施形態のような、紛失イベントが発生してからの時間に関する条件に限らない。例えば、他の実施形態においては、送信条件は、ゲームにおいてプレイヤキャラクタが所定の行動をとったこと（例えば、ゲーム内における所定の施設で落とし物の申請を行ったこと）であってもよい。また他の実施形態においては、ゲームシステム１ａは、送信条件を設定せず、紛失イベントが発生してすぐに自紛失イベントデータを送信してもよい。このとき、サーバ２０１は、自紛失イベントデータを受信しても待機時間が経過するまでは、他のゲームシステムにおいて拾得イベントが発生しないようにしてもよい（すなわち、後述する他紛失イベントデータを送信しないようにしてもよい）。
【0097】
サーバ２０１は、ゲームシステム１ａから自紛失イベントデータを受信すると、受信した自紛失イベントデータに基づいてイベント管理データを生成して記憶する（ステップＳ３）。イベント管理データは、１つの紛失イベントに関する内容および状況を示すデータである。
【0098】
図１２は、イベント管理データの一例を示す図である。図１２に示すように、イベント管理データは、位置情報、日時情報、代表アイテム情報、種類数情報、落とし主情報、報酬情報、拾い主情報、および、イベント状況情報を含む。
【0099】
位置情報、日時情報、代表アイテム情報、種類数情報、および、落とし主情報は、自紛失イベントデータに含まれる各情報と同じ内容であってよい。なお、イベント管理データに含まれる位置情報は、自紛失イベントデータに含まれる位置情報が示す位置とは異なる位置であってもよく、当該位置情報に基づいて決定される位置を示してもよい。例えば、サーバ２０１は、自紛失イベントデータに含まれる位置情報が示す位置に基づいて、当該位置の近傍の位置を決定し、決定された位置を示す位置情報をイベント管理データに含めてもよい。また、イベント管理データに含まれる日時情報は、自紛失イベントデータが送信された（あるいは、サーバ２０１に受信された）日時を示すものであってもよい。
【0100】
報酬情報は、紛失イベントに対する拾得イベントを発生させたプレイヤキャラクタに対して付与される報酬を示す。報酬の内容はどのように決定されてもよい。例えば、サーバ２０１は、自紛失イベントデータに含まれる代表アイテム情報および／または種類数情報に基づいて、報酬の内容を決定してもよい。また、他の実施形態において、報酬の内容は、紛失イベントが発生したゲームシステム１ａにおいて決定されて自紛失イベントデータに報酬の情報が含まれていてもよいし、拾得イベントが発生するゲームシステム１ｂにおいて決定されてもよい。
【0101】
拾い主情報は、紛失イベントに対する拾得イベントを発生させたプレイヤキャラクタを示す。イベント管理データが生成される時点では、まだ拾得イベントが発生していないので、拾い主情報は、拾い主がいないことを示す内容に設定される。なお、拾い主情報は、拾得イベントが発生したゲームシステム１ｂのユーザの名前を示すものであってもよい。
【0102】
イベント状況情報は、紛失イベントに対する拾得イベントが未発生であるか、それとも、発生済であるかを示す。イベント管理データが生成される時点では、まだ拾得イベントが発生していないので、イベント状況情報は、拾得イベントが未発生であることを示す内容に設定される。
【0103】
【0104】
図１３に示すように、本実施形態においては、サーバ２０１の記憶部２１２は第１記憶領域および第２記憶領域を有する。サーバ２０１において、イベント管理データは、第１記憶領域と第２記憶領域とに区別して記憶される。なお、第１記憶領域および第２記憶領域は、それぞれの領域に記憶されるイベント管理データを区別することができればよく、物理的に別の記憶領域である必要はない。
【0105】
本実施形態においては、第１記憶領域には、紛失イベントによって消失されたアイテムが未回収である（つまり、当該アイテムがプレイヤキャラクタの元に戻されていない）状態である紛失イベントのイベント管理データが記憶される。つまり、第１記憶領域に記憶されるイベント管理データには、拾得イベントが未発生である紛失イベントに関するイベント管理データと、拾得イベントが発生済であるものの、アイテムが未回収である紛失イベントに関するイベント管理データとが含まれる。本実施形態においては、サーバ２０１においてイベント管理データが生成された場合（つまり、ゲームシステムにおいて紛失イベントが発生した場合）には、当該イベント管理データはまず第１記憶領域に記憶される。
【0106】
第２記憶領域には、拾得イベントが発生済である紛失イベントに関するイベント管理データが記憶される。詳細は後述するが、第１記憶領域に記憶されているイベント管理データについて拾得イベントが発生した場合、サーバ２０１は、当該イベント管理データを一定条件下で第２記憶領域に記憶する。本実施形態における第１記憶領域および第２記憶領域の詳細な利用方法については後述する。
【0107】
図１１の説明に戻り、自紛失イベントデータがサーバ２０１に記憶された後において、ゲームシステム１ｂは、イベント受信要求をサーバへ送信する（ステップＳ４）。イベント受信要求は、他のゲームシステムのゲームにおいて発生した紛失イベントに関するデータ（「他紛失イベントデータ」と呼ぶ。）を受信する要求である。この他紛失イベントデータを受信することで、ゲームシステム１ｂは、他のゲームシステムで発生した紛失イベントに対応する拾得イベントを発生させることが可能となる。なお、ゲームシステムからイベント受信要求が送信される条件およびタイミングは任意である。本実施形態においては、ゲームシステム１ｂは、ゲーム中においてプレイヤによる指示が行われたことに応じて、イベント受信要求をサーバ２０１へ送信する。
【0108】
サーバ２０１は、ゲームシステム１ｂからイベント受信要求を受信すると、他紛失イベントデータを生成して当該ゲームシステム１ｂへ送信する（ステップＳ５）。他紛失イベントデータは、他のゲームシステムのゲームにおいて発生した紛失イベントの内容を含むデータである。サーバ２０１は、記憶部２１２に記憶されているイベント管理データに基づいて他紛失イベントデータを生成する。具体的には、本実施形態においては、他紛失イベントデータは、上述の位置情報、報酬情報、代表アイテム情報、種類数情報、落とし主情報、および、イベント状況情報を含む。サーバ２０１は、これらの情報をイベント管理データから抽出することで他紛失イベントデータを生成する。
【0109】
本実施形態においては、上記ステップＳ５において、サーバ２０１は、複数の他紛失イベントデータを生成してゲームシステム１ｂへ送信する。つまり、サーバ２０１は、複数の紛失イベントに関する他紛失イベントデータをそれぞれ生成してゲームシステム１ｂへ送信する。
【0110】
図１４は、他紛失イベントデータの生成方法の一例を示す図である。本実施形態においては、サーバ２０１は、ゲームシステム１ｂへ送信する送信データとして、所定の数（ここでは、８０～１００）の他紛失イベントデータを含むデータを生成する（図１４参照）。
【0111】
具体的には、サーバ２０１は、ゲームシステム１ｂのプレイヤのフレンドであるプレイヤに関する紛失イベントの他紛失イベントデータ（「フレンドの他紛失イベントデータ」と呼ぶ。）を、第１上限数（ここでは、２０）を上限として上記送信データに含める（図１４参照）。ここで、本実施形態においては、サーバ２０１は、各ゲームシステム１のプレイヤについて、当該プレイヤのフレンドとして登録されているプレイヤの情報を記憶しているものとする。サーバ２０１は、記憶部２１２の第１記憶領域に記憶されているイベント管理データのうちから、ゲームシステム１ｂのプレイヤのフレンドであるプレイヤに関するイベント管理データ（「フレンドのイベント管理データ」と呼ぶ。）を上記第１上限数を上限として選出し、選出されたイベント管理データに対応する他紛失イベントデータを生成する。なお、第１記憶領域に記憶されているイベント管理データのうちに含まれるフレンドのイベント管理データの数が上記第１上限数より多い場合において、フレンドのイベント管理データを選出する方法は任意である。第１記憶領域に記憶されているイベント管理データのうちに含まれるフレンドのイベント管理データの数が上記第１上限数より少ない場合、サーバ２０１は、第１記憶領域に記憶されている数だけフレンドのイベント管理データを選出する。
【0112】
上記のように、本実施形態においては、サーバ２０１は、他紛失イベントデータを受信する旨のイベント受信要求がゲームシステム１ｂからあった場合であって、当該ゲームシステム１ｂのプレイヤとの間でフレンド登録済のプレイヤに関するイベント管理データ（すなわち、フレンドのイベント管理データ）が第１記憶領域に記憶されている場合、当該イベント管理データに基づく他紛失イベントデータを含む少なくとも１つの他紛失イベントデータを当該ゲームシステム１ｂへ送信する。これによれば、あるプレイヤについて紛失イベントが発生した場合、当該プレイヤのフレンドであるプレイヤに対して、当該紛失イベントに対する拾得イベントを行う機会を与えやすくすることができる。これによって、拾得イベントを行う動機付けをプレイヤに与えることができる。また、プレイヤは、自身のフレンドであるプレイヤと協力してゲームを行うことができる。
【0113】
また、サーバ２０１は、記憶部２１２の第１記憶領域に記憶されているイベント管理データのうちから、拾得イベントが未発生であるイベント管理データ（「未発生のイベント管理データ」と呼ぶ。）を、第２上限数（ここでは、８０）を上限として選出し、選出されたイベント管理データに対応する他紛失イベントデータを生成する。なお、未発生のイベント管理データの選出方法は任意である。本実施形態においては、サーバ２０１は、第１記憶領域に記憶されている未発生のイベント管理データのうちから、第２上限数を上限として未発生のイベント管理データをランダムに選出する。なお、第１記憶領域に記憶されているイベント管理データのうちに含まれる未発生のイベント管理データの数が上記第２上限数より少ない場合、サーバ２０１は、第１記憶領域に記憶されている数だけ未発生のイベント管理データを選出する。
【0114】
上記のように、本実施形態においては、サーバ２０１は、イベント受信要求がゲームシステム１ｂからあった場合に、第１記憶領域に記憶された未発生のイベント管理データからランダムに選出された少なくとも１つのイベント管理データに基づく他紛失イベントデータをゲームシステム１ｂへ送信する。これによれば、情報処理システムは、拾得イベントが未発生である紛失イベントについて拾得イベントを発生させる機会を確保することができ、拾得イベントによってアイテムが回収される機会を確保することができる。
【0115】
なお、本明細書において「ランダムに選出する」とは、各選出候補（ここでは、イベント管理データ）が等しい確率で選出される方法に限らず、ランダム性を有する結果となるように（つまり、複数回の試行による選出結果が毎回同じにならないような方法で）選出することを含む意味である。例えば、サーバ２０１は、記憶されたイベント管理データが古いほど（つまり、サーバ２０１に記憶されてからの時間が長いほど）選出されやすいような方法で選出を行ってもよい。
【0116】
なお、未発生のイベント管理データの選出方法は任意である。サーバ２０１は、所定の選出ルールに基づいて未発生のイベント管理データを選出してもよい。例えば、上記選出ルールは、イベント管理データがサーバ２０１に記憶された順序に関するルール、あるいは、紛失イベントが発生した順序に関するルールであってもよい。具体的には、サーバ２０１は、イベント受信要求がゲームシステム１ｂからあった場合に、第１記憶領域に記憶された未発生のイベント管理データから、サーバ２０１に記憶された順（あるいは、紛失イベントが発生した順）が古い順に選出された少なくとも１つのイベント管理データに基づく他紛失イベントデータをゲームシステム１ｂへ送信するようにしてもよい。これによれば、発生してからの時間が長い紛失イベントについて拾得イベントが行われやすくすることができる。
【0117】
また例えば、上記選出ルールは、イベント管理データに含まれる位置データが示す位置に関するルールでもよい。具体的には、サーバ２０１は、イベント管理データに含まれる位置情報が示す位置がゲームフィールド上において偏りがでないように、複数のイベント管理データを選出してもよい。例えば、ゲームフィールドが複数のエリアに区分される場合、サーバ２０１は、１つのエリアにつき所定数のイベント管理データが当該エリア内の位置に対応する（つまり、イベント管理データに含まれる位置情報が示す位置が当該エリアに含まれる）ように、複数のイベント管理データを選出してもよい。
【0118】
また、他の実施形態においては、未発生のイベント管理データの選出は、イベント受信要求を送信するゲームシステム１ｂによって行われてもよい。つまり、上記「第１記憶領域に記憶された未発生のイベント管理データからランダムに選出された少なくとも１つのイベント管理データ」とは、ゲームシステム１ｂによって選出されたイベント管理データであってもよい意味である。
【0119】
ここで、第１記憶領域に記憶されているイベント管理データについて拾得イベントが発生すると、第１記憶領域に記憶されている未発生のイベント管理データが少なくなる。このとき、上記の第２上限数（ここでは、８０）の未発生のイベント管理データをサーバ２０１が選出することができない場合があり得る。この場合、サーバ２０１は、第２上限数に足りない分のイベント管理データを、第２記録領域に記憶されているイベント管理データ（すなわち、拾得イベントが発生済であるイベント管理データ。以下、「発生済のイベント管理データ」と呼ぶ。）から選出する。そして、サーバ２０１は、選出されたイベント管理データに基づく他紛失イベントデータを生成する。このように、サーバ２０１は、第１記憶領域に記憶されている未発生のイベント管理データと、第２記憶領域に記憶されている発生済のイベント管理データとの合計が上記第２上限数となるように、イベント管理データを選出する。これによって、第２上限数の他紛失イベントデータが生成される。
【0120】
なお、発生済のイベント管理データを選出する方法は任意である。発生済のイベント管理データを選出する方法は、未発生のイベント管理データを選出する方法と同じであってもよいし、異なっていてもよい。
【0121】
以上のように、本実施形態においては、サーバ２０１は、イベント受信要求がゲームシステム１ｂからあった場合に、少なくとも所定数（すなわち、８０）の他紛失イベントデータを当該ゲームシステム１ｂへ送信する。これによれば、サーバ２０１に記憶されている未発生のイベント管理データが少ない場合であっても、サーバ２０１は一定数の他紛失イベントデータをゲームシステム１ｂへ送信することができる。これによって、ゲームシステム１ｂにおいては、多くの他紛失イベントデータを用いてゲームを行うことができる。
【0122】
また、上記実施形態においては、サーバ２０１は、第２上限数（ここでは、８０）の他紛失イベントデータと、最大で第１上限数（ここでは、２０）の、フレンドのイベント管理データに基づく他紛失イベントデータとをゲームシステム１ｂへ送信する。つまり、サーバ２０１は、イベント受信要求がゲームシステム１ｂからあった場合であって、当該ゲームシステム１ｂのプレイヤとの間でフレンド登録済のプレイヤに関するイベント管理データが第１記憶領域に記憶されている場合、当該フレンド登録済のプレイヤに関する他紛失イベントデータを最大で第１の数（すなわち、２０）、および、当該フレンド登録済のプレイヤとは異なるプレイヤに関する他紛失イベントデータを第２の数（すなわち、８０）、ゲームシステム１ｂへ送信する。これによれば、サーバ２０１は、プレイヤに対して、当該プレイヤのフレンドのプレイヤによる紛失イベントに対する拾得イベントを行う機会を与えることができるとともに、フレンドのプレイヤがいない場合であっても、一定数の他紛失イベントデータをゲームシステムへ送信することができる。
【0123】
なお、他の実施形態においては、サーバ２０１は、プレイヤによる紛失イベントに関するイベント管理データに基づいて他紛失イベントデータを生成することに加えて、プレイヤによる紛失イベントに関連しない（すなわち、イベント管理データに基づかない）特別な他紛失イベントデータを生成するようにしてもよい。例えば、特定の期間において、サーバ２０１は、イベント管理データに基づかずに、特別な報酬が付与される他紛失イベントデータを生成し、イベント管理データに基づいて生成される他紛失イベントデータとともに、ゲームシステムへ送信するようにしてもよい。
【0124】
上記の複数の他紛失イベントデータを含む上記送信データを受信すると、ゲームシステム１ｂは、受信された複数の他紛失イベントデータに基づいて、当該ゲームシステム１ｂにおいて実行されるゲームにおけるゲームフィールドに落とし物を設定する（ステップＳ６）。これによって、ゲームシステム１ｂにおいて実行されるゲームは、プレイヤの操作に基づいて拾得イベントが発生させることが可能な状態となる。
【0125】
本実施形態においては、ゲームシステム１ｂは、受信された複数の他紛失イベントデータのうちから、所定の配置数（例えば、２０）の他紛失イベントデータを選出し、選出された他紛失イベントデータに基づいて落とし物を設定する。ゲームシステム１ｂは、１つの他紛失イベントデータにつき１つの落とし物をゲームフィールドに配置する。本実施形態においては、ゲームシステム１ｂは、他紛失イベントデータに含まれる位置情報が示す位置に落とし物を設定する。なお、他の実施形態においては、落とし物が設定される位置は、他紛失イベントデータに含まれる位置情報が示す位置に限らず、当該位置に基づいて決められる位置（例えば、当該位置の周囲の位置）であってもよいし、当該位置とは独立して決められる位置であってもよい。
【0126】
本実施形態においては、ゲームシステム１ｂは、落とし物がゲームフィールド上に偏りなく配置されるように、上記配置数の他紛失イベントデータを選出する。ここで、本実施形態においてはゲームフィールドが複数（具体的には、５つ）のエリアに区分されているものとする。ゲームシステム１ｂは、５つの各エリアにつきそれぞれ４つの落とし物が配置されるように、合計で上記配置数の他紛失イベントデータを選出する。これによれば、ゲームシステム１ｂは、ゲームフィールドに落とし物をまんべんなく設定することができるので、プレイヤが拾得イベントを発生させやすくすることができる。
【0127】
なお、本実施形態においては、サーバ２０１から受信した複数の他紛失イベントデータのうちに、ある１つのエリアに対応する他紛失イベントデータが４つ未満しか含まれない場合もあり得る（なお、他の実施形態においては、上述したように、各エリアに対応する他紛失イベントデータが４つ以上となるように、サーバ２０１側においてイベント管理データを選出するようにしてもよい。）。本実施形態においては、このような場合、ゲームシステム１ｂは、当該エリアに配置する追加の他紛失イベントデータを新たに生成し、生成された追加の他紛失イベントデータに基づいて落とし物を設定する。追加の他紛失イベントデータは、他のプレイヤによる紛失イベントに関するイベント管理データに基づくイベントデータではなく、イベント管理データに基づかずにゲームシステム１ｂにおいて生成されるイベントデータである。追加の他紛失イベントデータの生成方法は任意である。例えば、ゲームシステム１ｂは、他紛失イベントデータに含まれる位置情報以外の各情報の内容をランダムに設定することで、追加の他紛失イベントデータを生成するようにしてもよい。なお、追加の他紛失イベントデータは、ゲームシステム１ｂにおいて、サーバ２０１から受信した他紛失イベントデータと同様に取り扱われる。例えば、追加の他紛失イベントデータに基づく落とし物について拾得イベントが発生した場合、ゲームシステム１ｂは、他紛失イベントデータに含まれる報酬情報に基づいてプレイヤに報酬を付与する。
【0128】
なお、サーバ２０１から受信された複数の他紛失イベントデータのうちから、落とし物の設定に用いられる他紛失イベントデータを選出する方法は任意である。例えば、他の実施形態においては、サーバ２０１から受信された複数の他紛失イベントデータのうちから、ゲームシステム１ｂのプレイヤによって指定されたものが、落とし物の設定に用いられるようにしてもよい。
【0129】
落とし物が設定された場合、ゲームシステム１ｂは、ゲーム中において落とし物の概要をプレイヤに提示するようにしてもよい。例えば、ゲーム中においてゲームフィールドのマップを表すマップ画像が表示される場合、ゲームシステム１ｂは、マップ上に落とし物が設定された位置を示すマークをマップ画像とともに表示するようにしてもよい。また、ゲームシステム１ｂは、設定された落とし物に関する情報（具体的には、落とし主、代表アイテム、および、種類数の情報）を表示するようにしてもよい。例えば、ゲームシステム１ｂは、ゲーム中に表示されるメニュー画像において、設定された落とし物のリストを表示し、リストにおいて選択された落とし物について上記の情報を表示するようにしてもよい。これによって、プレイヤは、設定された落とし物の内容を確認することができる。なお、上記の情報は、他紛失イベントデータに含まれる代表アイテム情報、種類数情報、および、落とし主情報によって特定することができる。
【0130】
ゲームシステム１ｂにおけるゲーム中において、プレイヤキャラクタによって落とし物が拾われることで、拾得イベントが発生する（ステップＳ７）。なお、ゲームシステム１ｂは、落とし物が設定される位置にプレイヤキャラクタが到達したことで、当該落とし物が拾われたと判定してもよいし、落とし物が設定される位置にプレイヤキャラクタが位置する状態で、プレイヤキャラクタが所定の動作（例えば、プレイヤキャラクタがアイテムを拾う動作）を行うことで、当該落とし物が拾われたと判定してもよい。
【0131】
拾得イベントが発生すると、ゲームシステム１ｂは、一定条件下で、拾得イベントデータをサーバ２０１へ送信する（ステップＳ８）。拾得イベントデータは、拾得イベントが発生したことを示すデータであり、拾得イベントに対応するイベント管理データ（他紛失イベントデータとも言える）を特定可能な任意の情報を示す。例えば、拾得イベントデータは、位置情報、代表アイテム情報、および、落とし主情報を含む。また、拾得イベントデータは、拾い主情報として、拾得イベントを発生させたプレイヤキャラクタを示す情報を含む。
【0132】
ここで、本実施形態においては、ステップＳ７で発生した拾得イベントが未発生の他紛失イベントデータ（すなわち、未発生のイベント管理データに基づく他紛失イベントデータ）に基づくものである場合、ゲームシステム１ｂは、拾得イベントデータをサーバ２０１へ送信する。一方、ステップＳ７で発生した拾得イベントが発生済の他紛失イベントデータ（すなわち、発生済のイベント管理データに基づく他紛失イベントデータ）に基づくものである場合、ゲームシステム１ｂは、拾得イベントデータをサーバ２０１へ送信しない。
【0133】
なお、発生した拾得イベントが、未発生の他紛失イベントデータに基づくものであるか、それとも、発生済の他紛失イベントデータに基づくものであるかは、他紛失イベントデータに含まれるイベント状況情報により判別することができる。ゲームシステム１ｂは、拾得イベントが発生した場合であって、当該拾得イベントに関連付けられる他紛失イベントデータのイベント状況情報が未発生を示す場合に、拾得イベントデータをサーバ２０１へ送信する。これによれば、拾得イベントが発生済であるイベント管理データについてサーバ２０１への通知が行われないので、ゲームシステム１ｂからサーバ２０１への通信量を低減することができる。
【0134】
また、拾得イベントが発生した場合、ゲームシステム１ｂは、拾得イベントに応じた報酬をプレイヤに付与する。具体的には、ゲームシステム１ｂは、発生した拾得イベントに関連する他紛失イベントデータに含まれる報酬情報が示す報酬をプレイヤに付与する（ステップＳ９）。なお、報酬の内容は任意である。本実施形態においては、報酬は、ゲーム上の報酬であり、より具体的には、ゲーム内において用いられるアイテムである（したがって、報酬はプレイヤキャラクタに付与されるとも言える）。このように、本実施形態においては、拾得イベントに応じた報酬は、ゲームシステム１ｂにおいてすでに受信されている他紛失イベントデータに基づいて決定される。そのため、ゲームシステム１ｂは、報酬を付与する際にサーバ２０１との通信を行わなくても報酬を付与することができる。なお、他の実施形態においては、報酬の内容は、報酬情報に代えて、代表アイテム情報および／または種類数情報に基づいて決定されてもよいし、他紛失イベントデータに基づかずに（例えばランダムに）決定されてもよい。例えば、ゲームシステム１ｂは、発生した拾得イベントが、未発生の他紛失イベントデータに基づくものであるか、それとも、発生済の他紛失イベントデータに基づくものであるかによって報酬の内容を決定してもよい。
【0135】
なお、本実施形態においては、ゲームシステム１ｂは、発生した拾得イベントが、他のプレイヤによってすでに行われたものであるか否かを、当該ゲームシステム１ｂのプレイヤに通知しない。これによって、プレイヤが拾得イベントを行う意欲が削がれることを防止することができる。
【0136】
一方、ゲームシステム１ｂから拾得イベントデータを受信した場合、サーバ２０１は、受信した拾得イベントデータに対応するイベント管理データを更新する（ステップＳ１０）。具体的には、サーバ２０１は、受信した拾得イベントデータに対応するイベント管理データについて、イベント状況情報が発生済を示す内容となるように更新する。また、サーバ２０１は、受信した拾得イベントデータに対応するイベント管理データについて、拾い主情報が、当該拾得イベントデータに含まれる拾い主情報が示す内容となるように、更新する。また、サーバ２０１は、受信した拾得イベントデータに対応するイベント管理データについて、取得イベントが発生した日時、または、当該取得イベントデータを受信した日時を記憶しておく。
【0137】
ここで、本実施形態においては、あるゲームシステムに対して他紛失イベントデータが送信されてから当該ゲームシステムにおいて拾得イベントが発生するまでの間に、他のゲームシステムに対して同じ他紛失イベントデータが送信されて当該他のゲームシステムにおいて拾得イベントが発生することも考えられる。このとき、イベント状況情報が発生済を示すイベント管理データについて、ゲームシステムから取得イベントデータが送信されてくる場合がある。この場合、サーバ２０１は、イベント管理データの更新を行わない。つまり、本実施形態においては、サーバ２０１は、１つのイベント管理データについて、最初に取得イベントデータを受信した場合にデータの更新を行い、その後は更新を行わない。これによって、サーバ２０１は、１つの紛失イベントに対して、最初に拾得イベントを発生させたプレイヤキャラクタ（すなわち、最初の拾い主）を、イベント管理データに含まれる拾い主情報によって管理することとなる。
【0138】
上記のように、本実施形態においては、イベント管理データには、拾得イベントを発生させたプレイヤに関する情報（すなわち、拾い主情報）が含まれる。そして、サーバ２０１は、最初に拾得イベントデータをサーバ２０１へ送信したゲームシステムのプレイヤ、すなわち最初にサーバ２０１が受信した拾得イベントデータを送信したゲームシステムのプレイヤに関する情報を、拾得イベントを発生させたプレイヤに関する情報として記憶する。したがって、本実施形態においては、サーバ２０１は、１つの紛失イベントに対する拾得イベントを複数のプレイヤに行わせることができるとともに、紛失イベントに対して最初に拾得イベントを行ったプレイヤに関する情報をサーバ２０１において記憶することができる。
【0139】
なお、上記「プレイヤに関する情報」とは、プレイヤを特定可能な任意の情報を含む意味である。上記「プレイヤに関する情報」とは、プレイヤキャラクタの名前に限らず、プレイヤ自身の名前やＩＤを含む意味である。
【0140】
また、サーバ２０１は、第１記憶領域に記憶されているイベント管理データのうち、受信した拾得イベントデータに対応するイベント管理データを、一定条件下で第２記録領域に記憶する（ステップＳ１１）。つまり、サーバ２０１は、拾得イベントが発生したことに応じて、拾得イベントが発生したイベント管理データを第２記憶領域に記憶する（図１３参照）。
【0141】
本実施形態においては、サーバ２０１は、取得イベントに応じてイベント管理データを第２記憶領域に記憶するか否かを、所定の確率に基づいてランダムに判定する。これによれば、イベント管理データを第２記憶領域に記憶する処理の頻度を抑制することができ、処理負荷を軽減することができる。また、本実施形態においては上記の判定はランダムに行われるので、第２記憶領域に記憶されるイベント管理データの内容に偏りを生じるおそれを低減することができる。なお、上記の判定は、どのような方法で行われてもよい。例えば、他の実施形態においては、サーバ２０１は、所定の条件を満たすイベント管理データを第２記憶領域に記憶するようにしてもよいし、受信された取得イベントデータに対応する全てのイベント管理データを第２記憶領域に記憶するようにしてもよい。
【0142】
一方、紛失イベントが発生したゲームシステム１ａにおいては、通知受信要求が所定のタイミングでサーバ２０１へ送信される（ステップＳ１２）。通知受信要求は、自機で発生した紛失イベントに関する状況（すなわち、当該紛失イベントに対応する拾得イベントが未発生であるか発生済であるか）に関するイベント状況通知を受信する旨の要求である。通知受信要求が送信される上記所定のタイミングは任意である。本実施形態においては、例えば、ゲームシステム１ａがサーバ２０１と通信を行うタイミング、または、ゲーム中においてプレイヤによる指示が行われたタイミングで、ゲームシステム１ａは通知受信要求をサーバ２０１へ送信する。
【0143】
サーバ２０１は、ゲームシステム１ａから通知受信要求を受信すると、イベント状況通知を生成して当該ゲームシステム１ａへ送信する（ステップＳ１３）。イベント状況通知は、通知受信要求を送信したゲームシステムにおいて発生した紛失イベントに関する状況を示す情報を含む。具体的には、イベント状況通知は、ゲームシステム１ａで発生した紛失イベントに対応する拾得イベントが新たに発生したか否かを示す情報を含む。例えば、サーバ２０１は、第１記憶領域において、ゲームシステム１ａに関するイベント管理データであって、発生済のイベント管理データが記憶されている場合、拾得イベントが新たに発生したことを示すイベント状況通知を送信する。また、この場合、イベント状況通知は、拾得イベントについての拾い主情報を含む。一方、第１記憶領域において、ゲームシステム１ａに関するイベント管理データであって、発生済のイベント管理データが記憶されていない場合、サーバ２０１は、拾得イベントが新たに発生していないことを示すイベント状況通知を送信する。
【0144】
上記のイベント状況通知を受信することによって、ゲームシステム１ａは、自機で発生した紛失イベントに対応する拾得イベントが新たに発生したか否か（つまり、落とし物が他のプレイヤキャラクタによって拾われたか否か）を確認することができる。紛失イベントに対応する拾得イベントが新たに発生した場合、ゲームシステム１ａは、当該紛失イベントによって消失されたアイテムを元に戻す（ステップＳ１４）。上記のように、ゲームシステム１ａは、紛失イベントによって消失されたアイテムを示すデータを記憶しているので、当該データに基づいて、消失されたアイテムをプレイヤキャラクタの所有するアイテムに戻すことができる。これによって、紛失イベントによって消失されたアイテムが回収されたこととなる。
【0145】
なお、上記ステップＳ１３において、サーバ２０１は、拾得イベントが発生済となったことを示すイベント状況通知をゲームシステム１ａへ送信した場合、当該拾得イベントに関するイベント管理データを第１記憶領域から削除する。つまり、サーバ２０１は、紛失イベントによって消失されたアイテムが回収されることに応じて、当該紛失イベントに関するイベント管理データを第１記憶領域から削除する（図１３参照）。このように、本実施形態においては、サーバ２０１は、ゲームシステム１ａが送信した紛失イベントデータに対応する拾得イベントが発生済となったことを通知する通信を当該ゲームシステム１ａへ行った後、当該紛失イベントデータに関するイベント管理データを第１記憶領域から削除する。これによって、第１記憶領域に記憶されるイベント管理データのデータ量を抑制することができる。
【0146】
また、サーバ２０１は、第１記憶領域に記憶されているイベント管理データについて、予め定められた期間が経過すると削除する。具体的には、サーバ２０１は、紛失イベントが発生してから、予め定められた第１保存期間が経過するまでに、当該紛失イベントに対応する拾得イベントが行われない場合、当該紛失イベントに関するイベント管理データを第１記憶領域から削除する（図１３参照）。なお、サーバ２０１は、紛失イベントが発生した時期をイベント管理データに含まれる日時情報によって知ることができ、また、拾得イベントが発生したことをゲームシステム１ｂからの拾得イベントデータによって知ることができる。また、サーバ２０１は、イベント管理データについて拾得イベントが発生してから、予め定められた第２保存期間が経過するまでに、当該拾得イベントに対応するアイテムの回収が行われない場合（すなわち、当該イベント管理データについてゲームシステム１ａからの通知受信要求を受信しない場合）、当該イベント管理データを第１記憶領域から削除する（図１３参照）。上記のように、サーバ２０１は、イベント管理データについて一定期間内に拾得イベントまたはアイテムの回収が行われない場合、当該イベント管理データを第１記憶領域から削除する。これによって、第１記憶領域に記憶されるイベント管理データのデータ量を低減することができる。
【0147】
なお、本実施形態においては、上記第２保存期間は、上記第１保存期間よりも長く設定される。上述のように、本実施形態においては、あるゲームシステムにおいて発生した１つの紛失イベントに関する他紛失イベントデータが複数の他のゲームシステムへ送信され得るので、当該紛失イベントに対応する拾得イベントが発生する機会が多く設けられているということができる。そのため、本実施形態においては、第１保存期間を比較的短くすることが可能である。また、第２保存期間を長くすることで、拾得イベントが発生したことによってアイテムを回収できる状態となったにも関わらず、通知受信要求が第２保存期間内に行われていないことによってアイテムが回収できない結果となる可能性を低減することができる。
【0148】
また、サーバ２０１は、第２記憶領域に記憶されているイベント管理データについて、イベント管理データの数が、予め定められた制限数（ここでは、１００００）を超える場合、当該制限数を超える分のイベント管理データを削除する（図１３参照）。具体的には、上記の場合、サーバ２０１は、第２記憶領域に記憶されているイベント管理データのうち、古いものから順に、上記制限数を超える分のイベント管理データを削除する。これによれば、サーバ２０１は、一定量のイベント管理データを確保することができるとともに、第２記憶領域に記憶されるイベント管理データのデータ量を抑制することができる。
【0149】
なお、本実施形態においては、上記のようにイベント管理データを第１記憶領域と第２記憶領域とに分けて管理することによって、イベント管理データの選出や削除を容易に行うことができる。例えば、複数の上記他紛失イベントデータを含む送信データをサーバ２０１が生成する際には、未発生のイベント管理データについては、第２記憶領域を対象とせずに第１記憶領域から選出すればよく、発生済のイベント管理データについては、第１記憶領域を対象とせずに第２記憶領域から選出すればよい。また例えば、上記の第１または第２保存期間が経過したために削除すべきイベント管理データについては、第２記憶領域を対象とせずに第１記憶領域から、該当するイベント管理データを特定すればよい。なお、他の実施形態においては、サーバ２０１は、イベント管理データを第１記憶領域と第２記憶領域とに分けることなく管理するようにしてもよい。
【0150】
【0151】
［４－１．情報処理に用いられるデータ］
図１５は、ゲームシステムにおける情報処理に用いられる各種データの一例を示す図である。図１５に示す各種データは、ゲームシステム１の本体装置２がアクセス可能な記憶媒体（例えば、フラッシュメモリ８４、ＤＲＡＭ８５、および／または、スロット２３に装着されたメモリカード等）に記憶される。
図１５は、ゲームシステムにおける情報処理に用いられる各種データの一例を示す図である。図１５に示す各種データは、ゲームシステム１の本体装置２がアクセス可能な記憶媒体（例えば、フラッシュメモリ８４、ＤＲＡＭ８５、および／または、スロット２３に装着されたメモリカード等）に記憶される。
【0152】
図１５に示すように、ゲームシステム１は、端末側ゲームプログラムを記憶する。端末側ゲームプログラムは、上記ゲームを実行するための端末側のゲームプログラムであり、ゲームシステム１で実行されるゲーム処理（図１６および図１７に示す各処理）を実行するためのプログラムである。すなわち、ゲームシステム１のプロセッサ８１が上記端末側ゲームプログラムを実行することによって、後述する各処理（図１６および図１７参照）がゲームシステム１において実行される。
【0153】
ゲームシステム１は、少なくとも、キャラクタデータ、他紛失イベントデータ、および、落とし物データを記憶する。なお、これらのデータの他、ゲームシステム１は、ゲームの実行に用いられる各種データを記憶する。
【0154】
キャラクタデータは、ゲームシステム１におけるゲームのプレイヤキャラクタに関する各種情報を示すデータである。キャラクタデータは、所有アイテムデータ、および、消失アイテムデータを含む。所有アイテムデータは、プレイヤキャラクタが所有しているアイテムを示す。消失アイテムデータは、上記紛失イベントによってプレイヤキャラクタの所有アイテムから消失された状態となったアイテムを示す。また、キャラクタデータは、プレイヤキャラクタの名前を示す情報を含む。
【0155】
他紛失イベントデータは、上述のように、サーバ２０１から受信されるデータである。上述のように、ゲームシステム１はサーバ２０１から複数の他紛失イベントデータを受信し、各他紛失イベントデータを記憶する。落とし物データは、他紛失イベントデータに基づいて設定される落とし物の位置を示すデータである。
【0156】
図１３に示したように、サーバ２０１は、イベント管理データを記憶する。さらに、図示しないが、サーバ２０１は、サーバ側ゲームプログラムを記憶する。サーバ側ゲームプログラムは、上記ゲームを実行するためのサーバ側のゲームプログラムであり、サーバ２０１で実行されるサーバ処理（図１８に示す処理）を実行するためのプログラムである。すなわち、サーバ２０１の処理部２１１が上記サーバ側ゲームプログラムを実行することによって、後述する各処理（図１８参照）がサーバ２０１において実行される。
【0157】
なお、サーバ２０１は、図１３に示すデータの他に、サーバ処理の実行に用いるために、ゲームシステム１に記憶される各種データ（図１５参照）の一部または全部を記憶していてもよい。また、情報処理システムにおいて用いられる各データは、サーバ２０１およびゲームシステム１のいずれに記憶されていてもよい。なお、サーバ２０１とゲームシステム１とにおいて同じデータが記憶される場合には、適宜のタイミングで、サーバ２０１に記憶されるデータとゲームシステム１に記憶されるデータとの同期がとられる。
【0158】
［４－２．ゲームシステム１における処理］
図１６および図１７は、ゲームシステム１によって実行されるゲーム処理である端末処理の流れの一例を示すフローチャートである。なお、図１６および図１７に示す端末処理は、例えば、上記端末側ゲームプログラムの実行中において、ゲームを開始する指示がプレイヤによって行われたことに応じて開始される。
図１６および図１７は、ゲームシステム１によって実行されるゲーム処理である端末処理の流れの一例を示すフローチャートである。なお、図１６および図１７に示す端末処理は、例えば、上記端末側ゲームプログラムの実行中において、ゲームを開始する指示がプレイヤによって行われたことに応じて開始される。
【0159】
なお、本実施形態では、本体装置２のプロセッサ８１が、ゲームシステム１に記憶されている上記端末側ゲームプログラムを実行することによって、図１６および図１７に示す各ステップの処理を実行するものとして説明する。また、サーバ２０１のプロセッサ（すなわち、処理部２１１）が、サーバ２０１に記憶されている上記サーバ側ゲームプログラムを実行することによって、図１８に示す各ステップの処理を実行するものとして説明する。ただし、他の実施形態においては、上記各ステップの処理のうちの一部の処理を、プロセッサとは別のプロセッサ（例えば、専用回路等）が実行するようにしてもよい。また、ゲームシステム１において実行される各ステップの処理の一部は、サーバ２０１において実行されてもよいし、サーバ２０１において実行される各ステップの処理の一部は、ゲームシステム１において実行されてもよい。また、図１６～図１８に示す各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。
【0160】
また、ゲームシステム１またはサーバ２０１のプロセッサは、図１６～図１８に示す各ステップの処理を、メモリ（例えば、ＤＲＡＭ８５）を用いて実行する。すなわち、プロセッサは、各処理ステップによって得られる情報（換言すれば、データ）をメモリに記憶し、それ以降の処理ステップにおいて当該情報を用いる場合には、メモリから当該情報を読み出して利用する。
【0161】
図１６に示すステップＳ２１において、プロセッサ８１は、ゲームを進行させるための処理を実行する。例えば、プロセッサ８１は、プレイヤによる入力に応じてプレイヤキャラクタの動作を制御したり、ゲームプログラムにおいて定められたアルゴリズムに従って、プレイヤキャラクタ以外のキャラクタの動作を制御したり、ゲーム画像を生成してディスプレイ１２に表示したりする。なお、本実施形態においては、ゲームシステム１はディスプレイ１２に画像を表示するが、ディスプレイ１２とは異なる他の表示装置（例えば、本体装置２に接続されるモニタ）に画像を表示してもよい。また、上記ステップＳ２１の処理は、所定時間（例えば、１フレーム時間）に１回の割合で繰り返し実行される。ステップＳ２１の次に、ステップＳ２２の処理が実行される。
【0162】
ステップＳ２２において、プロセッサ８１は、ゲームにおいて紛失イベントが発生したか否かを判定する。すなわち、プロセッサ８１は、上記ステップＳ２１の処理の結果、上述のイベント発生条件が満たされたか否かを判定する。ステップＳ２２の判定結果が肯定である場合、ステップＳ２３の処理が実行される。一方、ステップＳ２２の判定結果が否定である場合、ステップＳ２３およびＳ２４の処理がスキップされて、後述のステップＳ２５の処理が実行される。
【0163】
ステップＳ２３において、プロセッサ８１は、プレイヤキャラクタが所有するアイテムを消失させる（図１１のステップＳ１参照）。具体的には、プロセッサ８１は、プレイヤキャラクタが所有するアイテムのうちから、消失させるアイテムを選択し、選択されたアイテムを含まない内容となるように、メモリに記憶されている所有アイテムデータを更新する。これによって、プレイヤキャラクタはアイテムを紛失したこととなる。また、プロセッサ８１は、選択されたアイテムを示す消失アイテムデータをメモリに新たに記憶する。ステップＳ２３の次に、ステップＳ２４の処理が実行される。
【0164】
ステップＳ２４において、プロセッサ８１は、紛失イベントが発生してからの時間のカウントを開始する。ステップＳ２４の次に、ステップＳ２５の処理が実行される。
【0165】
ステップＳ２５において、プロセッサ８１は、上述の自紛失イベントデータを送信するか否かを判定する。具体的には、プロセッサ８１は、上記ステップＳ２４でカウントを開始した時間が上述の待機時間を超えており、かつ、ゲームシステム１がサーバ２０１と通信可能であるか否かを判定する。ステップＳ２５の判定結果が肯定である場合、ステップＳ２６の処理が実行される。一方、ステップＳ２５の判定結果が否定である場合、ステップＳ２６の処理がスキップされて、後述のステップＳ２７の処理が実行される。
【0166】
ステップＳ２６において、プロセッサ８１は、自紛失イベントデータをサーバ２０１へ送信する（図１１のステップＳ２参照）。具体的には、プロセッサ８１は、上記ステップＳ２２で発生したと判定された紛失イベントについての自紛失イベントデータを生成し、生成された自紛失イベントデータを、ネットワーク通信部８２を用いてサーバ２０１へ送信する。ステップＳ２６の次に、ステップＳ２７の処理が実行される。
【0167】
ステップＳ２７において、プロセッサ８１は、上述のイベント受信要求を送信するか否かを判定する。本実施形態においては、プロセッサ８１は、イベント受信要求を送信する旨の指示がプレイヤによって行われたか否かを判定する。ステップＳ２７の判定結果が肯定である場合、ステップＳ２８の処理が実行される。一方、ステップＳ２７の判定結果が否定である場合、ステップＳ２８～Ｓ３１の処理がスキップされて、後述のステップＳ３２（図１７参照）の処理が実行される。
【0168】
ステップＳ２８において、プロセッサ８１は、イベント受信要求をサーバ２０１へ送信する（図１１のステップＳ４参照）。具体的には、プロセッサ８１は、イベント受信要求のデータを生成し、生成されたデータを、ネットワーク通信部８２を用いてサーバ２０１へ送信する。ステップＳ２８の次に、ステップＳ２９の処理が実行される。
【0169】
ステップＳ２９において、プロセッサ８１は、サーバ２０１から送信されてくる他紛失イベントデータを受信する。ここで、上記ステップＳ２８の処理によって送信されたイベント受信要求をゲームシステム１から受信したサーバ２０１は、複数の他紛失イベントデータを含む送信データを当該ゲームシステム１へ送信する。プロセッサ８１は、ネットワーク通信部８２を用いて、この送信データを受信する。受信された送信データに含まれる複数の他紛失イベントデータは、それぞれメモリに記憶される。ステップＳ２９の次に、ステップＳ３０の処理が実行される。
【0170】
ステップＳ３０において、プロセッサ８１は、ステップＳ２９で受信された複数の他紛失イベントデータのうちから、ゲームにおける落とし物の設定に用いられる他紛失イベントデータを選出する。すなわち、プロセッサ８１は、メモリに記憶されている複数の他紛失イベントデータのうちから、上記“［３．情報処理システムにおける処理の概要］”で述べた方法に従って、上述した配置数の他紛失イベントデータを選出する。ステップＳ３０の次に、ステップＳ３１の処理が実行される。
【0171】
ステップＳ３１において、プロセッサ８１は、ステップＳ３０で選出された他紛失イベントデータに基づいて、ゲームフィールドに落とし物を設定する（図１１のステップＳ６参照）。なお、落とし物を設定するための具体的な処理は、落とし物を表すオブジェクトをゲームフィールド上に配置する処理であってもよいし、（落とし物を表すオブジェクトをゲームフィールドに配置することなく）落とし物の位置をゲームフィールドのマップに設定するだけの処理であってもよい。ステップＳ３１の次に、ステップＳ３２の処理が実行される。
【0172】
図１７に示すステップＳ３２において、プロセッサ８１は、ゲームにおいて拾得イベントが発生したか否かを判定する。すなわち、プロセッサ８１は、ステップＳ３１で設定された落とし物がプレイヤキャラクタによって拾われたか否かを判定する。ステップＳ３２の判定結果が肯定である場合、ステップＳ３３の処理が実行される。一方、ステップＳ３２の判定結果が否定である場合、ステップＳ３３～Ｓ３５の処理がスキップされて、後述のステップＳ３６の処理が実行される。
【0173】
ステップＳ３３において、プロセッサ８１は、ステップＳ３２で発生したと判定された拾得イベントが、未発生の他紛失イベントデータに基づくものであるか否かを判定する。プロセッサ８１は、上記拾得イベントに関する他紛失イベントデータに含まれるイベント状況情報に基づいて上記の判定を行う。ステップＳ３３の判定結果が肯定である場合、ステップＳ３４の処理が実行される。一方、ステップＳ３３の判定結果が否定である場合、ステップＳ３４の処理がスキップされて、後述のステップＳ３５の処理が実行される。
【0174】
ステップＳ３４において、プロセッサ８１は、拾得イベントデータをサーバ２０１へ送信する（図１１のステップＳ８参照）。具体的には、プロセッサ８１は、上記ステップＳ３２で発生したと判定された拾得イベントについての拾得イベントデータを生成し、生成された拾得イベントデータを、ネットワーク通信部８２を用いてサーバ２０１へ送信する。ステップＳ３４の次に、ステップＳ３５の処理が実行される。
【0175】
ステップＳ３５において、プロセッサ８１は、拾得イベントに応じた報酬をプレイヤに付与する（図１１のステップＳ９参照）。すなわち、プロセッサ８１は、報酬としてアイテムをプレイヤキャラクタに付与する。このとき、プロセッサ８１は、付与されたアイテムを含むように、メモリに記憶されている所有アイテムデータの内容を更新する。ステップＳ３５の次に、ステップＳ３６の処理が実行される。
【0176】
ステップＳ３６において、プロセッサ８１は、上述の通知受信要求を送信するか否かを判定する。本実施形態においては、プロセッサ８１は、ゲームシステム１がサーバ２０１と通信を行うタイミングとなった場合、または、通知受信要求を送信する旨の指示がプレイヤによって行われた場合、通知受信要求を送信すると判定する。一方、ゲームシステム１がサーバ２０１と通信を行うタイミングでなく、かつ、通知受信要求を送信する旨の指示がプレイヤによって行われていない場合、プロセッサ８１は、通知受信要求を送信しないと判定する。ステップＳ３６の判定結果が肯定である場合、ステップＳ３７の処理が実行される。一方、ステップＳ３６の判定結果が否定である場合、ステップＳ３７～Ｓ４０の処理がスキップされて、後述のステップＳ４１の処理が実行される。
【0177】
ステップＳ３７において、プロセッサ８１は、通知受信要求をサーバ２０１へ送信する（図１１のステップＳ１２参照）。具体的には、プロセッサ８１は、通知受信要求のデータを生成し、生成されたデータを、ネットワーク通信部８２を用いてサーバ２０１へ送信する。ステップＳ３７の次に、ステップＳ３８の処理が実行される。
【0178】
ステップＳ３８において、プロセッサ８１は、サーバ２０１から送信されてくるイベント状況通知を受信する。ここで、上記ステップＳ３７の処理によって送信された通知受信要求をゲームシステム１から受信したサーバ２０１は、当該ゲームシステム１に関するイベント状況通知を当該ゲームシステム１へ送信する。プロセッサ８１は、ネットワーク通信部８２を用いて、このイベント状況通知を受信する。ステップＳ３８の次に、ステップＳ３９の処理が実行される。
【0179】
ステップＳ３９において、プロセッサ８１は、ステップＳ３８で受信されたイベント状況通知に基づいて、ゲームシステム１において発生した紛失イベントに対応する拾得イベントが新たに発生済となったか否かを判定する。ステップＳ３９の判定結果が肯定である場合、ステップＳ４０の処理が実行される。一方、ステップＳ３９の判定結果が否定である場合、ステップＳ４０の処理がスキップされて、ステップＳ４１の処理が実行される。
【0180】
ステップＳ４０において、プロセッサ８１は、拾得イベントが発生した紛失イベントによって消失されたアイテムを元に戻す（図１１のステップＳ１４参照）。すなわち、プロセッサ８１は、当該消失されたアイテムを、プレイヤキャラクタが所有するアイテムに戻す。具体的には、プロセッサ８１は、メモリに記憶されている、当該紛失イベントに対応する消失アイテムデータが示すアイテムを含むように、メモリに記憶されている所有アイテムデータの内容を更新する。これによって、紛失イベントによって消失されたアイテムが回収されたこととなる。ステップＳ４０の次に、ステップＳ４１の処理が実行される。
【0181】
ステップＳ４１において、プロセッサ８１は、ゲームを終了するか否かを判定する。例えば、プロセッサ８１は、ゲームを終了する指示がユーザによって行われたか否かを判定する。ステップＳ４１の判定結果が否定である場合、上記ステップＳ２１の処理が再度実行される。以降、ステップＳ４１においてゲームを終了すると判定されるまで、ステップＳ２１～Ｓ４１の一連の処理が繰り返し実行される。一方、ステップＳ４１の判定結果が肯定である場合、プロセッサ８１は、図１６および図１７に示す端末処理を終了する。
【0182】
上記の端末処理のように、本実施形態においては、ゲームシステム１は、紛失イベントに関する処理（ステップＳ２２～Ｓ２６およびＳ３６～Ｓ４０）と、拾得イベントに関する処理（ステップＳ２７～Ｓ３５）との両方を実行する。つまり、本実施形態においては、１つのゲーム中において、紛失イベントが発生することがあるとともに、他のゲームにおいて発生した紛失イベントに対応する拾得イベントを発生させることも可能である。これによれば、プレイヤは、自身の紛失イベントについて他のプレイヤに拾得イベントを行ってもらうことで助けてもらうことが可能であるとともに、他のプレイヤの紛失イベントについて拾得イベントを行うことで他のプレイヤを助けることができる。これによって、各プレイヤは、互いに協力し合いながらゲームを進行させることができる。
【0183】
なお、他の実施形態においては、一方のゲームにおいては紛失イベントのみが発生し、他方のゲームにおいては拾得イベントのみが発生するようにしてもよい。すなわち、上記一方のゲームを実行するゲームシステム１は、拾得イベントに関する処理を実行せずに、紛失イベントに関する処理を実行し、上記他方のゲームを実行するゲームシステム１は、紛失イベントに関する処理を実行せずに、拾得イベントに関する処理を実行してもよい。
【0184】
［４－３．サーバ２０１における処理］
図１８は、サーバによって実行されるサーバ処理の流れの一例を示すフローチャートである。なお、図１８に示す一連の処理は、サーバ２０１の動作中において継続的に実行される。
図１８は、サーバによって実行されるサーバ処理の流れの一例を示すフローチャートである。なお、図１８に示す一連の処理は、サーバ２０１の動作中において継続的に実行される。
【0185】
ステップＳ５１において、処理部２１１は、通信部２１３を用いて、ゲームシステム１から紛失イベントデータを受信したか否かを判定する。ステップＳ５１の判定結果が肯定である場合、ステップＳ５２の処理が実行される。一方、ステップＳ５１の判定結果が否定である場合、ステップＳ５２の処理がスキップされて、後述のステップＳ５３の処理が実行される。
【0186】
ステップＳ５２において、処理部２１１は、受信された紛失イベントデータに基づいてイベント管理データを生成し、記憶部２１２の第１記憶領域に記憶する（図１１に示すステップＳ３参照）。ステップＳ５２の次に、ステップＳ５３の処理が実行される。
【0187】
ステップＳ５３において、処理部２１１は、通信部２１３を用いて、ゲームシステム１からイベント受信要求を受信したか否かを判定する。ステップＳ５３の判定結果が肯定である場合、ステップＳ５４の処理が実行される。一方、ステップＳ５３の判定結果が否定である場合、ステップＳ５４の処理がスキップされて、後述のステップＳ５５の処理が実行される。
【0188】
ステップＳ５４において、処理部２１１は、複数の他紛失イベントデータを含む送信データを生成し、上記イベント受信要求を送信したゲームシステム１へ送信する（図１１に示すステップＳ５参照）。すなわち、処理部２１１は、上記“［３．情報処理システムにおける処理の概要］”で述べた方法に従って、第１記憶領域に記憶されているイベント管理データに基づいて複数の他紛失イベントデータを含む送信データを生成する。そして、処理部２１１は、生成された送信データを、通信部２１３を用いて上記ゲームシステム１へ送信する。ステップＳ５４の次に、ステップＳ５５の処理が実行される。
【0189】
ステップＳ５５において、処理部２１１は、通信部２１３を用いて、ゲームシステム１から拾得イベントデータを受信したか否かを判定する。ステップＳ５５の判定結果が肯定である場合、ステップＳ５６の処理が実行される。一方、ステップＳ５５の判定結果が否定である場合、ステップＳ５６およびＳ５７の処理がスキップされて、後述のステップＳ５８の処理が実行される。
【0190】
ステップＳ５６において、処理部２１１は、第１記憶領域に記憶されているイベント管理データを更新する（図１１に示すステップＳ１０参照）。具体的には、処理部２１１は、ステップＳ５５で受信されたと判定された拾得イベントデータに対応するイベント管理データを、イベント状況情報が発生済を示す内容となるように更新する。ステップＳ５６の次に、ステップＳ５７の処理が実行される。
【0191】
ステップＳ５７において、処理部２１１は、ステップＳ５６で更新されたイベント管理データを一定条件下で第２記憶領域に記憶する。すなわち、処理部２１１は、上記“［３．情報処理システムにおける処理の概要］”で述べた方法に従って、記憶するか否かを判定し、記憶すると判定された場合、上記イベント管理データを第２記憶領域に記憶する。また、この場合において、第２記憶領域に記憶されるイベント管理データの数が上記制限数を超える場合には、処理部２１１は、古いものから順に、当該制限数を超える分のイベント管理データを第２記憶領域から削除する。なお、上記の判定において、記憶しないと判定された場合、処理部２１１は第２記憶領域へのイベント管理データの記憶を行わない。ステップＳ５７の次に、ステップＳ５８の処理が実行される。
【0192】
ステップＳ５８において、処理部２１１は、通信部２１３を用いて、ゲームシステム１から通知受信要求を受信したか否かを判定する。ステップＳ５８の判定結果が肯定である場合、ステップＳ５９の処理が実行される。一方、ステップＳ５８の判定結果が否定である場合、ステップＳ５９およびＳ６０の処理がスキップされて、後述のステップＳ６１の処理が実行される。
【0193】
ステップＳ５９において、処理部２１１は、イベント状況通知を生成し、通信部２１３を用いて、上記通知受信要求を送信したゲームシステム１へ当該イベント状況通知を送信する（図１１に示すステップＳ１３参照）。ステップＳ５９の次に、ステップＳ６０の処理が実行される。
【0194】
ステップＳ６０において、処理部２１１は、ステップＳ５９の処理において生成されたイベント状況通知に関するイベント管理データであって、拾得イベントが発生済であることを示すイベント管理データを第１記憶領域から削除する。ステップＳ６０の次に、ステップＳ６１の処理が実行される。
【0195】
ステップＳ６１において、処理部２１１は、第１記憶領域に記憶されているイベント管理データのうちに、紛失イベントが発生してからの時間が上記第１保存期間を経過したイベント管理データがあるか否かを判定する。ステップＳ６１の判定結果が肯定である場合、ステップＳ６２の処理が実行される。一方、ステップＳ６１の判定結果が否定である場合、ステップＳ６２の処理がスキップされて、後述のステップＳ６３の処理が実行される。
【0196】
ステップＳ６２において、処理部２１１は、紛失イベントが発生してからの時間が上記第１保存期間を経過したイベント管理データを第１記憶領域から削除する。ステップＳ６２の次に、ステップＳ６３の処理が実行される。
【0197】
ステップＳ６３において、処理部２１１は、拾得イベントが発生してからの時間が上記第２保存期間を経過したイベント管理データがあるか否かを判定する。ステップＳ６３の判定結果が肯定である場合、ステップＳ６４の処理が実行される。一方、ステップＳ６３の判定結果が否定である場合、ステップＳ５１の処理が再度実行される。
【0198】
ステップＳ６４において、処理部２１１は、拾得イベントが発生してからの時間が上記第２保存期間を経過したイベント管理データを第１記憶領域から削除する。ステップＳ６４の次に、ステップＳ５１の処理が再度実行される。以降、サーバ２０１においては、上記ステップＳ５１～Ｓ６４の一連の処理が繰り返し実行される。
【0199】
［５．本実施形態の作用効果および変形例］
以上のように、上記実施形態においては、情報処理システムは、複数の情報処理装置（例えば、ゲームシステム１、より具体的には、本体装置２）と、サーバ２０１とを少なくとも含む構成である。この構成において、情報処理装置はそれぞれ、次の処理を実行する。
・プレイヤの操作入力に基づいて仮想空間内においてプレイヤキャラクタを制御するゲーム処理を実行する処理（ステップＳ２１）。
・ゲーム中において第１イベント（例えば、紛失イベント）が発生した場合、プレイヤキャラクタの所有物（例えば、アイテム）が失われる状態に設定し（ステップＳ２３）、当該第１イベントが発生した仮想空間内の位置に基づいて設定される位置情報と、プレイヤに関するプレイヤ情報（例えば、落とし主情報）とを少なくとも含む第１イベントデータ（例えば、自紛失イベントデータ）をサーバへ送信する（ステップＳ２６）処理。
・他の情報処理装置から送信された他のプレイヤの第１イベントデータに基づいた、位置情報とプレイヤ情報を少なくとも含む第２イベントデータ（例えば、他紛失イベントデータ）をサーバから受信する処理（ステップＳ２９）。
・第２イベントデータに含まれる位置情報に基づいて設定される仮想空間内の位置において、プレイヤの操作に基づいて第２イベント（例えば、拾得イベント）を発生させることが可能となるよう設定する処理（ステップＳ３１）。
・第２イベントが発生したことに基づいて、当該第２イベントが発生したことを示す第３イベントデータ（例えば、拾得イベントデータ）をサーバへ送信する処理（ステップＳ３４）。
また、上記構成において、サーバは、次の処理を実行する。
・情報処理装置から受信した第１イベントデータ毎に、位置情報と、プレイヤ情報と、第２イベントについて発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶する処理（ステップＳ５２）。
・いずれかの情報処理装置から第３イベントデータを受信した場合に、イベント管理データのイベント状況情報を発生済となるよう更新する処理（ステップＳ５６）。
・イベント状況情報が発生済を示す少なくともいずれかのイベント管理データを第２記憶領域にさらに記憶する処理（ステップＳ５７）。
・情報処理装置から第２イベントデータの受信要求があった場合に、少なくとも１つの第２イベントデータを情報処理装置へ送信する処理（ステップＳ５４）。ここで、上記少なくとも１つの第２イベントデータは、第１記憶領域に記憶された、イベント状況情報が未発生を示すイベント管理データに基づく第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、第２記憶領域に記憶されたイベント管理データに基づく第２イベントデータを含む（図１４）。
また、上記構成において、情報処理装置はさらに、次の処理を実行する。
・第１イベントデータを送信済の場合において、サーバと通信を行い（ステップＳ３７およびＳ３８）、当該第１イベントデータに関するイベント管理データにおいてイベント状況情報が発生済を示す場合、所有物の少なくとも一部について、失われる状態を元に戻す処理（ステップＳ４０）。
以上のように、上記実施形態においては、情報処理システムは、複数の情報処理装置（例えば、ゲームシステム１、より具体的には、本体装置２）と、サーバ２０１とを少なくとも含む構成である。この構成において、情報処理装置はそれぞれ、次の処理を実行する。
・プレイヤの操作入力に基づいて仮想空間内においてプレイヤキャラクタを制御するゲーム処理を実行する処理（ステップＳ２１）。
・ゲーム中において第１イベント（例えば、紛失イベント）が発生した場合、プレイヤキャラクタの所有物（例えば、アイテム）が失われる状態に設定し（ステップＳ２３）、当該第１イベントが発生した仮想空間内の位置に基づいて設定される位置情報と、プレイヤに関するプレイヤ情報（例えば、落とし主情報）とを少なくとも含む第１イベントデータ（例えば、自紛失イベントデータ）をサーバへ送信する（ステップＳ２６）処理。
・他の情報処理装置から送信された他のプレイヤの第１イベントデータに基づいた、位置情報とプレイヤ情報を少なくとも含む第２イベントデータ（例えば、他紛失イベントデータ）をサーバから受信する処理（ステップＳ２９）。
・第２イベントデータに含まれる位置情報に基づいて設定される仮想空間内の位置において、プレイヤの操作に基づいて第２イベント（例えば、拾得イベント）を発生させることが可能となるよう設定する処理（ステップＳ３１）。
・第２イベントが発生したことに基づいて、当該第２イベントが発生したことを示す第３イベントデータ（例えば、拾得イベントデータ）をサーバへ送信する処理（ステップＳ３４）。
また、上記構成において、サーバは、次の処理を実行する。
・情報処理装置から受信した第１イベントデータ毎に、位置情報と、プレイヤ情報と、第２イベントについて発生済か未発生かを示すイベント状況情報とを少なくとも含むイベント管理データを第１記憶領域に記憶する処理（ステップＳ５２）。
・いずれかの情報処理装置から第３イベントデータを受信した場合に、イベント管理データのイベント状況情報を発生済となるよう更新する処理（ステップＳ５６）。
・イベント状況情報が発生済を示す少なくともいずれかのイベント管理データを第２記憶領域にさらに記憶する処理（ステップＳ５７）。
・情報処理装置から第２イベントデータの受信要求があった場合に、少なくとも１つの第２イベントデータを情報処理装置へ送信する処理（ステップＳ５４）。ここで、上記少なくとも１つの第２イベントデータは、第１記憶領域に記憶された、イベント状況情報が未発生を示すイベント管理データに基づく第２イベントデータ、および／または、当該第２イベントデータが不足する場合に送信される、第２記憶領域に記憶されたイベント管理データに基づく第２イベントデータを含む（図１４）。
また、上記構成において、情報処理装置はさらに、次の処理を実行する。
・第１イベントデータを送信済の場合において、サーバと通信を行い（ステップＳ３７およびＳ３８）、当該第１イベントデータに関するイベント管理データにおいてイベント状況情報が発生済を示す場合、所有物の少なくとも一部について、失われる状態を元に戻す処理（ステップＳ４０）。
【0200】
上記の構成によれば、第２イベントが未発生であるイベント管理データに基づく第２イベントデータとともに、第２イベントが発生済であるイベント管理データに基づく第２イベントデータが情報処理装置へ送信され得る。前者の第２イベントデータが送信されることで、ある情報処理装置において発生した第１イベントに対応する第２イベントが他の情報処理装置において行われず、所有物が失われる状態を元に戻すことができないといった不都合が生じる可能性を低減することができる。また、後者の第２イベントデータが送信されることで、仮に第１イベントが発生する数が少なくても、第２イベントが情報処理装置において行われる機会を増やすことができるので、ゲーム間でのやり取りを行う機会をプレイヤに十分に与えることができる。このように、上記の構成によれば、第１イベントに対応する第２イベントが行われる機会を確保することができ、ゲーム間でのやり取りを行う機会をプレイヤに対して効果的に与えることができる。
【0201】
上記「プレイヤ情報」とは、プレイヤを識別可能な任意の情報でよい意味であり、例えば、プレイヤ自身の名前やＩＤであってもよいし、プレイヤが操作するプレイヤキャラクタの名前やＩＤであってもよい意味である。
【0202】
また、上記「所有物」とは、ゲームにおいてプレイヤキャラクタが所有する任意のものを指す意味であり、プレイヤキャラクタが所有するアイテムの他、プレイヤキャラクタが所有する、ゲーム内において利用可能なお金やポイントを含む意味である。
【0203】
上記第１イベントは、上記実施形態においては、プレイヤキャラクタが所有物を紛失するイベントである。また、上記第２イベントは、上記実施形態においては、情報処理装置が受信した第２イベントデータに含まれる位置情報が示す仮想空間内の位置において、当該情報処理装置に対応するプレイヤキャラクタが、当該第２イベントデータに関する他のプレイヤのプレイヤキャラクタが紛失した所有物を拾得する（すなわち、落とし物を拾得する）イベントである。ここで、第１イベントとは、所有物を紛失する任意のイベントでよい意味であり、所有物を紛失することに加えて、プレイヤキャラクタにその他のデメリットが生じる（例えば、プレイヤキャラクタがその場で動けなくなる）ようなイベントであってもよい。また、第２イベントとは、所有物が回収されることに加えて、第１イベントによって生じるデメリットの少なくとも一部を解消または軽減する（例えば、動けなくなったプレイヤキャラクタを救助する）ものであってもよい。
【0204】
また、上記実施形態においては、第１イベント（すなわち、紛失イベント）は、ゲーム中において、プレイヤキャラクタに設定された体力が失われたときに発生するものであった。なお、上記実施形態においては、第２イベントが発生済であるイベント管理データに基づく第２イベントデータが情報処理装置へ送信され得るので、第１イベントが発生しづらいゲームにおいても、第２イベントが情報処理装置において行われる機会を増やすことができる。なお、他の実施形態においては、第１イベントが発生する条件は任意である。例えば、他の実施形態においては、プレイヤキャラクタの所有物が敵キャラクタに盗まれたことであってもよいし、ゲームフィールドに設置された罠にプレイヤキャラクタがかかったことであってもよい。
【0205】
上記「当該第２イベントデータが不足する場合」とは、（第１記憶領域に記憶された、イベント状況情報が未発生を示すイベント管理データに基づく）第２イベントデータが、０である、または、ある数に満たないことを意味する。つまり、上記「当該第２イベントデータが不足する場合」とは、（ａ）当該第２イベントデータが０個である場合と、（ｂ）例えば、全体として所定数の第２イベントデータを送信する場合において、第１記憶領域に記憶された、イベント状況情報が未発生を示すイベント管理データに基づく第２イベントデータが当該所定数に満たない場合との両方を含む意味である。
【0206】
なお、上記の実施形態において、ある情報処理装置においてデータ（プログラムを含む意味である）を用いて処理が実行される場合、当該処理に必要なデータの一部が、当該ある情報処理装置とは異なる他の情報処理装置から送信されてもよい。このとき、当該ある情報処理装置は、他の情報処理装置から受信されたデータと、自身に記憶されているデータとを用いて上記処理を実行してもよい。
【0207】
なお、他の実施形態において、情報処理システムは、上記実施形態における構成の一部を備えていなくてもよいし、上記実施形態において実行される処理の一部を実行しなくてもよい。例えば、情報処理システムは、上記実施形態における一部の特定の効果を奏するためには、当該効果を奏するための構成を備え、当該効果を奏するための処理を実行すればよく、その他の構成を備えていなくてもよいし、その他の処理を実行しなくてもよい。
【産業上の利用可能性】
【0208】
上記実施形態は、ゲーム間でのやり取りを行う機会をプレイヤに対して効果的に与えること等を目的として、例えばゲームシステムやゲームプログラムとして利用することが可能である。
【符号の説明】
【0209】
１ ゲームシステム
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
２０１ サーバ
２１１ 処理部
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
２０１ サーバ
２１１ 処理部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】