JP2000020423A - リアルタイム情報配信方法 - Google Patents

Abstract

(57)【要約】 【課題】サーバとクライアントとの間で直接通信ができ
なくも、サーバ側の情報が更新された際に即座にクライ
アントに通知可能とする。 【解決手段】サーバ１０は、クライアント１１からペー
ジ要求を受けると、要求されたページをクライアント１
１に返す。ここで、クライアント１１からの要求とそれ
に対するサーバ１０の応答には、同じコネクションＩＤ
（Ｃｏｎｎ１）が付される。クライアント１１はページ
の解析をし、その中にイベント要求が記述されていれば
当該要求を別のコネクションＩＤ（Ｃｏｎｎ２）を付し
てサーバ１０に送る。するとサーバ１０は、イベントが
発生する毎に、そのコネクションＩＤ（Ｃｏｎｎ２）を
用いクライアント１１にイベントを送信する。クライア
ント１１はこのイベントを処理し、表示中の画面に反映
させる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアントサー
バ方式のシステム、例えば情報提供サーバ及び情報表示
クライアントがネットワークを介して接続されるシステ
ムに係り、特にサーバ側での情報更新をクライアント側
に通知するのに好適なリアルタイム情報配信方法に関す
る。

【０００２】

【従来の技術】近年、ＷＷＷ（Ｗｏｒ１ｄ Ｗｉｄｅ
Ｗｅｂ）と呼ばれるシステムが社会システムとして浸透
し、様々な情報がＷＷＷを介して提供されている。ＷＷ
Ｗはサーバ（情報提供サーバ）とクライアント（情報表
示クライアント）から構成される、インターネットを利
用した分散型の情報提供／情報表示（情報閲覧）システ
ムである。一般に、サーバはページと呼ばれる文書単位
でクライアントヘ情報を提供する。このページはＨＴＭ
Ｌ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａ
ｇｅ）と呼ばれる形式のフォーマットで記述されている
ファイルである。クライアントは通常、ブラウザと呼ば
れる情報表示（情報閲覧）用のソフトウェアを用いて実
現されており、サーバにアクセスし、画像や音声などを
含む文書を表示することができる。

【０００３】ＷＷＷの一般的な使われ方は、ブラウザか
らサーバに表示したいページのアドレス（ＵＲＬと呼ば
れる）を要求し、サーバはそのアドレスに対応するペー
ジをクライアントに返すというものである。ここで注意
しなければならないのは、ブラウザから明示的な要求が
ない限り、サーバは何もしないということである。これ
は、サーバに蓄えてあるページが変更されても、ブラウ
ザからは変更を即座に知ることができないとことを意味
する。

【０００４】サーバにあるページが更新されたことをブ
ラウザ側でできるだけ早く知るためには、ブラウザは常
にサーバのページが更新されたかどうかを定期的にアク
セスする必要がある。例えば、ニュースや天気予報など
のようなサーバ側のページが時々刻々変更されるような
ページをブラウザで表示している場合、サーバ側でペー
ジが更新されてもブラウザの画面は変わらない。そこ
で、ユーザが明示的に、ブラウザ（の情報表示画面）に
付加されているリロードボタンなどを押すことで、サー
バに明示的に再アクセスしなければならない。

【０００５】このような問題を解決するために、ユーザ
の明示的なリロードを行わなくても、自動的に定期的に
サーバにアクセスし、常に最新の情報を表示するような
ブラウザが知られている。つまり、ブラウザが情報の更
折を、ユーザに代わって白動的に行うものである。代表
的な例として、Ｐｏｉｎｔ Ｃａｓｔ社のＰｏｉｎｔＣ
ａｓｔや、Ｍａｒｉｍｂａ社のＣａｓｔａｎｅｔ Ｔｕ
ｎｅｒなどが知られている。

【０００６】これらのブラウザでは、自動更新の時間間
隔などをユーザが指定できるとか、更新された場合でも
無駄なデータを転送しないように差分データだけをブラ
ウザが受け取るような工夫がされている。この種の自動
更新を行う機構は、しばしば、プッシュ機構と呼ばれ
る。その理由は、サーバで更新された情報がＴＶ（テレ
ビジョン）放送のように自動的にブラウザに送られてく
るような感覚をユーザに与えるからでる。しかし、実際
に更新するのは、ブラウザてあり、単にユーザが明示的
にリロードボタンを押す作業をブラウザ側で自動化して
いるに過ぎない。ここでのプッシュ機構は、次に説明す
る、より本来の意味に近いプッシュ機構との区別を強調
するため、スマートプル機構と呼ばれることもある。

【０００７】さて、サーバ側で更新された情報をブラウ
ザ側で自動的に更新するもう一つの手法について述べ
る。この手法は、情報提供サーバ（ＷＷＷサーバ）が提
供するＨＴＭＬファイルを拡張し、ＨＴＭＬファイル中
に次回の更新時刻などの情報を記述する手段を設けるこ
とである。この場合、このＨＴＭＬファイルを受け取っ
たブラウザは、そのＨＴＭＬファイル中に記述されてい
る更新時刻などの情報を利用し、その時刻になったら、
サーバに新しい情報の提供を要求することで、サーバヘ
の無駄なアクセスがなく、あたかもリアルタイムで情報
が更新されたかのような効果をブラウザ側で実現するこ
とができる。この種の自動更新機構はプッシュ機構と呼
ばれる。

【０００８】

【発明が解決しようとする課題】上記したスマートプル
機構及びプッシュ機構は、情報を更新する主体がブラウ
ザである点では類似している。スマートプル機構では、
サーバの情報が更新されたかどうかをブラウザ側から当
該サーバに確認するために、ブラウザが定期的にサーバ
に自動的にアクセスする。そのため、情報には何ら特別
な属性を必要としない半面、サーバの情報が実際には更
新されていない場合でも定期的なアクセスを繰り返さな
ければならず、無駄なアクセスが多いという問題点があ
る。

【０００９】一方、プッシュ機構では、情報の中の属性
として次回に更新する時刻などが記述されたファイル
（ＨＴＭＬファイル）を用いることから、サーバ側の情
報が更新されているかどうかを確認するための無駄なア
クセスを減らすことができる。しかし、このプッシュ機
構では、更新する時刻を予め知ることができるような情
報種類のものにしか有効ではない。即ちプッシュ機構で
は、非同期的に変更されるような情報の場合、クライア
ントが何時更新してよいか分からないので、問題の解決
とはならない。

【００１０】更に、スマートプル機構及びプッシュ機構
のどちらの場合でも、更新間隔が極めて短い提供情報、
例えば１秒間隔で更新されるような情報に対しては、非
常に効率が悪いという問題がある。その理由は次の通り
である。一般にサーバとクライアント間で通信を始める
際には、送りたいデータを送る前に、まず幾つかの交信
のやりとり（ネゴシエーション）を行う必要がある。上
記の例では、このネゴシエーションを、１秒間隔で行わ
なければならない。つまり、提供情報の更新の時間間隔
が短い場合、情報本文を送るコストに比べ、このネゴシ
エーションのコストの比重が高くなり非常に効率が悪く
なる。

【００１１】一方、サーバからクライアントのブラウザ
に更新情報を直接送ることができるならば、上記問題は
解決可能となる。しかし、この方式は現状のＷＷＷのフ
レームワークに照らし合わせると現実的な解決ではな
い。その理由は次の通りである。

【００１２】まず、現状のＷＷＷでは、サーバとクライ
アント間に複数の中継サーバが存在することがある。中
継サーバの中には、ファイアーウォールと呼ばれる、情
報を一方向のみ転送するものがある。このファイアーウ
ォールは、特に企業などにおいて、外部からのシステム
（企業内システム）への進入を防ぐために一般的に用い
られている。

【００１３】中魅サーバを介した場合、クライアントと
直接通信するのは、クライアントに最も近い中継サーバ
であり、サーバと直接通信できるのは、サーバに最も近
い中継サーバである。したがって、サーバから見た場
合、直接のクライアントはその中継サーバてあり、ユー
ザが用いているブラウザはサーバから感知できない。し
たがって、サーバからブラウザに直接更新通知を送るこ
とはできない。しかも、途中にある中継サーバは不特定
多数のクライアントあるいはサーバからアクセスされる
ため、信頼性や安定性に問題がある。

【００１４】また、サーバからクライアントの動作を直
接知ることができないため、クライアントが現在どのペ
ージを表示しているかをサーバ側では感知することがで
きないという問題もある。このことは、あるブラウザが
ある特定のページを表示している間は、他のブラウザが
同じページを表示できなくするなどの排他制御ができな
い、もしくは非常に困難であることを意味する。そのた
め、利用可能なアプリケーションの種類が限られてしま
うという問題点がある。特に、制御機器をブラウザから
制御する場合などのように、一つのクライアントが独占
的（排他的）にサーバにアクセスし、機器を操作すると
いったアプリケーションの実装が困難である。

【００１５】本発明は上記事情を考慮してなされたもの
でその目的は、情報提供サーバとそのサーバに情報提供
を要求する情報表示クライアントとの間で直接通信する
ことができない状況において、サーバ側の情報が更新さ
れた場合に、即座にクライアントに通知することができ
るリアルタイム情報配信方法を提供することにある。本
発明の他の目的は、サーバ側での情報更新の時間間隔が
極めて短い場合や、予め更新の時刻が分からないような
非同期的な情報更新の場合でも、クライアント側の画面
にサーバ側での情報更新を効率良く反映させ、しかもサ
ーバとクライアントとの間の通信の信頼性及び安定性を
高めることができるリアルタイム情報配信方法を提供す
ることにある。

