JP5924960B2 - 画像形成装置、画像形成装置の制御方法、及びプログラム - Google Patents

Description

本発明は、画像形成装置のメンテナンスに関するものである。

画像形成装置の安定稼働のために、メンテナンス技術者は、定期的に、顧客先を訪問しメンテナンスを行う。その際、メンテナンス技術者は、開発会社から提供されるサービスマニュアルに従って、サービスメンテナンス用のインタフェースを用いて、画像形成装置に装備されている各種センサ情報や動作回数を計測しているカウンタ値などを確認する。そして、メンテナンス技術者は、前記確認した情報に基づき、画像形成装置の内部の状態および部品の劣化状態を判断し、前記インタフェースを介して、最適な調整値を設定したり調整操作を実行したりして、画像形成装置が正常動作するように調整を行う。

このような、メンテナンス技術者による顧客先でのメンテナンスの内容は、開発会社に報告される。開発会社では、これらの報告を集計し、機種固有の調整手段や特定事例の対処方法などを検討し、その結果としてサービスメンテナンス情報を更新して、サービスマニュアルやウェブサイトなどに公開してメンテナンス技術者に提供する。これを繰り返して、事例に応じた最適な対処方法の情報が常に更新され、顧客先でメンテナンス技術者は最適な対処ができるような運用となっている。 例えば、動作不具合事例が発生したときには、前記のサービスマニュアルやウェブサイトを確認して、前記の不具合動作の対処方法を確認する。不具合内容によって、部品交換、メカ的な調整などのハード的な対処のほか、調整値の再設定などソフトウェア的な対処がある。ソフトウェア的な対処の場合は、サービスマンは、前記のサービスメンテナンス用のインタフェースを介して、複数のセンサ値、カウンタ値を参照し、その値を鑑みて最適な調整値の設定を行うことになる。
このようなメンテナンスについて、検索キーを入力することで当該検索キーに対応するメンテナンス項目を表示する技術が提案されている（特許文献１）。

特開２００３−１１４７７９号公報

近年、画像形成装置の多機能化によって、給紙デッキやフィーダ、ソータといったオプション装置が組み込まれるようになった。これにより、画像形成装置やオプション装置のセンサやカウンタの数が増大していて、総計１０００個以上になる場合もある。また、これらのセンサやカウンタの値を確認、あるいは調整するためのメンテナンス項目の数も増大している。
一般的に、メンテナンスを行うためには、ユーザは複数のメンテナンス項目を確認して、最適な調整値を導き出さなければならない。つまりメンテナンスを行うときには、膨大な数のメンテナンス項目の中から所望のメンテナンス項目を特定するという作業を、確認すべき複数のメンテナンス項目のすべてに対してユーザが何度も行う必要がある。特許文献１が開示する技術を用いたとしても、ユーザが何度も検索キーを入力する手間が発生する。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、複数のメンテナンス項目を確認する必要があるメンテナンスを行う場合において、何度も画面を切り替えることになる不都合を回避することができる仕組みを提供することである。

本発明は、メンテナンス画面を表示可能な画像形成装置であって、メンテナンス画面において表示すべき複数のメンテナンス項目を特定するためのコード情報をユーザが入力する入力手段と、前記入力手段によって入力された前記コード情報に基づいて、すべてのメンテナンス項目の中からメンテナンス画面において表示すべき複数のメンテナンス項目を特定する特定手段と、前記特定手段によって特定された複数のメンテナンス項目を同一画面で表示するためのメンテナンス画面を生成する生成手段と、前記生成手段によって生成された前記メンテナンス画面を表示する表示手段とを有し、前記コード情報には機種を示す機種情報が含まれ、前記機種情報が示す機種が前記画像形成装置の機種と一致しない場合、前記表示手段は、エラー情報を表示することを特徴とする。

本発明によれば、複数のメンテナンス項目を確認する必要があるメンテナンスを行う場合において、何度も画面を切り替えることになる不都合を回避することができる。

本発明の一実施例を示す画像形成装置の構成の一例を示すブロック図である。 図１の画像形成装置の操作部９を説明する図である。 メンテナンス技術者が使用する通常のサービスメンテナンス用の画面の表示例を示す図である。 サービスメンテナンス用の項目のメニューのツリー構造の一例を示す図である。 本実施例のサービスメンテナンス用画面の表示例を示す図である。 実施例１の画像形成装置１１０が入力されたコードに基づいてメンテナンスモード用の項目画面を表示する処理の一例を示すフローチャートである。 実施例１の画像形成装置のサービスメンテナンス用の項目を示すコードの構造の一例を示す図である。 サービスメンテナンス用の項目と項目に割り当てられたコード番号との対応表の一例を示す図である。 実施例２の画像形成装置のサービスメンテナンス用の項目を示すコードの構造の一例を示す図である。 実施例２の画像形成装置１１０が入力されたコードに基づいてメンテナンスモード用の項目画面を表示する処理の一例を示すフローチャートである。

