JP2011150588A

JP2011150588A - 管理システム

Info

Publication number: JP2011150588A
Application number: JP2010012195A
Authority: JP
Inventors: Hitoshi Sunada; 仁砂田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2010-01-22
Filing date: 2010-01-22
Publication date: 2011-08-04

Abstract

【課題】デバイスから管理装置に対し依頼を通知、その依頼を取消す通知が可能である場合、障害が発生していなくても管理装置側に依頼をかけることができる反面、ユーザが生成する通知情報であるためステータスの取り扱いに問題があった
【解決手段】従って、依頼通知に対するステータスの変更方法においてデバイスからの通知によりステータスを変更したのか、管理装置側で手動によりステータス変更したのかを判別しやすい仕組みを提供する。
【選択図】図１５

Description

本発明は、プリンタ等の画像形成装置の稼働状況を監視・管理する管理手法に関する。

従来の技術でネットワーク上に配置された監視サーバーによってプリンタの稼動状態または利用状態を監視し、監視対象への追加や削除、変更を容易にするといった技術が特許文献１に開示されている。故障通知に対しデバイスが一定時間後に正常動作している場合故障の取消通知をおこなう系が提案されているが、デバイスが検知できる状態の通知の仕組みについてのみ提案されているだけであった。また、取消通知によるステータス変更しか用意されていないため取消通知がくることが大前提となっていることと、異常が発生していないと利用できないためユーザの都合で通報する通知ボタン機能に対する通知取消には適用しがたいものがあった。

特開２００１−２５０００８号

先行技術では取消通知を自動判定でおこなう仕組みしか提案されていないため、通知が来ないと問題が発生しつづけていることは判断できるが、デバイスが検知できない障害などの通知には適用できない問題もあった。

修理依頼はユーザがいつでも監視会社に修理を依頼できる仕組みとして非常に便利である半面、機器で検知して通知する情報ではないため取消を自動でおこなうことができない。そのため修理依頼に対して自然に問題が解決した場合、監視会社からの電話対応にて問題が解決した場合、現地にエンジニアが派遣され、結果修理もしくは何も措置無しで解決した場合など様様な状態が存在する。

さらに修理依頼後問題が解決したことは人手でしか判別できないため、デバイスにおいては修理依頼がおこなわれた状態のまま放置されてしまうこともある。そのため管理装置側ではデバイスからの修理依頼取り消し、完了の通知に応じて自動的にステータス変更できる仕組みを導入するとともに、修理依頼の通知に対して電話対応など様様なケースに対応できるよう手動でステータス変更できる機能を用意している。修理依頼取消、修理依頼完了通知を表示させることでデバイスから通知されたことを知るようにできる。一方で取消、完了通知が修理依頼と時間が開いて通知される場合も有り沢山のデバイスからの通知情報を監視する場合、修理依頼通知とそれに対する取消、完了通知の両方を探すことが面倒である課題があった。

また、修理依頼通知後、何を起因にステータス情報が変更されたのかが容易に判断できないと次に行う措置の判断や、どの措置によって問題が解決したのかがわかりづらいといった課題があった。

上記課題を解決するために本発明の管理システムは、画像形成装置と該画像形成装置の稼動状態を監視する監視装置とから構成され、
前記画像形成装置は、稼動状態を取得する稼動状態取得手段と、稼動状態を通知する情報を生成する通知情報生成部と、前記管理装置に前記通知情報生成部により生成した稼動情報を通知する通知手段と、前記通知手段には前記画像形成装置の稼動状態以外に修理を依頼する修理依頼情報を生成する修理依頼生成手段と、前記修理依頼生成手段により生成した修理依頼情報を前記通知手段に依頼する修理依頼手段とを有し、
前記管理装置は、前記画像形成装置の通知手段によって通知される通知情報、修理依頼通知を受信する通知情報受信手段と、前記通知情報受信手段により受信した情報を解析する解析手段と、前記解析手段により修理依頼通知を抽出するとともに過去の修理依頼通知の状態情報に基づき状態情報を記録、更新する修理依頼状態情報更新手段と、修理依頼通知の情報表示要求に基づき前記修理依頼状態情報更新手段によって記録されている状態情報により検索方法を変更する修理依頼検索手段と、前記修理依頼検索手段の検索結果を表示する表示情報生成部とを有することを特徴とする。

本発明によれば対となる通知に応じてステータスを変更するため後で通知される取消、完了の通知情報を検索結果画面に表示する必要がなくなり修理依頼通知のみを参照すればよくなることで利便性が向上する。

デバイス管理システムの概要画像形成装置１０１の代表的なブロック図管理装置１０２、監視装置１０３、ＰＣ１０８の代表的なブロック図画像形成装置１０２における各処理のブロック図装置１０２、１０３、１０８における各処理のブロック図デバイス通知結果の表示例画像形成装置１０１の修理依頼通知画面（選択）画像形成装置１０１の修理依頼通知画面（通知状況）画像形成装置１０１の修理依頼通知画面（取消確認）画像形成装置１０１の修理依頼通知画面（完了通知）画像形成装置から通知される修理依頼コード、テーブルの例画像形成装置１０１からの修理依頼通知処理を表すフローチャートデバイス通知結果のステータス変更仕様、修理依頼通知情報テーブルの例管理装置１０２での修理依頼通知受信時の処理フローチャート管理装置１０２での修理依頼通知詳細画面の処理フローチャート修理依頼詳細画面（取消通知）の表示例修理依頼詳細画面（完了通知）の表示例修理依頼詳細画面（手動ステータス変更）の表示例

以下、本発明の情報処理装置及びその情報処理方法、並びに制御プログラムの実施の形態について、図面を参照しながら説明する。

