JP4987770B2 - イベント通知装置、イベント通知方法、及びイベント通知プログラム - Google Patents

Description

本発明は、ネットワークなどを介して接続された他の機器に対してイベントを通知するイベント通知装置、イベント通知方法、及びイベント通知プログラムに関するに関するものである。

近年、インターネットやイントラネットなどのネットワークに接続する機能を備え、ネットワークを介して他の機器（ユーザ）からの操作指示などを受け付けるプリンタなどの画像処理装置（ネットワーク対応の画像処理装置）が普及してきている。このような画像処理装置は、イベントが発生した場合、自装置を利用するユーザに対して発生したイベントの内容を通知する。各ユーザは、イベントの内容（画像処理装置の状態）を把握し、必要に応じてその内容に従った動作を実行する。

このように、画像処理装置で発生したイベントを多数の機器に対して通知する場合、機器数が多いほど、通知を行うための処理及び負担が大きくなる。

そこで、特許文献１に記載された技術では、イベントをマルチキャストで通知することで、それぞれユニキャストで通知する場合と比べて、処理負担を軽減している。

特開２００７−２６４３９号公報

しかしながら、特許文献１に記載された技術は、通知先の機器が当該イベントを欲しているか否かに係わらず、マルチキャストでイベントを通知している。つまり、特許文献１に記載された技術は、通知先の機器において、不要なイベントの処理のための処理負担が増加するという問題が生じる。

本発明は、上記に鑑みてなされたものであって、通知負担及び通知先の機器側の処理負担を軽減させるイベント通知装置、イベント通知方法、及びイベント通知プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、クライアント装置とネットワークを介して接続されたイベント通知装置であって、各前記クライアント装置から、監視を要求するイベント種別を含むメッセージである監視イベント指定メッセージを受信する受信手段と、自装置においてイベントが発生したか否かを監視するイベント監視手段と、イベント種別と、当該イベント種別で示されたイベントが発生した場合にクライアント装置に対して通知する通知手法と、を対応付けて記憶する通知管理記憶手段と、前記イベント監視手段が前記イベントの発生を検出した際、発生したイベント種別が前記監視イベント指定メッセージで複数の前記クライアント装置から監視を要求されていた場合に、当該複数のクライアントに対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてマルチキャストと対応付けられている場合に、ネットワークを介して接続された複数のクライアント装置に対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてユニキャストと対応付けられている場合に、当該イベントを監視する所定のクライアント装置にユニキャストで通知するイベント通知手段と、を備えたことを特徴とする。

また、本発明にかかるイベント通知装置は、請求項１に記載の発明において、前記イベント通知手段は、さらに、イベントの発生を通知する際にＵＤＰを用い、イベントの完了を通知する際にＴＣＰを用いる、ことを特徴とする。
また、本発明にかかるイベント通知装置は、請求項１又は２に記載の発明において、前記監視イベント指定メッセージを前記受信手段が受信した場合に、前記監視イベント指定メッセージに対応するレスポンスを、前記監視イベント指定メッセージの送信した前記クライアント装置に対して送信する送信手段を、さらに備えることを特徴とする。

また、本発明にかかるイベント通知装置は、請求項１乃至３のいずれか一つに記載の発明において、前記受信手段が受信した前記監視イベント指定メッセージの送信元を表すアドレス情報と、検出対象となるイベントと、当該クライアントに対する通知手法としてマルチキャスト又はユニキャストを保持する通知手法と、を対応付けて記憶する記憶手段をさらに備え、前記イベント通知手段は、前記イベント監視手段が前記イベントの発生を検出した場合に、当該イベントと前記記憶手段で対応付けられているアドレス情報に対する通知手法に、当該イベントと対応付けられている通知手法で通知すること、を特徴とする。

また、本発明にかかるイベント通知方法は、イベント通知装置で実行されるイベント通知方法であって、前記イベント通知装置が、イベント種別と、当該イベント種別で示されたイベントが発生した場合にクライアント装置に対して通知する通知手法と、を対応付けて記憶する通知管理記憶手段を備え、受信手段が、ネットワークを開始して接続された各クライアント装置から、監視を要求するイベント種別を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、監視手段が、自装置においてイベントが発生したか否かを監視するイベント監視ステップと、イベント通知手段が、前記イベント監視ステップが前記イベントの発生を検出した際、発生したイベント種別が前記監視イベント指定メッセージで複数の前記クライアント装置から監視を要求されていた場合に、当該複数のクライアントに対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてマルチキャストと対応付けられている場合に、ネットワークを介して接続された複数のクライアント装置に対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてユニキャストと対応付けられている場合に、当該イベントを監視する所定のクライアント装置にユニキャストで通知するイベント通知ステップと、を有することを特徴とする。

また、本発明にかかるイベント通知方法は、請求項９に記載の発明において、前記イベント通知ステップは、さらに、イベントの発生を通知する際にＵＤＰを用い、イベントの完了を通知する際にＴＣＰを用いる、ことを特徴とする。
また、本発明にかかるイベント通知方法は、請求項９又は１０に記載の発明において、送信手段が、前記監視イベント指定メッセージを前記受信ステップが受信した場合に、前記監視イベント指定メッセージに対応するレスポンスを、前記監視イベント指定メッセージの送信した前記クライアント装置に対して送信する送信ステップを、さらに有することを特徴とする。

また、本発明にかかるイベント通知方法は、請求項１１に記載の発明において、前記イベント通知装置が、前記受信ステップにより受信した前記監視イベント指定メッセージの送信元を表すアドレス情報と、検出対象となるイベントと、当該クライアントに対する通知手法としてマルチキャスト又はユニキャストを保持する通知手法と、を対応付けて記憶する記憶部を、さらに備え、前記イベント通知ステップは、前記イベント監視ステップが前記イベントの発生を検出した場合に、当該イベントと前記記憶手段で対応付けられているアドレス情報に対する通知手法に、当該イベントと対応付けられている通知手法で通知すること、を特徴とする。

また、本発明にかかるイベント通知プログラムは、コンピュータが、イベント種別と、当該イベント種別で示されたイベントが発生した場合にクライアント装置に対して通知する通知手法と、を対応付けて記憶する通知管理記憶手段を備え、各前記クライアント装置から、監視を要求するイベント種別を含むメッセージである監視イベント指定メッセージを受信する受信手段と、自装置においてイベントが発生したか否かを監視するイベント監視手段と、前記イベント監視手段が前記イベントの発生を検出した際、発生したイベント種別が前記監視イベント指定メッセージで複数の前記クライアント装置から監視を要求されていた場合に、当該複数のクライアントに対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてマルチキャストと対応付けられている場合に、ネットワークを介して接続された複数のクライアント装置に対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてユニキャストと対応付けられている場合に、当該イベントを監視する所定のクライアント装置にユニキャストで通知するイベント通知手段と、して機能させることを特徴とする。

本発明によれば、マルチキャストで効率的な通信処理を確保すると共に、監視先固有のイベントについてはユニキャストで信頼性を確保することが可能となるという効果を奏する。

以下に添付図面を参照して、この発明にかかるイベント通知装置、イベント通知方法、及びイベント通知プログラムの最良な実施の形態を詳細に説明する。

本発明の一実施の形態として、イベント通知装置であってコピー機能、ファクシミリ（ＦＡＸ）機能、プリント機能、スキャナ機能及び入力画像（スキャナ機能による読み取り原稿画像やプリンタあるいはＦＡＸ機能により入力された画像）を配信する機能等を複合したいわゆるＭＦＰ（Multi Function Peripheral）と称される複合機１に適用した例を示す。

