JP5020373B2 - 通信システム、情報処理プログラム、情報処理方法、情報処理装置、情報処理システム - Google Patents

Description

本発明は、通信システムや通信機能を利用する情報処理に関し、より特定的には、近距離無線通信を用いた通信システムや情報処理に関する。

従来から、投稿者が所有している画像や動画などのコンテンツをユーザ端末からサーバに送信し、投稿者以外のユーザがユーザ端末を操作して当該サーバにログインしてコンテンツを評価することにより、投稿者は様々なユーザからの総合的な評価結果が得られるシステムが知られている（例えば、特許文献１参照）。

特開２００９−１８１２６２号公報

上記特許文献１に記載されているシステムでは、不特定多数のユーザにより評価が行われるため、コンテンツを有するユーザ自身が生活する地域における他のユーザから当該コンテンツの評価を受けたい場合であっても、簡単なシステム構成で実現することは困難であった。

それ故に、本発明の目的は、自装置内に保有するデータに対する他人の評価を受けることができるシステムを、簡易な構成によって提供することである。

上記目的を達成するために、本発明は以下のような構成を採用した。

本発明にかかる通信システムは、複数の情報処理装置を含むシステムであり、情報処理装置はそれぞれ、送信手段と、受信手段と、評価データ生成手段とを備える。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信手段は、他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

上記構成により、近距離無線通信により他の情報処理装置へ自動的に送信したデータに対して当該他の情報処理装置のユーザにより評価が行われ、その評価結果を近距離無線通信により自動的に受信するため、ユーザは自装置内に保有するデータに対する他人の評価を簡易な構成で受けることができる。

本発明にかかる情報処理プログラムは、情報処理装置のコンピュータを、送信手段と、受信手段と、評価データ生成手段として機能させる。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信手段は、他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。このような構成において、更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

上記構成例により、近距離無線通信により他の情報処理装置へ自動的に送信したデータに対して当該他の情報処理装置のユーザにより評価が行われ、その評価結果を近距離無線通信により自動的に受信するため、ユーザは自装置内に保有するデータに対する他人の評価を簡易な構成で受けることができる。

他の構成例として、コンピュータを、他の情報処理装置の送信手段により送信された評価データで示される評価の内容を出力装置に出力させる出力制御手段としてさらに機能させてもよい。

上記構成例によれば、自装置内に保有するデータに対する他人の評価の内容を容易に把握することができる。

更に他の構成例として、表示制御手段は、評価データで示される評価の対象となったデータに基づく画像とともに、評価の結果を表示装置に表示させてもよい。

上記構成例によれば、評価されたものが何かをユーザに把握させやすくすることができる。

更に他の構成例として、コンピュータを、受信手段によって受信されるデータに含まれている評価データが、当該評価データの受信時より以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段と、宛先判別手段による判別結果が肯定である場合、当該評価データで示される評価の内容を表示装置に表示させる表示制御手段としてさらに機能させてもよい。

上記構成例によれば、受信側において自分宛の評価データを判別するため、送信側において送信先を判別する手間を省き、評価データの送信にかかる時間を短縮することができる。特に、他の情報処理装置とすれ違った際に近距離無線通信により短時間で通信を完了させることが要求される場面において、有用である。

更に他の構成例として、送信手段は、評価データ生成手段により評価データが生成された後、近距離無線通信の通信可能範囲に他の情報処理装置が含まれるようになったとき、当該評価データを自動的に送信してもよい。

上記構成例によれば、他人のデータ内容についての評価を当該他人に伝えるためにユーザに別途の作業を行わせずにすませることができる。

更に他の構成例として、評価データ生成手段は、送信手段による送信および受信手段による受信が可能でない状態に移行した後に評価データを生成し、送信手段は、送信手段による送信および受信手段による受信が可能である状態に移行した後に、評価データ生成手段により生成された評価データを送信するようにしてもよい。

上記構成例によれば、接続状態が維持されていない状態でも（つまり、接続中でなくても）、受信されたデータによって示されるデータ内容をユーザに評価させることができる。

更に他の構成例として、評価データ生成手段は、受信手段によって受信されたデータが、以前に当該受信手段によって受信した実績がある場合に、ユーザの操作に基づいて、当該データによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成するようにしてもよい。

上記構成例によれば、以前に受信したことがあるデータを再度受信した場合に評価が制限されるため、送信データを格納しておくために必要なメモリの容量を削減することができる。

更に他の構成例として、コンピュータを、受信手段により受信されたデータに基づいて示されるデータ内容に対しての当該ユーザの評価として、第１の評価と第２の評価を含む複数の評価選択肢を表示し、いずれか１つをユーザに選択させる選択肢表示手段として更に機能させ、評価データ生成手段は、ユーザに選択された選択肢が第１の評価を示す場合にのみ評価データを作成するようにしてもよい。

上記構成例によれば、例えば、高評価がなされたときにのみ評価データが作成されるようにすることができる。

更に他の構成例として、評価データ生成手段は、評価データとして、当該評価データが示す評価の対象となったデータの送信元を示す送信元データを生成し、送信手段は、評価データ生成手段により生成された送信元データを送信してもよい。更に、コンピュータを、受信手段によって受信されるデータに含まれる送信元データに基づいて、評価データが、当該評価データの受信時以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段としてさらに機能させ、出力制御手段は、宛先判別手段による判別結果が肯定である場合、第１の評価の内容を出力装置に出力させるようにしてもよい。

上記構成例によれば、通信データ量を削減し、より短時間で他機とのデータの送受信を完了させることが可能となる。

更に他の構成例として、データは、ユーザの操作に基づいて前記情報処理装置で作成されたユーザ作成データであってもよい。

上記構成例によれば、ユーザは自身が作成したコンテンツ等のデータに対する他人の評価を簡易な構成で受けることができる。

更に他の構成例として、少なくとも受信手段により受信されたデータが所定の条件を満たすか否かを判別する評価可否条件判別手段と、評価可否条件判別手段による判別結果が肯定である場合、評価データ生成手段により評価データが生成されるためのユーザの操作を許可する許可手段としてさらに機能させてもよい。

上記構成例によれば、所定の条件が満たされる場合にのみ評価が可能となるため、例えば、初対面のユーザや、評価されることを希望しないユーザに対しては評価できないようにして、ユーザの利便性を高めることも可能となる。

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに、当該データの内容に対してのユーザの評価を許可することを示す許可データが含まれているか否かを判別するようにしてもよい。

上記構成例によれば、例えば、評価されることを希望するユーザのみ評価データが作成され、評価されることを希望しないユーザに対しては評価データが作成されないようにして、ユーザの利便性を高めることも可能となる。

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに、当該データの内容に対するユーザの評価を許可することを示す第１許可データが含まれており、かつ、自装置に、データの内容に対するユーザの評価を許可することを示す第２許可データが設定されているか否かを判別する。

上記構成例によれば、評価対象となるデータの送信側と受信側の双方が評価する／されることを許可しているときにのみ当該データに対する評価が可能となるため、一方的に評価が行われることを防ぐことができる。

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに対して、評価データ生成手段により評価データが生成されていないか否かを判別するようにしてもよい。

上記構成例によれば、一度も評価していないデータについてのみユーザの評価を行うことを可能とすることができ、一度評価したデータと同じデータを再度受信したときに、当該データに対して再度評価を行わせてしまうことを防ぐことができる。

更に他の構成例として、評価可否条件判別手段は、受信手段により受信されたデータに対して、評価データ生成手段により評価データが生成されているときに、当該データの少なくとも一部が変更されているか否かを判別するようにしてもよい。

上記構成例によれば、一度評価したデータと同じデータを再度受信したか否かを判別し、同じデータであるときに、再度評価を行わせてしまうことを防ぐことができる。

更に他の構成例として、コンピュータを、評価データを取得した回数を累計する評価回数累計手段と、評価回数の累計を表示する累計表示手段として更に機能させてもよい。

上記構成例によれば、例えば、高評価を受けた回数のみを累計し、ユーザに伝えることが可能となる。

本発明にかかる情報処理方法は、送信ステップと、受信ステップと、評価データ生成ステップとを備える。送信ステップは、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信ステップは、他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成ステップは、ユーザの操作に基づいて、受信ステップにおいて受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。更に、送信ステップでは、評価データ生成ステップにおいて生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

本発明にかかる情報処理装置は、送信手段と、受信手段と、評価データ生成手段とを備える。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理装置に対してデータを自動的に送信する。受信手段は、近距離無線通信によって、不特定の他の情報処理装置の送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。このような構成において、更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

本発明にかかる情報処理システムは、送信手段と、受信手段と、評価データ生成手段とを備える。送信手段は、近距離無線通信による通信範囲内の他の情報処理装置を繰り返し探索して自動的に無線接続し、無線接続した他の情報処理システムに対してデータを自動的に送信する。受信手段は、近距離無線通信によって、不特定の他の情報処理システムの送信手段により送信されたデータを自動的に受信する。評価データ生成手段は、ユーザの操作に基づいて、受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する。このような構成において、更に、送信手段は、評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する。

本発明によれば、ユーザは自装置内に保有するデータに対する他人の評価を簡易な構成で受けることができる。

本実施形態にかかる広場アプリ等を実行するゲーム装置１の外観図 ゲーム装置１の内部構成の一例を示すブロック図 本実施形態における「すれちがい通信」について説明するための図 本実施形態における「すれちがい通信」について説明するための図 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 広場アプリの処理にかかる画面の一例 ゲーム装置１の保存用データメモリ３４のメモリマップを示す図 本体設定データ３０６の構成の一例 ユーザキャラクタ記憶領域３０７の構成の一例を示す図 すれちがい通信用データ領域３０８の構成の一例を示す図 すれちがい送信データ３３３の構成の一例を示す図 アプリ用データ領域３０９の構成の一例を示す図 アプリセーブデータ３６３の構成の一例を示す図 受信ユーザキャラ情報保存データ３６４の構成の一例を示す図 すれちがい通信の処理の詳細を示したフローチャート 広場アプリの処理の詳細を示すフローチャート 図３１のステップＳ１４で示した広場アプリ初期設定処理の詳細を示すフローチャート 広場アプリメイン処理の詳細を示すフローチャート 広場アプリメイン処理の詳細を示すフローチャート 広場アプリメイン処理の詳細を示すフローチャート 広場アプリメイン処理の詳細を示すフローチャート 広場アプリメイン処理の詳細を示すフローチャート 広場アプリメイン処理の詳細を示すフローチャート あいさつ選択ウィンドウ１０５の一例

以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。

図１は、本実施形態にかかる広場アプリケーション（以下、広場アプリ）等を実行するゲーム装置１の外観図である。ここでは、ゲーム装置１の一例として、携帯ゲーム装置を示す。図１において、ゲーム装置１は、折り畳み型の携帯ゲーム装置であり、開いた状態（開状態）のゲーム装置１を示している。ゲーム装置１は、開いた状態においてもユーザが両手または片手で把持することができるようなサイズで構成される。

ゲーム装置１は、下側ハウジング１１および上側ハウジング２１を有する。下側ハウジング１１と上側ハウジング２１とは、開閉可能（折り畳み可能）に連結されている。図１の例では、下側ハウジング１１および上側ハウジング２１は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回転可能に連結されている。通常、ユーザは、開状態でゲーム装置１を使用する。また、ユーザは、ゲーム装置１を使用しない場合には閉状態としてゲーム装置１を保管する。また、図１に示した例では、ゲーム装置１は、上記閉状態および開状態のみでなく、下側ハウジング１１と上側ハウジング２１とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング２１を下側ハウジング１１に対して任意の角度で静止させることができる。

下側ハウジング１１には、下側ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示装置）１２が設けられる。下側ＬＣＤ１２は横長形状であり、長辺方向が下側ハウジング１１の長辺方向に一致するように配置される。なお、本実施形態では、ゲーム装置１に内蔵されている表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置等、他の任意の表示装置を利用してもよい。また、ゲーム装置１は、任意の解像度の表示装置を利用することができる。なお、詳細は後述するが、下側ＬＣＤ１２は、主に、内側カメラ２３または外側カメラ２５で撮影されている画像をリアルタイムに表示するために用いられる。

下側ハウジング１１には、入力装置として、各操作ボタン１４Ａ〜１４Ｋおよびタッチパネル１３が設けられる。図１に示されるように、各操作ボタン１４Ａ〜１４Ｋのうち、方向入力ボタン１４Ａ、操作ボタン１４Ｂ、操作ボタン１４Ｃ、操作ボタン１４Ｄ、操作ボタン１４Ｅ、電源ボタン１４Ｆ、スタートボタン１４Ｇ、およびセレクトボタン１４Ｈは、上側ハウジング２１と下側ハウジング１１とを折りたたんだときに内側となる、下側ハウジング１１の内側主面上に設けられる。方向入力ボタン１４Ａは、例えば選択操作等に用いられる。各操作ボタン１４Ｂ〜１４Ｅは、例えば決定操作やキャンセル操作等に用いられる。電源ボタン１４Ｆは、ゲーム装置１の電源をオン／オフするために用いられる。図１に示す例では、方向入力ボタン１４Ａおよび電源ボタン１４Ｆは、下側ハウジング１１の内側主面中央付近に設けられる下側ＬＣＤ１２に対して、左右一方側（図１では左側）の当該主面上に設けられる。また、操作ボタン１４Ｂ〜１４Ｅ、スタートボタン１４Ｇ、およびセレクトボタン１４Ｈは、下側ＬＣＤ１２に対して左右他方側（図１では右側）となる下側ハウジング１１の内側主面上に設けられる。方向入力ボタン１４Ａ、操作ボタン１４Ｂ〜１４Ｅ、スタートボタン１４Ｇ、およびセレクトボタン１４Ｈは、ゲーム装置１に対する各種操作を行うために用いられる。

