JP4553774B2 - 通信システム、中継サーバ、プログラム、および通信方法 - Google Patents

Description

この発明は、サーバから通信端末に情報を配信する通信システムに関する。

インターネットなどの通信ネットワークの普及に伴い、複数のプレイヤが同時に参加可
能なオンラインゲームの普及が進んでいる。オンラインゲームを提供する通信システムで
は、プレイヤが各自の通信端末に入力した情報を他のプレイヤの通信端末に配信する必要
がある。

下記の特許文献１および２には、オンラインゲームに伴うゲーム情報の配信技術が開示
されている。特許文献１に開示されるゲーム情報配信システムは、コマンド選択式のゲー
ムシステムを採用することにより、少ない通信回数でも楽しめるオンラインゲームを提供
する。

特許文献２に開示される通信システムは、端末装置の動作とは非同期にゲームサーバ側
で発生するゲーム情報を少ない遅延で端末装置へ通知することを可能にする。この通信シ
ステムでは、ゲームサーバが端末装置からリクエストを受信すると、端末に通知すべきゲ
ーム情報の有無を確認し、通知すべきゲーム情報が存在しない場合には、ゲーム情報が発
生するまで待機する。ゲーム情報が発生する前に最大待機時間が経過した場合は、ゲーム
サーバは、情報が発生していない旨を端末装置に通知する。これにより、ゲーム情報が発
生したときには、そのゲーム情報を大きく遅延させることなく端末装置に通知することが
できる。
特許第３２２２８７０号 特開２００４−１１８３２５号公報

大規模オンラインロールプレイングゲーム（Massively Multi-player Online Role Pla
ying Game：ＭＭＯＲＰＧ）のように、多数のプレイヤが共通の仮想空間（ゲーム空間）
内で各自のキャラクタを操作するオンラインゲームが知られている。このようなオンライ
ンゲームは、通信ネットワークを介してパーソナルコンピュータをゲームサーバに接続し
てプレイするのが一般的である。しかし、近年では、このようなオンラインゲームを、携
帯電話機などの携帯型通信端末を使用してプレイしたいというユーザが増えている。これ
に伴い、パーソナルコンピュータと携帯型通信端末の双方に対応した、いわゆるマルチプ
ラットフォームのゲームシステムを構築する必要が生じている。

ＭＭＯＲＰＧでは、多数のプレイヤが同時にゲームサーバに接続し、各自の通信端末か
らランダムなタイミングで情報を発信する。一つの通信端末からの情報発信に応じて、ゲ
ームサーバでは他の通信端末に配信すべきイベント情報が生成される。ＭＭＯＲＰＧでは
、多数のプレイヤがゲームサーバに接続するので、イベント情報は不定期に、しかも頻繁
に発生することになる。

各通信端末は、ユーザによって入力された情報をゲームサーバに送信すると共に、ゲー
ムサーバでイベント情報が発生するたびに、そのイベント情報をゲームサーバから取得し
なければならない。一般に、パーソナルコンピュータとゲームサーバとの通信では、通信
プロトコルとしてＴＣＰ（Transmission Control Protocol）が使用される。ＴＣＰ通信
では、ゲームサーバは通信端末に自発的にイベント情報を配信することができるので、リ
アルタイム性の高いＭＭＯＲＰＧを適切に提供することが可能である。

しかし、携帯電話機のなかには、データ通信用のプロトコルとしてＨＴＴＰ（HyperTex
t Transfer Protocol）しか扱えない機種が少なからず存在する。携帯電話機用のＨＴＴ
Ｐには、（１）携帯電話機とサーバとの間で通信セッションを維持し続けることができな
い、（２）リクエスト／レスポンス型の通信プロトコルなので、メインサーバから通信端
末に自発的に情報を配信することができない。（３）リクエストを発信し、それに対する
レスポンスを受け取るまでは新たにリクエストを発信できない、（４）単位時間当たりの
リクエスト発信回数に上限が定められている、といった通信上の様々な制約が存在する。
この制約が、携帯電話機を用いたＭＭＯＲＰＧの実現を困難にしている。

特許文献２で例示される麻雀ゲームのように、少数のプレイヤが所定の順序で交代しな
がら操作を行うゲームでは、プレイヤが他のプレイヤの操作を待ってから自分の操作を行
うため、リアルタイム性が低い。このため、ＨＴＴＰを用いた通信でも大きな支障なくゲ
ームを進行させることができる。これに対し、ＭＭＯＲＰＧのように同時進行性またはリ
アルタイム性の高いゲームでは、各通信端末は、自身に入力された情報をゲームサーバに
送信する一方で、自身の動作とは非同期にゲームサーバで発生するイベント情報をできる
限り少ない遅延で受信する必要がある。

しかし、上記の制約を伴うＨＴＴＰを用いる場合、ゲームサーバは通信端末からのリク
エストを受けなければイベント情報を通信端末に配信することができない。しかも、単位
時間当たりのリクエスト発信回数が制限されているため、リクエストの発信間隔を自由に
短縮することもできない。したがって、イベント情報の配信に遅延が生じやすく、リアル
タイム性の高いオンラインゲームを携帯電話機を使用して快適にプレイすることが困難に
なっている。このような問題点は、オンラインゲームに限らず、迅速な情報配信が要求さ
れる他の情報配信サービスでも同様に存在する。

本発明は、上記に鑑みなされたもので、不定期に発生する情報を少ない遅延で通信端末
に配信することの可能な通信システム、中継サーバ、プログラム、および通信方法を提供
することを課題とする。

本発明の一つの側面は、通信システムに関する。この通信システムは、第１プロトコル
に従ってリクエスト／レスポンス型の通信を行う通信端末と、第１プロトコルと異なる第
２プロトコルに従って通信を行うメインサーバと、第１プロトコルに従って通信端末と通
信すると共に、第２プロトコルに従ってメインサーバと通信する中継サーバと、この中継
サーバがアクセスすることの可能な記憶装置とを備えている。中継サーバは、通信端末か
らユーザＩＤと共に送信される第１リクエストに応じてメインサーバとの通信接続を確立
する。中継サーバは、メインサーバから通信端末宛てのデータを受信すると、そのデータ
をユーザＩＤに関連付けて記憶装置に記憶する。また、中継サーバは、通信端末からユー
ザＩＤと共に第２リクエストを受信すると、そのユーザＩＤに関連付けられた通信端末宛
てのデータを記憶装置から読み取り、第１プロトコルに準拠したデータに変換して、その
通信端末に送信する。メインサーバは、通信端末宛てのデータが発生すると、中継サーバ
からのリクエストを待つことなく、その通信端末宛てのデータを第２プロトコルに従って
中継サーバに送信してもよい。

第１プロトコルに従ってリクエスト／レスポンス型の通信を行う通信端末に対しては、
メインサーバが通信端末からのリクエストを待たずに自発的に情報を配信することはでき
ない。しかし、メインサーバは、通信端末と異なる第２プロトコルに従って中継サーバと
通信するので、中継サーバからのリクエストを待つことなく、中継サーバに対して自発的
な情報配信を行うことが可能である。このため、通信端末宛てのデータがメインサーバで
不定期に発生しても、中継サーバがそれらのデータをメインサーバから逐次受信して記憶
装置に記憶し、通信端末からリクエストを受信したときに、一括して通信端末に送信する
ことができる。したがって、通信端末のリクエスト発信間隔が制限されていても、遅延を
抑えて通信端末に情報を配信することができる。

メインサーバには、第２のプロトコルに従って通信を行う他の通信端末が中継サーバを
介することなく接続されていてもよい。第１のプロトコルを用いる通信端末に関しては中
継サーバがプロトコルの変換を行うので、メインサーバは、異なるプロトコルを使用する
通信端末を、プロトコルの違いを意識することなく同じように取り扱うことができる。し
たがって、本発明は、異なるプロトコルを使用する通信端末が共存するマルチプラットフ
ォーム環境を容易に実現することができる。

中継サーバは、第２リクエストを受信してから所定の待機時間が経過した後に、通信端
末宛てのデータを記憶装置から読み取ってもよい。この場合、待機時間の間に中継サーバ
がメインサーバから受信した通信端末宛てデータが、次回のリクエストではなく当該第２
リクエストに対するレスポンスとして通信端末に送信されることになる。第２リクエスト
が、メインサーバにデータを送信して処理を依頼するリクエストであれば、中継サーバが
その処理結果を待機時間中に受信し、当該第２リクエストに対するレスポンスとして通信
端末に送信することが可能になる。これにより、通信端末が依頼したメインサーバによる
処理の結果を、少ない遅延で通信端末に配信することができる。

