JP5537160B2 - イベント代行通知装置及びその制御方法とそのプログラム - Google Patents

Description

本発明は、イベントの通知を代行して行うイベント代行通知装置及びその制御方法とそのプログラムに関するものである。

ネットワーク技術の発展に伴い、ネットワークに接続される装置も多様化し、ネットワーク対応機器として従来のパーソナルコンピュータ（以下、ＰＣ）以外の多様な機器が開発されている。この結果、プリンタなどの画像形成装置や家電製品等に至るまで、ネットワーク対応化が急速に進められている。このように、ネットワークに存在する装置の種類が多様化してきているため、それらを利用する上での利便性、簡易性を高めるためのソフトウェアや技術が重要となってきている。

例えば、利用したいサービスを提供する装置を探索するソフトウェアや、依頼したジョブの処理状況や、構成情報の更新等の状態変化等のイベントを検知するソフトウェア等が知られている。その一例として、ＷＳＤ（Web Service on Devices)といった標準技術がある。このＷＳＤでは、ネットワークの装置を検索する際に、WS-Discoveryを使用している。またジョブの処理状況や、エラーステータス、構成情報の更新等のイベント通知技術にはWS-Eventingを使用している。これらにより、ネットワークに存在する多種多様な装置を発見でき、かつ各装置の状況をリアルタイムに把握することができ、空いているプリンタの効率的な利用や、故障時に、迅速で円滑なトラブル解決を行うことが可能となっている。

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

昨今は、ネットワークが大規模化し、ネットワークに存在するクライアント装置が益々増える傾向にある。ネットワークが大規模化することによりイベントを利用するクライアント装置の数が膨大になると、画像形成装置に代表されるイベントを通知する側の装置（以下、イベント通知装置）に大きな負荷がかかることになる。WS-Eventingのようなイベント通知のためのプロトコルでは、ＰＣ等のクライアント装置はイベント通知装置に対しイベントの通知要求のための登録（以下、イベント登録）を予め実行しなければならない。そしてイベント通知装置は、イベントが発生すると、イベント登録された全てのクライアント装置に対してイベントを通知しなければならない。このようなイベントの内、ジョブの実行に伴うステータスの変化に関連するイベントとして、ジョブ開始、ジョブ進捗、ジョブ完了、エラー等のイベント事象がある。これらイベントの発生を、イベント登録された全てのクライアント装置に通知するためには、ネットワークとの接続をクライアント装置毎に逐次確保する必要があり、これは極めて負荷の大きい処理となる。これにより、イベント通知装置におけるジョブ実行のパフォーマンスを著しく低下させてしまう等の問題が生じていた。

この問題を解決するために、特許文献１では、イベント通知先のクライアント装置の数に応じて、イベント通知装置におけるイベントの監視間隔を長くし、イベント通知処理の発生頻度を抑えイベント通知装置の負荷を軽減するようにしている。この特許文献１に記載の技術によれば、イベント通知装置の負荷を軽減することが可能である。しかし、イベント通知装置でイベントの監視間隔を長くするため、イベントの発生間隔が短いときには全てのイベントを通知できなくなるという問題がある。

特許文献２では、イベントの受信処理が可能な状態にあるクライアント装置に対してだけイベント通知することにより、無駄なイベント通知処理をなくし、イベント通知装置の負荷を軽減している。この特許文献２記載の技術によれば、イベント通知装置の負荷を軽減することが可能である。しかし、イベントの受信処理が可能なクライアント装置の数が多ければ、イベント通知装置の負荷は軽減されないという問題がある。

また特許文献３では、イベント登録時に、クライアント装置がイベント通知に用いる送信プロトコルを指定している。そしてイベント通知先として登録されているクライアント装置の数によって、ＴＣＰ等の処理の重い送信プロトコルを指定してきた場合はイベント登録を拒否している。特許文献３によれば、イベント通知装置の負荷を軽減できるが、イベント通知先のクライアント装置の数が制限されてしまうという問題がある。

本発明は上記従来技術の問題点を解決することにある。

本願発明の特徴は、イベント通知装置のイベント通知処理にかかる負荷を軽減し、クライアント装置に適切にイベントの通知を行う技術を提供することにある。

上記目的を達成するために本発明の一態様に係るイベント代行通知装置は以下のような構成を備える。即ち、
イベント通知装置からイベントの発行を受け取るとクライアント装置に当該イベントの発行を通知するイベント代行通知装置であって、
前記クライアント装置からのイベントの通知要求を受信すると、当該通知要求に含まれるイベントの種類、イベント通知装置及び前記クライアント装置に関する情報を登録する登録手段と、
イベント通知装置からイベントの発行を受け取ると、当該イベント通知装置、当該イベントの種類、及び当該イベントの通知を要求したクライアント装置が、前記登録手段によって登録されているかどうかを判定する判定手段と、
前記判定手段によって登録されていると判定された場合、前記イベントを前記登録手段によって登録されている前記クライアント装置に送信するイベント通知手段と、を有することを特徴とする

本発明によれば、イベント通知装置のイベント通知処理にかかる負荷が軽減される。

本発明の実施形態に係る通信システムの構成を示す図。 ＤＰ、クライアントＰＣのハードウェア構成を示すブロック図。 実施形態に係る画像形成装置のハードウェア構成を示すブロック図。 ＤＰ或いはクライアントＰＣが保持するデバイス情報管理テーブルの一例を示す図。 ハローメッセージ(hello message)の一例を示す図。 ＤＰがデバイス情報登録を行う際の処理を示すフローチャート。 Getメッセージの一例を示す図（Ａ）と、GetResponseメッセージの一例を示す図（Ｂ）。 クライアントＰＣのデバイスの検索処理の手順を示すフローチャート。 Probeメッセージの一例を示す図（Ａ）と、ProbeMatchメッセージの一例を示す図（Ｂ）。 ＤＰが、ＰＣからデバイス検索要求を受信したときの処理を示すフローチャート。 ProbeMatchメッセージの一例を示す図。 ＤＰが、ＰＣからGetメッセージを受信したときの処理を示すフローチャート。 ＤＰからＰＣに送信されるGetResponseメッセージの一例を示す図。 ＰＣ１１０、デバイス検索によって検索したデバイスに対して、イベント登録処理を行う手順を示すフローチャート（Ａ）と、ＰＣからＤＰに送信するSubscribeリクエストの一例を示す図（Ｂ）。 ＤＰが、ＰＣからSubscribeリクエストを受信してから画像形成装置にSubscribeリクエストを送信するまでの処理を示すフローチャート。 ＤＰが保持するデバイス管理テーブルの一例を示す図。 画像形成装置へ送信するSubscribeリクエストの一例を示す図。 イベントが発生したとき画像形成装置の処理手順を示すフローチャート。 ＤＰが、画像形成装置からイベントを受信してＰＣに当該イベントを転送するまでの処理を示すフローチャート。 実施形態２に係る画像形成装置がGetメッセージを受信してからGetResponseメッセージを送信するまでの処理を示すフローチャート。 実施形態３に係るＰＣが、イベント登録を行う処理の手順を示すフローチャートである。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