以下、本発明を実施するための形態について図面を用いて説明する。

図１は、本発明の一実施例を示す画像形成装置の構成の一例を示すブロック図である。
図１において、１１０は画像形成装置である。画像形成装置１１０において、コントロールブロック１００は、画像形成装置１１０全体を制御する。
コントロールブロック１００において、ＣＰＵ１は、プログラムＲＯＭ３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行し、システムバス４を介して、画像形成装置１１０の各デバイスを制御する。システムバス４には、ＣＰＵ１、ＲＡＭ２、プログラムＲＯＭ３、ネットワークインタフェース５、スキャン部Ｉ／Ｆ６、印刷部Ｉ／Ｆ７、外部メモリインタフェース８、操作部９、カウンタ１４、センサ１５等が接続されている。

プログラムＲＯＭ３には、ＣＰＵ１が実行するプログラムの他に各種データ等も記憶されている。ＲＡＭ２は、ＣＰＵ１の作業領域として利用される。
ネットワークインタフェース（ＮＥＴＷＯＲＫ Ｉ／Ｆ）５は、イーサネット（登録商標）等の外部ネットワーク環境１０と接続するためのインタフェースである。スキャン部Ｉ／Ｆ６は、スキャン部１１との通信を行う。印刷部Ｉ／Ｆ７は、印刷を実行する印刷部（プリンタエンジン）１２と通信を行う。

外部メモリインタフェース（外部メモリＩ／Ｆ）８は、ＵＳＢメモリ等の外部メモリ１３と接続するためのインタフェースである。操作部９は、各種情報の表示とユーザからの入力を受け付ける機能を有する。
センサ１５は、複数のセンサを有し、画像形成装置１１０の各種状態を検知する。カウンタ１４は、各種動作回数を保持する。

ＣＰＵ１は、プログラムＲＯＭ３に格納されている制御プログラム等に基づいて、印刷部（プリンタエンジン）１２に対して印刷部Ｉ／Ｆ６を介して出力情報としての画像信号を出力する。ＣＰＵ１は、同様にスキャン部１１からの画像信号をスキャン部Ｉ／Ｆ６を介して受信する。また、ＣＰＵ１は、コントローラ管理下の各種センサ１５よりセンサ情報を受信する。また、ＣＰＵ１は、動作回数を計測してカウントアップした値をカウンタ１４として管理保存するように制御する。

また、図示しないが、スキャン部１１及び印刷部１２もそれぞれセンサ情報及びカウンタを保持しており、ＣＰＵ１は、それぞれの値をスキャン部Ｉ／Ｆ６、印刷部Ｉ／Ｆ７を介して取得することが可能となっている。

以下で説明する操作部９の表示部に表示される情報及び表示の挙動は、プログラムＲＯＭ３に格納されたプログラムに従って、ＣＰＵ１によって実行されるものである。
図２は、図１の画像形成装置の操作部９を説明する図である。
図２に示すように、操作部９は、タッチパネル付の表示部２０、テンキーを含む各種コントロールキー（総じて２１と記載）、表示部２０に表示される内容を切り替えるための特殊キー（総じて２２と記載）を有する。

以下に示す本実施例での表示は、この表示部２０に表示され、この表示に対する入力は、表示部２０へのタッチやコントロールキー２１で実行されるものとする。
以下、図３及び図４を用いて、サービスメンテナンスのインタフェースについて説明する。操作部９の表示部２０に表示される内容は、画像形成装置１１０の使用するファンクションごとに変更される。

図３は、メンテナンス技術者が使用する通常のサービスメンテナンス用の画面の表示例を示す図である。通常サービスメンテナンス用の画面は、顧客ユーザには公開されておらず、メンテナンス技術者のみが使用できる。なお、通常サービスメンテナンス用の画面は、従来より画像形成装置に設けられているものである。