中継サーバは、第２リクエストを通信端末から受信すると、メインサーバ宛てのデータ
が第２リクエストに付加されているか否かを判断し、メインサーバ宛てのデータが前記第
２リクエストに付加されていると判断したときは、当該メインサーバ宛てのデータを第２
プロトコルに準拠したデータに変換してメインサーバに送信すると共に、第２リクエスト
を受信してから所定の待機時間が経過した後に、通信端末宛てのデータを記憶装置から読
み取ってもよい。更に、中継サーバは、メインサーバ宛てのデータが第２リクエストに付
加されていないと判断したときは、待機時間の経過を待つことなく、通信端末宛てのデー
タを記憶装置から読み取ってもよい。

上記の構成によれば、中継サーバは、メインサーバ宛てデータが第２リクエストに付加
されているときにだけ、待機時間の経過を待つ。第２リクエストが、メインサーバにデー
タを送信して処理を依頼するリクエストであれば、中継サーバがその処理結果を待機時間
中に受信し、当該第２リクエストに対するレスポンスとして通信端末に送信することが可
能になる。これにより、通信端末が依頼したメインサーバによる処理の結果を、少ない遅
延で通信端末に配信することができる。また、メインサーバ宛てデータが第２リクエスト
に付加されていないときは、記憶装置に格納された通信端末宛てデータをより迅速に通信
端末に配信することができる。

通信端末は、中継サーバに所定の時間間隔で定期的に第２リクエストを送信してもよい
。上記の待機時間は、この時間間隔より短いことが好ましい。待機時間をリクエストの間
隔よりも短くすることで、通信端末へのデータ配信の遅延をいっそう確実に抑えることが
できる。

第１のプロトコルでは、単位時間当たりのリクエスト発信回数の上限が定められていて
もよい。この場合でも、記憶装置に蓄積された通信端末宛てデータが１回のリクエストに
応じて一括して通信端末に送信されるので、通信端末へのデータ配信の遅延を抑えること
ができる。

本発明の別の側面は、通信システム内に設置される中継サーバに関する。この通信シス
テムは、第１プロトコルに従ってリクエスト／レスポンス型の通信を行う通信端末と、第
１プロトコルと異なる第２プロトコルに従って通信を行うメインサーバと、記憶装置とを
備えている。中継サーバは、第１プロトコルに従って通信端末と通信すると共に、第２プ
ロトコルに従ってメインサーバと通信し、記憶装置にアクセスすることが可能である。こ
の中継サーバは、通信端末からユーザＩＤと共に送信される第１リクエストに応じてメイ
ンサーバとの通信接続を確立する通信接続手段と、メインサーバから通信端末宛てのデー
タを受信すると、そのデータをユーザＩＤに関連付けて記憶装置に記憶する記憶手段と、
通信端末からユーザＩＤと共に第２リクエストを受信すると、そのユーザＩＤに関連付け
られた通信端末宛てのデータを記憶装置から読み取り、第１プロトコルに準拠したデータ
に変換する第１変換手段と、この変換されたデータを通信端末に送信する第１送信手段と
を備えている。

本発明の更に別の側面は、通信システム内に配置される中継サーバを制御するプログラ
ムに関する。この通信システムは、第１プロトコルに従ってリクエスト／レスポンス型の
通信を行う通信端末と、第１プロトコルと異なる第２プロトコルに従って通信を行うメイ
ンサーバと、記憶装置とを備えている。中継サーバは、第１プロトコルに従って通信端末
と通信すると共に、第２プロトコルに従ってメインサーバと通信し、記憶装置にアクセス
することが可能である。このプログラムは、通信端末からユーザＩＤと共に送信される第
１リクエストに応じてメインサーバとの通信接続を確立するステップと、メインサーバか
ら通信端末宛てのデータを受信すると、そのデータをユーザＩＤに関連付けて記憶装置に
記憶するステップと、通信端末からユーザＩＤと共に第２リクエストを受信すると、その
ユーザＩＤに関連付けられた通信端末宛てのデータを記憶装置から読み取り、第１プロト
コルに準拠したデータに変換するステップと、この第１プロトコルに準拠したデータを通
信端末に送信するステップとを中継サーバに実行させる。

本発明の更に別の側面は、第１プロトコルに従ってリクエスト／レスポンス型の通信を
行う通信端末と、第１プロトコルと異なる第２プロトコルに従って通信を行うメインサー
バと、第１プロトコルに従って通信端末と通信すると共に、第２プロトコルに従ってメイ
ンサーバと通信する中継サーバと、中継サーバがアクセスすることの可能な記憶装置とを
備える通信システムにおいて、通信端末とメインサーバとの間で通信を行う方法に関する
。この方法は、通信端末が、ユーザＩＤと共に第１リクエストを中継サーバに送信するス
テップと、中継サーバが、第１リクエストに応じてメインサーバとの通信接続を確立する
ステップと、メインサーバが、通信端末宛てのデータを中継サーバに送信するステップと
、中継サーバが、通信端末宛ての当該データを、ユーザＩＤに関連付けて記憶装置に記憶
するステップと、通信端末が、ユーザＩＤと共に第２リクエストを中継サーバに送信する
ステップと、中継サーバが、第２リクエストと共に送信されたユーザＩＤに関連付けられ
た通信端末宛てのデータを記憶装置から読み取り、第１プロトコルに準拠したデータに変
換するステップと、中継サーバが、この第１プロトコルに準拠したデータを通信端末に送
信するステップとを備えている。

本発明の更に別の側面は、第１プロトコルに従ってリクエスト／レスポンス型の通信を
行う通信端末と、第１プロトコルと異なる第２プロトコルに従って通信を行うメインサー
バと、第１プロトコルに従って通信端末と通信すると共に、第２プロトコルに従ってメイ
ンサーバと通信する中継サーバと、中継サーバがアクセスすることの可能な記憶装置とを
備える通信システムにおいて、メインサーバを制御するプログラムに関する。中継サーバ
は、通信端末からユーザＩＤと共に送信される第１リクエストに応じてメインサーバとの
通信接続を確立し、メインサーバから通信端末宛てのデータを受信すると、そのデータを
ユーザＩＤに関連付けて記憶装置に記憶し、通信端末からユーザＩＤと共に第２リクエス
トを受信すると、そのユーザＩＤに関連付けられた通信端末宛てのデータを記憶装置から
読み取り、第１プロトコルに準拠したデータに変換して通信端末に送信する。このプログ
ラムは、通信端末宛てのデータを中継サーバに送信するステップをメインサーバに実行さ
せる。

本発明の更に別の側面は、第１プロトコルに従ってリクエスト／レスポンス型の通信を
行う通信端末と、第１プロトコルと異なる第２プロトコルに従って通信を行うメインサー
バと、第１プロトコルに従って通信端末と通信すると共に、第２プロトコルに従ってメイ
ンサーバと通信する中継サーバと、中継サーバがアクセスすることの可能な記憶装置とを
備える通信システムにおいて、通信端末を制御するプログラムに関する。中継サーバは、
通信端末からユーザＩＤと共に送信される第１リクエストに応じてメインサーバとの通信
接続を確立し、メインサーバから通信端末宛てのデータを受信すると、そのデータをユー
ザＩＤに関連付けて記憶装置に記憶し、通信端末からユーザＩＤと共に第２リクエストを
受信すると、そのユーザＩＤに関連付けられた通信端末宛てのデータを記憶装置から読み
取り、第１プロトコルに準拠したデータに変換して通信端末に送信する。このプログラム
は、ユーザＩＤと共に第１リクエストを中継サーバに送信するステップと、ユーザＩＤと
共に第２リクエストを中継サーバに送信するステップと、第１プロトコルに準拠した上記
のデータを受信するステップとを通信端末に実行させる。

本発明は、通信端末とメインサーバとの通信を中継する中継サーバを用いることで、不
定期に発生する情報を少ない遅延で通信端末に配信することができる。この結果、情報の
迅速な配信が要求される通信サービスを通信端末に適切に提供することができる。

以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明
において同一の要素には同一の符号を付し、重複する説明を省略する。