【００１６】本発明の更に他の目的は、複数のクライア
ントがある特定のページを同時に表示できないように排
他制御することができるリアルタイム情報配信方法を提
供することにある。

【００１７】

【課題を解決するための手段】本発明は、情報表示クラ
イアントからのページ要求により要求されたページ情報
を情報提供サーバから上記クライアントにネットワーク
を介して送信するリアルタイム情報配信方法であって、
クライアントからサーバに情報提供の要求が送られた場
合、当該要求が新規のページ情報を要求するページ要求
であるか、あるいは現在開かれているページ情報の更新
情報を要求するイベント要求であるかを当該サーバにて
判別し、ページ要求の場合には、要求されたページ情報
を１回だけ当該サーバからページ要求元のクライアント
に送信し、イベント要求の場合には、対応するページ情
報の更新に相当するイベントが発生する毎に、当該ペー
ジ情報の更新内容を反映させるためのイベント通知を上
記サーバからイベント要求元のクライアントに送信する
ことを特徴とする。

【００１８】このような構成においては、従来から知ら
れている「ページ要求」の他に、現在開かれているペー
ジ情報の更新情報を要求する「イベント要求」という新
たな概念を導入し、サーバとクライアントを接続したま
まの状態で、クライアントからの１回のイベント要求に
対し、サーバからイベント発生に応じて継続的にイベン
ト通知をクライアントに送信することにより、サーバ側
でページ情報の更新が発生する毎に、その更新内容を自
動的にクライアント側に反映させることができ、しかも
サーバとクライアントとの間の通信の負荷を軽減するこ
とが可能となる。特に、イベントの発生頻度が１秒間隔
またはそれより短い程度のものに対して効率がよく、リ
アルタイム性が期待できる。更に、サーバはクライアン
トからの要求（イベント要求）に応じて継続的なイベン
ト通知を行うため、既存のＷＷＷプロトコルのみを用い
て実現できる。

【００１９】これに対して従来のＷＷＷ上のプッシュ技
術は、サーバで提供するページ情報の中に次にそのペー
ジ情報が更新される時刻などを記述することで、クライ
アント（ブラウザ）側でその時刻になったらサーバにア
クセスするというものであった。この技術では、時系列
データなどのような１秒程度の短い間隔で更新されるデ
ータについては、ネットワークの接続／切断が頻繁に発
生するため問題であった。

【００２０】また本発明は、クライアントからのページ
要求に対してサーバから送信するページ情報中に、当該
ページ情報を受け取ったクライアントから上記のイベン
ト要求を発行させるための、つまりサーバでのイベント
通知を起動させるための少なくとも１つのイベント要求
情報を設定するようにしたことを特徴とする。

【００２１】このような構成においては、要求したペー
ジ情報をサーバから受け取ったクライアント側では、当
該ページ情報中に設定されているイベント要求情報に従
って自動的にイベント要求を当該サーバに発行してイベ
ント通知を起動することができる。つまり、ページ情報
とイベントを関連付けることにより、クライアント側で
開かれているページ情報をサーバから送られてくるイベ
ント通知に応じて動的に変化させることができる。

【００２２】さて、クライアントが正常にイベント通知
を受け取っているか否かをサーバから知るためには、実
際にイベント通知を送る必要がある。しかし、サーバに
おいてイベントが発生するまでは、そのことがわからな
いため、たとえクライアントでのページ処理が終了して
いても、サーバ側ではネットワーク接続のための負荷が
かかっている。

【００２３】そこで本発明は、サーバでのイベント発生
毎に当該サーバからイベント要求元のクライアントにイ
ベント通知を送信する必要がある状況において、ある一
定時間イベントが発生しなかった場合には、イベント要
求元のクライアントの状態確認のための特別のイベント
通知（クライアント状態確認イベント通知）をサーバか
らクライアントに送るようにすると共に、サーバからの
（クライアント状態確認イベント通知を含む）イベント
通知時には、そのイベント通知に成功したか否かを当該
サーバにて確認し、イベント通知に失敗した場合には、
イベント通知に用いているネットワーク接続を当該サー
バ側で切断するようにしたことを特徴とする。

【００２４】このような構成においては、ある一定時間
以上イベントが発生しない場合には、定期的にイベント
要求元のクライアントの状態確認のための特別のイベン
ト通知を明示的に発生して当該クライアントに送信する
ことにより、当該クライアントの状態を知ることができ
る。そこで、クライアントでのページ処理が終了してい
たり、ネットワークが切れているといった要因でイベン
ト通知（の送信）に失敗した場合には、サーバ側でネッ
トワーク接続を切断することにより、無駄な負荷を削減
することができる。

【００２５】イベント通知に対するクライアント側の処
理として、イベント通知を受け取ったなら、その内容に
より画面に即座に反映させるという応用が考えられる。
そのためには、クライアント側で開かれているページ情
報が切り替えられる際には工夫が必要となる。

【００２６】そこで本発明は、クライアントからのペー
ジ要求に対してサーバから送信するイベント要求情報付
きのページ情報中に、当該クライアントにより実行させ
る所定の手続きを設定し、当該ページ情報を受け取った
クライアントにおいて、当該ページ情報の表示から他の
ページ要求に対応したページ情報の表示に切り替える際
に、つまり別のページに移動する際には、当該イベント
要求に対するサーバからのイベント通知に関係するネッ
トワーク接続を上記所定の手続きに従ってクライアント
により切断させるようにしたことを特徴とする。

【００２７】このような構成においては、クライアント
が別のページに移動したら、そのページの更新を反映さ
せるためのイベント通知を受け取るネットワーク（コネ
クション）がクライアント側で切断されるため、無駄な
通信を排除することができる。しかもクライアント側で
は、その処理のための特別な仕組みを必要としない。ま
た本発明は、クライアントからのページ要求に対してサ
ーバから送信するイベント要求情報付きのページ情報中
に、対応するイベントの発生が定期的であるか不定期的
であるかを示す情報、定期的である場合にはその時間間
隔の情報、及び当該クライアントにより実行させる所定
の手続きを設定し、当該ページ情報を受け取ったクライ
アントにより上記所定の手続きに従って、対応するイベ
ントの発生が定期的で、且つその時間間隔が定められた
間隔以上の場合に、イベント要求に対してサーバから送
られるイベント通知を受け取る毎にネットワーク接続を
一時的に切断し、上記時間間隔で決まるイベント発生予
定時期の到来を待って再びイベント要求を発行する動作
を実行させるようにしたことを特徴とする。

【００２８】このような構成においては、イベント発生
が定期的で、且つ、その間隔が長い場合には、クライア
ント側にて一旦ネットワーク接続が切断され、イベント
が発生する予定の時刻に近づいたならば再びネットワー
ク接続がなされてイベント要求が発行されるため、無駄
なネットワークの負荷、及びサーバとクライアントのＣ
ＰＵの負荷を削減できる。しかもクライアント側では、
その処理のための特別な仕組みを必要としない。

【００２９】また本発明は、クライアントからのページ
要求に対してサーバから送信するイベント要求情報付き
のページ情報、またはクライアントからのイベント要求
に応じてサーバから送信するイベント通知の中に、当該
クライアントにより実行させる所定の手続きを設定する
と共に、上記イベント通知の中に、次に同じイベントが
発生する時刻情報を設定し、上記イベント通知を受け取
ったクライアントにより、上記所定の手続きに従って次
のイベント通知の到来を監視させ、上記受け取ったイベ
ント通知中の時刻情報の示す予定時刻にサーバから次の
イベント通知を受け取ることができなかった場合には、
当該クライアントからサーバにイベント要求を発行させ
るようにしたことを特徴とする。

【００３０】このような構成においては、次にイベント
が発生する時刻が予測できる場合には、その時刻になっ
てもサーバからイベントが送られてこないならば、ネッ
トワークが一時的に切断された可能性があるとして、ク
ライアントから再びイベント要求が発行されるため、ネ
ットワーク接続を再開することができ、信頼性を高める
ことが可能となる。つまりイベント通知に用いるコネク
ションは、接続した状態を保ったままにしておくが、コ
ネクションが外的要因によリ切断されたら、クライアン
トから自動的に再接続することにより、不安定なネット
ワークであってもある程度の信頼性が期待できる。しか
もクライアント側では、その処理のための特別な仕組み
を必要としない。

【００３１】また本発明は、クライアントからのページ
要求に対してサーバから送信するイベント要求情報付き
のページ情報の中に、クライアントから発行されるイベ
ント要求に次回イベント要求を発行する時刻情報を付加
させる手続きを設定し、上記ページ情報を受け取ったク
ライアントからサーバに対して時刻情報付きのイベント
要求が発行された場合には、当該サーバにおいて次のイ
ベント要求の到来を監視し、先行するイベント要求中の
時刻情報の示す予定時刻に次のイベント要求を受け取る
ことができなかった場合には、当該イベント要求に関係
するネットワーク接続を切断することを特徴とする。

【００３２】このような構成においては、クライアント
からのイベント要求の発行予定時刻をサーバ側で知るこ
とができるため、その予定時刻になってもイベント要求
がなければ、サーバ側ではクライアントが正しく機能し
ていない（終了しているか、ネットワークが切断されて
いる）と判断し、ネットワーク接続を切断することによ
り、サーバの無駄なＣＰＵ負荷を削減することができ
る。しかもクライアント側では、次回のイベント要求の
発行予定時刻をサーバに通知するための特別な仕組みを
必要としない。

