(57)【要約】    【構成】  ゲーム装置１２は入出力プロセッサ４２ａを含み、この入出力プロセサ４２ａの指示に従ってネットワークを介して接続される他のゲーム装置１２との間でメッセージ（データ）を送受信する。たとえば、ゲーム装置１２（ゲーム装置Ａ）は、自動返信用のメッセージを送信メッセージボックスに登録し、当該自動返信用のメッセージが有る旨を他のゲーム装置１２（ゲーム装置Ｂ）などに通知する。ゲーム装置Ｂのユーザが自動返信要求情報を含むメッセージをゲーム装置Ａに送信すると、ゲーム装置Ａは、これに応じて、自動返信用のメッセージを送信可能にした後、ゲーム装置Ｂに送信する。    【効果】  オンラインゲームをプレイしていなくとも、他のゲーム機とデータのやり取りを行うことができる。【選択図】  図２
2014061421.tif 000002
【特許請求の範囲】
【請求項１】
他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するゲームプログラムを実行するゲーム装置であって、
データの送受信を行う通信部と、
前記通信部にデータの送受信を行わせる送受信管理手段と、
自動返信用の所定の返信データを記憶する返信データ記憶手段と、
受信された受信データを記憶する受信データ記憶手段と、
ユーザが指定するゲームプログラムを実行し、前記受信データを利用するゲーム処理を行うゲーム処理手段と、
前記送受信管理手段によって送受信が行われ、データを受信した場合に、当該受信した受信データを前記受信データ記憶手段に記憶し、当該受信データに返信を要求することを示す返信要求情報が含まれているか否かを判別する受信データ判別手段と、
前記受信データ判別手段において前記受信データ記憶手段に記憶された受信データに前記返信要求情報が含まれている場合に、前記返信データ記憶手段から自動的に前記返信データを読み出して前記通信部を介して送信する自動返信手段と、を備えるゲーム装置。
【請求項２】
前記自動返信手段は、前記返信データの送信後、前記返信データ記憶手段から当該返信データを削除する、請求項１記載のゲーム装置。
【請求項３】
前記自動返信手段は、データを受信する毎に、前記返信データを読み出して送信する、請求項１記載のゲーム装置。
【請求項４】
前記ゲーム処理手段は、ネットワークを介してゲームにおけるアイテムの取引を行うゲームプログラムを実行するものであって、前記返信データには、当該アイテムに関するデータが含まれ、前記返信要求情報が含まれる受信データには、当該アイテムの取引に同意する旨の意思表示情報がさらに含まれ、
前記自動返信手段において、当該返信要求情報が含まれる受信データに応じて前記アイテムに関するデータが含まれる送信データが送信されることによって、ゲームにおける取引を成立させる、請求項２に記載のゲーム装置。
【請求項５】
前記ゲーム処理手段は、前記取引を行う旨を通知する通知データを前記通信部に送信させる通知処理を含む、請求項４に記載のゲーム装置。
【請求項６】
他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するゲーム装置のゲームプログラムであって、
前記ゲーム装置のコンピュータを、
データの送受信を行う通信部と、
前記通信部にデータの送受信を行わせる送受信管理手段と、
自動返信用の所定の返信データを記憶する返信データ記憶手段と、
受信された受信データを記憶する受信データ記憶手段と、
ユーザが指定するゲームプログラムを実行し、前記受信データを利用するゲーム処理を行うゲーム処理手段と、
前記送受信管理手段によって送受信が行われ、データを受信した場合に、当該受信した受信データを前記受信データ記憶手段に記憶し、当該受信データに返信を要求することを示す返信要求情報が含まれているか否かを判別する受信データ判別手段と、
前記受信データ判別手段において前記受信データ記憶手段に記憶された受信データに前記返信要求情報が含まれている場合に、前記返信データ記憶手段から自動的に前記返信データを読み出して前記通信部を介して送信する自動返信手段として機能させる、ゲームプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はゲーム装置およびゲームプログラムに関し、特にたとえば、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用する、ゲーム装置およびゲームプログラムに関する。
【背景技術】
【０００２】
この種の背景技術の一例が特許文献１および特許文献２に開示される。特許文献１は、複数のユーザのゲームデータをサーバに登録しておき、交換条件が成立したときに、ゲームデータを交換するものである。特許文献２は、近距離無線でゲーム機同士の通信をおこなって、互いのゲームデータを交換するものである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２３６６１号公報
【特許文献２】特開２００５−２８１０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１に開示された発明では、専用のサーバが必要になり、また、ゲームデータをサーバに登録することが必要である。
【０００５】
また、特許文献２に開示された発明では、ゲーム機同士が通信範囲に近づくことが必要になり、また、同一のゲームプログラムが起動された状態で近づくことが必要である。
【０００６】
それゆえに、この発明の主たる目的は、新規な、ゲーム装置およびゲームプログラムを提供することである。
【０００７】
また、この発明の他の目的は、オンラインゲーム専用のサーバを設けることなく、複数のゲーム装置間でデータの提供をおこなうことが可能な、ゲーム装置およびゲームプログラムを提供することである。
【０００８】
また、この発明の他の目的は、複数のゲーム装置間で簡単にデータの提供が可能であり、かつ、提供の機会を増やすことができる、ゲーム装置およびゲームプログラムを提供することである。
【課題を解決するための手段】
【０００９】
第１の発明は、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するゲームプログラムを実行するゲーム装置であって、通信部と、送受信管理手段と、返信データ記憶手段と、受信データ記憶手段と、ゲーム処理手段と、受信データ判別手段と、自動返信手段とを備える。通信部は、データの送受信を行う。送受信管理手段は、通信部にデータの送受信を行わせる。返信データ記憶手段は、自動返信用の所定の返信データを記憶する。受信データ記憶手段は、受信された受信データを記憶する。ゲーム処理手段は、ユーザが指定するゲームプログラムを実行し、受信データを利用する。受信データ判別手段は、送受信管理手段によって送受信が行われ、データを受信した場合に、当該受信した受信データを受信データ記憶手段に記憶し、当該受信データに返信を要求することを示す返信要求情報が含まれているか否かを判別する。自動返信手段は、受信データ判別手段において受信データ記憶手段に記憶された受信データに返信要求情報が含まれている場合に、返信データ記憶手段から自動的に返信データを読み出して通信部を介して送信する。
【００１０】
第１の発明では、ゲーム装置は、ネットワークを介して他の装置のとの間でデータの送受信を行い、当該送受信されたデータを利用するゲームプログラムを実行する。通信部はデータの送受信を行い、送受信管理手段は、この通信部にデータの送受信を行わせる。返信データ記憶手段は、自動返信用の所定の返信データを記憶する。受信データ記憶手段は、受信された受信データを記憶する。ゲーム処理手段は、ユーザが指定するゲームプログラムを実行し、このとき、受信データ記憶手段によって記憶された受信データを利用する。受信データ判別手段は、送受信管理手段によって送受信が行われることによって、データを受信した場合に、当該受信データを受信データ記憶手段に記憶する。そして、当該受信データに返信を要求することを示す返信要求情報が含まれているか否かを判別する。自動返信手段は、受信データ判別手段において受信データ記憶手段に記憶された受信データに返信要求情報が含まれている場合に、返信記憶手段から自動的に返信データを読み出して通信部を介して送信する。ただし、返信データは、返信要求した装置に対して送信される。
【００１１】
第１の発明によれば、受信したデータに対して自動的に返信を行うことができ、オンラインゲームをプレイしている間でなくとも、他のゲーム機とのデータのやり取りを行うことができる。
【００１２】
第２の発明は、自動返信手段は、返信データの送信後、返信データ記憶手段から当該返信データを削除する、第１の発明に従属するゲーム装置である。
【００１３】
第２の発明では、自動返信手段は、返信データを送信すると、その後、返信データ記憶手段から当該返信データを削除する。
【００１４】
第２の発明によれば、自動返信を１回に限り行うことができる。
【００１５】
第３の発明は、自動返信手段は、データを受信する毎に、返信データを読み出して送信する、第１の発明に従属するゲーム装置である。
【００１６】
第３の発明では、第２の発明とは異なり、自動返信手段は、データを受信する毎に、返信データ読み出して送信する。たとえば、返信データの複製が送信される。
【００１７】
第３の発明によれば、自動返信を回数の制限無く行うことができる。
【００１８】
第４の発明は、ゲーム処理手段は、ネットワークを介してゲームにおけるアイテムの取引を行うゲームプログラムを実行するものであって、返信データには、当該アイテムに関するデータが含まれ、返信要求情報が含まれる受信データには、当該アイテムの取引に同意する旨の意思表示情報がさらに含まれ、自動返信手段において、当該返信要求情報が含まれる受信データに応じてアイテムに関するデータが含まれる送信データが送信されることによって、ゲームにおける取引を成立させる、第２の発明に従属するゲーム装置である。
【００１９】
第４の発明では、ゲーム処理手段は、ネットワークを介してゲームにおけるアイテムの取引を行うゲームプログラムを実行する。返信データには、当該アイテムに関するデータが含まれ、返信要求情報が含まれる場合には、さらに当該アイテムの取引に同意する旨の意思表示情報がさらに含まれる。自動返信手段において、当該返信要求情報が含まれる受信データに応じてアイテムに関する送信データが、返信要求した他の装置に送信される。これによって、ゲームにおける取引が成立する。
【００２０】
第４の発明によれば、ユーザがゲームをプレイしている間でなくとも、通信によって他のゲーム機とアイテムのやり取りを行うことができる。
【００２１】
第５の発明は、ゲーム処理手段は、取引を行う旨を通知する通知データを通信部に送信させる通知処理を含む、第４の発明に従属するゲーム装置である。
【００２２】
第５の発明では、ゲーム処理手段は、通知処理によって、取引を行う旨を通知する通知データを通信部に送信させる。
【００２３】
第５の発明によれば、予め他のユーザに通知を行うことができ、アイテムのやり取りを促すことができる。
【００２４】
第６の発明は、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するゲーム装置のゲームプログラムであって、ゲーム装置のコンピュータを、通信部と、送受信管理手段と、返信データ記憶手段と、受信データ記憶手段と、ゲーム処理手段と、受信データ判別手段と、自動返信手段として機能させる。通信部は、データの送受信を行う。送受信管理手段は、通信部にデータの送受信を行わせる。返信データ記憶手段は、自動返信用の所定の返信データを記憶する。受信データ記憶手段は、受信された受信データを記憶する。ゲーム処理手段は、ユーザが指定するゲームプログラムを実行し、受信データを利用する。受信データ判別手段は、送受信管理手段によって送受信が行われ、データを受信した場合に、当該受信した受信データを受信データ記憶手段に記憶し、当該受信データに返信を要求することを示す返信要求情報が含まれているか否かを判別する。自動返信手段は、受信データ判別手段において受信データ記憶手段に記憶された受信データに返信要求情報が含まれている場合に、返信データ記憶手段から自動的に返信データを読み出して通信部を介して送信する。
【００２５】
第６の発明においても、第１の発明と同様に、受信したデータに対して自動的に返信を行うことができ、オンラインゲームをプレイしている間でなくとも、他のゲーム機とのデータのやり取りを行うことができる。
【発明の効果】
【００２６】
この発明によれば、受信したデータに対して自動的に返信を行うことができ、オンラインゲームをプレイしている間でなくとも、他のゲーム機とのデータのやり取りを行うことができる。
【００２７】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施形態の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【００２８】
【図１】図１はこの発明のゲームシステムの一実施例を示す図解図である。
【図２】図２は図１に示すゲームシステムの電気的な構成を示すブロック図である。
【図３】図３は図１に示すコントローラの外観を説明するための図解図である。
【図４】図４は図３に示すコントローラの電気的な構成を示すブロック図である。
【図５】図５は図１に示すコントローラを用いてゲームプレイするときの状態を概説するための図解図である。
【図６】図６は図１に示すマーカおよびコントローラの視野角を説明するための図解図である。
【図７】図７は対象画像を含む撮像画像の一例を示す図解図である。
【図８】図８はこの発明の通信システムの一例を示す図解図である。
【図９】図９はゲーム装置で送受信されるメッセージにヘッダ情報を示す図解図である。
【図１０】図１０はゲーム装置に内蔵されるフラッシュメモリに記憶されるデータを模式的に示す図解図である。
【図１１】図１１はゲーム装置間におけるフレンド登録の流れを示す図解図である。
【図１２】図１２はゲーム装置とそれ以外の端末との間におけるフレンド登録の流れを示す図解図である。
【図１３】図１３はタスクのスケジューリングおよび実行時刻を説明するための図解図である。
【図１４】図１４は図２に示すＣＰＵのゲームアプリケーション処理を示すフロー図である。
【図１５】図１５は図２に示すＣＰＵのゲームアプリケーション処理の一部であるダウンロードデータ取得処理を示すフロー図である。
【図１６】図１６は図２に示すＣＰＵのアプリケーションの１つである伝言板機能を示すフロー図である。
【図１７】図１７は図２に示すＣＰＵの伝言板機能の一部であるメッセージ入力処理を示すフロー図である。
【図１８】図１８は図２に示すＣＰＵの伝言板機能の一部である伝言板表示処理を示すフロー図である。
【図１９】図１９は図２に示す入出力プロセッサのメッセージ送受信処理を示すフロー図である。
【図２０】図２０は図２に示す入出力プロセッサのメッセージ送受信処理の一部である上書き確認処理を示すフロー図である。
【図２１】図２１は図２に示す入出力プロセッサのメッセージ送受信処理の一部であるフィルタリング処理を示すフロー図である。
【図２２】図２２は図２に示す入出力プロセッサのダウンロード処理を示すフロー図である。
【図２３】図２３はこの発明の他の実施例のメッセージ送受信処理の一部を示すフロー図である。
【図２４】図２４はこの発明の他の実施例のメッセージ送受信処理の他の一部を示すフロー図である。
【図２５】図２５はこの発明の掲示板機能によって表示される画面の一例を示す図である。
【図２６】図２６はタスクリスト４４ｅの内容を示す図である。
【図２７】図２７は図２に示すＣＰＵのゲームアプリケーション処理の一部である送信データ作成処理を示すフロー図である。
【図２８】図２８は図２に示すＣＰＵのゲームアプリケーション処理の一部である受信データ取得処理を示すフロー図である。
【発明を実施するための形態】
【００２９】
図１を参照して、この発明の一実施例であるゲームシステム１０は、ビデオゲーム装置（以下、単に「ゲーム装置」という。）１２およびコントローラ２２を含む。なお、図示は省略するが、この実施例のゲーム装置１２は、最大４つのコントローラ２２と通信可能に設計されている。また、ゲーム装置１２と各コントローラ２２とは、無線によって接続される。たとえば、無線通信は、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格に従って実行されるが、赤外線や無線ＬＡＮなど他の規格に従って実行されてもよい。
【００３０】
ゲーム装置１２は、略直方体のハウジング１４を含み、ハウジング１４の前面にはディスクスロット１６が設けられる。ディスクスロット１６から、ゲームプログラム等を記憶した情報記憶媒体の一例である光ディスク１８が挿入されて、ハウジング１４内のディスクドライブ５４（図２参照）に装着される。ディスクスロット１６の周囲には、ＬＥＤと導光板が配置され、さまざまな処理に応答させて点灯させることが可能である。
【００３１】
また、ゲーム装置１２のハウジング１４の前面であり、その上部には、電源ボタン２０ａおよびリセットボタン２０ｂが設けられ、その下部には、イジェクトボタン２０ｃが設けられる。さらに、リセットボタン２０ｂとイジェクトボタン２０ｃとの間であり、ディスクスロット１６の近傍には、外部メモリカード用コネクタカバー２８が設けられる。この外部メモリカード用コネクタカバー２８の内側には、外部メモリカード用コネクタ６２（図２参照）が設けられ、図示しない外部メモリカード（以下、単に「メモリカード」という。）が挿入される。メモリカードは、光ディスク１８から読み出したゲームプログラム等をローディングして一時的に記憶したり、このゲームシステム１０を利用してプレイしたゲームのゲームデータ（ゲームの結果データまたは途中データ）を保存（セーブ）しておいたりするために利用される。ただし、上記のゲームデータの保存は、メモリカードに対して行うことに代えて、たとえばゲーム装置１２の内部に設けられるフラッシュメモリ４４（図２参照）のような内部メモリに対して行うようにしてもよい。また、メモリカードは、内部メモリのバックアップメモリとして用いるようにしてもよい。
【００３２】
なお、メモリカードとしては、汎用のＳＤカードを用いることができるが、メモリスティックやマルチメディアカード（登録商標）のような他の汎用のメモリカードを用いることもできる。
【００３３】
ゲーム装置１２のハウジング１４の後面には、ＡＶケーブルコネクタ５８（図２参照）が設けられ、そのＡＶコネクタ５８を用いて、ＡＶケーブル３２ａを通してゲーム装置１２にモニタ３４およびスピーカ３４ａを接続する。このモニタ３４およびスピーカ３４ａは典型的にはカラーテレビジョン受像機であり、ＡＶケーブル３２ａは、ゲーム装置１２からの映像信号をカラーテレビのビデオ入力端子に入力し、音声信号を音声入力端子に入力する。したがって、カラーテレビ（モニタ）３４の画面上にたとえば３次元（３Ｄ）ビデオゲームのゲーム画像が表示され、左右のスピーカ３４ａからゲーム音楽や効果音などのステレオゲーム音声が出力される。また、モニタ３４の周辺（この実施例では、モニタ３４の上側）には、２つの赤外ＬＥＤ（マーカ）３４ｍ，３４ｎを備えるマーカ部３４ｂが設けられる。このマーカ部３４ｂは、電源ケーブル３２ｂを通してゲーム装置１２に接続される。したがって、マーカ部３４ｂには、ゲーム装置１２から電源が供給される。これによって、マーカ３４ｍ，３４ｎは発光し、それぞれモニタ３４の前方に向けて赤外光を出力する。
【００３４】
なお、ゲーム装置１２の電源は、一般的なＡＣアダプタ（図示せず）によって与えられる。ＡＣアダプタは家庭用の標準的な壁ソケットに差し込まれ、ゲーム装置１２は、家庭用電源（商用電源）を、駆動に適した低いＤＣ電圧信号に変換する。他の実施例では、電源としてバッテリが用いられてもよい。
【００３５】
このゲームシステム１０において、ユーザまたはプレイヤがゲーム（またはゲームに限らず、他のアプリケーション）をプレイするために、ユーザはまずゲーム装置１２の電源をオンし、次いで、ユーザはビデオゲーム（もしくはプレイしたいと思う他のアプリケーション）のプログラムを記録している適宜の光ディスク１８を選択し、その光ディスク１８をゲーム装置１２のディスクドライブ５４にローディングする。応じて、ゲーム装置１２がその光ディスク１８に記録されているプログラムに基づいてビデオゲームもしくは他のアプリケーションを実行し始めるようにする。ユーザはゲーム装置１２に入力を与えるためにコントローラ２２を操作する。たとえば、入力手段２６のどれかを操作することによってゲームもしくは他のアプリケーションをスタートさせる。また、入力手段２６に対する操作以外にも、コントローラ２２自体を動かすことによって、動画オブジェクト（プレイヤオブジェクト）を異なる方向に移動させ、または３Ｄのゲーム世界におけるユーザの視点（カメラ位置）を変化させることができる。
【００３６】
図２は図１実施例のビデオゲームシステム１０の電気的な構成を示すブロック図である。図示は省略するが、ハウジング１４内の各コンポーネントは、プリント基板に実装される。図２に示すように、ゲーム装置１２には、ＣＰＵ４０が設けられる。このＣＰＵ４０は、ゲームプロセッサとして機能する。このＣＰＵ４０には、システムＬＳＩ４２が接続される。このシステムＬＳＩ４２には、外部メインメモリ４６、ＲＯＭ／ＲＴＣ４８、ディスクドライブ５４およびＡＶ  ＩＣ５６が接続される。
【００３７】
外部メインメモリ４６は、ゲームプログラム等のプログラムを記憶したり、各種データを記憶したりし、ＣＰＵ４０のワーク領域やバッファ領域として用いられる。ＲＯＭ／ＲＴＣ４８は、いわゆるブートＲＯＭであり、ゲーム装置１２の起動用のプログラムが組み込まれるとともに、時間をカウントする時計回路が設けられる。ディスクドライブ５４は、光ディスク１８からプログラムデータやテクスチャデータ等を読み出し、ＣＰＵ４０の制御の下で、後述する内部メインメモリ４２ｅまたは外部メインメモリ４６に書き込む。
【００３８】
システムＬＳＩ４２には、入出力プロセッサ４２ａ、ＧＰＵ(Graphics Processor Unit)４２ｂ，ＤＳＰ(Digital Signal Processor)４２ｃ，ＶＲＡＭ４２ｄおよび内部メインメモリ４２ｅが設けられ、図示は省略するが、これらは内部バスによって互いに接続される。
【００３９】
入出力プロセッサ（Ｉ／Ｏプロセッサ）４２ａは、データの送受信を実行したり、データのダウンロードを実行したりする。データの送受信やダウンロードについては後で詳細に説明する。
【００４０】
ＧＰＵ４２ｂは、描画手段の一部を形成し、ＣＰＵ４０からのグラフィクスコマンド(作画命令)を受け、そのコマンドに従ってゲーム画像データを生成する。ただし、ＣＰＵ４０は、グラフィクスコマンドに加えて、ゲーム画像データの生成に必要な画像生成プログラムをＧＰＵ４２ｂに与える。
【００４１】
図示は省略するが、上述したように、ＧＰＵ４２ｂにはＶＲＡＭ４２ｄが接続される。ＧＰＵ４２ｂが作画コマンドを実行するにあたって必要なデータ（画像データ：ポリゴンデータやテクスチャデータなどのデータ）は、ＧＰＵ４２ｂがＶＲＡＭ４２ｄにアクセスして取得する。なお、ＣＰＵ４０は、描画に必要な画像データを、ＧＰＵ４２ｂを介してＶＲＡＭ４２ｄに書き込む。ＧＰＵ４２ｂは、ＶＲＡＭ４２ｄにアクセスして描画のためのゲーム画像データを作成する。
【００４２】
なお、この実施例では、ＧＰＵ４２ｂがゲーム画像データを生成する場合について説明するが、ゲームアプリケーション以外の任意のアプリケーションを実行する場合には、ＧＰＵ４２ｂは当該任意のアプリケーションについての画像データを生成する。
【００４３】
また、ＤＳＰ４２ｃは、オーディオプロセッサとして機能し、内部メインメモリ４２ｅや外部メインメモリ４６に記憶されるサウンドデータや音波形（音色）データを用いて、スピーカ３４ａから出力する音、音声或いは音楽に対応するオーディオデータを生成する。
【００４４】
上述のように生成されたゲーム画像データおよびオーディオデータは、ＡＶ  ＩＣ５６によって読み出され、ＡＶコネクタ５８を介してモニタ３４およびスピーカ３４ａに出力される。したがって、ゲーム画面がモニタ３４に表示され、ゲームに必要な音（音楽）がスピーカ３４ａから出力される。
【００４５】
また、入出力プロセッサ４２ａには、フラッシュメモリ４４、無線通信モジュール５０および無線コントローラモジュール５２が接続されるとともに、拡張コネクタ６０およびメモリカード用コネクタ６２が接続される。また、無線通信モジュール５０にはアンテナ５０ａが接続され、無線コントローラモジュール５２にはアンテナ５２ａが接続される。
【００４６】
入出力プロセッサ４２ａは、無線通信モジュール５０を介して、ネットワークに接続される他のゲーム装置や各種サーバと通信することができる。ただし、ネットワークを介さずに、直接的に他のゲーム装置と通信することもできる。入出力プロセッサ４２ａは、定期的にフラッシュメモリ４４にアクセスし、ネットワークへ送信する必要があるデータ（送信データとする）の有無を検出し、当該送信データが有る場合には、無線通信モジュール５０およびアンテナ５０ａを介してネットワークに送信する。また、入出力プロセッサ４２ａは、他のゲーム装置から送信されるデータ（受信データとする）を、ネットワーク、アンテナ５０ａおよび無線通信モジュール５０を介して受信し、受信データをフラッシュメモリ４４に記憶する。ただし、一定の場合には、受信データをそのまま破棄する。さらに、入出力プロセッサ４２ａは、ダウンロードサーバからダウンロードしたデータ（ダウンロードデータとする）をネットワーク、アンテナ５０ａおよび無線通信モジュール５０を介して受信し、ダウンロードデータをフラッシュメモリ４４に記憶する。
【００４７】
また、入出力プロセッサ４２ａは、コントローラ２２から送信される入力データをアンテナ５２ａおよび無線コントローラモジュール５２を介して受信し、内部メインメモリ４２ｅまたは外部メインメモリ４６のバッファ領域に記憶（一時記憶）する。入力データは、ＣＰＵ４０のゲーム処理によって利用された後、バッファ領域から消去される。
【００４８】
なお、この実施例では、上述したように、無線コントローラモジュール５２は、Ｂｌｕｅｔｏｏｔｈ規格にしたがってコントローラ２２との間で通信を行う。
【００４９】
さらに、入出力プロセッサ４２ａには、拡張コネクタ６０およびメモリカード用コネクタ６２が接続される。拡張コネクタ６０は、ＵＳＢやＳＣＳＩのようなインターフェイスのためのコネクタであり、外部記憶媒体のようなメディアを接続したり、他のコントローラのような周辺機器を接続したりすることができる。また、拡張コネクタ６０に有線ＬＡＮアダプタを接続し、無線通信モジュール５０に代えて当該有線ＬＡＮを利用することもできる。メモリカード用コネクタ６２には、メモリカードのような外部記憶媒体を接続することができる。したがって、たとえば、入出力プロセッサ４２ａは、拡張コネクタ６０やメモリカード用コネクタ６２を介して、外部記憶媒体にアクセスし、データを保存したり、データを読み出したりすることができる。
【００５０】
詳細な説明は省略するが、図１にも示したように、ゲーム装置１２（ハウジング１４）には、電源ボタン２０ａ，リセットボタン２０ｂおよびイジェクトボタン２０ｃが設けられる。電源ボタン２０ａは、システムＬＳＩ４２に接続される。この電源ボタン２０ａがオンされると、システムＬＳＩ４２は、ゲーム装置１２の各コンポーネントに図示しないＡＣアダプタを経て電源が供給され、通常の通電状態となるモード（通常モードと呼ぶこととする）を設定する。一方、電源ボタン２０ａがオフされると、システムＬＳＩ４２は、ゲーム装置１２の一部のコンポーネントのみに電源が供給され、消費電力を必要最低限に抑えるモード（以下、「スタンバイモード」という。）を設定する。この実施例では、スタンバイモードが設定された場合には、システムＬＳＩ４２は、入出力プロセッサ４２ａ、フラッシュメモリ４４、外部メインメモリ４６、ＲＯＭ／ＲＴＣ４８および無線通信モジュール５０、無線コントローラモジュール５２以外のコンポーネントに対して、電源供給を停止する指示を行う。したがって、このスタンバイモードは、ＣＰＵ４０によってアプリケーションの実行が行われないモードである。
【００５１】
なお、システムＬＳＩ４２には、スタンバイモードにおいても電源が供給されるが、ＧＰＵ４２ｂ、ＤＳＰ４２ｃおよびＶＲＡＭ４２ｄへのクロックの供給を停止することにより、これらを駆動させないようにして、消費電力を低減するようにしてある。
【００５２】
また、図示は省略するが、ゲーム装置１２のハウジング１４内部には、ＣＰＵ４０やシステムＬＳＩ４２などのＩＣの熱を外部に排出するためのファンが設けられる。スタンバイモードでは、このファンも停止される。
【００５３】
ただし、スタンバイモードを利用したくない場合には、スタンバイモードを利用しない設定にしておくことにより、電源ボタン２０ａがオフされたときに、すべての回路コンポーネントへの電源供給が完全に停止される。
【００５４】
また、通常モードとスタンバイモードの切り替えは、コントローラ２２の電源スイッチ２６ｈのオン／オフの切り替えによっても遠隔操作によって行うことが可能である。当該遠隔操作を行わない場合には、スタンバイモードにおいて無線コントローラモジュール５２ａへの電源供給を行わない設定にしてもよい。
【００５５】
リセットボタン２０ｂもまた、システムＬＳＩ４２に接続される。リセットボタン２０ｂが押されると、システムＬＳＩ４２は、ゲーム装置１２の起動プログラムを再起動する。イジェクトボタン２０ｃは、ディスクドライブ５４に接続される。イジェクトボタン２０ｃが押されると、ディスクドライブ５４から光ディスク１８が排出される。
【００５６】
図３（Ａ）ないし図３（Ｅ）は、コントローラ２２の外観の一例を示す。図３（Ａ）はコントローラ２２の先端面を示し、図３（Ｂ）はコントローラ２２の上面を示し、図３（Ｃ）はコントローラ２２の右側面を示し、図３（Ｄ）はコントローラ２２の下面を示し、そして、図３（Ｅ）はコントローラ２２の後端面を示す。
【００５７】
図３（Ａ）ないし図３（Ｅ）を参照して、コントローラ２２は、たとえばプラスチック成型によって形成されたハウジング２２ａを有している。ハウジング２２ａは、略直方体形状であり、ユーザが片手で把持可能な大きさである。ハウジング２２ａ（コントローラ２２）には、入力手段（複数のボタンないしスイッチ）２６が設けられる。具体的には、図３（Ｂ）に示すように、ハウジング２２ａの上面には、十字キー２６ａ，１ボタン２６ｂ，２ボタン２６ｃ，Ａボタン２６ｄ，−ボタン２６ｅ，ＨＯＭＥボタン２６ｆ，＋ボタン２６ｇおよび電源スイッチ２６ｈが設けられる。また、図３（Ｃ）および図３（Ｄ）に示すように、ハウジング２２ａの下面に傾斜面が形成されており、この傾斜面に、Ｂトリガースイッチ２６ｉが設けられる。
【００５８】
十字キー２６ａは、４方向プッシュスイッチであり、矢印で示す４つの方向、前（または上）、後ろ（または下）、右および左の操作部を含む。この操作部のいずれか１つを操作することによって、プレイヤによって操作可能なキャラクタまたはオブジェクト（プレイヤキャラクタまたはプレイヤオブジェクト）の移動方向を指示したり、カーソルの移動方向を指示したりすることができる。
【００５９】
１ボタン２６ｂおよび２ボタン２６ｃは、それぞれ、押しボタンスイッチである。たとえば３次元ゲーム画像を表示する際の視点位置や視点方向、すなわち仮想カメラの位置や画角を調整する等のゲームの操作に使用される。または、１ボタン２６ｂおよび２ボタン２６ｃは、Ａボタン２６ｄおよびＢトリガースイッチ２６ｉと同じ操作或いは補助的な操作をする場合に用いるようにしてもよい。
【００６０】
Ａボタンスイッチ２６ｄは、押しボタンスイッチであり、プレイヤキャラクタまたはプレイヤオブジェクトに、方向指示以外の動作、すなわち、打つ（パンチ）、投げる、つかむ（取得）、乗る、ジャンプするなどの任意のアクションをさせるために使用される。たとえば、アクションゲームにおいては、ジャンプ、パンチ、武器を動かすなどを指示することができる。また、ロールプレイングゲーム（ＲＰＧ）やシミュレーションＲＰＧにおいては、アイテムの取得、武器やコマンドの選択および決定等を指示することができる。
【００６１】
−ボタン２６ｅ、ＨＯＭＥボタン２６ｆ、＋ボタン２６ｇおよび電源スイッチ２６ｈもまた、押しボタンスイッチである。−ボタン２６ｅは、ゲームモードを選択するために使用される。ＨＯＭＥボタン２６ｆは、ゲームメニュー（メニュー画面）を表示するために使用される。＋ボタン２６ｇは、ゲームを開始（再開）したり、一時停止したりするなどのために使用される。電源スイッチ２６ｈは、ゲーム装置１２の電源を遠隔操作によってオン／オフするために使用される。
【００６２】
なお、この実施例では、コントローラ２２自体をオン／オフするための電源スイッチは設けておらず、コントローラ２２の入力手段２６のいずれかを操作することによってコントローラ２２はオンとなり、一定時間（たとえば、３０秒）以上操作しなければ自動的にオフとなるようにしてある。
【００６３】
Ｂトリガースイッチ２６ｉもまた、押しボタンスイッチであり、主として、弾を撃つなどのトリガを模した入力を行ったり、コントローラ２２で選択した位置を指定したりするために使用される。また、Ｂトリガースイッチ２６ｉを押し続けると、プレイヤオブジェクトの動作やパラメータを一定の状態に維持することもできる。また、一定の場合には、Ｂトリガースイッチ２６ｉは、通常のＢボタンと同様に機能し、Ａボタン２６ｄによって決定したアクションを取り消すなどのために使用される。
【００６４】
また、図３（Ｅ）に示すように、ハウジング２２ａの後端面に外部拡張コネクタ２２ｂが設けられ、また、図３（Ｂ）に示すように、ハウジング２２ａの上面であり、後端面側にはインジケータ２２ｃが設けられる。外部拡張コネクタ２２ｂは、図示しない別の拡張コントローラを接続するためなどに使用される。インジケータ２２ｃは、たとえば、４つのＬＥＤで構成され、４つのうちのいずれか１つを点灯することにより、点灯ＬＥＤに対応するコントローラ２２の識別情報（コントローラ番号）を示したり、点灯させるＬＥＤの個数によってコントローラ２２の電源残量を示したりすることができる。
【００６５】
さらに、コントローラ２２は、撮像情報演算部８０（図４参照）を有しており、図３（Ａ）に示すように、ハウジング２２ａの先端面には撮像情報演算部８０の光入射口２２ｄが設けられる。また、コントローラ２２は、スピーカ８６（図４参照）を有しており、このスピーカ８６は、図３（Ｂ）に示すように、ハウジング２２ａの上面であり、１ボタン２６ｂとＨＯＭＥボタン２６ｆとの間に設けられる音抜き孔２２ｅに対応して、ハウジング２２ａ内部に設けられる。
【００６６】
なお、図３（Ａ）ないし図３（Ｅ）に示したコントローラ２２の形状や、各入力手段２６の形状、数および設置位置等は単なる一例に過ぎず、それらが適宜改変された場合であっても、本発明を実現できることは言うまでもない。
【００６７】
図４はコントローラ２２の電気的な構成を示すブロック図である。この図４を参照して、コントローラ２２はプロセッサ７０を含み、このプロセッサ７０には、内部バス（図示せず）によって、外部拡張コネクタ２２ｂ、入力手段２６、メモリ７２、加速度センサ７４、無線モジュール７６、撮像情報演算部８０、ＬＥＤ８２（インジケータ２２ｃ）、バイブレータ８４、スピーカ８６および電源回路８８が接続される。また、無線モジュール７６には、アンテナ７８が接続される。
【００６８】
プロセッサ７０は、コントローラ２２の全体制御を司り、入力手段２６、加速度センサ７４および撮像情報演算部８０によって入力された情報（入力情報）を、入力データとして無線モジュール７６およびアンテナ７８を介してゲーム装置１２に送信（入力）する。このとき、プロセッサ７０は、メモリ７２を作業領域ないしバッファ領域として用いる。
【００６９】
上述した入力手段２６（２６ａ−２６ｉ）からの操作信号（操作データ）は、プロセッサ７０に入力され、プロセッサ７０は操作データを一旦メモリ７２に記憶する。
【００７０】
また、加速度センサ７４は、コントローラ２２の縦方向（ｙ軸方向）、横方向（ｘ軸方向）および前後方向（ｚ軸方向）の３軸で各々の加速度を検出する。この加速度センサ７４は、典型的には、静電容量式の加速度センサであるが、他の方式のものを用いるようにしてもよい。
【００７１】
たとえば、加速度センサ７４は、第１所定時間毎に、ｘ軸，ｙ軸，ｚ軸の各々についての加速度（ａｘ，ａｙ，ａｚ）を検出し、検出した加速度のデータ（加速度データ）をプロセッサ７０に入力する。たとえば、加速度センサ７４は、各軸方向の加速度を、−２．０ｇ〜２．０ｇ（ｇは重力加速度である。以下、同じ。）の範囲で検出する。プロセッサ７０は、加速度センサ７４から与えられる加速度データを、第２所定時間毎に検出し、一旦メモリ７２に記憶する。プロセッサ７０は、操作データ、加速度データおよび後述するマーカ座標データの少なくとも１つを含む入力データを作成し、作成した入力データを、第３所定時間（たとえば、５ｍｓｅｃ）毎にゲーム装置１２に送信する。
【００７２】
なお、図３（Ａ）−図３（Ｅ）では省略したが、この実施例では、加速度センサ７４は、ハウジング２２ａ内部の基板上の十字キー２６ａが配置される付近に設けられる。
【００７３】
無線モジュール７６は、たとえばＢｌｕｅｔｏｏｔｈの技術を用いて、所定周波数の搬送波を入力データで変調し、その微弱電波信号をアンテナ７８から放射する。つまり、入力データは、無線モジュール７６によって微弱電波信号に変調されてアンテナ７８（コントローラ２２）から送信される。この微弱電波信号が上述したゲーム装置１２に設けられた無線コントローラモジュール５２によって受信される。受信された微弱電波は、復調および復号の処理を施され、したがって、ゲーム装置１２（ＣＰＵ４０）は、コントローラ２２からの入力データを取得することができる。そして、ＣＰＵ４０は、取得した入力データとプログラム（ゲームプログラム）とに従ってゲーム処理を行う。
【００７４】
さらに、上述したように、コントローラ２２には、撮像情報演算部８０が設けられる。この撮像情報演算部８０は、赤外線フィルタ８０ａ、レンズ８０ｂ、撮像素子８０ｃおよび画像処理回路８０ｄによって構成される。赤外線フィルタ８０ａは、コントローラ２２の前方から入射する光から赤外線のみを通過させる。上述したように、モニタ３４の表示画面近傍（周辺）に配置されるマーカ３４０ｍおよび３４０ｎは、モニタ３４の前方に向かって赤外光を出力する赤外ＬＥＤである。したがって、赤外線フィルタ８０ａを設けることによってマーカ３４０ｍおよび３４０ｎの画像をより正確に撮像することができる。レンズ８４は、赤外線フィル８２を透過した赤外線を集光して撮像素子８０ｃへ出射する。撮像素子８０ｃは、たとえばＣＭＯＳセンサあるいはＣＣＤのような固体撮像素子であり、レンズ８０ｂによって集光された赤外線を撮像する。したがって、撮像素子８０ｃは、赤外線フィルタ８０ａを通過した赤外線だけを撮像して画像データを生成する。以下では、撮像素子８０ｃによって撮像された画像を撮像画像と呼ぶ。撮像素子８０ｃによって生成された画像データは、画像処理回路８０ｄで処理される。画像処理回路８０ｄは、撮
像画像内における撮像対象（マーカ３４０ｍおよび３４０ｎ）の位置を算出し、第４所定時間毎に、当該位置を示す各座標値を撮像データとしてプロセッサ７０に出力する。なお、画像処理回路８０ｄにおける処理については後述する。
【００７５】
図５は、コントローラ２２を用いてゲームプレイするときの状態を概説する図解図である。図５に示すように、ビデオゲームシステム１０でコントローラ２２を用いてゲームをプレイする際、プレイヤは、一方の手でコントローラ２２を把持する。厳密に言うと、プレイヤは、コントローラ２２の先端面（撮像情報演算部８０が撮像する光の入射口２２ｄ側）がマーカ３４０ｍおよび３４０ｎの方を向く状態でコントローラ２２を把持する。ただし、図１からも分かるように、マーカ３４０ｍおよび３４０ｎは、モニタ３４の画面の横方向と平行に配置されている。この状態で、プレイヤは、コントローラ２２が指示する画面上の位置を変更したり、コントローラ２２と各マーカ３４０ｍおよび３４０ｎとの距離を変更したりすることによってゲーム操作を行う。
【００７６】
図６は、マーカ３４０ｍおよび３４０ｎと、コントローラ２２との視野角を説明するための図である。図６に示すように、マーカ３４０ｍおよび３４０ｎは、それぞれ、視野角θ１の範囲で赤外光を放射する。また、撮像情報演算部８０の撮像素子８０ｃは、コントローラ２２の視線方向を中心とした視野角θ２の範囲で入射する光を受光することができる。たとえば、マーカ３４０ｍおよび３４０ｎの視野角θ１は、共に３４°（半値角）であり、一方、撮像素子８０ｃの視野角θ２は４１°である。プレイヤは、撮像素子８０ｃが２つのマーカ３４０ｍおよび３４０ｎからの赤外光を受光することが可能な位置および向きとなるように、コントローラ２２を把持する。具体的には、撮像素子８０ｃの視野角θ２の中に少なくとも一方のマーカ３４０ｍおよび３４０ｎが存在し、かつ、マーカ３４０ｍまたは３４０ｎの少なくとも一方の視野角θ１の中にコントローラ２２が存在する状態となるように、プレイヤはコントローラ２２を把持する。この状態にあるとき、コントローラ２２は、マーカ３４０ｍおよび３４０ｎの少なくとも一方を検知することができる。プレイヤは、この状態を満たす範囲でコントローラ２２の位置および向きを変化させることによってゲーム操作を行うことができる。
【００７７】
なお、コントローラ２２の位置および向きがこの範囲外となった場合、コントローラ２２の位置および向きに基づいたゲーム操作を行うことができなくなる。以下では、上記範囲を「操作可能範囲」と呼ぶ。
【００７８】
操作可能範囲内でコントローラ２２が把持される場合、撮像情報演算部８０によって各マーカ３４０ｍおよび３４０ｎの画像が撮像される。すなわち、撮像素子８０ｃによって得られる撮像画像には、撮像対象である各マーカ３４０ｍおよび３４０ｎの画像（対象画像）が含まれる。図７は、対象画像を含む撮像画像の一例を示す図である。対象画像を含む撮像画像の画像データを用いて、画像処理回路８０ｄは、各マーカ３４０ｍおよび３４０ｎの撮像画像における位置を表す座標（マーカ座標）を算出する。
【００７９】
撮像画像の画像データにおいて対象画像は高輝度部分として現れるため、画像処理回路８０ｄは、まず、この高輝度部分を対象画像の候補として検出する。次に、画像処理回路８０ｄは、検出された高輝度部分の大きさに基づいて、その高輝度部分が対象画像であるか否かを判定する。撮像画像には、対象画像である２つのマーカ３４０ｍおよび３４０ｎの画像３４０ｍ’および３４０ｎ’のみならず、窓からの太陽光や部屋の蛍光灯の光によって対象画像以外の画像が含まれていることがある。高輝度部分が対象画像であるか否かの判定処理は、対象画像であるマーカ３４０ｍおよび３４０ｎの画像３４０ｍ’および３４０ｎ’と、それ以外の画像とを区別し、対象画像を正確に検出するために実行される。具体的には、当該判定処理においては、検出された高輝度部分が、予め定められた所定範囲内の大きさであるか否かが判定される。そして、高輝度部分が所定範囲内の大きさである場合には、当該高輝度部分は対象画像を表すと判定される。逆に、高輝度部分が所定範囲内の大きさでない場合には、当該高輝度部分は対象画像以外の画像を表すと判定される。
【００８０】
さらに、上記の判定処理の結果、対象画像を表すと判定された高輝度部分について、画像処理回路８０ｄは当該高輝度部分の位置を算出する。具体的には、当該高輝度部分の重心位置を算出する。ここでは、当該重心位置の座標をマーカ座標と呼ぶ。また、重心位置は撮像素子８０ｃの解像度よりも詳細なスケールで算出することが可能である。ここでは、撮像素子８０ｃによって撮像された撮像画像の解像度が１２６×９６であるとし、重心位置は１０２４×７６８のスケールで算出されるものとする。つまり、マーカ座標は、（０，０）から（１０２４，７６８）までの整数値で表現される。
【００８１】
なお、撮像画像における位置は、撮像画像の左上を原点とし、下向きをＹ軸正方向とし、右向きをＸ軸正方向とする座標系（ＸＹ座標系）で表現されるものとする。
【００８２】
また、対象画像が正しく検出される場合には、判定処理によって２つの高輝度部分が対象画像として判定されるので、２箇所のマーカ座標が算出される。画像処理回路８０ｄは、算出された２箇所のマーカ座標を示すデータを出力する。出力されたマーカ座標のデータ（マーカ座標データ）は、上述したように、プロセッサ７０によって入力データに含まれ、ゲーム装置１２に送信される。
【００８３】
ゲーム装置１２（ＣＰＵ４０）は、受信した入力データからマーカ座標データを検出すると、このマーカ座標データに基づいて、モニタ３４の画面上におけるコントローラ２２の指示位置（指示座標）と、コントローラ２２からマーカ３４０ｍおよび３４０ｎまでの各距離とを算出することができる。具体的には、２つのマーカ座標の中点の位置から、コントローラ２２の向いている位置すなわち指示位置が算出される。また、撮像画像における対象画像間の距離が、コントローラ２２と、マーカ３４０ｍおよび３４０ｎとの距離に応じて変化するので、２つのマーカ座標間の距離を算出することによって、ゲーム装置１２はコントローラ２２とマーカ３４０ｍおよび３４０ｎとの間の距離を把握できる。
【００８４】
以下、本願発明の一実施例における、メッセージの送受信について、概要を説明する。図８は上述のゲーム装置１２を用いた通信システム１００の一例を示す図解図である。図８に示すように、通信システム１００は、複数のゲーム装置１２を含み、各ゲーム装置１２はインターネットやＬＡＮのようなネットワーク１０６を介して、メールサーバ１０２および配信サーバ１０４に接続される。このようなネットワーク１０６に接続されることによって、メールサーバ１０２を介したメッセージの送受信や配信サーバ１０４からのデータのダウンロードを行うことが可能となる。
【００８５】
なお、この実施例では、複数のゲーム装置１２がネットワーク１０６に接続されている場合について説明するが、ゲーム装置１２は一台でも構わない。また、配信サーバ１０４は、ダウンロードデータ（コンテンツ）の種類に応じて複数設けられてもよい。さらに、ネットワーク１０６にはＰＣも接続され、また、携帯電話網を介して携帯電話機も接続される。それ以外にも、様々な電子機器をネットワークに接続して、メールサーバ１０２を介してゲーム装置１２とメッセージの送受信を行うことができる。
【００８６】
ゲーム装置１２同士は、ネットワーク１０６を介して通信可能である。プレイヤが入力したメッセージやゲーム装置１２で生成したメッセージは、電子メールの形式に変換され、ネットワーク１０６およびメールサーバ１０２を介して、ゲーム装置１２同士で送受信（やり取り）される。このため、メールサーバ１０２は、汎用的なメールサーバを用いることができる。したがって、ゲーム装置１２は、ＰＣや携帯電話機のような端末（他のゲーム装置１２以外の端末）との間でメッセージすなわち電子メールをやり取りすることも可能である。このようなゲーム装置１２におけるメッセージの送受信の処理は、ユーザが送受信指示を行わなくとも所定のスケジュールで自動的に実行されるので、ユーザは定期的なチェック作業を自ら行わなくとも、メッセージを受け取った状態でゲームや他のアプリケーションをプレイすることができる。また、ゲーム装置１２は、アドレス帳（後述するフレンドリスト４４ｄ）に宛先を登録したゲーム装置１２または他のゲーム装置１２以外の端末（以下、「他の端末」ということがある。）との間でのみメッセージの送受信を行うようにすることもでき、したがって汎用的なメールシステムを用いてもスパムメールのような不要なメッセージをユーザが受け取らないようにすることが可能である。
【００８７】
また、ゲーム機１２は、受信したメッセージをモニタ３４に表示するためのアプリケーションである伝言板機能を実行することができる。ただし、その他のアプリケーション（ゲーム等）に依存する固有のメッセージであって、当該アプリケーションによってのみ利用されるデータについては、当該アプリケーションでのみ読み取り可能とすることができる。したがって、特定のユーザのみにメッセージを送りたい場合には、個々のアプリケーションに依存するデータをメッセージに含めて送信すれば、伝言板機能では読めない形式にすることができる。ただし、アプリケーションの種類に拘わらず参照可能なメッセージは、伝言板機能によってモニタ３４に表示して誰でも参照する（読む）ことができる。
【００８８】
伝言板機能は、受信したメッセージをモニタ３４に表示する機能を有するアプリケーションであり、ネットワーク１０６から取得したメッセージを表示する。ただし、他のゲーム装置１２や他の端末から受信したメッセージのみならず、自身宛に作成したメッセージを同様に表示することもできる。したがって、ゲーム装置１２がネットワーク１０６に接続されていない場合であっても、家庭内の伝言板ないし個人用のメモ帳として、この伝言板機能を利用することができるし、ゲーム等のアプリケーションによって生成された記録を後から伝言板機能によって閲覧できるようにしておくこともできる。このとき、ゲーム機１２において生成されたメッセージを、ネットワーク１０６から取得したメッセージと同様の形式（本実施例においては電子メール形式）で同じ領域に記憶しておくようにすれば、表示のための処理を個別に用意する必要がなくなる。たとえば、メモまたは伝言を生成する際に電子メール形式のデータに変換を行ったり、ゲームプログラムの処理において電子メール形式のデータを生成したりすればよい。
【００８９】
図２５に、伝言板機能によってモニタ３４にメッセージが表示されている状態の一例を示す。図２５の例においては、伝言板機能は、その日受け取ったメッセージを一覧表示させる。たとえば、ネットワークから取得したメッセージや、家族からの伝言、ゲームをプレイした際の履歴等の表示が可能である。また、メモや伝言、またはネットワークへ送信したいメッセージを作成するためのプログラムを起動するためのボタンが表示される。メッセージのデータは日付毎に管理され、他の日を指定することによって画面の切り替えが行われ、指定された日に受け取ったメッセージが同様に一覧表示される。メッセージの内容（本文等）については、最初から閲覧できる状態であってもよいし、一覧においては時刻やタイトルのみ表示するようにして、当該メッセージを開くことで閲覧できるようにしてもよい。
【００９０】
また、詳細な説明は省略するが、メッセージ（電子メール）には、ゲームアプリケーションや画像を描画するアプリケーションによって描画された画像（この実施例では、静止画）のデータ（画像データ）や他の端末に保持された画像データを添付することができる。この画像データは、伝言板機能により、メッセージとともにモニタ３４に表示される。たとえば、他の端末に保持された画像データは、デジタルカメラや携帯電話機のカメラで撮影された画像（静止画）またはそのサムネイル画像のデータである。
【００９１】
さらに、詳細な説明は省略するが、メッセージ（電子メール）には、ゲームデータのようなアプリケーションに依存したデータを添付することもできる。
【００９２】
以下、メッセージに含まれる情報について説明する。この実施例では、メッセージには、図９に示すようなヘッダ情報が付加される。具体的には、ヘッダ情報は、送信元、宛先の情報、題目、日時、送信側のアプリケーションの識別情報、伝言板表示ＯＮ／ＯＦＦ属性、伝言板日時指定、上書きタグ、他アプリ制限、消滅属性、受信告知属性、代替ニックネームおよび返信属性を含む。
【００９３】
送信元の情報は、当該メッセージの送信元（送信する側）の、ゲーム装置１２の識別情報（もしくはメールアドレス）や他の端末のメールアドレスである。ここで、ゲーム装置１２の識別情報は、当該ゲーム装置１２を個別に識別するための情報であり、たとえば、数字およびアルファベットの少なくとも一方を用いた文字列である。また、ゲーム装置１２のメールアドレスには、当該ゲーム装置１２の識別情報の文字列を用いたメールアドレスが設定される。ゲーム装置１２のメールアドレスは識別情報から一意に決定されるので、いずれの情報によって管理するようにしてもよい。宛先の情報は、当該メッセージの宛先すなわち受信側（送信先）のゲーム装置１２の識別情報（メールアドレス）または他の端末のメールアドレスである。題目は、当該メッセージの標題である。
【００９４】
日時の情報は、当該メッセージを送信（または作成）した年月日および時間（時分秒）である。送信側のアプリケーションの識別情報（アプリＩＤ）は、当該アプリケーションを識別するための識別番号ないし識別記号である。この実施例では、当該メッセージを作成したアプリケーションの識別情報が記述される。上述の伝言板機能もアプリケーションの１つであるので、伝言板において作成されたメッセージにも伝言板を示す識別情報が含まれることになる。
【００９５】
受信告知属性は、当該メッセージを受信したことをユーザに告知するか否かを示す情報であって、たとえば「無し」と「パターンＩＤ」の値を示す。受信告知属性が「無し」を示す場合には、当該メッセージを受信しても受信側で告知処理が実行されない。しかし、受信告知属性が「パターンＩＤ」を示す場合には、当該メッセージを受信したことをパターンＩＤが示すパターンに従ってディスクスロット１６の挿入口のＬＥＤを明滅（点滅）させる。それ以外にも、パターンに従う音（音楽）を鳴らすようにしてもよい。
【００９６】
伝言板表示ＯＮ／ＯＦＦ属性の情報は、当該メッセージを伝言板において表示するか否かを識別するための情報である。この実施例では、伝言板表示ＯＮ／ＯＦＦ属性は、「ＯＮ」、「指定時間」、「ＯＦＦ」の３種類で識別される。この属性が「ＯＮ」を示す場合には、当該メッセージは伝言板に表示される。また、かかる場合には、メッセージが伝言板に表示（掲載）されるとともに上述した受信告知が行われるようにしてもよい。図示は省略するが、たとえば、ゲーム装置１２のディスクスロット１６の挿入口を点滅させたり、音（音楽）を出力したりすることにより、メッセージの表示を告知することができる。また、この属性が「指定時間」を示す場合には、当該メッセージは到着（受信）してから指定時間以内は伝言板に表示されない。したがって、たとえば、ゲーム内のイベントの告知や或る日時にゲーム装置１２を起動させたい場合に、「指定時間」が記述されたメッセージを送信する。さらに、この属性が「ＯＦＦ」を示す場合には、当該メッセージは伝言板に表示されない。
【００９７】
伝言板日時指定の情報は、当該メッセージを伝言板に表示する年月日および時間を指定するか否かを示す情報である。この情報として、年月日および時間が指定されている場合には、当該メッセージは当該年月日および時間に伝言板に表示される。しかし、この情報として、年月日および時間が指定されていない場合には、当該メッセージは受信した日時に表示される。
【００９８】
上書きタグは、受信されたメッセージで上書きを行うか否かに関する情報である。この実施例では、上書きタグは、「ＯＮ」または「ＯＦＦ」と、「上書きＩＤ」とが含まれる。当該メッセージ（説明の都合上、「今回のメッセージ」という。）についての上書きタグが「ＯＮ」を示すとき、送信元と、アプリＩＤと、上書きＩＤとのすべてが一致するメッセージ（説明の都合上、「前回のメッセージ」という。）が受信メッセージボックス４４ｂに存在するかどうかを比較判断する。そして、送信元の情報、アプリＩＤおよび上書きＩＤのすべてが一致する場合には、今回のメッセージが前回のメッセージに上書きされる。つまり、同じアプリケーション用のデータで、同じ送信者からのメッセージについて最新のものだけが必要な場合（たとえばゲームのスコアの最高記録など）には、送信側のゲーム装置１２において、当該アプリケーションがメッセージを作成する際に、上書きが「ＯＮ」を示し、同じ上書きＩＤを有するメッセージを作成するようにすれば、受信側で常に最新のメッセージに上書きされることになる。このようにすることで、無駄なメッセージによってフラッシュメモリ４４の容量を圧迫することを防ぐことができる。しかし、送信元、アプリＩＤおよび上書きＩＤのいずれか一つでも異なる場合には、別の目的のメッセージであるということなので、今回のメッセージによって上書きされることはない。また、今回のメッセージについての上書きタグＩＤが「ＯＦＦ」を示す場合にも、今回のメッセージが上書きされることはない。
【００９９】
他アプリ制限の情報は、当該メッセージをアプリＩＤで示されるアプリケーション以外のアプリケーションから参照可能にするかどうかを示す情報である。この情報が他のアプリケーションから参照可能な電子メール（メッセージ）であることを示す（他アプリ制限がオフである）場合には、当該メッセージは他のアプリケーションからも読取可能である。一方、この情報が他のアプリケーションから参照できないメッセージであることを示す（他アプリ制限がオンである）場合には、当該メッセージは他のアプリケーションから読み取ることが禁止される。ただし、他アプリ制限がオンである場合には、当該メッセージの内容を他のアプリケーションから参照できないだけであって、当該メッセージは伝言板には表示されるようにしてもよい。
【０１００】
なお、他の端末からの電子メールは、ゲーム装置１２のアプリケーションで生成されるメッセージではないため、他アプリ制限の情報を含めることができず、当該電子メール（メッセージ）は、自動的にすべてのアプリケーションで参照可能となる。
【０１０１】
消滅属性は、当該メッセージを受信側で自動的に消滅させるか否かを示す情報である。消滅属性が「消去せず」を示す場合には、受信側で当該メッセージを自動的に消滅させない。しかし、消滅属性が「指定時間」を示す場合には、当該メッセージを到着（受信）してから指定時間経過後に、受信側で当該メッセージを自動的に消滅させる。すなわち、受信したメッセージが伝言板機能等のアプリケーションで利用されないまま指定時間が経過した場合に当該メッセージが消滅するので、たとえばお知らせのような期限後には意味が無くなる性質の情報が含まれるメッセージについて、無駄に保存しておくことでフラッシュメモリ４４の容量を圧迫することを防ぐことができ、期限が過ぎてしまった後でユーザに無駄な情報を与えることを防ぐこともできる。
【０１０２】
代替ニックネームは、当該メッセージを表示する場合に、送信側から指定されるニックネームを表示するか否かを示す情報である。この情報が空の場合には、当該メッセージを表示するとき、送信者の情報として、アドレス帳に登録されたニックネームが参照され、当該ニックネームが表示される。また、代替ニックネームに文字列が含まれている場合には、当該メッセージを表示するとき、アドレス帳に登録されたニックネームに代えて、当該代替ニックネームの文字列が表示される。代替ニックネームに含まれる文字列は、名前に限らず、所定の文言を当該表示箇所に表示させるために用いることもできる。
【０１０３】
返信属性は、当該メッセージへの返信が可能か否かを示す情報である。ユーザ同士がメッセージのやり取りを行う場合は返信ができるのが通常であるが、アプリケーションから自動的に作成されたメッセージ等（たとえばゲームプレイ結果の記録）については、ユーザが返信を行うべきでないような情報もあり得るため、このような返信属性を設定する。返信属性が「可」を示すとき、当該メッセージへの返信が可能である。かかる場合には、たとえば、伝言板機能で当該メッセージを表示している場合に、ユーザが返信することを選択（指示）すると、返信するためのメッセージ入力画面（図示せず）が表示され、返信メッセージの作成が可能となる。しかし、返信属性が「不可」であるとき、当該メッセージへの返信が不能である。かかる場合には、たとえば、伝言板機能で当該メッセージを表示している場合に、ユーザが返信することを選択（指示）できないようにしたり、当該メッセージに返信することができない旨のメッセージを表示したりする。
【０１０４】
なお、上記のヘッダ情報の他に、一般的な電子メールにおいては、Ｃｃ，Ｂｃｃ，Ｒｅｐｌｙ−Ｔｏ，Ｒｅｔｕｒｎなどのヘッダ情報もあるが、本実施例においては、ゲーム装置１２では、ヘッダに含まれる情報のうち使用しないものは送信データおよび受信データのいずれの場合であっても無視することとする。
【０１０５】
図１０は、ゲーム装置１２に内蔵されるフラッシュメモリ４４に記憶されるデータの構成を模式的に示した図解図である。この図１０を用いて、本実施例におけるメッセージの送受信とダウンロード処理について概要を説明する。ゲーム装置１２は、メールサーバ１０２とメッセージの送受信を行い、配信サーバ１０４からデータのダウンロードを行い、２種類の通信処理を行う。メッセージの送受信およびダウンロードの処理は、入出力プロセッサ４２ａによって実行される。フラッシュメモリ４４は記憶領域として、送信メッセージボックス４４ａ、受信メッセージボックス４４ｂ、管理用ファイル４４ｃ、フレンドリスト４４ｄ、タスクリスト４４ｅ、セーブ領域４４ｆ、データベース４４ｇおよび本体アプリ領域４４ｈを含む。
【０１０６】
送信メッセージボックス４４ａは、ゲーム装置１２から他のゲーム装置１２や他の端末に送信する電子メール形式のメッセージ（送信データとする）を記憶する領域である。図１０からも分かるように、送信データは、メールサーバ１０２に送信される。したがって、ゲーム装置１２は、メールサーバ１０２およびネットワーク１０６を介して、他のゲーム装置１２にメッセージを送信することができる。入出力プロセッサ４２ａは、所定のスケジュールに基づいて（たとえば、１０分毎に）送信メッセージボックス４４ａを参照し、送信データが記憶されている場合には、記憶されている送信データをネットワーク１０６に送信する。送信データがネットワーク１０６に送信されると、当該送信データは送信メッセージボックス４４ａから削除される。
【０１０７】
したがって、電子メールの送信を入出力プロセッサ４２ａがアプリケーションとは独立に行うので、伝言板機能やゲーム等、ＣＰＵ４０で実行されるアプリケーションでは、メッセージの作成後、当該メッセージを電子メール形式で送信メッセージボックス４４ａに記録しておく処理を行うだけで、メッセージをネットワークに対して送信することができる。
【０１０８】
なお、本実施例においては、より汎用的な電子メール形式のデータをメールサーバと送受信するが、データの形式は電子メールに限られず、さまざまなフォーマットにて転用可能である。特にゲーム装置１２同士の通信に限られる場合は、汎用的なフォーマットでなくともよいし、他の端末とも通信する場合であっても、当該端末で処理可能な汎用フォーマットであれば適用できる。また、サーバの種類も、端末からのアクセスまで送信されたデータを保持する性質のものであれば、メールサーバ以外の種類のサーバでもよい。
【０１０９】
また、何らかの理由で送信機能が停止されていたり、通信障害が発生したりしている場合には、送信データの送信が行われないため、送信メッセージボックス４４ａのデータ量が一杯になる可能性がある。かかる場合には、送信メッセージの送信メッセージボックス４４ａへの登録を受け付けないようにする。
【０１１０】
受信メッセージボックス４４ｂは、他のゲーム装置１２、他の端末や配信サーバ１０４から受信される電子メール形式のメッセージ（この実施例では、上記の「送信データ」に対して「受信データ」ということがある。）を記憶する領域である。図１０からも分かるように、受信データは、メールサーバ１０２や配信サーバ１０４から送信される。入出力プロセッサ４２ａは、所定のスケジュールに基づいて（たとえば、１０分毎に）メールサーバ１０２にアクセスして、サーバに新着メールがあるかどうかを確認し、新着メールがある場合に、当該新着メールを受信して受信データとして受信メッセージボックス４４ｂに記憶する。受信メッセージボックス４４ｂでは、受信データは、アプリケーションによって開かれ（使用され）削除されるか、当該受信メッセージボックス４４ｂが一杯になるまで保持される。ただし、受信メッセージボックス４４ｂが一杯になると、新たな受信データを受信する毎に、最も古い受信データから順に削除される。また、ゲーム装置１２が通常モードである場合に、受信メッセージボックス４４ｂに保持された受信データは、ゲームデータのようなアプリケーションに依存するデータが添付されたものを除いて、ヘッダ情報に従ってデータベース４４ｇに移動され、伝言板機能によって読み出し可能な状態となる。
【０１１１】
なお、メールサーバ１０２からの受信データは、他のゲーム装置１２や他の端末からのメッセージである。また、配信サーバ１０４からの受信データは、配信サーバ１０４の管理者等からの複数ユーザに対するお知らせのようなメッセージである。たとえば、配信サーバ１０４の管理者等からは、新作のゲームアプリケーション（ゲームソフト）の情報やゲーム内におけるイベントの情報などのメッセージが送信（通知）される。配信サーバ１０４から受信したデータを受信メッセージボックス４４ｂに記憶する処理の詳細については後述する。
【０１１２】
管理用ファイル４４ｃは、ゲーム装置１２についての管理情報であり、ゲーム装置１２の識別情報、ユーザのプロファイルなど、ゲーム装置１２固有の情報が記憶され、必要に応じて読み出される。フレンドリスト４４ｄは、いわゆる電子メールのアドレス帳に相当し、登録した他のゲーム装置１２の識別情報（またはメールアドレス）および他の端末のメールアドレスが記述される。このフレンドリスト４４ｄは、伝言板機能を実行する場合に参照可能であるのみならず、各種アプリケーションからも参照可能である。ただし、フレンドリスト４４ｄに記述された他のゲーム装置１２の識別情報および他の端末のメールアドレスのうち、後述するフレンド登録が実行された他のゲーム装置１２の識別情報または他の端末のメールアドレスから送信された電子メール（受信データ）以外は削除される。つまり、送信元が不明である場合には、受信データがフィルタリングされる。これによって、スパムメールのような所望でない電子メールを自動的に削除することができる。
【０１１３】
タスクリスト４４ｅは、配信サーバ１０４からデータをダウンロードするスケジュールを表すタスクのリストであって、ゲーム装置１２の必要のために予め登録されたタスクやユーザによって任意に登録されたタスクをそれぞれ記憶する。それぞれのタスクが実行されることによって、ダウンロード処理が行われることになる。ただし、この実施例では、１つのアプリケーションにおいては、１つのタスクを登録することができる。図２６に、各タスクに含まれる属性情報の一例を示す。１つのタスクには、タスクの識別情報（タスクＩＤ）、アプリケーションの識別情報（アプリＩＤ）、配信元のＵＲＬ、残りダウンロード回数、タスクの起動間隔、リトライマージン、コンテンツ更新間隔およびファイル名が含まれる。
【０１１４】
タスクＩＤは、当該タスクを一意に識別するためのＩＤである。アプリＩＤは、当該タスクを登録したアプリケーションを一意に識別するためのＩＤである。このアプリＩＤは、タスクの登録処理を行ったアプリケーションに応じて決定される。
【０１１５】
配信元のＵＲＬは、配信元（配信サーバ１０４）の場所を示し、ダウンロードデータのファイル名までを含む。この配信元のＵＲＬは、ユーザによって設定されたり、アプリケーションによって自動的に設定されたりする。
【０１１６】
残りダウンロード回数は、ダウンロードを実行可能な回数を示す。この実施例では、ゲーム装置１２（入出力プロセッサ４２ａ）がダウンロードのために、ネットワーク１０６（配信サーバ１０４）に接続要求（リクエスト）を送信すると、通常の場合において残りダウンロード回数が１減算される。そして、残りダウンロード回数が０になると、当該タスクはタスクリスト４４ｅから削除され、当該タスクは実行不能となる。残りダウンロード回数を設定することにより、必要な期間において当該ダウンロードを行わせることができ、ダウンロードが不要になっても無駄なダウンロード処理を実行し続けることを防ぐことができる。
【０１１７】
タスクの起動間隔は、タスクを実行する時間間隔であり、具体的には、タスクを実行してから次にタスクを実行するまでの時間（期間）を意味する。ただし、タスクを登録した時点では、その登録時刻を基準にして、次にタスクを実行する時間が決定される。このタスクの起動間隔は、ユーザによって設定されたり、ダウンロードデータ（コンテンツ）の種類に応じて自動的に設定されたりする。
【０１１８】
リトライマージンは、ダウンロードの起動間隔によって決まる次回のタスクの実行時刻（予定時刻）を超過することが許容される時間である。たとえばゲーム装置１２の電源が完全にＯＦＦされている場合や、ネットワークに障害が生じている場合等には、タスクを実行することができず、次にタスクが実行可能な状態になった場合にはタスクの予定時刻を超過している場合があるが、予定時刻を大幅に超過した場合には、既にダウンロードされるデータ自体が不要なものになっている場合がある。したがって、タスク登録時に上記リトライマージンを設定し、タスクの起動間隔に応じてタスクの予定時刻が決定されると、リトライマージンに応じて、リトライが許容される時刻（リトライ許容時刻）が決定される。このリトライ許容時刻を越えると、当該タスクは実行されず、その後、タスクリスト４４ｅから削除される。このリトライマージンは、ユーザによって設定されたり、ダウンロードデータの種類に応じて自動的に設定されたりする。
【０１１９】
コンテンツ更新間隔は、配信元のＵＲＬに関して当該配信元で設定されるコンテンツ（ダウンロードデータ）を更新する間隔の平均値である。したがって、ダウンロードデータの種類によっては、このコンテンツ更新間隔が示すダウンロードデータを更新する間隔の平均値を考慮して、タスク起動間隔が設定される。具体的には、タスク起動間隔をコンテンツ更新間隔よりも長い時間に設定しておけば、同じダウンロードデータを重複して取得するような無駄を無くすことができる。逆に、タスク起動間隔をコンテンツ更新間隔よりも短い時間に設定しておけば、更新されるコンテンツのダウンロードを逃すことが無くなる。更新間隔の平均値は、予め想定されている値でもよいし、ダウンロードを実行する毎に配信サーバ１０４から更新間隔の平均値を取得してタスクを更新するようにしてもよい。
【０１２０】
ファイル名は、ダウンロードデータを保存する場合に付与するファイル名であり、たとえば、オプションによって指定可能である。ただし、ダウンロードデータにはファイル名が付されているため、ファイル名を指定せずとも所定のファイル名でデータを取得することは可能である。
【０１２１】
なお、タスクの実行については後で詳細に説明する。ダウンロードデータは、その識別情報（アプリＩＤ）が示すアプリケーションにおいて利用することができる。たとえば、ゲームのアプリケーションにおいては、ダウンロードデータは、当該ゲームについての追加マップ、追加キャラクタ、追加アイテムなどのデータである。
【０１２２】
図１０に戻って、セーブ領域４４ｆは、アプリケーションのデータを保存（セーブ）する領域であり、領域内にダウンロードボックス４４０を含む。ダウンロードボックス４４０は、上述したように、タスクに従って配信サーバ１０４からダウンロードされたダウンロードデータが記憶される領域である。詳細な説明は省略するが、ダウンロードデータには、タスクが登録されたアプリケーションを識別するためのアプリＩＤが予め付されている。ただし、アプリＩＤは必ずしもダウンロードデータに予め付されている必要はなく、他の実施例ではダウンロードボックス４４０に登録する際に、タスクの属性情報が示すアプリＩＤを参照して、これを付すようにしてもよい。したがって、様々な種類のアプリケーションについてのダウンロードデータがダウンロードボックス４４０に記憶されている場合であっても、そのアプリＩＤによって各ダウンロードデータを識別することができる。また、セーブ領域４４ｆは、アプリケーション毎に領域が確保されている。したがって、他の実施例では、ダウンロードデータに対応したアプリケーションのデータを記憶する領域内にアプリケーション毎のダウンロードボックスを設けるようにしてもよい。
【０１２３】
データベース４４ｇは、上述の伝言板機能によって利用される、日付毎のメッセージを格納しておく領域であり、他のアプリケーションからも参照可能である。上述したように、受信データは受信メッセージボックス４４ｂに記憶されるが、受信メッセージボックス４４ｂの容量は有限であり、一杯になると、受信データは古いものから順に削除する。したがってメッセージの長期間保存や共用化のために、データベース４４ｇを設け、受信データ（メッセージ）は、たとえばゲームデータが添付されたもののような、のような個々のアプリケーションでしか利用しないものを除いて、受信メッセージボックス４４ｂからデータベース４４ｇに移動される。このとき、メッセージのヘッダ情報が参照され、日付毎に管理されるデータベース４４ｇの各領域に記憶される。たとえば、伝言板日時指定の情報として年月日および時間が記述されている場合には、当該受信データは指定された年月日に対応する領域に記憶される。ただし、メッセージのヘッダ情報に日時等の指定が無ければ、当該メッセージを受信した日に対応する領域に、当該メッセージは記憶される。日付毎の領域の管理方法としては、たとえば日付毎にフォルダを設定し、メッセージを対応するフォルダ内に保存するようにすればよい。また、保存する際のファイル名を、時刻を表わすファイル名にしてもよい。
【０１２４】
なお、図示は省略するが、メモリカードがメモリカード用コネクタ６２に装着されている場合には、データベース４４ｇの内容はメモリカードに自動的またはユーザの指示によりバックアップすることができる。
【０１２５】
本体アプリ領域４４ｈは、本体機能として組み込まれたアプリケーションのプログラム（ソフト）を記憶する領域である。たとえば、ゲーム装置１２を起動した際のメニュープログラムや、伝言板機能、フレンド登録機能のようなゲーム装置１２自体の機能（本体機能）のアプリケーションは、本体アプリ領域４４ｈに記憶（インストール）されている。つまり、ゲーム装置１２は、光ディスク１８に記憶されているゲーム等のプログラムを読み出してアプリケーションを実行することも、フラッシュメモリ４４に記憶されているプログラムを読み出してアプリケーションを実行することも可能なゲーム装置である。また、本体アプリ領域４４ｈに記憶されるプログラムは上述のソフト以外にも追加することが可能である。
【０１２６】
次に、図１１および図１２を参照して、フレンド登録の手順について説明する。フレンド登録は、予めメッセージの送受信を許可する相手をフレンドリスト４４ｄに登録しておくものである。本実施例においては、メールサーバ１０２から受信するメッセージのうち、フレンド登録が行われていない送信元から送信されたメッセージは自動的に削除される。つまり、ゲーム機１２同士でメッセージのやり取りを行う場合には、互いのゲーム機１２において相手をフレンド登録しておく必要がある。ここで、フレンド登録においては、一方的に登録が行われている状態ではなく、相互に登録の意思があることが確認されている関係が確立されるべきであるが、以下では、当該関係を「フレンド関係」と呼ぶ。具体的には、ゲーム装置１２同士で互いにフレンド登録が行われ、相互の登録の確認が完了した状態、およびゲーム装置１２と他の端末との間において、ゲーム装置１２が他の端末を登録し、他の端末において当該登録を許可したことをゲーム装置１２側で確認した状態である。したがって、フレンド関係を確立させるために、ゲーム装置１２と、他のゲーム装置１２またはそれ以外の端末との間で、それぞれ以下のような手順が実行される。図１１はゲーム装置１２同士でのフレンド登録の手順を示し、図１２はゲーム装置１２と他の端末とのフレンド登録の手順を示す。このフレンド登録は、メッセージの送受信よって行われる。つまり、各ゲーム装置１２の入出力プロセッサ４２ａにおける処理を経てフレンド登録が実行される。
【０１２７】
なお、図１１では、２台のゲーム装置１２を分かり易くするために、一方のゲーム装置１２を「ゲーム装置Ａ」と呼び、他方のゲーム装置１２を「ゲーム装置Ｂ」と呼ぶことにする。また、図１２では、ゲーム装置１２を「ゲーム装置Ｃ」と呼び、他の端末を「端末Ｄ」と呼ぶことにする。
【０１２８】
また、フレンド登録では、その登録に先立って、ユーザ同士予め連絡をとったり直接話し合っておいたりすることにより、ゲーム装置１２の識別情報や他の端末のメールのアドレスを互いに知っている必要がある。ただし、1人のユーザが所有するゲーム装置１２と、他の端末とをフレンド登録する場合には、当該ユーザが他の端末のメールアドレスを知っていればよい。以下、時間軸に従ってフレンド登録の手順を説明する。
【０１２９】
まず、図１１を参照して、ゲーム装置１２同士の間でフレンド関係を確立させる手順を説明する。フレンドリスト４４ｄへの登録は、それぞれのゲーム装置１２においてそれぞれのユーザが行うものであるので、登録のタイミングは異なることになるが、ここでは先に登録を行ったゲーム装置１２をゲーム装置Ａとして説明する。ゲーム装置Ａのユーザが、当該ゲーム装置Ａのフレンドリスト４４ｄにゲーム装置Ｂのメールアドレス（識別情報）を入力し、登録する。すると、ゲーム装置Ａは、ゲーム装置Ｂのメールアドレスをアドレス帳（フレンドリスト４４ｄ）に登録した旨のメッセージ（登録メッセージ）をゲーム装置Ｂに自動送信する。上述したように、登録メッセージは、電子メールの形式で送信される。ただし、ここでは、ゲーム装置１２同士で自動的にメッセージが送受信されるため、ゲーム装置１２で解読可能であればよい。したがって、この登録メールは、単にアルファベットや数字を並べた文字列のように、人間が解読できないメッセージであってもよいし、空のメールであってもよい。以下、ゲーム装置１２同士で自動的にメッセージを送受信する場合について同様である。
【０１３０】
一方、ゲーム装置Ｂでは、当該登録メッセージを受信するが、上述のように、それぞれのユーザで登録のタイミングは異なり、この段階ではゲーム装置Ａのメールアドレスが未登録であるため、ゲーム装置Ｂは、ゲーム装置Ａからの登録メッセージを受信すると、そのままこの登録メッセージを削除する。この時点では、ゲーム装置Ａにおいて、ゲーム装置Ｂとの間のフレンド関係が成立していない状態である。当然のことながら、ゲーム装置Ｂにおいても、ゲーム装置Ａとの間のフレンド関係は成立していない。
【０１３１】
その後、ゲーム装置Ｂのユーザが、当該ゲーム装置Ｂのフレンドリスト４４ｄにゲーム装置Ａのメールアドレスを登録すると、ゲーム装置Ｂは、ゲーム装置Ａのメールアドレスをアドレス帳に登録した旨の登録メッセージをゲーム装置Ａに自動送信する。ゲーム装置Ａでは、既にゲーム装置Ｂのメールアドレスがフレンドリスト４４ｄに登録されているため、ゲーム装置Ａは、ゲーム装置Ｂから送信された登録メッセージを受信して、受信メッセージボックス４４ｂに保持する。このことによって、互いに登録を行ったことが確認されるので、ゲーム装置Ａにおいて、ゲーム装置Ｂとの間のフレンド関係が成立する。そして、ゲーム装置Ａは、ゲーム装置Ｂから登録メールを受信した旨の確認メッセージ（受信確認メッセージ）をゲーム装置Ｂに自動送信する。
【０１３２】
この時点においては、ゲーム装置Ｂでは、既にゲーム装置Ａのメールアドレスがフレンドリスト４４ｄに登録されているため、ゲーム装置Ｂは、ゲーム装置Ａから送信された受信確認メッセージを受信して、受信メッセージボックス４４ｂに保持する。このことによって、互いに登録を行ったことが確認されるので、ゲーム装置Ｂにおいて、ゲーム装置Ａとの間のフレンド関係が成立する。そして、ゲーム装置Ｂは、ゲーム装置Ａと同様の処理が行われるため、受信確認メッセージをゲーム装置Ａに自動送信する。ゲーム装置Ａは、ゲーム装置Ｂからの受信確認メッセージを受信するが、この時点で既にフレンド関係は成立しているので、これに対して返信等の処理を何らすることなく、その後、この受信確認メッセージは受信メッセージボックス４４ｂから削除される。
【０１３３】
上記のように、それぞれのゲーム装置１２において、アドレス登録後に登録メッセージを自動送信し、登録後にメッセージを受け取った場合にフレンド関係を確立し、受信確認メッセージを送信するという処理を行うという同様の処理をそれぞれ行うことによって、登録後のフレンド関係確立が自動的に行われる。
【０１３４】
次に図１２を参照して、ゲーム装置１２と他の端末との間でフレンド関係を確立させる手順を説明する。他の端末は電子メールの処理が可能な汎用的な端末であって、ゲーム機１２の入出力プロセッサ４２ａ等の構成を備えているものではないので、ゲーム装置１２と他の端末との場合には、ゲーム装置１２側からしか登録を開始できないこととする。ゲーム装置Ｃのユーザが、ゲーム装置Ｃのフレンドリスト４４ｄに端末Ｄのメールアドレスを登録すると、ゲーム装置Ｃは登録メッセージを端末Ｄに送信する。ただし、端末Ｄは、ゲーム装置１２ではなく、ゲーム装置Ｃにメッセージを送信するためには、端末Ｄのユーザがゲーム装置Ｃにメッセージを返信する必要がある。したがって、登録メッセージは、端末Ｄのユーザ（人間）が解読可能な形式で返信を促すメッセージを送信する必要がある。たとえば、「このメールに返信すれば、ゲーム装置Ｃとの間で電子メールの送受信が可能になります。」のような本文を含む登録メッセージが送信される。この時点では、ゲーム装置Ｃにおいて、端末Ｄとの間のフレンド関係は成立していない。
【０１３５】
その後、端末Ｄのユーザが、ゲーム装置Ｃからの登録メッセージに対するメッセージを当該ゲーム装置Ｃに返信する。ゲーム装置Ｃでは、既に端末Ｄのメールアドレスがフレンドリスト４４ｄに登録されているため、端末Ｄからのメッセージを受信したときに、端末Ｄとの間のフレンド関係が成立する。
【０１３６】
なお、端末Ｄにおいては、フレンド関係の確立を確認することができないので、ゲーム装置Ｃからフレンド関係確立とともに受信確認メッセージを送信する必要はない。
【０１３７】
また、上述したように、この実施例では、２台のゲーム装置１２のうち、一方のゲーム装置１２に他方のゲーム装置１２のメールアドレスが登録されただけの状態である場合には、フレンド関係は成立していない。かかる場合には、図示は省略するが、一方のゲーム装置１２に登録されたアドレスは薄い灰色で表示し、その後、フレンド関係が成立したときに、黒色で表示するようにして、フレンド関係の確立の有無をユーザが認識できるようにしてもよい。ただし、これは単なる一例であり、同じ色で輝度の違いにより表示を変えたり、異なる色で表示を変えたりすることもできる。また、ゲーム装置１２では、フレンドリスト４４ｄに登録してあるゲーム装置１２や他の端末とのフレンド関係の成立の有無を当該フレンドリスト４４ｄにおいて、たとえばフラグ等によって判別する。たとえば、フレンド関係の成立したゲーム装置１２の識別情報（またはメールアドレス）や他の端末のメールアドレスに対応するフラグがオンされる。一方、フレンド関係の成立していないゲーム装置１２の識別情報（またはメールアドレス）や他の端末のメールアドレスに対応するフラグがオフされる。当該フラグを参照することによって、登録メッセージ以外の通常のメッセージの作成を可能とするか禁止するか、そして受信したメッセージを削除するか受信メッセージボックス４４ｂに保存するかを決定することができる。ただし、フラグ以外の手段であっても、たとえば、フレンド関係確立前のアドレスと確立後のアドレスとを別の領域に記憶するようにして識別するようにしてもよい。
【０１３８】
次に、入出力プロセッサ４２ａによって実行されるダウンロード処理の概要について説明する。この実施例では、ダウンロードデータは、配信サーバ１０４から取得される。図１３（Ａ）に示すように、或るタスクがタスクリスト４４ｅに登録されると、その時刻ｔ１を基準に当該タスクがスケジューリングされる。たとえば、図１３（Ａ）に示す例では、タスクの実行間隔Ｔ１に従って時刻（予定時刻）ｔ２に当該タスクがスケジューリングされる。なお、この実行間隔Ｔ１が、当該タスクの属性情報のタスク起動間隔に相当する。時刻は、ＲＯＭ／ＲＴＣ４８から得ることができる。タスクが実行されると、当該実行時刻に実行間隔Ｔ１を加えた予定時刻に、次回タスクが実行される。ダウンロードのタスクは、ダウンロード実行とともに残りダウンロード回数が１減算され、このとき、次回タスクを実行する予定時刻（実行予定時刻）がスケジューリングされる。
【０１３９】
図１３（Ｂ）に示すように、入出力プロセッサ４２ａの内部では、処理の単位時間となる所定時間毎にトリガが発生し、当該トリガ発生時に、トリガ発生時刻と、前述のメッセージの送受信を行う予定時刻や、ダウンロードを行う予定時刻等とを比較する処理が行われ、予定時刻を超過している場合に当該処理が起動することになる。したがって、トリガの発生時よりも後にタスクがスケジューリングされている場合には、当該タスクは次回のトリガの発生時に実行されるため、タスクの実際の実行時刻は、図１３（Ａ）でスケジューリングした予定時刻ｔ２から若干遅れてしまうことがある。
【０１４０】
また、図１３（Ｃ）に示すように、スタンバイモードではなく、ゲーム装置１２の電源が完全にオフされた場合のように、タスクの実行自体が停止される場合も有り得る。かかる場合には、再びゲーム機１２が起動した後にタスクが実行されることになるが、タスクの実行時刻にかなりの遅れが生じてしまうことがある。
【０１４１】
なお、タスクの実行は、アプリケーションからの要求によって、一時的に停止させたり、再開させたりすることが可能であって、そのような場合にもタスクの実行時刻に遅れが生じる可能性がある。
【０１４２】
このように、タスクの実行時刻の遅延が発生した場合、ダウンロードするデータが既に不要なものになっている場合があるので、遅延が発生した場合に、当該タスクの実行を許容するか否かを決定するために、タスクの属性情報として、リトライマージンが設定されている。具体的には、タスクを実行するとき、タスクの実行を開始する時点（現在時刻）が、タスクの実行予定時刻にリトライマージンが示す時間を加算したリトライ許容時刻を越えているかどうかを判断する。そして、現在時刻がリトライ許容時刻を越えている場合には、タスクの実行は行わずに、当該タスクはタスクリスト４４ｅから削除される。一方、現在時刻がリトライ許容時刻に満たない場合には、当該タスクを実行し、以降の処理を続行する。
【０１４３】
以下、ＣＰＵ４０および入出力プロセッサ４２ａのそれぞれで実行されるソフトウェアの処理を具体的に説明する。図１４は、図２に示したＣＰＵ４０で実行されるゲームアプリケーション処理を示すフロー図である。ただし、本実施例ではゲームアプリケーションを例として説明するが、ゲーム以外のアプリケーションであっても適用可能であることはいうまでもない。図１４を参照して、ＣＰＵ４０がゲームアプリケーション処理を開始すると、ステップＳ１で、ゲーム終了かどうかを判断する。ここでは、ゲームオーバになったり、プレイヤの指示に従ってゲームを終了したりしたかどうかを判断する。ステップＳ１で“ＹＥＳ”であれば、つまりゲーム終了であれば、そのままゲームアプリケーション処理を終了する。一方、ステップＳ１で“ＮＯ”であれば、つまりゲーム終了でなければ、ステップＳ２でゲーム処理を実行する。ここでは、ＣＰＵ４０は、プレイヤの操作に従ってプレイヤキャラクタに任意のアクションを実行させたり、ノンプレイヤキャラクタの移動等を制御したりする。このとき、ＣＰＵ４０の指示の下、ＧＰＵ４２ｂは、ゲーム画像データを生成（更新）する。また、必要に応じて、ＣＰＵ４０の指示の下、ＤＳＰ４２ｃは、音データを生成する。これにより、ゲームが進行される。
【０１４４】
以降、ゲーム処理実行中において、送信データの作成や、受信データの取得、ダウンロードデータの取得の指示が発生する場合について説明する。ここでは、ＣＰＵ４０は、プレイヤの操作やゲームイベントの発生により、それらの指示が入力されたかどうかを判断する。
【０１４５】
なお、アプリケーションの種類によっては、送信データ、受信データ、ダウンロードデータのうちいずれかのデータしか用いないアプリケーションもあり得るため、すべての指示の判断処理が必ずしも実行されるものではない。
【０１４６】
まず、ステップＳ３で送信データの作成指示があったかどうかを判断し、“ＹＥＳ”であれば、つまり送信データの作成指示があれば、図２７に示すステップＳ４の送信データ作成処理に進む。一方、ステップＳ３で“ＮＯ”であれば、つまり送信データの作成指示がなければ、ステップＳ５に進む。
【０１４７】
次に、ステップＳ５において、受信データの取得指示があったかどうかを判断し、“ＹＥＳ”であれば、つまり受信データの取得指示があれば、図２８に示すステップＳ６の受信データ取得処理に進む。一方、ステップＳ５で“ＮＯ”であれば、つまり受信データの取得指示がなければ、ステップＳ７に進む。
【０１４８】
次に、ステップＳ７において、ダウンロードデータの取得指示があったかどうかを判断し、“ＹＥＳ”であれば、つまりダウンロードデータの取得指示があれば、図１５に示すステップＳ８のダウンロードデータ取得処理に進む。一方、ステップＳ７で“ＮＯ”であれば、つまりダウンロードデータの取得指示がなければ、ステップＳ１に戻る。以上の処理によって、ゲーム処理を実行しながら必要に応じて受信データ、送信データ、ダウンロードデータの利用を行うことができる。なお、図示は省略するが、ユーザの指示やイベントに応じて、ダウンロードのタスクを所定の条件で生成し、タスクリスト４４ｅに格納する処理が含まれていてもよい。
【０１４９】
次に、上述のステップＳ４の送信データ作成処理、ステップＳ６の受信データ取得処理、ステップＳ８のダウンロードデータ取得処理のそれぞれについて、処理の詳細を説明する。
【０１５０】
まず、ステップＳ４の送信データ作成処理について、図２７を参照して説明する。まず、ステップＳ９においてメッセージ内容が作成される。メッセージ内容は電子メールの本文に相当するものであって、ソフトウェアキーボードを表示させるなどしてユーザから入力された内容や、ゲーム処理において生成されたデータに基づいて自動的に生成された内容等である。次に、ステップＳ１０において、前記内容の本文を含む電子メール形式のメッセージが生成される。ここでは、宛先の指定等が行われ、図９のヘッダ情報がメッセージに付与される。
【０１５１】
次に、ステップＳ１１において、宛先がゲーム機１２自身のものであるかどうかを判断する。ゲーム機１２自身の宛先は、上述のように管理用ファイル４４ｃに記憶されているので、当該宛先を読み出して、メッセージの宛先と比較される。ステップＳ１１で“ＹＥＳ”の場合は、ステップＳ１２において作成した電子メールを受信メッセージボックスに記憶する。これは、たとえば伝言板機能等を用いてユーザが閲覧する、メモや伝言、ゲームの結果等が作成された場合であって、受信メッセージボックスに記憶しておくことによって、閲覧用に別の処理を行わなくとも、他の受信データとどうように閲覧することができる。
【０１５２】
ステップ１１で“ＮＯ”の場合は、ステップＳ１３において、作成した電子メールを送信メッセージボックスに記憶する。当該メッセージは、入出力プロセッサ４２ａにおいて、ＣＰＵ４０とは独立した処理において適宜のタイミングでネットワークに送信されるので、ゲームプログラムにおいては、データを作成して記憶する処理が含まれていればよく、複雑な送受信用プログラムを用意する必要がない。
【０１５３】
次に、ステップＳ６の受信データ取得処理について、図２８を参照して説明する。まず、ステップＳ１４で、受信メッセージボックス４４ｂを確認する。続いて、ステップＳ１５では、当該アプリケーション宛のアプリＩＤを有する受信データまたは閲覧可能な受信データがあるかどうかを判断する。つまり、ＣＰＵ４０は、受信メッセージボックス４４ｂに格納されているそれぞれの受信データのヘッダ情報を参照して、アプリＩＤが当該アプリケーションを示すアプリＩＤと一致するかどうかを判断する。そして、ＣＰＵ４０は、アプリＩＤが当該アプリケーションを識別する情報である場合に、当該受信データを取得する。また、ＣＰＵ４０は、アプリＩＤが当該アプリケーションのアプリＩＤと一致しない場合であっても、他アプリ制限がオフであれば、必要に応じて当該受信データを取得することが可能である。なお、ＣＰＵ４０は、これら以外の受信データを取得しない。
【０１５４】
ステップＳ１５で“ＮＯ”であれば、つまり当該アプリケーション宛のアプリＩＤの受信データまたは閲覧可能な受信データが存在しなければ、そのまま受信データ取得処理を終了してリターンする。一方、ステップＳ１５で“ＹＥＳ”であれば、つまり当該アプリケーション宛のアプリＩＤの受信データまたは閲覧可能な受信データが存在すれば、ステップＳ１６で、当該受信データを受信メッセージボックス４４ｂから読み出す。次のステップＳ１７で、取得した受信データをゲームデータとしてメインメモリ（４２ｅ，４６）に記憶する。したがって、受信データがその後のゲーム処理に利用される。たとえば、その後のゲーム処理によって、当該受信データをセーブ領域４４ｆに格納しておくようにしてもよいし、ゲーム処理に利用した後はメインメモリから破棄するようにしてもよい。
【０１５５】
そして、ステップＳ１８では、取得した受信データが当該アプリケーション宛の受信データであるかどうかを判断する。ステップＳ１７で“ＮＯ”であれば、つまり当該アプリケーション宛の受信データでなければ、そのまま受信データ取得処理を終了してリターンする。つまり、他のアプリケーション宛の受信データは本来他のアプリケーションによって利用されるものであるため削除を禁止する。一方、ステップＳ１８で“ＹＥＳ”であれば、つまり当該アプリケーション宛の受信データであれば、データ取得後は、通常はメッセージボックス４４ｂに残しておく必要がないのでステップＳ１９で、当該受信データを受信メッセージボックス４４ｂから削除して、リターンする。ただし、ＣＰＵ４０は、当該受信データのヘッダ情報の消滅属性が「消去せず」を示す場合には、当該受信データが当該アプリケーション宛であっても、ステップＳ１９の処理を実行せずにリターンする。
【０１５６】
次に図１５を参照して、ステップＳ８のダウンロードデータ取得処理について説明する。まず、ステップＳ２３で、ダウンロードボックス４４０を確認する。そして、ステップＳ２５で、当該アプリケーションのダウンロードデータがあるかどうかを判断する。つまり、ＣＰＵ４０は、当該アプリケーションのアプリＩＤが付されたダウンロードデータがダウンロードボックス４４０に記憶されているかどうかを判断する。
【０１５７】
ステップＳ２５で“ＮＯ”であれば、つまり当該アプリケーションのダウンロードデータがなければ、そのままリターンする。一方、ステップＳ２５で“ＹＥＳ”であれば、つまり当該アプリケーションのダウンロードデータがあれば、ステップＳ２７で、当該ダウンロードデータをダウンロードボックス４４０から読み出し、ステップＳ２９で、取得したダウンロードデータをゲームデータとしてメインメモリ（４２ｅ，４６）に記憶して、リターンする。したがって、ダウンロードデータがその後のゲーム処理に利用される。
【０１５８】
なお、ＣＰＵ４０は、内部メインメモリ４２ｅおよび外部メインメモリ４６のいずれにも高速にアクセス可能であるため、受信データやダウンロードデータはいずれのメモリに記憶するようにしてもよい。たとえば、ゲームアプリケーション（ゲームプログラム）やゲームデータによって利用されているメモリと同じ方のメモリに、受信データやダウンロードデータを記憶してもよい。
【０１５９】
また、この実施例では、ＣＰＵ４０がゲームアプリケーション処理を実行する場合について説明したが、アプリケーションの種類はこれに限定される必要はなく、たとえば画像閲覧ソフトのような他の種類のアプリケーションであっても同様の処理を実行することができる。
【０１６０】
たとえば、前述の伝言板機能もアプリケーションであるので、同様の処理が行われるが、伝言板機能は主としてメッセージの作成と閲覧のためのアプリケーションであるので、ステップＳ７およびＳ８の処理は行われない。以下、図１６ないし図１８を参照して、伝言板機能について、上述の一般的な（ゲーム）アプリケーションよりも詳細に具体的な処理を説明する。なお、ここでいう伝言板機能には、伝言板の表示に係る処理だけでなく、ゲーム装置１２の電源がオンされたときやゲーム装置１２の電源がオンである場合に自動的に実行される、受信データの処理をも含むものとして説明する。
【０１６１】
図１６を参照して、ＣＰＵ４０は、ゲーム装置１２の電源がオンのとき、たとえばメニュー画面を表示しているとき等に、定期的にステップＳ４１で、受信メッセージボックス４４ｂにメッセージ（受信データ）があるかどうかを判断する。ステップＳ４１で“ＮＯ”であれば、つまり受信メッセージボックス４４ｂにメッセージがなければ、そのままステップＳ４５に進む。一方、ステップＳ４１で“ＹＥＳ”であれば、つまり受信メッセージボックス４４ｂにメッセージがあれば、ステップＳ４３で、当該メッセージをそのヘッダ情報に従って日付毎にデータベース４４ｇに記憶して、ステップＳ４５に進む。つまり、伝言板において日付ごとにメッセージを表示するために、受信メッセージボックス４４ｂ内の受信データをデータベース４４ｇに移動させておく。日付毎にデータベース４４ｇに記憶する方法としては、例えば日付毎にフォルダを生成し、メッセージの日付に対応するフォルダに当該メッセージを格納するようにしてもよい。また、メッセージのファイル名を時刻を表す名称にしてもよい。
【０１６２】
ステップＳ４５では、伝言板の表示指示があるかどうかを判断する。ステップＳ４５で“ＹＥＳ”であれば、つまり伝言板の表示指示があれば、図１８に示すステップＳ４６の伝言板表示処理に進む。一方、ステップＳ４５で“ＮＯ”であれば、ステップＳ４１に戻る。つまり、伝言板機能全体としては、伝言板の表示を行っていないときであっても受信データをデータベース４４ｇに移動させていることになる。また、伝言板の表示中であっても、当該受信データの移動は行っていてもよく、そのようにすれば、メッセージを閲覧しながらリアルタイムに新しく受信したメッセージを確認することができる。
【０１６３】
次に、図１８を参照して、ステップＳ４６の伝言板表示処理について説明する。まず、ステップＳ６０で、日付の指定がされたかを判断する。伝言板は、図２５で示すように、メッセージを日付毎に一覧表示するものであって、日付の指定を変更すれば、当該日付におけるメッセージを閲覧することができる。なお、デフォルトの指定日としては、伝言板の表示が行われた日、つまり「今日」が指定されているものとして、伝言板表示が終了するまでは随時変更が可能となっている。なお、今日の日付（年月日）は、ＲＯＭ／ＲＴＣ４８にアクセスして取得することができる。
【０１６４】
ステップＳ６０で“ＹＥＳ”の場合、つまり指定日付の変更があった場合は、指定された日付に変更を行う。“ＮＯ”の場合は、同じ日付のまま、後述の表示に係る処理を続行する。
【０１６５】
ステップＳ６２において、背景や他のオブジェクトの配置等が行われ、メッセージ以外の表示に係る処理が行われる。ステップＳ６３において、データベース４４ｇ内に指定された日付のメッセージが存在するか否か判定される。具体的には、たとえば前述の日付毎のフォルダにメッセージを格納する実施例においては、当該日付に対応するフォルダ内にファイルが存在するか否か判定される。ステップＳ６３で“ＮＯ”の場合、表示すべきメッセージが存在しないので、そのままメッセージ以外の背景等が表示されるだけで、リターンされる。
【０１６６】
ステップＳ６３で“ＹＥＳ”の場合、ステップＳ６４において、ＣＰＵ４０はデータベース４４ｇから当該日付のメッセージを読み出す。たとえば、前述の実施例の場合、当該日付に対応するフォルダ内のファイルを全て読み出すようにする。そして、ステップＳ６５において、読み出されたメッセージの表示に係る処理が行われ、図２５に示すようなメッセージの一覧が表示されることになる。
【０１６７】
図１６の説明に戻って、ステップＳ４７において、伝言板の表示を終了するか否かが判定される。たとえば、ユーザからの指示があった場合には、伝言板の表示が終了されることになる。したがって、ステップＳ４７で“ＹＥＳ”の場合、ステップＳ４１に戻る。
【０１６８】
ステップＳ４７で“ＮＯ”の場合、伝言板の表示は続行されるが、次に、ステップＳ４８において、メッセージの入力の指示があったか判定される。伝言板には、たとえば図２５に示すように、メッセージ作成ボタンが表示され、ユーザの指示によって、メッセージの作成が可能である。たとえばそのメッセージ作成ボタンがユーザに操作される等の条件によって、ステップＳ４８が“ＹＥＳ”の場合には、図１７で示すステップＳ４９のメッセージ入力処理が行われる。“ＮＯ”の場合には、ステップＳ４６に戻り、伝言板の表示が続行される。
【０１６９】
図１７のメッセージ入力処理は、図２７で示される送信データ作成処理とほぼ同様の処理であって、メッセージの作成手段がユーザからの入力のものである。すなわち、ステップＳ５０において、ユーザからのメッセージの入力を受け付ける。この場合は、たとえばソフトウェアキーボードを表示するなどして、入力の受付を行う。なお、図示は省略するが、ユーザが宛先やメッセージの入力の中止を指示した場合には、宛先やメッセージの入力を中止して、つまりメッセージ作成を止めて、図１６に示すステップＳ４７に戻る。次に、ステップＳ５１において、メッセージの入力が終了したか否か判定される。ステップＳ５１で“ＮＯ”であれば、つまりメッセージの入力を終了していなければ、メッセージの入力中であるので、ステップＳ５０に戻る。一方、ステップＳ５１で“ＹＥＳ”であれば、つまりメッセージの入力を終了すれば、図１７に示すステップＳ５３で、入力されたメッセージについての電子メールを作成する。
【０１７０】
以降、ステップＳ５３−Ｓ５９における処理については、図２７のステップＳ１０−Ｓ１３の処理と同様であるので説明を省略する。メッセージ入力処理終了後は、ステップＳ４６の伝言板表示処理に戻り、再び終了までメッセージ一覧の表示が行われる。
【０１７１】
次に、図１９ないし図２１を参照して、図２に示した入出力プロセッサ４２ａがメッセージの送受信を行うメッセージ送受信処理を説明する。以下の処理は、ＣＰＵ４０とは独立に行われ、上述のスタンバイモードの間であっても、入出力プロセッサ４２ａには電力が供給されるので実行される。したがって、ユーザがゲーム装置１２を起動していない間であっても、スタンバイモードの元でゲーム装置１２は自動的に通信処理を行っているので、ユーザがゲーム装置１２を起動すると、新しいメッセージが既に届いている状態となっていて、すぐにメッセージを閲覧することができる。上述したように、入出力プロセッサ４２ａは、所定の単位時間毎に発生するトリガに応じて処理を実行する。まず、トリガが発生すると、ステップＳ８１で、送受信予定時刻であるかどうかを判断する。ここでは、入出力プロセッサ４２ａは、ＲＯＭ／ＲＴＣ４８に設けられる時計回路から時間を取得して、予め設定しておいた送受信予定時刻になったかどうかを比較判断する。
【０１７２】
ステップＳ８１で“ＮＯ”であれば、つまり送受信予定時刻でなければ、そのまま同じステップＳ８１に戻って、次のトリガが発生するまで待機する。言い換えれば、送受信予定時刻を超過するまでステップＳ８１の処理がトリガ発生毎に繰り返される。一方、ステップＳ８１で“ＹＥＳ”であれば、つまり送受信予定時刻であれば、ステップＳ８３で、メールサーバ１０２に接続する。続くステップＳ８５で、新着メール（新着メッセージ）すなわち受信データがサーバにあるかをチェックし、同時にステップＳ８７で、次回アクセス期間をメールサーバ１０２から取得する。ただし、通常、ゲーム装置１２（入出力プロセッサ４２ａ）は、所定時間（たとえば、１０分）毎にメールサーバ１０２にアクセスするよう設定されており、当該所定時間を毎回サーバから取得する。次回アクセス期間の変更は、たとえば、メンテナンスや、負荷の増大での対応などの理由により、アクセス期間をずらす場合等に行われる。
【０１７３】
続いて、ステップＳ８９では、受信データまたは送信データがあるかどうかを判断する。ここでは、入出力プロセッサ４２ａは、ステップＳ８５の新着チェックの結果から、これから受信すべき受信データの有無を判断し、また、送信メッセージボックス４４ａにアクセスして送信が必要な送信データの有無を判断する。ステップＳ８９で“ＮＯ”であれば、つまり受信データおよび送信データが無ければ、送受信処理は不要であるので、そのままステップＳ８１に戻る。ステップＳ８１によって、送受信が不要な場合には新着チェックのみで送受信を行わないことになるので、ネットワークの負荷を軽減することができる。一方、ステップＳ８９で“ＹＥＳ”であれば、つまり受信データまたは送信データ或いはそれらの両方が有れば、サーバと送受信を行う必要があるので、ステップＳ９１で、メールサーバ１０２との間でデータを送受信する。ここでは、入出力プロセッサ４２ａは、送信メッセージボックス４４ａに記憶された送信データをネットワーク１０６に送信する送信処理を実行するとともに、ネットワーク１０６を介してメールサーバ１０２から受
信データを受信する受信処理を実行する。
【０１７４】
続くステップＳ９３では、ステップＳ９１において送信したすべての送信データを、送信メッセージボックス４４ａから削除する。ただし、入出力プロセッサ４２ａは、送信データが送信メッセージボックス４４ａに格納されておらず、ステップＳ９１において送信データの送信処理を実行していない場合には、ステップＳ９３の削除処理では何も行われず、そのままステップＳ９５に進む。ステップＳ９５では、ステップＳ９１において受信したすべての受信データを、バッファに記憶（一時記憶）する。図示は省略するが、内部メインメモリ４２ｅまたは外部メインメモリ４６にバッファ領域が設けられる。バッファに記憶された受信データはステップＳ９４で受信メールボックス４４ｂに記憶されるが、この際にステップＳ９６のフィルタリング処理や、ステップＳ９７の上書き確認処理等の処理が行われる。
【０１７５】
なお、新着チェックの結果、受信データが無い場合、つまり送信のみの場合には、ステップＳ９５以降の処理では何も行われず、そのままステップＳ８１に戻ることになる。
【０１７６】
次に、図２１を参照して、ステップＳ９６のフィルタリング処理について説明する。まず、ステップＳ１１１で、受信メッセージボックス４４ｂに記憶されているすべての受信データのヘッダ情報およびフレンドリスト４４ｄを参照して、それぞれの送信元との間でフレンド関係が成立しているかどうかを判断する。たとえば、入出力プロセッサ４２ａは、フレンドリスト４４ｄを参照して、ヘッダ情報に記述されている送信元の情報（識別情報またはメールアドレス）がフレンド関係の確立しているものかどうか（たとえばフラグがオンされているかどうか）判断する。ステップＳ１１１で“ＹＥＳ”であれば、すべての受信データがフレンド関係の成立した送信元から送信されている場合には、そのまま以降の処理で受信メッセージボックス４４ｂに登録するためにリターンする。
【０１７７】
一方、ステップＳ１１１で“ＮＯ”であれば、つまり受信データがフレンド関係の成立していない送信元から送信されている場合には、ステップＳ１１３で、当該送信元がアドレス帳すなわちフレンドリスト４４ｄに登録されているかどうかを判断する。つまり、フレンド関係の確立前であって、相手を登録しているだけの状態であるかどうかを判断する。ただし、ステップＳ１１３〜ステップＳ１２９の処理については、フレンド関係の成立していない送信元からの受信データのそれぞれについて実行される。
【０１７８】
ステップＳ１１３で“ＮＯ”であれば、つまり当該送信元がアドレス帳に登録されていなければ、ステップＳ１１５で、当該新着メール（当該受信データ）をバッファから削除して、受信メールボックス４４ｂへの登録が行われないようにしてリターンする。つまり、送信元が不明なメッセージはフィルタリングされる。一方、ステップＳ１１３で“ＹＥＳ”であれば、つまり当該送信元がアドレス帳に登録されていれば、ステップＳ１１７で、当該送信元が他の端末かどうかを判断する。ここでは、入出力プロセッサ４２ａは、送信元の情報としてゲーム装置１２の識別情報を含んでいないメールアドレスであるかどうかを判断する。
【０１７９】
ステップＳ１１７で“ＹＥＳ”であれば、つまり当該受信データの送信元が他の端末である場合には、図１２で示すような当該ゲーム装置１２が送信した登録メッセージに対する返信であると判断し、ステップＳ１１９で、当該他の端末とのフレンド関係を確立させて、（たとえば当該他の端末に対応するフラグをオンして）ステップＳ８１に戻る。一方、ステップＳ１１７で“ＮＯ”であれば、つまり当該受信データの送信元が他のゲーム装置１２である場合には、ステップＳ１２１で、当該受信データが図１１で示すような受信確認メッセージであるかどうかを判断する。なお、当該受信確認メッセージは、上述したように、ゲーム装置１２間でやり取りし、各ゲーム装置１２でその内容を識別可能なメッセージ（文字列）である。
【０１８０】
ステップＳ１２１で“ＹＥＳ”であれば、つまり当該受信データが受信確認メッセージであれば、当該ゲーム装置１２が送信した登録メッセージに対する受信確認メッセージであると判断し、当該受信データの送信元とのフレンド関係を成立させるべく、そのままステップＳ１２５に進む。一方、ステップＳ１２１で“ＮＯ”であれば、つまり当該受信データが受信確認メッセージでなければ、ステップＳ１２３で、当該受信データが登録メッセージであるかどうかを判断する。ステップＳ１２３で“ＮＯ”であれば、つまり当該受信データが登録メッセージでなければ、そのままステップＳ１１５に進む。一方、ステップＳ１２３で“ＹＥＳ”であれば、つまり当該受信データが登録メッセージであれば、当該受信データの送信元とのフレンド関係を成立させるべく、ステップＳ１２５に進む。
【０１８１】
ステップＳ１２５では、入出力プロセッサ４２ａは、当該受信データの送信元のゲーム装置１２とのフレンド関係を成立させる。（たとえば、フレンドリスト４４ｄにおいて当該送信元に対応するフレンド関係のフラグをオンする。）続いて、ステップＳ１２７で、当該送信元を宛先とする受信確認メッセージを作成し、ステップＳ１２９で、作成した受信確認メッセージを送信メッセージボックス４４ａに記憶して、リターンする。当該受信確認メッセージは、次にメッセージ送受信が起動する際に送信されることになる。
【０１８２】
続いて、図２０を参照して、ステップＳ９７の上書き確認処理について説明する。ステップＳ９８では、１つ目の受信データの上書きタグを参照する。なお、詳細な説明は省略するが、ここでの受信データの順番は、受信した順番やバッファ内での記憶位置に従う順番であり、単に受信データを区別するためのものである。以下、同様である。次のステップＳ９９では、当該受信データを上書きするかどうかを判断する。ここでは、入出力プロセッサ４２ａは、当該受信データのヘッダ情報に含まれる上書きタグが「ＯＮ」を示すかどうかを判断する。
【０１８３】
ステップＳ９９で“ＮＯ”であれば、つまり上書きしない場合には、そのままステップＳ１０４に進む。一方、ステップＳ９９で“ＹＥＳ”であれば、つまり上書き「ＯＮ」の場合には、ステップＳ１０１で、送信元、アプリＩＤおよび上書きＩＤのすべてが一致する受信データが受信メッセージボックス４４ｂに記憶されているかどうかを判断する。ステップＳ１０１で“ＹＥＳ”であれば、つまり送信元、アプリＩＤおよび上書きＩＤのすべてが一致する受信データが受信メッセージボックス４４ｂに記憶されている場合には、当該メッセージは上書きすべきメッセージであるので、ステップＳ１０３で、送信元、アプリＩＤおよび上書きＩＤのすべてが一致する受信データに、当該受信データを上書きするように、当該受信データを受信メッセージボックス４４ｂに記憶して、図２１に示すステップＳ１１１に進む。なお、この説明では、受信データの受信メッセージボックス４４ｂへの記憶は、ステップＳ９４で行われるものとしているので、ステップＳ１０３においては、上書きをするという設定を一時的に保持したまま次のステップに進んでもよいし、ステップＳ１０３で先に上書きを行って、バッファから削除するようにしてもよく、上記条件を満たすものが上書きされればよい。一方、ステップＳ１０１で“ＮＯ”であれば、つまり送信元、アプリＩＤおよび上書きＩＤのすべてが一致する受信データが受信メッセージボックス４４ｂに記憶されていない場合には、上書きされるべきメッセージが存在しないので、そのままステップＳ１０４に進む。
【０１８４】
ステップＳ１０４では、全ての受信データを参照して上記処理を行ったか判定される。ステップＳ１０４で“ＹＥＳ”であれば、つまりすべての受信データについて処理が済んでいれば、リターンする。一方、ステップＳ１０４で“ＮＯ”であれば、つまりすべての受信データへの処理が済んでいなければ、ステップＳ１０５で、次の受信データの上書きタグを参照して、ステップＳ９９に戻る。
【０１８５】
次に、図２２を参照して、入出力プロセッサ４２ａのダウンロード処理について説明する。ダウンロード処理は、入出力プロセッサ４２ａがＣＰＵ４０と独立に実行するものであって、上述のスタンバイモード時であっても実行される。また、ＣＰＵ４０がアプリケーションを実行しているバックグラウンドにおいても独立に実行されている。なお、このダウンロード処理は、タスクが登録されている状態で、上述のように、入出力プロセッサ４２ａ内でトリガが発生するごとに実行され続ける。ただし、ダウンロード処理は、それぞれのタスクで実行される。この図２２に示すように、入出力プロセッサ４２ａはステップＳ１５１で、タスクを実行するためのトリガ（タスク実行トリガ）の発生を検出する。ステップＳ１５１で“ＮＯ”であれば、つまりタスク実行トリガが無ければ、そのままステップＳ１５１に戻る。一方、ステップＳ１５１で“ＹＥＳ”であれば、つまりタスク実行トリガが有れば、ステップＳ１５３で、当該タスクの実行予定時刻であるかどうかを判断する。厳密に言うと、ここでは、入出力プロセッサ４２ａは、実行予定時刻であるかどうか、または、実行予定時刻を経過しているかどうかを判断する。
【０１８６】
ステップＳ１５３で“ＮＯ”であれば、つまり当該タスクの実行予定時刻でなければ、そのままステップＳ１５１に戻る。一方、ステップＳ１５３で“ＹＥＳ”であれば、つまり当該タスクの実行予定時刻であれば、ステップＳ１５５で、リトライ許容時刻を経過しているかどうかを判断する。ステップＳ１５５で“ＹＥＳ”であれば、つまりリトライ許容時刻を経過していれば、ステップＳ１５７で、当該タスクをタスクリスト４４ｅから消去して、ダウンロード処理を終了する。ただし、ダウンロード処理はタスク毎に実行されるので、当該タスクに関するダウンロード処理が終了するという意味であって、他のタスクについてはそれ以降もトリガ発生とともにダウンロード処理が起動することになる。
【０１８７】
一方、ステップＳ１５５で“ＮＯ”であれば、つまりリトライ許容時刻を経過していなければ、ステップＳ１５９で、配信サーバ１０４に接続要求を送信する。つまり、入出力プロセッサ４２ａは、当該タスクの属性が示すコンテンツ（ダウンロードデータ）の取得元のＵＲＬにアクセス要求を送信するのである。続いて、ステップＳ１６１で、当該タスクの残りダウンロード回数を１減算する。ここで、図示は省略するが、入出力プロセッサ４２ａは、残りダウンロード回数が０になった時点で、当該タスクをタスクリスト４４ｅから消去し、次回のダウンロードが行われないようにする。ステップＳ１６３では、次回のタスク実行予定時刻をスケジューリングする。
【０１８８】
そして、ステップＳ１６５では、配信サーバ１０４との接続に成功したかどうかを判断する。ステップＳ１６５で“ＮＯ”であれば、つまり配信サーバ１０４との接続に失敗すれば、そのままステップＳ１５１に戻る。なお、この実施例では、入出力プロセッサ４２ａは、配信サーバ１０４との接続に失敗すると、直にステップＳ１５１に戻るようにしてあるが、所定回数（たとえば、３回のリトライ）接続要求を送信しても、接続に成功しない場合に、ステップＳ１５１に戻るようにしてもよい。また、ネットワークやサーバにエラーが発生している場合には、リトライを行わないようにしてもよい。また、そのようなエラーの場合には、上述の残りダウンロード回数の減算を行うとダウンロードが行われないまま終了してしまう可能性があるので、ステップＳ１６１をステップＳ１６５の後に実行するようにして、残り回数の減算を行わないようにしてもよい。
【０１８９】
ステップＳ１６５で“ＹＥＳ”であれば、つまり配信サーバ１０４との接続に成功すれば、ステップＳ１６７で、ダウンロードを実行する。つまり、入出力プロセッサ４２ａは、ダウンロードデータを取得する。そして、ステップＳ１６９で、ダウンロードデータがメッセージ配信用のデータであるかどうかを判断する。たとえば、メッセージ配信用のデータを電子メール形式のデータとし、入出力プロセッサ４２ａは、取得したダウンロードデータが電子メールの形式であるかどうかを判断する。または、メッセージ配信用のデータであることを示す情報をダウンロードデータに含め、ダウンロード実行後にゲーム装置１２において電子メール形式のデータに変換するようにしてもよい。
【０１９０】
ステップＳ１６９で“ＹＥＳ”であれば、つまりダウンロードデータがメッセージ配信用のデータである場合には、ステップＳ１７１で、当該ダウンロードデータを受信データとして受信メッセージボックス４４ｂに格納して、ステップＳ１５１に戻る。一方、ステップＳ１６９で“ＮＯ”であれば、つまりダウンロードデータがメッセージ配信用のデータでない場合には、ステップＳ１７３で、当該ダウンロードデータをダウンロードボックス４４０に格納して、ステップＳ１５１に戻る。
【０１９１】
上述したようなメッセージ送受信処理およびダウンロード処理は、基本的には、ＣＰＵ４０がゲームアプリーションのようなアプリケーションを実行している場合やスタインバイモードが設定されている場合であっても、入出力プロセッサ４２ａによって独立に実行される。ただし、ＣＰＵ４０（アプリケーション）から特に停止指示がある場合には、メッセージ送受信処理（自動送受信機能）は一時的に停止される。その後、ＣＰＵ４０（アプリケーション）からの再開指示により、メッセージ送受信処理は再開される。このようなメッセージ送受信処理およびダウンロード処理の停止・再開の機能（スケジューラ操作機能と呼ぶ）をそれぞれのアプリケーションプログラムに含めることができる。
【０１９２】
たとえば、パフォーマンスの厳しいアプリケーションを実行している場合に、一時的な処理速度の低下を防ぐことができる。また、無線通信モジュール５０ａを介して、上述のメッセージ送受信処理やダウンロード処理以外の通信処理（たとえばネットワークゲームのプレイ等）を同時に行っている場合に、通信速度が低下することを防ぐことができる。また、アプリケーションにおいてフラッシュメモリ４４にアクセスしているタイミングにおいて、フラッシュメモリ４４へのアクセスが集中することでアクセスの速度が一時的に低下することを防ぐことができる。
【０１９３】
したがって、このようなスケジューラ操作機能を用いることで、メッセージ送受信処理およびダウンロード処理を一時的に停止させることができる。このスケジューラ操作機能は、アプリケーションの実行中のどの段階でも呼び出し可能であるため、たとえば、フラッシュメモリ４４から大容量のデータを読み込む前に、メッセージ送受信処理およびダウンロード処理を一時停止させておき、読み込みが完了した後に、メッセージ送受信処理およびダウンロード処理を再開させることが可能である。また、たとえば、メッセージの送信処理を終えた段階でメッセージ送受信処理を一時停止させ、その後、メッセージ送受信処理を再開させて、メッセージの受信処理を実行させることも可能である。
【０１９４】
この実施例によれば、通常モードおよびスタンバイモードに拘わらずメッセージを送受信するので、通信するゲーム装置同士が同時に起動している必要がない。また、対象となるアプリケーションを識別可能なデータを本体機能によって送受信するので、アプリケーション毎に通信機能を設ける必要がなく、コストを削減することができる。また、メッセージを作成しているときに、ネットワークに接続している必要がないので、ユーザの手間や無駄な通信コストを削減することができる。したがって、コストやユーザの手間を軽減でき、汎用性の高い通信方法を提供することができる。
【０１９５】
なお、この実施例では、上書きタグの上書きＩＤが「上書きする」を示すとき、送信元の情報と、アプリＩＤと、上書きＩＤとのすべてが一致する前回のメッセージが受信メッセージボックス４４ｂに存在するとき、今回のメッセージを前回のメッセージに上書きするようにした。ただし、最新のメッセージよりも古いメッセージの方が後から受信される場合も想定される。かかる場合には、最新のメッセージに、それよりも古いメッセージが上書きされてしまうことがある。また、重要度の高いメッセージに、それよりも重要度の低いメッセージが上書きされてしまうような事態も想定される。
【０１９６】
したがって、このような不都合を回避するために、メッセージの新しさや重要度に応じた上書きの優先度を示す情報（優先度ＩＤ）をさらに付加する。たとえば、優先度ＩＤは、数字であり、数が大きい程、優先度が高く、逆に数が小さい程、優先度が低い。したがって、メッセージを受信したとき、送信元の情報、アプリＩＤ、上書きＩＤのすべてが一致し、さらに、優先度ＩＤが示す番号が大きい場合に、当該メッセージが上書きされるようにすればよい。
【０１９７】
また、他の実施例のゲーム装置１２は、メッセージの自動返信機能を有していてもよい。当該他の実施例は、メッセージの自動返信機能を有する以外は、上述の実施例と同じであるため、重複した説明は省略する。この他の実施例のゲーム装置１２では、メッセージのヘッダ情報に加えて、またはヘッダ情報に含んで、メッセージの自動返信情報が記述される。この自動返信情報は、「自動返信しない」、「自動返信する（コピー属性）」、「自動返信する（ムーブ属性）」の３種類で識別される。
【０１９８】
たとえば、メッセージを自動返信する場合には、送信可能な状態か否かの情報を含めてメッセージを識別するための識別情報（メッセージＩＤ）が付与される。このメッセージＩＤがメッセージ（送信データ）に付加されている場合には、当該送信データはメッセージ送受信処理においてもネットワーク１０６に送信されず、待機している状態である。このメッセージＩＤを削除する（取り除く）ことによって送信可能となり、次に実行されるメッセージ送受信処理において送信される。この実施例では、受信データに当該メッセージＩＤと同じメッセージＩＤが記述されている場合に、送信データに付加されたメッセージＩＤを削除する。
【０１９９】
ただし、この他の実施例では、送信データに付加されたメッセージＩＤと同じメッセージＩＤが記述（付加）された受信データを受信したとき、当該送信データのメッセージＩＤを削除するようにしてある。ただし、受信データに付加されるメッセージＩＤ（説明の都合上、「受信側メッセージＩＤ」という。）は、送信データに付加されたメッセージＩＤ（説明の都合上、「送信側メッセージＩＤ」という。）と同じである必要はない。たとえば、受信側メッセージＩＤと送信側メッセージＩＤとが一対（一組）の鍵となる関係を有し、受信側メッセージＩＤによって送信側メッセージＩＤを解くようにしてもよい。また、受信側メッセージＩＤの内容に関わらず、送信側メッセージＩＤを削除するようにして、返信要求のあるもの全てに返信するようなものであってもよい。
【０２００】
したがって、ユーザは当該送信データを自動送信したい他のユーザに対して当該送信データのメッセージＩＤと同じ（または一対（一組）の）メッセージＩＤを別途送信したり、他の手段で連絡しておいたりするのである。ただし、ユーザは、自動返信用のメッセージを作成する際に、ゲーム装置１２（入出力プロセッサ４２ａ）からの通知（画面表示）により、別途送信すべきメッセージＩＤを知ることができる。
【０２０１】
そして、メッセージＩＤを別途送信しておいた他のユーザから、メッセージＩＤ連絡のメッセージへの返信（送信要求）の受信や、別途連絡済みのメッセージＩＤを付加したメッセージの受信があると、送信データに付加されていたメッセージＩＤが削除され、当該送信データは送信可能となり、その後、当該他のユーザのゲーム装置１２や他の端末に送信される。すなわち、他のユーザに対して自動返信することができる。
【０２０２】
以下、本実施例の自動返信をゲームに利用する例を説明する。たとえば、自分だけの武器（アイテム）を作ることができ、その武器をフリーマーケットで売ることができるアプリケーションを想定する。このような場合には、オリジナルの武器を作ったユーザＡが当該武器をフリーマーケットに出す。つまり、ユーザＡ側のアプリケーションは、武器データを含むメッセージを自動返信用メッセージ（メッセージＩＤ付きのメッセージ）として、送信メッセージボックス４４ａに登録する。このとき、ユーザＡ側のアプリケーションは、武器データを含むメッセージのメッセージＩＤを知ることができる。ユーザＡ側のアプリは、武器データを含むメッセージのメッセージＩＤをユーザＢに送信する。ユーザＢ側のアプリケーションは、ユーザＢに「ユーザＡのフリーマットで武器が売り出されている」ことをメッセージで知らせる。ユーザＢがその武器を購入することを決めると、ユーザＢ側のアプリケーションはユーザＡ宛に、武器データを含むメッセージのメッセージＩＤと「ムーブ属性」を指定した自動返信機能を利用したメッセージを送信する。ユーザＢからの自動返信機能を含むメッセージを受け取ったユーザＡ側では、メッセージ送受信機能により、指定されたメッセージＩＤの付加された送信データ（メッセージ）が送信メッセージボックス４４ａにあるかどうかを検索する。そして、指定されたメッセージＩＤの付加された送信データが送信メッセージボックス４４ａにある場合には、自動返信用の属性（ここでは，メッセージＩＤ）を削除し、当該送信データは送信可能になる。その後、武器データを含む送信データがユーザＢ宛に送信される。
【０２０３】
このように、ムーブ属性が指定された場合には、送信データ（武器データ）はコピーされずに、一度返信を行うと削除されるものとする。なお、コピー属性が指定された場合には、送信データから自動返信用の属性が削除されると、当該送信データの複製が送信可能に送信メッセージボックス４４ａに保持される。自動返信が１回に限るものであるか、毎回返信するものであるかの用途の違いによって、それぞれの属性を使い分けることができる。
【０２０４】
なお、上記実施例は、自動返信機能をゲームにおける武器の売買に利用したが、利用対象は武器に限らず、アイテムやキャラクタの交換、履歴の交換等、さまざまな用途に利用することができる。
【０２０５】
自動返信のための具体的処理としては、上述の実施例で示したメッセージ送受信処理の一部が変更される。なお、変更した箇所以外は上述の実施例で示したとおりであるため、異なる点についてのみ説明する。また、詳細な説明は省略するが、上述の実施例のメッセージ入力処理において、電子メールを作成するときに、「コピー属性」や「ムーブ属性」を選択（設定）できるようにしておければよい。
【０２０６】
図１９に示したメッセージ送受信処理のステップＳ８９で“ＹＥＳ”であれば、ステップＳ９１、Ｓ９３、Ｓ９５における処理が具体的に図２３で示すような処理になる。ステップＳ２０１で、送信メッセージボックス４４ａの１つ目の送信データをチェックする。続くステップＳ２０３では、当該送信データが送信可能かどうかを判断する。具体的には、入出力プロセッサ４２ａは、当該送信データにメッセージＩＤが付加されているかどうかを判断する。
【０２０７】
ステップＳ２０３で“ＮＯ”であれば、つまり当該送信データが送信不能であれば、そのままステップＳ２０９に進む。一方、ステップＳ２０３で“ＹＥＳ”であれば、つまり当該送信データが送信可能であれば、ステップＳ２０５で、当該送信データをネットワーク１０６に送信する。そして、ステップＳ２０７で、当該送信データを送信メッセージボックス４４ａから削除し、ステップＳ２０９に進む。
【０２０８】
ステップＳ２０９では、すべての送信データの送信制御を実行したかどうかを判断する。ステップＳ２０９で“ＮＯ”であれば、つまりすべての送信データの送信制御を実行していなければ、ステップＳ２１１で、次の送信データをチェックして、ステップＳ２０３に戻る。一方、ステップＳ２０９で“ＹＥＳ”であれば、つまりすべての送信データの送信制御を実行していれば、ステップＳ２１３で、メールサーバ１０２から受信データを受信し、ステップＳ９５に進む。
【０２０９】
また、メッセージ送受信処理のステップＳ９４以降、図２４に示すような処理が行われる。ステップＳ９４で、受信データを受信メッセージボックス４４ｂに記憶すると、ステップＳ２２１で、当該受信データがメッセージＩＤを有しているかどうかを判断する。ステップＳ２２１で“ＮＯ”であれば、つまり当該受信データがメッセージＩＤを有していなければ、そのままステップＳ２２４に進む。一方、ステップＳ２２１で、当該受信データがメッセージＩＤを有していれば、ステップＳ２２３で、当該メッセージＩＤを含む送信データを送信可能に設定して、ステップＳ８７に進む。つまり、ステップＳ２２３では、自動返信機能の属性として「コピー属性」が指定されている場合には、受信データに含まれるメッセージＩＤ同じメッセージＩＤが付加された送信データの複製を送信メッセージボックス４４ａに記憶して、当該複製を送信可能にする。また、ステップＳ２２３では、自動返信機能の属性として「ムーブ属性」が指定されている場合には、受信データに含まれるメッセージＩＤと同じメッセージＩＤが付加された送信データから当該メッセージＩＤを削除して、当該送信データを送信可能にする。
【０２１０】
ただし、送信可能にした送信データを送信メッセージボックス４４ａに機構するとき、当該送信データは電子メール形式に変換されるが、その宛先には、自動送信を要求してきたゲーム装置１２のメールアドレスが自動的に登録される。ただし、上記の処理は、受信メッセージボックスに記憶後のデータに対してではなく、バッファに記憶されている状態でステップＳ２２１、Ｓ２２３、Ｓ２２４の処理が行われてもよい。
【０２１１】
他の実施例によれば、自動返信機能を利用することにより、特定のユーザとの間で特定のアイテムを交換したり、特定のユーザに特定のアイテムを譲ったりすることができる。したがって、上述の実施例の効果に加えて、利便性の高い通信環境を提供することができる。
【符号の説明】
【０２１２】
１０  …ゲームシステム
１２  …ゲーム装置
１８  …光ディスク
２２  …コントローラ
２４  …受信ユニット
３４  …モニタ
３４ａ  …スピーカ
４０  …ＣＰＵ
４２  …システムＬＳＩ
４２ａ  …入出力プロセッサ
４２ｂ  …ＧＰＵ
４２ｃ  …ＤＳＰ
４２ｄ  …ＶＲＡＭ
４２ｅ  …内部メインメモリ
４４  …フラッシュメモリ
４６  …外部メインメモリ
４８  …ＲＯＭ／ＲＴＣ
５０  …無線通信モジュール
５２  …無線コントローラモジュール
５４  …ディスクドライブ
５６  …ＡＶ  ＩＣ
５８  …ＡＶコネクタ
６０  …拡張コネクタ
６２  …メモリカード用コネクタ
７０  …プロセッサ
７４  …加速度センサ
８０  …画像情報演算部
８６  …撮像素子
８８  …画像処理回路
【図１】
2014061421.tif 000003
【図２】
2014061421.tif 000004
【図３】
2014061421.tif 000005
【図４】
2014061421.tif 000006
【図５】
2014061421.tif 000007
【図６】
2014061421.tif 000008
【図７】
2014061421.tif 000009
【図８】
2014061421.tif 000010
【図９】
2014061421.tif 000011
【図１０】
2014061421.tif 000012
【図１１】
2014061421.tif 000013
【図１２】
2014061421.tif 000014
【図１３】
2014061421.tif 000015
【図１４】
2014061421.tif 000016
【図１５】
2014061421.tif 000017
【図１６】
2014061421.tif 000018
【図１７】
2014061421.tif 000019
【図１８】
2014061421.tif 000020
【図１９】
2014061421.tif 000021
【図２０】
2014061421.tif 000022
【図２１】
2014061421.tif 000023
【図２２】
2014061421.tif 000024
【図２３】
2014061421.tif 000025
【図２４】
2014061421.tif 000026
【図２５】
2014061421.tif 000027
【図２６】
2014061421.tif 000028
【図２７】
2014061421.tif 000029
【図２８】
2014061421.tif 000030
【手続補正書】
【提出日】平成25年12月10日(2013.12.10)
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
この発明はゲーム装置、ゲームプログラム、ゲームシステムおよびゲーム制御方法に関し、特にたとえば、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用する、ゲーム装置、ゲームプログラム、ゲームシステムおよびゲーム制御方法に関する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
それゆえに、この発明の主たる目的は、新規な、ゲーム装置、ゲームプログラム、ゲームシステムおよびゲーム制御方法を提供することである。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
また、この発明の他の目的は、オンラインゲーム専用のサーバを設けることなく、複数のゲーム装置間でデータの提供をおこなうことが可能な、ゲーム装置、ゲームプログラム、ゲームシステムおよびゲーム制御方法を提供することである。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
また、この発明の他の目的は、複数のゲーム装置間で簡単にデータの提供が可能であり、かつ、提供の機会を増やすことができる、ゲーム装置、ゲームプログラム、ゲームシステムおよびゲーム制御方法を提供することである。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
第１の発明は、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行するゲーム装置であって、通信手段と、送信データ記憶手段と、受信データ記憶手段と、アプリケーション処理手段と、自動返信手段とを備える。通信手段は、データの送受信を行う。送信データ記憶手段は、送信を待機することを示す送信待機情報を含む送信データを記憶する。受信データ記憶手段は、受信された受信データを記憶する。アプリケーション処理手段は、ユーザが指定するアプリケーションプログラムを実行し、受信データを利用するアプリケーション処理を行う。自動返信手段は、受信データに返信を要求することを示す返信要求情報が含まれている場合に、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除し、当該送信データを通信手段を介して送信する。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
第１の発明では、ゲーム装置は、ネットワークを介して他の装置のとの間でデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行する。通信手段はデータの送受信を行い、送信データ記憶手段は、送信を待機することを示す送信待機情報を含む送信データを記憶する。受信データ記憶手段は、受信された受信データを記憶する。アプリケーション処理手段は、ユーザが指定するアプリケーションプログラムを実行し、このとき、受信データ記憶手段によって記憶された受信データを利用する。自動返信手段は、受信データに返信を要求することを示す返信要求情報が含まれている場合に、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除し、当該送信データを通信手段を介して送信する。ただし、送信データは、返信要求した装置に対して送信される。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
第２の発明は、第１の発明に従属し、自動返信手段は、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除した当該送信データ自体を送信する。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
第２の発明では、自動返信手段は、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除し、送信待機情報を削除した送信データ自体を送信する。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
第２の発明によれば、返信要求情報を含む受信データを受信すると、これに応じて、送信待機情報を含む送信データがその待機情報を解除されて自動的に送信されるので、相手からの要求に応じて自動でデータを送信することができる。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
第３の発明は、第１の発明に従属し、自動返信手段は、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除した当該送信データのコピーを送信する。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】変更
【補正の内容】
【００１６】
第３の発明では、自動返信手段は、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除し、送信待機情報を削除した送信データのコピーを送信する。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
第３の発明によれば、送信データのコピーを送信するので、同じ送信データを複数の相手に送信することができる。
【手続補正１４】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】変更
【補正の内容】
【００１８】
第４の発明は、第１ないし第３の発明のいずれかに従属し、アプリケーション処理手段は、ネットワークを介してアイテムの取引を行うゲームのアプリケーションプログラムを実行するものであって、送信データには、当該アイテムに関するデータが含まれ、返信要求情報が含まれる受信データには、当該アイテムの取引に同意する旨の意思表示情報がさらに含まれ、自動返信手段において、当該返信要求情報が含まれる受信データに応じてアイテムに関するデータが含まれる送信データが送信されることによって、ゲームにおける取引を成立させる。
【手続補正１５】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】変更
【補正の内容】
【００１９】
第４の発明では、アプリケーション処理手段は、ネットワークを介してアイテムの取引を行うゲームのアプリケーションプログラムを実行する。送信データには、当該アイテムに関するデータが含まれ、返信要求情報が含まれる受信データには、当該アイテムの取引に同意する旨の意思表示情報がさらに含まれる。自動返信手段において、当該返信要求情報が含まれる受信データに応じてアイテムに関する送信データが、返信要求した他の装置に送信される。これによって、ゲームにおける取引が成立する。
【手続補正１６】
【補正対象書類名】明細書
【補正対象項目名】００２１
【補正方法】変更
【補正の内容】
【００２１】
第５の発明は、アプリケーション処理手段は、取引を行う旨を通知する通知データを通信手段に送信させる通知処理を含む、第４の発明に従属するゲーム装置である。
【手続補正１７】
【補正対象書類名】明細書
【補正対象項目名】００２２
【補正方法】変更
【補正の内容】
【００２２】
第５の発明では、アプリケーション処理手段は、通知処理によって、取引を行う旨を通知する通知データを通信手段に送信させる。
【手続補正１８】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
第６の発明は、通信部と、送信データ記憶部と、受信データ記憶部を備え、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するゲーム装置のゲームプログラムであって、ゲーム装置のコンピュータを、ゲーム処理手段と、自動返信手段として機能させる。通信部は、データの送受信を行う。送信データ記憶部は、送信を待機することを示す送信待機情報を含む送信データを記憶する。受信データ記憶部は、受信された受信データを記憶する。ゲーム処理手段は、ユーザが指定するゲームプログラムを実行し、受信データを利用する。自動返信手段は、受信データに返信を要求することを示す返信要求情報が含まれている場合に、送信データ記憶部に記憶される送信データに含まれる送信待機情報を削除し、当該送信データを通信部を介して送信する。
第７の発明は、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行するゲームシステムであって、データの送受信を行う通信手段と、送信を待機することを示す送信待機情報を含む送信データを記憶する送信データ記憶手段と、受信された受信データを記憶する受信データ記憶手段と、ユーザが指定するアプリケーションプログラムを実行し、受信データを利用するアプリケーション処理を行うアプリケーション処理手段と、受信データに返信を要求することを示す返信要求情報が含まれている場合に、送信データ記憶手段に記憶される送信データに含まれる送信待機情報を削除し、当該送信データを通信手段を介して送信する自動返信手段を備える、ゲームシステムである。
第８の発明は、データの送受信を行う通信手段を備え、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行するゲーム装置のゲーム制御方法であって、ゲーム装置のコンピュータは、（ａ）送信を待機することを示す送信待機情報を含む送信データを記憶部に記憶し、（ｂ）受信された受信データを記憶部に記憶し、（ｃ）ユーザが指定するアプリケーションプログラムを実行し、受信データを利用するアプリケーション処理を行い、そして（ｄ）受信データに返信を要求することを示す返信要求情報が含まれている場合に、記憶部に記憶される送信データに含まれる送信待機情報を削除し、当該送信データを通信手段を介して送信する、ゲーム制御方法である。
【手続補正１９】
【補正対象書類名】明細書
【補正対象項目名】００２５
【補正方法】変更
【補正の内容】
【００２５】
第６ないし第８の発明においても、第１の発明と同様に、受信したデータに対して自動的に返信を行うことができ、オンラインゲームをプレイしている間でなくとも、他のゲーム機とのデータのやり取りを行うことができる。
【手続補正２０】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行するゲーム装置であって、
データの送受信を行う通信手段と、
送信を待機することを示す送信待機情報を含む送信データを記憶する送信データ記憶手段と、
受信された受信データを記憶する受信データ記憶手段と、
ユーザが指定するアプリケーションプログラムを実行し、前記受信データを利用するアプリケーション処理を行うアプリケーション処理手段と、
前記受信データに返信を要求することを示す返信要求情報が含まれている場合に、前記送信データ記憶手段に記憶される前記送信データに含まれる前記送信待機情報を削除し、当該送信データを前記通信手段を介して送信する自動返信手段を備える、ゲーム装置。
【請求項２】
前記自動返信手段は、前記送信データ記憶手段に記憶される前記送信データに含まれる前記送信待機情報を削除した当該送信データ自体を送信する、請求項１記載のゲーム装置。
【請求項３】
前記自動返信手段は、前記送信データ記憶手段に記憶される前記送信データに含まれる前記送信待機情報を削除した当該送信データのコピーを送信する、請求項１記載のゲーム装置。
【請求項４】
前記アプリケーション処理手段は、ネットワークを介してアイテムの取引を行うゲームの前記アプリケーションプログラムを実行するものであって、前記送信データには、当該アイテムに関するデータが含まれ、前記返信要求情報が含まれる受信データには、当該アイテムの取引に同意する旨の意思表示情報がさらに含まれ、
前記自動返信手段において、当該返信要求情報が含まれる受信データに応じて前記アイテムに関するデータが含まれる送信データが送信されることによって、ゲームにおける取引を成立させる、請求項１ないし３のいずれかに記載のゲーム装置。
【請求項５】
前記アプリケーション処理手段は、前記取引を行う旨を通知する通知データを前記通信手段に送信させる通知処理を含む、請求項４に記載のゲーム装置。
【請求項６】
データの送受信を行う通信部と、送信を待機することを示す送信待機情報を含む送信データを記憶する送信データ記憶部と、受信された受信データを記憶する受信データ記憶部を備え、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するゲーム装置のゲームプログラムであって、
前記ゲーム装置のコンピュータを、
ユーザが指定するゲームプログラムを実行し、前記受信データを利用するゲーム処理を行うゲーム処理手段と、
前記受信データに返信を要求することを示す返信要求情報が含まれている場合に、前記送信データ記憶部に記憶される前記送信データに含まれる前記送信待機情報を削除し、当該送信データを前記通信部を介して送信する自動返信手段として機能させる、ゲームプログラム。
【請求項７】
他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行するゲームシステムであって、
データの送受信を行う通信手段と、
送信を待機することを示す送信待機情報を含む送信データを記憶する送信データ記憶手段と、
受信された受信データを記憶する受信データ記憶手段と、
ユーザが指定するアプリケーションプログラムを実行し、前記受信データを利用するアプリケーション処理を行うアプリケーション処理手段と、
前記受信データに返信を要求することを示す返信要求情報が含まれている場合に、前記送信データ記憶手段に記憶される前記送信データに含まれる前記送信待機情報を削除し、当該送信データを前記通信手段を介して送信する自動返信手段を備える、ゲームシステム。
【請求項８】
データの送受信を行う通信手段を備え、他の装置とネットワークを介してデータの送受信を行い、当該送受信されたデータを利用するアプリケーションプログラムを実行するゲーム装置のゲーム制御方法であって、
前記ゲーム装置のコンピュータは、
（ａ）送信を待機することを示す送信待機情報を含む送信データを記憶部に記憶し、
（ｂ）受信された受信データを前記記憶部に記憶し、
（ｃ）ユーザが指定するアプリケーションプログラムを実行し、前記受信データを利用するアプリケーション処理を行い、そして
（ｄ）前記受信データに返信を要求することを示す返信要求情報が含まれている場合に、前記記憶部に記憶される前記送信データに含まれる前記送信待機情報を削除し、当該送信データを前記通信手段を介して送信する、ゲーム制御方法。