JP2011060095A - 情報処理装置、制御方法、及びプログラム - Google Patents

Abstract

【課題】複数のアドレスを有する画像処理装置からイベント通知が送信された場合に、イベント通知の送信元の画像処理装置を正しく識別して適切な処理を行うことを可能とした情報処理装置、制御方法、及びプログラムを提供する。
【解決手段】ＰＣは、ＭＦＰでイベントが発生した際にイベント通知を送信するよう依頼するイベント通知依頼パケットをＭＦＰに送信する。更に、ＰＣは、イベント通知依頼に対してＭＦＰから返信された返信パケットから送信元アドレスを取得し、イベント通知依頼済み装置のアドレスとしてＭＦＰ管理テーブルに登録する。ＰＣは、ＭＦＰからイベント通知パケットを受信すると、イベント通知パケットから送信元アドレスを取得してイベント通知依頼済み装置のアドレスと比較し、アドレスが一致する場合、イベント通知パケットを送信したＭＦＰを登録済みのＭＦＰであると判断する。
【選択図】図１０

Description

本発明は、画像処理装置から送信されるパケットを受信して処理することで画像処理装置の管理を行う情報処理装置、制御方法、及びプログラムに関する。

近年のオフィス環境では、ネットワークを介して接続された画像処理装置（複合機（ＭＦＰ）やプリンタ）を、情報処理装置（パーソナルコンピュータ）で動作するアプリケーションソフトウェアにより管理及び制御することが一般的になっている。

また、従来から、情報処理装置でデバイス（画像処理装置）及びデバイス内のジョブの管理を行うために、デバイスから情報処理装置に送信されるイベント通知を利用する技術が提案されている（例えば、特許文献１参照）。特許文献１によれば、デバイスを識別するために、予めデバイス毎に付与される識別ＩＤを用いている。更に、ネットワークを介して接続されたデバイスを識別する一般的な方法として、ネットワーク上のノード識別情報であるＩＰアドレスを用いることが知られている。

一方、ネットワークに接続可能なデバイスが多種多様となるなかで、従来から利用されているインターネットプロトコルであるＩＰｖ４（Internet Protocol Version 4）には、ＩＰアドレスの枯渇等の様々な課題がある。これに対して、ＩＰｖ４の課題を解決するためＩＰｖ６（Internet Protocol Version 6）が普及しつつある。

ＩＰｖ６では一つのネットワークインタフェースが同時に複数のＩＰアドレスを持つことが可能であるため、ＲＦＣ（Request for Comments）３４８４において複数のアドレスをどのように選択するかの判断基準が定義されている。ＲＦＣ３４８４によれば、送信元のアドレス選択基準の一つとしてLongestMatchという基準が示されている。LongestMatchとは、送信元の複数のＩＰアドレスのうち、送信先ＩＰアドレスとの比較により最長一致するプレフィックスを選択することを示している。

特開２００７−３１７０８７号公報

しかしながら、上述した技術には次の問題があった。ネットワーク接続されたデバイスを識別する方法としてＩＰアドレスを用いた場合、アプリケーションソフトウェアはデバイスが保持している複数のＩＰアドレスを予め把握しておく必要がある。情報処理装置がデバイスから受信したパケットの送信元ＩＰアドレスが未知の値である場合、受信したパケットがどのデバイスから送信されたものであるかを判断することができず、正しく処理することができないという問題があった。

また、特許文献１のようにデバイス毎の識別ＩＤをＩＰアドレスとは別に設けてデバイスを識別することは可能である。しかしながら、デバイスに予め識別ＩＤを付与してデバイスから情報処理装置に対する送信パケットに含めなければならないため、デバイスの処理及び送信パケットの構造を変更する必要がある。そのため、情報処理装置は既存のデバイスからの送信パケットに対して対応することができないという問題があった。

本発明の目的は、複数のアドレスを有する画像処理装置からイベント通知が送信された場合に、イベント通知の送信元の画像処理装置を正しく識別して適切な処理を行うことを可能とした情報処理装置、制御方法、及びプログラムを提供することにある。

上記目的を達成するために、本発明は、印刷を含むジョブの処理が可能な画像処理装置とネットワークを介して通信が可能な情報処理装置であって、画像処理装置でジョブの状態変化を含むイベントが発生した際にイベント通知を送信するよう依頼するイベント通知依頼パケットを前記画像処理装置に送信する依頼手段と、前記依頼手段により前記イベント通知依頼パケットを送信した送信先の前記画像処理装置から返信された返信パケットから送信元アドレスを取得し、イベント通知依頼済み装置のアドレスとして登録する登録手段と、画像処理装置からイベント通知パケットを受信した場合、前記イベント通知パケットから送信元アドレスを取得し、該取得した送信元アドレスと前記登録手段により登録された前記イベント通知依頼済み装置のアドレスとを比較する比較手段と、前記比較手段により前記送信元アドレスと前記イベント通知依頼済み装置のアドレスとが一致すると判定された場合、前記イベント通知パケットを送信してきた画像処理装置を前記登録手段により登録した画像処理装置であると判断する判断手段と、を備えることを特徴とする。

本発明によれば、情報処理装置は、イベント通知依頼の送信先アドレスとイベント通知の送信元アドレスとが異なる場合でも、イベント通知依頼済みの画像処理装置とイベント通知を送信した画像処理装置との対応付けが可能となる。これにより、情報処理装置は、複数のアドレスを有する画像処理装置から画像処理装置の状態やジョブの状態等のイベントの発生を通知された際に、イベント通知の送信元の画像処理装置を正しく識別して適切な処理を行うことが可能となる。

本発明の第１の実施の形態に係るネットワークシステムの構成例を示す構成図である。 ネットワークシステムを構成するＰＣのハードウェアの構成例を示すブロック図である。 ネットワークシステムを構成するＭＦＰのハードウェアの構成例を示すブロック図である。 ＰＣからＭＦＰに送信するイベント通知依頼の送信パケットの構成を示す図である。 ＭＦＰからＰＣに送信するイベント通知依頼の返信パケットの構成を示す図である。 ＭＦＰからＰＣに送信するイベント通知パケットの構成を示す図である。 ＰＣが保持するＭＦＰ管理テーブルの構成を示す図である。 ＭＦＰが保持するイベント通知先管理テーブルの構成を示す図である。 ＰＣがＭＦＰにイベント通知依頼を送信すると共にイベント通知依頼済みのＭＦＰをＭＦＰ管理テーブルに登録する処理を示すフローチャートである。 ＰＣがＭＦＰから送信されるイベント通知パケットを受信すると共にイベント通知パケットを解析した結果に応じて実行する処理を示すフローチャートである。 ＭＦＰがＰＣから送信されるイベント通知依頼の送信パケットを受信すると共にイベント通知依頼の返信パケットを生成してＰＣに送信する処理を示すフローチャートである。 ＭＦＰがイベント発生時に予めＰＣから依頼されているイベント通知をＰＣに送信する処理を示すフローチャートである。 本発明の第２の実施の形態に係るＰＣが保持するＭＦＰ管理テーブルの構成を示す図である。 ＰＣがＭＦＰにイベント通知依頼を送信すると共にイベント通知依頼済みのＭＦＰのアドレスをＭＦＰ管理テーブルに登録する処理を示すフローチャートである。 本発明の第３の実施の形態に係るＰＣがＭＦＰにイベント通知依頼を送信すると共にイベント通知依頼済みのＭＦＰのアドレスをＭＦＰ管理テーブルに登録する処理を示すフローチャートである。

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