第１実施形態
図１は、本発明の第１の実施形態に係る通信システムの構成を示す概略図である。この
通信システム１００は、多数のユーザが通信端末１を操作して共通のゲームをプレイする
オンラインゲームサービスを提供する。図１には、通信端末１の例として、携帯電話機１
ａおよびパーソナルコンピュータ１ｂが挙げられている。本明細書において、携帯電話機
にはＰＨＳ（PersonalHandy-phone System）も含まれる。通信端末１の他の例としては、
通信機能を有するゲーム機やＰＤＡ（Personal Data Assistants）などを挙げることがで
きる。通信端末１は、携帯電話機などの移動体端末であってもよいし、デスクトップ型コ
ンピュータなどの固定端末であってもよい。

通信システム１００は、二つのサーバ、すなわち中継サーバ３およびゲームサーバ５を
含んでいる。通信端末１の各々は、通信ネットワーク２を介してゲームサーバ５と通信を
行うことができる。携帯電話機１ａは、基地局６および通信ネットワーク２を介して中継
サーバ３に接続し、その中継サーバ３を介してゲームサーバ５と通信を行う。一方、パー
ソナルコンピュータ１ｂは、中継サーバ３を介さずにゲームサーバ５と通信を行う。

なお、図１では、通信ネットワーク２に携帯電話機１ａおよびパーソナルコンピュータ
１ｂが一つずつ接続されているが、複数の携帯電話機１ａおよびパーソナルコンピュータ
１ｂが通信ネットワーク２に接続されていてもよい。

携帯電話機１ａは、所定の通信プロトコルに従ってリクエスト／レスポンス型の通信を
行う。本実施形態では、携帯電話機１ａは通信プロトコルとしてＨＴＴＰ（HyperTextTra
nsfer Protocol）を使用する。一方、パーソナルコンピュータ１ｂは、ＴＣＰ（Transmis
sion Control Protocol）に従ってゲームサーバ５と通信を行う。

図２は、携帯電話機１ａの構成を概略的に示すブロック図である。携帯電話機１ａは、
ＣＰＵ（CentralProcessing Unit：中央処理装置）１０、ＲＡＭ（Random Access Memory
：ランダムアクセスメモリ）１２、ストレージ部１４、通信装置１６、入力装置２０、お
よび表示装置２２を有する。これらの構成要素はバス２４によって相互に接続されている
。データおよび制御信号はバス２４を通じてこれらの構成要素間を伝送される。

ＣＰＵ１０は、ＯＳ（OperatingSystem）やＯＳ上で動作するアプリケーションなどの
プログラムを実行して携帯電話機１の動作を制御する制御演算装置である。本実施形態で
は、ＣＰＵ１０は、主としてゲームアプリケーションを実行する。

ＲＡＭ１２は、ＣＰＵ１０がプログラムを実行するために使用する主記憶装置である。
ＲＡＭ１２には、ＣＰＵ１０が実行するプログラムおよびその実行に必要なデータが格納
される。後述するように、ゲームアプリケーションの実行中、ＲＡＭ１２には送信バッフ
ァ１８が設けられる。送信バッファ１８は、携帯電話機１ａがゲームサーバ５に送信すべ
きデータを一時的に記憶するための記憶領域である。

ストレージ部１４は、携帯電話機１の補助記憶装置であり、内蔵メモリ１４ａと、外付
けメモリ１５用の読み取り装置１４ｂとを含んでいる。内蔵メモリ１４ａは、携帯電話機
１ａの内部に固定された記憶装置である。内蔵メモリ１４ａは、例えば、フラッシュメモ
リなどの不揮発性メモリである。本実施形態では、携帯電話機１の電話番号やユーザＩＤ
がこの内蔵メモリ１４ａに記憶されている。後述するゲームアプリケーションも内蔵メモ
リ１４ａに記憶されており、その起動時にＲＡＭ１２に読み込まれる。読み取り装置１４
ｂは、携帯電話機１に対して着脱自在の外付けメモリ１５からデータを読み取るための装
置である。外付けメモリ１５は、コンピュータ読み取り可能な記録媒体であり、例えば、
各種のカード型メモリである。このほかに、外付けメモリ１５は、ＳＩＭ（Subscriber I
dentify Module：加入者識別モジュール）カードであってもよい。電話番号やユーザＩＤ
は、外付けメモリ１５に格納されていてもよい。

通信装置１６は、通信端末１と基地局６との通信を制御する。通信装置１６は、電波送
受信用のアンテナのほかに、送話音声を電気信号に変換するマイクロホン、受話音声を出
力するスピーカ、音声信号を処理する信号処理回路などを含んでいる。通信装置１６は、
ＣＰＵ１０の制御のもとで基地局６との間で電波を送受信し、通信ネットワーク２に無線
接続する。これにより、携帯電話機１と通信ネットワーク２との間で通信接続が確立され
る。通信装置１６は、音声通信だけでなくデータ通信も実行することができる。

入力装置２０は、携帯電話機１に命令およびデータを入力するために使用される。入力
装置２０は、ボタン、ダイヤル、スイッチなど、ユーザによって直接操作される装置であ
ってもよいし、ユーザの発する音声を判別する音声認識装置であってもよい。

表示装置２２は、ＣＰＵ１０の制御のもとで各種の情報を表示する。携帯電話機１ａ上
で実行されるゲームアプリケーションの出力画像も表示装置２２上に表示される。

中継サーバ３は、通信端末１とゲームサーバ５との間で通信を中継するコンピュータシ
ステムである。中継サーバ３は、単一のコンピュータから構成されていてもよいし、相互
に連携して動作する複数のコンピュータから構成されていてもよい。

図３は、中継サーバ３の構成を示すブロック図である。中継サーバ３は、ＣＰＵ３０、
ＲＡＭ３２、ハードディスクドライブ３４、通信装置３６、入力装置３８、および表示装
置４０を有する。これらの構成要素はバス４２によって相互に接続されている。データお
よび制御信号はバス４２を通じてこれらの構成要素間を伝送される。

ＣＰＵ３０は、中継サーバプログラムを実行して中継サーバ３の動作を制御する制御演
算装置である。この中継サーバプログラムは、中継サーバ３のＯＳ（Operating System）
上で動作する。ＲＡＭ３２は、ＣＰＵ３０が中継サーバプログラムを実行するために使用
する主記憶装置である。ＲＡＭ３２には、中継サーバプログラムおよびその実行に必要な
データが格納される。後述するように、サーバプログラムは、ＲＡＭ３２に接続情報テー
ブル７０を作成して保存する。

ハードディスクドライブ３４は、中継サーバ３の補助記憶装置であり、中継サーバプロ
グラムを格納している。中継サーバ３の起動時には、ハードディスクドライブ３４からＲ
ＡＭ３２に中継サーバプログラムが読み込まれ、ＣＰＵ３０によって実行される。このほ
かに、ハードディスクドライブ３４には、プロトコル変換テーブル８０が格納されている
。後述するように、プロトコル変換テーブル８０は、携帯電話機１ａで使用されるプロト
コルに準拠したデータとゲームサーバ５で使用されるプロトコルに準拠したデータとを相
互に変換するために使用される。本実施形態では、プロトコル変換テーブル８０は、中継
サーバプログラムと共にハードディスクドライブ３４からＲＡＭ３２に読み込まれる。

通信装置３６は、携帯電話機１ａまたはゲームサーバ５と中継サーバ３との間の通信を
制御する。通信装置３６は、携帯電話機１ａとの通信を制御する端末用インタフェース３
６ａと、ゲームサーバ５との通信を制御するゲームサーバ用インタフェース３６ｂを有し
ている。端末用インタフェース３６ａは、通信ネットワーク２を介して携帯電話機１ａと
ＨＴＴＰに従った通信を行う。一方、ゲームサーバ用インタフェース３６ｂは、ＴＣＰに
従ってゲームサーバ５と通信する。なお、インタフェース３６ａおよび３６ｂは、両者の
機能を兼ね備える単一のハードウェアに置き換えてもよい。

入力装置３８は、中継サーバ３に命令およびデータを入力するために使用される。表示
装置４０は、ＣＰＵ３０の制御のもとで各種の情報を表示する。

ゲームサーバ５は、クライアントである通信端末１にオンラインゲームサービスを提供
するコンピュータシステムである。サーバ５は、単一のコンピュータから構成されていて
もよいし、相互に連携して動作する複数のコンピュータから構成されていてもよい。