［管理システムの全体構成］
図１は本実施例におけるデバイス管理システムの構成を表すブロック図である。

顧客環境１００には管理対象となる画像形成装置１０１と、それらを管理する監視装置１０３がネットワーク１０４を介して接続されており、画像形成装置１０１の監視情報をネットワーク１０４経由で監視装置１０３に通知する。画像形成装置１０１、監視装置１０３は、ネットワーク１０４、ゲートウェイ機器１０５を介してインターネット１０６に接続し、管理装置１０２と通信を行う。ゲートウェイ機器１０６はルーターやプロキシサーバー、ファイヤーウォールなどで構成される。

次に顧客環境１００の画像形成装置を管理する管理装置１０２の処理情報を元にサービスをおこなう監視会社１０７の環境について説明する。監視会社環境１０７には管理装置１０２の処理情報を閲覧、処理する情報処理装置１０８がネットワーク１０９に接続されている。情報処理装置１０８は、ネットワーク１０９、ゲートウェイ機器１１０を介してインターネット１０６に接続し、管理装置１０２と通信を行う。ゲートウェイ機器１１０はルーターやプロキシサーバー、ファイヤーウォールなどで構成される。

管理装置１０２について説明する。管理装置１０２はネットワーク１１１、ゲートウェイ機器１１２を介してインターネット１０６に接続し、画像形成装置１０１や女王処理装置１０８と通信を行う。ゲートウェイ機器１１２はルーターやプロキシサーバー、ファイヤーウォールなどで構成される。管理装置１０１は画像形成装置１０１またはそれを監視する監視装置１０３からの管理情報を受信し処理を行う。また前記画像形成装置１０１を複数台処理できるように、前記画像形成装置１０１に用意されているユニークな製造番号（以降管理番号とする）を用いて管理をおこない、それら管理情報を情報処理装置１０８に配信する。

また、監視装置１０３の監視機能は前記画像形成装置１０１のプログラムで実現できるため画像形成装置１０１に組み込むこともできる。本実施例では監視装置１０３経由での監視と画像形成装置１０１自身に監視装置１０３と同じ監視機能を実現できるため、以降監視装置１０３の説明は画像形成装置１０１の監視機能として説明をする。

［画像形成装置］
図２は、本発明の実施の一形態に係わる情報処理装置を備えた画像形成装置１０１の構成を示す図である。

画像形成装置１０１は例えば、デジタル複合機、ファクシミリ装置、レーザービームプリンタ、インクジェットプリンタ、スキャナー装置などの画像形成装置に適用することができる。画像形成装置１０１は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ハードディスク装置（以後ＨＤＤ）２０４、ネットワークインターフェース２０５、内部バス２０６、デバイス制御２０７、定着器などを含む印刷部２０８で構成される。

ＣＰＵ２０１はＲＯＭ２０３に格納されているプログラム（後述する図４の各処理を実現するプログラムも含む）を備え、内部バス２０６を介して各デバイスを総括的に制御する。ＲＡＭ２０２は、ＣＰＵ２０１のメモリやワークエリアとして機能する。ネットワークインターフェース３０５は、ローカルエリアネットワーク１０４を介して、外部のネットワーク機器或いはパーソナルコンピュータ（ＰＣ）と片方向または双方向にデータをやりとりし、デバイス制御２０７は印刷部２０８を制御する。ＣＰＵ２０１は、ＲＡＭ２０２やＲＯＭ２０３とともにプログラムの実行処理をおこなうとともに、ＨＤＤ２０４等の記録媒体に画像データを記録する処理を行う。ＨＤＤ２０４は外部記憶装置として機能し、画像データ等を記憶するほか、前記バックアップＲＡＭ２０２に代えて、上記のカウンタ情報、システム情報及び監視情報を保存することも可能である。前述したように監視装置１０３の機能をプログラムとしＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４で代替することができる。

［管理装置］
図３は、本発明の実施の一形態に係わる情報処理装置を備えた管理装置１０２の構成を示す図である。管理装置１０２は、例えば、ＰＣ、サーバーなどの情報処理装置に適用することができる。

管理装置１０２は、ＲＯＭ３０３に格納されているプログラム（後述する図５の各処理を実現するプログラムも含む）を実行するＣＰＵ３０１を備え、内部バス３０６を介して各デバイスを総括的に制御する。内部バス３０６には、ＲＡＭ３０２、ＲＯＭ３０３、ＨＤＤ３０４、ネットワークインターフェース３０５の各デバイスが接続されている。

また入出力インターフェース３０７、例えばＰＳ２やＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ（ＵＳＢインターフェース）、アナログやデジタルのディスプレイインターフェースを備える。キーボードやマウス、ＣＲＴや液晶装置の入出力装置３０８は入出力インターフェース３０７を介して接続することができ、管理情報の登録・設定や処理情報の参照をすることができる。ネットワークインターフェース３０５は、ローカルエリアネットワーク１１２、ゲートウェイ機器１１１を介してインターネット１０６に接続し、画像形成装置１０１や監視装置１０３、情報処理装置１０８と通信を行うことができる。ゲートウェイ機器１０６はルーターやプロキシサーバー、ファイヤーウォールなどで構成される。ＣＰＵ３０１は、ＲＡＭ３０２やＲＯＭ３０３とともにプログラムの実行処理をおこなうとともに、ＨＤＤ３０４等の記録媒体に画像データを記録する処理を行う。ＨＤＤ３０４は外部記憶装置として機能し、画像形成装置の管理情報を記憶するほか、前記バックアップＲＡＭ３０２に代えて、システム情報及び処理情報を保存することも可能である。

