JP6384191B2 - プログラム - Google Patents

Description

本発明は、プログラムに関する。

画像形成装置やこれを制御する画像形成装置コントローラの中には、画像形成装置内のセンサの検知信号や印刷枚数等の印刷処理実績の管理情報等から、消耗品切れや交換部品の寿命到来、印刷画質の劣化等の不具合事象の発生やその予兆を検知し、画面表示する機能を有するものがある。そのような画像形成装置や画像形成装置コントローラが検知したセンサや予兆等の検知結果を、インターネット等の外部ネットワークを介して、画像形成装置保守サービスを提供する業者の管理システムに通知する仕組みも知られている。この仕組みでは、保守サービス業者の管理システムが画像形成装置側からの情報に基づいてその画像形成装置の不具合やその予兆の詳細情報を把握する。この情報に基づき、保守作業者の派遣などの処置がとられる。派遣される保守作業者は、画像形成装置側からの情報に基づいて求められた不具合等の詳細情報をもとに、必要な保守作業の準備を行う。

一方、印刷内容の機密保持等のために、インターネット等の外部ネットワーク環境から遮断された環境に画像形成装置を設けることがある。このように外部環境に接続されない画像形成装置の不具合やその予兆の情報は、外部ネットワークを介して保守サービス業者側の管理システムに通知することができない。このため、予兆等が検知された場合に、その検知結果や不具合の解析に必要なテストパターン等をその画像形成装置に印刷出力させることが行われている。

例えば、特許文献１に開示されたシステムでは、社内のネットワークに接続されたコンピュータが、同じネットワーク上の画像形成装置の情報により故障を予測し、予測できたとき、画像形成装置コントローラを介してその画像形成装置に、予測内容と故障解析用の所定画像のハードコピーを出力するように指示する。保守サービス業者からその画像形成装置のもとに派遣された保守作業員は、故障の予測がなされた時点でのテストパターンの印刷結果を参照することで、故障の内容を解析し、対策に役立てる。

特開平８−２６７８７９号公報

不具合事象やその予兆の識別や解析に必要な情報の中には、保守サービス業者から派遣された保守作業員には必要であっても、その画像形成装置のユーザの目に触れると無用の混乱を招く等の理由で秘匿すべき情報もある。ここで、秘匿すべき情報は予兆等の検出時点では印刷出力せず、後で保守作業員が到着してから収集するという対応策も考えられないではない。しかし、予兆等を検知した時点の情報でないと確かな解析ができない場合もあり、そのような情報については予兆等を検知した時点で、その時に検知した情報を画像形成装置に印刷させる必要がある。

本発明は、不具合事象の予兆を検知した時点での当該予兆に関する情報を、ユーザに対する秘匿性を確保しつつ印刷出力できるようにすることを目的とする。

参考例１の構成は、コンピュータを、画像形成装置の不具合事象の予兆を検知する検知手段、前記検知手段が検知した予兆について通知する予兆通知文書を前記画像形成装置に印刷させる制御を行う予兆通知制御手段であって、前記予兆通知文書のうちあらかじめ定められた秘匿対象部分の内容については当該内容を秘匿化した秘匿化画像を印刷させる予兆通知制御手段、として機能させるためのプログラムである。

参考例２の構成は、前記予兆通知制御手段は、前記秘匿対象部分に対して設定された秘匿条件が満たされる場合は、前記秘匿対象部分の内容を前記秘匿化画像として印刷させ、前記秘匿条件が満たされない場合は前記秘匿対象部分の内容を秘匿化せずに印刷させる、ことを特徴とする参考例１に記載のプログラムである。

参考例３の構成は、前記予兆通知制御手段は、前記予兆通知文書のうちあらかじめ定められた符号化対象部分の内容については、当該内容を機械読み取り可能な符号で表現した画像を前記画像形成装置に印刷させる、ことを特徴とする参考例１又は２に記載のプログラムである。

参考例４の構成は、前記プログラムはページ記述言語で記述されていることを特徴とする、参考例１〜３のいずれか１項に記載のプログラムである。

請求項１に係る発明は、コンピュータを、画像形成装置の不具合事象の予兆を検知する検知手段、前記検知手段が検知した予兆について通知する予兆通知文書を前記画像形成装置に印刷させる制御を行う予兆通知制御手段であって、前記予兆通知文書のうちあらかじめ定められた秘匿対象部分の内容については当該内容を秘匿化した秘匿化画像を印刷させる予兆通知制御手段、として機能させるためのプログラムであって、前記プログラムはバリアブル印刷に対応したページ記述言語で記述されており、前記検知手段は、バリアブル印刷の印刷データ中のバリアブルデータに含まれる、前記不具合事象の判定材料となる前記画像形成装置の状態データから、当該不具合事象の予兆を検知する、ことを特徴とするプログラムである。

請求項２に係る発明は、コンピュータを、１以上の不具合事象について、データベースに登録されているそれら不具合事象の判定材料となる前記画像形成装置の状態データから、請求項１に記載の検知手段が予兆の検知に用いるバリアブルデータを生成する生成手段、請求項１に記載のプログラムを前記コンピュータに実行させる命令と、前記生成手段が生成した前記バリアブルデータとを含む、ページ記述言語で記述されたプログラムを生成し、生成したプログラムを前記コンピュータに実行させる手段、として機能させるためのプログラムである。

請求項３に係る発明は、コンピュータを、画像形成装置の不具合事象の予兆を検知する検知手段、前記検知手段が検知した予兆について通知する予兆通知文書を前記画像形成装置に印刷させる制御を行う予兆通知制御手段であって、前記予兆通知文書のうちあらかじめ定められた秘匿対象部分の内容については当該内容を秘匿化した秘匿化画像を印刷させる予兆通知制御手段、として機能させるためのプログラムであって、前記予兆通知制御手段は、前記検知手段が検知した予兆の優先度が現在実行中の印刷処理の優先度より高い場合に、現在実行中の印刷処理を中断し、前記予兆通知文書を前記画像形成装置に印刷させる、ことを特徴とするプログラムである。

参考例５の構成は、画像形成装置の不具合事象の予兆を検知する検知手段と、前記検知手段が検知した予兆について通知する予兆通知文書を前記画像形成装置に印刷させる制御を行う予兆通知制御手段であって、前記予兆通知文書のうちあらかじめ定められた秘匿対象部分の内容については当該内容を秘匿化した秘匿化画像を印刷させる予兆通知制御手段と、を含む情報処理装置である。