図４は、ゲームサーバ５の構成を示すブロック図である。ゲームサーバ５は、ＣＰＵ５
０、ＲＡＭ５２、ハードディスクドライブ５４、通信装置５６、入力装置５８、および表
示装置６０を有する。これらの構成要素はバス６２によって相互に接続されている。デー
タおよび制御信号はバス６２を通じてこれらの構成要素間を伝送される。

ＣＰＵ５０は、ゲームサーバプログラムを実行してゲームサーバ５の動作を制御する制
御演算装置である。このゲームサーバプログラムは、ゲームサーバ５のＯＳ上で動作する
。ＲＡＭ５２は、ＣＰＵ５０がゲームサーバプログラムを実行するために使用する主記憶
装置である。ＲＡＭ５２には、ゲームサーバプログラムおよびその実行に必要なデータが
格納される。

ハードディスクドライブ５４は、ゲームサーバ５の補助記憶装置であり、ゲームサーバ
プログラムのほかに、ゲームに関連する種々のデータが格納されている。ゲームサーバ５
の起動時には、ハードディスクドライブ５４からＲＡＭ５２にゲームサーバプログラムが
読み込まれ、ＣＰＵ５０によって実行される。

通信装置５６は、パーソナルコンピュータ１ｂまたは中継サーバ３とゲームサーバ５と
の間の通信を制御する。通信装置５６は、通信ネットワーク２を介してパーソナルコンピ
ュータ１ｂとＴＣＰに従った通信を行うと共に、中継サーバ３ともＴＣＰに従って通信を
行う。通信装置５６は、通信ネットワーク２および中継サーバ３の双方に接続されたルー
タを含んでいてもよい。

入力装置５８は、ゲームサーバ５に命令およびデータを入力するために使用される。表
示装置６０は、ＣＰＵ５０の制御のもとで各種の情報を表示する。

以下では、通信システム１００の動作を説明する。ここで、携帯電話機１の動作は、ゲ
ームアプリケーションにしたがって制御される。このゲームアプリケーションは、ユーザ
による実行命令に応答して内蔵メモリ１４ａからＲＡＭ１２に読み込まれ、ＣＰＵ１０に
よって実行される。また、中継サーバ３及びゲームサーバ５の動作は、各自のサーバプロ
グラムにしたがって制御される。

まず、図５を参照しながら、中継サーバ３の機能を概略的に説明する。図５は、中継サ
ーバ３の機能ブロック図である。この図では、パーソナルコンピュータ１ｂ、通信ネット
ワーク２および基地局６は省略されている。

中継サーバ３は、携帯電話機１ａとゲームサーバ５との通信を中継するために、プロト
コル変換部４４およびバッファリング部４６を有している。中継サーバプログラムの制御
下で、プロトコル変換部４４は、ＣＰＵ３０、ＲＡＭ３２およびハードディスクドライブ
３４を用いて実現され、バッファリング部４６は、ＣＰＵ３０およびＲＡＭ３２によって
実現される。

プロトコル変換部４４は、端末用インタフェース３６ａを介して携帯電話機１ａからゲ
ームサーバ宛てのデータを受け取る。このデータは、例えば、オンラインゲームをプレイ
するなかでユーザが携帯電話機１ａに入力した情報である。このゲームサーバ宛てデータ
はＨＴＴＰに準拠している。プロトコル変換部４４は、このゲームサーバ宛てデータをＴ
ＣＰに準拠したデータに変換し、ゲームサーバ用インタフェース３６ｂに送る。ゲームサ
ーバ用インタフェース３６ｂは、この変換されたデータをＴＣＰに従ってゲームサーバ５
に送信し、ゲームサーバ５は通信装置５６を用いてこのデータを受信する。

ゲームサーバ５は、ある通信端末１に入力された情報を処理して、ゲームに関連する情
報を生成し、その情報をその通信端末１だけでなく他の通信端末１にも配信することによ
り、それらの通信端末１に共通のゲーム空間を提供する。このように、ゲームの進行に応
じてゲームサーバ５で発生し、通信端末１に同報される情報をイベント情報と呼ぶことに
する。ゲームサーバ５は、イベント情報が発生するたびに、そのイベント情報を自発的に
パーソナルコンピュータ１ｂや中継サーバ３に送信する。携帯電話機１ａ宛てのイベント
情報は、ＴＣＰに従って通信装置５６から中継サーバ３に送信される。中継サーバ３は、
ゲームサーバ用インタフェース３６ｂを用いてイベント情報を受信し、それをバッファリ
ング部４６に送る。

バッファリング部４６は、中継サーバ３に接続中の各携帯電話機１ａに対して個別に用
意されたバッファ記憶領域４８を有している。バッファ記憶領域４８は、ＲＡＭ３２内に
設けられ、必要に応じてハードディスクドライブ３４に待避される。ゲームサーバ５から
送信された携帯電話機１ａ宛てのイベント情報は、その携帯電話機１ａに対応するバッフ
ァ記憶領域４８に格納される。したがって、ゲームサーバ５で特定の携帯電話機１ａ宛て
のイベント情報が発生するたびに、中継サーバ３は、ゲームサーバ５からのイベント情報
を逐次受信し、その携帯電話機１ａに対応するバッファ記憶領域４８にイベント情報を蓄
積する。

後述するように、バッファ記憶領域４８に蓄積されたイベント情報は、携帯電話機１ａ
からのリクエストに応答してバッファ記憶領域４８から読み取られ、プロトコル変換部４
４に送られる。プロトコル変換部４４は、ＴＣＰに準拠したイベント情報をＨＴＴＰに準
拠したデータに変換して、端末用インタフェース３６ａに送る。端末用インタフェース３
６ａは、この変換されたデータを携帯電話機１ａに送信する。このようにして、中継サー
バ３は、異なるプロトコルを使用する携帯電話機１ａおよびゲームサーバ５間の通信を中
継する。

以下では、図６を参照しながら、ユーザが携帯電話機１ａ上でゲームアプリケーション
を起動してゲームをプレイするときに、携帯電話機１ａ、中継サーバ３及びゲームサーバ
５が実行する処理の流れを説明する。ここで図６は、携帯電話機１ａ、中継サーバ３およ
びゲームサーバ５間の通信の一例を時系列的に示すシーケンス図である。

図６に示されるように、携帯電話機１ａ上でゲームアプリケーションが起動され、ユー
ザがアカウント情報、すなわちユーザ名およびパスワードを携帯電話機１ａに入力すると
、携帯電話機１ａは、中継サーバ３との間に通信接続を確立し、初回のリクエストＲ１を
中継サーバ３に送信する。携帯電話機１ａから発信されるリクエストには常にユーザＩＤ
が付加されているが、このリクエストＲ１には、ユーザによって入力されたアカウント情
報が更に付加されている。

中継サーバ３は、リクエストＲ１を受信すると、ゲームサーバ５との間に通信接続を確
立する。具体的には、中継サーバプログラムは、ソケットを作成し、そのソケットをゲー
ムサーバ５側のソケットと接続する。ここで、ソケットとは、通信を行うプログラムが用
意する仮想的な通信インタフェースであり、プログラムはソケットに対してデータを読み
書きすることによってデータを送受信することができる。ソケットの接続は、中継サーバ
３のＯＳによって制御される。その際には、ゲームサーバ５のＩＰアドレス（Internet P
rotocol Address）およびポート番号が使用される。

なお、コンピュータ同士の通信接続はコネクションとも呼ばれる。ＨＴＴＰに従う携帯
電話機１ａと中継サーバ３との通信は、ステートレス型、すなわち携帯電話機１ａと中継
サーバ３の間でコネクションが維持されず、リクエスト発行のたびに接続をし直す形式で
ある。このような通信形式において、リクエストとそれに対するレスポンスで完結する一
つの接続単位はセッションと呼ばれる。

中継サーバ３は、携帯電話機１ａからのリクエストに応じてゲームサーバ５とのコネク
ションを確立すると、ソケット情報を作成し、携帯電話機１ａから送信されたユーザＩＤ
に関連付けて接続情報テーブル７０に登録する。ソケット情報は、中継サーバ３とゲーム
サーバ５とのコネクションを、リクエストを発した携帯電話機１ａと中継サーバ３とのセ
ッションに対応付ける。ソケット情報については、後でより詳しく説明する。

