JP4850761B2 - イベント通知装置及びイベント通知方法 - Google Patents

Description

本発明は、ネットワークなどを介して他の機器に、発生したイベントを通知するイベント通知装置及びイベント通知方法に関するものである。

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

ところで、ある特定の画像処理装置を多数のユーザが利用する場合、発生したイベントの内容を各ユーザに対して一斉に通知するため、イベント送信を要求するユーザの登録数が多いと、あるイベントが発生した際に、その通知をするためにより多くの時間を要する。

しかしながら、イベントの種類によっては、すべてのイベント監視先に通知を行う必要はない。そこで、通知するイベント（ジョブ）設定する技術としては特許文献１に記載された技術がある。この特許文献１に記載された技術では、ユーザの側のドライバに対して設定を行うことで、通知するジョブを設定することを可能としている。

特開２００６−７２５６８号公報

しかしながら、特許文献１に記載された技術は、ユーザのドライバに対して設定を行うものであって、イベントを通知する機器側に対して通知を行うものではない。つまり、特許文献１に記載された技術は、利用者の要求に応じて通知するイベントを変更するものであり、通知をするためにより多くの時間を要するという問題を解消するための技術ではない。

本発明は、上記に鑑みてなされたものであって、通知を行うための処理負担を軽減するイベント通知装置及びイベント通知方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、ネットワークを介して接続された通信装置から、イベントが発生した場合にイベントの送信の要求を受信する受信手段と、イベントの種類と、前記受信手段が受信した前記イベントの送信を要求した通信装置を示すイベント送信先のうち所定のイベント送信先に対してのみ送信する又はイベント送信先全てに送信するかを示す送信判断情報と、を対応付けたイベント送信判断情報を記憶する記憶手段と、自装置においてイベントが発生したか否かを監視するイベント監視手段と、前記イベント監視手段が前記イベントの発生を検出した場合に、検出した前記イベントの種類と、前記イベント送信判断情報において対応付けられた前記送信判断情報に基づいて、前記所定のイベント送信先に対してのみ送信する又はイベント送信先全てに送信するかを判断し、前記所定のイベント送信先のみ送信すると判断された場合にさらに前記イベント送信先の数が所定の閾値を超えたか否かを判断し、当該所定の閾値を超えた場合に前記所定のイベント送信先に対してのみに送信し、当該所定の閾値を超えなかった場合に前記イベント送信先全てに送信すると判断する判断手段と、前記判断手段により前記所定のイベント送信先に送信すると判断された場合に、当該検出された前記イベントを前記所定のイベント送信先にのみに通知し、前記判断手段により前記イベント送信先全てに送信すると判断された場合に、当該検出された前記イベントを前記イベント送信先全てに通知するイベント通知手段と、を備えることを特徴とする。

また、請求項２にかかる発明は、請求項１にかかる発明において、前記記憶手段が記憶する前記イベント送信判断情報において、前記イベントの種類と対応付けられた前記送信判断情報に対して、イベントの送信先のうち前記所定のイベント送信先に対してのみ送信するか否かを設定する設定手段を、さらに備えることを特徴とする。

また、請求項３にかかる発明は、請求項１又は２にかかる発明において、検出したイベントの種類にかかわらずイベントを送信する前記所定のイベント送信先を記憶する記憶手段をさらに備え、前記イベント通知手段は、前記判断手段の判断結果と関係なく、所定の通信プロトコルを用いて、当該検出されたイベントを前記所定のイベント送信先に通知すること、を特徴とする。

また、請求項４にかかる発明は、請求項１乃至３のいずれか一つにかかる発明において、前記イベント通知手段は、通知する際に通信プロトコルとして、WS-Eventingプロトコルを用いること、を特徴とする。