図１は、本発明の実施形態に係る通信システムの構成を示す図である。

ネットワーク１００には、画像形成装置１０１及び探索プロキシサーバ（以下、ＤＰ）１０２、クライアントＰＣ１１０が接続されている。このＤＰ１０２は、画像形成装置１０１でイベントが発生したことを、画像形成装置１０１に代わって通知するイベント代行通信装置として機能している。ネットワーク１００は、典型的にはＬＡＮにより構成されるが、ＷＡＮ等の他のネットワーク形態でもよい。

図２は、実施形態に係るＤＰ１０２、クライアントＰＣ１１０のハードウェア構成を示すブロック図である。尚、ＤＰ１０２、クライアントＰＣ１１０は基本的に同じ構成で、例えば汎用のＰＣ（パーソナルコンピュータ）を使用可能である。

図において、ＣＰＵ２０１はシステムバス２０４に接続された各種デバイスの制御を行う。ＲＯＭ２０２はＢＩＯＳやブートプログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１の主記憶装置として使用される。キーボードコントローラ（KBC）２０５は、マウス（登録商標）等のポインティングデバイス２０９ａ、キーボード２０９ｂからの情報などの入力に係る処理を行う。表示制御部（CRTC）２０６は、内部にビデオメモリを有し、ＣＰＵ２０１からの指示に従ってビデオメモリに描画すると共に、ビデオメモリに描画されたイメージデータをビデオ信号として表示部２１０に出力する。尚、表示部２１０は、ＣＲＴであっても液晶表示部であっても良く、表示部の種類は問わない。ディスクコントローラ（DKC）２０７は、ハードディスク(ＨＤ)２１１、フロッピー（登録商標）ディスク２１２へのアクセスを行う。ネットワークインタフェースカード（NIC）２０８は、ネットワーク１００に接続し、ネットワーク１００を介して情報通信を行う。尚、ＨＤ２１１には、ＯＳ（Operating System）やＯＳ上で動作する各種アプリケーションプログラム等が格納される。以上の構成において、この装置（ＤＰ１０２、クライアントＰＣ１１０）の電源がオンになると、ＣＰＵ２０１はＲＯＭ２０２に格納されたブートプログラムに従って、ＨＤ２１１からＯＳをＲＡＭ２０３に読み込み、情報処理装置として機能するようになる。またＯＳの制御の下でＨＤ２１１からＲＡＭ２０３にロードされたプログラムにより後述する処理が実行される。

図３は、実施形態に係る画像形成装置１０１のハードウェア構成を示すブロック図である。尚、ここでは、画像形成装置１０１が多機能処理装置（MFP）の場合を例にして説明する。

ＣＰＵ３０１は、ＲＯＭ３０３のプログラムＲＯＭに記憶された制御プログラムに基づいてシステムバス３０４に接続される各種のデバイスとのアクセスを総括的に制御する。また、印刷インターフェース３０７を介して接続される印刷部（プリンタエンジン）３１０に出力情報としての画像信号を出力したり、読取インターフェース３１２を介して接続される読取部（スキャナ）３１３から画像信号を入力する。またＲＯＭ３０３のプログラムＲＯＭは、ＣＰＵ３０１が実行可能な制御プログラム等が記憶する。更に、ＲＯＭ３０３のフォントＲＯＭには、プリンタエンジン３１０に出力する出力情報を生成する際に使用するフォントデータ（アウトラインフォントデータを含む）等が記憶されている。またＲＯＭ３０３のデータＲＯＭには、この画像形成装置１０１を使用するＰＣ等で利用される情報を記憶している。ＣＰＵ３０１はＬＡＮコントローラ３０６を介してネットワーク１００のＰＣなどとの通信処理が可能となっている。ＲＡＭ３０２は、主としてＣＰＵ３０１の主メモリ，ワークエリア等として機能し、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。尚、ＲＡＭ３０２は、上記出力情報の展開領域，環境データ格納領域等にも用いられる。外部記憶装置（ＨＤ）３１１は、ディスクコントローラ（DKC）３０８によりアクセスが制御される。ＨＤ３１１は、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶したり、プリントジョブを一時的にスプールし、スプールされたジョブを外部から制御するためのジョブ格納領域として使用される。また更に、スキャナ３１３で読み取った画像データやプリントジョブの画像データをＢＯＸデータとして保持し、ネットワーク１００から参照したり、印刷を行うＢＯＸデータの格納領域としても使用される。操作パネル３０５は、ユーザへのメッセージを表示したり、ユーザが各種情報を入力するのに使用される。不揮発性メモリ３０９は、操作パネル３０５を使用して設定される各種設定情報を記憶している。また、図示していないが、画像形成装置１０１には更に、オプションで、ステープルやソート機能を行うフィニッシャや、両面印刷機能を実現するための両面装置など各種拡張装置を装着でき、それらの動作はＣＰＵ３０１により制御される。

図４は、実施形態に係るＤＰ１０２或いはクライアントＰＣ１１０のＨＤ２１１が保持するデバイス情報管理テーブルの一例を示す図である。