情報処理装置１０８も、管理装置１０２と同様にＰＣ、サーバーなどの情報処理装置に適用することができるため、ネットワーク１１２を１０９に、管理装置１０２の構成を１０８に置き換えることもできる。入出力装置３０８は外部機器として説明したが、もちろん管理装置１０２や情報処理装置１０８にハードウェアとして内蔵されていても良い。

［画像形成装置のソフトウェアモジュール構成］
図４の４００は画像形成装置１０１の稼動状態を処理するソフトウェアモジュールの構成を示している。図中４００の４０１から４０７が画像形成装置１０１のソフトウェアモジュールに該当し、ＨＤＤ２０４に格納され実行時にＲＡＭ２０２に展開しＣＰＵ２０１にて処理をおこなう。

稼動状態監視処理部４０１では、通信処理部４０２を介してネットワークインターフェース２０５、ネットワーク１０４に接続して通信することができる。通信処理部４０２は稼動状態監視処理部４０１からの指示に従い、管理装置１０２への通知情報の送信や、逆に管理装置１０２からの応答を受信する。記録処理部４０３はＲＡＭ２０２，ＲＯＭ２０３，ＨＤＤ２０４の記録領域と情報のやりとりをおこなう。稼動状態監視処理部４０１で処理した情報をＨＤＤ２０４に記録したり、ＲＯＭ２０３に格納されている設定情報を取得したりする。稼動状態取得部４０４はデバイス制御２０７より利用枚数を示すカウンタや、部品の使用状況を示す部品カウンタ、その他利用状況を示す機能カウンタのほか、ジョブの処理状況や障害情報を取得する。稼動状態監視処理部４０１は必要に応じてデバイスの稼働状況を取得や、稼動状態取得部４０４に稼働状況に変更が発生した場合に通知するよう指示することもできる。障害情報の具体例としては障害情報としては、ハードディスクエラーや温度上昇や内部通信遮断などのハードエラーや、紙ジャム等のエラー、或いはトナー切れ、或いはドアオープン、排紙トレイの紙積載超過などのユーザが回避できるものも含むものとする。また、デバイス管理部はデバイス制御２０７で取得可能な情報だけでなく、通信処理部４０１、デバイス監視部４０３、設定処理部４０４で取得可能な情報も前記通信データとして扱うことができる。それら情報を管理装置に送信する際、画像形成装置固有または設定情報（ＩＰアドレス、ＭＡＣアドレス、デバイスシリアル番号、製品名、製品タイプなど）も一緒に送信することで、管理装置１０２は画像形成装置単位で判別、個別の処理を行うことができる。入出力処理部４０５は入出力装置２０９であるキーボード、マウス、ディスプレイを制御し画像形成装置の設定や状態を確認するためのインターフェースとなっている。修理依頼管理部４０６は顧客環境１００のユーザが管理会社１０７に対し任意に修理依頼をおこなう機能の処理を司る。修理依頼の実現方法として例えば表示パネルに画像形成装置１０１の通信データを送信するためのボタンを表示し、画像形成装置１０１の操作パネルにあるキーをイベントにして管理装置１０２に対し通信データを送信させることができる。詳細は後述するがこれにより、画像形成装置１０１で検知できない状態を管理装置１０２に通知することができる。例えば、センサーが備えられていない部位の異常を管理装置に通知することができる。具体例としてセンサーが検知レベルとして設定している閾値に達するまえにユーザが異常と認識して通知をおこなうことができるようになる。特に紙詰まりが頻繁に発生した場合や、画像の印刷結果が色ずれやかすれによりユーザの期待を下回った場合などがよくある例である。修理依頼管理部４０６は稼動状態取得部４０４が取得する画像形成装置１０１の稼動状態を管理装置１０２に通知するのと同じく、稼動状態を通知する通信において修理依頼情報を付加することで実現する。通知情報生成部４０７では前記修理依頼管理部４０６は稼動状態取得部４０４からの要求に対して、画像形成装置１０１の稼働状況、たとえば障害情報なのか修理依頼であるかに基づき通信処理部４０２を介して送信するための通知情報の生成を行う。ここで、前記通信データに含まれる画像形成装置１０１の監視情報は通信処理仕様に基づき必要に応じて加工処理されるため、管理装置１０２において処理することができる。通信処理仕様はＲＯＭ２０３、ＨＤＤ２０４に予め格納されているものとする。送信においては稼動状態監視処理部４０１からの情報、指示を受け、所定の通信処理仕様に基づく通信データを送信するだけでなく管理装置１０２からの受信情報により通知に成功、失敗したかを判断する。

［管理装置のソフトウェアモジュール構成］
図５の５００は管理装置１０２のソフトウェアモジュール構成を示す図である。