参考例１又は５の構成によれば、不具合事象の予兆を検知した時点での当該予兆に関する情報を、ユーザに対する秘匿性を確保しつつ印刷出力できる。

参考例２の構成によれば、秘匿対象部分の内容を秘匿化しないでよい場合には、秘匿化せずに印刷出力することができる。

参考例３の構成によれば、予兆通知文書のうちのあらかじめ定められた符号化対象部分については、人間の読み取りよりも誤りが少ない機械読み取りにより読み取ることが可能になる。

参考例４の構成によれば、ページ記述言語で記述されたプログラムを実行可能なソフトウエアを備えたコンピュータであれば、ハードウエア構成やオペレーティングシステムによらず、検知手段及び予兆通知制御手段として機能させることができる。

請求項１及び２に係る発明によれば、不具合事象の予兆を検知した時点での当該予兆に関する情報を、ユーザに対する秘匿性を確保しつつ印刷出力できると共に、バリアブル印刷の仕組みにより予兆通知文書を印刷出力させることができる。

請求項３に係る発明によれば、不具合事象の予兆を検知した時点での当該予兆に関する情報を、ユーザに対する秘匿性を確保しつつ印刷出力できると共に、実行中の印刷処理よりも優先度が高い予兆についてのみ、その印刷処理を中断して予兆通知文書をすぐに出力することができる。

実施形態の画像形成装置の機能構成の一例を示す図である。 予兆の分析及び分析結果の出力のために用いられる、バリアブル印刷のフォームの一例を示す図である。 予兆印字フォームの実行により印刷出力された予兆通知文書の一例を示す図である。 予兆分析ジョブのジョブデータの一例を示す図である。 メインのジョブが中間ジョブを呼び出す構造の例を示す図である。 階層構造化されたジョブ群の例を示す図である。

＜装置構成の例＞
図１に、本発明に係る装置の一実施形態を示す。図１に例示する画像形成装置１００は、ジョブ処理部１１０、印刷部１２０、保守情報ＤＢ（データベース）１３０、予兆分析ジョブ生成部１４０、予兆分析フォーム保管部１５０、フォーム登録部１６０を有する。図１では、画像形成装置１００が有する構成要素のうち、画像形成装置１００の不具合事象の予兆を検知し、その検知結果の情報を表示する機能に関係する構成要素を示し、通常の印刷処理のみに用いる構成要素の図示は省略している。

ジョブ処理部１１０は、ページ記述言語で記述されたジョブデータを処理することで、印刷部１２０が取扱可能なラスター形式等の形式の印刷画像データを生成する。ページ記述言語で記述されたジョブデータは、一種のプログラムであり、ジョブ処理部１１０はこのプログラムを実行する一種の仮想マシンである。例えば、ジョブ処理部１１０は、ジョブデータ内にファイルへの書き出し命令があれば、ファイルに書き出しを実行する。またジョブ処理部１１０はバリアブル印刷に対応しており、フォームに対してジョブデータ中で指定された個々のデータを適用することで、個別の印刷画像データを生成する。なお、ページ記述言語は、描画命令以外に、ジョブ処理部１１０内のインタプリタの内部状態の変更やファイルの読み書き等と言った、描画を伴わない演算処理の命令を含んでいる。したがって、ジョブデータ中に描画命令がない場合や、描画命令の対象となる描画内容がないとき（例えばバリアブル印刷において描画命令の対象となるデータが存在しないとき）もある。このようにジョブデータ中に印刷する情報がないときには、印刷は行われない。

印刷部１２０は、ジョブ処理部１１０が生成した印刷画像データを、トナー等の色材を用いて、紙等の記録媒体上に印刷する。

保守情報ＤＢ１３０は、画像形成装置１００の保守に用いる各種の情報を記憶し、管理するデータベースである。保守情報ＤＢ１３０は、例えば、消耗品情報１３２、デバイス情報１３４、デバイス利用計画１３６等を記憶している。消耗品情報１３２は、用紙やトナー等の各種消耗品の残量を表す情報である。デバイス情報１３４は、画像形成装置１００やその中の部品（例えば感光体ドラム等）の機種や個体の識別情報、感光体ドラム等の画像形成装置１００内の消耗品以外の交換可能部品の使用量（例えば何枚の印刷に用いたか等。印刷枚数の計数値等から求められる）や状態（これはセンサにより検知される）等の情報である。消耗品情報１３２やデバイス情報１３４は、画像形成装置１００内の各部に設けられセンサ（例えば用紙やトナーの残量センサ）からの信号、ジョブ処理部１１０等が管理する印刷処理の実行状況の情報等に応じて更新される。デバイス利用計画１３６は、画像形成装置１００の利用予定の情報であり、例えば何月何日の何時から何時までは印刷ジョブが実行される予定、その後何時から何時までは空き時間（印刷予定なし）、等と言ったスケジュールを表す。時間帯毎の印刷ジョブの実行の有無だけでなく、各時間帯に実行される印刷ジョブの識別情報や実行優先度等と言った、印刷ジョブの各種属性情報をデバイス利用計画１３６に登録しておいてもよい。

保守情報ＤＢ１３０が保持している各種のデータのデータ形式には特に限定はない。例えば、ＣＳＶ形式のようにデータの種類を表すラベルとそのデータの値とが分かる形式を用いればよい。

保守情報ＤＢ１３０へは、例えば、画像形成装置１００の制御部が一般的に管理している内部データ（例えばログファイル）から情報を収集して登録すればよい。例えば、用紙残量等の消耗品情報１３２や、交換可能部品の使用量等のデバイス情報１３４等は、このように画像形成装置１００が一般に管理している内部情報から収集し、登録すればよい。

また、画像形成装置１００の外部で作成される外部情報を保守情報ＤＢ１３０に登録することも可能である。この場合、例えば外部情報を保守情報ＤＢ１３０に登録するジョブをページ記述言語で記述し、このジョブを画像形成装置１００のジョブ処理部１１０に実行させることで、その外部情報を保守情報ＤＢ１３０に登録するようにしてもよい。この例では、ページ記述言語が持つファイルへの書き出し命令（例えばＰｏｓｔＳｃｒｉｐｔ（商標）のｆｉｌｅコマンド）を利用する。すなわち、ファイルへの書き出し命令、保守情報ＤＢ１３０内の書出先のファイルを特定する情報及び登録すべき外部情報が記述された外部情報登録ジョブを用意し、これをジョブ処理部１１０に実行させることで、その外部情報を保守情報ＤＢ１３０内のそのファイルに書き込む。保守情報ＤＢ１３０に登録する外部情報としては、例えばデバイス利用計画１３６がある。