なお、以下に示す実施の形態において、複合機はWS-Eventingを使用して、ネットワークを介して自身を利用する各端末との間でメッセージのやりとりを行うものとして説明する。このWS-Eventingとは、Ｗｅｂサービス上でのイベントの登録および通知のためのプロトコルであり、今後、多くの機器が使用すると予測されるものである。ただし、使用するプロトコルをWS-Eventingに限定するものではない。

このWS-Eventingを参照しているWS-DeviceProfileにて、次のような記述がある。"A Filter in this Dialect evaluates to true for an Output Message of a Notification or Solicit-Response operation if and only if a URI in the Filter matches the [action] property of the Message"。この仕様に従うと、イベントの種別が合えば、すべてのイベント監視先に通知を行うことになる。しかし、イベントの種別（例：ジョブ監視）によっては、すべてのイベント監視先に通知を行う必然性はない。そのジョブをリクエストした機器に対してのみ、イベントを発生させれば十分である。本実施の形態にかかる複合機１を用いた場合、この仕様を補うことができる。以下に当該仕様を補うための構成及び処理について説明する。

（実施の形態）
図１は、本実施の形態にかかる複合機およびネットワークを介して複合機を利用する端末により構成されるシステムの一例を示す図である。本図に示すシステムは、複合機１と、当該複合機１を利用する複数の通信装置としてパーソナルコンピュータ（ＰＣ−Ａ２，ＰＣ−Ｂ３，ＰＣ−Ｃ４，ＰＣ−Ｄ５，ＰＣ−Ｅ６，ＰＣ−Ｆ７，ＰＣ−Ｇ８）を含んでいる。通常、ネットワークを介して複合機１を利用するためには、所定の手続を実行する必要があるが、上記各パーソナルコンピュータは、必要な手続を既に実行し、上記複合機１を利用可能な状態にあるものとする。なお、複合機１を利用する装置は、パーソナルコンピュータに限らず、同様の通信機能などを備えた装置であればよい。また、これ以降、ネットワークを介して上記複合機１を利用する通信装置をクライアントと呼ぶ。

図２は、本実施の形態にかかる複合機１のハードウェア構成例を示す図である。本図に示すように、複合機１は、ＣＰＵ１１と、システムメモリ１２と、ノースブリッジ（ＮＢ）１３と、サウスブリッジ（ＳＢ）１４と、ＡＳＩＣ１５と、記憶部１６と、Ｉ／Ｆ部１７と、を備える。

複合機１において、ＣＰＵ１１は、複合機１の全体の制御を行う。システムメモリ１２は、描画処理を行う際などに使用される。ＮＢ１３は、ＣＰＵ１１、システムメモリ１２、ＳＢ１４、ＡＳＩＣ１５、Ｉ／Ｆ部１７を接続するためのブリッジ、ＳＢ１４は、図２に示した各構成要素と図示されていない他の構成要素（ＲＯＭなど）とを接続するためのブリッジである。ＡＳＩＣ１５は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）である。

記憶部１６は、ローカルメモリ２１、ＨＤＤ（Hard Disk Drive）２２、Ｆｌａｓｈ ＲＯＭ２３、ＮＶＲＡＭ２４、ＳＤＲＡＭ２５及びセキュアデバイス２６などを含み、画像データ等の格納用領域や画像処理を行う際の作業用領域などとして使用される。

Ｉ／Ｆ部１７は、Ethernet（登録商標）Ｉ／Ｆ３１、ＵＳＢ＿Ｉ／Ｆ３２、ＩＥＥＥ１３９４＿Ｉ／Ｆ３３、セントロニクス＿Ｉ／Ｆ３４、無線＿Ｉ／Ｆ３５及び外部記憶媒体用Ｉ／Ｆ３６などを含む。これらのＩ／Ｆは、インターネットやイントラネットなどのネットワークへの接続やパーソナルコンピュータなどへの接続のためなどに使用される。

さらに、ＡＳＩＣ１５は、オペレーションパネル４１と、ＦＣＵ４２と、エンジン部４３と接続され、これらとの間でデータを送受信する。

図３は、本実施の形態にかかる複合機１のソフトウェア構成例を示す図である。アプリケーション部３０３、プラットフォーム部３０１およびＳＯＡＰ／ＸＭＬ処理部３０２がソフトウェアを構成し、これらの各構成要素は、図２に示したＣＰＵ１１により制御される。また、複合機１は、セキュアデバイス３３１と、ＨＤＤ２２と、ＮＶＲＡＭ２４と、外部デバイスＩ／Ｆ３６と、EthernetＩ／Ｆ３１と、ＧＳＴＮ＿Ｉ／Ｆ３３６と接続されている。

アプリケーション部３０３は、プリンタ、コピーなどの画像形成処理に関連するユーザーサービスに固有の処理を行う複数のアプリケーション処理部を含む。アプリケーションの例としては、コピー用のアプリケーションであるコピーアプリ３１１、ファクシミリ用アプリケーションであるファクスアプリ３１２、スキャナ用アプリケーションであるスキャナアプリ３１３、ネットワークファイル用アプリケーションであるネットファイルアプリ３１４、及びページ記述言語およびプリンタ用のアプリケーションであるプリンタアプリ３１５とする。

プラットフォーム部３０１は、ＯＳ／Ｋｅｒｎｅｌ３２１とともに、アプリケーション部３０３からの処理要求を解釈してハードウェアなどの各種資源の獲得要求を発生する各種制御部（システム制御部３２２、メモリ制御部３２３、エンジン制御部３２４、ファックス制御部３２９、オペレーション制御部３２７、配信制御部３２６、ネットワーク制御部３２８、セキュリティ制御部３２５、…）を備えている。また、プラットフォーム部３０１は、予め定義されている関数によりアプリケーション部３０３からの処理要求を受信可能とするアプリケーションプログラムインターフェース（ＡＰＩ）を有する。また、ＯＳ／Ｋｅｒｎｅｌ３２１にはソケット以下のEthernetI/F３１等のネットワーク処理部が存在している。

図３に示すシステム制御部３２２は、操作部の制御、システム画面の表示、LEDの表示、ハードウェア資源の管理、割り込みアプリケーションの制御などの処理を行う。メモリ制御部３２３は、メモリの取得および解放、画像データの圧縮および伸張などのメモリ制御を行う。配信制御部３２６は、他機器との送受信のためのデータの管理やデータの加工などを行う。ネットワーク制御部３２８は、図１に示したEthernet（登録商標）Ｉ／Ｆ３１などのネットワークインタフェイスと接続され、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供し、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分け、各アプリケーションからのデータをネットワーク側に通知する際の仲介を行う。

エンジン制御部３２４は、複合機１が備えるプロッタエンジン等を制御する。セキュリティ制御部３２５は、アプリケーション部や各制御部に対してセキュリティサービスを行う。例えば、セキュリティ制御部３２５は、暗号化や復号化などを行う。

オペレーション制御部３２７は、オペレーションパネル４１の表示や、オペレーションパネル４１に対して行われた入力処理等の、オペレータと本体制御との間の情報伝達手段となるオペレーションパネル４１を制御する。ファックス制御部３２９は、ＧＳＴＮ Ｉ／Ｆ３３６と接続し、システムコントローラの各アプリケーション層からＧＳＴＮ網を利用したファクシミリ送受信、バックアップ用のメモリで管理されている各種ファクシミリデータの登録/引用、ファクシミリ読み取りを行い、ファクシミリ受信印刷などを行うためのＡＰＩを提供する。