なお、図１においては、操作ボタン１４Ｉ〜１４Ｋの図示を省略している。例えば、Ｌボタン１４Ｉは、下側ハウジング１１の上側面の左端部に設けられ、Ｒボタン１４Ｊは、下側ハウジング１１の上側面の右端部に設けられる。Ｌボタン１４ＩおよびＲボタン１４Ｊは、ゲーム装置１に対して、例えば撮影指示操作（シャッター操作）を行うために用いられる。さらに、音量ボタン１４Ｋは、下側ハウジング１１の左側面に設けられる。音量ボタン１４Ｋは、ゲーム装置１が備えるスピーカの音量を調整するために用いられる。

また、ゲーム装置１は、各操作ボタン１４Ａ〜１４Ｋとは別の入力装置として、さらにタッチパネル１３を備えている。タッチパネル１３は、下側ＬＣＤ１２の画面上を覆うように装着されている。なお、本実施形態では、タッチパネル１３は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル１３は、抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。また、本実施形態では、タッチパネル１３として、例えば下側ＬＣＤ１２の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル１３の解像度と下側ＬＣＤ１２の解像度とが一致している必要はない。また、下側ハウジング１１の右側面には、挿入口（図１に示す破線）が設けられている。挿入口は、タッチパネル１３に対する操作を行うために用いられるタッチペン２７を収納することができる。なお、タッチパネル１３に対する入力は、通常タッチペン２７を用いて行われるが、タッチペン２７に限らずユーザの指でタッチパネル１３を操作することも可能である。

また、下側ハウジング１１の右側面には、メモリカード２８を収納するための挿入口（図１では、二点鎖線で示している）が設けられている。この挿入口の内側には、ゲーム装置１とメモリカード２８とを電気的に接続するためのコネクタ（図示せず）が設けられる。メモリカード２８は、例えばＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリカードであり、コネクタに着脱自在に装着される。メモリカード２８は、例えば、ゲーム装置１によって撮影された画像を記憶（保存）したり、他の装置で生成された画像をゲーム装置１に読み込んだりするために用いられる。

さらに、下側ハウジング１１の上側面には、カートリッジ２９を収納するための挿入口（図１では、一点鎖線で示している）が設けられている。この挿入口の内側にも、ゲーム装置１とカートリッジ２９とを電気的に接続するためのコネクタ（図示せず）が設けられる。カートリッジ２９はゲームプログラム等を記録した記録媒体であり、下側ハウジング１１に設けられた挿入口に着脱自在に装着される。

下側ハウジング１１と上側ハウジング２１との連結部の左側部分には、３つのＬＥＤ１５Ａ〜１５Ｃが取り付けられる。ここで、ゲーム装置１は、他の機器との間で無線通信を行うことが可能であり、第１ＬＥＤ１５Ａは、ゲーム装置１の電源がオンである場合に点灯する。第２ＬＥＤ１５Ｂは、ゲーム装置１の充電中に点灯する。第３ＬＥＤ１５Ｃは、無線通信が確立している場合に点灯する。したがって、３つのＬＥＤ１５Ａ〜１５Ｃによって、ゲーム装置１の電源のオン／オフ状況、充電状況、および、通信確立状況をユーザに通知することができる。

一方、上側ハウジング２１には、上側ＬＣＤ２２が設けられる。上側ＬＣＤ２２は横長形状であり、長辺方向が上側ハウジング２１の長辺方向に一致するように配置される。なお、下側ＬＣＤ１２と同様、上側ＬＣＤ２２に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、上側ＬＣＤ２２上を覆うように、タッチパネルを設けてもかまわない。例えば、上側ＬＣＤ２２には、ユーザに各操作ボタン１４Ａ〜１４Ｋやタッチパネル１３の役割を教えるための、操作説明画面が表示される。

また、上側ハウジング２１には、２つのカメラ（内側カメラ２３および外側カメラ２５）が設けられる。図１に示されるように、内側カメラ２３は、上側ハウジング２１の連結部付近の内側主面に取り付けられる。一方、外側カメラ２５は、内側カメラ２３が取り付けられる内側主面の反対側の面、すなわち、上側ハウジング２１の外側主面（ゲーム装置１が閉状態となった場合に外側となる面であり、図１に示す上側ハウジング２１の背面）に取り付けられる。なお、図１においては、外側カメラ２５を破線で示している。これによって、内側カメラ２３は、上側ハウジング２１の内側主面が向く方向を撮影することが可能であり、外側カメラ２５は、内側カメラ２３の撮影方向の逆方向、すなわち、上側ハウジング２１の外側主面が向く方向を撮影することが可能である。このように、本実施形態では、２つの内側カメラ２３および外側カメラ２５の撮影方向が互いに逆方向となるように設けられる。例えば、ユーザは、ゲーム装置１からユーザの方を見た景色を内側カメラ２３で撮影することができるとともに、ゲーム装置１からユーザの反対側の方向を見た景色を外側カメラ２５で撮影することができる。

なお、上記連結部付近の内側主面には、音声入力装置としてマイク（図２に示すマイク４２）が収納されている。そして、上記連結部付近の内側主面には、マイク４２がゲーム装置１外部の音を検知できるように、マイクロフォン用孔１６が形成される。マイク４２を収納する位置およびマイクロフォン用孔１６の位置は必ずしも上記連結部である必要はなく、例えば下側ハウジング１１にマイク４２を収納し、マイク４２を収納位置に対応させて下側ハウジング１１にマイクロフォン用孔１６を設けるようにしても良い。

また、上側ハウジング２１の外側主面には、第４ＬＥＤ２６（図１では、破線で示す）が取り付けられる。第４ＬＥＤ２６は、外側カメラ２５によって撮影が行われた（シャッターボタンが押下された）時点で点灯する。また、外側カメラ２５によって動画が撮影される間点灯する。第４ＬＥＤ２６によって、ゲーム装置１による撮影が行われた（行われている）ことを撮影対象者や周囲に通知することができる。

また、上側ハウジング２１の内側主面中央付近に設けられる上側ＬＣＤ２２に対して、左右両側の当該主面に音抜き孔２４がそれぞれ形成される。音抜き孔２４の奥の上側ハウジング２１内にはスピーカが収納されている。音抜き孔２４は、スピーカからの音をゲーム装置１の外部に放出するための孔である。

以上に説明したように、上側ハウジング２１には、画像を撮影するための構成である内側カメラ２３および外側カメラ２５と、例えば撮影の際に操作説明画面を表示する表示手段である上側ＬＣＤ２２とが設けられる。一方、下側ハウジング１１には、ゲーム装置１に対する操作入力を行うための入力装置（タッチパネル１３および各ボタン１４Ａ〜１４Ｋ）と、ゲーム画面を表示するための表示手段である下側ＬＣＤ１２とが設けられる。したがって、ゲーム装置１を使用する際には、ユーザは、下側ＬＣＤ１２に表示される撮影画像（カメラによって撮影された画像）を見ながら、下側ハウジング１１を把持して入力装置に対する入力を行うことができる。

次に、図２を参照して、ゲーム装置１の内部構成を説明する。なお、図２は、ゲーム装置１の内部構成の一例を示すブロック図である。

図２において、ゲーム装置１は、ＣＰＵ３１、メインメモリ３２、メモリ制御回路３３、保存用データメモリ３４、プリセットデータ用メモリ３５、メモリカードインターフェース（メモリカードＩ／Ｆ）３６およびカートリッジＩ／Ｆ４４、無線通信モジュール３７、ローカル通信モジュール３８、リアルタイムクロック（ＲＴＣ）３９、電源回路４０、およびインターフェース回路（Ｉ／Ｆ回路）４１等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて、下側ハウジング１１（または上側ハウジング２１でもよい）内に収納される。

ＣＰＵ３１は、所定のプログラムを実行するための情報処理手段である。なお、ＣＰＵ３１によって実行されるプログラムは、ゲーム装置１内の保存用データメモリ３４に予め記憶されていてもよいし、メモリカード２８および／またはカートリッジ２９から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。例えば、インターネットを経由して所定のサーバからダウンロードすることで取得しても良いし、据置型ゲーム装置と通信を行うことで、当該据置型ゲーム装置に記憶されている所定のプログラムをダウンロードすることで取得しても良い。

ＣＰＵ３１には、メインメモリ３２、メモリ制御回路３３、およびプリセットデータ用メモリ３５が接続される。また、メモリ制御回路３３には、保存用データメモリ３４が接続される。メインメモリ３２は、ＣＰＵ３１のワーク領域やバッファ領域として用いられる記憶手段である。本実施形態では、メインメモリ３２として、例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。保存用データメモリ３４は、ＣＰＵ３１によって実行されるプログラムや内側カメラ２３および外側カメラ２５によって撮影された画像のデータ等を記憶するための記憶手段である。保存用データメモリ３４は、不揮発性の記憶媒体によって構成されており、例えば本実施例ではＮＡＮＤ型フラッシュメモリで構成される。メモリ制御回路３３は、ＣＰＵ３１の指示に従って、保存用データメモリ３４に対するデータの読み出しおよび書き込みを制御する回路である。プリセットデータ用メモリ３５は、ゲーム装置１において予め設定される各種パラメータ等のデータ（プリセットデータ）を記憶するための記憶手段である。プリセットデータ用メモリ３５としては、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）バスによってＣＰＵ３１と接続されるフラッシュメモリを用いることができる。

メモリカードＩ／Ｆ３６は、ＣＰＵ３１に接続される。メモリカードＩ／Ｆ３６は、コネクタに装着されたメモリカード２８に対するデータの読み出しおよび書き込みを、ＣＰＵ３１の指示に応じて行う。本実施形態では、外側カメラ２５によって撮像された画像データがメモリカード２８に書き込まれたり、メモリカード２８に記憶された画像データがメモリカード２８から読み出されて保存用データメモリ３４に記憶されたりする。

カートリッジＩ／Ｆ４４はＣＰＵ３１に接続される。カートリッジＩ／Ｆ４４は、コネクタに装着されたカートリッジ２９に対するデータの読み出しおよび書き込みをＣＰＵ３１の指示に従って行う。本実施形態では、情報処理装置１０が実行することが可能なアプリケーションプログラムがカートリッジ２９から読み出されてＣＰＵ３１によって実行されたり、当該アプリケーションプログラムに関するデータ（例えばゲームのセーブデータ等）がカートリッジ２９に書き込まれたりする。

なお、本発明にかかる広場アプリ処理のプログラムは、本ゲーム装置１のプリインストールアプリとして予め保存用データメモリ３４に記憶された状態であることを前提とするが、有線または無線の通信回線を通じてコンピュータシステムに供給されてもよい。

無線通信モジュール３７は、例えばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール３８は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール３７およびローカル通信モジュール３８は、ＣＰＵ３１に接続される。ＣＰＵ３１は、無線通信モジュール３７を用いてインターネットを介して他の機器との間でデータを送受信することができる。また、ＣＰＵ３１は、ローカル通信モジュール３８を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。例えば、ＣＰＵ３１は、ローカル通信モジュール３８を用いて、近距離無線通信による通信範囲内（例えば、機器間の距離が数十メートル）にある他のゲーム装置を繰り返し探索して自動的に無線接続し、無線接続した他のゲーム装置に対してデータを自動的に送信するとともに、無線接続した他のゲーム装置から送信されるデータを自動的に受信することができる。

また、ＣＰＵ３１には、ＲＴＣ３９および電源回路４０が接続される。ＲＴＣ３９は、時間をカウントしてＣＰＵ３１に出力する。例えば、ＣＰＵ３１は、ＲＴＣ３９によって計時された時間に基づいて、現在時刻（日付）等を計算することもできる。電源回路４０は、ゲーム装置１が有する電源（典型的には電池であり、下側ハウジング１１に収納される）から供給される電力を制御し、ゲーム装置１の各部品に電力を供給する。

ここで、本実施形態では、電源が落とされていないときのゲーム装置１の動作状態として、「通常動作モード」と「スリープモード」とよばれる２つの状態がある。「通常モード」は、ゲーム装置１が開いており、ゲーム装置１を構成する部品の全てに電力が供給されている状態である。つまり、ユーザがゲーム装置１を直接操作しているような状態である。「スリープモード」は、ゲーム装置１が閉じられた（折り畳んだ）状態であるが、ＣＰＵ３１等の一部の構成部品には電力が供給されている状態であり、ユーザは直接的にはゲーム装置１に対して操作は行っていないが、ＣＰＵ３１による処理は可能な状態である。本実施形態では、この「スリープモード」中に、上記ローカル通信モジュール３８を利用した「すれちがい通信」と呼ばれる通信が行われる（詳細は後述する）。

また、ゲーム装置１は、マイク４２およびアンプ４３を備えている。マイク４２およびアンプ４３は、それぞれＩ／Ｆ回路４１に接続される。マイク４２は、ゲーム装置１に向かって発声されたユーザの音声を検知して、当該音声を示す音声信号をＩ／Ｆ回路４１に出力する。アンプ４３は、Ｉ／Ｆ回路４１から音声信号を増幅してスピーカ（図示せず）から出力させる。Ｉ／Ｆ回路４１は、ＣＰＵ３１に接続される。