また、請求項５にかかる発明は、イベントの種類と、ネットワークを介してイベントの送信を要求した通信装置を示すイベント送信先のうち所定のイベント送信先に対してのみ送信するか否かを示す送信判断情報と、を対応付けたイベント送信判断情報を記憶する記憶手段を備えるイベント通知装置におけるイベント通知方法であって、前記通信装置から、イベントが発生した場合にイベントの送信の要求を受信する受信ステップと、自装置においてイベントが発生したか否かを監視するイベント監視ステップと、前記イベント監視ステップが前記イベントの発生を検出した場合に、検出した前記イベントの種類と、前記イベント送信判断情報において対応付けられた前記送信判断情報に基づいて、前記所定のイベント送信先に対してのみ送信する又はイベント送信先全てに送信するかを判断し、前記所定のイベント送信先のみ送信すると判断された場合にさらに前記イベント送信先の数が所定の閾値を超えたか否かを判断し、当該所定の閾値を超えた場合に前記所定のイベント送信先に対してのみに送信し、当該所定の閾値を超えなかった場合に前記イベント送信先全てに送信すると判断する判断ステップと、前記判断ステップにより前記所定のイベント送信先に送信すると判断された場合に、当該検出された前記イベントを前記所定のイベント送信先にのみ通知し、前記判断ステップにより前記イベント送信先全てに送信すると判断された場合に、当該検出された前記イベントを前記イベント送信先全てに通知するイベント通知ステップと、を有することを特徴とする。

また、請求項６にかかる発明は、請求項５にかかる発明において、前記イベント通知ステップは、通知する際に通通信プロトコルとして、WS-Eventingプロトコルを用いること、を特徴とする。

本発明によれば、所定のイベント送信先に限り送信するので、通知を行うための処理負担を軽減するという効果を奏する。

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

本発明の一実施の形態として、イベント通知装置であってコピー機能、ファクシミリ（ＦＡＸ）機能、プリント機能、スキャナ機能及び入力画像（スキャナ機能による読み取り原稿画像やプリンタあるいはＦＡＸ機能により入力された画像）を配信する機能等を複合したいわゆるＭＦＰ（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（登録商標）Ｉ／Ｆ３１などのネットワークインタフェイスと接続され、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供し、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分け、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。

エンジン制御部３２４は、複合機１が備えるプロッタエンジン等を制御する。セキュリティ制御部３２５は、複合機１に対するログイン等のセキュリティに関する制御を行う。オペレーション制御部３２７は、オペレーションパネル２の表示や、オペレーションパネル２に対して行われた入力処理等を制御する。ファックス制御部３２９は、複合機１が備えるファックス機能を制御する。

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

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

記憶部１６は、ＨＤＤ２２等の任意の記憶媒体においてイベントリクエスト管理テーブル４４２と、ＮＶＲＡＭ２４内において送信設定管理テーブル４４３と、イベント送信判断テーブル４４１と、特別指定監視先リスト４４４とを備える。

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

送信設定管理テーブル４４３は、イベントが発生した際に当該イベントの送信するために用いられる設定を管理している。図６は、送信設定管理テーブル４４３のテーブル構造を示す図である。図６に示すように、送信設定管理テーブル４４３は、イベントの通知先として全監視先又は特定監査先を示す情報と、イベントリクエスト数チェックをするか否か示す情報と、リクエスト数チェックする場合に用いられるイベントSubscribeリクエスト数の閾値と、特別指定監視先に送信するか否かを示す情報と、を保持している。

図７は、イベント送信判断テーブル４４１のテーブル構造を示す図である。図７に示すように、イベント送信判断テーブル４４１は、イベントの種類と、当該イベント種類のイベントが発生した場合にイベント通知を特定監視先、全監視先若しくは特別指定監視先のみ送信するのか否かを示す情報（以下、送信判断情報ともいう）を管理している。この特別指定監視先は、複合機１において指定される（利用者が指定する）固有の送信先とする。

また、特定監視先は、PrinterJobStatusやScannerJobStatusのようにＪｏｂをリクエストしたクライアントとする。なお、本実施の形態では、イベント種類をPrinterStatus等の粗い概念の例について説明しているが、トナー無しや紙無し等の詳細な概念毎にイベント種類を設定しても良い。

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