ＳＯＡＰ／ＸＭＬ処理部３０２は、アプリケーション部３０３からもプラットフォーム部３０１からも使用できるような形で存在している。通常、ＳＯＡＰ／ＸＭＬ処理部３０２は、ライブラリの形式で提供されるが、アプリや制御部などのようなプロセスの形式でもかまわない。このＳＯＡＰ／ＸＭＬ処理部３０２は、ＳＯＡＰ／ＸＭＬメッセージのエンコード／デコードを行う。なお、ＳＯＡＰ／ＸＭＬ処理部３０２は、通常、ライブラリの形式で提供されるが、プロセスの形式でもかまわない。

図４は、複合機１にかかるイベント通知に用いるアプリケーション部３０３、ＳＯＡＰ／ＸＭＬ処理部３０２、ネットワーク制御部３２８、及び記憶部１６及びＩ／Ｆ部１７の構成例を示す図である。

記憶部１６は、ＨＤＤ２２等の任意の記憶媒体においてイベントリクエスト管理テーブル４４２と、ＮＶＲＡＭ２４内において通知管理テーブル４４３と、ＩＰアドレス毎要求受入管理テーブル４４１と、イベント毎要求受入管理テーブル４４４とを備える。

図５は、イベントリクエスト管理テーブル４４２のテーブル構造を示す図である。図５に示すように、イベントリクエスト管理テーブル４４２は、イベント管理ＩＤと、イベントリクエスト元（監視先）ＩＰアドレスと、リクエストしたイベント種別と、イベントが発生した場合の通知手法とを対応付けて保持している。また、イベント管理ＩＤは、イベントリクエスト管理テーブル４４２のレコード毎に割り振られた固有のＩＤとする。そして、当該イベントリクエスト管理テーブル４４２は、クライアントからの登録に応じてレコードが追加される。

イベントリクエスト管理テーブル４４２は、イベント監視先（クライアント）からリクエストされた監視対象となるイベントと、イベントが発生した場合の通知手法と対応付けて保持するため、イベントが生じた場合に適切な通信を行うことができる。イベントリクエスト管理テーブル４４２の各レコードは、監視先からのSubscribe(Renew)リクエストを受信したときに登録、更新が行われる。

通知管理テーブル４４３は、イベントが発生した際のイベント毎に通知手法を管理している。図６は、通知管理テーブル４４３のテーブル構造を示す図である。図６に示すように、通知管理テーブル４４３は、イベント種別と、当該イベントが生じた場合の通知手法と、通知を行う際に用いるプロトコルと、を保持している。なお、通知手法が、マルチキャストの場合、マルチキャストとして通常用いるプロトコル（例えばＵＤＰ）を利用するものとして設定不要とする。

本実施の通知管理テーブル４４３では、イベント毎に通知手法のルールを保持している。例えば、通知管理テーブル４４３は、全てのイベント監視先に共通なイベント（例えば、紙なし、カバーオープン）に対して、マルチキャストを対応付け、特定の監視先固有のイベント（例えば、ジョブステータス）については、ユニキャストを対応付けた。これにより、共通するイベントについては、マルチキャストで効率的な通信処理を確保すると共に、監視先固有のイベントについては、ユニキャストで信頼性を確保することができる。

さらに、図６に示す通知管理テーブル４４３では、ユニキャストで用いるプロトコルにＴＣＰ又はＵＤＰを設定することができる。例えば、同じジョブステータスの排紙完了及び印刷開始のうち、印刷という操作としては、前者の方が重要である。そこで、排紙完了にＴＣＰを用い、印刷開始にＵＤＰを用いる。このように、イベントの重要性に応じて、プロトコルを変更することができる。

図７は、ＩＰアドレス毎要求受入管理テーブル４４１のテーブル構造を示す図である。図７に示すように、ＩＰアドレス毎要求受入管理テーブル４４１は、ＩＰアドレスと、通知手法の受入フラグと、を管理している。通知手法の受入フラグは、ＩＰアドレスからイベント監視リクエストを受信した際、当該リクエスト内で通知手法が指定されていた場合、当該通知手法を受け付けるか否か判断するフラグとなる。このように、当該テーブルは、イベントの監視の要求元から指定された通知手法を、当該要求元のＩＰアドレスに応じて受け入れるか否か判断する際に用いる。

図８は、イベント毎要求受入管理テーブル４４４のテーブル構造を示す図である。図７に示すように、イベント毎要求受入管理テーブル４４４は、イベント種別と、通知手法の受入フラグと、を管理している。通知手法の受入フラグは、イベント監視リクエストを受信した場合に、当該リクエストで指定された監視対象となるイベント種別において、当該通知手法を受け付けるか否か判断するフラグとなる。このように、当該テーブルは、イベントの監視の要求元から指定された通知手法をイベント種別に応じて、受け入れるか否か判断する際に用いる。

これら、各管理テーブルが保持するデータは、利用者がオペレーションパネル４１からオペレーション制御部３２７を通じて設定された情報、又はネットワーク制御部３２８を通じて外部から設定された情報とする。これにより、利用者は、条件に応じて適切な通知手法を設定することができる。

上述したようにＮＶＲＡＭ２４には様々な情報が格納されている。そして、このようなＮＶＲＡＭ２４保存されるデータは、複合機１のオペレーションパネル４１からオペレーション制御部３２７を通じて設定される。また、これらデータは、ネットワーク制御部３２８を通じてクライアント等の通信装置から設定されることにしても良い。

なお、上述した各テーブルは、本実施の形態のようにＮＶＲＡＭ２４などの記憶部１６に記憶するものに限らず、他の記憶媒体に記憶しても良い。さらには、これら対応関係をテーブルで管理するのではなくソフトウェア上にハードコーディングしても良い。

図４に戻り、ネットワーク制御部３２８は、全体を統括する全体制御部４１１、WS-Eventingプロトコルを処理するWS-Eventing処理部４１３、イベントを管理するイベント管理部４１４、図３に示したアプリケーション部３０３や他の制御部との間で各種情報（メッセージやデータ）のやり取りを行う通信部４１５、ＨＴＴＰ制御部４１６、およびＨＴＴＰ以外の各種プロトコル（たとえばFTP，Port9100，LPR)を処理するプロトコル制御部４１２と、を備えている。

WS-Eventing処理部４１３は、WS-Eventingの仕様に従ってイベント通知のメッセージの通知等を行うために必要な処理を行う。WS-Eventing処理部４１３は、WS-Eventingの仕様に従ってメッセージ等を生成する場合、ＳＯＡＰ／ＸＭＬ処理部３０２に処理を依頼することになる。これにより、WS-Eventingプロトコルを用いて送受信を行うことができる。

ＨＴＴＰ制御部４１６は、受信部４２１と、選択部４２２と、イベント通知部４２３とを備え、ＨＴＴＰプロトコルを用いてデータの送受信を行う。受信部４２１は、クライアントからイベント監視リクエストを受信する。その後、後述するイベント管理部４１４の登録部４３２が、受信したイベント監視リクエストに基づいて、イベントを監視するための情報を、イベントリクエスト管理テーブル４４２に登録する。

選択部４２２は、イベント監視部４３１がイベントの発生を検出した場合に、イベントの通知を、どのような通信手法で通信するのかを、イベントリクエスト管理テーブル４４２を用いて選択する。なお、詳細な処理手順については後述する。