【００３３】また本発明は、サーバ中に、複数のクライ
アントで同時に表示することが禁止される排他ページの
情報を登録しておき、サーバがクライアントからページ
要求を受け取った場合には、上記排他ページの登録情報
から、要求されたページ情報が排他ページであるか否か
を調べ、排他ページの場合には、当該ページが他のクラ
イアントで表示中であるか否かを調べ、他のクライアン
トで表示中でない場合には、要求されたページ情報の中
にイベント要求情報が設定された新たなページ情報をペ
ージ要求元のクライアントに送信し、他のクライアント
で表示中の場合には、要求されたページ情報に代えて、
特定のイベント要求を行わせるための特定イベント要求
情報が設定された特定ページ情報をページ要求元のクラ
イアントに送信して、当該クライアントでの要求された
ページ情報の表示を待たせ、排他ページの表示状態にあ
ったクライアントに対するサーバからのイベント通知に
関係するネットワーク接続が切断され、且つ排他ページ
の表示の待ち状態にあるクライアントが存在する場合に
は、その待ち状態にあるいずれか１つのクライアント
に、要求されたページ情報の中にイベント要求情報が設
定された新たなページ情報を上記特定イベント要求に対
する応答として送信することを特徴とする。

【００３４】このような構成においては、ページ情報中
に埋め込まれたイベント要求情報に従うクライアントか
らのイベント要求発行を利用することで、従来のＷＷＷ
では実現が困難であった複数のクライアントが同じペー
ジを同時に表示することができないような機構（ページ
のロック機構）を容易に実現でき、しかも排他ページを
表示しているクライアントでのページ処理が終了したり
した場合には、そのページを表示できないでいた他のク
ライアントにその旨を通知することにより、自動的に本
来要求したページに切り替えることができ、ユーザイン
タフェースの向上が図れる。

【００３５】また本発明は、要求したページが排他ペー
ジで、しかも別のクライアントで表示中のために、特別
のページが送られた待ち状態にあるクライアントからサ
ーバに対してページ要求またはイベント要求が送られた
場合、サーバにおける当該要求に対する処理を通常状態
から変更するようにしたことを特徴とする。

【００３６】このように、ロックされたページの待ち状
態にあるクライアントからサーバへの要求が発生した場
合に、その要求に対する処理を通常とは変え、例えば無
視することで、当該クライアント自身を仮想的にロック
することが可能となる。これは、制御機器などをクライ
アントから制御する場合に、他のクライアントに制御を
渡さないようにすることができ、信頼性の向上が図れ
る。

【００３７】

【発明の実施の形態】以下、本発明の実施の形態につき
図面を参照して説明する。

【００３８】［第１の実施形態］図１は本発明の第１の
実施形態に係るリアルタイム情報配信システムの構成を
示すブロック図である。

【００３９】同図において、情報提供サーバ（情報提供
サーバ計算機）１０は、ＷＷＷ（Ｗｏｒ１ｄ Ｗｉｄｅ
Ｗｅｂ）サーバとして機能し、インターネットなどの
ネットワーク１２に接続されている。情報表示クライア
ント（情報表示クライアント計算機）１１は、情報提供
サーバ１０にリクエストを発行し、結果を表示するブラ
ウザ（情報表示ソフトウェア）を有する。このブラウザ
は、Ｎｅｔｓｃａｐｅ社のＮｅｔｓｃａｐｅ Ｃｏｍｍ
ｉｎｉｃａｔｏｒやＭｉｃｒｏｓｏｆｔ社のＩｎｔｅｒ
ｎｅｔ Ｅｘｐ１ｏｒｅｒなどの汎用のブラウザでよ
い。

【００４０】また、図には示されていないが、情報提供
サーバ１０と情報表示クライアント１１の間には代理サ
ーバ（ｐｒｏｘｙサーバ）と呼ばれる中継サーバが存在
してもよい。代理サーバは、クライアントからリクエス
トを受け取り、そのリクエストをそのままサーバに送
り、サーバから送られてきた結果をそのままクライアン
トに返すものである。また、このような代理サーバは情
報提供サーバ１０と情報表示クライアント１１との間に
複数存在してもよい。以下、曖昧性がない場合、情報提
供サーバを単にサーバと呼び、情報表示クライアントを
単にクライアントと呼ぶ。また、クライアントを、ブラ
ウザと呼ぶこともある。

【００４１】なお、図では作図の都合上、ネットワーク
１２に接続されているクライアント１１が１台の場合を
示してあるが、複数のクライアント１１が接続されるの
が一般的である。またサーバ１０についても、１台に限
らないことは勿論である。

【００４２】図１のシステムは、クライアント１１から
制御される制御機器（図示せず）が、サーバ１０により
監視可能なように当該サーバ１０に接続されてている場
合を想定している。

【００４３】ここで、サーバ（情報提供サーバ）１０の
構成について説明する。

【００４４】ネットワークインタフェース１０１は、ネ
ットワーク１２からのデータを受信し、またネットワー
ク１２にデータを送信する機能を持つ。またネットワー
クインタフェース１０１は、受信したデータの種類を識
別し、その種類に適合したサーバ１０内装置に当該デー
タを渡す機能を持つ。

【００４５】ページ要求受信装置１０２は、ネットワー
クインタフェース１０１を介してクライアント１１から
送られるページ要求を受理し、解析し、当該クライアン
ト１１に送るべきページをページ送信装置１０３に伝え
る。ページ要求には、ＷＷＷで一般に用いられるＵＲＬ
（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏ
ｒ）と呼ばれる形式が適用されるものとする。

【００４６】ページ送信装置１０３は、サーバ１０内に
蓄えてあるＨＴＭＬファイル１００をネットワークイン
タフェース１０１を介してネットワーク１２に送信す
る。送信の対象となる情報としては、ＨＴＭＬファイル
（１００）に限らず、画像や音声などの任意の情報であ
ってもよい。

【００４７】イベント要求受信装置１０４は、ネットワ
ークインタフェース１０１を介してクライアント１１か
ら送られるイベント要求を受理し、解析し、コネクショ
ン管理装置１０５と通信してイベント要求を処理すべき
かどうか判断する。そしてイベント要求受信装置１０４
は、必要ならイベント送信装置１０６に対して、当該イ
ベント送信装置１０６からクライアント１１にイベント
を送るように指示する。

【００４８】イベント発生装置１０７は、非同期的ある
いは、不定期的にイベントを発生する。ここではイベン
トの種類は問わないが、イベントの例を挙げる。例え
ば、制御機器に流れている電流の値が一定値以上変化し
たとか、このサーバ１０にアクセスしているクライアン
ト１１の数が特定の数になったとか、予め指定した時刻
になったなどがイベントである。イベント発生装置１０
７で発生されたイベントは直接イベント送信装置１０６
に送られる。この他に、イベント発生監視装置１０８で
イベント発生要因を監視し、その結果発生するイベント
としてイベント送信装置１０６に送られる構成も適用さ
れる。このように本実施形態では、イベント送信装置１
０６へイベントを送るのに２種の方法が適用されるが、
いずれか一方を適用する構成であっても構わない。

【００４９】イベント発生監視装置１０８は、イベント
発生装置１０７では明示的には発生しないようなイベン
トを監視する。つまりイベント発生監視装置１０８は、
例えば、制御機器に流れる電流が１００Ａ以下になった
ときにイベントとしてクライアント１１に通知したいに
も拘わらずに、イベント発生装置１０でそのようなイベ
ントが定義されていない場合には、定期的に電流を監視
し、１００Ａ以下になったらイベントとしてイベント送
信装置１０６に通知するといった機能を持つ。この他
に、イベント発生装置１０７で発生したある特定のイベ
ントの発生回数が予め定められた回数となったことをも
って、クライアント１１に通知するなどといった種類の
イベントもイベント発生監視装置１０８で生成される。

【００５０】イベント送信装置１０６は、イベント発生
装置１０７またはイベント発生監視装置１０８から送ら
れるイベントをネットワークインタフェース１０１を介
してクライアント１１に送信する。また、同じイベント
を複数のクライアント１１が要求している場合もあり、
そのときはイベント送信装置１０６は、それぞれのクラ
イアント１１に同じイベントを送る。

【００５１】コネクション管理装置１０５は、イベント
の種類とそのイベントをどのクライアント１１が要求し
ているかの情報を管理する。イベント送信装置１０６は
この情報を参照しながら、イベントが発生したらそのイ
ベントを要求している全てのクライアント１１に、その
同じイベントを送る。イベントは、ページ送信装置１０
３が送るページと異なって一過性のものであり、また、
そのイベントを要求しているクライアント１１の数に拘
わらずに同じイベントをクライアント１１の数だけ複製
して送らなければならないことに注意されたい。

【００５２】次に、クライアント（情報表示クライアン
ト）１１の構成について説明する。ネットワークインタ
フェース１０９は、ネットワーク１２に接続されている
サーバ１０にページ要求、あるいはイベント要求を発行
するため、クライアント１１のリクエストをネットワー
ク１２に送出し、またサーバ１０からの応答を受け取
る。またネットワークインタフェース１０９は、サーバ
１０からの応答を、その種類に応じ、ページ受信装置１
１２あるいはイベント受信装置１１４に転送する。