図中の５０１から５０９が管理装置１０２のソフトウェアモジュールに該当し、ＨＤＤ３０４に格納され実行時にＲＡＭ３０２に展開しＣＰＵ３０１にて処理をおこなう。通信情報管理処理部５０１は管理装置１０２において画像形成装置から通知される通知情報を判断、加工、記録などの処理を司る処理部である。通信情報管理処理部５０１は通信処理部５０２、記録処理部５０３、検索処理部５０４、表示情報生成部５０５、入出力処理部５０６、通信情報生成部５０７、通知判定処理部５０８、修理依頼状態処理部５０９を制御する。通信処理部５０２はネットワークインターフェース３０５を介してネットワーク１１１に接続し、画像形成装置１０１や情報処理装置１０８からの通知や要求を受け付けることができる。通信処理部５０２では、通信情報管理処理部５０１からの情報、指示を受け、所定の通信処理仕様に基づく通信データを送信、または受信処理をおこなう。処理した通知情報は履歴として記録処理部５０３を介してＲＯＭ３０３、ＨＤＤ３０４に格納する。格納した情報は検索処理部５０４により履歴検索し、表示情報性西部５０５によって表示可能な情報に変換され参照することができる。入出力装置３０７のキーボード、マウス、ディスプレイに表示を行う場合は入出力処理部を介して表示可能なフォーマットに変換して表示を行う。監視会社の環境にある情報処理装置１０８が画像形成装置の情報を参照するためにインターネット経由で接続することがあるため、ブラウザで処理が可能なＨＴＭＬフォーマットに変換する。ＨＴＭＬフォーマットに限らず表示する機器に合わせた別のフォーマットを用意できることはいうまでもない。前記情報処理装置１０８がＨＴＭＬフォーマット情報を参照するために、通信処理部５０２にはＷＷＷサーバーの機能を設けている。また、記憶領域に格納された通知情報は履歴として参照できるだけでなく、通知情報に対して監視会社が管理情報や備忘録として実施した状態を情報として追加、更新することもできる。追加、更新する仕組みは次の通り。通信処理部５０２、または入出力処理部５０６のいずれでも良いが既に記録されている通知情報の履歴に対し、状態の情報を追加、更新する要求を行う。通知情報管理処理部５０１は通信処理部５０２、または入出力処理部５０６からの要求を受け記録処理部５０３を介して状態情報を追加し、更新する。変更された情報は履歴情報として先に説明した表示方法を用いて参照、確認することができる。通信処理部５０２経由で要求する方法は、前記情報処理装置１０８に対して提供したＨＴＭＬフォーマットの応答として要求を受信したり、前記画像形成装置１０１の通知情報を要求と見なして状態情報を更新したりすることもできる。これらの処理により監視会社１０７では、管理装置１０２が通知され処理された情報を元に画像形成装置１０１の故障や、ユーザが管理装置１０２に通知したことを知ることができるだけでなく修理が必要であればエンジニアを派遣したりすることができる。更に、管理装置で処理された情報にユーザや画像形成装置１０１の状態情報を記録することで、発生した障害や措置の状態を管理することができる。

状態情報を管理する方法については後述する。通信解析処理部５０７は画像形成装置１０１からの通知情報に含まれる情報を解析し、画像形成装置を特定するシリアルナンバーなどの情報や稼働状況や修理依頼などを意味するコードを特定し、解析情報を通知情報管理処理部５０１に渡す。通知情報管理処理部５０１は渡されたシリアルナンバーより記録処理部５０３経由で登録されている画像形成装置であるかを確認する。登録されている場合コードを元に処理を開始する。コードが修理依頼に該当するコードである場合、通知判定処理部５０８にて修理依頼処理の判断をおこなう。後述するが修理依頼には複数のコードを定義していることと、前回通知済みの修理依頼の措置状況も処理分岐の条件とするため通知判定処理部５０８は修理依頼状態処理部５０９に措置状況を問い合わせる。

修理依頼状態処理部５０９は措置状態の問い合わせに対し、通知情報管理処理部５０１、記録処理部５０３経由で記録されている修理依頼の状態を問い合わせ、決められた分岐条件に基づき修理依頼に対する処理を行う。

［管理装置が提供する画面の例］
図６では図５の通信処理部５０１が情報処理装置１０８に提供している画面の例について説明する。図６では管理装置１０２が監視対象としている画像形成装置１０１（単数もしくは複数）から通知された管理情報の処理結果を表示する通知情報画面６０１と通知情報画面に表示されるアイコン例６０２をあらわしている。

通知情報画面６０１は画像形成装置１０１から通知された情報のうち、製品名、製品ＩＤ（ここではシリアルナンバーとしている）、受信日時、通知内容、各通知の詳細情報を表示する詳細画面への詳細ボタンを表示する。表示は最初アクセスした際、新しい通知情報を上に表示し、古い通知情報ほど下に表示するようになっている。製品ＩＤはシリアルナンバーを指し画像形成装置１０１から通知され、予め管理する対象として記憶領域であるＲＯＭ３０４，ＨＤＤ３０５に登録されているシリアルナンバーと製品名情報を結び付けて表示している。また、受信日時は管理装置１０２が管理情報を受信した時点での日時（年月日時分）を表示する。ＨＴＴＰ通信などの通信方式を用いた場合はこれでよいが、ＳＭＴＰなど遅延の可能性を含む通信方式を採用した場合は、画像形成装置１０１が送信する時点での日時を適用することで発生時間の順番を適切なものにすることができる。通知内容は情報を参照する人が容易に通知のカテゴリを知ることができる情報である。図６の例では紙詰まりが頻繁に発生したことを示す「ジャム多発」や、画像形成装置としては検知できていないがユーザが異常と判断し通知してくる修理依頼の通知をあらわす「修理依頼」、障害をあらわす「エラー」がある。各通知は２行で表現され、図６の一番上の通知情報を例にとると、ＣＰ３００というシリアルナンバーの画像形成装置１０１から２００９年の１１月１２日、１５時３２分に紙詰まりが頻繁に発生したことを示す通知があったことを示す。どこで紙詰まりが発生しているかを知るためのコード情報、例では０９０００１（予備コード００００００００）もあわせて表示され、情報処理装置１０８で参照した画像形成装置１０１のどの部位で紙詰まりが頻繁に発生しているかを知ることができる。

更に、各通知の先頭にはステータス領域を設けており、まだ通知しか行われていなくて何も対応措置を取っていない場合は未対応、例のように「対応済み（電話）」とあれば、ユーザに電話で指示をして解決した場合を指している。その他６０２のアイコンのように、予め記憶領域ＲＯＭ３０４，ＨＤＤ３０５に通知された情報に対する対応についてアイコン表示を切替える情報をもたせることで、アイコンを切替える。例えば修理依頼通知の場合は修理依頼通知アイコン、障害（エラー）であってもユーザに電源のオフ、オンをしてもらうことで対応可能な障害は電話対応アイコンにしたりすることができる。同様に現地にエンジニアを派遣して故障した部品を交換する必要がある障害について現地修理が必要なアイコンを表示させたりすることができる。アイコンの切り替えはコード情報と一緒にＲＯＭ３０３、ＨＤＤ３０４にアイコン表示を切り替える情報を持たせることで実現する。