イベント通知部４２３は、後述するイベント管理部４１４がイベントを検出した場合に、ＨＴＴＰプロトコルを用いて、クライアントにイベント通知を行う。なお、通知を行うクライアントの決定や、イベント通知として通知されるメッセージの生成手順については後述する。

イベント管理部４１４は、イベント監視部４３１と、登録部４３２と、を備える。

イベント監視部４３１は、通信部４１５を介して、アプリケーション部３０３の各アプリにおいてイベントが発生するか否かを監視する。

登録部４３２は、受信部４２１がイベント監視リクエストを受信した場合、当該リクエスト内容等に従って、イベント管理ＩＤと、当該リクエストの送信元のＩＰアドレスと、当該リクエストで監視対象となるイベント種別と、メッセージの通知手法とを、対応付けて、イベントリクエスト管理テーブル４４２に登録する。なお、詳細な登録手順については、後述する。

アプリケーション部３０３に含まれる各アプリケーション（アプリ＃１，…）は、ほぼ同様の構成となり、アプリケーションの制御を行うアプリケーション制御部４５３と、イベントを検出するイベント検出部４５２と、プラットフォーム部３０１を構成する各制御部（すなわち上記イベント通知部に含まれる各制御部）との間で各種情報（メッセージやデータ）の送受信を行う情報通信部４５１と、を備える。

そして、イベント監視部４３１は、アプリケーション部３０３の各アプリケーション（アプリ＃１，…）のイベント検出部４５２と、通信部４１５を介してデータの送受信を行うことで、各アプリケーションにおいてイベントが発生したか否かの監視を定期的に行う。そして、イベント監視部４３１がいずれかのアプリケーションにおいてイベント発生を検出した場合、選択部４２２が通信手法の選択を行った後、イベント通知部４２３が選択された通信手法を用いて、イベントの発生を各クライアントへ通知する。

次に、複合機１が、クライアントとの間で送受信されるメッセージについて具体的に説明する。

図９は、クライアントが複合機１に対して送信する、イベントの通知を要求するメッセージの例を示した図である。図９は、イベント通知を要求するSubscribeメッセージの一例を示したものである。符号９０１で示した行により、Subscribeメッセージであることが確認できる。

図９で示したメッセージは、複合機１において当該メッセージで指示するイベントが発生した場合、その内容をメッセージの通知元のクライアントに通知するように複合機１に対して要求する。

具体的には、当該メッセージの内容は、「"PrinterStatusEvent(符号９０２)"が示すイベントについてStatusが変化したら（イベントが発生したら）通知をしてほしい」ということを示している。Subscribeメッセージを受信した複合機１は、その要求内容に応じることができるか否かを確認し、ＨＴＴＰ制御部４１６が確認結果に基づいた内容の応答メッセージを返信する。この符号９０２で示されたDialectに記載された値が、イベントの種別に相当する。

そして、タグ"rr:Notification_Method"で囲まれた範囲９０３に、通信手法を設定することができる。図９に示す例では、"Multicast"が設定されていることから、マルチキャストで通信することを要求している。ただし、指定した通知方法で、通知されるとは限らない。通知方法の設定手法については後述する。次に、Subscribeメッセージに対応する応答メッセージについて説明する。

図１０は、図９のSubscribeメッセージに対応する、複合機１が通知する応答メッセージの例を示した図である。複合機１は、図１０に示すような内容のメッセージを、Subscribeメッセージに対するレスポンス（SubscribeResponse）メッセージとして、各クライアントに通知する。図１０に示すレスポンスメッセージは、Subscribeメッセージを正常に受け付けた場合に通知されるメッセージである。符号１００１で示した行により、SubscribeResponseメッセージであることが確認できる。

図１０に示すレスポンスメッセージは、「Subscribeメッセージで指示されたイベントが発生（検知）した場合、その内容（発生したイベント）を、マルチキャストで通知する」ということを示している。これ以後、原則として、複合機１は、上記Subscribeメッセージで指示されたイベントを検知した場合、タグ"rr:Notificatoin_Method"１００２で定義された通信手法で、イベントが検出されたことを表す内容を上記SubscribeResponseメッセージの通知先のクライアントに通知する。なお、図１０に示す例では、マルチキャスト通信がなされることになる。次に、別のSubscribeメッセージについて説明する。

図１１は、クライアントが複合機１に対して送信する、イベントの通知を要求するメッセージの他の例を示した図である。図１１は、イベント通知を要求するSubscribeメッセージの他の一例を示したものである。符号１１０１で示した行により、Subscribeメッセージであることが確認できる。

図９と異なる点としては、当該メッセージの内容は、「"JobStatusEvent(符号１１０２)"が示すイベントについてStatusが変化したら（イベントが発生したら）通知をしてほしい」ということを示している。Subscribeメッセージを受信した複合機１は、その要求内容に応じることができるか否かを確認し、ＨＴＴＰ制御部４１６が確認結果に基づいた内容の応答メッセージを返信する。この符号１１０２で示されたDialectに記載された値が、イベントの種別に相当する。

そして、タグ"rr:Notification_Method"で囲まれた範囲１１０３に、通信手法を設定することができる。図１１に示す例では、"Unicast:TCP"が設定されていることから、プロトコルとしてＴＣＰを用いた上でユニキャスト通信することを要求している。

図１２は、図１１のSubscribeメッセージに対応する、複合機１が通知する応答メッセージの例を示した図である。複合機１は、図１１に示すような内容のメッセージを、Subscribeメッセージに対するレスポンス（SubscribeResponse）メッセージとして、各クライアントに通知する。図１２に示すレスポンスメッセージは、Subscribeメッセージを正常に受け付けた場合に通知されるメッセージである。符号１２０１で示した行により、SubscribeResponseメッセージであることが確認できる。

図１２に示すレスポンスメッセージは、「Subscribeメッセージで指示されたイベントが発生（検知）した場合、その内容（発生したイベント）を、ＵＤＰによるユニキャスト通知を行う」ということを示している。これ以後、原則として、複合機１は、上記Subscribeメッセージで指示されたイベントを検知した場合、タグ"rr:Notificatoin_Method"１２０２で定義された通信手法で、イベントが検出されたことを表す内容を上記SubscribeResponseメッセージの通知先のクライアントに通知する。なお、図１２に示す例では、ＵＤＰによるユニキャスト通信がなされることになる。

図９〜図１２で示したメッセージにおける、Expiresフィールドの値（図９の符号９０４、図１０の符号１００３、図１１の符号１１０４及び図１２の符号１２０３）は、リクエストの有効期間を表している。各図においては、例として３０分が設定されている場合とするが、リクエスト毎に適切な時間が設定される。また、イベント監視先となるクライアント（例えばＰＣ−Ａ２）は、監視を続ける必要がある場合、有効期間前に有効期限を更新するRenewリクエストを、複合機１に対して通知する。これに対して、複合機１は、RenewResponseメッセージによる応答を、更新要求を行ったクライアントに対して送信する。なお、Renewリクエスト、及びRenewResponseメッセージは、更新要求とそれに対応する応答であれば、どのようなフォーマットによるリクエスト、メッセージでも良い。

図１３は、Subscribeメッセージによる要求に対して、複合機１がＮＧであることを通知する応答メッセージの例を示した図である。複合機１は、図１３に示すような内容のメッセージを、Subscribeメッセージに対するレスポンス（SubscribeResponse）メッセージとして、クライアントに通知する。図１３に示すレスポンスメッセージは、Subscribeメッセージを拒否した場合に通知されるメッセージである。符号１３０１で示した行の、EventSourceUnableToProcessの記載より、要求が拒否されたことが確認できる。