図７は、接続情報テーブル７０の構成を示す概略図である。接続情報テーブル７０は、
上述したＲＡＭ３２内のバッファ記憶領域４８に格納されている。接続情報テーブル７０
には、接続レコード７２が列挙される。接続レコード７２は、中継サーバ３と携帯電話機
１ａとの通信接続と、中継サーバ３とゲームサーバ５との通信接続とを一対一に対応させ
るためのデータである。図７に示されるように、接続レコード７２は、相互に関連付けら
れたユーザＩＤ、ソケット情報、最新リクエスト日時、バッファデータ、その他のデータ
を含んでいる。

中継サーバ３は、携帯電話機１ａからのリクエストに付加されたユーザＩＤと、上述の
ソケット情報とを相互に関連付けて、一つの接続レコード７２を作成し、接続情報テーブ
ル７０に追加する。これにより、携帯電話機１ａと中継サーバ３とのセッションが、中継
サーバ３とゲームサーバ５とのコネクションに一対一に対応付けられることになる。

ユーザＩＤは、携帯電話機１ａを他の携帯電話機１ａやパーソナルコンピュータ１ｂと
区別するために使用されるユニークな識別データであり、本実施形態では、携帯電話機１
ａの電話番号と一対一に対応している。上述のように、ユーザＩＤは携帯電話機１ａ内の
内蔵メモリ１４ａに格納されており、リクエストの発信時に内蔵メモリ１４ａからＲＡＭ
１２に読み込まれる。

ソケット情報は、ゲームサーバ５とのコネクションと携帯電話機１ａとのセッションを
一対一に対応付けるデータである。中継サーバ３に複数の携帯電話機１ａが接続されてい
る場合、中継サーバ３は、これらの携帯電話機１ａの各々に対して別個にゲームサーバ５
とのコネクションを確立する。中継サーバ３は、携帯電話機１ａとのセッションを通じて
リクエストを受け取ると、ソケット情報を用いて、そのセッションに対応するゲームサー
バ５とのコネクションを特定する。そして、中継サーバ３は、そのコネクションを通じて
ゲームサーバ５にデータを送信したり、あるいはそのコネクションを通じてゲームサーバ
５から受信したデータを携帯電話機１ａに送信する。具体的には、ソケット情報は、ゲー
ムサーバ５とのコネクションに使用されるゲームサーバ５のＩＰアドレスおよびポート番
号と、そのコネクションに対応する中継サーバ３側のＩＰアドレスおよびポート番号との
組み合わせに対応付けられている。これらのＩＰアドレスおよびポート番号は、中継サー
バ３のＯＳによって管理されている。

最新リクエスト日時は、対応するユーザＩＤを有する携帯電話機１ａからリクエストを
受信した最新の日時であり、中継サーバ３が携帯電話機１ａからリクエストを受信するた
びに更新される。中継サーバ３は、各接続レコード７２内の最新リクエスト日時を現在時
刻と定期的に比較し、最新のリクエスト日時から所定の時間が経過した接続レコード７２
を発見すると、その接続レコード７２に対応するセッションはすでに切断されたものとみ
なして、その接続レコード７２を削除する。

バッファデータは、中継サーバ３がゲームサーバ５から受信した携帯電話機１ａ宛ての
データである。このバッファデータの例は、携帯電話機１ａがゲームサーバ５に送信した
データの処理結果を示すデータや、他の通信端末１の操作に応じて発生したイベント情報
である。

再び図６を参照する。中継サーバ３は、ゲームサーバ５とのコネクションを確立すると
、携帯電話機１ａから受信したアカウント情報をゲームサーバ５に送信する。ゲームサー
バ５は、そのアカウント情報を用いてログイン認証を実行する。

図８は、図６に示されるシーケンスにおいてゲームサーバ５が実行する処理を示すフロ
ーチャートである。ゲームサーバ５は、中継サーバ３とのコネクションを確立した後（ス
テップＳ８０２）、中継サーバ３からアカウント情報を受信し（ステップＳ８０４）、そ
のアカウント情報が有効か否かを判断する（ステップＳ８０６）。この判断は、正規に登
録されたアカウント情報を格納するアカウントデータベース内において、中継サーバ３か
ら受信したアカウント情報を検索することにより行われる。アカウントデータベース内に
アカウント情報が発見されれば、そのアカウント情報は有効と判断され、発見されなけれ
ば無効と判断される。アカウントデータベースは、ハードディスクドライブ５４に格納さ
れていてもよいし、ゲームサーバ５がアクセス可能な外部の記憶装置に格納されていても
よい。

アカウント情報が無効と判断されると（ステップＳ８０６にてＮｏ）、ゲームサーバ５
は、ログイン拒否通知を中継サーバ３に送信し、中継サーバ３とのコネクションを切断す
る（ステップＳ８０７）。これに応じて中継サーバ３は、ログイン拒否通知を携帯電話機
１ａに送信し、携帯電話機１ａとのセッションを閉じる。

一方、アカウント情報が有効と判断されると（ステップＳ８０６にてＹｅｓ）、ゲーム
サーバ５はログイン処理を実行する（ステップＳ８０８）。ゲームサーバ５は、そのアカ
ウント情報に対応するプレイヤキャラクタのデータをハードディスクドライブ３４または
外部の記憶装置から取得する。また、ゲームサーバ５は、そのプレイヤキャラクタをゲー
ム空間に出現させるための処理を実行する。

次に、ゲームサーバ５は、ログイン成功通知および初期イベント情報を中継サーバ３に
送信する（ステップＳ８１０）。この初期イベント情報は、例えば、アカウント情報に対
応するプレイヤキャラクタのステータス（ヒットポイントや経験値など）や、ゲーム空間
内におけるプレイヤキャラクタの周囲の状況を表すデータである。

図６に示されるように、中継サーバ３はゲームサーバ５から初期イベント情報を受信す
ると、それを携帯電話機１ａに転送する。具体的には、中継サーバ３がゲームサーバ５か
らログイン成功通知および初期イベント情報を受信すると、中継サーバ３のバッファリン
グ部４６は、その受信に使用したコネクションに対応するソケット情報をキーとして、接
続情報テーブル７０からそのソケット情報を含む接続レコード７２を検索する。そして、
バッファリング部４６は、受信した初期イベント情報を、検索された接続レコード７２内
のバッファデータとしてバッファ記憶領域４８に記憶する。

続いて、中継サーバ３は、検索された接続レコード７２内のユーザＩＤを有する携帯電
話機１ａに、初回のリクエストＲ１に対するレスポンスを送信する。このレスポンスには
、ログイン成功通知および初期イベント情報が付加される。中継サーバ３のプロトコル変
換部４４は、そのユーザＩＤと同じ接続レコード７２内のバッファデータ、すなわち上記
の初期イベント情報を読み取り、ＨＴＴＰに準拠したデータに変換する。この変換された
データは端末用インタフェース３６ａに送られ、レスポンスおよびログイン成功通知と共
に携帯電話機１ａに送信される。

以下では、図６〜図８に加えて図９を参照しながら、ログイン成功後に実行される処理
を説明する。ここで図９は、図６に示されるシーケンスにおいてログイン成功後に携帯電
話機１ａおよび中継サーバ３が実行する処理を示すフローチャートである。

まず、中継サーバ３における携帯電話機宛てデータの蓄積を説明する。ゲームサーバ５
が使用するＴＣＰは、クライアントからのリクエストによらずにサーバからクライアント
へ自発的に情報を配信することを許容するプロトコルである。ゲームサーバ５は、このよ
うなＴＣＰを利用して、携帯電話機１ａに送信すべきデータが発生するたびに、そのデー
タを中継サーバ３に自発的に送信する。

具体的には、図８に示されるように、携帯電話機１ａがゲームサーバ５へのログインに
成功した後、ゲームサーバ５は、携帯電話機１ａに配信すべきイベント情報が発生したか
否かを確認する（ステップＳ８１２）。イベント情報が発生したことを確認すると（ステ
ップＳ８１２にてＹｅｓ）、ゲームサーバ５は、そのイベント情報を中継サーバ３に送信
する（ステップＳ８１４）。このイベント情報の送信は、イベント情報の配信先である携
帯電話機１ａからのリクエストに応じて中継サーバ３とゲームサーバ５との間に確立され
たコネクションを使用して行われる。

図９に示されるように、中継サーバ３は、そのコネクションに対応するソケットを使用
してイベント情報を受信し、そのソケットに対応するソケット情報を含む接続レコード７
２内のバッファデータとして、そのイベント情報をバッファ記憶領域４８に記憶する（ス
テップＳ９２０）。イベント情報は、例えば、イベント情報の配信先の携帯電話機１ａと
は別の通信端末１を操作するユーザが同じオンラインゲームをプレイするうえでその通信
端末１に入力した情報を反映している。このため、イベント情報は、配信先の携帯電話機
１ａの動作とは非同期に、かつ不定期に発生する。ゲームサーバ５が中継サーバ３にイベ
ント情報を送信するたびに上記のようなバッファリングが行われ、イベント情報がバッフ
ァ記憶領域４８に蓄積されることになる。