図４は、サービスメンテナンス用の項目のメニューのツリー構造の一例を示す図である。
サービスメンテナンスの各項目は、ツリー構造のメニューの最終ノードに位置する（図４の例では、表示レベル＞第２階層＞第３階層＞第４階層＞項目）。サービスメンテナンスの各項目では、バージョン情報、各種センサ情報、カウンタ情報、調整値の設定、動作変更のスイッチの状態を表示したり、設定値を変更したりすることができる。

図４に示すように、ツリー構造の各階層において、最上位階層（第１階層）は、「表示レベル」で分類される。表示レベルは、そのツリー以下の階層および項目のレベルを示す。例えば、通常メンテナンス作業時で確認するためだけに使用するレベル、通常のメンテナンス作業で設定変更を行う時に使用するレベル、さらには、かなり特殊なケースでのみ使用するレベルなどで分類される。

第２階層は、画像形成装置１１０の部位（コントローラブロック１００、印刷部１２、スキャン部１１、フィーダ等）で分類される。
第３階層は、第２階層の部位のファンクションごとに分類される。例えば、第２階層「印刷部」の下の第３階層は、動作モードを切り替える機能、調整機能、部位内のさらに部品レベル（定着部、給紙部、作像部）などで分類される。
第４階層は、その上層の第３階層の意味合いで変化する。第４階層の下の階層がツリーの最終階層となり、個別の項目を指し示す。

図３（Ａ）は、ツリーを辿って項目まで辿り着くまでの途中段階の表示例を示す。
表示レベルで「レベル２」（３１）、第２階層で「ＦＥＥＤＥＲ」（３２）、第３階層で「ＯＰＴＩＯＮ」（３３）を選択した状態を示している。
表示部２０の最上段に、それぞれ選択済みの階層が「表示レベル２＞ＦＥＥＤＥＲ＞ＯＰＴＩＯＮ」のように表示される。
表示領域３８には、ノード（図４の３３）（表示レベル２＞ＦＥＥＤＥＲ＞ＯＰＴＩＯＮ）の下に存在する第４階層のノード名（ＳＥＮＳＯＲ、ＭＥＮＵ１、ＭＥＮＵ３、ＭＥＮＵ４、ＭＥＮＵ５）がメニューとして表示される。

図３（Ｂ）は、図３（Ａ）で「ＳＥＮＳＯＲ」（３４）メニューを選択し、最終階層に達したときの表示を示す。最終ノードは項目を指すので、各項目が管理している値を表示している。

図３（Ｂ）の例では、第４階層の「ＳＥＮＳＯＲ」（３４）の下にある２０項目のうち８項目（ＳＥＮＳＯＲ_１、ＳＥＮＳＯＲ_２、・・・、ＳＥＮＳＯＲ_８）が表示領域３０に表示されている。

表示部２０の画面サイズの制限から表示できる項目数が限られているため、同時表示が８個までになっているが、左ボタン（３５）と右ボタン（３６）を使って表示する項目を切り替える、いわゆるスクロールすることが可能となっている。

図３（Ｂ）の表示例から明らかなように、同時に表示可能な項目は、同じ最終ノードに含まれているもので、かつ同じスクロール範囲内にあったときのみである。
ある不具合や要調整事例に対処する際に、現場のメンテナンス技術者は、マニュアルやウェブサイトを調べて、その対処方法の情報を得る。例えば、ウェブサイトでは、該当事例を入力すると、対処方法を指し示す事例のデータベースなどが運用されている。

対処方法の一例として、画像形成装置の現在の状態をセンサ値でチェックし、調整値をそのセンサ値に則して変更する等がある。具体的には、画像形成装置内の温度、湿度の値から特定部品の電圧値を変える、温度ごとの電位マップのテーブルを変更する等である。マニュアルやウェブサイトには、これらの項目を確認、設定変更するようにという指示がウェブサイト等に掲載されている。

図５は、本実施例のサービスメンテナンス用画面の表示例を示す図である。
図５では、ある特定の不具合に対処するために必要な情報表示と調整値設定を行うための項目が、全く別のツリー構造のノードに属している例を示す。
例えば、表示レベル「２」＞第２階層「ＦＥＥＤＥＲ」＞第３階層「ＯＰＴＩＯＮ」＞第４階層「ＳＥＮＳＯＲ」の項目「ＳＥＮＳＯＲ_１」、
表示レベル「１」＞第２階層「ＣＯＰＩＥＲ」＞第３階層「ＡＤＪＵＳＴ」＞第４階層「ＯＰＴＩＯＮ」の項目「ＴＭＰＴＢＬ１」、
表示レベル「２」＞第２階層「ＣＯＰＩＥＲ」＞第３階層「ＡＤＪＵＳＴ」＞第４階層「ＯＰＴＩＯＮ」の項目「ＴＭＰＴＢＬ２」、
表示レベル「１」＞第２階層「ＦＥＥＤＥＲ」＞第３階層「ＯＰＴＩＯＮ」＞第４階層「ＦＥＥＤＳＮＳ」の項目「ＳＥＮＳＰＷＲ」の、情報表示と調整値設定が必要な場合がある。