図１４は、イベント通知部４２３が通知するPrinterStatusEventReportメッセージの例を示す図である。複合機１は、図９に示したSubscribeメッセージを受け付けた後に、発生したイベントを、当該PrinterStatusEventReportメッセージとして通知する。なお、符号１４０１で示した行により、PrinterStatusEventReportメッセージであることが確認できる。

図１４に示したメッセージは、符号１４０２で示した行により、複合機１のトナーがなくなった（Out of Toner）ことが検出されたことを通知するためのメッセージであることが確認できる。

また、図５に示すイベントリクエスト管理テーブル４４２のレコード５０１で、「トナーなし」のイベントについて通信手法にマルチキャストが設定されている。このため、PrinterStatusEventReportメッセージはマルチキャストで通知される。

これにより、クライアントは、複合機１においてトナーが無くなったことを認識することができる。

図１５は、イベント通知部４２３が通知するJobStatusEventReportメッセージの例を示す図である。複合機１は、図９に示したSubscribeメッセージを受け付けた後に、発生したイベントを、当該JobStatusEventReportメッセージとして通知する。なお、符号１５０１で示した行により、JobStatusEventReportメッセージであることが確認できる。

図１５に示したメッセージは、符号１５０２で示した行により、複合機１においてＪｏｂが終了した（Completed）ことが検出されたことを通知するためのメッセージであることが確認できる。

また、図１５に示したメッセージは、図５に示すイベントリクエスト管理テーブル４４２のレコード５０２において、通信手法にＴＣＰによるユニキャストが設定されている。このため、排紙が終了したことを表すJobStatusEventReportメッセージは、ＴＣＰによるユニキャストで通知される。

つづいて、イベント管理部４１４の動作を中心に、本実施の形態にかかる複合機１の詳細動作を説明する。まず、各クライアントが上記複合機１からイベント発生時にその内容の通知を受けるために必要な動作である複合機１に対する初期設定動作について説明する。具体的には、クライアントが複合機１に対して、発生したイベントを通知するように要求を出し、この要求に対して複合機１が実行する動作について説明する。

図１６は、複合機１がクライアントからSubscribeメッセージまたはRenewメッセージを受信するシーケンスを示す図である。なお、図１６に示す例ではクライアントがＰＣ−Ａ２の場合について説明するが当然に他の機器でも良い。

複合機１は、ＰＣ−Ａ２からSubscribeメッセージまたはRenewメッセージを受信する（ステップＳ１６０１）。その場合、複合機１のネットワーク制御部３２８のＨＴＴＰ制御部４１６は、受信したメッセージをWS-Eventing処理部４１３に出力する（ステップＳ１６０２）。

そして、WS-Eventing処理部４１３は、入力されたメッセージを、さらにＳＯＡＰ／ＸＭＬ処理部３０２に出力する（ステップＳ１６０３）。これにより、ＳＯＡＰ／ＸＭＬ処理部３０２は、入力されたメッセージを解析する。そして、ＳＯＡＰ／ＸＭＬ処理部３０２は、当該内容解析結果を、WS-Eventing処理部４１３に出力する（ステップＳ１６０４）。

次に、WS-Eventing処理部４１３は、ステップＳ１６０４により入力された内容解析結果を登録するようにイベント管理部４１４に対して要求する（ステップＳ１６０５）。これにより、イベント管理部４１４は、ステップＳ１６０５の要求内容に基づいて、当該解析内容結果をイベントリクエスト管理テーブル４４２に対して登録又は確認する処理を行う（ステップＳ１６０６）。

例えば、イベント管理部４１４は、受信したSubscribeメッセージが示す要求を受け入れることができると判断した場合、イベント管理部４１４の登録部４３２が、当該Subscribeメッセージに含まれている情報及び各管理テーブルに基づいて、イベントリクエスト管理テーブル４４２に新たなレコード情報を登録する。この登録されるレコード情報は、Subscribeメッセージで指定されているイベントが発生した場合に、当該イベントをどのクライアントに通知すべきか否かが示された情報である。そして、イベントリクエスト管理テーブル４４２では、当該イベントの種別と、送信先のクライアントとの対応関係を保持している。また、イベントリクエスト管理テーブル４４２に、上述したイベントの通知を行う有効期限を含めてもよい。なお、登録される情報の選択手順、及び登録手順の詳細については後述する。

そして、イベント管理部４１４は、上述した処理が終了すると、その処理結果をWS-Eventing処理部４１３に出力する（ステップＳ１６０７）。その後、WS-Eventing処理部４１３は、上記Subscribeメッセージ又はRenewメッセージの送信先であるクライアントに対して送信するメッセージ（レスポンスメッセージ）を、入力された処理結果に基づいて生成するようにＳＯＡＰ／ＸＭＬ処理部３０２に対して要求する（ステップＳ１６０８）。

そして、ＳＯＡＰ／ＸＭＬ処理部３０２は、WS-Eventing処理部４１３か入力された処理結果に従って、レスポンスメッセージを生成して、WS-Eventing処理部４１３に出力する（ステップＳ１６０９）。

次に、WS-Eventing処理部４１３は、入力されたレスポンスメッセージを、ＨＴＴＰ制御部４１６に出力する（ステップＳ１６１０）。これにより、ＨＴＴＰ制御部４１６は、入力されたレスポンスメッセージを、クライアントに対して送信する（ステップＳ１６１１）。

なお、ステップＳ１６１１においてＨＴＴＰ制御部４１６から送信されるメッセージは、ステップＳ１６０１において複合機１が受け取ったメッセージの内容（SubscribeメッセージかRenewメッセージか）及び上記ステップＳ１６０６におけるイベント管理部４１４の処理結果により異なるものとなる。例えばステップＳ１６０１においてSubscribeメッセージを受信した場合、複合機１は、ステップＳ１６１１においてSubscribeResponseメッセージを送信する。また、ステップＳ１６０１においてRenewメッセージを受信した場合、複合機１は、ステップＳ１６１１においてRenewResposeメッセージを送信する。

図１７は、複合機１におけるイベント発生監視動作シーケンス及び検出したイベントの通知動作の一例を示す図である。図１７に示す例では、通知方式としてマルチキャストを用いた例とする。

まず、複合機１のネットワーク制御部３２８に格納されているイベント管理部４１４のイベント監視部４３１は、アプリケーション部３０３の各アプリケーションにおいてイベントが発生したか否かの監視を定期的に行う（ステップＳ１７０１、Ｓ１７０３）。本実施の形態では、イベント監視部４３１は、イベントが発生したか否か（状態が変化したか否か）を、各アプリケーションのイベント検出部４５２に対して問い合わせる。

図１７に示した監視は、内部的にはイベント検出ポーリング型とする。つまり、ネットワーク制御部３２８のイベント管理部４１４は、他のアプリの情報通信部４５１を介して、アプリのイベントを管轄するイベント検出部４５２に状態変化の問い合わせを定期的に行う。例えば、図９に示したような、PrinterStatusEventの監視を受け付けた場合、ネットワーク制御部３２８は、プリンタアプリ３１５に対する問い合わせで、イベントを検出する。

このように、イベント管理部４１４と各アプリケーションのイベント検出部４５２は、通信部４１５及び情報通信部４５１を介して通信が行われている。