次に、携帯電話機１ａによるリクエストの発信を説明する。ログイン成功後、携帯電話
機１ａは中継サーバ３に定期的にリクエストを送信する。リクエストには、ゲームサーバ
宛てのデータが付加されていることがある。このゲームサーバ宛てデータは、例えば、ユ
ーザがゲームのプレイするうえで携帯電話機１ａに入力した情報である。ゲームサーバ５
は、そのようなデータを受信すると、そのデータを用いて所定の処理を実行し、ゲームを
進行させる。この処理結果は、その携帯電話機１ａに送信されると共に、必要に応じて他
の通信端末１にも送信される。

より具体的には、図９に示されるように、携帯電話機１ａは、ゲームサーバ宛てデータ
が発生したか否かを確認し（ステップＳ９０２）、ゲームサーバ宛てデータの発生が確認
された場合には（ステップＳ９０２にてＹｅｓ）、そのゲームサーバ宛てデータを送信バ
ッファ１８に格納する（ステップＳ９０４）。送信バッファ１８は、ＲＡＭ１２内に設け
られた記憶領域であり、ゲームサーバ宛てデータを一時的に保存するために使用される。
送信バッファ１８は、必要に応じて内蔵メモリ１４ａに退避させてもよい。

本実施形態において携帯電話機１ａが使用するＨＴＴＰでは、単位時間当たりのリクエ
スト発信回数が、例えば１分間に８回までと制限されており、リクエストの頻度を自由に
設定することができない。このため、携帯電話機１ａは、リクエストの発信の合間に逐次
発生するゲームサーバ宛てデータを送信バッファ１８に蓄積しておき、リクエストの発信
時に一括して中継サーバ３に送信する。

送信バッファ１８へのデータ格納（ステップＳ９０４）が完了し、あるいはゲームサー
バ宛てデータが発生していないことが確認されると（ステップＳ９０２にてＮｏ）、前回
のリクエストから所定の時間が経過したか否かが判断される（ステップＳ９０６）。以下
では、この所定時間をリクエスト発信時間と呼ぶことにする。図６では、リクエスト発信
時間が符号Ｔｉで表されている。本実施形態では、ログイン成功後のリクエスト発信時間
が８秒に固定されており、したがって、リクエストが８秒間隔で定期的に発信される。携
帯電話機１ａは、リクエストを発信すると同時に時間計測を開始し、計測された時間をリ
クエスト発信時間と比較することによりステップＳ９０６の判断を行う。

リクエスト発信時間が経過していないと判断された場合（ステップＳ９０６にてＮｏ）
、ステップＳ９０２以降の処理が再び実行される。一方、リクエスト発信時間が経過した
と判断された場合には（ステップＳ９０６にてＹｅｓ）、携帯電話機１ａは中継サーバ３
にリクエストを送信する（ステップＳ９０８）。このリクエストには、携帯電話機１ａの
ユーザＩＤが付加される。また、送信バッファ１８にゲームサーバ宛てデータが格納され
ている場合、携帯電話機１ａは、そのゲームサーバ宛てデータを送信バッファ１８から読
み取り、リクエストに付加して中継サーバ３に送信する。

中継サーバ３は、携帯電話機１ａからリクエストを受信すると（ステップＳ９２２）、
そのリクエストに付加されているユーザＩＤに基づいて接続情報テーブル７０を参照する
（ステップＳ９２４）。中継サーバ３は、そのユーザＩＤを接続情報テーブル７０内で検
索し（ステップＳ９２６）、そのユーザＩＤを発見したら（ステップＳ９２６にてＹｅｓ
）、そのユーザＩＤを含む接続レコード７２内のソケット情報を読み取る（ステップＳ９
２８）。前述のように、中継サーバ３は古い接続レコード７２を削除するので、接続情報
テーブル７０内にユーザＩＤを発見できない可能性もある（ステップＳ９２６にてＮｏ）
。この場合、中継サーバ３は、ゲームサーバ５との間に新たなコネクションを確立し（ス
テップＳ９３０）、そのコネクションに対応する接続レコード７２を作成して、接続情報
テーブル７０に追加する（ステップＳ９３２）。ステップＳ９２８またはＳ９３２が完了
すると、中継サーバ３は、携帯電話機１ａから受信したユーザＩＤを含む接続レコード７
２内の最新リクエスト日時を現在の日時に更新する（ステップＳ９３４）。

次に、中継サーバ３は、携帯電話機１ａからのリクエストにゲームサーバ宛てデータが
付加されているか否かを判断する（ステップＳ９３６）。ゲームサーバ宛てのデータがリ
クエストに付加されている場合（ステップＳ９３６にてＹｅｓ）、中継サーバ３はそのデ
ータをＴＣＰに準拠したデータに変換し、この変換されたデータをリクエストと共にゲー
ムサーバ５に送信する（ステップＳ９３８）。このリクエストは、ＴＣＰに準拠したゲー
ムサーバ宛てデータの処理をゲームサーバ５に要求する。ゲームサーバ宛てデータのプロ
トコル変換は、ハードディスクドライブ３４に格納されたプロトコル変換テーブル８０を
用いて実行される。プロトコル変換テーブル８０は、ＨＴＴＰプロトコルに準拠した様々
なデータをＴＣＰプロトコルに準拠したデータに一対一に対応付けている。

図８に示されるように、ゲームサーバ５は、イベント情報が発生していないことを確認
し（ステップＳ８１２にてＮｏ）、あるいはイベント情報を中継サーバ３に送信すると（
ステップＳ８１４）、中継サーバ３から処理リクエストを受信したか否かを判断する（ス
テップＳ８１６）。処理リクエストは、携帯電話機１ａがゲームサーバ５に処理を要求す
るリクエストであり、携帯電話機１ａから中継サーバ３を介してゲームサーバ５に送信さ
れる。上述したゲームサーバ宛てデータが付加されたリクエストも、処理リクエストの一
例である。

中継サーバ３から処理リクエストを受信したと判断された場合（ステップＳ８１６にて
Ｙｅｓ）、その処理リクエストが切断リクエストであるか否かが判断される（ステップＳ
８１８）。切断リクエストである場合（ステップＳ８１８にてＹｅｓ）、ゲームサーバ５
は、切断リクエストを発信した携帯電話機１ａが操作するプレイヤキャラクタをゲーム空
間からログアウトさせるための終了処理を実行し、その後、切断リクエストの受信に使用
した中継サーバ３とのコネクションを切断する（ステップＳ８１９）。

一方、処理リクエストが切断リクエストでない場合（ステップＳ８１８にてＮｏ）、ゲ
ームサーバ５はリクエストされた処理を実行し、レスポンスを中継サーバ３に送信する（
ステップＳ８２０）。このレスポンスには、必要であれば処理結果を示すデータが付加さ
れる。携帯電話機１ａから送信されたゲームサーバ宛てデータが処理リクエストに付加さ
れていれば、ゲームサーバ５は、そのゲームサーバ宛てデータを所定の方法で処理する。
例えば、ゲームサーバ宛てデータがユーザによって携帯電話機１ａに入力された敵モンス
ターの攻撃指令であれば、ゲームサーバ５は、その攻撃指令に基づいて敵モンスターが受
けるダメージを算出する。このダメージが処理結果の一例である。処理結果の送信は、処
理リクエストの受信に使用されたものと同じコネクションを使用して行われる。中継サー
バ３は、その処理結果を受信し、そのコネクションに対応するソケット情報を含む接続レ
コード７２内のバッファデータとして、その処理結果をバッファ記憶領域４８に格納する
（ステップＳ９２０）。

再び図９を参照する。中継サーバ３は、携帯電話機１ａからのリクエストにゲームサー
バ宛てデータが付加されていないと判断し（ステップＳ９３６にてＮｏ）、あるいはゲー
ムサーバ宛てデータを中継サーバ３に送信すると（ステップＳ９３８）、携帯電話機１ａ
からリクエストを受信した時刻から所定の待機時間が経過するまで待機する（ステップＳ
９４０）。この待機時間は、携帯電話機１ａでのリクエスト発信時間（本実施形態では８
秒）よりも短く、例えば１秒である。リクエスト受信時刻は、接続レコード７２中の最新
リクエスト日時として記録されている。この待機の間、ゲームサーバ５から中継サーバ３
に携帯電話機宛てデータが送信されれば、そのデータは、上述したようにしてバッファ記
憶領域４８に格納される。