〔第１の実施の形態〕
図１は、本発明の第１の実施の形態に係るネットワークシステムの構成例を示す構成図である。

図１において、ネットワークシステムは、複数の画像処理装置と複数の情報処理装置をネットワークを介して通信可能に接続した構成となっている。本実施の形態では、複数の画像処理装置は、ＭＦＰ（Multi Function Peripheral）１０１、１０２として構成されている。また、複数の情報処理装置は、パーソナルコンピュータ（ＰＣ）１０３、１０４として構成されている。また、ネットワークは、ＬＡＮ１１０として構成されている。

ＭＦＰ１０１、ＭＦＰ１０２は、画像読取部（スキャナエンジン）と画像形成部（プリンタエンジン）を備えており、画像読取機能及び画像形成機能を有する。ＭＦＰ１０１は、スキャナエンジンにより原稿から画像を読み取るスキャン処理、読み取った画像を記録紙に複写するコピー処理を行う。また、ＭＦＰ１０１、ＭＦＰ１０２は、読み取った画像をＬＡＮ１１０を介して送信する処理、ＬＡＮ１１０を介して受信した画像をプリンタエンジンにより記録紙に形成するプリント処理を行う。本実施の形態では、ＭＦＰ１０１は、ＩＰｖ６のアドレスとして、2001:db8:aaaa::a/64と2001:db8:bbbb::b/64の２つのアドレスを保持しているものとする。

ＰＣ１０３とＰＣ１０４は、ＬＡＮ１１０を介してＭＦＰ１０１あるいはＭＦＰ１０２と接続されている。また、ＰＣ１０３とＰＣ１０４は、ＭＦＰ１０１あるいはＭＦＰ１０２の状態管理や、ＭＦＰ１０１あるいはＭＦＰ１０２で処理中のジョブ（スキャン、プリント、コピー等）の管理を行うことができる。本実施の形態では、ＰＣ１０３は、ＩＰｖ６のアドレスとして、2001:db8:abcd::e/64と2001:db8:cccc::c/64の２つのアドレスを保持しているものとする。

図２は、ネットワークシステムを構成するＰＣのハードウェアの構成例を示すブロック図である。

図２において、ＰＣ１０３とＰＣ１０４は、それぞれ、ＣＰＵ２０１、ＲＡＭ２０２、液晶ディスプレイ（ＬＣＤ）２０３、入力部（Input Device）２０４、ＲＯＭ２０５、ディスク２０６、ネットワークインタフェース（Ｉ／Ｆ）２０７を備える。上記各部はシステムバス２１０を介して相互に接続されている。

ＣＰＵ２０１は、上記各部の制御を司ると共に、ＬＡＮ１１０に接続されたＭＦＰとの間でネットワークＩ／Ｆ２０７を介して通信を行う。また、ＣＰＵ２０１は、ＬＣＤ２０３を介したユーザに対するメッセージの表示、ユーザからの入力部２０４を介した入力の受け付けを行う。また、ＣＰＵ２０１は、制御プログラム（プログラムコード）に基づき後述の各フローチャート（図９、図１０、図１４、図１５）に示す処理を実行する。

ＲＡＭ２０２は、ＣＰＵ２０１の作業領域や一時記憶領域として使用される。ＲＯＭ２０５あるいはディスク２０６には、ＰＣを制御するための制御プログラムが記憶されており、必要に応じてＲＡＭ２０２に読み出されてＣＰＵ２０１により実行される。また、ＲＯＭ２０５あるいはディスク２０６には、制御プログラム以外にもＰＣで処理されるデータ等が記憶される。尚、ディスク２０６としては例えばハードディスクが使用される。

ＬＣＤ２０３は、ＣＰＵ２０１の制御に基づき各種表示を行う。入力部２０４は、ユーザがＰＣに各種データ入力や各種指示を行う際に用いる。ネットワークＩ／Ｆ２０７は、ＰＣがＭＦＰとの間で通信を行う際のインタフェースを司る。ネットワークＩ／Ｆ２０７としては、イーサネット(登録商標)Ｉ／Ｆ、ＵＳＢ規格のシリアルＩ／Ｆ、ＩＥＥＥ１３９４規格のシリアルＩ／Ｆ、ブルートゥース等の無線通信ネットワークＩ／Ｆ、等の各種の形態が考えられる。

本実施の形態では、特に断らない限り、図２の構成を有するＰＣにおいて、ＣＰＵ２０１がシステムバス２１０を介して入力部２０４からのユーザ入力を受け取り、各処理を実行する。また、ＣＰＵ２０１がシステムバス２１０を介して上記各部（ＲＡＭ２０２〜ネットワークＩ／Ｆ２０７）を制御し、各処理を実行する。

図３は、ネットワークシステムを構成するＭＦＰのハードウェアの構成例を示すブロック図である。

図３において、ＭＦＰ１０１とＭＦＰ１０２は、それぞれ、ＣＰＵ３０１、ＲＡＭ３０２、ＬＣＤ３０３、入力部３０４、ＲＯＭ３０５、スキャナエンジン３０６、プリンタエンジン３０７、ディスク３０８、ネットワークインタフェースＩ／Ｆ３０９を備える。上記各部はシステムバス３１０を介して相互に接続されている。

ＣＰＵ３０１は、上記各部の制御を司ると共に、ＬＡＮ１１０に接続されたＰＣとの間でネットワークＩ／Ｆ３０７を介して通信を行う。また、ＣＰＵ３０１は、ＬＣＤ３０３を介したユーザに対するメッセージの表示、ユーザからの入力部３０４を介した入力の受け付けを行う。また、ＣＰＵ３０１は、制御プログラムに基づき後述の各フローチャート（図１１、図１２）に示す処理を実行する。

ＲＡＭ３０２は、ＣＰＵ３０１の作業領域や一時記憶領域として使用される。ＲＯＭ３０５あるいはディスク３０８には、ＭＦＰを制御するための制御プログラムが記憶されており、必要に応じてＲＡＭ３０２に読み出されてＣＰＵ３０１により実行される。また、ＲＯＭ３０５あるいはディスク３０８には、制御プログラム以外にも、ＭＦＰで処理されるジョブの機能及び状態を示す属性情報、印刷出力の対象となるジョブ・データ、外部から受信して蓄積されたジョブ・データ等が記憶される。尚、ディスク３０８としては例えばハードディスクが使用される。

