JP2009294736A - イベント制御プログラム、イベント制御方法およびイベント制御装置 - Google Patents

Abstract

【課題】サーバの負荷を軽減させること。
【解決手段】イベント制御装置１を、受信手段１ａ、要求手段１ｂ、転送手段１ｃとして機能させる。
受信手段１ａは、クライアント４ａ、４ｂを指定する指定情報を含むイベントの通知要求を受信する。要求手段１ｂは、受信した指定情報に基づいて、サーバ３ａ〜３ｃの中から指定情報によって特定されるクライアントに対してサービスを提供している振り分け先のサーバの通知を要求する。転送手段１ｃは、要求手段１ｂによる要求に応じて通知された振り分け先のサーバに、イベントの通知要求を転送する。
【選択図】図１

Description

本発明はイベント制御プログラム、イベント制御方法およびイベント制御装置に関し、特に、複数のプロトコルを利用するサービスに用いるイベント制御プログラム、イベント制御方法およびイベント制御装置に関する。

近年、Ｗｅｂ上のサービスにおいて、ＨＴＴＰ（HyperText Transfer Protocol）やＳＩＰ（Session Initiation Protocol）等複数のプロトコル（Protocol）を用いたサービスを組み合わせることで、特徴あるアプリケーションを容易に提供したい、という要求が高まっている。

一例として、プレゼンスサーバ（Presence Server）からのＳＩＰ Ｎｏｔｉｆｙ情報をもとに、ＷｅｂブラウザからのＨＴＴＰリクエストの応答コンテンツを変更する、といったサービスが知られている。

このようなサービスでは、サービス利用者の増加に伴うサーバ（Server）の処理速度の低下やサービスの停止を防ぐため、一般的に、複数のサーバを利用した負荷分散が行われる。

図２３は、負荷分散を行うシステムの構成を示す図である。
図２３に示すシステムは、サーバロードバランサ（SLB:Server Load Balancer）９１と、プレゼンスサーバ９２と、クライアント９３ａ、９３ｂと、Ｗｅｂサーバ９４ａ、９４ｂとを有している。

サーバロードバランサ９１は、クライアント９３ａ、９３ｂに対するＷｅｂアプリケーションの負荷分散のため、クライアント９３ａ、９３ｂからのＨＴＴＰリクエストを順番にＷｅｂサーバ９４ａ、９４ｂに振り分ける機能を有している。

一旦、クライアントとＷｅｂサーバ間でセッションが確立されると、サーバロードバランサ９１は、一定時間は、そのクライアントからのＨＴＴＰリクエストを、セッションが確立したＷｅｂサーバに振り分ける。

プレゼンスサーバ９２は、プレゼンス情報を必要とするＷｅｂサーバ９４ａ、９４ｂからの、通知を要求する状態変化（イベント）の通知要求を、予めＳｕｂｓｃｒｉｂｅ（登録）する。

その後、プレゼンスサーバ９２は、通知を要求する状態変化を検知すると、（Ｓｕｂｓｃｒｉｂｅしていた）Ｗｅｂサーバ９４ａ、９４ｂにそれぞれＮｏｔｉｆｙ（状態変化の通知）を転送する。

これにより、例えば、クライアント９３ａとＷｅｂサーバ９４ａ間でセッションが確立されると、サーバロードバランサ９１によりクライアント９３ａからのＨＴＴＰリクエストは、Ｗｅｂサーバ９４ａに振り分けられる。

一方、プレゼンスサーバ９２によるＮｏｔｉｆｙは、Ｓｕｂｓｃｒｉｂｅしている全てのＷｅｂサーバ９４ａ、９４ｂに通知される。
このため、クライアント９３によりＨＴＴＰアクセスされてないＷｅｂサーバ９４ｂにもＮｏｔｉｆｙが通知されることになる。

通常、Ｎｏｔｉｆｙを受信したＷｅｂサーバは、そのＮｏｔｉｆｙに格納されたタグの情報に基づく処理（例えば、データベース検索や画面データの準備等）を実施するため、ＨＴＴＰアクセス対象ではないＷｅｂサーバ（図２３ではＷｅｂサーバ９４ｂ）にとっては無駄な処理を行っていることになる。

ここで、Ｓｕｂｓｃｒｉｂｅ時において対象物の状態が変化していない場合は、空のＮｏｔｉｆｙを送信することで、ネットワーク負荷の軽減を図る技術が知られている。
しかしながら、このような場合においてもＷｅｂサーバに対してＮｏｔｉｆｙが通知されてしまうため、サーバの負荷を軽減させることはできないという問題がある。
特開２００７−２６００６号公報

本発明はこのような点に鑑みてなされたものであり、サーバの処理負荷を軽減させることができるイベント制御プログラム、イベント制御方法およびイベント制御装置を提供することを目的とする。

上記目的を達成するために、イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムが提供される。このプログラムは、イベント制御装置を、受信手段、要求手段、転送手段として機能させる。

受信手段は、クライアントを指定する指定情報を含むイベントの通知要求を受信する。
要求手段は、受信した指定情報に基づいて、複数のサーバのうち、指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する。

転送手段は、要求手段による要求に応じて通知された振り分け先のサーバに、イベントの通知要求を転送する。
このようなイベント制御プログラムを実行するコンピュータによれば、受信手段により、指定情報を含むイベントの通知要求が受信される。要求手段により、受信手段によって受信された識別情報に基づいて、振り分け先のサーバの通知が要求される。

転送手段により、要求手段による要求に応じて通知された振り分け先のサーバに、イベントの通知要求が転送される。

開示のイベント制御プログラムによれば、通知された振り分け先のサーバ以外には通知要求は転送されなくなるため、他のサーバの処理負荷を軽減させることができる。

以下、実施の形態を、図面を参照して詳細に説明する。
まず、実施の形態のコンピュータシステムの概要について説明し、その後、実施の形態をより具体的に説明する。

図１は、実施の形態のコンピュータシステムの概要を示す図である。
イベント制御装置１は、ネットワークを介して負荷分散装置２およびサーバ３ａ〜３ｃに接続されている。

負荷分散装置２は、サーバ３ａ〜３ｃと所定のプロトコル（例えばＨＴＴＰ等）でデータ通信を行うクライアント４ａ、４ｂからのデータ処理の要求をサーバ３ａ〜３ｃに動的に振り分ける。その際、振り分け先として決定したサーバとクライアントとの関係が分かるように保管しておき、セッションが確立している時間は、クライアントからのデータ処理の要求は、上記の関係に基づいてサーバに振り分ける。

図１では、一例として、負荷分散装置２は、クライアント４ａからのデータ処理の要求をサーバ３ｃに振り分けることを決定し、この関係を保管している。また、クライアント４ｂからのデータ処理の要求をサーバ３ａに振り分けることを決定し、この関係を保管している。

サーバ３ａ〜３ｃは、それぞれクライアント４ａ、４ｂの要求に応じて所定のサービスを提供する。
イベント制御装置１は、受信手段１ａと、要求手段１ｂと、転送手段１ｃとを有している。

受信手段１ａは、クライアントを指定する指定情報を含むイベントの通知要求を受信する。この通知要求は、サーバ−クライアント間のプロトコルとは異なるプロトコル（例えば、ＳＩＰ等）で送信される。