【００５３】入出力装置１１０は、キーボード、ディス
プレイ及びマウスなどから構成される。ページ要求のＵ
ＲＬは、入出力装置１１０を用いた操作、例えば入出力
装置１１０内の例えばキーボードから直接入力すること
で、あるいはページ中にあるリンクをマウスでクリック
することで、ページ要求装置１１１に伝えられる。

【００５４】ページ要求装置１１１は、入出力装置１１
０から入力されたページのアドレス（ＵＲＬ）を受け取
り、ネットワークインタフェース１０９を介してサーバ
１０に要求する。

【００５５】ページ受信装置１１２は、要求したページ
に対し、サーバ１０からの応答をネネットワークインタ
フェース１０９を介して受信する。受信したページは、
入出力装置１１０のディスプレイに表示される。サーバ
１０から受信したページの中にはサーバ１０へのイベン
ト要求をするための記述が含まれている場合がある。そ
のときには、ページ受信装置１１２からイベント要求装
置１１３にイベント要求のＵＲＬが伝えられる。

【００５６】イベント要求装置１１３は、指定されたＵ
ＲＬをネットワークインタフェース１０９を介してサー
バ１０に送る。なお、図には示していないが、イベント
要求のＵＲＬはページ受信装置１１２から与えられるだ
けでなく、入出力装置１１０からユーザにより直接与え
られてもよい。

【００５７】イベント受信装置１１４は、イベント要求
装置１１３がサーバ１０に要求することにより当該サー
バ１０から送られるイベントを受け取る。受け取ったイ
ベントは、必要に応じ入出力装置１１０に伝えられ表示
画面にその旨を反映させることができる。

【００５８】本実施形態において、クライアント１１の
ページ要求に対してサーバ１０から送られるページの形
式は、通常のＨＴＭＬファイル形式である。勿論、それ
以外の形式であっても構わない。

【００５９】図２にＨＴＭＬファイル形式の例を示す。
この例ではページの中にサーバヘのイベント要求が含ま
れている例を示した。イベント要求はＥＭＢＥＤという
タグの中のＥＶＥＮＴというタグのＵＲＬという属性で
示される。この表現はこれに限るものではない。例え
ば、イベント要求がＨＴＭＬファイル中には明示的に記
述されてなく、他のページへのリンクとして表現され、
そのページの中でイベント要求が記述されている場合で
も、もとのＨＴＭＬファイルからイベント要求がサーバ
に送られるという方法も適用可能である。また、別の方
法としては、ページ中に埋め込まれた何らかのプログラ
ム（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社が開発したＪ
ａｖａのＡｐｐｌｅｔや、Ｎｅｔｓｃａｐｅ社が開発し
たＪａｖａＳｃｒｉｐｔなど）から動的にイベント要求
が発生する手法を適用することも可能である。

【００６０】次に、図１のシステムのクライアント１１
における、当該クライアント１１からサーバ１０へのペ
ージ要求とそれに付随するイベント要求の処理の流れに
ついて、図３のフローチャートを参照して説明する。

【００６１】まずクライアント１１において、入出力装
置１１０からページ要求（ＵＲＬ）が発生すると（ステ
ップＡ１）、現在表示しているページにイベント要求が
含まれていれば、ネットワークインタフェース１０９は
そのイベント要求に対するサーバ１０からのイベント通
知に関係するネットワーク接続を切断する（ステップＡ
２）。この操作は、クライアント１１側で別のページ要
求が発生したとき、つまりページを切り替えようとする
際に、イベント要求が含まれている表示中のページに関
するイベント受信のネットワーク接続を当該クライアン
ト１１（内のネットワークインタフェース１０９）によ
り切断させる手続きを、当該ページ中に予め記述してお
くことで実現される。この手続きには、Ｓｕｎ Ｍｉｃ
ｒｏｓｙｓｔｅｍｓ社のＪａｖａ（Ａｐｐｌｅｔ）や、
Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社の
ＪａｖａＳｃｒｉｐｔなどが適用可能である。

【００６２】ページ要求装置１１１は適切なサーバ１０
に対してページを要求する（ステップＡ３）。ページ受
信装置１１２はサーバ１０からの応答を読む準備をし
（ステップＡ４）、当該サーバ１０からページが送られ
てくるまで待機する（ステップＡ５）。ページ受信装置
１１２はサーバ１０からページが送られてきたら当該ペ
ージの内容を解析し（ステップＡ６）、イベント要求が
そのページに含まれているかどうか判断する（ステップ
Ａ７）。

【００６３】もし、イベント要求が含まれていない場合
には、ページ受信装置１１２はそのページを入出力装置
１１０に出力する（ステップＡ１２）。これにより受信
したページの内容が入出力装置１１０のディスプレイに
表示される。

【００６４】一方、イベント要求が含まれていた場合に
は、ページ受信装置１１２はイベント要求装置１１３に
イベントのＵＲＬを伝え、イベント要求装置１１３によ
りサーバ１０にイベント要求を送らせる（ステップＡ
８）。この場合、ページ受信装置１１２はサーバ１０か
らの応答（イベント）を読む準備をし（ステップＡ
９）、当該サーバ１０からイベントが送られてきたかど
うかチェックする（ステップＡ１０）。そしてページ受
信装置１１２は、イベントが送られてない場合にはその
まま待機し、イベントが送られてきたらそのイベントを
処理する（ステップＡ１１）。イベントの処理の結果に
よっては、後述するように入出力装置１１０の表示画面
が更新されることもある。

【００６５】なお、図３のフローチャート中で一点鎖線
で囲まれた処理部分（ステップＡ８〜Ａ１１）はステッ
プＡ１２と並行して処理することができる。つまり、ス
テップＡ１２で画面にページを表示している最中でもイ
ベントの読み込みや処理を行うことができる。また、ペ
ージの中に複数のイベント要求が記述されている場合に
も、複数のイベント処理を同時に進めることができる。

【００６６】以上のクライアント１１側の処理で特徴的
な点は、ページ要求に対する応答は１回であるのに対
し、イベント要求に対する応答とその処理は限りがない
ということである。イベントの処理を終了させるために
は、図には示していないが、外部からの指示が必要であ
る。

【００６７】次にサーバ１０側の処理の流れについて、
図４及び図５のフローチャートを参照して説明する。

【００６８】まずサーバ１０内のネットワークインタフ
ェース１０１は、クライアント１１からの要求を受信す
る状態で常に待機している（ステップＢ１）。ネットワ
ークインタフェース１０１はクライアント１１からの要
求を受信するとそれがページ要求かイベント要求かを判
断し（ステップＢ２，Ｂ３）、ページ要求であればペー
ジ要求受信装置１０２に渡す。するとページ要求受信装
置１０２は、ページ要求の内容を解析してページ送信装
置１０３に伝える（ステップＢ４）。

【００６９】ページ送信装置１０３は目的のページに相
当するＨＴＭＬファイル１００が（図示せぬファイル蓄
積装置に）あるかどうか調べる（ステップＢ５）。も
し、該当するＨＴＭＬファイル１００があるならば、ペ
ージ送信装置１０３はそのファイル１００を要求元のク
ライアント１１に返し（ステップＢ６）、なければエラ
ーメッセージを当該クライアント１１に返す（ステップ
Ｂ７）。ここで、ページのファイルとしてＨＴＭＬファ
イルを例にしているが、これに限るものではない。

【００７０】一方、クライアント１１からの要求がイベ
ント要求の場合には、ネットワークインタフェース１０
１は、そのイベント要求をイベント要求受信装置１０４
に渡す。するとイベント要求受信装置１０４は、コネク
ション管理装置１０５に対し、イベント要求により要求
されたイベントの識別子（イベントＩＤ）と要求元のク
ライアント１１の識別子（クライアントＩＤ）との対が
既に登録されているかどうか問い合わせる（ステップＢ
８，Ｂ９）。既に登録されている場合には、イベント要
求受信装置１０４はネットワークインタフェース１０１
によりクライアント１１との接続を切らせる（ステップ
Ｂ１０）。これに対して登録されていない場合には、コ
ネクション管理装置１０５にそれを登録させる（ステッ
プＢ１１）。このステップＢ１０，Ｂ１１の処理は、後
の説明で明らかになるように、コネクション管理装置１
０５に登録されているイベントとそのクライアント１１
はその時点で既に通信（コネクション）が張られている
ことを意味し、同じクライアント１１へ２重にイベント
を送信しないためのものである。

【００７１】次に、イベント発生装置１０７またはイベ
ント発生監視装置１０８においてイベントが発生したか
どうかが調べられる（ステップＢ１２）。イベントが発
生していない場合、イベント送信装置１０６において、
前回最後にイベントを送った時刻から、予め定められた
一定時間が経過したかどうかが調べられる（ステップＢ
１３）。もし、経過していたら、イベント送信装置１０
６は、イベント要求元のクライアント１１の状態等を確
認するために、システムイベントと呼ぶ特別なイベント
をイベント要求元のクライアント１１に送る（ステップ
Ｂ１４）。これに対し、まだ時間が経過していなけれ
ば、イベント発生装置１０７またはイベント発生監視装
置１０８においてイベントが発生したかどうかが再び調
べられる（ステップＢ１２）。

【００７２】一方、イベント発生装置１０７またはイベ
ント発生監視装置１０８でイベントが発生したならば、
イベント送信装置１０６に対し、そのイベントをクライ
アント１１に送るように伝えられる（ステップＢ１
５）。これによりイベント送信装置１０６は、ネットワ
ークインタフェース１０１を介してイベント要求元のク
ライアント１１にそのイベントを送る（ステップＢ１
６）。

