情報処理プログラム、情報処理装置、情報処理方法および情報処理システム
【課題】ユーザに提供すべきでないデータに関する情報を他の装置と共有することのできる情報処理装置、情報処理プログラム、情報処理方法および情報処理システムを提供する。
【解決手段】システムに含まれるゲーム装置１０のそれぞれからユーザに提供すべきでないコンテンツを含むデータの通報回数を、当該データに付与されている情報に基づいてカウントする。カウント値が所定の閾値以上となったときに当該情報を特定情報に追加して登録する。特定情報はシステムのサーバからそれぞれの情報処理装置に送信され、それぞれの情報処理装置で用いられる。
【解決手段】システムに含まれるゲーム装置１０のそれぞれからユーザに提供すべきでないコンテンツを含むデータの通報回数を、当該データに付与されている情報に基づいてカウントする。カウント値が所定の閾値以上となったときに当該情報を特定情報に追加して登録する。特定情報はシステムのサーバからそれぞれの情報処理装置に送信され、それぞれの情報処理装置で用いられる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理プログラム、情報処理装置、情報処理方法および情報処理システムに関し、より特定的には、装置間で送受信されるデータの中から好ましくないデータを特定する情報処理プログラム、情報処理装置、情報処理方法および情報処理システムに関する。
【背景技術】
【０００２】
従来、不快感を与えるデータや不要なデータを、ブラックリストを用いて、受信したデータの中から削除するシステムがある（例えば、特許文献１参照）。上記特許文献１で開示されているシステムでは、迷惑メールの送信元のアドレスを予め登録しておく。そして、登録されたアドレスが送信元となっているメールを受信した場合には、当該メールを自動的に削除する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−３３５２８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１で開示されているシステムでは、迷惑メールのメールアドレスを記憶したデータベースは、他の装置と共有されることがない。従って、上記特許文献１で開示されているようなシステムでは、ユーザが不快感を与えるデータ或いは不要なデータ等の不適切なコンテンツの閲覧を必ずしも防ぐことはできなかった。
【０００５】
それ故に本発明の目的は、ユーザに提供すべきでないデータに関する情報を他の装置と共有することのできる情報処理装置、情報処理プログラム、情報処理方法および情報処理システムを提供することである。
【課題を解決するための手段】
【０００６】
本発明は、コンテンツを含むデータの送受信が可能な複数の情報処理装置を少なくとも含む情報処理システムである。本発明の情報処理システムは、特定情報受信手段と、特定情報格納手段と、特定情報送信手段と、データ送受信手段と、出力手段とを備える情報処理装置を少なくとも含む。上記特定情報受信手段は、出力を制限する上記データを特定する情報を特定情報として受信する。上記特定情報格納手段は、上記特定情報受信手段によって受信された上記特定情報を格納する。上記特定情報送信手段は、上記特定情報格納手段に格納された上記特定情報をさらに他の情報処理装置へ送信する。上記データ送受信手段は、上記データを他の情報処理装置との間で送受信する。上記出力手段は、上記データ送受信手段によって受信される上記データの内、上記特定情報格納手段に格納されている上記特定情報に基づいて特定された上記データを出力せず、当該特定情報に基づいて特定されない上記データを出力する。
【０００７】
上記構成例によれば、他の情報処理装置から受信した特定情報を用いてユーザに提供すべきでないデータを特定できるので、提供すべきでないデータに関する情報を他の情報処理装置と共有することができる。さらに、ユーザは不適切なデータを提供されることを未然に防げる。また、特定情報は他の情報処理装置へ送信（伝播）されるので、自らが最新の特定情報を持っている場合に、他人に最新の特定情報を提供することができ、他人が不適切なデータを提供されてしまうことも未然に防ぐことができる。
【０００８】
他の構成例として、各上記情報処理装置は、無線通信手段をさらに備えていてもよい。ここで、上記無線通信手段は、通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する。この場合、上記特定情報受信手段は、上記無線通信手段を用いて上記特定情報を自動的に受信してもよい。また、この場合、上記特定情報格納手段は、上記無線通信手段によって受信された上記特定情報を格納してもよい。また、この場合、上記特定情報送信手段は、上記特定情報格納手段に格納された上記特定情報を上記無線通信手段を用いて他の情報処理装置に自動的に送信してもよい。
【０００９】
上記構成例によれば、能動的に特定情報を取り込むためのアクセスを行わずとも、自動的に他の情報処理装置から特定情報を送受信できるため、ユーザが意識することなく特定情報を共有することができ、不適切なコンテンツが出力されることを防げる。
【００１０】
他の構成例として、各上記情報処理装置は、無線通信手段をさらに備えていてもよい。ここで、上記無線通信手段は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置に無線接続し、当該他の情報処理装置との間で通信する。この場合、上記特定情報受信手段は、上記無線通信手段を用いて上記特定情報を受信してもよい。また、この場合、上記特定情報格納手段は、上記無線通信手段によって受信された上記特定情報を格納してもよい。また、この場合、上記特定情報送信手段は、上記特定情報格納手段に格納された上記特定情報を上記無線通信手段を用いて他の情報処理装置に送信してもよい。
【００１１】
上記構成例によれば、予測しないデータを受信してしまったとしても、特定情報も他の情報処理装置から自動的に受信するため、不適切なデータが提供されてしまうことを未然に防げる。
【００１２】
他の構成例として、上記情報処理システムは、各情報処理装置のそれぞれに対して上記特定情報を送信するサーバ装置をさらに含んでいてもよい。この場合、各上記情報処理装置は、サーバ情報受信手段と、更新手段とをさらに備えていてもよい。ここで、上記サーバ情報受信手段は、上記サーバ装置から送信される上記特定情報を受信する。また、上記更新手段は、上記サーバ情報受信手段によって受信された上記特定情報で上記特定情報格納手段に格納された上記特定情報を更新する。
【００１３】
上記構成例によれば、複数の情報処理装置で共有される特定情報をサーバ装置で一括して効率的に管理できる。また、近距離無線によって送受信を行う場合には、サーバ装置から受信した特定情報を近距離無線で伝播させることができるので、サーバ装置に接続できない場合にも近距離無線を通して特定情報を得ることができる。
【００１４】
他の構成例として、各上記情報処理装置は、受付手段と、送信手段とをさらに備えていてもよい。ここで、上記受付手段は、上記データ送受信手段によって受信される上記データの中で出力しないように設定する上記データの選択をユーザから受け付ける。また、上記送信手段は、上記受付手段によって受け付けられた上記データまたは当該データに関連する情報の内少なくとも一部を通報データとして上記サーバ装置に送信する。この場合、上記サーバ装置は、サーバ側更新手段と、サーバ側特定情報格納手段とを備えていてもよい。ここで、上記サーバ側更新手段は、各上記情報処理装置の上記送信手段から送信される上記通報データに基づいて、各上記情報処理装置に送信する上記特定情報を更新する。また、上記サーバ側特定情報格納手段は、上記サーバ側更新手段によって更新される上記特定情報を格納する。
【００１５】
上記構成例によれば、サーバ装置はシステムに含まれる複数の情報処理装置から送信される通報データに基づいて、それぞれの情報処理装置のユーザによって不適切と判断された結果を反映した特定情報を管理できるので、複数のユーザの総意に基づいた特定情報を形成することができる。
【００１６】
他の構成例として、上記サーバ装置は、サーバ情報送信手段をさらに備えていてもよい。ここで、上記サーバ情報送信手段は、上記サーバ側特定情報格納手段に格納されている上記特定情報を送信する。この場合、上記サーバ情報受信手段は、上記サーバ情報送信手段から上記特定情報を定期的に受信してもよい。
【００１７】
上記構成例によれば、サーバがユーザによって不適切と判断された結果を反映した特定情報を定期的に送信するので、システムに含まれる各情報処理装置のそれぞれは最新の結果を反映した特定情報に基づいて提供すべきでないデータを特定できる。
【００１８】
他の構成例として、上記サーバ側更新手段は、各上記情報処理装置の上記送信手段からそれぞれ送信される上記通報データの送信回数が所定の閾値以上となったとき、上記サーバ側特定情報格納手段に格納されている上記特定情報を更新してもよい。
【００１９】
上記構成例によれば、システムに含まれる各情報処理装置それぞれのユーザによってデータが不適切と判断された回数を特定情報に反映できる。
【００２０】
他の構成例として、上記データは、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子及び当該データのデータ識別子を含んでいてもよい。この場合、上記送信手段は、少なくとも上記ユーザ識別子及び上記データ識別子を上記通報データとして上記サーバ装置に送信してもよい。また、この場合、上記サーバ側更新手段は、上記送信手段からの送信回数が第１の閾値以上となった上記通報データの上記データ識別子を上記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第１の閾値よりも大きい第２の閾値以上となった上記通報データの上記ユーザ識別子を上記特定情報に追加して更新してもよい。
【００２１】
上記構成例によれば、あるデータが、相対的に小さい値である第１の閾値以上の回数だけサーバに通報されたときには、データ固有の識別子を特定情報として追加するので、当該データのみが提供されないようにすることができる。すなわち、比較的厳しくない制限を行う。また、相対的に大きな値である第２の閾値以上の回数だけ通報されたときには、データの作成者を示す識別子を特定情報として追加するので、提供されないようにするデータは増え、比較的厳しい制限を行うことになる。このように、通報された回数によって、データが提供されないようにするための制限を段階的に設定することができる。
【００２２】
他の構成例として、上記出力手段は、上記データ送受信手段によって受信される上記データの内、上記データ識別子と上記特定情報に含まれる上記データ識別子が一致する上記データ、及び、上記ユーザ識別子と上記特定情報に含まれる上記ユーザ識別子が一致する上記データを出力せず、いずれも一致しない上記データを出力してもよい。
【００２３】
上記構成例によれば、上記第１の閾値及び上記第２の閾値を用いて段階的に設定した制限で実際にデータを提供することができる。
【００２４】
他の構成例として、上記データは、複数のアプリケーションの内いずれかを用いて作成され、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子及び当該データを作成するのに用いられたアプリケーションプログラムを示すアプリ識別子を含んでいてもよい。この場合、上記サーバ側更新手段は、上記送信手段からの送信回数が第２の閾値以上となった上記データの上記ユーザ識別子と上記アプリ識別子とを組み合わせて上記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第２の閾値よりも大きい第３の閾値以上となった上記通報データの上記ユーザ識別子と、全てのアプリケーションプログラムを示す上記アプリ識別子とを組み合わせて当該特定情報に追加することで当該特定情報を更新してもよい。
【００２５】
上記構成例によれば、あるデータが、相対的に小さい値である第２の閾値以上の回数だけサーバに通報されたときは、通報されたデータの作成者を示す識別子と通報されたデータを作成したアプリケーションの識別子との組み合わせを特定情報として追加するので、作成者と作成したアプリケーションとが一致するデータが提供されないようにすることができる。すなわち、比較的厳しくない制限を行う。また、相対的に大きな値である第３の閾値以上の回数だけ通報されたときには、通報されたデータの作成者を示す識別子と全てのアプリケーションを表す識別子との組み合わせを特定情報として追加するので、作成者が一致するデータであれば作成したアプリケーションを問わずに提供されないようにすることができる。すなわち、比較的厳しい制限を行うことになる。このように、通報された回数によって、データが提供されないようにするための制限を段階的に設定することができる。
【００２６】
他の構成例として、上記出力手段は、上記データ送受信手段によって受信される上記データの内、上記アプリ識別子と上記ユーザ識別子との組み合わせが上記特定情報に含まれる上記アプリ識別子と上記ユーザ識別子との組み合わせと一致する上記データを出力せず、一致しない上記データを出力してもよい。
【００２７】
上記構成例によれば、上記第２の閾値及び上記第３の閾値を用いて段階的に設定した制限で実際にデータを提供することができる。
【００２８】
他の構成例として、各上記情報処理装置は、受付手段と、送信手段とをさらに備えていてもよい。ここで、上記受付手段は、上記データ送受信手段によって受信される上記データの中で出力しないように設定する上記データの選択をユーザから受け付ける。また、上記送信手段は、上記受付手段によって受け付けられた上記データ又は当該データに関連する情報の内少なくとも一部を通報データとして上記サーバ装置に送信する。この場合、上記サーバ装置は、通知手段と、サーバ側更新手段と、サーバ側特定情報格納手段とを備えていてもよい。ここで、上記通知手段は、各上記情報処理装置の上記送信手段から送信される上記通報データに基づいて、当該通報データを用いて特定される上記データが不適切なデータであることを通知する。また、上記サーバ側更新手段は、上記通知手段による通知を受けた上記サーバ装置の使用者の操作により、各情報処理装置に送信する上記特定情報を更新する。また、上記サーバ側特定情報格納手段は、上記サーバ側更新手段によって更新される上記特定情報を格納する。
【００２９】
上記構成例によれば、システムに含まれる複数の情報処理装置から送信される通報データに基づいて、それぞれの情報処理装置のユーザによって不適切と判断された結果を反映した通知をサーバ装置の使用者が受けられる。したがって、サーバ装置の使用者は、どのようなデータが多くのユーザによって不適切と思われているかどうかを把握することが容易になる。
【００３０】
他の構成例として、上記通知手段は、各上記情報処理装置の上記送信手段からの送信回数が所定の閾値以上となった上記通報データを用いて特定される上記データが不適切なデータであることを通知してもよい。
【００３１】
上記構成例によれば、システムに含まれる各情報処理装置の一定数以上のユーザによって不適切と判断されたデータがどのようなものであるかをサーバの使用者に通知することができる。
【００３２】
他の構成例として、上記更新手段は、上記サーバ情報受信手段によって受信された上記特定情報が、情報処理装置に既に格納されている上記特定情報よりも新しい場合、既に格納されている上記特定情報に、受信された上記特定情報の差分を追加又は全部を上書きすることで上記特定情報を更新してもよい。
【００３３】
上記構成例によれば、サーバ装置で管理されている特定情報が新しいときに情報処理装置において特定情報が更新されるので、最新の特定情報を効率的に維持できる。
【００３４】
他の構成例として、上記更新手段は、上記サーバ情報受信手段によって上記特定情報が受信された時点で上記情報処理装置に格納された上記特定情報を更新してもよい。
【００３５】
上記構成例によれば、サーバ装置で管理されている特定情報が常に最新の特定情報であると見なして、情報処理装置における特定情報が即座に更新されるので、最新の特定情報を効率的に維持できる。
【００３６】
他の構成例として、各上記情報処理装置は、無線通信手段をさらに備えていてもよい。ここで、上記無線通信手段は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する。この場合、上記データ送受信手段は、上記無線通信手段を用いて自動的に上記データを送受信する。
【００３７】
上記構成例によれば、他の情報処理装置との間で自動的にデータを送受信するため予測しないデータを受信してしまうことがあるが、特定情報を他の情報処理装置から受信するため、不適切なデータが出力されてしまうことを未然に防げる。
【００３８】
他の構成例として、各上記情報処理装置は、データ格納手段をさらに備えていてもよい。ここで、上記データ格納手段は、上記データ送受信手段によって現在までに受信された上記データを格納する。この場合、上記出力手段は、上記データ格納手段に格納された上記データの内、上記特定情報格納手段に格納されている上記特定情報によって特定された上記データを出力しなくてもよい。
【００３９】
上記構成例によれば、現在までに受信した全てのデータに対して、最新の特定情報を用いて提供可能か否かを判断することができる。
【００４０】
他の構成例として、各上記情報処理装置は、携帯可能であってもよい。
【００４１】
上記構成例によれば、情報処理装置が携帯されることによって、データの送受信が相対的に多くなる場合でも、不適切なデータがそれぞれの情報装置のユーザに提供されることを未然に防げる。
【００４２】
また、本発明は、上記各手段を備える情報処理プログラムおよび情報処理システムや上記各手段で行われる動作を含む情報処理方法の形態で実施されてもよい。
【発明の効果】
【００４３】
本発明によれば、ユーザに提供すべきでないデータに関する情報を他の装置と共有することのできる情報処理装置、情報処理プログラム、情報処理方法および情報処理システムを提供できる。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態に係る情報処理プログラムを実行するゲーム装置１０の外観図
【図２】図１のゲーム装置１０の内部構成の一例を示すブロック図
【図３】サーバ５と図１に記載のゲーム装置１０とからなる情報処理システムの構成例を示す図
【図４】図３のサーバ５の内部構成の一例を示すブロック図
【図５】本発明におけるキャラクタのパーツの候補選択画面の一例を示す図
【図６】本発明の一実施形態に係る情報処理システムの概略を説明するための図
【図７Ａ】図１のゲーム装置１０で実行される情報処理プログラムを実行することに応じて、メインメモリ３２に記憶される各種データの一例を示す図
【図７Ｂ】図７Ａのユーザ作成データＵｄのより詳細なデータ構成を示す図
【図７Ｃ】図７ＡのタスクデータＴｄのより詳細なデータ構成を示す図
【図７Ｄ】図７ＡのＬＢＬデータＬｄのより詳細なデータ構成を示す図
【図７Ｅ】図７ＡのＧＢＬデータＧｄのより詳細なデータ構成を示す図
【図７Ｆ】図４のサーバ５で実行されるサーバ処理プログラムを実行することに応じて、メインメモリ５５に記憶される各種データの一例を示す図
【図８Ａ】図１のゲーム装置１０で実行されるキャラクタ取り扱い処理プログラムを実行することによってゲーム装置１０がキャラクタ取り扱い処理を行う一例を示すフローチャート
【図８Ｂ】図１のゲーム装置１０で実行されるキャラクタ取り扱い処理プログラムを実行することによってゲーム装置１０がキャラクタ取り扱い処理を行う一例を示すフローチャート
【図８Ｃ】図８Ａのステップ１４０で実行されるキャラクタ編集処理の詳細を示すフローチャート
【図８Ｄ】図８Ａのステップ１４０で実行されるキャラクタ編集処理の詳細を示すフローチャート
【図８Ｅ】図８Ａのステップ１５０で実行されるＬＢＬ登録処理の詳細を示すフローチャート
【図８Ｆ】図１のゲーム装置１０で実行されるすれ違い通信処理プログラムを実行することによってゲーム装置１０がすれ違い通信処理を行う一例を示すフローチャート
【図８Ｇ】図１のゲーム装置１０で実行されるインターネット通信処理プログラムを実行することによってゲーム装置１０がインターネット通信処理を行う一例を示すフローチャート
【図８Ｈ】図１のゲーム装置１０で実行されるローカル通信処理プログラムを実行することによってゲーム装置１０がローカル通信処理を行う一例を示すフローチャート
【図８Ｉ】図１のゲーム装置１０で実行されるフィルタリング処理プログラムを実行することによってゲーム装置１０がフィルタリング処理を行う一例を示すフローチャート
【図８Ｊ】図１のゲーム装置１０で実行されるＧＢＬ更新処理プログラムを実行することによってゲーム装置１０がＧＢＬ更新処理を行う一例を示すフローチャート
【図９】図３のサーバ５で実行されるサーバ処理プログラムを実行することによってサーバ５がサーバ処理を行う一例を示すフローチャート
【発明を実施するための形態】
【００４５】
（第１の実施形態）
図面を参照して、本発明の第１の実施形態に係る情報処理プログラムを実行する情報処理装置について説明する。本発明の情報処理プログラムは、任意のコンピュータシステムで実行されることによって適用することができるが、情報処理装置の一例として携帯型のゲーム装置１０を用い、ゲーム装置１０で実行される情報処理プログラムを用いて説明する。
【００４６】
［ゲーム装置の外部構成］
まず始めに、図１を参照して、ゲーム装置１０の外部構成について説明する。なお、図１は、ゲーム装置１０の外観の一例を示す平面図である。ゲーム装置１０は、一例として携帯型のゲーム装置であり、折り畳み可能に構成されている。図１は、開いた状態（開状態）におけるゲーム装置１０の一例を示す正面図である。
【００４７】
図１において、ゲーム装置１０は、下側ハウジング１１および上側ハウジング２１を有する。下側ハウジング１１と上側ハウジング２１とは、開閉可能（折り畳み可能）に連結されている。図１の例では、下側ハウジング１１および上側ハウジング２１は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回動可能に連結されている。通常、ユーザは、開状態でゲーム装置１０を使用する。そして、ユーザは、ゲーム装置１０を使用しない場合には閉状態としてゲーム装置１０を保管する。また、ゲーム装置１０は、上記閉状態および開状態のみでなく、下側ハウジング１１と上側ハウジング２１とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング２１を下側ハウジング１１に対して任意の角度で静止させることができる。
【００４８】
下側ハウジング１１には、下側ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示装置）１２、タッチパネル１３、各操作ボタン１４Ａ〜１４Ｌ（図１、図３Ａ〜図３Ｄ）、アナログスティック１５、ＬＥＤ１６Ａ〜１６Ｂ、挿入口１７、および、マイクロフォン用孔１８が設けられる。以下、これらの詳細について説明する。
【００４９】
図１に示すように、下側ＬＣＤ１２は下側ハウジング１１に収納される。下側ＬＣＤ１２は横長形状であり、長辺方向が下側ハウジング１１の長辺方向に一致するように配置される。下側ＬＣＤ１２は、下側ハウジング１１の中央に配置される。下側ＬＣＤ１２は、下側ハウジング１１の内側面（主面）に設けられ、下側ハウジング１１の内側面に設けられた開口部から下側ＬＣＤ１２の画面が露出する。そして、ゲーム装置１０を使用しない場合には上記閉状態としておくことによって、下側ＬＣＤ１２の画面が汚れたり傷ついたりすることを防止することができる。なお、本実施例では表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置など、他の任意の表示装置を利用してもよい。また、下側ＬＣＤ１２として、任意の解像度の表示装置を利用することができる。
【００５０】
図１に示されるように、ゲーム装置１０は、入力装置として、タッチパネル１３を備えている。タッチパネル１３は、下側ＬＣＤ１２の画面上を覆うように装着されている。なお、本実施例では、タッチパネル１３は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル１３は、抵抗膜方式に限らず、例えば静電容量方式等、任意の押圧式のタッチパネルを用いることができる。本実施例では、タッチパネル１３として、下側ＬＣＤ１２の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル１３の解像度と下側ＬＣＤ１２の解像度とが一致している必要はない。また、下側ハウジング１１の上側面には挿入口１７（図１に示す点線）が設けられている。挿入口１７は、タッチパネル１３に対する操作を行うために用いられるタッチペン２８を収納することができる。なお、タッチパネル１３に対する入力は通常タッチペン２８を用いて行われるが、タッチペン２８に限らずユーザの指でタッチパネル１３に対する入力をすることも可能である。
【００５１】
各操作ボタン１４Ａ〜１４Ｌは、所定の入力を行うための入力装置である。図１に示されるように、下側ハウジング１１の内側面（主面）には、各操作ボタン１４Ａ〜１４Ｌの内、十字ボタン１４Ａ（方向入力ボタン１４Ａ）、ボタン１４Ｂ、ボタン１４Ｃ、ボタン１４Ｄ、ボタン１４Ｅ、電源ボタン１４Ｆ、セレクトボタン１４Ｊ、ＨＯＭＥボタン１４Ｋ、およびスタートボタン１４Ｌが設けられる。十字ボタン１４Ａは、十字の形状を有しており、上下左右の方向を指示するボタンを有している。ボタン１４Ｂ、ボタン１４Ｃ、ボタン１４Ｄ、およびボタン１４Ｅは、十字状に配置される。ボタン１４Ａ〜１４Ｅ、セレクトボタン１４Ｊ、ＨＯＭＥボタン１４Ｋ、およびスタートボタン１４Ｌには、ゲーム装置１０が実行するプログラムに応じた機能が適宜割り当てられる。例えば、十字ボタン１４Ａは選択操作等に用いられ、各操作ボタン１４Ｂ〜１４Ｅは例えば決定操作やキャンセル操作等に用いられる。また、電源ボタン１４Ｆは、ゲーム装置１０の電源をオン／オフするために用いられる。
【００５２】
アナログスティック１５は、方向を指示するデバイスであり、下側ハウジング１１の内側面の下側ＬＣＤ１２より左側領域の上部領域に設けられる。図１に示すように、十字ボタン１４Ａが下側ＬＣＤ１２より左側領域の下部領域に設けられ、アナログスティック１５が十字ボタン１４Ａの上方に設けられる。また、アナログスティック１５および十字ボタン１４Ａは、下側ハウジング１１を把持した左手の親指で操作可能な位置に設計される。また、アナログスティック１５を上部領域に設けたことにより、下側ハウジング１１を把持する左手の親指が自然と位置するところにアナログスティック１５が配され、十字ボタン１４Ａは、左手の親指を少し下にずらした位置に配される。アナログスティック１５は、そのキートップが、下側ハウジング１１の内側面に平行にスライドするように構成されている。アナログスティック１５は、ゲーム装置１０が実行するプログラムに応じて機能する。例えば、３次元仮想空間に所定のオブジェクトが登場するゲームがゲーム装置１０によって実行される場合、アナログスティック１５は、当該所定のオブジェクトを３次元仮想空間内で移動させるための入力装置として機能する。この場合において、所定のオブジェクトは、アナログスティック１５のキートップがスライドした方向に移動される。なお、アナログスティック１５として、上下左右および斜め方向の任意の方向に所定量だけ傾倒することでアナログ入力を可能としたものを用いてもよい。
【００５３】
十字状に配置される、ボタン１４Ｂ、ボタン１４Ｃ、ボタン１４Ｄ、およびボタン１４Ｅの４つのボタンは、下側ハウジング１１を把持する右手の親指が自然と位置するところに配置される。また、これらの４つのボタンとアナログスティック１５とは、下側ＬＣＤ１２を挟んで、左右対称に配置される。これにより、ゲームプログラムによっては、例えば、左利きの人が、これらの４つのボタンを使用して方向指示入力をすることも可能である。
【００５４】
なお、図１においては、操作ボタン１４Ｇ〜１４Ｉの図示を省略している。例えば、Ｌボタン１４Ｇは、下側ハウジング１１の上側面の左端部に設けられ、Ｒボタン１４Ｈは、下側ハウジング１１の上側面の右端部に設けられる。Ｌボタン１４ＧおよびＲボタン１４Ｈは、ゲーム装置１に対して、例えば撮影指示操作（シャッター操作）を行うために用いられる。さらに、音量ボタン１４Ｉは、下側ハウジング１１の左側面に設けられる。音量ボタン１４Ｉは、ゲーム装置１０が備えるスピーカの音量を調整するために用いられる。
【００５５】
また、下側ハウジング１１の内側面には、マイクロフォン用孔１８が設けられる。マイクロフォン用孔１８の下部には後述する音声入力装置としてのマイク（図２参照）が設けられ、当該マイクがゲーム装置１０の外部の音を検出する。
【００５６】
また、下側ハウジング１１の左側面には開閉可能なカバー部１１Ｃが設けられる。このカバー部１１Ｃの内側には、ゲーム装置１０とデータ保存用外部メモリ４６とを電気的に接続するためのコネクタ（図示せず）が設けられる。データ保存用外部メモリ４６は、上記コネクタに着脱自在に装着される。データ保存用外部メモリ４６は、例えば、ゲーム装置１０によって撮像された画像のデータを記憶（保存）するために用いられる。なお、上記コネクタおよびそのカバー部１１Ｃは、下側ハウジング１１の右側面に設けられてもよい。
【００５７】
また、下側ハウジング１１の上側面にはゲーム装置１０とゲームプログラムを記録した外部メモリ４５を挿入するための挿入口１１Ｄが設けられ、その挿入口１１Ｄの内部には、外部メモリ４５と電気的に着脱自在に接続するためのコネクタ（図示せず）が設けられる。外部メモリ４５がゲーム装置１０に接続されることにより、所定のゲームプログラムが実行される。なお、上記コネクタおよび挿入口１１Ｄは、下側ハウジング１１の他の側面（例えば、右側面等）に設けられてもよい。
【００５８】
図１に示されるように、下側ハウジング１１の下側面には、ゲーム装置１０の電源のＯＮ／ＯＦＦ状況をユーザに通知する第１ＬＥＤ１６Ａが設けられる。また、図示はしていないが、下側ハウジング１１の右側面には、ゲーム装置１０の無線通信の確立状況をユーザに通知する第２ＬＥＤ１６Ｂが設けられる。ゲーム装置１０は、他の機器との間で無線通信を行うことが可能であり、第２ＬＥＤ１６Ｂは、他の機器との無線通信が確立している場合に点灯する。ゲーム装置１０は、例えば、ＩＥＥＥ８０２．１１ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。下側ハウジング１１の右側面には、この無線通信の機能を有効／無効にする無線スイッチ１９（図示せず）が設けられる。
【００５９】
なお、図示は省略するが、下側ハウジング１１には、ゲーム装置１０の電源となる充電式電池が収納され、下側ハウジング１１の側面（例えば、上側面）に設けられた端子を介して当該電池を充電することができる。
【００６０】
上側ハウジング２１には、上側ＬＣＤ２２、２つの外側撮像部２３（外側左撮像部２３ａおよび外側右撮像部２３ｂ）、内側撮像部２４、３Ｄ調整スイッチ２５、および３Ｄインジケータ２６が設けられる。以下、これらの詳細について説明する。
【００６１】
図１に示すように、上側ＬＣＤ２２は、上側ハウジング２１に収納される。上側ＬＣＤ２２は、横長形状であり、長辺方向が上側ハウジング２１の長辺方向に一致するように配置される。上側ＬＣＤ２２は、上側ハウジング２１の中央に配置される。上側ＬＣＤ２２の画面の面積は、一例として下側ＬＣＤ１２の画面の面積よりも大きく設定される。具体的には、上側ＬＣＤ２２の画面は、下側ＬＣＤ１２の画面よりも横長に設定される。すなわち、上側ＬＣＤ２２の画面のアスペクト比における横幅の割合は、下側ＬＣＤ１２の画面のアスペクト比における横幅の割合よりも大きく設定される。
【００６２】
上側ＬＣＤ２２の画面は、上側ハウジング２１の内側面（主面）２１Ｂに設けられ、上側ハウジング２１の内側面に設けられた開口部から上側ＬＣＤ２２の画面が露出する。また、上側ハウジング２１の内側面は、図示しない透明なスクリーンカバー２７によって覆われている。スクリーンカバー２７は、上側ＬＣＤ２２の画面を保護するとともに、上側ＬＣＤ２２と上側ハウジング２１の内側面と一体的にさせ、これにより統一感を持たせている。なお、本実施例では、上側ＬＣＤ２２が液晶表示装置であるとしたが、例えばＥＬを利用した表示装置などが利用されてもよい。また、上側ＬＣＤ２２として、任意の解像度の表示装置を利用することができる。
【００６３】
上側ＬＣＤ２２は、レンチキュラー方式やパララックスバリア方式（視差バリア方式）を用いて立体視可能な画像を表示することが可能な表示装置である。すなわち、上側ＬＣＤ２２は、視差バリアを用いてユーザの左目に左目用画像を、そして、ユーザの右目に右目用画像をそれぞれ視認させることにより、ユーザにとって立体感のある立体画像（立体視可能な画像）を表示することができる。また、上側ＬＣＤ２２は、上記視差バリアを無効にすることが可能であり、視差バリアを無効にした場合は、画像を平面的に表示することができる（上述した立体視とは反対の意味で平面視の画像を表示することができる。すなわち、表示された同一の画像が右目にも左目にも見えるような表示モードである。）。このように、上側ＬＣＤ２２は、立体視可能な画像を表示する立体表示モードと、画像を平面的に表示する（平面視画像を表示する）平面表示モードとを切り替えることが可能な表示装置である。この表示モードの切り替えは、後述する３Ｄ調整スイッチ２５によって行われる。
【００６４】
外側撮像部２３は、上側ハウジング２１の外側面（上側ＬＣＤ２２が設けられた主面と反対側の背面）２１Ｄ（図示せず）に設けられた２つの撮像部（外側左撮像部２３ａおよび外側右撮像部２３ｂ）の総称である。外側左撮像部２３ａおよび外側右撮像部２３ｂの撮像方向は、いずれも外側面２１Ｄの外向きの法線方向である。また、外側左撮像部２３ａおよび外側右撮像部２３ｂは、いずれも、上側ＬＣＤ２２の表示面（内側面）の法線方向と１８０度反対の方向に設計される。すなわち、外側左撮像部２３ａの撮像方向および外側右撮像部２３ｂの撮像方向は、平行である。外側左撮像部２３ａと外側右撮像部２３ｂとは、ゲーム装置１０が実行するプログラムによって、ステレオカメラとして使用することが可能である。また、プログラムによっては、２つの外側撮像部（外側左撮像部２３ａおよび外側右撮像部２３ｂ）のいずれか一方を単独で用いて、外側撮像部２３を非ステレオカメラとして使用することも可能である。また、プログラムによっては、２つの外側撮像部（外側左撮像部２３ａおよび外側右撮像部２３ｂ）で撮像した画像を合成してまたは補完的に使用することにより撮像範囲を広げた撮像を行うことも可能である。本実施例では、外側撮像部２３は、外側左撮像部２３ａおよび外側右撮像部２３ｂの２つの撮像部で構成される。外側左撮像部２３ａおよび外側右撮像部２３ｂは、それぞれ所定の共通の解像度を有する撮像素子（例えば、ＣＣＤイメージセンサやＣＭＯＳイメージセンサ等）と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
【００６５】
なお、本実施例においては、外側左撮像部２３ａおよび外側右撮像部２３ｂは、ハウジングに固定されており、撮像方向を変更することはできない。
【００６６】
内側撮像部２４は、上側ハウジング２１の内側面（主面）２１Ｂに設けられ、当該内側面の内向きの法線方向を撮像方向とする撮像部である。内側撮像部２４は、所定の解像度を有する撮像素子（例えば、ＣＣＤイメージセンサやＣＭＯＳイメージセンサ等）と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
【００６７】
図１に示すように、内側撮像部２４は、上側ハウジング２１を開いた状態において、上側ハウジング２１の上部であって、上側ＬＣＤ２２の画面の上端よりも上方に配置され、上側ハウジング２１の左右方向に関して中央の位置（上側ハウジング２１（上側ＬＣＤ２２の画面）を左右に２等分する線の線上）に配置される。具体的には、図１に示されるように、内側撮像部２４は、上側ハウジング２１の内側面であって、外側左撮像部２３ａおよび外側右撮像部２３ｂの中間の裏側の位置に配置される。このように、内側撮像部２４は、外側撮像部２３とは反対方向を撮像するので、ゲーム装置１０を把持しているユーザの顔を正面から撮像することも可能である。
【００６８】
３Ｄ調整スイッチ２５は、スライドスイッチであり、上述のように上側ＬＣＤ２２の表示モードを切り替えるために用いられるスイッチである。また、３Ｄ調整スイッチ２５は、上側ＬＣＤ２２に表示された立体視可能な画像（立体画像）の立体感を調整するために用いられる。図１に示されるように、３Ｄ調整スイッチ２５は、上側ハウジング２１の内側面および右側面の端部に設けられ、ユーザが上側ＬＣＤ２２を正視した場合に、当該３Ｄ調整スイッチ２５を視認できる位置に設けられる。３Ｄ調整スイッチ２５は、所定方向（例えば、上下方向）の任意の位置にスライド可能なスライダを有しており、当該スライダの位置に応じて上側ＬＣＤ２２の表示モードが設定される。
【００６９】
例えば、３Ｄ調整スイッチ２５のスライダが最下点位置に配置されている場合、上側ＬＣＤ２２が平面表示モードに設定され、上側ＬＣＤ２２の画面には平面画像が表示される。一方、上記最下点位置より上側にスライダが配置されている場合、上側ＬＣＤ２２は立体表示モードに設定される。この場合、上側ＬＣＤ２２の画面には立体視可能な画像が表示される。ここで、スライダが上記最下点位置より上側に配置されている場合、スライダの位置に応じて、立体画像の見え方が調整される。具体的には、スライダの位置に応じて、右目用画像および左目用画像における横方向の位置のずれ量が調整される。
【００７０】
３Ｄインジケータ２６は、上側ＬＣＤ２２が立体表示モードか否かを示す。例えば、３Ｄインジケータ２６は、ＬＥＤであり、上側ＬＣＤ２２の立体表示モードが有効の場合に点灯する。図１に示されるように、３Ｄインジケータ２６は、上側ハウジング２１の内側面に設けられ、上側ＬＣＤ２２の画面近傍に設けられる。このため、ユーザが上側ＬＣＤ２２の画面を正視した場合、ユーザは３Ｄインジケータ２６を視認しやすい。従って、ユーザは、上側ＬＣＤ２２の画面を視認している状態でも、上側ＬＣＤ２２の表示モードを容易に認識することができる。
【００７１】
また、上側ハウジング２１の内側面には、スピーカ孔２１Ｅが設けられる。後述するスピーカ４４からの音声がこのスピーカ孔２１Ｅから出力される。
【００７２】
［ゲーム装置の内部構成］
次に、図２を参照して、ゲーム装置１０の内部構成を説明する。なお、図２は、ゲーム装置１０の内部構成の一例を示すブロック図である。
【００７３】
図２において、ゲーム装置１０は、上述した各構成部に加えて、情報処理部３１、メインメモリ３２、外部メモリインターフェイス（外部メモリＩ／Ｆ）３３、データ保存用外部メモリＩ／Ｆ３４、データ保存用内部メモリ３５、無線通信モジュール３６、ローカル通信モジュール３７、リアルタイムクロック（ＲＴＣ）３８、加速度センサ３９、角速度センサ４０、電源回路４１、およびインターフェイス回路（Ｉ／Ｆ回路）４２等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて下側ハウジング１１（または上側ハウジング２１でもよい）内に収納される。
【００７４】
情報処理部３１は、所定のプログラムを実行するためのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１１、画像処理を行うＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１２等を含む情報処理手段である。本実施例では、所定のプログラムがゲーム装置１０内のメモリ（例えば外部メモリＩ／Ｆ３３に接続された外部メモリ４５やデータ保存用内部メモリ３５）に記憶されている。情報処理部３１のＣＰＵ３１１は、当該所定のプログラムを実行することによって、後述する情報処理などを実行する。なお、情報処理部３１のＣＰＵ３１１によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。情報処理部３１は、ＶＲＡＭ（Ｖｉｄｅｏ ＲＡＭ）３１３を含む。情報処理部３１のＧＰＵ３１２は、情報処理部３１のＣＰＵ３１１からの命令に応じて画像を生成し、ＶＲＡＭ３１３に描画する。そして、情報処理部３１のＧＰＵ３１２は、ＶＲＡＭ３１３に描画された画像を上側ＬＣＤ２２および／または下側ＬＣＤ１２に出力し、上側ＬＣＤ２２および／または下側ＬＣＤ１２に当該画像が表示される。
【００７５】
情報処理部３１には、メインメモリ３２、外部メモリＩ／Ｆ３３、データ保存用外部メモリＩ／Ｆ３４、およびデータ保存用内部メモリ３５が接続される。外部メモリＩ／Ｆ３３は、外部メモリ４５を着脱自在に接続するためのインターフェイスである。また、データ保存用外部メモリＩ／Ｆ３４は、データ保存用外部メモリ４６を着脱自在に接続するためのインターフェイスである。
【００７６】
メインメモリ３２は、情報処理部３１（ＣＰＵ３１１）のワーク領域やバッファ領域として用いられる揮発性の記憶手段である。すなわち、メインメモリ３２は、画像処理やゲーム処理で用いられる各種データを一時的に記憶したり、外部（外部メモリ４５や他の機器等）から取得されるプログラムを一時的に記憶したりする。本実施例では、メインメモリ３２として例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。
【００７７】
外部メモリ４５は、情報処理部３１によって実行されるプログラムを記憶するための不揮発性の記憶手段である。外部メモリ４５は、例えば読み取り専用の半導体メモリで構成される。外部メモリ４５が外部メモリＩ／Ｆ３３に接続されると、情報処理部３１は外部メモリ４５に記憶されたプログラムを読み込むことができる。情報処理部３１が読み込んだプログラムを実行することにより、所定の処理が行われる。データ保存用外部メモリ４６は、不揮発性の読み書き可能なメモリ（例えばＮＡＮＤ型フラッシュメモリ）で構成され、所定のデータを格納するために用いられる。例えば、データ保存用外部メモリ４６に外側撮像部２３で撮像された画像や他の機器で撮像された画像が記憶される。データ保存用外部メモリ４６がデータ保存用外部メモリＩ／Ｆ３４に接続されると、情報処理部３１はデータ保存用外部メモリ４６に記憶された画像を読み込み、上側ＬＣＤ２２および／または下側ＬＣＤ１２に当該画像を表示することができる。
【００７８】
データ保存用内部メモリ３５は、読み書き可能な不揮発性メモリ（例えばＮＡＮＤ型フラッシュメモリ）で構成され、所定のデータを格納するために用いられる。例えば、データ保存用内部メモリ３５には、無線通信モジュール３６を介した無線通信によってダウンロードされたデータやプログラムが格納される。
【００７９】
無線通信モジュール３６は、例えばＩＥＥＥ８０２．１１ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール３７は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール３６およびローカル通信モジュール３７は、情報処理部３１に接続される。情報処理部３１は、無線通信モジュール３６を用いてインターネットを介して他の機器との間でデータを送受信したり、ローカル通信モジュール３７を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。
【００８０】
ローカル通信モジュール３７は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。ここで、ローカル通信モジュール３７は、この無線通信で使用する電波は例えば無線局の免許が不要な程の微弱電波であり、例えばデータ伝送距離が１０ｍの範囲内の近距離無線通信を行う。従って、情報処理部３１は、他のゲーム装置１０の通信可能範囲内（例えば、両機間の距離が１０ｍ以内）に位置するときに、ローカル通信モジュール３７を用いて当該他のゲーム装置１０とデータを送受信することができる。このデータの送受信は、ユーザの選択に応じて、所定周期毎に自動的に繰り返し行われる場合がある。すなわち、情報処理部３１は、前述の近距離無線通信が可能な範囲内に存在する他のゲーム装置１０を検出して、検出の結果見つかったゲーム装置１０との間で自動的に通信を開始しデータを送受信する。そして、当該通信が完了した後で自動的に通信の切断を行う。本実施例では、このように自動的に通信を開始してから完了するまでの処理が所定周期毎に繰り返し行われる。この通信を以下「すれ違い通信」と記載し、すれ違い通信のための処理を以下「すれ違い通信処理」と記載する。
【００８１】
すれ違い通信処理は、通信を行う複数のゲーム装置１０が電源オンされているときに常に実行される。すなわち、複数のゲーム装置１０がスリープモードに設定されているときだけでなくアプリケーションが実行されているときにも行われる。なお、スリープモードとは、省電力モードのことであり、ゲーム装置１０における一部の機能（例えば、情報処理部３１の一部の機能、ディスプレイの一部の機能等）が停止している状態である。例えば、ＣＰＵ３１１が停止することでアプリケーションの実行をしない状態もスリープモードに該当する。
【００８２】
情報処理部３１には、加速度センサ３９が接続される。加速度センサ３９は、３軸（本実施例では、ｘｙｚ軸）方向に沿った直線方向の加速度（直線加速度）の大きさを検出する。加速度センサ３９は、例えば下側ハウジング１１の内部に設けられる。加速度センサ３９は、図１に示すように、下側ハウジング１１の長辺方向をｘ軸、下側ハウジング１１の短辺方向をｙ軸、下側ハウジング１１の内側面（主面）に対して垂直な方向をｚ軸として、ゲーム装置１０の各軸方向へ生じる直線加速度の大きさをそれぞれ検出する。なお、加速度センサ３９は、例えば静電容量式の加速度センサとするが、他の方式の加速度センサを用いるようにしてもよい。また、加速度センサ３９は１軸または２軸方向を検出する加速度センサであってもよい。情報処理部３１は、加速度センサ３９が検出した加速度を示すデータ（加速度データ）を受信して、ゲーム装置１０の姿勢や動きを算出する。
【００８３】
情報処理部３１には、角速度センサ４０が接続される。角速度センサ４０は、ゲーム装置１０の３軸（本実施例では、ｘｙｚ軸）周りに生じる角速度をそれぞれ検出し、検出した角速度を示すデータ（角速度データ）を情報処理部３１へ出力する。角速度センサ４０は、例えば下側ハウジング１１の内部に設けられる。情報処理部３１は、角速度センサ４０から出力された角速度データを受信して、ゲーム装置１０の姿勢や動きを算出する。
【００８４】
情報処理部３１には、ＲＴＣ３８および電源回路４１が接続される。ＲＴＣ３８は、時間をカウントして情報処理部３１に出力する。情報処理部３１は、ＲＴＣ３８によって計時された時間に基づき現在時刻（日付）を計算する。電源回路４１は、ゲーム装置１０が有する電源（下側ハウジング１１に収納される上記充電式電池）からの電力を制御し、ゲーム装置１０の各部品に電力を供給する。
【００８５】
情報処理部３１には、Ｉ／Ｆ回路４２が接続される。Ｉ／Ｆ回路４２には、マイク４３、スピーカ４４、およびタッチパネル１３が接続される。具体的には、Ｉ／Ｆ回路４２には、図示しないアンプを介してスピーカ４４が接続される。マイク４３は、ユーザの音声を検知して音声信号をＩ／Ｆ回路４２に出力する。アンプは、Ｉ／Ｆ回路４２からの音声信号を増幅し、音声をスピーカ４４から出力させる。Ｉ／Ｆ回路４２は、マイク４３およびスピーカ４４（アンプ）の制御を行う音声制御回路と、タッチパネル１３の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル１３からの信号に基づいて所定の形式のタッチ位置データを生成して情報処理部３１に出力する。タッチ位置データは、タッチパネル１３の入力面において入力が行われた位置（タッチ位置）の座標を示す。なお、タッチパネル制御回路は、タッチパネル１３からの信号の読み込み、およびタッチ位置データの生成を所定時間に１回の割合で行う。情報処理部３１は、タッチ位置データを取得することにより、タッチパネル１３に対して入力が行われたタッチ位置を知ることができる。
【００８６】
操作ボタン１４は、上記各操作ボタン１４Ａ〜１４Ｌからなり、情報処理部３１に接続される。操作ボタン１４から情報処理部３１へは、各操作ボタン１４Ａ〜１４Ｉに対する入力状況（押下されたか否か）を示す操作データが出力される。情報処理部３１は、操作ボタン１４から操作データを取得することによって、操作ボタン１４に対する入力に応じた処理を実行する。
【００８７】
下側ＬＣＤ１２および上側ＬＣＤ２２は、情報処理部３１に接続される。下側ＬＣＤ１２および上側ＬＣＤ２２は、情報処理部３１（ＧＰＵ３１２）の指示に従って画像を表示する。本実施例では、情報処理部３１は、後述するユーザ作成データに含まれるキャラクタなどのコンテンツを下側ＬＣＤ１２及び／又は上側ＬＣＤ２２に表示させる。また、情報処理部３１は、上側ＬＣＤ２２に外側撮像部２３で撮像した右目用画像と左目用画像とを用いた立体画像（立体視可能な画像）を表示させたり、内側撮像部２４で撮像した平面画像を上側ＬＣＤ２２に表示させたり、上側ＬＣＤ２２に外側撮像部２３で撮像した右目用画像および左目用画像の一方を用いた平面画像を表示させたりすることも可能である。
【００８８】
具体的には、情報処理部３１は、上側ＬＣＤ２２のＬＣＤコントローラ（図示せず）と接続され、当該ＬＣＤコントローラに対して視差バリアのＯＮ／ＯＦＦを制御する。上側ＬＣＤ２２の視差バリアがＯＮになっている場合、情報処理部３１のＶＲＡＭ３１３に格納された（外側撮像部２３で撮像された）右目用画像と左目用画像とが、上側ＬＣＤ２２に出力される。より具体的には、ＬＣＤコントローラは、右目用画像について縦方向に１ライン分の画素データを読み出す処理と、左目用画像について縦方向に１ライン分の画素データを読み出す処理とを交互に繰り返すことによって、ＶＲＡＭ３１３から右目用画像と左目用画像とを読み出す。これにより、右目用画像および左目用画像が、画素を縦に１ライン毎に並んだ短冊状画像に分割され、分割された右目用画像の短冊状画像と左目用画像の短冊状画像とが交互に配置された画像が、上側ＬＣＤ２２の画面に表示される。そして、上側ＬＣＤ２２の視差バリアを介して当該画像がユーザに視認されることによって、ユーザの右目に右目用画像が、ユーザの左目に左目用画像が視認される。以上により、上側ＬＣＤ２２の画面には立体視可能な画像が表示される。
【００８９】
外側撮像部２３および内側撮像部２４は、情報処理部３１に接続される。外側撮像部２３および内側撮像部２４は、情報処理部３１の指示に従って画像を撮像し、撮像した画像データを情報処理部３１に出力する。本実施例では、情報処理部３１は、外側撮像部２３および内側撮像部２４のいずれか一方に対して撮像指示を行い、撮像指示を受けた撮像部が画像を撮像して画像データを情報処理部３１に送る。具体的には、ユーザによるタッチパネル１３や操作ボタン１４を用いた操作によって使用する撮像部が選択される。そして、撮像部が選択されたことを情報処理部３１（ＣＰＵ３１１）が検知し、情報処理部３１が外側撮像部２３または内側撮像部２４に対して撮像指示を行う。
【００９０】
３Ｄ調整スイッチ２５は、情報処理部３１に接続される。３Ｄ調整スイッチ２５は、スライダの位置に応じた電気信号を情報処理部３１に送信する。
【００９１】
３Ｄインジケータ２６は、情報処理部３１に接続される。情報処理部３１は、３Ｄインジケータ２６の点灯を制御する。例えば、情報処理部３１は、上側ＬＣＤ２２が立体表示モードである場合、３Ｄインジケータ２６を点灯させる。
【００９２】
［ネットワーク構成］
次に、図３を参照して、本実施例におけるネットワーク構成について説明する。なお、図３は、本実施例におけるネットワーク構成を示す図である。
【００９３】
図３において、本実施例におけるネットワークは、ゲーム装置１０、アクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ。以下、ＡＰと称する）２、インターネット通信網３およびサーバ５からなる。より詳細には、本実施例におけるネットワークは、上述したようにローカル通信モジュール３７を用いて互いに近距離無線通信が可能なゲーム装置１０と、これらのゲーム装置１０と無線通信モジュール３６を用いて無線通信が可能なＡＰ２と、ＡＰ２およびインターネット通信網３を介してゲーム装置１０のそれぞれと通信可能なサーバ５からなる。
【００９４】
ＡＰ２は、従来周知のアクセスポイントである。ＡＰ２は、それぞれがインターネット通信網３に接続されている。ゲーム装置１０は、その無線通信モジュール３６の通信範囲内に位置するＡＰ２を介してインターネット通信網３に接続された種々の通信端末と通信することができる。本実施例におけるＡＰ２は、例えば、ゲーム装置１０の製造元が管理するＡＰ、ユーザの個人宅に設置されたＡＰおよび当該製造元以外の事業者などが設置したＡＰなどが該当する。
【００９５】
サーバ５は、インターネット通信網３に接続されており、同じくインターネット通信網３に接続されているＡＰ２を通してそれぞれのゲーム装置１０と通信可能である。図４は、サーバ５の内部構成の一例を示す図である。
【００９６】
サーバ５は、ＣＰＵ５１、操作検出部５２、通信部５３、ＨＤＤ５４、メインメモリ５５とからなり、これらは通信バス５６で互いに通信可能に接続されている。
【００９７】
ＣＰＵ５１は、メインメモリ５５に格納された各種プログラムに従って処理をする。操作検出部５２は、サーバ５の入力装置（例えば、キーボードなど）に対するユーザ（例えば、サーバ管理者）の操作を検出する。通信部５３は、インターネット通信網３を通して、同じくインターネット通信網３に接続されている種々の通信装置と通信する。ＨＤＤ５４は、従来周知のハードディスクドライブであって、ＣＰＵ５１が実行する各種プログラムが格納されている。メインメモリ５５は、ＣＰＵ５１が処理を開始するときにＨＤＤ５４から読み出された各種プログラムが格納される。なお、詳細は後述するが、メインメモリ５５には、後述するグローバルブラックリスト（Ｇｌｏｂａｌ Ｂｌａｃｋ Ｌｉｓｔ。以下、ＧＢＬと称する）が格納されており、通信部５３およびインターネット通信網３を通してゲーム装置１０によってダウンロードされる。ゲーム装置１０は、サーバ５からダウンロードしたＧＢＬに基づいて処理をする。また、サーバ５は一方のユーザから他方のユーザへ送信されるデータを受け付けて一時的に保存する機能なども有している。ここで、サーバ５が受け付けるデータには後述するキャラクタを示すユーザ作成データなどが一例として挙げられる。
【００９８】
本発明では、任意のユーザがゲーム装置１０を用いて自由に作成したデータ（以下、ユーザ作成データと称する）が、不特定多数のゲーム装置１０同士で送受信されるものとする。ユーザ作成データがゲーム装置１０同士で送受信される場合には、ユーザによる選択に応じて、即座に送受信される場合と、すれ違い通信または後述するインターネット通信において通信可能なタイミングが到来したときに自動的に送受信される場合とがある。そして、本発明は、他のゲーム装置１０から受信したデータの内、表示するのに不適切な内容を示すユーザ作成データを非表示データとし、その内容を表示しないようにする。
【００９９】
ユーザ作成データの一例としては、ユーザによって自由に作成されたキャラクタを示すデータが挙げられる。図５は、キャラクタを取り扱うアプリケーション（以下、キャラクタ取り扱いアプリケーションと称する）の実行中において、キャラクタを作成する画面が表示されているゲーム装置１０の一例を示す図である。図５において、下側ＬＣＤ１２には、キャラクタを構成するパーツを選択する画面として、口のパーツを候補の中から選択する画面が表示されている。また、図５において、上側ＬＣＤ２２には、既に選択された各パーツで構成されたキャラクタが表示されている。本実施例では、図５に一例として示すように、ユーザが、キャラクタを構成する各パーツ（目、鼻、口、髪および種々の体型の体など）を、それぞれの候補の中から、上述したゲーム装置１０の入力装置を用いて選択することによって、キャラクタを作成することができるものとする。そして、本実施例では、それぞれのユーザによって作成されたキャラクタを示すユーザ作成データが、不特定多数のゲーム装置１０同士で送受信されるものとする。
【０１００】
上述したようにユーザは、キャラクタを自由に作成することができる。従って、ユーザは、例えば、過去に存在した犯罪者を模したキャラクタなどの道徳上の観点から好ましくない内容を示すデータを、ユーザ作成データとして作成することも可能である。そして、このように道徳上の観点から好ましくない内容を示すデータも、上述したように不特定多数のゲーム装置１０同士で送受信される。そして、受信されたユーザ作成データは、当該データを受信したゲーム装置１０において事前に特定しない限りユーザにその内容が表示されてしまう。
【０１０１】
そこで、本発明では、このように道徳上の観点から好ましくない内容を示すユーザ作成データを受信したとしても非表示データとして表示しないようにする。本発明では、受信したデータの中から非表示データを特定するために、上述したＧＢＬおよびローカルブラックリスト（Ｌｏｃａｌ Ｂｌａｃｋ Ｌｉｓｔ。以下、ＬＢＬと称する）を用いる。以下、本発明に係る情報処理システムの概略を説明する。
【０１０２】
図６は、本発明に係る情報処理システム（以下、単に本システムと称する）の概略を説明するための図である。図６には、ゲーム装置Ａ〜ゲーム装置Ｄの４台のゲーム装置１０と、サーバ５とが示されている。また、図６には、本システムにおける動作に時系列に従った順番（Ｉ）〜（Ｘ）を付している。
【０１０３】
図６において、例えば、ゲーム装置Ａのユーザがユーザ作成データを作成したとする（以下、このデータをユーザ作成データａと称する）。そして、ユーザ作成データａが、すれ違い通信によってゲーム装置Ａからゲーム装置Ｂに送信されたとする（図６の（Ｉ））。ここで、ゲーム装置Ｂのユーザが、受信したユーザ作成データａによって示されるキャラクタを道徳上の観点から好ましくないと感じたとする。この場合、本システムにおいて、ゲーム装置Ｂのユーザは、ゲーム装置Ｂに格納されているＬＢＬにユーザ作成データａを登録することができる。ＬＢＬは、それぞれのゲーム装置１０に格納されており、それぞれのユーザは任意のユーザ作成データを登録できる（図６の（ＩＩ））。ＬＢＬに登録されたユーザ作成データによって示されるキャラクタは、登録後に同じデータを受信したとしても表示されなくなる。なお、本システムでは、一例として、ＬＢＬがゲーム装置１０同士で送受信されることはない。
【０１０４】
また、本システムでは、ゲーム装置Ｂのユーザがユーザ作成データａを特定するための情報（ＩＤ）などを非表示データとしてＬＢＬに登録することが可能であると共に、当該ユーザ作成データａをサーバ５に通報することも可能である。ここでは、ゲーム装置Ｂのユーザが、ユーザ作成データａをＬＢＬに登録すると共にサーバ５に通報したものとする（図６の（ＩＩＩ））。サーバ５は、上述したようにＧＢＬを管理しており、不特定多数のゲーム装置１０からインターネット通信網３を用いて通報を受け付ける。サーバ５は、通報を受けたユーザ作成データの中で所定の条件を満たすユーザ作成データを非表示データとしてＧＢＬに登録する。ここでは、ゲーム装置Ｂのユーザによってユーザ作成データａが通報されたことにより、当該ユーザ作成データａがＧＢＬに登録されたものとする（図６の（ＩＶ））。後に詳述するが、ユーザ作成データがＧＢＬに登録されるときには、上述したように通報されるときに送信される当該ユーザ作成データに含まれるユーザＩＤやデータＩＤなどがＧＢＬに登録されることとなる。それぞれのゲーム装置１０は、それぞれの所定の周期で、サーバ５で管理されているＧＢＬをダウンロードし、格納しているＧＢＬを必要に応じて更新する。ここでは、ゲーム装置Ｃが、サーバ５からＧＢＬをダウンロードして更新したものとする（図６の（Ｖ））。これにより、ゲーム装置Ｃでは、ユーザ作成データａが非表示データとして特定される。従って、ゲーム装置Ｃでユーザ作成データａが受信されたとしても、当該ユーザ作成データａで示されるキャラクタは表示されない（図６の（ＶＩＩ））。これにより、ゲーム装置Ｃのユーザは、道徳上の観点から好ましくないキャラクタを見ずに済む。
【０１０５】
また、ＧＢＬは、ＬＢＬと異なり、ゲーム装置１０同士ですれ違い通信によって送受信され、必要に応じて更新される。ここでは、ゲーム装置Ｃに格納されたＧＢＬが、すれ違い通信によってゲーム装置Ｄに送信されたものとする（図６の（ＶＩＩＩ））。ゲーム装置Ｄは、すれ違い通信によって受信したＧＢＬで、既に格納されているＧＢＬを更新する。このように、ゲーム装置Ｄは、例えば、インターネット通信網３に接続できず、サーバ５からＧＢＬをダウンロードできなかったとしても、他のゲーム装置ＣからＧＢＬを受信して更新することができる。そして、ゲーム装置Ｄが、すれ違い通信によってユーザ生成データａを受信したとしても（図６の（ＩＸ））、ゲーム装置Ｄでは非表示データとして特定される。従って、ゲーム装置Ｄには、ユーザ生成データａで示されるキャラクタが表示されない（図５の（Ｘ））。このように、本システムでは、ゲーム装置Ｄがサーバ５と通信できなかったとしても、ゲーム装置Ｄのユーザは、道徳上の観点から好ましくないキャラクタを見ずに済む。
【０１０６】
以上で説明したように、本システムでは、それぞれのゲーム装置１０がＬＢＬを格納しており、それぞれのユーザは受信したユーザ作成データの中から任意のデータを登録することができる。また、それぞれのユーザは、上述したように自身が好ましくないと感じたユーザ作成データをサーバ５に通報することができる。サーバ５は、それぞれのユーザから通報された回数を管理し、通報回数が所定の閾値を超えたユーザ作成データを所定の条件を満たすデータとしてＧＢＬに登録して更新する。また、上述したようにサーバ５によって管理されているＧＢＬは、それぞれのゲーム装置１０によってそれぞれの所定の周期でダウンロードされる。そして、それぞれのゲーム装置１０は、格納しているＧＢＬをダウンロードしたＧＢＬで必要に応じて更新する。従って、それぞれのゲーム装置１０に格納されているＧＢＬは、常に最新の非表示データを示す情報となる。さらに、ゲーム装置１０によって受信されたＧＢＬは、すれ違い通信によって交換することができる。従って、サーバ５からＧＢＬをダウンロードできないゲーム装置１０であっても、他のゲーム装置１０と通信可能であればＧＢＬを受信して更新することができる。そして、それぞれのゲーム装置１０がＧＢＬを格納することにより、未だに受信していないユーザ作成データであっても、非表示データとして特定されれば事前に表示しないようにできる。以上が、本システムの概要の説明である。
【０１０７】
［各種データの説明］
次に、ゲーム装置１０およびサーバ５でそれぞれ行われる処理を具体的に説明する前に、図７Ａ〜図７Ｆを参照して、それぞれにおいて用いられるデータについて説明する。なお、図７Ａは、ゲーム装置１０に電源が投入されることに応じてメインメモリ３２に格納されるデータ及び各種プログラムを示す。また、図７Ｂは、図７Ａに示すユーザ作成データＵｄのより詳細なデータの構成を示す。また、図７Ｃは、図７Ａに示すタスクデータＴｄのより詳細なデータの構成を示す。また、図７Ｄは、図７Ａに示すＬＢＬデータＬｄのより詳細なデータの構成を示す。また、図７Ｅは、図７Ａに示すＧＢＬデータＧｄのより詳細なデータの構成を示す。また、図７Ｆは、サーバ５が各種プログラムを実行することに応じてメインメモリ５５に格納されるデータを示す。
【０１０８】
［ゲーム装置１０に格納されるデータ］
まず、図７Ａ〜図７Ｅを参照して、ゲーム装置１０のメインメモリ３２に格納されるデータおよび各種プログラムについて説明する。ゲーム装置１０のメインメモリ３２には、図７Ａに示すように、ユーザ作成データＵｄ、タスクデータＴｄ、ＬＢＬデータＬｄ、ＧＢＬデータＧｄ、ネット受信ＧＢＬデータＮｇｄ、すれ違いボックスデータＴｂおよび各種プログラムＰａが格納される。
【０１０９】
ユーザ作成データＵｄは、任意のアプリケーションを用いてユーザが作成したデータである。本実施例では、任意のアプリケーションの一例として、キャラクタ取り扱いアプリケーションを挙げている。従って、本実施例におけるユーザ作成データＵｄは、キャラクタ取り扱いアプリケーションで取り扱われるキャラクタを示すデータとなる。ユーザ作成データＵｄは、図７Ｂに示すように、ユーザＩＤとデータＩＤとアプリＩＤとデータ本文とからなる。以下、ユーザ作成データＵｄに含まれるそれぞれのデータについて説明する。
【０１１０】
ユーザＩＤは、ユーザ作成データＵｄによって示されるキャラクタを新たに作成したユーザおよび既存のキャラクタを変更したユーザを示すデータである。具体的には、ユーザＩＤには、作成者ＩＤと変更者ＩＤとが含まれる。作成者ＩＤは、キャラクタを新たに作成したユーザを示すＩＤである。作成者ＩＤは、例えば、ユーザがキャラクタを新たに作成するのに使用したゲーム装置１０を識別するための固有の識別子など、キャラクタを新たに作成したユーザを特定できる情報であれば任意の情報であってよい。なお、作成者ＩＤは、キャラクタを新たに作成したユーザのＩＤを示すので、作成者ＩＤが更新されることはない。
【０１１１】
変更者ＩＤは、既存のキャラクタを変更したユーザを示すＩＤである。変更者ＩＤは、例えば、ユーザが既存のキャラクタを変更するのに使用したゲーム装置１０を識別するための固有の識別子など、既存のキャラクタを変更したユーザを特定できる情報であれば任意の情報であってよい。変更者ＩＤは、既存のキャラクタが変更される度にユーザＩＤに追加される。
【０１１２】
データ本文は、ユーザ作成データＵｄによって示されるデータの内容（コンテンツ）そのものである。ユーザ作成データＵｄは、上述したように任意のアプリケーションを用いて生成されたデータである。そして、ユーザ作成データＵｄがキャラクタ取り扱いアプリケーションにおいて取り扱われるキャラクタを示す場合、データ本文は当該キャラクタを構成する各パーツの形状や色を示すデータとなる。データ本文で示される形状のキャラクタが、当該データ本文を含むユーザ作成データＵｄによって示されるキャラクタとなる。
【０１１３】
アプリＩＤは、当該アプリＩＤを含むユーザ作成データＵｄを取り扱うアプリケーションを一意に識別するためのＩＤである。すなわち、ユーザ作成データＵｄの作成や変更に用いられたアプリケーションを示すＩＤである。本実施例では、キャラクタ取り扱いアプリケーションを示すＩＤがアプリＩＤとなる。なお、アプリＩＤは、ユーザ作成データＵｄを取り扱うアプリケーションが同一であれば、当該ユーザ作成データＵｄが異なるゲーム装置１０に格納されていたとしても同一のＩＤとなる。
【０１１４】
データＩＤは、前述のデータ本文をアプリケーション毎に一意に識別するためのＩＤである。従って、ユーザ作成データＵｄを取り扱うアプリケーションが同一であれば、当該ユーザ作成データＵｄを格納しているゲーム装置１０が異なっていても、データＩＤは重複しない。一方で、データＩＤは、同一のゲーム装置１０に格納されていたとしても、取り扱うアプリケーションが異なれば、同一のＩＤとなる場合もある。
【０１１５】
以上がユーザ作成データＵｄに含まれるそれぞれのデータの説明である。なお、図７Ａには、１つのユーザ作成データＵｄがメインメモリ３２に格納されている一例を示している。しかしながら、メインメモリ３２には、新たなユーザ作成データＵｄが生成される或いは既存のユーザ作成データＵｄが読み込まれることにより、１以上のユーザ作成データＵｄが格納される。
【０１１６】
新たなユーザ作成データＵｄは、ユーザがキャラクタ取り扱いアプリケーションを使用してキャラクタを新たに作成したときにメインメモリ３２に生成される。新たなユーザ作成データＵｄは、ユーザがキャラクタを新たに作成する度にメインメモリ３２に追加される。そして、ユーザがキャラクタの作成を終え、キャラクタ取り扱いアプリケーションを終了すると、メインメモリ３２に生成されたユーザ作成データＵｄがデータ保存用外部メモリ４６に格納される。データ保存用外部メモリ４６に格納された既存のユーザ作成データＵｄは、ユーザがキャラクタ取り扱いアプリケーションをゲーム装置１０に実行させたときに読み出されメインメモリ３２に格納される。このとき、データ保存用外部メモリ４６に１以上のユーザ作成データＵｄが格納されていれば、１以上のユーザ作成データＵｄがメインメモリ３２に格納されることになる。
【０１１７】
次に、タスクデータＴｄについて説明する。タスクデータＴｄは、インターネット通信を用いたデータの受信または送信をタスクとして示すデータである。タスクは当該タスクを生成したアプリケーションが実行中であるか否かに関わらずに、ＣＰＵ３１１によって実行される。本実施例におけるタスクは、ＣＰＵ３１１によって設定された時刻に実行されるタスクであるものとする。なお、他の一実施形態では、ゲーム装置１０において実行可能なタスクとして、ユーザの指示に応じて即座に実行されるタスクや、通信相手となるＡＰ２の管理者を示す情報に応じて実行優先度または実行順序などが変更可能なタスクがあってもよい。
【０１１８】
タスクデータＴｄは、図７Ｃに一例として示すように、アプリＩＤと通信先ＵＲＬと次回実行時刻と送信／受信識別フラグと格納先情報とからなる。
【０１１９】
アプリＩＤは、タスクデータＴｄを生成するのに用いられたアプリケーションを一意に識別するためのＩＤである。通信先ＵＲＬは、データを受信または送信する通信先を示す。次回実行時刻は、タスクデータＴｄで示されるタスクを次に実行する時刻を示す。送信／受信識別フラグは、当該フラグを含むタスクデータＴｄで示されるタスクが、受信のタスクであるか送信のタスクであるかを示す情報である。格納先情報は、タスクデータＴｄで示されるタスクで取り扱うデータの格納先を示す情報である。より具体的には、タスクデータＴｄで示されるタスクが送信タスクである場合には、格納先情報は、送信するデータのゲーム装置１０における格納領域を示す情報となる。一方、タスクデータＴｄで示されるタスクが受信タスクである場合には、格納先情報は、受信したデータのゲーム装置１０における格納領域を示す情報となる。
【０１２０】
本実施例において、タスクデータＴｄによって示されるタスクとしては、キャラクタを通報するタスク、キャラクタを受信するタスク、キャラクタを送信するタスクおよび配信用ＧＢＬデータＧｓｄを受信するタスクが一例として挙げられる。
【０１２１】
まず、キャラクタを通報するためのタスクデータＴｄについて説明する。キャラクタを通報するためのタスクデータＴｄは、後述するように、ＬＢＬ登録処理においてユーザによって通報が選択されたときに生成される。ＬＢＬ登録処理はキャラクタ取り扱いアプリケーションにおいて実行される。従って、キャラクタを通報するためのタスクデータＴｄには、キャラクタ取り扱いアプリケーションを一意に識別するアプリＩＤが含まれる。また、キャラクタを通報するためのタスクデータＴｄには、通報先がサーバ５として予め定められているため、通信先ＵＲＬとして、サーバ５のＵＲＬが含まれる。また、キャラクタを通報するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、キャラクタを通報するためのタスクデータＴｄは、通報するときにキャラクタを示すユーザ作成データＵｄを送信するので送信を示す送信／受信識別フラグを含む。また、キャラクタを通報するためのタスクデータＴｄには、当該キャラクタを示すユーザ作成データＵｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２２】
次に、キャラクタを受信するためのタスクデータＴｄについて説明する。キャラクタを受信するためのタスクデータＴｄは、後述するように、キャラクタ取り扱い処理において、キャラクタのインターネット通信網３を介した受信がユーザによって選択されたときに生成される。また、キャラクタ取り扱い処理プログラムのインストール時に生成されてもよい。従って、キャラクタを受信するためのタスクデータＴｄには、キャラクタ取り扱いアプリケーションを一意に識別するアプリＩＤが含まれる。また、キャラクタを受信するためのタスクデータＴｄには、自身宛に他人から送信されたキャラクタを一時的に保持しておくためのサーバ５のＵＲＬが通信先ＵＲＬとして含まれる。また、キャラクタを受信するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、キャラクタを受信するためのタスクデータＴｄは、キャラクタを受信するためのタスクを示すので、受信を示す送信／受信識別フラグを含む。また、キャラクタを受信するためのタスクデータＴｄには、新たに受信したキャラクタを示すユーザ作成データＵｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２３】
次に、キャラクタを他人に送信するためのタスクデータＴｄについて説明する。キャラクタを送信するためのタスクデータＴｄは、後述するように、キャラクタ取り扱い処理において、インターネット通信網３を介したキャラクタの送信がユーザによって選択されたときに生成される。従って、キャラクタを送信するためのタスクデータＴｄには、キャラクタ取り扱いアプリケーションを一意に識別するアプリＩＤが含まれる。また、キャラクタを送信するためのタスクデータＴｄには、キャラクタの送信を受け付けるためのサーバ５のＵＲＬが通信先ＵＲＬとして含まれる。また、キャラクタを送信するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、キャラクタを送信するためのタスクデータＴｄは、キャラクタを送信するためのタスクを示すので、送信を示す送信／受信識別フラグを含む。また、キャラクタを送信するためのタスクデータＴｄには、ユーザによって送信するように選択されたキャラクタを示すユーザ作成データＵｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２４】
次に、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄについて説明する。後に詳述するが、ゲーム装置１０は、配信用ＧＢＬデータＧｓｄをサーバ５から定期的に受信してＧＢＬを更新する。すなわち、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄは、キャラクタ取り扱いアプリケーションなどの任意のアプリケーションの実行中に生成されるデータではない。従って、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、例えば、アプリＩＤとして考えられるＩＤ以外のＩＤが例外的にアプリＩＤとして含まれる。例えば、本体のシステムを表すＩＤなどである。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、当該配信用ＧＢＬデータＧｓｄをサーバ５から受信するために、当該サーバ５のＵＲＬが通信先ＵＲＬとして含まれる。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄは、配信用ＧＢＬデータＧｓｄを受信するためのタスクを示すので、受信を示す送信／受信識別フラグを含む。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、インターネット通信網３を用いて受信したネット受信ＧＢＬデータＮｇｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２５】
なお、図７Ａには、１つのタスクデータＴｄが格納されているメインメモリ３２を一例として示している。しかしながら、本実施例におけるタスクには、上述したように種々のタスクがある。そして、これらのタスクはユーザの選択などに応じて複数設定される場合がある。また、未実行のタスクが残っている状態で、同種のタスクが設定される場合もある。このような場合、メインメモリ３２には、設定されたタスクを示す１以上のタスクデータＴｄが格納される。
【０１２６】
また、上述した種々のタスクデータＴｄに含まれる次回実行時刻はＣＰＵ３１１によって設定された次回実行時刻であるものとした。ここで、ＣＰＵ３１１が次回実行時刻を設定するのは、タスクデータＴｄを生成したときおよびタスクを実行して次回実行時刻を更新するときである。ＣＰＵ３１１がタスクデータＴｄを生成したときには、生成した時刻から所定の時間間隔をおいた時刻が次回実行時刻として設定されるものとする。また、ＣＰＵ３１１が次回実行時刻を更新するときには、更新したときから所定の時間間隔をおいた時刻が次回実行時刻として設定されるものとする。なお、他の一実施形態では、ユーザによって設定された時刻に次回実行時刻を更新するようにしてもよい。
【０１２７】
以上が、タスクデータＴｄの説明である。次に、ＬＢＬデータＬｄについて説明する。ＬＢＬデータＬｄは、上述したＬＢＬを示すデータである。より詳細には、ＬＢＬデータＬｄは、他のゲーム装置１０から受信したユーザ作成データＵｄの中から、ＣＰＵ３１１が非表示データを特定するためのＬＢＬを示すデータである。ＣＰＵ３１１がＬＢＬデータＬｄを用いて特定する非表示データは、ユーザによって判断され登録されたキャラクタを示すユーザ作成データＵｄである。
【０１２８】
ＬＢＬデータＬｄは、図７Ｄに示すように、変更者ＬＢＬを示す変更者ＬＢＬデータおよびデータＬＢＬを示すデータＬＢＬデータからなる。また、変更者ＬＢＬデータは、アプリＩＤと変更者ＩＤとを含む変更者特定ＬＢＬデータの集合体である。変更者特定ＬＢＬデータに含まれる変更者ＩＤは、後述するようにユーザによって登録するように選択されたユーザ作成データＵｄの最後の変更者ＩＤである。従って、変更者特定ＬＢＬデータは、ユーザ作成データＵｄを最後に変更した変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるものとして示すデータとなる。そして、変更者ＬＢＬは、ユーザ作成データＵｄを最後に変更した変更者を、道徳上の観点から好ましくないキャラクタを作成するユーザとして示すリストとなる。また、他の一実施形態では、ユーザ作成データの最初の作成者のＩＤを登録するようにしてもよい。
【０１２９】
一方、データＬＢＬデータは、アプリＩＤとデータＩＤとを含むデータ特定ＬＢＬデータの集合体である。データ特定ＬＢＬデータに含まれるデータＩＤは、後述するようにユーザによって登録するように選択されたユーザ作成データＵｄのデータＩＤである。従って、データ特定ＬＢＬデータは、ユーザ作成データＵｄで示されるキャラクタが道徳上の観点から好ましくないキャラクタであることを示すデータとなる。そして、データＬＢＬは、道徳上の観点から好ましくないキャラクタを示すリストとなる。
【０１３０】
なお、図７Ｄには、２つの変更者特定ＬＢＬデータを含む変更者ＬＢＬデータを一例として示している。しかしながら、変更者ＬＢＬデータには、ユーザによって任意に登録された数だけ変更者特定ＬＢＬデータを含めることができる。また、図７Ｄには、２つのデータ特定ＬＢＬデータを含むデータＬＢＬデータを一例として示している。しかしながら、データＬＢＬデータには、ユーザによって任意に登録された数だけデータ特定ＬＢＬデータを含めることができる。
【０１３１】
次に、ＧＢＬデータＧｄについて説明する。ＧＢＬデータＧｄは、上述したＧＢＬを示すデータである。より詳細には、ＧＢＬデータＧｄは、他のゲーム装置１０から受信したユーザ作成データＵｄの中から、ＣＰＵ３１１が非表示データを特定するためのＧＢＬを示すデータである。ＧＢＬデータＧｄは、サーバ５によって管理されている配信用ＧＢＬデータＧｓｄをゲーム装置１０が受信したデータである。後に詳述するが、サーバ５は、ユーザによって通報された通報回数に基づいてＧＢＬに登録するユーザ作成データＵｄを判断する。従って、ＣＰＵ３１１がＧＢＬデータＧｄを用いて特定する非表示データは、サーバ５によって判断されたキャラクタを示すユーザ作成データＵｄとなる。
【０１３２】
ＧＢＬデータＧｄは、図７Ｅに示すように、変更者ＧＢＬを示す変更者ＧＢＬデータおよびデータＧＢＬを示すデータＧＢＬデータからなる。変更者ＧＢＬデータは、アプリＩＤと変更者ＩＤとを含む変更者特定ＧＢＬデータの集合体である。変更者特定ＧＢＬデータに含まれる変更者ＩＤは、後述するようにサーバ５によって判断された変更者ＩＤである。より詳細には、サーバ５はユーザ作成データＵｄの最後の変更者ＩＤの通報回数に基づいて、通報されたユーザ作成データＵｄの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるか否かを判断する。そして、サーバ５に対する通報は、本システムに含まれるゲーム装置１０の全てのユーザのそれぞれの選択に応じて行われる。従って、変更者特定ＧＢＬデータは、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいてサーバ５が判断したユーザを示すデータとなる。そして、変更者ＧＢＬは、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいて、道徳上の観点から好ましくないキャラクタを作成すると判断されたユーザのリストとなる。また、他の一実施形態では、サーバ５は、ユーザ作成データの最初の作成者のＩＤの通報回数に基づいて好ましくないキャラクタを作成するユーザを判断するようにしてもよい。
【０１３３】
なお、変更者特定ＧＢＬデータは、Ｎｕｌｌで示されるアプリＩＤと変更者ＩＤとを含む場合がある。Ｎｕｌｌで示されるアプリＩＤとは、全てのアプリケーションを示すＩＤである。従って、ＮｕｌｌのアプリＩＤと共に変更者特定ＧＢＬデータに含まれている変更者ＩＤを含むユーザ作成データＵｄは、当該ユーザ作成データＵｄを取り扱うアプリケーションに関わらず非表示データに設定される。
【０１３４】
一方、データＧＢＬデータは、アプリＩＤとデータＩＤとを含むデータ特定ＧＢＬデータの集合体である。データ特定ＧＢＬデータに含まれるデータＩＤは、後述するようにサーバ５によって判断された変更者ＩＤである。より詳細には、サーバ５はユーザ作成データＵｄのデータＩＤの通報回数に基づいて、通報されたユーザ作成データＵｄによって示されるキャラクタが道徳上の観点から好ましくないキャラクタであるか否かを判断する。そして、サーバ５に対する通報は、上述したように本システムに含まれるゲーム装置１０の全てのユーザのそれぞれの選択に応じて行われる。従って、データ特定ＧＢＬデータは、変更者特定ＧＢＬデータと同様に、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいてサーバ５が判断したキャラクタを示すデータとなる。そして、データ特定ＧＢＬは、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいて判断された、道徳上の観点から好ましくないキャラクタのリストとなる。
【０１３５】
なお、図７Ｅには、２つの変更者特定ＧＢＬデータを含む変更者ＧＢＬデータを一例として示している。しかしながら、変更者ＧＢＬデータには、サーバ５によって登録された数だけ変更者特定ＧＢＬデータを含めることができる。また、図７Ｅには、２つのデータ特定ＧＢＬデータを含むデータＧＢＬデータを一例として示している。しかしながら、データＧＢＬデータには、サーバ５によって登録された数だけデータ特定ＧＢＬデータを含めることができる。
【０１３６】
次に、ネット受信ＧＢＬデータＮｇｄについて説明する。ネット受信ＧＢＬデータＮｇｄは、上述した送信ＧＢＬデータＳｇｄを受信するタスクが実行されることによって受信されたデータである。後に詳述するが、ネット受信ＧＢＬデータＮｇｄで示されるバージョンがより新しい場合に、メインメモリ３２に格納されているＧＢＬデータＧｄが更新される。
【０１３７】
次に、すれ違いボックスデータＴｂに含まれるデータについて説明する。すれ違いボックスデータＴｂは、すれ違い通信において自動的に送受信するためのデータからなる。具体的には、すれ違いボックスデータＴｂは、受信ボックスデータＪｂと送信ボックスデータＳｂとからなる。
【０１３８】
受信ボックスデータＪｂは、すれ違い通信において自動的に受信されたデータからなる。本実施例におけるすれ違い通信では、図７Ａに示すように、すれ違い受信データＪｄと受信ＧＢＬデータＪｇｄがそれぞれ自動的に受信される。
【０１３９】
すれ違い受信データＪｄは、すれ違い通信において他のゲーム装置１０から自動的に送信されたユーザ作成データＵｄである。また、受信ＧＢＬデータＪｇｄは、すれ違い通信において他のゲーム装置１０から自動的に送信された送信ＧＢＬデータＳｇｄである。従って、受信ＧＢＬデータＪｇｄには上述した例外的なアプリＩＤが含まれている（図示せず）。
【０１４０】
一方、送信ボックスデータＳｂは、すれ違い通信において自動的に送信されるデータからなる。本実施例におけるすれ違い通信では、図７Ａに示すように、すれ違い送信データＳｄと送信ＧＢＬデータＳｇｄがそれぞれ自動的に送信される。
【０１４１】
すれ違い送信データＪｄは、すれ違い通信をする他のゲーム装置１０に自動的に送信されるユーザ作成データＵｄである。また、送信ＧＢＬデータＳｇｄは、すれ違い通信をする他のゲーム装置１０に自動的に送信されるＧＢＬデータＧｄである。従って、送信ＧＢＬデータＳｇｄにも上述した例外的なアプリＩＤが含まれている（図示せず）。
【０１４２】
以上が、すれ違いボックスデータＴｂに含まれるデータの説明である。なお、図７Ａには、一例として、すれ違い送信データＳｄを１つだけ含む送信ボックスデータＳｂを示している。しかし、後述で明らかとなるが、送信ボックスデータＳｂにはすれ違い通信での送信が選択されたキャラクタの数だけすれ違い送信データＳｄが含まれることとなる。また、他の一実施形態では、同一アプリ間ですれ違い通信によって交換されるデータは１つのすれ違い送信データＪｄにまとめて含めるようにしてもよい。また、図７Ａには、一例として、すれ違い受信データＪｄを１つだけ含む受信ボックスデータＪｂを示している。しかし、後述で明らかとなるが、受信ボックスデータＪｂにはすれ違い通信で他のゲーム装置１０から送信されたすれ違い送信データＳｄの数だけすれ違い受信データＪｄが含まれることとなる。また、他の一実施形態では、同一アプリ間ですれ違い通信によって交換されるデータは１つのすれ違い受信データＪｄにまとめて含めるようにしてもよい。
【０１４３】
メインメモリ３２には、他にも図７Ａに示すように各種プログラムＰａが含まれるが、各種プログラムＰａの詳細については後述する。
【０１４４】
以上が、ゲーム装置１０のメインメモリ３２に格納されるデータおよびプログラムの説明である。次に、図７Ｆを参照して、サーバ５のメインメモリ５５に格納される各種データについて説明する。
【０１４５】
［サーバ５に格納されるデータ］
サーバ５のメインメモリ５５には、図７Ｆに示すように、配信用ＧＢＬデータＧｓｄ、ユーザ特定用カウントデータＵｃｄおよびデータ特定用カウントデータＤｃｄが格納される。
【０１４６】
配信用ＧＢＬデータＧｓｄは、サーバ５が管理しているＧＢＬを示すデータである。サーバ５が管理しているＧＢＬは、後述するようにゲーム装置１０のそれぞれによって配信用ＧＢＬデータＧｓｄを受信するためのタスクが実行されることに応じて、それぞれのゲーム装置１０に送信される。なお、サーバ５が管理している配信用ＧＢＬデータＧｓｄのデータ構造は、ゲーム装置１０のメインメモリ３２に格納されるＧＢＬデータＧｄのデータ構造と同一である。そして、サーバ５が管理している配信用ＧＢＬデータＧｓｄは、後述するようにユーザからの通報回数に基づいて常に最新のデータとなるように更新される。
【０１４７】
ユーザ特定用カウントデータＵｃｄは、ユーザ作成データＵｄの通報回数を最後の変更者毎にカウントするためのデータである。具体的には、ユーザ特定用カウントデータＵｃｄには、１以上のユーザカウントデータが含まれる。ユーザカウントデータは、変更者ＩＤとアプリＩＤと通報回数とからなる。ユーザカウントデータに含まれる通報回数は、それ自体に含まれる変更者ＩＤとアプリＩＤとを含むユーザ作成データＵｄが通報された回数を示す。また、ユーザカウントデータに含まれる変更者ＩＤは、通報されたユーザ作成データＵｄに含まれる最後の変更者ＩＤである。従って、ユーザカウントデータは、ユーザ作成データＵｄによって示される最後の変更者に基づいて通報された回数を示す。
【０１４８】
なお、通報されたユーザ作成データＵｄに含まれる最後の変更者ＩＤとアプリＩＤとを含むユーザカウントデータがユーザ特定用カウントデータＵｃｄに含まれていない場合には、当該変更者ＩＤと当該アプリＩＤとを含むユーザカウントデータが新たに生成される。従って、ユーザ特定用カウントデータＵｃｄに含まれるユーザカウントデータは、図７Ｆに示すように２つに限られない。
【０１４９】
また、データ特定用カウントデータＤｃｄは、ユーザ作成データＵｄの通報回数をデータ毎にカウントするためのデータである。具体的には、データ特定用カウントデータＤｃｄには、データＩＤとアプリＩＤと通報回数とからなるデータカウントデータが１以上含まれる。データカウントデータに含まれる通報回数は、それ自体に含まれるデータＩＤとアプリＩＤとを含むユーザ作成データＵｄが通報された回数を示す。従って、データカウントデータは、ユーザ作成データＵｄによって示されるデータの内容に基づいて通報された回数を示すデータとなる。
【０１５０】
なお、通報されたユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとを含むデータカウントデータがデータ特定用カウントデータＤｃｄに含まれていない場合には、当該データＩＤと当該アプリＩＤとを含むデータカウントデータが新たに生成される。従って、データ特定用カウントデータＤｃｄに含まれるデータカウントデータは、図７Ｆに示すように２つに限られない。
【０１５１】
［各種プログラムによる処理の説明］
次に、図８Ａ〜図８Ｊを参照して、ゲーム装置１０で実行される各種プログラムによる具体的な処理について説明する。なお、図８Ａおよび図８Ｂは、キャラクタ取り扱い処理プログラムを実行することによってゲーム装置１０がキャラクタ取り扱い処理を行う一例を示すフローチャートである。図８Ｃおよび図８Ｄは、図８Ａのステップ１４０で実行されるキャラクタ編集処理の詳細を示すフローチャートである。図８Ｅは、図８Ａのステップ１５０で実行されるＬＢＬ登録処理の詳細を示すフローチャートである。図８Ｆは、すれ違い通信処理プログラムを実行することによってゲーム装置１０がすれ違い通信処理を行う一例を示すフローチャートである。図８Ｇは、インターネット通信処理プログラムを実行することによってゲーム装置１０がインターネット通信処理を行う一例を示すフローチャートである。図８Ｈは、図８Ｂのステップ１８０で実行されるローカル通信処理の詳細を示すフローチャートである。図８Ｉは、図８Ｄのステップ２８０、図８Ｆのステップ５６０および図８Ｇのステップ６３５で実行されるフィルタリング処理の詳細を示すフローチャートである。図８Ｊは、ＧＢＬ更新処理プログラムを実行することによってゲーム装置１０がＧＢＬ更新処理を行う一例を示すフローチャートである。なお、これらの処理を実行するためのプログラムは、データ保存用内部メモリ３５に格納されている各種プログラムＰａに含まれており、ゲーム装置１０の電源がオンになったときに、データ保存用内部メモリ３５からメインメモリ３２に読み出されて、ＣＰＵ３１１によって実行される。本実施例では上記各種プログラムＰａは予めデータ保存用内部メモリ３５に記憶されているものとしたが、当該各種プログラムＰａの１つ又は全部のプログラムを、インターネット等を介してゲーム装置１０にダウンロードするようにしてもよい。また、データ保存用外部メモリ４６や外部メモリ４５に格納されたプログラムから読み出して実行するようにしてもよい。
【０１５２】
また、図８Ａ〜図８Ｊにそれぞれ示す処理の内、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理は、ゲーム装置１０の電源をオンにした後は、他の処理のいずれかが実行されているときであっても、実行されている他の処理とそれぞれとが並行して常に繰り返し実行されているものとする。また、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理は、他に実行されている処理がない場合でも並行して常に繰り返し実行されているものとする。つまり、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理は、他の処理が実行されているか否かに関わらず、常にそれぞれが並行して繰り返し実行されているものとする。
【０１５３】
まず、ゲーム装置１０の電源（電源ボタン１４Ｆ）がオンにされると、ＣＰＵ３１１によってブートプログラム（図示せず）が実行され、これによりデータ保存用内部メモリ３５に格納されている、複数のアプリケーションプログラムを選択的に実行させるプログラムであるランチャープログラムがメインメモリ３２にロードされＣＰＵ３１１で実行される。その後、ランチャープログラム上でキャラクタ取り扱いアプリケーションを選択して実行することにより、キャラクタ取り扱い処理プログラムがメインメモリ３２にロードされる。そして、ロードされたキャラクタ取り扱い処理プログラムをＣＰＵ３１１が実行することによって、図８Ａのステップ１０１から処理が開始される。なお、図８Ａ〜図８Ｊにおいては、ステップを「Ｓ」と略称している。
【０１５４】
キャラクタ取り扱い処理とは、キャラクタの編集、ＬＢＬへの登録および通信を用いた交換などをユーザの選択に応じて実行するための処理である。より具体的には、キャラクタ取り扱い処理とは、後述するようにキャラクタを新規作成する処理、既存のキャラクタを変更する処理、キャラクタをＬＢＬへ登録する処理、すれ違い通信においてキャラクタを送信する処理、インターネット通信においてキャラクタを受信する処理、インターネット通信においてキャラクタを送信する処理、ローカル通信においてキャラクタを送信する処理およびその他の各種処理などをユーザが選択してゲーム装置１０に実行させるための処理である。
【０１５５】
図８Ａにおいて、ＣＰＵ３１１は、上述したそれぞれの処理のユーザによる選択を受け付ける前に、メインメモリ３２に格納されている受信ボックスデータＪｂを参照して、新たなすれ違い受信データＪｄ（新着データ）が格納されているか否かを判断する（ステップ１０１）。ＣＰＵ３１１は、新たなすれ違い受信データＪｄが格納されていると判断した場合（ステップ１０１でＹｅｓ）、当該すれ違い受信データＪｄを新たなユーザ作成データＵｄとして、ユーザ作成データＵｄの格納領域に格納する（ステップ１０５）。新たなユーザ作成データＵｄを格納すると、ＣＰＵ３１１は、受信ボックスデータＪｂに格納されている新たなすれ違い受信データＪｄを削除する（ステップ１１０）。
【０１５６】
ＣＰＵ３１１は、新たなすれ違い受信データＪｄが格納されていないと判断した場合（ステップ１０１でＮｏ）または新たなすれ違い受信データＪｄを削除すると、フィルタリング処理を実行する（ステップ１１５）。フィルタリング処理の詳細については後述するが、概要を説明すると、フィルタリング処理は、フィルタリング対象となるユーザ作成データＵｄをフィルタリングして非表示データを特定して設定する処理である。ステップ１１５におけるフィルタリング処理ではメインメモリ３２に格納されているユーザ作成データＵｄがフィルタリング対象となる。非表示データを設定すると、ＣＰＵ３１１は、非表示データに設定されていないそれぞれのユーザ作成データＵｄで示されるキャラクタを表示対象として上側ＬＣＤ２２に表示する（ステップ１２０）。ここでは、非表示データに設定されていないキャラクタの全てを表示するのに限らず、例えば、非表示データに設定されていないキャラクタのうち、今回すれ違い通信によって新たに受信したものを表示したり、非表示データに設定されていないキャラクタのうち、ランダムに複数をピックアップして表示したりする。また、ＣＰＵ３１１は、表示対象を上側ＬＣＤ２２に表示すると共に、下側ＬＣＤ１２に、各種処理をそれぞれ示すアイコンを表示する。本実施例では、このように、表示対象のみのキャラクタとそれぞれのアイコンとを表示する画面をキャラクタ取り扱い画面として表示するものとする。キャラクタ取り扱い画面では、表示されたアイコンにユーザがタッチ操作することによって対応する処理を選択することができる。
【０１５７】
キャラクタ取り扱い画面を表示するとＣＰＵ３１１は、上述したそれぞれの処理のユーザによる選択の受け付けを開始する。ＣＰＵ３１１は、まず始めに、ユーザによってキャラクタを新規作成する処理が選択されたか否かを判断する（ステップ１２５）。キャラクタを新規作成する処理が選択されたと判断した場合（ステップ１２５でＹｅｓ）、ＣＰＵ３１１は、キャラクタ編集処理を開始する（ステップ１４０）。このとき、ＣＰＵ３１１は、新規作成されるキャラクタを編集対象とする。
【０１５８】
一方、ＣＰＵ３１１は、キャラクタを新規作成する処理が選択されていないと判断した場合（ステップ１２５でＮｏ）、既存のキャラクタを変更する処理がユーザによって選択されたか否かを判断する（ステップ１３０）。ＣＰＵ３１１は、既存のキャラクタを変更する処理がユーザによって選択されたと判断した場合（ステップ１３０でＹｅｓ）、変更フラグＨｆ（図示せず）をオンにする（ステップ１３５）。このとき、ＣＰＵ３１１は、上側ＬＣＤ２２に表示されているキャラクタの内、編集対象とするキャラクタをユーザに選択させてから変更フラグＨｆをオンにする。編集対象とするキャラクタをユーザに選択させるには、上側ＬＣＤ２２に表示されているキャラクタに対応する情報（例えば、名前など）を下側ＬＣＤ１２に一覧表示し、ユーザに選択させる手法などが一例として挙げられる。編集対象とするキャラクタをユーザに選択させるときに、キャラクタに対応する情報を下側ＬＣＤ１２に一覧表示する場合、下側ＬＣＤ１２に既に表示されている上述したアイコンは消去されるものとする。
【０１５９】
変更フラグＨｆをオンにすると、ＣＰＵ３１１は、キャラクタ編集処理を開始する（ステップ１４０）。以下、図８Ｃを参照して、上記ステップ１４０で行うキャラクタ編集処理の詳細について説明する。
【０１６０】
［キャラクタ編集処理］
図８Ｃにおいて、ＣＰＵ３１１は、キャラクタ編集処理を開始すると、ユーザによってキャラクタの新規作成が選択されたか否かを判断する（ステップ２０１）。具体的には、ＣＰＵ３１１は、メインメモリ３２を参照して変更フラグＨｆがオンとなっているか否かを判断する。ＣＰＵ３１１は、変更フラグＨｆがオンとなっていない場合、ユーザによって新規作成が選択されたと判断する。一方、ＣＰＵ３１１は、変更フラグＨｆがオンとなっている場合、ユーザによってキャラクタの変更が選択されたと判断する。
【０１６１】
ＣＰＵ３１１は、ユーザによってキャラクタの新規作成が選択されたと判断した場合（ステップ２０１でＹｅｓ）、新たなユーザ作成データＵｄをメインメモリ３２に生成する（ステップ２０３）。なお、新たに生成されたときのユーザ作成データＵｄで示されるキャラクタの各パーツは、初期パーツとして予め定められているものとする。
【０１６２】
ＣＰＵ３１１は、ユーザによってキャラクタの変更が選択されたと判断した場合（ステップ２０１でＮｏ）またはキャラクタを新規作成すると、編集対象のキャラクタを示すユーザ作成データＵｄのデータ本文を参照する（ステップ２０５）。
【０１６３】
ＣＰＵ３１１は、編集対象のデータ本文を参照（ステップ２０５）すると、表示画面をキャラクタ取り扱い画面からキャラクタの編集画面に切り替える（ステップ２１０）。具体的には、ＣＰＵ３１１は、参照したデータ本文で示されるキャラクタのみを上側ＬＣＤ２２に表示する。また、ＣＰＵ３１１は、編集する対象となるパーツ（例えば、口、目、体など）を示すアイコンをそれぞれ下側ＬＣＤ１２に表示する。さらに、ＣＰＵ３１１は、編集を終了するための終了アイコンも下側ＬＣＤ１２に表示する。
【０１６４】
ＣＰＵ３１１は、キャラクタの編集画面を表示すると、編集対象となるパーツがユーザによって選択されたか否かを判断する（ステップ２２０）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されているアイコンのいずれにタッチされたか否かを判断する。ＣＰＵ３１１は、編集対象となるパーツが選択されたと判断した場合（ステップ２２０でＹｅｓ）、選択されたパーツの候補をそれぞれ示すアイコンが下側ＬＣＤ１２に表示されるように表示を切り替える（ステップ２２５）。ＣＰＵ３１１が、ステップ２２５の処理をすることによりパーツの候補選択画面が下側ＬＣＤ１２に表示される。ここで、編集対象のパーツの候補とは、例えば、編集対象が目のパーツであれば、丸目、細目および切れ長の目などが当該候補となる。また、パーツの候補選択画面の一例は、図５に示すような画面であってもよい。図５は、口のパーツの候補選択画面の一例を示している。
【０１６５】
ＣＰＵ３１１は、編集対象として選択されたパーツの候補を示すアイコンをそれぞれ表示すると、ユーザによっていずれの候補が選択されたか否かを判断する（ステップ２３０）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されているアイコンのいずれにタッチされたか否かを判断する。ＣＰＵ３１１は、候補が選択されていないと判断した場合（ステップ２３０でＮｏ）、候補が選択されるまでステップ２３０の処理を繰り返して待機する。一方、ＣＰＵ３１１は、候補が選択されたと判断した場合（ステップ２３０でＹｅｓ）、選択された候補を登録する（ステップ２３５）。なお、選択されたパーツの候補を登録するとき、ＣＰＵ３１１は、編集対象のデータ本文の内、編集対象のパーツを示す箇所を選択された候補のパーツを示すように更新して登録する。
【０１６６】
ＣＰＵ３１１は、選択された候補を登録すると、上述したキャラクタの編集画面を再び表示する（ステップ２３７）。具体的には、ＣＰＵ３１１は、上側ＬＣＤ２２に表示されているキャラクタのパーツの中で編集対象として選択されたパーツを、登録した候補のパーツに切り替えて表示する。また、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されていたパーツの候補をそれぞれ示すアイコンを消去し、上述したキャラクタの編集画面に表示を切り替える。
【０１６７】
ＣＰＵ３１１は、キャラクタの編集画面に表示を切り替えると、ユーザによってパーツ選択の終了が選択されたか否かを判断する（ステップ２４０）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されている終了のアイコンにタッチされたか否かを判断する。ＣＰＵ３１１は、パーツ選択の終了が選択されていないと判断した場合（ステップ２４０でＮｏ）、ステップ２２０から処理を繰り返して、編集対象となるパーツを再びユーザに選択させる。
【０１６８】
一方、ＣＰＵ３１１は、パーツ選択の終了が選択されたと判断した場合（ステップ２４０でＹｅｓ）、次にキャラクタ情報を入力する画面に表示を切り替えて編集対象のキャラクタ情報の入力をユーザから受け付ける処理を開始する（ステップ２４５）。ここで、キャラクタ情報とは、例えば、キャラクタの名前、性別、年齢および当該キャラクタを紹介するコメントなどの情報である。ＣＰＵ３１１は、キャラクタ情報の入力の受け付けを開始すると、キャラクタ情報の入力を受け付けながら、キャラクタ情報の入力の完了がユーザによって選択されたか否かを判断する（ステップ２５０）。ＣＰＵ３１１は、キャラクタ情報の入力の完了が選択されていないと判断した場合（ステップ２５０でＮｏ）、キャラクタ情報の入力の中止がユーザによって選択されたか否かを判断する（ステップ２７０）。ＣＰＵ３１１は、キャラクタ情報の入力の中止が選択されていないと判断した場合（ステップＳ２７０でＮｏ）、ステップ２５０に処理を戻す。
【０１６９】
一方、ＣＰＵ３１１は、キャラクタ情報の入力の完了が選択されたと判断した場合（ステップ２５０でＹｅｓ）、編集対象のキャラクタが新規に作成されたキャラクタか否かを判断する（ステップ２５５）。具体的には、ＣＰＵ３１１は、メインメモリ３２に格納されている変更フラグＨｆを参照する。変更フラグＨｆがオフである場合、ＣＰＵ３１１は、編集対象となっているキャラクタが新規に作成されたキャラクタであると判断する（ステップ２５５でＹｅｓ）。一方、ＣＰＵ３１１は、変更フラグＨｆがオンである場合、ＣＰＵ３１１は、編集対象となっているキャラクタが既存のキャラクタであると判断する（ステップ２５５でＮｏ）。
【０１７０】
ＣＰＵ３１１は、新規に作成されたキャラクタであると判断した場合（ステップ２５５でＹｅｓ）、ユーザ作成データＵｄのユーザＩＤに作成者ＩＤを付与する（ステップ２６０）。一方、ＣＰＵ３１１は、新規に作成されたキャラクタでないと判断した場合（ステップ２５５でＮｏ）、編集対象となっているキャラクタが変更された既存のキャラクタであると判断して、ユーザ作成データＵｄのユーザＩＤに変更者ＩＤを追加する（ステップ２６５）。
【０１７１】
ＣＰＵ３１１は、ユーザ作成データＵｄに作成者ＩＤを付与する（ステップ２６０）またはユーザ作成データＵｄに変更者ＩＤを追加する（ステップ２６５）と、メインメモリ３２に格納されている変更フラグＨｆをオフに更新して（ステップ２７５）、キャラクタ作成処理を終了する。また、ＣＰＵ３１１は、ユーザによってキャラクタ情報の入力の中止が選択されたと判断したときにも（ステップ２７０でＹｅｓ）、変更フラグＨｆをオフに更新して（ステップ２７５）、キャラクタ編集処理を終了する。なお、ＣＰＵ３１１が、キャラクタ編集処理を終了するときには、上述したキャラクタ取り扱い画面に表示を切り替える。
【０１７２】
以上が、本実施例におけるキャラクタ編集処理の説明である。本実施例では、ＣＰＵ３１１が上述したキャラクタ編集処理を行うことによりユーザは自由にキャラクタを作成・編集でき、ユーザ作成データＵｄを生成することができる。
【０１７３】
図８Ａに戻り、ＣＰＵ３１１は、キャラクタの変更がユーザによって選択されなかったと判断した場合（ステップ１３０でＮｏ）、キャラクタのＬＢＬへの登録が選択されたか否かを判断する（ステップ１４５）。ＣＰＵ３１１は、キャラクタのＬＢＬへの登録がユーザによって選択されたと判断した場合（ステップ１４５でＹｅｓ）、ＬＢＬ登録処理を開始する（ステップ１５０）。以下、図８Ｅを参照して、上記ステップ１５０で行うＬＢＬ登録処理の詳細について説明する。
【０１７４】
［ＬＢＬ登録処理］
図８Ｅにおいて、ＣＰＵ３１１は、メインメモリ３２に格納されているユーザ作成データＵｄの内、他のゲーム装置１０から受信したキャラクタのみを下側ＬＣＤ１２に表示する（ステップ３０１）。具体的には、ＣＰＵ３１１は、まず、キャラクタ取り扱い画面を消去する。そして、ＣＰＵ３１１は、他のゲーム装置１０から受信したキャラクタのみを下側ＬＣＤ１２に表示してユーザからのタッチ操作によって選択できるようにする。ＣＰＵ３１１は、他のゲーム装置１０から受信したキャラクタのみを表示するとき、作成者ＩＤおよび変更者ＩＤの両方が他のゲーム装置１０のＩＤであるユーザ作成データＵｄで示されるキャラクタのみを表示する。また、ＣＰＵ３１１が、ＬＢＬ登録処理においてキャラクタを表示するときには、当該処理を終了するためのアイコンも下側ＬＣＤ１２に表示する。これにより、ＬＢＬ登録処理画面が下側ＬＣＤ１２に表示される。
【０１７５】
ＣＰＵ３１１は、他のゲーム装置１０から受信したキャラクタを表示すると、ＬＢＬに登録するキャラクタがユーザによって選択されたか否かを判断する（ステップ３０５）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されているいずれかのキャラクタにタッチ操作されたか否かを判断する。
【０１７６】
そして、ＣＰＵ３１１は、ＬＢＬに登録するキャラクタがユーザによって選択されたと判断すると（ステップ３０５でＹｅｓ）、まず、選択されたキャラクタを登録するＬＢＬとして変更者ＬＢＬがユーザによって選択されたか否かを判断する（ステップ３１０）。ＣＰＵ３１１は変更者ＬＢＬが選択されていないと判断したとき（ステップ３１０でＮｏ）、選択されたキャラクタを登録するＬＢＬとしてデータＬＢＬがユーザによって選択されたか否かを判断する（ステップ３２５）。
【０１７７】
ＣＰＵ３１１は、選択されたキャラクタを登録するＬＢＬとしてデータＬＢＬがユーザによって選択されていないと判断したとき（ステップ３２５でＮｏ）、登録するＬＢＬが選択されなかったものとして、処理をステップ３０５に戻す。
【０１７８】
一方、ＣＰＵ３１１は、選択されたキャラクタを登録するＬＢＬとして変更者ＬＢＬが選択されたと判断したとき（ステップ３１０でＹｅｓ）、当該キャラクタを変更者ＬＢＬに登録する。具体的には、ＣＰＵ３１１は、選択されたキャラクタを示すユーザ作成データＵｄに含まれる最後の変更者ＩＤとアプリＩＤとを含む変更者特定ＬＢＬデータを生成して、変更者ＬＢＬデータに追加して登録する（ステップ３１５）。
【０１７９】
一方、ＣＰＵ３１１は、選択されたキャラクタを登録するＬＢＬとしてデータＬＢＬがユーザによって選択されたと判断したとき（ステップ３２５でＹｅｓ）、当該キャラクタをデータＬＢＬに登録する。具体的には、ＣＰＵ３１１は、選択されたキャラクタを示すユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとを含むデータ特定ＬＢＬデータを生成して、データＬＢＬデータに追加して登録する（ステップ３３０）。
【０１８０】
ＣＰＵ３１１は、変更者ＬＢＬにキャラクタを登録（ステップ３１５）またはデータＬＢＬにキャラクタを登録（ステップ３３０）すると、登録したキャラクタのサーバ５への通報がユーザによって選択されたか否かを判断する（ステップ３４０）。
【０１８１】
ＣＰＵ３１１は、ユーザによって通報が選択されたと判断したとき（ステップ３４０でＹｅｓ）、通報するキャラクタを示すユーザ作成データＵｄをサーバ５に送信するタスクを示すタスクデータＴｄを生成する（ステップ３４５）。後述で明らかとなるが、このとき生成されたタスクデータＴｄで示されるタスクが実行されれば、ユーザが道徳上の観点から不適切と判断したキャラクタを示すユーザ作成データＵｄがサーバ５に送信され通報される。
【０１８２】
一方、ＣＰＵ３１１は、通報がユーザによって選択されないと判断したとき（ステップ３４０でＮｏ）、ステップ３０５へ処理を戻して、ＬＢＬに登録するキャラクタがユーザによって選択されたか否かを再び判断する。また、ＣＰＵ３１１は、ステップ３４５においてタスクデータＴｄを生成した後も、ステップ３０５へ処理を戻して、ＬＢＬに登録する他のキャラクタがユーザによって選択されたか否かを再び判断する。
【０１８３】
一方、ＣＰＵ３１１は、ＬＢＬに登録するキャラクタが選択されなかったと判断したとき（ステップ３０５でＮｏ）、ユーザによってＬＢＬ登録処理の終了が選択されたか否かを判断する（ステップ３５０）。ＣＰＵ３１１は、ＬＢＬ登録処理の終了が選択されたと判断したとき（ステップ３５０でＹｅｓ）、ＬＢＬ登録処理を終了する。一方、ＣＰＵ３１１は、ＬＢＬ登録処理の終了が選択されていないと判断したとき、ステップ３０５へ処理を戻して、ＬＢＬに登録するキャラクタがユーザによって選択されたか否かを再び判断する。なお、ＣＰＵ３１１が、ＬＢＬ登録処理を終了するときには、上述したＬＢＬ登録処理画面からキャラクタ取り扱い画面に表示が切り替えられる。
【０１８４】
以上が、本実施例におけるＬＢＬ登録処理の説明である。上述したＬＢＬ登録処理によれば、ユーザは、他のゲーム装置１０から受信したキャラクタの中で道徳上の観点から好ましくないと感じたキャラクタを登録することができる。より詳細には、ＬＢＬ登録処理においてユーザは、キャラクタを変更者ＬＢＬまたはデータＬＢＬのいずれかに登録できる。そして、ユーザはキャラクタを変更者ＬＢＬに登録することにより、当該キャラクタの最後の変更者を道徳上の観点から好ましくないキャラクタを作成したユーザとしてＬＢＬに登録できる。一方、ユーザはキャラクタをデータＬＢＬに登録することにより、当該キャラクタを示すデータを道徳上の観点から好ましくないキャラクタを示すデータとしてＬＢＬに登録できる。
【０１８５】
また、上述したＬＢＬ登録処理では、ユーザがＬＢＬに登録したキャラクタをサーバ５に通報することもできる。サーバ５に通報されたキャラクタは、後に詳述するサーバ処理によって所定の条件を満たすと判断されたときにＧＢＬに登録される。つまり、ＬＢＬ登録処理においてキャラクタを通報できるようにすることで、サーバ５は、本システムに含まれる全てのゲーム装置１０のユーザの感覚（総意）に基づいてＧＢＬに登録するキャラクタを判断できる。
【０１８６】
また、ＬＢＬおよびＧＢＬの少なくともいずれか一方に登録されたキャラクタのユーザ作成データＵｄは、後に詳述するフィルタリング処理によって非表示データに設定される。これにより、ユーザは、道徳上の観点から好ましくないと感じたキャラクタを表示しないようにすることができる。
【０１８７】
図８Ａに戻り、ＣＰＵ３１１は、ＬＢＬへの登録が選択されていないと判断した場合（ステップ１４５でＮｏ）、図８Ｂにおいて、キャラクタのすれ違い通信における送信がユーザによって選択されたか否かを判断する（ステップ１５５）。
【０１８８】
ＣＰＵ３１１は、キャラクタのすれ違い通信における送信が選択されたと判断した場合（ステップ１５５でＹｅｓ）、送信するキャラクタの選択をユーザから受け付ける（ステップ１５７）。ＣＰＵ３１１は、送信するキャラクタの選択をユーザから受け付けると、選択されたキャラクタのユーザ作成データＵｄをすれ違い送信データＳｄとしてメインメモリ３２に格納する（ステップ１６０）。ここで、上述したすれ違い通信処理について、図８Ｆを参照して説明する。なお、すれ違い通信処理において行われる全てのデータの送受信は、上述したように、同種のゲーム装置との間で無線通信を行う機能を有するローカル通信モジュール３７を用いて行われる。
【０１８９】
［すれ違い通信処理］
図８Ｆにおいて、ＣＰＵ３１１は、メインメモリ３２を参照して、通信時刻から所定時間が経過したＭＡＣアドレス（図示せず）が存在するか否かを判断する（ステップ４０１）。ここで、通信時刻とは、後述するように送信ボックスデータＳｂに含まれるデータまたは接続応答を送信したときの時刻である。通信時刻は、送信ボックスデータＳｂに含まれるデータまたは接続応答を送信したときに送信先のＭＡＣアドレスと共にメインメモリ３２に格納される。後に明らかとなるが、本実施例では、通信時刻を用いることにより同一の通信先との短期間における重複した通信を防ぐことができる。
【０１９０】
ＣＰＵ３１１は、所定時間が経過したＭＡＣアドレスが格納されていると判断したとき（ステップ４０１でＹｅｓ）、当該ＭＡＣアドレスを通信時刻と共にメインメモリ３２から削除する（ステップ４０５）。一方、ＣＰＵ３１１は、所定時間が経過したＭＡＣアドレスが格納されていないと判断したとき（ステップ４０１でＮｏ）またはＭＡＣアドレスを削除すると（ステップ４０５）、接続要求をブロードキャストで送信する（ステップ４１０）。ここで、接続要求とは、他のゲーム装置１０に対してすれ違い通信を要求するために無線で送信される通信フレームである。接続要求には、当該通信フレームが接続要求であることを示す情報、送信元のゲーム装置１０のＭＡＣアドレス、および送信ボックスデータＳｂに含まれる全てのデータ（すれ違い送信データＳｄおよび送信ＧＢＬデータＳｇｄ）にそれぞれ含まれるアプリＩＤからなる。
【０１９１】
ＣＰＵ３１１は、接続要求を送信すると、自身の接続要求に対する接続応答を受信したか否かを、当該接続要求を送信してから所定期間だけ判断する（ステップ４１５）。ここで、接続応答とは、前述の接続要求を受信した他のゲーム装置１０からの応答を示す通信フレームである。接続応答は４つの情報からなる。すなわち、当該通信フレームが接続応答であることを示す情報、接続要求の送信元のＭＡＣアドレス、当該接続応答の送信元（他のゲーム装置１０）のＭＡＣアドレスおよび接続応答の送信元のゲーム装置１０に格納されている送信ボックスデータＳｂに含まれる全てのデータ（すれ違い送信データＳｄおよび送信ＧＢＬデータＳｇｄ）にそれぞれ含まれるアプリＩＤからなる。
【０１９２】
ＣＰＵ３１１は、自身の接続要求に対する接続応答を受信したか否かを判断するとき、ＭＡＣアドレスを用いて判断する。より詳細には、ＣＰＵ３１１は、接続要求を送信してから所定期間が経過するまでに受信した接続応答に含まれるＭＡＣアドレスと自身のゲーム装置１０のＭＡＣアドレスとが一致するか否かを判断する。ＣＰＵ３１１は、両方のＭＡＣアドレスが一致すれば、当該ＭＡＣアドレスを含む接続応答が自身の接続要求に対する接続応答であると判断できる。
【０１９３】
ＣＰＵ３１１は、自身の接続要求に対する接続応答を受信したと判断した場合（ステップ４１５でＹｅｓ）、当該接続応答を送信したゲーム装置１０とすれ違い通信をする必要があるか否かを判断する（ステップ４２０）。具体的には、ＣＰＵ３１１は、受信した接続応答に含まれるアプリＩＤの中に、送信ボックスデータＳｂに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在するか否かを判断する。そして、ＣＰＵ３１１は、受信した接続応答に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在する場合、すれ違い通信が必要であると判断する。一方、ＣＰＵ３１１は、受信した接続応答に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在しない場合、すれ違い通信が必要でないと判断する。
【０１９４】
ＣＰＵ３１１は、すれ違い通信が必要であると判断した場合（ステップ４２０でＹｅｓ）、すれ違い通信を開始する。具体的には、ＣＰＵ３１１は、ステップ４２０で一致すると判断したアプリＩＤを含む全てのデータを、ステップ４１５で判断した接続応答の送信元に送信する（ステップ４２５）。
【０１９５】
ＣＰＵ３１１は、ステップ４２０で一致すると判断したアプリＩＤを含む全てのデータを送信すると、送信先のゲーム装置１０のＭＡＣアドレス（接続応答に含まれていた送信元のＭＡＣアドレス）と共に、送信時刻を前述の通信時刻としてメインメモリ３２に格納する（ステップ４３０）。
【０１９６】
次に、ＣＰＵ３１１は、ステップ４２５におけるデータの送信先から当該送信先の送信ボックスデータＳｂに含まれるデータを受信済みであるか否かを受信ボックスデータＪｂを参照して判断する（ステップ４３５）。ＣＰＵ３１１は、データを受信済みであると判断した場合（ステップ４３５でＹｅｓ）、受信ボックスデータＪｂに含まれるすれ違い受信データＪｄをフィルタリング対象として後述するフィルタリング処理を行う（ステップ４８０）。
【０１９７】
一方、ＣＰＵ３１１は、接続要求を送信した後に接続応答を受信していないと判断した場合（ステップ４１５でＮｏ）、他のゲーム装置１０から接続要求を受信したか否かを判断する（ステップ４４０）。ＣＰＵ３１１は、他のゲーム装置１０から接続要求を受信したと判断した場合（ステップ４４０でＹｅｓ）、受信した接続要求の送信元に対して接続応答を送信することが可能か否かを判断する（ステップ４４５）。具体的には、ＣＰＵ３１１は、受信した接続要求に含まれている送信元のＭＡＣアドレスが通信時刻と共にメインメモリ３２に格納されているか否かを判断する。ＣＰＵ３１１は、接続要求に含まれているＭＡＣアドレスがメインメモリ３２に格納されていない場合、短期間に重複した通信をすることにならないので、接続応答を送信することが可能であると判断できる。この理由は、上述したように通信時刻と共にメインメモリ３２に格納されているＭＡＣアドレスは、当該通信時刻から所定期間が経過すると削除されるためである。
【０１９８】
ＣＰＵ３１１は、接続応答を送信することが可能であると判断した場合（ステップ４４５でＹｅｓ）、ステップ４４０で受信したと判断した接続要求の送信元とすれ違い通信をする必要があるか否かを判断する（ステップ４５０）。具体的には、ＣＰＵ３１１は、受信した接続要求に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在するか否かを判断する。そして、ＣＰＵ３１１は、受信した接続要求に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在する場合、すれ違い通信が必要であると判断する。一方、ＣＰＵ３１１は、受信した接続要求に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在しない場合、すれ違い通信が必要でないと判断する。
【０１９９】
ＣＰＵ３１１は、すれ違い通信が必要であると判断した場合（ステップ４５０でＹｅｓ）、ステップ４４０で受信したと判断した接続要求の送信元に対して接続応答を送信する（ステップ４５５）。接続応答を送信すると、ＣＰＵ３１１は、その送信時刻を通信時刻として、送信先のゲーム装置１０のＭＡＣアドレス（ステップ４４０で受信したと判断した接続要求に含まれていた送信元のＭＡＣアドレス）と共にメインメモリ３２に格納する（ステップ４６０）。
【０２００】
次に、ＣＰＵ３１１は、ステップ４５５で送信した接続応答の送信先からデータを受信したか否かを判断する（ステップ４６５）。ＣＰＵ３１１は、データを受信したと判断した場合（ステップ４６５でＹｅｓ）、受信したデータを受信ボックスデータＪｂ内に格納する（ステップ４７０）。具体的には、ＣＰＵ３１１は、受信したデータの中にすれ違い送信データＳｄが含まれていれば、すれ違い受信データＪｄとして受信ボックスデータＪｂに格納する。また、ＣＰＵ３１１は、受信したデータの中に送信ＧＢＬデータＳｇｄが含まれていれば、受信ＧＢＬデータＪｇｄとして受信ボックスデータＪｂに格納する。
【０２０１】
ＣＰＵ３１１は、データを格納すると、当該データの送信元に対してデータを送信済みか否かを判断する（ステップ４７５）。ＣＰＵ３１１は、データを送信済みであると判断すると、後述するフィルタリング処理を実行する（ステップ４８０）。より詳細には、ＣＰＵ３１１は、受信したデータの中にすれ違い送信データＳｄが含まれていれば、当該すれ違い送信データＳｄすなわちユーザ作成データＵｄをフィルタリング対象として、後述するフィルタリング処理をする。なお、ＣＰＵ３１１は、ステップ４７５からフィルタリング処理へ進むときには、ステップ４７０で格納したすれ違い受信データＪｄをフィルタリング対象とする。
【０２０２】
一方、ＣＰＵ３１１は、データを送信済みでないと判断した場合（ステップ４７５でＮｏ）、前述のステップ４２５へ処理を進めてデータを送信する。なお、ステップ４２５の説明では、データの送信先は、ステップ４１５で判断した接続応答の送信元であるものとした。しかしながら、ＣＰＵ３１１が、ステップ４７５からステップ４２５へ処理を進めたときに送信するデータの送信先は、ステップ４５５で送信した接続応答の送信先となる。
【０２０３】
また、ＣＰＵ３１１は、ステップ４３５でデータを受信していないと判断したときにも、ステップ４６５へ処理を進めてデータを受信したか否かを判断する。上述したステップ４６５の説明では、ステップ４５５で送信した接続応答の送信先からデータを受信したか否かを判断するものとした。しかしながら、ＣＰＵ３１１が、ステップ４３５からステップ４６５へ処理を進めたときに判断するデータの送信元は、ステップ４２５で送信したデータの送信先となる。
【０２０４】
一方、ＣＰＵ３１１は、データを受信していないと判断した場合（ステップ４６５でＮｏ）、すれ違い通信処理をはじめから繰り返す。
【０２０５】
以上が、本実施例におけるすれ違い通信処理の説明である。上述したように、すれ違い通信処理は、本システムに含まれるゲーム装置１０のそれぞれにおいて常に繰り返し実行される。これにより、それぞれのゲーム装置１０は互いのローカル通信モジュール３７の通信範囲内に位置したときに、すれ違い通信を自動的に実行することができる。そして、互いのゲーム装置１０において、同一のアプリケーションで取り扱われるユーザ作成データＵｄがすれ違い送信データＳｄとして格納されている場合に互いのデータを自動的に送受信して交換できる。本実施例では、本システムに含まれるそれぞれのゲーム装置１０においてユーザ作成データＵｄを取り扱うアプリケーションとして、キャラクタ取り扱いアプリケーションが実行される。従って、本システムでは、上述したようにすれ違い通信で送信するようにユーザによって選択されたキャラクタをそれぞれのゲーム装置１０で自動的に交換することができる。このように交換されたキャラクタを示すデータは、図８Ａのステップ１０１で新たに受信されたすれ違い受信データＪｄとして判断され、ステップ１０５においてユーザ作成データＵｄとして格納される。
【０２０６】
また、本システムでは、すれ違い通信で送信ＧＢＬデータＳｇｄを互いのゲーム装置１０で送受信する。これにより、本システムでは、互いのゲーム装置１０に格納されているＧＢＬデータＧｄをすれ違い通信で自動的に交換することができる。また、すれ違い通信で受信した受信ＧＢＬデータＪｇｄは、後述するＧＢＬ更新処理において新しいバージョンであると判断されたときに、ＧＢＬデータＧｄとしてメインメモリ３２に格納され、更新される。従って、本システムによれば、インターネット通信網３に接続できないゲーム装置１０が存在したとしても、すれ違い通信可能な他のゲーム装置１０が存在すれば、ＧＢＬを新たなＧＢＬに更新することができる。
【０２０７】
また、すれ違い通信処理、それぞれ後に詳述するインターネット通信処理またはローカル通信処理で受信したユーザ作成データＵｄで示されるキャラクタのすれ違い通信における送信がユーザによって選択された場合には、当該ユーザ作成データＵｄをそのまますれ違い通信において転送できる。
【０２０８】
図８Ｂに戻って、ＣＰＵ３１１は、キャラクタのすれ違い通信における送信がユーザによって選択されていないと判断した場合（ステップ１５５でＮｏ）、キャラクタのインターネット通信網３を用いた受信がユーザによって選択されたか否かを判断する（ステップ１６５）。ＣＰＵ３１１は、キャラクタのインターネット通信網３を用いた受信が選択されたと判断した場合（ステップ１６５でＹｅｓ）、キャラクタを示すユーザ作成データＵｄを受信するための上述したタスクデータＴｄを生成する（ステップ１７０）。
【０２０９】
一方、ＣＰＵ３１１は、キャラクタのインターネット通信網３を用いた受信が選択されていないと判断した場合（ステップ１６５でＮｏ）、キャラクタのインターネット通信網３を用いた送信がユーザによって選択されたか否かを判断する（ステップ１７５）。ＣＰＵ３１１は、キャラクタのインターネット通信網３を介した送信が選択されたと判断した場合（ステップ１７５でＹｅｓ）、送信するキャラクタのユーザによる選択と、送信先の相手を表す情報の入力又は選択とを受け付ける（ステップ１７７）。ユーザによるキャラクタの選択と、送信先の入力又は選択とを受け付けると、ＣＰＵ３１１は、ユーザによって選択されたキャラクタを送信するための上述したタスクデータＴｄを生成する（ステップ１８０）。
【０２１０】
ここで、ＣＰＵ３１１がインターネット通信網３を用いてデータを送受信するためのインターネット通信処理について、図８Ｇを参照して説明する。なお、インターネット通信処理において行われる全てのデータの送受信は、上述したようにインターネット通信網３を用いて他の機器との間でデータを送受信するための無線通信モジュール３６を用いて行われる。
【０２１１】
［インターネット通信処理］
図８Ｇにおいて、ＣＰＵ３１１は、メインメモリ３２を参照して、次回実行時刻が現在時刻を過ぎているタスクデータＴｄが存在するか否かを判断する（ステップ５０１）。ＣＰＵ３１１は、次回実行時刻が現在時刻を過ぎているタスクデータＴｄが存在していると判断した場合（ステップ５０１でＹｅｓ）、無線通信モジュール３６の通信範囲内に存在する前述のＡＰ２の検出を開始する（ステップ５１０）。ＣＰＵ３１１は、所定時間だけＡＰ２の検出を実行した後、ＡＰ２を検出できたか否かを判断する（ステップ５１５）。ＣＰＵ３１１は、ＡＰ２を検出できたと判断した場合（ステップ５１５でＹｅｓ）、検出したＡＰ２との通信を開始する（ステップ５２０）。
【０２１２】
一方、ＣＰＵ３１１は、次回実行時刻が現在時刻を過ぎているタスクデータＴｄが存在していないと判断したとき（ステップ５０１でＮｏ）、又は、ＡＰ２を検出できなかったと判断したとき（ステップ５１５でＮｏ）、ステップ５０１から処理を繰り返す。
【０２１３】
次に、ＣＰＵ３１１は、ＡＰ２との通信を開始すると、ステップ５０１で判断したタスクデータＴｄの中から、実行時刻が過ぎているが未だに実行されていない未実行のタスクを示すタスクデータＴｄを選択する（ステップ５２５）。ＣＰＵ３１１は、未実行のタスクを選択すると、選択した未実行タスクを全て実行したか否かを判断する（ステップ５３０）。ＣＰＵ３１１は、未実行タスクを全て実行していないと判断した場合（ステップ５３０でＮｏ）、未実行タスクを１つだけ選択する（ステップ５３５）。ＣＰＵ３１１が、全ての未実行タスクの中から１つを選択する手法は、例えば、所定の優先度を用いるなど、任意の手法を用いてかまわない。
【０２１４】
ＣＰＵ３１１は、未実行タスクを選択すると、選択した未実行タスクが受信タスクであるか否かを判断する（ステップ５４０）。具体的には、ＣＰＵ３１１は、選択した未実行タスクを示すタスクデータＴｄに含まれる送信／受信識別フラグを参照して、当該フラグが受信を示すか否かを判断する。
【０２１５】
ＣＰＵ３１１は、選択した未実行タスクが受信タスクであると判断した場合（ステップ５４０でＹｅｓ）、当該タスクを示すタスクデータＴｄに従ってデータを受信する（ステップ５４５）。具体的には、ＣＰＵ３１１は、未実行タスクを示すタスクデータＴｄに含まれる通信先ＵＲＬにアクセスして、データを受信する。受信されたデータは、タスクデータＴｄに含まれる格納先情報で示される格納先に格納される。例えば、配信用ＧＢＬデータＧｓｄを受信するためのタスクが実行されたときには、受信された配信用ＧＢＬデータＧｓｄが、ネット受信ＧＢＬデータＮｇｄとして、メインメモリ３２における格納先に格納され更新される。また、例えば、キャラクタを受信するためのタスクが実行されたときには、受信されたキャラクタを示すユーザ作成データＵｄがメインメモリ３２における格納先に格納される。
【０２１６】
ＣＰＵ３１１は、受信タスクを実行すると、実行したタスクを示すタスクデータＴｄに含まれる次回実行時刻を上述したように更新する（ステップ５５０）。
【０２１７】
一方、ＣＰＵ３１１は、選択した未実行タスクが受信タスクでないと判断した場合（ステップ５４０でＮｏ）、当該未実行タスクが送信タスクであるとして、当該タスクを示すタスクデータＴｄに従ってデータを送信する（ステップ５５５）。具体的には、ＣＰＵ３１１は、未実行の送信タスクを示すタスクデータＴｄに含まれる通信先ＵＲＬにアクセスして、データを送信する。送信されるデータは、タスクデータＴｄに含まれる格納先情報で示される格納先に格納されているデータとなる。例えば、キャラクタを送信するためのタスクが実行されたときには、ユーザによって選択されたキャラクタを示すユーザ作成データＵｄが、キャラクタの送信を受け付けるサーバ５を表すＵＲＬへ送信される。また、例えば、通報のためのタスクが実行されたときには、ユーザによって選択された通報するキャラクタを示すユーザ作成データＵｄがサーバ５へ送信される。
【０２１８】
ＣＰＵ３１１は、送信タスクを実行すると、実行したタスクを示すタスクデータＴｄを削除する（ステップ５６０）。
【０２１９】
次に、ＣＰＵ３１１は、実行したタスクが、配信用ＧＢＬデータＧｓｄを受信するためのタスクまたは任意のデータを送信するためのタスクであったか否かを判断する（ステップ５６５）。具体的には、ＣＰＵ３１１は、実行したタスクを示すタスクデータＴｄに含まれる送信／受信識別フラグと、格納先情報で示される格納先に格納されているデータとを参照して判断する。ＣＰＵ３１１は、実行したタスクが、配信用ＧＢＬデータＧｓｄを受信するためのタスクまたは任意のデータを送信するためのタスクではないと判断した場合（ステップ５６５でＮｏ）、実行したタスクが配信用ＧＢＬデータＧｓｄ以外のデータの受信であったと判断する。すなわち、ＣＰＵ３１１は、実行したタスクがユーザ作成データＵｄの受信であったと判断する。
【０２２０】
ＣＰＵ３１１は、実行したタスクがユーザ作成データＵｄの受信であったと判断すると（ステップ５６５でＹｅｓ）、受信したデータをフィルタリング対象として後述するフィルタリング処理を実行する（ステップ５７０）。一方、ＣＰＵ３１１は、実行したタスクが配信用ＧＢＬデータＧｓｄを受信するためのタスクまたは任意のデータを送信するためのタスクであると判断した場合（ステップ５６５でＹｅｓ）、フィルタリング処理の必要がないと判断し、処理をステップ５３０へ戻して、残りの未実行タスクがあるか否かを判断する。
【０２２１】
一方、ＣＰＵ３１１は、選択した未実行タスクを全て実行した（残りの未実行タスクがない）と判断した場合（ステップ５３０でＹｅｓ）、インターネット通信処理を始めから繰り返す。
【０２２２】
以上が、本実施例におけるインターネット通信処理の説明である。上述したように、インターネット通信処理は、本システムに含まれるゲーム装置１０のそれぞれにおいて常に繰り返し実行される。インターネット通信処理では、ユーザ作成データＵｄを送信するためのタスク、キャラクタを通報するためのタスク、ユーザ作成データＵｄを受信するためのタスクおよび配信用ＧＢＬデータＧｓｄを受信するためのタスクが実行される。そして、これらのタスクの中で送信のためのタスクを示すタスクデータＴｄは、当該タスクが実行されるまで削除されない。従って、キャラクタを通報するためのタスクは実行されるまで削除されないので、ユーザによって選択されたキャラクタを示すユーザ作成データＵｄを確実に通報することができる。
【０２２３】
また、上述したタスクの中で受信のタスクを示すタスクデータＴｄは、当該タスクが実行される度に次回実行時刻が更新される。従って、配信用ＧＢＬデータＧｓｄを受信するためのタスクは定期的に実行されるので、サーバ５によって管理されているＧＢＬを定期的に受信できる。
【０２２４】
また、後に詳述するローカル通信処理、それぞれ上述したすれ違い通信処理またはインターネット通信処理で受信したユーザ作成データＵｄで示されるキャラクタのインターネット通信網３を用いた送信がユーザによって選択された場合には、当該ユーザ作成データＵｄをそのままインターネット通信網３を介して転送できる。
【０２２５】
図８Ｂに戻って、ＣＰＵ３１１は、キャラクタのインターネット通信網３を用いた送信が選択されていないと判断した場合（ステップ１７５でＮｏ）、キャラクタのローカル通信での送信がユーザによって選択されたか否かを判断する（ステップ１８５）。ＣＰＵ３１１は、キャラクタのローカル通信での送信が選択されたと判断した場合（ステップ１８５でＹｅｓ）、送信するキャラクタのユーザによる選択を受け付ける（ステップ１８７）。ＣＰＵ３１１は、送信するキャラクタの選択を受け付けると、ローカル通信処理を実行する（ステップ１９０）。
【０２２６】
なお、ローカル通信処理において行われる全てのデータの送受信は、上述したように、同種のゲーム装置との間で無線通信を行う機能を有するローカル通信モジュール３７を用いて行われる。
【０２２７】
［ローカル通信処理］
図８Ｈにおいて、ＣＰＵ３１１は、キャラクタ取り扱い画面を消去し、通信範囲内に存在する他のゲーム装置１０を検出中であることを示す画像を下側ＬＣＤ１２に表示する（ステップ６０１）。検出中であることを示す画像を表示すると、ＣＰＵ３１１は、ローカル通信モジュール３７の通信範囲内に存在する他のゲーム装置１０の検出を開始する（ステップ６０３）。ＣＰＵ３１１は、所定時間だけ他のゲーム装置１０の検出を実行した後、検出中であることを示す画像を消去して、他のゲーム装置１０を検出できたか否かを判断する（ステップ６０５）。ＣＰＵ３１１は、他のゲーム装置１０を検出できたと判断すると（ステップ６０５でＹｅｓ）、検出したゲーム装置１０を下側ＬＣＤ１２に検出結果として一覧表示する（ステップ６１０）。ＣＰＵ３１１は、検出結果を表示すると、表示した検出結果の中から通信先がユーザによって選択されたか否かを判断する（ステップ６１５）。具体的には、検出結果の一覧のいずれかにタッチ操作されたか否かを判断する。
【０２２８】
ＣＰＵ３１１は、ユーザによって通信先のゲーム装置１０が選択されたと判断した場合（ステップ６１５でＹｅｓ）、当該通信先のゲーム装置１０によって自身のゲーム装置１０が通信先として選択されたか否かを当該通信先から送信される情報に基づいて判断する（ステップ６２０）。ＣＰＵ３１１は、通信先によって自身のゲーム装置１０が選択されたと判断した場合（ステップ６２０でＹｅｓ）、ステップ１８７で選択されたキャラクタのユーザ作成データＵｄを当該通信先に送信する（ステップ６２５）。そして、ＣＰＵ３１１は、自身のゲーム装置１０からのユーザ作成データＵｄの送信に応じて送信される通信先からのユーザ作成データＵｄを受信する（ステップ６３０）。ＣＰＵ３１１は、通信先からユーザ作成データＵｄを受信すると、受信したユーザ作成データＵｄをフィルタリング対象として、後述するフィルタリング処理を実行する（ステップ６３５）。ＣＰＵ３１１は、フィルタリング処理を実行した後、受信したユーザ作成データＵｄをメインメモリ３２に格納する。
【０２２９】
一方、ＣＰＵ３１１は、通信先を発見できなかった（ステップ６０５でＮｏ）、ユーザによって通信先が選択されなかった(ステップ６１５でＮｏ）あるいは通信先によって自身のゲーム装置１０が選択されなかった(ステップ６２０でＮｏ）場合、データを受信できないのでフィルタリング処理をすることなく、ローカル通信処理を終了する。
【０２３０】
以上が、本実施例におけるローカル通信処理の説明である。上述の説明から明らかなように、ローカル通信処理は、ユーザからの操作に応じて即座に実行される。これにより、ユーザは、すれ違い通信による自動的なデータの送受信のみに頼ることなく、自らの意志でユーザ作成データＵｄを他のゲーム装置１０と交換することができる。
【０２３１】
また、それぞれ上述したすれ違い通信処理、インターネット通信処理またはローカル通信処理で受信したユーザ作成データＵｄで示されるキャラクタのローカル通信での送信がユーザによって選択された場合には、当該ユーザ作成データＵｄをそのままローカル通信において転送できる。
【０２３２】
図８Ｂに戻り、ＣＰＵ３１１は、ユーザ作成データＵｄのローカル通信での送信がユーザによって選択されていないと判断した場合（ステップ１８５でＮｏ）、キャラクタ取り扱い処理において必要な他の各種処理を実行する（ステップ１９５）。キャラクタ取り扱い処理において必要な他の各処理とは、例えば、上側ＬＣＤ２２に表示されているキャラクタの動作を制御する処理などである。
【０２３３】
ＣＰＵ３１１は、ユーザ作成データ生成処理（図８Ａのステップ１４０）、ＬＢＬ登録処理（ステップ１５０）、すれ違い通信で送信するユーザ作成データＵｄを格納する処理（図８Ｂのステップ１６０）、インターネット通信処理での送信が選択されたときにおけるタスクを生成する処理（ステップ１７０、ステップ１８０）、ローカル通信処理（ステップ１９０）および前述の各種処理（ステップ１９５）のいずれかを実行すると、キャラクタ取り扱い処理を終了する選択がユーザによってされたか否かを判断する（ステップ２００）。ＣＰＵ３１１は、キャラクタ作成処理を終了する選択がユーザによってされていないと判断した場合（ステップ２００でＮｏ）、ステップ１１５に処理を戻す。上述したように、ステップ１１５では、メインメモリ３２に格納されている全てのユーザ作成データＵｄをフィルタリング対象としてフィルタリング処理が実行される。一方、キャラクタ取り扱い処理を終了する選択がなされた場合（ステップ２００でＹｅｓ）、キャラクタ取り扱い処理を終了し、上述のランチャーアプリケーションに戻る。
【０２３４】
以上が、本実施例におけるキャラクタ取り扱い処理の説明である。
【０２３５】
［フィルタリング処理］
次に、図８Ｉを参照して、本実施例におけるフィルタリング処理について説明する。図８Ｉにおいて、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中から変更者ＬＢＬデータを構成するそれぞれの変更者特定ＬＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７０１）。
【０２３６】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、変更者ＬＢＬデータを構成するそれぞれの変更者特定ＬＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７０１でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７０５）。
【０２３７】
これにより、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄを最後に変更した変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであることを判断できる。また、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザである場合に、当該キャラクタを表示する前に非表示データとして設定できる。また、変更者ＬＢＬデータは、上述したようにＬＢＬ登録処理において自身のゲーム装置１０のユーザによる選択に応じてデータが登録される。従って、ＣＰＵ３１１は変更者ＬＢＬデータに基づいて非表示データを設定することにより、自身のゲーム装置１０のユーザが自ら登録したデータを表示しないように設定できる。
【０２３８】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中から変更者ＬＢＬデータを構成するそれぞれの変更者特定ＬＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７０１でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中から、データＬＢＬデータを構成するそれぞれのデータ特定ＬＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７１０）。
【０２３９】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中からデータＬＢＬデータを構成するそれぞれのデータ特定ＬＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７１０でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７１５）。
【０２４０】
これにより、ＣＰＵ３１１は、キャラクタが道徳上の観点から好ましくないキャラクタであることをデータＬＢＬに基づいて判断できる。そして、ＣＰＵ３１１は、ユーザ作成データＵｄによって示されるキャラクタに基づいて当該キャラクタを表示しないように設定できる。また、データＬＢＬデータは、上述したようにＬＢＬ登録処理においてＣＰＵ３１１自身のゲーム装置１０のユーザによる選択に応じてデータが登録される。従って、ＣＰＵ３１１は、データＬＢＬデータに基づいて非表示データを設定することにより、自身のゲーム装置１０のユーザが自ら登録したデータを表示しないように設定できる。
【０２４１】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中からデータＬＢＬデータを構成するそれぞれのデータ特定ＬＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７１０でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中から、変更者ＧＢＬデータを構成するそれぞれの変更者特定ＧＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７２０）。
【０２４２】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中から変更者ＧＢＬデータを構成するそれぞれの変更者特定ＧＢＬデータに含まれるアプリＩＤとユーザＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７２０でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７２５）。
【０２４３】
これにより、ＣＰＵ３１１は、キャラクタを最後に変更した変更者は道徳上の観点から好ましくないキャラクタを作成する変更者であることを変更者ＧＢＬに基づいて判断できる。そして、ＣＰＵ３１１は、キャラクタの外見に関わらずに最後の変更者に基づいて当該キャラクタを表示しないように設定できる。また、変更者ＧＢＬはサーバ５によって管理されるＧＢＬである。そして、後述するように、サーバ５は本システムに含まれる全てのゲーム装置１０のユーザそれぞれからの通報回数に基づいて変更者ＧＢＬを管理する。サーバ５が通報を受けるのは、上述したようにユーザが道徳上の観点から好ましくないと判断しさらに通報する選択をしたときである。従って、ＣＰＵ３１１は、変更者ＧＢＬを用いて非表示データを判断することにより、本システムに含まれるゲーム装置１０の全てのユーザの総意による判断に基づいて非表示データを設定できる。
【０２４４】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、変更者ＧＢＬデータを構成するそれぞれの変更者特定ＧＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７２０でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中に、データＧＢＬデータを構成するそれぞれのデータ特定ＧＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７３０）。
【０２４５】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、データＧＢＬデータを構成するそれぞれのデータ特定ＧＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７３０でＹｅｓ）当該ユーザ作成データＵｄを非表示データに設定する（ステップ７３５）。
【０２４６】
これにより、ＣＰＵ３１１は、キャラクタが道徳上の観点から好ましくないキャラクタであることをデータＧＢＬに基づいて判断できる。そして、ＣＰＵ３１１は、ユーザ作成データＵｄによって示されるキャラクタに基づいて当該キャラクタを表示しないように設定できる。また、データＧＢＬはサーバ５によって管理されるＧＢＬである。そして、後述するように、サーバ５は本システムに含まれる全てのゲーム装置１０のユーザそれぞれからの通報回数に基づいてデータＧＢＬを管理する。サーバ５が通報を受けるのは、上述したようにユーザが道徳上の観点から好ましくないと判断しさらに通報する選択をしたときである。従って、ＣＰＵ３１１は、データＧＢＬを用いて非表示データを判断することにより、本システムに含まれるゲーム装置１０の全てのユーザの総意に基づいて非表示データを設定できる。
【０２４７】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、データＧＢＬデータを構成するそれぞれのデータ特定ＧＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７３０でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中に、アプリＩＤがＮｕｌｌとなっている変更者特定ＧＢＬデータの変更者ＩＤと一致する変更者ＩＤのユーザ作成データＵｄが含まれているか否かを判断する（ステップ７４０）。
【０２４８】
ＣＰＵ３１１は、アプリＩＤがＮｕｌｌとなっている変更者特定ＧＢＬデータのユーザＩＤと一致する変更者ＩＤのユーザ作成データＵｄが含まれていると判断したとき（ステップ７４０でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７４５）。ＣＰＵ３１１は、アプリＩＤがＮｕｌｌとなっている変更者特定ＧＢＬデータの変更者ＩＤと一致する変更者ＩＤのユーザ作成データＵｄが含まれてないと判断した場合（ステップ７４０でＮｏ）または非表示データを設定した場合、フィルタリング処理を終了する。
【０２４９】
以上が、本実施例におけるフィルタリング処理の説明である。
【０２５０】
［ＧＢＬ更新処理］
次に、図８Ｊを参照して、本実施例におけるＧＢＬ更新処理を説明する。図８Ｊにおいて、ＣＰＵ３１１は、受信ボックスデータＪｂの中に新たに受信した受信ＧＢＬデータＪｇｄ（新着ＧＢＬ）が格納されているか否かを判断する（ステップ８０１）。ＣＰＵ３１１は、新たな受信ＧＢＬデータＪｇｄが格納されていると判断した場合（ステップ８０１でＹｅｓ）、当該受信ＧＢＬデータＪｇｄで示されるＧＢＬが新しいバージョンのＧＢＬであるか否かを判断する（ステップ８０５）。具体的には、ＣＰＵ３１１は、受信ＧＢＬデータＪｇｄで示されるＧＢＬのバージョンと、メインメモリ３２に既に格納しているＧＢＬデータＧｄで示されるＧＢＬのバージョンとを比較する。
【０２５１】
ＣＰＵ３１１は、受信ＧＢＬデータＪｇｄで示されるＧＢＬが新しいバージョンのＧＢＬであると判断した場合（ステップ８０５でＹｅｓ）、当該受信ＧＢＬデータＪｇｄで示されるＧＢＬでメインメモリ３２に格納されているＧＢＬデータＧｄを更新する（ステップ８１０）。そして、ＣＰＵ３１１は、更新したＧＢＬデータＧｄを送信ＧＢＬデータＳｇｄとして送信ボックスデータＳｄに格納する（ステップ８１５）。これにより、すれ違い通信によって受信した最新のＧＢＬをすれ違い通信によってさらに他のゲーム装置１０へ送ることができる。次に、ＣＰＵ３１１は、送信ＧＢＬデータＳｇｄを格納すると、受信ボックスデータＪｂに格納されている受信ＧＢＬデータＪｇｄを削除する（ステップ８２０）。
【０２５２】
一方、ＣＰＵ３１１は、新たな受信ＧＢＬデータＪｇｄが格納されていない場合（ステップ８０１でＮｏ）、受信ＧＢＬデータＪｇｄで示されるＧＢＬが新しいバージョンでない場合（ステップ８０５でＮｏ）、または受信ＧＢＬデータＳｇｄを削除したとき、インターネット通信処理でＧＢＬを受信したか否かを判断する（ステップ８２５）。具体的には、ＣＰＵ３１１は、メインメモリ３２にネット受信ＧＢＬデータＮｇｄが格納されているか否かを判断する。
【０２５３】
ＣＰＵ３１１は、インターネット通信処理でＧＢＬを受信したと判断した場合（ステップ８２５でＹｅｓ）、受信したネット受信ＧＢＬデータＮｇｄで示されるＧＢＬが新しいバージョンであるか否かを判断する（ステップ８３０）。具体的には、ＣＰＵ３１１は、メインメモリ３２に格納されているネット受信ＧＢＬデータＮｇｄで示されるＧＢＬのバージョンと、メインメモリ３２に既に格納されていたＧＢＬデータＧｄで示されるＧＢＬのバージョンとを比較する。
【０２５４】
ＣＰＵ３１１は、ネット受信ＧＢＬデータＮｇｄで示されるＧＢＬが新しいバージョンであると判断したとき（ステップ８３０でＹｅｓ）、当該ＧＢＬを示すようにメインメモリ３２に格納されているＧＢＬデータＧｄを更新する（ステップ８３５）。そして、ＣＰＵ３１１は、更新したＧＢＬデータＧｄを送信ＧＢＬデータＳｇｄとして送信ボックスデータＳｄに格納する（ステップ８４０）。これにより、インターネット通信処理で受信した最新のＧＢＬをすれ違い通信によって他のゲーム装置１０へ送ることができる。ＣＰＵ３１１は、ＧＢＬを更新すると、ネット受信ＧＢＬデータＮｇｄを削除する（ステップ８４５）。
【０２５５】
一方、ＣＰＵ３１１は、インターネット通信処理でＧＢＬを受信していないと判断した場合（ステップ８２５でＮｏ）、ネット受信ＧＢＬデータＮｇｄで示されるＧＢＬが新しいバージョンでないと判断した場合（ステップ８３０でＮｏ）、またはネット受信ＧＢＬデータＮｇｄを削除したとき、ＧＢＬ更新処理をはじめから繰り返す。
【０２５６】
以上が、本実施例におけるＧＢＬ更新処理の説明である。上述で説明したように、ＣＰＵ３１１は、他の処理を実行しているか否かに関わらず、ＧＢＬ更新処理を繰り返し実行する。これにより、ＣＰＵ３１１は、すれ違い通信処理で受信ＧＢＬデータＪｇｄを格納したときまたはインターネット通信処理でネット受信ＧＢＬデータＮｇｄを格納したときに、新しいバージョンのＧＢＬを示すか否かを常に確認できる。そして、ＣＰＵ３１１は、新しいバージョンのＧＢＬを示すデータを受信したときには、即座にＧＢＬデータＧｄを更新して、常に最新のバージョンのＧＢＬを記憶しておくことができる。また、ＣＰＵ３１１は、すれ違い通信で受信した受信ＧＢＬデータＪｇｄによって示されるＧＢＬや、インターネット通信で受信したネット受信ＧＢＬデータＮｇｄが新しいバージョンである場合には、当該受信ＧＢＬデータＪｇｄを送信ＧＢＬデータＳｇｄとして格納する。従って、ＣＰＵ３１１は、新しいバージョンのＧＢＬを即座にすれ違い通信で他のゲーム装置１０に自動的に送信できる。
【０２５７】
［サーバ処理］
次に、図９を参照して、サーバ５で実行されるプログラムによる具体的な処理について説明する。なお、図９は、サーバ処理プログラムを実行することによってサーバ５がサーバ処理を行う一例を示すフローチャートである。なお、この処理を実行するためのプログラムは、ＨＤＤ５４に格納されており、サーバ５の電源がオンになったときに、通信バス５６を介してＨＤＤ５４からメインメモリ５５に読み出されて、ＣＰＵ５１によって実行される。
【０２５８】
図９において、ＣＰＵ５１は、ユーザによって通報されたユーザ作成データＵｄを受信したか否かを判断する（ステップ９０１）。ＣＰＵ５１は、通報されたユーザ作成データＵｄを受信したと判断した場合（ステップ９０１でＹｅｓ）、受信したユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとからなるデータカウントデータがＨＤＤ５４に既に格納されているか否かを判断する（ステップ９０３）。ＣＰＵ５１は、データカウントデータが格納されていないと判断したとき（ステップ９０３でＮｏ）、受信したユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとからなるデータカウントデータを新規に作成してメインメモリ５５に格納する（ステップ９０４）。このとき作成されるデータカウントデータに含まれる通報回数の初期値は１となる。
【０２５９】
一方、ＣＰＵ５１は、データカウントデータが格納されていると判断したとき（ステップ９０３でＹｅｓ）、当該データカウントデータの通報回数を１だけ加算してカウントする（ステップ９０５）。
【０２６０】
次に、ＣＰＵ５１は、メインメモリ５５に格納されている全てのデータカウントデータの中に通報回数が第１の閾値ｔｈ１以上であるデータカウントデータが存在するか否かを判断する（ステップ９１０）。これにより、ＣＰＵ５１は、本システムに含まれる全てのユーザそれぞれからの通報回数に基づいて、通報されたユーザ作成データＵｄによって示されるキャラクタが道徳上の観点から好ましくないキャラクタであるか否かを判断できる。なお、今回新規作成又はカウントを行ったデータカウントデータについてのみ、ステップ９１０の判断を行うようにしてもよい。
【０２６１】
ＣＰＵ５１は、通報回数が第１の閾値ｔｈ１以上であるデータカウントデータが存在すると判断した場合（ステップ９１０でＹｅｓ）、データ特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加する（ステップ９１５）。このとき、配信用ＧＢＬデータＧｓｄに追加されるのは、通報回数が第１の閾値ｔｈ１以上となるデータカウントデータのそれぞれに含まれるデータＩＤとアプリＩＤとをそれぞれ含むデータ特定ＧＢＬデータである。これにより、ＣＰＵ５１は、ユーザ作成データＵｄの中から道徳上の観点から好ましくないキャラクタを示すデータを特定するためのデータ特定用ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加することができる。
【０２６２】
次に、ＣＰＵ５１は、ユーザによって通報されたユーザ作成データＵｄに含まれるユーザＩＤとアプリＩＤとからなるユーザカウントデータがＨＤＤ５４に格納されているか否かを判断する（ステップ９１７）。ＣＰＵ５１は、ユーザカウントデータが格納されていないと判断したとき（ステップ９１７でＮｏ）、受信したユーザ作成データＵｄに含まれる変更者ＩＤとアプリＩＤとからなるユーザカウントデータを新規に作成してＨＤＤ５４に格納する（ステップ９１９）。このとき作成されるユーザカウントデータに含まれる通報回数の初期値は１となる。
【０２６３】
一方、ＣＰＵ５１は、ユーザカウントデータが格納されていると判断したとき（ステップ９１７でＹｅｓ）、当該データカウントデータの通報回数を１だけ加算してカウントする（ステップ９２０）。
【０２６４】
次に、ＣＰＵ５１は、メインメモリ５５に格納されている全てのユーザカウントデータの中に通報回数が第２の閾値ｔｈ２以上のユーザカウントデータが存在するか否かを判断する（ステップ９２５）。これにより、ＣＰＵ５１は、本システムに含まれる全てのユーザそれぞれからの通報回数に基づいて、通報されたユーザ作成データＵｄの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるか否かを判断できる。なお、今回新規作成又はカウントを行ったデータカウントデータについてのみ、ステップ９２５の判断を行うようにしてもよい。
【０２６５】
ＣＰＵ５１は、通報回数が第２の閾値ｔｈ２以上のユーザカウントデータが存在すると判断した場合（ステップ９２５でＹｅｓ）、ユーザ特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加する（ステップ９３０）。このとき、配信用ＧＢＬデータＧｓｄに追加されるのは、通報回数が第２の閾値ｔｈ２以上となるユーザカウントデータのそれぞれに含まれる変更者ＩＤとアプリＩＤとをそれぞれ含むユーザ特定ＧＢＬデータである。これにより、ＣＰＵ５１は、ユーザ作成データＵｄの中から最後の変更者を道徳上の観点から好ましくないキャラクタを作成するユーザとして示すデータを特定するための変更者特定用ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加することができる。
【０２６６】
ＣＰＵ５１は、ユーザ特定ＧＢＬデータを追加する（ステップ９３０）または第２の閾値ｔｈ２以上のユーザカウントデータがないと判断した場合（ステップ９２５でＮｏ）、サーバ処理をはじめから繰り返す。
【０２６７】
なお、図９のフローチャートには図示していないが、ＣＰＵ５１は、配信用ＧＢＬデータＧｓｄを本システムに含まれるゲーム装置１０のそれぞれに送信する処理を並行して行っているものとする。当該処理は、本システムに含まれるゲーム装置１０のそれぞれによって配信用ＧＢＬデータＧｓｄを受信するタスクが実行されたことに応じて実行されるものとする。
【０２６８】
次に、上述で説明したサーバ処理において用いられる第１の閾値ｔｈ１および第２の閾値ｔｈ２について説明する。第２の閾値ｔｈ２は、第１の閾値ｔｈ１よりも大きくなるように予め定められるものとする。上述の説明から明らかなように、ＣＰＵ５１は、ユーザ作成データＵｄが通報される度に、当該ユーザ作成データＵｄに対応するユーザカウントデータの通報回数と、当該ユーザ作成データＵｄに対応するデータカウントデータの通報回数とがそれぞれ加算される。
【０２６９】
そして、データＩＤとアプリＩＤとを含むデータカウントデータで示される通報回数は最も低い第１の閾値ｔｈ１と比較され、変更者ＩＤとアプリＩＤとを含むユーザカウントデータで示される通報回数は第１の閾値ｔｈ１よりも大きい第２の閾値ｔｈ２と比較される。
【０２７０】
ここで、本システムにおいて、同一のデータＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報と同一の変更者ＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報とがそれぞれ繰り返された場合を想定する。この場合、本システムでは、まず始めに、データカウントデータで示される通報回数が第１の閾値ｔｈ１以上となる。そして、ユーザ作成データＵｄで示されるキャラクタに基づいてゲーム装置１０が非表示データを設定できるように、データ特定ＧＢＬデータが先に配信用ＧＢＬデータＧｓｄに追加される。
【０２７１】
そして、さらに、同一のデータＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報と同一の変更者ＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報とがそれぞれ続けて繰り返された場合を想定する。この場合、本システムでは、データカウントデータの通報回数が第１の閾値ｔｈ１以上となった後に、ユーザカウントデータの通報回数が第２の閾値ｔｈ２以上となる。従って、本システムでは、ユーザ作成データＵｄで示されるキャラクタに基づいてゲーム装置１０によって非表示データが設定されるようになった後、ユーザ作成データＵｄで示される最後の変更者ＩＤに基づいて非表示データを設定できるように、変更者特定ＧＢＬデータが配信用ＧＢＬデータＧｓｄに追加される。
【０２７２】
ユーザ特定ＧＢＬデータの変更者ＩＤで示されるユーザは、当該ユーザ特定ＧＢＬデータに含まれるアプリＩＤで示されるキャラクタ取り扱いアプリケーションで取り扱われるユーザ作成データＵｄを送受信しても他のゲーム装置１０にはキャラクタが表示されなくなる。従って、ユーザ作成データＵｄの最後の変更者ＩＤがアプリＩＤと共に変更者特定ＧＢＬデータとして追加されると当該変更者ＩＤのユーザは当該アプリＩＤで示されるアプリケーションによって提供される楽しみを奪われてしまう。このような状況は、アプリケーションの製造元としてもなるべく避けたいので、上述で説明したサーバ処理では、通報回数が第１の閾値ｔｈ１よりも大きい第２の閾値ｔｈ２以上となったときにユーザ作成データＵｄで示される最後の変更者ＩＤが当該ユーザ作成データＵｄのアプリＩＤと共に変更者特定ＧＢＬデータとして登録される。
【０２７３】
以上が、本実施例におけるサーバ処理の説明である。上述したサーバ処理によれば、ＣＰＵ５１は、本システムに含まれるゲーム装置１０のそれぞれからの通報に基づいて、配信用ＧＢＬデータＧｓｄで示される情報を最新の情報に常に更新できる。
【０２７４】
以上が、本システムの説明である。本システムによれば、当該システムに含まれるそれぞれのゲーム装置１０において互いに送受信されるユーザ作成データＵｄで示されるキャラクタの中から道徳上の観点から好ましくないキャラクタが出力されてユーザに表示されることを防げる。例えば、上述したキャラクタ取り扱い画面において上側ＬＣＤ２２に道徳上の観点から好ましくないキャラクタが表示されるのを防げる。また、例えば、上述したキャラクタ編集画面において上側ＬＣＤ２２に１つだけ表示されるキャラクタとして道徳上の観点から好ましくないキャラクタが表示されるのを防げる。
【０２７５】
なお、上述の説明では、ユーザ作成データＵｄを取り扱うアプリケーションとして、キャラクタ取り扱いアプリケーションを一例に挙げて説明した。本システムにおけるアプリケーションの他の一例としては、ユーザが自由に楽曲を作成することができる楽曲作成プログラムが挙げられる。この場合、ユーザによって作成された楽曲を示すデータがユーザ作成データＵｄとなる。また、この場合、ユーザ作成データＵｄに含まれるアプリＩＤは、楽曲作成アプリケーションを示すアプリＩＤとなる。また、この場合、ユーザ作成データＵｄに含まれるデータ本文は楽曲の内容を示すデータ本文となる。また、本システムにおけるアプリケーションの他の一例としては、マイク４３を用いて入力した音声などを用いて作成したユーザ作成データＵｄを取り扱うアプリケーションも挙げられる。
【０２７６】
つまり、本システムでは、キャラクタなどの表示オブジェクト、楽曲および音声などの任意のアプリケーションを用いて作成される任意の内容（コンテンツ）を示すユーザ作成データＵｄを対象とすることができる。これにより、本システムでは、表示オブジェクトなど表示装置に表示出力されることによってユーザに提供されるコンテンツ、楽曲および音声などスピーカ４４を用いて音声出力されることによってユーザに提供されるコンテンツなどの中からユーザにとって不適切なコンテンツを提供すべきでないコンテンツとしてＧＢＬおよびＬＢＬの少なくとも一方を用いて特定できる。
【０２７７】
その他、ユーザ作成データＵｄの例としては、タッチパネル１３への入力により手書きでなされたメッセージや、タッチパネル１３、操作ボタン１４又はキーボードなどの周辺機器により入力された、任意の文字列データなどを挙げることができる。また、アプリケーションプログラムのセキュリティホール等を狙って、アプリケーションプログラムの動作を停止させたり、アプリケーションプログラムの異常動作を引き起こしたりするようなユーザ作成データＵｄを対象とすることで、アプリケーションプログラムの停止や異常動作を未然に防ぐことができる。
【０２７８】
また、上述の説明では、作成者ＩＤ、変更者ＩＤ、アプリＩＤおよびデータＩＤなどを、データ本文（コンテンツ）の作成時に関連する情報（以下、作成情報と称する）、または、当該コンテンツに関連する情報（以下、コンテンツ情報と称する）として当該コンテンツを含むユーザ作成データＵｄに付与する場合を一例として説明した。そして、ＧＢＬデータＧｄおよびＬＢＬデータＬｄには、作成情報またはコンテンツ情報に含まれる作成者ＩＤ、変更者ＩＤ、アプリＩＤおよびデータＩＤの中から作成者ＩＤと変更者ＩＤとの組み合わせを除く少なくとも２つのＩＤを追加するものとした。この場合、ゲーム装置１０では、上述で説明したように、ＧＢＬデータＧｄまたはＬＢＬデータＬｄに前述の２つのＩＤが含まれていれば、一致するＩＤを含むユーザ作成データＵｄに含まれるコンテンツがユーザに提供すべきでないコンテンツとして特定されることとなる。
【０２７９】
また、上述の説明では、すれ違い通信においてＧＢＬが送信ＧＢＬデータＳｇｄ或いは受信ＧＢＬデータＪｇｄとして送受信して交換される場合を一例として説明した。しかしながら、他の一実施形態では、ＬＢＬもＧＢＬと同様にすれ違い通信で交換してもよい。
【０２８０】
また、上述の説明では、ユーザが通報するときには通報するユーザ作成データＵｄを送信するものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄに付与されている作成者ＩＤ、変更者ＩＤ、アプリＩＤおよびデータＩＤの中から任意の組み合わせのＩＤを送信してもよい。そして、サーバ５のＣＰＵ５１は、送信されたＩＤを用いて上述したデータカウントデータおよびユーザカウントデータもしくは、当該データカウントデータおよび当該ユーザカウントデータにおける組み合わせとは異なる組み合わせのＩＤで通報回数をカウントするためのカウントデータを用いて通報回数をカウントしてもよい。
【０２８１】
また、上述の説明では、ゲーム装置１０は、配信用ＧＢＬデータＧｓｄを受信するためのタスクを定期的に実行して受信する場合を一例として説明した。しかしながら、他の一実施形態では、サーバ５のＣＰＵ５１が、通信可能なゲーム装置１０に定期的に配信用ＧＢＬデータＧｓｄを送信するようにしてもよい。
【０２８２】
また、上述の説明では、上述したコンテンツの一例としてキャラクタが道徳上の観点から好ましくない場合に表示されないように設定する場合を説明した。しかしながら、他の一実施形態では、道徳上の観点から好ましくない不適切でユーザに提供するべきでないコンテンツを提供することのできる所定のコンテンツに置き換えることによって不適切なコンテンツをユーザに提供しないようにしてもよい。さらに、他の一実施形態では、不適切なコンテンツを含むユーザ作成データＵｄを削除するようにしてもよい。
【０２８３】
また、上述の説明では、ＧＢＬのバージョンを比較するために、配信用ＧＢＬデータＧｓｄをネット受信ＧＢＬデータＮｇｄとしてメインメモリ３２に格納した後、新しいバージョンであるときにＧＢＬデータＧｄを更新するものとした。しかしながら、他の一実施形態では、配信用ＧＢＬデータＧｓｄでメインメモリ３２に格納されているＧＢＬデータＧｄを直接更新してもよい。これにより、配信用ＧＢＬデータＧｓｄが常に最新のバージョンのＧＢＬを示すデータとしてメインメモリ３２に格納されているＧＢＬデータＧｄを更新できる。
【０２８４】
また、上述の説明では、すれ違い通信およびローカル通信が、同じローカル通信モジュール３７を用いて行われるものとした。ここで、すれ違い通信処理による通信とローカル通信処理による通信とが同時に発生する場合には、互いの処理を時分割で行う、或いは互いの処理で送受信するデータを時分割するなどの手法を用いることにより、両方の通信の両立が可能である。
【０２８５】
また、上述の説明では、ユーザ作成データＵｄに含まれるデータＩＤがデータ本文をアプリケーション毎に一意に識別するためのＩＤであるものとした。しかしながら、他の一実施形態では、データＩＤは、アプリケーションに関わらずデータ本文を一意に識別するためのＩＤとしてもかまわない。この場合、データ特定ＬＢＬデータおよびデータ特定ＧＢＬデータには、当該データＩＤのみを含むようにする。これにより、フィルタリング処理において、フィルタリング対象のユーザ作成データＵｄに含まれるデータＩＤのみをデータ特定ＬＢＬデータおよびデータ特定ＧＢＬデータとそれぞれ比較して非表示データを特定することができる。
【０２８６】
また、上述の説明では、配信用ＧＢＬデータＧｓｄ、ユーザ特定用カウントデータＵｃｄおよびデータ特定用カウントデータＤｃｄがサーバ５のメインメモリ５５に格納されるものとした。しかしながら、他の一実施形態では、配信用ＧＢＬデータＧｓｄ、ユーザ特定用カウントデータＵｃｄおよびデータ特定用カウントデータＤｃｄの少なくともいずれか１つをサーバ５のＨＤＤ５４に格納するようにしてもよい。
【０２８７】
また、上述の説明では、ＧＢＬデータＧｄに含まれるアプリＩＤおよび配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄに含まれるアプリＩＤは、例外的なアプリＩＤであるものとした。しかしながら、他の一実施形態では、ＧＢＬデータＧｄおよび配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄに含まれるアプリＩＤは、例外的なアプリＩＤでなくてもよい。具体的には、ＧＢＬデータＧｄを取り扱うアプリケーションを仮想した場合のアプリＩＤであってもよいし、上述したサーバ処理プログラムをアプリケーションプログラムと見なした場合の当該アプリケーションプログラムに付与されているアプリＩＤであってもよい。
【０２８８】
また、上述の説明では、ユーザ作成データＵｄの最後の変更者ＩＤとアプリＩＤとを含むデータを変更者特定ＧＢＬデータとして追加するものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄの作成者ＩＤとアプリＩＤとを含むデータを変更者特定ＧＢＬデータと同様に追加して用いてもよい。この場合、ゲーム装置１０はユーザ作成データＵｄに含まれる作成者ＩＤとアプリＩＤとの両方が変更者特定ＧＢＬデータに含まれる作成者ＩＤとアプリＩＤとの両方と一致したときに当該ユーザ作成データＵｄを非表示データに設定すればよい。また、この場合、ユーザがユーザ作成データＵｄを通報することによって、当該ユーザ作成データＵｄに含まれる作成者ＩＤのユーザが道徳上の観点から好ましくないキャラクタを作成したユーザとして通報される。
【０２８９】
また、上述の説明では、変更者ＩＤとアプリＩＤとからなるユーザカウントデータおよびデータＩＤとアプリＩＤとからなるデータカウントデータに基づいて変更者特定ＧＢＬデータおよびデータ特定ＧＢＬデータをそれぞれ配信用ＧＢＬデータＧｓｄに追加するものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄの最後の変更者ＩＤ毎に、通報されたユーザ作成データＵｄの数を通報回数としてさらにカウントしてもよい。そして、カウントした通報回数が所定の第３の閾値ｔｈ３以上となったときに当該変更者ＩＤと全てのアプリケーションを示すアプリＩＤとを含む変更者特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加するようにしてもよい。これにより、複数のアプリケーションを用いて、道徳上の観点から好ましくないユーザ作成データＵｄを作成するユーザを特定するための変更者特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加することができる。なお、全てのアプリケーションを示すアプリＩＤとは、ゲーム装置１０で実行し得る全てのアプリケーションを示すアプリＩＤとして予め定められたＩＤであればどのようなＩＤであってもよい。一例としては、Ｎｕｌｌで示されるアプリＩＤが挙げられる。この場合、ゲーム装置１０は、受信したユーザ作成データＵｄの最後の変更者ＩＤのみが変更者特定ＧＢＬデータに含まれる変更者ＩＤと一致すれば、アプリＩＤに関わらず当該ユーザ作成データＵｄを非表示データとして設定できる。すなわち、変更者特定ＧＢＬデータに含まれる変更者ＩＤのユーザは、ユーザ作成データＵｄを作成するためにどのようなアプリケーションを用いたとしても、送信したユーザ作成データＵｄで示されるデータが他のゲーム装置１０に表示されることはない。従って、この場合に追加される変更者特定ＧＢＬデータの変更者ＩＤで示されるユーザは、本システムにおいて、データを他のゲーム装置１０に一切送信できなくなる。このように、広範囲の制限を与えてしまうので、第３の閾値ｔｈ３は、第１の閾値ｔｈ１や第２の閾値ｔｈ２よりも高い値となることが望ましい。
【０２９０】
また、上述の説明では、ユーザ作成データＵｄには、作成者ＩＤおよび１以上の追加された変更者ＩＤが含まれる場合を一例として説明した。しかしながら、他の一実施形態では、作成者ＩＤを保持せず、また、変更者ＩＤも複数保持せずに最後の変更者ＩＤのみを含むユーザ作成データＵｄを用いてもよい。この場合、ユーザ作成データＵｄを新規に作成したときには最後の変更者ＩＤに作成者のＩＤが記録され、ユーザ作成データＵｄが変更される度に、変更したユーザを示すＩＤが最後の変更者ＩＤとして上書きされることとなる。
【０２９１】
さらに、他の一実施形態では、作成者ＩＤと変更者ＩＤとを１つずつ含むユーザ作成データＵｄを用いてもよい。この場合、ユーザ作成データＵｄが変更される度に変更したユーザを示すＩＤが変更者ＩＤとして上書きされる。また、この場合、ユーザ作成データＵｄに含まれる変更者ＩＤが最後の変更者を示すＩＤとなるので、このようなユーザ作成データＵｄは、そのまま上述で説明した実施形態で用いることが可能である。
【０２９２】
また、上述の説明では、ユーザ作成データＵｄで示されるキャラクタをＬＢＬに登録するときにユーザは変更者ＬＢＬまたはデータＬＢＬの中から登録するＬＢＬを選択できるものとした。しかしながら、他の一実施形態では、ユーザによってキャラクタのＬＢＬへの登録が選択されたときには、当該キャラクタを変更者ＬＢＬとデータＬＢＬとの両方に登録するようにしてもよい。
【０２９３】
また、上述の説明では、ユーザ作成データＵｄの最後の変更者ＩＤを変更者特定ＧＢＬデータに含ませるものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄに含まれる作成者ＩＤおよび変更者ＩＤの中から変更者特定ＧＢＬデータに変更者ＩＤとして含ませるＩＤを選択できるようにしてもよい。
【０２９４】
また、上述の説明では、第１の閾値ｔｈ１が第２の閾値ｔｈ２以下であるものとして説明した。しかしながら、他の一実施形態では、必ずしも第１の閾値ｔｈ１が第２の閾値ｔｈ２以下でなくてもよい。ただし、上述したように第１の閾値ｔｈ１が第２の閾値ｔｈ２以下としたのは、ユーザ作成データＵｄの最後の変更者ＩＤがアプリＩＤと共に変更者特定ＧＢＬデータとして追加された場合に、当該変更者ＩＤのユーザは当該アプリＩＤで示されるアプリケーションによって提供される楽しみを奪われてしまう状況を避けるためである。従って、第１の閾値ｔｈ１が第２の閾値ｔｈ２以下でなくなるようにそれぞれの閾値を予め定める場合には、前述の状況を避けなくてもよい場合に限る。
【０２９５】
また、他の一実施形態では、ゲーム装置１０が「通常電力モード」と「省電力モード」の２つの電源制御モードのいずれかで動作するようにしてもよい。「通常電力モード」は、ゲーム装置１０の構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーションを実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。また、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、無線通信モジュール３６およびローカル通信モジュール３７にのみ電源を供給し、それ以外の部品、つまり、ＬＣＤなどへの電力供給は停止している状態である。上述の説明では、ゲーム装置１０をオンにした後は、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理を互いに並行して繰り返して行うものとした。このことは、ゲーム装置１０が上記「通常電力モード」と「省電力モード」の２つの電源制御モードのいずれかで動作する場合も同様にしてよい。すなわち、ゲーム装置１０は、「スリープモード」で動作している場合でもすれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理を互いに並行して繰り返して行ってもよい。
【０２９６】
また、上述の説明では、ユーザに提供すべきでないコンテンツを含むユーザ作成データＵｄを特定するためにアプリＩＤおよびデータＩＤなどを用いるものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄ毎に計算したハッシュ値を用いてユーザに提供すべきでないコンテンツを含むユーザ作成データＵｄを特定してもよい。また、他の一実施形態では、ユーザ作成データＵｄに含まれるデータ本文（コンテンツ）そのものをＧＢＬまたはＬＢＬに登録して用いてもよい。
【０２９７】
また、上述の説明では、ゲーム装置１０が複数のアプリケーションを選択的に実行できることを説明した。しかしながら、仮に、ゲーム装置１０が１つのアプリケーションしか実行できないのであれば、ユーザに提供すべきでないコンテンツを含むユーザ作成データＵｄを特定するのに、アプリＩＤを用いなくてもよいことは言うまでもない。
【０２９８】
また、上述の説明では、ＣＰＵ３１１が、ＧＢＬデータＧｄを更新するときには新しいＧＢＬのＧＢＬデータＧｄを既に格納されているＧＢＬデータＧｄに上書きして更新するものとして説明した。しかしながら、他の一実施形態では、新しいＧＢＬデータＧｄの一部（例えば、既に格納されているＧＢＬデータＧｄとの差分）を追加或いは全部を上書きすることによって、既に格納されているＧＢＬデータＧｄを更新してもよい。
【０２９９】
また、上述の説明では、サーバ５のＣＰＵ５１が上述したサーバ処理を行うことによりユーザからの通報回数を自動的に集計してＧＢＬに提供するべきでないコンテンツを含むユーザ作成データＵｄを特定するためのデータを登録するものとした。しかしながら、他の一実施形態では、提供するべきでないコンテンツを含むユーザ作成データＵｄを特定するためのデータの登録を、例えば、サーバ５の使用者などによる手動で行うようにしてもよい。より詳細には、例えば、サーバ５において、ユーザ作成データＵｄの通報回数が所定の閾値以上となったときに当該ユーザ作成データＵｄが道徳上の観点から好ましくないコンテンツを示すデータであるとしてサーバ５の使用者に通知をするように構成してもよい。これにより、サーバ５の使用者は通知を受けたときに通知されたデータのコンテンツを目視してＧＢＬに登録するべきか否かを判断してから必要に応じて登録することができる。
【０３００】
また、上述の説明では、サーバ５から受信した配信用ＧＢＬデータＧｓｄで示されるＧＢＬのバージョンが新しい場合に、メインメモリ３２に格納されているＧＢＬデータＧｄを更新するものとした。しかしながら、他の一実施形態では、配信用ＧＢＬデータＧｓｄで示されるＧＢＬの更新日時が新しい場合に、メインメモリ３２に格納されているＧＢＬデータＧｄを更新するようにしてもよい。
【０３０１】
また、上述の説明では、ユーザが道徳上の観点から好ましくないコンテンツを示すユーザ作成データＵｄを通報するときには、当該ユーザ作成データＵｄがそのままサーバ５に送信されるものとした。しかしながら、他の一実施形態では、ユーザがユーザ作成データＵｄを通報するときに、通報するユーザ作成データＵｄに含まれるユーザＩＤとデータＩＤとの組み合わせをサーバ５に送信して通報するようにしてもよい。そして、サーバ５は、ユーザＩＤとデータＩＤとの組み合わせの送信回数が上述した第１の閾値以上となったときに当該組み合わせにおけるデータＩＤを配信用ＧＢＬデータＧｓｄのデータ特定ＧＢＬデータとしてデータＧＢＬデータに追加して更新するようにしてもよい。さらに、この場合、サーバ５は、ユーザＩＤとデータＩＤとの組み合わせの送信回数が上述した第２の閾値以上となったときに当該組み合わせにおけるユーザＩＤを配信用ＧＢＬデータＧｓｄの変更者特定ＧＢＬデータとして変更者ＧＢＬデータに追加して更新するようにしてもよい。
【０３０２】
また、上述の説明では、ユーザが道徳上の観点から好ましくないコンテンツを示すユーザ作成データＵｄを通報するときには、当該ユーザ作成データＵｄがそのままサーバ５に送信されるものとした。しかしながら、他の一実施形態では、ユーザがユーザ作成データＵｄを通報するときに、通報するユーザ作成データＵｄに含まれるユーザＩＤとアプリＩＤとの組み合わせをサーバ５に送信して通報するようにしてもよい。そして、サーバ５は、ユーザＩＤとアプリＩＤとの組み合わせの送信回数が上述した第２の閾値以上となったときに当該組み合わせのユーザＩＤとアプリＩＤとを配信用ＧＢＬデータＧｓｄの変更者特定ＧＢＬデータとして変更者ＧＢＬデータに追加して更新するようにしてもよい。さらに、この場合、サーバ５は、ユーザＩＤとアプリＩＤとの組み合わせの送信回数が上述した第３の閾値以上となったときに、当該組み合わせにおけるユーザＩＤと上述した全てのアプリケーションを示すアプリＩＤとの組み合わせを、配信用ＧＢＬデータＧｓｄの変更者特定ＧＢＬデータとして変更者ＧＢＬデータに追加して更新するようにしてもよい。
【０３０３】
また、上述の説明では、ローカル通信モジュール３７を用いてすれ違い通信を行うものとした。しかしながら、他の一実施形態では、無線通信モジュール３６を用いてＡＰ２との間ですれ違い通信をしてもよい。これにより、インターネット通信網３を介したすれ違い通信を行うことができる。また、赤外線通信などの通信方式を用いてもよい。
【０３０４】
また、上述の説明では、ＧＢＬデータＧｄ或いはＬＢＬデータＬｄに登録されるデータはユーザ作成データＵｄによって示されるコンテンツを特定するための情報（ユーザＩＤ、データＩＤなど）であるものとして説明した。しかしながら、他の一実施形態では、ゲーム装置１０などの情報処理装置を対象として作成されたウイルスプログラムを特定するための情報をＧＢＬデータＧｄ或いはＬＢＬデータＬｄに登録するようにしてもよい。この場合、ウイルスプログラムを特定したデータをすれ違い通信等で伝播させることができるので、上述で説明したような道徳上の観点から好ましくないコンテンツと同様にウイルスプログラムの蔓延を未然に防止できる。
【０３０５】
また、上述の説明では、ユーザ作成データＵｄを特定するための情報に基づいてユーザに出力するか否かを決定する場合について説明した。しかしながら、他の一実施形態では、ユーザ作成データＵｄの送信元のアドレスに基づいてユーザに出力するか否かを判別してもよい。また、ユーザ作成データＵｄによって示されるコンテンツがメールである場合には、メールの送信元のアドレスに基づいて当該メールをユーザに表示出力するか否か判別してもよい。この場合、ＧＢＬデータＧｄ或いはＬＢＬデータＬｄには、このような送信元のアドレスが登録され、すれ違い通信等で伝播されることになる。
【０３０６】
また、上述の説明では、２画面分の液晶表示部の一例として、物理的に分離された下側ＬＣＤ１２および上側ＬＣＤ２２を互いに上下に配置した場合（上下２画面の場合）を説明した。しかしながら、２画面分の表示画面の構成は、他の構成でもかまわない。例えば、下側ハウジング１１の一方主面に下側ＬＣＤ１２および上側ＬＣＤ２２を左右に配置してもかまわない。また、下側ＬＣＤ１２と横幅が同じで縦の長さが２倍のサイズからなる縦長サイズのＬＣＤ（すなわち、物理的には１つで、表示サイズが縦に２画面分あるＬＣＤ）を下側ハウジング１１の一方主面に配設して、２つの画像を上下に表示（すなわち上下の境界部分無しに隣接して表示）するように構成してもよい。また、下側ＬＣＤ１２と縦幅が同じで横の長さが２倍のサイズからなる横長サイズのＬＣＤを下側ハウジング１１の一方主面に配設して、横方向に２つのゲーム画像を左右に表示（すなわち左右の境界部分無しに隣接して表示）するように構成してもよい。すなわち、物理的に１つの画面を２つに分割して使用することにより２つの画像を表示してもかまわない。いずれの画像の形態に対しても、上述した下側ＬＣＤ１２に表示していた表示画像が表示される画面上にタッチパネル１３を配設すれば、同様に本発明を実現することができる。また、物理的に１つの画面を２つに分割して使用することにより上記２つの画像を表示する場合、当該画面全面にタッチパネル１３を配設してもかまわない。
【０３０７】
また、上述の説明では、ゲーム装置１０にタッチパネル１３が一体的に設けられているが、ゲーム装置とタッチパネルとを別体にして構成しても、本発明を実現できることは言うまでもない。
【０３０８】
また、上述の説明では、座標入力を実現するゲーム装置１０の入力手段としてタッチパネル１３を用いたが、他のポインティングデバイスを用いてもかまわない。ここで、ポインティングデバイスは、画面上での入力位置や座標を指定する入力装置であり、例えば、マウス、トラックパッド、トラックボール等を入力手段として使用し、入力手段から出力される出力値から計算された画面座標系の位置情報を用いれば、本発明を同様に実現することができる。
【０３０９】
また、ゲームコントローラをユーザが把持してゲームを楽しむ据置型のゲーム装置の場合、他の態様のポインティングデバイスも考えられる。例えば、ゲームコントローラのハウジングに固設されたカメラを、上記ポインティングデバイスとして利用することも可能である。この場合、ゲームコントローラのハウジングで指し示した位置の変化に応じてカメラが撮像する撮像画像が変化する。従って、この撮像画像を解析することにより、表示画面に対して上記ハウジングで指し示した座標を算出することができる。なお、本発明においては、ゲーム装置１０にタッチパネル１３等のポインティングデバイス自体が設けられていなくても実現可能であることは言うまでもない。
【０３１０】
また、上記実施例では、携帯型のゲーム装置１０や据置型のゲーム装置を用いて説明したが、一般的なパーソナルコンピュータ等の情報処理装置で本発明の画像通信プログラムを実行して、本発明を実現してもかまわない。
【０３１１】
また、上述したゲーム装置１０の形状や、それに設けられている各種操作ボタン１４やタッチパネル１３の形状、数、および設置位置等は、単なる一例に過ぎず、他の形状、数、および設置位置であっても、本発明を実現できることは言うまでもない。また、上述した画像通信処理で用いられる各ステップの実行順序や画面表示例等は、単なる一例に過ぎず、他の実行順序や画面表示であっても、本発明を実現できることは言うまでもない。
【０３１２】
また、上述した説明では、上記情報処理プログラムの一例としてゲームプログラムが情報処理部３１で実行される例を用いたが、本実施形態に係る情報処理プログラムの少なくとも一部を、当該情報処理部３１と通信可能な他の装置に備えられた少なくともＣＰＵを含む情報処理部で実行してもかまわない。本実施形態に係る情報処理プログラムの一例として上記ゲームプログラムを実行する場合には、例えば、ゲーム装置１０が他の装置（例えば、サーバなど）と通信可能に構成されている場合、上記ゲームプログラムにおける処理は、ゲーム装置１０および当該他の装置が協働することによって実行してもよい。一例として、他の装置において上記ゲームプログラムが実行され、当該ゲームプログラムの実行に必要な操作入力の検出、当該ゲームプログラムの実行に必要な表示を行う表示装置などは、それぞれゲーム装置１０のタッチパネル１３、上側ＬＣＤ２２および／または下側ＬＣＤ１２を用いるように構成したゲームシステムにおいて、上記ゲームプログラムを実行してもよい。このことは、本実施形態に係る情報処理プログラムの他の一例として上述した動作制御プログラムについても同様である。つまり、本実施形態に係る情報処理プログラムは、一例として、他の装置において当該情報処理プログラムが実行され、当該情報処理プログラムの実行に必要な操作入力の検出、当該情報処理プログラムの実行に必要な表示を行う表示装置などは、それぞれゲーム装置１０のタッチパネル１３、上側ＬＣＤ２２および／または下側ＬＣＤ１２を用いるように構成した情報処理システムにおいて実行されてもよい。
【０３１３】
また、上述した説明では、本発明を携帯型のゲーム装置１０に適用した場合について説明したが、本発明は携帯型ゲーム装置に限定されない。例えば、据置型ゲーム装置、携帯電話機、簡易型携帯電話機（ＰＨＳ）、ＰＤＡ等の携帯情報端末にも本発明の適用は可能である。また、据置型ゲーム機やパーソナルコンピュータにも本発明の適用は可能である。
【０３１４】
以上、本発明を詳細に説明してきたが、前述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。また、当業者は、本発明の具体的な実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。また、本明細書において使用される用語は、特に言及しない限り、当該分野で通常用いられる意味で用いられることが理解されるべきである。従って、他に定義されない限り、本明細書中で使用される全ての専門用語および技術用語は、本発明の属する分野の当業者によって一般的に理解されるのと同じ意味を有する。矛盾する場合、本明細書（定義を含めて）が優先する。
【産業上の利用可能性】
【０３１５】
本発明に係る情報処理プログラム、情報処理装置、情報処理システムおよび情報処理方法は、ユーザに提供すべきでないコンテンツを提供しないようにすることが可能であり、データの送受信を行う情報処理プログラム、情報処理装置、情報処理システムおよび情報処理方法等として有用である。
【符号の説明】
【０３１６】
５ サーバ
１０ ゲーム装置
１１ 下側ハウジング
１２ 下側ＬＣＤ
１３ タッチパネル
１４ 操作ボタン
１５ アナログスティック
１６ ＬＥＤ
１７ 挿入口
１８ マイクロフォン用孔
１９ 無線スイッチ
２１ 上側ハウジング
２２ 上側ＬＣＤ
２３ 外側撮像部
２３ａ 外側左撮像部
２３ｂ 外側右撮像部
２４ 内側撮像部
２５ ３Ｄ調整スイッチ
２６ ３Ｄインジケータ
２７ スクリーンカバー
２８ タッチペン
３１ 情報処理部
３１１ ＣＰＵ
３１２ ＧＰＵ
３１３ ＶＲＡＭ
３２ メインメモリ
３３ 外部メモリＩ／Ｆ
３４ データ保存用外部メモリＩ／Ｆ
３５ データ保存用内部メモリ
３６ 無線通信モジュール
３７ ローカル通信モジュール
３８ ＲＴＣ
３９ 加速度センサ
４０ 角速度センサ
４１ 電源回路
４２ Ｉ／Ｆ回路
４３ マイク
４４ スピーカ
４５ 外部メモリ
４６ データ保存用外部メモリ
５１ ＣＰＵ
５２ 操作検出部
５３ 通信部
５４ ＨＤＤ
５５ メインメモリ
【技術分野】
【０００１】
本発明は、情報処理プログラム、情報処理装置、情報処理方法および情報処理システムに関し、より特定的には、装置間で送受信されるデータの中から好ましくないデータを特定する情報処理プログラム、情報処理装置、情報処理方法および情報処理システムに関する。
【背景技術】
【０００２】
従来、不快感を与えるデータや不要なデータを、ブラックリストを用いて、受信したデータの中から削除するシステムがある（例えば、特許文献１参照）。上記特許文献１で開示されているシステムでは、迷惑メールの送信元のアドレスを予め登録しておく。そして、登録されたアドレスが送信元となっているメールを受信した場合には、当該メールを自動的に削除する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−３３５２８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１で開示されているシステムでは、迷惑メールのメールアドレスを記憶したデータベースは、他の装置と共有されることがない。従って、上記特許文献１で開示されているようなシステムでは、ユーザが不快感を与えるデータ或いは不要なデータ等の不適切なコンテンツの閲覧を必ずしも防ぐことはできなかった。
【０００５】
それ故に本発明の目的は、ユーザに提供すべきでないデータに関する情報を他の装置と共有することのできる情報処理装置、情報処理プログラム、情報処理方法および情報処理システムを提供することである。
【課題を解決するための手段】
【０００６】
本発明は、コンテンツを含むデータの送受信が可能な複数の情報処理装置を少なくとも含む情報処理システムである。本発明の情報処理システムは、特定情報受信手段と、特定情報格納手段と、特定情報送信手段と、データ送受信手段と、出力手段とを備える情報処理装置を少なくとも含む。上記特定情報受信手段は、出力を制限する上記データを特定する情報を特定情報として受信する。上記特定情報格納手段は、上記特定情報受信手段によって受信された上記特定情報を格納する。上記特定情報送信手段は、上記特定情報格納手段に格納された上記特定情報をさらに他の情報処理装置へ送信する。上記データ送受信手段は、上記データを他の情報処理装置との間で送受信する。上記出力手段は、上記データ送受信手段によって受信される上記データの内、上記特定情報格納手段に格納されている上記特定情報に基づいて特定された上記データを出力せず、当該特定情報に基づいて特定されない上記データを出力する。
【０００７】
上記構成例によれば、他の情報処理装置から受信した特定情報を用いてユーザに提供すべきでないデータを特定できるので、提供すべきでないデータに関する情報を他の情報処理装置と共有することができる。さらに、ユーザは不適切なデータを提供されることを未然に防げる。また、特定情報は他の情報処理装置へ送信（伝播）されるので、自らが最新の特定情報を持っている場合に、他人に最新の特定情報を提供することができ、他人が不適切なデータを提供されてしまうことも未然に防ぐことができる。
【０００８】
他の構成例として、各上記情報処理装置は、無線通信手段をさらに備えていてもよい。ここで、上記無線通信手段は、通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する。この場合、上記特定情報受信手段は、上記無線通信手段を用いて上記特定情報を自動的に受信してもよい。また、この場合、上記特定情報格納手段は、上記無線通信手段によって受信された上記特定情報を格納してもよい。また、この場合、上記特定情報送信手段は、上記特定情報格納手段に格納された上記特定情報を上記無線通信手段を用いて他の情報処理装置に自動的に送信してもよい。
【０００９】
上記構成例によれば、能動的に特定情報を取り込むためのアクセスを行わずとも、自動的に他の情報処理装置から特定情報を送受信できるため、ユーザが意識することなく特定情報を共有することができ、不適切なコンテンツが出力されることを防げる。
【００１０】
他の構成例として、各上記情報処理装置は、無線通信手段をさらに備えていてもよい。ここで、上記無線通信手段は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置に無線接続し、当該他の情報処理装置との間で通信する。この場合、上記特定情報受信手段は、上記無線通信手段を用いて上記特定情報を受信してもよい。また、この場合、上記特定情報格納手段は、上記無線通信手段によって受信された上記特定情報を格納してもよい。また、この場合、上記特定情報送信手段は、上記特定情報格納手段に格納された上記特定情報を上記無線通信手段を用いて他の情報処理装置に送信してもよい。
【００１１】
上記構成例によれば、予測しないデータを受信してしまったとしても、特定情報も他の情報処理装置から自動的に受信するため、不適切なデータが提供されてしまうことを未然に防げる。
【００１２】
他の構成例として、上記情報処理システムは、各情報処理装置のそれぞれに対して上記特定情報を送信するサーバ装置をさらに含んでいてもよい。この場合、各上記情報処理装置は、サーバ情報受信手段と、更新手段とをさらに備えていてもよい。ここで、上記サーバ情報受信手段は、上記サーバ装置から送信される上記特定情報を受信する。また、上記更新手段は、上記サーバ情報受信手段によって受信された上記特定情報で上記特定情報格納手段に格納された上記特定情報を更新する。
【００１３】
上記構成例によれば、複数の情報処理装置で共有される特定情報をサーバ装置で一括して効率的に管理できる。また、近距離無線によって送受信を行う場合には、サーバ装置から受信した特定情報を近距離無線で伝播させることができるので、サーバ装置に接続できない場合にも近距離無線を通して特定情報を得ることができる。
【００１４】
他の構成例として、各上記情報処理装置は、受付手段と、送信手段とをさらに備えていてもよい。ここで、上記受付手段は、上記データ送受信手段によって受信される上記データの中で出力しないように設定する上記データの選択をユーザから受け付ける。また、上記送信手段は、上記受付手段によって受け付けられた上記データまたは当該データに関連する情報の内少なくとも一部を通報データとして上記サーバ装置に送信する。この場合、上記サーバ装置は、サーバ側更新手段と、サーバ側特定情報格納手段とを備えていてもよい。ここで、上記サーバ側更新手段は、各上記情報処理装置の上記送信手段から送信される上記通報データに基づいて、各上記情報処理装置に送信する上記特定情報を更新する。また、上記サーバ側特定情報格納手段は、上記サーバ側更新手段によって更新される上記特定情報を格納する。
【００１５】
上記構成例によれば、サーバ装置はシステムに含まれる複数の情報処理装置から送信される通報データに基づいて、それぞれの情報処理装置のユーザによって不適切と判断された結果を反映した特定情報を管理できるので、複数のユーザの総意に基づいた特定情報を形成することができる。
【００１６】
他の構成例として、上記サーバ装置は、サーバ情報送信手段をさらに備えていてもよい。ここで、上記サーバ情報送信手段は、上記サーバ側特定情報格納手段に格納されている上記特定情報を送信する。この場合、上記サーバ情報受信手段は、上記サーバ情報送信手段から上記特定情報を定期的に受信してもよい。
【００１７】
上記構成例によれば、サーバがユーザによって不適切と判断された結果を反映した特定情報を定期的に送信するので、システムに含まれる各情報処理装置のそれぞれは最新の結果を反映した特定情報に基づいて提供すべきでないデータを特定できる。
【００１８】
他の構成例として、上記サーバ側更新手段は、各上記情報処理装置の上記送信手段からそれぞれ送信される上記通報データの送信回数が所定の閾値以上となったとき、上記サーバ側特定情報格納手段に格納されている上記特定情報を更新してもよい。
【００１９】
上記構成例によれば、システムに含まれる各情報処理装置それぞれのユーザによってデータが不適切と判断された回数を特定情報に反映できる。
【００２０】
他の構成例として、上記データは、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子及び当該データのデータ識別子を含んでいてもよい。この場合、上記送信手段は、少なくとも上記ユーザ識別子及び上記データ識別子を上記通報データとして上記サーバ装置に送信してもよい。また、この場合、上記サーバ側更新手段は、上記送信手段からの送信回数が第１の閾値以上となった上記通報データの上記データ識別子を上記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第１の閾値よりも大きい第２の閾値以上となった上記通報データの上記ユーザ識別子を上記特定情報に追加して更新してもよい。
【００２１】
上記構成例によれば、あるデータが、相対的に小さい値である第１の閾値以上の回数だけサーバに通報されたときには、データ固有の識別子を特定情報として追加するので、当該データのみが提供されないようにすることができる。すなわち、比較的厳しくない制限を行う。また、相対的に大きな値である第２の閾値以上の回数だけ通報されたときには、データの作成者を示す識別子を特定情報として追加するので、提供されないようにするデータは増え、比較的厳しい制限を行うことになる。このように、通報された回数によって、データが提供されないようにするための制限を段階的に設定することができる。
【００２２】
他の構成例として、上記出力手段は、上記データ送受信手段によって受信される上記データの内、上記データ識別子と上記特定情報に含まれる上記データ識別子が一致する上記データ、及び、上記ユーザ識別子と上記特定情報に含まれる上記ユーザ識別子が一致する上記データを出力せず、いずれも一致しない上記データを出力してもよい。
【００２３】
上記構成例によれば、上記第１の閾値及び上記第２の閾値を用いて段階的に設定した制限で実際にデータを提供することができる。
【００２４】
他の構成例として、上記データは、複数のアプリケーションの内いずれかを用いて作成され、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子及び当該データを作成するのに用いられたアプリケーションプログラムを示すアプリ識別子を含んでいてもよい。この場合、上記サーバ側更新手段は、上記送信手段からの送信回数が第２の閾値以上となった上記データの上記ユーザ識別子と上記アプリ識別子とを組み合わせて上記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第２の閾値よりも大きい第３の閾値以上となった上記通報データの上記ユーザ識別子と、全てのアプリケーションプログラムを示す上記アプリ識別子とを組み合わせて当該特定情報に追加することで当該特定情報を更新してもよい。
【００２５】
上記構成例によれば、あるデータが、相対的に小さい値である第２の閾値以上の回数だけサーバに通報されたときは、通報されたデータの作成者を示す識別子と通報されたデータを作成したアプリケーションの識別子との組み合わせを特定情報として追加するので、作成者と作成したアプリケーションとが一致するデータが提供されないようにすることができる。すなわち、比較的厳しくない制限を行う。また、相対的に大きな値である第３の閾値以上の回数だけ通報されたときには、通報されたデータの作成者を示す識別子と全てのアプリケーションを表す識別子との組み合わせを特定情報として追加するので、作成者が一致するデータであれば作成したアプリケーションを問わずに提供されないようにすることができる。すなわち、比較的厳しい制限を行うことになる。このように、通報された回数によって、データが提供されないようにするための制限を段階的に設定することができる。
【００２６】
他の構成例として、上記出力手段は、上記データ送受信手段によって受信される上記データの内、上記アプリ識別子と上記ユーザ識別子との組み合わせが上記特定情報に含まれる上記アプリ識別子と上記ユーザ識別子との組み合わせと一致する上記データを出力せず、一致しない上記データを出力してもよい。
【００２７】
上記構成例によれば、上記第２の閾値及び上記第３の閾値を用いて段階的に設定した制限で実際にデータを提供することができる。
【００２８】
他の構成例として、各上記情報処理装置は、受付手段と、送信手段とをさらに備えていてもよい。ここで、上記受付手段は、上記データ送受信手段によって受信される上記データの中で出力しないように設定する上記データの選択をユーザから受け付ける。また、上記送信手段は、上記受付手段によって受け付けられた上記データ又は当該データに関連する情報の内少なくとも一部を通報データとして上記サーバ装置に送信する。この場合、上記サーバ装置は、通知手段と、サーバ側更新手段と、サーバ側特定情報格納手段とを備えていてもよい。ここで、上記通知手段は、各上記情報処理装置の上記送信手段から送信される上記通報データに基づいて、当該通報データを用いて特定される上記データが不適切なデータであることを通知する。また、上記サーバ側更新手段は、上記通知手段による通知を受けた上記サーバ装置の使用者の操作により、各情報処理装置に送信する上記特定情報を更新する。また、上記サーバ側特定情報格納手段は、上記サーバ側更新手段によって更新される上記特定情報を格納する。
【００２９】
上記構成例によれば、システムに含まれる複数の情報処理装置から送信される通報データに基づいて、それぞれの情報処理装置のユーザによって不適切と判断された結果を反映した通知をサーバ装置の使用者が受けられる。したがって、サーバ装置の使用者は、どのようなデータが多くのユーザによって不適切と思われているかどうかを把握することが容易になる。
【００３０】
他の構成例として、上記通知手段は、各上記情報処理装置の上記送信手段からの送信回数が所定の閾値以上となった上記通報データを用いて特定される上記データが不適切なデータであることを通知してもよい。
【００３１】
上記構成例によれば、システムに含まれる各情報処理装置の一定数以上のユーザによって不適切と判断されたデータがどのようなものであるかをサーバの使用者に通知することができる。
【００３２】
他の構成例として、上記更新手段は、上記サーバ情報受信手段によって受信された上記特定情報が、情報処理装置に既に格納されている上記特定情報よりも新しい場合、既に格納されている上記特定情報に、受信された上記特定情報の差分を追加又は全部を上書きすることで上記特定情報を更新してもよい。
【００３３】
上記構成例によれば、サーバ装置で管理されている特定情報が新しいときに情報処理装置において特定情報が更新されるので、最新の特定情報を効率的に維持できる。
【００３４】
他の構成例として、上記更新手段は、上記サーバ情報受信手段によって上記特定情報が受信された時点で上記情報処理装置に格納された上記特定情報を更新してもよい。
【００３５】
上記構成例によれば、サーバ装置で管理されている特定情報が常に最新の特定情報であると見なして、情報処理装置における特定情報が即座に更新されるので、最新の特定情報を効率的に維持できる。
【００３６】
他の構成例として、各上記情報処理装置は、無線通信手段をさらに備えていてもよい。ここで、上記無線通信手段は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する。この場合、上記データ送受信手段は、上記無線通信手段を用いて自動的に上記データを送受信する。
【００３７】
上記構成例によれば、他の情報処理装置との間で自動的にデータを送受信するため予測しないデータを受信してしまうことがあるが、特定情報を他の情報処理装置から受信するため、不適切なデータが出力されてしまうことを未然に防げる。
【００３８】
他の構成例として、各上記情報処理装置は、データ格納手段をさらに備えていてもよい。ここで、上記データ格納手段は、上記データ送受信手段によって現在までに受信された上記データを格納する。この場合、上記出力手段は、上記データ格納手段に格納された上記データの内、上記特定情報格納手段に格納されている上記特定情報によって特定された上記データを出力しなくてもよい。
【００３９】
上記構成例によれば、現在までに受信した全てのデータに対して、最新の特定情報を用いて提供可能か否かを判断することができる。
【００４０】
他の構成例として、各上記情報処理装置は、携帯可能であってもよい。
【００４１】
上記構成例によれば、情報処理装置が携帯されることによって、データの送受信が相対的に多くなる場合でも、不適切なデータがそれぞれの情報装置のユーザに提供されることを未然に防げる。
【００４２】
また、本発明は、上記各手段を備える情報処理プログラムおよび情報処理システムや上記各手段で行われる動作を含む情報処理方法の形態で実施されてもよい。
【発明の効果】
【００４３】
本発明によれば、ユーザに提供すべきでないデータに関する情報を他の装置と共有することのできる情報処理装置、情報処理プログラム、情報処理方法および情報処理システムを提供できる。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態に係る情報処理プログラムを実行するゲーム装置１０の外観図
【図２】図１のゲーム装置１０の内部構成の一例を示すブロック図
【図３】サーバ５と図１に記載のゲーム装置１０とからなる情報処理システムの構成例を示す図
【図４】図３のサーバ５の内部構成の一例を示すブロック図
【図５】本発明におけるキャラクタのパーツの候補選択画面の一例を示す図
【図６】本発明の一実施形態に係る情報処理システムの概略を説明するための図
【図７Ａ】図１のゲーム装置１０で実行される情報処理プログラムを実行することに応じて、メインメモリ３２に記憶される各種データの一例を示す図
【図７Ｂ】図７Ａのユーザ作成データＵｄのより詳細なデータ構成を示す図
【図７Ｃ】図７ＡのタスクデータＴｄのより詳細なデータ構成を示す図
【図７Ｄ】図７ＡのＬＢＬデータＬｄのより詳細なデータ構成を示す図
【図７Ｅ】図７ＡのＧＢＬデータＧｄのより詳細なデータ構成を示す図
【図７Ｆ】図４のサーバ５で実行されるサーバ処理プログラムを実行することに応じて、メインメモリ５５に記憶される各種データの一例を示す図
【図８Ａ】図１のゲーム装置１０で実行されるキャラクタ取り扱い処理プログラムを実行することによってゲーム装置１０がキャラクタ取り扱い処理を行う一例を示すフローチャート
【図８Ｂ】図１のゲーム装置１０で実行されるキャラクタ取り扱い処理プログラムを実行することによってゲーム装置１０がキャラクタ取り扱い処理を行う一例を示すフローチャート
【図８Ｃ】図８Ａのステップ１４０で実行されるキャラクタ編集処理の詳細を示すフローチャート
【図８Ｄ】図８Ａのステップ１４０で実行されるキャラクタ編集処理の詳細を示すフローチャート
【図８Ｅ】図８Ａのステップ１５０で実行されるＬＢＬ登録処理の詳細を示すフローチャート
【図８Ｆ】図１のゲーム装置１０で実行されるすれ違い通信処理プログラムを実行することによってゲーム装置１０がすれ違い通信処理を行う一例を示すフローチャート
【図８Ｇ】図１のゲーム装置１０で実行されるインターネット通信処理プログラムを実行することによってゲーム装置１０がインターネット通信処理を行う一例を示すフローチャート
【図８Ｈ】図１のゲーム装置１０で実行されるローカル通信処理プログラムを実行することによってゲーム装置１０がローカル通信処理を行う一例を示すフローチャート
【図８Ｉ】図１のゲーム装置１０で実行されるフィルタリング処理プログラムを実行することによってゲーム装置１０がフィルタリング処理を行う一例を示すフローチャート
【図８Ｊ】図１のゲーム装置１０で実行されるＧＢＬ更新処理プログラムを実行することによってゲーム装置１０がＧＢＬ更新処理を行う一例を示すフローチャート
【図９】図３のサーバ５で実行されるサーバ処理プログラムを実行することによってサーバ５がサーバ処理を行う一例を示すフローチャート
【発明を実施するための形態】
【００４５】
（第１の実施形態）
図面を参照して、本発明の第１の実施形態に係る情報処理プログラムを実行する情報処理装置について説明する。本発明の情報処理プログラムは、任意のコンピュータシステムで実行されることによって適用することができるが、情報処理装置の一例として携帯型のゲーム装置１０を用い、ゲーム装置１０で実行される情報処理プログラムを用いて説明する。
【００４６】
［ゲーム装置の外部構成］
まず始めに、図１を参照して、ゲーム装置１０の外部構成について説明する。なお、図１は、ゲーム装置１０の外観の一例を示す平面図である。ゲーム装置１０は、一例として携帯型のゲーム装置であり、折り畳み可能に構成されている。図１は、開いた状態（開状態）におけるゲーム装置１０の一例を示す正面図である。
【００４７】
図１において、ゲーム装置１０は、下側ハウジング１１および上側ハウジング２１を有する。下側ハウジング１１と上側ハウジング２１とは、開閉可能（折り畳み可能）に連結されている。図１の例では、下側ハウジング１１および上側ハウジング２１は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回動可能に連結されている。通常、ユーザは、開状態でゲーム装置１０を使用する。そして、ユーザは、ゲーム装置１０を使用しない場合には閉状態としてゲーム装置１０を保管する。また、ゲーム装置１０は、上記閉状態および開状態のみでなく、下側ハウジング１１と上側ハウジング２１とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング２１を下側ハウジング１１に対して任意の角度で静止させることができる。
【００４８】
下側ハウジング１１には、下側ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示装置）１２、タッチパネル１３、各操作ボタン１４Ａ〜１４Ｌ（図１、図３Ａ〜図３Ｄ）、アナログスティック１５、ＬＥＤ１６Ａ〜１６Ｂ、挿入口１７、および、マイクロフォン用孔１８が設けられる。以下、これらの詳細について説明する。
【００４９】
図１に示すように、下側ＬＣＤ１２は下側ハウジング１１に収納される。下側ＬＣＤ１２は横長形状であり、長辺方向が下側ハウジング１１の長辺方向に一致するように配置される。下側ＬＣＤ１２は、下側ハウジング１１の中央に配置される。下側ＬＣＤ１２は、下側ハウジング１１の内側面（主面）に設けられ、下側ハウジング１１の内側面に設けられた開口部から下側ＬＣＤ１２の画面が露出する。そして、ゲーム装置１０を使用しない場合には上記閉状態としておくことによって、下側ＬＣＤ１２の画面が汚れたり傷ついたりすることを防止することができる。なお、本実施例では表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置など、他の任意の表示装置を利用してもよい。また、下側ＬＣＤ１２として、任意の解像度の表示装置を利用することができる。
【００５０】
図１に示されるように、ゲーム装置１０は、入力装置として、タッチパネル１３を備えている。タッチパネル１３は、下側ＬＣＤ１２の画面上を覆うように装着されている。なお、本実施例では、タッチパネル１３は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル１３は、抵抗膜方式に限らず、例えば静電容量方式等、任意の押圧式のタッチパネルを用いることができる。本実施例では、タッチパネル１３として、下側ＬＣＤ１２の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル１３の解像度と下側ＬＣＤ１２の解像度とが一致している必要はない。また、下側ハウジング１１の上側面には挿入口１７（図１に示す点線）が設けられている。挿入口１７は、タッチパネル１３に対する操作を行うために用いられるタッチペン２８を収納することができる。なお、タッチパネル１３に対する入力は通常タッチペン２８を用いて行われるが、タッチペン２８に限らずユーザの指でタッチパネル１３に対する入力をすることも可能である。
【００５１】
各操作ボタン１４Ａ〜１４Ｌは、所定の入力を行うための入力装置である。図１に示されるように、下側ハウジング１１の内側面（主面）には、各操作ボタン１４Ａ〜１４Ｌの内、十字ボタン１４Ａ（方向入力ボタン１４Ａ）、ボタン１４Ｂ、ボタン１４Ｃ、ボタン１４Ｄ、ボタン１４Ｅ、電源ボタン１４Ｆ、セレクトボタン１４Ｊ、ＨＯＭＥボタン１４Ｋ、およびスタートボタン１４Ｌが設けられる。十字ボタン１４Ａは、十字の形状を有しており、上下左右の方向を指示するボタンを有している。ボタン１４Ｂ、ボタン１４Ｃ、ボタン１４Ｄ、およびボタン１４Ｅは、十字状に配置される。ボタン１４Ａ〜１４Ｅ、セレクトボタン１４Ｊ、ＨＯＭＥボタン１４Ｋ、およびスタートボタン１４Ｌには、ゲーム装置１０が実行するプログラムに応じた機能が適宜割り当てられる。例えば、十字ボタン１４Ａは選択操作等に用いられ、各操作ボタン１４Ｂ〜１４Ｅは例えば決定操作やキャンセル操作等に用いられる。また、電源ボタン１４Ｆは、ゲーム装置１０の電源をオン／オフするために用いられる。
【００５２】
アナログスティック１５は、方向を指示するデバイスであり、下側ハウジング１１の内側面の下側ＬＣＤ１２より左側領域の上部領域に設けられる。図１に示すように、十字ボタン１４Ａが下側ＬＣＤ１２より左側領域の下部領域に設けられ、アナログスティック１５が十字ボタン１４Ａの上方に設けられる。また、アナログスティック１５および十字ボタン１４Ａは、下側ハウジング１１を把持した左手の親指で操作可能な位置に設計される。また、アナログスティック１５を上部領域に設けたことにより、下側ハウジング１１を把持する左手の親指が自然と位置するところにアナログスティック１５が配され、十字ボタン１４Ａは、左手の親指を少し下にずらした位置に配される。アナログスティック１５は、そのキートップが、下側ハウジング１１の内側面に平行にスライドするように構成されている。アナログスティック１５は、ゲーム装置１０が実行するプログラムに応じて機能する。例えば、３次元仮想空間に所定のオブジェクトが登場するゲームがゲーム装置１０によって実行される場合、アナログスティック１５は、当該所定のオブジェクトを３次元仮想空間内で移動させるための入力装置として機能する。この場合において、所定のオブジェクトは、アナログスティック１５のキートップがスライドした方向に移動される。なお、アナログスティック１５として、上下左右および斜め方向の任意の方向に所定量だけ傾倒することでアナログ入力を可能としたものを用いてもよい。
【００５３】
十字状に配置される、ボタン１４Ｂ、ボタン１４Ｃ、ボタン１４Ｄ、およびボタン１４Ｅの４つのボタンは、下側ハウジング１１を把持する右手の親指が自然と位置するところに配置される。また、これらの４つのボタンとアナログスティック１５とは、下側ＬＣＤ１２を挟んで、左右対称に配置される。これにより、ゲームプログラムによっては、例えば、左利きの人が、これらの４つのボタンを使用して方向指示入力をすることも可能である。
【００５４】
なお、図１においては、操作ボタン１４Ｇ〜１４Ｉの図示を省略している。例えば、Ｌボタン１４Ｇは、下側ハウジング１１の上側面の左端部に設けられ、Ｒボタン１４Ｈは、下側ハウジング１１の上側面の右端部に設けられる。Ｌボタン１４ＧおよびＲボタン１４Ｈは、ゲーム装置１に対して、例えば撮影指示操作（シャッター操作）を行うために用いられる。さらに、音量ボタン１４Ｉは、下側ハウジング１１の左側面に設けられる。音量ボタン１４Ｉは、ゲーム装置１０が備えるスピーカの音量を調整するために用いられる。
【００５５】
また、下側ハウジング１１の内側面には、マイクロフォン用孔１８が設けられる。マイクロフォン用孔１８の下部には後述する音声入力装置としてのマイク（図２参照）が設けられ、当該マイクがゲーム装置１０の外部の音を検出する。
【００５６】
また、下側ハウジング１１の左側面には開閉可能なカバー部１１Ｃが設けられる。このカバー部１１Ｃの内側には、ゲーム装置１０とデータ保存用外部メモリ４６とを電気的に接続するためのコネクタ（図示せず）が設けられる。データ保存用外部メモリ４６は、上記コネクタに着脱自在に装着される。データ保存用外部メモリ４６は、例えば、ゲーム装置１０によって撮像された画像のデータを記憶（保存）するために用いられる。なお、上記コネクタおよびそのカバー部１１Ｃは、下側ハウジング１１の右側面に設けられてもよい。
【００５７】
また、下側ハウジング１１の上側面にはゲーム装置１０とゲームプログラムを記録した外部メモリ４５を挿入するための挿入口１１Ｄが設けられ、その挿入口１１Ｄの内部には、外部メモリ４５と電気的に着脱自在に接続するためのコネクタ（図示せず）が設けられる。外部メモリ４５がゲーム装置１０に接続されることにより、所定のゲームプログラムが実行される。なお、上記コネクタおよび挿入口１１Ｄは、下側ハウジング１１の他の側面（例えば、右側面等）に設けられてもよい。
【００５８】
図１に示されるように、下側ハウジング１１の下側面には、ゲーム装置１０の電源のＯＮ／ＯＦＦ状況をユーザに通知する第１ＬＥＤ１６Ａが設けられる。また、図示はしていないが、下側ハウジング１１の右側面には、ゲーム装置１０の無線通信の確立状況をユーザに通知する第２ＬＥＤ１６Ｂが設けられる。ゲーム装置１０は、他の機器との間で無線通信を行うことが可能であり、第２ＬＥＤ１６Ｂは、他の機器との無線通信が確立している場合に点灯する。ゲーム装置１０は、例えば、ＩＥＥＥ８０２．１１ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。下側ハウジング１１の右側面には、この無線通信の機能を有効／無効にする無線スイッチ１９（図示せず）が設けられる。
【００５９】
なお、図示は省略するが、下側ハウジング１１には、ゲーム装置１０の電源となる充電式電池が収納され、下側ハウジング１１の側面（例えば、上側面）に設けられた端子を介して当該電池を充電することができる。
【００６０】
上側ハウジング２１には、上側ＬＣＤ２２、２つの外側撮像部２３（外側左撮像部２３ａおよび外側右撮像部２３ｂ）、内側撮像部２４、３Ｄ調整スイッチ２５、および３Ｄインジケータ２６が設けられる。以下、これらの詳細について説明する。
【００６１】
図１に示すように、上側ＬＣＤ２２は、上側ハウジング２１に収納される。上側ＬＣＤ２２は、横長形状であり、長辺方向が上側ハウジング２１の長辺方向に一致するように配置される。上側ＬＣＤ２２は、上側ハウジング２１の中央に配置される。上側ＬＣＤ２２の画面の面積は、一例として下側ＬＣＤ１２の画面の面積よりも大きく設定される。具体的には、上側ＬＣＤ２２の画面は、下側ＬＣＤ１２の画面よりも横長に設定される。すなわち、上側ＬＣＤ２２の画面のアスペクト比における横幅の割合は、下側ＬＣＤ１２の画面のアスペクト比における横幅の割合よりも大きく設定される。
【００６２】
上側ＬＣＤ２２の画面は、上側ハウジング２１の内側面（主面）２１Ｂに設けられ、上側ハウジング２１の内側面に設けられた開口部から上側ＬＣＤ２２の画面が露出する。また、上側ハウジング２１の内側面は、図示しない透明なスクリーンカバー２７によって覆われている。スクリーンカバー２７は、上側ＬＣＤ２２の画面を保護するとともに、上側ＬＣＤ２２と上側ハウジング２１の内側面と一体的にさせ、これにより統一感を持たせている。なお、本実施例では、上側ＬＣＤ２２が液晶表示装置であるとしたが、例えばＥＬを利用した表示装置などが利用されてもよい。また、上側ＬＣＤ２２として、任意の解像度の表示装置を利用することができる。
【００６３】
上側ＬＣＤ２２は、レンチキュラー方式やパララックスバリア方式（視差バリア方式）を用いて立体視可能な画像を表示することが可能な表示装置である。すなわち、上側ＬＣＤ２２は、視差バリアを用いてユーザの左目に左目用画像を、そして、ユーザの右目に右目用画像をそれぞれ視認させることにより、ユーザにとって立体感のある立体画像（立体視可能な画像）を表示することができる。また、上側ＬＣＤ２２は、上記視差バリアを無効にすることが可能であり、視差バリアを無効にした場合は、画像を平面的に表示することができる（上述した立体視とは反対の意味で平面視の画像を表示することができる。すなわち、表示された同一の画像が右目にも左目にも見えるような表示モードである。）。このように、上側ＬＣＤ２２は、立体視可能な画像を表示する立体表示モードと、画像を平面的に表示する（平面視画像を表示する）平面表示モードとを切り替えることが可能な表示装置である。この表示モードの切り替えは、後述する３Ｄ調整スイッチ２５によって行われる。
【００６４】
外側撮像部２３は、上側ハウジング２１の外側面（上側ＬＣＤ２２が設けられた主面と反対側の背面）２１Ｄ（図示せず）に設けられた２つの撮像部（外側左撮像部２３ａおよび外側右撮像部２３ｂ）の総称である。外側左撮像部２３ａおよび外側右撮像部２３ｂの撮像方向は、いずれも外側面２１Ｄの外向きの法線方向である。また、外側左撮像部２３ａおよび外側右撮像部２３ｂは、いずれも、上側ＬＣＤ２２の表示面（内側面）の法線方向と１８０度反対の方向に設計される。すなわち、外側左撮像部２３ａの撮像方向および外側右撮像部２３ｂの撮像方向は、平行である。外側左撮像部２３ａと外側右撮像部２３ｂとは、ゲーム装置１０が実行するプログラムによって、ステレオカメラとして使用することが可能である。また、プログラムによっては、２つの外側撮像部（外側左撮像部２３ａおよび外側右撮像部２３ｂ）のいずれか一方を単独で用いて、外側撮像部２３を非ステレオカメラとして使用することも可能である。また、プログラムによっては、２つの外側撮像部（外側左撮像部２３ａおよび外側右撮像部２３ｂ）で撮像した画像を合成してまたは補完的に使用することにより撮像範囲を広げた撮像を行うことも可能である。本実施例では、外側撮像部２３は、外側左撮像部２３ａおよび外側右撮像部２３ｂの２つの撮像部で構成される。外側左撮像部２３ａおよび外側右撮像部２３ｂは、それぞれ所定の共通の解像度を有する撮像素子（例えば、ＣＣＤイメージセンサやＣＭＯＳイメージセンサ等）と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
【００６５】
なお、本実施例においては、外側左撮像部２３ａおよび外側右撮像部２３ｂは、ハウジングに固定されており、撮像方向を変更することはできない。
【００６６】
内側撮像部２４は、上側ハウジング２１の内側面（主面）２１Ｂに設けられ、当該内側面の内向きの法線方向を撮像方向とする撮像部である。内側撮像部２４は、所定の解像度を有する撮像素子（例えば、ＣＣＤイメージセンサやＣＭＯＳイメージセンサ等）と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
【００６７】
図１に示すように、内側撮像部２４は、上側ハウジング２１を開いた状態において、上側ハウジング２１の上部であって、上側ＬＣＤ２２の画面の上端よりも上方に配置され、上側ハウジング２１の左右方向に関して中央の位置（上側ハウジング２１（上側ＬＣＤ２２の画面）を左右に２等分する線の線上）に配置される。具体的には、図１に示されるように、内側撮像部２４は、上側ハウジング２１の内側面であって、外側左撮像部２３ａおよび外側右撮像部２３ｂの中間の裏側の位置に配置される。このように、内側撮像部２４は、外側撮像部２３とは反対方向を撮像するので、ゲーム装置１０を把持しているユーザの顔を正面から撮像することも可能である。
【００６８】
３Ｄ調整スイッチ２５は、スライドスイッチであり、上述のように上側ＬＣＤ２２の表示モードを切り替えるために用いられるスイッチである。また、３Ｄ調整スイッチ２５は、上側ＬＣＤ２２に表示された立体視可能な画像（立体画像）の立体感を調整するために用いられる。図１に示されるように、３Ｄ調整スイッチ２５は、上側ハウジング２１の内側面および右側面の端部に設けられ、ユーザが上側ＬＣＤ２２を正視した場合に、当該３Ｄ調整スイッチ２５を視認できる位置に設けられる。３Ｄ調整スイッチ２５は、所定方向（例えば、上下方向）の任意の位置にスライド可能なスライダを有しており、当該スライダの位置に応じて上側ＬＣＤ２２の表示モードが設定される。
【００６９】
例えば、３Ｄ調整スイッチ２５のスライダが最下点位置に配置されている場合、上側ＬＣＤ２２が平面表示モードに設定され、上側ＬＣＤ２２の画面には平面画像が表示される。一方、上記最下点位置より上側にスライダが配置されている場合、上側ＬＣＤ２２は立体表示モードに設定される。この場合、上側ＬＣＤ２２の画面には立体視可能な画像が表示される。ここで、スライダが上記最下点位置より上側に配置されている場合、スライダの位置に応じて、立体画像の見え方が調整される。具体的には、スライダの位置に応じて、右目用画像および左目用画像における横方向の位置のずれ量が調整される。
【００７０】
３Ｄインジケータ２６は、上側ＬＣＤ２２が立体表示モードか否かを示す。例えば、３Ｄインジケータ２６は、ＬＥＤであり、上側ＬＣＤ２２の立体表示モードが有効の場合に点灯する。図１に示されるように、３Ｄインジケータ２６は、上側ハウジング２１の内側面に設けられ、上側ＬＣＤ２２の画面近傍に設けられる。このため、ユーザが上側ＬＣＤ２２の画面を正視した場合、ユーザは３Ｄインジケータ２６を視認しやすい。従って、ユーザは、上側ＬＣＤ２２の画面を視認している状態でも、上側ＬＣＤ２２の表示モードを容易に認識することができる。
【００７１】
また、上側ハウジング２１の内側面には、スピーカ孔２１Ｅが設けられる。後述するスピーカ４４からの音声がこのスピーカ孔２１Ｅから出力される。
【００７２】
［ゲーム装置の内部構成］
次に、図２を参照して、ゲーム装置１０の内部構成を説明する。なお、図２は、ゲーム装置１０の内部構成の一例を示すブロック図である。
【００７３】
図２において、ゲーム装置１０は、上述した各構成部に加えて、情報処理部３１、メインメモリ３２、外部メモリインターフェイス（外部メモリＩ／Ｆ）３３、データ保存用外部メモリＩ／Ｆ３４、データ保存用内部メモリ３５、無線通信モジュール３６、ローカル通信モジュール３７、リアルタイムクロック（ＲＴＣ）３８、加速度センサ３９、角速度センサ４０、電源回路４１、およびインターフェイス回路（Ｉ／Ｆ回路）４２等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて下側ハウジング１１（または上側ハウジング２１でもよい）内に収納される。
【００７４】
情報処理部３１は、所定のプログラムを実行するためのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１１、画像処理を行うＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１２等を含む情報処理手段である。本実施例では、所定のプログラムがゲーム装置１０内のメモリ（例えば外部メモリＩ／Ｆ３３に接続された外部メモリ４５やデータ保存用内部メモリ３５）に記憶されている。情報処理部３１のＣＰＵ３１１は、当該所定のプログラムを実行することによって、後述する情報処理などを実行する。なお、情報処理部３１のＣＰＵ３１１によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。情報処理部３１は、ＶＲＡＭ（Ｖｉｄｅｏ ＲＡＭ）３１３を含む。情報処理部３１のＧＰＵ３１２は、情報処理部３１のＣＰＵ３１１からの命令に応じて画像を生成し、ＶＲＡＭ３１３に描画する。そして、情報処理部３１のＧＰＵ３１２は、ＶＲＡＭ３１３に描画された画像を上側ＬＣＤ２２および／または下側ＬＣＤ１２に出力し、上側ＬＣＤ２２および／または下側ＬＣＤ１２に当該画像が表示される。
【００７５】
情報処理部３１には、メインメモリ３２、外部メモリＩ／Ｆ３３、データ保存用外部メモリＩ／Ｆ３４、およびデータ保存用内部メモリ３５が接続される。外部メモリＩ／Ｆ３３は、外部メモリ４５を着脱自在に接続するためのインターフェイスである。また、データ保存用外部メモリＩ／Ｆ３４は、データ保存用外部メモリ４６を着脱自在に接続するためのインターフェイスである。
【００７６】
メインメモリ３２は、情報処理部３１（ＣＰＵ３１１）のワーク領域やバッファ領域として用いられる揮発性の記憶手段である。すなわち、メインメモリ３２は、画像処理やゲーム処理で用いられる各種データを一時的に記憶したり、外部（外部メモリ４５や他の機器等）から取得されるプログラムを一時的に記憶したりする。本実施例では、メインメモリ３２として例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。
【００７７】
外部メモリ４５は、情報処理部３１によって実行されるプログラムを記憶するための不揮発性の記憶手段である。外部メモリ４５は、例えば読み取り専用の半導体メモリで構成される。外部メモリ４５が外部メモリＩ／Ｆ３３に接続されると、情報処理部３１は外部メモリ４５に記憶されたプログラムを読み込むことができる。情報処理部３１が読み込んだプログラムを実行することにより、所定の処理が行われる。データ保存用外部メモリ４６は、不揮発性の読み書き可能なメモリ（例えばＮＡＮＤ型フラッシュメモリ）で構成され、所定のデータを格納するために用いられる。例えば、データ保存用外部メモリ４６に外側撮像部２３で撮像された画像や他の機器で撮像された画像が記憶される。データ保存用外部メモリ４６がデータ保存用外部メモリＩ／Ｆ３４に接続されると、情報処理部３１はデータ保存用外部メモリ４６に記憶された画像を読み込み、上側ＬＣＤ２２および／または下側ＬＣＤ１２に当該画像を表示することができる。
【００７８】
データ保存用内部メモリ３５は、読み書き可能な不揮発性メモリ（例えばＮＡＮＤ型フラッシュメモリ）で構成され、所定のデータを格納するために用いられる。例えば、データ保存用内部メモリ３５には、無線通信モジュール３６を介した無線通信によってダウンロードされたデータやプログラムが格納される。
【００７９】
無線通信モジュール３６は、例えばＩＥＥＥ８０２．１１ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール３７は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール３６およびローカル通信モジュール３７は、情報処理部３１に接続される。情報処理部３１は、無線通信モジュール３６を用いてインターネットを介して他の機器との間でデータを送受信したり、ローカル通信モジュール３７を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。
【００８０】
ローカル通信モジュール３７は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。ここで、ローカル通信モジュール３７は、この無線通信で使用する電波は例えば無線局の免許が不要な程の微弱電波であり、例えばデータ伝送距離が１０ｍの範囲内の近距離無線通信を行う。従って、情報処理部３１は、他のゲーム装置１０の通信可能範囲内（例えば、両機間の距離が１０ｍ以内）に位置するときに、ローカル通信モジュール３７を用いて当該他のゲーム装置１０とデータを送受信することができる。このデータの送受信は、ユーザの選択に応じて、所定周期毎に自動的に繰り返し行われる場合がある。すなわち、情報処理部３１は、前述の近距離無線通信が可能な範囲内に存在する他のゲーム装置１０を検出して、検出の結果見つかったゲーム装置１０との間で自動的に通信を開始しデータを送受信する。そして、当該通信が完了した後で自動的に通信の切断を行う。本実施例では、このように自動的に通信を開始してから完了するまでの処理が所定周期毎に繰り返し行われる。この通信を以下「すれ違い通信」と記載し、すれ違い通信のための処理を以下「すれ違い通信処理」と記載する。
【００８１】
すれ違い通信処理は、通信を行う複数のゲーム装置１０が電源オンされているときに常に実行される。すなわち、複数のゲーム装置１０がスリープモードに設定されているときだけでなくアプリケーションが実行されているときにも行われる。なお、スリープモードとは、省電力モードのことであり、ゲーム装置１０における一部の機能（例えば、情報処理部３１の一部の機能、ディスプレイの一部の機能等）が停止している状態である。例えば、ＣＰＵ３１１が停止することでアプリケーションの実行をしない状態もスリープモードに該当する。
【００８２】
情報処理部３１には、加速度センサ３９が接続される。加速度センサ３９は、３軸（本実施例では、ｘｙｚ軸）方向に沿った直線方向の加速度（直線加速度）の大きさを検出する。加速度センサ３９は、例えば下側ハウジング１１の内部に設けられる。加速度センサ３９は、図１に示すように、下側ハウジング１１の長辺方向をｘ軸、下側ハウジング１１の短辺方向をｙ軸、下側ハウジング１１の内側面（主面）に対して垂直な方向をｚ軸として、ゲーム装置１０の各軸方向へ生じる直線加速度の大きさをそれぞれ検出する。なお、加速度センサ３９は、例えば静電容量式の加速度センサとするが、他の方式の加速度センサを用いるようにしてもよい。また、加速度センサ３９は１軸または２軸方向を検出する加速度センサであってもよい。情報処理部３１は、加速度センサ３９が検出した加速度を示すデータ（加速度データ）を受信して、ゲーム装置１０の姿勢や動きを算出する。
【００８３】
情報処理部３１には、角速度センサ４０が接続される。角速度センサ４０は、ゲーム装置１０の３軸（本実施例では、ｘｙｚ軸）周りに生じる角速度をそれぞれ検出し、検出した角速度を示すデータ（角速度データ）を情報処理部３１へ出力する。角速度センサ４０は、例えば下側ハウジング１１の内部に設けられる。情報処理部３１は、角速度センサ４０から出力された角速度データを受信して、ゲーム装置１０の姿勢や動きを算出する。
【００８４】
情報処理部３１には、ＲＴＣ３８および電源回路４１が接続される。ＲＴＣ３８は、時間をカウントして情報処理部３１に出力する。情報処理部３１は、ＲＴＣ３８によって計時された時間に基づき現在時刻（日付）を計算する。電源回路４１は、ゲーム装置１０が有する電源（下側ハウジング１１に収納される上記充電式電池）からの電力を制御し、ゲーム装置１０の各部品に電力を供給する。
【００８５】
情報処理部３１には、Ｉ／Ｆ回路４２が接続される。Ｉ／Ｆ回路４２には、マイク４３、スピーカ４４、およびタッチパネル１３が接続される。具体的には、Ｉ／Ｆ回路４２には、図示しないアンプを介してスピーカ４４が接続される。マイク４３は、ユーザの音声を検知して音声信号をＩ／Ｆ回路４２に出力する。アンプは、Ｉ／Ｆ回路４２からの音声信号を増幅し、音声をスピーカ４４から出力させる。Ｉ／Ｆ回路４２は、マイク４３およびスピーカ４４（アンプ）の制御を行う音声制御回路と、タッチパネル１３の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル１３からの信号に基づいて所定の形式のタッチ位置データを生成して情報処理部３１に出力する。タッチ位置データは、タッチパネル１３の入力面において入力が行われた位置（タッチ位置）の座標を示す。なお、タッチパネル制御回路は、タッチパネル１３からの信号の読み込み、およびタッチ位置データの生成を所定時間に１回の割合で行う。情報処理部３１は、タッチ位置データを取得することにより、タッチパネル１３に対して入力が行われたタッチ位置を知ることができる。
【００８６】
操作ボタン１４は、上記各操作ボタン１４Ａ〜１４Ｌからなり、情報処理部３１に接続される。操作ボタン１４から情報処理部３１へは、各操作ボタン１４Ａ〜１４Ｉに対する入力状況（押下されたか否か）を示す操作データが出力される。情報処理部３１は、操作ボタン１４から操作データを取得することによって、操作ボタン１４に対する入力に応じた処理を実行する。
【００８７】
下側ＬＣＤ１２および上側ＬＣＤ２２は、情報処理部３１に接続される。下側ＬＣＤ１２および上側ＬＣＤ２２は、情報処理部３１（ＧＰＵ３１２）の指示に従って画像を表示する。本実施例では、情報処理部３１は、後述するユーザ作成データに含まれるキャラクタなどのコンテンツを下側ＬＣＤ１２及び／又は上側ＬＣＤ２２に表示させる。また、情報処理部３１は、上側ＬＣＤ２２に外側撮像部２３で撮像した右目用画像と左目用画像とを用いた立体画像（立体視可能な画像）を表示させたり、内側撮像部２４で撮像した平面画像を上側ＬＣＤ２２に表示させたり、上側ＬＣＤ２２に外側撮像部２３で撮像した右目用画像および左目用画像の一方を用いた平面画像を表示させたりすることも可能である。
【００８８】
具体的には、情報処理部３１は、上側ＬＣＤ２２のＬＣＤコントローラ（図示せず）と接続され、当該ＬＣＤコントローラに対して視差バリアのＯＮ／ＯＦＦを制御する。上側ＬＣＤ２２の視差バリアがＯＮになっている場合、情報処理部３１のＶＲＡＭ３１３に格納された（外側撮像部２３で撮像された）右目用画像と左目用画像とが、上側ＬＣＤ２２に出力される。より具体的には、ＬＣＤコントローラは、右目用画像について縦方向に１ライン分の画素データを読み出す処理と、左目用画像について縦方向に１ライン分の画素データを読み出す処理とを交互に繰り返すことによって、ＶＲＡＭ３１３から右目用画像と左目用画像とを読み出す。これにより、右目用画像および左目用画像が、画素を縦に１ライン毎に並んだ短冊状画像に分割され、分割された右目用画像の短冊状画像と左目用画像の短冊状画像とが交互に配置された画像が、上側ＬＣＤ２２の画面に表示される。そして、上側ＬＣＤ２２の視差バリアを介して当該画像がユーザに視認されることによって、ユーザの右目に右目用画像が、ユーザの左目に左目用画像が視認される。以上により、上側ＬＣＤ２２の画面には立体視可能な画像が表示される。
【００８９】
外側撮像部２３および内側撮像部２４は、情報処理部３１に接続される。外側撮像部２３および内側撮像部２４は、情報処理部３１の指示に従って画像を撮像し、撮像した画像データを情報処理部３１に出力する。本実施例では、情報処理部３１は、外側撮像部２３および内側撮像部２４のいずれか一方に対して撮像指示を行い、撮像指示を受けた撮像部が画像を撮像して画像データを情報処理部３１に送る。具体的には、ユーザによるタッチパネル１３や操作ボタン１４を用いた操作によって使用する撮像部が選択される。そして、撮像部が選択されたことを情報処理部３１（ＣＰＵ３１１）が検知し、情報処理部３１が外側撮像部２３または内側撮像部２４に対して撮像指示を行う。
【００９０】
３Ｄ調整スイッチ２５は、情報処理部３１に接続される。３Ｄ調整スイッチ２５は、スライダの位置に応じた電気信号を情報処理部３１に送信する。
【００９１】
３Ｄインジケータ２６は、情報処理部３１に接続される。情報処理部３１は、３Ｄインジケータ２６の点灯を制御する。例えば、情報処理部３１は、上側ＬＣＤ２２が立体表示モードである場合、３Ｄインジケータ２６を点灯させる。
【００９２】
［ネットワーク構成］
次に、図３を参照して、本実施例におけるネットワーク構成について説明する。なお、図３は、本実施例におけるネットワーク構成を示す図である。
【００９３】
図３において、本実施例におけるネットワークは、ゲーム装置１０、アクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ。以下、ＡＰと称する）２、インターネット通信網３およびサーバ５からなる。より詳細には、本実施例におけるネットワークは、上述したようにローカル通信モジュール３７を用いて互いに近距離無線通信が可能なゲーム装置１０と、これらのゲーム装置１０と無線通信モジュール３６を用いて無線通信が可能なＡＰ２と、ＡＰ２およびインターネット通信網３を介してゲーム装置１０のそれぞれと通信可能なサーバ５からなる。
【００９４】
ＡＰ２は、従来周知のアクセスポイントである。ＡＰ２は、それぞれがインターネット通信網３に接続されている。ゲーム装置１０は、その無線通信モジュール３６の通信範囲内に位置するＡＰ２を介してインターネット通信網３に接続された種々の通信端末と通信することができる。本実施例におけるＡＰ２は、例えば、ゲーム装置１０の製造元が管理するＡＰ、ユーザの個人宅に設置されたＡＰおよび当該製造元以外の事業者などが設置したＡＰなどが該当する。
【００９５】
サーバ５は、インターネット通信網３に接続されており、同じくインターネット通信網３に接続されているＡＰ２を通してそれぞれのゲーム装置１０と通信可能である。図４は、サーバ５の内部構成の一例を示す図である。
【００９６】
サーバ５は、ＣＰＵ５１、操作検出部５２、通信部５３、ＨＤＤ５４、メインメモリ５５とからなり、これらは通信バス５６で互いに通信可能に接続されている。
【００９７】
ＣＰＵ５１は、メインメモリ５５に格納された各種プログラムに従って処理をする。操作検出部５２は、サーバ５の入力装置（例えば、キーボードなど）に対するユーザ（例えば、サーバ管理者）の操作を検出する。通信部５３は、インターネット通信網３を通して、同じくインターネット通信網３に接続されている種々の通信装置と通信する。ＨＤＤ５４は、従来周知のハードディスクドライブであって、ＣＰＵ５１が実行する各種プログラムが格納されている。メインメモリ５５は、ＣＰＵ５１が処理を開始するときにＨＤＤ５４から読み出された各種プログラムが格納される。なお、詳細は後述するが、メインメモリ５５には、後述するグローバルブラックリスト（Ｇｌｏｂａｌ Ｂｌａｃｋ Ｌｉｓｔ。以下、ＧＢＬと称する）が格納されており、通信部５３およびインターネット通信網３を通してゲーム装置１０によってダウンロードされる。ゲーム装置１０は、サーバ５からダウンロードしたＧＢＬに基づいて処理をする。また、サーバ５は一方のユーザから他方のユーザへ送信されるデータを受け付けて一時的に保存する機能なども有している。ここで、サーバ５が受け付けるデータには後述するキャラクタを示すユーザ作成データなどが一例として挙げられる。
【００９８】
本発明では、任意のユーザがゲーム装置１０を用いて自由に作成したデータ（以下、ユーザ作成データと称する）が、不特定多数のゲーム装置１０同士で送受信されるものとする。ユーザ作成データがゲーム装置１０同士で送受信される場合には、ユーザによる選択に応じて、即座に送受信される場合と、すれ違い通信または後述するインターネット通信において通信可能なタイミングが到来したときに自動的に送受信される場合とがある。そして、本発明は、他のゲーム装置１０から受信したデータの内、表示するのに不適切な内容を示すユーザ作成データを非表示データとし、その内容を表示しないようにする。
【００９９】
ユーザ作成データの一例としては、ユーザによって自由に作成されたキャラクタを示すデータが挙げられる。図５は、キャラクタを取り扱うアプリケーション（以下、キャラクタ取り扱いアプリケーションと称する）の実行中において、キャラクタを作成する画面が表示されているゲーム装置１０の一例を示す図である。図５において、下側ＬＣＤ１２には、キャラクタを構成するパーツを選択する画面として、口のパーツを候補の中から選択する画面が表示されている。また、図５において、上側ＬＣＤ２２には、既に選択された各パーツで構成されたキャラクタが表示されている。本実施例では、図５に一例として示すように、ユーザが、キャラクタを構成する各パーツ（目、鼻、口、髪および種々の体型の体など）を、それぞれの候補の中から、上述したゲーム装置１０の入力装置を用いて選択することによって、キャラクタを作成することができるものとする。そして、本実施例では、それぞれのユーザによって作成されたキャラクタを示すユーザ作成データが、不特定多数のゲーム装置１０同士で送受信されるものとする。
【０１００】
上述したようにユーザは、キャラクタを自由に作成することができる。従って、ユーザは、例えば、過去に存在した犯罪者を模したキャラクタなどの道徳上の観点から好ましくない内容を示すデータを、ユーザ作成データとして作成することも可能である。そして、このように道徳上の観点から好ましくない内容を示すデータも、上述したように不特定多数のゲーム装置１０同士で送受信される。そして、受信されたユーザ作成データは、当該データを受信したゲーム装置１０において事前に特定しない限りユーザにその内容が表示されてしまう。
【０１０１】
そこで、本発明では、このように道徳上の観点から好ましくない内容を示すユーザ作成データを受信したとしても非表示データとして表示しないようにする。本発明では、受信したデータの中から非表示データを特定するために、上述したＧＢＬおよびローカルブラックリスト（Ｌｏｃａｌ Ｂｌａｃｋ Ｌｉｓｔ。以下、ＬＢＬと称する）を用いる。以下、本発明に係る情報処理システムの概略を説明する。
【０１０２】
図６は、本発明に係る情報処理システム（以下、単に本システムと称する）の概略を説明するための図である。図６には、ゲーム装置Ａ〜ゲーム装置Ｄの４台のゲーム装置１０と、サーバ５とが示されている。また、図６には、本システムにおける動作に時系列に従った順番（Ｉ）〜（Ｘ）を付している。
【０１０３】
図６において、例えば、ゲーム装置Ａのユーザがユーザ作成データを作成したとする（以下、このデータをユーザ作成データａと称する）。そして、ユーザ作成データａが、すれ違い通信によってゲーム装置Ａからゲーム装置Ｂに送信されたとする（図６の（Ｉ））。ここで、ゲーム装置Ｂのユーザが、受信したユーザ作成データａによって示されるキャラクタを道徳上の観点から好ましくないと感じたとする。この場合、本システムにおいて、ゲーム装置Ｂのユーザは、ゲーム装置Ｂに格納されているＬＢＬにユーザ作成データａを登録することができる。ＬＢＬは、それぞれのゲーム装置１０に格納されており、それぞれのユーザは任意のユーザ作成データを登録できる（図６の（ＩＩ））。ＬＢＬに登録されたユーザ作成データによって示されるキャラクタは、登録後に同じデータを受信したとしても表示されなくなる。なお、本システムでは、一例として、ＬＢＬがゲーム装置１０同士で送受信されることはない。
【０１０４】
また、本システムでは、ゲーム装置Ｂのユーザがユーザ作成データａを特定するための情報（ＩＤ）などを非表示データとしてＬＢＬに登録することが可能であると共に、当該ユーザ作成データａをサーバ５に通報することも可能である。ここでは、ゲーム装置Ｂのユーザが、ユーザ作成データａをＬＢＬに登録すると共にサーバ５に通報したものとする（図６の（ＩＩＩ））。サーバ５は、上述したようにＧＢＬを管理しており、不特定多数のゲーム装置１０からインターネット通信網３を用いて通報を受け付ける。サーバ５は、通報を受けたユーザ作成データの中で所定の条件を満たすユーザ作成データを非表示データとしてＧＢＬに登録する。ここでは、ゲーム装置Ｂのユーザによってユーザ作成データａが通報されたことにより、当該ユーザ作成データａがＧＢＬに登録されたものとする（図６の（ＩＶ））。後に詳述するが、ユーザ作成データがＧＢＬに登録されるときには、上述したように通報されるときに送信される当該ユーザ作成データに含まれるユーザＩＤやデータＩＤなどがＧＢＬに登録されることとなる。それぞれのゲーム装置１０は、それぞれの所定の周期で、サーバ５で管理されているＧＢＬをダウンロードし、格納しているＧＢＬを必要に応じて更新する。ここでは、ゲーム装置Ｃが、サーバ５からＧＢＬをダウンロードして更新したものとする（図６の（Ｖ））。これにより、ゲーム装置Ｃでは、ユーザ作成データａが非表示データとして特定される。従って、ゲーム装置Ｃでユーザ作成データａが受信されたとしても、当該ユーザ作成データａで示されるキャラクタは表示されない（図６の（ＶＩＩ））。これにより、ゲーム装置Ｃのユーザは、道徳上の観点から好ましくないキャラクタを見ずに済む。
【０１０５】
また、ＧＢＬは、ＬＢＬと異なり、ゲーム装置１０同士ですれ違い通信によって送受信され、必要に応じて更新される。ここでは、ゲーム装置Ｃに格納されたＧＢＬが、すれ違い通信によってゲーム装置Ｄに送信されたものとする（図６の（ＶＩＩＩ））。ゲーム装置Ｄは、すれ違い通信によって受信したＧＢＬで、既に格納されているＧＢＬを更新する。このように、ゲーム装置Ｄは、例えば、インターネット通信網３に接続できず、サーバ５からＧＢＬをダウンロードできなかったとしても、他のゲーム装置ＣからＧＢＬを受信して更新することができる。そして、ゲーム装置Ｄが、すれ違い通信によってユーザ生成データａを受信したとしても（図６の（ＩＸ））、ゲーム装置Ｄでは非表示データとして特定される。従って、ゲーム装置Ｄには、ユーザ生成データａで示されるキャラクタが表示されない（図５の（Ｘ））。このように、本システムでは、ゲーム装置Ｄがサーバ５と通信できなかったとしても、ゲーム装置Ｄのユーザは、道徳上の観点から好ましくないキャラクタを見ずに済む。
【０１０６】
以上で説明したように、本システムでは、それぞれのゲーム装置１０がＬＢＬを格納しており、それぞれのユーザは受信したユーザ作成データの中から任意のデータを登録することができる。また、それぞれのユーザは、上述したように自身が好ましくないと感じたユーザ作成データをサーバ５に通報することができる。サーバ５は、それぞれのユーザから通報された回数を管理し、通報回数が所定の閾値を超えたユーザ作成データを所定の条件を満たすデータとしてＧＢＬに登録して更新する。また、上述したようにサーバ５によって管理されているＧＢＬは、それぞれのゲーム装置１０によってそれぞれの所定の周期でダウンロードされる。そして、それぞれのゲーム装置１０は、格納しているＧＢＬをダウンロードしたＧＢＬで必要に応じて更新する。従って、それぞれのゲーム装置１０に格納されているＧＢＬは、常に最新の非表示データを示す情報となる。さらに、ゲーム装置１０によって受信されたＧＢＬは、すれ違い通信によって交換することができる。従って、サーバ５からＧＢＬをダウンロードできないゲーム装置１０であっても、他のゲーム装置１０と通信可能であればＧＢＬを受信して更新することができる。そして、それぞれのゲーム装置１０がＧＢＬを格納することにより、未だに受信していないユーザ作成データであっても、非表示データとして特定されれば事前に表示しないようにできる。以上が、本システムの概要の説明である。
【０１０７】
［各種データの説明］
次に、ゲーム装置１０およびサーバ５でそれぞれ行われる処理を具体的に説明する前に、図７Ａ〜図７Ｆを参照して、それぞれにおいて用いられるデータについて説明する。なお、図７Ａは、ゲーム装置１０に電源が投入されることに応じてメインメモリ３２に格納されるデータ及び各種プログラムを示す。また、図７Ｂは、図７Ａに示すユーザ作成データＵｄのより詳細なデータの構成を示す。また、図７Ｃは、図７Ａに示すタスクデータＴｄのより詳細なデータの構成を示す。また、図７Ｄは、図７Ａに示すＬＢＬデータＬｄのより詳細なデータの構成を示す。また、図７Ｅは、図７Ａに示すＧＢＬデータＧｄのより詳細なデータの構成を示す。また、図７Ｆは、サーバ５が各種プログラムを実行することに応じてメインメモリ５５に格納されるデータを示す。
【０１０８】
［ゲーム装置１０に格納されるデータ］
まず、図７Ａ〜図７Ｅを参照して、ゲーム装置１０のメインメモリ３２に格納されるデータおよび各種プログラムについて説明する。ゲーム装置１０のメインメモリ３２には、図７Ａに示すように、ユーザ作成データＵｄ、タスクデータＴｄ、ＬＢＬデータＬｄ、ＧＢＬデータＧｄ、ネット受信ＧＢＬデータＮｇｄ、すれ違いボックスデータＴｂおよび各種プログラムＰａが格納される。
【０１０９】
ユーザ作成データＵｄは、任意のアプリケーションを用いてユーザが作成したデータである。本実施例では、任意のアプリケーションの一例として、キャラクタ取り扱いアプリケーションを挙げている。従って、本実施例におけるユーザ作成データＵｄは、キャラクタ取り扱いアプリケーションで取り扱われるキャラクタを示すデータとなる。ユーザ作成データＵｄは、図７Ｂに示すように、ユーザＩＤとデータＩＤとアプリＩＤとデータ本文とからなる。以下、ユーザ作成データＵｄに含まれるそれぞれのデータについて説明する。
【０１１０】
ユーザＩＤは、ユーザ作成データＵｄによって示されるキャラクタを新たに作成したユーザおよび既存のキャラクタを変更したユーザを示すデータである。具体的には、ユーザＩＤには、作成者ＩＤと変更者ＩＤとが含まれる。作成者ＩＤは、キャラクタを新たに作成したユーザを示すＩＤである。作成者ＩＤは、例えば、ユーザがキャラクタを新たに作成するのに使用したゲーム装置１０を識別するための固有の識別子など、キャラクタを新たに作成したユーザを特定できる情報であれば任意の情報であってよい。なお、作成者ＩＤは、キャラクタを新たに作成したユーザのＩＤを示すので、作成者ＩＤが更新されることはない。
【０１１１】
変更者ＩＤは、既存のキャラクタを変更したユーザを示すＩＤである。変更者ＩＤは、例えば、ユーザが既存のキャラクタを変更するのに使用したゲーム装置１０を識別するための固有の識別子など、既存のキャラクタを変更したユーザを特定できる情報であれば任意の情報であってよい。変更者ＩＤは、既存のキャラクタが変更される度にユーザＩＤに追加される。
【０１１２】
データ本文は、ユーザ作成データＵｄによって示されるデータの内容（コンテンツ）そのものである。ユーザ作成データＵｄは、上述したように任意のアプリケーションを用いて生成されたデータである。そして、ユーザ作成データＵｄがキャラクタ取り扱いアプリケーションにおいて取り扱われるキャラクタを示す場合、データ本文は当該キャラクタを構成する各パーツの形状や色を示すデータとなる。データ本文で示される形状のキャラクタが、当該データ本文を含むユーザ作成データＵｄによって示されるキャラクタとなる。
【０１１３】
アプリＩＤは、当該アプリＩＤを含むユーザ作成データＵｄを取り扱うアプリケーションを一意に識別するためのＩＤである。すなわち、ユーザ作成データＵｄの作成や変更に用いられたアプリケーションを示すＩＤである。本実施例では、キャラクタ取り扱いアプリケーションを示すＩＤがアプリＩＤとなる。なお、アプリＩＤは、ユーザ作成データＵｄを取り扱うアプリケーションが同一であれば、当該ユーザ作成データＵｄが異なるゲーム装置１０に格納されていたとしても同一のＩＤとなる。
【０１１４】
データＩＤは、前述のデータ本文をアプリケーション毎に一意に識別するためのＩＤである。従って、ユーザ作成データＵｄを取り扱うアプリケーションが同一であれば、当該ユーザ作成データＵｄを格納しているゲーム装置１０が異なっていても、データＩＤは重複しない。一方で、データＩＤは、同一のゲーム装置１０に格納されていたとしても、取り扱うアプリケーションが異なれば、同一のＩＤとなる場合もある。
【０１１５】
以上がユーザ作成データＵｄに含まれるそれぞれのデータの説明である。なお、図７Ａには、１つのユーザ作成データＵｄがメインメモリ３２に格納されている一例を示している。しかしながら、メインメモリ３２には、新たなユーザ作成データＵｄが生成される或いは既存のユーザ作成データＵｄが読み込まれることにより、１以上のユーザ作成データＵｄが格納される。
【０１１６】
新たなユーザ作成データＵｄは、ユーザがキャラクタ取り扱いアプリケーションを使用してキャラクタを新たに作成したときにメインメモリ３２に生成される。新たなユーザ作成データＵｄは、ユーザがキャラクタを新たに作成する度にメインメモリ３２に追加される。そして、ユーザがキャラクタの作成を終え、キャラクタ取り扱いアプリケーションを終了すると、メインメモリ３２に生成されたユーザ作成データＵｄがデータ保存用外部メモリ４６に格納される。データ保存用外部メモリ４６に格納された既存のユーザ作成データＵｄは、ユーザがキャラクタ取り扱いアプリケーションをゲーム装置１０に実行させたときに読み出されメインメモリ３２に格納される。このとき、データ保存用外部メモリ４６に１以上のユーザ作成データＵｄが格納されていれば、１以上のユーザ作成データＵｄがメインメモリ３２に格納されることになる。
【０１１７】
次に、タスクデータＴｄについて説明する。タスクデータＴｄは、インターネット通信を用いたデータの受信または送信をタスクとして示すデータである。タスクは当該タスクを生成したアプリケーションが実行中であるか否かに関わらずに、ＣＰＵ３１１によって実行される。本実施例におけるタスクは、ＣＰＵ３１１によって設定された時刻に実行されるタスクであるものとする。なお、他の一実施形態では、ゲーム装置１０において実行可能なタスクとして、ユーザの指示に応じて即座に実行されるタスクや、通信相手となるＡＰ２の管理者を示す情報に応じて実行優先度または実行順序などが変更可能なタスクがあってもよい。
【０１１８】
タスクデータＴｄは、図７Ｃに一例として示すように、アプリＩＤと通信先ＵＲＬと次回実行時刻と送信／受信識別フラグと格納先情報とからなる。
【０１１９】
アプリＩＤは、タスクデータＴｄを生成するのに用いられたアプリケーションを一意に識別するためのＩＤである。通信先ＵＲＬは、データを受信または送信する通信先を示す。次回実行時刻は、タスクデータＴｄで示されるタスクを次に実行する時刻を示す。送信／受信識別フラグは、当該フラグを含むタスクデータＴｄで示されるタスクが、受信のタスクであるか送信のタスクであるかを示す情報である。格納先情報は、タスクデータＴｄで示されるタスクで取り扱うデータの格納先を示す情報である。より具体的には、タスクデータＴｄで示されるタスクが送信タスクである場合には、格納先情報は、送信するデータのゲーム装置１０における格納領域を示す情報となる。一方、タスクデータＴｄで示されるタスクが受信タスクである場合には、格納先情報は、受信したデータのゲーム装置１０における格納領域を示す情報となる。
【０１２０】
本実施例において、タスクデータＴｄによって示されるタスクとしては、キャラクタを通報するタスク、キャラクタを受信するタスク、キャラクタを送信するタスクおよび配信用ＧＢＬデータＧｓｄを受信するタスクが一例として挙げられる。
【０１２１】
まず、キャラクタを通報するためのタスクデータＴｄについて説明する。キャラクタを通報するためのタスクデータＴｄは、後述するように、ＬＢＬ登録処理においてユーザによって通報が選択されたときに生成される。ＬＢＬ登録処理はキャラクタ取り扱いアプリケーションにおいて実行される。従って、キャラクタを通報するためのタスクデータＴｄには、キャラクタ取り扱いアプリケーションを一意に識別するアプリＩＤが含まれる。また、キャラクタを通報するためのタスクデータＴｄには、通報先がサーバ５として予め定められているため、通信先ＵＲＬとして、サーバ５のＵＲＬが含まれる。また、キャラクタを通報するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、キャラクタを通報するためのタスクデータＴｄは、通報するときにキャラクタを示すユーザ作成データＵｄを送信するので送信を示す送信／受信識別フラグを含む。また、キャラクタを通報するためのタスクデータＴｄには、当該キャラクタを示すユーザ作成データＵｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２２】
次に、キャラクタを受信するためのタスクデータＴｄについて説明する。キャラクタを受信するためのタスクデータＴｄは、後述するように、キャラクタ取り扱い処理において、キャラクタのインターネット通信網３を介した受信がユーザによって選択されたときに生成される。また、キャラクタ取り扱い処理プログラムのインストール時に生成されてもよい。従って、キャラクタを受信するためのタスクデータＴｄには、キャラクタ取り扱いアプリケーションを一意に識別するアプリＩＤが含まれる。また、キャラクタを受信するためのタスクデータＴｄには、自身宛に他人から送信されたキャラクタを一時的に保持しておくためのサーバ５のＵＲＬが通信先ＵＲＬとして含まれる。また、キャラクタを受信するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、キャラクタを受信するためのタスクデータＴｄは、キャラクタを受信するためのタスクを示すので、受信を示す送信／受信識別フラグを含む。また、キャラクタを受信するためのタスクデータＴｄには、新たに受信したキャラクタを示すユーザ作成データＵｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２３】
次に、キャラクタを他人に送信するためのタスクデータＴｄについて説明する。キャラクタを送信するためのタスクデータＴｄは、後述するように、キャラクタ取り扱い処理において、インターネット通信網３を介したキャラクタの送信がユーザによって選択されたときに生成される。従って、キャラクタを送信するためのタスクデータＴｄには、キャラクタ取り扱いアプリケーションを一意に識別するアプリＩＤが含まれる。また、キャラクタを送信するためのタスクデータＴｄには、キャラクタの送信を受け付けるためのサーバ５のＵＲＬが通信先ＵＲＬとして含まれる。また、キャラクタを送信するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、キャラクタを送信するためのタスクデータＴｄは、キャラクタを送信するためのタスクを示すので、送信を示す送信／受信識別フラグを含む。また、キャラクタを送信するためのタスクデータＴｄには、ユーザによって送信するように選択されたキャラクタを示すユーザ作成データＵｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２４】
次に、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄについて説明する。後に詳述するが、ゲーム装置１０は、配信用ＧＢＬデータＧｓｄをサーバ５から定期的に受信してＧＢＬを更新する。すなわち、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄは、キャラクタ取り扱いアプリケーションなどの任意のアプリケーションの実行中に生成されるデータではない。従って、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、例えば、アプリＩＤとして考えられるＩＤ以外のＩＤが例外的にアプリＩＤとして含まれる。例えば、本体のシステムを表すＩＤなどである。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、当該配信用ＧＢＬデータＧｓｄをサーバ５から受信するために、当該サーバ５のＵＲＬが通信先ＵＲＬとして含まれる。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、ＣＰＵ３１１によって設定された次回実行時刻が含まれる。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄは、配信用ＧＢＬデータＧｓｄを受信するためのタスクを示すので、受信を示す送信／受信識別フラグを含む。また、配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄには、インターネット通信網３を用いて受信したネット受信ＧＢＬデータＮｇｄのメインメモリ３２における格納領域が格納先情報として含まれる。
【０１２５】
なお、図７Ａには、１つのタスクデータＴｄが格納されているメインメモリ３２を一例として示している。しかしながら、本実施例におけるタスクには、上述したように種々のタスクがある。そして、これらのタスクはユーザの選択などに応じて複数設定される場合がある。また、未実行のタスクが残っている状態で、同種のタスクが設定される場合もある。このような場合、メインメモリ３２には、設定されたタスクを示す１以上のタスクデータＴｄが格納される。
【０１２６】
また、上述した種々のタスクデータＴｄに含まれる次回実行時刻はＣＰＵ３１１によって設定された次回実行時刻であるものとした。ここで、ＣＰＵ３１１が次回実行時刻を設定するのは、タスクデータＴｄを生成したときおよびタスクを実行して次回実行時刻を更新するときである。ＣＰＵ３１１がタスクデータＴｄを生成したときには、生成した時刻から所定の時間間隔をおいた時刻が次回実行時刻として設定されるものとする。また、ＣＰＵ３１１が次回実行時刻を更新するときには、更新したときから所定の時間間隔をおいた時刻が次回実行時刻として設定されるものとする。なお、他の一実施形態では、ユーザによって設定された時刻に次回実行時刻を更新するようにしてもよい。
【０１２７】
以上が、タスクデータＴｄの説明である。次に、ＬＢＬデータＬｄについて説明する。ＬＢＬデータＬｄは、上述したＬＢＬを示すデータである。より詳細には、ＬＢＬデータＬｄは、他のゲーム装置１０から受信したユーザ作成データＵｄの中から、ＣＰＵ３１１が非表示データを特定するためのＬＢＬを示すデータである。ＣＰＵ３１１がＬＢＬデータＬｄを用いて特定する非表示データは、ユーザによって判断され登録されたキャラクタを示すユーザ作成データＵｄである。
【０１２８】
ＬＢＬデータＬｄは、図７Ｄに示すように、変更者ＬＢＬを示す変更者ＬＢＬデータおよびデータＬＢＬを示すデータＬＢＬデータからなる。また、変更者ＬＢＬデータは、アプリＩＤと変更者ＩＤとを含む変更者特定ＬＢＬデータの集合体である。変更者特定ＬＢＬデータに含まれる変更者ＩＤは、後述するようにユーザによって登録するように選択されたユーザ作成データＵｄの最後の変更者ＩＤである。従って、変更者特定ＬＢＬデータは、ユーザ作成データＵｄを最後に変更した変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるものとして示すデータとなる。そして、変更者ＬＢＬは、ユーザ作成データＵｄを最後に変更した変更者を、道徳上の観点から好ましくないキャラクタを作成するユーザとして示すリストとなる。また、他の一実施形態では、ユーザ作成データの最初の作成者のＩＤを登録するようにしてもよい。
【０１２９】
一方、データＬＢＬデータは、アプリＩＤとデータＩＤとを含むデータ特定ＬＢＬデータの集合体である。データ特定ＬＢＬデータに含まれるデータＩＤは、後述するようにユーザによって登録するように選択されたユーザ作成データＵｄのデータＩＤである。従って、データ特定ＬＢＬデータは、ユーザ作成データＵｄで示されるキャラクタが道徳上の観点から好ましくないキャラクタであることを示すデータとなる。そして、データＬＢＬは、道徳上の観点から好ましくないキャラクタを示すリストとなる。
【０１３０】
なお、図７Ｄには、２つの変更者特定ＬＢＬデータを含む変更者ＬＢＬデータを一例として示している。しかしながら、変更者ＬＢＬデータには、ユーザによって任意に登録された数だけ変更者特定ＬＢＬデータを含めることができる。また、図７Ｄには、２つのデータ特定ＬＢＬデータを含むデータＬＢＬデータを一例として示している。しかしながら、データＬＢＬデータには、ユーザによって任意に登録された数だけデータ特定ＬＢＬデータを含めることができる。
【０１３１】
次に、ＧＢＬデータＧｄについて説明する。ＧＢＬデータＧｄは、上述したＧＢＬを示すデータである。より詳細には、ＧＢＬデータＧｄは、他のゲーム装置１０から受信したユーザ作成データＵｄの中から、ＣＰＵ３１１が非表示データを特定するためのＧＢＬを示すデータである。ＧＢＬデータＧｄは、サーバ５によって管理されている配信用ＧＢＬデータＧｓｄをゲーム装置１０が受信したデータである。後に詳述するが、サーバ５は、ユーザによって通報された通報回数に基づいてＧＢＬに登録するユーザ作成データＵｄを判断する。従って、ＣＰＵ３１１がＧＢＬデータＧｄを用いて特定する非表示データは、サーバ５によって判断されたキャラクタを示すユーザ作成データＵｄとなる。
【０１３２】
ＧＢＬデータＧｄは、図７Ｅに示すように、変更者ＧＢＬを示す変更者ＧＢＬデータおよびデータＧＢＬを示すデータＧＢＬデータからなる。変更者ＧＢＬデータは、アプリＩＤと変更者ＩＤとを含む変更者特定ＧＢＬデータの集合体である。変更者特定ＧＢＬデータに含まれる変更者ＩＤは、後述するようにサーバ５によって判断された変更者ＩＤである。より詳細には、サーバ５はユーザ作成データＵｄの最後の変更者ＩＤの通報回数に基づいて、通報されたユーザ作成データＵｄの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるか否かを判断する。そして、サーバ５に対する通報は、本システムに含まれるゲーム装置１０の全てのユーザのそれぞれの選択に応じて行われる。従って、変更者特定ＧＢＬデータは、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいてサーバ５が判断したユーザを示すデータとなる。そして、変更者ＧＢＬは、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいて、道徳上の観点から好ましくないキャラクタを作成すると判断されたユーザのリストとなる。また、他の一実施形態では、サーバ５は、ユーザ作成データの最初の作成者のＩＤの通報回数に基づいて好ましくないキャラクタを作成するユーザを判断するようにしてもよい。
【０１３３】
なお、変更者特定ＧＢＬデータは、Ｎｕｌｌで示されるアプリＩＤと変更者ＩＤとを含む場合がある。Ｎｕｌｌで示されるアプリＩＤとは、全てのアプリケーションを示すＩＤである。従って、ＮｕｌｌのアプリＩＤと共に変更者特定ＧＢＬデータに含まれている変更者ＩＤを含むユーザ作成データＵｄは、当該ユーザ作成データＵｄを取り扱うアプリケーションに関わらず非表示データに設定される。
【０１３４】
一方、データＧＢＬデータは、アプリＩＤとデータＩＤとを含むデータ特定ＧＢＬデータの集合体である。データ特定ＧＢＬデータに含まれるデータＩＤは、後述するようにサーバ５によって判断された変更者ＩＤである。より詳細には、サーバ５はユーザ作成データＵｄのデータＩＤの通報回数に基づいて、通報されたユーザ作成データＵｄによって示されるキャラクタが道徳上の観点から好ましくないキャラクタであるか否かを判断する。そして、サーバ５に対する通報は、上述したように本システムに含まれるゲーム装置１０の全てのユーザのそれぞれの選択に応じて行われる。従って、データ特定ＧＢＬデータは、変更者特定ＧＢＬデータと同様に、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいてサーバ５が判断したキャラクタを示すデータとなる。そして、データ特定ＧＢＬは、本システムに含まれるゲーム装置１０の全てのユーザの選択に基づいて判断された、道徳上の観点から好ましくないキャラクタのリストとなる。
【０１３５】
なお、図７Ｅには、２つの変更者特定ＧＢＬデータを含む変更者ＧＢＬデータを一例として示している。しかしながら、変更者ＧＢＬデータには、サーバ５によって登録された数だけ変更者特定ＧＢＬデータを含めることができる。また、図７Ｅには、２つのデータ特定ＧＢＬデータを含むデータＧＢＬデータを一例として示している。しかしながら、データＧＢＬデータには、サーバ５によって登録された数だけデータ特定ＧＢＬデータを含めることができる。
【０１３６】
次に、ネット受信ＧＢＬデータＮｇｄについて説明する。ネット受信ＧＢＬデータＮｇｄは、上述した送信ＧＢＬデータＳｇｄを受信するタスクが実行されることによって受信されたデータである。後に詳述するが、ネット受信ＧＢＬデータＮｇｄで示されるバージョンがより新しい場合に、メインメモリ３２に格納されているＧＢＬデータＧｄが更新される。
【０１３７】
次に、すれ違いボックスデータＴｂに含まれるデータについて説明する。すれ違いボックスデータＴｂは、すれ違い通信において自動的に送受信するためのデータからなる。具体的には、すれ違いボックスデータＴｂは、受信ボックスデータＪｂと送信ボックスデータＳｂとからなる。
【０１３８】
受信ボックスデータＪｂは、すれ違い通信において自動的に受信されたデータからなる。本実施例におけるすれ違い通信では、図７Ａに示すように、すれ違い受信データＪｄと受信ＧＢＬデータＪｇｄがそれぞれ自動的に受信される。
【０１３９】
すれ違い受信データＪｄは、すれ違い通信において他のゲーム装置１０から自動的に送信されたユーザ作成データＵｄである。また、受信ＧＢＬデータＪｇｄは、すれ違い通信において他のゲーム装置１０から自動的に送信された送信ＧＢＬデータＳｇｄである。従って、受信ＧＢＬデータＪｇｄには上述した例外的なアプリＩＤが含まれている（図示せず）。
【０１４０】
一方、送信ボックスデータＳｂは、すれ違い通信において自動的に送信されるデータからなる。本実施例におけるすれ違い通信では、図７Ａに示すように、すれ違い送信データＳｄと送信ＧＢＬデータＳｇｄがそれぞれ自動的に送信される。
【０１４１】
すれ違い送信データＪｄは、すれ違い通信をする他のゲーム装置１０に自動的に送信されるユーザ作成データＵｄである。また、送信ＧＢＬデータＳｇｄは、すれ違い通信をする他のゲーム装置１０に自動的に送信されるＧＢＬデータＧｄである。従って、送信ＧＢＬデータＳｇｄにも上述した例外的なアプリＩＤが含まれている（図示せず）。
【０１４２】
以上が、すれ違いボックスデータＴｂに含まれるデータの説明である。なお、図７Ａには、一例として、すれ違い送信データＳｄを１つだけ含む送信ボックスデータＳｂを示している。しかし、後述で明らかとなるが、送信ボックスデータＳｂにはすれ違い通信での送信が選択されたキャラクタの数だけすれ違い送信データＳｄが含まれることとなる。また、他の一実施形態では、同一アプリ間ですれ違い通信によって交換されるデータは１つのすれ違い送信データＪｄにまとめて含めるようにしてもよい。また、図７Ａには、一例として、すれ違い受信データＪｄを１つだけ含む受信ボックスデータＪｂを示している。しかし、後述で明らかとなるが、受信ボックスデータＪｂにはすれ違い通信で他のゲーム装置１０から送信されたすれ違い送信データＳｄの数だけすれ違い受信データＪｄが含まれることとなる。また、他の一実施形態では、同一アプリ間ですれ違い通信によって交換されるデータは１つのすれ違い受信データＪｄにまとめて含めるようにしてもよい。
【０１４３】
メインメモリ３２には、他にも図７Ａに示すように各種プログラムＰａが含まれるが、各種プログラムＰａの詳細については後述する。
【０１４４】
以上が、ゲーム装置１０のメインメモリ３２に格納されるデータおよびプログラムの説明である。次に、図７Ｆを参照して、サーバ５のメインメモリ５５に格納される各種データについて説明する。
【０１４５】
［サーバ５に格納されるデータ］
サーバ５のメインメモリ５５には、図７Ｆに示すように、配信用ＧＢＬデータＧｓｄ、ユーザ特定用カウントデータＵｃｄおよびデータ特定用カウントデータＤｃｄが格納される。
【０１４６】
配信用ＧＢＬデータＧｓｄは、サーバ５が管理しているＧＢＬを示すデータである。サーバ５が管理しているＧＢＬは、後述するようにゲーム装置１０のそれぞれによって配信用ＧＢＬデータＧｓｄを受信するためのタスクが実行されることに応じて、それぞれのゲーム装置１０に送信される。なお、サーバ５が管理している配信用ＧＢＬデータＧｓｄのデータ構造は、ゲーム装置１０のメインメモリ３２に格納されるＧＢＬデータＧｄのデータ構造と同一である。そして、サーバ５が管理している配信用ＧＢＬデータＧｓｄは、後述するようにユーザからの通報回数に基づいて常に最新のデータとなるように更新される。
【０１４７】
ユーザ特定用カウントデータＵｃｄは、ユーザ作成データＵｄの通報回数を最後の変更者毎にカウントするためのデータである。具体的には、ユーザ特定用カウントデータＵｃｄには、１以上のユーザカウントデータが含まれる。ユーザカウントデータは、変更者ＩＤとアプリＩＤと通報回数とからなる。ユーザカウントデータに含まれる通報回数は、それ自体に含まれる変更者ＩＤとアプリＩＤとを含むユーザ作成データＵｄが通報された回数を示す。また、ユーザカウントデータに含まれる変更者ＩＤは、通報されたユーザ作成データＵｄに含まれる最後の変更者ＩＤである。従って、ユーザカウントデータは、ユーザ作成データＵｄによって示される最後の変更者に基づいて通報された回数を示す。
【０１４８】
なお、通報されたユーザ作成データＵｄに含まれる最後の変更者ＩＤとアプリＩＤとを含むユーザカウントデータがユーザ特定用カウントデータＵｃｄに含まれていない場合には、当該変更者ＩＤと当該アプリＩＤとを含むユーザカウントデータが新たに生成される。従って、ユーザ特定用カウントデータＵｃｄに含まれるユーザカウントデータは、図７Ｆに示すように２つに限られない。
【０１４９】
また、データ特定用カウントデータＤｃｄは、ユーザ作成データＵｄの通報回数をデータ毎にカウントするためのデータである。具体的には、データ特定用カウントデータＤｃｄには、データＩＤとアプリＩＤと通報回数とからなるデータカウントデータが１以上含まれる。データカウントデータに含まれる通報回数は、それ自体に含まれるデータＩＤとアプリＩＤとを含むユーザ作成データＵｄが通報された回数を示す。従って、データカウントデータは、ユーザ作成データＵｄによって示されるデータの内容に基づいて通報された回数を示すデータとなる。
【０１５０】
なお、通報されたユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとを含むデータカウントデータがデータ特定用カウントデータＤｃｄに含まれていない場合には、当該データＩＤと当該アプリＩＤとを含むデータカウントデータが新たに生成される。従って、データ特定用カウントデータＤｃｄに含まれるデータカウントデータは、図７Ｆに示すように２つに限られない。
【０１５１】
［各種プログラムによる処理の説明］
次に、図８Ａ〜図８Ｊを参照して、ゲーム装置１０で実行される各種プログラムによる具体的な処理について説明する。なお、図８Ａおよび図８Ｂは、キャラクタ取り扱い処理プログラムを実行することによってゲーム装置１０がキャラクタ取り扱い処理を行う一例を示すフローチャートである。図８Ｃおよび図８Ｄは、図８Ａのステップ１４０で実行されるキャラクタ編集処理の詳細を示すフローチャートである。図８Ｅは、図８Ａのステップ１５０で実行されるＬＢＬ登録処理の詳細を示すフローチャートである。図８Ｆは、すれ違い通信処理プログラムを実行することによってゲーム装置１０がすれ違い通信処理を行う一例を示すフローチャートである。図８Ｇは、インターネット通信処理プログラムを実行することによってゲーム装置１０がインターネット通信処理を行う一例を示すフローチャートである。図８Ｈは、図８Ｂのステップ１８０で実行されるローカル通信処理の詳細を示すフローチャートである。図８Ｉは、図８Ｄのステップ２８０、図８Ｆのステップ５６０および図８Ｇのステップ６３５で実行されるフィルタリング処理の詳細を示すフローチャートである。図８Ｊは、ＧＢＬ更新処理プログラムを実行することによってゲーム装置１０がＧＢＬ更新処理を行う一例を示すフローチャートである。なお、これらの処理を実行するためのプログラムは、データ保存用内部メモリ３５に格納されている各種プログラムＰａに含まれており、ゲーム装置１０の電源がオンになったときに、データ保存用内部メモリ３５からメインメモリ３２に読み出されて、ＣＰＵ３１１によって実行される。本実施例では上記各種プログラムＰａは予めデータ保存用内部メモリ３５に記憶されているものとしたが、当該各種プログラムＰａの１つ又は全部のプログラムを、インターネット等を介してゲーム装置１０にダウンロードするようにしてもよい。また、データ保存用外部メモリ４６や外部メモリ４５に格納されたプログラムから読み出して実行するようにしてもよい。
【０１５２】
また、図８Ａ〜図８Ｊにそれぞれ示す処理の内、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理は、ゲーム装置１０の電源をオンにした後は、他の処理のいずれかが実行されているときであっても、実行されている他の処理とそれぞれとが並行して常に繰り返し実行されているものとする。また、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理は、他に実行されている処理がない場合でも並行して常に繰り返し実行されているものとする。つまり、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理は、他の処理が実行されているか否かに関わらず、常にそれぞれが並行して繰り返し実行されているものとする。
【０１５３】
まず、ゲーム装置１０の電源（電源ボタン１４Ｆ）がオンにされると、ＣＰＵ３１１によってブートプログラム（図示せず）が実行され、これによりデータ保存用内部メモリ３５に格納されている、複数のアプリケーションプログラムを選択的に実行させるプログラムであるランチャープログラムがメインメモリ３２にロードされＣＰＵ３１１で実行される。その後、ランチャープログラム上でキャラクタ取り扱いアプリケーションを選択して実行することにより、キャラクタ取り扱い処理プログラムがメインメモリ３２にロードされる。そして、ロードされたキャラクタ取り扱い処理プログラムをＣＰＵ３１１が実行することによって、図８Ａのステップ１０１から処理が開始される。なお、図８Ａ〜図８Ｊにおいては、ステップを「Ｓ」と略称している。
【０１５４】
キャラクタ取り扱い処理とは、キャラクタの編集、ＬＢＬへの登録および通信を用いた交換などをユーザの選択に応じて実行するための処理である。より具体的には、キャラクタ取り扱い処理とは、後述するようにキャラクタを新規作成する処理、既存のキャラクタを変更する処理、キャラクタをＬＢＬへ登録する処理、すれ違い通信においてキャラクタを送信する処理、インターネット通信においてキャラクタを受信する処理、インターネット通信においてキャラクタを送信する処理、ローカル通信においてキャラクタを送信する処理およびその他の各種処理などをユーザが選択してゲーム装置１０に実行させるための処理である。
【０１５５】
図８Ａにおいて、ＣＰＵ３１１は、上述したそれぞれの処理のユーザによる選択を受け付ける前に、メインメモリ３２に格納されている受信ボックスデータＪｂを参照して、新たなすれ違い受信データＪｄ（新着データ）が格納されているか否かを判断する（ステップ１０１）。ＣＰＵ３１１は、新たなすれ違い受信データＪｄが格納されていると判断した場合（ステップ１０１でＹｅｓ）、当該すれ違い受信データＪｄを新たなユーザ作成データＵｄとして、ユーザ作成データＵｄの格納領域に格納する（ステップ１０５）。新たなユーザ作成データＵｄを格納すると、ＣＰＵ３１１は、受信ボックスデータＪｂに格納されている新たなすれ違い受信データＪｄを削除する（ステップ１１０）。
【０１５６】
ＣＰＵ３１１は、新たなすれ違い受信データＪｄが格納されていないと判断した場合（ステップ１０１でＮｏ）または新たなすれ違い受信データＪｄを削除すると、フィルタリング処理を実行する（ステップ１１５）。フィルタリング処理の詳細については後述するが、概要を説明すると、フィルタリング処理は、フィルタリング対象となるユーザ作成データＵｄをフィルタリングして非表示データを特定して設定する処理である。ステップ１１５におけるフィルタリング処理ではメインメモリ３２に格納されているユーザ作成データＵｄがフィルタリング対象となる。非表示データを設定すると、ＣＰＵ３１１は、非表示データに設定されていないそれぞれのユーザ作成データＵｄで示されるキャラクタを表示対象として上側ＬＣＤ２２に表示する（ステップ１２０）。ここでは、非表示データに設定されていないキャラクタの全てを表示するのに限らず、例えば、非表示データに設定されていないキャラクタのうち、今回すれ違い通信によって新たに受信したものを表示したり、非表示データに設定されていないキャラクタのうち、ランダムに複数をピックアップして表示したりする。また、ＣＰＵ３１１は、表示対象を上側ＬＣＤ２２に表示すると共に、下側ＬＣＤ１２に、各種処理をそれぞれ示すアイコンを表示する。本実施例では、このように、表示対象のみのキャラクタとそれぞれのアイコンとを表示する画面をキャラクタ取り扱い画面として表示するものとする。キャラクタ取り扱い画面では、表示されたアイコンにユーザがタッチ操作することによって対応する処理を選択することができる。
【０１５７】
キャラクタ取り扱い画面を表示するとＣＰＵ３１１は、上述したそれぞれの処理のユーザによる選択の受け付けを開始する。ＣＰＵ３１１は、まず始めに、ユーザによってキャラクタを新規作成する処理が選択されたか否かを判断する（ステップ１２５）。キャラクタを新規作成する処理が選択されたと判断した場合（ステップ１２５でＹｅｓ）、ＣＰＵ３１１は、キャラクタ編集処理を開始する（ステップ１４０）。このとき、ＣＰＵ３１１は、新規作成されるキャラクタを編集対象とする。
【０１５８】
一方、ＣＰＵ３１１は、キャラクタを新規作成する処理が選択されていないと判断した場合（ステップ１２５でＮｏ）、既存のキャラクタを変更する処理がユーザによって選択されたか否かを判断する（ステップ１３０）。ＣＰＵ３１１は、既存のキャラクタを変更する処理がユーザによって選択されたと判断した場合（ステップ１３０でＹｅｓ）、変更フラグＨｆ（図示せず）をオンにする（ステップ１３５）。このとき、ＣＰＵ３１１は、上側ＬＣＤ２２に表示されているキャラクタの内、編集対象とするキャラクタをユーザに選択させてから変更フラグＨｆをオンにする。編集対象とするキャラクタをユーザに選択させるには、上側ＬＣＤ２２に表示されているキャラクタに対応する情報（例えば、名前など）を下側ＬＣＤ１２に一覧表示し、ユーザに選択させる手法などが一例として挙げられる。編集対象とするキャラクタをユーザに選択させるときに、キャラクタに対応する情報を下側ＬＣＤ１２に一覧表示する場合、下側ＬＣＤ１２に既に表示されている上述したアイコンは消去されるものとする。
【０１５９】
変更フラグＨｆをオンにすると、ＣＰＵ３１１は、キャラクタ編集処理を開始する（ステップ１４０）。以下、図８Ｃを参照して、上記ステップ１４０で行うキャラクタ編集処理の詳細について説明する。
【０１６０】
［キャラクタ編集処理］
図８Ｃにおいて、ＣＰＵ３１１は、キャラクタ編集処理を開始すると、ユーザによってキャラクタの新規作成が選択されたか否かを判断する（ステップ２０１）。具体的には、ＣＰＵ３１１は、メインメモリ３２を参照して変更フラグＨｆがオンとなっているか否かを判断する。ＣＰＵ３１１は、変更フラグＨｆがオンとなっていない場合、ユーザによって新規作成が選択されたと判断する。一方、ＣＰＵ３１１は、変更フラグＨｆがオンとなっている場合、ユーザによってキャラクタの変更が選択されたと判断する。
【０１６１】
ＣＰＵ３１１は、ユーザによってキャラクタの新規作成が選択されたと判断した場合（ステップ２０１でＹｅｓ）、新たなユーザ作成データＵｄをメインメモリ３２に生成する（ステップ２０３）。なお、新たに生成されたときのユーザ作成データＵｄで示されるキャラクタの各パーツは、初期パーツとして予め定められているものとする。
【０１６２】
ＣＰＵ３１１は、ユーザによってキャラクタの変更が選択されたと判断した場合（ステップ２０１でＮｏ）またはキャラクタを新規作成すると、編集対象のキャラクタを示すユーザ作成データＵｄのデータ本文を参照する（ステップ２０５）。
【０１６３】
ＣＰＵ３１１は、編集対象のデータ本文を参照（ステップ２０５）すると、表示画面をキャラクタ取り扱い画面からキャラクタの編集画面に切り替える（ステップ２１０）。具体的には、ＣＰＵ３１１は、参照したデータ本文で示されるキャラクタのみを上側ＬＣＤ２２に表示する。また、ＣＰＵ３１１は、編集する対象となるパーツ（例えば、口、目、体など）を示すアイコンをそれぞれ下側ＬＣＤ１２に表示する。さらに、ＣＰＵ３１１は、編集を終了するための終了アイコンも下側ＬＣＤ１２に表示する。
【０１６４】
ＣＰＵ３１１は、キャラクタの編集画面を表示すると、編集対象となるパーツがユーザによって選択されたか否かを判断する（ステップ２２０）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されているアイコンのいずれにタッチされたか否かを判断する。ＣＰＵ３１１は、編集対象となるパーツが選択されたと判断した場合（ステップ２２０でＹｅｓ）、選択されたパーツの候補をそれぞれ示すアイコンが下側ＬＣＤ１２に表示されるように表示を切り替える（ステップ２２５）。ＣＰＵ３１１が、ステップ２２５の処理をすることによりパーツの候補選択画面が下側ＬＣＤ１２に表示される。ここで、編集対象のパーツの候補とは、例えば、編集対象が目のパーツであれば、丸目、細目および切れ長の目などが当該候補となる。また、パーツの候補選択画面の一例は、図５に示すような画面であってもよい。図５は、口のパーツの候補選択画面の一例を示している。
【０１６５】
ＣＰＵ３１１は、編集対象として選択されたパーツの候補を示すアイコンをそれぞれ表示すると、ユーザによっていずれの候補が選択されたか否かを判断する（ステップ２３０）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されているアイコンのいずれにタッチされたか否かを判断する。ＣＰＵ３１１は、候補が選択されていないと判断した場合（ステップ２３０でＮｏ）、候補が選択されるまでステップ２３０の処理を繰り返して待機する。一方、ＣＰＵ３１１は、候補が選択されたと判断した場合（ステップ２３０でＹｅｓ）、選択された候補を登録する（ステップ２３５）。なお、選択されたパーツの候補を登録するとき、ＣＰＵ３１１は、編集対象のデータ本文の内、編集対象のパーツを示す箇所を選択された候補のパーツを示すように更新して登録する。
【０１６６】
ＣＰＵ３１１は、選択された候補を登録すると、上述したキャラクタの編集画面を再び表示する（ステップ２３７）。具体的には、ＣＰＵ３１１は、上側ＬＣＤ２２に表示されているキャラクタのパーツの中で編集対象として選択されたパーツを、登録した候補のパーツに切り替えて表示する。また、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されていたパーツの候補をそれぞれ示すアイコンを消去し、上述したキャラクタの編集画面に表示を切り替える。
【０１６７】
ＣＰＵ３１１は、キャラクタの編集画面に表示を切り替えると、ユーザによってパーツ選択の終了が選択されたか否かを判断する（ステップ２４０）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されている終了のアイコンにタッチされたか否かを判断する。ＣＰＵ３１１は、パーツ選択の終了が選択されていないと判断した場合（ステップ２４０でＮｏ）、ステップ２２０から処理を繰り返して、編集対象となるパーツを再びユーザに選択させる。
【０１６８】
一方、ＣＰＵ３１１は、パーツ選択の終了が選択されたと判断した場合（ステップ２４０でＹｅｓ）、次にキャラクタ情報を入力する画面に表示を切り替えて編集対象のキャラクタ情報の入力をユーザから受け付ける処理を開始する（ステップ２４５）。ここで、キャラクタ情報とは、例えば、キャラクタの名前、性別、年齢および当該キャラクタを紹介するコメントなどの情報である。ＣＰＵ３１１は、キャラクタ情報の入力の受け付けを開始すると、キャラクタ情報の入力を受け付けながら、キャラクタ情報の入力の完了がユーザによって選択されたか否かを判断する（ステップ２５０）。ＣＰＵ３１１は、キャラクタ情報の入力の完了が選択されていないと判断した場合（ステップ２５０でＮｏ）、キャラクタ情報の入力の中止がユーザによって選択されたか否かを判断する（ステップ２７０）。ＣＰＵ３１１は、キャラクタ情報の入力の中止が選択されていないと判断した場合（ステップＳ２７０でＮｏ）、ステップ２５０に処理を戻す。
【０１６９】
一方、ＣＰＵ３１１は、キャラクタ情報の入力の完了が選択されたと判断した場合（ステップ２５０でＹｅｓ）、編集対象のキャラクタが新規に作成されたキャラクタか否かを判断する（ステップ２５５）。具体的には、ＣＰＵ３１１は、メインメモリ３２に格納されている変更フラグＨｆを参照する。変更フラグＨｆがオフである場合、ＣＰＵ３１１は、編集対象となっているキャラクタが新規に作成されたキャラクタであると判断する（ステップ２５５でＹｅｓ）。一方、ＣＰＵ３１１は、変更フラグＨｆがオンである場合、ＣＰＵ３１１は、編集対象となっているキャラクタが既存のキャラクタであると判断する（ステップ２５５でＮｏ）。
【０１７０】
ＣＰＵ３１１は、新規に作成されたキャラクタであると判断した場合（ステップ２５５でＹｅｓ）、ユーザ作成データＵｄのユーザＩＤに作成者ＩＤを付与する（ステップ２６０）。一方、ＣＰＵ３１１は、新規に作成されたキャラクタでないと判断した場合（ステップ２５５でＮｏ）、編集対象となっているキャラクタが変更された既存のキャラクタであると判断して、ユーザ作成データＵｄのユーザＩＤに変更者ＩＤを追加する（ステップ２６５）。
【０１７１】
ＣＰＵ３１１は、ユーザ作成データＵｄに作成者ＩＤを付与する（ステップ２６０）またはユーザ作成データＵｄに変更者ＩＤを追加する（ステップ２６５）と、メインメモリ３２に格納されている変更フラグＨｆをオフに更新して（ステップ２７５）、キャラクタ作成処理を終了する。また、ＣＰＵ３１１は、ユーザによってキャラクタ情報の入力の中止が選択されたと判断したときにも（ステップ２７０でＹｅｓ）、変更フラグＨｆをオフに更新して（ステップ２７５）、キャラクタ編集処理を終了する。なお、ＣＰＵ３１１が、キャラクタ編集処理を終了するときには、上述したキャラクタ取り扱い画面に表示を切り替える。
【０１７２】
以上が、本実施例におけるキャラクタ編集処理の説明である。本実施例では、ＣＰＵ３１１が上述したキャラクタ編集処理を行うことによりユーザは自由にキャラクタを作成・編集でき、ユーザ作成データＵｄを生成することができる。
【０１７３】
図８Ａに戻り、ＣＰＵ３１１は、キャラクタの変更がユーザによって選択されなかったと判断した場合（ステップ１３０でＮｏ）、キャラクタのＬＢＬへの登録が選択されたか否かを判断する（ステップ１４５）。ＣＰＵ３１１は、キャラクタのＬＢＬへの登録がユーザによって選択されたと判断した場合（ステップ１４５でＹｅｓ）、ＬＢＬ登録処理を開始する（ステップ１５０）。以下、図８Ｅを参照して、上記ステップ１５０で行うＬＢＬ登録処理の詳細について説明する。
【０１７４】
［ＬＢＬ登録処理］
図８Ｅにおいて、ＣＰＵ３１１は、メインメモリ３２に格納されているユーザ作成データＵｄの内、他のゲーム装置１０から受信したキャラクタのみを下側ＬＣＤ１２に表示する（ステップ３０１）。具体的には、ＣＰＵ３１１は、まず、キャラクタ取り扱い画面を消去する。そして、ＣＰＵ３１１は、他のゲーム装置１０から受信したキャラクタのみを下側ＬＣＤ１２に表示してユーザからのタッチ操作によって選択できるようにする。ＣＰＵ３１１は、他のゲーム装置１０から受信したキャラクタのみを表示するとき、作成者ＩＤおよび変更者ＩＤの両方が他のゲーム装置１０のＩＤであるユーザ作成データＵｄで示されるキャラクタのみを表示する。また、ＣＰＵ３１１が、ＬＢＬ登録処理においてキャラクタを表示するときには、当該処理を終了するためのアイコンも下側ＬＣＤ１２に表示する。これにより、ＬＢＬ登録処理画面が下側ＬＣＤ１２に表示される。
【０１７５】
ＣＰＵ３１１は、他のゲーム装置１０から受信したキャラクタを表示すると、ＬＢＬに登録するキャラクタがユーザによって選択されたか否かを判断する（ステップ３０５）。具体的には、ＣＰＵ３１１は、下側ＬＣＤ１２に表示されているいずれかのキャラクタにタッチ操作されたか否かを判断する。
【０１７６】
そして、ＣＰＵ３１１は、ＬＢＬに登録するキャラクタがユーザによって選択されたと判断すると（ステップ３０５でＹｅｓ）、まず、選択されたキャラクタを登録するＬＢＬとして変更者ＬＢＬがユーザによって選択されたか否かを判断する（ステップ３１０）。ＣＰＵ３１１は変更者ＬＢＬが選択されていないと判断したとき（ステップ３１０でＮｏ）、選択されたキャラクタを登録するＬＢＬとしてデータＬＢＬがユーザによって選択されたか否かを判断する（ステップ３２５）。
【０１７７】
ＣＰＵ３１１は、選択されたキャラクタを登録するＬＢＬとしてデータＬＢＬがユーザによって選択されていないと判断したとき（ステップ３２５でＮｏ）、登録するＬＢＬが選択されなかったものとして、処理をステップ３０５に戻す。
【０１７８】
一方、ＣＰＵ３１１は、選択されたキャラクタを登録するＬＢＬとして変更者ＬＢＬが選択されたと判断したとき（ステップ３１０でＹｅｓ）、当該キャラクタを変更者ＬＢＬに登録する。具体的には、ＣＰＵ３１１は、選択されたキャラクタを示すユーザ作成データＵｄに含まれる最後の変更者ＩＤとアプリＩＤとを含む変更者特定ＬＢＬデータを生成して、変更者ＬＢＬデータに追加して登録する（ステップ３１５）。
【０１７９】
一方、ＣＰＵ３１１は、選択されたキャラクタを登録するＬＢＬとしてデータＬＢＬがユーザによって選択されたと判断したとき（ステップ３２５でＹｅｓ）、当該キャラクタをデータＬＢＬに登録する。具体的には、ＣＰＵ３１１は、選択されたキャラクタを示すユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとを含むデータ特定ＬＢＬデータを生成して、データＬＢＬデータに追加して登録する（ステップ３３０）。
【０１８０】
ＣＰＵ３１１は、変更者ＬＢＬにキャラクタを登録（ステップ３１５）またはデータＬＢＬにキャラクタを登録（ステップ３３０）すると、登録したキャラクタのサーバ５への通報がユーザによって選択されたか否かを判断する（ステップ３４０）。
【０１８１】
ＣＰＵ３１１は、ユーザによって通報が選択されたと判断したとき（ステップ３４０でＹｅｓ）、通報するキャラクタを示すユーザ作成データＵｄをサーバ５に送信するタスクを示すタスクデータＴｄを生成する（ステップ３４５）。後述で明らかとなるが、このとき生成されたタスクデータＴｄで示されるタスクが実行されれば、ユーザが道徳上の観点から不適切と判断したキャラクタを示すユーザ作成データＵｄがサーバ５に送信され通報される。
【０１８２】
一方、ＣＰＵ３１１は、通報がユーザによって選択されないと判断したとき（ステップ３４０でＮｏ）、ステップ３０５へ処理を戻して、ＬＢＬに登録するキャラクタがユーザによって選択されたか否かを再び判断する。また、ＣＰＵ３１１は、ステップ３４５においてタスクデータＴｄを生成した後も、ステップ３０５へ処理を戻して、ＬＢＬに登録する他のキャラクタがユーザによって選択されたか否かを再び判断する。
【０１８３】
一方、ＣＰＵ３１１は、ＬＢＬに登録するキャラクタが選択されなかったと判断したとき（ステップ３０５でＮｏ）、ユーザによってＬＢＬ登録処理の終了が選択されたか否かを判断する（ステップ３５０）。ＣＰＵ３１１は、ＬＢＬ登録処理の終了が選択されたと判断したとき（ステップ３５０でＹｅｓ）、ＬＢＬ登録処理を終了する。一方、ＣＰＵ３１１は、ＬＢＬ登録処理の終了が選択されていないと判断したとき、ステップ３０５へ処理を戻して、ＬＢＬに登録するキャラクタがユーザによって選択されたか否かを再び判断する。なお、ＣＰＵ３１１が、ＬＢＬ登録処理を終了するときには、上述したＬＢＬ登録処理画面からキャラクタ取り扱い画面に表示が切り替えられる。
【０１８４】
以上が、本実施例におけるＬＢＬ登録処理の説明である。上述したＬＢＬ登録処理によれば、ユーザは、他のゲーム装置１０から受信したキャラクタの中で道徳上の観点から好ましくないと感じたキャラクタを登録することができる。より詳細には、ＬＢＬ登録処理においてユーザは、キャラクタを変更者ＬＢＬまたはデータＬＢＬのいずれかに登録できる。そして、ユーザはキャラクタを変更者ＬＢＬに登録することにより、当該キャラクタの最後の変更者を道徳上の観点から好ましくないキャラクタを作成したユーザとしてＬＢＬに登録できる。一方、ユーザはキャラクタをデータＬＢＬに登録することにより、当該キャラクタを示すデータを道徳上の観点から好ましくないキャラクタを示すデータとしてＬＢＬに登録できる。
【０１８５】
また、上述したＬＢＬ登録処理では、ユーザがＬＢＬに登録したキャラクタをサーバ５に通報することもできる。サーバ５に通報されたキャラクタは、後に詳述するサーバ処理によって所定の条件を満たすと判断されたときにＧＢＬに登録される。つまり、ＬＢＬ登録処理においてキャラクタを通報できるようにすることで、サーバ５は、本システムに含まれる全てのゲーム装置１０のユーザの感覚（総意）に基づいてＧＢＬに登録するキャラクタを判断できる。
【０１８６】
また、ＬＢＬおよびＧＢＬの少なくともいずれか一方に登録されたキャラクタのユーザ作成データＵｄは、後に詳述するフィルタリング処理によって非表示データに設定される。これにより、ユーザは、道徳上の観点から好ましくないと感じたキャラクタを表示しないようにすることができる。
【０１８７】
図８Ａに戻り、ＣＰＵ３１１は、ＬＢＬへの登録が選択されていないと判断した場合（ステップ１４５でＮｏ）、図８Ｂにおいて、キャラクタのすれ違い通信における送信がユーザによって選択されたか否かを判断する（ステップ１５５）。
【０１８８】
ＣＰＵ３１１は、キャラクタのすれ違い通信における送信が選択されたと判断した場合（ステップ１５５でＹｅｓ）、送信するキャラクタの選択をユーザから受け付ける（ステップ１５７）。ＣＰＵ３１１は、送信するキャラクタの選択をユーザから受け付けると、選択されたキャラクタのユーザ作成データＵｄをすれ違い送信データＳｄとしてメインメモリ３２に格納する（ステップ１６０）。ここで、上述したすれ違い通信処理について、図８Ｆを参照して説明する。なお、すれ違い通信処理において行われる全てのデータの送受信は、上述したように、同種のゲーム装置との間で無線通信を行う機能を有するローカル通信モジュール３７を用いて行われる。
【０１８９】
［すれ違い通信処理］
図８Ｆにおいて、ＣＰＵ３１１は、メインメモリ３２を参照して、通信時刻から所定時間が経過したＭＡＣアドレス（図示せず）が存在するか否かを判断する（ステップ４０１）。ここで、通信時刻とは、後述するように送信ボックスデータＳｂに含まれるデータまたは接続応答を送信したときの時刻である。通信時刻は、送信ボックスデータＳｂに含まれるデータまたは接続応答を送信したときに送信先のＭＡＣアドレスと共にメインメモリ３２に格納される。後に明らかとなるが、本実施例では、通信時刻を用いることにより同一の通信先との短期間における重複した通信を防ぐことができる。
【０１９０】
ＣＰＵ３１１は、所定時間が経過したＭＡＣアドレスが格納されていると判断したとき（ステップ４０１でＹｅｓ）、当該ＭＡＣアドレスを通信時刻と共にメインメモリ３２から削除する（ステップ４０５）。一方、ＣＰＵ３１１は、所定時間が経過したＭＡＣアドレスが格納されていないと判断したとき（ステップ４０１でＮｏ）またはＭＡＣアドレスを削除すると（ステップ４０５）、接続要求をブロードキャストで送信する（ステップ４１０）。ここで、接続要求とは、他のゲーム装置１０に対してすれ違い通信を要求するために無線で送信される通信フレームである。接続要求には、当該通信フレームが接続要求であることを示す情報、送信元のゲーム装置１０のＭＡＣアドレス、および送信ボックスデータＳｂに含まれる全てのデータ（すれ違い送信データＳｄおよび送信ＧＢＬデータＳｇｄ）にそれぞれ含まれるアプリＩＤからなる。
【０１９１】
ＣＰＵ３１１は、接続要求を送信すると、自身の接続要求に対する接続応答を受信したか否かを、当該接続要求を送信してから所定期間だけ判断する（ステップ４１５）。ここで、接続応答とは、前述の接続要求を受信した他のゲーム装置１０からの応答を示す通信フレームである。接続応答は４つの情報からなる。すなわち、当該通信フレームが接続応答であることを示す情報、接続要求の送信元のＭＡＣアドレス、当該接続応答の送信元（他のゲーム装置１０）のＭＡＣアドレスおよび接続応答の送信元のゲーム装置１０に格納されている送信ボックスデータＳｂに含まれる全てのデータ（すれ違い送信データＳｄおよび送信ＧＢＬデータＳｇｄ）にそれぞれ含まれるアプリＩＤからなる。
【０１９２】
ＣＰＵ３１１は、自身の接続要求に対する接続応答を受信したか否かを判断するとき、ＭＡＣアドレスを用いて判断する。より詳細には、ＣＰＵ３１１は、接続要求を送信してから所定期間が経過するまでに受信した接続応答に含まれるＭＡＣアドレスと自身のゲーム装置１０のＭＡＣアドレスとが一致するか否かを判断する。ＣＰＵ３１１は、両方のＭＡＣアドレスが一致すれば、当該ＭＡＣアドレスを含む接続応答が自身の接続要求に対する接続応答であると判断できる。
【０１９３】
ＣＰＵ３１１は、自身の接続要求に対する接続応答を受信したと判断した場合（ステップ４１５でＹｅｓ）、当該接続応答を送信したゲーム装置１０とすれ違い通信をする必要があるか否かを判断する（ステップ４２０）。具体的には、ＣＰＵ３１１は、受信した接続応答に含まれるアプリＩＤの中に、送信ボックスデータＳｂに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在するか否かを判断する。そして、ＣＰＵ３１１は、受信した接続応答に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在する場合、すれ違い通信が必要であると判断する。一方、ＣＰＵ３１１は、受信した接続応答に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在しない場合、すれ違い通信が必要でないと判断する。
【０１９４】
ＣＰＵ３１１は、すれ違い通信が必要であると判断した場合（ステップ４２０でＹｅｓ）、すれ違い通信を開始する。具体的には、ＣＰＵ３１１は、ステップ４２０で一致すると判断したアプリＩＤを含む全てのデータを、ステップ４１５で判断した接続応答の送信元に送信する（ステップ４２５）。
【０１９５】
ＣＰＵ３１１は、ステップ４２０で一致すると判断したアプリＩＤを含む全てのデータを送信すると、送信先のゲーム装置１０のＭＡＣアドレス（接続応答に含まれていた送信元のＭＡＣアドレス）と共に、送信時刻を前述の通信時刻としてメインメモリ３２に格納する（ステップ４３０）。
【０１９６】
次に、ＣＰＵ３１１は、ステップ４２５におけるデータの送信先から当該送信先の送信ボックスデータＳｂに含まれるデータを受信済みであるか否かを受信ボックスデータＪｂを参照して判断する（ステップ４３５）。ＣＰＵ３１１は、データを受信済みであると判断した場合（ステップ４３５でＹｅｓ）、受信ボックスデータＪｂに含まれるすれ違い受信データＪｄをフィルタリング対象として後述するフィルタリング処理を行う（ステップ４８０）。
【０１９７】
一方、ＣＰＵ３１１は、接続要求を送信した後に接続応答を受信していないと判断した場合（ステップ４１５でＮｏ）、他のゲーム装置１０から接続要求を受信したか否かを判断する（ステップ４４０）。ＣＰＵ３１１は、他のゲーム装置１０から接続要求を受信したと判断した場合（ステップ４４０でＹｅｓ）、受信した接続要求の送信元に対して接続応答を送信することが可能か否かを判断する（ステップ４４５）。具体的には、ＣＰＵ３１１は、受信した接続要求に含まれている送信元のＭＡＣアドレスが通信時刻と共にメインメモリ３２に格納されているか否かを判断する。ＣＰＵ３１１は、接続要求に含まれているＭＡＣアドレスがメインメモリ３２に格納されていない場合、短期間に重複した通信をすることにならないので、接続応答を送信することが可能であると判断できる。この理由は、上述したように通信時刻と共にメインメモリ３２に格納されているＭＡＣアドレスは、当該通信時刻から所定期間が経過すると削除されるためである。
【０１９８】
ＣＰＵ３１１は、接続応答を送信することが可能であると判断した場合（ステップ４４５でＹｅｓ）、ステップ４４０で受信したと判断した接続要求の送信元とすれ違い通信をする必要があるか否かを判断する（ステップ４５０）。具体的には、ＣＰＵ３１１は、受信した接続要求に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在するか否かを判断する。そして、ＣＰＵ３１１は、受信した接続要求に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在する場合、すれ違い通信が必要であると判断する。一方、ＣＰＵ３１１は、受信した接続要求に含まれるアプリＩＤの中に、送信ボックスデータＳｄに含まれるそれぞれのデータのアプリＩＤと一致するアプリＩＤが存在しない場合、すれ違い通信が必要でないと判断する。
【０１９９】
ＣＰＵ３１１は、すれ違い通信が必要であると判断した場合（ステップ４５０でＹｅｓ）、ステップ４４０で受信したと判断した接続要求の送信元に対して接続応答を送信する（ステップ４５５）。接続応答を送信すると、ＣＰＵ３１１は、その送信時刻を通信時刻として、送信先のゲーム装置１０のＭＡＣアドレス（ステップ４４０で受信したと判断した接続要求に含まれていた送信元のＭＡＣアドレス）と共にメインメモリ３２に格納する（ステップ４６０）。
【０２００】
次に、ＣＰＵ３１１は、ステップ４５５で送信した接続応答の送信先からデータを受信したか否かを判断する（ステップ４６５）。ＣＰＵ３１１は、データを受信したと判断した場合（ステップ４６５でＹｅｓ）、受信したデータを受信ボックスデータＪｂ内に格納する（ステップ４７０）。具体的には、ＣＰＵ３１１は、受信したデータの中にすれ違い送信データＳｄが含まれていれば、すれ違い受信データＪｄとして受信ボックスデータＪｂに格納する。また、ＣＰＵ３１１は、受信したデータの中に送信ＧＢＬデータＳｇｄが含まれていれば、受信ＧＢＬデータＪｇｄとして受信ボックスデータＪｂに格納する。
【０２０１】
ＣＰＵ３１１は、データを格納すると、当該データの送信元に対してデータを送信済みか否かを判断する（ステップ４７５）。ＣＰＵ３１１は、データを送信済みであると判断すると、後述するフィルタリング処理を実行する（ステップ４８０）。より詳細には、ＣＰＵ３１１は、受信したデータの中にすれ違い送信データＳｄが含まれていれば、当該すれ違い送信データＳｄすなわちユーザ作成データＵｄをフィルタリング対象として、後述するフィルタリング処理をする。なお、ＣＰＵ３１１は、ステップ４７５からフィルタリング処理へ進むときには、ステップ４７０で格納したすれ違い受信データＪｄをフィルタリング対象とする。
【０２０２】
一方、ＣＰＵ３１１は、データを送信済みでないと判断した場合（ステップ４７５でＮｏ）、前述のステップ４２５へ処理を進めてデータを送信する。なお、ステップ４２５の説明では、データの送信先は、ステップ４１５で判断した接続応答の送信元であるものとした。しかしながら、ＣＰＵ３１１が、ステップ４７５からステップ４２５へ処理を進めたときに送信するデータの送信先は、ステップ４５５で送信した接続応答の送信先となる。
【０２０３】
また、ＣＰＵ３１１は、ステップ４３５でデータを受信していないと判断したときにも、ステップ４６５へ処理を進めてデータを受信したか否かを判断する。上述したステップ４６５の説明では、ステップ４５５で送信した接続応答の送信先からデータを受信したか否かを判断するものとした。しかしながら、ＣＰＵ３１１が、ステップ４３５からステップ４６５へ処理を進めたときに判断するデータの送信元は、ステップ４２５で送信したデータの送信先となる。
【０２０４】
一方、ＣＰＵ３１１は、データを受信していないと判断した場合（ステップ４６５でＮｏ）、すれ違い通信処理をはじめから繰り返す。
【０２０５】
以上が、本実施例におけるすれ違い通信処理の説明である。上述したように、すれ違い通信処理は、本システムに含まれるゲーム装置１０のそれぞれにおいて常に繰り返し実行される。これにより、それぞれのゲーム装置１０は互いのローカル通信モジュール３７の通信範囲内に位置したときに、すれ違い通信を自動的に実行することができる。そして、互いのゲーム装置１０において、同一のアプリケーションで取り扱われるユーザ作成データＵｄがすれ違い送信データＳｄとして格納されている場合に互いのデータを自動的に送受信して交換できる。本実施例では、本システムに含まれるそれぞれのゲーム装置１０においてユーザ作成データＵｄを取り扱うアプリケーションとして、キャラクタ取り扱いアプリケーションが実行される。従って、本システムでは、上述したようにすれ違い通信で送信するようにユーザによって選択されたキャラクタをそれぞれのゲーム装置１０で自動的に交換することができる。このように交換されたキャラクタを示すデータは、図８Ａのステップ１０１で新たに受信されたすれ違い受信データＪｄとして判断され、ステップ１０５においてユーザ作成データＵｄとして格納される。
【０２０６】
また、本システムでは、すれ違い通信で送信ＧＢＬデータＳｇｄを互いのゲーム装置１０で送受信する。これにより、本システムでは、互いのゲーム装置１０に格納されているＧＢＬデータＧｄをすれ違い通信で自動的に交換することができる。また、すれ違い通信で受信した受信ＧＢＬデータＪｇｄは、後述するＧＢＬ更新処理において新しいバージョンであると判断されたときに、ＧＢＬデータＧｄとしてメインメモリ３２に格納され、更新される。従って、本システムによれば、インターネット通信網３に接続できないゲーム装置１０が存在したとしても、すれ違い通信可能な他のゲーム装置１０が存在すれば、ＧＢＬを新たなＧＢＬに更新することができる。
【０２０７】
また、すれ違い通信処理、それぞれ後に詳述するインターネット通信処理またはローカル通信処理で受信したユーザ作成データＵｄで示されるキャラクタのすれ違い通信における送信がユーザによって選択された場合には、当該ユーザ作成データＵｄをそのまますれ違い通信において転送できる。
【０２０８】
図８Ｂに戻って、ＣＰＵ３１１は、キャラクタのすれ違い通信における送信がユーザによって選択されていないと判断した場合（ステップ１５５でＮｏ）、キャラクタのインターネット通信網３を用いた受信がユーザによって選択されたか否かを判断する（ステップ１６５）。ＣＰＵ３１１は、キャラクタのインターネット通信網３を用いた受信が選択されたと判断した場合（ステップ１６５でＹｅｓ）、キャラクタを示すユーザ作成データＵｄを受信するための上述したタスクデータＴｄを生成する（ステップ１７０）。
【０２０９】
一方、ＣＰＵ３１１は、キャラクタのインターネット通信網３を用いた受信が選択されていないと判断した場合（ステップ１６５でＮｏ）、キャラクタのインターネット通信網３を用いた送信がユーザによって選択されたか否かを判断する（ステップ１７５）。ＣＰＵ３１１は、キャラクタのインターネット通信網３を介した送信が選択されたと判断した場合（ステップ１７５でＹｅｓ）、送信するキャラクタのユーザによる選択と、送信先の相手を表す情報の入力又は選択とを受け付ける（ステップ１７７）。ユーザによるキャラクタの選択と、送信先の入力又は選択とを受け付けると、ＣＰＵ３１１は、ユーザによって選択されたキャラクタを送信するための上述したタスクデータＴｄを生成する（ステップ１８０）。
【０２１０】
ここで、ＣＰＵ３１１がインターネット通信網３を用いてデータを送受信するためのインターネット通信処理について、図８Ｇを参照して説明する。なお、インターネット通信処理において行われる全てのデータの送受信は、上述したようにインターネット通信網３を用いて他の機器との間でデータを送受信するための無線通信モジュール３６を用いて行われる。
【０２１１】
［インターネット通信処理］
図８Ｇにおいて、ＣＰＵ３１１は、メインメモリ３２を参照して、次回実行時刻が現在時刻を過ぎているタスクデータＴｄが存在するか否かを判断する（ステップ５０１）。ＣＰＵ３１１は、次回実行時刻が現在時刻を過ぎているタスクデータＴｄが存在していると判断した場合（ステップ５０１でＹｅｓ）、無線通信モジュール３６の通信範囲内に存在する前述のＡＰ２の検出を開始する（ステップ５１０）。ＣＰＵ３１１は、所定時間だけＡＰ２の検出を実行した後、ＡＰ２を検出できたか否かを判断する（ステップ５１５）。ＣＰＵ３１１は、ＡＰ２を検出できたと判断した場合（ステップ５１５でＹｅｓ）、検出したＡＰ２との通信を開始する（ステップ５２０）。
【０２１２】
一方、ＣＰＵ３１１は、次回実行時刻が現在時刻を過ぎているタスクデータＴｄが存在していないと判断したとき（ステップ５０１でＮｏ）、又は、ＡＰ２を検出できなかったと判断したとき（ステップ５１５でＮｏ）、ステップ５０１から処理を繰り返す。
【０２１３】
次に、ＣＰＵ３１１は、ＡＰ２との通信を開始すると、ステップ５０１で判断したタスクデータＴｄの中から、実行時刻が過ぎているが未だに実行されていない未実行のタスクを示すタスクデータＴｄを選択する（ステップ５２５）。ＣＰＵ３１１は、未実行のタスクを選択すると、選択した未実行タスクを全て実行したか否かを判断する（ステップ５３０）。ＣＰＵ３１１は、未実行タスクを全て実行していないと判断した場合（ステップ５３０でＮｏ）、未実行タスクを１つだけ選択する（ステップ５３５）。ＣＰＵ３１１が、全ての未実行タスクの中から１つを選択する手法は、例えば、所定の優先度を用いるなど、任意の手法を用いてかまわない。
【０２１４】
ＣＰＵ３１１は、未実行タスクを選択すると、選択した未実行タスクが受信タスクであるか否かを判断する（ステップ５４０）。具体的には、ＣＰＵ３１１は、選択した未実行タスクを示すタスクデータＴｄに含まれる送信／受信識別フラグを参照して、当該フラグが受信を示すか否かを判断する。
【０２１５】
ＣＰＵ３１１は、選択した未実行タスクが受信タスクであると判断した場合（ステップ５４０でＹｅｓ）、当該タスクを示すタスクデータＴｄに従ってデータを受信する（ステップ５４５）。具体的には、ＣＰＵ３１１は、未実行タスクを示すタスクデータＴｄに含まれる通信先ＵＲＬにアクセスして、データを受信する。受信されたデータは、タスクデータＴｄに含まれる格納先情報で示される格納先に格納される。例えば、配信用ＧＢＬデータＧｓｄを受信するためのタスクが実行されたときには、受信された配信用ＧＢＬデータＧｓｄが、ネット受信ＧＢＬデータＮｇｄとして、メインメモリ３２における格納先に格納され更新される。また、例えば、キャラクタを受信するためのタスクが実行されたときには、受信されたキャラクタを示すユーザ作成データＵｄがメインメモリ３２における格納先に格納される。
【０２１６】
ＣＰＵ３１１は、受信タスクを実行すると、実行したタスクを示すタスクデータＴｄに含まれる次回実行時刻を上述したように更新する（ステップ５５０）。
【０２１７】
一方、ＣＰＵ３１１は、選択した未実行タスクが受信タスクでないと判断した場合（ステップ５４０でＮｏ）、当該未実行タスクが送信タスクであるとして、当該タスクを示すタスクデータＴｄに従ってデータを送信する（ステップ５５５）。具体的には、ＣＰＵ３１１は、未実行の送信タスクを示すタスクデータＴｄに含まれる通信先ＵＲＬにアクセスして、データを送信する。送信されるデータは、タスクデータＴｄに含まれる格納先情報で示される格納先に格納されているデータとなる。例えば、キャラクタを送信するためのタスクが実行されたときには、ユーザによって選択されたキャラクタを示すユーザ作成データＵｄが、キャラクタの送信を受け付けるサーバ５を表すＵＲＬへ送信される。また、例えば、通報のためのタスクが実行されたときには、ユーザによって選択された通報するキャラクタを示すユーザ作成データＵｄがサーバ５へ送信される。
【０２１８】
ＣＰＵ３１１は、送信タスクを実行すると、実行したタスクを示すタスクデータＴｄを削除する（ステップ５６０）。
【０２１９】
次に、ＣＰＵ３１１は、実行したタスクが、配信用ＧＢＬデータＧｓｄを受信するためのタスクまたは任意のデータを送信するためのタスクであったか否かを判断する（ステップ５６５）。具体的には、ＣＰＵ３１１は、実行したタスクを示すタスクデータＴｄに含まれる送信／受信識別フラグと、格納先情報で示される格納先に格納されているデータとを参照して判断する。ＣＰＵ３１１は、実行したタスクが、配信用ＧＢＬデータＧｓｄを受信するためのタスクまたは任意のデータを送信するためのタスクではないと判断した場合（ステップ５６５でＮｏ）、実行したタスクが配信用ＧＢＬデータＧｓｄ以外のデータの受信であったと判断する。すなわち、ＣＰＵ３１１は、実行したタスクがユーザ作成データＵｄの受信であったと判断する。
【０２２０】
ＣＰＵ３１１は、実行したタスクがユーザ作成データＵｄの受信であったと判断すると（ステップ５６５でＹｅｓ）、受信したデータをフィルタリング対象として後述するフィルタリング処理を実行する（ステップ５７０）。一方、ＣＰＵ３１１は、実行したタスクが配信用ＧＢＬデータＧｓｄを受信するためのタスクまたは任意のデータを送信するためのタスクであると判断した場合（ステップ５６５でＹｅｓ）、フィルタリング処理の必要がないと判断し、処理をステップ５３０へ戻して、残りの未実行タスクがあるか否かを判断する。
【０２２１】
一方、ＣＰＵ３１１は、選択した未実行タスクを全て実行した（残りの未実行タスクがない）と判断した場合（ステップ５３０でＹｅｓ）、インターネット通信処理を始めから繰り返す。
【０２２２】
以上が、本実施例におけるインターネット通信処理の説明である。上述したように、インターネット通信処理は、本システムに含まれるゲーム装置１０のそれぞれにおいて常に繰り返し実行される。インターネット通信処理では、ユーザ作成データＵｄを送信するためのタスク、キャラクタを通報するためのタスク、ユーザ作成データＵｄを受信するためのタスクおよび配信用ＧＢＬデータＧｓｄを受信するためのタスクが実行される。そして、これらのタスクの中で送信のためのタスクを示すタスクデータＴｄは、当該タスクが実行されるまで削除されない。従って、キャラクタを通報するためのタスクは実行されるまで削除されないので、ユーザによって選択されたキャラクタを示すユーザ作成データＵｄを確実に通報することができる。
【０２２３】
また、上述したタスクの中で受信のタスクを示すタスクデータＴｄは、当該タスクが実行される度に次回実行時刻が更新される。従って、配信用ＧＢＬデータＧｓｄを受信するためのタスクは定期的に実行されるので、サーバ５によって管理されているＧＢＬを定期的に受信できる。
【０２２４】
また、後に詳述するローカル通信処理、それぞれ上述したすれ違い通信処理またはインターネット通信処理で受信したユーザ作成データＵｄで示されるキャラクタのインターネット通信網３を用いた送信がユーザによって選択された場合には、当該ユーザ作成データＵｄをそのままインターネット通信網３を介して転送できる。
【０２２５】
図８Ｂに戻って、ＣＰＵ３１１は、キャラクタのインターネット通信網３を用いた送信が選択されていないと判断した場合（ステップ１７５でＮｏ）、キャラクタのローカル通信での送信がユーザによって選択されたか否かを判断する（ステップ１８５）。ＣＰＵ３１１は、キャラクタのローカル通信での送信が選択されたと判断した場合（ステップ１８５でＹｅｓ）、送信するキャラクタのユーザによる選択を受け付ける（ステップ１８７）。ＣＰＵ３１１は、送信するキャラクタの選択を受け付けると、ローカル通信処理を実行する（ステップ１９０）。
【０２２６】
なお、ローカル通信処理において行われる全てのデータの送受信は、上述したように、同種のゲーム装置との間で無線通信を行う機能を有するローカル通信モジュール３７を用いて行われる。
【０２２７】
［ローカル通信処理］
図８Ｈにおいて、ＣＰＵ３１１は、キャラクタ取り扱い画面を消去し、通信範囲内に存在する他のゲーム装置１０を検出中であることを示す画像を下側ＬＣＤ１２に表示する（ステップ６０１）。検出中であることを示す画像を表示すると、ＣＰＵ３１１は、ローカル通信モジュール３７の通信範囲内に存在する他のゲーム装置１０の検出を開始する（ステップ６０３）。ＣＰＵ３１１は、所定時間だけ他のゲーム装置１０の検出を実行した後、検出中であることを示す画像を消去して、他のゲーム装置１０を検出できたか否かを判断する（ステップ６０５）。ＣＰＵ３１１は、他のゲーム装置１０を検出できたと判断すると（ステップ６０５でＹｅｓ）、検出したゲーム装置１０を下側ＬＣＤ１２に検出結果として一覧表示する（ステップ６１０）。ＣＰＵ３１１は、検出結果を表示すると、表示した検出結果の中から通信先がユーザによって選択されたか否かを判断する（ステップ６１５）。具体的には、検出結果の一覧のいずれかにタッチ操作されたか否かを判断する。
【０２２８】
ＣＰＵ３１１は、ユーザによって通信先のゲーム装置１０が選択されたと判断した場合（ステップ６１５でＹｅｓ）、当該通信先のゲーム装置１０によって自身のゲーム装置１０が通信先として選択されたか否かを当該通信先から送信される情報に基づいて判断する（ステップ６２０）。ＣＰＵ３１１は、通信先によって自身のゲーム装置１０が選択されたと判断した場合（ステップ６２０でＹｅｓ）、ステップ１８７で選択されたキャラクタのユーザ作成データＵｄを当該通信先に送信する（ステップ６２５）。そして、ＣＰＵ３１１は、自身のゲーム装置１０からのユーザ作成データＵｄの送信に応じて送信される通信先からのユーザ作成データＵｄを受信する（ステップ６３０）。ＣＰＵ３１１は、通信先からユーザ作成データＵｄを受信すると、受信したユーザ作成データＵｄをフィルタリング対象として、後述するフィルタリング処理を実行する（ステップ６３５）。ＣＰＵ３１１は、フィルタリング処理を実行した後、受信したユーザ作成データＵｄをメインメモリ３２に格納する。
【０２２９】
一方、ＣＰＵ３１１は、通信先を発見できなかった（ステップ６０５でＮｏ）、ユーザによって通信先が選択されなかった(ステップ６１５でＮｏ）あるいは通信先によって自身のゲーム装置１０が選択されなかった(ステップ６２０でＮｏ）場合、データを受信できないのでフィルタリング処理をすることなく、ローカル通信処理を終了する。
【０２３０】
以上が、本実施例におけるローカル通信処理の説明である。上述の説明から明らかなように、ローカル通信処理は、ユーザからの操作に応じて即座に実行される。これにより、ユーザは、すれ違い通信による自動的なデータの送受信のみに頼ることなく、自らの意志でユーザ作成データＵｄを他のゲーム装置１０と交換することができる。
【０２３１】
また、それぞれ上述したすれ違い通信処理、インターネット通信処理またはローカル通信処理で受信したユーザ作成データＵｄで示されるキャラクタのローカル通信での送信がユーザによって選択された場合には、当該ユーザ作成データＵｄをそのままローカル通信において転送できる。
【０２３２】
図８Ｂに戻り、ＣＰＵ３１１は、ユーザ作成データＵｄのローカル通信での送信がユーザによって選択されていないと判断した場合（ステップ１８５でＮｏ）、キャラクタ取り扱い処理において必要な他の各種処理を実行する（ステップ１９５）。キャラクタ取り扱い処理において必要な他の各処理とは、例えば、上側ＬＣＤ２２に表示されているキャラクタの動作を制御する処理などである。
【０２３３】
ＣＰＵ３１１は、ユーザ作成データ生成処理（図８Ａのステップ１４０）、ＬＢＬ登録処理（ステップ１５０）、すれ違い通信で送信するユーザ作成データＵｄを格納する処理（図８Ｂのステップ１６０）、インターネット通信処理での送信が選択されたときにおけるタスクを生成する処理（ステップ１７０、ステップ１８０）、ローカル通信処理（ステップ１９０）および前述の各種処理（ステップ１９５）のいずれかを実行すると、キャラクタ取り扱い処理を終了する選択がユーザによってされたか否かを判断する（ステップ２００）。ＣＰＵ３１１は、キャラクタ作成処理を終了する選択がユーザによってされていないと判断した場合（ステップ２００でＮｏ）、ステップ１１５に処理を戻す。上述したように、ステップ１１５では、メインメモリ３２に格納されている全てのユーザ作成データＵｄをフィルタリング対象としてフィルタリング処理が実行される。一方、キャラクタ取り扱い処理を終了する選択がなされた場合（ステップ２００でＹｅｓ）、キャラクタ取り扱い処理を終了し、上述のランチャーアプリケーションに戻る。
【０２３４】
以上が、本実施例におけるキャラクタ取り扱い処理の説明である。
【０２３５】
［フィルタリング処理］
次に、図８Ｉを参照して、本実施例におけるフィルタリング処理について説明する。図８Ｉにおいて、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中から変更者ＬＢＬデータを構成するそれぞれの変更者特定ＬＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７０１）。
【０２３６】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、変更者ＬＢＬデータを構成するそれぞれの変更者特定ＬＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７０１でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７０５）。
【０２３７】
これにより、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄを最後に変更した変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであることを判断できる。また、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザである場合に、当該キャラクタを表示する前に非表示データとして設定できる。また、変更者ＬＢＬデータは、上述したようにＬＢＬ登録処理において自身のゲーム装置１０のユーザによる選択に応じてデータが登録される。従って、ＣＰＵ３１１は変更者ＬＢＬデータに基づいて非表示データを設定することにより、自身のゲーム装置１０のユーザが自ら登録したデータを表示しないように設定できる。
【０２３８】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中から変更者ＬＢＬデータを構成するそれぞれの変更者特定ＬＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７０１でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中から、データＬＢＬデータを構成するそれぞれのデータ特定ＬＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７１０）。
【０２３９】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中からデータＬＢＬデータを構成するそれぞれのデータ特定ＬＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７１０でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７１５）。
【０２４０】
これにより、ＣＰＵ３１１は、キャラクタが道徳上の観点から好ましくないキャラクタであることをデータＬＢＬに基づいて判断できる。そして、ＣＰＵ３１１は、ユーザ作成データＵｄによって示されるキャラクタに基づいて当該キャラクタを表示しないように設定できる。また、データＬＢＬデータは、上述したようにＬＢＬ登録処理においてＣＰＵ３１１自身のゲーム装置１０のユーザによる選択に応じてデータが登録される。従って、ＣＰＵ３１１は、データＬＢＬデータに基づいて非表示データを設定することにより、自身のゲーム装置１０のユーザが自ら登録したデータを表示しないように設定できる。
【０２４１】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中からデータＬＢＬデータを構成するそれぞれのデータ特定ＬＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７１０でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中から、変更者ＧＢＬデータを構成するそれぞれの変更者特定ＧＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７２０）。
【０２４２】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中から変更者ＧＢＬデータを構成するそれぞれの変更者特定ＧＢＬデータに含まれるアプリＩＤとユーザＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７２０でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７２５）。
【０２４３】
これにより、ＣＰＵ３１１は、キャラクタを最後に変更した変更者は道徳上の観点から好ましくないキャラクタを作成する変更者であることを変更者ＧＢＬに基づいて判断できる。そして、ＣＰＵ３１１は、キャラクタの外見に関わらずに最後の変更者に基づいて当該キャラクタを表示しないように設定できる。また、変更者ＧＢＬはサーバ５によって管理されるＧＢＬである。そして、後述するように、サーバ５は本システムに含まれる全てのゲーム装置１０のユーザそれぞれからの通報回数に基づいて変更者ＧＢＬを管理する。サーバ５が通報を受けるのは、上述したようにユーザが道徳上の観点から好ましくないと判断しさらに通報する選択をしたときである。従って、ＣＰＵ３１１は、変更者ＧＢＬを用いて非表示データを判断することにより、本システムに含まれるゲーム装置１０の全てのユーザの総意による判断に基づいて非表示データを設定できる。
【０２４４】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、変更者ＧＢＬデータを構成するそれぞれの変更者特定ＧＢＬデータに含まれるアプリＩＤと変更者ＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７２０でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中に、データＧＢＬデータを構成するそれぞれのデータ特定ＧＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在するか否かを判断する（ステップ７３０）。
【０２４５】
ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、データＧＢＬデータを構成するそれぞれのデータ特定ＧＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在すると判断した場合（ステップ７３０でＹｅｓ）当該ユーザ作成データＵｄを非表示データに設定する（ステップ７３５）。
【０２４６】
これにより、ＣＰＵ３１１は、キャラクタが道徳上の観点から好ましくないキャラクタであることをデータＧＢＬに基づいて判断できる。そして、ＣＰＵ３１１は、ユーザ作成データＵｄによって示されるキャラクタに基づいて当該キャラクタを表示しないように設定できる。また、データＧＢＬはサーバ５によって管理されるＧＢＬである。そして、後述するように、サーバ５は本システムに含まれる全てのゲーム装置１０のユーザそれぞれからの通報回数に基づいてデータＧＢＬを管理する。サーバ５が通報を受けるのは、上述したようにユーザが道徳上の観点から好ましくないと判断しさらに通報する選択をしたときである。従って、ＣＰＵ３１１は、データＧＢＬを用いて非表示データを判断することにより、本システムに含まれるゲーム装置１０の全てのユーザの総意に基づいて非表示データを設定できる。
【０２４７】
一方、ＣＰＵ３１１は、フィルタリング対象となっているユーザ作成データＵｄの中に、データＧＢＬデータを構成するそれぞれのデータ特定ＧＢＬデータに含まれるアプリＩＤとデータＩＤとが一致するユーザ作成データＵｄが存在しないと判断した場合（ステップ７３０でＮｏ）または非表示データを設定した場合、フィルタリング対象となっているユーザ作成データＵｄの中に、アプリＩＤがＮｕｌｌとなっている変更者特定ＧＢＬデータの変更者ＩＤと一致する変更者ＩＤのユーザ作成データＵｄが含まれているか否かを判断する（ステップ７４０）。
【０２４８】
ＣＰＵ３１１は、アプリＩＤがＮｕｌｌとなっている変更者特定ＧＢＬデータのユーザＩＤと一致する変更者ＩＤのユーザ作成データＵｄが含まれていると判断したとき（ステップ７４０でＹｅｓ）、当該ユーザ作成データＵｄを非表示データに設定する（ステップ７４５）。ＣＰＵ３１１は、アプリＩＤがＮｕｌｌとなっている変更者特定ＧＢＬデータの変更者ＩＤと一致する変更者ＩＤのユーザ作成データＵｄが含まれてないと判断した場合（ステップ７４０でＮｏ）または非表示データを設定した場合、フィルタリング処理を終了する。
【０２４９】
以上が、本実施例におけるフィルタリング処理の説明である。
【０２５０】
［ＧＢＬ更新処理］
次に、図８Ｊを参照して、本実施例におけるＧＢＬ更新処理を説明する。図８Ｊにおいて、ＣＰＵ３１１は、受信ボックスデータＪｂの中に新たに受信した受信ＧＢＬデータＪｇｄ（新着ＧＢＬ）が格納されているか否かを判断する（ステップ８０１）。ＣＰＵ３１１は、新たな受信ＧＢＬデータＪｇｄが格納されていると判断した場合（ステップ８０１でＹｅｓ）、当該受信ＧＢＬデータＪｇｄで示されるＧＢＬが新しいバージョンのＧＢＬであるか否かを判断する（ステップ８０５）。具体的には、ＣＰＵ３１１は、受信ＧＢＬデータＪｇｄで示されるＧＢＬのバージョンと、メインメモリ３２に既に格納しているＧＢＬデータＧｄで示されるＧＢＬのバージョンとを比較する。
【０２５１】
ＣＰＵ３１１は、受信ＧＢＬデータＪｇｄで示されるＧＢＬが新しいバージョンのＧＢＬであると判断した場合（ステップ８０５でＹｅｓ）、当該受信ＧＢＬデータＪｇｄで示されるＧＢＬでメインメモリ３２に格納されているＧＢＬデータＧｄを更新する（ステップ８１０）。そして、ＣＰＵ３１１は、更新したＧＢＬデータＧｄを送信ＧＢＬデータＳｇｄとして送信ボックスデータＳｄに格納する（ステップ８１５）。これにより、すれ違い通信によって受信した最新のＧＢＬをすれ違い通信によってさらに他のゲーム装置１０へ送ることができる。次に、ＣＰＵ３１１は、送信ＧＢＬデータＳｇｄを格納すると、受信ボックスデータＪｂに格納されている受信ＧＢＬデータＪｇｄを削除する（ステップ８２０）。
【０２５２】
一方、ＣＰＵ３１１は、新たな受信ＧＢＬデータＪｇｄが格納されていない場合（ステップ８０１でＮｏ）、受信ＧＢＬデータＪｇｄで示されるＧＢＬが新しいバージョンでない場合（ステップ８０５でＮｏ）、または受信ＧＢＬデータＳｇｄを削除したとき、インターネット通信処理でＧＢＬを受信したか否かを判断する（ステップ８２５）。具体的には、ＣＰＵ３１１は、メインメモリ３２にネット受信ＧＢＬデータＮｇｄが格納されているか否かを判断する。
【０２５３】
ＣＰＵ３１１は、インターネット通信処理でＧＢＬを受信したと判断した場合（ステップ８２５でＹｅｓ）、受信したネット受信ＧＢＬデータＮｇｄで示されるＧＢＬが新しいバージョンであるか否かを判断する（ステップ８３０）。具体的には、ＣＰＵ３１１は、メインメモリ３２に格納されているネット受信ＧＢＬデータＮｇｄで示されるＧＢＬのバージョンと、メインメモリ３２に既に格納されていたＧＢＬデータＧｄで示されるＧＢＬのバージョンとを比較する。
【０２５４】
ＣＰＵ３１１は、ネット受信ＧＢＬデータＮｇｄで示されるＧＢＬが新しいバージョンであると判断したとき（ステップ８３０でＹｅｓ）、当該ＧＢＬを示すようにメインメモリ３２に格納されているＧＢＬデータＧｄを更新する（ステップ８３５）。そして、ＣＰＵ３１１は、更新したＧＢＬデータＧｄを送信ＧＢＬデータＳｇｄとして送信ボックスデータＳｄに格納する（ステップ８４０）。これにより、インターネット通信処理で受信した最新のＧＢＬをすれ違い通信によって他のゲーム装置１０へ送ることができる。ＣＰＵ３１１は、ＧＢＬを更新すると、ネット受信ＧＢＬデータＮｇｄを削除する（ステップ８４５）。
【０２５５】
一方、ＣＰＵ３１１は、インターネット通信処理でＧＢＬを受信していないと判断した場合（ステップ８２５でＮｏ）、ネット受信ＧＢＬデータＮｇｄで示されるＧＢＬが新しいバージョンでないと判断した場合（ステップ８３０でＮｏ）、またはネット受信ＧＢＬデータＮｇｄを削除したとき、ＧＢＬ更新処理をはじめから繰り返す。
【０２５６】
以上が、本実施例におけるＧＢＬ更新処理の説明である。上述で説明したように、ＣＰＵ３１１は、他の処理を実行しているか否かに関わらず、ＧＢＬ更新処理を繰り返し実行する。これにより、ＣＰＵ３１１は、すれ違い通信処理で受信ＧＢＬデータＪｇｄを格納したときまたはインターネット通信処理でネット受信ＧＢＬデータＮｇｄを格納したときに、新しいバージョンのＧＢＬを示すか否かを常に確認できる。そして、ＣＰＵ３１１は、新しいバージョンのＧＢＬを示すデータを受信したときには、即座にＧＢＬデータＧｄを更新して、常に最新のバージョンのＧＢＬを記憶しておくことができる。また、ＣＰＵ３１１は、すれ違い通信で受信した受信ＧＢＬデータＪｇｄによって示されるＧＢＬや、インターネット通信で受信したネット受信ＧＢＬデータＮｇｄが新しいバージョンである場合には、当該受信ＧＢＬデータＪｇｄを送信ＧＢＬデータＳｇｄとして格納する。従って、ＣＰＵ３１１は、新しいバージョンのＧＢＬを即座にすれ違い通信で他のゲーム装置１０に自動的に送信できる。
【０２５７】
［サーバ処理］
次に、図９を参照して、サーバ５で実行されるプログラムによる具体的な処理について説明する。なお、図９は、サーバ処理プログラムを実行することによってサーバ５がサーバ処理を行う一例を示すフローチャートである。なお、この処理を実行するためのプログラムは、ＨＤＤ５４に格納されており、サーバ５の電源がオンになったときに、通信バス５６を介してＨＤＤ５４からメインメモリ５５に読み出されて、ＣＰＵ５１によって実行される。
【０２５８】
図９において、ＣＰＵ５１は、ユーザによって通報されたユーザ作成データＵｄを受信したか否かを判断する（ステップ９０１）。ＣＰＵ５１は、通報されたユーザ作成データＵｄを受信したと判断した場合（ステップ９０１でＹｅｓ）、受信したユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとからなるデータカウントデータがＨＤＤ５４に既に格納されているか否かを判断する（ステップ９０３）。ＣＰＵ５１は、データカウントデータが格納されていないと判断したとき（ステップ９０３でＮｏ）、受信したユーザ作成データＵｄに含まれるデータＩＤとアプリＩＤとからなるデータカウントデータを新規に作成してメインメモリ５５に格納する（ステップ９０４）。このとき作成されるデータカウントデータに含まれる通報回数の初期値は１となる。
【０２５９】
一方、ＣＰＵ５１は、データカウントデータが格納されていると判断したとき（ステップ９０３でＹｅｓ）、当該データカウントデータの通報回数を１だけ加算してカウントする（ステップ９０５）。
【０２６０】
次に、ＣＰＵ５１は、メインメモリ５５に格納されている全てのデータカウントデータの中に通報回数が第１の閾値ｔｈ１以上であるデータカウントデータが存在するか否かを判断する（ステップ９１０）。これにより、ＣＰＵ５１は、本システムに含まれる全てのユーザそれぞれからの通報回数に基づいて、通報されたユーザ作成データＵｄによって示されるキャラクタが道徳上の観点から好ましくないキャラクタであるか否かを判断できる。なお、今回新規作成又はカウントを行ったデータカウントデータについてのみ、ステップ９１０の判断を行うようにしてもよい。
【０２６１】
ＣＰＵ５１は、通報回数が第１の閾値ｔｈ１以上であるデータカウントデータが存在すると判断した場合（ステップ９１０でＹｅｓ）、データ特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加する（ステップ９１５）。このとき、配信用ＧＢＬデータＧｓｄに追加されるのは、通報回数が第１の閾値ｔｈ１以上となるデータカウントデータのそれぞれに含まれるデータＩＤとアプリＩＤとをそれぞれ含むデータ特定ＧＢＬデータである。これにより、ＣＰＵ５１は、ユーザ作成データＵｄの中から道徳上の観点から好ましくないキャラクタを示すデータを特定するためのデータ特定用ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加することができる。
【０２６２】
次に、ＣＰＵ５１は、ユーザによって通報されたユーザ作成データＵｄに含まれるユーザＩＤとアプリＩＤとからなるユーザカウントデータがＨＤＤ５４に格納されているか否かを判断する（ステップ９１７）。ＣＰＵ５１は、ユーザカウントデータが格納されていないと判断したとき（ステップ９１７でＮｏ）、受信したユーザ作成データＵｄに含まれる変更者ＩＤとアプリＩＤとからなるユーザカウントデータを新規に作成してＨＤＤ５４に格納する（ステップ９１９）。このとき作成されるユーザカウントデータに含まれる通報回数の初期値は１となる。
【０２６３】
一方、ＣＰＵ５１は、ユーザカウントデータが格納されていると判断したとき（ステップ９１７でＹｅｓ）、当該データカウントデータの通報回数を１だけ加算してカウントする（ステップ９２０）。
【０２６４】
次に、ＣＰＵ５１は、メインメモリ５５に格納されている全てのユーザカウントデータの中に通報回数が第２の閾値ｔｈ２以上のユーザカウントデータが存在するか否かを判断する（ステップ９２５）。これにより、ＣＰＵ５１は、本システムに含まれる全てのユーザそれぞれからの通報回数に基づいて、通報されたユーザ作成データＵｄの最後の変更者が道徳上の観点から好ましくないキャラクタを作成するユーザであるか否かを判断できる。なお、今回新規作成又はカウントを行ったデータカウントデータについてのみ、ステップ９２５の判断を行うようにしてもよい。
【０２６５】
ＣＰＵ５１は、通報回数が第２の閾値ｔｈ２以上のユーザカウントデータが存在すると判断した場合（ステップ９２５でＹｅｓ）、ユーザ特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加する（ステップ９３０）。このとき、配信用ＧＢＬデータＧｓｄに追加されるのは、通報回数が第２の閾値ｔｈ２以上となるユーザカウントデータのそれぞれに含まれる変更者ＩＤとアプリＩＤとをそれぞれ含むユーザ特定ＧＢＬデータである。これにより、ＣＰＵ５１は、ユーザ作成データＵｄの中から最後の変更者を道徳上の観点から好ましくないキャラクタを作成するユーザとして示すデータを特定するための変更者特定用ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加することができる。
【０２６６】
ＣＰＵ５１は、ユーザ特定ＧＢＬデータを追加する（ステップ９３０）または第２の閾値ｔｈ２以上のユーザカウントデータがないと判断した場合（ステップ９２５でＮｏ）、サーバ処理をはじめから繰り返す。
【０２６７】
なお、図９のフローチャートには図示していないが、ＣＰＵ５１は、配信用ＧＢＬデータＧｓｄを本システムに含まれるゲーム装置１０のそれぞれに送信する処理を並行して行っているものとする。当該処理は、本システムに含まれるゲーム装置１０のそれぞれによって配信用ＧＢＬデータＧｓｄを受信するタスクが実行されたことに応じて実行されるものとする。
【０２６８】
次に、上述で説明したサーバ処理において用いられる第１の閾値ｔｈ１および第２の閾値ｔｈ２について説明する。第２の閾値ｔｈ２は、第１の閾値ｔｈ１よりも大きくなるように予め定められるものとする。上述の説明から明らかなように、ＣＰＵ５１は、ユーザ作成データＵｄが通報される度に、当該ユーザ作成データＵｄに対応するユーザカウントデータの通報回数と、当該ユーザ作成データＵｄに対応するデータカウントデータの通報回数とがそれぞれ加算される。
【０２６９】
そして、データＩＤとアプリＩＤとを含むデータカウントデータで示される通報回数は最も低い第１の閾値ｔｈ１と比較され、変更者ＩＤとアプリＩＤとを含むユーザカウントデータで示される通報回数は第１の閾値ｔｈ１よりも大きい第２の閾値ｔｈ２と比較される。
【０２７０】
ここで、本システムにおいて、同一のデータＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報と同一の変更者ＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報とがそれぞれ繰り返された場合を想定する。この場合、本システムでは、まず始めに、データカウントデータで示される通報回数が第１の閾値ｔｈ１以上となる。そして、ユーザ作成データＵｄで示されるキャラクタに基づいてゲーム装置１０が非表示データを設定できるように、データ特定ＧＢＬデータが先に配信用ＧＢＬデータＧｓｄに追加される。
【０２７１】
そして、さらに、同一のデータＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報と同一の変更者ＩＤとアプリＩＤとを含むユーザ作成データＵｄの通報とがそれぞれ続けて繰り返された場合を想定する。この場合、本システムでは、データカウントデータの通報回数が第１の閾値ｔｈ１以上となった後に、ユーザカウントデータの通報回数が第２の閾値ｔｈ２以上となる。従って、本システムでは、ユーザ作成データＵｄで示されるキャラクタに基づいてゲーム装置１０によって非表示データが設定されるようになった後、ユーザ作成データＵｄで示される最後の変更者ＩＤに基づいて非表示データを設定できるように、変更者特定ＧＢＬデータが配信用ＧＢＬデータＧｓｄに追加される。
【０２７２】
ユーザ特定ＧＢＬデータの変更者ＩＤで示されるユーザは、当該ユーザ特定ＧＢＬデータに含まれるアプリＩＤで示されるキャラクタ取り扱いアプリケーションで取り扱われるユーザ作成データＵｄを送受信しても他のゲーム装置１０にはキャラクタが表示されなくなる。従って、ユーザ作成データＵｄの最後の変更者ＩＤがアプリＩＤと共に変更者特定ＧＢＬデータとして追加されると当該変更者ＩＤのユーザは当該アプリＩＤで示されるアプリケーションによって提供される楽しみを奪われてしまう。このような状況は、アプリケーションの製造元としてもなるべく避けたいので、上述で説明したサーバ処理では、通報回数が第１の閾値ｔｈ１よりも大きい第２の閾値ｔｈ２以上となったときにユーザ作成データＵｄで示される最後の変更者ＩＤが当該ユーザ作成データＵｄのアプリＩＤと共に変更者特定ＧＢＬデータとして登録される。
【０２７３】
以上が、本実施例におけるサーバ処理の説明である。上述したサーバ処理によれば、ＣＰＵ５１は、本システムに含まれるゲーム装置１０のそれぞれからの通報に基づいて、配信用ＧＢＬデータＧｓｄで示される情報を最新の情報に常に更新できる。
【０２７４】
以上が、本システムの説明である。本システムによれば、当該システムに含まれるそれぞれのゲーム装置１０において互いに送受信されるユーザ作成データＵｄで示されるキャラクタの中から道徳上の観点から好ましくないキャラクタが出力されてユーザに表示されることを防げる。例えば、上述したキャラクタ取り扱い画面において上側ＬＣＤ２２に道徳上の観点から好ましくないキャラクタが表示されるのを防げる。また、例えば、上述したキャラクタ編集画面において上側ＬＣＤ２２に１つだけ表示されるキャラクタとして道徳上の観点から好ましくないキャラクタが表示されるのを防げる。
【０２７５】
なお、上述の説明では、ユーザ作成データＵｄを取り扱うアプリケーションとして、キャラクタ取り扱いアプリケーションを一例に挙げて説明した。本システムにおけるアプリケーションの他の一例としては、ユーザが自由に楽曲を作成することができる楽曲作成プログラムが挙げられる。この場合、ユーザによって作成された楽曲を示すデータがユーザ作成データＵｄとなる。また、この場合、ユーザ作成データＵｄに含まれるアプリＩＤは、楽曲作成アプリケーションを示すアプリＩＤとなる。また、この場合、ユーザ作成データＵｄに含まれるデータ本文は楽曲の内容を示すデータ本文となる。また、本システムにおけるアプリケーションの他の一例としては、マイク４３を用いて入力した音声などを用いて作成したユーザ作成データＵｄを取り扱うアプリケーションも挙げられる。
【０２７６】
つまり、本システムでは、キャラクタなどの表示オブジェクト、楽曲および音声などの任意のアプリケーションを用いて作成される任意の内容（コンテンツ）を示すユーザ作成データＵｄを対象とすることができる。これにより、本システムでは、表示オブジェクトなど表示装置に表示出力されることによってユーザに提供されるコンテンツ、楽曲および音声などスピーカ４４を用いて音声出力されることによってユーザに提供されるコンテンツなどの中からユーザにとって不適切なコンテンツを提供すべきでないコンテンツとしてＧＢＬおよびＬＢＬの少なくとも一方を用いて特定できる。
【０２７７】
その他、ユーザ作成データＵｄの例としては、タッチパネル１３への入力により手書きでなされたメッセージや、タッチパネル１３、操作ボタン１４又はキーボードなどの周辺機器により入力された、任意の文字列データなどを挙げることができる。また、アプリケーションプログラムのセキュリティホール等を狙って、アプリケーションプログラムの動作を停止させたり、アプリケーションプログラムの異常動作を引き起こしたりするようなユーザ作成データＵｄを対象とすることで、アプリケーションプログラムの停止や異常動作を未然に防ぐことができる。
【０２７８】
また、上述の説明では、作成者ＩＤ、変更者ＩＤ、アプリＩＤおよびデータＩＤなどを、データ本文（コンテンツ）の作成時に関連する情報（以下、作成情報と称する）、または、当該コンテンツに関連する情報（以下、コンテンツ情報と称する）として当該コンテンツを含むユーザ作成データＵｄに付与する場合を一例として説明した。そして、ＧＢＬデータＧｄおよびＬＢＬデータＬｄには、作成情報またはコンテンツ情報に含まれる作成者ＩＤ、変更者ＩＤ、アプリＩＤおよびデータＩＤの中から作成者ＩＤと変更者ＩＤとの組み合わせを除く少なくとも２つのＩＤを追加するものとした。この場合、ゲーム装置１０では、上述で説明したように、ＧＢＬデータＧｄまたはＬＢＬデータＬｄに前述の２つのＩＤが含まれていれば、一致するＩＤを含むユーザ作成データＵｄに含まれるコンテンツがユーザに提供すべきでないコンテンツとして特定されることとなる。
【０２７９】
また、上述の説明では、すれ違い通信においてＧＢＬが送信ＧＢＬデータＳｇｄ或いは受信ＧＢＬデータＪｇｄとして送受信して交換される場合を一例として説明した。しかしながら、他の一実施形態では、ＬＢＬもＧＢＬと同様にすれ違い通信で交換してもよい。
【０２８０】
また、上述の説明では、ユーザが通報するときには通報するユーザ作成データＵｄを送信するものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄに付与されている作成者ＩＤ、変更者ＩＤ、アプリＩＤおよびデータＩＤの中から任意の組み合わせのＩＤを送信してもよい。そして、サーバ５のＣＰＵ５１は、送信されたＩＤを用いて上述したデータカウントデータおよびユーザカウントデータもしくは、当該データカウントデータおよび当該ユーザカウントデータにおける組み合わせとは異なる組み合わせのＩＤで通報回数をカウントするためのカウントデータを用いて通報回数をカウントしてもよい。
【０２８１】
また、上述の説明では、ゲーム装置１０は、配信用ＧＢＬデータＧｓｄを受信するためのタスクを定期的に実行して受信する場合を一例として説明した。しかしながら、他の一実施形態では、サーバ５のＣＰＵ５１が、通信可能なゲーム装置１０に定期的に配信用ＧＢＬデータＧｓｄを送信するようにしてもよい。
【０２８２】
また、上述の説明では、上述したコンテンツの一例としてキャラクタが道徳上の観点から好ましくない場合に表示されないように設定する場合を説明した。しかしながら、他の一実施形態では、道徳上の観点から好ましくない不適切でユーザに提供するべきでないコンテンツを提供することのできる所定のコンテンツに置き換えることによって不適切なコンテンツをユーザに提供しないようにしてもよい。さらに、他の一実施形態では、不適切なコンテンツを含むユーザ作成データＵｄを削除するようにしてもよい。
【０２８３】
また、上述の説明では、ＧＢＬのバージョンを比較するために、配信用ＧＢＬデータＧｓｄをネット受信ＧＢＬデータＮｇｄとしてメインメモリ３２に格納した後、新しいバージョンであるときにＧＢＬデータＧｄを更新するものとした。しかしながら、他の一実施形態では、配信用ＧＢＬデータＧｓｄでメインメモリ３２に格納されているＧＢＬデータＧｄを直接更新してもよい。これにより、配信用ＧＢＬデータＧｓｄが常に最新のバージョンのＧＢＬを示すデータとしてメインメモリ３２に格納されているＧＢＬデータＧｄを更新できる。
【０２８４】
また、上述の説明では、すれ違い通信およびローカル通信が、同じローカル通信モジュール３７を用いて行われるものとした。ここで、すれ違い通信処理による通信とローカル通信処理による通信とが同時に発生する場合には、互いの処理を時分割で行う、或いは互いの処理で送受信するデータを時分割するなどの手法を用いることにより、両方の通信の両立が可能である。
【０２８５】
また、上述の説明では、ユーザ作成データＵｄに含まれるデータＩＤがデータ本文をアプリケーション毎に一意に識別するためのＩＤであるものとした。しかしながら、他の一実施形態では、データＩＤは、アプリケーションに関わらずデータ本文を一意に識別するためのＩＤとしてもかまわない。この場合、データ特定ＬＢＬデータおよびデータ特定ＧＢＬデータには、当該データＩＤのみを含むようにする。これにより、フィルタリング処理において、フィルタリング対象のユーザ作成データＵｄに含まれるデータＩＤのみをデータ特定ＬＢＬデータおよびデータ特定ＧＢＬデータとそれぞれ比較して非表示データを特定することができる。
【０２８６】
また、上述の説明では、配信用ＧＢＬデータＧｓｄ、ユーザ特定用カウントデータＵｃｄおよびデータ特定用カウントデータＤｃｄがサーバ５のメインメモリ５５に格納されるものとした。しかしながら、他の一実施形態では、配信用ＧＢＬデータＧｓｄ、ユーザ特定用カウントデータＵｃｄおよびデータ特定用カウントデータＤｃｄの少なくともいずれか１つをサーバ５のＨＤＤ５４に格納するようにしてもよい。
【０２８７】
また、上述の説明では、ＧＢＬデータＧｄに含まれるアプリＩＤおよび配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄに含まれるアプリＩＤは、例外的なアプリＩＤであるものとした。しかしながら、他の一実施形態では、ＧＢＬデータＧｄおよび配信用ＧＢＬデータＧｓｄを受信するためのタスクデータＴｄに含まれるアプリＩＤは、例外的なアプリＩＤでなくてもよい。具体的には、ＧＢＬデータＧｄを取り扱うアプリケーションを仮想した場合のアプリＩＤであってもよいし、上述したサーバ処理プログラムをアプリケーションプログラムと見なした場合の当該アプリケーションプログラムに付与されているアプリＩＤであってもよい。
【０２８８】
また、上述の説明では、ユーザ作成データＵｄの最後の変更者ＩＤとアプリＩＤとを含むデータを変更者特定ＧＢＬデータとして追加するものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄの作成者ＩＤとアプリＩＤとを含むデータを変更者特定ＧＢＬデータと同様に追加して用いてもよい。この場合、ゲーム装置１０はユーザ作成データＵｄに含まれる作成者ＩＤとアプリＩＤとの両方が変更者特定ＧＢＬデータに含まれる作成者ＩＤとアプリＩＤとの両方と一致したときに当該ユーザ作成データＵｄを非表示データに設定すればよい。また、この場合、ユーザがユーザ作成データＵｄを通報することによって、当該ユーザ作成データＵｄに含まれる作成者ＩＤのユーザが道徳上の観点から好ましくないキャラクタを作成したユーザとして通報される。
【０２８９】
また、上述の説明では、変更者ＩＤとアプリＩＤとからなるユーザカウントデータおよびデータＩＤとアプリＩＤとからなるデータカウントデータに基づいて変更者特定ＧＢＬデータおよびデータ特定ＧＢＬデータをそれぞれ配信用ＧＢＬデータＧｓｄに追加するものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄの最後の変更者ＩＤ毎に、通報されたユーザ作成データＵｄの数を通報回数としてさらにカウントしてもよい。そして、カウントした通報回数が所定の第３の閾値ｔｈ３以上となったときに当該変更者ＩＤと全てのアプリケーションを示すアプリＩＤとを含む変更者特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加するようにしてもよい。これにより、複数のアプリケーションを用いて、道徳上の観点から好ましくないユーザ作成データＵｄを作成するユーザを特定するための変更者特定ＧＢＬデータを配信用ＧＢＬデータＧｓｄに追加することができる。なお、全てのアプリケーションを示すアプリＩＤとは、ゲーム装置１０で実行し得る全てのアプリケーションを示すアプリＩＤとして予め定められたＩＤであればどのようなＩＤであってもよい。一例としては、Ｎｕｌｌで示されるアプリＩＤが挙げられる。この場合、ゲーム装置１０は、受信したユーザ作成データＵｄの最後の変更者ＩＤのみが変更者特定ＧＢＬデータに含まれる変更者ＩＤと一致すれば、アプリＩＤに関わらず当該ユーザ作成データＵｄを非表示データとして設定できる。すなわち、変更者特定ＧＢＬデータに含まれる変更者ＩＤのユーザは、ユーザ作成データＵｄを作成するためにどのようなアプリケーションを用いたとしても、送信したユーザ作成データＵｄで示されるデータが他のゲーム装置１０に表示されることはない。従って、この場合に追加される変更者特定ＧＢＬデータの変更者ＩＤで示されるユーザは、本システムにおいて、データを他のゲーム装置１０に一切送信できなくなる。このように、広範囲の制限を与えてしまうので、第３の閾値ｔｈ３は、第１の閾値ｔｈ１や第２の閾値ｔｈ２よりも高い値となることが望ましい。
【０２９０】
また、上述の説明では、ユーザ作成データＵｄには、作成者ＩＤおよび１以上の追加された変更者ＩＤが含まれる場合を一例として説明した。しかしながら、他の一実施形態では、作成者ＩＤを保持せず、また、変更者ＩＤも複数保持せずに最後の変更者ＩＤのみを含むユーザ作成データＵｄを用いてもよい。この場合、ユーザ作成データＵｄを新規に作成したときには最後の変更者ＩＤに作成者のＩＤが記録され、ユーザ作成データＵｄが変更される度に、変更したユーザを示すＩＤが最後の変更者ＩＤとして上書きされることとなる。
【０２９１】
さらに、他の一実施形態では、作成者ＩＤと変更者ＩＤとを１つずつ含むユーザ作成データＵｄを用いてもよい。この場合、ユーザ作成データＵｄが変更される度に変更したユーザを示すＩＤが変更者ＩＤとして上書きされる。また、この場合、ユーザ作成データＵｄに含まれる変更者ＩＤが最後の変更者を示すＩＤとなるので、このようなユーザ作成データＵｄは、そのまま上述で説明した実施形態で用いることが可能である。
【０２９２】
また、上述の説明では、ユーザ作成データＵｄで示されるキャラクタをＬＢＬに登録するときにユーザは変更者ＬＢＬまたはデータＬＢＬの中から登録するＬＢＬを選択できるものとした。しかしながら、他の一実施形態では、ユーザによってキャラクタのＬＢＬへの登録が選択されたときには、当該キャラクタを変更者ＬＢＬとデータＬＢＬとの両方に登録するようにしてもよい。
【０２９３】
また、上述の説明では、ユーザ作成データＵｄの最後の変更者ＩＤを変更者特定ＧＢＬデータに含ませるものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄに含まれる作成者ＩＤおよび変更者ＩＤの中から変更者特定ＧＢＬデータに変更者ＩＤとして含ませるＩＤを選択できるようにしてもよい。
【０２９４】
また、上述の説明では、第１の閾値ｔｈ１が第２の閾値ｔｈ２以下であるものとして説明した。しかしながら、他の一実施形態では、必ずしも第１の閾値ｔｈ１が第２の閾値ｔｈ２以下でなくてもよい。ただし、上述したように第１の閾値ｔｈ１が第２の閾値ｔｈ２以下としたのは、ユーザ作成データＵｄの最後の変更者ＩＤがアプリＩＤと共に変更者特定ＧＢＬデータとして追加された場合に、当該変更者ＩＤのユーザは当該アプリＩＤで示されるアプリケーションによって提供される楽しみを奪われてしまう状況を避けるためである。従って、第１の閾値ｔｈ１が第２の閾値ｔｈ２以下でなくなるようにそれぞれの閾値を予め定める場合には、前述の状況を避けなくてもよい場合に限る。
【０２９５】
また、他の一実施形態では、ゲーム装置１０が「通常電力モード」と「省電力モード」の２つの電源制御モードのいずれかで動作するようにしてもよい。「通常電力モード」は、ゲーム装置１０の構成部品の全てに電力を供給している状態である。例えば、ユーザが所定のゲームを実際に操作してプレイする場合や、各種アプリケーションを実際に操作する場合の電源制御モードは「通常電力モード」である。「省電力モード」は、上記構成部品の一部に対してのみ電力の供給を継続し、それ以外の構成部品に対しての電力供給は停止している状態である。また、この「省電力モード」の一つとして、「スリープモード」がある。「スリープモード」は、無線通信モジュール３６およびローカル通信モジュール３７にのみ電源を供給し、それ以外の部品、つまり、ＬＣＤなどへの電力供給は停止している状態である。上述の説明では、ゲーム装置１０をオンにした後は、すれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理を互いに並行して繰り返して行うものとした。このことは、ゲーム装置１０が上記「通常電力モード」と「省電力モード」の２つの電源制御モードのいずれかで動作する場合も同様にしてよい。すなわち、ゲーム装置１０は、「スリープモード」で動作している場合でもすれ違い通信処理、インターネット通信処理およびＧＢＬ更新処理を互いに並行して繰り返して行ってもよい。
【０２９６】
また、上述の説明では、ユーザに提供すべきでないコンテンツを含むユーザ作成データＵｄを特定するためにアプリＩＤおよびデータＩＤなどを用いるものとした。しかしながら、他の一実施形態では、ユーザ作成データＵｄ毎に計算したハッシュ値を用いてユーザに提供すべきでないコンテンツを含むユーザ作成データＵｄを特定してもよい。また、他の一実施形態では、ユーザ作成データＵｄに含まれるデータ本文（コンテンツ）そのものをＧＢＬまたはＬＢＬに登録して用いてもよい。
【０２９７】
また、上述の説明では、ゲーム装置１０が複数のアプリケーションを選択的に実行できることを説明した。しかしながら、仮に、ゲーム装置１０が１つのアプリケーションしか実行できないのであれば、ユーザに提供すべきでないコンテンツを含むユーザ作成データＵｄを特定するのに、アプリＩＤを用いなくてもよいことは言うまでもない。
【０２９８】
また、上述の説明では、ＣＰＵ３１１が、ＧＢＬデータＧｄを更新するときには新しいＧＢＬのＧＢＬデータＧｄを既に格納されているＧＢＬデータＧｄに上書きして更新するものとして説明した。しかしながら、他の一実施形態では、新しいＧＢＬデータＧｄの一部（例えば、既に格納されているＧＢＬデータＧｄとの差分）を追加或いは全部を上書きすることによって、既に格納されているＧＢＬデータＧｄを更新してもよい。
【０２９９】
また、上述の説明では、サーバ５のＣＰＵ５１が上述したサーバ処理を行うことによりユーザからの通報回数を自動的に集計してＧＢＬに提供するべきでないコンテンツを含むユーザ作成データＵｄを特定するためのデータを登録するものとした。しかしながら、他の一実施形態では、提供するべきでないコンテンツを含むユーザ作成データＵｄを特定するためのデータの登録を、例えば、サーバ５の使用者などによる手動で行うようにしてもよい。より詳細には、例えば、サーバ５において、ユーザ作成データＵｄの通報回数が所定の閾値以上となったときに当該ユーザ作成データＵｄが道徳上の観点から好ましくないコンテンツを示すデータであるとしてサーバ５の使用者に通知をするように構成してもよい。これにより、サーバ５の使用者は通知を受けたときに通知されたデータのコンテンツを目視してＧＢＬに登録するべきか否かを判断してから必要に応じて登録することができる。
【０３００】
また、上述の説明では、サーバ５から受信した配信用ＧＢＬデータＧｓｄで示されるＧＢＬのバージョンが新しい場合に、メインメモリ３２に格納されているＧＢＬデータＧｄを更新するものとした。しかしながら、他の一実施形態では、配信用ＧＢＬデータＧｓｄで示されるＧＢＬの更新日時が新しい場合に、メインメモリ３２に格納されているＧＢＬデータＧｄを更新するようにしてもよい。
【０３０１】
また、上述の説明では、ユーザが道徳上の観点から好ましくないコンテンツを示すユーザ作成データＵｄを通報するときには、当該ユーザ作成データＵｄがそのままサーバ５に送信されるものとした。しかしながら、他の一実施形態では、ユーザがユーザ作成データＵｄを通報するときに、通報するユーザ作成データＵｄに含まれるユーザＩＤとデータＩＤとの組み合わせをサーバ５に送信して通報するようにしてもよい。そして、サーバ５は、ユーザＩＤとデータＩＤとの組み合わせの送信回数が上述した第１の閾値以上となったときに当該組み合わせにおけるデータＩＤを配信用ＧＢＬデータＧｓｄのデータ特定ＧＢＬデータとしてデータＧＢＬデータに追加して更新するようにしてもよい。さらに、この場合、サーバ５は、ユーザＩＤとデータＩＤとの組み合わせの送信回数が上述した第２の閾値以上となったときに当該組み合わせにおけるユーザＩＤを配信用ＧＢＬデータＧｓｄの変更者特定ＧＢＬデータとして変更者ＧＢＬデータに追加して更新するようにしてもよい。
【０３０２】
また、上述の説明では、ユーザが道徳上の観点から好ましくないコンテンツを示すユーザ作成データＵｄを通報するときには、当該ユーザ作成データＵｄがそのままサーバ５に送信されるものとした。しかしながら、他の一実施形態では、ユーザがユーザ作成データＵｄを通報するときに、通報するユーザ作成データＵｄに含まれるユーザＩＤとアプリＩＤとの組み合わせをサーバ５に送信して通報するようにしてもよい。そして、サーバ５は、ユーザＩＤとアプリＩＤとの組み合わせの送信回数が上述した第２の閾値以上となったときに当該組み合わせのユーザＩＤとアプリＩＤとを配信用ＧＢＬデータＧｓｄの変更者特定ＧＢＬデータとして変更者ＧＢＬデータに追加して更新するようにしてもよい。さらに、この場合、サーバ５は、ユーザＩＤとアプリＩＤとの組み合わせの送信回数が上述した第３の閾値以上となったときに、当該組み合わせにおけるユーザＩＤと上述した全てのアプリケーションを示すアプリＩＤとの組み合わせを、配信用ＧＢＬデータＧｓｄの変更者特定ＧＢＬデータとして変更者ＧＢＬデータに追加して更新するようにしてもよい。
【０３０３】
また、上述の説明では、ローカル通信モジュール３７を用いてすれ違い通信を行うものとした。しかしながら、他の一実施形態では、無線通信モジュール３６を用いてＡＰ２との間ですれ違い通信をしてもよい。これにより、インターネット通信網３を介したすれ違い通信を行うことができる。また、赤外線通信などの通信方式を用いてもよい。
【０３０４】
また、上述の説明では、ＧＢＬデータＧｄ或いはＬＢＬデータＬｄに登録されるデータはユーザ作成データＵｄによって示されるコンテンツを特定するための情報（ユーザＩＤ、データＩＤなど）であるものとして説明した。しかしながら、他の一実施形態では、ゲーム装置１０などの情報処理装置を対象として作成されたウイルスプログラムを特定するための情報をＧＢＬデータＧｄ或いはＬＢＬデータＬｄに登録するようにしてもよい。この場合、ウイルスプログラムを特定したデータをすれ違い通信等で伝播させることができるので、上述で説明したような道徳上の観点から好ましくないコンテンツと同様にウイルスプログラムの蔓延を未然に防止できる。
【０３０５】
また、上述の説明では、ユーザ作成データＵｄを特定するための情報に基づいてユーザに出力するか否かを決定する場合について説明した。しかしながら、他の一実施形態では、ユーザ作成データＵｄの送信元のアドレスに基づいてユーザに出力するか否かを判別してもよい。また、ユーザ作成データＵｄによって示されるコンテンツがメールである場合には、メールの送信元のアドレスに基づいて当該メールをユーザに表示出力するか否か判別してもよい。この場合、ＧＢＬデータＧｄ或いはＬＢＬデータＬｄには、このような送信元のアドレスが登録され、すれ違い通信等で伝播されることになる。
【０３０６】
また、上述の説明では、２画面分の液晶表示部の一例として、物理的に分離された下側ＬＣＤ１２および上側ＬＣＤ２２を互いに上下に配置した場合（上下２画面の場合）を説明した。しかしながら、２画面分の表示画面の構成は、他の構成でもかまわない。例えば、下側ハウジング１１の一方主面に下側ＬＣＤ１２および上側ＬＣＤ２２を左右に配置してもかまわない。また、下側ＬＣＤ１２と横幅が同じで縦の長さが２倍のサイズからなる縦長サイズのＬＣＤ（すなわち、物理的には１つで、表示サイズが縦に２画面分あるＬＣＤ）を下側ハウジング１１の一方主面に配設して、２つの画像を上下に表示（すなわち上下の境界部分無しに隣接して表示）するように構成してもよい。また、下側ＬＣＤ１２と縦幅が同じで横の長さが２倍のサイズからなる横長サイズのＬＣＤを下側ハウジング１１の一方主面に配設して、横方向に２つのゲーム画像を左右に表示（すなわち左右の境界部分無しに隣接して表示）するように構成してもよい。すなわち、物理的に１つの画面を２つに分割して使用することにより２つの画像を表示してもかまわない。いずれの画像の形態に対しても、上述した下側ＬＣＤ１２に表示していた表示画像が表示される画面上にタッチパネル１３を配設すれば、同様に本発明を実現することができる。また、物理的に１つの画面を２つに分割して使用することにより上記２つの画像を表示する場合、当該画面全面にタッチパネル１３を配設してもかまわない。
【０３０７】
また、上述の説明では、ゲーム装置１０にタッチパネル１３が一体的に設けられているが、ゲーム装置とタッチパネルとを別体にして構成しても、本発明を実現できることは言うまでもない。
【０３０８】
また、上述の説明では、座標入力を実現するゲーム装置１０の入力手段としてタッチパネル１３を用いたが、他のポインティングデバイスを用いてもかまわない。ここで、ポインティングデバイスは、画面上での入力位置や座標を指定する入力装置であり、例えば、マウス、トラックパッド、トラックボール等を入力手段として使用し、入力手段から出力される出力値から計算された画面座標系の位置情報を用いれば、本発明を同様に実現することができる。
【０３０９】
また、ゲームコントローラをユーザが把持してゲームを楽しむ据置型のゲーム装置の場合、他の態様のポインティングデバイスも考えられる。例えば、ゲームコントローラのハウジングに固設されたカメラを、上記ポインティングデバイスとして利用することも可能である。この場合、ゲームコントローラのハウジングで指し示した位置の変化に応じてカメラが撮像する撮像画像が変化する。従って、この撮像画像を解析することにより、表示画面に対して上記ハウジングで指し示した座標を算出することができる。なお、本発明においては、ゲーム装置１０にタッチパネル１３等のポインティングデバイス自体が設けられていなくても実現可能であることは言うまでもない。
【０３１０】
また、上記実施例では、携帯型のゲーム装置１０や据置型のゲーム装置を用いて説明したが、一般的なパーソナルコンピュータ等の情報処理装置で本発明の画像通信プログラムを実行して、本発明を実現してもかまわない。
【０３１１】
また、上述したゲーム装置１０の形状や、それに設けられている各種操作ボタン１４やタッチパネル１３の形状、数、および設置位置等は、単なる一例に過ぎず、他の形状、数、および設置位置であっても、本発明を実現できることは言うまでもない。また、上述した画像通信処理で用いられる各ステップの実行順序や画面表示例等は、単なる一例に過ぎず、他の実行順序や画面表示であっても、本発明を実現できることは言うまでもない。
【０３１２】
また、上述した説明では、上記情報処理プログラムの一例としてゲームプログラムが情報処理部３１で実行される例を用いたが、本実施形態に係る情報処理プログラムの少なくとも一部を、当該情報処理部３１と通信可能な他の装置に備えられた少なくともＣＰＵを含む情報処理部で実行してもかまわない。本実施形態に係る情報処理プログラムの一例として上記ゲームプログラムを実行する場合には、例えば、ゲーム装置１０が他の装置（例えば、サーバなど）と通信可能に構成されている場合、上記ゲームプログラムにおける処理は、ゲーム装置１０および当該他の装置が協働することによって実行してもよい。一例として、他の装置において上記ゲームプログラムが実行され、当該ゲームプログラムの実行に必要な操作入力の検出、当該ゲームプログラムの実行に必要な表示を行う表示装置などは、それぞれゲーム装置１０のタッチパネル１３、上側ＬＣＤ２２および／または下側ＬＣＤ１２を用いるように構成したゲームシステムにおいて、上記ゲームプログラムを実行してもよい。このことは、本実施形態に係る情報処理プログラムの他の一例として上述した動作制御プログラムについても同様である。つまり、本実施形態に係る情報処理プログラムは、一例として、他の装置において当該情報処理プログラムが実行され、当該情報処理プログラムの実行に必要な操作入力の検出、当該情報処理プログラムの実行に必要な表示を行う表示装置などは、それぞれゲーム装置１０のタッチパネル１３、上側ＬＣＤ２２および／または下側ＬＣＤ１２を用いるように構成した情報処理システムにおいて実行されてもよい。
【０３１３】
また、上述した説明では、本発明を携帯型のゲーム装置１０に適用した場合について説明したが、本発明は携帯型ゲーム装置に限定されない。例えば、据置型ゲーム装置、携帯電話機、簡易型携帯電話機（ＰＨＳ）、ＰＤＡ等の携帯情報端末にも本発明の適用は可能である。また、据置型ゲーム機やパーソナルコンピュータにも本発明の適用は可能である。
【０３１４】
以上、本発明を詳細に説明してきたが、前述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。また、当業者は、本発明の具体的な実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。また、本明細書において使用される用語は、特に言及しない限り、当該分野で通常用いられる意味で用いられることが理解されるべきである。従って、他に定義されない限り、本明細書中で使用される全ての専門用語および技術用語は、本発明の属する分野の当業者によって一般的に理解されるのと同じ意味を有する。矛盾する場合、本明細書（定義を含めて）が優先する。
【産業上の利用可能性】
【０３１５】
本発明に係る情報処理プログラム、情報処理装置、情報処理システムおよび情報処理方法は、ユーザに提供すべきでないコンテンツを提供しないようにすることが可能であり、データの送受信を行う情報処理プログラム、情報処理装置、情報処理システムおよび情報処理方法等として有用である。
【符号の説明】
【０３１６】
５ サーバ
１０ ゲーム装置
１１ 下側ハウジング
１２ 下側ＬＣＤ
１３ タッチパネル
１４ 操作ボタン
１５ アナログスティック
１６ ＬＥＤ
１７ 挿入口
１８ マイクロフォン用孔
１９ 無線スイッチ
２１ 上側ハウジング
２２ 上側ＬＣＤ
２３ 外側撮像部
２３ａ 外側左撮像部
２３ｂ 外側右撮像部
２４ 内側撮像部
２５ ３Ｄ調整スイッチ
２６ ３Ｄインジケータ
２７ スクリーンカバー
２８ タッチペン
３１ 情報処理部
３１１ ＣＰＵ
３１２ ＧＰＵ
３１３ ＶＲＡＭ
３２ メインメモリ
３３ 外部メモリＩ／Ｆ
３４ データ保存用外部メモリＩ／Ｆ
３５ データ保存用内部メモリ
３６ 無線通信モジュール
３７ ローカル通信モジュール
３８ ＲＴＣ
３９ 加速度センサ
４０ 角速度センサ
４１ 電源回路
４２ Ｉ／Ｆ回路
４３ マイク
４４ スピーカ
４５ 外部メモリ
４６ データ保存用外部メモリ
５１ ＣＰＵ
５２ 操作検出部
５３ 通信部
５４ ＨＤＤ
５５ メインメモリ
【特許請求の範囲】
【請求項１】
コンテンツを含むデータの送受信が可能な複数の情報処理装置を少なくとも含む情報処理システムであって、
各前記情報処理装置は、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信手段と、
前記特定情報受信手段によって受信された前記特定情報を格納する特定情報格納手段と、
前記特定情報格納手段に格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信手段と、
前記データを他の情報処理装置との間で送受信するデータ送受信手段と、
前記データ送受信手段によって受信される前記データの内、前記特定情報格納手段に格納されている前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力手段とを備える、情報処理システム。
【請求項２】
各前記情報処理装置は、通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する無線通信手段をさらに備え、
前記特定情報受信手段は、前記無線通信手段を用いて前記特定情報を自動的に受信し、
前記特定情報格納手段は、前記無線通信手段によって受信された前記特定情報を格納し、
前記特定情報送信手段は、前記特定情報格納手段に格納された前記特定情報を前記無線通信手段を用いて他の情報処理装置に自動的に送信する、請求項１に記載の情報処理システム。
【請求項３】
各前記情報処理装置は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置に無線接続し、当該他の情報処理装置との間で通信する無線通信手段をさらに備え、
前記特定情報受信手段は、前記無線通信手段を用いて前記特定情報を受信し、
前記特定情報格納手段は、前記無線通信手段によって受信された前記特定情報を格納し、
前記特定情報送信手段は、前記特定情報格納手段に格納された前記特定情報を前記無線通信手段を用いて他の情報処理装置に送信する、請求項１に記載の情報処理システム。
【請求項４】
各情報処理装置のそれぞれに対して前記特定情報を送信するサーバ装置をさらに含み、
各前記情報処理装置は、
前記サーバ装置から送信される前記特定情報を受信するサーバ情報受信手段と、
前記サーバ情報受信手段によって受信された前記特定情報で前記特定情報格納手段に格納された前記特定情報を更新する更新手段とをさらに備える、請求項１〜３のいずれか１つに記載の情報処理システム。
【請求項５】
各前記情報処理装置は、
前記データ送受信手段によって受信される前記データの中で出力しないように設定する前記データの選択をユーザから受け付ける受付手段と、
前記受付手段によって受け付けられた前記データまたは当該データに関連する情報の内少なくとも一部を通報データとして前記サーバ装置に送信する送信手段とをさらに備え、
前記サーバ装置は、
各前記情報処理装置の前記送信手段から送信される前記通報データに基づいて、各前記情報処理装置に送信する前記特定情報を更新するサーバ側更新手段と、
前記サーバ側更新手段によって更新される前記特定情報を格納するサーバ側特定情報格納手段とを備える、請求項４に記載の情報処理システム。
【請求項６】
前記サーバ装置は、前記サーバ側特定情報格納手段に格納されている前記特定情報を送信するサーバ情報送信手段をさらに備え、
前記サーバ情報受信手段は、前記サーバ情報送信手段から前記特定情報を定期的に受信する、請求項４または５に記載の情報処理システム。
【請求項７】
前記サーバ側更新手段は、各前記情報処理装置の前記送信手段からそれぞれ送信される前記通報データの送信回数が所定の閾値以上となったとき、前記サーバ側特定情報格納手段に格納されている前記特定情報を更新する、請求項５または６のいずれかに記載の情報処理システム。
【請求項８】
前記データは、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子及び当該データのデータ識別子を含み、
前記送信手段は、少なくとも前記ユーザ識別子および前記データ識別子を前記通報データとして前記サーバ装置に送信し、
前記サーバ側更新手段は、前記送信手段からの送信回数が第１の閾値以上となった前記通報データの前記データ識別子を前記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第１の閾値よりも大きい第２の閾値以上となった前記通報データの前記ユーザ識別子を前記特定情報に追加して更新する、請求項７に記載の情報処理システム。
【請求項９】
前記出力手段は、前記データ送受信手段によって受信される前記データの内、前記データ識別子と前記特定情報に含まれる前記データ識別子が一致する前記データ、および、前記ユーザ識別子と前記特定情報に含まれる前記ユーザ識別子が一致する前記データを出力せず、いずれも一致しない前記データを出力する、請求項８に記載の情報処理システム。
【請求項１０】
前記データは、複数のアプリケーションの内いずれかを用いて作成され、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子および当該データを作成するのに用いられたアプリケーションプログラムを示すアプリ識別子を含み、
前記サーバ側更新手段は、前記送信手段からの送信回数が第２の閾値以上となった前記通報データの前記ユーザ識別子と前記アプリ識別子とを組み合わせて前記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第２の閾値よりも大きい第３の閾値以上となった前記通報データの前記ユーザ識別子と、全てのアプリケーションプログラムを示す前記アプリ識別子とを組み合わせて当該特定情報に追加することで当該特定情報を更新する、請求項７に記載の情報処理システム。
【請求項１１】
前記出力手段は、前記データ送受信手段によって受信される前記データの内、前記アプリ識別子と前記ユーザ識別子との組み合わせが前記特定情報に含まれる前記アプリ識別子と前記ユーザ識別子との組み合わせと一致する前記データを出力せず、一致しない前記データを出力する、請求項１０に記載の情報処理システム。
【請求項１２】
各前記情報処理装置は、
前記データ送受信手段によって受信される前記データの中で出力しないように設定する前記データの選択をユーザから受け付ける受付手段と、
前記受付手段によって受け付けられた前記データ又は当該データに関連する情報の内少なくとも一部を通報データとして前記サーバ装置に送信する送信手段とをさらに備え、
前記サーバ装置は、
各前記情報処理装置の前記送信手段から送信される前記通報データに基づいて、当該通報データを用いて特定される前記データが不適切なデータであることを通知する通知手段と、
前記通知手段による通知を受けた前記サーバ装置の使用者の操作により、各情報処理装置に送信する前記特定情報を更新するサーバ側更新手段と、
前記サーバ側更新手段によって更新される前記特定情報を格納するサーバ側特定情報格納手段とを備える、請求項４に記載の情報処理システム。
【請求項１３】
前記通知手段は、各前記情報処理装置の前記送信手段からの送信回数が所定の閾値以上となった前記通報データを用いて特定される前記データが不適切なデータであることを通知する、請求項１２に記載の情報処理システム。
【請求項１４】
前記更新手段は、前記サーバ情報受信手段によって受信された前記特定情報が、情報処理装置に既に格納されている前記特定情報よりも新しい場合、既に格納されている前記特定情報に、受信された前記特定情報の差分を追加又は全部を上書することで前記特定情報を更新する、請求項４に記載の情報処理システム。
【請求項１５】
前記更新手段は、前記サーバ情報受信手段によって前記特定情報が受信された時点で前記情報処理装置に格納された前記特定情報を更新する、請求項４に記載の情報処理システム。
【請求項１６】
各前記情報処理装置は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する無線通信手段をさらに備え、
前記データ送受信手段は、前記無線通信手段を用いて自動的に前記データを送受信する、請求項１に記載の情報処理システム。
【請求項１７】
前記情報処理装置は、前記データ送受信手段によって現在までに受信された前記データを格納するデータ格納手段をさらに備え、
前記出力手段は、前記データ格納手段に格納された前記データの内、前記特定情報格納手段に格納されている前記特定情報によって特定された前記データを出力しない、請求項１〜４のいずれか１つに記載の情報処理システム。
【請求項１８】
各前記情報処理装置は、携帯可能である、請求項３に記載の情報処理システム。
【請求項１９】
コンテンツを含むデータの送受信が可能な情報処理装置で用いられる情報処理方法であって、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信ステップと、
前記特定情報受信ステップにおいて受信された前記特定情報を格納する特定情報格納ステップと、
前記特定情報格納ステップにおいて格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信ステップと、
前記データを他の情報処理装置との間で送受信するデータ送受信ステップと、
前記データ送受信ステップにおいて受信される前記データの内、前記特定情報格納ステップにおいて格納された前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力ステップとを備える、情報処理方法。
【請求項２０】
コンテンツを含むデータの送受信が可能な情報処理装置のコンピュータで実行される情報処理プログラムであって、
前記コンピュータを、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信手段と、
前記特定情報受信手段によって受信された前記特定情報を格納する特定情報格納手段と、
前記特定情報格納手段に格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信手段と、
前記データを他の情報処理装置との間で送受信するデータ送受信手段と、
前記データ送受信手段によって受信される前記データの内、前記特定情報格納手段に格納されている前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力手段として機能させる、情報処理プログラム。
【請求項２１】
コンテンツを含むデータの送受信が可能な情報処理装置であって、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信手段と、
前記特定情報受信手段によって受信された前記特定情報を格納する特定情報格納手段と、
前記特定情報格納手段に格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信手段と、
前記データを他の情報処理装置との間で送受信するデータ送受信手段と、
前記データ送受信手段によって受信される前記データの内、前記特定情報格納手段に格納されている前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力手段とを備える、情報処理装置。
【請求項２２】
データの送受信が可能な複数の情報処理装置を少なくとも含む情報処理システムであって、
各前記情報処理装置は、出力を行わないデータを特定する特定情報を、他の情報処理装置との間で送受信する特定情報送受信手段を備える、情報処理システム。
【請求項１】
コンテンツを含むデータの送受信が可能な複数の情報処理装置を少なくとも含む情報処理システムであって、
各前記情報処理装置は、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信手段と、
前記特定情報受信手段によって受信された前記特定情報を格納する特定情報格納手段と、
前記特定情報格納手段に格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信手段と、
前記データを他の情報処理装置との間で送受信するデータ送受信手段と、
前記データ送受信手段によって受信される前記データの内、前記特定情報格納手段に格納されている前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力手段とを備える、情報処理システム。
【請求項２】
各前記情報処理装置は、通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する無線通信手段をさらに備え、
前記特定情報受信手段は、前記無線通信手段を用いて前記特定情報を自動的に受信し、
前記特定情報格納手段は、前記無線通信手段によって受信された前記特定情報を格納し、
前記特定情報送信手段は、前記特定情報格納手段に格納された前記特定情報を前記無線通信手段を用いて他の情報処理装置に自動的に送信する、請求項１に記載の情報処理システム。
【請求項３】
各前記情報処理装置は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置に無線接続し、当該他の情報処理装置との間で通信する無線通信手段をさらに備え、
前記特定情報受信手段は、前記無線通信手段を用いて前記特定情報を受信し、
前記特定情報格納手段は、前記無線通信手段によって受信された前記特定情報を格納し、
前記特定情報送信手段は、前記特定情報格納手段に格納された前記特定情報を前記無線通信手段を用いて他の情報処理装置に送信する、請求項１に記載の情報処理システム。
【請求項４】
各情報処理装置のそれぞれに対して前記特定情報を送信するサーバ装置をさらに含み、
各前記情報処理装置は、
前記サーバ装置から送信される前記特定情報を受信するサーバ情報受信手段と、
前記サーバ情報受信手段によって受信された前記特定情報で前記特定情報格納手段に格納された前記特定情報を更新する更新手段とをさらに備える、請求項１〜３のいずれか１つに記載の情報処理システム。
【請求項５】
各前記情報処理装置は、
前記データ送受信手段によって受信される前記データの中で出力しないように設定する前記データの選択をユーザから受け付ける受付手段と、
前記受付手段によって受け付けられた前記データまたは当該データに関連する情報の内少なくとも一部を通報データとして前記サーバ装置に送信する送信手段とをさらに備え、
前記サーバ装置は、
各前記情報処理装置の前記送信手段から送信される前記通報データに基づいて、各前記情報処理装置に送信する前記特定情報を更新するサーバ側更新手段と、
前記サーバ側更新手段によって更新される前記特定情報を格納するサーバ側特定情報格納手段とを備える、請求項４に記載の情報処理システム。
【請求項６】
前記サーバ装置は、前記サーバ側特定情報格納手段に格納されている前記特定情報を送信するサーバ情報送信手段をさらに備え、
前記サーバ情報受信手段は、前記サーバ情報送信手段から前記特定情報を定期的に受信する、請求項４または５に記載の情報処理システム。
【請求項７】
前記サーバ側更新手段は、各前記情報処理装置の前記送信手段からそれぞれ送信される前記通報データの送信回数が所定の閾値以上となったとき、前記サーバ側特定情報格納手段に格納されている前記特定情報を更新する、請求項５または６のいずれかに記載の情報処理システム。
【請求項８】
前記データは、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子及び当該データのデータ識別子を含み、
前記送信手段は、少なくとも前記ユーザ識別子および前記データ識別子を前記通報データとして前記サーバ装置に送信し、
前記サーバ側更新手段は、前記送信手段からの送信回数が第１の閾値以上となった前記通報データの前記データ識別子を前記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第１の閾値よりも大きい第２の閾値以上となった前記通報データの前記ユーザ識別子を前記特定情報に追加して更新する、請求項７に記載の情報処理システム。
【請求項９】
前記出力手段は、前記データ送受信手段によって受信される前記データの内、前記データ識別子と前記特定情報に含まれる前記データ識別子が一致する前記データ、および、前記ユーザ識別子と前記特定情報に含まれる前記ユーザ識別子が一致する前記データを出力せず、いずれも一致しない前記データを出力する、請求項８に記載の情報処理システム。
【請求項１０】
前記データは、複数のアプリケーションの内いずれかを用いて作成され、少なくともユーザによって作成されたコンテンツ、当該データを作成したユーザを示すユーザ識別子および当該データを作成するのに用いられたアプリケーションプログラムを示すアプリ識別子を含み、
前記サーバ側更新手段は、前記送信手段からの送信回数が第２の閾値以上となった前記通報データの前記ユーザ識別子と前記アプリ識別子とを組み合わせて前記特定情報に追加することで当該特定情報を更新し、当該送信回数が当該第２の閾値よりも大きい第３の閾値以上となった前記通報データの前記ユーザ識別子と、全てのアプリケーションプログラムを示す前記アプリ識別子とを組み合わせて当該特定情報に追加することで当該特定情報を更新する、請求項７に記載の情報処理システム。
【請求項１１】
前記出力手段は、前記データ送受信手段によって受信される前記データの内、前記アプリ識別子と前記ユーザ識別子との組み合わせが前記特定情報に含まれる前記アプリ識別子と前記ユーザ識別子との組み合わせと一致する前記データを出力せず、一致しない前記データを出力する、請求項１０に記載の情報処理システム。
【請求項１２】
各前記情報処理装置は、
前記データ送受信手段によって受信される前記データの中で出力しないように設定する前記データの選択をユーザから受け付ける受付手段と、
前記受付手段によって受け付けられた前記データ又は当該データに関連する情報の内少なくとも一部を通報データとして前記サーバ装置に送信する送信手段とをさらに備え、
前記サーバ装置は、
各前記情報処理装置の前記送信手段から送信される前記通報データに基づいて、当該通報データを用いて特定される前記データが不適切なデータであることを通知する通知手段と、
前記通知手段による通知を受けた前記サーバ装置の使用者の操作により、各情報処理装置に送信する前記特定情報を更新するサーバ側更新手段と、
前記サーバ側更新手段によって更新される前記特定情報を格納するサーバ側特定情報格納手段とを備える、請求項４に記載の情報処理システム。
【請求項１３】
前記通知手段は、各前記情報処理装置の前記送信手段からの送信回数が所定の閾値以上となった前記通報データを用いて特定される前記データが不適切なデータであることを通知する、請求項１２に記載の情報処理システム。
【請求項１４】
前記更新手段は、前記サーバ情報受信手段によって受信された前記特定情報が、情報処理装置に既に格納されている前記特定情報よりも新しい場合、既に格納されている前記特定情報に、受信された前記特定情報の差分を追加又は全部を上書することで前記特定情報を更新する、請求項４に記載の情報処理システム。
【請求項１５】
前記更新手段は、前記サーバ情報受信手段によって前記特定情報が受信された時点で前記情報処理装置に格納された前記特定情報を更新する、請求項４に記載の情報処理システム。
【請求項１６】
各前記情報処理装置は、近距離無線を用いて通信可能範囲に存在する他の情報処理装置を繰り返し探索して自動的に無線接続し、当該他の情報処理装置との間で自動的に通信する無線通信手段をさらに備え、
前記データ送受信手段は、前記無線通信手段を用いて自動的に前記データを送受信する、請求項１に記載の情報処理システム。
【請求項１７】
前記情報処理装置は、前記データ送受信手段によって現在までに受信された前記データを格納するデータ格納手段をさらに備え、
前記出力手段は、前記データ格納手段に格納された前記データの内、前記特定情報格納手段に格納されている前記特定情報によって特定された前記データを出力しない、請求項１〜４のいずれか１つに記載の情報処理システム。
【請求項１８】
各前記情報処理装置は、携帯可能である、請求項３に記載の情報処理システム。
【請求項１９】
コンテンツを含むデータの送受信が可能な情報処理装置で用いられる情報処理方法であって、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信ステップと、
前記特定情報受信ステップにおいて受信された前記特定情報を格納する特定情報格納ステップと、
前記特定情報格納ステップにおいて格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信ステップと、
前記データを他の情報処理装置との間で送受信するデータ送受信ステップと、
前記データ送受信ステップにおいて受信される前記データの内、前記特定情報格納ステップにおいて格納された前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力ステップとを備える、情報処理方法。
【請求項２０】
コンテンツを含むデータの送受信が可能な情報処理装置のコンピュータで実行される情報処理プログラムであって、
前記コンピュータを、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信手段と、
前記特定情報受信手段によって受信された前記特定情報を格納する特定情報格納手段と、
前記特定情報格納手段に格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信手段と、
前記データを他の情報処理装置との間で送受信するデータ送受信手段と、
前記データ送受信手段によって受信される前記データの内、前記特定情報格納手段に格納されている前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力手段として機能させる、情報処理プログラム。
【請求項２１】
コンテンツを含むデータの送受信が可能な情報処理装置であって、
出力を制限する前記データを特定する情報を特定情報として受信する特定情報受信手段と、
前記特定情報受信手段によって受信された前記特定情報を格納する特定情報格納手段と、
前記特定情報格納手段に格納された前記特定情報をさらに他の情報処理装置へ送信する特定情報送信手段と、
前記データを他の情報処理装置との間で送受信するデータ送受信手段と、
前記データ送受信手段によって受信される前記データの内、前記特定情報格納手段に格納されている前記特定情報に基づいて特定された前記データを出力せず、当該特定情報に基づいて特定されない前記データを出力する出力手段とを備える、情報処理装置。
【請求項２２】
データの送受信が可能な複数の情報処理装置を少なくとも含む情報処理システムであって、
各前記情報処理装置は、出力を行わないデータを特定する特定情報を、他の情報処理装置との間で送受信する特定情報送受信手段を備える、情報処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図７Ｅ】
【図７Ｆ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図８Ｆ】
【図８Ｇ】
【図８Ｈ】
【図８Ｉ】
【図８Ｊ】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図７Ｅ】
【図７Ｆ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図８Ｆ】
【図８Ｇ】
【図８Ｈ】
【図８Ｉ】
【図８Ｊ】
【図９】
【公開番号】特開２０１２−９３９１６（Ｐ２０１２−９３９１６Ａ）
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願番号】特願２０１０−２４００５６（Ｐ２０１０−２４００５６）
【出願日】平成２２年１０月２６日（２０１０．１０．２６）
【出願人】（０００２３３７７８）任天堂株式会社 (1,115)
【Ｆターム（参考）】
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願日】平成２２年１０月２６日（２０１０．１０．２６）
【出願人】（０００２３３７７８）任天堂株式会社 (1,115)
【Ｆターム（参考）】
[ Back to top ]