なお、指定情報としては、例えば、クライアントを直接指定するクライアントのＩＰアドレスや、クライアントを間接的に指定する、クライアントがログインしているユーザのＩＤや、クライアントに対応して設けられているタグのＩＤ等が挙げられる。

また、イベントの通知要求とは、イベントの通知要求を予めＳｕｂｓｃｒｉｂｅしているサーバに対してイベントを通知する要求である。
要求手段１ｂは、受信手段１ａが受信したイベントの通知要求に含まれる指定情報に基づいて、サーバ３ａ〜３ｃのうち、指定情報によって特定されるクライアントに対してサービスを提供しているサーバを、振り分け先のサーバとして通知するよう負荷分散装置２に要求する。

負荷分散装置２は、予め保管しておいた情報に基づいて振り分け先のサーバを決定し、イベント制御装置１に返す。
転送手段１ｃは、要求手段１ｂによる要求に応じて通知された振り分け先のサーバに対し、イベントの通知要求をサーバ−クライアント間のプロトコルとは異なるプロトコルで転送する。

例えば、負荷分散装置２からサーバ３ｃが振り分け先として通知された場合、転送手段１ｃは、サーバ３ｃにのみ通知要求を転送し、サーバ３ａ、３ｂには通知要求は転送しない。

このイベントの通知要求により、（クライアント４ａと通信を行っている）サーバ３ｃは、イベントの処理を実行し、クライアント４ａに応答する。
このように、イベント制御装置１が、振り分け先として決定されたサーバ３ａ〜３ｃのいずれかに通知要求を転送し、その他のサーバには通知要求を転送しないようにすることで、その他のサーバは無駄な処理を行わなくてよいため、その他のサーバの処理負荷を軽減させることができる。

以下、実施の形態をより具体的に説明する。
＜第１の実施の形態＞
図２は、ネットワークシステムの構成を示す図である。

ネットワークシステム１００は、クライアント１０ａ、１０ｂと、タグリーダー２０ａ、２０ｂと、ＨＴＴＰロードバランサ（サーバロードバランサ）３０と、プレゼンスサーバ４０と、Ｎｏｔｉｆｙ制御装置５０と、サーバ６０ａ、６０ｂとを有している。

クライアント１０ａ、１０ｂとＨＴＴＰロードバランサ３０間、タグリーダー２０ａ、２０ｂとプレゼンスサーバ４０間、プレゼンスサーバ４０とＮｏｔｉｆｙ制御装置５０間、およびＮｏｔｉｆｙ制御装置５０とＨＴＴＰロードバランサ３０とサーバ６０ａ、６０ｂ間はそれぞれネットワークで接続されている。これらのネットワークは、個別のネットワークであってもよいし、または、部分的にもしくは全体が重複していてもよい。

ここで、クライアント１０ａ、１０ｂ、ＨＴＴＰロードバランサ３０およびサーバ６０ａ、６０ｂ間は、ＨＴＴＰによる通信制御が行われる。また、ＨＴＴＰロードバランサ３０とＮｏｔｉｆｙ制御装置５０間、並びにプレゼンスサーバ４０、Ｎｏｔｉｆｙ制御装置５０およびサーバ６０ａ、６０ｂ間は、ＳＩＰによる通信制御が行われる。なお、タグリーダー２０ａ、２０ｂとプレゼンスサーバ４０間のプロトコルは特に限定されず、任意のプロトコルによる通信制御が行われる。

クライアント１０ａ、１０ｂは、それぞれサーバ６０ａ、６０ｂが提供するサービスをユーザが利用（享受）する装置である。
これらのクライアント１０ａ、１０ｂには、マウスやキーボード等（図示せず）が接続されており、それぞれユーザのマウスやキーボード等の操作（以下、単に「ユーザの操作」と言う）により送られてくる信号に応じてＷｅｂブラウザ１１ａ、１１ｂをクライアント１０ａ、１０ｂに接続されたモニタ（図示せず）に起動する。

そして、クライアント１０ａ、１０ｂは、それぞれユーザの操作により、Ｗｅｂブラウザ１１ａ、１１ｂ上に所定の画面を表示させる要求を受けつけると、ＨＴＴＰリクエストをＨＴＴＰロードバランサ３０に出力する。

タグリーダー２０ａ、２０ｂは、それぞれクライアント１０ａ、１０ｂに対応して設けられている。図２では、タグリーダー２０ａは、クライアント１０ａの近傍に設けられており、タグリーダー２０ｂは、クライアント１０ｂの近傍に設けられている。

タグリーダー２０ａ、２０ｂは、それぞれ所定のエリア内に存在するタグ（例えば、携帯端末装置やカードに内蔵されたタグ）を読み込む機能を有しており、読み込んだ内容に所定の情報を付加したタグ情報を、プレゼンスサーバ４０に送信する。

なお、読み込んだ内容には、例えば、クライアント１０ａ、１０ｂにログインしたユーザを識別するユーザＩＤ等が含まれる。また、付加する所定の情報には、例えばタグリーダー２０ａ、２０ｂの識別情報等が含まれる。

このようなネットワークシステム１００の使われ方の一例を簡単に説明する。
クライアント１０ａを操作するユーザは、Ｗｅｂブラウザ１１ａの閲覧中にＷｅｂアプリケーション６１ａによる特別なサービスを享受したい場合、タグリーダー２０ａにタグを読み込ませる。これにより、プレゼンスサーバ４０およびＮｏｔｉｆｙ制御装置５０により後述する処理が行われ、サーバ６０ａにＮｏｔｉｆｙが転送される。サーバ６０ａのＷｅｂアプリケーション６１ａは、Ｎｏｔｉｆｙに対する処理を実行し、Ｗｅｂブラウザ１１ａにその応答コンテンツを返す。これによって、ユーザは、特別なサービスを享受することができる。

ＨＴＴＰロードバランサ３０は、クライアント１０ａ、１０ｂとサーバ６０ａ、６０ｂ間を中継している。
ＨＴＴＰロードバランサ３０は、クライアント１０ａまたはクライアント１０ｂからのＨＴＴＰリクエストを受信すると、そのＨＴＴＰリクエストを処理させる（振り分け先の）サーバ６０ａまたはサーバ６０ｂを決定し、決定したサーバ６０ａまたはサーバ６０ｂにそのＨＴＴＰリクエストを動的に振り分ける。

ＨＴＴＰロードバランサ３０は、ＨＴＴＰリクエストを送信したクライアントと、そのクライアントからのＨＴＴＰリクエストを振り分けるサーバとを関連づけて振り分け先管理テーブル（後述）に格納する。

以後、ＨＴＴＰリクエストを受信すると、振り分け先管理テーブルを参照し、そのＨＴＴＰリクエストを要求したクライアントに関連づけられたサーバに対し、そのＨＴＴＰリクエストを振り分ける。