このデバイス情報管理テーブルは、ＤＰ１０２、クライアントＰＣ１１０において、デバイス（画像形成装置等）に関する情報をレコードとして保持する。レコードはＩＤ４０１、ＵＵＩＤ４０２、バージョン４０３、デバイスタイプ４０４、モデル名４０５、デバイス名４０６、ＵＲＬ４０７、ＩＰアドレス４０８、ＸＭＬ保存パス４０９を含む。ＩＤ４０１は、デバイスを識別するためのＩＤ（識別情報）を示す。ＵＵＩＤ４０２は、デバイスをグローバルに識別するＵＵＩＤを示す。バージョン４０３は、デバイス情報のバージョンを示す。デバイスタイプ４０４は、複合機を意味する「MFP」、プリンタを意味する「Printer」などのタイプを示す情報である。モデル名４０５は、「LBPXXXX」のようなデバイスのモデル名を示す。デバイス名４０６は、デバイス管理者が、そのデバイスに設定した名前を示す。ＵＲＬ４０７は、デバイス情報を取得するためのＵＲＬを示す。ＩＰアドレス４０８は、そのデバイスのＩＰアドレスを示す。ＸＭＬ保存パス４０９は、後述するデバイスから取得したGetResponseデータのＨＤ２１１の保存先を示す情報である。このデバイス情報管理テーブルにより、ＤＰ１０２及びクライアントＰＣ１１０は、ネットワーク１００を介して使用できるデバイスを管理できる。

画像形成装置１０１のＣＰＵ３０１は、起動時にＤＰ１０２に対して図５に示すようなＸＭＬ形式のHelloメッセージをユニキャストで送信することにより存在を通知する。

図５は、このハローメッセージの一例を示す図である。

このHelloメッセージは、＜Header＞タグで囲まれるヘッダ部５０１と、＜Body＞タグで囲まれるbody部５０２とで構成され、全体が＜Envelope＞タグで囲まれる構造になっている。この構造は本実施形態において使用するメッセージ全てに共通である。ヘッダ部５０１は、メッセージの内容に依存しない共通ヘッダとしての役割を果たしており、＜Action＞タグ、＜MessageID＞タグ、＜To＞タグが存在する。＜Action＞タグは、メッセージの種類を識別するためのものである。＜MessageID＞タグは、メッセージを一意に識別するための識別子である。＜To＞タグは、このメッセージの送信先を識別するためのものである。図５の例では、このメッセージの送信先がＤＰ１０２に設定されている。

一方、body部５０２は、メッセージの内容に対応して構造が変化する。図５では、＜Body＞タグの直下に＜Hello＞タグが存在し、このメッセージがHelloメッセージであることを示している。＜Hello＞タグの中には、＜EndpointReference＞タグ、＜Types＞タグ、＜XAddrs＞タグ、＜MetadataVersion＞タグが存在する。＜EndpointReference＞タグの中には＜Address＞タグが存在し、デバイスを識別するアドレス情報が記述されている。＜Types＞タグは、デバイスのタイプ情報（ここでは「MFP」）を記述している。＜XAddrs＞タグは、デバイス情報を取得するためのＵＲＬを記述している。＜MetadataVersion＞タグは、デバイス情報のバージョンを記述している。

図６は、本実施形態に係るＤＰ１０２がデバイス情報を登録する際の処理を示すフローチャートである。この処理は、実行時にＤＰ１０２のＲＡＭ２０３にロードされたプログラムをＤＰ１０２のＣＰＵ２０１が実行することにより達成される。

まずＳ１で、ＣＰＵ２０１は、前述したHelloメッセージを受信する。次にＳ２に進み、ＣＰＵ２０１は、そのHelloメッセージの中からデバイスをグローバルに識別するＵＵＩＤとして＜EndpointReference＞タグの中の＜Address＞タグの値を抽出する。図５の例では、ＵＵＩＤは「１２３４５６」である。次にＳ３に進み、ＣＰＵ２０１は、Ｓ２で抽出したＵＵＩＤと同じＵＵＩＤを持つレコードがＨＤ２１１に記憶されているデバイス情報管理テーブル（図４）に存在するかどうかを調べる。存在しないと判定した場合はＳ４に進む。Ｓ４では、ＣＰＵ２０１は、ＨＤ２１１に記憶されているデバイス情報管理テーブルに新たにレコードを追加する。ここでは、受信したHelloメッセージから、デバイスタイプとして＜Types＞タグの値（図５では「ＭＦＰ」）を抽出する。またデバイス情報のバージョンとして＜MetadataVersion＞タグの値（図５では「１」）を抽出し、デバイス情報を取得するためのＵＲＬとして＜XAddrs＞タグの値を抽出する。このＵＲＬは、図５では「http://192.168.0.1/wsd/mex」である。そして、これらをＨＤ２１１に記憶されているデバイス情報管理テーブルに新規レコードとして追加する。また、Helloメッセージの送信元のＩＰアドレスも、そのデバイス情報管理テーブルに新規レコードとして追加する。そしてＳ５に進み、ＣＰＵ２０１は、＜XAddrs＞タグから抽出したＵＲＬにGetメッセージを送信する。本実施形態１では、このＵＲＬは画像形成装置１０１のＩＰアドレスである。

一方、Ｓ３で、Ｓ２で抽出したＵＵＩＤと同じＵＵＩＤを持つレコードがＨＤ２１１に記憶されていると判定した場合はＳ７に進む。Ｓ７では、ＣＰＵ２０１は、Helloメッセージからバージョン情報を抽出する。そしてＳ８において、ＣＰＵ２０１は、ＵＵＩＤが一致したレコードにおけるバージョン情報が同じでかどうかを判定する。バージョンが異なった場合はＳ５に進むが、バージョンが同じであった場合には何もせずに処理を終了する。

図７（Ａ）は、Ｓ５でＤＰ１０２から画像形成装置１０１に発行するGetメッセージの一例を示す図である。

このGetメッセージは、ヘッダ部のみを持つメッセージである。ヘッダ部の＜Action＞タグが、このメッセージがGetメッセージであることを示している。画像形成装置１０１のＣＰＵ３０１は、このGetメッセージを受信すると図７（Ｂ）に示すようなGetResponseメッセージをＤＰ１０２に送信する。

このとき画像形成装置１０１は、画像形成装置１０１のＣＰＵ３０１がGetメッセージを受信したと判断すると、ＨＤ３１１に記録されている自デバイス情報を取得し、GetResponseメッセージを作成してＤＰ１０２に応答する。

図７（Ｂ）は、GetResponseメッセージの一例を示す図である。

