(第1の実施形態)
図面を参照して、本発明の第1の実施形態に係る情報処理プログラムを実行する情報処理装置について説明する。本発明の情報処理プログラムは、任意のコンピュータシステムで実行されることによって適用することができるが、情報処理装置の一例として携帯型のゲーム装置10を用い、ゲーム装置10で実行される情報処理プログラムを用いて説明する。
[ゲーム装置の外部構成]
まず始めに、図1を参照して、ゲーム装置10の外部構成について説明する。なお、図1は、ゲーム装置10の外観の一例を示す平面図である。ゲーム装置10は、一例として携帯型のゲーム装置であり、折り畳み可能に構成されている。図1は、開いた状態(開状態)におけるゲーム装置10の一例を示す正面図である。
図1において、ゲーム装置10は、下側ハウジング11および上側ハウジング21を有する。下側ハウジング11と上側ハウジング21とは、開閉可能(折り畳み可能)に連結されている。図1の例では、下側ハウジング11および上側ハウジング21は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回動可能に連結されている。通常、ユーザは、開状態でゲーム装置10を使用する。そして、ユーザは、ゲーム装置10を使用しない場合には閉状態としてゲーム装置10を保管する。また、ゲーム装置10は、上記閉状態および開状態のみでなく、下側ハウジング11と上側ハウジング21とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング21を下側ハウジング11に対して任意の角度で静止させることができる。
下側ハウジング11には、下側LCD(Liquid Crystal Display:液晶表示装置)12、タッチパネル13、各操作ボタン14A〜14L(図1、図3A〜図3D)、アナログスティック15、LED16A〜16B、挿入口17、および、マイクロフォン用孔18が設けられる。以下、これらの詳細について説明する。
図1に示すように、下側LCD12は下側ハウジング11に収納される。下側LCD12は横長形状であり、長辺方向が下側ハウジング11の長辺方向に一致するように配置される。下側LCD12は、下側ハウジング11の中央に配置される。下側LCD12は、下側ハウジング11の内側面(主面)に設けられ、下側ハウジング11の内側面に設けられた開口部から下側LCD12の画面が露出する。そして、ゲーム装置10を使用しない場合には上記閉状態としておくことによって、下側LCD12の画面が汚れたり傷ついたりすることを防止することができる。なお、本実施例では表示装置としてLCDを用いているが、例えばEL(Electro Luminescence:電界発光)を利用した表示装置など、他の任意の表示装置を利用してもよい。また、下側LCD12として、任意の解像度の表示装置を利用することができる。
図1に示されるように、ゲーム装置10は、入力装置として、タッチパネル13を備えている。タッチパネル13は、下側LCD12の画面上を覆うように装着されている。なお、本実施例では、タッチパネル13は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル13は、抵抗膜方式に限らず、例えば静電容量方式等、任意の押圧式のタッチパネルを用いることができる。本実施例では、タッチパネル13として、下側LCD12の解像度と同解像度(検出精度)のものを利用する。ただし、必ずしもタッチパネル13の解像度と下側LCD12の解像度とが一致している必要はない。また、下側ハウジング11の上側面には挿入口17(図1に示す点線)が設けられている。挿入口17は、タッチパネル13に対する操作を行うために用いられるタッチペン28を収納することができる。なお、タッチパネル13に対する入力は通常タッチペン28を用いて行われるが、タッチペン28に限らずユーザの指でタッチパネル13に対する入力をすることも可能である。
各操作ボタン14A〜14Lは、所定の入力を行うための入力装置である。図1に示されるように、下側ハウジング11の内側面(主面)には、各操作ボタン14A〜14Lの内、十字ボタン14A(方向入力ボタン14A)、ボタン14B、ボタン14C、ボタン14D、ボタン14E、電源ボタン14F、セレクトボタン14J、HOMEボタン14K、およびスタートボタン14Lが設けられる。十字ボタン14Aは、十字の形状を有しており、上下左右の方向を指示するボタンを有している。ボタン14B、ボタン14C、ボタン14D、およびボタン14Eは、十字状に配置される。ボタン14A〜14E、セレクトボタン14J、HOMEボタン14K、およびスタートボタン14Lには、ゲーム装置10が実行するプログラムに応じた機能が適宜割り当てられる。例えば、十字ボタン14Aは選択操作等に用いられ、各操作ボタン14B〜14Eは例えば決定操作やキャンセル操作等に用いられる。また、電源ボタン14Fは、ゲーム装置10の電源をオン/オフするために用いられる。
アナログスティック15は、方向を指示するデバイスであり、下側ハウジング11の内側面の下側LCD12より左側領域の上部領域に設けられる。図1に示すように、十字ボタン14Aが下側LCD12より左側領域の下部領域に設けられ、アナログスティック15が十字ボタン14Aの上方に設けられる。また、アナログスティック15および十字ボタン14Aは、下側ハウジング11を把持した左手の親指で操作可能な位置に設計される。また、アナログスティック15を上部領域に設けたことにより、下側ハウジング11を把持する左手の親指が自然と位置するところにアナログスティック15が配され、十字ボタン14Aは、左手の親指を少し下にずらした位置に配される。アナログスティック15は、そのキートップが、下側ハウジング11の内側面に平行にスライドするように構成されている。アナログスティック15は、ゲーム装置10が実行するプログラムに応じて機能する。例えば、3次元仮想空間に所定のオブジェクトが登場するゲームがゲーム装置10によって実行される場合、アナログスティック15は、当該所定のオブジェクトを3次元仮想空間内で移動させるための入力装置として機能する。この場合において、所定のオブジェクトは、アナログスティック15のキートップがスライドした方向に移動される。なお、アナログスティック15として、上下左右および斜め方向の任意の方向に所定量だけ傾倒することでアナログ入力を可能としたものを用いてもよい。
十字状に配置される、ボタン14B、ボタン14C、ボタン14D、およびボタン14Eの4つのボタンは、下側ハウジング11を把持する右手の親指が自然と位置するところに配置される。また、これらの4つのボタンとアナログスティック15とは、下側LCD12を挟んで、左右対称に配置される。これにより、ゲームプログラムによっては、例えば、左利きの人が、これらの4つのボタンを使用して方向指示入力をすることも可能である。
なお、図1においては、操作ボタン14G〜14Iの図示を省略している。例えば、Lボタン14Gは、下側ハウジング11の上側面の左端部に設けられ、Rボタン14Hは、下側ハウジング11の上側面の右端部に設けられる。Lボタン14GおよびRボタン14Hは、ゲーム装置1に対して、例えば撮影指示操作(シャッター操作)を行うために用いられる。さらに、音量ボタン14Iは、下側ハウジング11の左側面に設けられる。音量ボタン14Iは、ゲーム装置10が備えるスピーカの音量を調整するために用いられる。
また、下側ハウジング11の内側面には、マイクロフォン用孔18が設けられる。マイクロフォン用孔18の下部には後述する音声入力装置としてのマイク(図2参照)が設けられ、当該マイクがゲーム装置10の外部の音を検出する。
また、下側ハウジング11の左側面には開閉可能なカバー部11Cが設けられる。このカバー部11Cの内側には、ゲーム装置10とデータ保存用外部メモリ46とを電気的に接続するためのコネクタ(図示せず)が設けられる。データ保存用外部メモリ46は、上記コネクタに着脱自在に装着される。データ保存用外部メモリ46は、例えば、ゲーム装置10によって撮像された画像のデータを記憶(保存)するために用いられる。なお、上記コネクタおよびそのカバー部11Cは、下側ハウジング11の右側面に設けられてもよい。
また、下側ハウジング11の上側面にはゲーム装置10とゲームプログラムを記録した外部メモリ45を挿入するための挿入口11Dが設けられ、その挿入口11Dの内部には、外部メモリ45と電気的に着脱自在に接続するためのコネクタ(図示せず)が設けられる。外部メモリ45がゲーム装置10に接続されることにより、所定のゲームプログラムが実行される。なお、上記コネクタおよび挿入口11Dは、下側ハウジング11の他の側面(例えば、右側面等)に設けられてもよい。
図1に示されるように、下側ハウジング11の下側面には、ゲーム装置10の電源のON/OFF状況をユーザに通知する第1LED16Aが設けられる。また、図示はしていないが、下側ハウジング11の右側面には、ゲーム装置10の無線通信の確立状況をユーザに通知する第2LED16Bが設けられる。ゲーム装置10は、他の機器との間で無線通信を行うことが可能であり、第2LED16Bは、他の機器との無線通信が確立している場合に点灯する。ゲーム装置10は、例えば、IEEE802.11b/gの規格に準拠した方式により、無線LANに接続する機能を有する。下側ハウジング11の右側面には、この無線通信の機能を有効/無効にする無線スイッチ19(図示せず)が設けられる。
なお、図示は省略するが、下側ハウジング11には、ゲーム装置10の電源となる充電式電池が収納され、下側ハウジング11の側面(例えば、上側面)に設けられた端子を介して当該電池を充電することができる。
上側ハウジング21には、上側LCD22、2つの外側撮像部23(外側左撮像部23aおよび外側右撮像部23b)、内側撮像部24、3D調整スイッチ25、および3Dインジケータ26が設けられる。以下、これらの詳細について説明する。
図1に示すように、上側LCD22は、上側ハウジング21に収納される。上側LCD22は、横長形状であり、長辺方向が上側ハウジング21の長辺方向に一致するように配置される。上側LCD22は、上側ハウジング21の中央に配置される。上側LCD22の画面の面積は、一例として下側LCD12の画面の面積よりも大きく設定される。具体的には、上側LCD22の画面は、下側LCD12の画面よりも横長に設定される。すなわち、上側LCD22の画面のアスペクト比における横幅の割合は、下側LCD12の画面のアスペクト比における横幅の割合よりも大きく設定される。
上側LCD22の画面は、上側ハウジング21の内側面(主面)21Bに設けられ、上側ハウジング21の内側面に設けられた開口部から上側LCD22の画面が露出する。また、上側ハウジング21の内側面は、図示しない透明なスクリーンカバー27によって覆われている。スクリーンカバー27は、上側LCD22の画面を保護するとともに、上側LCD22と上側ハウジング21の内側面と一体的にさせ、これにより統一感を持たせている。なお、本実施例では、上側LCD22が液晶表示装置であるとしたが、例えばELを利用した表示装置などが利用されてもよい。また、上側LCD22として、任意の解像度の表示装置を利用することができる。
上側LCD22は、レンチキュラー方式やパララックスバリア方式(視差バリア方式)を用いて立体視可能な画像を表示することが可能な表示装置である。すなわち、上側LCD22は、視差バリアを用いてユーザの左目に左目用画像を、そして、ユーザの右目に右目用画像をそれぞれ視認させることにより、ユーザにとって立体感のある立体画像(立体視可能な画像)を表示することができる。また、上側LCD22は、上記視差バリアを無効にすることが可能であり、視差バリアを無効にした場合は、画像を平面的に表示することができる(上述した立体視とは反対の意味で平面視の画像を表示することができる。すなわち、表示された同一の画像が右目にも左目にも見えるような表示モードである。)。このように、上側LCD22は、立体視可能な画像を表示する立体表示モードと、画像を平面的に表示する(平面視画像を表示する)平面表示モードとを切り替えることが可能な表示装置である。この表示モードの切り替えは、後述する3D調整スイッチ25によって行われる。
外側撮像部23は、上側ハウジング21の外側面(上側LCD22が設けられた主面と反対側の背面)21D(図示せず)に設けられた2つの撮像部(外側左撮像部23aおよび外側右撮像部23b)の総称である。外側左撮像部23aおよび外側右撮像部23bの撮像方向は、いずれも外側面21Dの外向きの法線方向である。また、外側左撮像部23aおよび外側右撮像部23bは、いずれも、上側LCD22の表示面(内側面)の法線方向と180度反対の方向に設計される。すなわち、外側左撮像部23aの撮像方向および外側右撮像部23bの撮像方向は、平行である。外側左撮像部23aと外側右撮像部23bとは、ゲーム装置10が実行するプログラムによって、ステレオカメラとして使用することが可能である。また、プログラムによっては、2つの外側撮像部(外側左撮像部23aおよび外側右撮像部23b)のいずれか一方を単独で用いて、外側撮像部23を非ステレオカメラとして使用することも可能である。また、プログラムによっては、2つの外側撮像部(外側左撮像部23aおよび外側右撮像部23b)で撮像した画像を合成してまたは補完的に使用することにより撮像範囲を広げた撮像を行うことも可能である。本実施例では、外側撮像部23は、外側左撮像部23aおよび外側右撮像部23bの2つの撮像部で構成される。外側左撮像部23aおよび外側右撮像部23bは、それぞれ所定の共通の解像度を有する撮像素子(例えば、CCDイメージセンサやCMOSイメージセンサ等)と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
なお、本実施例においては、外側左撮像部23aおよび外側右撮像部23bは、ハウジングに固定されており、撮像方向を変更することはできない。
内側撮像部24は、上側ハウジング21の内側面(主面)21Bに設けられ、当該内側面の内向きの法線方向を撮像方向とする撮像部である。内側撮像部24は、所定の解像度を有する撮像素子(例えば、CCDイメージセンサやCMOSイメージセンサ等)と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
図1に示すように、内側撮像部24は、上側ハウジング21を開いた状態において、上側ハウジング21の上部であって、上側LCD22の画面の上端よりも上方に配置され、上側ハウジング21の左右方向に関して中央の位置(上側ハウジング21(上側LCD22の画面)を左右に2等分する線の線上)に配置される。具体的には、図1に示されるように、内側撮像部24は、上側ハウジング21の内側面であって、外側左撮像部23aおよび外側右撮像部23bの中間の裏側の位置に配置される。このように、内側撮像部24は、外側撮像部23とは反対方向を撮像するので、ゲーム装置10を把持しているユーザの顔を正面から撮像することも可能である。
3D調整スイッチ25は、スライドスイッチであり、上述のように上側LCD22の表示モードを切り替えるために用いられるスイッチである。また、3D調整スイッチ25は、上側LCD22に表示された立体視可能な画像(立体画像)の立体感を調整するために用いられる。図1に示されるように、3D調整スイッチ25は、上側ハウジング21の内側面および右側面の端部に設けられ、ユーザが上側LCD22を正視した場合に、当該3D調整スイッチ25を視認できる位置に設けられる。3D調整スイッチ25は、所定方向(例えば、上下方向)の任意の位置にスライド可能なスライダを有しており、当該スライダの位置に応じて上側LCD22の表示モードが設定される。
例えば、3D調整スイッチ25のスライダが最下点位置に配置されている場合、上側LCD22が平面表示モードに設定され、上側LCD22の画面には平面画像が表示される。一方、上記最下点位置より上側にスライダが配置されている場合、上側LCD22は立体表示モードに設定される。この場合、上側LCD22の画面には立体視可能な画像が表示される。ここで、スライダが上記最下点位置より上側に配置されている場合、スライダの位置に応じて、立体画像の見え方が調整される。具体的には、スライダの位置に応じて、右目用画像および左目用画像における横方向の位置のずれ量が調整される。
3Dインジケータ26は、上側LCD22が立体表示モードか否かを示す。例えば、3Dインジケータ26は、LEDであり、上側LCD22の立体表示モードが有効の場合に点灯する。図1に示されるように、3Dインジケータ26は、上側ハウジング21の内側面に設けられ、上側LCD22の画面近傍に設けられる。このため、ユーザが上側LCD22の画面を正視した場合、ユーザは3Dインジケータ26を視認しやすい。従って、ユーザは、上側LCD22の画面を視認している状態でも、上側LCD22の表示モードを容易に認識することができる。
また、上側ハウジング21の内側面には、スピーカ孔21Eが設けられる。後述するスピーカ44からの音声がこのスピーカ孔21Eから出力される。
[ゲーム装置の内部構成]
次に、図2を参照して、ゲーム装置10の内部構成を説明する。なお、図2は、ゲーム装置10の内部構成の一例を示すブロック図である。
図2において、ゲーム装置10は、上述した各構成部に加えて、情報処理部31、メインメモリ32、外部メモリインターフェイス(外部メモリI/F)33、データ保存用外部メモリI/F34、データ保存用内部メモリ35、無線通信モジュール36、ローカル通信モジュール37、リアルタイムクロック(RTC)38、加速度センサ39、角速度センサ40、電源回路41、およびインターフェイス回路(I/F回路)42等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて下側ハウジング11(または上側ハウジング21でもよい)内に収納される。
情報処理部31は、所定のプログラムを実行するためのCPU(Central Processing Unit)311、画像処理を行うGPU(Graphics Processing Unit)312等を含む情報処理手段である。本実施例では、所定のプログラムがゲーム装置10内のメモリ(例えば外部メモリI/F33に接続された外部メモリ45やデータ保存用内部メモリ35)に記憶されている。情報処理部31のCPU311は、当該所定のプログラムを実行することによって、後述する情報処理などを実行する。なお、情報処理部31のCPU311によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。情報処理部31は、VRAM(Video RAM)313を含む。情報処理部31のGPU312は、情報処理部31のCPU311からの命令に応じて画像を生成し、VRAM313に描画する。そして、情報処理部31のGPU312は、VRAM313に描画された画像を上側LCD22および/または下側LCD12に出力し、上側LCD22および/または下側LCD12に当該画像が表示される。
情報処理部31には、メインメモリ32、外部メモリI/F33、データ保存用外部メモリI/F34、およびデータ保存用内部メモリ35が接続される。外部メモリI/F33は、外部メモリ45を着脱自在に接続するためのインターフェイスである。また、データ保存用外部メモリI/F34は、データ保存用外部メモリ46を着脱自在に接続するためのインターフェイスである。
メインメモリ32は、情報処理部31(CPU311)のワーク領域やバッファ領域として用いられる揮発性の記憶手段である。すなわち、メインメモリ32は、画像処理やゲーム処理で用いられる各種データを一時的に記憶したり、外部(外部メモリ45や他の機器等)から取得されるプログラムを一時的に記憶したりする。本実施例では、メインメモリ32として例えばPSRAM(Pseudo−SRAM)を用いる。
外部メモリ45は、情報処理部31によって実行されるプログラムを記憶するための不揮発性の記憶手段である。外部メモリ45は、例えば読み取り専用の半導体メモリで構成される。外部メモリ45が外部メモリI/F33に接続されると、情報処理部31は外部メモリ45に記憶されたプログラムを読み込むことができる。情報処理部31が読み込んだプログラムを実行することにより、所定の処理が行われる。データ保存用外部メモリ46は、不揮発性の読み書き可能なメモリ(例えばNAND型フラッシュメモリ)で構成され、所定のデータを格納するために用いられる。例えば、データ保存用外部メモリ46に外側撮像部23で撮像された画像や他の機器で撮像された画像が記憶される。データ保存用外部メモリ46がデータ保存用外部メモリI/F34に接続されると、情報処理部31はデータ保存用外部メモリ46に記憶された画像を読み込み、上側LCD22および/または下側LCD12に当該画像を表示することができる。
データ保存用内部メモリ35は、読み書き可能な不揮発性メモリ(例えばNAND型フラッシュメモリ)で構成され、所定のデータを格納するために用いられる。例えば、データ保存用内部メモリ35には、無線通信モジュール36を介した無線通信によってダウンロードされたデータやプログラムが格納される。
無線通信モジュール36は、例えばIEEE802.11b/gの規格に準拠した方式により、無線LANに接続する機能を有する。また、ローカル通信モジュール37は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール36およびローカル通信モジュール37は、情報処理部31に接続される。情報処理部31は、無線通信モジュール36を用いてインターネットを介して他の機器との間でデータを送受信したり、ローカル通信モジュール37を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。
ローカル通信モジュール37は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。ここで、ローカル通信モジュール37は、この無線通信で使用する電波は例えば無線局の免許が不要な程の微弱電波であり、例えばデータ伝送距離が10mの範囲内の近距離無線通信を行う。従って、情報処理部31は、他のゲーム装置10の通信可能範囲内(例えば、両機間の距離が10m以内)に位置するときに、ローカル通信モジュール37を用いて当該他のゲーム装置10とデータを送受信することができる。このデータの送受信は、ユーザの選択に応じて、所定周期毎に自動的に繰り返し行われる場合がある。すなわち、情報処理部31は、前述の近距離無線通信が可能な範囲内に存在する他のゲーム装置10を検出して、検出の結果見つかったゲーム装置10との間で自動的に通信を開始しデータを送受信する。そして、当該通信が完了した後で自動的に通信の切断を行う。本実施例では、このように自動的に通信を開始してから完了するまでの処理が所定周期毎に繰り返し行われる。この通信を以下「すれ違い通信」と記載し、すれ違い通信のための処理を以下「すれ違い通信処理」と記載する。
すれ違い通信処理は、通信を行う複数のゲーム装置10が電源オンされているときに常に実行される。すなわち、複数のゲーム装置10がスリープモードに設定されているときだけでなくアプリケーションが実行されているときにも行われる。なお、スリープモードとは、省電力モードのことであり、ゲーム装置10における一部の機能(例えば、情報処理部31の一部の機能、ディスプレイの一部の機能等)が停止している状態である。例えば、CPU311が停止することでアプリケーションの実行をしない状態もスリープモードに該当する。
情報処理部31には、加速度センサ39が接続される。加速度センサ39は、3軸(本実施例では、xyz軸)方向に沿った直線方向の加速度(直線加速度)の大きさを検出する。加速度センサ39は、例えば下側ハウジング11の内部に設けられる。加速度センサ39は、図1に示すように、下側ハウジング11の長辺方向をx軸、下側ハウジング11の短辺方向をy軸、下側ハウジング11の内側面(主面)に対して垂直な方向をz軸として、ゲーム装置10の各軸方向へ生じる直線加速度の大きさをそれぞれ検出する。なお、加速度センサ39は、例えば静電容量式の加速度センサとするが、他の方式の加速度センサを用いるようにしてもよい。また、加速度センサ39は1軸または2軸方向を検出する加速度センサであってもよい。情報処理部31は、加速度センサ39が検出した加速度を示すデータ(加速度データ)を受信して、ゲーム装置10の姿勢や動きを算出する。
情報処理部31には、角速度センサ40が接続される。角速度センサ40は、ゲーム装置10の3軸(本実施例では、xyz軸)周りに生じる角速度をそれぞれ検出し、検出した角速度を示すデータ(角速度データ)を情報処理部31へ出力する。角速度センサ40は、例えば下側ハウジング11の内部に設けられる。情報処理部31は、角速度センサ40から出力された角速度データを受信して、ゲーム装置10の姿勢や動きを算出する。
情報処理部31には、RTC38および電源回路41が接続される。RTC38は、時間をカウントして情報処理部31に出力する。情報処理部31は、RTC38によって計時された時間に基づき現在時刻(日付)を計算する。電源回路41は、ゲーム装置10が有する電源(下側ハウジング11に収納される上記充電式電池)からの電力を制御し、ゲーム装置10の各部品に電力を供給する。
情報処理部31には、I/F回路42が接続される。I/F回路42には、マイク43、スピーカ44、およびタッチパネル13が接続される。具体的には、I/F回路42には、図示しないアンプを介してスピーカ44が接続される。マイク43は、ユーザの音声を検知して音声信号をI/F回路42に出力する。アンプは、I/F回路42からの音声信号を増幅し、音声をスピーカ44から出力させる。I/F回路42は、マイク43およびスピーカ44(アンプ)の制御を行う音声制御回路と、タッチパネル13の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するA/D変換およびD/A変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル13からの信号に基づいて所定の形式のタッチ位置データを生成して情報処理部31に出力する。タッチ位置データは、タッチパネル13の入力面において入力が行われた位置(タッチ位置)の座標を示す。なお、タッチパネル制御回路は、タッチパネル13からの信号の読み込み、およびタッチ位置データの生成を所定時間に1回の割合で行う。情報処理部31は、タッチ位置データを取得することにより、タッチパネル13に対して入力が行われたタッチ位置を知ることができる。
操作ボタン14は、上記各操作ボタン14A〜14Lからなり、情報処理部31に接続される。操作ボタン14から情報処理部31へは、各操作ボタン14A〜14Iに対する入力状況(押下されたか否か)を示す操作データが出力される。情報処理部31は、操作ボタン14から操作データを取得することによって、操作ボタン14に対する入力に応じた処理を実行する。
下側LCD12および上側LCD22は、情報処理部31に接続される。下側LCD12および上側LCD22は、情報処理部31(GPU312)の指示に従って画像を表示する。本実施例では、情報処理部31は、後述するユーザ作成データに含まれるキャラクタなどのコンテンツを下側LCD12及び/又は上側LCD22に表示させる。また、情報処理部31は、上側LCD22に外側撮像部23で撮像した右目用画像と左目用画像とを用いた立体画像(立体視可能な画像)を表示させたり、内側撮像部24で撮像した平面画像を上側LCD22に表示させたり、上側LCD22に外側撮像部23で撮像した右目用画像および左目用画像の一方を用いた平面画像を表示させたりすることも可能である。
具体的には、情報処理部31は、上側LCD22のLCDコントローラ(図示せず)と接続され、当該LCDコントローラに対して視差バリアのON/OFFを制御する。上側LCD22の視差バリアがONになっている場合、情報処理部31のVRAM313に格納された(外側撮像部23で撮像された)右目用画像と左目用画像とが、上側LCD22に出力される。より具体的には、LCDコントローラは、右目用画像について縦方向に1ライン分の画素データを読み出す処理と、左目用画像について縦方向に1ライン分の画素データを読み出す処理とを交互に繰り返すことによって、VRAM313から右目用画像と左目用画像とを読み出す。これにより、右目用画像および左目用画像が、画素を縦に1ライン毎に並んだ短冊状画像に分割され、分割された右目用画像の短冊状画像と左目用画像の短冊状画像とが交互に配置された画像が、上側LCD22の画面に表示される。そして、上側LCD22の視差バリアを介して当該画像がユーザに視認されることによって、ユーザの右目に右目用画像が、ユーザの左目に左目用画像が視認される。以上により、上側LCD22の画面には立体視可能な画像が表示される。
外側撮像部23および内側撮像部24は、情報処理部31に接続される。外側撮像部23および内側撮像部24は、情報処理部31の指示に従って画像を撮像し、撮像した画像データを情報処理部31に出力する。本実施例では、情報処理部31は、外側撮像部23および内側撮像部24のいずれか一方に対して撮像指示を行い、撮像指示を受けた撮像部が画像を撮像して画像データを情報処理部31に送る。具体的には、ユーザによるタッチパネル13や操作ボタン14を用いた操作によって使用する撮像部が選択される。そして、撮像部が選択されたことを情報処理部31(CPU311)が検知し、情報処理部31が外側撮像部23または内側撮像部24に対して撮像指示を行う。
3D調整スイッチ25は、情報処理部31に接続される。3D調整スイッチ25は、スライダの位置に応じた電気信号を情報処理部31に送信する。
3Dインジケータ26は、情報処理部31に接続される。情報処理部31は、3Dインジケータ26の点灯を制御する。例えば、情報処理部31は、上側LCD22が立体表示モードである場合、3Dインジケータ26を点灯させる。
[ネットワーク構成]
次に、図3を参照して、本実施例におけるネットワーク構成について説明する。なお、図3は、本実施例におけるネットワーク構成を示す図である。
図3において、本実施例におけるネットワークは、ゲーム装置10、アクセスポイント(Access Point。以下、APと称する)2、インターネット通信網3およびサーバ5からなる。より詳細には、本実施例におけるネットワークは、上述したようにローカル通信モジュール37を用いて互いに近距離無線通信が可能なゲーム装置10と、これらのゲーム装置10と無線通信モジュール36を用いて無線通信が可能なAP2と、AP2およびインターネット通信網3を介してゲーム装置10のそれぞれと通信可能なサーバ5からなる。
AP2は、従来周知のアクセスポイントである。AP2は、それぞれがインターネット通信網3に接続されている。ゲーム装置10は、その無線通信モジュール36の通信範囲内に位置するAP2を介してインターネット通信網3に接続された種々の通信端末と通信することができる。本実施例におけるAP2は、例えば、ゲーム装置10の製造元が管理するAP、ユーザの個人宅に設置されたAPおよび当該製造元以外の事業者などが設置したAPなどが該当する。
サーバ5は、インターネット通信網3に接続されており、同じくインターネット通信網3に接続されているAP2を通してそれぞれのゲーム装置10と通信可能である。図4は、サーバ5の内部構成の一例を示す図である。
サーバ5は、CPU51、操作検出部52、通信部53、HDD54、メインメモリ55とからなり、これらは通信バス56で互いに通信可能に接続されている。
CPU51は、メインメモリ55に格納された各種プログラムに従って処理をする。操作検出部52は、サーバ5の入力装置(例えば、キーボードなど)に対するユーザ(例えば、サーバ管理者)の操作を検出する。通信部53は、インターネット通信網3を通して、同じくインターネット通信網3に接続されている種々の通信装置と通信する。HDD54は、従来周知のハードディスクドライブであって、CPU51が実行する各種プログラムが格納されている。メインメモリ55は、CPU51が処理を開始するときにHDD54から読み出された各種プログラムが格納される。なお、詳細は後述するが、メインメモリ55には、後述するグローバルブラックリスト(Global Black List。以下、GBLと称する)が格納されており、通信部53およびインターネット通信網3を通してゲーム装置10によってダウンロードされる。ゲーム装置10は、サーバ5からダウンロードしたGBLに基づいて処理をする。また、サーバ5は一方のユーザから他方のユーザへ送信されるデータを受け付けて一時的に保存する機能なども有している。ここで、サーバ5が受け付けるデータには後述するキャラクタを示すユーザ作成データなどが一例として挙げられる。
本発明では、任意のユーザがゲーム装置10を用いて自由に作成したデータ(以下、ユーザ作成データと称する)が、不特定多数のゲーム装置10同士で送受信されるものとする。ユーザ作成データがゲーム装置10同士で送受信される場合には、ユーザによる選択に応じて、即座に送受信される場合と、すれ違い通信または後述するインターネット通信において通信可能なタイミングが到来したときに自動的に送受信される場合とがある。そして、本発明は、他のゲーム装置10から受信したデータの内、表示するのに不適切な内容を示すユーザ作成データを非表示データとし、その内容を表示しないようにする。
ユーザ作成データの一例としては、ユーザによって自由に作成されたキャラクタを示すデータが挙げられる。図5は、キャラクタを取り扱うアプリケーション(以下、キャラクタ取り扱いアプリケーションと称する)の実行中において、キャラクタを作成する画面が表示されているゲーム装置10の一例を示す図である。図5において、下側LCD12には、キャラクタを構成するパーツを選択する画面として、口のパーツを候補の中から選択する画面が表示されている。また、図5において、上側LCD22には、既に選択された各パーツで構成されたキャラクタが表示されている。本実施例では、図5に一例として示すように、ユーザが、キャラクタを構成する各パーツ(目、鼻、口、髪および種々の体型の体など)を、それぞれの候補の中から、上述したゲーム装置10の入力装置を用いて選択することによって、キャラクタを作成することができるものとする。そして、本実施例では、それぞれのユーザによって作成されたキャラクタを示すユーザ作成データが、不特定多数のゲーム装置10同士で送受信されるものとする。
上述したようにユーザは、キャラクタを自由に作成することができる。従って、ユーザは、例えば、過去に存在した犯罪者を模したキャラクタなどの道徳上の観点から好ましくない内容を示すデータを、ユーザ作成データとして作成することも可能である。そして、このように道徳上の観点から好ましくない内容を示すデータも、上述したように不特定多数のゲーム装置10同士で送受信される。そして、受信されたユーザ作成データは、当該データを受信したゲーム装置10において事前に特定しない限りユーザにその内容が表示されてしまう。
そこで、本発明では、このように道徳上の観点から好ましくない内容を示すユーザ作成データを受信したとしても非表示データとして表示しないようにする。本発明では、受信したデータの中から非表示データを特定するために、上述したGBLおよびローカルブラックリスト(Local Black List。以下、LBLと称する)を用いる。以下、本発明に係る情報処理システムの概略を説明する。
図6は、本発明に係る情報処理システム(以下、単に本システムと称する)の概略を説明するための図である。図6には、ゲーム装置A〜ゲーム装置Dの4台のゲーム装置10と、サーバ5とが示されている。また、図6には、本システムにおける動作に時系列に従った順番(I)〜(X)を付している。
図6において、例えば、ゲーム装置Aのユーザがユーザ作成データを作成したとする(以下、このデータをユーザ作成データaと称する)。そして、ユーザ作成データaが、すれ違い通信によってゲーム装置Aからゲーム装置Bに送信されたとする(図6の(I))。ここで、ゲーム装置Bのユーザが、受信したユーザ作成データaによって示されるキャラクタを道徳上の観点から好ましくないと感じたとする。この場合、本システムにおいて、ゲーム装置Bのユーザは、ゲーム装置Bに格納されているLBLにユーザ作成データaを登録することができる。LBLは、それぞれのゲーム装置10に格納されており、それぞれのユーザは任意のユーザ作成データを登録できる(図6の(II))。LBLに登録されたユーザ作成データによって示されるキャラクタは、登録後に同じデータを受信したとしても表示されなくなる。なお、本システムでは、一例として、LBLがゲーム装置10同士で送受信されることはない。
また、本システムでは、ゲーム装置Bのユーザがユーザ作成データaを特定するための情報(ID)などを非表示データとしてLBLに登録することが可能であると共に、当該ユーザ作成データaをサーバ5に通報することも可能である。ここでは、ゲーム装置Bのユーザが、ユーザ作成データaをLBLに登録すると共にサーバ5に通報したものとする(図6の(III))。サーバ5は、上述したようにGBLを管理しており、不特定多数のゲーム装置10からインターネット通信網3を用いて通報を受け付ける。サーバ5は、通報を受けたユーザ作成データの中で所定の条件を満たすユーザ作成データを非表示データとしてGBLに登録する。ここでは、ゲーム装置Bのユーザによってユーザ作成データaが通報されたことにより、当該ユーザ作成データaがGBLに登録されたものとする(図6の(IV))。後に詳述するが、ユーザ作成データがGBLに登録されるときには、上述したように通報されるときに送信される当該ユーザ作成データに含まれるユーザIDやデータIDなどがGBLに登録されることとなる。それぞれのゲーム装置10は、それぞれの所定の周期で、サーバ5で管理されているGBLをダウンロードし、格納しているGBLを必要に応じて更新する。ここでは、ゲーム装置Cが、サーバ5からGBLをダウンロードして更新したものとする(図6の(V))。これにより、ゲーム装置Cでは、ユーザ作成データaが非表示データとして特定される。従って、ゲーム装置Cでユーザ作成データaが受信されたとしても、当該ユーザ作成データaで示されるキャラクタは表示されない(図6の(VII))。これにより、ゲーム装置Cのユーザは、道徳上の観点から好ましくないキャラクタを見ずに済む。
また、GBLは、LBLと異なり、ゲーム装置10同士ですれ違い通信によって送受信され、必要に応じて更新される。ここでは、ゲーム装置Cに格納されたGBLが、すれ違い通信によってゲーム装置Dに送信されたものとする(図6の(VIII))。ゲーム装置Dは、すれ違い通信によって受信したGBLで、既に格納されているGBLを更新する。このように、ゲーム装置Dは、例えば、インターネット通信網3に接続できず、サーバ5からGBLをダウンロードできなかったとしても、他のゲーム装置CからGBLを受信して更新することができる。そして、ゲーム装置Dが、すれ違い通信によってユーザ生成データaを受信したとしても(図6の(IX))、ゲーム装置Dでは非表示データとして特定される。従って、ゲーム装置Dには、ユーザ生成データaで示されるキャラクタが表示されない(図5の(X))。このように、本システムでは、ゲーム装置Dがサーバ5と通信できなかったとしても、ゲーム装置Dのユーザは、道徳上の観点から好ましくないキャラクタを見ずに済む。
以上で説明したように、本システムでは、それぞれのゲーム装置10がLBLを格納しており、それぞれのユーザは受信したユーザ作成データの中から任意のデータを登録することができる。また、それぞれのユーザは、上述したように自身が好ましくないと感じたユーザ作成データをサーバ5に通報することができる。サーバ5は、それぞれのユーザから通報された回数を管理し、通報回数が所定の閾値を超えたユーザ作成データを所定の条件を満たすデータとしてGBLに登録して更新する。また、上述したようにサーバ5によって管理されているGBLは、それぞれのゲーム装置10によってそれぞれの所定の周期でダウンロードされる。そして、それぞれのゲーム装置10は、格納しているGBLをダウンロードしたGBLで必要に応じて更新する。従って、それぞれのゲーム装置10に格納されているGBLは、常に最新の非表示データを示す情報となる。さらに、ゲーム装置10によって受信されたGBLは、すれ違い通信によって交換することができる。従って、サーバ5からGBLをダウンロードできないゲーム装置10であっても、他のゲーム装置10と通信可能であればGBLを受信して更新することができる。そして、それぞれのゲーム装置10がGBLを格納することにより、未だに受信していないユーザ作成データであっても、非表示データとして特定されれば事前に表示しないようにできる。以上が、本システムの概要の説明である。
[各種データの説明]
次に、ゲーム装置10およびサーバ5でそれぞれ行われる処理を具体的に説明する前に、図7A〜図7Fを参照して、それぞれにおいて用いられるデータについて説明する。なお、図7Aは、ゲーム装置10に電源が投入されることに応じてメインメモリ32に格納されるデータ及び各種プログラムを示す。また、図7Bは、図7Aに示すユーザ作成データUdのより詳細なデータの構成を示す。また、図7Cは、図7Aに示すタスクデータTdのより詳細なデータの構成を示す。また、図7Dは、図7Aに示すLBLデータLdのより詳細なデータの構成を示す。また、図7Eは、図7Aに示すGBLデータGdのより詳細なデータの構成を示す。また、図7Fは、サーバ5が各種プログラムを実行することに応じてメインメモリ55に格納されるデータを示す。
[ゲーム装置10に格納されるデータ]
まず、図7A〜図7Eを参照して、ゲーム装置10のメインメモリ32に格納されるデータおよび各種プログラムについて説明する。ゲーム装置10のメインメモリ32には、図7Aに示すように、ユーザ作成データUd、タスクデータTd、LBLデータLd、GBLデータGd、ネット受信GBLデータNgd、すれ違いボックスデータTbおよび各種プログラムPaが格納される。
ユーザ作成データUdは、任意のアプリケーションを用いてユーザが作成したデータである。本実施例では、任意のアプリケーションの一例として、キャラクタ取り扱いアプリケーションを挙げている。従って、本実施例におけるユーザ作成データUdは、キャラクタ取り扱いアプリケーションで取り扱われるキャラクタを示すデータとなる。ユーザ作成データUdは、図7Bに示すように、ユーザIDとデータIDとアプリIDとデータ本文とからなる。以下、ユーザ作成データUdに含まれるそれぞれのデータについて説明する。
ユーザIDは、ユーザ作成データUdによって示されるキャラクタを新たに作成したユーザおよび既存のキャラクタを変更したユーザを示すデータである。具体的には、ユーザIDには、作成者IDと変更者IDとが含まれる。作成者IDは、キャラクタを新たに作成したユーザを示すIDである。作成者IDは、例えば、ユーザがキャラクタを新たに作成するのに使用したゲーム装置10を識別するための固有の識別子など、キャラクタを新たに作成したユーザを特定できる情報であれば任意の情報であってよい。なお、作成者IDは、キャラクタを新たに作成したユーザのIDを示すので、作成者IDが更新されることはない。
変更者IDは、既存のキャラクタを変更したユーザを示すIDである。変更者IDは、例えば、ユーザが既存のキャラクタを変更するのに使用したゲーム装置10を識別するための固有の識別子など、既存のキャラクタを変更したユーザを特定できる情報であれば任意の情報であってよい。変更者IDは、既存のキャラクタが変更される度にユーザIDに追加される。
データ本文は、ユーザ作成データUdによって示されるデータの内容(コンテンツ)そのものである。ユーザ作成データUdは、上述したように任意のアプリケーションを用いて生成されたデータである。そして、ユーザ作成データUdがキャラクタ取り扱いアプリケーションにおいて取り扱われるキャラクタを示す場合、データ本文は当該キャラクタを構成する各パーツの形状や色を示すデータとなる。データ本文で示される形状のキャラクタが、当該データ本文を含むユーザ作成データUdによって示されるキャラクタとなる。
アプリIDは、当該アプリIDを含むユーザ作成データUdを取り扱うアプリケーションを一意に識別するためのIDである。すなわち、ユーザ作成データUdの作成や変更に用いられたアプリケーションを示すIDである。本実施例では、キャラクタ取り扱いアプリケーションを示すIDがアプリIDとなる。なお、アプリIDは、ユーザ作成データUdを取り扱うアプリケーションが同一であれば、当該ユーザ作成データUdが異なるゲーム装置10に格納されていたとしても同一のIDとなる。
データIDは、前述のデータ本文をアプリケーション毎に一意に識別するためのIDである。従って、ユーザ作成データUdを取り扱うアプリケーションが同一であれば、当該ユーザ作成データUdを格納しているゲーム装置10が異なっていても、データIDは重複しない。一方で、データIDは、同一のゲーム装置10に格納されていたとしても、取り扱うアプリケーションが異なれば、同一のIDとなる場合もある。
以上がユーザ作成データUdに含まれるそれぞれのデータの説明である。なお、図7Aには、1つのユーザ作成データUdがメインメモリ32に格納されている一例を示している。しかしながら、メインメモリ32には、新たなユーザ作成データUdが生成される或いは既存のユーザ作成データUdが読み込まれることにより、1以上のユーザ作成データUdが格納される。
新たなユーザ作成データUdは、ユーザがキャラクタ取り扱いアプリケーションを使用してキャラクタを新たに作成したときにメインメモリ32に生成される。新たなユーザ作成データUdは、ユーザがキャラクタを新たに作成する度にメインメモリ32に追加される。そして、ユーザがキャラクタの作成を終え、キャラクタ取り扱いアプリケーションを終了すると、メインメモリ32に生成されたユーザ作成データUdがデータ保存用外部メモリ46に格納される。データ保存用外部メモリ46に格納された既存のユーザ作成データUdは、ユーザがキャラクタ取り扱いアプリケーションをゲーム装置10に実行させたときに読み出されメインメモリ32に格納される。このとき、データ保存用外部メモリ46に1以上のユーザ作成データUdが格納されていれば、1以上のユーザ作成データUdがメインメモリ32に格納されることになる。
次に、タスクデータTdについて説明する。タスクデータTdは、インターネット通信を用いたデータの受信または送信をタスクとして示すデータである。タスクは当該タスクを生成したアプリケーションが実行中であるか否かに関わらずに、CPU311によって実行される。本実施例におけるタスクは、CPU311によって設定された時刻に実行されるタスクであるものとする。なお、他の一実施形態では、ゲーム装置10において実行可能なタスクとして、ユーザの指示に応じて即座に実行されるタスクや、通信相手となるAP2の管理者を示す情報に応じて実行優先度または実行順序などが変更可能なタスクがあってもよい。
タスクデータTdは、図7Cに一例として示すように、アプリIDと通信先URLと次回実行時刻と送信/受信識別フラグと格納先情報とからなる。
アプリIDは、タスクデータTdを生成するのに用いられたアプリケーションを一意に識別するためのIDである。通信先URLは、データを受信または送信する通信先を示す。次回実行時刻は、タスクデータTdで示されるタスクを次に実行する時刻を示す。送信/受信識別フラグは、当該フラグを含むタスクデータTdで示されるタスクが、受信のタスクであるか送信のタスクであるかを示す情報である。格納先情報は、タスクデータTdで示されるタスクで取り扱うデータの格納先を示す情報である。より具体的には、タスクデータTdで示されるタスクが送信タスクである場合には、格納先情報は、送信するデータのゲーム装置10における格納領域を示す情報となる。一方、タスクデータTdで示されるタスクが受信タスクである場合には、格納先情報は、受信したデータのゲーム装置10における格納領域を示す情報となる。
本実施例において、タスクデータTdによって示されるタスクとしては、キャラクタを通報するタスク、キャラクタを受信するタスク、キャラクタを送信するタスクおよび配信用GBLデータGsdを受信するタスクが一例として挙げられる。
まず、キャラクタを通報するためのタスクデータTdについて説明する。キャラクタを通報するためのタスクデータTdは、後述するように、LBL登録処理においてユーザによって通報が選択されたときに生成される。LBL登録処理はキャラクタ取り扱いアプリケーションにおいて実行される。従って、キャラクタを通報するためのタスクデータTdには、キャラクタ取り扱いアプリケーションを一意に識別するアプリIDが含まれる。また、キャラクタを通報するためのタスクデータTdには、通報先がサーバ5として予め定められているため、通信先URLとして、サーバ5のURLが含まれる。また、キャラクタを通報するためのタスクデータTdには、CPU311によって設定された次回実行時刻が含まれる。また、キャラクタを通報するためのタスクデータTdは、通報するときにキャラクタを示すユーザ作成データUdを送信するので送信を示す送信/受信識別フラグを含む。また、キャラクタを通報するためのタスクデータTdには、当該キャラクタを示すユーザ作成データUdのメインメモリ32における格納領域が格納先情報として含まれる。
次に、キャラクタを受信するためのタスクデータTdについて説明する。キャラクタを受信するためのタスクデータTdは、後述するように、キャラクタ取り扱い処理において、キャラクタのインターネット通信網3を介した受信がユーザによって選択されたときに生成される。また、キャラクタ取り扱い処理プログラムのインストール時に生成されてもよい。従って、キャラクタを受信するためのタスクデータTdには、キャラクタ取り扱いアプリケーションを一意に識別するアプリIDが含まれる。また、キャラクタを受信するためのタスクデータTdには、自身宛に他人から送信されたキャラクタを一時的に保持しておくためのサーバ5のURLが通信先URLとして含まれる。また、キャラクタを受信するためのタスクデータTdには、CPU311によって設定された次回実行時刻が含まれる。また、キャラクタを受信するためのタスクデータTdは、キャラクタを受信するためのタスクを示すので、受信を示す送信/受信識別フラグを含む。また、キャラクタを受信するためのタスクデータTdには、新たに受信したキャラクタを示すユーザ作成データUdのメインメモリ32における格納領域が格納先情報として含まれる。
次に、キャラクタを他人に送信するためのタスクデータTdについて説明する。キャラクタを送信するためのタスクデータTdは、後述するように、キャラクタ取り扱い処理において、インターネット通信網3を介したキャラクタの送信がユーザによって選択されたときに生成される。従って、キャラクタを送信するためのタスクデータTdには、キャラクタ取り扱いアプリケーションを一意に識別するアプリIDが含まれる。また、キャラクタを送信するためのタスクデータTdには、キャラクタの送信を受け付けるためのサーバ5のURLが通信先URLとして含まれる。また、キャラクタを送信するためのタスクデータTdには、CPU311によって設定された次回実行時刻が含まれる。また、キャラクタを送信するためのタスクデータTdは、キャラクタを送信するためのタスクを示すので、送信を示す送信/受信識別フラグを含む。また、キャラクタを送信するためのタスクデータTdには、ユーザによって送信するように選択されたキャラクタを示すユーザ作成データUdのメインメモリ32における格納領域が格納先情報として含まれる。
次に、配信用GBLデータGsdを受信するためのタスクデータTdについて説明する。後に詳述するが、ゲーム装置10は、配信用GBLデータGsdをサーバ5から定期的に受信してGBLを更新する。すなわち、配信用GBLデータGsdを受信するためのタスクデータTdは、キャラクタ取り扱いアプリケーションなどの任意のアプリケーションの実行中に生成されるデータではない。従って、配信用GBLデータGsdを受信するためのタスクデータTdには、例えば、アプリIDとして考えられるID以外のIDが例外的にアプリIDとして含まれる。例えば、本体のシステムを表すIDなどである。また、配信用GBLデータGsdを受信するためのタスクデータTdには、当該配信用GBLデータGsdをサーバ5から受信するために、当該サーバ5のURLが通信先URLとして含まれる。また、配信用GBLデータGsdを受信するためのタスクデータTdには、CPU311によって設定された次回実行時刻が含まれる。また、配信用GBLデータGsdを受信するためのタスクデータTdは、配信用GBLデータGsdを受信するためのタスクを示すので、受信を示す送信/受信識別フラグを含む。また、配信用GBLデータGsdを受信するためのタスクデータTdには、インターネット通信網3を用いて受信したネット受信GBLデータNgdのメインメモリ32における格納領域が格納先情報として含まれる。
なお、図7Aには、1つのタスクデータTdが格納されているメインメモリ32を一例として示している。しかしながら、本実施例におけるタスクには、上述したように種々のタスクがある。そして、これらのタスクはユーザの選択などに応じて複数設定される場合がある。また、未実行のタスクが残っている状態で、同種のタスクが設定される場合もある。このような場合、メインメモリ32には、設定されたタスクを示す1以上のタスクデータTdが格納される。
また、上述した種々のタスクデータTdに含まれる次回実行時刻はCPU311によって設定された次回実行時刻であるものとした。ここで、CPU311が次回実行時刻を設定するのは、タスクデータTdを生成したときおよびタスクを実行して次回実行時刻を更新するときである。CPU311がタスクデータTdを生成したときには、生成した時刻から所定の時間間隔をおいた時刻が次回実行時刻として設定されるものとする。また、CPU311が次回実行時刻を更新するときには、更新したときから所定の時間間隔をおいた時刻が次回実行時刻として設定されるものとする。なお、他の一実施形態では、ユーザによって設定された時刻に次回実行時刻を更新するようにしてもよい。
以上が、タスクデータTdの説明である。次に、LBLデータLdについて説明する。LBLデータLdは、上述したLBLを示すデータである。より詳細には、LBLデータLdは、他のゲーム装置10から受信したユーザ作成データUdの中から、CPU311が非表示データを特定するためのLBLを示すデータである。CPU311がLBLデータLdを用いて特定する非表示データは、ユーザによって判断され登録されたキャラクタを示すユーザ作成データUdである。
LBLデータLdは、図7Dに示すように、変更者LBLを示す変更者LBLデータおよびデータLBLを示すデータLBLデータからなる。また、変更者LBLデータは、アプリIDと変更者IDとを含む変更者特定LBLデータの集合体である。変更者特定LBLデータに含まれる変更者IDは、後述するようにユーザによって登録するように選択されたユーザ作成データUdの最後の変更者IDである。従って、変更者特定LBLデータは、ユーザ作成データUdを最後に変更した変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるものとして示すデータとなる。そして、変更者LBLは、ユーザ作成データUdを最後に変更した変更者を、道徳上の観点から好ましくないキャラクタを作成するユーザとして示すリストとなる。また、他の一実施形態では、ユーザ作成データの最初の作成者のIDを登録するようにしてもよい。
一方、データLBLデータは、アプリIDとデータIDとを含むデータ特定LBLデータの集合体である。データ特定LBLデータに含まれるデータIDは、後述するようにユーザによって登録するように選択されたユーザ作成データUdのデータIDである。従って、データ特定LBLデータは、ユーザ作成データUdで示されるキャラクタが道徳上の観点から好ましくないキャラクタであることを示すデータとなる。そして、データLBLは、道徳上の観点から好ましくないキャラクタを示すリストとなる。
なお、図7Dには、2つの変更者特定LBLデータを含む変更者LBLデータを一例として示している。しかしながら、変更者LBLデータには、ユーザによって任意に登録された数だけ変更者特定LBLデータを含めることができる。また、図7Dには、2つのデータ特定LBLデータを含むデータLBLデータを一例として示している。しかしながら、データLBLデータには、ユーザによって任意に登録された数だけデータ特定LBLデータを含めることができる。
次に、GBLデータGdについて説明する。GBLデータGdは、上述したGBLを示すデータである。より詳細には、GBLデータGdは、他のゲーム装置10から受信したユーザ作成データUdの中から、CPU311が非表示データを特定するためのGBLを示すデータである。GBLデータGdは、サーバ5によって管理されている配信用GBLデータGsdをゲーム装置10が受信したデータである。後に詳述するが、サーバ5は、ユーザによって通報された通報回数に基づいてGBLに登録するユーザ作成データUdを判断する。従って、CPU311がGBLデータGdを用いて特定する非表示データは、サーバ5によって判断されたキャラクタを示すユーザ作成データUdとなる。
GBLデータGdは、図7Eに示すように、変更者GBLを示す変更者GBLデータおよびデータGBLを示すデータGBLデータからなる。変更者GBLデータは、アプリIDと変更者IDとを含む変更者特定GBLデータの集合体である。変更者特定GBLデータに含まれる変更者IDは、後述するようにサーバ5によって判断された変更者IDである。より詳細には、サーバ5はユーザ作成データUdの最後の変更者IDの通報回数に基づいて、通報されたユーザ作成データUdの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるか否かを判断する。そして、サーバ5に対する通報は、本システムに含まれるゲーム装置10の全てのユーザのそれぞれの選択に応じて行われる。従って、変更者特定GBLデータは、本システムに含まれるゲーム装置10の全てのユーザの選択に基づいてサーバ5が判断したユーザを示すデータとなる。そして、変更者GBLは、本システムに含まれるゲーム装置10の全てのユーザの選択に基づいて、道徳上の観点から好ましくないキャラクタを作成すると判断されたユーザのリストとなる。また、他の一実施形態では、サーバ5は、ユーザ作成データの最初の作成者のIDの通報回数に基づいて好ましくないキャラクタを作成するユーザを判断するようにしてもよい。
なお、変更者特定GBLデータは、Nullで示されるアプリIDと変更者IDとを含む場合がある。Nullで示されるアプリIDとは、全てのアプリケーションを示すIDである。従って、NullのアプリIDと共に変更者特定GBLデータに含まれている変更者IDを含むユーザ作成データUdは、当該ユーザ作成データUdを取り扱うアプリケーションに関わらず非表示データに設定される。
一方、データGBLデータは、アプリIDとデータIDとを含むデータ特定GBLデータの集合体である。データ特定GBLデータに含まれるデータIDは、後述するようにサーバ5によって判断された変更者IDである。より詳細には、サーバ5はユーザ作成データUdのデータIDの通報回数に基づいて、通報されたユーザ作成データUdによって示されるキャラクタが道徳上の観点から好ましくないキャラクタであるか否かを判断する。そして、サーバ5に対する通報は、上述したように本システムに含まれるゲーム装置10の全てのユーザのそれぞれの選択に応じて行われる。従って、データ特定GBLデータは、変更者特定GBLデータと同様に、本システムに含まれるゲーム装置10の全てのユーザの選択に基づいてサーバ5が判断したキャラクタを示すデータとなる。そして、データ特定GBLは、本システムに含まれるゲーム装置10の全てのユーザの選択に基づいて判断された、道徳上の観点から好ましくないキャラクタのリストとなる。
なお、図7Eには、2つの変更者特定GBLデータを含む変更者GBLデータを一例として示している。しかしながら、変更者GBLデータには、サーバ5によって登録された数だけ変更者特定GBLデータを含めることができる。また、図7Eには、2つのデータ特定GBLデータを含むデータGBLデータを一例として示している。しかしながら、データGBLデータには、サーバ5によって登録された数だけデータ特定GBLデータを含めることができる。
次に、ネット受信GBLデータNgdについて説明する。ネット受信GBLデータNgdは、上述した送信GBLデータSgdを受信するタスクが実行されることによって受信されたデータである。後に詳述するが、ネット受信GBLデータNgdで示されるバージョンがより新しい場合に、メインメモリ32に格納されているGBLデータGdが更新される。
次に、すれ違いボックスデータTbに含まれるデータについて説明する。すれ違いボックスデータTbは、すれ違い通信において自動的に送受信するためのデータからなる。具体的には、すれ違いボックスデータTbは、受信ボックスデータJbと送信ボックスデータSbとからなる。
受信ボックスデータJbは、すれ違い通信において自動的に受信されたデータからなる。本実施例におけるすれ違い通信では、図7Aに示すように、すれ違い受信データJdと受信GBLデータJgdがそれぞれ自動的に受信される。
すれ違い受信データJdは、すれ違い通信において他のゲーム装置10から自動的に送信されたユーザ作成データUdである。また、受信GBLデータJgdは、すれ違い通信において他のゲーム装置10から自動的に送信された送信GBLデータSgdである。従って、受信GBLデータJgdには上述した例外的なアプリIDが含まれている(図示せず)。
一方、送信ボックスデータSbは、すれ違い通信において自動的に送信されるデータからなる。本実施例におけるすれ違い通信では、図7Aに示すように、すれ違い送信データSdと送信GBLデータSgdがそれぞれ自動的に送信される。
すれ違い送信データJdは、すれ違い通信をする他のゲーム装置10に自動的に送信されるユーザ作成データUdである。また、送信GBLデータSgdは、すれ違い通信をする他のゲーム装置10に自動的に送信されるGBLデータGdである。従って、送信GBLデータSgdにも上述した例外的なアプリIDが含まれている(図示せず)。
以上が、すれ違いボックスデータTbに含まれるデータの説明である。なお、図7Aには、一例として、すれ違い送信データSdを1つだけ含む送信ボックスデータSbを示している。しかし、後述で明らかとなるが、送信ボックスデータSbにはすれ違い通信での送信が選択されたキャラクタの数だけすれ違い送信データSdが含まれることとなる。また、他の一実施形態では、同一アプリ間ですれ違い通信によって交換されるデータは1つのすれ違い送信データJdにまとめて含めるようにしてもよい。また、図7Aには、一例として、すれ違い受信データJdを1つだけ含む受信ボックスデータJbを示している。しかし、後述で明らかとなるが、受信ボックスデータJbにはすれ違い通信で他のゲーム装置10から送信されたすれ違い送信データSdの数だけすれ違い受信データJdが含まれることとなる。また、他の一実施形態では、同一アプリ間ですれ違い通信によって交換されるデータは1つのすれ違い受信データJdにまとめて含めるようにしてもよい。
メインメモリ32には、他にも図7Aに示すように各種プログラムPaが含まれるが、各種プログラムPaの詳細については後述する。
以上が、ゲーム装置10のメインメモリ32に格納されるデータおよびプログラムの説明である。次に、図7Fを参照して、サーバ5のメインメモリ55に格納される各種データについて説明する。
[サーバ5に格納されるデータ]
サーバ5のメインメモリ55には、図7Fに示すように、配信用GBLデータGsd、ユーザ特定用カウントデータUcdおよびデータ特定用カウントデータDcdが格納される。
配信用GBLデータGsdは、サーバ5が管理しているGBLを示すデータである。サーバ5が管理しているGBLは、後述するようにゲーム装置10のそれぞれによって配信用GBLデータGsdを受信するためのタスクが実行されることに応じて、それぞれのゲーム装置10に送信される。なお、サーバ5が管理している配信用GBLデータGsdのデータ構造は、ゲーム装置10のメインメモリ32に格納されるGBLデータGdのデータ構造と同一である。そして、サーバ5が管理している配信用GBLデータGsdは、後述するようにユーザからの通報回数に基づいて常に最新のデータとなるように更新される。
ユーザ特定用カウントデータUcdは、ユーザ作成データUdの通報回数を最後の変更者毎にカウントするためのデータである。具体的には、ユーザ特定用カウントデータUcdには、1以上のユーザカウントデータが含まれる。ユーザカウントデータは、変更者IDとアプリIDと通報回数とからなる。ユーザカウントデータに含まれる通報回数は、それ自体に含まれる変更者IDとアプリIDとを含むユーザ作成データUdが通報された回数を示す。また、ユーザカウントデータに含まれる変更者IDは、通報されたユーザ作成データUdに含まれる最後の変更者IDである。従って、ユーザカウントデータは、ユーザ作成データUdによって示される最後の変更者に基づいて通報された回数を示す。
なお、通報されたユーザ作成データUdに含まれる最後の変更者IDとアプリIDとを含むユーザカウントデータがユーザ特定用カウントデータUcdに含まれていない場合には、当該変更者IDと当該アプリIDとを含むユーザカウントデータが新たに生成される。従って、ユーザ特定用カウントデータUcdに含まれるユーザカウントデータは、図7Fに示すように2つに限られない。
また、データ特定用カウントデータDcdは、ユーザ作成データUdの通報回数をデータ毎にカウントするためのデータである。具体的には、データ特定用カウントデータDcdには、データIDとアプリIDと通報回数とからなるデータカウントデータが1以上含まれる。データカウントデータに含まれる通報回数は、それ自体に含まれるデータIDとアプリIDとを含むユーザ作成データUdが通報された回数を示す。従って、データカウントデータは、ユーザ作成データUdによって示されるデータの内容に基づいて通報された回数を示すデータとなる。
なお、通報されたユーザ作成データUdに含まれるデータIDとアプリIDとを含むデータカウントデータがデータ特定用カウントデータDcdに含まれていない場合には、当該データIDと当該アプリIDとを含むデータカウントデータが新たに生成される。従って、データ特定用カウントデータDcdに含まれるデータカウントデータは、図7Fに示すように2つに限られない。
[各種プログラムによる処理の説明]
次に、図8A〜図8Jを参照して、ゲーム装置10で実行される各種プログラムによる具体的な処理について説明する。なお、図8Aおよび図8Bは、キャラクタ取り扱い処理プログラムを実行することによってゲーム装置10がキャラクタ取り扱い処理を行う一例を示すフローチャートである。図8Cおよび図8Dは、図8Aのステップ140で実行されるキャラクタ編集処理の詳細を示すフローチャートである。図8Eは、図8Aのステップ150で実行されるLBL登録処理の詳細を示すフローチャートである。図8Fは、すれ違い通信処理プログラムを実行することによってゲーム装置10がすれ違い通信処理を行う一例を示すフローチャートである。図8Gは、インターネット通信処理プログラムを実行することによってゲーム装置10がインターネット通信処理を行う一例を示すフローチャートである。図8Hは、図8Bのステップ180で実行されるローカル通信処理の詳細を示すフローチャートである。図8Iは、図8Dのステップ280、図8Fのステップ560および図8Gのステップ635で実行されるフィルタリング処理の詳細を示すフローチャートである。図8Jは、GBL更新処理プログラムを実行することによってゲーム装置10がGBL更新処理を行う一例を示すフローチャートである。なお、これらの処理を実行するためのプログラムは、データ保存用内部メモリ35に格納されている各種プログラムPaに含まれており、ゲーム装置10の電源がオンになったときに、データ保存用内部メモリ35からメインメモリ32に読み出されて、CPU311によって実行される。本実施例では上記各種プログラムPaは予めデータ保存用内部メモリ35に記憶されているものとしたが、当該各種プログラムPaの1つ又は全部のプログラムを、インターネット等を介してゲーム装置10にダウンロードするようにしてもよい。また、データ保存用外部メモリ46や外部メモリ45に格納されたプログラムから読み出して実行するようにしてもよい。
また、図8A〜図8Jにそれぞれ示す処理の内、すれ違い通信処理、インターネット通信処理およびGBL更新処理は、ゲーム装置10の電源をオンにした後は、他の処理のいずれかが実行されているときであっても、実行されている他の処理とそれぞれとが並行して常に繰り返し実行されているものとする。また、すれ違い通信処理、インターネット通信処理およびGBL更新処理は、他に実行されている処理がない場合でも並行して常に繰り返し実行されているものとする。つまり、すれ違い通信処理、インターネット通信処理およびGBL更新処理は、他の処理が実行されているか否かに関わらず、常にそれぞれが並行して繰り返し実行されているものとする。
まず、ゲーム装置10の電源(電源ボタン14F)がオンにされると、CPU311によってブートプログラム(図示せず)が実行され、これによりデータ保存用内部メモリ35に格納されている、複数のアプリケーションプログラムを選択的に実行させるプログラムであるランチャープログラムがメインメモリ32にロードされCPU311で実行される。その後、ランチャープログラム上でキャラクタ取り扱いアプリケーションを選択して実行することにより、キャラクタ取り扱い処理プログラムがメインメモリ32にロードされる。そして、ロードされたキャラクタ取り扱い処理プログラムをCPU311が実行することによって、図8Aのステップ101から処理が開始される。なお、図8A〜図8Jにおいては、ステップを「S」と略称している。
キャラクタ取り扱い処理とは、キャラクタの編集、LBLへの登録および通信を用いた交換などをユーザの選択に応じて実行するための処理である。より具体的には、キャラクタ取り扱い処理とは、後述するようにキャラクタを新規作成する処理、既存のキャラクタを変更する処理、キャラクタをLBLへ登録する処理、すれ違い通信においてキャラクタを送信する処理、インターネット通信においてキャラクタを受信する処理、インターネット通信においてキャラクタを送信する処理、ローカル通信においてキャラクタを送信する処理およびその他の各種処理などをユーザが選択してゲーム装置10に実行させるための処理である。
図8Aにおいて、CPU311は、上述したそれぞれの処理のユーザによる選択を受け付ける前に、メインメモリ32に格納されている受信ボックスデータJbを参照して、新たなすれ違い受信データJd(新着データ)が格納されているか否かを判断する(ステップ101)。CPU311は、新たなすれ違い受信データJdが格納されていると判断した場合(ステップ101でYes)、当該すれ違い受信データJdを新たなユーザ作成データUdとして、ユーザ作成データUdの格納領域に格納する(ステップ105)。新たなユーザ作成データUdを格納すると、CPU311は、受信ボックスデータJbに格納されている新たなすれ違い受信データJdを削除する(ステップ110)。
CPU311は、新たなすれ違い受信データJdが格納されていないと判断した場合(ステップ101でNo)または新たなすれ違い受信データJdを削除すると、フィルタリング処理を実行する(ステップ115)。フィルタリング処理の詳細については後述するが、概要を説明すると、フィルタリング処理は、フィルタリング対象となるユーザ作成データUdをフィルタリングして非表示データを特定して設定する処理である。ステップ115におけるフィルタリング処理ではメインメモリ32に格納されているユーザ作成データUdがフィルタリング対象となる。非表示データを設定すると、CPU311は、非表示データに設定されていないそれぞれのユーザ作成データUdで示されるキャラクタを表示対象として上側LCD22に表示する(ステップ120)。ここでは、非表示データに設定されていないキャラクタの全てを表示するのに限らず、例えば、非表示データに設定されていないキャラクタのうち、今回すれ違い通信によって新たに受信したものを表示したり、非表示データに設定されていないキャラクタのうち、ランダムに複数をピックアップして表示したりする。また、CPU311は、表示対象を上側LCD22に表示すると共に、下側LCD12に、各種処理をそれぞれ示すアイコンを表示する。本実施例では、このように、表示対象のみのキャラクタとそれぞれのアイコンとを表示する画面をキャラクタ取り扱い画面として表示するものとする。キャラクタ取り扱い画面では、表示されたアイコンにユーザがタッチ操作することによって対応する処理を選択することができる。
キャラクタ取り扱い画面を表示するとCPU311は、上述したそれぞれの処理のユーザによる選択の受け付けを開始する。CPU311は、まず始めに、ユーザによってキャラクタを新規作成する処理が選択されたか否かを判断する(ステップ125)。キャラクタを新規作成する処理が選択されたと判断した場合(ステップ125でYes)、CPU311は、キャラクタ編集処理を開始する(ステップ140)。このとき、CPU311は、新規作成されるキャラクタを編集対象とする。
一方、CPU311は、キャラクタを新規作成する処理が選択されていないと判断した場合(ステップ125でNo)、既存のキャラクタを変更する処理がユーザによって選択されたか否かを判断する(ステップ130)。CPU311は、既存のキャラクタを変更する処理がユーザによって選択されたと判断した場合(ステップ130でYes)、変更フラグHf(図示せず)をオンにする(ステップ135)。このとき、CPU311は、上側LCD22に表示されているキャラクタの内、編集対象とするキャラクタをユーザに選択させてから変更フラグHfをオンにする。編集対象とするキャラクタをユーザに選択させるには、上側LCD22に表示されているキャラクタに対応する情報(例えば、名前など)を下側LCD12に一覧表示し、ユーザに選択させる手法などが一例として挙げられる。編集対象とするキャラクタをユーザに選択させるときに、キャラクタに対応する情報を下側LCD12に一覧表示する場合、下側LCD12に既に表示されている上述したアイコンは消去されるものとする。
変更フラグHfをオンにすると、CPU311は、キャラクタ編集処理を開始する(ステップ140)。以下、図8Cを参照して、上記ステップ140で行うキャラクタ編集処理の詳細について説明する。
[キャラクタ編集処理]
図8Cにおいて、CPU311は、キャラクタ編集処理を開始すると、ユーザによってキャラクタの新規作成が選択されたか否かを判断する(ステップ201)。具体的には、CPU311は、メインメモリ32を参照して変更フラグHfがオンとなっているか否かを判断する。CPU311は、変更フラグHfがオンとなっていない場合、ユーザによって新規作成が選択されたと判断する。一方、CPU311は、変更フラグHfがオンとなっている場合、ユーザによってキャラクタの変更が選択されたと判断する。
CPU311は、ユーザによってキャラクタの新規作成が選択されたと判断した場合(ステップ201でYes)、新たなユーザ作成データUdをメインメモリ32に生成する(ステップ203)。なお、新たに生成されたときのユーザ作成データUdで示されるキャラクタの各パーツは、初期パーツとして予め定められているものとする。
CPU311は、ユーザによってキャラクタの変更が選択されたと判断した場合(ステップ201でNo)またはキャラクタを新規作成すると、編集対象のキャラクタを示すユーザ作成データUdのデータ本文を参照する(ステップ205)。
CPU311は、編集対象のデータ本文を参照(ステップ205)すると、表示画面をキャラクタ取り扱い画面からキャラクタの編集画面に切り替える(ステップ210)。具体的には、CPU311は、参照したデータ本文で示されるキャラクタのみを上側LCD22に表示する。また、CPU311は、編集する対象となるパーツ(例えば、口、目、体など)を示すアイコンをそれぞれ下側LCD12に表示する。さらに、CPU311は、編集を終了するための終了アイコンも下側LCD12に表示する。
CPU311は、キャラクタの編集画面を表示すると、編集対象となるパーツがユーザによって選択されたか否かを判断する(ステップ220)。具体的には、CPU311は、下側LCD12に表示されているアイコンのいずれにタッチされたか否かを判断する。CPU311は、編集対象となるパーツが選択されたと判断した場合(ステップ220でYes)、選択されたパーツの候補をそれぞれ示すアイコンが下側LCD12に表示されるように表示を切り替える(ステップ225)。CPU311が、ステップ225の処理をすることによりパーツの候補選択画面が下側LCD12に表示される。ここで、編集対象のパーツの候補とは、例えば、編集対象が目のパーツであれば、丸目、細目および切れ長の目などが当該候補となる。また、パーツの候補選択画面の一例は、図5に示すような画面であってもよい。図5は、口のパーツの候補選択画面の一例を示している。
CPU311は、編集対象として選択されたパーツの候補を示すアイコンをそれぞれ表示すると、ユーザによっていずれの候補が選択されたか否かを判断する(ステップ230)。具体的には、CPU311は、下側LCD12に表示されているアイコンのいずれにタッチされたか否かを判断する。CPU311は、候補が選択されていないと判断した場合(ステップ230でNo)、候補が選択されるまでステップ230の処理を繰り返して待機する。一方、CPU311は、候補が選択されたと判断した場合(ステップ230でYes)、選択された候補を登録する(ステップ235)。なお、選択されたパーツの候補を登録するとき、CPU311は、編集対象のデータ本文の内、編集対象のパーツを示す箇所を選択された候補のパーツを示すように更新して登録する。
CPU311は、選択された候補を登録すると、上述したキャラクタの編集画面を再び表示する(ステップ237)。具体的には、CPU311は、上側LCD22に表示されているキャラクタのパーツの中で編集対象として選択されたパーツを、登録した候補のパーツに切り替えて表示する。また、CPU311は、下側LCD12に表示されていたパーツの候補をそれぞれ示すアイコンを消去し、上述したキャラクタの編集画面に表示を切り替える。
CPU311は、キャラクタの編集画面に表示を切り替えると、ユーザによってパーツ選択の終了が選択されたか否かを判断する(ステップ240)。具体的には、CPU311は、下側LCD12に表示されている終了のアイコンにタッチされたか否かを判断する。CPU311は、パーツ選択の終了が選択されていないと判断した場合(ステップ240でNo)、ステップ220から処理を繰り返して、編集対象となるパーツを再びユーザに選択させる。
一方、CPU311は、パーツ選択の終了が選択されたと判断した場合(ステップ240でYes)、次にキャラクタ情報を入力する画面に表示を切り替えて編集対象のキャラクタ情報の入力をユーザから受け付ける処理を開始する(ステップ245)。ここで、キャラクタ情報とは、例えば、キャラクタの名前、性別、年齢および当該キャラクタを紹介するコメントなどの情報である。CPU311は、キャラクタ情報の入力の受け付けを開始すると、キャラクタ情報の入力を受け付けながら、キャラクタ情報の入力の完了がユーザによって選択されたか否かを判断する(ステップ250)。CPU311は、キャラクタ情報の入力の完了が選択されていないと判断した場合(ステップ250でNo)、キャラクタ情報の入力の中止がユーザによって選択されたか否かを判断する(ステップ270)。CPU311は、キャラクタ情報の入力の中止が選択されていないと判断した場合(ステップS270でNo)、ステップ250に処理を戻す。
一方、CPU311は、キャラクタ情報の入力の完了が選択されたと判断した場合(ステップ250でYes)、編集対象のキャラクタが新規に作成されたキャラクタか否かを判断する(ステップ255)。具体的には、CPU311は、メインメモリ32に格納されている変更フラグHfを参照する。変更フラグHfがオフである場合、CPU311は、編集対象となっているキャラクタが新規に作成されたキャラクタであると判断する(ステップ255でYes)。一方、CPU311は、変更フラグHfがオンである場合、CPU311は、編集対象となっているキャラクタが既存のキャラクタであると判断する(ステップ255でNo)。
CPU311は、新規に作成されたキャラクタであると判断した場合(ステップ255でYes)、ユーザ作成データUdのユーザIDに作成者IDを付与する(ステップ260)。一方、CPU311は、新規に作成されたキャラクタでないと判断した場合(ステップ255でNo)、編集対象となっているキャラクタが変更された既存のキャラクタであると判断して、ユーザ作成データUdのユーザIDに変更者IDを追加する(ステップ265)。
CPU311は、ユーザ作成データUdに作成者IDを付与する(ステップ260)またはユーザ作成データUdに変更者IDを追加する(ステップ265)と、メインメモリ32に格納されている変更フラグHfをオフに更新して(ステップ275)、キャラクタ作成処理を終了する。また、CPU311は、ユーザによってキャラクタ情報の入力の中止が選択されたと判断したときにも(ステップ270でYes)、変更フラグHfをオフに更新して(ステップ275)、キャラクタ編集処理を終了する。なお、CPU311が、キャラクタ編集処理を終了するときには、上述したキャラクタ取り扱い画面に表示を切り替える。
以上が、本実施例におけるキャラクタ編集処理の説明である。本実施例では、CPU311が上述したキャラクタ編集処理を行うことによりユーザは自由にキャラクタを作成・編集でき、ユーザ作成データUdを生成することができる。
図8Aに戻り、CPU311は、キャラクタの変更がユーザによって選択されなかったと判断した場合(ステップ130でNo)、キャラクタのLBLへの登録が選択されたか否かを判断する(ステップ145)。CPU311は、キャラクタのLBLへの登録がユーザによって選択されたと判断した場合(ステップ145でYes)、LBL登録処理を開始する(ステップ150)。以下、図8Eを参照して、上記ステップ150で行うLBL登録処理の詳細について説明する。
[LBL登録処理]
図8Eにおいて、CPU311は、メインメモリ32に格納されているユーザ作成データUdの内、他のゲーム装置10から受信したキャラクタのみを下側LCD12に表示する(ステップ301)。具体的には、CPU311は、まず、キャラクタ取り扱い画面を消去する。そして、CPU311は、他のゲーム装置10から受信したキャラクタのみを下側LCD12に表示してユーザからのタッチ操作によって選択できるようにする。CPU311は、他のゲーム装置10から受信したキャラクタのみを表示するとき、作成者IDおよび変更者IDの両方が他のゲーム装置10のIDであるユーザ作成データUdで示されるキャラクタのみを表示する。また、CPU311が、LBL登録処理においてキャラクタを表示するときには、当該処理を終了するためのアイコンも下側LCD12に表示する。これにより、LBL登録処理画面が下側LCD12に表示される。
CPU311は、他のゲーム装置10から受信したキャラクタを表示すると、LBLに登録するキャラクタがユーザによって選択されたか否かを判断する(ステップ305)。具体的には、CPU311は、下側LCD12に表示されているいずれかのキャラクタにタッチ操作されたか否かを判断する。
そして、CPU311は、LBLに登録するキャラクタがユーザによって選択されたと判断すると(ステップ305でYes)、まず、選択されたキャラクタを登録するLBLとして変更者LBLがユーザによって選択されたか否かを判断する(ステップ310)。CPU311は変更者LBLが選択されていないと判断したとき(ステップ310でNo)、選択されたキャラクタを登録するLBLとしてデータLBLがユーザによって選択されたか否かを判断する(ステップ325)。
CPU311は、選択されたキャラクタを登録するLBLとしてデータLBLがユーザによって選択されていないと判断したとき(ステップ325でNo)、登録するLBLが選択されなかったものとして、処理をステップ305に戻す。
一方、CPU311は、選択されたキャラクタを登録するLBLとして変更者LBLが選択されたと判断したとき(ステップ310でYes)、当該キャラクタを変更者LBLに登録する。具体的には、CPU311は、選択されたキャラクタを示すユーザ作成データUdに含まれる最後の変更者IDとアプリIDとを含む変更者特定LBLデータを生成して、変更者LBLデータに追加して登録する(ステップ315)。
一方、CPU311は、選択されたキャラクタを登録するLBLとしてデータLBLがユーザによって選択されたと判断したとき(ステップ325でYes)、当該キャラクタをデータLBLに登録する。具体的には、CPU311は、選択されたキャラクタを示すユーザ作成データUdに含まれるデータIDとアプリIDとを含むデータ特定LBLデータを生成して、データLBLデータに追加して登録する(ステップ330)。
CPU311は、変更者LBLにキャラクタを登録(ステップ315)またはデータLBLにキャラクタを登録(ステップ330)すると、登録したキャラクタのサーバ5への通報がユーザによって選択されたか否かを判断する(ステップ340)。
CPU311は、ユーザによって通報が選択されたと判断したとき(ステップ340でYes)、通報するキャラクタを示すユーザ作成データUdをサーバ5に送信するタスクを示すタスクデータTdを生成する(ステップ345)。後述で明らかとなるが、このとき生成されたタスクデータTdで示されるタスクが実行されれば、ユーザが道徳上の観点から不適切と判断したキャラクタを示すユーザ作成データUdがサーバ5に送信され通報される。
一方、CPU311は、通報がユーザによって選択されないと判断したとき(ステップ340でNo)、ステップ305へ処理を戻して、LBLに登録するキャラクタがユーザによって選択されたか否かを再び判断する。また、CPU311は、ステップ345においてタスクデータTdを生成した後も、ステップ305へ処理を戻して、LBLに登録する他のキャラクタがユーザによって選択されたか否かを再び判断する。
一方、CPU311は、LBLに登録するキャラクタが選択されなかったと判断したとき(ステップ305でNo)、ユーザによってLBL登録処理の終了が選択されたか否かを判断する(ステップ350)。CPU311は、LBL登録処理の終了が選択されたと判断したとき(ステップ350でYes)、LBL登録処理を終了する。一方、CPU311は、LBL登録処理の終了が選択されていないと判断したとき、ステップ305へ処理を戻して、LBLに登録するキャラクタがユーザによって選択されたか否かを再び判断する。なお、CPU311が、LBL登録処理を終了するときには、上述したLBL登録処理画面からキャラクタ取り扱い画面に表示が切り替えられる。
以上が、本実施例におけるLBL登録処理の説明である。上述したLBL登録処理によれば、ユーザは、他のゲーム装置10から受信したキャラクタの中で道徳上の観点から好ましくないと感じたキャラクタを登録することができる。より詳細には、LBL登録処理においてユーザは、キャラクタを変更者LBLまたはデータLBLのいずれかに登録できる。そして、ユーザはキャラクタを変更者LBLに登録することにより、当該キャラクタの最後の変更者を道徳上の観点から好ましくないキャラクタを作成したユーザとしてLBLに登録できる。一方、ユーザはキャラクタをデータLBLに登録することにより、当該キャラクタを示すデータを道徳上の観点から好ましくないキャラクタを示すデータとしてLBLに登録できる。
また、上述したLBL登録処理では、ユーザがLBLに登録したキャラクタをサーバ5に通報することもできる。サーバ5に通報されたキャラクタは、後に詳述するサーバ処理によって所定の条件を満たすと判断されたときにGBLに登録される。つまり、LBL登録処理においてキャラクタを通報できるようにすることで、サーバ5は、本システムに含まれる全てのゲーム装置10のユーザの感覚(総意)に基づいてGBLに登録するキャラクタを判断できる。
また、LBLおよびGBLの少なくともいずれか一方に登録されたキャラクタのユーザ作成データUdは、後に詳述するフィルタリング処理によって非表示データに設定される。これにより、ユーザは、道徳上の観点から好ましくないと感じたキャラクタを表示しないようにすることができる。
図8Aに戻り、CPU311は、LBLへの登録が選択されていないと判断した場合(ステップ145でNo)、図8Bにおいて、キャラクタのすれ違い通信における送信がユーザによって選択されたか否かを判断する(ステップ155)。
CPU311は、キャラクタのすれ違い通信における送信が選択されたと判断した場合(ステップ155でYes)、送信するキャラクタの選択をユーザから受け付ける(ステップ157)。CPU311は、送信するキャラクタの選択をユーザから受け付けると、選択されたキャラクタのユーザ作成データUdをすれ違い送信データSdとしてメインメモリ32に格納する(ステップ160)。ここで、上述したすれ違い通信処理について、図8Fを参照して説明する。なお、すれ違い通信処理において行われる全てのデータの送受信は、上述したように、同種のゲーム装置との間で無線通信を行う機能を有するローカル通信モジュール37を用いて行われる。
[すれ違い通信処理]
図8Fにおいて、CPU311は、メインメモリ32を参照して、通信時刻から所定時間が経過したMACアドレス(図示せず)が存在するか否かを判断する(ステップ401)。ここで、通信時刻とは、後述するように送信ボックスデータSbに含まれるデータまたは接続応答を送信したときの時刻である。通信時刻は、送信ボックスデータSbに含まれるデータまたは接続応答を送信したときに送信先のMACアドレスと共にメインメモリ32に格納される。後に明らかとなるが、本実施例では、通信時刻を用いることにより同一の通信先との短期間における重複した通信を防ぐことができる。
CPU311は、所定時間が経過したMACアドレスが格納されていると判断したとき(ステップ401でYes)、当該MACアドレスを通信時刻と共にメインメモリ32から削除する(ステップ405)。一方、CPU311は、所定時間が経過したMACアドレスが格納されていないと判断したとき(ステップ401でNo)またはMACアドレスを削除すると(ステップ405)、接続要求をブロードキャストで送信する(ステップ410)。ここで、接続要求とは、他のゲーム装置10に対してすれ違い通信を要求するために無線で送信される通信フレームである。接続要求には、当該通信フレームが接続要求であることを示す情報、送信元のゲーム装置10のMACアドレス、および送信ボックスデータSbに含まれる全てのデータ(すれ違い送信データSdおよび送信GBLデータSgd)にそれぞれ含まれるアプリIDからなる。
CPU311は、接続要求を送信すると、自身の接続要求に対する接続応答を受信したか否かを、当該接続要求を送信してから所定期間だけ判断する(ステップ415)。ここで、接続応答とは、前述の接続要求を受信した他のゲーム装置10からの応答を示す通信フレームである。接続応答は4つの情報からなる。すなわち、当該通信フレームが接続応答であることを示す情報、接続要求の送信元のMACアドレス、当該接続応答の送信元(他のゲーム装置10)のMACアドレスおよび接続応答の送信元のゲーム装置10に格納されている送信ボックスデータSbに含まれる全てのデータ(すれ違い送信データSdおよび送信GBLデータSgd)にそれぞれ含まれるアプリIDからなる。
CPU311は、自身の接続要求に対する接続応答を受信したか否かを判断するとき、MACアドレスを用いて判断する。より詳細には、CPU311は、接続要求を送信してから所定期間が経過するまでに受信した接続応答に含まれるMACアドレスと自身のゲーム装置10のMACアドレスとが一致するか否かを判断する。CPU311は、両方のMACアドレスが一致すれば、当該MACアドレスを含む接続応答が自身の接続要求に対する接続応答であると判断できる。
CPU311は、自身の接続要求に対する接続応答を受信したと判断した場合(ステップ415でYes)、当該接続応答を送信したゲーム装置10とすれ違い通信をする必要があるか否かを判断する(ステップ420)。具体的には、CPU311は、受信した接続応答に含まれるアプリIDの中に、送信ボックスデータSbに含まれるそれぞれのデータのアプリIDと一致するアプリIDが存在するか否かを判断する。そして、CPU311は、受信した接続応答に含まれるアプリIDの中に、送信ボックスデータSdに含まれるそれぞれのデータのアプリIDと一致するアプリIDが存在する場合、すれ違い通信が必要であると判断する。一方、CPU311は、受信した接続応答に含まれるアプリIDの中に、送信ボックスデータSdに含まれるそれぞれのデータのアプリIDと一致するアプリIDが存在しない場合、すれ違い通信が必要でないと判断する。
CPU311は、すれ違い通信が必要であると判断した場合(ステップ420でYes)、すれ違い通信を開始する。具体的には、CPU311は、ステップ420で一致すると判断したアプリIDを含む全てのデータを、ステップ415で判断した接続応答の送信元に送信する(ステップ425)。
CPU311は、ステップ420で一致すると判断したアプリIDを含む全てのデータを送信すると、送信先のゲーム装置10のMACアドレス(接続応答に含まれていた送信元のMACアドレス)と共に、送信時刻を前述の通信時刻としてメインメモリ32に格納する(ステップ430)。
次に、CPU311は、ステップ425におけるデータの送信先から当該送信先の送信ボックスデータSbに含まれるデータを受信済みであるか否かを受信ボックスデータJbを参照して判断する(ステップ435)。CPU311は、データを受信済みであると判断した場合(ステップ435でYes)、受信ボックスデータJbに含まれるすれ違い受信データJdをフィルタリング対象として後述するフィルタリング処理を行う(ステップ480)。
一方、CPU311は、接続要求を送信した後に接続応答を受信していないと判断した場合(ステップ415でNo)、他のゲーム装置10から接続要求を受信したか否かを判断する(ステップ440)。CPU311は、他のゲーム装置10から接続要求を受信したと判断した場合(ステップ440でYes)、受信した接続要求の送信元に対して接続応答を送信することが可能か否かを判断する(ステップ445)。具体的には、CPU311は、受信した接続要求に含まれている送信元のMACアドレスが通信時刻と共にメインメモリ32に格納されているか否かを判断する。CPU311は、接続要求に含まれているMACアドレスがメインメモリ32に格納されていない場合、短期間に重複した通信をすることにならないので、接続応答を送信することが可能であると判断できる。この理由は、上述したように通信時刻と共にメインメモリ32に格納されているMACアドレスは、当該通信時刻から所定期間が経過すると削除されるためである。
CPU311は、接続応答を送信することが可能であると判断した場合(ステップ445でYes)、ステップ440で受信したと判断した接続要求の送信元とすれ違い通信をする必要があるか否かを判断する(ステップ450)。具体的には、CPU311は、受信した接続要求に含まれるアプリIDの中に、送信ボックスデータSdに含まれるそれぞれのデータのアプリIDと一致するアプリIDが存在するか否かを判断する。そして、CPU311は、受信した接続要求に含まれるアプリIDの中に、送信ボックスデータSdに含まれるそれぞれのデータのアプリIDと一致するアプリIDが存在する場合、すれ違い通信が必要であると判断する。一方、CPU311は、受信した接続要求に含まれるアプリIDの中に、送信ボックスデータSdに含まれるそれぞれのデータのアプリIDと一致するアプリIDが存在しない場合、すれ違い通信が必要でないと判断する。
CPU311は、すれ違い通信が必要であると判断した場合(ステップ450でYes)、ステップ440で受信したと判断した接続要求の送信元に対して接続応答を送信する(ステップ455)。接続応答を送信すると、CPU311は、その送信時刻を通信時刻として、送信先のゲーム装置10のMACアドレス(ステップ440で受信したと判断した接続要求に含まれていた送信元のMACアドレス)と共にメインメモリ32に格納する(ステップ460)。
次に、CPU311は、ステップ455で送信した接続応答の送信先からデータを受信したか否かを判断する(ステップ465)。CPU311は、データを受信したと判断した場合(ステップ465でYes)、受信したデータを受信ボックスデータJb内に格納する(ステップ470)。具体的には、CPU311は、受信したデータの中にすれ違い送信データSdが含まれていれば、すれ違い受信データJdとして受信ボックスデータJbに格納する。また、CPU311は、受信したデータの中に送信GBLデータSgdが含まれていれば、受信GBLデータJgdとして受信ボックスデータJbに格納する。
CPU311は、データを格納すると、当該データの送信元に対してデータを送信済みか否かを判断する(ステップ475)。CPU311は、データを送信済みであると判断すると、後述するフィルタリング処理を実行する(ステップ480)。より詳細には、CPU311は、受信したデータの中にすれ違い送信データSdが含まれていれば、当該すれ違い送信データSdすなわちユーザ作成データUdをフィルタリング対象として、後述するフィルタリング処理をする。なお、CPU311は、ステップ475からフィルタリング処理へ進むときには、ステップ470で格納したすれ違い受信データJdをフィルタリング対象とする。
一方、CPU311は、データを送信済みでないと判断した場合(ステップ475でNo)、前述のステップ425へ処理を進めてデータを送信する。なお、ステップ425の説明では、データの送信先は、ステップ415で判断した接続応答の送信元であるものとした。しかしながら、CPU311が、ステップ475からステップ425へ処理を進めたときに送信するデータの送信先は、ステップ455で送信した接続応答の送信先となる。
また、CPU311は、ステップ435でデータを受信していないと判断したときにも、ステップ465へ処理を進めてデータを受信したか否かを判断する。上述したステップ465の説明では、ステップ455で送信した接続応答の送信先からデータを受信したか否かを判断するものとした。しかしながら、CPU311が、ステップ435からステップ465へ処理を進めたときに判断するデータの送信元は、ステップ425で送信したデータの送信先となる。
一方、CPU311は、データを受信していないと判断した場合(ステップ465でNo)、すれ違い通信処理をはじめから繰り返す。
以上が、本実施例におけるすれ違い通信処理の説明である。上述したように、すれ違い通信処理は、本システムに含まれるゲーム装置10のそれぞれにおいて常に繰り返し実行される。これにより、それぞれのゲーム装置10は互いのローカル通信モジュール37の通信範囲内に位置したときに、すれ違い通信を自動的に実行することができる。そして、互いのゲーム装置10において、同一のアプリケーションで取り扱われるユーザ作成データUdがすれ違い送信データSdとして格納されている場合に互いのデータを自動的に送受信して交換できる。本実施例では、本システムに含まれるそれぞれのゲーム装置10においてユーザ作成データUdを取り扱うアプリケーションとして、キャラクタ取り扱いアプリケーションが実行される。従って、本システムでは、上述したようにすれ違い通信で送信するようにユーザによって選択されたキャラクタをそれぞれのゲーム装置10で自動的に交換することができる。このように交換されたキャラクタを示すデータは、図8Aのステップ101で新たに受信されたすれ違い受信データJdとして判断され、ステップ105においてユーザ作成データUdとして格納される。
また、本システムでは、すれ違い通信で送信GBLデータSgdを互いのゲーム装置10で送受信する。これにより、本システムでは、互いのゲーム装置10に格納されているGBLデータGdをすれ違い通信で自動的に交換することができる。また、すれ違い通信で受信した受信GBLデータJgdは、後述するGBL更新処理において新しいバージョンであると判断されたときに、GBLデータGdとしてメインメモリ32に格納され、更新される。従って、本システムによれば、インターネット通信網3に接続できないゲーム装置10が存在したとしても、すれ違い通信可能な他のゲーム装置10が存在すれば、GBLを新たなGBLに更新することができる。
また、すれ違い通信処理、それぞれ後に詳述するインターネット通信処理またはローカル通信処理で受信したユーザ作成データUdで示されるキャラクタのすれ違い通信における送信がユーザによって選択された場合には、当該ユーザ作成データUdをそのまますれ違い通信において転送できる。
図8Bに戻って、CPU311は、キャラクタのすれ違い通信における送信がユーザによって選択されていないと判断した場合(ステップ155でNo)、キャラクタのインターネット通信網3を用いた受信がユーザによって選択されたか否かを判断する(ステップ165)。CPU311は、キャラクタのインターネット通信網3を用いた受信が選択されたと判断した場合(ステップ165でYes)、キャラクタを示すユーザ作成データUdを受信するための上述したタスクデータTdを生成する(ステップ170)。
一方、CPU311は、キャラクタのインターネット通信網3を用いた受信が選択されていないと判断した場合(ステップ165でNo)、キャラクタのインターネット通信網3を用いた送信がユーザによって選択されたか否かを判断する(ステップ175)。CPU311は、キャラクタのインターネット通信網3を介した送信が選択されたと判断した場合(ステップ175でYes)、送信するキャラクタのユーザによる選択と、送信先の相手を表す情報の入力又は選択とを受け付ける(ステップ177)。ユーザによるキャラクタの選択と、送信先の入力又は選択とを受け付けると、CPU311は、ユーザによって選択されたキャラクタを送信するための上述したタスクデータTdを生成する(ステップ180)。
ここで、CPU311がインターネット通信網3を用いてデータを送受信するためのインターネット通信処理について、図8Gを参照して説明する。なお、インターネット通信処理において行われる全てのデータの送受信は、上述したようにインターネット通信網3を用いて他の機器との間でデータを送受信するための無線通信モジュール36を用いて行われる。
[インターネット通信処理]
図8Gにおいて、CPU311は、メインメモリ32を参照して、次回実行時刻が現在時刻を過ぎているタスクデータTdが存在するか否かを判断する(ステップ501)。CPU311は、次回実行時刻が現在時刻を過ぎているタスクデータTdが存在していると判断した場合(ステップ501でYes)、無線通信モジュール36の通信範囲内に存在する前述のAP2の検出を開始する(ステップ510)。CPU311は、所定時間だけAP2の検出を実行した後、AP2を検出できたか否かを判断する(ステップ515)。CPU311は、AP2を検出できたと判断した場合(ステップ515でYes)、検出したAP2との通信を開始する(ステップ520)。
一方、CPU311は、次回実行時刻が現在時刻を過ぎているタスクデータTdが存在していないと判断したとき(ステップ501でNo)、又は、AP2を検出できなかったと判断したとき(ステップ515でNo)、ステップ501から処理を繰り返す。
次に、CPU311は、AP2との通信を開始すると、ステップ501で判断したタスクデータTdの中から、実行時刻が過ぎているが未だに実行されていない未実行のタスクを示すタスクデータTdを選択する(ステップ525)。CPU311は、未実行のタスクを選択すると、選択した未実行タスクを全て実行したか否かを判断する(ステップ530)。CPU311は、未実行タスクを全て実行していないと判断した場合(ステップ530でNo)、未実行タスクを1つだけ選択する(ステップ535)。CPU311が、全ての未実行タスクの中から1つを選択する手法は、例えば、所定の優先度を用いるなど、任意の手法を用いてかまわない。
CPU311は、未実行タスクを選択すると、選択した未実行タスクが受信タスクであるか否かを判断する(ステップ540)。具体的には、CPU311は、選択した未実行タスクを示すタスクデータTdに含まれる送信/受信識別フラグを参照して、当該フラグが受信を示すか否かを判断する。
CPU311は、選択した未実行タスクが受信タスクであると判断した場合(ステップ540でYes)、当該タスクを示すタスクデータTdに従ってデータを受信する(ステップ545)。具体的には、CPU311は、未実行タスクを示すタスクデータTdに含まれる通信先URLにアクセスして、データを受信する。受信されたデータは、タスクデータTdに含まれる格納先情報で示される格納先に格納される。例えば、配信用GBLデータGsdを受信するためのタスクが実行されたときには、受信された配信用GBLデータGsdが、ネット受信GBLデータNgdとして、メインメモリ32における格納先に格納され更新される。また、例えば、キャラクタを受信するためのタスクが実行されたときには、受信されたキャラクタを示すユーザ作成データUdがメインメモリ32における格納先に格納される。
CPU311は、受信タスクを実行すると、実行したタスクを示すタスクデータTdに含まれる次回実行時刻を上述したように更新する(ステップ550)。
一方、CPU311は、選択した未実行タスクが受信タスクでないと判断した場合(ステップ540でNo)、当該未実行タスクが送信タスクであるとして、当該タスクを示すタスクデータTdに従ってデータを送信する(ステップ555)。具体的には、CPU311は、未実行の送信タスクを示すタスクデータTdに含まれる通信先URLにアクセスして、データを送信する。送信されるデータは、タスクデータTdに含まれる格納先情報で示される格納先に格納されているデータとなる。例えば、キャラクタを送信するためのタスクが実行されたときには、ユーザによって選択されたキャラクタを示すユーザ作成データUdが、キャラクタの送信を受け付けるサーバ5を表すURLへ送信される。また、例えば、通報のためのタスクが実行されたときには、ユーザによって選択された通報するキャラクタを示すユーザ作成データUdがサーバ5へ送信される。
CPU311は、送信タスクを実行すると、実行したタスクを示すタスクデータTdを削除する(ステップ560)。
次に、CPU311は、実行したタスクが、配信用GBLデータGsdを受信するためのタスクまたは任意のデータを送信するためのタスクであったか否かを判断する(ステップ565)。具体的には、CPU311は、実行したタスクを示すタスクデータTdに含まれる送信/受信識別フラグと、格納先情報で示される格納先に格納されているデータとを参照して判断する。CPU311は、実行したタスクが、配信用GBLデータGsdを受信するためのタスクまたは任意のデータを送信するためのタスクではないと判断した場合(ステップ565でNo)、実行したタスクが配信用GBLデータGsd以外のデータの受信であったと判断する。すなわち、CPU311は、実行したタスクがユーザ作成データUdの受信であったと判断する。
CPU311は、実行したタスクがユーザ作成データUdの受信であったと判断すると(ステップ565でYes)、受信したデータをフィルタリング対象として後述するフィルタリング処理を実行する(ステップ570)。一方、CPU311は、実行したタスクが配信用GBLデータGsdを受信するためのタスクまたは任意のデータを送信するためのタスクであると判断した場合(ステップ565でYes)、フィルタリング処理の必要がないと判断し、処理をステップ530へ戻して、残りの未実行タスクがあるか否かを判断する。
一方、CPU311は、選択した未実行タスクを全て実行した(残りの未実行タスクがない)と判断した場合(ステップ530でYes)、インターネット通信処理を始めから繰り返す。
以上が、本実施例におけるインターネット通信処理の説明である。上述したように、インターネット通信処理は、本システムに含まれるゲーム装置10のそれぞれにおいて常に繰り返し実行される。インターネット通信処理では、ユーザ作成データUdを送信するためのタスク、キャラクタを通報するためのタスク、ユーザ作成データUdを受信するためのタスクおよび配信用GBLデータGsdを受信するためのタスクが実行される。そして、これらのタスクの中で送信のためのタスクを示すタスクデータTdは、当該タスクが実行されるまで削除されない。従って、キャラクタを通報するためのタスクは実行されるまで削除されないので、ユーザによって選択されたキャラクタを示すユーザ作成データUdを確実に通報することができる。
また、上述したタスクの中で受信のタスクを示すタスクデータTdは、当該タスクが実行される度に次回実行時刻が更新される。従って、配信用GBLデータGsdを受信するためのタスクは定期的に実行されるので、サーバ5によって管理されているGBLを定期的に受信できる。
また、後に詳述するローカル通信処理、それぞれ上述したすれ違い通信処理またはインターネット通信処理で受信したユーザ作成データUdで示されるキャラクタのインターネット通信網3を用いた送信がユーザによって選択された場合には、当該ユーザ作成データUdをそのままインターネット通信網3を介して転送できる。
図8Bに戻って、CPU311は、キャラクタのインターネット通信網3を用いた送信が選択されていないと判断した場合(ステップ175でNo)、キャラクタのローカル通信での送信がユーザによって選択されたか否かを判断する(ステップ185)。CPU311は、キャラクタのローカル通信での送信が選択されたと判断した場合(ステップ185でYes)、送信するキャラクタのユーザによる選択を受け付ける(ステップ187)。CPU311は、送信するキャラクタの選択を受け付けると、ローカル通信処理を実行する(ステップ190)。
なお、ローカル通信処理において行われる全てのデータの送受信は、上述したように、同種のゲーム装置との間で無線通信を行う機能を有するローカル通信モジュール37を用いて行われる。
[ローカル通信処理]
図8Hにおいて、CPU311は、キャラクタ取り扱い画面を消去し、通信範囲内に存在する他のゲーム装置10を検出中であることを示す画像を下側LCD12に表示する(ステップ601)。検出中であることを示す画像を表示すると、CPU311は、ローカル通信モジュール37の通信範囲内に存在する他のゲーム装置10の検出を開始する(ステップ603)。CPU311は、所定時間だけ他のゲーム装置10の検出を実行した後、検出中であることを示す画像を消去して、他のゲーム装置10を検出できたか否かを判断する(ステップ605)。CPU311は、他のゲーム装置10を検出できたと判断すると(ステップ605でYes)、検出したゲーム装置10を下側LCD12に検出結果として一覧表示する(ステップ610)。CPU311は、検出結果を表示すると、表示した検出結果の中から通信先がユーザによって選択されたか否かを判断する(ステップ615)。具体的には、検出結果の一覧のいずれかにタッチ操作されたか否かを判断する。
CPU311は、ユーザによって通信先のゲーム装置10が選択されたと判断した場合(ステップ615でYes)、当該通信先のゲーム装置10によって自身のゲーム装置10が通信先として選択されたか否かを当該通信先から送信される情報に基づいて判断する(ステップ620)。CPU311は、通信先によって自身のゲーム装置10が選択されたと判断した場合(ステップ620でYes)、ステップ187で選択されたキャラクタのユーザ作成データUdを当該通信先に送信する(ステップ625)。そして、CPU311は、自身のゲーム装置10からのユーザ作成データUdの送信に応じて送信される通信先からのユーザ作成データUdを受信する(ステップ630)。CPU311は、通信先からユーザ作成データUdを受信すると、受信したユーザ作成データUdをフィルタリング対象として、後述するフィルタリング処理を実行する(ステップ635)。CPU311は、フィルタリング処理を実行した後、受信したユーザ作成データUdをメインメモリ32に格納する。
一方、CPU311は、通信先を発見できなかった(ステップ605でNo)、ユーザによって通信先が選択されなかった(ステップ615でNo)あるいは通信先によって自身のゲーム装置10が選択されなかった(ステップ620でNo)場合、データを受信できないのでフィルタリング処理をすることなく、ローカル通信処理を終了する。
以上が、本実施例におけるローカル通信処理の説明である。上述の説明から明らかなように、ローカル通信処理は、ユーザからの操作に応じて即座に実行される。これにより、ユーザは、すれ違い通信による自動的なデータの送受信のみに頼ることなく、自らの意志でユーザ作成データUdを他のゲーム装置10と交換することができる。
また、それぞれ上述したすれ違い通信処理、インターネット通信処理またはローカル通信処理で受信したユーザ作成データUdで示されるキャラクタのローカル通信での送信がユーザによって選択された場合には、当該ユーザ作成データUdをそのままローカル通信において転送できる。
図8Bに戻り、CPU311は、ユーザ作成データUdのローカル通信での送信がユーザによって選択されていないと判断した場合(ステップ185でNo)、キャラクタ取り扱い処理において必要な他の各種処理を実行する(ステップ195)。キャラクタ取り扱い処理において必要な他の各処理とは、例えば、上側LCD22に表示されているキャラクタの動作を制御する処理などである。
CPU311は、ユーザ作成データ生成処理(図8Aのステップ140)、LBL登録処理(ステップ150)、すれ違い通信で送信するユーザ作成データUdを格納する処理(図8Bのステップ160)、インターネット通信処理での送信が選択されたときにおけるタスクを生成する処理(ステップ170、ステップ180)、ローカル通信処理(ステップ190)および前述の各種処理(ステップ195)のいずれかを実行すると、キャラクタ取り扱い処理を終了する選択がユーザによってされたか否かを判断する(ステップ200)。CPU311は、キャラクタ作成処理を終了する選択がユーザによってされていないと判断した場合(ステップ200でNo)、ステップ115に処理を戻す。上述したように、ステップ115では、メインメモリ32に格納されている全てのユーザ作成データUdをフィルタリング対象としてフィルタリング処理が実行される。一方、キャラクタ取り扱い処理を終了する選択がなされた場合(ステップ200でYes)、キャラクタ取り扱い処理を終了し、上述のランチャーアプリケーションに戻る。
以上が、本実施例におけるキャラクタ取り扱い処理の説明である。
[フィルタリング処理]
次に、図8Iを参照して、本実施例におけるフィルタリング処理について説明する。図8Iにおいて、CPU311は、フィルタリング対象となっているユーザ作成データUdの中から変更者LBLデータを構成するそれぞれの変更者特定LBLデータに含まれるアプリIDと変更者IDとが一致するユーザ作成データUdが存在するか否かを判断する(ステップ701)。
CPU311は、フィルタリング対象となっているユーザ作成データUdの中に、変更者LBLデータを構成するそれぞれの変更者特定LBLデータに含まれるアプリIDと変更者IDとが一致するユーザ作成データUdが存在すると判断した場合(ステップ701でYes)、当該ユーザ作成データUdを非表示データに設定する(ステップ705)。
これにより、CPU311は、フィルタリング対象となっているユーザ作成データUdを最後に変更した変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであることを判断できる。また、CPU311は、フィルタリング対象となっているユーザ作成データUdの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザである場合に、当該キャラクタを表示する前に非表示データとして設定できる。また、変更者LBLデータは、上述したようにLBL登録処理において自身のゲーム装置10のユーザによる選択に応じてデータが登録される。従って、CPU311は変更者LBLデータに基づいて非表示データを設定することにより、自身のゲーム装置10のユーザが自ら登録したデータを表示しないように設定できる。
一方、CPU311は、フィルタリング対象となっているユーザ作成データUdの中から変更者LBLデータを構成するそれぞれの変更者特定LBLデータに含まれるアプリIDと変更者IDとが一致するユーザ作成データUdが存在しないと判断した場合(ステップ701でNo)または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データUdの中から、データLBLデータを構成するそれぞれのデータ特定LBLデータに含まれるアプリIDとデータIDとが一致するユーザ作成データUdが存在するか否かを判断する(ステップ710)。
CPU311は、フィルタリング対象となっているユーザ作成データUdの中からデータLBLデータを構成するそれぞれのデータ特定LBLデータに含まれるアプリIDとデータIDとが一致するユーザ作成データUdが存在すると判断した場合(ステップ710でYes)、当該ユーザ作成データUdを非表示データに設定する(ステップ715)。
これにより、CPU311は、キャラクタが道徳上の観点から好ましくないキャラクタであることをデータLBLに基づいて判断できる。そして、CPU311は、ユーザ作成データUdによって示されるキャラクタに基づいて当該キャラクタを表示しないように設定できる。また、データLBLデータは、上述したようにLBL登録処理においてCPU311自身のゲーム装置10のユーザによる選択に応じてデータが登録される。従って、CPU311は、データLBLデータに基づいて非表示データを設定することにより、自身のゲーム装置10のユーザが自ら登録したデータを表示しないように設定できる。
一方、CPU311は、フィルタリング対象となっているユーザ作成データUdの中からデータLBLデータを構成するそれぞれのデータ特定LBLデータに含まれるアプリIDとデータIDとが一致するユーザ作成データUdが存在しないと判断した場合(ステップ710でNo)または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データUdの中から、変更者GBLデータを構成するそれぞれの変更者特定GBLデータに含まれるアプリIDと変更者IDとが一致するユーザ作成データUdが存在するか否かを判断する(ステップ720)。
CPU311は、フィルタリング対象となっているユーザ作成データUdの中から変更者GBLデータを構成するそれぞれの変更者特定GBLデータに含まれるアプリIDとユーザIDとが一致するユーザ作成データUdが存在すると判断した場合(ステップ720でYes)、当該ユーザ作成データUdを非表示データに設定する(ステップ725)。
これにより、CPU311は、キャラクタを最後に変更した変更者は道徳上の観点から好ましくないキャラクタを作成する変更者であることを変更者GBLに基づいて判断できる。そして、CPU311は、キャラクタの外見に関わらずに最後の変更者に基づいて当該キャラクタを表示しないように設定できる。また、変更者GBLはサーバ5によって管理されるGBLである。そして、後述するように、サーバ5は本システムに含まれる全てのゲーム装置10のユーザそれぞれからの通報回数に基づいて変更者GBLを管理する。サーバ5が通報を受けるのは、上述したようにユーザが道徳上の観点から好ましくないと判断しさらに通報する選択をしたときである。従って、CPU311は、変更者GBLを用いて非表示データを判断することにより、本システムに含まれるゲーム装置10の全てのユーザの総意による判断に基づいて非表示データを設定できる。
一方、CPU311は、フィルタリング対象となっているユーザ作成データUdの中に、変更者GBLデータを構成するそれぞれの変更者特定GBLデータに含まれるアプリIDと変更者IDとが一致するユーザ作成データUdが存在しないと判断した場合(ステップ720でNo)または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データUdの中に、データGBLデータを構成するそれぞれのデータ特定GBLデータに含まれるアプリIDとデータIDとが一致するユーザ作成データUdが存在するか否かを判断する(ステップ730)。
CPU311は、フィルタリング対象となっているユーザ作成データUdの中に、データGBLデータを構成するそれぞれのデータ特定GBLデータに含まれるアプリIDとデータIDとが一致するユーザ作成データUdが存在すると判断した場合(ステップ730でYes)当該ユーザ作成データUdを非表示データに設定する(ステップ735)。
これにより、CPU311は、キャラクタが道徳上の観点から好ましくないキャラクタであることをデータGBLに基づいて判断できる。そして、CPU311は、ユーザ作成データUdによって示されるキャラクタに基づいて当該キャラクタを表示しないように設定できる。また、データGBLはサーバ5によって管理されるGBLである。そして、後述するように、サーバ5は本システムに含まれる全てのゲーム装置10のユーザそれぞれからの通報回数に基づいてデータGBLを管理する。サーバ5が通報を受けるのは、上述したようにユーザが道徳上の観点から好ましくないと判断しさらに通報する選択をしたときである。従って、CPU311は、データGBLを用いて非表示データを判断することにより、本システムに含まれるゲーム装置10の全てのユーザの総意に基づいて非表示データを設定できる。
一方、CPU311は、フィルタリング対象となっているユーザ作成データUdの中に、データGBLデータを構成するそれぞれのデータ特定GBLデータに含まれるアプリIDとデータIDとが一致するユーザ作成データUdが存在しないと判断した場合(ステップ730でNo)または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データUdの中に、アプリIDがNullとなっている変更者特定GBLデータの変更者IDと一致する変更者IDのユーザ作成データUdが含まれているか否かを判断する(ステップ740)。
CPU311は、アプリIDがNullとなっている変更者特定GBLデータのユーザIDと一致する変更者IDのユーザ作成データUdが含まれていると判断したとき(ステップ740でYes)、当該ユーザ作成データUdを非表示データに設定する(ステップ745)。CPU311は、アプリIDがNullとなっている変更者特定GBLデータの変更者IDと一致する変更者IDのユーザ作成データUdが含まれてないと判断した場合(ステップ740でNo)または非表示データを設定した場合、フィルタリング処理を終了する。
以上が、本実施例におけるフィルタリング処理の説明である。
[GBL更新処理]
次に、図8Jを参照して、本実施例におけるGBL更新処理を説明する。図8Jにおいて、CPU311は、受信ボックスデータJbの中に新たに受信した受信GBLデータJgd(新着GBL)が格納されているか否かを判断する(ステップ801)。CPU311は、新たな受信GBLデータJgdが格納されていると判断した場合(ステップ801でYes)、当該受信GBLデータJgdで示されるGBLが新しいバージョンのGBLであるか否かを判断する(ステップ805)。具体的には、CPU311は、受信GBLデータJgdで示されるGBLのバージョンと、メインメモリ32に既に格納しているGBLデータGdで示されるGBLのバージョンとを比較する。
CPU311は、受信GBLデータJgdで示されるGBLが新しいバージョンのGBLであると判断した場合(ステップ805でYes)、当該受信GBLデータJgdで示されるGBLでメインメモリ32に格納されているGBLデータGdを更新する(ステップ810)。そして、CPU311は、更新したGBLデータGdを送信GBLデータSgdとして送信ボックスデータSdに格納する(ステップ815)。これにより、すれ違い通信によって受信した最新のGBLをすれ違い通信によってさらに他のゲーム装置10へ送ることができる。次に、CPU311は、送信GBLデータSgdを格納すると、受信ボックスデータJbに格納されている受信GBLデータJgdを削除する(ステップ820)。
一方、CPU311は、新たな受信GBLデータJgdが格納されていない場合(ステップ801でNo)、受信GBLデータJgdで示されるGBLが新しいバージョンでない場合(ステップ805でNo)、または受信GBLデータSgdを削除したとき、インターネット通信処理でGBLを受信したか否かを判断する(ステップ825)。具体的には、CPU311は、メインメモリ32にネット受信GBLデータNgdが格納されているか否かを判断する。
CPU311は、インターネット通信処理でGBLを受信したと判断した場合(ステップ825でYes)、受信したネット受信GBLデータNgdで示されるGBLが新しいバージョンであるか否かを判断する(ステップ830)。具体的には、CPU311は、メインメモリ32に格納されているネット受信GBLデータNgdで示されるGBLのバージョンと、メインメモリ32に既に格納されていたGBLデータGdで示されるGBLのバージョンとを比較する。
CPU311は、ネット受信GBLデータNgdで示されるGBLが新しいバージョンであると判断したとき(ステップ830でYes)、当該GBLを示すようにメインメモリ32に格納されているGBLデータGdを更新する(ステップ835)。そして、CPU311は、更新したGBLデータGdを送信GBLデータSgdとして送信ボックスデータSdに格納する(ステップ840)。これにより、インターネット通信処理で受信した最新のGBLをすれ違い通信によって他のゲーム装置10へ送ることができる。CPU311は、GBLを更新すると、ネット受信GBLデータNgdを削除する(ステップ845)。
一方、CPU311は、インターネット通信処理でGBLを受信していないと判断した場合(ステップ825でNo)、ネット受信GBLデータNgdで示されるGBLが新しいバージョンでないと判断した場合(ステップ830でNo)、またはネット受信GBLデータNgdを削除したとき、GBL更新処理をはじめから繰り返す。
以上が、本実施例におけるGBL更新処理の説明である。上述で説明したように、CPU311は、他の処理を実行しているか否かに関わらず、GBL更新処理を繰り返し実行する。これにより、CPU311は、すれ違い通信処理で受信GBLデータJgdを格納したときまたはインターネット通信処理でネット受信GBLデータNgdを格納したときに、新しいバージョンのGBLを示すか否かを常に確認できる。そして、CPU311は、新しいバージョンのGBLを示すデータを受信したときには、即座にGBLデータGdを更新して、常に最新のバージョンのGBLを記憶しておくことができる。また、CPU311は、すれ違い通信で受信した受信GBLデータJgdによって示されるGBLや、インターネット通信で受信したネット受信GBLデータNgdが新しいバージョンである場合には、当該受信GBLデータJgdを送信GBLデータSgdとして格納する。従って、CPU311は、新しいバージョンのGBLを即座にすれ違い通信で他のゲーム装置10に自動的に送信できる。
[サーバ処理]
次に、図9を参照して、サーバ5で実行されるプログラムによる具体的な処理について説明する。なお、図9は、サーバ処理プログラムを実行することによってサーバ5がサーバ処理を行う一例を示すフローチャートである。なお、この処理を実行するためのプログラムは、HDD54に格納されており、サーバ5の電源がオンになったときに、通信バス56を介してHDD54からメインメモリ55に読み出されて、CPU51によって実行される。
図9において、CPU51は、ユーザによって通報されたユーザ作成データUdを受信したか否かを判断する(ステップ901)。CPU51は、通報されたユーザ作成データUdを受信したと判断した場合(ステップ901でYes)、受信したユーザ作成データUdに含まれるデータIDとアプリIDとからなるデータカウントデータがHDD54に既に格納されているか否かを判断する(ステップ903)。CPU51は、データカウントデータが格納されていないと判断したとき(ステップ903でNo)、受信したユーザ作成データUdに含まれるデータIDとアプリIDとからなるデータカウントデータを新規に作成してメインメモリ55に格納する(ステップ904)。このとき作成されるデータカウントデータに含まれる通報回数の初期値は1となる。
一方、CPU51は、データカウントデータが格納されていると判断したとき(ステップ903でYes)、当該データカウントデータの通報回数を1だけ加算してカウントする(ステップ905)。
次に、CPU51は、メインメモリ55に格納されている全てのデータカウントデータの中に通報回数が第1の閾値th1以上であるデータカウントデータが存在するか否かを判断する(ステップ910)。これにより、CPU51は、本システムに含まれる全てのユーザそれぞれからの通報回数に基づいて、通報されたユーザ作成データUdによって示されるキャラクタが道徳上の観点から好ましくないキャラクタであるか否かを判断できる。なお、今回新規作成又はカウントを行ったデータカウントデータについてのみ、ステップ910の判断を行うようにしてもよい。
CPU51は、通報回数が第1の閾値th1以上であるデータカウントデータが存在すると判断した場合(ステップ910でYes)、データ特定GBLデータを配信用GBLデータGsdに追加する(ステップ915)。このとき、配信用GBLデータGsdに追加されるのは、通報回数が第1の閾値th1以上となるデータカウントデータのそれぞれに含まれるデータIDとアプリIDとをそれぞれ含むデータ特定GBLデータである。これにより、CPU51は、ユーザ作成データUdの中から道徳上の観点から好ましくないキャラクタを示すデータを特定するためのデータ特定用GBLデータを配信用GBLデータGsdに追加することができる。
次に、CPU51は、ユーザによって通報されたユーザ作成データUdに含まれるユーザIDとアプリIDとからなるユーザカウントデータがHDD54に格納されているか否かを判断する(ステップ917)。CPU51は、ユーザカウントデータが格納されていないと判断したとき(ステップ917でNo)、受信したユーザ作成データUdに含まれる変更者IDとアプリIDとからなるユーザカウントデータを新規に作成してHDD54に格納する(ステップ919)。このとき作成されるユーザカウントデータに含まれる通報回数の初期値は1となる。
一方、CPU51は、ユーザカウントデータが格納されていると判断したとき(ステップ917でYes)、当該データカウントデータの通報回数を1だけ加算してカウントする(ステップ920)。
次に、CPU51は、メインメモリ55に格納されている全てのユーザカウントデータの中に通報回数が第2の閾値th2以上のユーザカウントデータが存在するか否かを判断する(ステップ925)。これにより、CPU51は、本システムに含まれる全てのユーザそれぞれからの通報回数に基づいて、通報されたユーザ作成データUdの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるか否かを判断できる。なお、今回新規作成又はカウントを行ったデータカウントデータについてのみ、ステップ925の判断を行うようにしてもよい。
CPU51は、通報回数が第2の閾値th2以上のユーザカウントデータが存在すると判断した場合(ステップ925でYes)、ユーザ特定GBLデータを配信用GBLデータGsdに追加する(ステップ930)。このとき、配信用GBLデータGsdに追加されるのは、通報回数が第2の閾値th2以上となるユーザカウントデータのそれぞれに含まれる変更者IDとアプリIDとをそれぞれ含むユーザ特定GBLデータである。これにより、CPU51は、ユーザ作成データUdの中から最後の変更者を道徳上の観点から好ましくないキャラクタを作成するユーザとして示すデータを特定するための変更者特定用GBLデータを配信用GBLデータGsdに追加することができる。
CPU51は、ユーザ特定GBLデータを追加する(ステップ930)または第2の閾値th2以上のユーザカウントデータがないと判断した場合(ステップ925でNo)、サーバ処理をはじめから繰り返す。
なお、図9のフローチャートには図示していないが、CPU51は、配信用GBLデータGsdを本システムに含まれるゲーム装置10のそれぞれに送信する処理を並行して行っているものとする。当該処理は、本システムに含まれるゲーム装置10のそれぞれによって配信用GBLデータGsdを受信するタスクが実行されたことに応じて実行されるものとする。
次に、上述で説明したサーバ処理において用いられる第1の閾値th1および第2の閾値th2について説明する。第2の閾値th2は、第1の閾値th1よりも大きくなるように予め定められるものとする。上述の説明から明らかなように、CPU51は、ユーザ作成データUdが通報される度に、当該ユーザ作成データUdに対応するユーザカウントデータの通報回数と、当該ユーザ作成データUdに対応するデータカウントデータの通報回数とがそれぞれ加算される。
そして、データIDとアプリIDとを含むデータカウントデータで示される通報回数は最も低い第1の閾値th1と比較され、変更者IDとアプリIDとを含むユーザカウントデータで示される通報回数は第1の閾値th1よりも大きい第2の閾値th2と比較される。
ここで、本システムにおいて、同一のデータIDとアプリIDとを含むユーザ作成データUdの通報と同一の変更者IDとアプリIDとを含むユーザ作成データUdの通報とがそれぞれ繰り返された場合を想定する。この場合、本システムでは、まず始めに、データカウントデータで示される通報回数が第1の閾値th1以上となる。そして、ユーザ作成データUdで示されるキャラクタに基づいてゲーム装置10が非表示データを設定できるように、データ特定GBLデータが先に配信用GBLデータGsdに追加される。
そして、さらに、同一のデータIDとアプリIDとを含むユーザ作成データUdの通報と同一の変更者IDとアプリIDとを含むユーザ作成データUdの通報とがそれぞれ続けて繰り返された場合を想定する。この場合、本システムでは、データカウントデータの通報回数が第1の閾値th1以上となった後に、ユーザカウントデータの通報回数が第2の閾値th2以上となる。従って、本システムでは、ユーザ作成データUdで示されるキャラクタに基づいてゲーム装置10によって非表示データが設定されるようになった後、ユーザ作成データUdで示される最後の変更者IDに基づいて非表示データを設定できるように、変更者特定GBLデータが配信用GBLデータGsdに追加される。
ユーザ特定GBLデータの変更者IDで示されるユーザは、当該ユーザ特定GBLデータに含まれるアプリIDで示されるキャラクタ取り扱いアプリケーションで取り扱われるユーザ作成データUdを送受信しても他のゲーム装置10にはキャラクタが表示されなくなる。従って、ユーザ作成データUdの最後の変更者IDがアプリIDと共に変更者特定GBLデータとして追加されると当該変更者IDのユーザは当該アプリIDで示されるアプリケーションによって提供される楽しみを奪われてしまう。このような状況は、アプリケーションの製造元としてもなるべく避けたいので、上述で説明したサーバ処理では、通報回数が第1の閾値th1よりも大きい第2の閾値th2以上となったときにユーザ作成データUdで示される最後の変更者IDが当該ユーザ作成データUdのアプリIDと共に変更者特定GBLデータとして登録される。
以上が、本実施例におけるサーバ処理の説明である。上述したサーバ処理によれば、CPU51は、本システムに含まれるゲーム装置10のそれぞれからの通報に基づいて、配信用GBLデータGsdで示される情報を最新の情報に常に更新できる。
以上が、本システムの説明である。本システムによれば、当該システムに含まれるそれぞれのゲーム装置10において互いに送受信されるユーザ作成データUdで示されるキャラクタの中から道徳上の観点から好ましくないキャラクタが出力されてユーザに表示されることを防げる。例えば、上述したキャラクタ取り扱い画面において上側LCD22に道徳上の観点から好ましくないキャラクタが表示されるのを防げる。また、例えば、上述したキャラクタ編集画面において上側LCD22に1つだけ表示されるキャラクタとして道徳上の観点から好ましくないキャラクタが表示されるのを防げる。
なお、上述の説明では、ユーザ作成データUdを取り扱うアプリケーションとして、キャラクタ取り扱いアプリケーションを一例に挙げて説明した。本システムにおけるアプリケーションの他の一例としては、ユーザが自由に楽曲を作成することができる楽曲作成プログラムが挙げられる。この場合、ユーザによって作成された楽曲を示すデータがユーザ作成データUdとなる。また、この場合、ユーザ作成データUdに含まれるアプリIDは、楽曲作成アプリケーションを示すアプリIDとなる。また、この場合、ユーザ作成データUdに含まれるデータ本文は楽曲の内容を示すデータ本文となる。また、本システムにおけるアプリケーションの他の一例としては、マイク43を用いて入力した音声などを用いて作成したユーザ作成データUdを取り扱うアプリケーションも挙げられる。
つまり、本システムでは、キャラクタなどの表示オブジェクト、楽曲および音声などの任意のアプリケーションを用いて作成される任意の内容(コンテンツ)を示すユーザ作成データUdを対象とすることができる。これにより、本システムでは、表示オブジェクトなど表示装置に表示出力されることによってユーザに提供されるコンテンツ、楽曲および音声などスピーカ44を用いて音声出力されることによってユーザに提供されるコンテンツなどの中からユーザにとって不適切なコンテンツを提供すべきでないコンテンツとしてGBLおよびLBLの少なくとも一方を用いて特定できる。
その他、ユーザ作成データUdの例としては、タッチパネル13への入力により手書きでなされたメッセージや、タッチパネル13、操作ボタン14又はキーボードなどの周辺機器により入力された、任意の文字列データなどを挙げることができる。また、アプリケーションプログラムのセキュリティホール等を狙って、アプリケーションプログラムの動作を停止させたり、アプリケーションプログラムの異常動作を引き起こしたりするようなユーザ作成データUdを対象とすることで、アプリケーションプログラムの停止や異常動作を未然に防ぐことができる。
また、上述の説明では、作成者ID、変更者ID、アプリIDおよびデータIDなどを、データ本文(コンテンツ)の作成時に関連する情報(以下、作成情報と称する)、または、当該コンテンツに関連する情報(以下、コンテンツ情報と称する)として当該コンテンツを含むユーザ作成データUdに付与する場合を一例として説明した。そして、GBLデータGdおよびLBLデータLdには、作成情報またはコンテンツ情報に含まれる作成者ID、変更者ID、アプリIDおよびデータIDの中から作成者IDと変更者IDとの組み合わせを除く少なくとも2つのIDを追加するものとした。この場合、ゲーム装置10では、上述で説明したように、GBLデータGdまたはLBLデータLdに前述の2つのIDが含まれていれば、一致するIDを含むユーザ作成データUdに含まれるコンテンツがユーザに提供すべきでないコンテンツとして特定されることとなる。
また、上述の説明では、すれ違い通信においてGBLが送信GBLデータSgd或いは受信GBLデータJgdとして送受信して交換される場合を一例として説明した。しかしながら、他の一実施形態では、LBLもGBLと同様にすれ違い通信で交換してもよい。
また、上述の説明では、ユーザが通報するときには通報するユーザ作成データUdを送信するものとした。しかしながら、他の一実施形態では、ユーザ作成データUdに付与されている作成者ID、変更者ID、アプリIDおよびデータIDの中から任意の組み合わせのIDを送信してもよい。そして、サーバ5のCPU51は、送信されたIDを用いて上述したデータカウントデータおよびユーザカウントデータもしくは、当該データカウントデータおよび当該ユーザカウントデータにおける組み合わせとは異なる組み合わせのIDで通報回数をカウントするためのカウントデータを用いて通報回数をカウントしてもよい。
また、上述の説明では、ゲーム装置10は、配信用GBLデータGsdを受信するためのタスクを定期的に実行して受信する場合を一例として説明した。しかしながら、他の一実施形態では、サーバ5のCPU51が、通信可能なゲーム装置10に定期的に配信用GBLデータGsdを送信するようにしてもよい。
また、上述の説明では、上述したコンテンツの一例としてキャラクタが道徳上の観点から好ましくない場合に表示されないように設定する場合を説明した。しかしながら、他の一実施形態では、道徳上の観点から好ましくない不適切でユーザに提供するべきでないコンテンツを提供することのできる所定のコンテンツに置き換えることによって不適切なコンテンツをユーザに提供しないようにしてもよい。さらに、他の一実施形態では、不適切なコンテンツを含むユーザ作成データUdを削除するようにしてもよい。
また、上述の説明では、GBLのバージョンを比較するために、配信用GBLデータGsdをネット受信GBLデータNgdとしてメインメモリ32に格納した後、新しいバージョンであるときにGBLデータGdを更新するものとした。しかしながら、他の一実施形態では、配信用GBLデータGsdでメインメモリ32に格納されているGBLデータGdを直接更新してもよい。これにより、配信用GBLデータGsdが常に最新のバージョンのGBLを示すデータとしてメインメモリ32に格納されているGBLデータGdを更新できる。
また、上述の説明では、すれ違い通信およびローカル通信が、同じローカル通信モジュール37を用いて行われるものとした。ここで、すれ違い通信処理による通信とローカル通信処理による通信とが同時に発生する場合には、互いの処理を時分割で行う、或いは互いの処理で送受信するデータを時分割するなどの手法を用いることにより、両方の通信の両立が可能である。
また、上述の説明では、ユーザ作成データUdに含まれるデータIDがデータ本文をアプリケーション毎に一意に識別するためのIDであるものとした。しかしながら、他の一実施形態では、データIDは、アプリケーションに関わらずデータ本文を一意に識別するためのIDとしてもかまわない。この場合、データ特定LBLデータおよびデータ特定GBLデータには、当該データIDのみを含むようにする。これにより、フィルタリング処理において、フィルタリング対象のユーザ作成データUdに含まれるデータIDのみをデータ特定LBLデータおよびデータ特定GBLデータとそれぞれ比較して非表示データを特定することができる。
また、上述の説明では、配信用GBLデータGsd、ユーザ特定用カウントデータUcdおよびデータ特定用カウントデータDcdがサーバ5のメインメモリ55に格納されるものとした。しかしながら、他の一実施形態では、配信用GBLデータGsd、ユーザ特定用カウントデータUcdおよびデータ特定用カウントデータDcdの少なくともいずれか1つをサーバ5のHDD54に格納するようにしてもよい。
また、上述の説明では、GBLデータGdに含まれるアプリIDおよび配信用GBLデータGsdを受信するためのタスクデータTdに含まれるアプリIDは、例外的なアプリIDであるものとした。しかしながら、他の一実施形態では、GBLデータGdおよび配信用GBLデータGsdを受信するためのタスクデータTdに含まれるアプリIDは、例外的なアプリIDでなくてもよい。具体的には、GBLデータGdを取り扱うアプリケーションを仮想した場合のアプリIDであってもよいし、上述したサーバ処理プログラムをアプリケーションプログラムと見なした場合の当該アプリケーションプログラムに付与されているアプリIDであってもよい。
また、上述の説明では、ユーザ作成データUdの最後の変更者IDとアプリIDとを含むデータを変更者特定GBLデータとして追加するものとした。しかしながら、他の一実施形態では、ユーザ作成データUdの作成者IDとアプリIDとを含むデータを変更者特定GBLデータと同様に追加して用いてもよい。この場合、ゲーム装置10はユーザ作成データUdに含まれる作成者IDとアプリIDとの両方が変更者特定GBLデータに含まれる作成者IDとアプリIDとの両方と一致したときに当該ユーザ作成データUdを非表示データに設定すればよい。また、この場合、ユーザがユーザ作成データUdを通報することによって、当該ユーザ作成データUdに含まれる作成者IDのユーザが道徳上の観点から好ましくないキャラクタを作成したユーザとして通報される。
また、上述の説明では、変更者IDとアプリIDとからなるユーザカウントデータおよびデータIDとアプリIDとからなるデータカウントデータに基づいて変更者特定GBLデータおよびデータ特定GBLデータをそれぞれ配信用GBLデータGsdに追加するものとした。しかしながら、他の一実施形態では、ユーザ作成データUdの最後の変更者ID毎に、通報されたユーザ作成データUdの数を通報回数としてさらにカウントしてもよい。そして、カウントした通報回数が所定の第3の閾値th3以上となったときに当該変更者IDと全てのアプリケーションを示すアプリIDとを含む変更者特定GBLデータを配信用GBLデータGsdに追加するようにしてもよい。これにより、複数のアプリケーションを用いて、道徳上の観点から好ましくないユーザ作成データUdを作成するユーザを特定するための変更者特定GBLデータを配信用GBLデータGsdに追加することができる。なお、全てのアプリケーションを示すアプリIDとは、ゲーム装置10で実行し得る全てのアプリケーションを示すアプリIDとして予め定められたIDであればどのようなIDであってもよい。一例としては、Nullで示されるアプリIDが挙げられる。この場合、ゲーム装置10は、受信したユーザ作成データUdの最後の変更者IDのみが変更者特定GBLデータに含まれる変更者IDと一致すれば、アプリIDに関わらず当該ユーザ作成データUdを非表示データとして設定できる。すなわち、変更者特定GBLデータに含まれる変更者IDのユーザは、ユーザ作成データUdを作成するためにどのようなアプリケーションを用いたとしても、送信したユーザ作成データUdで示されるデータが他のゲーム装置10に表示されることはない。従って、この場合に追加される変更者特定GBLデータの変更者IDで示されるユーザは、本システムにおいて、データを他のゲーム装置10に一切送信できなくなる。このように、広範囲の制限を与えてしまうので、第3の閾値th3は、第1の閾値th1や第2の閾値th2よりも高い値となることが望ましい。
また、上述の説明では、ユーザ作成データUdには、作成者IDおよび1以上の追加された変更者IDが含まれる場合を一例として説明した。しかしながら、他の一実施形態では、作成者IDを保持せず、また、変更者IDも複数保持せずに最後の変更者IDのみを含むユーザ作成データUdを用いてもよい。この場合、ユーザ作成データUdを新規に作成したときには最後の変更者IDに作成者のIDが記録され、ユーザ作成データUdが変更される度に、変更したユーザを示すIDが最後の変更者IDとして上書きされることとなる。
さらに、他の一実施形態では、作成者IDと変更者IDとを1つずつ含むユーザ作成データUdを用いてもよい。この場合、ユーザ作成データUdが変更される度に変更したユーザを示すIDが変更者IDとして上書きされる。また、この場合、ユーザ作成データUdに含まれる変更者IDが最後の変更者を示すIDとなるので、このようなユーザ作成データUdは、そのまま上述で説明した実施形態で用いることが可能である。
また、上述の説明では、ユーザ作成データUdで示されるキャラクタをLBLに登録するときにユーザは変更者LBLまたはデータLBLの中から登録するLBLを選択できるものとした。しかしながら、他の一実施形態では、ユーザによってキャラクタのLBLへの登録が選択されたときには、当該キャラクタを変更者LBLとデータLBLとの両方に登録するようにしてもよい。
また、上述の説明では、ユーザ作成データUdの最後の変更者IDを変更者特定GBLデータに含ませるものとした。しかしながら、他の一実施形態では、ユーザ作成データUdに含まれる作成者IDおよび変更者IDの中から変更者特定GBLデータに変更者IDとして含ませるIDを選択できるようにしてもよい。
また、上述の説明では、第1の閾値th1が第2の閾値th2以下であるものとして説明した。しかしながら、他の一実施形態では、必ずしも第1の閾値th1が第2の閾値th2以下でなくてもよい。ただし、上述したように第1の閾値th1が第2の閾値th2以下としたのは、ユーザ作成データUdの最後の変更者IDがアプリIDと共に変更者特定GBLデータとして追加された場合に、当該変更者IDのユーザは当該アプリIDで示されるアプリケーションによって提供される楽しみを奪われてしまう状況を避けるためである。従って、第1の閾値th1が第2の閾値th2以下でなくなるようにそれぞれの閾値を予め定める場合には、前述の状況を避けなくてもよい場合に限る。
また、他の一実施形態では、ゲーム装置10が「通常電力モード」と「省電力モード」の2つの電源制御モードのいずれかで動作するようにしてもよい。「通常電力モード」は、ゲーム装置10の構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーションを実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。また、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、無線通信モジュール36およびローカル通信モジュール37にのみ電源を供給し、それ以外の部品、つまり、LCDなどへの電力供給は停止している状態である。上述の説明では、ゲーム装置10をオンにした後は、すれ違い通信処理、インターネット通信処理およびGBL更新処理を互いに並行して繰り返して行うものとした。このことは、ゲーム装置10が上記「通常電力モード」と「省電力モード」の2つの電源制御モードのいずれかで動作する場合も同様にしてよい。すなわち、ゲーム装置10は、「スリープモード」で動作している場合でもすれ違い通信処理、インターネット通信処理およびGBL更新処理を互いに並行して繰り返して行ってもよい。
また、上述の説明では、ユーザに提供すべきでないコンテンツを含むユーザ作成データUdを特定するためにアプリIDおよびデータIDなどを用いるものとした。しかしながら、他の一実施形態では、ユーザ作成データUd毎に計算したハッシュ値を用いてユーザに提供すべきでないコンテンツを含むユーザ作成データUdを特定してもよい。また、他の一実施形態では、ユーザ作成データUdに含まれるデータ本文(コンテンツ)そのものをGBLまたはLBLに登録して用いてもよい。
また、上述の説明では、ゲーム装置10が複数のアプリケーションを選択的に実行できることを説明した。しかしながら、仮に、ゲーム装置10が1つのアプリケーションしか実行できないのであれば、ユーザに提供すべきでないコンテンツを含むユーザ作成データUdを特定するのに、アプリIDを用いなくてもよいことは言うまでもない。
また、上述の説明では、CPU311が、GBLデータGdを更新するときには新しいGBLのGBLデータGdを既に格納されているGBLデータGdに上書きして更新するものとして説明した。しかしながら、他の一実施形態では、新しいGBLデータGdの一部(例えば、既に格納されているGBLデータGdとの差分)を追加或いは全部を上書きすることによって、既に格納されているGBLデータGdを更新してもよい。
また、上述の説明では、サーバ5のCPU51が上述したサーバ処理を行うことによりユーザからの通報回数を自動的に集計してGBLに提供するべきでないコンテンツを含むユーザ作成データUdを特定するためのデータを登録するものとした。しかしながら、他の一実施形態では、提供するべきでないコンテンツを含むユーザ作成データUdを特定するためのデータの登録を、例えば、サーバ5の使用者などによる手動で行うようにしてもよい。より詳細には、例えば、サーバ5において、ユーザ作成データUdの通報回数が所定の閾値以上となったときに当該ユーザ作成データUdが道徳上の観点から好ましくないコンテンツを示すデータであるとしてサーバ5の使用者に通知をするように構成してもよい。これにより、サーバ5の使用者は通知を受けたときに通知されたデータのコンテンツを目視してGBLに登録するべきか否かを判断してから必要に応じて登録することができる。
また、上述の説明では、サーバ5から受信した配信用GBLデータGsdで示されるGBLのバージョンが新しい場合に、メインメモリ32に格納されているGBLデータGdを更新するものとした。しかしながら、他の一実施形態では、配信用GBLデータGsdで示されるGBLの更新日時が新しい場合に、メインメモリ32に格納されているGBLデータGdを更新するようにしてもよい。
また、上述の説明では、ユーザが道徳上の観点から好ましくないコンテンツを示すユーザ作成データUdを通報するときには、当該ユーザ作成データUdがそのままサーバ5に送信されるものとした。しかしながら、他の一実施形態では、ユーザがユーザ作成データUdを通報するときに、通報するユーザ作成データUdに含まれるユーザIDとデータIDとの組み合わせをサーバ5に送信して通報するようにしてもよい。そして、サーバ5は、ユーザIDとデータIDとの組み合わせの送信回数が上述した第1の閾値以上となったときに当該組み合わせにおけるデータIDを配信用GBLデータGsdのデータ特定GBLデータとしてデータGBLデータに追加して更新するようにしてもよい。さらに、この場合、サーバ5は、ユーザIDとデータIDとの組み合わせの送信回数が上述した第2の閾値以上となったときに当該組み合わせにおけるユーザIDを配信用GBLデータGsdの変更者特定GBLデータとして変更者GBLデータに追加して更新するようにしてもよい。
また、上述の説明では、ユーザが道徳上の観点から好ましくないコンテンツを示すユーザ作成データUdを通報するときには、当該ユーザ作成データUdがそのままサーバ5に送信されるものとした。しかしながら、他の一実施形態では、ユーザがユーザ作成データUdを通報するときに、通報するユーザ作成データUdに含まれるユーザIDとアプリIDとの組み合わせをサーバ5に送信して通報するようにしてもよい。そして、サーバ5は、ユーザIDとアプリIDとの組み合わせの送信回数が上述した第2の閾値以上となったときに当該組み合わせのユーザIDとアプリIDとを配信用GBLデータGsdの変更者特定GBLデータとして変更者GBLデータに追加して更新するようにしてもよい。さらに、この場合、サーバ5は、ユーザIDとアプリIDとの組み合わせの送信回数が上述した第3の閾値以上となったときに、当該組み合わせにおけるユーザIDと上述した全てのアプリケーションを示すアプリIDとの組み合わせを、配信用GBLデータGsdの変更者特定GBLデータとして変更者GBLデータに追加して更新するようにしてもよい。
また、上述の説明では、ローカル通信モジュール37を用いてすれ違い通信を行うものとした。しかしながら、他の一実施形態では、無線通信モジュール36を用いてAP2との間ですれ違い通信をしてもよい。これにより、インターネット通信網3を介したすれ違い通信を行うことができる。また、赤外線通信などの通信方式を用いてもよい。
また、上述の説明では、GBLデータGd或いはLBLデータLdに登録されるデータはユーザ作成データUdによって示されるコンテンツを特定するための情報(ユーザID、データIDなど)であるものとして説明した。しかしながら、他の一実施形態では、ゲーム装置10などの情報処理装置を対象として作成されたウイルスプログラムを特定するための情報をGBLデータGd或いはLBLデータLdに登録するようにしてもよい。この場合、ウイルスプログラムを特定したデータをすれ違い通信等で伝播させることができるので、上述で説明したような道徳上の観点から好ましくないコンテンツと同様にウイルスプログラムの蔓延を未然に防止できる。
また、上述の説明では、ユーザ作成データUdを特定するための情報に基づいてユーザに出力するか否かを決定する場合について説明した。しかしながら、他の一実施形態では、ユーザ作成データUdの送信元のアドレスに基づいてユーザに出力するか否かを判別してもよい。また、ユーザ作成データUdによって示されるコンテンツがメールである場合には、メールの送信元のアドレスに基づいて当該メールをユーザに表示出力するか否か判別してもよい。この場合、GBLデータGd或いはLBLデータLdには、このような送信元のアドレスが登録され、すれ違い通信等で伝播されることになる。
また、上述の説明では、2画面分の液晶表示部の一例として、物理的に分離された下側LCD12および上側LCD22を互いに上下に配置した場合(上下2画面の場合)を説明した。しかしながら、2画面分の表示画面の構成は、他の構成でもかまわない。例えば、下側ハウジング11の一方主面に下側LCD12および上側LCD22を左右に配置してもかまわない。また、下側LCD12と横幅が同じで縦の長さが2倍のサイズからなる縦長サイズのLCD(すなわち、物理的には1つで、表示サイズが縦に2画面分あるLCD)を下側ハウジング11の一方主面に配設して、2つの画像を上下に表示(すなわち上下の境界部分無しに隣接して表示)するように構成してもよい。また、下側LCD12と縦幅が同じで横の長さが2倍のサイズからなる横長サイズのLCDを下側ハウジング11の一方主面に配設して、横方向に2つのゲーム画像を左右に表示(すなわち左右の境界部分無しに隣接して表示)するように構成してもよい。すなわち、物理的に1つの画面を2つに分割して使用することにより2つの画像を表示してもかまわない。いずれの画像の形態に対しても、上述した下側LCD12に表示していた表示画像が表示される画面上にタッチパネル13を配設すれば、同様に本発明を実現することができる。また、物理的に1つの画面を2つに分割して使用することにより上記2つの画像を表示する場合、当該画面全面にタッチパネル13を配設してもかまわない。
また、上述の説明では、ゲーム装置10にタッチパネル13が一体的に設けられているが、ゲーム装置とタッチパネルとを別体にして構成しても、本発明を実現できることは言うまでもない。
また、上述の説明では、座標入力を実現するゲーム装置10の入力手段としてタッチパネル13を用いたが、他のポインティングデバイスを用いてもかまわない。ここで、ポインティングデバイスは、画面上での入力位置や座標を指定する入力装置であり、例えば、マウス、トラックパッド、トラックボール等を入力手段として使用し、入力手段から出力される出力値から計算された画面座標系の位置情報を用いれば、本発明を同様に実現することができる。
また、ゲームコントローラをユーザが把持してゲームを楽しむ据置型のゲーム装置の場合、他の態様のポインティングデバイスも考えられる。例えば、ゲームコントローラのハウジングに固設されたカメラを、上記ポインティングデバイスとして利用することも可能である。この場合、ゲームコントローラのハウジングで指し示した位置の変化に応じてカメラが撮像する撮像画像が変化する。従って、この撮像画像を解析することにより、表示画面に対して上記ハウジングで指し示した座標を算出することができる。なお、本発明においては、ゲーム装置10にタッチパネル13等のポインティングデバイス自体が設けられていなくても実現可能であることは言うまでもない。
また、上記実施例では、携帯型のゲーム装置10や据置型のゲーム装置を用いて説明したが、一般的なパーソナルコンピュータ等の情報処理装置で本発明の画像通信プログラムを実行して、本発明を実現してもかまわない。
また、上述したゲーム装置10の形状や、それに設けられている各種操作ボタン14やタッチパネル13の形状、数、および設置位置等は、単なる一例に過ぎず、他の形状、数、および設置位置であっても、本発明を実現できることは言うまでもない。また、上述した画像通信処理で用いられる各ステップの実行順序や画面表示例等は、単なる一例に過ぎず、他の実行順序や画面表示であっても、本発明を実現できることは言うまでもない。
また、上述した説明では、上記情報処理プログラムの一例としてゲームプログラムが情報処理部31で実行される例を用いたが、本実施形態に係る情報処理プログラムの少なくとも一部を、当該情報処理部31と通信可能な他の装置に備えられた少なくともCPUを含む情報処理部で実行してもかまわない。本実施形態に係る情報処理プログラムの一例として上記ゲームプログラムを実行する場合には、例えば、ゲーム装置10が他の装置(例えば、サーバなど)と通信可能に構成されている場合、上記ゲームプログラムにおける処理は、ゲーム装置10および当該他の装置が協働することによって実行してもよい。一例として、他の装置において上記ゲームプログラムが実行され、当該ゲームプログラムの実行に必要な操作入力の検出、当該ゲームプログラムの実行に必要な表示を行う表示装置などは、それぞれゲーム装置10のタッチパネル13、上側LCD22および/または下側LCD12を用いるように構成したゲームシステムにおいて、上記ゲームプログラムを実行してもよい。このことは、本実施形態に係る情報処理プログラムの他の一例として上述した動作制御プログラムについても同様である。つまり、本実施形態に係る情報処理プログラムは、一例として、他の装置において当該情報処理プログラムが実行され、当該情報処理プログラムの実行に必要な操作入力の検出、当該情報処理プログラムの実行に必要な表示を行う表示装置などは、それぞれゲーム装置10のタッチパネル13、上側LCD22および/または下側LCD12を用いるように構成した情報処理システムにおいて実行されてもよい。
また、上述した説明では、本発明を携帯型のゲーム装置10に適用した場合について説明したが、本発明は携帯型ゲーム装置に限定されない。例えば、据置型ゲーム装置、携帯電話機、簡易型携帯電話機(PHS)、PDA等の携帯情報端末にも本発明の適用は可能である。また、据置型ゲーム機やパーソナルコンピュータにも本発明の適用は可能である。
以上、本発明を詳細に説明してきたが、前述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。また、当業者は、本発明の具体的な実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。また、本明細書において使用される用語は、特に言及しない限り、当該分野で通常用いられる意味で用いられることが理解されるべきである。従って、他に定義されない限り、本明細書中で使用される全ての専門用語および技術用語は、本発明の属する分野の当業者によって一般的に理解されるのと同じ意味を有する。矛盾する場合、本明細書(定義を含めて)が優先する。