JP4634547B2

JP4634547B2 - リアルタイム情報配信方法

Info

Publication number: JP4634547B2
Application number: JP19958798A
Authority: JP
Inventors: 秀行堤竹
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1998-06-30
Filing date: 1998-06-30
Publication date: 2011-02-16
Anticipated expiration: 2018-06-30
Also published as: US6480883B1; JP2000020423A

Description

【０００１】
【発明の属する技術分野】
本発明は、クライアントサーバ方式のシステム、例えば情報提供サーバ及び情報表示クライアントがネットワークを介して接続されるシステムに係り、特にサーバ側での情報更新をクライアント側に通知するのに好適なリアルタイム情報配信方法に関する。
【０００２】
【従来の技術】
近年、ＷＷＷ（Ｗｏｒ１ｄＷｉｄｅＷｅｂ）と呼ばれるシステムが社会システムとして浸透し、様々な情報がＷＷＷを介して提供されている。ＷＷＷはサーバ（情報提供サーバ）とクライアント（情報表示クライアント）から構成される、インターネットを利用した分散型の情報提供／情報表示（情報閲覧）システムである。一般に、サーバはページと呼ばれる文書単位でクライアントヘ情報を提供する。このページはＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）と呼ばれる形式のフォーマットで記述されているファイルである。クライアントは通常、ブラウザと呼ばれる情報表示（情報閲覧）用のソフトウェアを用いて実現されており、サーバにアクセスし、画像や音声などを含む文書を表示することができる。
【０００３】
ＷＷＷの一般的な使われ方は、ブラウザからサーバに表示したいページのアドレス（ＵＲＬと呼ばれる）を要求し、サーバはそのアドレスに対応するページをクライアントに返すというものである。ここで注意しなければならないのは、ブラウザから明示的な要求がない限り、サーバは何もしないということである。これは、サーバに蓄えてあるページが変更されても、ブラウザからは変更を即座に知ることができないとことを意味する。
【０００４】
サーバにあるページが更新されたことをブラウザ側でできるだけ早く知るためには、ブラウザは常にサーバのページが更新されたかどうかを定期的にアクセスする必要がある。例えば、ニュースや天気予報などのようなサーバ側のページが時々刻々変更されるようなページをブラウザで表示している場合、サーバ側でページが更新されてもブラウザの画面は変わらない。そこで、ユーザが明示的に、ブラウザ（の情報表示画面）に付加されているリロードボタンなどを押すことで、サーバに明示的に再アクセスしなければならない。
【０００５】
このような問題を解決するために、ユーザの明示的なリロードを行わなくても、自動的に定期的にサーバにアクセスし、常に最新の情報を表示するようなブラウザが知られている。つまり、ブラウザが情報の更折を、ユーザに代わって白動的に行うものである。代表的な例として、ＰｏｉｎｔＣａｓｔ社のＰｏｉｎｔＣａｓｔや、Ｍａｒｉｍｂａ社のＣａｓｔａｎｅｔＴｕｎｅｒなどが知られている。
【０００６】
これらのブラウザでは、自動更新の時間間隔などをユーザが指定できるとか、更新された場合でも無駄なデータを転送しないように差分データだけをブラウザが受け取るような工夫がされている。この種の自動更新を行う機構は、しばしば、プッシュ機構と呼ばれる。その理由は、サーバで更新された情報がＴＶ（テレビジョン）放送のように自動的にブラウザに送られてくるような感覚をユーザに与えるからでる。しかし、実際に更新するのは、ブラウザてあり、単にユーザが明示的にリロードボタンを押す作業をブラウザ側で自動化しているに過ぎない。ここでのプッシュ機構は、次に説明する、より本来の意味に近いプッシュ機構との区別を強調するため、スマートプル機構と呼ばれることもある。
【０００７】
さて、サーバ側で更新された情報をブラウザ側で自動的に更新するもう一つの手法について述べる。この手法は、情報提供サーバ（ＷＷＷサーバ）が提供するＨＴＭＬファイルを拡張し、ＨＴＭＬファイル中に次回の更新時刻などの情報を記述する手段を設けることである。この場合、このＨＴＭＬファイルを受け取ったブラウザは、そのＨＴＭＬファイル中に記述されている更新時刻などの情報を利用し、その時刻になったら、サーバに新しい情報の提供を要求することで、サーバヘの無駄なアクセスがなく、あたかもリアルタイムで情報が更新されたかのような効果をブラウザ側で実現することができる。この種の自動更新機構はプッシュ機構と呼ばれる。
【０００８】
【発明が解決しようとする課題】
上記したスマートプル機構及びプッシュ機構は、情報を更新する主体がブラウザである点では類似している。スマートプル機構では、サーバの情報が更新されたかどうかをブラウザ側から当該サーバに確認するために、ブラウザが定期的にサーバに自動的にアクセスする。そのため、情報には何ら特別な属性を必要としない半面、サーバの情報が実際には更新されていない場合でも定期的なアクセスを繰り返さなければならず、無駄なアクセスが多いという問題点がある。
【０００９】
一方、プッシュ機構では、情報の中の属性として次回に更新する時刻などが記述されたファイル（ＨＴＭＬファイル）を用いることから、サーバ側の情報が更新されているかどうかを確認するための無駄なアクセスを減らすことができる。しかし、このプッシュ機構では、更新する時刻を予め知ることができるような情報種類のものにしか有効ではない。即ちプッシュ機構では、非同期的に変更されるような情報の場合、クライアントが何時更新してよいか分からないので、問題の解決とはならない。
【００１０】
更に、スマートプル機構及びプッシュ機構のどちらの場合でも、更新間隔が極めて短い提供情報、例えば１秒間隔で更新されるような情報に対しては、非常に効率が悪いという問題がある。その理由は次の通りである。一般にサーバとクライアント間で通信を始める際には、送りたいデータを送る前に、まず幾つかの交信のやりとり（ネゴシエーション）を行う必要がある。上記の例では、このネゴシエーションを、１秒間隔で行わなければならない。つまり、提供情報の更新の時間間隔が短い場合、情報本文を送るコストに比べ、このネゴシエーションのコストの比重が高くなり非常に効率が悪くなる。
【００１１】
一方、サーバからクライアントのブラウザに更新情報を直接送ることができるならば、上記問題は解決可能となる。しかし、この方式は現状のＷＷＷのフレームワークに照らし合わせると現実的な解決ではない。その理由は次の通りである。
【００１２】
まず、現状のＷＷＷでは、サーバとクライアント間に複数の中継サーバが存在することがある。中継サーバの中には、ファイアーウォールと呼ばれる、情報を一方向のみ転送するものがある。このファイアーウォールは、特に企業などにおいて、外部からのシステム（企業内システム）への進入を防ぐために一般的に用いられている。
【００１３】
中魅サーバを介した場合、クライアントと直接通信するのは、クライアントに最も近い中継サーバであり、サーバと直接通信できるのは、サーバに最も近い中継サーバである。したがって、サーバから見た場合、直接のクライアントはその中継サーバてあり、ユーザが用いているブラウザはサーバから感知できない。したがって、サーバからブラウザに直接更新通知を送ることはできない。しかも、途中にある中継サーバは不特定多数のクライアントあるいはサーバからアクセスされるため、信頼性や安定性に問題がある。
【００１４】
また、サーバからクライアントの動作を直接知ることができないため、クライアントが現在どのページを表示しているかをサーバ側では感知することができないという問題もある。このことは、あるブラウザがある特定のページを表示している間は、他のブラウザが同じページを表示できなくするなどの排他制御ができない、もしくは非常に困難であることを意味する。そのため、利用可能なアプリケーションの種類が限られてしまうという問題点がある。特に、制御機器をブラウザから制御する場合などのように、一つのクライアントが独占的（排他的）にサーバにアクセスし、機器を操作するといったアプリケーションの実装が困難である。
【００１５】
本発明は上記事情を考慮してなされたものでその目的は、情報提供サーバとそのサーバに情報提供を要求する情報表示クライアントとの間で直接通信することができない状況において、サーバ側の情報が更新された場合に、即座にクライアントに通知することができるリアルタイム情報配信方法を提供することにある。
本発明の他の目的は、サーバ側での情報更新の時間間隔が極めて短い場合や、予め更新の時刻が分からないような非同期的な情報更新の場合でも、クライアント側の画面にサーバ側での情報更新を効率良く反映させ、しかもサーバとクライアントとの間の通信の信頼性及び安定性を高めることができるリアルタイム情報配信方法を提供することにある。
【００１６】
本発明の更に他の目的は、複数のクライアントがある特定のページを同時に表示できないように排他制御することができるリアルタイム情報配信方法を提供することにある。
【００１７】
【課題を解決するための手段】
本発明は、情報表示クライアントからのページ要求により要求されたページ情報を情報提供サーバから上記クライアントにネットワークを介して送信するリアルタイム情報配信方法であって、クライアントからサーバに情報提供の要求が送られた場合、当該要求が新規のページ情報を要求するページ要求であるか、あるいは現在開かれているページ情報の更新情報を要求するイベント要求であるかを当該サーバにて判別し、ページ要求の場合には、要求されたページ情報を１回だけ当該サーバからページ要求元のクライアントに送信し、イベント要求の場合には、対応するページ情報の更新に相当するイベントが発生する毎に、当該ページ情報の更新内容を反映させるためのイベント通知を上記サーバからイベント要求元のクライアントに送信することを特徴とする。
【００１８】
このような構成においては、従来から知られている「ページ要求」の他に、現在開かれているページ情報の更新情報を要求する「イベント要求」という新たな概念を導入し、サーバとクライアントを接続したままの状態で、クライアントからの１回のイベント要求に対し、サーバからイベント発生に応じて継続的にイベント通知をクライアントに送信することにより、サーバ側でページ情報の更新が発生する毎に、その更新内容を自動的にクライアント側に反映させることができ、しかもサーバとクライアントとの間の通信の負荷を軽減することが可能となる。特に、イベントの発生頻度が１秒間隔またはそれより短い程度のものに対して効率がよく、リアルタイム性が期待できる。更に、サーバはクライアントからの要求（イベント要求）に応じて継続的なイベント通知を行うため、既存のＷＷＷプロトコルのみを用いて実現できる。
【００１９】
これに対して従来のＷＷＷ上のプッシュ技術は、サーバで提供するページ情報の中に次にそのページ情報が更新される時刻などを記述することで、クライアント（ブラウザ）側でその時刻になったらサーバにアクセスするというものであった。この技術では、時系列データなどのような１秒程度の短い間隔で更新されるデータについては、ネットワークの接続／切断が頻繁に発生するため問題であった。
【００２０】
また本発明は、クライアントからのページ要求に対してサーバから送信するページ情報中に、当該ページ情報を受け取ったクライアントから上記のイベント要求を発行させるための、つまりサーバでのイベント通知を起動させるための少なくとも１つのイベント要求情報を設定するようにしたことを特徴とする。
【００２１】
このような構成においては、要求したページ情報をサーバから受け取ったクライアント側では、当該ページ情報中に設定されているイベント要求情報に従って自動的にイベント要求を当該サーバに発行してイベント通知を起動することができる。つまり、ページ情報とイベントを関連付けることにより、クライアント側で開かれているページ情報をサーバから送られてくるイベント通知に応じて動的に変化させることができる。
【００２２】
さて、クライアントが正常にイベント通知を受け取っているか否かをサーバから知るためには、実際にイベント通知を送る必要がある。しかし、サーバにおいてイベントが発生するまでは、そのことがわからないため、たとえクライアントでのページ処理が終了していても、サーバ側ではネットワーク接続のための負荷がかかっている。
【００２３】
そこで本発明は、サーバでのイベント発生毎に当該サーバからイベント要求元のクライアントにイベント通知を送信する必要がある状況において、ある一定時間イベントが発生しなかった場合には、イベント要求元のクライアントの状態確認のための特別のイベント通知（クライアント状態確認イベント通知）をサーバからクライアントに送るようにすると共に、サーバからの（クライアント状態確認イベント通知を含む）イベント通知時には、そのイベント通知に成功したか否かを当該サーバにて確認し、イベント通知に失敗した場合には、イベント通知に用いているネットワーク接続を当該サーバ側で切断するようにしたことを特徴とする。
【００２４】
このような構成においては、ある一定時間以上イベントが発生しない場合には、定期的にイベント要求元のクライアントの状態確認のための特別のイベント通知を明示的に発生して当該クライアントに送信することにより、当該クライアントの状態を知ることができる。そこで、クライアントでのページ処理が終了していたり、ネットワークが切れているといった要因でイベント通知（の送信）に失敗した場合には、サーバ側でネットワーク接続を切断することにより、無駄な負荷を削減することができる。
【００２５】
イベント通知に対するクライアント側の処理として、イベント通知を受け取ったなら、その内容により画面に即座に反映させるという応用が考えられる。そのためには、クライアント側で開かれているページ情報が切り替えられる際には工夫が必要となる。
【００２６】
そこで本発明は、クライアントからのページ要求に対してサーバから送信するイベント要求情報付きのページ情報中に、当該クライアントにより実行させる所定の手続きを設定し、当該ページ情報を受け取ったクライアントにおいて、当該ページ情報の表示から他のページ要求に対応したページ情報の表示に切り替える際に、つまり別のページに移動する際には、当該イベント要求に対するサーバからのイベント通知に関係するネットワーク接続を上記所定の手続きに従ってクライアントにより切断させるようにしたことを特徴とする。
【００２７】
このような構成においては、クライアントが別のページに移動したら、そのページの更新を反映させるためのイベント通知を受け取るネットワーク（コネクション）がクライアント側で切断されるため、無駄な通信を排除することができる。しかもクライアント側では、その処理のための特別な仕組みを必要としない。
また本発明は、クライアントからのページ要求に対してサーバから送信するイベント要求情報付きのページ情報中に、対応するイベントの発生が定期的であるか不定期的であるかを示す情報、定期的である場合にはその時間間隔の情報、及び当該クライアントにより実行させる所定の手続きを設定し、当該ページ情報を受け取ったクライアントにより上記所定の手続きに従って、対応するイベントの発生が定期的で、且つその時間間隔が定められた間隔以上の場合に、イベント要求に対してサーバから送られるイベント通知を受け取る毎にネットワーク接続を一時的に切断し、上記時間間隔で決まるイベント発生予定時期の到来を待って再びイベント要求を発行する動作を実行させるようにしたことを特徴とする。
【００２８】
このような構成においては、イベント発生が定期的で、且つ、その間隔が長い場合には、クライアント側にて一旦ネットワーク接続が切断され、イベントが発生する予定の時刻に近づいたならば再びネットワーク接続がなされてイベント要求が発行されるため、無駄なネットワークの負荷、及びサーバとクライアントのＣＰＵの負荷を削減できる。しかもクライアント側では、その処理のための特別な仕組みを必要としない。
【００２９】
また本発明は、クライアントからのページ要求に対してサーバから送信するイベント要求情報付きのページ情報、またはクライアントからのイベント要求に応じてサーバから送信するイベント通知の中に、当該クライアントにより実行させる所定の手続きを設定すると共に、上記イベント通知の中に、次に同じイベントが発生する時刻情報を設定し、上記イベント通知を受け取ったクライアントにより、上記所定の手続きに従って次のイベント通知の到来を監視させ、上記受け取ったイベント通知中の時刻情報の示す予定時刻にサーバから次のイベント通知を受け取ることができなかった場合には、当該クライアントからサーバにイベント要求を発行させるようにしたことを特徴とする。
【００３０】
このような構成においては、次にイベントが発生する時刻が予測できる場合には、その時刻になってもサーバからイベントが送られてこないならば、ネットワークが一時的に切断された可能性があるとして、クライアントから再びイベント要求が発行されるため、ネットワーク接続を再開することができ、信頼性を高めることが可能となる。つまりイベント通知に用いるコネクションは、接続した状態を保ったままにしておくが、コネクションが外的要因によリ切断されたら、クライアントから自動的に再接続することにより、不安定なネットワークであってもある程度の信頼性が期待できる。しかもクライアント側では、その処理のための特別な仕組みを必要としない。
【００３１】
また本発明は、クライアントからのページ要求に対してサーバから送信するイベント要求情報付きのページ情報の中に、クライアントから発行されるイベント要求に次回イベント要求を発行する時刻情報を付加させる手続きを設定し、上記ページ情報を受け取ったクライアントからサーバに対して時刻情報付きのイベント要求が発行された場合には、当該サーバにおいて次のイベント要求の到来を監視し、先行するイベント要求中の時刻情報の示す予定時刻に次のイベント要求を受け取ることができなかった場合には、当該イベント要求に関係するネットワーク接続を切断することを特徴とする。
【００３２】
このような構成においては、クライアントからのイベント要求の発行予定時刻をサーバ側で知ることができるため、その予定時刻になってもイベント要求がなければ、サーバ側ではクライアントが正しく機能していない（終了しているか、ネットワークが切断されている）と判断し、ネットワーク接続を切断することにより、サーバの無駄なＣＰＵ負荷を削減することができる。しかもクライアント側では、次回のイベント要求の発行予定時刻をサーバに通知するための特別な仕組みを必要としない。
【００３３】
また本発明は、サーバ中に、複数のクライアントで同時に表示することが禁止される排他ページの情報を登録しておき、サーバがクライアントからページ要求を受け取った場合には、上記排他ページの登録情報から、要求されたページ情報が排他ページであるか否かを調べ、排他ページの場合には、当該ページが他のクライアントで表示中であるか否かを調べ、他のクライアントで表示中でない場合には、要求されたページ情報の中にイベント要求情報が設定された新たなページ情報をページ要求元のクライアントに送信し、他のクライアントで表示中の場合には、要求されたページ情報に代えて、特定のイベント要求を行わせるための特定イベント要求情報が設定された特定ページ情報をページ要求元のクライアントに送信して、当該クライアントでの要求されたページ情報の表示を待たせ、排他ページの表示状態にあったクライアントに対するサーバからのイベント通知に関係するネットワーク接続が切断され、且つ排他ページの表示の待ち状態にあるクライアントが存在する場合には、その待ち状態にあるいずれか１つのクライアントに、要求されたページ情報の中にイベント要求情報が設定された新たなページ情報を上記特定イベント要求に対する応答として送信することを特徴とする。
【００３４】
このような構成においては、ページ情報中に埋め込まれたイベント要求情報に従うクライアントからのイベント要求発行を利用することで、従来のＷＷＷでは実現が困難であった複数のクライアントが同じページを同時に表示することができないような機構（ページのロック機構）を容易に実現でき、しかも排他ページを表示しているクライアントでのページ処理が終了したりした場合には、そのページを表示できないでいた他のクライアントにその旨を通知することにより、自動的に本来要求したページに切り替えることができ、ユーザインタフェースの向上が図れる。
【００３５】
また本発明は、要求したページが排他ページで、しかも別のクライアントで表示中のために、特別のページが送られた待ち状態にあるクライアントからサーバに対してページ要求またはイベント要求が送られた場合、サーバにおける当該要求に対する処理を通常状態から変更するようにしたことを特徴とする。
【００３６】
このように、ロックされたページの待ち状態にあるクライアントからサーバへの要求が発生した場合に、その要求に対する処理を通常とは変え、例えば無視することで、当該クライアント自身を仮想的にロックすることが可能となる。これは、制御機器などをクライアントから制御する場合に、他のクライアントに制御を渡さないようにすることができ、信頼性の向上が図れる。
【００３７】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００３８】
［第１の実施形態］
図１は本発明の第１の実施形態に係るリアルタイム情報配信システムの構成を示すブロック図である。
【００３９】
同図において、情報提供サーバ（情報提供サーバ計算機）１０は、ＷＷＷ（Ｗｏｒ１ｄＷｉｄｅＷｅｂ）サーバとして機能し、インターネットなどのネットワーク１２に接続されている。情報表示クライアント（情報表示クライアント計算機）１１は、情報提供サーバ１０にリクエストを発行し、結果を表示するブラウザ（情報表示ソフトウェア）を有する。このブラウザは、Ｎｅｔｓｃａｐｅ社のＮｅｔｓｃａｐｅＣｏｍｍｉｎｉｃａｔｏｒやＭｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔＥｘｐ１ｏｒｅｒなどの汎用のブラウザでよい。
【００４０】
また、図には示されていないが、情報提供サーバ１０と情報表示クライアント１１の間には代理サーバ（ｐｒｏｘｙサーバ）と呼ばれる中継サーバが存在してもよい。代理サーバは、クライアントからリクエストを受け取り、そのリクエストをそのままサーバに送り、サーバから送られてきた結果をそのままクライアントに返すものである。また、このような代理サーバは情報提供サーバ１０と情報表示クライアント１１との間に複数存在してもよい。以下、曖昧性がない場合、情報提供サーバを単にサーバと呼び、情報表示クライアントを単にクライアントと呼ぶ。また、クライアントを、ブラウザと呼ぶこともある。
【００４１】
なお、図では作図の都合上、ネットワーク１２に接続されているクライアント１１が１台の場合を示してあるが、複数のクライアント１１が接続されるのが一般的である。またサーバ１０についても、１台に限らないことは勿論である。
【００４２】
図１のシステムは、クライアント１１から制御される制御機器（図示せず）が、サーバ１０により監視可能なように当該サーバ１０に接続されてている場合を想定している。
【００４３】
ここで、サーバ（情報提供サーバ）１０の構成について説明する。
【００４４】
ネットワークインタフェース１０１は、ネットワーク１２からのデータを受信し、またネットワーク１２にデータを送信する機能を持つ。またネットワークインタフェース１０１は、受信したデータの種類を識別し、その種類に適合したサーバ１０内装置に当該データを渡す機能を持つ。
【００４５】
ページ要求受信装置１０２は、ネットワークインタフェース１０１を介してクライアント１１から送られるページ要求を受理し、解析し、当該クライアント１１に送るべきページをページ送信装置１０３に伝える。ページ要求には、ＷＷＷで一般に用いられるＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）と呼ばれる形式が適用されるものとする。
【００４６】
ページ送信装置１０３は、サーバ１０内に蓄えてあるＨＴＭＬファイル１００をネットワークインタフェース１０１を介してネットワーク１２に送信する。送信の対象となる情報としては、ＨＴＭＬファイル（１００）に限らず、画像や音声などの任意の情報であってもよい。
【００４７】
イベント要求受信装置１０４は、ネットワークインタフェース１０１を介してクライアント１１から送られるイベント要求を受理し、解析し、コネクション管理装置１０５と通信してイベント要求を処理すべきかどうか判断する。そしてイベント要求受信装置１０４は、必要ならイベント送信装置１０６に対して、当該イベント送信装置１０６からクライアント１１にイベントを送るように指示する。
【００４８】
イベント発生装置１０７は、非同期的あるいは、不定期的にイベントを発生する。ここではイベントの種類は問わないが、イベントの例を挙げる。例えば、制御機器に流れている電流の値が一定値以上変化したとか、このサーバ１０にアクセスしているクライアント１１の数が特定の数になったとか、予め指定した時刻になったなどがイベントである。イベント発生装置１０７で発生されたイベントは直接イベント送信装置１０６に送られる。この他に、イベント発生監視装置１０８でイベント発生要因を監視し、その結果発生するイベントとしてイベント送信装置１０６に送られる構成も適用される。このように本実施形態では、イベント送信装置１０６へイベントを送るのに２種の方法が適用されるが、いずれか一方を適用する構成であっても構わない。
【００４９】
イベント発生監視装置１０８は、イベント発生装置１０７では明示的には発生しないようなイベントを監視する。つまりイベント発生監視装置１０８は、例えば、制御機器に流れる電流が１００Ａ以下になったときにイベントとしてクライアント１１に通知したいにも拘わらずに、イベント発生装置１０でそのようなイベントが定義されていない場合には、定期的に電流を監視し、１００Ａ以下になったらイベントとしてイベント送信装置１０６に通知するといった機能を持つ。この他に、イベント発生装置１０７で発生したある特定のイベントの発生回数が予め定められた回数となったことをもって、クライアント１１に通知するなどといった種類のイベントもイベント発生監視装置１０８で生成される。
【００５０】
イベント送信装置１０６は、イベント発生装置１０７またはイベント発生監視装置１０８から送られるイベントをネットワークインタフェース１０１を介してクライアント１１に送信する。また、同じイベントを複数のクライアント１１が要求している場合もあり、そのときはイベント送信装置１０６は、それぞれのクライアント１１に同じイベントを送る。
【００５１】
コネクション管理装置１０５は、イベントの種類とそのイベントをどのクライアント１１が要求しているかの情報を管理する。イベント送信装置１０６はこの情報を参照しながら、イベントが発生したらそのイベントを要求している全てのクライアント１１に、その同じイベントを送る。イベントは、ページ送信装置１０３が送るページと異なって一過性のものであり、また、そのイベントを要求しているクライアント１１の数に拘わらずに同じイベントをクライアント１１の数だけ複製して送らなければならないことに注意されたい。
【００５２】
次に、クライアント（情報表示クライアント）１１の構成について説明する。
ネットワークインタフェース１０９は、ネットワーク１２に接続されているサーバ１０にページ要求、あるいはイベント要求を発行するため、クライアント１１のリクエストをネットワーク１２に送出し、またサーバ１０からの応答を受け取る。またネットワークインタフェース１０９は、サーバ１０からの応答を、その種類に応じ、ページ受信装置１１２あるいはイベント受信装置１１４に転送する。
【００５３】
入出力装置１１０は、キーボード、ディスプレイ及びマウスなどから構成される。ページ要求のＵＲＬは、入出力装置１１０を用いた操作、例えば入出力装置１１０内の例えばキーボードから直接入力することで、あるいはページ中にあるリンクをマウスでクリックすることで、ページ要求装置１１１に伝えられる。
【００５４】
ページ要求装置１１１は、入出力装置１１０から入力されたページのアドレス（ＵＲＬ）を受け取り、ネットワークインタフェース１０９を介してサーバ１０に要求する。
【００５５】
ページ受信装置１１２は、要求したページに対し、サーバ１０からの応答をネネットワークインタフェース１０９を介して受信する。受信したページは、入出力装置１１０のディスプレイに表示される。サーバ１０から受信したページの中にはサーバ１０へのイベント要求をするための記述が含まれている場合がある。そのときには、ページ受信装置１１２からイベント要求装置１１３にイベント要求のＵＲＬが伝えられる。
【００５６】
イベント要求装置１１３は、指定されたＵＲＬをネットワークインタフェース１０９を介してサーバ１０に送る。なお、図には示していないが、イベント要求のＵＲＬはページ受信装置１１２から与えられるだけでなく、入出力装置１１０からユーザにより直接与えられてもよい。
【００５７】
イベント受信装置１１４は、イベント要求装置１１３がサーバ１０に要求することにより当該サーバ１０から送られるイベントを受け取る。受け取ったイベントは、必要に応じ入出力装置１１０に伝えられ表示画面にその旨を反映させることができる。
【００５８】
本実施形態において、クライアント１１のページ要求に対してサーバ１０から送られるページの形式は、通常のＨＴＭＬファイル形式である。勿論、それ以外の形式であっても構わない。
【００５９】
図２にＨＴＭＬファイル形式の例を示す。この例ではページの中にサーバヘのイベント要求が含まれている例を示した。イベント要求はＥＭＢＥＤというタグの中のＥＶＥＮＴというタグのＵＲＬという属性で示される。この表現はこれに限るものではない。例えば、イベント要求がＨＴＭＬファイル中には明示的に記述されてなく、他のページへのリンクとして表現され、そのページの中でイベント要求が記述されている場合でも、もとのＨＴＭＬファイルからイベント要求がサーバに送られるという方法も適用可能である。また、別の方法としては、ページ中に埋め込まれた何らかのプログラム（ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ社が開発したＪａｖａのＡｐｐｌｅｔや、Ｎｅｔｓｃａｐｅ社が開発したＪａｖａＳｃｒｉｐｔなど）から動的にイベント要求が発生する手法を適用することも可能である。
【００６０】
次に、図１のシステムのクライアント１１における、当該クライアント１１からサーバ１０へのページ要求とそれに付随するイベント要求の処理の流れについて、図３のフローチャートを参照して説明する。
【００６１】
まずクライアント１１において、入出力装置１１０からページ要求（ＵＲＬ）が発生すると（ステップＡ１）、現在表示しているページにイベント要求が含まれていれば、ネットワークインタフェース１０９はそのイベント要求に対するサーバ１０からのイベント通知に関係するネットワーク接続を切断する（ステップＡ２）。この操作は、クライアント１１側で別のページ要求が発生したとき、つまりページを切り替えようとする際に、イベント要求が含まれている表示中のページに関するイベント受信のネットワーク接続を当該クライアント１１（内のネットワークインタフェース１０９）により切断させる手続きを、当該ページ中に予め記述しておくことで実現される。この手続きには、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ社のＪａｖａ（Ａｐｐｌｅｔ）や、ＮｅｔｓｃａｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ社のＪａｖａＳｃｒｉｐｔなどが適用可能である。
【００６２】
ページ要求装置１１１は適切なサーバ１０に対してページを要求する（ステップＡ３）。ページ受信装置１１２はサーバ１０からの応答を読む準備をし（ステップＡ４）、当該サーバ１０からページが送られてくるまで待機する（ステップＡ５）。ページ受信装置１１２はサーバ１０からページが送られてきたら当該ページの内容を解析し（ステップＡ６）、イベント要求がそのページに含まれているかどうか判断する（ステップＡ７）。
【００６３】
もし、イベント要求が含まれていない場合には、ページ受信装置１１２はそのページを入出力装置１１０に出力する（ステップＡ１２）。これにより受信したページの内容が入出力装置１１０のディスプレイに表示される。
【００６４】
一方、イベント要求が含まれていた場合には、ページ受信装置１１２はイベント要求装置１１３にイベントのＵＲＬを伝え、イベント要求装置１１３によりサーバ１０にイベント要求を送らせる（ステップＡ８）。この場合、ページ受信装置１１２はサーバ１０からの応答（イベント）を読む準備をし（ステップＡ９）、当該サーバ１０からイベントが送られてきたかどうかチェックする（ステップＡ１０）。そしてページ受信装置１１２は、イベントが送られてない場合にはそのまま待機し、イベントが送られてきたらそのイベントを処理する（ステップＡ１１）。イベントの処理の結果によっては、後述するように入出力装置１１０の表示画面が更新されることもある。
【００６５】
なお、図３のフローチャート中で一点鎖線で囲まれた処理部分（ステップＡ８〜Ａ１１）はステップＡ１２と並行して処理することができる。つまり、ステップＡ１２で画面にページを表示している最中でもイベントの読み込みや処理を行うことができる。また、ページの中に複数のイベント要求が記述されている場合にも、複数のイベント処理を同時に進めることができる。
【００６６】
以上のクライアント１１側の処理で特徴的な点は、ページ要求に対する応答は１回であるのに対し、イベント要求に対する応答とその処理は限りがないということである。イベントの処理を終了させるためには、図には示していないが、外部からの指示が必要である。
【００６７】
次にサーバ１０側の処理の流れについて、図４及び図５のフローチャートを参照して説明する。
【００６８】
まずサーバ１０内のネットワークインタフェース１０１は、クライアント１１からの要求を受信する状態で常に待機している（ステップＢ１）。ネットワークインタフェース１０１はクライアント１１からの要求を受信するとそれがページ要求かイベント要求かを判断し（ステップＢ２，Ｂ３）、ページ要求であればページ要求受信装置１０２に渡す。するとページ要求受信装置１０２は、ページ要求の内容を解析してページ送信装置１０３に伝える（ステップＢ４）。
【００６９】
ページ送信装置１０３は目的のページに相当するＨＴＭＬファイル１００が（図示せぬファイル蓄積装置に）あるかどうか調べる（ステップＢ５）。もし、該当するＨＴＭＬファイル１００があるならば、ページ送信装置１０３はそのファイル１００を要求元のクライアント１１に返し（ステップＢ６）、なければエラーメッセージを当該クライアント１１に返す（ステップＢ７）。ここで、ページのファイルとしてＨＴＭＬファイルを例にしているが、これに限るものではない。
【００７０】
一方、クライアント１１からの要求がイベント要求の場合には、ネットワークインタフェース１０１は、そのイベント要求をイベント要求受信装置１０４に渡す。するとイベント要求受信装置１０４は、コネクション管理装置１０５に対し、イベント要求により要求されたイベントの識別子（イベントＩＤ）と要求元のクライアント１１の識別子（クライアントＩＤ）との対が既に登録されているかどうか問い合わせる（ステップＢ８，Ｂ９）。既に登録されている場合には、イベント要求受信装置１０４はネットワークインタフェース１０１によりクライアント１１との接続を切らせる（ステップＢ１０）。これに対して登録されていない場合には、コネクション管理装置１０５にそれを登録させる（ステップＢ１１）。このステップＢ１０，Ｂ１１の処理は、後の説明で明らかになるように、コネクション管理装置１０５に登録されているイベントとそのクライアント１１はその時点で既に通信（コネクション）が張られていることを意味し、同じクライアント１１へ２重にイベントを送信しないためのものである。
【００７１】
次に、イベント発生装置１０７またはイベント発生監視装置１０８においてイベントが発生したかどうかが調べられる（ステップＢ１２）。イベントが発生していない場合、イベント送信装置１０６において、前回最後にイベントを送った時刻から、予め定められた一定時間が経過したかどうかが調べられる（ステップＢ１３）。もし、経過していたら、イベント送信装置１０６は、イベント要求元のクライアント１１の状態等を確認するために、システムイベントと呼ぶ特別なイベントをイベント要求元のクライアント１１に送る（ステップＢ１４）。これに対し、まだ時間が経過していなければ、イベント発生装置１０７またはイベント発生監視装置１０８においてイベントが発生したかどうかが再び調べられる（ステップＢ１２）。
【００７２】
一方、イベント発生装置１０７またはイベント発生監視装置１０８でイベントが発生したならば、イベント送信装置１０６に対し、そのイベントをクライアント１１に送るように伝えられる（ステップＢ１５）。これによりイベント送信装置１０６は、ネットワークインタフェース１０１を介してイベント要求元のクライアント１１にそのイベントを送る（ステップＢ１６）。
【００７３】
ネットワークインタフェース１０１は、クライアント１１にイベントを送ると、そのイベントが正しく送られたかどうかを、当該クライアント１１からの応答により調べる（ステップＢ１７）。もし、正しく送られたなら、再びイベントが発生するまで待機状態となる。これに対し、イベントが正しく送られなかったなら、ネットワークインタフェース１０１によりクライアント１１との接続が切断され、イベント送信装置１０６によりコネクション管理装置１０５から対応する項目が削除される（ステップＢ１８）。
【００７４】
以上のサーバ１０側の処理で特徴的な点は、クライアント１１からのイベント要求が１度だけあると、常時イベントが発生する度に当該クライアント１１にイベントを送り続けるという流れになっていることである。これは、ページ要求のように、１回の要求に対１つのページを送るという方式と異なる。クライアント１１とイベント要求元のクライアント１１との間では接続が常時保たれたままであり、イベントが正しく送られなかったらその接続を切る。また、イベントが、予め定められた一定時間の間に発生しない場合には、システムイベントを定期的にイベント要求元クライアント１１に送り、当該クライアント１１がイベントを受信できているかどうかをチェックする。これは、ネットワーク１２の回線が途中で切断されるとか、クライアント１１が自ら接続を切断したという状況を検出し、そのときには、サーバ１０側のイベント検出／送信ループを中止するようにするためである。
【００７５】
次に図１のシステムにおける、サーバ１０とクライアント１１の両者を含めた動作について説明する。
【００７６】
図６はサーバ１０とクライアント１１との間の通信の過程の一例を時間軸と共に示したものである。
【００７７】
まず、クライアント１１からサーバ１０にページ要求が発生すると、サーバ１０は要求された目的のページをクライアント１１に返す。ここで、クライアント１１からの要求とそれに対するサーバ１０の応答は、両者が対応付けられるように同じＩＤ（図ではＣｏｎｎ１）を付けるものとする。
【００７８】
次に、クライアント１１はページの解析をし、その中に記述されているイベント要求がもしあればサーバ１０に送る。このとき別のコネクションＩＤ（Ｃｏｎｎ２）が用いられる。サーバ１０はイベントが発生すると、そのコネクションＩＤを用いクライアント１１にイベントを送信する。以降イベントが発生する度にこれを繰り返す。
【００７９】
一方、クライアント１１が、別のページ要求（Ｃｏｎｎ３）をした場合には、同時にＣｏｎｎ２の接続を切断する。すると、サーバ１０側でＣｏｎｎ２に送るべきイベントが発生したときにエラーが検出され、コネクション管理装置１０５から対応する項目を削除する。クライアント１１からの新たなページ要求に対しては、該当するページをサーバ１０から当該クライアント１１に送る。以下、同様の通信が線り返される。
【００８０】
クライアント１１側で、別のページ要求が発生したとき、サーバ１０からのイベント受信の接続を切断することの効果は次の通りである。即ち、サーバ１０からのイベントを受信した際に、クライアント１１側でのイベントの処理として、そのイベントを要求したページ上の画面に視覚的な効果として反映させる場合が実用上多く、そのページが画面から消えたら、無駄なイベント処理を中断するという効果がある。勿論、場合によっては、明示的な指示によりページが別のページに切り替わってもイベント処理を継続してもよい。
【００８１】
次に、以上に説明した方法を用いて、サーバ１０から送られてくるイベントをクライアント１１側で処理しブラウザの画面（ページ表示画面）を更新する方法について説明する。
【００８２】
図７はブラウザの画面例を示す。ここで表示されるページ画面は、クライアント１１により制御される制御機器の状態を表示するための、例えば電流値表示欄７１と、正常／異常を示す装置（機器）状態表示欄７２を持っている。また、表示のもとになるページにはイベント要求が記述されている。このため、当該ページがブラウザで表示されると、そのページの中に記述されているイベント要求が当該ページの提供サーバ１０に伝えられる。この例では、イベント要求として、１秒間隔でサーバ１０から送られてくる現在の電流値と、非同期的にサーバ１０から送られてくる制御機器の状態（正常か異常かを示すもの）がある。
【００８３】
ブラウザ（クライアント１１）側では、ページ表示に応じて発行されるイベント要求に対してサーバ１０から送られてくるイベントを処理し、画面上の電流値表示欄７１または装置状態表示欄７２に反映させる。つまり、イベントはサーバ１０側での情報更新をクライアント１１側に通知するための情報更新イベントであるといえ、ページ画面は当該イベント（サーバ１０側での情報更新）を反映させるためのイベント画面であるといえる。イベント処理の結果をページ画面（イベント画面）に反映させるには、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ社のＪａｖａ（Ａｐｐｌｅｔ）や、ＮｅｔｓｃａｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ社のＪａｖａＳｃｒｉｐｔ、あるいはＭｉｃｒｏｓｏｆｔ社のＤｙｎａｍｉｃＨＴＭＬなどを用いればよい。勿論、この方法に限るものではない。
【００８４】
図７の画面のもとになるページの形式の例を図８に示す。図８の例では、サーバ１０ヘのイベント要求は、ページ中のＥＶＥＮＴというタグで指定されている。そのタグの中には、クライアント１１ヘ送るイベントの時間間隔（ｐｅｒｉｏｄ）や受け取ったイベントを画面に反映させるターゲット（ｔａｒｇｅｔ）などの属性がある。イベントを画面上で反映させるタグとして、ＨＡＮＤＬＥＲというタグを導入している。そのタグには、画面に表示したときの形式（ｔｙｐｅ）や名前（ｎａｍｅ）などの属性がある。ＥＶＥＮＴタグのｔａｒｇｅｔ属性にはこのｎａｍｅ属性と同じ名前を指定する。なお、ここでの表現は一例に過ぎず、その他の形式であっても勿論構わない。
【００８５】
［第２の実施形態］
図９は本発明の第２の実施形態に係るリアルタイム情報配信システムの構成を示すブロック図であり、図１と同一部分には同一符号を付してある。
【００８６】
図９のシステムが図１のシステムと異なる点は、図１中のサーバ１０に代えて、タイマ装置Ｃが追加されたサーバ（情報提供サーバ）２０を用いると共に、図１中のクライアント１１に代えて、タイマ装置Ａ及びタイマ装置Ｂが追加されたクライアント（情報表示クライアント）２１を用いていることである。
【００８７】
図９のシステムの特徴は、タイマ装置Ａ〜Ｃを導入することにより、以下に述べるように、サーバ２０側で発生するイベントの発生間隔に応じてイベントの送信方式を柔軟に変更することを可能とし、更にネットワーク１２が何らかの障害により切断されたときに、クライアント２１からサーバ２０へのイベントの再要求を自動化することを可能としたことにある。
【００８８】
ここで、図９のシステムにおけるクライアント２１のタイマ装置Ａを中心とする動作について、図１０のフローチャートを参照して説明する。
【００８９】
まずタイマ装置Ａは、サーバ２０からクライアント２１に当該クライアント２１の要求したページが送られると、そのページをページ受信装置１１２を介して受け取って、そのページ中のイベント要求の形式を解析する（ステップＣ１）。次にタイマ装置Ａは、ステップＣ１での解析の結果から、イベントの発生が定期的かどうかを調べる（ステップＣ２）。イベントの発生が定期的である場合、上記ページ中には、そのイベントの発生時間間隔が記述されている。
【００９０】
もし、定期的でなければ、タイマ装置Ａは本実施形態に特有の特別の動作をせずに、そのままイベント要求装置１１３に対して、サーバ２０にそのイベントを要求することを伝える（ステップＣ３）。これに対して定期的であれば、タイマ装置Ａは（ページ受信装置１１２から受け取ったページの解析結果から取得される）そのイベントの発生時間間隔をＴＭとし（ステップＣ４）、ＴＭが予め定められた一定時間以上長いかどうかを判定する（ステップＣ５）。
【００９１】
もし、短い場合には、タイマ装置Ａは本実施形態に特有の特別の動作をせずに、そのままイベント要求装置１１３に対して、サーバ２０にそのイベントを要求することを伝える（ステップＣ３）。一方、長い場合には、タイマ装置Ａは当該タイマ装置Ａ内に時間ＴＭを設定して時間計測を開始すると共に、イベント要求装置１１３対して、サーバ２０にそのイベントを要求することを伝える（ステップＣ６）。これにより、イベント要求装置１１３からサーバ２０に対してイベント要求が発行される。この際、イベント要求装置１１３は、定期的にイベント要求が発行できる場合など、次回にイベント要求を発行する時刻が分かっているときは、次回のイベント要求発行時刻の情報が付加されたイベント要求を発行する。
【００９２】
さて、イベント要求装置１１３からのイベント要求に応じて、要求したイベントがサーバ２０から送られてきたならば、イベント受信装置１１４はイベントの処理を行い、ネットワークインタフェース１０９はこのイベントに関するネットワーク１２の接続を切断する（ステップＣ７）。サーバ２０から送られるイベント（イベント通知）には、当該イベントが定期的に発生するなど、次に同種のイベントが発生する時刻が分かっているときは、次の同種イベント発生時刻の情報が付加される。
【００９３】
一方、タイマ装置Ａは、サーバ２０からイベントが送られると、時間ＴＭの計測を終了するまで、つまり上記ステップＣ６の開始時から時間ＴＭが経過するまで休止する（ステップＣ８）。そして時間ＴＭを計測すると、即ち次のイベントの発生時刻が到来すると、タイマ装置Ａは再びステップＣ６に戻り同様の処理を線り返す。
【００９４】
このタイマ装置Ａの役割は次の通りである。即ち、サーバ２０側で発生するイベントの時間間隔が定期的であり、且つ、その時間間隔ＴＭが予め定められた一定時間以上長い場合には、タイマ装置Ａによりイベントを受け取る時刻までの時間ＴＭを計測して、その間はイベントを受信するネットワーク接続を切断し、その時刻になったらクライアント２１（内のイベント要求装置１１３）から明示的にイベント要求を再びサーバ２０に発行できるようにするものである。これにより、イベントが発生しない時間にサーバ２０側の無駄な負荷を軽減することができる。また、クライアント２１側でも、サーバ２０からイベントが送られない時間帯であるにも拘らずに、そのイベントの受信のために待機しているという無駄な負荷を軽減することができる。
【００９５】
なお、ここの例では、イベントの発生する時間間隔を用いていたが、それ以外にイベントの発生する絶対時間などを用いてもよい。
【００９６】
次に、図９のシステムにおけるクライアント２１のタイマ装置Ｂを中心とする動作について、図１１のフローチャートを参照して説明する。
【００９７】
まず、タイマ装置Ｂはサーバ２０から送られてきたイベントをイベント受信装置１１４を介して受け取る（ステップＤ１）。次にタイマ装置Ｂは、そのイベントの中に、同種のイベントが次回に発生する時刻が記述されているかどうか調べ（ステップＤ２）、記述されていなければステップＤ１に戻る。もし、記述されていれば、その時刻をＴＭとし（ステップＤ３）、時刻ＴＭに実際に次のイベントを受け取ったかどうか調べる（ステップＤ４）。もし時刻ＴＭにイベントを受け取ったなら、ステップＤ２に戻る。これに対し、時刻ＴＭにイベントを受け取らなかったなら、イベントをサーバ２０に要求するようにイベント要求装置１１３に伝え、ステップＤ１に戻る。
【００９８】
このタイマ装置Ｂの役割は次の通りである。即ち、サーバ２０側で発生するイベントの時間間隔が定期的である場合など、サーバ２０から送られるイベントに次に同種のイベントが発生する時刻の情報が付加されている場合には、その時刻情報の示す時刻に、クライアント２１からのイベント要求に対するサーバ２０からの応答イベントが当該クライアント２１に送られてきているかどうかを、タイマ装置Ｂでの時間監視によって調べることにより、もし、本来送られてくるはずの時刻にイベントがサーバ２０から送られてこない場合には、クライアント２１から再びサーバ２０にイベント要求を発行できるようにするものである。こうすることにより、ネットワーク１２が何らかの原因により一時的に切断された場合でも、イベントの受信を再開することができる。
【００９９】
以上に述べたクライアント２１におけるタイマ装置Ａ及びタイマ装置Ｂの動作は、例えばイベント要求が設定されたページの中に、対応する処理手続きを予め設定して、サーバ２０からクライアント２１に送信すればよい。また、この処理手続きを、イベント要求に対応してサーバ２０からクライアント２１に送られるイベント中に設定するようにしても構わない。この処理手続きには、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ社のＪａｖａ（Ａｐｐｌｅｔ）や、ＮｅｔｓｃａｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ社のＪａｖａＳｃｒｉｐｔなどが適用可能である。
【０１００】
次に、図９のシステムにおけるサーバ２０のタイマ装置Ｃを中心とする動作について、図１２のフローチャートを参照して説明する。
【０１０１】
既に述べたように、サーバ２０側で発生するイベントが定期的であり、且つ、そのイベント発生時間間隔がある一定時間間隔以上である場合には、タイマ装置Ａの動作により、サーバ２０にはクライアント２１から定期的にイベント要求が送られる。このように、クライアント２１から定期的にイベント要求が発行される場合など、クライアント２１において次にイベント要求を発行する時刻が分かっているときは、次のイベント要求発行時刻の情報が付加されたイベント要求がサーバ２０に対して発行される。タイマ装置Ｃは、クライアント２１（内のイベント要求装置１１３）から送られる、次のイベント要求発行時刻の情報が付加されたイベント要求をチェックするものである。
【０１０２】
まずタイマ装置Ｃは、クライアント２１からのイベント要求をイベント要求受信装置１０４を介して受け取ると（ステップＥ１）、そのイベント要求の中に、次にイベント要求が発行される時刻が記述されているかどうか調べる（ステップＥ２）。もし、記述されていなければ、タイマ装置Ｃは何もしない（ステップＥ３）。
【０１０３】
これに対して記述されていれば、タイマ装置Ｃはその時刻をＴＭとして（ステップＥ４）、時刻ＴＭに実際に次のイベント要求を受け取ったかどうか調べる（ステップＥ５）。もし、イベント要求を受け取ったなら、ステップＥ２に戻り、同様の操作を線り返す。一方、イベント要求を受け取らなかったなら、コネクション管理装置１０５から該当する項目を削除し、このイベントに関する接続を切る（ステップＥ６）。
【０１０４】
このタイマ装置Ｃの役割は次の通りである。即ち、クライアント２１からサーバ２０に送られるべきイベント要求の到来予定時刻を計測し、本来送られてくるはずのイベント要求が予定時刻になっても到来しない場合には、ネットワーク１２に何らかの障害が発生したか、クライアント２１に何らかの異常が発生したと判断し、接続を切るようにするものである。もし、ネットワーク１２やクライアント２１の障害や異常でなく、一時的にネットワーク１２が遅いなどの原因により接続を切った場合には、先に述べたクライアント２１側のタイマ装置Ｂの機能で、再びクライアント２１からのイベント要求が発生するので、接続を自動的に再開することができる。
【０１０５】
［第３の実施形態］
図１３は本発明の第３の実施形態に係るリアルタイム情報配信システムの構成を示すブロック図であり、図１と同一部分には同一符号を付してある。
【０１０６】
図１３のシステムが図１のシステムと異なる点は、図１のサーバ１０に代えて、排他ページ管理装置３００が追加されたサーバ３０を用いていることである。この排他ページ管理装置３００には、複数のクライアント１１で同時に表示することができないページ、つまり排他ページを識別するためのページ識別子（例えばＵＲＬ）の集合が登録されている。ここでは、排他ページの表示の待ち状態にあるクライアント１１が存在する場合には、当該排他ページの識別子の他に、その待ち状態にあるクライアント１１のクライアント識別子の待ち行列（キュー）が付加される。この排他ページ管理装置３００への排他ページ（の識別子）の登録は、クライアント１１からサーバ３０に送るページ要求中に、その要求ページを排他使用することを宣言する情報を設定しておくことで実現される。
【０１０７】
また排他ページ管理装置３００は、与えられた任意のＨＴＭＬファイル１００に対し、特定のイベント要求を行うように、ＥＭＢＥＤ，ＥＶＥＮＴタグなどを加えて、そのＨＴＭＬファイル１００を加工する機能を有する。
【０１０８】
図１３のシステムの特徴は、排他ページ管理装置３００が付加されたサーバ３０を用いることにより、以下に述べるように、あるクライアント１１（クライアントＡとする）がサーバ３０から送られたある特定のページ（例えばページＰ）を表示している間は、他のクライアント１１（クライアントＢとする）が同じページをサーバ３０に要求しても、サーバ３０はそのクライアントＢに対し、要求されたページ（Ｐ）とは異なったページ（例えばページＱ）を送るようにしたことにある。更に図１３のシステムの特徴は、クライアントＡが他のページを表示したときに、クライアントＢの画面に自動的に要求されたページ（ページＰ）を表示できるようにしたことにもある。即ち、図１３のシステムは、複数のクライアント１１が同時に同じページを表示ができないようにしたことを特徴とする。
なお、本実施形態では、第１の実施形態で用いたサーバに排他ページ管理装置３００を加えたものをサーバ３０として用い、クライアントには同じく第１の実施形態で用いたクライアント１１をそのまま用いているが、第２の実施形態で用いたサーバ２０及びクライアント２１を利用しても構わない。
【０１０９】
以下、図１３のシステムにおけるサーバ３０の排他ページ管理装置３００を中心とする動作について、図１４のフローチャートを参照して説明する。
【０１１０】
まず、クライアント１１（クライアントＡとする）からのページ要求がサーバ３０に送られると、排他ページ管理装置３００は、要求されたページが当該排他ページ管理装置３００に登録されているページ、つまり排他ページであるかどうかの間い合わせをページ要求受信装置１０２から受ける（ステップＦ１，Ｆ２）。もし、排他ページでなければ、排他ページ管理装置３００は何もしないで終了する（ステップＦ３）。この場合には、要求されたページがページ要求受信装置１０２からページ送信装置１０３に伝えられ、当該要求されたページに相当するＨＴＭＬファイル１００がページ送信装置１０３からネットワークインタフェース１０１を介して要求元のクライアント１１（Ａ）に送られる。
【０１１１】
これに対し、クライアント１１（Ａ）から要求されたページが排他ページ（ページＰとする）である場合には、排他ページ管理装置３００はコネクション管理装置１０５に間い合わせ、そのページ（Ｐ）中に記述されているイベント要求に対する接続が登録されているかどうか調べる（ステップＦ４，Ｆ５）。ここで、この接続が登録されている場合には、既に他のクライアント１１（クライアントＢとする）が同じページ（Ｐ）を表示していることに注意されたい。なお、排他ページを表示中のクライアントの識別子を、当該ページのページ識別子と組をなして、上記待ち行列とは別に、排他ページ管理装置３００内に登録するようにしても構わない。
【０１１２】
さて、排他ページ（Ｐ）中に記述されているイベント要求に対する接続がコネクション管理装置１０５に登録されていた場合、つまり排他ページ（Ｐ）が他のクライアント１１（Ｂ）で表示されている場合には、排他ページ管理装置３００は、ページ要求元のクライアント１１（Ａ）の識別子を、当該排他ページ（Ｐ）の識別子と組をなす待ち行列に登録する。このとき、待ち行列に既に登録されているクライアント識別子がないならば、当該クライアント１１（Ａ）の識別子は待ち行列の先頭位置に登録されることになる。
【０１１３】
同時に排他ページ管理装置３００は、ページ要求受信装置１０２を介してページ送信装置１０３に、定期的にイベント要求を行う特定のページ（ページＱとする）を伝え、当該ページ送信装置１０３により当該特定のページ（Ｑ）をクライアント１１（Ａ）に返させる（ステップＦ６）。ここで、特定のページ（Ｑ）は、クライアント１１（Ａ）から要求された目的のページ（Ｐ）とは異なるページであり、クライアント１１（Ａ）がそのページ（Ｑ）を受け取ることにより、要求したページ（Ｐ）は既に他のクライアント１１で表示されていると判別できるようなページであればよい。
【０１１４】
一方、排他ページ（Ｐ）中に記述されているイベント要求に対する接続がコネクション管理装置１０５に登録されていない場合には、排他ページ管理装置３００は、要求されたページ（Ｐ）に相当するＨＴＭＬファイル１００に定期的なイベント要求を行うタグを埋め込み、新たなＨＴＭＬファイル１００を生成する（ステップＦ７）。そして排他ページ管理装置３００は、生成したＨＴＭＬファイル１００をページ送信装置１０３から要求元のクライアント１１（Ａ）に送らせる（ステップＦ８）。
【０１１５】
ここで、要求されたページ（Ｐ）中に記述されているイベント要求に対する接続が登録されている場合でも、あるいは登録されていない場合でも、いずれにせよ、クライアント１１が排他ページ（Ｐ）を要求した場合には、イベント要求を必ず含むページがサーバから返されることに注意されたい。
【０１１６】
イベント要求を含むページがクライアントに送られた場合、前記第１及び第２の実施形態での説明からも明らかなように、クライアントが他のページの表示に移動したり、ネットワークが何らかの障害により切断されたりしたこと、更にはクライアントで異常（正常な終了を合む）が発生したことを、サーバ側で検出することができる。
【０１１７】
このことは、本実施形態においてステップＦ７で生成されたＨＴＭＬファイル１００を受け取ったクライアント１１が他のページの表示に移動したり、当該クライアント１１で異常状態が発生した場合、あるいはネットワーク１２に障害が発生した場合にも同様である。
【０１１８】
このような場合、要求元クライアント１１に送られたＨＴＭＬファイル１００にイベント要求が記述されているにも拘わらず、そのクライアント１１からイベント要求が送られない、あるいはイベント要求がサーバ３０に伝達されないため、その異常がサーバ３０側でわかる。
【０１１９】
その結果サーバ３０からは、同じページ（Ｐ）を要求した別のクライアント１１（Ｂ）、つまりステップＦ６で返された特定ページ（Ｑ）を表示しているクライアント１１（Ｂ）に対し、目的のページ（Ｐ）、つまりステップＦ７で返されるページと同じものを表示するイベントが送られる。このイベントを受けたクライアント１１（Ｂ）では、イベント処理の結果、画面が切り替わって目的のページ（Ｐ）が自動的に表示されることになる。
【０１２０】
さて本実施形態においては、ステップＦ６で生成されたページを受信しているクライアント１１（Ｂ）は、本来目的としているページ（Ｐ）を表示しているのではないことに注意されたい。この場合、このクライアント１１（Ｂ）は本来のページを表示することができないため、ロックされている状態とみなすことができる。そこで、このクライアント１１（Ｂ）からサーバ３０に対し、ページ要求あるいはイベント要求があった場合には、特定のその要求を無視する機能を当該サーバ３０に付加してもよい。
【０１２１】
なお、この実施形態では、同じページを複数のクライアントで表示できないことを示す例であるが、異なったページでも同様のことが可能である。例えば、ページＡとページＢが複数のクライアントで同時に表示されないようにすることを実現できるのは、上記の説明で明らかである（ステップＦ５において、登録されているクライアントの数で判断すればよい）。また、ある特定のページを同時に表示できるクライアントの数も、本実施形態のように１つに限る必要はない。
【０１２２】
以上に述べたサーバ（情報提供サーバ）１０，２０，３０を構成する機能要素群、あるいはサーバ１０，２０，３０にて実行される処理手順は、コンピュータをその機能要素群の集合として機能させるためのプログラム、あるいはコンピュータに当該処理手順を実行させるためのプログラムが記録されたＣＤ−ＲＯＭ等の記録媒体をコンピュータに装着して、当該プログラムを読み取り実行させることにより実現される。このプログラムが、通信回線等の通信媒体を通してコンピュータにロードされるものであってもよい。
【０１２３】
なお、以上に述べたシステムは、ネットワークに接続された制御機器やＯＡ機器、及び携帯電話やテレビなどにも応用可能である。ここで、ネットワークとはインターネットのような大規模なものであるとは限らず、複数の機能要素の間を接続し、その機能要素間で情報交換が行えるもの全体を指し、例えばシリアルバスであってもよい。また、サーバとクライアント同一筐体に内蔵されるものであっても構わない。このような例として、パーソナルコンピュータにおけるＣＰＵと、周辺装置のマイクロプロセッサ（入出力ドライバ）などがある。要するに本発明は、情報の更新に相当するイベント（事象）の発生（ＯＡ機器、例えばプリンタであれば、用紙がなくなったというイベント、あるいはトナーがなくなったというイベントなど）を監視するサーバと、その情報を必要とするクライアントからなるシステムに適用可能である。
【０１２４】
【発明の効果】
以上詳述したように本発明によれば、「ページ要求」の他に、現在開かれているページ情報の更新情報を要求する「イベント要求」という新たな概念を導入し、情報提供サーバとそのサーバに情報提供を要求する情報表示クライアントとの間で直接通信することができない状況において、クライアントからの１回のイベント要求に対し、クライアント側で表示されている情報のもとになるサーバ側の情報の更新に相当するイベントが発生する毎に、その更新内容を反映させるためのイベント通知がクライアントに自動的に送信されるため、サーバ側での情報更新を自動的に且つ即座にクライアント側に反映することができる。
【０１２５】
また本発明によれば、サーバ側での情報更新の時間間隔が極めて短い場合や、予め更新の時刻が分からないような非同期的な情報更新の場合でも、クライアント側の画面にサーバ側での情報更新を効率良く反映させ、しかもサーバとクライアントとの間の通信の信頼性及び安定性を高めることができる。
【０１２６】
また本発明によれば、複数のクライアントがある特定のページを同時に表示できないように排他制御することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るリアルタイム情報配信システムの構成を示すブロック図。
【図２】同実施形態で適用されるＨＴＭＬファイルの形式例を示す図。
【図３】図１中のクライアント１１における処理の流れを説明するためのフローチャート。
【図４】図１中のサーバ１０における処理の流れを説明するためのフローチャートの一部を示す図。
【図５】図１中のサーバ１０における処理の流れを説明するためのフローチャートの残りを示す図。
【図６】図１中のサーバ１０とクライアント１１との間の通信の過程の一例を時間軸と共に示す図。
【図７】ブラウザの画面例を示す図。
【図８】図７の画面のもとになるページの形式の一例を示す図。
【図９】本発明の第２の実施形態に係るリアルタイム情報配信システムの構成を示すブロック図。
【図１０】図９のシステムにおけるクライアント２１のタイマ装置Ａを中心とする動作を説明するためのフローチャート。
【図１１】図９のシステムにおけるクライアント２１のタイマ装置Ｂを中心とする動作を説明するためのフローチャート。
【図１２】図９のシステムにおけるサーバ２０のタイマ装置Ｃを中心とする動作を説明するためのフローチャート。
【図１３】本発明の第３の実施形態に係るリアルタイム情報配信システムの構成を示すブロック図。
【図１４】図１３のシステムにおけるサーバ３０の排他ページ管理装置３００を中心とする動作を説明するためのフローチャート。
【符号の説明】
１０，２０，３０…情報提供サーバ
１１，２１…情報表示クライアント
１０１，１０９…ネットワークインタフェース
１０２…ページ要求受信装置
１０３…ページ送信装置
１０４…イベント要求受信装置
１０５…コネクション管理装置
１０６…イベント送信装置
１０７…イベント発生装置
１０８…イベント発生監視装置
１１０…入出力装置
１１１…ページ要求装置
１１２…ページ受信装置
１１３…イベント要求装置
１１４…イベント受信装置
３００…排他ページ管理装置
Ａ，Ｂ，Ｃ…タイマ装置