例では修理依頼はユーザが意識的に通知してきた情報としてコード情報のフィールドを色付けして目立たせている。これにより情報処理装置１０８を参照している監視会社は容易に通知された修理依頼情報を見つけることができる。

［画像形成装置の修理依頼通知機能の例］
図７〜１２を用いて画像形成装置１０１から管理装置１０２に対し修理依頼通知を行う流れ、仕組みについて説明する。図７〜１０は画像形成装置の入出力制御２０９を用いて表示、操作をおこなう例をあらわしている。図１１は修理依頼通知の種類および通知内容、図１２は各画面の操作順、流れについて説明している。

図１２の修理依頼通知処理は画像形成装置１０１を利用しているユーザが図７の修理依頼画面を要求したところから説明する。

Ｓ１２０１は修理依頼画面である図７修理依頼／取消画面７０１の要求があるかないかを判定する。ユーザは修理依頼通知を行う際、専用の画面を呼び出して操作させるためにこの画面を用意している。Ｓ１２０１にて要求がない場合、修理依頼／取消画面７０１が呼び出されることはない。次にＳ１２０１にて要求があった場合、修理依頼管理部４０６が修理依頼画面を入出力処理部に依頼するまえにすでに修理依頼状態にあるかをＳ１２０２にて判断する。修理依頼は画像形成装置において同時に複数通知することができず、通知中の修理依頼が存在する場合は通知中であることを示すことを知らせる必要がある。修理依頼通知状態は記憶領域ＲＯＭ２０４，またはＨＤＤ２０４に格納されており、修理依頼の処理内容に応じて状態を変更、更新する。修理依頼状態を記録処理部４０３経由で取得しＳ１２０３またはＳ１２０６に進むかを判断する。

Ｓ１２０２にて修理依頼通知状態を確認した結果、通知中の修理依頼がないと判断した場合、Ｓ１２０３に進み入出力制御２０９にて修理依頼／取消画面７０１を表示する。修理依頼／取消画面７０１には修理依頼操作をやめるための閉じるボタン７０６を用意し、閉じるボタンを押下することでＳ１２０１の処理に戻るようになっている。修理依頼の通知内容として画像不良７０２、紙詰まり７０３、その他動作不良７０４のボタンを用意している。各ボタンは一度押下すると反転し選択状態となり、もう一度押下すると非選択状態に戻る。１つ以上ボタンが選択されている状態で管理装置１０２に修理依頼通知をおこなう依頼するボタン７０５が押下できるようになっている。画像不良７０２、紙詰まり７０３、その他動作不良７０４のボタンは複数選択にすることができ、１コードで１個から最大３個の修理依頼情報を通知することができる。各ボタンの選択状態の組合せに対する、管理装置１０２への通知情報コードを図１１に示す。修理依頼の通知情報コードは３７０００１から３７０００７までの７種類ある。

Ｓ１２０３にて修理依頼通知する内容を選択後、Ｓ１２０４依頼するボタンを押下することで管理装置１０２への通知処理を開始する。画像形成装置１０１では修理依頼コードテーブルのうちコード、コードの説明にある情報をＨＤＤ２０４に記録していて、通知の目的に合わせてコードを選択する。また、管理装置１０２にはコード、コードの説明の他アイコン情報、メッセージとして表示するためにメッセージ情報（文字列）をテーブルとしてＨＤＤ３０４に格納している。アイコンの情報については前述のように修理依頼アイコンを表示する場合は３を定義しておく。ゼロにすると対象となるアイコンがないとしてアイコンは表示しない。

Ｓ１２０４では修理依頼管理部４０６が通知情報生成部４０７に対し選択されている通知ボタンにあわせてアラームコード表１１０１のコードを生成するように依頼する。通知情報生成部４０７は生成した修理依頼の通知情報を通信処理部４０２経由で管理装置１０２に通知する。Ｓ１２０５では管理装置１０２に対する修理依頼通知が適切におこなわれたかを判断する。ネットワークの不具合や、画像形成装置の都合、または管理装置１０２の不具合により修理依頼通知が成功しない場合を想定している。通知が成功した否かは稼動情報監視処理部４０１が検知し、失敗の場合は入出力処理部４０５を介してエラーメッセージを表示し、修理依頼前の元のＳ１２０１に戻る。メッセージは通知できない理由を詳細に伝えても良いし、別の手段（例えば電話やメール）にて監視会社に連絡するよう促しても良い。Ｓ１２０５にて管理装置１０２への通知が成功した場合、Ｓ１２０６に進む。

Ｓ１２０６では図８の修理依頼／取消画面８０１を表示し、管理装置への修理依頼通知が成功した旨を表示する。同時に修理依頼管理部４０６は記録処理部４０３に修理依頼通知状態を記憶領域に記録する。その際、通知した日時および通知内容、例えば画像不良のみを通知したことを画面に表示する。実施例では８０２にあるように画像不良の文字領域の色を変えることで画像不良の修理依頼をおこなったことをあらわしている。先に説明した通り、修理依頼は画像形成装置毎に同時に１通しか通知できないため、修理依頼ボタンを用意する画面を呼び出す修理依頼へボタン８０３は選択できないようになっている。また、この画面では依頼取消８０４、閉じるボタン８０５を用意している。

