JP2004348294A - 画像処理装置管理システム - Google Patents
画像処理装置管理システム Download PDFInfo
- Publication number
- JP2004348294A JP2004348294A JP2003142746A JP2003142746A JP2004348294A JP 2004348294 A JP2004348294 A JP 2004348294A JP 2003142746 A JP2003142746 A JP 2003142746A JP 2003142746 A JP2003142746 A JP 2003142746A JP 2004348294 A JP2004348294 A JP 2004348294A
- Authority
- JP
- Japan
- Prior art keywords
- image processing
- processing apparatus
- management
- maintenance
- information
- 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.)
- Granted
Links
Images
Abstract
【課題】画像処理装置管理システムにおけるメンテナンスのサービス性を向上させると共に、その効率化を図る。
【解決手段】画像処理装置１００と通信可能な管理装置１０２によってその画像処理装置を管理する画像処理装置管理システムにおいて、管理装置１０２が、画像処理装置１００のメンテナンス情報として画像処理装置１００のメンテナンス予定日時を記憶しておき、そのメンテナンス予定日時よりも所定期間前になったときにそのメンテナンス予定日時を画像処理装置１００に通知する（Ｓ１０１，Ｓ１０３）。そして、画像処理装置１００は、管理装置１０２からメンテナンス予定日時を受信する（Ｓ２０１，Ｓ２０５）と、そのメンテナンス予定日時を操作パネルに表示する（Ｓ２０３）。
【選択図】 図１１
【解決手段】画像処理装置１００と通信可能な管理装置１０２によってその画像処理装置を管理する画像処理装置管理システムにおいて、管理装置１０２が、画像処理装置１００のメンテナンス情報として画像処理装置１００のメンテナンス予定日時を記憶しておき、そのメンテナンス予定日時よりも所定期間前になったときにそのメンテナンス予定日時を画像処理装置１００に通知する（Ｓ１０１，Ｓ１０３）。そして、画像処理装置１００は、管理装置１０２からメンテナンス予定日時を受信する（Ｓ２０１，Ｓ２０５）と、そのメンテナンス予定日時を操作パネルに表示する（Ｓ２０３）。
【選択図】 図１１
Description
【０００１】
【発明の属する技術分野】
この発明は、ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機などの画像処理装置と通信可能な管理装置によって、これらの画像処理装置を管理する画像処理装置管理システムに関する。
【０００２】
【従来の技術】
近年、ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機などの画像処理装置に通信機能を設け、その画像処理装置を、サービス拠点に設置したコンピュータなどの管理装置が公衆回線やインタネットなどのネットワークを介して遠隔管理し、画像処理装置に異常が発生した時やメンテナンスが必要な時にその旨を自動的に管理装置に通報するようにして、迅速かつ的確な保守点検サービスを提供できるようにした画像処理装置管理システムが開発されている。
【０００３】
このような画像処理装置管理システムとしては、例えば特許文献１に見られるように、画像処理装置が故障を検出したときに、その故障検出データを管理装置に自動的に通知すると共に「自動通報中」等の文字メッセージを表示パネルに表示し、その通知に対する応答として、管理装置からサービスマン手配済み信号が受信したときに、「サービスマン手配中」または「サービスマン訪問」等の文字メッセージを表示し、さらに通知に失敗した場合にユーザに通報作業を依頼する「サービスセンターにＴＥＬしてください」等の文字メッセージを表示することにより、ユーザが自動通知の状況を的確に把握して必要な場合にのみ通報作業を行なうことができるようにした画像形成装置管理システムが提案されている。
【０００４】
また、例えば特許文献２に見られるように、画像処理装置が故障および消耗を検出したときに、その故障および消耗の状態と画像処理装置のメモリに登録された状態とを比較して、一致した場合に管理装置に通知するようにした画像処理装置管理システムも提案されている。
なお、この画像処理装置管理システムでは、管理装置は、画像処理装置から通知があった状態に対応する対処情報をデータベースから読み出して画像処理装置に送信するので、ユーザおよびオペレータの手間を低減することができる。
あるいは、データベースから読み出した対処情報を管理装置のオペレータに提示することもできる。この場合、オペレータが提示された対処情報を確認し、その対処情報がサービスマンの派遣であった場合に派遣予定日時を入力した後、管理装置に指示して、その対処情報を画像処理装置宛に送信することができる。
【０００５】
【特許文献１】
特開２００３−１５４７６号公報
【特許文献２】
特開２０００−２００１６９号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、このような従来の画像処理装置管理システムでは、管理装置が画像処理装置からの異常の通報に対して上述したような様々な情報を返信するという形でサービスを行なっているため、画像処理装置からの通報の有無に関係なく定期的に行なうメンテナンスなど不急な作業に関して作業日時等の詳しい情報を画像処理装置に送ることまでは行なっていなかった。
一般に、画像処理装置は複雑な機構を用いて画像処理を行うため、異常の発生を防いで性能を維持するためには定期的にメンテナンスを行なう必要があるが、このメンテナンスを行なう場合、サービスマンが画像処理装置の設置場所まで行き、そこで保守点検や消耗部品の交換等の作業を行う。そのため、ユーザはメンテナンス中に画像処理装置を使用することができない。
【０００７】
従って、従来の画像処理装置管理システムでは、ユーザはメンテナンスがいつ行なわれるか具体的な日時までは知ることができないため、メンテナンスのたびに画像処理装置の使用の予定が狂ってしまうという問題点があった。
つまり、従来の画像処理装置管理システムでは、メンテナンスに関するサービスがユーザにとって十分満足できるものではないという問題点があった。
さらに、サービス提供側では、画像処理装置のユーザの都合を予め知ることができないため、サービスマンを派遣したときにユーザの多忙や不在等の理由で作業ができない可能性があるという問題点もあった。
【０００８】
このような事態を避ける方法としては、管理装置のオペレータまたはサービスマンがユーザと連絡をとり、予め双方が都合の良い日時を調整してメンテナンスを行なうことが考えられる。しかし、管理している画像処理装置の全てに対してメンテナンスのたびに連絡作業を行なうのは非常に手間がかかり、効率が悪いという問題点があった。
この発明は上記の問題点に鑑みてなされたものであり、画像処理装置管理システムにおけるメンテナンスのサービス性を向上させると共に、その効率化を図ることを目的とする。
【０００９】
【課題を解決するための手段】
この発明は、上記の目的を達成するため、画像処理装置と通信可能な管理装置によって画像処理装置を管理する画像処理装置管理システムにおいて、管理装置に、画像処理装置のメンテナンスに関する情報であるメンテナンス情報として、画像処理装置のメンテナンス予定日時の情報を記憶する記憶手段と、その手段により記憶しているメンテナンス予定日時より所定期間前になったときにそのメンテナンス予定日時を画像処理装置に通知する通知手段とを設け、画像処理装置に、管理装置から通知されたメンテナンス予定日時を表示する表示手段を設けたものである。
【００１０】
また、上記画像処理装置に、所定の連絡先に対して管理装置から通知されたメンテナンス予定日時を報知する報知手段と、その報知に対する応答を受け付けて管理装置に送信する手段とを設けるようにするとよい。
このとき、上記管理装置に、画像処理装置から受信した応答の内容に従ってメンテナンス情報を更新する更新手段と、サービスマン用の携帯端末に上記メンテナンス情報を送信する送信手段とを設けるようにすると更によい。
【００１１】
【発明の実施の形態】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による管理システムの構成例について説明する。図１は、その管理システムの構成の一例を示す概念図である。なお、ここでは、通信機能を持ち、管理装置によって管理される電子装置（通信装置）を説明の便宜上「被管理装置」と云う。
【００１２】
この管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像形成装置あるいは画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等の電子装置に通信機能を持たせた通信装置を被管理装置１０とする遠隔管理システムである。そして、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）によって接続された遠隔管理仲介装置である仲介装置１０１、更に仲介装置１０１とインタネット１０３（公衆回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置１０２を備え、管理センタ等に配置される当該管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。
【００１３】
なお、仲介装置１０１と被管理装置１０との接続は、ＬＡＮに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）規格等に準拠したパラレル接続等によって行ってもよい。例えばＲＳ−４８５規格の場合には、仲介装置１０１に直列に５台までの被管理装置１０を接続することができる。
また、当該仲介装置１０１及び被管理装置１０は、その利用環境に応じて多様な階層構造を成す。
【００１４】
この点について、図１に示す設置環境Ａでは、管理装置１０２とＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）による直接的なコネクションを確立できる仲介装置１０１ａが、被管理装置１０ａ及び１０ｂを従える単純な階層構造になっている。しかし、設置する被管理装置１０の数が多く、１台の仲介装置１０１を設置しただけでは負荷が大きくなる場合には、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる上位の仲介装置が、被管理装置だけでなく、他の下位の仲介装置を従え、この仲介装置が他の被管理装置を更に従えるという階層構造を形成することもできる。この場合、下位の仲介装置に従えられる被管理装置を遠隔管理するために管理装置１０２から発せられた情報は、上位の仲介装置とその下位のノードとなる仲介装置とを経由して、それらの被管理装置に到達することになる。
【００１５】
また、設置環境Ｂにおいては、仲介装置１０１ｂと被管理装置１０ｃ，１０ｄのほか、ユーザが被管理装置１０ｃ，１０ｄに対して種々の操作を行うための端末装置１０５を設けている。このような端末装置１０５は、例えばパーソナルコンピュータ（ＰＣ）や携帯情報端末（ＰＤＡ）等に所要のプログラムを実行させることによって実現されるものであり、管理システムの構成においては必須ではない。しかし、このような端末装置１０５を設けることにより、ユーザは、被管理装置１０に設けた操作部だけでなく、端末装置１０５によっても被管理装置に種々の指示を行って動作させることができる。可能な動作は、当然被管理装置１０の種類によって異なるが、ここでいう動作には、画像形成，画像読み取り等の外見上の変化や動きを伴うもののみならず、情報の取得、設定の変更等、外見上は何も変化しないものも含むものとする。
【００１６】
また、設置環境Ｃのように、被管理装置１０に仲介装置１０１の機能を併せ持たせた仲介機能付被管理装置１１ａ，１１ｂを、別途仲介装置を介さずにインタネット１０３によって管理装置１０２に接続するようにしてもよい。
図示はしていないが、仲介機能付被管理装置１１の下位にさらに被管理装置１０を接続することもできる。
なお、各設置環境には、セキュリティ面を考慮し、ファイアウォール１０４を設置する。
【００１７】
なお、設置環境Ｂにおいては、相互のノードの接続関係が設置環境Ａ，Ｃと大きく異なるように図示しているが、これは、設置環境Ａ，ＣについてはＬＡＮ以外の接続方式も考慮して抽象的に各ノードの関係を示したのに対し、設置環境Ｂでは、ＬＡＮによって各ノードを接続した場合の構成を示したためである（ただし、被管理装置１０と端末装置１０５との接続をＬＡＮによるものに限定する意図ではない）。従って、設置環境Ａ，Ｃにおける各ノードをＬＡＮで接続すれば設置環境Ｂについて示したものに近い構成になるし、また、設置環境Ｂにおける被管理装置１０ｃ，１０ｄも、管理装置１０２との通信については、設置環境Ａの場合と同様仲介装置１０１ｂを介して行う。
【００１８】
このような遠隔管理システムにおいて、仲介装置１０１は、これに接続された被管理装置１０の制御管理のためのアプリケーションプログラムを実装している。
管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した被管理装置１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置１０も含め、この遠隔管理システムにおけるこれら各ノードは、ＲＰＣ（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
【００１９】
すなわち、仲介装置１０１又はこれと接続された被管理装置１０では、管理装置１０２への要求を生成してこれを管理装置１０２へ引き渡し、この要求に対する応答を取得できる一方で、管理装置１０２は、上記仲介装置１０１側への要求を生成してこれを仲介装置１０１側へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、仲介装置１０１に被管理装置１０に対して各種要求を送信させ、被管理装置１０からの応答を仲介装置１０１を介して取得することも含まれる。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ），ＨＴＴＰ，ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ），ＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ），ＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
【００２０】
この送受信のデータ送受モデルを図２の概念図に示す。なお、この図においては、ファイアウォール１０４の存在は考慮していない。
（Ａ）は、被管理装置１０で管理装置１０２に対する要求が発生したケースである。このケースでは、被管理装置１０が被管理装置側要求ａを生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこの要求に対する応答ａを返すというモデルになる。同図に示す仲介装置１０１は複数であるケースも想定できる。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、管理装置１０２が、仲介装置１０１を経由して被管理装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
【００２１】
（Ｂ）は、管理装置１０２で被管理装置１０に対する要求が発生したケースである。このケースでは、管理装置１０２が管理装置側要求ｂを生成し、これを仲介装置１０１を経由して受け取った被管理装置１０が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。
【００２２】
次に、図１に示す管理装置１０２の物理的構成について説明すると、当該管理装置１０２は、不図示のＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、ネットワークインタフェースカード（以下ＮＩＣという）等を備えている。
更に、図１に示す仲介装置１０１の物理的構成について説明すると、当該仲介装置１０１は、不図示のＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、ＮＩＣ等を備えている。
また、仲介機能付被管理装置１１については、仲介装置１０１の機能を実現するためにこれらのユニットを単に被管理装置１０に付加しても良いが、被管理装置１０に備えるＣＰＵ，ＲＯＭ，ＲＡＭ等のハードウェア資源を利用し、ＣＰＵに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置１０１の機能を実現することもできる。
【００２３】
以下、図１に示した管理装置のより具体的な例として、この発明による通信装置の一例である画像処理装置を被管理装置とした、この発明による遠隔管理システムの一例である画像処理装置遠隔管理システムについて説明する。図３は、その画像処理装置遠隔管理システムの構成の一例を示す概念図であるが、被管理装置１０を画像処理装置１００に、仲介機能付被管理装置１１を仲介機能付画像処理装置１１０に変更した点が図１と相違するのみであるので、システムの全体構成についての説明は省略する。
画像処理装置１００は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、仲介機能付画像処理装置１１０は、画像処理装置１００に仲介装置１０１の機能を併せ持たせたものである。
【００２４】
このような画像処理装置１００の物理的構成について図４を用いて説明する。
図４は、画像処理装置１００内の物理的構成の一例を示すブロック図である。同図に示すように、画像処理装置１００は、コントローラボード２００、ＨＤＤ（ハードディスクドライブ）２０１、ＮＶ−ＲＡＭ（不揮発性ＲＡＭ）２０２、ＰＩ（パーソナルインタフェース）ボード２０３、ＰＨＹ（物理メディアインタフェース）２０４、操作パネル２０５、プロッタ／スキャナエンジンボード２０６、電源ユニット２０７、フィニッシャ２０８、ＡＤＦ（自動原稿給送装置）２０９、給紙バンク２１０、その他周辺機２１１を備えている。これらのユニットは、それぞれがこの画像処理装置１００におけるハードウェア資源である。
【００２５】
ここで、コントローラボード２００は、制御手段に該当し、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備え、ＰＣＩ−ＢＵＳ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｔｅｒｃｏｎｎｅｃｔ−Ｂｕｓ）２１２を介して各機能を制御している。また、ＨＤＤ２０１は、記憶手段に該当する。また、ＮＶ−ＲＡＭ２０２は、記憶手段に該当し、不揮発性メモリであって、例えば、フラッシュメモリ等が該当する。これらの記憶手段には、この画像処理装置１００の制御に使用する各種プログラムや、動作ログ、画像データ、後述する画像処理枚数のカウント値、画像データ送信手段による画像データの送信先情報を始め、認証処理に用いる照合用のパスワードや設定パラメータ等を含む、各種のデータを記憶する。
【００２６】
また、ＰＩボード２０３とＰＨＹ２０４は、ネットワーク通信手段に該当し、外部との通信を行うためのものであって、例えば、通信ボード等が該当する。ＰＩボード２０３はＲＳ４８５規格に準拠したインタフェースを備え、ラインアダプタを介して公衆回線に接続している。なお、上述したように、このＰＩボード２０３を用いて画像処理装置１００と仲介装置１０１とを接続することも可能である。ＰＨＹ２０４は、ＬＡＮを介して外部装置と通信を行うためのインタフェースである。これらのＰＩボード２０３とＰＨＹ２０４は、画像データを外部装置に送信する画像データ送信手段としても機能させることができる。
【００２７】
プロッタ／スキャナエンジンボード２０６は、画像データに基づいて用紙に画像を形成する画像処理手段や、原稿の画像データを読み取る画像読取手段に該当する。さらに、この画像処理手段によって画像処理した用紙の枚数をカウントするカウント手段も備えている。
なお、同図中のＥＮＧＲＤＹは、エンジン側の各種初期設定が完了して、コントローラボード２００とコマンドの送受信の準備ができたことをコントローラボード２００側に通知するための信号線である。また、ＰＷＲＣＴＬは、エンジンへの電源供給をコントローラボード２００側から制御するための信号線である。
【００２８】
また、操作パネル２０５は、図５に示すように液晶タッチパネル３１と複数のハードキーを備えており、表示手段および操作を受け付ける手段として機能する。
液晶タッチパネル３１は、液晶ディスプレイの表面にタッチパネルを備えており、機能キーや部数、装置の状態を示すメッセージ等を表示するユニットである。
また、ハードキーとしては、プリント枚数や倍率等を入力するためのテンキー３２、プリント動作の中断やテンキー３２の入力結果のクリア等を指示するためのクリア／ストップ（Ｃ／Ｓ）キー３３、プリント動作の開始等を指示するためのスタートキー３４、管理者や使用者の使い勝手に合わせた装置の設定を行うための初期設定キー３６、液晶タッチパネル３１の表示言語を別の言語に切り替える言語切換キー３７、それぞれのアプリケーションを選択するためのコピーキー３８，ＦＡＸキー３９，プリンタキー４０，スキャナキー４１、実行中のプリント動作に割り込んで別のプリント動作等をさせるための割込キー４２、予熱状態の移行／解除等を指示するための予熱キー４３、設定されているプリントモードをデフォルト状態に戻すためのリセットキー（モードクリアキー）４４等が設けられている。
【００２９】
さらに、いくつかのハードキー上には、そのキーの選択状態を示すためのＬＥＤによる表示部４５が設けられている。特にスタートキー３４上には、画像処理装置１００がプリント動作可能である場合は緑色に点灯し、動作不可である場合は赤色に点灯するよう、赤・緑両方のＬＥＤによる表示部４６が付加されている。
なお、これらのハードキーのいくつかを省略し、液晶ディスプレイ３１にタッチキーとして表示するようにしてもよい。
【００３０】
次に、画像処理装置１００におけるソフトウェア構成を図６を用いて説明する。
図６は、画像処理装置１００のソフトウェア構成の一例を示すブロック図である。当該画像処理装置１００のソフトウェア構成は、最上位のアプリケーションモジュール（アプリ）層、その下位のサービスモジュール層からなる。そして、これらのソフトウェアを構成するプログラムはＨＤＤ２０１やコントローラボード２００上のＲＡＭに記憶され、必要に応じて読み出されてコントローラボード２００上のＣＰＵによって実行される。そしてＣＰＵは、これらのプログラムを必要に応じて実行することにより、この発明による各機能（報知手段，送信手段，その他の手段としての機能）を実現することができる。
【００３１】
特に、アプリケーションモジュール層のソフトウェアは、ＣＰＵをハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段として機能させるためのプログラムによって構成され、サービスモジュール層のソフトウェアは、ＣＰＵを、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段として機能させるためのプログラムによって構成される。
【００３２】
なお、それらの機能のうち、管理装置１０２との通信に係わる機能の実現方法は、画像処理装置１００と仲介機能付画像処理装置１１０とによって異なる。つまり、仲介機能付画像処理装置１１０の場合は、仲介装置の機能を備えているため、ＣＰＵが対応するプログラムを実行することにより、通信に係わる機能を実現することができる。画像処理装置１００の場合には、ＣＰＵが対応するプログラムを実行すると共に、仲介装置１０１を利用することにより、通信に係わる機能を実現することができる。
【００３３】
サービスモジュール層には、オペレーションコントロールサービス（ＯＣＳ）３００、エンジンコントロールサービス（ＥＣＳ）３０１、メモリコントロールサービス（ＭＣＳ）３０２、ネットワークコントロールサービス（ＮＣＳ）３０３、ファクスコントロールサービス（ＦＣＳ）３０４、ニューリモートサービス（ＮＲＳ）３０５、システムコントロールサービス（ＳＣＳ）３０６、システムリソースマネージャ（ＳＲＭ）３０７、イメージメモリハンドラ（ＩＭＨ）３０８、カスタマーサポートシステム（ＣＳＳ）３１５、デリバリーコントロールサービス（ＤＣＳ）３１６、ユーザコントロールサービス（ＵＣＳ）３１７を実装している。更に、アプリケーションモジュール層には、コピーアプリ３０９、ファクスアプリ３１０、プリンタアプリ３１１、スキャナアプリ３１２、ネットファイルアプリ３１３、ウェブアプリ３１４を実装している。
【００３４】
これらを更に詳述する。
ＯＣＳ３００は、操作パネル２０５を制御するモジュールである。
ＥＣＳ３０１は、ハードウェアリソース等のエンジンを制御するモジュールである。
ＭＣＳ３０２は、メモリ制御をするモジュールであり、例えば、画像メモリの取得及び開放、ＨＤＤ２０１の利用等を行う。
ＮＣＳ３０３は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
ＦＣＳ３０４は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。
【００３５】
ＮＲＳ３０５は、ネットワークを介してデータを送受信する際のデータの変換等をするモジュールであり、またネットワークを介した遠隔管理に関する機能をまとめたモジュールである。
ＳＣＳ３０６は、コマンドの内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理及び終了管理を行うモジュールである。
ＳＲＭ３０７は、システムの制御及びリソースの管理を行うモジュールである。
ＩＭＨ３０８は、一時的に画像データを入れておくメモリを管理するモジュールである。
【００３６】
ＣＳＳ３１５は、公衆回線を介してデータを送受信する際のデータの変換等をするモジュールであり、また公衆回線を介した遠隔管理に関する機能をまとめたモジュールである。
ＤＣＳ３１６は、ＨＤＤ２０１やコントローラボード２００上のメモリに記憶している（する）画像ファイル等をＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いて送受信するモジュールである。
ＵＣＳ３１７は、ユーザが登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
【００３７】
コピーアプリ３０９は、コピーサービスの機能を実現するためのアプリケーションプログラムである。
ファクスアプリ３１０は、ファクスサービスの機能を実現するためのアプリケーションプログラムである。
プリンタアプリ３１１は、プリンタサービスの機能を実現するためのアプリケーションプログラムである。
スキャナアプリ３１２は、スキャナサービスの機能を実現するためのアプリケーションプログラムである。
ネットファイルアプリ３１３は、ネットファイルサービスの機能を実現するためのアプリケーションプログラムである。
ウェブアプリ３１４は、ウェブページに関する入出力処理を行うためのアプリケーションプログラムである。
【００３８】
次に、上述した画像処理装置１００のソフトウェアの構成に含まれるＮＲＳ３０５の内部構成を図７を用いて更に説明する。
図７は、ＮＲＳモジュールの構成の一例を示す機能ブロック図である。同図に示すように、ＮＲＳ３０５は、ＳＣＳ３０６とＮＣＳ３０３との間で処理を行なっている。ウェブサーバ機能部５００は、外部から受信した要求に関する応答処理を行う。ここでの要求は、例えば、構造化言語であるＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記載された、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）によるＳＯＡＰリクエストであることが考えられる。ウェブクライアント機能部５０１は、外部への要求を発行する処理を行う。ｌｉｂｓｏａｐ５０２は、ＳＯＡＰを処理するライブラリであり、ｌｉｂｘｍｌ５０３は、ＸＭＬ形式で記載されたデータを処理するライブラリである。また、ｌｉｂｇｗｗｗ５０４は、ＨＴＴＰを処理するライブラリであり、ｌｉｂｇｗ＿ｎｃｓ５０５は、ＮＣＳ３０３との間の処理をするライブラリである。
【００３９】
続いて、図３に示した管理装置１０２について説明する。図８は、管理装置の概略構成例を示すブロック図である。
この管理装置１０２は、モデム６０１，通信端末６０２，プロキシ（Ｐｒｏｘｙ）サーバ６０３，操作者端末６０４，データベース６０５，制御装置６０６等からなる。
モデム６０１は、公衆回線を介して機器利用者側（例えば画像処理装置を利用しているユーザ先）の仲介装置１０１との通信を司るものであり、送受信するデータを変復調する。このモデム６０１と後述する通信端末６０２により通信手段としての機能を果たす。
通信端末６０２は、公衆回線を介してラインアダプタや仲介装置１０１とのデータの送受信を行う。
プロキシサーバ６０３は、インタネット１０３を介して機器利用者側の仲介装置１０１とのデータの送受信及びセキュリティ管理を行う。このプロキシサーバ６０３も、通信手段としての機能を果たす。
【００４０】
操作者端末６０４は、管理センタのオペレータが操作する端末であり、各種データの入力をオペレータによるキーボード等の入力装置上の操作により受け付けたり、オペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各機器利用者側の仲介装置１０１又は仲介機能付画像処理装置１１０が管理装置１０２へ通信する際に使用するＩＰアドレスや発呼先電話番号等の顧客情報がある。
データベース６０５は、図示しないサーバのハードディスク装置等の記憶装置に存在し、各機器利用者側の仲介装置１０１および仲介機能付画像処理装置１１０のＩＰアドレスや電話番号、それらの装置から受信したデータ、および操作者端末６０４から入力されたデータ等の各種データを記憶する。
【００４１】
制御装置６０６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、上記プログラムを必要に応じて実行すると共に、モデム６０１，通信端末６０２，プロキシサーバ６０３，操作者端末６０４またはデータベース６０５を利用することにより、この発明による各機能（記憶手段，通知手段，更新手段，送信手段，その他の手段としての機能）を実現することができる。
【００４２】
上述した構成を踏まえて、図３の画像処理装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例について図９を用いて説明する。なお、以下に示すＳＣＳ３０６，ＮＲＳ３０５およびウェブサービスアプリ３１８による処理は、実際にはＣＰＵがそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。以後も、プログラムが何らかの処理を行うものとして説明を行う場合には、同様とする。
【００４３】
図９は、管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
この例においては、まず、仲介装置１０１は、管理装置１０２に対してポーリング（送信要求があるかどうかの問い合わせ）を行う（Ｓ６０１）。つまり、自己の識別情報である識別子を付加したポーリング用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして管理装置１０２へ送信する。図３に示したように、仲介装置１０１と管理装置１０２との間にはファイアウォール１０４を設けているため、管理装置１０２から仲介装置１０１に向けて通信セッションを張る（通信を要求して通信経路を確立する）ことができないので、管理装置１０２から仲介装置１０１（あるいは仲介装置１０１を介して画像処理装置１００）に要求を送信したい場合でも、このように仲介装置１０１からのポーリングを待つ必要があるのである。
【００４４】
管理装置１０２は、仲介装置１０１から上記ＨＴＴＰメッセージを受信すると、課金カウンタ取得要求を示すＳＯＡＰドキュメントを生成し、該当する仲介装置１０１（受信したＳＯＡＰメッセージの送信元）へ、ポーリングに対する応答のＨＴＴＰメッセージとして送信する（Ｓ６０２）。このとき、受信したＨＴＴＰメッセージ内のＳＯＡＰドキュメントに付加された識別子に基づいて該当する仲介装置１０１を認識する。このように、ファイアウォール１０４の内側からの通信（ＨＴＴＰリクエスト）に対する応答（ＨＴＴＰレスポンス）であれば、ファイアウォールの外側から内側に対してデータを送信することができる。
【００４５】
仲介装置１０１は、管理装置１０２から上記ＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいて課金カウンタ取得要求を示すＳＯＡＰドキュメントを生成し、やはりＨＴＴＰメッセージとして自己に接続されている画像処理装置１００へ送信し、画像処理装置１００側ではウェブサービスアプリ３１８がこれを受け取る（Ｓ６０３）。
そして、ウェブサービスアプリ３１８が仲介装置１０１からＨＴＴＰメッセージとして受信したＳＯＡＰドキュメントに記述されている課金カウンタ取得要求をＮＲＳ３０５に渡し、ＮＲＳ３０５がそれをＳＣＳ３０６へ通知する（Ｓ６０４）。
ＳＣＳ３０６は、ＮＲＳ３０５から課金カウンタ取得要求の通知を受けると、ＮＶ−ＲＡＭ２０２に格納されている課金カウンタのデータを読み取る（Ｓ６０５）。そして、その読み取った課金カウンタのデータ（応答データ）をＮＲＳ３０５へ引き渡す（Ｓ６０６）。
【００４６】
ＮＲＳ３０５は、ＳＣＳ３０６から課金カウンタのデータを受け取る（取得する）と、これをウェブサービスアプリ３１８に渡す。そして、ウェブサービスアプリ３１８がその内容を示す課金カウンタ用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして仲介装置１０１へ送信する（Ｓ６０７）。
仲介装置１０１は、ウェブサービスアプリ３１８から課金カウンタ用のＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントをＨＴＴＰメッセージとして管理装置１０２へ送信する（Ｓ６０８）。
このように、上記通信シーケンスにより、データの送受信が行われる。
【００４７】
次に、上記図９と異なり、画像処理装置１００から仲介装置１０１を経て管理装置１０２へデータを送信する場合の通信シーケンスの一例について図１０を用いて説明する。
図１０は、画像処理装置から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、ＯＣＳ３００は、ユーザコールキーが押下された旨をＳＣＳ３０６へ通知する（Ｓ７０１）。
ＳＣＳ３０６は、ＯＣＳ３００からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をＮＲＳ３０５へ通知する（Ｓ７０２）。
【００４８】
ＮＲＳ３０５は、ＳＣＳ３０６からユーザコール要求の通知を受けると、これをウェブサービスアプリ３１８に渡す。そして、ウェブサービスアプリ３１８がユーザコールを知らせるユーザコール情報であるユーザコール用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして仲介装置１０１へ送信する（Ｓ７０３）。
仲介装置１０１は、ウェブサービスアプリ３１８からユーザコール用のＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントに自己の識別情報である識別子を付加し、そのＳＯＡＰドキュメントをやはりＨＴＴＰメッセージとして管理装置１０２に対して送信し、ユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のＳＯＡＰドキュメントを管理装置１０２へ通報する（Ｓ７０４）。この場合には、ファイアウォール１０４の内側から外側に向けての送信であるので、仲介装置１０１が自ら管理装置１０２に向けてセッションを張ってデータを送信することができる。
ここで、ステップＳ７０４の処理後のパターンを以下の（Ａ）から（Ｃ）に分けて説明する。
【００４９】
まず、（Ａ）において、管理装置１０２は、ユーザ先の仲介装置１０１からユーザコール用のＳＯＡＰドキュメントをＨＴＴＰメッセージとして受信し、その受信が正常に終了した場合には、その旨（ユーザコールが成功した旨）のコール結果を、正常に終了しなかった（異常に終了した）場合には、その旨（ユーザコールが失敗した旨）のコール結果を示すＳＯＡＰドキュメント生成し、ＨＴＴＰメッセージによる応答として通報元の仲介装置１０１へ送信する（Ｓ７０５）。
仲介装置１０１は、管理装置１０２からコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントを、やはりＨＴＴＰメッセージとしてユーザコールキーが押下された画像処理装置１００へ送信し、画像処理装置１００側ではウェブサービスアプリ３１８がこれを受け取る（Ｓ７０６）。
【００５０】
ウェブサービスアプリ３１８は、仲介装置１０１からコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントが示すコール結果をＮＲＳ３０５に渡す。そしてＮＲＳ３０５がそのコール結果を解釈（判定）し、ＳＣＳ３０６へ通知する（Ｓ７０７）。
ＳＣＳ３０６は、コール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７０８）。
【００５１】
次に（Ｂ）において、仲介装置１０１は、規定時間（予め設定された所定時間）が経っても管理装置１０２から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果を示すＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとしてウェブサービスアプリ３１８へ送信する（Ｓ７０９）。
ウェブサービスアプリ３１８は、失敗した旨のコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントに記述されている失敗した旨のコール結果をＮＲＳ３０５に渡す。そしてＮＲＳ３０５がそのコール結果を解釈し、ＳＣＳ３０６へ通知する（Ｓ７１０）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１１）。
【００５２】
次に（Ｃ）において、ＮＲＳ３０５は、規定時間が経っても仲介装置１０１から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をＳＣＳ３０６へ通知する（Ｓ７１２）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１３）。
【００５３】
なお、ここでは管理装置１０２からファイアウォール１０４を越えて仲介装置１０１（あるいは仲介装置１０１を介して画像処理装置１００）にデータを送信するために、仲介装置１０１からのＨＴＴＰリクエストに対するレスポンスという形で送信を行う例について説明したが、ファイアウォール１０４を越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用して、送信したいデータを記載あるいは添付したメールを管理装置１０２から仲介装置１０１に送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。
【００５４】
次に、このような基本的な機能を有する図３に示した画像処理装置管理システムにおける本発明の特徴に関連する動作、すなわち、管理装置１０２が画像処理装置１００にメンテナンス予定日時を通知し、画像処理装置１００がそのメンテナンス予定日時を表示すると共に、報知用の連絡先が設定されていた場合にそのメンテナンス予定日時を其処に報知する処理について説明する。
図１１は、この場合に画像処理装置１００および管理装置１０２のＣＰＵが各々行う処理のフローを、管理装置と画像処理装置との間で送受信されるデータと共に示した図である。これらの処理は、画像処理装置１００のＣＰＵおよび管理装置１０２のＣＰＵが、それぞれ所要のプログラムを実行することによって行うものである。
【００５５】
なお、図が煩雑になるのを防ぐため、図１１では本発明の特徴に係る部分のみを図示している。以下、後述する図１２乃至図１５についても同様である。
また、図１１において、２本のフローチャート間の矢印はデータの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。このデータの送信は、実際には図２あるいは図３に示したように仲介装置１０１等を介して行なわれるが、説明を簡単にするため、ここでは直接送信するかのように記載する。後述する図１３についても同様である。
【００５６】
この画像処理装置管理システムにおいて、管理装置１０２のデータベース６０５には、管理対象の画像処理装置１００毎に、メンテナンスに関する情報として、過去に行なったメンテナンスの作業日時や作業内容等のメンテナンス情報を記憶している。画像処理装置１００における異常発生履歴等もこの情報に含めるようにしてもよい。そして、これらの情報を基に画像処理装置１００毎に定期メンテナンスのスケジュールを決定し、設置先への訪問予定日としてメンテナンス予定日時も、メンテナンス情報の一部として記憶している。なお、メンテナンス予定日時は自動で定めることができるようにするとよいが、管理装置１０２のオペレータ等が定めて記憶させるようにしてもよい。
【００５７】
管理装置１０２のＣＰＵは、各画像処理装置１００についてこのようなメンテナンス予定日時の情報を参照し、いずれかの画像処理装置１００についてのメンテナンス予定日時よりも所定期間前になると、その画像処理装置を対象として図１１の左側のフローチャートに示す処理を開始する。ここで、所定期間は、何週間、何日、何時間のように、予め定めておくものとする。
そして、この処理を開始すると、まずステップＳ１０１でメンテナンス予定日時の情報を対象の画像処理装置１００に送信して、メンテナンス予定日時を通知する。
【００５８】
一方、対象となった画像処理装置１００は、管理装置１０２からメンテナンス予定日時の情報を受信すると図１１の右側のフローチャートに示す処理を開始する。そして、まずステップＳ２０１でその受信が成功したか否かを判断する。
ステップＳ２０１で成功の場合はステップＳ２０２へ進み、受信が成功した旨の応答を管理装置１０２に送信する。そして、次のステップＳ２０３へ進み、表示手段である操作パネル２０５に受信した情報に従ってメンテナンス予定日時を表示させる。そして、ステップＳ２０７で、画像処理装置１００にメンテナンス予定日時を報知すべき連絡先が設定されているか否かを判断し、設定されている場合はステップＳ２０８へ進んで、設定された連絡先に管理装置１０２から通知されたメンテナンス予定日時を報知して処理を終了する。
【００５９】
なお、この連絡先としては、例えば管理者として画像処理装置１００に登録されているユーザの電子メールアドレスなどが考えられ、報知の方法としては、例えば設定された連絡先の電子メールアドレスにメンテナンス予定日時の情報を添付した電子メールを送信する等が考えられる。
また、ステップＳ２０７で設定されていない場合は、報知を行なわずにそのまま処理を終了する。
一方、ステップＳ２０１で失敗の場合はステップＳ２０４へ進み、管理装置１０２への応答としてメンテナンス予定日時の再送要求を送信する。
【００６０】
管理装置１０２側では、ステップＳ１０１の次のステップＳ１０２で、ステップＳ１０１でメンテナンス予定日時の情報を通知してから一定時間内に、画像処理装置１００から再送要求があったか否かを判断する。
そして、ステップＳ１０２でなかった場合は、そのまま処理を終了する。ステップＳ１０２で再送要求があった場合はステップＳ１０３へ進み、メンテナンス予定日時の情報を画像処理装置１００へ再び通知してから処理を終了する。
【００６１】
画像処理装置１００側では、ステップＳ２０４の次のステップＳ２０５で、ステップＳ２０４で管理装置１００に再送要求を送信してから一定時間内にメンテナンス予定日時の情報の受信に成功したか否かを再び判断する。
ステップＳ２０５で成功の場合はステップＳ２０２へ進み、以下ステップＳ２０２以降で、前述したステップＳ２０１の判断でＹＥＳの場合と同様の処理を行う。すなわち、管理装置１０２に受信成功の応答を送信して、操作パネル２０５にメンテナンス予定日時を表示させて処理を終了する。
ステップＳ２０５で失敗の場合はステップＳ２０６に進み、エラー処理を行って処理を終了する。このエラー処理としては、例えば「メンテナンス予定日時の受信に失敗しました」等の文字メッセージを操作パネル２０５に表示するなどが考えられる。
【００６２】
なお、ステップＳ２０５で失敗の場合にステップＳ２０６のエラー処理を行なわずにステップＳ２０４に戻り、再びメンテナンス予定日時の情報の再送要求を管理装置１０２に送信するようにしてもよい。
また、管理装置１０２が一定期間内に成功応答を受信しなかった場合にも、メンテナンス日時の情報を再送するようにしてもよい。
以上の処理において、管理装置１０２のＣＰＵは、ステップＳ１０１およびＳ１０３で通知手段として機能する。また、画像処理装置１００のＣＰＵはステップＳ２０８で報知手段として機能する。
【００６３】
この画像処理装置管理システムにおいては、このような処理を行うことにより、決定したメンテナンス予定日時を事前に画像処理装置に通知して操作パネル２０５等に表示させることができるため、ユーザはその予告告知されたメンテナンス予定日時を考慮して画像処理装置の使用の予定を計画することができるようになり、サービスマンを派遣したときにユーザの多忙や不在等の理由で作業できない可能性が少なくなる。従って、メンテナンスのサービス性を向上させることができ、しかも効率よくサービスを行なうことができるようになる。
また、画像処理装置１００に設定されている連絡先にメンテナンス予定日時を報知することができるため、画像処理装置を管理しているユーザ等がメンテナンス予定日時の情報を見落としてしまう可能性を低くすることができる。
【００６４】
なお、ステップＳ２０３において、画像処理装置１００が受信したメンテナンス予定日時の情報を一旦ＨＤＤ２０１等に記憶しておき、所定の時間またはユーザの指示を受け付けたときに操作パネル２０５に表示するようにしてもよい。
また、受信したメンテナンス予定日時を、操作パネル２０５へ表示する代わりに用紙等に印刷するようにしてもよい。あるいは、メンテナンス予定日時の情報を、画像処理装置１００にＬＡＮ等で接続されている端末装置１０５（図３参照）に電子メール等を用いて転送（報知）するようにしてもよい。また、これらの複数の方法でユーザにメンテナンス予定日時を予告告知するようにしてもよい。
さらにまた、ステップＳ２０８の報知を行なう場合には、ステップＳ２０３の表示は行なわないようにしてもよい。
【００６５】
ところで、ステップＳ２０８の処理によるメンテナンス予定日時の報知を受けたユーザは、この報知に対して、そのメンテナンス予定日時の都合、メンテナンスの必要性、その他要望等を応答として管理装置１０２に対して送信することができる。そしてここでは、この送信は画像処理装置１００を介して行なう。すなわち、ユーザがこの応答を画像処理装置１００に送信すると、画像処理装置１００が自動的にこれを管理装置１０２に送信するようにしている。
次に、この場合の処理について説明する。図１２は、この場合に画像処理装置および管理装置のＣＰＵが各々行う処理のフローを送受信されるデータと共に示した図である。
この画像処理装置管理システムにおいて、画像処理装置１００のＣＰＵは、メンテナンス予定日時を報知した所定の連絡先から上記の応答を受け付けたときに図１２の右側のフローチャートに示す処理を開始する。
【００６６】
そして、画像処理装置１００は、処理を開始するとまずステップＳ２２１で、所定の連絡先から受け付けたメンテナンス日時の報知に対する応答の情報を管理装置１０２に送信する。
一方、管理装置１０２は、その応答の情報を受信すると図１２の左側のフローチャートに示す処理を開始し、まずステップＳ１２１でその受信が成功したか否かを判断する。
ステップＳ１２１で成功の場合はステップＳ１２２へ進み、受信が成功した旨の応答を画像処理装置１００に送信する。そして、次のステップＳ１２３で、受信した応答の情報をデータベース６０５に記憶しているメンテナンス情報に追加してメンテナンス情報の更新を行ない、処理を終了する。
ステップＳ１２１で失敗の場合はステップＳ１２４へ進み、画像処理装置１００に応答の情報の再送要求を送信する。
【００６７】
画像処理装置１００側では、ステップＳ２２１の次のステップＳ２２２で、ステップＳ２２１で応答の情報を送信してから一定時間内に、管理装置１０２から再送要求があったか否かを判断する。
そして、ステップＳ２２２で再送要求がなかった場合は、そのまま処理を終了する。ステップＳ２２２で再送要求があった場合はステップＳ２２３へ進み、所定の連絡先から受け付けたメンテナンス日時の報知に対する応答の情報を管理装置１０２へ再び通知してから処理を終了する。
【００６８】
管理装置１０２側では、ステップＳ１２４の次のステップＳ１２５で、ステップＳ１２４で画像処理装置１００に再送要求を送信してから一定時間内に応答の情報の受信に成功したか否かを再び判断する。
ステップＳ１２５で成功の場合はステップＳ１２２へ進み、以下ステップＳ１２２以降で、前述したステップＳ１２１の判断でＹＥＳの場合と同様の処理を行う。すなわち、画像処理装置１００に受信成功の応答を送信し、受信した応答の情報をメンテナンス情報に追加して更新して、処理を終了する。
【００６９】
ステップＳ１２５で失敗の場合はステップＳ１２６に進み、エラー処理を行って処理を終了する。このエラー処理としては、例えばメンテナンス日時の報知に対する応答の情報の受信に失敗した旨をオペレータに通知する等が考えられる。
なお、ステップＳ１２５で失敗の場合にステップＳ１２６のエラー処理を行なわずにステップＳ１２４に戻り、再び応答の情報の再送要求を画像処理装置１００に送信するようにしてもよい。
また、画像処理装置１００が一定期間内に成功応答を受信しなかった場合にも、応答の情報を再送するようにしてもよい。
【００７０】
以上の処理において、画像処理装置１００のＣＰＵは、ステップＳ２２１およびＳ２２３でメンテナンス予定日時の報知に対する応答の情報を管理装置１０２に送信する手段として機能する。
この画像処理装置管理システムにおいては、このような処理を行うことにより、画像処理装置に登録されているユーザの連絡先に報知したメンテナンス予定日時に対するユーザからの応答の情報を画像処理装置１００が受け付けて管理装置１０２に送信し、管理装置でその応答の情報をデータベース６０５のメンテナンス情報に追加して更新することができるので、メンテナンス予定日時におけるユーザの都合や要望事項等を事前にサービス提供側が知ることができる。さらに、その応答の情報に応じてサービスマンが行なうメンテナンスの作業内容やメンテナンス予定日時を変更することも可能である。従って、ユーザとサービス提供側とのコミュニケーションが円滑になり、メンテナンスのサービス性をさらに向上させることができ、サービスの効率も一層よくなる。
【００７１】
なお、ステップＳ１２３で受信した応答の情報をメンテナンス情報に追加して更新する代りに（または更新すると共に）、その応答の情報を管理装置１０２のオペレータに提示するようにしてもよい。
このとき、管理装置１０２又は管理装置１０２のオペレータが、更新後のメンテナンス情報を基に画像処理装置１００のメンテナンス予定日を再決定するようにしてもよい。そして、再決定したメンテナンス予定日時が図１１のステップＳ１０１で画像処理装置１００に通知したメンテナンス予定日時と異なる場合は、再び図１１の処理を行なって新しいメンテナンス予定日時を画像処理装置１００に通知するようにしてもよい。
【００７２】
ところで、このようにメンテナンス情報は随時更新が行なわれるため、サービスマンが携帯端末を用いて外出先等から最新のメンテナンス情報を閲覧したい場合があり得る。
次に、管理装置１０２がサービスマン用の携帯端末からメンテナンス情報の閲覧要求を受け付け、その閲覧要求に従ってメンテナンス情報を送信する場合の処理および動作について説明する。図１３は、この場合の管理装置１０２の処理を示すフローチャートである。
この画像処理装置管理システムにおいて、管理装置１０２のＣＰＵは、サービスマン用の携帯端末の通信接続要求に応答して、その携帯端末と通信を接続したときに図１３のフローチャートに示す処理を開始する。
【００７３】
なお、サービスマン用の携帯端末は、ＣＰＵ，ＲＯＭ，ＲＡＭ，不揮発性メモリ，ＮＩＣ等を備えた小型の端末装置（図示はしない）であり、図３に示したインタネット１０３または他の通信回線網等のネットワークに接続して管理装置１０２と通信できるものとする。この携帯端末は、サービスマンが携帯して管理装置１０２との連絡等に使用するため、例えばＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ），ラップトップ型コンピュータ，携帯電話等を適用することができるが、それに限定するものではない。
【００７４】
さて、管理装置１０２は処理を開始すると、まずステップＳ１３１で通信を接続しているサービスマン用の携帯端末からメンテナンス情報の閲覧要求を受信したか否かを判断する。
ステップＳ１３１で受信した場合はステップＳ１３２へ進み、そのサービスマン用の携帯端末にメンテナンス情報を送信する。この送信方法としては、例えばメンテナンス情報を電子メール等に添付して送信したり、携帯端末のブラウザで閲覧可能なハイパーテキスト文書として送信したりする等が考えられる。
【００７５】
その後、次のステップＳ１３３へ進み、その携帯端末から通信の切断要求を受信したか否かを判断する。そして、受信していない場合にはステップＳ１３１に戻って処理をくり返し、受信した場合はステップＳ１３４へ進み、通信の切断処理を行って処理を終了する。
一方、ステップＳ１３１で閲覧要求を受信しない場合はそのままステップＳ１３３へ進み、上記と同様な処理を行う。
以上の処理において、管理装置１０２のＣＰＵは、ステップＳ１３２で送信手段として機能する。
【００７６】
この画像処理装置管理システムにおいては、このような処理を行うことにより、サービスマンが外出先などからでも携帯端末を用いて最新のメンテナンス情報を参照してメンテナンス予定日時を確認することができる。さらに、前述したメンテナンス予定日時の報知に対する所定の連絡先からの応答の情報から、メンテナンス予定日時における画像処理装置やユーザの予定、メンテナンスの必要性、その他要望事項等を事前に知ることができ、それに早く対応することができる。従って、メンテナンスのサービス性をさらに向上させることができ、サービスの効率が一層良くなる。
【００７７】
なお、ここではサービスマン用の携帯端末からの要求に応じてメンテナンス情報を送信する例について説明したが、この要求を待たずに、管理装置１０２側から各サービスマンの端末装置に担当顧客の装置に係るメンテナンス情報を送信する等してもよい。
また、管理装置１０２が、サービスマン用の携帯端末からメンテナンス情報に対する応答（例えばユーザおよび画像処理装置の予定とサービスマン自身の予定との両方を考慮した新しいメンテナンス予定日時の提案等）を受け付けて、その応答の内容に従ってメンテナンス情報を更新するようにしてもよい。このようにすれば、メンテナンス情報の更新を速く行なうことができるので、メンテナンスのサービス性をさらに向上させることができ、サービスの効率も一層よくなる。
さらにこのとき、更新されたメンテナンス情報を基にメンテナンス予定日時を再決定するようにしてもよい。そして、再決定したメンテナンス予定日時が画像処理装置１００に通知済みのメンテナンス予定日時と異なる場合は、新しいメンテナンス予定日時を画像処理装置に通知するようにしてもよい。
【００７８】
また、ここではこの発明を画像処理装置管理システムに適用した例について説明したが、この発明はこれに限られるものではななく、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた各種通信装置の管理システムに適用することも可能である。
【００７９】
【発明の効果】
以上説明してきたように、この発明による画像処理装置管理システムによれば、メンテナンス予定日時を事前に画像処理装置に通知して表示させることができるので、画像処理装置管理システムにおけるメンテナンスのサービス性を向上させることができ、サービスの効率をよくすることができる。
【図面の簡単な説明】
【図１】この発明による管理システムの構成の一例を示す概念図である。
【図２】図１に示した管理システムにおけるデータ送受モデルを示す概念図である。
【図３】この発明による画像処理装置管理システムの一実施形態の構成を示す概念図である
【図４】図３に示した画像処理装置の制御部の物理的構成を示すブロック図である。
【図５】図４に示した操作パネルの構成例を示す図である。
【図６】図３に示した画像処理装置のソフトウェア構成の一例を示すブロック図である。
【図７】図６に示したＮＲＳモジュールの構成の一例を示す機能ブロック図である。
【図８】図３に示した管理装置の概略構成例を示すブロック図である。
【図９】図３に示した管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の一例を示す通信シーケンスである。
【図１０】同じく、管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の図９とは異なる例を示す通信シーケンスである。
【図１１】図３に示した画像処理システム管理装置において、管理装置が画像処理装置にメンテナンス予定日時を通知する場合に各装置が実行する処理のフローを送受信されるデータと共に示した図である。
【図１２】同じく、画像処理装置が管理装置にメンテナンス予定日時の報知に対する応答を送信する場合の処理を送受信されるデータと共に示した図である。
【図１３】図３に示した管理装置がサービスマン用の携帯端末からメンテナンス情報の閲覧要求を受け付けた場合の処理を示すフローチャートである。
【符号の説明】
１０：被管理装置 １１：仲介機能付被管理装置
１００：画像処理装置 １０１：仲介装置
１０２：管理装置 １０３：インタネット
１１０：仲介機能付画像処理装置
２００：コントローラボード ２０１：ＨＤＤ
２０２：ＮＶ−ＲＡＭ ２０３：ＰＩボード
２０４：ＰＨＹ ２０５：操作パネル
２０６：プロッタ／スキャナエンジンボード
２１１：周辺機 ２１２：ＰＣＩ−ＢＵＳ
３００：ＯＣＳ ３０１：ＥＣＳ
３０２：ＭＣＳ ３０３：ＮＣＳ
３０４：ＦＣＳ ３０５：ＮＲＳ
３０６：ＳＣＳ ３０７：ＳＲＭ
３０８：ＩＭＨ ３０９：コピーアプリ
３１０：ファクスアプリ ３１１：プリンタアプリ
３１２：スキャナアプリ
３１３：ネットファイルアプリ
３１４：ウェブアプリ ３１５：ＣＳＳ
３１６：ＤＣＳ ３１７：ＵＣＳ
６０１：モデム ６０２：通信端末
６０３：プロキシサーバ ６０４：操作者端末
６０５：データベース ６０６：制御装置
【発明の属する技術分野】
この発明は、ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機などの画像処理装置と通信可能な管理装置によって、これらの画像処理装置を管理する画像処理装置管理システムに関する。
【０００２】
【従来の技術】
近年、ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機などの画像処理装置に通信機能を設け、その画像処理装置を、サービス拠点に設置したコンピュータなどの管理装置が公衆回線やインタネットなどのネットワークを介して遠隔管理し、画像処理装置に異常が発生した時やメンテナンスが必要な時にその旨を自動的に管理装置に通報するようにして、迅速かつ的確な保守点検サービスを提供できるようにした画像処理装置管理システムが開発されている。
【０００３】
このような画像処理装置管理システムとしては、例えば特許文献１に見られるように、画像処理装置が故障を検出したときに、その故障検出データを管理装置に自動的に通知すると共に「自動通報中」等の文字メッセージを表示パネルに表示し、その通知に対する応答として、管理装置からサービスマン手配済み信号が受信したときに、「サービスマン手配中」または「サービスマン訪問」等の文字メッセージを表示し、さらに通知に失敗した場合にユーザに通報作業を依頼する「サービスセンターにＴＥＬしてください」等の文字メッセージを表示することにより、ユーザが自動通知の状況を的確に把握して必要な場合にのみ通報作業を行なうことができるようにした画像形成装置管理システムが提案されている。
【０００４】
また、例えば特許文献２に見られるように、画像処理装置が故障および消耗を検出したときに、その故障および消耗の状態と画像処理装置のメモリに登録された状態とを比較して、一致した場合に管理装置に通知するようにした画像処理装置管理システムも提案されている。
なお、この画像処理装置管理システムでは、管理装置は、画像処理装置から通知があった状態に対応する対処情報をデータベースから読み出して画像処理装置に送信するので、ユーザおよびオペレータの手間を低減することができる。
あるいは、データベースから読み出した対処情報を管理装置のオペレータに提示することもできる。この場合、オペレータが提示された対処情報を確認し、その対処情報がサービスマンの派遣であった場合に派遣予定日時を入力した後、管理装置に指示して、その対処情報を画像処理装置宛に送信することができる。
【０００５】
【特許文献１】
特開２００３−１５４７６号公報
【特許文献２】
特開２０００−２００１６９号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、このような従来の画像処理装置管理システムでは、管理装置が画像処理装置からの異常の通報に対して上述したような様々な情報を返信するという形でサービスを行なっているため、画像処理装置からの通報の有無に関係なく定期的に行なうメンテナンスなど不急な作業に関して作業日時等の詳しい情報を画像処理装置に送ることまでは行なっていなかった。
一般に、画像処理装置は複雑な機構を用いて画像処理を行うため、異常の発生を防いで性能を維持するためには定期的にメンテナンスを行なう必要があるが、このメンテナンスを行なう場合、サービスマンが画像処理装置の設置場所まで行き、そこで保守点検や消耗部品の交換等の作業を行う。そのため、ユーザはメンテナンス中に画像処理装置を使用することができない。
【０００７】
従って、従来の画像処理装置管理システムでは、ユーザはメンテナンスがいつ行なわれるか具体的な日時までは知ることができないため、メンテナンスのたびに画像処理装置の使用の予定が狂ってしまうという問題点があった。
つまり、従来の画像処理装置管理システムでは、メンテナンスに関するサービスがユーザにとって十分満足できるものではないという問題点があった。
さらに、サービス提供側では、画像処理装置のユーザの都合を予め知ることができないため、サービスマンを派遣したときにユーザの多忙や不在等の理由で作業ができない可能性があるという問題点もあった。
【０００８】
このような事態を避ける方法としては、管理装置のオペレータまたはサービスマンがユーザと連絡をとり、予め双方が都合の良い日時を調整してメンテナンスを行なうことが考えられる。しかし、管理している画像処理装置の全てに対してメンテナンスのたびに連絡作業を行なうのは非常に手間がかかり、効率が悪いという問題点があった。
この発明は上記の問題点に鑑みてなされたものであり、画像処理装置管理システムにおけるメンテナンスのサービス性を向上させると共に、その効率化を図ることを目的とする。
【０００９】
【課題を解決するための手段】
この発明は、上記の目的を達成するため、画像処理装置と通信可能な管理装置によって画像処理装置を管理する画像処理装置管理システムにおいて、管理装置に、画像処理装置のメンテナンスに関する情報であるメンテナンス情報として、画像処理装置のメンテナンス予定日時の情報を記憶する記憶手段と、その手段により記憶しているメンテナンス予定日時より所定期間前になったときにそのメンテナンス予定日時を画像処理装置に通知する通知手段とを設け、画像処理装置に、管理装置から通知されたメンテナンス予定日時を表示する表示手段を設けたものである。
【００１０】
また、上記画像処理装置に、所定の連絡先に対して管理装置から通知されたメンテナンス予定日時を報知する報知手段と、その報知に対する応答を受け付けて管理装置に送信する手段とを設けるようにするとよい。
このとき、上記管理装置に、画像処理装置から受信した応答の内容に従ってメンテナンス情報を更新する更新手段と、サービスマン用の携帯端末に上記メンテナンス情報を送信する送信手段とを設けるようにすると更によい。
【００１１】
【発明の実施の形態】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による管理システムの構成例について説明する。図１は、その管理システムの構成の一例を示す概念図である。なお、ここでは、通信機能を持ち、管理装置によって管理される電子装置（通信装置）を説明の便宜上「被管理装置」と云う。
【００１２】
この管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像形成装置あるいは画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等の電子装置に通信機能を持たせた通信装置を被管理装置１０とする遠隔管理システムである。そして、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）によって接続された遠隔管理仲介装置である仲介装置１０１、更に仲介装置１０１とインタネット１０３（公衆回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置１０２を備え、管理センタ等に配置される当該管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。
【００１３】
なお、仲介装置１０１と被管理装置１０との接続は、ＬＡＮに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）規格等に準拠したパラレル接続等によって行ってもよい。例えばＲＳ−４８５規格の場合には、仲介装置１０１に直列に５台までの被管理装置１０を接続することができる。
また、当該仲介装置１０１及び被管理装置１０は、その利用環境に応じて多様な階層構造を成す。
【００１４】
この点について、図１に示す設置環境Ａでは、管理装置１０２とＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）による直接的なコネクションを確立できる仲介装置１０１ａが、被管理装置１０ａ及び１０ｂを従える単純な階層構造になっている。しかし、設置する被管理装置１０の数が多く、１台の仲介装置１０１を設置しただけでは負荷が大きくなる場合には、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる上位の仲介装置が、被管理装置だけでなく、他の下位の仲介装置を従え、この仲介装置が他の被管理装置を更に従えるという階層構造を形成することもできる。この場合、下位の仲介装置に従えられる被管理装置を遠隔管理するために管理装置１０２から発せられた情報は、上位の仲介装置とその下位のノードとなる仲介装置とを経由して、それらの被管理装置に到達することになる。
【００１５】
また、設置環境Ｂにおいては、仲介装置１０１ｂと被管理装置１０ｃ，１０ｄのほか、ユーザが被管理装置１０ｃ，１０ｄに対して種々の操作を行うための端末装置１０５を設けている。このような端末装置１０５は、例えばパーソナルコンピュータ（ＰＣ）や携帯情報端末（ＰＤＡ）等に所要のプログラムを実行させることによって実現されるものであり、管理システムの構成においては必須ではない。しかし、このような端末装置１０５を設けることにより、ユーザは、被管理装置１０に設けた操作部だけでなく、端末装置１０５によっても被管理装置に種々の指示を行って動作させることができる。可能な動作は、当然被管理装置１０の種類によって異なるが、ここでいう動作には、画像形成，画像読み取り等の外見上の変化や動きを伴うもののみならず、情報の取得、設定の変更等、外見上は何も変化しないものも含むものとする。
【００１６】
また、設置環境Ｃのように、被管理装置１０に仲介装置１０１の機能を併せ持たせた仲介機能付被管理装置１１ａ，１１ｂを、別途仲介装置を介さずにインタネット１０３によって管理装置１０２に接続するようにしてもよい。
図示はしていないが、仲介機能付被管理装置１１の下位にさらに被管理装置１０を接続することもできる。
なお、各設置環境には、セキュリティ面を考慮し、ファイアウォール１０４を設置する。
【００１７】
なお、設置環境Ｂにおいては、相互のノードの接続関係が設置環境Ａ，Ｃと大きく異なるように図示しているが、これは、設置環境Ａ，ＣについてはＬＡＮ以外の接続方式も考慮して抽象的に各ノードの関係を示したのに対し、設置環境Ｂでは、ＬＡＮによって各ノードを接続した場合の構成を示したためである（ただし、被管理装置１０と端末装置１０５との接続をＬＡＮによるものに限定する意図ではない）。従って、設置環境Ａ，Ｃにおける各ノードをＬＡＮで接続すれば設置環境Ｂについて示したものに近い構成になるし、また、設置環境Ｂにおける被管理装置１０ｃ，１０ｄも、管理装置１０２との通信については、設置環境Ａの場合と同様仲介装置１０１ｂを介して行う。
【００１８】
このような遠隔管理システムにおいて、仲介装置１０１は、これに接続された被管理装置１０の制御管理のためのアプリケーションプログラムを実装している。
管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した被管理装置１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置１０も含め、この遠隔管理システムにおけるこれら各ノードは、ＲＰＣ（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
【００１９】
すなわち、仲介装置１０１又はこれと接続された被管理装置１０では、管理装置１０２への要求を生成してこれを管理装置１０２へ引き渡し、この要求に対する応答を取得できる一方で、管理装置１０２は、上記仲介装置１０１側への要求を生成してこれを仲介装置１０１側へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、仲介装置１０１に被管理装置１０に対して各種要求を送信させ、被管理装置１０からの応答を仲介装置１０１を介して取得することも含まれる。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ），ＨＴＴＰ，ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ），ＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ），ＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
【００２０】
この送受信のデータ送受モデルを図２の概念図に示す。なお、この図においては、ファイアウォール１０４の存在は考慮していない。
（Ａ）は、被管理装置１０で管理装置１０２に対する要求が発生したケースである。このケースでは、被管理装置１０が被管理装置側要求ａを生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこの要求に対する応答ａを返すというモデルになる。同図に示す仲介装置１０１は複数であるケースも想定できる。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、管理装置１０２が、仲介装置１０１を経由して被管理装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
【００２１】
（Ｂ）は、管理装置１０２で被管理装置１０に対する要求が発生したケースである。このケースでは、管理装置１０２が管理装置側要求ｂを生成し、これを仲介装置１０１を経由して受け取った被管理装置１０が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。
【００２２】
次に、図１に示す管理装置１０２の物理的構成について説明すると、当該管理装置１０２は、不図示のＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、ネットワークインタフェースカード（以下ＮＩＣという）等を備えている。
更に、図１に示す仲介装置１０１の物理的構成について説明すると、当該仲介装置１０１は、不図示のＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、ＮＩＣ等を備えている。
また、仲介機能付被管理装置１１については、仲介装置１０１の機能を実現するためにこれらのユニットを単に被管理装置１０に付加しても良いが、被管理装置１０に備えるＣＰＵ，ＲＯＭ，ＲＡＭ等のハードウェア資源を利用し、ＣＰＵに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置１０１の機能を実現することもできる。
【００２３】
以下、図１に示した管理装置のより具体的な例として、この発明による通信装置の一例である画像処理装置を被管理装置とした、この発明による遠隔管理システムの一例である画像処理装置遠隔管理システムについて説明する。図３は、その画像処理装置遠隔管理システムの構成の一例を示す概念図であるが、被管理装置１０を画像処理装置１００に、仲介機能付被管理装置１１を仲介機能付画像処理装置１１０に変更した点が図１と相違するのみであるので、システムの全体構成についての説明は省略する。
画像処理装置１００は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、仲介機能付画像処理装置１１０は、画像処理装置１００に仲介装置１０１の機能を併せ持たせたものである。
【００２４】
このような画像処理装置１００の物理的構成について図４を用いて説明する。
図４は、画像処理装置１００内の物理的構成の一例を示すブロック図である。同図に示すように、画像処理装置１００は、コントローラボード２００、ＨＤＤ（ハードディスクドライブ）２０１、ＮＶ−ＲＡＭ（不揮発性ＲＡＭ）２０２、ＰＩ（パーソナルインタフェース）ボード２０３、ＰＨＹ（物理メディアインタフェース）２０４、操作パネル２０５、プロッタ／スキャナエンジンボード２０６、電源ユニット２０７、フィニッシャ２０８、ＡＤＦ（自動原稿給送装置）２０９、給紙バンク２１０、その他周辺機２１１を備えている。これらのユニットは、それぞれがこの画像処理装置１００におけるハードウェア資源である。
【００２５】
ここで、コントローラボード２００は、制御手段に該当し、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備え、ＰＣＩ−ＢＵＳ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｔｅｒｃｏｎｎｅｃｔ−Ｂｕｓ）２１２を介して各機能を制御している。また、ＨＤＤ２０１は、記憶手段に該当する。また、ＮＶ−ＲＡＭ２０２は、記憶手段に該当し、不揮発性メモリであって、例えば、フラッシュメモリ等が該当する。これらの記憶手段には、この画像処理装置１００の制御に使用する各種プログラムや、動作ログ、画像データ、後述する画像処理枚数のカウント値、画像データ送信手段による画像データの送信先情報を始め、認証処理に用いる照合用のパスワードや設定パラメータ等を含む、各種のデータを記憶する。
【００２６】
また、ＰＩボード２０３とＰＨＹ２０４は、ネットワーク通信手段に該当し、外部との通信を行うためのものであって、例えば、通信ボード等が該当する。ＰＩボード２０３はＲＳ４８５規格に準拠したインタフェースを備え、ラインアダプタを介して公衆回線に接続している。なお、上述したように、このＰＩボード２０３を用いて画像処理装置１００と仲介装置１０１とを接続することも可能である。ＰＨＹ２０４は、ＬＡＮを介して外部装置と通信を行うためのインタフェースである。これらのＰＩボード２０３とＰＨＹ２０４は、画像データを外部装置に送信する画像データ送信手段としても機能させることができる。
【００２７】
プロッタ／スキャナエンジンボード２０６は、画像データに基づいて用紙に画像を形成する画像処理手段や、原稿の画像データを読み取る画像読取手段に該当する。さらに、この画像処理手段によって画像処理した用紙の枚数をカウントするカウント手段も備えている。
なお、同図中のＥＮＧＲＤＹは、エンジン側の各種初期設定が完了して、コントローラボード２００とコマンドの送受信の準備ができたことをコントローラボード２００側に通知するための信号線である。また、ＰＷＲＣＴＬは、エンジンへの電源供給をコントローラボード２００側から制御するための信号線である。
【００２８】
また、操作パネル２０５は、図５に示すように液晶タッチパネル３１と複数のハードキーを備えており、表示手段および操作を受け付ける手段として機能する。
液晶タッチパネル３１は、液晶ディスプレイの表面にタッチパネルを備えており、機能キーや部数、装置の状態を示すメッセージ等を表示するユニットである。
また、ハードキーとしては、プリント枚数や倍率等を入力するためのテンキー３２、プリント動作の中断やテンキー３２の入力結果のクリア等を指示するためのクリア／ストップ（Ｃ／Ｓ）キー３３、プリント動作の開始等を指示するためのスタートキー３４、管理者や使用者の使い勝手に合わせた装置の設定を行うための初期設定キー３６、液晶タッチパネル３１の表示言語を別の言語に切り替える言語切換キー３７、それぞれのアプリケーションを選択するためのコピーキー３８，ＦＡＸキー３９，プリンタキー４０，スキャナキー４１、実行中のプリント動作に割り込んで別のプリント動作等をさせるための割込キー４２、予熱状態の移行／解除等を指示するための予熱キー４３、設定されているプリントモードをデフォルト状態に戻すためのリセットキー（モードクリアキー）４４等が設けられている。
【００２９】
さらに、いくつかのハードキー上には、そのキーの選択状態を示すためのＬＥＤによる表示部４５が設けられている。特にスタートキー３４上には、画像処理装置１００がプリント動作可能である場合は緑色に点灯し、動作不可である場合は赤色に点灯するよう、赤・緑両方のＬＥＤによる表示部４６が付加されている。
なお、これらのハードキーのいくつかを省略し、液晶ディスプレイ３１にタッチキーとして表示するようにしてもよい。
【００３０】
次に、画像処理装置１００におけるソフトウェア構成を図６を用いて説明する。
図６は、画像処理装置１００のソフトウェア構成の一例を示すブロック図である。当該画像処理装置１００のソフトウェア構成は、最上位のアプリケーションモジュール（アプリ）層、その下位のサービスモジュール層からなる。そして、これらのソフトウェアを構成するプログラムはＨＤＤ２０１やコントローラボード２００上のＲＡＭに記憶され、必要に応じて読み出されてコントローラボード２００上のＣＰＵによって実行される。そしてＣＰＵは、これらのプログラムを必要に応じて実行することにより、この発明による各機能（報知手段，送信手段，その他の手段としての機能）を実現することができる。
【００３１】
特に、アプリケーションモジュール層のソフトウェアは、ＣＰＵをハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段として機能させるためのプログラムによって構成され、サービスモジュール層のソフトウェアは、ＣＰＵを、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段として機能させるためのプログラムによって構成される。
【００３２】
なお、それらの機能のうち、管理装置１０２との通信に係わる機能の実現方法は、画像処理装置１００と仲介機能付画像処理装置１１０とによって異なる。つまり、仲介機能付画像処理装置１１０の場合は、仲介装置の機能を備えているため、ＣＰＵが対応するプログラムを実行することにより、通信に係わる機能を実現することができる。画像処理装置１００の場合には、ＣＰＵが対応するプログラムを実行すると共に、仲介装置１０１を利用することにより、通信に係わる機能を実現することができる。
【００３３】
サービスモジュール層には、オペレーションコントロールサービス（ＯＣＳ）３００、エンジンコントロールサービス（ＥＣＳ）３０１、メモリコントロールサービス（ＭＣＳ）３０２、ネットワークコントロールサービス（ＮＣＳ）３０３、ファクスコントロールサービス（ＦＣＳ）３０４、ニューリモートサービス（ＮＲＳ）３０５、システムコントロールサービス（ＳＣＳ）３０６、システムリソースマネージャ（ＳＲＭ）３０７、イメージメモリハンドラ（ＩＭＨ）３０８、カスタマーサポートシステム（ＣＳＳ）３１５、デリバリーコントロールサービス（ＤＣＳ）３１６、ユーザコントロールサービス（ＵＣＳ）３１７を実装している。更に、アプリケーションモジュール層には、コピーアプリ３０９、ファクスアプリ３１０、プリンタアプリ３１１、スキャナアプリ３１２、ネットファイルアプリ３１３、ウェブアプリ３１４を実装している。
【００３４】
これらを更に詳述する。
ＯＣＳ３００は、操作パネル２０５を制御するモジュールである。
ＥＣＳ３０１は、ハードウェアリソース等のエンジンを制御するモジュールである。
ＭＣＳ３０２は、メモリ制御をするモジュールであり、例えば、画像メモリの取得及び開放、ＨＤＤ２０１の利用等を行う。
ＮＣＳ３０３は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
ＦＣＳ３０４は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。
【００３５】
ＮＲＳ３０５は、ネットワークを介してデータを送受信する際のデータの変換等をするモジュールであり、またネットワークを介した遠隔管理に関する機能をまとめたモジュールである。
ＳＣＳ３０６は、コマンドの内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理及び終了管理を行うモジュールである。
ＳＲＭ３０７は、システムの制御及びリソースの管理を行うモジュールである。
ＩＭＨ３０８は、一時的に画像データを入れておくメモリを管理するモジュールである。
【００３６】
ＣＳＳ３１５は、公衆回線を介してデータを送受信する際のデータの変換等をするモジュールであり、また公衆回線を介した遠隔管理に関する機能をまとめたモジュールである。
ＤＣＳ３１６は、ＨＤＤ２０１やコントローラボード２００上のメモリに記憶している（する）画像ファイル等をＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いて送受信するモジュールである。
ＵＣＳ３１７は、ユーザが登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
【００３７】
コピーアプリ３０９は、コピーサービスの機能を実現するためのアプリケーションプログラムである。
ファクスアプリ３１０は、ファクスサービスの機能を実現するためのアプリケーションプログラムである。
プリンタアプリ３１１は、プリンタサービスの機能を実現するためのアプリケーションプログラムである。
スキャナアプリ３１２は、スキャナサービスの機能を実現するためのアプリケーションプログラムである。
ネットファイルアプリ３１３は、ネットファイルサービスの機能を実現するためのアプリケーションプログラムである。
ウェブアプリ３１４は、ウェブページに関する入出力処理を行うためのアプリケーションプログラムである。
【００３８】
次に、上述した画像処理装置１００のソフトウェアの構成に含まれるＮＲＳ３０５の内部構成を図７を用いて更に説明する。
図７は、ＮＲＳモジュールの構成の一例を示す機能ブロック図である。同図に示すように、ＮＲＳ３０５は、ＳＣＳ３０６とＮＣＳ３０３との間で処理を行なっている。ウェブサーバ機能部５００は、外部から受信した要求に関する応答処理を行う。ここでの要求は、例えば、構造化言語であるＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記載された、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）によるＳＯＡＰリクエストであることが考えられる。ウェブクライアント機能部５０１は、外部への要求を発行する処理を行う。ｌｉｂｓｏａｐ５０２は、ＳＯＡＰを処理するライブラリであり、ｌｉｂｘｍｌ５０３は、ＸＭＬ形式で記載されたデータを処理するライブラリである。また、ｌｉｂｇｗｗｗ５０４は、ＨＴＴＰを処理するライブラリであり、ｌｉｂｇｗ＿ｎｃｓ５０５は、ＮＣＳ３０３との間の処理をするライブラリである。
【００３９】
続いて、図３に示した管理装置１０２について説明する。図８は、管理装置の概略構成例を示すブロック図である。
この管理装置１０２は、モデム６０１，通信端末６０２，プロキシ（Ｐｒｏｘｙ）サーバ６０３，操作者端末６０４，データベース６０５，制御装置６０６等からなる。
モデム６０１は、公衆回線を介して機器利用者側（例えば画像処理装置を利用しているユーザ先）の仲介装置１０１との通信を司るものであり、送受信するデータを変復調する。このモデム６０１と後述する通信端末６０２により通信手段としての機能を果たす。
通信端末６０２は、公衆回線を介してラインアダプタや仲介装置１０１とのデータの送受信を行う。
プロキシサーバ６０３は、インタネット１０３を介して機器利用者側の仲介装置１０１とのデータの送受信及びセキュリティ管理を行う。このプロキシサーバ６０３も、通信手段としての機能を果たす。
【００４０】
操作者端末６０４は、管理センタのオペレータが操作する端末であり、各種データの入力をオペレータによるキーボード等の入力装置上の操作により受け付けたり、オペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各機器利用者側の仲介装置１０１又は仲介機能付画像処理装置１１０が管理装置１０２へ通信する際に使用するＩＰアドレスや発呼先電話番号等の顧客情報がある。
データベース６０５は、図示しないサーバのハードディスク装置等の記憶装置に存在し、各機器利用者側の仲介装置１０１および仲介機能付画像処理装置１１０のＩＰアドレスや電話番号、それらの装置から受信したデータ、および操作者端末６０４から入力されたデータ等の各種データを記憶する。
【００４１】
制御装置６０６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、上記プログラムを必要に応じて実行すると共に、モデム６０１，通信端末６０２，プロキシサーバ６０３，操作者端末６０４またはデータベース６０５を利用することにより、この発明による各機能（記憶手段，通知手段，更新手段，送信手段，その他の手段としての機能）を実現することができる。
【００４２】
上述した構成を踏まえて、図３の画像処理装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例について図９を用いて説明する。なお、以下に示すＳＣＳ３０６，ＮＲＳ３０５およびウェブサービスアプリ３１８による処理は、実際にはＣＰＵがそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。以後も、プログラムが何らかの処理を行うものとして説明を行う場合には、同様とする。
【００４３】
図９は、管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
この例においては、まず、仲介装置１０１は、管理装置１０２に対してポーリング（送信要求があるかどうかの問い合わせ）を行う（Ｓ６０１）。つまり、自己の識別情報である識別子を付加したポーリング用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして管理装置１０２へ送信する。図３に示したように、仲介装置１０１と管理装置１０２との間にはファイアウォール１０４を設けているため、管理装置１０２から仲介装置１０１に向けて通信セッションを張る（通信を要求して通信経路を確立する）ことができないので、管理装置１０２から仲介装置１０１（あるいは仲介装置１０１を介して画像処理装置１００）に要求を送信したい場合でも、このように仲介装置１０１からのポーリングを待つ必要があるのである。
【００４４】
管理装置１０２は、仲介装置１０１から上記ＨＴＴＰメッセージを受信すると、課金カウンタ取得要求を示すＳＯＡＰドキュメントを生成し、該当する仲介装置１０１（受信したＳＯＡＰメッセージの送信元）へ、ポーリングに対する応答のＨＴＴＰメッセージとして送信する（Ｓ６０２）。このとき、受信したＨＴＴＰメッセージ内のＳＯＡＰドキュメントに付加された識別子に基づいて該当する仲介装置１０１を認識する。このように、ファイアウォール１０４の内側からの通信（ＨＴＴＰリクエスト）に対する応答（ＨＴＴＰレスポンス）であれば、ファイアウォールの外側から内側に対してデータを送信することができる。
【００４５】
仲介装置１０１は、管理装置１０２から上記ＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいて課金カウンタ取得要求を示すＳＯＡＰドキュメントを生成し、やはりＨＴＴＰメッセージとして自己に接続されている画像処理装置１００へ送信し、画像処理装置１００側ではウェブサービスアプリ３１８がこれを受け取る（Ｓ６０３）。
そして、ウェブサービスアプリ３１８が仲介装置１０１からＨＴＴＰメッセージとして受信したＳＯＡＰドキュメントに記述されている課金カウンタ取得要求をＮＲＳ３０５に渡し、ＮＲＳ３０５がそれをＳＣＳ３０６へ通知する（Ｓ６０４）。
ＳＣＳ３０６は、ＮＲＳ３０５から課金カウンタ取得要求の通知を受けると、ＮＶ−ＲＡＭ２０２に格納されている課金カウンタのデータを読み取る（Ｓ６０５）。そして、その読み取った課金カウンタのデータ（応答データ）をＮＲＳ３０５へ引き渡す（Ｓ６０６）。
【００４６】
ＮＲＳ３０５は、ＳＣＳ３０６から課金カウンタのデータを受け取る（取得する）と、これをウェブサービスアプリ３１８に渡す。そして、ウェブサービスアプリ３１８がその内容を示す課金カウンタ用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして仲介装置１０１へ送信する（Ｓ６０７）。
仲介装置１０１は、ウェブサービスアプリ３１８から課金カウンタ用のＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントをＨＴＴＰメッセージとして管理装置１０２へ送信する（Ｓ６０８）。
このように、上記通信シーケンスにより、データの送受信が行われる。
【００４７】
次に、上記図９と異なり、画像処理装置１００から仲介装置１０１を経て管理装置１０２へデータを送信する場合の通信シーケンスの一例について図１０を用いて説明する。
図１０は、画像処理装置から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、ＯＣＳ３００は、ユーザコールキーが押下された旨をＳＣＳ３０６へ通知する（Ｓ７０１）。
ＳＣＳ３０６は、ＯＣＳ３００からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をＮＲＳ３０５へ通知する（Ｓ７０２）。
【００４８】
ＮＲＳ３０５は、ＳＣＳ３０６からユーザコール要求の通知を受けると、これをウェブサービスアプリ３１８に渡す。そして、ウェブサービスアプリ３１８がユーザコールを知らせるユーザコール情報であるユーザコール用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして仲介装置１０１へ送信する（Ｓ７０３）。
仲介装置１０１は、ウェブサービスアプリ３１８からユーザコール用のＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントに自己の識別情報である識別子を付加し、そのＳＯＡＰドキュメントをやはりＨＴＴＰメッセージとして管理装置１０２に対して送信し、ユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のＳＯＡＰドキュメントを管理装置１０２へ通報する（Ｓ７０４）。この場合には、ファイアウォール１０４の内側から外側に向けての送信であるので、仲介装置１０１が自ら管理装置１０２に向けてセッションを張ってデータを送信することができる。
ここで、ステップＳ７０４の処理後のパターンを以下の（Ａ）から（Ｃ）に分けて説明する。
【００４９】
まず、（Ａ）において、管理装置１０２は、ユーザ先の仲介装置１０１からユーザコール用のＳＯＡＰドキュメントをＨＴＴＰメッセージとして受信し、その受信が正常に終了した場合には、その旨（ユーザコールが成功した旨）のコール結果を、正常に終了しなかった（異常に終了した）場合には、その旨（ユーザコールが失敗した旨）のコール結果を示すＳＯＡＰドキュメント生成し、ＨＴＴＰメッセージによる応答として通報元の仲介装置１０１へ送信する（Ｓ７０５）。
仲介装置１０１は、管理装置１０２からコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントを、やはりＨＴＴＰメッセージとしてユーザコールキーが押下された画像処理装置１００へ送信し、画像処理装置１００側ではウェブサービスアプリ３１８がこれを受け取る（Ｓ７０６）。
【００５０】
ウェブサービスアプリ３１８は、仲介装置１０１からコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントが示すコール結果をＮＲＳ３０５に渡す。そしてＮＲＳ３０５がそのコール結果を解釈（判定）し、ＳＣＳ３０６へ通知する（Ｓ７０７）。
ＳＣＳ３０６は、コール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７０８）。
【００５１】
次に（Ｂ）において、仲介装置１０１は、規定時間（予め設定された所定時間）が経っても管理装置１０２から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果を示すＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとしてウェブサービスアプリ３１８へ送信する（Ｓ７０９）。
ウェブサービスアプリ３１８は、失敗した旨のコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントに記述されている失敗した旨のコール結果をＮＲＳ３０５に渡す。そしてＮＲＳ３０５がそのコール結果を解釈し、ＳＣＳ３０６へ通知する（Ｓ７１０）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１１）。
【００５２】
次に（Ｃ）において、ＮＲＳ３０５は、規定時間が経っても仲介装置１０１から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をＳＣＳ３０６へ通知する（Ｓ７１２）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１３）。
【００５３】
なお、ここでは管理装置１０２からファイアウォール１０４を越えて仲介装置１０１（あるいは仲介装置１０１を介して画像処理装置１００）にデータを送信するために、仲介装置１０１からのＨＴＴＰリクエストに対するレスポンスという形で送信を行う例について説明したが、ファイアウォール１０４を越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用して、送信したいデータを記載あるいは添付したメールを管理装置１０２から仲介装置１０１に送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。
【００５４】
次に、このような基本的な機能を有する図３に示した画像処理装置管理システムにおける本発明の特徴に関連する動作、すなわち、管理装置１０２が画像処理装置１００にメンテナンス予定日時を通知し、画像処理装置１００がそのメンテナンス予定日時を表示すると共に、報知用の連絡先が設定されていた場合にそのメンテナンス予定日時を其処に報知する処理について説明する。
図１１は、この場合に画像処理装置１００および管理装置１０２のＣＰＵが各々行う処理のフローを、管理装置と画像処理装置との間で送受信されるデータと共に示した図である。これらの処理は、画像処理装置１００のＣＰＵおよび管理装置１０２のＣＰＵが、それぞれ所要のプログラムを実行することによって行うものである。
【００５５】
なお、図が煩雑になるのを防ぐため、図１１では本発明の特徴に係る部分のみを図示している。以下、後述する図１２乃至図１５についても同様である。
また、図１１において、２本のフローチャート間の矢印はデータの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。このデータの送信は、実際には図２あるいは図３に示したように仲介装置１０１等を介して行なわれるが、説明を簡単にするため、ここでは直接送信するかのように記載する。後述する図１３についても同様である。
【００５６】
この画像処理装置管理システムにおいて、管理装置１０２のデータベース６０５には、管理対象の画像処理装置１００毎に、メンテナンスに関する情報として、過去に行なったメンテナンスの作業日時や作業内容等のメンテナンス情報を記憶している。画像処理装置１００における異常発生履歴等もこの情報に含めるようにしてもよい。そして、これらの情報を基に画像処理装置１００毎に定期メンテナンスのスケジュールを決定し、設置先への訪問予定日としてメンテナンス予定日時も、メンテナンス情報の一部として記憶している。なお、メンテナンス予定日時は自動で定めることができるようにするとよいが、管理装置１０２のオペレータ等が定めて記憶させるようにしてもよい。
【００５７】
管理装置１０２のＣＰＵは、各画像処理装置１００についてこのようなメンテナンス予定日時の情報を参照し、いずれかの画像処理装置１００についてのメンテナンス予定日時よりも所定期間前になると、その画像処理装置を対象として図１１の左側のフローチャートに示す処理を開始する。ここで、所定期間は、何週間、何日、何時間のように、予め定めておくものとする。
そして、この処理を開始すると、まずステップＳ１０１でメンテナンス予定日時の情報を対象の画像処理装置１００に送信して、メンテナンス予定日時を通知する。
【００５８】
一方、対象となった画像処理装置１００は、管理装置１０２からメンテナンス予定日時の情報を受信すると図１１の右側のフローチャートに示す処理を開始する。そして、まずステップＳ２０１でその受信が成功したか否かを判断する。
ステップＳ２０１で成功の場合はステップＳ２０２へ進み、受信が成功した旨の応答を管理装置１０２に送信する。そして、次のステップＳ２０３へ進み、表示手段である操作パネル２０５に受信した情報に従ってメンテナンス予定日時を表示させる。そして、ステップＳ２０７で、画像処理装置１００にメンテナンス予定日時を報知すべき連絡先が設定されているか否かを判断し、設定されている場合はステップＳ２０８へ進んで、設定された連絡先に管理装置１０２から通知されたメンテナンス予定日時を報知して処理を終了する。
【００５９】
なお、この連絡先としては、例えば管理者として画像処理装置１００に登録されているユーザの電子メールアドレスなどが考えられ、報知の方法としては、例えば設定された連絡先の電子メールアドレスにメンテナンス予定日時の情報を添付した電子メールを送信する等が考えられる。
また、ステップＳ２０７で設定されていない場合は、報知を行なわずにそのまま処理を終了する。
一方、ステップＳ２０１で失敗の場合はステップＳ２０４へ進み、管理装置１０２への応答としてメンテナンス予定日時の再送要求を送信する。
【００６０】
管理装置１０２側では、ステップＳ１０１の次のステップＳ１０２で、ステップＳ１０１でメンテナンス予定日時の情報を通知してから一定時間内に、画像処理装置１００から再送要求があったか否かを判断する。
そして、ステップＳ１０２でなかった場合は、そのまま処理を終了する。ステップＳ１０２で再送要求があった場合はステップＳ１０３へ進み、メンテナンス予定日時の情報を画像処理装置１００へ再び通知してから処理を終了する。
【００６１】
画像処理装置１００側では、ステップＳ２０４の次のステップＳ２０５で、ステップＳ２０４で管理装置１００に再送要求を送信してから一定時間内にメンテナンス予定日時の情報の受信に成功したか否かを再び判断する。
ステップＳ２０５で成功の場合はステップＳ２０２へ進み、以下ステップＳ２０２以降で、前述したステップＳ２０１の判断でＹＥＳの場合と同様の処理を行う。すなわち、管理装置１０２に受信成功の応答を送信して、操作パネル２０５にメンテナンス予定日時を表示させて処理を終了する。
ステップＳ２０５で失敗の場合はステップＳ２０６に進み、エラー処理を行って処理を終了する。このエラー処理としては、例えば「メンテナンス予定日時の受信に失敗しました」等の文字メッセージを操作パネル２０５に表示するなどが考えられる。
【００６２】
なお、ステップＳ２０５で失敗の場合にステップＳ２０６のエラー処理を行なわずにステップＳ２０４に戻り、再びメンテナンス予定日時の情報の再送要求を管理装置１０２に送信するようにしてもよい。
また、管理装置１０２が一定期間内に成功応答を受信しなかった場合にも、メンテナンス日時の情報を再送するようにしてもよい。
以上の処理において、管理装置１０２のＣＰＵは、ステップＳ１０１およびＳ１０３で通知手段として機能する。また、画像処理装置１００のＣＰＵはステップＳ２０８で報知手段として機能する。
【００６３】
この画像処理装置管理システムにおいては、このような処理を行うことにより、決定したメンテナンス予定日時を事前に画像処理装置に通知して操作パネル２０５等に表示させることができるため、ユーザはその予告告知されたメンテナンス予定日時を考慮して画像処理装置の使用の予定を計画することができるようになり、サービスマンを派遣したときにユーザの多忙や不在等の理由で作業できない可能性が少なくなる。従って、メンテナンスのサービス性を向上させることができ、しかも効率よくサービスを行なうことができるようになる。
また、画像処理装置１００に設定されている連絡先にメンテナンス予定日時を報知することができるため、画像処理装置を管理しているユーザ等がメンテナンス予定日時の情報を見落としてしまう可能性を低くすることができる。
【００６４】
なお、ステップＳ２０３において、画像処理装置１００が受信したメンテナンス予定日時の情報を一旦ＨＤＤ２０１等に記憶しておき、所定の時間またはユーザの指示を受け付けたときに操作パネル２０５に表示するようにしてもよい。
また、受信したメンテナンス予定日時を、操作パネル２０５へ表示する代わりに用紙等に印刷するようにしてもよい。あるいは、メンテナンス予定日時の情報を、画像処理装置１００にＬＡＮ等で接続されている端末装置１０５（図３参照）に電子メール等を用いて転送（報知）するようにしてもよい。また、これらの複数の方法でユーザにメンテナンス予定日時を予告告知するようにしてもよい。
さらにまた、ステップＳ２０８の報知を行なう場合には、ステップＳ２０３の表示は行なわないようにしてもよい。
【００６５】
ところで、ステップＳ２０８の処理によるメンテナンス予定日時の報知を受けたユーザは、この報知に対して、そのメンテナンス予定日時の都合、メンテナンスの必要性、その他要望等を応答として管理装置１０２に対して送信することができる。そしてここでは、この送信は画像処理装置１００を介して行なう。すなわち、ユーザがこの応答を画像処理装置１００に送信すると、画像処理装置１００が自動的にこれを管理装置１０２に送信するようにしている。
次に、この場合の処理について説明する。図１２は、この場合に画像処理装置および管理装置のＣＰＵが各々行う処理のフローを送受信されるデータと共に示した図である。
この画像処理装置管理システムにおいて、画像処理装置１００のＣＰＵは、メンテナンス予定日時を報知した所定の連絡先から上記の応答を受け付けたときに図１２の右側のフローチャートに示す処理を開始する。
【００６６】
そして、画像処理装置１００は、処理を開始するとまずステップＳ２２１で、所定の連絡先から受け付けたメンテナンス日時の報知に対する応答の情報を管理装置１０２に送信する。
一方、管理装置１０２は、その応答の情報を受信すると図１２の左側のフローチャートに示す処理を開始し、まずステップＳ１２１でその受信が成功したか否かを判断する。
ステップＳ１２１で成功の場合はステップＳ１２２へ進み、受信が成功した旨の応答を画像処理装置１００に送信する。そして、次のステップＳ１２３で、受信した応答の情報をデータベース６０５に記憶しているメンテナンス情報に追加してメンテナンス情報の更新を行ない、処理を終了する。
ステップＳ１２１で失敗の場合はステップＳ１２４へ進み、画像処理装置１００に応答の情報の再送要求を送信する。
【００６７】
画像処理装置１００側では、ステップＳ２２１の次のステップＳ２２２で、ステップＳ２２１で応答の情報を送信してから一定時間内に、管理装置１０２から再送要求があったか否かを判断する。
そして、ステップＳ２２２で再送要求がなかった場合は、そのまま処理を終了する。ステップＳ２２２で再送要求があった場合はステップＳ２２３へ進み、所定の連絡先から受け付けたメンテナンス日時の報知に対する応答の情報を管理装置１０２へ再び通知してから処理を終了する。
【００６８】
管理装置１０２側では、ステップＳ１２４の次のステップＳ１２５で、ステップＳ１２４で画像処理装置１００に再送要求を送信してから一定時間内に応答の情報の受信に成功したか否かを再び判断する。
ステップＳ１２５で成功の場合はステップＳ１２２へ進み、以下ステップＳ１２２以降で、前述したステップＳ１２１の判断でＹＥＳの場合と同様の処理を行う。すなわち、画像処理装置１００に受信成功の応答を送信し、受信した応答の情報をメンテナンス情報に追加して更新して、処理を終了する。
【００６９】
ステップＳ１２５で失敗の場合はステップＳ１２６に進み、エラー処理を行って処理を終了する。このエラー処理としては、例えばメンテナンス日時の報知に対する応答の情報の受信に失敗した旨をオペレータに通知する等が考えられる。
なお、ステップＳ１２５で失敗の場合にステップＳ１２６のエラー処理を行なわずにステップＳ１２４に戻り、再び応答の情報の再送要求を画像処理装置１００に送信するようにしてもよい。
また、画像処理装置１００が一定期間内に成功応答を受信しなかった場合にも、応答の情報を再送するようにしてもよい。
【００７０】
以上の処理において、画像処理装置１００のＣＰＵは、ステップＳ２２１およびＳ２２３でメンテナンス予定日時の報知に対する応答の情報を管理装置１０２に送信する手段として機能する。
この画像処理装置管理システムにおいては、このような処理を行うことにより、画像処理装置に登録されているユーザの連絡先に報知したメンテナンス予定日時に対するユーザからの応答の情報を画像処理装置１００が受け付けて管理装置１０２に送信し、管理装置でその応答の情報をデータベース６０５のメンテナンス情報に追加して更新することができるので、メンテナンス予定日時におけるユーザの都合や要望事項等を事前にサービス提供側が知ることができる。さらに、その応答の情報に応じてサービスマンが行なうメンテナンスの作業内容やメンテナンス予定日時を変更することも可能である。従って、ユーザとサービス提供側とのコミュニケーションが円滑になり、メンテナンスのサービス性をさらに向上させることができ、サービスの効率も一層よくなる。
【００７１】
なお、ステップＳ１２３で受信した応答の情報をメンテナンス情報に追加して更新する代りに（または更新すると共に）、その応答の情報を管理装置１０２のオペレータに提示するようにしてもよい。
このとき、管理装置１０２又は管理装置１０２のオペレータが、更新後のメンテナンス情報を基に画像処理装置１００のメンテナンス予定日を再決定するようにしてもよい。そして、再決定したメンテナンス予定日時が図１１のステップＳ１０１で画像処理装置１００に通知したメンテナンス予定日時と異なる場合は、再び図１１の処理を行なって新しいメンテナンス予定日時を画像処理装置１００に通知するようにしてもよい。
【００７２】
ところで、このようにメンテナンス情報は随時更新が行なわれるため、サービスマンが携帯端末を用いて外出先等から最新のメンテナンス情報を閲覧したい場合があり得る。
次に、管理装置１０２がサービスマン用の携帯端末からメンテナンス情報の閲覧要求を受け付け、その閲覧要求に従ってメンテナンス情報を送信する場合の処理および動作について説明する。図１３は、この場合の管理装置１０２の処理を示すフローチャートである。
この画像処理装置管理システムにおいて、管理装置１０２のＣＰＵは、サービスマン用の携帯端末の通信接続要求に応答して、その携帯端末と通信を接続したときに図１３のフローチャートに示す処理を開始する。
【００７３】
なお、サービスマン用の携帯端末は、ＣＰＵ，ＲＯＭ，ＲＡＭ，不揮発性メモリ，ＮＩＣ等を備えた小型の端末装置（図示はしない）であり、図３に示したインタネット１０３または他の通信回線網等のネットワークに接続して管理装置１０２と通信できるものとする。この携帯端末は、サービスマンが携帯して管理装置１０２との連絡等に使用するため、例えばＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ），ラップトップ型コンピュータ，携帯電話等を適用することができるが、それに限定するものではない。
【００７４】
さて、管理装置１０２は処理を開始すると、まずステップＳ１３１で通信を接続しているサービスマン用の携帯端末からメンテナンス情報の閲覧要求を受信したか否かを判断する。
ステップＳ１３１で受信した場合はステップＳ１３２へ進み、そのサービスマン用の携帯端末にメンテナンス情報を送信する。この送信方法としては、例えばメンテナンス情報を電子メール等に添付して送信したり、携帯端末のブラウザで閲覧可能なハイパーテキスト文書として送信したりする等が考えられる。
【００７５】
その後、次のステップＳ１３３へ進み、その携帯端末から通信の切断要求を受信したか否かを判断する。そして、受信していない場合にはステップＳ１３１に戻って処理をくり返し、受信した場合はステップＳ１３４へ進み、通信の切断処理を行って処理を終了する。
一方、ステップＳ１３１で閲覧要求を受信しない場合はそのままステップＳ１３３へ進み、上記と同様な処理を行う。
以上の処理において、管理装置１０２のＣＰＵは、ステップＳ１３２で送信手段として機能する。
【００７６】
この画像処理装置管理システムにおいては、このような処理を行うことにより、サービスマンが外出先などからでも携帯端末を用いて最新のメンテナンス情報を参照してメンテナンス予定日時を確認することができる。さらに、前述したメンテナンス予定日時の報知に対する所定の連絡先からの応答の情報から、メンテナンス予定日時における画像処理装置やユーザの予定、メンテナンスの必要性、その他要望事項等を事前に知ることができ、それに早く対応することができる。従って、メンテナンスのサービス性をさらに向上させることができ、サービスの効率が一層良くなる。
【００７７】
なお、ここではサービスマン用の携帯端末からの要求に応じてメンテナンス情報を送信する例について説明したが、この要求を待たずに、管理装置１０２側から各サービスマンの端末装置に担当顧客の装置に係るメンテナンス情報を送信する等してもよい。
また、管理装置１０２が、サービスマン用の携帯端末からメンテナンス情報に対する応答（例えばユーザおよび画像処理装置の予定とサービスマン自身の予定との両方を考慮した新しいメンテナンス予定日時の提案等）を受け付けて、その応答の内容に従ってメンテナンス情報を更新するようにしてもよい。このようにすれば、メンテナンス情報の更新を速く行なうことができるので、メンテナンスのサービス性をさらに向上させることができ、サービスの効率も一層よくなる。
さらにこのとき、更新されたメンテナンス情報を基にメンテナンス予定日時を再決定するようにしてもよい。そして、再決定したメンテナンス予定日時が画像処理装置１００に通知済みのメンテナンス予定日時と異なる場合は、新しいメンテナンス予定日時を画像処理装置に通知するようにしてもよい。
【００７８】
また、ここではこの発明を画像処理装置管理システムに適用した例について説明したが、この発明はこれに限られるものではななく、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた各種通信装置の管理システムに適用することも可能である。
【００７９】
【発明の効果】
以上説明してきたように、この発明による画像処理装置管理システムによれば、メンテナンス予定日時を事前に画像処理装置に通知して表示させることができるので、画像処理装置管理システムにおけるメンテナンスのサービス性を向上させることができ、サービスの効率をよくすることができる。
【図面の簡単な説明】
【図１】この発明による管理システムの構成の一例を示す概念図である。
【図２】図１に示した管理システムにおけるデータ送受モデルを示す概念図である。
【図３】この発明による画像処理装置管理システムの一実施形態の構成を示す概念図である
【図４】図３に示した画像処理装置の制御部の物理的構成を示すブロック図である。
【図５】図４に示した操作パネルの構成例を示す図である。
【図６】図３に示した画像処理装置のソフトウェア構成の一例を示すブロック図である。
【図７】図６に示したＮＲＳモジュールの構成の一例を示す機能ブロック図である。
【図８】図３に示した管理装置の概略構成例を示すブロック図である。
【図９】図３に示した管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の一例を示す通信シーケンスである。
【図１０】同じく、管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の図９とは異なる例を示す通信シーケンスである。
【図１１】図３に示した画像処理システム管理装置において、管理装置が画像処理装置にメンテナンス予定日時を通知する場合に各装置が実行する処理のフローを送受信されるデータと共に示した図である。
【図１２】同じく、画像処理装置が管理装置にメンテナンス予定日時の報知に対する応答を送信する場合の処理を送受信されるデータと共に示した図である。
【図１３】図３に示した管理装置がサービスマン用の携帯端末からメンテナンス情報の閲覧要求を受け付けた場合の処理を示すフローチャートである。
【符号の説明】
１０：被管理装置 １１：仲介機能付被管理装置
１００：画像処理装置 １０１：仲介装置
１０２：管理装置 １０３：インタネット
１１０：仲介機能付画像処理装置
２００：コントローラボード ２０１：ＨＤＤ
２０２：ＮＶ−ＲＡＭ ２０３：ＰＩボード
２０４：ＰＨＹ ２０５：操作パネル
２０６：プロッタ／スキャナエンジンボード
２１１：周辺機 ２１２：ＰＣＩ−ＢＵＳ
３００：ＯＣＳ ３０１：ＥＣＳ
３０２：ＭＣＳ ３０３：ＮＣＳ
３０４：ＦＣＳ ３０５：ＮＲＳ
３０６：ＳＣＳ ３０７：ＳＲＭ
３０８：ＩＭＨ ３０９：コピーアプリ
３１０：ファクスアプリ ３１１：プリンタアプリ
３１２：スキャナアプリ
３１３：ネットファイルアプリ
３１４：ウェブアプリ ３１５：ＣＳＳ
３１６：ＤＣＳ ３１７：ＵＣＳ
６０１：モデム ６０２：通信端末
６０３：プロキシサーバ ６０４：操作者端末
６０５：データベース ６０６：制御装置
Claims (3)
- 画像処理装置と通信可能な管理装置によって前記画像処理装置を管理する画像処理装置管理システムであって、
前記管理装置に、前記画像処理装置のメンテナンスに関する情報であるメンテナンス情報として、前記画像処理装置のメンテナンス予定日時の情報を記憶する記憶手段と、該手段により記憶しているメンテナンス予定日時より所定期間前になったときに該メンテナンス予定日時を前記画像処理装置に通知する通知手段とを設け、
前記画像処理装置に、前記管理装置から通知された前記メンテナンス予定日時を表示する表示手段を設けたことを特徴とする画像処理装置管理システム。 - 請求項１記載の画像処理装置管理システムにおいて、
前記画像処理装置に、所定の連絡先に対して前記管理装置から通知された前記メンテナンス予定日時を報知する報知手段と、前記報知に対する応答を受け付けてこれを前記管理装置に送信する手段とを設けたことを特徴とする画像処理装置管理システム。 - 請求項２記載の画像処理装置管理システムにおいて、
前記管理装置に、前記画像処理装置から受信した前記応答の内容に従ってメンテナンス情報を更新する更新手段と、サービスマン用の携帯端末に前記メンテナンス情報を送信する送信手段とを設けたことを特徴とする画像処理装置管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003142746A JP4133579B2 (ja) | 2003-05-20 | 2003-05-20 | 画像処理装置管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003142746A JP4133579B2 (ja) | 2003-05-20 | 2003-05-20 | 画像処理装置管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004348294A true JP2004348294A (ja) | 2004-12-09 |
| JP4133579B2 JP4133579B2 (ja) | 2008-08-13 |
Family
ID=33530718
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003142746A Expired - Fee Related JP4133579B2 (ja) | 2003-05-20 | 2003-05-20 | 画像処理装置管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4133579B2 (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006115338A1 (en) * | 2005-04-08 | 2006-11-02 | Lg Electronics Inc. | System and method for scheduling device management |
| JP2009218803A (ja) * | 2008-03-10 | 2009-09-24 | Kyocera Mita Corp | 延命管理装置、延命管理システム及び延命管理方法 |
| JP2014006915A (ja) * | 2007-08-10 | 2014-01-16 | Smiths Medical Asd Inc | 予防保守データの医療機器への送信 |
| JP2015225404A (ja) * | 2014-05-26 | 2015-12-14 | キヤノン株式会社 | 通信システム、情報処理装置およびその制御方法、並びにプログラム |
| JP2017154419A (ja) * | 2016-03-03 | 2017-09-07 | セイコーエプソン株式会社 | 記録装置、記録システムおよび記録装置のメンテナンス方法 |
-
2003
- 2003-05-20 JP JP2003142746A patent/JP4133579B2/ja not_active Expired - Fee Related
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006115338A1 (en) * | 2005-04-08 | 2006-11-02 | Lg Electronics Inc. | System and method for scheduling device management |
| JP2008532173A (ja) * | 2005-04-08 | 2008-08-14 | エルジー エレクトロニクス インコーポレイティド | 装置管理スケジューリングのためのシステム及び方法 |
| US7966365B2 (en) | 2005-04-08 | 2011-06-21 | Lg Electronics Inc. | System and method for scheduling device management |
| JP4805281B2 (ja) * | 2005-04-08 | 2011-11-02 | エルジー エレクトロニクス インコーポレイティド | 装置管理スケジューリングのためのシステム及び方法 |
| US8849992B2 (en) | 2005-04-08 | 2014-09-30 | Lg Electronics Inc. | System and method for scheduling device management |
| JP2014006915A (ja) * | 2007-08-10 | 2014-01-16 | Smiths Medical Asd Inc | 予防保守データの医療機器への送信 |
| EP3540741A1 (en) * | 2007-08-10 | 2019-09-18 | Smiths Medical ASD, Inc. | System for controlling medical devices |
| JP2009218803A (ja) * | 2008-03-10 | 2009-09-24 | Kyocera Mita Corp | 延命管理装置、延命管理システム及び延命管理方法 |
| JP2015225404A (ja) * | 2014-05-26 | 2015-12-14 | キヤノン株式会社 | 通信システム、情報処理装置およびその制御方法、並びにプログラム |
| JP2017154419A (ja) * | 2016-03-03 | 2017-09-07 | セイコーエプソン株式会社 | 記録装置、記録システムおよび記録装置のメンテナンス方法 |
| CN107150506A (zh) * | 2016-03-03 | 2017-09-12 | 精工爱普生株式会社 | 记录装置、记录系统以及记录装置的维护方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4133579B2 (ja) | 2008-08-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4019038B2 (ja) | 通信装置，通信装置の遠隔管理システム，通信装置の制御方法，およびプログラム | |
| US7586633B2 (en) | Image processing apparatus, and method of and system for managing image processing apparatus | |
| US9875240B2 (en) | Report creating system, report creating apparatus, and report creating method | |
| JP2005301999A (ja) | 遠隔管理システムとその被管理装置，通信制御方法，プログラム，および記録媒体 | |
| US20040133674A1 (en) | Remote management system, electronic apparatus, control method, and program that reduce communication costs in occurrence of abnormality | |
| US20040168109A1 (en) | Efficient remote management of devices by accurately removing abnormal condition reports | |
| JP4184247B2 (ja) | 管理装置、遠隔管理システム、およびプログラム | |
| JP4133579B2 (ja) | 画像処理装置管理システム | |
| JP4381839B2 (ja) | 電子装置とその遠隔管理システムおよびログ管理方法並びにプログラム | |
| JP4163550B2 (ja) | 遠隔管理システムとその仲介装置，管理装置，秘密情報設定方法，およびプログラム | |
| JP4347645B2 (ja) | 遠隔管理システムとその通信装置，制御方法，およびプログラム | |
| JP4809272B2 (ja) | 遠隔管理システムおよび管理情報取得制御方法 | |
| US11809754B2 (en) | Printing control system | |
| US20040158632A1 (en) | Recovery of interrupted communication for remote management of devices | |
| JP4744808B2 (ja) | 通信装置とその遠隔管理システムおよびプログラム | |
| JP4376811B2 (ja) | 遠隔管理システムとその管理装置 | |
| JP3958676B2 (ja) | 通信装置とその遠隔管理システムおよび異常送信時の制御方法並びにプログラム | |
| JP4767036B2 (ja) | 画像形成装置及びコンピュータプログラム | |
| JP2004295866A (ja) | 電子装置とその遠隔管理システムおよびログ管理方法並びにプログラム | |
| JP2004086033A (ja) | 遠隔管理装置 | |
| JP2008065780A (ja) | 機器、機器管理プログラム及び記録媒体 | |
| JP3549859B2 (ja) | 画像形成装置の管理システム、画像形成装置、プログラム及びコンピュータ読み取り可能な記録媒体 | |
| JP4298494B2 (ja) | 管理装置，遠隔管理システム，およびカウンタ監視型遠隔管理方法 | |
| JP2004208295A (ja) | 通信装置、通信装置の遠隔管理システム、通信装置の制御方法及びプログラム | |
| JP4339025B2 (ja) | 画像形成装置管理システムとその画像形成装置，画像状態判定通知方法，およびプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050707 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080116 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080205 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080404 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080513 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080602 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110606 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110606 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110606 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120606 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130606 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |