JP2012037976A - サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体 - Google Patents

サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体 Download PDF

Info

Publication number
JP2012037976A
JP2012037976A JP2010175573A JP2010175573A JP2012037976A JP 2012037976 A JP2012037976 A JP 2012037976A JP 2010175573 A JP2010175573 A JP 2010175573A JP 2010175573 A JP2010175573 A JP 2010175573A JP 2012037976 A JP2012037976 A JP 2012037976A
Authority
JP
Japan
Prior art keywords
event
error
message
terminal device
server device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2010175573A
Other languages
English (en)
Inventor
Shoji Nishiyama
将司 西山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2010175573A priority Critical patent/JP2012037976A/ja
Priority to US13/198,079 priority patent/US8775878B2/en
Publication of JP2012037976A publication Critical patent/JP2012037976A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0784—Routing of error reports, e.g. with a specific transmission path or data flow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0733—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a data processing system embedded in an image processing device, e.g. printer, facsimile, scanner
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/121—Facilitating exception or error detection and recovery, e.g. fault, media or consumables depleted
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1229—Printer resources management or printer maintenance, e.g. device status, power levels
    • G06F3/1234—Errors handling and recovery, e.g. reprinting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
    • G06F3/1285—Remote printer device, e.g. being remote from client or server
    • G06F3/1288—Remote printer device, e.g. being remote from client or server in client-server-printer device configuration

Abstract

【課題】プリンタにおけるエラー解除イベントの確認をクライアントＰＣで確実に行う。
【解決手段】プロキシサーバ１２１は、プリンタ１０１〜１０３及びクライアントＰＣ１１１〜１１３にネットワーク１００を介して接続されている。プロキシサーバはプリンタで発生したイベントを示すイベントメッセージを受信した際、当該イベントメッセージをクライアント装置に転送する。そして、プロキシサーバはクライアントＰＣに転送したイベントメッセージがプリンタにおけるエラーを示すエラーイベントであると、プリンタにおいてエラーイベントの解除が行われたか否かを監視して、プリンタにおいてエラーイベントの解除が行われると、クライアントＰＣにエラーイベントが解除された旨を示すエラー解除メッセージを通知する。
【選択図】図１

Description

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

Claims (10)

  1. 端末装置とクライアント装置とにネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを受信した際、当該イベントメッセージを前記クライアント装置に転送するサーバ装置であって、
    前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視手段と、
    前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知手段とを有することを特徴とするサーバ装置。
  2. 前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、当該エラーイベントが未送信であることを示すエラー解除未送信情報を、前記エラー解除メッセージが送信されるまで保持する保持手段を有することを特徴とする請求項１記載のサーバ装置。
  3. 前記クライアント装置から前記イベントの通知要求を受信した場合に、当該クライアント装置に前記イベントメッセージの通知を行うメッセージ通知手段を有することを特徴とする請求項１又は２記載のサーバ装置。
  4. 前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
    前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントであると、当該登録イベントについて予め登録されたイベント通知先に通知する第１のイベント通知手段を有することを特徴とする請求項１〜３いずれか１項記載のサーバ装置。
  5. 前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントであると、当該イベントが前記エラーイベントであるか否かを判定するエラー判定手段と、
    前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定手段と、
    前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知する第２のイベント通知手段とを有することを特徴とする請求項４記載のサーバ装置。
  6. 前記監視手段は、予め定められた周期で前記端末装置において前記エラーイベントの解除が行われたか否かを確認することを特徴とする請求項１〜５いずれか１項記載のサーバ装置。
  7. 端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する通信システムであって、
    前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
    前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定手段と、
    前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定手段と、
    前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知手段とを備え、
    前記サーバ装置は、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視手段と、
    前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知手段とを備えることを特徴とする通信システム。
  8. 端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する際に用いられる通信制御方法であって、
    前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
    前記端末装置は、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定ステップと、
    前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定ステップと、
    前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知ステップとを実行し、
    前記サーバ装置は、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視ステップと、
    前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知ステップとを実行することを特徴とする通信制御方法。
  9. 端末装置と、クライアント装置と、サーバ装置とがネットワークを介して接続され、前記端末装置で発生したイベントを示すイベントメッセージを前記サーバ装置が受信した際、前記サーバ装置が当該イベントメッセージを前記クライアント装置に転送する際に用いられる通信制御プログラムであって、
    前記端末装置には、前記イベントについて前記サーバ装置又は前記クライアント装置がイベント通知先として登録されており、
    前記端末装置が備えるコンピュータに、該端末装置で発生したイベントが予め登録された通知すべき登録イベントである際、当該イベントが前記端末装置で発生したエラーを示すエラーイベントであるか否かを判定するエラー判定ステップと、
    前記イベントがエラーイベントであると、前記イベント通知先が前記サーバ装置であるか否かを判定する通知先判定ステップと、
    前記イベント通知先が前記サーバ装置であると、前記エラーイベントを示すエラーイベントメッセージを前記サーバ装置に通知するイベント通知ステップとを実行させ、
    前記サーバ装置が備えるコンピュータに、前記クライアント装置に転送した前記イベントメッセージが前記端末装置におけるエラーを示すエラーイベントであると、前記端末装置において当該エラーイベントの解除が行われたか否かを監視する監視ステップと、
    前記端末装置においてエラーイベントの解除が行われると、前記クライアント装置に前記エラーイベントが解除された旨を示すエラー解除メッセージを通知する通知ステップとを実行させることを特徴とする通信制御プログラム。
  10. 請求項９に記載の通信制御プログラムが記録されたコンピュータに読み取り可能な記録媒体。
