説明

通信制御システム、プログラム、情報記憶媒体および通信制御方法

【課題】 より効率的かつ低コストで複数の端末装置が通信できるように通信制御することが可能な通信制御システム等を提供すること。
【解決手段】 通信機能を有する複数の端末装置間の通信を媒介する通信部190と、通信を制御する通信制御部118と、第2の端末装置から第1の端末装置に通知することが必要な通知情報が受信されたかどうかを判定する判定部114とを含んでコンピュータを構成し、通信制御部118を、通知情報が受信されたかどうかを確認する第1の端末装置からの確認情報が受信された場合、通知情報の有無を示す応答情報を第1の端末装置に送信しないように通信部190を制御し、通知情報が受信された後、当該通知情報を第1の端末装置へ向け送信するように通信部190を制御するように構成する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数の端末装置と通信を行う通信制御システム、プログラム、情報記憶媒体および通信制御方法に関する。
【背景技術】
【0002】
例えば、複数の携帯電話間でサーバーを介して将棋等の対戦型通信ゲームを行う場合、HTTPプロトコルを使用して通信が行われる。HTTPプロトコルを使用してパケット通信を行う場合、各携帯電話は、対戦相手の携帯電話から応答があったかどうかをサーバーに問い合わせ(いわゆるポーリング)、サーバーは、即座に応答の有無を示すパケットを携帯電話に送信する。
【0003】
このような場合、携帯電話のユーザーにとっては、ゲームとは関係のない通信によってパケット料を課金されることになり、不満を感じる原因となる。特に、相手からの応答がない場合、携帯電話はサーバーに何度も応答の有無を確認する必要があるため、携帯電話とサーバーとの間でゲームとは関係のないパケット通信が行われることになる。
【0004】
このような通信料金を低減することを目的として、特許文献1の情報通信方法では、サーバーと、端末装置との間に接続された通信路が解放された後、通信路が未接続の状態で、端末装置が、サーバーからの提供情報に基づく生成情報を生成し、電話網を通じた疑似着呼サービスを用いて送信する手法が開示されている。
【特許文献1】特開平11−261724号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
しかし、特許文献1の手法は、無線通信回線の使用料よりも通常の電話回線の使用料の方が安いために、通信回線として、通常の電話回線を使用する手法に過ぎず、問題を技術的に解決する手法ではない。特に、特許文献1の手法は、通信回線を切り換えたり、無線通信回線を一旦切断した場合、再接続したりするため、効率的な通信の妨げとなる。
【0006】
本発明は、上記課題に鑑みなされたものであり、その目的は、より効率的かつ低コストで複数の端末装置が通信できるように通信制御することが可能な通信制御システム、プログラム、情報記憶媒体および通信制御方法を提供することにある。
【課題を解決するための手段】
【0007】
上記課題を解決するため、本発明に係る通信制御システムは、通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第2の端末装置から第1の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第1の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段と、
を含み、
前記第1の端末装置は、前記複数の端末装置のうちの少なくとも1台の端末装置であり、
前記第2の端末装置は、前記複数の端末装置のうちの前記第1の端末装置とは異なる少なくとも1台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第1の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第1の端末装置へ向け送信するように前記通信手段を制御することを特徴とする。
【0008】
また、本発明に係るプログラムは、コンピュータにより読み取り可能なプログラムであって、
コンピュータを、
通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第2の端末装置から第1の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第1の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段として機能させ
前記第1の端末装置は、前記複数の端末装置のうちの少なくとも1台の端末装置であり、
前記第2の端末装置は、前記複数の端末装置のうちの前記第1の端末装置とは異なる少なくとも1台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第1の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第1の端末装置へ向け送信するように前記通信手段を制御することを特徴とする。
【0009】
また、本発明に係る情報記憶媒体は、コンピュータにより読み取り可能なプログラムを記憶した情報記憶媒体であって、
上記プログラムを記憶したことを特徴とする。
【0010】
本発明に係る通信制御方法は、通信機能を有する複数の端末装置間の通信をコンピュータが制御する通信制御方法において、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報が受信されたかどうかを確認する確認情報を受信し、
当該確認情報の送信元の端末装置に前記通知情報の有無を示す応答情報を送信しないように前記通信部を制御し、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報を受信し、
当該通知情報を前記確認情報の送信元の端末装置へ向け送信するように前記通信部を制御することを特徴とする。
【0011】
本発明によれば、通信制御システム等は、確認情報を受信した場合であっても応答情報を送信しないように制御し、通知情報を受信した時点で当該通知情報を送信することにより、必要最小限の通信で複数の端末装置間の通信を媒介することができる。これにより、複数の端末装置は、より効率的かつ低コストで通信することができる。
【0012】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体は、各端末装置の通信状態を示す状態データを記憶する記憶手段と、
前記通信手段の受信状況に応じて前記状態データを更新する更新手段と、
を含み、
前記判定手段は、前記通信手段と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記通信制御手段は、前記セッション数が前記しきい値を超えた場合、前記状態データに基づき、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信手段を制御してもよい。
【0013】
また、前記通信制御方法は、前記通信部と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記セッション数が前記しきい値を超えた場合、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信部を制御してもよい。
【0014】
これによれば、通信制御システム等は、常にしきい値以下のセッション数で端末装置と通信することができるため、通信の度にセッションの開始、終了を行う場合と比べ、端末装置は、より効率的に通信することができる。
【0015】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体において、前記記憶手段は、前記端末装置ごとに当該端末装置が送信先として指定されている前記通知情報を送信データの少なくとも一部として記憶し、
前記判定手段は、各送信データが所定データ量を超えるかどうかを判定し、
前記更新手段は、所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去してもよい。
【0016】
また、前記通信制御方法は、前記端末装置ごとに送信データを記憶し、
前記通知情報を受信した場合、当該通知情報を、送信先として指定されている端末装置用の前記送信データの少なくとも一部として記憶し、
各送信データが所定データ量を超えるかどうかを判定し、
所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去してもよい。
【0017】
これによれば、通信制御システム等は、常に所定データ量以下の送信データを用いて端末装置と通知情報を送受信することができる。これにより、通信制御システム等は、必要となる記憶容量の増加を低減することができる。また、これによれば、通信制御システム等は、通知情報を送信データとして一旦記憶しておくことにより、万が一端末装置が通知情報を受信できない場合であっても、通知情報を再送することができる。
【0018】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体において、前記記憶手段は、端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記更新手段は、前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定してもよい。
【0019】
また、前記通信制御方法は、端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定してもよい。
【0020】
これによれば、通信制御システム等は、端末装置間の関連づけ(例えば、対戦相手同士としての関連づけ等)に応じて通知情報を記憶すべき送信データを決定することができる。
【0021】
また、前記通信制御システム、前記プログラムおよび前記情報記憶媒体は、所定の情報を生成する情報生成手段を含み、
前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記判定手段は、前記通信手段によって受信される情報に基づき、前記第1および第2の端末装置のうち、前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記情報生成手段は、前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通信手段は、前記通知情報生成制御情報を前記他の端末装置へ向け送信してもよい。
【0022】
また、前記通信制御方法において、前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通知情報生成制御情報を前記他の端末装置へ向け送信してもよい。
【0023】
これによれば、端末装置は、通知情報生成制御情報を受信することにより、終了端末装置が送信していた通知情報を生成して送信することができる。これにより、端末装置は、いわゆる代打ちの機能(実際のプレイヤーに代わってコンピュータプレイヤーが操作する機能)を実現することができる。また、この場合、端末装置がゲーム演算を行うことにより、通信制御システムに負荷はかからないため、代打ちを行う場合であっても、通信制御システムは、効率的に通信制御することができる。
【発明を実施するための最良の形態】
【0024】
以下、本発明を、複数の携帯電話間の通信を媒介する通信制御システムに適用した場合を例に採り、図面を参照しつつ説明する。なお、以下に示す実施形態は、特許請求の範囲に記載された発明の内容を何ら限定するものではない。また、以下の実施形態に示す構成の全てが、特許請求の範囲に記載された発明の解決手段として必須であるとは限らない。
【0025】
(システム全体の説明)
図1は、本実施形態の一例に係るシステム全体の概略図である。
【0026】
本システムは、通信制御システムとして機能するサーバー100と、サーバー100とネットワーク300を介して接続されている端末装置の一種である携帯電話200とを含んで構成されている。なお、説明を簡単にするため、ここでは、2台の携帯電話200−1、200−2間で対戦型通信ゲームを行う場合を例に採り説明する。もちろん、3台以上の携帯電話200間でゲームを行う場合にも本発明を適用可能である。
【0027】
携帯電話200は、HTTPプロトコルに従った通信方式でサーバー100との間で情報を送受信する。サーバー100は、携帯電話200−1、200−2間の通信を媒介する。
【0028】
次に、従来のサーバーと、携帯電話200−1、200−2との情報送受信手順について説明する。
【0029】
図2は、従来の通信手順を示す模式図である。
【0030】
携帯電話200−1は、自分の操作情報をサーバーに送信した後、HTTPプロトコルに従った通信方式でサーバーに相手からの応答あるかどうかを問い合わせる情報を送信する。
【0031】
サーバーは、相手からの応答があるかどうかを示す情報を、HTTPプロトコルに従った通信方式で携帯電話200−1に送信する。
【0032】
図2に示すように、HTTPプロトコルに従った通信方式の場合、サーバーは、相手からの応答がない場合であっても、応答がないことを示す情報を携帯電話200−1に送信し、携帯電話200−1は、応答があるまで何度もサーバーに問い合わせる必要がある。
【0033】
特に、携帯電話200の場合、一般的には、従量制のパケット通信方式が採用されているため、何度もサーバーに問い合わせることにより、ゲームとは関係のないパケット通信料金が多大となってしまっていた。
【0034】
また、常時接続方式の場合であっても、携帯電話200−1が問い合わせの情報を送信してから応答ありという情報を受信するまでの時間がかかる上、同じ問い合わせのために何度も情報を送受信することは伝送帯域を無駄に使用することになる。
【0035】
次に、本実施形態におけるサーバー100と、携帯電話200−1、200−2との情報送受信手順について説明する。
【0036】
図3は、本実施形態の一例に係る通信手順を示す模式図である。
【0037】
本実施形態におけるサーバー100は、第1の端末装置である携帯電話200−1から通知情報の有無を確認するための確認情報を受信した場合、即座に通知情報の有無を示す応答情報を送信せず、第2の端末装置である携帯電話200−2から操作情報等の通知情報を受信した場合、当該通知情報(当該通知情報を変形した情報も含む。)を携帯電話200−1に送信する。
【0038】
これにより、より効率的かつ低コストで複数の携帯電話200間の通信を制御することが可能となる。
【0039】
次に、このような機能を実装するためのサーバー100の機能ブロックについて説明する。
【0040】
図4は、本実施形態の一例に係るサーバー100の機能ブロック図である。
【0041】
サーバー100は、所定の処理を行う処理部110と、所定のデータを記憶する記憶部120と、日時を示す日時情報を出力するタイマー部130と、携帯電話200と情報を送受信する通信部190とを含んで構成されている。
【0042】
また、記憶部120は、ゲームの画像データ等であるゲームデータ122と、ユーザーデータ124と、送信データ126と、通信状況データ128とを記憶している。
【0043】
また、処理部110は、情報を生成する情報生成部112と、判定部114と、ユーザーデータ124等を更新する更新部116と、通信制御部118とを含んで構成されている。
【0044】
ここで、ユーザーデータ124のデータ構造について説明する。
【0045】
図5は、本実施形態の一例に係るユーザーデータ124のデータ構造を示す模式図である。
【0046】
ユーザーデータ124は、各プレイヤーの対戦相手や現在の状態等を示すデータである。ユーザーデータ124の項目としては、例えば、「ユーザーID」、対戦相手のユーザーIDを示す「対戦相手ID」、携帯電話200が情報を送信した最新の日時を示す「送信日時」、各携帯電話200の状態を示す「状態」等が該当する。なお、「対戦相手ID」は携帯電話200ごとの相互の関連づけを示す相手データの一種である。また、「送信日時」および「状態」は、通信状態を示す状態データの一種である。
【0047】
図5に示す例では、例えば、「ユーザーID」が「U001」のユーザーは、「対戦相手」が「U002」であり、2004年10月10日20時10分に情報を送信し、現在は相手からの情報の「受信待ち」であることを示している。
【0048】
次に、送信データ126のデータ構造について説明する。
【0049】
図6は、本実施形態の一例に係る送信データ126のデータ構造を示す模式図である。
【0050】
送信データ126は、ユーザーごとに設けられるいわゆる受信箱のような機能を有するデータである。送信データ126の項目としては、例えば、「送信元」、「送信日時」、「内容」等が該当する。
【0051】
例えば、「ユーザーID」が「U001」のユーザー用の送信データ126−1には、「ユーザーID」が「U002」の携帯電話200−2から送信された情報(通知情報を含む。)の送信日時と内容等が含まれる。
【0052】
サーバー100は、ユーザーごとに送信データ126を使用することにより、万が一送信に失敗した場合であっても情報を再送することができる。
【0053】
また、送信データ126は、一定の記憶容量に制限されていてもよい。これによれば、記憶部120に必要となる記憶容量を抑制することができる。
【0054】
また、通信状況データ128は、維持された状態(接続中)のセッション数を示すデータである。更新部216は、通信部190の通信状況に応じて通信状況データ128を更新する。
【0055】
なお、上述したサーバー100の各部の機能は、通信部190としては例えばルーター等、処理部110としては例えばCPUや画像処理回路等、記憶部120としては例えばHDD等、タイマー部130としては例えばシステムタイマー等を用いてコンピュータに実装することが可能である。
【0056】
また、コンピュータを上述した通信制御部118等として機能させるためのプログラムが記憶された情報記憶媒体180から当該コンピュータがプログラムを読み取って上述した通信制御部118等を実装することも可能である。
【0057】
また、コンピュータは、情報記憶媒体180からではなく、例えば、ネットワークを介して所定のホスト端末等からプログラムを読み取って上述したサーバー100の各部の機能を実装することも可能である。
【0058】
なお、情報記憶媒体180としては、例えば、CD−ROM、DVD−ROM、ICカード、ROM、RAM、メモリカード、HDD等のレーザーや磁気等を用いた記憶媒体を適用できる。また、情報記憶媒体180からのプログラムの読み取り方式は、接触式でも非接触式でもよい。
【0059】
次に、携帯電話200の機能ブロックについて説明する。
【0060】
図7は、本実施形態の一例に係る携帯電話200の機能ブロック図である。
【0061】
携帯電話200は、処理部210と、記憶部220と、操作部230と、出力部250と、通信部290とを含んで構成されている。
【0062】
また、記憶部220は、ゲームプログラム222と、ゲーム状況を示すゲーム状況データ224とを記憶している。
【0063】
また、処理部210は、通知情報や確認情報等を生成する情報生成部212と、ゲーム状況等を判定する判定部214と、ゲーム状況データ224等を更新する更新部216とを含んで構成されている。
【0064】
また、出力部250は、表示部252と、音声出力部254とを含んで構成されている。
【0065】
なお、携帯電話200としては、市販の携帯電話を適用可能である。
【0066】
次に、これらの各部を用いた処理の流れについて説明する。
【0067】
図8は、接続からゲーム終了までの処理の流れを示すフローチャートである。
【0068】
判定部114は、通信部190によって携帯電話200からの接続要求を示す情報が受信されたかどうかを判定する(ステップS1)。
【0069】
接続要求を示す情報が受信された場合、判定部114は、通信状況データ128を参照して現在のセッション数がしきい値を超えていないかどうかを判定する(ステップS2)。
【0070】
しきい値を超えている場合、通信部190は、最も古い(最も長い間使用されていない)セッションを終了する(ステップS11)。また、これに伴い、更新部116は、通信状況データ128におけるセッション数を1つ減少させる。
【0071】
セッション数がしきい値を超えていない場合、通信部190は、接続要求に応じて携帯電話200とセッションを開始する(ステップS3)。なお、通信部190は、ゲーム終了までセッションを維持する。これにより、サーバー100は、より効率的に携帯電話200との通信を実行することができる。また、セッションの開始後、更新部116は、通信状況データ128におけるセッション数を1つ増加させる。
【0072】
判定部114は、ゲームにおける対戦相手を決定し、更新部116は、ユーザーデータ124を更新する(ステップS4)。より具体的には、更新部116は、ユーザーデータ124における「対戦相手ID」を更新する。
【0073】
そして、判定部114は、通信部190によって携帯電話200−2からの操作情報が受信されたかどうかを判定する(ステップS5)。なお、通信部190は、携帯電話200−1からの確認情報(携帯電話200−2から応答があったかどうかを確認する情報)を既に受信しているものと仮定する。また、判定部114は、携帯電話200から何らかの情報を受信した場合、相手に通知する必要があるかどうかを判定してもよい。例えば、ゲームを実行するために必要となる画像情報や文字情報の要求情報は相手に通知する必要はない。
【0074】
操作情報が受信されていない場合、判定部114は、ユーザーデータ124の「状態」が「受信待ち」になっているユーザーの「送信日時」とタイマー部130のタイマー値を参照して送信してから所定時間(例えば、30分等)が経過してタイムアウトになっているかどうかを判定する(ステップS12)。
【0075】
タイムアウトになっていない場合は、操作情報の受信を待つ。また、タイムアウトになっている場合、情報生成部112が、携帯電話200−2のプレイヤーからコンピュータプレイヤーに変更するための変更情報を生成し、通信部190が、当該変更情報を携帯電話200−1へ向け送信することにより、コンピュータプレイヤーに変更する(ステップS13)。なお、コンピュータプレイヤーへの変更の具体的な処理手順については後述する。
【0076】
また、操作情報が受信された場合、情報生成部112は、受信完了通知情報を生成し、通信部190は、受信完了通知情報を携帯電話200−2へ向け送信する(ステップS6)。
【0077】
判定部114は、携帯電話200−1用の送信データ126−1が新たなデータを記憶するための十分な空き容量を有しているかどうかを判定する(ステップS7)。
【0078】
空き容量が十分ではない場合、更新部116は、送信データ126−1内の最も古いデータ(最も長い間使用されていないデータ)を消去する(ステップS14)。
【0079】
空き容量が十分である場合、更新部116は、ユーザーデータ124と送信データ126を更新する(ステップS8)。より具体的には、更新部116は、ユーザーIDが「U002」の「送信日時」を更新し、「状態」を「受信待ち」に更新し、ユーザーIDが「U001」の「状態」を「受信待ち」から「要送信」に更新する。また、更新部116は、携帯電話200−2から送信された操作情報に基づき、ユーザーIDが「U001」のユーザー用の送信データ126−1の「送信元」、「送信日時」および「内容」を更新する。
【0080】
そして、通信部190は、携帯電話200−2からの操作情報を携帯電話200−1へ向け送信する(ステップS9)。携帯電話200−1の通信部290は、当該操作情報を受信する。情報生成部212は、当該操作情報と、ゲームプログラム222とに基づいてゲーム演算を行ってゲーム用の画像情報や音声情報を生成する。表示部252は、当該画像情報に基づき、ゲーム画像を表示し、音声出力部254は、当該音声情報に基づき、ゲーム音を出力する。
【0081】
そして、携帯電話200−1の情報生成部212は、操作部230からの情報に基づき、操作情報を生成し、通信部290は、当該操作情報をサーバー100へ向け送信する。
【0082】
以上の手順により、各携帯電話200は、他の携帯電話200からの操作情報に基づいて対戦型通信ゲームを実行することができる。
【0083】
判定部114は、携帯電話200から送信される情報に基づき、ゲーム終了かどうかを判定し(ステップS10)、サーバー100は、ゲーム終了ではない場合、直前に操作情報を受信した携帯電話200−2から確認情報を受信し(ステップS15)、ステップS5〜S15の処理を繰り返し実行する。なお、通信制御部118は、確認情報の受信後、通信部190が応答の有無を示す応答情報を送信しないように、通信部190を制御する。
【0084】
以上のように、本実施形態によれば、サーバー100は、確認情報を受信した場合であっても応答情報を送信しないように制御し、通知情報を受信した時点で当該通知情報を送信することにより、必要最小限の通信で複数の端末装置間の通信を媒介することができる。これにより、各携帯電話200は、より効率的かつ低コストで通信することができる。
【0085】
特に、HTTPプロトコルとパケット通信を用いて対戦型通信ゲームを行う場合であっても、従来よりもパケット通信料金を低減できるため、プレイヤーは、気軽に対戦型通信ゲームを楽しむことができる。
【0086】
また、本実施形態によれば、サーバー100は、常に所定データ量以下の送信データ126を用いて携帯電話200と通知情報を送受信することができる。これにより、サーバー100は、必要となる記憶部120の記憶容量の増加を低減することができる。また、これによれば、サーバー100は、通知情報を送信データ126として一旦記憶しておくことにより、万が一携帯電話200が通知情報を受信できない場合であっても、通知情報を再送することができる。
【0087】
また、本実施形態によれば、サーバー100は、携帯電話200間の関連づけ(例えば、対戦相手同士としての関連づけ等)を示すユーザーデータ124を用いることにより、当該関連づけに応じて通知情報を記憶すべき送信データ126を決定することができる。そして、更新部116は、関連づけに応じて携帯電話200ごとの送信データ126を更新する。
【0088】
これにより、サーバー100は、単に通知情報を逐次記憶して管理する場合と比べ、より効率的に処理することができる。
【0089】
また、サーバー100は、ゲーム実行中はセッションを維持し、セッション数の合計値がしきい値を超えた場合には古いセッションを終了することにより、より効率的かつ低コストで複数の携帯電話200間の通信を制御することができる。
【0090】
(コンピュータプレイヤーへの変更手順についての説明)
ここで、代打ちを携帯電話200が実行するためのコンピュータプレイヤーへの変更手順についてより具体的に説明する。
【0091】
ここでは、図1に示すように、4台の携帯電話200−1〜200−4が同じゲーム空間で対戦型ゲームを実行しているものと仮定する。
【0092】
例えば、携帯電話200−2のプレイヤーがゲーム実行中にゲームを終了する操作を行った場合、携帯電話200−2は、ゲーム終了を示す通知情報をサーバー100へ向け送信する。
【0093】
通信部190は、ゲーム終了を示す通知情報を受信する。判定部114は、通信部190によってゲーム終了を示す通知情報が受信されたかどうかを判定することにより、対戦型通信ゲームを途中で終了した終了端末装置である携帯電話200があるかどうかを判定する。
【0094】
さらに、判定部114は、ユーザーデータ124の携帯電話200−2のユーザーIDである「U002」の「対戦相手ID」を参照して「U001、U003、U004」が対戦相手であると判定し、代打ちを行う携帯電話200として、例えば、「U001」の携帯電話200−1を選択する。
【0095】
そして、情報生成部112は、途中で終了した携帯電話200−2がある場合、判定部114によって選択された携帯電話200−1が携帯電話200−2の操作情報(通知情報)を生成するように制御する通知情報生成制御情報を生成する。
【0096】
そして、通信部190は、当該通知情報生成制御情報を携帯電話200−1へ送信する。
【0097】
携帯電話200−1の通信部290は、当該通知情報生成制御情報を受信し、更新部216は、当該通知情報生成制御情報に基づき、携帯電話200−2がゲームを終了したことを示し、携帯電話200−1が代打ちを行う必要があることを示すように、ゲーム状況データ224を更新する。
【0098】
判定部214は、ゲーム状況データ224に基づき、代打ちを行う必要があると判定した場合、携帯電話200−2用の操作情報を生成するように情報生成部212を制御する。情報生成部212は、ゲーム演算を行って携帯電話200−2用の操作情報を生成し、通信部290は、当該操作情報をサーバー100へ向け送信する。
【0099】
以上の手順により、サーバー100と携帯電話200は、代打ち機能を実現することができる。また、この場合、携帯電話200がゲーム演算を行うことにより、サーバー100にゲーム演算の負荷はかからない。このため、代打ちを行う場合であっても、サーバー100は、効率的に通信制御することができる。
【0100】
さらに、例えば、4台の携帯電話200が存在している状態で、2台の携帯電話200がゲームを途中で終了した場合、通信制御部118は、残りの2台の携帯電話200がそれぞれ1台分の操作情報を生成するように、通信制御してもよい。これにより、複数の携帯電話200が分散して代打ちを行うことができるため、通信制御部118は、1台あたりの処理負荷が過負荷にならないように携帯電話200を制御することができる。
【0101】
(変形例)
以上、本発明を適用した好適な実施例について説明したが、本発明は上述した実施例に限定されず、種々の変形が可能である。
【0102】
例えば、上述した実施例ではゲーム開始から終了までセッションを維持したが、変形例として、通信制御部118は、セッションの開始と終了を逐次行ってもよい。
【0103】
この場合、通信制御部118を、通信部190が各携帯電話200とセッションを開始して確認情報を受信した場合、通知情報を送信するまで当該セッションを維持し、通知情報を送信した後に当該セッションを終了するように通信部190を制御してもよい。
【0104】
これによれば、サーバー100は、セッションを維持したままの状態で通知情報の受信を待つころにより、通知情報を受信した場合、即座に通知情報を携帯電話200に送信することができる。これにより、複数の携帯電話200は、より効率的かつ低コストで通信することができる。
【0105】
また、例えば、通信方式はパケット通信方式に限定されず、例えば、常時接続方式等であってもよい。また、使用するプロトコルはHTTPに限定されず、例えば、FTP、TCP/IP等であってもよい。
【0106】
また、上述した通信制御システムとして機能するサーバー100の機能を複数の装置に分散して実装してもよい。
【0107】
また、上述した実施例では、端末装置として携帯電話200を用いた場合を例に採り説明したが、端末装置として、例えば、PC、PDA、携帯型ゲーム装置、家庭用ゲーム装置、業務用ゲーム装置等を適用してもよい。
【0108】
また、上述した対戦型通信ゲームとしては、具体的には、例えば、コマンド形式の対戦バトルゲーム、五目並べ、リバーシ、7並べ等の対戦型トランプゲーム、将棋、囲碁、対戦型パズルゲーム等の種々のゲームを採用可能である。
【図面の簡単な説明】
【0109】
【図1】本実施形態の一例に係るシステム全体の概略図である。
【図2】従来の通信手順を示す模式図である。
【図3】本実施形態の一例に係る通信手順を示す模式図である。
【図4】本実施形態の一例に係るサーバーの機能ブロック図である。
【図5】本実施形態の一例に係るユーザーデータのデータ構造を示す模式図である。
【図6】本実施形態の一例に係る送信データのデータ構造を示す模式図である。
【図7】本実施形態の一例に係る携帯電話の機能ブロック図である。
【図8】接続からゲーム終了までの処理の流れを示すフローチャートである。
【符号の説明】
【0110】
100 サーバー(通信制御システム)
112 情報生成部
114 判定部
116 通信制御部
120 記憶部
124 ユーザーデータ(相手データ、状態データ)
126 送信データ
128 通信状況データ
130 タイマー部
180 情報記憶媒体
190 通信部
200 携帯電話(端末装置)

【特許請求の範囲】
【請求項1】
通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第2の端末装置から第1の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第1の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段と、
を含み、
前記第1の端末装置は、前記複数の端末装置のうちの少なくとも1台の端末装置であり、
前記第2の端末装置は、前記複数の端末装置のうちの前記第1の端末装置とは異なる少なくとも1台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第1の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第1の端末装置へ向け送信するように前記通信手段を制御することを特徴とする通信制御システム。
【請求項2】
請求項1において、
各端末装置の通信状態を示す状態データを記憶する記憶手段と、
前記通信手段の受信状況に応じて前記状態データを更新する更新手段と、
を含み、
前記判定手段は、前記通信手段と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記通信制御手段は、前記セッション数が前記しきい値を超えた場合、前記状態データに基づき、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信手段を制御することを特徴とする通信制御システム。
【請求項3】
請求項2において、
前記記憶手段は、前記端末装置ごとに当該端末装置が送信先として指定されている前記通知情報を送信データの少なくとも一部として記憶し、
前記判定手段は、各送信データが所定データ量を超えるかどうかを判定し、
前記更新手段は、所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去することを特徴とする通信制御システム。
【請求項4】
請求項2、3のいずれかにおいて、
前記記憶手段は、端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記更新手段は、前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定することを特徴とする通信制御システム。
【請求項5】
請求項1〜4のいずれかにおいて、
所定の情報を生成する情報生成手段を含み、
前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記判定手段は、前記通信手段によって受信される情報に基づき、前記第1および第2の端末装置のうち、前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記情報生成手段は、前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通信手段は、前記通知情報生成制御情報を前記他の端末装置へ向け送信することを特徴とする通信制御システム。
【請求項6】
コンピュータにより読み取り可能なプログラムであって、
コンピュータを、
通信機能を有する複数の端末装置間の通信を媒介する通信手段と、
前記通信手段による通信を制御する通信制御手段と、
前記通信手段によって第2の端末装置から第1の端末装置に通知することが必要な通知情報が受信されたかどうか、並びに、前記通信手段によって前記通知情報が受信されたかどうかを確認する前記第1の端末装置からの確認情報が前記通信手段によって受信されたかどうかを判定する判定手段として機能させ、
前記第1の端末装置は、前記複数の端末装置のうちの少なくとも1台の端末装置であり、
前記第2の端末装置は、前記複数の端末装置のうちの前記第1の端末装置とは異なる少なくとも1台の端末装置であり、
前記通信制御手段は、
前記判定手段によって前記確認情報が前記通信手段によって受信されたと判定された場合、前記通知情報の有無を示す応答情報を前記第1の端末装置に送信しないように前記通信手段を制御し、
前記判定手段によって前記通知情報が前記通信手段によって受信されたと判定された場合、当該通知情報を前記第1の端末装置へ向け送信するように前記通信手段を制御することを特徴とするプログラム。
【請求項7】
コンピュータにより読み取り可能なプログラムを記憶した情報記憶媒体であって、
請求項6に記載のプログラムを記憶したことを特徴とする情報記憶媒体。
【請求項8】
通信機能を有する複数の端末装置間の通信をコンピュータが制御する通信制御方法において、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報が受信されたかどうかを確認する確認情報を受信し、
当該確認情報の送信元の端末装置に前記通知情報の有無を示す応答情報を送信しないように前記通信部を制御し、
前記通信部が、前記複数の端末装置のうち所定の端末装置から他の端末装置に通知することが必要な通知情報を受信し、
当該通知情報を前記確認情報の送信元の端末装置へ向け送信するように前記通信部を制御することを特徴とする通信制御方法。
【請求項9】
請求項8において、
前記通信部と各端末装置との間で維持された状態のセッションの数を示すセッション数がしきい値を超えるかどうかを判定し、
前記セッション数が前記しきい値を超えた場合、最も長い間通信が行われていない端末装置とのセッションを終了するように前記通信部を制御することを特徴とする通信制御方法。
【請求項10】
請求項8、9のいずれかにおいて、
前記端末装置ごとに送信データを記憶し、
前記通知情報を受信した場合、当該通知情報を、送信先として指定されている端末装置用の前記送信データの少なくとも一部として記憶し、
各送信データが所定データ量を超えるかどうかを判定し、
所定データ量を超えた送信データがある場合、当該送信データのうち最も長い間使用されていない前記通知情報を消去することを特徴とする通信制御方法。
【請求項11】
請求項10において、
端末装置ごとの相互の関連づけを示す相手データを記憶し、
前記通知情報が受信された場合、前記相手データに基づき、当該通知情報を記憶する送信データを決定することを特徴とする通信制御方法。
【請求項12】
請求項8〜11のいずれかにおいて、
前記複数の端末装置は、対戦型通信ゲームを実行する機能を有し、
前記対戦型通信ゲームを途中で終了した端末装置である終了端末装置があるかどうかを判定し、
前記終了端末装置がある場合、前記終了端末装置に代えて他の端末装置が前記終了端末装置用の前記通知情報を生成するように制御する通知情報生成制御情報を生成し、
前記通知情報生成制御情報を前記他の端末装置へ向け送信することを特徴とする通信制御方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2006−4237(P2006−4237A)
【公開日】平成18年1月5日(2006.1.5)
【国際特許分類】
【出願番号】特願2004−180843(P2004−180843)
【出願日】平成16年6月18日(2004.6.18)
【出願人】(000134855)株式会社ナムコ (1,157)
【Fターム(参考)】