イベント通知装置、イベント通知方法及びイベント通知プログラム
【課題】イベント通知装置の処理負担を軽減させる。
【解決手段】画像処理装置は、イベント種類と、イベント通知先クライアントと、を対応付けて記憶するイベント管理情報と、各クライアントから、監視を要求するイベント種類を含むSubscribeメッセージを受信するリクエスト受信部と、Subscribeメッセージを受信した場合、Subscribeメッセージに含まれているイベント種類と、Subscribeメッセージの送信元のクライアントを示すクライアントと、を対応付けてイベント管理情報に追加する追加部と、イベント管理情報に格納されている監視イベント数に応じてイベントの監視間隔を設定する設定部と、設定されたイベント間隔で、それぞれのイベントが発生したか否かを監視するイベント監視部と、イベント発生を検出した場合、発生したイベントを示すイベント種類の監視を要求したクライアントに対して、当該発生したイベントを通知するイベント通知部と、を備える。
【解決手段】画像処理装置は、イベント種類と、イベント通知先クライアントと、を対応付けて記憶するイベント管理情報と、各クライアントから、監視を要求するイベント種類を含むSubscribeメッセージを受信するリクエスト受信部と、Subscribeメッセージを受信した場合、Subscribeメッセージに含まれているイベント種類と、Subscribeメッセージの送信元のクライアントを示すクライアントと、を対応付けてイベント管理情報に追加する追加部と、イベント管理情報に格納されている監視イベント数に応じてイベントの監視間隔を設定する設定部と、設定されたイベント間隔で、それぞれのイベントが発生したか否かを監視するイベント監視部と、イベント発生を検出した場合、発生したイベントを示すイベント種類の監視を要求したクライアントに対して、当該発生したイベントを通知するイベント通知部と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークなどを介して接続された他の機器にイベントを通知するイベント通知装置、イベント通知方法及びイベント通知プログラムに関するものである。
【背景技術】
【０００２】
近年、インターネットやイントラネットなどのネットワークに接続する機能を備え、ネットワークを介して他の機器（ユーザ）からの操作指示などを受け付けるプリンタなどの画像処理装置（ネットワーク対応の画像処理装置）が普及してきている。このような画像処理装置は、自身においてイベントが発生した場合、自身を利用するユーザに対して発生したイベントの内容を通知する。各ユーザは、イベントの内容（画像処理装置の状態）を把握し、必要に応じてその内容に従った動作を実行する。
【０００３】
ところで、ある特定の画像処理装置を多数のユーザが利用する場合、発生したイベントの内容を各ユーザに対して一斉に通知するため、ネットワーク上のトラフィックが一時的に増大し、応答速度が低下してしまう、という問題が指摘されていた。そのため、この問題を解決するために、下記特許文献１に記載の技術では、イベントの通知先となるユーザ数に応じて、各ユーザに対するイベント通知動作の間に待ち時間（ディレイ）を設けることによりトラフィックが急増するのを防止し、応答速度が低下するのを回避するようにしている。
【０００４】
【特許文献１】特開２００１−２８２４７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述したように、上記特許文献１に記載の技術によれば、応答速度が低下するのを回避することが可能である。しかしながら、イベントの通知先（イベント内容を示す情報の宛先）となるユーザ数が多い場合には、イベント発生時にその旨を全てのユーザに対して通知できないことがある、という上記応答速度の低下とは異なる解決すべき課題が存在する。
【０００６】
たとえば、画像処理装置が２秒間隔でイベントを監視する場合について考えてみると、第１のイベントの発生を検出してから２秒経過後に新たなイベント（第２のイベント）が発生（イベント発生を検出）すると、その時点で第１のイベントの内容を示す第１のイベント発生情報が通知されていないユーザに対しては、引き続き第１のイベント発生情報を通知する。その結果、第１のイベントが発生してから２秒以内に第１のイベント発生情報を通知されなかったユーザの認識と、画像処理装置の実際の状態とに不一致が生じ、ユーザが混乱する可能性がある。すなわち、図３４（Ａ）に示した例のような場合には全てのユーザに対して正しくイベント発生情報を通知できるが、図３４（Ｂ）に示した例のような場合には正しく通知できず、２秒以内に通知を受けることができなかったユーザは古い情報の通知を受ける可能性がある。
【０００７】
また、他の例としては、複数の装置に対してイベント通知を要求する有効期限が長いために、通知を要求するユーザ数が多くなり、通知処理に遅延が生じる可能性がある。
【０００８】
本発明は、上記に鑑みてなされたものであって、イベント発生時に当該イベントの通知を必要とするユーザに対して適切にイベントの通知を行うイベント通知装置、イベント通知方法及びイベント通知プログラムを得ることを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、本発明にかかるイベント通知装置は、クライアント装置とネットワークを介して接続されたイベント通知装置であって、イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けて記憶するイベント情報記憶手段と、各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信手段と、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加手段と、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定手段と、それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視手段と、前記イベント監視手段がイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知手段と、を備える。
【００１０】
また、本発明にかかるイベント通知装置は、上記のイベント通知装置において、前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、を特徴とする。
【００１１】
また、本発明にかかるイベント通知装置は、上記のイベント通知装置において、前記イベント情報記憶手段は、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて記憶し、前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記有効時間内に限り行うこと、を特徴とする。
【００１２】
また、本発明にかかるイベント通知方法は、ネットワークを介して接続されたクライアント装置に対してイベントを通知するイベント通知方法であって、イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、を有することを特徴とする。
【００１３】
また、本発明にかかるイベント通知方法は、上記のイベント通知方法において、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、を特徴とする。
【００１４】
また、本発明にかかるイベント通知方法は、上記のイベント通知方法において、前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、を特徴とする。
【００１５】
また、本発明にかかるイベント通知プログラムは、ネットワークを介して接続されたクライアント装置に対してイベントを通知させることをコンピュータに実行させるイベント通知プログラムであって、イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、をコンピュータに実行させることを特徴とする。
【００１６】
また、本発明にかかるイベント通知プログラムは、上記のイベント通知プログラムにおいて、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、を特徴とする。
【００１７】
また、本発明にかかるイベント通知プログラムは、上記のイベント通知プログラムにおいて、前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、を特徴とする。
【発明の効果】
【００１８】
本発明によれば、所定の監視制御に用いる設定情報を設定し、当該設定情報を使用して所定の監視制御を行うことで、状況に応じて適切な監視を行うことを可能とし、処理負担を軽減させることができるという効果を奏する。
【発明を実施するための最良の形態】
【００１９】
以下に、添付図面を参照して、この発明にかかるイベント通知装置であってコピー機能、ファクシミリ（ＦＡＸ）機能、プリント機能、スキャナ機能及び入力画像（スキャナ機能による読み取り原稿画像やプリンタあるいはＦＡＸ機能により入力された画像）を配信する機能等を備える画像処理装置に適用した最良な実施形態を詳細に説明する。
【００２０】
（第１の実施の形態）
図１は、第１の実施形態にかかる画像処理装置およびネットワークを介して画像処理装置を利用する端末により構成されるシステムの一例を示す図である。このシステムは、上記画像処理装置に相当する“機器”および当該機器を利用する複数のパーソナルコンピュータ（ＰＣ−Ａ，ＰＣ−Ｂ，ＰＣ−Ｃ，ＰＣ−Ｄ，ＰＣ−Ｅ，ＰＣ−Ｆ，ＰＣ−Ｇ）を含んでいる。通常、ネットワークを介して画像処理装置１を利用するためには、所定の手続を実行する必要があるが、上記各パーソナルコンピュータは、必要な手続を既に実行し、上記画像処理装置１を利用可能な状態にあるものとする。なお、画像処理装置１を利用するのはパーソナルコンピュータに限らず、同様の通信機能などを備えた端末であってもよい。また、これ以降、ネットワークを介して上記画像処理装置１を利用する端末をクライアントと呼ぶ。
【００２１】
図２は、本実施の形態にかかる画像処理装置のハードウェア構成例を示す図であり、この画像処理装置１は、ＣＰＵ１１と、システムメモリ１２と、ノースブリッジ（ＮＢ）１３と、サウスブリッジ（ＳＢ）１４と、ＡＳＩＣ１５と、記憶部１６と、Ｉ／Ｆ部１７と、を備える。なお、以下、上記画像処理装置を“画像処理装置１”と呼ぶ。
【００２２】
画像処理装置１において、ＣＰＵ１１は、画像処理装置１の全体の制御を行う。システムメモリ１２は、描画処理を行う際などに使用される。ＮＢ１３は、ＣＰＵ１１、システムメモリ１２、ＳＢ１４、ＡＳＩＣ１５、Ｉ／Ｆ部１７を接続するためのブリッジ、ＳＢ１４は、図２に示した各構成要素と図示されていない他の構成要素（ＲＯＭなど）とを接続するためのブリッジである。ＡＳＩＣ１５は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）である。記憶部１６は、ローカルメモリ，ＨＤＤ（Hard Disk Drive），Ｆｌａｓｈ ＲＯＭ，ＮＶＲＡＭ，などを含み、画像データ等の格納用領域や画像処理を行う際の作業用領域、などとして使用される。Ｉ／Ｆ部１７は、Ethernet（登録商標） I/F，USB I/F，IEEE1394 I/F，無線I/F，などを含む。これらのＩ／Ｆは、インターネットやイントラネットなどのネットワークへの接続やパーソナルコンピュータなどへの接続のためなどに使用される。
【００２３】
図３は、本実施の形態にかかる画像処理装置１のソフトウェア構成例を示す図である。アプリケーション部２１、プラットフォーム部２２およびＳＯＡＰ／ＸＭＬ処理部２３がソフトウェアを構成し、これらの各構成要素は、図２に示したＣＰＵ１１により制御される。また、アプリケーション部２１は、プリンタ、コピーなどの画像形成処理に関連するユーザーサービスに固有の処理を行う複数のアプリケーション処理部（アプリ＃１，アプリ＃２，アプリ＃３，アプリ＃４，…）を含み、プラットフォーム部２２は、ＯＳ／Ｋｅｒｎｅｌ２８とともに、アプリケーション部２１からの処理要求を解釈してハードウェアなどの各種資源の獲得要求を発生する各種制御部（システム制御部２４，メモリ制御部２５，配信制御部２６，ネットワーク制御部２７，…）を含む。また、プラットフォーム部２２は、予め定義されている関数によりアプリケーション部２１からの処理要求を受信可能とするアプリケーションプログラムインターフェース（ＡＰＩ）を有する。
【００２４】
なお、システム制御部２４は、アプリケーションの管理、ハードウェア資源の管理、などの処理を行う。メモリ制御部２５は、メモリの取得および解放などのメモリ制御を行う。配信制御部２６は、他機器との送受信のためのデータの管理やデータの加工などを行う。ネットワーク制御部２７は、図１に示したEthernet（登録商標）I/Fなどのネットワークインタフェイスと接続され、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供し、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分け、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。また、ＯＳ／Ｋｅｒｎｅｌ２８にはソケット以下のネットワーク処理部が存在している。
【００２５】
ＳＯＡＰ／ＸＭＬ処理部２３は、アプリケーション部からもプラットフォーム部からも使用できるような形で存在している。このＳＯＡＰ／ＸＭＬ処理部２３は、ＳＯＡＰ／ＸＭＬメッセージのエンコード／デコードを行う。なお、ＳＯＡＰ／ＸＭＬ処理部２３は、通常、ライブラリの形式で提供されるが、プロセスの形式でもかまわない。
【００２６】
図４は、本実施の形態にかかる画像処理装置１の特徴的な処理を実現するためのイベント処理部の構成例および図３に示したアプリケーション部２１の構成例を示す図である。このイベント処理部は、図３に示したプラットフォーム部２２に含まれるネットワーク制御部２７およびＳＯＡＰ／ＸＭＬ処理部２３と、図２に示した記憶部１６およびＩ／Ｆ部１７と、により構成される。
【００２７】
ネットワーク制御部２７は、全体を統括する全体制御部４１、WS-Eventingプロトコルを処理するWS-Eventing処理部４２、イベントを管理するイベント管理部４３、図３に示したアプリケーション部２１との間で各種情報（メッセージやデータ）のやり取りを行うアプリ通信部４４、ＨＴＴＰ制御部４５、およびＨＴＴＰ以外の各種プロトコル（たとえばFTP，Port9100，LPR)を処理するプロトコル制御部４６を備える。
【００２８】
ＨＴＴＰ制御部４５は、リクエスト受信部５１と、イベント通知部５２とを備え、ＨＴＴＰプロトコルを用いてデータの送受信を行う。リクエスト受信部５１は、クライアントからイベント監視リクエストを受信する。そして、リクエスト受信部５１は、受信したイベント監視リクエストを、イベント管理情報７１に登録する。
【００２９】
イベント通知部５２は、後述するイベント管理部４３がイベントを検出した場合に、ＨＴＴＰプロトコルを用いて、送信先にイベント通知を行う。
【００３０】
イベント管理部４３は、イベント監視部６１と、追加部６２と、更新部６３と、設定部６４とを備える。イベント監視部６１は、アプリ通信部４４を介して、アプリケーション部２１の各アプリにおいてイベントが発生するか否かを監視する。
【００３１】
追加部６２は、イベント監視リクエストをリクエスト受信部５１が受信した場合、イベント監視リクエストに含まれているイベント名と、イベント監視リクエストの送信元のクライアント名と、有効期限とを対応付けて、後述するイベント管理情報７１に追加する。なお、この送信元のクライアントは、イベントの通知先のクライアントとして追加される。また、イベント名は、換言すれば発生するイベントの種類を示している。なお、有効期限の取得手法については後述する。更新部６３は、当該イベント管理情報に対して更新処理を行う。
【００３２】
設定部６４は、イベント管理情報７１が記憶しているイベントの通知先のクライアントおよびイベント名のいずれか一つ以上に基づいて、イベント監視部６１が監視制御を行う設定情報を設定する。本実施の形態では、設定部６４が、設定情報としてイベントの監視周期を設定する場合について説明する。
【００３３】
記憶部１６は、イベント管理情報７１と、監視間隔テーブル７２と、優先度テーブル７３と、を記憶する。なお、各テーブルの詳細については後述する。
【００３４】
アプリケーション部２１に含まれる各アプリケーション処理部（アプリ＃１，…）は、それぞれ同様の構成をとり、アプリケーション処理部の制御を行うアプリケーション制御部３１と、イベントを検出するイベント検出部３２と、図３に示したプラットフォーム部２２を構成する各制御部（すなわち上記イベント処理部に含まれる各制御部）との間で各種情報（メッセージやデータ）のやり取りを行う情報通信部３３と、を備える。
【００３５】
そして、上記イベント処理部は、アプリケーション部２１の各アプリケーション処理部（アプリ＃１，…）においてイベントが発生したかどうかの監視を定期的に行い、いずれかのアプリケーション処理部におけるイベント発生を検出した場合には、その旨を各クライアントへ通知する。イベントが発生したかどうかの監視動作の詳細およびイベント発生時の各クライアントへのイベント内容通知動作の詳細については後述する。
【００３６】
つづいて、イベント処理部の動作を中心に、本実施の形態にかかる画像処理装置１の詳細動作を説明する。まず、各クライアントが上記画像処理装置１からイベント発生時にその内容の通知を受けるために必要な動作である画像処理装置１に対する初期設定動作について説明する。具体的には、クライアントが画像処理装置１に対して、発生したイベントを通知するように要求を出し、この要求に対して画像処理装置１が実行する動作について説明する。
【００３７】
WS-Eventingプロトコルを使用する場合の例を以下に示す。まずクライアントは、図５に示したような内容のメッセージを画像処理装置１に対して送信する。図５は、Subscribeメッセージの一例を示したものであり、クライアントが、このメッセージで指示するイベントが発生した場合、その内容を通知するように画像処理装置１に対して要求するものである。このメッセージの内容は、「“StatusEvent（符号５０１）”が示すイベントについてStatusが変化したら（イベントが発生したら）通知をしてほしい」ということを示している。Subscribeメッセージを受信した画像処理装置１は、その要求内容に応じることができるかどうかを確認し、確認結果に基づいた内容の応答メッセージを返信する。
【００３８】
つぎに、Subscribeメッセージを受信した画像処理装置１は、たとえば図６に示したような内容のメッセージをクライアントに対して送信する。図６は、Subscribeメッセージに対するレスポンス（SubscribeResponse）メッセージの一例を示したものであり、Subscribeメッセージを正常に受け付けた場合のものである。この内容は、「Subscribeメッセージで指示されたイベントが発生（検知）した場合、Expiresフィールド６０１に示された有効期限が到来するまでの間、その内容（発生したイベント）を通知する」ということを示している。これ以後、原則としてExpiresフィールドに示された有効期限が到来するまで、画像処理装置１は、上記Subscribeメッセージで指示されたイベントを検知した場合、その内容を上記SubscribeResponseメッセージの送信相手先クライアントへ通知する。
【００３９】
また、上記SubscribeResponseメッセージを受信したクライアントは、当該受信したメッセージに示された上記有効期限が到来後も引き続いてイベントの通知を受けたい場合、図７に示したような内容のメッセージを画像処理装置１に対して送信する。図７は、Renewメッセージの一例を示したものであり、通常はクライアントが画像処理装置１からイベント通知を受けている状態において送信される。この内容は、「（それ以前に受信したSubscribeResponseメッセージなどに含まれるExpiresフィールドに示された）有効期限が到来後も引き続いて、発生したイベントを通知してほしい」ということを示している。
【００４０】
Renewメッセージを受信すると、画像処理装置１は、たとえば図８に示したような内容のメッセージをクライアントに対して送信する。図８は、Renewメッセージに対するレスポンス（RenewResponse）メッセージの一例を示したものであり、Renewメッセージを正常に受け付けた場合のものである。この内容は、「Expiresフィールドに示された有効期限が到来するまでの間、発生（検知）したイベントを通知する」ということを示している。すなわち、更新された有効期限がExpiresフィールドに示される。
【００４１】
なお、図９は、SubscriptionEndメッセージの一例を示す図である。このSubscriptionEndメッセージは、上記Expiresフィールドに示された有効期限内であるにもかかわらずイベントの通知を停止する場合、画像処理装置１がイベントの通知を停止するクライアントに対して送信する。
【００４２】
図１０は、StatusEventReportメッセージの一例を示す図である。画像処理装置１は、SubscribeResponseメッセージおよびRenewResponseメッセージの送信先であるクライアントに対して、それらのメッセージにて通知した有効期限が到来するまでに発生したイベントを、このStatusEventReportメッセージを使用して通知する。図１０に示した例は、トナーがなくなった（Out of Toner）ことを検出した場合にそれを通知するためのメッセージである。
【００４３】
また、図１１の（Ａ），（Ｂ）は、それぞれSubscribeメッセージ（図５参照），Renewメッセージ（図７参照）に対する応答メッセージの一例を示す図であり、画像処理装置１が要求（Subscribe，Renew）を受け付けられない場合に返送するfaultメッセージの一例を示している。SubscribeメッセージまたはRenewメッセージを受信したが、それを受け付けることができない場合、画像処理装置１は、SubscribeResponseメッセージまたはRenewメッセージに代えて、faultメッセージを送信する。図１１の（Ａ）および（Ｂ）に示したいずれの例も、リソース不足（not-enough resource）を理由として要求（SubscribeまたはRenew）を受け付けられない場合に返送されるメッセージである。
【００４４】
図１２は、画像処理装置１がクライアントからSubscribeメッセージまたはRenewメッセージを受信するシーケンス例を示す図である。なお、“Subscriber”がクライアントに相当する。
【００４５】
画像処理装置１がクライアントからSubscribeメッセージまたはRenewメッセージを受信すると（ステップＳ１１）、画像処理装置１のネットワーク制御部において、ＨＴＴＰ制御部４５のリクエスト受信部５１が、受信したメッセージをWS-Eventing処理部４２へ渡す（ステップＳ１２）。WS-Eventing処理部４２はＨＴＴＰ制御部４５から渡されたメッセージをさらにＳＯＡＰ／ＸＭＬ処理部２３に渡してその内容を解析させる（ステップＳ１３）。ＳＯＡＰ／ＸＭＬ処理部２３はステップＳ１３において受け取ったメッセージの内容解析結果をWS-Eventing処理部４２に対して返信する（ステップＳ１４）。
【００４６】
つぎに、WS-Eventing処理部４２は、ステップＳ１４において受け取った内容解析結果を登録するように、イベント管理部４３に対して要求し（ステップＳ１５）、イベント管理部４３はステップＳ１５における要求内容に基づいた処理を実行する。
【００４７】
たとえば、リクエスト受信部５１がSubscribeメッセージを受信し、イベント管理部４３が当該メッセージで示された要求を受け入れることができると判断した場合、イベント管理部４３の追加部６２は、Subscribeメッセージの内容に基づいて、新たなレコードをイベント管理情報７１に追加する。このイベント管理情報７１は、あるイベントが発生した場合、そのイベントをどのクライアントに通知すべきかを示した情報であり、各イベントとその通知先クライアントの対応関係を示したものである。イベント管理情報７１にはイベント通知動作の有効期限情報（どのイベントの通知をどのクライアントに対していつまで行うかを示す情報）も含まれる。
【００４８】
図１３は、イベント管理情報７１のテーブル構造を示した図である。図１３に示すようにイベント管理情報７１は、イベント名と、通知先クライアントと、有効期限とを対応付けて記憶している。つまり、イベント管理部４３が任意のイベントが発生したと判断した場合、イベント通知部５２が、当該イベントを示すイベント名と対応付けられた通知先クライアントに対して、有効期限内であれば、発生した当該イベントを示すメッセージを通知する。
【００４９】
また、リクエスト受信部５１がRenewメッセージを受信し、イベント管理部４３が当該メッセージが示す要求を受け入れることができると判断した場合、更新部６２は上記イベント管理情報７１に含まれるイベント通知動作の有効期限情報を更新、すなわちイベント管理情報７１を更新する。なお、SubscribeメッセージやRenewメッセージの受信に伴い更新されたイベント管理情報７１は、記憶部１６などに保持される。SubscribeメッセージやRenewメッセージが示す要求を受け入れられない場合、イベント管理情報７１は更新されない。
【００５０】
イベント管理部４３は、処理が終了すると、その処理結果をWS-Eventing処理部４２へ通知する（ステップＳ１６）。さらに、WS-Eventing処理部４２は、上記SubscribeメッセージまたはRenewメッセージの送信元であるクライアントに対して返信するメッセージ（レスポンスメッセージ）を、ステップＳ１６において通知を受けた処理結果に基づいて生成するようにＳＯＡＰ／ＸＭＬ処理部２３に対して要求する（ステップＳ１７）。ＳＯＡＰ／ＸＭＬ処理部２３は、WS-Eventing処理部４２からの要求内容に従ってレスポンスメッセージを生成し、それをWS-Eventing処理部４２に渡す（ステップＳ１８）。ステップＳ１８においてレスポンスメッセージを受け取ったWS-Eventing処理部４２は、それをＨＴＴＰ制御部４５へ渡し（ステップＳ１９）、ＨＴＴＰ制御部４５は受け取ったレスポンスメッセージをクライアントに対して返信する（ステップＳ２０）。
【００５１】
なお、ステップＳ２０においてＨＴＴＰ制御部４５から返信されるメッセージの内容は、上記ステップＳ１１において画像処理装置が受け取ったメッセージの内容（SubscribeメッセージかRenewメッセージか）および上記ステップＳ１６におけるイベント管理部４３の処理結果により異なる。ステップＳ１１において受け取ったメッセージが示す内容（要求）を画像処理装置１が受け付ける場合には、SubscribeResponseメッセージ（図６参照）またはRenewResponseメッセージ（図８参照）が返信される。一方、要求を受け付けない場合には、faultメッセージ（図１１（Ａ）および（Ｂ）参照）が返信される。
【００５２】
図１４は、画像処理装置１におけるイベント発生監視動作シーケンスおよび検出したイベントの通知動作シーケンスの一例を示す図である。
【００５３】
画像処理装置１においてネットワーク制御部のイベント管理部４３のイベント監視部６１は、アプリケーション部２１の各アプリケーション処理部においてイベントが発生したかどうかの監視を定期的に行う（ステップＳ３１，Ｓ３３）。具体的には、イベント監視部６１は、アプリ通信部４４を介して、イベントが発生したかどうか（状態が変化したかどうか）を各アプリケーション処理部のイベント検出部３２に対して問い合わせる。
【００５４】
なお、図１４に示した例においては、説明を簡単にするためにイベント管理部４３が１つのアプリケーション処理部（アプリ＃Ｎ）のイベント検出部３２に対してのみ問い合わせを行っているが、実際には全てのアプリケーション処理部に対して問い合わせを行う。また、イベント管理部４３と各アプリケーション処理部のイベント検出部３２はアプリ通信部４４および情報通信部３３を介して通信を行う。
【００５５】
ここで、イベント管理部４３のイベント監視部６１が各アプリケーション処理部においてイベントが発生したかどうかの監視を定期的に行うにあたり、イベント管理部４３の設定部６４が、その監視周期を監視結果の通知対象となるクライアント数に応じて設定する。
【００５６】
図１５は、画像処理装置がイベント監視動作時に使用する情報の一例を示す図である。たとえば、図１５（Ａ）に示したような監視間隔テーブル７２を予め準備して記憶部１６に保持しておく。そして、設定部６４が、上記イベント管理情報７１から監視結果の通知対象であるSubscribe登録済みクライアントの数（イベント発生時にその通知を行う相手先となるクライアントの数）を確認する。確認の結果、設定部６４は、クライアント数が１００以下であれば（Subscribe登録個数が１００個以下であれば）イベント発生の監視周期（Polling間隔）を１秒に設定し、１０１以上２００未満であれば監視周期を２秒に設定する。なお、図１５（Ａ）の監視間隔テーブル７２に示した監視周期は、１クライアントに対する監視結果通知処理に必要とする時間に基づいて決定する。これにより、検出したイベントをSubscribe登録済みのクライアント全てに対して正しく通知することができる。
【００５７】
ところで、画像処理装置１において発生するイベントには、その内容を迅速かつ正確に通知する必要があるものとそうでないものが存在する。たとえば、トナーに関するイベントでは、トナーが完全に無くなったことを検出するのは頻繁に行う必要があると考えられる。一方、トナーが少なくなったことを検出するのはそれほど頻繁に行う必要はなく、またトナーが少なくなったことをクライアントに対して直ちに、正しく通知しなくても（トナーが少ない状態となった後、直ちにその状態が通知されなくても）それほど大きな問題とはならない。そのため、各イベントの監視周期を一律にするのではなく、アプリケーションごとにイベントの監視周期を違えてもよい。
【００５８】
そこで、本実施の形態の変形例としては、図１５（Ａ）に示した監視間隔テーブル７２の代わりに、図１５（Ｂ）に示したような監視間隔テーブルを予め準備して記憶部１６に保持しておき、設定部６４は、当該監視間隔テーブルに示された監視時間を使用して監視間隔を設定する。そして、イベント監視部６１が当該監視間隔で各イベントの監視を行う。これにより、優先度の高いイベント（通知の迅速性や正確性が要求されるイベント）の発生をより迅速かつ正しくSubscribe登録済みのクライアント全てに対して通知することができる。なお、図１５（Ｂ）の監視間隔テーブルに示した監視周期は、１クライアントに対する監視結果通知処理に必要とする時間に基づいて決定する。また、図１５（Ｂ）の例では監視間隔を２種類としているが３種類以上としてもよい。
【００５９】
第１の実施の形態の図１４に戻り、イベント検出部３２は、イベント管理部４３のイベント監視部６１からの問い合わせに対して、イベントが発生していなければその旨を通知する（ステップＳ３２）。これに対して、イベント検出部３２は、イベントが発生している場合にはその旨を通知する（ステップＳ３４）。
【００６０】
イベント検出部３２からイベント発生の通知を受けた場合、イベント管理部４３はその旨をWS-Eventing処理部４２へ通知する（ステップＳ３５）。WS-Eventing処理部４２は、イベントの発生をクライアントに対して通知するためのメッセージを生成するようにＳＯＡＰ／ＸＭＬ処理部２３に対して要求し（ステップＳ３６）、これに対するメッセージをＳＯＡＰ／ＸＭＬ処理部２３から受け取り（ステップＳ３７）、さらに、ＳＯＡＰ／ＸＭＬ処理部２３から受け取ったメッセージをＨＴＴＰ制御部４５へ渡す（ステップＳ３８）。そして、ＨＴＴＰ制御部４５のイベント通知部５２は、WS-Eventing処理部４２から受け取ったメッセージ（図１０に例示したようなStatusEventReportメッセージ）をクライアントに対して送信する（ステップＳ３９）。図１４においてはStatusEventReportメッセージをNotificationメッセージと表現している。通常、クライアントは受信したメッセージに対する応答メッセージ（図１４の例ではHTTP 200 Response）を返信する（ステップＳ４０）。なお、上記ステップＳ３９では、画像処理装置１のイベント通知部５２は、イベントの通知要求を受けている全てのクライアント（SubscribeメッセージまたはRenewメッセージを受信済み、かつそれらに対する応答メッセージにおいて示した有効期限が到来していないクライアント）に対して、発生したイベントを示すメッセージを送信する。
【００６１】
図１６は、画像処理装置１がSubscriptionEndメッセージを送出する場合のシーケンス例を示す図である。イベント管理部４３はSubscriptionEndに相当する事象が発生すると、その旨をWS-Eventing処理部４２へ通知する（ステップＳ５１）。WS-Eventing処理部４２は、SubscriptionEndをクライアントに対して通知するためのメッセージを生成するようにＳＯＡＰ／ＸＭＬ処理部２３に対して要求し（ステップＳ５２）、これに対するメッセージをＳＯＡＰ／ＸＭＬ処理部２３から受け取り（ステップＳ５３）、さらに、ＳＯＡＰ／ＸＭＬ処理部２３から受け取ったメッセージをＨＴＴＰ制御部４５へ渡す（ステップＳ５４）。そして、ＨＴＴＰ制御部４５はWS-Eventing処理部４２から受け取ったメッセージ（図９に例示したようなSubscriptionEndメッセージ）をクライアントに対して送信する（ステップＳ５５）。通常、クライアントは受信メッセージに対する応答メッセージを返信する（ステップＳ５６）。
【００６２】
図１７は、画像処理装置１がSubscribeメッセージ／Renewメッセージを受信した場合の動作例を示すフローチャートである。SubscribeメッセージまたはRenewメッセージを受信すると（ステップＳ６１）、画像処理装置１のイベント管理部４３は、その内容を確認し、特定条件に該当するかどうかを確認する（ステップＳ６２）。ここで、特定条件に該当するかどうかは、たとえば、SubscribeメッセージやRenewメッセージの送信元（クライアント）や、監視するイベントの種類に応じて判断する。
【００６３】
つまり、追加部６２は、Subscribeメッセージ／Renewメッセージを受信した場合、常にイベント管理情報７１にレコードを追加するわけではなく、Subscribeメッセージ／Renewメッセージに含まれているイベント名又はSubscribeメッセージ／Renewメッセージを送信したクライアントと、イベント管理情報７１に格納されている情報（例えば、イベント、通知先クライアント）と、に基づいて、Subscribeメッセージ／Renewメッセージに含まれているイベント名や、Subscribeメッセージ／Renewメッセージの送信元のクライアントと、を対応付けてイベント管理情報７１に追加するか否か判断する。この例としては、イベントやクライアント等に優先度を設定し、当該優先度に基づいて追加するか否か判断することが考えられる。
【００６４】
図１８は、Subscribe／Renewメッセージの送信元のＩＰアドレスと優先度の関係を保持する優先度テーブル７３の一例を示す図である。この場合、図１８（Ａ）に示したような優先度テーブル７３を予め準備して記憶部１６に保持しておき、保持しておいたテーブルを用いて判断を行う。たとえば、優先度（Priority）の高いＩＰアドレスの送信元からメッセージを受信した場合や、特定条件と判断する。
【００６５】
つまり、リクエスト受信部５１がSubscribeメッセージを受信した場合、イベント管理部４３の追加部６２は、当該Subscribeメッセージに含まれるイベント名が、イベント管理情報７１のフィールド“イベント”に格納されているレコード数を算出する。そして、追加部６２は、算出したレコード数が所定の数（例えば１００）だけ存在しているか否か判断する。そして、追加部６２は、レコード数が所定の数と一致していると判断した場合に、Subscribeメッセージの送信元のクライアントが、優先度テーブル７３で優先すべきクライアントであるか否か判断する。この優先すべきクライアントであるか否かは、例えば優先度テーブル７３で、優先度Highのクライアントを、優先すべきクライアントと判断する等が考えられる。そして、追加部６２は、優先すべきクライアントであると判断した場合に、イベント管理情報７１で優先すべきではないと判断されたクライアント（例えば優先度テーブル７３で優先度がLowと対応付けられているクライアント）が格納されているレコードを削除し、Subscribeメッセージの送信元のクライアントを通知先クライアントとしたレコードを追加する。
【００６６】
また、本実施の形態の変形例として、受信したメッセージの内容がテーブルに示した優先度の高い項目に該当する場合に、特定条件と判断してもよい。図１８（Ｂ）は、通知対象イベントの種類と優先度の関係を保持する優先度テーブルの一例を示す図である。この場合、Subscribeメッセージを受信して、イベント管理情報７１のレコード数が所定の数以上となった場合に、優先度が低いイベントのレコードが削除され、優先度が高いイベントのレコードが追加されることになる。
【００６７】
さらには、特定条件に該当するかどうかの確認処理においては、図１８（Ａ）または（Ｂ）のいずれか一つのテーブルのみを用いて判断するようにしてもよいし、双方を用いて判断するようにしてもよい。また、これらのテーブルは、メッセージ（Subscribe／Renew）の送信元の機器の種類や、画像処理装置の仕様や種類により異なる可能性がある。
【００６８】
図１７に戻り、上記ステップＳ６２において特定条件に該当しないと判断した場合（ステップＳ６２，Ｎｏ）、画像処理装置１はエラーレスポンス（図１１（Ａ）または（Ｂ）に例示したようなfaultメッセージ）を返信する（ステップＳ６３）。これに対して、特定条件に該当すると判断した場合（ステップＳ６２，Ｙｅｓ）、正常レスポンス（図６に例示したSubscribeResponseメッセージまたは図８に例示したRenewResponseメッセージ）を返信する（ステップＳ６４）。なお、ステップＳ６３，Ｓ６４の詳細動作については、図１２に基づいて上述したとおりである。
【００６９】
また、図１７で示した処理手順では、特定条件に該当するか否かのみでイベント管理情報７１に追加するか否か判断していたが、これにイベント管理情報７１で保持しているレコード数も考慮しても良い。そこで、特定条件とレコード数とを考慮した変形例について説明する。
【００７０】
図１９は、当該変形例にかかる画像処理装置１がSubscribeメッセージを受信した場合の動作例を示すフローチャートである。リクエスト受信部５１がSubscribeメッセージを受信すると（ステップＳ７１）、画像処理装置１のイベント管理部４３の追加部６２は、Subscribe登録済みのクライアント数が登録可能な最大数に達しているかどうかを確認する（ステップＳ７２）。図５に例示したSubscribeメッセージの説明において示したように、クライアントはSubscribeする対象のイベントを個別に指定できるため、Subscribe登録済みのクライアント数が登録可能な最大数に達しているイベントとそうでないイベントが混在している可能性がある。そのためステップＳ７２においては、Subscribeメッセージで指示されたイベントそれぞれについて、Subscribe登録済みのクライアント数が登録可能な最大数に達しているかどうかを確認する。ステップＳ７２の処理の結果、確認した全てのイベントについて、追加部６２がSubscribe登録済みのクライアント数が登録可能最大数に達していないと判断した場合（ステップＳ７２，Ｎｏ）、ＨＴＴＰ制御部４５が正常レスポンス（図６に例示したSubscribeResponseメッセージ）を返信する（ステップＳ７４）。一方、追加部６２がSubscribe登録済みのクライアント数が登録可能な最大数に達しているイベントが１つでも存在すると判断した場合には（ステップＳ７２，Ｙｅｓ）、受信したSubscribeメッセージの内容を確認し、特定条件に該当するかどうかを確認する（ステップＳ７３）。ここで、特定条件に該当するかどうかの確認処理は、上記図１６に示したステップＳ６２における確認処理と同様である。追加部６２が、ステップＳ７３において特定条件に該当しないと判断した場合（ステップＳ７３，Ｎｏ）、画像処理装置１のＨＴＴＰ制御部４５がエラーレスポンス（図１１（Ａ）に例示したようなfaultメッセージ）を返信する（ステップＳ７５）。これに対して、追加部６２が、特定条件に該当すると判断した場合（ステップＳ７３，Ｙｅｓ）、正常レスポンス（図６に例示したようなSubscribeResponseメッセージ）を返信する（ステップＳ７６）。
【００７１】
リクエスト受信部５１が優先度の高いクライアントからSuscribeメッセージを受信した場合、追加部６２が、優先度の低いSubscribe登録済みのクライアントを選択してその登録を抹消し、ＨＴＴＰ制御部４５が、当該クライアントに対してSbscriptionEndメッセージを送信する（ステップＳ７７）、すなわち、追加部６２が、Subscribe登録済みのクライアント数が登録可能な最大数に達しているイベントに関して、選択した登録済みの情報に代えて上記ステップＳ７１において受信したSubscribeメッセージの内容を新しい情報として登録する。なお、上記登録可能最大数はSubscribe登録するイベント（監視対象として登録するイベント）の種類に応じて異なる値としてもよい。
【００７２】
また、優先度の高いイベントの監視を要求するSuscribeメッセージを受信した場合には、Subscribe登録済みのクライアント数が登録可能最大数に達しているイベントのSubscribe登録済みのクライアントの中から、優先度の低いクライアントを選択し、選択したクライアントに代えて上記ステップＳ７１において受信したSubscribeメッセージの送信元クライアントを新たにSubscribe登録する。
【００７３】
図２０は、画像処理装置１においてイベントが発生した場合の動作例を示すフローチャートである。イベントの発生を検出すると、イベント管理部４３は、それを通知するためのメッセージの宛先としてSubscribe登録済みのクライアントの中から選択する（ステップＳ８１）。そして、イベント通知部５２が、上記図１４に示したステップＳ３６〜Ｓ３９の処理を実行することにより発生したイベントの内容を通知するためのメッセージ（イベント通知メッセージ）をステップＳ８１で選択した宛先（クライアント）に対して送信する（ステップＳ８２）。そして、イベント通知部５２が、指定時間内にメッセージの宛先から応答が返ってきたかどうかを確認する（ステップＳ８３）。指定時間内に応答がなかった場合（ステップＳ８３，Ｎｏ）、イベント通知部５２が、上記ステップＳ８２において送信したメッセージのあて先を送信失敗あて先に登録する（ステップＳ８４）。このとき、必要に応じて、イベント管理部からそのイベント情報を削除する。なお、指定時間の設定手法については後述する。
【００７４】
これに対して、指定時間内に応答があった場合（ステップＳ８３，Ｙｅｓ）、イベント通知部５２が、上記イベント通知メッセージの送信先がまだ残っているかどうか（Subscribe登録済みの全てのクライアントに対してイベント通知メッセージを送信したかどうか）を確認する（ステップＳ８５）。送信先が残っていない（Subscribe登録済みの全てのクライアントに対してイベント通知メッセージを送信した）ことを確認した場合（ステップＳ８５，Ｎｏ）、処理を終了する。イベント通知部５２が、送信先が残っていることを確認した場合（ステップＳ８５，Ｙｅｓ）、上記ステップＳ８１に遷移して、上述したステップＳ８１〜Ｓ８５に示した処理を継続する。
【００７５】
図２１は、上記イベントが発生した場合の動作例を時系列に示した図である。また、上記ステップＳ８３の処理においては、Subscribeの登録個数（Subscribe登録済みのクライアント数）に基づいてメッセージの宛先からの応答を待つ時間（上記指定時間に相当）を変更する。たとえば、図２２に示したようなテーブルを予め準備して記憶部１６に保持しておき、Subscribeの登録個数が１００個以下であれば、応答待ち時間を４秒とする。これにより、全てのSubscribe登録済みのクライアントに対するイベント通知処理を特定の時間内において終了することが可能となる。なお、図２２に示した応答待ち時間は、１クライアントに対する監視結果通知処理に必要とする時間に基づいて決定する。
【００７６】
このように、本実施の形態においては、イベント発生時の通知相手先（イベント通知先）となるクライアントの数（Subscribe登録済みのクライアント数）に応じて、イベントの検出間隔を変化させるようにした。これにより、イベント発生を検出した場合には、全てのイベント通知先に対して、最新の情報（発生イベント）を正しく通知することができる。
【００７７】
また、受け付けるイベント監視リクエスト（Subscribeメッセージ）の種類により、優先度を設定して、イベントの検出間隔を変化させるようにしたので、イベント発生を検出した場合には、全てのイベント通知先に対して、発生イベントを正しくかつ効率的に通知することができる。
【００７８】
また、Subscribe登録済みのクライアント数に基づいて、すなわち、Subscribe登録済のクライアント数が、登録可能最大数に達しているかどうかを考慮して、新たなイベント監視リクエストや更新イベント監視リクエスト（Renewメッセージ）を処理するかどうか判断するようにしたので、一度登録されたイベント通知先に対して、発生イベントを確実に通知することができる。
【００７９】
また、Subscribe登録済のクライアント数が、登録可能最大数に達している場合であっても、優先度が高いなどの特定の相手（優先クライアント）からのイベント監視リクエストを受け付けた場合には、他の優先度がそれほど高くないSubscribe登録済のクライアントに関する登録を抹消し、優先クライアントをSubscribe登録することにしたので、優先度の高い相手に対して、発生イベントを確実に通知することができる。
【００８０】
また、Subscribe登録済のクライアント数が、登録可能最大数に達している場合であっても、優先度が高いなどの特定の種類のイベント監視リクエストを受け付けた場合には、他の優先度がそれほど高くないSubscribe登録済のクライアントに関する登録を抹消することにしたので、優先度の高いイベントが発生した場合にそれを確実に通知することができる。
【００８１】
また、Subscribe登録済のクライアント数に応じて、イベント通知に対するイベント通知先からの応答待ち時間を変化させるようにしたので、イベント通知をできるだけ多くのイベント通知先に対して行うことができる。
【００８２】
また、本実施の形態では、イベントを通知する画像処理装置１について説明したが、画像処理装置に制限するものではなく様々な装置に適用することができる。例えば、社内ネットワークを介して様々な装置と接続されているビジネスオフィス機器等にも適用する子ことができる。つまり、ネットワークを介してクライアントなどの装置と接続され、監視対象の状態が変化した場合に通知を行うことが可能な装置であればよい。
【００８３】
また、本実施の形態にかかる画像処理装置１においては、監視イベント数に応じて監視間隔が設定されるので、監視イベント数が多くなれば監視間隔を長くすることで、処理負担を軽減させることができる。
【００８４】
（第２の実施の形態）
上述した第１の実施の形態にかかる画像処理装置１においては、イベントを監視する監視制御の設定情報として、監視周期を設定する場合について説明した。しかしながら、監視制御の設定情報を監視周期に限るものではない。そこで、第２の実施形態では、監視制御の設定情報として、イベント通知を行う際の有効期限を設定する場合について説明する。
【００８５】
第２の実施の形態にかかる画像処理装置１は、上述した第１の実施の形態にかかる画像処理装置１とは、ネットワーク制御部２７とは処理が異なるネットワーク制御部２６０１に変更された構成を有している点で異なる。以下の説明では、上述した第１の実施の形態と同一の構成要素には同一の符号を付してその説明を省略している。
【００８６】
図２３は、本実施の形態にかかる画像処理装置１のイベント処理部の構成例およびアプリケーション部２１の構成例を示す図である。上述した第１の実施形態にかかるイベント処理部とは、ネットワーク制御部２６０１の他、記憶部１６に格納されているテーブルが異なる点とする。
【００８７】
記憶部１６は、イベント管理テーブル２６２１と、有効時間管理テーブル２６２２と、を備える。
【００８８】
図２４は、イベント管理テーブル２６２１のテーブル構造を示した図である。図２４に示すように、イベント管理テーブル２６２１は、管理番号と、通知先クライアント、イベント種類、SubscribeID、有効時間及び登録時間とを対応付けて記憶している。イベント管理テーブル２６２１のレコードは、クライアントからイベント通知要求に応じて登録される。そして、イベントが発生した場合、画像処理装置１は、当該イベント監視テーブルを参照して、通知先クライアントに、イベントの通知を行う。
【００８９】
管理番号は各レコードを示すシーケンシャルな番号とする。また、SubscribeIDは、Subscribeメッセージ毎に割り当てられるユニークなＩＤとする。登録時間は、当該レコードの登録や更新が行われた時間を保持する。そして、当該登録時間から有効時間だけ時間が経過すると、該当するレコードが削除される。なお、詳細な処理については後述する。
【００９０】
図２５は、有効時間管理テーブル２６２２のテーブル構造を示した図である。図２５に示すように、有効時間管理テーブル２６２２は、監視イベント数と、有効時間とを対応付けて記憶している。そして、本実施の形態にかかる画像処理装置１では、当該有効時間管理テーブル２６２２を用いて、上述したイベント管理テーブル２６２１の有効時間を設定する。
【００９１】
また、有効時間管理テーブル２６２２は、記憶部１６のＮＢＲＡＭ内に保存することが考えられる。また、当該有効時間管理テーブル２６２２は、書き換え可能な記憶部ではなくともよいし、当該処理を行うためにソフトウェア上ハードコーディングすることなども考えられる。
【００９２】
そして、画像処理装置１では、有効時間管理テーブル２６２２を参照し、イベント管理テーブル２６２１のレコードの登録、更新を行う際に適切な有効時間を設定する。
【００９３】
図２３に戻り、ネットワーク制御部２６０１は、第１の実施の形態にかかるネットワーク処理部２７とは、イベント管理部４３とは処理が異なるイベント管理部２６１１に変更され、WS-Discovery処理部２６１２が追加された点とする。
【００９４】
WS-Discovery処理部２６１２は、WS-Discoveryプロトコルを処理する。WS-Discoveryプロトコルで定義されているパケットとしては、ネットワーク離脱パケットByeがある。
【００９５】
つまり、本実施の形態にかかる画像処理装置１では、第１の実施形態の画像処理装置１が処理したSubscribeメッセージなどのWS-Eventingプロトコルのメッセージに加えて、ByeパケットなどのWS-Discoveryプロトコルで定義されているパケットについても処理する。
【００９６】
図２６は、WS-EventingプロトコルにおけるSubscribeのメッセージの一例を示した図である。クライアントは、このようなSubscribeメッセージを画像処理装置１に対して送信することで、イベントの通知を要求する。図２６に示すSubscribeメッセージは、行３００１でSubscribeメッセージであることが特定できる。また、行３００２には、有効時間が記載されている。さらに、行３００３は、イベント“PrinterStatusEvent”を監視対象として登録することを要求している。なお、イベント“PrinterStatusEvent”は、画像処理装置１の“PrinterStatus”が変化した場合に発生するイベントとする。つまり、画像処理装置１の“PrinterStatus”が変更した場合に、クライアントに対してイベント通知が行われる。
【００９７】
図２７は、WS-EventingプロトコルにおけるSubscribeResponseメッセージの一例を示した図である。行３１０１でSubscribeResponseメッセージであることが特定できる。また、行３１０２のExpiresタグで囲まれた“PT30M”がこのイベント監視の有効時間として、３０分を設定したことを示している。
【００９８】
また、図２７に示すSubscribeResponseメッセージは、図２６に示すSubscribeメッセージのレスポンスメッセージの第１の例である。当該SubscribeResponseメッセージは、図２６に示すSubscribeメッセージを通知したクライアントに対して画像処理装置１が送信する。具体的には、図２６で示すSubscribeメッセージで、有効時間として３０分要求したのに対して、図２７に示すSubscribeResponseメッセージで要求通り有効時間として３０分で設定した旨の応答を行っている。
【００９９】
図２８に示すSubscribeResponseメッセージは、図２６に示すSubscribeメッセージのレスポンスメッセージの第２の例である。当該レスポンスメッセージでは、行３２０１でSubscribeResponseメッセージであることが特定できる。また、行３２０２のExpiresタグで囲まれた“PT10M”がこのイベント監視の有効時間として、１０分を設定したことを示している。つまり、図２６で示すSubscribeメッセージで、有効時間として３０分要求したのに対して、図２８に示すSubscribeResponseメッセージでは、要求より少ない１０分が有効時間として設定された旨の応答を行っている。
【０１００】
このように本実施の形態にかかる画像処理装置１では、クライアントからイベント通知の要求があった場合、当該要求の有効時間を状況に応じて適切に設定する。この有効時間を設定するための状況としては、イベント数、イベント監視先、イベント種類等が考えられる。本実施の形態では、イベント数で有効時間を変更する場合について説明している。
【０１０１】
図２３に戻り、イベント管理部２６１１は、イベント監視部６１と、追加部６２と、更新部６３と、設定部２６３１とを備える。
【０１０２】
設定部２６３１は、イベント管理テーブル２６２１に記憶されているイベント数に基づいて、各イベントの監視する有効時間を設定する。
【０１０３】
次に、以上のように構成された本実施の形態にかかる画像処理装置１におけるメッセージを受信した場合の処理について説明する。図２９は、本実施の形態にかかる画像処理装置１における上述した処理の手順を示すフローチャートである。
【０１０４】
まず、リクエスト受信部５１が、クライアントからのSubscribeリクエスト又はRenewリクエストを受信する（ステップＳ３３０１）。
【０１０５】
そして、設定部２６３１は、有効時間管理テーブル２６２２を参照して、有効時間を設定する（ステップＳ３３０２）。本実施の形態では、設定部２６３１は、受信したリクエストの数と、イベント管理テーブルで有効期限が経過していないレコードとの和を監視対象であるイベント数として算出し、算出されたイベント数と有効時間管理テーブル２６２２を参照して、有効時間を設定する。
【０１０６】
また、設定部２６３１は、監視イベント数が１−５０であればSubscribeメッセージ又はRenewメッセージで要求された有効時間を、実際の有効時間と設定する。監視イベント数が、５１−１００であれば有効時間を３０分と設定する。監視イベント数が、１０１−１００であれば有効時間を２０分と設定する。監視イベント数が、２０１以上であれば有効時間を１０分と設定する。さらに、Subscribeメッセージ又はRenewメッセージで有効時間を要求されなかった場合、有効時間を１０分と設定する。
【０１０７】
このようにして設定された各レコードは、有効時間が経過すると、イベント管理テーブル２６２１から削除される。しかしながら、有効時間が経過する前にクライアントからRenewリクエストを受信した場合は、当該レコードは削除されず、新たな有効時間が設定される。この有効時間を設定する際に監視イベント数が変化していれば、その数にしたがって新しい有効時間が設定される。このように、以前のSubscribeリクエストやRenewリクエストの時の有効時間とは異なる有効時間が設定される場合がある。
【０１０８】
つまり、設定部２６３１は、イベント管理テーブル２６２１を参照して、監視イベント数が１〜５０であればクライアントが要求した有効時間通りに設定し、それ以上の監視イベント数であれば、監視イベント数が多くなるに従って有効時間を短く設定する。これにより、画像処理装置１の監視負担を軽減することができる。
【０１０９】
そして、設定部２６３１は、設定された有効時間と共に、クライアントから監視を要求されたイベントに関する情報対応付けて、イベント管理テーブル２６２１に登録／更新する。なお、Subscribeリクエストを受信した場合にレコードの登録を行い、Renewリクエストを受信した場合にレコードの更新を行うこととする。なお、本実施の形態では、設定部２６３１の有効時間の設定は新たに登録／更新したレコードに対して飲み行うが、イベント管理テーブル２６２１の全てのレコードに対して有効期限の再設定を行ってもよい。
【０１１０】
次に、設定部２６３１は、Subscribeリクエスト又はRenewリクエストを送信してきたクライアントに対して、Subscribe／Renewレスポンスメッセージを送信する（ステップＳ３３０４）。
【０１１１】
上述した処理手順により、Subscribeリクエスト又はRenewリクエストを受信した場合に、イベント監視数に応じて適切な有効時間の設定することが可能となる。
【０１１２】
なお、本実施の形態とは異なるが、イベント種類や、リクエスト送信元のクライアントに応じて有効時間を設定しても良い。そこで、変形例として、イベント種類に従って有効時間を設定する場合について説明する。図３０は、変形例１にかかる有効時間管理テーブルのテーブル構造を示した図である。図３０（Ａ）に示すように、有効時間管理テーブルでは、イベント種類と、有効時間とが対応付けられている。これにより、図２９のステップＳ３３０２において、設定部は、当該有効時間管理テーブルを参照し、Subscribeリクエスト又はRenewリクエストで監視を要求するイベントを表すイベント種類と対応付けられた有効時間の設定を行う。また、本変形例にかかる有効時間管理テーブルにおいては、重要なイベント種類ほど長い有効時間が設定されている。これにより、重要なイベントがクライアントに通知される可能性が向上する。なお、他の処理は第１の実施形態と同様とする。
【０１１３】
さらに他の変形例として、リクエスト送信元のクライアントに応じて有効時間を設定する場合について説明する。図３０（Ｂ）は、変形例２にかかる有効時間管理テーブルのテーブル構造を示した図である。図３０（Ｂ）に示すように、有効時間管理テーブルでは、クライアントを識別するＩＰアドレスと、有効時間とが対応付けられている。また、有効時間管理テーブルにおいては、重要なイベント種類ほど長い有効時間が設定されている。また、本変形例にかかる有効時間管理テーブルにおいては、クライアントほど長い有効時間が設定されている。これにより、図２９のステップＳ３３０２において、設定部は、当該有効時間管理テーブルを参照し、Subscribeリクエスト又はRenewリクエストで監視を要求してきたクライアントに応じて、有効時間の設定を行う。また、本変形例にかかる有効時間管理テーブルにおいては、重要なクライアントほど長い有効時間が設定されている。なお、他の処理は第１の実施形態と同様とする。
【０１１４】
上述した変形例のように、利用者の実施する環境に応じて適切な有効時間管理テーブルを使用して良い。また、上述した実施の形態及び変形例で説明した全ての有効時間管理テーブルを予め画像処理装置に格納して、管理者が適切な有効時間管理テーブルを使用するように設定しても良い。この設定手法としては、画像処理装置に備え付けられているオペレーションパネルからネットワーク制御部に対して設定してもよいし、ネットワーク制御部を通じて外部から設定されたりする。
【０１１５】
また、本実施の形態にかかる画像処理装置１においては、イベント管理テーブル２６２１からレコードを削除するのは、有効期間を経過した場合に限るものではない。例えば、画像処理装置１は、クライアントがネットワークから離脱した場合にも、イベント管理テーブル２６２１からレコードを削除する。
【０１１６】
次に、本実施の形態にかかる画像処理装置１におけるネットワーク離脱パケット受信処理について説明する。図３１は、本実施の形態にかかる画像処理装置１における上述した処理の手順を示すフローチャートである。
【０１１７】
まず、本実施の形態にかかる画像処理装置１のＨＴＴＰ制御部４５は、Ｉ／Ｆ部１７を介して、パケットの受信を受け付ける（ステップＳ３６０１）。
【０１１８】
次に、ＨＴＴＰ制御部４５は、WS-Discoveryプロトコルによるパケットを受信したか否か判断する（ステップＳ３６０２）。WS-Discoveryプロトコル以外のパケットを受信した場合（ステップＳ３６０２：Ｎｏ）、WS-Discovery処理部２６１２以外の構成が処理を行ったあと、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１１９】
そして、WS-Discoveryプロトコルによるパケットを受信した場合（ステップＳ３６０２：Ｙｅｓ）、WS-Discovery処理部２６１２が、当該パケットが、クライアントからのネットワーク離脱パケットか判断する（ステップＳ３６０３）。ネットワーク離脱パケットではないと判断した場合（ステップＳ３６０３：Ｎｏ）、判断したパケットに応じて適切な処理を行った後、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１２０】
図３２は、ネットワーク離脱パケットの一例を示した図である。図３２の行３７０１を確認すると、“Bye”と記載されているためにネットワーク離脱パケットと判断できる。
【０１２１】
図３１に戻り、WS-Discovery処理部２６１２が、ネットワーク離脱パケットと判断した場合（ステップＳ３６０３：Ｙｅｓ）、その旨を、ネットワークを離脱したクライアントを示すＩＰアドレスと共にイベント管理部２６１１に通知する。
【０１２２】
そして、イベント管理部２６１１が、イベント管理テーブル２６２１で、通知されたＩＰアドレスが通知先クライアントとして登録されたレコードが存在するか否か判断する（ステップＳ３６０４）。無いと判断した場合（ステップＳ３６０４：Ｎｏ）、特に処理を行わず、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１２３】
また、イベント管理部２６１１は、当該レコードが存在すると判断した場合（ステップＳ３６０４：Ｙｅｓ）、イベント管理テーブル２６２１から、当該レコードを削除する処理を行う（ステップＳ３６０５）。これにより、ネットワーク離脱されたクライアントからのイベント監視要求が削除されたことになる。その後、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１２４】
上述した処理によりネットワーク離脱したクライアントからのイベント通知要求が削除される。
【０１２５】
次に、画像処理装置１において、ネットワーク離脱パケットを受信した場合について説明する。図３３は、画像処理装置１において、ネットワーク離脱パケットを受信した場合のシーケンス図である。
【０１２６】
まずは、ＨＴＴＰ制御部４５は、クライアント（Subscriber）から、ネットワーク離脱パケット（Bye）を受信する（ステップＳ３８０１）。
【０１２７】
当該ネットワーク離脱パケットは、WS-Discoveryプロトコルで記載されているので、WS-Discovery処理部２６１２に受信したパケットを通知する（ステップＳ３８０２）。
【０１２８】
そして、WS-Discovery処理部２６１２は、ＨＴＴＰ制御部４５から渡されたパケットをさらにＳＯＡＰ／ＸＭＬ処理部２３に渡してその内容を解析させる（ステップＳ３８０３）。ＳＯＡＰ／ＸＭＬ処理部２３はステップＳ３８０３において受け取ったメッセージの内容解析結果をWS-Discovery処理部２６１２に対して返信する（ステップＳ３８０４）。
【０１２９】
つぎに、WS-Discovery処理部２６１２は、受け取った内容解析結果から、所定のクライアントのネットワーク離脱が発生したことを認識し、イベント管理部２６１１に対して、ネットワークを離脱したクライアントしたことを通知する（ステップＳ３８０５）。これにより、ネットワークを離脱したクライアントからのイベント監視が格納されているレコードをイベント管理テーブル２６２１から削除できる。
【０１３０】
本実施の形態にかかる画像処理装置１では、当該リクエストを出したクライアントに対してイベントを通知する有効時間を状況に応じて変化させることで、画像処理装置１の処理負担を軽減させることができる。
【０１３１】
また、有効時間管理テーブルで有効時間を管理し、受け付けたリクエストに応じて有効時間を変更させることで、画像処理装置１に自由度を持たせることができる。また、有効時間管理テーブルに格納されているデータを利用者に変更可能とすることで、カスタマイズ性を向上させることができる。
【０１３２】
また、上述した実施の形態にかかる画像処理装置１、２６００で実行されるイベント通知プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、上述した実施の形態にかかる画像処理装置１、２６００で実行されるイベント通知プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。
【０１３３】
また、上述した実施の形態にかかる画像処理装置１、２６００のイベント通知プログラムを、ＲＯＭ等に予め組みこまれて提供される。
【０１３４】
上述した実施の形態にかかる画像処理装置１、２６００で実行されるイベント通知プログラムは、上述した各部（システム制御部２４、メモリ制御部２５、配信制御部２６、ネットワーク制御部２７、ＯＳ／Ｋｅｒｎｅｌ２８）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵが上記記録媒体からイベント通知プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、システム制御部２４、メモリ制御部２５、配信制御部２６、ネットワーク制御部２７、ＯＳ／Ｋｅｒｎｅｌ２８が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１３５】
以上のように、本発明にかかるイベント通知装置、イベント通知方法及びイベント通知プログラムは、他の装置に対してイベントを通知する技術に有用であり、特に、イベント通知を行う際に処理負担を軽減させる技術に適している。
【図面の簡単な説明】
【０１３６】
【図１】第１の実施の形態にかかる画像処理装置およびネットワークを介して画像処理装置を利用する装置により構成されるシステムの一例を示す図である。
【図２】第１の実施の形態にかかる画像処理装置のハードウェア構成例を示す図である。
【図３】第１の実施の形態にかかる画像処理装置のソフトウェア構成例を示す図である。
【図４】第１の実施の形態にかかる画像処理装置の特徴的な処理を実現するためのイベント通知部およびアプリケーション部の構成例を示す図である。
【図５】Subscribeメッセージの一例を示す図である。
【図６】SubscribeResponseメッセージの一例を示す図である。
【図７】Renewメッセージの一例を示す図である。
【図８】RenewResponseメッセージの一例を示す図である。
【図９】SubscriptionEndメッセージの一例を示す図である。
【図１０】StatusEventReportメッセージの一例を示す図である。
【図１１】faultメッセージの一例を示す図である。
【図１２】画像処理装置がSubscribeメッセージまたはRenewメッセージを受信するシーケンス例を示す図である。
【図１３】第１の実施形態にかかるイベント管理情報のテーブル構造を示した図である。
【図１４】イベント発生監視動作およびイベント通知動作のシーケンス例を示す図である。
【図１５】画像処理装置がイベント監視動作時に使用する情報の一例を示す図である。
【図１６】画像処理装置がSubscriptionEndメッセージを送出する場合のシーケンス例を示す図である。
【図１７】画像処理装置がSubscribeメッセージ／Renewメッセージを受信した場合の動作例を示すフローチャートである。
【図１８】画像処理装置がSubscribeメッセージ／Renewメッセージ受信時の動作において使用する情報の一例を示す図である。
【図１９】画像処理装置がSubscribeメッセージを受信した場合の動作例を示すフローチャートである。
【図２０】画像処理装置においてイベントが発生した場合の動作例を示すフローチャートである。
【図２１】画像処理装置においてイベントが発生した場合の動作例を時系列に示した図である。
【図２２】画像処理装置がイベント通知動作において使用する情報の一例を示す図である。
【図２３】第２の実施の形態にかかる画像処理装置のイベント通知部およびアプリケーション部の構成例を示す図である。
【図２４】第２の実施の形態にかかるイベント管理テーブルのテーブル構造を示した図である。
【図２５】第２の実施の形態にかかる有効時間管理テーブルのテーブル構造を示した図である。
【図２６】WS-EventingプロトコルにおけるSubscribeのメッセージの一例を示した図である。
【図２７】第２の実施の形態にかかるSubscribeResponseメッセージの第１の例を示した図である。
【図２８】第２の実施の形態にかかるSubscribeResponseメッセージの第２の例を示した図である。
【図２９】第２の実施の形態にかかる画像処理装置におけるメッセージを受信した場合の処理の手順を示すフローチャートである。
【図３０】第２の実施の形態の変形例にかかる有効時間管理テーブルのテーブル構造を示した図である。
【図３１】第２の実施の形態にかかる画像処理装置におけるネットワーク離脱パケット受信処理の手順を示すフローチャートである。
【図３２】ネットワーク離脱パケットの一例を示した図である。
【図３３】第２の実施の形態にかかる画像処理装置において、ネットワーク離脱パケットを受信した場合のシーケンス図である。
【図３４】課題を説明するための図である。
【符号の説明】
【０１３７】
１ 画像処理装置
１１ ＣＰＵ
１２ システムメモリ
１３ ノースブリッジ（ＮＢ）
１４ サウスブリッジ（ＳＢ）
１５ ＡＳＩＣ
１６ 記憶部
１７ Ｉ／Ｆ部
２１ アプリケーション部
２２ プラットフォーム部
２３ ＳＯＡＰ／ＸＭＬ処理部
２４ システム制御部
２５ メモリ制御部
２６ 配信制御部
２７、２６０１ ネットワーク制御部
２８ ＯＳ／Ｋｅｒｎｅｌ
３１ アプリケーション制御部
３２ イベント検出部
３３ 情報通信部
４１ 全体制御部
４２ WS-Eventing処理部
４３、２６１１ イベント管理部
４４ アプリ通信部
４５ ＨＴＴＰ制御部
４６ プロトコル制御部
５１ リクエスト受信部
５２ イベント通知部
６１ イベント監視部
６２ 追加部
６３ 更新部
６４、２６３１ 設定部
７１ イベント管理情報
７２ 監視間隔テーブル
７３ 優先度テーブル
２６１２ WS-Discovery処理部
２６２１ イベント管理テーブル
２６２２ 有効時間管理テーブル
【技術分野】
【０００１】
本発明は、ネットワークなどを介して接続された他の機器にイベントを通知するイベント通知装置、イベント通知方法及びイベント通知プログラムに関するものである。
【背景技術】
【０００２】
近年、インターネットやイントラネットなどのネットワークに接続する機能を備え、ネットワークを介して他の機器（ユーザ）からの操作指示などを受け付けるプリンタなどの画像処理装置（ネットワーク対応の画像処理装置）が普及してきている。このような画像処理装置は、自身においてイベントが発生した場合、自身を利用するユーザに対して発生したイベントの内容を通知する。各ユーザは、イベントの内容（画像処理装置の状態）を把握し、必要に応じてその内容に従った動作を実行する。
【０００３】
ところで、ある特定の画像処理装置を多数のユーザが利用する場合、発生したイベントの内容を各ユーザに対して一斉に通知するため、ネットワーク上のトラフィックが一時的に増大し、応答速度が低下してしまう、という問題が指摘されていた。そのため、この問題を解決するために、下記特許文献１に記載の技術では、イベントの通知先となるユーザ数に応じて、各ユーザに対するイベント通知動作の間に待ち時間（ディレイ）を設けることによりトラフィックが急増するのを防止し、応答速度が低下するのを回避するようにしている。
【０００４】
【特許文献１】特開２００１−２８２４７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述したように、上記特許文献１に記載の技術によれば、応答速度が低下するのを回避することが可能である。しかしながら、イベントの通知先（イベント内容を示す情報の宛先）となるユーザ数が多い場合には、イベント発生時にその旨を全てのユーザに対して通知できないことがある、という上記応答速度の低下とは異なる解決すべき課題が存在する。
【０００６】
たとえば、画像処理装置が２秒間隔でイベントを監視する場合について考えてみると、第１のイベントの発生を検出してから２秒経過後に新たなイベント（第２のイベント）が発生（イベント発生を検出）すると、その時点で第１のイベントの内容を示す第１のイベント発生情報が通知されていないユーザに対しては、引き続き第１のイベント発生情報を通知する。その結果、第１のイベントが発生してから２秒以内に第１のイベント発生情報を通知されなかったユーザの認識と、画像処理装置の実際の状態とに不一致が生じ、ユーザが混乱する可能性がある。すなわち、図３４（Ａ）に示した例のような場合には全てのユーザに対して正しくイベント発生情報を通知できるが、図３４（Ｂ）に示した例のような場合には正しく通知できず、２秒以内に通知を受けることができなかったユーザは古い情報の通知を受ける可能性がある。
【０００７】
また、他の例としては、複数の装置に対してイベント通知を要求する有効期限が長いために、通知を要求するユーザ数が多くなり、通知処理に遅延が生じる可能性がある。
【０００８】
本発明は、上記に鑑みてなされたものであって、イベント発生時に当該イベントの通知を必要とするユーザに対して適切にイベントの通知を行うイベント通知装置、イベント通知方法及びイベント通知プログラムを得ることを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、本発明にかかるイベント通知装置は、クライアント装置とネットワークを介して接続されたイベント通知装置であって、イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けて記憶するイベント情報記憶手段と、各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信手段と、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加手段と、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定手段と、それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視手段と、前記イベント監視手段がイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知手段と、を備える。
【００１０】
また、本発明にかかるイベント通知装置は、上記のイベント通知装置において、前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、を特徴とする。
【００１１】
また、本発明にかかるイベント通知装置は、上記のイベント通知装置において、前記イベント情報記憶手段は、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて記憶し、前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記有効時間内に限り行うこと、を特徴とする。
【００１２】
また、本発明にかかるイベント通知方法は、ネットワークを介して接続されたクライアント装置に対してイベントを通知するイベント通知方法であって、イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、を有することを特徴とする。
【００１３】
また、本発明にかかるイベント通知方法は、上記のイベント通知方法において、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、を特徴とする。
【００１４】
また、本発明にかかるイベント通知方法は、上記のイベント通知方法において、前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、を特徴とする。
【００１５】
また、本発明にかかるイベント通知プログラムは、ネットワークを介して接続されたクライアント装置に対してイベントを通知させることをコンピュータに実行させるイベント通知プログラムであって、イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、をコンピュータに実行させることを特徴とする。
【００１６】
また、本発明にかかるイベント通知プログラムは、上記のイベント通知プログラムにおいて、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、を特徴とする。
【００１７】
また、本発明にかかるイベント通知プログラムは、上記のイベント通知プログラムにおいて、前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、を特徴とする。
【発明の効果】
【００１８】
本発明によれば、所定の監視制御に用いる設定情報を設定し、当該設定情報を使用して所定の監視制御を行うことで、状況に応じて適切な監視を行うことを可能とし、処理負担を軽減させることができるという効果を奏する。
【発明を実施するための最良の形態】
【００１９】
以下に、添付図面を参照して、この発明にかかるイベント通知装置であってコピー機能、ファクシミリ（ＦＡＸ）機能、プリント機能、スキャナ機能及び入力画像（スキャナ機能による読み取り原稿画像やプリンタあるいはＦＡＸ機能により入力された画像）を配信する機能等を備える画像処理装置に適用した最良な実施形態を詳細に説明する。
【００２０】
（第１の実施の形態）
図１は、第１の実施形態にかかる画像処理装置およびネットワークを介して画像処理装置を利用する端末により構成されるシステムの一例を示す図である。このシステムは、上記画像処理装置に相当する“機器”および当該機器を利用する複数のパーソナルコンピュータ（ＰＣ−Ａ，ＰＣ−Ｂ，ＰＣ−Ｃ，ＰＣ−Ｄ，ＰＣ−Ｅ，ＰＣ−Ｆ，ＰＣ−Ｇ）を含んでいる。通常、ネットワークを介して画像処理装置１を利用するためには、所定の手続を実行する必要があるが、上記各パーソナルコンピュータは、必要な手続を既に実行し、上記画像処理装置１を利用可能な状態にあるものとする。なお、画像処理装置１を利用するのはパーソナルコンピュータに限らず、同様の通信機能などを備えた端末であってもよい。また、これ以降、ネットワークを介して上記画像処理装置１を利用する端末をクライアントと呼ぶ。
【００２１】
図２は、本実施の形態にかかる画像処理装置のハードウェア構成例を示す図であり、この画像処理装置１は、ＣＰＵ１１と、システムメモリ１２と、ノースブリッジ（ＮＢ）１３と、サウスブリッジ（ＳＢ）１４と、ＡＳＩＣ１５と、記憶部１６と、Ｉ／Ｆ部１７と、を備える。なお、以下、上記画像処理装置を“画像処理装置１”と呼ぶ。
【００２２】
画像処理装置１において、ＣＰＵ１１は、画像処理装置１の全体の制御を行う。システムメモリ１２は、描画処理を行う際などに使用される。ＮＢ１３は、ＣＰＵ１１、システムメモリ１２、ＳＢ１４、ＡＳＩＣ１５、Ｉ／Ｆ部１７を接続するためのブリッジ、ＳＢ１４は、図２に示した各構成要素と図示されていない他の構成要素（ＲＯＭなど）とを接続するためのブリッジである。ＡＳＩＣ１５は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）である。記憶部１６は、ローカルメモリ，ＨＤＤ（Hard Disk Drive），Ｆｌａｓｈ ＲＯＭ，ＮＶＲＡＭ，などを含み、画像データ等の格納用領域や画像処理を行う際の作業用領域、などとして使用される。Ｉ／Ｆ部１７は、Ethernet（登録商標） I/F，USB I/F，IEEE1394 I/F，無線I/F，などを含む。これらのＩ／Ｆは、インターネットやイントラネットなどのネットワークへの接続やパーソナルコンピュータなどへの接続のためなどに使用される。
【００２３】
図３は、本実施の形態にかかる画像処理装置１のソフトウェア構成例を示す図である。アプリケーション部２１、プラットフォーム部２２およびＳＯＡＰ／ＸＭＬ処理部２３がソフトウェアを構成し、これらの各構成要素は、図２に示したＣＰＵ１１により制御される。また、アプリケーション部２１は、プリンタ、コピーなどの画像形成処理に関連するユーザーサービスに固有の処理を行う複数のアプリケーション処理部（アプリ＃１，アプリ＃２，アプリ＃３，アプリ＃４，…）を含み、プラットフォーム部２２は、ＯＳ／Ｋｅｒｎｅｌ２８とともに、アプリケーション部２１からの処理要求を解釈してハードウェアなどの各種資源の獲得要求を発生する各種制御部（システム制御部２４，メモリ制御部２５，配信制御部２６，ネットワーク制御部２７，…）を含む。また、プラットフォーム部２２は、予め定義されている関数によりアプリケーション部２１からの処理要求を受信可能とするアプリケーションプログラムインターフェース（ＡＰＩ）を有する。
【００２４】
なお、システム制御部２４は、アプリケーションの管理、ハードウェア資源の管理、などの処理を行う。メモリ制御部２５は、メモリの取得および解放などのメモリ制御を行う。配信制御部２６は、他機器との送受信のためのデータの管理やデータの加工などを行う。ネットワーク制御部２７は、図１に示したEthernet（登録商標）I/Fなどのネットワークインタフェイスと接続され、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供し、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分け、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。また、ＯＳ／Ｋｅｒｎｅｌ２８にはソケット以下のネットワーク処理部が存在している。
【００２５】
ＳＯＡＰ／ＸＭＬ処理部２３は、アプリケーション部からもプラットフォーム部からも使用できるような形で存在している。このＳＯＡＰ／ＸＭＬ処理部２３は、ＳＯＡＰ／ＸＭＬメッセージのエンコード／デコードを行う。なお、ＳＯＡＰ／ＸＭＬ処理部２３は、通常、ライブラリの形式で提供されるが、プロセスの形式でもかまわない。
【００２６】
図４は、本実施の形態にかかる画像処理装置１の特徴的な処理を実現するためのイベント処理部の構成例および図３に示したアプリケーション部２１の構成例を示す図である。このイベント処理部は、図３に示したプラットフォーム部２２に含まれるネットワーク制御部２７およびＳＯＡＰ／ＸＭＬ処理部２３と、図２に示した記憶部１６およびＩ／Ｆ部１７と、により構成される。
【００２７】
ネットワーク制御部２７は、全体を統括する全体制御部４１、WS-Eventingプロトコルを処理するWS-Eventing処理部４２、イベントを管理するイベント管理部４３、図３に示したアプリケーション部２１との間で各種情報（メッセージやデータ）のやり取りを行うアプリ通信部４４、ＨＴＴＰ制御部４５、およびＨＴＴＰ以外の各種プロトコル（たとえばFTP，Port9100，LPR)を処理するプロトコル制御部４６を備える。
【００２８】
ＨＴＴＰ制御部４５は、リクエスト受信部５１と、イベント通知部５２とを備え、ＨＴＴＰプロトコルを用いてデータの送受信を行う。リクエスト受信部５１は、クライアントからイベント監視リクエストを受信する。そして、リクエスト受信部５１は、受信したイベント監視リクエストを、イベント管理情報７１に登録する。
【００２９】
イベント通知部５２は、後述するイベント管理部４３がイベントを検出した場合に、ＨＴＴＰプロトコルを用いて、送信先にイベント通知を行う。
【００３０】
イベント管理部４３は、イベント監視部６１と、追加部６２と、更新部６３と、設定部６４とを備える。イベント監視部６１は、アプリ通信部４４を介して、アプリケーション部２１の各アプリにおいてイベントが発生するか否かを監視する。
【００３１】
追加部６２は、イベント監視リクエストをリクエスト受信部５１が受信した場合、イベント監視リクエストに含まれているイベント名と、イベント監視リクエストの送信元のクライアント名と、有効期限とを対応付けて、後述するイベント管理情報７１に追加する。なお、この送信元のクライアントは、イベントの通知先のクライアントとして追加される。また、イベント名は、換言すれば発生するイベントの種類を示している。なお、有効期限の取得手法については後述する。更新部６３は、当該イベント管理情報に対して更新処理を行う。
【００３２】
設定部６４は、イベント管理情報７１が記憶しているイベントの通知先のクライアントおよびイベント名のいずれか一つ以上に基づいて、イベント監視部６１が監視制御を行う設定情報を設定する。本実施の形態では、設定部６４が、設定情報としてイベントの監視周期を設定する場合について説明する。
【００３３】
記憶部１６は、イベント管理情報７１と、監視間隔テーブル７２と、優先度テーブル７３と、を記憶する。なお、各テーブルの詳細については後述する。
【００３４】
アプリケーション部２１に含まれる各アプリケーション処理部（アプリ＃１，…）は、それぞれ同様の構成をとり、アプリケーション処理部の制御を行うアプリケーション制御部３１と、イベントを検出するイベント検出部３２と、図３に示したプラットフォーム部２２を構成する各制御部（すなわち上記イベント処理部に含まれる各制御部）との間で各種情報（メッセージやデータ）のやり取りを行う情報通信部３３と、を備える。
【００３５】
そして、上記イベント処理部は、アプリケーション部２１の各アプリケーション処理部（アプリ＃１，…）においてイベントが発生したかどうかの監視を定期的に行い、いずれかのアプリケーション処理部におけるイベント発生を検出した場合には、その旨を各クライアントへ通知する。イベントが発生したかどうかの監視動作の詳細およびイベント発生時の各クライアントへのイベント内容通知動作の詳細については後述する。
【００３６】
つづいて、イベント処理部の動作を中心に、本実施の形態にかかる画像処理装置１の詳細動作を説明する。まず、各クライアントが上記画像処理装置１からイベント発生時にその内容の通知を受けるために必要な動作である画像処理装置１に対する初期設定動作について説明する。具体的には、クライアントが画像処理装置１に対して、発生したイベントを通知するように要求を出し、この要求に対して画像処理装置１が実行する動作について説明する。
【００３７】
WS-Eventingプロトコルを使用する場合の例を以下に示す。まずクライアントは、図５に示したような内容のメッセージを画像処理装置１に対して送信する。図５は、Subscribeメッセージの一例を示したものであり、クライアントが、このメッセージで指示するイベントが発生した場合、その内容を通知するように画像処理装置１に対して要求するものである。このメッセージの内容は、「“StatusEvent（符号５０１）”が示すイベントについてStatusが変化したら（イベントが発生したら）通知をしてほしい」ということを示している。Subscribeメッセージを受信した画像処理装置１は、その要求内容に応じることができるかどうかを確認し、確認結果に基づいた内容の応答メッセージを返信する。
【００３８】
つぎに、Subscribeメッセージを受信した画像処理装置１は、たとえば図６に示したような内容のメッセージをクライアントに対して送信する。図６は、Subscribeメッセージに対するレスポンス（SubscribeResponse）メッセージの一例を示したものであり、Subscribeメッセージを正常に受け付けた場合のものである。この内容は、「Subscribeメッセージで指示されたイベントが発生（検知）した場合、Expiresフィールド６０１に示された有効期限が到来するまでの間、その内容（発生したイベント）を通知する」ということを示している。これ以後、原則としてExpiresフィールドに示された有効期限が到来するまで、画像処理装置１は、上記Subscribeメッセージで指示されたイベントを検知した場合、その内容を上記SubscribeResponseメッセージの送信相手先クライアントへ通知する。
【００３９】
また、上記SubscribeResponseメッセージを受信したクライアントは、当該受信したメッセージに示された上記有効期限が到来後も引き続いてイベントの通知を受けたい場合、図７に示したような内容のメッセージを画像処理装置１に対して送信する。図７は、Renewメッセージの一例を示したものであり、通常はクライアントが画像処理装置１からイベント通知を受けている状態において送信される。この内容は、「（それ以前に受信したSubscribeResponseメッセージなどに含まれるExpiresフィールドに示された）有効期限が到来後も引き続いて、発生したイベントを通知してほしい」ということを示している。
【００４０】
Renewメッセージを受信すると、画像処理装置１は、たとえば図８に示したような内容のメッセージをクライアントに対して送信する。図８は、Renewメッセージに対するレスポンス（RenewResponse）メッセージの一例を示したものであり、Renewメッセージを正常に受け付けた場合のものである。この内容は、「Expiresフィールドに示された有効期限が到来するまでの間、発生（検知）したイベントを通知する」ということを示している。すなわち、更新された有効期限がExpiresフィールドに示される。
【００４１】
なお、図９は、SubscriptionEndメッセージの一例を示す図である。このSubscriptionEndメッセージは、上記Expiresフィールドに示された有効期限内であるにもかかわらずイベントの通知を停止する場合、画像処理装置１がイベントの通知を停止するクライアントに対して送信する。
【００４２】
図１０は、StatusEventReportメッセージの一例を示す図である。画像処理装置１は、SubscribeResponseメッセージおよびRenewResponseメッセージの送信先であるクライアントに対して、それらのメッセージにて通知した有効期限が到来するまでに発生したイベントを、このStatusEventReportメッセージを使用して通知する。図１０に示した例は、トナーがなくなった（Out of Toner）ことを検出した場合にそれを通知するためのメッセージである。
【００４３】
また、図１１の（Ａ），（Ｂ）は、それぞれSubscribeメッセージ（図５参照），Renewメッセージ（図７参照）に対する応答メッセージの一例を示す図であり、画像処理装置１が要求（Subscribe，Renew）を受け付けられない場合に返送するfaultメッセージの一例を示している。SubscribeメッセージまたはRenewメッセージを受信したが、それを受け付けることができない場合、画像処理装置１は、SubscribeResponseメッセージまたはRenewメッセージに代えて、faultメッセージを送信する。図１１の（Ａ）および（Ｂ）に示したいずれの例も、リソース不足（not-enough resource）を理由として要求（SubscribeまたはRenew）を受け付けられない場合に返送されるメッセージである。
【００４４】
図１２は、画像処理装置１がクライアントからSubscribeメッセージまたはRenewメッセージを受信するシーケンス例を示す図である。なお、“Subscriber”がクライアントに相当する。
【００４５】
画像処理装置１がクライアントからSubscribeメッセージまたはRenewメッセージを受信すると（ステップＳ１１）、画像処理装置１のネットワーク制御部において、ＨＴＴＰ制御部４５のリクエスト受信部５１が、受信したメッセージをWS-Eventing処理部４２へ渡す（ステップＳ１２）。WS-Eventing処理部４２はＨＴＴＰ制御部４５から渡されたメッセージをさらにＳＯＡＰ／ＸＭＬ処理部２３に渡してその内容を解析させる（ステップＳ１３）。ＳＯＡＰ／ＸＭＬ処理部２３はステップＳ１３において受け取ったメッセージの内容解析結果をWS-Eventing処理部４２に対して返信する（ステップＳ１４）。
【００４６】
つぎに、WS-Eventing処理部４２は、ステップＳ１４において受け取った内容解析結果を登録するように、イベント管理部４３に対して要求し（ステップＳ１５）、イベント管理部４３はステップＳ１５における要求内容に基づいた処理を実行する。
【００４７】
たとえば、リクエスト受信部５１がSubscribeメッセージを受信し、イベント管理部４３が当該メッセージで示された要求を受け入れることができると判断した場合、イベント管理部４３の追加部６２は、Subscribeメッセージの内容に基づいて、新たなレコードをイベント管理情報７１に追加する。このイベント管理情報７１は、あるイベントが発生した場合、そのイベントをどのクライアントに通知すべきかを示した情報であり、各イベントとその通知先クライアントの対応関係を示したものである。イベント管理情報７１にはイベント通知動作の有効期限情報（どのイベントの通知をどのクライアントに対していつまで行うかを示す情報）も含まれる。
【００４８】
図１３は、イベント管理情報７１のテーブル構造を示した図である。図１３に示すようにイベント管理情報７１は、イベント名と、通知先クライアントと、有効期限とを対応付けて記憶している。つまり、イベント管理部４３が任意のイベントが発生したと判断した場合、イベント通知部５２が、当該イベントを示すイベント名と対応付けられた通知先クライアントに対して、有効期限内であれば、発生した当該イベントを示すメッセージを通知する。
【００４９】
また、リクエスト受信部５１がRenewメッセージを受信し、イベント管理部４３が当該メッセージが示す要求を受け入れることができると判断した場合、更新部６２は上記イベント管理情報７１に含まれるイベント通知動作の有効期限情報を更新、すなわちイベント管理情報７１を更新する。なお、SubscribeメッセージやRenewメッセージの受信に伴い更新されたイベント管理情報７１は、記憶部１６などに保持される。SubscribeメッセージやRenewメッセージが示す要求を受け入れられない場合、イベント管理情報７１は更新されない。
【００５０】
イベント管理部４３は、処理が終了すると、その処理結果をWS-Eventing処理部４２へ通知する（ステップＳ１６）。さらに、WS-Eventing処理部４２は、上記SubscribeメッセージまたはRenewメッセージの送信元であるクライアントに対して返信するメッセージ（レスポンスメッセージ）を、ステップＳ１６において通知を受けた処理結果に基づいて生成するようにＳＯＡＰ／ＸＭＬ処理部２３に対して要求する（ステップＳ１７）。ＳＯＡＰ／ＸＭＬ処理部２３は、WS-Eventing処理部４２からの要求内容に従ってレスポンスメッセージを生成し、それをWS-Eventing処理部４２に渡す（ステップＳ１８）。ステップＳ１８においてレスポンスメッセージを受け取ったWS-Eventing処理部４２は、それをＨＴＴＰ制御部４５へ渡し（ステップＳ１９）、ＨＴＴＰ制御部４５は受け取ったレスポンスメッセージをクライアントに対して返信する（ステップＳ２０）。
【００５１】
なお、ステップＳ２０においてＨＴＴＰ制御部４５から返信されるメッセージの内容は、上記ステップＳ１１において画像処理装置が受け取ったメッセージの内容（SubscribeメッセージかRenewメッセージか）および上記ステップＳ１６におけるイベント管理部４３の処理結果により異なる。ステップＳ１１において受け取ったメッセージが示す内容（要求）を画像処理装置１が受け付ける場合には、SubscribeResponseメッセージ（図６参照）またはRenewResponseメッセージ（図８参照）が返信される。一方、要求を受け付けない場合には、faultメッセージ（図１１（Ａ）および（Ｂ）参照）が返信される。
【００５２】
図１４は、画像処理装置１におけるイベント発生監視動作シーケンスおよび検出したイベントの通知動作シーケンスの一例を示す図である。
【００５３】
画像処理装置１においてネットワーク制御部のイベント管理部４３のイベント監視部６１は、アプリケーション部２１の各アプリケーション処理部においてイベントが発生したかどうかの監視を定期的に行う（ステップＳ３１，Ｓ３３）。具体的には、イベント監視部６１は、アプリ通信部４４を介して、イベントが発生したかどうか（状態が変化したかどうか）を各アプリケーション処理部のイベント検出部３２に対して問い合わせる。
【００５４】
なお、図１４に示した例においては、説明を簡単にするためにイベント管理部４３が１つのアプリケーション処理部（アプリ＃Ｎ）のイベント検出部３２に対してのみ問い合わせを行っているが、実際には全てのアプリケーション処理部に対して問い合わせを行う。また、イベント管理部４３と各アプリケーション処理部のイベント検出部３２はアプリ通信部４４および情報通信部３３を介して通信を行う。
【００５５】
ここで、イベント管理部４３のイベント監視部６１が各アプリケーション処理部においてイベントが発生したかどうかの監視を定期的に行うにあたり、イベント管理部４３の設定部６４が、その監視周期を監視結果の通知対象となるクライアント数に応じて設定する。
【００５６】
図１５は、画像処理装置がイベント監視動作時に使用する情報の一例を示す図である。たとえば、図１５（Ａ）に示したような監視間隔テーブル７２を予め準備して記憶部１６に保持しておく。そして、設定部６４が、上記イベント管理情報７１から監視結果の通知対象であるSubscribe登録済みクライアントの数（イベント発生時にその通知を行う相手先となるクライアントの数）を確認する。確認の結果、設定部６４は、クライアント数が１００以下であれば（Subscribe登録個数が１００個以下であれば）イベント発生の監視周期（Polling間隔）を１秒に設定し、１０１以上２００未満であれば監視周期を２秒に設定する。なお、図１５（Ａ）の監視間隔テーブル７２に示した監視周期は、１クライアントに対する監視結果通知処理に必要とする時間に基づいて決定する。これにより、検出したイベントをSubscribe登録済みのクライアント全てに対して正しく通知することができる。
【００５７】
ところで、画像処理装置１において発生するイベントには、その内容を迅速かつ正確に通知する必要があるものとそうでないものが存在する。たとえば、トナーに関するイベントでは、トナーが完全に無くなったことを検出するのは頻繁に行う必要があると考えられる。一方、トナーが少なくなったことを検出するのはそれほど頻繁に行う必要はなく、またトナーが少なくなったことをクライアントに対して直ちに、正しく通知しなくても（トナーが少ない状態となった後、直ちにその状態が通知されなくても）それほど大きな問題とはならない。そのため、各イベントの監視周期を一律にするのではなく、アプリケーションごとにイベントの監視周期を違えてもよい。
【００５８】
そこで、本実施の形態の変形例としては、図１５（Ａ）に示した監視間隔テーブル７２の代わりに、図１５（Ｂ）に示したような監視間隔テーブルを予め準備して記憶部１６に保持しておき、設定部６４は、当該監視間隔テーブルに示された監視時間を使用して監視間隔を設定する。そして、イベント監視部６１が当該監視間隔で各イベントの監視を行う。これにより、優先度の高いイベント（通知の迅速性や正確性が要求されるイベント）の発生をより迅速かつ正しくSubscribe登録済みのクライアント全てに対して通知することができる。なお、図１５（Ｂ）の監視間隔テーブルに示した監視周期は、１クライアントに対する監視結果通知処理に必要とする時間に基づいて決定する。また、図１５（Ｂ）の例では監視間隔を２種類としているが３種類以上としてもよい。
【００５９】
第１の実施の形態の図１４に戻り、イベント検出部３２は、イベント管理部４３のイベント監視部６１からの問い合わせに対して、イベントが発生していなければその旨を通知する（ステップＳ３２）。これに対して、イベント検出部３２は、イベントが発生している場合にはその旨を通知する（ステップＳ３４）。
【００６０】
イベント検出部３２からイベント発生の通知を受けた場合、イベント管理部４３はその旨をWS-Eventing処理部４２へ通知する（ステップＳ３５）。WS-Eventing処理部４２は、イベントの発生をクライアントに対して通知するためのメッセージを生成するようにＳＯＡＰ／ＸＭＬ処理部２３に対して要求し（ステップＳ３６）、これに対するメッセージをＳＯＡＰ／ＸＭＬ処理部２３から受け取り（ステップＳ３７）、さらに、ＳＯＡＰ／ＸＭＬ処理部２３から受け取ったメッセージをＨＴＴＰ制御部４５へ渡す（ステップＳ３８）。そして、ＨＴＴＰ制御部４５のイベント通知部５２は、WS-Eventing処理部４２から受け取ったメッセージ（図１０に例示したようなStatusEventReportメッセージ）をクライアントに対して送信する（ステップＳ３９）。図１４においてはStatusEventReportメッセージをNotificationメッセージと表現している。通常、クライアントは受信したメッセージに対する応答メッセージ（図１４の例ではHTTP 200 Response）を返信する（ステップＳ４０）。なお、上記ステップＳ３９では、画像処理装置１のイベント通知部５２は、イベントの通知要求を受けている全てのクライアント（SubscribeメッセージまたはRenewメッセージを受信済み、かつそれらに対する応答メッセージにおいて示した有効期限が到来していないクライアント）に対して、発生したイベントを示すメッセージを送信する。
【００６１】
図１６は、画像処理装置１がSubscriptionEndメッセージを送出する場合のシーケンス例を示す図である。イベント管理部４３はSubscriptionEndに相当する事象が発生すると、その旨をWS-Eventing処理部４２へ通知する（ステップＳ５１）。WS-Eventing処理部４２は、SubscriptionEndをクライアントに対して通知するためのメッセージを生成するようにＳＯＡＰ／ＸＭＬ処理部２３に対して要求し（ステップＳ５２）、これに対するメッセージをＳＯＡＰ／ＸＭＬ処理部２３から受け取り（ステップＳ５３）、さらに、ＳＯＡＰ／ＸＭＬ処理部２３から受け取ったメッセージをＨＴＴＰ制御部４５へ渡す（ステップＳ５４）。そして、ＨＴＴＰ制御部４５はWS-Eventing処理部４２から受け取ったメッセージ（図９に例示したようなSubscriptionEndメッセージ）をクライアントに対して送信する（ステップＳ５５）。通常、クライアントは受信メッセージに対する応答メッセージを返信する（ステップＳ５６）。
【００６２】
図１７は、画像処理装置１がSubscribeメッセージ／Renewメッセージを受信した場合の動作例を示すフローチャートである。SubscribeメッセージまたはRenewメッセージを受信すると（ステップＳ６１）、画像処理装置１のイベント管理部４３は、その内容を確認し、特定条件に該当するかどうかを確認する（ステップＳ６２）。ここで、特定条件に該当するかどうかは、たとえば、SubscribeメッセージやRenewメッセージの送信元（クライアント）や、監視するイベントの種類に応じて判断する。
【００６３】
つまり、追加部６２は、Subscribeメッセージ／Renewメッセージを受信した場合、常にイベント管理情報７１にレコードを追加するわけではなく、Subscribeメッセージ／Renewメッセージに含まれているイベント名又はSubscribeメッセージ／Renewメッセージを送信したクライアントと、イベント管理情報７１に格納されている情報（例えば、イベント、通知先クライアント）と、に基づいて、Subscribeメッセージ／Renewメッセージに含まれているイベント名や、Subscribeメッセージ／Renewメッセージの送信元のクライアントと、を対応付けてイベント管理情報７１に追加するか否か判断する。この例としては、イベントやクライアント等に優先度を設定し、当該優先度に基づいて追加するか否か判断することが考えられる。
【００６４】
図１８は、Subscribe／Renewメッセージの送信元のＩＰアドレスと優先度の関係を保持する優先度テーブル７３の一例を示す図である。この場合、図１８（Ａ）に示したような優先度テーブル７３を予め準備して記憶部１６に保持しておき、保持しておいたテーブルを用いて判断を行う。たとえば、優先度（Priority）の高いＩＰアドレスの送信元からメッセージを受信した場合や、特定条件と判断する。
【００６５】
つまり、リクエスト受信部５１がSubscribeメッセージを受信した場合、イベント管理部４３の追加部６２は、当該Subscribeメッセージに含まれるイベント名が、イベント管理情報７１のフィールド“イベント”に格納されているレコード数を算出する。そして、追加部６２は、算出したレコード数が所定の数（例えば１００）だけ存在しているか否か判断する。そして、追加部６２は、レコード数が所定の数と一致していると判断した場合に、Subscribeメッセージの送信元のクライアントが、優先度テーブル７３で優先すべきクライアントであるか否か判断する。この優先すべきクライアントであるか否かは、例えば優先度テーブル７３で、優先度Highのクライアントを、優先すべきクライアントと判断する等が考えられる。そして、追加部６２は、優先すべきクライアントであると判断した場合に、イベント管理情報７１で優先すべきではないと判断されたクライアント（例えば優先度テーブル７３で優先度がLowと対応付けられているクライアント）が格納されているレコードを削除し、Subscribeメッセージの送信元のクライアントを通知先クライアントとしたレコードを追加する。
【００６６】
また、本実施の形態の変形例として、受信したメッセージの内容がテーブルに示した優先度の高い項目に該当する場合に、特定条件と判断してもよい。図１８（Ｂ）は、通知対象イベントの種類と優先度の関係を保持する優先度テーブルの一例を示す図である。この場合、Subscribeメッセージを受信して、イベント管理情報７１のレコード数が所定の数以上となった場合に、優先度が低いイベントのレコードが削除され、優先度が高いイベントのレコードが追加されることになる。
【００６７】
さらには、特定条件に該当するかどうかの確認処理においては、図１８（Ａ）または（Ｂ）のいずれか一つのテーブルのみを用いて判断するようにしてもよいし、双方を用いて判断するようにしてもよい。また、これらのテーブルは、メッセージ（Subscribe／Renew）の送信元の機器の種類や、画像処理装置の仕様や種類により異なる可能性がある。
【００６８】
図１７に戻り、上記ステップＳ６２において特定条件に該当しないと判断した場合（ステップＳ６２，Ｎｏ）、画像処理装置１はエラーレスポンス（図１１（Ａ）または（Ｂ）に例示したようなfaultメッセージ）を返信する（ステップＳ６３）。これに対して、特定条件に該当すると判断した場合（ステップＳ６２，Ｙｅｓ）、正常レスポンス（図６に例示したSubscribeResponseメッセージまたは図８に例示したRenewResponseメッセージ）を返信する（ステップＳ６４）。なお、ステップＳ６３，Ｓ６４の詳細動作については、図１２に基づいて上述したとおりである。
【００６９】
また、図１７で示した処理手順では、特定条件に該当するか否かのみでイベント管理情報７１に追加するか否か判断していたが、これにイベント管理情報７１で保持しているレコード数も考慮しても良い。そこで、特定条件とレコード数とを考慮した変形例について説明する。
【００７０】
図１９は、当該変形例にかかる画像処理装置１がSubscribeメッセージを受信した場合の動作例を示すフローチャートである。リクエスト受信部５１がSubscribeメッセージを受信すると（ステップＳ７１）、画像処理装置１のイベント管理部４３の追加部６２は、Subscribe登録済みのクライアント数が登録可能な最大数に達しているかどうかを確認する（ステップＳ７２）。図５に例示したSubscribeメッセージの説明において示したように、クライアントはSubscribeする対象のイベントを個別に指定できるため、Subscribe登録済みのクライアント数が登録可能な最大数に達しているイベントとそうでないイベントが混在している可能性がある。そのためステップＳ７２においては、Subscribeメッセージで指示されたイベントそれぞれについて、Subscribe登録済みのクライアント数が登録可能な最大数に達しているかどうかを確認する。ステップＳ７２の処理の結果、確認した全てのイベントについて、追加部６２がSubscribe登録済みのクライアント数が登録可能最大数に達していないと判断した場合（ステップＳ７２，Ｎｏ）、ＨＴＴＰ制御部４５が正常レスポンス（図６に例示したSubscribeResponseメッセージ）を返信する（ステップＳ７４）。一方、追加部６２がSubscribe登録済みのクライアント数が登録可能な最大数に達しているイベントが１つでも存在すると判断した場合には（ステップＳ７２，Ｙｅｓ）、受信したSubscribeメッセージの内容を確認し、特定条件に該当するかどうかを確認する（ステップＳ７３）。ここで、特定条件に該当するかどうかの確認処理は、上記図１６に示したステップＳ６２における確認処理と同様である。追加部６２が、ステップＳ７３において特定条件に該当しないと判断した場合（ステップＳ７３，Ｎｏ）、画像処理装置１のＨＴＴＰ制御部４５がエラーレスポンス（図１１（Ａ）に例示したようなfaultメッセージ）を返信する（ステップＳ７５）。これに対して、追加部６２が、特定条件に該当すると判断した場合（ステップＳ７３，Ｙｅｓ）、正常レスポンス（図６に例示したようなSubscribeResponseメッセージ）を返信する（ステップＳ７６）。
【００７１】
リクエスト受信部５１が優先度の高いクライアントからSuscribeメッセージを受信した場合、追加部６２が、優先度の低いSubscribe登録済みのクライアントを選択してその登録を抹消し、ＨＴＴＰ制御部４５が、当該クライアントに対してSbscriptionEndメッセージを送信する（ステップＳ７７）、すなわち、追加部６２が、Subscribe登録済みのクライアント数が登録可能な最大数に達しているイベントに関して、選択した登録済みの情報に代えて上記ステップＳ７１において受信したSubscribeメッセージの内容を新しい情報として登録する。なお、上記登録可能最大数はSubscribe登録するイベント（監視対象として登録するイベント）の種類に応じて異なる値としてもよい。
【００７２】
また、優先度の高いイベントの監視を要求するSuscribeメッセージを受信した場合には、Subscribe登録済みのクライアント数が登録可能最大数に達しているイベントのSubscribe登録済みのクライアントの中から、優先度の低いクライアントを選択し、選択したクライアントに代えて上記ステップＳ７１において受信したSubscribeメッセージの送信元クライアントを新たにSubscribe登録する。
【００７３】
図２０は、画像処理装置１においてイベントが発生した場合の動作例を示すフローチャートである。イベントの発生を検出すると、イベント管理部４３は、それを通知するためのメッセージの宛先としてSubscribe登録済みのクライアントの中から選択する（ステップＳ８１）。そして、イベント通知部５２が、上記図１４に示したステップＳ３６〜Ｓ３９の処理を実行することにより発生したイベントの内容を通知するためのメッセージ（イベント通知メッセージ）をステップＳ８１で選択した宛先（クライアント）に対して送信する（ステップＳ８２）。そして、イベント通知部５２が、指定時間内にメッセージの宛先から応答が返ってきたかどうかを確認する（ステップＳ８３）。指定時間内に応答がなかった場合（ステップＳ８３，Ｎｏ）、イベント通知部５２が、上記ステップＳ８２において送信したメッセージのあて先を送信失敗あて先に登録する（ステップＳ８４）。このとき、必要に応じて、イベント管理部からそのイベント情報を削除する。なお、指定時間の設定手法については後述する。
【００７４】
これに対して、指定時間内に応答があった場合（ステップＳ８３，Ｙｅｓ）、イベント通知部５２が、上記イベント通知メッセージの送信先がまだ残っているかどうか（Subscribe登録済みの全てのクライアントに対してイベント通知メッセージを送信したかどうか）を確認する（ステップＳ８５）。送信先が残っていない（Subscribe登録済みの全てのクライアントに対してイベント通知メッセージを送信した）ことを確認した場合（ステップＳ８５，Ｎｏ）、処理を終了する。イベント通知部５２が、送信先が残っていることを確認した場合（ステップＳ８５，Ｙｅｓ）、上記ステップＳ８１に遷移して、上述したステップＳ８１〜Ｓ８５に示した処理を継続する。
【００７５】
図２１は、上記イベントが発生した場合の動作例を時系列に示した図である。また、上記ステップＳ８３の処理においては、Subscribeの登録個数（Subscribe登録済みのクライアント数）に基づいてメッセージの宛先からの応答を待つ時間（上記指定時間に相当）を変更する。たとえば、図２２に示したようなテーブルを予め準備して記憶部１６に保持しておき、Subscribeの登録個数が１００個以下であれば、応答待ち時間を４秒とする。これにより、全てのSubscribe登録済みのクライアントに対するイベント通知処理を特定の時間内において終了することが可能となる。なお、図２２に示した応答待ち時間は、１クライアントに対する監視結果通知処理に必要とする時間に基づいて決定する。
【００７６】
このように、本実施の形態においては、イベント発生時の通知相手先（イベント通知先）となるクライアントの数（Subscribe登録済みのクライアント数）に応じて、イベントの検出間隔を変化させるようにした。これにより、イベント発生を検出した場合には、全てのイベント通知先に対して、最新の情報（発生イベント）を正しく通知することができる。
【００７７】
また、受け付けるイベント監視リクエスト（Subscribeメッセージ）の種類により、優先度を設定して、イベントの検出間隔を変化させるようにしたので、イベント発生を検出した場合には、全てのイベント通知先に対して、発生イベントを正しくかつ効率的に通知することができる。
【００７８】
また、Subscribe登録済みのクライアント数に基づいて、すなわち、Subscribe登録済のクライアント数が、登録可能最大数に達しているかどうかを考慮して、新たなイベント監視リクエストや更新イベント監視リクエスト（Renewメッセージ）を処理するかどうか判断するようにしたので、一度登録されたイベント通知先に対して、発生イベントを確実に通知することができる。
【００７９】
また、Subscribe登録済のクライアント数が、登録可能最大数に達している場合であっても、優先度が高いなどの特定の相手（優先クライアント）からのイベント監視リクエストを受け付けた場合には、他の優先度がそれほど高くないSubscribe登録済のクライアントに関する登録を抹消し、優先クライアントをSubscribe登録することにしたので、優先度の高い相手に対して、発生イベントを確実に通知することができる。
【００８０】
また、Subscribe登録済のクライアント数が、登録可能最大数に達している場合であっても、優先度が高いなどの特定の種類のイベント監視リクエストを受け付けた場合には、他の優先度がそれほど高くないSubscribe登録済のクライアントに関する登録を抹消することにしたので、優先度の高いイベントが発生した場合にそれを確実に通知することができる。
【００８１】
また、Subscribe登録済のクライアント数に応じて、イベント通知に対するイベント通知先からの応答待ち時間を変化させるようにしたので、イベント通知をできるだけ多くのイベント通知先に対して行うことができる。
【００８２】
また、本実施の形態では、イベントを通知する画像処理装置１について説明したが、画像処理装置に制限するものではなく様々な装置に適用することができる。例えば、社内ネットワークを介して様々な装置と接続されているビジネスオフィス機器等にも適用する子ことができる。つまり、ネットワークを介してクライアントなどの装置と接続され、監視対象の状態が変化した場合に通知を行うことが可能な装置であればよい。
【００８３】
また、本実施の形態にかかる画像処理装置１においては、監視イベント数に応じて監視間隔が設定されるので、監視イベント数が多くなれば監視間隔を長くすることで、処理負担を軽減させることができる。
【００８４】
（第２の実施の形態）
上述した第１の実施の形態にかかる画像処理装置１においては、イベントを監視する監視制御の設定情報として、監視周期を設定する場合について説明した。しかしながら、監視制御の設定情報を監視周期に限るものではない。そこで、第２の実施形態では、監視制御の設定情報として、イベント通知を行う際の有効期限を設定する場合について説明する。
【００８５】
第２の実施の形態にかかる画像処理装置１は、上述した第１の実施の形態にかかる画像処理装置１とは、ネットワーク制御部２７とは処理が異なるネットワーク制御部２６０１に変更された構成を有している点で異なる。以下の説明では、上述した第１の実施の形態と同一の構成要素には同一の符号を付してその説明を省略している。
【００８６】
図２３は、本実施の形態にかかる画像処理装置１のイベント処理部の構成例およびアプリケーション部２１の構成例を示す図である。上述した第１の実施形態にかかるイベント処理部とは、ネットワーク制御部２６０１の他、記憶部１６に格納されているテーブルが異なる点とする。
【００８７】
記憶部１６は、イベント管理テーブル２６２１と、有効時間管理テーブル２６２２と、を備える。
【００８８】
図２４は、イベント管理テーブル２６２１のテーブル構造を示した図である。図２４に示すように、イベント管理テーブル２６２１は、管理番号と、通知先クライアント、イベント種類、SubscribeID、有効時間及び登録時間とを対応付けて記憶している。イベント管理テーブル２６２１のレコードは、クライアントからイベント通知要求に応じて登録される。そして、イベントが発生した場合、画像処理装置１は、当該イベント監視テーブルを参照して、通知先クライアントに、イベントの通知を行う。
【００８９】
管理番号は各レコードを示すシーケンシャルな番号とする。また、SubscribeIDは、Subscribeメッセージ毎に割り当てられるユニークなＩＤとする。登録時間は、当該レコードの登録や更新が行われた時間を保持する。そして、当該登録時間から有効時間だけ時間が経過すると、該当するレコードが削除される。なお、詳細な処理については後述する。
【００９０】
図２５は、有効時間管理テーブル２６２２のテーブル構造を示した図である。図２５に示すように、有効時間管理テーブル２６２２は、監視イベント数と、有効時間とを対応付けて記憶している。そして、本実施の形態にかかる画像処理装置１では、当該有効時間管理テーブル２６２２を用いて、上述したイベント管理テーブル２６２１の有効時間を設定する。
【００９１】
また、有効時間管理テーブル２６２２は、記憶部１６のＮＢＲＡＭ内に保存することが考えられる。また、当該有効時間管理テーブル２６２２は、書き換え可能な記憶部ではなくともよいし、当該処理を行うためにソフトウェア上ハードコーディングすることなども考えられる。
【００９２】
そして、画像処理装置１では、有効時間管理テーブル２６２２を参照し、イベント管理テーブル２６２１のレコードの登録、更新を行う際に適切な有効時間を設定する。
【００９３】
図２３に戻り、ネットワーク制御部２６０１は、第１の実施の形態にかかるネットワーク処理部２７とは、イベント管理部４３とは処理が異なるイベント管理部２６１１に変更され、WS-Discovery処理部２６１２が追加された点とする。
【００９４】
WS-Discovery処理部２６１２は、WS-Discoveryプロトコルを処理する。WS-Discoveryプロトコルで定義されているパケットとしては、ネットワーク離脱パケットByeがある。
【００９５】
つまり、本実施の形態にかかる画像処理装置１では、第１の実施形態の画像処理装置１が処理したSubscribeメッセージなどのWS-Eventingプロトコルのメッセージに加えて、ByeパケットなどのWS-Discoveryプロトコルで定義されているパケットについても処理する。
【００９６】
図２６は、WS-EventingプロトコルにおけるSubscribeのメッセージの一例を示した図である。クライアントは、このようなSubscribeメッセージを画像処理装置１に対して送信することで、イベントの通知を要求する。図２６に示すSubscribeメッセージは、行３００１でSubscribeメッセージであることが特定できる。また、行３００２には、有効時間が記載されている。さらに、行３００３は、イベント“PrinterStatusEvent”を監視対象として登録することを要求している。なお、イベント“PrinterStatusEvent”は、画像処理装置１の“PrinterStatus”が変化した場合に発生するイベントとする。つまり、画像処理装置１の“PrinterStatus”が変更した場合に、クライアントに対してイベント通知が行われる。
【００９７】
図２７は、WS-EventingプロトコルにおけるSubscribeResponseメッセージの一例を示した図である。行３１０１でSubscribeResponseメッセージであることが特定できる。また、行３１０２のExpiresタグで囲まれた“PT30M”がこのイベント監視の有効時間として、３０分を設定したことを示している。
【００９８】
また、図２７に示すSubscribeResponseメッセージは、図２６に示すSubscribeメッセージのレスポンスメッセージの第１の例である。当該SubscribeResponseメッセージは、図２６に示すSubscribeメッセージを通知したクライアントに対して画像処理装置１が送信する。具体的には、図２６で示すSubscribeメッセージで、有効時間として３０分要求したのに対して、図２７に示すSubscribeResponseメッセージで要求通り有効時間として３０分で設定した旨の応答を行っている。
【００９９】
図２８に示すSubscribeResponseメッセージは、図２６に示すSubscribeメッセージのレスポンスメッセージの第２の例である。当該レスポンスメッセージでは、行３２０１でSubscribeResponseメッセージであることが特定できる。また、行３２０２のExpiresタグで囲まれた“PT10M”がこのイベント監視の有効時間として、１０分を設定したことを示している。つまり、図２６で示すSubscribeメッセージで、有効時間として３０分要求したのに対して、図２８に示すSubscribeResponseメッセージでは、要求より少ない１０分が有効時間として設定された旨の応答を行っている。
【０１００】
このように本実施の形態にかかる画像処理装置１では、クライアントからイベント通知の要求があった場合、当該要求の有効時間を状況に応じて適切に設定する。この有効時間を設定するための状況としては、イベント数、イベント監視先、イベント種類等が考えられる。本実施の形態では、イベント数で有効時間を変更する場合について説明している。
【０１０１】
図２３に戻り、イベント管理部２６１１は、イベント監視部６１と、追加部６２と、更新部６３と、設定部２６３１とを備える。
【０１０２】
設定部２６３１は、イベント管理テーブル２６２１に記憶されているイベント数に基づいて、各イベントの監視する有効時間を設定する。
【０１０３】
次に、以上のように構成された本実施の形態にかかる画像処理装置１におけるメッセージを受信した場合の処理について説明する。図２９は、本実施の形態にかかる画像処理装置１における上述した処理の手順を示すフローチャートである。
【０１０４】
まず、リクエスト受信部５１が、クライアントからのSubscribeリクエスト又はRenewリクエストを受信する（ステップＳ３３０１）。
【０１０５】
そして、設定部２６３１は、有効時間管理テーブル２６２２を参照して、有効時間を設定する（ステップＳ３３０２）。本実施の形態では、設定部２６３１は、受信したリクエストの数と、イベント管理テーブルで有効期限が経過していないレコードとの和を監視対象であるイベント数として算出し、算出されたイベント数と有効時間管理テーブル２６２２を参照して、有効時間を設定する。
【０１０６】
また、設定部２６３１は、監視イベント数が１−５０であればSubscribeメッセージ又はRenewメッセージで要求された有効時間を、実際の有効時間と設定する。監視イベント数が、５１−１００であれば有効時間を３０分と設定する。監視イベント数が、１０１−１００であれば有効時間を２０分と設定する。監視イベント数が、２０１以上であれば有効時間を１０分と設定する。さらに、Subscribeメッセージ又はRenewメッセージで有効時間を要求されなかった場合、有効時間を１０分と設定する。
【０１０７】
このようにして設定された各レコードは、有効時間が経過すると、イベント管理テーブル２６２１から削除される。しかしながら、有効時間が経過する前にクライアントからRenewリクエストを受信した場合は、当該レコードは削除されず、新たな有効時間が設定される。この有効時間を設定する際に監視イベント数が変化していれば、その数にしたがって新しい有効時間が設定される。このように、以前のSubscribeリクエストやRenewリクエストの時の有効時間とは異なる有効時間が設定される場合がある。
【０１０８】
つまり、設定部２６３１は、イベント管理テーブル２６２１を参照して、監視イベント数が１〜５０であればクライアントが要求した有効時間通りに設定し、それ以上の監視イベント数であれば、監視イベント数が多くなるに従って有効時間を短く設定する。これにより、画像処理装置１の監視負担を軽減することができる。
【０１０９】
そして、設定部２６３１は、設定された有効時間と共に、クライアントから監視を要求されたイベントに関する情報対応付けて、イベント管理テーブル２６２１に登録／更新する。なお、Subscribeリクエストを受信した場合にレコードの登録を行い、Renewリクエストを受信した場合にレコードの更新を行うこととする。なお、本実施の形態では、設定部２６３１の有効時間の設定は新たに登録／更新したレコードに対して飲み行うが、イベント管理テーブル２６２１の全てのレコードに対して有効期限の再設定を行ってもよい。
【０１１０】
次に、設定部２６３１は、Subscribeリクエスト又はRenewリクエストを送信してきたクライアントに対して、Subscribe／Renewレスポンスメッセージを送信する（ステップＳ３３０４）。
【０１１１】
上述した処理手順により、Subscribeリクエスト又はRenewリクエストを受信した場合に、イベント監視数に応じて適切な有効時間の設定することが可能となる。
【０１１２】
なお、本実施の形態とは異なるが、イベント種類や、リクエスト送信元のクライアントに応じて有効時間を設定しても良い。そこで、変形例として、イベント種類に従って有効時間を設定する場合について説明する。図３０は、変形例１にかかる有効時間管理テーブルのテーブル構造を示した図である。図３０（Ａ）に示すように、有効時間管理テーブルでは、イベント種類と、有効時間とが対応付けられている。これにより、図２９のステップＳ３３０２において、設定部は、当該有効時間管理テーブルを参照し、Subscribeリクエスト又はRenewリクエストで監視を要求するイベントを表すイベント種類と対応付けられた有効時間の設定を行う。また、本変形例にかかる有効時間管理テーブルにおいては、重要なイベント種類ほど長い有効時間が設定されている。これにより、重要なイベントがクライアントに通知される可能性が向上する。なお、他の処理は第１の実施形態と同様とする。
【０１１３】
さらに他の変形例として、リクエスト送信元のクライアントに応じて有効時間を設定する場合について説明する。図３０（Ｂ）は、変形例２にかかる有効時間管理テーブルのテーブル構造を示した図である。図３０（Ｂ）に示すように、有効時間管理テーブルでは、クライアントを識別するＩＰアドレスと、有効時間とが対応付けられている。また、有効時間管理テーブルにおいては、重要なイベント種類ほど長い有効時間が設定されている。また、本変形例にかかる有効時間管理テーブルにおいては、クライアントほど長い有効時間が設定されている。これにより、図２９のステップＳ３３０２において、設定部は、当該有効時間管理テーブルを参照し、Subscribeリクエスト又はRenewリクエストで監視を要求してきたクライアントに応じて、有効時間の設定を行う。また、本変形例にかかる有効時間管理テーブルにおいては、重要なクライアントほど長い有効時間が設定されている。なお、他の処理は第１の実施形態と同様とする。
【０１１４】
上述した変形例のように、利用者の実施する環境に応じて適切な有効時間管理テーブルを使用して良い。また、上述した実施の形態及び変形例で説明した全ての有効時間管理テーブルを予め画像処理装置に格納して、管理者が適切な有効時間管理テーブルを使用するように設定しても良い。この設定手法としては、画像処理装置に備え付けられているオペレーションパネルからネットワーク制御部に対して設定してもよいし、ネットワーク制御部を通じて外部から設定されたりする。
【０１１５】
また、本実施の形態にかかる画像処理装置１においては、イベント管理テーブル２６２１からレコードを削除するのは、有効期間を経過した場合に限るものではない。例えば、画像処理装置１は、クライアントがネットワークから離脱した場合にも、イベント管理テーブル２６２１からレコードを削除する。
【０１１６】
次に、本実施の形態にかかる画像処理装置１におけるネットワーク離脱パケット受信処理について説明する。図３１は、本実施の形態にかかる画像処理装置１における上述した処理の手順を示すフローチャートである。
【０１１７】
まず、本実施の形態にかかる画像処理装置１のＨＴＴＰ制御部４５は、Ｉ／Ｆ部１７を介して、パケットの受信を受け付ける（ステップＳ３６０１）。
【０１１８】
次に、ＨＴＴＰ制御部４５は、WS-Discoveryプロトコルによるパケットを受信したか否か判断する（ステップＳ３６０２）。WS-Discoveryプロトコル以外のパケットを受信した場合（ステップＳ３６０２：Ｎｏ）、WS-Discovery処理部２６１２以外の構成が処理を行ったあと、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１１９】
そして、WS-Discoveryプロトコルによるパケットを受信した場合（ステップＳ３６０２：Ｙｅｓ）、WS-Discovery処理部２６１２が、当該パケットが、クライアントからのネットワーク離脱パケットか判断する（ステップＳ３６０３）。ネットワーク離脱パケットではないと判断した場合（ステップＳ３６０３：Ｎｏ）、判断したパケットに応じて適切な処理を行った後、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１２０】
図３２は、ネットワーク離脱パケットの一例を示した図である。図３２の行３７０１を確認すると、“Bye”と記載されているためにネットワーク離脱パケットと判断できる。
【０１２１】
図３１に戻り、WS-Discovery処理部２６１２が、ネットワーク離脱パケットと判断した場合（ステップＳ３６０３：Ｙｅｓ）、その旨を、ネットワークを離脱したクライアントを示すＩＰアドレスと共にイベント管理部２６１１に通知する。
【０１２２】
そして、イベント管理部２６１１が、イベント管理テーブル２６２１で、通知されたＩＰアドレスが通知先クライアントとして登録されたレコードが存在するか否か判断する（ステップＳ３６０４）。無いと判断した場合（ステップＳ３６０４：Ｎｏ）、特に処理を行わず、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１２３】
また、イベント管理部２６１１は、当該レコードが存在すると判断した場合（ステップＳ３６０４：Ｙｅｓ）、イベント管理テーブル２６２１から、当該レコードを削除する処理を行う（ステップＳ３６０５）。これにより、ネットワーク離脱されたクライアントからのイベント監視要求が削除されたことになる。その後、再びパケットの受信の受付から開始する（ステップＳ３６０１）。
【０１２４】
上述した処理によりネットワーク離脱したクライアントからのイベント通知要求が削除される。
【０１２５】
次に、画像処理装置１において、ネットワーク離脱パケットを受信した場合について説明する。図３３は、画像処理装置１において、ネットワーク離脱パケットを受信した場合のシーケンス図である。
【０１２６】
まずは、ＨＴＴＰ制御部４５は、クライアント（Subscriber）から、ネットワーク離脱パケット（Bye）を受信する（ステップＳ３８０１）。
【０１２７】
当該ネットワーク離脱パケットは、WS-Discoveryプロトコルで記載されているので、WS-Discovery処理部２６１２に受信したパケットを通知する（ステップＳ３８０２）。
【０１２８】
そして、WS-Discovery処理部２６１２は、ＨＴＴＰ制御部４５から渡されたパケットをさらにＳＯＡＰ／ＸＭＬ処理部２３に渡してその内容を解析させる（ステップＳ３８０３）。ＳＯＡＰ／ＸＭＬ処理部２３はステップＳ３８０３において受け取ったメッセージの内容解析結果をWS-Discovery処理部２６１２に対して返信する（ステップＳ３８０４）。
【０１２９】
つぎに、WS-Discovery処理部２６１２は、受け取った内容解析結果から、所定のクライアントのネットワーク離脱が発生したことを認識し、イベント管理部２６１１に対して、ネットワークを離脱したクライアントしたことを通知する（ステップＳ３８０５）。これにより、ネットワークを離脱したクライアントからのイベント監視が格納されているレコードをイベント管理テーブル２６２１から削除できる。
【０１３０】
本実施の形態にかかる画像処理装置１では、当該リクエストを出したクライアントに対してイベントを通知する有効時間を状況に応じて変化させることで、画像処理装置１の処理負担を軽減させることができる。
【０１３１】
また、有効時間管理テーブルで有効時間を管理し、受け付けたリクエストに応じて有効時間を変更させることで、画像処理装置１に自由度を持たせることができる。また、有効時間管理テーブルに格納されているデータを利用者に変更可能とすることで、カスタマイズ性を向上させることができる。
【０１３２】
また、上述した実施の形態にかかる画像処理装置１、２６００で実行されるイベント通知プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、上述した実施の形態にかかる画像処理装置１、２６００で実行されるイベント通知プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。
【０１３３】
また、上述した実施の形態にかかる画像処理装置１、２６００のイベント通知プログラムを、ＲＯＭ等に予め組みこまれて提供される。
【０１３４】
上述した実施の形態にかかる画像処理装置１、２６００で実行されるイベント通知プログラムは、上述した各部（システム制御部２４、メモリ制御部２５、配信制御部２６、ネットワーク制御部２７、ＯＳ／Ｋｅｒｎｅｌ２８）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵが上記記録媒体からイベント通知プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、システム制御部２４、メモリ制御部２５、配信制御部２６、ネットワーク制御部２７、ＯＳ／Ｋｅｒｎｅｌ２８が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１３５】
以上のように、本発明にかかるイベント通知装置、イベント通知方法及びイベント通知プログラムは、他の装置に対してイベントを通知する技術に有用であり、特に、イベント通知を行う際に処理負担を軽減させる技術に適している。
【図面の簡単な説明】
【０１３６】
【図１】第１の実施の形態にかかる画像処理装置およびネットワークを介して画像処理装置を利用する装置により構成されるシステムの一例を示す図である。
【図２】第１の実施の形態にかかる画像処理装置のハードウェア構成例を示す図である。
【図３】第１の実施の形態にかかる画像処理装置のソフトウェア構成例を示す図である。
【図４】第１の実施の形態にかかる画像処理装置の特徴的な処理を実現するためのイベント通知部およびアプリケーション部の構成例を示す図である。
【図５】Subscribeメッセージの一例を示す図である。
【図６】SubscribeResponseメッセージの一例を示す図である。
【図７】Renewメッセージの一例を示す図である。
【図８】RenewResponseメッセージの一例を示す図である。
【図９】SubscriptionEndメッセージの一例を示す図である。
【図１０】StatusEventReportメッセージの一例を示す図である。
【図１１】faultメッセージの一例を示す図である。
【図１２】画像処理装置がSubscribeメッセージまたはRenewメッセージを受信するシーケンス例を示す図である。
【図１３】第１の実施形態にかかるイベント管理情報のテーブル構造を示した図である。
【図１４】イベント発生監視動作およびイベント通知動作のシーケンス例を示す図である。
【図１５】画像処理装置がイベント監視動作時に使用する情報の一例を示す図である。
【図１６】画像処理装置がSubscriptionEndメッセージを送出する場合のシーケンス例を示す図である。
【図１７】画像処理装置がSubscribeメッセージ／Renewメッセージを受信した場合の動作例を示すフローチャートである。
【図１８】画像処理装置がSubscribeメッセージ／Renewメッセージ受信時の動作において使用する情報の一例を示す図である。
【図１９】画像処理装置がSubscribeメッセージを受信した場合の動作例を示すフローチャートである。
【図２０】画像処理装置においてイベントが発生した場合の動作例を示すフローチャートである。
【図２１】画像処理装置においてイベントが発生した場合の動作例を時系列に示した図である。
【図２２】画像処理装置がイベント通知動作において使用する情報の一例を示す図である。
【図２３】第２の実施の形態にかかる画像処理装置のイベント通知部およびアプリケーション部の構成例を示す図である。
【図２４】第２の実施の形態にかかるイベント管理テーブルのテーブル構造を示した図である。
【図２５】第２の実施の形態にかかる有効時間管理テーブルのテーブル構造を示した図である。
【図２６】WS-EventingプロトコルにおけるSubscribeのメッセージの一例を示した図である。
【図２７】第２の実施の形態にかかるSubscribeResponseメッセージの第１の例を示した図である。
【図２８】第２の実施の形態にかかるSubscribeResponseメッセージの第２の例を示した図である。
【図２９】第２の実施の形態にかかる画像処理装置におけるメッセージを受信した場合の処理の手順を示すフローチャートである。
【図３０】第２の実施の形態の変形例にかかる有効時間管理テーブルのテーブル構造を示した図である。
【図３１】第２の実施の形態にかかる画像処理装置におけるネットワーク離脱パケット受信処理の手順を示すフローチャートである。
【図３２】ネットワーク離脱パケットの一例を示した図である。
【図３３】第２の実施の形態にかかる画像処理装置において、ネットワーク離脱パケットを受信した場合のシーケンス図である。
【図３４】課題を説明するための図である。
【符号の説明】
【０１３７】
１ 画像処理装置
１１ ＣＰＵ
１２ システムメモリ
１３ ノースブリッジ（ＮＢ）
１４ サウスブリッジ（ＳＢ）
１５ ＡＳＩＣ
１６ 記憶部
１７ Ｉ／Ｆ部
２１ アプリケーション部
２２ プラットフォーム部
２３ ＳＯＡＰ／ＸＭＬ処理部
２４ システム制御部
２５ メモリ制御部
２６ 配信制御部
２７、２６０１ ネットワーク制御部
２８ ＯＳ／Ｋｅｒｎｅｌ
３１ アプリケーション制御部
３２ イベント検出部
３３ 情報通信部
４１ 全体制御部
４２ WS-Eventing処理部
４３、２６１１ イベント管理部
４４ アプリ通信部
４５ ＨＴＴＰ制御部
４６ プロトコル制御部
５１ リクエスト受信部
５２ イベント通知部
６１ イベント監視部
６２ 追加部
６３ 更新部
６４、２６３１ 設定部
７１ イベント管理情報
７２ 監視間隔テーブル
７３ 優先度テーブル
２６１２ WS-Discovery処理部
２６２１ イベント管理テーブル
２６２２ 有効時間管理テーブル
【特許請求の範囲】
【請求項１】
クライアント装置とネットワークを介して接続されたイベント通知装置であって、
イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けて記憶するイベント情報記憶手段と、
各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信手段と、
前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加手段と、
前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定手段と、
それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視手段と、
前記イベント監視手段がイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知手段と、
を備えることを特徴とするイベント通知装置。
【請求項２】
前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、
前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、
を特徴とする請求項１に記載のイベント通知装置。
【請求項３】
前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報に基づいてイベント毎の監視周期を決定する場合、前記イベント情報記憶手段で、前記イベント種類毎に対応付けられた前記通知先クライアント情報の数を確認し、任意の前記イベント種類で他の前記イベント種類より前記通知先クライアント情報の数が多い場合、当該任意の前記イベント種類を、他の前記イベント種類より長い監視間隔に設定すること、
を特徴とする請求項２に記載のイベント通知装置。
【請求項４】
前記追加手段は、前記監視イベント指定メッセージを受信した場合、前記イベント情報記憶手段に記憶されている前記イベント種類又は前記イベント通知先クライアント情報と、に基づいて、監視イベント指定メッセージに含まれている前記イベント種類と、当該監視イベント指定メッセージの送信元のクライアント装置を示すクライアント情報と、を対応付けて前記イベント情報記憶手段に追加するか否か判断することを特徴とする請求項２又は３に記載のイベント通知装置。
【請求項５】
前記追加手段は、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージに含まれている前記イベント種類と前記イベント情報記憶手段で対応付けられたイベント通知先クライアント情報の数が、所定の数と一致しているか否か判断し、当該所定の数と一致していると判断した場合に、前記イベント情報記憶手段に追加を行わないこと、
を特徴とする請求項４に記載のイベント通知装置。
【請求項６】
イベントの通知する優先すべきクライアント装置を示す優先クライアント情報を記憶する優先度記憶手段と、
前記追加手段は、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージに含まれている前記イベント種類と前記イベント情報記憶手段で対応付けられたイベント通知先クライアント情報の数が、所定の数と一致しているか否か判断し、当該所定の数と一致していると判断した場合に、前記監視イベント指定メッセージの送信元のクライアント装置が、前記優先クライアント情報から優先すべきクライアント装置であるか否か判断し、優先すべきクライアントであると判断された場合に、前記優先クライアント情報から優先すべきではないと判断されたクライアント装置を示す前記イベント通知先クライアント情報を削除し、前記監視イベント指定メッセージの送信元のクライアント装置を示すイベント通知先クライアント情報を追加すること、
を特徴とする請求項２乃至５のいずれか一つに記載のイベント通知装置。
【請求項７】
前記イベント通知手段は、前記クライアント装置に対して、当該発生したイベントを通知した後、当該クライアント装置から通知されたイベントに対する応答メッセージを受信したか否かを監視し、当該応答メッセージを受信した場合、又は発生した前記イベントと前記イベント情報記憶手段で対応付けられている前記イベント通知先クライアント情報の数に基づいて決定した指定時間が経過した場合、発生した前記イベントの通知先であるクライアント装置であって、前記イベントを通知していないクライアント装置に対してイベントを通知し、以降、前記イベントの通知先全てのクライアント装置に対してイベントを通知するまで、当該通知処理を継続すること、
を特徴とする請求項２乃至６のいずれか一つに記載のイベント通知装置。
【請求項８】
前記イベント情報記憶手段は、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて記憶し、
前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、
前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記有効時間内に限り行うこと、
を特徴とする請求項１に記載のイベント通知装置。
【請求項９】
前記設定手段は、前記イベント情報記憶手段に追加された前記通知先クライアント情報の数に基づいて、前記イベント種類の前記有効時間を設定すること、
を特徴とする請求項８に記載のイベント通知装置。
【請求項１０】
前記クライアント装置と、当該クライアント装置でイベントの通知を優先すべき優先度とを対応付けて記憶する優先度記憶手段と、
前記設定手段は、前記イベント情報記憶手段に追加された前記通知先クライアント情報が示すクライアント装置と、前記優先度記憶手段で対応付けられている前記優先度に基づいて、前記イベント種類の前記有効時間を設定すること、
を特徴とする請求項８に記載のイベント通知装置。
【請求項１１】
前記イベント種類と、当該イベント種類の場合の通知する時間間隔を示すイベント有効時間とを対応付けて記憶する有効時間記憶手段と、
前記設定手段は、前記イベント情報記憶手段に追加された前記通知先クライアント情報と対応付けられている前記イベント種類と、前記有効時間記憶手段で対応付けられている前記イベント有効時間で、追加された前記通知先クライアント情報と対応付けられている前記有効時間を設定すること、
を特徴とする請求項８に記載のイベント通知装置。
【請求項１２】
前記受信手段は、各前記クライアント装置から、前記有効時間が指定可能な前記監視イベント指定メッセージを受信し、
前記設定手段は、受信した前記監視イベント指定メッセージに、前記有効時間が指定されている場合に指定された前記有効時間を設定し、前記有効時間が指定されていない場合に前記イベント情報記憶手段に追加された前記通知先クライアント情報の数に基づいて、前記有効時間を設定すること、
を特徴とする請求項８乃至１１のいずれか一つに記載のイベント通知装置。
【請求項１３】
前記イベント通知手段は、WS-Eventingプロトコルを使用して、前記イベントの通知を行うことを特徴とする請求項１乃至１２のいずれか一つに記載のイベント通知装置。
【請求項１４】
ネットワークを介して接続されたクライアント装置に対してイベントを通知するイベント通知方法であって、
イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、
各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、
前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、
前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、
それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、
前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、
を有することを特徴とするイベント通知方法。
【請求項１５】
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、
を特徴とする請求項１４に記載のイベント通知方法。
【請求項１６】
前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、
を特徴とする請求項１４に記載のイベント通知方法。
【請求項１７】
ネットワークを介して接続されたクライアント装置に対してイベントを通知させることをコンピュータに実行させるイベント通知プログラムであって、
イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、
各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、
前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、
前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、
それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、
前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、
をコンピュータに実行させることを特徴とするイベント通知プログラム。
【請求項１８】
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、
を特徴とする請求項１７に記載のイベント通知プログラム。
【請求項１９】
前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、
を特徴とする請求項１７に記載のイベント通知プログラム。
【請求項１】
クライアント装置とネットワークを介して接続されたイベント通知装置であって、
イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けて記憶するイベント情報記憶手段と、
各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信手段と、
前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加手段と、
前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定手段と、
それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視手段と、
前記イベント監視手段がイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知手段と、
を備えることを特徴とするイベント通知装置。
【請求項２】
前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、
前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、
を特徴とする請求項１に記載のイベント通知装置。
【請求項３】
前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報に基づいてイベント毎の監視周期を決定する場合、前記イベント情報記憶手段で、前記イベント種類毎に対応付けられた前記通知先クライアント情報の数を確認し、任意の前記イベント種類で他の前記イベント種類より前記通知先クライアント情報の数が多い場合、当該任意の前記イベント種類を、他の前記イベント種類より長い監視間隔に設定すること、
を特徴とする請求項２に記載のイベント通知装置。
【請求項４】
前記追加手段は、前記監視イベント指定メッセージを受信した場合、前記イベント情報記憶手段に記憶されている前記イベント種類又は前記イベント通知先クライアント情報と、に基づいて、監視イベント指定メッセージに含まれている前記イベント種類と、当該監視イベント指定メッセージの送信元のクライアント装置を示すクライアント情報と、を対応付けて前記イベント情報記憶手段に追加するか否か判断することを特徴とする請求項２又は３に記載のイベント通知装置。
【請求項５】
前記追加手段は、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージに含まれている前記イベント種類と前記イベント情報記憶手段で対応付けられたイベント通知先クライアント情報の数が、所定の数と一致しているか否か判断し、当該所定の数と一致していると判断した場合に、前記イベント情報記憶手段に追加を行わないこと、
を特徴とする請求項４に記載のイベント通知装置。
【請求項６】
イベントの通知する優先すべきクライアント装置を示す優先クライアント情報を記憶する優先度記憶手段と、
前記追加手段は、前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージに含まれている前記イベント種類と前記イベント情報記憶手段で対応付けられたイベント通知先クライアント情報の数が、所定の数と一致しているか否か判断し、当該所定の数と一致していると判断した場合に、前記監視イベント指定メッセージの送信元のクライアント装置が、前記優先クライアント情報から優先すべきクライアント装置であるか否か判断し、優先すべきクライアントであると判断された場合に、前記優先クライアント情報から優先すべきではないと判断されたクライアント装置を示す前記イベント通知先クライアント情報を削除し、前記監視イベント指定メッセージの送信元のクライアント装置を示すイベント通知先クライアント情報を追加すること、
を特徴とする請求項２乃至５のいずれか一つに記載のイベント通知装置。
【請求項７】
前記イベント通知手段は、前記クライアント装置に対して、当該発生したイベントを通知した後、当該クライアント装置から通知されたイベントに対する応答メッセージを受信したか否かを監視し、当該応答メッセージを受信した場合、又は発生した前記イベントと前記イベント情報記憶手段で対応付けられている前記イベント通知先クライアント情報の数に基づいて決定した指定時間が経過した場合、発生した前記イベントの通知先であるクライアント装置であって、前記イベントを通知していないクライアント装置に対してイベントを通知し、以降、前記イベントの通知先全てのクライアント装置に対してイベントを通知するまで、当該通知処理を継続すること、
を特徴とする請求項２乃至６のいずれか一つに記載のイベント通知装置。
【請求項８】
前記イベント情報記憶手段は、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて記憶し、
前記設定手段は、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、
前記イベント監視手段は、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記有効時間内に限り行うこと、
を特徴とする請求項１に記載のイベント通知装置。
【請求項９】
前記設定手段は、前記イベント情報記憶手段に追加された前記通知先クライアント情報の数に基づいて、前記イベント種類の前記有効時間を設定すること、
を特徴とする請求項８に記載のイベント通知装置。
【請求項１０】
前記クライアント装置と、当該クライアント装置でイベントの通知を優先すべき優先度とを対応付けて記憶する優先度記憶手段と、
前記設定手段は、前記イベント情報記憶手段に追加された前記通知先クライアント情報が示すクライアント装置と、前記優先度記憶手段で対応付けられている前記優先度に基づいて、前記イベント種類の前記有効時間を設定すること、
を特徴とする請求項８に記載のイベント通知装置。
【請求項１１】
前記イベント種類と、当該イベント種類の場合の通知する時間間隔を示すイベント有効時間とを対応付けて記憶する有効時間記憶手段と、
前記設定手段は、前記イベント情報記憶手段に追加された前記通知先クライアント情報と対応付けられている前記イベント種類と、前記有効時間記憶手段で対応付けられている前記イベント有効時間で、追加された前記通知先クライアント情報と対応付けられている前記有効時間を設定すること、
を特徴とする請求項８に記載のイベント通知装置。
【請求項１２】
前記受信手段は、各前記クライアント装置から、前記有効時間が指定可能な前記監視イベント指定メッセージを受信し、
前記設定手段は、受信した前記監視イベント指定メッセージに、前記有効時間が指定されている場合に指定された前記有効時間を設定し、前記有効時間が指定されていない場合に前記イベント情報記憶手段に追加された前記通知先クライアント情報の数に基づいて、前記有効時間を設定すること、
を特徴とする請求項８乃至１１のいずれか一つに記載のイベント通知装置。
【請求項１３】
前記イベント通知手段は、WS-Eventingプロトコルを使用して、前記イベントの通知を行うことを特徴とする請求項１乃至１２のいずれか一つに記載のイベント通知装置。
【請求項１４】
ネットワークを介して接続されたクライアント装置に対してイベントを通知するイベント通知方法であって、
イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、
各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、
前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、
前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、
それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、
前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、
を有することを特徴とするイベント通知方法。
【請求項１５】
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、
を特徴とする請求項１４に記載のイベント通知方法。
【請求項１６】
前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、
を特徴とする請求項１４に記載のイベント通知方法。
【請求項１７】
ネットワークを介して接続されたクライアント装置に対してイベントを通知させることをコンピュータに実行させるイベント通知プログラムであって、
イベント種類と、当該イベント種類で示されるイベントが発生した場合に当該イベントの内容の通知先となるクライアント装置を示すイベント通知先クライアント情報と、を対応付けてイベント情報記憶手段に記憶するイベント情報記憶ステップと、
各前記クライアント装置から、監視を要求するイベント種類を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、
前記監視イベント指定メッセージを受信した場合、当該監視イベント指定メッセージの送信元のクライアント装置を前記イベント通知先クライアント情報として、当該監視イベント指定メッセージに含まれている前記イベント種類と、対応付けて前記イベント情報記憶手段に追加する追加ステップと、
前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、イベントの所定の監視制御に用いる設定情報を設定する設定ステップと、
それぞれのイベントが発生したか否かの監視に、前記設定情報を使用して前記所定の監視制御を行うイベント監視ステップと、
前記イベント監視ステップがイベント発生を検出した場合、発生したイベントを示す前記イベント種類と前記イベント情報記憶手段で対応付けられた前記イベント通知先クライアント情報で示された前記クライアント装置に対して、当該発生したイベントを通知するイベント通知ステップと、
をコンピュータに実行させることを特徴とするイベント通知プログラム。
【請求項１８】
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記設定情報である、イベント種類毎の監視周期を設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記監視周期で行うこと、
を特徴とする請求項１７に記載のイベント通知プログラム。
【請求項１９】
前記イベント情報記憶ステップは、さらに、クライアント装置に当該イベントを通知する時間間隔を示す有効時間を対応付けて前記イベント情報記憶手段に記憶し、
前記設定ステップは、前記イベント情報記憶手段が記憶している前記イベント通知先クライアント情報および前記イベント種類のいずれか一つ以上に基づいて、前記有効時間を、前記監視制御の設定情報として設定し、
前記イベント監視ステップは、前記イベント種類毎のイベントが発生したか否かの監視を、設定された前記イベント有効時間内に限り行うこと、
を特徴とする請求項１７に記載のイベント通知プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【公開番号】特開２００８−９７５８２（Ｐ２００８−９７５８２Ａ）
【公開日】平成２０年４月２４日（２００８．４．２４）
【国際特許分類】
【出願番号】特願２００７−１９２９４３（Ｐ２００７−１９２９４３）
【出願日】平成１９年７月２５日（２００７．７．２５）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２０年４月２４日（２００８．４．２４）
【国際特許分類】
【出願日】平成１９年７月２５日（２００７．７．２５）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]