ＬＣＤ３０３は、ＣＰＵ３０１の制御に基づき各種表示を行う。入力部３０４は、ユーザがＭＦＰに各種データ入力や各種指示を行う際に用いる。スキャナエンジン３０６は、原稿から画像を読み取るスキャンを行う。プリンタエンジン３０７は、原稿の画像を記録紙に複写するコピー、外部から受信した画像を記録紙に形成するプリントを行う。ネットワークＩ／Ｆ３０９は、ＭＦＰがＰＣとの間で通信を行う際のインタフェースを司る。ネットワークＩ／Ｆ３０７としては、イーサネット(登録商標)Ｉ／Ｆ、ＵＳＢ規格のシリアルＩ／Ｆ、ＩＥＥＥ１３９４規格のシリアルＩ／Ｆ、ブルートゥース等の無線通信ネットワークＩ／Ｆ、等の各種の形態が考えられる。

ＭＦＰは、スキャナエンジン３０６を用いて紙文書を読み込みイメージデータを作成するスキャンジョブを実行することができる。また、ＭＦＰは、外部から受信したデータをプリンタエンジン３０７を用いて出力するプリントジョブを実行することができる。また、ＭＦＰは、スキャナエンジン３０６とプリンタエンジン３０７とを用いて紙文書の複写を行うコピージョブを実行することができる。

本実施の形態では、特に断らない限り、図３の構成を有するＭＦＰにおいて、ＣＰＵ３０１がシステムバス３１０を介して入力部３０４からのユーザ入力を受け取り、各処理を実行する。また、ＣＰＵ３０１がシステムバス３１０を介して上記各部（ＲＡＭ３０２〜ネットワークＩ／Ｆ３０９）を制御し、各処理を実行する。

ここで、本実施の形態のＰＣ及びＭＦＰにおいて処理する単位とＰＣ及びＭＦＰ間の相互通信に関わる事象とについて用語を定義する。ＭＦＰが実行する、印刷（プリント、コピー）、スキャン、ＦＡＸ送信、ＦＡＸ受信、文書保存、文書送信等の処理を「ジョブ」と称する。ジョブの状態の変化（ジョブが実行待ちであるか、ジョブが実行中であるか、ジョブの処理が完了したのか、ジョブが中断中であるか）を通知する処理を「ジョブの状態変化通知」と称する。

ＭＦＰで処理するジョブ（スキャンジョブ、コピージョブ、プリントジョブ等）の状態の変化等を含むＭＦＰ内で発生する事象を「イベント」と称する。ＭＦＰが、ＭＦＰでイベントが発生した際に予め登録された通知先のＰＣにイベント発生及びイベント内容を通知することを「イベント通知」と称する。ＰＣが、ＭＦＰでイベントが発生した際にＭＦＰからイベント通知をＰＣに送信させるように予めＰＣに登録するためのＭＦＰに対する依頼を「イベント通知依頼」と称する。

次に、本実施の形態のネットワークシステムを構成する複数のＰＣのうち例えばＰＣ１０３が生成してＭＦＰ１０１に送信するイベント通知依頼の送信パケットの構成について図４を用いて説明する。

図４は、ＰＣ１０３からＭＦＰ１０１に送信するイベント通知依頼の送信パケット（イベント通知依頼パケット）の構成を示す図である。尚、図４で示すイベント通知依頼の送信パケットの構成は一例であり、送信パケットの内容・識別子・格納順・その他の詳細については本発明を実施する上で特に構成を限定するものではない。

図４において、イベント通知依頼の送信パケットデータ（以下イベント通知依頼の送信パケットと略記）は、アプリケーション層データ４１０とトランスポート層データ４２０から構成される。アプリケーション層データ４１０は、更に、ヘッダ部４０１、ブロックナンバー（ＢｌｏｃｋＮｏ）部４０２、オペレーションコード部４０３、サイズ部４０４、パラメータ部４０５から構成される。パラメータ部４０５は、更に、ＩＰ部４１１、ポート部４１２、イベントＩＤ部４１３から構成される。トランスポート層データ４２０は、更に、ヘッダ部４２１、送信元アドレス部４２２、送信先アドレス部４２３から構成される。

ヘッダ部４０１は、プロトコル識別子、プロトコルバージョン、リプライ要求フラグ等を含むオペレーションコード部４０３のコードに依存しないアプリケーションプロトコル固有の情報から構成される。これにより、ＭＦＰ１０１は、ＰＣ１０３から送信される図４のイベント通知依頼の送信パケットを受信すると、ヘッダ部４０１を見て処理可能なプロトコルであるかどうかを判断することができる。

ＢｌｏｃｋＮｏ部４０２は、イベント通知依頼の送信パケットと該送信パケットに対応する返信パケットとを対応付けるためのインデックスを示す。イベント通知依頼の送信パケットには、ＰＣ１０３が任意の値を格納することができる。送信パケットに対応する返信パケットには、送信パケットのＢｌｏｃｋＮｏ部４０２で指定されたＢｌｏｃｋＮｏが格納される。

オペレーションコード部４０３は、図４に示すアプリケーションプロトコルにおけるオペレーション種別を識別するためのコードを格納する。例えば、イベント通知依頼の場合は、イベント通知依頼であることを示す“Subscribe Event”を格納する。サイズ部４０４は、パラメータ部４０５のサイズを示す。パラメータ部４０５が可変長であるため、サイズ部４０４にパラメータ部４０５のサイズを格納しておく。パラメータ部４０５は、オペレーションコード部４０３に対応したパラメータを格納する。オペレーションコード部４０３により格納される情報は変化する。

パラメータ部４０５の詳細をＩＰ部４１１〜イベントＩＤ部４１３を用いて説明する。ＩＰ部４１１は、ＭＦＰでイベントが発生したときに通知する送信先ＩＰアドレスの指定を示し、ＰＣ１０３がＭＦＰからイベント通知パケットを受信するためのＩＰアドレスを指定する。ポート部４１２は、ＩＰ部４１１により示すＩＰアドレスでイベント通知パケットを受信するためのポート番号の指定を示す。

ＭＦＰ１０１及びＭＦＰ１０２からのイベント通知パケットの受信を一つのポートで行う場合は、ポート番号は固定の値となる。図４の場合、ＩＰアドレス2001:db8:abcd::e/64のポート９００５０番へのイベント通知依頼であることを示す。イベントＩＤ部４１３は、イベント通知依頼するイベントの指定を示し、“JobStateChanged”はジョブの状態変化イベントの指定を示す。

トランスポート層データ４２０の詳細をヘッダ部４２１〜送信先アドレス部４２３を用いて説明する。ヘッダ部４２１は、トランスポート層に従ったヘッダ情報を格納する。送信元アドレス部４２２は、ヘッダ部４２１に含まれる情報であり、送信元のＰＣ１０３のＩＰアドレスとポート番号を選択して格納する。送信先アドレス部４２３は、ヘッダ部４２１に含まれる情報であり、送信先のＭＦＰ１０１のＩＰアドレスとポート番号を選択して格納する。

次に、ＭＦＰ１０１がＰＣ１０３からの図４のイベント通知依頼の送信パケットに対してＰＣ１０３に送信（返信）するイベント通知依頼の返信パケットの構成について図５を用いて説明する。

