JP2007293503A - デバイス、その制御方法、及びプログラム - Google Patents

Abstract

【課題】イベントに係る通信に使用するプロトコルをイベント提供装置にかかる通信負荷を考慮して柔軟に変更できるようにする。
【解決手段】デバイスは、クライアントから送信されるイベント登録要求を受信し、その受信したイベント登録要求に基づいて、発生したイベントをクライアントに通知する。また、デバイスは、イベントの通知に対する通信負荷に係る閾値を記憶しており、イベント登録要求を受信した場合、イベントの通知に対する通信負荷が前記閾値を超えるか否かを判定する。そして、デバイスは、その判定結果に基づいて、前記イベント登録要求に対するイベントの通知の為に使用するプロトコルを決定する。
【選択図】図２

Description

本発明は、クライアント装置からの要求に応じてイベントを通信媒体を介して提供する場合のプロトコルの選択技術に関する。

従来、ネットワーク上のクライアント装置からのイベント登録要求に基づいて、イベント提供装置の状態の遷移時などにイベントをクライアント装置に送信するイベント提供システムが知られている。

また、イベントを提供するイベント提供装置でのイベント登録、登録イベントの削除、イベントの制御・表示等を行うアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等を提供するための各種のプロトコル、アーキテクチャが提案されている。

さらに、複数の企業、標準化団体が、イベント登録、イベント送信、登録イベント削除等の標準的な方法の拡張に対応すべく、仕様の策定作業を進めている。
特開平１１−２２４２２６

上述の従来技術を用いてイベントを利用することによって即時情報更新が可能となりユーザの利便性が向上する。しかしながら、イベント登録要求を行うクライアント装置が多くなると、イベントを送信するイベント提供装置の通信部に大きな通信負荷がかかるという問題があった。

すなわち、一般に、ＴＣＰプロトコルは、ＵＤＰプロトコルに比べて、通信部に対して大きな通信負荷がかかる。また、ＩＰＳｅｃやＳＳＬプロトコルは、ＴＣＰプロトコルに比べて、通信部に対して大きな通信負荷がかかる。

そのため、一般ユーザの利用するアプリケーションが高負荷のかかるプロトコルを利用してしまう場合に、管理者のネットワーク機器管理アプリケーションが使えなくなる場合があった。

また、イベントを送信するイベント提供装置のイベント送信先数（エンドポイント数）は、プロトコル毎、又は全プロトコルで登録数に限界がある。そのため、一般ユーザの通信機器モニタアプリケーションにより、エンドポイント数の上限までイベント登録がなされてしまうと、管理者のネットワーク機器管理アプリケーションがイベント登録を行えなくなっていた。

本発明は、このような背景の下になされたもので、その目的は、イベントに係る通信に使用するプロトコルをイベント提供装置にかかる通信負荷を考慮して柔軟に変更できるようにすることにある。

上記目的を達成するため、本発明に係るデバイスは、ネットワーク上の情報処理装置から送信されるイベント登録要求を受信する受信手段と、前記受信手段で受信したイベント登録要求に基づいて、発生したイベントを前記情報処理装置に通知する通知手段と、イベントの通知に対する通信負荷に係る閾値を記憶する記憶手段と、前記受信手段がイベント登録要求を受信した場合、イベントの通知に対する通信負荷が前記閾値を超えるか否かを判定する判定手段と、前記判定手段による判定結果に基づいて、前記イベント登録要求に対するイベントの通知の為に使用するプロトコルを決定する決定手段とを有している。

本発明によれば、イベントに係る通信に使用するプロトコルをイベント提供装置にかかる通信負荷を考慮して柔軟に変更することが可能となる。

以下、本発明を実施するための最良の形態を、図面に基づいて説明する。

［第１の実施の形態］
図１は、本発明の第１〜第３の実施の形態に係るイベント提供装置（デバイス）を含む通信システムのシステム構成図である。なお、本システム構成図は、主として、イベント登録を行うユーティリティソフトウエアの構成を示したものである。

図１に示したように、本通信システムは、クライアント装置１００とネットワーク対応装置（デバイス）２００を有し、両装置はＥｔｈｅｒｎｅｔ(登録商標)等のネットワークにより接続されている。なお、本実施の形態では、クライアント装置１００としては、パーソナルコンピュータ等の情報処理装置を想定している。ネットワーク対応装置２００としては、プリンタを想定しているが、スキャナ、コピー機、ファクシミリ、複合機等であってもよく、ネットワークに接続可能なデバイスである。また、ネットワーク対応装置２００としてのプリンタは、イベント提供装置として機能している。さらには、実際には複数のクライアント装置１００がネットワークを介してネットワーク対応装置２００に接続されているが、図１では、１台のクライアント装置１００だけを図示している。