【００７３】ネットワークインタフェース１０１は、ク
ライアント１１にイベントを送ると、そのイベントが正
しく送られたかどうかを、当該クライアント１１からの
応答により調べる（ステップＢ１７）。もし、正しく送
られたなら、再びイベントが発生するまで待機状態とな
る。これに対し、イベントが正しく送られなかったな
ら、ネットワークインタフェース１０１によりクライア
ント１１との接続が切断され、イベント送信装置１０６
によりコネクション管理装置１０５から対応する項目が
削除される（ステップＢ１８）。

【００７４】以上のサーバ１０側の処理で特徴的な点
は、クライアント１１からのイベント要求が１度だけあ
ると、常時イベントが発生する度に当該クライアント１
１にイベントを送り続けるという流れになっていること
である。これは、ページ要求のように、１回の要求に対
１つのページを送るという方式と異なる。クライアント
１１とイベント要求元のクライアント１１との間では接
続が常時保たれたままであり、イベントが正しく送られ
なかったらその接続を切る。また、イベントが、予め定
められた一定時間の間に発生しない場合には、システム
イベントを定期的にイベント要求元クライアント１１に
送り、当該クライアント１１がイベントを受信できてい
るかどうかをチェックする。これは、ネットワーク１２
の回線が途中で切断されるとか、クライアント１１が自
ら接続を切断したという状況を検出し、そのときには、
サーバ１０側のイベント検出／送信ループを中止するよ
うにするためである。

【００７５】次に図１のシステムにおける、サーバ１０
とクライアント１１の両者を含めた動作について説明す
る。

【００７６】図６はサーバ１０とクライアント１１との
間の通信の過程の一例を時間軸と共に示したものであ
る。

【００７７】まず、クライアント１１からサーバ１０に
ページ要求が発生すると、サーバ１０は要求された目的
のページをクライアント１１に返す。ここで、クライア
ント１１からの要求とそれに対するサーバ１０の応答
は、両者が対応付けられるように同じＩＤ（図ではＣｏ
ｎｎ１）を付けるものとする。

【００７８】次に、クライアント１１はページの解析を
し、その中に記述されているイベント要求がもしあれば
サーバ１０に送る。このとき別のコネクションＩＤ（Ｃ
ｏｎｎ２）が用いられる。サーバ１０はイベントが発生
すると、そのコネクションＩＤを用いクライアント１１
にイベントを送信する。以降イベントが発生する度にこ
れを繰り返す。

【００７９】一方、クライアント１１が、別のページ要
求（Ｃｏｎｎ３）をした場合には、同時にＣｏｎｎ２の
接続を切断する。すると、サーバ１０側でＣｏｎｎ２に
送るべきイベントが発生したときにエラーが検出され、
コネクション管理装置１０５から対応する項目を削除す
る。クライアント１１からの新たなページ要求に対して
は、該当するページをサーバ１０から当該クライアント
１１に送る。以下、同様の通信が線り返される。

【００８０】クライアント１１側で、別のページ要求が
発生したとき、サーバ１０からのイベント受信の接続を
切断することの効果は次の通りである。即ち、サーバ１
０からのイベントを受信した際に、クライアント１１側
でのイベントの処理として、そのイベントを要求したペ
ージ上の画面に視覚的な効果として反映させる場合が実
用上多く、そのページが画面から消えたら、無駄なイベ
ント処理を中断するという効果がある。勿論、場合によ
っては、明示的な指示によりページが別のページに切り
替わってもイベント処理を継続してもよい。

【００８１】次に、以上に説明した方法を用いて、サー
バ１０から送られてくるイベントをクライアント１１側
で処理しブラウザの画面（ページ表示画面）を更新する
方法について説明する。

【００８２】図７はブラウザの画面例を示す。ここで表
示されるページ画面は、クライアント１１により制御さ
れる制御機器の状態を表示するための、例えば電流値表
示欄７１と、正常／異常を示す装置（機器）状態表示欄
７２を持っている。また、表示のもとになるページには
イベント要求が記述されている。このため、当該ページ
がブラウザで表示されると、そのページの中に記述され
ているイベント要求が当該ページの提供サーバ１０に伝
えられる。この例では、イベント要求として、１秒間隔
でサーバ１０から送られてくる現在の電流値と、非同期
的にサーバ１０から送られてくる制御機器の状態（正常
か異常かを示すもの）がある。

【００８３】ブラウザ（クライアント１１）側では、ペ
ージ表示に応じて発行されるイベント要求に対してサー
バ１０から送られてくるイベントを処理し、画面上の電
流値表示欄７１または装置状態表示欄７２に反映させ
る。つまり、イベントはサーバ１０側での情報更新をク
ライアント１１側に通知するための情報更新イベントで
あるといえ、ページ画面は当該イベント（サーバ１０側
での情報更新）を反映させるためのイベント画面である
といえる。イベント処理の結果をページ画面（イベント
画面）に反映させるには、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔ
ｅｍｓ社のＪａｖａ（Ａｐｐｌｅｔ）や、Ｎｅｔｓｃａ
ｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社のＪａｖａＳｃ
ｒｉｐｔ、あるいはＭｉｃｒｏｓｏｆｔ社のＤｙｎａｍ
ｉｃ ＨＴＭＬなどを用いればよい。勿論、この方法に
限るものではない。

【００８４】図７の画面のもとになるページの形式の例
を図８に示す。図８の例では、サーバ１０ヘのイベント
要求は、ページ中のＥＶＥＮＴというタグで指定されて
いる。そのタグの中には、クライアント１１ヘ送るイベ
ントの時間間隔（ｐｅｒｉｏｄ）や受け取ったイベント
を画面に反映させるターゲット（ｔａｒｇｅｔ）などの
属性がある。イベントを画面上で反映させるタグとし
て、ＨＡＮＤＬＥＲというタグを導入している。そのタ
グには、画面に表示したときの形式（ｔｙｐｅ）や名前
（ｎａｍｅ）などの属性がある。ＥＶＥＮＴタグのｔａ
ｒｇｅｔ属性にはこのｎａｍｅ属性と同じ名前を指定す
る。なお、ここでの表現は一例に過ぎず、その他の形式
であっても勿論構わない。

【００８５】［第２の実施形態］図９は本発明の第２の
実施形態に係るリアルタイム情報配信システムの構成を
示すブロック図であり、図１と同一部分には同一符号を
付してある。

【００８６】図９のシステムが図１のシステムと異なる
点は、図１中のサーバ１０に代えて、タイマ装置Ｃが追
加されたサーバ（情報提供サーバ）２０を用いると共
に、図１中のクライアント１１に代えて、タイマ装置Ａ
及びタイマ装置Ｂが追加されたクライアント（情報表示
クライアント）２１を用いていることである。

【００８７】図９のシステムの特徴は、タイマ装置Ａ〜
Ｃを導入することにより、以下に述べるように、サーバ
２０側で発生するイベントの発生間隔に応じてイベント
の送信方式を柔軟に変更することを可能とし、更にネッ
トワーク１２が何らかの障害により切断されたときに、
クライアント２１からサーバ２０へのイベントの再要求
を自動化することを可能としたことにある。

【００８８】ここで、図９のシステムにおけるクライア
ント２１のタイマ装置Ａを中心とする動作について、図
１０のフローチャートを参照して説明する。

【００８９】まずタイマ装置Ａは、サーバ２０からクラ
イアント２１に当該クライアント２１の要求したページ
が送られると、そのページをページ受信装置１１２を介
して受け取って、そのページ中のイベント要求の形式を
解析する（ステップＣ１）。次にタイマ装置Ａは、ステ
ップＣ１での解析の結果から、イベントの発生が定期的
かどうかを調べる（ステップＣ２）。イベントの発生が
定期的である場合、上記ページ中には、そのイベントの
発生時間間隔が記述されている。

【００９０】もし、定期的でなければ、タイマ装置Ａは
本実施形態に特有の特別の動作をせずに、そのままイベ
ント要求装置１１３に対して、サーバ２０にそのイベン
トを要求することを伝える（ステップＣ３）。これに対
して定期的であれば、タイマ装置Ａは（ページ受信装置
１１２から受け取ったページの解析結果から取得され
る）そのイベントの発生時間間隔をＴＭとし（ステップ
Ｃ４）、ＴＭが予め定められた一定時間以上長いかどう
かを判定する（ステップＣ５）。

【００９１】もし、短い場合には、タイマ装置Ａは本実
施形態に特有の特別の動作をせずに、そのままイベント
要求装置１１３に対して、サーバ２０にそのイベントを
要求することを伝える（ステップＣ３）。一方、長い場
合には、タイマ装置Ａは当該タイマ装置Ａ内に時間ＴＭ
を設定して時間計測を開始すると共に、イベント要求装
置１１３対して、サーバ２０にそのイベントを要求する
ことを伝える（ステップＣ６）。これにより、イベント
要求装置１１３からサーバ２０に対してイベント要求が
発行される。この際、イベント要求装置１１３は、定期
的にイベント要求が発行できる場合など、次回にイベン
ト要求を発行する時刻が分かっているときは、次回のイ
ベント要求発行時刻の情報が付加されたイベント要求を
発行する。

【００９２】さて、イベント要求装置１１３からのイベ
ント要求に応じて、要求したイベントがサーバ２０から
送られてきたならば、イベント受信装置１１４はイベン
トの処理を行い、ネットワークインタフェース１０９は
このイベントに関するネットワーク１２の接続を切断す
る（ステップＣ７）。サーバ２０から送られるイベント
（イベント通知）には、当該イベントが定期的に発生す
るなど、次に同種のイベントが発生する時刻が分かって
いるときは、次の同種イベント発生時刻の情報が付加さ
れる。