予兆分析ジョブ生成部１４０は、予兆分析ジョブのジョブデータを生成する。予兆分析ジョブとは、画像形成装置１００内での不具合事象の発生の予兆の有無（及び有る実施例では更にその予兆の緊急度合い）を分析し、分析の結果、予兆があると判定した場合に、その予兆を通知する予兆通知文書を印刷するジョブである。

予兆分析ジョブのジョブデータは、本体部分とバリアブルデータ部分とを含む。本体部分は、予兆分析及び通知に使用する１以上のフォームを指定する命令等により予兆分析及び通知の処理手順を記述している。バリアブルデータ部分は、本体部分で指定されたフォームに対して適用されるバリアブルデータを表している。ここで、フォームとは、ページ記述言語で記述された処理プログラムの一種であり、基本的にはバリアブルデータから印刷用の画像を生成（描画）するための手順を表す。ただし、フォームは、必ずしも描画命令を含んでいる必要はない。バリアブルデータに対する演算や条件判定等の手順を表し、描画命令を含まないフォームもある。また、バリアブルデータとは、バリアブル印刷においてフォーム中の変数に代入され得るデータ値群を含むデータである。

予兆分析ジョブのジョブデータのうち本体部分は、予兆分析ジョブ生成部１４０が有している固定のデータである。これに対してバリアブルデータ部分は、予兆分析ジョブ生成部１４０が保守情報ＤＢ１３０中の消耗品情報１３２やデバイス情報１３４から動的に生成する。すなわち、予兆分析ジョブ生成部１４０は、予兆分析ジョブのジョブデータを生成するタイミングが到来すると、保守情報ＤＢ１３０からその時点でのデータ値を収集し、バリアブルデータ部分を構成する。

予兆分析フォーム保管部１５０は、予兆分析ジョブで用いられるフォーム群を保管している。保管されるフォームは、フォーム登録部１６０を介してユーザにより登録される。

＜予兆分析のためのフォームの例＞
図２に、予兆分析フォーム保管部１５０に保管されるフォームの例を示す。図２に例示するフォームは、予兆条件フォーム２００と予兆印字フォーム２１０という２つのフォームから構成される。大略的には、予兆条件フォーム２００は、予兆の検知条件、すなわち不具合の予兆があると判定する条件を記述するフォームであり、別の角度から言えば、予兆の有無を判定する処理を記述するフォームである。予兆印字フォーム２１０は、予兆があると判定された場合に印字する印字内容と、その印字内容を印刷出力する処理を記述するフォームである。これらのフォームは、ＶＩＰＰ（Variable data Intelligent Postscript Printware）という、米国Ｘｅｒｏｘ社が開発したＰｏｓｔＳｃｒｉｐｔベースのバリアブル印刷用ページ記述言語を用いて記述されている。ＶＩＰＰは米国Ｘｅｒｏｘ社にて公開されている。

図２の例において、「%」で始まる行はコメント行である。また「SETVAR」という命令は、変数に値を設定する命令である。

例えば予兆条件フォーム２００の２行目の「/VARTonerColor Type VSUB2 SETVAR」という記述は、変数「VARTonerColor」（トナーの色を示す）に対し、ジョブデータ内のバリアブルデータ中の「Type」フィールドの値を設定する命令を表す。また、同フォームの７〜１３行目の「/VARCheck VARTonerPercent 10 le ...（中略）...}ENDIF} SETVAR」という記述は、変数「VARTonerPercent」（トナー残量のパーセンテージを示す）の値が１０未満である場合は変数「VARIsPredictor」（トナー切れの予兆の判定結果を示す）に値「true」（「予兆あり」を示す）を設定し、そうでない場合は変数「VARIsPredictor」に値「false」（「予兆なし」を示す）を設定する命令を表す。すなわち、７〜１３行の記述は、予兆ありと判定する条件を記述している。このように、予兆条件フォーム２００は、後述する予兆印字フォーム２１０やこれらフォームを呼び出すジョブデータ（後で図４を参照して説明する）で用いられる変数に値を設定する処理を表し、それら変数の中にはトナー残量切れの予兆の有無の判定結果を表すものも含まれる。

予兆印字フォーム２１０は、予兆条件フォーム２００で設定された変数の値を用いて、トナー切れの予兆があると判定された場合の予兆通知を印字する処理を記述している。予兆印字フォーム２１０は、全体的には、２行目の変数「VARPrint」に対して３行目から最終行の命令「SETVAR」までの記述の実行結果を代入する命令を示す。より詳細には、４〜５行目の記述２１２は、変数「VARMsg」に対して、「＜ａ＞トナーの残りが＜ｂ＞％になりました」（ただし＜ａ＞には変数「VARTonerColor」が示すトナーの色が代入され、＜ｂ＞には変数「VARTonerPercent」が示すトナー残量のパーセンテージが代入される）という文字列を設定する命令を示す。

また６〜１２行目の記述２１４は、変数「VARMode」（画像形成装置１００の動作モードを示す）の値が３より小さい場合には、変数「VARMsg」の値（上述の文字列）を文字列として描画（命令「SHL」）し、そうでない場合には、変数「VARMsg」の値をＱＲコード（登録商標）として描画する命令を示す。

記述２１４の例では、変数「VARMsg」の値をＱＲコードに変換することで、画像形成装置１００のユーザに対してその情報を秘匿できるようにしている。保守サービス業者はＱＲコードが表す内容を読み取り装置により読み取ることが可能であるが、読み取り装置を持たない画像形成装置１００のユーザはそのＱＲコードが読み取れない。この例では、変数「VARMsg」の値が、ユーザに秘匿するか否かの判定対象であり、変数「VARMode」の値が３未満であることが、その秘匿判定対象を「秘匿する」と判定する秘匿条件である。この秘匿条件が満たされると、その秘匿判定対象の情報はＱＲコードという人間に読み取れない形式に変換され、印刷されることとなる。これに対し、秘匿条件が満たされない場合は、秘匿判定対象は、人間に読み取れる文字列の形で印刷される。

記述２１６は、変数「VARTonerStock」（トナーカートリッジの在庫数を示す）の値が２より小さい場合に、「＜ａ＞トナーの在庫は＜ｃ＞個です。」（＜ｃ＞には変数「VARTonerStock」が示す在庫数が代入される）という文字列と、「ＩＤ：＜ｄ＞を購入してください。」（＜ｃ＞には変数「VARTonerSerial」が示すシリアル番号（トナーの識別情報）という文字列を描画し、更に動作モードが「２」である場合はそのシリアル番号をＱＲコードで描画する、という命令を示す。