このGetResponseメッセージでは、body部に＜Metadata＞タグで示されるデバイス情報を持つ構造となっている。

＜Metadata＞タグの中には、＜MetadataSection＞タグで示されるMetadataSection部７０１，７０２，７０３が存在する。各MetadataSection部は直下のタグにより、その中に持つ情報の種類が指定される。MetadataSection部７０１は、＜ThisDevice＞タグを持っており、ここにはデバイスごとに異なる情報が記述される。＜FriendlyName＞タグは、このデバイスにつけた名前、＜FirmwareVersion＞タグはこのデバイスのファームウェアバージョン、＜SerialNumber＞タグはこのデバイスのシリアル番号を示している。MetadataSection部７０２は、＜ThisModel＞タグを持っており、デバイスのモデルごとに異なる情報が記述される。＜Manufacturer＞タグは、このデバイスの製造会社名、＜Manufacturer＞タグはデバイス製造会社のＵＲＬである。また＜PresentationＵＲＬ＞は、デバイスの情報を示すＵＲＬ、＜ModelName＞タグはデバイスのモデル名を示している。MetadataSection部７０３は、＜Relationship＞タグを持っており、このデバイスが持つ内部サービスの情報が記述される。

本実施形態１では、内部サービスとは、画像形成装置１０１が提供するプリントサービスである。＜Relationship＞タグは、さらにその直下に＜Hosted＞タグを持ち、その中に＜EndpointReference＞タグ、＜Types＞タグ、＜ServiceId＞タグが存在する。＜EndpointReference＞タグの中には＜Address＞タグが存在し、サービスを利用するためのアドレス情報を記述している。＜Types＞タグは、サービスのタイプ情報を記述している。＜ServiceId＞タグは、デバイス内でサービスを識別するための識別子を記述している。

こうしてＳ６で、ＣＰＵ２０１は、画像形成装置１０１からのGetResponseメッセージからデバイス名として＜FriendlyName＞タグの値、モデル名として＜ModelName＞タグの値を抽出する。これら抽出した値によってＨＤ２１１に記憶されているデバイス情報管理テーブル（図４）の当該レコードを更新する。また、受信したGetResponseメッセージのＸＭＬ自体もＨＤ２１１に記憶し、そのファイルパスをＸＭＬ保存パス４０９としてＨＤ２１１に記憶されているデバイス情報管理テーブルに保存する。

図８は、本実施形態１に係るクライアントＰＣ１１０のデバイスの検索処理の手順を示すフローチャートである。この処理を実行するプログラムは、実行時はＰＣ１１０のＲＡＭ２０３にロードされており、ＰＣ１１０のＣＰＵ２０１の制御の下に実行される。

まずＳ１１で、クライントＰＣ１１０のＣＰＵ２０１は、図９（Ａ）に示すようなProbeメッセージ（探索要求）をマルチキャストで送信し、ＤＰ１０２を検索する。

図９（Ａ）は、Probeメッセージの一例を示す図である。

このProbeメッセージでは、body部に＜Probe＞タグが存在し、このメッセージがProbeメッセージであることを示している。そして＜Probe＞タグの中に＜Types＞タグが存在すし、この＜Types＞タグには、ＤＰ１０２を示す「DeveiceProxy」が記述されている。

このProbeメッセージを受信したＤＰ１０２は、そのProbeメッセージの＜Types＞タグを抽出し、自機が「DeviceProxy」に該当するかを判定する。「DeviceProxy」に該当すると判定すると、図９（Ｂ）に示すProbeMatchメッセージをクライアントＰＣ１１０に送信する。

図９（Ｂ）は、このProbeMatchメッセージ（探索結果）の一例を示す図である。

このProbeMatchメッセージでは、body部に＜ProbeMatches＞タグが存在し、このメッセージがProbeMatchメッセージであることを示している。＜ProbeMatches＞タグの中には、＜ProbeMatch＞タグで示されるProbeMatch部９０１が存在する。このProbeMatch部９０１が１個の検索結果に対応しており、検索されたＤＰ１０２の情報が返されていることを示している。

次にＳ１２に進み、クライアントＰＣ１１０のＣＰＵ２０１は、ＤＰ１０２からProbeMatchメッセージを受信するとＳ１３に進む。Ｓ１３でＣＰＵ２０１は、ProbeMatchメッセージの＜XAddrs＞タグから抽出したＵＲＬに、Probeメッセージをユニキャストで送信する。

ここでは、このProbeメッセージでは、＜Types＞タグで「Printer」を指定し、プリンタデバイスを検索することを示している。

一方、Ｓ１２でProbeMatchメッセージを受信しない場合は、ネットワーク１００にＤＰ１０２が存在しないことを示す。よってこの場合はＳ２０に進み、ＣＰＵ２０１は、＜Types＞タグに「Printer」を指定したProbメッセージをマルチキャストで送信する。これによりＤＰ１０２を利用せずに自らデバイスを検索することになる。

図１０は、本実施形態１に係るＤＰ１０２が、クライアントＰＣ１１０からデバイス検索要求を受信した場合の処理を示すフローチャートである。この処理を実行するプログラムは、実行時はＤＰ１０２のＲＡＭ２０３にロードされており、ＤＰ１０２のＣＰＵ２０１の制御の下に実行される。

まずＳ３１で、ＤＰ１０２のＣＰＵ２０１は、ＰＣ１１０からProbeメッセージを受信するとＳ３２に進む。Ｓ３２でＣＰＵ０１は、そのProbeメッセージから＜Types＞タグを抽出し、ＨＤ２１１に記憶されているデバイス情報管理テーブル（図４）の中から検索条件に合致するデバイスを探す。そしてＳ３３でＣＰＵ２０１は、その検索条件に合致したデバイスが、デバイス情報管理テーブルに存在するか調べ、存在する場合はＳ３４に進む。Ｓ３４でＣＰＵ２０１は、図１１に示すようなProbeMatchメッセージをクライアントＰＣ１１０に送信する。

図１１は、ProbeMatchメッセージの一例を示す図である。