また、タッチパネル１３は、Ｉ／Ｆ回路４１に接続される。Ｉ／Ｆ回路４１は、マイク４２およびアンプ４３（スピーカ）の制御を行う音声制御回路と、タッチパネル１３の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル１３からの信号に基づいて所定の形式のタッチ位置データを生成してＣＰＵ３１に出力する。例えば、タッチ位置データは、タッチパネル１３の入力面に対して入力が行われた位置の座標を示すデータである。なお、タッチパネル制御回路は、タッチパネル１３からの信号の読み込み、および、タッチ位置データの生成を所定時間に１回の割合で行う。ＣＰＵ３１は、Ｉ／Ｆ回路４１を介して、タッチ位置データを取得することにより、タッチパネル１３に対して入力が行われた位置を知ることができる。

操作ボタン１４は、上記各操作ボタン１４Ａ〜１４Ｋから構成され、ＣＰＵ３１に接続される。操作ボタン１４からＣＰＵ３１へは、各操作ボタン１４Ａ〜１４Ｋに対する入力状況（押下されたか否か）を示す操作データが出力される。ＣＰＵ３１は、操作ボタン１４から操作データを取得することによって、操作ボタン１４に対する入力に応じた処理を実行する。

内側カメラ２３および外側カメラ２５は、それぞれＣＰＵ３１に接続される。内側カメラ２３および外側カメラ２５は、ＣＰＵ３１の指示に応じて画像を撮影し、撮影した画像データをＣＰＵ３１に出力する。本実施形態では、ＣＰＵ３１は、内側カメラ２３および外側カメラ２５のいずれか一方に対して撮影指示を行い、撮影指示を受けたカメラが画像を撮影して画像データをＣＰＵ３１に送る。

また、下側ＬＣＤ１２および上側ＬＣＤ２２は、それぞれＣＰＵ３１に接続される。下側ＬＣＤ１２および上側ＬＣＤ２２は、それぞれＣＰＵ３１の指示に従って画像を表示する。

以下、本実施形態で想定する広場アプリ等の処理の概要について説明する。まず、広場アプリ等の処理の内容の説明に先立ち、この処理の前提となる「すれちがい通信」の概要について説明する。図３および図４は、本実施形態におけるすれちがい通信について説明するための図である。本実施形態では、保存用データメモリ３４の中に、すれちがい通信専用の記憶領域を設ける。当該領域は、複数の「スロット」と呼ばれる単位で論理的に分けられる。このスロットの一つ一つが、所定の１つのアプリと対応付けられる。各スロットには、「送信ボックス」「受信ボックス」「アプリＩＤ」というデータが記憶される。このうち、アプリＩＤが、当該スロットに対応するアプリを識別するためのデータである。送信ボックスには、すれちがい通信において他のゲーム装置に送信するためのデータが格納され、受信ボックスには、すれちがい通信において他のゲーム装置から受信したデータが格納される。

本実施形態では、すれちがい通信は、ゲーム装置１を上記スリープモードにしている間に行われるものとする。例えば、ユーザが、ゲーム装置を閉じた状態にして所持したまま外出したような場合に、ゲーム装置を同様の状態にして所持している他のユーザとすれ違った場合に、以下のような通信が行われる。まず、上記のようなスリープモード中において、各ゲーム装置１からは所定の周期でビーコン信号が発信される。また、互いに自機の通信可能範囲内に存在する他のゲーム装置を検出しあっている。そして、他のゲーム装置１が検知されたとき、いずれかのゲーム装置１が主導する形で、ゲーム装置間ですれちがい通信用のリンク（以下、このようなゲーム装置１同士での直接的な通信を「ローカル通信」と呼ぶ）が確立される。そして、ローカル通信が可能な状態となれば、ゲーム装置間で同じアプリＩＤが登録されたスロットの有無が判断される、そして、同じアプリＩＤを有するスロットが双方に存在すれば、図４に示すように、このスロットの送信ボックス内のデータが互いに送信される。相手側のゲーム装置１から送信されたデータは、受信ボックスに格納される。このようにして他のゲーム装置１から受信し、受信ボックスに格納されたデータについては、対応するアプリの起動時に当該受信ボックスから取得され、各アプリにおいて適宜用いられることになる。

次に、本実施形態にかかるアプリケーションの処理概要を説明する。本実施形態にかかるアプリケーションには、主に、「ユーザキャラクタ作成アプリ」と「広場アプリ」の２つがある。これらは、ゲーム装置１の基本的なメニュー画面であるホームメニューからユーザによって選択されることで適宜実行される（例えば、これらのアプリを示す各アイコンがユーザによって選択されることで実行開始される）。

ユーザキャラクタ作成アプリは、「ユーザキャラクタ」と呼ばれるキャラクタをユーザに生成させるためのアプリケーションである。本実施形態においては、ユーザキャラクタは複数のパーツによって構成されており、このパーツは、例えば、「目」、「鼻」、「口」、「輪郭」、「髪型」等に分類されている。そして、各分類毎に予め複数のパーツが用意されてゲーム装置１に記憶されている。ユーザは、当該ユーザキャラクタ作成アプリで各種パーツを組みあわせる操作を行うことで、例えば、ユーザの顔に似ている顔を有するユーザキャラクタを生成することができる。そして、当該ユーザキャラクタ作成アプリで生成されたユーザキャラクタは、保存用データメモリ３４に保存される。なお、このユーザキャラクタは、複数体生成して保存することも可能である。また、一旦作成したユーザキャラクタの外見等を編集（例えばパーツを異なるものに変更）することも可能である。

一方、「広場アプリ」は、上記ユーザキャラクタをコレクションすることを主目的としたアプリである。ユーザキャラクタの収集は、上記すれちがい通信によって行われる。具体的には、上記ユーザキャラクタ作成アプリによって生成されたユーザキャラクタを、上述したようなすれちがい通信によって、他のゲーム装置１に送信すると共に、他のユーザが作成したユーザキャラクタを受信する。これにより、上記すれちがい通信が繰り返されることで、他のユーザが作成したユーザキャラクタを収集することが可能となる。そして、当該広場アプリにおいて、他のユーザの作ったユーザキャラクタを閲覧したり、自分と他のユーザのユーザキャラクタを用いた所定のミニゲーム等を実行することができる。また、このミニゲームでは、例えば、ユーザキャラクタの外観を変更することのできる「アクセサリ」のようなパーツを入手することが可能となっている。

ここで、当該広場アプリでは、自己の作成したユーザキャラクタと上記すれちがい通信で取得した他のユーザキャラクタとの間で「あいさつ」させることが可能である。以下、このあいさつにかかる処理を「あいさつ処理」と呼ぶ。更に、当該広場アプリでは、他のユーザキャラクタを「評価」し、その結果を相手に伝えることも可能となっている。本実施形態では、この評価対象について、他のユーザキャラクタの外観についての評価を行うものとする。以下では、この評価にかかる処理を「評価処理」と呼ぶ。以下、これらの処理を含めた、広場アプリの動作の流れの全体的な概要を説明する。

典型的な処理の流れとしては、以下のような流れを想定する。まず、広場アプリの初期設定として、すれちがい通信で用いるユーザキャラクタがユーザの操作によって登録される。本実施形態では、すれちがい通信で送受信することが可能なユーザキャラクタの数は１体のみであるとする。その後、ユーザがゲーム装置１をスリープモードにした状態で所持し、外出する。外出中に、何人かの他のユーザ（より正確には、広場アプリについてのすれちがい通信の設定が済んでいるユーザ）とすれ違うことで、上記のようなすれちがい通信（ユーザキャラクタの送受信）が何度か発生する。その後、外出を終えて帰って来たユーザが再度広場アプリを起動すると、「新着通知」として、今回の外出中に行われたすれちがい通信の回数等が示される。そして、今回の外出中に取得された他のユーザキャラクタについて、１体ずつ順番に、後述するような「あいさつ処理」と「評価処理」が行われる。そして、今回の外出中に取得された他のユーザキャラクタ全てに対しての「あいさつ処理」と「評価処理」が終われば、広場アプリのメイン画面が表示される、という流れとなる。換言すれば、本実施形態で説明する「あいさつ処理」と「評価処理」は、上記ゲーム装置をスリープモードにしてから、次に広場アプリが起動されるまでに上記すれちがい通信で取得された他のユーザキャラクタ（いわば新着のユーザキャラクタ）を対象として行われる処理である。以下、各処理の概要について説明する。

［広場アプリの初期設定］
まず、上記広場アプリが初めて起動されると（初回起動時）、当該広場アプリについての初期設定処理が自動的に開始される。この処理においては、当該広場アプリの内容についての簡単な紹介が行われた後、上記すれちがい通信に関する設定、および、上記あいさつ処理において使用される「共通あいさつ」の作成（具体的には文字列の入力）が行われる。

当該設定項目についてより具体的に説明する。上記すれちがい通信に関する主な設定項目としては、「すれちがい通信自体を行うか否か」という設定項目、「あいさつ処理を行うか否か」という設定項目、「評価処理を行うか否か」という設定項目、そして、すれちがい通信で用いるユーザキャラクタの選択、という設定項目がある。これらの設定項目については、当該初期設定処理において、各設定項目について「行う」「行わない」をユーザに問いかける画面を表示し、これに対するユーザの入力によって設定される。

本実施形態では、「すれちがい通信自体を行うか否か」という設定項目については、「行う」という設定にする。その結果、上述したようなすれちがい通信用のスロット（上記図３参照）のいずれか一つと当該広場アプリとが関連づけられる。具体的には、当該広場アプリを示すアプリＩＤが上記いずれかのスロットのアプリＩＤに記憶されることで、スロットと広場アプリとの関連付けが行われることになる。更に、すれちがい通信において送信対象となるユーザキャラクタの選択も行われる。具体的には、ユーザキャラクタの一覧画面等が表示され、ユーザがいずれかのユーザキャラクタを選択する操作を行うことで、すれちがい通信すれちがい通信で用いるユーザキャラクタが選択されることになる。なお、もし上記スロットの全てが既に他のアプリで用いられていた場合は、その旨を知らせるメッセージが適宜表示され、この時点では関連付けは行われない。いずれかのスロットが開放された後に、再度当該関連付けの設定が行われることになる。また、ユーザキャラクタが１体も作成されていない場合は、上記ユーザキャラクタの選択の際にその旨を示すメッセージと、上記ユーザキャラクタ作成アプリを用いてユーザキャラクタの作成を促す旨のメッセージが適宜表示される。

「あいさつ処理を行うか否か」という設定項目、および、「評価処理を行うか否か」という設定項目については、本実施形態では、自分側も相手側も共に「行う」と設定されている場合を例として説明する。ここで、本実施形態では、自分側と相手側の双方がこれらの設定項目を「行う」と設定している場合にのみ、あいさつ処理や評価処理が行われる。つまり、あいさつ処理についていずれか一方で「行わない」という設定がされていた場合は、あいさつ処理は行われない。また、「評価処理」についていずれか一方で「行わない」という設定がされていた場合は、評価処理は行われない。これは、いずれか一方が「あいさつ処理」を行うことを望まない場合や、「評価」されることを望まない場合にまで、強制的にあいさつや評価を行うことでユーザに不快感を与えないようにするためである。そのため、例えば、いずれか一方の側が、あいさつ処理については「行う」と設定しているが、評価処理については「行わない」と設定しているような場合は、あいさつ処理は行われるが、評価処理については行われないことになる。

次に、上記「共通あいさつ」の作成の説明に際し、本実施形態のあいさつ処理で用いられる「あいさつ」全般について説明する。本実施形態のあいさつ処理では、すれちがい通信で受信した他のユーザキャラクタと自己のユーザキャラクタとの間で「あいさつ」するような処理が行われる。この「あいさつ」として、本実施形態では２種類のあいさつが定義されている。１つめは、「共通あいさつ」と呼ばれる種類のあいさつであり、２つめは「個別あいさつ」と呼ばれる種類のあいさつである。「共通あいさつ」は、不特定多数の他のユーザ（他のゲーム装置１）に対してのあいさつ、という位置づけである。つまり、相手を特に指定しないで、無差別に行われるあいさつである。また、例えば、あるグループに属している全体（全員）に対してのあいさつも「共通あいさつ」である。また、この「共通あいさつ」は、ある属性を有する多数の相手向けのあいさつであってもよい。例えば、性別が「男」である他のユーザキャラクタに向けてのあいさつであってもよい。一方、「個別あいさつ」は、ある特定のユーザ（ゲーム装置１）に向けたあいさつ、という位置づけである。つまり、ユーザが個別の相手に対して行うことを意図しているあいさつである。換言すれば、（送信側のユーザの意図としては）あいさつする相手を指定・指名したあいさつである。そして、本実施形態では、基本的には「共通あいさつ」が用いられるが、２回以上すれちがい通信が行われたユーザに対しては、「個別あいさつ」を行うことも可能となる。つまり、初対面の相手に対しては「共通あいさつ」のみ利用できるが、２回以上すれ違ったことがある相手に対しては、「共通あいさつ」および「個別あいさつ」のいずれかを選択して利用可能となる。これは、２回もすれ違う（すれちがい通信が行われる）ような相手とは、それ以降何回もすれ違う可能性があることから、「個別あいさつ」によって、より親しい関係のあいさつを可能とするものである。

そして、広場アプリの初期設定においては、上記「共通あいさつ」の作成のみが行われる。本実施形態では、適宜入力画面が表示され、これに対して１６文字までのテキストをユーザが入力する。このテキストが「共通あいさつ」として記憶される。その結果、「あいさつ処理」では、ここで作成・記憶された「共通あいさつ」が選択できる。なお、本実施形態では、当該「共通あいさつ」は一つしか作成できないものとする。