記述２１６の例では、トナーの識別情報（シリアル番号）は、かならず文字列の形で印刷されると共に、動作モードが「２」であるという条件を満たす場合には更にＱＲコードの形でも印刷される。この場合のＱＲコードは、ユーザに対する秘匿を主たる目的とするものではなく、欠乏したトナーカートリッジの再注文の際のシリアル番号の入力誤りを避けることを主たる目的としている。シリアル番号を人間が読み取って発注システムに入力する方式では誤入力が生じる可能性が少なくないが、シリアル番号を表すＱＲコードを読み取り装置で読み取って入力することとすれば、そのような誤入力は防げる。

例えばトナーの残量が８％、トナーカートリッジの在庫数が１個、動作モードが「２」という状況でジョブ処理部１１０が図２のフォームを実行すると、図３に示すシアン（Ｃｙａｎ）トナーの購入を促す予兆通知が印刷部１２０から印刷出力されることになる。

図２はトナー切れの予兆を検知して通知するためのフォームの例であるが、感光体ドラム等の他の部分についても、検知及び通知したい予兆毎にそれぞれ同様のフォームを作成し、予兆分析フォーム保管部１５０に登録しておく。

＜ジョブデータの例＞
図４に、予兆分析ジョブ生成部１４０が生成する予兆分析のジョブデータの一例を示す。例示するジョブデータはＶＩＰＰで記述されており、その冒頭の１〜４行目の記述３１０は、印刷に用いる用紙のサイズや色を指定する記述である。その後に続く６〜１０行目の記述３２０は、変数「FORMName」に対して値「Form1」及び「Form2」を順に適用する処理を表している。「Form1」及び「Form2」はそれぞれ特定のフォームの識別情報であり、例えば図２に示した予兆条件フォーム２００及び予兆印字フォーム２１０を指し示す。すなわち、ジョブ処理部１１０がこの記述３２０を実行すると、それら２つのフォームが順に呼び出され、実行されることになる。

記述３３０は、変数「FORMName」が示す各フォームを実行し、その実行の結果変数「VARIsPredictor」の値が「true」ならば変数「VARPrint」に設定された記述を実行し、この「VARPrint」の実行の際、描画位置が改ページ位置に達した場合に改ページ処理（PAGEBRK）を行う、という処理を示す。ここで、変数「VARIsPredictor」の値は、記述３２０により呼び出した予兆条件フォーム２００（図２参照）の実行により予兆ありと判定された場合には「true」に設定され、予兆なしと判定された場合には「false」に設定されている。また。変数「VARPrint」には、記述３２０により呼び出した予兆印字フォーム２１０（図２参照）の実行により、予兆通知の印刷指示の命令群が設定されている。

記述３３０によれば、予兆印字フォーム２１０の実行により設定された変数「VARPrint」に設定された予兆通知の印刷指示が実行されるのは、予兆条件フォーム２００の実行により予兆ありと判定された場合のみである。予兆なしと判定された予兆については変数「VARPrint」に設定された印刷指示は実行されず、したがってその予兆については何の印刷も行われない。

以上の記述３１０〜３３０は、予兆分析ジョブ生成部１４０が保持している固定的なデータである。

なお、記述３２０のように実行するフォームの識別情報に記述する代わりに、実行すべきフォームが保存されているフォルダの識別情報を記述してもよい。この場合、ジョブ処理部１１０がその記述を実行すると、そのフォルダに保存されている各フォームを順に取り出して実行する。

記述３４０は、このジョブにおけるバリアブルデータを記述した部分である。この例のバリアブルデータは、「Group」（グループ）、「Type」（タイプ）、「PrintMode」（画像形成装置１００の動作モード）、「Param1」（パラメータ１）、「Param2」（パラメータ２）、「Param3」（パラメータ３）の６つのフィールドからなる表をＣＳＶ（comma-separated values）で表現している。このうちの「Group」は、画像形成装置１００の消耗品、部品のグループ名を示す。「Type」は、消耗品、部品のタイプ名を示す。記述３４０に示される４つのレコードでは、グループ名がいずれも「Toner」（トナー）であり、タイプ名はそれぞれ「KeyPlate」（黒）、「Cyan」（シアン）、「Yellow」（イエロー）、「Magenta」（マゼンタ）である。すなわち、それら各レコードは、画像形成装置１００に装着された黒、シアン、イエロー、マゼンタの４色のトナーの情報を示している。また「Param1」は当該レコードに対応する色のトナーの残量パーセンテージを、「Param2」はそのトナーの在庫数を、「Param3」はそのトナーの識別情報を示す。このバリアブルデータの記述３４０は、予兆分析ジョブ生成部１４０が、予兆分析ジョブを生成するタイミングが到来した際に、その時点で保守情報ＤＢ１３０が保持しているデータを参照して動的に生成する。

図４のジョブデータは、図２のトナー切れの予兆を検知するための予兆条件フォーム２００と、トナー切れの場合の予兆通知を印刷するための予兆印字フォーム２１０という１組のフォームを呼び出すものであった。しかしこれは一例にすぎない。例えば、検知したい予兆毎に予兆条件フォーム２００と予兆印字フォーム２１０の組（以下、「フォーム組」と呼ぶ）を用意し、１つのジョブデータのフォーム呼び出しの記述３２０からそれら個々の予兆に対応するフォーム組を順に呼び出して実行するようにしてもよい。なお、予兆条件フォーム２００に記載される予兆の判定条件や、予兆印字フォーム２１０に記載される予兆通知の印字内容は、予兆毎に異なる。この例では、１つのフォーム組に予兆条件フォーム２００と予兆印字フォーム２１０とがそれぞれ１つずつ含まれていたが、これは必須のことではない。例えば、複数の予兆条件フォーム２００と１つの予兆印字フォーム２１０からなるフォーム組が存在してもよい。この場合、フォーム組に属するフォーム群を呼び出すと、複数の予兆条件フォーム２００の実行により複数の不具合事象についての予兆の有無が判定され、そのうち予兆ありと判定された不具合事象についての予兆通知内容が、予兆印字フォーム２１０の実行により印刷されることになる。また複数の予兆条件フォーム２００と複数の予兆印字フォーム２１０からなるフォーム組等も存在してよい。