ProbeMatchメッセージでは、＜ProbeMatches＞タグの中に、＜ProbeMatch＞タグで示されるProbeMatch部１１０１，１１０２が存在する。それぞれのProbeMatch部が１個の検索結果に対応しており、図１１の例では、２個のデバイスが検索されたことが返されていることを示している。図１１において、図９の９０１に対応している＜ProbeMatches＞タグの中の＜XAddrs＞タグが示すＵＲＬは、ＤＰ１０２のＩＰアドレスである。

次に再び図８に戻って、Ｓ１４で、クライアントＰＣ１１０のＣＰＵ２０１は、ProbeMatchメッセージを受信したかを判定し、受信するとＳ１５に進む。Ｓ１５では、ＣＰＵ２０１は、このProbeMatchメッセージの中からデバイスをグローバルに識別するＵＵＩＤとして＜EndpointReference＞タグの中の＜Address＞タグの値を抽出する。図１１の例では、２つのＵＵＩＤが抽出される。

次にＳ１６に進み、ＣＰＵ２０１は、Ｓ１５で抽出されたＵＵＩＤと同じＵＵＩＤを持つレコードが、クライアントＰＣ１１０のＨＤ２１１のデバイス情報管理テーブル（図４）に存在するかどうかを調べる。存在しなかった場合はＳ１７に進み、ＣＰＵ２０１は、クライアントＰＣ１１０のＨＤ２１１のデバイス情報管理テーブルに新たにレコードを追加する。一方、Ｓ１６で、存在すると判定した場合はＳ２１に進み、クライアントＰＣ１１０のＣＰＵ２０１は、Ｓ１４で受信したProbeMatchメッセージからバージョン情報を抽出する。そしてＳ２２で、ＣＰＵ２０１は、ＵＵＩＤが一致したレコードにおけるバージョン情報が同じをどうか判定し、バージョンが異なる場合はＳ１８に進むが、バージョンが同じ場合はＳ２３に進む。Ｓ１８では、クライアントＰＣ１１０のＣＰＵ２０１は、ProbeMatchメッセージの中から＜XAddrs＞タグで記載されたＵＲＬを抽出し、そのＵＲＬに対して図７（Ａ）で説明したGetメッセージをユニキャストで送信する。このＵＲＬが示すアドレスはＳ１２の分岐によって、画像形成装置１０１のアドレスになるか、ＤＰ１０２のアドレスになるかが分かれる。例えば、Ｓ１２でＹｅｓと判定した場合は、Ｓ１３でＤＰ１０２に対してデバイス検索要求し、Ｓ１４で、ＤＰ１０２からProbeMatchメッセージを受信する。よってProbeMatchメッセージ上の＜XAddrs＞タグはＤＰ１０２のＩＰアドレスである。一方、Ｓ１２での判定がＮｏの場合はＳ２０に進み、マルチキャストでデバイス検索要求する。そしてＳ１４で、画像形成装置１０１からProbeMatchメッセージを受信する。よってこの場合は、ProbeMatchメッセージ上の＜XAddrs＞タグは、画像形成装置１０１のＩＰアドレスとなる。

図１２は、実施形態１に係るＤＰ１０２が、クライアントＰＣ１１０からGetメッセージを受信した場合の処理を示すフローチャートである。この処理を実行するプログラムは、実行時はＤＰ１０２のＲＡＭ２０３にロードされており、ＤＰ１０２のＣＰＵ２０１の制御の下に実行される。

まずＳ４１で、ＤＰ１０２のＣＰＵ２０１は、Getメッセージを受信するとＳ４２に進む。Ｓ４２では、ＣＰＵ２０１は、Getメッセージの中からデバイスをグローバルに識別するＵＵＩＤとして＜To＞タグの値を抽出する。次にＳ２３に進み、ＣＰＵ２０１は、その抽出されたＵＵＩＤと同じＵＵＩＤを持つレコードがＨＤ２１１のデバイス情報管理テーブル（図４）に存在するかどうかを判定する。Ｓ４４で、存在すると判定したときはＳ４５に進み、ＣＰＵ２０１は、図１３に示すようなGetResponseメッセージをクライアントＰＣ１１０に送信する。

図１３は、ＤＰ１０２からクライアントＰＣ１１０に送信されるGetResponseメッセージの一例を示す図である。このメッセージは、ＤＰ１０２のＨＤ２１１に記憶されているデバイス情報管理テーブルの情報を基に作成される。

図１３では、＜Relationship＞タグの下に＜Hosted＞タグで示されるHostd部１３０１が追加されている。＜Types＞として「DeviceProxyEventingServiceType」が指定され、＜Address＞タグにはＤＰ１０２のＩＰアドレスであるＵＲＬが記述されている。詳細は後述するが、クライアントＰＣ１１０は、このＵＲＬにイベント登録リクエスト（Subscribeリクエスト）を送信することにより、ＤＰ１０２経由で、デバイス（ここでは画像形成装置１０１）にイベント登録リクエストを発行することができる。

こうしてGetResponseメッセージを受信すると図８のＳ１９に進む。Ｓ１９では、クライアントＰＣ１１０のＣＰＵ２０１は、その受信したGetResponseメッセージの情報を基に、クライアントＰＣ１１０のＨＤ２１１のデバイス情報管理テーブルの当該レコードを更新する。更に、受信したGetResoponseメッセージのＸＭＬデータもクライアントＰＣ１１０のＨＤ２１１に記憶する。

いまＳ１８で、クライアントＰＣ１１０のＣＰＵ２０１が、GetメッセージをＤＰ１０２に送信している場合、受信するGetResponseメッセージは、ＤＰ１０２のＣＰＵ２０１から送信される図１３のようなメッセージになる。図１３では、＜Types＞が「DeviceProxyEventingServiceType」である＜Hosted＞タグが存在する。

またＳ１８で、クライアントＰＣ１１０のＣＰＵ２０１が、Getメッセージを画像形成装置１０１に送信している場合、受信するGetResponseメッセージは、画像形成装置１０１のＣＰＵ３０１から送信される図７（Ｂ）のようなメッセージになる。図７（Ｂ）では、＜Types＞が「DeviceProxyEventingServiceType」である＜Hosted＞タグが存在しない。その場合、「PrinterServiceType」が示すＵＲＬ（「１２３４５６」）にイベント登録リクエスト（Subscribeリクエスト）を送信することにより、直接、画像形成装置１０１にイベントを登録する。クライアントＰＣ１１０のＣＰＵ２０１は、図１１のようにProbeMatchメッセージに複数の検索結果が存在している場合には、全てのデバイス分の情報を取得するまで、Ｓ１５〜Ｓ２３の処理を繰り返す。