そして、イベント検出部４５２は、イベント管理部４１４からの問い合わせに対して、イベントが発生していなければその旨を通知する（ステップＳ１７０２）。これに対して、イベント検出部４５２がイベントの発生を検出した場合（ステップＳ１７０４）、イベントが発生している旨を通知する（ステップＳ１７０５）。

次に、イベント監視部４３１が、イベント検出部４５２からイベント発生の通知を受け付けた場合、イベント管理部４１４がその旨をWS-Eventing処理部４１３に通知する（ステップＳ１７０６）。WS-Eventing処理部４１３は、イベントの発生をクライアントに対して通知するためのメッセージを生成するようにＳＯＡＰ／ＸＭＬ処理部３０２に対して要求する（ステップＳ１７０７）。

そして、ＳＯＡＰ／ＸＭＬ処理部３０２がメッセージを生成した後、生成されたメッセージをWS-Eventing処理部４１３に対して出力する（ステップＳ１７０８）。その後、WS-Eventing処理部４１３は、入力されたメッセージを、ＨＴＴＰ制御部４１６に出力する（ステップＳ１７０９）。

選択部４２２が、イベントリクエスト管理テーブル４４２を参照し、当該イベントと対応付けられた通知手法を選択する（ステップＳ１７１０）。本シーケンス図では、マルチキャストが選択されたものとする。

次に、ＨＴＴＰ制御部４１６のイベント通知部４２３は、WS-Eventing処理部４１３から入力されたメッセージ（例えば、図１４に示すPrinterStatusEventReportメッセージ）を、ＰＣ−Ａ２を含む装置群にマルチキャストで通知する（ステップＳ１７１１）。なお、図１７に示す例では、イベントが発生した旨のメッセージをNotificationメッセージとして表現している。

図１８は、複合機１におけるイベント発生監視動作シーケンス及び検出したイベントの通知動作の第２の例を示す図である。図１８に示す例では、通知方式としてユニキャストを用いた例とする。

図１８に示すように、アプリのイベント検出部４５２が、イベントを検出する（ステップＳ１８０１）。なお、図１８に示す、イベント検出部４５２による監視は、内部的にはイベントドリブン型とする。そして、アプリ内のイベント検出部４５２は、発生したイベントを、情報通信部４５１を介して、ネットワーク制御部３２８のイベント管理部４１４に送信する（ステップＳ１８０２）。これ以降のステップＳ１８０３〜Ｓ１８０６で示した処理は、図１７のステップＳ１７０６〜Ｓ１７０９に示した処理と同様として説明を省略する。

その後、選択部４２２が、イベントリクエスト管理テーブル４４２を参照し、当該イベントと対応付けられた通知手法を選択する（ステップＳ１８１０）。本シーケンス図では、ユニキャストが選択されたものとする。

次に、ＨＴＴＰ制御部４１６のイベント通知部４２３は、WS-Eventing処理部４１３から入力されたメッセージ（例えば、図１５に示すJobStatusEventReportメッセージ）を、ＰＣ−Ａ２にユニキャストで通知する（ステップＳ１８１１）。

その後、ＰＣ−Ａ２は、受信したメッセージに対する応答メッセージ(図１７に示す例ではHTTP 200 Response)を返信する（ステップＳ１８１２）。

図１９は、複合機１における終了処理時の動作の例を示す図である。図１９に示す例では、終了を通知するための通知方式としてマルチキャストを用いた例とする。

イベント管理部４１４は、利用者から複合機１の終了する要求を受け付ける（ステップＳ１９０１）。

次に、イベント管理部４１４が、終了処理要求を、WS-Eventing処理部４１３に通知する（ステップＳ１９０２）。WS-Eventing処理部４１３は、終了することをクライアントに対して通知するためのメッセージを生成するようにＳＯＡＰ／ＸＭＬ処理部３０２に対して要求する（ステップＳ１９０３）。

そして、ＳＯＡＰ／ＸＭＬ処理部３０２は、メッセージを生成した後、生成されたメッセージをWS-Eventing処理部４１３に対して出力する（ステップＳ１９０４）。その後、WS-Eventing処理部４１３は、入力されたメッセージを、ＨＴＴＰ制御部４１６に出力する（ステップＳ１９０５）。

その後、選択部４２２が、イベントリクエスト管理テーブル４４２を参照し、イベントの監視要求を行った全てのクライアントのＩＰアドレスを選択する（ステップＳ１９０６）。

そして、ＨＴＴＰ制御部４１６のイベント通知部４２３は、WS-Eventing処理部４１３から入力されたメッセージ（終了するすることを表すSubscriptionEndメッセージ）を、選択されたＩＰアドレスを含むクライアント群にマルチキャストで通知する（ステップＳ１９０７）。

上述した処理手順により、複合機１に対してイベントの監視を要求した全てのクライアント群に対して、当該複合機１が終了したことを認識させることができる。このようにマルチキャストなどのメッセージの通知に用いる通知手法は、イベントリクエスト管理テーブル４４２で設定されている通知手法を用いることに制限するものではない。

次に、本実施の形態にかかる複合機１におけるSubscribe(Renew)リクエストの受信から、SubscribeResponse(RenewResponse)メッセージを送信するまでの処理について説明する。図２０は、本実施の形態にかかる複合機１における上述した処理の手順を示すフローチャートである。なお、当該フローは、図１６の内部シーケンスに相当する。

まず、ＨＴＴＰ制御部４１６は、Subscribe/Renewリクエストを受信する（ステップＳ２００１）。そして、ＳＯＡＰ／ＸＭＬ処理部３０２により、当該リクエストを解析した後、イベント管理部４１４に、当該リクエストの内容が送信される。

次に、イベント管理部４１４は、入力されたメッセージに、通知方法のリクエストがあるか否か判断する（ステップＳ２００２）。

そして、イベント管理部４１４が、クライアントからの通知方法のリクエストがあると判断した場合（ステップＳ２００２：Ｙｅｓ）、ＩＰアドレス毎要求受入管理テーブル４４１を参照し、クライアントのＩＰアドレスが、制限対象となるＩＰアドレスか否か判断する（ステップＳ２００３）。そして、イベント管理部４１４が、制限対象となるＩＰアドレスと判断した場合（ステップＳ２００３：Ｙｅｓ）、当該ＩＰアドレスと対応付けられている通知手法を、登録する通知手法として選択する（ステップＳ２０１１）。

一方、イベント管理部４１４が、制限対象となるＩＰアドレスと判断しなかった場合（ステップＳ２００３：Ｎｏ）、イベント毎要求受入管理テーブル４４２を参照し、クライアントから監視要求がなされたイベントが制限対象イベントであるか否か判断する（ステップＳ２００４）。

そして、イベント管理部４１４が、イベントが制限対象イベントであると判断した場合（ステップＳ２００４：Ｙｅｓ）、及び通知手法のリクエストがないと判断していた場合(ステップＳ２００２：Ｎｏ)、イベント毎要求受入管理テーブル４４２を参照し、当該イベントと対応付けられた通知手法（マルチキャスト、ユニキャストＴＣＰ、ユニキャストＵＤＰ）が設定されているか否か判断する（ステップＳ２００８）。そして、通知手法が設定されていないと判断した場合（ステップＳ２００８：Ｎｏ）、イベント管理部４１４は、複合機１の予め設定されているデフォルトの通知手法を、登録する通知手法として選択する（ステップＳ２０１０）。なお、ステップＳ２０１０においては、イベント管理部４１４は、通知管理テーブル４４３等で設定されている通知手法を選択しても良い。