なお、図２では、クライアント１０ａの要求したＨＴＴＰリクエストをサーバ６０ａに振り分けた場合を示している。
また、ＨＴＴＰロードバランサ３０は、振り分け先のサーバ６０ａまたはサーバ６０ｂからＨＴＴＰリクエストに対する応答を受信すると、ＨＴＴＰリクエストを送信したクライアント１０ａまたはクライアント１０ｂに対し、その応答を返す。なお、図２では、サーバ６０ａからリクエストに対する応答があり、ＨＴＴＰリクエストを送信したクライアント１０ａに対し、その応答を返す場合を示している。

また、ＨＴＴＰロードバランサ３０は、Ｎｏｔｉｆｙ制御装置５０から、Ｎｏｔｉｆｙの振り分け先のサーバに関する問い合わせを受けると、後述する処理によって振り分け先のサーバを特定し、応答する。

プレゼンスサーバ４０には、受信したタグ情報の最初の転送先としてＮｏｔｉｆｙ制御装置５０のＩＰアドレスが予め設定されている。これにより、プレゼンスサーバ４０が受信した全てのタグ情報は、タグ情報の宛先に記載されたサーバに直接送信されることなく、Ｎｏｔｉｆｙ制御装置５０に送信される。

プレゼンスサーバ４０は、タグリーダー２０ａまたはタグリーダー２０ｂからのタグ情報を受信すると、Ｓｕｂｓｃｒｉｂｅ管理テーブル（後述）を参照してＳｕｂｓｃｒｉｂｅ元（イベントの通知要請元）となるサーバを特定し、このサーバに対するＮｏｔｉｆｙをＮｏｔｉｆｙ制御装置５０に送信する。このＮｏｔｉｆｙには、タグ情報が含まれる。

なお、Ｓｕｂｓｃｒｉｂｅ元となるサーバが複数存在する場合、これらのサーバのそれぞれに対応するＮｏｔｉｆｙを送信する。
Ｎｏｔｉｆｙ制御装置５０は、プレゼンスサーバ４０からのＮｏｔｉｆｙを受信すると、ＨＴＴＰロードバランサ３０に振り分け先を問い合わせる。具体的には、Ｎｏｔｉｆｙ制御装置５０は、ＨＴＴＰロードバランサ３０に振り分け先を問い合わせる際、予め用意されたグループ管理テーブル（後述）を参照することで応答コンテンツを必要とするクライアントを特定し、特定したクライアントのＩＰアドレスに基づいて振り分け先を問い合わせる。

振り分け先を問い合わせることで、受信したＮｏｔｉｆｙに対するＮｏｔｉｆｙの転送先のサーバ６０ａまたはサーバ６０ｂを決定する。
図２では、クライアント１０ａが特定された場合を図示している。前述したように、ＨＴＴＰロードバランサ３０は、クライアント１０ａが送信するＨＴＴＰリクエストを、サーバ６０ａに振り分けているため、ＨＴＴＰロードバランサ３０からは、サーバ６０ａが振り分け先として通知され、Ｎｏｔｉｆｙ制御装置５０は、サーバ６０ａを振り分け先として決定する。

その後、Ｎｏｔｉｆｙ制御装置５０は、振り分け先として決定したサーバにＮｏｔｉｆｙを転送してよいか否かの判定を行い、転送してよいと判定した場合、そのサーバにＮｏｔｉｆｙを転送する。

サーバ６０ａ、６０ｂは、それぞれＷｅｂブラウザ１１ａ、１１ｂの要求に応じたＷｅｂアプリケーション６１ａ、６１ｂを実行する機能を有しており、ＨＴＴＰロードバランサ３０からＨＴＴＰリクエストを受信すると、そのリクエストに応じたＷｅｂアプリケーションを実行し、処理結果のファイル（ＨＴＭＬファイル等）をＨＴＴＰロードバランサ３０に送信する。

また、サーバ６０ａ、６０ｂは、Ｎｏｔｉｆｙ制御装置５０からのＮｏｔｉｆｙを受信すると、そのＮｏｔｉｆｙに含まれる情報に応じた処理を行い、その応答コンテンツを、ＨＴＴＰリクエストに対する応答に含ませて、特定したクライアントに送信する。

次に、ＨＴＴＰロードバランサ３０が備える振り分け先管理テーブルについて説明する。
図３は、振り分け先管理テーブルを示す図である。

振り分け先管理テーブル３０ａには、クライアントおよび振り分け先の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
クライアントの欄には、ＨＴＴＰロードバランサ３０が受信したＨＴＴＰリクエストの送信元のクライアントのＩＰアドレス（識別情報）が格納される。

図３では、クライアント１０ａのＩＰアドレス「１９２．１６．０．５」が格納されている。
振り分け先アドレスの欄には、クライアントの欄に格納されたＩＰアドレスを備えるクライアントとセッションが確立されているサーバを識別するＩＰアドレスが記載される。

図３では、サーバ６０ａのＩＰアドレス「１０．１６．０．２」が格納されている。
次に、プレゼンスサーバ４０が備えるＳｕｂｓｃｒｉｂｅ管理テーブルについて説明する。

図４は、Ｓｕｂｓｃｒｉｂｅ管理テーブルを示す図である。
Ｓｕｂｓｃｒｉｂｅ管理テーブル４０ａには、Ｓｕｂｓｃｒｉｂｅ元および購読対象の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。

Ｓｕｂｓｃｒｉｂｅ元の欄には、Ｓｕｂｓｃｒｉｂｅ送信元のサーバのＩＰアドレスが格納される。
図４では、サーバ６０ａのＩＰアドレス「１０．１６．０．２」およびサーバ６０ｂのＩＰアドレス「１０．１６．０．５」が格納されている。

購読対象の欄には、Ｓｕｂｓｃｒｉｂｅ元の欄に格納されたサーバがＳｕｂｓｃｒｉｂｅを受けつける（Ｓｕｂｓｃｒｉｂｅ対象となる）タグリーダーのＵＲＩ（Uniform Resource Identifier）が格納される。

図４では、タグリーダー２０ａのＵＲＩ「ｒｅａｄｅｒ０５＠１０．２５．１０．３」が格納されている。
このＳｕｂｓｃｒｉｂｅ管理テーブル４０ａを参照することにより、プレゼンスサーバ４０は、どのサーバが、どのタグリーダーの変化を通知して欲しいことを予めＳｕｂｓｃｒｉｂｅしているかを認識することができる。

次に、Ｎｏｔｉｆｙ制御装置５０が備えるグループ管理テーブルについて説明する。
図５は、グループ管理テーブルを示す図である。
グループ管理テーブル５０ａには、クライアントおよびＦｒｏｍ ＵＲＩの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。

クライアントの欄には、クライアントのＩＰアドレスが格納されている。
Ｆｒｏｍ ＵＲＩの欄には、タグリーダーのＵＲＩが格納されている。
このグループ管理テーブル５０ａを参照することにより、Ｎｏｔｉｆｙ制御装置５０は、受け取ったＮｏｔｉｆｙに含まれるタグ情報が、どのクライアントに対応しているのかを認識することができる。

次に、ネットワークシステム１００の処理を簡単に説明する。
図６は、ネットワークシステムの処理を示すシーケンス図である。
サーバ６０ａ、６０ｂは、それぞれＳｕｂｓｃｒｉｂｅ元および購読対象を含むＳＩＰ Ｓｕｂｓｃｒｉｂｅをプレゼンスサーバ４０に送信する。プレゼンスサーバ４０は、受信したＳＩＰ Ｓｕｂｓｃｒｉｂｅに含まれるＳｕｂｓｃｒｉｂｅ元および購読対象をＳｕｂｓｃｒｉｂｅ管理テーブル４０ａに格納する。ここまでが前処理として行われている。