図８は、特別指定監視先リスト４４４のテーブル構造を示す図である。図８に示すように、特別指定監視先リスト４４４は、図６の送信設定管理テーブル４４３が保持する特別指定監視先に送信するか否かを示す情報が、特別指定監視先に送信する旨が設定されている場合において、イベントが発生した際に、当該イベントを必ず送信する特別指定監視先のリストを保持している。

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

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

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

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

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

イベント管理部４１４は、イベント監視部４３１と、判断部４３２と、設定部４３３とを備える。

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

判断部４３２は、イベント監視部４３１がイベントの発生を検出した場合に、イベントの通知を特定監視先に送信するのか、全ての監視先に送信するのかを、上述した様々なテーブルを用いて判断する。なお、詳細な処理手順については後述する。なお、全ての監視先とは、イベントリクエスト管理テーブル４４２に登録されている全てのイベントリクエスト元ＩＰアドレスを示すものとする。

設定部４３３は、複合機１のオペレーションパネル２からオペレーション制御部３２７を通じて、ＮＶＲＡＭ２７が保持する送信設定管理テーブル４４３と、イベント送信判断テーブル４４１と、特別指定監視先リスト４４４が保持する各フィールドに対して、様々な値を設定する。また、これら値は、ネットワーク制御部３２８を通じてクライアント等の外部装置から設定されることにしても良い。

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

そして、イベント監視部４３１は、アプリケーション部３０３の各アプリケーション（アプリ＃１，…）のイベント検出部４５２と、アプリ通信部４１５を介してデータの送受信を行うことで、各アプリケーションにおいてイベントが発生したか否かの監視を定期的に行う。そして、イベント監視部４３１がいずれかのアプリケーションにおいてイベント発生を検出した場合、判断部４３２が所定の処理を行った後、イベント通知部４２２がその旨を各クライアントへ通知する。なお、イベントが発生したか否かの監視動作の詳細およびイベント発生時の各クライアントへのイベント内容通知動作の詳細については後述する。

次に、本実施の形態にかかる複合機１の詳細動作について説明する。まず、各クライアントが複合機１からイベント発生時にその内容の通知を受けるために必要な動作である、複合機１に対する初期設定動作について説明する。本実施の形態では、各クライアントが複合機１に対して、発生したイベントを通知するように要求する。なお、本実施の形態では、WS-Eventingプロトコルを使用する例とする。

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

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

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

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

図１０に示すレスポンスメッセージは、「Subscribeメッセージで指示されたイベントが発生（検知）した場合、Expiresフィールドに示された有効期限が到来するまでの間、その内容（発生したイベント）を通知する」ということを示している。これ以後、原則としてExpiresフィールドに示された有効期限が到来するまで、複合機１は、上記Subscribeメッセージで指示されたイベントを検知した場合、その内容を上記SubscribeResponseメッセージの送信先のクライアントに通知する。

図１１は、イベント通知を要求するSubscribeメッセージの一例を示したものである。符号１１０１で示した行により、Subscribeメッセージであることが確認できる。そして符号１１０２に示された行（Dialect）は、「"PrinterJobStatusEvent"が示すイベントについてStatusが変化したら（イベントが発生したら）通知をしてほしい」旨を示している。なお、図９と図１１とに示された内容（Filter中のDialect）がひとつのSubscribeメッセージで記載されることもある。

また、上記SubscribeResponseメッセージを受信したクライアントは、当該受信したメッセージに示された上記有効期限が到来後も引き続いてイベントの通知を受けたい場合、図１２に示す内容のメッセージを複合機１に対して送信する。図１２は、クライアントが送信するRenewメッセージの例を示した図である。図１２に示すメッセージは、通常、クライアントが複合機１からイベント通知を受け付けている場合に送信される。符号１２０１で示した行により、Renewメッセージであることが確認できる。

また、図１２に示すメッセージは、「（それ以前に受信したSubscribeResponseメッセージなどに含まれるExpiresフィールドに示された）有効期限が到来後も引き続いて、発生したイベントを通知してほしい」ことを示している。このRenewのメッセージは、SubscribeResponseのExpiresに設定されている有効期限が経過する前にクライアントが送信する。