一方、イベント管理部４１４が、通知手法が設定されていると判断した場合（ステップＳ２００８：Ｙｅｓ）、イベント毎要求受入管理テーブル４４２を参照し、イベントと対応付けられている通知手法を、登録する通知手法として選択する（ステップＳ２００９）。

また、イベント管理部４１４は、クライアントから監視を要求されたイベントが制限対象イベントではないと判断した場合（ステップＳ２００４：Ｎｏ）、当該イベントが通知管理テーブル４４３に登録されているか否か判断する（ステップＳ２００５）。イベント管理部４１４が、通知管理テーブル４４３に登録されているイベントであると判断した場合（ステップＳ２００５：Ｙｅｓ）、既に通知管理テーブル４４３に登録されているルールに従った通知手法を、登録する通知手法として選択する（ステップＳ２００７）。ルールの例としては、ステータス関連は、マルチキャスト、ジョブ関連はユニキャストとする、又は既に登録されているイベントと対応付けられている通知手法に従う等が考えられる。

一方、イベント管理部４１４が、通知管理テーブル４４３に登録されているイベントではないと判断した場合（ステップＳ２００５：Ｎｏ）、クライアントからリクエストされた通知手法を、登録する通知手法として選択する（ステップＳ２００６）。

そして、ステップＳ２０１１、Ｓ２００６、Ｓ２００９及びＳ２０１０の処理の後、イベント管理部４１４の登録部４３２が、イベントリクエスト管理テーブル４４２に対して、イベント管理ＩＤ、クライアントのＩＰアドレス、監視がリクエストされたイベント種別、及び選択された通知手法の登録、継続確認を行う（ステップＳ２０１２）。

その後、入力された処理結果に基づいてメッセージをＳＯＡＰ／ＸＭＬ処理部３０２が生成する。その後、ＨＴＴＰ制御部４１６が、Subscribe/Renew Responseメッセージを送信する（ステップＳ２０１３）。

上述した処理手順により、監視対象となるイベント毎に適切な通知手法が選択される。なお、当該処理手順は一例として示したものであり、条件として異なる組み合わせも考えられる。

上述した複合機１では、イベントリクエスト管理テーブル４４２で管理されている通信手法に従って、イベントの通知を行うことで、イベントの種別や、イベントの監視を要求したクライアントなどに応じて、マルチキャストかユニキャストか、ユニキャストでもＴＣＰかＵＤＰか選択することができる。

本実施の形態にかかる複合機１は、ネットワークを介して様々なクライアント装置と接続され、当該クライアント装置からのイベント監視リクエストを受け付け、当該イベント監視リクエストで監視要求が行われたイベントが発生した場合に、当該リクエストを出力したクライアントに対して、イベント通知を行う。このイベント通知にマルチキャストで通知を行うことで、通知回数を軽減させることができるので、処理負担を軽減させることができる。

また、複合機１は、通知手法をマルチキャストかユニキャストかの選択可能としたため、通知手法に自由度を持たせることを可能とすると共に、イベント毎に効果的な通知を行うことが可能となる。また、通知手法のカスタマイズとして、各管理テーブルのレコードを編集により実現できる。このように、利用者の要求に従った通知手法を実現できる。

また、イベント毎要求受入管理テーブル４４４において、イベント種別と、通知手法とを対応付けて保持している。当該イベント毎要求受入管理テーブル４４４に従って、イベントリクエスト管理テーブル４４２のレコードが登録されるので、イベント種別毎に効果的な通知を行うことができる。

また、複合機１で、ユニキャストで通知を行う際に、イベント種別に応じてＵＤＰかＴＣＰか選択することができる。これにより、通知手法に自由度を持たせることを可能とすると共に、イベント毎に効果的な通知を行うことが可能となる。

また、クライアントがイベント監視リクエストにおいて、イベント発生時の通知方法としてユニキャストかマルチキャストかを指定することで、複合機１で当該指定に基づいて、イベントリクエスト管理テーブル４４２の登録が行われる。これにより、クライアント側で通知手法の設定に自由度を持たせることができる。

その際、複合機１で、クライアントに指定された通知方法を受け入れるかどうかを判断することで、クライアント側で通知手法の設定に自由度を持たせることができると共にリクエスト側の優先度付けを行うことができる。

実施の形態にかかる複合機およびネットワークを介して複合機を利用する端末により構成されるシステムの一例を示す図である。 実施の形態にかかる複合機のハードウェア構成例を示す図である。 実施の形態にかかる複合機のソフトウェア構成例を示す図である。 実施の形態にかかる複合機においてイベント通知に用いるアプリケーション部、ＳＯＡＰ／ＸＭＬ処理部、ネットワーク制御部、及び記憶部及びＩ／Ｆ部の構成例を示す図である。 実施の形態にかかるイベントリクエスト管理テーブルのテーブル構造を示す図である。 実施の形態にかかる通知管理テーブルのテーブル構造を示す図である。 実施の形態にかかるＩＰアドレス毎要求受入管理テーブルのテーブル構造を示す図である。 実施の形態にかかるイベント毎要求受入管理テーブルのテーブル構造を示す図である。 クライアントが送信する、イベント通知を要求するSubscribeメッセージの第１例を示した図である。 実施の形態にかかる複合機が送信する、図９のSubscribeメッセージに対応する応答メッセージの例を示した図である。 クライアントが送信する、イベント通知を要求するSubscribeメッセージの第１例を示した図である。 実施の形態にかかる複合機が送信する、図１１のSubscribeメッセージに対応する応答メッセージの例を示した図である。 実施の形態にかかる複合機が送信する、図１１のSubscribeの要求に対してＮＧであることを表す応答メッセージの例を示した図である。 イベント通知部が通知するPrinterStatusEventのイベント通知の例を示す図である。 イベント通知部が通知するJobStatusEventのイベント通知の例を示す図である。 複合機がクライアントからSubscribeメッセージまたはRenewメッセージを受信した場合に行われるデータの送受信のシーケンスを示す図である。 複合機におけるイベント発生監視動作シーケンス及び検出したイベントをマルチキャストで通知する一例を示す図である。 複合機におけるイベント発生監視動作シーケンス及び検出したイベントをユニキャストで通知する一例を示す図である。 複合機が終了する際に、終了通知をマルチキャストでクライアントに通知する一例を示す図である。 本実施の形態にかかる複合機でSubscribe又はRenewメッセージを受信した場合の処理の手順を示すフローチャートである。

符号の説明

１ 複合機
１１ ＣＰＵ
１２ システムメモリ
１３ ノースブリッジ（ＮＢ）
１４ サウスブリッジ（ＳＢ）
１５ ＡＳＩＣ
１６ 記憶部
１７ Ｉ／Ｆ部
４１ オペレーションパネル
４２ ＦＣＵ
４３ エンジン部
３０１ プラットフォーム部
３０２ ＳＯＡＰ／ＸＭＬ処理部
３０３ アプリケーション部
３１１ コピーアプリ
３１２ ファックスアプリ
３１３ スキャナアプリ
３１４ ネットファイルアプリ
３１５ プリンタアプリ
３２１ ＯＳ／Ｋｅｒｎｅｌ
３２２ システム制御部
３２３ メモリ制御部
３２４ エンジン制御部
３２５ セキュリティ制御部
３２６ 配信制御部
３２７ オペレーション制御部
３２８ ネットワーク制御部
３２９ ファックス制御部
３３１ セキュアデバイス
３３６ ＧＳＴＮ＿Ｉ／Ｆ
４１１ 全体制御部
４１２ プロトコル制御部
４１３ WS-Eventing処理部
４１４ イベント管理部
４１５ 通信部
４１６ ＨＴＴＰ制御部
４２１ 受信部
４２２ 選択部
４２３ イベント通知部
４３１ イベント監視部
４３２ 登録部
４４１ アドレス毎要求受入管理テーブル
４４２ イベントリクエスト管理テーブル
４４３ 通知管理テーブル
４４４ イベント毎要求受入管理テーブル
４５１ 情報通信部
４５２ イベント検出部
４５３ アプリケーション制御部