その後、クライアント１０ａのＷｅｂブラウザ１１ａが起動され、ＨＴＴＰロードバランサ３０に対してＨＴＴＰリクエストが送信される（ステップＳ１）。
ＨＴＴＰロードバランサ３０は、ＨＴＴＰリクエストに応じて振り分け先のサーバを決定し、送信元のクライアントのＩＰアドレスと、決定した振り分け先のサーバのＩＰアドレスとを関連づけて振り分け先管理テーブル３０ａに格納する（ステップＳ２）。

その後、ＨＴＴＰロードバランサ３０は、そのＨＴＴＰリクエストを振り分け先のサーバ（図６では、サーバ６０ａ）に振り分ける（ステップＳ３）。
ＨＴＴＰリクエストが振り分けられたサーバ６０ａは、そのＨＴＴＰリクエストに応じたＨＴＭＬファイルをクライアント１０ａに返す（ステップＳ４）。

その後、タグリーダー２０ａにタグがかざされると、タグリーダー２０ａは、プレゼンスサーバ４０にタグ情報を送信する（ステップＳ５）。
プレゼンスサーバ４０は、Ｓｕｂｓｃｒｉｂｅ管理テーブル４０ａを参照して得られるＳｕｂｓｃｒｉｂｅ元に対するＮｏｔｉｆｙ通知をＮｏｔｉｆｙ制御装置５０に送信する（ステップＳ６）。

Ｎｏｔｉｆｙ制御装置５０は、Ｎｏｔｉｆｙ通知を受信すると、ＨＴＴＰロードバランサ３０に対し、振り分け先を問い合わせる（振り分け先の通知を要求する）（ステップＳ７）。

ＨＴＴＰロードバランサ３０は、Ｎｏｔｉｆｙ制御装置５０の要求に応じて振り分け先管理テーブル３０ａを参照し、振り分け先を応答する（ステップＳ８）。
Ｎｏｔｉｆｙ制御装置５０は、その応答に含まれる振り分け先として決定したサーバにＮｏｔｉｆｙを転送するか否かの判定を行い、転送する場合、そのサーバ（図６では、サーバ６０ａ）にＮｏｔｉｆｙを転送する（ステップＳ９）。なお、転送するか否かの判定基準については後に詳述する。

これにより、サーバ６０ａのＷｅｂアプリケーション６１は、アプリケーションを実行し、得られた応答コンテンツをクライアント１０ａに送信する（ステップＳ１０）。これにより、クライアント１０ａが備えるモニタに応答コンテンツが表示される。

以上でネットワークシステム１００の処理の説明を終了する。
以下、Ｎｏｔｉｆｙ制御装置５０の構成について詳しく説明する。
図７は、Ｎｏｔｉｆｙ制御装置のハードウェア構成例を示す図である。

Ｎｏｔｉｆｙ制御装置５０は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０６を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、および通信インタフェース１０４、１０５が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。また、ＨＤＤ１０３内には、プログラムファイルが格納される。

通信インタフェース１０４は、ＨＴＴＰロードバランサ３０との間でデータの送受信を行う。通信インタフェース１０５は、プレゼンスサーバ４０およびサーバ６０ａ、６０ｂとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。このようなハードウェア構成のシステムにおいて前述した処理を行うために、Ｎｏｔｉｆｙ制御装置５０内には、以下のような機能が設けられる。

図８は、Ｎｏｔｉｆｙ制御装置の機能を示すブロック図である。
Ｎｏｔｉｆｙ制御装置５０は、Ｎｏｔｉｆｙ受信部５１と、管理テーブル格納部５２と、検索部５３と、アドレス要求部５４と、転送判定部５５とを有している。

Ｎｏｔｉｆｙ受信部５１は、プレゼンスサーバ４０からのＮｏｔｉｆｙを受信する。
管理テーブル格納部５２には、グループ管理テーブル５０ａが格納されている。なお、管理テーブル格納部５２は、例えば、図７のＨＤＤ１０３またはＲＡＭ１０２の記憶領域として実現される。

検索部５３は、グループ管理テーブル５０ａを参照し、Ｎｏｔｉｆｙ受信部５１が受信したＮｏｔｉｆｙに含まれるＦｒｏｍ ＵＲＩに対応するクライアントのＩＰアドレスを検索し、取得する。

アドレス要求部５４は、検索部５３が取得したＩＰアドレスに基づいて、ＨＴＴＰロードバランサ３０に対し、振り分け先を問い合わせる。
そして、問い合わせに対するＨＴＴＰロードバランサ３０からの応答を転送判定部５５に送る。

転送判定部５５は、振り分け先として決定したサーバにＮｏｔｉｆｙを転送してよいか否かを判定し、転送してよいと判定した場合、その振り分け先に対してＮｏｔｉｆｙを転送する。転送してはいけないと判定した場合、Ｎｏｔｉｆｙを廃棄する。

次に、Ｎｏｔｉｆｙ制御装置５０の処理を説明する。
図９は、Ｎｏｔｉｆｙ制御装置の処理を示すフローチャートである。
まず、Ｎｏｔｉｆｙ受信部５１が、Ｎｏｔｉｆｙを受信する（ステップＳ１１）。

次に、検索部５３が、グループ管理テーブル５０ａを参照し、Ｎｏｔｉｆｙ受信部５１が受信したＮｏｔｉｆｙに含まれるＦｒｏｍ ＵＲＩに対応するクライアントのＩＰアドレスを検索し、取得する（ステップＳ１２）。

次に、アドレス要求部５４が、検索部５３が取得したクライアントのＩＰアドレスに基づいて、ＨＴＴＰロードバランサ３０に対し、振り分け先のサーバ（図９では単に「振り分け先」と表記している。以下同じ）を問い合わせる（ステップＳ１３）。

次に、転送判定部５５が、ＨＴＴＰロードバランサ３０から振り分け先のサーバが得られたか否かを判定する（ステップＳ１４）。
振り分け先のサーバが得られない場合、すなわち、振り分け先管理テーブル３０ａに、クライアントに対応する振り分け先のサーバが存在しない場合（ステップＳ１４のＮｏ）、転送判定部５５は、Ｎｏｔｉｆｙに含まれる宛先を、このクライアントに対するＮｏｔｉｆｙの振り分け先としてＨＴＴＰロードバランサ３０に登録を要求する（ステップＳ１５）。その後、宛先のサーバを振り分け先のサーバとして、宛先のサーバに対しＮｏｔｉｆｙを転送し（ステップＳ１８）、処理を終了する。

一方、振り分け先のサーバが得られた場合（ステップＳ１４のＹｅｓ）、転送判定部５５は、振り分け先のサーバのＩＰアドレスとＮｏｔｉｆｙに含まれる宛先のＩＰアドレスとが一致するか否かを判定する（ステップＳ１６）。