Renewメッセージを受信すると、複合機１は、SubscribeResponseで指定されたSubscribeIDに対して、有効期限の更新を行う。

その後、複合機１は、例えば図１３に示す内容のメッセージを、クライアントに対して送信する。図１３は、複合機１がクライアントに対して、Renewメッセージに対して送信するレスポンス（RenewResponse）メッセージの例を示した図である。図１３に示したレスポンス（RenewResponse）メッセージは、Renewメッセージを正常に受け付けた場合に送信されるものである。

また、図１３に示すレスポンスメッセージは、「Expiresフィールドに示された有効期限が到来するまでの間、発生（検知）したイベントを通知する」ということを示している。すなわち、更新された有効期限がExpiresフィールド（符号１３０２）に示される。

そして、複合機１は、Subscribeメッセージやrenewメッセージにより受け付けたイベントの発生を検出した場合に、イベント通知部４２２からクライアントに対してイベント通知が行われる。

図１４は、イベント通知部４２２が通知するPrinterStatusEventReportメッセージの例を示す図である。複合機１は、これらメッセージを受け付けた際に設定された有効期限が到来するまでに発生したイベントを、当該PrinterStatusEventReportメッセージとして通知する。なお、符号１４０１で示した行により、PrinterStatusEventReportメッセージであることが確認できる。

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

また、図７のイベント送信判断テーブル４４１に示されるように、PrinterStatusは、送信判断情報において全監視先と設定されている。このため、図１４に示したメッセージは、イベント種類に拘わらず、イベントリクエスト管理テーブル４４２に登録されている全てのイベントリクエスト元ＩＰアドレスに対して送信される。つまり、複合機１は、クライアントからSubscribeResponseメッセージ又はRenewResponseメッセージを受け取ることで、PrinterStatusに関するイベントの監視を開始するが、当該イベントが発生した場合、上記メッセージを送信したクライアントだけではなく、他に複合機１を監視しているクライアントに対して、当該メッセージが送信される。

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

図１５は、イベント通知部４２２が通知するPrinterJobStatusEventReportメッセージの例を示す図である。複合機１は、これらメッセージを受け付けた際に設定された有効期限が到来するまでに発生したイベントを、当該PrinterJobStatusEventReportメッセージとして通知する。なお、符号１５０１で示した行により、PrinterJobStatusEventReportメッセージであることが確認できる。

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

また、図７のイベント送信判断テーブル４４１に示されるように、PrinterStatusは、送信判断情報において特定監視先と設定されている。このため、図１５に示したメッセージは、イベントリクエスト管理テーブル４４２に登録されているイベントリクエスト元ＩＰアドレスのうち、イベント種類が“PrinterJobStatus”と対応付けられているイベントリクエスト元ＩＰアドレスに対して送信される。つまり、複合機１は、受け付けたリクエスト数が閾値以上の場合に、イベント種類が“PrinterJobStatus”のSubscribeResponseメッセージ又はRenewResponseメッセージを送信したクライアントに対して、当該メッセージを送信する。

次に、複合機１とクライアントとの間で行われる処理について説明する。図１６は、複合機１とクライアントであるＰＣ−Ａ２との間で、印刷ジョブイベントの監視リクエスト(Subscribe)を受け付けてから、印刷完了イベントが通知されるまでに送受信されるデータのフローを示した図である。

図１６に示すように、まず、ＰＣ−Ａ２は、印刷ジョブに関するイベントを監視するために、印刷ジョブイベントの監視リクエスト（Subscribe）を、複合機１に対して通知する（ステップＳ１６０１）。この監視リクエストは、図１１で示すようなメッセージとする。

そして、複合機１は、当該監視リクエスト（Subscribe）を正常に受け付けた場合、管理クエスト(Subscribe)を了承する旨のレスポンスメッセージを、ＰＣ−Ａ２に対して送信する。このレスポンスメッセージは、図１０で示すようなメッセージとする。