【００９３】一方、タイマ装置Ａは、サーバ２０からイ
ベントが送られると、時間ＴＭの計測を終了するまで、
つまり上記ステップＣ６の開始時から時間ＴＭが経過す
るまで休止する（ステップＣ８）。そして時間ＴＭを計
測すると、即ち次のイベントの発生時刻が到来すると、
タイマ装置Ａは再びステップＣ６に戻り同様の処理を線
り返す。

【００９４】このタイマ装置Ａの役割は次の通りであ
る。即ち、サーバ２０側で発生するイベントの時間間隔
が定期的であり、且つ、その時間間隔ＴＭが予め定めら
れた一定時間以上長い場合には、タイマ装置Ａによりイ
ベントを受け取る時刻までの時間ＴＭを計測して、その
間はイベントを受信するネットワーク接続を切断し、そ
の時刻になったらクライアント２１（内のイベント要求
装置１１３）から明示的にイベント要求を再びサーバ２
０に発行できるようにするものである。これにより、イ
ベントが発生しない時間にサーバ２０側の無駄な負荷を
軽減することができる。また、クライアント２１側で
も、サーバ２０からイベントが送られない時間帯である
にも拘らずに、そのイベントの受信のために待機してい
るという無駄な負荷を軽減することができる。

【００９５】なお、ここの例では、イベントの発生する
時間間隔を用いていたが、それ以外にイベントの発生す
る絶対時間などを用いてもよい。

【００９６】次に、図９のシステムにおけるクライアン
ト２１のタイマ装置Ｂを中心とする動作について、図１
１のフローチャートを参照して説明する。

【００９７】まず、タイマ装置Ｂはサーバ２０から送ら
れてきたイベントをイベント受信装置１１４を介して受
け取る（ステップＤ１）。次にタイマ装置Ｂは、そのイ
ベントの中に、同種のイベントが次回に発生する時刻が
記述されているかどうか調べ（ステップＤ２）、記述さ
れていなければステップＤ１に戻る。もし、記述されて
いれば、その時刻をＴＭとし（ステップＤ３）、時刻Ｔ
Ｍに実際に次のイベントを受け取ったかどうか調べる
（ステップＤ４）。もし時刻ＴＭにイベントを受け取っ
たなら、ステップＤ２に戻る。これに対し、時刻ＴＭに
イベントを受け取らなかったなら、イベントをサーバ２
０に要求するようにイベント要求装置１１３に伝え、ス
テップＤ１に戻る。

【００９８】このタイマ装置Ｂの役割は次の通りであ
る。即ち、サーバ２０側で発生するイベントの時間間隔
が定期的である場合など、サーバ２０から送られるイベ
ントに次に同種のイベントが発生する時刻の情報が付加
されている場合には、その時刻情報の示す時刻に、クラ
イアント２１からのイベント要求に対するサーバ２０か
らの応答イベントが当該クライアント２１に送られてき
ているかどうかを、タイマ装置Ｂでの時間監視によって
調べることにより、もし、本来送られてくるはずの時刻
にイベントがサーバ２０から送られてこない場合には、
クライアント２１から再びサーバ２０にイベント要求を
発行できるようにするものである。こうすることによ
り、ネットワーク１２が何らかの原因により一時的に切
断された場合でも、イベントの受信を再開することがで
きる。

【００９９】以上に述べたクライアント２１におけるタ
イマ装置Ａ及びタイマ装置Ｂの動作は、例えばイベント
要求が設定されたページの中に、対応する処理手続きを
予め設定して、サーバ２０からクライアント２１に送信
すればよい。また、この処理手続きを、イベント要求に
対応してサーバ２０からクライアント２１に送られるイ
ベント中に設定するようにしても構わない。この処理手
続きには、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社のＪａ
ｖａ（Ａｐｐｌｅｔ）や、ＮｅｔｓｃａｐｅＣｏｍｍｕ
ｎｉｃａｔｉｏｎｓ社のＪａｖａＳｃｒｉｐｔなどが適
用可能である。

【０１００】次に、図９のシステムにおけるサーバ２０
のタイマ装置Ｃを中心とする動作について、図１２のフ
ローチャートを参照して説明する。

【０１０１】既に述べたように、サーバ２０側で発生す
るイベントが定期的であり、且つ、そのイベント発生時
間間隔がある一定時間間隔以上である場合には、タイマ
装置Ａの動作により、サーバ２０にはクライアント２１
から定期的にイベント要求が送られる。このように、ク
ライアント２１から定期的にイベント要求が発行される
場合など、クライアント２１において次にイベント要求
を発行する時刻が分かっているときは、次のイベント要
求発行時刻の情報が付加されたイベント要求がサーバ２
０に対して発行される。タイマ装置Ｃは、クライアント
２１（内のイベント要求装置１１３）から送られる、次
のイベント要求発行時刻の情報が付加されたイベント要
求をチェックするものである。

【０１０２】まずタイマ装置Ｃは、クライアント２１か
らのイベント要求をイベント要求受信装置１０４を介し
て受け取ると（ステップＥ１）、そのイベント要求の中
に、次にイベント要求が発行される時刻が記述されてい
るかどうか調べる（ステップＥ２）。もし、記述されて
いなければ、タイマ装置Ｃは何もしない（ステップＥ
３）。

【０１０３】これに対して記述されていれば、タイマ装
置Ｃはその時刻をＴＭとして（ステップＥ４）、時刻Ｔ
Ｍに実際に次のイベント要求を受け取ったかどうか調べ
る（ステップＥ５）。もし、イベント要求を受け取った
なら、ステップＥ２に戻り、同様の操作を線り返す。一
方、イベント要求を受け取らなかったなら、コネクショ
ン管理装置１０５から該当する項目を削除し、このイベ
ントに関する接続を切る（ステップＥ６）。

【０１０４】このタイマ装置Ｃの役割は次の通りであ
る。即ち、クライアント２１からサーバ２０に送られる
べきイベント要求の到来予定時刻を計測し、本来送られ
てくるはずのイベント要求が予定時刻になっても到来し
ない場合には、ネットワーク１２に何らかの障害が発生
したか、クライアント２１に何らかの異常が発生したと
判断し、接続を切るようにするものである。もし、ネッ
トワーク１２やクライアント２１の障害や異常でなく、
一時的にネットワーク１２が遅いなどの原因により接続
を切った場合には、先に述べたクライアント２１側のタ
イマ装置Ｂの機能で、再びクライアント２１からのイベ
ント要求が発生するので、接続を自動的に再開すること
ができる。

【０１０５】［第３の実施形態］図１３は本発明の第３
の実施形態に係るリアルタイム情報配信システムの構成
を示すブロック図であり、図１と同一部分には同一符号
を付してある。

【０１０６】図１３のシステムが図１のシステムと異な
る点は、図１のサーバ１０に代えて、排他ページ管理装
置３００が追加されたサーバ３０を用いていることであ
る。この排他ページ管理装置３００には、複数のクライ
アント１１で同時に表示することができないページ、つ
まり排他ページを識別するためのページ識別子（例えば
ＵＲＬ）の集合が登録されている。ここでは、排他ペー
ジの表示の待ち状態にあるクライアント１１が存在する
場合には、当該排他ページの識別子の他に、その待ち状
態にあるクライアント１１のクライアント識別子の待ち
行列（キュー）が付加される。この排他ページ管理装置
３００への排他ページ（の識別子）の登録は、クライア
ント１１からサーバ３０に送るページ要求中に、その要
求ページを排他使用することを宣言する情報を設定して
おくことで実現される。

【０１０７】また排他ページ管理装置３００は、与えら
れた任意のＨＴＭＬファイル１００に対し、特定のイベ
ント要求を行うように、ＥＭＢＥＤ，ＥＶＥＮＴタグな
どを加えて、そのＨＴＭＬファイル１００を加工する機
能を有する。

【０１０８】図１３のシステムの特徴は、排他ページ管
理装置３００が付加されたサーバ３０を用いることによ
り、以下に述べるように、あるクライアント１１（クラ
イアントＡとする）がサーバ３０から送られたある特定
のページ（例えばページＰ）を表示している間は、他の
クライアント１１（クライアントＢとする）が同じペー
ジをサーバ３０に要求しても、サーバ３０はそのクライ
アントＢに対し、要求されたページ（Ｐ）とは異なった
ページ（例えばページＱ）を送るようにしたことにあ
る。更に図１３のシステムの特徴は、クライアントＡが
他のページを表示したときに、クライアントＢの画面に
自動的に要求されたページ（ページＰ）を表示できるよ
うにしたことにもある。即ち、図１３のシステムは、複
数のクライアント１１が同時に同じページを表示ができ
ないようにしたことを特徴とする。なお、本実施形態で
は、第１の実施形態で用いたサーバに排他ページ管理装
置３００を加えたものをサーバ３０として用い、クライ
アントには同じく第１の実施形態で用いたクライアント
１１をそのまま用いているが、第２の実施形態で用いた
サーバ２０及びクライアント２１を利用しても構わな
い。

【０１０９】以下、図１３のシステムにおけるサーバ３
０の排他ページ管理装置３００を中心とする動作につい
て、図１４のフローチャートを参照して説明する。