図５は、ＭＦＰ１０１からＰＣ１０３に送信するイベント通知依頼の返信パケットの構成を示す図である。尚、図５で示すイベント通知依頼の返信パケットの構成は一例であり、返信パケットの内容・識別子・格納順・その他の詳細については本発明を実施する上で特に構成を限定するものではない。

図５において、イベント通知依頼の返信パケットは、アプリケーション層データ５１０とトランスポート層データ５２０から構成される。アプリケーション層データ５１０は、更に、ヘッダ部５０１、ブロックナンバー（ＢｌｏｃｋＮｏ）部５０２、オペレーションコード部５０３、サイズ部５０４、ステータスコード部５０５から構成される。トランスポート層データ５２０は、更に、ヘッダ部５２１、送信元アドレス部５２２、送信先アドレス部５２３から構成される。

ヘッダ部５０１は、プロトコル識別子、プロトコルバージョン、リプライ要求フラグ等を含むオペレーションコード部５０３のコードに依存しないアプリケーションプロトコル固有の情報から構成される。これにより、ＰＣ１０３は、ＭＦＰ１０１から送信される図５のイベント通知依頼の返信パケットを受信すると、ヘッダ部５０１を見て処理可能なプロトコルであるかどうかを判断することができる。

ＢｌｏｃｋＮｏ部５０２は、イベント通知依頼の送信パケットと該送信パケットに対応する返信パケットとを対応付けるためのインデックスを示す。イベント通知依頼の返信パケットには、送信パケットのＢｌｏｃｋＮｏ部４０２で指定されたＢｌｏｃｋＮｏが格納される。

ＰＣ１０３は、ＭＦＰ１０１に送信するイベント通知依頼の送信パケットのＢｌｏｃｋＮｏ部４０２に、順次インクリメントするシリアルＮＯ等を格納することができる。これにより、ＰＣ１０３は、ＭＦＰ１０１から返信される返信パケットのＢｌｏｃｋＮｏ部５０２と送信パケットのＢｌｏｃｋＮｏ部４０２を比較することで、当該返信パケットがどの送信パケットに対する返信パケットであるかを識別することができる。

オペレーションコード部５０３は、図５に示すアプリケーションプロトコルにおけるオペレーション種別を識別するためのコード（返信パケットに対応する送信パケットと同じコード）を格納する。サイズ部５０４は、パラメータ部５０５のサイズを示す。ステータスコード部５０５は、オペレーションコード部５０３に対応した情報を格納する。ステータスコード部５０５に格納される情報はオペレーションコード部５０３により変化するが、図５では“SubscribeEvent”に対する処理結果を示すステータスコードを格納する。処理が正常に終了していれば処理結果として“ＯＫ”を格納する。

トランスポート層データ５２０の詳細は図４と同様である。送信元アドレス部５２２には、ＭＦＰ１０１のＩＰアドレス（例えば2001:db8:aaaa::a/64）とポート番号を格納する。送信先アドレス部５２３には、ＰＣ１０３のＩＰアドレス（例えば2001:db8:abcd::e/64）とポート番号を格納する。

ここで、送信元アドレス部５２２に格納するＩＰアドレスは、送信先アドレス部５２３のＩＰアドレスと上述したLongestMatchによりＭＦＰ１０１が持つ複数のＩＰアドレスから一つを選択して設定する。例えば、送信先ＩＰアドレス2001:db8:abcd::e/64との比較により、2001:db8:aaaa::a/64と2001:db8:bbbb::b/64から、2001:db8:aaaa::a/64を選択する。

次に、ＭＦＰ１０１が生成してＰＣ１０３に送信するイベント通知パケットの構成について図６を用いて説明する。

図６は、ＭＦＰ１０１からＰＣ１０３に送信するイベント通知パケットの構成を示す図である。尚、図６で示すイベント通知パケットの構成は一例であり、イベント通知パケットの内容・識別子・格納順・その他の詳細については本発明を実施する上で特に構成を限定するものではない。

図６において、イベント通知パケットは、アプリケーション層データ６１０とトランスポート層データ６２０から構成される。アプリケーション層データ６１０は、更に、ヘッダ部６０１、オペレーションコード部６０２、サイズ部６０３、パラメータ部６０４から構成される。パラメータ部６０４は、更に、イベントＩＤ６１１、ジョブＩＤ６１２、ジョブステート６１３、Ｒｅａｓｏｎ６１４から構成される。トランスポート層データ６２０は、更に、ヘッダ部６２１、送信元アドレス部６２２、送信先アドレス部６２３から構成される。

ヘッダ部６０１は、プロトコル識別子やプロトコルバージョン等を含むオペレーションコード６０２に依存しないアプリケーションプロトコル固有の情報から構成される。これにより、ＰＣ１０３は、ＭＦＰ１０１から送信される図６のイベント通知パケットを受信すると、ヘッダ部６０１を見て処理可能なプロトコルであるかどうかを判断することができる。

オペレーションコード部６０２は、図６に示すアプリケーションプロトコルにおけるオペレーション種別を識別するためのコードを格納する。例えばＭＦＰ１０１からＰＣ１０３に送信するイベント通知の場合は、イベント通知であることを示す“Notify”を格納する。サイズ部６０３は、パラメータ部６０４のサイズを示す。パラメータ部６０４には、イベント通知内容を格納する。

パラメータ部６０４の詳細をイベントＩＤ６１１〜Ｒｅａｓｏｎ６１４を用いて説明する。イベントＩＤ６１１は、ＭＦＰ１０１からＰＣ１０３に通知したイベントの識別子であり、“JobStateChanged”はジョブの状態変化イベントを示す。ジョブＩＤ６１２は、イベント通知対象のジョブの識別子を示す。ＭＦＰ１０１から送信される図６のイベント通知を受信して処理するＰＣ１０３は、ジョブの識別子１００１を指定することで、イベント通知されたジョブに関する参照や操作が可能になる。

ジョブステート６１３は、ジョブの状態を示す。ジョブステート６１３の“OperatorCall”はオペレータ操作が必要なエラー発生であることを示す。Ｒｅａｓｏｎ６１４は、ジョブステート６１３に関する要因を示す。Ｒｅａｓｏｎ６１４の“MemoryFull”はＭＦＰ１０１でメモリ不足が発生していることを示す。

トランスポート層データ６２０の詳細は図４及び図５と同様である。送信元アドレス部６２２には、ＭＦＰ１０１のＩＰアドレス（例えば、2001:db8:aaaa::a/64）とポート番号を格納する。送信先アドレス部６２３には、ＰＣ１０３のＩＰアドレス（例えば、2001:db8:abcd::e/64）とポート番号を格納する。

尚、図６で示したイベント通知パケットの構成は、ＭＦＰ１０１で処理するジョブの状態変化イベントをＰＣ１０３に通知する場合の一例である。イベント通知パケットに図示の内容以外のものが含まれていてもよく、例えばジョブ名を示す文字列やイベント通知を受信して表示する場合の表示文字列などが含まれていてもよい。更に、イベント通知パケットの構成は、通知するイベントにより異なってもよいし、同じイベントを通知する場合でも通知する状態や予め登録されたイベント通知依頼に応じて異なってもよい。

