図1を参照して、この発明の一実施例であるゲームシステム10は、ビデオゲーム装置(以下、単に「ゲーム装置」という。)12およびコントローラ22を含む。なお、図示は省略するが、この実施例のゲーム装置12は、最大4つのコントローラ22と通信可能に設計されている。また、ゲーム装置12と各コントローラ22とは、無線によって接続される。たとえば、無線通信は、Bluetooth(登録商標)規格に従って実行されるが、赤外線や無線LANなど他の規格に従って実行されてもよい。
ゲーム装置12は、略直方体のハウジング14を含み、ハウジング14の前面にはディスクスロット16が設けられる。ディスクスロット16から、ゲームプログラム等を記憶した情報記憶媒体の一例である光ディスク18が挿入されて、ハウジング14内のディスクドライブ54(図2参照)に装着される。ディスクスロット16の周囲には、LEDと導光板が配置され、さまざまな処理に応答させて点灯させることが可能である。
また、ゲーム装置12のハウジング14の前面であり、その上部には、電源ボタン20aおよびリセットボタン20bが設けられ、その下部には、イジェクトボタン20cが設けられる。さらに、リセットボタン20bとイジェクトボタン20cとの間であり、ディスクスロット16の近傍には、外部メモリカード用コネクタカバー28が設けられる。この外部メモリカード用コネクタカバー28の内側には、外部メモリカード用コネクタ62(図2参照)が設けられ、図示しない外部メモリカード(以下、単に「メモリカード」という。)が挿入される。メモリカードは、光ディスク18から読み出したゲームプログラム等をローディングして一時的に記憶したり、このゲームシステム10を利用してプレイしたゲームのゲームデータ(ゲームの結果データまたは途中データ)を保存(セーブ)しておいたりするために利用される。ただし、上記のゲームデータの保存は、メモリカードに対して行うことに代えて、たとえばゲーム装置12の内部に設けられるフラッシュメモリ44(図2参照)のような内部メモリに対して行うようにしてもよい。また、メモリカードは、内部メモリのバックアップメモリとして用いるようにしてもよい。
なお、メモリカードとしては、汎用のSDカードを用いることができるが、メモリスティックやマルチメディアカード(登録商標)のような他の汎用のメモリカードを用いることもできる。
ゲーム装置12のハウジング14の後面には、AVケーブルコネクタ58(図2参照)が設けられ、そのAVコネクタ58を用いて、AVケーブル32aを通してゲーム装置12にモニタ34およびスピーカ34aを接続する。このモニタ34およびスピーカ34aは典型的にはカラーテレビジョン受像機であり、AVケーブル32aは、ゲーム装置12からの映像信号をカラーテレビのビデオ入力端子に入力し、音声信号を音声入力端子に入力する。したがって、カラーテレビ(モニタ)34の画面上にたとえば3次元(3D)ビデオゲームのゲーム画像が表示され、左右のスピーカ34aからゲーム音楽や効果音などのステレオゲーム音声が出力される。また、モニタ34の周辺(この実施例では、モニタ34の上側)には、2つの赤外LED(マーカ)34m,34nを備えるマーカ部34bが設けられる。このマーカ部34bは、電源ケーブル32bを通してゲーム装置12に接続される。したがって、マーカ部34bには、ゲーム装置12から電源が供給される。これによって、マーカ34m,34nは発光し、それぞれモニタ34の前方に向けて赤外光を出力する。
なお、ゲーム装置12の電源は、一般的なACアダプタ(図示せず)によって与えられる。ACアダプタは家庭用の標準的な壁ソケットに差し込まれ、ゲーム装置12は、家庭用電源(商用電源)を、駆動に適した低いDC電圧信号に変換する。他の実施例では、電源としてバッテリが用いられてもよい。
このゲームシステム10において、ユーザまたはプレイヤがゲーム(またはゲームに限らず、他のアプリケーション)をプレイするために、ユーザはまずゲーム装置12の電源をオンし、次いで、ユーザはビデオゲーム(もしくはプレイしたいと思う他のアプリケーション)のプログラムを記録している適宜の光ディスク18を選択し、その光ディスク18をゲーム装置12のディスクドライブ54にローディングする。応じて、ゲーム装置12がその光ディスク18に記録されているプログラムに基づいてビデオゲームもしくは他のアプリケーションを実行し始めるようにする。ユーザはゲーム装置12に入力を与えるためにコントローラ22を操作する。たとえば、入力手段26のどれかを操作することによってゲームもしくは他のアプリケーションをスタートさせる。また、入力手段26に対する操作以外にも、コントローラ22自体を動かすことによって、動画オブジェクト(プレイヤオブジェクト)を異なる方向に移動させ、または3Dのゲーム世界におけるユーザの視点(カメラ位置)を変化させることができる。
図2は図1実施例のビデオゲームシステム10の電気的な構成を示すブロック図である。図示は省略するが、ハウジング14内の各コンポーネントは、プリント基板に実装される。図2に示すように、ゲーム装置12には、CPU40が設けられる。このCPU40は、ゲームプロセッサとして機能する。このCPU40には、システムLSI42が接続される。このシステムLSI42には、外部メインメモリ46、ROM/RTC48、ディスクドライブ54およびAV IC56が接続される。
外部メインメモリ46は、ゲームプログラム等のプログラムを記憶したり、各種データを記憶したりし、CPU40のワーク領域やバッファ領域として用いられる。ROM/RTC48は、いわゆるブートROMであり、ゲーム装置12の起動用のプログラムが組み込まれるとともに、時間をカウントする時計回路が設けられる。ディスクドライブ54は、光ディスク18からプログラムデータやテクスチャデータ等を読み出し、CPU40の制御の下で、後述する内部メインメモリ42eまたは外部メインメモリ46に書き込む。
システムLSI42には、入出力プロセッサ42a、GPU(Graphics Processor Unit)42b,DSP(Digital Signal Processor)42c,VRAM42dおよび内部メインメモリ42eが設けられ、図示は省略するが、これらは内部バスによって互いに接続される。
入出力プロセッサ(I/Oプロセッサ)42aは、データの送受信を実行したり、データのダウンロードを実行したりする。データの送受信やダウンロードについては後で詳細に説明する。
GPU42bは、描画手段の一部を形成し、CPU40からのグラフィクスコマンド(作画命令)を受け、そのコマンドに従ってゲーム画像データを生成する。ただし、CPU40は、グラフィクスコマンドに加えて、ゲーム画像データの生成に必要な画像生成プログラムをGPU42bに与える。
図示は省略するが、上述したように、GPU42bにはVRAM42dが接続される。GPU42bが作画コマンドを実行するにあたって必要なデータ(画像データ:ポリゴンデータやテクスチャデータなどのデータ)は、GPU42bがVRAM42dにアクセスして取得する。なお、CPU40は、描画に必要な画像データを、GPU42bを介してVRAM42dに書き込む。GPU42bは、VRAM42dにアクセスして描画のためのゲーム画像データを作成する。
なお、この実施例では、GPU42bがゲーム画像データを生成する場合について説明するが、ゲームアプリケーション以外の任意のアプリケーションを実行する場合には、GPU42bは当該任意のアプリケーションについての画像データを生成する。
また、DSP42cは、オーディオプロセッサとして機能し、内部メインメモリ42eや外部メインメモリ46に記憶されるサウンドデータや音波形(音色)データを用いて、スピーカ34aから出力する音、音声或いは音楽に対応するオーディオデータを生成する。
上述のように生成されたゲーム画像データおよびオーディオデータは、AV IC56によって読み出され、AVコネクタ58を介してモニタ34およびスピーカ34aに出力される。したがって、ゲーム画面がモニタ34に表示され、ゲームに必要な音(音楽)がスピーカ34aから出力される。
また、入出力プロセッサ42aには、フラッシュメモリ44、無線通信モジュール50
および無線コントローラモジュール52が接続されるとともに、拡張コネクタ60およびメモリカード用コネクタ62が接続される。また、無線通信モジュール50にはアンテナ50aが接続され、無線コントローラモジュール52にはアンテナ52aが接続される。
入出力プロセッサ42aは、無線通信モジュール50を介して、ネットワークに接続される他のゲーム装置や各種サーバと通信することができる。ただし、ネットワークを介さずに、直接的に他のゲーム装置と通信することもできる。入出力プロセッサ42aは、定期的にフラッシュメモリ44にアクセスし、ネットワークへ送信する必要があるデータ(送信データとする)の有無を検出し、当該送信データが有る場合には、無線通信モジュール50およびアンテナ50aを介してネットワークに送信する。また、入出力プロセッサ42aは、他のゲーム装置から送信されるデータ(受信データとする)を、ネットワーク、アンテナ50aおよび無線通信モジュール50を介して受信し、受信データをフラッシュメモリ44に記憶する。ただし、一定の場合には、受信データをそのまま破棄する。さらに、入出力プロセッサ42aは、ダウンロードサーバからダウンロードしたデータ(ダウンロードデータとする)をネットワーク、アンテナ50aおよび無線通信モジュール50を介して受信し、ダウンロードデータをフラッシュメモリ44に記憶する。
また、入出力プロセッサ42aは、コントローラ22から送信される入力データをアンテナ52aおよび無線コントローラモジュール52を介して受信し、内部メインメモリ42eまたは外部メインメモリ46のバッファ領域に記憶(一時記憶)する。入力データは、CPU40のゲーム処理によって利用された後、バッファ領域から消去される。
なお、この実施例では、上述したように、無線コントローラモジュール52は、Bluetooth規格にしたがってコントローラ22との間で通信を行う。
さらに、入出力プロセッサ42aには、拡張コネクタ60およびメモリカード用コネクタ62が接続される。拡張コネクタ60は、USBやSCSIのようなインターフェイスのためのコネクタであり、外部記憶媒体のようなメディアを接続したり、他のコントローラのような周辺機器を接続したりすることができる。また、拡張コネクタ60に有線LANアダプタを接続し、無線通信モジュール50に代えて当該有線LANを利用することもできる。メモリカード用コネクタ62には、メモリカードのような外部記憶媒体を接続することができる。したがって、たとえば、入出力プロセッサ42aは、拡張コネクタ60やメモリカード用コネクタ62を介して、外部記憶媒体にアクセスし、データを保存したり、データを読み出したりすることができる。
詳細な説明は省略するが、図1にも示したように、ゲーム装置12(ハウジング14)には、電源ボタン20a,リセットボタン20bおよびイジェクトボタン20cが設けられる。電源ボタン20aは、システムLSI42に接続される。この電源ボタン20aがオンされると、システムLSI42は、ゲーム装置12の各コンポーネントに図示しないACアダプタを経て電源が供給され、通常の通電状態となるモード(通常モードと呼ぶこととする)を設定する。一方、電源ボタン20aがオフされると、システムLSI42は、ゲーム装置12の一部のコンポーネントのみに電源が供給され、消費電力を必要最低限に抑えるモード(以下、「スタンバイモード」という。)を設定する。この実施例では、スタンバイモードが設定された場合には、システムLSI42は、入出力プロセッサ42a、フラッシュメモリ44、外部メインメモリ46、ROM/RTC48および無線通信モジュール50、無線コントローラモジュール52以外のコンポーネントに対して、電源供給を停止する指示を行う。したがって、このスタンバイモードは、CPU40によってアプリケーションの実行が行われないモードである。
なお、システムLSI42には、スタンバイモードにおいても電源が供給されるが、GPU42b、DSP42cおよびVRAM42dへのクロックの供給を停止することにより、これらを駆動させないようにして、消費電力を低減するようにしてある。
また、図示は省略するが、ゲーム装置12のハウジング14内部には、CPU40やシステムLSI42などのICの熱を外部に排出するためのファンが設けられる。スタンバイモードでは、このファンも停止される。
ただし、スタンバイモードを利用したくない場合には、スタンバイモードを利用しない設定にしておくことにより、電源ボタン20aがオフされたときに、すべての回路コンポーネントへの電源供給が完全に停止される。
また、通常モードとスタンバイモードの切り替えは、コントローラ22の電源スイッチ26hのオン/オフの切り替えによっても遠隔操作によって行うことが可能である。当該遠隔操作を行わない場合には、スタンバイモードにおいて無線コントローラモジュール52aへの電源供給を行わない設定にしてもよい。
リセットボタン20bもまた、システムLSI42に接続される。リセットボタン20bが押されると、システムLSI42は、ゲーム装置12の起動プログラムを再起動する。イジェクトボタン20cは、ディスクドライブ54に接続される。イジェクトボタン20cが押されると、ディスクドライブ54から光ディスク18が排出される。
図3(A)ないし図3(E)は、コントローラ22の外観の一例を示す。図3(A)はコントローラ22の先端面を示し、図3(B)はコントローラ22の上面を示し、図3(C)はコントローラ22の右側面を示し、図3(D)はコントローラ22の下面を示し、そして、図3(E)はコントローラ22の後端面を示す。
図3(A)ないし図3(E)を参照して、コントローラ22は、たとえばプラスチック成型によって形成されたハウジング22aを有している。ハウジング22aは、略直方体形状であり、ユーザが片手で把持可能な大きさである。ハウジング22a(コントローラ22)には、入力手段(複数のボタンないしスイッチ)26が設けられる。具体的には、図3(B)に示すように、ハウジング22aの上面には、十字キー26a,1ボタン26b,2ボタン26c,Aボタン26d,−ボタン26e,HOMEボタン26f,+ボタン26gおよび電源スイッチ26hが設けられる。また、図3(C)および図3(D)に示すように、ハウジング22aの下面に傾斜面が形成されており、この傾斜面に、Bトリガースイッチ26iが設けられる。
十字キー26aは、4方向プッシュスイッチであり、矢印で示す4つの方向、前(または上)、後ろ(または下)、右および左の操作部を含む。この操作部のいずれか1つを操作することによって、プレイヤによって操作可能なキャラクタまたはオブジェクト(プレイヤキャラクタまたはプレイヤオブジェクト)の移動方向を指示したり、カーソルの移動方向を指示したりすることができる。
1ボタン26bおよび2ボタン26cは、それぞれ、押しボタンスイッチである。たとえば3次元ゲーム画像を表示する際の視点位置や視点方向、すなわち仮想カメラの位置や画角を調整する等のゲームの操作に使用される。または、1ボタン26bおよび2ボタン26cは、Aボタン26dおよびBトリガースイッチ26iと同じ操作或いは補助的な操作をする場合に用いるようにしてもよい。
Aボタンスイッチ26dは、押しボタンスイッチであり、プレイヤキャラクタまたはプレイヤオブジェクトに、方向指示以外の動作、すなわち、打つ(パンチ)、投げる、つかむ(取得)、乗る、ジャンプするなどの任意のアクションをさせるために使用される。たとえば、アクションゲームにおいては、ジャンプ、パンチ、武器を動かすなどを指示することができる。また、ロールプレイングゲーム(RPG)やシミュレーションRPGにおいては、アイテムの取得、武器やコマンドの選択および決定等を指示することができる。
−ボタン26e、HOMEボタン26f、+ボタン26gおよび電源スイッチ26hもまた、押しボタンスイッチである。−ボタン26eは、ゲームモードを選択するために使用される。HOMEボタン26fは、ゲームメニュー(メニュー画面)を表示するために使用される。+ボタン26gは、ゲームを開始(再開)したり、一時停止したりするなどのために使用される。電源スイッチ26hは、ゲーム装置12の電源を遠隔操作によってオン/オフするために使用される。
なお、この実施例では、コントローラ22自体をオン/オフするための電源スイッチは設けておらず、コントローラ22の入力手段26のいずれかを操作することによってコントローラ22はオンとなり、一定時間(たとえば、30秒)以上操作しなければ自動的にオフとなるようにしてある。
Bトリガースイッチ26iもまた、押しボタンスイッチであり、主として、弾を撃つなどのトリガを模した入力を行ったり、コントローラ22で選択した位置を指定したりするために使用される。また、Bトリガースイッチ26iを押し続けると、プレイヤオブジェクトの動作やパラメータを一定の状態に維持することもできる。また、一定の場合には、Bトリガースイッチ26iは、通常のBボタンと同様に機能し、Aボタン26dによって決定したアクションを取り消すなどのために使用される。
また、図3(E)に示すように、ハウジング22aの後端面に外部拡張コネクタ22bが設けられ、また、図3(B)に示すように、ハウジング22aの上面であり、後端面側にはインジケータ22cが設けられる。外部拡張コネクタ22bは、図示しない別の拡張コントローラを接続するためなどに使用される。インジケータ22cは、たとえば、4つのLEDで構成され、4つのうちのいずれか1つを点灯することにより、点灯LEDに対応するコントローラ22の識別情報(コントローラ番号)を示したり、点灯させるLEDの個数によってコントローラ22の電源残量を示したりすることができる。
さらに、コントローラ22は、撮像情報演算部80(図4参照)を有しており、図3(A)に示すように、ハウジング22aの先端面には撮像情報演算部80の光入射口22dが設けられる。また、コントローラ22は、スピーカ86(図4参照)を有しており、このスピーカ86は、図3(B)に示すように、ハウジング22aの上面であり、1ボタン26bとHOMEボタン26fとの間に設けられる音抜き孔22eに対応して、ハウジング22a内部に設けられる。
なお、図3(A)ないし図3(E)に示したコントローラ22の形状や、各入力手段26の形状、数および設置位置等は単なる一例に過ぎず、それらが適宜改変された場合であっても、本発明を実現できることは言うまでもない。
図4はコントローラ22の電気的な構成を示すブロック図である。この図4を参照して、コントローラ22はプロセッサ70を含み、このプロセッサ70には、内部バス(図示せず)によって、外部拡張コネクタ22b、入力手段26、メモリ72、加速度センサ74、無線モジュール76、撮像情報演算部80、LED82(インジケータ22c)、バイブレータ84、スピーカ86および電源回路88が接続される。また、無線モジュール76には、アンテナ78が接続される。
プロセッサ70は、コントローラ22の全体制御を司り、入力手段26、加速度センサ74および撮像情報演算部80によって入力された情報(入力情報)を、入力データとして無線モジュール76およびアンテナ78を介してゲーム装置12に送信(入力)する。このとき、プロセッサ70は、メモリ72を作業領域ないしバッファ領域として用いる。
上述した入力手段26(26a−26i)からの操作信号(操作データ)は、プロセッサ70に入力され、プロセッサ70は操作データを一旦メモリ72に記憶する。
また、加速度センサ74は、コントローラ22の縦方向(y軸方向)、横方向(x軸方向)および前後方向(z軸方向)の3軸で各々の加速度を検出する。この加速度センサ74は、典型的には、静電容量式の加速度センサであるが、他の方式のものを用いるようにしてもよい。
たとえば、加速度センサ74は、第1所定時間毎に、x軸,y軸,z軸の各々についての加速度(ax,ay,az)を検出し、検出した加速度のデータ(加速度データ)をプロセッサ70に入力する。たとえば、加速度センサ74は、各軸方向の加速度を、−2.0g〜2.0g(gは重力加速度である。以下、同じ。)の範囲で検出する。プロセッサ70は、加速度センサ74から与えられる加速度データを、第2所定時間毎に検出し、一旦メモリ72に記憶する。プロセッサ70は、操作データ、加速度データおよび後述するマーカ座標データの少なくとも1つを含む入力データを作成し、作成した入力データを、第3所定時間(たとえば、5msec)毎にゲーム装置12に送信する。
なお、図3(A)−図3(E)では省略したが、この実施例では、加速度センサ74は、ハウジング22a内部の基板上の十字キー26aが配置される付近に設けられる。
無線モジュール76は、たとえばBluetoothの技術を用いて、所定周波数の搬送波を入力データで変調し、その微弱電波信号をアンテナ78から放射する。つまり、入力データは、無線モジュール76によって微弱電波信号に変調されてアンテナ78(コントローラ22)から送信される。この微弱電波信号が上述したゲーム装置12に設けられた無線コントローラモジュール52によって受信される。受信された微弱電波は、復調および復号の処理を施され、したがって、ゲーム装置12(CPU40)は、コントローラ22からの入力データを取得することができる。そして、CPU40は、取得した入力データとプログラム(ゲームプログラム)とに従ってゲーム処理を行う。
さらに、上述したように、コントローラ22には、撮像情報演算部80が設けられる。この撮像情報演算部80は、赤外線フィルタ80a、レンズ80b、撮像素子80cおよび画像処理回路80dによって構成される。赤外線フィルタ80aは、コントローラ22の前方から入射する光から赤外線のみを通過させる。上述したように、モニタ34の表示画面近傍(周辺)に配置されるマーカ340mおよび340nは、モニタ34の前方に向かって赤外光を出力する赤外LEDである。したがって、赤外線フィルタ80aを設けることによってマーカ340mおよび340nの画像をより正確に撮像することができる。レンズ84は、赤外線フィル82を透過した赤外線を集光して撮像素子80cへ出射する。撮像素子80cは、たとえばCMOSセンサあるいはCCDのような固体撮像素子であり、レンズ80bによって集光された赤外線を撮像する。したがって、撮像素子80cは、赤外線フィルタ80aを通過した赤外線だけを撮像して画像データを生成する。以下では、撮像素子80cによって撮像された画像を撮像画像と呼ぶ。撮像素子80cによって生成された画像データは、画像処理回路80dで処理される。画像処理回路80dは、撮像画像内における撮像対象(マーカ340mおよび340n)の位置を算出し、第4所定時間毎に、当該位置を示す各座標値を撮像データとしてプロセッサ70に出力する。なお、画像処理回路80dにおける処理については後述する。
図5は、コントローラ22を用いてゲームプレイするときの状態を概説する図解図である。図5に示すように、ビデオゲームシステム10でコントローラ22を用いてゲームをプレイする際、プレイヤは、一方の手でコントローラ22を把持する。厳密に言うと、プレイヤは、コントローラ22の先端面(撮像情報演算部80が撮像する光の入射口22d側)がマーカ340mおよび340nの方を向く状態でコントローラ22を把持する。ただし、図1からも分かるように、マーカ340mおよび340nは、モニタ34の画面の横方向と平行に配置されている。この状態で、プレイヤは、コントローラ22が指示する画面上の位置を変更したり、コントローラ22と各マーカ340mおよび340nとの距離を変更したりすることによってゲーム操作を行う。
図6は、マーカ340mおよび340nと、コントローラ22との視野角を説明するための図である。図6に示すように、マーカ340mおよび340nは、それぞれ、視野角θ1の範囲で赤外光を放射する。また、撮像情報演算部80の撮像素子80cは、コントローラ22の視線方向を中心とした視野角θ2の範囲で入射する光を受光することができる。たとえば、マーカ340mおよび340nの視野角θ1は、共に34°(半値角)であり、一方、撮像素子80cの視野角θ2は41°である。プレイヤは、撮像素子80cが2つのマーカ340mおよび340nからの赤外光を受光することが可能な位置および向きとなるように、コントローラ22を把持する。具体的には、撮像素子80cの視野角θ2の中に少なくとも一方のマーカ340mおよび340nが存在し、かつ、マーカ340mまたは340nの少なくとも一方の視野角θ1の中にコントローラ22が存在する状態となるように、プレイヤはコントローラ22を把持する。この状態にあるとき、コントローラ22は、マーカ340mおよび340nの少なくとも一方を検知することができる。プレイヤは、この状態を満たす範囲でコントローラ22の位置および向きを変化させることによってゲーム操作を行うことができる。
なお、コントローラ22の位置および向きがこの範囲外となった場合、コントローラ22の位置および向きに基づいたゲーム操作を行うことができなくなる。以下では、上記範囲を「操作可能範囲」と呼ぶ。
操作可能範囲内でコントローラ22が把持される場合、撮像情報演算部80によって各マーカ340mおよび340nの画像が撮像される。すなわち、撮像素子80cによって得られる撮像画像には、撮像対象である各マーカ340mおよび340nの画像(対象画像)が含まれる。図7は、対象画像を含む撮像画像の一例を示す図である。対象画像を含む撮像画像の画像データを用いて、画像処理回路80dは、各マーカ340mおよび340nの撮像画像における位置を表す座標(マーカ座標)を算出する。
撮像画像の画像データにおいて対象画像は高輝度部分として現れるため、画像処理回路80dは、まず、この高輝度部分を対象画像の候補として検出する。次に、画像処理回路80dは、検出された高輝度部分の大きさに基づいて、その高輝度部分が対象画像であるか否かを判定する。撮像画像には、対象画像である2つのマーカ340mおよび340nの画像340m’および340n’のみならず、窓からの太陽光や部屋の蛍光灯の光によって対象画像以外の画像が含まれていることがある。高輝度部分が対象画像であるか否かの判定処理は、対象画像であるマーカ340mおよび340nの画像340m’および340n’と、それ以外の画像とを区別し、対象画像を正確に検出するために実行される。具体的には、当該判定処理においては、検出された高輝度部分が、予め定められた所定範囲内の大きさであるか否かが判定される。そして、高輝度部分が所定範囲内の大きさである場合には、当該高輝度部分は対象画像を表すと判定される。逆に、高輝度部分が所定範囲内の大きさでない場合には、当該高輝度部分は対象画像以外の画像を表すと判定される。
さらに、上記の判定処理の結果、対象画像を表すと判定された高輝度部分について、画像処理回路80dは当該高輝度部分の位置を算出する。具体的には、当該高輝度部分の重心位置を算出する。ここでは、当該重心位置の座標をマーカ座標と呼ぶ。また、重心位置は撮像素子80cの解像度よりも詳細なスケールで算出することが可能である。ここでは、撮像素子80cによって撮像された撮像画像の解像度が126×96であるとし、重心位置は1024×768のスケールで算出されるものとする。つまり、マーカ座標は、(0,0)から(1024,768)までの整数値で表現される。
なお、撮像画像における位置は、撮像画像の左上を原点とし、下向きをY軸正方向とし、右向きをX軸正方向とする座標系(XY座標系)で表現されるものとする。
また、対象画像が正しく検出される場合には、判定処理によって2つの高輝度部分が対象画像として判定されるので、2箇所のマーカ座標が算出される。画像処理回路80dは、算出された2箇所のマーカ座標を示すデータを出力する。出力されたマーカ座標のデータ(マーカ座標データ)は、上述したように、プロセッサ70によって入力データに含まれ、ゲーム装置12に送信される。
ゲーム装置12(CPU40)は、受信した入力データからマーカ座標データを検出すると、このマーカ座標データに基づいて、モニタ34の画面上におけるコントローラ22の指示位置(指示座標)と、コントローラ22からマーカ340mおよび340nまでの各距離とを算出することができる。具体的には、2つのマーカ座標の中点の位置から、コントローラ22の向いている位置すなわち指示位置が算出される。また、撮像画像における対象画像間の距離が、コントローラ22と、マーカ340mおよび340nとの距離に応じて変化するので、2つのマーカ座標間の距離を算出することによって、ゲーム装置12はコントローラ22とマーカ340mおよび340nとの間の距離を把握できる。
以下、本願発明の一実施例における、メッセージの送受信について、概要を説明する。図8は上述のゲーム装置12を用いた通信システム100の一例を示す図解図である。図8に示すように、通信システム100は、複数のゲーム装置12を含み、各ゲーム装置12はインターネットやLANのようなネットワーク106を介して、メールサーバ102および配信サーバ104に接続される。このようなネットワーク106に接続されることによって、メールサーバ102を介したメッセージの送受信や配信サーバ104からのデータのダウンロードを行うことが可能となる。
なお、この実施例では、複数のゲーム装置12がネットワーク106に接続されている場合について説明するが、ゲーム装置12は一台でも構わない。また、配信サーバ104は、ダウンロードデータ(コンテンツ)の種類に応じて複数設けられてもよい。さらに、ネットワーク106にはPCも接続され、また、携帯電話網を介して携帯電話機も接続される。それ以外にも、様々な電子機器をネットワークに接続して、メールサーバ102を介してゲーム装置12とメッセージの送受信を行うことができる。
ゲーム装置12同士は、ネットワーク106を介して通信可能である。プレイヤが入力したメッセージやゲーム装置12で生成したメッセージは、電子メールの形式に変換され、ネットワーク106およびメールサーバ102を介して、ゲーム装置12同士で送受信(やり取り)される。このため、メールサーバ102は、汎用的なメールサーバを用いることができる。したがって、ゲーム装置12は、PCや携帯電話機のような端末(他のゲーム装置12以外の端末)との間でメッセージすなわち電子メールをやり取りすることも可能である。このようなゲーム装置12におけるメッセージの送受信の処理は、ユーザが送受信指示を行わなくとも所定のスケジュールで自動的に実行されるので、ユーザは定期的なチェック作業を自ら行わなくとも、メッセージを受け取った状態でゲームや他のアプリケーションをプレイすることができる。また、ゲーム装置12は、アドレス帳(後述するフレンドリスト44d)に宛先を登録したゲーム装置12または他のゲーム装置12以外の端末(以下、「他の端末」ということがある。)との間でのみメッセージの送受信を行うようにすることもでき、したがって汎用的なメールシステムを用いてもスパムメールのような不要なメッセージをユーザが受け取らないようにすることが可能である。
また、ゲーム機12は、受信したメッセージをモニタ34に表示するためのアプリケーションである伝言板機能を実行することができる。ただし、その他のアプリケーション(ゲーム等)に依存する固有のメッセージであって、当該アプリケーションによってのみ利用されるデータについては、当該アプリケーションでのみ読み取り可能とすることができる。したがって、特定のユーザのみにメッセージを送りたい場合には、個々のアプリケーションに依存するデータをメッセージに含めて送信すれば、伝言板機能では読めない形式にすることができる。ただし、アプリケーションの種類に拘わらず参照可能なメッセージは、伝言板機能によってモニタ34に表示して誰でも参照する(読む)ことができる。
伝言板機能は、受信したメッセージをモニタ34に表示する機能を有するアプリケーションであり、ネットワーク106から取得したメッセージを表示する。ただし、他のゲーム装置12や他の端末から受信したメッセージのみならず、自身宛に作成したメッセージを同様に表示することもできる。したがって、ゲーム装置12がネットワーク106に接続されていない場合であっても、家庭内の伝言板ないし個人用のメモ帳として、この伝言板機能を利用することができるし、ゲーム等のアプリケーションによって生成された記録を後から伝言板機能によって閲覧できるようにしておくこともできる。このとき、ゲーム機12において生成されたメッセージを、ネットワーク106から取得したメッセージと同様の形式(本実施例においては電子メール形式)で同じ領域に記憶しておくようにすれば、表示のための処理を個別に用意する必要がなくなる。たとえば、メモまたは伝言を生成する際に電子メール形式のデータに変換を行ったり、ゲームプログラムの処理において電子メール形式のデータを生成したりすればよい。
図25に、伝言板機能によってモニタ34にメッセージが表示されている状態の一例を示す。図25の例においては、伝言板機能は、その日受け取ったメッセージを一覧表示させる。たとえば、ネットワークから取得したメッセージや、家族からの伝言、ゲームをプレイした際の履歴等の表示が可能である。また、メモや伝言、またはネットワークへ送信したいメッセージを作成するためのプログラムを起動するためのボタンが表示される。メッセージのデータは日付毎に管理され、他の日を指定することによって画面の切り替えが行われ、指定された日に受け取ったメッセージが同様に一覧表示される。メッセージの内容(本文等)については、最初から閲覧できる状態であってもよいし、一覧においては時刻やタイトルのみ表示するようにして、当該メッセージを開くことで閲覧できるようにしてもよい。
また、詳細な説明は省略するが、メッセージ(電子メール)には、ゲームアプリケーションや画像を描画するアプリケーションによって描画された画像(この実施例では、静止画)のデータ(画像データ)や他の端末に保持された画像データを添付することができる。この画像データは、伝言板機能により、メッセージとともにモニタ34に表示される。たとえば、他の端末に保持された画像データは、デジタルカメラや携帯電話機のカメラで撮影された画像(静止画)またはそのサムネイル画像のデータである。
さらに、詳細な説明は省略するが、メッセージ(電子メール)には、ゲームデータのようなアプリケーションに依存したデータを添付することもできる。
以下、メッセージに含まれる情報について説明する。この実施例では、メッセージには、図9に示すようなヘッダ情報が付加される。具体的には、ヘッダ情報は、送信元、宛先の情報、題目、日時、送信側のアプリケーションの識別情報、伝言板表示ON/OFF属性、伝言板日時指定、上書きタグ、他アプリ制限、消滅属性、受信告知属性、代替ニックネームおよび返信属性を含む。
送信元の情報は、当該メッセージの送信元(送信する側)の、ゲーム装置12の識別情報(もしくはメールアドレス)や他の端末のメールアドレスである。ここで、ゲーム装置12の識別情報は、当該ゲーム装置12を個別に識別するための情報であり、たとえば、数字およびアルファベットの少なくとも一方を用いた文字列である。また、ゲーム装置12のメールアドレスには、当該ゲーム装置12の識別情報の文字列を用いたメールアドレスが設定される。ゲーム装置12のメールアドレスは識別情報から一意に決定されるので、いずれの情報によって管理するようにしてもよい。宛先の情報は、当該メッセージの宛先すなわち受信側(送信先)のゲーム装置12の識別情報(メールアドレス)または他の端末のメールアドレスである。題目は、当該メッセージの標題である。
日時の情報は、当該メッセージを送信(または作成)した年月日および時間(時分秒)である。送信側のアプリケーションの識別情報(アプリID)は、当該アプリケーションを識別するための識別番号ないし識別記号である。この実施例では、当該メッセージを作成したアプリケーションの識別情報が記述される。上述の伝言板機能もアプリケーションの1つであるので、伝言板において作成されたメッセージにも伝言板を示す識別情報が含まれることになる。
受信告知属性は、当該メッセージを受信したことをユーザに告知するか否かを示す情報であって、たとえば「無し」と「パターンID」の値を示す。受信告知属性が「無し」を示す場合には、当該メッセージを受信しても受信側で告知処理が実行されない。しかし、受信告知属性が「パターンID」を示す場合には、当該メッセージを受信したことをパターンIDが示すパターンに従ってディスクスロット16の挿入口のLEDを明滅(点滅)させる。それ以外にも、パターンに従う音(音楽)を鳴らすようにしてもよい。
伝言板表示ON/OFF属性の情報は、当該メッセージを伝言板において表示するか否かを識別するための情報である。この実施例では、伝言板表示ON/OFF属性は、「ON」、「指定時間」、「OFF」の3種類で識別される。この属性が「ON」を示す場合には、当該メッセージは伝言板に表示される。また、かかる場合には、メッセージが伝言板に表示(掲載)されるとともに上述した受信告知が行われるようにしてもよい。図示は省略するが、たとえば、ゲーム装置12のディスクスロット16の挿入口を点滅させたり、音(音楽)を出力したりすることにより、メッセージの表示を告知することができる。また、この属性が「指定時間」を示す場合には、当該メッセージは到着(受信)してから指定時間以内は伝言板に表示されない。したがって、たとえば、ゲーム内のイベントの告知や或る日時にゲーム装置12を起動させたい場合に、「指定時間」が記述されたメッセージを送信する。さらに、この属性が「OFF」を示す場合には、当該メッセージは伝言板に表示されない。
伝言板日時指定の情報は、当該メッセージを伝言板に表示する年月日および時間を指定するか否かを示す情報である。この情報として、年月日および時間が指定されている場合には、当該メッセージは当該年月日および時間に伝言板に表示される。しかし、この情報として、年月日および時間が指定されていない場合には、当該メッセージは受信した日時に表示される。
上書きタグは、受信されたメッセージで上書きを行うか否かに関する情報である。この実施例では、上書きタグは、「ON」または「OFF」と、「上書きID」とが含まれる。当該メッセージ(説明の都合上、「今回のメッセージ」という。)についての上書きタグが「ON」を示すとき、送信元と、アプリIDと、上書きIDとのすべてが一致するメッセージ(説明の都合上、「前回のメッセージ」という。)が受信メッセージボックス44bに存在するかどうかを比較判断する。そして、送信元の情報、アプリIDおよび上書きIDのすべてが一致する場合には、今回のメッセージが前回のメッセージに上書きされる。つまり、同じアプリケーション用のデータで、同じ送信者からのメッセージについて最新のものだけが必要な場合(たとえばゲームのスコアの最高記録など)には、送信側のゲーム装置12において、当該アプリケーションがメッセージを作成する際に、上書きが「ON」を示し、同じ上書きIDを有するメッセージを作成するようにすれば、受信側で常に最新のメッセージに上書きされることになる。このようにすることで、無駄なメッセージによってフラッシュメモリ44の容量を圧迫することを防ぐことができる。しかし、送信元、アプリIDおよび上書きIDのいずれか一つでも異なる場合には、別の目的のメッセージであるということなので、今回のメッセージによって上書きされることはない。また、今回のメッセージについての上書きタグIDが「OFF」を示す場合にも、今回のメッセージが上書きされることはない。
他アプリ制限の情報は、当該メッセージをアプリIDで示されるアプリケーション以外のアプリケーションから参照可能にするかどうかを示す情報である。この情報が他のアプリケーションから参照可能な電子メール(メッセージ)であることを示す(他アプリ制限がオフである)場合には、当該メッセージは他のアプリケーションからも読取可能である。一方、この情報が他のアプリケーションから参照できないメッセージであることを示す(他アプリ制限がオンである)場合には、当該メッセージは他のアプリケーションから読み取ることが禁止される。ただし、他アプリ制限がオンである場合には、当該メッセージの内容を他のアプリケーションから参照できないだけであって、当該メッセージは伝言板には表示されるようにしてもよい。
なお、他の端末からの電子メールは、ゲーム装置12のアプリケーションで生成されるメッセージではないため、他アプリ制限の情報を含めることができず、当該電子メール(メッセージ)は、自動的にすべてのアプリケーションで参照可能となる。
消滅属性は、当該メッセージを受信側で自動的に消滅させるか否かを示す情報である。消滅属性が「消去せず」を示す場合には、受信側で当該メッセージを自動的に消滅させない。しかし、消滅属性が「指定時間」を示す場合には、当該メッセージを到着(受信)してから指定時間経過後に、受信側で当該メッセージを自動的に消滅させる。すなわち、受信したメッセージが伝言板機能等のアプリケーションで利用されないまま指定時間が経過した場合に当該メッセージが消滅するので、たとえばお知らせのような期限後には意味が無くなる性質の情報が含まれるメッセージについて、無駄に保存しておくことでフラッシュメモリ44の容量を圧迫することを防ぐことができ、期限が過ぎてしまった後でユーザに無駄な情報を与えることを防ぐこともできる。
代替ニックネームは、当該メッセージを表示する場合に、送信側から指定されるニックネームを表示するか否かを示す情報である。この情報が空の場合には、当該メッセージを表示するとき、送信者の情報として、アドレス帳に登録されたニックネームが参照され、当該ニックネームが表示される。また、代替ニックネームに文字列が含まれている場合には、当該メッセージを表示するとき、アドレス帳に登録されたニックネームに代えて、当該代替ニックネームの文字列が表示される。代替ニックネームに含まれる文字列は、名前に限らず、所定の文言を当該表示箇所に表示させるために用いることもできる。
返信属性は、当該メッセージへの返信が可能か否かを示す情報である。ユーザ同士がメッセージのやり取りを行う場合は返信ができるのが通常であるが、アプリケーションから自動的に作成されたメッセージ等(たとえばゲームプレイ結果の記録)については、ユーザが返信を行うべきでないような情報もあり得るため、このような返信属性を設定する。返信属性が「可」を示すとき、当該メッセージへの返信が可能である。かかる場合には、たとえば、伝言板機能で当該メッセージを表示している場合に、ユーザが返信することを選択(指示)すると、返信するためのメッセージ入力画面(図示せず)が表示され、返信メッセージの作成が可能となる。しかし、返信属性が「不可」であるとき、当該メッセージへの返信が不能である。かかる場合には、たとえば、伝言板機能で当該メッセージを表示している場合に、ユーザが返信することを選択(指示)できないようにしたり、当該メッセージに返信することができない旨のメッセージを表示したりする。
なお、上記のヘッダ情報の他に、一般的な電子メールにおいては、Cc,Bcc,Reply−To,Returnなどのヘッダ情報もあるが、本実施例においては、ゲーム装置12では、ヘッダに含まれる情報のうち使用しないものは送信データおよび受信データのいずれの場合であっても無視することとする。
図10は、ゲーム装置12に内蔵されるフラッシュメモリ44に記憶されるデータの構成を模式的に示した図解図である。この図10を用いて、本実施例におけるメッセージの送受信とダウンロード処理について概要を説明する。ゲーム装置12は、メールサーバ102とメッセージの送受信を行い、配信サーバ104からデータのダウンロードを行い、2種類の通信処理を行う。メッセージの送受信およびダウンロードの処理は、入出力プロセッサ42aによって実行される。フラッシュメモリ44は記憶領域として、送信メッセージボックス44a、受信メッセージボックス44b、管理用ファイル44c、フレンドリスト44d、タスクリスト44e、セーブ領域44f、データベース44gおよび本体アプリ領域44hを含む。
送信メッセージボックス44aは、ゲーム装置12から他のゲーム装置12や他の端末に送信する電子メール形式のメッセージ(送信データとする)を記憶する領域である。図10からも分かるように、送信データは、メールサーバ102に送信される。したがって、ゲーム装置12は、メールサーバ102およびネットワーク106を介して、他のゲーム装置12にメッセージを送信することができる。入出力プロセッサ42aは、所定のスケジュールに基づいて(たとえば、10分毎に)送信メッセージボックス44aを参照し、送信データが記憶されている場合には、記憶されている送信データをネットワーク106に送信する。送信データがネットワーク106に送信されると、当該送信データは送信メッセージボックス44aから削除される。
したがって、電子メールの送信を入出力プロセッサ42aがアプリケーションとは独立に行うので、伝言板機能やゲーム等、CPU40で実行されるアプリケーションでは、メッセージの作成後、当該メッセージを電子メール形式で送信メッセージボックス44aに記録しておく処理を行うだけで、メッセージをネットワークに対して送信することができる。
なお、本実施例においては、より汎用的な電子メール形式のデータをメールサーバと送受信するが、データの形式は電子メールに限られず、さまざまなフォーマットにて転用可能である。特にゲーム装置12同士の通信に限られる場合は、汎用的なフォーマットでなくともよいし、他の端末とも通信する場合であっても、当該端末で処理可能な汎用フォーマットであれば適用できる。また、サーバの種類も、端末からのアクセスまで送信されたデータを保持する性質のものであれば、メールサーバ以外の種類のサーバでもよい。
また、何らかの理由で送信機能が停止されていたり、通信障害が発生したりしている場合には、送信データの送信が行われないため、送信メッセージボックス44aのデータ量が一杯になる可能性がある。かかる場合には、送信メッセージの送信メッセージボックス44aへの登録を受け付けないようにする。
受信メッセージボックス44bは、他のゲーム装置12、他の端末や配信サーバ104から受信される電子メール形式のメッセージ(この実施例では、上記の「送信データ」に対して「受信データ」ということがある。)を記憶する領域である。図10からも分かるように、受信データは、メールサーバ102や配信サーバ104から送信される。入出力プロセッサ42aは、所定のスケジュールに基づいて(たとえば、10分毎に)メールサーバ102にアクセスして、サーバに新着メールがあるかどうかを確認し、新着メールがある場合に、当該新着メールを受信して受信データとして受信メッセージボックス44bに記憶する。受信メッセージボックス44bでは、受信データは、アプリケーションによって開かれ(使用され)削除されるか、当該受信メッセージボックス44bが一杯になるまで保持される。ただし、受信メッセージボックス44bが一杯になると、新たな受信データを受信する毎に、最も古い受信データから順に削除される。また、ゲーム装置12が通常モードである場合に、受信メッセージボックス44bに保持された受信データは、ゲームデータのようなアプリケーションに依存するデータが添付されたものを除いて、ヘッダ情報に従ってデータベース44gに移動され、伝言板機能によって読み出し可能な状態となる。
なお、メールサーバ102からの受信データは、他のゲーム装置12や他の端末からのメッセージである。また、配信サーバ104からの受信データは、配信サーバ104の管理者等からの複数ユーザに対するお知らせのようなメッセージである。たとえば、配信サーバ104の管理者等からは、新作のゲームアプリケーション(ゲームソフト)の情報やゲーム内におけるイベントの情報などのメッセージが送信(通知)される。配信サーバ104から受信したデータを受信メッセージボックス44bに記憶する処理の詳細については後述する。
管理用ファイル44cは、ゲーム装置12についての管理情報であり、ゲーム装置12の識別情報、ユーザのプロファイルなど、ゲーム装置12固有の情報が記憶され、必要に応じて読み出される。フレンドリスト44dは、いわゆる電子メールのアドレス帳に相当し、登録した他のゲーム装置12の識別情報(またはメールアドレス)および他の端末のメールアドレスが記述される。このフレンドリスト44dは、伝言板機能を実行する場合に参照可能であるのみならず、各種アプリケーションからも参照可能である。ただし、フレンドリスト44dに記述された他のゲーム装置12の識別情報および他の端末のメールアドレスのうち、後述するフレンド登録が実行された他のゲーム装置12の識別情報または他の端末のメールアドレスから送信された電子メール(受信データ)以外は削除される。つまり、送信元が不明である場合には、受信データがフィルタリングされる。これによって、スパムメールのような所望でない電子メールを自動的に削除することができる。
タスクリスト44eは、配信サーバ104からデータをダウンロードするスケジュールを表すタスクのリストであって、ゲーム装置12の必要のために予め登録されたタスクやユーザによって任意に登録されたタスクをそれぞれ記憶する。それぞれのタスクが実行されることによって、ダウンロード処理が行われることになる。ただし、この実施例では、1つのアプリケーションにおいては、1つのタスクを登録することができる。図26に、各タスクに含まれる属性情報の一例を示す。1つのタスクには、タスクの識別情報(タスクID)、アプリケーションの識別情報(アプリID)、配信元のURL、残りダウンロード回数、タスクの起動間隔、リトライマージン、コンテンツ更新間隔およびファイル名が含まれる。
タスクIDは、当該タスクを一意に識別するためのIDである。アプリIDは、当該タスクを登録したアプリケーションを一意に識別するためのIDである。このアプリIDは、タスクの登録処理を行ったアプリケーションに応じて決定される。
配信元のURLは、配信元(配信サーバ104)の場所を示し、ダウンロードデータのファイル名までを含む。この配信元のURLは、ユーザによって設定されたり、アプリケーションによって自動的に設定されたりする。
残りダウンロード回数は、ダウンロードを実行可能な回数を示す。この実施例では、ゲーム装置12(入出力プロセッサ42a)がダウンロードのために、ネットワーク106(配信サーバ104)に接続要求(リクエスト)を送信すると、通常の場合において残りダウンロード回数が1減算される。そして、残りダウンロード回数が0になると、当該タスクはタスクリスト44eから削除され、当該タスクは実行不能となる。残りダウンロード回数を設定することにより、必要な期間において当該ダウンロードを行わせることができ、ダウンロードが不要になっても無駄なダウンロード処理を実行し続けることを防ぐことができる。
タスクの起動間隔は、タスクを実行する時間間隔であり、具体的には、タスクを実行してから次にタスクを実行するまでの時間(期間)を意味する。ただし、タスクを登録した時点では、その登録時刻を基準にして、次にタスクを実行する時間が決定される。このタスクの起動間隔は、ユーザによって設定されたり、ダウンロードデータ(コンテンツ)の種類に応じて自動的に設定されたりする。
リトライマージンは、ダウンロードの起動間隔によって決まる次回のタスクの実行時刻(予定時刻)を超過することが許容される時間である。たとえばゲーム装置12の電源が完全にOFFされている場合や、ネットワークに障害が生じている場合等には、タスクを実行することができず、次にタスクが実行可能な状態になった場合にはタスクの予定時刻を超過している場合があるが、予定時刻を大幅に超過した場合には、既にダウンロードされるデータ自体が不要なものになっている場合がある。したがって、タスク登録時に上記リトライマージンを設定し、タスクの起動間隔に応じてタスクの予定時刻が決定されると、リトライマージンに応じて、リトライが許容される時刻(リトライ許容時刻)が決定される。このリトライ許容時刻を越えると、当該タスクは実行されず、その後、タスクリスト44eから削除される。このリトライマージンは、ユーザによって設定されたり、ダウンロードデータの種類に応じて自動的に設定されたりする。
コンテンツ更新間隔は、配信元のURLに関して当該配信元で設定されるコンテンツ(ダウンロードデータ)を更新する間隔の平均値である。したがって、ダウンロードデータの種類によっては、このコンテンツ更新間隔が示すダウンロードデータを更新する間隔の平均値を考慮して、タスク起動間隔が設定される。具体的には、タスク起動間隔をコンテンツ更新間隔よりも長い時間に設定しておけば、同じダウンロードデータを重複して取得するような無駄を無くすことができる。逆に、タスク起動間隔をコンテンツ更新間隔よりも短い時間に設定しておけば、更新されるコンテンツのダウンロードを逃すことが無くなる。更新間隔の平均値は、予め想定されている値でもよいし、ダウンロードを実行する毎に配信サーバ104から更新間隔の平均値を取得してタスクを更新するようにしてもよい。
ファイル名は、ダウンロードデータを保存する場合に付与するファイル名であり、たとえば、オプションによって指定可能である。ただし、ダウンロードデータにはファイル名が付されているため、ファイル名を指定せずとも所定のファイル名でデータを取得することは可能である。
なお、タスクの実行については後で詳細に説明する。ダウンロードデータは、その識別情報(アプリID)が示すアプリケーションにおいて利用することができる。たとえば、ゲームのアプリケーションにおいては、ダウンロードデータは、当該ゲームについての追加マップ、追加キャラクタ、追加アイテムなどのデータである。
図10に戻って、セーブ領域44fは、アプリケーションのデータを保存(セーブ)する領域であり、領域内にダウンロードボックス440を含む。ダウンロードボックス440は、上述したように、タスクに従って配信サーバ104からダウンロードされたダウンロードデータが記憶される領域である。詳細な説明は省略するが、ダウンロードデータには、タスクが登録されたアプリケーションを識別するためのアプリIDが予め付されている。ただし、アプリIDは必ずしもダウンロードデータに予め付されている必要はなく、他の実施例ではダウンロードボックス440に登録する際に、タスクの属性情報が示すアプリIDを参照して、これを付すようにしてもよい。したがって、様々な種類のアプリケーションについてのダウンロードデータがダウンロードボックス440に記憶されている場合であっても、そのアプリIDによって各ダウンロードデータを識別することができる。また、セーブ領域44fは、アプリケーション毎に領域が確保されている。したがって、他の実施例では、ダウンロードデータに対応したアプリケーションのデータを記憶する領域内にアプリケーション毎のダウンロードボックスを設けるようにしてもよい。
データベース44gは、上述の伝言板機能によって利用される、日付毎のメッセージを格納しておく領域であり、他のアプリケーションからも参照可能である。上述したように、受信データは受信メッセージボックス44bに記憶されるが、受信メッセージボックス44bの容量は有限であり、一杯になると、受信データは古いものから順に削除する。したがってメッセージの長期間保存や共用化のために、データベース44gを設け、受信データ(メッセージ)は、たとえばゲームデータが添付されたもののような、のような個々のアプリケーションでしか利用しないものを除いて、受信メッセージボックス44bからデータベース44gに移動される。このとき、メッセージのヘッダ情報が参照され、日付毎に管理されるデータベース44gの各領域に記憶される。たとえば、伝言板日時指定の情報として年月日および時間が記述されている場合には、当該受信データは指定された年月日に対応する領域に記憶される。ただし、メッセージのヘッダ情報に日時等の指定が無ければ、当該メッセージを受信した日に対応する領域に、当該メッセージは記憶される。日付毎の領域の管理方法としては、たとえば日付毎にフォルダを設定し、メッセージを対応するフォルダ内に保存するようにすればよい。また、保存する際のファイル名を、時刻を表わすファイル名にしてもよい。
なお、図示は省略するが、メモリカードがメモリカード用コネクタ62に装着されている場合には、データベース44gの内容はメモリカードに自動的またはユーザの指示によりバックアップすることができる。
本体アプリ領域44hは、本体機能として組み込まれたアプリケーションのプログラム(ソフト)を記憶する領域である。たとえば、ゲーム装置12を起動した際のメニュープログラムや、伝言板機能、フレンド登録機能のようなゲーム装置12自体の機能(本体機能)のアプリケーションは、本体アプリ領域44hに記憶(インストール)されている。つまり、ゲーム装置12は、光ディスク18に記憶されているゲーム等のプログラムを読み出してアプリケーションを実行することも、フラッシュメモリ44に記憶されているプログラムを読み出してアプリケーションを実行することも可能なゲーム装置である。また、本体アプリ領域44hに記憶されるプログラムは上述のソフト以外にも追加することが可能である。
次に、図11および図12を参照して、フレンド登録の手順について説明する。フレンド登録は、予めメッセージの送受信を許可する相手をフレンドリスト44dに登録しておくものである。本実施例においては、メールサーバ102から受信するメッセージのうち、フレンド登録が行われていない送信元から送信されたメッセージは自動的に削除される。つまり、ゲーム機12同士でメッセージのやり取りを行う場合には、互いのゲーム機12において相手をフレンド登録しておく必要がある。ここで、フレンド登録においては、一方的に登録が行われている状態ではなく、相互に登録の意思があることが確認されている関係が確立されるべきであるが、以下では、当該関係を「フレンド関係」と呼ぶ。具体的には、ゲーム装置12同士で互いにフレンド登録が行われ、相互の登録の確認が完了した状態、およびゲーム装置12と他の端末との間において、ゲーム装置12が他の端末を登録し、他の端末において当該登録を許可したことをゲーム装置12側で確認した状態である。したがって、フレンド関係を確立させるために、ゲーム装置12と、他のゲーム装置12またはそれ以外の端末との間で、それぞれ以下のような手順が実行される。図11はゲーム装置12同士でのフレンド登録の手順を示し、図12はゲーム装置12と他の端末とのフレンド登録の手順を示す。このフレンド登録は、メッセージの送受信よって行われる。つまり、各ゲーム装置12の入出力プロセッサ42aにおける処理を経てフレンド登録が実行される。
なお、図11では、2台のゲーム装置12を分かり易くするために、一方のゲーム装置12を「ゲーム装置A」と呼び、他方のゲーム装置12を「ゲーム装置B」と呼ぶことにする。また、図12では、ゲーム装置12を「ゲーム装置C」と呼び、他の端末を「端末D」と呼ぶことにする。
また、フレンド登録では、その登録に先立って、ユーザ同士予め連絡をとったり直接話し合っておいたりすることにより、ゲーム装置12の識別情報や他の端末のメールのアドレスを互いに知っている必要がある。ただし、1人のユーザが所有するゲーム装置12と、他の端末とをフレンド登録する場合には、当該ユーザが他の端末のメールアドレスを知っていればよい。以下、時間軸に従ってフレンド登録の手順を説明する。
まず、図11を参照して、ゲーム装置12同士の間でフレンド関係を確立させる手順を説明する。フレンドリスト44dへの登録は、それぞれのゲーム装置12においてそれぞれのユーザが行うものであるので、登録のタイミングは異なることになるが、ここでは先に登録を行ったゲーム装置12をゲーム装置Aとして説明する。ゲーム装置Aのユーザが、当該ゲーム装置Aのフレンドリスト44dにゲーム装置Bのメールアドレス(識別情報)を入力し、登録する。すると、ゲーム装置Aは、ゲーム装置Bのメールアドレスをアドレス帳(フレンドリスト44d)に登録した旨のメッセージ(登録メッセージ)をゲーム装置Bに自動送信する。上述したように、登録メッセージは、電子メールの形式で送信される。ただし、ここでは、ゲーム装置12同士で自動的にメッセージが送受信されるため、ゲーム装置12で解読可能であればよい。したがって、この登録メールは、単にアルファベットや数字を並べた文字列のように、人間が解読できないメッセージであってもよいし、空のメールであってもよい。以下、ゲーム装置12同士で自動的にメッセージを送受信する場合について同様である。
一方、ゲーム装置Bでは、当該登録メッセージを受信するが、上述のように、それぞれのユーザで登録のタイミングは異なり、この段階ではゲーム装置Aのメールアドレスが未登録であるため、ゲーム装置Bは、ゲーム装置Aからの登録メッセージを受信すると、そのままこの登録メッセージを削除する。この時点では、ゲーム装置Aにおいて、ゲーム装置Bとの間のフレンド関係が成立していない状態である。当然のことながら、ゲーム装置Bにおいても、ゲーム装置Aとの間のフレンド関係は成立していない。
その後、ゲーム装置Bのユーザが、当該ゲーム装置Bのフレンドリスト44dにゲーム装置Aのメールアドレスを登録すると、ゲーム装置Bは、ゲーム装置Aのメールアドレスをアドレス帳に登録した旨の登録メッセージをゲーム装置Aに自動送信する。ゲーム装置Aでは、既にゲーム装置Bのメールアドレスがフレンドリスト44dに登録されているため、ゲーム装置Aは、ゲーム装置Bから送信された登録メッセージを受信して、受信メッセージボックス44bに保持する。このことによって、互いに登録を行ったことが確認されるので、ゲーム装置Aにおいて、ゲーム装置Bとの間のフレンド関係が成立する。そして、ゲーム装置Aは、ゲーム装置Bから登録メールを受信した旨の確認メッセージ(受信確認メッセージ)をゲーム装置Bに自動送信する。
この時点においては、ゲーム装置Bでは、既にゲーム装置Aのメールアドレスがフレンドリスト44dに登録されているため、ゲーム装置Bは、ゲーム装置Aから送信された受信確認メッセージを受信して、受信メッセージボックス44bに保持する。このことによって、互いに登録を行ったことが確認されるので、ゲーム装置Bにおいて、ゲーム装置Aとの間のフレンド関係が成立する。そして、ゲーム装置Bは、ゲーム装置Aと同様の処理が行われるため、受信確認メッセージをゲーム装置Aに自動送信する。ゲーム装置Aは、ゲーム装置Bからの受信確認メッセージを受信するが、この時点で既にフレンド関係は成立しているので、これに対して返信等の処理を何らすることなく、その後、この受信確認メッセージは受信メッセージボックス44bから削除される。
上記のように、それぞれのゲーム装置12において、アドレス登録後に登録メッセージを自動送信し、登録後にメッセージを受け取った場合にフレンド関係を確立し、受信確認メッセージを送信するという処理を行うという同様の処理をそれぞれ行うことによって、登録後のフレンド関係確立が自動的に行われる。
次に図12を参照して、ゲーム装置12と他の端末との間でフレンド関係を確立させる手順を説明する。他の端末は電子メールの処理が可能な汎用的な端末であって、ゲーム機12の入出力プロセッサ42a等の構成を備えているものではないので、ゲーム装置12と他の端末との場合には、ゲーム装置12側からしか登録を開始できないこととする。ゲーム装置Cのユーザが、ゲーム装置Cのフレンドリスト44dに端末Dのメールアドレスを登録すると、ゲーム装置Cは登録メッセージを端末Dに送信する。ただし、端末Dは、ゲーム装置12ではなく、ゲーム装置Cにメッセージを送信するためには、端末Dのユーザがゲーム装置Cにメッセージを返信する必要がある。したがって、登録メッセージは、端末Dのユーザ(人間)が解読可能な形式で返信を促すメッセージを送信する必要がある。たとえば、「このメールに返信すれば、ゲーム装置Cとの間で電子メールの送受信が可能になります。」のような本文を含む登録メッセージが送信される。この時点では、ゲーム装置Cにおいて、端末Dとの間のフレンド関係は成立していない。
その後、端末Dのユーザが、ゲーム装置Cからの登録メッセージに対するメッセージを当該ゲーム装置Cに返信する。ゲーム装置Cでは、既に端末Dのメールアドレスがフレンドリスト44dに登録されているため、端末Dからのメッセージを受信したときに、端末Dとの間のフレンド関係が成立する。
なお、端末Dにおいては、フレンド関係の確立を確認することができないので、ゲーム装置Cからフレンド関係確立とともに受信確認メッセージを送信する必要はない。
また、上述したように、この実施例では、2台のゲーム装置12のうち、一方のゲーム装置12に他方のゲーム装置12のメールアドレスが登録されただけの状態である場合には、フレンド関係は成立していない。かかる場合には、図示は省略するが、一方のゲーム装置12に登録されたアドレスは薄い灰色で表示し、その後、フレンド関係が成立したときに、黒色で表示するようにして、フレンド関係の確立の有無をユーザが認識できるようにしてもよい。ただし、これは単なる一例であり、同じ色で輝度の違いにより表示を変えたり、異なる色で表示を変えたりすることもできる。また、ゲーム装置12では、フレンドリスト44dに登録してあるゲーム装置12や他の端末とのフレンド関係の成立の有無を当該フレンドリスト44dにおいて、たとえばフラグ等によって判別する。たとえば、フレンド関係の成立したゲーム装置12の識別情報(またはメールアドレス)や他の端末のメールアドレスに対応するフラグがオンされる。一方、フレンド関係の成立していないゲーム装置12の識別情報(またはメールアドレス)や他の端末のメールアドレスに対応するフラグがオフされる。当該フラグを参照することによって、登録メッセージ以外の通常のメッセージの作成を可能とするか禁止するか、そして受信したメッセージを削除するか受信メッセージボックス44bに保存するかを決定することができる。ただし、フラグ以外の手段であっても、たとえば、フレンド関係確立前のアドレスと確立後のアドレスとを別の領域に記憶するようにして識別するようにしてもよい。
次に、入出力プロセッサ42aによって実行されるダウンロード処理の概要について説明する。この実施例では、ダウンロードデータは、配信サーバ104から取得される。図13(A)に示すように、或るタスクがタスクリスト44eに登録されると、その時刻t1を基準に当該タスクがスケジューリングされる。たとえば、図13(A)に示す例では、タスクの実行間隔T1に従って時刻(予定時刻)t2に当該タスクがスケジューリングされる。なお、この実行間隔T1が、当該タスクの属性情報のタスク起動間隔に相当する。時刻は、ROM/RTC48から得ることができる。タスクが実行されると、当該実行時刻に実行間隔T1を加えた予定時刻に、次回タスクが実行される。ダウンロードのタスクは、ダウンロード実行とともに残りダウンロード回数が1減算され、このとき、次回タスクを実行する予定時刻(実行予定時刻)がスケジューリングされる。
図13(B)に示すように、入出力プロセッサ42aの内部では、処理の単位時間となる所定時間毎にトリガが発生し、当該トリガ発生時に、トリガ発生時刻と、前述のメッセージの送受信を行う予定時刻や、ダウンロードを行う予定時刻等とを比較する処理が行われ、予定時刻を超過している場合に当該処理が起動することになる。したがって、トリガの発生時よりも後にタスクがスケジューリングされている場合には、当該タスクは次回のトリガの発生時に実行されるため、タスクの実際の実行時刻は、図13(A)でスケジューリングした予定時刻t2から若干遅れてしまうことがある。
また、図13(C)に示すように、スタンバイモードではなく、ゲーム装置12の電源が完全にオフされた場合のように、タスクの実行自体が停止される場合も有り得る。かかる場合には、再びゲーム機12が起動した後にタスクが実行されることになるが、タスクの実行時刻にかなりの遅れが生じてしまうことがある。
なお、タスクの実行は、アプリケーションからの要求によって、一時的に停止させたり、再開させたりすることが可能であって、そのような場合にもタスクの実行時刻に遅れが生じる可能性がある。
このように、タスクの実行時刻の遅延が発生した場合、ダウンロードするデータが既に不要なものになっている場合があるので、遅延が発生した場合に、当該タスクの実行を許容するか否かを決定するために、タスクの属性情報として、リトライマージンが設定されている。具体的には、タスクを実行するとき、タスクの実行を開始する時点(現在時刻)が、タスクの実行予定時刻にリトライマージンが示す時間を加算したリトライ許容時刻を越えているかどうかを判断する。そして、現在時刻がリトライ許容時刻を越えている場合には、タスクの実行は行わずに、当該タスクはタスクリスト44eから削除される。一方、現在時刻がリトライ許容時刻に満たない場合には、当該タスクを実行し、以降の処理を続行する。
以下、CPU40および入出力プロセッサ42aのそれぞれで実行されるソフトウェアの処理を具体的に説明する。図14は、図2に示したCPU40で実行されるゲームアプリケーション処理を示すフロー図である。ただし、本実施例ではゲームアプリケーションを例として説明するが、ゲーム以外のアプリケーションであっても適用可能であることはいうまでもない。図14を参照して、CPU40がゲームアプリケーション処理を開始すると、ステップS1で、ゲーム終了かどうかを判断する。ここでは、ゲームオーバになったり、プレイヤの指示に従ってゲームを終了したりしたかどうかを判断する。ステップS1で“YES”であれば、つまりゲーム終了であれば、そのままゲームアプリケーション処理を終了する。一方、ステップS1で“NO”であれば、つまりゲーム終了でなければ、ステップS2でゲーム処理を実行する。ここでは、CPU40は、プレイヤの操作に従ってプレイヤキャラクタに任意のアクションを実行させたり、ノンプレイヤキャラクタの移動等を制御したりする。このとき、CPU40の指示の下、GPU42bは、ゲーム画像データを生成(更新)する。また、必要に応じて、CPU40の指示の下、DSP42cは、音データを生成する。これにより、ゲームが進行される。
以降、ゲーム処理実行中において、送信データの作成や、受信データの取得、ダウンロードデータの取得の指示が発生する場合について説明する。ここでは、CPU40は、プレイヤの操作やゲームイベントの発生により、それらの指示が入力されたかどうかを判断する。
なお、アプリケーションの種類によっては、送信データ、受信データ、ダウンロードデータのうちいずれかのデータしか用いないアプリケーションもあり得るため、すべての指示の判断処理が必ずしも実行されるものではない。
まず、ステップS3で送信データの作成指示があったかどうかを判断し、“YES”であれば、つまり送信データの作成指示があれば、図27に示すステップS4の送信データ作成処理に進む。一方、ステップS3で“NO”であれば、つまり送信データの作成指示がなければ、ステップS5に進む。
次に、ステップS5において、受信データの取得指示があったかどうかを判断し、“YES”であれば、つまり受信データの取得指示があれば、図28に示すステップS6の受信データ取得処理に進む。一方、ステップS5で“NO”であれば、つまり受信データの取得指示がなければ、ステップS7に進む。
次に、ステップS7において、ダウンロードデータの取得指示があったかどうかを判断し、“YES”であれば、つまりダウンロードデータの取得指示があれば、図15に示すステップS8のダウンロードデータ取得処理に進む。一方、ステップS7で“NO”であれば、つまりダウンロードデータの取得指示がなければ、ステップS1に戻る。以上の処理によって、ゲーム処理を実行しながら必要に応じて受信データ、送信データ、ダウンロードデータの利用を行うことができる。なお、図示は省略するが、ユーザの指示やイベントに応じて、ダウンロードのタスクを所定の条件で生成し、タスクリスト44eに格納する処理が含まれていてもよい。
次に、上述のステップS4の送信データ作成処理、ステップS6の受信データ取得処理、ステップS8のダウンロードデータ取得処理のそれぞれについて、処理の詳細を説明する。
まず、ステップS4の送信データ作成処理について、図27を参照して説明する。まず、ステップS9においてメッセージ内容が作成される。メッセージ内容は電子メールの本文に相当するものであって、ソフトウェアキーボードを表示させるなどしてユーザから入力された内容や、ゲーム処理において生成されたデータに基づいて自動的に生成された内容等である。次に、ステップS10において、前記内容の本文を含む電子メール形式のメッセージが生成される。ここでは、宛先の指定等が行われ、図9のヘッダ情報がメッセージに付与される。
次に、ステップS11において、宛先がゲーム機12自身のものであるかどうかを判断する。ゲーム機12自身の宛先は、上述のように管理用ファイル44cに記憶されているので、当該宛先を読み出して、メッセージの宛先と比較される。ステップS11で“YES”の場合は、ステップS12において作成した電子メールを受信メッセージボックスに記憶する。これは、たとえば伝言板機能等を用いてユーザが閲覧する、メモや伝言、ゲームの結果等が作成された場合であって、受信メッセージボックスに記憶しておくことによって、閲覧用に別の処理を行わなくとも、他の受信データとどうように閲覧することができる。
ステップ11で“NO”の場合は、ステップS13において、作成した電子メールを送信メッセージボックスに記憶する。当該メッセージは、入出力プロセッサ42aにおいて、CPU40とは独立した処理において適宜のタイミングでネットワークに送信されるので、ゲームプログラムにおいては、データを作成して記憶する処理が含まれていればよく、複雑な送受信用プログラムを用意する必要がない。
次に、ステップS6の受信データ取得処理について、図28を参照して説明する。まず、ステップS14で、受信メッセージボックス44bを確認する。続いて、ステップS15では、当該アプリケーション宛のアプリIDを有する受信データまたは閲覧可能な受信データがあるかどうかを判断する。つまり、CPU40は、受信メッセージボックス44bに格納されているそれぞれの受信データのヘッダ情報を参照して、アプリIDが当該アプリケーションを示すアプリIDと一致するかどうかを判断する。そして、CPU40は、アプリIDが当該アプリケーションを識別する情報である場合に、当該受信データを取得する。また、CPU40は、アプリIDが当該アプリケーションのアプリIDと一致しない場合であっても、他アプリ制限がオフであれば、必要に応じて当該受信データを取得することが可能である。なお、CPU40は、これら以外の受信データを取得しない。
ステップS15で“NO”であれば、つまり当該アプリケーション宛のアプリIDの受信データまたは閲覧可能な受信データが存在しなければ、そのまま受信データ取得処理を終了してリターンする。一方、ステップS15で“YES”であれば、つまり当該アプリケーション宛のアプリIDの受信データまたは閲覧可能な受信データが存在すれば、ステップS16で、当該受信データを受信メッセージボックス44bから読み出す。次のステップS17で、取得した受信データをゲームデータとしてメインメモリ(42e,46)に記憶する。したがって、受信データがその後のゲーム処理に利用される。たとえば、その後のゲーム処理によって、当該受信データをセーブ領域44fに格納しておくようにしてもよいし、ゲーム処理に利用した後はメインメモリから破棄するようにしてもよい。
そして、ステップS18では、取得した受信データが当該アプリケーション宛の受信データであるかどうかを判断する。ステップS17で“NO”であれば、つまり当該アプリケーション宛の受信データでなければ、そのまま受信データ取得処理を終了してリターンする。つまり、他のアプリケーション宛の受信データは本来他のアプリケーションによって利用されるものであるため削除を禁止する。一方、ステップS18で“YES”であれば、つまり当該アプリケーション宛の受信データであれば、データ取得後は、通常はメッセージボックス44bに残しておく必要がないのでステップS19で、当該受信データを受信メッセージボックス44bから削除して、リターンする。ただし、CPU40は、当該受信データのヘッダ情報の消滅属性が「消去せず」を示す場合には、当該受信データが当該アプリケーション宛であっても、ステップS19の処理を実行せずにリターンする。
次に図15を参照して、ステップS8のダウンロードデータ取得処理について説明する。まず、ステップS23で、ダウンロードボックス440を確認する。そして、ステップS25で、当該アプリケーションのダウンロードデータがあるかどうかを判断する。つまり、CPU40は、当該アプリケーションのアプリIDが付されたダウンロードデータがダウンロードボックス440に記憶されているかどうかを判断する。
ステップS25で“NO”であれば、つまり当該アプリケーションのダウンロードデータがなければ、そのままリターンする。一方、ステップS25で“YES”であれば、つまり当該アプリケーションのダウンロードデータがあれば、ステップS27で、当該ダウンロードデータをダウンロードボックス440から読み出し、ステップS29で、取得したダウンロードデータをゲームデータとしてメインメモリ(42e,46)に記憶して、リターンする。したがって、ダウンロードデータがその後のゲーム処理に利用される。
なお、CPU40は、内部メインメモリ42eおよび外部メインメモリ46のいずれにも高速にアクセス可能であるため、受信データやダウンロードデータはいずれのメモリに記憶するようにしてもよい。たとえば、ゲームアプリケーション(ゲームプログラム)やゲームデータによって利用されているメモリと同じ方のメモリに、受信データやダウンロードデータを記憶してもよい。
また、この実施例では、CPU40がゲームアプリケーション処理を実行する場合について説明したが、アプリケーションの種類はこれに限定される必要はなく、たとえば画像閲覧ソフトのような他の種類のアプリケーションであっても同様の処理を実行することができる。
たとえば、前述の伝言板機能もアプリケーションであるので、同様の処理が行われるが、伝言板機能は主としてメッセージの作成と閲覧のためのアプリケーションであるので、ステップS7およびS8の処理は行われない。以下、図16ないし図18を参照して、伝言板機能について、上述の一般的な(ゲーム)アプリケーションよりも詳細に具体的な処理を説明する。なお、ここでいう伝言板機能には、伝言板の表示に係る処理だけでなく、ゲーム装置12の電源がオンされたときやゲーム装置12の電源がオンである場合に自動的に実行される、受信データの処理をも含むものとして説明する。
図16を参照して、CPU40は、ゲーム装置12の電源がオンのとき、たとえばメニュー画面を表示しているとき等に、定期的にステップS41で、受信メッセージボックス44bにメッセージ(受信データ)があるかどうかを判断する。ステップS41で“NO”であれば、つまり受信メッセージボックス44bにメッセージがなければ、そのままステップS45に進む。一方、ステップS41で“YES”であれば、つまり受信メッセージボックス44bにメッセージがあれば、ステップS43で、当該メッセージをそのヘッダ情報に従って日付毎にデータベース44gに記憶して、ステップS45に進む。つまり、伝言板において日付ごとにメッセージを表示するために、受信メッセージボックス44b内の受信データをデータベース44gに移動させておく。日付毎にデータベース44gに記憶する方法としては、例えば日付毎にフォルダを生成し、メッセージの日付に対応するフォルダに当該メッセージを格納するようにしてもよい。また、メッセージのファイル名を時刻を表す名称にしてもよい。
ステップS45では、伝言板の表示指示があるかどうかを判断する。ステップS45で“YES”であれば、つまり伝言板の表示指示があれば、図18に示すステップS46の伝言板表示処理に進む。一方、ステップS45で“NO”であれば、ステップS41に戻る。つまり、伝言板機能全体としては、伝言板の表示を行っていないときであっても受信データをデータベース44gに移動させていることになる。また、伝言板の表示中であっても、当該受信データの移動は行っていてもよく、そのようにすれば、メッセージを閲覧しながらリアルタイムに新しく受信したメッセージを確認することができる。
次に、図18を参照して、ステップS46の伝言板表示処理について説明する。まず、ステップS60で、日付の指定がされたかを判断する。伝言板は、図25で示すように、メッセージを日付毎に一覧表示するものであって、日付の指定を変更すれば、当該日付におけるメッセージを閲覧することができる。なお、デフォルトの指定日としては、伝言板の表示が行われた日、つまり「今日」が指定されているものとして、伝言板表示が終了するまでは随時変更が可能となっている。なお、今日の日付(年月日)は、ROM/RTC48にアクセスして取得することができる。
ステップS60で“YES”の場合、つまり指定日付の変更があった場合は、指定された日付に変更を行う。“NO”の場合は、同じ日付のまま、後述の表示に係る処理を続行する。
ステップS62において、背景や他のオブジェクトの配置等が行われ、メッセージ以外の表示に係る処理が行われる。ステップS63において、データベース44g内に指定された日付のメッセージが存在するか否か判定される。具体的には、たとえば前述の日付毎のフォルダにメッセージを格納する実施例においては、当該日付に対応するフォルダ内にファイルが存在するか否か判定される。ステップS63で“NO”の場合、表示すべきメッセージが存在しないので、そのままメッセージ以外の背景等が表示されるだけで、リターンされる。
ステップS63で“YES”の場合、ステップS64において、CPU40はデータベース44gから当該日付のメッセージを読み出す。たとえば、前述の実施例の場合、当該日付に対応するフォルダ内のファイルを全て読み出すようにする。そして、ステップS65において、読み出されたメッセージの表示に係る処理が行われ、図25に示すようなメッセージの一覧が表示されることになる。
図16の説明に戻って、ステップS47において、伝言板の表示を終了するか否かが判定される。たとえば、ユーザからの指示があった場合には、伝言板の表示が終了されることになる。したがって、ステップS47で“YES”の場合、ステップS41に戻る。
ステップS47で“NO”の場合、伝言板の表示は続行されるが、次に、ステップS48において、メッセージの入力の指示があったか判定される。伝言板には、たとえば図25に示すように、メッセージ作成ボタンが表示され、ユーザの指示によって、メッセージの作成が可能である。たとえばそのメッセージ作成ボタンがユーザに操作される等の条件によって、ステップS48が“YES”の場合には、図17で示すステップS49のメッセージ入力処理が行われる。“NO”の場合には、ステップS46に戻り、伝言板の表示が続行される。
図17のメッセージ入力処理は、図27で示される送信データ作成処理とほぼ同様の処理であって、メッセージの作成手段がユーザからの入力のものである。すなわち、ステップS50において、ユーザからのメッセージの入力を受け付ける。この場合は、たとえばソフトウェアキーボードを表示するなどして、入力の受付を行う。なお、図示は省略するが、ユーザが宛先やメッセージの入力の中止を指示した場合には、宛先やメッセージの入力を中止して、つまりメッセージ作成を止めて、図16に示すステップS47に戻る。次に、ステップS51において、メッセージの入力が終了したか否か判定される。ステップS51で“NO”であれば、つまりメッセージの入力を終了していなければ、メッセージの入力中であるので、ステップS50に戻る。一方、ステップS51で“YES”であれば、つまりメッセージの入力を終了すれば、図17に示すステップS53で、入力されたメッセージについての電子メールを作成する。
以降、ステップS53−S59における処理については、図27のステップS10−S13の処理と同様であるので説明を省略する。メッセージ入力処理終了後は、ステップS46の伝言板表示処理に戻り、再び終了までメッセージ一覧の表示が行われる。
次に、図19ないし図21を参照して、図2に示した入出力プロセッサ42aがメッセージの送受信を行うメッセージ送受信処理を説明する。以下の処理は、CPU40とは独立に行われ、上述のスタンバイモードの間であっても、入出力プロセッサ42aには電力が供給されるので実行される。したがって、ユーザがゲーム装置12を起動していない間であっても、スタンバイモードの元でゲーム装置12は自動的に通信処理を行っているので、ユーザがゲーム装置12を起動すると、新しいメッセージが既に届いている状態となっていて、すぐにメッセージを閲覧することができる。上述したように、入出力プロセッサ42aは、所定の単位時間毎に発生するトリガに応じて処理を実行する。まず、トリガが発生すると、ステップS81で、送受信予定時刻であるかどうかを判断する。ここでは、入出力プロセッサ42aは、ROM/RTC48に設けられる時計回路から時間を取得して、予め設定しておいた送受信予定時刻になったかどうかを比較判断する。
ステップS81で“NO”であれば、つまり送受信予定時刻でなければ、そのまま同じステップS81に戻って、次のトリガが発生するまで待機する。言い換えれば、送受信予定時刻を超過するまでステップS81の処理がトリガ発生毎に繰り返される。一方、ステップS81で“YES”であれば、つまり送受信予定時刻であれば、ステップS83で、メールサーバ102に接続する。続くステップS85で、新着メール(新着メッセージ)すなわち受信データがサーバにあるかをチェックし、同時にステップS87で、次回アクセス期間をメールサーバ102から取得する。ただし、通常、ゲーム装置12(入出力プロセッサ42a)は、所定時間(たとえば、10分)毎にメールサーバ102にアクセスするよう設定されており、当該所定時間を毎回サーバから取得する。次回アクセス期間の変更は、たとえば、メンテナンスや、負荷の増大での対応などの理由により、アクセス期間をずらす場合等に行われる。
続いて、ステップS89では、受信データまたは送信データがあるかどうかを判断する。ここでは、入出力プロセッサ42aは、ステップS85の新着チェックの結果から、これから受信すべき受信データの有無を判断し、また、送信メッセージボックス44aにアクセスして送信が必要な送信データの有無を判断する。ステップS89で“NO”であれば、つまり受信データおよび送信データが無ければ、送受信処理は不要であるので、そのままステップS81に戻る。ステップS81によって、送受信が不要な場合には新着チェックのみで送受信を行わないことになるので、ネットワークの負荷を軽減することができる。一方、ステップS89で“YES”であれば、つまり受信データまたは送信データ或いはそれらの両方が有れば、サーバと送受信を行う必要があるので、ステップS91で、メールサーバ102との間でデータを送受信する。ここでは、入出力プロセッサ42aは、送信メッセージボックス44aに記憶された送信データをネットワーク106に送信する送信処理を実行するとともに、ネットワーク106を介してメールサーバ102から受信データを受信する受信処理を実行する。
続くステップS93では、ステップS91において送信したすべての送信データを、送信メッセージボックス44aから削除する。ただし、入出力プロセッサ42aは、送信データが送信メッセージボックス44aに格納されておらず、ステップS91において送信データの送信処理を実行していない場合には、ステップS93の削除処理では何も行われず、そのままステップS95に進む。ステップS95では、ステップS91において受信したすべての受信データを、バッファに記憶(一時記憶)する。図示は省略するが、内部メインメモリ42eまたは外部メインメモリ46にバッファ領域が設けられる。バッファに記憶された受信データはステップS94で受信メールボックス44bに記憶されるが、この際にステップS96のフィルタリング処理や、ステップS97の上書き確認処理等の処理が行われる。
なお、新着チェックの結果、受信データが無い場合、つまり送信のみの場合には、ステップS95以降の処理では何も行われず、そのままステップS81に戻ることになる。
次に、図21を参照して、ステップS96のフィルタリング処理について説明する。まず、ステップS111で、受信メッセージボックス44bに記憶されているすべての受信データのヘッダ情報およびフレンドリスト44dを参照して、それぞれの送信元との間でフレンド関係が成立しているかどうかを判断する。たとえば、入出力プロセッサ42aは、フレンドリスト44dを参照して、ヘッダ情報に記述されている送信元の情報(識別情報またはメールアドレス)がフレンド関係の確立しているものかどうか(たとえばフラグがオンされているかどうか)判断する。ステップS111で“YES”であれば、すべての受信データがフレンド関係の成立した送信元から送信されている場合には、そのまま以降の処理で受信メッセージボックス44bに登録するためにリターンする。
一方、ステップS111で“NO”であれば、つまり受信データがフレンド関係の成立していない送信元から送信されている場合には、ステップS113で、当該送信元がアドレス帳すなわちフレンドリスト44dに登録されているかどうかを判断する。つまり、フレンド関係の確立前であって、相手を登録しているだけの状態であるかどうかを判断する。ただし、ステップS113〜ステップS129の処理については、フレンド関係の成立していない送信元からの受信データのそれぞれについて実行される。
ステップS113で“NO”であれば、つまり当該送信元がアドレス帳に登録されていなければ、ステップS115で、当該新着メール(当該受信データ)をバッファから削除して、受信メールボックス44bへの登録が行われないようにしてリターンする。つまり、送信元が不明なメッセージはフィルタリングされる。一方、ステップS113で“YES”であれば、つまり当該送信元がアドレス帳に登録されていれば、ステップS117で、当該送信元が他の端末かどうかを判断する。ここでは、入出力プロセッサ42aは、送信元の情報としてゲーム装置12の識別情報を含んでいないメールアドレスであるかどうかを判断する。
ステップS117で“YES”であれば、つまり当該受信データの送信元が他の端末である場合には、図12で示すような当該ゲーム装置12が送信した登録メッセージに対する返信であると判断し、ステップS119で、当該他の端末とのフレンド関係を確立させて、(たとえば当該他の端末に対応するフラグをオンして)ステップS81に戻る。一方、ステップS117で“NO”であれば、つまり当該受信データの送信元が他のゲーム装置12である場合には、ステップS121で、当該受信データが図11で示すような受信確認メッセージであるかどうかを判断する。なお、当該受信確認メッセージは、上述したように、ゲーム装置12間でやり取りし、各ゲーム装置12でその内容を識別可能なメッセージ(文字列)である。
ステップS121で“YES”であれば、つまり当該受信データが受信確認メッセージであれば、当該ゲーム装置12が送信した登録メッセージに対する受信確認メッセージであると判断し、当該受信データの送信元とのフレンド関係を成立させるべく、そのままステップS125に進む。一方、ステップS121で“NO”であれば、つまり当該受信データが受信確認メッセージでなければ、ステップS123で、当該受信データが登録メッセージであるかどうかを判断する。ステップS123で“NO”であれば、つまり当該受信データが登録メッセージでなければ、そのままステップS115に進む。一方、ステップS123で“YES”であれば、つまり当該受信データが登録メッセージであれば、当該受信データの送信元とのフレンド関係を成立させるべく、ステップS125に進む。
ステップS125では、入出力プロセッサ42aは、当該受信データの送信元のゲーム装置12とのフレンド関係を成立させる。(たとえば、フレンドリスト44dにおいて当該送信元に対応するフレンド関係のフラグをオンする。)続いて、ステップS127で、当該送信元を宛先とする受信確認メッセージを作成し、ステップS129で、作成した受信確認メッセージを送信メッセージボックス44aに記憶して、リターンする。当該受信確認メッセージは、次にメッセージ送受信が起動する際に送信されることになる。
続いて、図20を参照して、ステップS97の上書き確認処理について説明する。ステップS98では、1つ目の受信データの上書きタグを参照する。なお、詳細な説明は省略するが、ここでの受信データの順番は、受信した順番やバッファ内での記憶位置に従う順番であり、単に受信データを区別するためのものである。以下、同様である。次のステップS99では、当該受信データを上書きするかどうかを判断する。ここでは、入出力プロセッサ42aは、当該受信データのヘッダ情報に含まれる上書きタグが「ON」を示すかどうかを判断する。
ステップS99で“NO”であれば、つまり上書きしない場合には、そのままステップS104に進む。一方、ステップS99で“YES”であれば、つまり上書き「ON」の場合には、ステップS101で、送信元、アプリIDおよび上書きIDのすべてが一致する受信データが受信メッセージボックス44bに記憶されているかどうかを判断する。ステップS101で“YES”であれば、つまり送信元、アプリIDおよび上書きIDのすべてが一致する受信データが受信メッセージボックス44bに記憶されている場合には、当該メッセージは上書きすべきメッセージであるので、ステップS103で、送信元、アプリIDおよび上書きIDのすべてが一致する受信データに、当該受信データを上書きするように、当該受信データを受信メッセージボックス44bに記憶して、図21に示すステップS111に進む。なお、この説明では、受信データの受信メッセージボックス44bへの記憶は、ステップS94で行われるものとしているので、ステップS103においては、上書きをするという設定を一時的に保持したまま次のステップに進んでもよいし、ステップS103で先に上書きを行って、バッファから削除するようにしてもよく、上記条件を満たすものが上書きされればよい。一方、ステップS101で“NO”であれば、つまり送信元、アプリIDおよび上書きIDのすべてが一致する受信データが受信メッセージボックス44bに記憶されていない場合には、上書きされるべきメッセージが存在しないので、そのままステップS104に進む。
ステップS104では、全ての受信データを参照して上記処理を行ったか判定される。ステップS104で“YES”であれば、つまりすべての受信データについて処理が済んでいれば、リターンする。一方、ステップS104で“NO”であれば、つまりすべての受信データへの処理が済んでいなければ、ステップS105で、次の受信データの上書きタグを参照して、ステップS99に戻る。
次に、図22を参照して、入出力プロセッサ42aのダウンロード処理について説明する。ダウンロード処理は、入出力プロセッサ42aがCPU40と独立に実行するものであって、上述のスタンバイモード時であっても実行される。また、CPU40がアプリケーションを実行しているバックグラウンドにおいても独立に実行されている。なお、このダウンロード処理は、タスクが登録されている状態で、上述のように、入出力プロセッサ42a内でトリガが発生するごとに実行され続ける。ただし、ダウンロード処理は、それぞれのタスクで実行される。この図22に示すように、入出力プロセッサ42aはステップS151で、タスクを実行するためのトリガ(タスク実行トリガ)の発生を検出する。ステップS151で“NO”であれば、つまりタスク実行トリガが無ければ、そのままステップS151に戻る。一方、ステップS151で“YES”であれば、つまりタスク実行トリガが有れば、ステップS153で、当該タスクの実行予定時刻であるかどうかを判断する。厳密に言うと、ここでは、入出力プロセッサ42aは、実行予定時刻であるかどうか、または、実行予定時刻を経過しているかどうかを判断する。
ステップS153で“NO”であれば、つまり当該タスクの実行予定時刻でなければ、そのままステップS151に戻る。一方、ステップS153で“YES”であれば、つまり当該タスクの実行予定時刻であれば、ステップS155で、リトライ許容時刻を経過しているかどうかを判断する。ステップS155で“YES”であれば、つまりリトライ許容時刻を経過していれば、ステップS157で、当該タスクをタスクリスト44eから消去して、ダウンロード処理を終了する。ただし、ダウンロード処理はタスク毎に実行されるので、当該タスクに関するダウンロード処理が終了するという意味であって、他のタスクについてはそれ以降もトリガ発生とともにダウンロード処理が起動することになる。
一方、ステップS155で“NO”であれば、つまりリトライ許容時刻を経過していなければ、ステップS159で、配信サーバ104に接続要求を送信する。つまり、入出力プロセッサ42aは、当該タスクの属性が示すコンテンツ(ダウンロードデータ)の取得元のURLにアクセス要求を送信するのである。続いて、ステップS161で、当該タスクの残りダウンロード回数を1減算する。ここで、図示は省略するが、入出力プロセッサ42aは、残りダウンロード回数が0になった時点で、当該タスクをタスクリスト44eから消去し、次回のダウンロードが行われないようにする。ステップS163では、次回のタスク実行予定時刻をスケジューリングする。
そして、ステップS165では、配信サーバ104との接続に成功したかどうかを判断する。ステップS165で“NO”であれば、つまり配信サーバ104との接続に失敗すれば、そのままステップS151に戻る。なお、この実施例では、入出力プロセッサ42aは、配信サーバ104との接続に失敗すると、直にステップS151に戻るようにしてあるが、所定回数(たとえば、3回のリトライ)接続要求を送信しても、接続に成功しない場合に、ステップS151に戻るようにしてもよい。また、ネットワークやサーバにエラーが発生している場合には、リトライを行わないようにしてもよい。また、そのようなエラーの場合には、上述の残りダウンロード回数の減算を行うとダウンロードが行われないまま終了してしまう可能性があるので、ステップS161をステップS165の後に実行するようにして、残り回数の減算を行わないようにしてもよい。
ステップS165で“YES”であれば、つまり配信サーバ104との接続に成功すれば、ステップS167で、ダウンロードを実行する。つまり、入出力プロセッサ42aは、ダウンロードデータを取得する。そして、ステップS169で、ダウンロードデータがメッセージ配信用のデータであるかどうかを判断する。たとえば、メッセージ配信用のデータを電子メール形式のデータとし、入出力プロセッサ42aは、取得したダウンロードデータが電子メールの形式であるかどうかを判断する。または、メッセージ配信用のデータであることを示す情報をダウンロードデータに含め、ダウンロード実行後にゲーム装置12において電子メール形式のデータに変換するようにしてもよい。
ステップS169で“YES”であれば、つまりダウンロードデータがメッセージ配信用のデータである場合には、ステップS171で、当該ダウンロードデータを受信データとして受信メッセージボックス44bに格納して、ステップS151に戻る。一方、ステップS169で“NO”であれば、つまりダウンロードデータがメッセージ配信用のデータでない場合には、ステップS173で、当該ダウンロードデータをダウンロードボックス440に格納して、ステップS151に戻る。
上述したようなメッセージ送受信処理およびダウンロード処理は、基本的には、CPU40がゲームアプリーションのようなアプリケーションを実行している場合やスタインバイモードが設定されている場合であっても、入出力プロセッサ42aによって独立に実行される。ただし、CPU40(アプリケーション)から特に停止指示がある場合には、メッセージ送受信処理(自動送受信機能)は一時的に停止される。その後、CPU40(アプリケーション)からの再開指示により、メッセージ送受信処理は再開される。このようなメッセージ送受信処理およびダウンロード処理の停止・再開の機能(スケジューラ操作機能と呼ぶ)をそれぞれのアプリケーションプログラムに含めることができる。
たとえば、パフォーマンスの厳しいアプリケーションを実行している場合に、一時的な処理速度の低下を防ぐことができる。また、無線通信モジュール50aを介して、上述のメッセージ送受信処理やダウンロード処理以外の通信処理(たとえばネットワークゲームのプレイ等)を同時に行っている場合に、通信速度が低下することを防ぐことができる。また、アプリケーションにおいてフラッシュメモリ44にアクセスしているタイミングにおいて、フラッシュメモリ44へのアクセスが集中することでアクセスの速度が一時的に低下することを防ぐことができる。
したがって、このようなスケジューラ操作機能を用いることで、メッセージ送受信処理およびダウンロード処理を一時的に停止させることができる。このスケジューラ操作機能は、アプリケーションの実行中のどの段階でも呼び出し可能であるため、たとえば、フラッシュメモリ44から大容量のデータを読み込む前に、メッセージ送受信処理およびダウンロード処理を一時停止させておき、読み込みが完了した後に、メッセージ送受信処理およびダウンロード処理を再開させることが可能である。また、たとえば、メッセージの送信処理を終えた段階でメッセージ送受信処理を一時停止させ、その後、メッセージ送受信処理を再開させて、メッセージの受信処理を実行させることも可能である。
この実施例によれば、通常モードおよびスタンバイモードに拘わらずメッセージを送受信するので、通信するゲーム装置同士が同時に起動している必要がない。また、対象となるアプリケーションを識別可能なデータを本体機能によって送受信するので、アプリケーション毎に通信機能を設ける必要がなく、コストを削減することができる。また、メッセージを作成しているときに、ネットワークに接続している必要がないので、ユーザの手間や無駄な通信コストを削減することができる。したがって、コストやユーザの手間を軽減でき、汎用性の高い通信方法を提供することができる。
なお、この実施例では、上書きタグの上書きIDが「上書きする」を示すとき、送信元の情報と、アプリIDと、上書きIDとのすべてが一致する前回のメッセージが受信メッセージボックス44bに存在するとき、今回のメッセージを前回のメッセージに上書きするようにした。ただし、最新のメッセージよりも古いメッセージの方が後から受信される場合も想定される。かかる場合には、最新のメッセージに、それよりも古いメッセージが上書きされてしまうことがある。また、重要度の高いメッセージに、それよりも重要度の低いメッセージが上書きされてしまうような事態も想定される。
したがって、このような不都合を回避するために、メッセージの新しさや重要度に応じた上書きの優先度を示す情報(優先度ID)をさらに付加する。たとえば、優先度IDは、数字であり、数が大きい程、優先度が高く、逆に数が小さい程、優先度が低い。したがって、メッセージを受信したとき、送信元の情報、アプリID、上書きIDのすべてが一致し、さらに、優先度IDが示す番号が大きい場合に、当該メッセージが上書きされるようにすればよい。
また、他の実施例のゲーム装置12は、メッセージの自動返信機能を有していてもよい。当該他の実施例は、メッセージの自動返信機能を有する以外は、上述の実施例と同じであるため、重複した説明は省略する。この他の実施例のゲーム装置12では、メッセージのヘッダ情報に加えて、またはヘッダ情報に含んで、メッセージの自動返信情報が記述される。この自動返信情報は、「自動返信しない」、「自動返信する(コピー属性)」、「自動返信する(ムーブ属性)」の3種類で識別される。
たとえば、メッセージを自動返信する場合には、送信可能な状態か否かの情報を含めてメッセージを識別するための識別情報(メッセージID)が付与される。このメッセージIDがメッセージ(送信データ)に付加されている場合には、当該送信データはメッセージ送受信処理においてもネットワーク106に送信されず、待機している状態である。このメッセージIDを削除する(取り除く)ことによって送信可能となり、次に実行されるメッセージ送受信処理において送信される。この実施例では、受信データに当該メッセージIDと同じメッセージIDが記述されている場合に、送信データに付加されたメッセージIDを削除する。
ただし、この他の実施例では、送信データに付加されたメッセージIDと同じメッセージIDが記述(付加)された受信データを受信したとき、当該送信データのメッセージIDを削除するようにしてある。ただし、受信データに付加されるメッセージID(説明の都合上、「受信側メッセージID」という。)は、送信データに付加されたメッセージID(説明の都合上、「送信側メッセージID」という。)と同じである必要はない。たとえば、受信側メッセージIDと送信側メッセージIDとが一対(一組)の鍵となる関係を有し、受信側メッセージIDによって送信側メッセージIDを解くようにしてもよい。また、受信側メッセージIDの内容に関わらず、送信側メッセージIDを削除するようにして、返信要求のあるもの全てに返信するようなものであってもよい。
したがって、ユーザは当該送信データを自動送信したい他のユーザに対して当該送信データのメッセージIDと同じ(または一対(一組)の)メッセージIDを別途送信したり、他の手段で連絡しておいたりするのである。ただし、ユーザは、自動返信用のメッセージを作成する際に、ゲーム装置12(入出力プロセッサ42a)からの通知(画面表示)により、別途送信すべきメッセージIDを知ることができる。
そして、メッセージIDを別途送信しておいた他のユーザから、メッセージID連絡のメッセージへの返信(送信要求)の受信や、別途連絡済みのメッセージIDを付加したメッセージの受信があると、送信データに付加されていたメッセージIDが削除され、当該送信データは送信可能となり、その後、当該他のユーザのゲーム装置12や他の端末に送信される。すなわち、他のユーザに対して自動返信することができる。
以下、本実施例の自動返信をゲームに利用する例を説明する。たとえば、自分だけの武器(アイテム)を作ることができ、その武器をフリーマーケットで売ることができるアプリケーションを想定する。このような場合には、オリジナルの武器を作ったユーザAが当該武器をフリーマーケットに出す。つまり、ユーザA側のアプリケーションは、武器データを含むメッセージを自動返信用メッセージ(メッセージID付きのメッセージ)として、送信メッセージボックス44aに登録する。このとき、ユーザA側のアプリケーションは、武器データを含むメッセージのメッセージIDを知ることができる。ユーザA側のアプリは、武器データを含むメッセージのメッセージIDをユーザBに送信する。ユーザB側のアプリケーションは、ユーザBに「ユーザAのフリーマットで武器が売り出されている」ことをメッセージで知らせる。ユーザBがその武器を購入することを決めると、ユーザB側のアプリケーションはユーザA宛に、武器データを含むメッセージのメッセージIDと「ムーブ属性」を指定した自動返信機能を利用したメッセージを送信する。ユーザBからの自動返信機能を含むメッセージを受け取ったユーザA側では、メッセージ送受信機能により、指定されたメッセージIDの付加された送信データ(メッセージ)が送信メッセージボックス44aにあるかどうかを検索する。そして、指定されたメッセージIDの付加された送信データが送信メッセージボックス44aにある場合には、自動返信用の属性(ここでは,メッセージID)を削除し、当該送信データは送信可能になる。その後、武器データを含む送信データがユーザB宛に送信される。
このように、ムーブ属性が指定された場合には、送信データ(武器データ)はコピーされずに、一度返信を行うと削除されるものとする。なお、コピー属性が指定された場合には、送信データから自動返信用の属性が削除されると、当該送信データの複製が送信可能に送信メッセージボックス44aに保持される。自動返信が1回に限るものであるか、毎回返信するものであるかの用途の違いによって、それぞれの属性を使い分けることができる。
なお、上記実施例は、自動返信機能をゲームにおける武器の売買に利用したが、利用対象は武器に限らず、アイテムやキャラクタの交換、履歴の交換等、さまざまな用途に利用することができる。
自動返信のための具体的処理としては、上述の実施例で示したメッセージ送受信処理の一部が変更される。なお、変更した箇所以外は上述の実施例で示したとおりであるため、異なる点についてのみ説明する。また、詳細な説明は省略するが、上述の実施例のメッセージ入力処理において、電子メールを作成するときに、「コピー属性」や「ムーブ属性」を選択(設定)できるようにしておければよい。
図19に示したメッセージ送受信処理のステップS89で“YES”であれば、ステップS91、S93、S95における処理が具体的に図23で示すような処理になる。ステップS201で、送信メッセージボックス44aの1つ目の送信データをチェックする。続くステップS203では、当該送信データが送信可能かどうかを判断する。具体的には、入出力プロセッサ42aは、当該送信データにメッセージIDが付加されているかどうかを判断する。
ステップS203で“NO”であれば、つまり当該送信データが送信不能であれば、そのままステップS209に進む。一方、ステップS203で“YES”であれば、つまり当該送信データが送信可能であれば、ステップS205で、当該送信データをネットワーク106に送信する。そして、ステップS207で、当該送信データを送信メッセージボックス44aから削除し、ステップS209に進む。
ステップS209では、すべての送信データの送信制御を実行したかどうかを判断する。ステップS209で“NO”であれば、つまりすべての送信データの送信制御を実行していなければ、ステップS211で、次の送信データをチェックして、ステップS203に戻る。一方、ステップS209で“YES”であれば、つまりすべての送信データの送信制御を実行していれば、ステップS213で、メールサーバ102から受信データを受信し、ステップS95に進む。
また、メッセージ送受信処理のステップS94以降、図24に示すような処理が行われる。ステップS94で、受信データを受信メッセージボックス44bに記憶すると、ステップS221で、当該受信データがメッセージIDを有しているかどうかを判断する。ステップS221で“NO”であれば、つまり当該受信データがメッセージIDを有していなければ、そのままステップS224に進む。一方、ステップS221で、当該受信データがメッセージIDを有していれば、ステップS223で、当該メッセージIDを含む送信データを送信可能に設定して、ステップS87に進む。つまり、ステップS223では、自動返信機能の属性として「コピー属性」が指定されている場合には、受信データに含まれるメッセージID同じメッセージIDが付加された送信データの複製を送信メッセージボックス44aに記憶して、当該複製を送信可能にする。また、ステップS223では、自動返信機能の属性として「ムーブ属性」が指定されている場合には、受信データに含まれるメッセージIDと同じメッセージIDが付加された送信データから当該メッセージIDを削除して、当該送信データを送信可能にする。
ただし、送信可能にした送信データを送信メッセージボックス44aに機構するとき、当該送信データは電子メール形式に変換されるが、その宛先には、自動送信を要求してきたゲーム装置12のメールアドレスが自動的に登録される。ただし、上記の処理は、受信メッセージボックスに記憶後のデータに対してではなく、バッファに記憶されている状態でステップS221、S223、S224の処理が行われてもよい。
他の実施例によれば、自動返信機能を利用することにより、特定のユーザとの間で特定のアイテムを交換したり、特定のユーザに特定のアイテムを譲ったりすることができる。したがって、上述の実施例の効果に加えて、利便性の高い通信環境を提供することができる。