こうしてクライアントＰＣ１１０が複数のデバイスの情報を取得すると、その結果を表示部２１０に表示する。尚、このデバイスの検索において、検索するデバイスのタイプを、例えば「MFP」「Printer」などのキーワードにより指定できる。検索するデバイスのタイプを指定しない場合は、全てのデバイスを対象として検索が行われる。

図１４（Ａ）は、実施形態１に係るクライアントＰＣ１１０が、前述のデバイス検索によって検索したデバイスに対して、イベント登録処理を行う手順を示すフローチャートである。この処理を実行するプログラムは、実行時はＰＣ１１０のＲＡＭ２０３にロードされており、ＰＣ１１０のＣＰＵ２０１の制御の下に実行される。

まずＳ５１で、クライアントＰＣ１１０のＣＰＵ２０１は、クライアントＰＣ１１０のＨＤ２１１に記憶されているGetResponseメッセージデータから、イベント登録リクエスト送信先のＵＲＬを抽出する。図８のＳ１８で、ＤＰ１０２からデバイス情報を取得している場合は、イベント登録リクエスト送信先のＵＲＬはＤＰ１０２のＩＰアドレスである。またＳ１８で画像形成装置１０１からデバイス情報を取得している場合は、イベント登録リクエスト送信先のＵＲＬは、画像形成装置１０１のＩＰアドレスである。そしてＳ５２に進み、クライアントＰＣ１１０のＣＰＵ２０１は、イベント登録リクエスト先のＵＲＬに対して、Subscribeリクエストを送信する。

図１４（Ｂ）は、Ｓ５２で、ＰＣ１１０からＤＰ１０２に送信するSubscribeリクエストの一例を示す図である。

wsa:Filter部１４０１は、「PrinterStatusEvent」が示すイベントについてStatusが変化したら（イベントが発生したら）通知をしてほしい旨を示している。wsa:To部１４０２は、サービスを提供する装置のＵＲＬを示している。このＵＲＬは図８のＳ１８で取得したGetResponseメッセージの中の、＜Types＞が「PrinterServiceType」である＜Hosted＞タグ内の＜Address＞タグが示すＵＲＬに該当する。

図１５は、本実施形態に１係るＤＰ１０２が、クライアントＰＣ１１０からSubscribeリクエストを受信してから画像形成装置１０１にSubscribeリクエストを送信するまでの処理を示すフローチャートである。この処理を実行するプログラムは、実行時はＤＰ１０２のＲＡＭ２０３にロードされており、ＤＰ１０２のＣＰＵ２０１の制御の下に実行される。

まずＳ６１で、ＤＰ１０２のＣＰＵ２０１は、Subscribeリクエストを受信するとＳ６２に進む。Ｓ６２でＣＰＵ２０１は、その受信したSubscribeリクエストの情報を代行イベント情報としてＤＰ１０２のＨＤ２１１が保持する後述のデバイス管理テーブル（図１６）に追加記録する。

図１６は、ＤＰ１０２のＨＤ２１１が保持するイベントを通知するためのデバイス管理テーブルの一例を示す図である。

このデバイス情報管理テーブルは、それぞれの代行イベント情報をレコードとして保持する。レコードはＩＤ１６０１、イベント登録先ＵＲＬ１６０２、イベント通知先ＵＲＬ１６０３、イベント種別１６０４を含んでいる。ＩＤ１６０１は、ＤＰ１０２内で代行イベント情報を識別するためのＩＤを示す。イベント登録先ＵＲＬ１６０２は、イベント登録先のサービスＵＲＬを示し、図１４（Ｂ）のwsa:Toタグに示す情報が該当する。図１４（Ｂ）では、画像形成装置１０１のＵＲＬである。イベント通知先ＵＲＬ１６０３は、Subscribeリクエスト送信元のクライアントＰＣ１１０ＵＲＬを示し、図１４（Ｂ）のwsa:ReplyToタグに示す情報が該当する。イベント種別１６０４は、通知して欲しいイベントの種別を示し、図１４（Ｂ）のwsa:Filterに示す情報が該当する。ここでは画像形成装置１０１の状態が変化したとき「PrinterStatusEvent」である。後述するが、ＤＰ１０２は、イベント登録先ＵＲＬ１６０２に示すデバイスから、イベント種別１６０４に示すイベント種別のイベントを受信すると、そのイベントをイベント通知先ＵＲＬ１６０３に示すクライアント（ここではＰＣ１１０）に通知する。

次にＳ６３で、ＤＰ１０２のＣＰＵ２０１は、デバイス情報管理テーブルに追加したレコードのイベント登録先ＵＲＬ１６０３が新規であるかどうかを判定する。ここで新規であると判定するとＳ６５に進む。またＳ６４で、イベント登録先ＵＲＬ１６０３部が新規でない場合でもイベント種別１６０４が新規であればＳ６５に進む。Ｓ６５でＤＰ１０２のＣＰＵ２０１は、図１７のようなＸＭＬ形式のSubscribeリクエストをイベント登録先ＵＲＬ１７０３が示すＵＲＬに送信する。Ｓ６３でイベント登録先ＵＲＬ１６０３が新規でなく、かつＳ６４で同じイベント種別が存在している場合は、既に同イベント登録先ＵＲＬに対して同イベント種別でSubscribeリクエスト送信済であるため、何もしないで終了する。

図１７は、ＤＰ１０２から画像形成装置１０１へ送信するSubscribeリクエストの一例を示す図である。

この例では、画像形成装置１０１は、「PrintStatusEvent」と「ScannerStatusEvent」が示すイベントについて状態が変化した場合、ＤＰ１０２にイベントを通知することになる。ここでは画像形成装置１０１は、ＤＰ１０２にだけ送信すればよいため、複数のクライアントＰＣにネットワークを介してイベントを送信するという手間がなくなる。画像形成装置１０１のＣＰＵ３０１は、Subscribeリクエストを受信すると、画像形成装置１０１のＨＤ３１１に、通知すべきイベント種別とイベント通知先の情報とを関連付けて記憶する。