一致しない場合（ステップＳ１６のＮｏ）、受信したＮｏｔｉｆｙを廃棄し（ステップＳ１７）、処理を終了する。
一方、一致する場合（ステップＳ１６のＹｅｓ）、一致した振り分け先のサーバに対しＮｏｔｉｆｙを転送し（ステップＳ１８）、処理を終了する。

以上でＮｏｔｉｆｙ制御装置５０の処理の説明を終了する。
次に、ネットワークシステム１００の処理の具体例を説明する。
以下、具体例では、ＨＴＴＰロードバランサ３０の処理に際しては、図３に示す振り分け先管理テーブル３０ａの値を使用する。プレゼンスサーバ４０の処理に際しては、図４に示すＳｕｂｓｃｒｉｂｅ管理テーブル４０ａに格納された値を使用する。Ｎｏｔｉｆｙ制御装置５０の処理に際しては、図５に示すグループ管理テーブル５０ａに格納された値を使用する。

図１０は、処理の具体例を示すシーケンス図である。
ステップＳ２１〜ステップＳ２５：それぞれ図６のステップＳ１〜ステップＳ５と同様の処理を行う。

タグリーダー２０ａからのタグ情報を受信したプレゼンスサーバ４０は、Ｓｕｂｓｃｒｉｂｅ管理テーブル４０ａを参照する。そして、タグ情報に含まれるタグリーダー２０ａのＩＤ「ｒｅａｄｅｒ０５＠．１０．２５．１０．３」に対応するＩＰアドレス「１０．１６．０．２」のサーバ、すなわちサーバ６０ａをＳｕｂｓｃｒｉｂｅ元として特定する。また、タグリーダー２０ａのＩＤ「ｒｅａｄｅｒ０５＠．１０．２５．１０．３」に対応するＩＰアドレス「１０．１６．０．５」のサーバ、すなわちサーバ６０ｂをＳｕｂｓｃｒｉｂｅ元として特定する。

そして、Ｆｒｏｍ ＵＲＩを「ｒｅａｄｅｒ０５＠１０．２５．１０．３」とし、Ｔｏ ＵＲＩを「ｓｅｒｖｅｒ０１＠１０．１６．０．２」としたＮｏｔｉｆｙを、サーバ６０ａに対するＮｏｔｉｆｙとする。

また、Ｆｒｏｍ ＵＲＩを「ｒｅａｄｅｒ０５＠１０．２５．１０．３」とし、Ｔｏ ＵＲＩを「ｓｅｒｖｅｒ０１＠１０．１６．０．５」としたＮｏｔｉｆｙを、サーバ６０ｂに対するＮｏｔｉｆｙとする。

そして、これらＮｏｔｉｆｙをそれぞれＮｏｔｉｆｙ制御装置５０に送信する（ステップＳ２６、Ｓ２７）。
以下、説明を分かりやすくするために、まず、ステップＳ２６のＮｏｔｉｆｙがＮｏｔｉｆｙ制御装置５０に通知された場合の処理を説明し、次に、ステップＳ２７のＮｏｔｉｆｙがＮｏｔｉｆｙ制御装置５０に通知された場合を説明する。なお、このような処理の順序は特に限定されるものではない。

Ｎｏｔｉｆｙ受信部５１が、ステップＳ２６のＮｏｔｉｆｙを受信すると、検索部５３が、グループ管理テーブル５０ａを参照する。そして、Ｎｏｔｉｆｙに含まれるＦｒｏｍ ＵＲＩ「ｒｅａｄｅｒ０５＠１０．２５．１０．３」に対応するＩＰアドレス「１９２．１６．０．５」のクライアント、すなわちクライアント１０ａを特定する。

そして、アドレス要求部５４が、クライアント１０ａに対する振り分け先をＨＴＴＰロードバランサ３０に問い合わせる（ステップＳ２８）。
要求を受信したＨＴＴＰロードバランサ３０は、振り分け先管理テーブル３０ａを参照する。

ここで、振り分け先管理テーブル３０ａには、ＩＰアドレス「１９２．１６．０．５」のクライアント１０ａに対する振り分け先のＩＰアドレス「１０．１６．０．２」が存在するため、振り分け先のＩＰアドレス「１０．１６．０．２」をＮｏｔｉｆｙ制御装置５０に応答する（ステップＳ２９）。

振り分け先のサーバのＩＰアドレスが得られたため、転送判定部５５が、振り分け先のサーバのＩＰアドレスとＮｏｔｉｆｙの宛先の一致を判定する。
ここで、振り分け先のサーバのＩＰアドレスとＮｏｔｉｆｙのＴｏ ＵＲＩは、共に「１０．１６．０．２」で一致するため、転送判定部５５は、ＩＰアドレス「１０．１６．０．２」のサーバ、すなわちサーバ６０ａにＮｏｔｉｆｙを出力する（ステップＳ３０）。

これにより、サーバ６０ａは、Ｎｏｔｉｆｙに含まれる情報（ＳＩＰリクエストのボディ）に対応するアプリケーションを実行し、その結果をクライアント１０ａに送信する（ステップＳ３１）。

一方、Ｎｏｔｉｆｙ受信部５１が、ステップＳ２７のＮｏｔｉｆｙを受信すると、検索部５３およびアドレス要求部５４は、ステップＳ２８およびステップＳ２９と同様の処理を行う（ステップＳ３２、Ｓ３３）。

そして、転送判定部５５が、振り分け先のサーバのＩＰアドレスとＮｏｔｉｆｙの宛先の一致を判定する。
ここで、振り分け先のサーバのＩＰアドレス「１０．１６．０．２」とＮｏｔｉｆｙのＴｏ ＵＲＩ「１０．１６．０．５」は、一致しないため、転送判定部５５は、Ｎｏｔｉｆｙを廃棄する。

以上述べたように、ネットワークシステム１００によれば、Ｎｏｔｉｆｙ制御装置５０が、振り分け先と宛先が一致した宛先にのみ、Ｎｏｔｉｆｙを転送し、一致しないＮｏｔｉｆｙを廃棄するようにしたので、Ｓｕｂｓｃｒｉｂｅ管理テーブル４０ａに格納されているが、今回の処理対象ではないサーバにはＮｏｔｉｆｙは転送されない。これにより、サーバの無駄な処理を回避させることができる。

また、ＨＴＴＰロードバランサ３０と連携してＮｏｔｉｆｙの無駄な転送を減らすようにしたので、複数のプロトコルを用いたシステムにも適用することができる。
また、振り分け先のサーバが得られなかった場合、ＨＴＴＰロードバランサ３０に登録を要求するようにして、今回のＮｏｔｉｆｙは、宛先のサーバに転送するようにしたので、例えば、クライアント１０ａとサーバ６０ａ間にセッションが確立していない場合において、ユーザがタグリーダー２０ａにタグ情報を読み込ませてしまった場合においても、その情報が振り分け先のサーバのＷｅｂアプリケーション６１ａに確実に転送される。そして、クライアント１０ａとサーバ６０ａ間のセッション確立後に、応答コンテンツがＷｅｂブラウザ１１ａに送信される。

これにより、例えばＷｅｂブラウザ１１ａ、１１ｂと、タグリーダー２０ａ、２０ｂのどちらが先に動作した場合においても振り分け先のサーバの無駄な処理を回避させることができる。