この待機の後、中継サーバ３は、ステップＳ９２２で受信したユーザＩＤを含む接続レ
コード７２内のバッファデータをバッファ記憶領域４８から読み取り、ＨＴＴＰに準拠し
たデータに変換して、携帯電話機１ａにレスポンスと共に送信する（ステップＳ９４２）
。携帯電話機１ａが、このレスポンスを受信すると、携帯電話機１ａと中継サーバ３との
一つのセッションが終了する（ステップＳ９１０）。

図６では、上記の待機時間が符号Ｔｗで表され、携帯電話機１ａからのリクエストＲ２
の受信時刻からゲームサーバ５からのレスポンス受信時刻までに経過した時間が符号Ｔ２
で表されている。図６に示されるように、待機時間Ｔｗが経過する前にゲームサーバ５か
らのレスポンスが中継サーバ３に届けば、リクエストＲ２に対する携帯電話機１ａへのレ
スポンスには、リクエストＲ２に応じたゲームサーバ５での処理結果が付加されることに
なる。

リクエストＲ２の発信からリクエスト発信時間Ｔｉが経過すると、新たなリクエストＲ
３が携帯電話機１ａから発信される。このリクエストＲ３には、ゲームサーバ宛てデータ
が付加されていないものとする。この場合も、中継サーバ３は、リクエストＲ３の受信時
刻から待機時間Ｔｗが経過するのを待ってから、送信バッファ４８に蓄積されたバッファ
データをＨＴＴＰに準拠したデータに変換し、リクエストＲ３に対するレスポンスと共に
携帯電話機１ａに送信する。このバッファデータには、待機中に中継サーバ３が受信した
携帯電話機宛てデータ（図６ではイベント情報）も含まれる。

携帯電話機１ａが切断リクエストＲ４を発信し、中継サーバ３がそれを受信すると、中
継サーバ３は、ゲームサーバ５へ切断リクエストを送信すると共に、その携帯電話機１ａ
のユーザＩＤを含む接続レコード７２を接続情報テーブル７０から削除する。これにより
、その接続レコード７２に対応するゲームサーバ５とのコネクションが切断される。切断
リクエストに応じてゲームサーバ５が実行する処理は、図８を参照して上述した通りであ
る。また、中継サーバ３は、携帯電話機１ａに最後のレスポンスを送信し、携帯電話機１
ａとのセッションを終了する。

以下では、本実施形態の利点を説明する。携帯電話機１ａはリクエスト／レスポンス型
の通信しか行えないため、ゲームサーバ５が自発的に携帯電話機１ａに情報を配信するこ
とはできない。しかし、通信システム１００では、携帯電話機１ａ宛てのデータがゲーム
サーバ５で不定期かつ頻繁に発生しても、中継サーバ３がそれらのデータを受信してバッ
ファ記憶領域４８に蓄積し、携帯電話機１ａからのリクエストに応じて携帯電話機１ａに
一括して送信する。このため、携帯電話機１ａ宛てのデータを少ない遅延で携帯電話機１
ａに配信することができる。この結果、ＭＭＯＲＰＧなど、リアルタイム性が要求される
通信サービスを携帯電話機１ａに適切に提供することができる。

また、ＨＴＴＰを用いる携帯電話機１ａに関しては中継サーバ３がプロトコルの変換を
行うので、メインサーバ５は、異なるプロトコルを使用する携帯電話機１ａおよびパーソ
ナルコンピュータ１ｂを、プロトコルの違いを意識することなく同じように取り扱うこと
ができる。したがって、異なるプロトコルを使用する通信端末１が共存するマルチプラッ
トフォーム環境を容易に実現することができる。

更に、中継サーバ３は、携帯電話機１ａからリクエストを受信した後、所定の待機時間
Ｔｗにわたって待機してから、そのリクエストに対するレスポンスを携帯電話機１ａに送
信する。このため、待機時間Ｔｗを適切に定めれば、携帯電話機１ａからのリクエストに
対してゲームサーバ５が生成した携帯電話機宛てデータを、そのリクエストに対するレス
ポンスに付加して携帯電話機１ａに送信することができる。

比較のため、待機をせずにレスポンスを携帯電話機１ａに送信する場合を考える。この
場合、通信端末１からのリクエストに応じてゲームサーバ５が生成するデータ（例えば、
ゲームサーバ５へ送信したゲームサーバ宛てデータの処理結果）は、次回のリクエストに
対するレスポンスに付加されて携帯電話機１ａに送信されることになり、遅延が比較的大
きい。

これに対し、本実施形態では、中継サーバ３がリクエスト受信後の待機時間Ｔｗ中に、
そのリクエストに応じて生成されたデータをゲームサーバ５から受信すれば、そのデータ
を同じリクエストに対するレスポンスに付加して携帯電話機１ａに送信することができる
。これにより、携帯電話機１ａへのデータ送信の遅延を更に低減し、リアルタイム性が要
求される通信サービスを携帯電話機１ａにいっそう適切に提供することができる。

第２実施形態
以下では、図１０および図１１を参照しながら、本発明に係る通信システムの第２の実
施形態を説明する。本実施形態の通信システムは、図１〜図５を参照して上述した通信シ
ステム１００と同様の構成を有している。図１０は、携帯電話機１ａ、中継サーバ３およ
びゲームサーバ５間の通信の一例を時系列的に示すシーケンス図であり、図１１は、図１
０に示されるシーケンスにおいてログイン成功後に携帯電話機１ａおよび中継サーバ３が
実行する処理を示すフローチャートである。本実施形態は、中継サーバ３におけるリクエ
スト受信後の待機に関する処理の点で第１実施形態と異なる。他の処理は第１実施形態と
同じである。以下では、本実施形態を第１実施形態との相違点を説明し、第１実施形態と
重複する説明は省略する。

図１１におけるステップＳ１１０２〜Ｓ１１４２の各処理は、図９におけるステップＳ
９０２〜Ｓ９４２の各処理と同じである。しかし、本実施形態は、携帯電話機１ａからの
リクエストにゲームサーバ宛てデータが付加されていないと中継サーバ３が判断した場合
（ステップＳ１１３６にてＮｏ）、リクエスト受信後の待機（ステップＳ１１４０）を行
わない点で第１実施形態と相違する。すなわち、本実施形態では、携帯電話機１ａからの
リクエストにゲームサーバ宛てデータが付加されていると判断されたときにだけ（ステッ
プＳ１１３６にてＹｅｓ）、待機時間Ｔｗにわたる待機が行われる（ステップＳ１１４０
）。中継サーバ３は、ゲームサーバ宛てデータを伴わないリクエストを受信すると、即座
にバッファ記憶領域４８からバッファデータを読み取り、ＨＴＴＰに準拠したデータに変
換した後、そのリクエストに対するレスポンスに付加して携帯電話機１ａに送信する（ス
テップＳ１１４２）。

本実施形態は、第１実施形態と同じ利点に加えて下記の利点を有している。すなわち、
ゲームサーバ宛てデータが付加されていないリクエストは、ゲームサーバ５による処理結
果を待つ必要のないリクエストであることが少なくない。本実施形態では、そのようなリ
クエストに対して待機を行わないので、ゲームサーバ５からの携帯電話機宛てデータをよ
り迅速に携帯電話機１ａに送信することができる。

以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形
態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能
である。

上記実施形態では通信システム１００が提供するサービスとしてオンラインゲームを挙
げているが、他の任意のサービスを提供してもよい。例えば、本発明に係る通信システム
は、株価情報、交通情報、天気予報、ニュースなどの情報を携帯電話機に配信するサービ
スを提供してもよい。また、本発明に係る通信システムは、インスタントメッセンジャー
サービスやスポーツ中継サービスを提供してもよい。

上記実施形態では、ゲームサーバ５がＴＣＰに従って通信を行う。しかし、本発明にお
けるメインサーバは、ＵＤＰ（User Datagram Protocol）など、他のプロトコルに従って
通信を行ってもよい。

上記実施形態では、中継サーバ３とゲームサーバ５が別個のハードウェアとして実装さ
れている。しかし、本発明では、中継サーバとメインサーバを、同一のコンピュータ上で
別個のサーバプログラムを動作させることにより実装してもよい。