次に、ＰＣ１０３が記憶部（ＲＯＭあるいはディスク）に保持しているＭＦＰ管理テーブルの構成について図７を用いて説明する。

図７は、ＰＣ１０３が保持するＭＦＰ管理テーブルの構成を示す図である。

図７において、ＭＦＰ管理テーブル（通知依頼済みテーブル）は、管理ＩＤ７０１、デバイスＩＤ７０２、イベント登録７０３、ＩＰアドレス７０４から構成される。管理ＩＤ７０１は、ＭＦＰ管理テーブルのインデックス番号である。ＰＣ１０３で管理しているＭＦＰの数だけインデックス（管理ＩＤ７０１）を付けてＭＦＰ管理テーブルに格納する。デバイスＩＤ７０２は、ＰＣ１０３がＭＦＰ（デバイス）を識別するためのＩＤを示す。デバイスＩＤ７０２に格納する値は、ＰＣ１０３が生成して決定してもよいし、それぞれのＭＦＰから取得した値であってもよい。

イベント登録７０３は、デバイスＩＤ７０２で示すＭＦＰに対してイベント通知依頼済みかどうか（ＯＮ／ＯＦＦ）を示す。イベント登録７０３がＯＮであればＭＦＰに対してイベント通知依頼済みであることを示し、イベント登録７０３がＯＦＦであればＭＦＰに対してイベント通知依頼はしていないことを示す。ＩＰアドレス７０４は、ＰＣ１０３がＬＡＮ１１０上のＭＦＰ１０１あるいはＭＦＰ１０２を識別しているＩＰアドレスを示す。ＩＰアドレス７０４には、ＩＰｖ４あるいはＩＰｖ６のアドレスを格納する。

次に、ＭＦＰ１０１が記憶部（ＲＯＭあるいはディスク）に保持しているイベント通知先管理テーブルの構成について図８を用いて説明する。

図８は、ＭＦＰ１０１が保持するイベント通知先管理テーブルの構成を示す図である。

図８において、イベント通知先管理テーブルは、管理ＩＤ８０１、通知先ＩＰアドレス８０２、通知先ポート番号８０３、通知対象イベント８０４から構成される。管理ＩＤ８０１は、イベント通知先管理テーブルのインデックス番号である。ＭＦＰ１０１でイベント通知を登録しているＰＣの数だけインデックス（管理ＩＤ８０１）を付けてイベント通知先管理テーブルに格納する。

通知先ＩＰアドレス８０２は、ＭＦＰ１０１がＰＣに対してイベント通知する際の送信先アドレスとなるＩＰアドレスを格納する。通知先ポート番号８０３は、ＭＦＰ１０１がＰＣに対してイベント通知を送信する際の通知先（送信先）ポート番号を示す。通知対象イベント８０４は、ＭＦＰ１０１からＰＣに対してイベント通知の送信対象とするイベントを示す。

次に、上記の構成を備える本実施の形態のネットワークシステムの動作について図９乃至図１２に基づき説明する。

図９は、ＰＣ１０３がＭＦＰ１０１にイベント通知依頼を送信すると共にイベント通知依頼済みのＭＦＰをＭＦＰ管理テーブルに登録する処理を示すフローチャートである。

図９において、ステップＳ９０１では、ＰＣ１０３のＣＰＵ２０１は、イベント通知依頼（ＭＦＰでイベントが発生した際にＭＦＰからイベント通知をＰＣに送信させるように予めＭＦＰに登録するための依頼）を送信するＭＦＰ及び通知対象イベントを決定する。イベント通知依頼を送信するＭＦＰはユーザに設定させてもよいし、ＭＦＰ探索のためのパケットをブロードキャストしてＬＡＮ内の管理対象のＭＦＰを探索して決定してもよい。通知対象イベントとしては、ＰＣ１０３がＭＦＰから受信して処理するイベントを設定する。

ステップＳ９０２では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ９０１で決定したイベント通知依頼をＭＦＰに行うためのイベント通知依頼の送信パケット（イベント通知依頼パケット）を生成する。生成するイベント通知依頼パケットの詳細構成は図４で説明したとおりである。更に、ＰＣ１０３のＣＰＵ２０１は、ステップＳ９０１で決定したイベント通知依頼を送信するＭＦＰのＩＰアドレスをイベント通知依頼の送信先アドレス部４２３に格納し、ＰＣ１０３のＩＰアドレスをイベント通知依頼の送信元アドレス部４２２に格納する。

ステップＳ９０３では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ９０２で生成した図４に示すイベント通知依頼パケットを、ステップＳ９０１で決定したＭＦＰに対してネットワークＩ／Ｆ２０９及びＬＡＮ１１０を介して送信する。

ステップＳ９０４では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ９０３でＭＦＰに送信したイベント通知依頼に対するＭＦＰからの返信パケット（リプライ）を受信する。イベント通知依頼の返信パケットの詳細構成は図５で説明したとおりである。尚、上述したとおり、ＭＦＰから受信した返信パケットについては、ＰＣ１０３のＣＰＵ２０１は、図５のヘッダ部５０１、ＢｌｏｃｋＮｏ部５０２、オペレーションコード部５０３に示す値を参照する。これにより、ステップＳ９０３でＭＦＰに送信したイベント通知依頼に対する返信パケットであると判断することができる。

ステップＳ９０５では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ９０４でＭＦＰから受信したイベント通知依頼の返信パケットのステータスコード部５０５を参照して、ＭＦＰに対するイベント通知依頼が成功（ＯＫ）か失敗（ＮＧ）かを判断する。ＭＦＰに対するイベント通知依頼が成功した場合は、ステップＳ９０６へ進む。ＭＦＰに対するイベント通知依頼が失敗した場合は、本処理を終了する。

ステップＳ９０６では、ＰＣ１０３のＣＰＵ２０１は、図５に示すイベント通知依頼の返信パケットの送信元アドレス部５２２を読み出す。尚、ステップＳ９０６で読み出す送信元アドレス部５２２のＩＰアドレスは、ステップＳ９０２で設定したイベント通知依頼の送信先アドレス部４２３のＩＰアドレスとは一致していなくてもよい。

ステップＳ９０７では、ＰＣ１０３のＣＰＵ２０１は、イベント通知依頼済みのＭＦＰとして図７で示したＭＦＰ管理テーブルに登録する。その際、ステップＳ９０６で読み出した送信元アドレス部５２２に含まれるＩＰアドレスをＭＦＰのＩＰアドレス７０４としてＭＦＰ管理テーブルに登録する。即ち、ＰＣ１０３のイベント通知依頼に対してＭＦＰより返信された返信パケットから送信元アドレスを取得し、イベント通知依頼済み装置のアドレスとして登録する。また、ＰＣ１０３のＣＰＵ２０１は、ＭＦＰ管理テーブルにおけるイベント登録済みかどうかを示すイベント登録７０３もＯＮに設定する。これにより、本処理を終了する。

図１０は、ＰＣ１０３がＭＦＰ１０１から送信されるイベント通知パケットを受信すると共にイベント通知パケットを解析した結果に応じて実行する処理を示すフローチャートである。