このように、ある特定の不具合に対処するために、全く別のツリー構造のノードに属している４つの項目の情報表示と調整値設定が必要な場合がある。
図３に示したようなメンテナンス用インタフェースの場合は、必要な項目をアクセスするために各項目についてツリー構造のメニューを辿って必要な項目にユーザが何度もアクセスする必要があり、操作手数がかかる上に、表示された値を見比べる作業もできず、非常に不便であった。

そのため、前記の不具合に対処するために必要な複数の項目の情報表示と調整値設定するためのインタフェースを同一画面上に表示することができれば、前記の問題を解決できる。例えば、図５に示したようなインタフェースとすることで、５３ａ〜５３ｄのように、前記の不具合に対処するために必要な複数の項目の値を比較確認でき、その設定が可能となる。項目の設定を行う場合、サービスマンは、調整したい項目を５４ｂ〜５４ｄのいずれかをタッチすることにより選択し、コントロールキー２１から、その項目の調整値を入力することで、その項目の設定を行うことができる。

なお、一般的な画像形成装置の要調整事例や、過去の機種および同系統の機種で発生していた要調整項目については、予め仕込んでおくことも可能である。サービスメンテナンスのプログラムをバージョンアップすることで内容の更新も可能である。該プログラムは、画像形成装置のプログラムに同梱されているので、画像形成装置のプログラムのバージョンアップの仕組みと同じ手段でバージョンアップが可能である。すなわち、画像形成装置とパーソナルコンピュータとをピアツーピアで接続して専用ツールを用いてダウンロードする方法、画像形成装置がネットワーク経由でダウンロードサイトよりプログラムをダウンロードする方法、ＵＳＢメモリなどの外部メモリを使ってプログラムをダウンロードする方法などでバージョンアップ可能である。

しかしながら、この方法でも、最初からプログラムに組み込んでいない任意の組み合わせの項目をまとめて表示することはできない。前述のように画像形成装置が市場の顧客先で運用が進むにつれ、新たな問題が発生したり、より改善された対策手段が見出されたりする。その都度、画像形成装置のプログラムのバージョンアップを行うことで対応は可能であるが、そのための工数が新たに必要となり現実的ではない。

そこで、新たな組み合わせをプログラムの改変を行わずに、対策を集積した画面を作成できることが望ましい。
そのため、開発会社は新たな要調整事例とその対策を、マニュアルの補遺や前記ウェブサイトに対策情報追加する際に、後述する８〜１６桁の数字列から成るコードを掲載しておく。

メンテナンス技術者は、前記マニュアルの補遺や前記ウェブサイトから、該要調整事例を検索して、対応手段の情報とともに、掲載されているコードを取得する。
画像形成装置のサービスメンテナンス画面にコード情報の入力を可能とする機能（図５の５１）を用意し、ＣＰＵ１は操作部９を介して、メンテナンス技術者からのコード入力を受け付ける。コード情報の入力を行う場合、サービスマンは、コード入力部５１をタッチすることにより選択し、コントロールキー２１のテンキーからコードを入力する。
画像形成装置は、コード入力部５１から入力されたコードから対策用の項目を示すデータを抽出し、必要項目を前記サービスメンテナンス画面（図５）に再構成して表示する。即ち、ＣＰＵ１は、操作部９から入力されたコード情報に基づいて、すべてのメンテナンス項目の中から画像形成装置１１０が表示すべき複数のメンテナンス項目を特定し、該特定された複数のメンテナンス項目を同一画面で表示するための画面を生成し、該生成した画面を表示する（図５の５０）。

以下、コードの構造について、図７と図８を用いて説明する。
図７は、実施例１の画像形成装置のサービスメンテナンス用の項目を示すコードの構造の一例を示す図である。
図７に示すように、コードの先頭の２ビット（７１）が４種類のコードデータのフォーマット（図７（Ａ），図７（Ｂ），図７（Ｃ），図７（Ｄ））を示すフォーマットビットである。