JP2010175573A 2010-08-04 2010-08-04 サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体 Pending JP2012037976A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010175573A JP2012037976A (ja) 2010-08-04 2010-08-04 サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体
US13/198,079 US8775878B2 (en) 2010-08-04 2011-08-04 Information processing apparatus, communication system, communication control method, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010175573A JP2012037976A (ja) 2010-08-04 2010-08-04 サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体

Publications (1)

Publication Number Publication Date
JP2012037976A true JP2012037976A (ja) 2012-02-23

Family

ID=45556990

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010175573A Pending JP2012037976A (ja) 2010-08-04 2010-08-04 サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体

Country Status (2)

Country Link
US (1) US8775878B2 (ja)
JP (1) JP2012037976A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015162063A (ja) * 2014-02-27 2015-09-07 京セラドキュメントソリューションズ株式会社 イベント管理装置及びイベント管理方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10198304B2 (en) * 2014-11-04 2019-02-05 Oath Inc. Targeted crash fixing on a client device
JP6720735B2 (ja) * 2016-07-04 2020-07-08 コニカミノルタ株式会社 印刷システム及び装置検索方法並びに装置検索プログラム
WO2019220006A1 (en) * 2018-05-16 2019-11-21 Nokia Technologies Oy Error handling framework for security management in a communication system
JP2019204226A (ja) * 2018-05-22 2019-11-28 キヤノン株式会社 画像形成装置および端末装置および画像形成システムとその制御方法、プログラム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6697970B1 (en) * 2000-07-14 2004-02-24 Nortel Networks Limited Generic fault management method and system
DE10144006A1 (de) * 2001-09-07 2003-04-30 Siemens Ag Verfahren zur Meldungsdiagnose
US7284163B2 (en) * 2003-01-31 2007-10-16 American Megatrends, Inc. Event mechanism for reporting diagnostic event messages
JP4235481B2 (ja) * 2003-04-15 2009-03-11 キヤノン株式会社 通信機器及び通信機器のデータ処理方法
US8825837B2 (en) * 2010-04-21 2014-09-02 International Business Machines Corporation Notice of restored malfunctioning links
JP4379811B2 (ja) 2005-08-29 2009-12-09 京セラミタ株式会社 ネットワーク機器のエラー通知装置およびエラー通知プログラム
JP2010008742A (ja) * 2008-06-27 2010-01-14 Oki Data Corp 画像形成装置
US8453017B2 (en) * 2008-08-27 2013-05-28 Kyocera Document Solutions Inc. Electronic device saving selected error information and an error management system including such a device
US8250413B2 (en) * 2008-09-30 2012-08-21 Hewlett-Packard Development Company, L.P. Connection broker assignment status reporting
US8793783B2 (en) * 2011-12-20 2014-07-29 International Business Machines Corporation Dynamic allocation of network security credentials for alert notification recipients

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015162063A (ja) * 2014-02-27 2015-09-07 京セラドキュメントソリューションズ株式会社 イベント管理装置及びイベント管理方法

Also Published As

Publication number Publication date
US20120036403A1 (en) 2012-02-09
US8775878B2 (en) 2014-07-08

Similar Documents

Publication Publication Date Title
JP5595035B2 (ja) 情報処理装置、その方法及びプログラム
JP4865299B2 (ja) 情報処理装置及び情報処理方法及びそのプログラム
JP4753727B2 (ja) 画像処理システム、管理サーバ、画像処理方法及び画像処理プログラム
JP5236958B2 (ja) 通知方法、管理装置及びクライアント装置
US8935708B2 (en) Communication system and communication apparatus and control method thereof
EP3232318B1 (en) Image processing apparatus having file server function, and control method and storage medium therefor
US8250042B2 (en) Data processing apparatus and data processing method with conversion of error information
JP5979986B2 (ja) 配信システム及びその制御方法
JP2007122093A (ja) 印刷制御装置及び印刷制御方法ならびに印刷制御方法を実行するプログラム
JP2020140439A (ja) 印刷管理プログラム、印刷管理方法、および印刷管理装置
JP2012037976A (ja) サーバ装置、通信システム、通信制御方法、及び通信制御プログラム、並びに記録媒体
JP2008092556A (ja) 画像処理装置に対するリモートインターフェースを遠隔で構築するためのシステムおよび方法
US20050097198A1 (en) Printer monitoring system and method
JP5537160B2 (ja) イベント代行通知装置及びその制御方法とそのプログラム
CN101253048B (zh) 图像形成设备及其控制方法以及图像形成系统
JP2016076161A (ja) 管理システム及び情報処理方法
JP4987770B2 (ja) イベント通知装置、イベント通知方法、及びイベント通知プログラム
JP2007156614A (ja) ローカルデバイスが接続される制御装置におけるメニューデータの生成
JP2006285840A (ja) 文書管理システム
JP5056200B2 (ja) イベント通知方法及び制御プログラム並びに制御装置
JP2013156807A (ja) ネットワークにおけるイベント通知システム
JP4435772B2 (ja) キー操作監視方法、この方法をコンピュータに実行させるプログラムおよび画像形成装置
JP2006260596A (ja) 描画情報取得方法、この方法をコンピュータに実行させるプログラムおよび画像形成装置
JP4268174B2 (ja) キー操作再生方法、この方法をコンピュータに実行させるプログラムおよび画像形成装置
JP2009141774A (ja) データ処理装置及びその制御方法、コンピュータプログラム