図１において、クライアント装置１００は、Ｅｔｈｅｒｎｅｔ(登録商標)に対応した通信機能を有している。すなわち、クライアント装置１００は、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１、及びＨＴＴＰ２を備え、これらを用いてＨＴＴＰリクエストの解析、レスポンス処理等を行う。

また、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１、およびＨＴＴＰ２の上位層には、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）プロセッサ３が設けられている。ユーティリティ９、及びＷＳＥモジュール５は、ＳＯＡＰプロセッサ３の制御の下にＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されたデータの双方向通信を行う。

また、イベント制御モジュール４は、イベントを制御し、イベント登録やイベント受信に必要な情報をメモリコントローラ６を介して記憶装置８に書込み、読出し、消去する。

また、イベント制御モジュール４は、Ｓｕｂｓｃｒｉｂｅ等のメッセージの送信処理をＷＳＥモジュール５に対して依頼する。

ＷＳＥモジュール５は、ＳＯＡＰプロセッサ３の制御の下に、イベント登録時のＳｕｂｓｃｒｉｂｅ、登録イベント削除時のＵｎｓｕｂｓｃｒｉｂｅ等のメッセージをネットワーク対応装置２００に発行する発行処理を行う。Ｓｕｂｓｃｒｉｂｅとは、デバイスで発生したイベントのうち、クライアント装置に通知すべきイベントの内容を登録するための要求である。Ｕｎｓｕｂｓｃｒｉｂｅとは、デバイスに登録されたイベントを削除するための要求である。ＷＳＥモジュール５は、上記の発行メッセージに基づいてネットワーク対応装置２００から通知されるＮｏｔｉｆｉｃａｔｉｏｎメッセージに対する処理を行う。この場合、ネットワーク対応装置２００は、登録イベントに係る状態遷移があると、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージをクライアント装置１００に送信する。

イベント制御モジュール４は、上記のＮｏｔｉｆｉｃａｔｉｏｎメッセージを受信した場合、そのメッセージをユーティリティ９、アプリケーション１０など、当該イベント制御モジュール４に対してイベント要求を行ったソフトウェアに対して通知する。なお、受信に係るイベント、メッセージ等は、メモリコントローラ６により、記憶装置８に格納される。

ネットワーク対応装置２００は、クライアント装置１００と同様に、Ｅｔｈｅｒｎｅｔ(登録商標)に対応した通信機能を有している。すなわち、ネットワーク対応装置２００は、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１１、及びＨＴＴＰ１２を備え、これらを用いてＨＴＴＰリクエストの解析、レスポンス処理等を行う。

ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１１、ＨＴＴＰ１２の上位層には、ＳＯＡＰプロセッサ１３が設けられている。ＷＳＥモジュール１５、及びプリンタコントローラ１６は、ＳＯＡＰプロセッサ１３の制御の下に、ＸＭＬで記述されたデータの双方向通信を行う。

ＷＳＥモジュール１５は、ＳＯＡＰプロセッサ１３の制御の下に、クライアント装置１００から発行されるイベント登録時のＳｕｂｓｃｒｉｂｅメッセージに対する応答処理を行う。同様に、ＷＳＥモジュール１５は、登録イベント削除時のＵｎｓｕｂｓｃｒｉｂｅメッセージに対する応答処理、イベント送信時のＮｏｔｉｆｉｃａｔｉｏｎメッセージの通知等を行う。

ユーザ認証／権限確認モジュール２０は、クライアント装置１００から送信されてきたＳｕｂｓｃｒｉｂｅメッセージ等に添付されているユーザ証明書に基づいてユーザ認証を行う。また、ユーザ認証／権限確認モジュール２０は、認証したユーザがＳｕｂｓｃｒｉｂｅ時のイベントの登録権限を有するか否かを判定したり、Ｎｏｔｉｆｙ時のイベント通知用プロトコルが許可されたプロトコルであるか否かを判定したりする。

なお、ユーザ認証／権限確認モジュール２０は、ネットワーク対応装置２００が保持する、又はネットワークを経由して入手可能なルート証明機関の証明書を用いてユーザ認証を行う。また、ユーザ認証／権限確認モジュール２０は、ユーザの権限情報を管理するユーザ管理サーバに問い合わせることにより、権限確認を行う。

プロトコル決定モジュール２１は、ネットワーク対応装置２００にかかる通信負荷やネットワークリソースの不足により、クライアント装置１００へのイベント送信に利用するプロトコルを利用できない、或いは利用制限を行う必要があるのか否かを判定する。

次に、第１の実施の形態におけるイベント登録処理を図２のフローチャートに基づいて説明する。なお、本実施形態におけるＳｕｂｓｃｒｉｂｅメッセージは、図３に示したフォーマットでＸＭＬ−ＳＯＡＰで記述されている。

図２において、クライアント装置１００は、ネットワーク対応装置２００に対して、イベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージをＳＯＡＰメッセージとして送信する（ステップＳ２０１）。このクライアント装置における送信処理は、イベント制御モジュール４の制御により、ＷＳＥモジュール５、ＳＯＡＰプロセッサ３、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１を介して行われる。

ネットワーク対応装置２００は、このイベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージをネットワークを介して受信する（ステップＳ２０２）。この受信したＳｕｂｓｃｒｉｂｅメッセージは、ＴＣＰ／ＵＤＰ／ＩＰプロトコルスタック１１を介してＳＯＡＰプロセッサ１３に通知されて解析される。そして、ＳＯＡＰプロセッサ１３は、その解析結果をＷＳＥモジュール１５に通知する。ＷＳＥモジュール１５は、ＳＯＡＰプロセッサ１３から通知されたＳｕｂｓｃｒｉｂｅメッセージを解析し、イベント制御モジュール１４に通知する。

イベント制御モジュール１４は、イベント登録テーブルの情報を取得する（ステップＳ２０３）。このテーブル情報の取得処理は、イベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージを送信したクライアント装置１００のアドレス（イベント登録アドレス）と、ネットワーク対応装置２００に登録済みのイベントのイベント通知先アドレス（ＥｎｄＰｏｉｎｔ）を比較するために行われる。なお、イベント登録テーブルは、記憶装置１８上に構築されている。

イベント制御モジュール１４は、イベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージ中のイベント通知先アドレスが新規のＥｎｄＰｏｉｎｔであるか否かを判別する（ステップＳ２０４）。その結果、当該イベント通知先アドレスが既にイベント登録テーブルに登録されている場合は、イベント制御モジュール１４は、イベント登録テーブル上の当該イベント通知先アドレスに係るイベントを更新する（ステップＳ２０８）。即ち、新規のＥｎｄＰｏｉｎｔでない場合は、イベント制御モジュール１４は、イベント登録テーブル上の当該イベント通知先アドレスに係るイベントを更新する。この更新処理では、受信したイベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージに記述されたイベントが、イベント登録テーブル上の既存のイベント通知先アドレスと対応付けて新たに登録されることとなる。

次に、イベント制御モジュール１４は、Ｓｕｂｓｃｒｉｂｅの結果、すなわち要求に係るイベントを登録した旨のメッセージをクライアント装置１００に返信する（ステップＳ２０９）。

ステップＳ２０４にて、登録要求に係るイベント通知先アドレスが新規のＥｎｄＰｏｉｎｔであると判別された場合は、ステップＳ２０５に進む。ステップＳ２０５において、イベント制御モジュール１４は、プロトコル決定モジュール２１により、リクエストプロトコルでの新規イベント登録が可能であるか否かを判別させる。なお、リクエストプロトコルとは、イベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージでイベント返信（通知）時のプロトコルとして要求されたプロトコルを意味する。

リクエストプロトコルでの新規イベント登録が可能であると判別された場合は、イベント制御モジュール１４は、イベント登録テーブル上の当該イベント通知先アドレスに係るイベントを更新する（ステップＳ２０８）。この更新処理では、受信したイベント登録要求のＳｕｂｓｃｒｉｂｅメッセージに係るイベントと、当該メッセージ中でリクエストされたプロトコルとが、当該Ｓｕｂｓｃｒｉｂｅメッセージ中のイベント通知先アドレスと対応付けてイベント登録テーブルに登録される。この更新登録情報は、Ｓｕｂｓｃｒｉｂｅの結果として、クライアント装置１００に返信される（ステップＳ２０９）。

