(57)【要約】【課題】ファイアウォール等の設定変更なしに、インターネット側からＬＡＮ側へのイベント通知を円滑かつ効率的に行う。【解決手段】イベント中継サーバ装置２は、イベント通知装置３からイベント情報を受信し、イベント受信装置１から、イベント情報の送信を要求するリクエストを受信する。イベント中継サーバ装置２は、リクエストを受信した際に、イベント受信装置１に対するイベント情報を受信しているか否かを判断し、イベント受信装置１に対する通知情報を受信している場合に当該イベント情報を含むリプライを生成する。イベント情報を受信していない場合に、一定期間の経過前にイベント情報が受信された場合に当該イベント情報の受信に応答して当該イベント情報を含むリプライを直ちに生成し、一定時間経過後も受信しない場合に、イベント情報が存在しない旨のリプライを生成し、生成したリプライをルータ装置５を介してイベント受信装置１に送信する。【選択図】図１
2007335960.tif 000002
【特許請求の範囲】
【請求項１】
通知情報を発信する一つ以上の通知情報発信装置と、通知情報を取得する情報取得装置と通信を行う情報提供装置であって、
それぞれの通知情報発信装置から通知情報を受信する通知情報受信部と、
通知情報の送信を要求するリクエストを前記情報取得装置から受信するリクエスト受信部と、
前記リクエスト受信部が前記情報取得装置からのリクエストを受信した際に、前記情報取得装置に対する通知情報が受信されているか否かを判断し、前記情報取得装置に対する通知情報が受信されていない場合にいずれかの通知情報発信装置からの通知情報の受信を待ち、一定期間の経過前に前記情報取得装置に対する通知情報が受信された場合に当該通知情報の受信に応答して当該通知情報を含むリプライを生成し、一定時間を経過しても前記情報取得装置に対する通知情報が受信されない場合に、前記情報取得装置に対する通知情報が存在しない旨のリプライを生成するリプライ生成部と、
前記リプライ生成部により生成されたリプライを前記情報取得装置に対して送信するリプライ送信部とを有することを特徴とする情報提供装置。
【請求項２】
前記情報提供装置は、
外部からの情報取得装置へのアクセスを遮断する中継装置の外部に配置され、前記中継装置を介して前記情報取得装置と通信を行い、
前記リクエスト受信部は、
前記中継装置がリプライとしてならば外部からのデータの通過を許可する通信プロトコルの形式で生成されたリクエストを前記中継装置を介して前記情報取得装置から受信し、
前記リプライ生成部は、
前記通信プロトコルの形式でリプライを生成することを特徴とする請求項１に記載の情報提供装置。
【請求項３】
前記リクエスト受信部は、
ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコル及びＨＴＴＰＳ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｏｖｅｒ  Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）プロトコルのいずれかの形式で生成されたリクエストを受信し、
前記リプライ生成部は、
ＨＴＴＰプロトコル及びＨＴＴＰＳプロトコルのいずれかの形式でリプライを生成することを特徴とする請求項２に記載に情報提供装置。
【請求項４】
前記通知情報受信部は、
通知情報発信装置で発生したイベント及び通知情報発信装置が管理する機器で発生したイベントの少なくともいずれかを通知するイベント通知情報をそれぞれの通知情報発信装置から受信し、
前記リプライ生成部は、
前記通知情報受信部で受信されたイベント通知情報を含むリプライを生成することを特徴とする請求項１に記載の情報提供装置。
【請求項５】
前記リクエスト受信部は、
複数の情報取得装置からリクエストを受信し、
前記通知情報受信部は、
それぞれの通知情報発信装置から、通知情報の仮の送信先を示す仮送信先識別情報が付加された通知情報を受信し、
前記情報提供装置は、更に、
前記通知情報受信部により受信された通知情報に付加された仮送信先識別情報を解析し、当該通知情報の送信先を決定する送信先決定部を有し、
前記リプライ生成部は、
前記送信先決定部により送信先として決定された情報取得装置からのリクエストに対して当該通知情報を含むリプライを生成することを特徴とする請求項１に記載の情報提供装置。
【請求項６】
前記リクエスト受信部は、
複数の情報取得装置からリクエストを受信し、
前記通知情報受信部は、
それぞれの通知情報発信装置から、複数種類の通知情報を受信し、
前記情報提供装置は、更に、
前記通知情報受信部により受信された通知情報の種類を解析し、当該通知情報の送信先を決定する送信先決定部を有し、
前記リプライ生成部は、
前記送信先決定部により送信先として決定された情報取得装置からのリクエストに対して当該通知情報を含むリプライを生成することを特徴とする請求項１に記載の情報提供装置。
【請求項７】
前記通知情報受信部は、
それぞれの通知情報発信装置から、複数種類の通知情報を受信し、
前記送信先決定部は、
前記通知情報受信部により受信された通知情報に付加された仮送信先識別情報と当該通知情報の種類とを解析し、当該通知情報の送信先を決定することを特徴とする請求項５に記載の情報提供装置。
【請求項８】
前記送信先決定部は、
通知情報の送信先を決定するとともに、当該通知情報のデータ変換を行うか否かを決定し、
前記リプライ生成部は、
前記送信先決定部によりいずれかの通知情報のデータ変換を行うと決定された場合に、当該通知情報のデータ変換を行ってデータ変換後の通知情報を含むリプライを生成することを特徴とする請求項５〜７のいずれかに記載の情報提供装置。
【請求項９】
前記送信先決定部は、
仮送信先識別情報を解析した結果、仮送信先識別情報に送信先として示された情報取得装置以外の情報取得装置にも当該通知情報を同報送信するか否かを決定し、
前記リプライ生成部は、
前記送信先決定部により通知情報を二以上の情報取得装置に対して同報送信すると決定された場合に、同報送信の対象となる二以上の情報取得装置からのリクエストに対して当該通知情報を含むリプライを生成することを特徴とする請求項５に記載の情報提供装置。
【請求項１０】
前記送信先決定部は、
通知情報の種類を解析した結果、当該通知情報を二以上の情報取得装置に対して同報送信するか否かを決定し、
前記リプライ生成部は、
前記送信先決定部により通知情報を二以上の情報取得装置に対して同報送信すると決定された場合に、同報送信の対象となる二以上の情報取得装置からのリクエストに対して当該通知情報を含むリプライを生成することを特徴とする請求項６に記載の情報提供装置。
【請求項１１】
通知情報を発信する一つ以上の通知情報発信装置と、通知情報を取得する情報取得装置と通信を行う情報提供方法であって、
それぞれの通知情報発信装置から通知情報を受信する通知情報受信ステップと、
通知情報の送信を要求するリクエストを前記情報取得装置から受信するリクエスト受信ステップと、
前記リクエスト受信ステップが前記情報取得装置からのリクエストを受信した際に、前記情報取得装置に対する通知情報が受信されているか否かを判断し、前記情報取得装置に対する通知情報が受信されていない場合にいずれかの通知情報発信装置からの通知情報の受信を待ち、一定期間の経過前に前記情報取得装置に対する通知情報が受信された場合に当該通知情報の受信に応答して当該通知情報を含むリプライを生成し、一定時間を経過しても前記情報取得装置に対する通知情報が受信されない場合に、前記情報取得装置に対する通知情報が存在しない旨のリプライを生成するリプライ生成ステップと、
前記リプライ生成ステップにより生成されたリプライを前記情報取得装置に対して送信するリプライ送信ステップとを有することを特徴とする情報提供方法。
【請求項１２】
通知情報を発信する一つ以上の通知情報発信装置と、通知情報を取得する情報取得装置と通信を行うコンピュータに、
それぞれの通知情報発信装置から通知情報を受信する通知情報受信処理と、
通知情報の送信を要求するリクエストを前記情報取得装置から受信するリクエスト受信処理と、
前記リクエスト受信処理が前記情報取得装置からのリクエストを受信した際に、前記情報取得装置に対する通知情報が受信されているか否かを判断し、前記情報取得装置に対する通知情報が受信されていない場合にいずれかの通知情報発信装置からの通知情報の受信を待ち、一定期間の経過前に前記情報取得装置に対する通知情報が受信された場合に当該通知情報の受信に応答して当該通知情報を含むリプライを生成し、一定時間を経過しても前記情報取得装置に対する通知情報が受信されない場合に、前記情報取得装置に対する通知情報が存在しない旨のリプライを生成するリプライ生成処理と、
前記リプライ生成処理により生成されたリプライを前記情報取得装置に対して送信するリプライ送信処理とを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲートウェイ装置を介してインターネットに接続しているＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続した装置に対して、インターネットに接続している装置から情報を提供する技術に関する。
【背景技術】
【０００２】
ゲートウェイ装置を介して、ＬＡＮに接続した装置（端末装置）に対して、インターネットに接続した装置（サーバ装置）からアクセスをするには様々な制限がある。
【０００３】
例えば、端末装置がグローバルＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスを持たず、ローカルＩＰアドレスしか持たない場合、ゲートウェイ装置（ルータ）が、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）機能やＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）機能を用いて、ＩＰアドレスやポート番号の変換を行う技術がある。
ＮＡＴ機能やＮＡＰＴ機能により、端末装置のＩＰアドレスやポート番号の変換を行う場合、端末装置からのリクエストによって、サーバ装置は、端末装置のＩＰアドレスやポート番号を知る。したがって、サーバ装置側から、能動的に端末装置にアクセスすることは困難である。
また、ＮＡＰＴテーブルを持つルータによってＮＡＰＴ内のＬＡＮに接続された端末装置とＮＡＰＴ外のインターネットに接続されたサーバ装置が通信する場合、インターネット側からＬＡＮ側へイベント通知するためには、明示的にＮＡＰＴテーブルをインターネット側からＬＡＮ側へのアクセス許可の設定をする必要がある。
このような設定をしなくても、上記のアクセスを可能とするための技術として、特許文献１に記載の方法がある。
特許文献１では、ＬＡＮ側の端末側から定期的にインターネット側のサーバ装置にパケットを送信し、本通信において、自動的に、一定期間の間、設定されるルータのマッピングテーブルを利用することによって、インターネット側のサーバからＬＡＮ側へのアクセスを行う事によってイベントを通知する。
【０００４】
また、セキュリティ上の観点から、ゲートウェイ装置が、サーバ装置から端末装置へのアクセスを制限する技術（いわゆるファイアウォール）がある。
ファイアウォール技術には、様々なものがあるが、端末装置からサーバ装置へのアクセス及びそれに対するサーバ装置からの応答は許可し、それ以外のサーバ装置から端末装置へのアクセスは制限するという方式が、広く行われている。
【特許文献１】特開２００４−１２０５４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の技術は、サーバ装置から端末装置へのアクセスにＵＤＰ（Ｕｓｅｒ
Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）を用いている。
しかし、ＵＤＰには、通信開始等の手続がないので、端末装置とサーバ装置とのどちらから通信を始めたのか判別することは難しい。
したがって、ファイアウォール技術において、ＵＤＰによる通信を一律に制限する場合があり、特許文献１の方法では、利用可能な環境が制限されるという問題点があった。例えば、企業などにおいては、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰＳ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｏｖｅｒ  Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）のみを認めるＷｅｂプロキシ経由でＬＡＮ側の端末からインターネット側のサーバへアクセスする環境では、本手法は利用できなという問題がある。
また、イベントのように、状況によっては通知先の変更や、複数の通知先へのイベント通知、さらには、状況に応じたイベント内容の変更などが必要になる場合に、本手法では対応出来ないという問題がある。
【０００６】
この発明は、上記のような問題点を解決することを主な目的とし、Ｗｅｂアクセスが可能な環境であれば、既に設定されているセキュリティを保持し、ルータの設定などの変更も不要でインターネット側のサーバからＬＡＮ側への即時のイベント通知を実現することを主な目的とする。また、イベントの内容によって、その送信先を変更することも主な目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る情報提供装置は、
通知情報を発信する一つ以上の通知情報発信装置と、通知情報を取得する情報取得装置と通信を行う情報提供装置であって、
それぞれの通知情報発信装置から通知情報を受信する通知情報受信部と、
通知情報の送信を要求するリクエストを前記情報取得装置から受信するリクエスト受信部と、
前記リクエスト受信部が前記情報取得装置からのリクエストを受信した際に、前記情報取得装置に対する通知情報が受信されているか否かを判断し、前記情報取得装置に対する通知情報が受信されていない場合にいずれかの通知情報発信装置からの通知情報の受信を待ち、一定期間の経過前に前記情報取得装置に対する通知情報が受信された場合に当該通知情報の受信に応答して当該通知情報を含むリプライを生成し、一定時間を経過しても前記情報取得装置に対する通知情報が受信されない場合に、前記情報取得装置に対する通知情報が存在しない旨のリプライを生成するリプライ生成部と、
前記リプライ生成部により生成されたリプライを前記情報取得装置に対して送信するリプライ送信部とを有することを特徴とする。
【発明の効果】
【０００８】
本発明では、リクエストに対して、即座にリプライを返すのではなく、リクエストの受信後、通知情報の受信を待ち、一定期間の経過前に通知情報が受信された場合に当該通知情報の受信に応答して、直ちに、当該通知情報を含むリプライを送信するため、通知情報の受信後直ちに情報取得装置に通知情報を送信することができる。
【発明を実施するための最良の形態】
【０００９】
実施の形態１．
図１は、この実施の形態における通信システムの全体構成の一例を示すシステム構成図である。
本実施の形態に係る通信システムは、イベント受信装置１、ルータ装置５、イベント中継サーバ装置２、イベント通知装置３を有する。イベント受信装置１は、情報取得装置の例である。ルータ装置５は中継装置の例である。イベント中継サーバ装置２は情報提供装置の例である。イベント通知装置３は通知情報発信装置の例である。
【００１０】
ルータ装置５、イベント中継サーバ装置２、イベント通知装置３は、インターネット４に接続しており、相互に通信することができる。
イベント受信装置１は、ＬＡＮを介してルータ装置５に接続しており、ルータ装置５を経由することにより、インターネット４に接続し、インターネット４に接続した装置（例えば、イベント中継サーバ装置２）と通信することができる。
【００１１】
ルータ装置５は、ファイアウォール機能を有している。
ルータ装置５は、イベント受信装置１からインターネット側の装置（例えば、イベント中継サーバ装置２）に対する通信を許可する。また、それに対する応答として、インターネット側の装置からイベント受信装置１への通信も許可する。しかし、イベント受信装置１からの通信に対する応答でない通信は、禁止する。
したがって、イベント受信装置１からイベント中継サーバ装置２へのアクセスは可能であるが、イベント中継サーバ装置２からイベント受信装置１へのアクセスは許可しない。
【００１２】
また、ルータ装置５は、ＮＡＰＴ機能を有している。
ルータ装置５は、ＬＡＮ内でのみ有効なイベント受信装置１のローカルＩＰアドレスを、ＮＡＰＴ機能によって変換し、インターネット側の装置と接続する。
【００１３】
イベント通知装置３は、図１では１台しか表示されていないが、複数台存在するものとする。
イベント通知装置３は、各種イベントを通知するイベント通知情報（以下、イベント情報という）をイベント中継サーバ装置２に送信する。イベント通知装置３は、別途、イベントを発生する機器とＬＡＮや独自のネットワーク等で接続した形式でもよい。
例えば、冷熱機器システムにおいては、イベント通知機能は、冷熱機器（例えば、エアコンの室内機や室外機）そのものに内在していてもよいし、冷熱機器を統合的に管理制御する冷熱機器コントローラに内在していてもよい。後者の場合は、異常などのイベントは冷熱機器そのものが発生させるか、あるいは冷熱機器コントローラが冷熱機器の状態を監視してイベントを発生させる場合がある。なお、この場合、冷熱機器コントローラは独自のネットワークで各冷熱機器と接続し、冷熱機器コントローラは、ＬＡＮ等にてルータ装置を経由してインターネット上のイベント中継サーバ装置２に接続する事になる。また、１つのイベント通知装置（例えば、冷熱機器コントローラなど）に複数のイベント発生装置（例えば、冷熱機器）が接続した形態であってもよい。
同様に、給湯器システム、床暖房システム、照明システム、エレベータシステム、オール電化システム、セキュリティシステム、監視カメラシステムあるいはＦＡシステムなどの各機器と各制御コントローラも同関係であってもよい。
【００１４】
イベント中継サーバ装置２は、イベント通知装置３からのイベント情報をルータ装置５を介して、イベント受信装置１に送信する。
【００１５】
イベント受信装置１は、その受信したイベント情報を表示する装置と接続されていてもよいし、別途、メールシステムなどと連携して、受信したイベントを別途設定するあて先にメールを送信してもよい。また、イベント受信装置１は、イベント情報を蓄積し、Ｗｅｂサーバ機能などと連携し、たくわえたイベント内容をＷｅｂクライアントなどから確認できるように構成してもよい。
【００１６】
次に、図３を用いて、本実施の形態に係る通信システムの動作を概説する。
本実施の形態では、イベント中継サーバ装置２（情報提供装置）が、イベント情報（通知情報）を発信する一つ以上のイベント通知装置３（通知情報発信装置）と接続され、また、イベント情報を取得するイベント受信装置１（情報取得装置）とルータ装置５を介して接続される。
そして、イベント中継サーバ装置２は、それぞれのイベント通知装置３からイベント情報を受信し、また、イベント受信装置１からは、イベント情報の送信を要求するリクエストを受信する。図３に示すように、イベント受信装置１は、イベント中継サーバ装置２からのリプライを受信する度にリクエストを送信し、イベント中継サーバ装置２に対して連続的にリクエストを送信する。
イベント中継サーバ装置２は、イベント受信装置１からのリクエストを受信した際に、イベント受信装置１に対するイベント情報を受信しているか否かを判断し、イベント受信装置１に対する通知情報を受信している場合に当該イベント情報を含むリプライを生成し、生成したリプライをルータ装置５を介してイベント受信装置１に送信する。
他方、イベント受信装置１に対するイベント情報を受信していない場合にいずれかのイベント通知装置３からのイベント情報の受信を待ち、一定期間の経過前にイベント受信装置１に対するイベント情報が受信された場合に当該イベント情報の受信に応答して直ちに当該イベント情報を含むリプライを生成し、生成したリプライをルータ装置５を介してイベント受信装置１に送信する。
また、一定時間を経過してもイベント受信装置１に対するイベント情報が受信されない場合に、イベント受信装置１に対するイベント情報が存在しない旨のリプライを生成し、生成したリプライをルータ装置５を介してイベント受信装置１に送信する。
イベント受信装置１では、イベント情報を受信した場合は、イベント情報に対する所定の処理を行う。
図３の例では、リクエスト（１）、（２）、（ｎ）及び（ｎ＋２）に対する応答であるリプライ（１）、（２）、（ｎ）及び（ｎ＋２）はイベント情報なしとのリプライであり、リクエスト（ｎ＋１）に対する応答であるリプライ（ｎ＋１）は、イベント情報が含まれるリプライである。
なお、イベント中継サーバ装置２の構成要素である端末アクセス受信部１０及びイベント受信中継部１３については後述する。
【００１７】
図２は、実施の形態におけるイベント受信装置１、イベント中継サーバ装置２、イベント通知装置３の機能ブロックの構成の一例を示すブロック構成図である。
なお、図２では、ルータ装置５、ＬＡＮ、インターネット４は省略されている。
【００１８】
イベント受信装置１は、サーバアクセス部６、イベント受信制御部７、イベント情報解析部８、イベント受信部９を有する。
【００１９】
サーバアクセス部６は、イベント中継サーバ装置２と通信する。通信のプロトコルには、ＨＴＴＰ又はＨＴＴＰＳを用いるが、通常のゲートウェイ装置、ファイアウォールやプロキシで通過が許可されているプロトコルであれば、他のプロトコルを用いてもよい。
イベント受信制御部７は、イベント中継サーバ装置２に対してイベント情報の送信を要求するリクエストを生成する。
イベント情報解析部８は、サーバアクセス部６により受信されたイベント中継サーバ装置２からのリプライを解析し、リプライにイベント情報が含まれているかを判断する。
イベント受信部９は、イベント情報解析部８によりリプライにイベント情報が含まれていると判断された場合に、イベント情報解析部８からイベント情報を受信し、イベント情報に対する処理を行う。例えば、上述したように、イベント情報の表示や、所定の宛先へのメール送信等を行う。
【００２０】
イベント中継サーバ装置２は、端末アクセス受信部１０、イベント確認部１１、イベント受信中継部１３を有する。
端末アクセス受信部１０は、イベント受信装置１から、イベント情報の送信を要求するリクエストを受信する。
イベント受信中継部１３は、複数のイベント通知装置３のそれぞれからイベント情報を受信する。
イベント確認部１１は、端末アクセス受信部１０が、イベント受信装置１からのリクエストを受信した際に、イベント受信中継部１３が、イベント受信装置１に対するイベント情報を受信しているか否かを判断する。イベント受信装置１に対するイベント情報を受信している場合に当該イベント情報を含むリプライを生成する。他方、イベント受信装置１に対するイベント情報を受信していない場合にいずれかのイベント通知装置３からのイベント情報の受信を待ち、一定期間の経過前にイベント受信装置１に対するイベント情報が受信された場合に当該イベント情報の受信に応答して直ちに当該イベント情報を含むリプライを生成し、一定時間を経過してもイベント受信装置１に対するイベント情報が受信されない場合に、イベント受信装置１に対するイベント情報が存在しない旨のリプライを生成する。
また、端末アクセス受信部１０は、イベント確認部１１により生成されたリプライをルータ装置５を介してイベント受信装置１に送信する。
端末アクセス受信部１０は、リクエスト受信部及びリプライ送信部の例である。イベント確認部１１は、リプライ生成部の例である。イベント受信中継部１３は、通知情報受信部の例である。
【００２１】
イベント通知装置３は、イベント通知部１４を有する。
イベント通知部１４は、イベント通知装置３で発生したイベント及びイベント通知装置３が管理する機器（例えば、上述の冷熱機器等）で発生したイベントの少なくともいずれかを通知するイベント情報をイベント中継サーバ装置２に送信する。
【００２２】
ここで、本実施の形態に係るイベント受信装置１、イベント中継サーバ装置２、イベント通知装置３及びルータ装置５のハードウェア構成例について説明する。
図１５は、本実施の形態及び以下に述べる実施の形態に示すイベント受信装置１、イベント中継サーバ装置２、イベント通知装置３及びルータ装置５のハードウェア資源の一例を示す図である。
図１５において、イベント受信装置１、イベント中継サーバ装置２、イベント通知装置３及びルータ装置５は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。
【００２３】
通信ボード９１５は、図１に示すように、インターネット又はＬＡＮに接続されている。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【００２４】
上記プログラム群９２３には、本実施の形態及び以下に述べる実施の形態の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、以下に述べる説明において、「〜の判定結果」、「〜の計算結果」、「〜の処理結果」、「〜の評価結果」等として説明している情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、以下で説明するフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００２５】
また、本実施の形態及び以下に述べる実施の形態の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」、「手段」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、本実施の形態及び以下に述べる実施の形態の「〜部」としてコンピュータを機能させるものである。あるいは、本実施の形態及び以下に述べる実施の形態の「〜部」の手順や方法をコンピュータに実行させるものである。
【００２６】
このように、本実施の形態及び以下に述べる実施の形態に示すイベント受信装置１、イベント中継サーバ装置２、イベント通知装置３及びルータ装置５は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【００２７】
次に、イベント受信装置１の動作について、図４のフローチャート図を用いて説明する。
Ｓ４０１で、サーバアクセス部６は、イベント中継サーバ装置２に対してＨＴＴＰあるいはＨＴＴＰアクセスして、リクエストに対するリプライを得る。
Ｓ４０２で、イベント情報解析部８がこのリプライのデータを解析し、イベント情報が含まれているかどうかを判断する。イベント情報が含まれていない場合は、イベント受信制御部７により再度Ｓ１に戻る。イベント情報があれば、イベント情報解析部８はイベント受信部９にイベント情報を渡す。
次に、Ｓ４０３で、イベント受信部９は得たイベント情報を処理する。その後再度、Ｓ１に戻る。
【００２８】
次に、イベント中継サーバ装置２の動作例（情報提供方法）を図５及び図６を参照して説明する。
【００２９】
先ずは、イベント中継サーバ装置２のイベント受信中継部１３の動作例を図５のフローチャートを用いて説明する。
先ず、Ｓ５０１において、イベント受信中継部１３は、イベント通知装置３からイベント情報を受信する（通知情報受信ステップ）。
次に、Ｓ５０２において、イベント受信中継部１３は、イベント確認部１１にイベント情報の受信を通知し、受信したイベント情報をイベント確認部１１に渡す。イベント確認部１１では、イベント受信中継部１３から受け取ったイベント情報を所定のバッファメモリに記憶する。
【００３０】
次に、イベント中継サーバ装置２の端末アクセス受信部１０及びイベント確認部１１の動作例について、図６のフローチャートを用いて説明する。
Ｓ６０１で、イベント中継サーバ装置２では、端末アクセス受信部１０がイベント受信装置１からのアクセス（ＨＴＴＰリクエスト、ＨＴＴＰＳリクエスト）を受ける（リクエスト受信ステップ）。
次に、Ｓ６０２で、イベント確認部１１は、既に、イベント受信中継部１３から、当該イベント受信装置１宛のイベント情報を受け取っているか否か、すなわち当該イベント受信装置１宛のイベント情報がバッファメモリに記憶されているか否かを判断し（リプライ生成ステップ）、既にイベント情報を受け取っている場合は、イベント確認部１１は、ステップＳ６０６に進み、該当するイベント情報を付加してリプライを生成し（リプライ生成ステップ）、端末アクセス受信部１０が当該リプライをルータ装置５を介してイベント受信装置１に送信する（リプライ送信ステップ）。
一方、Ｓ６０２において、イベント受信装置１宛のイベント情報が未受信と判断された場合は、Ｓ６０３で、イベント確認部１１が、Ｓ６０１のリクエストの受信から一定時間が経過するか、あるいはイベント受信中継部１３からイベント情報の受信の通知があるまで待つ（リプライ生成ステップ）。
ここで、イベント確認部１１が、イベント受信中継部１３からイベント情報を受け取っていない場合、つまり、一定時間たった場合（Ｓ６０４でＮｏの場合）は、Ｓ６０５に進み、イベント確認部１１は、イベント情報なしのリプライを生成し端末アクセス受信部１０が当該リプライをルータ装置５を介してイベント受信装置１に送信する（リプライ送信ステップ）。その後、処理は、Ｓ６０１に戻る。
他方、一定期間内にイベント確認部１１がイベント受信中継部１３からイベント情報を受け取った場合（Ｓ６０４でＮｏの場合）は、Ｓ６０６に進み、直ちに、該当するイベント情報を付加してリプライを生成し（リプライ生成ステップ）、端末アクセス受信部１０が当該リプライをルータ装置５を介してイベント受信装置１に送信する（リプライ送信ステップ）。
【００３１】
このように、本実施の形態では、イベント中継サーバ装置２の端末アクセス受信部１０及びイベント確認部１１は、イベント受信装置１に対するイベント情報を受信していない場合に、リクエストに対して、即座にリプライを返すのではなく、一定時間の間、イベント受信中継部１３がイベント情報を受信するかどうかを待ち、イベント受信中継部１３がイベント情報を受信したら、直ちに、イベント情報が含まれるリプライを返すので、イベントの即時通知が可能となる。
通常のポーリング方式と呼ばれる、リクエストを受けてレスポンスを即返し、イベント受信装置側で一定時間まって、リクエストを送信する方法では、この即時通知ができない。
【００３２】
また、イベント受信装置は、ＮＡＰＴルータあるいはＷｅｂプロキシを越えてイベント中継サーバ装置２と通信を行うが、イベント中継サーバ装置２からは、リクエスト・リプライのリプライでしかイベント情報の送信をしないので、イベント情報はＮＡＰＴルータあるいはＷｅｂプロキシを通過できる。
つまり、イベント受信装置１とイベント中継サーバ装置２間の通信はすべて、イベント受信装置１からイベント中継サーバ装置２へのＨＴＴＰあるいはＨＴＴＰＳのアクセスおよびそのリプライで実現しているため、ＮＡＰＴルータやＷｅｂプロキシ経由でのアクセスであっても端末とサーバ間の通信は可能である。
また、この通信により、イベント情報は、イベント中継サーバ装置からイベント受信装置へ渡す事ができる。
なお、本実施の形態では、イベント受信装置１からＨＴＴＰプロトコル又はＨＴＴＰＳプロトコルに従ったリクエストを送信する例を説明したが、ルータ装置５がリプライとしてならば外部からのデータの通過を許可する通信プロトコルの形式で生成されたリクエストならば他の形式でもよい。そして、イベント中継サーバ装置２は、当該通信プロトコルの形式でリプライを生成する。
【００３３】
また、イベント受信装置からイベント中継サーバ装置へは、常時接続しているように見えるため、即時のイベント通知が可能である。これは、イベント受信装置からイベント中継サーバ装置にＨＴＴＰあるいはＨＴＴＰＳアクセスし、一定期間の間接続した状態にしておき、一旦リプライを返す。その後、即座にイベント受信装置からイベント中継サーバ装置にアクセスすることを行う事により、常時接続しているのと同じ効果をもたらしている。そのため、本当に常時接続した場合には、途中のルータ装置５等が無通信状態と判断して自動的にＴＣＰセッションを切断する場合があるが、この実施の形態では、そのような事態は発生しない。また、その無通信時の自動セッション断を防ぐための定期的な通信（ＫｅｅｐＡｌｉｖｅ）も不要である。
【００３４】
以上、本実施の形態では、以下の手段を備えたイベント受信装置について説明した。
（ａ）イベント中継サーバ装置に対して、ＨＴＴＰあるいはＨＴＴＰＳプロトコルにより、イベント受信装置識別情報を送信し、そのリプライとしてデータを受信し、そのデータをイベント情報解析手段に渡すサーバアクセス手段、
（ｂ）サーバアクセス手段から渡されたデータを解析し、イベント情報の有無を判断し、イベント情報を含む場合、イベント受信手段にそのイベント情報を渡すイベント情報解析手段、また、イベント情報を含まない場合は何もしないイベント情報解析手段、
（ｃ）上記処理を繰り返し行うように制御するイベント受信制御手段、
（ｄ）イベントを受けて処理するイベント受信手段。
【００３５】
また、本実施の形態では、以下の手段を備えたイベント中継サーバ装置について説明した。
（ａ）イベント受信装置から、ＨＴＴＰあるいはＨＴＴＰＳプロトコルにより、イベント受信装置識別情報を受信したあと、イベント確認手段からのイベント情報を受け、そのイベント情報を、同受信データのリプライとして、イベント受信装置に返す端末アクセス受信手段、
（ａ−２）上記で、イベント確認手段からのイベント通知が、別途定めた時間の間なかった場合は、そのイベント情報を載せずに、同受信データのリプライとして、イベント受信装置に返す端末アクセス受信手段。
【００３６】
また、本実施の形態に係る中継サーバ装置は、更に、以下の手段を備えていることを説明した。
（ａ）イベント受信中継手段から、イベント送信先のイベント受信装置識別情報とイベント情報を受け、当該イベント受信装置識別情報で示されるイベント受信装置からのアクセスを受けている端末アクセス受信手段に対して、イベント情報を通知する、イベント確認手段、
（ｂ）イベント通知装置のイベント通知手段、イベント送信先のイベント受信装置識別情報とイベント情報を受け取り、イベント確認手段に渡すイベント受信中継手段。
【００３７】
また、本実施の形態では、以下の手段を備えたイベント通知装置について説明した。
（ａ）イベント送信先のイベント受信装置識別情報とイベント情報を、イベント中継サーバ装置のイベント中継手段に送信するイベント通知手段。
【００３８】
実施の形態２．
以上の実施の形態１では、イベント通知装置３が指定したイベント送信先のイベント受信装置１に、指定されたイベント内容をそのままイベント通知したものであるが、イベント通知先の変更や、イベント通知のドロップあるいは、複数先へのイベントの同時通知、あるいはイベント内容を変更したイベント通知を行う実施の形態を示す。
【００３９】
図７は、本実施の形態に係るシステム構成例を示している。
図７では、図１と異なり、イベント受信装置１が複数存在する。これ以外の点は、図１と同様である。各イベント受信装置１のｔｅｒｍｘｘとは、イベント受信装置１の識別番号である。
【００４０】
図２は、実施の形態におけるイベント受信装置１、イベント中継サーバ装置２、イベント通知装置３の機能ブロックの構成の一例を示すブロック構成図である。
なお、図５では、ルータ装置５、ＬＡＮ、インターネット４は省略されている。
図８では、図２と比較して、イベント通知先決定部１２とイベント通知ルールテーブル１５が追加されている。これ以外の点は、図２と同様である。
なお、イベント通知先決定部１２は送信先決定部の例である。
【００４１】
図８において、図２との違いは、イベント確認部１１が、イベント受信中継部１３から得たイベント送信先のイベント受信装置識別情報とイベント情報から、そのまま、該当するイベント受信装置向けのリプライを生成するのではなく、一旦、これらの情報を、イベント通知先決定部１２に渡して、その、結果から得られる、０個以上のイベント送信先に対して、かつ、結果から得たイベント情報を含むリプライを生成する点である。
したがって、イベント送信先が０の場合は、当該イベント情報はドロップ、つまりはどのイベント受信装置１にもイベント通知されない。
イベント送信先が１個の場合は、イベント情報がその送信先に通知される。
また、イベント送信先が２個以上の場合は、イベント情報は、それぞれの送信先に複製されて同報される。
【００４２】
本実施の形態では、イベント受信中継部１３（通知情報受信部）は、複数のイベント通知装置３（通知情報発信装置）のそれぞれから、イベント情報の仮の送信先を示す仮イベント通知先情報（仮送信先識別情報）が付加されたイベント情報を受信する。
そして、イベント通知先決定部１２（送信先決定部）は、イベント情報に付加された仮イベント通知先情報を解析し、当該イベント情報の送信先を決定する。イベント通知先決定部１２は、例えば、仮イベント通知先情報を解析した結果、仮イベント通知先情報に送信先として示されたイベント受信装置１以外のイベント受信装置１にも当該イベント情報を同報送信するか否かを決定する。
そして、イベント確認部１１（リプライ生成部）は、イベント通知先決定部１２によりイベント情報を二以上のイベント受信装置１に対して同報送信すると決定された場合に、同報送信の対象となる二以上のイベント受信装置１からのリクエストに対して当該イベント情報を含むリプライを生成する。
【００４３】
また、イベント受信中継部１３は、複数のイベント通知装置３のそれぞれから、複数種類のイベント情報を受信し、イベント通知先決定部１２は、イベント情報の種類を解析し、当該イベント情報の送信先を決定する。イベント通知先決定部１２は、例えば、イベント情報の種類を解析した結果、当該イベント情報を二以上のイベント受信装置１に対して同報送信するか否かを決定する。
そして、イベント確認部１１は、イベント通知先決定部１２によりイベント情報を二以上のイベント受信装置１に対して同報送信すると決定された場合に、同報送信の対象となる二以上のイベント受信装置１からのリクエストに対して当該イベント情報を含むリプライを生成する。
【００４４】
また、イベント通知先決定部１２は、イベント情報に付加された仮イベント通知先情報と当該イベント情報の種類とを解析し、当該イベント情報の送信先を決定する場合もある。
【００４５】
更に、イベント通知先決定部１２は、イベント情報の送信先を決定するとともに、当該イベント情報のデータ変換を行うか否かを決定し、イベント確認部１１は、イベント通知先決定部１２によりいずれかのイベント情報のデータ変換を行うと決定された場合に、当該イベント情報のデータ変換を行ってデータ変換後のイベント情報を含むリプライを生成する。
【００４６】
本実施の形態では、イベント通知先決定部１２は、イベント情報を解析し、図９〜図１１のイベント通知ルールテーブルに従って、イベント情報の送信先を決定する。
【００４７】
図９は、イベント通知先決定部１２がイベント情報の送信先を決定する際に、参照するイベント通知ルールテーブルの例を示す。図９では、仮イベント通知先情報に基づいてイベント情報の送信先を決定する場合のイベント通知ルールテーブルの例を示す。
図９において、仮イベント送信先とは、仮イベント通知先情報であり、イベント情報の仮の送信先を示している。そして、実イベント送信先とは、イベント通知先決定部１２が、実際にイベント情報を送信する送信先として決定するイベント受信装置１を示す。なお、ｔｅｒｍｘｘは、イベント受信装置１の識別番号であり、図７に示すようにイベント受信装置１には各々識別番号が設定されている。
例えば、仮イベント送信先としてｔｅｒｍ１が指定された場合は実イベント送信先情報群としてｔｅｒｍ１を返し、仮イベント送信先としてｔｅｒｍ１ｘと指定された場合は、ｔｅｒｍ１０，ｔｅｒｍ１１，．．ｔｅｒｍ１ｎを返し、仮イベント送信先がｔｅｒｍ０の場合は、このイベント情報を送信しない。
【００４８】
図１０は、イベント情報の種類に基づいてイベント情報の送信先を決定する場合のイベント通知ルールテーブルの例を示す。
図１０では、ＩＮＦＯ、ＥＲＲＯＲ、ＦＡＴＡＬ、ＤＥＢＵＧ等のイベント情報の種類が示され、それぞれの種類に対して実イベント送信先が指定されている。
例えば、イベント情報がＩＮＦＯあるいはＩＮＦＯに該当する情報の場合は、実イベント送信先情報群としてｔｅｒｍ１を返し、ＥＲＲＯＲに該当する情報の場合は、ｔｅｒｍ１０，ｔｅｒｍ１１を返し、ＦＡＴＡＬの場合は、ｔｅｒｍ１０，ｔｅｒｍ１１．．．ｔｅｒｍ１ｎを返し、ＤＥＢＵＧの場合は、このイベントを送信しない。
【００４９】
図１１は、仮イベント通知先情報とイベント情報の種類の組み合わせに基づいてイベント情報の送信先を決定する場合のイベント通知ルールテーブルの例を示す。
また、図１１では、イベント情報に対して日本語変換、コード変換、データ圧縮等のデータ変換を行うか否かも示されている。
例えば、イベント情報がＩＮＦＯに該当する情報の場合で、仮イベント送信先がｔｅｒｍ１の場合は、実イベント送信先情報群としてｔｅｒｍ１，ｔｅｒｍ２を返し、当該イベント情報を日本語変換して送信する。また、イベント情報がＩＮＦＯに該当する情報の場合で、仮イベント送信先がｔｅｒｍ０の場合は、実イベント送信先情報群としてｔｅｒｍ１を返し、当該イベント情報のデータのコード変換をして送信する。また、ＤＥＢＵＧの場合は、イベント情報を圧縮して送信する。
【００５０】
次に、本実施の形態に係る動作（１：１のイベント通知）を図１２を参照して説明する。
イベント受信装置１（ｔｅｒｍ１，ｔｅｒｍ１０，ｔｅｒｍ１１，．．ｔｅｒｍ１ｎ）は、イベント中継サーバ装置２の端末アクセス受信部１０に対して、各々、リクエストを送信する。なお、図１２では、作図上の都合から、イベント受信装置１（ｔｅｒｍ１）とイベント中継サーバ装置２との間のリクエスト及びリプライしか示されていないが、各イベント受信装置１とイベント中継サーバ装置２との間でも同様にリクエスト及びリプライの送受信が行われているものとする。
イベント中継サーバ装置２の端末アクセス受信部１０は、実施の形態１と同様に、イベント情報を受信していない場合は、イベント受信装置１からのリクエストを一定時間保持してから、そのリプライを返す。
リプライを受けたイベント受信装置１は、再度リクエストを送信する。これを、繰り返す。
上記状態で、イベント通知装置３（ｔｅｒｍＸ）から、イベント情報（仮イベント送信先＝ｔｅｒｍ１）を、イベント中継サーバ装置２のイベント受信中継部１３が受信したとする。
イベント受信中継部１３は、実施の形態１と同様に、イベント確認部１１にイベント情報の受信を通知するとともに、当該イベント情報をイベント確認部１１に渡す。イベント確認部１１では、このイベント情報をイベント通知先決定部１２に渡す。
イベント通知先決定部１２は、イベント通知ルールテーブルを参照して、仮イベント送信先ｔｅｒｍ１に該当するイベント受信装置ｔｅｒｍ１を実イベント送信先として決定する（図１２では、図９のイベント通知ルールテーブルを利用する例を示している）。
イベント確認部１１は、イベント通知先決定部１２により決定されたイベント情報の送信先であるイベント受信装置１（ｔｅｒｍ１）に対するリプライ（イベント情報を含むリプライ）を生成する。
次に、端末アクセス受信部１０は、即時に（通常は一定時間接続を保持するが）、対応するイベント受信装置１（ｔｅｒｍ１）からのリクエストに対するリプライを送信する。これによって、イベント情報は、イベント通知装置（ｔｅｒｍＸ）からイベント受信装置１（ｔｅｒｍ１）に渡される。
【００５１】
次に、本実施の形態に係る動作（１：Ｎのイベント通知）を図１３を参照して説明する。
イベント受信装置１（ｔｅｒｍ１，ｔｅｒｍ１０，ｔｅｒｍ１１，．．ｔｅｒｍ１ｎ）は、イベント中継サーバ装置２の端末アクセス受信部１０に対して、各々、リクエストを送信する。なお、図１３では、作図上の都合から、一部のリクエスト及びリプライの送受信の状況しか示されていないが、各イベント受信装置１とイベント中継サーバ装置２との間で、図１２に示したように、連続してリクエスト及びリプライの送受信が行われているものとする。
ここで、イベント通知装置３（ｔｅｒｍＸ）から、イベント情報（仮イベント送信先＝ｔｅｒｍ１ｘ）を、イベント中継サーバ装置２のイベント受信中継部１３が受信したとする。
イベント受信中継部１３は、実施の形態１と同様に、イベント確認部１１にイベント情報の受信を通知するとともに、当該イベント情報をイベント確認部１１に渡す。イベント確認部１１では、このイベント情報をイベント通知先決定部１２に渡す。
イベント通知先決定部１２は、イベント通知ルールテーブルを参照して、仮イベント送信先ｔｅｒｍ１に該当するイベント受信装置１（ｔｅｒｍ１０．ｔｅｒｍ１１，．．ｔｅｒｍ１ｎ）を実イベント送信先として決定する（図１２では、図９のイベント通知ルールテーブルを利用する例を示している）。
イベント確認部１１は、イベント通知先決定部１２により決定されたイベント情報の送信先であるイベント受信装置１（ｔｅｒｍ１０．ｔｅｒｍ１１，．．ｔｅｒｍ１ｎ）に対するリプライ（イベント情報を含むリプライ）を生成する。
次に、端末アクセス受信部１０は、即時に（通常は一定時間接続を保持するが）、対応するイベント受信装置１（ｔｅｒｍ１０．ｔｅｒｍ１１，．．ｔｅｒｍ１ｎ）からのリクエストに対するリプライを同報送信する。これによって、イベント情報は、イベント通知装置（ｔｅｒｍＸ）からイベント受信装置１（ｔｅｒｍ１０．ｔｅｒｍ１１，．．ｔｅｒｍ１ｎ）に渡される。
【００５２】
なお、図１２、図１３では、図９のイベント通知ルールテーブルを利用する例を説明したが、図１０及び図１１のイベント通知ルールテーブルを利用する場合も同様の処理である。
【００５３】
次に、本実施の形態に係るイベント中継サーバ装置２の動作例を図１４のフローチャートを用いて説明する。
図１４において、Ｓ１４０１〜Ｓ１４０５は、図６のＳ６０１〜Ｓ６０５と同じなので、説明を省略する。
Ｓ１４０６では、イベント情報に示された仮イベント通知先情報、イベント情報の種類に基づき、図９〜図１１のイベント通知ルールテーブルに従って、イベント通知先決定部１２がイベント情報の送信先を決定する。
そして、Ｓ１４０７において、イベント確認部１１が、イベント通知先決定部１２によりイベント情報の送信先として決定されたイベント受信装置１からのリクエストに対してイベント情報を含むリプライを生成し、端末アクセス受信部１０がイベント情報を含むリプライを送信する。
【００５４】
このように、本実施の形態によれば、イベント通知先の変更や、イベント通知のドロップあるいは、複数先へのイベントの同時通知、あるいはイベント内容（データ形式）を変更したイベント通知が可能となる。
【００５５】
以上、本実施の形態では、以下の手段を持つイベント中継サーバ装置について説明した。
（ａ）イベント受信中継手段から得た、イベント送信先のイベント受信装置識別情報を、イベント通知先決定手段に渡して、新たなイベント送信先のイベント受信装置識別情報を得るイベント確認手段、
（ｂ）イベント確認手段から得たイベント送信先のイベント受信装置識別情報から、イベント通知ルールテーブルを検索し、新たな０個以上のイベント送信先のイベント受信装置識別情報を返すイベント通知先決定手段、
（ｃ）キーとなるイベント通知先情報（仮イベント通知先情報と呼ぶ）と、０個以上の新たなイベント通知先情報（実イベント通知先情報群と呼ぶ）の対応表を持つイベント通知ルールテーブル。
【００５６】
また、本実施の形態では、以下の手段を持つイベント中継サーバ装置について説明した。
（ａ）イベント受信中継手段から得た、イベント情報を、イベント通知先決定手段に渡して、新たなイベント送信先のイベント受信装置識別情報を得るイベント確認手段、
（ｂ）イベント確認手段から得たイベント情報から、イベント通知ルールテーブルを検索し、新たな０個以上のイベント送信先のイベント受信装置識別情報を返すイベント通知先決定手段、
（ｃ）キーとなるイベント情報と、０個以上の新たなイベント通知先情報（実イベント通知先情報群と呼ぶ）の対応表を持つイベント通知ルールテーブル。
【００５７】
また、以下の手段を持つイベント中継サーバ装置についても説明した。
（ａ）イベント受信中継手段から得た、イベント情報及び、あるいはイベント送信先のイベント受信装置識別情報を、イベント通知先決定手段に渡して、新たなイベント内容とイベント送信先のイベント受信装置識別情報を得るイベント確認手段、
（ｂ）イベント確認手段から得たイベント情報及び、あるいはイベント送信先のイベント受信装置識別情報から、イベント通知ルールテーブルを検索し、新たなイベント情報を返すイベント通知先決定手段、
（ｃ）キーとなるイベント情報及び、あるいはイベント送信先のイベント受信装置識別情報と、新イベント情報の対応表あるいはイベント置き換えルールを持つイベント通知ルールテーブル。
【図面の簡単な説明】
【００５８】
【図１】実施の形態１に係るシステム構成例を示す図。
【図２】実施の形態１に係るイベント受信装置、イベント中継サーバ装置、イベント通知装置の構成例を示すブロック図。
【図３】実施の形態１に係るイベント受信装置、イベント中継サーバ装置、イベント通知装置の動作の概要を示す図。
【図４】実施の形態１に係るイベント受信装置の動作例を示すフローチャート図。
【図５】実施の形態１に係るイベント中継サーバ装置の動作例を示すフローチャート図。
【図６】実施の形態１に係るイベント中継サーバ装置の動作例を示すフローチャート図。
【図７】実施の形態２に係るシステム構成例を示す図。
【図８】実施の形態２に係るイベント受信装置、イベント中継サーバ装置、イベント通知装置の構成例を示すブロック図。
【図９】実施の形態２に係るイベント通知ルールテーブルの例を示す図。
【図１０】実施の形態２に係るイベント通知ルールテーブルの例を示す図。
【図１１】実施の形態２に係るイベント通知ルールテーブルの例を示す図。
【図１２】実施の形態２に係るイベント受信装置、イベント中継サーバ装置、イベント通知装置の動作の概要を示す図。
【図１３】実施の形態２に係るイベント受信装置、イベント中継サーバ装置、イベント通知装置の動作の概要を示す図。
【図１４】実施の形態２に係るイベント中継サーバ装置の動作例を示すフローチャート図。
【図１５】実施の形態１、２に係るイベント受信装置、イベント中継サーバ装置、イベント通知装置、ルータ装置のハードウェア構成例を示す図。
【符号の説明】
【００５９】
１  イベント受信装置、２  イベント中継サーバ装置、３  イベント通知装置、４  インターネット、５  ルータ装置、６  サーバアクセス部、７  イベント受信制御部、８  イベント情報解析部、９  イベント受信部、１０  端末アクセス受信部、１１  イベント確認部、１２  イベント通知先決定部、１３  イベント受信中継部、１４  イベント通知部、１５  イベント通知ルールテーブル。
【図１】
2007335960.tif 000003
【図２】
2007335960.tif 000004
【図３】
2007335960.tif 000005
【図４】
2007335960.tif 000006
【図５】
2007335960.tif 000007
【図６】
2007335960.tif 000008
【図７】
2007335960.tif 000009
【図８】
2007335960.tif 000010
【図９】
2007335960.tif 000011
【図１０】
2007335960.tif 000012
【図１１】
2007335960.tif 000013
【図１２】
2007335960.tif 000014
【図１３】
2007335960.tif 000015
【図１４】
2007335960.tif 000016
【図１５】
2007335960.tif 000017