次に、ＰＣ−Ａ２は、複合機１に対して、印刷処理を要求するために印刷ジョブリクエストを送信する（ステップＳ１６０３）。

そして、複合機１は、当該印刷ジョブリクエストを受け付けた場合に、印刷可能であれば、リクエストに了承する旨のメッセージをＰＣ−Ａ２に対して送信する（ステップＳ１６０４）。

これにより、ＰＣ−Ａ２は、複合機１に対して印刷ジョブデータを送信する（ステップＳ１６０５）。これにより、複合機１は、送信されてきた印刷ジョブデータを受信する（ステップＳ１６０６）。そして、複合機１は、全ての印刷ジョブデータの受信が完了した場合に、データがＯＫだった旨を、ＰＣ−Ａ２に対して送信する（ステップＳ１６０７）。

その後、複合機１では、受信した印刷ジョブデータに基づいて印刷処理を行う（ステップＳ１６０８）。

そして、複合機１は、印刷処理が完了した場合にその旨の印刷ジョブに関するイベントを検出する。そこで、複合機１は、印刷ジョブの監視リクエストを送信してきたＰＣ−Ａ２を含めクライアントに対して、印刷完了イベントを通知する（ステップＳ１６０９）。

図１７は、複合機１がクライアントから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メッセージを送信する。

図１８は、複合機１におけるイベント発生監視動作シーケンス及び検出したイベントの通知動作の一例を示す図である。

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

なお、図１８に示した処理手順の例では、説明を容易にするためにイベント管理部４１４が、一つのアプリケーション（アプリ♯Ｎ）のイベント検出部４５２に対してのみ問い合わせを行っている。しかしながら、実際にはアプリケーション部３０３の全てのアプリケーションに対して問い合わせを行っているものとする。また、イベント管理部４１４と各アプリケーションのイベント検出部４５２は、アプリ通信部４１５及び情報通信部４５１を介して通信が行われている。

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

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

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

次に、ＨＴＴＰ制御部４１６のイベント通知部４２２は、WS-Eventing処理部４１３から入力されたメッセージ（例えば、図１４に示すPrinterStatusEventReportメッセージ又は図１５に示すPrinterJobStatusEventReportメッセージ）を、ＰＣ−Ａ２に対して送信する（ステップＳ１８１０）。

図１８に示す例では、イベントが発生した旨のメッセージをNotificationメッセージとして表現している。通常、クライアント（ＰＣ−Ａ２）は、受信したメッセージに対する応答メッセージ(図１８に示す例ではHTTP 200 Response)を返信する（ステップＳ１８１１）。

なお、図１８のステップＳ１８１０で送信されるメッセージは、イベントの種類に応じて送信先が異なることになる。次に、イベントの種類に応じて設定される送信先について説明する。

次に、以上のように構成された本実施の形態にかかるイベント通知部４２２におけるイベント通知を行うまでの処理について説明する。図１９は、本実施の形態にかかるイベント通知部４２２における上述した処理の手順を示すフローチャートである。なお、送信するためのメッセージは既に生成されているものとする。

まず、イベント通知部４２２は、送信設定管理テーブル４４３が保持している特別指定監視先に送信するか否かを示す情報を参照して、特別指定監視先に送信するか否かを判断する（ステップＳ２００１）。特別指定監視先に送信しないと判断した場合（ステップＳ２００１：Ｎｏ）、特別指定監視先に関する処理は特に行わない。

そして、イベント通知部４２２が、特別指定監視先に送信すると判断した場合（ステップＳ２００１：Ｙｅｓ）、必ず特別指定監視先に通知（Notification）を行う（ステップＳ２００２）。

そして、イベント通知部４２２は、送信設定管理テーブル４４３が保持しているイベントリクエスト数チェックをするか否か示す情報を参照してリクエスト数チェックを行うか否か判断する（ステップＳ２００３）。