一方、クライアント装置１００がリクエストするプロトコルでのイベント登録が不可能であれば、イベント制御モジュール１４は、プロトコル決定モジュール２１により、登録可能な他のイベントプロトコルがあるか否かを判別させる（ステップＳ２０６）。

このステップＳ２０６の判別処理は、次のようにして行なわれる。例えば、ネットワーク対応装置２００は、通信負荷を考慮すると、通信負荷が比較的に大きなＴＣＰを５ＥｎｄＰｏｉｎｔ、通信負荷が比較的に小さなＵＤＰを１０ＥｎｄＰｏｉｎｔ登録（返信）できるものとする。また、ネットワーク対応装置２００は、現在、既にＴＣＰの５ＥｎｄＰｏｉｎｔが全て登録済みであり、ＵＤＰのＥｎｄＰｏｉｎｔが未だ登録可能状態にあったものとする。さらに、この状態でクライアント装置１００からのイベント登録（Ｓｕｂｓｃｒｉｂｅ）でＴＣＰによるイベント登録のリクエストがあったものとする。

この場合、プロトコル決定モジュール２１は、当該Ｓｕｂｓｃｒｉｂｅについて、リクエストプロトコルであるＴＣＰでのイベント登録は不可能であるが、ＵＤＰでのイベント登録は可能であると判定する。

なお、クライアント装置１００がイベント登録要求時に利用するプロトコルでイベント通知を行わない場合には、予め決められた優先プロトコルから１つのプロトコルを決定するように構成することも考えられる。また、ステップＳ２０５の判別処理も、同様に、ネットワーク対応装置２００にかかる通信負荷を考慮してプロトコル毎に設定されたエンドポイント数に基づいて行っている。

イベント制御モジュール１４は、プロトコル決定モジュール２１により、登録可能なイベントプロトコルが無いと判別された場合は、イベント登録テーブル上の当該イベント通知先アドレスに係るイベントを更新する（ステップＳ２０８）。この更新処理では、リクエストに係るイベント通知先アドレスだけが新規のＥｎｄＰｏｉｎｔとして登録され、リクエストに係るプロトコルとは登録されることはない。この更新登録情報は、Ｓｕｂｓｃｒｉｂｅの結果として、クライアント装置１００に返信される（ステップＳ２０９）。

一方、イベント制御モジュール１４は、登録可能なイベントプロトコルが有るとプロトコル決定モジュール２１により判別された場合、その登録可能なイベントプロトコルをクライアント装置１００に通知するためのメッセージを返信する（ステップＳ２０７）。

クライアント装置１００は、この登録可能なイベントプロトコルを通知するメッセージを受信する（ステップＳ２１０）。この場合、クライアント装置１００は、その登録可能プロトコルをイベント返信用プロトコルとして指定してイベントの再登録を行うべく、イベント登録要求のＳｕｂｓｃｒｉｂｅメッセージを作成し直す（ステップＳ２１１）。そして、クライアント装置１００は、ステップＳ２０１に戻り、この作成し直したイベント登録要求のＳｕｂｓｃｒｉｂｅメッセージを、通知に係る登録可能なプロトコルによりネットワーク対応装置２００に再送信する。

この場合、ネットワーク対応装置２００は、再送されたイベント登録要求のＳｕｂｓｃｒｉｂｅメッセージに基づいて、イベント登録テーブル上の該当するイベント通知先アドレスと対応付けて、通知に係る登録可能なプロトコルを登録する（ステップＳ２０４→Ｓ２０８の処理）。

また、クライアント装置１００は、ステップＳ２０９で返信されたＳｕｂｓｃｒｉｂｅの結果に係るメッセージを受信することにより、イベント待ち状態に遷移する（ステップＳ２１２）。

一方、ネットワーク対応装置２００は、イベントが発生すると（ステップＳ２１３）、そのイベント情報を、対応するクライアント装置１００に送信する（ステップＳ２１４）。

この場合、イベント待ち状態に遷移していたクライアント装置１００は、自己宛のイベント情報を受信する（ステップＳ２１５）。

なお、ステップＳ２１３〜Ｓ２１５のイベント発生からイベント受信までのフローは、一般的なイベント登録プロトコルと同様にＳｕｂｓｃｒｉｂｅからＵｎ Ｓｕｂｓｃｒｉｂｅまでの期間は有効であり、その有効期間中は繰り返し実行される。