【０１１０】まず、クライアント１１（クライアントＡ
とする）からのページ要求がサーバ３０に送られると、
排他ページ管理装置３００は、要求されたページが当該
排他ページ管理装置３００に登録されているページ、つ
まり排他ページであるかどうかの間い合わせをページ要
求受信装置１０２から受ける（ステップＦ１，Ｆ２）。
もし、排他ページでなければ、排他ページ管理装置３０
０は何もしないで終了する（ステップＦ３）。この場合
には、要求されたページがページ要求受信装置１０２か
らページ送信装置１０３に伝えられ、当該要求されたペ
ージに相当するＨＴＭＬファイル１００がページ送信装
置１０３からネットワークインタフェース１０１を介し
て要求元のクライアント１１（Ａ）に送られる。

【０１１１】これに対し、クライアント１１（Ａ）から
要求されたページが排他ページ（ページＰとする）であ
る場合には、排他ページ管理装置３００はコネクション
管理装置１０５に間い合わせ、そのページ（Ｐ）中に記
述されているイベント要求に対する接続が登録されてい
るかどうか調べる（ステップＦ４，Ｆ５）。ここで、こ
の接続が登録されている場合には、既に他のクライアン
ト１１（クライアントＢとする）が同じページ（Ｐ）を
表示していることに注意されたい。なお、排他ページを
表示中のクライアントの識別子を、当該ページのページ
識別子と組をなして、上記待ち行列とは別に、排他ペー
ジ管理装置３００内に登録するようにしても構わない。

【０１１２】さて、排他ページ（Ｐ）中に記述されてい
るイベント要求に対する接続がコネクション管理装置１
０５に登録されていた場合、つまり排他ページ（Ｐ）が
他のクライアント１１（Ｂ）で表示されている場合に
は、排他ページ管理装置３００は、ページ要求元のクラ
イアント１１（Ａ）の識別子を、当該排他ページ（Ｐ）
の識別子と組をなす待ち行列に登録する。このとき、待
ち行列に既に登録されているクライアント識別子がない
ならば、当該クライアント１１（Ａ）の識別子は待ち行
列の先頭位置に登録されることになる。

【０１１３】同時に排他ページ管理装置３００は、ペー
ジ要求受信装置１０２を介してページ送信装置１０３
に、定期的にイベント要求を行う特定のページ（ページ
Ｑとする）を伝え、当該ページ送信装置１０３により当
該特定のページ（Ｑ）をクライアント１１（Ａ）に返さ
せる（ステップＦ６）。ここで、特定のページ（Ｑ）
は、クライアント１１（Ａ）から要求された目的のペー
ジ（Ｐ）とは異なるページであり、クライアント１１
（Ａ）がそのページ（Ｑ）を受け取ることにより、要求
したページ（Ｐ）は既に他のクライアント１１で表示さ
れていると判別できるようなページであればよい。

【０１１４】一方、排他ページ（Ｐ）中に記述されてい
るイベント要求に対する接続がコネクション管理装置１
０５に登録されていない場合には、排他ページ管理装置
３００は、要求されたページ（Ｐ）に相当するＨＴＭＬ
ファイル１００に定期的なイベント要求を行うタグを埋
め込み、新たなＨＴＭＬファイル１００を生成する（ス
テップＦ７）。そして排他ページ管理装置３００は、生
成したＨＴＭＬファイル１００をページ送信装置１０３
から要求元のクライアント１１（Ａ）に送らせる（ステ
ップＦ８）。

【０１１５】ここで、要求されたページ（Ｐ）中に記述
されているイベント要求に対する接続が登録されている
場合でも、あるいは登録されていない場合でも、いずれ
にせよ、クライアント１１が排他ページ（Ｐ）を要求し
た場合には、イベント要求を必ず含むページがサーバか
ら返されることに注意されたい。

【０１１６】イベント要求を含むページがクライアント
に送られた場合、前記第１及び第２の実施形態での説明
からも明らかなように、クライアントが他のページの表
示に移動したり、ネットワークが何らかの障害により切
断されたりしたこと、更にはクライアントで異常（正常
な終了を合む）が発生したことを、サーバ側で検出する
ことができる。

【０１１７】このことは、本実施形態においてステップ
Ｆ７で生成されたＨＴＭＬファイル１００を受け取った
クライアント１１が他のページの表示に移動したり、当
該クライアント１１で異常状態が発生した場合、あるい
はネットワーク１２に障害が発生した場合にも同様であ
る。

【０１１８】このような場合、要求元クライアント１１
に送られたＨＴＭＬファイル１００にイベント要求が記
述されているにも拘わらず、そのクライアント１１から
イベント要求が送られない、あるいはイベント要求がサ
ーバ３０に伝達されないため、その異常がサーバ３０側
でわかる。

【０１１９】その結果サーバ３０からは、同じページ
（Ｐ）を要求した別のクライアント１１（Ｂ）、つまり
ステップＦ６で返された特定ページ（Ｑ）を表示してい
るクライアント１１（Ｂ）に対し、目的のページ
（Ｐ）、つまりステップＦ７で返されるページと同じも
のを表示するイベントが送られる。このイベントを受け
たクライアント１１（Ｂ）では、イベント処理の結果、
画面が切り替わって目的のページ（Ｐ）が自動的に表示
されることになる。

【０１２０】さて本実施形態においては、ステップＦ６
で生成されたページを受信しているクライアント１１
（Ｂ）は、本来目的としているページ（Ｐ）を表示して
いるのではないことに注意されたい。この場合、このク
ライアント１１（Ｂ）は本来のページを表示することが
できないため、ロックされている状態とみなすことがで
きる。そこで、このクライアント１１（Ｂ）からサーバ
３０に対し、ページ要求あるいはイベント要求があった
場合には、特定のその要求を無視する機能を当該サーバ
３０に付加してもよい。

【０１２１】なお、この実施形態では、同じページを複
数のクライアントで表示できないことを示す例である
が、異なったページでも同様のことが可能である。例え
ば、ページＡとページＢが複数のクライアントで同時に
表示されないようにすることを実現できるのは、上記の
説明で明らかである（ステップＦ５において、登録され
ているクライアントの数で判断すればよい）。また、あ
る特定のページを同時に表示できるクライアントの数
も、本実施形態のように１つに限る必要はない。

【０１２２】以上に述べたサーバ（情報提供サーバ）１
０，２０，３０を構成する機能要素群、あるいはサーバ
１０，２０，３０にて実行される処理手順は、コンピュ
ータをその機能要素群の集合として機能させるためのプ
ログラム、あるいはコンピュータに当該処理手順を実行
させるためのプログラムが記録されたＣＤ−ＲＯＭ等の
記録媒体をコンピュータに装着して、当該プログラムを
読み取り実行させることにより実現される。このプログ
ラムが、通信回線等の通信媒体を通してコンピュータに
ロードされるものであってもよい。

【０１２３】なお、以上に述べたシステムは、ネットワ
ークに接続された制御機器やＯＡ機器、及び携帯電話や
テレビなどにも応用可能である。ここで、ネットワーク
とはインターネットのような大規模なものであるとは限
らず、複数の機能要素の間を接続し、その機能要素間で
情報交換が行えるもの全体を指し、例えばシリアルバス
であってもよい。また、サーバとクライアント同一筐体
に内蔵されるものであっても構わない。このような例と
して、パーソナルコンピュータにおけるＣＰＵと、周辺
装置のマイクロプロセッサ（入出力ドライバ）などがあ
る。要するに本発明は、情報の更新に相当するイベント
（事象）の発生（ＯＡ機器、例えばプリンタであれば、
用紙がなくなったというイベント、あるいはトナーがな
くなったというイベントなど）を監視するサーバと、そ
の情報を必要とするクライアントからなるシステムに適
用可能である。

【０１２４】

【発明の効果】以上詳述したように本発明によれば、
「ページ要求」の他に、現在開かれているページ情報の
更新情報を要求する「イベント要求」という新たな概念
を導入し、情報提供サーバとそのサーバに情報提供を要
求する情報表示クライアントとの間で直接通信すること
ができない状況において、クライアントからの１回のイ
ベント要求に対し、クライアント側で表示されている情
報のもとになるサーバ側の情報の更新に相当するイベン
トが発生する毎に、その更新内容を反映させるためのイ
ベント通知がクライアントに自動的に送信されるため、
サーバ側での情報更新を自動的に且つ即座にクライアン
ト側に反映することができる。

【０１２５】また本発明によれば、サーバ側での情報更
新の時間間隔が極めて短い場合や、予め更新の時刻が分
からないような非同期的な情報更新の場合でも、クライ
アント側の画面にサーバ側での情報更新を効率良く反映
させ、しかもサーバとクライアントとの間の通信の信頼
性及び安定性を高めることができる。

【０１２６】また本発明によれば、複数のクライアント
がある特定のページを同時に表示できないように排他制
御することができる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態に係るリアルタイム情
報配信システムの構成を示すブロック図。

【図２】同実施形態で適用されるＨＴＭＬファイルの形
式例を示す図。

【図３】図１中のクライアント１１における処理の流れ
を説明するためのフローチャート。

【図４】図１中のサーバ１０における処理の流れを説明
するためのフローチャートの一部を示す図。

【図５】図１中のサーバ１０における処理の流れを説明
するためのフローチャートの残りを示す図。

【図６】図１中のサーバ１０とクライアント１１との間
の通信の過程の一例を時間軸と共に示す図。

【図７】ブラウザの画面例を示す図。

