JP2004118325A - データ通信方法及びデータ通信システム - Google Patents
データ通信方法及びデータ通信システム Download PDFInfo
- Publication number
- JP2004118325A JP2004118325A JP2002277647A JP2002277647A JP2004118325A JP 2004118325 A JP2004118325 A JP 2004118325A JP 2002277647 A JP2002277647 A JP 2002277647A JP 2002277647 A JP2002277647 A JP 2002277647A JP 2004118325 A JP2004118325 A JP 2004118325A
- Authority
- JP
- Japan
- Prior art keywords
- terminal device
- server
- generated
- predetermined information
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】本発明の課題は、要求／応答型の通信手順に従った通信システムにおいて、データ通信量を削減することにある。
【解決手段】本発明は、要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバであって、端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信する受信手段と、要求メッセージにて指定された所定の情報を取得する取得手段と、所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、取得手段は、所定の情報が発生していない場合には、前記所定の情報が発生するまで待機することを特徴とする。
【選択図】 図４
【解決手段】本発明は、要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバであって、端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信する受信手段と、要求メッセージにて指定された所定の情報を取得する取得手段と、所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、取得手段は、所定の情報が発生していない場合には、前記所定の情報が発生するまで待機することを特徴とする。
【選択図】 図４
Description
【０００１】
【発明の属する技術分野】
本発明は、端末装置とサーバとにより構成される通信システム及び通信方法の技術に関する。
【０００２】
【従来の技術】
今日、インターネット等の普及に伴い、ネットワークを利用した様々なゲームが登場している。このようなネットワークを利用したゲームには、例えば、マージャンゲームがある。このマージャンゲームは、各プレーヤが自分の端末装置からネットワークを介してサーバにアクセスし、ネットワーク上で他のプレーヤとマージャンをするというものである。
【０００３】
このようなマージャンゲームの流れについて、図９を用いて説明する。プレーヤの端末装置には、マージャンゲームを実行するためのアプリケーションが予め実装されている。マージャンゲームに必要なプレーヤ（例えば４人）が、全員、サーバにアクセスすると、ゲームが開始される。
【０００４】
まず、サーバと端末装置は、それぞれのゲーム環境を初期化する（Ｓ１００１、Ｓ２００１）。そして、サーバは、各プレーヤの牌を決定し、それぞれの端末装置へ決定した牌を通知する（Ｓ１００２）。端末装置は、サーバから牌を受信すると、画面に表示する（Ｓ２００２）。ここで、プレーヤは、自分の牌を確認することができる。
【０００５】
次に、サーバは、次の順番のプレーヤ（例えば、プレーヤＡ）のツモった牌を決定し、プレーヤＡの端末装置へ決定した牌を通知する（Ｓ１００３）。プレーヤＡの端末装置は、サーバから牌を受信すると、画面に表示する（Ｓ２００３）。プレーヤＡは、自分がツモった牌を確認すると、持っている牌の中から捨てる牌を選択する（Ｓ２００４）。端末装置は、プレーヤＡが選択した捨て牌を、サーバに送信する（Ｓ２００５）。
【０００６】
サーバは、プレーヤＡの端末装置から、プレーヤＡの捨て牌を受信すると（Ｓ１００４）、他のプレーヤ（例えば、プレーヤＢ、プレーヤＣ、プレーヤＤ）に、プレーヤＡの捨て牌を通知する（Ｓ１００５）。他のプレーヤの端末装置は、プレーヤＡの捨て牌を受信すると、画面に表示する（Ｓ２００５）。これにより、他のプレーヤは、プレーヤＡが捨てた牌を確認する。
【０００７】
続いて、サーバは、受信したプレーヤＡの捨て牌に基づいて、プレーヤＡがあがったか否かを判断し（Ｓ１００６）プレーヤＡが上がっていないと判断した場合は、Ｓ１００３に戻り、次の順番のプレーヤ（例えば、プレーヤＢ）のツモった牌を決定し、プレーヤＢの端末装置へ通知する（Ｓ１００３）。以後、プレーヤのいずれかが上がるまで、牌の通知や捨て碑の受信等を繰り返す。
【０００８】
一方、サーバは、プレーヤＡが上がったと判断した場合は、プレーヤＡが上がった旨を、他のプレーヤの端末装置へ通知する（Ｓ１００７）。他のプレーヤの端末装置は、プレーヤＡが上がった旨を受信すると、その旨を画面に表示する（Ｓ２００６）。これにより、他のプレーヤは、プレーヤＡが上がったこと、つまり、ゲームが終了したことを知る。サーバは、各プレーヤの得点を計算し、各プレーヤの端末装置へ通知する（Ｓ１００８）。各プレーヤの端末装置は、得点を受信すると、画面に表示する。
【０００９】
このようなマージャンゲームでは、ゲームの進行に合わせて発生するサーバ側の情報を、リアルタイムで端末装置へ通知する必要がある。例えば、各プレーヤの牌を決定したとき（Ｓ１００２、Ｓ１００３）や、プレーヤの捨て牌を受信したとき（Ｓ１００４）等である。
【００１０】
そこで、従来、ＨＴＴＰプロトコル（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を前提とした通信方法では、このような情報をリアルタイムで端末装置へ通知するために、端末装置からサーバに対しリクエストを定期的に送信する方法（ポーリング）が採られていた。ＨＴＴＰプロトコルのように、端末装置が要求（ｒｅｑｕｅｓｔ）をかけると、それに対してサーバが応答（ｒｅｓｐｏｎｓｅ）するリクエスト／レスポンス型のプロトコルの場合、サーバ側から自発的に情報を通知することができないからである。
【００１１】
図１０は、ＨＴＴＰプロトコルに基づいてサーバ側の情報を端末装置へ通知する従来の処理の流れを説明するための図である。なお、ここでは、ゲームの進行に応じて発生しサーバから端末装置へ通知する必要のある情報を、イベント情報と呼ぶものとする。クライアントの通信ソフトとサーバの通信ソフトは、ＨＴＴＰプロトコルに従って、要求メッセージと応答メッセージを送受信する。クライアントのアプリケーションは、ゲームの進行に応じて、イベント情報の取得指示を通信ソフトへ通知する。通信ソフトは、アプリケーションの指示に従い、イベント情報の取得要求メッセージを、サーバへ送信する（Ｒｅｑｕｅｓｔ（１））。サーバの通信ソフトは、イベント情報の取得要求メッセージを受け付けると、イベント情報をアプリケーションから取得する。しかし、ここでは、イベント情報が存在しないので、サーバのアプリケーションは、その旨を通信ソフトへ通知する。サーバの通信ソフトは、イベント情報が存在しない旨を応答メッセージとしてクライアントへ通知する（Ｒｅｓｐｏｎｓｅ（１））。
【００１２】
クライアントの通信ソフトは、受信した応答メッセージからイベント情報がサーバに存在しないことを認識すると、再度、イベント情報の取得要求メッセージを、サーバへ送信する（Ｒｅｑｕｅｓｔ（２））。しかし、この時点でも、イベント情報は発生していないので、イベント情報は存在しない旨がクライアントへ通知される（Ｒｅｓｐｏｎｓｅ（２））。
【００１３】
クライアントの通信ソフトは、再度、イベント情報の取得要求メッセージを、サーバへ送信する（Ｒｅｑｕｅｓｔ（３））。すると、今度は、イベント情報が発生しているので、サーバのアプリケーションは、イベント情報を通信ソフトへ通知する。サーバの通信ソフトは、イベント情報を応答メッセージとしてクライアントへ通知する（Ｒｅｓｐｏｎｓｅ（３））。クライアントの通信ソフトは、応答メッセージを受け付け、イベント情報の受信を確認すると、イベント情報をアプリケーションに通知する。
【００１４】
【発明が解決しようとする課題】
しかしながら、上述したような従来の通信方法では、以下に述べるような問題があった。
【００１５】
第１に、サーバの情報を取得するまでリクエストを繰り返し送信する従来のポーリング方法では、サーバ側で通知すべき情報が発生していない場合にも、定期的に通信を行う必要があるため、通信コストが高くなりやすいという問題があった。つまり、端末装置がサーバから情報を取得するまで、要求メッセージと応答メッセージが繰り返し送受信されるので、データ通信量が多くなる。よって、データ通信量に応じて料金が課金される場合には、ゲームに要する通信コストが高くなりやすく、プレーヤの負担となっていた。
【００１６】
第２に、従来のポーリング方法では、端末装置は、サーバ側で発生した情報をリアルタイムで取得することが困難であった。つまり、従来のポーリング方法では、サーバは、端末装置へ通知すべきイベント情報が発生しても、次のリクエストが送信されるまでは、イベント情報を通知することができない。よって、端末装置は、ポーリングの周期よりも早くサーバ側の情報を取得することができないからである。
【００１７】
そこで、本発明の第１の課題は、リクエスト／レスポンス型の通信手順に従った通信システムにおいて、データ通信量を抑えながら、サーバ側の情報を端末装置へ通知することができる通信システム及び通信方法を提供することにある。
【００１８】
また、本発明の第２の課題は、リクエスト／レスポンス型の通信手順に従った通信システムにおいて、サーバ側で通知すべき情報が発生した場合に、その情報をリアルタイムで端末装置へ通知することができる通信システム及び通信方法を提供することにある。
【００１９】
【課題を解決するための手段】
上記課題を解決するための本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバであって、前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信する受信手段と、前記受信された要求メッセージにて指定された所定の情報を取得する取得手段と、前記取得された所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、前記取得手段は、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機することを特徴とする。
【００２０】
前記取得手段は、前記要求メッセージの受信後、所定の時間内に前記所定の情報を取得できない場合には、前記待機を中止し、前記送信手段は、前記所定の情報が発生していない旨の応答メッセージを送信することを特徴とする。
【００２１】
前記所定の情報は、前記端末装置の動作とは非同期にサーバにより生成される情報及び前記端末装置の動作とは非同期に他の端末装置からサーバに送信される情報のうち、少なくともいずれか１つの情報を含むことを特徴とする。
【００２２】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、前記端末装置の動作とは非同期に発生する所定の情報をサーバが端末装置へ通知する通知方法であって、前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信し、該受信された要求メッセージにて指定された所定の情報が発生していない場合には、前記所定の情報が発生するまで待機し、前記所定の情報が発生したときに、この発生した所定の情報に基づく応答メッセージを前記端末装置へ送信することを特徴とする。
【００２３】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバに、前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信するステップ、前記受信された要求メッセージにて指定された所定の情報が発生していない場合には、前記所定の情報が発生するまで待機するステップ、前記所定の情報が発生した場合に、この発生した所定の情報を取得するステップ、前記取得された所定の情報に基づいて応答メッセージを生成するステップ、前記生成された応答メッセージを前記端末装置へ送信するステップ、を実行させるためのプログラムである。
【００２４】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバとの間で通信を行う端末装置であって、前記端末装置の動作とは非同期に発生する所定の情報に対する取得要求と、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機する旨の条件と、を含む要求メッセージを、前記サーバへ送信する送信手段、を備えることを特徴とする。
【００２５】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って通信を行う通信システムであって、前記端末装置は、該端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージをサーバに送信する送信手段、を備え、前記サーバは、前記送信された要求メッセージを受信する受信手段と、前記受信された要求メッセージにて指定された所定の情報を取得する取得手段と、前記取得された所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、前記取得手段は、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機し、前記所定の情報が発生したときに、該発生した所定の情報を取得することを特徴とする。
【００２６】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って通信を行う通信システムにおける通信方法であって、前記端末装置は、該端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージをサーバに送信し、前記サーバは、前記送信された要求メッセージを受信し、この受信した要求メッセージにて指定された所定の情報が発生していない場合には、前記送信された要求メッセージに対する応答メッセージの送信を中止し、前記端末装置は、前記要求メッセージの送信後所定の時間が経過しても前記サーバから応答メッセージを受信していない場合には、前記サーバから前記要求メッセージにて指定した所定の情報が発生していない旨の応答メッセージを受信したものとみなす、ことを特徴とする。
【００２７】
上記本発明によれば、サーバ側で通知すべき情報が発生していない場合には、所定の情報が発生するまで待機し、所定の情報が発生したときに、その発生した情報を通知することとしたので、端末装置の動作とは非同期に発生する所定の情報を、リアルタイムで端末装置に通知することができるようになる。
【００２８】
また、本発明によれば、サーバ側で通知すべき情報が発生していない場合には、情報が発生するまで待機するので、端末装置とサーバ間のリクエスト及びレスポンスの回数を減らすことができる結果、通信量及び通信費用を抑えることが可能になる。
【００２９】
【発明の実施の形態】
次に、本発明の実施の形態について、図面を参照しつつ説明する。なお、本実施形態では、端末装置とサーバとの間の通信は、ＨＴＴＰプロトコルに従って行われるものとする。また、本実施形態では、要求メッセージを送信する端末装置の動作とは非同期に発生する情報であって、サーバから端末装置へ通知すべき情報（端末装置がサーバから取得すべき情報）を、イベント情報と呼ぶものとする。本実施形態でいうイベント情報は、典型的には、通信ゲームにおけるゲームの進行やプレーヤの決定・選択に応じて発生する情報が該当するが、本発明に係るイベント情報は、ゲームに限られず、例えば、交通情報や天気予報、株価情報、ニュースなどでもよい。
【００３０】
［第１の実施の形態］
第１の実施の形態では、端末装置からイベント情報の要求メッセージを受け付けたサーバは、要求メッセージに対応するイベント情報が発生するまで待機し、イベント情報が発生したときに、応答メッセージとして端末装置へ通知することを特徴とする。換言すれば、サーバは、イベント情報が発生していない場合は、イベント情報が発生するまで応答メッセージの送信を保留することを特徴とする。
【００３１】
［イベント情報］
本実施形態に係るイベント情報は、既述のように、端末装置の動作とは非同期に発生する情報であって、通信ゲームにおけるゲームの進行やプレーヤの決定・選択に応じて発生する情報であるが、イベント情報の内容や発生タイミングは、サーバ側の要求仕様に応じて適宜これを定義することが可能である。なお、ここでは、ゲームの進行に伴いサーバがイベント情報を生成した場合や、ゲームの進行に伴いプレーヤの端末装置からサーバがイベント情報を受信した場合に、イベント情報が発生する。
【００３２】
サーバが生成するイベント情報には、例えば、ゲーム開始時に決定される各プレーヤの牌や、該当するプレーヤがツモった牌、各プレーヤの待ち時間制限によるタイムアウト、プレーヤが上がった際の各プレーヤの得点、などが該当する。また、他のプレーヤの端末装置から受信するイベント情報には、例えば、プレーヤの捨て牌が該当する。
【００３３】
［システム全体の構成］
図１は、本発明にかかる通信システムの全体構成を表す図である。本通信システムは、ユーザにより使用される端末装置１と、所定のイベント情報をユーザの端末装置１に通知するサーバ２とを備え、端末装置１とサーバ２とは、通信路３を介して通信可能に構成されている。なお、端末装置１とサーバ２との間の通信は、ＨＴＴＰプロトコルに従って行われるものとする。
【００３４】
端末装置１は、ＨＴＴＰプロトコルに従って通信を行うためのクライアント用の通信ソフト１０と、所定のアプリケーション１２と、を実装している。ここでは、マージャンゲームを実行するアプリケーション１２が実装されているものとする。プレーヤの操作に従い、アプリケーション１２が起動されると、端末装置１は通信路３を介してサーバ２へアクセスする。以後、端末装置１は、ゲームの進行に従って、サーバ２との間でデータ通信を行う。
【００３５】
サーバ２は、ＨＴＴＰプロトコルに従って通信を行うためのサーバ用の通信ソフト２０と、所定のアプリケーション２２と、を実装している。ここでは、既述のように、マージャンゲームを実行するアプリケーション２２が実装されているものとする。サーバ２は、各端末装置１（端末装置Ａ、Ｂ、Ｃ、Ｄ）との間でデータ通信を行うことにより、ゲーム全体の進行を制御する。
【００３６】
なお、本実施形態では、端末装置１の一例として、携帯電話（携帯移動端末）が採用されている。端末装置１はパケット通信網に、サーバ２はインターネットに、それぞれ接続され、端末装置１とサーバ２は、通信路３に設けられたゲートウェイ（図示せず）を介して通信可能に構成されている。
【００３７】
［クライアントの構成］
図２は、端末装置（クライアント）１の機能を示す機能構成図である。端末装置１は、通信ソフト１０やアプリケーション１２によって規定された各処理を実行する制御手段（図示せず）を備えており、図２は、その制御手段が実行する各処理を、それぞれ機能実現手段としてとらえて図示している。端末装置１は、通信ソフト１０に規定された各処理を実行することにより、リクエスト生成手段１００、通知条件付加手段１０２、リクエスト送信手段１０４、レスポンス受信手段を備える。
【００３８】
リクエスト生成手段１００は、アプリケーション１２（ゲーム制御手段１２０）の指示に従って、サーバに送信すべきリクエストを生成する。具体的には、アプリケーション１２から指示されたイベント情報の取得要求を、サーバに送信するためのリクエストを生成する。リクエストを生成すると、生成したリクエストを通知条件付加手段１０２に通知する。
【００３９】
通知条件付加手段１０２は、リクエスト生成手段１００より生成されたリクエストに、所定の通知条件を付加する。ここで、所定の通知条件とは、「サーバ側にイベント情報が発生していない場合には、イベント情報が発生するまで待機し、イベント情報が発生した時点で、そのイベント情報を通知する」、という条件が該当する。
【００４０】
この所定の通知条件は、任意の構成でリクエストに付加することができるが、本実施形態では、リクエストに含まれる通知条件フラグとして設定する。具体的には、待機を指定する場合には、通知条件フラグをＯＮに設定し、待機を指定しない場合には、ＯＦＦを設定する。また、所定の通知条件をリクエストに付加するか否かは、任意にこれを設定することができる。例えば、アプリケーション単位で指定したり、イベント情報の属性に応じて指定したりすることもできる。通知条件付加手段１０２は、所定の通知条件を付加すると、所定の通知条件が付加されたリクエストを、リクエスト送信手段１０４に通知する。
【００４１】
リクエスト送信手段１０４は、受け付けたリクエストをサーバ２に送信する。具体的には、リクエスト送信手段１０４は、通知条件付加手段１０２からリクエストを受け付けると、サーバ２に対してコネクションの確立を要求し、サーバ２から正常なレスポンスを受け付けると、コネクションが成立する。リクエスト送信手段１０４は、続いて、イベント情報の取得要求であるリクエストをサーバ２に対して送信する。サーバ２は、リクエストを受け付けると、要求されたイベント情報をレスポンスとして端末装置１へ送り返す。
【００４２】
レスポンス受信手段１０６は、サーバ２から送信されるレスポンスを受信する。例えば、レスポンス受信手段１０６は、レスポンスのステータスに含まれる応答コードを参照し、要求が正常に処理されたか否かを判断する。要求が正常に処理されている場合には、取得したイベント情報をアプリケーション１２（ゲーム制御手段１２０）に通知する。一方、要求が正常に処理されなかった場合には、リクエストを再度送信する旨をリクエスト送信手段１０４に通知する。なお、ゲーム制御手段１２０は、受け取ったイベント情報をゲームの進行に応じて処理する。例えば、イベント情報記憶手段１２２に記憶するとともに、画面に表示する。
【００４３】
［サーバの構成］
図３は、サーバ２の機能を示す機能構成図である。サーバ２は、通信ソフト２０やアプリケーション２２によって規定された各処理を実行する制御手段（図示せず）を備えており、図３は、その制御手段が実行する各処理を、それぞれ機能実現手段としてとらえて図示している。サーバ２は、通信ソフト２０規定された各処理を実行することにより、リクエスト受信手段２００、イベント情報取得手段２０２、タイムアウト計測手段２０８、レスポンス生成手段２０４、レスポンス送信手段２０６を備える。
【００４４】
リクエスト受信手段２００は、端末装置１からイベント情報の取得要求であるリクエストを受信する。具体的には、リクエストを受信すると、リクエストにて要求されているイベント情報を、イベント情報取得手段２０２に通知する。また、リクエスト受信手段２００は、リクエストを受信した旨を、タイムアウト計測手段２０８に通知する。なお、リクエストが、端末装置１からサーバ２に対してイベント情報（例えば、プレーヤの捨て牌）を送信するものである場合には、受信したイベント情報をアプリケーション２２のゲーム制御手段２２０に通知する。なお、ゲーム制御手段２２０は、イベント情報を受け取ると、ゲームの進行に応じて処理する。例えば、イベント情報がプレーヤの捨て牌である場合には、イベント情報記憶手段２２２に記憶するとともに、プレーヤが上がったか否かを判断する。
【００４５】
イベント情報取得手段２０２は、端末装置１から要求されたイベント情報をアプリケーション２２から取得する。具体的には、イベント情報取得手段２０２は、通知されたイベント情報をアプリケーション２２のゲーム制御手段２２０に問い合わせる。ゲーム制御手段２２０は、イベント情報記憶手段２２２にイベント情報が存在する場合には、そのイベント情報を読み出して、イベント情報取得手段２０２に通知する。イベント情報取得手段２０２は、イベント情報を取得すると、取得したイベント情報をレスポンス生成手段２０４に通知する。
【００４６】
一方、ゲーム制御手段２２０は、イベント情報が存在しない場合には、その旨を、イベント情報取得手段２０２に通知する。イベント情報取得手段２０２は、イベント情報を取得しなかった場合には、イベント情報が発生していないと判断し、イベント情報が通知されるまで待機する。ゲーム制御手段２２０は、イベント情報が発生した場合には、発生したイベント情報を、イベント情報取得手段２０２に通知する。イベント情報が発生した場合とは、例えば、プレーヤが捨て牌を決定して他の端末装置１から捨て牌の情報が送信された場合や、プレーヤが上がった場合などである。イベント情報取得手段２０２は、イベント情報を取得すると、取得したイベント情報をレスポンス生成手段２０４に通知する。
【００４７】
タイムアウト計測手段２０８は、イベント情報取得手段２０２がイベント情報の発生を待機する最大待機時間を計測する。最大待機時間とは、イベント情報取得手段２０２が、待機することのできる最大時間であり、例えば、ＨＴＴＰプロトコルにて規定されているタイムアウトが発生することを回避するために、該タイムアウトよりも短い時間で設定されている。タイムアウト計測手段２０８は、リクエスト受信手段２００から、リクエストを受信した旨の通知を受け付けると、時間の計測を開始する。そして、計測時間が、最大待機時間を経過した場合には、その旨をイベント情報取得手段２０２に通知する。イベント情報取得手段２０２は、最大待機時間を経過した旨の通知を受け付けると、イベント情報の待機を中止し、イベント情報が発生していない旨を、レスポンス生成手段２０４に通知する。なお、イベント情報取得手段２０２は、タイムアウト計測手段２０８から通知を受ける前に、イベント情報を取得した場合には、その旨をタイムアウト計測手段２０８に通知する。タイムアウト計測手段２０８には、イベント情報を取得した旨を受け付けると、時間の計測を中止する。
【００４８】
レスポンス生成手段２０４は、イベント情報もしくはイベント情報が発生していない旨を、イベント情報取得手段２０２から受け取ると、その旨を含むレスポンスを生成する。そして、生成したレスポンスをレスポンス送信手段２０６に通知する。
【００４９】
レスポンス送信手段２０６は、生成されたレスポンスを要求メッセージに対する応答として端末装置１に送り返す。また、端末装置１に対してコネクションの切断要求を送信する。端末装置１が、サーバ２からのコネクションの切断を要求に応じると、コネクションが切断される。
【００５０】
［イベント情報通知処理の流れ（１）］
次に、端末装置からのリクエストに応じてサーバがイベント情報を通知する、イベント情報通知処理の流れについて図４を用いて説明する。まず、端末装置側の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると、ＨＴＴＰプロトコルに従い、リクエスト（ｒｅｑｕｅｓｔ（１））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認する。サーバ側の通信ソフトは、アプリケーションにイベント情報が存在しない場合には、イベント情報が発生していないと判断し、イベント情報が発生するまで待機する。そして、アプリケーションからイベント情報を受信すると、そのイベント情報をレスポンス（Ｒｅｓｐｏｎｓｅ（１））として端末装置に通知する。端末装置側の通信ソフトは、サーバからイベント情報を取得すると、それをアプリケーションに通知する。
【００５１】
以上によれば、サーバ２は、イベント情報が発生すると、即座にそのイベント情報を端末装置１通知することができるようになる。また、端末装置１は、１回のリクエストで、サーバ２側のイベント情報を取得することができるようになる。
【００５２】
［イベント情報通知処理の流れ（２）］
次に、サーバ側の待機時間が最大待機時間を超えた場合のイベント情報通知処理の流れについて、図５を用いて説明する。
【００５３】
端末装置側の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると、ＨＴＴＰプロトコルに従い、リクエスト（ｒｅｑｕｅｓｔ（１））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認し、アプリケーションにイベント情報が発生していない場合には、イベント情報が発生するまで待機する。しかし、イベント情報が発生する前に、イベント情報の発生を待機可能な最大待機時間が経過した場合には、イベント情報が発生していない旨を、レスポンス（Ｒｅｓｐｏｎｓｅ（１））として端末装置に通知する。
【００５４】
端末装置側の通信ソフトは、サーバからイベント情報が発生していない旨を取得すると、再度、リクエスト（ｒｅｑｕｅｓｔ（２））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認し、アプリケーションにイベント情報が発生していない場合には、イベント情報が発生するまで待機する。そして、アプリケーションからイベント情報を受信すると、そのイベント情報をレスポンス（Ｒｅｓｐｏｎｓｅ（２））として端末装置に通知する。端末装置側の通信ソフトは、サーバからイベント情報を取得すると、それをアプリケーションに通知する。
【００５５】
以上によれば、通信エラー等によるタイムアウトが端末装置側へ通知される前に、イベント情報が発生していない旨を端末装置１に通知しているので、端末装置１は、イベント情報が発生していないためにレスポンスが遅いのか、他の通信エラーなどによりレスポンスが遅いのかを、判断することができるようになる。
【００５６】
［端末装置側の処理］
次に、端末装置側の処理の流れについて、図６を用いて説明する。端末装置１の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると（Ｓ６０１）、イベント情報の取得を要求する要求メッセージに、通知条件を付加して、サーバ２に送信する（Ｓ６０２）。既述のように、通知条件とは、サーバ側に要求するイベント情報が発生していない場合には、イベント情報の発生を待って、発生したイベント情報を端末装置へ通知するという条件である。通知条件は、具体的には、要求メッセージに含まれる通知条件フラグをＯＮに設定することにより付加される。
【００５７】
そして、端末装置１の通信ソフトは、応答メッセージをサーバ２から受信すると、要求したイベント情報を取得したか否かを判断し（Ｓ６０４）、応答メッセージにイベント情報が含まれていると判断する場合は（Ｓ６０４；ＹＥＳ）、イベント情報をアプリケーションに通知する（Ｓ６０５）。一方、応答メッセージにイベント情報が含まれていないと判断する場合は（Ｓ６０４；ＮＯ）、Ｓ６０２に戻り、通知条件を付加した要求メッセージを、再度、サーバ２へ送信する。
【００５８】
［サーバ側の処理］
次に、サーバ側の処理の流れについて、図７を用いて説明する。サーバ２の通信ソフトは、イベント情報の取得要求メッセージを端末装置１から受信すると（Ｓ７０１）、最大待機時間（タイムアウト）の計測を開始するとともに（Ｓ７０２）、イベント情報の取得をアプリケーションに要求する（Ｓ７０３）。
【００５９】
サーバ２の通信ソフトは、アプリケーションからイベント情報を取得したか否かを判断し（Ｓ７０４）、イベント情報を取得したと判断する場合には（Ｓ７０４；ＹＥＳ）、応答メッセージにイベント情報を添付して、端末装置１へ送信する（Ｓ７０５）。これに対し、イベント情報を取得していない（イベント情報が発生していない）と判断する場合には（Ｓ７０４；Ｎｏ）、イベント情報を取得するまで待機するか否かを判断する（Ｓ７０６）。具体的には、要求メッセージに含まれる通知条件フラグがＯＮに設定されている場合には、イベント情報を取得するまで待機すると判断する。なお、通知条件フラグがＯＦＦの場合には（Ｓ７０６；ＮＯ）、待機する必要がないので、Ｓ７０８にて、イベント情報が発生していない旨の応答メッセージをただちに送信する。
【００６０】
イベント情報を取得するまで待機すると判断した場合には（Ｓ７０６；ＹＥＳ）、続いて、最大待機時間が経過していないか否かを判断し（Ｓ７０７）、経過していないと判断する場合には（Ｓ７０７；ＮＯ）、ステップＳ７０４に戻り、処理を続ける。一方、最大待機時間が経過していると判断する場合には（Ｓ７０７；ＹＥＳ）、イベント情報の待機を解除し、応答メッセージにイベント情報は発生していない旨をセットして、端末装置１へ送信する（Ｓ７０８）。
【００６１】
［第２の実施の形態］
第１の実施の形態では、サーバ側で通知すべき情報が発生していない場合には、通知すべき情報が発生するまで待機する場合について説明した。しかし、第２の実施の形態では、サーバ側で通知すべき情報が発生していない場合には、サーバは、応答メッセージを送信せず、端末装置は、所定の時間が経過しても、サーバから応答メッセージが通知されない場合には、「通知すべき情報が発生していない」という応答メッセージが送信されたとみなす。つまり、第２の実施の形態では、応答メッセージの不送信により、通知すべき情報が発生していない旨を、端末装置へ通知することを、特徴とする。
【００６２】
ここで、図２及び図３を用いて、第２の実施の形態に係る端末装置及びサーバの機能について説明する。第２の実施の形態では、端末装置１の通知条件付加手段１０２は、通知条件として、「通知すべき情報が発生していない場合には、応答メッセージを送信しない」という条件を設定する。また、リクエスト送信手段１０４は、リクエストを送信すると、その旨をレスポンス受信手段１０６に通知する。
【００６３】
レスポンス受信手段１０６は、リクエストを送信した旨を受け付けると、非通知時間の計測を開始する。非通知時間は、端末装置からの取得要求に対してサーバが応答メッセージを通知するのに要する平均的な時間や、通信のトラフィック状況などを考慮して設定、更新される。レスポンス受信手段１０６は、非通知時間の計測開始後、設定された非通知時間を経過しても、サーバ２から応答メッセージを受信していない場合には、イベント情報不存在による応答メッセージの非通知であると判断する。そして、この場合、イベント情報が発生していない旨の応答メッセージを受信したものとみなし、その旨を、アプリケーションに通知する。
【００６４】
一方、サーバ２のイベント情報取得手段２０２は、アプリケーション２２からイベント情報が発生していない旨を受け付けると、通知条件に従って、応答メッセージを送信しない旨を決定する。よって、レスポンス送信手段２０６からは、応答メッセージが送信されない。
【００６５】
［イベント情報非通知処理の流れ］
次に、サーバ側で通知すべき情報が発生していない場合には、応答メッセージを送信しないイベント情報非通知処理の流れについて、図８を用いて説明する。図８では、イベント情報が存在する場合の処理と、イベント情報が発生していない場合の処理を、それぞれ記載している。
【００６６】
まず、端末装置側の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると、ＨＴＴＰプロトコルに従い、リクエスト（ｒｅｑｕｅｓｔ（１））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認する。アプリケーションにイベント情報が存在する場合には、そのイベント情報をレスポンス（Ｒｅｓｐｏｎｓｅ（１））として端末装置に通知する。端末装置側の通信ソフトは、サーバからイベント情報を取得すると、それをアプリケーションに通知する。
【００６７】
また、端末装置１の通信ソフトは、リクエスト（ｒｅｑｕｅｓｔ（２））をサーバに送信すると、これに伴い、非通知時間の計測を開始する。リクエスト（ｒｅｑｕｅｓｔ（２））を受け付けたサーバ側で、アプリケーションにイベント情報が発生していない場合には、通知条件に従って、応答メッセージを送信しない旨を決定する。端末装置１の通信ソフトは、非通知時間の計測開始後、設定された非通知時間を経過してもサーバ２から応答メッセージを受信していない場合には、イベント情報不存在による応答メッセージの非通知であると判断する。そして、この場合、イベント情報が発生していない旨の応答メッセージを受信したものとみなし、その旨を、アプリケーションに通知する。
【００６８】
以上によれば、応答メッセージの非通知という構成により、イベント情報が発生していない旨を端末装置側へ通知することができるようになる。よって、イベント情報が発生していない旨の応答メッセージの送信が不要となり、データ通信量ひいては通信コストを軽減することができるようになる。
【００６９】
［その他の実施の形態］
上記実施形態は、本発明を説明するための例示であり、本発明を上記実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱しない限り、さまざまな形態で実施することができる。例えば、上記機能実現手段の動作をシーケンシャルに説明したが、特にこれにこだわるものではない。従って、動作に矛盾が生じない限り、処理の順序を入れ替えまたは並行動作するように構成しても良い。
【００７０】
【発明の効果】
本発明によれば、リクエスト／レスポンス型の通信手順に従って所定の情報を送受信する通信システムにおいて、データ通信量を削減することが可能になる。また、端末装置の動作とは非同期に発生する所定の情報を、リアルタイムで端末装置に通知することができるようになる。
【図面の簡単な説明】
【図１】本発明にかかる通信システムの全体構成を表す図である
【図２】端末装置（クライアント）１の機能を示す機能構成図である。
【図３】サーバ２の機能を示す機能構成図である。
【図４】イベント情報通知処理の流れ（１）を示すフローチャートである。
【図５】イベント情報通知処理の流れ（２）を示すフローチャートである。
【図６】端末装置側の処理の流れを示すフローチャートである。
【図７】サーバ側の処理の流れを示すフローチャートである。
【図８】イベント情報非通知処理の流れ示すフローチャートである。
【図９】ネットワークゲームの流れを説明するための図である。
【図１０】ＨＴＴＰプロトコルに基づいてサーバ側の情報を端末装置へ通知する従来の処理の流れを説明するための図である。
【符号の説明】
１…端末装置
２…サーバ
３…通信路
１０…通信ソフト
１２…アプリケーション
２０…通信ソフト
２２…アプリケーション
【発明の属する技術分野】
本発明は、端末装置とサーバとにより構成される通信システム及び通信方法の技術に関する。
【０００２】
【従来の技術】
今日、インターネット等の普及に伴い、ネットワークを利用した様々なゲームが登場している。このようなネットワークを利用したゲームには、例えば、マージャンゲームがある。このマージャンゲームは、各プレーヤが自分の端末装置からネットワークを介してサーバにアクセスし、ネットワーク上で他のプレーヤとマージャンをするというものである。
【０００３】
このようなマージャンゲームの流れについて、図９を用いて説明する。プレーヤの端末装置には、マージャンゲームを実行するためのアプリケーションが予め実装されている。マージャンゲームに必要なプレーヤ（例えば４人）が、全員、サーバにアクセスすると、ゲームが開始される。
【０００４】
まず、サーバと端末装置は、それぞれのゲーム環境を初期化する（Ｓ１００１、Ｓ２００１）。そして、サーバは、各プレーヤの牌を決定し、それぞれの端末装置へ決定した牌を通知する（Ｓ１００２）。端末装置は、サーバから牌を受信すると、画面に表示する（Ｓ２００２）。ここで、プレーヤは、自分の牌を確認することができる。
【０００５】
次に、サーバは、次の順番のプレーヤ（例えば、プレーヤＡ）のツモった牌を決定し、プレーヤＡの端末装置へ決定した牌を通知する（Ｓ１００３）。プレーヤＡの端末装置は、サーバから牌を受信すると、画面に表示する（Ｓ２００３）。プレーヤＡは、自分がツモった牌を確認すると、持っている牌の中から捨てる牌を選択する（Ｓ２００４）。端末装置は、プレーヤＡが選択した捨て牌を、サーバに送信する（Ｓ２００５）。
【０００６】
サーバは、プレーヤＡの端末装置から、プレーヤＡの捨て牌を受信すると（Ｓ１００４）、他のプレーヤ（例えば、プレーヤＢ、プレーヤＣ、プレーヤＤ）に、プレーヤＡの捨て牌を通知する（Ｓ１００５）。他のプレーヤの端末装置は、プレーヤＡの捨て牌を受信すると、画面に表示する（Ｓ２００５）。これにより、他のプレーヤは、プレーヤＡが捨てた牌を確認する。
【０００７】
続いて、サーバは、受信したプレーヤＡの捨て牌に基づいて、プレーヤＡがあがったか否かを判断し（Ｓ１００６）プレーヤＡが上がっていないと判断した場合は、Ｓ１００３に戻り、次の順番のプレーヤ（例えば、プレーヤＢ）のツモった牌を決定し、プレーヤＢの端末装置へ通知する（Ｓ１００３）。以後、プレーヤのいずれかが上がるまで、牌の通知や捨て碑の受信等を繰り返す。
【０００８】
一方、サーバは、プレーヤＡが上がったと判断した場合は、プレーヤＡが上がった旨を、他のプレーヤの端末装置へ通知する（Ｓ１００７）。他のプレーヤの端末装置は、プレーヤＡが上がった旨を受信すると、その旨を画面に表示する（Ｓ２００６）。これにより、他のプレーヤは、プレーヤＡが上がったこと、つまり、ゲームが終了したことを知る。サーバは、各プレーヤの得点を計算し、各プレーヤの端末装置へ通知する（Ｓ１００８）。各プレーヤの端末装置は、得点を受信すると、画面に表示する。
【０００９】
このようなマージャンゲームでは、ゲームの進行に合わせて発生するサーバ側の情報を、リアルタイムで端末装置へ通知する必要がある。例えば、各プレーヤの牌を決定したとき（Ｓ１００２、Ｓ１００３）や、プレーヤの捨て牌を受信したとき（Ｓ１００４）等である。
【００１０】
そこで、従来、ＨＴＴＰプロトコル（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を前提とした通信方法では、このような情報をリアルタイムで端末装置へ通知するために、端末装置からサーバに対しリクエストを定期的に送信する方法（ポーリング）が採られていた。ＨＴＴＰプロトコルのように、端末装置が要求（ｒｅｑｕｅｓｔ）をかけると、それに対してサーバが応答（ｒｅｓｐｏｎｓｅ）するリクエスト／レスポンス型のプロトコルの場合、サーバ側から自発的に情報を通知することができないからである。
【００１１】
図１０は、ＨＴＴＰプロトコルに基づいてサーバ側の情報を端末装置へ通知する従来の処理の流れを説明するための図である。なお、ここでは、ゲームの進行に応じて発生しサーバから端末装置へ通知する必要のある情報を、イベント情報と呼ぶものとする。クライアントの通信ソフトとサーバの通信ソフトは、ＨＴＴＰプロトコルに従って、要求メッセージと応答メッセージを送受信する。クライアントのアプリケーションは、ゲームの進行に応じて、イベント情報の取得指示を通信ソフトへ通知する。通信ソフトは、アプリケーションの指示に従い、イベント情報の取得要求メッセージを、サーバへ送信する（Ｒｅｑｕｅｓｔ（１））。サーバの通信ソフトは、イベント情報の取得要求メッセージを受け付けると、イベント情報をアプリケーションから取得する。しかし、ここでは、イベント情報が存在しないので、サーバのアプリケーションは、その旨を通信ソフトへ通知する。サーバの通信ソフトは、イベント情報が存在しない旨を応答メッセージとしてクライアントへ通知する（Ｒｅｓｐｏｎｓｅ（１））。
【００１２】
クライアントの通信ソフトは、受信した応答メッセージからイベント情報がサーバに存在しないことを認識すると、再度、イベント情報の取得要求メッセージを、サーバへ送信する（Ｒｅｑｕｅｓｔ（２））。しかし、この時点でも、イベント情報は発生していないので、イベント情報は存在しない旨がクライアントへ通知される（Ｒｅｓｐｏｎｓｅ（２））。
【００１３】
クライアントの通信ソフトは、再度、イベント情報の取得要求メッセージを、サーバへ送信する（Ｒｅｑｕｅｓｔ（３））。すると、今度は、イベント情報が発生しているので、サーバのアプリケーションは、イベント情報を通信ソフトへ通知する。サーバの通信ソフトは、イベント情報を応答メッセージとしてクライアントへ通知する（Ｒｅｓｐｏｎｓｅ（３））。クライアントの通信ソフトは、応答メッセージを受け付け、イベント情報の受信を確認すると、イベント情報をアプリケーションに通知する。
【００１４】
【発明が解決しようとする課題】
しかしながら、上述したような従来の通信方法では、以下に述べるような問題があった。
【００１５】
第１に、サーバの情報を取得するまでリクエストを繰り返し送信する従来のポーリング方法では、サーバ側で通知すべき情報が発生していない場合にも、定期的に通信を行う必要があるため、通信コストが高くなりやすいという問題があった。つまり、端末装置がサーバから情報を取得するまで、要求メッセージと応答メッセージが繰り返し送受信されるので、データ通信量が多くなる。よって、データ通信量に応じて料金が課金される場合には、ゲームに要する通信コストが高くなりやすく、プレーヤの負担となっていた。
【００１６】
第２に、従来のポーリング方法では、端末装置は、サーバ側で発生した情報をリアルタイムで取得することが困難であった。つまり、従来のポーリング方法では、サーバは、端末装置へ通知すべきイベント情報が発生しても、次のリクエストが送信されるまでは、イベント情報を通知することができない。よって、端末装置は、ポーリングの周期よりも早くサーバ側の情報を取得することができないからである。
【００１７】
そこで、本発明の第１の課題は、リクエスト／レスポンス型の通信手順に従った通信システムにおいて、データ通信量を抑えながら、サーバ側の情報を端末装置へ通知することができる通信システム及び通信方法を提供することにある。
【００１８】
また、本発明の第２の課題は、リクエスト／レスポンス型の通信手順に従った通信システムにおいて、サーバ側で通知すべき情報が発生した場合に、その情報をリアルタイムで端末装置へ通知することができる通信システム及び通信方法を提供することにある。
【００１９】
【課題を解決するための手段】
上記課題を解決するための本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバであって、前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信する受信手段と、前記受信された要求メッセージにて指定された所定の情報を取得する取得手段と、前記取得された所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、前記取得手段は、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機することを特徴とする。
【００２０】
前記取得手段は、前記要求メッセージの受信後、所定の時間内に前記所定の情報を取得できない場合には、前記待機を中止し、前記送信手段は、前記所定の情報が発生していない旨の応答メッセージを送信することを特徴とする。
【００２１】
前記所定の情報は、前記端末装置の動作とは非同期にサーバにより生成される情報及び前記端末装置の動作とは非同期に他の端末装置からサーバに送信される情報のうち、少なくともいずれか１つの情報を含むことを特徴とする。
【００２２】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、前記端末装置の動作とは非同期に発生する所定の情報をサーバが端末装置へ通知する通知方法であって、前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信し、該受信された要求メッセージにて指定された所定の情報が発生していない場合には、前記所定の情報が発生するまで待機し、前記所定の情報が発生したときに、この発生した所定の情報に基づく応答メッセージを前記端末装置へ送信することを特徴とする。
【００２３】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバに、前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信するステップ、前記受信された要求メッセージにて指定された所定の情報が発生していない場合には、前記所定の情報が発生するまで待機するステップ、前記所定の情報が発生した場合に、この発生した所定の情報を取得するステップ、前記取得された所定の情報に基づいて応答メッセージを生成するステップ、前記生成された応答メッセージを前記端末装置へ送信するステップ、を実行させるためのプログラムである。
【００２４】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバとの間で通信を行う端末装置であって、前記端末装置の動作とは非同期に発生する所定の情報に対する取得要求と、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機する旨の条件と、を含む要求メッセージを、前記サーバへ送信する送信手段、を備えることを特徴とする。
【００２５】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って通信を行う通信システムであって、前記端末装置は、該端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージをサーバに送信する送信手段、を備え、前記サーバは、前記送信された要求メッセージを受信する受信手段と、前記受信された要求メッセージにて指定された所定の情報を取得する取得手段と、前記取得された所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、前記取得手段は、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機し、前記所定の情報が発生したときに、該発生した所定の情報を取得することを特徴とする。
【００２６】
また、本発明は、端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って通信を行う通信システムにおける通信方法であって、前記端末装置は、該端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージをサーバに送信し、前記サーバは、前記送信された要求メッセージを受信し、この受信した要求メッセージにて指定された所定の情報が発生していない場合には、前記送信された要求メッセージに対する応答メッセージの送信を中止し、前記端末装置は、前記要求メッセージの送信後所定の時間が経過しても前記サーバから応答メッセージを受信していない場合には、前記サーバから前記要求メッセージにて指定した所定の情報が発生していない旨の応答メッセージを受信したものとみなす、ことを特徴とする。
【００２７】
上記本発明によれば、サーバ側で通知すべき情報が発生していない場合には、所定の情報が発生するまで待機し、所定の情報が発生したときに、その発生した情報を通知することとしたので、端末装置の動作とは非同期に発生する所定の情報を、リアルタイムで端末装置に通知することができるようになる。
【００２８】
また、本発明によれば、サーバ側で通知すべき情報が発生していない場合には、情報が発生するまで待機するので、端末装置とサーバ間のリクエスト及びレスポンスの回数を減らすことができる結果、通信量及び通信費用を抑えることが可能になる。
【００２９】
【発明の実施の形態】
次に、本発明の実施の形態について、図面を参照しつつ説明する。なお、本実施形態では、端末装置とサーバとの間の通信は、ＨＴＴＰプロトコルに従って行われるものとする。また、本実施形態では、要求メッセージを送信する端末装置の動作とは非同期に発生する情報であって、サーバから端末装置へ通知すべき情報（端末装置がサーバから取得すべき情報）を、イベント情報と呼ぶものとする。本実施形態でいうイベント情報は、典型的には、通信ゲームにおけるゲームの進行やプレーヤの決定・選択に応じて発生する情報が該当するが、本発明に係るイベント情報は、ゲームに限られず、例えば、交通情報や天気予報、株価情報、ニュースなどでもよい。
【００３０】
［第１の実施の形態］
第１の実施の形態では、端末装置からイベント情報の要求メッセージを受け付けたサーバは、要求メッセージに対応するイベント情報が発生するまで待機し、イベント情報が発生したときに、応答メッセージとして端末装置へ通知することを特徴とする。換言すれば、サーバは、イベント情報が発生していない場合は、イベント情報が発生するまで応答メッセージの送信を保留することを特徴とする。
【００３１】
［イベント情報］
本実施形態に係るイベント情報は、既述のように、端末装置の動作とは非同期に発生する情報であって、通信ゲームにおけるゲームの進行やプレーヤの決定・選択に応じて発生する情報であるが、イベント情報の内容や発生タイミングは、サーバ側の要求仕様に応じて適宜これを定義することが可能である。なお、ここでは、ゲームの進行に伴いサーバがイベント情報を生成した場合や、ゲームの進行に伴いプレーヤの端末装置からサーバがイベント情報を受信した場合に、イベント情報が発生する。
【００３２】
サーバが生成するイベント情報には、例えば、ゲーム開始時に決定される各プレーヤの牌や、該当するプレーヤがツモった牌、各プレーヤの待ち時間制限によるタイムアウト、プレーヤが上がった際の各プレーヤの得点、などが該当する。また、他のプレーヤの端末装置から受信するイベント情報には、例えば、プレーヤの捨て牌が該当する。
【００３３】
［システム全体の構成］
図１は、本発明にかかる通信システムの全体構成を表す図である。本通信システムは、ユーザにより使用される端末装置１と、所定のイベント情報をユーザの端末装置１に通知するサーバ２とを備え、端末装置１とサーバ２とは、通信路３を介して通信可能に構成されている。なお、端末装置１とサーバ２との間の通信は、ＨＴＴＰプロトコルに従って行われるものとする。
【００３４】
端末装置１は、ＨＴＴＰプロトコルに従って通信を行うためのクライアント用の通信ソフト１０と、所定のアプリケーション１２と、を実装している。ここでは、マージャンゲームを実行するアプリケーション１２が実装されているものとする。プレーヤの操作に従い、アプリケーション１２が起動されると、端末装置１は通信路３を介してサーバ２へアクセスする。以後、端末装置１は、ゲームの進行に従って、サーバ２との間でデータ通信を行う。
【００３５】
サーバ２は、ＨＴＴＰプロトコルに従って通信を行うためのサーバ用の通信ソフト２０と、所定のアプリケーション２２と、を実装している。ここでは、既述のように、マージャンゲームを実行するアプリケーション２２が実装されているものとする。サーバ２は、各端末装置１（端末装置Ａ、Ｂ、Ｃ、Ｄ）との間でデータ通信を行うことにより、ゲーム全体の進行を制御する。
【００３６】
なお、本実施形態では、端末装置１の一例として、携帯電話（携帯移動端末）が採用されている。端末装置１はパケット通信網に、サーバ２はインターネットに、それぞれ接続され、端末装置１とサーバ２は、通信路３に設けられたゲートウェイ（図示せず）を介して通信可能に構成されている。
【００３７】
［クライアントの構成］
図２は、端末装置（クライアント）１の機能を示す機能構成図である。端末装置１は、通信ソフト１０やアプリケーション１２によって規定された各処理を実行する制御手段（図示せず）を備えており、図２は、その制御手段が実行する各処理を、それぞれ機能実現手段としてとらえて図示している。端末装置１は、通信ソフト１０に規定された各処理を実行することにより、リクエスト生成手段１００、通知条件付加手段１０２、リクエスト送信手段１０４、レスポンス受信手段を備える。
【００３８】
リクエスト生成手段１００は、アプリケーション１２（ゲーム制御手段１２０）の指示に従って、サーバに送信すべきリクエストを生成する。具体的には、アプリケーション１２から指示されたイベント情報の取得要求を、サーバに送信するためのリクエストを生成する。リクエストを生成すると、生成したリクエストを通知条件付加手段１０２に通知する。
【００３９】
通知条件付加手段１０２は、リクエスト生成手段１００より生成されたリクエストに、所定の通知条件を付加する。ここで、所定の通知条件とは、「サーバ側にイベント情報が発生していない場合には、イベント情報が発生するまで待機し、イベント情報が発生した時点で、そのイベント情報を通知する」、という条件が該当する。
【００４０】
この所定の通知条件は、任意の構成でリクエストに付加することができるが、本実施形態では、リクエストに含まれる通知条件フラグとして設定する。具体的には、待機を指定する場合には、通知条件フラグをＯＮに設定し、待機を指定しない場合には、ＯＦＦを設定する。また、所定の通知条件をリクエストに付加するか否かは、任意にこれを設定することができる。例えば、アプリケーション単位で指定したり、イベント情報の属性に応じて指定したりすることもできる。通知条件付加手段１０２は、所定の通知条件を付加すると、所定の通知条件が付加されたリクエストを、リクエスト送信手段１０４に通知する。
【００４１】
リクエスト送信手段１０４は、受け付けたリクエストをサーバ２に送信する。具体的には、リクエスト送信手段１０４は、通知条件付加手段１０２からリクエストを受け付けると、サーバ２に対してコネクションの確立を要求し、サーバ２から正常なレスポンスを受け付けると、コネクションが成立する。リクエスト送信手段１０４は、続いて、イベント情報の取得要求であるリクエストをサーバ２に対して送信する。サーバ２は、リクエストを受け付けると、要求されたイベント情報をレスポンスとして端末装置１へ送り返す。
【００４２】
レスポンス受信手段１０６は、サーバ２から送信されるレスポンスを受信する。例えば、レスポンス受信手段１０６は、レスポンスのステータスに含まれる応答コードを参照し、要求が正常に処理されたか否かを判断する。要求が正常に処理されている場合には、取得したイベント情報をアプリケーション１２（ゲーム制御手段１２０）に通知する。一方、要求が正常に処理されなかった場合には、リクエストを再度送信する旨をリクエスト送信手段１０４に通知する。なお、ゲーム制御手段１２０は、受け取ったイベント情報をゲームの進行に応じて処理する。例えば、イベント情報記憶手段１２２に記憶するとともに、画面に表示する。
【００４３】
［サーバの構成］
図３は、サーバ２の機能を示す機能構成図である。サーバ２は、通信ソフト２０やアプリケーション２２によって規定された各処理を実行する制御手段（図示せず）を備えており、図３は、その制御手段が実行する各処理を、それぞれ機能実現手段としてとらえて図示している。サーバ２は、通信ソフト２０規定された各処理を実行することにより、リクエスト受信手段２００、イベント情報取得手段２０２、タイムアウト計測手段２０８、レスポンス生成手段２０４、レスポンス送信手段２０６を備える。
【００４４】
リクエスト受信手段２００は、端末装置１からイベント情報の取得要求であるリクエストを受信する。具体的には、リクエストを受信すると、リクエストにて要求されているイベント情報を、イベント情報取得手段２０２に通知する。また、リクエスト受信手段２００は、リクエストを受信した旨を、タイムアウト計測手段２０８に通知する。なお、リクエストが、端末装置１からサーバ２に対してイベント情報（例えば、プレーヤの捨て牌）を送信するものである場合には、受信したイベント情報をアプリケーション２２のゲーム制御手段２２０に通知する。なお、ゲーム制御手段２２０は、イベント情報を受け取ると、ゲームの進行に応じて処理する。例えば、イベント情報がプレーヤの捨て牌である場合には、イベント情報記憶手段２２２に記憶するとともに、プレーヤが上がったか否かを判断する。
【００４５】
イベント情報取得手段２０２は、端末装置１から要求されたイベント情報をアプリケーション２２から取得する。具体的には、イベント情報取得手段２０２は、通知されたイベント情報をアプリケーション２２のゲーム制御手段２２０に問い合わせる。ゲーム制御手段２２０は、イベント情報記憶手段２２２にイベント情報が存在する場合には、そのイベント情報を読み出して、イベント情報取得手段２０２に通知する。イベント情報取得手段２０２は、イベント情報を取得すると、取得したイベント情報をレスポンス生成手段２０４に通知する。
【００４６】
一方、ゲーム制御手段２２０は、イベント情報が存在しない場合には、その旨を、イベント情報取得手段２０２に通知する。イベント情報取得手段２０２は、イベント情報を取得しなかった場合には、イベント情報が発生していないと判断し、イベント情報が通知されるまで待機する。ゲーム制御手段２２０は、イベント情報が発生した場合には、発生したイベント情報を、イベント情報取得手段２０２に通知する。イベント情報が発生した場合とは、例えば、プレーヤが捨て牌を決定して他の端末装置１から捨て牌の情報が送信された場合や、プレーヤが上がった場合などである。イベント情報取得手段２０２は、イベント情報を取得すると、取得したイベント情報をレスポンス生成手段２０４に通知する。
【００４７】
タイムアウト計測手段２０８は、イベント情報取得手段２０２がイベント情報の発生を待機する最大待機時間を計測する。最大待機時間とは、イベント情報取得手段２０２が、待機することのできる最大時間であり、例えば、ＨＴＴＰプロトコルにて規定されているタイムアウトが発生することを回避するために、該タイムアウトよりも短い時間で設定されている。タイムアウト計測手段２０８は、リクエスト受信手段２００から、リクエストを受信した旨の通知を受け付けると、時間の計測を開始する。そして、計測時間が、最大待機時間を経過した場合には、その旨をイベント情報取得手段２０２に通知する。イベント情報取得手段２０２は、最大待機時間を経過した旨の通知を受け付けると、イベント情報の待機を中止し、イベント情報が発生していない旨を、レスポンス生成手段２０４に通知する。なお、イベント情報取得手段２０２は、タイムアウト計測手段２０８から通知を受ける前に、イベント情報を取得した場合には、その旨をタイムアウト計測手段２０８に通知する。タイムアウト計測手段２０８には、イベント情報を取得した旨を受け付けると、時間の計測を中止する。
【００４８】
レスポンス生成手段２０４は、イベント情報もしくはイベント情報が発生していない旨を、イベント情報取得手段２０２から受け取ると、その旨を含むレスポンスを生成する。そして、生成したレスポンスをレスポンス送信手段２０６に通知する。
【００４９】
レスポンス送信手段２０６は、生成されたレスポンスを要求メッセージに対する応答として端末装置１に送り返す。また、端末装置１に対してコネクションの切断要求を送信する。端末装置１が、サーバ２からのコネクションの切断を要求に応じると、コネクションが切断される。
【００５０】
［イベント情報通知処理の流れ（１）］
次に、端末装置からのリクエストに応じてサーバがイベント情報を通知する、イベント情報通知処理の流れについて図４を用いて説明する。まず、端末装置側の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると、ＨＴＴＰプロトコルに従い、リクエスト（ｒｅｑｕｅｓｔ（１））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認する。サーバ側の通信ソフトは、アプリケーションにイベント情報が存在しない場合には、イベント情報が発生していないと判断し、イベント情報が発生するまで待機する。そして、アプリケーションからイベント情報を受信すると、そのイベント情報をレスポンス（Ｒｅｓｐｏｎｓｅ（１））として端末装置に通知する。端末装置側の通信ソフトは、サーバからイベント情報を取得すると、それをアプリケーションに通知する。
【００５１】
以上によれば、サーバ２は、イベント情報が発生すると、即座にそのイベント情報を端末装置１通知することができるようになる。また、端末装置１は、１回のリクエストで、サーバ２側のイベント情報を取得することができるようになる。
【００５２】
［イベント情報通知処理の流れ（２）］
次に、サーバ側の待機時間が最大待機時間を超えた場合のイベント情報通知処理の流れについて、図５を用いて説明する。
【００５３】
端末装置側の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると、ＨＴＴＰプロトコルに従い、リクエスト（ｒｅｑｕｅｓｔ（１））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認し、アプリケーションにイベント情報が発生していない場合には、イベント情報が発生するまで待機する。しかし、イベント情報が発生する前に、イベント情報の発生を待機可能な最大待機時間が経過した場合には、イベント情報が発生していない旨を、レスポンス（Ｒｅｓｐｏｎｓｅ（１））として端末装置に通知する。
【００５４】
端末装置側の通信ソフトは、サーバからイベント情報が発生していない旨を取得すると、再度、リクエスト（ｒｅｑｕｅｓｔ（２））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認し、アプリケーションにイベント情報が発生していない場合には、イベント情報が発生するまで待機する。そして、アプリケーションからイベント情報を受信すると、そのイベント情報をレスポンス（Ｒｅｓｐｏｎｓｅ（２））として端末装置に通知する。端末装置側の通信ソフトは、サーバからイベント情報を取得すると、それをアプリケーションに通知する。
【００５５】
以上によれば、通信エラー等によるタイムアウトが端末装置側へ通知される前に、イベント情報が発生していない旨を端末装置１に通知しているので、端末装置１は、イベント情報が発生していないためにレスポンスが遅いのか、他の通信エラーなどによりレスポンスが遅いのかを、判断することができるようになる。
【００５６】
［端末装置側の処理］
次に、端末装置側の処理の流れについて、図６を用いて説明する。端末装置１の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると（Ｓ６０１）、イベント情報の取得を要求する要求メッセージに、通知条件を付加して、サーバ２に送信する（Ｓ６０２）。既述のように、通知条件とは、サーバ側に要求するイベント情報が発生していない場合には、イベント情報の発生を待って、発生したイベント情報を端末装置へ通知するという条件である。通知条件は、具体的には、要求メッセージに含まれる通知条件フラグをＯＮに設定することにより付加される。
【００５７】
そして、端末装置１の通信ソフトは、応答メッセージをサーバ２から受信すると、要求したイベント情報を取得したか否かを判断し（Ｓ６０４）、応答メッセージにイベント情報が含まれていると判断する場合は（Ｓ６０４；ＹＥＳ）、イベント情報をアプリケーションに通知する（Ｓ６０５）。一方、応答メッセージにイベント情報が含まれていないと判断する場合は（Ｓ６０４；ＮＯ）、Ｓ６０２に戻り、通知条件を付加した要求メッセージを、再度、サーバ２へ送信する。
【００５８】
［サーバ側の処理］
次に、サーバ側の処理の流れについて、図７を用いて説明する。サーバ２の通信ソフトは、イベント情報の取得要求メッセージを端末装置１から受信すると（Ｓ７０１）、最大待機時間（タイムアウト）の計測を開始するとともに（Ｓ７０２）、イベント情報の取得をアプリケーションに要求する（Ｓ７０３）。
【００５９】
サーバ２の通信ソフトは、アプリケーションからイベント情報を取得したか否かを判断し（Ｓ７０４）、イベント情報を取得したと判断する場合には（Ｓ７０４；ＹＥＳ）、応答メッセージにイベント情報を添付して、端末装置１へ送信する（Ｓ７０５）。これに対し、イベント情報を取得していない（イベント情報が発生していない）と判断する場合には（Ｓ７０４；Ｎｏ）、イベント情報を取得するまで待機するか否かを判断する（Ｓ７０６）。具体的には、要求メッセージに含まれる通知条件フラグがＯＮに設定されている場合には、イベント情報を取得するまで待機すると判断する。なお、通知条件フラグがＯＦＦの場合には（Ｓ７０６；ＮＯ）、待機する必要がないので、Ｓ７０８にて、イベント情報が発生していない旨の応答メッセージをただちに送信する。
【００６０】
イベント情報を取得するまで待機すると判断した場合には（Ｓ７０６；ＹＥＳ）、続いて、最大待機時間が経過していないか否かを判断し（Ｓ７０７）、経過していないと判断する場合には（Ｓ７０７；ＮＯ）、ステップＳ７０４に戻り、処理を続ける。一方、最大待機時間が経過していると判断する場合には（Ｓ７０７；ＹＥＳ）、イベント情報の待機を解除し、応答メッセージにイベント情報は発生していない旨をセットして、端末装置１へ送信する（Ｓ７０８）。
【００６１】
［第２の実施の形態］
第１の実施の形態では、サーバ側で通知すべき情報が発生していない場合には、通知すべき情報が発生するまで待機する場合について説明した。しかし、第２の実施の形態では、サーバ側で通知すべき情報が発生していない場合には、サーバは、応答メッセージを送信せず、端末装置は、所定の時間が経過しても、サーバから応答メッセージが通知されない場合には、「通知すべき情報が発生していない」という応答メッセージが送信されたとみなす。つまり、第２の実施の形態では、応答メッセージの不送信により、通知すべき情報が発生していない旨を、端末装置へ通知することを、特徴とする。
【００６２】
ここで、図２及び図３を用いて、第２の実施の形態に係る端末装置及びサーバの機能について説明する。第２の実施の形態では、端末装置１の通知条件付加手段１０２は、通知条件として、「通知すべき情報が発生していない場合には、応答メッセージを送信しない」という条件を設定する。また、リクエスト送信手段１０４は、リクエストを送信すると、その旨をレスポンス受信手段１０６に通知する。
【００６３】
レスポンス受信手段１０６は、リクエストを送信した旨を受け付けると、非通知時間の計測を開始する。非通知時間は、端末装置からの取得要求に対してサーバが応答メッセージを通知するのに要する平均的な時間や、通信のトラフィック状況などを考慮して設定、更新される。レスポンス受信手段１０６は、非通知時間の計測開始後、設定された非通知時間を経過しても、サーバ２から応答メッセージを受信していない場合には、イベント情報不存在による応答メッセージの非通知であると判断する。そして、この場合、イベント情報が発生していない旨の応答メッセージを受信したものとみなし、その旨を、アプリケーションに通知する。
【００６４】
一方、サーバ２のイベント情報取得手段２０２は、アプリケーション２２からイベント情報が発生していない旨を受け付けると、通知条件に従って、応答メッセージを送信しない旨を決定する。よって、レスポンス送信手段２０６からは、応答メッセージが送信されない。
【００６５】
［イベント情報非通知処理の流れ］
次に、サーバ側で通知すべき情報が発生していない場合には、応答メッセージを送信しないイベント情報非通知処理の流れについて、図８を用いて説明する。図８では、イベント情報が存在する場合の処理と、イベント情報が発生していない場合の処理を、それぞれ記載している。
【００６６】
まず、端末装置側の通信ソフトは、アプリケーションからイベント情報の取得指示を受け付けると、ＨＴＴＰプロトコルに従い、リクエスト（ｒｅｑｕｅｓｔ（１））をサーバに送信する。サーバ側の通信ソフトは、端末装置からのリクエストを受信すると、アプリケーションにイベント情報の有無を確認する。アプリケーションにイベント情報が存在する場合には、そのイベント情報をレスポンス（Ｒｅｓｐｏｎｓｅ（１））として端末装置に通知する。端末装置側の通信ソフトは、サーバからイベント情報を取得すると、それをアプリケーションに通知する。
【００６７】
また、端末装置１の通信ソフトは、リクエスト（ｒｅｑｕｅｓｔ（２））をサーバに送信すると、これに伴い、非通知時間の計測を開始する。リクエスト（ｒｅｑｕｅｓｔ（２））を受け付けたサーバ側で、アプリケーションにイベント情報が発生していない場合には、通知条件に従って、応答メッセージを送信しない旨を決定する。端末装置１の通信ソフトは、非通知時間の計測開始後、設定された非通知時間を経過してもサーバ２から応答メッセージを受信していない場合には、イベント情報不存在による応答メッセージの非通知であると判断する。そして、この場合、イベント情報が発生していない旨の応答メッセージを受信したものとみなし、その旨を、アプリケーションに通知する。
【００６８】
以上によれば、応答メッセージの非通知という構成により、イベント情報が発生していない旨を端末装置側へ通知することができるようになる。よって、イベント情報が発生していない旨の応答メッセージの送信が不要となり、データ通信量ひいては通信コストを軽減することができるようになる。
【００６９】
［その他の実施の形態］
上記実施形態は、本発明を説明するための例示であり、本発明を上記実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱しない限り、さまざまな形態で実施することができる。例えば、上記機能実現手段の動作をシーケンシャルに説明したが、特にこれにこだわるものではない。従って、動作に矛盾が生じない限り、処理の順序を入れ替えまたは並行動作するように構成しても良い。
【００７０】
【発明の効果】
本発明によれば、リクエスト／レスポンス型の通信手順に従って所定の情報を送受信する通信システムにおいて、データ通信量を削減することが可能になる。また、端末装置の動作とは非同期に発生する所定の情報を、リアルタイムで端末装置に通知することができるようになる。
【図面の簡単な説明】
【図１】本発明にかかる通信システムの全体構成を表す図である
【図２】端末装置（クライアント）１の機能を示す機能構成図である。
【図３】サーバ２の機能を示す機能構成図である。
【図４】イベント情報通知処理の流れ（１）を示すフローチャートである。
【図５】イベント情報通知処理の流れ（２）を示すフローチャートである。
【図６】端末装置側の処理の流れを示すフローチャートである。
【図７】サーバ側の処理の流れを示すフローチャートである。
【図８】イベント情報非通知処理の流れ示すフローチャートである。
【図９】ネットワークゲームの流れを説明するための図である。
【図１０】ＨＴＴＰプロトコルに基づいてサーバ側の情報を端末装置へ通知する従来の処理の流れを説明するための図である。
【符号の説明】
１…端末装置
２…サーバ
３…通信路
１０…通信ソフト
１２…アプリケーション
２０…通信ソフト
２２…アプリケーション
Claims (8)
- 端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバであって、
前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信する受信手段と、
前記受信された要求メッセージにて指定された所定の情報を取得する取得手段と、
前記取得された所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、
前記取得手段は、
前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機することを特徴とするサーバ。 - 前記取得手段は、
前記要求メッセージの受信後、所定の時間内に前記所定の情報を取得できない場合には、前記待機を中止し、
前記送信手段は、
前記所定の情報が発生していない旨の応答メッセージを送信することを特徴とする請求項１記載のサーバ。 - 前記所定の情報は、前記端末装置の動作とは非同期にサーバにより生成される情報及び前記端末装置の動作とは非同期に他の端末装置からサーバに送信される情報のうち、少なくともいずれか１つの情報を含むことを特徴とする請求項１または２記載のサーバ。
- 端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、前記端末装置の動作とは非同期に発生する所定の情報をサーバが端末装置へ通知する通知方法であって、
前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信し、該受信された要求メッセージにて指定された所定の情報が発生していない場合には、前記所定の情報が発生するまで待機し、前記所定の情報が発生したときに、この発生した所定の情報に基づく応答メッセージを前記端末装置へ送信することを特徴とする通知方法。 - 端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバに、
前記端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージを端末装置から受信するステップ、
前記受信された要求メッセージにて指定された所定の情報が発生していない場合には、前記所定の情報が発生するまで待機するステップ、
前記所定の情報が発生した場合に、この発生した所定の情報を取得するステップ、
前記取得された所定の情報に基づいて応答メッセージを生成するステップ、
前記生成された応答メッセージを前記端末装置へ送信するステップ、
を実行させるためのプログラム。 - 端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って、所定の情報を端末装置へ通知するサーバとの間で通信を行う端末装置であって、
前記端末装置の動作とは非同期に発生する所定の情報に対する取得要求と、前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機する旨の条件と、を含む要求メッセージを、前記サーバへ送信する送信手段、
を備えることを特徴とする端末装置。 - 端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って通信を行う通信システムであって、
前記端末装置は、
該端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージをサーバに送信する送信手段、を備え、
前記サーバは、
前記送信された要求メッセージを受信する受信手段と、
前記受信された要求メッセージにて指定された所定の情報を取得する取得手段と、
前記取得された所定の情報に基づく応答メッセージを端末装置へ送信する送信手段と、を備え、
前記取得手段は、
前記所定の情報が発生していない場合には、前記所定の情報が発生するまで待機し、前記所定の情報が発生したときに、該発生した所定の情報を取得することを特徴とする通信システム。 - 端末装置から送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型の通信手順に従って通信を行う通信システムにおける通信方法であって、
前記端末装置は、該端末装置の動作とは非同期に発生する所定の情報に対する要求メッセージをサーバに送信し、
前記サーバは、前記送信された要求メッセージを受信し、この受信した要求メッセージにて指定された所定の情報が発生していない場合には、前記送信された要求メッセージに対する応答メッセージの送信を中止し、
前記端末装置は、前記要求メッセージの送信後所定の時間が経過しても前記サーバから応答メッセージを受信していない場合には、前記サーバから前記要求メッセージにて指定した所定の情報が発生していない旨の応答メッセージを受信したものとみなす、ことを特徴とする通信システムにおける通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002277647A JP2004118325A (ja) | 2002-09-24 | 2002-09-24 | データ通信方法及びデータ通信システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002277647A JP2004118325A (ja) | 2002-09-24 | 2002-09-24 | データ通信方法及びデータ通信システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004118325A true JP2004118325A (ja) | 2004-04-15 |
Family
ID=32273189
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002277647A Pending JP2004118325A (ja) | 2002-09-24 | 2002-09-24 | データ通信方法及びデータ通信システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004118325A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007335960A (ja) * | 2006-06-12 | 2007-12-27 | Mitsubishi Electric Corp | 情報提供装置及び情報提供方法及びプログラム |
| WO2010140570A1 (ja) * | 2009-05-31 | 2010-12-09 | コミットメントテクノロジー株式会社 | 電子会議サーバおよびコンピュータプログラム |
| JP2011154651A (ja) * | 2010-01-28 | 2011-08-11 | Casio Computer Co Ltd | Ｈｔｔｐトンネルサーバ装置およびその制御プログラム |
| JP2012501481A (ja) * | 2008-08-29 | 2012-01-19 | マルチモーダル・テクノロジーズ・インク | 片方向通信を使用する分散型音声認識 |
-
2002
- 2002-09-24 JP JP2002277647A patent/JP2004118325A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007335960A (ja) * | 2006-06-12 | 2007-12-27 | Mitsubishi Electric Corp | 情報提供装置及び情報提供方法及びプログラム |
| JP2012501481A (ja) * | 2008-08-29 | 2012-01-19 | マルチモーダル・テクノロジーズ・インク | 片方向通信を使用する分散型音声認識 |
| WO2010140570A1 (ja) * | 2009-05-31 | 2010-12-09 | コミットメントテクノロジー株式会社 | 電子会議サーバおよびコンピュータプログラム |
| JP2011154651A (ja) * | 2010-01-28 | 2011-08-11 | Casio Computer Co Ltd | Ｈｔｔｐトンネルサーバ装置およびその制御プログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4668268B2 (ja) | ネットワーク参加者のステータス評価 | |
| CN100477614C (zh) | 用于选择数据提供者的系统和方法 | |
| JP2004129042A5 (ja) | ||
| RU2006144606A (ru) | Способ и устройство для роуминга в системе информации о местоположении | |
| CN111224999A (zh) | 一种传输协议切换方法、装置、设备及存储介质 | |
| US20160050267A1 (en) | Sign-In Method and Terminal | |
| JP2008015593A (ja) | 中継装置、プログラム、中継方法及び通信システム | |
| WO2008074244A1 (zh) | 一种即时通信的方法、系统及装置 | |
| JP2004118325A (ja) | データ通信方法及びデータ通信システム | |
| JP2004015336A (ja) | 緊急情報通知機能を備えたサーバ装置 | |
| AU2713701A (en) | System and method for inputting a web-page input data into web page by employing a wire/wireless telephone | |
| JP3507824B2 (ja) | データ伝送装置及びデータ伝送方法 | |
| JP4547210B2 (ja) | クライアント端末、サービス提供装置及びサービス発見方法 | |
| JP2007243814A (ja) | Ｉｐ電話システム | |
| JP3776848B2 (ja) | 管理サーバ及びプログラム | |
| CN111245874B (zh) | 信息推送方法、装置、服务器及存储介质 | |
| US9106608B2 (en) | Communication device, communication method, and non-transitory computer-readable recording medium | |
| CN103338115B (zh) | 信息处理系统、管理终端装置、信息处理装置 | |
| JP2002062159A (ja) | 測位履歴転送装置、測位履歴記録システム、測位履歴記録方法、及び測位履歴用プログラムを記録した記録媒体 | |
| JP3968060B2 (ja) | セッションメディア保留方法、保留装置、保留プログラム及び該プログラムを記録した記録媒体 | |
| JP4140728B2 (ja) | 管理サーバ及びプログラム | |
| JP2008113427A (ja) | ネットワーク・アクセス設備、ネットワーク接続を確立する方法及びこれらを使う移動通信システム | |
| JP3929903B2 (ja) | 呼接続システム、方法及び該方法を実行させるためのプログラム | |
| CN108769006A (zh) | 一种基于实时通讯库的协同办公系统及方法 | |
| JP4958225B2 (ja) | リクエスト受付方法およびシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050916 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070501 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070629 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070723 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071114 |