以上説明したように、第１の実施の形態では、イベント提供装置としてのネットワーク対応装置２００は、イベント返信時の通信負荷を考慮して、プロトコル毎にイベント登録可能なユーザ（クライアント装置）の数、すなわちエンドポイント数を設定している。そして、ネットワーク対応装置２００は、クライアント装置１００からイベント登録要求があった場合は、そのエンドポイント数の範囲内でイベント登録処理を行う。この際、ネットワーク対応装置２００は、イベント返信時のプロトコルとして、登録要求に係るプロトコルは登録できないが、通信負荷の小さな他のプロトコルは登録できる場合は、そのプロトコルをクライアント装置１００に通知する。ネットワーク対応装置２００は、その通知に係るプロトコルをイベント返信時のプロトコルとする旨のイベント登録要求が再度なされた場合は、正式にイベント登録処理を行う。

従って、イベントに係る通信に使用するプロトコルをイベント提供装置にかかる通信負荷を考慮して柔軟に変更することが可能となる。さらには、管理者が利用するネットワーク機器管理アプリケーションを利用できなくなるといった事態を回避することが可能となる。

［第２の実施の形態］
第２の実施の形態は、ネットワーク対応装置２００において、イベント登録をリクエストしたユーザを特定し、イベント返信プロトコルの利用制限を行うものである。なお、第２の実施の形態におけるシステム構成は、図１に示した第１の実施の形態に係るシステム構成と全く同様である。また、図４に示した第２の実施の形態に係るイベント登録処理は、図２に示した第１の実施の形態に係るイベント登録処理と重複する部分が多く、ここでは、相違点を主として説明する。また、図４では、図２と同一の処理内容に係るステップには、同一のステップ番号を付している。

図４において、ネットワーク対応装置２００は、クライアント装置１００から送信されてきたイベント登録リクエストのＳｕｂｓｃｒｉｂｅメッセージを受信する（ステップＳ２０１）。この受信メッセージは、ＷＳＥモジュール１５からユーザ認証／権限確認モジュール２０に通知される。ここで、イベント登録をリクエストしたクライアント装置１００が新規のＥｎｄＰｏｉｎｔであったものとする（ステップＳ２０４）。この場合、ユーザ認証／権限確認モジュール２０は、記憶装置１８に格納されている各ユーザのイベント登録権限情報のリストを取得する（ステップＳ４０１）。

そして、ユーザ認証／権限確認モジュール２０は、各ユーザのイベント登録権限情報のリストに基づいて、イベント登録リクエストに係るＳｕｂｓｃｒｉｂｅメッセージを送信したユーザについて、ユーザ認証を行う。また、当該ユーザのイベント登録権限を判別する（ステップＳ４０２）。この場合、ユーザ認証／権限確認モジュール２０は、イベント登録要求に係るＳｕｂｓｃｒｉｂｅメッセージに添付されたユーザ証明書を用いて、チャレンジ・レスポンス方式等によって、ユーザ認証処理を行い、イベント登録権限の有無を判別する。

なお、イベント登録権限の有無の判別処理は、ユーザを認証できたことを条件として行われる。また、ユーザ認証／権限確認処理は、ユーザの権限情報を管理するユーザ権限管理サーバ等に問い合わせることにより、又はネットワークを経由して入手可能なルート証明機関の証明書を用いて行う。

さらに、イベント登録権限の有無だけでなく、クライアント装置１００に対してＮｏｔｉｆｙを行う際のイベント返信（通知）用プロトコルが許可されたプロトコルであるか否かの確認処理を行うことも可能である。

ユーザを認証できない場合、当該ユーザにイベント登録権限が無い場合、或いはＮｏｔｉｆｙを行う際のイベント返信用プロトコルが許可されたプロトコルでない場合は、イベント制御モジュール１４は、イベント登録要求を行ったクライアント装置１００にイベント登録の失敗を通知する（ステップＳ４０３）。この通知を受けて、クライアント装置１００は、イベント登録処理を終了する。

図５は、ユーザ毎のイベント送信で利用可能なプロトコル情報を例示した図である。図５に示したように、ユーザ名５０１と対応付けて、当該ユーザがイベント返信時に使用可能なプロトコル名が登録されている。このプロトコル情報は、記憶装置１８に予め記憶されている。