Claims (13)

1. クライアント装置とネットワークを介して接続されたイベント通知装置であって、
   各前記クライアント装置から、監視を要求するイベント種別を含むメッセージである監視イベント指定メッセージを受信する受信手段と、
   自装置においてイベントが発生したか否かを監視するイベント監視手段と、
   イベント種別と、当該イベント種別で示されたイベントが発生した場合にクライアント装置に対して通知する通知手法と、を対応付けて記憶する通知管理記憶手段と、
   前記イベント監視手段が前記イベントの発生を検出した際、発生したイベント種別が前記監視イベント指定メッセージで複数の前記クライアント装置から監視を要求されていた場合に、当該複数のクライアントに対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてマルチキャストと対応付けられている場合に、ネットワークを介して接続された複数のクライアント装置に対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてユニキャストと対応付けられている場合に、当該イベントを監視する所定のクライアント装置にユニキャストで通知するイベント通知手段と、
   を備えたことを特徴とするイベント通知装置。
2. 前記イベント通知手段は、さらに、イベントの発生を通知する際にＵＤＰを用い、イベントの完了を通知する際にＴＣＰを用いる、
   ことを特徴とする請求項１に記載のイベント通知装置。
3. 前記監視イベント指定メッセージを前記受信手段が受信した場合に、前記監視イベント指定メッセージに対応するレスポンスを、前記監視イベント指定メッセージの送信した前記クライアント装置に対して送信する送信手段を、
   さらに備えることを特徴とする請求項１又は２に記載のイベント通知装置。
4. 前記受信手段が受信した前記監視イベント指定メッセージの送信元を表すアドレス情報と、検出対象となるイベントと、当該クライアントに対する通知手法としてマルチキャスト又はユニキャストを保持する通知手法と、を対応付けて記憶する記憶手段をさらに備え、
   前記イベント通知手段は、前記イベント監視手段が前記イベントの発生を検出した場合に、当該イベントと前記記憶手段で対応付けられているアドレス情報に対する通知手法に、当該イベントと対応付けられている通知手法で通知すること、
   を特徴とする請求項１乃至３のいずれか一つに記載のイベント通知装置。
5. アドレス情報と、当該アドレス情報に対して予め設定された通知手法と、を対応付けて記憶するアドレス管理記憶手段と、
   前記受信手段が前記監視イベント指定メッセージを受信した場合に、前記記憶部に対して、前記監視イベント指定メッセージの送信元のアドレス情報と、前記監視イベント指定メッセージで監視が要求されたイベントと、当該アドレス情報と前記アドレス管理記憶手段で対応付けられた前記通知手法と、を対応付けて登録する登録手段と、
   をさらに備えることを特徴とする請求項４に記載のイベント通知装置。
6. イベントと、当該アドレス情報に対して予め設定された通知手法と、を対応付けて記憶するイベント管理記憶手段と、
   前記受信手段が前記監視イベント指定メッセージを受信した場合に、前記記憶部に対して、前記監視イベント指定メッセージの送信元のアドレス情報と、前記監視イベント指定メッセージで監視が要求されたイベントと、当該イベントと前記イベント管理記憶手段で対応付けられた前記通知手法と、を対応付けて登録する登録手段と、
   をさらに備えることを特徴とする請求項４に記載のイベント通知装置。
7. 前記イベント通知手段は、イベント通知装置の終了処理が行われる場合、前記記憶部に記憶されている全てのアドレス情報を含めて、マルチキャストで、自装置が終了することを通知すること、
   を特徴とする請求項４乃至６のいずれか一つに記載のイベント通知装置。
8. 前記イベント通知手段は、WS―Eventingプロトコルを用いて通知すること、
   を特徴とする請求項１乃至７のいずれか一つに記載のイベント通知装置。
9. イベント通知装置で実行されるイベント通知方法であって、
   前記イベント通知装置が、イベント種別と、当該イベント種別で示されたイベントが発生した場合にクライアント装置に対して通知する通知手法と、を対応付けて記憶する通知管理記憶手段を備え、
   受信手段が、ネットワークを開始して接続された各クライアント装置から、監視を要求するイベント種別を含むメッセージである監視イベント指定メッセージを受信する受信ステップと、
   監視手段が、自装置においてイベントが発生したか否かを監視するイベント監視ステップと、
   イベント通知手段が、前記イベント監視ステップが前記イベントの発生を検出した際、発生したイベント種別が前記監視イベント指定メッセージで複数の前記クライアント装置から監視を要求されていた場合に、当該複数のクライアントに対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてマルチキャストと対応付けられている場合に、ネットワークを介して接続された複数のクライアント装置に対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてユニキャストと対応付けられている場合に、当該イベントを監視する所定のクライアント装置にユニキャストで通知するイベント通知ステップと、
   を有することを特徴とするイベント通知方法。
10. 前記イベント通知ステップは、さらに、イベントの発生を通知する際にＵＤＰを用い、イベントの完了を通知する際にＴＣＰを用いる、
    ことを特徴とする請求項９に記載のイベント通知方法。
11. 送信手段が、前記監視イベント指定メッセージを前記受信ステップが受信した場合に、前記監視イベント指定メッセージに対応するレスポンスを、前記監視イベント指定メッセージの送信した前記クライアント装置に対して送信する送信ステップを、さらに有することを特徴とする請求項９又は１０に記載のイベント通知方法。
12. 前記イベント通知装置が、前記受信ステップにより受信した前記監視イベント指定メッセージの送信元を表すアドレス情報と、検出対象となるイベントと、当該クライアントに対する通知手法としてマルチキャスト又はユニキャストを保持する通知手法と、を対応付けて記憶する記憶部を、さらに備え、
    前記イベント通知ステップは、前記イベント監視ステップが前記イベントの発生を検出した場合に、当該イベントと前記記憶手段で対応付けられているアドレス情報に対する通知手法に、当該イベントと対応付けられている通知手法で通知すること、
    を特徴とする請求項１１に記載のイベント通知方法。
13. コンピュータが、イベント種別と、当該イベント種別で示されたイベントが発生した場合にクライアント装置に対して通知する通知手法と、を対応付けて記憶する通知管理記憶手段を備え、
    各前記クライアント装置から、監視を要求するイベント種別を含むメッセージである監視イベント指定メッセージを受信する受信手段と、
    自装置においてイベントが発生したか否かを監視するイベント監視手段と、
    前記イベント監視手段が前記イベントの発生を検出した際、発生したイベント種別が前記監視イベント指定メッセージで複数の前記クライアント装置から監視を要求されていた場合に、当該複数のクライアントに対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてマルチキャストと対応付けられている場合に、ネットワークを介して接続された複数のクライアント装置に対して検出されたイベントをマルチキャストで通知し、発生したイベント種別が前記通知管理記憶手段で通知手法としてユニキャストと対応付けられている場合に、当該イベントを監視する所定のクライアント装置にユニキャストで通知するイベント通知手段と、
    して機能させるイベント通知プログラム。

Images