Ｓ１２０７では修理依頼通知を取り消す依頼取消８０４ボタン、通常の画像形成装置利用に戻るための閉じるボタン８０５の判断処理をおこなう。前述の修理依頼通知と同様に修理依頼管理部４０６、通知情報生成部４０７にて修理依頼取消の通知情報を生成し通知を行う。

まず、閉じるボタン８０５を押下した場合について説明する。ユーザは修理依頼の内容を確認し監視会社からの連絡、もしくは修理をまつことになれば閉じるボタン８０５を押下して画像形成装置１０１を印刷やスキャンができる状態、またはそれら処理を表示する画面に戻す。次のような場合、ユーザが修理依頼通知を取り消す場合がある。修理依頼通知の内容が足りなかった、または多かった、もしくはユーザ環境の担当者により問題が解決し、監視会社の手を借りる必要なくなった場合などが該当する。

修理依頼の内容を変更するには一度修理依頼通知を取り消す必要があるため、ユーザは依頼取消ボタン８０４を押下する。取消ボタンが押下されると、Ｓ１２０８にて図９の依頼取消しても問題がないかを確認する画面９０１を表示する。「いいえ」ボタン９０３を押下すると何もしないで図８の修理依頼／取消画面８０１に戻る。「はい」ボタン９０２を押下すると通知時と同様にＳ１２０９にて管理装置１０２に対し正しく修理依頼の取消が通知されたかを確認する。取り消しの通知に失敗した場合、Ｓ１２１１に進みユーザに対し修理依頼取消の通知が失敗したことを示すメッセージを表示し、修理依頼前の元のＳ１２０１に戻る。メッセージは通知できない理由を詳細に伝えても良いし、別の手段（例えば電話やメール）にて監視会社に連絡するよう促しても良い。取り消しの通知が成功するとＳ１２１０にて前記修理依頼が取り消され、修理依頼が行われていないことを記憶装置ＲＯＭ３０４，またはＨＤＤ３０５に記録する。修理依頼取り消しでは図１１の修理依頼取消ボタン押下をあらわす３７１０００のコードが管理装置１０２に通知され、管理装置１０２では修理依頼が取り消されたことを把握できる。

ここまでの説明において、顧客環境のユーザが操作できる画面について説明した。実際の運用では修理依頼通知ただしく取り消されることが保証されないことがある。またエンジニアが現地で作業した場合の修理通知の通知方法を管理装置１０２にて切り分けられるようエンジニアが現地から管理装置１０２に対し修理依頼の取消、作業の完了を通知するために修理依頼完了のコード３７２０００を用意している。このコードはユーザが送信できないように特殊な画面（例えば管理会社が管理するメニューにパスワードを設ける、エンジニア専用の画面に用意し、特殊な操作をしないと選択できない）から通知できるように画像形成装置１０１に備えておく。これは現地にエンジニアが出向き画像形成装置１０１を修理することにより障害が解決した場合や、現地で確認した結果問題が無いことが判明したが、当然修理依頼が通知中になっているため解除する方法が必要である。エンジニアはユーザが操作できない完了通知をおこなうことで、管理装置１０２ではエンジニアが現地で問題解決、確認作業を行ったことを把握することができる。

図１０の修理依頼完了通知画面１００１では、完了ボタン１００２を押下することで管理装置に１０２に修理依頼の完了通知を送信することができる。同時に通知に成功した場合、修理依頼の通知状態を通知中から通知なしの状態に戻す。これにより以降、ユーザが再び修理依頼を行うことができる。修理依頼完了通知画面１００１の閉じるボタン１００３はエンジニアが完了通知をおこなわない場合のために用意している。

［修理依頼通知処理］
画像形成装置１０１からの修理依頼通知の仕組みについて説明祖してきたが、次に管理装置１０２の修理依頼通知処理について説明をする。図１３は図６で説明したステータス項目を変更できる条件について説明している。図１４、図１５は修理依頼通知を受信した時の処理を表すフローチャートである。図１６〜１８は図１３〜１５の処理により情報処理装置１０８にてどのように表示させるかをあらわしたものである。

まず図１３を用いて、図６で説明したステータスの変更方法について説明する。図１３は修理依頼通知におけるステータスの変更仕様と、管理装置１０２が修理依頼通知の履歴として記録するテーブル１３０２について説明している。

図６の通知情報画面６０１でステータスの一例について説明をしているが、具体的には図１３のステータス種を用意している。それぞれのステータスには数字が定義されておりテーブルにはステータスに合わせて数字を格納する。通知情報に対するステータスとしては未対応、対応中、対応済み（電話）、対応済み（ディスパッチ）、対応不要の５種類を用意している。修理依頼に限らずステータスは同じ意味をもつが、ここでは修理依頼を例に説明を行う。未対応は図１１の修理依頼通知コード３７０００１から３７０００７の修理依頼要求が通知され、管理装置１０２にて受信、格納処理が行われた後に監視会社により要求のあった画像形成装置に対しなにも措置を講じていないことを表している。監視会社はユーザに電話をしたり、エンジニアを派遣するなど何らかの措置を講じた際にステータスを手動で変更し、その状態を参照することで２重に電話をするのを防止したり、作業状況を把握、管理するために利用する。対応中は、前述のように電話での対応や、エンジニア派遣をしていることを表している。ただし、対応はしたが現地での問題が解決できていなかったりエンジニア派遣の結果修理に必要な部品の持ち合わせがなく、次回訪問に解決予定であったりするものも含まれる。それらステータスに対し対応済み（電話）、対応済み（ディスパッチ）は電話対応もしくはエンジニアの派遣により現地での問題が解決した状態を表している。対応済み（電話）はあくまで人為的な状態を指し、電話で対応したユーザが利用上問題無くなった、もしくはこれ以上の対応は不要であると伝えたことを表すものであって、画像形成装置１０１からの通知情報とは連動していない。対応不要はユーザが修理依頼の通知をおこなったにも係らず、その後ユーザが修理依頼の要求を取り下げた場合を表している。他の対応済みステータスと異なり監視会社側では何も対処をしていないことになる。ユーザが画像形成装置１０１より修理依頼取消通知を行った場合、または監視会社に電話やメールなどで対応しなくても良い旨を伝えてきた場合もこの状態にする。