［スリープモード中のすれちがい通信］
このような広場アプリの初期設定が一通り終われば、上記ユーザキャラクタに関するデータや「共通あいさつ」のテキストデータ等が上記送信ボックスに格納される。その後、広場アプリのメイン画面が表示される。

ユーザは、一旦広場アプリを終了させてゲーム装置１をスリープモードにする。そして、当該ゲーム装置１を所持して外出する。外出中に上記のようなすれちがい通信が何度か行われた後、ユーザが帰ってきたとする。

外出から帰って来たユーザが広場アプリを起動すると、今回の外出中に発生したすれちがい通信（より正確には、上記ユーザキャラクタの送受信を伴うすれちがい通信。以下の説明では、すれちがい通信とはこのようなユーザキャラクタの送受信を伴うすれちがい通信のことを指すものとする）で得られた他のユーザキャラクタについての処理として、以下のような処理が実行される。

［新着通知］
まず、新着通知の処理が行われる。具体的には、図５に示すように、今回の外出中に発生したすれちがい通信の回数が表示される。図５では、画面左側には自己が作成したユーザキャラクタ１０１が表示され、画面右側には、すれちがいで得られた他のユーザキャラクタ１０２の列が表示されている。また、画面上部の略中央に、今回のすれちがい回数を示すメッセージが表示されている。そして、他のユーザキャラクタ１０２の列から１体ずつ自己のユーザキャラクタ１０１に近づいてきてすれ違うようなアニメーションが表示される。その後、図６に示すような、今までに発生した（ユーザキャラクタの送受信を伴う）すれちがい通信の合計回数が表示される。

新着通知にかかる表示が終わると、次に、他のユーザキャラクタ毎に、以下のような処理が順に行われる。
（１）相手側の自己紹介→（２）あいさつ処理→（３）相手側の近況報告等→（４）評価処理

図７〜図２１は、これらの処理にかかる画面の一例である。例えば、図７においては、画面の左側に自己のユーザキャラクタ１０１が表示され、画面右側に、今回の外出中に発生したすれちがい通信で得られた他のユーザキャラクタ１０２が表示されている。このような画面を基本として、以下のような処理が実行される。

［（１）相手側の自己紹介］
まず最初に、（１）相手側の自己紹介が行われる。本実施形態では、図７に示すように、他のユーザの居住している「地域」と他のユーザの「名前」を自己紹介として表示する。この「地域」は、他のユーザキャラクタの送信元となったゲーム装置１の本体設定の一つとして記憶されている内容である。また、「名前」は、当該他のユーザキャラクタの作成者（つまり、他のユーザ）がそのユーザキャラクタに対して任意に付けた名前である。また、この表示は、他のユーザキャラクタ１０２が話しているかのように見せるため、吹き出しを用いた表示がなされる。

相手側の自己紹介が終わると、当該ユーザキャラクタ１０２が初対面となるユーザキャラクタであるときには、図８に示すように、「はじめまして」というメッセージが吹き出しを用いて表示される。また、以前にすれちがい通信で取得した実績がある他のユーザキャラクタの場合は、図９に示すように、すれ違った回数を示すメッセージが表示される。

［（２）あいさつ処理］
次に、（２）あいさつ処理が行われる。この処理では、まず「相手側から自分側へのあいさつ」が行われた後、「自分側から相手側へのあいさつ」が行われる。以下では、他のユーザキャラクタ１０２が初対面である場合と、そうではない場合とに分けて説明する。

［初対面の場合］
現在の処理にかかる他のユーザキャラクタが初対面のユーザキャラクタである場合は、まず、「相手側から自分側へのあいさつ」として、図１０に示すように、相手側が設定した「共通あいさつ」が、他のユーザキャラクタ１０２が話している様子で表示される。その後、「自分側から相手側へのあいさつ」として、図１１に示すように、ユーザ自身が設定した「共通あいさつ」が、自己のユーザキャラクタ１０１が話している様子で表示される。これは、上記初期設定において作成された最長１６文字のテキストメッセージである。

［２度目以降の対面の場合］
現在の処理にかかる他のユーザキャラクタ１０２が初対面のユーザキャラクタではない場合は、「相手側から自分側へのあいさつ」としては、図１２に示すように、相手側が設定した「共通あいさつ」、あるいは、「個別あいさつ」が表示される。いずれが表示されるかは、相手側がいずれのあいさつを行ったかによる。ここで、相手側のあいさつが「個別あいさつ」の場合は、その「個別あいさつ」の基となった自分側のあいさつの内容も共に表示される（図１３参照）。具体的には、まず、自分側のあいさつの内容が先に表示される。そして、このあいさつ内容に対して返事するように、相手側の個別あいさつが表示される。これは、相手側の「個別あいさつ」の内容が、自分側のどのような内容のあいさつに対してのもの（返事）であるのかをユーザに把握させやすくするためである。それと同時に、自分側のユーザキャラクタ１０１と相手側のユーザキャラクタ１０２があたかも会話しているかのように見せることで、ユーザが他のユーザとコミュニケーションをとっている感覚をより高めている。

次に、「自分側から相手側へのあいさつ」として、まず、図１４に示すようなあいさつの種類を選択するあいさつ選択ウィンドウ１０５が表示される。図１４では「みんな向け」と「こべつの」の２つの選択肢が表示されている。これに対して、ユーザが「みんな向け」を選択すると、共通あいさつを選択したものとして扱われる。その結果、図１５に示すように、自己の作成した「共通あいさつ」が表示される。一方、ユーザが「こべつの」を選択したときは、「個別あいさつ」を選択したとして扱われる。その結果、まず、「個別あいさつ」としてのテキストを入力するための画面（図示は省略）が表示される。この画面に対して、２バイト文字で１６文字以内のテキストをユーザが所定の入力装置を用いて入力する。そして、入力が終われば、図１６に示すような確認画面が表示される。この確認画面でユーザが了承すれば、図１７に示すように、今入力した「個別あいさつ」が表示される。以上で、現在の他のユーザキャラクタに対するあいさつ処理は終了する。

ここで上記「個別あいさつ」については、その送信相手を特定する情報と共にすれちがい通信用の送信データとして適宜設定され、送信ボックスに格納される。そして、すれちがい通信によって送信される。なお、本実施形態では、「個別あいさつ」の送信に関しては、とりあえず不特定多数の相手に送信を行うものとする。そして、受信した側で、自分宛の「個別あいさつ」か否かを判断して振り分ける。

なお、上述したあいさつ処理を行うか否かの設定項目において「行わない」と設定されている場合は、図１０〜図１７にかかるあいさつ処理は省略される。

［（３）相手側の近況報告等］
あいさつ処理が終わると、次に、相手側からの近況報告等を示すメッセージがいくつか表示される。図示は省略するが、例えば、最近遊んだゲームが何かを示すメッセージ等が表示される。また、その他、趣味や好きな食べ物等、プロフィールについてのメッセージ等も表示される。

［（４）評価処理］
相手側の近況報告等を示すメッセージの表示が終われば、次に、評価処理が実行される。ここで、当該評価処理に関しては、個別あいさつの場合と同様に、２回以上すれちがい通信を行った相手にのみ可能となっている。つまり、初対面の相手に対しては評価処理は行われない。相手が初対面（初めてすれ違った人）である場合は、その時点では、再度会う（すれ違う）可能性については未知数であり、同じ人と２度とすれ違わない可能性も低くはない。一方、同じ人と２回目のすれちがい通信が発生した場合、比較的親しい間柄であると考えられることから、３回目以降のすれちがい通信が行われることが期待できる。そのため、再度すれ違う可能性が高い相手に対してのみ評価処理を行うようにして、無駄な評価作業を減らそうとするものである。

まず、図１８に示すような、他のユーザキャラクタの外観に対するユーザの評価の選択画面が表示される。図１８では、他のユーザキャラクタ１０２の問いかけメッセージと共に、評価選択ウィンドウ１０７に「ふつうかな」および「すごくいい！」という２つの選択肢が表示されている。ここでは、「すごくいい！」のほうが高評価であるとする。ユーザは、この選択肢から一方を選択する。すると、その選択肢に応じた所定のメッセージが、他のユーザキャラクタ１０２が話しているかのように表示される。例えば、「すごくいい！」が選ばれたときは、図１９に示すように、喜びを示すようなメッセージが表示される。なお、本実施形態では、評価の方法として、２つの予め記憶されているメッセージのうち１つのメッセージを選択することにより評価を行うようしているが、これに限られず、ユーザのテキスト入力により評価を行うようにしていてもよい。

ここで、上記２つの選択肢のうち、高評価のほうの選択肢が選ばれた場合は、その旨を示すデータがすれちがい通信用の送信データの一つとして設定される。そして、以後に発生するすれちがい通信において、高評価したことを示すデータも他の各種データと共に相手側に送信される。そして、受信した側において、自分宛の高評価のデータが含まれているか否かを判断し、含まれていれば、次に説明するような「相手側から自分への評価」として表示されることになる。つまり、高評価の場合は、高評価したということがその相手側に通知されることになる（もちろん、同じユーザとすれ違うことが前提である）。

また、この評価処理に関しては、同じ相手（ユーザキャラクタ）に対しては、原則として１度しか行えない。但し、同じ相手であっても、その外観が変更されていた場合は（上記ユーザキャラクタ生成アプリで編集可能であるため）、変更この外観について再度評価を行うことが可能となっている。

自分側から相手側への評価が終われば、次に、相手側から自分への評価が表示される。これは、上記のように、相手側が自分に対して高評価を行っていた場合にのみ表示される。この場合は、図２０に示すように、相手から自分への評価を示すメッセージが表示された後、図２１に示すように、今までに高評価を受けた累計回数が表示される。一方、相手側が自分に対して高評価は行っていない場合（例えば、上記選択肢で「ふつうかな」を相手が選んでいた場合）は、相手側から自分への評価にかかる処理は実行されないこととなる。

以上のような、（１）相手側の自己紹介→（２）あいさつ処理→（３）相手側の近況報告等→（４）評価処理、の一連の処理が、すれちがい通信で取得した他のユーザキャラクタの数の回数分だけ繰り返された後、広場アプリのメイン画面が表示され、当該広場アプリのメインとなる処理が適宜実行される。このメインとなる処理については本実施形態の説明に直接関係しないため、説明は省略する。

このように、本実施形態では、近距離無線通信である「すれちがい通信」を用いてユーザキャラクタを収集すると共に、同じ相手と複数回すれちがい通信が発生している場合は、ユーザと親しい間柄の相手であるとして、上記「個別あいさつ」のような特定の相手向けのあいさつを可能としている。また、他のユーザの作成したユーザキャラクタについて評価を行い、その評価結果について相手側に送信することも可能となっている。これにより、ゲーム装置を所持して外出するだけで上記の様なすれちがい通信によるユーザキャラクタの収集が可能となり、サーバ等が不要の比較的簡易な構成で、自己のユーザキャラクタを他のユーザに評価してもらい、フィードバックしてもらうことが可能である。また、上記のように何度かすれ違った相手に対しては「個別あいさつ」という形で個別のメッセージを送信することができ、他のゲーム装置１を所持しているユーザとより親密なコミュニケーションを取っているプレイ感覚を提供することができる。

次に、ゲーム装置１によって実行される広場アプリ等の処理の詳細を説明する。まず、各種処理の際に用いられる各種データについて説明する。図２２は、ゲーム装置１の保存用データメモリ３４のメモリマップを示す図である。図２において、保存用データメモリ３４は、プログラム記憶領域３０１およびデータ記憶領域３０５を含む。プログラム記憶領域３０１およびデータ記憶領域３０５のデータは、広場アプリの実行時に、必要に応じてメインメモリ３２に適宜転送されて使用される。

プログラム記憶領域３０１は、ＣＰＵ３１によって実行される各種プログラムを記憶する。本実施形態では、すれちがい通信処理プログラム３０２と、ユーザキャラ生成アプリプログラム３０３と、広場アプリプログラム３０４などが記憶される。すれちがい通信処理プログラム３０２は、上述したようなスリープモードにおけるすれちがい通信を実行するためのプログラムである。ユーザキャラ生成アプリプログラム３０３は、上記ユーザキャラクタ作成アプリを実行するためのプログラムであり、広場アプリプログラム３０４は、上記広場アプリを実行するためのプログラムである。

データ記憶領域３０５には、本体設定データ３０６等が記憶される。また、データ記憶領域３０５は、ユーザキャラクタ記憶領域３０７、すれちがい通信用データ領域３０８、アプリ用データ領域３０９を含んでいる。

本体設定データ３０６は、主にゲーム装置１の本体に関する設定データである。図２３は、本体設定データ３０６の構成の一例である。本体設定データ３０６は、ユーザ名データ３１１、地域データ３１２等から構成される。ユーザ名データ３１１は、ゲーム装置１の所有者（つまり、ユーザ）の氏名のデータである。なお、ユーザ名データ３１１には、ユーザを一意に識別するためのユーザＩＤも含まれている。地域データ３１２は、ユーザによって設定されるデータであり、典型的には、ユーザの住んでいる地域を示すデータである。その他、本体設定データ３０６には、ネットワークに接続するための情報等も含まれる。

図２２に戻り、ユーザキャラクタ記憶領域３０７は、ユーザキャラクタを保存するための領域である。図２４は、当該ユーザキャラクタ記憶領域３０７の構成の一例を示す図である。ユーザキャラクタ記憶領域３０７は、複数のユーザキャラクタデータ３２１の集合で構成されている。この領域には、ユーザ自身が作成したユーザキャラクタのデータの他、上記すれちがい通信で取得された、他のユーザによって作成されたユーザキャラクタも保存される。また、当該領域に保存されているユーザキャラクタは、上記広場アプリを含め、様々なアプリにおいて利用可能なデータである。