予兆検知結果の印刷（描画）処理を表す記述３３０は、複数のフォーム組を呼び出す場合にも対応可能である。なお、このように複数の予兆の検知及び通知（印刷）を１つのジョブデータにより実現する場合、予兆分析ジョブ生成部１４０は、それら複数の予兆の各々の分析に必要なデータを保守情報ＤＢ１３０から取得し、それら取得したデータをバリアブルデータの記述３４０としてジョブデータに組み込む。

ジョブデータ中のフォーム呼び出しの記述（図４の符号３２０）と同じ記述方式でジョブデータを呼び出すことも可能である。すなわち、記述３２０の中に、フォーム名に代えて、呼び出したいジョブデータを一意的に指し示す識別情報（ジョブ名）を記述することで、ジョブデータから別のジョブデータを呼び出すことができる。

１つの例では、図５に示すように個々の予兆に対応するジョブデータを中間ジョブとして定義しておき、メインのジョブデータである印字画像生成ジョブからそれら複数（Ｎ個。Ｎは２以上の数）の中間ジョブを呼び出すことも可能である。個々の中間ジョブは、予兆条件フォーム２００及び予兆印字フォーム２１０を呼び出す記述と、それらフォーム２００及び２１０に適用されるバリアブルデータとを含む。例えば、図中の「中間ジョブ１」は、「フォーム１」及び「フォーム２」を呼び出す記述と、それらフォームで用いられるバリアブルデータである「データ１」を含んでいる。この例では、中間ジョブとは、メインのジョブとフォームとの間に位置するジョブ、すなわち最上位のメインジョブから呼び出され、最下位のフォームを呼び出すジョブ、を意味する。

図５の例では、メインの「印字画像生成ジョブ」は、中間ジョブ呼び出しの記述を含むが、フォーム呼び出しの記述やバリアブルデータを含まない。ただし、これはあくまで一例に過ぎず、メインのジョブデータが、フォーム呼び出しの記述やバリアブルデータを含んでもよい。

図５の例は、中間ジョブから呼び出すのはフォームのみであったが、中間ジョブが別の中間ジョブを呼び出すようにしてもよい。すなわち、この例では中間ジョブとは別のジョブから呼び出されるジョブのことであり、中間ジョブは他の中間ジョブ及びフォームのうちの少なくとも一方を呼び出す。

ジョブが他のジョブを呼び出す仕組みを利用して、ジョブ群を構造化することも可能である。図６に、構造化されたジョブ群の一例を示す。この例では、最上位の「定時チェックジョブ」及び「起動時チェックジョブ」と最下位のフォーム群との間に、２段階の中間ジョブの層がある。これら２段階のうちの下位側の中間ジョブは、この例ではフォームを呼び出す。例えば「トナーチェックジョブ」は、トナー切れの予兆をチェックするジョブであり、トナー切れの判定処理を記述した「トナー切れ予兆条件フォーム」と、トナー切れの予兆があると判定した場合の印字処理を記述した「トナー切れ予兆印字フォーム」とを呼び出す。なお、「トナーチェックジョブ」のジョブデータには、それらフォームの呼び出しの記述の他にそれらフォームの処理で用いられるトナー残量等を示すバリアブルデータが含まれる。

また図６の例では、２段階のうちの上位側の中間ジョブは、下位側の中間ジョブを呼び出す。例えば「消耗品チェックジョブ」は、下位側の中間ジョブである「トナーチェックジョブ」と「用紙チェックジョブ」とを呼び出す。ここで「用紙チェックジョブ」は、給紙部の用紙切れの予兆をチェックするジョブであり「用紙切れ予兆条件フォーム」と、「用紙切れ予兆印字フォーム」とを呼び出す。同様に、上位側の「装置状態チェックジョブ」は、印刷部１２０の印刷画質劣化の予兆を検知する「画質チェックジョブ」と、感光体の劣化（寿命到来）の予兆を検知する「感光体チェックジョブ」とを呼び出す。この例では、「消耗品チェックジョブ」及び「装置状態チェックジョブ」は、バリアブルデータを含まない。

また図６の例では、最上位のジョブは、上位側の中間ジョブを呼び出す。例えば、３０分ごとなどのあらかじめ定めた時間毎に実行される「定時チェックジョブ」は、「消耗品チェックジョブ」を呼び出す。また、画像形成装置１００が起動されたときに実行される「起動時チェックジョブ」は、「消耗品チェックジョブ」と「装置状態チェックジョブ」とを呼び出す。

このような構造では、最上位のジョブを実行すると、その最上位のジョブから上位側の中間ジョブが呼び出される。そして、呼び出された上位側の中間ジョブから下位側の中間ジョブが呼び出され、この下位側の中間ジョブからフォームが呼び出される。例えば「起動時チェックジョブ」の実行が指示された場合、最終的には、図６に例示したすべてのフォーム（トナー切れ予兆条件フォーム、トナー切れ予兆印字フォーム、用紙切れ予兆条件フォーム、用紙切れ予兆印字フォーム、画質劣化予兆条件フォーム、画質劣化予兆印字フォーム、感光体寿命予兆条件フォーム、及び感光体寿命予兆印字フォーム）が実行されることになる。

ユーザは、このように階層構造化されたジョブ群の中から所望のものを指定し、画像形成装置１００に実行させることができる。例えば、トナーチェックジョブを指定して実行させることもできれば、消耗品チェックジョブを指定することでトナーチェックジョブと用紙チェックジョブの両方を実行させることもできる。

また、あらかじめ定めたスケジュール又は条件に従ってあらかじめ定めたジョブを実行するようにしてもよい。例えば、毎正時に定時チェックジョブを実行する等のスケジュールを用いたり、画像形成装置１００が起動したという条件を満たすときに起動時チェックジョブを実行したりする等である。

＜処理手順の例＞
次に、本実施形態における予兆分析のジョブの実行手順の一例を説明する。

予兆分析のジョブは、ユーザからそのジョブの実行指示が明示的にあった場合、又はスケジュールに定められたそのジョブの実行タイミングが到来した場合等のように、ジョブの実行条件が満たされた場合に実行される。このジョブ実行では、まず予兆分析ジョブ生成部１４０が、指定されたジョブのジョブデータを作成する。前述（図４参照）の通り、ジョブデータは、フォームや他のジョブの呼び出し等を記述した固定の本体部分（図４の記述３１０，３２０，３３０）と、呼び出されるフォームが用いるバリアブルデータ部分３４０とを含んでいる。したがって、予兆分析ジョブ生成部１４０は、保守情報ＤＢ１３０の情報からそのバリアブルデータ部分を作成し、本体部分と結合することで、最新の保守情報を反映したバリアブルデータを有するジョブデータを作成する。