なお、本実施の形態では、要求元のクライアントがＨＴＴＰロードバランサ３０に登録されていなかった場合にＮｏｔｉｆｙ制御装置５０のアドレス要求部５４がＮｏｔｉｆｙの振り分け先の登録をＨＴＴＰロードバランサ３０に要求するようにしたが、これに限らず、ＨＴＴＰロードバランサ３０が振り分け先を決定し、アドレス要求部５４に通知するようにしてもよい。以下、詳しく説明する。

図１１は、ＨＴＴＰロードバランサの処理を示すフローチャートである。
まず、アドレス要求部５４から振り分け先の問い合わせを受信する（ステップＳ４１）。

次に、振り分け先管理テーブル３０ａを参照し、問い合わせに含まれるクライアントのＩＰアドレスに基づいて、振り分け先のサーバを検索する（ステップＳ４２）。
次に、振り分け先のサーバが得られたか否かを判断する（ステップＳ４３）。

振り分け先のサーバが得られた場合（ステップＳ４３のＹｅｓ）、得られた振り分け先のサーバのＩＰアドレスをアドレス要求部５４に送信する（ステップＳ４４）。
一方、振り分け先のサーバが得られなかった場合（ステップＳ４３のＮｏ）、任意のサーバのＩＰアドレスを振り分け先として１つ選択する（ステップＳ４５）。選択の方法は特に限定されないが、例えば、振り分け可能なサーバのＩＰアドレスが格納されているリストを予め用意しておいて、そのリストの上から順番に選択する方法や、リストからランダムに選択する方法等が挙げられる。

次に、選択したサーバのＩＰアドレスを、問い合わせに含まれるクライアントのＩＰアドレスに関連づけて振り分け先管理テーブル３０ａに反映（格納）する（ステップＳ４６）。

その後、ステップＳ４４に移行し、選択した振り分け先のサーバのＩＰアドレスをアドレス要求部５４に送信する。
以上で処理の説明を終了する。

このような処理を行うことによって、振り分け先管理テーブル３０ａの管理（設定）がＨＴＴＰロードバランサ３０の中で閉じて行われるため、管理の容易化を図ることができる。

また、本実施の形態では、Ｎｏｔｉｆｙ制御装置５０が有する各機能を独立した装置（Ｎｏｔｉｆｙ制御装置５０）に持たせて説明したが、このような構成に限定されず、例えば、ネットワークシステム１００の他の装置にＮｏｔｉｆｙ制御装置５０が有する機能を備えさせるようにしてもよい。

図１２および図１３は、Ｎｏｔｉｆｙ制御装置が有する機能を他の装置に実装した例を示す図である。
図１２に示すネットワークシステム１００ａでは、プレゼンスサーバ４０１は、プレゼンスサーバ４０と同じ機能を備えるＮｏｔｉｆｙ配信部４１と、Ｎｏｔｉｆｙ制御装置５０と同じ機能を備えるＮｏｔｉｆｙ制御部４２とを有している。

図１３に示すネットワークシステム１００ｂでは、ＨＴＴＰロードバランサ３０１は、ＨＴＴＰロードバランサ３０と同じ機能を備えるＨＴＴＰ振り分け部３１と、Ｎｏｔｉｆｙ制御部４２とを有している。

図１２および図１３に示すネットワークシステム１００ａ、１００ｂによっても、ネットワークシステム１００と同様の効果が得られる。また、このようなシステム構成によれば、ネットワークシステムの小型化を図ることができる。

また、本実施の形態では、ＨＴＴＰとＳＩＰを利用するネットワークシステムについて説明したが、本発明は、複数のプロトコルを利用するシステムであれば、利用するプロトコルの種別は特に限定されず、例えばＳＯＡＰ（Simple Object Access Protocol）、ＳＭＴＰ（Simple Mail Transfer Protocol）、ＲＴＰ（Real-time Transport Protocol）／ＲＴＣＰ（RTP Control Protocol）等を用いたシステムにも適用することができる。

＜第２の実施の形態＞
次に、第２の実施の形態のネットワークシステムについて説明する。
以下、第２の実施の形態のネットワークシステムについて、前述した第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。

第２の実施の形態のネットワークシステムは、Ｎｏｔｉｆｙを必要とするサーバと必要としないサーバとの混在を可能とするシステムであり、Ｎｏｔｉｆｙ制御装置５０の代わりにＮｏｔｉｆｙ制御装置５０１を備えている。

図１４は、第２の実施の形態のＮｏｔｉｆｙ制御装置の機能を示すブロック図である。
Ｎｏｔｉｆｙ制御装置５０１は、管理テーブル格納部５２ａおよび検索部５３ａを備えている点がＮｏｔｉｆｙ制御装置５０と異なっている。

管理テーブル格納部５２ａは、グループ管理テーブル５０ａに加え、処理対象サーバリストを備えている。
図１５は、処理対象サーバリストを示す図である。

処理対象サーバリスト５０ｂには、アドレス要求部５４および転送判定部５５の処理対象となるサーバ（処理対象サーバ）のＩＰアドレスがリスト化されて格納されている。
再び図１４に戻って説明する。

検索部５３ａは、処理対象サーバリスト５０ｂを参照し、Ｎｏｔｉｆｙに含まれる宛先が、処理対象サーバリスト５０ｂに存在しない場合、Ｎｏｔｉｆｙをアドレス要求部５４に送ることなく宛先のサーバに転送する。

図１６は、第２の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。
まず、Ｎｏｔｉｆｙ受信部５１が、Ｎｏｔｉｆｙを受信する（ステップＳ５１）。

次に、検索部５３ａが、宛先が処理対象のサーバか否かを判断する（ステップＳ５２）。具体的には、処理対象サーバリスト５０ｂを参照し、Ｎｏｔｉｆｙの宛先が処理対象サーバリスト５０ｂに含まれているか否かを判断する。

宛先が処理対象のサーバである場合、すなわち、宛先が処理対象サーバリスト５０ｂに含まれている場合（ステップＳ５２のＹｅｓ）、ステップＳ５３に移行する。
ステップＳ５３〜ステップＳ５９：転送判定部５５が、それぞれ図９のステップＳ１２〜ステップＳ１８と同様の処理を行う。

一方、宛先が処理対象のサーバではない場合、すなわち、宛先が処理対象サーバリスト５０ｂに含まれていない場合（ステップＳ５２のＮｏ）、検索部５３ａは、Ｎｏｔｉｆｙをアドレス要求部５４に送ることなく宛先のサーバに転送する（ステップＳ６０）。

以上で処理の説明を終了する。
この第２の実施の形態のＮｏｔｉｆｙ制御装置５０１によれば、第１の実施の形態のＮｏｔｉｆｙ制御装置５０と同様の効果が得られる。

そして、第２の実施の形態のＮｏｔｉｆｙ制御装置５０１によれば、処理対象サーバリスト５０ｂに含まれていないサーバ（例えば、ＨＴＴＰロードバランサ３０の分散対象でないサーバ）の宛先がＮｏｔｉｆｙに含まれている場合、そのサーバに対しては必ずＮｏｔｉｆｙが通知されるようにすることができるため、Ｎｏｔｉｆｙ制御装置５０１の処理の負荷を軽減することができる。また、Ｎｏｔｉｆｙが誤って廃棄されることを防止することができる。

