(57)【要約】【課題】プラットフォームのソフトウェア構成の変更を抑制し、ユーザの操作性を低下させることなく状態通報の漏れをなくすことができる画像形成装置等を提供すること。【解決手段】機器の状態を知らせる情報を外部に送信する画像形成装置１００であって、機器の状態を検出する機器状態検出手段７１と、機器の状態に応じて状態通報情報を生成する状態通報生成手段７２と、状態通報情報を外部に送信する通信手段６１，６２と、前記通信手段の起動完了よりも早いタイミングで起動が完了し、前記通信手段の状態を管理する状態管理手段７７と、前記状態管理手段の起動が完了してから前記通信手段が起動完了するまでの間、前記通信手段が一時停止状態であると推定し、前記状態通報情報を一時的に記憶する一次記憶手段７４と、を有することを特徴とする。【選択図】図１
2011250176.tif 000002
【特許請求の範囲】
【請求項１】
機器の状態を知らせる情報を外部に送信する画像形成装置であって、
機器の状態を検出する機器状態検出手段と、
機器の状態に応じて状態通報情報を生成する状態通報生成手段と、
前記状態通報情報を外部に送信する通信手段と、
前記通信手段の起動完了よりも早いタイミングで起動が完了し、前記通信手段の状態を管理する状態管理手段と、
前記状態管理手段の起動が完了してから前記通信手段が起動完了するまでの間、前記通信手段が一時停止状態であると推定し、前記状態通報情報を一時的に記憶する一次記憶手段と、
を有することを特徴とする画像形成装置。
【請求項２】
前記状態管理手段が前記通信手段から有効状態であることを示す有効通知を取得した場合、一時的に記憶した前記状態通報情報を、前記通信手段に送信するよう要求する制御手段と、
前記状態管理手段が起動完了してから所定時間内に前記有効通知を取得しない場合、前記通信手段を介することなく、外部に前記状態通報情報を送信する簡易通報手段と、
ことを特徴とする請求項１記載の画像形成装置。
【請求項３】
前記状態管理手段は前記通信手段に状態を問い合わせることなく、前記通信手段が前記状態管理手段に該通信手段の状態を通知する、
ことを特徴とする請求項１又は２記載の画像形成装置。
【請求項４】
前記通信手段は、有効状態、無効状態又は一時停止状態の３つの状態を有し、
前記制御手段は、前記状態管理手段が管理する前記通信手段の３つの状態に基づき、有効状態の場合は、前記状態通報情報を前記通信手段に送信するよう要求し、無効状態の場合は破棄し、一時停止状態の場合は前記一次記憶手段に前記状態通報情報を一時的に記憶するよう要求する、
ことを特徴とする請求項２記載の画像形成装置。
【請求項５】
複数の前記通信手段がインストールされている場合、
前記状態管理手段が管理する各通信手段の状態に基づき、前記状態通報情報の送信を要求する前記通信手段を切り替える切換手段を有する、
ことを特徴とする請求項１〜４いずれか１項記載の画像形成装置。
【請求項６】
二つの前記通信手段のうちの１つは、ＬＡＮ内の仲介機器を介して外部に前記状態通報情報を送信し、他の１つは、前記仲介機器を介することなく外部に前記状態通報情報を送信する、
ことを特徴とする請求項５記載の画像形成装置。
【請求項７】
前記制御手段は、前記通信手段の識別情報を取得することなく、状態の情報のみを前記状態管理手段から取得する、
ことを特徴とする請求項５又は６記載の画像形成装置。
【請求項８】
前記簡易通報手段が前記通信手段を介することなく外部に送信する前記状態通報情報は、前記通信手段が送信する前記状態通報情報よりも情報量が少ない簡易的な前記状態通報情報である、
ことを特徴とする請求項２記載の画像形成装置。
【請求項９】
通信手段を用いて画像形成装置が機器の状態を知らせる情報を外部に送信する情報送信方法であって、
機器状態検出手段が、機器の状態を検出するステップと、
状態通報生成手段が、機器の状態に応じて状態通報情報を生成するステップと、
状態管理手段が、前記通信手段の起動完了よりも早いタイミングで起動を完了させ、前記通信手段の状態を管理するステップと、
一次記憶手段が、前記状態管理手段の起動が完了してから前記通信手段が起動完了するまでの間、前記通信手段が一時停止状態であると推定し、前記状態通報情報を一時的に記憶するステップと、
を有することを特徴とする情報送信方法。
【請求項１０】
機器の状態を知らせる情報を外部に送信する画像形成装置のＣＰＵを、
外部に情報を送信する通信手段に通信を要求する手段と、
機器の状態を検出する機器状態検出手段と、
機器の状態に応じて状態通報情報を生成する状態通報生成手段と、
前記通信手段の起動完了よりも早いタイミングで起動が完了し、前記通信手段の状態を管理する状態管理手段と、
前記状態管理手段の起動が完了してから前記通信手段が起動完了するまでの間、前記通信手段が一時停止状態であると推定し、前記状態通報情報を一時的に記憶する一次記憶手段と、
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部に機器の状態を知らせる情報を送信する画像形成装置等に関し、特に、通信のソフトウェアをオプションパッケージとして扱う画像形成装置、情報送信方法及びプログラムに関する。
【背景技術】
【０００２】
ＭＦＰ（Multifunction Peripheral）をサービスセンタと接続し、サービスセンタがＭＦＰの状態を検知することでＭＦＰの状態を管理するＭＦＰ管理システムが知られている。ＭＦＰは、紙切れやトナー切れなどの状態をサービスセンタに送信し、また、サービスセンタからもＭＦＰに状態を問い合わせることができるので、迅速かつ適切なサービスが可能となる（例えば、特許文献１参照。）。
【０００３】
特許文献１には、遠隔通報データを各画像形成装置別に蓄積する蓄積手段と、蓄積された遠隔通報データを解析する解析手段と、該手段による解析結果に基づいて遠隔通報データ受信手段によって受信された遠隔通報データを送信した画像形成装置の異常内容を判断する異常内容判断手段と、該手段によって判断された異常内容に対応する処置を行なう異常処置手段と、該手段によって行なわれた処置方法を蓄積する処置方法蓄積手段と、上記解析結果に基づいて各画像形成装置毎の特性を照合して段階的に故障の予知を行なう故障予知手段と、該手段より得られた予知のレベルに対応する遠隔通報データあるいは上記処置方法の履歴レポートを作成する履歴レポート作成手段と、を有するサービスセンタが開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のＭＦＰ管理システムでは、ＭＦＰの状態を通知する状態通報にいくつかの制約が生じていた。
【０００５】
例えば、状態通報をサービスセンタに送信するソフトウェア（以下、通報クライアントという）はオプションパッケージとして扱われるが、通報クライアントと印刷等を制御するプラットフォームを実現するソフトウェアは別々に起動される。このため、プラットフォームが起動した後は状態を通知する状況が生じうるが、通報クライアントが起動完了していないと、通報漏れが発生するという問題がある。これを防ぐため、通報クライアントの起動が完了するまでプラットフォームの起動が完了しないように設計すると、印刷が可能になるまでの起動時間が長くなってしまい、ユーザの利便性を阻害する。
【０００６】
ここで、プラットフォームが通報クライアントの状態を管理することで、先にプラットフォームが起動しても、通報クライアントの起動が完了するまで、状態通報をキャッシュすることが可能になる。
【０００７】
しかし、オプションパッケージとして提供されるのは通報クライアントだけではないという事情がある。通報クライアントは、オプションパッケージとして提供される他のソフトウェアと異なり、ほぼ唯一、有効状態／無効状態／一時停止状態の３つの状態を取るという特殊性がある。例えば、通報クライアントが無効状態又は一時停止状態の場合、プラットフォームが状態通報を要求しても、通報クライアントは状態通報をサービスセンタに送信しない。
【０００８】
このため、プラットフォームが通報クライアントの状態を管理して、有効状態であることが確認できた場合に、通報クライアントに状態通報を要求することになる。上記のように３つの状態を取るのは通報クライアントだけなので、通報クライアントの状態を確認する処理は、通報クライアントに対してのみ必要になる。しかし、オプションパッケージとして提供される複数のソフトウェアに共通の処理を施すプラットフォームに、通報クライアントに固有の処理を追加することは好ましくない。
【０００９】
また、プラットフォームから通報クライアントに状態を問い合わせるためには、言語仕様の問題を解決する必要がある。プラットフォームや通報クライアントの記述にプログラミング言語としてＪａｖａ（登録商標）言語を用いた場合、コンパイルが必要であるが、プラットフォームのコンパイル時に、コンパイル時に存在しない通報クライアントのライブラリへの参照が発生する。このため、プラットフォームのコンパイルが失敗してしまう。プラットフォームのコンパイル時に通報クライアントのライブラリを用意することも不可能ではないが、開発環境の再構築が必要になり容易ではない。このように、プラットフォームから通報クライアントへ状態を問い合わせる仕組みは、ソフトウェアの実装やプログラミング言語の制約上難しい。
【００１０】
本発明は、上記課題に鑑み、プラットフォームのソフトウェア構成の変更を抑制し、ユーザの操作性を低下させることなく状態通報の漏れをなくすことができる画像形成装置、情報送信方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題に鑑み、本発明は、機器の状態を知らせる情報を外部に送信する画像形成装置であって、機器の状態を検出する機器状態検出手段と、機器の状態に応じて状態通報情報を生成する状態通報生成手段と、前記状態通報情報を外部に送信する通信手段と、前記通信手段の起動完了よりも早いタイミングで起動が完了し、前記通信手段の状態を管理する状態管理手段と、前記状態管理手段の起動が完了してから前記通信手段が起動完了するまでの間、前記通信手段が一時停止状態であると推定し、前記状態通報情報を一時的に記憶する一次記憶手段と、を有することを特徴とする。
【発明の効果】
【００１２】
プラットフォームのソフトウェア構成の変更を抑制し、ユーザの操作性を低下させることなく状態通報の漏れをなくすことができる画像形成装置を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】ＭＦＰの特徴を説明するフローチャート図の一例である。
【図２】ＭＦＰ管理システムのシステム構成図の一例である。
【図３】ＭＦＰのハードウェア構成図の一例である。
【図４】サービスセンタのハードウェア構成図の一例を示す図である。
【図５】ＭＦＰの全体構成図の一例である。
【図６】オプションパッケージに含まれる通報クライアントを説明する図の一例である。
【図７】通報クライアントの３つの状態の状態遷移図の一例である。
【図８】各コンポーネントの機能ブロック図の一例である。
【図９】キャッシュ手段と破棄手段を使い分けを説明するフローチャート図の一例である。
【図１０】ＭＦＰ管理システムの動作手順を示すシーケンス図の一例である。
【図１１】ＭＦＰ管理システムの動作手順を示すシーケンス図の一例である。
【図１２】ＭＦＰ管理システムの動作手順を示すシーケンス図の一例である。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を参照しながら説明する。まず、本実施形態のＭＦＰ（Multifunction Peripheral）の特徴について説明する。
（１）プラットフォームは、通報クライアントからの状態の受信を通報の開始条件とし、通報クライアントの起動が完了するまで（有効状態になるまで）、必要な状態通報を内部でキャッシュする。これにより、状態通報を漏らさずにサービスセンタに送信することができる。
【００１５】
また、通報クライアントよりも先にプラットフォームを起動させるので、ＭＦＰは早期に印刷可能状態になり、ユーザから見た機器の起動時間を短縮することができる。
【００１６】
また、プラットフォームが通報クライアントから状態を受信することは、プラットフォームから通報クライアントのソフトウェア（オプションパッケージ）への依存を発生させないので、ソフトウェアの実装やプログラミング言語の制約を受けることがない。
（２）プラットフォームの起動後、一定時間内に通報クライアントが有効状態にならなかった場合、プラットフォームは状態通報が不可能であることを、通報クライアントを利用せずに簡易的にサービスセンタに通知する。
【００１７】
こうすることで、プラットフォームが受動的に通報クライアントから状態の通知を受ける状況が生じても、サービスセンタに通報できない状態が継続することを防止できる。
（３）通報クライアントにいくつかの種類がある場合に、プラットフォーム（ここでは後述の機器管理アクティビティ）は、通報クライアントの種類によらず状態のみを受信する。これにより、機器管理アクティビティは、通報クライアントの種類を区別せずに、複数の異なる種類の通報クライアントに共通のプログラムを利用して状態通報をサービスセンタに送信することができる。
【００１８】
図１は、本実施形態のＭＦＰの特徴を説明するフローチャート図の一例である。図1の手順は、ＭＦＰの主電源がオンになるとスタートする。
【００１９】
まず、プラットフォームが起動完了する（Ｓ１）。これにより、ＭＦＰは印刷可能になる。
【００２０】
次に、プラットフォームの起動完了よりも必ず後に、通報クライアントの起動が完了する。このため、プラットフォームは、通報クライアントの起動完了を意味する有効通知を取得したか否かを判定することができる（Ｓ２）。
【００２１】
有効通知を取得していない場合（Ｓ２のＮｏ）、次に、プラットフォームは起動完了から所定時間が経過したか否かを判定する（Ｓ３）。
【００２２】
起動完了から所定時間が経過していない場合（Ｓ３のＮｏ）、プラットフォームが状態通報すべき状態を検出するとプラットフォームは状態通報をキャッシュする（Ｓ４）。これにより、状態通報を漏らさずにサービスセンタに送信することができる。
【００２３】
有効通知を取得した場合（Ｓ２のＹｅｓ）、プラットフォームはキャッシュしていた状態通報をサービスセンタに送信する（Ｓ５）。なお、キャッシュせずに状態通報をサービスセンタに送信することもある。
【００２４】
また、有効通知を取得することなく（Ｓ２のＮｏ）、起動完了から所定時間が経過した場合（Ｓ３のＹｅｓ）、プラットフォームは簡易状態通報をサービスセンタに送信する（Ｓ６）。これにより、プラットフォームがサービスセンタに通報できない状態が継続することを防止できる。
【００２５】
図２は、ＭＦＰ管理システム５００のシステム構成図の一例を示す。２台のＭＦＰ（区別する場合、ＭＦＰ_Ａ、ＭＦＰ_Ｂという。）１００及び仲介機器２００がＬＡＮに接続されている。また、ＭＦＰ_Ａ及び仲介機器２００は、インターネットを介してサービスセンタ３００に接続されている。
【００２６】
この図に示すように、ＭＦＰ＿Ａは仲介機器２００を介さずにサービスセンタ３００に状態通報を送信することが可能であるが、ＭＦＰ＿Ｂは仲介機器２００を介してサービスセンタ３００に状態通報を送信する。この違いは、ＭＦＰ１００のサイズ、価格又は設置場所などに起因するものであり、本実施形態のＭＦＰ管理システム５００の特徴に直接の影響は与えない。
【００２７】
しかし、サービスセンタ３００にインターネットを介して接続するＭＦＰ_Ａと、仲介機器２００に接続するＭＦＰ_Ｂとでは、実装する通報クライアントに違いが生じる。本実施例では、ＭＦＰ＿Ａが実装する通報クライアントを外部通報仲介通報クライアントと、ＭＦＰ＿Ｂが実装する通報クライアントをWebService通報クライアントと、称する。区別しない場合は、これまで通り通報クライアントと称する。
【００２８】
ところで、外部通報仲介通報クライアントとWebService通報クライアントはソフトウェアなので、両方を１つのＭＦＰ１００に実装することもできる。この場合、ＭＦＰ１００が、ＭＦＰ_ＡとＭＦＰ_Ｂのどちらの形態でインターネットに接続しても、ＭＦＰ１００がサービスセンタ３００に状態通報を送信できるので、ＭＦＰ１００の設置場所などの制約が少なくなる。１つのＭＦＰ１００に複数の通報クライアントを実装した場合の通報クライアントの切換については後述する。
【００２９】
なお、図２ではＭＦＰ＿Ａと仲介機器２００がＬＡＮとインターネットに別々に接続しているように図示したが、実際には、ＬＡＮを介してインターネットに接続する形態を採用することが多い。
【００３０】
図３は、ＭＦＰ１００のハードウェア構成図の一例を示す。ＭＦＰ１００は、コントローラ３０と、オペレーションパネル２５と、ファクシミリコントロールユニット（ＦＣＵ）２６と、撮像部２７及び印刷部２８が有する。
【００３１】
コントローラ３０は、ＣＰＵ１４と、ＡＳＩＣ１６と、ＮＢ（ノースブリッジ）１５と、ＳＢ（サウスブリッジ）１７と、ＭＥＭ−Ｐ（システムメモリ）１１と、ＭＥＭ−Ｃ（ローカルメモリ）１２と、ＨＤＤ（ハードディスクドライブ）１３と、メモリカードスロット２３と、ＮＩＣ（ネットワークインタフェースコントローラ）１８と、ＵＳＢデバイス１９と、ＩＥＥＥ１３９４デバイス２１と、セントロニクスデバイス２２とを有する。
【００３２】
ＣＰＵ１４は、種々の情報処理を実行するためのＩＣであり、アプリケーションプログラムやプラットフォーム、オプションパッケージをＵＮＩＸ（登録商標）等のＯＳによりプロセス単位で並列的に実行する。ＡＳＩＣ１６は、画像処理用のＩＣである。ＮＢ１５は、ＣＰＵ１４とＡＳＩＣ１６を接続するためのブリッジである。ＳＢ１７は、ＮＢ１５と周辺機器等を接続するためのブリッジである。ＡＳＩＣ１６とＮＢ１５は、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介して接続されている。
【００３３】
ＭＥＭ−Ｐ１１は、ＮＢ１５に接続されたメモリである。ＭＥＭ−Ｃ１２は、ＡＳＩＣ１６に接続されたメモリである。ＨＤＤ１３は、ＡＳＩＣ１６に接続されたストレージであり、画像データ蓄積・文書データ蓄積・プログラム蓄積・フォントデータ蓄積・フォームデータ蓄積等を行うために使用される。プログラムには、アプリケーションプログラム（図示略）、後述する各種のコンポーネントのコンポーネントプログラム３１及びオプションプログラム（オプションパッケージに対応する）３２等がある。
【００３４】
メモリカードスロット２３は、ＳＢ１７に接続され、メモリカード２４をセット（挿入）するために使用される。メモリカード２４は、ＵＳＢメモリ等のフラッシュメモリであり、コンポーネントプログラム３１及びオプションプログラム３２を配布するために使用される。また、コンポーネントプログラム３１及びオプションプログラム３２は所定のサーバからＭＦＰ１００にダウンロードして配布することもできる。
【００３５】
ＮＩＣ１８は、ネットワーク等を介してＭＡＣアドレス等を使用したデータ通信を行うためのコントローラである。ＵＳＢデバイス１９は、ＵＳＢ規格に準拠したシリアルポートを提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２１は、ＩＥＥＥ１３９４規格に準拠したシリアルポートを提供するためのデバイスである。セントロニクスデバイス２２は、セントロニクス仕様に準拠したパラレルポートを提供するためのデバイスである。ＮＩＣ１８と、ＵＳＢデバイス１９と、ＩＥＥＥ１３９４デバイス２１と、セントロニクスデバイス２２と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＮＢ１５とＳＢ１７に接続されている。
【００３６】
オペレーションパネル２５は、ユーザがＭＦＰ１００に入力を行うためのハードウェア（操作部）であると共に、ＭＦＰ１００がオペレータに可視情報を提供するためのハードウェア（表示部）である。オペレーションパネル２５は、ＡＳＩＣ１６に接続されている。ＦＣＵ２６と、撮像部２７と、印刷部２８は、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＡＳＩＣ１６に接続されている。
【００３７】
図４は、サービスセンタ３００のハードウェア構成図の一例を示す図である。サービスセンタ３００は、コンピュータを実体とするサーバである。サービスセンタ３００は、それぞれバスで相互に接続されているＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、記憶媒体装着部１０４、通信装置１０５、入力装置１０６、表示制御部１０７及び記憶装置１０８を有する。ＣＰＵ１０１は、ＯＳ、サーバアプリケーション、通報処理プログラム１１０を記憶装置１０８から読み出して、ＲＡＭ１０２を作業メモリにして実行する。
【００３８】
通報処理プログラム１１０は、ＭＦＰ１００から状態通報を受信した場合、状態通報の内容に応じて、ＣＥ（カスタマーエンジニア）を派遣したり、消耗品を発送するなどの処理を行う。ＲＡＭ１０２は必要なデータを一時保管する作業メモリ（主記憶メモリ）になり、ＲＯＭ１０３にはＢＩＯＳや初期設定されたデータ、プログラムが記憶されている。
【００３９】
記憶媒体装着部１０４はＵＳＢケーブル等のケーブルや、可搬型の記憶媒体１１１を装着するインタフェースである。
【００４０】
通信装置１０５は、ＬＡＮカードやイーサネット（登録商標）カードと呼ばれ、ＣＰＵ１０１からの指示によりＭＰＦ１００にパケットデータを送信し、ＭＦＰ１００から状態通報を受信する。入力装置１０６は、キーボード、マウスなど、ユーザの様々な操作指示を受け付けるユーザインターフェイスである。タッチパネルや音声入力装置を入力装置とすることもできる。表示制御部１０７は、通報処理プログラム１１０が指示する画面情報に基づき所定の解像度や色数等でディスプレイ１０９の描画を制御する。ディスプレイ１０９は、液晶や有機ＥＬなどのＦＰＤ（Ｆｌａｔ  Ｐａｎｅｌ  Ｄｉｓｐｌａｙ）である。
【００４１】
記憶装置１０８は、ＨＤＤやフラッシュメモリなどの不揮発メモリを実体とし、ＯＳ、サーバアプリケーション、及び、通報処理プログラム１１０を記憶している。
【００４２】
記憶媒体１１１は、例えば、ＳＤカードやＵＳＢメモリなど不揮発性のメモリである。サーバアプリケーションや通報処理プログラム１１０は、記憶媒体１１１に記録された状態又は不図示のサーバからダウンロードされる態様で配布される。
【００４３】
なお、仲介機器２００は、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）等のコンピュータを実体とする。仲介機器２００のハードウェア構成図はサービスセンタ３００と同様なので省略する。
【００４４】
図５は、ＭＦＰ１００の全体構成図の一例を示す。ＭＦＰ１００は、上層から、オペレーションパネル２５、アプリケーション４１及びエンジン４２を有する。また、アプリケーション４１はプラットフォーム４３とオプションパッケージ４４を有する。
【００４５】
アプリケーション４１について詳細は省略したが、コピー用のアプリケーション４１であるコピーアプリと、プリンタ用のアプリケーション４１であるプリンタアプリと、スキャナ用のアプリケーション４１であるスキャナアプリと、ファクシミリ用のアプリケーション４１であるファクシミリアプリと、ネットワークファイル用のアプリケーション４１であるネットワークファイルアプリ等がある。アプリケーション４１は、このように、ＭＦＰ１００の各機能に固有な情報処理を実行するためのソフトウェアである。
【００４６】
プラットフォーム４３は、各アプリケーション４１から共通に利用されるソフトウェアである。本実施形態のＭＦＰ１００は、「パイプ＆フィルタアーキテクチャ」を採用しており、ジョブの処理手段である「フィルタ」と、フィルタ間を接続する「パイプ」とを組み合わせ、ジョブを実行する。フィルタには、「入力フィルタ」、「加工フィルタ」、及び、「出力フィルタ」があり、これらは数あるソフトウェア部品の１つである。
【００４７】
このようなソフトウェア部品を本実施例では「コンポーネント」と称する。コンポーネントには、この他、プラグイン管理コンポーネント（以下、プラグイン管理ＣＭＰという）５１、アクティビティコンポーネント、及び、機器状態外部通報コンポーネント（以下、機器状態外部通報ＣＭＰという）５３等がある。
【００４８】
プラグイン管理ＣＭＰ５１は、ＭＦＰ１００へのコンポーネント及びオプションパッケージ４４のインストール／アンインストールを監視し、各コンポーネントと各オプションパッケージ４４の状態を管理する。
【００４９】
アクティビティコンポーネントは、上記各フィルタコンポーネントとパイプとの連携を制御するコンポーネントである。アクティビティコンポーネントは、ジョブや内部的な処理に必要なコンポーネントを組み合わせて、ＭＦＰ１００の機能を提供する。このアクティビティコンポーネントの１つに機器管理アクティビティコンポーネント（以下、機器管理アクティビティという。）５２があり、機器管理アクティビティ５２は各コンポーネントを利用して、ＭＦＰ１００からサービスセンタ３００に状態通報する。
【００５０】
機器状態外部通報ＣＭＰ５３は、オプションパッケージ４４の通報クライアントに状態通報を要求する。機器状態外部通報ＣＭＰ５３は、インストールされているオプションパッケージ４４の種類、オプションパッケージ４４に含まれる通報クライアントの状態を管理している。また、複数の通報クライアントがインストールされている場合、通報クライアントを使い分ける。
【００５１】
プラットフォーム内のコンポーネントが標準的に全てのＭＦＰ１００にインストールされているのに対し、オプションパッケージ４４はＭＦＰ毎に選択的にインストールされる。選択的とすることで、状態通報をサービスセンタ３００に送信する機器管理を望まないユーザにコスト負担を強いることを防止できる。有料か無償かは技術的要請ではなく販売形態に過ぎないため、オプションパッケージ４４は無償で全て又は一部のＭＦＰ１００にインストールされてもよい。
【００５２】
オプションパッケージ４４がインストールされた場合、プラグイン管理ＣＭＰ５１は、インストールされたオプションパッケージ４４の識別情報を記憶し、以後、オプションパッケージ４４の情報を管理する。オプションパッケージ４４の情報とは、取り付け（インストール）、取り外し（アンインストール）、有効、無効等である。ここでオプションパッケージ４４の「有効」は、利用可能であることを（通報クライアントを含むオプションパッケージ４４の場合は、状態通報の送信が可能であることを）意味し、「無効」は利用できないことを（通報クライアントを含むオプションパッケージ４４の場合は、状態通報の送信が禁止されていることを）意味する。「無効」状態を設けることで、ユーザが利用を希望した場合に、インストールすることなく、例えばＣＥやサービスセンタ３００が有効状態に切り替えるだけでオプションパッケージ４４を使用することが可能になる。
【００５３】
本実施形態のオプションパッケージ４４は、WebServiceパッケージ５４又は外部通報仲介パッケージ５５である。ＭＦＰ１００が仲介機器２００を介して通信する形態の場合は外部通報仲介パッケージ５５が、ＭＦＰ１００が仲介機器２００を介さず通信する形態の場合はWebServiceパッケージ５４が、ＭＦＰ１００にインストールされる。しかし、両方のオプションパッケージ４４がインストールされることも少なくない。インストールするオプションパッケージ４４の選別は、ユーザやＣＥが適宜行う。
【００５４】
また、エンジン４２としては、画像形成するプロッタエンジン（図３の印刷部２８に相当）、原稿を読み取るスキャナエンジン（図３の撮像部２７に相当）、及び、ＦＡＸエンジン（図３のＦＣＵ２６に相当）等がある。
【００５５】
図６は、オプションパッケージ４４に含まれる通報クライアントを説明する図の一例である。図示するように、WebServiceパッケージ５４はWebService通報クライアント６１を、外部通報仲介パッケージ５５は外部通報仲介通報クライアント６２を、それぞれ有する。外部通報仲介通報クライアント６２は、ＩＰネットワークを超えてサービスセンタ３００と通信するため、状態通報には必ずサービスセンタ３００のＩＰアドレスを添付し、また、ＩＰネットワークのプロトコルであるＴＣＰ／ＩＰのプロトコルスタックを備える。これに対し、WebService通報クライアント６１は、ＬＡＮ内で仲介機器２００と通信すればよいので状態通報にはサービスセンタ３００のＩＰアドレスを添付する必要はなく仲介機器２００のＩＰアドレスとＭＡＣアドレスを添付する。また、ＴＣＰ／ＩＰのプロトコルスタックを備える必要はない。このため、仲介機器２００には少なくともサービスセンタ３００のＩＰアドレスが登録されており、また、仲介機器２００はＴＣＰ／ＩＰのプロトコルスタックを有する。
【００５６】
これら通報クライアントは、オプションパッケージ４４の有効／無効とは独立に、「有効状態／無効状態／一時停止状態」の３つの状態を取ることができる。ただし、オプションパッケージ４４が無効状態の場合、通報クライアントも無効状態である。
【００５７】
図７は、通報クライアントの３つの状態の状態遷移図の一例である。オプションパッケージ４４が有効状態の場合、通報クライアントは、有効状態から無効状態又は一時停止状態に遷移することができ、無効状態から有効状態又は一時停止状態に遷移することができ、一時停止状態から無効状態又は有効状態に遷移することができる。
【００５８】
通報クライアントの３つの状態は、外的な操作により互いに遷移する。例えば、ユーザやＣＥがオペレーションパネル２５を操作して通報クライアントを有効状態から無効状態又は一時停止状態に、無効状態から有効状態又は一時停止状態に、一時停止状態から無効状態又は有効状態に、それぞれ切り替えることができる。または、サービスセンタ３００がＭＦＰ１００と通信して（例えば、一時的に通報クライアントを有効にして）、３つの状態を切り替えることができるとしてもよい。
【００５９】
また、本実施形態では、外的な操作に拘わらず、通報クライアントの起動開始から起動完了までを一時停止状態として扱う。通報クライアントの起動が完了すると、通報クライアントは外的な操作なく、一時停止状態から有効状態又は無効状態に遷移する。有効状態又は無効状態のどちらに遷移するかは、通報クライアントの停止直前（ＭＦＰ１００の停止直前）の状態に依存する。
【００６０】
通報クライアントの３つの状態の遷移は、このように、他のコンポーネントに依存することなく、オプションパッケージ４４内の処理として完結する。オプションパッケージ４４は、通報クライアント毎に、通報クライアントが３つの状態のうち現在いずれの状態かをフラグなどで管理している。
【００６１】
オプションパッケージ４４は、また、禁則情報を有する。禁則情報は、３つの状態の遷移の禁則を定める規則である。禁則情報により、例えば、有効状態から直接、無効状態に遷移することを禁止して、一時停止状態を経るように規定することができる。本実施形態では、２つ以上の通報クライアントがインストールされた場合の禁則情報が登録されている。
【００６２】
２つ以上の通報クライアントがインストールされた場合、機器状態外部通報ＣＭＰ５３が、どの通報クライアントを通信に使用すべきか決定する必要が生じてしまう。そこで、オプションパッケージ４４は、２つ以上の通報クライアントがインストールされた場合、いずれか１つの通報クライアントのみに有効状態を認める禁則情報を有する。他方の通報クライアントは無効状態となる。禁則情報は、ユーザやＣＥ又はサービスセンタ３００が設定することができる。
【００６３】
オプションパッケージ４４は、後述するように、各通報クライアントの状態を機器状態外部通報ＣＭＰ５３に通知する。これにより、プラットフォーム４３の各コンポーネントは、各通報クライアントの状態を共有することが可能になり、次のように動作することが可能になる。
通報クライアントが有効状態：機器管理アクティビティ５２は状態通報の送信を通報クライアントに要求する。
通報クライアントが無効状態：機器管理アクティビティ５２は状態通報を破棄する。
通報クライアントが一時停止状態：機器管理アクティビティ５２は状態通報をＨＤＤ１３等にキャッシュしておき、通報クライアントが有効状態になると、状態通報の送信を通報クライアントに要求する。
【００６４】
通報クライアントが一時停止状態の場合に、機器管理アクティビティ５２が状態通報をキャッシュすることにより、ＭＦＰ１００は状態通報を漏らさずにサービスセンタ３００に送信することができる。また、機器管理アクティビティ５２は通報クライアントに状態を問い合わせることがないので、ソフトウェアの実装やプログラミング言語の制約を受けることがない。
【００６５】
図８は、各コンポーネントの機能ブロック図の一例である。プラグイン管理ＣＭＰ５１は、状態検出手段７１と状態通報生成手段７２を有し、機器管理アクティビティ５２は状態保持制御手段７３、キャッシュ手段７４、破棄手段７５及び簡易通報手段７６を有し、機器状態外部通報ＣＭＰ５３は、状態管理手段７７と振り分け手段７９を有する。
【００６６】
まず、状態検出手段７１は、ＭＦＰ１００の各部位に備えられたセンサが検出する信号を監視して、ＭＦＰ１００の状態を検出する。この状態には、例えば、用紙切れ、トナー切れ、用紙ジャム、ＡＤＦ（Auto Document Feeder）のオープン、ドアのオープン等、種々の状態が含まれる。状態通報生成手段７２は、状態検出手段７１が検出した状態に基づき、サービスセンタ３００に通報すべきとして定められた状態を通報する状態通報を生成する。
【００６７】
状態通報は、例えば、状態を示すコード、日時情報、ＭＦＰ１００のシリアル番号、ユーザ名、ＭＦＰ１００の各部位の状態、トナー残量、用紙残量等が含まれる。状態通報生成手段７２は、状態通報の送信を機器管理アクティビティ５２に要求する。状態通報の一部は、通報クライアントがＭＦＰ１００の各コンポーネントに問い合わせて生成するが、本実施例では、状態通報生成手段７２が生成するとした。
【００６８】
機器管理アクティビティ５２の状態保持制御手段７３は、通報クライアントの状態を保持し、機器管理アクティビティ５２の動作を制御する。状態保持制御手段７３は、状態管理手段７７が管理する状態の通知を取得し単に状態を保持すればよい。状態保持制御手段７３は、通報クライアントの種類を意識しないので、有効状態の通報クライアントがあれば状態通報の送信を機器状態外部通報ＣＭＰ５３に要求する。
【００６９】
状態保持制御手段７３は、通報クライアントの状態に基づき、キャッシュ手段７４と破棄手段７５を使い分ける。また、状況によっては、状態保持制御手段７３は、簡易通報手段７６に簡易通報を要求する。
【００７０】
図９は、キャッシュ手段７４、破棄手段７５及び簡易通報状態７６を使い分けを説明するフローチャート図の一例である。図９の手順は、機器管理アクティビティ５２が状態通報を取得するとスタートする。
【００７１】
まず、状態保持制御手段７３は、機器状態外部通報ＣＭＰ５３から有効状態の通知を取得したか否かを判定する（Ｓ１０）。有効な通報クライアントがある場合、それは１つしかないので、有効な通報クライアントがある場合（Ｓ１０のＹｅｓ）、状態保持制御手段７３は状態通報を送信すると判定する（Ｓ２０）。
【００７２】
有効な通報クライアントがない場合（Ｓ１０のＮｏ）、一時停止状態の通報クライアントか無効状態の通報クライアントが存在する可能性があるので、状態保持制御手段７３は機器状態外部通報ＣＭＰ５３から一時停止状態の通知を取得したか否かを判定する（Ｓ３０）。この場合、複数の通報クライアントが一時停止状態の場合があるが、有効状態になるのは１つだけなので、複数あるか否かは考慮しなくてよい。
【００７３】
一時停止状態の通報クライアントがある場合（Ｓ３０のＹｅｓ）、通報クライアントが有効状態になったら通報クライアントに送信を要求できるので、状態保持制御手段７３はキャッシュ手段７４に状態通報のキャッシュを要求すると判定する（Ｓ４０）。よって、キャッシュ手段７４は、ＨＤＤ１３等に状態通報をキャシュする（記憶する）。
【００７４】
一時停止状態の通報クライアントがない場合（Ｓ３０のＮｏ）、状態保持制御手段７３は機器状態外部通報ＣＭＰ５３から無効状態の通知を取得したか否かを判定する（Ｓ５０）。
【００７５】
無効状態の通報クライアントがある場合（Ｓ５０のＹｅｓ）、その通報クライアントが仮に有効状態になっても状態通報を送信する必要はないので、状態保持制御手段７３は破棄手段７５に状態通報の破棄を要求すると判定する（Ｓ６０）。よって、破棄手段７５は、状態通報を破棄する（ＨＤＤ１３等から消去する）。
【００７６】
無効状態の通報クライアントがない場合（Ｓ３０のＮｏ）、機器状態外部通報ＣＭＰ５３からなんら通知がないことになるので、状態保持制御手段７３はプラットフォーム４３の起動完了から所定時間が経過したか否かを判定する（Ｓ７０）。所定時間が経過するまでは（Ｓ７０のＮｏ）、状態通報を破棄できないので、所定時間の経過までステップＳ１０、Ｓ３０、Ｓ５０の判定を繰り返す。なお、プラットフォーム４３の起動完了は、機器管理アクティビティ５２又は機器状態外部通報ＣＭＰ５３の少なくとも一方の記号が完了したことをいう。
【００７７】
所定時間が経過した場合（Ｓ７０のＹｅｓ）、状態保持制御手段７３は簡易通報手段７６に簡易状態通報を送信するよう要求する（Ｓ８０）。よって、簡易通報手段７６は、簡易状態通報を生成してサービスセンタ３００に送信する。
【００７８】
簡易状態通報は、状態通報と比べて情報量が少ない。通報クライアントは、プラグイン管理ＣＭＰ５１の状態通報生成手段７２が生成した状態通報に、ＭＦＰ１００の各コンポーネントに問い合わせた結果を含め各種の情報を追加できるが、通報クライアントが有効状態でないので、簡易状態通報は、最小限の情報のみを含む。例えば、状態通報が「状態を示すコード、日時情報、ＭＦＰ１００のシリアル番号、ユーザ名、各部位の状態、トナー残量、用紙残量」であれば、簡易状態通報は「状態を示すコード、日時情報、ＭＦＰ１００のシリアル番号、ユーザ名」だけである。
【００７９】
図８に戻り、機器状態外部通報ＣＭＰ５３の状態管理手段７７は、オプションパッケージ４４から通知される通報クライアントの状態を管理する。状態管理手段７７は、通報クライアント毎に、有効状態／無効状態／一時停止状態の区別を状態テーブル７８に登録しておく。必ずしも通報クライアント毎である必要はない。
【００８０】
なお、状態管理手段７７は、ＭＦＰ１００の主電源がオフされる直前の通報クライアントの状態が「有効状態」又は「一時停止状態」の場合、ＭＦＰ１００の主電源オン（例えば機器状態外部通報ＣＭＰ５３の起動が完了してから）から、通報クライアントから状態（こちらも有効状態か一時停止状態のどちらかである）を通知されるまでの間、状態テーブル７８に「一時停止状態」を登録する。そして、状態管理手段７７は、オプションからの有効状態／無効状態／一時停止状態の通知の有無に関係なく、起動直後から機器管理アクティビティ５２に一時停止状態を通知できる。こうすることで、通報クライアントから状態を通知されるまでの間の状態通報を、機器管理アクティビティ５２がキャッシュすることができる。
【００８１】
振り分け手段７９は、機器管理アクティビティ５２から状態通報を取得した際に、状態テーブル７８を参照して、状態通報を要求する通報クライアントを選択する。こうすることで、複数の通報クライアントがインストールされていても、有効な通報クライアントを選択して通報クライアント選択できる。
【００８２】
有効なWebService通報クライアント６１、又は、有効な外部通報仲介通報クライアント６２は、必要であればＭＦＰ１００の各コンポーネントに問い合わせて各種の情報を集め、ＮＩＣ１８を介して状態通報をサービスセンタ（又は、仲介機器２００を介して）３００に送信する。
【００８３】
図１０は、ＭＦＰ管理システム５００の動作手順を示すシーケンス図の一例である。以下のシーケンス図では、「有効状態の通知」を「有効通知」、「無効状態の通知」を「無効通知」、「一時停止状態の通知」を「一時停止通知」と記述した。また、図では通報クライアントが通報クライアントの状態を通知するが、実際にはオプションパッケージ４４が通知する。また、図１０では通報クライアントを「WebService通報クライアント」としたが、外部通報仲介通報クライアント６２でも手順は同じである。
【００８４】
まず、ユーザがＭＦＰ１００の主電源をオンにする（Ｓ１００）。主電源がオンになるとＣＰＵ１４は、コンポーネントプログラム３１及びオプションプログラム３２をＨＤＤから読み出す。まず、プラグイン管理ＣＭＰ５１が起動を完了し、プラットフォーム４３の全体が起動を完了する。これにより、ＭＦＰ１００は印刷可能状態となる。
【００８５】
プラグイン管理ＣＭＰ５１は起動完了を機器管理アクティビティ５２に通知する（Ｓ１１０）。プラグイン管理ＣＭＰ５１が起動完了すると、状態検出手段７１が状態を検出し、状態通報生成手段７２が状態通報を生成可能になる。図１０では、プラグイン管理ＣＭＰ５１の起動完了後、WebService通報クライアント６１が有効状態を通知する前に、状態通報生成手段７２が状態通報を機器管理アクティビティ５２に通知する（Ｓ１２０）。
【００８６】
機器状態外部通報ＣＭＰ５３は、起動後、早期に（例えば、プラグイン管理ＣＭＰ５１の起動直後）、機器管理アクティビティ５２に一次停止状態を通知する（Ｓ１３０）。これは、通報クライアントが「有効状態」又は「一時停止状態」になる可能性があることを知らせておくためである。
【００８７】
これにより、機器管理アクティビティ５２の状態保持制御手段７３はWebService通報クライアント６１が、一時停止状態であると推定することができる。
【００８８】
ステップＳ１２０で機器管理アクティビティ５２に状態通報が通知されると、状態保持制御手段７３は、WebService通報クライアント６１が一時停止状態であるため、キャッシュ手段７４に状態通報のキャッシュを要求する。これにより、キャッシュ手段７４は状態通報をキャッシュする（Ｓ１４０）。
【００８９】
次に、WebService通報クライアント６１が起動を完了し、状態を通知する（Ｓ１５０）。図１０では、ＭＦＰ１００が主電源をオフするまでの状態が有効状態であったため、WebService通報クライアント６１は有効状態を機器状態外部通報ＣＭＰ５３に通知する。
【００９０】
機器状態外部通報ＣＭＰ５３の状態管理手段７７は状態テーブル７８にWebService通報クライアント６１の状態を登録し、機器管理アクティビティ５２にWebService通報クライアント６１が有効状態であることを通知する（Ｓ１６０）。これにより、機器管理アクティビティ５２の状態保持制御手段７３は、WebService通報クライアント６１が一時停止状態と推定していた状態から有効状態に遷移したものと実際に検出できる。
【００９１】
よって、機器管理アクティビティ５２は、キャッシュしてある状態通報を送信するよう機器状態外部通報ＣＭＰ５３に要求する（Ｓ１７０）。
【００９２】
機器状態外部通報ＣＭＰ５３は、状態通報をWebService通報クライアント６１に送信するよう要求する（Ｓ１８０）。
【００９３】
WebService通報クライアント６１は、仲介機器２００に状態通報を送信する（Ｓ１９０）。仲介機器２００は、状態通報を受信し、通信などの処理を施して、サービスセンタ３００に送信する（Ｓ２００）。これにより、サービスセンタ３００は、ＭＦＰ１００の状態を検知して、遠隔操作したり、必要であればＣＥを派遣することなどが可能になる。
【００９４】
一方、例えば、ユーザやＣＥが通報クライアントをアップデートする場合、通報クライアントを一時停止状態にする（Ｓ２１０）。通報クライアントは一時停止状であることを機器状態外部通報ＣＭＰ５３に通知する（Ｓ２２０）。
【００９５】
機器状態外部通報ＣＭＰ５３の状態管理手段７７は状態テーブル７８にWebService通報クライアント６１が一時停止状態であることを登録し、機器管理アクティビティ５２に一時停止状態を通知する（Ｓ２３０）。これにより、機器管理アクティビティ５２の状態保持制御手段７３は、WebService通報クライアント６１が有効状態から一時停止状態に遷移したものと判定できる。
【００９６】
この後、状態通報生成手段７２が状態通報を機器管理アクティビティ５２に通知した場合（Ｓ２４０）、キャッシュ手段７４は状態通報をキャッシュすることができる（Ｓ２５０）。なお、WebService通報クライアント６１は、一時停止状態に遷移した後、アップデートされる（Ｓ２６０）。
【００９７】
以上のように、状態通報をキャッシュすることで、ＭＦＰ１００は、起動時間を延ばすことなく、状態通報を漏らさずにサービスセンタ３００に送信することができる。また、機器管理アクティビティ５２が通報クライアントから状態を受信することで、ソフトウェアの実装やプログラミング言語の制約を受けることがない。
【００９８】
図１１は、ＭＦＰ管理システム５００の動作手順を示すシーケンス図の一例である。図１１のシーケンス図は、簡易状態通報の手順を説明するシーケンス図である。なお、図１１では通報クライアントを「外部通報仲介通報クライアント」としたが、WebService通報クライアント６１でも手順は同じである。
【００９９】
ステップＳ１４０までの処理は図１０とほぼ同様である。ユーザがＭＦＰ１００の主電源をオンにする（Ｓ１００）。主電源がオンになるとＣＰＵ１４は、コンポーネントプログラム３１及びオプションプログラム３２をＨＤＤから読み出す。まず、プラグイン管理ＣＭＰ５１が起動を完了し、プラットフォーム４３の全体が起動を完了する。これにより、ＭＦＰ１００は印刷可能状態となる。
【０１００】
プラグイン管理ＣＭＰ５１は起動完了を機器管理アクティビティ５２に通知する（Ｓ１１０）。機器状態外部通報ＣＭＰ５３は、起動後、早期に（例えば、プラグイン管理ＣＭＰ５１の起動直後）、機器管理アクティビティ５２に一次停止状態を通知する（Ｓ１３０）。このとき、状態保持制御手段７３は起動してから経過した時間のカウントを開始する。よって、時間のカウントが開始するのはプラットフォーム４３が起動完了した後になる。
【０１０１】
プラグイン管理ＣＭＰ５１が起動完了すると、状態検出手段７１が状態を検出し、状態通報生成手段７２が状態通報を生成可能になる。図１１では外部通報仲介通報クライアント６２は有効にならない。
【０１０２】
このため、状態通報生成手段７２が状態通報を機器管理アクティビティ５２に通知すると（Ｓ１２０）、状態保持制御手段７３は、キャッシュ手段７４に状態通報のキャッシュを要求する。これにより、キャッシュ手段７４は状態通報をキャッシュする（Ｓ１４０）。
【０１０３】
状態保持制御手段７３は、起動してから経過した時間のカウントを継続しており、所定時間の経過を検出する（Ｓ３１０）。
【０１０４】
このため、状態保持制御手段７３は簡易通報手段７６に簡易状態通報を送信するよう要求する。簡易通報手段７６は、簡易状態通報を生成してサービスセンタ３００に送信する（Ｓ３２０）。
【０１０５】
サービスセンタ３００は簡易状態通報を受信することができ、ＭＦＰ１００の状態を監視する最小限の情報を取得することができる。なお、サービスセンタ３００は、簡易状態通報と状態通報を両者に共通のヘッダ情報に含まれるフラグや情報量から判断することができる。よって、サービスセンタ３００は、簡易状態通報を受信した場合、これを「通報不可能の通報」とみなし、ＭＦＰ１００の通報クライアントの不具合を検出して、遠隔操作したりＣＥを派遣するなど適切な処理を実行できる。
【０１０６】
以上のように、機器管理アクティビティ５２が受動的に通報クライアントから状態の通知を受ける状況が生じても、一定時間内に通報クライアントが有効状態にならなかったことを検出することで、通報クライアントを利用しなくても簡易的にサービスセンタ３００に通知することができる。
【０１０７】
図１２は、ＭＦＰ管理システム５００の動作手順を示すシーケンス図の一例である。図１２のシーケンス図は、複数の通報クライアントがインストールされている場合の、通報クライアントの切り替えを説明するシーケンス図である。
【０１０８】
図１２では、通報クライアントとして、「外部通報仲介通報クライアント」と「WebService通報クライアント」がインストールされている。複数の「外部通報仲介通報クライアント」、又は、複数の「WebService通報クライアント」がインストールされることはないとしてよいが、仮にその状況が生じても禁則情報により有効状態になるのは１つの通報クライアントだけである。
【０１０９】
図１２では、外部通報仲介通報クライアント６２が起動完了した時点から説明する。ほぼ同時期にWebService通報クライアント６１も起動完了するか、オプションパッケージ４４は、禁則情報基づき、外部通報仲介通報クライアント６２が有効状態であることを機器状態外部通報ＣＭＰ５３に通知する（Ｓ４１０）。
【０１１０】
機器状態外部通報ＣＭＰ５３の状態管理手段７７は状態テーブル７８に外部通報仲介通報クライアントの状態を登録し、機器管理アクティビティ５２に有効状態を通知する（Ｓ４２０）。これにより、機器管理アクティビティ５２の状態保持制御手段７３は、外部通報仲介通報クライアントが一時停止状態から有効状態に遷移したものと判定できる。
【０１１１】
プラグイン管理ＣＭＰ５１が機器管理アクティビティ５２に状態通報を通知すると（Ｓ４３０）、機器管理アクティビティ５２は、状態通報を送信するよう機器状態外部通報ＣＭＰ５３に要求する（Ｓ４４０）。
【０１１２】
機器状態外部通報ＣＭＰ５３の振り分け手段７９は状態テーブル７８を参照し、外部通報仲介通報クライアント６２が有効状態であることを検出する。これにより、振り分け手段７９は、状態通報の送信を外部通報仲介通報クライアントに要求すればよいと判定し、状態通報の送信を外部通報仲介通報クライアント６２に要求する（Ｓ４５０）。
【０１１３】
外部通報仲介通報クライアント６２は、サービスセンタ３００に状態通報を送信する（Ｓ４６０）。これにより、サービスセンタ３００は、ＭＦＰ１００の状態を検知して、遠隔操作したり、必要であればＣＥを派遣することなどが可能になる。
【０１１４】
一方、外部通報仲介通報クライアント６２は、ユーザの判断などを理由に無効にされる場合がある。この場合、外部通報仲介通報クライアント６２は取り外される（アンインストールされる）場合が多い。
【０１１５】
ユーザやＣＥがオペレーションパネル２５を操作して、外部通報仲介通報クライアント６２を無効化すると、外部通報仲介通報クライアント（オプションパッケージ４４）６２が無効状態を機器状態外部通報ＣＭＰ５３に通知する（Ｓ４７０）。
【０１１６】
機器状態外部通報ＣＭＰ５３の状態管理手段７７は状態テーブル７８に外部通報仲介通報クライアントが無効状態であると登録し、機器管理アクティビティ５２に無効状態であることを通知する（Ｓ４８０）。これにより、機器管理アクティビティ５２の状態保持制御手段７３は、外部通報仲介通報クライアントが有効状態から無効状態に遷移したものと判定できる。この時点では、状態保持制御手段７３は、全ての通報クライアントが無効状態であると判定する。全ての通報クライアントが無効状態となることは禁則情報により禁止されていない。
【０１１７】
次に、ユーザやＣＥがオペレーションパネル２５を操作して、WebService通報クライアント６１を有効化する（Ｓ４９０）。WebServiceパッケージ５４は有効状態であることを機器状態外部通報ＣＭＰ５３に通知する（Ｓ５００）。
【０１１８】
機器状態外部通報ＣＭＰ５３の状態管理手段７７は状態テーブル７８にWebService通報クライアント６１の状態を登録し、機器管理アクティビティ５２に有効状態を通知する（Ｓ５１０）。これにより、機器管理アクティビティ５２の状態保持制御手段７３は、WebService通報クライアント６１が無効状態から有効状態に遷移したものと判定できる。
【０１１９】
プラグイン管理ＣＭＰ５１が機器管理アクティビティ５２に状態通報を通知すると（Ｓ５２０）、機器管理アクティビティ５２は、状態通報を送信するよう機器状態外部通報ＣＭＰ５３に要求する（Ｓ５３０）。
【０１２０】
機器状態外部通報ＣＭＰ５３の振り分け手段７９は状態テーブル７８を参照し、WebService通報クライアント６１が有効状態であることを検出する。これにより、振り分け手段７９は、状態通報の送信をWebService通報クライアント６１に要求すればよいと判定し、状態通報の送信をWebService通報クライアント６１に要求する（Ｓ５４０）。
【０１２１】
WebService通報クライアント６１は、仲介機器２００に状態通報を送信する（Ｓ５５０）。仲介機器２００は状態通報をサービスセンタ３００に送信する（Ｓ５６０）。サービスセンタ３００は、ＭＦＰ１００の状態を検知して、遠隔操作したり、必要であればＣＥを派遣することなどが可能になる。
【０１２２】
以上のように、通報クライアントにいくつかの種類がある場合でも、機器管理アクティビティ５２は、通報クライアントの種類によらず状態のみを受信することで、機器管理アクティビティ５２は、通報クライアントの種類を区別せずに状態通報をサービスセンタ３００に送信することができる。
【符号の説明】
【０１２３】
１３        ＨＤＤ
１４        ＣＰＵ
１５        ＮＢ
１６        ＡＳＩＣ
２５        オペレーションパネル
４１        アプリケーション
４３        プラットフォーム
４４        オプションパッケージ
５１        プラグイン管理コンポーネント
５２        機器管理アクティビティ
５３        機器状態外部通報コンポーネント
５４        WebServiceパッケージ
５５        外部通報仲介通報パッケージ
６１        WebService通報クライアント
６２        外部通報仲介通報クライアント
１００      ＭＦＰ（画像形成装置）
２００      仲介機器
３００      サービスセンタ
５００      ＭＦＰ管理システム
【先行技術文献】
【特許文献】
【０１２４】
【特許文献１】特開平１１−２０２６９９号公報
【図１】
2011250176.tif 000003
【図２】
2011250176.tif 000004
【図３】
2011250176.tif 000005
【図４】
2011250176.tif 000006
【図５】
2011250176.tif 000007
【図６】
2011250176.tif 000008
【図７】
2011250176.tif 000009
【図８】
2011250176.tif 000010
【図９】
2011250176.tif 000011
【図１０】
2011250176.tif 000012
【図１１】
2011250176.tif 000013
【図１２】
2011250176.tif 000014