JP5593566B2

JP5593566B2 - 情報処理システム、情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム

Info

Publication number: JP5593566B2
Application number: JP2010132760A
Authority: JP
Inventors: 秀樹紺野
Original assignee: Nintendo Co Ltd
Current assignee: Nintendo Co Ltd
Priority date: 2010-06-10
Filing date: 2010-06-10
Publication date: 2014-09-24
Anticipated expiration: 2030-06-10
Also published as: US8990299B2; JP2011258044A; US20110307554A1

Description

この発明は、情報処理システムおよび情報処理装置に関し、特に、例えば、互いに無線通信可能な複数の携帯型の情報処理装置等を備える、情報処理システム、情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラムに関する。

従来より、情報処理装置が近接した場合に、自動的に通信を実行するシステムが存在する。例えば、特開２０００−１８１８２２号公報においては、携帯型のデータ送受信端末装置が示されており、通信可能エリア内に存在する他の携帯型のデータ送受信端末装置に自動的に送信するものが記載されている。

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

特許文献１に示された方式においては、携帯型のデータ送受信端末装置のユーザが一旦データを送信すると、他の携帯型のデータ送受信端末装置に際限なく、送信されていくことになるため、ユーザ等がデータをある程度の範囲に設定して送信することを希望する場合であってもその意図を反映させることができなかった。

本発明の目的は、上記のような問題を解決するためになされたものであって、データを送信する送信者の意図を反映させた効率的なデータ通信を実行することが可能な情報処理システムおよび情報処理装置を提供することである。

この本発明の第１の局面に従う情報処理システムは、複数の情報処理装置を含む、情報処理システムであって、情報処理装置は、それぞれ、データを伝播させるための伝播情報を送信すべき譲渡データに設定可能な設定手段と、設定手段により伝播情報が設定された譲渡データを他の情報処理装置に送信する送信手段と、他の情報処理装置の送信手段により送信された設定手段により伝播情報が設定された譲渡データを受信する受信手段と、受信手段によって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定する伝播判定手段とを含む。送信手段は、伝播判定手段による判定結果が肯定である場合に、受信手段によって受信された譲渡データをさらに他の情報処理装置に送信する。

第１の局面によれば、情報処理システムの情報処理装置は、譲渡データにデータを伝播させるための伝播情報を設定して送信することが可能であり、受信した情報処理装置は、譲渡データに設定された伝播情報に基づいて伝播させるか否かを判定して、判定結果が肯定である場合に譲渡データを伝播させるため、譲渡データが際限なく、他の情報処理装置に送信されることを抑制して、送信者の意図を反映させた効率的なデータ通信を実行することが可能である。

好ましい、第２の局面によれば、情報処理装置は、伝播判定手段による判定結果が肯定である場合に、受信された譲渡データに含まれる伝播情報を更新する伝播情報更新手段をさらに含み、送信手段は、伝播判定手段による判定結果が肯定である場合に、伝播情報更新手段により更新された伝播情報を含む受信手段によって受信された譲渡データをさらに他の情報処理装置に送信する。

第２の局面によれば、伝播情報更新手段により、譲渡データに含まれる伝播情報が更新されるため、譲渡データが際限なく、他の情報処理装置に送信されることを抑制して、送信者の意図を反映させた効率的なデータ通信を実行することが可能である。

好ましい第３の局面によれば、送信手段により送信された、伝播情報更新手段により更新された伝播情報を含む受信手段によって受信された譲渡データは記憶手段に記憶される。

好ましい第４の局面によれば、情報処理装置は、記憶手段に記憶された送信された譲渡データを読み出して、表示手段に表示するアクセス手段をさらに含む。

第３および第４の局面によれば、送信手段により送信された譲渡データは、記憶手段に記憶され、記憶された譲渡データが表示手段に表示されるため、伝播情報を含む譲渡データの送信を把握することが可能である。

好ましい第５の局面によれば、設定手段は、データを送信する回数を規定する送信情報を送信すべき譲渡データに設定可能であり、情報処理装置は、設定手段により設定された送信情報を含む譲渡データの送信情報に基づいて、当該譲渡データを送信させるか否かを判定する送信判定手段をさらに含み、送信手段は、送信判定手段による判定結果が肯定である場合に、譲渡データを他の情報処理装置に送信する。

第５の局面によれば、譲渡データにデータを送信する回数を規定する送信情報を設定して送信することが可能であり、受信した情報処理装置は、譲渡データに設定された送信情報に基づいて送信させるか否かを判定して、判定結果が肯定である場合に譲渡データを送信させるため、譲渡データの伝播と、送信とを切り分けたデータ通信が可能であり、効率的なデータ通信が可能である。さらに、譲渡データの伝播と送信に関する情報をそれぞれ設定することができるため、多様なデータ通信が可能である。

好ましい第６の局面によれば、情報処理装置は、送信手段による送信が成功したか否かを判定する送信成功判定手段と、送信成功判定手段による判定結果が肯定である場合に、譲渡データに含まれる送信情報を更新する送信情報更新手段とをさらに含み、送信判定手段は、送信情報更新手段により更新された送信情報に基づいて、譲渡データを再度送信させるか否かを判定する。

第６の局面によれば、譲渡データの送信が成功した場合に、送信情報更新手段により、譲渡データに含まれる送信情報が更新されるため、譲渡データが際限なく、他の情報処理装置に送信されることを抑制して、送信者の意図を反映させた効率的なデータ通信を実行することが可能である。

好ましい第７の局面によれば、伝播情報および送信情報は、それぞれ伝播回数および送信回数を規定し、設定手段は、伝播回数が１回以上の場合には、送信回数が１回となるように設定する。

第７の局面によれば、伝播回数が１回以上の場合には、送信回数が１回となるように設定されることにより、譲渡データを伝播させる場合には、送信回数を制限することにより譲渡データが伝播される範囲を制限することが可能となり、データを送信する送信者の意図を反映させた効率的なデータ通信を実行することが可能である。

好ましい第８の局面によれば、情報処理装置は、譲渡データを利用可能なアプリケーションプログラムを実行可能であり、送信手段は、アプリケーションプログラムの実行の有無に関わらず、伝播判定手段による判定結果が肯定である場合に、受信手段によって受信された譲渡データをさらに他の情報処理装置に送信する。

第８の局面によれば、譲渡データを送信するためにアプリケーションプログラムを実行しておく必要がないため、譲渡データを気軽に他の情報処理装置に送信することが可能である。

好ましい第９の局面によれば、情報処理装置は、伝播判定手段による判定結果が肯定である場合に、受信手段によって受信された譲渡データを記憶手段の受信したデータを記憶する受信記憶領域に記憶させるとともに、記憶手段の送信するデータを記憶する送信記憶領域に受信手段によって受信された譲渡データを複製して記憶させるデータ格納手段をさらに含む。

好ましい第１０の局面によれば、情報処理装置は、近距離無線通信を用いて通信可能な複数の情報処理装置のうちの他の情報処理装置を探索する無線モジュールをさらに含み、データ格納手段により譲渡データを送信記憶領域に記憶させた後、無線モジュール以外の本体部はスリープ状態に遷移する。

好ましい第１１の局面によれば、無線モジュールは、近距離無線通信を用いて通信可能な他の情報処理装置を繰り返して探索し、他の情報処理装置と通信可能になったときに、他の情報処理装置との間でデータ通信を実行するように送信手段に指示する。

第９〜第１１の局面によれば、本体部は、通信可能な情報処理装置が探索されるまで、スリープ状態に遷移し、他の情報処理装置と通信可能になったときに、譲渡データを送信することが可能であるため、消費電力を低減させたデータ通信を実行することが可能である。

この本発明の第１２の局面に従う情報処理装置は、データを伝播させるための伝播情報を送信すべき譲渡データに設定可能な設定手段と、設定手段により伝播情報が設定された譲渡データを他の情報処理装置に送信する送信手段と、他の情報処理装置の送信手段により送信された設定手段により伝播情報が設定された譲渡データを受信する受信手段と、受信手段によって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定する伝播判定手段とを備え、送信手段は、伝播判定手段による判定結果が肯定である場合に、受信手段によって受信された譲渡データをさらに他の情報処理装置に送信する。

この発明の第１３の局面に従う情報処理装置の制御方法は、データを伝播させるための伝播情報を送信すべき譲渡データに設定するステップと、設定するステップにより伝播情報が設定された譲渡データを他の情報処理装置に送信するステップと、他の情報処理装置により送信された伝播情報が設定された譲渡データを受信するステップと、受信するステップによって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定するステップとを備え、送信するステップは、判定するステップによる判定結果が肯定である場合に、受信するステップにより受信された譲渡データをさらに他の情報処理装置に送信する。

この発明の第１４の局面に従う情報処理装置の制御プログラムは、コンピュータに、データを伝播させるための伝播情報を送信すべき譲渡データに設定するステップと、設定するステップにより伝播情報が設定された譲渡データを他の情報処理装置に送信するステップと、他の情報処理装置により送信された伝播情報が設定された譲渡データを受信するステップと、受信するステップによって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定するステップとの処理を実行させ、送信するステップは、判定するステップによる判定結果が肯定である場合に、受信するステップにより受信された譲渡データをさらに他の情報処理装置に送信する、処理を実行させる。

第１２〜第１４の局面によれば、情報処理装置は、譲渡データにデータを伝播させるための伝播情報を設定して送信することが可能であり、また、譲渡データを受信した場合には、譲渡データに設定された伝播情報に基づいて伝播させるか否かを判定して、判定結果が肯定である場合に譲渡データを伝播させるため、譲渡データが際限なく、他の情報処理装置に送信されることを抑制して、送信者の意図を反映させた効率的なデータ通信を実行することが可能である。

上述の記載においては、本発明の理解を助けるために後述の実施形態との対応関係を示すための参照符号および補足説明等を付したが、これらは本発明を何ら限定するものではない。

本発明に従えば、データに伝播情報を設定して、当該伝播情報に基づいてデータを伝播させるかどうかを判断するため、際限なく送信されることはなく効率的なデータ通信を実行することが可能である。

本発明に係る情報処理システムの典型例について説明する図である。本発明の実施の形態に従うゲーム装置１の構成の概略ブロック図である。本発明の実施の形態に従う無線通信モジュール３８の構成について説明する図である。本発明の実施の形態に従う保存用データメモリ３４のメモリマップについて説明する図である。本発明の実施の形態に従うゲーム装置１における交換データの授受を実行する機能ブロックについて説明する図である。本発明の実施の形態に従うゲーム装置の本体部３９の機能ブロックの詳細について説明する図である。本発明の実施の形態に従う携帯端末間処理を実行する無線通信モジュール３８の機能ブロックの詳細について説明する図である。本発明の実施の形態に従う携帯端末間処理の交換データの授受処理を実行するデータ通信実行処理部２０８の詳細について説明する図である。本発明の実施の形態に従う交換データ保存領域８０の送信ＢＯＸへの交換データの格納処理について説明するフロー図である。本発明の実施の形態に従うアプリケーションに対応付けられた送信ＢＯＸおよび受信ＢＯＸを説明する概念図である。本発明の実施の形態に従う送信ＢＯＸにデータが格納された場合を説明する図である。本発明の実施の形態に従う送信ＢＯＸの送信ＢＯＸスロットに格納されたデータのデータ構造を説明する図である。アプリケーションにより交換データ保存領域８０の送信ＢＯＸに交換データを格納する場合について説明する図である。無線通信モジュール３８への通信設定処理について説明するフロー図である。ＣＰＵ３１（通信設定処理部２０４）における通信設定処理のフロー図である。通信設定処理によりＲＡＭ６６に格納されたデータの概念図について説明する図である。本発明の実施の形態に従う無線通信モジュール３８で実行する無線通信のフロー図である。本発明の実施の形態に従う携帯端末間通信について説明するフロー図である。本発明の実施の形態に従う携帯端末間通信においてゲーム装置において送信される送信無線フレームの構成について説明する図である。ベンダ特定ＩＤデータＤ４の構成について説明する図である。フィルタリング用データ保存領域６８で保存されているアプリケーションＩＤの状態を説明する概念図である。本発明の実施の形態に従うＭＡＣアドレスを比較する場合の概念図である。本発明の実施の形態に従うＭＡＣアドレスを比較する場合の別の概念図である。アプリケーションＩＤ判定部２３０における全体のフロー図である。本発明の実施の形態に従う比較対象となるベンダ特定ＩＥの比較について説明する図である。本発明の実施の形態に従う第１アルゴリズムに従うＩＤリスト比較処理について説明するフロー図である。本発明の実施の形態に従うＩＤデータの比較について説明する図である。本発明の実施の形態に従うＩＤデータのさらに別の比較について説明する図である。本発明の実施の形態に従う第２アルゴリズムに従うＩＤリスト比較処理について説明するフロー図である。本発明の実施の形態に従う送受信条件データであるセンドフラグデータおよびレシーブフラグデータの比較について説明する図である。本発明の実施の形態に従う取得条件を満たしているか否かに関する条件データの比較について説明する図である。本発明の実施の形態に従う取得条件データの具体例について説明する図である。図３２で説明した取得条件データに基づく条件データの比較の具体例について説明する図である。本発明の実施の形態に従う取得条件データの別の具体例について説明する図である。図３４で説明した取得条件データに基づく条件データの比較の具体例について説明する図である。本発明の実施の形態に従うアプリケーションＩＤを比較する場合の概念図である。本発明の実施の形態に従うゲーム装置間における交換データの交換処理について説明する図（その１）である。本発明の実施の形態に従うゲーム装置間における交換データの交換処理について説明する図（その２）である。本発明の実施の形態に従うゲーム装置間における交換データの交換処理について説明する図（その３）である。本発明の実施の形態に従うデータ授受処理のフロー図である。本発明の実施の形態に従うフレンド認証処理のフロー図である。本発明の実施の形態に従うフレンド認証処理のデータの流れについて説明する図である。本発明の実施の形態に従う送信スロット作成の処理について説明するフロー図である。送信無線フレームの比較に基づく交換データを授受することが可能なアプリ（交換データ授受アプリとも称する）を確認する処理を模式的に説明する図である。本発明の実施の形態に従う送信スロットの作成の概念図である。本発明の実施の形態に従う別の送信スロットの作成の概念図である。本発明の実施の形態に従う送信スロットの作成の具体例について説明する図である。本発明の実施の形態に従う送信ＢＯＸに格納されたデータと、フレンドとの関係について説明する図である。本発明の実施の形態に従う送信データリストの作成処理について説明するフロー図である。本発明の実施の形態に従う送信データリストについて説明する図である。本発明の実施の形態に従う送受信データリスト分析処理について説明するフロー図である。本実施の形態に従う送受信データリストの送受信の流れについて説明する図である。本発明の実施の形態に従う送受信実行処理について説明するフロー図である。本発明の実施の形態に従う送信データリスト送信判定処理を説明するフロー図である。本発明の実施の形態に従う受信データリスト受信判定処理を説明するフロー図である。本発明の実施の形態に従う送受信実行処理について親機側の処理を部分的に説明するフロー図である。本発明の実施の形態に従う送受信実行処理のデータの流れについて説明する図である。本発明の実施の形態に従うデータ格納処理のフロー図である。本発明の実施の形態に従う送信データリストフラグ判定処理のフロー図である。本発明の実施の形態に従う送信データリストフラグ条件判定処理のフロー図である。本発明の実施の形態に従う受信データリストフラグ判定処理について説明するフロー図である。本発明の実施の形態に従う受信データリストフラグ条件判定処理のフロー図である。本発明の実施の形態に従う送受信実行処理のデータの流れについて説明する別の図である。本発明の実施の形態に従うデータ格納処理における受信データの受信ＢＯＸへの格納について説明する概念図である。本発明の実施の形態に従うデータ格納処理における交換データの送信回数の更新および配列の変更について説明する概念図である。本発明の実施の形態に従う受信データ判定処理のフロー図である。本発明の実施の形態に従う伝播条件を満たしている受信データの流れについて説明する図である。本発明の実施の形態に従う伝播回数が０より大きい交換データが送信ＢＯＸに格納されている場合の処理について説明する概念図である。本発明の実施の形態に従う交換データの伝播の概念図について説明する図である。本実施の形態に従うＭＡＣアドレス保存処理のフロー図である。本発明の実施の形態に従うデータ通知処理について説明するフロー図である。本発明の実施の形態に従う交換データ追加および消去処理のフロー図である。本発明の実施の形態に従う通信条件設定処理のフロー図である。本発明の実施の形態に従う通信条件設定画面を説明する図である。本発明の実施の形態に従うＢＯＸアクセス処理のフロー図である。本発明の実施の形態に従うＢＯＸ探索処理を説明するフロー図である。本発明の実施の形態に従うＢＯＸ表示画面を説明する図である。本発明の実施の形態に従う通信相手サーチ処理の１周期の期間について説明する図である。本発明の実施の形態に従う通信相手サーチ処理（１）を示すフロー図である。本発明の実施の形態に従う通信相手サーチ処理（２）を示すフロー図（その１）である。本発明の実施の形態に従う通信相手サーチ処理（２）を示すフロー図（その２）である。本発明の実施の形態に従う交換データの授受のデータの遣り取りについて説明する図である。本発明の実施の形態に従うゲーム装置１と固定端末機器５との通信処理の概略について説明する図である。本発明の実施の形態に従うゲーム装置１における配信データを受信する機能ブロックについて説明する図である。本発明の実施の形態に従う携帯固定端末間処理を実行する無線通信モジュール３８の機能ブロックの詳細について説明する図である。本発明の実施の形態に従う携帯固定端末間通信について説明する図である。本発明の実施の形態に従う携帯固定端末間通信においてゲーム装置においてビーコンとして受信される配信無線フレームの構成について説明する図である。本発明の実施の形態に従う配信データを取得するデータ取得処理のフロー図である。本発明の実施の形態に従う配信データのデータ格納処理について説明するフロー図である。本発明の実施の形態に従う固定端末サーチ処理のフロー図である。本発明の実施の形態に従う配信データ取得のデータの遣り取りについて説明する図である。本発明の実施の形態に従うゲーム装置１と固定端末機器５＃との通信処理の概略について説明する図である。本発明の実施の形態に従うＭＡＣアドレスの更新について説明する図である。本発明の実施の形態に従うローカルアドレスの更新のフロー図である。本発明の実施の形態に従うＭＡＣアドレスの更新処理について説明する図である。本発明の実施の形態に従うＭＡＣアドレスリスト保存領域８８の構成について説明する図である。本発明の実施の形態に従うＭＡＣアドレスリストの消去を説明するフロー図である。

この発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。

＜全体構成＞
図１は、本発明に係る情報処理システムの典型例について説明する図である。

図１を参照して、この発明の実施の形態に従う本発明に係る情報処理システムは、複数の携帯型の情報処理装置を含む。本例においては、複数の携帯型の情報処理装置の一例として携帯ゲーム装置（以下、単にゲーム装置とも称する）１〜３が示されている。なお、ここでは、３台のゲーム装置が示されているが少なくとも２台有ればよい。また、さらに複数台のゲーム装置を設けた構成とすることも可能である。

なお、本例においては、本発明の実施の形態における情報処理システムにおいて、必須の構成物ではないが、携帯型の情報処理装置であるゲーム装置と無線通信可能な固定端末機器５を設ける。

ゲーム装置１〜３は、互いに無線通信を実行してデータの授受が可能であり、本例においては、ゲーム装置１（以下、単に、自機とも称する）と、他のゲーム装置および固定端末機器５と通信する場合について説明する。

また、図１においては、ゲーム装置１（自機）において、無線通信を実行する場合の通信可能範囲１０が点線で示されている。すなわち、図１の例においては、ゲーム装置１（自機）は、ゲーム装置２，３と、固定端末機器５とそれぞれ通信が可能な状態であることが示されている。なお、図１においては、自機のゲーム装置１の通信可能範囲１０に、ユーザ名「一郎」および「二郎」のゲーム装置２，３がそれぞれ存在し、ゲーム装置１は、ユーザ名「二郎」のゲーム装置３と無線通信している様子が示されている。

詳細については後述するが、ゲーム装置１とゲーム装置３とは、互いに無線通信を実行して、互いに有している後述する交換データを交換する。そして、ゲーム装置１，３は、交換した交換データを利用することが可能であるものとする。

また、後述するが、固定端末機器５は、周辺のゲーム装置に対して所定の配信データを配信する。そして、ゲーム装置は、固定端末機器５から配信された配信データを取得した場合には、取得した配信データを利用することが可能であるものとする。

＜ゲーム装置の構成＞
図２は、本発明の実施の形態に従うゲーム装置１の構成の概略ブロック図である。なお、ゲーム装置２，３についても同様の構成であるためその詳細な説明は省略する。

図２を参照して、ゲーム装置１は、ＣＰＵ３１と、メインメモリ３２と、メモリ制御回路３３と、保存用データメモリ３４と、プリセットデータ用メモリ３５と、メモリカードインターフェース（メモリカードＩ／Ｆ）３６と、無線通信モジュール３８と、リアルタイムクロック（ＲＴＣ）４０と、電源回路４１とを備えている。

ＣＰＵ３１は、プログラムを実行するための演算処理手段である。本発明の実施の形態では、当該プログラムは、ゲーム装置１内のメモリ（たとえば、保存用データメモリ３４）やメモリカード２６等に記録されている。なお、ＣＰＵ３１によって実行されるプログラムは、ゲーム装置１内のメモリに予め記録されていてもよいし、メモリカード２６から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。また、ＣＰＵ３１は、マルチタスク制御が可能である。具体的には、ゲーム処理を実行しつつ、バックグラウンドで、後述する交換データの授受処理を実行することができる。

ＣＰＵ３１には、メインメモリ３２、メモリ制御回路３３、およびプリセットデータ用メモリ３５が接続される。また、メモリ制御回路３３には、保存用データメモリ３４が接続される。

メインメモリ３２は、ＣＰＵ３１のワーク領域やバッファ領域として用いられる記憶手段である。すなわち、メインメモリ３２は、上記情報処理に用いられる各種データを記憶したり、外部（メモリカード２６や他の機器等）から取得されるプログラムを記憶したりする。本発明の実施の形態では、メインメモリ３２として、たとえばＰＳＲＡＭ（Pseudo-SRAM）を用いる。

保存用データメモリ３４は、後述するが、ＣＰＵ３１によって実行されるプログラムやカメラ２３によって撮影された画像のデータ等を記憶するための記憶手段である。

保存用データメモリ３４は、不揮発性の記憶媒体によって構成されており、たとえば本実施例ではＮＡＮＤ型フラッシュメモリで構成される。メモリ制御回路３３は、ＣＰＵ３１の指示に従って、保存用データメモリ３４に対するデータの読み出しおよび書き込みを制御する回路である。

プリセットデータ用メモリ３５は、ゲーム装置１において予め設定される各種パラメータ等のデータ（プリセットデータ）を記憶するための記憶手段である。プリセットデータ用メモリ３５としては、ＳＰＩ（Serial Peripheral Interface）バスによってＣＰＵ３１と接続されるフラッシュメモリを用いることができる。

メモリカードＩ／Ｆ３６は、ＣＰＵ３１に接続される。メモリカードＩ／Ｆ３６は、コネクタに装着されたメモリカード２６に対するデータの読み出しおよび書き込みを、ＣＰＵ３１の指示に応じて行なう。

無線通信モジュール３８は、後述するが同種のゲーム装置等との間で無線通信を行なう機能を有する。

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

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

Ｉ／Ｆ回路４２は、マイク４３からの音声信号の入力を受ける音声入力制御回路５４と、アンプ４４に対する音声信号の出力の制御を行なう音声出力制御回路５６とを含む。

音声入力制御回路５４は、マイク４３からの音声信号の入力レベルを検知して、音声信号に対するＡ／Ｄ変換を行なったり、音声信号を所定の形式の音声データに変換したりする。

音声出力制御回路５６は、出力信号がステレオ設定あるいはモノラル設定に従って、アンプ４４に出力する音声信号を調整する。

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

カメラ２３は、ＣＰＵ３１に接続される。カメラ２３は、ＣＰＵ３１の指示に応じて画像を撮影し、撮影した画像データをＣＰＵ３１に出力する。たとえば、ＣＰＵ３１は、カメラ２３に対して撮影指示を行ない、撮影指示を受けたカメラが画像を撮影して画像データをＣＰＵ３１に送る。

また、ＬＣＤ１２は、ＣＰＵ３１に接続される。ＬＣＤ１２は、ＣＰＵ３１の指示に従って図示しないが操作画面等を表示する。

メモリカード２６は、図示しないコネクタと着脱可能であり、コネクタと接続された場合にはメモリカードＩ／Ｆ３６と接続される。メモリカード２６は、ＲＯＭ２７と、バックアップＲＡＭ２８とが内蔵され、ＲＯＭ２７には、ゲーム装置１で実行するためのアプリケーション（以下、単にアプリとも称する）等が予め設定（記憶）されている。なお、ＲＯＭ２７には、ＲＯＭ２７に記憶されるアプリケーションを識別するための名称（タイトル）を意味する識別番号が記憶されている。また、バックアップＲＡＭ２８には、アプリケーションの途中のデータや結果データが記憶（セーブ）される。また、バックアップＲＡＭ２８は、後述するが、当該アプリケーションを実行した場合に他のゲーム装置に提供するデータ（以下、交換データとも称する）をゲーム装置に保存した場合には交換フラグデータを記憶する。

なお、典型的には、後述するアプリケーション識別情報（アプリケーションＩＤ）とは、アプリケーションを識別するための名称（タイトル）を意味するデータ（識別番号）を含むが、必ずしもそれに限られるものではなく、本実施例においては、アプリケーションを識別するための名称に加えて、交換データとして交換対象となるデータであるかを識別可能とするデータ（交換条件データ）をも含むものとする。

図３は、本発明の実施の形態に従う無線通信モジュール３８の構成について説明する図である。

図３を参照して、本発明の実施の形態に従う無線通信モジュール３８は、ＣＰＵ６０と、ＲＦ−ＩＣ（Radio Frequency IC）６２と、メモリ制御部６４と、モジュールＩ／Ｆ７６と、各部と接続されている内部バス７４とを含む。

メモリ制御部６４は、ＲＡＭ６６と、無線通信に関するプログラムの少なくとも一部等が保存されるＲＯＭ７２とを含む。ＲＡＭ６６には、フィルタリング用データ保存領域６８と、ＭＡＣアドレスリスト保存領域７０，７０＃と、送信無線フレーム保存領域６７と、受信無線フレーム保存領域６９とが設けられる。

フィルタリング用データ保存領域６８は、後述するがＣＰＵ３１からの指示に従って登録された少なくとも１つ以上のフィルタリング用データを保存する領域である。フィルタリング用データは、交換データに設定されているデータであり、通信相手である他のゲーム装置等との間で実質的な通信を実行する前に交換データの交換等の処理が可能であるかどうかを判定するためのデータが含まれている。具体的には、フィルタリング用データには、交換データのアプリケーションを識別するための後述するアプリケーションＩＤが含まれている。

また、本例においては後述するが当該アプリケーションＩＤと他のアプリケーションＩＤとを比較する際の判定のアルゴリズムとして複数の判定方式を設けることが可能であり、フィルタリング用データの各々に含まれているアプリケーションＩＤを各判定方式に対応するリストとして纏めて保存することが可能である。そして、リスト毎に保存する際には、判定のアルゴリズムの方式を示す情報（アルゴリズム識別情報）を含むリストヘッダ情報がそれぞれのリストに対して設けられる。なお、リストヘッダ情報は、当該リストをさらに、交換データのアプリケーションの種別毎に分類するためのシステムフラグ情報を含む。

また、ＭＡＣアドレスリスト保存領域７０は、後述するがＣＰＵ３１からの指示に従って登録された他のゲーム装置のＭＡＣアドレスを保存する領域である。また、ＭＡＣアドレスリスト保存領域７０＃は、後述するがＣＰＵ３１からの指示に従って登録された固定端末機器５のＭＡＣアドレスを保存する領域である。当該ＭＡＣアドレスは、後述するが通信相手である他のゲーム装置等との間では実質的な通信を実行する前に以前に通信した通信相手であるかどうかを判定するＭＡＣアドレスフィルタリング処理の際に用いられる。

なお、本例においては、他のゲーム装置のＭＡＣアドレスを保存する領域と、固定端末機器のＭＡＣアドレスを保存する領域とをそれぞれ分けて設けた構成について説明するが同じ領域に保存するようにすることも可能である。

送信無線フレーム保存領域６７は、後述するがＲＦ−ＩＣ６２を介して外部のゲーム装置に送信する無線フレーム（送信無線フレームとも称する）のデータを保存する領域である。また、受信無線フレーム保存領域６９は、後述するが外部のゲーム装置から送信され、ＲＦ−ＩＣ６２を介して受信された無線フレーム（受信無線フレームとも称する）のデータを保存する領域である。なお、受信無線フレーム保存領域６９には、後述するが、固定端末機器５から送信された配信無線フレームのデータも保存される。

ＣＰＵ６０は、無線通信に関するプログラムを実行するための演算処理手段である。
ＣＰＵ６０は、メモリ制御部６４に格納されているＲＯＭ７２から読出されたプログラムによって無線通信の所定の機能を実現することが可能である。具体的には、一例としてＲＯＭ７２には後述する携帯端末間通信を実行するためのアプリケーションおよび携帯固定端末間通信を実行するためのアプリケーションが格納されている。

ＣＰＵ６０が当該携帯端末間処理を実行するためのアプリケーションを実行することにより、無線通信モジュール３８において交換データを交換する通信相手を探索する処理（以下、交換相手探索処理とも称する）が実行される。そして、無線通信モジュール３８における交換相手探索処理により交換データを交換する通信相手が見つかった場合には、後述するがゲーム装置１の本体側のＣＰＵ３１に通知されて、交換データの授受処理が実行される。本実施例においては、本体側のＣＰＵ３１の指示に従って通信相手との接続を確立する処理が実行されて、接続が確立された後、交換データの授受処理が実行される。

同様に、ＣＰＵ６０が携帯固定端末間通信を実行するためのアプリケーションを実行することにより、無線通信モジュール３８において、配信データを提供する通信相手を探索する処理（以下、配信相手探索処理とも称する）が実行される。そして、無線通信モジュール３８における配信相手探索処理により配信データを提供する通信相手が見つかった場合には、後述するがゲーム装置１の本体側のＣＰＵ３１に通知されて、配信データを取得する処理が実行される。本実施例においては、本体側のＣＰＵ３１の指示に従って通信相手である固定端末機器との接続を確立する処理が実行されて、接続が確立された後、配信データを取得する処理が実行される。

ＲＦ−ＩＣ６２は、例えば、他のゲーム装置に対してＣＰＵ６０の指示により送信されるデータを変調して、アンテナ６１から電波を送信する。ただし、電波強度は、非常に微弱で、電波法においてユーザが無免許で利用できる程度の小さい値に設定されている。また、無線通信モジュール３８は、例えば、他のゲーム装置から送信された電波をアンテナ６１で受信して、ＲＦ−ＩＣ６２において受信データが復調される。復調された受信データは、メモリ制御部６４のＲＡＭ６６に格納される。これにより、無線通信モジュール３８は、例えばデータ伝送距離が１０ｍの範囲内の近距離無線通信を行うことができる。

モジュールＩ／Ｆ７６は、無線通信モジュール３８とゲーム装置１のＣＰＵ３１等の本体部とのインターフェースであり、無線通信モジュールのアンテナ６１で受信し、ＲＡＭ６６に格納された他のゲーム装置から送信された交換データは、モジュールＩ／Ｆ７６を介してゲーム装置１の本体側のＣＰＵ３１に出力され、メインメモリ３２に格納される。また、ＣＰＵ３１からの指示に従って、保存用データメモリ３４に格納されている後述する交換データがモジュールＩ／Ｆ７６を介して無線通信モジュール３８に入力されてメモリ制御部６４のＲＡＭ６６に一時的に格納され、上述したように送信されるデータとしてアンテナ６１から例えば外部の他のゲーム装置に出力することが可能である。なお、受信した交換データは、一時的にＲＡＭ６６に格納した後、メインメモリ３２に格納しても良いし、直接メインメモリ３２に格納するようにしても良い。また、送信される交換データについてもＲＡＭ６６に一時的に格納しても良いし、格納することなく送信するようにしても良い。本例においては、送信および受信する交換データについてはＲＡＭ６６に一時的に格納する場合については説明しないものとする。

なお、外部の他のゲーム装置に送信するデータとしては、モジュールＩ／Ｆ７６を介してゲーム装置１の本体側のＣＰＵ３１の指示により入力されたデータに限られず、無線通信モジュール３８内でＣＰＵ６０の指示によりメモリ制御部６４に設けられたＲＡＭ６６等に格納されているデータに基づいて生成した送信無線フレームを送信データとして出力する場合もある。後述するが当該送信無線フレームは、子機側からの接続要求信号として出力される。

図４は、本発明の実施の形態に従う保存用データメモリ３４のメモリマップについて説明する図である。

図４を参照して、保存用データメモリ３４は、交換データ保存領域８０と、受信データ保存領域８２と、内蔵アプリ保存領域８４と、システムプログラム保存領域８６と、ＭＡＣアドレスリスト保存領域８８，８８＃と、フレンドコードリスト保存領域８９とを含む。

交換データ保存領域８０は、他のゲーム装置との間でのデータの交換を実行する際に用いられる交換データが保存される領域である。

この交換データ保存領域８０には、後述するが複数の記憶領域である複数の送信ＢＯＸが設けられている。送信ＢＯＸは、各アプリケーション毎に設けられる。この各送信ＢＯＸは、アプリケーションで利用可能なデータを他のゲーム装置に提供する交換データとして格納する領域であり、実際にアプリケーションで利用されるデータは、当該アプリケーションを識別するデータ（例えばアプリケーションＩＤ）に対応付けられた送信ＢＯＸに格納される。また、後述するが、各送信ＢＯＸには、複数の交換データを格納することが可能である。

なお、上述したようにアプリケーションＩＤは、本例において、単にアプリケーションを識別するデータを含むが、必ずしもそれに限られるものではなく、後述するが交換データが交換対象となるデータであるかを識別可能とするデータ（交換条件データ）も含むものとする。また、後述するが、当該アプリケーションＩＤを無線通信モジュール３８のフィルタリング用データ保存領域６８に保存する際に、判定のアルゴリズムの方式毎のリストとして保存する際には、当該アプリケーションＩＤをどのリストに保存するべきかを識別するために判定のアルゴリズムの方式を示す情報（アルゴリズム識別情報）がアプリケーションＩＤと対応付けられて格納することも可能である。また、後述する内蔵アプリ保存領域８４に格納されているアプリケーション（内蔵アプリとも称する）と、それ以外のアプリケーション例えば、メモリカード２６に保存されたアプリケーション（ゲームアプリとも称する）とを区別する、すなわちアプリケーションの種別を判別するためのシステムフラグ情報もアプリケーションＩＤと対応付けられて格納することも可能である。なお、本例においては、内蔵アプリと、それ以外のアプリケーション例えば、メモリカード２６に保存されたアプリケーション（ゲームアプリとも称する）とを区別するためにシステムフラグ情報が用いられる場合について説明するが、さらに別のアプリケーション例えば、固定端末機器から配信されるアプリケーションプログラム等については別のシステムフラグ情報を割り当てて用いるようにすることも可能である。

また、受信データ保存領域８２は、他のゲーム装置との間でのデータの交換の際に、他のゲーム装置から受信した交換データを保存する領域である。この受信データ保存領域８２には、後述するが複数の記憶領域である複数の受信ＢＯＸが設けられている。受信ＢＯＸは、各アプリケーション毎に設けられる。この各受信ＢＯＸは、他のゲーム装置から提供された交換データを受信データとして格納して保存する領域であり、実際にアプリケーションで利用されるデータは、当該アプリケーションを識別するデータ（例えばアプリケーションＩＤ）に対応付けられた受信ＢＯＸに格納される。また、後述するが、各受信ＢＯＸには、複数の受信データを格納することが可能である。

また、内蔵アプリ保存領域８４は、ゲーム装置１に格納されている、当該ゲーム装置１上で実行する複数のアプリケーション等が保存されている領域である。ゲーム装置１は、前述のとおり、メモリカード２６に保存されたアプリケーションを実行することができるが、この内蔵アプリ保存領域８４に保存されたアプリケーションを実行することも可能である。内蔵アプリ保存領域８４に保存されるアプリケーションは、予め保存されていても良いし、インターネット等を介して外部からダウンロードして保存するようにしてもよい。なお、内蔵アプリ保存領域８４には、アプリケーション本体用の保存領域と、各アプリケーション毎に設けられた、当該アプリケーションが占有的に使用するセーブデータを保存するための保存領域（アプリケーション用記憶領域）とが設けられる。

したがって、内蔵アプリ保存領域８４に複数のアプリケーションが保存されている場合には、それぞれのアプリケーションに対応して設けられた複数の保存領域が設けられる。

また、システムプログラム保存領域８６は、情報処理装置の本体機能を実現するための本体機能プログラム、例えば、起動するアプリケーションを選択するためのメニュープログラムや、交換データを有する通信相手と互いに交換データの授受を実行するデータ授受処理および配信データを通信相手から取得するデータ取得処理を実行するためのプログラム等が保存されている領域である。

また、ＭＡＣアドレスリスト保存領域８８は、無線通信モジュール３８において、以前に通信した通信相手である他のゲーム装置を識別することが可能な装置識別情報であるＭＡＣアドレスを保存する領域である。また、ＭＡＣアドレスリスト保存領域８８＃は、無線通信モジュール３８において、以前に通信した通信相手である固定端末機器を識別することが可能な装置識別情報であるＭＡＣアドレスを保存する領域である。後述するが、無線通信を実行する際の通信設定処理において、ＭＡＣアドレスリスト保存領域７０，７０＃に保存されているＭＡＣアドレスが当該ＭＡＣアドレスリスト保存領域８８，８８＃にそれぞれ保存される。

また、フレンドコードリスト保存領域８９は、フレンド登録した他のゲーム装置のフレンドコードが保存されている領域である。フレンドコードは、他のゲーム装置の所有者がフレンドであるかを識別するためのコードである。自己のフレンドコードは各ゲーム装置において一意に定められており、フレンドコードリスト保存領域８９にて保持されているものとする。すなわち、ゲーム装置毎にフレンドコードは異なる。フレンドコードリスト保存領域８９に対する他のゲーム装置のフレンドコードの登録の仕方は種々の方式があるが、例えば、内蔵アプリの中にフレンドコードの登録処理のためのアプリケーションプログラムが含まれているものとする。当該アプリケーションプログラムを実行することにより、図示しないが自己のフレンドコードが表示されるとともに、他のゲーム装置のフレンドコードの入力画面が表示されるものとする。そして、当該入力画面において、他のゲーム装置のフレンドコードを入力して登録することによりフレンドコードリスト保存領域８９に他のゲーム装置のフレンドコードが登録されるものとする。また、相手に自己のフレンドコードを伝達することにより、他のゲーム装置において同様の方式に従って、フレンドコードリスト保存領域８９に自己のフレンドコードが登録されることになる。なお、本例においては、ユーザがフレンドコードを入力して登録する場合について説明したが、無線通信で他のゲーム装置とフレンドコードを授受することによりフレンドコードリスト保存領域８９に他のゲーム装置のフレンドコードを登録するようにしても良い。例えば、他のゲーム装置と無線通信でゲームアプリを互いに実行した場合には、フレンドコードリスト保存領域８９に他のゲーム装置のフレンドコードを登録するようにしても良い。

本実施例におけるゲーム装置１のデータ通信は、大別すると他のゲーム装置との交換データの授受を実行するデータ通信と、固定端末機器からの配信データを受信するデータ通信とに分けることができる。

まず、本発明の実施の形態に従うゲーム装置１と他のゲーム装置との交換データの授受を実行するデータ通信について説明する。

＜ゲーム装置３との間で交換データの授受を実行する機能ブロックの説明＞
図５は、本発明の実施の形態に従うゲーム装置１における交換データの授受を実行する機能ブロックについて説明する図である。

図５を参照して、ゲーム装置１は、無線通信モジュール３８と、無線通信モジュール３８以外の本体部３９とで構成される。

本体部３９は、無線通信設定部２０５と、装置識別情報登録処理部２１１と、データ通信制御部２０９と、交換データ保存領域８０と、受信データ保存領域８２と、ＭＡＣアドレスリスト保存領域８８と、データ格納処理部２１０とを含む。

無線通信モジュール３８は、無線フレーム送受信部２２３と、交換データ通信判断部２２５と、フィルタリング用データ保存領域６８と、ＭＡＣアドレスリスト保存領域７０と、送信無線フレーム保存領域６７と、受信無線フレーム保存領域６９とを含む。

無線通信設定部２０５は、ＭＡＣアドレスリスト保存領域８８に格納されているＭＡＣアドレスリストをＭＡＣアドレスリスト保存領域７０に格納する。また、無線通信設定部２０５は、交換データ保存領域８０の送信ＢＯＸに保存されている交換データに設定されているフィルタリング用データをフィルタリング用データ保存領域６８に格納する。なお、フィルタリング用データ保存領域６８には、各送信ＢＯＸに含まれている少なくとも１つの交換データに設定されているフィルタリング用データがフィルタリング用データ保存領域６８に格納される。なお、フィルタリング用データをフィルタリング用データ保存領域６８に格納する際には、フィルタリング用データの各々に含まれているアプリケーションＩＤを判定のアルゴリズム毎のリストとして纏めて保存することが可能である。そして、リスト毎に保存する際には、判定のアルゴリズムの方式を示す情報（アルゴリズム識別情報）およびアプリケーションの種別を識別するシステムフラグ情報を含むリストヘッダ情報がそれぞれのリストに対して設けられる。

また、無線通信設定部２０５は、無線通信モジュール３８における無線通信を実行するための指示を無線フレーム送受信部２２３に出力する。

無線通信モジュール３８の無線フレーム送受信部２２３は、無線通信を実行する指示を受けてフィルタリング用データ保存領域６８に保存されているフィルタリング用データ、すなわち、フィルタリング用データに各々含まれているアプリケーションＩＤをシステムフラグ情報毎に分類し、さらに判定のアルゴリズム毎のリストとして纏めて保存したデータを含む送信無線フレームを設定して送信無線フレーム保存領域６７に格納するとともに、当該設定された送信無線フレームを用いて通信相手を探索する交換相手探索処理を実行する。本例においては、無線フレーム送受信部２２３は、通信相手として一例としてゲーム装置３に対して送信無線フレームを送信し、ゲーム装置３から送信された送信無線フレームすなわち受信無線フレームを受信するものとする。そして、無線フレーム送受信部２２３は、当該受信した受信無線フレームを受信無線フレーム保存領域６９に格納する。

交換データ通信判断部２２５は、受信した受信無線フレームに基づいて通信相手が交換データを交換する交換相手であるかどうかを判断し、交換相手であると判断された場合には、その旨を本体部３９に通知する。

具体的には、受信した受信無線フレームに含まれている装置識別情報であるＭＡＣアドレスがＭＡＣアドレスリスト保存領域７０に保存されているＭＡＣアドレスリストに登録されているかどうかを判断する。また、当該受信した受信無線フレームが交換データの授受に関する処理が可能な無線フレームであるかどうかを判定する。また、当該受信した受信無線フレームに含まれているアプリケーションＩＤと、送信無線フレーム保存領域６７に保存されている送信無線フレームに含まれているアプリケーションＩＤとを比較して、比較結果に基づいて、通信相手と交換データの交換が可能であるかどうかを判断する。

そして、交換データ通信判断部２２５は、受信した受信無線フレームに含まれているＭＡＣアドレスがＭＡＣアドレスリストに登録されておらず、また、当該受信した受信無線フレームが交換データの授受に関する処理が可能な無線フレームであり、また通信相手と交換データの交換が可能であると判断した場合には、交換データの交換が可能である旨の通知を本体部３９のデータ通信制御部２０９に出力する。なお、ここでは、３つの条件が満たされた場合に交換データの交換が可能である旨の通知を本体部３９のデータ通信制御部２０９に出力する場合について説明しているが、少なくとも１つの条件が満たされた場合に当該通知を出力するようにしても良い。

データ通信制御部２０９は、交換データ通信判断部２２５から出力された交換データの交換が可能である旨の通知を受けて、交換データ保存領域８０に保存されている交換データを送信するとともに、ゲーム装置３から交換データを受信する交換データの授受処理を実行する。

データ格納処理部２１０は、データ通信制御部２０９で受信した交換データについて、交換条件が満たされているかどうかを判定し、満たしていると判定する場合には、受信データ保存領域８２の交換データのアプリケーションＩＤに対応付けられて設けられた受信ＢＯＸに格納する。また、データ格納処理部２１０は、受信データ保存領域８２の受信ＢＯＸに格納された受信データに設定されている伝播回数を確認して、伝播条件を満たしているかどうかを判定し、満たしている場合には、受信データを他のゲーム装置に伝播するために、受信データをコピーして交換データ（伝播データ）として交換データ保存領域８０のアプリケーションＩＤに対応付けられて設けられた送信ＢＯＸに格納する。

装置識別情報登録処理部２１１は、データ通信制御部２０９により受信した交換データがデータ格納処理部２１０により受信データ保存領域８２の受信ＢＯＸに格納された場合には、交換相手であるゲーム装置３の装置識別情報であるＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８に格納する。すなわち、装置識別情報を蓄積する。また、装置識別情報登録処理部２１１は、後述するが、受信した交換データが受信データ保存領域８２の受信ＢＯＸに格納される毎にＭＡＣアドレスリスト保存領域８８に交換相手であるゲーム装置の装置識別情報を追記することが可能である。すなわち、ＭＡＣアドレスリスト保存領域８８に交換相手であるゲーム装置の装置識別情報が追記されて登録されることは、装置識別情報に対応するゲーム装置との間で交換データの授受を実行したことの実行履歴が残されることを意味する。

そして、無線通信設定部２０５は、再び、ＭＡＣアドレスリスト保存領域８８に格納されているＭＡＣアドレスリストをＭＡＣアドレスリスト保存領域７０に格納し、無線通信モジュール３８における無線通信を実行するための指示を無線フレーム送受信部２２３に出力する。すなわち、上記で説明したのと同様の処理を繰り返す。

無線通信モジュール３８の無線フレーム送受信部２２３は、再び、送信無線フレームを設定して、当該設定された送信無線フレームを用いて通信相手を探索する交換相手探索処理を実行する。例えば、再び、本例において、ゲーム装置３に対して送信無線フレームを送信し、ゲーム装置３から送信された送信無線フレームすなわち受信無線フレームを受信するものとする。

交換データ通信判断部２２５は、上述したように、受信した受信無線フレームに含まれている装置識別情報であるＭＡＣアドレスがＭＡＣアドレスリスト保存領域７０に保存されているＭＡＣアドレスリストに登録されているかどうかを判断する。

その際、交換データ通信判断部２２５は、上述したように以前に交換データの授受を実行している場合には、ＭＡＣアドレスリストにゲーム装置３の装置識別情報であるＭＡＣアドレスが格納されているためＭＡＣアドレスに登録されていると判断し、その後のデータ通信である交換データの授受処理は実行しない。すなわち、一度通信を行った通信相手との通信を行わずに効率的なデータ通信を実行することが可能である。

なお、本体部３９と、無線通信モジュール３８とは独立して動作することが可能である。すなわち、本体部３９がスリープ状態に遷移している場合においても、無線通信モジュール３８は、設定された送信無線フレームを用いて通信相手を探索する交換相手探索処理を実行することが可能である。そして、交換可能な通信相手が見つかった場合にのみ、本体部３９に通知されて、通信相手との接続が確立されて、交換データの授受が実行される。したがって、例えば、本体部３９がスリープ状態等の省電力状態に遷移している場合に、無線通信モジュール３８における交換相手探索処理により通信相手が見つかった場合であっても交換が可能でなければ本体部３９に通知されて通信接続が確立されることはないため、ゲーム装置１全体における省電力を図ることが可能である。

以下、本体部３９および無線通信モジュール３８の各機能の詳細について具体的に説明する。

図６は、本発明の実施の形態に従うゲーム装置の本体部３９の機能ブロックの詳細について説明する図である。

図６を参照して、本例においては、一例として、ＣＰＵ３１がシステムプログラム保存領域８６に保存された本体機能プログラムおよびメモリカード２６のＲＯＭ２７に格納されているアプリケーションを実行することにより所定の機能を実現する場合について説明するが、必ずしもＣＰＵ３１により実現される場合に限られず、少なくとも一部の機能を専用のＩＣ（Integrated Circuit）を用いて実現するようにしても良い。ここでは、保存用データメモリ３４の交換データ保存領域８０、受信データ保存領域８２、ＭＡＣアドレスリスト保存領域８８，８８＃にアクセスする場合についてメモリ制御回路３３を介さない場合について示しているが、図１で説明したメモリ制御回路３３を介して保存用データメモリ３４に格納するようにしても良い。

なお、ここで、本体部３９の機能ブロックは、後述するが携帯端末間処理および携帯固定端末間処理の共通の機能として説明する。

本体部３９は、無線通信設定部２０５と、データ通信制御部２０９と、装置識別情報登録処理部２１１の他に、さらに、データロード処理部２００と、アプリケーション実行処理部２０１と、通信条件設定処理部２０２と、交換データ格納処理部２０３と、データ通知処理部２１２と、交換データ追加および消去処理部２１４と、ＢＯＸアクセス処理部２１５と、ＢＯＸ作成処理部２１７と、装置識別情報消去処理部２１８との機能をさらに有する。無線通信設定部２０５は、通信設定処理部２０４と、通信指示処理部２０６とを含む。データ通信制御部２０９は、データ通信実行処理部２０８と、スリープ設定／解除処理部２１６とを含む。

上記機能のうち、データロード処理部２００、通信設定処理部２０４、通信指示処理部２０６、データ通信実行処理部２０８、データ格納処理部２１０、装置識別情報登録処理部２１１、データ通知処理部２１２、スリープ設定／解除処理部２１６および装置識別情報消去処理部２１８は、一例として、ＣＰＵ３１が本体機能プログラムを実行することにより実現される機能である。また、アプリケーション実行処理部２０１、通信条件設定処理部２０２、ＢＯＸアクセス処理部２１５、ＢＯＸ作成処理部２１７、交換データ格納処理部２０３および交換データ追加および消去処理部２１４は、一例として、ＣＰＵ３１がメモリカード２６のＲＯＭ２７に格納されているアプリケーションを実行することにより実現される機能である。なお、各機能は、必要に応じてマルチタスク制御により実現されるものとする。

データロード処理部２００は、アプリケーション（データ）をロードする。
アプリケーション実行処理部２０１は、ロードすなわち取得したデータに基づいてアプリケーションを実行する。

ＢＯＸ作成処理部２１７は、アプリケーションの実行処理によりＢＯＸ作成指示に従って交換データ保存領域８０および受信データ保存領域８２にそれぞれアプリケーションを識別するためのデータ（例えばアプリケーションＩＤ）に対応付けられた送信ＢＯＸおよび受信ＢＯＸを作成する。

通信条件設定処理部２０２は、アプリケーションの実行処理により交換データ登録イベントが発生した場合に、交換データについての通信条件を設定する。例えば、ユーザ等の設定指示に従って交換データをゲーム装置から送信する送信回数および／または交換データを他のゲーム装置を用いて伝播する伝播回数を設定する。

なお、本例においては、交換データに関して、主に、他のゲーム装置との間で他のゲーム装置が有しているデータと互いに交換するデータに伝搬回数を設定する場合について説明するが、互いに交換することなく、単に譲渡するようなデータ（譲渡データ）、例えば、他のゲーム装置に対して自己のデータを一方的に送信のみするデータ、あるいは、自己のデータを複製して一方的に送信するデータ、あるいは逆に、他のゲーム装置から一方的に受信のみするデータについても同様に伝搬回数を設定することが可能である。

交換データ格納処理部２０３は、アプリケーションの実行処理により保存用データメモリ３４の交換データ保存領域８０に設けられた送信ＢＯＸに通信条件が設定された交換データを格納する。なお、当該交換データは、後述する実質的な通信を実行する前に交換データの交換等の処理が可能であるかどうかを判定する判定処理用のフィルタリング用データが設定された状態で格納される。なお、フィルタリング用データには、アプリケーションＩＤとともに、判定のアルゴリズムの方式毎のリストとして保存するための当該アプリケーションＩＤをどのリストに保存するべきかを識別するために判定のアルゴリズムの方式を示す情報（アルゴリズム識別情報）と、アプリケーションの種別を判別するシステムフラグ情報とが含まれる。

交換データ追加および消去処理部２１４は、後述するがアプリケーションの実行処理により交換フラグデータが有ると判断された場合に受信データ保存領域８２の受信ＢＯＸを確認し、受信ＢＯＸに交換条件を満たす交換データが有ると判断される場合には、受信データ保存領域８２の受信ＢＯＸに記憶された交換データを取得して、交換データ保存領域８０の送信ＢＯＸに記憶された交換データを削除する。

ＢＯＸアクセス処理部２１５は、アプリケーションの実行処理によりＢＯＸ確認の指定入力が有った場合に、ＢＯＸアクセス処理を実行する。例えば、ユーザ等のＢＯＸ確認の指定指示に従って交換データ保存領域８０および受信データ保存領域８２にそれぞれ設けられたアプリケーションＩＤに対応する送信ＢＯＸおよび受信ＢＯＸにアクセスして、その中に格納された交換データおよび／または受信データをユーザに表示等する。

通信設定処理部２０４は、無線通信モジュール３８による無線通信が可能であると判断した場合には、交換データ保存領域８０の送信ＢＯＸに格納されている交換データに設定されているフィルタリング用データを無線通信モジュール３８に出力して、無線通信モジュール３８のフィルタリング用データ保存領域６８に格納する。

本例においては、一例として、通信設定処理部２０４は、当該フィルタリング用データを無線通信モジュール３８のフィルタリング用データ保存領域６８に保存する際に、フィルタリング用データに含まれているアプリケーションＩＤを、システムフラグ情報を確認して分類するとともに、さらに、判定のアルゴリズムを識別するためのアルゴリズム識別情報を確認して、フィルタリング用データ保存領域６８にシステムフラグ情報およびアルゴリズム識別情報に従って設けられたリストにアプリケーションＩＤを格納する。

また、通信設定処理部２０４は、ＭＡＣアドレスリスト保存領域８８，８８＃に保存されているＭＡＣアドレスリストを無線通信モジュール３８に出力して、無線通信モジュール３８のＭＡＣアドレスリスト保存領域７０，７０＃に格納する。

また、後述するが通信設定処理部２０４は、所定期間経過後に送信無線フレームに設定されるＭＡＣアドレスを更新することが可能であるものとする。

また、装置識別情報消去処理部２１８は、ＭＡＣアドレスリスト保存領域８８，８８＃のデータについて、所定の条件に応じてアクセスして消去する。本実施例においては、ユーザからの所定の操作指示に従ってＭＡＣアドレスリスト保存領域８８，８８＃のデータを消去することが可能である。また、ＭＡＣアドレスリスト保存領域８８，８８＃として所定のデータ容量が設けられており、複数のＭＡＣアドレスを保存することにより当該所定のデータ容量が一杯となり、保存する領域が無い場合には、保存された古いＭＡＣアドレスを消去して新しいＭＡＣアドレスが保存されるようにしても良い。また、装置識別情報消去処理部２１８は、ユーザからの所定の操作指示とは別に、後述するが所定条件の場合、たとえば所定期間経過後にＭＡＣアドレスリスト保存領域のデータの一部を消去する。なお、ＭＡＣアドレスリスト保存領域８８，８８＃のデータを消去する際には、無線通信モジュール３８内のＲＡＭ６６のＭＡＣアドレスリスト保存領域７０，７０＃に格納されているＭＡＣアドレスリストについても消去するように指示しても良い。

なお、本例においては、ＭＡＣアドレスリスト保存領域７０，７０＃に格納されているＭＡＣアドレスリストを消去する場合について説明するが、本体部からの指示によらず、無線通信モジュール３８内で所定期間経過後、無線通信モジュール３８のＣＰＵ６０の指示によりＲＡＭ６６のＭＡＣアドレスリスト保存領域７０，７０＃に格納されているＭＡＣアドレスリストを消去するようにしても良い。

通信指示処理部２０６は、無線通信の通信開始指示を無線通信モジュール３８に出力する。

図７は、本発明の実施の形態に従う携帯端末間処理を実行する無線通信モジュール３８の機能ブロックの詳細について説明する図である。

図７を参照して、本例においては、一例として、ＣＰＵ６０がＲＯＭ７２に保存された携帯端末間処理を実行するためのアプリケーションを実行することにより所定の機能を実現する場合について説明するが、必ずしもＣＰＵ６０により実現される場合に限られず、少なくとも一部の機能を専用のＩＣ（Integrated Circuit）を用いて実現するようにしても良い。

無線通信モジュール３８は、無線フレーム送受信部２２３と、交換データ通信判断部２２５とを含む。無線フレーム送受信部２２３は、無線フレーム設定部２２２と、通信相手探索部２２４とを含む。交換データ通信判断部２２５は、装置識別情報比較部２２６と、通信データ判定部２２８と、アプリケーションＩＤ判定部２３０とを含む。なお、各機能は、必要に応じてマルチタスク制御により実現されるものとする。

無線フレーム設定部２２２は、無線通信の通信開始指示に従って、フィルタリング用データ保存領域６８に保存されたフィルタリング用データに基づいて、通信相手を探索する後述する交換相手探索処理を実行するための送信無線フレームを設定する。送信無線フレームの詳細については後述する。そして、無線フレーム設定部２２２は、設定した送信無線フレームを送信無線フレーム保存領域６７に格納する。

通信相手探索部２２４は、送信無線フレーム保存領域６７に格納された設定した送信無線フレームを用いて上述した通信可能範囲１０に含まれる通信相手を探索する交換相手探索処理を実行する。本例においては、一例として通信相手としてゲーム装置３との間で通信する場合について説明する。そして、通信相手探索部２２４は、ゲーム装置３に対して送信無線フレームを送信した場合に、ゲーム装置３から送信された送信無線フレームを受信無線フレームとして受信し、受信無線フレーム保存領域６９に格納する。

交換データ通信判断部２２５は、通信相手探索部２２４で通信相手を発見した場合、すなわち、通信相手から受信無線フレームを受信した場合、当該受信無線フレームに基づいて通信相手が交換データを交換する交換相手であるかどうかを判断し、交換相手であると判断された場合には、その旨を通知する。

具体的には、装置識別情報比較部２２６は、通信相手探索部２２４において通信相手が発見された場合に、通信相手であるゲーム装置から受信した受信無線フレームに含まれている装置識別情報であるＭＡＣアドレスが、ＭＡＣアドレスリスト保存領域７０に保存されたＭＡＣアドレスリストと比較して一致するものがあるかどうかを判断する。

通信データ判定部２２８は、通信相手が発見された場合に、装置識別情報比較部２２６の比較結果に従って受信無線フレームに含まれているＭＡＣアドレスがＭＡＣアドレスリスト保存領域７０に保存されているＭＡＣアドレスリストと一致しないと判断された場合に、受信した受信無線フレームのデータ内容を確認して、受信無線フレームが携帯端末間処理として処理可能な無線フレームであるかどうかを判定する。

アプリケーションＩＤ判定部２３０は、通信データ判定部２２８の判定により処理可能な受信無線フレームを受信したと判定した場合に、受信した受信無線フレームに格納されているアプリケーションＩＤが交換データの交換に関する所定条件を満たすか否かを判定する。

具体的には、アプリケーションＩＤ判定部２３０は、ＩＤリストヘッダ情報比較部２３２と、ＩＤリスト比較部２３４とを含む。各部の処理については後述する。

そして、ＩＤリスト比較部２３４における比較結果に基づいて所定条件を満たした（アプリケーションＩＤが一致した）と判断した場合には、本体側にその旨を通知する。

再び、図６を参照して、スリープ設定／解除処理部２１６は、無線通信モジュール３８からの通知（本例においては図７のＩＤリスト比較部２３４からの通知）を受ける。

スリープ設定／解除処理部２１６は、本体部３９の各機能を所定条件に基づいてスリープ状態に設定するあるいはスリープ状態を解除する。スリープ設定／解除処理部２１６は、一例として、ユーザの操作ボタン１４による操作指示入力を監視し、所定期間、操作ボタン１４による操作指示入力がなかったと判断した場合に本体部３９の各機能における処理を停止するスリープ状態に設定する。当該機能によりユーザがゲーム装置の操作を希望しない場合に自動的に省電力状態とすることが可能である。また、ユーザからの指示入力によりスリープ状態に設定するようにしても良い。また、スリープ設定／解除処理部２１６は、本体部３９の各機能における処理が停止したスリープ状態においてユーザの操作ボタン１４による操作指示に従いスリープ状態を解除して元の状態に復帰させる。すなわち、本体部３９における各種処理が可能となる。また、本例においては、ユーザの操作ボタン１４による操作指示以外に、本体部３９がスリープ状態である場合に無線通信モジュール３８からの通知によりスリープ状態を解除するものとする。なお、本例において、スリープ設定／解除処理部２１６は、一例としてデータ通信制御部２０９に含まれるものとして説明したが、特にこれに限られず、当該機能をデータ通信制御部２０９とは別に設けるようにすることも可能である。

そして、スリープ設定／解除処理部２１６は、無線通信モジュール３８から通知があった場合には、その通知をデータ通信実行処理部２０８に出力する。

スリープ設定／解除処理部２１６は、現在の状態がスリープ状態でない場合には、そのまま無線通信モジュール３８からの通知をデータ通信実行処理部２０８に出力する。

データ通信実行処理部２０８は、携帯端末間通信における無線通信モジュール３８からの通知に従ってゲーム装置３との間で交換データの授受処理を実行する。具体的には、交換データ保存領域８０の送信ＢＯＸに保存されている交換データをゲーム装置３に送信する。そして、ゲーム装置３から交換データを受信する。

なお、後述するがデータ通信実行処理部２０８は、携帯固定端末間通信における無線通信モジュール３８からの通知に従って固定端末機器５からの配信データの取得処理を実行する。具体的には、固定端末機器５に対して配信データの要求を送信し、固定端末機器５から送信される配信データを受信する。

データ格納処理部２１０は、データ通信実行処理部２０８により受信した交換データの交換条件が成立したかどうかを判断し、判断結果に基づいて、受信データ保存領域８２のアプリケーションＩＤに対応する受信ＢＯＸに格納する。また、受信データの伝播回数を確認して、伝播条件を満たしているか否かを判断して、満たしていると判断した場合には、受信データをコピーして交換データ（伝播データ）として交換データ保存領域８０のアプリケーションＩＤに対応する送信ＢＯＸに格納する。

装置識別情報登録処理部２１１は、交換条件が成立した場合には、交換相手であるゲーム装置３の装置識別情報であるＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８に格納する。

また、後述するが装置識別情報登録処理部２１１は、データ通信実行処理部２０８により受信した配信データを受信データ保存領域８２に格納した場合には、配信相手である固定端末機器５の装置識別情報であるＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８＃に格納する。

データ通知処理部２１２は、交換データを交換した等の旨あるいは配信データを取得した旨をユーザに通知する。

図８は、本発明の実施の形態に従う携帯端末間処理の交換データの授受処理を実行するデータ通信実行処理部２０８の詳細について説明する図である。

図８を参照して、データ通信実行処理部２０８は、本例においては、一例として、ＣＰＵ３１がプリセットデータ用メモリ３５に保存された携帯端末間処理の交換データの授受処理を実行するためのアプリケーションを実行することにより所定の機能を実現する場合について説明するが、必ずしもＣＰＵ３１により実現される場合に限られず、少なくとも一部の機能を専用のＩＣ（Integrated Circuit）を用いて実現するようにしても良い。

データ通信実行処理部２０８は、通信接続確立処理部３０２と、フレンド認証処理部３０４と、送信スロット作成処理部３０６と、送信データリスト作成処理部３０８と、送受信データリスト分析処理部３１０と、送受信実行処理部３１２と、データリスト判定部３１４と、通信切断処理部３１６とを含む。なお、各機能は、必要に応じてマルチタスク制御により実現されるものとする。

通信接続確立処理部３０２は、無線通信モジュール３８からの交換データを有するゲーム装置が発見された旨の通知に含まれている通信相手のＭＡＣアドレス等の接続情報に基づいて通信相手との間で通信接続を確立（通信路を形成）する。

フレンド認証処理部３０４は、フレンドコードリスト保存領域８９に格納されたフレンドコードを授受することにより、通信相手がフレンドあるいは非フレンドのいずれであるかを判断する。

具体的には、フレンド認証処理部３０４は、自己のフレンドコードを無線通信モジュール３８を介してゲーム装置３に送信する。また、フレンド認証処理部３０４は、無線通信モジュール３８を介してゲーム装置３から送信されたフレンドコードを受信する。そして、受信したフレンドコードがフレンドコードリスト保存領域８９に保存されているかどうかを判断し、フレンドコードリスト保存領域８９に受信したフレンドコードが保存されている場合には、フレンド認証が成功した旨をゲーム装置３に通知する。また、ゲーム装置３においても同様の方式に従って、通信相手であるゲーム装置１のフレンドコードがフレンドコード保存領域に保存されているかどうかを判断する。そして、ゲーム装置３において、ゲーム装置１のフレンドコードがフレンドコード保存領域に保存されていると判断した場合には、フレンド認証が成功した旨をゲーム装置１に通知する。フレンド認証処理部３０４は、自己のフレンド認証が成功し、かつ、通信相手からフレンド認証が成功した旨の通知を受けた場合、すなわち、両方の装置でフレンド認証が成功した場合に、通信相手がフレンドであると判断する。通信相手がフレンドであるかどうかに従って、後の送信スロットに格納される交換データの内容を変更することが可能となる。

送信スロット作成処理部３０６は、送信スロット保存領域９０に各送信ＢＯＸに対応して設けられる送信スロットを作成して、当該送信スロットに、交換データ保存領域８０の各送信ＢＯＸに保存されているデータを実際に授受するための交換データとして格納する。なお、送信スロット保存領域９０は、メインメモリ３２の一部領域を用いて設けられるものとする。

送信データリスト作成処理部３０８は、送信スロット保存領域９０に設けられた各送信ＢＯＸ毎に設けられた送信スロットに基づいて、交換データを送信するための送信データリストを作成する。送信データリストには、各アプリケーション毎の各送信スロットに格納された交換データのデータのサイズ等の情報が含まれる。

送受信データリスト分析処理部３１０は、送信データリスト作成処理部３０８で作成された送信データリストを無線通信モジュール３８を介してゲーム装置３に送信する。また、送受信データリスト分析処理部３１０は、ゲーム装置３から送信された送信データリスト（以下、受信データリストとも称する）を受信する。そして、受信データ保存領域８２に設けられた各アプリケーションに対応して設けられた受信ＢＯＸの容量等を確認して、受信データリストに含まれるゲーム装置３から送信される各アプリケーション毎の交換データのサイズに基づいて、当該交換データを受信ＢＯＸに保存することができるかどうかを判断する。そして、受信データリストに含まれている各アプリケーション毎に、当該交換データを受信ＢＯＸに保存できるか否かを判定し、保存できると判断した場合には、受信データリストに含まれている各アプリケーション毎にＯＫ判定フラグを付加する。一方、当該交換データを受信ＢＯＸに保存できないと判断した場合には、受信データリストに含まれている各アプリケーション毎にＮＧ判定フラグを付加する。送受信データリスト分析処理部３１０は、ＯＫ判定フラグあるいはＮＧ判定フラグを付加した受信データリストをゲーム装置３に送信（返信）する。同様に、ゲーム装置３においても同様の方式に従って、ゲーム装置１から送信された送信データリストに対して、各アプリケーション毎にＯＫ判定フラグあるいはＮＧ判定フラグを付加する。そして、各アプリケーション毎にＯＫ判定フラグあるいはＮＧ判定フラグを付加した送信データリストをゲーム装置１に送信（返信）する。

ゲーム装置１の送受信データリスト分析処理部３１０は、ＯＫ判定フラグあるいはＮＧ判定フラグが付加された送信データリストを取得する。

送受信実行処理部３１２は、ＯＫ判定フラグあるいはＮＧ判定フラグが付加された送信データリストに基づいて、送信スロット保存領域９０に保存された送信スロットから交換データを無線通信モジュール３８を介して送信する。また、送受信実行処理部３１２は、ＯＫ判定フラグあるいはＮＧ判定フラグが付加された受信データリストに基づいて、ゲーム装置３から送信された交換データを無線通信モジュール３８を介して受信する。

データリスト判定部３１４は、送信あるいは受信データリストに基づくデータ送受信処理が適切に実行されたかどうかを判定する。具体的には、送信データリストに基づいて、各アプリケーションに対応して設けられた送信スロットから交換データの送信が適切に実行されたか、また、受信データリストに基づいて、ゲーム装置３から送信された交換データの受信が適切に実行されたかどうかを判定する。

通信切断処理部３１６は、データリスト判定部３１４において送信データリストおよび受信データリストに基づくデータ送受信処理が適切に実行された場合には、ゲーム装置３との通信接続を切断する処理を実行する。また、データ送受信が適切に実行されなかった場合、例えば、通信が中断された場合等においても、ゲーム装置３との通信接続を切断する処理を実行する。そして、通信切断処理部３１６は、通信接続を切断した旨をデータ格納処理部２１０に通知する。

以下、各部における具体的処理について説明する。
＜交換データ保存領域８０への格納＞
図９は、本発明の実施の形態に従う交換データ保存領域８０の送信ＢＯＸへの交換データの格納処理について説明するフロー図である。

本例においては、交換データは、ユーザがゲーム装置１においてアプリケーションを実行中に、当該アプリケーションで利用可能なデータを交換データとして外部のゲーム装置に対して提供する目的で操作することにより、指定した交換データが交換データ保存領域８０の対応する送信ＢＯＸに格納される。一例として、メモリカード２６のＲＯＭに格納されたアプリケーションを実行する場合について説明する。

図９を参照して、ゲーム装置１の主電源がオンし、ユーザが所定の操作を実行することにより、ゲーム装置１のＣＰＵ３１（データロード処理部２００）は、メモリカード２６に格納されたデータをロードする（ステップＳ０）。すなわち、メインメモリ３２に展開する。

そして、次に、ＣＰＵ３１（アプリケーション実行処理部２０１）は、メインメモリ３２に展開されたデータに基づいてアプリケーションを実行する（ステップＳ１）。

そして、ＣＰＵ３１（アプリケーション実行処理部２０１）は、当該アプリケーションの実行により、まず、当該アプリケーションに対応するＢＯＸ（送信ＢＯＸおよび受信ＢＯＸ）が作成済みであるかどうかを判断する（ステップＳ２）。ステップＳ２において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、ＢＯＸ作成済みであると判断した場合（ステップＳ２においてＹＥＳ）には、ステップＳ４に進む。

一方、ステップＳ２において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、ＢＯＸ作成済みでないと判断した場合（ステップＳ２においてＮＯ）には、ステップＳ３に進む。具体的には、アプリケーション実行処理部２０１は、ＢＯＸ作成処理部２１７にＢＯＸ作成指示を出力する。

そして、ＣＰＵ３１（ＢＯＸ作成処理部２１７）は、交換データ保存領域８０および受信データ保存領域８２にそれぞれ自身のアプリケーションに対応付けられた送信ＢＯＸおよび受信ＢＯＸを作成する（ステップＳ３）。

図１０は、本発明の実施の形態に従うアプリケーションに対応付けられた送信ＢＯＸおよび受信ＢＯＸを説明する概念図である。

図１０を参照して、ここでは、一例としてアプリケーションプログラムＡに対応付けられて作成されたＢＯＸが示されている。図１０（Ａ）は、交換データ保存領域８０にアプリケーションＡに対応付けて設けられた送信ＢＯＸ（ボックス）ＳＢであり、図１０（Ｂ）は、受信データ保存領域８２にアプリケーションＡに対応付けて設けられた受信ＢＯＸ（ボックス）ＲＢである。送信ＢＯＸは、複数個のデータの１つずつが格納される複数の送信ＢＯＸスロットＳＢＵで構成されている。受信ＢＯＸについても同様に、受信データが１つずつ格納される複数の受信ＢＯＸスロットＲＢＵで構成されている。この送信ＢＯＸおよび受信ＢＯＸを作成するために用いられる記憶領域の容量ならびに送信ＢＯＸスロットおよび受信ＢＯＸスロットの個数については、予めアプリケーションプログラム毎に規定されて設定されるものとする。なお、後述する交換データを送信する際にメインメモリ３２に作成される送信スロットとして用いられる記憶領域の最大容量についても予めアプリケーションプログラム毎に規定されて設定されるものとする。

図１１は、本発明の実施の形態に従う送信ＢＯＸにデータが格納された場合を説明する図である。

図１１を参照して、ここでは、送信ＢＯＸ（ボックス）ＳＢの各送信ＢＯＸスロットにデータＸ，Ｙがそれぞれ格納されている場合が示されている。なお、送信ＢＯＸスロットには、スロット番号が割り当てられており、番号が小さい順にデータが格納され、基本的には格納された順番に従ってデータが１つずつ送信スロットに交換データとして格納される。

図１２は、本発明の実施の形態に従う送信ＢＯＸの送信ＢＯＸスロットに格納されたデータのデータ構造を説明する図である。

図１２を参照して、送信ＢＯＸスロットに格納された交換データとなるデータ構造は、ＩＤデータＩＤＤ０と、データグループＩＤＩＤＤ１と、データサイズＩＤＤ２と、データ本体ＩＤＩＤＤ３と、フレンドフラグデータＩＤＤ４と、送受信条件データＩＤＤ５と、送信者データＩＤＤ６と、送信回数ＩＤＤ７と、伝播回数ＩＤＤ８と、フィルタリング用データＩＤＤ９と、データ本体ＩＤＤ１０とで構成されている。

ＩＤデータＩＤＤ０は、アプリケーション毎に予め設けられたアプリケーション名を示す識別データである。

データグループＩＤＩＤＤ１は、後述するデータグルーピング処理を実行するための識別データである。具体的には、データグループＩＤが同じデータは同じグループのデータとして扱われる。

データサイズＩＤＤ２は、データ全体のデータサイズを示す値が格納される。
データ本体ＩＤＩＤＤ３は、データ本体の生成に際して割り当てられる固有の識別データである。データ本体が同じ内容である場合には、同じ識別データが設定される。

フレンドフラグデータＩＤＤ４は、当該交換データとなるデータの送信対象がフレンドに対するものか、あるいは、非フレンドに対するものか、あるいは、フレンド／非フレンドのいずれも（ＡＮＹ）に対するものかを識別するフラグデータである。例えば、「フレンド」のフラグデータが設定されている場合には、当該データの送信対象がフレンドに対するものであることを意味する。また、「非フレンド」のフラグデータが設定されている場合には、当該データの送信対象がフレンドでない非フレンドに対するものであることを意味する。また、「ＡＮＹ」のフラグデータが設定されている場合には、当該データの送信対象がフレンド／非フレンドのいずれに対するものでもあることを意味する。

送受信条件データＩＤＤ５は、後述するセンドフラグデータおよびレシーブフラグデータを含む。

送信者データＩＤＤ６は、送信者であるゲーム装置を識別するための情報であり一例としてＭＡＣアドレス等を含む。

送信回数ＩＤＤ７は、当該データを送信する回数を規定するものである。例えば、送信回数が１回に設定されている場合には、１回交換データとして送信して当該データの送信が終了することを意味する。一方、送信回数が３回に設定されている場合には、当該データの送信が３回実行されることを意味する。なお、当該送信回数の設定は、上述した通信条件設定処理部２０２の処理として実行される。

伝播回数ＩＤＤ８は、当該データを伝播する回数を規定するものである。例えば、伝播回数が１回に設定されている当該データが交換データとして他のゲーム装置に送信された場合に、他のゲーム装置からさらに別のゲーム装置に１回だけ当該データが伝播される。なお、当該伝播回数の設定は、上述した通信条件設定処理部２０２の処理として実行される。

フィルタリング用データＩＤＤ９は、通信相手である他のゲーム装置等との間で実質的な通信を実行する前に交換データの交換等の処理が可能であるかどうかを判定するためのアプリケーションＩＤを含むデータであり、アプリケーションＩＤとともに、当該アプリケーションＩＤの判定のアルゴリズムの方式を示すアルゴリズム識別情報と、アプリケーションの種別を判別するためのシステムフラグ情報とが含められる。

データ本体ＩＤＤ１０は、交換データとなるデータ内容である。
再び、図９を参照して、ＣＰＵ３１（アプリケーション実行処理部２０１）は、バックアップＲＡＭ２８に格納されていたデータに交換データを交換データ保存領域８０の対応する送信ＢＯＸに格納したことを示す交換フラグデータが含まれていたかどうかを判断する（ステップＳ４）。

ステップＳ４において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、バックアップＲＡＭ２８に格納されていたデータに交換データを交換データ保存領域８０の対応する送信ＢＯＸに格納したことを示す交換フラグデータが含まれていたと判断した場合（ステップＳ４においてＹＥＳ）には、交換データの追加処理および消去処理を実行する（ステップＳ２２）。当該処理すなわち、交換データ追加および消去処理部２１４における処理については後述する。そして、当該追加処理および消去処理を実行した後、ステップＳ５に進む。

ステップＳ４において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、バックアップＲＡＭ２８に格納されていたデータに交換データを交換データ保存領域８０の対応する送信ＢＯＸに格納したことを示す交換フラグデータが含まれていないと判断した場合（ステップＳ４においてＮＯ）には、次に、ステップＳ５に進む。

そして、ＣＰＵ３１（アプリケーション実行処理部２０１）は、アプリケーションの実行により、交換データの登録イベント（以下、交換データ登録イベントとも称する）が発生したかどうかを判断する（ステップＳ５）。つまりアプリケーションの実行中に実行しているアプリケーションで利用可能なデータを交換データとして、交換データ保存領域８０の対応する送信ＢＯＸに格納するかどうかを促すシーンに移行されたかどうかを判断する。

ここで、交換データとは、アプリケーションプログラムにおいて利用されるデータであり、より好ましくは、アプリケーションプログラムを実行することによりユーザが獲得または作成したデータである。

図示は省略するが、たとえば、交換データ登録イベントとしては、アプリケーションの実行により、バックアップＲＡＭに記憶されているゲーム内で獲得または作成したデータ等、当該アプリケーションで利用可能なデータの一覧をＬＣＤ１２に表示し、その中からユーザが他人にあげても良いデータを選択するような場合が挙げられる。

交換データの格納については、以下に説明するが、例えば、ユーザがゲーム内で手に入れたアイテムや、ゲームを進行することによって成長させたキャラクタのデータを交換データとしてもよい。また、アイテムにはユーザのメッセージを付加してもよい。より具体的には、「手紙」のアイテムにユーザがメッセージを書いて、当該メッセージを交換データとして格納するようにしてもよい。このように、ゲームの実行状況に応じたアイテムやキャラクタを交換データとすることで、データにユーザごとの個性が生じることになり、交換した場合の興趣が高まる。

また、交換データ登録イベントを、ゲーム上のイベントとして表現しても良い。例えば、ユーザが、ゲーム内で所定の場所にアイテムやキャラクタを置いたり預けたりする操作をした場合に、当該アイテムやキャラクタのデータを交換データとして交換データ保存領域８０の送信ＢＯＸに格納する処理を実行しても良い。また、ゲーム内で「手紙」のアイテムをボトルに入れて海に流すような演出をして、海に流した「手紙」のアイテムのデータを交換データとして交換データ保存領域８０の送信ＢＯＸに格納する処理を実行しても良い。

また、交換データの交換に際し、付加的な条件（取得条件データ）を付けることも可能である。例えば、交換を希望する装置の所有者あるいはアプリケーションを実行しているユーザの性別、年齢、住所、職業等を交換する際の条件として、当該条件を示すデータを取得条件データとしたり、あるいは、交換を希望するデータあるいはその旨を示すデータ等を交換する際の条件に含めるようにしても良い。例えば、上記交換データ登録イベントにおいて交換データの交換条件をユーザに選択させるようにして取得条件データを取得するようにすることが可能であるし、あるいは、ゲーム上のイベントと対応付けてアプリケーションが当該取得条件データを設定するようにしてもよい。このような取得条件データについては、後述するが交換条件データとしてアプリケーションＩＤ内に収められる。

また、本例において、交換データとは、主に他のゲーム装置との間で他のゲーム装置が有しているデータと互いに交換するデータについて説明するが、互いに交換することなく、単に譲渡するようなデータ（譲渡データ）、例えば、他のゲーム装置に対して自己のデータを一方的に送信のみするデータ、あるいは、自己のデータを複製して一方的に送信するデータ、あるいは逆に、他のゲーム装置から一方的に受信のみするデータも含むものとする。

また、さらに付加的な条件として、当該データの送受信に関する条件（送受信条件データ）を付けることも可能である。例えば、上記交換データ登録イベントにおいて交換データの送受信に関する条件をユーザに選択させるようにして送受信条件データを取得するようにすることも可能であるし、あるいは、ゲーム上のイベントと対応付けてアプリケーションが当該取得条件データを設定するようにしてもよい。たとえば、上記例において、ゲーム内で「手紙」のアイテムをボトルに入れて海に流すような演出をして、海に流した「手紙」のアイテムのデータを交換データとするような場合には、他のゲーム装置に対して自己のデータを一方的に送信するデータとして、送受信条件データを設定するようにすることも可能である。また、別の例としては、ゲーム内で、ユーザが望むアイテムを捜してもらうような演出をして、ユーザが望むアイテムの交換データを他のゲーム装置から一方的に受信するのみのデータとして、送受信条件データを設定するようにすることも可能である。このような送受信条件データについても後述するが交換条件データとしてアプリケーションＩＤ内に収められる。ユーザが望むアイテムの交換データを他のゲーム装置から一方的に受信するのみのデータとして、送受信条件データを設定するようにすることも可能である。なお、交換データを他のゲーム装置から一方的に受信するのみの場合には、他のゲーム装置に送信するデータは無いため交換データ保存領域８０の送信ＢＯＸに格納する交換データとしては、空データやダミーデータを保存するようにしても良い。

当該付加的な条件を付けることにより交換データの交換に際し、希望する交換データの取得等、交換データのデータ取得のバリエーションを広げることができ、交換の興趣性を高めることができる。

そして、本例においては、後述するが当該アプリケーションＩＤを他のアプリケーションＩＤと比較する際の判定のアルゴリズムとして複数の判定方式を設けることが可能であり、アプリケーションＩＤ内のデータ形式すなわち交換条件データの有無に従って、判定のアルゴリズムの方式を示す情報であるアルゴリズム識別情報が異なるものとして設定されるものとする。

一方、ＣＰＵ３１（アプリケーション実行処理部２０１）は、交換データ登録イベントが発生していないと判断した場合（ステップＳ５においてＮＯ）には、ＢＯＸ確認の指定入力があったかどうかを判断する（ステップＳ２４）。

ＣＰＵ３１は、（アプリケーション実行処理部２０１）は、ＢＯＸ確認の指定入力があったと判断した場合（ステップＳ２４においてＹＥＳ）には、ステップＳ２６に進む。具体的には、アプリケーション実行処理部２０１は、ＢＯＸアクセス処理部２１５にＢＯＸ確認の指定入力があった旨を出力する。当該処理すなわち、ＢＯＸアクセス処理部２１５における処理については後述する。そして、当該ＢＯＸアクセス処理を実行した後、ステップＳ１に戻り、通常のアプリケーションを実行する。例えば、ユーザの操作に基づいて仮想空間内でオブジェクトを動作させる等のゲーム処理を実行する。

また、ＣＰＵ３１は、（アプリケーション実行処理部２０１）は、ＢＯＸ確認の指定入力がなかったと判断した場合（ステップＳ２４においてＮＯ）にも、ステップＳ１に戻る。

次に、ステップＳ５において、交換データ登録イベントが発生したと判断された場合（ステップＳ５においてＹＥＳ）には、ＣＰＵ３１（アプリケーション実行処理部２０１）は、交換データの指定入力があったかどうかを判断する（ステップＳ６）。

次に、ステップＳ６において、交換データの指定入力があったと判断した場合（ステップＳ６においてＹＥＳ）には、ＣＰＵ３１（通信条件設定処理部２０２）は、交換データの送信回数および交換データを伝播する伝播回数を設定する通信条件設定処理を実行する（ステップＳ７）。通信条件設定処理については後述する。

一方、ステップＳ６において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、交換データの指定入力が無いと判断した場合（ステップＳ６においてＮＯ）には、ユーザが交換を希望しないため、再び、ステップＳ１に戻り通常のアプリケーションを実行する。

次に、通信条件設定処理の後、ＣＰＵ３１（交換データ格納処理部２０３）は、交換データ保存領域８０を確認する（ステップＳ８）。具体的には、交換データ保存領域８０の対応する送信ＢＯＸを確認する。

次に、ＣＰＵ３１（交換データ格納処理部２０３）は、交換データ保存領域８０の対応する送信ＢＯＸを確認した後、交換データ保存領域８０の対応する送信ＢＯＸに空き送信ＢＯＸスロットがあるどうかを判断する（ステップＳ１０）。

ステップＳ１０において、ＣＰＵ３１（交換データ格納処理部２０３）は、交換データ保存領域８０の対応する送信ＢＯＸに空き送信ＢＯＸスロットがあると判断した場合（ステップＳ１０においてＹＥＳ）には、空き送信ＢＯＸスロットに交換データを格納する（ステップＳ１２）。

一方、ステップＳ１０において、ＣＰＵ３１（交換データ格納処理部２０３）は、空き送信ＢＯＸスロットがないと判断した場合（ステップＳ１０においてＮＯ）には、送信ＢＯＸスロットのデータを削除したかどうかを判断する（ステップＳ１１）。図示は省略するが、たとえば空き送信ＢＯＸスロットが無い旨をユーザに通知し、ユーザにいずれかの送信ＢＯＸスロットのデータを削除するように指定させることが可能である。そして、指定があった場合には、当該送信ＢＯＸスロットのデータが削除されるものとする。

ステップＳ１１において、ＣＰＵ３１（交換データ格納処理部２０３）は、送信ＢＯＸスロットのデータが削除されたと判断した場合には、再びステップＳ１０に戻る。そして、空き送信ＢＯＸスロットに交換データを格納する。なお、送信ＢＯＸスロットのデータの削除により送信ＢＯＸスロットの配列を更新して、最後の順番の空き送信ＢＯＸスロットに交換データを格納するようにする。当該処理により、格納した順番に交換データを送信することが可能である。あるいは、送信ＢＯＸスロットの配列をユーザが入れ替えることができるようにしても良い。

一方、ステップＳ１１において、ＣＰＵ３１（交換データ格納処理部２０３）は、送信ＢＯＸスロットのデータが削除されていないと判断した場合には、再び、ステップＳ１に戻り、通常のアプリケーションを実行する。当該処理までが交換データ格納処理部２０３における処理である。

以降の処理は、アプリケーション実行処理部２０１における処理である。
そして、次に、ＣＰＵ３１（アプリケーション実行処理部２０１）は、ユーザからアプリケーションの終了指示が有るかどうかを判断する（ステップＳ１４）。

ステップＳ１４において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、ユーザからアプリケーションの終了指示が有ると判断した場合には、次のステップＳ１６に進む。一方、ステップＳ１４において、ユーザからアプリケーションの終了指示が無いと判断した場合（ステップＳ１４においてＮＯ）には、再び、ステップＳ１に戻り、通常のアプリケーションを実行する。

次に、ステップＳ１６において、ＣＰＵ３１（アプリケーション実行処理部２０１）は、交換データが交換データ保存領域８０に格納されたかどうかを判断する。そして、ＣＰＵ３１（アプリケーション実行処理部２０１）は、交換データ保存領域８０に交換データが格納されたと判断した場合（ステップＳ１６においてＹＥＳ）には、バックアップＲＡＭ２８に交換データを交換データ保存領域８０に格納したことを示す交換フラグデータをセーブデータ（例えば、獲得したアイテム、キャラクタ、文章や絵などの作成データなどアプリケーションで利用するデータ）とともに保存する（ステップＳ１８）。そして、処理を終了する（エンド）。一方、ＣＰＵ３１（アプリケーション実行処理部２０１）は、交換データ保存領域８０に交換データが格納されていないと判断した場合（ステップＳ１６においてＮＯ）には、バックアップＲＡＭ２８にセーブデータのみを保存する（ステップＳ２０）。そして、処理を終了する（エンド）。

当該処理により、バックアップＲＡＭ２８に交換フラグデータを保存することにより、上述したようにステップＳ２における判断処理において、交換フラグデータが含まれている場合には、交換データの追加処理および消去処理を実行することが可能である。

なお、本例においては、一例として、メモリカード２６のＲＯＭに格納されたアプリケーションを実行した場合における交換データ保存領域８０への交換データの格納処理について説明したが、特にメモリカード２６に格納されたアプリケーションに限られず、内蔵アプリ保存領域８４に格納されているアプリケーションを実行した場合における交換データの格納処理についても、内蔵アプリ保存領域８４に各アプリケーション毎に設けられた、当該アプリケーションのセーブデータを保存するための保存領域を上記したバックアップＲＡＭと対応付けて用いることにより実現可能である。また、内蔵アプリ保存領域８４に格納されているアプリケーションを実行した場合における交換データと、それ以外の例えばメモリカード２６のＲＯＭに格納されたアプリケーションを実行した場合における交換データとは、アプリケーションプログラムの種別が異なるものとして異なるシステムフラグ情報が割り当てられる。そして、フィルタリング用データの中にアルゴリズム識別情報がアプリケーションＩＤとともに含められるものとする。このシステムフラグ情報は、後述する通信設定処理の際に用いることが可能である。

また、本例においては、通信条件を設定する機能等についてはメモリカード２６のＲＯＭ２７に格納されているアプリケーションにより実行される機能として説明するが、システムプログラム保存領域８６に保存されている本体機能プログラムにより実行される機能としても良い。

また、本例においては、ＢＯＸアクセス処理およびＢＯＸ作成処理についてはメモリカード２６のＲＯＭ２７に格納されているアプリケーションにより実行される機能として説明するが、システムプログラム保存領域８６に保存されている本体機能プログラムにより実行される機能としても良い。

また、本例においては、交換データを追加および消去する機能等についてはメモリカード２６のＲＯＭ２７に格納されているアプリケーションにより実行される機能として説明するが、システムプログラム保存領域８６に保存されている本体機能プログラムにより実行される機能としても良い。具体的には、メモリカード２６に格納されたデータをロードした後、展開されているデータ中に、交換フラグデータが有るか否かを判断して、交換データを追加および消去する処理を実行した後、アプリケーションを実行するようにすれば良い。

図１３は、アプリケーションにより交換データ保存領域８０の送信ＢＯＸに交換データを格納する場合について説明する図である。

図１３（Ａ）を参照して、ここでは、たとえば、上述したメモリカードに記憶されたアプリケーション名Ａのアプリケーションプログラムを実行することによって、交換データ保存領域８０のアプリケーションプログラムＡに対応して設けられた送信ＢＯＸＳＢＡに交換データが格納されている場合が示されている。なお、ここでは、説明を簡易にするためにアプリケーション名とアプリケーションＩＤとを同一のものとして説明するが、特に同じである必要は無く異なるものとすることも可能である。なお、交換データには、上述したアプリケーションＩＤを含むフィルタリング用データが設定されている。本例においては当該アプリケーションＩＤと他のアプリケーションＩＤとを比較する際の判定のアルゴリズムとして複数の判定方式を設けることが可能であり、ここでは、図示していないがアプリケーションＩＤとともに、判定のアルゴリズムの方式を示す情報として、アプリケーションＩＤ内のデータ形式すなわち交換条件データの有無に従うアルゴリズム識別情報およびアプリケーションの種別を識別するシステムフラグ情報を登録することが可能である。

また、１つのアプリケーションに対して１つの交換データが格納される必要は無く、図１３（Ｂ）においては、上述したメモリカードに記憶されたアプリケーションプログラムＣを実行することによって、交換データ保存領域８０の対応する送信ＢＯＸＳＢＣに２つの交換データがそれぞれ格納される場合が示されている。

また、特にメモリカードのアプリケーションに限られず、図１３（Ｃ）に示されるように、ゲーム装置１の内蔵アプリ保存領域８４に格納されている内蔵アプリＤを実行することによって、交換データ保存領域８０の対応する送信ＢＯＸＳＢＤに交換データが格納される場合が示されている。なお、内蔵アプリＤに対応する交換データが格納されるためフィルタリング用データに格納されるシステムフラグ情報は、アプリケーションプログラムＡ等の交換データのフィルタリング用データに格納されるシステムフラグ情報とは異なるものが設定される。

そして、本例における交換データ保存領域８０の各スロットに格納された交換データは、所定の後述する条件が満たされた場合に他のゲーム装置に送信される。

＜無線通信モジュール３８に対する通信設定＞
図１４は、無線通信モジュール３８への通信設定処理について説明するフロー図である。

図１４を参照して、ＣＰＵ３１（通信設定処理部２０４）は、交換データ保存領域８０が変更されたかどうかを判断する（ステップＳ２７）。具体的には、交換データ保存領域８０の少なくとも１つの送信ＢＯＸが変更されたかどうかを判断する。

本例においては、一例として、交換データ保存領域８０の少なくとも１つの送信ＢＯＸにおける内容が変更された場合をトリガとして動作する場合として説明する。例えば、図１３で説明した如くアプリケーションプログラムを実行することによって、交換データ保存領域８０の対応する送信ＢＯＸに交換データを格納したことに応答して通信設定処理部２０４における処理が実行されるものとする。

ステップＳ２７において、交換データ保存領域８０の対応する送信ＢＯＸに変更が合った場合（ステップＳ２７においてＹＥＳ）には、通信設定処理を実行する（ステップＳ２８）。

図１５は、ＣＰＵ３１（通信設定処理部２０４）における通信設定処理のフロー図である。

図１５を参照して、まず、本体側のＣＰＵ３１（通信設定処理部２０４）は、保存用データメモリ３４の交換データ保存領域８０を確認する（ステップＳ３０）。そして、次に、ＣＰＵ３１（通信設定処理部２０４）は、保存用データメモリ３４の交換データ保存領域８０の送信ＢＯＸに交換データがあるかどうかを判断する（ステップＳ３２）。

そして、ステップＳ３２において、ＣＰＵ３１（通信設定処理部２０４）は、交換データ保存領域８０の送信ＢＯＸに交換データがあると判断した場合（ステップＳ３２においてＹＥＳ）には、各送信ＢＯＸに格納されている交換データに設定されているフィルタリング用データおよびＭＡＣアドレスリスト保存領域８８，８８＃に格納されているＭＡＣアドレスリストを無線通信モジュール３８に出力する（ステップＳ３４）。

そして、無線通信モジュール側において、ＣＰＵ３１（通信設定処理部２０４）の指示によりフィルタリング用データとＭＡＣアドレスリストをそれぞれＲＡＭ６６のフィルタリング用データ保存領域６８およびＭＡＣアドレスリスト保存領域７０，７０＃にそれぞれ格納する（ステップＳ３６）。そして、処理を終了する（リターン）。

なお、本実施例においては、携帯端末間通信処理および携帯固定端末間通信処理が一連の処理として連続して実行される方式であるため後述する携帯固定端末間通信処理のＭＡＣアドレスフィルタリング処理に用いられる固定端末機器のＭＡＣアドレスリストについてもＭＡＣアドレスリスト保存領域８８＃から読み出して、ＭＡＣアドレスリスト保存領域７０＃に格納するようにしている。したがって、２つの種類がそれぞれ異なる通信処理について、それぞれ独立に通信設定するのではなく、１回にまとめて設定することが可能であり効率的な通信設定を実現することが可能である。

また、本例の如く、携帯端末間通信処理のＭＡＣアドレスフィルタリング処理に用いられるＭＡＣアドレスリスト保存領域７０と、携帯固定端末間通信処理のＭＡＣアドレスフィルタリング処理に用いられるＭＡＣアドレスリスト保存領域７０＃とをそれぞれ別々に設けることにより、ＭＡＣアドレスフィルタリング処理の処理負荷を軽減することが可能である。

また、フィルタリング用データのアプリケーションＩＤは、システムフラグ情報に基づいて分類される。さらに、当該アプリケーションＩＤを他のアプリケーションＩＤと比較する際の判定のアルゴリズムとして複数の判定方式を設けることが可能であり、アプリケーションＩＤを各判定方式に対応するリストとして纏めてフィルタリング用データ保存領域６８に保存することが可能である。具体的には、ＣＰＵ３１（通信設定処理部２０４）は、各フィルタリング用データについて、フィルタリング用データに含まれているアプリケーションＩＤに対応付けられているシステムフラグ情報を確認して、分類するとともに、さらに、判定のアルゴリズムの方式を示すアルゴリズム識別情報を確認して、フィルタリング用データ保存領域６８のシステムフラグ情報およびアルゴリズム識別情報に従って設けられた対応するリストに当該アプリケーションＩＤを保存するように指示する。なお、リスト毎に保存する際には、システムフラグ情報および判定のアルゴリズムの方式を示す情報（アルゴリズム識別情報）を含むリストヘッダ情報がそれぞれのリストに対して設けられる。

当該処理により無線通信モジュール３８による無線通信の準備が完了する。すなわち、無線通信モジュール３８のＣＰＵ６０は、交換相手探索処理のための送信無線フレームを生成して他のゲーム装置に送信することが可能となる。

具体的には、ＣＰＵ６０は、フィルタリング用データに含まれている、交換データ保存領域８０の送信ＢＯＸに実際に格納されている交換データを識別可能なアプリケーションＩＤを含む送信無線フレームを他のゲーム装置に送信することが可能となる。なお、アプリケーションＩＤをシステムフラグ情報およびアルゴリズム識別情報に対応するリストとして纏めてフィルタリング用データ保存領域６８に保存している場合には、リスト毎に送信無線フレームに含めることが可能である。なお、本例においては、交換データ保存領域８０の複数の送信ＢＯＸにそれぞれ交換データが格納されている場合について説明するが、１つの送信ＢＯＸのみに交換データが格納されている場合であっても１つのアプリケーションＩＤを含むリストとして送信無線フレームに含めることが可能である。

したがって、受信無線フレームを受信した他のゲーム装置は、送信無線フレームに含められたアプリケーションＩＤを確認することにより、他のゲーム装置自身が有している交換データに対応付けられているアプリケーションＩＤと比較して、一致するものがあるならば、交換データの交換が可能であり、不一致すなわち一致するものが無いならば交換データの交換が不可能であると判断することが可能となる。

なお、上記においては、フィルタリング用データに含まれるアプリケーションＩＤを分類するために、システムフラグ情報およびアルゴリズム識別情報を用いてリスト毎に分類して、当該リストにアプリケーションＩＤを含める方式について説明したが、上述したアプリケーションプログラムの種別を示すシステムフラグ情報を用いて、さらに高度なアプリケーションＩＤの分類を実行するようにしても良い。

具体的には、上記のアルゴリズム識別情報毎のリストを作成する際に、交換データのフィルタリング用データに含まれるシステムフラグ情報を確認して、内蔵アプリ保存領域８４に内蔵されているアプリケーションプログラムに対応する交換データのアプリケーションＩＤは、システムフラグ情報およびアルゴリズム識別情報毎のリストの中に含めないようにすることが可能である。すなわち、内蔵アプリ保存領域８４に内蔵されているアプリケーションプログラムに対応する交換データのアプリケーションＩＤのリストを作成しないようにすることが可能である。

当該処理により、内蔵アプリ保存領域８４に内蔵されているアプリケーションプログラムに対応する交換データのアプリケーションＩＤについては、送信無線フレーム内に含めないようにすることが可能である。

内蔵アプリ保存領域８４に格納されているアプリケーションプログラムは、全てのゲーム装置に予め内蔵されているものを含んでいる。したがって、当該アプリケーションプログラムを実行することによって生じた交換データを識別するアプリケーションＩＤを含めた送信無線フレームを通信相手であるゲーム装置３に送信あるいは、ゲーム装置３から受信した場合には、ゲーム装置３にも同じアプリケーションプログラムが内蔵されているため基本的にアプリケーションＩＤが一致する可能性が高い。すなわち、各ゲーム装置に同じアプリケーションプログラムが内蔵アプリ保存領域８４に内蔵されているため、内蔵アプリに対応するアプリケーションＩＤ以外にアプリケーションＩＤが一致しない場合であっても基本的に通信相手となる全てのゲーム装置との間で実質的な通信を実行することになる可能性がある。したがって、内蔵アプリ保存領域８４に内蔵されているアプリケーションプログラムに対応する交換データのアプリケーションＩＤは、アルゴリズム識別情報毎のリストの中に含めないようにすることにより、通信相手を制限することが可能となり、データ授受処理を実行させるためにスリープ状態の本体部を起動させる回数を減少させることにより消費電力を低減することが可能となる。

なお、当該処理の場合には、後述する送信スロット作成の際の交換データ授受アプリの確認の際に、送信無線フレームと受信無線フレームとの比較に基づいて一致したアプリケーション以外に、送信ＢＯＸに交換データを格納している内蔵アプリを交換データを授受することが可能なアプリケーションの中に含めるようにすれば良い。

また、ＭＡＣアドレスリスト保存領域７０に本体側のＣＰＵ３１から出力されたＭＡＣアドレスリストを格納することにより、後述する携帯端末間通信処理におけるＭＡＣアドレスフィルタリング処理を実現することが可能となる。

一方、ステップＳ３２において、ＣＰＵ３１（通信設定処理部２０４）は、交換データ保存領域８０の送信ＢＯＸに交換データがないと判断した場合（ステップＳ３２においてＮＯ）には、上記の処理を実行することなく処理を終了する（リターン）。この場合には、送信ＢＯＸに交換データが無いため後述する携帯端末間通信に従う他のゲーム装置との間での交換データの授受処理は実行されないが、後述する携帯固定端末間通信に従う配信データを受信することが可能である。

再び、図１４を参照して、次に、ＣＰＵ３１（通信指示処理部２０６）は、無線通信モジュール３８に対して無線通信の通信開始指示を出力する（ステップＳ２９）。当該指示により無線通信モジュール３８による無線通信が開始される。たとえば、ＣＰＵ３１（通信指示処理部２０６）は、通信設定処理部２０４における通信設定処理の後、無線通信モジュール３８を利用したアプリケーションが実行されていないと判断した場合に無線通信モジュール３８に無線通信の通信開始指示を出力する。

なお、本例においては、一例として、無線通信モジュール３８による無線通信の準備として、交換データ保存領域８０の送信ＢＯＸの内容に変更が有ったかどうかに基づいて、例えば、図１３で説明した如くアプリケーションプログラムが交換データ保存領域８０の送信ＢＯＸに交換データを格納したことに応答して当該通信設定処理部２０４における処理を実行し、通信指示処理部２０６における通信開始指示を出力する場合について説明したが、特にその場合に限られず、電源投入時に、無線通信が有効に設定された場合に通信設定処理（ステップＳ２８）を開始するようにすることも可能である。あるいは、ユーザからの操作指示に応答して通信設定処理（ステップＳ２８）を開始するようにしても良い。あるいは、所定期間経過毎に、自動的に通信設定処理（ステップＳ２８）を開始するようにしたり、これらを組み合わせるようにしても良い。

図１６は、通信設定処理によりＲＡＭ６６に格納されたデータの概念図について説明する図である。

図１６（Ａ）を参照して、ここでは、ＲＡＭ６６のフィルタリング用データ保存領域６８にアプリケーションＩＤ「Ａ，Ｂ，Ｃ，Ｄ」のリストがそれぞれ格納されている場合が示されている。

なお、図１６（Ａ）は、ＭＡＣアドレスリストには何も格納されていない状態である。なお、ここでは、内蔵アプリＤに対応するアプリケーションＩＤもフィルタリング用データ保存領域６８に格納した場合について説明するが、上述したように含めないようにすることも可能である。以下においても同様である。

図１６（Ｂ）においては、図１６（Ａ）で説明したアプリケーションＩＤのリストがフィルタリング用データ保存領域６８に格納されるとともに、ＭＡＣアドレスリストとして、ＭＡＣアドレスＡＤ１，ＡＤ２，ＡＤ３がＭＡＣアドレスリスト保存領域７０に格納されている場合が示されている。当該ＭＡＣアドレスリストのデータは、後述する携帯端末間通信におけるＭＡＣアドレスの比較によるＭＡＣアドレスフィルタリング処理の際に用いられる。

＜無線通信モジュール３８による無線通信の全体フロー＞
図１７は、本発明の実施の形態に従う無線通信モジュール３８で実行する無線通信のフロー図である。

図１７を参照して、ＣＰＵ３１からの通信開始指示に従い無線通信モジュール３８のＣＰＵ６０は、以下の処理を実行する。具体的には、ＣＰＵ６０は、所定期間の間、携帯端末間通信を実行する（ステップＳ４４）。そして、再び、所定期間の間、携帯端末間通信を実行する（ステップＳ４６）。そして、次に、所定期間の間、携帯固定端末間通信を実行する（ステップＳ４８）。そして、再び、ステップＳ４４に戻って携帯端末間通信を実行する。

なお、携帯端末間通信と携帯固定端末間通信を実行する所定期間の長さは同じであっても良いし、異なるものとすることも可能である。

また、本例においては、一例として、携帯端末間通信を実行した後に、携帯固定端末間通信を実行する場合について説明するが、特に当該順序に限られず、携帯固定端末間通信を最初に実行するようにしても良い。

また、本実施例においては、２回の携帯端末間通信の後に、１回の携帯固定端末間通信を実行する場合について説明するが、特にこの場合に限られず、回数は自由に設定することが可能である。

当該携帯端末間通信（図１８）および携帯固定端末間通信（図８６）については、一例として無線通信モジュール３８のＣＰＵ６０がＲＯＭ７２に格納されている携帯端末間通信を実行するためのアプリケーションおよび携帯固定端末間通信を実行するためのアプリケーションをそれぞれ実行することにより実現されるものである。
したがって、無線通信モジュール３８は、本体側のＣＰＵ３１のアプリケーションの実行の有無に関わらず、例えば、アプリケーションを実行していないとき、さらには、スリープ状態等の省電力状態にあるときでも、上記の携帯端末間通信および携帯固定端末間通信を実行し続ける。

なお、本体側のＣＰＵ３１は、無線通信モジュール３８を利用するアプリケーションを実行する場合には、無線通信モジュール３８に対して、当該無線通信の中止を指示し、当該無線通信を終了させて、当該アプリケーションに基づく別の通信を実行することも可能である。

そして、ＣＰＵ３１は、当該別の通信が終了した場合には、上記で説明した通信設定処理部２０４における通信設定処理後、通信指示処理部２０６による通信開始指示を出力する。これにより、再び携帯端末間通信および携帯固定端末間通信である無線通信を再開することが可能である。

＜無線通信モジュール３８による携帯端末間通信＞
図１８は、本発明の実施の形態に従う携帯端末間通信について説明するフロー図である。当該処理は、無線通信モジュール３８において交換データを交換する通信相手を探索する交換相手探索処理であり、一例としてＣＰＵ６０が、ＲＯＭ７２に格納されている携帯端末間処理を実行するためのアプリケーションを実行することにより実現される。

図１８を参照して、まず、ＣＰＵ６０（無線フレーム設定部２２２）は、送信無線フレームを設定する（ステップＳ５０）。

具体的には、ＣＰＵ６０（無線フレーム設定部２２２）は、ゲーム装置３に対して送信する送信データとしてＲＡＭ６６に格納されているフィルタリング用データ保存領域６８に格納されているアプリケーションＩＤに基づく送信無線フレームを設定する。

なお、アプリケーションＩＤを各判定方式に対応するリストとして纏めてフィルタリング用データ保存領域６８に保存している場合には、アプリケーションＩＤをリスト毎に送信無線フレームに含める。その際には、リストを識別するために設けられた判定のアルゴリズムの方式を示すアルゴリズム識別情報およびシステムフラグ情報を含むリストヘッダ情報もリストとともに含めた送信無線フレームを設定する。設定された送信無線フレームは、ＲＦ−ＩＣ６２を介して外部に出力される送信データとしてＲＡＭ６６の送信無線フレーム保存領域６７に保存される。また、設定された送信無線フレームは、後述するアプリケーションＩＤ判定処理において用いられる。

図１９は、本発明の実施の形態に従う携帯端末間通信においてゲーム装置において送信される送信無線フレームの構成について説明する図である。なお、受信される受信無線フレームの構成についても同様である。

図１９を参照して、送信無線フレームは、ヘッダフィールドＤ１と、データフィールドＤ３とを含む。

ヘッダフィールドＤ１は、当該送信無線フレームを受信無線フレームとして受信するインターフェース（無線通信モジュール）に対して当該受信無線フレームの開始を認識させ、同期を取るタイミングを設定するためのデータやフレーム長およびＭＡＣアドレスを規定するＭＡＣ部Ｄ２等を含む。

データフィールドＤ３は、複数のＩＥ（Information Element）データを含む。例えば、無線通信で用いられる識別コード、ＳＳＩＤ（Service Set Identifier）や、電波干渉を避けるために設定される無線チャンネル（周波数）等のデータに関するＩＥデータがそれぞれ格納される。

そして、本例においては、データフィールドＤ３に携帯端末間通信のＩＥデータとして、ベンダ特定ＩＥデータＤ４が含まれる場合が示されている。ベンダ特定ＩＥデータは、本例における携帯端末間通信における交換データの通信処理を実行するか否かに関する通信判断条件に相当する。

ここで、ＭＡＣアドレスを規定するＭＡＣ部Ｄ２の構成について説明する。
ＭＡＣ部Ｄ２は、ネットワーク機器のベンダー毎に割り当てられているベンダーコードＤ５と、各ベンダがネットワークインターフェース毎に異なるように割り当てるインタフェースコードＤ６とを含む。

ベンダーコードＤ５およびインタフェースコードＤ６は、それぞれ３オクテット（１オクテットは８ビット）で構成され、ベンダーコードＤ５の最初のオクテットＤ５−１の最下位のビットＤ５ｂがＸ、最下位から２番目のビットＤ５ａがＹとしてＭＡＣアドレスのタイプを規定するものとして設けられている。

具体的には、ビットＸは、グループ分けされた複数の宛先を示すマルチキャストアドレスか、ただ１つの宛先を表すユニキャストアドレスかを判定するビットとして用いられる。本例においては、ビットＸ＝１の場合には、マルチキャストアドレス、ビットＸ＝０の場合には、ユニキャストアドレスとする。

そして、ビットＹは、ユニキャストアドレスの場合において、グローバルアドレスか、ローカルアドレスかを判定するビットとして用いられる。本例においては、ビットＸ＝０の場合にビットＹ＝０の場合には、グローバルアドレス、ビットＹ＝１の場合には、ローカルアドレスとする。

そして、本例においては、ＩＥデータに含まれる携帯端末間通信のＭＡＣアドレスのタイプとして、ビットＸ＝０、Ｙ＝１が設定されているものとする。すなわち、ベンダーコードＤ５には、ローカルアドレスが設定されるものとする。

当該ローカルアドレスについては後述するが変更することが可能である。
図２０は、ベンダ特定ＩＤデータＤ４の構成について説明する図である。

図２０を参照して、ベンダ特定ＩＥデータは、タグ情報ＤＤ１、タグ長情報ＤＤ２、ベンダ情報ＤＤ３、通信データ識別情報ＤＤ４、第１ＩＤ群ＤＤＡ、第２ＩＤ群ＤＤＢとを含む。

タグ情報ＤＤ１は、複数のＩＥデータをそれぞれ識別する識別データである。タグ長情報ＤＤ２は、ベンダ特定ＩＥデータＤ４のデータ長を示すデータが含まれている。

ベンダ情報ＤＤ３は、当該データを提供する企業等を識別するためのデータである。
通信データ識別情報ＤＤ４は、通信データの種別を示すデータであり、携帯端末間通信の場合には、携帯端末間通信の通信データを示す情報が格納される。なお、携帯固定端末間通信の場合において、固定端末機器５から送信される配信無線フレームには、携帯固定端末間通信の通信データを示す別の情報が格納される。当該情報を確認することにより携帯端末間通信の通信データかどうか、すなわち、受信無線フレームが携帯端末間処理として処理可能な無線フレームであるかどうかが判断される。あるいは、受信した配信無線フレームが携帯固定端末間処理として処理可能な無線フレームであるかどうかが判断される。

本例においては、一例として、アプリケーションＩＤをリストとして纏めてフィルタリング用データ保存領域６８に保存している場合について説明する。

それゆえ、アプリケーションＩＤのリストおよび当該リストを識別するために設けられたリストヘッダ情報が設けられる形式となっている。リストヘッダ情報は、システムフラグ情報と、アルゴリズム識別情報とを含む。

当該形式により、複数のアプリケーションＩＤで、システムフラグ情報および比較のアルゴリズムを識別するアルゴリズム識別情報を共有することができるためデータ量を縮小することが可能となる。また、システムフラグ情報および比較のアルゴリズム毎にアプリケーションＩＤのリストが設けられた形式であるため比較の際の検索が容易となり高速な比較処理が可能となる。なお、比較のアルゴリズムについては後述する。

本例においては、一例として、比較のアルゴリズムを規定する２つのそれぞれ異なるアルゴリズム識別情報に従って第１ＩＤ群ＤＤＡと、第２ＩＤ群ＤＤＢとが設けられている場合が示されている。なお、ここで、一例として、第１ＩＤ群ＤＤＡおよび第ＩＤ群ＤＤＢのシステムフラグ情報は、同じであるものとする。また、当該システムフラグ情報は、一例として、内蔵アプリ保存領域８４に内蔵されたアプリケーション以外のアプリケーションであることを示すものであるとする。

第１ＩＤ群ＤＤＡは、第１ＩＤリストヘッダ情報ＤＤ５と、第１ＩＤリストＤＤ６とを含む。

第１ＩＤリストＤＤ６は、複数のアプリケーションＩＤを含む。本例においては一例として、アプリケーションＩＤ［０］ＤＤ６−１、アプリケーションＩＤ［１］ＤＤ６−２、・・・が含まれる場合が示されている。

各アプリケーションＩＤは、長さデータＤＤ９と、ＩＤデータＤＤ１０とを含む。長さデータＤＤ９は、ＩＤデータＤＤ１０の比較に用いられる長さを示すデータである。ＩＤデータＤＤ１０は、アプリケーション毎に予め設けられたアプリケーション名を示す識別データである。当該アプリケーションＩＤは、上述したＣＰＵ３１におけるアプリケーションの実行により交換データ登録イベントの発生および交換データの指定入力に従い交換データに対応付けられて設定される。例えば、この場合は一例として交換条件データ等の設定はなかったものとする。

当該第１ＩＤリストＤＤ６の複数のアプリケーションＩＤのリストのヘッダ情報として、第１ＩＤリストヘッダ情報ＤＤ５が設けられる。

具体的には、第１ＩＤリストヘッダ情報ＤＤ５は、交換データに対応するアプリケーションの種別を規定するシステムフラグ情報ＤＤ５−１、比較のアルゴリズムを規定するアルゴリズム識別情報ＤＤ５−２、リストとして設けられたアプリケーションＩＤの長さあるいは個数を規定するリスト長情報ＤＤ５−３とを含む。

第２ＩＤ群ＤＤＢは、第２ＩＤリストヘッダ情報ＤＤ７と、第２ＩＤリストＤＤ８とを含む。

第２ＩＤリストヘッダ情報ＤＤ７は、システムフラグ情報ＤＤ７−１、アルゴリズム識別情報ＤＤ７−２、リスト長情報ＤＤ７−３とを含む。

第２ＩＤリストヘッダ情報ＤＤ７−１は、上述したように交換データ用のアプリケーションＩＤのリストを規定するシステムフラグ情報ＤＤ７−１、比較のアルゴリズムを規定するアルゴリズム識別情報ＤＤ７−２、リストとして設けられたアプリケーションＩＤ＃の長さあるいは個数を規定するリスト長情報ＤＤ７−３とを含む。

第２ＩＤリストＤＤ８は、複数のアプリケーションＩＤ＃を含む。本例においては一例として、アプリケーションＩＤ＃［０］ＤＤ８−１、アプリケーションＩＤ＃［１］ＤＤ８−２、・・・が含まれる場合が示されている。

各アプリケーションＩＤ＃は、ＩＤデータＤＤ１１と、フィルタサイズデータＤＤ１２と、センドフラグデータＤＤ１３と、レシーブフラグデータＤＤ１４と、マスクデータＤＤ１５と、コンディションデータＤＤ１６と、リクエストＤＤ１７とを含む。

本例においてアプリケーションＩＤ＃は、上述した送受信条件データおよび取得条件データが交換条件データとして収められている。具体的には、センドフラグデータおよびレシーブフラグデータが送受信条件データを示すデータである。また、マスクデータ、コンディションデータ、リクエストデータが取得条件データを示すデータである。当該アプリケーションＩＤ＃は、上述したＣＰＵ３１におけるアプリケーションの実行により交換データ登録イベントの発生および交換データの指定入力に従い交換データに対応付けられて設定される。例えば、この場合は一例として交換データ登録イベントにおいて、送受信条件データおよび取得条件データ等の交換条件データの設定があったものとする。

ＩＤデータＤＤ１１は、アプリケーション毎に予め設けられたアプリケーション名を示す識別データである。

フィルタサイズデータＤＤ１２は、マスクデータＤＤ１５、コンディションデータＤＤ１６、リクエストデータＤＤ１７のデータ長を規定するデータである。したがって、フィルタサイズデータＤＤ１２の値に従ってマスクデータＤＤ１５、コンディションデータＤＤ１６、リクエストデータＤＤ１７の範囲が規定されることになる。

センドフラグデータＤＤ１３、レシーブフラグデータＤＤ１４は、アプリケーションＩＤ＃に含まれるＩＤデータＤＤ１１に対応する交換データの送受信条件データを規定するものである。一例として、送信通信のみ可か、受信通信のみ可か、双方向通信のみ可か、いずれの条件でも通信可かその通信の条件を規定するためのデータである。

マスクデータＤＤ１５、コンディションデータＤＤ１６、リクエストデータＤＤ１７は、交換データの取得条件データを規定するデータである。

コンディションデータＤＤ１６は、交換データの交換に際し、自己が保有しているデータあるいは自己の属性等を示すデータ等、相手に送信する自己の交換データに関連付けられた属性データである。自己が送信する交換データに関して相手の要求条件を満たしているかどうかに用いられる。

リクエストデータＤＤ１７は、交換データの交換に際し、受信する相手に要求する交換データに関連付けられた属性データである。相手から受信する交換データに関して自己の要求条件を満たしているかどうかに用いられる。

マスクデータＤＤ１５は、リクエストデータＤＤ１７の有効／無効の領域を設定するデータである。すなわち、マスクデータＤＤ１５がリクエストデータＤＤ１７の無効を規定した場合には、交換データの交換に際し、自己の要求条件は無い、言い換えるならば自己の要求条件は常に満たしていることを意味する。

当該アプリケーションＩＤのリストを送信無線フレーム中にデータとして含めることにより、当該送信無線フレームを受信無線フレームとして受信した側において、当該アプリケーションＩＤのリストに基づいて、例えば同じアプリケーションの交換データを有しているか否かを判断することが可能である。なお、比較した場合に条件が一致するか否かを判断できさえすれば良く、例えば、当該アプリケーションＩＤそのものを送信するのではなく、ハッシュ関数に基づくハッシュ値を送信して、受信した側においてデータ比較するようにしても良い。他の情報等についても同様にすることも可能である。

当該送信無線フレームは、不特定の相手（ゲーム装置）に対して送信されたものであり、不特定の相手（ゲーム装置）が受信無線フレームとして受信するものである。後述するが子機側のゲーム装置は、宛先を特定せずに当該送信を繰り返し実行する。そして、当該送信無線フレームを受信無線フレームとして受信したゲーム装置（親機側）は、当該送信無線フレームを発信したゲーム装置（子機側）に対して、自己が有するデータに基づく送信無線フレームを送信し、データの授受に従って不特定のゲーム装置同士が通信処理を実行する。

なお、本例における送信無線フレームについては、一例として、複数のＩＥ（Information Element）データが含まれた送信無線フレームについて説明したが、特にこれに限られず、ベンダ特定ＩＥデータのみを含む送信無線フレームとすることも可能である。

図２１は、フィルタリング用データ保存領域６８で保存されているアプリケーションＩＤの状態を説明する概念図である。

図２１を参照して、ここでは、アプリケーションプログラムＡに対応する送信ＢＯＸＳＢＡと、アプリケーションプログラムＢに対応する送信ＢＯＸＳＢＢが設けられている場合が示されている。各送信ＢＯＸには、複数の交換データとなるデータが格納されている場合が示されている。後述するが、一例として、基本的には各送信ＢＯＸ内の左端のデータから順番に１つずつ送信されるものとする。本例においては、送信ＢＯＸＳＢＡ内の左端のデータＸと、送信ＢＯＸＳＢＢの左端のデータＺが示されている。

データＸは、ＩＤデータＩＤＤ０Ａ（「０００１」）と、データグループＩＤＩＤＤ１Ａ（「１００１」）と、フィルタリング用データＩＤＤ９Ａ（「Ｆ１００１」）とを含む。データＺは、ＩＤデータＩＤＤ０Ｂ（「０００２」）と、データグループＩＤＩＤＤ１Ｂ（「２００１」）と、フィルタリング用データＩＤＤ９Ｂ（「Ｆ２００１」）とを含む。

上述したように、交換データ保存領域８０の各送信ＢＯＸのデータが確認され、交換データが有ると判断された場合には、各送信ＢＯＸに格納されているデータのフィルタリング用データが取得されて、フィルタリング用データ保存領域６８に格納される。本例においては、送信ＢＯＸＳＢＡの左端のデータＸのフィルタリング用データＩＤＤ９Ａ（「Ｆ１００１」）が取得されて、フィルタリング用データ保存領域６８に格納される。同様に、送信ＢＯＸＳＢＢの左端のデータＺのフィルタリング用データＩＤＤ９Ｂ（「Ｆ２００１」）が取得されて、フィルタリング用データ保存領域６８にリスト形式で格納される。

当該フィルタリング用データ保存領域６８の格納の際に、システムフラグ情報およびアルゴリズム識別情報に基づいて、アプリケーションＩＤが分類されたリスト形式で保存される。

フィルタリング用データは、上述したようにシステムフラグ情報と、アルゴリズム識別情報と、アプリケーションＩＤとで構成されている。そして、当該システムフラグ情報およびアルゴリズム識別情報に基づいて、フィルタリング用データのアプリケーションＩＤが分類される。ここでは、データＸのアプリケーションＩＤＡと、データＺのアプリケーションＩＤＢとが同じ分類としてリスト形式で纏められた状態が示されている。リストヘッダ情報には、システムフラグ情報、アルゴリズム識別情報およびリスト長情報が含められている。そして、当該形式で保存されたフィルタリング用データのアプリケーションＩＤが送信無線フレームにセットされることになる。

なお、本例においては、一例として、アプリケーションＩＤをシステムフラグ情報およびアルゴリズム識別情報に従うリストとして纏めてフィルタリング用データ保存領域６８に保存している場合において、アプリケーションＩＤをリスト毎に送信無線フレームに含めるとともに、当該リストを識別するために設けられたシステムフラグ情報およびアルゴリズム識別情報を含むリストヘッダ情報もリストとともに含めた送信無線フレームを設定する場合について説明したが、フィルタリング用データ保存領域６８にリスト毎にアプリケーションＩＤが保存されていない場合であっても上記の送信無線フレームを設定することは可能である。

例えば、送信無線フレームを設定する際に、無線フレーム設定部２２２が、フィルタリング用データ保存領域６８に保存されているフィルタリング用データに含まれているアプリケーションＩＤと、当該アプリケーションＩＤに対応づけられたシステムフラグ情報およびアルゴリズム識別情報に基づいて、システムフラグ情報およびアルゴリズム識別情報毎のリストと、当該リストを識別するためのリストヘッダ情報を作成して、送信無線フレームを設定するようにすることも可能である。

再び、図１８を参照して、送信無線フレームを設定した後、次に、ＣＰＵ６０（通信相手探索部２２４）は、所定期間が経過したかどうかを判断する（ステップＳ５１）。そして、ステップＳ５１において、ＣＰＵ６０は、所定期間が経過していないと判断した場合（ステップＳ５１においてＮＯ）には、通信相手（他のゲーム装置）を探索する通信相手サーチ処理を実行する（ステップＳ５２）。通信相手サーチ処理については後述する。

そして、次に、ＣＰＵ６０（通信相手探索部２２４）は、通信相手サーチ処理により通信相手が発見されたかどうかを判断する（ステップＳ５４）。

ステップＳ５４において通信相手が発見されない場合（ステップＳ５４においてＮＯ）には、ステップＳ５１に戻る。

ステップＳ５４において、通信相手が発見された場合（ステップＳ５４においてＹＥＳ）には、ＣＰＵ６０（装置識別情報比較部２２６）は、ＭＡＣアドレスを比較する（ステップＳ５６）。具体的には、受信無線フレームに含まれるＭＡＣアドレスと、上述したＭＡＣアドレスリスト保存領域７０に格納されているＭＡＣアドレスとを比較する。上述したようにＭＡＣアドレスは、通信対象を識別する識別情報であり、各ゲーム装置にそれぞれ固有のＭＡＣアドレスが割り当てられている。そして、ＭＡＣアドレスリスト保存領域７０には、各ゲーム装置に割り当てられたＭＡＣアドレスが保存されている。

そして、次に、ＣＰＵ６０（装置識別情報比較部２２６）は、受信無線フレームに含まれる他のゲーム装置のＭＡＣアドレスが、ＭＡＣアドレスリストに格納されているＭＡＣアドレスと一致するかどうかを判断する（ステップＳ５８）。

そして、ステップＳ５８において、ＭＡＣアドレスが一致したと判断した場合（ステップＳ５８においてＹＥＳ）には、再びステップＳ５１に戻る。すなわち、以降の処理を実行することなく当該ＭＡＣアドレスに対応する他のゲーム装置との通信を終了する。したがって、通信可能範囲１０に含まれる他のゲーム装置からの通信対象となるデータを受信する毎に識別情報であるＭＡＣアドレスと一致するかどうかの判断が繰り返される。

図２２は、本発明の実施の形態に従うＭＡＣアドレスを比較する場合の概念図である。
本例においては、ゲーム装置１と、通信相手である他のゲーム装置としてゲーム装置３との通信接続について説明する。

図２２を参照して、ここでは、ゲーム装置１側において、交換データ保存領域８０の送信ＢＯＸＳＢＡ〜ＳＢＤにそれぞれ交換データが格納されている場合が示されている。

そして、無線通信モジュール３８のＲＡＭ６６のフィルタリング用データ保存領域６８には、図１６（Ａ）で説明したのと同様にアプリケーションＩＤ「Ａ，Ｂ，Ｃ，Ｄ」がそれぞれ格納されている場合が示されている。

なお、ＭＡＣアドレスリストには何も格納されていない。
次に、ゲーム装置３側について説明する。ゲーム装置３側の対応する同一の構成要素については、「Ｐ」の記号をさらに付加している。具体的には、ゲーム装置１の交換データ保存領域８０と、ゲーム装置３側の交換データ保存領域８０Ｐとが対応している。

また、ゲーム装置１の無線通信モジュール３８と、ゲーム装置３側の無線通信モジュール３８Ｐとが対応している。他の場合についても同様である。

そして、ゲーム装置３の交換データ保存領域８０Ｐの送信ＢＯＸＳＢＢ，ＳＢＥにそれぞれ交換データが格納されている場合が示されている。

ゲーム装置３側においても同様の方式に従って、無線通信モジュール３８Ｐのフィルタリング用データ保存領域６８ＰにアプリケーションＩＤ「Ｂ，Ｅ」がそれぞれ格納されている場合が示されている。

なお、ＭＡＣアドレスリストには何も格納されていない。当該場合において、ゲーム装置１である自機のＭＡＣアドレスはＡＤ０に設定されているものとする。

また、ゲーム装置３のＭＡＣアドレスはＡＤ１に設定されているものとする。
例えば、ゲーム装置３からの受信無線フレームを受信した場合には、ゲーム装置３のＭＡＣアドレスＡＤ１は、ゲーム装置１のＭＡＣアドレスリストには登録されていないためＭＡＣアドレスは一致しないと判断される。したがって、次の処理に進む。

なお、本例においては、ゲーム装置１において、ＭＡＣアドレスリストに登録されているかどうかが判断される場合について説明しているが、ゲーム装置３側においても同様の処理が実行される。

図２３は、本発明の実施の形態に従うＭＡＣアドレスを比較する場合の別の概念図である。

図２３を参照して、ここでは、図２２の構成と比較して、ＭＡＣアドレスリストに登録されている内容が異なる。具体的には、無線通信モジュール３８のＭＡＣアドレスリスト保存領域７０には、ＭＡＣアドレスＡＤ１が登録されている場合が示されている。

また、同様に、ゲーム装置３側のＭＡＣアドレスリスト保存領域７０ＰにＭＡＣアドレスＡＤ０が登録されている場合が示されている。

例えば、ゲーム装置３からの受信無線フレームを受信した場合には、ゲーム装置３のＭＡＣアドレスＡＤ１は、ゲーム装置１のＭＡＣアドレスリストに登録されておりＭＡＣアドレスが一致すると判断される。

したがって、当該場合には、当該ＭＡＣアドレスに対応する他のゲーム装置であるゲーム装置３との以降の通信処理を行わない（ＭＡＣアドレスフィルタリング処理）。すなわち、ＭＡＣアドレスリストに登録されている以前に通信処理が実行されたゲーム装置との間では実質的な通信は実行されない。なお、ゲーム装置３側においても同様の処理が実行される。

なお、上述したようにＭＡＣアドレスリスト保存領域７０に格納されているＭＡＣアドレスリストはたとえば所定の操作指示に従って消去することも可能であり、消去された場合には、再度、以前に通信処理が実行された装置ともデータ通信を実行することが可能である。すなわち、以前に交換データの授受が実行された装置についても状況が変わり（新たな交換データが設定されているなど）、交換データの授受が可能な状況となっている可能性もあるため再度、交換データの交換が可能か否かを判断して、可能であるならば交換データの授受を実行するようにしても良い。

たとえば、図９のステップＳ１２において空きＢＯＸスロットに交換データを格納した際に、ＭＡＣアドレスリスト保存領域８８および７０に格納されているアドレスリストを消去するようにしても良い。

再び図１８を参照して、ステップＳ５８において、ＭＡＣアドレスが一致しないと判断した場合（ステップＳ５８においてＮＯ）には、ＣＰＵ６０（通信データ判定部２２８）は、受信したデータの内容を確認する（ステップＳ５９）。

そして、ＣＰＵ６０（通信データ判定部２２８）は、受信したデータとして、受信無線フレームが携帯端末間処理として処理可能な無線フレームであるかどうかを判定する（ステップＳ６０）。

具体的には、図１９で説明した当該データを提供する企業等を識別するためのベンダ情報がゲーム装置１が予め有しているベンダ情報と一致するかどうかを判断する。ベンダ情報が一致する場合とは、送信されたデータの発信源が互いに通信接続が可能な同種の装置であることを意味し、異なる場合には、送信されたデータの発信源が互いに通信接続が不可能である全く種類の異なる装置であることを意味する。

また、通信データ識別情報がゲーム装置１が予め有している通信データ識別情報と一致するかどうかを判断する。通信データ識別情報が一致する場合とは、携帯端末間通信における通信データ、すなわち携帯端末間処理として処理可能な無線フレームであることを意味する。ゲーム装置１側の比較の対象であるベンダ情報は予めＲＯＭ７２に登録されているものとする。また、ゲーム装置１側の比較の対象である通信データ識別情報についても予めＲＯＭ７２に登録されているものとする。

一方、携帯端末間通信における通信データ識別情報と、後述するが携帯固定端末間通信における固定端末機器５から出力される配信無線フレームに含まれる通信データ識別情報とは異なるため仮に携帯端末間通信において固定端末機器５から出力されたビーコン（配信無線フレーム）を受信した場合であっても通信データ識別情報が異なるためデータ通信は実行されず同種のゲーム装置とのみ通信することが可能である。

ＣＰＵ６０（通信データ判定部２２８）は、携帯端末間通信か携帯固定端末間通信かによって比較する通信データ識別情報を切り替えて、受信したデータ（受信無線フレーム）に含まれている通信データ識別情報と一致するか否か判断する。

すなわち、ステップＳ６０において、受信無線フレームを受信しないと判断した場合（ステップＳ６０においてＮＯ）には、再びステップＳ５１に戻る。したがって、互いに通信接続が不可能である装置からデータを受信あるいは通信対象とならないデータを受信した場合には、以降の処理を実行することなく通信を終了する。なお、本例においてはベンダ情報および通信データ識別情報がともに一致するかどうかを判断する場合について説明したが、通信データ識別情報のみが一致するかどうかを判断するようにしても良い。

次に、受信無線フレームを受信したと判断した場合（ステップＳ６０においてＹＥＳ）には、次に、ＣＰＵ６０（アプリケーションＩＤ判定部２３０）は、アプリケーションＩＤの判定処理を実行する（ステップＳ６２）。

アプリケーションＩＤの判定処理については後述する。
そして、ＣＰＵ６０（アプリケーションＩＤ判定部２３０）は、判定処理結果に基づいてアプリケーションＩＤの一致フラグがオンであるかどうかを判断する（ステップＳ６４）。具体的には、受信した受信無線フレームに含まれるアプリケーションＩＤのリストと自己が有している送信無線フレームに含まれるアプリケーションＩＤのリストとを参照して、一致すると判定されたアプリケーションＩＤが少なくとも１つ存在するかどうかを判断する。すなわち、ここでは、通信接続により交換可能な交換データを互いに有しているかどうかが判断される。同一のアプリケーションＩＤであれば、データを交換した場合に同じアプリケーションを実行することにより互いにデータを利用可能である。なお、アプリケーションＩＤが同じでなくても、データの互換性のあるアプリケーションであることが判定して、そのような関係にあるアプリケーションＩＤであれば、ステップＳ６４でＹＥＳと判断してもよい。

ＣＰＵ６０（アプリケーションＩＤ判定部２３０）は、アプリケーションＩＤの一致フラグがオンであると判断した場合（ステップＳ６４においてＹＥＳ）には、一致したアプリケーションＩＤに対応する交換データを有する他のゲーム装置が発見された旨すなわち通信相手が交換データを交換する交換相手である旨を本体側に通知する（ステップＳ６６）。そして処理を終了する（エンド）。

以降、他のゲーム装置である通信相手と接続を確立して、他のゲーム装置との間での一致したアプリケーションＩＤに対応する交換データの授受を実行するデータ授受処理については、無線通信モジュール３８を用いた本体側のＣＰＵ３１のアプリケーションとして実行されることになる。

したがって、本体側に、交換データを有する他のゲーム装置が発見された旨を通知することにより無線通信モジュール３８のＣＰＵ６０のみが独立して実行する無線通信、すなわち、無線通信モジュール３８において交換データを交換する通信相手を探索する交換相手探索処理は終了する。

一方、ステップＳ６４において、アプリケーションＩＤの一致フラグがオンでない場合（一致フラグオフ）（ステップＳ６４においてＮＯ）には、ステップＳ５１に戻る。

当該処理により、本例においては、無線通信モジュール３８における交換相手探索処理により交換可能な通信相手が見つかった場合にのみ、本体側のＣＰＵ３１に通知されて、通信相手との接続が確立されて、交換データの授受が実行される。したがって、例えば、本体側のＣＰＵ３１がスリープ状態等の省電力状態である場合に、無線通信モジュール３８における交換相手探索処理により通信相手が見つかった場合であっても交換が可能でなければ本体側のＣＰＵ３１に通知されて通信接続が確立されることはないため、ゲーム装置１全体における省電力を図ることが可能である。

＜アプリケーションＩＤの判定処理＞
本実施例においては、アプリケーションＩＤを各判定方式に対応するリストとして纏めた形式である図２０に示す送信無線フレームのアプリケーションＩＤの判定処理について説明する。

図２４は、アプリケーションＩＤ判定部２３０における全体のフロー図である。
図２４を参照して、ＣＰＵ６０（ＩＤリストヘッダ情報比較部２３２）は、まず、比較対象となるＩＤリストヘッダ情報を抽出する（ステップＳ７２）。

例えば、まず最初に、受信無線フレーム保存領域６９に保存された受信無線フレーム（ゲーム装置３）のベンダ特定ＩＥデータに含まれる第１ＩＤリストヘッダ情報と、送信無線フレーム保存領域６７に保存された送信無線フレーム（自機１）のベンダ特定ＩＥデータに含まれる第１ＩＤリストヘッダ情報を抽出する。

なお、当該フローにおいては、後述するが、システムフラグ情報およびアルゴリズム識別情報が一致するまで受信無線フレーム保存領域６９に保存された受信無線フレームおよび送信無線フレーム保存領域６７に保存された送信無線フレームからＩＤリストヘッダ情報をそれぞれ１つずつ抽出して、全ての組み合わせにおいて比較処理を実行する。

そして、次に、ＣＰＵ６０（ＩＤリストヘッダ情報比較部２３２）は、受信無線フレーム保存領域６９に保存された受信無線フレームから抽出されたＩＤリストヘッダ情報に含まれるシステムフラグ情報と、送信無線フレーム保存領域６７に保存された送信無線フレームから抽出されたＩＤリストヘッダ情報に含まれるシステムフラグ情報と一致するかどうかを判断する（ステップＳ７４）。

ステップＳ７４において、システムフラグ情報がともに一致すると判断された場合（ステップＳ７４においてＹＥＳ）には、次に、ＣＰＵ６０（ＩＤリストヘッダ情報比較部２３２）は、受信データから抽出されたＩＤリストヘッダ情報に含まれるアルゴリズム識別情報が送信無線フレーム保存領域６７に保存された送信無線フレームから抽出されたＩＤリストヘッダ情報に含まれるアルゴリズム識別情報と一致するかどうかを判断する（ステップＳ７６）。

ステップＳ７６において、アルゴリズム識別情報が一致しないと判断された場合（ステップＳ７６においてＮＯ）には、ステップＳ８２に進む。

ステップＳ７６において、アルゴリズム識別情報がともに一致すると判断された場合（ステップＳ７６においてＹＥＳ）には、次に、ＣＰＵ６０（ＩＤリストヘッダ情報比較部２３２）は、受信無線フレーム保存領域６９に保存された受信無線フレームから抽出されたＩＤリストヘッダ情報に含まれるアルゴリズム識別情報が「０」かどうかを判断する（ステップＳ７８）。

ステップＳ７８において、アルゴリズム識別情報が「０」である場合には、ＣＰＵ６０（ＩＤリスト比較部２３４）は、第１アルゴリズムに従うＩＤリスト比較処理を実行する（ステップＳ８０）。そして、処理を終了する（リターン）。第１アルゴリズムに従うＩＤリスト比較処理については後述する。

一方、ステップＳ７８において、アルゴリズム識別情報が「０」でない場合、すなわち、「１」である場合には、ＣＰＵ６０（ＩＤリスト比較部２３４）は、第２アルゴリズムに従うＩＤリスト比較処理を実行する（ステップＳ８６）。そして、処理を終了する（リターン）。第２アルゴリズムに従うＩＤリスト比較処理については後述する。

一方、ステップＳ７４において、システムフラグ情報が一致しないと判断された場合（ステップＳ７４においてＮＯ）には、次に、ＣＰＵ６０（ＩＤリストヘッダ情報比較部２３２）は、比較対象となる他のＩＤリストヘッダ情報が有るかどうかを判断する（ステップＳ８２）。

ステップＳ８２において、比較対象となる他のＩＤリストヘッダ情報が有ると判断した場合には、次の比較対象となるＩＤリストヘッダ情報を抽出する（ステップＳ８４）。そして、ステップＳ７４に進み同様の処理を繰り返す。例えば、一例として第２ＩＤリストヘッダ情報を抽出する。

一方、ステップＳ８２において、ＣＰＵ６０（ＩＤリストヘッダ情報比較部２３２）は、比較対象となる他のＩＤリストヘッダ情報がないと判断した場合には、処理を終了する（リターン）。

すなわち、受信無線フレーム保存領域６９に保存された受信無線フレームおよび送信無線フレーム保存領域６７に保存された送信無線フレームからＩＤリストヘッダ情報を抽出して、全ての組み合わせにおいて一致するものが無い場合には、交換データは存在しないと判断して処理を終了する。

例えば、本例の如く、送信無線フレーム（自機１）に２つのＩＤリストヘッダ情報が含まれ、また、受信無線フレーム（ゲーム装置）にも２つのＩＤリストヘッダ情報が含まれる場合において、ＩＤリストヘッダ情報を抽出して全ての組み合わせについて比較する場合について説明すると、まず、送信無線フレーム（自機１）のベンダ特定ＩＥデータに含まれる第１ＩＤリストヘッダ情報を抽出し、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストヘッダ情報を抽出して比較する。次に、送信無線フレーム（自機１）のベンダ特定ＩＥデータに含まれる第１ＩＤリストヘッダ情報と、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストヘッダ情報を抽出して比較する。次に、送信無線フレーム（自機１）のベンダ特定ＩＥデータに含まれる第２ＩＤリストヘッダ情報を抽出し、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストヘッダ情報を抽出して比較する。次に、送信無線フレーム（自機１）のベンダ特定ＩＥデータに含まれる第２ＩＤリストヘッダ情報と、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストヘッダ情報を抽出して比較する。

すなわち、簡易に説明すると、まず、送信無線フレーム（自機１）から最初のＩＤリストヘッダ情報を抽出して固定し、そして、受信無線フレーム（ゲーム装置）からＩＤリストヘッダ情報を順番に抽出して比較する。システムフラグ情報およびアルゴリズム識別情報が一致しない場合には、次に、送信無線フレーム（自機１）から次のＩＤリストヘッダ情報を抽出して固定し、そして、受信無線フレーム（ゲーム装置）からＩＤリストヘッダ情報を順番に抽出して比較する。当該処理を送信無線フレーム（自機１）に含まれているＩＤリストヘッダ情報の個数分繰り返すことになる。そして、送信無線フレーム（自機１）から最後のＩＤリストヘッダ情報を抽出して固定し、そして、受信無線フレーム（ゲーム装置）からＩＤリストヘッダ情報を順番に抽出して比較した場合に、システムフラグ情報およびアルゴリズム識別情報が一致しない場合には、ステップＳ８２において、比較対象ＩＤリストヘッダ情報が無いと判断（ステップＳ８２においてＮＯ）されて、アプリケーションＩＤ判定処理が終了する（リターン）。

当該方式により、アプリケーションＩＤを比較する前に受信無線フレーム保存領域６９に保存された受信無線フレームおよび送信無線フレーム保存領域６７に保存された送信無線フレームのベンダ特定ＩＥに含まれるＩＤリストヘッダ情報に基づいて比較処理を継続するべきか否かが判断されるため、高速な比較処理を実行することが可能となる。

図２５は、本発明の実施の形態に従う比較対象となるベンダ特定ＩＥの比較について説明する図である。

図２５を参照して、ここでは、図２０で説明したものと同様のデータ構成が示されている。

上側が自機１の送信無線フレーム保存領域６７に保存された送信無線フレームに含まれるベンダ特定ＩＥの構成であり、下側がゲーム装置３の受信無線フレーム保存領域６９に保存された受信無線フレームに含まれるベンダ特定ＩＥの構成である。

本例においては、自機１の第１ＩＤリストヘッダ情報ＤＤ５に含まれるシステムフラグ情報ＤＤ５−１と、ゲーム装置３の第１ＩＤリストヘッダ情報ＤＤｐ５に含まれるシステムフラグ情報ＤＤｐ５−１とを比較して一致し、さらに、アルゴリズム識別情報ＤＤ５−２とアルゴリズム識別情報ＤＤｐ５−２とを比較して一致した場合において、自機１の第１ＩＤリストＤＤ６に含まれるアプリケーションＩＤ［０］，ＩＤ［１］，・・・と、ゲーム装置３の第１ＩＤリストＤＤｐ６に含まれるアプリケーションＩＤ［０］，ＩＤ［１］，・・・との比較を行う場合が示されている。

図２６は、本発明の実施の形態に従う第１アルゴリズムに従うＩＤリスト比較処理について説明するフロー図である。

図２６を参照して、ＣＰＵ６０（ＩＤリスト比較部２３４）は、まず、比較対象となるＩＤリストからアプリケーションＩＤを抽出する（ステップＳ９０）。

例えば、図２５で示されるように、送信無線フレーム保存領域６７に保存された送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［０］と、受信無線フレーム保存領域６９に保存された受信無線フレーム（ゲーム装置３）の第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［０］とを抽出する。

なお、当該フローにおいては、後述するが、比較する長さおよびＩＤデータが一致するまで比較対象となるＩＤリストからアプリケーションＩＤをそれぞれ１つずつ抽出して、全ての組み合わせにおいて比較処理を実行する。

そして、次に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、比較する長さが一致するか否かを判断する（ステップＳ９２）。

ステップＳ９２において、ＣＰＵ６０（ＩＤリスト比較部２３４）は、比較する長さが一致すると判断された場合（ステップＳ９２においてＹＥＳ）には、ＩＤデータを比較する（ステップＳ９４）。

そして、ＣＰＵ６０（ＩＤリスト比較部２３４）は、ＩＤデータが一致するか否か判断する（ステップＳ９６）。

ステップＳ９６において、ＩＤデータが一致しないと判断された場合（ステップＳ９６においてＮＯ）には、ステップＳ１００に進む。

ステップＳ９６において、ＩＤデータが一致すると判断された場合（ステップＳ９６においてＹＥＳ）には、ＣＰＵ６０（ＩＤリスト比較部２３４）は、アプリケーションＩＤの一致フラグをオンに設定する（ステップＳ９８）。そして、処理を終了する（リターン）。

一方、ステップＳ９２において比較する長さが一致しないと判断された場合には、次に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、比較対象となるＩＤリストから他のアプリケーションＩＤが有るかどうかを判断する（ステップＳ１００）。ステップＳ１００において、比較対象となるＩＤリストから他のアプリケーションＩＤが有ると判断した場合には、比較対象となるＩＤリストから他のアプリケーションＩＤを抽出する（ステップＳ１０１）。そして、再び、ステップＳ９２に戻る。

例えば、図２５で示されるように、送信無線フレーム保存領域６７に保存された送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［１］を抽出して同様の処理を実行する。

一方、ステップＳ１００において、ＣＰＵ６０（ＩＤリスト比較部２３４）は、比較対象となるＩＤリストから他のアプリケーションＩＤがないと判断した場合には、「Ｉ」に進む。

すなわち、比較する長さおよびＩＤデータが一致するまで、受信無線フレーム保存領域６９に保存された受信無線フレームおよび送信無線フレーム保存領域６７に保存された送信無線フレームそれぞれの比較対象となるＩＤリストからアプリケーションＩＤをそれぞれ１つずつ抽出して、全ての組み合わせにおいて一致するものが無い場合には、図２４のステップＳ８２に進み、再度、上述した処理を繰り返す。

例えば、本例においては、一例として、比較対象となるＩＤリストとして、送信無線フレーム保存領域６７に保存された送信無線フレーム（自機１）の第１ＩＤリストＤＤ６と、受信無線フレーム保存領域６９に保存された受信無線フレーム（ゲーム装置３）の第１ＩＤリストＤＤｐ６とが抽出された場合について説明する。例えば、一例として、第１ＩＤリストＤＤ６および第１ＩＤリストＤＤｐ６は、ともに、アプリケーションＩＤを（ｎ＋１）個有しているものとする。

当該場合において、比較対象となるＩＤリストからアプリケーションＩＤをそれぞれ１つずつ抽出して全ての組み合わせについて比較する場合について説明すると、まず、送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［０］ＤＤ６−１を抽出し、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［０］ＤＤｐ６−１を抽出して比較する。次に、送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［０］ＤＤ６−１と、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［１］ＤＤｐ６−２を抽出して比較する。

次に、送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［０］ＤＤ６−１と、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［２］、アプリケーションＩＤ［３］、・・・アプリケーションＩＤ［ｎ］をそれぞれ順番に抽出して比較する。

次に、送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［１］ＤＤ６−２を抽出し、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［０］ＤＤｐ６−１を抽出して比較する。次に、送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［１］ＤＤ６−２と、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［１］ＤＤｐ６−２を抽出して比較する。

次に、送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［１］ＤＤ６−２と、受信無線フレーム（ゲーム装置）に含まれる第１ＩＤリストＤＤｐ６のアプリケーションＩＤ［２］、アプリケーションＩＤ［３］、・・・アプリケーションＩＤ［ｎ］をそれぞれ順番に抽出して比較する。この処理を送信無線フレーム（自機１）の第１ＩＤリストＤＤ６のアプリケーションＩＤ［２］、アプリケーションＩＤ［３］、・・・アプリケーションＩＤ［ｎ］まで同様に繰り返す。

すなわち、簡易に説明すると、比較対象となるＩＤリストにおいて、まず、送信無線フレーム（自機１）から最初のアプリケーションＩＤを抽出して固定し、そして、受信無線フレーム（ゲーム装置）からアプリケーションＩＤを順番に抽出して比較する。比較する長さおよびＩＤデータが一致しない場合には、次に、送信無線フレーム（自機１）から次のアプリケーションＩＤを抽出して固定し、そして、受信無線フレーム（ゲーム装置）からアプリケーションＩＤを順番に抽出して比較する。当該処理を送信無線フレーム（自機１）のＩＤリストに含まれているアプリケーションＩＤの個数分繰り返すことになる。そして、送信無線フレーム（自機１）から最後のアプリケーションＩＤを抽出して固定し、そして、受信無線フレーム（ゲーム装置）からアプリケーションＩＤを順番に抽出して比較した場合に、比較する長さおよびＩＤデータが一致しない場合には、ステップＳ１００において、比較対象となるＩＤリストから他のアプリケーションＩＤがないと判断（ステップＳ１００においてＮＯ）されて、「Ｉ」に進む。

ここで、上記で説明したＩＤデータの比較について説明する。
図２７は、本発明の実施の形態に従うＩＤデータの比較について説明する図である。

図２７を参照して、本例に示されるように自機１の送信無線フレーム保存領域６７に保存された送信無線フレームに含まれているアプリケーションＩＤのＩＤデータと、ゲーム装置３からの受信無線フレーム保存領域６９に保存された受信無線フレームに含まれているアプリケーションＩＤのＩＤデータとの比較において、同じ長さのＩＤデータを比較する。例えば、一例として、当該ＩＤデータは、アプリケーション名等のアプリケーションを特定する情報であるものとする。

具体的には、図２０で説明したアプリケーションＩＤに含まれている上述したＩＤデータの比較の長さを示す長さデータを用いて当該長さデータが一致するＩＤデータとのみデータ比較を実行する。

すなわち、長さデータが一致するＩＤデータすなわち、比較の長さが同じであるＩＤデータとのみ比較するため、比較の長さが異なるＩＤデータの比較を実行する必要が無く高速にアプリケーションＩＤの比較を実行することが可能である。

上記においては、同じ長さデータの自機１のＩＤデータとゲーム装置３のＩＤデータとが一致する場合にアプリケーションＩＤの一致フラグをオンする方式について説明したが、特にこれに限られず、さらに別の比較を実行することも可能である。

図２８は、本発明の実施の形態に従うＩＤデータのさらに別の比較について説明する図である。

図２８を参照して、この場合には、ＩＤデータに、アプリケーション名等のアプリケーションを特定する情報（アプリケーション名情報）だけでなく、他の情報が含まれている場合が示されている。

他の情報として、自機のＩＤデータの少なくとも一部を用いて自分が欲しいキャラクタ情報と、自分が相手に渡すキャラクタ情報とを格納する。

一方、他のゲーム装置側においても、同様に、アプリケーション名情報だけでなく、他の情報として、ＩＤデータの少なくとも一部を用いて自分が欲しいキャラクタ情報と、自分が相手に渡すキャラクタ情報とを格納する。

そして、アプリケーション名情報が一致するか否かを判断するとともに、さらに、自機のＩＤデータに含まれる自分が欲しいキャラクタ情報と、他のゲーム装置のＩＤデータに含まれる自分が相手に渡すキャラクタ情報とが一致するか否かを判断し、自機のＩＤデータに含まれる自分が相手に渡すキャラクタ情報と、他のゲーム装置のＩＤデータに含まれる自分が欲しいキャラクタ情報とが一致するか否かも判断する。アプリケーション名情報の一致のみならず、さらに、交換するキャラクタ情報が一致する場合にアプリケーションＩＤの一致と判断する。

当該比較方式により、ゲーム装置１である自機と他のゲーム装置３とで実際に交換データを交換する前に、互いに交換する交換データの内容（キャラクタ情報）に基づいて互いが希望する交換データであればアプリケーションＩＤの一致フラグをオンして本体側に通知し、いずれか一方でも希望しない場合にはアプリケーションＩＤの一致フラグはオンせず、本体側に通知されないためユーザが望む交換データのみを交換することが可能となる。

すなわち、ＩＤデータにアプリケーション名等のアプリケーションを特定する情報以外に他の情報（例えば交換データ）を含ませることにより、不本意なデータ授受処理を回避することができ、情報処理装置であるゲーム装置に対する興趣性を増すことができる。

なお、当該比較については、例えば、別のアルゴリズム識別情報を用いることにより図２６で説明した方式と区別するようにしても良い。

次に、ＩＤデータとは別に、付加的な条件として交換条件データを付加して高度な交換処理を実現する場合について説明する。

具体的には、交換条件データとして送受信条件データと取得条件データとを含む場合について説明する。

図２９は、本発明の実施の形態に従う第２アルゴリズムに従うＩＤリスト比較処理について説明するフロー図である。

本例においては、アルゴリズム識別情報が「１」である場合に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、第２アルゴリズムに従うＩＤリスト比較処理を実行する。

本例においては、一例として、送信無線フレーム保存領域６７に保存されている送信無線フレーム（自機１）のベンダ特定ＩＥデータに含まれる第２ＩＤリストヘッダ情報に含まれるアルゴリズム識別情報と、受信無線フレーム保存領域６９に保存されている受信無線フレーム（ゲーム装置３）のベンダ特定ＩＥデータに含まれる第２ＩＤリストヘッダ情報に含まれるアルゴリズム識別情報がともに「１」であるものとする。

この場合に、例えば一例として図２５で説明した送信無線フレーム保存領域６７に保存された送信無線フレームに含まれる第２ＩＤリストと、受信無線フレーム保存領域６９に保存された受信無線フレームに含まれる第２ＩＤリストとが比較対象となる。

図２９を参照して、ＣＰＵ６０（ＩＤリスト比較部２３４）は、まず、比較対象となるＩＤリストからアプリケーションＩＤ＃を抽出する（ステップＳ１１０）。

例えば、図２０および図２５で示されるように、送信無線フレーム保存領域６７に保存された送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［０］と、受信無線フレーム保存領域６９に保存された受信無線フレーム（ゲーム装置３）の第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［０］とを抽出する。

なお、当該フローにおいては、後述するが、ＩＤデータや取得条件データ等の判定条件を満たすまで比較対象となるＩＤリストからアプリケーションＩＤをそれぞれ１つずつ抽出して、全ての組み合わせにおいて比較処理を実行する。

そして、次に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、抽出されたアプリケーションＩＤ＃に含まれるＩＤデータを比較する（ステップＳ１１２）。

具体的には、第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［０］のＩＤデータと、第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［０］のＩＤデータとを比較する。

そして、次に、ステップＳ１１２において、ＣＰＵ６０（ＩＤリスト比較部２３４）は、ＩＤデータが一致するか否か判断する（ステップＳ１１４）。

ステップＳ１１４において、ＩＤデータが一致すると判断された場合（ステップＳ１１４においてＹＥＳ）には、ＣＰＵ６０（ＩＤリスト比較部２３４）は、フィルタサイズデータを比較する（ステップＳ１１６）。

そして、次に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、フィルタサイズが一致するかどうか判断する（ステップＳ１１８）。具体的には、第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［０］のフィルタサイズデータと、第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［０］のフィルタサイズデータとを比較する。フィルタサイズデータは、上述したようにマスクデータ、コンディションデータ、リクエストデータの各々のデータのサイズを規定するデータである。

フィルタサイズデータが異なる場合には、比較対象とするデータサイズが異なるため以降の後述するデータ比較処理を実行するまでもなく条件は不一致と判断することが可能である。

そして、次に、ステップＳ１１８において、ＣＰＵ６０（ＩＤリスト比較部２３４）は、フィルタサイズが一致すると判断した場合（ステップＳ１１８においてＹＥＳ）には、次に互いの送受信条件データが満たされるかどうかを判断する。具体的には、送受信条件データであるセンドフラグデータおよびレシーブフラグデータを比較する（ステップＳ１２０）。センドフラグデータおよびレシーブフラグデータの比較については後述する。

そして、ＣＰＵ６０（ＩＤリスト比較部２３４）は、比較の結果、互いの送受信条件データが満たされるすなわちフラグデータがＯＫ判定であるかどうかを判断する（ステップＳ１２２）。

図３０は、本発明の実施の形態に従う送受信条件データであるセンドフラグデータおよびレシーブフラグデータの比較について説明する図である。

図３０（Ａ）を用いて、自機１における送受信条件データであるセンドフラグデータおよびレシーブフラグデータの形式について説明する。

具体的には、センドフラグとレシーブフラグとの組み合わせに従って、交換データの送受信条件データを設定することが可能である。

具体的には、センドフラグが「１」、レシーブフラグが「０」である場合には、交換データの自機１からの送信通信のみ可能であることを示す。

また、センドフラグが「０」、レシーブフラグが「１」である場合には、交換データの他のゲーム装置からの受信通信のみ可能であることを示す。

また、センドフラグおよびレシーブフラグが「１」、「１」の場合には、いずれの条件であっても交換データの通信が可能であることを示す。すなわち、この場合には、通信相手の送受信条件データに従う通信となる。

また、センドフラグおよびレシーブフラグが「０」、「０」の場合には、交換データの自機１および他のゲーム装置との間での双方向の通信のみ可能であることを示す。

当該送受信条件データに対して、送受信条件データが満たされるすなわちフラグデータがＯＫ判定（以下、単にフラグＯＫ判定とも称する）となる場合について説明する。

自機１のセンドフラグが「１」、レシーブフラグが「０」の場合は、通信相手のセンドフラグが「０」、レシーブフラグが「１」あるいはセンドフラグが「１」、レシーブフラグが「１」の場合にフラグＯＫ判定となる。

自機１のセンドフラグが「０」、レシーブフラグが「１」の場合は、通信相手のセンドフラグが「１」、レシーブフラグが「０」あるいはセンドフラグが「１」、レシーブフラグが「１」の場合にフラグＯＫ判定となる。

自機１のセンドフラグが「１」、レシーブフラグが「１」の場合は、通信相手のセンドフラグが「０」、レシーブフラグが「０」、あるいはセンドフラグが「０」、レシーブフラグが「１」、あるいはセンドフラグが「１」、レシーブフラグが「０」、あるいはセンドフラグが「１」、レシーブフラグが「１」の場合にフラグＯＫ判定となる。

自機１のセンドフラグが「０」、レシーブフラグが「０」の場合は、通信相手のセンドフラグが「０」、レシーブフラグが「０」の場合、あるいは、センドフラグが「１」、レシーブフラグが「１」の場合にフラグＯＫ判定となる。

図３０（Ｂ）を用いて、送受信条件データに関するフラグデータ比較における具体例について説明する。

例１の場合は、自機１のセンドフラグが「０」、レシーブフラグが「１」でゲーム装置３のセンドフラグが「１」、レシーブフラグが「０」の場合における比較が示されている。したがって、自機１の送受信条件データは、受信通信のみ可であり、ゲーム装置３の送受信条件データは送信通信のみ可であるため受信フラグＯＫ判定すなわち通信可となる。

例２の場合は、自機１のセンドフラグが「１」、レシーブフラグが「０」でゲーム装置３のセンドフラグが「０」、レシーブフラグが「１」の場合における比較が示されている。したがって、自機１の送受信条件データは、送信通信のみ可であり、ゲーム装置３の送受信条件データは受信通信のみ可であるためフラグＯＫ判定すなわち通信可となる。

例３の場合は、自機１のセンドフラグが「１」、レシーブフラグが「１」でゲーム装置３のセンドフラグが「１」、レシーブフラグが「０」の場合における比較が示されている。したがって、自機１の送受信条件データは、いずれの条件でも通信可であり、ゲーム装置３の送受信条件データは送信通信のみ可であるためフラグＯＫ判定すなわち通信可となる。

例４の場合は、自機１のセンドフラグが「１」、レシーブフラグが「０」でゲーム装置３のセンドフラグが「１」、レシーブフラグが「０」の場合における比較が示されている。したがって、自機１の送受信条件データは、送信通信のみ可であり、ゲーム装置３の送受信条件データは送信通信のみ可であるためフラグＮＧ判定すなわち通信不可となる。

例５の場合は、自機１のセンドフラグが「０」、レシーブフラグが「０」でゲーム装置３のセンドフラグが「１」、レシーブフラグが「０」の場合における比較が示されている。したがって、自機１の送受信条件データは、双方向通信のみ可であり、ゲーム装置３の送受信条件データは送信通信のみ可であるためフラグＮＧ判定すなわち通信不可となる。

当該方式により、ＩＤデータに交換条件データとして送受信条件データ（センドフラグデータおよびレシーブフラグデータ）を含ませて比較することにより、交換データの送信だけをしたい場合、あるいは、交換データの受信だけをしたい場合、あるいは、通信相手との間で交換データの送受信のみしたい場合、あるいは、通信相手の送受信条件データに合わせて通信した場合等、データ交換する際の通信形式のバリエーションを増すことが可能であり、データ交換の興趣性を増大させることができる。

再び、図２９を参照して、次に、ステップＳ１２２において、フラグＯＫ判定である場合（ステップＳ１２２においてＹＥＳ）には、ＣＰＵ６０（ＩＤリスト比較部２３４）は、互いの取得条件が満たされるかどうかを判断する。具体的には、取得条件が満たされるか否かの判断として条件データを比較する（ステップＳ１２４）。条件データの比較については後述する。

そして、次に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、自己の取得条件を満たしているかどうかを判断する（ステップＳ１２６）。

そして、自己の取得条件を満たしていると判断した場合（ステップＳ１２６においてＹＥＳ）には、次に相手の取得条件を満たしているかどうかを判断する（ステップＳ１２８）。

次に、ＣＰＵ６０（ＩＤリスト比較部２３４）は、相手の取得条件を満たしていると判断した場合（ステップＳ１２８においてＹＥＳ）には、アプリケーションＩＤの一致フラグをオンする（ステップＳ１３０）。そして、処理を終了する（リターン）。

図３１は、本発明の実施の形態に従う取得条件を満たしているか否かに関する条件データの比較について説明する図である。

図３１（Ａ）は、自己の条件データの比較について説明する図である。
条件データは、自機１の取得条件データ（マスクデータ、コンディションデータ、リクエストデータ）と、ゲーム装置３の取得条件データ（マスクデータ、コンディションデータ、リクエストデータ）とにより生成される。

具体的には、条件データの比較として、自機１のマスクデータとゲーム装置３のコンディションデータとの積と、自機１のマスクデータと自機１のリクエストデータとの積とが同じ値であるかどうかを判断する。

図３１（Ｂ）は、相手の取得条件を満たしているかに関する条件データの比較について説明する図である。

具体的には、条件データの比較として、ゲーム装置３のマスクデータと自機１のコンディションデータとの積と、ゲーム装置３のマスクデータとゲーム装置３のリクエストデータとの積とが同じ値であるかどうかを判断する。

図３２は、本発明の実施の形態に従う取得条件データの具体例について説明する図である。

図３２を参照して、ここでは、４つの取得条件データの例が示されている。
具体的には、ユーザであるＨＡ、ＨＢ、ＨＣ、ＨＤさんのそれぞれが設定した取得条件データが示されている。

マスクデータ、コンディションデータ、リクエストデータは、それぞれ１ビットであるものとする。

本例においては、一例として、例えば、上記の交換データ登録イベントにおける、交換データの格納に際し、ＨＡ、ＨＢ、ＨＣ、ＨＤさんがそれぞれデータ交換を希望する際の条件として性別を取得条件データとして設定した場合の例について説明する。

具体的には、相手に送信する自己の交換データおよび相手から受信する交換データに関連付けられた属性データとして、性別を示すデータ（男：「１」、女：「０」）を用いた場合について説明する。

図３２（Ａ）は、ＨＡさんの取得条件データが示されており、マスクデータが「１」、コンディションデータが「１」、リクエストデータが「０」である場合が示されている。当該場合は、ＨＡさんは、コンディションデータが「１」であるため性別は男であることを示すとともに、リクエストデータが「０」であるため性別が女とデータ交換を希望する場合である。なお、マスクデータが「０」の場合には、リクエストデータを無効に設定することができる。すなわち、データ交換を希望する性別をいずれでも良いものに設定することができる。

図３２（Ｂ）は、ＨＢさんの取得条件データが示されており、マスクデータが「１」、コンディションデータが「０」、リクエストデータが「１」である場合が示されている。当該場合は、ＨＢさんは、コンディションデータが「０」であるため性別は女であることを示すとともに、リクエストデータが「０」であるため性別が男とデータ交換を希望する場合である。

図３２（Ｃ）は、ＨＣさんの取得条件データが示されており、マスクデータが「０」、コンディションデータが「１」、リクエストデータが「０」である場合が示されている。当該場合は、ＨＢさんは、コンディションデータが「１」であるため性別は男である。ここで、マスクデータが「０」であるためデータ交換の相手は性別を問わないため、リクエストデータは「０」あるいは「１」いずれでも良い、すなわちドントケアであるが、ここでは説明を簡易にするため「０」としている。

図３２（Ｄ）は、ＨＤさんの取得条件データが示されており、マスクデータが「０」、コンディションデータが「０」、リクエストデータが「０」である場合が示されている。当該場合は、ＨＢさんは、コンディションデータが「０」であるため性別は女である。ここで、マスクデータが「０」であるためデータ交換の相手は性別を問わないため、リクエストデータは「０」あるいは「１」いずれでも良いすなわち、ドントケアであるが、ここでは説明を簡易にするため「０」としている。

図３３は、図３２で説明した取得条件データに基づく条件データの比較の具体例について説明する図である。

本例においては、ＨＡさんと、他の人、すなわち、ＨＢさん、ＨＣさん、ＨＤさんとの条件データの比較について説明する。

図３３（Ａ）を参照して、ここでは、ＨＡさんと、ＨＢさんとの条件データの比較が示されている。

ＨＡさん側の処理について説明する。
相手のコンディションデータと自分のマスクデータとの積は、「０」＆「１」＝「０」となる。

また、自分のリクエストデータと自分のマスクデータとの積は、「０」＆「１」＝「０」となる。

したがって、この場合、自己の条件データは一致し、自己の取得条件は満たしていると判断される。

また、自分のコンディションデータと相手のマスクデータとの積は、「１」＆「１」＝「１」となる。

相手のリクエストデータと相手のマスクデータとの積は、「１」＆「１」＝「１」となる。

したがって、この場合、相手の条件データは一致し、相手の取得条件は満たしていると判断される。

すなわち、ＨＡさん側の取得条件のデータ比較において、自己の取得条件および相手の取得条件はともに満たしていると判断される。

上記においては、ＨＡさん側の処理について説明したが、ＨＢさん側の処理としても同様に実行される。

相手のコンディションデータと自分のマスクデータとの積は、「１」＆「１」＝「１」となる。

また、自分のリクエストデータと自分のマスクデータとの積は、「１」＆「１」＝「１」となる。

また、自分のコンディションデータと相手のマスクデータとの積は、「０」＆「１」＝「０」となる。

相手のリクエストデータと相手のマスクデータとの積は、「０」＆「１」＝「０」となる。

すなわち、ＨＢさん側の取得条件のデータ比較において、自己の取得条件および相手の取得条件はともに満たしていると判断される。

したがって、性別が男であるＨＡさんは、データ交換を希望する性別が女であるＨＢさんとデータ交換の条件が一致するためデータ交換することが可能である。

図３３（Ｂ）を参照して、ここでは、ＨＡさんと、ＨＣさんとの条件データの比較が示されている。

ＨＡさん側の処理について説明する。
相手のコンディションデータと自分のマスクデータとの積は、「１」＆「１」＝「１」となる。

したがって、この場合、自己の条件データは不一致であり、自己の取得条件は満たしていないと判断される。

また、自分のコンディションデータと相手のマスクデータとの積は、「１」＆「０」＝「０」となる。

相手のリクエストデータと相手のマスクデータとの積は、「０」＆「０」＝「０」となる。

したがって、この場合、相手の条件データは一致であり、相手の取得条件は満たしていると判断される。

すなわち、ＨＡさん側の取得条件のデータ比較において、相手の条件データは一致しているため取得条件は満たしているが、自己の条件データは不一致であり、自己の取得条件は満たしていないと判断される。

上記においては、ＨＡさん側の処理について説明したが、ＨＣさん側の処理としても同様に実行される。

相手のコンディションデータと自分のマスクデータとの積は、「１」＆「０」＝「０」となる。

また、自分のリクエストデータと自分のマスクデータとの積は、「０」＆「０」＝「０」となる。

したがって、この場合、自己の条件データは一致しており、自己の取得条件は満たしていると判断される。

したがって、この場合、相手の条件データは不一致であり、相手の取得条件は満たしていないと判断される。

すなわち、ＨＣさん側の取得条件のデータ比較において、自己の条件データは一致しており自己の取得条件は満たしているが、相手の条件データは不一致であるため相手の取得条件は満たしていないと判断される。

したがって、性別が男であるＨＣさんは、データ交換の性別を問わないため性別が男であるＨＡさんとデータ交換が可能であるが、性別が男であるＨＡさんは、性別が男であるＨＣさんとデータ交換を希望しないため、データ交換することはできない。

図３３（Ｃ）を参照して、ここでは、ＨＡさんと、ＨＤさんとの条件データの比較が示されている。

したがって、この場合、相手の条件データは一致しており、相手の取得条件は満たしていると判断される。

上記においては、ＨＡさん側の処理について説明したが、ＨＤさん側の処理としても同様に実行される。

したがって、性別が女であるＨＤさんは、データ交換の性別を問わないため性別が男であるＨＡさんとデータ交換が可能であり、また、性別が男であるＨＡさんは、性別が女であるＨＤさんとデータ交換を希望するため、データ交換が可能となる。

上記においては、性別を取得条件データとして比較する場合について説明したが、特にこれに限られず、別のデータを取得条件データとして設定することも可能である。

図３４は、本発明の実施の形態に従う取得条件データの別の具体例について説明する図である。

図３４を参照して、ここでは、３つの取得条件データの例が示されている。
具体的には、ユーザであるＨＥ、ＨＦ、ＨＧさんのそれぞれが設定した取得条件データが示されている。

マスクデータ、コンディションデータ、リクエストデータは、それぞれ２ビットであるものとする。

本例においては、一例として、例えば、上記の交換データ登録イベントにおける、交換データの格納に際し、ＨＥ、ＨＦ、ＨＧさんがそれぞれデータ交換を希望するゲームのコースデータを取得条件データとして設定した場合の例について説明する。

具体的には、相手に送信する自己の交換データおよび相手から受信する交換データに関連付けられた属性データとして、データの有無（有り：「１」、無し：「０」）および希望の有無（有り：「１」、無し「０」）を用いた場合について説明する。

一例として、コンディションデータとして２ビットが設けられ、それぞれコースＰおよびコースＱに対応している。例えば、コンディションデータについて、対応するコースのデータを有している場合「１」、対応するコースのデータを有していない場合「０」とする。

また、リクエストデータとして２ビットが設けられ、それぞれコースＰおよびコースＱに対応している。例えば、リクエストデータは、対応するコースのデータの取得を希望する場合「１」、対応するコースのデータの取得を希望しない場合「０」とする。

また、マスクデータとして２ビットが設けられ、それぞれコースＰおよびコースＱに対応している。なお、マスクデータが「０」の場合には、リクエストデータを無効に設定することができる。すなわち、データ交換を取得しても良いし、取得しなくても良いものに設定することができる。

図３４（Ａ）を参照して、ＨＥさんの取得条件データが示されており、コースＰ，Ｑに対応してマスクデータが「０１」、コンディションデータが「１１」、リクエストデータが「０１」である場合が示されている。

当該場合は、ＨＥさんは、コンディションデータが「１１」であるためコースＰ，Ｑをそれぞれ有している。リクエストデータは「０１」であるためコースＱについてデータ交換を希望する場合である。なお、マスクデータがコースＰに関して「０」であるため、リクエストデータについてコースＰについては「０」あるいは「１」いずれでも良いすなわち、ドントケアであるが、ここでは説明を簡易にするため「０」としている。

図３４（Ｂ）を参照して、ＨＦさんの取得条件データが示されており、コースＰ，Ｑに対応してマスクデータが「１１」、コンディションデータが「１０」、リクエストデータが「０１」である場合が示されている。

当該場合は、ＨＦさんは、コンディションデータが「１０」であるためコースＰを有している。リクエストデータは「０１」であるためコースＱについてデータ交換を希望する場合である。

図３４（Ｃ）を参照して、ＨＧさんの取得条件データが示されており、コースＰ，Ｑに対応してマスクデータが「１１」、コンディションデータが「０１」、リクエストデータが「１１」である場合が示されている。

当該場合は、ＨＧさんは、コンディションデータが「０１」であるためコースＱを有している。リクエストデータは「１１」であるためコースＰ，Ｑについてデータ交換を希望する場合である。

図３５は、図３４で説明した取得条件データに基づく条件データの比較の具体例について説明する図である。

本例においては、ＨＥさんと、他の人、すなわち、ＨＦさん、ＨＧさんとの条件データの比較について説明する。

図３５（Ａ）を参照して、ここでは、ＨＥさんと、ＨＦさんとの条件データの比較が示されている。

ＨＥさん側の処理について説明する。
相手のコンディションデータと自分のマスクデータとの積は、「１０」＆「０１」＝「００」となる。

また、自分のリクエストデータと自分のマスクデータとの積は、「０１」＆「１１」＝「０１」となる。

また、自分のコンディションデータと相手のマスクデータとの積は、「１１」＆「１１」＝「１１」となる。

相手のリクエストデータと相手のマスクデータとの積は、「０１」＆「１１」＝「０１」となる。

すなわち、ＨＥさん側の取得条件のデータ比較において、自己の取得条件および相手の取得条件はともに満たしていないと判断される。

上記においては、ＨＥさん側の処理について説明したが、ＨＦさん側の処理としても同様に実行される。

相手のコンディションデータと自分のマスクデータとの積は、「１１」＆「１１」＝「１１」となる。

また、自分のコンディションデータと相手のマスクデータとの積は、「１０」＆「０１」＝「００」となる。

相手のリクエストデータと相手のマスクデータとの積は、「０１」＆「０１」＝「０１」となる。

すなわち、ＨＦさん側の取得条件のデータ比較においても、自己の取得条件および相手の取得条件はともに満たしていないと判断される。

したがって、コースＱのデータ交換を希望するＨＥさんと、コースＱのデータを有していないＨＦさんとは、データ交換の取得条件データを満たさないためデータ交換することはできない。

図３５（Ｂ）を参照して、ここでは、ＨＥさんと、ＨＧさんとの条件データの比較が示されている。

ＨＥさん側の処理について説明する。
相手のコンディションデータと自分のマスクデータとの積は、「０１」＆「０１」＝「０１」となる。

また、自分のリクエストデータと自分のマスクデータとの積は、「０１」＆「０１」＝「０１」となる。

相手のリクエストデータと相手のマスクデータとの積は、「１１」＆「１１」＝「１１」となる。

すなわち、ＨＥさん側の取得条件のデータ比較において、自己の取得条件および相手の取得条件はともに満たしていると判断される。

上記においては、ＨＥさん側の処理について説明したが、ＨＧさん側の処理としても同様に実行される。

また、自分のリクエストデータと自分のマスクデータとの積は、「１１」＆「１１」＝「１１」となる。

すなわち、ＨＧさん側の取得条件のデータ比較においても、自己の取得条件データおよび相手の取得条件データはともに満たしていると判断される。

したがって、コースＱのデータ交換を希望するＨＥさんと、コースＱのデータを有しているＨＧさんとは、データ交換の取得条件データが満たされ、また、コースＰのデータ交換を希望するＨＧさんと、コースＰのデータを有しているＨＥさんとは、データ交換の取得条件データが満たされるためデータ交換が可能である。

再び、図２９を参照して、ステップＳ１１４において、ＩＤデータが一致しないと判断された場合（ステップＳ１１４においてＮＯ）には、比較対象となるＩＤリストにアプリケーションＩＤ＃が他に有るかどうかを判断する（ステップＳ１３２）。

また、ステップＳ１１８において、フィルタサイズが一致しない場合（ステップＳ１１８においてＮＯ）には、ステップＳ１３２に進む。

また、ステップＳ１２２において、フラグＯＫ判定で無い場合（ステップＳ１２２においてＮＯ）には、ステップＳ１３２に進む。

また、ステップＳ１２６において、自己の取得条件を満たしていない場合（ステップＳ１２６においてＮＯ）には、ステップＳ１３２に進む。

また、ステップＳ１２８において、相手の取得条件を満たしていない場合（ステップＳ１２８においてＮＯ）には、ステップＳ１３２に進む。

ステップＳ１３２において、比較対象となるＩＤリストにアプリケーションＩＤ＃が他に有る場合（ステップＳ１３２においてＹＥＳ）には、比較対象となるＩＤリストから次のアプリケーションＩＤ＃を抽出する（ステップＳ１３４）。そして、ステップＳ１１２に進み同様の処理を繰り返す。

例えば、図２０で示されるように、第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［１］を抽出して同様の処理を実行する。

一方、ステップＳ１３２において、比較対象となるＩＤリストにアプリケーションＩＤ＃が他に無い場合（ステップＳ１３２においてＮＯ）には、「Ｉ」に進む。

すなわち、ＩＤデータや取得条件データ等の判定条件を満たすまで、受信無線フレーム保存領域６９に保存された受信無線フレームおよび送信無線フレーム保存領域６７に保存された送信無線フレームそれぞれの比較対象となるＩＤリストからアプリケーションＩＤ＃をそれぞれ１つずつ抽出して、全ての組み合わせにおいて条件を満たすものが無い場合には、図２４のステップＳ８２に進み、再度、上述した処理を繰り返す。

例えば、本例においては、一例として、比較対象となるＩＤリストとして、送信無線フレーム保存領域６７に保存された送信無線フレーム（自機１）の第２ＩＤリストＤＤ８と、受信無線フレーム保存領域６９に保存された受信無線フレーム（ゲーム装置３）の第２ＩＤリストＤＤｐ８とが抽出された場合について説明する。例えば、一例として、第２ＩＤリストＤＤ８および第２ＩＤリストＤＤｐ８は、ともに、アプリケーションＩＤ＃を（ｎ＋１）個有しているものとする。

当該場合において、比較対象となるＩＤリストからアプリケーションＩＤ＃をそれぞれ１つずつ抽出して全ての組み合わせについて比較する場合について説明すると、まず、送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［０］ＤＤ８−１を抽出し、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［０］ＤＤｐ８−１を抽出して比較する。次に、送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［０］ＤＤ８−１と、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［１］ＤＤｐ８−２を抽出して比較する。

次に、送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［０］ＤＤ８−１と、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［２］、アプリケーションＩＤ＃［３］、・・・アプリケーションＩＤ＃［ｎ］をそれぞれ順番に抽出して比較する。

次に、送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［１］ＤＤ８−２を抽出し、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［０］ＤＤｐ８−１を抽出して比較する。次に、送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［１］ＤＤ８−２と、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［１］ＤＤｐ８−２を抽出して比較する。

次に、送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［１］ＤＤ８−２と、受信無線フレーム（ゲーム装置）に含まれる第２ＩＤリストＤＤｐ８のアプリケーションＩＤ＃［２］、アプリケーションＩＤ＃［３］、・・・アプリケーションＩＤ＃［ｎ］をそれぞれ順番に抽出して比較する。この処理を送信無線フレーム（自機１）の第２ＩＤリストＤＤ８のアプリケーションＩＤ＃［２］、アプリケーションＩＤ＃［３］、・・・アプリケーションＩＤ＃［ｎ］まで同様に繰り返す。

すなわち、簡易に説明すると、比較対象となるＩＤリストにおいて、まず、送信無線フレーム（自機１）から最初のアプリケーションＩＤ＃を抽出して固定し、そして、受信無線フレーム（ゲーム装置）からアプリケーションＩＤ＃を順番に抽出して比較する。ＩＤデータや取得条件データ等の判定条件を満たさない場合には、次に、送信無線フレーム（自機１）から次のアプリケーションＩＤ＃を抽出して固定し、そして、受信無線フレーム（ゲーム装置）からアプリケーションＩＤ＃を順番に抽出して比較する。当該処理を送信無線フレーム（自機１）のＩＤリストに含まれているアプリケーションＩＤ＃の個数分繰り返すことになる。そして、送信無線フレーム（自機１）から最後のアプリケーションＩＤ＃を抽出して固定し、そして、受信無線フレーム（ゲーム装置）からアプリケーションＩＤ＃を順番に抽出して比較した場合に、ＩＤデータや取得条件データ等の判定条件を満たさない場合には、ステップＳ１３２において、比較対象となるＩＤリストから他のアプリケーションＩＤ＃がないと判断（ステップＳ１３２においてＮＯ）されて、「Ｉ」に進む。

なお、上記図２９のフローにおいては、フラグデータ比較（ステップＳ１２０）と、条件データ比較（ステップＳ１２４）をそれぞれ関連付けずに実行する方式について説明したが、例えば、図３０で説明したように自機１の送受信条件データが送信通信のみを指定するような場合には、相手から交換データを受信することを希望しないため自己の取得条件を満たしているかの判断は不要である。また、逆に、自機１の送受信条件データが受信通信のみを指定するような場合には、相手に交換データを送信することを希望しないため相手の取得条件を満たしているかの判断は不要である。したがって、ステップＳ１２０のフラグデータの比較結果に基づいて、ステップＳ１２４〜ステップＳ１２８までの条件データ比較および判断の処理を変更するようにしても良い。

また、本例においては、アルゴリズム識別情報が「０」，「１」の場合にそれぞれ第１および第２アルゴリズムに従うＩＤリスト比較処理について説明したが、これに限られず、他のアルゴリズム識別情報（たとえば「２」）を設けてさらに別のアルゴリズムに従うＩＤリスト比較処理を実行するようにしても良い。

また、本例においては、取得条件データについて、マスクデータを含めた形式について説明したが、コンディションデータおよびリクエストデータの形式とすることも可能である。その場合には、条件データの比較として、自分のコンディションデータと相手のリクエストデータとの比較および自分のリクエストデータと相手のコンディションデータとの比較を実行して自己の取得条件および相手の取得条件を満たしているかを判断するようにしても良い。

図３６は、本発明の実施の形態に従うアプリケーションＩＤを比較する場合の概念図である。

図３６を参照して、ここでは、図２２で説明したゲーム装置１およびゲーム装置３と同様の状況が示されており、無線通信モジュール３８のＲＡＭ６６のフィルタリング用データ保存領域６８には、アプリケーションＩＤとして「Ａ，Ｂ，Ｃ，Ｄ」がそれぞれ格納されている場合が示されている。そして、ゲーム装置３側の無線通信モジュール３８Ｐのフィルタリング用データ保存領域６８ＰにアプリケーションＩＤとして「Ｂ，Ｅ」がそれぞれ格納されている場合が示されている。

そして、上述したように、フィルタリング用データ保存領域６８に格納されているデータに基づいて送信用の送信無線フレームが設定され、受信用の受信無線フレームに含まれているアプリケーションＩＤと比較して、一致フラグがオンするかどうかが判断される。

本例においては、アプリケーションＩＤ「Ｂ」に関して、一致フラグがオンする場合が示されている。

図３７〜図３９は、本発明の実施の形態に従うゲーム装置間における交換データの交換処理について説明する図である。

本例においては、ゲーム装置１と、通信相手である他のゲーム装置としてゲーム装置３との間で交換データの授受処理を実行する場合について説明する。

上記したように、ＣＰＵ３１（データ通信実行処理部２０８）は、無線通信モジュール３８から一致したアプリケーションＩＤに対応する交換データを有する他のゲーム装置が発見された旨の通知を受けた場合には、データ授受処理を実行する。

図３７を参照して、まず、一致したアプリケーションＩＤに対応する交換データが格納された送信ＢＯＸ（交換データ保存領域８０）からデータを読み出してデータを送信スロットにコピーする。例えば、メインメモリ３２に設けられた送信スロットにコピーデータを作成する。そして、当該送信スロットに格納されたコピーデータが無線通信モジュール３８を介してゲーム装置３に送信される。

ゲーム装置３においても、ゲーム装置１と同様に無線通信モジュール３８Ｐから一致したアプリケーションＩＤに対応する交換データを有するゲーム装置が発見された旨の通知が本体側に出力される。

そして、本体側において、一致したアプリケーションＩＤに対応する交換データが格納された送信ＢＯＸ（交換データ保存領域８０）からデータが読み出されてデータを送信スロットにコピーする。そして、当該送信スロットに格納されたコピーデータが無線通信モジュール３８Ｐを介してゲーム装置１に送信される。

図３８を参照して、ゲーム装置１は、無線通信モジュール３８を介してゲーム装置３から送信された交換データを取得する。そして、ゲーム装置１の交換データを送信し、ゲーム装置３の交換データを受信する交換条件が成立した場合には、アプリケーションＩＤに対応付けられて設けられた受信ＢＯＸＲＢＢ（受信データ保存領域８２）に格納する。

同様に、ゲーム装置３は、無線通信モジュール３８Ｐを介してゲーム装置１から送信された交換データを取得する。そして、ゲーム装置３の交換データを送信し、ゲーム装置１の交換データを受信する交換条件が成立した場合には、アプリケーションＩＤに対応付けられて設けられた受信ＢＯＸＲＢＢ（受信データ保存領域８２Ｐ）に格納する。

そして、図３９を参照して、本例においては、一例として、ゲーム装置１について交換データ保存領域８０の送信ＢＯＸに格納されていたデータを消去する。本例においては、交換データ保存領域８０の送信ＢＯＸＳＢＢに対応する領域のデータを消去する。

同様に、本例においては、一例として、ゲーム装置３について交換データ保存領域８０Ｐの送信ＢＯＸに格納されていたデータを消去する。本例においては、交換データ保存領域８０Ｐの送信ＢＯＸＳＢＢに対応する領域のデータを消去する。

当該処理により、通信相手に送信した交換データを消去することにより交換データの交換処理が完了する。

なお、後述するが交換データの消去は、送信ＢＯＸに格納されていた交換データを利用するアプリケーションを起動することにより当該アプリケーションの実行によって交換データ保存領域の送信ＢＯＸの送信ＢＯＸスロットのデータが消去されるものとする。

なお、本例においては、交換データを消去する場合について説明するが、消去せずにそのまま維持するようにすることも可能である。その場合には、交換データの交換処理ではなく複製データの授受となる。

また、本例においては、一例として、一致したアプリケーションＩＤに対応する１つの交換データについて、交換処理を行う場合について説明しているが、特に１つの交換データに限られず、一致したアプリケーションＩＤに対応する交換データが複数個有る場合においてもそれぞれの交換データについて同様の処理が実行される。

図４０は、本発明の実施の形態に従うデータ授受処理のフロー図である。
当該データ授受処理は、一例として、上述したシステムプログラム保存領域８６に格納されている本体機能プログラムをＣＰＵ３１が実行することにより実現されるものである。当該データ授受処理は、例えば、本体の起動時に開始して、バックグラウンドで継続的に実行される。

図４０を参照して、まず、ＣＰＵ３１（スリープ設定／解除処理部２１６）は、無線通信モジュール３８からの通知が有るかどうかを判断する（ステップＳ１４０）。

ステップＳ１４０において、ＣＰＵ３１（スリープ設定／解除処理部２１６）は、無線通信モジュール３８からの通知があったと判断した場合（ステップＳ１４０においてＹＥＳ）には、本体側の機能がスリープ状態であるかどうかを判断する（ステップＳ１４１）。

そして、ＣＰＵ３１（スリープ設定／解除処理部２１６）は、本体側の機能がスリープ状態であると判断した場合（ステップＳ１４１においてＹＥＳ）には、スリープ状態を解除する（ステップＳ１４２）。

そして、次に、ＣＰＵ３１（データ通信実行処理部２０８）は、データ授受処理を開始する（ステップＳ１４３）。一方、本体側の機能がスリープ状態で無いと判断した場合（ステップＳ１４１においてＮＯ）には、ステップＳ１４３に進む。以降、データ通信実行処理部２０８の各機能を用いて説明する。

まず、ＣＰＵ３１（通信接続確立処理部３０２）は、無線通信モジュール３８からの交換データを有するゲーム装置が発見された旨の通知に含まれている通信相手のＭＡＣアドレス等の接続情報に基づいて通信相手との間で通信接続を確立する（ステップＳ１４４）。

なお、本例においては、ゲーム装置が発見された旨の通知後、通信相手との接続を確立する場合、すなわち、ＣＰＵ３１（通信接続確立処理部３０２）が実行する場合について説明するが、ゲーム装置が発見された旨の通知前、例えば、無線通信モジュール３８において図１８のステップＳ６４とステップＳ６６との間で通信相手との接続を確立する処理を実行するようにしても良い。

そして、次に、ＣＰＵ３１（フレンド認証処理部３０４）は、通信相手がフレンドであるか否かを判定するフレンド認証処理を実行する（ステップＳ１４５）。フレンド認証処理の詳細については後述する。

次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、通信相手に交換データを送信するための送信スロットを作成する送信スロット作成処理を実行する（ステップＳ１４６）。送信スロット作成処理の詳細については後述する。

次に、ＣＰＵ３１（送信データリスト作成処理部３０８）は、作成した送信スロットに基づいて送信データリストを作成する送信データリスト作成処理を実行する（ステップＳ１４７）。送信データリスト作成処理の詳細については後述する。

次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、作成した送信データリストを通信相手に送信して、通信相手に対して交換データの送信が可能であるかどうかを判断するとともに、通信相手が作成した送信データリストを受信して、通信相手からの交換データの受信が可能であるかどうかを判断する処理（送受信データリスト分析処理）を実行する（ステップＳ１４８）。送受信データリスト分析処理の詳細については後述する。

次に、ＣＰＵ３１（送受信実行処理部３１２）は、送受信データリスト分析処理の結果に基づいて、送信データリストの中から送信が可能な交換データを実際に送信し、また、通信相手の送信データリスト（受信データリストとも称する）の中から通信相手から送信された交換データを受信する送受信処理を実行する（ステップＳ１４９）。処理の詳細については後述する。

次に、ＣＰＵ３１（通信切断処理部３１６）は、送受信処理が終了した場合、あるいは、通信接続が遮断された場合に通信を切断する（ステップＳ１６０）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、通信相手から受信した交換データを格納等する処理（データ格納処理とも称する）を実行する（ステップＳ１６１）。データ格納処理の詳細については後述する。

次に、ＣＰＵ３１（装置識別情報登録処理部２１１）は、通信相手の装置識別情報であるＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８に格納する処理（ＭＡＣアドレス保存処理）を実行する（ステップＳ１６２）。ＭＡＣアドレス保存処理の詳細については後述する。

次に、ＣＰＵ３１（データ通知処理部２１２）は、交換データを交換した旨をユーザに通知する処理（交換データ通知処理）を実行する（ステップＳ１６４）。交換データ通知処理の詳細については後述する。

以下、各処理について詳細に説明する。
＜フレンド認証処理＞
図４１は、本発明の実施の形態に従うフレンド認証処理のフロー図である。

図４１を参照して、ＣＰＵ３１（フレンド認証処理部３０４）は、フレンドコードの読み出しを実行する（ステップＳ４００）。具体的には、保存用データメモリ３４のフレンドコードリスト保存領域８９に格納されている自己のフレンドコードを取得する。

そして、ＣＰＵ３１（フレンド認証処理部３０４）は、無線通信モジュール３８を介してゲーム装置３にフレンドコードを送信する（ステップＳ４０２）。

次に、ＣＰＵ３１（フレンド認証処理部３０４）は、無線通信モジュール３８を介してゲーム装置３からフレンドコードを受信したかどうかを判断する（ステップＳ４０４）。

次に、ＣＰＵ３１（フレンド認証処理部３０４）は、無線通信モジュール３８を介してゲーム装置３からフレンドコードを受信したと判断した場合（ステップＳ４０４においてＹＥＳ）には、フレンド確認を実行する（ステップＳ４０６）。具体的には、受信したフレンドコードが保存用データメモリ３４のフレンドコードリスト保存領域８９に保存されているかどうかを判断する。

そして、受信したフレンドコードが保存用データメモリ３４のフレンドコードリスト保存領域８９に保存されていると判断した場合には、フレンド認証判定が成功（ＯＫ）とする。

一方、受信したフレンドコードが保存用データメモリ３４のフレンドコードリスト保存領域８９に保存されていないと判断した場合には、フレンド認証判定が失敗（ＮＧ）とする。

次に、ＣＰＵ３１（フレンド認証処理部３０４）は、フレンド確認結果を無線通信モジュール３８を介してゲーム装置３に送信する（ステップＳ４０８）。具体的には、フレンド認証判定がＯＫかＮＧかを送信する。

次に、ＣＰＵ３１（フレンド認証処理部３０４）は、フレンド確認結果を無線通信モジュール３８を介してゲーム装置３から受信したかどうかを判断する（ステップＳ４１０）。具体的には、ゲーム装置３からフレンド認証判定がＯＫかＮＧかの確認結果の受信があるかどうかを判断する。

ＣＰＵ３１（フレンド認証処理部３０４）は、ゲーム装置３からフレンド確認結果を受信したと判断した場合（ステップＳ４１０においてＹＥＳ）には、自機におけるフレンド認証判定がＯＫであったかどうかを判断する（ステップＳ４１２）。

ステップＳ４１２において、ＣＰＵ３１（フレンド認証処理部３０４）は、フレンド認証判定がＯＫであると判断した場合（ステップＳ４１２においてＹＥＳ）には、他機におけるフレンド認証判定がＯＫであったかどうかを判断する（ステップＳ４１４）。

ＣＰＵ３１（フレンド認証処理部３０４）は、自機および他機におけるフレンド認証判定がＯＫであると判断した場合（ステップＳ４１４においてＹＥＳ）には、フレンドフラグをオンに設定する（ステップＳ４１６）。そして、フレンド認証処理部３０４における処理を終了する（リターン）。

一方、ＣＰＵ３１（フレンド認証処理部３０４）は、無線通信モジュール３８を介してゲーム装置３からフレンドコードを受信しなかったと判断した場合（ステップＳ４０４においてＮＯ）には、通信接続が中断したと判断して通信を切断する（ステップＳ４１８）。

また、ステップＳ４１０において、無線通信モジュール３８を介してゲーム装置３からフレンド確認結果を受信しなかったと判断した場合（ステップＳ４１０においてＮＯ）には、通信接続が中断したと判断して通信を切断する（ステップＳ４１８）。

また、ステップＳ４１２，Ｓ４１４において、ＣＰＵ３１（フレンド認証処理部３０４）は、自機におけるフレンド認証判定がＯＫでないと判断した場合（ステップＳ４１２においてＮＯ）あるいは、他機におけるフレンド認証判定がＯＫでないと判断した場合（ステップＳ４１４においてＮＯ）には、フレンドフラグをオンにすることなく処理を終了する（リターン）。

図４２は、本発明の実施の形態に従うフレンド認証処理のデータの流れについて説明する図である。

図４２を参照して、まず、自機からフレンドコードＦＣＤ１が送信される（シーケンスｓｑ２００）。そして、ゲーム装置３においてフレンドコードＦＣＤ１が受信される（シーケンスｓｑ２０２）。

そして、次に、ゲーム装置３からフレンドコードＦＣＤ２が送信される（シーケンスｓｑ２０４）。そして、自機においてフレンドコードＦＣＤ２が受信される（シーケンスｓｑ２０６）。

そして、自機においてフレンド確認が実行される（シーケンスｓｑ２０８）。具体的には、受信したフレンドコードＦＣＤ２がフレンドコードリスト保存領域８９に格納されているかどうかが判断される。格納されている場合には、フレンド認証判定が成功（ＯＫ）、格納されていない場合には、フレンド認証判定が失敗（ＮＧ）となる。そして、フレンド確認結果が自機からゲーム装置３に送信される（シーケンスｓｑ２１０）。また、ゲーム装置３において、フレンド確認が実行される（シーケンスｓｑ２１２）。具体的には、受信したフレンドコードＦＣＤ１がフレンドコードリスト保存領域に格納されているかどうかが判断される。格納されている場合には、フレンド認証判定が成功（ＯＫ）、格納されていない場合には、フレンド認証判定が失敗（ＮＧ）となる。

そして、フレンド確認結果がゲーム装置３から自機に送信される（シーケンスｓｑ２１４）。

そして、自機１側において、自機および他機におけるフレンド認証判定がＯＫであると判断した場合にフレンドフラグがオンに設定される（シーケンスｓｑ２１６）。同様に、ゲーム装置３側においてもゲーム装置３側およびゲーム装置１側におけるフレンド認証判定がともにＯＫであると判断した場合にフレンドフラグがオンに設定される（シーケンスｓｑ２１８）。

なお、図４１におけるフレンド認証処理のフロー図は、ゲーム装置１側の処理について説明したが、ゲーム装置３側の処理としては、ステップＳ４００の前にステップＳ４０４の処理を実行し、ステップＳ４０８の前にステップＳ４１０の処理を実行する点で異なり、その他の点については同様であるのでその詳細な点については繰り返さない。

なお、本例においては、自機におけるフレンドコードリスト保存領域８９にゲーム装置３のフレンドコードが格納されているか否かに基づいてフレンド認証判定を実行する場合について説明したが、例えば、自機内でフレンド認証判定を実行するのではなく、フレンドコードリストが格納されている外部の認証サーバ等で認証判定した結果を自機１側に通知するような方式とすることも可能である。具体的には、外部のネットワークと接続されている無線アクセスポイント装置との間でデータ通信を行い、自機側から無線アクセスポイント装置を経由してネットワークと接続された認証サーバにフレンドコードを送信する。そして、認証サーバでフレンド認証判定を実行した結果を無線アクセスポイント装置を経由して、自機が受信する方式とすることが可能である。

＜送信スロット作成処理＞
図４３は、本発明の実施の形態に従う送信スロット作成の処理について説明するフロー図である。

図４３を参照して、ＣＰＵ３１（送信スロット作成処理部３０６）は、交換データを授受することが可能なアプリケーション（以下、交換データ授受アプリとも称する）を確認する（ステップＳ４２０）。具体的には、上述したゲーム装置１側の送信無線フレームとゲーム装置３から送信された受信無線フレームとに基づくアプリケーションＩＤ判定により、一致フラグがオンする全てのアプリケーションＩＤを確認する。アプリケーションＩＤ判定処理については上述したのと同様であるのでその詳細な説明は繰り返さない。すなわち、アプリケーションＩＤの一致により交換データを授受可能なアプリケーションを把握することが可能となる。また、内蔵アプリ保存領域８４に内蔵されているアプリケーションプログラムに対応する交換データのアプリケーションＩＤについて送信無線フレーム内に含めないようにする処理とした場合には、上記処理によるアプリケーションＩＤの一致によるアプリケーションの把握とは別に、内蔵アプリ保存領域８４に内蔵されているアプリケーションプログラムに対応する送信ＢＯＸに交換データが含まれているか否かを判断して、含まれている場合には、当該アプリケーションも交換データ授受アプリに付加するようにすれば良い。以降の処理についてはメモリカード２６に格納されているアプリケーションプログラムと、内蔵アプリ保存領域８４に格納されているアプリケーションプログラムとで処理は異ならないため特段区別することなく説明する。

図４４は、送信無線フレームの比較に基づく交換データを授受することが可能なアプリ（交換データ授受アプリとも称する）を確認する処理を模式的に説明する図である。

図４４を参照して、ここでは、リスト形式で示されており、自機側の送信無線フレームには、アプリＡ，Ｂ，Ｃ，Ｄ，ＥのアプリケーションＩＤが格納されている場合が示されている。なお、上述したように、アプリケーションＩＤには、アプリＡに対応するＩＤデータＩＤＤ０が格納されており、当該ＩＤデータに基づいてアプリＡが識別されることになるが、説明の簡略化のために以下の説明においては、ＩＤデータの代わりにアプリ名で説明する。他のアプリケーションについても同様である。

また、各アプリケーションＩＤに含められている送受信条件データが示されている。当該場合に交換データを授受することが可能なアプリについて説明する。

具体的には、アプリＡは、送受信条件データとして、いずれの条件でも通信が可能であるセンドフラグおよびレシーブフラグがそれぞれ「１１」である場合が示されている。また、アプリＢは、送受信条件データとして、双方向通信のみのセンドフラグおよびレシーブフラグがそれぞれ「００」である場合が示されている。アプリＣは、送受信条件データとして、送信通信のみのセンドフラグおよびレシーブフラグがそれぞれ「１０」である場合が示されている。また、アプリＤは、送受信条件データとして、受信通信のみのセンドフラグおよびレシーブフラグがそれぞれ「０１」である場合が示されている。アプリＥは、送受信条件データとして、受信通信のみのセンドフラグおよびレシーブフラグがそれぞれ「０１」である場合が示されている。

また、他機側の送信無線フレーム（受信無線フレーム）には、アプリＡ，Ｂ，Ｃ，Ｄ，ＦのアプリケーションＩＤが格納されている場合が示されている。また、各アプリケーションＩＤに含められている送受信条件データが示されている。

具体的には、アプリＡは、送受信条件データとして、いずれの条件でも通信が可能であるセンドフラグおよびレシーブフラグがそれぞれ「１１」である場合が示されている。また、アプリＢは、送受信条件データとして、双方向通信のみのセンドフラグおよびレシーブフラグがそれぞれ「００」である場合が示されている。アプリＣは、送受信条件データとして、受信通信のみのセンドフラグおよびレシーブフラグがそれぞれ「０１」である場合が示されている。また、アプリＤは、送受信条件データとして、送信通信のみのセンドフラグおよびレシーブフラグがそれぞれ「１０」である場合が示されている。アプリＦは、送受信条件データとして、いずれの条件でも通信が可能であるセンドフラグおよびレシーブフラグがそれぞれ「１１」である場合が示されている。

そして、上述したアプリケーションＩＤ判定により、アプリケーションＩＤが一致するとともに、送受信条件が合致するアプリケーション（アプリ）が交換データの授受が可能なアプリと判断される。なお、本例においては、アプリケーションＩＤ判定において、第２アルゴリズムに従うＩＤリスト比較に関して、説明の簡略化のために、交換条件データとして、送受信条件データが一致する場合のみを考えたが、取得条件データ等、他の条件も含めた判断により交換データ授受可能アプリを判断するようにしても良い。

一例として、本例においては、送受信条件データのみを判断した場合、図３０で説明した方式に従えば、自機１側においては、アプリＡ，Ｂ，Ｃについて送受信条件データが合致し、交換データ授受アプリと判断されるものとする。

同様に、ゲーム装置３側においては、アプリＡ，Ｂ，Ｄについて送受信条件データが合致し、交換データ授受アプリと判断されるものとする。

再び、図４３を参照して、次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、１つ目の交換データ授受アプリの送信ＢＯＸをアクセスする（ステップＳ４２１）。例えば、上記の図４４で説明した方式に従って、アプリＡが交換データ授受アプリである場合には、アプリＡに対応付けられて設けられた送信ＢＯＸＳＢＡがアクセスされる。

そして、次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、フレンドフラグがオンであるかどうかを判断する（ステップＳ４２２）。具体的には、図４０のフレンド認証処理部３０４のフレンド認証処理（ステップＳ１４５）に従ってフレンドフラグがオンされたかどうかを判断する。フレンドフラグがオンであるか否かに基づいて以降の処理が異なる。

ステップＳ４２２において、ＣＰＵ３１（送信スロット作成処理部３０６）は、フレンドフラグがオンであると判断した場合（ステップＳ４２２においてＹＥＳ）には、次に、送信ＢＯＸの先頭のデータを確認する（ステップＳ４２３）。具体的には、送信ＢＯＸスロットに格納された先頭のデータを確認する。

そして、次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、先頭のデータに格納されている送信回数が１以上であるかどうかを判断する（ステップＳ４２４）。後述するが送信回数が１以上でなければすなわち、送信回数が０の場合には、送信が終了していることを意味し、送信スロットには格納しない。

ステップＳ４２４において、ＣＰＵ３１（送信スロット作成処理部３０６）は、先頭のデータに格納されている送信回数が１以上であると判断した場合（ステップＳ４２４においてＹＥＳ）には、次に、データに格納されているフレンドフラグデータがフレンドであるか、あるいはＡＮＹであるかどうかを判断する（ステップＳ４２５）。

ステップＳ４２５において、ＣＰＵ３１（送信スロット作成処理部３０６）はデータに格納されているフレンドフラグデータがフレンドであるか、あるいはＡＮＹであると判断した場合（ステップＳ４２５においてＹＥＳ）には、送信ＢＯＸの先頭のデータをコピーする（ステップＳ４２６）。そして、ＣＰＵ３１（送信スロット作成処理部３０６）は、メインメモリ３２の送信スロット保存領域９０に作成した送信スロットに当該コピーしたデータを格納する（ステップＳ４２７）。

一方、ステップＳ４２４において、ＣＰＵ３１（送信スロット作成処理部３０６）は、先頭のデータに格納されている送信回数が１以上でないと判断した場合（ステップＳ４２４においてＮＯ）には、送信ＢＯＸに格納された最後のデータまで確認したかどうかを判断する（ステップＳ４３６）。

ステップＳ４３６において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに格納された最後のデータまで確認していないと判断した場合（ステップＳ４３６においてＮＯ）には、送信ＢＯＸの次のデータを確認する（ステップＳ４３７）。そして、再び、ステップＳ４２４に戻り、同様の処理を繰り返す。すなわち、送信回数が１回以上のデータが選択される。

また、ステップＳ４２５において、データに格納されているフレンドフラグデータがフレンドまたはＡＮＹでないと判断した場合（ステップＳ４２５においてＮＯ）にもステップＳ４３６に進む。

そして、ステップＳ４３６において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに格納された最後のデータまで確認していないと判断した場合（ステップＳ４３６においてＮＯ）には、送信ＢＯＸの次のデータを確認する（ステップＳ４３７）。そして、再び、ステップＳ４２４に戻り、同様の処理を繰り返す。すなわち、フレンドフラグデータがフレンドまたはＡＮＹのデータが選択される。

ステップＳ４３６において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに格納された最後のデータまで確認したと判断した場合（ステップＳ４３６においてＹＥＳ）には、条件が一致するデータが無いため、ステップＳ４３４に進む。すなわち、この場合には、送信スロットにデータはコピーされない。

次に、ステップＳ４２８において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信スロットに格納したデータのデータグループＩＤを確認する。

そして、次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに同一のデータグループＩＤのデータが有るかどうかを判断する（ステップＳ４２９）。

次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに同一のデータグループＩＤのデータが有ると判断した場合（ステップＳ４２９においてＹＥＳ）には、当該データに格納されている送信回数が１以上であるかどうかを判断する（ステップＳ４３０）。

次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信回数が１以上であると判断した場合（ステップＳ４３０においてＹＥＳ）には、次に、当該データに格納されているフレンドフラグデータがフレンドであるか、あるいはＡＮＹであるかどうかを判断する（ステップＳ４３１）。

ステップＳ４３１において、ＣＰＵ３１（送信スロット作成処理部３０６）は当該データに格納されているフレンドフラグデータがフレンドであるか、あるいはＡＮＹであると判断した場合（ステップＳ４３１においてＹＥＳ）には、送信ＢＯＸの当該データをコピーする（ステップＳ４３２）。そして、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信スロットに同一のデータＩＤグループのコピーしたデータを格納する（ステップＳ４３３）。

当該処理により、送信スロットに送信ＢＯＸの１つのデータ（フレンドフラグはフレンド又はＡＮＹ）が格納される。そして、格納したデータのデータグループＩＤを確認して、同一のデータグループＩＤのデータについてもフレンドフラグがフレンド又はＡＮＹの場合には、同じスロットに格納される。すなわち、送信スロットに格納された複数のデータが１つの交換データとして送信されることになる。本例においては、データグループＩＤが一致するデータを１まとめにする処理をデータグルーピング処理とも称する。ここまでで、フレンドフラグがオンである場合の１つの交換データ授受アプリの送信スロットの作成が完了する。

一方、ステップＳ４２９において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに同一のデータグループＩＤのデータがないと判断した場合（ステップＳ４２９においてＮＯ）には、ステップＳ４３４に進む。また、ステップＳ４３０において、ＣＰＵ３１（送信スロット作成処理部３０６）は、データに格納されている送信回数が１以上でないと判断した場合（ステップＳ４３０においてＮＯ）には、ステップＳ４３４に進む。また、ステップＳ４３１において、ＣＰＵ３１（送信スロット作成処理部３０６）は、データに格納されているフレンドフラグデータがフレンドでないあるいはＡＮＹでないと判断した場合（ステップＳ４３１においてＮＯ）には、ステップＳ４３４に進む。

一方、ステップＳ４２２において、ＣＰＵ３１（送信スロット作成処理部３０６）は、フレンドフラグがオンでないと判断した場合（ステップＳ４２２においてＮＯ）には、次に、送信ＢＯＸの先頭のデータを確認する（ステップＳ４３８）。具体的には、送信ＢＯＸスロットに格納された先頭のデータを確認する。

そして、次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、先頭のデータに格納されている送信回数が１以上であるかどうかを判断する（ステップＳ４３９）。後述するが送信回数が１以上でなければすなわち、送信回数が０の場合には、送信が終了していることを意味し、送信スロットには格納しない。

ステップＳ４３９において、ＣＰＵ３１（送信スロット作成処理部３０６）は、先頭のデータに格納されている送信回数が１以上であると判断した場合（ステップＳ４３９においてＹＥＳ）には、次に、データに格納されているフレンドフラグデータが非フレンドであるか、あるいはＡＮＹであるかどうかを判断する（ステップＳ４４０）。

ステップＳ４４０において、ＣＰＵ３１（送信スロット作成処理部３０６）はデータに格納されているフレンドフラグデータが非フレンドであるか、あるいはＡＮＹであると判断した場合（ステップＳ４４０においてＹＥＳ）には、送信ＢＯＸの先頭のデータをコピーする（ステップＳ４４１）。そして、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信スロットに当該コピーしたデータを格納する（ステップＳ４４２）。

一方、ステップＳ４３９において、ＣＰＵ３１（送信スロット作成処理部３０６）は、先頭のデータに格納されている送信回数が１以上でないと判断した場合（ステップＳ４３９においてＮＯ）には、送信ＢＯＸに格納された最後のデータまで確認したかどうかを判断する（ステップＳ４４９）。

ステップＳ４４９において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに格納された最後のデータまで確認していないと判断した場合（ステップＳ４４９においてＮＯ）には、送信ＢＯＸの次のデータを確認する（ステップＳ４５０）。そして、再び、ステップＳ４３９に戻り、同様の処理を繰り返す。すなわち、送信回数が１回以上のデータが選択される。

また、ステップＳ４４０において、データに格納されているフレンドフラグデータが非フレンドまたはＡＮＹでないと判断した場合（ステップＳ４４０においてＮＯ）にもステップＳ４４９に進む。

そして、ステップＳ４４９において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに格納された最後のデータまで確認していないと判断した場合（ステップＳ４４９においてＮＯ）には、送信ＢＯＸの次のデータを確認する（ステップＳ４５０）。そして、再び、ステップＳ４３９に戻り、同様の処理を繰り返す。すなわち、フレンドフラグデータが非フレンドまたはＡＮＹのデータが選択される。

ステップＳ４４９において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに格納された最後のデータまで確認したと判断した場合（ステップＳ４４９においてＹＥＳ）には、条件が一致するデータが無いため、ステップＳ４３４に進む。すなわち、この場合には、送信スロットにデータはコピーされない。

次に、ステップＳ４４３において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信スロットに格納したデータのデータグループＩＤを確認する。

そして、次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに同一のデータグループＩＤのデータが有るかどうかを判断する（ステップＳ４４４）。

次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに同一のデータグループＩＤのデータが有ると判断した場合（ステップＳ４４４においてＹＥＳ）には、当該データに格納されている送信回数が１以上であるかどうかを判断する（ステップＳ４４５）。

次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信回数が１以上であると判断した場合（ステップＳ４４５においてＹＥＳ）には、次に、当該データに格納されているフレンドフラグデータが非フレンドであるか、あるいはＡＮＹであるかどうかを判断する（ステップＳ４４６）。

ステップＳ４４６において、ＣＰＵ３１（送信スロット作成処理部３０６）は当該データに格納されているフレンドフラグデータが非フレンドであるか、あるいはＡＮＹであると判断した場合（ステップＳ４４６においてＹＥＳ）には、送信ＢＯＸの当該データをコピーする（ステップＳ４４７）。そして、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信スロットに同一のデータＩＤグループのコピーしたデータを格納する（ステップＳ４４８）。

当該処理により、送信スロットに送信ＢＯＸの１つのデータ（フレンドフラグは非フレンド又はＡＮＹ）が格納される。そして、格納したデータのデータグループＩＤを確認して、同一のデータグループＩＤのデータについてもフレンドフラグが非フレンド又はＡＮＹの場合には、同じスロットに格納される。すなわち、送信スロットに格納された複数のデータが１つの交換データとして送信されることになる。当該処理により、フレンドフラグがオンでない場合の１つの交換データ授受アプリの送信スロットの作成が完了する。

一方、ステップＳ４４４において、ＣＰＵ３１（送信スロット作成処理部３０６）は、送信ＢＯＸに同一のデータグループＩＤのデータがないと判断した場合（ステップＳ４４４においてＮＯ）には、ステップＳ４３４に進む。また、ステップＳ４４５において、ＣＰＵ３１（送信スロット作成処理部３０６）は、データに格納されている送信回数が１以上でないと判断した場合（ステップＳ４４５においてＮＯ）には、ステップＳ４３４に進む。また、ステップＳ４４６において、ＣＰＵ３１（送信スロット作成処理部３０６）は、データに格納されているフレンドフラグデータが非フレンドでないあるいはＡＮＹでないと判断した場合（ステップＳ４４６においてＮＯ）には、ステップＳ４３４に進む。

次に、ＣＰＵ３１（送信スロット作成処理部３０６）は、交換データ授受アプリが他にあるかどうかを判断する（ステップＳ４３４）。

ステップＳ４３４において、ＣＰＵ３１（送信スロット作成処理部３０６）は、交換データ授受アプリが他にあると判断した場合には、次の交換データ授受アプリの送信ＢＯＸをアクセスする（ステップＳ４３５）。例えば、上記の図４４で説明した方式に従って、アプリＢが次の交換データ授受アプリである場合には、アプリＢに対応付けられて設けられた送信ＢＯＸＳＢＢがアクセスされる。そして、ステップＳ４２２に戻り、同様の処理を繰り返す。

当該処理を繰り返すことにより、全ての交換データ授受アプリについて、送信ＢＯＸをアクセスして送信スロットの作成処理が実行される。

図４５は、本発明の実施の形態に従う送信スロットの作成の概念図である。
図４５を参照して、ここでは、送信ＢＯＸに４つのデータが格納されている場合が示されている。具体的には、ＩＤデータＩＤＤ０と、データグループＩＤＩＤＤ１と、データ本体ＩＤＤ１０とで構成されるデータが示されている。２つ目のデータと、４つ目のデータのデータグループＩＤとは同じ値であり、それ以外のデータは、それぞれ異なるデータグループＩＤが設定されている。

なお、説明を簡易にするためここでは、フレンドフラグは考慮しないものとする。また、送信回数も１回以上のデータが格納されているものとする。

上記の処理に従い、まず、図４５（Ａ）には、送信ＢＯＸの先頭（左端）のデータが確認されて、１つ目のデータが送信スロットに格納された場合が示されている。

そして、次に、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているかどうかが判断され、同一のデータグループＩＤのデータは送信ＢＯＸに格納されていないため図４５（Ｂ）に示されるように、送信スロットの作成は完了する。

一方、図４５（Ｂ）で作成された送信スロットに格納された交換データが送信された後、ここでは、一例として、図４５（Ｃ）には、送信ＢＯＸに３つのデータが格納されている場合が示されている。

上記の処理と同様に、まず、送信ＢＯＸの先頭のデータが確認されて、１つ目のデータが送信スロットに格納される。そして、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているかどうかが判断され、同一のデータグループＩＤの３つ目のデータが送信ＢＯＸに格納されているため、送信ＢＯＸに当該データが格納されて送信スロットの作成が完了する。

ここでは、データグループＩＤに基づくデータグルーピング処理について説明した。次に、フレンドフラグに基づくデータグルーピング処理について説明する。

図４６は、本発明の実施の形態に従う別の送信スロットの作成の概念図である。
図４６を参照して、ここでは、送信ＢＯＸに３つのデータが格納されている場合が示されている。具体的には、ＩＤデータＩＤＤ０と、データグループＩＤＩＤＤ１と、フレンドフラグデータＩＤＤ４と、データ本体ＩＤＤ１０とで構成されるデータが示されている。

具体的には、ＩＤデータＩＤＤ０と、データグループＩＤＩＤＤ１とは全て共通であり、フレンドフラグデータＩＤＤ４がそれぞれ異なる３つのデータが示されている。なお、説明を簡易にするためここでは、送信回数は１回以上のデータが格納されているものとする。

まず、フレンドフラグがオンである場合（フレンド）について説明する。上記の処理に従い、まず、送信ＢＯＸの先頭（左端）のデータが確認される。左端のデータのフレンドフラグはＡＮＹであるため、まず、最初に送信スロットに格納される。そして、次に、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているかどうかが判断され、同一のデータグループＩＤのデータが送信ＢＯＸに格納されていると判断される。そして、次に、データグループＩＤが同一であるデータについて、さらに、フレンドフラグがフレンド又はＡＮＹに設定されているデータが送信ＢＯＸ格納されているかどうかが判断される。２番目のデータのフレンドフラグがフレンドであるため送信スロットにさらに格納され、送信スロットの作成は完了する。

また、フレンドフラグがオンでない場合（非フレンド）について説明する。上記の処理に従い、まず、送信ＢＯＸの先頭（左端）のデータが確認される。左端のデータのフレンドフラグはＡＮＹであるため、まず、最初に送信スロットに格納される。そして、次に、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているかどうかが判断され、同一のデータグループＩＤのデータが送信ＢＯＸに格納されていると判断される。そして、次に、データグループＩＤが同一であるデータについて、さらに、フレンドフラグが非フレンド又はＡＮＹに設定されているデータが送信ＢＯＸ格納されているかどうかが判断される。３番目のデータのフレンドフラグが非フレンドであるため送信スロットにさらに格納され、送信スロットの作成は完了する。

したがって、フレンドフラグを用いることにより、データグルーピング処理においてフレンド用の交換データおよび非フレンド用の交換データに切り分けて送信スロットを作成することが可能となる。

図４７は、本発明の実施の形態に従う送信スロットの作成の具体例について説明する図である。

図４７（Ａ）を参照して、ここでは、送信ＢＯＸに３つのデータが格納されている場合が示されている。

具体的には、３つのデータの共通のアプリＩＤは、「１２３４５６７８」である。また、先頭および３番目のデータのデータグループＩＤは「１２３」、２番目のデータのデータグループＩＤは「４５６」である。また、先頭のデータのフレンドフラグデータは「フレンド」、２番目、３番目のフレンドフラグデータは「ＡＮＹ」である。また、１番目〜３番目のデータ本体はそれぞれ異なるためデータ本体ＩＤは、それぞれ「１００」、「２００」、「３００」として割り当てられている場合が示されている。

図４７（Ｂ）を参照して、ここでは、相手がフレンドである場合の送信スロットの作成の流れが示されている。

まず、（ｉ）送信ＢＯＸの先頭のデータを確認（チェック）する。（ｉｉ）次に、フレンドフラグを確認（チェック）する。本例においては、フラグオンでフレンドフラグがフレンドであるため条件を満たす（ＴＲＵＥ）。したがって、送信スロットに入れる。（ｉｉｉ）次のデータグループＩＤを確認（チェック）する。先頭のデータグループＩＤと、データグループＩＤが異なる。したがって、送信スロットには入れない。（ｉｖ）次のデータグループＩＤを確認（チェック）する。先頭のデータグループＩＤと、データグループＩＤが同じである。すなわち、条件を満たす（ＴＲＵＥ）。したがって、送信スロットには入れる。

図４７（Ｃ）を参照して、ここでは、相手が非フレンドである場合の送信スロットの作成の流れが示されている。

まず、（ｉ）送信ＢＯＸの先頭のデータを確認（チェック）する。（ｉｉ）次にフレンドフラグを確認（チェック）する。本例においては、フラグオフでフレンドフラグがフレンドであるため条件を満たさない（ＦＡＬＳＥ）。したがって、送信スロットに入れない。（ｉｉｉ）次のデータのフレンドフラグを確認（チェック）する。本例においては、フラグオフでフレンドフラグがＡＮＹであるため条件を満たす（ＴＲＵＥ）。したがって、送信スロットに入れる。（ｉｖ）次の、データグループＩＤを確認（チェック）する。２番目のデータのデータグループＩＤと、データグループＩＤが異なる。したがって、送信スロットには入れない。

図４８は、本発明の実施の形態に従う送信ＢＯＸに格納されたデータと、フレンドとの関係について説明する図である。

図４８（Ａ）を参照して、ここでは、送信ＢＯＸに４つのデータが格納されている場合が示されている。

具体的には、４つのデータの共通のアプリＩＤは、「１２３４５６７８」である。また、先頭および２番目のデータのデータグループＩＤは「１」、３番目および４番目のデータのデータグループＩＤは「２」である。また、先頭および３番目のデータのフレンドフラグデータは「ＡＮＹ」、２番目および４番目のフレンドフラグデータは「フレンド」である。また、１番目〜４番目のデータ本体はそれぞれ異なるためデータ本体ＩＤは、それぞれ「１００」、「２００」、「３００」、「４００」として割り当てられている場合が示されている。１番目のデータ本体には、アイテムのデータが格納されているものとする。また、２番目のデータ本体には、「プレゼントをあげます」のコメントデータが格納されているものとする。３番目のデータ本体には、アイテム２のデータが格納されているものとする。また、４番目のデータ本体には、「レアなアイテムです」のコメントデータが格納されているものとする。

フレンドフラグがオンである場合（フレンド）には、送信スロットに１番目と２番目のデータが格納される。１番目と２番目のデータが送信スロットから送信された後、２回目の送信として、３番目と４番目のデータが送信スロットに格納される。したがって、当該方式により、アイテムの送信に際して、フレンドに対してはコメントを付加したアイテムの送信が可能となる。

一方、フレンドフラグがオフである場合（非フレンド）には、送信スロットに１番目のデータが格納される。１番目のデータが送信スロットから送信された後、２回目の送信として、３番目のデータが送信スロットに格納される。したがって、当該方式により、アイテムの送信に際して、非フレンドに対してはコメントを付加しないアイテムの送信が可能となる。すなわち、フレンドか非フレンドかに従ってアイテムを送信する際に、コメントの付加を変更することが可能となり、データ交換の興趣性が増す。

図４８（Ｂ）を参照して、ここでは、送信ＢＯＸに４つのデータが格納されている場合が示されている。

具体的には、４つのデータの共通のアプリＩＤは、「１２３４５６７８」である。また、４つのデータのデータグループＩＤは、共通の「１」である。また、先頭および２番目のデータのフレンドフラグデータは「非フレンド」、３番目および４番目のフレンドフラグデータは「フレンド」である。また、１番目〜４番目のデータ本体はそれぞれ異なるためデータ本体ＩＤは、それぞれ「１００」、「２１０」、「３００」、「４００」として割り当てられている場合が示されている。１番目のデータ本体には、アイテムのデータが格納されているものとする。また、２番目のデータ本体には、「誰かもらってください」のコメントデータが格納されているものとする。３番目のデータ本体には、アイテム２のデータが格納されているものとする。また、４番目のデータ本体には、「レアなアイテムです」のコメントデータが格納されているものとする。

フレンドフラグがオンである場合（フレンド）には、送信スロットに３番目と４番目のデータが格納される。したがって、当該方式により、アイテムの送信に際して、フレンドに対してはコメントとともにアイテム２の送信が可能となる。

一方、フレンドフラグがオフである場合（非フレンド）には、送信スロットに１番目と２番目のデータが格納される。したがって、当該方式により、アイテムの送信に際して、非フレンドに対してはコメントとともにアイテム１の送信が可能となる。すなわち、フレンドか非フレンドに従って送信するアイテムの種類を変更することが可能となり、データ交換の興趣性が増す。

図４８（Ｃ）を参照して、ここでは、送信ＢＯＸに３つのデータが格納されている場合が示されている。

具体的には、３つのデータの共通のアプリＩＤは、「１２３４５６７８」である。また、３つのデータのデータグループＩＤは、共通の「１」である。また、先頭のデータのフレンドフラグデータは「非フレンド」、２番目のフレンドフラグデータは「ＡＮＹ」、３番目のフレンドフラグデータは「フレンド」である。また、１番目〜３番目のデータ本体はそれぞれ異なるためデータ本体ＩＤは、それぞれ「２１０」、「１００」、「３１０」として割り当てられている場合が示されている。１番目のデータ本体には、「誰かもらってください」のコメントデータが格納されているものとする。２番目のデータ本体には、アイテムのデータが格納されているものとする。また、３番目のデータ本体には、「○○からのプレゼント！」のコメントデータが格納されているものとする。

フレンドフラグがオンである場合（フレンド）には、送信スロットに２番目と３番目のデータが格納される。したがって、当該方式により、アイテムの送信に際して、「○○からのプレゼント！」のコメントを付加することが可能となる。

一方、フレンドフラグがオフである場合（非フレンド）には、送信スロットに１番目と２番目のデータが格納される。したがって、当該方式により、アイテムの送信に際して、「誰かもらってください」のコメントを付加することが可能となる。すなわち、フレンドか非フレンドかに従って送信するアイテムとともに付加するコメントの内容を変更することが可能となり、適切なコメントを付加してデータ交換の興趣性が増すことになる。

＜送信データリスト作成処理＞
図４９は、本発明の実施の形態に従う送信データリストの作成処理について説明するフロー図である。

図４９を参照して、ＣＰＵ３１（送信データリスト作成処理部３０８）は、送信スロットを確認する（ステップＳ４６０）。具体的には、送信スロット保存領域９０に保存された、送信スロット作成処理部３０６により作成された交換データ授受アプリ毎の送信スロットを確認する。

そして、次に、ＣＰＵ３１（送信データリスト作成処理部３０８）は、各送信スロットのデータを確認する（ステップＳ４６２）。具体的には、送信スロットに格納された各々のデータのＩＤデータ、送受信条件データ、データサイズ等を確認する。

そして、ＣＰＵ３１（送信データリスト作成処理部３０８）は、送信データリストを作成する（ステップＳ４６４）。そして、処理を終了する（リターン）。

図５０は、本発明の実施の形態に従う送信データリストについて説明する図である。
本例では、図４４の比較に基づいて、自機側においてアプリＡ，Ｂ，Ｃが交換データ授受アプリである場合について説明する。また、ゲーム装置３側において、アプリＡ，Ｂ，Ｄが交換データ授受アプリである場合について説明する。

図５０（Ａ）に示されるように、ここでは、自機側の送信データリストが示されている。

具体的には、アプリＡ，Ｂ，Ｃにそれぞれ対応する送受信条件データと、アプリＡ，Ｂ，Ｃにそれぞれ対応して設けられた送信スロットに格納されたデータサイズが格納される。また、ゲーム装置３が交換データを受信可能であるか否かを示すフラグ欄が設けられている。

図５０（Ｂ）に示されるように、ここでは、ゲーム装置３側の送信データリストが示されている。

具体的には、アプリＡ，Ｂ，Ｄにそれぞれ対応する送受信条件データと、アプリＡ，Ｂ，Ｄに対応して設けられた送信スロットに格納されたデータサイズが格納される。また、ゲーム装置３が交換データを受信可能であるか否かを示すフラグ欄が設けられている。

自機側で作成された送信データリストは、ゲーム装置３側に送信される。そして、ゲーム装置３側において、送信データリストにリストアップされた交換データの受信が可能であるかどうかを判断して、その結果をフラグ欄に書込んで返信する。

同様に、ゲーム装置３側で作成された送信データリスト（自機側からは受信データリストとも称する）が送信される。そして、自機側において、受信データリストにリストアップされた交換データの受信が可能であるかどうかを判断して、その結果をフラグ欄に書込んで返信する。

＜送受信データリスト分析処理＞
図５１は、本発明の実施の形態に従う送受信データリスト分析処理について説明するフロー図である。

図５１を参照して、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、送信データリスト作成処理部３０８で作成した送信データリストを送信する（ステップＳ４６０）。本例においては、ゲーム装置３に送信データリストを送信する。

そして、次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、受信データリストを受信したかどうかを判断する（ステップＳ４６２）。具体的には、通信相手であるゲーム装置３で作成され、送信された送信データリスト（受信データリスト）を受信したかどうかを判断する。

そして、次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、受信データリストを受信したと判断した場合（ステップＳ４６２においてＹＥＳ）には、受信データリストの受信判定を実行する（ステップＳ４６４）。具体的には、受信データリストにリストアップされているゲーム装置３から送信される交換データを受信可能であるかどうかを判断する。

上述したように、アプリケーション毎に受信ＢＯＸの容量および受信可能なデータ個数が規定されており、受信ＢＯＸの容量あるいは、受信可能なデータ個数を超えるようなデータの受信はできない。

したがって、受信データリストにリストアップされている交換データのサイズと、対応するアプリケーションの受信ＢＯＸの容量および受信可能なデータ個数を確認することにより受信可能であるかどうかを判断する。

そして、次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、受信データリストの更新処理を実行する（ステップＳ４６６）。

具体的には、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、受信可能であると判断した場合には、ＯＫ判定フラグを当該受信データリストのフラグ欄に付加する処理を実行する。一方、受信が不可能であると判断した場合には、ＮＧ判定フラグを当該受信データリストのフラグ欄に付加する処理を実行する。

そして、次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、更新した受信データリストを送信する（ステップＳ４６８）。本例においては、ゲーム装置３に受信データリストを送信（返信）する。

次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、更新された送信データリストを受信したかどうかを判断する（ステップＳ４７０）。ゲーム装置３側においても自機側と同様の処理が実行される。すなわち、送信データリストにリストアップされている交換データのサイズと、対応するアプリケーションの受信ＢＯＸの容量および受信可能なデータ個数を確認することにより受信可能であるかどうかを判断する。そして、自機から送信された送信データリストのフラグ欄にＯＫ判定フラグあるいはＮＧ判定フラグが付加されて、更新された送信データリストが返信されることになる。

次に、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、更新された送信データリストを受信したと判断した場合（ステップＳ４７０においてＹＥＳ）には、処理を終了する（リターン）。

一方、ステップＳ４６２において、ＣＰＵ３１（送受信データリスト分析処理部３１０）は、受信データリストを受信しなかったと判断した場合（ステップＳ４６２においてＮＯ）あるいは、更新された送信データリストを受信しなかったと判断した場合（ステップＳ４７０においてＮＯ）には、通信が遮断されたと判断して通信接続を切断する（ステップＳ４７２）。そして、処理を終了する（エンド）。

図５２は、本実施の形態に従う送受信データリストの送受信の流れについて説明する図である。

図５２を参照して、自機側から、作成された送信データリストが送信される（シーケンスｓｑ２２０）。また、ゲーム装置３側から、作成された送信データリストが送信される（シーケンスｓｑ２２２）。

そして、自機側において、ゲーム装置３から送信された送信データリスト（受信データリスト）を分析して、リストアップされている交換データが受信可能であるかどうかを判断し、受信データリストを更新する（シーケンスｓｑ２２４）。

本例においては、一例としてアプリＡ，Ｂ，Ｃについては、受信可能であるＯＫ判定フラグがフラグ欄に付加された場合が示されている。

そして、更新した受信データリストを返信する（シーケンスｓｑ２２６）。
また、ゲーム装置３側において、自機側から送信された送信データリストを分析して、リストアップされている交換データが受信可能であるかどうかを判断し、受信データリストを更新する（シーケンスｓｑ２２８）。本例においては、一例として、アプリＡ，Ｂについては、受信可能であるＯＫ判定フラグがフラグ欄に付加され、アプリＣについては、受信が不可能であるＮＧ判定フラグがフラグ欄に付加された場合が示されている。

そして、更新した受信データリストを返信する（シーケンスｓｑ２３０）。
当該処理により、自機側は、ゲーム装置３側で更新された送信データリストを受信し、送信データリストのフラグ欄に書き込まれたＯＫ判定フラグあるいはＮＧ判定フラグに従って実際に交換データを送受信するかどうかを判断することが可能となる。

本例においては、送信データリストに従って、アプリＡ，Ｂの送信は可能であるが、アプリＣの送信は不可能であると判断される。

また、自機側において、ゲーム装置３で作成された受信データリストを受信して、受信が可能かどうかをフラグ欄に書込んで返信することにより、ゲーム装置３から実際に送信される交換データを把握することが可能となる。

本例においては、受信データリストに従って、アプリＡ，Ｂ，Ｄの交換データがゲーム装置３から送信され、自機側で受信するものとして把握することが可能である。

ゲーム装置３側についても同様である。
具体的には、ゲーム装置３側においては、送信データリストに従って、アプリＡ，Ｂ，Ｄの送信は可能であると判断される。

また、受信データリストに従って、アプリＡ，Ｂの交換データが自機側から送信され、受信されるが、アプリＣの交換データは自機側からは送信されないもの（受信が不可能である為）として把握することが可能である。

＜送受信実行処理＞
図５３は、本発明の実施の形態に従う送受信実行処理について説明するフロー図である。

本例における送受信実行処理は、主に、図８の送受信実行処理部３１２で実行されるが、後述する送信データリスト送信判定処理（ステップＳ１５１）および受信データリスト受信判定処理（ステップＳ１５５）は、図８のデータリスト判定部３１４で実行される処理である。また、ステップＳ１５７において通信が終了したかどうかを判断して、ステップＳ１５８において通信を切断する処理は、図８の通信切断処理部３１６で実行される処理である。

図５３を参照して、ＣＰＵ３１（送受信実行処理部３１２）は、送信処理を開始する（ステップＳ１５０）。

ここで、送信処理に際し、互いに交換データの授受を実行する２つのゲーム装置のうち一方が親機となり他方が子機となるが、本例においては、接続要求信号を出力した子機側のゲーム装置から親機側のゲーム装置に交換データを出力するものとする。なお、本例においては、ゲーム装置１が子機となった場合の処理について説明する。そして、ゲーム装置３が親機となった場合の処理について説明する。

次に、ＣＰＵ３１（送受信実行処理部３１２）は、自機が親機か子機かを判断するため子機としての接続フラグがオンであるかどうかを判断する（ステップＳ１５０＃）。接続フラグの設定に関しては、後述する。

そして、次に、子機としての接続フラグがオンである場合、すなわち、自機が子機であると判断した場合（ステップＳ１５０＃においてＹＥＳ）には、ＣＰＵ３１（データリスト判定部３１４）は、送信データリストの送信可能なデータが全て送信されたかどうかを判定する送信データリスト送信判定処理を実行する（ステップＳ１５１）。

図５４は、本発明の実施の形態に従う送信データリスト送信判定処理を説明するフロー図である。

図５４を参照して、ＣＰＵ３１（データリスト判定部３１４）は、後述する送信完了フラグがオンされているかどうかを判断する（ステップＳ４９０）。

ステップＳ４９０において、ＣＰＵ３１（データリスト判定部３１４）は、送信完了フラグがオンされていない場合（ステップＳ４９０においてＮＯ）には、送信データリストを確認する（ステップＳ４９２）。具体的には、送信データリストの送信可能なデータに立てられる送信完了フラグを確認する。

そして、次に、ＣＰＵ３１（データリスト判定部３１４）は、送信データリストの送信可能なデータが全て送信されたかどうかを判断する（ステップＳ４９４）。具体的には、送信データリストの送信可能なデータに全ての送信完了フラグが立てられたかどうかを判断する。

ステップＳ４９４において、ＣＰＵ３１（データリスト判定部３１４）は、送信データリストの送信可能なデータが全て送信されたと判断した場合（ステップＳ４９４においてＹＥＳ）には、送信完了フラグをオンに設定する（ステップＳ４９６）。そして、処理を終了する（リターン）。

ステップＳ４９０において、ＣＰＵ３１（データリスト判定部３１４）は、送信完了フラグがオンされている場合（ステップＳ４９０においてＹＥＳ）には、送信データリストを確認する必要がなく処理を終了する（ＤＤに進む）。すなわち、ステップＳ１５３に進む。

再び、図５３を参照して、次に、ＣＰＵ３１（送受信実行処理部３１２）は、通信相手（親機）に交換データを送信する（ステップＳ１５２）。具体的には、送信データリストの送信可能な交換データを送信する。なお、送信データリストの送信可能なデータについて、データサイズの小さい交換データから送信するようにしても良い。

次に、ＣＰＵ３１（送受信実行処理部３１２）は、送信データリストを更新する（ステップＳ１５２＃）。具体的には、送信データリストにおいて、交換データを送信した場合に当該交換データを送信した旨を示す送信ＯＫフラグを立てる。

一方、子機としての接続フラグがオンでない場合、すなわち、自機が親機であると判断した場合（ステップＳ１５０＃においてＮＯ）には、「ＡＡ」に進む。「ＡＡ」以降の処理は、親機側の処理であり後述する。

そして、次に、ＣＰＵ３１（送受信実行処理部３１２）は、通信相手（親機）から交換データを一定期間内に受信したかどうかを判断する（ステップＳ１５３）。

ステップＳ１５３において、ＣＰＵ３１（送受信実行処理部３１２）は、通信相手（親機）から交換データを一定期間内に受信したと判断した場合には（ステップＳ１５２においてＹＥＳ）には、受信データリストを更新する（ステップＳ１５３＃）。具体的には、受信データリストにおいて、交換データを受信した場合に当該交換データを受信した旨を示す受信ＯＫフラグを立てる。

次に、ＣＰＵ３１（送受信実行処理部３１２）は、メインメモリ３２に交換データを格納する（ステップＳ１５４）。なお、この時点においては、後述するデータ格納処理のためにメインメモリに一時的に格納し、アプリケーション毎に設けられた受信ＢＯＸには保存しない。

そして、次に、ＣＰＵ３１（データリスト判定部３１４）は、受信データリストの受信可能なデータが全て受信されたかどうかを判定する受信データリスト受信判定処理を実行する（ステップＳ１５５）。

図５５は、本発明の実施の形態に従う受信データリスト受信判定処理を説明するフロー図である。

図５５を参照して、ＣＰＵ３１（データリスト判定部３１４）は、受信完了フラグがオンされているかどうかを判断する（ステップＳ４８０）。

ステップＳ４８０において、ＣＰＵ３１（データリスト判定部３１４）は、受信完了フラグがオンされていない場合（ステップＳ４８０においてＮＯ）には、受信データリストを確認する（ステップＳ４８２）。具体的には、受信データリストの受信可能なデータに立てられる受信完了フラグを確認する。

そして、次に、ＣＰＵ３１（データリスト判定部３１４）は、受信データリストの受信可能なデータが全て受信されたかどうかを判断する（ステップＳ４８４）。具体的には、受信データリストの受信可能なデータに全ての受信完了フラグが立てられたかどうかを判断する。

ステップＳ４８４において、ＣＰＵ３１（データリスト判定部３１４）は、受信データリストの受信可能なデータが全て受信されたと判断した場合（ステップＳ４８４においてＹＥＳ）には、受信完了フラグをオンに設定する（ステップＳ４８６）。そして、処理を終了する（リターン）。

ステップＳ４８０において、ＣＰＵ３１（データリスト判定部３１４）は、受信完了フラグがオンされている場合（ステップＳ４８０においてＹＥＳ）には、受信データリストを確認する必要がなく処理を終了する（リターン）。

再び、図５３を参照して、次に、ＣＰＵ３１（通信切断処理部３１６）は、通信が終了したかどうかを判断する（ステップＳ１５７）。具体的には、送信完了フラグおよび受信完了フラグがともにオンである場合には、送受信が完了すなわち通信が終了したと判断する。また、通信が遮断された場合にも通信が終了したと判断する。

ＣＰＵ３１（通信切断処理部３１６）は、通信が終了したと判断した場合（ステップＳ１５７においてＹＥＳ）には、通信接続を切断する（ステップＳ１５８）。そして、処理を終了する（リターン）。

一方、ＣＰＵ３１（通信切断処理部３１６）は、通信が終了していないと判断した場合（ステップＳ１５７においてＮＯ）には、ステップＳ１５１に戻る。

次に、親機側の処理について説明する。
なお、本例においては、ゲーム装置３が親機となった場合の処理について説明する。

図５６は、本発明の実施の形態に従う送受信実行処理について親機側の処理を部分的に説明するフロー図である。

親機側の処理についても、子機側の処理とほぼ同様であり、受信および送信のタイミングが基本的に異なるのみである。

図５６を参照して、子機としての接続フラグがオンでない場合、すなわち、親機としての接続フラグがオンであり自機が親機であると判断した場合（ステップＳ１５０＃においてＮＯ）には、ＣＰＵ３１（送受信実行処理部３１２）は、通信相手（子機）から交換データを一定期間内に受信したかどうかを判断する（ステップＳ１７２）。

次に、ステップＳ１７２において、通信相手（子機）から一定期間内に交換データを受信したと判断した場合（ステップＳ１７２においてＹＥＳ）には、受信データリストを更新する（ステップＳ１７４）。具体的には、受信データリストにおいて、交換データを受信した場合に当該交換データを受信した旨を示す受信ＯＫフラグを立てる。

次に、ＣＰＵ３１（送受信実行処理部３１２）は、メインメモリ３２に交換データを格納する（ステップＳ１７８）。なお、この時点においては、後述するデータ格納処理のためにメインメモリ３２に一時的に格納し、アプリケーション毎に設けられた受信ＢＯＸには保存しない。

そして、次に「ＢＢ」に進む。すなわち、図５３のステップＳ１５５に進む。以降の処理については上述したのと同様である。

また、ステップＳ１７２において、ＣＰＵ３１（送受信実行処理部３１２）は、通信相手（子機）から一定期間内に交換データを受信していないと判断した場合（ステップＳ１７２においてＮＯ）には、次に、「ＣＣ」に進む。すなわち、図５３のステップＳ１５７に進む。

そして、ステップＳ１５７において、ＣＰＵ３１（通信切断処理部３１６）は、通信が終了したかどうかを判断し、送信完了フラグおよび受信完了フラグがともにオンでない場合には、ステップＳ１５１に戻る。そして、当該処理を繰り返す。

図５７は、本発明の実施の形態に従う送受信実行処理のデータの流れについて説明する図である。本例においては、図５２で説明した送信データリストおよび受信データリストに基づく送受信実行処理について説明する。

図５７を参照して、自機側から、ゲーム装置３側にアプリＡの交換データが送信される（シーケンスｓｑ２３０）。当該交換データの送信処理に従い自機側の送信データリストのアプリＡに対応して送信ＯＫフラグが立てられる。また、ゲーム装置３側において、ゲーム装置３側の受信データリストのアプリＡに対応して受信ＯＫフラグが立てられる。

次に、ゲーム装置３側から、自機側にアプリＡの交換データが送信される（シーケンスｓｑ２３２）。当該交換データの送信処理に従いゲーム装置３側の送信データリストのアプリＡに対応して送信ＯＫフラグが立てられる。また、自機側において、受信データリストのアプリＡに対応して受信ＯＫフラグが立てられる。

次に、自機側から、ゲーム装置３側にアプリＢの交換データが送信される（シーケンスｓｑ２３４）。当該交換データの送信処理に従い自機側の送信データリストのアプリＡに対応して送信ＯＫフラグが立てられる。また、ゲーム装置３側において、ゲーム装置３側の受信データリストのアプリＢに対応して受信ＯＫフラグが立てられる。

次に、ゲーム装置３側から、自機側にアプリＢの交換データが送信される（シーケンスｓｑ２３６）。当該交換データの送信処理に従いゲーム装置３側の送信データリストのアプリＢに対応して送信ＯＫフラグが立てられる。また、自機側において、受信データリストのアプリＡに対応して受信ＯＫフラグが立てられる。

そして、自機側においては、送信データリストは送信完了フラグがオンであるためデータの送信処理は行われず、受信完了フラグはオンではなくオフであるためデータの受信待ち状態となる。

そして、ゲーム装置３側から、自機側にアプリＤの交換データが送信される（シーケンスｓｑ２３８）。当該交換データの送信処理に従いゲーム装置３側の送信データリストのアプリＤに対応して送信ＯＫフラグが立てられる。また、自機側において、受信データリストのアプリＤに対応して受信ＯＫフラグが立てられる。これにより、自機側においては、受信完了フラグがオンする。

したがって、自機側において、送信完了フラグおよび受信完了フラグがオンするため通信が終了する。同様に、ゲーム装置３側においても、受信完了フラグおよび送信完了フラグがオンするため通信が終了する。

すなわち、上記処理により通信相手との間での交換データの授受処理が終了することになる。

なお、本例においては、アプリＡから順番に交互に自機側からゲーム装置３側に交換データが送信される場合について説明しているが、特にこの順番に限られず、送信データリストの送信可能なデータについて、データサイズの小さい交換データから送信するようにして、データの送受信がなるべく成功するようにしても良い。

＜データ格納処理＞
図５８は、本発明の実施の形態に従うデータ格納処理のフロー図である。

図５８を参照して、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストを確認する（ステップＳ５００）。具体的には、自機側の送信データリストについて確認する。なお、ステップＳ５００〜Ｓ５０６の処理において、自機側の送信データリストにリストアップされたアプリケーションについて、送受信条件が満たされているか否かが判断される。なお、自機側の送信データリストには、交換データをゲーム装置３に送信するアプリケーションのみがリストアップされるため、交換データをゲーム装置３から受信のみするアプリケーションについてはリストアップされない。したがって、当該交換データをゲーム装置３から受信のみするアプリケーションについて、受信条件を満たしているか否かについては、ステップＳ５０８〜Ｓ５１４の処理で判断される。

次に、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストの１つを抽出する（ステップＳ５０２）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ判定処理を実行する（ステップＳ５０４）。

図５９は、本発明の実施の形態に従う送信データリストフラグ判定処理のフロー図である。

図５９を参照して、ＣＰＵ３１（データ格納処理部２１０）は、抽出された１つの送信データリストの送受信条件データ（センドフラグおよびレシーブフラグ）を確認する（ステップＳ５２０）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、送受信条件データに従って条件が満たされたかどうかを判定する送信データリストフラグ条件判定処理を実行する（ステップＳ５２２）。

図６０は、本発明の実施の形態に従う送信データリストフラグ条件判定処理のフロー図である。

図６０を参照して、送受信条件データについてセンドフラグ，レシーブフラグが「０，０」であるかどうかを判断する（ステップＳ５４０）。すなわち、送受信条件データが双方向通信（交換通信）のみであるかどうかを判断する。

ステップＳ５４０において、送受信条件データについてセンドフラグ，レシーブフラグが「０，０」であると判断した場合（ステップＳ５４０においてＹＥＳ）には、送信データリストの送信フラグがＯＫであるかどうかを判断する（ステップＳ５４２）。

ステップＳ５４２において、送信データリストの送信フラグがＯＫであると判断した場合（ステップＳ５４２においてＹＥＳ）には、受信データリストを確認する（ステップＳ５４４）。具体的には、対応するアプリケーションの受信データリストを確認する。

次に、受信データリストの受信フラグがＯＫであるかどうかを判断する（ステップＳ５４６）。

ステップＳ５４６において、受信データリストの受信フラグがＯＫであると判断した場合（ステップＳ５４６においてＹＥＳ）には、送受信ＯＫ判定とする（ステップＳ５４８）。すなわち、送受信条件データが双方向通信（交換通信）のみであり、当該条件が満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５４２において、送信データリストの送信フラグがＯＫでないと判断した場合（ステップＳ５４２においてＮＯ）には、ＮＧ判定とする（ステップＳ５５０）。すなわち、送受信条件データが双方向通信（交換通信）のみであり、当該条件が満たされなかったことを意味する。そして、処理を終了する（リターン）。

また、ステップＳ５４６において、受信データリストの受信フラグがＯＫでないと判断した場合（ステップＳ５４６においてＮＯ）には、ＮＧ判定とする（ステップＳ５５０）。すなわち、送受信条件データが双方向通信（交換通信）のみであり、当該条件が満たされなかったことを意味する。そして、処理を終了する（リターン）。

次に、ステップＳ５４０において、送受信条件データについてセンドフラグ，レシーブフラグが「０，０」でないと判断された場合（ステップＳ５４０においてＮＯ）には、送受信条件データについてセンドフラグ，レシーブフラグが「１，１」であるかどうかを判断する（ステップＳ５５２）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であるかどうかを判断する。

ステップＳ５５２において、送受信条件データについてセンドフラグ，レシーブフラグが「１，１」であると判断した場合（ステップＳ５５２においてＹＥＳ）には、送信データリストの送信フラグがＯＫであるかどうかを判断する（ステップＳ５５４）。

ステップＳ５５４において、送信データリストの送信フラグがＯＫであると判断した場合（ステップＳ５５４においてＹＥＳ）には、受信データリストを確認する（ステップＳ５５６）。具体的には、対応するアプリケーションの受信データリストを確認する。

次に、受信データリストの受信フラグがＯＫであるかどうかを判断する（ステップＳ５５８）。

ステップＳ５５８において、受信データリストの受信フラグがＯＫであると判断した場合（ステップＳ５５８においてＹＥＳ）には、送受信ＯＫ判定とする（ステップＳ５６０）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であり、送信および受信の当該条件がともに満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５５８において、受信データリストの受信フラグがＯＫでないと判断した場合（ステップＳ５５８においてＮＯ）には、送信ＯＫ判定とする（ステップＳ５５９）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であり、送信条件のみが満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５５４において、送信データリストの送信フラグがＯＫでないと判断した場合（ステップＳ５５４においてＮＯ）には、受信データリストを確認する（ステップＳ５６１）。

具体的には、対応するアプリケーションの受信データリストを確認する。
次に、受信データリストの受信フラグがＯＫであるかどうかを判断する（ステップＳ５６２）。

ステップＳ５６２において、受信データリストの受信フラグがＯＫであると判断した場合（ステップＳ５６２においてＹＥＳ）には、受信ＯＫ判定とする（ステップＳ５６３）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であり、受信条件のみが満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５６２において、受信データリストの受信フラグがＯＫでないと判断した場合（ステップＳ５６２においてＮＯ）には、ＮＧ判定とする（ステップＳ５６４）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であり、送信条件および受信条件のいずれの条件も満たされなかったことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５５２において、送受信条件データについてセンドフラグ，レシーブフラグが「１，１」でないと判断した場合（ステップＳ５５２においてＮＯ）には、送受信条件データについてセンドフラグ，レシーブフラグが「１，０」であるかどうかを判断する（ステップＳ５６５）。すなわち、送受信条件データが送信通信のみであるかどうかを判断する。

ステップＳ５６５において、送受信条件データについて、センドフラグ，レシーブフラグが「１，０」であると判断した場合（ステップＳ５６５においてＹＥＳ）には、送信データリストの送信フラグがＯＫであるかどうかを判断する（ステップＳ５６６）。

ステップＳ５６６において、送信データリストの送信フラグがＯＫであると判断した場合（ステップＳ５６６においてＹＥＳ）には、送信ＯＫ判定とする（ステップＳ５６７）。すなわち、送受信条件データが送信通信のみであり、送信条件のみが満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５６６において、送信データリストの送信フラグがＯＫでないと判断した場合（ステップＳ５６６においてＮＯ）には、ＮＧ判定とする（ステップＳ５６８）。すなわち、送受信条件データが送信通信のみであり、送信条件を満たさなかったことを意味する。そして、処理を終了する（リターン）。

なお、送受信条件データであるセンドフラグ，レシーブフラグが「０，１」の場合については、交換データは、当該送受信条件データは受信通信のみを意味するため、送信スロットは形成されない。したがって、送信データリストには当該送受信条件データは存在しない。

再び、図５９を参照して、次に、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が送受信ＯＫ判定であるかどうかを判断する（ステップＳ５２４）。

ステップＳ５２４において、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が送受信ＯＫ判定であると判断（ステップＳ５２４においてＹＥＳ）には、受信データを対応するアプリケーションの受信ＢＯＸに格納する（ステップＳ５２６）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、受信データ判定処理を実行する（ステップＳ５２８）。受信データ判定処理の詳細については後述する。

一方、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が送受信ＯＫ判定でないと判断した場合（ステップＳ５２４においてＮＯ）には、ステップＳ５３２に進む。

そして、次に、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が送信ＯＫ判定であるかどうかを判断する（ステップＳ５３２）。

ステップＳ５３２において、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が送信ＯＫ判定であると判断した場合（ステップＳ５３２においてＹＥＳ）には、対応する送信ＢＯＸの交換データの送信回数を更新する（ステップＳ５３０）。具体的には、送信回数を１減算する。例えば、送信回数が２回である場合には、当該送信回数は１回に更新される。当該送信回数は、送信スロットから交換データとして送信される回数を意味する。したがって、送信回数が０回となった場合には、送信スロットから交換データとして送信されない。

そして、次に、送信ＢＯＸのデータの配列を変更する（ステップＳ５３１）。具体的には、送信ＢＯＸにある送信スロットに格納して送信した交換データを最後尾に配置する。なお、送信スロットに送信ＢＯＸから複数のデータが格納された場合においても、送信したデータ全てが送信ＢＯＸの最後尾に配置される。したがって、送信ＢＯＸに配置されたデータが順番に送信されることになる。そして、処理を終了する（リターン）。

一方、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が送信ＯＫ判定でないと判断した場合（ステップＳ５３２においてＮＯ）には、ステップＳ５３３に進む。

そして、次に、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が受信ＯＫ判定であるかどうかを判断する（ステップＳ５３３）。ステップＳ５３３において、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が受信ＯＫ判定であると判断した場合（ステップＳ５３３においてＹＥＳ）には、受信データを対応するアプリケーションの受信ＢＯＸに格納する（ステップＳ５３４）。そして、次に、ＣＰＵ３１（データ格納処理部２１０）は、受信データ判定処理を実行する（ステップＳ５３５）。受信データ判定処理の詳細については後述する。

一方、次に、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストフラグ条件判定処理の判定結果が受信ＯＫ判定でないと判断した場合（ステップＳ５３３においてＮＯ）には、ＮＧ判定かどうかを判断する（ステップＳ５３６）。

そして、ステップＳ５３６において、ＣＰＵ３１（データ格納処理部２１０）は、ＮＧ判定であると判断した場合（ステップＳ５３６においてＹＥＳ）には、受信データが有るかどうかを判断する（ステップＳ５３７）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、受信データがあると判断した場合（ステップＳ５３７においてＹＥＳ）には、メインメモリから当該受信データを削除する（ステップＳ５３８）。

そして、処理を終了する（リターン）。
そして、ステップＳ５３６において、ＣＰＵ３１（データ格納処理部２１０）は、ＮＧ判定でないと判断した場合（ステップＳ５３６においてＮＯ）あるいは、ステップＳ５３７において、受信データが無いと判断した場合（ステップＳ５３７においてＮＯ）には、処理を終了する（リターン）。

再び、図５８を参照して、ＣＰＵ３１（データ格納処理部２１０）は、送信データリストの確認が全て終了したかどうかを判断する（ステップＳ５０６）。具体的には、送信データリストの全てについて確認が終了したかどうかを判断する。

ＣＰＵ３１（データ格納処理部２１０）は、送信データリストの全てについて確認が終了していないと判断した場合（ステップＳ５０６においてＮＯ）には、ステップＳ５０２に戻り、次の送信データリストの１つを抽出して、同様の処理を繰り返す。

ＣＰＵ３１（データ格納処理部２１０）は、送信データリストの全てについて確認が終了したと判断した場合（ステップＳ５０６においてＹＥＳ）には、送信データリストにリストアップされていないアプリケーションに対応する受信データリストを確認する（ステップＳ５０８）。上述したように、自機側の送信データリストには、交換データをゲーム装置３に送信するアプリケーションのみがリストアップされる。したがって、上記処理においては、自機側の送信データリストにリストアップされたアプリケーションの交換データの送受信条件のみが判断されるため、交換データをゲーム装置３から受信のみするアプリケーションについてはリストアップされない。したがって、自機側の送信データリストにリストアップされない、ゲーム装置３から受信のみするアプリケーションについて判断する。

次に、ＣＰＵ３１（データ格納処理部２１０）は、当該受信データリストの１つを抽出する（ステップＳ５１０）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、受信データリストフラグ判定処理を実行する（ステップＳ５１２）。

図６１は、本発明の実施の形態に従う受信データリストフラグ判定処理について説明するフロー図である。

図６１を参照して、ＣＰＵ３１（データ格納処理部２１０）は、送受信条件データを確認する（ステップＳ５７０）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、受信データリストフラグ条件判定処理を実行する（ステップＳ５７２）。

図６２は、本発明の実施の形態に従う受信データリストフラグ条件判定処理のフロー図である。

上述したように、交換データをゲーム装置３から受信のみするアプリについて判断する必要があるため、ゲーム装置３から送信される送信データリストにおいて判断する必要のある送受信条件データは、「１，０」と、「１，１」の２つである。

図６２を参照して、送受信条件データについてまず、センドフラグ，レシーブフラグが「１，０」であるかどうかを判断する（ステップＳ５８０）。すなわち、ゲーム装置３における送受信条件データが送信通信のみであるかどうかを判断する。

ステップＳ５８０において、送受信条件データについてセンドフラグ，レシーブフラグが「１，０」であると判断した場合（ステップＳ５８０においてＹＥＳ）には、受信データリストの受信フラグがＯＫであるかどうかを判断する（ステップＳ５８２）。

ステップＳ５８２において、受信データリストの受信フラグがＯＫであると判断した場合（ステップＳ５８２においてＹＥＳ）には、受信ＯＫ判定とする（ステップＳ５８４）。すなわち、ゲーム装置３における送受信条件データが送信通信のみであり、当該条件が満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５８２において、受信データリストの受信フラグがＯＫでないと判断した場合（ステップＳ５８２においてＮＯ）には、ＮＧ判定とする（ステップＳ５８５）。すなわち、ゲーム装置３における送受信条件データが送信通信のみであり、当該条件が満たされなかったことを意味する。そして、処理を終了する（リターン）。

次に、ステップＳ５８０において、送受信条件データについてセンドフラグ，レシーブフラグが「１，０」でないと判断された場合（ステップＳ５８０においてＮＯ）には、送受信条件データについてセンドフラグ，レシーブフラグが「１，１」であるかどうかを判断する（ステップＳ５８６）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であるかどうかを判断する。

ステップＳ５８６において、送受信条件データについてセンドフラグ，レシーブフラグが「１，１」であると判断した場合（ステップＳ５８６においてＹＥＳ）には、受信データリストの受信フラグがＯＫであるかどうかを判断する（ステップＳ５８７）。

ステップＳ５８７において、受信データリストの受信フラグがＯＫであると判断した場合（ステップＳ５８７においてＹＥＳ）には、受信ＯＫ判定とする（ステップＳ５８８）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であり、受信条件が満たされたことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５８７において、受信データリストの受信フラグがＯＫでないと判断した場合（ステップＳ５８７においてＮＯ）には、ＮＧ判定とする（ステップＳ５８９）。すなわち、送受信条件データが双方向通信（いずれの条件でも通信可）であり、当該条件が満たされなかったことを意味する。そして、処理を終了する（リターン）。

一方、ステップＳ５８６において、送受信条件データについてセンドフラグ，レシーブフラグが「１，１」でないと判断した場合（ステップＳ５８６においてＮＯ）には、処理を終了する（リターン）。

再び、図６１を参照して、ＣＰＵ３１（データ格納処理部２１０）は、受信ＯＫ判定であるかどうかを判断する（ステップＳ５７４）。

ステップＳ５７４において、ＣＰＵ３１（データ格納処理部２１０）は、受信ＯＫ判定である場合（ステップＳ５７４においてＹＥＳ）には、受信データを対応するアプリケーションの受信ＢＯＸに格納する（ステップＳ５７６）。

そして、受信データ判定処理を実行する（ステップＳ５７８）。受信データ判定処理の詳細については後述する。そして、処理を終了する（リターン）。

一方、ステップＳ５７４において、ＣＰＵ３１（データ格納処理部２１０）は、受信ＯＫ判定でないすなわちＮＧ判定であると判断した場合（ステップＳ５７４においてＮＯ）には、処理を終了する（リターン）。

再び、図５８を参照して、ＣＰＵ３１（データ格納処理部２１０）は、受信データリストの確認が全て終了したかどうかを判断する（ステップＳ５１４）。

ステップＳ５１４において、ＣＰＵ３１（データ格納処理部２１０）は、受信データリストの確認が全て終了していないと判断した場合（ステップＳ５１４においてＮＯ）には、ステップＳ５１０に戻り、次の受信データリストの１つを抽出して、同様の処理を繰り返す。

そして、ステップＳ５１４において、ＣＰＵ３１（データ格納処理部２１０）は、受信データリストの確認が全て終了したと判断した場合（ステップＳ５１４においてＹＥＳ）には、送信スロットを削除する（ステップＳ５１６）。そして、処理を終了する（リターン）。

図６３は、本発明の実施の形態に従う送受信実行処理のデータの流れについて説明する別の図である。本例においては、図５２で説明した送信データリストおよび受信データリストに基づく送受信実行処理について説明する。

図６３を参照して、自機側から、ゲーム装置３側にアプリＡの交換データが送信される（シーケンスｓｑ２４０）。当該交換データの送信処理に従い自機側の送信データリストのアプリＡに対応して送信ＯＫフラグが立てられる。また、ゲーム装置３側において、ゲーム装置３側の受信データリストのアプリＡに対応して受信ＯＫフラグが立てられる。

次に、ゲーム装置３側から、自機側にアプリＡの交換データが送信される（シーケンスｓｑ２４２）。当該交換データの送信処理に従いゲーム装置３側の送信データリストのアプリＡに対応して送信ＯＫフラグが立てられる。また、自機側において、受信データリストのアプリＡに対応して受信ＯＫフラグが立てられる。

次に、自機側から、ゲーム装置３側にアプリＢの交換データが送信される（シーケンスｓｑ２４４）。当該交換データの送信処理に従い自機側の送信データリストのアプリＢに対応して送信ＯＫフラグが立てられる。また、ゲーム装置３側において、ゲーム装置３側の受信データリストのアプリＢに対応して受信ＯＫフラグが立てられる。

この後、通信不良により例えば通信が遮断されたものとする。
そして、ゲーム装置３側から、自機側にアプリＢの交換データを送信しようとするが、通信が遮断されて送信できなかったものとする（シーケンスｓｑ２４６）。当該交換データの送信処理に従いゲーム装置３側の送信データリストのアプリＢに対応して送信ＮＧフラグが立てられる。

また、自機側において、受信データリストのアプリＢに対応して受信ＮＧフラグが立てられる。

以降、アプリＤの交換データも送信できないため送信ＮＧフラグが立てられる。また、自機側において、受信データリストのアプリＤに対応して受信ＮＧフラグが立てられる。

すなわち、アプリＡについては通信相手との間での交換データの授受処理が実行され、アプリＢについては中断したものとする。アプリＣ，Ｄについても処理は実行されなかったものとする。

図６４は、本発明の実施の形態に従うデータ格納処理における受信データの受信ＢＯＸへの格納について説明する概念図である。

本例においては、図６３で説明した送受信実行処理の場合について説明する。
図６４を参照して、自機側のアプリＡについては、送受信条件データは「１，１」であり、双方向通信（いずれの条件でも通信可）が設定されている。そして、送信データリストおよび受信データリストについては、送信ＯＫフラグおよび受信ＯＫフラグが立てられているため送受信ＯＫ判定となる。したがって、送受信ＯＫ判定であるため受信データがアプリＡに対応付けられて設けられた受信ＢＯＸに格納される。

一方、自機側のアプリＢについては、送受信条件データは「０，０」であり、双方向通信（交換通信）のみに設定されている。そして、送信データリストおよび受信データリストについては、送信ＯＫフラグおよび受信ＮＧフラグが立てられているためＮＧ判定となる。したがって、ＮＧ判定であるため交換不成立として処理を終了する。なお、自機側のアプリＢについては受信できていないためメインメモリから受信データは削除されない。

なお、アプリＣ，Ｄについても同様の方式に従ってＮＧ判定となり、通信不成立として処理を終了する。

ゲーム装置３側のアプリＡについては、送受信条件データは「１，１」であり、双方向通信（いずれの条件でも通信可）が設定されている。そして、送信データリストおよび受信データリストについては、送信ＯＫフラグおよび受信ＯＫフラグが立てられているため送受信ＯＫ判定となる。したがって、送受信ＯＫ判定であるため受信データがアプリＡに対応付けられて設けられた受信ＢＯＸに格納される。

一方、ゲーム装置３側のアプリＢについては、送受信条件データは「０，０」であり、双方向通信（交換通信）のみに設定されている。そして、送信データリストおよび受信データリストについては、送信ＮＧフラグおよび受信ＯＫフラグが立てられているためＮＧ判定となる。したがって、ＮＧ判定であり、交換不成立として処理を終了する。なお、ゲーム装置３のアプリＢについてはメインメモリに受信データが格納されている。したがって、メインメモリから受信データが削除されて、アプリＢに対応付けられて設けられた受信ＢＯＸには格納されない。

したがって、自機側およびゲーム装置３側においても、アプリＡについては、送受信条件データを満たすため送受信が成功として処理される。したがって、通信が途中で遮断された場合であっても、送受信条件データを確認して、通信が成功したと判断される場合には、当該処理は有効とすることが可能であるため適切にデータの授受を実行することが可能となる。

一方、アプリＢについては、自機側およびゲーム装置３側において、送受信条件データを満たさないため通信エラーとして処理される。すなわち、通信が途中で遮断されて受信データのみ受信される、あるいは送信データのみが送信されるような場合であっても通信エラーを適切に判断して、当該処理は無効とすることが可能であるため適切にデータの授受を実行することが可能となる。

アプリＣ，Ｄについても同様である。
図６５は、本発明の実施の形態に従うデータ格納処理における交換データの送信回数の更新および配列の変更について説明する概念図である。

図６５を参照して、ここでは、送信ＢＯＸに４つのデータが格納されている場合が示されている。なお、説明を簡易にするためここでは、送信ＢＯＸに格納されている交換データのデータ構造として、ＩＤデータＩＤＤ０、データグループＩＤＩＤＤ１、送信回数ＩＤＤ７と、データ本体ＩＤＤ１０とが示されている。なお、本例においては、２回のデータ送信の送信スロットおよび送信ＢＯＸのデータの流れについて説明する。図６５（Ａ）および（Ｂ）は、１回目のデータ送信である。図６５（Ｃ）および（Ｄ）は、２回目のデータ送信である。

上述した処理に従い、まず、図６５（Ａ）に示されるように、送信ＢＯＸの先頭（左端）のデータが確認されて、１つ目のデータが送信スロットに格納された場合が示されている。なお、１つ目のデータの送信回数は２回に設定されている。なお、データの送信回数は、図９の通信条件設定処理（ステップＳ７）で設定されたものである。

そして、上述した処理に従い、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているかどうかが判断され、同一のデータグループＩＤのデータは送信ＢＯＸに格納されていないため送信スロットの作成は完了する。

そして、図６５（Ｂ）に示されるように、送信スロットに格納された交換データが送信された後、データ格納処理により、送信ＢＯＸの先頭のデータが送信ＢＯＸの最後尾に配置される場合が示されている。そして、送信回数は２回から１回に更新される。

図６５（Ｃ）は、２回目のデータ送信の際に、送信ＢＯＸの先頭（左端）のデータが確認されて、１つ目のデータが送信スロットに格納され、そして、上述した処理に従い、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているかどうかが判断され、同一のデータグループＩＤのデータが送信ＢＯＸに格納されているため、３つ目のデータがさらに送信スロットに格納されて、送信スロットの作成は完了する。なお、１つ目および３つ目のデータの送信回数は１回に設定されている。

そして、図６３（Ｄ）に示されるように、送信スロットに格納された交換データが送信された後、データ格納処理により、送信ＢＯＸの先頭の１つ目のデータおよび３つ目のデータが送信ＢＯＸの最後尾に配置される場合が示されている。そして、送信回数は１回から０回に更新される。

したがって、送信ＢＯＸに配置されたデータが順番に送信されることになり、同じ交換データが送信されることを抑制して、交換データの送受信の興趣性が増す。

（データ伝播処理）
次に、本発明の実施の形態に従うデータの伝播の方式について説明する。

図６６は、本発明の実施の形態に従う受信データ判定処理のフロー図である。
図６６を参照して、ＣＰＵ３１（データ格納処理部２１０）は、受信データを受信ＢＯＸに格納した後、当該格納した受信データの伝播回数を確認する（ステップＳ５９０）。

次に、ＣＰＵ３１（データ格納処理部２１０）は、伝播条件を満たしているか、本例においては、伝播回数が０より大きいかどうかを判断する（ステップＳ５９２）。

ステップＳ５９２において、ＣＰＵ３１（データ格納処理部２１０）は、伝播条件を満たしている場合、すなわち、本例においては、伝播回数が０より大きいと判断した場合（ステップＳ５９２においてＹＥＳ）には、伝播回数を更新する（ステップＳ５９３）。具体的には、伝播回数を１減算する。例えば、伝播回数が１回である場合には、当該伝播回数は０回に更新される。当該伝播回数は、受信データが伝播される回数を意味する。したがって、伝播回数が０回となった場合には、当該伝播回数の受信データを受信したゲーム装置は、他のゲーム装置の当該受信データを伝播（送信）しない。

そして、次に、ＣＰＵ３１（データ格納処理部２１０）は、伝播条件を満たしていると判断した場合には、伝播回数を更新した受信データをコピーして、送信ＢＯＸに格納する（ステップＳ５９４）。そして、処理を終了する（リターン）。

一方、ステップＳ５９２において、ＣＰＵ３１（データ格納処理部２１０）は、伝播条件を満たしていないと判断した場合、すなわち、伝播回数が０より大きくないと判断した場合（ステップＳ５９２においてＮＯ）には、ステップＳ５９３，５９４の処理をスキップして処理を終了する（リターン）。

すなわち、伝播条件を満たしている（伝播回数が０より大きい値が設定された）受信データを受信した場合には、当該受信データがコピーされて送信ＢＯＸに格納されることになる。すなわち、送信ＢＯＸに格納されて送信スロットに格納されることになるため、ユーザが意識することなく当該受信データが自動的に別のゲーム装置にさらに送信されることになる。

なお、本例においては、一例として、受信データを受信ＢＯＸに格納した後、当該格納した受信データの伝播回数を確認して、伝播条件を満たしているか否かに基づいて送信ＢＯＸに格納する場合について説明するが、受信ＢＯＸに格納する前に当該受信データの判定処理を実行するようにしても良い。具体的には、ステップＳ５７８の受信データ判定処理をステップＳ５７４とステップＳ５７６との間において実行するようにしても良い。

図６７は、本発明の実施の形態に従う伝播条件を満たしている受信データの流れについて説明する図である。

図６７を参照して、メインメモリに一時的に格納された受信データは、対応するアプリケーションＡに対して設けられた受信ＢＯＸに格納される。そして、上記の図６６の処理に従い受信データの伝播回数が確認される。本例においては、受信データの伝播回数は０より大きいものとする。したがって、当該受信データがコピーされて、対応するアプリケーションに設けられた送信ＢＯＸに格納される。本例においては、アプリＡの受信データが受信ＢＯＸと、送信ＢＯＸに格納される場合が示されている。

図６８は、本発明の実施の形態に従う伝播回数が０より大きい交換データが送信ＢＯＸに格納されている場合の処理について説明する概念図である。

図６８を参照して、ここでは、送信ＢＯＸに１つのデータが格納されている場合が示されている。なお、説明を簡易にするためここでは、送信ＢＯＸに格納されている交換データのデータ構造として、ＩＤデータＩＤＤ０、データグループＩＤＩＤＤ１、送信回数ＩＤＤ７と、伝播回数ＩＤＤ８と、データ本体ＩＤＤ１０とが示されている。なお、本例においては、図６８（Ａ）および（Ｂ）は、自機における処理である。図６８（Ｃ）および（Ｄ）は、ゲーム装置３等の他機における処理である。

上述した処理に従い、まず、図６８（Ａ）に示されるように、送信ＢＯＸの先頭（左端）のデータが確認されて、１つ目のデータが送信スロットに格納された場合が示されている。なお、１つ目のデータの送信回数は１回、伝播回数は２回に設定されている。なお、データの送信回数および伝播回数は、図９の通信条件設定処理（ステップＳ７）で設定されたものである。また、当該通信条件設定処理において、伝播回数が０より大きい場合には、送信回数は１より大きい数には設定できないものとする。

そして、図６８（Ｂ）に示されるように、送信スロットに格納された交換データが送信された後、データ格納処理により、送信ＢＯＸの先頭のデータが送信ＢＯＸの最後尾に配置される場合が示されている。そして、送信回数は１回から０回に更新される。したがって、当該データは送信回数が０回であるため、送信ＢＯＸから送信スロットにコピーされて格納されることはない。

図６８（Ｃ）は、例えば、ゲーム装置３等の他機において、自機から送信された受信データを受信して、受信ＢＯＸに格納した場合が示されている。

そして、受信ＢＯＸにおいて、伝播回数が確認され、伝播回数が２回であるため伝播回数を１回に更新して、送信ＢＯＸにコピーして格納した場合が示されている。

図６８（Ｄ）は、ゲーム装置３等の他機において、送信ＢＯＸに格納された伝播回数が１回のデータが再び、送信スロットに格納された場合が示されている。

そして、図６８（Ｅ）に示されるように、ゲーム装置３等の他機において、送信スロットに格納された交換データが送信された後、データ格納処理により、送信ＢＯＸの先頭のデータが送信ＢＯＸの最後尾に配置される場合が示されている。そして、送信回数は１回から０回に更新される。したがって、当該データは送信回数が０回であるため、送信ＢＯＸから送信スロットにコピーされて格納されることはない。当該処理が交換データが伝播される毎に各ゲーム装置で行われることになる。

図６９は、本発明の実施の形態に従う交換データの伝播の概念図について説明する図である。

図６９を参照して、本例においては、自機１と、ゲーム装置２〜４とがそれぞれ設けられている場合が示されている。

本例においては、交換データが伝播されるため伝播データとして説明する。例えば、当該伝播データの伝播回数は自機１で設定されたものとする。なお、送信回数は１回に設定されているものとする。

自機１から伝播回数が２に設定された伝播データは、ゲーム装置３に送信される。そして、ゲーム装置３から伝播回数が１に設定された伝播データがゲーム装置２に送信される。そして、ゲーム装置２から伝播回数が０に設定された伝播データがゲーム装置４に送信される。

したがって、自機１からゲーム装置３に送信された伝播データ（伝播回数２回）は、ゲーム装置３から他のゲーム装置を介して２回伝播されることになる。

したがって、交換データが伝播される回数を設定することができ、交換データの送受信の興趣性が増す。

さらに、伝播回数を設定することにより、無制限に交換データが伝播されることを抑制することが可能となり、交換データを送信する送信者の意図を反映したデータ通信が可能となる。さらに、伝播回数を設定することにより無制限に交換データが伝播されることを抑制して、通信トラフィック量を減らすことが可能となる。

＜ＭＡＣアドレス保存処理＞
図７０は、本実施の形態に従うＭＡＣアドレス保存処理のフロー図である。

図７０を参照して、ＣＰＵ３１（装置識別情報登録処理部２１１）は、受信データ保存領域８２の各受信ＢＯＸの少なくとも１つに変更があったかどうかを判断する（ステップＳ６００）。

ステップＳ６００において、ＣＰＵ３１（装置識別情報登録処理部２１１）は、受信データ保存領域８２の各受信ＢＯＸの少なくとも１つに変更がなかったと判断した場合（ステップＳ６００においてＮＯ）には、次に、交換データ保存領域８０の各送信ＢＯＸの少なくとも１つに変更があったかどうかを判断する（ステップＳ６０２）。

そして、ステップＳ６００において、ＣＰＵ３１（装置識別情報登録処理部２１１）は、受信データ保存領域８２の各受信ＢＯＸの少なくとも１つに変更があったと判断した場合（ステップＳ６００においてＹＥＳ）あるいは、交換データ保存領域８０の各送信ＢＯＸの少なくとも１つに変更があったと判断した場合（ステップＳ６０２においてＹＥＳ）には、保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８に、通信相手を識別するＭＡＣアドレスを保存する（ステップＳ６０４）。当該ＭＡＣアドレスリスト保存領域８８に保存されたＭＡＣアドレスがＭＡＣアドレスリストの一部に含められ上述した通信設定処理で用いられることになる。

一方、ステップＳ６０２において、ＣＰＵ３１（装置識別情報登録処理部２１１）は、受信ＢＯＸおよび送信ＢＯＸのいずれにも変更が無かったと判断した場合（ステップＳ６００においてＮＯ）には、通信相手を識別するＭＡＣアドレスを保存することなく、処理を終了する（リターン）。したがって、この場合には、交換データを適切に取得することができなかったためＭＡＣアドレスリスト保存領域７０にＭＡＣアドレスを保存されない。したがって、再度、携帯端末間通信に従って上述した処理を実行して、交換データのデータ授受処理を再開することが可能である。

なお、本例においては、少なくとも１つの受信ＢＯＸあるいは送信ＢＯＸに変更が有った場合には、すなわち、通信相手との間での少なくとも１つの交換データの授受処理（通信処理）を実行した場合には、ＣＰＵ３１（装置識別情報登録処理部２１１）が保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８に、通信相手を識別するＭＡＣアドレスを保存（登録）する場合について説明するが、上述したように通信が途中で遮断されて通信エラーとなる場合もあるため、通信エラーとならずに通信処理が完全（適切）に終了した場合（送信完了フラグオンおよび受信完了フラグオンの場合等）に、ＭＡＣアドレスを登録するようにするようにしても良い。

そして、通信設定処理により、ＭＡＣアドレスリスト保存領域７０にＭＡＣアドレスリストが保存されるため、上述したＭＡＣアドレスフィルタリング処理により、同じゲーム装置との間で何度も通信することを防止することができ、効率的かつ効果的なデータ通信を実行することが可能である。

なお、本例においては、本体側の保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８に保存されたＭＡＣアドレスリストと、無線通信モジュール３８のＭＡＣアドレスリスト保存領域７０に格納されているＭＡＣアドレスリストは同じであり、ＭＡＣアドレスリスト保存領域７０のみを用いて上記で説明した方式を実現しても良い。

一方で、本体側の保存用データメモリ３４にＭＡＣアドレスリスト保存領域８８を設けて、当該ＭＡＣアドレスリスト保存領域８８にＭＡＣアドレスを保存することにより、無線通信モジュール３８にアクセスしてＭＡＣアドレスリスト保存領域７０のデータを編集するよりも、ＭＡＣアドレスのデータの追加あるいは削除等の編集を容易かつ高速に実行することが可能である。

また、本例においては、受信データ保存領域８２の受信ＢＯＸに交換データが保存された場合に、すなわち、通信相手との間での交換データの授受処理（通信処理）を実行した場合に、ＣＰＵ３１（装置識別情報登録処理部２１１）は、保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８に、一例として、通信相手を識別するＭＡＣアドレスを保存する場合について説明したが、特にこの順序に限られず、例えば、図４０のステップＳ１４２におけるスリープ状態が解除された後、データ授受処理を開始する前に通信相手を識別するＭＡＣアドレスを保存するようにすることも可能である。

すなわち、当該構成においては、無線通信モジュール３８から本体部に通知があった場合、例えばスリープ状態である場合にはスリープ状態が解除された場合に、当該スリープ状態を解除した他のゲーム装置のＭＡＣアドレスが装置識別情報登録処理部２１１によりＭＡＣアドレスリスト保存領域８８に保存されることになる。上述した処理により、一度、本体部に通知があった、すなわちスリープ状態である場合にスリープ状態を解除した通信相手との通信を行わずに効率的なデータ通信を実行することが可能である。

なお、当該構成においては、本体部に通知があった、すなわちスリープ状態である場合にスリープ状態を解除したことを条件（登録条件）として、ＣＰＵ３１（装置識別情報登録処理部２１１）が保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８に、通信相手を識別するＭＡＣアドレスを保存（登録）する場合について説明したが、当該本体部に通知があった、すなわちスリープ状態である場合にスリープ状態を解除したことのみをＭＡＣアドレスを登録する登録条件とする場合に限られず、当該スリープ状態を解除した上でさらに他の条件の判定処理を実行した上で、当該他の条件の判定処理を満たす場合に、ＭＡＣアドレスを登録するようにするようにしても良い。

＜データ通知処理＞
図７１は、本発明の実施の形態に従うデータ通知処理について説明するフロー図である。当該データ通知処理は、一例として上述したシステムプログラム保存領域８６に格納されている本体機能プログラムをＣＰＵ３１が実行することにより実現されるものである。

図７１を参照して、ＣＰＵ３１（データ通知処理部２１２）は、受信データ保存領域８２の受信ＢＯＸに交換データが格納されたかどうかを判断する（ステップＳ６１０）。

そして、ＣＰＵ３１（データ通知処理部２１２）は、受信データ保存領域８２の受信ＢＯＸに交換データが格納されたと判断した場合（ステップＳ６１０においてＹＥＳ）には、効果音を出力する（ステップＳ６１２）。具体的には、ＣＰＵ３１（データ通知処理部２１２）は、図２で説明したスピーカ４５から予め用意されている効果音を出力するように指示する。そして、次に、ＣＰＵ３１（データ通知処理部２１２）は、交換データの内容を表示する（ステップＳ６１４）。具体的には、ＣＰＵ３１（データ通知処理部２１２）は、交換データが有った旨の表示をＬＣＤ１２に出力するように指示する。そして、処理を終了する（エンド）。なお、交換データがあった旨の表示は、交換データが格納された受信ＢＯＸ毎に表示させても良いし、一覧として、交換データが格納された全ての受信ＢＯＸに対応付けて一度に表示させるようにしても良い。

当該効果音のスピーカ４５からの出力およびＬＣＤ１２への表示によりユーザは、交換データが格納されたことを認知することが可能である。

なお、本例においては、一例としてスピーカ４５からの効果音およびＬＣＤ１２への表示による聴覚および視覚による交換データが授受されたことをユーザに通知する場合について説明したが、いずれか一方でも良い。また、例えば、バイブレーション機能を実行してゲーム装置を振動させて触覚により交換データが授受されたことをユーザに通知するようにしても良い。

そして、当該交換データの格納に伴いユーザは、当該交換データを利用可能なアプリケーションを起動するものとする。そして、当該アプリケーションの起動により交換データ保存領域に格納された交換データが消去されるものとする。

＜交換データ追加および消去処理＞
図７２は、本発明の実施の形態に従う交換データ追加および消去処理のフロー図である。すなわち、図９のステップＳ２２における処理について説明する。

なお、交換データ追加および消去処理は、一例としてメモリカード２６のＲＯＭ２７に格納されているアプリケーションプログラムをＣＰＵ３１が実行することにより実現される。

図７２を参照して、まず、ＣＰＵ３１（交換データ追加および消去処理部２１４）は、受信データ保存領域８２の受信ＢＯＸを確認する（ステップＳ６２０）。

そして、ＣＰＵ３１（交換データ追加および消去処理部２１４）は、データをロードした実行中のアプリケーションのアプリケーションＩＤに対応する交換データが受信データ保存領域８２の対応する受信ＢＯＸに有るかどうかを判断する（ステップＳ６２２）。

そして、次に、ＣＰＵ３１（交換データ追加および消去処理部２１４）は、受信データ保存領域８２の受信ＢＯＸに当該アプリケーションＩＤに対応する交換データが有ると判断した場合には、交換データを取得する（ステップＳ６２４）。

当該処理により取得した交換データを用いたアプリケーションを実行することが可能となる。

このとき、取得した交換データをセーブデータとして、自己のセーブ領域（バックアップＲＡＭ）に転送保存しても良い。また、それに伴い受信データ保存領域８２の受信ＢＯＸに有る交換データを削除することも可能である。

なお、本例においては、交換データが受信データ保存領域８２の受信ＢＯＸに有るかどうかを判断して、受信データ保存領域８２に有る場合には、交換データを取得するとして説明したが、このとき、ユーザに交換データを取得した旨（より好ましくは、取得した交換データの内容）を提示するようにしても良い。さらには、当該交換データを利用するかどうか、ユーザに選択させるようにすることも可能である。

そして、次に、ＣＰＵ３１（交換データ追加および消去処理部２１４）は、交換データ保存領域８０の送信ＢＯＸに格納されたアプリケーションＩＤに対応する交換データを削除する（ステップＳ６２６）。具体的には、送信ＢＯＸの中の最後尾にある送信回数が０のデータを削除するようにすれば良い。

このとき、自己のセーブ領域（バックアップＲＡＭ）にあるセーブデータとして格納されている交換データを削除することも可能である。

当該処理により交換データ保存領域８０の送信ＢＯＸに格納されたアプリケーションＩＤに対応する交換データが削除されることにより交換データの交換処理が完了することになる。

そして、次に、ＣＰＵ３１（交換データ追加および消去処理部２１４）は、交換データ保存領域８０に格納された交換データを削除したためバックアップＲＡＭ２８に格納されていた交換フラグデータを消去する（ステップＳ６２８）。

そして、処理を終了する（リターン）。
そして、図９で説明したようにステップＳ５に進むことになる。

なお、本例においては、アプリケーションを起動した際に、交換フラグデータの有無に基づいて受信データ保存領域８２の受信ＢＯＸを確認して交換データが有る場合には、当該受信データ保存領域８２の受信ＢＯＸに記憶された交換データを取得して、交換データ保存領域８０の送信ＢＯＸに記憶された交換データを削除する方式について説明したが、当該アプリケーションを起動しない場合においても交換データ保存領域８０の送信ＢＯＸに記憶された交換データを削除するようにしても良い。たとえば、ＣＰＵ３１が受信データ保存領域８２の受信ＢＯＸに他のゲーム装置からの交換データを格納することに応答して、交換データ保存領域８０の送信ＢＯＸに記憶された交換データを削除するように指示することにより実現可能である。

また、本例においては、交換データ保存領域８０の送信ＢＯＸに格納されたアプリケーションＩＤに対応する交換データを消去する場合について説明したが、消去せずにそのまま維持するようにすることも可能である。その場合には、交換データの交換処理ではなく複製データの授受となる。例えば、一例として上記したように送受信条件データがアプリケーションＩＤに含められている場合に、送受信条件データとして受信通信のみが条件として含められている場合に、送信ＢＯＸから消去せずにそのまま維持するように処理するようにしても良い。また、別の場合として、例えば、一例として上記したように送受信条件データがアプリケーションＩＤに含められている場合に、送受信条件データとして双方向通信（いずれの通信でも通信可）が条件として含められている場合に、送信回数が１回以上に設定されているような場合にも、送信ＢＯＸから消去せずにそのまま維持するように処理しても良い。

なお、送信ＢＯＸの中の最後尾にある送信回数が０のデータを削除する点について説明したが、１つに限られず、送信ＢＯＸの中にある送信回数が０のデータを全て削除するようにしても良い。

送信回数が０である場合には、送信ＢＯＸから送信スロットにコピーして格納されることはないため当該処理により送信ＢＯＸを整理することが可能となる。

なお、通信条件設定処理部２０２で設定された伝播回数に従って、ゲーム装置が伝播データを伝播する場合には、送信ＢＯＸに格納されている送信回数が０の伝播データについては自動的には削除しないようにしても良い。伝播データの場合には、ゲーム装置のユーザの意思に係わらず、データを伝播するため、送信ＢＯＸに残しておくことにより、ユーザが何を伝播したかを把握するようにしても良い。あるいは、伝播データの場合には、受信ＢＯＸの伝播データをコピーして、送信ＢＯＸに格納する際に、伝播データの表示に必要なデータのみ記憶させておくようにしても良い。当該場合に、送信回数が０となった伝播データを削除し、記憶しておいた伝播データの表示に必要なデータに基づいて、後述するＢＯＸ表示画面で伝播データに関する情報を表示させるようにしても良い。

＜通信条件設定処理＞
図７３は、本発明の実施の形態に従う通信条件設定処理のフロー図である。すなわち、図９のステップＳ７における処理について説明する。

なお、通信条件設定処理は、一例としてメモリカード２６のＲＯＭ２７に格納されているアプリケーションプログラムをＣＰＵ３１が実行することにより実現される。

図７３を参照して、まず、ＣＰＵ３１（通信条件設定処理部２０２）は、設定画面を表示する（ステップＳ６３０）。

図７４は、本発明の実施の形態に従う通信条件設定画面を説明する図である。
図７４を参照して、ＬＣＤ１２に表示された通信条件設定画面１０００には、「交換データの送信回数を設定して下さい」の表示とともに、送信回数を表示する表示欄１００２と、送信回数ＵＰ／ＤＯＷＮボタン１００４とが設けられている場合が示されている。また、「交換データの伝播回数を設定して下さい」の表示とともに、伝播回数を表示する表示欄１００６と、伝播回数ＵＰ／ＤＯＷＮボタン１００８とが設けられている場合が示されている。また、「ＯＫ」ボタン１０１０が設けられている。送信回数ＵＰ／ＤＯＷＮボタン１００４を操作することにより送信回数がインクリメントあるいはデクリメントされて回数を設定することが可能となる。また、伝播回数ＵＰ／ＤＯＷＮボタン１００８を操作することにより伝播回数がインクリメントあるいはデクリメントされて回数を設定することが可能となる。そして、「ＯＫ」ボタン１０１０を押下することにより表示された内容を確定することが可能となる。本例においては、一例として送信回数１回、伝播回数１回が設定されている場合が示されている。なお、送信回数が１回、伝播回数が１回の交換データの場合には、上述したように相手に送信された交換データが受信ＢＯＸに格納され、そして、送信ＢＯＸにも格納されて、さらに他のゲーム装置に送信される。

なお、伝播回数が１より大きい場合には、送信回数は１より大きい値に設定できないように設定される。仮に送信回数が２回以上である場合には、伝播回数との組み合わせにより、交換データの伝播が送信者の意図を越えた範囲にまで拡大する可能性があるからである。

再び、図７３を参照して、ＣＰＵ３１（通信条件設定処理部２０２）は、設定画面において設定指示の入力があったかどうかを判断する（ステップＳ６３２）。具体的には、「ＯＫ」ボタンの押下があったかどうかが判断される。

そして、次に、ＣＰＵ３１（通信条件設定処理部２０２）は、ステップＳ６３２において、設定指示の入力が有ったと判断した場合（ステップＳ６３２においてＹＥＳ）には、指示された内容に従い交換データの送信回数および伝播回数が設定される（ステップＳ６３４）。そして、処理を終了する（リターン）。すなわち、図９で説明したステップＳ８に進むことになる。

なお、本例においては、図９のステップＳ６からの交換データの指定入力が有った場合に、図７３で説明した通信条件設定処理が実行される場合について説明した。すなわち、ユーザが任意に通信条件設定画面１０００で伝播回数および送信回数を設定可能である場合について説明したが、伝播回数および送信回数をアプリケーションの実行処理により自動的に設定するようにしても良い。具体的には、交換データ登録イベントが発生した場合において、交換データの種類に従って、ユーザが送信回数および伝播回数を任意に設定できるようにしたり、あるいは、アプリケーションが自動的に設定したりすれば良い。

＜ＢＯＸアクセス処理＞
図７５は、本発明の実施の形態に従うＢＯＸアクセス処理のフロー図である。すなわち、図９のステップＳ２６における処理について説明する。

なお、ＢＯＸアクセス処理は、一例としてメモリカード２６のＲＯＭ２７に格納されているアプリケーションプログラムをＣＰＵ３１が実行することにより実現される。

図７５を参照して、ＢＯＸ確認の指定入力が有った場合には、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、交換データ保存領域８０および受信データ保存領域８２の送信ＢＯＸおよび受信ＢＯＸの探索処理を実行する（ステップＳ６４０）。

図７６は、本発明の実施の形態に従うＢＯＸ探索処理を説明するフロー図である。
図７６を参照して、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、まず、アプリケーションアクセス権限を確認する（ステップＳ６５０）。具体的には、アプリケーションの実行により指示された保存用データメモリ３４に格納されたＢＯＸの確認の指定入力（コマンド）の中に特定のアプリケーションを識別するデータではなく、特殊コマンドが含まれているかどうかを確認する。例えば、アプリケーションプログラムがシステムプログラム保存領域８６に格納された情報を管理する管理プログラムであるような場合には、特殊コマンドが含まれるものとする。

そして、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、特殊コマンドが有るかどうかを判断する（ステップＳ６５２）。

ステップＳ６５２において、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、特殊コマンドが有ると判断した場合（ステップＳ６５２においてＹＥＳ）には、全ＢＯＸを探索する（ステップＳ６６２）。

そして、次に、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、探索した全ＢＯＸを抽出する（ステップＳ６６４）。そして、処理を終了する（リターン）。

一方、ステップＳ６５２において、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、特殊コマンドがないと判断した場合（ステップＳ６５２においてＮＯ）には、アプリケーションＩＤに対応するＢＯＸを探索する（ステップＳ６５４）。

そして、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、対応するアプリケーションＩＤの送信ＢＯＸおよび受信ＢＯＸを抽出する（ステップＳ６５８）。そして、処理を終了する（リターン）。

再び、図７５を参照して、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、抽出した送信ＢＯＸおよび受信ＢＯＸを表示する処理を実行する（ステップＳ６４４）。具体的には、ＬＣＤ１２に抽出したＢＯＸを表示する。そして、次に、ステップＳ６４６において、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、ＢＯＸ表示終了の指定入力が有るかどうかを判断する（ステップＳ６４６）。ステップＳ６４６において、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、ＢＯＸ表示終了の指定入力が有ると判断した場合（ステップＳ６４６においてＹＥＳ）には、処理を終了する（リターン）。一方、ステップＳ６４６において、ＣＰＵ３１（ＢＯＸアクセス処理部２１５）は、ＢＯＸ表示終了の指定入力がないと判断した場合（ステップＳ６４６においてＮＯ）には、ステップＳ６４４に戻る。

図７７は、本発明の実施の形態に従うＢＯＸ表示画面を説明する図である。
図７７（Ａ）を参照して、本例のＢＯＸ表示画面１１００においては、対応するアプリケーションＩＤに対応する送信ＢＯＸ１１０２および受信ＢＯＸ１１０４が表示されている場合が示されている。また、「終了」ボタン１１０６が設けられており、当該「終了」ボタン１１０６を押下することにより当該ＢＯＸの表示処理を終了させることが可能となる。

図７７（Ｂ）を参照して、本例のＢＯＸ表示画面１１１０においては、抽出された全ＢＯＸが表示されている場合が示されている。ここで、各アプリケーション毎に表示領域１１１２が設けられ、当該表示領域内に送信ＢＯＸおよび受信ＢＯＸが表示されている場合が示されている。また、「終了」ボタン１１１４が設けられており、当該「終了」ボタン１１１４を押下することにより当該ＢＯＸの表示処理を終了させることが可能となる。

したがって、当該処理により、ユーザは、対応するアプリケーションＩＤに対応する送信ＢＯＸおよび受信ＢＯＸに格納されたデータを確認することが可能となる。

なお、特殊なコマンドは、アプリケーションプログラムがシステムプログラム保存領域８６に格納された情報を管理する管理プログラムである場合に限られず、他のアプリケーションプログラムを実行した場合に、ＢＯＸの確認の指定入力（コマンド）の中に含められるようにすることも可能である。

なお、一般的には、コマンドの中に特定のアプリケーションを識別するデータを含めて、当該特定のアプリケーションに対応する送信ＢＯＸおよび受信ＢＯＸのみ探索して情報を取得する処理が行われるが、当該特殊コマンドを用いることにより、全ての送信ＢＯＸおよび受信ＢＯＸを探索して情報を取得する処理が実行可能であるため当該特殊コマンドを用いた高度なゲーム装置１に対するアクセスが可能となる。例えば、当該特殊コマンドを用いて、固定端末機器から保存用データメモリ３４に格納されている送信ＢＯＸおよび受信ＢＯＸに直接アクセスするようにしても良い。

＜通信相手のサーチ処理＞
次に、図７８〜図８１を参照して、前述のステップＳ５２（図１８）の通信相手サーチ処理について説明する。

この処理では、ゲーム装置１は、親機または子機として他のゲーム装置との間で通信可能な相手を探索する交換相手探索処理を実行する。

ゲーム装置１は、通信可能範囲１０に存在する他のゲーム装置をサーチすべく、上述した送信無線フレームとして接続要求信号を宛先を特定せずに繰り返し送信する（本実施例においては、接続要求信号を定期的に繰り返し送信する方式について説明するが、いわゆるプローブリクエストによる方式等を採用することも可能である）。

本例においては、子機側のゲーム装置から送信無線フレームとして接続要求信号を送信するものとする。そして、親機側のゲーム装置は、子機側から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信するまで待機し、受信した場合には、これに応答して、子機側のゲーム装置に対して親機側から送信無線フレームである接続応答信号を送信する。

この接続要求信号および接続応答信号の送受信により、親機および子機としてのゲーム装置間においてデータ通信が可能となる。なお、本例においては、子機側のゲーム装置から接続要求信号を送信し、親機側のゲーム装置は、接続応答信号を送信する場合について説明するが、親機と子機との関係を入れ替えるようにしても良い。

このような通信相手サーチ処理では、各ゲーム装置１は、親機として動作して子機からのサーチを受ける処理と、子機として動作して親機をサーチする処理とを交互に繰り返す。

図７８は、本発明の実施の形態に従う通信相手サーチ処理の１周期の期間について説明する図である。

具体的には、所定の期間（図７８のＴｃｙｃｌｅ）を１周期として、各周期の一部を子機として動作する期間（図７８のＴｓｐ）とし、残りを親機として動作する期間（Ｔｓｃ）とする。ここで、子機として動作中のゲーム装置と親機として動作中のゲーム装置との間で接続可能であり、子機として動作中のゲーム装置と子機として動作中のゲーム装置、および、親機として動作中のゲーム装置と親機として動作中のゲーム装置は、接続不可能である。

ゆえに、子機として動作する期間と親機として動作する期間を固定的にした場合、偶然にそれらの期間が一致している２つのゲーム装置においてデータ通信が不可能になる。

このようなことを防ぐため、１周期における子機として動作する期間と親機として動作する期間の配分または配置をランダムに変えるようにしてある。

配分をランダムに変える方式が図７８（Ａ）に示すような「通信相手サーチ処理（１）」であり、配置をランダムに変える方式が図７８（Ｂ）に示すような「通信相手サーチ処理（２）」である。

図７８（Ａ）を参照して、通信相手サーチ処理（１）は、上述したように、ＴｓｐおよびＴｓｃの配分がランダムに決定される。この処理（１サイクル）の期間を固定値のＴｃｙｃｌｅ（たとえば、４秒）とし、Ｔｓｃの長さは０からＴｃｙｃｌｅの間のランダム値に決定され、Ｔｓｐの長さはＴｃｙｃｌｅの残りの期間（Ｔｃｙｃｌｅ−Ｔｓｃ）に決まる。また、ＴｓｃおよびＴｓｐが、この順番でＴｃｙｃｌｅに設定される。Ｔｓｃの長さは毎回ランダムに決定されるため、Ｔｓｐの長さもランダムに決定される。これにより、通信可能範囲１０に存在する他のゲーム装置との間でデータ通信を実行することができない状態を回避するようにしてある。ただし、Ｔｓｐが短くなり過ぎると、他のゲーム装置を正確にサーチすることができず、他のゲーム装置との間でデータ通信を実行することができない場合があるため、Ｔｓｐについての必要最小限の期間を決定しておき、これを確保できない場合には、再度Ｔｓｃを決定し直すようにしてもよい。

なお、この実施例では、Ｔｓｃ、Ｔｓｐの順でＴｃｙｃｌｅを設定するようにしてあるが、逆の順番で設定するようにしてもよい。

図７８（Ｂ）を参照して、通信相手サーチ処理（２）は、上述したように、ＴｓｐやＴｓｃの配置がランダムに決定される。言い換えると、Ｔｓｐの長さを固定値として、Ｔｃｙｃｌｅ内におけるＴｓｐの開始位置をランダムに設定する。具体的に説明すると、図７８（Ｂ）に示すように、通信相手サーチ処理（２）では、Ｔｃｙｃｌｅ（この実施例では、固定値であり、４秒に設定される。）には、固定値で決定されるＴｓｐおよびこのＴｓｐを間に挟むようにランダムに決定されるＴｓｃ１およびＴｓｃ２が設けられる。つまり、Ｔｃｙｃｌｅには、Ｔｓｃ１、ＴｓｐおよびＴｓｃ２がこの順で設けられる。また、Ｔｓｃ１の長さは０から（Ｔｃｙｃｌｅ−Ｔｓｐ）の間でランダムに決定され、Ｔｓｃ２の長さは、Ｔｃｙｃｌｅからランダムに決定されたＴｓｃ１およびＴｓｐを減算して決定される。

なお、本実施例では、Ｔｓｃ、Ｔｓｐの順でＴｃｙｃｌｅが設定されるのでＴｓｐの開始位置をランダムにしたが、Ｔｓｐ、Ｔｓｃの順でＴｃｙｃｌｅが設定される場合には、Ｔｓｃの開始時期をランダムに決定すればよい。

通信相手サーチ処理（１）または（２）においては、Ｔｓｐの期間において、ゲーム装置１は、接続要求信号を宛先を特定せずに送信した後、他のゲーム装置３から送信される接続応答信号の受信を試みるという処理を繰り返す。また、Ｔｓｃの期間において、ゲーム装置１は、他のゲーム装置から送信される接続要求信号の受信を試みて、受信に成功した場合には、接続応答信号を送信するという処理を繰り返す。

また、ゲーム装置１は、消費電力の浪費を防止するために、子機として働く期間においては、所定期間（この実施例では、６４ｍｓ）毎に接続要求信号を送信するようにしてある。つまり、間欠的にデータ送信が実行されるのである。

以下、通信相手サーチ処理（１）および通信相手サーチ処理（２）について、フロー図を用いて、それぞれ、具体的に説明することにする。

図７９は、本発明の実施の形態に従う通信相手サーチ処理（１）を示すフロー図である。

図７９を参照して、通信相手サーチ処理（１）を開始すると、ステップＳ２１０で、Ｔｓｃを０からＴｃｙｃｌｅの範囲内でランダムに決定する。図示は省略するが、Ｔｃｙｃｌｅは固定値であるため、Ｔｓｃが決定されると、Ｔｓｐも決定される。

続くステップＳ２１２〜Ｓ２１６，Ｓ２２８，Ｓ２３０が上述のＴｓｃにおいて実行される処理であり、親機として動作して子機をサーチする処理がされる。ステップＳ２１８〜Ｓ２２６，Ｓ２３２が上述のＴｓｐにおいて実行される処理であり、子機として動作して親機をサーチする処理がされる。

ステップＳ２１２では、子機のサーチを開始する。図示は省略するが、このときタイマ回路をスタートする。次にステップＳ２１４で、子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信したかどうかを判断する。

子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信した場合（ステップＳ２１４においてＹＥＳ）には、ステップＳ２２８で、子機に対して送信無線フレームである接続応答信号を送信し、その後、ステップＳ２３０において、親機としての接続フラグをオンして、通信相手サーチ処理（１）をリターンする。つまり、親機として、他のゲーム装置との間で通信接続が可能であることが判明する。

なお、図７９においては省略したが、通信相手サーチ処理（１）が開始されたとき、子機としての接続フラグ（後述する親機としての接続フラグも同じ。）はオフ（リセット）される。

一方、子機からの接続要求信号を全く受信しない場合（ステップＳ２１４においてＮＯ）には、ステップＳ２１６で、子機サーチ時間すなわち親機として他のゲーム装置からの接続が試みられる期間がＴｓｃ秒経過したかどうかを判断する。

ステップＳ２１６において、子機サーチ時間がＴｓｃ秒経過していなければ（ステップＳ２１６においてＮＯ）、そのままステップＳ２１４に戻る。

一方、子機サーチ時間がＴｓｃ秒経過すれば（ステップＳ２１６においてＹＥＳ）、ステップＳ２１８で、親機のサーチを開始し、つまりタイマ回路をリセットおよびスタートし、ステップＳ２２０で、送信無線フレームである接続要求信号を宛先を特定せずに送信する。

続くステップＳ２２２では、親機から送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）を受信したかどうかを判断する。親機から送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）を受信すれば（ステップＳ２２２においてＹＥＳ）であれば、、ステップＳ２３２で、子機としての接続フラグをオンして、通信相手サーチ処理（１）をリターンする。つまり、子機として他のゲーム装置との間で通信接続が可能であることが判明する。

一方、親機から送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）を受信しなければ（ステップＳ２２２においてＮＯ）、ステップＳ２２４で、６４ｍｓ待機し、続くステップＳ２２６で、親機サーチ時間すなわち子機として他のゲーム装置との接続を試みる期間がＴｓｐ秒経過したかどうかを判断する。

親機サーチ時間がＴｓｐ秒経過していなければ（ステップＳ２２６においてＮＯ）、そのままステップＳ２２０に戻る。

一方、親機サーチ時間がＴｓｐ秒経過すれば（ステップＳ２２６においてＹＥＳ）、Ｔｃｙｃｌｅの期間が経過したと判断して、通信相手サーチ処理（１）をリターンする。

ステップＳ２２６で６４ｍｓ待機することにより、ステップＳ２２０において、送信無線フレームである接続要求信号を宛先を特定せずに送信を繰り返す処理が間欠的に行われることになり、消費電力を抑えることができる。

図８０および図８１は、本発明の実施の形態に従う通信相手サーチ処理（２）を示すフロー図である。

図８０を参照して、通信相手サーチ処理（２）を開始すると、ステップＳ２４０で、Ｔｓｃ１を０から（Ｔｃｙｃｌｅ−Ｔｓｐ）の範囲内でランダムに決定する。上述したように、通信相手サーチ処理（２）では、ＴｃｙｃｌｅおよびＴｓｐは固定値であるため、Ｔｓｃ１が決定されると、Ｔｓｃ２も決定される。

続くステップＳ２４２〜Ｓ２４６，Ｓ２５８，Ｓ２６０が上述のＴｓｃ１において実行される処理であり、親機として動作して子機をサーチする処理がされる。ステップＳ２４８〜Ｓ２５６，Ｓ２６２が上述のＴｓｐにおいて実行される処理であり、子機として動作して親機をサーチする処理がされる。さらに、ステップＳ２７０〜Ｓ２７４，Ｓ２７６，Ｓ２７８が上述のＴｓｃ２において実行される処理であり、親機として動作して子機をサーチする処理がされる。

ステップＳ２４２では、子機のサーチを開始する。図示は省略するが、このときタイマ回路をスタートする。次にステップＳ２４４で、子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信したかどうかを判断する。

子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信すれば（ステップＳ２４４においてＹＥＳ）、ステップＳ２５８で、子機に対して親機から送信無線フレームである接続応答信号を送信し、その後、ステップＳ２６０において、親機としての接続フラグをオンして、通信相手サーチ処理（２）をリターンする。つまり、親機として他のゲーム装置との間で通信接続が可能であることが判明する。

なお、図８１においては省略したが、通信相手サーチ処理（２）が開始されたとき、子機としての接続フラグおよび親機としての接続フラグがオフされるのは、通信相手サーチ処理（１）の場合と同じである。

一方、子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を全く受信しない場合（ステップＳ２４４においてＮＯ）には、ステップＳ２４６で、子機サーチ時間すなわち親機として他のゲーム装置から接続を試みられる期間がＴｓｃ１秒経過したかどうかを判断する。

子機サーチ時間がＴｓｃ１秒経過していなければ（ステップＳ２４６においてＮＯ）、そのままステップＳ２４４に戻る。

一方、子機サーチ時間がＴｓｃ１秒経過すれば（ステップＳ２４６においてＹＥＳ）、ステップＳｓ４８で、親機のサーチを開始し、つまりタイマ回路をリセットおよびスタートし、ステップＳ１９７で、送信無線フレームである接続要求信号を宛先を特定せずに送信する。

続くステップＳ２５０では、親機から送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）を受信したかどうかを判断する。親機から送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）を受信すれば（ステップＳ２５２においてＹＥＳ）、ステップＳ２６２で、子機としての接続フラグをオンして、通信相手サーチ処理（２）をリターンする。つまり、子機として他のゲーム装置との間で通信接続が可能であることが判明する。

一方、親機から送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）を受信しなければ（ステップＳ２５２においてＮＯ）、ステップＳ２５４で、６４ｍｓ待機し、続くステップＳ２５６で、親機サーチ時間すなわち子機として他のゲーム装置との接続を試みる期間がＴｓｐ秒経過したかどうかを判断する。

親機サーチ時間がＴｓｐ秒経過していなければ（ステップＳ２５６においてＮＯ）、そのままステップＳ２５０に戻る。

一方、親機サーチ時間がＴｓｐ秒経過すれば（ステップＳ２５６においてＹＥＳ）、図８１に示すステップ２７０で、子機のサーチを開始する。このとき、タイマ回路をリセットおよびスタートする。

次のステップＳ２７２では、子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信したかどうかを判断する。

子機から送信された送信無線フレームである接続要求信号（すなわち受信無線フレーム）を受信すれば（ステップＳ２７２においてＹＥＳ）、ステップＳ２７６で、子機に対して接続応答信号を送信し、その後、ステップＳ２７８において、親機としての接続フラグをオンして、通信相手サーチ処理（２）をリターンする。

一方、子機からの接続要求信号を全く受信しない場合（ステップＳ２７２においてＮＯ）には、ステップＳ２７４で、子機サーチ時間がＴｓｃ２秒経過したかどうかを判断する。

子機サーチ時間がＴｓｃ２秒経過していなければ（ステップＳ２７４においてＮＯ）、そのままステップＳ２７２に戻る。

一方、子機サーチ時間がＴｓｃ２秒経過すれば（ステップＳ２７４においてＹＥＳ）、Ｔｃｙｃｌｅの期間が経過したと判断して、通信相手サーチ処理（２）をリターンする。

図８２は、本発明の実施の形態に従う交換データの授受のデータの遣り取りについて説明する図である。

図８２を参照して、本体側のＣＰＵ３１においてアプリケーションプログラムの実行による交換データが設定される（シーケンスｓｑ２）。そして、本体側のＣＰＵ３１は、無線通信モジュール３８に対して通信設定のためのデータを出力する（シーケンスｓｑ４）。具体的には、交換データのアプリケーションＩＤおよびＭＡＣアドレスリストに関するデータを出力する。そして、当該交換データのアプリケーションＩＤは、フィルタリング用データ保存領域６８に格納され、ＭＡＣアドレスリスト保存領域８８のＭＡＣアドレスリストは、ＭＡＣアドレスリスト保存領域７０に格納される。本例においては、アプリケーションＩＤを各判定方式に対応するリストとして纏めてフィルタリング用データ保存領域６８に保存する。なお、上述したようにＭＡＣアドレスリスト保存領域８８＃のＭＡＣアドレスリストについてもＭＡＣアドレスリスト保存領域７０＃に保存される。

そして、本体側のＣＰＵ３１は、通信開始指示を無線通信モジュール３８に出力する（シーケンスｓｑ６）。

これに伴い通信開始指示に従い無線通信モジュール３８による無線通信が開始される（シーケンスｓｑ８）。そして、本実施例においては、無線通信モジュール３８において交換データを交換する通信相手を探索する交換相手探索処理である携帯端末間通信が開始される。

一方、ゲーム装置３においても、本体側のＣＰＵにおいてアプリケーションプログラムの実行による交換データが設定される（シーケンスｓｑ１４）。そして、本体側のＣＰＵは、無線通信モジュール３８Ｐに対して通信設定のためのデータを出力する（シーケンスｓｑ１６）。具体的には、交換データのアプリケーションＩＤおよびＭＡＣアドレスリストに関するデータを出力する。そして、当該交換データのアプリケーションＩＤのは、フィルタリング用データ保存領域６８Ｐに格納され、ＭＡＣアドレスリストは、ＭＡＣアドレスリスト保存領域７０Ｐに格納される。本例においては、アプリケーションＩＤを各判定方式に対応するリストとして纏めてフィルタリング用データ保存領域６８に保存する。

そして、本体側のＣＰＵ３１は、通信開始指示を無線通信モジュール３８Ｐに出力する（シーケンスｓｑ１８）。

これに伴い通信開始指示に従い無線通信モジュール３８Ｐによる無線通信が開始される（シーケンスｓｑ２０）。そして、上述したのと同様に、携帯端末間通信が開始される。

再び、ゲーム装置１に関して、次に、上述したように携帯端末間通信において、子機サーチが実行される（シーケンスｓｑ２１）。そして、次に、親機サーチが実行される（シーケンスｓｑ２２）。

そして、親機サーチにおいて、ゲーム装置１の無線通信モジュール３８からゲーム装置３の無線通信モジュール３８Ｐに対して接続要求信号が送信されると（シーケンスｓｑ２６）、ゲーム装置３の無線通信モジュール３８Ｐは、ゲーム装置１から送信された送信無線フレーム（すなわち受信無線フレーム）を受け付けて、ゲーム装置１の無線通信モジュール３８に対してゲーム装置３の送信無線フレームである接続応答信号を送信する（シーケンスｓｑ２８）。

そして、無線通信モジュール３８は、無線通信モジュール３８Ｐから送信された送信無線フレームである接続応答信号（すなわち受信無線フレーム）の入力を受け付ける。

当該処理により、上述したように自機であるゲーム装置１については子機としての接続フラグがオンする。また、ゲーム装置３については親機としての接続フラグがオンする。

ゲーム装置１においては、子機としての接続フラグがオンとなることに伴い通信相手である親機と通信接続が可能であるすなわち通信相手を発見したと判断する（シーケンスｓｑ３０）。また、ゲーム装置３においても親機としての接続フラグがオンとなることに伴い通信相手である子機と通信接続が可能であるすなわち通信相手を発見したと判断する（シーケンスｓｑ４２）。

そして、ゲーム装置１においては、通信相手を発見した後、次に、ＭＡＣアドレスを比較する（シーケンスｓｑ３２）。すなわち、通信相手であるゲーム装置３から受信した受信無線フレームに含まれているＭＡＣアドレスが、ＭＡＣアドレスリスト保存領域７０に保存されたＭＡＣアドレスリストと比較して一致するかどうかが判断される。

そして、不一致であると判断された場合、すなわち、未だ通信していない相手である場合には、次にデータ内容を確認する（シーケンスｓｑ３４）。すなわち、受信無線フレームが携帯端末間処理として処理可能な無線フレームであるかどうかを判定する。

そして、携帯端末間処理として処理可能な受信無線フレームを受信したと判定された場合には、アプリケーションＩＤ判定処理を実行する（シーケンスｓｑ３６）。

そして、アプリケーションＩＤ判定処理により一致フラグがオンした場合には、無線通信モジュール３８は、本体側のＣＰＵに対して一致したアプリケーションＩＤに対応する交換データについて、交換が可能なゲーム装置３が発見された旨を通知する（シーケンスｓｑ３８）。

これにより本体側のＣＰＵは、無線通信モジュール３８からの通知によって通信接続が可能な交換相手が発見されたことを認識し、データ授受処理を開始する（シーケンスｓｑ４０）。

一方、同様の処理に従ってゲーム装置３側においても、通信相手を発見した（シーケンスｓｑ４２）後、ＭＡＣアドレスを比較し（シーケンスｓｑ４４）、不一致である場合、すなわち、未だ通信していない相手である場合にはデータ内容を確認し（シーケンスｓｑ４６）、そして、携帯端末間処理として処理可能な受信無線フレームを受信したと判定した場合にはアプリケーションＩＤ判定処理を実行し（シーケンスｓｑ４８）、そして、一致フラグがオンした場合には本体側のＣＰＵに交換が可能なゲーム装置１が発見された旨を通知する（シーケンスｓｑ５０）。

これにより、ゲーム装置３においてもデータ授受処理が開始される（シーケンスｓｑ５２）。

そして、次に、ゲーム装置１の本体側のＣＰＵ３１は、データ授受処理が開始された後、ゲーム装置３との間で通信接続を確立する（シーケンスｓｑ５４）。

同様に、ゲーム装置３の本体側のＣＰＵにおいてもデータ授受処理が開始された後、ゲーム装置１との間で通信接続を確立する（シーケンスｓｑ５６）。

そして、ゲーム装置１は、交換データを送信する（シーケンスｓｑ５８）。当該交換データは、スロットに格納されている交換データをコピーしたコピーデータである。

そして、ゲーム装置３においてゲーム装置１から送信された交換データを受信して、当該交換データを格納する（シーケンスｓｑ６０）。

そして、ゲーム装置３において、交換データを送信する（シーケンスｓｑ６２）。当該交換データは、スロットに格納されている交換データをコピーしたコピーデータである。

そして、ゲーム装置１においては、ゲーム装置３から送信された交換データを受信して、当該交換データを格納する（シーケンスｓｑ６４）。

そして、通信を切断する（シーケンスｓｑ６６）。
そして、データ格納処理を実行する（シーケンスｓｑ６７）。
そして、ＭＡＣアドレスを登録する（シーケンスｓｑ６７）。

そして、データ通知処理を実行する（シーケンスｓｑ６８）。
同様に、ゲーム装置３においても、交換データを格納した後、通信を切断する（シーケンスｓｑ７０）。そして、データ格納処理を実行する（シーケンスｓｑ７１）。そして、ＭＡＣアドレスを登録し（シーケンスｓｑ７２）、データ通知処理を実行する（シーケンスｓｑ７２）。

そして、上述したように交換データの通知を受けて、ユーザが当該交換データを利用するアプリケーションを実行することにより上記で説明したスロットに格納されている交換データの消去処理が実行されて交換データの交換処理が完了する。

なお、上記シーケンスにおいて、シーケンスｓｑ４，ｓｑ６，ｓｑ１６，ｓｑ１８，ｓｑ４０，ｓｑ５２〜ｓｑ７２は、それぞれのゲーム装置において、一例として、上述したように本体側の機能でありシステムプログラム保存領域８６に格納された本体機能プログラムにより実現されるものである。一方、シーケンスｓｑ８，ｓｑ２０〜ｓｑ３８，ｓｑ４２〜ｓｑ５０は、一例として、上述したように、それぞれのゲーム装置において、無線通信モジュール３８におけるメモリ制御部６４に格納されているＲＯＭ７２から読出されたプログラムにより実現されるものである。

この無線通信により、所定のアプリケーションで利用される交換データを、当該アプリケーションを実行していない時でも、通信接続が確立するゲーム装置との間で自動で交換することができるので、知人との間で交換データの交渉をする機会が増す。また、無線通信により、本体側のＣＰＵ３１で実行されるアプリケーションの有無に関わらず、所定のアプリケーションで利用される交換データを、当該アプリケーションを実行していない時でも、通信接続が確立するゲーム装置との間で自動で交換することができるので、当該アプリケーションを格納しているメモリカード２６を装着している必要は無く、利便性が高く、また、何が交換されるかが分からないため興趣性が増す。また、交換する相手が知人に限定されないため、人が集まる場所に出かければ、交換データを交換することができる可能性が高くなり、交換の楽しさを増大させることができる。つまり、交換データを利用するアプリケーションの興趣性を向上させることができる。また、まず、無線通信モジュール間のみでの通信処理を実行して交換可能であると判断した場合に、初めて本体側のＣＰＵに通知して交換データの授受処理を実行するためＣＰＵの処理負荷を軽減することが可能であるとともに消費電量を低減することが可能である。

そして、当該交換データの授受処理が実行された後、再び、無線通信モジュール３８における交換相手探索処理が開始される。

具体的には、交換データの授受処理により交換データ保存領域８０の内容が変更されることになる。したがって、図１４で説明したフローに従って、ＣＰＵ３１（通信設定処理部２０４）は、通信設定処理（ステップＳ２８）を実行する。通信設定処理の詳細については図１５で説明したので繰り返さない。そして、次に、ＣＰＵ３１（通信指示処理部２０６）は、通信開始指示を無線通信モジュール３８に出力する（ステップＳ２９）。

これにより再び、図１７のステップＳ４４で説明したように無線通信モジュール３８において携帯端末間通信が開始される（ステップＳ４４）。携帯端末間通信の詳細については図１８で説明したとおりである。

図２３で説明したように携帯端末間通信においては、ＭＡＣアドレスが一致する他のゲーム装置（本例においてはゲーム装置３）との再度の通信処理を行わないＭＡＣアドレスフィルタリング処理が実行される。

すなわち、ＭＡＣアドレスリストに登録されている一度通信を行った通信相手であるゲーム装置（本例においてはゲーム装置３）との間では実質的な通信は実行されない。

したがって、本発明の実施の形態に従うゲーム装置においては、通信範囲のゲーム装置を自動的に繰り返して探知し、見つかったゲーム装置を通信候補に設定する。この場合、同じゲーム装置を何度も探知して見つけてしまう可能性があるが、上述のようなＭＡＣアドレスフィルタリング処理により、同じゲーム装置との間で何度も通信することを防止することができ、効率的かつ効果的なデータ通信を実行することが可能である。

＜変形例＞
なお、上記携帯端末間通信においては、送信無線フレームの設定にあたり、ＭＡＣアドレスとともに通信判断条件であるベンダ特定ＩＥデータを送信無線フレームに含めて送信する方式について説明したが、セキュリティを高めるために、まず、ＭＡＣアドレスのみを含めた送信無線フレームを送信し、そして、後に、別の送信無線フレームにベンダ特定ＩＥデータを含めて送受信する方式とすることも可能である。

具体的には、先の送信無線フレームに含まれているＭＡＣアドレスを用いて、上述したＭＡＣアドレスフィルタリング処理を実行することが可能である。

そして、その場合には、図７で説明した無線通信モジュール３８の機能として設けられる交換データ通信判断部２２５の構成としては、装置識別情報比較部２２６のみの構成とする。

当該構成において、装置識別情報比較部２２６におけるＭＡＣアドレスフィルタリング処理においてＭＡＣアドレスが不一致であると判断される場合に本体側に通知するようにしても良い。

そして、上述した通信接続確立後に別の送信無線フレームを送受信して、一例として、本体機能プログラムの実行により本体部の機能として上記で説明した交換データ通信判断部２２５の他の機能である通信データ判定部２２８およびアプリケーションＩＤ判定部２３０の処理を実行するようにしても良い。

また、本例においても、上述したように、ステップＳ１４２におけるスリープ状態が解除された後、データ授受処理を開始する前に装置識別情報登録処理部２１１により通信相手を識別するＭＡＣアドレスを保存するようにすることも可能である。

すなわち、当該構成においては、装置識別情報比較部２２６を含む交換データ通信判断部２２５を通過した場合に、当該交換データ通信判断部２２５における判断処理を通過した他のゲーム装置のＭＡＣアドレスが装置識別情報登録処理部２１１によりＭＡＣアドレスリスト保存領域８８に保存されることになる。上述した処理により、一度、当該判断処理を通過した通信相手との通信を行わずに効率的なデータ通信を実行することが可能である。

なお、当該構成においては、交換データ通信判断部２２５における判断処理を通過したことを条件（登録条件）として、ＣＰＵ３１（装置識別情報登録処理部２１１）が保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８に、通信相手を識別するＭＡＣアドレスを保存（登録）する場合について説明したが、当該交換データ通信判断部２２５における判断処理を通過した場合のみをＭＡＣアドレスを登録する登録条件とする場合に限られず、当該判断処理を通過した上でさらに他の条件の判定処理を実行した上で、当該他の条件の判定処理を満たす場合に、ＭＡＣアドレスを登録するようにするようにしても良い。

なお、当該構成において、本体部の機能として、通信データ判定部２２８およびアプリケーションＩＤ判定部２３０の処理を実行する場合について説明しているが、その場合に、通信データ判定部２２８において受信無線フレームを受信しないと判断した場合、すなわち互いに通信接続が不可能である装置からデータを受信あるいは通信対象とならないデータを受信したと判定される場合には、再度データ通信を実行する必要はないと考えられる。

したがって、その場合にも当該データを送信した装置のＭＡＣアドレスを装置識別情報登録処理部２１１によりＭＡＣアドレスリスト保存領域８８に保存するようにしても良い。

これにより、通信対象とならない装置のＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８に保存することにより、一度通信を行った通信相手との通信を行わずに効率的なデータ通信を実行することが可能となる。

また、同様に、アプリケーションＩＤ判定部２３０の判定処理において、アプリケーションＩＤの一致フラグがオンでない、すなわち、他のゲーム装置は交換データの交換相手とはならないと判定される場合においても、再度データ通信を実行する必要はないと考えられる。

したがって、その場合にも他のゲーム装置のＭＡＣアドレスを装置識別情報登録処理部２１１によりＭＡＣアドレスリスト保存領域８８に保存するようにしても良い。

これにより、交換データの交換相手とはならない他のゲーム装置のＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８に保存することにより、一度通信を行った通信相手との通信を行わずに効率的なデータ通信を実行することが可能となる。

＜携帯固定端末間通信＞
次に、本発明の実施の形態に従うゲーム装置１において固定端末機器の配信データを受信するデータ通信について説明する。

図８３は、本発明の実施の形態に従うゲーム装置１と固定端末機器５との通信処理の概略について説明する図である。

図８３を参照して、固定端末機器５は、無線アクセスポイント装置１００と、信号発生装置１０２とを含む。無線アクセスポイント装置１００は、ネットワーク１１０を介して配信サーバ１１５と接続される。信号発生装置１０２は、無線アクセスポイント装置１００と接続するために必要な接続情報を含む後述する配信無線フレームを宛先を特定せずに送信する。

無線アクセスポイント装置１００は、ゲーム装置１からの配信データの要求に対してネットワーク１１０を介して配信サーバ１１５から取得（ダウンロード）した配信データをゲーム装置１に対して送信する。

＜固定端末機器５からの配信データの受信を実行する機能ブロックの説明＞
図８４は、本発明の実施の形態に従うゲーム装置１における配信データを受信する機能ブロックについて説明する図である。

図８４を参照して、ゲーム装置１は、無線通信モジュール３８と、無線通信モジュール３８以外の本体部３９とで構成される。

本体部３９は、無線通信設定部２０５と、装置識別情報登録処理部２１１と、データ通信制御部２０９と、受信データ保存領域８２と、ＭＡＣアドレスリスト保存領域８８＃とを含む。

無線通信モジュール３８は、無線フレーム受信部２２３＃と、配信データ通信判断部２２５＃と、ＭＡＣアドレスリスト保存領域７０＃と、受信無線フレーム保存領域６９とを含む。

無線通信設定部２０５は、ＭＡＣアドレスリスト保存領域８８＃に格納されているＭＡＣアドレスリストをＭＡＣアドレスリスト保存領域７０＃に格納する。また、無線通信設定部２０５は、無線通信モジュール３８における無線通信を実行するための指示を無線フレーム受信部２２３＃に出力する。

無線通信モジュール３８の無線フレーム受信部２２３＃は、無線通信を実行する指示を受けて配信相手を探索する配信相手探索処理を実行する。本例においては、無線フレーム受信部２２３＃は、配信相手として一例として固定端末機器５から送信された配信無線フレームを受信無線フレームとして受信するものとする。そして、無線フレーム受信部２２３＃は、当該受信した受信無線フレームを受信無線フレーム保存領域６９に格納する。

配信データ通信判断部２２５＃は、受信した配信無線フレーム（受信無線フレーム）に基づいて通信相手が配信データを配信する配信相手であるかどうかを判断し、配信相手であると判断された場合には、その旨を本体部３９に通知する。

具体的には、配信無線フレーム（受信無線フレーム）に含まれている装置識別情報であるＭＡＣアドレスがＭＡＣアドレスリスト保存領域７０＃に保存されているＭＡＣアドレスリストに登録されているかどうかを判断する。また、当該配信無線フレーム（受信無線フレーム）について、配信データの取得処理が可能な無線フレームであるかどうかを判定する。

そして、配信データ通信判断部２２５＃は、配信無線フレームに含まれているＭＡＣアドレスがＭＡＣアドレスリストに登録されておらず、また、また、当該配信無線フレームが配信データの取得処理が可能な無線フレームであると判断した場合には、配信データの受信が可能である旨の通知を本体部３９のデータ通信制御部２０９に出力する。なお、ここでは、２つの条件が満たされた場合に配信データの受信が可能である旨の通知を本体部３９のデータ通信制御部２０９に出力する場合について説明しているが、少なくとも１つの条件が満たされた場合に当該通知を出力するようにしても良い。

データ通信制御部２０９は、配信データ通信判断部２２５＃から出力された配信データの受信が可能である旨の通知を受けて、固定端末機器５に対して配信データの送信を要求し、固定端末機器５から送信された配信データを受信する配信データ取得処理を実行する。そして、受信した配信データを受信データ保存領域８２に格納する。

装置識別情報登録処理部２１１は、データ通信制御部２０９により受信した配信データが受信データ保存領域８２に格納された場合には、配信相手である固定端末機器５の装置識別情報であるＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８＃に格納する。

そして、無線通信設定部２０５は、再び、ＭＡＣアドレスリスト保存領域８８＃に格納されているＭＡＣアドレスリストをＭＡＣアドレスリスト保存領域７０＃に格納し、無線通信モジュール３８における無線通信を実行するための指示を無線フレーム受信部２２３＃に出力する。すなわち、上記で説明したのと同様の処理を繰り返す。

無線通信モジュール３８の無線フレーム受信部２２３＃は、再び、無線通信を実行する指示を受けて配信相手を探索する配信相手探索処理を実行する。そして、例えば、再び、本例において、固定端末機器５から送信された配信無線フレームすなわち受信無線フレームを受信するものとする。

配信データ通信判断部２２５＃は、上述したように、配信無線フレームに含まれている装置識別情報であるＭＡＣアドレスがＭＡＣアドレスリスト保存領域７０＃に保存されているＭＡＣアドレスリストに登録されているかどうかを判断する。

その際、配信データ通信判断部２２５＃は、上述したように以前に配信データの取得処理が実行されている場合には、ＭＡＣアドレスリストに固定端末機器５の装置識別情報であるＭＡＣアドレスが格納されているためＭＡＣアドレスに登録されていると判断し、その後のデータ通信である配信データ取得処理は実行しない。すなわち、一度通信を行った通信相手との通信を行わずに効率的なデータ通信を実行することが可能である。

なお、本体部３９と、無線通信モジュール３８とは独立して動作することが可能である。すなわち、本体部３９がスリープ状態に遷移している場合においても、無線通信モジュール３８は、配信相手を探索する配信相手探索処理を実行することが可能である。そして、配信データを受信することが可能な配信相手が見つかった場合にのみ、本体部３９に通知されて、通信相手との接続が確立されて、配信データの取得処理が実行される。したがって、例えば、本体部３９がスリープ状態等の省電力状態に遷移している場合に、無線通信モジュール３８における配信相手探索処理により通信相手が見つかった場合であっても交換が可能でなければ本体部３９に通知されて通信接続が確立されることはないため、ゲーム装置１全体における省電力を図ることが可能である。

図８５は、本発明の実施の形態に従う携帯固定端末間処理を実行する無線通信モジュール３８の機能ブロックの詳細について説明する図である。

図８５を参照して、本例においては、一例として、ＣＰＵ６０がＲＯＭ７２に保存された携帯固定端末間処理を実行するためのアプリケーションを実行することにより所定の機能を実現する場合について説明するが、必ずしもＣＰＵ６０により実現される場合に限られず、少なくとも一部の機能を専用のＩＣ（Integrated Circuit）を用いて実現するようにしても良い。

無線通信モジュール３８は、無線フレーム受信部２２３＃と、配信データ通信判断部２２５＃とを含む。

無線フレーム受信部２２３＃は、通信相手探索部２２４を含む。配信データ通信判断部２２５＃は、装置識別情報比較部２２６と、通信データ判定部２２８とを含む。なお、各機能は、必要に応じてマルチタスク制御により実現されるものとする。

図７の機能ブロックと比較すると送信無線フレームを送信しないために無線フレーム設定部２２２が設けられていない構成である。

通信相手探索部２２４は、通信可能範囲１０に含まれる通信相手を探索する配信相手探索処理を実行する。本例においては、一例として配信相手として固定端末機器５との間で通信する場合について説明する。そして、通信相手探索部２２４は、固定端末機器５からの配信無線フレームを受信するまで待機し、受信した場合に当該配信無線フレームを受信無線フレームとして受信無線フレーム保存領域６９に格納する。

配信データ通信判断部２２５＃は、通信相手探索部２２４で通信相手を発見した場合、すなわち、通信相手から配信無線フレームを受信した場合、当該配信無線フレームに基づいて通信相手が配信データを取得することが可能な配信相手であるかどうかを判断し、配信相手であると判断された場合には、その旨を通知する。

具体的には、装置識別情報比較部２２６は、通信相手探索部２２４において通信相手が発見された場合に、通信相手である固定端末機器５から受信した配信無線フレームに含まれている装置識別情報であるＭＡＣアドレスが、ＭＡＣアドレスリスト保存領域７０＃に保存されたＭＡＣアドレスリストと比較して一致するものがあるかどうかを判断する。

通信データ判定部２２８は、通信相手が発見された場合に、装置識別情報比較部２２６の比較結果に従って配信無線フレームに含まれているＭＡＣアドレスがＭＡＣアドレスリスト保存領域７０＃に保存されているＭＡＣアドレスリストと一致しないと判断された場合に、配信無線フレームのデータ内容を確認して、配信無線フレームが携帯固定端末間処理として処理可能な無線フレームであるかどうかを判定する。

そして、通信データ判定部２２８は、配信無線フレームが携帯固定端末間処理として処理可能な無線フレームであると判断した場合には、本体側にその旨を通知する。

以降の処理は、ゲーム装置１の本体部３９の機能として実行されることになる。
なお、ゲーム装置１の本体部３９の機能ブロックの詳細については、上述したように図６で説明した構成と基本的に同様であるので図６を用いて説明する。

具体的には、スリープ設定／解除処理部２１６は、無線通信モジュール３８からの通知（図８５の通信データ判定部２２８からの通知）を受ける。

データ通信実行処理部２０８は、無線通信モジュール３８からの通知に従って固定端末機器５からの配信データの取得処理を実行する。具体的には、配信データの要求を固定端末機器５に送信する。そして、固定端末機器５から送信された配信データを受信する。

そして、固定端末機器５から受信した配信データを保存用データメモリ３４の受信データ保存領域８２に保存する。

装置識別情報登録処理部２１１は、データ通信実行処理部２０８により受信した配信データを受信データ保存領域８２に格納した場合には、配信相手である固定端末機器５の装置識別情報であるＭＡＣアドレスをＭＡＣアドレスリスト保存領域８８＃に格納する。

データ通知処理部２１２は、配信データを取得した旨をユーザに通知する。
＜無線通信モジュール３８による携帯固定端末間通信＞
図８６は、本発明の実施の形態に従う携帯固定端末間通信について説明する図である。当該処理は、無線通信モジュール３８において、配信データを提供する通信相手を探索する配信相手探索処理であり、一例として、ＣＰＵ６０が、ＲＯＭ７２に格納されている携帯固定端末間処理を実行するためのアプリケーションを実行することにより実現される。

図８６を参照して、まず、ＣＰＵ６０（通信相手探索部２２４）は、所定期間が経過したかどうかを判断する（ステップＳ２８０）。そして、ステップＳ２８０において、ＣＰＵ６０は、所定期間が経過していないと判断した場合（ステップＳ２８０においてＮＯ）には、通信相手（固定端末機器）を探索する通信相手サーチ処理を実行する（ステップＳ２８２）。通信相手サーチ処理については後述する。

そして、次に、ＣＰＵ６０（通信相手探索部２２４）は、通信相手サーチ処理により通信相手が発見されたかどうかを判断する（ステップＳ２８４）。

ステップＳ２８４において通信相手が発見されない場合（ステップＳ２８４においてＮＯ）には、ステップＳ２８０に戻る。

ステップＳ２８４において、通信相手が発見された場合（ステップＳ２８４においてＹＥＳ）には、ＣＰＵ６０（装置識別情報比較部２２６）は、ＭＡＣアドレスを比較する（ステップＳ２８６）。具体的には、配信無線フレームに含まれるＭＡＣアドレスと、上述したＭＡＣアドレスリスト保存領域７０＃に格納されているＭＡＣアドレスとを比較する。上述したようにＭＡＣアドレスは、通信対象を識別する識別情報であり、各固定端末機器には固有のＭＡＣアドレスが割り当てられている。そして、ＭＡＣアドレスリスト保存領域７０＃には、各固定端末機器に割り当てられたＭＡＣアドレスが保存されている。

そして、次に、ＣＰＵ６０（装置識別情報比較部２２６）は、配信無線フレームに含まれる固定端末機器のＭＡＣアドレスが、ＭＡＣアドレスリストに格納されているＭＡＣアドレスと一致するかどうかを判断する（ステップＳ２８８）。

そして、ステップＳ２８８において、ＭＡＣアドレスが一致したと判断した場合（ステップＳ２８８においてＹＥＳ）には、再びステップＳ２８０に戻る。すなわち、以降の処理を実行することなく当該ＭＡＣアドレスに対応する固定端末機器５との通信を終了する。すなわち、上述したＭＡＣアドレスフィルタリング処理が実行される。したがって、通信可能範囲１０に含まれる他のゲーム装置からの通信対象となるデータを受信する毎に識別情報であるＭＡＣアドレスと一致するかどうかの判断が繰り返される。

ＭＡＣアドレスの比較の概念図については、図２２，２３で説明したのと同様であるのでその詳細については繰り返さない。

ステップＳ２８８においてＭＡＣアドレスが一致しないと判断した場合（ステップＳ２８８においてＮＯ）には、ＣＰＵ６０（通信データ判定部２２８）は、受信したデータの内容を確認する（ステップＳ２９０）。

図８７は、本発明の実施の形態に従う携帯固定端末間通信においてゲーム装置においてビーコンとして受信される配信無線フレームの構成について説明する図である。

図８７を参照して、固定端末機器５の信号発生装置１０２から送信される配信無線フレームの構成の概略は、図１９で説明した送信無線フレームと同様の構成であり、図２０で説明したベンダ特定ＩＥデータの構成が異なる。

具体的には、ビーコンとして受信される配信無線フレームに含まれるベンダ特定ＩＥデータは、タグ情報ＤＤ２１、タグ長情報ＤＤ２２、ベンダ情報ＤＤ２３、通信データ識別情報ＤＤ２４、アプリケーションＩＤＤＤ２５とを含む。

タグ情報ＤＤ２１は、複数のＩＥデータをそれぞれ識別する識別データである。タグ長情報ＤＤ２２は、当該ベンダ特定ＩＥデータのデータ長を示すデータが含まれている。

ベンダ情報ＤＤ２３は、当該データを提供する企業等を識別するためのデータである。
通信データ識別情報ＤＤ２４は、通信データの種別を示すデータであり、携帯固定端末間通信の場合には、携帯固定端末間通信の通信データを示す情報が格納される。

そして、以降にアプリケーションＩＤＤＤ２５が設けられる。
当該配信無線フレームは、後述するが固定端末機器５から不特定の相手（ゲーム装置）に対して送信されたものであり、不特定の相手（ゲーム装置）が受信するものである。親機側の固定端末機器５は、宛先を特定せずに子機側の通信相手に対して当該送信を繰り返し実行する。

再び、図８６を参照して、次に、ＣＰＵ６０は、受信したデータに含まれる配信無線フレームを受信したかどうかを判断する（ステップＳ２８８）。

具体的には、図８７で説明した当該データを提供する企業等を識別するためのベンダ情報がゲーム装置１が予め有しているベンダ情報と一致するかどうかを判断する。ベンダ情報が一致する場合とは、送信されたデータの発信源が通信接続が可能な装置であることを意味し、異なる場合には、送信されたデータの発信源が通信接続が不可能である装置であることを意味する。

また、通信データ識別情報がゲーム装置１が予め有している通信データ識別情報と一致するかどうかを判断する。通信データ識別情報が一致する場合とは、携帯固定端末間通信における通信データ、すなわち携帯固定端末間処理として処理可能な無線フレームであることを意味する。ゲーム装置１側の比較の対象であるベンダ情報は予めＲＯＭ７２に登録されているものとする。また、ゲーム装置１側の比較の対象である通信データ識別情報についても予めＲＯＭ７２に登録されているものとする。

一方、携帯固定端末間通信における通信データ識別情報と、携帯端末間通信における通信データ識別情報とは異なるため、仮にゲーム装置３から出力されたデータを受信した場合であっても通信データ識別情報が異なるため当該データを受信せず固定端末機器５とのみ通信することが可能である。

ＣＰＵ６０（通信データ判定部２２８）は、携帯端末間通信か携帯固定端末間通信かによって比較対象とする通信データ識別情報を切り替えて、受信したデータに含まれている通信データ識別情報と一致するか否か判断する。

すなわち、ステップＳ２８８において、ＣＰＵ６０（通信データ判定部２２８）は、配信無線フレームを受信していないと判断した場合（ステップＳ２８８においてＮＯ）には、再びステップＳ２８０に戻る。

したがって、互いに通信接続が不可能である装置からデータを受信あるいは通信対象とならないデータを受信した場合には、以降の処理を実行することなく通信を終了する。なお、本例においてはベンダ情報および通信データ識別情報がともに一致するかどうかを判断する場合について説明したが、通信データ識別情報のみが一致するかどうかを判断するようにしても良い。

次に、ステップＳ２９２において、ＣＰＵ６０（通信データ判定部２２８）は、配信無線フレームを受信したと判断した場合（ステップＳ２９２においてＹＥＳ）には、次に、配信データを有する固定端末機器５が発見された旨を本体側に通知する（ステップＳ２９４）。そして処理を終了する（エンド）。

以降、通信相手である固定端末機器５と接続を確立して、配信データを取得する配信データ取得処理については、無線通信モジュール３８を用いた本体側のＣＰＵ３１のアプリケーションとして実行されることになる。

したがって、本体側に、配信データを有する固定端末機器５が発見された旨を通知することにより無線通信モジュール３８のＣＰＵ６０のみが独立して実行する無線通信すなわち、無線通信モジュール３８において配信データを取得する通信相手を探索する配信相手探索処理は終了する。

一方、ステップＳ２９２において、ＣＰＵ６０（通信データ判定部２２８）は、配信無線フレームを受信しないと判断した場合（ステップＳ２９２においてＮＯ）には、ステップＳ２８０に戻る。

当該処理により、本例においては、無線通信モジュール３８における配信相手探索処理により配信データを取得可能な通信相手が見つかった場合にのみ、本体側のＣＰＵ３１に通知されて、通信相手との接続が確立されて、配信データの取得処理が実行される。したがって、例えば、本体側のＣＰＵ３１がスリープ状態等の省電力状態である場合に、無線通信モジュール３８における配信相手探索処理により通信相手が見つかった場合であっても配信データの取得ができないと判断されれば本体側のＣＰＵ３１に通知されて通信接続が確立されることはないため、ゲーム装置１全体における省電力を図ることが可能である。

図８８は、本発明の実施の形態に従う配信データを取得するデータ取得処理のフロー図である。当該データ取得処理は、一例として上述したシステムプログラム保存領域８６に格納されている本体機能プログラムをＣＰＵ３１が実行することにより実現されるものである。当該データ取得処理は、例えば、本体の起動時に開始して、バックグラウンドで継続的に実行される。

図８８を参照して、まず、ＣＰＵ３１（スリープ設定／解除処理部２１６）は、無線通信モジュール３８からの通知があるかどうかを判断する（ステップＳ３００）。

ステップＳ３００において、ＣＰＵ３１（スリープ設定／解除処理部２１６）は、無線通信モジュール３８からの通知があったと判断した場合（ステップＳ３００においてＹＥＳ）には、本体側の機能がスリープ状態であるかどうかを判断する（ステップＳ３０１）。

そして、ＣＰＵ３１（スリープ設定／解除処理部２１６）は、本体側の機能がスリープ状態であると判断した場合（ステップＳ３０１においてＹＥＳ）には、スリープ状態を解除する（ステップＳ３０２）。

そして、次に、ＣＰＵ３１（データ通信実行処理部２０８）は、データ取得処理を開始する（ステップＳ３０３）。一方、本体側の機能がスリープ状態で無いと判断した場合（ステップＳ３０１においてＮＯ）には、ステップＳ３０３に進む。

そして、ＣＰＵ３１（データ通信実行処理部２０８）は、無線通信モジュール３８からの配信データを有する固定端末機器が発見された旨の通知に含まれている通信相手のＭＡＣアドレス等の接続情報に基づいて通信相手との間で通信接続を確立する（ステップＳ３０４）。本例においては、固定端末機器５の無線アクセスポイント装置１００との間で通信接続を確立する。なお、本例においては、固定端末機器が発見された旨の通知後、通信相手との接続を確立する場合、すなわち、ＣＰＵ３１（データ通信実行処理部２０８）が実行する場合について説明するが、ゲーム装置が発見された旨の通知前、例えば、無線通信モジュール３８において図８６のステップＳ２９２とステップＳ２９４との間で通信相手との接続を確立する処理を実行するようにしても良い。

そして、次に、ＣＰＵ３１（データ通信実行処理部２０８）は、配信データの要求を送信する（ステップＳ３０５）。

そして、次に、ＣＰＵ３１（データ通信実行処理部２０８）は、配信データを受信したかどうかを判断する（ステップＳ３０６）。

そして、ステップＳ３０６において、ＣＰＵ３１（データ通信実行処理部２０８）は、配信データを受信したと判断した場合（ステップＳ３０６においてＹＥＳ）には、メインメモリ３２に配信データを格納する（ステップＳ３０８）。

そして、次に、ＣＰＵ３１（データ通信実行処理部２０８）は、通信相手（固定端末機器５）との通信を切断する（ステップＳ３１０）。すなわち、上記処理により通信相手である固定端末機器との間での配信データのデータ取得処理が終了することになる。

そして、次に、ＣＰＵ３１（データ格納処理部２１０）は、データ格納処理を実行する。

図８９は、本発明の実施の形態に従う配信データのデータ格納処理について説明するフロー図である。

図８９を参照して、ＣＰＵ３１（データ格納処理部２１０）は、データ通信実行処理部２０８で受信した配信データを受信データ保存領域８２のアプリケーションＩＤに対応付けられて設けられた受信ＢＯＸに格納する（ステップＳ７００）。

そして、次に、ＣＰＵ３１（データ格納処理部）は、受信データ判定処理を実行する（ステップＳ７０２）。受信データ判定処理については、図６６で説明したのと同様である。すなわち、受信データ保存領域８２の受信ＢＯＸに格納された配信データと対応付けられて設定されている伝播回数を確認して、条件を満たしているかどうかを判定し、満たされている場合には、配信データを他のゲーム装置に伝播するために、配信データをコピーして交換データ（伝播データ）として交換データ保存領域８０のアプリケーションＩＤに対応付けられて設けられた送信ＢＯＸに格納する。

そして、処理を終了する（リターン）。
再び、図８８を参照して、次に、ＣＰＵ３１（装置識別情報登録処理部２１１）は、ＭＡＣアドレス保存処理を実行する（ステップＳ３１４）。ＭＡＣアドレス保存処理については、図７０で説明したのとほぼ同様であるが、受信ＢＯＸに変更があった場合には、保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８＃に、通信相手を識別するＭＡＣアドレスを保存する。当該ＭＡＣアドレスリスト保存領域８８＃に保存されたＭＡＣアドレスがＭＡＣアドレスリストの一部に含められ上述した通信設定処理で用いられることになる。

そして、通信設定処理により、ＭＡＣアドレスリスト保存領域７０＃にＭＡＣアドレスリストが保存されるため、上述したＭＡＣアドレスフィルタリング処理により、同じ固定端末機器との間で何度も通信することを防止することができ、効率的かつ効果的なデータ通信を実行することが可能である。

なお、本例においては、本体側の保存用データメモリ３４に設けられているＭＡＣアドレスリスト保存領域８８＃に保存されたＭＡＣアドレスリストと、無線通信モジュール３８のＭＡＣアドレスリスト保存領域７０＃に格納されているＭＡＣアドレスリストは同じであり、ＭＡＣアドレスリスト保存領域７０＃のみを用いて上記で説明した方式を実現しても良い。

一方で、本体側の保存用データメモリ３４にＭＡＣアドレスリスト保存領域８８＃を設けて、当該ＭＡＣアドレスリスト保存領域８８＃にＭＡＣアドレスを保存することにより、無線通信モジュール３８にアクセスしてＭＡＣアドレスリスト保存領域７０のデータを編集するよりも、ＭＡＣアドレスのデータの追加あるいは削除等の編集を容易かつ高速に実行することが可能である。

そして、ＣＰＵ３１（データ通知処理部２１２）は、取得データ通知処理を実行する（ステップＳ３１６）。そして、処理を終了する（エンド）。なお、取得データ通知処理については、図７１で説明したのと同様に配信データを取得した場合には、効果音あるいは内容を表示することによりユーザに通知する。

一方、ステップＳ３０６において、ＣＰＵ３１（データ通信実行処理部２０８）は、配信相手である固定端末機器から配信データを一定期間内に受信していないと判断した場合（ステップＳ３０６においてＮＯ）には、ステップＳ３１８に進む。ステップＳ３１８において、ＣＰＵ３１（データ通信実行処理部２０８）は、配信相手である固定端末機器との通信を切断する。そして、ステップＳ３１２に進む。したがって、この場合には、配信データを適切に取得することができなかったためＭＡＣアドレスリスト保存領域７０＃にＭＡＣアドレスを保存することなく通信を切断する。したがって、再度、携帯固定端末間通信に従って上述した処理を実行して、配信データのデータ取得処理を再開することが可能である。

図９０は、本発明の実施の形態に従う固定端末サーチ処理のフロー図である。
この処理では、ゲーム装置１は、子機として親機である固定端末機器５との間で無線通信を実行し、ゲーム装置１は、親機である固定端末機器５からのビーコンの受信があるまで待機する。この通信相手サーチ処理では、ゲーム装置１は、常に子機として動作して親機をサーチする処理を実行する。なお、本例においては、固定端末機器５からのみビーコンが送信され、ゲーム装置１は当該信号の受信を待つ方式について説明しているが、固定端末機器５は、備え付けの機器であるため、携帯型の移動可能なゲーム装置から信号を出力するよりも固定端末機器５からのみビーコンを送信した方が効率よくデータ通信を実行することができるからである。

図９０を参照して、固定端末サーチ処理を開始すると、図示は省略するが、このときタイマ回路をスタートする。

そして、ステップＳ３２０で、親機である固定端末機器５のビーコンを受信したかどうかを判断する。

固定端末機器５からのビーコンを受信した場合（ステップＳ３２０においてＹＥＳ）には、ステップＳ３２４において接続フラグをオンして、固定端末サーチ処理をリターンする。つまり、子機として、親機である固定端末機器５との間で通信接続が可能であることが判明する。

なお、図９０においては省略したが、固定端末サーチ処理が開始されたとき、接続フラグはオフ（リセット）される。

一方、親機からの接続要求信号を全く受信しない場合（ステップＳ３２０においてＮＯ）には、ステップＳ３２２で、子機として固定端末機器５に接続を試みる期間がＴｓｄ秒経過したかどうかを判断する。

ステップＳ３２２において、親機サーチ時間がＴｓｄ秒経過していなければ（ステップＳ３２２においてＮＯ）、そのままステップＳ３２０に戻る。

一方、親機サーチ時間がＴｓｄ秒経過すれば（ステップＳ３２２においてＹＥＳ）固定端末サーチ処理をリターンする。

図９１は、本発明の実施の形態に従う配信データ取得のデータの遣り取りについて説明する図である。

図９１を参照して、シーケンスｓｑ２〜ｓｑ８までは、図８２で説明したのと同様であり、本体側のＣＰＵ３１においてアプリケーションプログラムの実行による交換データが設定される（シーケンスｓｑ２）。そして、本体側のＣＰＵ３１は、無線通信モジュール３８に対して通信初期設定のためのデータを出力する（シーケンスｓｑ４）。そして、本体側のＣＰＵ３１は、通信開始指示を無線通信モジュール３８に出力する（シーケンスｓｑ６）。

これに伴い通信開始指示に応答して無線通信モジュール３８による無線通信が開始される（シーケンスｓｑ８）。

そして、まず、無線通信モジュール３８において交換データを交換する通信相手を探索する携帯端末間通信が開始され（シーケンスｓｑ１００）、所定期間内に通信相手を発見することができなかったものとする。

そして、さらに、携帯端末間通信が開始される（シーケンスｓｑ１０２）この場合においても所定期間内に通信相手を発見することができなかったものとする。

そして、次に、携帯固定端末間通信が開始される（シーケンスｓｑ１０３）。
固定端末機器５は、上述したように、信号発生装置１０２からビーコンを繰り返し発信（送信）する。

そして、ゲーム装置１の無線通信モジュール３８は、固定端末機器５から送信されたビーコンの入力を受け付ける（シーケンスｓｑ１０４）。

これにより、上述したように自機であるゲーム装置１について接続フラグがオンする。
ゲーム装置１の無線通信モジュール３８においては、接続フラグがオンとなることに伴い通信相手である固定端末機器と通信接続が可能であるすなわち通信相手を発見したと判断する（シーケンスｓｑ１０８）。

そして、ゲーム装置１の無線通信モジュール３８においては、データ内容を確認する（シーケンスｓｑ１１０）。

そして、配信無線フレームを受信したと判断した場合には、無線通信モジュール３８は、本体側のＣＰＵに対して配信データの提供を受けることが可能な固定端末機器５が発見された旨を通知する（シーケンスｓｑ１１２）。

これにより、本体側のＣＰＵは、無線通信モジュール３８からの通知によって、配信データを配信する固定端末機器５と通信接続が可能であることを認識し、データ取得処理を開始する（ｓｑ１１４）。

そして、次に、ゲーム装置１の本体側のＣＰＵ３１は、データ取得処理が開始された後、配信データ要求を送信する（シーケンスｓｑ１１６）。

固定端末機器５の無線アクセスポイント装置１００は、ゲーム装置１からの配信データ要求を受け付けて、当該配信データ要求をネットワーク１１０を介して配信サーバ１１５に送信する（シーケンスｓｑ１１７）。

そして、配信サーバ１１５は、無線アクセスポイント装置１００からの配信データ要求に従って、配信データを送信する（シーケンスｓｑ１１８）。

無線アクセスポイント装置１００は、ネットワーク１１０を介する配信サーバ１１５からの配信データを受け付けた後、当該配信データをゲーム装置１に対して送信する（シーケンスｓｑ１１９）。

そして、ゲーム装置１は、固定端末機器５の無線アクセスポイント装置１００から送信された配信データを受け付けて、受信した配信データをメモリに格納する（シーケンスｓｑ１２０）。

そして、通信を切断する（シーケンスｓｑ１２２）。
そして、データ格納処理を実行する（シーケンスｓｑ１２３）。

そして、ＭＡＣアドレスを登録する（シーケンスｓｑ１２４）。
そして、取得データを通知する（シーケンスｓｑ１２６）。

なお、上記シーケンスにおいて、シーケンスｓｑ４，ｓｑ６，ｓｑ１１４〜１２６は、一例として、上述したように本体側の機能でありシステムプログラム保存領域８６に格納された本体機能プログラムにより実現されるものである。一方、シーケンスｓｑ８，ｓｑ１００〜ｓｑ１１０は、一例として、上述したように、無線通信モジュール３８におけるメモリ制御部６４に格納されているＲＯＭ７２から読出されたプログラムにより実現されるものである。

この実施例によれば、無線通信により、通信接続が確立する固定端末機器５との間で配信データを自動で取得することができる。

例えば、配信データが店頭で使用することが可能なクーポンを表示するようなものである場合、ゲーム装置１を携帯しているだけで固定端末機器５と無線通信した場合に当該クーポンを表示する配信データを取得することが可能であり、配信データの取得の楽しさを増大させることができる。

また、たとえば、取得したクーポンを表示する配信データを交換データとして上述した交換データ保存領域８０のスロットに格納させるようにしても良い。たとえば、当該配信データに上述した交換データとして交換データ保存領域に格納させるアプリケーションを含ませるようにすれば良い。当該処理により、携帯端末間通信において交換データとして他の人に当該配信データを提供することが可能となる。

すなわち、固定端末機器５からのみしか取得できない配信データについても携帯端末間通信を利用して他のユーザに提供することが可能となり、配信データの興趣性をさらに増大させることが可能である。

そして、当該配信データの取得処理が実行された後、再び、無線通信モジュール３８における配信相手探索処理が開始される。

例えば、上述したように所定期間経過毎に、自動的に通信設定処理を開始することも可能である。通信設定処理の詳細については図１５で説明したので繰り返さない。そして、次に、ＣＰＵ３１（通信指示処理部２０６）は、通信開始指示を無線通信モジュール３８に出力する（ステップＳ２９）。

これにより再び、図１７のステップＳ４４で説明したように無線通信モジュール３８において携帯端末間通信が実行される（ステップＳ４４）。次に、再び、携帯端末間通信が実行される（ステップＳ４６）。

携帯端末間通信において、所定期間内に通信相手を発見することができなかった場合には、再び、携帯固定端末間通信が実行される。

携帯固定端末間通信の詳細については図８６で説明したとおりである。
図８６で説明したように携帯固定端末間通信においても、ＭＡＣアドレスが一致する他の固定端末機器との再度の通信処理を行わないＭＡＣアドレスフィルタリング処理が実行される。

すなわち、ＭＡＣアドレスリストに登録されている一度通信を行った通信相手である固定端末機器（本例においては固定端末機器５）との間では実質的な通信は実行されない。

したがって、本発明の実施の形態に従うゲーム装置においては、通信範囲の固定端末機器を自動的に繰り返して探知し、見つかった固定端末機器を通信候補に設定する。この場合、同じ固定端末機器を何度も探知して見つけてしまう可能性があるが、上述のようなＭＡＣアドレスフィルタリング処理により、同じ固定端末機器との間で何度も通信することを防止することができ、効率的かつ効果的なデータ通信を実行することが可能である。

なお、図８５における構成においては、図７で説明したようなアプリケーションＩＤ判定部２３０が設けられていない構成について説明したが、携帯固定端末間通信においても、受信した配信無線フレームに格納されているアプリケーションＩＤが配信データの受信に関する所定条件を満たすか否かを判定するアプリケーションＩＤ判定部を設けるようにすることも可能である。具体的には、携帯端末間通信で説明した方式と同様に送信無線フレーム保存領域６７に保存されているアプリケーションＩＤとの判定処理を実行するようにしても良い。例えば、上記したように送信無線フレーム保存領域６７に保存されているアプリケーションＩＤについて、上述した送受信条件データ（センドフラグデータおよびレシーブフラグデータ）が含まれている場合に、データの受信だけをしたい場合が設定されているような場合に、当該アプリケーションＩＤと、配信無線フレームに含まれているアプリケーションＩＤとを比較して一致するかどうかの判定処理を実行するようにしても良い。

なお、図８３に示す固定端末機器５においては、無線アクセスポイント装置１００と、信号発生装置１０２とをそれぞれ別々のものとして設けた場合について説明したが両者をまとめて１つの装置とすることも可能である。すなわち、無線アクセスポイント装置１００が信号発生装置１０２の機能を含み接続要求信号を出力するようにしても良い。

一方で、図８３に示される構成の如く、信号発生装置１０２を接続要求信号のみを送信する専用の装置として設けることにより、無線アクセスポイント装置１００の処理負荷を軽減することにより、例えば、複数のゲーム装置との間での配信データのデータ通信を効率的に実行させるようにしても良い。

また、信号発生装置１０２として、固定端末機器５と通信するゲーム装置を接続要求信号のみを送信する専用の信号発生装置として用いるようにしても良い。ベンダ情報等、通信相手であるゲーム装置と同様の情報を有しているため簡易に信号発生装置を実現することが可能である。

図９２は、本発明の実施の形態に従うゲーム装置１と固定端末機器５＃との通信処理の概略について説明する図である。

図９２を参照して、固定端末機器５＃は、図８３で説明した固定端末機器５と比較して、通信モジュール１０４、ＣＰＵ１０６、ＨＤＤ１０８をさらに含む点で異なる。その他の構成については、図８３で説明したのと同様でるのでその詳細な説明は繰り返さない。

通信モジュール１０４は、ネットワーク１１０と接続されるものとする。ＣＰＵ１０６は、通信モジュール１０４、ＨＤＤ（Hard Disk Drive）１０８、信号発生装置１０２とそれぞれ接続され、これらを制御するものとする。本例においては、一例としてＣＰＵ１０６がＨＤＤ１０８に格納されている配信データを通信モジュール１０４と接続されているネットワーク１１０を介して他の装置に出力可能であるものとする。

当該構成とすることにより、上記と同様の処理を実行することにより、無線アクセスポイント装置１００は、配信サーバ１１５から配信データを取得することができるとともに、ネットワーク１１０を介して接続されている通信モジュール１０４と接続して、例えば、ＨＤＤ１０８に格納されている配信データを取得して、無線アクセスポイント装置１００からゲーム装置に送信することも可能である。

例えば、固定端末機器５＃が複数の店舗等にそれぞれ設けられた場合に、各店舗毎に、ＨＤＤ１０８に格納されている配信データをカスタマイズすることにより、カスタマイズされた配信データをゲーム装置に送信することが可能であり、ゲーム装置における配信データの取得の楽しさを増大させることができる。

＜ＭＡＣアドレスの更新＞
図９３は、本発明の実施の形態に従うＭＡＣアドレスの更新について説明する図である。

図９３に示されるように、ＭＡＣアドレスリスト保存領域には、所定のデータ容量が設けられており、当該所定のデータ容量が一杯となり、保存する領域が無い場合には、保存された古いＭＡＣアドレスを消去して新しいＭＡＣアドレスを保存する。なお、本例においては、ＭＡＣアドレスが登録した日付けがタイムスタンプとして登録されている場合が示されているが、特に当該方式に限られず、タイムスタンプが無い場合であっても登録した順に配列しておくことにより古いものを消去して新しいものを登録するようにすることが可能である。

次に、携帯端末間通信の送信無線フレームの設定に関して、セキュリティを向上させる方式について説明する。

上述したように装置を識別する情報としてＭＡＣアドレスが用いられるが、第三者が当該ＭＡＣアドレスを偽装して当該装置になりすます可能性も考えられる。

したがって、本例においては、セキュリティを向上させるためにＭＡＣアドレスを更新する。

具体的には、ＣＰＵ３１（通信設定処理部２０４）は、図１９で説明したベンダーコードに設定されるローカルアドレスの内容を更新する。

図９４は、本発明の実施の形態に従うローカルアドレスの更新のフロー図である。
図９４を参照して、まず、本体側のＣＰＵ３１（通信設定処理部２０４）は、所定期間が経過したかを判断する（ステップＳ３３０）。一例として所定期間としては６時間程度とする。

そして、ステップＳ３３０において、ＣＰＵ３１（通信設定処理部２０４）は、所定期間が経過したと判断された場合（ステップＳ３３０においてＹＥＳ）には、ローカルアドレスの更新設定を指示する（ステップＳ３３２）。

そして、無線通信モジュール側のＣＰＵ６０は、ローカルアドレスの更新設定指示に従って、ローカルアドレスを更新登録する（ステップＳ３３４）。すなわち、送信無線フレームで設定するためのローカルアドレスの値を更新してＲＡＭ６６に登録する。

そして、処理を終了する（リターン）。
当該処理により、各装置におけるローカルアドレスが所定期間経過後に更新されることになる。

したがって、ＭＡＣアドレスの内容が所定期間経過後に更新されるため一意にＭＡＣアドレスが規定されることはない。それゆえ、ＭＡＣアドレスに従って装置を一意に特定することはできない仕組みとすることによりセキュリティを向上させることが可能となる。

＜ＭＡＣアドレスリストの消去＞
上記においては、ＭＡＣアドレスリスト保存領域８８のデータは、ユーザからの所定の操作指示に従ってＣＰＵ３１（装置識別情報消去処理部２１８）の指示により消去する、あるいは、所定のデータ容量が一杯となり、保存する領域が無い場合には、保存された古いＭＡＣアドレスを消去して新しいＭＡＣアドレスを保存するようにして保存領域を確保する等の処理について説明したが、上記ＭＡＣアドレスの更新と連動させてＭＡＣアドレスリストを消去するようにさせることも可能である。

上述したように、各装置におけるローカルアドレスが所定期間経過後に更新される場合、他のゲーム装置のＭＡＣアドレスが更新される結果以前に上述した交換データの授受処理を実行した相手と再度、当該処理を実行する可能性がある。

図９５は、本発明の実施の形態に従うＭＡＣアドレスの更新処理について説明する図である。

図９５を参照して、ここでは、自機１と、ゲーム装置３について説明する。
時系列で所定期間毎に自機１のＭＡＣアドレスがＡＤ０、ＡＤ０ａ、ＡＤ０ｂと更新される場合が示されている。

また、ゲーム装置３のＭＡＣアドレスがＡＤ１、ＡＤ１ａと更新される場合が示されている。

したがって、同一の装置（ゲーム装置３）について、ＭＡＣアドレスが更新される毎にデータ通信する可能性があり、ＭＡＣアドレスリスト保存領域に確保するべきデータ容量が大きくなる可能性がある。

一方で、図９５に示されるようにＭＡＣアドレスの更新のタイミングは、各装置においてそれぞれ異なる。

自機１のＭＡＣアドレスがＡＤ０の場合に、ゲーム装置３と上述した交換データの授受処理を実行したものとすると、ゲーム装置３のＭＡＣアドレスＡＤ１が登録されることになる。

自機１のＭＡＣアドレスがＡＤ０からＡＤ０ａに更新される際（更新１回目）、ゲーム装置３のＭＡＣアドレスが更新されているとは限らないため、ＭＡＣアドレスがＡＤ０の際に登録したゲーム装置３のＭＡＣアドレスＡＤ１を消去せずにそのまま残しておくことにより、無駄なデータ通信を回避することが可能である。

そして、さらに所定期間後、自機１のＭＡＣアドレスがＡＤ０ａからＡＤ０ｂに更新される際（更新２回目）について考える。この場合には、ゲーム装置３のＭＡＣアドレスについても所定期間が経過しているためＡＤ１からＡＤ１ａに更新されている。

したがって、前回残しておいたゲーム装置３のＭＡＣアドレスＡＤ１を残しておく必要はない。

それゆえ、本例においては、現在使用しているＭＡＣアドレスに対応するＭＡＣアドレスリストを保持するとともに、１つ前のＭＡＣアドレスに対応するＭＡＣアドレスリストを保持し、それよりも前すなわち２つ前のＭＡＣアドレスに対応するＭＡＣアドレスリストについては消去する。

図９６は、本発明の実施の形態に従うＭＡＣアドレスリスト保存領域８８の構成について説明する図である。

本例においては、ＭＡＣアドレスリスト保存領域の構成として、２つの領域を設けることとする。ここでは、現在について、ＭＡＣアドレスリスト保存領域８８ａとし、所定期間後について、ＭＡＣアドレスリスト保存領域８８ｂとした場合について説明する。

図９６（Ａ）を参照して、ＭＡＣアドレスリスト保存領域８８ａは、２つのサブリストＲ１，Ｒ２を含む。なお、当該場合において、ＭＡＣアドレスＡＤ０ａを使用したデータ通信を実行しているものとする。

具体的には現在使用しているＭＡＣアドレス（ＡＤ０ａ）を使用した交換データの授受処理を実行することにより、他のゲーム装置のＭＡＣアドレスを保存する領域（サブリストＲ１）と、現在使用しているＭＡＣアドレスよりも前に使用していたＭＡＣアドレス（ＡＤ０）を使用した交換データの授受処理を実行することにより他のゲーム装置のＭＡＣアドレスを保存する領域（サブリストＲ２）とを設ける。

図９７は、本発明の実施の形態に従うＭＡＣアドレスリストの消去を説明するフロー図である。

図９７を参照して、まず、本体側のＣＰＵ３１（装置識別情報消去処理部２１８）は、所定期間が経過したかを判断する（ステップＳ３４０）。一例として所定期間としては６時間程度とする。

そして、ステップＳ３４０において、ＣＰＵ３１（装置識別情報消去処理部２１８）は、所定期間が経過したと判断された場合（ステップＳ３４０においてＹＥＳ）には、ＭＡＣアドレスリスト保存領域８８を確認する（ステップＳ３４２）。

そして、次に、ＭＡＣアドレスリスト保存領域８８ａに設けられているサブリストＲ１とサブリストＲ２のいずれが古いかを判断する（ステップＳ３４４）。

そして、サブリストＲ１が古いと判断された場合には、サブリストＲ１の内容を削除する（ステップＳ３４６）。

一方、サブリストＲ２が古いと判断された場合には、サブリストＲ２の内容を削除する（ステップＳ３４８）。

そして、削除した領域を新しいＭＡＣアドレス用の領域に設定する（ステップＳ３５０）。

そして、処理を終了する（エンド）。
図９６（Ｂ）を参照して、ここでは、所定期間後に、ＭＡＣアドレスＡＤ０ａがＭＡＣアドレスＡＤ０ｂに更新された場合が示されている。

当該場合において、ＭＡＣアドレスリスト保存領域８８ｂは、２つのサブリストＲ１，Ｒ２のうち、古いサブリストＲ２（ＭＡＣアドレスＡＤ０）の内容を削除して、新しいＭＡＣアドレス（ＭＡＣアドレスＡＤ０ｂ）用の領域に設定した場合が示されている。

当該処理により、ＭＡＣアドレスの更新毎に２つの領域の一方のデータ内容が削除されるためＭＡＣアドレスリスト保存領域全体のデータ量を抑えることが可能となる。

また、ＭＡＣアドレスを更新する際に、現在使用しているＭＡＣアドレスに対応するサブリストを保持することが可能であるため保持されたＭＡＣアドレスに基づいてＭＡＣアドレスフィルタリングを実行することができ、ＭＡＣアドレスを更新した場合にも効率的なデータ通信を継続することが可能である。

なお、当該場合においても、ＣＰＵ３１（装置識別情報消去処理部２１８）は、携帯端末間通信のＭＡＣアドレスが保存されているＭＡＣアドレスリスト保存領域８８とともに、携帯固定端末間通信のＭＡＣアドレスが保存されているＭＡＣアドレスリスト保存領域８８＃のデータ内容を削除することも可能であるが、固定端末機器のＭＡＣアドレスは更新されないため携帯固定端末間通信と同様のタイミングでデータ内容を消去しなくても良い。

したがって、ＣＰＵ３１（装置識別情報消去処理部２１８）は、携帯端末間通信のＭＡＣアドレスが保存されているＭＡＣアドレスリスト保存領域８８のデータ内容を消去するタイミングと異なるタイミングで、携帯固定端末間通信のＭＡＣアドレスが保存されているＭＡＣアドレスリスト保存領域８８＃のデータ内容を消去するようにしても良い。

なお、ここでは、本体部のＭＡＣアドレスリスト保存領域８８，８８＃について説明したが、無線通信モジュール３８側のＭＡＣアドレスリスト保存領域７０，７０＃についても同様に適用可能である。

＜その他の形態＞
上述の実施の形態においては、本発明に係る情報処理装置の代表例として、ゲーム装置１について例示したが、これに限定されることはない。すなわち、本発明に係るプログラムとして、パーソナルコンピュータで実行可能なアプリケーションを提供してもよい。このとき、本発明に係るプログラムは、パーソナルコンピュータ上で実行される各種アプリケーションの一部の機能として組み込まれてもよい。

なお、この実施例では、携帯型のゲーム装置を用いた情報処理システムについてのみ説明したが、当該携帯型のゲーム装置に変えて、携帯電話機やＰＤＡ等の携帯端末でも同様に適用可能である。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１，２，３携帯型ゲーム装置、５，５＃固定端末機器、１０通信可能範囲、１２ＬＣＤ、１４操作ボタン、２３カメラ、２６メモリカード、２７ＲＯＭ、２８バックアップＲＡＭ、３１，６０，１０６ＣＰＵ、３２メインメモリ、３３メモリ制御回路、３４保存用データメモリ、３５プリセットデータ用メモリ、３８無線通信モジュール、４０ＲＴＣ、４１電源回路、４２Ｉ／Ｆ回路、４３マイク、４４アンプ、４５スピーカ、６１アンテナ、６２ＲＦ−ＩＣ、６４メモリ制御部、６６ＲＡＭ、６８送信無線フレーム保存領域、６８フィルタリング用データ保存領域、６９受信無線フレーム保存領域、７０，７０＃，８８，８８＃ＭＡＣアドレスリスト保存領域、７２ＲＯＭ、８０交換データ保存領域、８２受信データ保存領域、８４内蔵アプリ保存領域、８６システムプログラム保存領域、８９フレンドコードリスト保存領域、１００無線アクセスポイント装置、１０２信号発生装置、１０４通信モジュール、１０８ＨＤＤ、１１０ネットワーク、１１５配信サーバ。

Claims

複数の情報処理装置を含む、情報処理システムであって、
前記情報処理装置は、それぞれ、
データを伝播させるための伝播情報を送信すべき譲渡データに設定可能な設定手段と、
前記設定手段により前記伝播情報が設定された前記譲渡データを他の情報処理装置に送信する送信手段と、
他の情報処理装置の前記送信手段により送信された前記設定手段により前記伝播情報が設定された前記譲渡データを受信する受信手段と、
前記受信手段によって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定する伝播判定手段とを含み、
前記情報処理装置は、前記譲渡データを利用可能なアプリケーションプログラムを実行可能であり、
前記送信手段は、前記アプリケーションプログラムの実行の有無に関わらず、前記伝播判定手段による判定結果が肯定である場合に、前記受信手段によって受信された前記譲渡データをさらに他の情報処理装置に送信する、情報処理システム。
前記情報処理装置は、前記伝播判定手段による判定結果が肯定である場合に、前記受信された譲渡データに含まれる伝播情報を更新する伝播情報更新手段をさらに含み、
前記送信手段は、前記伝播判定手段による判定結果が肯定である場合に、前記伝播情報更新手段により更新された伝播情報を含む前記受信手段によって受信された前記譲渡データをさらに他の情報処理装置に送信する、請求項１に記載の情報処理システム。
前記送信手段により送信された、前記伝播情報更新手段により更新された伝播情報を含む前記受信手段によって受信された前記譲渡データは記憶手段に記憶される、請求項２に記載の情報処理システム。
前記情報処理装置は、前記記憶手段に記憶された前記送信された前記譲渡データを読み出して、表示手段に表示するアクセス手段をさらに含む、請求項３に記載の情報処理システム。
前記設定手段は、データを送信する回数を規定する送信情報を送信すべき前記譲渡データに設定可能であり、
前記情報処理装置は、前記設定手段により設定された送信情報を含む前記譲渡データの送信情報に基づいて、当該譲渡データを送信させるか否かを判定する送信判定手段をさらに含み、
前記送信手段は、前記送信判定手段による判定結果が肯定である場合に、前記譲渡データを他の情報処理装置に送信する、請求項１〜４のいずれか１項に記載の情報処理システム。
前記情報処理装置は、
前記送信手段による送信が成功したか否かを判定する送信成功判定手段と、
前記送信成功判定手段による判定結果が肯定である場合に、前記譲渡データに含まれる送信情報を更新する送信情報更新手段とをさらに含み、
前記送信判定手段は、前記送信情報更新手段により更新された送信情報に基づいて、前記譲渡データを再度送信させるか否かを判定する、請求項５に記載の情報処理システム。
前記伝播情報および前記送信情報は、それぞれ伝播回数および送信回数を規定し、
前記設定手段は、前記伝播回数が１回以上の場合には、前記送信回数が１回となるように設定する、請求項５または６に記載の情報処理システム。
前記情報処理装置は、前記伝播判定手段による判定結果が肯定である場合に、前記受信手段によって受信された前記譲渡データを記憶手段の受信したデータを記憶する受信記憶領域に記憶させるとともに、前記記憶手段の送信するデータを記憶する送信記憶領域に前記受信手段によって受信された前記譲渡データを複製して記憶させるデータ格納手段をさらに含む、請求項１〜７のいずれか１項に記載の情報処理システム。
前記情報処理装置は、近距離無線通信を用いて通信可能な前記複数の情報処理装置のうちの他の情報処理装置を探索する無線モジュールをさらに含み、
前記データ格納手段により前記譲渡データを前記送信記憶領域に記憶させた後、前記無線モジュール以外の本体部はスリープ状態に遷移する、請求項８記載の情報処理システム。
前記無線モジュールは、近距離無線通信を用いて通信可能な他の情報処理装置を繰り返して探索し、他の前記情報処理装置と通信可能になったときに、前記他の情報処理装置との間でデータ通信を実行するように前記送信手段に指示する、請求項９記載の情報処理システム。
データを伝播させるための伝播情報を送信すべき譲渡データに設定可能な設定手段と、
前記設定手段により前記伝播情報が設定された前記譲渡データを他の情報処理装置に送信する送信手段と、
他の情報処理装置の前記送信手段により送信された前記設定手段により前記伝播情報が設定された前記譲渡データを受信する受信手段と、
前記受信手段によって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定する伝播判定手段とを備え、
前記情報処理装置は、前記譲渡データを利用可能なアプリケーションプログラムを実行可能であり、
前記送信手段は、前記アプリケーションプログラムの実行の有無に関わらず、前記伝播判定手段による判定結果が肯定である場合に、前記受信手段によって受信された前記譲渡データをさらに他の情報処理装置に送信する、情報処理装置。
データを伝播させるための伝播情報を送信すべき譲渡データに設定するステップと、
前記設定するステップにより前記伝播情報が設定された前記譲渡データを他の情報処理装置に送信するステップと、
他の情報処理装置により送信された前記伝播情報が設定された前記譲渡データを受信するステップと、
前記受信するステップによって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定するステップと、
前記譲渡データを利用可能なアプリケーションプログラムを実行するステップとを備え、
前記送信するステップは、前記アプリケーションプログラムの実行の有無に関わらず、前記判定するステップによる判定結果が肯定である場合に、前記受信するステップにより受信された前記譲渡データをさらに他の情報処理装置に送信する、情報処理装置の制御方法。
情報処理装置の制御プログラムであって、コンピュータに、
データを伝播させるための伝播情報を送信すべき譲渡データに設定するステップと、
前記設定するステップにより前記伝播情報が設定された前記譲渡データを他の情報処理装置に送信するステップと、
他の情報処理装置により送信された前記伝播情報が設定された前記譲渡データを受信するステップと、
前記受信するステップによって受信された譲渡データに含まれる伝播情報に基づいて、当該譲渡データを伝播させるか否かを判定するステップと、
前記譲渡データを利用可能なアプリケーションプログラムを実行するステップとの処理を実行させ、
前記送信するステップは、前記アプリケーションプログラムの実行の有無に関わらず、前記判定するステップによる判定結果が肯定である場合に、前記受信するステップにより受信された前記譲渡データをさらに他の情報処理装置に送信する、処理を実行させる、情報処理装置の制御プログラム。