そして、イベント通知部４２２は、リクエスト数チェックすると判断した場合（ステップＳ２００３：Ｙｅｓ）、イベントリクエスト管理テーブル４４２に格納されているイベント数が、送信設定監視テーブルのイベントSubscribeリクエスト数の閾値より大きいか否か判断する（ステップＳ２００４）。

次に、イベント通知部４２２は、リクエスト数チェックを行わないと判断した場合（ステップＳ２００３：Ｎｏ）、又はイベント数が閾値より大きいと判断した場合（ステップＳ２００４：Ｙｅｓ）、イベント送信判断テーブル４４１を参照し、当該イベント送信判断テーブル４４１において発生したイベントの種類と対応付けられている送信先から、イベント通知の送信先を特定監視先のみ通知するか否かを判断する（ステップＳ２００５）。

そして、イベント通知部４２２は、特定監視先のみ通知すると判断した場合（ステップＳ２００５：Ｙｅｓ）、特定監視先のみイベント通知を行う（ステップＳ２００６）。この特定監視先は、発生したイベントの種類に応じて異なる。図７のイベント送信判断テーブル４４１に格納されている値のように、特定のＩＰアドレス（例えば192.168.2.56）のみ送信でもよいし、ジョブ関連イベントの場合はジョブをリクエストしたクライアントのみ送信しても良い。

また、イベント通知部４２２は、イベント数が閾値より小さいと判断した場合（ステップＳ２００４：Ｎｏ）、又は特定監視先のみ通知するものではないと判断した場合（ステップＳ２００５：Ｎｏ）、全ての監視先に対してイベント通知を行う（ステップＳ２００７）。

上述した実施の形態にかかる複合機１では、発生したイベントの種類に応じて特定のイベント監視先にのみ通知することができる。また、複合機１では、特定のイベント監視先かすべてのイベント監視先に通知させるかの設定を行うこともできる。イベント監視リクエストの数によりイベント通知を制御することもできる。この場合においても、特定の監視先に対しては必ず通知することもできる。

また、複合機１は、このような処理を行うことで、当該イベント通知が必要なクライアントに対してはイベント通知を行うと共に、イベント通知が必要のないクライアントに対してイベント通知を行わないので、処理負担を軽減すると共に、イベント通知において遅延が生じるのを防ぐことができる。

本実施の形態にかかる複合機１では、イベント監視リクエストをクライアント（イベントの監視先）から受け付け、当該リクエストに従ってイベントの発生を監視し、イベントが発生した場合に、クライアントにイベントを通知する際に、発生したイベント種類に基づいて、イベント通知を特定監視先のみ送信するのか、全ての監視先に送信するのか切り替えることで、イベント通知の必要な監視先には必ず通知を行うと共に、不要なイベント通知は行わないことになるので、不要なパケットの送信を抑えられる。

また、イベント送信判断テーブルのレコード情報を変更することで、イベントの種類と対応付けられたイベント通知先を、特定のイベント監視先かすべてのイベント監視先かを変更することができるので、利用者の要求に応じて通知先をカスタマイズすることができる。

また、複合機１の送信設定管理テーブル４４３又はイベント送信判断テーブル４４１のレコード情報変更することで、すべてのイベント監視先が機器のすべてのイベントを監視するように設定することできるし、不要なパケットを送らないように設定することもできる。

また、送信設定管理テーブル４４３のリクエスト数を変更することで、イベントの通知の数をカスタマイズすることができる。これにより、イベント監視先と、複合機１及びネットワークにかかる処理負担等を考慮して、適切に送信先の数を設定することができる。

また、特別指定監視先に予めＩＰアドレスを設定しておくことで、管理ＰＣ等に対して、必ずすべてのイベントを通知することができる。このように利用者の要求に応じて様々なカスタマイズを行うことができる。

なお、本実施形態の複合機１で実行されるイベント通知プログラムは、ＲＯＭ等に予め組み込まれて提供される。

本実施形態の複合機１で実行されるイベント通知プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

さらに、本実施形態の複合機１で実行されるイベント通知プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の複合機１で実行されるイベント通知プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