各ユーザキャラクタデータ３２１は、ユーザキャラクタＩＤ３２２、ユーザキャラクタ名３２３、構成パーツ情報３２４、作成者ＩＤ３２５等から構成される。ユーザキャラクタＩＤ３２２は、ユーザキャラクタを一意に識別するためのＩＤである。本実施形態では、ゲーム装置本体に固有の番号（例えばシリアルＮｏ）等も利用して、全世界でユニークなＩＤとなるように生成される。具体的には、ゲーム装置本体に固有の番号と、ユーザキャクタが作成された時点の日時を利用することでユーザキャラクタＩＤ３２２が生成される。

ユーザキャラクタ名３２３は、各ユーザキャラクタに設定された名前であり、例えば、２バイト文字で１０文字までの長さの文字列データである。

構成パーツ情報３２４は、ユーザキャラクタを構成している各パーツを示す情報である（上述したように、ユーザキャラクタは、「目」、「鼻」等に分類されているパーツの集まりで構成されている）。

作成者ＩＤ３２５は、ユーザキャラクタを作成した人の識別情報である。当該作成者ＩＤ３２５は、ゲーム装置本体に固有の番号を使用して生成される。その結果、作成者ＩＤ３２５は、ゲーム装置１毎に異なる識別情報となる。ユーザ自身が作成したユーザキャラクタであれば、上記本体設定データ３０６のユーザ名データ３１１が当該作成者情報３２５として記憶される。他のゲーム装置で作成されたユーザキャラクタであれば、そのユーザキャラクタを作成したユーザを示すデータ（他のゲーム装置１におけるユーザ名データ３１１）が作成者情報３２５となる。

図２２に戻り、すれちがい通信用データ領域３０８は、上記図３および図４で説明したような、すれちがい通信において用いられる各種データを格納するための領域である。図２５は、当該すれちがい通信用データ領域３０８の構成の一例を示す図である。すれちがい通信用データ領域３０８には複数のスロット３３１（本実施形態では計１６スロット）が含まれている。各スロットは、アプリＩＤ３３２、すれちがい送信データ３３３、のすれちがい受信データ３３４で構成されている。

アプリＩＤ３３２は、当該スロットを使用する（対応付けられている）アプリケーションを識別するためのＩＤである。

すれちがい送信データ３３３は、すれちがい通信において他のゲーム装置１に送信するためのデータである。図２６は、すれちがい送信データ３３３の構成の一例を示す図である。図２６において、すれちがい送信データ３３３は、送信用ユーザキャラクタデータ３４１、共通あいさつ文字列データ３４２、プロフィールデータ３４３、地域データ３４４、あいさつ処理実行フラグ３４５、評価処理実行フラグ３４６、個別あいさつデータ３４７、評価リスト３５２から構成されている。

送信用ユーザキャラクタデータ３４１は、すれちがい通信において送信する対象となるユーザキャラクタのデータである。上記複数のユーザキャラクタデータ３２１のうちから、ユーザによって選ばれた１体分のユーザキャラクタデータ３２１（あるいは、このデータを特定するための情報）が送信用ユーザキャラクタデータ３４１として記憶される。

共通あいさつ文字列データ３４２は、上述したような「共通あいさつ」を示す文字列データである。

プロフィールデータ３４３は、上記広場アプリにおいて、あいさつ処理の後に行われる「相手側の近況報告等」で用いられるデータである。すれちがい通信における送信先となった他のゲーム装置１上で「相手側の近況報告等」が実行される際に、当該プロフィールデータ３４３の内容が用いられることになる。

地域データ３４４は、上記本体設定データ３０６の地域データ３１２がコピーされたものである。

あいさつ処理実行フラグ３４５は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、あいさつ処理を行うことを許可することを示す。オフに設定されているときは、あいさつ処理を行うことを許可しないことを示す。

評価処理実行フラグ３４６は、上述したような評価処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、評価処理を行うことを許可することを示す。オフに設定されているときは、評価処理を行うことを許可しないことを示す。

個別あいさつデータ３４７は、上述したような「個別あいさつ」に関するデータであり、直近の１６件分の「個別あいさつ」のデータが記憶されている。個別あいさつ１件分のデータは、宛先ユーザキャラＩＤ３４８、個別あいさつ文字列データ３４９、引用あいさつ文字列データ３５０、引用あいさつ種別フラグ３５１で構成される。

宛先ユーザキャラＩＤ３４８は、「個別あいさつ」を行った対象である相手のユーザキャラクタを特定するためのデータであり、上記ユーザキャラクタＩＤ３２２に対応する。

個別あいさつ文字列データ３４９は、「個別あいさつ」の内容を示す文字列データである。

引用あいさつ文字列データ３５０は、当該「個別あいさつ」を生成した際の、他のユーザキャラクタからのあいさつの内容である。例えば、他のユーザキャラクタが行った「またあったね、元気？」という「あいさつ」に対して、「元気だよ。」という「個別あいさつ」を返す場合を想定する。この場合、上記個別あいさつ文字列データ３４９には「元気だよ。」という文字列のデータが格納され、引用あいさつ文字列データ３５０には、「またあったね、元気？」という文字列のデータが格納されることになる。

引用あいさつ種別フラグ３５１は、上記引用あいさつ文字列データ３５０として格納される、他のユーザキャラクタからのあいさつの種類が「共通あいさつ」であるか「個別あいさつ」であるかを示すフラグである。例えば、この値が”０”であれば「共通あいさつ」、”１”であれば、「個別あいさつ」であることを示す。

以上のようなデータで構成される個別あいさつのデータが最大で１６件まで個別あいさつデータ３４７に記憶される。なお、新たに当該データを格納する際に既に１６件まで埋まっている場合は、古いものが１件分消去されてから格納される。

評価リスト３５２は、当該すれちがい送信データの作成元のユーザ（つまり、送信者）が高評価したユーザキャラクタを示すデータである。直近に高評価したユーザキャラクタのユーザキャラクタＩＤ３５３が、最大で３２件分まで格納される。

図２５に戻り、すれちがい受信データ３３４は、すれちがい通信において他のゲーム装置１から受信したデータである。ここには、上記すれちがい送信データ３３３と同様の構成を有する受信データ３３５が複数件格納される。そのため、各受信データ３３５については説明を省略する。

なお、すれちがい送信データ３３３と受信データ３３５の構成が同じであるため、以下の説明では、これらのデータの参照符号の末尾に”Ｓ”または”Ｒ”を付加することで、すれちがい送信データ３３３と受信データ３３５のいずれに含まれるデータであるかを区別する。例えば、「送信用ユーザキャラクタデータ３４１Ｓ」は、すれちがい送信データ３３３に含まれている送信用ユーザキャラクタデータ３４１であることを示し、「送信用ユーザキャラクタデータ３４１Ｒ」は、受信データ３３５に含まれている送信用ユーザキャラクタデータ３４１であることを示す。また、その他のデータについても、末尾に”Ｒ”をつけたデータについては、受信データ３３５に含まれているデータ（つまり、すれちがい通信によって受信したデータに含まれているデータ）であることを示すものとする。

図２２に戻り、アプリ用データ領域３０９は、ゲーム装置１で実行される各種アプリケーションで用いられるデータを記憶する領域である。図２７は、当該アプリ用データ領域３０９の構成の一例を示す図である。当該領域には、各アプリ毎に論理的に分けられて、各アプリにおいて用いられる各種データが記憶される。図２７の例では、広場アプリ用データ３６１と、ユーザキャラ生成アプリ用データ３６６と、その他のアプリ用データ３６７が示されている。ここでは主に、広場アプリ用データ３６１の内容について説明する。

広場アプリ用データ３６１は、アプリＩＤ３６２、アプリセーブデータ３６３、受信ユーザキャラ情報保存データ３６４等で構成される。

アプリＩＤ３６２は、当該「広場アプリ」を識別するためのＩＤである。上述のようなすれちがい通信に用いるスロットとの関連付けに用いられる。

アプリセーブデータ３６３は、広場アプリに関する各種設定等を記憶したデータである。図２８は、アプリセーブデータ３６３の構成の一例を示す図である。図２８において、アプリセーブデータ３６３は、すれちがい用ユーザキャラクタデータ３７１、共通あいさつ文字列データ３７２、プロフィールデータ３７３、あいさつ処理実行フラグ３７４、評価処理実行フラグ３７５、個別あいさつデータ３７６、評価リスト３７７、受けた評価データ３７８から構成される。また、図示は省略するが、広場アプリに関してすれちがい通信を利用するかか否か（つまり、すれちがい通信を行うか否か）の設定や、すれちがい通信の累計数等のデータもアプリセーブデータ３６３に含まれる。

すれちがい用ユーザキャラクタデータ３７１は、すれちがい通信における送信対象として設定したユーザキャラクタのデータである。

共通あいさつ文字列データ３７２は、上述したような「共通あいさつ」を示す文字列データである。

プロフィールデータ３７３は、上述したような「相手側の近況報告等」で用いられるデータである。

あいさつ処理実行フラグ３７４は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。また、評価処理実行フラグ３７５は、上述したような評価処理を行うことを許可するか否かを示すフラグである。その内容は、上記すれちがい送信データ３３３におけるあいさつ処理実行フラグ３４５および評価処理実行フラグ３４６と同様である。

個別あいさつデータ３７６は、直近の１６件分の「個別あいさつ」についてのデータである。その構成は、上記すれちがい送信データ３３３における個別あいさつデータ３４７と同様である。

評価リスト３７７は、自分が高評価を与えた他のユーザキャラクタのユーザキャラクタＩＤのリストであり、最大で直近の３２件分まで保存される。その構成は、上記すれちがい送信データ３３３における評価リスト３５２と同様である。

受けた評価データ３７８は、自己の作成したユーザキャラクタに対して高評価を行った他のユーザについてのデータであり、本実施形態では、最大で１００件分の評価者情報３７９が記憶される。各評価者情報３７９は、評価対象ユーザキャラクタＩＤ３８０と、評価した作成者情報３８１で構成されている。評価対象ユーザキャラクタＩＤ３８０は、自己の作成したユーザキャラクタであって、高評価を受けた（評価の対象となった）ユーザキャラクタのＩＤである。評価した作成者情報３８１は、高評価を与えた他のユーザを示す情報であり、他のゲーム装置１から受信した作成者情報３２５Ｒが当該評価した作成者情報３８１として記憶される。例えば、ユーザＡが２体のユーザキャラクタＡおよびＢを作成したとする。この２体を、すれちがい通信に用いるユーザキャラクタを適宜変更することで、ユーザＢの所持するゲーム装置と、ユーザＣが所持するゲーム装置に送信した場合を想定する。そして、ユーザキャラクタＡについては、他のユーザＢおよびＣから高評価をされたが、ユーザキャラクタＢについては、他のユーザＣからしか高評価がなされなかった場合を想定する。このような場合は、受けた評価データ３７８としては、＜ユーザキャラクタＡのＩＤ＋ユーザＢの作成者情報＞と、＜ユーザキャラクタＡのＩＤ＋ユーザＣの作成者情報＞と、＜ユーザキャラクタＢのＩＤ＋ユーザＣの作成者情報＞の３件分の情報となる。

図２７に戻り、受信ユーザキャラ情報保存データ３６４は、すれちがい通信によって他のゲーム装置１から受信したユーザキャラクタに関するデータである。図２９は、受信ユーザキャラ情報保存データ３６４の構成の一例を示す図である。図２９において、受信ユーザキャラ情報保存データ３６４には、１０００体分の受信ユーザキャラ３９１が記憶される。各受信ユーザキャラ３９１は、ユーザキャラデータ３９２、プロフィールデータ３９３、すれちがい回数３９４、前回すれちがい日時３９５、地域データ３９６、評価処理実行フラグ３９７で構成されている。

ユーザキャラデータ３９２は、上記受信データ３３５に含まれている送信用ユーザキャラクタデータ３４１Ｒがコピーされたものである。同様に、プロフィールデータ３９３は、上記受信データ３３５に含まれているプロフィールデータ３４３Ｒがコピーされたものである。

すれちがい回数３９４は、当該受信したユーザキャラクタの送信元のゲーム装置１との間で、上記のようなすれちがい通信が行われた回数を示すデータである。前回すれちがい日時３９５は、上記受信したユーザキャラクタの送信元のゲーム装置１とすれちがい通信が最後に行われた日時を示すデータである。地域データ３９６は、上記受信データ３３５に含まれている地域データ３４４Ｒがコピーされたものである。

評価処理実行フラグ３９７は、上記受信データ３３５に含まれている評価処理実行フラグ３４６Ｒがコピーされたものである。つまり、当該受信したユーザキャラクタの作成者が、このキャラクタが評価されることを望んでいるか否かを示すフラグである。

以下、ゲーム装置１が行う広場アプリについての処理の詳細動作を説明するが、広場アプリの詳細動作の説明に先立って、上述したすれちがい通信にかかる具体的な処理の流れについて簡単に説明する。

図３０は、本実施形態にかかるすれちがい通信の処理の詳細を示したフローチャートである。このフローにかかる処理は、ゲーム装置１が「スリープモード」（すれちがい通信モード）中のときに実行される。まず、ステップＳ１において、ビーコン信号が発信される。このビーコン信号は、ゲーム装置同士のローカル通信確立のきっかけとなるような情報が含まれている。次に、ステップＳ２において、他のゲーム装置から発信されたビーコンの存在を検出する。