なお、本実施の形態では、処理対象のサーバを処理対象サーバリスト５０ｂに格納したが、本発明はこれに限らず、例えば、処理対象外のサーバをリスト化し、このリストに含まれているサーバの宛先がＮｏｔｉｆｙに含まれている場合、そのサーバに対しては必ずＮｏｔｉｆｙが通知されるようにしてもよい。

＜第３の実施の形態＞
次に、第３の実施の形態のネットワークシステムについて説明する。
以下、第３の実施の形態のネットワークシステムについて、前述した第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。

第３の実施の形態のネットワークシステムは、ユーザＩＤを使って振り分け先を管理するシステムであり、ＨＴＴＰロードバランサ３０が備える振り分け先管理テーブルの内容およびＮｏｔｉｆｙ制御装置の機能構成が異なっている。

図１７は、第３の実施の形態の振り分け先管理テーブルを示す図である。
振り分け先管理テーブル３０ｂには、ユーザＩＤおよび振り分けアドレスの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。

ユーザＩＤの欄には、クライアントに現在ログインしているユーザを識別する情報（ユーザＩＤ）が格納されている。
図１８は、第３の実施の形態のＮｏｔｉｆｙ制御装置の機能を示すブロック図である。

Ｎｏｔｉｆｙ制御装置５０２は、管理テーブル格納部５２および検索部５３を有さず、アドレス要求部５４が、Ｎｏｔｉｆｙ受信部５１が受信したＮｏｔｉｆｙを直接取得する。すなわち、本実施の形態のＮｏｔｉｆｙ制御装置５０２では、タグリーダーのＵＲＩに応じてクライアントを特定する処理は行わない。

アドレス要求部５４は、クライアントのＩＰアドレスの代わりにタグ情報に含まれているユーザＩＤに基づいてＨＴＴＰロードバランサ３０に対し、振り分け先を問い合わせる。

図１９は、第３の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。
まず、Ｎｏｔｉｆｙ受信部５１が、Ｎｏｔｉｆｙを受信する（ステップＳ６１）。

次に、アドレス要求部５４が、Ｎｏｔｉｆｙのタグ情報に含まれているユーザＩＤに基づいて、ＨＴＴＰロードバランサ３０に対し、振り分け先を問い合わせる（ステップＳ６２）。

ステップＳ６３〜ステップＳ６７：転送判定部５５が、それぞれ図９のステップＳ１４〜ステップＳ１８と同様の処理を行う。なお、本実施の形態のＨＴＴＰロードバランサ３０は、アドレス要求部５４から振り分け先の問い合わせを受信すると、振り分け先管理テーブル３０ｂを参照し、問い合わせに含まれるユーザＩＤに基づいて、振り分け先のサーバを特定する。

この第３の実施の形態のＮｏｔｉｆｙ制御装置５０２によれば、第１の実施の形態のＮｏｔｉｆｙ制御装置５０と同様の効果が得られる。
なお、本実施の形態では、ＨＴＴＰロードバランサ３０およびプレゼンスサーバ４０からの通知パラメータとしてユーザＩＤを利用したが、これに限定されず、その他の通知パラメータ、例えば、ＨＴＴＰブラウザに与えたセッションＩＤ等を利用するようにしてもよい。

＜第４の実施の形態＞
次に、第４の実施の形態のネットワークシステムについて説明する。
以下、第４の実施の形態のネットワークシステムについて、前述した第１の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。

第４の実施の形態のネットワークシステムは、ユーザを認証する認証サーバを備えている点、およびＮｏｔｉｆｙ制御装置の機能構成が異なっている。
図２０は、第４の実施の形態のＮｏｔｉｆｙ制御装置を示すブロック図である。

第４の実施の形態のＮｏｔｉｆｙ制御装置５０３は、管理テーブル格納部５２および検索部５３の代わりに、認証要求部５６を備えている。
認証要求部５６は、Ｎｏｔｉｆｙのタグ情報に含まれるユーザＩＤに基づいて、認証サーバ７０に対してＮｏｔｉｆｙ受信部５１が受信したＮｏｔｉｆｙの認証を要求する。

図２１は、認証サーバが備えるユーザ利用状況管理テーブルを示す図である。
ユーザ利用状況管理テーブル７０ａには、クライアントおよびユーザＩＤの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。

ユーザＩＤの欄には、クライアントへのログインを許可するユーザＩＤが格納されている。
認証サーバ７０は、認証要求部５６からの要求を受信すると、対応するクライアントのＩＰアドレスが存在すればそのＩＰアドレスを返し、存在しなければ対応なしを返す。

図２２は、第４の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。
まず、Ｎｏｔｉｆｙ受信部５１が、Ｎｏｔｉｆｙを受信する（ステップＳ７１）。

次に、認証要求部５６が、Ｎｏｔｉｆｙのタグ情報に含まれているユーザＩＤに基づいて、認証サーバ７０に対して認証を要求する（ステップＳ７２）。
次に、認証要求部５６が、クライアントのアドレスが得られたか否かを判断する（ステップＳ７３）。

得られない場合（ステップＳ７３のＮｏ）、処理を終了する。
得られた場合（ステップＳ７３のＹｅｓ）、ステップＳ７４に移行する。
ステップＳ７４〜ステップＳ７９：転送判定部５５が、それぞれ図９のステップＳ１３〜ステップＳ１８と同様の処理を行う。

この第４の実施の形態のＮｏｔｉｆｙ制御装置５０３によれば、第１の実施の形態のＮｏｔｉｆｙ制御装置５０と同様の効果が得られる。
なお、本実施の形態では、認証にユーザＩＤを用いたが、これに限定されず、例えば、認証サーバ７０から得られる証明ＩＤをタグに格納し、このタグをタグリーダー２０ａ、２０ｂに読み込ませてＮｏｔｉｆｙに格納するようにしてもよい。

以上、本発明のイベント制御プログラム、イベント制御方法およびイベント制御装置を、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。

また、本発明は、前述した各実施の形態のうちの、任意の２以上の構成（特徴）を組み合わせたものであってもよい。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、Ｎｏｔｉｆｙ制御装置５０、５０１、５０２、５０３が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

イベント制御プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

以上の実施形態に関し、更に以下の付記を開示する。
（付記１） イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムにおいて、
前記イベント制御装置を、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信手段、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求手段、
前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送手段、
として機能させることを特徴とするイベント制御プログラム。

（付記２） 前記受信手段は、前記通知要求をプレゼンスサーバから受信し、
前記要求手段は、前記通知要求を分散処理装置に要求し、
前記サーバは、アプリケーションサーバである、
ことを特徴とする付記１記載のイベント制御プログラム。

（付記３） 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記転送手段は、通知された前記振り分け先と、前記宛先とが一致した場合のみ前記振り分け先のサーバに対し、前記イベントの通知要求を転送することを特徴とする付記１または２記載のイベント制御プログラム。