本実施の形態の複合機１で実行されるイベント通知プログラムは、上述したネットワーク制御部３２８に含まれる各部を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記ＲＯＭからイベント通知プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、ネットワーク制御部３２８に含まれる各部が主記憶装置上に生成されるようになっている。

以上のように、本発明にかかるイベント通知装置及びイベント通知方法は、ネットワークを介してイベントを通知する技術に有用であり、特に、イベントを通知する際に不要なパケットの送信を抑える技術に適している。

実施の形態にかかる複合機およびネットワークを介して複合機を利用する端末により構成されるシステムの一例を示す図である。 実施の形態にかかる複合機のハードウェア構成例を示す図である。 実施の形態にかかる複合機のソフトウェア構成例を示す図である。 実施の形態にかかる複合機においてイベント通知に用いるアプリケーション部、ＳＯＡＰ／ＸＭＬ処理部、ネットワーク制御部、及び記憶部及びＩ／Ｆ部の構成例を示す図である。 実施の形態にかかるイベントリクエスト管理テーブルのテーブル構造を示す図である。 実施の形態にかかる送信設定管理テーブルのテーブル構造を示す図である。 実施の形態にかかるイベント送信判断テーブルのテーブル構造を示す図である。 実施の形態にかかる特別指定監視先リストのテーブル構造を示す図である。 実施の形態にかかるクライアントが複合機に対して送信する、イベントを通知するよう要求するメッセージの例を示した図である。 実施の形態にかかる複合機が送信する応答メッセージの例を示した図である。 イベント通知を要求するSubscribeメッセージの一例を示した図である。 クライアントが送信するRenewメッセージの例を示した図である。 複合機がクライアントに対して、Renewメッセージに対して送信するレスポンス（RenewResponse）メッセージの例を示した図である。 イベント通知部が通知するPrinterStatusEventReportメッセージの例を示す図である。 イベント通知部が通知するPrinterJobStatusEventReportメッセージの例を示す図である。 複合機とクライアントであるＰＣ−Ａとの間で、印刷ジョブイベントの監視リクエスト(Subscribe)を受け付けてから、印刷完了イベントが通知されるまでに送受信されるデータのフローを示した図である。 複合機がクライアントからSubscribeメッセージまたはRenewメッセージを受信するシーケンスを示す図である。 複合機におけるイベント発生監視動作シーケンス及び検出したイベントの通知動作の一例を示す図である。 本実施の形態にかかるイベント通知部におけるイベント通知を行うまでの処理の手順を示すフローチャートである。

符号の説明

１ 複合機
２ オペレーションパネル
３ ＦＣＵ
４ エンジン部
１１ ＣＰＵ
１２ システムメモリ
１３ ノースブリッジ（ＮＢ）
１４ サウスブリッジ（ＳＢ）
１５ ＡＳＩＣ
１６ 記憶部
１７ Ｉ／Ｆ部
３０１ プラットフォーム部
３０２ ＳＯＡＰ／ＸＭＬ処理部
３０３ アプリケーション部
３２２ システム制御部
３２３ メモリ制御部
３２４ エンジン制御部
３２５ セキュリティ制御部
３２６ 配信制御部
３２７ オペレーション制御部
３２８ ネットワーク制御部
３２９ ファックス制御部
４１１ 全体制御部
４１２ プロトコル制御部
４１３ WS-Eventing処理部
４１４ イベント管理部
４１５ アプリ通信部
４１６ ＨＴＴＰ制御部
４２１ リクエスト受信部
４２２ イベント通知部
４３１ イベント監視部
４３２ 判断部
４３３ 設定部
４４１ イベント送信判断テーブル
４４２ イベントリクエスト管理テーブル
４４３ 送信設定管理テーブル
４４４ 特別指定監視先リスト
４５１ 情報通信部
４５２ イベント検出部
４５３ アプリケーション制御部

Claims (6)