次の２ビット（７２）は、コードの中で指定するデータ部の数を示すビット（データ数ビット）である。さらに、次の２ビット（７３）は、チェックサム用のビット（チェックサムビット）である。チェックサムビット７３は、コードの誤りの有無を判定することにより、コードが有効であるか否かを判定するための判定情報である。

さらに、その次に続く、データ部７４〜７７は、フォーマットビット（７１）によってビット長が異なっている。データ部には、図８の表にあるように、それぞれが、サービスメンテナンス用の項目に割り当てられたコード番号が格納される。なお、データ部は４つに限定されるものではない。即ち、特定の不具合に対処するためにコード入力部５１に入力するコードは、画像形成装置１１０のメンテナンス用の各項目に割り当てられたコード番号を１又は複数含むコードである。

図８は、サービスメンテナンス用の項目と項目に割り当てられたコード番号との対応表の一例を示す図である。即ち、図８は、図７に示したデータ部７４〜７７に格納されるコード番号とサービスメンテナンス用の項目との対応情報を示す。なお、図８に示す対応表のデータは、画像形成装置１１０のＲＯＭ３に格納されているものとする。

サービスメンテナンス用の項目は、例えば２０００項目など多数存在するが、実際に調整メンテナンスに使用する項目は、ある程度限られている。例えば、バージョン情報やファンクションの動作モード、画面表示だけに使用する設定値などは、特定事例対応用の画面（図５）では使われることがなく、したがってコードの中に含まれることがないと考えてよい。このように特定事例対処用の画面（図５）で使用されることのない項目には大きな値を割り当て、比較的使用頻度の高い項目には小さい値を割り当てておく。これにより、使用頻度の最も高い項目だけを、コード入力部５１から入力する特定の不具合に対処するためのコードに含める場合は、図７（Ａ）で示されるように各データ部のビット長をすべて８ビットとすることが可能となり、コードの全体ビットサイズを小さくすることができる。

図８にあるように、段階的に使用頻度順に項目を割り当てておき、コード作成時には、コードに含める複数の項目のうち、最大のビット数になる項目に合わせてフォーマットを決定するものとする。これにより、使用頻度の高い項目だけであれば、例えば、コードの桁数は１１桁以下で納めることができる。なお、コード番号の桁数は、１１桁以下に限られるものではなく、画像形成装置に設けられるサービスメンテナンス用の項目の数に応じて設計変更可能なものである。

以下、図６のフローチャートを用いて、画像形成装置１１０が、入力されたコードを解析し、画面５０を表示するロジックについて説明する。
図６は、実施例１の画像形成装置１１０が入力されたコードに基づいてメンテナンスモード用の項目画面を表示する処理の一例を示すフローチャートである。なお、このフローチャートの各ステップは、画像形成装置１１０のＣＰＵ１がプログラムＲＯＭ３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現されるものである。

まず、Ｓ６０１において、ＣＰＵ１は、コード入力部５１がタッチされると、コントロールキー２１のテンキーによるコードの入力を受け付け、メンテナンス技術者によってテンキーでコードが入力されると、該入力を検知し、前記テンキーで入力されたコードを取得する。本実施例では、コードはテンキーで入力可能な１０進数の数値としている。しかし、コードは数字のみに限定されるものではなく、ソフトキーボードやＵＳＢ接続されたハードキーボードなどを用いて入力可能な文字列を用いてもよい。

次に、Ｓ６０２において、ＣＰＵ１は、前記Ｓ６０１で取得したコードからフォーマット情報７１を取得する。
次に、Ｓ６０３において、ＣＰＵ１は、前記Ｓ６０１で取得したコードからチェックサム情報７３を取得し、データ部７４〜７７のビットのチェックサムが正しいかどうかを判定する。チェックサムの判定方法は、例えば、フォーマットビット７１とデータ数ビット７２を除いたコードをビット表記した際の１値の数が偶数になるように、チェックサムビットを調整することで、コードのミス入力かどうかをチェックする。また、入力されたコードをそのままビット表記した際の１値の数が偶数になるように、チェックサムビットを調整することで、コードのミス入力かどうかをチェックするようにしてもよい。