実施形態に係る通信システムの構成を示す概略図である。 携帯電話機の構成を概略的に示すブロック図である。 中継サーバの構成を示すブロック図である。 ゲームサーバ５の構成を示すブロック図である。 中継サーバの機能ブロック図である。 第１実施形態における携帯電話機、中継サーバおよびゲームサーバ間の通信の一例を時系列的に示すシーケンス図である。 接続情報テーブルの構成を示す概略図である。 ゲームサーバが実行する処理を示すフローチャートである。 第１実施形態において携帯電話機および中継サーバが実行する処理を示すフローチャートである。 第２実施形態における携帯電話機、中継サーバおよびゲームサーバ間の通信の一例を時系列的に示すシーケンス図である。 第２実施形態において携帯電話機および中継サーバが実行する処理を示すフローチャートである。

符号の説明

１…通信端末、１ａ…携帯電話機、１ｂ…パーソナルコンピュータ、２…通信ネットワ
ーク、３…中継サーバ、５…ゲームサーバ、６…基地局、１６…通信装置、１８…送信バ
ッファ、３６…通信装置、３６ａ…端末用インタフェース、３６ｂ…ゲームサーバ用イン
タフェース、４４…プロトコル変換部、４６…バッファリング部、４８…バッファ記憶領
域、５６…通信装置、７０…接続情報テーブル、７２…接続レコード、８０…プロトコル
変換テーブル。

Claims (9)

1. 第１プロトコルと異なる第２プロトコルに従って通信を行うメインサーバと、
   前記第１プロトコルに従ってリクエスト／レスポンス型の通信を行う通信端末と前記第１プロトコルに従って通信すると共に、前記第２プロトコルに従って前記メインサーバと通信する中継サーバと、
   前記中継サーバがアクセスすることの可能な記憶装置と、
   を備え、
   前記中継サーバは、前記通信端末からユーザＩＤと共に送信される第１リクエストに応じて前記メインサーバとの通信接続を確立し、前記メインサーバから前記通信端末宛てのデータを受信すると、当該データを前記ユーザＩＤに関連付けて前記記憶装置に記憶し、前記通信端末が前記中継サーバに所定の時間間隔で定期的に第２リクエストを送信する場合に、前記通信端末から前記ユーザＩＤと共に前記第２リクエストを受信すると、前記第２リクエストを受信してから前記時間間隔よりも短い所定の待機時間が経過するまで前記通信端末にレスポンスを返すのを待ち、当該待機時間が経過した後に当該ユーザＩＤに関連付けられた前記通信端末宛てのデータを前記記憶装置から読み取り、前記第１プロトコルに準拠したデータに変換して、前記レスポンスに付加して当該記憶装置から読み取った前記通信端末宛てのデータを前記通信端末に送信する、
   通信システム。
2. 前記メインサーバは、前記通信端末宛てのデータが発生すると、前記中継サーバからのリクエストを待つことなく、前記通信端末宛てのデータを前記第２プロトコルに従って前記中継サーバに送信する、請求項１に記載の通信システム。
3. 前記中継サーバは、前記第２リクエストを前記通信端末から受信すると、前記メインサーバ宛てのデータが前記第２リクエストに付加されているか否かを判断し、前記メインサーバ宛てのデータが前記第２リクエストに付加されていると判断したときは、当該メインサーバ宛てのデータを前記第２プロトコルに準拠したデータに変換して前記メインサーバに送信すると共に、前記第２リクエストを受信してから所定の待機時間が経過した後に、前記通信端末宛てのデータを前記記憶装置から読み取り、前記メインサーバ宛てのデータが前記第２リクエストに付加されていないと判断したときは、前記待機時間の経過を待つことなく、前記通信端末宛てのデータを前記記憶装置から読み取る、請求項１に記載の通信システム。
4. 前記第１のプロトコルでは、単位時間当たりのリクエスト発信回数の上限が定められている、請求項１〜３のいずれかに記載の通信システム。
5. 第１プロトコルと異なる第２プロトコルに従って通信を行うメインサーバと、記憶装置とを備える通信システム内に設置され、前記第１プロトコルに従ってリクエスト／レスポンス型の通信を行う通信端末と前記第１プロトコルに従って前記通信端末と通信すると共に、前記第２プロトコルに従って前記メインサーバと通信し、前記記憶装置にアクセス可能な中継サーバであって、
   前記通信端末からユーザＩＤと共に送信される第１リクエストに応じて前記メインサーバとの通信接続を確立する通信接続手段と、
   前記メインサーバから前記通信端末宛てのデータを受信すると、当該データを前記ユーザＩＤに関連付けて前記記憶装置に記憶する記憶手段と、
   前記通信端末が前記中継サーバに所定の時間間隔で定期的に第２リクエストを送信する場合に、前記通信端末から前記ユーザＩＤと共に前記第２リクエストを受信すると、前記第２リクエストを受信してから前記時間間隔よりも短い所定の待機時間が経過するまで前記通信端末にレスポンスを返すのを待ち、当該待機時間が経過した後に当該ユーザＩＤに関連付けられた前記通信端末宛てのデータを前記記憶装置から読み取り、前記第１プロトコルに準拠したデータに変換する第１変換手段と、
   この変換されたデータを前記レスポンスに付加して前記通信端末に送信する第１送信手段と、
   を備える中継サーバ。
6. 前記メインサーバは、前記通信端末宛てのデータが発生すると、前記中継サーバからのリクエストを待つことなく、前記通信端末宛てのデータを前記第２プロトコルに従って前記中継サーバに送信する、請求項５に記載の中継サーバ。
7. 前記第２リクエストを前記通信端末から受信すると、前記メインサーバ宛てのデータが前記第２リクエストに付加されているか否かを判断する判断手段と、
   前記メインサーバ宛てのデータが前記第２リクエストに付加されていると判断されたときに、当該メインサーバ宛てのデータを前記第２プロトコルに準拠したデータに変換する第２変換手段と、
   前記第２変換手段によって変換されたデータを前記メインサーバに送信する第２送信手段と、
   を更に備え、
   前記第１変換手段は、前記メインサーバ宛てのデータが前記第２リクエストに付加されていると判断されたときは、前記第２リクエストを受信してから所定の待機時間が経過した後に、前記通信端末宛てのデータを前記記憶装置から読み取り、前記メインサーバ宛てのデータが付加されていないと判断されたときは、前記待機時間の経過を待つことなく、前記通信端末宛てのデータを前記記憶装置から読み取る、
   請求項５に記載の中継サーバ。
8. 前記第１のプロトコルでは、単位時間当たりのリクエスト発信回数の上限が定められている、請求項５〜７のいずれかに記載の中継サーバ。
9. 第１プロトコルと異なる第２プロトコルに従って通信を行うメインサーバと、第１プロトコルに従ってリクエスト／レスポンス型の通信を行う通信端末と前記第１プロトコルに従って前記通信端末と通信すると共に、前記第２プロトコルに従って前記メインサーバと通信する中継サーバと、前記中継サーバがアクセスすることの可能な記憶装置とを備える通信システムにおいて、前記通信端末と前記メインサーバとの間で通信を行う方法であって、
   前記中継サーバが、前記通信端末がユーザＩＤと共に前記中継サーバに送信する前記第１リクエストに応じて前記メインサーバとの通信接続を確立するステップと、
   前記メインサーバが、前記通信端末宛てのデータを前記中継サーバに送信するステップと、
   前記中継サーバが、前記通信端末宛ての当該データを、前記ユーザＩＤに関連付けて前記記憶装置に記憶するステップと、
   前記中継サーバが、前記通信端末が前記中継サーバに所定の時間間隔で定期的に第２リクエストを送信し、このとき前記通信端末が前記ユーザＩＤと共に第２リクエストを前記中継サーバに送信した場合に、前記第２リクエストを受信してから前記時間間隔よりも短い所定の待機時間が経過するまで前記通信端末にレスポンスを返すのを待ち、当該待機時間が経過した後に前記第２リクエストと共に送信された前記ユーザＩＤに関連付けられた前記通信端末宛てのデータを前記記憶装置から読み取り、前記第１プロトコルに準拠したデータに変換するステップと、
   前記中継サーバが、この第１プロトコルに準拠したデータを前記レスポンスに付加して前記通信端末に送信するステップと、
   を備える通信方法。

Images