図１８は、本実施形態に係る画像形成装置１０１における、イベントが発生した場合の処理の手順を示すフローチャートである。この処理を実行するプログラムは、実行時はＲＡＭ３０２にロードされており、ＣＰＵ３０１の制御の下に実行される。この処理は、例えばジョブに対する遷移状態変化に関わるイベント、エラー情報関連イベント、オプション装置等の変更に関するイベント、各種設定変更に関連するイベントが発生することによる開始される。

まずＳ７１で、ＣＰＵ３０１は、イベントが発生したかどうかを判定する。イベントが発生したと判定するとＳ７２に進み、ＣＰＵ３０１は、画像形成装置１０１のＨＤ３１１に記憶されているイベント通知先情報とイベント種別を検索する。次にＳ７３に進み、通知すべきイベントとして登録されているかどうかを判定し、そうであればＳ７４に進み、ＣＰＵ３０１は、ＨＤ３１１に記憶されているイベント通知先にイベントを送信してＳ７５に進む。一方、Ｓ７３で、通知すべきイベントとして登録されていないと判定した場合はＳ７５に進む。Ｓ７５で、ＨＤ３１１に通知すべきイベント通知先への送信処理が全て完了したかを調べ、完了していない場合はＳ７２に戻り、前述の処理を実行する。

これにより画像形成装置１０１は、ＨＤ３１１に記憶されている通知すべきイベント通知先がＤＰ１０２であれば、Ｓ７４でＤＰ１０２に対してのみイベントを送信すれば良い。これにより、複数のクライアントＰＣへイベントを送信する手間が省ける。

図１９は、実施形態１に係るＤＰ１０２が、画像形成装置１０１からイベントを受信し、クライアントＰＣ１１０に当該イベントを転送するまでの処理を示すフローチャートである。この処理を実行するプログラムは、実行時はＤＰ１０２のＲＡＭ２０３にロードされており、ＤＰ１０２のＣＰＵ２０１の制御の下に実行される。

まずＳ８１で、ＤＰ１０２のＣＰＵ２０１は、イベントを受信したかどうかを判定する。イベントを受信したと判定するとＳ８２に進み、ＤＰ１０２のＣＰＵ２０１は、ＤＰ１０２のＨＤ２１１が保持するデバイス情報管理テーブル（図１６）に、受信したイベントの送信元がイベント登録先ＵＲＬとして登録されているかを調べる。ここで登録されていると判定した場合はＳ８３に進む。Ｓ８３では、ＤＰ１０２のＣＰＵ２０１は、登録されているイベント通知先ＵＲＬと同じレコード上のイベント通知先ＵＲＬ１６０３が示すＵＲＬに対してイベントを送信する。次にＳ８４に進み、イベント登録先ＵＲＬに対して、複数のイベント通知先ＵＲＬが登録されている場合は、その全ての通知先に対してイベントの送信が完了したかを調べる。完了していない場合はＳ８３に戻って、未送信のイベント通知先ＵＲＬへイベントを送信する。こうしてＳ８４で、全てのイベント登録先ＵＲＬへのイベントの通知が完了すると、この処理を終了する。

以上説明したように本実施形態１によれば、クライアントＰＣ１１０は、ＤＰ１０２にイベント登録リクエストを送信し、ＤＰ１０２がクライアントＰＣ１１０の代わりに画像形成装置１０１にイベント登録リクエストを送信する。従って画像処理装置１０１でイベントが発生すると、画像処理装置１０１はＤＰ１０２だけにイベント通知を行えばよい。これにより、ネットワーク上に存在するクライアントＰＣの数が多くなり、イベント通知を望むクライアントＰＣの数が多くなったとしても、イベント通知装置である画像形成装置１０１のイベント通知に係る処理負荷を軽減できる。

［実施形態２］
次に本発明の実施形態２を説明する。尚、この実施形態２に係るネットワークの構成、及び画像形成装置１０１、ＤＰ１０２及びＰＣ１１０のハードウェア構成は前述の実施形態１と同じであるため、それらの説明を省略する。

この実施形態２では、画像形成装置１０１がＤＰ１０２にGetResponseメッセージを送信する際に、画像形成装置１０１が、図１３に示すHostd部１３０１を追加する。前述の実施形態１では、図１２のＳ４５で、ＤＰ１０２がクライアントＰＣ１１０に送信するデバイス情報（GetResponseメッセージ）は、ＤＰ１０２が加工して、図１３に示すようにHostd部１３０１を書き加えている。このHostd部１３０１は、＜Types＞として「DeviceProxyEventingServiceType」を指定し、＜Address＞タグにはＤＰ１０２のＩＰアドレスであるＵＲＬが記述されている。これによりデバイス情報（GetResponseメッセージ）を取得したクライアントＰＣ１１０は、そのデバイスへイベントの通知要求を発行する場合には、ＤＰ１０２にイベント登録リクエストを送信することになる。

図２０は、実施形態２に係る画像形成装置１０１が、Getメッセージを受信してからGetResponseメッセージを送信するまでの処理を示すフローチャートである。この処理を実行するプログラムは、実行時はＲＡＭ３０２にロードされており、ＣＰＵ３０１の制御の下に実行される。

まずＳ９１で、画像形成装置１０１のＣＰＵ３０１は、Getメッセージを受信したかを判定し、受信するとＳ９２に進む。Ｓ９２で、ＣＰＵ３０１は、ＨＤ３１１に登録されているイベント通知先の数を調べる。その数が一定以上の場合はＳ９３に進む。Ｓ９３では、ＣＰＵ３０１は、GetResponseメッセージに、Hostd部１３０１を書き加えて送信する。一方、Ｓ９２で、イベント通知先が一定数以下であると判定すると、図７（Ｂ）に示すような、自サービスを示すHostd部だけにしてGetResponseメッセージを送信する。尚、この一定数の設定は、画像形成装置１０１の操作パネル３０５から設定可能とする。

これによりＤＰ１０２は、図６のＳ５でGetResponseメッセージを受信するが、実施形態２では、この時点でGetResponseメッセージには既にHostd部１３０１が追加されている。よって図１２のＳ４５で、ＤＰ１０２がクライアントＰＣ１１０にGetResponseメッセージを送信する時は、このGetResponseメッセージを加工せずに送信することができる。

