(57)【要約】【課題】  より効率的かつ低コストで複数の端末装置が通信できるように通信制御することが可能な通信制御システム等を提供すること。【解決手段】  通信機能を有する複数の端末装置間の通信を媒介する通信部１９０と、通信を制御する通信制御部１１８と、第２の端末装置から第１の端末装置に通知することが必要な通知情報が受信されたかどうかを判定する判定部１１４とを含んでコンピュータを構成し、通信制御部１１８を、通知情報が受信されたかどうかを確認する第１の端末装置からの確認情報が受信された場合、通知情報の有無を示す応答情報を第１の端末装置に送信しないように通信部１９０を制御し、通知情報が受信された後、当該通知情報を第１の端末装置へ向け送信するように通信部１９０を制御するように構成する。【選択図】      図２
2006004237.tif 000002
【特許請求の範囲】
【請求項１】
通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第２の端末装置から第１の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第１の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段と、
を含み、
前記第１の端末装置は、前記複数の端末装置のうちの少なくとも１台の端末装置であり、
前記第２の端末装置は、前記複数の端末装置のうちの前記第１の端末装置とは異なる少なくとも１台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第１の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第１の端末装置へ向け送信するように前記通信手段を制御することを特徴とする通信制御システム。
【請求項２】
請求項１において、
各端末装置の通信状態を示す状態データを記憶する記憶手段と、
前記通信手段の受信状況に応じて前記状態データを更新する更新手段と、
を含み、
前記判定手段は、前記通信手段と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記通信制御手段は、前記セッション数が前記しきい値を超えた場合、前記状態データに基づき、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信手段を制御することを特徴とする通信制御システム。
【請求項３】
請求項２において、
前記記憶手段は、前記端末装置ごとに当該端末装置が送信先として指定されている前記通知情報を送信データの少なくとも一部として記憶し、
前記判定手段は、各送信データが所定データ量を超えるかどうかを判定し、
前記更新手段は、所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去することを特徴とする通信制御システム。
【請求項４】
請求項２、３のいずれかにおいて、
前記記憶手段は、端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記更新手段は、前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定することを特徴とする通信制御システム。
【請求項５】
請求項１〜４のいずれかにおいて、
所定の情報を生成する情報生成手段を含み、
前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記判定手段は、前記通信手段によって受信される情報に基づき、前記第１および第２の端末装置のうち、前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記情報生成手段は、前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通信手段は、前記通知情報生成制御情報を前記他の端末装置へ向け送信することを特徴とする通信制御システム。
【請求項６】
コンピュータにより読み取り可能なプログラムであって、
コンピュータを、
通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第２の端末装置から第１の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第１の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段として機能させ、
前記第１の端末装置は、前記複数の端末装置のうちの少なくとも１台の端末装置であり、
前記第２の端末装置は、前記複数の端末装置のうちの前記第１の端末装置とは異なる少なくとも１台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第１の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第１の端末装置へ向け送信するように前記通信手段を制御することを特徴とするプログラム。
【請求項７】
コンピュータにより読み取り可能なプログラムを記憶した情報記憶媒体であって、
請求項６に記載のプログラムを記憶したことを特徴とする情報記憶媒体。
【請求項８】
通信機能を有する複数の端末装置間の通信をコンピュータが制御する通信制御方法において、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報が受信されたかどうかを確認する確認情報を受信し、
当該確認情報の送信元の端末装置に前記通知情報の有無を示す応答情報を送信しないように前記通信部を制御し、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報を受信し、
当該通知情報を前記確認情報の送信元の端末装置へ向け送信するように前記通信部を制御することを特徴とする通信制御方法。
【請求項９】
請求項８において、
前記通信部と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記セッション数が前記しきい値を超えた場合、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信部を制御することを特徴とする通信制御方法。
【請求項１０】
請求項８、９のいずれかにおいて、
前記端末装置ごとに送信データを記憶し、
前記通知情報を受信した場合、当該通知情報を、送信先として指定されている端末装置用の前記送信データの少なくとも一部として記憶し、
各送信データが所定データ量を超えるかどうかを判定し、
所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去することを特徴とする通信制御方法。
【請求項１１】
請求項１０において、
端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定することを特徴とする通信制御方法。
【請求項１２】
請求項８〜１１のいずれかにおいて、
前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通知情報生成制御情報を前記他の端末装置へ向け送信することを特徴とする通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の端末装置と通信を行う通信制御システム、プログラム、情報記憶媒体および通信制御方法に関する。
【背景技術】
【０００２】
例えば、複数の携帯電話間でサーバーを介して将棋等の対戦型通信ゲームを行う場合、ＨＴＴＰプロトコルを使用して通信が行われる。ＨＴＴＰプロトコルを使用してパケット通信を行う場合、各携帯電話は、対戦相手の携帯電話から応答があったかどうかをサーバーに問い合わせ（いわゆるポーリング）、サーバーは、即座に応答の有無を示すパケットを携帯電話に送信する。
【０００３】
このような場合、携帯電話のユーザーにとっては、ゲームとは関係のない通信によってパケット料を課金されることになり、不満を感じる原因となる。特に、相手からの応答がない場合、携帯電話はサーバーに何度も応答の有無を確認する必要があるため、携帯電話とサーバーとの間でゲームとは関係のないパケット通信が行われることになる。
【０００４】
このような通信料金を低減することを目的として、特許文献１の情報通信方法では、サーバーと、端末装置との間に接続された通信路が解放された後、通信路が未接続の状態で、端末装置が、サーバーからの提供情報に基づく生成情報を生成し、電話網を通じた疑似着呼サービスを用いて送信する手法が開示されている。
【特許文献１】特開平１１−２６１７２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１の手法は、無線通信回線の使用料よりも通常の電話回線の使用料の方が安いために、通信回線として、通常の電話回線を使用する手法に過ぎず、問題を技術的に解決する手法ではない。特に、特許文献１の手法は、通信回線を切り換えたり、無線通信回線を一旦切断した場合、再接続したりするため、効率的な通信の妨げとなる。
【０００６】
本発明は、上記課題に鑑みなされたものであり、その目的は、より効率的かつ低コストで複数の端末装置が通信できるように通信制御することが可能な通信制御システム、プログラム、情報記憶媒体および通信制御方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明に係る通信制御システムは、通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第２の端末装置から第１の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第１の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段と、
を含み、
前記第１の端末装置は、前記複数の端末装置のうちの少なくとも１台の端末装置であり、
前記第２の端末装置は、前記複数の端末装置のうちの前記第１の端末装置とは異なる少なくとも１台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第１の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第１の端末装置へ向け送信するように前記通信手段を制御することを特徴とする。
【０００８】
また、本発明に係るプログラムは、コンピュータにより読み取り可能なプログラムであって、
コンピュータを、
通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第２の端末装置から第１の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第１の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段として機能させ
前記第１の端末装置は、前記複数の端末装置のうちの少なくとも１台の端末装置であり、
前記第２の端末装置は、前記複数の端末装置のうちの前記第１の端末装置とは異なる少なくとも１台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第１の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第１の端末装置へ向け送信するように前記通信手段を制御することを特徴とする。
【０００９】
また、本発明に係る情報記憶媒体は、コンピュータにより読み取り可能なプログラムを記憶した情報記憶媒体であって、
上記プログラムを記憶したことを特徴とする。
【００１０】
本発明に係る通信制御方法は、通信機能を有する複数の端末装置間の通信をコンピュータが制御する通信制御方法において、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報が受信されたかどうかを確認する確認情報を受信し、
当該確認情報の送信元の端末装置に前記通知情報の有無を示す応答情報を送信しないように前記通信部を制御し、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報を受信し、
当該通知情報を前記確認情報の送信元の端末装置へ向け送信するように前記通信部を制御することを特徴とする。
【００１１】
本発明によれば、通信制御システム等は、確認情報を受信した場合であっても応答情報を送信しないように制御し、通知情報を受信した時点で当該通知情報を送信することにより、必要最小限の通信で複数の端末装置間の通信を媒介することができる。これにより、複数の端末装置は、より効率的かつ低コストで通信することができる。
【００１２】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体は、各端末装置の通信状態を示す状態データを記憶する記憶手段と、
前記通信手段の受信状況に応じて前記状態データを更新する更新手段と、
を含み、
前記判定手段は、前記通信手段と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記通信制御手段は、前記セッション数が前記しきい値を超えた場合、前記状態データに基づき、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信手段を制御してもよい。
【００１３】
また、前記通信制御方法は、前記通信部と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記セッション数が前記しきい値を超えた場合、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信部を制御してもよい。
【００１４】
これによれば、通信制御システム等は、常にしきい値以下のセッション数で端末装置と通信することができるため、通信の度にセッションの開始、終了を行う場合と比べ、端末装置は、より効率的に通信することができる。
【００１５】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体において、前記記憶手段は、前記端末装置ごとに当該端末装置が送信先として指定されている前記通知情報を送信データの少なくとも一部として記憶し、
前記判定手段は、各送信データが所定データ量を超えるかどうかを判定し、
前記更新手段は、所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去してもよい。
【００１６】
また、前記通信制御方法は、前記端末装置ごとに送信データを記憶し、
前記通知情報を受信した場合、当該通知情報を、送信先として指定されている端末装置用の前記送信データの少なくとも一部として記憶し、
各送信データが所定データ量を超えるかどうかを判定し、
所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去してもよい。
【００１７】
これによれば、通信制御システム等は、常に所定データ量以下の送信データを用いて端末装置と通知情報を送受信することができる。これにより、通信制御システム等は、必要となる記憶容量の増加を低減することができる。また、これによれば、通信制御システム等は、通知情報を送信データとして一旦記憶しておくことにより、万が一端末装置が通知情報を受信できない場合であっても、通知情報を再送することができる。
【００１８】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体において、前記記憶手段は、端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記更新手段は、前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定してもよい。
【００１９】
また、前記通信制御方法は、端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定してもよい。
【００２０】
これによれば、通信制御システム等は、端末装置間の関連づけ（例えば、対戦相手同士としての関連づけ等）に応じて通知情報を記憶すべき送信データを決定することができる。
【００２１】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体は、所定の情報を生成する情報生成手段を含み、
前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記判定手段は、前記通信手段によって受信される情報に基づき、前記第１および第２の端末装置のうち、前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記情報生成手段は、前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通信手段は、前記通知情報生成制御情報を前記他の端末装置へ向け送信してもよい。
【００２２】
また、前記通信制御方法において、前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通知情報生成制御情報を前記他の端末装置へ向け送信してもよい。
【００２３】
これによれば、端末装置は、通知情報生成制御情報を受信することにより、終了端末装置が送信していた通知情報を生成して送信することができる。これにより、端末装置は、いわゆる代打ちの機能（実際のプレイヤーに代わってコンピュータプレイヤーが操作する機能）を実現することができる。また、この場合、端末装置がゲーム演算を行うことにより、通信制御システムに負荷はかからないため、代打ちを行う場合であっても、通信制御システムは、効率的に通信制御することができる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明を、複数の携帯電話間の通信を媒介する通信制御システムに適用した場合を例に採り、図面を参照しつつ説明する。なお、以下に示す実施形態は、特許請求の範囲に記載された発明の内容を何ら限定するものではない。また、以下の実施形態に示す構成の全てが、特許請求の範囲に記載された発明の解決手段として必須であるとは限らない。
【００２５】
（システム全体の説明）
図１は、本実施形態の一例に係るシステム全体の概略図である。
【００２６】
本システムは、通信制御システムとして機能するサーバー１００と、サーバー１００とネットワーク３００を介して接続されている端末装置の一種である携帯電話２００とを含んで構成されている。なお、説明を簡単にするため、ここでは、２台の携帯電話２００−１、２００−２間で対戦型通信ゲームを行う場合を例に採り説明する。もちろん、３台以上の携帯電話２００間でゲームを行う場合にも本発明を適用可能である。
【００２７】
携帯電話２００は、ＨＴＴＰプロトコルに従った通信方式でサーバー１００との間で情報を送受信する。サーバー１００は、携帯電話２００−１、２００−２間の通信を媒介する。
【００２８】
次に、従来のサーバーと、携帯電話２００−１、２００−２との情報送受信手順について説明する。
【００２９】
図２は、従来の通信手順を示す模式図である。
【００３０】
携帯電話２００−１は、自分の操作情報をサーバーに送信した後、ＨＴＴＰプロトコルに従った通信方式でサーバーに相手からの応答あるかどうかを問い合わせる情報を送信する。
【００３１】
サーバーは、相手からの応答があるかどうかを示す情報を、ＨＴＴＰプロトコルに従った通信方式で携帯電話２００−１に送信する。
【００３２】
図２に示すように、ＨＴＴＰプロトコルに従った通信方式の場合、サーバーは、相手からの応答がない場合であっても、応答がないことを示す情報を携帯電話２００−１に送信し、携帯電話２００−１は、応答があるまで何度もサーバーに問い合わせる必要がある。
【００３３】
特に、携帯電話２００の場合、一般的には、従量制のパケット通信方式が採用されているため、何度もサーバーに問い合わせることにより、ゲームとは関係のないパケット通信料金が多大となってしまっていた。
【００３４】
また、常時接続方式の場合であっても、携帯電話２００−１が問い合わせの情報を送信してから応答ありという情報を受信するまでの時間がかかる上、同じ問い合わせのために何度も情報を送受信することは伝送帯域を無駄に使用することになる。
【００３５】
次に、本実施形態におけるサーバー１００と、携帯電話２００−１、２００−２との情報送受信手順について説明する。
【００３６】
図３は、本実施形態の一例に係る通信手順を示す模式図である。
【００３７】
本実施形態におけるサーバー１００は、第１の端末装置である携帯電話２００−１から通知情報の有無を確認するための確認情報を受信した場合、即座に通知情報の有無を示す応答情報を送信せず、第２の端末装置である携帯電話２００−２から操作情報等の通知情報を受信した場合、当該通知情報（当該通知情報を変形した情報も含む。）を携帯電話２００−１に送信する。
【００３８】
これにより、より効率的かつ低コストで複数の携帯電話２００間の通信を制御することが可能となる。
【００３９】
次に、このような機能を実装するためのサーバー１００の機能ブロックについて説明する。
【００４０】
図４は、本実施形態の一例に係るサーバー１００の機能ブロック図である。
【００４１】
サーバー１００は、所定の処理を行う処理部１１０と、所定のデータを記憶する記憶部１２０と、日時を示す日時情報を出力するタイマー部１３０と、携帯電話２００と情報を送受信する通信部１９０とを含んで構成されている。
【００４２】
また、記憶部１２０は、ゲームの画像データ等であるゲームデータ１２２と、ユーザーデータ１２４と、送信データ１２６と、通信状況データ１２８とを記憶している。
【００４３】
また、処理部１１０は、情報を生成する情報生成部１１２と、判定部１１４と、ユーザーデータ１２４等を更新する更新部１１６と、通信制御部１１８とを含んで構成されている。
【００４４】
ここで、ユーザーデータ１２４のデータ構造について説明する。
【００４５】
図５は、本実施形態の一例に係るユーザーデータ１２４のデータ構造を示す模式図である。
【００４６】
ユーザーデータ１２４は、各プレイヤーの対戦相手や現在の状態等を示すデータである。ユーザーデータ１２４の項目としては、例えば、「ユーザーＩＤ」、対戦相手のユーザーＩＤを示す「対戦相手ＩＤ」、携帯電話２００が情報を送信した最新の日時を示す「送信日時」、各携帯電話２００の状態を示す「状態」等が該当する。なお、「対戦相手ＩＤ」は携帯電話２００ごとの相互の関連づけを示す相手データの一種である。また、「送信日時」および「状態」は、通信状態を示す状態データの一種である。
【００４７】
図５に示す例では、例えば、「ユーザーＩＤ」が「Ｕ００１」のユーザーは、「対戦相手」が「Ｕ００２」であり、２００４年１０月１０日２０時１０分に情報を送信し、現在は相手からの情報の「受信待ち」であることを示している。
【００４８】
次に、送信データ１２６のデータ構造について説明する。
【００４９】
図６は、本実施形態の一例に係る送信データ１２６のデータ構造を示す模式図である。
【００５０】
送信データ１２６は、ユーザーごとに設けられるいわゆる受信箱のような機能を有するデータである。送信データ１２６の項目としては、例えば、「送信元」、「送信日時」、「内容」等が該当する。
【００５１】
例えば、「ユーザーＩＤ」が「Ｕ００１」のユーザー用の送信データ１２６−１には、「ユーザーＩＤ」が「Ｕ００２」の携帯電話２００−２から送信された情報（通知情報を含む。）の送信日時と内容等が含まれる。
【００５２】
サーバー１００は、ユーザーごとに送信データ１２６を使用することにより、万が一送信に失敗した場合であっても情報を再送することができる。
【００５３】
また、送信データ１２６は、一定の記憶容量に制限されていてもよい。これによれば、記憶部１２０に必要となる記憶容量を抑制することができる。
【００５４】
また、通信状況データ１２８は、維持された状態（接続中）のセッション数を示すデータである。更新部２１６は、通信部１９０の通信状況に応じて通信状況データ１２８を更新する。
【００５５】
なお、上述したサーバー１００の各部の機能は、通信部１９０としては例えばルーター等、処理部１１０としては例えばＣＰＵや画像処理回路等、記憶部１２０としては例えばＨＤＤ等、タイマー部１３０としては例えばシステムタイマー等を用いてコンピュータに実装することが可能である。
【００５６】
また、コンピュータを上述した通信制御部１１８等として機能させるためのプログラムが記憶された情報記憶媒体１８０から当該コンピュータがプログラムを読み取って上述した通信制御部１１８等を実装することも可能である。
【００５７】
また、コンピュータは、情報記憶媒体１８０からではなく、例えば、ネットワークを介して所定のホスト端末等からプログラムを読み取って上述したサーバー１００の各部の機能を実装することも可能である。
【００５８】
なお、情報記憶媒体１８０としては、例えば、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＩＣカード、ＲＯＭ、ＲＡＭ、メモリカード、ＨＤＤ等のレーザーや磁気等を用いた記憶媒体を適用できる。また、情報記憶媒体１８０からのプログラムの読み取り方式は、接触式でも非接触式でもよい。
【００５９】
次に、携帯電話２００の機能ブロックについて説明する。
【００６０】
図７は、本実施形態の一例に係る携帯電話２００の機能ブロック図である。
【００６１】
携帯電話２００は、処理部２１０と、記憶部２２０と、操作部２３０と、出力部２５０と、通信部２９０とを含んで構成されている。
【００６２】
また、記憶部２２０は、ゲームプログラム２２２と、ゲーム状況を示すゲーム状況データ２２４とを記憶している。
【００６３】
また、処理部２１０は、通知情報や確認情報等を生成する情報生成部２１２と、ゲーム状況等を判定する判定部２１４と、ゲーム状況データ２２４等を更新する更新部２１６とを含んで構成されている。
【００６４】
また、出力部２５０は、表示部２５２と、音声出力部２５４とを含んで構成されている。
【００６５】
なお、携帯電話２００としては、市販の携帯電話を適用可能である。
【００６６】
次に、これらの各部を用いた処理の流れについて説明する。
【００６７】
図８は、接続からゲーム終了までの処理の流れを示すフローチャートである。
【００６８】
判定部１１４は、通信部１９０によって携帯電話２００からの接続要求を示す情報が受信されたかどうかを判定する（ステップＳ１）。
【００６９】
接続要求を示す情報が受信された場合、判定部１１４は、通信状況データ１２８を参照して現在のセッション数がしきい値を超えていないかどうかを判定する（ステップＳ２）。
【００７０】
しきい値を超えている場合、通信部１９０は、最も古い（最も長い間使用されていない）セッションを終了する（ステップＳ１１）。また、これに伴い、更新部１１６は、通信状況データ１２８におけるセッション数を１つ減少させる。
【００７１】
セッション数がしきい値を超えていない場合、通信部１９０は、接続要求に応じて携帯電話２００とセッションを開始する（ステップＳ３）。なお、通信部１９０は、ゲーム終了までセッションを維持する。これにより、サーバー１００は、より効率的に携帯電話２００との通信を実行することができる。また、セッションの開始後、更新部１１６は、通信状況データ１２８におけるセッション数を１つ増加させる。
【００７２】
判定部１１４は、ゲームにおける対戦相手を決定し、更新部１１６は、ユーザーデータ１２４を更新する（ステップＳ４）。より具体的には、更新部１１６は、ユーザーデータ１２４における「対戦相手ＩＤ」を更新する。
【００７３】
そして、判定部１１４は、通信部１９０によって携帯電話２００−２からの操作情報が受信されたかどうかを判定する（ステップＳ５）。なお、通信部１９０は、携帯電話２００−１からの確認情報（携帯電話２００−２から応答があったかどうかを確認する情報）を既に受信しているものと仮定する。また、判定部１１４は、携帯電話２００から何らかの情報を受信した場合、相手に通知する必要があるかどうかを判定してもよい。例えば、ゲームを実行するために必要となる画像情報や文字情報の要求情報は相手に通知する必要はない。
【００７４】
操作情報が受信されていない場合、判定部１１４は、ユーザーデータ１２４の「状態」が「受信待ち」になっているユーザーの「送信日時」とタイマー部１３０のタイマー値を参照して送信してから所定時間（例えば、３０分等）が経過してタイムアウトになっているかどうかを判定する（ステップＳ１２）。
【００７５】
タイムアウトになっていない場合は、操作情報の受信を待つ。また、タイムアウトになっている場合、情報生成部１１２が、携帯電話２００−２のプレイヤーからコンピュータプレイヤーに変更するための変更情報を生成し、通信部１９０が、当該変更情報を携帯電話２００−１へ向け送信することにより、コンピュータプレイヤーに変更する（ステップＳ１３）。なお、コンピュータプレイヤーへの変更の具体的な処理手順については後述する。
【００７６】
また、操作情報が受信された場合、情報生成部１１２は、受信完了通知情報を生成し、通信部１９０は、受信完了通知情報を携帯電話２００−２へ向け送信する（ステップＳ６）。
【００７７】
判定部１１４は、携帯電話２００−１用の送信データ１２６−１が新たなデータを記憶するための十分な空き容量を有しているかどうかを判定する（ステップＳ７）。
【００７８】
空き容量が十分ではない場合、更新部１１６は、送信データ１２６−１内の最も古いデータ（最も長い間使用されていないデータ）を消去する（ステップＳ１４）。
【００７９】
空き容量が十分である場合、更新部１１６は、ユーザーデータ１２４と送信データ１２６を更新する（ステップＳ８）。より具体的には、更新部１１６は、ユーザーＩＤが「Ｕ００２」の「送信日時」を更新し、「状態」を「受信待ち」に更新し、ユーザーＩＤが「Ｕ００１」の「状態」を「受信待ち」から「要送信」に更新する。また、更新部１１６は、携帯電話２００−２から送信された操作情報に基づき、ユーザーＩＤが「Ｕ００１」のユーザー用の送信データ１２６−１の「送信元」、「送信日時」および「内容」を更新する。
【００８０】
そして、通信部１９０は、携帯電話２００−２からの操作情報を携帯電話２００−１へ向け送信する（ステップＳ９）。携帯電話２００−１の通信部２９０は、当該操作情報を受信する。情報生成部２１２は、当該操作情報と、ゲームプログラム２２２とに基づいてゲーム演算を行ってゲーム用の画像情報や音声情報を生成する。表示部２５２は、当該画像情報に基づき、ゲーム画像を表示し、音声出力部２５４は、当該音声情報に基づき、ゲーム音を出力する。
【００８１】
そして、携帯電話２００−１の情報生成部２１２は、操作部２３０からの情報に基づき、操作情報を生成し、通信部２９０は、当該操作情報をサーバー１００へ向け送信する。
【００８２】
以上の手順により、各携帯電話２００は、他の携帯電話２００からの操作情報に基づいて対戦型通信ゲームを実行することができる。
【００８３】
判定部１１４は、携帯電話２００から送信される情報に基づき、ゲーム終了かどうかを判定し（ステップＳ１０）、サーバー１００は、ゲーム終了ではない場合、直前に操作情報を受信した携帯電話２００−２から確認情報を受信し（ステップＳ１５）、ステップＳ５〜Ｓ１５の処理を繰り返し実行する。なお、通信制御部１１８は、確認情報の受信後、通信部１９０が応答の有無を示す応答情報を送信しないように、通信部１９０を制御する。
【００８４】
以上のように、本実施形態によれば、サーバー１００は、確認情報を受信した場合であっても応答情報を送信しないように制御し、通知情報を受信した時点で当該通知情報を送信することにより、必要最小限の通信で複数の端末装置間の通信を媒介することができる。これにより、各携帯電話２００は、より効率的かつ低コストで通信することができる。
【００８５】
特に、ＨＴＴＰプロトコルとパケット通信を用いて対戦型通信ゲームを行う場合であっても、従来よりもパケット通信料金を低減できるため、プレイヤーは、気軽に対戦型通信ゲームを楽しむことができる。
【００８６】
また、本実施形態によれば、サーバー１００は、常に所定データ量以下の送信データ１２６を用いて携帯電話２００と通知情報を送受信することができる。これにより、サーバー１００は、必要となる記憶部１２０の記憶容量の増加を低減することができる。また、これによれば、サーバー１００は、通知情報を送信データ１２６として一旦記憶しておくことにより、万が一携帯電話２００が通知情報を受信できない場合であっても、通知情報を再送することができる。
【００８７】
また、本実施形態によれば、サーバー１００は、携帯電話２００間の関連づけ（例えば、対戦相手同士としての関連づけ等）を示すユーザーデータ１２４を用いることにより、当該関連づけに応じて通知情報を記憶すべき送信データ１２６を決定することができる。そして、更新部１１６は、関連づけに応じて携帯電話２００ごとの送信データ１２６を更新する。
【００８８】
これにより、サーバー１００は、単に通知情報を逐次記憶して管理する場合と比べ、より効率的に処理することができる。
【００８９】
また、サーバー１００は、ゲーム実行中はセッションを維持し、セッション数の合計値がしきい値を超えた場合には古いセッションを終了することにより、より効率的かつ低コストで複数の携帯電話２００間の通信を制御することができる。
【００９０】
（コンピュータプレイヤーへの変更手順についての説明）
ここで、代打ちを携帯電話２００が実行するためのコンピュータプレイヤーへの変更手順についてより具体的に説明する。
【００９１】
ここでは、図１に示すように、４台の携帯電話２００−１〜２００−４が同じゲーム空間で対戦型ゲームを実行しているものと仮定する。
【００９２】
例えば、携帯電話２００−２のプレイヤーがゲーム実行中にゲームを終了する操作を行った場合、携帯電話２００−２は、ゲーム終了を示す通知情報をサーバー１００へ向け送信する。
【００９３】
通信部１９０は、ゲーム終了を示す通知情報を受信する。判定部１１４は、通信部１９０によってゲーム終了を示す通知情報が受信されたかどうかを判定することにより、対戦型通信ゲームを途中で終了した終了端末装置である携帯電話２００があるかどうかを判定する。
【００９４】
さらに、判定部１１４は、ユーザーデータ１２４の携帯電話２００−２のユーザーＩＤである「Ｕ００２」の「対戦相手ＩＤ」を参照して「Ｕ００１、Ｕ００３、Ｕ００４」が対戦相手であると判定し、代打ちを行う携帯電話２００として、例えば、「Ｕ００１」の携帯電話２００−１を選択する。
【００９５】
そして、情報生成部１１２は、途中で終了した携帯電話２００−２がある場合、判定部１１４によって選択された携帯電話２００−１が携帯電話２００−２の操作情報（通知情報）を生成するように制御する通知情報生成制御情報を生成する。
【００９６】
そして、通信部１９０は、当該通知情報生成制御情報を携帯電話２００−１へ送信する。
【００９７】
携帯電話２００−１の通信部２９０は、当該通知情報生成制御情報を受信し、更新部２１６は、当該通知情報生成制御情報に基づき、携帯電話２００−２がゲームを終了したことを示し、携帯電話２００−１が代打ちを行う必要があることを示すように、ゲーム状況データ２２４を更新する。
【００９８】
判定部２１４は、ゲーム状況データ２２４に基づき、代打ちを行う必要があると判定した場合、携帯電話２００−２用の操作情報を生成するように情報生成部２１２を制御する。情報生成部２１２は、ゲーム演算を行って携帯電話２００−２用の操作情報を生成し、通信部２９０は、当該操作情報をサーバー１００へ向け送信する。
【００９９】
以上の手順により、サーバー１００と携帯電話２００は、代打ち機能を実現することができる。また、この場合、携帯電話２００がゲーム演算を行うことにより、サーバー１００にゲーム演算の負荷はかからない。このため、代打ちを行う場合であっても、サーバー１００は、効率的に通信制御することができる。
【０１００】
さらに、例えば、４台の携帯電話２００が存在している状態で、２台の携帯電話２００がゲームを途中で終了した場合、通信制御部１１８は、残りの２台の携帯電話２００がそれぞれ１台分の操作情報を生成するように、通信制御してもよい。これにより、複数の携帯電話２００が分散して代打ちを行うことができるため、通信制御部１１８は、１台あたりの処理負荷が過負荷にならないように携帯電話２００を制御することができる。
【０１０１】
（変形例）
以上、本発明を適用した好適な実施例について説明したが、本発明は上述した実施例に限定されず、種々の変形が可能である。
【０１０２】
例えば、上述した実施例ではゲーム開始から終了までセッションを維持したが、変形例として、通信制御部１１８は、セッションの開始と終了を逐次行ってもよい。
【０１０３】
この場合、通信制御部１１８を、通信部１９０が各携帯電話２００とセッションを開始して確認情報を受信した場合、通知情報を送信するまで当該セッションを維持し、通知情報を送信した後に当該セッションを終了するように通信部１９０を制御してもよい。
【０１０４】
これによれば、サーバー１００は、セッションを維持したままの状態で通知情報の受信を待つころにより、通知情報を受信した場合、即座に通知情報を携帯電話２００に送信することができる。これにより、複数の携帯電話２００は、より効率的かつ低コストで通信することができる。
【０１０５】
また、例えば、通信方式はパケット通信方式に限定されず、例えば、常時接続方式等であってもよい。また、使用するプロトコルはＨＴＴＰに限定されず、例えば、ＦＴＰ、ＴＣＰ／ＩＰ等であってもよい。
【０１０６】
また、上述した通信制御システムとして機能するサーバー１００の機能を複数の装置に分散して実装してもよい。
【０１０７】
また、上述した実施例では、端末装置として携帯電話２００を用いた場合を例に採り説明したが、端末装置として、例えば、ＰＣ、ＰＤＡ、携帯型ゲーム装置、家庭用ゲーム装置、業務用ゲーム装置等を適用してもよい。
【０１０８】
また、上述した対戦型通信ゲームとしては、具体的には、例えば、コマンド形式の対戦バトルゲーム、五目並べ、リバーシ、７並べ等の対戦型トランプゲーム、将棋、囲碁、対戦型パズルゲーム等の種々のゲームを採用可能である。
【図面の簡単な説明】
【０１０９】
【図１】本実施形態の一例に係るシステム全体の概略図である。
【図２】従来の通信手順を示す模式図である。
【図３】本実施形態の一例に係る通信手順を示す模式図である。
【図４】本実施形態の一例に係るサーバーの機能ブロック図である。
【図５】本実施形態の一例に係るユーザーデータのデータ構造を示す模式図である。
【図６】本実施形態の一例に係る送信データのデータ構造を示す模式図である。
【図７】本実施形態の一例に係る携帯電話の機能ブロック図である。
【図８】接続からゲーム終了までの処理の流れを示すフローチャートである。
【符号の説明】
【０１１０】
１００  サーバー（通信制御システム）
１１２  情報生成部
１１４  判定部
１１６  通信制御部
１２０  記憶部
１２４  ユーザーデータ（相手データ、状態データ）
１２６  送信データ
１２８  通信状況データ
１３０  タイマー部
１８０  情報記憶媒体
１９０  通信部
２００  携帯電話（端末装置）
【図１】
2006004237.tif 000003
【図２】
2006004237.tif 000004
【図３】
2006004237.tif 000005
【図４】
2006004237.tif 000006
【図５】
2006004237.tif 000007
【図６】
2006004237.tif 000008
【図７】
2006004237.tif 000009
【図８】
2006004237.tif 000010