デバイス管理システム
【課題】 デバイスを監視している拠点監視装置が監視の設定の変更指示をデバイスに行う。このとき、設定変更を反映するために、一時的にデバイスの監視を数十秒から１分程度止める。デバイスが監視を停止しているときに、サービスコールエラーやトナー切れなどのイベントが発生した場合には、監視すべきイベントが取得できないという問題があった。
【解決手段】 デバイスが、監視設定を反映して監視を再開する際に、前回の監視時の状態を記憶装置から読み出し、ただちにデバイスのステータス情報を拠点監視装置へ送信すべきか否かを判断し、必要なステータス情報を拠点監視装置へ送信する。
【解決手段】 デバイスが、監視設定を反映して監視を再開する際に、前回の監視時の状態を記憶装置から読み出し、ただちにデバイスのステータス情報を拠点監視装置へ送信すべきか否かを判断し、必要なステータス情報を拠点監視装置へ送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プリンタ等の画像形成装置に発生している障害等の情報を外部装置に通知する技術に関する。
【背景技術】
【０００２】
従来、プリンタ等の画像形成装置において、サービスマンによる修理を必要とするようなエラー（サービスコールエラー）が発生した場合に、デバイス管理システムを利用したメンテナンスが知られている。デバイス管理システムでは、発生したサービスコールエラー情報を、ネットワークを介して製造元或いは販売元のサービスセンターのホストサーバへ送る。そして、サービスセンター側では、サービスコールエラー情報を発した画像形成装置の修理のためにサービスマンを派遣するなどしてエラー対処を行っている。
【０００３】
また、デバイス監視システムでは、消耗品がなくなったことや交換されたことを検知し管理することで、消耗品を適切なタイミングでユーザーへ配送する、といった対処が行われている。このようなシステムで、画像形成装置等のデバイス装置におけるエラー発生時の対処方法としては、例えば次のようなものがあった。ユーザーによる電源ＯＦＦ／ＯＮ操作でサービスコールエラーが復旧した場合に、サービスコールエラーが解消したことをホストサーバ側に通知することができる情報処理装置を提供する（特許文献１を参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−７２９６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来のシステムでは次のような問題点があった。例えば、拠点監視装置のＰＣ移設などに伴い、監視情報の設定変更指示を画像形成装置に行うと、一時的に監視処理が停止する。しかし、監視を停止した間に発生したサービスコールエラーや、消耗品切れの状態変化が発生すると、監視システムはデバイスのメンテナンス情報を検知することができず、メンテナンスの対処が行いなくなるという問題があった。
【０００６】
本発明は上記従来の問題点に鑑み、設定変更によりデバイス監視が停止したとしても、監視再開時にサーバに通知するべき情報が発生したことを検知し、ホストサーバ側に通知することができる情報処理装置、その方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は上記目的を達成するため、ネットワークに接続された複数のデバイスからデバイスの監視情報を監視サーバにて収集することによりデバイスを監視するデバイス監視システムにおいて、監視対象のデバイスは、デバイスの状態変化を検知し、状態変化の検知時のデバイスステータスを送信することのできるデバイスステータス送信手段と、デバイスステータス送信手段の送信先や、その他の監視に必要な監視設定情報を記憶する記憶手段と、デバイスの監視設定情報を変更することのできる監視設定情報変更手段と、デバイスの監視設定情報変更手段によって、変更した監視設定情報をプログラムに反映する際に、記憶手段に記載されたデバイスの状態に応じて、前記デバイスステータスを送信するべきか否かを判断する判断手段と、判断手段の結果に応じて、デバイスステータスを送信する手段と、を有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、画像形成装置が設定変更により監視停止状態になったときに、発生した障害を該画像形成装置の監視再開時に検知し、外部装置側に知らせることが可能になる。
【図面の簡単な説明】
【０００９】
【図１】デバイス、拠点監視装置及び管理サーバとのネットワーク接続関係を示す図である。
【図２】デバイスのハードウェアコントローラの構成例を示すブロック図である。
【図３】デバイスのソフトウェア機能構成例を示すブロック図である。
【図４】デバイスの動作例を表すシーケンス図及びフローチャートである。
【図５】デバイスの不揮発性領域内の保管データの一例を示す図である。
【図６】デバイスのエラー発生通知にて送信されるパケットデータの一例を示す図である。
【図７】デバイスのエラー正常復帰通知にて送信されるパケットデータの一例を示す図である。
【図８】デバイスのエラー発生通知または正常復帰通知に対するレスポンスの一例を示す図である。
【図９】デバイスへの監視設定変更指示にて送信されるパケットデータの一例を示す図である。
【図１０】デバイスへの監視設定変更指示に対するレスポンスの一例を示す図である。
【図１１】デバイスへの監視設定問い合わせにて送信されるパケットデータの一例を示す図である。
【図１２】デバイスへの監視設定問い合わせに対するレスポンスの一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１１】
＜本実施形態のデバイス管理システムの構成例＞
図１は、本発明の実施の形態に係る複写機と、遠隔監視装置、及び、管理サーバとのネットワークにおける接続関係を示す図である。
【００１２】
図１において、１００は顧客の社内ネットワークに接続されたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）やＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）を示している。これらプリント・複写などの機能をもつ機器の事をここではデバイスと呼ぶ。また、１０１は複数のデバイス１００を監視する拠点監視装置を示している。そのほか、社内ネットワークには、インターネットとの接続ポイントであるファイアウォール１０２が設置されている。ファイアウォール１０２により、外部からの社内ＬＡＮ１０３への不正なネットワークアクセスを防止する。デバイス１００は、自己監視の機能を持っており、デバイスのカウンタ情報やアラームなどのデバイス監視情報を外部の監視機器である拠点監視装置１０１や、インターネット１０４上に設置している管理サーバ１０５へ送信することができる。デバイスの初期設定では、インターネット１０４上にある管理サーバのＷｅｂ Ｓｅｒｖｉｃｅへ監視データを送信するように設定してある。顧客のイントラネットに設置されたときに、プロクシサーバなどのネットワーク環境情報を設定することによって、自らデバイス監視情報を管理サーバへ送信可能となる。また、デバイスは、監視情報の設定変更を外部の機器から行うことが可能であり、例えば、拠点監視装置１０１からＵＲＬの変更指示を受信すると、デバイスの監視情報送信先を変更することができる。拠点監視装置１０１は、一般的なＰＣ（パーソナルコンピュータ）として図面に記されているが、監視プログラムの走る機器を指している。したがって、監視プログラムは、ＰＣのほかに専用のハードウェアやデバイスなどにインストールすることができる。ここでは、拠点監視装置の形態に制限はない。拠点監視装置１０１は、イントラネット１０３を介してデバイス１００の各種動作モード設定や、カウンタ値、稼働ログなどの稼働情報、およびハード障害やジャム多発等の障害情報を収集する。拠点監視装置１０１は、Ｗｅｂサービスや独自プロトコルを用いてサービスを提供し、デバイスから送信されるデバイス監視情報を受信することで情報収集を行なう。管理サーバ１０５は、インターネット１０４を介して、顧客のイントラネット１０３上に設置されている拠点監視装置１０１や、デバイス１００からデバイス管理情報を受信することでデバイスを管理している。拠点監視装置１０１は、顧客の社内ＬＡＮ１０３に大量のデバイスが存在する場合に社内ＬＡＮに存在するデバイスから、一元的にデバイス監視情報を収集し管理サーバ１０５へ送信を行うことでメンテナンスの効率を高めることができる。デバイスの監視情報とは、デバイスの使用状況や、現在の状態、また、ファームウェア情報などである。また、管理サーバは、課金カウンタのレポート表示、エラー・アラームなどの障害イベント通知、デバイスの部品消耗度の算出、トナー在庫個数の管理などのサービスを販売会社へ提供する。インターネット１０４には、イントラネット１０３に類似した別顧客のネットワークが無数に接続されている。
【００１３】
＜本実施形態のデバイスの制御部構成例＞
図２は、図１におけるデバイス１００制御部のハードウェア構成を示すブロック図である。
【００１４】
デバイス１００の制御部では、主として、プリントやスキャンなどプログラムの制御処理を行う。また、そのほかにデバイス監視プログラムなどの各アプリケーションが制御されている。デバイス１００は、管理サーバ１０５、または、拠点監視装置１０１へ監視情報を送信する際、制御部内でデバイス１００の監視情報を所定の通信フォーマットでデータ生成し、拠点監視装置１０１に送信するなどの処理を行う。制御部は、システム管理を行う部分と、画像処理管理を行う部分から構成されている。システム管理を行う各構成要素は、操作部２０１、Ｎｅｔｗｏｒｋ Ｉ／Ｆ部２０２、回線Ｉ／Ｆ部２０３、ＲＯＭ２０４、ＲＡＭ２０５、記憶装置２０６、ＣＰＵ２０７から構成されている。また、画像処理管理を行う各構成要素は、ＩＯ制御部２０８、画像処理部２０９、デジタルＩ／Ｆ部２１１、圧縮伸長部２１２、画素密度変換部２１３から構成されている。そして、これらの構成要素は、システムバス２１６及び画像バス２１７に接続されている。ＲＯＭ２０４にはデバイスの制御プログラム及び、デバイス監視プログラムが格納されており、ＣＰＵ２０７で実行される。ＲＡＭ２０５は、プログラムを実行するためのワークメモリエリアであり、デバイス監視プログラムが監視を行ううえで必要なデバイスのステータス情報や、画像データを一時記憶するための画像メモリでもある。２０６は不揮発性記憶装置であり、デバイス１００の再起動後も保持しておく必要のある各種動作モード設定や、カウンタ値（サイズ毎の印刷枚数や、原稿読み取り回数等）、および、ステータス情報（ステータスフラグを含む）などが記憶される。Ｎｅｔｗｏｒｋ Ｉ／Ｆ２０２はＬＡＮと接続するためのインタフェース部であり、ＬＡＮを介して拠点監視装置１０１と通信を行う。回線Ｉ／Ｆ部２０３は、ＩＳＤＮや公衆電話網に接続され、ＲＯＭ２０４内の通信制御プログラムにより制御され、ＩＳＤＮ Ｉ／Ｆやモデム、ＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）を介して遠隔の端末とデータの送受信を行う。ファクシミリの送受信もこの回線Ｉ／Ｆ部２０３を使用して行う。操作部２０１には表示手段やキー入力手段が内蔵されており、これらはＣＰＵ２０７にて制御される。操作者は、キー入力手段を通してスキャナ読み取りやプリント出力に関する各種設定指示や、作動／停止指示を行う。以上のデバイスがシステムバス２１６上に配置される。ＩＯ制御部２０８は、システムバス２１６と画像データを高速で転送する画像バス２１７とを接続するためのバスブリッジである。画像バス２１７は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス２１７上には以下のデバイスが配置される。デジタルＩ／Ｆ部２１１は、デバイスのリーダー部２１５やプリンタ部２１４と制御部とを接続し、画像データの同期系／非同期系の変換を行う。また、リーダー部２１５やプリンタ部２１４内の各所に配置した前述の各種センサが検出した情報は、このデジタルＩ／Ｆ部２１１、及びＩＯ制御部２０８を介してシステムバス２１６へ流れる。画像処理部２０９は、入力及び出力画像データに対し補正／加工／編集を行う。画像回転部２１０は画像データの回転を行う。画像圧縮伸長部２１２は、多値画像データはＪＰＥＧ、２値画像データはＪＢＩＧ／ＭＭＲ／ＭＲ／ＭＨの圧縮伸張処理を行う。画像密度変換部２１３は、出力用画像データに対して解像度変換等を行う。ＣＰＵ２０７で実行される制御プログラムにより、ＣＰＵ２０７は記憶装置２０６内のカウンタ値や稼働ログなどの稼動情報や障害情報を読み出してデバイス１００のステータス情報として拠点監視装置１０１へ、Ｎｅｔｗｏｒｋ Ｉ／Ｆ２０２を介して送信する。
【００１５】
＜印刷デバイス装置のソフトウェアモジュール構成＞
図３は、拠点監視装置１０１の外部システムと通信可能なデバイス１００のソフトウェアモジュールの構成を示す図である。図中の３０１乃至３０９、および、３１１乃至３１３がデバイス１００のソフトウェアモジュールに該当する。３０９は、組み込み診断システムのソフトウェアモジュールを表しており、３１４は監視設定変更システムのソフトウェアモジュールを表している。
【００１６】
デバイスインタフェース３０１は、図２のＩＯ制御部２０８を示す。該インタフェースを介してプリンタ部２１４で検知されるエラー（障害と呼ぶこともある）を含む画像形成装置ステータスが、組み込み診断システム３０９へ通知されてくる。画像形成装置のエラーとは、ハードディスクエラーや課金カウンタエラー等のサービスコールエラー、紙ジャム等のエラー、或いはトナーロー等のワーニングなどのエラー、或いはドアオープン、排紙トレイの紙積載超過なども含むものとする。状態イベントモジュール３０２は、デバイスインタフェース３０１から通知されたエラー情報をマネージャー３０４に通知する。デバイスインタフェース３０１から通知されるエラー情報は、プリンタ部３１４で各種センサにより検出された画像形成装置ステータスに基づく。このエラー情報は時系列的に変化する。タイマー３０３は、所定の時刻に行うカウンタの送信や送信できなかったエラー情報の再送の要求をマネージャー３０４に発行する。不揮発性記憶装置３０６には、送信すべきログ情報や、カウンタ、障害情報、及び、図４のステップＳ４１１において参照されるステータスフラグなどが格納されている。マネージャー３０４はロジック３０５を介してこの送信すべきデバイス監視情報を確認する。マネージャー３０４は、可変情報であるエラー情報とともに、自デバイスに係わる固有の識別子に相当する固定情報をＳＯＡＰファンクションモジュール３０７に通知する。ここで、固定情報とは、例えばＩＰアドレス、ＭＡＣアドレス、デバイスシリアル番号、製品名、製品タイプなどが挙げられる。これらは、図６の６０１、図７の７０１におけるｄｅｖｉｃｅスキーマに埋め込まれる情報である。
【００１７】
ＳＯＡＰファンクションモジュール３０７は、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８に、マネージャー３０４から受けた内容（固定情報及び可変情報）を渡す。そして、マークアップ言語記述の作成依頼、及び作成したマークアップ言語記述の指定サーバへの通信依頼を行う。ここで、指定サーバの情報は、事前にＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８が保持している形態でも良いし、固定情報に含めるようにしても良い。ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８では、ＳＯＡＰファンクションモジュール３０７からの固定情報を受け、図６、図７の６０１、７０１における、ｄｅｖｉｃｅスキーマに基づくマークアップ言語記述を作成する。そして同様に可変情報を受け、図６、７の６０２、６０３、７０２に示されるｓｔａｔｕｓスキーマに基づくマークアップ言語記述を同時に作成する。ここで、可変情報や固定情報の各々に対応するスキーマはＨＴＴＰ／ＳＯＡＰクライアントモジュールがアクセスできる記憶部に事前に格納されているものとする。そして、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８は、作成したマークアップ言語記述のデータを、指定のサーバへ送信する。マークアップ言語記述としては、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が挙げられる。
【００１８】
設定変更用ＷｅｂＳｅｒｖｉｃｅ３１１は、ＮｅｔｗｏｒｋＩＦ２０２より受信した監視設定変更要求を受け付ける。設定変更用ＷｅｂＳｅｒｖｉｃｅ３１１にて受け付けた監視設定変更要求は、認証３１２モジュールにより認証される。これは、ＨＴＴＰＳのクライアント認証で実現されてもよいし、ユーザアカウントとパスワードのようなデータで認証が行なわれてもよい。デバイスに対し監視設定変更要求を発行できる正規の機器だけがこの指示を発行できる。認証３１２モジュールは、認証の結果を設定変更用ＷｅｂＳｅｒｖｉｃｅに返し、認証が成功した場合、受け付けた設定変更要求から設定変更プログラム３１３に設定変更要求を発行する。設定変更プログラム３１３は、不揮発性記憶装置３０６へ監視設定としてプログラムの設定ファイルを書き換える。また、マネージャー３０４に対し設定を反映するために設定を再読み込みするように指示を発行する。
【００１９】
設定再読み込みの指示を受信したマネージャー３０４は、一時的にデバイス監視処理を停止して、不揮発性記憶装置３０６に保管されている監視設定を読み出して、監視プログラムの設定変更を反映する。
【００２０】
不揮発性記憶装置３０６には、設定変更指示を受信したときに、組み込み診断システムの状態を示す監視中フラグと、重要度の高い障害が発生していたかを示すイベントフラグが格納される。マネージャー３０４は、設定変更指示を受信したときに、組み込み診断システムの状態が監視中であった場合には、監視中フラグを“１”と設定して、設定変更処理へ入る。また、設定変更処理へ入る際に、デバイスに重要度の高い障害が発生していた場合には、イベントフラグを“１”と設定する。
【００２１】
組み込み診断システムが、設定情報を読み込んで監視を再開したときに監視中フラグが“１”であった場合には、デバイスに障害が発生していないかを確認する。デバイスに障害が発生していないかの問い合わせは、マネージャー３０４が、デバイスインタフェース３０１を介してプリンタ部３１４における状態の問い合わせを行う。このときデバイスのステータスに重要度の高い障害が発生していた場合には、デバイスインタフェース３０１の応答結果から、マネージャー３０４は、可変情報としてｃｏｄｅとｍａｊｏｒｓｔａｔｕｓの値を識別された種類のコード値に設定する。また、固定情報として上に説明した自デバイスに係わる情報を設定し、それらの情報をＳＯＡＰファンクションモジュール３０７に渡す。このとき、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８が、上述の可変情報及び固定情報を、自らＳＯＡＰファンクションモジュール３０７から取得するようにしても良い。
【００２２】
組み込み診断システムが、設定情報を読み込んで監視を再開したときにイベントフラグが“１”であった場合には、設定変更のために監視停止に入る前に重要度の高い障害が発生していたことになる。マネージャー３０４は、設定変更後に障害のステータスが変化している可能性があるために、デバイスインタフェース３０１を介してプリンタ部３１４における状態の問い合わせ要求が行われる。この時デバイスインタフェース３０１は、問い合わせが発生したことに応じて各種状態をセンサにより検知し応答するようにしても良いし、事前に検知しておいた各種状態を応答するようにしても良い。
【００２３】
デバイスインタフェース３０１の応答結果から、マネージャー３０４は、可変情報としてｃｏｄｅとｍａｊｏｒｓｔａｔｕｓの値を識別された種類のコード値に設定する。また、固定情報として上に説明した自デバイスに係わる情報を設定し、それらの情報をＳＯＡＰファンクションモジュール３０７に渡す。このとき、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８が、上述の可変情報及び固定情報を、自らＳＯＡＰファンクションモジュール３０７から取得するようにしても良い。何れの種類のエラーも発生していなければ、可変情報としてエラーが何もないという情報（ｃｏｄｅとｍａｊｏｒｓｔａｔｕｓの値を０とする）を設定し、それらの情報をＳＯＡＰファンクションモジュール３０７に渡す。
【００２４】
ＳＯＡＰファンクションモジュール３０７は、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８に対して、マネージャー３０４から受けた固定情報及び可変情報をもとにした、スキーマの作成及び指定のサーバへの通信依頼を行う。依頼を受けたＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８では、対応するスキーマを読み込み、読み込まれたスキーマ及び渡された値に基づき、図６、図７に示されるような、スキーマに基づくマークアップ言語記述を作成する。
【００２５】
以上の処理により、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８は依頼された固定情報及び可変情報の対応するスキーマに基づきマークアップ言語記述の作成を行う。また、監視再開時にイベントフラグが読み取られ且つ何れの種類の障害発生も識別されないと、障害発生が無いことを示す識別子を埋め込んだスキーマ―に基づくマークアップ言語記述を作成する。
【００２６】
一方、ホスト側（図３中の外部システム３１０）では、ゲートウェイを介して、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８から通知されたマークアップ言語記述の解析に基づき、障害の遷移を管理する。特に、図６に示されるような、障害発生が無いことを示す識別子を解析により識別すると、障害発生しているとして管理されていた障害について、障害解消を識別することができる。
【００２７】
より具体的には、図６、７のマークアップ言語記述のデータを受信するとともに、常に個々のデバイス及び個々の種類のエラー状態を更新する。更新されたエラー状態は記憶部に保存される。そして、更新の際に以前に発生していた種類の障害に対応する識別子（ｃｏｄｅの値、及びｍａｊｏｒｓｔａｔｕｓの値）が、受信したマークアップ言語記述の中に含まれておらず確認できなければ、その種類のエラーが解消したとものと識別する。特に、図６のマークアップ言語記述のデータを受信した場合には、例えば、以前に保持されていたすべてのエラーは解消されたとし、ホスト側のデバイス情報を正常状態として更新する。これにより、障害発生が解消しないことに起因する、無駄なサービスマンの派遣などを防ぐことができる。
【００２８】
尚、上の説明では、ＳＯＡＰファンクションモジュール３０７がＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８に各種情報の通知を行うよう説明した。しかし、ＨＴＴＰＳ／ＳＯＡＰクライアントモジュール３０８が、上述の可変情報及び固定情報を、自らＳＯＡＰファンクションモジュール３０７から取得するようにしても良い。
【００２９】
＜本実施の形態に係る印刷デバイス装置の動作＞
以上の構成において、図１に示したデバイス１００の動作について、図４を参照して説明する。なお、図４は、本実施の形態に係るデバイス１００の動作を示すフローチャートである。このフローチャートは、デバイス１００が通常の監視状態から、監視関する設定変更指示を拠点監視装置から受信し、監視を再開するまでの処理である。これは、図２に示すＲＯＭ２０４、ＲＡＭ２０５、記憶装置２０６のいずれかの記憶手段に記憶され、ＣＰＵ２０７により実行される。
【００３０】
まずステップＳ４０１において、組み込み監視システム３０９は、デバイスの監視を開始する。ステップＳ４０２において、ＣＰＵ２０７は、プリンタ部２１４のステータスに変化が生じたかどうかを検知する。検知方法としては、各種センサ値を検出する方式でも、レスポンスの未応答を認識する方式でも、プリンタにおけるステータスを識別できれば、どのような方法でもよい。プリンタ部２１４のステータスに変化が発生し、且つサービスコールエラー（例えば、ハードディスクエラーや課金カウンタエラーなどサービスマンによる修理を必要とするような種類のエラー）が発生している場合には、ステップＳ４０３へ進む。ステップＳ４０３では、後述の図６で示すパケットを用いて、そのサービスコールエラー情報を拠点監視装置１０１に通知する（Ｔ１）。この通知に対する拠点監視装置１０１からの返答（レスポンス）Ｔ２が、後述する図７に示すレスポンスパケットであり、ここでは、サービスコールエラー情報を正常に受け取ったことを意味する＜ｒｅｓｕｌｔ＞ＯＫ＜ｒｅｓｕｌｔ＞が返信されている。また、サービスコールエラーが復旧した場合には、後述の図６に示すパケットを用いて、正常復帰情報を拠点監視装置１０１へ通知する。
【００３１】
ステップＳ４０２において、デバイスにサービスコールエラーなどのステータス変化が発生していない場合、組み込み監視システム３０９は処理をステップＳ４０４へ進める。尚、例えばドアオープンなどの、サービスコールエラーで無いエラーに関しても、ステップＳ４０２でＹＥＳと判定しても良い。
【００３２】
ステップＳ４０４では、デバイス１００は、監視設定変更システム３１４により、拠点監視装置１０１より発行された監視設定変更要求を受信する（Ｔ３）。監視設定変更要求を受信しない場合には、ステップＳ４０１へ戻り、監視処理を繰り返す。監視設定変更要求を拠点監視装置から受信した場合には、拠点監視装置に対して、監視設定変更要求を受信したことを示す応答（レスポンス）Ｔ４を発行し、ステップＳ４０５へ進む。ステップＳ４０５において、監視設定変更要求を受信したときに、デバイス１００が監視中の状態であった場合には、ステップＳ４０６へ進む。ステップＳ４０６では、設定変更要求指示を処理する前に、現在の組み込み診断システム３０９が監視状態であることを、不揮発性記憶装置３０６の監視中フラグ用メモリ領域に“１”を書き込み、ステップＳ４０７へ進む。また、ステップＳ４０５において、監視設定変更要求を受信したときに、デバイス１００が監視中の状態でなかった場合には、ステップＳ４０９へ進む。
【００３３】
ステップＳ４０７では、デバイス１００に重要度の高いイベントが発生していないか確認を行う。重要度の高いイベントが発生していた場合には、そのイベントが解消されたか否かが重要な情報となる。このため、監視が一時的に中断され、再度監視が再開されたときには、その重要度の高いイベントがどうなったかを拠点監視装置に通知する必要がある。重要度の高いイベントがデバイス１００に発生していた場合には、ステップＳ４０８へ進む。ステップＳ４０８では、デバイス１００に重要度の高いイベントが発行していることを記録するために、不揮発性記憶装置３０６のイベントフラグ用メモリ領域に“１”を書き込み、ステップＳ４０９へ進む。
【００３４】
ステップＳ４０９では、拠点監視装置から指示された監視設定変更要求を元に、監視設定変更を行う。このときに、デバイス１００の監視を一時的に停止し、設定情報を再度読み込むことによって変更を行う。拠点監視装置１０１は、Ｔ３によって要求した設定変更要求指示の結果がどのようになったかをポーリングによって確認する。このときの確認はＴ５によってリクエストされ、設定変更ＷｅｂＳｅｒｖｉｃｅ３１１は、確認指示に対する応答（レスポンス）Ｔ６を発行する。ステップＳ４０９にて、設定変更処理が完了すると、ステップＳ４１０へ進み、デバイス１００は監視を開始する。このとき、組み込み診断システムは新しい監視設定を読み込む。ここでいう監視設定とは、不揮発性記憶装置３０６に保存されているイベントフラグ、監視中フラグ、拠点監視装置１０１のＵＲＬやポート、並びに拠点監視装置１０１との送信間隔を示すスケジュール情報などである。
【００３５】
続くステップＳ４１１では、不揮発性記憶装置３０６に保存されている監視中フラグを参照し、監視中フラグが”１”であれば、ステップＳ４１２へ進み、”０”であれば本処理を終了する。つまり、監視中フラグが“１”であることは、当該デバイスの監視設定の変更を受け付けたときには、監視処理がすでに動いており、デバイスが監視中であることを示している。本フラグがあることによって、監視処理は、新しい設定情報を読み込んで起動するときのデバイスの最新ステータスを送信する必要性を確認することができる。
【００３６】
ステップＳ４１２では、不揮発性記憶装置３０６に保存されているイベントフラグを参照し、イベントフラグが“１”であれば、ステップＳ４１４へ進み、“０”であればステップＳ４１３へ進む。ここで、イベントフラグが”１”であることは、当該デバイスの監視設定の変更を受け付けたときには、すでに重大な障害が発生したことを示している。このため、監視処理が停止していた間にデバイスになんらかの状態変化が発生していた場合には、遠隔監視を利用するユーザーが状態変化を把握する必要があると判断する。当該デバイスの監視設定の変更を受け付けたときに、重大な障害が発生していない場合には、イベントフラグが”０”となっている。ステップＳ４１３にて、監視処理が停止している間に、状態が変化していないかを確認する。ここで重大なイベントが発生していたい場合には、ステップＳ４１４へ進み、何も発生しておらず、通常の状態であった場合には、処理を終了する。
【００３７】
ステップＳ４１４では、当該デバイスの最新ステータスを確認し、拠点監視装置１０１へステータス変化通知を送信する（Ｔ７）。この通知に対する拠点監視装置１０１からの応答（レスポンス）Ｔ８は、後述する図７に示すレスポンスパケットであり、ここでは、状態変化通知を正常に受け取ったことを示している。監視処理は、状態変化通知を拠点監視装置へ送信し、監視設定変更時の一連の処理を終了する。この後、通常の監視処理へと切り替わる。
【００３８】
また、上記の説明では、デバイス装置であるプリンタ部２１４のエラーとしてサービスコールエラーに限定して説明したが、サービスコールエラーに限らず、紙ジャム等のエラー、或いはトナーロー等のワーニングなどのエラーであっても良い。
【００３９】
＜不揮発記憶領域に保管されるデータの一例＞
図５は、本実施例の形態にかかる不揮発領域に保管されるデータの一例を示す図である。保管されるデータには、デバイスを識別するための情報であるデバイス固定情報と、デバイス監視を行うための監視設定情報、そのほか、設定変更を受けたときに利用する設定変更時情報、現在のデバイスステータスを保管するためのＣｕｒｒｅｎｔＳｔａｔｕｓなどが保管される。
【００４０】
デバイス固定情報には、図４の通信Ｔ１やＴ７で利用するデバイスの識別情報として、ＭａｃアドレスやＩＰアドレス、ＳｅｒｉａｌＮｕｍｂｅｒなどの情報が保管される。
【００４１】
監視設定情報には、組み込み診断システム３０９がデバイス監視情報を送信するときの送信先ＵＲＬやポート番号が保管されている。また、直接デバイスが監視情報を管理サーバ１０５へ送るのか、拠点監視装置１０１を経由してデバイス監視情報を送信するかのモード設定情報などが保管される。
【００４２】
設定変更時情報には、監視設定変更要求を受信したときに、監視を行なっていたかを記述する監視中フラグや、継続監視の必要な重大な障害が発生しているかを記述するイベントフラグなどがある。また、前回の設定変更要求の処理タイプや、その処理結果が保管される。ＣｕｒｒｅｎｔＳｔａｔｕｓには、そのときのデバイスの異常ステータスを記録する。デバイスの状態が常にこの領域で保管され、状態変化を検知すると同時に、新しい状態へＴｉｍｅＳｔａｍｐとともに書き換える。そして、書き換わった最新の状態を拠点漢詩装置１０１へと送信を行う。
【００４３】
＜エラー通知用のパケットデータの一例＞
図６は、本実施の形態に係るエラー通知時（図４のＴ１，Ｔ７）に送信されるマークアップ言語のパケットデータの一例を示す図であり、スキーマに基づき記述されている。このパケットデータは、ＨＴＴＰ上のＳＯＡＰを用いたエラー通知の一例である。このパケット（ｐｏｓｔＳｔａｔｕｓＩｎｆｏと称される）は、デバイス１００から拠点監視装置１０１に送信される。
【００４４】
このデータはＸＭＬ形式で記述されている。無論ＸＭＬ形式に限定されるもので無い。例えばＨＴＭＬでも良い。ｐｏｓｔＳｔａｔｕｓＩｎｆｏパケットは、プリンタ部２１４にエラーが発生した際に、拠点監視装置１０１にエラー情報を通知するコマンドである。固定的な情報を示す図６のパケットの発信元或いはエラー発生元のデバイス装置を示すデバイス情報（＜ｄｅｖｉｃｅ＞タグ）や、可変的な情報を示すステータス情報リスト（＜ｓｔａｔｕｓ＞タグ）等の情報が記述されている。＜ｄｅｖｉｃｅ＞タグには、ＭＡＣアドレスを識別する＜ｍａｃ＞、ＩＰアドレスを識別する＜ｉｐ＞、シリアル番号＜ｓｅｒｉａｌＮｕｍｂｅｒ＞、製品名＜ｐｒｏｄｕｃｔＮａｍｅ＞、及び形式＜ｔｙｐｅ＞が記述される。また、ｐｏｓｔＳｔａｔｕｓＩｎｆｏには、デバイスを識別する＜ｄｅｖｉｃｅ＞と＜ｓｔａｔｕｓ＞のリスト、並びにカウンタ情報＜ｃｏｕｎｔｅｒＬｉｓｔ＞が含まれている。＜ｓｔａｔｕｓ＞には、エラーコード＜ｃｏｄｅ＞、大分類の＜ｍａｊｏｒｓｔａｔｕｓ＞、エラーを示す文字情報＜ｏｐｍｅｓｓａｇｅ＞、及びタイムスタンプ情報＜ｔｉｍｅＳｔａｍｐ＞が記述されている。＜ｃｏｕｎｔｅｒＬｉｓｔ＞には、サービスモード番号＜ｉｄ＞とサービスモード番号で指定されたカウンタ値＜ｖａｌｕｅ＞が記述されている。なお、上記図６の説明におけるクライアントとはプリンタなどのデバイスを指す。
【００４５】
＜正常復帰通知用のパケットデータの一例＞
図６は、本実施の形態に係るエラー正常復帰通知時（図４のＴ７）に送信されるパケットデータの一例を示す図であり、図６と同様にスキーマに基づき記述されている。このパケットデータは、エラーが解消された後、ＨＴＴＰ上のＳＯＡＰを用いてデバイス１００から拠点監視装置１０１に送信される正常復帰通知用のパケットデータ（ｐｏｓｔＳｔａｔｕｓＩｎｆｏと称される）の一例である。
【００４６】
図６に示したパケットデータとスキーマは同様であるが、＜ｓｔａｔｕｓ＞において、エラーコード＜ｃｏｄｅ＞並びに大分類の＜ｍａｊｏｒｓｔａｔｕｓ＞がそれぞれ０、エラーを示す文字情報＜ｏｐｍｅｓｓａｇｅ＞はＮＵＬＬが設定される。このように＜ｓｔａｔｕｓ＞を設定することにより、エラーが解消されたことを示すパケットとなっている。
【００４７】
また、先の図６で示した＜ｄｅｖｉｃｅ＞タグにおける、ＭＡＣアドレス、ＩＰアドレス、及びシリアル番号によって、デバイスを特定することができるため、どのデバイス装置がエラー解消したかを特定することができる。また、エラーが解消される旨を通知するスキーマとしてｐｏｓｔＳｔａｔｕｓＩｎｆｏを使用したが、その他のＳＯＡＰ関数を使用しても良い。
【００４８】
このように、図６と同様の、ｓｔａｔｕｓスキーマ（＜ｓｔａｕｔｓ＞）を用い、図６に示されるエラー正常復帰通知を行うことができるので、通知フォーマットを簡易化できる。結果、通知を受ける側の拠点監視装置１０１側の処理を効率化できる。例えば、エラー正常復帰通知を示すスキーマをｓｔａｔｕｓスキーマとは別途設けるにようにしても良い。しかし、より好適な形態として、本実施例では、拠点監視装置１０１側で、まずｓｔａｔｕｓスキーマ６０２を解析し、図６の６０２と同様の＜ｍａｊｏｒｓｔａｔｕｓ＞スキーマで記述される値が０であることを識別し、サービスコールエラーが解消したと判定する。これにより、拠点監視装置１０１側のスキーマ判定処理を軽減できる。
【００４９】
＜通知に対するレスポンスの一例＞ 図７は、本実施の形態に係るエラー通知（図６）又は正常復帰通知（図６）に対するレスポンスの一例を示す図であり、図６、７と同様にスキーマに基づき記述されている。本データも図６のパケットデータと同様にＸＭＬ形式で記述され、本実施の形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ｐｏｓｔＳｔａｔｕｓＩｎｆｏ応答パケットには、ｐｏｓｔＳｔａｔｕｓＩｎｆｏコマンド対する結果情報＜ｒｅｓｕｌｔ＞として、ＯＫやＮＧを記述し、返信する。
【００５０】
＜デバイスへの監視設定変更要求のパケットデータの一例＞
図８は、本実施の形態に係る漢詩設定変更要求時（図４のＴ３）に送信されるマークアップ言語のパケットデータの一例を示す図であり、スキーマに基づき記述されている。このパケットデータは、監視設定変更を指示するために拠点監視装置１０１からデバイス１００に送信されるパケットデータ（ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇと称される）の一例である。ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇパケットは、拠点監視装置１０１が、特定のデバイスに対して監視設定変更を発行するコマンドである。これには、特定のデバイス宛の指示であることを示す＜ｓｅｒｉａｌＮｕｍｂｅｒ＞や、デバイス監視情報の送信先である＜ｓｅｎｄＵＲＬ＞、特定の処理を指示する＜ｐｒｏｃｅｓｓＴｙｐｅ＞などの情報がある。また、この要求発行元を識別するためにアカウント情報やパスワード情報などが記述されても良い。
【００５１】
＜監視設定変更要求に対するレスポンスの一例＞
図９は、本実施の形態に係る監視設定変更要求（図８）に対するレスポンスの一例を示す図であり、図６、７と同様にスキーマに基づき記述されている。本データも図６のパケットデータと同様にＸＭＬ形式で記述され、本実施の形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。 ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇ応答パケットには、ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇコマンド対する結果情報＜ｒｅｓｕｌｔ＞として、ＯＫやＮＧを記述し、返信する。
【００５２】
＜デバイスへの監視設定問い合わせのパケットデータの一例＞
図１０は、本実施の形態に係る監視設定問い合わせ（図４のＴ５）に送信されるマークアップ言語のパケットデータの一例を示す図であり、スキーマに基づき記述されている。このパケットデータは、監視設定の問い合わせを指示するために、拠点監視装置１０１からデバイス１００に送信されるパケットデータ（ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇと称される）の一例である。ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇパケットは、拠点監視装置１０１が特定のデバイスに対して監視設定の問い合わせを発行するコマンドである。 これには特定のデバイス宛の指示であることを示すデバイス識別子である＜ｓｅｒｉａｌＮｕｍｂｅｒ＞の情報がある。
【００５３】
＜監視設定変更要求に対するレスポンスの一例＞
図１１は、本実施の形態に係る監視設定問い合わせ（図４のＴ５）に対するレスポンスの一例を示す図であり、図６、７と同様にスキーマに基づき記述されている。本データも図６のパケットデータと同様にＸＭＬ形式で記述され、本実施の形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇ応答パケットには、ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇコマンド対する処理結果として＜ｒｅｓｕｌｔ＞にＯＫ／ＮＧを記述し、処理を実施した時刻を記述する＜ｔｉｍｅＳｔａｍｐ＞がある。また、問い合わせを実行したときの監視設定を出力する情報がある。ｊこれには、デバイスの識別子＜ｓｅｒｉａｌＮｕｍｂｅｒ＞やデバイス監視情報の送信先ＵＲＬ＜ｓｅｎｄＵｒｌ＞、前回処理を受け付けたときの処理の種類＜ｐｒｏｃｅｓｓＴｙｐｅ＞や、処理結果＜ｓｔａｔｅ＞がある。この＜ｓｔａｔｅ＞には、ＣＯＭＰＬＥＴＥＤのほかに、エラーなど処理がとまってしまった場合のステータスを記述する。
【００５４】
（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【技術分野】
【０００１】
本発明は、プリンタ等の画像形成装置に発生している障害等の情報を外部装置に通知する技術に関する。
【背景技術】
【０００２】
従来、プリンタ等の画像形成装置において、サービスマンによる修理を必要とするようなエラー（サービスコールエラー）が発生した場合に、デバイス管理システムを利用したメンテナンスが知られている。デバイス管理システムでは、発生したサービスコールエラー情報を、ネットワークを介して製造元或いは販売元のサービスセンターのホストサーバへ送る。そして、サービスセンター側では、サービスコールエラー情報を発した画像形成装置の修理のためにサービスマンを派遣するなどしてエラー対処を行っている。
【０００３】
また、デバイス監視システムでは、消耗品がなくなったことや交換されたことを検知し管理することで、消耗品を適切なタイミングでユーザーへ配送する、といった対処が行われている。このようなシステムで、画像形成装置等のデバイス装置におけるエラー発生時の対処方法としては、例えば次のようなものがあった。ユーザーによる電源ＯＦＦ／ＯＮ操作でサービスコールエラーが復旧した場合に、サービスコールエラーが解消したことをホストサーバ側に通知することができる情報処理装置を提供する（特許文献１を参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−７２９６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来のシステムでは次のような問題点があった。例えば、拠点監視装置のＰＣ移設などに伴い、監視情報の設定変更指示を画像形成装置に行うと、一時的に監視処理が停止する。しかし、監視を停止した間に発生したサービスコールエラーや、消耗品切れの状態変化が発生すると、監視システムはデバイスのメンテナンス情報を検知することができず、メンテナンスの対処が行いなくなるという問題があった。
【０００６】
本発明は上記従来の問題点に鑑み、設定変更によりデバイス監視が停止したとしても、監視再開時にサーバに通知するべき情報が発生したことを検知し、ホストサーバ側に通知することができる情報処理装置、その方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は上記目的を達成するため、ネットワークに接続された複数のデバイスからデバイスの監視情報を監視サーバにて収集することによりデバイスを監視するデバイス監視システムにおいて、監視対象のデバイスは、デバイスの状態変化を検知し、状態変化の検知時のデバイスステータスを送信することのできるデバイスステータス送信手段と、デバイスステータス送信手段の送信先や、その他の監視に必要な監視設定情報を記憶する記憶手段と、デバイスの監視設定情報を変更することのできる監視設定情報変更手段と、デバイスの監視設定情報変更手段によって、変更した監視設定情報をプログラムに反映する際に、記憶手段に記載されたデバイスの状態に応じて、前記デバイスステータスを送信するべきか否かを判断する判断手段と、判断手段の結果に応じて、デバイスステータスを送信する手段と、を有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、画像形成装置が設定変更により監視停止状態になったときに、発生した障害を該画像形成装置の監視再開時に検知し、外部装置側に知らせることが可能になる。
【図面の簡単な説明】
【０００９】
【図１】デバイス、拠点監視装置及び管理サーバとのネットワーク接続関係を示す図である。
【図２】デバイスのハードウェアコントローラの構成例を示すブロック図である。
【図３】デバイスのソフトウェア機能構成例を示すブロック図である。
【図４】デバイスの動作例を表すシーケンス図及びフローチャートである。
【図５】デバイスの不揮発性領域内の保管データの一例を示す図である。
【図６】デバイスのエラー発生通知にて送信されるパケットデータの一例を示す図である。
【図７】デバイスのエラー正常復帰通知にて送信されるパケットデータの一例を示す図である。
【図８】デバイスのエラー発生通知または正常復帰通知に対するレスポンスの一例を示す図である。
【図９】デバイスへの監視設定変更指示にて送信されるパケットデータの一例を示す図である。
【図１０】デバイスへの監視設定変更指示に対するレスポンスの一例を示す図である。
【図１１】デバイスへの監視設定問い合わせにて送信されるパケットデータの一例を示す図である。
【図１２】デバイスへの監視設定問い合わせに対するレスポンスの一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１１】
＜本実施形態のデバイス管理システムの構成例＞
図１は、本発明の実施の形態に係る複写機と、遠隔監視装置、及び、管理サーバとのネットワークにおける接続関係を示す図である。
【００１２】
図１において、１００は顧客の社内ネットワークに接続されたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）やＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）を示している。これらプリント・複写などの機能をもつ機器の事をここではデバイスと呼ぶ。また、１０１は複数のデバイス１００を監視する拠点監視装置を示している。そのほか、社内ネットワークには、インターネットとの接続ポイントであるファイアウォール１０２が設置されている。ファイアウォール１０２により、外部からの社内ＬＡＮ１０３への不正なネットワークアクセスを防止する。デバイス１００は、自己監視の機能を持っており、デバイスのカウンタ情報やアラームなどのデバイス監視情報を外部の監視機器である拠点監視装置１０１や、インターネット１０４上に設置している管理サーバ１０５へ送信することができる。デバイスの初期設定では、インターネット１０４上にある管理サーバのＷｅｂ Ｓｅｒｖｉｃｅへ監視データを送信するように設定してある。顧客のイントラネットに設置されたときに、プロクシサーバなどのネットワーク環境情報を設定することによって、自らデバイス監視情報を管理サーバへ送信可能となる。また、デバイスは、監視情報の設定変更を外部の機器から行うことが可能であり、例えば、拠点監視装置１０１からＵＲＬの変更指示を受信すると、デバイスの監視情報送信先を変更することができる。拠点監視装置１０１は、一般的なＰＣ（パーソナルコンピュータ）として図面に記されているが、監視プログラムの走る機器を指している。したがって、監視プログラムは、ＰＣのほかに専用のハードウェアやデバイスなどにインストールすることができる。ここでは、拠点監視装置の形態に制限はない。拠点監視装置１０１は、イントラネット１０３を介してデバイス１００の各種動作モード設定や、カウンタ値、稼働ログなどの稼働情報、およびハード障害やジャム多発等の障害情報を収集する。拠点監視装置１０１は、Ｗｅｂサービスや独自プロトコルを用いてサービスを提供し、デバイスから送信されるデバイス監視情報を受信することで情報収集を行なう。管理サーバ１０５は、インターネット１０４を介して、顧客のイントラネット１０３上に設置されている拠点監視装置１０１や、デバイス１００からデバイス管理情報を受信することでデバイスを管理している。拠点監視装置１０１は、顧客の社内ＬＡＮ１０３に大量のデバイスが存在する場合に社内ＬＡＮに存在するデバイスから、一元的にデバイス監視情報を収集し管理サーバ１０５へ送信を行うことでメンテナンスの効率を高めることができる。デバイスの監視情報とは、デバイスの使用状況や、現在の状態、また、ファームウェア情報などである。また、管理サーバは、課金カウンタのレポート表示、エラー・アラームなどの障害イベント通知、デバイスの部品消耗度の算出、トナー在庫個数の管理などのサービスを販売会社へ提供する。インターネット１０４には、イントラネット１０３に類似した別顧客のネットワークが無数に接続されている。
【００１３】
＜本実施形態のデバイスの制御部構成例＞
図２は、図１におけるデバイス１００制御部のハードウェア構成を示すブロック図である。
【００１４】
デバイス１００の制御部では、主として、プリントやスキャンなどプログラムの制御処理を行う。また、そのほかにデバイス監視プログラムなどの各アプリケーションが制御されている。デバイス１００は、管理サーバ１０５、または、拠点監視装置１０１へ監視情報を送信する際、制御部内でデバイス１００の監視情報を所定の通信フォーマットでデータ生成し、拠点監視装置１０１に送信するなどの処理を行う。制御部は、システム管理を行う部分と、画像処理管理を行う部分から構成されている。システム管理を行う各構成要素は、操作部２０１、Ｎｅｔｗｏｒｋ Ｉ／Ｆ部２０２、回線Ｉ／Ｆ部２０３、ＲＯＭ２０４、ＲＡＭ２０５、記憶装置２０６、ＣＰＵ２０７から構成されている。また、画像処理管理を行う各構成要素は、ＩＯ制御部２０８、画像処理部２０９、デジタルＩ／Ｆ部２１１、圧縮伸長部２１２、画素密度変換部２１３から構成されている。そして、これらの構成要素は、システムバス２１６及び画像バス２１７に接続されている。ＲＯＭ２０４にはデバイスの制御プログラム及び、デバイス監視プログラムが格納されており、ＣＰＵ２０７で実行される。ＲＡＭ２０５は、プログラムを実行するためのワークメモリエリアであり、デバイス監視プログラムが監視を行ううえで必要なデバイスのステータス情報や、画像データを一時記憶するための画像メモリでもある。２０６は不揮発性記憶装置であり、デバイス１００の再起動後も保持しておく必要のある各種動作モード設定や、カウンタ値（サイズ毎の印刷枚数や、原稿読み取り回数等）、および、ステータス情報（ステータスフラグを含む）などが記憶される。Ｎｅｔｗｏｒｋ Ｉ／Ｆ２０２はＬＡＮと接続するためのインタフェース部であり、ＬＡＮを介して拠点監視装置１０１と通信を行う。回線Ｉ／Ｆ部２０３は、ＩＳＤＮや公衆電話網に接続され、ＲＯＭ２０４内の通信制御プログラムにより制御され、ＩＳＤＮ Ｉ／Ｆやモデム、ＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）を介して遠隔の端末とデータの送受信を行う。ファクシミリの送受信もこの回線Ｉ／Ｆ部２０３を使用して行う。操作部２０１には表示手段やキー入力手段が内蔵されており、これらはＣＰＵ２０７にて制御される。操作者は、キー入力手段を通してスキャナ読み取りやプリント出力に関する各種設定指示や、作動／停止指示を行う。以上のデバイスがシステムバス２１６上に配置される。ＩＯ制御部２０８は、システムバス２１６と画像データを高速で転送する画像バス２１７とを接続するためのバスブリッジである。画像バス２１７は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス２１７上には以下のデバイスが配置される。デジタルＩ／Ｆ部２１１は、デバイスのリーダー部２１５やプリンタ部２１４と制御部とを接続し、画像データの同期系／非同期系の変換を行う。また、リーダー部２１５やプリンタ部２１４内の各所に配置した前述の各種センサが検出した情報は、このデジタルＩ／Ｆ部２１１、及びＩＯ制御部２０８を介してシステムバス２１６へ流れる。画像処理部２０９は、入力及び出力画像データに対し補正／加工／編集を行う。画像回転部２１０は画像データの回転を行う。画像圧縮伸長部２１２は、多値画像データはＪＰＥＧ、２値画像データはＪＢＩＧ／ＭＭＲ／ＭＲ／ＭＨの圧縮伸張処理を行う。画像密度変換部２１３は、出力用画像データに対して解像度変換等を行う。ＣＰＵ２０７で実行される制御プログラムにより、ＣＰＵ２０７は記憶装置２０６内のカウンタ値や稼働ログなどの稼動情報や障害情報を読み出してデバイス１００のステータス情報として拠点監視装置１０１へ、Ｎｅｔｗｏｒｋ Ｉ／Ｆ２０２を介して送信する。
【００１５】
＜印刷デバイス装置のソフトウェアモジュール構成＞
図３は、拠点監視装置１０１の外部システムと通信可能なデバイス１００のソフトウェアモジュールの構成を示す図である。図中の３０１乃至３０９、および、３１１乃至３１３がデバイス１００のソフトウェアモジュールに該当する。３０９は、組み込み診断システムのソフトウェアモジュールを表しており、３１４は監視設定変更システムのソフトウェアモジュールを表している。
【００１６】
デバイスインタフェース３０１は、図２のＩＯ制御部２０８を示す。該インタフェースを介してプリンタ部２１４で検知されるエラー（障害と呼ぶこともある）を含む画像形成装置ステータスが、組み込み診断システム３０９へ通知されてくる。画像形成装置のエラーとは、ハードディスクエラーや課金カウンタエラー等のサービスコールエラー、紙ジャム等のエラー、或いはトナーロー等のワーニングなどのエラー、或いはドアオープン、排紙トレイの紙積載超過なども含むものとする。状態イベントモジュール３０２は、デバイスインタフェース３０１から通知されたエラー情報をマネージャー３０４に通知する。デバイスインタフェース３０１から通知されるエラー情報は、プリンタ部３１４で各種センサにより検出された画像形成装置ステータスに基づく。このエラー情報は時系列的に変化する。タイマー３０３は、所定の時刻に行うカウンタの送信や送信できなかったエラー情報の再送の要求をマネージャー３０４に発行する。不揮発性記憶装置３０６には、送信すべきログ情報や、カウンタ、障害情報、及び、図４のステップＳ４１１において参照されるステータスフラグなどが格納されている。マネージャー３０４はロジック３０５を介してこの送信すべきデバイス監視情報を確認する。マネージャー３０４は、可変情報であるエラー情報とともに、自デバイスに係わる固有の識別子に相当する固定情報をＳＯＡＰファンクションモジュール３０７に通知する。ここで、固定情報とは、例えばＩＰアドレス、ＭＡＣアドレス、デバイスシリアル番号、製品名、製品タイプなどが挙げられる。これらは、図６の６０１、図７の７０１におけるｄｅｖｉｃｅスキーマに埋め込まれる情報である。
【００１７】
ＳＯＡＰファンクションモジュール３０７は、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８に、マネージャー３０４から受けた内容（固定情報及び可変情報）を渡す。そして、マークアップ言語記述の作成依頼、及び作成したマークアップ言語記述の指定サーバへの通信依頼を行う。ここで、指定サーバの情報は、事前にＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８が保持している形態でも良いし、固定情報に含めるようにしても良い。ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８では、ＳＯＡＰファンクションモジュール３０７からの固定情報を受け、図６、図７の６０１、７０１における、ｄｅｖｉｃｅスキーマに基づくマークアップ言語記述を作成する。そして同様に可変情報を受け、図６、７の６０２、６０３、７０２に示されるｓｔａｔｕｓスキーマに基づくマークアップ言語記述を同時に作成する。ここで、可変情報や固定情報の各々に対応するスキーマはＨＴＴＰ／ＳＯＡＰクライアントモジュールがアクセスできる記憶部に事前に格納されているものとする。そして、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８は、作成したマークアップ言語記述のデータを、指定のサーバへ送信する。マークアップ言語記述としては、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が挙げられる。
【００１８】
設定変更用ＷｅｂＳｅｒｖｉｃｅ３１１は、ＮｅｔｗｏｒｋＩＦ２０２より受信した監視設定変更要求を受け付ける。設定変更用ＷｅｂＳｅｒｖｉｃｅ３１１にて受け付けた監視設定変更要求は、認証３１２モジュールにより認証される。これは、ＨＴＴＰＳのクライアント認証で実現されてもよいし、ユーザアカウントとパスワードのようなデータで認証が行なわれてもよい。デバイスに対し監視設定変更要求を発行できる正規の機器だけがこの指示を発行できる。認証３１２モジュールは、認証の結果を設定変更用ＷｅｂＳｅｒｖｉｃｅに返し、認証が成功した場合、受け付けた設定変更要求から設定変更プログラム３１３に設定変更要求を発行する。設定変更プログラム３１３は、不揮発性記憶装置３０６へ監視設定としてプログラムの設定ファイルを書き換える。また、マネージャー３０４に対し設定を反映するために設定を再読み込みするように指示を発行する。
【００１９】
設定再読み込みの指示を受信したマネージャー３０４は、一時的にデバイス監視処理を停止して、不揮発性記憶装置３０６に保管されている監視設定を読み出して、監視プログラムの設定変更を反映する。
【００２０】
不揮発性記憶装置３０６には、設定変更指示を受信したときに、組み込み診断システムの状態を示す監視中フラグと、重要度の高い障害が発生していたかを示すイベントフラグが格納される。マネージャー３０４は、設定変更指示を受信したときに、組み込み診断システムの状態が監視中であった場合には、監視中フラグを“１”と設定して、設定変更処理へ入る。また、設定変更処理へ入る際に、デバイスに重要度の高い障害が発生していた場合には、イベントフラグを“１”と設定する。
【００２１】
組み込み診断システムが、設定情報を読み込んで監視を再開したときに監視中フラグが“１”であった場合には、デバイスに障害が発生していないかを確認する。デバイスに障害が発生していないかの問い合わせは、マネージャー３０４が、デバイスインタフェース３０１を介してプリンタ部３１４における状態の問い合わせを行う。このときデバイスのステータスに重要度の高い障害が発生していた場合には、デバイスインタフェース３０１の応答結果から、マネージャー３０４は、可変情報としてｃｏｄｅとｍａｊｏｒｓｔａｔｕｓの値を識別された種類のコード値に設定する。また、固定情報として上に説明した自デバイスに係わる情報を設定し、それらの情報をＳＯＡＰファンクションモジュール３０７に渡す。このとき、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８が、上述の可変情報及び固定情報を、自らＳＯＡＰファンクションモジュール３０７から取得するようにしても良い。
【００２２】
組み込み診断システムが、設定情報を読み込んで監視を再開したときにイベントフラグが“１”であった場合には、設定変更のために監視停止に入る前に重要度の高い障害が発生していたことになる。マネージャー３０４は、設定変更後に障害のステータスが変化している可能性があるために、デバイスインタフェース３０１を介してプリンタ部３１４における状態の問い合わせ要求が行われる。この時デバイスインタフェース３０１は、問い合わせが発生したことに応じて各種状態をセンサにより検知し応答するようにしても良いし、事前に検知しておいた各種状態を応答するようにしても良い。
【００２３】
デバイスインタフェース３０１の応答結果から、マネージャー３０４は、可変情報としてｃｏｄｅとｍａｊｏｒｓｔａｔｕｓの値を識別された種類のコード値に設定する。また、固定情報として上に説明した自デバイスに係わる情報を設定し、それらの情報をＳＯＡＰファンクションモジュール３０７に渡す。このとき、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８が、上述の可変情報及び固定情報を、自らＳＯＡＰファンクションモジュール３０７から取得するようにしても良い。何れの種類のエラーも発生していなければ、可変情報としてエラーが何もないという情報（ｃｏｄｅとｍａｊｏｒｓｔａｔｕｓの値を０とする）を設定し、それらの情報をＳＯＡＰファンクションモジュール３０７に渡す。
【００２４】
ＳＯＡＰファンクションモジュール３０７は、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８に対して、マネージャー３０４から受けた固定情報及び可変情報をもとにした、スキーマの作成及び指定のサーバへの通信依頼を行う。依頼を受けたＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８では、対応するスキーマを読み込み、読み込まれたスキーマ及び渡された値に基づき、図６、図７に示されるような、スキーマに基づくマークアップ言語記述を作成する。
【００２５】
以上の処理により、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８は依頼された固定情報及び可変情報の対応するスキーマに基づきマークアップ言語記述の作成を行う。また、監視再開時にイベントフラグが読み取られ且つ何れの種類の障害発生も識別されないと、障害発生が無いことを示す識別子を埋め込んだスキーマ―に基づくマークアップ言語記述を作成する。
【００２６】
一方、ホスト側（図３中の外部システム３１０）では、ゲートウェイを介して、ＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８から通知されたマークアップ言語記述の解析に基づき、障害の遷移を管理する。特に、図６に示されるような、障害発生が無いことを示す識別子を解析により識別すると、障害発生しているとして管理されていた障害について、障害解消を識別することができる。
【００２７】
より具体的には、図６、７のマークアップ言語記述のデータを受信するとともに、常に個々のデバイス及び個々の種類のエラー状態を更新する。更新されたエラー状態は記憶部に保存される。そして、更新の際に以前に発生していた種類の障害に対応する識別子（ｃｏｄｅの値、及びｍａｊｏｒｓｔａｔｕｓの値）が、受信したマークアップ言語記述の中に含まれておらず確認できなければ、その種類のエラーが解消したとものと識別する。特に、図６のマークアップ言語記述のデータを受信した場合には、例えば、以前に保持されていたすべてのエラーは解消されたとし、ホスト側のデバイス情報を正常状態として更新する。これにより、障害発生が解消しないことに起因する、無駄なサービスマンの派遣などを防ぐことができる。
【００２８】
尚、上の説明では、ＳＯＡＰファンクションモジュール３０７がＨＴＴＰ／ＳＯＡＰクライアントモジュール３０８に各種情報の通知を行うよう説明した。しかし、ＨＴＴＰＳ／ＳＯＡＰクライアントモジュール３０８が、上述の可変情報及び固定情報を、自らＳＯＡＰファンクションモジュール３０７から取得するようにしても良い。
【００２９】
＜本実施の形態に係る印刷デバイス装置の動作＞
以上の構成において、図１に示したデバイス１００の動作について、図４を参照して説明する。なお、図４は、本実施の形態に係るデバイス１００の動作を示すフローチャートである。このフローチャートは、デバイス１００が通常の監視状態から、監視関する設定変更指示を拠点監視装置から受信し、監視を再開するまでの処理である。これは、図２に示すＲＯＭ２０４、ＲＡＭ２０５、記憶装置２０６のいずれかの記憶手段に記憶され、ＣＰＵ２０７により実行される。
【００３０】
まずステップＳ４０１において、組み込み監視システム３０９は、デバイスの監視を開始する。ステップＳ４０２において、ＣＰＵ２０７は、プリンタ部２１４のステータスに変化が生じたかどうかを検知する。検知方法としては、各種センサ値を検出する方式でも、レスポンスの未応答を認識する方式でも、プリンタにおけるステータスを識別できれば、どのような方法でもよい。プリンタ部２１４のステータスに変化が発生し、且つサービスコールエラー（例えば、ハードディスクエラーや課金カウンタエラーなどサービスマンによる修理を必要とするような種類のエラー）が発生している場合には、ステップＳ４０３へ進む。ステップＳ４０３では、後述の図６で示すパケットを用いて、そのサービスコールエラー情報を拠点監視装置１０１に通知する（Ｔ１）。この通知に対する拠点監視装置１０１からの返答（レスポンス）Ｔ２が、後述する図７に示すレスポンスパケットであり、ここでは、サービスコールエラー情報を正常に受け取ったことを意味する＜ｒｅｓｕｌｔ＞ＯＫ＜ｒｅｓｕｌｔ＞が返信されている。また、サービスコールエラーが復旧した場合には、後述の図６に示すパケットを用いて、正常復帰情報を拠点監視装置１０１へ通知する。
【００３１】
ステップＳ４０２において、デバイスにサービスコールエラーなどのステータス変化が発生していない場合、組み込み監視システム３０９は処理をステップＳ４０４へ進める。尚、例えばドアオープンなどの、サービスコールエラーで無いエラーに関しても、ステップＳ４０２でＹＥＳと判定しても良い。
【００３２】
ステップＳ４０４では、デバイス１００は、監視設定変更システム３１４により、拠点監視装置１０１より発行された監視設定変更要求を受信する（Ｔ３）。監視設定変更要求を受信しない場合には、ステップＳ４０１へ戻り、監視処理を繰り返す。監視設定変更要求を拠点監視装置から受信した場合には、拠点監視装置に対して、監視設定変更要求を受信したことを示す応答（レスポンス）Ｔ４を発行し、ステップＳ４０５へ進む。ステップＳ４０５において、監視設定変更要求を受信したときに、デバイス１００が監視中の状態であった場合には、ステップＳ４０６へ進む。ステップＳ４０６では、設定変更要求指示を処理する前に、現在の組み込み診断システム３０９が監視状態であることを、不揮発性記憶装置３０６の監視中フラグ用メモリ領域に“１”を書き込み、ステップＳ４０７へ進む。また、ステップＳ４０５において、監視設定変更要求を受信したときに、デバイス１００が監視中の状態でなかった場合には、ステップＳ４０９へ進む。
【００３３】
ステップＳ４０７では、デバイス１００に重要度の高いイベントが発生していないか確認を行う。重要度の高いイベントが発生していた場合には、そのイベントが解消されたか否かが重要な情報となる。このため、監視が一時的に中断され、再度監視が再開されたときには、その重要度の高いイベントがどうなったかを拠点監視装置に通知する必要がある。重要度の高いイベントがデバイス１００に発生していた場合には、ステップＳ４０８へ進む。ステップＳ４０８では、デバイス１００に重要度の高いイベントが発行していることを記録するために、不揮発性記憶装置３０６のイベントフラグ用メモリ領域に“１”を書き込み、ステップＳ４０９へ進む。
【００３４】
ステップＳ４０９では、拠点監視装置から指示された監視設定変更要求を元に、監視設定変更を行う。このときに、デバイス１００の監視を一時的に停止し、設定情報を再度読み込むことによって変更を行う。拠点監視装置１０１は、Ｔ３によって要求した設定変更要求指示の結果がどのようになったかをポーリングによって確認する。このときの確認はＴ５によってリクエストされ、設定変更ＷｅｂＳｅｒｖｉｃｅ３１１は、確認指示に対する応答（レスポンス）Ｔ６を発行する。ステップＳ４０９にて、設定変更処理が完了すると、ステップＳ４１０へ進み、デバイス１００は監視を開始する。このとき、組み込み診断システムは新しい監視設定を読み込む。ここでいう監視設定とは、不揮発性記憶装置３０６に保存されているイベントフラグ、監視中フラグ、拠点監視装置１０１のＵＲＬやポート、並びに拠点監視装置１０１との送信間隔を示すスケジュール情報などである。
【００３５】
続くステップＳ４１１では、不揮発性記憶装置３０６に保存されている監視中フラグを参照し、監視中フラグが”１”であれば、ステップＳ４１２へ進み、”０”であれば本処理を終了する。つまり、監視中フラグが“１”であることは、当該デバイスの監視設定の変更を受け付けたときには、監視処理がすでに動いており、デバイスが監視中であることを示している。本フラグがあることによって、監視処理は、新しい設定情報を読み込んで起動するときのデバイスの最新ステータスを送信する必要性を確認することができる。
【００３６】
ステップＳ４１２では、不揮発性記憶装置３０６に保存されているイベントフラグを参照し、イベントフラグが“１”であれば、ステップＳ４１４へ進み、“０”であればステップＳ４１３へ進む。ここで、イベントフラグが”１”であることは、当該デバイスの監視設定の変更を受け付けたときには、すでに重大な障害が発生したことを示している。このため、監視処理が停止していた間にデバイスになんらかの状態変化が発生していた場合には、遠隔監視を利用するユーザーが状態変化を把握する必要があると判断する。当該デバイスの監視設定の変更を受け付けたときに、重大な障害が発生していない場合には、イベントフラグが”０”となっている。ステップＳ４１３にて、監視処理が停止している間に、状態が変化していないかを確認する。ここで重大なイベントが発生していたい場合には、ステップＳ４１４へ進み、何も発生しておらず、通常の状態であった場合には、処理を終了する。
【００３７】
ステップＳ４１４では、当該デバイスの最新ステータスを確認し、拠点監視装置１０１へステータス変化通知を送信する（Ｔ７）。この通知に対する拠点監視装置１０１からの応答（レスポンス）Ｔ８は、後述する図７に示すレスポンスパケットであり、ここでは、状態変化通知を正常に受け取ったことを示している。監視処理は、状態変化通知を拠点監視装置へ送信し、監視設定変更時の一連の処理を終了する。この後、通常の監視処理へと切り替わる。
【００３８】
また、上記の説明では、デバイス装置であるプリンタ部２１４のエラーとしてサービスコールエラーに限定して説明したが、サービスコールエラーに限らず、紙ジャム等のエラー、或いはトナーロー等のワーニングなどのエラーであっても良い。
【００３９】
＜不揮発記憶領域に保管されるデータの一例＞
図５は、本実施例の形態にかかる不揮発領域に保管されるデータの一例を示す図である。保管されるデータには、デバイスを識別するための情報であるデバイス固定情報と、デバイス監視を行うための監視設定情報、そのほか、設定変更を受けたときに利用する設定変更時情報、現在のデバイスステータスを保管するためのＣｕｒｒｅｎｔＳｔａｔｕｓなどが保管される。
【００４０】
デバイス固定情報には、図４の通信Ｔ１やＴ７で利用するデバイスの識別情報として、ＭａｃアドレスやＩＰアドレス、ＳｅｒｉａｌＮｕｍｂｅｒなどの情報が保管される。
【００４１】
監視設定情報には、組み込み診断システム３０９がデバイス監視情報を送信するときの送信先ＵＲＬやポート番号が保管されている。また、直接デバイスが監視情報を管理サーバ１０５へ送るのか、拠点監視装置１０１を経由してデバイス監視情報を送信するかのモード設定情報などが保管される。
【００４２】
設定変更時情報には、監視設定変更要求を受信したときに、監視を行なっていたかを記述する監視中フラグや、継続監視の必要な重大な障害が発生しているかを記述するイベントフラグなどがある。また、前回の設定変更要求の処理タイプや、その処理結果が保管される。ＣｕｒｒｅｎｔＳｔａｔｕｓには、そのときのデバイスの異常ステータスを記録する。デバイスの状態が常にこの領域で保管され、状態変化を検知すると同時に、新しい状態へＴｉｍｅＳｔａｍｐとともに書き換える。そして、書き換わった最新の状態を拠点漢詩装置１０１へと送信を行う。
【００４３】
＜エラー通知用のパケットデータの一例＞
図６は、本実施の形態に係るエラー通知時（図４のＴ１，Ｔ７）に送信されるマークアップ言語のパケットデータの一例を示す図であり、スキーマに基づき記述されている。このパケットデータは、ＨＴＴＰ上のＳＯＡＰを用いたエラー通知の一例である。このパケット（ｐｏｓｔＳｔａｔｕｓＩｎｆｏと称される）は、デバイス１００から拠点監視装置１０１に送信される。
【００４４】
このデータはＸＭＬ形式で記述されている。無論ＸＭＬ形式に限定されるもので無い。例えばＨＴＭＬでも良い。ｐｏｓｔＳｔａｔｕｓＩｎｆｏパケットは、プリンタ部２１４にエラーが発生した際に、拠点監視装置１０１にエラー情報を通知するコマンドである。固定的な情報を示す図６のパケットの発信元或いはエラー発生元のデバイス装置を示すデバイス情報（＜ｄｅｖｉｃｅ＞タグ）や、可変的な情報を示すステータス情報リスト（＜ｓｔａｔｕｓ＞タグ）等の情報が記述されている。＜ｄｅｖｉｃｅ＞タグには、ＭＡＣアドレスを識別する＜ｍａｃ＞、ＩＰアドレスを識別する＜ｉｐ＞、シリアル番号＜ｓｅｒｉａｌＮｕｍｂｅｒ＞、製品名＜ｐｒｏｄｕｃｔＮａｍｅ＞、及び形式＜ｔｙｐｅ＞が記述される。また、ｐｏｓｔＳｔａｔｕｓＩｎｆｏには、デバイスを識別する＜ｄｅｖｉｃｅ＞と＜ｓｔａｔｕｓ＞のリスト、並びにカウンタ情報＜ｃｏｕｎｔｅｒＬｉｓｔ＞が含まれている。＜ｓｔａｔｕｓ＞には、エラーコード＜ｃｏｄｅ＞、大分類の＜ｍａｊｏｒｓｔａｔｕｓ＞、エラーを示す文字情報＜ｏｐｍｅｓｓａｇｅ＞、及びタイムスタンプ情報＜ｔｉｍｅＳｔａｍｐ＞が記述されている。＜ｃｏｕｎｔｅｒＬｉｓｔ＞には、サービスモード番号＜ｉｄ＞とサービスモード番号で指定されたカウンタ値＜ｖａｌｕｅ＞が記述されている。なお、上記図６の説明におけるクライアントとはプリンタなどのデバイスを指す。
【００４５】
＜正常復帰通知用のパケットデータの一例＞
図６は、本実施の形態に係るエラー正常復帰通知時（図４のＴ７）に送信されるパケットデータの一例を示す図であり、図６と同様にスキーマに基づき記述されている。このパケットデータは、エラーが解消された後、ＨＴＴＰ上のＳＯＡＰを用いてデバイス１００から拠点監視装置１０１に送信される正常復帰通知用のパケットデータ（ｐｏｓｔＳｔａｔｕｓＩｎｆｏと称される）の一例である。
【００４６】
図６に示したパケットデータとスキーマは同様であるが、＜ｓｔａｔｕｓ＞において、エラーコード＜ｃｏｄｅ＞並びに大分類の＜ｍａｊｏｒｓｔａｔｕｓ＞がそれぞれ０、エラーを示す文字情報＜ｏｐｍｅｓｓａｇｅ＞はＮＵＬＬが設定される。このように＜ｓｔａｔｕｓ＞を設定することにより、エラーが解消されたことを示すパケットとなっている。
【００４７】
また、先の図６で示した＜ｄｅｖｉｃｅ＞タグにおける、ＭＡＣアドレス、ＩＰアドレス、及びシリアル番号によって、デバイスを特定することができるため、どのデバイス装置がエラー解消したかを特定することができる。また、エラーが解消される旨を通知するスキーマとしてｐｏｓｔＳｔａｔｕｓＩｎｆｏを使用したが、その他のＳＯＡＰ関数を使用しても良い。
【００４８】
このように、図６と同様の、ｓｔａｔｕｓスキーマ（＜ｓｔａｕｔｓ＞）を用い、図６に示されるエラー正常復帰通知を行うことができるので、通知フォーマットを簡易化できる。結果、通知を受ける側の拠点監視装置１０１側の処理を効率化できる。例えば、エラー正常復帰通知を示すスキーマをｓｔａｔｕｓスキーマとは別途設けるにようにしても良い。しかし、より好適な形態として、本実施例では、拠点監視装置１０１側で、まずｓｔａｔｕｓスキーマ６０２を解析し、図６の６０２と同様の＜ｍａｊｏｒｓｔａｔｕｓ＞スキーマで記述される値が０であることを識別し、サービスコールエラーが解消したと判定する。これにより、拠点監視装置１０１側のスキーマ判定処理を軽減できる。
【００４９】
＜通知に対するレスポンスの一例＞ 図７は、本実施の形態に係るエラー通知（図６）又は正常復帰通知（図６）に対するレスポンスの一例を示す図であり、図６、７と同様にスキーマに基づき記述されている。本データも図６のパケットデータと同様にＸＭＬ形式で記述され、本実施の形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ｐｏｓｔＳｔａｔｕｓＩｎｆｏ応答パケットには、ｐｏｓｔＳｔａｔｕｓＩｎｆｏコマンド対する結果情報＜ｒｅｓｕｌｔ＞として、ＯＫやＮＧを記述し、返信する。
【００５０】
＜デバイスへの監視設定変更要求のパケットデータの一例＞
図８は、本実施の形態に係る漢詩設定変更要求時（図４のＴ３）に送信されるマークアップ言語のパケットデータの一例を示す図であり、スキーマに基づき記述されている。このパケットデータは、監視設定変更を指示するために拠点監視装置１０１からデバイス１００に送信されるパケットデータ（ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇと称される）の一例である。ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇパケットは、拠点監視装置１０１が、特定のデバイスに対して監視設定変更を発行するコマンドである。これには、特定のデバイス宛の指示であることを示す＜ｓｅｒｉａｌＮｕｍｂｅｒ＞や、デバイス監視情報の送信先である＜ｓｅｎｄＵＲＬ＞、特定の処理を指示する＜ｐｒｏｃｅｓｓＴｙｐｅ＞などの情報がある。また、この要求発行元を識別するためにアカウント情報やパスワード情報などが記述されても良い。
【００５１】
＜監視設定変更要求に対するレスポンスの一例＞
図９は、本実施の形態に係る監視設定変更要求（図８）に対するレスポンスの一例を示す図であり、図６、７と同様にスキーマに基づき記述されている。本データも図６のパケットデータと同様にＸＭＬ形式で記述され、本実施の形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。 ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇ応答パケットには、ｓｅｔＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇコマンド対する結果情報＜ｒｅｓｕｌｔ＞として、ＯＫやＮＧを記述し、返信する。
【００５２】
＜デバイスへの監視設定問い合わせのパケットデータの一例＞
図１０は、本実施の形態に係る監視設定問い合わせ（図４のＴ５）に送信されるマークアップ言語のパケットデータの一例を示す図であり、スキーマに基づき記述されている。このパケットデータは、監視設定の問い合わせを指示するために、拠点監視装置１０１からデバイス１００に送信されるパケットデータ（ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇと称される）の一例である。ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇパケットは、拠点監視装置１０１が特定のデバイスに対して監視設定の問い合わせを発行するコマンドである。 これには特定のデバイス宛の指示であることを示すデバイス識別子である＜ｓｅｒｉａｌＮｕｍｂｅｒ＞の情報がある。
【００５３】
＜監視設定変更要求に対するレスポンスの一例＞
図１１は、本実施の形態に係る監視設定問い合わせ（図４のＴ５）に対するレスポンスの一例を示す図であり、図６、７と同様にスキーマに基づき記述されている。本データも図６のパケットデータと同様にＸＭＬ形式で記述され、本実施の形態においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇ応答パケットには、ｃｈｅｃｋＭｏｎｉｔｏｒｉｎｇＣｏｎｆｉｇコマンド対する処理結果として＜ｒｅｓｕｌｔ＞にＯＫ／ＮＧを記述し、処理を実施した時刻を記述する＜ｔｉｍｅＳｔａｍｐ＞がある。また、問い合わせを実行したときの監視設定を出力する情報がある。ｊこれには、デバイスの識別子＜ｓｅｒｉａｌＮｕｍｂｅｒ＞やデバイス監視情報の送信先ＵＲＬ＜ｓｅｎｄＵｒｌ＞、前回処理を受け付けたときの処理の種類＜ｐｒｏｃｅｓｓＴｙｐｅ＞や、処理結果＜ｓｔａｔｅ＞がある。この＜ｓｔａｔｅ＞には、ＣＯＭＰＬＥＴＥＤのほかに、エラーなど処理がとまってしまった場合のステータスを記述する。
【００５４】
（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数のデバイスからデバイスの監視情報を監視サーバにて収集することによりデバイスを監視するデバイス監視システムにおいて、
監視対象のデバイスは、
デバイスの状態変化を検知（３０２）し、状態変化の検知時のデバイスステータスを送信することのできるデバイスステータス送信手段（３０８）と、
デバイスステータス送信手段の送信先や、その他の監視に必要な監視設定情報を記憶する記憶手段（３０６）と、
デバイスの監視設定情報を変更することのできる監視設定情報変更手段（３１５）と、
デバイスの監視設定情報変更手段によって、変更した監視設定情報をプログラムに反映する際に、記憶手段に記載されたデバイスの状態に応じて、前記デバイスステータスを送信するべきか否かを判断する判断手段（３０５、Ｓ４１１、Ｓ４１２，Ｓ４１３）と、
判断手段の結果に応じて、デバイスステータスを送信する手段と、
を有することを特徴とする。
【請求項１】
ネットワークに接続された複数のデバイスからデバイスの監視情報を監視サーバにて収集することによりデバイスを監視するデバイス監視システムにおいて、
監視対象のデバイスは、
デバイスの状態変化を検知（３０２）し、状態変化の検知時のデバイスステータスを送信することのできるデバイスステータス送信手段（３０８）と、
デバイスステータス送信手段の送信先や、その他の監視に必要な監視設定情報を記憶する記憶手段（３０６）と、
デバイスの監視設定情報を変更することのできる監視設定情報変更手段（３１５）と、
デバイスの監視設定情報変更手段によって、変更した監視設定情報をプログラムに反映する際に、記憶手段に記載されたデバイスの状態に応じて、前記デバイスステータスを送信するべきか否かを判断する判断手段（３０５、Ｓ４１１、Ｓ４１２，Ｓ４１３）と、
判断手段の結果に応じて、デバイスステータスを送信する手段と、
を有することを特徴とする。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−１５０５８７（Ｐ２０１１−１５０５８７Ａ）
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願番号】特願２０１０−１２１９４（Ｐ２０１０−１２１９４）
【出願日】平成２２年１月２２日（２０１０．１．２２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願日】平成２２年１月２２日（２０１０．１．２２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]