（付記４） 前記指定情報は、前記クライアントの識別情報以外の情報であり、
前記イベント制御装置を、前記指定情報と前記クライアントの識別情報とを関連づけて格納する格納手段、
前記受信手段により前記イベントの通知要求が受信されると、受信した前記イベントの通知要求に含まれる前記指定情報に応じた前記クライアントの識別情報を前記格納手段から検索する検索手段、として機能させ、
前記要求手段は、前記検索手段により検索された前記クライアントの識別情報に基づいて、前記振り分け先のサーバの通知を要求することを特徴とする付記１から３の何れかに記載のイベント制御プログラム。

（付記５） 前記要求手段は、前記サーバの負荷を分散する機能を備え前記クライアントとセッションが確立しているサーバの情報を格納する負荷分散装置に対して前記振り分け先のサーバの通知を要求することを特徴とする付記１記載のイベント制御プログラム。

（付記６） 前記負荷分散装置は、前記指定情報に基づいた前記振り分け先のサーバが存在しない場合、任意のリストから前記振り分け先のサーバを選択し、前記要求手段に応答することを特徴とする付記４記載のイベント制御プログラム。

（付記７） 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記要求手段は、前記振り分け先のサーバの通知を要求した要求先から前記振り分け先のサーバが通知されなかった場合、前記要求先に対し、前記指定情報に応じた前記宛先の登録を要求することを特徴とする付記１記載のイベント制御プログラム。

（付記８） 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記格納手段は、処理対象のサーバの識別情報を格納するリストを格納しており、
前記検索手段は、前記宛先が、前記リストに含まれている場合、振り分け先のサーバの通知を要求することなく前記リストに含まれているサーバに対し、前記イベントの通知要求を前記第１のプロトコルで転送することを特徴とする付記１記載のイベント制御プログラム。

（付記９） 前記受信手段は、第１のプロトコルで送信された前記イベントの通知要求を受信し、
前記要求手段は、前記指定情報によって指定されるクライアントに対して第２のプロトコルでサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段は、前記イベントの通知要求を前記第１のプロトコルで転送することを特徴とする付記１記載のイベント制御プログラム。

（付記１０） イベントの中継制御を、受信手段と要求手段と転送手段を有するイベント制御装置に実行させるイベント制御方法において、
前記受信手段が、クライアントを指定する指定情報を含むイベントの通知要求を受信し、
前記要求手段が、前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段が、前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する、
ことを特徴とするイベント制御方法。

（付記１１） イベントの中継制御を行うイベント制御装置において、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信部と、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求部と、
前記要求部による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送部と、
を有することを特徴とするイベント制御装置。

実施の形態のコンピュータシステムの概要を示す図である。 ネットワークシステムの構成を示す図である。 振り分け先管理テーブルを示す図である。 Ｓｕｂｓｃｒｉｂｅ管理テーブルを示す図である。 グループ管理テーブルを示す図である。 ネットワークシステムの処理を示すシーケンス図である。 Ｎｏｔｉｆｙ制御装置のハードウェア構成例を示す図である。 Ｎｏｔｉｆｙ制御装置の機能を示すブロック図である。 Ｎｏｔｉｆｙ制御装置の処理を示すフローチャートである。 処理の具体例を示すシーケンス図である。 ＨＴＴＰロードバランサの処理を示すフローチャートである。 Ｎｏｔｉｆｙ制御装置が有する機能を他の装置に実装した例を示す図である。 Ｎｏｔｉｆｙ制御装置が有する機能を他の装置に実装した例を示す図である。 第２の実施の形態のＮｏｔｉｆｙ制御装置の機能を示すブロック図である。 処理対象サーバリストを示す図である。 第２の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。 第３の実施の形態の振り分け先管理テーブルを示す図である。 第３の実施の形態のＮｏｔｉｆｙ制御装置の機能を示すブロック図である。 第３の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。 第４の実施の形態のＮｏｔｉｆｙ制御装置を示すブロック図である。 認証サーバが備えるユーザ利用状況管理テーブルを示す図である。 第４の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。 負荷分散を行うシステムの構成を示す図である。

符号の説明

１ イベント制御装置
１ａ 受信手段
１ｂ 要求手段
１ｃ 転送手段
２ 負荷分散装置
３ａ〜３ｃ、６０ａ、６０ｂ サーバ
４ａ、４ｂ、１０ａ、１０ｂ クライアント
１１ａ、１１ｂ Ｗｅｂブラウザ
２０ａ、２０ｂ タグリーダー
３０、３０１ ＨＴＴＰロードバランサ
３０ａ、３０ｂ 振り分け先管理テーブル
４０、４０１ プレゼンスサーバ
４０ａ Ｓｕｂｓｃｒｉｂｅ管理テーブル
４１ Ｎｏｔｉｆｙ配信部
４２ Ｎｏｔｉｆｙ制御部
５０、５０１、５０２、５０３ Ｎｏｔｉｆｙ制御装置
５０ａ グループ管理テーブル
５０ｂ 処理対象サーバリスト
５１ Ｎｏｔｉｆｙ受信部
５２、５２ａ 管理テーブル格納部
５３、５３ａ 検索部
５４ アドレス要求部
５５ 転送判定部
５６ 認証要求部
６１ａ、６１ｂ Ｗｅｂアプリケーション
７０ 認証サーバ
７０ａ ユーザ利用状況管理テーブル
１００、１００ａ、１００ｂ ネットワークシステム

Claims (6)

1. イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムにおいて、
   前記イベント制御装置を、
   クライアントを指定する指定情報を含むイベントの通知要求を受信する受信手段、
   前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求手段、
   前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送手段、
   として機能させることを特徴とするイベント制御プログラム。
2. 前記受信手段は、前記通知要求をプレゼンスサーバから受信し、
   前記要求手段は、前記通知要求を分散処理装置に要求し、
   前記サーバは、アプリケーションサーバである、
   ことを特徴とする請求項１記載のイベント制御プログラム。
3. 前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
   前記転送手段は、通知された前記振り分け先と、前記宛先とが一致した場合のみ前記振り分け先のサーバに対し、前記イベントの通知要求を転送することを特徴とする請求項１または２記載のイベント制御プログラム。
4. 前記指定情報は、前記クライアントの識別情報以外の情報であり、
   前記イベント制御装置を、前記指定情報と前記クライアントの識別情報とを関連づけて格納する格納手段、
   前記受信手段により前記イベントの通知要求が受信されると、受信した前記イベントの通知要求に含まれる前記指定情報に応じた前記クライアントの識別情報を前記格納手段から検索する検索手段、として機能させ、
   前記要求手段は、前記検索手段により検索された前記クライアントの識別情報に基づいて、前記振り分け先のサーバの通知を要求することを特徴とする請求項１から３の何れかに記載のイベント制御プログラム。
5. イベントの中継制御を、受信手段と要求手段と転送手段を有するイベント制御装置に実行させるイベント制御方法において、
   前記受信手段が、クライアントを指定する指定情報を含むイベントの通知要求を受信し、
   前記要求手段が、前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
   前記転送手段が、前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する、
   ことを特徴とするイベント制御方法。
6. イベントの中継制御を行うイベント制御装置において、
   クライアントを指定する指定情報を含むイベントの通知要求を受信する受信部と、
   前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求部と、
   前記要求部による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送部と、
   を有することを特徴とするイベント制御装置。

Images