続いてステータスを変更する仕様、条件について説明する。未対応、対応中、対応済み（電話）、対応済み（ディスパッチ）、対応不要の５種類については全て手動で変更することができるようになっている。

一方、画像形成装置１０１からの修理依頼通知によって自動的に変更されるステータスが対応済み（ディスパッチ）と対応不要の２種類である。対応済み（ディスパッチ）はステータスが未対応の場合に画像形成層装置１０１からの修理完了通知を受信した場合にのみ未対応から変更される。修理依頼完了通知を受ける前に手動にて未対応以外のステータスに変更されていた場合は、ステータス変更処理をおこなわない。対応不要はステータスが未対応の場合に画像形成層装置１０１からの修理完了通知を受信した場合にのみ未対応から変更される。修理依頼完了通知を受ける前に手動にて未対応以外のステータスに変更されていた場合は、ステータス変更処理をおこなわない。

次に図１４、図１５のフローチャートと処理の結果どのような表示になるかを図１６〜１８の表示例を用いて説明する。

図１４は管理装置１０２が画像形成装置１０１から修理依頼通知を受信して処理する流れを説明するものである。

管理装置１０１はＳ１４０１にて修理依頼通知を受信する。修理依頼通知であるか否かは前述のコードを元に判定している。通信処理部５０２が画像形成装置１０１からの通知を受信すると通信解析処理部５０７にて修理依頼の通知であるかを判断する。Ｓ１４０２では修理依頼通知を受信すると修理依頼情報テーブル１３０２の処置に記録されている情報を参照し、新規の修理依頼通知として処理するか否かを判断する。処理には対象０、対象外１が記録されていて過去に修理依頼の取消通知または修理依頼の完了通知を受信しているか、もしくは手動にてステータス変更が行われている場合を意味している。処置がゼロの場合、Ｓ１４０３にすすみステータスを未対応として処理する。この処理は前記モジュールの通信情報管理処理部５０１がコードの判断、未対応ステータスとする判断をおこない、記録処理部５０３経由で記録装置であるＨＤＤ３０４などに格納する。

Ｓ１４０４では格納された修理依頼の通知情報のステータス変更処理について判断するステップであり、修理依頼状態処理部５０９にて処理する。Ｓ１４０３までの処理の場合、ステータスは未対応であるため、図６の修理依頼通知のステータス項目にあるように未対応として表示される。これは修理依頼がされたことにより監視会社において何も措置を講じていない状態を意味している。未対応であることから電話対応するのか現地にエンジニアを派遣するのか等を判断してステータスを変更する。Ｓ１４０４のステータス変更ステップは通知判定処理部５０８が通信処理部５０２、通信解析処理部５０７により画面からの手動変更であるか、修理依頼取消／完了通知であるかを判断した結果をうけ判定する。

なにも要求がない場合はＳ１４０５で待機する。

Ｓ１４０５にて画像形成装置１０１からの修理依頼取消または修理依頼完了の通知の場合修理依頼取消か修理依頼完了かを判断する。Ｓ１４０５にて修理依頼完了通知と判断するとＳ１４０６にて修理依頼情報テーブル１３０２の変更情報を１に変更すると共に、ステータスを３とし表示要求があった際には対応済み（ディスパッチ）と表示する。また、修理依頼取消の場合Ｓ１４０７にて修理依頼情報テーブル１３０２の変更情報を１に変更すると共に、ステータスを４とし表示要求があった際には対応不要と表示する。画像形成装置１０１から修理依頼取消通知または修理依頼完了通知のいずれかでステータス変更できるものは対応済み（ディスパッチ）と対応不要に限っている。限ってはいるが修理依頼完了通知の場合、現地に派遣されたエンジニアが修理完了をもって通知してくる通知であるため対応済み（ディスパッチ）のステータスにしか変更できなくても正しい措置となる。

また、修理依頼取消通知は修理依頼をおこなったデバイスからユーザが別の修理依頼をしたい場合や、または取消をしたいために通知してくる通知であるため対応不要とし、新たな修理依頼に対し措置を講じるもしくは対応不要とするのも正しい措置となる。

Ｓ１４０４にて手動変更であると判断した場合未対応のステータスから変更できるステータスは図１３のデバイスからの通知による変更対象、手動変更の対応表に従う。手動でのステータス変更は未対応のステータスから他のどのステータスにも変更ができる。これは監視会社の都合で細かいステータス状態に変更することにより措置の状況を把握しやすくするための機能である。

次に図１５を用いて修理依頼通知のステータス変更をおこなった要因が何であるかを表示する処理について説明する。

図１４で説明したように修理依頼は手動でもステータス変更ができるし、画像形成装置１０１からの要求によっても変更ができる仕組みになっている。前述したように、色々な事情により手動によるステータス変更が好ましい場合もあるため融通が利く。一方、ステータスを変更した要因が特定できないことによりどのような措置をしたのかが分かりにくい場合もある。画像形成装置１０１からの取消や完了の通知を図６の通知情報画面に１通知として表示させる方法もある。しかし、最初の通知情報と離れて表示されることも大いに予想され、手動でステータス変更されたにも係らず取消や完了の通知がおこなわれる場合もあるため必ずしも分かりやすいとはいえない。当然、取消や完了の通知がすぐにこなければ期間が離れてしまうため探すのも大変であることは言うまでもない。