イベント登録権限があり、Ｎｏｔｉｆｙを行う際のイベント返信用プロトコルが許可されたプロトコルである場合、権限確認により権限がある場合は、続いて、リクエストプロトコルでの新規イベント登録が可能か判定を行う（ステップＳ２０５）。

以上の処理により、ユーザ毎にイベント返信で利用可能なプロトコルを制限することが可能となる。

［第３の実施の形態］
第３の実施の形態は、イベント登録処理を行うに当たり、ネットワーク対応装置２００でのイベント返信時の通信負荷が高くなる場合は、一般ユーザのイベント返信プロトコルを変更するものである。

なお、第３の実施の形態におけるシステム構成は、図１に示した第１の実施の形態に係るシステム構成と全く同様である。また、図６に示した第３の実施の形態に係るイベント登録処理は、図２、図４に示した第１，第２の実施の形態に係るイベント登録処理と重複する部分が多く、ここでは、相違点を主として説明する。また、図６では、図２，図４と同一の処理内容に係るステップには、同一のステップ番号を付している。

図６において、イベント登録処理を行う際のステップＳ２０１〜Ｓ２１５の処理は、第１の実施の形態と同様なので、その説明を省略する。

今、例えば多数のクライアント装置１００からのイベント登録要求が同時間帯に集中してイベント返信時の通信負荷が急増する可能性がある等のプロトコル変更要因が発生したものとする（ステップＳ６０１）。このようなプロトコル変更要因が発生した場合、イベント制御モジュール１４は、イベント返信用プロトコルを変更する必要があるか否かを判別する（ステップＳ６０２）。

この判別基準は、次のようにして決定することができる。ネットワーク対応装置２００において、例えば、イベント送信時の通信負荷のＣＰＵ負荷に対する割合、ＴＣＰのＥｎｄＰｏｉｎｔの最大許容登録数等、イベント送信時の通信処理負荷の閾値を予め決めておく。そして、この閾値を越えた場合に、負荷が比較的大きなＴＣＰプロトコルから負荷が比較的小さなＵＤＰプロトコルに変更する等の方法が考えられる。

イベント制御モジュール１４は、イベント返信用プロトコルを変更する必要がない場合は、終了する。一方、イベント返信用プロトコルを変更する必要がある場合は、イベント制御モジュール１４は、変更後の登録可能なプロトコルをクライアント装置１００に通知する（ステップＳ６０３）。尚、図５のテーブルにおいて、ユーザ毎に優先度を対応付けて管理することにより、優先度のより低いユーザのクライアント装置に対してのみ、変更要求を通知するようにしてもよい。

クライアント装置１００は、登録可能なプロトコルの通知を受信し（ステップＳ６０４）、登録可能なプロトコルをイベント返信用プロトコルとして指定するＳｕｂｓｃｒｉｂｅメッセージにより、イベントの登録要求を再度行う（ステップＳ６０５，Ｓ２０１）。

なお、本発明は、第１〜第３の実施の形態に限定されることはない。例えば、第１〜第３の実施の形態では、通信負荷が大きくなったために、イベント送信用プロトコルをＴＣＰからＵＤＰに変更する場合を想定している。しかし、ＴＣＰに対するＥｎｄＰｏｉｎｔが許容限度まで登録されている状態で、管理者権限のユーザがＴＣＰでイベント登録要求を行った場合は、一般ユーザのイベント送信用プロトコルをＴＣＰからＵＤＰに変更することも可能である。

また、クライアント装置１００によるイベント登録要求、及びネットワーク対応装置２００によるイベント通知（返信）を行う際には、ＷＳ−Ｅｖｅｎｔｉｎｇで定義されるプロトコルを採用しているが、他のプロトコルを利用することも可能である。

さらに、通信媒体としては、第１〜第３の実施の形態で使用したＥｔｈｅｒｎｅｔ(登録商標)以外の例えばローカルＩ／Ｏ、ネットワーク等を使用することも可能である。さらに、プリンタ以外のスキャナ、ストレージ装置等のネットワーク対応の装置をイベント提供装置として機能させることも可能である。

また、上述した実施例においては、ネットワーク対応装置２００がユーザの権限を確認するためのメモリ上に保持するデータにアクセスする形態を示した。ただし、ユーザ権限に限らず、事前設定されているデータベースアクセスや、アプリケーション、ユーティリティソフトウエアの保持するデータのアクセスに対しても適用可能である。また、これらのデータがネットワーク対応装置２００上に保持されている場合、あるいは第３のサーバ上に保持されている場合にも適用可能である。

