複数の情報処理装置を含む通信システムであって、前記情報処理装置はそれぞれ、他の情報処理装置へ送信するための第1データを記憶する記憶手段と、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して前記第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された第1データを自動的に受信する通信手段と、前記通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データの前記通信手段による送信を許容する制御手段とを備える、通信システム。他の情報処理装置へ送信するための第1データを記憶する記憶手段に接続された情報処理装置のコンピュータを、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して前記第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された前記第1データを自動的に受信する通信手段と、前記通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データの前記通信手段による送信を許容する制御手段として機能させる、情報処理プログラム。前記第1データは、不特定の他の情報処理装置に送信するためのデータであり、前記第2データは、特定の他の情報処理装置に送信するためのデータである、請求項2に記載の情報処理プログラム。前記通信手段は、前記制御手段により前記第2データの送信が許容された場合に、当該第2データに対応する他の情報処理装置に、当該第2データを前記近距離無線通信によって自動的に送信する、請求項2または3に記載の情報処理プログラム。前記制御手段は、前記第2データの作成をユーザに許容することにより、当該第2データの前記通信手段による送信を許容する、請求項2ないし4のいずれかに記載の情報処理プログラム。前記コンピュータを、前記受信手段により受信した前記第1データに基づく内容を表示装置に表示させる表示制御手段としてさらに機能させ、前記制御手段は、前記表示制御手段により前記内容が表示された後に、前記第2データの作成をユーザに許容する、請求項2ないし5のいずれかに記載の情報処理プログラム。前記第1データおよび第2データは文字列データであり、前記制御手段は、前記第2データが作成される際に前記表示制御手段によって表示されていた前記第1データまたは第2データの内容を示す引用データを当該第2データに含める、請求項6に記載の情報処理プログラム。前記第1データは、前記通信手段による前記他の情報処理装置との通信が初めて行われるよりも前に予め作成されているデータであり、前記第2データは、他の情報処理装置から受信された前記第1データまたは第2データが前記表示制御手段によって表示された後にのみ作成することが可能である、請求項6または7に記載の情報処理プログラム。前記コンピュータを、前記実績のある他の情報処理装置に向けて次回に送信するデータとして、前記第1データおよび前記第2データのいずれかを選択する選択手段としてさらに機能させ、前記制御手段は、前記選択手段によって前記第2データが選択された場合、前記第2データの作成をユーザに許容する、請求項5に記載の情報処理プログラム。前記通信手段は、無線接続した他の情報処理装置に対して、キャラクタの画像データとともに前記第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信されたキャラクタの画像データと前記第1データを自動的に受信し、前記制御手段は、前記通信手段によって以前にキャラクタの画像データと当該画像データに対応した第1データの送受信を行った実績がある他の情報処理装置に対する前記第2データの前記通信手段による送信を許容する、請求項2ないし9のいずれかに記載の情報処理プログラム。前記コンピュータを、前記受信手段により受信した前記第1データまたは第2データの内容を表示装置に表示させる表示制御手段と、以前に前記通信手段によって第1データの送受信を行った実績がない前記他の情報処理装置に対しては、次回に送信するデータとして前記第2データのみを選択可能とし、以前に当該通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対しては、当該通信手段により前記他の情報処理装置に対して次回に送信するデータとして、前記第1データおよび前記第2データのいずれかを選択可能とする選択手段としてさらに機能させる、請求項10に記載の情報処理プログラム。前記制御手段は、前記第2データとしてのテキストの入力をユーザに許容する、請求項5に記載の情報処理プログラム。記憶手段に記憶されている他の情報処理装置へ送信するためのデータの情報処理方法であって、近距離無線による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して前記記憶手段に記憶されている第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された第1データを自動的に受信する通信ステップと、前記通信ステップによる第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データを前記通信ステップにおいて送信することを許容する制御ステップとを備える、情報処理方法。他の情報処理装置へ送信するための第1データを記憶する記憶手段に接続された情報処理装置であって、近距離無線による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して前記第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された前記第1データを自動的に受信する通信手段と、前記通信手段によって前記第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データの前記通信手段による送信を許容する制御手段とを備える、情報処理装置。他の情報処理システムへ送信するための第1データを記憶する記憶手段に接続された情報処理システムであって、近距離無線による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理システムに対して前記第1データを自動的に送信するとともに、無線接続した他の情報処理システムから送信された前記第1データを自動的に受信する通信手段と、前記通信手段によって前記第1データの送受信を行った実績がある他の情報処理システムに対する当該第1データとは異なる第2データの前記通信手段による送信を許容する制御手段とを備える、情報処理システム。しかしながら、上記特許文献1に記載されているシステムでは、どの携帯端末に対しても同じメッセージを送信し続けることになりユーザにとっては、他の携帯端末のユーザとコミュニケーションを取っているという感覚が乏しく、他の携帯端末とのやり取りが単調なものとなっていた。出願人は、この点について、近距離無線通信を利用する携帯端末間でのコミュニケーションに関し、興趣性を向上させるという点について改善の余地があることを発見した。それ故に、本発明の目的は、近距離無線通信を利用した情報処理装置間のコミュニケーションをより活性化させることができるシステムを提供することである。上記目的を達成するために、本発明は以下のような構成を採用した。本発明にかかる通信システムは、複数の情報処理装置を含む通信システムであって、情報処理装置はそれぞれ、記憶手段と、通信手段と、制御手段とを備える。記憶手段は、他の情報処理装置へ送信するための第1データを記憶する。通信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された第1データを自動的に受信する。制御手段は、通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対する、当該第1データとは異なる第2データの通信手段による送信を許容する。上記構成により、近距離無線通信によるデータの送受信を行ったことがある相手に対しては、当該データとは異なるデータを送ることが可能となる。そのため、近距離無線通信を用いた他人とのコミュニケーションが無味乾燥なものとなることを防ぎ、他人とのコミュニケーションの活性化を図ることが可能となる。換言すれば、例えば、見ず知らずの他人との間で近距離無線通信が複数回行われることで、この相手に向けた個別データのやりとりを通じて親密度を増し、新たに友達となる可能性を高めることができ、コミュニケーションの活性化を図ることが可能となる。本発明にかかる情報処理プログラムは、他の情報処理装置へ送信するための第1データを記憶する記憶手段に接続された情報処理装置のコンピュータを、通信手段と、制御手段として機能させる。通信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された第1データを自動的に受信する。制御手段は、通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データの通信手段による送信を許容する。上記構成により、近距離無線通信によるデータの送受信を行ったことがある相手に対しては、当該データとは異なるデータを送ることが可能となる。そのため、近距離無線通信を用いた他人とのコミュニケーションが無味乾燥なものとなることを防ぎ、他人とのコミュニケーションの活性化を図ることが可能となる。他の構成例として、第1データは、不特定の他の情報処理装置に送信するためのデータであり、第2データは、特定の他の情報処理装置に送信するためのデータであってもよい。上記構成例によれば、例えば、不特定多数の相手や、ある集団の全体向けのような、相手を指定しないデータと、相手を指定した個別のデータとを併用することで、近距離無線通信を用いた他人とのコミュニケーションが無味乾燥なものとなることを防ぎ、他人とのコミュニケーションの活性化を図ることが可能となる。更に他の構成例として、通信手段は、制御手段により第2データの送信が許容された場合に、当該第2データに対応する他の情報処理装置に、当該第2データを近距離無線通信によって自動的に送信するようにしてもよい。上記構成例によれば、近距離無線通信によるデータの送受信を行ったことがある相手に対して当該データとは異なるデータを送ることが可能となり、他人とのコミュニケーションの活性化を図ることが可能となる。更に他の構成例として、制御手段は、第2データの作成をユーザに許容することにより、当該第2データの通信手段による送信を許容してもよい。上記構成例によれば、例えば、よくすれ違う相手に向けた特別なデータをユーザが自分で作成することができ、コミュニケーションの更なる活性化を図ることができる。更に他の構成例として、コンピュータを、受信手段により受信した第1データに基づく内容を表示装置に表示させる表示制御手段としてさらに機能させてもよい。そして、制御手段は、表示制御手段により内容が表示された後に、第2データの作成をユーザに許容するようにしてもよい。上記構成例によれば、不特定の相手向けのデータに対する返事として、その相手に向けた宛先特定データを生成することができ、コミュニケーションの円滑化を図ることができる。更に他の構成例として、第1データおよび第2データは文字列データであり、制御手段は、第2データが作成される際に表示制御手段によって表示されていた第1データまたは第2データの内容を示す引用データを当該第2データに含めるようにしてもよい。上記構成例によれば、受信したデータが自分宛のデータであった場合、自分が以前に送ったどのようなデータに対しての返信であるかをユーザに把握させることができ、コミュニケーションの円滑化を図ることが可能となる。更に他の構成例として、第1データは、通信手段による他の情報処理装置との通信が初めて行われるよりも前に予め作成されているデータであり、第2データは、他の情報処理装置から受信された第1データまたは第2データが表示制御手段によって表示された後にのみ作成することが可能なようにしてもよい。上記構成例によれば、例えば、不特定の相手向けのメッセージについては事前に定型文として作成しておくことでユーザの手間を省くことができ、特定の相手向けのメッセージについてはその都度作成させることで、臨機応変に特定の相手向けのメッセージが作成可能となる。更に他の構成例として、コンピュータを、実績のある他の情報処理装置に向けて次回に送信するデータとして、第1データおよび第2データのいずれかを選択する選択手段としてさらに機能させてもよい。そして、制御手段は、選択手段によって第2データが選択された場合、第2データの作成をユーザに許容するようにしてもよい。上記構成例によれば、近距離無線通信を行った回数が多くなった相手に対して、不特定の相手向けのデータを送るか、その相手を特定したデータを送るかをユーザに選択させることができる。その結果、近距離無線通信を行った回数が多くなった相手に対して、必ずしもその相手を特定したデータを作成して送らなくてもよいという余地を与えることで、ユーザの利便性を高めることができる。更に他の構成例として、通信手段は、無線接続した他の情報処理装置に対して、キャラクタの画像データとともに第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信されたキャラクタの画像データと第1データを自動的に受信し制御手段は、通信手段によって以前にキャラクタの画像データと当該画像データに対応した第1データの送受信を行った実績がある他の情報処理装置に対する第2データの通信手段による送信を許容するようにしてもよい。上記構成例によれば、キャラクタの画像データを用いることで、当該画像データを通して通信相手に対するイメージをユーザに伝えやすくすることができ、コミュニケーションの円滑化を図ることができる。更に他の構成例として、コンピュータを、受信手段により受信した第1データまたは第2データの内容を表示装置に表示させる表示制御手段と、以前に通信手段によって第1データの送受信を行った実績がない他の情報処理装置に対しては、次回に送信するデータとして第1データのみを選択可能とし、以前に当該通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対しては、当該通信手段により他の情報処理装置に対して次回に送信するデータとして、第1データおよび第2データのいずれかを選択可能とする選択手段としてさらに機能させる。上記構成例によれば、例えば、初対面の相手、見ず知らずの相手や親しくない相手に対しては、当たり障りのないメッセージを宛先不特定データとして送信し、近距離無線通信を何度か行った実績ができて初めて、個別のメッセージを宛先特定データとして作成可能となる。これにより、不特定多数の他人の中から親しくなれそうな相手が抽出され、その相手に対して個別にメッセージを送ることができるため、コミュニケーションの活性化円滑化を図ることができる。更に他の構成例として、通信実績判別手段による判別結果が肯定である場合、前記宛先特定データとしてのテキストの入力をユーザに許容してもよい。上記構成例によれば、宛先特定データとしてテキストデータを送信することができるため、例えば、よくすれ違う相手に向けた特別なメッセージを作成して送信することが可能となる。本発明にかかる情報処理方法は、記憶手段に記憶されている他の情報処理装置へ送信するためのデータの情報処理方法であって、通信ステップと、制御ステップとを備える。通信ステップでは、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された第1データを自動的に受信する。制御ステップでは、通信ステップによる第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データを通信ステップにおいて送信することを許容する。本発明にかかる情報処理装置は、他の情報処理装置へ送信するための第1データを記憶する記憶手段に接続された情報処理装置であって、通信手段と、制御手段とを備える。通信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対して第1データを自動的に送信するとともに、無線接続した他の情報処理装置から送信された第1データを自動的に受信する。制御手段は、通信手段によって第1データの送受信を行った実績がある他の情報処理装置に対する当該第1データとは異なる第2データの通信手段による送信を許容する。本発明にかかる情報処理システムは、他の情報処理システムへ送信するための第1データを記憶する記憶手段に接続された情報処理システムであって、通信手段と、制御手段とを備える。通信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理システムに対して第1データを自動的に送信するとともに、無線接続した他の情報処理システムから送信された第1データを自動的に受信する。制御手段は、通信手段によって第1データの送受信を行った実績がある他の情報処理システムに対する、当該第1データとは異なる第2データの通信手段による送信を許容する。本発明によれば、近距離無線通信を利用した情報処理装置間のコミュニケーションをより活性化させることができる。以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。図1は、本実施形態にかかる広場アプリケーション以下、広場アプリ等を実行するゲーム装置1の外観図である。ここでは、ゲーム装置1の一例として、携帯ゲーム装置を示す。図1において、ゲーム装置1は、折り畳み型の携帯ゲーム装置であり、開いた状態開状態のゲーム装置1を示している。ゲーム装置1は、開いた状態においてもユーザが両手または片手で把持することができるようなサイズで構成される。ゲーム装置1は、下側ハウジング11および上側ハウジング21を有する。下側ハウジング11と上側ハウジング21とは、開閉可能折り畳み可能に連結されている。図1の例では、下側ハウジング11および上側ハウジング21は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回転可能に連結されている。通常、ユーザは、開状態でゲーム装置1を使用する。また、ユーザは、ゲーム装置1を使用しない場合には閉状態としてゲーム装置1を保管する。また、図1に示した例では、ゲーム装置1は、上記閉状態および開状態のみでなく、下側ハウジング11と上側ハウジング21とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング21を下側ハウジング11に対して任意の角度で静止させることができる。下側ハウジング11には、下側LCDLiquidCrystalDisplay:液晶表示装置12が設けられる。下側LCD12は横長形状であり、長辺方向が下側ハウジング11の長辺方向に一致するように配置される。なお、本実施形態では、ゲーム装置1に内蔵されている表示装置としてLCDを用いているが、例えばELElectroLuminescence:電界発光を利用した表示装置等、他の任意の表示装置を利用してもよい。また、ゲーム装置1は、任意の解像度の表示装置を利用することができる。なお、詳細は後述するが、下側LCD12は、主に、内側カメラ23または外側カメラ25で撮影されている画像をリアルタイムに表示するために用いられる。下側ハウジング11には、入力装置として、各操作ボタン14A~14Kおよびタッチパネル13が設けられる。図1に示されるように、各操作ボタン14A~14Kのうち、方向入力ボタン14A、操作ボタン14B、操作ボタン14C、操作ボタン14D、操作ボタン14E、電源ボタン14F、スタートボタン14G、およびセレクトボタン14Hは、上側ハウジング21と下側ハウジング11とを折りたたんだときに内側となる、下側ハウジング11の内側主面上に設けられる。方向入力ボタン14Aは、例えば選択操作等に用いられる。各操作ボタン14B~14Eは、例えば決定操作やキャンセル操作等に用いられる。電源ボタン14Fは、ゲーム装置1の電源をオン/オフするために用いられる。図1に示す例では、方向入力ボタン14Aおよび電源ボタン14Fは、下側ハウジング11の内側主面中央付近に設けられる下側LCD12に対して、左右一方側図1では左側の当該主面上に設けられる。また、操作ボタン14B~14E、スタートボタン14G、およびセレクトボタン14Hは、下側LCD12に対して左右他方側図1では右側となる下側ハウジング11の内側主面上に設けられる。方向入力ボタン14A、操作ボタン14B~14E、スタートボタン14G、およびセレクトボタン14Hは、ゲーム装置1に対する各種操作を行うために用いられる。なお、図1においては、操作ボタン14I~14Kの図示を省略している。例えば、Lボタン14Iは、下側ハウジング11の上側面の左端部に設けられ、Rボタン14Jは、下側ハウジング11の上側面の右端部に設けられる。Lボタン14IおよびRボタン14Jは、ゲーム装置1に対して、例えば撮影指示操作シャッター操作を行うために用いられる。さらに、音量ボタン14Kは、下側ハウジング11の左側面に設けられる。音量ボタン14Kは、ゲーム装置1が備えるスピーカの音量を調整するために用いられる。また、ゲーム装置1は、各操作ボタン14A~14Kとは別の入力装置として、さらにタッチパネル13を備えている。タッチパネル13は、下側LCD12の画面上を覆うように装着されている。なお、本実施形態では、タッチパネル13は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル13は、抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。また、本実施形態では、タッチパネル13として、例えば下側LCD12の解像度と同解像度検出精度のものを利用する。ただし、必ずしもタッチパネル13の解像度と下側LCD12の解像度とが一致している必要はない。また、下側ハウジング11の右側面には、挿入口図1に示す破線が設けられている。挿入口は、タッチパネル13に対する操作を行うために用いられるタッチペン27を収納することができる。なお、タッチパネル13に対する入力は、通常タッチペン27を用いて行われるが、タッチペン27に限らずユーザの指でタッチパネル13を操作することも可能である。また、下側ハウジング11の右側面には、メモリカード28を収納するための挿入口図1では、二点鎖線で示しているが設けられている。この挿入口の内側には、ゲーム装置1とメモリカード28とを電気的に接続するためのコネクタ図示せずが設けられる。メモリカード28は、例えばSDSecureDigitalメモリカードであり、コネクタに着脱自在に装着される。メモリカード28は、例えば、ゲーム装置1によって撮影された画像を記憶保存したり、他の装置で生成された画像をゲーム装置1に読み込んだりするために用いられる。さらに、下側ハウジング11の上側面には、カートリッジ29を収納するための挿入口図1では、一点鎖線で示しているが設けられている。この挿入口の内側にも、ゲーム装置1とカートリッジ29とを電気的に接続するためのコネクタ図示せずが設けられる。カートリッジ29はゲームプログラム等を記録した記録媒体であり、下側ハウジング11に設けられた挿入口に着脱自在に装着される。下側ハウジング11と上側ハウジング21との連結部の左側部分には、3つのLED15A~15Cが取り付けられる。ここで、ゲーム装置1は、他の機器との間で無線通信を行うことが可能であり、第1LED15Aは、ゲーム装置1の電源がオンである場合に点灯する。第2LED15Bは、ゲーム装置1の充電中に点灯する。第3LED15Cは、無線通信が確立している場合に点灯する。したがって、3つのLED15A~15Cによって、ゲーム装置1の電源のオン/オフ状況、充電状況、および、通信確立状況をユーザに通知することができる。一方、上側ハウジング21には、上側LCD22が設けられる。上側LCD22は横長形状であり、長辺方向が上側ハウジング21の長辺方向に一致するように配置される。なお、下側LCD12と同様、上側LCD22に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、上側LCD22上を覆うように、タッチパネルを設けてもかまわない。例えば、上側LCD22には、ユーザに各操作ボタン14A~14Kやタッチパネル13の役割を教えるための、操作説明画面が表示される。また、上側ハウジング21には、2つのカメラ内側カメラ23および外側カメラ25が設けられる。図1に示されるように、内側カメラ23は、上側ハウジング21の連結部付近の内側主面に取り付けられる。一方、外側カメラ25は、内側カメラ23が取り付けられる内側主面の反対側の面、すなわち、上側ハウジング21の外側主面ゲーム装置1が閉状態となった場合に外側となる面であり、図1に示す上側ハウジング21の背面に取り付けられる。なお、図1においては、外側カメラ25を破線で示している。これによって、内側カメラ23は、上側ハウジング21の内側主面が向く方向を撮影することが可能であり、外側カメラ25は、内側カメラ23の撮影方向の逆方向、すなわち、上側ハウジング21の外側主面が向く方向を撮影することが可能である。このように、本実施形態では、2つの内側カメラ23および外側カメラ25の撮影方向が互いに逆方向となるように設けられる。例えば、ユーザは、ゲーム装置1からユーザの方を見た景色を内側カメラ23で撮影することができるとともに、ゲーム装置1からユーザの反対側の方向を見た景色を外側カメラ25で撮影することができる。なお、上記連結部付近の内側主面には、音声入力装置としてマイク図2に示すマイク42が収納されている。そして、上記連結部付近の内側主面には、マイク42がゲーム装置1外部の音を検知できるように、マイクロフォン用孔16が形成される。マイク42を収納する位置およびマイクロフォン用孔16の位置は必ずしも上記連結部である必要はなく、例えば下側ハウジング11にマイク42を収納し、マイク42を収納位置に対応させて下側ハウジング11にマイクロフォン用孔16を設けるようにしても良い。また、上側ハウジング21の外側主面には、第4LED26図1では、破線で示すが取り付けられる。第4LED26は、外側カメラ25によって撮影が行われたシャッターボタンが押下された時点で点灯する。また、外側カメラ25によって動画が撮影される間点灯する。第4LED26によって、ゲーム装置1による撮影が行われた行われていることを撮影対象者や周囲に通知することができる。また、上側ハウジング21の内側主面中央付近に設けられる上側LCD22に対して、左右両側の当該主面に音抜き孔24がそれぞれ形成される。音抜き孔24の奥の上側ハウジング21内にはスピーカが収納されている。音抜き孔24は、スピーカからの音をゲーム装置1の外部に放出するための孔である。以上に説明したように、上側ハウジング21には、画像を撮影するための構成である内側カメラ23および外側カメラ25と、例えば撮影の際に操作説明画面を表示する表示手段である上側LCD22とが設けられる。一方、下側ハウジング11には、ゲーム装置1に対する操作入力を行うための入力装置タッチパネル13および各ボタン14A~14Kと、ゲーム画面を表示するための表示手段である下側LCD12とが設けられる。したがって、ゲーム装置1を使用する際には、ユーザは、下側LCD12に表示される撮影画像カメラによって撮影された画像を見ながら、下側ハウジング11を把持して入力装置に対する入力を行うことができる。次に、図2を参照して、ゲーム装置1の内部構成を説明する。なお、図2は、ゲーム装置1の内部構成の一例を示すブロック図である。図2において、ゲーム装置1は、CPU31、メインメモリ32、メモリ制御回路33、保存用データメモリ34、プリセットデータ用メモリ35、メモリカードインターフェースメモリカードI/F36およびカートリッジI/F44、無線通信モジュール37、ローカル通信モジュール38、リアルタイムクロックRTC39、電源回路40、およびインターフェース回路I/F回路41等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて、下側ハウジング11または上側ハウジング21でもよい内に収納される。CPU31は、所定のプログラムを実行するための情報処理手段である。なお、CPU31によって実行されるプログラムは、ゲーム装置1内の保存用データメモリ34に予め記憶されていてもよいし、メモリカード28および/またはカートリッジ29から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。例えば、インターネットを経由して所定のサーバからダウンロードすることで取得しても良いし、据置型ゲーム装置と通信を行うことで、当該据置型ゲーム装置に記憶されている所定のプログラムをダウンロードすることで取得しても良い。CPU31には、メインメモリ32、メモリ制御回路33、およびプリセットデータ用メモリ35が接続される。また、メモリ制御回路33には、保存用データメモリ34が接続される。メインメモリ32は、CPU31のワーク領域やバッファ領域として用いられる記憶手段である。本実施形態では、メインメモリ32として、例えばPSRAMPseudo-SRAMを用いる。保存用データメモリ34は、CPU31によって実行されるプログラムや内側カメラ23および外側カメラ25によって撮影された画像のデータ等を記憶するための記憶手段である。保存用データメモリ34は、不揮発性の記憶媒体によって構成されており、例えば本実施例ではNAND型フラッシュメモリで構成される。メモリ制御回路33は、CPU31の指示に従って、保存用データメモリ34に対するデータの読み出しおよび書き込みを制御する回路である。プリセットデータ用メモリ35は、ゲーム装置1において予め設定される各種パラメータ等のデータプリセットデータを記憶するための記憶手段である。プリセットデータ用メモリ35としては、SPISerialPeripheralInterfaceバスによってCPU31と接続されるフラッシュメモリを用いることができる。メモリカードI/F36は、CPU31に接続される。メモリカードI/F36は、コネクタに装着されたメモリカード28に対するデータの読み出しおよび書き込みを、CPU31の指示に応じて行う。本実施形態では、外側カメラ25によって撮像された画像データがメモリカード28に書き込まれたり、メモリカード28に記憶された画像データがメモリカード28から読み出されて保存用データメモリ34に記憶されたりする。カートリッジI/F44はCPU31に接続される。カートリッジI/F44は、コネクタに装着されたカートリッジ29に対するデータの読み出しおよび書き込みをCPU31の指示に従って行う。本実施形態では、情報処理装置10が実行することが可能なアプリケーションプログラムがカートリッジ29から読み出されてCPU31によって実行されたり、当該アプリケーションプログラムに関するデータ例えばゲームのセーブデータ等がカートリッジ29に書き込まれたりする。なお、本発明にかかる広場アプリ処理のプログラムは、本ゲーム装置1のプリインストールアプリとして予め保存用データメモリ34に記憶された状態であることを前提とするが、有線または無線の通信回線を通じてコンピュータシステムに供給されてもよい。無線通信モジュール37は、例えばIEEE802.11.b/gの規格に準拠した方式により、無線LANに接続する機能を有する。また、ローカル通信モジュール38は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール37およびローカル通信モジュール38は、CPU31に接続される。CPU31は、無線通信モジュール37を用いてインターネットを介して他の機器との間でデータを送受信することができる。また、CPU31は、ローカル通信モジュール38を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。例えば、CPU31は、ローカル通信モジュール38を用いて、近距離無線通信による通信範囲内例えば、機器間の距離が数十メートルにある他のゲーム装置を繰り返し探索して自動的に無線接続し、無線接続した他のゲーム装置に対してデータを自動的に送信するとともに、無線接続した他のゲーム装置から送信されるデータを自動的に受信することができる。また、CPU31には、RTC39および電源回路40が接続される。RTC39は、時間をカウントしてCPU31に出力する。例えば、CPU31は、RTC39によって計時された時間に基づいて、現在時刻日付等を計算することもできる。電源回路40は、ゲーム装置1が有する電源典型的には電池であり、下側ハウジング11に収納されるから供給される電力を制御し、ゲーム装置1の各部品に電力を供給する。ここで、本実施形態では、電源が落とされていないときのゲーム装置1の動作状態として、通常動作モードとスリープモードとよばれる2つの状態がある。通常モードは、ゲーム装置1が開いており、ゲーム装置1を構成する部品の全てに電力が供給されている状態である。つまり、ユーザがゲーム装置1を直接操作しているような状態である。スリープモードは、ゲーム装置1が閉じられた折り畳んだ状態であるが、CPU31等の一部の構成部品には電力が供給されている状態であり、ユーザは直接的にはゲーム装置1に対して操作は行っていないが、CPU31による処理は可能な状態である。本実施形態では、このスリープモード中に、上記ローカル通信モジュール38を利用したすれちがい通信と呼ばれる通信が行われる詳細は後述する。また、ゲーム装置1は、マイク42およびアンプ43を備えている。マイク42およびアンプ43は、それぞれI/F回路41に接続される。マイク42は、ゲーム装置1に向かって発声されたユーザの音声を検知して、当該音声を示す音声信号をI/F回路41に出力する。アンプ43は、I/F回路41から音声信号を増幅してスピーカ図示せずから出力させる。I/F回路41は、CPU31に接続される。また、タッチパネル13は、I/F回路41に接続される。I/F回路41は、マイク42およびアンプ43スピーカの制御を行う音声制御回路と、タッチパネル13の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するA/D変換およびD/A変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル13からの信号に基づいて所定の形式のタッチ位置データを生成してCPU31に出力する。例えば、タッチ位置データは、タッチパネル13の入力面に対して入力が行われた位置の座標を示すデータである。なお、タッチパネル制御回路は、タッチパネル13からの信号の読み込み、および、タッチ位置データの生成を所定時間に1回の割合で行う。CPU31は、I/F回路41を介して、タッチ位置データを取得することにより、タッチパネル13に対して入力が行われた位置を知ることができる。操作ボタン14は、上記各操作ボタン14A~14Kから構成され、CPU31に接続される。操作ボタン14からCPU31へは、各操作ボタン14A~14Kに対する入力状況押下されたか否かを示す操作データが出力される。CPU31は、操作ボタン14から操作データを取得することによって、操作ボタン14に対する入力に応じた処理を実行する。内側カメラ23および外側カメラ25は、それぞれCPU31に接続される。内側カメラ23および外側カメラ25は、CPU31の指示に応じて画像を撮影し、撮影した画像データをCPU31に出力する。本実施形態では、CPU31は、内側カメラ23および外側カメラ25のいずれか一方に対して撮影指示を行い、撮影指示を受けたカメラが画像を撮影して画像データをCPU31に送る。また、下側LCD12および上側LCD22は、それぞれCPU31に接続される。下側LCD12および上側LCD22は、それぞれCPU31の指示に従って画像を表示する。以下、本実施形態で想定する広場アプリ等の処理の概要について説明する。まず、広場アプリ等の処理の内容の説明に先立ち、この処理の前提となるすれちがい通信の概要について説明する。図3および図4は、本実施形態におけるすれちがい通信について説明するための図である。本実施形態では、保存用データメモリ34の中に、すれちがい通信専用の記憶領域を設ける。当該領域は、複数のスロットと呼ばれる単位で論理的に分けられる。このスロットの一つ一つが、所定の1つのアプリと対応付けられる。各スロットには、送信ボックス受信ボックスアプリIDというデータが記憶される。このうち、アプリIDが、当該スロットに対応するアプリを識別するためのデータである。送信ボックスには、すれちがい通信において他のゲーム装置に送信するためのデータが格納され、受信ボックスには、すれちがい通信において他のゲーム装置から受信したデータが格納される。本実施形態では、すれちがい通信は、ゲーム装置1を上記スリープモードにしている間に行われるものとする。例えば、ユーザが、ゲーム装置を閉じた状態にして所持したまま外出したような場合に、ゲーム装置を同様の状態にして所持している他のユーザとすれ違った場合に、以下のような通信が行われる。まず、上記のようなスリープモード中において、各ゲーム装置1からは所定の周期でビーコン信号が発信される。また、互いに自機の通信可能範囲内に存在する他のゲーム装置を検出しあっている。そして、他のゲーム装置1が検知されたとき、いずれかのゲーム装置1が主導する形で、ゲーム装置間ですれちがい通信用のリンク以下、このようなゲーム装置1同士での直接的な通信をローカル通信と呼ぶが確立される。そして、ローカル通信が可能な状態となれば、ゲーム装置間で同じアプリIDが登録されたスロットの有無が判断される、そして、同じアプリIDを有するスロットが双方に存在すれば、図4に示すように、このスロットの送信ボックス内のデータが互いに送信される。相手側のゲーム装置1から送信されたデータは、受信ボックスに格納される。このようにして他のゲーム装置1から受信し、受信ボックスに格納されたデータについては、対応するアプリの起動時に当該受信ボックスから取得され、各アプリにおいて適宜用いられることになる。次に、本実施形態にかかるアプリケーションの処理概要を説明する。本実施形態にかかるアプリケーションには、主に、ユーザキャラクタ作成アプリと広場アプリの2つがある。これらは、ゲーム装置1の基本的なメニュー画面であるホームメニューからユーザによって選択されることで適宜実行される例えば、これらのアプリを示す各アイコンがユーザによって選択されることで実行開始される。ユーザキャラクタ作成アプリは、ユーザキャラクタと呼ばれるキャラクタをユーザに生成させるためのアプリケーションである。本実施形態においては、ユーザキャラクタは複数のパーツによって構成されており、このパーツは、例えば、目、鼻、口、輪郭、髪型等に分類されている。そして、各分類毎に予め複数のパーツが用意されてゲーム装置1に記憶されている。ユーザは、当該ユーザキャラクタ作成アプリで各種パーツを組みあわせる操作を行うことで、例えば、ユーザの顔に似ている顔を有するユーザキャラクタを生成することができる。そして、当該ユーザキャラクタ作成アプリで生成されたユーザキャラクタは、保存用データメモリ34に保存される。なお、このユーザキャラクタは、複数体生成して保存することも可能である。また、一旦作成したユーザキャラクタの外見等を編集例えばパーツを異なるものに変更することも可能である。一方、広場アプリは、上記ユーザキャラクタをコレクションすることを主目的としたアプリである。ユーザキャラクタの収集は、上記すれちがい通信によって行われる。具体的には、上記ユーザキャラクタ作成アプリによって生成されたユーザキャラクタを、上述したようなすれちがい通信によって、他のゲーム装置1に送信すると共に、他のユーザが作成したユーザキャラクタを受信する。これにより、上記すれちがい通信が繰り返されることで、他のユーザが作成したユーザキャラクタを収集することが可能となる。そして、当該広場アプリにおいて、他のユーザの作ったユーザキャラクタを閲覧したり、自分と他のユーザのユーザキャラクタを用いた所定のミニゲーム等を実行することができる。また、このミニゲームでは、例えば、ユーザキャラクタの外観を変更することのできるアクセサリのようなパーツを入手することが可能となっている。ここで、当該広場アプリでは、自己の作成したユーザキャラクタと上記すれちがい通信で取得した他のユーザキャラクタとの間であいさつさせることが可能である。以下、このあいさつにかかる処理をあいさつ処理と呼ぶ。更に、当該広場アプリでは、他のユーザキャラクタを評価し、その結果を相手に伝えることも可能となっている。本実施形態では、この評価対象について、他のユーザキャラクタの外観についての評価を行うものとする。以下では、この評価にかかる処理を評価処理と呼ぶ。以下、これらの処理を含めた、広場アプリの動作の流れの全体的な概要を説明する。典型的な処理の流れとしては、以下のような流れを想定する。まず、広場アプリの初期設定として、すれちがい通信で用いるユーザキャラクタがユーザの操作によって登録される。本実施形態では、すれちがい通信で送受信することが可能なユーザキャラクタの数は1体のみであるとする。その後、ユーザがゲーム装置1をスリープモードにした状態で所持し、外出する。外出中に、何人かの他のユーザより正確には、広場アプリについてのすれちがい通信の設定が済んでいるユーザとすれ違うことで、上記のようなすれちがい通信ユーザキャラクタの送受信が何度か発生する。その後、外出を終えて帰って来たユーザが再度広場アプリを起動すると、新着通知として、今回の外出中に行われたすれちがい通信の回数等が示される。そして、今回の外出中に取得された他のユーザキャラクタについて、1体ずつ順番に、後述するようなあいさつ処理と評価処理が行われる。そして、今回の外出中に取得された他のユーザキャラクタ全てに対してのあいさつ処理と評価処理が終われば、広場アプリのメイン画面が表示される、という流れとなる。換言すれば、本実施形態で説明するあいさつ処理と評価処理は、上記ゲーム装置をスリープモードにしてから、次に広場アプリが起動されるまでに上記すれちがい通信で取得された他のユーザキャラクタいわば新着のユーザキャラクタを対象として行われる処理である。以下、各処理の概要について説明する。[広場アプリの初期設定]まず、上記広場アプリが初めて起動されると初回起動時、当該広場アプリについての初期設定処理が自動的に開始される。この処理においては、当該広場アプリの内容についての簡単な紹介が行われた後、上記すれちがい通信に関する設定、および、上記あいさつ処理において使用される共通あいさつの作成具体的には文字列の入力が行われる。当該設定項目についてより具体的に説明する。上記すれちがい通信に関する主な設定項目としては、すれちがい通信自体を行うか否かという設定項目、あいさつ処理を行うか否かという設定項目、評価処理を行うか否かという設定項目、そして、すれちがい通信で用いるユーザキャラクタの選択、という設定項目がある。これらの設定項目については、当該初期設定処理において、各設定項目について行う行わないをユーザに問いかける画面を表示し、これに対するユーザの入力によって設定される。本実施形態では、すれちがい通信自体を行うか否かという設定項目については、行うという設定にする。その結果、上述したようなすれちがい通信用のスロット上記図3参照のいずれか一つと当該広場アプリとが関連づけられる。具体的には、当該広場アプリを示すアプリIDが上記いずれかのスロットのアプリIDに記憶されることで、スロットと広場アプリとの関連付けが行われることになる。更に、すれちがい通信において送信対象となるユーザキャラクタの選択も行われる。具体的には、ユーザキャラクタの一覧画面等が表示され、ユーザがいずれかのユーザキャラクタを選択する操作を行うことで、すれちがい通信すれちがい通信で用いるユーザキャラクタが選択されることになる。なお、もし上記スロットの全てが既に他のアプリで用いられていた場合は、その旨を知らせるメッセージが適宜表示され、この時点では関連付けは行われない。いずれかのスロットが開放された後に、再度当該関連付けの設定が行われることになる。また、ユーザキャラクタが1体も作成されていない場合は、上記ユーザキャラクタの選択の際にその旨を示すメッセージと、上記ユーザキャラクタ作成アプリを用いてユーザキャラクタの作成を促す旨のメッセージが適宜表示される。あいさつ処理を行うか否かという設定項目、および、評価処理を行うか否かという設定項目については、本実施形態では、自分側も相手側も共に行うと設定されている場合を例として説明する。ここで、本実施形態では、自分側と相手側の双方がこれらの設定項目を行うと設定している場合にのみ、あいさつ処理や評価処理が行われる。つまり、あいさつ処理についていずれか一方で行わないという設定がされていた場合は、あいさつ処理は行われない。また、評価処理についていずれか一方で行わないという設定がされていた場合は、評価処理は行われない。これは、いずれか一方があいさつ処理を行うことを望まない場合や、評価されることを望まない場合にまで、強制的にあいさつや評価を行うことでユーザに不快感を与えないようにするためである。そのため、例えば、いずれか一方の側が、あいさつ処理については行うと設定しているが、評価処理については行わないと設定しているような場合は、あいさつ処理は行われるが、評価処理については行われないことになる。次に、上記共通あいさつの作成の説明に際し、本実施形態のあいさつ処理で用いられるあいさつ全般について説明する。本実施形態のあいさつ処理では、すれちがい通信で受信した他のユーザキャラクタと自己のユーザキャラクタとの間であいさつするような処理が行われる。このあいさつとして、本実施形態では2種類のあいさつが定義されている。1つめは、共通あいさつと呼ばれる種類のあいさつであり、2つめは個別あいさつと呼ばれる種類のあいさつである。共通あいさつは、不特定多数の他のユーザ他のゲーム装置1に対してのあいさつ、という位置づけである。つまり、相手を特に指定しないで、無差別に行われるあいさつである。また、例えば、あるグループに属している全体全員に対してのあいさつも共通あいさつである。また、この共通あいさつは、ある属性を有する多数の相手向けのあいさつであってもよい。例えば、性別が男である他のユーザキャラクタに向けてのあいさつであってもよい。一方、個別あいさつは、ある特定のユーザゲーム装置1に向けたあいさつ、という位置づけである。つまり、ユーザが個別の相手に対して行うことを意図しているあいさつである。換言すれば、送信側のユーザの意図としてはあいさつする相手を指定指名したあいさつである。そして、本実施形態では、基本的には共通あいさつが用いられるが、2回以上すれちがい通信が行われたユーザに対しては、個別あいさつを行うことも可能となる。つまり、初対面の相手に対しては共通あいさつのみ利用できるが、2回以上すれ違ったことがある相手に対しては、共通あいさつおよび個別あいさつのいずれかを選択して利用可能となる。これは、2回もすれ違うすれちがい通信が行われるような相手とは、それ以降何回もすれ違う可能性があることから、個別あいさつによって、より親しい関係のあいさつを可能とするものである。そして、広場アプリの初期設定においては、上記共通あいさつの作成のみが行われる。本実施形態では、適宜入力画面が表示され、これに対して16文字までのテキストをユーザが入力する。このテキストが共通あいさつとして記憶される。その結果、あいさつ処理では、ここで作成記憶された共通あいさつが選択できる。なお、本実施形態では、当該共通あいさつは一つしか作成できないものとする。[スリープモード中のすれちがい通信]このような広場アプリの初期設定が一通り終われば、上記ユーザキャラクタに関するデータや共通あいさつのテキストデータ等が上記送信ボックスに格納される。その後、広場アプリのメイン画面が表示される。ユーザは、一旦広場アプリを終了させてゲーム装置1をスリープモードにする。そして、当該ゲーム装置1を所持して外出する。外出中に上記のようなすれちがい通信が何度か行われた後、ユーザが帰ってきたとする。外出から帰って来たユーザが広場アプリを起動すると、今回の外出中に発生したすれちがい通信より正確には、上記ユーザキャラクタの送受信を伴うすれちがい通信。以下の説明では、すれちがい通信とはこのようなユーザキャラクタの送受信を伴うすれちがい通信のことを指すものとするで得られた他のユーザキャラクタについての処理として、以下のような処理が実行される。[新着通知]まず、新着通知の処理が行われる。具体的には、図5に示すように、今回の外出中に発生したすれちがい通信の回数が表示される。図5では、画面左側には自己が作成したユーザキャラクタ101が表示され、画面右側には、すれちがいで得られた他のユーザキャラクタ102の列が表示されている。また、画面上部の略中央に、今回のすれちがい回数を示すメッセージが表示されている。そして、他のユーザキャラクタ102の列から1体ずつ自己のユーザキャラクタ101に近づいてきてすれ違うようなアニメーションが表示される。その後、図6に示すような、今までに発生したユーザキャラクタの送受信を伴うすれちがい通信の合計回数が表示される。新着通知にかかる表示が終わると、次に、他のユーザキャラクタ毎に、以下のような処理が順に行われる。1相手側の自己紹介→2あいさつ処理→3相手側の近況報告等→4評価処理図7~図21は、これらの処理にかかる画面の一例である。例えば、図7においては、画面の左側に自己のユーザキャラクタ101が表示され、画面右側に、今回の外出中に発生したすれちがい通信で得られた他のユーザキャラクタ102が表示されている。このような画面を基本として、以下のような処理が実行される。[1相手側の自己紹介]まず最初に、1相手側の自己紹介が行われる。本実施形態では、図7に示すように、他のユーザの居住している地域と他のユーザの名前を自己紹介として表示する。この地域は、他のユーザキャラクタの送信元となったゲーム装置1の本体設定の一つとして記憶されている内容である。また、名前は、当該他のユーザキャラクタの作成者つまり、他のユーザがそのユーザキャラクタに対して任意に付けた名前である。また、この表示は、他のユーザキャラクタ102が話しているかのように見せるため、吹き出しを用いた表示がなされる。相手側の自己紹介が終わると、当該ユーザキャラクタ102が初対面となるユーザキャラクタであるときには、図8に示すように、はじめましてというメッセージが吹き出しを用いて表示される。また、以前にすれちがい通信で取得した実績がある他のユーザキャラクタの場合は、図9に示すように、すれ違った回数を示すメッセージが表示される。[2あいさつ処理]次に、2あいさつ処理が行われる。この処理では、まず相手側から自分側へのあいさつが行われた後、自分側から相手側へのあいさつが行われる。以下では、他のユーザキャラクタ102が初対面である場合と、そうではない場合とに分けて説明する。[初対面の場合]現在の処理にかかる他のユーザキャラクタが初対面のユーザキャラクタである場合は、まず、相手側から自分側へのあいさつとして、図10に示すように、相手側が設定した共通あいさつが、他のユーザキャラクタ102が話している様子で表示される。その後、自分側から相手側へのあいさつとして、図11に示すように、ユーザ自身が設定した共通あいさつが、自己のユーザキャラクタ101が話している様子で表示される。これは、上記初期設定において作成された最長16文字のテキストメッセージである。[2度目以降の対面の場合]現在の処理にかかる他のユーザキャラクタ102が初対面のユーザキャラクタではない場合は、相手側から自分側へのあいさつとしては、図12に示すように、相手側が設定した共通あいさつ、あるいは、個別あいさつが表示される。いずれが表示されるかは、相手側がいずれのあいさつを行ったかによる。ここで、相手側のあいさつが個別あいさつの場合は、その個別あいさつの基となった自分側のあいさつの内容も共に表示される図13参照。具体的には、まず、自分側のあいさつの内容が先に表示される。そして、このあいさつ内容に対して返事するように、相手側の個別あいさつが表示される。これは、相手側の個別あいさつの内容が、自分側のどのような内容のあいさつに対してのもの返事であるのかをユーザに把握させやすくするためである。それと同時に、自分側のユーザキャラクタ101と相手側のユーザキャラクタ102があたかも会話しているかのように見せることで、ユーザが他のユーザとコミュニケーションをとっている感覚をより高めている。次に、自分側から相手側へのあいさつとして、まず、図14に示すようなあいさつの種類を選択するあいさつ選択ウィンドウ105が表示される。図14ではみんな向けとこべつのの2つの選択肢が表示されている。これに対して、ユーザがみんな向けを選択すると、共通あいさつを選択したものとして扱われる。その結果、図15に示すように、自己の作成した共通あいさつが表示される。一方、ユーザがこべつのを選択したときは、個別あいさつを選択したとして扱われる。その結果、まず、個別あいさつとしてのテキストを入力するための画面図示は省略が表示される。この画面に対して、2バイト文字で16文字以内のテキストをユーザが所定の入力装置を用いて入力する。そして、入力が終われば、図16に示すような確認画面が表示される。この確認画面でユーザが了承すれば、図17に示すように、今入力した個別あいさつが表示される。以上で、現在の他のユーザキャラクタに対するあいさつ処理は終了する。ここで上記個別あいさつについては、その送信相手を特定する情報と共にすれちがい通信用の送信データとして適宜設定され、送信ボックスに格納される。そして、すれちがい通信によって送信される。なお、本実施形態では、個別あいさつの送信に関しては、とりあえず不特定多数の相手に送信を行うものとする。そして、受信した側で、自分宛の個別あいさつか否かを判断して振り分ける。なお、上述したあいさつ処理を行うか否かの設定項目において行わないと設定されている場合は、図10~図17にかかるあいさつ処理は省略される。[3相手側の近況報告等]あいさつ処理が終わると、次に、相手側からの近況報告等を示すメッセージがいくつか表示される。図示は省略するが、例えば、最近遊んだゲームが何かを示すメッセージ等が表示される。また、その他、趣味や好きな食べ物等、プロフィールについてのメッセージ等も表示される。[4評価処理]相手側の近況報告等を示すメッセージの表示が終われば、次に、評価処理が実行される。ここで、当該評価処理に関しては、個別あいさつの場合と同様に、2回以上すれちがい通信を行った相手にのみ可能となっている。つまり、初対面の相手に対しては評価処理は行われない。相手が初対面初めてすれ違った人である場合は、その時点では、再度会うすれ違う可能性については未知数であり、同じ人と2度とすれ違わない可能性も低くはない。一方、同じ人と2回目のすれちがい通信が発生した場合、比較的親しい間柄であると考えられることから、3回目以降のすれちがい通信が行われることが期待できる。そのため、再度すれ違う可能性が高い相手に対してのみ評価処理を行うようにして、無駄な評価作業を減らそうとするものである。まず、図18に示すような、他のユーザキャラクタの外観に対するユーザの評価の選択画面が表示される。図18では、他のユーザキャラクタ102の問いかけメッセージと共に、評価選択ウィンドウ107にふつうかなおよびすごくいいという2つの選択肢が表示されている。ここでは、すごくいいのほうが高評価であるとする。ユーザは、この選択肢から一方を選択する。すると、その選択肢に応じた所定のメッセージが、他のユーザキャラクタ102が話しているかのように表示される。例えば、すごくいいが選ばれたときは、図19に示すように、喜びを示すようなメッセージが表示される。なお、本実施形態では、評価の方法として、2つの予め記憶されているメッセージのうち1つのメッセージを選択することにより評価を行うようしているが、これに限られず、ユーザのテキスト入力により評価を行うようにしていてもよい。ここで、上記2つの選択肢のうち、高評価のほうの選択肢が選ばれた場合は、その旨を示すデータがすれちがい通信用の送信データの一つとして設定される。そして、以後に発生するすれちがい通信において、高評価したことを示すデータも他の各種データと共に相手側に送信される。そして、受信した側において、自分宛の高評価のデータが含まれているか否かを判断し、含まれていれば、次に説明するような相手側から自分への評価として表示されることになる。つまり、高評価の場合は、高評価したということがその相手側に通知されることになるもちろん、同じユーザとすれ違うことが前提である。また、この評価処理に関しては、同じ相手ユーザキャラクタに対しては、原則として1度しか行えない。但し、同じ相手であっても、その外観が変更されていた場合は上記ユーザキャラクタ生成アプリで編集可能であるため、変更この外観について再度評価を行うことが可能となっている。自分側から相手側への評価が終われば、次に、相手側から自分への評価が表示される。これは、上記のように、相手側が自分に対して高評価を行っていた場合にのみ表示される。この場合は、図20に示すように、相手から自分への評価を示すメッセージが表示された後、図21に示すように、今までに高評価を受けた累計回数が表示される。一方、相手側が自分に対して高評価は行っていない場合例えば、上記選択肢でふつうかなを相手が選んでいた場合は、相手側から自分への評価にかかる処理は実行されないこととなる。以上のような、1相手側の自己紹介→2あいさつ処理→3相手側の近況報告等→4評価処理、の一連の処理が、すれちがい通信で取得した他のユーザキャラクタの数の回数分だけ繰り返された後、広場アプリのメイン画面が表示され、当該広場アプリのメインとなる処理が適宜実行される。このメインとなる処理については本実施形態の説明に直接関係しないため、説明は省略する。このように、本実施形態では、近距離無線通信であるすれちがい通信を用いてユーザキャラクタを収集すると共に、同じ相手と複数回すれちがい通信が発生している場合は、ユーザと親しい間柄の相手であるとして、上記個別あいさつのような特定の相手向けのあいさつを可能としている。また、他のユーザの作成したユーザキャラクタについて評価を行い、その評価結果について相手側に送信することも可能となっている。これにより、ゲーム装置を所持して外出するだけで上記の様なすれちがい通信によるユーザキャラクタの収集が可能となり、サーバ等が不要の比較的簡易な構成で、自己のユーザキャラクタを他のユーザに評価してもらい、フィードバックしてもらうことが可能である。また、上記のように何度かすれ違った相手に対しては個別あいさつという形で個別のメッセージを送信することができ、他のゲーム装置1を所持しているユーザとより親密なコミュニケーションを取っているプレイ感覚を提供することができる。次に、ゲーム装置1によって実行される広場アプリ等の処理の詳細を説明する。まず、各種処理の際に用いられる各種データについて説明する。図22は、ゲーム装置1の保存用データメモリ34のメモリマップを示す図である。図2において、保存用データメモリ34は、プログラム記憶領域301およびデータ記憶領域305を含む。プログラム記憶領域301およびデータ記憶領域305のデータは、広場アプリの実行時に、必要に応じてメインメモリ32に適宜転送されて使用される。プログラム記憶領域301は、CPU31によって実行される各種プログラムを記憶する。本実施形態では、すれちがい通信処理プログラム302と、ユーザキャラ生成アプリプログラム303と、広場アプリプログラム304などが記憶される。すれちがい通信処理プログラム302は、上述したようなスリープモードにおけるすれちがい通信を実行するためのプログラムである。ユーザキャラ生成アプリプログラム303は、上記ユーザキャラクタ作成アプリを実行するためのプログラムであり、広場アプリプログラム304は、上記広場アプリを実行するためのプログラムである。データ記憶領域305には、本体設定データ306等が記憶される。また、データ記憶領域305は、ユーザキャラクタ記憶領域307、すれちがい通信用データ領域308、アプリ用データ領域309を含んでいる。本体設定データ306は、主にゲーム装置1の本体に関する設定データである。図23は、本体設定データ306の構成の一例である。本体設定データ306は、ユーザ名データ311、地域データ312等から構成される。ユーザ名データ311は、ゲーム装置1の所有者つまり、ユーザの氏名のデータである。なお、ユーザ名データ311には、ユーザを一意に識別するためのユーザIDも含まれている。地域データ312は、ユーザによって設定されるデータであり、典型的には、ユーザの住んでいる地域を示すデータである。その他、本体設定データ306には、ネットワークに接続するための情報等も含まれる。図22に戻り、ユーザキャラクタ記憶領域307は、ユーザキャラクタを保存するための領域である。図24は、当該ユーザキャラクタ記憶領域307の構成の一例を示す図である。ユーザキャラクタ記憶領域307は、複数のユーザキャラクタデータ321の集合で構成されている。この領域には、ユーザ自身が作成したユーザキャラクタのデータの他、上記すれちがい通信で取得された、他のユーザによって作成されたユーザキャラクタも保存される。また、当該領域に保存されているユーザキャラクタは、上記広場アプリを含め、様々なアプリにおいて利用可能なデータである。各ユーザキャラクタデータ321は、ユーザキャラクタID322、ユーザキャラクタ名323、構成パーツ情報324、作成者ID325等から構成される。ユーザキャラクタID322は、ユーザキャラクタを一意に識別するためのIDである。本実施形態では、ゲーム装置本体に固有の番号例えばシリアルNo等も利用して、全世界でユニークなIDとなるように生成される。具体的には、ゲーム装置本体に固有の番号と、ユーザキャクタが作成された時点の日時を利用することでユーザキャラクタID322が生成される。ユーザキャラクタ名323は、各ユーザキャラクタに設定された名前であり、例えば、2バイト文字で10文字までの長さの文字列データである。構成パーツ情報324は、ユーザキャラクタを構成している各パーツを示す情報である上述したように、ユーザキャラクタは、目、鼻等に分類されているパーツの集まりで構成されている。作成者ID325は、ユーザキャラクタを作成した人の識別情報である。当該作成者ID325は、ゲーム装置本体に固有の番号を使用して生成される。その結果、作成者ID325は、ゲーム装置1毎に異なる識別情報となる。ユーザ自身が作成したユーザキャラクタであれば、上記本体設定データ306のユーザ名データ311が当該作成者情報325として記憶される。他のゲーム装置で作成されたユーザキャラクタであれば、そのユーザキャラクタを作成したユーザを示すデータ他のゲーム装置1におけるユーザ名データ311が作成者情報325となる。図22に戻り、すれちがい通信用データ領域308は、上記図3および図4で説明したような、すれちがい通信において用いられる各種データを格納するための領域である。図25は、当該すれちがい通信用データ領域308の構成の一例を示す図である。すれちがい通信用データ領域308には複数のスロット331本実施形態では計16スロットが含まれている。各スロットは、アプリID332、すれちがい送信データ333、のすれちがい受信データ334で構成されている。アプリID332は、当該スロットを使用する対応付けられているアプリケーションを識別するためのIDである。すれちがい送信データ333は、すれちがい通信において他のゲーム装置1に送信するためのデータである。図26は、すれちがい送信データ333の構成の一例を示す図である。図26において、すれちがい送信データ333は、送信用ユーザキャラクタデータ341、共通あいさつ文字列データ342、プロフィールデータ343、地域データ344、あいさつ処理実行フラグ345、評価処理実行フラグ346、個別あいさつデータ347、評価リスト352から構成されている。送信用ユーザキャラクタデータ341は、すれちがい通信において送信する対象となるユーザキャラクタのデータである。上記複数のユーザキャラクタデータ321のうちから、ユーザによって選ばれた1体分のユーザキャラクタデータ321あるいは、このデータを特定するための情報が送信用ユーザキャラクタデータ341として記憶される。共通あいさつ文字列データ342は、上述したような共通あいさつを示す文字列データである。プロフィールデータ343は、上記広場アプリにおいて、あいさつ処理の後に行われる相手側の近況報告等で用いられるデータである。すれちがい通信における送信先となった他のゲーム装置1上で相手側の近況報告等が実行される際に、当該プロフィールデータ343の内容が用いられることになる。地域データ344は、上記本体設定データ306の地域データ312がコピーされたものである。あいさつ処理実行フラグ345は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、あいさつ処理を行うことを許可することを示す。オフに設定されているときは、あいさつ処理を行うことを許可しないことを示す。評価処理実行フラグ346は、上述したような評価処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、評価処理を行うことを許可することを示す。オフに設定されているときは、評価処理を行うことを許可しないことを示す。個別あいさつデータ347は、上述したような個別あいさつに関するデータであり、直近の16件分の個別あいさつのデータが記憶されている。個別あいさつ1件分のデータは、宛先ユーザキャラID348、個別あいさつ文字列データ349、引用あいさつ文字列データ350、引用あいさつ種別フラグ351で構成される。宛先ユーザキャラID348は、個別あいさつを行った対象である相手のユーザキャラクタを特定するためのデータであり、上記ユーザキャラクタID322に対応する。個別あいさつ文字列データ349は、個別あいさつの内容を示す文字列データである。引用あいさつ文字列データ350は、当該個別あいさつを生成した際の、他のユーザキャラクタからのあいさつの内容である。例えば、他のユーザキャラクタが行ったまたあったね、元気というあいさつに対して、元気だよ。という個別あいさつを返す場合を想定する。この場合、上記個別あいさつ文字列データ349には元気だよ。という文字列のデータが格納され、引用あいさつ文字列データ350には、またあったね、元気という文字列のデータが格納されることになる。引用あいさつ種別フラグ351は、上記引用あいさつ文字列データ350として格納される、他のユーザキャラクタからのあいさつの種類が共通あいさつであるか個別あいさつであるかを示すフラグである。例えば、この値が0であれば共通あいさつ、1であれば、個別あいさつであることを示す。以上のようなデータで構成される個別あいさつのデータが最大で16件まで個別あいさつデータ347に記憶される。なお、新たに当該データを格納する際に既に16件まで埋まっている場合は、古いものが1件分消去されてから格納される。評価リスト352は、当該すれちがい送信データの作成元のユーザつまり、送信者が高評価したユーザキャラクタを示すデータである。直近に高評価したユーザキャラクタのユーザキャラクタID353が、最大で32件分まで格納される。図25に戻り、すれちがい受信データ334は、すれちがい通信において他のゲーム装置1から受信したデータである。ここには、上記すれちがい送信データ333と同様の構成を有する受信データ335が複数件格納される。そのため、各受信データ335については説明を省略する。なお、すれちがい送信データ333と受信データ335の構成が同じであるため、以下の説明では、これらのデータの参照符号の末尾にSまたはRを付加することで、すれちがい送信データ333と受信データ335のいずれに含まれるデータであるかを区別する。例えば、送信用ユーザキャラクタデータ341Sは、すれちがい送信データ333に含まれている送信用ユーザキャラクタデータ341であることを示し、送信用ユーザキャラクタデータ341Rは、受信データ335に含まれている送信用ユーザキャラクタデータ341であることを示す。また、その他のデータについても、末尾にRをつけたデータについては、受信データ335に含まれているデータつまり、すれちがい通信によって受信したデータに含まれているデータであることを示すものとする。図22に戻り、アプリ用データ領域309は、ゲーム装置1で実行される各種アプリケーションで用いられるデータを記憶する領域である。図27は、当該アプリ用データ領域309の構成の一例を示す図である。当該領域には、各アプリ毎に論理的に分けられて、各アプリにおいて用いられる各種データが記憶される。図27の例では、広場アプリ用データ361と、ユーザキャラ生成アプリ用データ366と、その他のアプリ用データ367が示されている。ここでは主に、広場アプリ用データ361の内容について説明する。広場アプリ用データ361は、アプリID362、アプリセーブデータ363、受信ユーザキャラ情報保存データ364等で構成される。アプリID362は、当該広場アプリを識別するためのIDである。上述のようなすれちがい通信に用いるスロットとの関連付けに用いられる。アプリセーブデータ363は、広場アプリに関する各種設定等を記憶したデータである。図28は、アプリセーブデータ363の構成の一例を示す図である。図28において、アプリセーブデータ363は、すれちがい用ユーザキャラクタデータ371、共通あいさつ文字列データ372、プロフィールデータ373、あいさつ処理実行フラグ374、評価処理実行フラグ375、個別あいさつデータ376、評価リスト377、受けた評価データ378から構成される。また、図示は省略するが、広場アプリに関してすれちがい通信を利用するかか否かつまり、すれちがい通信を行うか否かの設定や、すれちがい通信の累計数等のデータもアプリセーブデータ363に含まれる。すれちがい用ユーザキャラクタデータ371は、すれちがい通信における送信対象として設定したユーザキャラクタのデータである。共通あいさつ文字列データ372は、上述したような共通あいさつを示す文字列データである。プロフィールデータ373は、上述したような相手側の近況報告等で用いられるデータである。あいさつ処理実行フラグ374は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。また、評価処理実行フラグ375は、上述したような評価処理を行うことを許可するか否かを示すフラグである。その内容は、上記すれちがい送信データ333におけるあいさつ処理実行フラグ345および評価処理実行フラグ346と同様である。個別あいさつデータ376は、直近の16件分の個別あいさつについてのデータである。その構成は、上記すれちがい送信データ333における個別あいさつデータ347と同様である。評価リスト377は、自分が高評価を与えた他のユーザキャラクタのユーザキャラクタIDのリストであり、最大で直近の32件分まで保存される。その構成は、上記すれちがい送信データ333における評価リスト352と同様である。受けた評価データ378は、自己の作成したユーザキャラクタに対して高評価を行った他のユーザについてのデータであり、本実施形態では、最大で100件分の評価者情報379が記憶される。各評価者情報379は、評価対象ユーザキャラクタID380と、評価した作成者情報381で構成されている。評価対象ユーザキャラクタID380は、自己の作成したユーザキャラクタであって、高評価を受けた評価の対象となったユーザキャラクタのIDである。評価した作成者情報381は、高評価を与えた他のユーザを示す情報であり、他のゲーム装置1から受信した作成者情報325Rが当該評価した作成者情報381として記憶される。例えば、ユーザAが2体のユーザキャラクタAおよびBを作成したとする。この2体を、すれちがい通信に用いるユーザキャラクタを適宜変更することで、ユーザBの所持するゲーム装置と、ユーザCが所持するゲーム装置に送信した場合を想定する。そして、ユーザキャラクタAについては、他のユーザBおよびCから高評価をされたが、ユーザキャラクタBについては、他のユーザCからしか高評価がなされなかった場合を想定する。このような場合は、受けた評価データ378としては、<ユーザキャラクタAのIDユーザBの作成者情報>と、<ユーザキャラクタAのIDユーザCの作成者情報>と、<ユーザキャラクタBのIDユーザCの作成者情報>の3件分の情報となる。図27に戻り、受信ユーザキャラ情報保存データ364は、すれちがい通信によって他のゲーム装置1から受信したユーザキャラクタに関するデータである。図29は、受信ユーザキャラ情報保存データ364の構成の一例を示す図である。図29において、受信ユーザキャラ情報保存データ364には、1000体分の受信ユーザキャラ391が記憶される。各受信ユーザキャラ391は、ユーザキャラデータ392、プロフィールデータ393、すれちがい回数394、前回すれちがい日時395、地域データ396、評価処理実行フラグ397で構成されている。ユーザキャラデータ392は、上記受信データ335に含まれている送信用ユーザキャラクタデータ341Rがコピーされたものである。同様に、プロフィールデータ393は、上記受信データ335に含まれているプロフィールデータ343Rがコピーされたものである。すれちがい回数394は、当該受信したユーザキャラクタの送信元のゲーム装置1との間で、上記のようなすれちがい通信が行われた回数を示すデータである。前回すれちがい日時395は、上記受信したユーザキャラクタの送信元のゲーム装置1とすれちがい通信が最後に行われた日時を示すデータである。地域データ396は、上記受信データ335に含まれている地域データ344Rがコピーされたものである。評価処理実行フラグ397は、上記受信データ335に含まれている評価処理実行フラグ346Rがコピーされたものである。つまり、当該受信したユーザキャラクタの作成者が、このキャラクタが評価されることを望んでいるか否かを示すフラグである。以下、ゲーム装置1が行う広場アプリについての処理の詳細動作を説明するが、広場アプリの詳細動作の説明に先立って、上述したすれちがい通信にかかる具体的な処理の流れについて簡単に説明する。図30は、本実施形態にかかるすれちがい通信の処理の詳細を示したフローチャートである。このフローにかかる処理は、ゲーム装置1がスリープモードすれちがい通信モード中のときに実行される。まず、ステップS1において、ビーコン信号が発信される。このビーコン信号は、ゲーム装置同士のローカル通信確立のきっかけとなるような情報が含まれている。次に、ステップS2において、他のゲーム装置から発信されたビーコンの存在を検出する。次に、ステップS3において、上記ビーコンの検出の結果、ビーコンが検出できたか否か、つまり、自機の通信可能範囲内に他のゲーム装置1が存在するか否かが判定される。その結果、自機の通信可能範囲内に他のゲーム装置1が存在していないときはステップS3でNO、後述のステップS9に処理が進められる。一方、自機の通信可能範囲内に他のゲーム装置1が存在するときはステップS3でYES、ステップS4において、ローカル通信を確立するための処理が実行される。ローカル通信が確立すれば、ステップS5において、通信相手となったゲーム装置1との間で、共通するアプリID332を有するスロット331があるか否かが判定される。つまり、すれちがい通信において送受信すべきデータが在るか否かが判定される。その結果、共通するアプリID332を有するスロット331がないときはステップS5でNO、後述のステップS8に処理が進められる。一方、共通するアプリID332を有するスロット331が存在するときはステップS5でYES、ステップS6において、当該スロット331にかかるすれちがい送信データ333が他のゲーム装置1に送信される。同時に、他のゲーム装置1から送信されてくるすれちがい送信データ333が、すれちがい受信データ334の受信データ335として格納される。次に、ステップS7において、上記データの送受信が完了したか、または、ローカル通信が強制的に切断されたかすれちがい通信が完了する前に、通信可能範囲外にユーザが移動したような場合等が判定される。その結果、データの送受信が未完了であり、ローカル通信も切断されていなければステップS7でNO、上記ステップS6に戻り、データの送受信が継続される。一方、送受信が完了、または、ローカル通信が強制切断されたときはステップS7でYES、ステップS8において、ローカル通信を終了するための処理が実行される。データの送受信が完了した場合は、通信を切断することで、すれちがい通信を正常終了させるための処理が実行される。また、送受信完了前にローカル通信が強制切断されていた場合は、それまでに受信したデータをクリアし、すれちがい通信が始まる前の状態に戻す処理が行われる。次に、ステップS9において、スリープモードを終了させる指示がなされたか否かが判定され、終了指示がなされていないときはステップS9でNO、上記ステップS1に戻り、処理が繰り返される。一方、終了指示がなされたときはステップS9でYES、すれちがい通信処理が終了される。以降、ゲーム装置1が通常モードで動作することで、以下に説明するような処理が実行されることになる。次に、ゲーム装置1で実行される広場アプリの処理の詳細について説明する。この処理は、ゲーム装置1のホームメニューから広場アプリの実行指示がユーザによって行われることで開始される。例えば、ホームメニューの中から、広場アプリに対応するアイコン画像をユーザが選択して所定のボタンを押下したときに開始される。図31は、広場アプリの処理の詳細を示すフローチャートである。まず、図31において、広場アプリが起動されると、保存用データメモリ34からメインメモリ32への必要なファイルのロード等の初期処理が適宜実行される。その後、ステップS11において、ユーザキャラクタ記憶領域307が参照され、作成済みのユーザキャラクタ101が1体以上存在するか否かが判定される。当該判定の結果、ユーザキャラクタ101が1体も作成されていないときはステップS11でNO、ステップS12において、ユーザキャラクタの作成を促すメッセージが表示される。そして、広場アプリ処理は終了する。つまり、ユーザキャラクタが未作成の状態では、広場アプリは実質的に利用できないことになる。一方、ユーザキャラクタ101が1体以上作成済みであるときはステップS11でYES、次に、ステップS13において、広場アプリが初回起動であるか否かつまり、今まで一度も実行されたことが無いか否かが判定される。その結果、初回起動のときはステップS13でYES、ステップS14において、広場アプリ初期設定処理が実行される。この処理は、すれちがい通信で用いるユーザキャラクタの選択等、広場アプリを利用するために必要な各種設定を行うための処理である。一方、初回起動ではないときはステップS13でNO、広場アプリ初期設定処理はスキップされて、後述のステップS15に処理が進められる。図32は、上記ステップS14で示した広場アプリ初期設定処理の詳細を示すフローチャートである。図32において、まず、ステップS21で、広場アプリの簡単な紹介と説明が表示される。続くステップS22において、ユーザとの対話形式ですれちがい通信に関する設定を行う処理が実行される。具体的には、すれちがい通信を行うか否か、あいさつ処理を行うか否か、評価処理を行うか否か、等について、対話形式を用いて設定される。その結果、ユーザの入力内容に応じて、上記すれちがい通信用データ領域308のいずれかのスロット331と広場アプリとを関連づける処理が実行される。更に、ユーザキャラクタ記憶領域307から、すれちがい通信で用いるユーザキャラクタがユーザの入力内容に基づいて選択され、アプリセーブデータ363のすれちがい用ユーザキャラクタデータ371として保存される。また、アプリセーブデータ363のあいさつ処理実行フラグ374および評価処理実行フラグ375も、ユーザの入力内容に応じて適宜設定される。次に、ステップS23において、プロフィールデータ373作成の元となる質問が適宜表示され、これに対するユーザの入力内容に応じて、プロフィールデータ373が適宜設定される。次に、ステップS24において、共通あいさつを生成するための処理が実行される。具体的には、共通あいさつとしての文字列を入力するための画面が表示される。これに対して、ユーザによって入力された所定の文字列が共通あいさつ文字列データ372として記録される。以上で、広場アプリ初期設定処理は終了する。図31に戻り、次に、ステップS15において、広場アプリメイン処理が実行される。図33~図38は、当該広場アプリメイン処理の詳細を示すフローチャートである。図33において、まず、ステップS41で、アプリセーブデータ363が参照され、広場アプリですれちがい通信を行う設定がなされているか否かが判定される。その結果、すれちがい通信を行わない旨の設定が成されているときはステップS41でNO、後述するステップS80に処理が進められ、広場アプリのメイン画面が表示されることになる。一方、すれちがい通信を行う旨の設定がなされているときはステップS41でYES、次に、ステップS42において、すれちがい通信用データ領域308が参照され、今回の直近のスリープモード中においてすれちがい通信が発生したか否かが判定される。例えば、すれちがい受信データ334の内容が空であるか否かで判定される。当該判定の結果、すれちがい通信が発生していないときはステップS42でNO、続くステップS43で、アプリセーブデータ363が参照されて、すれちがい通信の累計回数が0か否かが判定される。その結果、すれちがい通信の回数が0のときはステップS43でNO、他のユーザキャラクタを1体も受信していない状態であると考えられるため、ステップS44において、ユーザにすれちがい通信を行わせることを支援するためのメッセージ例えば、人の集まるところですれちがい通信をしてみようが表示される。その後、後述のステップS80に処理が進められる。一方、直近のスリープモード中においてすれちがい通信が発生していたときはステップS42でYES、少なくとも1体は他のユーザキャラクタを受信していると考えられるため、新着通知にかかる処理が実行される。具体的には、ステップS45において、上記図5を用いて説明したような画面を用いて、今回のすれちがい通信においてすれ違った回数受信した他のユーザキャラクタの数が表示される。その後、当該回数が、累計すれちがい回数を示すデータ図示は省略に加算されて、上記図6で示したような画面が生成されて表示される。また、当該加算後の累計すれちがい回数はアプリセーブデータ363の一部として記憶される。新着通知にかかる処理が終われば、次に、受信された各ユーザキャラクタについての処理が実行される。まず、ステップS46において、すれちがい受信データ334が参照されて、処理対象となるユーザキャラクタ受信データ335が古い順に1件選択されて読み出される。以下、当該選択されたユーザキャラクタを処理対象キャラクタと呼ぶ。次に、ステップS47において、処理対象キャラの自己紹介を表示する処理が行われる。具体的には、受信データ335その構成は上記図26で示したすれちがい送信データ333と同様であるの送信用ユーザキャラクタデータ341Rが参照され、これに含まれているユーザキャラクタ名323Rが取得される。また、受信データ335の地域データ344Rが参照されることで、地域名も取得される。そして、これらのデータに基づき、地域と名前を表示した自己紹介画面上記図7参照が生成されて表示される。次に、図34のステップS48において、処理対象キャラクタが初対面となるユーザキャラクタか否かが判定される。初対面か否かは、例えば、当該処理対象キャラクタのユーザキャラクタID322Rを基にして受信ユーザキャラ情報保存データを検索し、検索できたか否かで判定される検索できなかった場合は初対面となる。当該判定の結果、初対面であるときはステップS48でYES、ステップS49において、初対面処理が実行される。図35は、当該初対面処理の詳細を示すフローチャートである。まず、ステップS101において、初対面用のあいさつが表示される。当該初対面用のあいさつは、予め定義されている文字列である。ここでは、上記図8で示したような、はじめましてというあいさつが表示される。次に、ステップS102において、あいさつ処理の実行に関してお互いに許可されているか否かが判定される。例えば、まず、アプリセーブデータ363のあいさつ処理実行フラグ374が参照され、自分側のあいさつ処理の実行許可が設定されているか否かが判定される。その結果、許可されていなければ、当該ステップS102の判定結果はNOとなる。許可されていれば、次に、処理対象キャラクタのあいさつ処理実行フラグ345Rが参照され、相手側のあいさつ処理の実行許可が設定されているか否かが判定される。ここで許可されていないときは、当該ステップS102の判定結果はNOとなる。許可されているときは、当該ステップS102の判定結果はYESとなる。ステップS102の判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときはステップS102でNO、後述のステップS105に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されていればステップS102でYES、ステップS103において、受信データ335の共通あいさつ文字列データ342Rが参照され、処理対象キャラクタにかかるつまり、相手側の共通あいさつが表示される。次に、ステップS104において、アプリセーブデータ363の共通あいさつ文字列データ372が参照され、ユーザ自身が作成したつまり、自分側の共通あいさつが表示される。つまり、初対面のときは、個別あいさつは一切用いられないことになる。次に、ステップS105において、処理対象キャラクタにかかる近況報告の処理が実行される。これは、受信データ335のプロフィールデータ343Rが参照されることで、その内容を反映したメッセージが生成されて表示される処理である。以上で、初対面処理は終了する。図34に戻り、初対面処理が終わると、後述するステップS78に処理が進められ、次の他のユーザキャラクタにかかる処理に移行することになるつまり、初対面時は、評価処理はなされないことになる。一方、図34のステップS48の判定の結果、初対面のキャラクタではないときはステップS48でNO、次に、ステップS50において、処理対象キャラクタとの遭遇回数すれちがい通信が行われた回数を表示する処理が実行される。具体的には、受信ユーザキャラ情報保存データ364が参照され、処理対象キャラクタにかかるすれちがい回数394が取得される。そして、この回数に1を加算した値に基づいて上記図9で示したような画面が生成されて表示される。また、この加算後の値は、当該処理対象キャラクタにかかるすれちがい回数394として記憶される。次に、ステップS51において、あいさつ処理を行うか否かが判定される。すなわち、双方ともにあいさつ処理の実行許可が設定されているか否かが判定される。当該判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときはステップS51でNO、後述のステップS67に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されているときはステップS51でYES、ステップS52において、処理対象キャラクタ相手側のあいさつの種類が共通あいさつか否かかが判定される。具体的には、まず、処理対象キャラクタにかかる受信データ335の個別あいさつデータ347Rが参照され、自分側のユーザキャラクタのユーザキャラクタID322と一致する宛先ユーザキャラID348Rが検索される。その結果、検索できた場合は、相手側のあいさつは個別あいさつであり、見つからなかった場合は、相手側のあいさつは共通あいさつであると判定される。ステップS52の判定の結果、処理対象キャラクタ側のあいさつが共通あいさつであるときはステップS52でYES、ステップS53において、処理対象キャラクタにかかる受信データ335の共通あいさつ文字列データ342Rに基づいて、処理対象キャラクタ側の共通あいさつが表示される。次に、ステップS54において、処理対象キャラクタとのすれちがい回数が2回目であるか否かが判定される。例えば、受信ユーザキャラ情報保存データ364が参照され、処理対象キャラクタに対応する受信ユーザキャラのデータが存在するか否かが判定される。そして、存在していれば、すれちがい回数394が参照され、2回目を示すデータが格納されているときは、今回、2回目のすれちがいが行われたと判定される。このような判定の結果、すれちがい回数が2回目のときはステップS54でYES、ステップS55において、個別あいさつが送信可能となった旨のメッセージを表示する。次に、ステップS56において、上記図14で示したような、あいさつ選択ウィンドウ105に表示する内容の設定が行われる。ここでは、上記図14で示されているようなみんな向けとこべつのという2つの選択肢が設定される。その後、後述するステップS61に処理が進められる。一方、上記ステップS54の判定の結果、2回目ではないつまり、3回目以上のときはステップS54でNO、上記ステップS55の処理はスキップされる。次に、上記ステップS52の判定の結果、処理対象キャラクタ側のあいさつが共通あいさつではないときステップS52でNO、つまり、個別あいさつであるときの処理について説明する。このときは、上記図13で示したような、相手側の個別あいさつと、これの基になった自分側のあいさつの文字列を示す画面を表示するための処理が実行される。まず、図36のステップS57において、処理対象キャラ側の個別あいさつデータ347Rが参照され、引用あいさつ文字列データ350Rが取得される。そして、当該データで示される文字列、つまり、前回のすれちがい時に自分側が行ったあいさつ内容が表示される。続いて、ステップS571において、同じく処理対象キャラ側の個別あいさつデータ347Rが参照され、自分宛の個別あいさつ文字列データ349Rが取得される。そして、当該データに基づき、相手側の個別あいさつが表示される。その結果、まず、前回すれちがい時に自分側が行ったあいさつが表示され、これに答えるように、相手側の個別あいさつが次に表示されることになる。このように、自分側のあいさつと相手側のあいさつを順番に表示することで、自分側のユーザキャラクタ101と相手側のユーザキャラクタ102とがあたかも会話しているかのような表現が行われることになる。。次に、ステップS58において、処理対象データにかかる受信データ335の引用あいさつ種別フラグ351Rが参照され、当該処理対象キャラクタと前回すれちがい通信が行われた際に、自分側が送ったあいさつの種類が個別あいさつであったか否かが判定される。その結果、前回送ったあいさつが個別あいさつのときはステップS58でYES、ステップS59において、あいさつ選択ウィンドウ105の内容が設定される。ここで設定される内容は、上記図14で示したようなあいさつ選択ウィンドウ105の内容となる。一方、前回送ったあいさつが共通あいさつのときはステップS58でNO、ステップS581において、引用あいさつ文字列データ350Rと共通あいさつ文字列データ372とが参照され、その内容が一致するか否かが判定される。その結果、一致していないときはステップS581でNO、上記ステップS59に処理が進められる。一方、一致しているときはステップS581でYES、次のステップS60において、あいさつ選択ウィンドウ105の内容が設定されるが、ここで設定される内容は、図39に示すような、個別あいさつをするかしないかを問い合わせるような内容となる。これは、共通あいさつで同じあいさつを複数回行ってしまうことを防止するため、共通あいさつに対する相手側の個別あいさつに対して個別あいさつを返すことを促すためである。また、上記ステップS581の判定は、前回すれちがい通信が行われた後、共通あいさつの文字列がユーザによって変更され、更にその後に同じ相手とすれちがい通信が行われた場合を想定したものである。つまり、ある相手に一旦共通あいさつを送った後、共通あいさつの文字列をユーザが変更した場合は、その後同じ相手に共通あいさつを送ったとしても、そのあいさつ内容は別の文字列となっているため、同じ文字列の共通あいさつが連続して行われることにはならない。このような、共通あいさつの変更が行われたか否かを判別するために上記ステップS581の判定が行われている。図36に戻り、次に、ステップS61において、上記ステップS59またはステップS60で設定された内容であいさつ選択ウィンドウ105が生成されて表示される。そして、当該選択ボックスに対するユーザからの入力が受け付けられる。次に、ステップS62で、上記あいさつ選択ウィンドウ105に対するユーザの選択内容が個別あいさつを選択したものであるか否かが判定される。当該判定の結果、個別あいさつが選択されていないときはステップS62でNO、ステップS63において、共通あいさつ文字列データ372に基づいた共通あいさつが表示される。そして、後述のステップS67に処理が進められる。一方、個別あいさつが選択されたときはステップS62でYES、ステップS64において、個別あいさつを作成する処理が実行される。具体的には、文字列入力画面が表示され、ユーザからの文字列入力が受け付けられる。ユーザからの文字列入力が終われば、確認メッセージが表示され上記図16参照、入力内容が確定すれば、次のステップS65において、当該入力された文字列データに基づき、上記図17で示したように、上記ユーザの入力した個別あいさつが表示される。次に、ステップS66において、アプリセーブデータ363の個別あいさつデータ376が更新される。具体的には、現在の処理対象キャラクタを示すユーザキャラクタID322Rが、アプリセーブデータ363の個別あいさつデータ376に含まれる宛先ユーザキャラIDとして記憶される。また、上記入力が確定した文字列のデータが個別あいさつ文字列データとして記憶され、現在の処理対象キャラクタ側のあいさつの文字列データが引用あいさつ文字列データとして記憶され、現在の処理対象キャラ側のあいさつの種別を示すデータが引用あいさつ種別フラグとして記憶される。以上で、あいさつ処理は終了する。次に、図37のステップS67において、相手側の近況報告処理が行われる。相手側の近況報告処理が終われば、次に、評価処理が行われる。まず、ステップS68において、自分側と相手側の双方ともに評価処理の実行許可が設定されているか否かが判定される。これは、相手側と自分側の評価処理実行フラグが参照されることで判定される。当該判定の結果、少なくとも一方で評価処理の実行許可が設定されていないときはステップS68でNO、後述のステップS78に処理が進められる。一方、双方ともに評価処理の実行許可が設定されているときはステップS68でYES、ステップS69において、処理対象キャラクタについて既に評価済みであるか否かが判定される。これは、まず、処理対象キャラとのすれちがい回数が2回目か否かが判定され、2回目であれば、まだ評価していないと判定される。一方、3回目以降であるときは、更に、受信ユーザキャラ情報保存データ364に保存されている処理対象キャラクタのユーザキャラデータ392と、受信データ335における送信用ユーザキャラクタデータ341Rとが比較され、ユーザキャラクタの外見が一致するか否かが判定される。その結果、外観に違いがあるときは、新たな外観についての評価はまだ行われていないとして、まだ評価していないと判定される。3回目以降であって、前回から外観に変化がないときは、評価済みであると判定される。なお、例えば2回目のすれちがいにおいて、相手側の評価処理実行フラグ346Rが許可しない設定であり、3回目のすれちがいにおいて、相手側の評価処理実行フラグ346Rが許可する設定となっていた場合であっても、2回目と3回目とで処理対象キャラの外観に変化がないときは、評価済みであると判定される。ステップS69の判定の結果、既に評価済みであるときはステップS69でYES、後述のステップS75に処理が進められる。一方、まだ評価していないときはステップS69でNO、ステップS70において、上記図18で示したような画面が表示される。すなわち、2つの選択肢高評価/普通を有する評価選択ウィンドウ107が表示される。そして、ユーザからの入力が受け付けられる。次に、ステップS71において、ユーザの入力内容に応じた処理対象キャラクタのリアクションが表示される上記図19参照。また、上記受信ユーザキャラ情報保存データ364に保存されている処理対象キャラのユーザキャラデータ392の内容が受信後のデータ内容に基づいて適宜更新される。次に、ステップS72において、上記ユーザの入力にかかる内容が、高評価にかかる内容であるか否かが判定される。その結果、高評価であったときはステップS72でYES、ステップS73において、次回すれ違ったときに、当該処理対象キャラの送信元のゲーム装置1に評価が送信される旨の通知メッセージが表示される。次に、ステップS74において、アプリセーブデータ363のうち、上記評価処理に関するデータが適宜更新される。具体的には、アプリセーブデータ363の評価リスト377に処理対象キャラのユーザキャラクタIDが保存される、このとき、当該IDが重複していれば、古い方のIDは削除される。また、既に32件登録されている状態であれば、一番古いデータが削除されてから保存される。一方、上記ステップS72の判定の結果、高評価ではなかったときはステップS72でNO、当該ステップS73およびステップS74の処理はスキップされる。次に、図38のステップS75において、相手側から自分への評価データがあるか否かが判定される。具体的には、まず、アプリセーブデータ363の受けた評価データ378が参照され、既に100件分の評価を受けているか否か既に100件登録されているか否かが判定される。その結果、100件未満のときは、次に、処理対象キャラクタにかかる受信データ335の評価リスト352Rから自分のユーザキャラクタすれちがい通信用として現在設定されているユーザキャラクタのユーザキャラクタIDが検索される。その結果、見つかったときは、自分への評価データがあると判定され、見つからなかったときは、自分への評価データがないと判定される。一方、受けた評価データ378に既に100件分の評価が保存されていれば、相手側から自分への評価データがある場合でも、評価データはないものとして判定される。つまり、既に100件分の評価があるときは、相手側からの評価に関する処理は実行されないことになる。ステップS75の判定の結果、相手側から自分への評価データがないときはステップS75でNO、後述のステップS78に処理が進められる。一方、自分への評価データがあるときはステップS75でYES、ステップS751において、受信データ335の評価リスト352RのユーザキャラID353R評価対象ユーザキャラクタID380に対応と受信データ335の送信用ユーザキャラクタデータ341Rにおける作成者ID325R評価した作成者情報381に対応の組み合わせが、受けた評価データ378に既に存在するかどうかが判定される。その結果、既に存在するときはステップS751でYES、この相手からは既に評価を受けていることになるため、後述のステップS78に処理が進められる。一方、存在しないときはステップS751でNO、この相手からはまだ評価を受けたことがないことになる。この場合は、続くステップS76において、相手側からの評価を表示する処理が実行される。すなわち、上記図20で示したような画面が表示される。次に、ステップS77において、高評価の累計数が表示される。具体的には、まず、今回評価された自分側のユーザキャラクタID322が、評価者情報379の評価対象ユーザキャラクタID380として記憶され、今回の処理対象キャラクタの作成者情報325Rが評価した作成者情報381として記憶される。そして、受けた評価データ378に含まれる評価者情報379の件数が高評価の累計数として算出される。つまり、当該累計数は、複数のユーザキャラクタが作成されている場合は、これら全てのユーザキャラクタに対する高評価の数を合計した値が用いられることになる。各ユーザキャラクタは、相手毎に評価が得られるため、例えば、ユーザキャラクタAが、2人の他のユーザから高評価を得ており、ユーザキャラクタBについては4人の他のユーザから高評価を得ているときは、高評価の累計数は6となる。これは、高評価の数を集めることを目的にさせることで、ユーザに様々なユーザキャラクタを作成させて楽しんでもらう事を促進するためである。そして、この累計数に基づいて、上記図21で示したような画面が生成されて表示される。なお、上記ステップS751の判定の結果、上記の組み合わせが既に存在するときに、上記ステップS76に処理を進めるようにしても良い。この場合は、高評価の累計数は更新しないようにしてもよい。つまり、既に評価を受けた相手については、その相手からの評価の表示のみを行い、累計数は加算しないようにしてもよい。以上で、評価処理は終了する。このようにしてあいさつ処理や評価処理が終了したユーザキャラクタにかかる受信データ335は、処理済みであるとして、すれちがい受信データ334からクリアされる。次に、ステップS78において、上述したような処理がまだ行われていない受信データ335が残っているか否かが判定される。その結果、まだ残っているときはステップS78でYES、上記ステップS46に戻り、処理が繰り返される。一方、全て処理したときはステップS78でNO、ステップS79において、上述した処理内容が反映されるようにすれちがい送信データ333が適宜更新される。すなわち、あいさつ処理における個別あいさつに関連するデータである個別あいさつデータ347Sや、評価処理に関する評価リスト352S等が適宜更新される。次に、ステップS80において広場メイン画面が表示され、続くステップS81において、その他の広場アプリの処理が実行される。続くステップS82において、広場アプリの終了指示がユーザから指示されたか否かが判定され、終了指示がなされていなければステップS82でNO、上記ステップS81の処理が繰り返され、終了指示がなされたときはステップS82でYES、当該広場アプリは終了され、ホームメニュー画面に戻ることになる。以上で、本実施形態にかかる広場アプリ処理の説明を終了する。このように、本実施形態では、最初は不特定多数に向けた共通あいさつを用いて不特定多数相手とのコミュニケーションを図りつつ、その中で複数回すれ違った相手に対しては、その相手を特定した個別あいさつが送信できるようにしている。これにより、他のユーザとの通信内容が画一的になることを防ぎ、よくすれ違う相手との親密度を高めることを可能として、上記のようなすれちがい通信による他人とのコミュニケーションの興趣性をより高めることが可能となる。換言すれば、すれちがい通信を繰り返すことで、親しくなれる可能性の高い他人を抽出し、その相手に対して個別にアプローチすることを可能とすることで、新たな友達を作る可能性を高めることができる。また、相手側の個別あいさつが表示される際、その個別あいさつの基になった自分側のあいさつ内容も合わせて表示されるようにしている。これにより、相手側のあいさつ相手側の反応内容が、自分が相手側に送ったどのようなあいさつに対してものであるかを把握させやすくすることができる。特に、上記のようなすれちがい通信によってあいさつが送受信される、換言すれば、あいさつ内容はリアルタイムにやりとりされるものではないため、このように過去に送ったあいさつ内容を表示することは効果的である。また、自己が作成したユーザキャラクタを、近距離無線通信であるすれちがい通信を用いて送信し、他のユーザに評価してもらうことが可能となっている。つまり、ユーザが生活する地域の近隣範囲内において、簡易なシステム構成によって自己の作成したユーザキャラクタを他人に評価してもらい、その結果をフィードバックしてもらうことが可能となる。これにより、自己のユーザキャラクタを他人に評価してもらうことを手軽にユーザに楽しんでもらうことが可能となる。その結果、複雑なシステム構成を用いることなく、他人とのコミュニケーションをより活発化させることが可能となる。また、評価については、高評価が行われたときにしか相手側にフィードバックしないようにしているため、ユーザが評価内容に不満を感じることを軽減して興趣性が下がってしまうことを防ぐことができる。更に、複数のユーザキャラクタを用いている場合、1つのユーザキャラクタについては原則評価は一回のみとする反面、各キャラクタに与えられた高評価の数を集計して表示するようにしている。そのため、よりたくさんの高評価を得るために、より多くのユーザキャラクタを生成し、より多くのすれちがい通信を行うことをユーザに促進させることが可能となる。なお、上記実施形態では、あいさつの内容については、文字列のみの場合を例に挙げたが、この他、ユーザが自由な表現で作成することができるものであれば、画像や音声なども含むようにしてもよい。また、ゲーム装置1上で作成されるものに限られず、外部の装置で作成されたものを利用可能としてもよい。また、その他、例えば、あいさつを表示するときに、ユーザキャラクタに所定のアクションを行わせるようにしてもよいエモーション動作等。この場合は、所定のアクションの内容を示すデータを上記共通あいさつや個別あいさつのデータに含めるようにすればよい。また、個別あいさつを作成するタイミングに関して、上記実施形態では、上記あいさつ選択ウィンドウ105でユーザが個別あいさつの作成を選択したときに、個別あいさつの入力画面に遷移するようにしていた。この他、個別あいさつについては、他のタイミングにおいても作成することができるようにしてもよい。例えば、広場アプリのメイン処理の機能の一つとして個別あいさつの作成と記憶が可能にしておき、ユーザは、この機能を用いて、いくつかの個別あいさつを作成し、ゲーム装置1に記憶させておく。その後、上記の様なあいさつ処理が行われ、上記あいさつ選択ウィンドウ105で、ユーザが個別あいさつの作成を選択したときは、入力画面は表示せずに、代わりに、上記の機能を用いて事前に作成しておいた個別あいさつを選択肢一覧として表示させる。そして、ユーザにこの中から個別あいさつを1つ選択させるようにすればよい。また、上記実施形態では、すれちがい通信はスリープモードのときに行われる場合を例に挙げたが、スリープモード以外の状態においても上記すれちがい通信が行われるように構成しても良い。また、上記実施形態では、送受信するゲーム装置1が共に携帯型ゲーム装置である場合を例に挙げたが、この他、いずれか一方は据置型ゲーム装置であってもよい。例えば、窓際に設置された据置型ゲーム装置と、その近くを通りがかったユーザの携帯型ゲーム装置との間で上記のようなすれちがい通信によりユーザキャラクタの送受信が行われてもよい。また、上記ユーザキャラクタに関して、上記実施形態では、ユーザキャラ作成アプリにおいてユーザが作成したユーザキャラクタをすれちがい通信用のユーザキャラクタに設定する場合を例に挙げていたが、この他、上記すれちがい通信によって取得された他のユーザキャラクタを、上記すれちがい通信用のキャラクタつまり、自分側から送信するユーザキャラクタとして設定できるようにしてもよい。また、上記実施形態においては、他のゲーム装置1から受信した評価データに基づく評価結果を画面に表示する場合を例に挙げていたが、この他、評価結果を音声や振動等を用いてユーザに報知させるようにしてもよい。また、上記実施形態においては、すれちがい通信によって受信した他のユーザキャラクタを利用したあいさつ処理や評価処理に関する一連の処理については単一の装置ゲーム装置1において実行される場合を説明したが、他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。