以上説明したように本実施形態２によれば、イベント通知装置である画像形成装置１０１が、イベントの通知先の数が所定数よりも多いためイベント通知の負荷が大きいと判断すると、自動的にイベント通知の登録先をイベント代行通知装置にしている。これによりイベントを通知する通知先の数が増えても、イベント通知装置の処理の負荷の増大を抑えることができる。

［実施形態３］
次に本発明の実施形態３を説明する。尚、この実施形態３に係るネットワークの構成、及び画像形成装置１０１、ＤＰ１０２及びＰＣ１１０のハードウェア構成は前述の実施形態１，２と同じであるため、それらの説明を省略する。この実施形態３では、イベント登録先の画像形成装置１０１がＤＰ１０２によって検索されたものか否かによって、クライアントＰＣ１１０がイベント登録をＤＰ１０２に対して行うか、画像形成装置１０１に直接行うかを切り替える。前述の実施形態１及び２では、図１２のＳ４５で、ＤＰ１０２がクライアントＰＣ１１０に送信するデバイス情報（GetResponseメッセージ）に、図１３のHostd部１３０１で示すようなイベント登録先のＵＲＬが加えられていた。これに対して実施形態３では、ＤＰ１０２にイベント登録する際のＵＲＬは、GetResponseメッセージから取得するのではなく、予めクライアントＰＣ１１０のＨＤ２１１に記憶しておくものとする。

図２１は、実施形態３に係るクライアントＰＣ１１０が、イベント登録を行う処理の手順を示すフローチャートである。この処理を実行するプログラムは、実行時はＰＣ１１０のＲＡＭ２０３にロードされており、ＰＣ１１０のＣＰＵ２０１の制御の下に実行される。

まずＳ１０１で、クライアントＰＣ１１０のＣＰＵ２０１は、イベント登録先の画像形成装置１０１が、ＤＰ１０２によって検索されたデバイスかどうかを判定する。ここでは、予めクライアントＰＣ１１０のＨＤ２１１にＤＰ１０２のイベント登録先のＵＲＬが記憶されているものとする。Ｓ１０１で、ＤＰ１０２によって検索されたと判定した場合はＳ１０２に進む。Ｓ１０２では、クライアントＰＣ１１０のＣＰＵ２０１は、クライアントＰＣ１１０のＨＤ２１１に記憶されているＤＰ１０２のイベント登録先ＵＲＬを取得してＳ１０４に進む。一方、Ｓ１０１で、ＤＰ１０２によって検索されたものでないと判定した場合はＳ１０３に進み、ＣＰＵ２０１は、GetResponseメッセージに記載されたイベント登録先ＵＲＬを取得してＳ１０４に進む。Ｓ１０４では、クライアントＰＣ１１０のＣＰＵ２０１は、イベント登録先ＵＲＬにイベント登録リクエストを送信する。

以上説明したように本実施形態３によれば、ＤＰ１０２によって検索されたイベント登録先の画像形成装置１０１に対してのみ、クライアントＰＣがイベント登録先として設定できる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (6)

1. イベント通知装置からイベントの発行を受け取るとクライアント装置に当該イベントの発行を通知するイベント代行通知装置であって、
   前記クライアント装置からのイベントの通知要求を受信すると、当該通知要求に含まれるイベントの種類、イベント通知装置及び前記クライアント装置に関する情報を登録する登録手段と、
   イベント通知装置からイベントの発行を受け取ると、当該イベント通知装置、当該イベントの種類、及び当該イベントの通知を要求したクライアント装置が、前記登録手段によって登録されているかどうかを判定する判定手段と、
   前記判定手段によって登録されていると判定された場合、前記イベントを前記登録手段によって登録されている前記クライアント装置に送信するイベント通知手段と、
   を有することを特徴とするイベント代行通知装置。
2. 前記登録手段は、前記イベントの通知要求に含まれる前記イベント通知装置に対して情報を要求し、当該要求に対する前記イベント通知装置からの応答に基づいて前記イベント通知装置に関する情報を抽出することを特徴とする請求項１に記載のイベント代行通知装置。
3. 前記クライアント装置から、前記登録手段に登録されているイベント通知装置の探索要求を受信する受信手段と、
   前記受信手段で受信した前記探索要求に応答して探索結果を前記クライアント装置に応答する手段とを更に有することを特徴とする請求項１又は２に記載のイベント代行通知装置。
4. 前記イベント通知手段は、前記イベントを、前記登録手段により登録されているクライアント装置の中で、当該イベントの通知要求を行っている全てのクライアント装置に送信することを特徴とする請求項１乃至３のいずれか１項にイベント代行通知装置。
5. イベント通知装置からイベントの発行を受け取るとクライアント装置に当該イベントの発行を通知するイベント代行通知装置の制御方法であって、
   前記クライアント装置からのイベントの通知要求を受信すると、当該通知要求に含まれるイベントの種類、イベント通知装置及び前記クライアント装置に関する情報を登録する登録工程と、
   イベント通知装置からイベントの発行を受け取ると、当該イベント通知装置、当該イベントの種類、及び当該イベントの通知を要求したクライアント装置が、前記登録工程で登録されているかどうかを判定する判定工程と、
   前記判定工程で登録されていると判定された場合、前記イベントを前記登録工程で登録されている前記クライアント装置に送信するイベント通知工程と、
   を有することを特徴とするイベント代行通知装置の制御方法。
6. イベント通知装置からイベントの発行を受け取るとクライアント装置に当該イベントの発行を通知するイベント代行通知をコンピュータに実行させるために、当該コンピュータを、
   前記クライアント装置からのイベントの通知要求を受信すると、当該通知要求に含まれるイベントの種類、イベント通知装置及び前記クライアント装置に関する情報を登録する登録手段と、
   イベント通知装置からイベントの発行を受け取ると、当該イベント通知装置、当該イベントの種類、及び当該イベントの通知を要求したクライアント装置が、前記登録手段によって登録されているかどうかを判定する判定手段と、
   前記判定手段によって登録されていると判定された場合、前記イベントを前記登録手段によって登録されている前記クライアント装置に送信するイベント通知手段とを有するイベント代行通知装置として機能させるためのプログラム。

Images