前記Ｓ６０３におけるチェックサムの判定の結果、データ部がチェックサムと一致しないと判定した場合、前記Ｓ６０１で取得したコードが有効でなくエラー（ＮＧ）であると判定し、ＣＰＵ１は、Ｓ６０８に処理を進める。Ｓ６０８では、ＣＰＵ１は、エラー情報（ここでは、入力したコードに誤りがある旨を示すエラー情報）を操作部９の表示部２０に表示し、Ｓ６０１へ処理を遷移し、コードの再入力を待機する。

一方、前記Ｓ６０３におけるチェックサムが正しいと判定した場合、前記Ｓ６０１で取得したコードが有効である（ＯＫ）と判定し、ＣＰＵ１は、Ｓ６０４に処理を遷移させる。

Ｓ６０４では、ＣＰＵ１は、前記Ｓ６０１で取得したコードのデータ数７２からデータの数を取得し、そのデータ数分コードのデータ部１（７４）〜データ部４（７７）から項目番号を抽出する。前述したように、データ部のビットサイズはフォーマット（７１）によって異なっており、このビットサイズでデータ部からデータ数（７２）が示す数だけ項目のコード番号を抽出する。

次に、Ｓ６０５において、ＣＰＵ１は、前記Ｓ６０４で抽出した各項目のコード番号から、ＲＯＭ３に格納されているコード表（図８）を用いて、各項目の抽出を行う。
次に、Ｓ６０６において、ＣＰＵ１は、前記Ｓ６０５の抽出処理でコード番号に対応する項目を全てコード表から抽出できた（コード表に含まれていた）かどうかを判定する。
そして、前記Ｓ６０６において、前記Ｓ６０５の抽出処理でいずれかの項目番号に対応する項目をコード表から抽出できなかった（コード表に含まれていなかった）と判定した場合（Ｎｏ）、ＣＰＵ１は、Ｓ６０８に処理を進める。Ｓ６０８では、ＣＰＵ１は、操作部９の表示部２０にエラー情報を表示し、Ｓ６０１に遷移して、再度のコードの入力を待機するように制御する。

一方、前記Ｓ６０６において、前記Ｓ６０５の抽出処理で項目番号に対応する項目を全てコード表から抽出できた（コード表に含まれていた）と判定した場合（Ｙｅｓ）、ＣＰＵ１は、Ｓ６０７に処理を進める。

Ｓ６０７では、ＣＰＵ１は、前記Ｓ６０５で前記コード表から抽出した各項目に関する情報（例えば図５の５３ａ〜５３ｄ）を表示するための画面５０を動的に生成して表示するように制御する。その後、ＣＰＵ１は、前記画面５０から前記表示された各項目に対する調整値の設定を受け付けるように制御する。詳細には、ＣＰＵ１は、５４ｂ〜５４ｄのいずれかをタッチされたことを検知すると、コントロールキー２１からその項目の調整値の入力を受け付けるように制御する。そして、コントロールキー２１から項目の調整値が入力され、ＯＫボンタン５２がタッチされたことを検知すると、前記入力された調整値を項目に設定するように制御する。

以上の処理により、画像形成装置のサービスメンテナンスにおいて、深い階層構造に分散された複数の項目に対しても、最新の事例に対処するために必要な項目を収集したインタフェースを動的に構成して提供することができる。これにより、必要な項目へのアクセスに要するサービスマンの工数を大幅に削減することができる。

また、サービスメンテナンスについて最新の情報が更新された場合でも、画像形成装置に新たなプログラムをインストールしたりアップデートしたりする必要がなく、図５の５１のように、簡易なコードを入力するだけで、最新の情報が反映されたインタフェースを提供することができる。これにより、画像形成装置の設置先の環境（ネットワークのポリシー等）に左右されることなく、サービスメンテナンスを行うことができる。
さらに、コードにチェックサム情報７３を含めることにより、ユーザのコード入力ミス等をチェックすることができる。

図３に示したような従来から設けられているサービスメンテナンス用の項目をアクセスするためのインタフェースは、項目の特徴別にカテゴライズされたものであり、事例に応じた対応をするために必要な項目は散在することになり、効率的な作業に適していない。また、画像形成装置のプログラムを修正して専用の画面を設けて対応することは可能であるが、最新のメンテナンス情報を反映するために、その都度、画像形成装置のアップデートすることは運用上難しい場合がある。しかし、上述した構成により、画像形成装置のプログラムをアップデートすることなく、最新の事例に対応するために必要な項目を集めた画面（例えば図５の５０）を、コード入力することで（例えば図５の５１）、動的に作成して提供することができ、上記の課題を解決することができる。

