(57)【要約】【課題】プリンタにおけるエラー解除イベントの確認をクライアントＰＣで確実に行う。【解決手段】プロキシサーバ１２１は、プリンタ１０１〜１０３及びクライアントＰＣ１１１〜１１３にネットワーク１００を介して接続されている。プロキシサーバはプリンタで発生したイベントを示すイベントメッセージを受信した際、当該イベントメッセージをクライアント装置に転送する。そして、プロキシサーバはクライアントＰＣに転送したイベントメッセージがプリンタにおけるエラーを示すエラーイベントであると、プリンタにおいてエラーイベントの解除が行われたか否かを監視して、プリンタにおいてエラーイベントの解除が行われると、クライアントＰＣにエラーイベントが解除された旨を示すエラー解除メッセージを通知する。【選択図】図１
2012037976.tif 000002
【特許請求の範囲】
【請求項１】
端末装置とクライアント装置とにネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを受信した際、当該イベントメッセージを前記クライアント装置に転送するサーバ装置であって、
前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視手段と、
前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知手段とを有することを特徴とするサーバ装置。
【請求項２】
前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、当該エラーイベントが未送信であることを示すエラー解除未送信情報を、前記エラー解除メッセージが送信されるまで保持する保持手段を有することを特徴とする請求項１記載のサーバ装置。
【請求項３】
前記クライアント装置から前記イベントの通知要求を受信した場合に、当該クライアント装置に前記イベントメッセージの通知を行うメッセージ通知手段を有することを特徴とする請求項１又は２記載のサーバ装置。
【請求項４】
前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントであると、当該登録イベントについて予め登録されたイベント通知先に通知する第１のイベント通知手段を有することを特徴とする請求項１〜３いずれか１項記載のサーバ装置。
【請求項５】
前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントであると、当該イベントが前記エラーイベントであるか否かを判定するエラー判定手段と、
前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定手段と、
前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知する第２のイベント通知手段とを有することを特徴とする請求項４記載のサーバ装置。
【請求項６】
前記監視手段は、予め定められた周期で前記端末装置において前記エラーイベントの解除が行われたか否かを確認することを特徴とする請求項１〜５いずれか１項記載のサーバ装置。
【請求項７】
端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する通信システムであって、
前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定手段と、
前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定手段と、
前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知手段とを備え、
前記サーバ装置は、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視手段と、
前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知手段とを備えることを特徴とする通信システム。
【請求項８】
端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する際に用いられる通信制御方法であって、
前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定ステップと、
前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定ステップと、
前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知ステップとを実行し、
前記サーバ装置は、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視ステップと、
前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知ステップとを実行することを特徴とする通信制御方法。
【請求項９】
端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する際に用いられる通信制御プログラムであって、
前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
前記端末装置が備えるコンピュータに、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定ステップと、
前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定ステップと、
前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知ステップとを実行させ、
前記サーバ装置が備えるコンピュータに、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視ステップと、
前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知ステップとを実行させることを特徴とする通信制御プログラム。
【請求項１０】
請求項９に記載の通信制御プログラムが記録されたコンピュータに読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体に関し、特に、サーバ装置、クライアント装置、及び端末装置が相互にネットワークで接続された通信システムに関する。
【背景技術】
【０００２】
一般に、ＷＳ−Ｅｖｅｎｔｉｎｇ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｅｖｅｎｔｉｎｇ）を用いた通信システムにおいては、クライアント装置であるクライアントＰＣ（パーソナルコンピュータ）がイベント通知装置（端末装置）に対してイベント通知要求のための登録（以下、イベント登録と呼ぶ）を行う。
【０００３】
イベント通知装置は、イベントが発生するとイベント登録された全てのクライアントＰＣに対してイベントメッセージを送信する。これによって、クライアントＰＣはネットワーク上に存在する多種多様なイベント通知装置の状況をリアルタイムで把握することができる。そして、イベント通知装置の状況をリアルタイムで把握すれば、空いているイベント通知装置の効率的な利用及び故障時の迅速でかつ円滑なトラブル解決を行うことが可能となる。
【０００４】
イベント通知装置をプリンタとすると、イベントの種類として、例えば、ジョブ状態変化イベント、紙詰まり、トナー及びインク切れ、及びプリンタ本体の故障等のエラーイベントがある。クライアントＰＣによっては、プリンタからエラーイベントメッセージが送信されると、以後、イベント通知元のプリンタが故障中であると判断し、そのプリンタの使用を禁止する。そのため、プリンタは、エラーから復旧した場合にはエラー解除イベントメッセージをクライアントＰＣ側に送信する必要がある。
【０００５】
エラー解除イベントメッセージを送信しないと、プリンタが復旧したにも関わらず、クライアントＰＣは当該プリンタを故障中と判断して使用を禁止したままとなってしまう。
【０００６】
ところで、上記のエラーイベントメッセージの送信履歴情報を記憶して、エラー発生時には、エラー復旧した際のエラー解除イベントを確実にクライアントＰＣに送信するようにしたものがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−６５７５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところが、一般に安価なプリンタでは、不揮発性の記憶媒体を備えないことがあり、たとえ不揮発性の記録媒体が備えられていたとしても、その容量は少ない。このようなプリンタにおいては、特許文献１に記載のようにエラーイベントメッセージの送信履歴情報を記憶しておくことが困難である。
【０００９】
つまり、容量が少なければ、エラーが解除された際には、他の情報が別に書き込まれて、エラーイベントメッセージの送信先履歴情報が消えている可能性がある。その結果、エラー解除イベントメッセージを確実にクライアントＰＣに送信することができない。
【００１０】
よって、上述のように安価なプリンタが接続された通信システムにおいては、クライアントＰＣはエラー解除イベントの確認を行うことが難しいという課題がある。
【００１１】
従って、本発明の目的は、確実にエラー解除イベントの確認を行うことのできるサーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体を提供することにある。
【課題を解決するための手段】
【００１２】
上記の目的を達成するため、本発明によるサーバ装置は、端末装置とクライアント装置とにネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを受信した際、当該イベントメッセージを前記クライアント装置に転送するサーバ装置であって、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視手段と、前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知手段とを有することを特徴とする。
【００１３】
本発明による通信システムは、端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する通信システムであって、前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定手段と、前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定手段と、前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知手段とを備え、前記サーバ装置は、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視手段と、前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知手段とを備えることを特徴とする。
【００１４】
本発明による通信制御方法は、端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する際に用いられる通信制御方法であって、前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定ステップと、前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定ステップと、前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知ステップとを実行し、前記サーバ装置は、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視ステップと、前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知ステップとを実行することを特徴とする。
【００１５】
本発明による通信制御プログラムは、端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する際に用いられる通信制御プログラムであって、前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、前記端末装置が備えるコンピュータに、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定ステップと、前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定ステップと、前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知ステップとを実行させ、前記サーバ装置が備えるコンピュータに、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視ステップと、前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知ステップとを実行させることを特徴とする。
【００１６】
本発明による記録媒体は、上記の通信制御プログラムが記録されたコンピュータに読み取り可能な記録媒体である。
【発明の効果】
【００１７】
本発明よれば、サーバ装置が端末装置のエラー発生状況を監視・確認して、エラーが解除されると、エラー解除メッセージをクライアント装置に送信する。これによって、クライアント装置は、端末装置におけるエラー解除を確実に知ることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の第１の実施形態による通信システムの一例を示す図である。
【図２】図１に示すＤＰ及びクライアントＰＣの各々のハードウェア構成の一例を示すブロック図である。
【図３】図１に示すプリンタの各々のハードウェア構成の一例を示すブロック図である。
【図４】図１に示すＤＰ又はクライアントＰＣに備えられたＨＤに記憶されるデバイス情報の一例を示す図である。
【図５】図１及び図２に示すＤＰにおいてデバイス情報登録を行う際の処理を説明するためのフローチャートである。
【図６】図１及び図３に示すプリンタの各々においてＧｅｔメッセージ受信からＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージの送信処理に至るまでの手順を説明するためのフローチャートである。
【図７】図１及び図２に示すクライアントＰＣの各々においてプリンタの検索処理の手順を説明するためのフローチャートである。
【図８】図１及び図２に示すＤＰにおいてクライアントＰＣからＤＰ検索要求を受信して検索応答をクライアントＰＣに送信するまでの処理を説明するためのフローチャートである。
【図９】図１及び図２に示すＤＰにおいてクライアントＰＣからデバイス検索要求を受信した場合の処理を説明するためのフローチャートである。
【図１０】図７に示す処理においてクライアントＰＣからＧｅｔメッセージを受信した際のＤＰにおける処理を説明するためのフローチャートである。
【図１１】図１及び図３に示すクライアントＰＣにおいて、検索したデバイスの情報を表示する際に用いられるユーザインターフェース（ＵＩ）の一例を示す図である。
【図１２】図１及び図３に示すクライアントＰＣにおいてデバイス検索によって検索されたデバイスに対してイベント登録処理を行う手順を説明するためのフローチャートである。
【図１３】図１及び図２に示すＤＰがクライアントＰＣからＳｕｂｓｃｒｉｂｅリクエストを受信してからプリンタにＳｕｂｓｃｒｉｂｅリクエストを送信するまでの処理を説明するためのフローチャートである。
【図１４】図２に示すＤＰのＨＤに記憶された代行イベント情報の一例を示す図である。
【図１５】図３に示すプリンタのＲＡＭに記憶されるイベント登録情報の一例を示す図である。
【図１６】は、図１及び図３に示すプリンタにおいてイベントが発生した際の処理の手順を説明するためのフローチャートである。
【図１７】図１及び図２に示すＤＰにおいてプリンタからイベントメッセージを受信してクライアントＰＣに当該イベントを転送するまでの処理を説明するためのフローチャートである。
【図１８】図１及び図２に示すＤＰ１２１においてプリンタのエラー解除状態を確認して、エラー解除イベントメッセージをクライアントＰＣに送信するまでの処理を説明するためのフローチャートである。
【図１９】図３に示すＲＡＭに記憶されるイベント登録情報の一例を示す図である。
【図２０】図１及び図３に示すプリンタにおいてイベントが発生した場合の処理の手順を説明するためのフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態による通信システムの一例について図面を参照して説明する。
【００２０】
（第１の実施形態）
図１は、本発明の第１の実施形態による通信システムの一例を示す図である。
【００２１】
図１を参照すると、図示の通信システムにおいては、イベント通知装置である複数のプリンタ（端末装置）１０１〜１０３が備えられている。そして、プリンタ１０１〜１０３はクライアント装置である複数のクライアントＰＣ１１１〜１１３とプロキシサーバ（サーバ装置：Ｄｅｖｉｃｅ  ｐｒｏｘｙ（以下ＤＰと呼ぶ））とネットワーク１００を介して接続されている。
【００２２】
図示のプリンタ１０１〜１０３は、プリンタ本来の機能であるプリント機能を有するとともに、ＷＳ−Ｅｖｅｎｔｉｎｇを用いてイベント登録元にイベントメッセージを送信するイベント送信機能を有している。図示の例では、イベントの内容として、ジョブ状態変化イベント、紙詰まり、トナー又はインク切れ、そして、その他プリンタ本体の故障等のエラーイベントがある。さらに、プリンタ１０１〜１０３の各々は、リクエストに応じたリクエストレスポンスによってジョブ状態変化及びエラー状態を返答するエラー返答機能を有している。
【００２３】
加えて、図示のプリンタ１０１〜１０３の各々は、不揮発記録媒体を備えているが、その容量が少ないためにイベント登録元に関する情報を不揮発記録媒体には記憶せず、例えば、ＲＡＭ等の揮発性記録媒体に記憶するものとする。従って、電源がオン／オフされた場合には、プリンタ１０１〜１０３においては、イベント登録元に関する情報の全てが消えてしまう。そのため、電源のオン／オフ後においては、たとえ、エラーが解除されても、プリンタ１０１〜１０２はエラー解除イベントメッセージをイベント登録元に送信することがない。
【００２４】
クライアントＰＣ１１１〜１１３は、例えば、演算、制御、及び表示機能を有するクライアント機器（情報処理装置）である。クライアントＰＣ１１１〜１１３の各々は、少なくともプリンタ１０１〜１０３に対して印刷ジョブを送信（以下、特に言及しない限り「送信する」とはユニキャストで送信することをいう）する。これによって、印刷ジョブを受信したプリンタ１０１〜１０３のいずれかは印刷ジョブに応じた印刷を実行する。
【００２５】
また、クライアントＰＣ１１１〜１１３は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  ｄｙｎａｍｉｃ  Ｄｉｓｃｏｖｅｒｙ）を用いて、プリンタ１０１〜１０３又はＤＰ１２１を検索する検索機能を有する。さらに、クライアントＰＣ１１１〜１１３は、ＷＳ−Ｅｖｅｎｔｉｎｇを用いて、プリンタ１０１〜１０３又はＤＰ１２１に対して、イベント登録メッセージを送信するメッセージ送信機能を有する。そして、クライアントＰＣ１１１〜１１３は、プリンタ１０１〜１０３からエラーイベントメッセージを受信すると、エラー解除イベントメッセージを受信するまで、プリンタ１０１〜１０３に対して印刷ジョブの送信を実行不可とする。
【００２６】
ＤＰ１２１は、クライアントＰＣ１１１〜１１３からのデバイス検索要求に応じてプリンタ１０１〜１０３を検索して、その検索結果をクライアントＰＣ１１１〜１１３に返答する検索・返答機能を有している。図示の例では、クライアントＰＣ１１１〜１１３はＤＰ検索によってＤＰ１２１を発見した場合には、ＤＰ１２１にプリンタ検索を依頼する。
【００２７】
そして、クライアントＰＣ１１１〜１１３はＤＰ１２１によって検索されたプリンタ１０１〜１０３に対するイベント登録もＤＰ１２１に依頼する。これによって、ＤＰ１２１はクライアントＰＣ１１１〜１１３に代わってイベント登録を行う。
【００２８】
プリンタ１０１〜１０３においてイベントが発生した場合、プリンタ１０１〜１０３はＤＰ１２１に対してイベントメッセージを送信する。プリンタ１０１〜１０３で発生したイベントがエラーイベントの場合には、プリンタ１０１〜１０３はＤＰ１２１に対してエラーイベントメッセージを送信する。
【００２９】
ＤＰ１２１は、エラーイベント（つまり、エラーイベントメッセージ）を受信すると、一定間隔（所定の間隔）でプリンタ１０１〜１０３にエラー状態を問い合わせる。一方、エラーが解除された旨の返答を受けると、ＤＰ１２１はクライアントＰＣ１０１〜１０３にエラー解除イベントメッセージを送信する。
【００３０】
クライアントＰＣ１１１〜１１３が直接プリンタ１０１〜１０３に対してイベント登録を行うようにしてもよいが、その場合には、プリンタ１０１〜１０３においてエラーイベントが発生しても、プリンタ１０１〜１０３はクライアントＰＣ１１１〜１１３にはエラーイベントは通知しない。そして、前述のように、プリンタ１０１〜１０３は電源がオン／オフされると、イベント登録元に関する情報が消えてしまい、エラー解除イベントメッセージをイベント登録元に送信することができない。
【００３１】
図２は、図１に示すＤＰ１２１及びクライアントＰＣ１１１〜１１３の各々のハードウェア構成の一例を示すブロック図である。ここで、ＤＰ１２１及びクライアントＰＣ１１１〜１１３の各々として、所謂汎用ＰＣが使用可能であり、図示のように、ＤＰ１２１及びクライアントＰＣ１１１〜１１３の各々は同様のハードウェア構成を有している。従って、ここでは、ＤＰ１２１を例に挙げて説明することにする。
【００３２】
図２を参照して、ＳＰ１２１はＣＰＵ２０１を有しており、ＣＰＵ２０１はシステムバス２０４に接続された各種デバイスの制御を行う。ＲＯＭ２０２にはＢＩＯＳ及びブートプログラム等が記憶されており、ＲＡＭ２０３はＣＰＵ２０１の主記憶装置として使用される。
【００３３】
キーボードコントローラ（ＫＢＣ）２０５は、マウス（登録商標）等のポインティングデバイス２０９ａ及びキーボード２０９ｂからの入力情報等に係る入力処理を行う。表示制御部（ＣＲＴＣ）２０６は、その内部にビデオメモリを有し、ＣＰＵ２０１からの指示に応じてビデオメモリに描画するととともに、ビデオメモリに描画されたイメージデータをビデオ信号としてＣＲＴ表示装置２１０に出力する。
【００３４】
なお、図２においては、ＣＲＴ表示装置２１０が示されているが、例えば、液晶表示装置又は他の表示装置を用いるようにしてもよい。
【００３５】
ディスクコントローラ（ＤＫＣ）２０７は、ハードディスク（ＨＤ）２１１及びフロッピー（登録商標）ディスク２１２に対するアクセスを行う。ネットワークインタフェースカード（ＮＩＣ）２０８は、ネットワーク１００（図１）に接続して、ネットワーク１００を介して情報通信を行う。なお、ＨＤ２１１には、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）及びＯＳ上で動作する各種アプリケーションプログラム等が格納される。
【００３６】
上記の構成において、電源がオンとなると、ＣＰＵ２０１はＲＯＭ２０２に格納されたブートプログラムに従って、ＨＤ２１１からＯＳをＲＡＭ２０３に読み込み、情報処理装置として機能する。
【００３７】
図３は、図１に示すプリンタ１０１〜１０３の各々のハードウェア構成の一例を示すブロック図である。ここで、プリンタ１０１〜１０３のハードウェア構成は同様であるので、プリンタ１０１を例に挙げて説明する。
【００３８】
図３を参照して、プリンタ１０１は、ＣＰＵ３０１を有している。そして、図示の例では、ＲＯＭ３０３はフォントＲＯＭ部３０３ａ、プログラムＲＯＭ部３０３ｂ、及びデータＲＯＭ部３０３ｃに分けられている。
【００３９】
ＣＰＵ３０１は、プログラム用ＲＯＭ部３０３ｂに記憶された制御プログラムに基づいてシステムバス３０４に接続される各種のデバイスに対するアクセスを総括的に制御する。また、ＣＰＵ３０１は印刷インターフェース３０７を介して接続される印刷部（プリンタエンジン）３１０に出力情報として画像データを出力する。さらに、ＣＰＵ３０１は読取インターフェース（図示せず）を介して接続される読取部（スキャナ：図示せず）から入力される画像信号を受ける。
【００４０】
フォント用ＲＯＭ部３０３ａには、例えば、ＣＰＵ３０１が画像信号から画像データ（出力情報）を生成する際に用いるフォントデータ（アウトラインフォントデータを含む）等が記憶されている。データ用ＲＯＭ部３０３ｃには、ホストコンピュータ（例えば、クライアントＰＣ）で利用される情報等が記憶されている。
【００４１】
ＣＰＵ３０１はＬＡＮコントローラ部３０６を介してネットワーク１００のホストコンピュータ及び画像形成装置（他のプリンタ）との通信処理が可能である。ＲＡＭ３０２は、主にＣＰＵ３０１の主メモリ，ワークエリア等として用いられる。
【００４２】
なお、ＲＡＭ３０２は、揮発性の記憶媒体であり、出力情報展開領域，環境データ格納領域等にも用いられる。そして、ユーザは操作パネル３０５に備えられたソフトウェアキーを用いて各種情報を入力する。
【００４３】
図４は、図１に示すＤＰ１２１又はクライアントＰＣ１１１〜１１３に備えられたＨＤ２１１に記憶されるデバイス情報の一例を示す図である。
【００４４】
ここでは、ＤＰ１２１に備えられるデバイス情報を例に挙げて説明する。図示のデバイス情報管理テーブル４００は、デバイス自体に関する情報（以下デバイス情報と呼ぶ）をレコードとして記憶する。デバイス情報４００は、ＩＤ４０１、ＵＵＩＤ４０２、バージョン４０３、デバイスタイプ４０４、モデル名４０５、デバイス名４０６、ＵＲＬ４０７、ＩＰアドレス４０８、及びＸＭＬ保存パス４０９を有している。
【００４５】
ＩＤ４０１はＤＰにおいてデバイスを管理するにあたって、各デバイスを識別するためのものである。ＵＵＩＤ４０２はデバイスをグローバルに一意に識別するものである。バージョン４０３はデバイス情報のバージョンを表す。デバイスタイプ４０４には複合機を表す「ＭＦＰ」、プリンタを表す「Ｐｒｉｎｔｅｒ」等がある。
【００４６】
モデル名４０５は「ＬＢＰＸＸＸＸ」のようなデバイスのモデル名を表している。デバイス名４０６はデバイス管理者がデバイスに設定した名前である。ＵＲＬ４０７はデバイス情報を取得するためのものである。ＩＰアドレス４０８はデバイスのＩＰアドレスである。ＸＭＬ保存パス４０９は、後述するデバイスから取得したゲットレスポンス（Ｇｅｔ  Ｒｅｓｐｏｎｓｅ）データのＨＤ２１１における保存先を表す。
【００４７】
各プリンタ１０１〜１０３のＣＰＵ３０１は、起動時においてＤＰ１２１に対して、ＸＭＬ形式のＨｅｌｌｏメッセージを送信して、その存在をＤＰ１２１に通知する。Ｈｅｌｌｏメッセージは、＜Ｈｅａｄｅｒ＞タグで囲まれるヘッダ（ｈｅａｄｅｒ部）と＜Ｂｏｄｙ＞タグで囲まれるボディー（ｂｏｄｙ）部５０２とを有している。そして、Ｈｅｌｌｏメッセージの全体が＜Ｅｎｖｅｌｏｐｅ＞タグで囲まれる構造になっている。
【００４８】
ｈｅａｄｅｒ部５０１はメッセージの内容に依存しない共通ヘッダとしての役割を果たしており、＜Ａｃｔｉｏｎ＞タグ、＜Ｍｅｓｓａｇｅ  ＩＤ＞タグ、＜Ｔｏ＞タグが存在する。＜Ａｃｔｉｏｎ＞タグはメッセージの種類を識別するためのものである。そして、＜Ｍｅｓｓａｇｅ  ＩＤ＞タグはメッセージを一意に識別するための識別子である。＜Ｔｏ＞タグはこのメッセージの送信先を識別するためのものである。一方、ｂｏｄｙ部５０２はメッセージの内容に対応してその構造が変化する。
【００４９】
Ｈｅｌｌｏメッセージにおいては、＜Ｂｏｄｙ＞タグの直下に＜Ｈｅｌｌｏ＞タグが存在し、このメッセージがＨｅｌｌｏメッセージであることを示している。＜Ｈｅｌｌｏ＞タグの中には＜Ｅｎｄｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、＜ＸＡｄｄｒｓ＞タグ、及び＜Ｍｅｔａｄａｔａ  Ｖｅｒｓｉｏｎ＞タグが存在する。＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグ中には＜Ａｄｄｒｅｓｓ＞タグが存在し、このタグはデバイスを識別するアドレス情報を有する。
【００５０】
＜Ｔｙｐｅｓ＞タグはデバイスのタイプ情報を有する。＜ＸＡｄｄｒｓ＞タグはデバイス情報を取得するためのＵＲＬを有する。＜Ｍｅｔａｄａｔａ  Ｖｅｒｓｉｏｎ＞タグはデバイス情報のバージョンを有する。
【００５１】
図５は、図１及び図２に示すＤＰ１２１においてデバイス情報登録を行う際の処理を説明するためのフローチャートである。
【００５２】
図２及び図５を参照して、いま、ＤＰ１２１においてＣＰＵ２０１がＨｅｌｌｏメッセージを受信したとする（ステップＳ６０１）。すると、ＣＰＵ２０１は、Ｈｅｌｌｏメッセージからデバイスをグローバルに識別するＵＵＩＤとして＜Ｅｎｄｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ＞タグ中の＜Ａｄｄｒｅｓｓ＞タグの値を抽出する（ステップＳ６０２）。続いて、ＣＰＵ２０１は、＜Ａｄｄｒｅｓｓ＞タグの値と同一のＵＵＩＤを有するレコードがデバイス情報管理テーブル４００に存在するか否かについて調べる（ステップＳ６０３）。
【００５３】
デバイス情報管理テーブル４００に当該レコードが存在しないと（ステップＳ６０３において、ＮＯ）、ＣＰＵ２０１は、受信したＨｅｌｌｏメッセージからデバイスタイプとして＜Ｔｙｐｅｓ＞タグの値を抽出する。さらに、ＣＰＵ２０１は、受信したＨｅｌｌｏメッセージからデバイス情報のバージョンとして＜Ｍｅｔａｄａｔａ  Ｖｅｒｓｉｏｎ＞タグの値を抽出する。加えて、ＣＰＵ２０１は、受信したＨｅｌｌｏメッセージからデバイス情報を取得するためのＵＲＬとして＜ＸＡｄｄｒｓ＞タグの値を抽出する。
【００５４】
そして、ＣＰＵ２０１は、前述の抽出した値と受信したＨｅｌｌｏメッセージの送信元ＩＰアドレスとに基づいて、デバイス情報管理テーブル４００に新規レコードを追加する（ステップＳ６０４）。
【００５５】
続いて、ＣＰＵ２０１は、＜ＸＡｄｄｒｓ＞タグから抽出したＵＲＬに対して、後述するＧｅｔメッセージを送信する（ステップＳ６０５）。図示の例では、＜ＸＡｄｄｒｓ＞タグから抽出したＵＲＬはプリンタ１０１〜１０３のいずれかのＩＰアドレスを示ものとする。
【００５６】
例えば、Ｇｅｔメッセージは、ｈｅａｄｅｒ部のみを有するメッセージであり、ｈｅａｄｅｒ部の＜Ａｃｔｉｏｎ＞タグにおいて、このメッセージがＧｅｔメッセージであることが示される。プリンタ１０１〜１０３のいずれかにおいて、ＣＰＵ３０１（図３）は、Ｇｅｔメッセージを受信すると、Ｇｅｔ  ＲｅｓｐｏｎｓｅメッセージをＤＰ１２１に送信する。そして、ＤＰ１２１において、ＣＰＵ２０１はＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージを受信する（ステップＳ６０５）。
【００５７】
このＧｅｔＲｅｓｐｏｎｓｅメッセージは、例えば、そのｂｏｄｙ部に＜Ｍｅｔａ  ｄａｔａ＞タグで示されるデバイス情報を有する構造となっている。＜Ｍｅｔａ  ｄａｔａ＞タグ中には＜Ｍｅｔａ  ｄａｔａ  Ｓｅｃｔｉｏｎ＞タグで示されるＭｅｔａ  ｄａｔａ  Ｓｅｃｔｉｏｎ部が３つ存在する。各Ｍｅｔａ  ｄａｔａ  Ｓｅｃｔｉｏｎ部はその直下のタグによって、その中に含まれる情報の種類が指定される。
【００５８】
最初のＭｅｔａ  ｄａｔａ  Ｓｅｃｔｉｏｎ部は＜Ｔｈｉｓ  Ｄｅｖｉｃｅ＞タグを有しており、デバイス毎に異なる情報が格納される。＜Ｆｒｉｅｎｄｌｙ  Ｎａｍｅ＞タグは、当該デバイスにつけた名前であり、＜Ｆｉｒｍｗａｒｅ  Ｖｅｒｓｉｏｎ＞タグは、当該デバイスのファームウェアバージョンを示す。また、＜Ｓｅｒｉａｌ  Ｎｕｍｂｅｒ＞タグは当該デバイスのシリアル番号を示す。続くＭｅｔａ  ｄａｔａ  Ｓｅｃｔｉｏｎ部は＜Ｔｈｉｓ  Ｍｏｄｅｌ＞タグを有しており、当該デバイスのモデル毎に異なる情報が格納される。
【００５９】
＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグは当該デバイスの製造会社名を示し、＜Ｍａｎｕｆａｃｔｕｒｅｒ＞タグはデバイス製造会社のＵＲＬを示す。そして、＜Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵＲＬ＞は当該デバイスの情報を示すＵＲＬである。＜Ｍｏｄｅｌ  Ｎａｍｅ＞タグはデバイスのモデル名を示す。
【００６０】
最後のＭｅｔａ  ｄａｔａ  Ｓｅｃｔｉｏｎ部は、＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグを有しており、このタグには当該デバイスが有する内部サービスの情報が格納される。ここでは、内部サービスとはプリンタが提供するプリントサービスを意味する。＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞タグはさらにその直下に＜Ｈｏｓｔｅｄ＞タグを有し、その中に＜Ｅｎｄｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ＞タグ、＜Ｔｙｐｅｓ＞タグ、及び＜ＳｅｒｖｉｃｅＩｄ＞タグが存在する。
【００６１】
＜Ｅｎｄｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ＞タグ中には＜Ａｄｄｒｅｓｓ＞タグが存在し、この＜Ａｄｄｒｅｓｓ＞タグはサービスを利用するためのアドレス情報を有している。＜Ｔｙｐｅｓ＞タグはサービスのタイプ情報を有する。＜ＳｅｒｖｉｃｅＩｄ＞タグはデバイス内におけるサービスを識別するための識別子を有している。
【００６２】
Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージを受信すると、ＣＰＵ２０１は、Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージからデバイス名として＜Ｆｒｉｅｎｄｌｙ  Ｎａｍｅ＞タグの値、モデル名として＜Ｍｏｄｅｌ  Ｎａｍｅ＞タグの値を抽出する。さらに、ＣＰＵ２０１は、＜Ｆｒｉｅｎｄｌｙ  Ｎａｍｅ＞及び＜ＭｏｄｅｌＮａｍｅ＞タグから抽出した値に応じてデバイス情報管理テーブル４００の当該レコードを更新する（ステップＳ６０６）。
【００６３】
さらに、ＣＰＵ２０１は、受信したＧｅｔ  ＲｅｓｐｏｎｓｅメッセージのＸＭＬ自体もＨＤ２１１に記憶して、そのファイルパスをＸＭＬ保存パス４０９とし、デバイス情報管理テーブル４００の当該レコードを更新する。そして、ＣＰＵ２０１は処理を終了する。
【００６４】
一方、ステップＳ６０３において、デバイス情報管理テーブル４００に当該レコードが存在すると（ステップＳ６０３において、ＹＥＳ）、ＣＰＵ２０１は、Ｈｅｌｌｏメッセージからバージョン情報を抽出する（ステップＳ６０７）。続いて、ＣＰＵ２０１は、ＵＵＩＤが一致したレコードにおいてバージョン情報が同一であるか否かについて判定する（ステップＳ６０８）。
【００６５】
バージョン情報が異なっていると（ステップＳ６０８において、ＮＯ）、ＣＰＵ２０１はステップＳ６０５に進む。一方、バージョン情報が同一であると（ステップＳ６０８において、ＹＥＳ）、ＣＰＵ２０１は処理を終了する。
【００６６】
図６は、図１及び図３に示すプリンタ１０１〜１０３の各々においてＧｅｔメッセージ受信からＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージの送信処理に至るまでの手順を説明するためのフローチャートである。ここでは、プリンタ１０１がＧｅｔメッセージを受信したとして説明する。
【００６７】
図３及び図６を参照して、ＣＰＵ３０１は、Ｇｅｔメッセージを受信したか否かについて判定する（ステップＳ９０１）。Ｇｅｔメッセージを受信すると（ステップＳ９０１において、ＹＥＳ）、ＣＰＵ３０１は、前述のＧｅｔ  ＲｅｓｐｏｎｓｅメッセージをＤＰ１２１に送信して（ステップＳ９０２）、ステップＳ９０１に戻る。一方、Ｇｅｔメッセージを受信しないと（ステップＳ９０１において、ＮＯ）、ＣＰＵ３０１は待機する。
【００６８】
図７は、図１及び図２に示すクライアントＰＣ１１１〜１１３の各々においてプリンタ１０１〜１０３の検索処理の手順を説明するためのフローチャートである。
【００６９】
図２及び図７を参照して、ここではクライアントＰＣ１１１における検索処理について説明する。なお、他のクライアントＰＣ１１２及び１１３も同様にして検索処理を行う。
【００７０】
クライアントＰＣ１１１がプリンタ１０１〜１０３の検索処理を行う際には、ＣＰＵ２０１は、後述するプローブ（Ｐｒｏｂｅ）メッセージ（第１のＰｒｏｂｅメッセージ）をマルチキャストで送信して、ＤＰ１２１を検索する（ステップＳ１００１）。
【００７１】
第１のＰｒｏｂｅメッセージは、例えば、そのｂｏｄｙ部に＜Ｐｒｏｂｅ＞タグが存在し、これによって、このメッセージがＰｒｏｂｅメッセージであることが示される。＜Ｐｒｏｂｅ＞タグ中には＜Ｔｙｐｅｓ＞タグが存在する。そして、＜Ｔｙｐｅｓ＞タグには”Ｄｅｖｅｉｃｅ  Ｐｒｏｘｙ”が指定される。
【００７２】
図８は、図１及び図２に示すＤＰ１２１においてクライアントＰＣ１１１〜１１３からＤＰ検索要求を受信して検索応答をクライアントＰＣ１１１〜１１３に送信するまでの処理を説明するためのフローチャートである。
【００７３】
図２及び図８を参照すると、ＤＰ１２１において、ＣＰＵ２０１は、第１のＰｒｏｂｅメッセージを受信したか否かを監視している（ステップＳ１２０１）。第１のＰｒｏｂｅメッセージを受信しないと（ステップＳ１２０１において、ＮＯ）、ＣＰＵ２０１は待機する。
【００７４】
一方、第１のＰｒｏｂｅメッセージを受信すると（ステップＳ１２０１において、ＹＥＳ）、ＣＰＵ２０１は、当該Ｐｒｏｂｅメッセージ中の＜Ｔｙｐｅｓ＞タグを抽出して、”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ”に該当するか否かについて調べる（ステップＳ１２０２）。
【００７５】
”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ”に該当する場合には（ステップＳ１２０２において、ＹＥＳ）、ＣＰＵ２０１は、後述するプローブ一致（Ｐｒｏｂｅ  Ｍａｔｃｈ）メッセージ（第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージ）をクライアントＰＣ１１１に送信する（ステップＳ１２０３）。そして、ＣＰＵ２０１はＳ１２０１に戻る。一方、”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ”に該当しない場合には（ステップＳ１２０２において、ＮＯ）、ＣＰＵ２０１はステップＳ１２０１に戻る。
【００７６】
前述の第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージは、例えば、ｂｏｄｙ部に＜Ｐｒｏｂｅ  Ｍａｔｃｈｅｓ＞タグが存在する。そして、このタグによって、当該メッセージがＰｒｏｂｅ  Ｍａｔｃｈメッセージであることが示される。
【００７７】
＜Ｐｒｏｂｅ  Ｍａｔｃｈｅｓ＞タグ中には＜Ｐｒｏｂｅ  Ｍａｔｃｈ＞タグで示されるＰｒｏｂｅ  Ｍａｔｃｈ部が存在する。Ｐｒｏｂｅ  Ｍａｔｃｈ部が１つの検索結果に対応しており、ここでは、ＤＰ１２１による検索結果が返送されることが示される。
【００７８】
再び図２及び図７を参照して、前述のようにして、Ｐｒｏｂｅメッセージを送信した後、クライアントＰＣ１１１において、ＣＰＵ２０１は、ＤＰ１２１から第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信したか否かを監視する（ステップＳ１００２）。
【００７９】
第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信すると（ステップＳ１００２において、ＹＥＳ）、ＣＰＵ２０１は、第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージ中の＜ＸＡｄｄｒｓ＞タグから抽出したＵＲＬに対して（つまり、ＤＯ２１２に対して）、別のＰｒｏｂｅメッセージ（第２のＰｒｏｂｅメッセージ）を送信する（ステップＳ１００３）。
【００８０】
第２のＰｒｏｂｅメッセージは、例えば、＜Ｔｙｐｅｓ＞タグ中にＰｒｉｎｔｅｒが指定され、これによって、プリンタデバイスの検索が示される。
【００８１】
図９は、図１及び図２に示すＤＰ１２１においてクライアントＰＣ１１１〜１１３からデバイス検索要求を受信した場合の処理を説明するためのフローチャートである。
【００８２】
図２及び図９を参照して、ＤＰ１２１において、ＣＰＵ２０１は、第２のＰｒｏｂｅメッセージを受信したか否かを監視している（ステップＳ１５０１）、第２のＰｒｏｂｅメッセージを受信しないと（ステップＳ１５０１において、ＮＯ）、ＣＰＵ２０１は待機する。
【００８３】
一方、第２のＰｒｏｂｅメッセージを受信すると（ステップＳ１５０１において、ＹＥＳ）、ＣＰＵ２０１は、第２のＰｒｏｂｅメッセージ中から＜Ｔｙｐｅｓ＞タグを抽出して、ＨＤ２１１に記憶されたデバイス情報管理テーブル４００から検索条件に合致するデバイスを探す（ステップＳ１５０２）。そして、ＣＰＵ２０１は、当該検索条件に合致したデバイスがデバイス情報管理テーブル４００に存在するか否かを調べる（ステップＳ１５０３）。
【００８４】
検索条件に合致するデバイスが存在すると（ステップＳ１５０３において、ＹＥＳ）、ＣＰＵ２０１は、別のＰｒｏｂｅ  Ｍａｔｃｈメッセージ（第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージ）をクライアントＰＣ１１１に送信する（ステップＳ１５０４）。そして、ＣＰＵ２０１はステップＳ１５０１に戻る。
【００８５】
なお、検索条件に合致するデバイスが存在しないと（ステップＳ１５０３において、ＮＯ）、ＣＰＵ２０１はステップＳ１５０１に戻る。
【００８６】
上記の第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージは、例えば、＜Ｐｒｏｂｅ  Ｍａｔｃｈｅｓ＞タグ中に＜Ｐｒｏｂｅ  Ｍａｔｃｈ＞タグで示されるＰｒｏｂｅ  Ｍａｔｃｈ部が２つ存在する。各Ｐｒｏｂｅ  Ｍａｔｃｈ部が１つの検索結果に対応しており、ここでは、２つの検索結果が返送されることが示されている。また、第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージでは、＜Ｐｒｏｂｅ  Ｍａｔｃｈｅｓ＞タグ中の＜ＸＡｄｄｒｓ＞タグが示すＵＲＬは、ＤＰ１２１のＩＰアドレスからなる。
【００８７】
再び図２及び図７を参照して、クライアントＰＣ１１１において、第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信しないと（ステップＳ１００２において、ＮＯ）、ネットワーク上にＤＰ１２１が存在しないことを示すため、ＣＰＵ２０１は、＜Ｔｙｐｅｓ＞タグにＰｒｉｎｔｅｒを指定し、Ｐｒｏｂメッセージ（第３のＰｒｏｂｅメッセージ）をマルチキャストで送信する（ステップＳ１００４）。
【００８８】
クライアントＰＣ１１１において、ＣＰＵ２０１は、第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信したか否かを監視している（ステップＳ１００５）。第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信すると（ステップＳ１００５において、ＹＥＳ）、ＣＰＵ２０１は、第２のＰｒｏｂｅＭａｔｃｈメッセージからデバイスをグローバルに識別するＵＵＩＤとして＜Ｅｎｄｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ＞タグ中の＜Ａｄｄｒｅｓｓ＞タグの値を抽出する（ステップＳ１００６）。
【００８９】
続いて、ＣＰＵ２０１は、抽出したＵＵＩＤと同一のＵＵＩＤを有するレコード（以下ＵＵＩＤ一致レコードと呼ぶ）がデバイス情報管理テーブル４００に存在するか否かについて調べる（ステップＳ１００７）。ＵＵＩＤ一致レコードが存在しないと（ステップＳ１００７において、ＮＯ）、ＣＰＵ２０１は、ＨＤ２１１に記憶されたデバイス情報管理テーブル４００に新たにレコードを追加する（ステップＳ１００８）。
【００９０】
次に、ＣＰＵ２０１は、第２のＰｒｏｂｅＭａｔｃｈメッセージから＜ＸＡｄｄｒｓ＞タグで記載されたＵＲＬを抽出して、そのＵＲＬに対して前述のＧｅｔメッセージを送信する（ステップＳ１００９）。そして、ＣＰＵ２０１は当該Ｇｅｔメッセージに対するＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージを受信することになる。
【００９１】
ここでは、ＣＰＵ２０１が送信するＧｅｔメッセージの＜Ｔｏ＞タグには、ステップＳ１００５において受信した第２のＰｒｏｂ  Ｍａｔｃｈメッセージの＜ＥｎｄｐｏｉｎｔＲｅｆｅｒｅｎｃｅ＞タグが示す情報を挿入する。
【００９２】
続いて、クライアントＰＣ１１１において、ＣＰＵ２０１は、受信したＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージの情報を参照して、ＨＤ２１１に記憶されたデバイス情報管理テーブル４００の当該レコードを更新する（ステップＳ１０１０）。
【００９３】
さらに、ステップＳ１０１０において、ＣＰＵ２０１は、受信したＧｅｔ  ＲｅｓｏｐｏｎｓｅメッセージのＸＭＬをＨＤ２１１に記憶する。加えて、ＣＰＵ２０１は、上記のＸＭＬのファイルパスをＸＭＬ保存パスとしてデバイス情報管理テーブル４００に記憶する。
【００９４】
ところで、ステップＳ１００９において、Ｇｅｔメッセージの送信先がＤＰ１２１である場合、ステップＳ１００９において受信するＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージには、例えば、＜Ｔｙｐｅｓ＞が”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ  Ｅｖｅｎｔｉｎｇ  Ｓｅｒｖｉｃｅ  Ｔｙｐｅ”である＜Ｈｏｓｔｅｄ＞タグが存在する。
【００９５】
一方、ステップＳ１００９において、Ｇｅｔメッセージの送信先がプリンタ１０１〜１０３である場合、ステップＳ１００９で受信するＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージには、例えば、＜Ｔｙｐｅｓ＞が”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ  Ｅｖｅｎｔｉｎｇ  Ｓｅｒｖｉｃｅ  Ｔｙｐｅ”である＜Ｈｏｓｔｅｄ＞タグが存在しない。
【００９６】
この場合、ＣＰＵ２０１は、Ｐｒｉｎｔｅｒ  Ｓｅｒｖｉｃｅ  Ｔｙｐｅが示すＵＲＬにイベント登録リクエスト（Ｓｕｂｓｃｒｉｂｅリクエスト）を送信して、直接プリンタ１０１〜１０３にイベント登録することになる。
【００９７】
なお、ステップＳ１００９において抽出されたＵＲＬが示すアドレスは、ステップＳ１００２の分岐に応じてプリンタ１０１〜１０３のアドレスとなるか又はＤＰ１２１のアドレスとなる。
【００９８】
例えば、ステップＳ１００２において、第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信すると（ステップＳ１００２において、ＹＥＳ）、ステップＳ１００３において、ＣＰＵ２０１はＤＰ１２１に対してデバイス検索要求する。そして、ステップＳ１００４において、ＣＰＵ２０１はＤＰ１２１から第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信する。従って、第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージでは、＜ＸＡｄｄｒｓ＞タグはＤＰ１２１のＩＰアドレスからなる。
【００９９】
一方、ステップＳ１００２において、第１のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信しないと（ステップＳ１００２において、ＮＯ）、ステップＳ１００４において、ＣＰＵ２０１はマルチキャストでデバイス検索要求することになる。従って、ステップＳ１００４において、ＣＰＵ２０１はプリンタ１０１〜１０３からＰｒｏｂｅ  Ｍａｔｃｈメッセージを第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージとして受信することになる。よって、この場合には、第２のＰｒｏｂｅＭａｔｃｈメッセージ上の＜ＸＡｄｄｒｓ＞タグはプリンタ１０１〜１０３のＩＰアドレスからなる。
【０１００】
ステップＳ１００７において、ＵＵＩＤ一致レコードが存在する場合には（ステップＳ１００７において、ＹＥＳ）、ＣＰＵ２０１は、第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージからバージョン情報を抽出する（ステップＳ１０１１）。そして、ＣＰＵ２０１は、当該バージョン情報が同一であるか否かについて判定する（ステップＳ１０１２）。バージョン情報が異なる場合には（ステップＳ１０１２において、ＮＯ）、ＣＰＵ２０１は、前述のステップＳ１００９に進む。
【０１０１】
一方、バージョン情報が一致する場合には（ステップＳ１０１２において、ＹＥＳ）、ＣＰＵ２０１は、後述するステップＳ１０１３に進む。
【０１０２】
図１０は、図７に示す処理においてクライアントＰＣ１１１からＧｅｔメッセージを受信した際のＤＰ１２１における処理を説明するためのフローチャートである。
【０１０３】
図２及び図１０を参照して、ＤＰ１２１において、ＣＰＵ２０１は、Ｇｅｔメッセージを受信したか否かについて監視している（ステップＳ１７０１）。Ｇｅｔメッセージを受信しないと（ステップＳ１７０１において、ＮＯ）、ＣＰＵ２０１は待機する。一方、Ｇｅｔメッセージを受信すると（ステップＳ１７０１において、ＹＥＳ）、ＣＰＵ２０１は、Ｇｅｔメッセージの中からデバイスをグローバルに識別するＵＵＩＤとして＜Ｔｏ＞タグの値を抽出する（ステップＳ１７０２）。
【０１０４】
続いて、ＣＰＵ２０１は、抽出したＵＵＩＤと同一のＵＵＩＤを有するレコードがデバイス情報管理テーブル４００に存在するかについて検索する（デバイス情報検索：ステップＳ１７０３）。そして、ＣＰＵ２０１は、抽出されたＵＵＩＤと同一のＵＵＩＤを有するレコードが存在するか否かについて判定する（ステップＳ１７０４）。
【０１０５】
抽出されたＵＵＩＤと同一のＵＵＩＤを有するレコードが存在すると（ステップＳ１７０４において、ＹＥＳ）、ＣＰＵ２０１は、後述するＧｅｔ  ＲｅｓｐｏｎｓｅメッセージをクライアントＰＣ１１１に送信して（ステップＳ１７０５）、ステップＳ１７０１に戻る。
【０１０６】
なお、抽出されたＵＵＩＤと同一のＵＵＩＤを有するレコードが存在しなければ（ステップＳ１７０４において、ＮＯ）、ＣＰＵ２０１はステップＳ１７０１に戻る。
【０１０７】
上述のステップＳ１７０５において送信されるＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージは、例えば、ＤＰ１２１のＨＤ２１１に記憶されたデバイス情報管理テーブル４００の情報に基づいて作成される。このＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージは、＜Ｍｅｔａｄａｔａ＞タグ中にＨｏｓｔｅｄ部が２つ存在する。
【０１０８】
一つ目のＨｏｓｔｅｄ部は、前述のステップＳ１７０３においてデバイス情報管理テーブル４００から検索されたデバイスの情報を示す。二つ目のＨｏｓｔｅｄ部は、ＤＰ１２１自体の情報を示す。二つ目のＨｏｓｔｅｄ部は、＜Ｔｙｐｅｓ＞として”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ  Ｅｖｅｎｔｉｎｇ  Ｓｅｒｖｉｃｅ  Ｔｙｐｅ”が指定され、＜Ａｄｄｒｅｓｓ＞タグにはＤＰ１２１のＩＰアドレスからなるＵＲＬが指定される。
【０１０９】
後述するように、クライアントＰＣ１１１は、上記のＵＲＬにイベント登録リクエスト（Ｓｕｂｓｃｒｉｂｅリクエスト）を送信して、ＤＰ１２１経由によってデバイスにイベント登録リクエストを発行することができる。
【０１１０】
続いて、図７を再び参照して、クライアントＰＣ１１１において、ＣＰＵ２０１は、前述のステップＳ１００５において受信した第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージに含まれている全Ｐｒｏｂｅ  Ｍａｔｃｈ分の処理が完了したか否かについて判定する（ステップＳ１０１３）。未だ全ＰｒｏｂｅＭａｔｃｈ分の処理が完了していない場合には（ステップＳ１０１３において、ＮＯ）、ＣＰＵ２０１はステップＳ１００６に戻って処理を続行する。
【０１１１】
一方、全ＰｒｏｂｅＭａｔｃｈ分の処理が完了している場合には（ステップＳ１０１３において、ＹＥＳ）、ＣＰＵ２０１は処理を終了する。なお、ステップＳ１００５において、第２のＰｒｏｂｅ  Ｍａｔｃｈメッセージを受信しないと（ステップＳ１００５において、ＮＯ）、ＣＰＵ２０１は待機する。
【０１１２】
図１１は、図１及び図３に示すクライアントＰＣ１１１〜１１３において、検索したデバイスの情報を表示する際に用いられるユーザインターフェース（ＵＩ）の一例を示す図である。
【０１１３】
図１１において、ＵＩには領域１９０１が表示され、この領域１９０１において検索するデバイスのタイプが指定される。例えば、「ＭＦＰ」及び「Ｐｒｉｎｔｅｒ」等のキーワードが領域１９０１で指定可能である。領域１９０１が無入力であると、ＣＰＵ２０１は全てのデバイスを検索する。そして、ボタン１９０２の押下によって、上述したデバイスの検索が実行され、検索の結果は領域１９０３に表示される。
【０１１４】
図１２は、図１及び図３に示すクライアントＰＣ１１１〜１１３においてデバイス検索によって検索されたデバイスに対してイベント登録処理を行う手順を説明するためのフローチャートである。ここでも、クライアントＰＣ１１１がイベント登録を行う場合について説明する。
【０１１５】
図３及び図１２を参照して、クライアントＰＣ１１１において、ＣＰＵ２０１は、ＨＤ２１１に記憶されたＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージの情報から、イベント登録リクエスト送信先のＵＲＬを抽出する（ステップＳ２００１）。図７のステップＳ１００９において、ＤＰ１２１からデバイス情報を取得している場合には、イベント登録リクエスト送信先のＵＲＬはＤＰ１２１のＩＰアドレスからなる。
【０１１６】
一方、図７のステップＳ１００９において、プリンタ１０１〜１０３からデバイス情報を取得している場合には、イベント登録リクエスト送信先のＵＲＬはプリンタ１０１〜１０３のＩＰアドレスからなる。
【０１１７】
続いて、ＣＰＵ２０１は、イベント登録リクエスト先のＵＲＬに対して、Ｓｕｂｓｃｒｉｂｅリクエストを送信する（ステップＳ２００２）。ＤＰ１２１に送信する際のＳｕｂｓｃｒｉｂｅリクエストにおいては、ｗｓａ：Ｆｉｌｔｅｒ部は、「”Ｐｒｉｎｔｅｒ  Ｓｔａｔｕｓ  Ｅｖｅｎｔ”が示すイベントについて、そのＳｔａｔｕｓが変化したら（つまり、イベントが発生したら）通知をしてほしい」旨を示す（通知要求）。
【０１１８】
また、ｗｓａ：Ｔｏ部は、イベント通知のサービスを提供する装置のＵＲＬを示す。このＵＲＬは、図７のステップＳ１００９において取得したＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージ中において、＜Ｔｙｐｅｓ＞がＰｒｉｎｔｅｒ  Ｓｅｒｖｉｃｅ  Ｔｙｐｅである＜Ｈｏｓｔｅｄ＞タグ内の＜Ａｄｄｒｅｓｓ＞タグが示すＵＲＬに該当する。
【０１１９】
ｗｓａ：Ｒｅｐｌｙ  Ｔｏ部は、メッセージの応答を受信すべきエンドポイントのＵＲＬを示す。ここでは、クライアントＰＣ１１１のＵＲＬが該当する。
【０１２０】
図１３は、図１及び図２に示すＤＰ１２１がクライアントＰＣ１１１〜１１３からＳｕｂｓｃｒｉｂｅリクエストを受信してからプリンタ１０１〜１０３にＳｕｂｓｃｒｉｂｅリクエストを送信するまでの処理を説明するためのフローチャートである。ここでは、ＤＰ２１２がクライアントＰＣ１１１からＳｕｂｓｃｒｉｂｅリクエストを受信した場合について説明する。
【０１２１】
図２及び図１３を参照して、ＤＰ２１２において、ＣＰＵ２０１はＳｕｂｓｃｒｉｂｅリクエストを受信したか否かを監視している（ステップＳ２２０１）。Ｓｕｂｓｃｒｉｂｅリクエストを受信しないと（ステップＳ２２０１において、ＮＯ）、ＣＰＵ２０１は待機する。
【０１２２】
一方、Ｓｕｂｓｃｒｉｂｅリクエストを受信すると（ステップＳ２２０１において、ＹＥＳ）、ＣＰＵ２０１は、受信したＳｕｂｓｃｒｉｂｅリクエストの情報を代行イベント情報としてＨＤ２１１に記憶された後述の代行イベント情報保持部（デバイス管理テーブルの１つ）２３００に追加記録する（ステップＳ２２０２）。
【０１２３】
図１４は、図２にＤＰ１２１のＨＤ２１１に記憶された代行イベント情報の一例を示す図である。
【０１２４】
図１４において、デバイス情報管理テーブル２３００には、各代行イベント情報がレコードとして記憶する。レコードはＩＤ２３０１、イベント登録先ＵＲＬ２３０２、イベント通知先ＵＲＬ２３０３、イベント種別２３０４、及びエラー解除イベント未送信リスト２３０５を有している。
【０１２５】
ＩＤ２３０１はＤＰ１２１において代行イベント情報を識別するためのものである。イベント登録先ＵＲＬ２３０２は、イベント登録先のサービスＵＲＬを示し、前述のｗｓａ：Ｔｏタグに示す情報が該当する。イベント通知先ＵＲＬ２３０３は、Ｓｕｂｓｃｒｉｂｅリクエスト送信元のクライアントＰＣのＵＲＬを表し、前述のｗｓａ：Ｒｅｐｌｙ  Ｔｏタグに示す情報が該当する。イベント種別２３０４は、通知して欲しいイベントの種別を示し、前述のｗｓａ：Ｆｉｌｔｅｒに示す情報が該当する。
【０１２６】
後述するように、ＤＰ１２１は、イベント登録先ＵＲＬ２３０２に示すデバイスから、イベント種別２３０４に示すイベント種別のイベントを受信した場合には、イベント通知先ＵＲＬ２３０３に示すクライアントＰＣにイベントメッセージを送信することになる。
【０１２７】
エラー解除イベント未送信リスト２３０５は、エラーイベントをイベント通知先ＵＲＬに送信したが、エラー解除イベントをイベント通知先ＵＲＬに送信していないものを示す。このリスト中の情報は、イベント通知先ＵＲＬに送信したエラーイベントのＭｅｓｓａｇｅ  ＩＤとエラー内容とを表す。
【０１２８】
ＤＰ１２１は、イベント登録先ＵＲＬ２３０２に示すデバイスに対して、定期的にエラーが解除されたか否かを確認する。そして、エラーが解除されたことを確認した場合は、ＤＰ１２１はエラー解除イベントをイベント通知先ＵＲＬに送信する。エラー解除イベントをイベント通知先ＵＲＬに送信した場合には、ＤＰ１２１において、ＣＰＵ２０１は該当するＭｅｓｓｅｇｅ  ＩＤをエラー解除イベント未送信リストから削除する。
【０１２９】
再び図２及び図１３を参照して、ＤＰ１２１において、ＣＰＵ２０１は、デバイス情報管理テーブル２３００に追加したレコードのイベント登録先ＵＲＬ２３０３が新規である否かを判定する（ステップＳ２２０３）。イベント登録先ＵＲＬ２３０３が新規でないと（ステップＳ２２０３において、ＮＯ）、ＣＰＵ２０１はイベント種別２３０４が新規であるか否かについて調べる（ステップＳ２２０４）。そして、イベント種別２３０４が新規でなければ（ステップＳ２２０４において、ＮＯ）、ＣＰＵ２０１は処理を終了する。
【０１３０】
つまり、イベント種別２３０４が新規でなければ、既に同一のイベント種別が存在していることになる。この場合には、既にイベント登録先ＵＲＬに対して同一のイベント種別においてＳｕｂｓｃｒｉｂｅリクエスト送信済であるため、ＣＰＵ２０１は処理を終了することになる。何もしないで終了する。
【０１３１】
一方、イベント登録先ＵＲＬ２３０３が新規であると（ステップＳ２２０３において、ＹＥＳ）、ＣＰＵ２０１は、ＸＭＬ形式のＳｕｂｓｃｒｉｂｅリクエストをイベント登録先ＵＲＬ２３０３が示すＵＲＬに送信する（ステップＳ２００５）。なお、ステップＳ２２０４において、イベント種別２３０４が新規であれば（ステップＳ２２０４において、ＹＥＳ）、ＣＰＵ２０１は同様にステップＳ２２０５に進む。
【０１３２】
前述のステップＳ２００５でＣＰＵ２０１が送信するＳｕｂｓｃｒｉｂｅリクエストにおいて、ｗｓａ：Ｆｉｌｔｅｒ部は、”ＰｒｉｎｔｅｒＳｔａｔｕｓＥｖｅｎｔ”が示すイベントについてＳｔａｔｕｓが変化したら（イベントが発生したら）通知をしてほしい」旨を示す。また、ｗｓａ：Ｔｏ部は、イベント通知のサービスを提供する装置のＵＲＬを示す。そして、当該ＵＲＬはイベント登録先ＵＲＬ２３０２のＵＲＬに該当する。
【０１３３】
さらに、ｗｓａ：Ｒｅｐｌｙ  Ｔｏ部は、メッセージの応答を受信すべきエンドポイントのＵＲＬを示す。ここでは、ＤＰ１２１のＵＲＬが該当する。プリンタ１０１〜１０３の各々において、ＣＰＵ３０１は、Ｓｕｂｓｃｒｉｂｅリクエストを受信すると、ＲＡＭ３０２に通知すべきイベント種別とイベント通知先情報とを関連付けて記憶する。
【０１３４】
図１５は、図３に示すプリンタ１０１〜１０３のＲＡＭ３０２に記憶されるイベント登録情報の一例を示す図である。
【０１３５】
図１５において、イベント登録情報テーブル２５００には、各登録（Ｓｕｂｓｃｒｉｂｅ）元からの登録情報がレコードとして記憶される。ＩＤ２５０１は、プリンタ１０１〜１０３の各々において、イベント登録情報を識別するためのものである。イベント通知先ＵＲＬ２５０２は、イベントが発生した際の通知先のＵＲＬを表す。
【０１３６】
このイベント通知先ＵＲＬ２５０２は、ＤＰ１２１から登録（Ｓｕｂｓｃｒｉｂｅ）された場合には、ＤＰ１２１のＵＲＬを表す。一方、他のクライアントＰＣから登録されたされた場合には、これらクライアントＰＣの各々のＵＲＬを表す。イベント種別２５０３は、通知して欲しいイベントの種別を表し、例えば、前述のｗｓａ：Ｆｉｌｔｅｒに示す情報が該当する。
【０１３７】
前述のように、ＲＡＭ３０２は揮発性のメモリであるので、電源をＯＦＦすると、ＲＡＭ３０２に記憶されたイベント登録情報テーブル２５００に係る情報は全て消えてしまう。
【０１３８】
図１６は、図１及び図３に示すプリンタ１０１〜１０３においてイベントが発生した際の処理の手順を説明するためのフローチャートである。なお、ここでは、プリンタ１０１を例に挙げて説明する。
【０１３９】
図３及び図１６を参照して、プリンタ１０１において、例えば、ジョブに対する遷移状態変化に関するイベント、エラーイベント、オプション装置等の変更に関するイベント、及び諸設定変更に関連するイベントが発生すると、図１６に示す処理が開始される。
【０１４０】
プリンタ１０１において、ＣＰＵ３０１はイベントが発生したか否かを監視している（ステップＳ２６０１）。イベントが発生しないと（ステップＳ２６０１において、ＮＯ）、ＣＰＵ３０１は待機する。一方、イベントが発生すると（ステップＳ２６０１において、ＹＥＳ）、ＣＰＵ３０１は、ＲＡＭ３０２に記憶されているイベント登録情報テーブル２５００を検索する（ステップＳ２６０２）。
【０１４１】
続いて、ＣＰＵ３０１は、発生したイベントが通知すべきイベント種別として登録イベント）、イベント登録情報テーブル２５００に記憶されているか否かを調べる（ステップＳ２６０３）。発生したイベントが通知すべきイベント種別であると（ステップＳ２６０３において、ＹＥＳ）、ＣＰＵ３０１は当該イベントがエラー関連イベント（つまり、エラーイベント）であるか否かについて調べる（ステップＳ２６０４：エラー判定手段）。
【０１４２】
発生したイベントがエラーイベントであると（ステップＳ２６０４において、ＹＥＳ）、ＣＰＵ３０１は、イベント通知先ＵＲＬに対して、Ｇｅｔメッセージを送信する（ステップＳ２６０５）。そして、ＣＰＵ３０１は、後述するＧｅｔ  Ｒｅｓｐｏｎｓｅメッセージの受信を待つ。
【０１４３】
ＣＰＵ３０１は、イベント通知先ＵＲＬから、Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージを受信する（ステップＳ２６０６）。そして、ＣＰＵ３０１は、受信したＧｅｔ  Ｒｅｓｐｏｎｓｅの送信元がＤＰ（Ｄｅｖｉｃｅ  Ｐｒｏｘｙ）１２１であるか否かについて判定する（ステップＳ２６０７：通知先判定手段）。
【０１４４】
例えば、Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージにおいて、＜Ｔｙｐｅｓ＞が”Ｄｅｖｉｃｅ  Ｐｒｏｘｙ  Ｅｖｅｎｔｉｎｇ  Ｓｅｒｖｉｃｅ  Ｔｙｐｅ”である＜Ｈｏｓｔｅｄ＞タグが存在する場合、Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージの送信元はＤＰ１２１であることを示している。
【０１４５】
Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージの送信元（つまり、イベント通知先）がＤＰ１２１である場合（ステップＳ２６０７において、ＹＥＳ）、ＣＰＵ３０１は、イベント通知先ＵＲＬに対してイベントメッセージ（Ｓｔａｔｕｓ  Ｅｖｅｎｔ  Ｒｅｐｏｒｔ）を送信する（ステップＳ２６０８：第１のイベント通知手段及び第２のイベント通知手段）。
【０１４６】
ここでは、サービスコールエラーが発生した場合について、Ｓｔａｔｕｓ  Ｅｖｅｎｔ  Ｒｅｐｏｒｔメッセージが送信される。つまり、ここでは、ＣＰＵ３０１は、サービスコールエラーが発生したことを検出した場合に、当該エラーイベントを通知するために、Ｓｔａｔｕｓ  Ｅｖｅｎｔ  Ｒｅｐｏｒｔメッセージを送信する。
【０１４７】
その後、ＣＰＵ３０１はイベント登録テーブル２５００の全てについて検索・処理が終了したか否かについては判定する（ステップＳ２６０９）。そして、イベント登録テーブル２５００の全てについて検索・処理が終了していないと（ステップＳ２６０９において、ＮＯ）、ＣＰＵ３０１はステップＳ２６０２に戻って処理を続行する。
【０１４８】
一方、イベント登録テーブル２５００の全てについて検索・処理が終了すると（ステップＳ２６０９において、ＹＥＳ）、ＣＰＵ３０１は処理を終了する。
【０１４９】
なお、ステップＳ２６０７において、Ｇｅｔ  Ｒｅｓｐｏｎｓｅメッセージの送信元がＤＰ１２１でないと（ステップＳ２６０７において、ＮＯ）、ＣＰＵ３０１は処理をステップＳ２６０９に移行する。
【０１５０】
また、ステップＳ２６０４において、発生したイベントがエラーイベントではないと（ステップＳ２６０４において、ＮＯ）、ＣＰＵ３０１は処理をステップＳ２６０８に移行して、イベント通知先ＵＲＬに対してイベントメッセージを送信することになる。
【０１５１】
さらに、ステップＳ２６０３において、発生したイベントが通知すべきイベント種別でないと（ステップＳ２６０３において、ＮＯ）、ＣＰＵ３０１は処理をステップＳ２６０９に移行する。
【０１５２】
図１７は、図１及び図２に示すＤＰ１２１においてプリンタ１０１〜１０３からイベントメッセージを受信してクライアントＰＣ１１１〜１１３に当該イベントを転送するまでの処理を説明するためのフローチャートである。なお、ここでは、プリンタ１０１からイベントメッセージを受信するものとして説明する。
【０１５３】
図２及び図１７を参照して、ＤＰ１２１において、ＣＰＵ２０１は、イベントメッセージの受信を監視している（ステップＳ３００１）。イベントメッセージを受信しないと（ステップＳ３００１において、ＮＯ）、ＣＰＵ２０１は待機する。
【０１５４】
一方、イベントメッセージを受信すると（ステップＳ３００１において、ＹＥＳ）、ＣＰＵ２０１は、受信したイベントメッセージについてそのイベント送信元が、ＨＤ２１１に記憶されたデバイス情報管理テーブル２３００にイベント登録先ＵＲＬとして登録されているか否かについて調べる（ステップＳ３００２）。
【０１５５】
イベント送信元がイベント登録先ＵＲＬとして登録されている場合には（ステップＳ３００２において、ＹＥＳ）、ＣＰＵ２０１は、登録されているイベント通知先ＵＲＬと同一のレコード上のイベント通知先ＵＲＬ２３０３が示すＵＲＬに対してイベントメッセージを送信する（ステップＳ３００３：メッセージ通知手段）。
【０１５６】
続いて、ＣＰＵ３０１は、送信したイベントメッセージがエラーイベントメッセージであるか否かを調べる（ステップＳ３００４）。送信したイベントメッセージがエラーイベントメッセージであると（ステップＳ３００４において、ＹＥＳ）、ＣＰＵ２０１は、エラー解除イベント未送信リスト２３０５に、送信したエラーイベントメッセージ（エラーメッセージともいう）のＭｅｓｓａｇｅ  ＩＤ（エラー解除未送信情報）を追加登録する（ステップＳ３００５：保持手段）。
【０１５７】
次に、ＣＰＵ２０１は、全てのイベント通知先ＵＲＬにイベントメッセージの送信が完了したか否かを判定する（ステップＳ３００６）。つまり、ＣＰＵ２０１は、イベント登録先ＵＲＬに対して複数のイベント通知先ＵＲＬが登録されている場合には、その全てに対してイベント送信処理が完了したか否かを判定することになる。
【０１５８】
全てのイベント通知先ＵＲＬに対してイベントメッセージの送信が完了していない場合には（ステップＳ３００６において、ＮＯ）、ＣＰＵ２０１は、ステップＳ３００３に戻って処理を続行する。一方、全てのイベント通知先ＵＲＬに対してイベントメッセージの送信が完了していると（ステップＳ３００６において、ＹＥＳ）、ＣＰＵ２０１は処理を終了する。
【０１５９】
なお、ステップＳ３００２において、イベント送信元がイベント登録先ＵＲＬとして登録されていない場合には（ステップＳ３００２において、ＮＯ）、ＣＰＵ２０１は処理を終了する。
【０１６０】
図１８は、図１及び図２に示すＤＰ１２１においてプリンタ１０１〜１０３のエラー解除状態を確認して、エラー解除イベントメッセージをクライアントＰＣ１１１〜１１３に送信するまでの処理を説明するためのフローチャートである。
【０１６１】
図２及び図１８を参照して、ＤＰ１２１において、ＣＰＵ２０１は、まず、エラー解除イベント未送信リスト２３０５を先頭から検索する（ステップＳ３１０１）。そして、ＣＰＵ２０１は、エラー解除イベント未送信リスト２３０５にエラー解除イベント未送信のデータがあるか否かについて判定する（ステップＳ３１０２）。
【０１６２】
エラー解除イベント未送信リスト２３０５にエラー解除イベント未送信のデータが存在すると（ステップＳ３１０２において、ＹＥＳ）、ＣＰＵ２０１は、イベント登録先ＵＲＬが示すプリンタの状態を確認する（ステップＳ３１０３）。なお、プリンタの状態を確認する手法については種々の手法が知られている。
【０１６３】
続いて、ＣＰＵ２０１は確認の結果に応じてエラーが既に解除されているか否かについて判断する（ステップＳ３１０４：監視手段）。確認した結果、エラー解除イベント未送信リスト２３０５のデータが示すエラーが解除されていると（ステップＳ３１０４において、ＹＥＳ）、ＣＰＵ２０１は、エラー解除イベントメッセージをイベント通知先ＵＲＬへ送信する（ステップＳ３１０５：通知手段）。
【０１６４】
そして、ＣＰＵ２０１は、送信したエラー解除イベントメッセージに該当するデータを、エラー解除イベント未送信リスト２３０５から削除する（ステップＳ３１０６：保持手段）。次に、ＣＰＵ２０１は、エラー解除イベント未送信リスト２３０５から次のデータを検索して（ステップＳ３１０７）、ステップＳ３１０２に戻って処理を続行する。
【０１６５】
なお、ステップＳ３１０２において、エラー解除イベント未送信リスト２３０５にエラー解除イベント未送信のデータが存在しないと（ステップＳ３１０２において、ＮＯ）、ＣＰＵ２０１は、所定の時間（一定時間）の待った後（ステップＳ３１０８）、ステップＳ３１０１に戻って処理を続ける。
【０１６６】
また、ステップＳ３１０４において、確認した結果、エラー解除イベント未送信リスト２３０５のデータが示すエラーが解除されていないと（ステップＳ３１０４において、ＮＯ）、ＣＰＵ２０１は処理をステップＳ３１０７に進める。
【０１６７】
このように、第１の実施形態においては、プリンタ１０１〜１０３は、エラーイベントが発生した場合、イベント登録元がＤＰ１２１であると、ＤＰ１２１にエラーイベントメッセージを送信する。そして、ＤＰ１２１は、プリンタ１０１〜１０３からエラーイベントメッセージを受信すると、クライアントＰＣ１１１〜１１３にイベントを転送する。
【０１６８】
次に、ＤＰ１２１は、エラーが解除されたか否かをプリンタ１０１〜１０３に対して周期的に確認して（予め定められた周期で確認して）、エラーが解除されたことを知ると、クライアントＰＣ１１１〜１１１３にエラー解除イベントメッセージを送信する。
【０１６９】
これによって、クライアントＰＣ１１１〜１１３はエラーイベントメッセージとエラー解除イベントメッセージを受信することが可能となって、プリンタ１０１〜１０３のエラー状況をリアルタイムに把握することができる。
【０１７０】
つまり、第１の実施形態では、プロキシサーバがプリンタのエラー発生状況を監視・確認して、エラーが解除されると、エラー解除メッセージをクライアントＰＣに送信する。これによって、クライアントＰＣは、プリンタにおけるエラー解除を確実に知ることができる。この結果、プリンタがイベント登録情報を不揮発性の記憶媒体に記憶できない場合であっても、エラー解除メッセージを利用してエラー解除の確認をクライアントＰＣで行うことができることになる。
【０１７１】
（第２の実施形態）
上述の第１の実施形態においては、図１６に関連して説明したように、プリンタ１０１〜１０３でイベントが発生すると、Ｇｅｔメッセージを用いてイベント通知先がＤＰ１２１か否かを確認するようにしている。第２の実施形態においては、図１３に示すステップＳ２２０５において、ＤＰ１２１のＣＰＵ２０１がプリンタ１０１〜１０３に送信するＳｕｂｓｃｒｉｂｅリクエスト中に、ＤＰ１２１からのリクエストであることを示すタグを含める。
【０１７２】
これによって、プリンタ１０１〜１０３のＣＰＵ３０１は、受信したＳｕｂｓｃｒｉｂｅリクエストの内容からリクエスト元がＤＰ１２１であるかクライアントＰＣ１１１〜１１３であるかを抽出する。そして、プリンタ１０１〜１０３において、ＣＰＵ３０１は、後述するイベント登録情報をＲＡＭ３０２に記憶する。
【０１７３】
図１９は、図３に示すＲＡＭ３０２に記憶されるイベント登録情報の一例を示す図である。
【０１７４】
図１９において、イベント登録情報３３００には、ＩＤ、イベント通知先ＵＲＬ、イベント種別の他に、イベント通知先タイプ３３０１が備えられている。そして、このイベント通知先タイプ３３０１によって、リクエスト元がＤＰ１２１であるかクライアントＰＣ１１１〜１１３であるかが示される。
【０１７５】
つまり、ＣＰＵ３０１は、イベント通知先タイプ３３０１によって、イベント通知先ＵＲＬが示す装置がＤＰ１２１であるか又はクライアントＰＣ１１１〜１１３であるかを判断することができることになる。
【０１７６】
図２０は、図１及び図３に示すプリンタ１０１〜１０３においてイベントが発生した場合の処理の手順を説明するためのフローチャートである。
【０１７７】
第１の実施形態ではプリンタ１０１〜１０３の各々においてイベントが発生した際には、図１６で説明したように、ステップＳ２６０５においてＧｅｔメッセージの送信を行い、ステップＳ２６０６においてＧｅｔＲｅｓｐｏｎｓｅメッセージの受信処理を行っている。
【０１７８】
第２の実施形態においては、図１６に示すステップＳ２６０５及び２６０６の代わりに、ＣＰＵ３０１はイベント登録情報３３００を参照してイベント通知先のタイプがＤＰ１２１であるか否かを判定する（ステップＳ３４０５）。
【０１７９】
そして、イベント通知先のタイプがＤＰ１２１であると（ステップＳ３４０５において、ＹＥＳ）、ＣＰＵ３０１は、図１６で説明したステップＳ２６０８に処理を進める。一方、イベント通知先のタイプがＤＰ１２１でないと（ステップＳ３４０５において、ＮＯ）、ＣＰＵ３０１は、図１６で説明したステップＳ２６０９に処理を進める。
【０１８０】
なお、図２０において、図１６と同様のステップについては同一の参照符号が付されている。
【０１８１】
このように、第２の実施形態においては、第１の実施形態に比べて、ＣＰＵ３０１が実行するステップの数が少なくなっているので、イベント発生時におけるイベントメッセージ送信処理に係るパフォーマンスを向上することができる。
【０１８２】
上述の説明から明らかなように、ＤＰ１２１において、ＣＰＵ２０１が監視手段、メッセージ通知手段、及び通知手段として機能する。また、ＤＰ１２１において、ＣＰＵ２０１及びＨＤ２１１がとして機能する。そして、プリンタ１０１〜１０３の各々において、ＣＰＵ３０１が第１及び第２のイベント通知手段、判定するエラー判定手段、及び通知先判定手段として機能する。
【０１８３】
以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
【０１８４】
例えば、上記の実施の形態の機能を通信制御方法として、この通信制御方法を、ＤＰ１２１及びプリンタ１０１〜１０３に実行させるようにすればよい。また、上述の実施の形態の機能を有するプログラムを通信制御プログラムとして、この制御プログラムをＤＰ１２１及びプリンタ１０１〜１０３が備えるコンピュータに実行させるようにしてもよい。
【０１８５】
この際、通信制御方法及び通信制御プログラムは、少なくともエラー判定ステップ、通知先判定ステップ、通知ステップ、監視ステップ、及び通知ステップを有することになる。
【０１８６】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１８７】
１００  ネットワーク
１０１〜１０３  プリンタ
１１１〜１１３  クライアントＰＣ
１２１  プロキシサーバ（Ｄｅｖｉｃｅ  Ｐｒｏｘｙ）
２０１，３０１  ＣＰＵ
２０８  ＮＩＣ
３０５  操作パネル
３０６  ＬＡＮコントローラ
３０７  印刷インターフェース
３０８  プリントエンジン
【図１】
2012037976.tif 000003
【図２】
2012037976.tif 000004
【図３】
2012037976.tif 000005
【図４】
2012037976.tif 000006
【図５】
2012037976.tif 000007
【図６】
2012037976.tif 000008
【図７】
2012037976.tif 000009
【図８】
2012037976.tif 000010
【図９】
2012037976.tif 000011
【図１０】
2012037976.tif 000012
【図１１】
2012037976.tif 000013
【図１２】
2012037976.tif 000014
【図１３】
2012037976.tif 000015
【図１４】
2012037976.tif 000016
【図１５】
2012037976.tif 000017
【図１６】
2012037976.tif 000018
【図１７】
2012037976.tif 000019
【図１８】
2012037976.tif 000020
【図１９】
2012037976.tif 000021
【図２０】
2012037976.tif 000022