【図８】図７の画面のもとになるページの形式の一例を
示す図。

【図９】本発明の第２の実施形態に係るリアルタイム情
報配信システムの構成を示すブロック図。

【図１０】図９のシステムにおけるクライアント２１の
タイマ装置Ａを中心とする動作を説明するためのフロー
チャート。

【図１１】図９のシステムにおけるクライアント２１の
タイマ装置Ｂを中心とする動作を説明するためのフロー
チャート。

【図１２】図９のシステムにおけるサーバ２０のタイマ
装置Ｃを中心とする動作を説明するためのフローチャー
ト。

【図１３】本発明の第３の実施形態に係るリアルタイム
情報配信システムの構成を示すブロック図。

【図１４】図１３のシステムにおけるサーバ３０の排他
ページ管理装置３００を中心とする動作を説明するため
のフローチャート。

【符号の説明】

１０，２０，３０…情報提供サーバ １１，２１…情報表示クライアント １０１，１０９…ネットワークインタフェース １０２…ページ要求受信装置 １０３…ページ送信装置 １０４…イベント要求受信装置 １０５…コネクション管理装置 １０６…イベント送信装置 １０７…イベント発生装置 １０８…イベント発生監視装置 １１０…入出力装置 １１１…ページ要求装置 １１２…ページ受信装置 １１３…イベント要求装置 １１４…イベント受信装置 ３００…排他ページ管理装置 Ａ，Ｂ，Ｃ…タイマ装置

Claims (10)

【特許請求の範囲】
1. 【請求項１】 情報表示クライアントからのページ要求
   により要求されたページ情報を情報提供サーバから前記
   クライアントにネットワークを介して送信するリアルタ
   イム情報配信方法であって、 前記クライアントから前記サーバに情報提供の要求が送
   られた場合、当該要求が新規のページ情報を要求するペ
   ージ要求であるか、あるいは現在開かれているページ情
   報の更新情報を要求するイベント要求であるかを当該サ
   ーバにて判別し、 前記ページ要求の場合には、要求されたページ情報を１
   回だけ前記サーバからページ要求元のクライアントに送
   信し、 前記イベント要求の場合には、対応するページ情報の更
   新に相当するイベントが発生する毎に、当該ページ情報
   の更新内容を反映させるためのイベント通知を前記サー
   バからイベント要求元のクライアントに送信することを
   特徴とするリアルタイム情報配信方法。
2. 【請求項２】 前記サーバは前記クライアントからのペ
   ージ要求に応じて、ページ情報の更新情報をページ要求
   元のクライアントから当該サーバに要求するイベント要
   求を発行させるための少なくとも１つのイベント要求情
   報が設定されたページ情報を送信し、 前記イベント要求情報が設定されたページ情報に応じ
   て、前記クライアントから前記サーバに前記イベント要
   求が送られた場合には、当該ページ情報の更新に相当す
   るイベントが発生する毎に、当該ページ情報の更新内容
   を反映させるためのイベント通知をイベント要求先のサ
   ーバからイベント要求元のクライアントに送信すること
   を特徴とする請求項１記載のリアルタイム情報配信方
   法。
3. 【請求項３】 前記クライアントからの前記イベント要
   求に応じてイベント発生毎に前記サーバからイベント要
   求元のクライアントにイベント通知を送信する必要があ
   る状況において、前記サーバでの前記イベントの発生を
   当該サーバが監視し、 予め定められた一定時間イベントが発生しなかった場合
   には、前記イベント要求元のクライアントの状態確認の
   ためのクライアント状態確認イベント通知を前記サーバ
   から当該クライアントに送り、 前記サーバからのイベント通知時には、そのイベント通
   知に成功したか否かを当該サーバにて確認し、イベント
   通知に失敗した場合には、イベント通知に用いているネ
   ットワーク接続を当該サーバ側で切断することを特徴と
   する請求項2 記載のリアルタイム情報配信方法。
4. 【請求項４】 前記クライアントからのページ要求に応
   じて前記サーバから送信される、前記イベント要求情報
   が設定されたページ情報の中に、前記クライアントによ
   り実行させる所定の手続きを設定することにより、 前記イベント要求が設定されたページ情報を受け取った
   クライアントにおいて、当該ページ情報の表示から他の
   ページ要求に対応したページ情報の表示に切り替える際
   に、当該イベント要求に対する前記サーバからのイベン
   ト通知に関係するネットワーク接続を前記所定の手続き
   に従って前記クライアントにより切断させるようにした
   ことを特徴とする請求項２記載のリアルタイム情報配信
   方法。
5. 【請求項５】 前記クライアントからのページ要求に応
   じて前記サーバから送信される、前記イベント要求情報
   が設定されたページ情報の中に、対応するイベントの発
   生が定期的であるか不定期的であるかを示す情報、定期
   的である場合にはその時間間隔の情報、及び前記クライ
   アントにより実行させる所定の手続きを設定することに
   より、 前記イベント要求情報が設定されたページ情報を受け取
   ったクライアントにより当該ページ情報中の前記所定の
   手続きに従って、対応するイベントの発生が定期的で、
   且つその時間間隔が定められた間隔以上の場合に、前記
   イベント要求に対して前記サーバから送られるイベント
   通知を受け取る毎にネットワーク接続を一時的に切断
   し、前記時間間隔で決まるイベント発生予定時期の到来
   を待って再びイベント要求を発行する動作を実行させる
   ようにしたことを特徴とする請求項２記載のリアルタイ
   ム情報配信方法。
6. 【請求項６】 前記クライアントからのページ要求に応
   じて前記サーバから送信される、前記イベント要求情報
   が設定されたページ情報、または前記クライアントから
   のイベント要求に応じて前記サーバから送信されるイベ
   ント通知の中に、前記クライアントにより実行させる所
   定の手続きを設定すると共に、当該イベント通知の中
   に、次に同じイベントが発生する時刻情報を設定するこ
   とにより、 前記イベント通知を受け取った前記クライアントによ
   り、前記所定の手続きに従って次のイベント通知の到来
   を監視させ、前記受け取ったイベント通知中の時刻情報
   の示す予定時刻に前記サーバから次のイベント通知を受
   け取ることができなかった場合には、前記サーバにイベ
   ント要求を発行させるようにしたことを特徴とする請求
   項２記載のリアルタイム情報配信方法。
7. 【請求項７】 前記クライアントからのページ要求に応
   じて前記サーバから送信される、前記イベント要求情報
   が設定されたページ情報の中に、前記クライアントから
   発行される前記イベント要求に次回イベント要求を発行
   する時刻情報を付加させる手続きを設定し、 前記クライアントから前記サーバに前記イベント要求が
   発行された場合には、前記サーバにおいて前記クライア
   ントからの次のイベント要求の到来を監視し、先行する
   イベント要求中の時刻情報の示す予定時刻に次のイベン
   ト要求を受け取ることができなかった場合には、当該イ
   ベント要求に関係するネットワーク接続を切断すること
   を特徴とする請求項２記載のリアルタイム情報配信方
   法。
8. 【請求項８】 前記サーバ中に、複数のクライアントで
   同時に表示することが禁止される排他ページの情報を登
   録しておき、 前記サーバが前記クライアントからページ要求を受け取
   った場合には、前記排他ページの登録情報から、要求さ
   れたページ情報が排他ページであるか否かを調べ、 排他ページの場合には、当該ページが他のクライアント
   で表示中であるか否かを調べ、 他のクライアントで表示中でない場合には、前記要求さ
   れたページ情報の中に前記イベント要求情報が設定され
   た新たなページ情報を前記ページ要求元のクライアント
   に送信し、 他のクライアントで表示中の場合には、要求されたペー
   ジ情報に代えて、特定のイベント要求を行わせるための
   特定イベント要求情報が設定された特定ページ情報を前
   記ページ要求元のクライアントに送信して、当該クライ
   アントでの要求されたページ情報の表示を待たせ、 前記排他ページの表示状態にあった前記クライアントに
   対する前記サーバからのイベント通知に関係するネット
   ワーク接続が切断され、且つ前記排他ページの表示の待
   ち状態にあるクライアントが存在する場合には、その待
   ち状態にあるいずれか１つのクライアントに、前記要求
   されたページ情報の中に前記イベント要求情報が設定さ
   れた新たなページ情報を前記特定イベント要求に対する
   応答として送信することを特徴とする請求項３または請
   求項４記載のリアルタイム情報配信方法。
9. 【請求項９】 前記待ち状態にあるクライアントから前
   記サーバに対してページ要求またはイベント要求が送ら
   れた場合、前記サーバにおける当該要求に対する処理を
   通常状態から変更することを特徴とする請求項８記載の
   リアルタイム情報配信方法。
10. 【請求項１０】 情報表示クライアントからのページ要
    求により要求されたページ情報を当該クライアントにネ
    ットワークを介して送信する情報提供サーバにおいて、 前記クライアントから情報提供の要求が送られた場合
    に、当該要求が新規のページ情報を要求するページ要求
    であるか、あるいは更新情報を要求するイベント要求で
    あるかを判別する要求判別手段と、 前記ページ要求の場合には、要求されたページ情報を１
    回だけ前記サーバからページ要求元のクライアントに送
    信するページ情報送信手段と、 前記イベント要求の場合には、対応するページ情報の更
    新に相当するイベントが発生する毎に、当該ページ情報
    の更新のためのイベント通知をイベント要求元のクライ
    アントに送信するイベント送信手段とを具備することを
    特徴とする情報提供サーバ。