上記実施例１では、コードの中に含まれている項目の情報およびコード番号の確かさを保証するチェックサム情報を、コードに含む構成について説明した。実施例２では、さらにコードの中に、該コードが入力された画像形成装置が該コードの対象機種であるか否かを確認するための付加情報を、コードが有効であるか否かを判定するための判定情報として追加するように構成する。

図９は、実施例２の画像形成装置のサービスメンテナンス用の項目を示すコードの構造の一例を示す図である。
図９に示すように、実施例２のコードは、コード内に、ＯＰＴＩＯＮの種類を示すＯＰＴＩＯＮ ＦＬＡＧ（９１）と、ＯＰＴＩＯＮ ＤＡＴＡ（９２）が追加されている。
例えば、このコードが対応している要調整事例の対応先が特定の機種のみで有効であった場合、関係ない機種で使用してしまうとかえって問題を起こすこともありうる。そのため、本実施例では、ＯＰＴＩＯＮとして機種コードを含めておき、対象外の機種での誤用を防ぐことが可能である。

例えば、ＯＰＴＩＯＮ ＦＬＡＧ（９１）が「００」の場合、ＯＰＴＩＯＮ ＤＡＴＡ（９２）が画像形成装置の機種コード（機種情報）を示すものとする。また、ＯＰＴＩＯＮ ＦＬＡＧ（９１）が「０１」の場合、ＯＰＴＩＯＮ ＤＡＴＡ（９２）が画像形成装置のシリアル番号を示すものとする。また、ＯＰＴＩＯＮ ＦＬＡＧ（９１）が「１０」の場合、ＯＰＴＩＯＮ ＤＡＴＡ（９２）がコードの有効期限の日時情報を示すものとする。

以下、この実施例のコード入力から画面表示までの動作について、以下、図１０のフローチャートを用いて説明する。なお、ここでは、ＯＰＴＩＯＮ ＦＬＡＧ（９１）が「００」、すなわち、ＯＰＴＩＯＮ ＤＡＴＡ（９２）が機種コードを示す場合について説明する。

図１０は、実施例２の画像形成装置１１０が入力されたコードに基づいてメンテナンスモード用の項目画面を表示する処理の一例を示すフローチャートである。なお、このフローチャートの各ステップは、画像形成装置１１０のＣＰＵ１がプログラムＲＯＭ３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現されるものである。

なお、図１０のＳ９０１〜Ｓ９０６までは、実施例１の図６のＳ６０１から６０６までと同一であるので説明は省略する。
Ｓ９０７において、ＣＰＵ１は、Ｓ９０１で取得したコードから、ＯＰＴＩＯＮ ＦＬＡＧ（９１）とＯＰＴＩＯＮ ＤＡＴＡ（９２）とを取得する。
次に、Ｓ９０８において、ＣＰＵ１は、オプションが有効かどうかを判定する。ここで、ＯＰＴＩＯＮ ＦＬＡＧ（９１）が「００」の場合、ＯＰＴＩＯＮ ＤＡＴＡ（９２）の値は画像形成装置の機種コードを示すため、ＣＰＵ１は、画像形成装置１１０の機種コードと一致するかどうかで、オプションが有効かどうかを判定する。なお、画像形成装置１１０の機種コード（機種情報）は、機種情報記憶部（プログラムＲＯＭ３内の記憶領域）に記憶されているものとする。

前記Ｓ９０８において、ＯＰＴＩＯＮ ＤＡＴＡ（９２）の値が画像形成装置１１０の機種コードと一致しない場合、ＣＰＵ１は、オプションが有効でない（即ち、取得したコードが有効でない）と判定し（Ｎｏ）、Ｓ９１０に処理を進める。Ｓ９１０では、ＣＰＵ１は、エラーメッセージを操作部９の表示部２０に表示し、Ｓ９０１に処理を遷移させ、コード入力を待機するように制御する。

一方、前記Ｓ９０８において、ＯＰＴＩＯＮ ＤＡＴＡ（９２）の値が画像形成装置１１０の機種コードと一致する場合、ＣＰＵ１は、オプションが有効である（即ち、取得したコードが有効である）と判定し（Ｙｅｓ）、Ｓ９０９に処理を進める。

Ｓ９０９では、ＣＰＵ１は、Ｓ９０５でコード表から抽出した各項目を、画面５０に表示するように制御する。その後、ＣＰＵ１は、前記画面５０から前記表示された各項目に対する調整値の設定を受け付けるように制御する。