次に、ステップＳ３において、上記ビーコンの検出の結果、ビーコンが検出できたか否か、つまり、自機の通信可能範囲内に他のゲーム装置１が存在するか否かが判定される。その結果、自機の通信可能範囲内に他のゲーム装置１が存在していないときは（ステップＳ３でＮＯ）、後述のステップＳ９に処理が進められる。一方、自機の通信可能範囲内に他のゲーム装置１が存在するときは（ステップＳ３でＹＥＳ）、ステップＳ４において、ローカル通信を確立するための処理が実行される。ローカル通信が確立すれば、ステップＳ５において、通信相手となったゲーム装置１との間で、共通するアプリＩＤ３３２を有するスロット３３１があるか否かが判定される。つまり、すれちがい通信において送受信すべきデータが在るか否かが判定される。その結果、共通するアプリＩＤ３３２を有するスロット３３１がないときは（ステップＳ５でＮＯ）、後述のステップＳ８に処理が進められる。一方、共通するアプリＩＤ３３２を有するスロット３３１が存在するときは（ステップＳ５でＹＥＳ）、ステップＳ６において、当該スロット３３１にかかるすれちがい送信データ３３３が他のゲーム装置１に送信される。同時に、他のゲーム装置１から送信されてくるすれちがい送信データ３３３が、すれちがい受信データ３３４の受信データ３３５として格納される。

次に、ステップＳ７において、上記データの送受信が完了したか、または、ローカル通信が強制的に切断されたか（すれちがい通信が完了する前に、通信可能範囲外にユーザが移動したような場合等）が判定される。その結果、データの送受信が未完了であり、ローカル通信も切断されていなければ（ステップＳ７でＮＯ）、上記ステップＳ６に戻り、データの送受信が継続される。一方、送受信が完了、または、ローカル通信が強制切断されたときは（ステップＳ７でＹＥＳ）、ステップＳ８において、ローカル通信を終了するための処理が実行される。データの送受信が完了した場合は、通信を切断することで、すれちがい通信を「正常終了」させるための処理が実行される。また、送受信完了前にローカル通信が強制切断されていた場合は、それまでに受信したデータをクリアし、すれちがい通信が始まる前の状態に戻す処理が行われる。

次に、ステップＳ９において、「スリープモード」を終了させる指示がなされたか否かが判定され、終了指示がなされていないときは（ステップＳ９でＮＯ）、上記ステップＳ１に戻り、処理が繰り返される。一方、終了指示がなされたときは（ステップＳ９でＹＥＳ）、すれちがい通信処理が終了される。以降、ゲーム装置１が「通常モード」で動作することで、以下に説明するような処理が実行されることになる。

次に、ゲーム装置１で実行される広場アプリの処理の詳細について説明する。この処理は、ゲーム装置１のホームメニューから広場アプリの実行指示がユーザによって行われることで開始される。例えば、ホームメニューの中から、広場アプリに対応するアイコン画像をユーザが選択して所定のボタンを押下したときに開始される。

図３１は、広場アプリの処理の詳細を示すフローチャートである。まず、図３１において、広場アプリが起動されると、保存用データメモリ３４からメインメモリ３２への必要なファイルのロード等の初期処理が適宜実行される。その後、ステップＳ１１において、ユーザキャラクタ記憶領域３０７が参照され、作成済みのユーザキャラクタ１０１が１体以上存在するか否かが判定される。当該判定の結果、ユーザキャラクタ１０１が１体も作成されていないときは（ステップＳ１１でＮＯ）、ステップＳ１２において、ユーザキャラクタの作成を促すメッセージが表示される。そして、広場アプリ処理は終了する。つまり、ユーザキャラクタが未作成の状態では、広場アプリは実質的に利用できないことになる。

一方、ユーザキャラクタ１０１が１体以上作成済みであるときは（ステップＳ１１でＹＥＳ）、次に、ステップＳ１３において、広場アプリが初回起動であるか否か（つまり、今まで一度も実行されたことが無いか否か）が判定される。その結果、初回起動のときは（ステップＳ１３でＹＥＳ）、ステップＳ１４において、広場アプリ初期設定処理が実行される。この処理は、すれちがい通信で用いるユーザキャラクタの選択等、広場アプリを利用するために必要な各種設定を行うための処理である。一方、初回起動ではないときは（ステップＳ１３でＮＯ）、広場アプリ初期設定処理はスキップされて、後述のステップＳ１５に処理が進められる。

図３２は、上記ステップＳ１４で示した広場アプリ初期設定処理の詳細を示すフローチャートである。図３２において、まず、ステップＳ２１で、広場アプリの簡単な紹介と説明が表示される。続くステップＳ２２において、ユーザとの対話形式ですれちがい通信に関する設定を行う処理が実行される。具体的には、「すれちがい通信」を行うか否か、「あいさつ処理」を行うか否か、「評価処理」を行うか否か、等について、対話形式を用いて設定される。その結果、ユーザの入力内容に応じて、上記すれちがい通信用データ領域３０８のいずれかのスロット３３１と広場アプリとを関連づける処理が実行される。更に、ユーザキャラクタ記憶領域３０７から、すれちがい通信で用いるユーザキャラクタがユーザの入力内容に基づいて選択され、アプリセーブデータ３６３のすれちがい用ユーザキャラクタデータ３７１として保存される。また、アプリセーブデータ３６３のあいさつ処理実行フラグ３７４および評価処理実行フラグ３７５も、ユーザの入力内容に応じて適宜設定される。

次に、ステップＳ２３において、プロフィールデータ３７３作成の元となる質問が適宜表示され、これに対するユーザの入力内容に応じて、プロフィールデータ３７３が適宜設定される。

次に、ステップＳ２４において、「共通あいさつ」を生成するための処理が実行される。具体的には、「共通あいさつ」としての文字列を入力するための画面が表示される。これに対して、ユーザによって入力された所定の文字列が共通あいさつ文字列データ３７２として記録される。以上で、広場アプリ初期設定処理は終了する。

図３１に戻り、次に、ステップＳ１５において、広場アプリメイン処理が実行される。図３３〜図３８は、当該広場アプリメイン処理の詳細を示すフローチャートである。図３３において、まず、ステップＳ４１で、アプリセーブデータ３６３が参照され、広場アプリですれちがい通信を行う設定がなされているか否かが判定される。その結果、すれちがい通信を行わない旨の設定が成されているときは（ステップＳ４１でＮＯ）、後述するステップＳ８０に処理が進められ、広場アプリのメイン画面が表示されることになる。

一方、すれちがい通信を行う旨の設定がなされているときは（ステップＳ４１でＹＥＳ）、次に、ステップＳ４２において、すれちがい通信用データ領域３０８が参照され、今回の（直近の）スリープモード中においてすれちがい通信が発生したか否かが判定される。例えば、すれちがい受信データ３３４の内容が空であるか否かで判定される。当該判定の結果、すれちがい通信が発生していないときは（ステップＳ４２でＮＯ）、続くステップＳ４３で、アプリセーブデータ３６３が参照されて、すれちがい通信の累計回数が０か否かが判定される。その結果、すれちがい通信の回数が０のときは（ステップＳ４３でＮＯ）、他のユーザキャラクタを１体も受信していない状態であると考えられるため、ステップＳ４４において、ユーザにすれちがい通信を行わせることを支援するためのメッセージ（例えば、「人の集まるところですれちがい通信をしてみよう！」）が表示される。その後、後述のステップＳ８０に処理が進められる。

一方、直近のスリープモード中においてすれちがい通信が発生していたときは（ステップＳ４２でＹＥＳ）、少なくとも１体は他のユーザキャラクタを受信していると考えられるため、新着通知にかかる処理が実行される。具体的には、ステップＳ４５において、上記図５を用いて説明したような画面を用いて、今回のすれちがい通信においてすれ違った回数（受信した他のユーザキャラクタの数）が表示される。その後、当該回数が、累計すれちがい回数を示すデータ（図示は省略）に加算されて、上記図６で示したような画面が生成されて表示される。また、当該加算後の累計すれちがい回数はアプリセーブデータ３６３の一部として記憶される。

新着通知にかかる処理が終われば、次に、受信された各ユーザキャラクタについての処理が実行される。まず、ステップＳ４６において、すれちがい受信データ３３４が参照されて、処理対象となるユーザキャラクタ（受信データ３３５）が古い順に１件選択されて読み出される。以下、当該選択されたユーザキャラクタを処理対象キャラクタと呼ぶ。

次に、ステップＳ４７において、処理対象キャラの自己紹介を表示する処理が行われる。具体的には、受信データ３３５（その構成は上記図２６で示したすれちがい送信データ３３３と同様である）の送信用ユーザキャラクタデータ３４１Ｒが参照され、これに含まれているユーザキャラクタ名３２３Ｒが取得される。また、受信データ３３５の地域データ３４４Ｒが参照されることで、地域名も取得される。そして、これらのデータに基づき、地域と名前を表示した自己紹介画面（上記図７参照）が生成されて表示される。

次に、図３４のステップＳ４８において、処理対象キャラクタが「初対面」となるユーザキャラクタか否かが判定される。「初対面」か否かは、例えば、当該処理対象キャラクタのユーザキャラクタＩＤ３２２Ｒを基にして受信ユーザキャラ情報保存データを検索し、検索できたか否かで判定される（検索できなかった場合は「初対面」となる）。

当該判定の結果、初対面であるときは（ステップＳ４８でＹＥＳ）、ステップＳ４９において、初対面処理が実行される。図３５は、当該初対面処理の詳細を示すフローチャートである。まず、ステップＳ１０１において、初対面用のあいさつが表示される。当該初対面用のあいさつは、予め定義されている文字列である。ここでは、上記図８で示したような、「はじめまして」というあいさつが表示される。

次に、ステップＳ１０２において、あいさつ処理の実行に関してお互いに許可されているか否かが判定される。例えば、まず、アプリセーブデータ３６３のあいさつ処理実行フラグ３７４が参照され、自分側のあいさつ処理の実行許可が設定されているか否かが判定される。その結果、許可されていなければ、当該ステップＳ１０２の判定結果はＮＯとなる。許可されていれば、次に、処理対象キャラクタのあいさつ処理実行フラグ３４５Ｒが参照され、相手側のあいさつ処理の実行許可が設定されているか否かが判定される。ここで許可されていないときは、当該ステップＳ１０２の判定結果はＮＯとなる。許可されているときは、当該ステップＳ１０２の判定結果はＹＥＳとなる。

ステップＳ１０２の判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときは（ステップＳ１０２でＮＯ）、後述のステップＳ１０５に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されていれば（ステップＳ１０２でＹＥＳ）、ステップＳ１０３において、受信データ３３５の共通あいさつ文字列データ３４２Ｒが参照され、処理対象キャラクタにかかる（つまり、相手側の）「共通あいさつ」が表示される。

次に、ステップＳ１０４において、アプリセーブデータ３６３の共通あいさつ文字列データ３７２が参照され、ユーザ自身が作成した（つまり、自分側の）「共通あいさつ」が表示される。つまり、初対面のときは、「個別あいさつ」は一切用いられないことになる。

次に、ステップＳ１０５において、処理対象キャラクタにかかる近況報告の処理が実行される。これは、受信データ３３５のプロフィールデータ３４３Ｒが参照されることで、その内容を反映したメッセージが生成されて表示される処理である。以上で、初対面処理は終了する。

図３４に戻り、初対面処理が終わると、後述するステップＳ７８に処理が進められ、次の他のユーザキャラクタにかかる処理に移行することになる（つまり、初対面時は、評価処理はなされないことになる）。

一方、図３４のステップＳ４８の判定の結果、初対面のキャラクタではないときは（ステップＳ４８でＮＯ）、次に、ステップＳ５０において、処理対象キャラクタとの遭遇回数（すれちがい通信が行われた回数）を表示する処理が実行される。具体的には、受信ユーザキャラ情報保存データ３６４が参照され、処理対象キャラクタにかかるすれちがい回数３９４が取得される。そして、この回数に１を加算した値に基づいて上記図９で示したような画面が生成されて表示される。また、この加算後の値は、当該処理対象キャラクタにかかるすれちがい回数３９４として記憶される。

次に、ステップＳ５１において、あいさつ処理を行うか否かが判定される。すなわち、双方ともに「あいさつ処理」の実行許可が設定されているか否かが判定される。当該判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときは（ステップＳ５１でＮＯ）、後述のステップＳ６７に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されているときは（ステップＳ５１でＹＥＳ）、ステップＳ５２において、処理対象キャラクタ（相手側）のあいさつの種類が「共通あいさつ」か否かかが判定される。具体的には、まず、処理対象キャラクタにかかる受信データ３３５の個別あいさつデータ３４７Ｒが参照され、自分側のユーザキャラクタのユーザキャラクタＩＤ３２２と一致する宛先ユーザキャラＩＤ３４８Ｒが検索される。その結果、検索できた場合は、相手側のあいさつは「個別あいさつ」であり、見つからなかった場合は、相手側のあいさつは「共通あいさつ」であると判定される。

ステップＳ５２の判定の結果、処理対象キャラクタ側のあいさつが「共通あいさつ」であるときは（ステップＳ５２でＹＥＳ）、ステップＳ５３において、処理対象キャラクタにかかる受信データ３３５の共通あいさつ文字列データ３４２Ｒに基づいて、処理対象キャラクタ側の「共通あいさつ」が表示される。