図１０において、ＰＣ１０３に対してＭＦＰ１０１から送信されるイベント通知パケットは図６に示す構成である。ステップＳ１００１では、ＰＣ１０３のＣＰＵ２０１は、ＭＦＰ１０１から送信されたイベント通知パケットをＬＡＮ１１０及びネットワークＩ／Ｆ２０７を介して受信する。更に、ＰＣ１０３のＣＰＵ２０１は、ＭＦＰ１０１から受信したイベント通知パケットの送信元アドレス部６２２からＩＰアドレスを読み出す。

ステップＳ１００２では、ＰＣ１０３のＣＰＵ２０１は、ＭＦＰ１０１から受信したイベント通知パケットがイベント通知依頼済みのＭＦＰから送信されたものかどうかを調べるために、次の検索を行う。即ち、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１００１でイベント通知パケットから読み出したＩＰアドレスをキーにして図７で示したＭＦＰ管理テーブルを検索する。

ステップＳ１００３では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１００２で行った検索の結果を判定する。ＭＦＰ管理テーブルにＭＦＰ１０１のエントリが見つかった場合（ＩＰアドレスが一致した場合）は、ステップＳ１００４へ進む。ＭＦＰ管理テーブルにＭＦＰ１０１のエントリが見つからなかった場合（ＩＰアドレスが異なる場合）は、受信したイベント通知パケットを破棄し、本処理を終了する。

ステップＳ１００４では、ＰＣ１０３のＣＰＵ２０１は、ＭＦＰ１０１から受信したイベント通知パケットを解析する。図６で示したイベント通知パケットからヘッダ部６０１〜パラメータ部６０４を読み出すことで、ジョブＩＤが１００１であるジョブについて、ＭＦＰ１０１のメモリフルの発生により、ジョブの状態がオペレータコールに変化したことを示すことが分かる。また、ステップＳ１００２のＭＦＰ管理テーブルの検索で見つかったエントリに対応するＭＦＰ１０１からのイベント通知であることが分かる。

ステップＳ１００５では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１００４でイベント通知パケットを解析した結果に応じた処理を行う。これにより、本処理を終了する。尚、ＰＣ１０３が例えば図６に示すイベント通知パケットをＭＦＰから受信した場合は、当該ジョブがオペレータコールで停止していることを知らせるユーザインタフェース（ＵＩ）表示を行う、ジョブキャンセルのためのコマンドを送信する、等が考えられる。前記表示や送信は一例であり、特に限定するものではない。

図１１は、ＭＦＰ１０１がＰＣ１０３から送信されるイベント通知依頼の送信パケットを受信すると共にイベント通知依頼の返信パケットを生成してＰＣ１０３に送信する処理を示すフローチャートである。

図１１において、ＭＦＰ１０１がＰＣ１０３から受信するイベント通知依頼の送信パケットは図４に示す構成である。ステップＳ１１０１では、ＭＦＰ１０１のＣＰＵ３０１は、ＰＣ１０３から送信されたイベント通知依頼の送信パケットをＬＡＮ１１０及びネットワークＩ／Ｆ３０９を介して受信する。

ステップＳ１１０２では、ＭＦＰ１０１のＣＰＵ３０１は、ＰＣ１０３から受信したイベント通知依頼の送信パケットを解析し、イベント通知登録を行うために図８で示したイベント通知先管理テーブルに登録して更新する。ここで、図４の送信パケットのＩＰ部４１１の値を通知先ＩＰアドレス８０２に登録し、ポート部４１２の値を通知先ポート８０３に登録し、イベントＩＤ部４１３の値を通知対象イベント８０４に登録する。

ステップＳ１１０３では、ＭＦＰ１０１のＣＰＵ３０１は、イベント通知依頼に対する返信パケットを送信するアドレス（図５の送信元アドレス部５２２のＩＰアドレス）を決定する。ＭＦＰ１０１のＣＰＵ３０１は、ステップＳ１１０１で受信したイベント通知依頼の送信パケットの送信元アドレス部４２２からＩＰアドレスとポート番号を取得し、送信先アドレスとする。

尚、イベント通知依頼の返信パケットの送信元アドレス部５２２のＩＰアドレスは、以下のように設定する。ステップＳ１１０３で決定したイベント通知依頼の返信パケットの送信先アドレス部５２３のＩＰアドレスとのLongestMatchにより、ＭＦＰ１０１が持つ複数のＩＰアドレスから一つを選択して設定する。

ステップＳ１１０４では、ＭＦＰ１０１のＣＰＵ３０１は、ステップＳ１１０２でのイベント通知先管理テーブルに対する登録更新処理の結果と、ステップＳ１１０３で決定した送信先アドレスとを基に、図５に示すイベント通知依頼の返信パケットを生成する。

ステップＳ１１０５では、ＭＦＰ１０１のＣＰＵ３０１は、ステップＳ１１０４で生成したイベント通知依頼の返信パケットを、ステップＳ１１０３で決定したＰＣ１０３の送信アドレスにネットワークＩ／Ｆ３０９及びＬＡＮ１１０を介して送信する。これにより、本処理を終了する。

図１２は、ＭＦＰ１０１がイベント発生時に予めＰＣ１０３から依頼されているイベント通知をＰＣ１０３に送信する処理を示すフローチャートである。

図１２において、ステップＳ１２０１では、ＭＦＰ１０１のＣＰＵ３０１は、ＭＦＰ１０１でイベント発生を検知するまでイベント発生の有無の判定を繰り返し行う。ＭＦＰ１０１でイベントが発生した場合は、ステップＳ１２０２へ進む。

ステップＳ１２０２では、ＭＦＰ１０１のＣＰＵ３０１は、ステップＳ１２０１で検知したイベントについて、ＰＣ１０３からイベント通知依頼がされているか否かをチェックするため、ＭＦＰ１０１が保持する図８のイベント通知先管理テーブルを検索する。

例えば、発生したイベントがジョブの状態変化を示す“JobStateChanged”である場合は、これをキーにして図８のイベント通知先管理テーブルの通知対象イベント８０４を検索する。図８のイベント通知先管理テーブルの例では、“JobStateChanged”を含む管理ＩＤ１、管理ＩＤ２のエントリがそれぞれ該当する。該当するエントリが見つかった場合は、ステップＳ１２０３へ進む。該当するエントリが見つからない場合は、ＭＦＰ１０１からＰＣ１０３にイベント通知の送信は行わないため、本処理を終了する。

ステップＳ１２０３では、ＭＦＰ１０１のＣＰＵ３０１は、ステップＳ１２０２で見つかったエントリに対してイベント通知の送信先ＩＰアドレスとポート番号を決定する。図８のイベント通知先管理テーブルの例では、管理ＩＤ１、管理ＩＤ２のそれぞれに対応する通知先ＩＰアドレス８０２及び通知先ポート番号８０３を、それぞれのイベント通知の送信先アドレスとして決定する。