なお、ＯＰＴＩＯＮ ＦＬＡＧ（９１）が「０１」や「１０」の場合、即ち、ＯＰＴＩＯＮの種類が、画像形成装置のシリアル番号や、コードの有効期限の日時情報などである場合の制御も、ＯＰＴＩＯＮの種類が機種コードの場合と同様である。

例えば、ＣＰＵ１は、Ｓ９０１で入力されたコードに含まれるシリアル番号と画像形成装置１１０のシリアル番号とが一致しない場合、Ｓ９０８において、オプションが無効である（即ち、取得したコードが無効である）と判定し（Ｎｏ）、Ｓ９１０に処理を進める。なお、画像形成装置１１０のシリアル番号は、シリアル番号記憶部（プログラムＲＯＭ３内の記憶領域）に記憶されているものとする。

また、ＣＰＵ１は、Ｓ９０１で入力されたコードに含まれる有効期限を示す情報がその時点の日時を超える場合、Ｓ９０８において、オプションが無効である（即ち、取得したコードが無効である）と判定し（Ｎｏ）、Ｓ９１０に処理を進める。

以上示したように、コード内に、該コードが対応する画像形成装置の種類や、シリアル番号、該コードの有効期限等の情報（９１，９２）を含めることにより、無効なコードの入力をチェックすることができる。 また、上記実施例では、コントロールキー２１のテンキーや、表示部２０に表示されるソフトキーボードからコードを入力する構成について説明した。しかし、コードの入力はこの形態に限定されるものではない。例えば、サービスマニュアルやウェブサイトなどに掲載されている情報（例えば、バーコード）を、スキャン部１１により読み取って、前記バーコード内からコードを抽出するように構成してもよい。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施例について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

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

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１１０ 画像形成装置
１ ＣＰＵ
９ 操作部
１４ カウンタ
１５ センサ
２０ 表示部
５１ コード入力部

Claims (6)

1. メンテナンス画面を表示可能な画像形成装置であって、
   メンテナンス画面において表示すべき複数のメンテナンス項目を特定するためのコード情報をユーザが入力する入力手段と、
   前記入力手段によって入力された前記コード情報に基づいて、すべてのメンテナンス項目の中からメンテナンス画面において表示すべき複数のメンテナンス項目を特定する特定手段と、
   前記特定手段によって特定された複数のメンテナンス項目を同一画面で表示するためのメンテナンス画面を生成する生成手段と、
   前記生成手段によって生成された前記メンテナンス画面を表示する表示手段とを有し、
   前記コード情報には機種を示す機種情報が含まれ、
   前記機種情報が示す機種が前記画像形成装置の機種と一致しない場合、前記表示手段は、エラー情報を表示することを特徴とする画像形成装置。
2. 特定のメンテナンス項目を示すコード番号を前記すべてのメンテナンス項目に対応付けて記憶する記憶手段を更に有し、
   前記入力手段によって入力されるコード情報は複数のコード番号を示し、
   前記特定手段は、前記複数のコード番号が示す複数のメンテナンス項目を、メンテナンス画面において表示すべき複数のメンテナンス項目として特定することを特徴とする請求項１に記載の画像形成装置。
3. 前記メンテナンス画面において表示される複数のメンテナンス項目について、ユーザが所望の調整値を入力可能であることを特徴とする請求項１又は２に記載の画像形成装置。
4. 前記メンテナンス画面には、ユーザに入力された調整値を前記画像形成装置に設定するための設定ボタンが表示されることを特徴とする請求項３に記載の画像形成装置。
5. メンテナンス画面を表示可能な画像形成装置の制御方法であって、
   メンテナンス画面において表示すべき複数のメンテナンス項目を特定するためのコード情報の入力をユーザから受け付ける入力ステップと、
   前記入力ステップで入力された前記コード情報に基づいて、すべてのメンテナンス項目の中からメンテナンス画面において表示すべき複数のメンテナンス項目を特定する特定ステップと、
   前記特定ステップで特定された複数のメンテナンス項目を同一画面で表示するためのメンテナンス画面を生成する生成ステップと、
   前記生成ステップで生成された前記メンテナンス画面を表示する表示ステップとを有し、
   前記コード情報には機種を示す機種情報が含まれ、
   前記機種情報が示す機種が前記画像形成装置の機種と一致しない場合、前記表示ステップは、エラー情報を表示することを特徴とする画像形成装置の制御方法。
6. コンピュータを、請求項１乃至４のいずれか１項に記載された手段として機能させるためのプログラム。

Images