Claims

情報表示クライアントからのページ要求により要求されたページ情報を情報提供サーバから前記クライアントにネットワークを介して送信するリアルタイム情報配信システムにおいて、
前記クライアントからのページ要求に応じて、ページ情報の更新情報をページ要求元のクライアントから当該サーバに要求するイベント要求を発行させるためのイベント要求情報であって、前記ページ要求元のクライアントと前記サーバとを接続させるためのイベント要求情報が設定されたページ情報を、前記サーバからページ要求元のクライアントに送信し、
前記サーバから前記クライアントに送信されたページ情報に設定されている前記イベント要求情報に基づいて前記クライアントから前記サーバにイベント識別子を含むイベント要求を送信することによって、前記サーバに対して、ページ情報の更新に相当する当該イベント識別子で示されるイベントの発生に応じて当該イベントを通知することを要求すると共に、当該イベントの通知のために前記サーバを前記クライアントとネットワーク接続することを要求し、
前記クライアントからの前記イベント要求に応じて、前記サーバが当該クライアントの識別子及び前記イベント要求に含まれている前記イベント識別子の対を当該サーバに登録し、
ページ情報の更新に相当するイベントの発生であって、前記サーバに登録されているイベント識別子で示されるイベントの発生の都度、当該ページ情報の更新内容を反映させるためのイベント通知を前記サーバからイベント要求元のクライアントに前記ネットワーク接続を利用して送信し、
前記サーバからの前記イベント通知時には、そのイベント通知に成功したか否かを前記イベント要求元のクライアントからの応答に基づき前記サーバが判定し、当該イベント通知に失敗した場合には、前記サーバが、当該サーバに登録されている当該クライアントの識別子及び前記イベント識別子の対を削除して、当該イベント通知に用いられている当該クライアントとのネットワーク接続を切断することを特徴とするリアルタイム情報配信方法。
前記サーバに登録されているイベント識別子で示されるイベントの発生を前記サーバが監視し、
前記サーバに登録されているイベント識別子で示されるイベントが予め定められた一定時間発生しなかった場合には、前記イベント要求元のクライアントの状態確認のためのイベント通知を前記サーバから当該クライアントに送信し、
前記クライアントへの前記状態確認のためのイベント通知に失敗した場合には、前記サーバが、当該サーバに登録されている当該クライアントの識別子及び前記イベント識別子の対を削除して、当該イベント通知に用いられている当該クライアントとのネットワーク接続を切断することを特徴とする請求項１記載のリアルタイム情報配信方法。
前記クライアントからのページ要求に応じて前記サーバから送信される、前記イベント要求情報が設定されたページ情報の中に、前記クライアントにより実行させる所定の手続きを設定することにより、
前記イベント要求が設定されたページ情報を受け取ったクライアントにおいて、当該ページ情報の表示から他のページ要求に対応したページ情報の表示に切り替える際に、当該イベント要求に対する前記サーバからのイベント通知に用いられるネットワーク接続を前記所定の手続きに従って前記クライアントにより切断させるようにしたことを特徴とする請求項１記載のリアルタイム情報配信方法。
前記クライアントからのページ要求に応じて前記サーバから送信される、前記イベント要求情報が設定されたページ情報の中に、対応するイベントの発生が定期的であるか不定期的であるかを示す情報、定期的である場合にはその時間間隔の情報、及び前記クライアントにより実行させる所定の手続きを設定することにより、
前記イベント要求情報が設定されたページ情報を受け取ったクライアントが当該ページ情報中の前記所定の手続きに従って動作して、対応するイベントの発生が定期的で、且つその時間間隔が定められた間隔以上の場合に、前記イベント要求に対して前記サーバから送られるイベント通知を受け取る毎に当該イベント通知に用いられるネットワーク接続を一時的に切断し、前記時間間隔で決まるイベント発生予定時期の到来を待って再びイベント要求を前記サーバに送信することを特徴とする請求項１記載のリアルタイム情報配信方法。
前記クライアントからのページ要求に応じて前記サーバから送信される、前記イベント要求情報が設定されたページ情報、または前記クライアントからのイベント要求に応じて前記サーバから送信されるイベント通知の中に、前記クライアントにより実行させる所定の手続きを設定すると共に、当該イベント通知の中に、次に同じイベントが発生する時刻情報を設定することにより、
前記イベント通知を受け取った前記クライアントが、前記所定の手続きに従って次のイベント通知の到来を監視し、前記受け取ったイベント通知中の時刻情報の示す予定時刻に前記サーバから次のイベント通知を受け取ることができなかった場合には、前記サーバにイベント要求を送信することを特徴とする請求項１記載のリアルタイム情報配信方法。
前記クライアントからのページ要求に応じて前記サーバから送信される、前記イベント要求情報が設定されたページ情報の中に、前記クライアントから発行される前記イベント要求に次回イベント要求を発行する時刻情報を付加させる手続きを設定し、
前記クライアントから前記サーバに前記イベント要求が発行された場合には、前記サーバにおいて前記クライアントからの次のイベント要求の到来を監視し、先行するイベント要求中の時刻情報の示す予定時刻に次のイベント要求を受け取ることができなかった場合には、当該イベント要求に用いられるネットワーク接続を切断することを特徴とする請求項１記載のリアルタイム情報配信方法。
前記サーバ中に、複数のクライアントで同時に表示することが禁止される排他ページの情報を登録しておき、
前記サーバが前記クライアントからページ要求を受け取った場合には、前記排他ページの登録情報から、要求されたページ情報が排他ページであるか否かを調べ、
排他ページの場合には、当該ページが他のクライアントで表示中であるか否かを調べ、
他のクライアントで表示中でない場合には、前記要求されたページ情報の中に前記イベント要求情報が設定された新たなページ情報を前記サーバから前記ページ要求元のクライアントに送信し、
他のクライアントで表示中の場合には、要求されたページ情報に代えて、特定のイベント要求を行わせるための特定イベント要求情報が設定された特定ページ情報を前記サーバから前記ページ要求元のクライアントに送信して、当該クライアントでの要求されたページ情報の表示を待たせ、
前記排他ページの表示状態にあった前記クライアントに対する前記サーバからのイベント通知に用いられるネットワーク接続が切断され、且つ前記排他ページの表示の待ち状態にあるクライアントが存在する場合には、前記サーバから、その待ち状態にあるいずれか１つのクライアントに、前記要求されたページ情報の中に前記イベント要求情報が設定された新たなページ情報を前記特定イベント要求に対する応答として送信することを特徴とする請求項２または請求項３記載のリアルタイム情報配信方法。