ステップＳ１２０４では、ＭＦＰ１０１のＣＰＵ３０１は、ステップＳ１２０１で検知したイベントをＰＣ１０３に通知（送信）するためのイベント通知パケットを生成する。生成するイベント通知パケットの詳細構成は図６を用いて説明したとおりである。イベント通知パケットは、ステップＳ１２０１で検知したイベント、ステップＳ１２０２で見つかったイベント通知先管理テーブルのエントリ、ステップＳ１２０３で決定したイベント通知の送信先ＩＰアドレス、ＭＦＰ１０１のＩＰアドレスに基づき生成する。

尚、図６のイベント通知パケットの送信元アドレス部６２２のＩＰアドレスは、イベント通知の送信先アドレス部６２３とのLongestMatchにより、ＰＣ１０３が持つ複数のＩＰアドレスから一つを選択して設定する。例えば、イベント通知の送信先ＩＰアドレスである2001:db8:abcd::e/64との比較により、2001:db8:aaaa::a/64と2001:db8:bbbb::b/64から2001:db8:aaaa::a/64を選択する。

ステップＳ１２０５では、ＭＦＰ１０１のＣＰＵ３０１は、次の送信を行う。即ち、ステップＳ１２０４で生成したイベント通知パケットを、ステップＳ１２０３で決定した送信先ＩＰアドレス及びポート番号を有するＰＣ１０３に対してネットワークＩ／Ｆ３０９及びＬＡＮ１１０を介して送信する。イベント通知パケットの送信が完了すると、本処理を終了する。

以上詳細に説明したように、本実施の形態によれば以下の効果を奏する。ＰＣは、予めイベント通知依頼を送信した送信先のＭＦＰのＩＰアドレスとは異なるＩＰアドレスを送信元とするイベント通知を受信した場合でも、前記イベント通知依頼を送信した送信先のＭＦＰからのイベント通知として処理することができる。

即ち、ＰＣは、イベント通知依頼の送信先ＩＰアドレスとイベント通知の送信元ＩＰアドレスとが異なる場合でも、ＰＣからイベント通知依頼済みのＭＦＰとイベント通知をＰＣに送信したＭＦＰとの対応付けが可能となる。これにより、ＰＣは、複数のＩＰアドレスを有するＭＦＰからＭＦＰの状態やジョブの状態等のイベント通知が送信されてきた場合に、イベント通知の送信元のＭＦＰを正しく識別して適切な処理を行うことが可能となる。

〔第２の実施の形態〕
本発明の第２の実施の形態は、上記第１の実施の形態に対して、図１３及び図１４で説明する点において相違する。本実施の形態のその他の要素は、上記第１の実施の形態（図１、図２、図３）の対応するものと同一なので説明を省略する。

図１３は、本実施の形態に係るＰＣ１０３が保持するＭＦＰ管理テーブルの構成を示す図である。

図１３において、ＭＦＰ管理テーブルは、管理ＩＤ１３０１、デバイスＩＤ１３０２、イベント登録１３０３、第１のＩＰアドレス１３０４、第２のＩＰアドレス１３０５から構成される。管理ＩＤ１３０１は、ＭＦＰ管理テーブルのインデックス番号である。ＰＣ１０３では、管理しているＭＦＰの数だけインデックスを付けてＭＦＰ管理テーブルに格納する。

デバイスＩＤ１３０２は、ＰＣ１０３がＭＦＰ（デバイス）を識別するためのＩＤを示す。デバイスＩＤ１３０２に格納する値は、ＰＣ１０３が生成して決定してもよいし、それぞれのＭＦＰから取得した値であってもよい。イベント登録１３０３は、デバイスＩＤ１３０２で示すＭＦＰに対してイベント通知依頼済みかどうかを示す。イベント登録１３０３がＯＮであればイベント通知依頼済みを示し、イベント登録１３０３がＯＦＦであればイベント通知依頼は行っていないことを示す。

第１のＩＰアドレス１３０４は、ＰＣ１０３がＬＡＮ１１０上のＭＦＰ１０１あるいはＭＦＰ１０２を識別している第１のＩＰアドレスを示す。第１のＩＰアドレス１３０４には、ＩＰｖ４あるいはＩＰｖ６のアドレスを格納する。第２のＩＰアドレス１３０５は、ＰＣ１０３がＬＡＮ１１０上のＭＦＰ１０１あるいはＭＦＰ１０２を識別している第２のＩＰアドレスを示す。第２のＩＰアドレス１３０５には、ＩＰｖ４あるいはＩＰｖ６のアドレスを格納する。

尚、図１３のＭＦＰ管理テーブルにＭＦＰ１０１及び１０２のそれぞれについて第１のＩＰアドレスと第２のＩＰアドレスの２つのＩＰアドレスを格納するように構成しているが、これに限定されるものではない。ＭＦＰ管理テーブルに３つ以上のＩＰアドレスを格納することが可能な構成としてもよい。

図１４は、ＰＣ１０３がＭＦＰ１０１にイベント通知依頼を送信すると共にイベント通知依頼済みのＭＦＰのアドレスをＭＦＰ管理テーブルに登録する処理を示すフローチャートである。

図１４において、ステップＳ１４０１〜ステップＳ１４０６の処理は、上記第１の実施の形態で説明した図９のステップＳ９０１〜Ｓ９０６の処理と同様であるため説明を省略する。ステップＳ１４０７以降について説明する。

ステップＳ１４０７では、ＰＣ１０３のＣＰＵ２０１は、イベント通知依頼の返信パケット（イベント通知依頼パケット）から読み出した送信元アドレスを、イベント通知依頼済みのＭＦＰのアドレスとして図１３のＭＦＰ管理テーブルに登録する。その際、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１４０６で読み出したイベント通知依頼の返信パケットの送信元アドレス部５２２に含まれるＩＰアドレスを、ＭＦＰ管理テーブルの第１のＩＰアドレス１３０４にＭＦＰの第１のＩＰアドレスとして登録する。また、ＰＣ１０３のＣＰＵ２０１は、イベント登録済みかどうかを示すイベント登録１３０３もＯＮに設定する。

ステップＳ１４０８では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１４０１で決定してステップＳ１４０３でイベント通知依頼パケットを送信した送信先のＭＦＰのＩＰアドレスを格納した送信先アドレス部４２３からＩＰアドレスを読み出す。更に、ＰＣ１０３のＣＰＵ２０１は、読み出したＩＰアドレスを、ＭＦＰ管理テーブルの第２のＩＰアドレス１３０５にＭＦＰの第２のＩＰアドレスとして格納する。即ち、イベント通知依頼に対してＭＦＰから返信された返信パケットから取得した送信元アドレスに加えて、イベント通知依頼を送信した送信先のＭＦＰを示す送信先アドレスを、イベント通知依頼済み装置のアドレスとして登録する。

以上詳細に説明したように、本実施の形態によれば以下の効果を奏する。ＰＣは、予めイベント通知依頼を送信した送信先のＭＦＰのＩＰアドレスとは異なるＩＰアドレスと、予めイベント通知依頼を送信した送信先のＭＦＰのＩＰアドレスを送信元としたイベント通知のそれぞれを受信することができる。更に、ＰＣは、受信したイベント通知を前記イベント通知依頼を送信した送信先のＭＦＰからのイベント通知として処理することができる。