1. ネットワークを介して接続された通信装置から、イベントが発生した場合にイベントの送信の要求を受信する受信手段と、
   イベントの種類と、前記受信手段が受信した前記イベントの送信を要求した通信装置を示すイベント送信先のうち所定のイベント送信先に対してのみ送信する又はイベント送信先全てに送信するかを示す送信判断情報と、を対応付けたイベント送信判断情報を記憶する記憶手段と、
   自装置においてイベントが発生したか否かを監視するイベント監視手段と、
   前記イベント監視手段が前記イベントの発生を検出した場合に、検出した前記イベントの種類と、前記イベント送信判断情報において対応付けられた前記送信判断情報に基づいて、前記所定のイベント送信先に対してのみ送信する又はイベント送信先全てに送信するかを判断し、前記所定のイベント送信先のみ送信すると判断された場合にさらに前記イベント送信先の数が所定の閾値を超えたか否かを判断し、当該所定の閾値を超えた場合に前記所定のイベント送信先に対してのみに送信し、当該所定の閾値を超えなかった場合に前記イベント送信先全てに送信すると判断する判断手段と、
   前記判断手段により前記所定のイベント送信先に送信すると判断された場合に、当該検出された前記イベントを前記所定のイベント送信先にのみに通知し、前記判断手段により前記イベント送信先全てに送信すると判断された場合に、当該検出された前記イベントを前記イベント送信先全てに通知するイベント通知手段と、
   を備えることを特徴とするイベント通知装置。
2. 前記記憶手段が記憶する前記イベント送信判断情報において、前記イベントの種類と対応付けられた前記送信判断情報に対して、前記イベントの送信先のうち前記所定のイベント送信先に対してのみ送信するか否かを設定する設定手段を、さらに備えることを特徴とする請求項１に記載のイベント通知装置。
3. 検出したイベントの種類にかかわらずイベントを送信する前記所定のイベント送信先を記憶する記憶手段をさらに備え、
   前記イベント通知手段は、前記判断手段の判断結果と関係なく、所定の通信プロトコルを用いて、当該検出されたイベントを前記所定のイベント送信先に通知すること、
   を特徴とする請求項１又は２に記載のイベント通知装置。
4. 前記イベント通知手段は、通知する際に通信プロトコルとして、WS-Eventingプロトコルを用いること、を特徴とする請求項１乃至３のいずれか一つに記載のイベント通知装置。
5. イベントの種類と、ネットワークを介してイベントの送信を要求した通信装置を示すイベント送信先のうち所定のイベント送信先に対してのみ送信するか否かを示す送信判断情報と、を対応付けたイベント送信判断情報を記憶する記憶手段を備えるイベント通知装置におけるイベント通知方法であって、
   前記通信装置から、イベントが発生した場合にイベントの送信の要求を受信する受信ステップと、
   自装置においてイベントが発生したか否かを監視するイベント監視ステップと、
   前記イベント監視ステップが前記イベントの発生を検出した場合に、検出した前記イベントの種類と、前記イベント送信判断情報において対応付けられた前記送信判断情報に基づいて、前記所定のイベント送信先に対してのみ送信する又はイベント送信先全てに送信するかを判断し、前記所定のイベント送信先のみ送信すると判断された場合にさらに前記イベント送信先の数が所定の閾値を超えたか否かを判断し、当該所定の閾値を超えた場合に前記所定のイベント送信先に対してのみに送信し、当該所定の閾値を超えなかった場合に前記イベント送信先全てに送信すると判断する判断ステップと、
   前記判断ステップにより前記所定のイベント送信先に送信すると判断された場合に、当該検出された前記イベントを前記所定のイベント送信先にのみ通知し、前記判断ステップにより前記イベント送信先全てに送信すると判断された場合に、当該検出された前記イベントを前記イベント送信先全てに通知するイベント通知ステップと、
   を有することを特徴とするイベント通知方法。
6. 前記イベント通知ステップは、通知する際に通信プロトコルとして、WS-Eventingプロトコルを用いること、を特徴とする請求項５のいずれか一つに記載のイベント通知方法。

Images