次に、ステップＳ５４において、処理対象キャラクタとのすれちがい回数が２回目であるか否かが判定される。例えば、受信ユーザキャラ情報保存データ３６４が参照され、処理対象キャラクタに対応する受信ユーザキャラのデータが存在するか否かが判定される。そして、存在していれば、すれちがい回数３９４が参照され、「２回目」を示すデータが格納されているときは、今回、２回目のすれちがいが行われたと判定される。このような判定の結果、すれちがい回数が２回目のときは（ステップＳ５４でＹＥＳ）、ステップＳ５５において、「個別あいさつ」が送信可能となった旨のメッセージを表示する。次に、ステップＳ５６において、上記図１４で示したような、あいさつ選択ウィンドウ１０５に表示する内容の設定が行われる。ここでは、上記図１４で示されているような「みんな向け」と「こべつの」という２つの選択肢が設定される。その後、後述するステップＳ６１に処理が進められる。

一方、上記ステップＳ５４の判定の結果、２回目ではない（つまり、３回目以上）のときは（ステップＳ５４でＮＯ）、上記ステップＳ５５の処理はスキップされる。

次に、上記ステップＳ５２の判定の結果、処理対象キャラクタ側のあいさつが「共通あいさつ」ではないとき（ステップＳ５２でＮＯ）、つまり、「個別あいさつ」であるときの処理について説明する。このときは、上記図１３で示したような、相手側の「個別あいさつ」と、これの基になった自分側のあいさつの文字列を示す画面を表示するための処理が実行される。まず、図３６のステップＳ５７において、処理対象キャラ側の個別あいさつデータ３４７Ｒが参照され、引用あいさつ文字列データ３５０Ｒが取得される。そして、当該データで示される文字列、つまり、前回のすれちがい時に自分側が行ったあいさつ内容が表示される。続いて、ステップＳ５７１において、同じく処理対象キャラ側の個別あいさつデータ３４７Ｒが参照され、自分宛の個別あいさつ文字列データ３４９Ｒが取得される。そして、当該データに基づき、相手側の「個別あいさつ」が表示される。その結果、まず、前回すれちがい時に自分側が行ったあいさつが表示され、これに答えるように、相手側の「個別あいさつ」が次に表示されることになる。このように、自分側のあいさつと相手側のあいさつを順番に表示することで、自分側のユーザキャラクタ１０１と相手側のユーザキャラクタ１０２とがあたかも会話しているかのような表現が行われることになる。。

次に、ステップＳ５８において、処理対象データにかかる受信データ３３５の引用あいさつ種別フラグ３５１Ｒが参照され、当該処理対象キャラクタと前回すれちがい通信が行われた際に、自分側が送ったあいさつの種類が「個別あいさつ」であったか否かが判定される。その結果、前回送ったあいさつが「個別あいさつ」のときは（ステップＳ５８でＹＥＳ）、ステップＳ５９において、あいさつ選択ウィンドウ１０５の内容が設定される。ここで設定される内容は、上記図１４で示したようなあいさつ選択ウィンドウ１０５の内容となる。

一方、前回送ったあいさつが「共通あいさつ」のときは（ステップＳ５８でＮＯ）、ステップＳ５８１において、引用あいさつ文字列データ３５０Ｒと共通あいさつ文字列データ３７２とが参照され、その内容が一致するか否かが判定される。その結果、一致していないときは（ステップＳ５８１でＮＯ）、上記ステップＳ５９に処理が進められる。一方、一致しているときは（ステップＳ５８１でＹＥＳ）、次のステップＳ６０において、あいさつ選択ウィンドウ１０５の内容が設定されるが、ここで設定される内容は、図３９に示すような、個別あいさつをするかしないかを問い合わせるような内容となる。これは、「共通あいさつ」で同じあいさつを複数回行ってしまうことを防止するため、「共通あいさつ」に対する相手側の「個別あいさつ」に対して「個別あいさつ」を返すことを促すためである。また、上記ステップＳ５８１の判定は、前回すれちがい通信が行われた後、「共通あいさつ」の文字列がユーザによって変更され、更にその後に同じ相手とすれちがい通信が行われた場合を想定したものである。つまり、ある相手に一旦「共通あいさつ」を送った後、「共通あいさつ」の文字列をユーザが変更した場合は、その後同じ相手に「共通あいさつ」を送ったとしても、そのあいさつ内容は別の文字列となっているため、同じ文字列の「共通あいさつ」が連続して行われることにはならない。このような、「共通あいさつ」の変更が行われたか否かを判別するために上記ステップＳ５８１の判定が行われている。

図３６に戻り、次に、ステップＳ６１において、上記ステップＳ５９またはステップＳ６０で設定された内容であいさつ選択ウィンドウ１０５が生成されて表示される。そして、当該選択ボックスに対するユーザからの入力が受け付けられる。

次に、ステップＳ６２で、上記あいさつ選択ウィンドウ１０５に対するユーザの選択内容が「個別あいさつ」を選択したものであるか否かが判定される。当該判定の結果、「個別あいさつ」が選択されていないときは（ステップＳ６２でＮＯ）、ステップＳ６３において、共通あいさつ文字列データ３７２に基づいた「共通あいさつ」が表示される。そして、後述のステップＳ６７に処理が進められる。

一方、「個別あいさつ」が選択されたときは（ステップＳ６２でＹＥＳ）、ステップＳ６４において、「個別あいさつ」を作成する処理が実行される。具体的には、文字列入力画面が表示され、ユーザからの文字列入力が受け付けられる。ユーザからの文字列入力が終われば、確認メッセージが表示され（上記図１６参照）、入力内容が確定すれば、次のステップＳ６５において、当該入力された文字列データに基づき、上記図１７で示したように、上記ユーザの入力した「個別あいさつ」が表示される。次に、ステップＳ６６において、アプリセーブデータ３６３の個別あいさつデータ３７６が更新される。具体的には、現在の処理対象キャラクタを示すユーザキャラクタＩＤ３２２Ｒが、アプリセーブデータ３６３の個別あいさつデータ３７６に含まれる宛先ユーザキャラＩＤとして記憶される。また、上記入力が確定した文字列のデータが個別あいさつ文字列データとして記憶され、現在の処理対象キャラクタ側のあいさつの文字列データが引用あいさつ文字列データとして記憶され、現在の処理対象キャラ側のあいさつの種別を示すデータが引用あいさつ種別フラグとして記憶される。以上で、あいさつ処理は終了する。

次に、図３７のステップＳ６７において、相手側の近況報告処理が行われる。相手側の近況報告処理が終われば、次に、評価処理が行われる。まず、ステップＳ６８において、自分側と相手側の双方ともに評価処理の実行許可が設定されているか否かが判定される。これは、相手側と自分側の評価処理実行フラグが参照されることで判定される。当該判定の結果、少なくとも一方で評価処理の実行許可が設定されていないときは（ステップＳ６８でＮＯ）、後述のステップＳ７８に処理が進められる。

一方、双方ともに評価処理の実行許可が設定されているときは（ステップＳ６８でＹＥＳ）、ステップＳ６９において、処理対象キャラクタについて既に評価済みであるか否かが判定される。これは、まず、処理対象キャラとのすれちがい回数が２回目か否かが判定され、２回目であれば、まだ評価していないと判定される。一方、３回目以降であるときは、更に、受信ユーザキャラ情報保存データ３６４に保存されている処理対象キャラクタのユーザキャラデータ３９２と、受信データ３３５における送信用ユーザキャラクタデータ３４１Ｒとが比較され、ユーザキャラクタの外見が一致するか否かが判定される。その結果、外観に違いがあるときは、新たな外観についての評価はまだ行われていないとして、まだ評価していないと判定される。３回目以降であって、前回から外観に変化がないときは、評価済みであると判定される。なお、例えば２回目のすれちがいにおいて、相手側の評価処理実行フラグ３４６Ｒが「許可しない」設定であり、３回目のすれちがいにおいて、相手側の評価処理実行フラグ３４６Ｒが「許可する」設定となっていた場合であっても、２回目と３回目とで処理対象キャラの外観に変化がないときは、評価済みであると判定される。

ステップＳ６９の判定の結果、既に評価済みであるときは（ステップＳ６９でＹＥＳ）、後述のステップＳ７５に処理が進められる。一方、まだ評価していないときは（ステップＳ６９でＮＯ）、ステップＳ７０において、上記図１８で示したような画面が表示される。すなわち、２つの選択肢（高評価／普通）を有する評価選択ウィンドウ１０７が表示される。そして、ユーザからの入力が受け付けられる。

次に、ステップＳ７１において、ユーザの入力内容に応じた処理対象キャラクタのリアクションが表示される（上記図１９参照）。また、上記受信ユーザキャラ情報保存データ３６４に保存されている処理対象キャラのユーザキャラデータ３９２の内容が受信後のデータ内容に基づいて適宜更新される。

次に、ステップＳ７２において、上記ユーザの入力にかかる内容が、高評価にかかる内容であるか否かが判定される。その結果、高評価であったときは（ステップＳ７２でＹＥＳ）、ステップＳ７３において、次回すれ違ったときに、当該処理対象キャラの送信元のゲーム装置１に評価が送信される旨の通知メッセージが表示される。次に、ステップＳ７４において、アプリセーブデータ３６３のうち、上記評価処理に関するデータが適宜更新される。具体的には、アプリセーブデータ３６３の評価リスト３７７に処理対象キャラのユーザキャラクタＩＤが保存される、このとき、当該ＩＤが重複していれば、古い方のＩＤは削除される。また、既に３２件登録されている状態であれば、一番古いデータが削除されてから保存される。

一方、上記ステップＳ７２の判定の結果、高評価ではなかったときは（ステップＳ７２でＮＯ）、当該ステップＳ７３およびステップＳ７４の処理はスキップされる。

次に、図３８のステップＳ７５において、相手側から自分への評価データがあるか否かが判定される。具体的には、まず、アプリセーブデータ３６３の受けた評価データ３７８が参照され、既に１００件分の評価を受けているか否か（既に１００件登録されているか否か）が判定される。その結果、１００件未満のときは、次に、処理対象キャラクタにかかる受信データ３３５の評価リスト３５２Ｒから自分のユーザキャラクタ（すれちがい通信用として現在設定されているユーザキャラクタ）のユーザキャラクタＩＤが検索される。その結果、見つかったときは、自分への評価データがあると判定され、見つからなかったときは、自分への評価データがないと判定される。一方、受けた評価データ３７８に既に１００件分の評価が保存されていれば、相手側から自分への評価データがある場合でも、評価データはないものとして判定される。つまり、既に１００件分の評価があるときは、相手側からの評価に関する処理は実行されないことになる。

ステップＳ７５の判定の結果、相手側から自分への評価データがないときは（ステップＳ７５でＮＯ）、後述のステップＳ７８に処理が進められる。一方、自分への評価データがあるときは（ステップＳ７５でＹＥＳ）、ステップＳ７５１において、受信データ３３５の評価リスト３５２ＲのユーザキャラＩＤ３５３Ｒ（評価対象ユーザキャラクタＩＤ３８０に対応）と受信データ３３５の送信用ユーザキャラクタデータ３４１Ｒにおける作成者ＩＤ３２５Ｒ（評価した作成者情報３８１に対応）の組み合わせが、受けた評価データ３７８に既に存在するかどうかが判定される。その結果、既に存在するときは（ステップＳ７５１でＹＥＳ）、この相手からは既に評価を受けていることになるため、後述のステップＳ７８に処理が進められる。一方、存在しないときは（ステップＳ７５１でＮＯ）、この相手からはまだ評価を受けたことがないことになる。この場合は、続くステップＳ７６において、相手側からの評価を表示する処理が実行される。すなわち、上記図２０で示したような画面が表示される。

次に、ステップＳ７７において、高評価の累計数が表示される。具体的には、まず、今回評価された自分側のユーザキャラクタＩＤ３２２が、評価者情報３７９の評価対象ユーザキャラクタＩＤ３８０として記憶され、今回の処理対象キャラクタの作成者情報３２５Ｒが評価した作成者情報３８１として記憶される。そして、受けた評価データ３７８に含まれる評価者情報３７９の件数が高評価の累計数として算出される。つまり、当該累計数は、複数のユーザキャラクタが作成されている場合は、これら全てのユーザキャラクタに対する高評価の数を合計した値が用いられることになる。各ユーザキャラクタは、相手毎に評価が得られるため、例えば、ユーザキャラクタＡが、２人の他のユーザから高評価を得ており、ユーザキャラクタＢについては４人の他のユーザから高評価を得ているときは、高評価の累計数は６となる。これは、高評価の数を集めることを目的にさせることで、ユーザに様々なユーザキャラクタを作成させて楽しんでもらう事を促進するためである。そして、この累計数に基づいて、上記図２１で示したような画面が生成されて表示される。

なお、上記ステップＳ７５１の判定の結果、上記の組み合わせが既に存在するときに、上記ステップＳ７６に処理を進めるようにしても良い。この場合は、高評価の累計数は更新しないようにしてもよい。つまり、既に評価を受けた相手については、その相手からの評価の表示のみを行い、累計数は加算しないようにしてもよい。

以上で、評価処理は終了する。このようにしてあいさつ処理や評価処理が終了したユーザキャラクタにかかる受信データ３３５は、処理済みであるとして、すれちがい受信データ３３４からクリアされる。

次に、ステップＳ７８において、上述したような処理がまだ行われていない受信データ３３５が残っているか否かが判定される。その結果、まだ残っているときは（ステップＳ７８でＹＥＳ）、上記ステップＳ４６に戻り、処理が繰り返される。一方、全て処理したときは（ステップＳ７８でＮＯ）、ステップＳ７９において、上述した処理内容が反映されるようにすれちがい送信データ３３３が適宜更新される。すなわち、あいさつ処理における個別あいさつに関連するデータである個別あいさつデータ３４７Ｓや、評価処理に関する評価リスト３５２Ｓ等が適宜更新される。