〔第３の実施の形態〕
本発明の第３の実施の形態は、上記第１の実施の形態に対して、図１５で説明する点において相違する。本実施の形態のその他の要素は、上記第１の実施の形態（図１、図２、図３）の対応するものと同一なので説明を省略する。

図１５は、本実施の形態に係るＰＣ１０３がＭＦＰ１０１にイベント通知依頼を送信すると共にイベント通知依頼済みのＭＦＰのアドレスをＭＦＰ管理テーブルに登録する処理を示すフローチャートである。

図１５において、ステップＳ１５０１〜ステップＳ１５０６の処理は、上記第１の実施の形態で説明した図９のステップＳ９０１〜ステップＳ９０６の処理と同様であるため説明を省略する。ステップＳ１５０７以降について説明する。

ステップＳ１５０７では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１５０１で決定してステップＳ１５０３でイベント通知依頼パケットを送信した送信先のＭＦＰのＩＰアドレスを格納した送信先アドレス部４２３からＩＰアドレスを読み出す。更に、ＰＣ１０３のＣＰＵ２０１は、前記送信先アドレス部４２３に含まれるＩＰアドレスと、ステップＳ１５０６で読み出したイベント通知依頼の返信パケットの送信元アドレス部５２２に含まれるＩＰアドレスとを比較する（第２の比較手段）。

ステップＳ１５０８では、ＰＣ１０３のＣＰＵ２０１は、ステップＳ１５０７の比較結果を判定し、両方のＩＰアドレスが一致した場合は、ステップＳ１５０９に進み、両方のＩＰアドレスが一致せず異なる場合は、ステップＳ１５１０へ進む。尚、ステップＳ１５０９の処理は、上記第１の実施の形態で説明した図９のステップＳ９０７の処理と同様であるため説明を省略する。

ステップＳ１５１０では、ＰＣ１０３のＣＰＵ２０１は、次の依頼を行う。ステップＳ１５０３でイベント通知依頼パケットを送信した送信先のＭＦＰの送信先アドレスに対してイベント通知依頼を削除する依頼を送信し、一旦イベント通知依頼を行った内容の削除をＭＦＰに対して依頼する。

ＰＣ１０３のＣＰＵ２０１は、イベント通知依頼の削除を行った後、イベント通知依頼の送信先アドレスとして、ステップＳ１５０６で読み出したＩＰアドレスを設定し、ステップＳ１５０２へ戻る。その後、再度、イベント通知依頼パケットを生成する処理以降をやり直す。即ち、返信パケットに含まれる送信元アドレスを有するＭＦＰに対してイベント通知依頼パケットをＰＣ１０３から再度送信する。

以上詳細に説明したように、本実施の形態によれば以下の効果を奏する。ＰＣは、予めイベント通知依頼を送信した送信先のＭＦＰのＩＰアドレスとは異なるＩＰアドレスを送信元とするイベント通知依頼の返信を受信した場合、イベント通知依頼の返信の送信元ＩＰアドレスに対してイベント通知依頼を送信し直すことができる。また、ＰＣは、ＰＣからＭＦＰに送信したイベント通知依頼に基づいてＭＦＰから送信されるイベント通知を受信した場合、イベント通知依頼を送信した送信先のＭＦＰからのイベント通知として処理することができる。

〔他の実施の形態〕
第１乃至第３の実施の形態では、ネットワークシステムを図１に示す構成としたが、これに限定されるものではない。ネットワーク接続している情報処理装置の台数（２）、画像処理装置の台数（２）及び種類（ＭＦＰ）は一例であり、構築するネットワーク環境に応じた仕様とすることが可能である。

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

１０１、１０２ ＭＦＰ
１０３、１０４ ＰＣ
２０１ ＰＣのＣＰＵ
３０１ ＭＦＰのＣＰＵ

Claims (5)

1. 印刷を含むジョブの処理が可能な画像処理装置とネットワークを介して通信が可能な情報処理装置であって、
   画像処理装置でジョブの状態変化を含むイベントが発生した際にイベント通知を送信するよう依頼するイベント通知依頼パケットを前記画像処理装置に送信する依頼手段と、
   前記依頼手段により前記イベント通知依頼パケットを送信した送信先の前記画像処理装置から返信された返信パケットから送信元アドレスを取得し、イベント通知依頼済み装置のアドレスとして登録する登録手段と、
   画像処理装置からイベント通知パケットを受信した場合、前記イベント通知パケットから送信元アドレスを取得し、該取得した送信元アドレスと前記登録手段により登録された前記イベント通知依頼済み装置のアドレスとを比較する比較手段と、
   前記比較手段により前記送信元アドレスと前記イベント通知依頼済み装置のアドレスとが一致すると判定された場合、前記イベント通知パケットを送信してきた画像処理装置を前記登録手段により登録した画像処理装置であると判断する判断手段と、
   を備えることを特徴とする情報処理装置。
2. 前記登録手段は、前記依頼手段により前記イベント通知依頼パケットを送信した送信先の前記画像処理装置から返信された返信パケットから取得した送信元アドレスに加えて、前記イベント通知依頼パケットを送信した送信先の前記画像処理装置の送信先アドレスを、前記イベント通知依頼済み装置のアドレスとして登録することを特徴とする請求項１記載の情報処理装置。
3. 前記依頼手段により前記イベント通知依頼パケットを送信した送信先の前記画像処理装置から返信された返信パケットから取得した送信元アドレスと、前記イベント通知依頼パケットを送信した送信先の前記画像処理装置の送信先アドレスとを比較する第２の比較手段を備え、
   前記依頼手段は、前記第２の比較手段により前記送信元アドレスと前記送信先アドレスとが異なると判定された場合、前記画像処理装置から返信された前記返信パケットから取得した送信元アドレスに対してイベント通知依頼パケットを再度送信することを特徴とする請求項１又は２記載の情報処理装置。
4. 印刷を含むジョブの処理が可能な画像処理装置とネットワークを介して通信が可能な情報処理装置の制御方法であって、
   画像処理装置でジョブの状態変化を含むイベントが発生した際にイベント通知を送信するよう依頼するイベント通知依頼パケットを前記画像処理装置に送信する依頼ステップと、
   前記依頼ステップにより前記イベント通知依頼パケットを送信した送信先の前記画像処理装置から返信された返信パケットから送信元アドレスを取得し、イベント通知依頼済み装置のアドレスとして登録する登録ステップと、
   画像処理装置からイベント通知パケットを受信した場合、前記イベント通知パケットから送信元アドレスを取得し、該取得した送信元アドレスと前記登録ステップにより登録された前記イベント通知依頼済み装置のアドレスとを比較する比較ステップと、
   前記比較ステップにより前記送信元アドレスと前記イベント通知依頼済み装置のアドレスとが一致すると判定された場合、前記イベント通知パケットを送信してきた画像処理装置を前記登録ステップにより登録した画像処理装置であると判断する判断ステップと、を有することを特徴とする制御方法。
5. 請求項４に記載の情報処理装置の制御方法をコンピュータに実行させるためのコンピュータで読み取り可能なプログラムコードを有するプログラム。