(57)【特許請求の範囲】
【請求項１】
イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムにおいて、
前記イベント制御装置を、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信手段、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求手段、
前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送手段、
として機能させることを特徴とするイベント制御プログラム。
【請求項２】
前記受信手段は、前記通知要求をプレゼンスサーバから受信し、
前記要求手段は、前記通知要求を分散処理装置に要求し、
前記サーバは、アプリケーションサーバである、
ことを特徴とする請求項１記載のイベント制御プログラム。
【請求項３】
前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記転送手段は、通知された前記振り分け先と、前記宛先とが一致した場合のみ前記振り分け先のサーバに対し、前記イベントの通知要求を転送することを特徴とする請求項１または２記載のイベント制御プログラム。
【請求項４】
前記指定情報は、前記クライアントの識別情報以外の情報であり、
前記イベント制御装置を、前記指定情報と前記クライアントの識別情報とを関連づけて格納する格納手段、
前記受信手段により前記イベントの通知要求が受信されると、受信した前記イベントの通知要求に含まれる前記指定情報に応じた前記クライアントの識別情報を前記格納手段から検索する検索手段、として機能させ、
前記要求手段は、前記検索手段により検索された前記クライアントの識別情報に基づいて、前記振り分け先のサーバの通知を要求することを特徴とする請求項１から３の何れかに記載のイベント制御プログラム。
【請求項５】
イベントの中継制御を、受信手段と要求手段と転送手段を有するイベント制御装置に実行させるイベント制御方法において、
前記受信手段が、クライアントを指定する指定情報を含むイベントの通知要求を受信し、
前記要求手段が、前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段が、前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する、
ことを特徴とするイベント制御方法。
【請求項６】
イベントの中継制御を行うイベント制御装置において、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信部と、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求部と、
前記要求部による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送部と、
を有することを特徴とするイベント制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はイベント制御プログラム、イベント制御方法およびイベント制御装置に関し、特に、複数のプロトコルを利用するサービスに用いるイベント制御プログラム、イベント制御方法およびイベント制御装置に関する。
【背景技術】
【０００２】
近年、Ｗｅｂ上のサービスにおいて、ＨＴＴＰ（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）等が挙げられる。
【０１４８】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１４９】
イベント制御プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１５０】
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）  イベントの中継制御をイベント制御装置に実行させるイベント制御プログラムにおいて、
前記イベント制御装置を、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信手段、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求手段、
前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送手段、
として機能させることを特徴とするイベント制御プログラム。
【０１５１】
（付記２）  前記受信手段は、前記通知要求をプレゼンスサーバから受信し、
前記要求手段は、前記通知要求を分散処理装置に要求し、
前記サーバは、アプリケーションサーバである、
ことを特徴とする付記１記載のイベント制御プログラム。
【０１５２】
（付記３）  前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記転送手段は、通知された前記振り分け先と、前記宛先とが一致した場合のみ前記振り分け先のサーバに対し、前記イベントの通知要求を転送することを特徴とする付記１または２記載のイベント制御プログラム。
【０１５３】
（付記４）  前記指定情報は、前記クライアントの識別情報以外の情報であり、
前記イベント制御装置を、前記指定情報と前記クライアントの識別情報とを関連づけて格納する格納手段、
前記受信手段により前記イベントの通知要求が受信されると、受信した前記イベントの通知要求に含まれる前記指定情報に応じた前記クライアントの識別情報を前記格納手段から検索する検索手段、として機能させ、
前記要求手段は、前記検索手段により検索された前記クライアントの識別情報に基づいて、前記振り分け先のサーバの通知を要求することを特徴とする付記１から３の何れかに記載のイベント制御プログラム。
【０１５４】
（付記５）  前記要求手段は、前記サーバの負荷を分散する機能を備え前記クライアントとセッションが確立しているサーバの情報を格納する負荷分散装置に対して前記振り分け先のサーバの通知を要求することを特徴とする付記１記載のイベント制御プログラム。
【０１５５】
（付記６）  前記負荷分散装置は、前記指定情報に基づいた前記振り分け先のサーバが存在しない場合、任意のリストから前記振り分け先のサーバを選択し、前記要求手段に応答することを特徴とする付記４記載のイベント制御プログラム。
【０１５６】
（付記７）  前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記要求手段は、前記振り分け先のサーバの通知を要求した要求先から前記振り分け先のサーバが通知されなかった場合、前記要求先に対し、前記指定情報に応じた前記宛先の登録を要求することを特徴とする付記１記載のイベント制御プログラム。
【０１５７】
（付記８）  前記イベントの通知要求には、前記イベントの通知を要求するサーバの宛先が含まれており、
前記格納手段は、処理対象のサーバの識別情報を格納するリストを格納しており、
前記検索手段は、前記宛先が、前記リストに含まれている場合、振り分け先のサーバの通知を要求することなく前記リストに含まれているサーバに対し、前記イベントの通知要求を前記第１のプロトコルで転送することを特徴とする付記１記載のイベント制御プログラム。
【０１５８】
（付記９）  前記受信手段は、第１のプロトコルで送信された前記イベントの通知要求を受信し、
前記要求手段は、前記指定情報によって指定されるクライアントに対して第２のプロトコルでサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段は、前記イベントの通知要求を前記第１のプロトコルで転送することを特徴とする付記１記載のイベント制御プログラム。
【０１５９】
（付記１０）  イベントの中継制御を、受信手段と要求手段と転送手段を有するイベント制御装置に実行させるイベント制御方法において、
前記受信手段が、クライアントを指定する指定情報を含むイベントの通知要求を受信し、
前記要求手段が、前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求し、
前記転送手段が、前記要求手段による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する、
ことを特徴とするイベント制御方法。
【０１６０】
（付記１１）  イベントの中継制御を行うイベント制御装置において、
クライアントを指定する指定情報を含むイベントの通知要求を受信する受信部と、
前記指定情報に基づいて、複数のサーバのうち、前記指定情報によって特定されるクライアントに対してサービスを提供しているサーバを振り分け先のサーバとして通知するよう要求する要求部と、
前記要求部による要求に応じて通知された前記振り分け先のサーバに、前記イベントの通知要求を転送する転送部と、
を有することを特徴とするイベント制御装置。
【図面の簡単な説明】
【０１６１】
【図１】実施の形態のコンピュータシステムの概要を示す図である。
【図２】ネットワークシステムの構成を示す図である。
【図３】振り分け先管理テーブルを示す図である。
【図４】Ｓｕｂｓｃｒｉｂｅ管理テーブルを示す図である。
【図５】グループ管理テーブルを示す図である。
【図６】ネットワークシステムの処理を示すシーケンス図である。
【図７】Ｎｏｔｉｆｙ制御装置のハードウェア構成例を示す図である。
【図８】Ｎｏｔｉｆｙ制御装置の機能を示すブロック図である。
【図９】Ｎｏｔｉｆｙ制御装置の処理を示すフローチャートである。
【図１０】処理の具体例を示すシーケンス図である。
【図１１】ＨＴＴＰロードバランサの処理を示すフローチャートである。
【図１２】Ｎｏｔｉｆｙ制御装置が有する機能を他の装置に実装した例を示す図である。
【図１３】Ｎｏｔｉｆｙ制御装置が有する機能を他の装置に実装した例を示す図である。
【図１４】第２の実施の形態のＮｏｔｉｆｙ制御装置の機能を示すブロック図である。
【図１５】処理対象サーバリストを示す図である。
【図１６】第２の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。
【図１７】第３の実施の形態の振り分け先管理テーブルを示す図である。
【図１８】第３の実施の形態のＮｏｔｉｆｙ制御装置の機能を示すブロック図である。
【図１９】第３の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。
【図２０】第４の実施の形態のＮｏｔｉｆｙ制御装置を示すブロック図である。
【図２１】認証サーバが備えるユーザ利用状況管理テーブルを示す図である。
【図２２】第４の実施の形態のＮｏｔｉｆｙ制御装置の処理を示すフローチャートである。
【図２３】負荷分散を行うシステムの構成を示す図である。
【符号の説明】
【０１６２】
１  イベント制御装置
１ａ  受信手段
１ｂ  要求手段
１ｃ  転送手段
２  負荷分散装置
３ａ〜３ｃ、６０ａ、６０ｂ  サーバ
４ａ、４ｂ、１０ａ、１０ｂ  クライアント
１１ａ、１１ｂ  Ｗｅｂブラウザ
２０ａ、２０ｂ  タグリーダー
３０、３０１  ＨＴＴＰロードバランサ
３０ａ、３０ｂ  振り分け先管理テーブル
４０、４０１  プレゼンスサーバ
４０ａ  Ｓｕｂｓｃｒｉｂｅ管理テーブル
４１  Ｎｏｔｉｆｙ配信部
４２  Ｎｏｔｉｆｙ制御部
５０、５０１、５０２、５０３  Ｎｏｔｉｆｙ制御装置
５０ａ  グループ管理テーブル
５０ｂ  処理対象サーバリスト
５１  Ｎｏｔｉｆｙ受信部
５２、５２ａ  管理テーブル格納部
５３、５３ａ  検索部
５４  アドレス要求部
５５  転送判定部
５６  認証要求部
６１ａ、６１ｂ  Ｗｅｂアプリケーション
７０  認証サーバ
７０ａ  ユーザ利用状況管理テーブル
１００、１００ａ、１００ｂ  ネットワークシステム
【図１】
0005029495.tif 000002
【図２】
0005029495.tif 000003
【図３】
0005029495.tif 000004
【図４】
0005029495.tif 000005
【図５】
0005029495.tif 000006
【図６】
0005029495.tif 000007
【図７】
0005029495.tif 000008
【図８】
0005029495.tif 000009
【図９】
0005029495.tif 000010
【図１０】
0005029495.tif 000011
【図１１】
0005029495.tif 000012
【図１２】
0005029495.tif 000013
【図１３】
0005029495.tif 000014
【図１４】
0005029495.tif 000015
【図１５】
0005029495.tif 000016
【図１６】
0005029495.tif 000017
【図１７】
0005029495.tif 000018
【図１８】
0005029495.tif 000019
【図１９】
0005029495.tif 000020
【図２０】
0005029495.tif 000021
【図２１】
0005029495.tif 000022
【図２２】
0005029495.tif 000023
【図２３】
0005029495.tif 000024