次に、ステップＳ８０において広場メイン画面が表示され、続くステップＳ８１において、その他の広場アプリの処理が実行される。続くステップＳ８２において、広場アプリの終了指示がユーザから指示されたか否かが判定され、終了指示がなされていなければ（ステップＳ８２でＮＯ）、上記ステップＳ８１の処理が繰り返され、終了指示がなされたときは（ステップＳ８２でＹＥＳ）、当該広場アプリは終了され、ホームメニュー画面に戻ることになる。以上で、本実施形態にかかる広場アプリ処理の説明を終了する。

このように、本実施形態では、最初は不特定多数に向けた「共通あいさつ」を用いて不特定多数相手とのコミュニケーションを図りつつ、その中で複数回すれ違った相手に対しては、その相手を特定した「個別あいさつ」が送信できるようにしている。これにより、他のユーザとの通信内容が画一的になることを防ぎ、よくすれ違う相手との親密度を高めることを可能として、上記のようなすれちがい通信による他人とのコミュニケーションの興趣性をより高めることが可能となる。換言すれば、すれちがい通信を繰り返すことで、親しくなれる可能性の高い他人を抽出し、その相手に対して個別にアプローチすることを可能とすることで、新たな友達を作る可能性を高めることができる。

また、相手側の個別あいさつが表示される際、その個別あいさつの基になった自分側のあいさつ内容も合わせて表示されるようにしている。これにより、相手側のあいさつ（相手側の反応内容）が、自分が相手側に送ったどのようなあいさつに対してものであるかを把握させやすくすることができる。特に、上記のようなすれちがい通信によってあいさつが送受信される、換言すれば、あいさつ内容はリアルタイムにやりとりされるものではないため、このように過去に送ったあいさつ内容を表示することは効果的である。

また、自己が作成したユーザキャラクタを、近距離無線通信であるすれちがい通信を用いて送信し、他のユーザに評価してもらうことが可能となっている。つまり、ユーザが生活する地域の近隣範囲内において、簡易なシステム構成によって自己の作成したユーザキャラクタを他人に評価してもらい、その結果をフィードバックしてもらうことが可能となる。これにより、自己のユーザキャラクタを他人に評価してもらうことを手軽にユーザに楽しんでもらうことが可能となる。その結果、複雑なシステム構成を用いることなく、他人とのコミュニケーションをより活発化させることが可能となる。

また、評価については、高評価が行われたときにしか相手側にフィードバックしないようにしているため、ユーザが評価内容に不満を感じることを軽減して興趣性が下がってしまうことを防ぐことができる。更に、複数のユーザキャラクタを用いている場合、１つのユーザキャラクタについては原則評価は一回のみとする反面、各キャラクタに与えられた高評価の数を集計して表示するようにしている。そのため、よりたくさんの高評価を得るために、より多くのユーザキャラクタを生成し、より多くのすれちがい通信を行うことをユーザに促進させることが可能となる。

なお、上記実施形態では、「あいさつ」の内容については、文字列のみの場合を例に挙げたが、この他、ユーザが自由な表現で作成することができるものであれば、画像や音声なども含むようにしてもよい。また、ゲーム装置１上で作成されるものに限られず、外部の装置で作成されたものを利用可能としてもよい。また、その他、例えば、「あいさつ」を表示するときに、ユーザキャラクタに所定のアクションを行わせるようにしてもよい（エモーション動作等）。この場合は、所定のアクションの内容を示すデータを上記「共通あいさつ」や「個別あいさつ」のデータに含めるようにすればよい。

また、「個別あいさつ」を作成するタイミングに関して、上記実施形態では、上記あいさつ選択ウィンドウ１０５でユーザが「個別あいさつ」の作成を選択したときに、「個別あいさつ」の入力画面に遷移するようにしていた。この他、「個別あいさつ」については、他のタイミングにおいても作成することができるようにしてもよい。例えば、広場アプリのメイン処理の機能の一つとして「個別あいさつ」の作成と記憶が可能にしておき、ユーザは、この機能を用いて、いくつかの「個別あいさつ」を作成し、ゲーム装置１に記憶させておく。その後、上記の様なあいさつ処理が行われ、上記あいさつ選択ウィンドウ１０５で、ユーザが「個別あいさつ」の作成を選択したときは、入力画面は表示せずに、代わりに、上記の機能を用いて事前に作成しておいた「個別あいさつ」を選択肢（一覧）として表示させる。そして、ユーザにこの中から「個別あいさつ」を１つ選択させるようにすればよい。

また、上記実施形態では、すれちがい通信は「スリープモード」のときに行われる場合を例に挙げたが、「スリープモード」以外の状態においても上記すれちがい通信が行われるように構成しても良い。

また、上記実施形態では、送受信するゲーム装置１が共に携帯型ゲーム装置である場合を例に挙げたが、この他、いずれか一方は据置型ゲーム装置であってもよい。例えば、窓際に設置された据置型ゲーム装置と、その近くを通りがかったユーザの携帯型ゲーム装置との間で上記のようなすれちがい通信によりユーザキャラクタの送受信が行われてもよい。

また、上記ユーザキャラクタに関して、上記実施形態では、ユーザキャラ作成アプリにおいてユーザが作成したユーザキャラクタをすれちがい通信用のユーザキャラクタに設定する場合を例に挙げていたが、この他、上記すれちがい通信によって取得された他のユーザキャラクタを、上記すれちがい通信用のキャラクタ（つまり、自分側から送信するユーザキャラクタ）として設定できるようにしてもよい。

また、上記実施形態においては、他のゲーム装置１から受信した評価データに基づく評価結果を画面に表示する場合を例に挙げていたが、この他、評価結果を音声や振動等を用いてユーザに報知させるようにしてもよい。

また、上記実施形態においては、すれちがい通信によって受信した他のユーザキャラクタを利用したあいさつ処理や評価処理に関する一連の処理については単一の装置（ゲーム装置１）において実行される場合を説明したが、他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。

本発明にかかる通信システム、情報処理プログラム、情報処理方法、情報処理装置、情報処理システムは、簡易なシステム構成によって、ユーザが作成したコンテンツを他人に評価してもらうことを手軽に実現でき、各種ゲーム装置や携帯型情報端末等に有用である。

１…ゲーム装置
１１…下側ハウジング
１２…下側ＬＣＤ
１３…タッチパネル
１４…操作ボタン
１５、２６…ＬＥＤ
１６…マイクロフォン用孔
２１…上側ハウジング
２２…上側ＬＣＤ
２３…内側カメラ
２４…音抜き孔
２５…外側カメラ
２７…タッチペン
２８、２９…メモリカード
３１…ＣＰＵ
３２…メインメモリ
３３…メモリ制御回路
３４…保存用データメモリ
３５…プリセットデータ用メモリ
３６…メモリカードＩ／Ｆ
３７…無線通信モジュール
３８…ローカル通信モジュール
３９…ＲＴＣ
４０…電源回路
４１…Ｉ／Ｆ回路
４２…マイク
４３…アンプ

Claims (20)

1. 複数の携帯型の情報処理装置を含む通信システムであって、
   前記情報処理装置はそれぞれ、
   近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、
   不特定の他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段と、
   ユーザの操作に基づいて、前記受信手段により受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段とを備え、
   前記送信手段は、再度、近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対して、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、通信システム。
2. 情報処理装置のコンピュータを、
   近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、
   不特定の他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段、および
   ユーザの操作に基づいて、前記受信手段により受信されたデータによって示される内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段として機能させ、
   前記送信手段は、再度、近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対して、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理プログラム。
3. 前記コンピュータを、
   他の情報処理装置の前記送信手段により送信された評価データで示される評価の内容を出力装置に出力させる出力制御手段としてさらに機能させる、請求項２に記載の情報処理プログラム。
4. 前記出力制御手段は、前記評価データで示される評価の対象となったデータに基づく画像とともに、前記評価の内容を表示装置に表示させる、請求項３に記載の情報処理プログラム。
5. 前記コンピュータを、
   前記受信手段によって受信されるデータに含まれている前記評価データが、当該評価データの受信時以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段としてさらに機能させ、
   前記出力制御手段は、前記宛先判別手段による判別結果が肯定である場合、前記評価の内容を前記出力装置に出力させる、請求項３に記載の情報処理プログラム。
6. 前記送信手段は、前記評価データ生成手段により評価データが生成された後、前記近距離に他の情報処理装置が存在するようになったとき、当該他の情報処理装置に対して当該評価データを自動的に送信する、請求項２ないし５のいずれかに記載の情報処理プログラム。
7. 前記評価データ生成手段は、前記送信手段による送信および前記受信手段による受信が可能でない状態に移行した後に、前記評価データを生成し、
   前記送信手段は、当該送信手段による送信および前記受信手段による受信が可能である状態に移行した後に、前記評価データ生成手段により生成された評価データを送信する、請求項２ないし６のいずれかに記載の情報処理プログラム。
8. 前記評価データ生成手段は、前記受信手段によって受信されたデータが、以前に当該受信手段によって受信した実績がある場合に、ユーザの操作に基づいて、当該データによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する、請求項２ないし請求項７のいずれかに記載の情報処理プログラム。
9. 前記評価データ生成手段は、
   ユーザの操作に基づいて、前記受信手段により受信されたデータに基づいて示されるデータ内容に対しての当該ユーザの評価として、第１の評価と第２の評価の何れか一方を選択する手段および
   前記第１の評価が選択された場合に前記評価データを作成する手段を含み、
   前記出力制御手段は、前記評価データで示される第１の評価の内容を前記出力装置に出力させる、請求項３に記載の情報処理プログラム。
10. 前記評価データ生成手段は、前記評価データとして、当該評価データが示す評価の対象となったデータの送信元を示す送信元データを生成し、
    前記送信手段は、前記評価データ生成手段により生成された送信元データを送信し、
    前記コンピュータを、
    前記受信手段によって受信されるデータに含まれる前記送信元データに基づいて、前記評価データが、当該評価データの受信時以前に自機の送信手段によって送信されたデータに対しての評価データであるか否かを判別する宛先判別手段としてさらに機能させ、
    前記出力制御手段は、前記宛先判別手段による判別結果が肯定である場合、前記第１の評価の内容を前記出力装置に出力させる、請求項９に記載の情報処理プログラム。
11. 前記データは、ユーザの操作に基づいて前記情報処理装置で作成されたユーザ作成データである、請求項２ないし１０のいずれかに記載の情報処理プログラム。
12. 前記コンピュータを、
    少なくとも前記受信手段により受信されたデータが所定の条件を満たすか否かを判別する評価可否条件判別手段と、
    前記評価可否条件判別手段による判別結果が肯定である場合、前記評価データ生成手段により評価データが生成されるためのユーザの操作を許可する許可手段としてさらに機能させる、請求項２ないし１１のいずれかに記載の情報処理プログラム。
13. 前記評価可否条件判別手段は、前記受信手段により受信されたデータに、当該データの内容に対してのユーザの評価を許可することを示す許可データが含まれているか否かを判別する、請求項１２に記載の情報処理プログラム。
14. 前記評価可否条件判別手段は、前記受信手段により受信されたデータに、当該データの内容に対するユーザの評価を許可することを示す第１許可データが含まれており、かつ、自装置に、データの内容に対するユーザの評価を許可することを示す第２許可データが設定されているか否かを判別する、請求項１２に記載の情報処理プログラム。
15. 前記評価可否条件判別手段は、前記受信手段により受信されたデータに対して、前記評価データ生成手段により評価データが生成されていないか否かを判別する、請求項１２に記載の情報処理プログラム。
16. 前記評価可否条件判別手段は、前記受信手段により受信されたデータに対して、前記評価データ生成手段により評価データが生成されているときに、当該データの少なくとも一部が変更されているか否かを判別する、請求項１２に記載の情報処理プログラム。
17. 前記コンピュータを、
    前記評価データを取得した回数を累計する評価回数累計手段としてさらに機能させ、
    前記出力制御手段は、前記評価回数の累計を前記出力装置に出力させる、請求項３、４、９、１０のいずれかに記載の情報処理プログラム。
18. 複数の携帯型の情報処理装置を含む情報処理システムを制御する情報処理方法であって、
    近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対してデータを自動的に送信する送信ステップと、
    不特定の他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信ステップと、
    ユーザの操作に基づいて、前記受信ステップにおいて受信されたデータによって示されるデータ内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成ステップとを備え、
    前記送信ステップは、再度、近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対して、前記評価データ生成ステップにおいて生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理方法。
19. 近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、
    不特定の他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段と、
    ユーザの操作に基づいて、前記受信手段により受信されたデータによって示される内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段とを備え、
    前記送信手段は、再度、近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対して、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理装置。
20. 近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対してデータを自動的に送信する送信手段と、
    不特定の他の情報処理装置の前記送信手段により送信されたデータを自動的に受信する受信手段と、
    ユーザの操作に基づいて、前記受信手段により受信されたデータによって示される内容に対する当該ユーザの評価を示す評価データを生成する評価データ生成手段とを備え、
    前記送信手段は、再度、近距離に存在する不特定の他の情報処理装置と自動的に接続し、接続した他の情報処理装置に対して、前記評価データ生成手段により生成された評価データを、当該評価データにより示される評価の対象となったデータの送信元を指定して送信する、情報処理システム。

Images