この実施の形態に記載されているプロトコル、バージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。

また、本発明の目的は、前述した各実施の形態の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給することによって達成してもよい。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した各実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ等の光ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。または、プログラムコードをネットワークを介してダウンロードしてもよい。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した各実施の形態の機能が実現される場合も含まれる。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その拡張機能を拡張ボードや拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した各実施の形態の機能が実現される場合も含まれる。

本発明の第１〜第３の実施の形態に係るイベント提供装置（デバイス）を含む通信システムのシステム構成図である。 第１の実施の形態におけるイベント登録処理を示すフローチャートである。 Ｓｕｂｓｃｒｉｂｅメッセージ例を示す図である。 第２の実施の形態におけるイベント登録処理を示すフローチャートである。 ユーザ毎のイベント通知で利用可能なプロトコルを例示した図である。 第３の実施の形態におけるイベント登録処理を示すフローチャートである。

符号の説明

１，１１…ＴＣＰ／ＵＤＰ／ＩＰプロトコル
３，１３…ＳＯＡＰプロセッサ
４，１４…イベント制御モジュール
５，１５…ＷＳＥモジュール
１８…記憶装置
２０…ユーザ認証／権限確認モジュール
１００…クライアント装置
２００…ネットワーク対応装置（イベント提供装置）

Claims (9)

1. ネットワーク上の情報処理装置から送信されるイベント登録要求を受信する受信手段と、
   前記受信手段で受信したイベント登録要求に基づいて、発生したイベントを前記情報処理装置に通知する通知手段と、
   イベントの通知に対する通信負荷に係る閾値を記憶する記憶手段と、
   前記受信手段がイベント登録要求を受信した場合、イベントの通知に対する通信負荷が前記閾値を超えるか否かを判定する判定手段と、
   前記判定手段による判定結果に基づいて、前記イベント登録要求に対するイベントの通知の為に使用するプロトコルを決定する決定手段と、
   を有することを特徴とするデバイス。
2. 前記イベント登録要求は、該イベント登録要求に対するイベントの通知の為に使用するプロトコルの識別情報を含み、前記決定手段は、前記判定手段による判定結果に基づいて、該イベント登録要求において要求されているプロトコルを変更することを特徴とする請求項１に記載のデバイス。
3. 前記決定手段は、前記判定手段によってイベントの通知に対する通信負荷が前記閾値を超えると判定された場合、前記受信手段で受信したイベント登録要求において要求されているプロトコルを変更することを特徴とする請求項２に記載のデバイス。
4. 前記決定手段は、前記受信手段で受信したイベント登録要求において要求されているプロトコルを変更するに先立って、該イベント登録要求を送信した情報処理装置に変更後のプロトコルを通知し、当該変更後のプロトコルでイベント登録要求が再送された場合にプロトコルを変更することを特徴とする請求項２又は３に記載のデバイス。
5. 前記決定手段は、管理者としての権限を有するユーザ又は情報処理装置からイベント登録要求が送信されてきた際にプロトコルを変更する場合は、管理者以外のユーザ又はクライアント装置に係るプロトコルを変更することを特徴とする請求項１乃至４の何れかに記載のデバイス。
6. 前記イベント登録要求を送信したユーザ又は前記情報処理装置が前記デバイスにイベント登録を行う権限を有するか否かを判定する第２の判定手段を有することを特徴とする請求項２〜５の何れかに記載のデバイス。
7. 前記決定手段は、プロトコルを変更する場合は、通信負荷が小さいプロトコルに変更することを特徴とする請求項２〜６の何れかに記載のデバイス。
8. ネットワーク上の情報処理装置から送信されるイベント登録要求を受信する受信工程と、
   前記受信工程で受信したイベント登録要求に基づいて、発生したイベントを前記情報処理装置に通知する通知工程と、
   イベントの通知に対する通信負荷に係る閾値を記憶する記憶工程と、
   前記受信工程がイベント登録要求を受信した場合、イベントの通知に対する通信負荷が前記閾値を超えるか否かを判定する判定工程と、
   前記判定工程による判定結果に基づいて、前記イベント登録要求に対するイベントの通知の為に使用するプロトコルを決定する決定工程と、
   を有することを特徴とするデバイスの制御方法。
9. 請求項８に記載の制御方法を実行するプログラム。

Images