予兆分析ジョブ生成部１４０は、実行対象のジョブのバリアブルデータ部分の各フィールド（図４の例では、Group、Type、PrintMode、Param1、Param2、Param3）がそれぞれ保守情報ＤＢ１３０のどのデータ項目に対応しているかの対応関係の情報を有している。あるいはそのような対応関係の情報にアクセス可能となっている。予兆分析ジョブ生成部１４０は、その対応関係の情報に従い、実行対象のジョブのバリアブルデータ部分の各フィールドに対応するデータ項目を特定し、そのデータ項目のデータを保守情報ＤＢ１３０から収集する。そして、収集したデータをフィールド名と合わせて、バリアブルデータ部分を作成し、作成したバリアブルデータ部分を本体部分と結合することでジョブデータを完成させ、完成したジョブデータをジョブ処理部１１０に入力して処理させる。

ジョブ処理部１１０は、予兆分析ジョブ生成部１４０から入力されたジョブデータを実行する。このジョブデータの実行では、ジョブデータ内に記述されたフォーム呼び出しが順に実行され、これにより予兆の有無が判定され（予兆条件フォーム）、予兆が有ると判定された場合には、予兆通知の印刷データが生成される（予兆印字フォーム）。ここでの判定等の処理に、ジョブデータ中のバリアブルデータ部分３４０に示される各フィールドの値が用いられる。そして、予兆通知の印刷データが生成された場合、それが印刷部１２０から印刷出力される。

＜予兆の重複通知防止＞
ある予兆を検知してこれを知らせる予兆通知を印刷出力した後、その予兆が解消されないまま再び同じ予兆を検知した場合に、その予兆の通知を再び印刷出力したのでは、用紙の無駄である。また、最初の予兆通知の印刷出力に基づきユーザや保守サービス業者が予兆解消のための手配、準備を行っている場合があり、そのような場合にその予兆が解消されないまま再び同じ予兆の通知が出力されると混乱を招くおそれがある。そこで、予兆通知を印字出力したあと、当該予兆に係る不具合が解消されない状態で再度その予兆の通知を印刷出力することがないよう、例えば予兆印字フォーム２１０（図２）に以下のようなＩＦ文（ａ）の制御構造を埋め込む。

IF検知した予兆が前回の判定結果から悪化している {
<印字処理>
}
・・・（ａ）

ここで「<印字処理>」は、予兆条件フォーム２００（図２）の実行により検知された予兆についての予兆通知の印字処理を記述する部分であり、例えば図２に例示した予兆印字フォーム２１０の記述内容全体がこれにあたる。この記述内容を実行するかどうかを、「IF 検知した予兆が前回の判定結果から悪化している」というＩＦ文（ａ）で制御するのである。このＩＦ文は、当然ながら実際のページ記述言語の記述ではなく、あくまで判定の意味を概念的に表現したものである。このＩＦ文（ａ）の判定では、今回の予兆条件フォーム２００の実行による予兆の判定結果と、ログに記録されている前回の予兆分析ジョブの実行時の当該予兆の判定結果とを比較する。今回の判定結果が前回より悪化していれば、このＩＦ文（ａ）の判定結果が肯定（Ｙｅｓ）となり、そのＩＦ文（ａ）の後に続く「<印字処理>」が実行されることになる。例えば、今回の予兆分析ジョブの実行でトナー切れの予兆が「あり」と判定された場合を考える。この場合、ログに記録されている前回の予兆分析ジョブでのトナー切れ予兆の判定結果が「予兆なし」であれば、前回に比べ今回トナー切れの予兆が悪化しているので上述のＩＦ文（ａ）の判定結果はＹｅｓとなり、「<印字処理>」が実行される。これに対し、ログに記録されている前回の予兆分析ジョブでのトナー切れ予兆の判定結果の「予兆あり」であれば、今回のトナー切れの予兆は前回から比べて悪化していないので、ＩＦ文（ａ）の判定結果はＮｏとなり「<印字処理>」は実行されない。

この例では、例えばジョブ処理部１１０が記録する予兆分析ジョブの処理履歴を示すログ情報に、そのジョブにおける予兆の判定結果を含める。そして、予兆分析ジョブ生成部１４０が予兆分析のジョブデータを生成する際、記録されているログ情報群の中から、そのジョブデータの判定対象の予兆についての前回の判定結果を取得し、取得した判定結果をジョブデータ中のバリアブルデータ部分３４０内に含める。予兆印字フォーム２１０を実行するジョブ処理部１１０は、そのバリアブルデータ部分３４０に含まれる前回の予兆の判定結果を参照して、上記ＩＦ文（ａ）の判定を行う。

なお、予兆分析ジョブで判定する予兆の種類が回ごとに異なる場合、今回検知された予兆が前回は判定されていないという場合もある。このような場合を考慮に入れると、前述のＩＦ文（ａ）における「前回の判定結果」とは、「今回検知した予兆と同じ予兆について判定した、今回の１つ前の回における判定結果」という意味である。

また、上述の例では、予兆の段階として「あり」、「なし」の２段階しかなかったので、前回の「なし」から今回「あり」に変わる場合が、予兆の「悪化」であった。これに対し、同じ「予兆あり」でも複数段階の緊急度を設けることも考えられる。この場合、今回検知された予兆の緊急度が前回検知された当該予兆の緊急度よりも悪化した、すなわち緊急度がより高くなった場合に、上記ＩＦ文（ａ）の判定結果がＹｅｓとなり、「<印字処理>」が実行されることとなる。

なお、予兆の緊急度の判定は、その予兆に対応する予兆条件フォーム２００の中にその判定の処理内容を記述する式を入れることで実現できる。例えば、図２の予兆条件フォーム２００では、変数「VARIsPredictor」のとる値は「false」（予兆なし）か「true」（予兆あり）の２段階であったが、これを例えば「予兆なし」、「緊急度が低い予兆あり」、「緊急度が中程度の予兆あり」、「緊急度が高い予兆あり」などの多段階としてもよい。この場合、例えばトナーの残量（変数「VARTonerPercent」の値）の１５％以上であれば「予兆なし」、１０％以上１５％未満であれば「緊急度が低い予兆あり」、５％以上１０％未満であれば「緊急度が中程度の予兆あり」、５％未満であれば「緊急度が高い予兆あり」等と判定すればよい。