図１５のフローチャートは修理依頼通知の詳細画面を説明するため、先に図１６の障害情報の詳細（修理依頼）画面１６０１を呼び出した時の表示画面を説明する。障害情報の詳細（修理依頼）画面１６０１は大別して、修理依頼対応ステータス設定領域１６０４、通知履歴領域１６０９から構成される。修理依頼完了／取消状況表示領域１６０２には画像形成装置が通知してきた日時は発生日時１６０５に表示する。コード１６０６、詳細１６０７、カウンタ１６０８には修理依頼取消通知または修理依頼完了通知として通知されたコード情報、カウンタ情報を表示し、コードに基づき予めＲＯＭ３０３，ＨＤＤ３０４に格納されているメッセージを表示する。同様に通知履歴領域１６０９も詳細情報を要求した修理依頼通知を一番上に表示し、それより古い履歴情報を検索した結果を表示する。表示する情報である発生日時、コード、詳細、カウンタは修理依頼完了／取消状況表示領域１６０２と同じくそれぞれ通知してきた情報を表示している。なお発生日時は検索および表示において利用し、障害情報の詳細（修理依頼）画面１６０１においては詳細を選択した任意の修理依頼と、その修理依頼通知より前に通知されている通知情報を順に表示する。これにより情報処理装置１０８を用いて画像形成装置１０１を管理している監視会社は選択した修理依頼通知より前に通知された障害などの状況を時系列に把握することができる。

最後に画面下部にはステータス選択ラジオボタン群１６１０、ステータス保存ボタン１６１１を儲け細かくステータスを設定、更新する仕組みを用意している。ステータス選択ラジオボタン群１６１０には図１３で説明したステータスを用意し、ステータス保存ボタン１６１１にて設定を更新することができる。

Ｓ１５０１では図６の修理依頼通知の詳細ボタンが押されたときの処理について説明する。Ｓ１５０１は詳細ボタンが押下されることで、前述の通信情報管理処理部５０１が詳細画面を記録処理部５０３、検索処理部５０４、表示情報生成部５０５に要求して表示情報を準備し、情報処理装置１０８などに返す。Ｓ１５０２では詳細情報を指定した修理依頼のステータスを判断して処理を切り分ける。

最初にステータスが手動によって変更されている場合について説明する。手動で変更されている場合、Ｓ１５０３により検索処理部５０４がいま選択されている修理依頼通知より古い通知情報の履歴を検索して情報を収集する。さらに図１８の修理依頼完了／取消状況の領域に手動でステータス変更されたことを表すために発生日時、コード、カウンタにＮ／Ａを表示する。これは通知がないため何も表示する情報がないということをＮ／Ａで表している。詳細には手動で変更されたことを表す手動ステータス変更のメッセージを表示する。これによりこの修理依頼は手動でステータスが変更されたことを知ることができる。

次に画像形成装置１０１から修理依頼取消通知、または修理依頼完了通知が通知されている場合について説明する。Ｓ１５０５では画像形成装置からのステータス変更があったことを判断して手動のときと同様に検索処理部５０４がいま選択されている修理依頼通知より古い通知情報の履歴を検索して情報を収集する。続いてＳ１５０６にて修理依頼完了／取消状況の領域に画像形成装置１０１から通知された取消、または完了の通知を表示するために修理依頼通知より未来の履歴を検索する。

Ｓ１５０７では図１６、図１７の表示例に有るように修理依頼完了／取消状況の領域に画像形成装置１０１からの通知によってステータス変更されたことを表すために発生日時、コード、カウンタに該当する通知情報を表示する。詳細には、修理依頼取消通知の場合修理依頼が取り消された棟のメッセージを、修理依頼完了通知の場合は図１７のように修理依頼完了通知である旨のメッセージを表示する。

最後にステータスが未処理の状態で詳細ボタンが押された場合について説明する。この状態は手動でも画像形成装置１０１からのどちらからも変更要求がなかったことをあらわすため、詳細画面の修理依頼完了／取消状況の領域には何も表示することがないため発生日時、コード、詳細、カウンタ全てにＮ／Ａを表示する。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

画像形成装置と、その画像形成装置の稼動状態を監視する監視装置とから成る管理システムにおいて、
前記画像形成装置は、
稼動状態を取得する稼動状態取得手段（４０１）と、
稼動状態を通知する情報を生成する通知情報生成部（４０４）と、
前記管理装置に前記通知情報生成部により生成した稼動情報を通知する通知手段（４０２）と、
前記通知手段には前記画像形成装置の稼動状態以外に修理を依頼する修理依頼情報を生成する修理依頼生成手段（４０６、Ｓ１２０４）と、
前記修理依頼生成手段により生成した修理依頼情報を前記通知手段に依頼する修理依頼手段（４０１）とを有し、
前記管理装置は、
前記画像形成装置の通知手段によって通知される通知情報、修理依頼通知を受信する通知情報受信手段（５０２）と、
前記通知情報受信手段により受信した情報を解析する解析手段（５０７）と、
前記解析手段により修理依頼通知を抽出するとともに過去の修理依頼通知の状態情報に基づき状態情報を記録、更新する修理依頼状態情報更新手段（５０８、Ｓ１４０６、Ｓ１４０７，Ｓ１４０８）と、
修理依頼通知の情報表示要求に基づき前記修理依頼状態情報更新手段によって記録されている状態情報により検索方法を変更する修理依頼検索手段（５０４）と、
前記修理依頼検索手段の検索結果を表示する表示情報生成部（５０５、Ｓ１５０２〜Ｓ１５０７）とを有することを特徴とする管理システム。