＜印刷ジョブ実行中の予兆通知＞
例えば予兆分析ジョブを定時に実行する等の場合、画像形成装置１００が印刷ジョブを実行している最中に予兆分析ジョブを実行することになることがある。予兆分析ジョブのうち予兆の判定処理（予兆条件フォーム２００の実行）は、画像形成装置１００の内蔵コンピュータのオペレーティングシステムがマルチタスク処理に対応しているのであれば、印刷ジョブのための画像処理等の情報処理と並列的に実行可能である。しかし、複数のジョブの印刷出力を印刷部１２０で並列実行することはできないので、予兆通知の印刷が必要になった場合には、実行中の印刷ジョブを一時中断して予兆通知を印刷するか、実行中の印刷ジョブの印刷出力が終了するのを待って予兆通知を印刷するかのいずれかとなる。ここで例えば一律に実行中の印刷ジョブを中断して予兆通知を印刷することとした場合、緊急性があまり高くない予兆通知の出力のために重要な印刷ジョブの処理が遅れたり、印刷ジョブの出力結果に混じった予兆通知の文書を取り出す手間が増えたりする等の問題が生じる。そこで、この例では、予兆と印刷ジョブのそれぞれの重要性を考慮に入れて、予兆通知の出力ために印刷ジョブを一時中断するか否かを制御する。

このような制御のためには、例えば予兆印字フォーム２１０（図２）に以下のようなＩＦ文（ｂ）の制御構造を埋め込む。

IF 現在実行中の印刷ジョブの優先度 検知した予兆の優先度 le 検知した予兆が前回の判定結果から悪化している and {
<印字処理>
}
・・・（ｂ）

すなわちこの例では、予兆通知の印字処理を記述する部分「<印字処理>」（例えば図２に例示した予兆印字フォーム２１０の記述全体）を実行するかどうかを、「ＩＦ 現在実行中の印刷ジョブの優先度 検知した予兆の優先度 le 検知した予兆が前回の判定結果から悪化している and」というＩＦ文（ｂ）で制御する。このＩＦ文（ｂ）はあくまで概念的な表現である。このＩＦ文（ｂ）は、「現在実行中の印刷ジョブの優先度」が「検知した予兆の優先度」未満である（「le」）という条件と、「検知した予兆が前回の判定結果から悪化している」という前節（「予兆の重複通知防止」）で説明した条件との両方（「and」）が満たされた場合に、判定結果が肯定（Ｙｅｓ）となる。

ＩＦ文（ｂ）の前半の条件に関して、印刷ジョブの優先度は重要な印刷ジョブほど高い値に設定され、予兆の優先度は緊急度が高い予兆ほど高い値に設定される。例えば、予兆の種類によって緊急性は異なるので、予兆の優先度を予兆の種類に応じて定めてもよい。例えば、画質劣化の予兆の優先度は例えば３段階評価（値が大きいほど優先度が高い）で「１」、トナー切れの予兆の優先度は「３」とするなどである。また、予兆の有無だけでなく、予兆の緊急度も判定する例では、予兆の種類と緊急度の組み合わせに応じて優先度を定めればよい。同じ種類の予兆の場合、緊急度の上昇に応じて優先度が単調に上昇するように定めればよい。

ＩＦ文（ｂ）の前半の条件の処理には、現在実行中の印刷ジョブの優先度の情報が必要となる。このためには、例えば、予兆分析ジョブ生成部１４０がジョブデータを生成する際、保守情報ＤＢ１３０内のデバイス利用計画１３６から、その生成の時点で画像形成装置１００が実行している印刷ジョブの優先度の情報を取得し、その情報をジョブデータのバリアブルデータ部分３４０（図４参照）に含め、予兆印字フォーム２１０のＩＦ文（ｂ）からそのバリアブルデータ部分３４０内の印刷ジョブの優先度を参照すればよい。なお、デバイス利用計画１３６から、ジョブデータの生成の時点で実行されている印刷ジョブが無いことが分かった場合は、予兆分析ジョブ生成部１４０は、例えば予兆の優先度が取り得る最低値よりも更に低いあらかじめ定めた優先度を「現在実行中の印刷ジョブの優先度」としてバリアブルデータに組み込む等により、ＩＦ文（ｂ）の前半の条件が必ず満たされるようにすればよい。

「検知した予兆の優先度」は、当該予兆分析ジョブが検知対象としている予兆の優先度なので、既知である。その既知の値を予兆印字フォーム２１０のＩＦ文（ｂ）内に組み込んでおけばよい。

ＩＦ文（ｂ）の制御構造を含む予兆印字フォーム２１０を実行した場合、検知した予兆が前回の判定結果から悪化していたとしても、検知した予兆の優先度が実行中の印刷ジョブの優先度よりも低ければ、予兆通知は印刷出力されないことになる。ジョブ処理部１１０は、このとき実行した予兆分析ジョブのログ情報に、予兆通知を出力しなかった旨の記録を含めるようにしてもよい。

予兆分析ジョブ生成部１４０は、予兆分析ジョブのジョブデータを生成する際、そのジョブでの分析対象の予兆についての前回の判定結果をログ情報から取得するが、その前回の判定結果のログに予兆通知を出力しなかった旨の情報が記録されている場合、更に前の予兆分析ジョブのログに遡って調べる。このようにして順にログを遡っていく中で、最初に見つかった、予兆通知を出力した回の判定結果を取得し、その判定結果をジョブデータ内のバリアブルデータ部分に組み込む。そして、ジョブ処理部は、そのジョブデータから呼び出される予兆印字フォーム２１０を実行する際、バリアブルデータ部分内のその判定結果を参照することで、上記ＩＦ文（ｂ）の後半の条件「検知した予兆が前回の判定結果から悪化している」の判定を行う。

以上の例では、ＩＦ文（ｂ）の判定結果がＮｏの場合、予兆通知の印刷が行われないまま、その予兆分析ジョブが終了する。したがって、その予兆分析ジョブが対象としていた予兆について再度判定がされるのは、同じ予兆を対象とする次の予兆分析ジョブが実行されるタイミングとなる。しかし、これは必須のことではない。この代わりに、予兆分析ジョブにおいて予兆通知を印刷出力しなかった場合に、同じ予兆分析ジョブを、ジョブ処理部１１０のジョブの待ち行列の、そのとき実行中の印刷ジョブの次に追加してもよい。これによりその印刷ジョブの終了後に同じ予兆通知ジョブが再度実行されるので、スケジュール上で同じ予兆分析ジョブが再度実行されるのを待たずに予兆通知を行うことができる。

以上、本発明の実施の形態を説明した。以上に説明した実施の形態は、あくまで例示的なものにすぎず、本発明の技術的思想の範囲内で様々な変形や改良が可能である。

例えば、予兆条件フォーム２００の実行の結果、予兆あり（あるいは予兆が前回から悪化した）と判定された場合に、デバイス利用計画１３６に示される画像形成装置１００の空き時間のいくつかを、判定した予兆に対する保守作業が可能な時間帯の例として、予兆通知に含めて印刷出力するようにしてもよい。これには、例えば、予兆分析ジョブ生成部１４０が、予兆分析ジョブのジョブデータを生成する際、保守情報ＤＢ１３０内のデバイス利用計画１３６から、その時点以降の直近の空き時間帯を所定数求め、求めた各空き時間帯の情報をそのジョブデータのバリアブルデータ部分３４０に含める。そして、予兆ありと判定された場合に、そのバリアブルデータ部分３４０内の空き時間帯の情報を、検知した予兆に対する保守作業の候補時間帯として印字する旨の命令を、予兆印字フォーム２１０に組み込んでおけばよい。

また、以上の例では、ジョブデータやフォームを記述するページ記述言語としてＶＩＰＰを用いたが、もちろんこれに限らず、他のページ記述言語を用いてもよい。

また、以上の例では、画像形成装置１００のユーザに秘匿したい情報についてはＱＲコードに変換して印刷した（図２の記述２１４参照）が、秘匿化の手法はＱＲコードに限定されない。他の種類の二次元コードや、バーコード等の一次元コードを用いてもよい。また、秘匿したい情報を暗号化し、暗号化結果のデータをＱＲコード等に変換してもよい。また、機械読み取り以外の方式での秘匿化も可能である。例えば、予兆通知の内容を米国Ｘｅｒｏｘ社が開発したコレレーションテキストの形に変換することにより、その内容を秘匿化してもよい。コレレーションテキストは、ハーフトーンスクリーン同士の空間的相関を利用することで、印刷された内容がそのままでは人間の目には読み取れないようにする技術である。コレレーションテキストについては、例えば以下のＵＲＬにその概要が示されている。
http://www.xeroxtechnology.com/xt.nsf/p02?readform&unid=2179E8DE6FB58D61852577200062AA09
印刷されたコレレーションテキストは、専用の透明フィルムを重ねることで、人間の目に読み取れるようになる。また、自然光や一般的な照明光の下では人間の目には読み取れないが、紫外線などの特別な光をあてることで読み取れる特別なインクを用いて印刷することで、印刷内容の秘匿化を行ってもよい。

以上に説明したように、この実施形態では、予兆分析ジョブを表すジョブデータ及びそのジョブデータから呼び出されるフォーム（及び他のジョブデータ）をページ記述言語で記述した。このため、本実施形態の予兆分析処理は、画像形成装置が搭載するコンピュータのハードウエアやオペレーティングシステムによらず、そのページ記述言語を処理できるジョブ処理部を搭載した画像形成装置ならばどのような画像形成装置でも実行できる。

以上に例示した画像形成装置１００のうちの情報処理を実行する部分（図１に示す構成要素のうち、印刷部１２０以外の部分）は、例えば、汎用のコンピュータに当該装置の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで言うコンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）、フラッシュメモリ等の二次記憶を制御する二次記憶コントローラ、各種Ｉ／Ｏ（入出力）インタフェース、無線又は有線のネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤ、ブルーレイディスクなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、フラッシュメモリ等の二次記憶装置に保存され、コンピュータにインストールされる。二次記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

なお、図１の例では、ジョブ処理部１１０、保守情報ＤＢ１３０、予兆分析ジョブ生成部１４０、予兆分析フォーム保管部１５０、フォーム登録部１６０が画像形成装置１００内に設けられていたが、これらのうち１以上が、画像形成装置１００の外部の、画像形成装置１００と通信可能なコンピュータ上に設けられていてももちろんよい。

１００ 画像形成装置、１１０ ジョブ処理部、１２０ 印刷部、１３０ 保守情報ＤＢ、１３２ 消耗品情報、１３４ デバイス情報、１３６ デバイス利用計画、１４０ 予兆分析ジョブ生成部、１５０ 予兆分析フォーム保管部、１６０ フォーム登録部、２００ 予兆条件フォーム、２１０ 予兆印字フォーム。

Claims (3)

1. コンピュータを、
   画像形成装置の不具合事象の予兆を検知する検知手段、
   前記検知手段が検知した予兆について通知する予兆通知文書を前記画像形成装置に印刷させる制御を行う予兆通知制御手段であって、前記予兆通知文書のうちあらかじめ定められた秘匿対象部分の内容については当該内容を秘匿化した秘匿化画像を印刷させる予兆通知制御手段、
   として機能させるためのプログラムであって、
   前記プログラムはバリアブル印刷に対応したページ記述言語で記述されており、
   前記検知手段は、バリアブル印刷の印刷データ中のバリアブルデータに含まれる、前記不具合事象の判定材料となる前記画像形成装置の状態データから、当該不具合事象の予兆を検知する、
   ことを特徴とするプログラム。
2. コンピュータを、
   １以上の不具合事象について、データベースに登録されているそれら不具合事象の判定材料となる前記画像形成装置の状態データから、請求項１に記載の検知手段が予兆の検知に用いるバリアブルデータを生成する生成手段、
   請求項１に記載のプログラムを前記コンピュータに実行させる命令と、前記生成手段が生成した前記バリアブルデータとを含む、ページ記述言語で記述されたプログラムを生成し、生成したプログラムを前記コンピュータに実行させる手段、
   として機能させるためのプログラム。
3. コンピュータを、
   画像形成装置の不具合事象の予兆を検知する検知手段、
   前記検知手段が検知した予兆について通知する予兆通知文書を前記画像形成装置に印刷させる制御を行う予兆通知制御手段であって、前記予兆通知文書のうちあらかじめ定められた秘匿対象部分の内容については当該内容を秘匿化した秘匿化画像を印刷させる予兆通知制御手段、
   として機能させるためのプログラムであって、
   前記予兆通知制御手段は、前記検知手段が検知した予兆の優先度が現在実行中の印刷処理の優先度より高い場合に、現在実行中の印刷処理を中断し、前記予兆通知文書を前記画像形成装置に印刷させる、ことを特徴とするプログラム。

Images