JP2007083682A - 画像形成装置及び画像形成方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】 メンテナンス作業中に生じるバックグランド・ジョブやフォアグランド・ジョブに対応しながら適正な控除処理を行なう。
【解決手段】 メンテナンス作業中に起動可能なジョブの種別をあらかじめ設定し、メンテナンス作業モード下でジョブ要求が発生したときは起動可能と設定されたジョブのみ起動を許可する。ジョブの重要性や緊急性に応じてメンテナンス作業中に起動可能なジョブの種別を設定しておけば、カスタマー・エンジニアがメンテナンス作業に集中できる環境を整えながら、重要性や緊急度の高いバックグランド・ジョブを適宜起動させ、顧客の利益を守ることができる。
【選択図】 図１５

Description

本発明は、ビリング・カウンタを用いて画像形成回数を管理する画像形成装置及び画像形成方法、並びにコンピュータ・プログラムに係り、特に、メンテナンス時におけるテスト・コピーなどの画像形成回数をビリング・カウンタで計数される通常の画像形成回数から控除処理する画像形成装置及び画像形成方法、並びにコンピュータ・プログラムに関する。

さらに詳しくは、本発明は、メンテナンス作業中にフォアグランド又はバックグランドで発生するジョブの要求に対応しながら適正な控除処理を行なう画像形成装置及び画像形成方法、並びにコンピュータ・プログラムに係り、特に、メンテナンス作業中に生じるバックグランド・ジョブによる割込みプリントを実行しながら適正な控除処理を行なう画像形成装置及び画像形成方法、並びにコンピュータ・プログラムに関する。

ドキュメンテーションが重要視される現代社会では、画像を高解像度且つ高品位に複製することができる画像形成装置が生活環境に深く浸透して久しい。この種の画像形成装置は、原初的には、スキャンした原稿の白黒画像を印刷用紙に複写するものであったが、カラー・コピーや拡大、縮小など複写形態が多様化するとともに、画像の高解像度化、高品質化が進んできている。また、複写機能の他に、プリンタやファクシミリ、コンテンツ・サービスなど複数の機能を搭載した複合複写機が広く普及してきている。

この種の画像形成装置の多くは、リース契約により調達され、ベンダがビリング・カウンタで画像形成回数を計数して、顧客に使用料を請求するという利用形態がとられる。

また、画像形成装置は、自動濃度調整機能が作動していても、設置されている環境（温度や湿度など）や、サプライの状態（感光体の疲労）や経時変化などの影響により画質が変化する。画像形成装置のエンジン部分に相当する電子写真プロセスは構造が複雑で、顧客が勝手に調整することは困難である。このため、大抵の場合、カスタマー・エンジニアが定期的に画像形成装置の設置場所に訪問してメンテナンスを行なうというメンテナンス契約が、顧客とベンダの間で交わされる。

画像形成装置のメンテナンス作業時には、装置の正常動作や画質の確認を行なうためにテスト・コピーやテスト・プリント（以下、併せて「テスト・コピー」とする）を行ない、さらには各種レポートのプリントなどを行なう。例えば、メンテナンス作業を実行したときのレポートを印刷出力する画像形成装置について提案がなされている（例えば、特許文献１を参照のこと）。

ここで、ビリング・カウンタにメンテナンスの都合で行なわれるこれらのコピー枚数が加算されると、メンテナンス契約の請求金額は顧客にとって不利な金額となることから、控除処理する必要がある。この控除処理は、基本的には、カスタマー・エンジニアが訪問したときのビリング・カウンタを書き留めておき、メンテナンス終了時のビリング・カウンタの値から訪問時のカウンタ値を減算した値をテスト・コピーの枚数として控除対象とする。

カスタマー・エンジニアは、一般に、メンテナンス作業を行なった際に、自社にメンテナンス作業の内容を報告する「サービス・レポート」（図２５を参照のこと）や、顧客にメンテナンス作業の記録を残す「保守完了報告書」（図２６を参照のこと）を記入するが、それぞれのフォームの中段付近には、メンテナンス終了時のビリング・カウンタの値を書き込む「終了メーター」と、訪問時のカウンタ値を書き留める「訪問メーター」の欄が設けられており、終了メーターから訪問メーターを引き算した値を控除対象として「メンテナンス作業」の欄に書き込む。

このような控除処理をカスタマー・エンジニアが手計算で行なうのは面倒であり、ミスを生じ易い。また、サービス・レポートや保守完了報告書などの各種レポートを、メンテナンスを行なった画像形成装置上で発行する場合には、レポート作成時にはレポートの枚数を考慮して終了メーターの値を記入しなければならないので、計算間違いを犯し易い。

カスタマー・エンジニアの手間を省くとともに、控除処理を正確に行なう必要がある。このため、試しコピー時にカウンタを止める画像形成装置（例えば、特許文献２を参照のこと）や、サービスマンの実施するメンテナンスの画像形成回数を全画像形成回数から差し引いてユーザによる画像形成枚数を算出する画像形成装置の管理システムについて提案がなされている（例えば、特許文献３を参照のこと）。

また、メンテナンス時には通常のカウンタを停止して、テスト・コピー用のカウンタを別に持つ画像形成装置（例えば、特許文献４を参照のこと）や、プリント画質に問題があると判定されたときに印刷枚数のカウンタをメンテナンス用のものに切り替えるシステム（例えば、特許文献５を参照のこと）について提案がなされている。

しかしながら、プリンタやファクシミリといった複数の機能を搭載した複合複写機の場合には、メンテナンス作業中であっても、ＬＡＮや公衆回線といった外部との接続回線を経由して、ファクシミリ受信やネットワーク・プリントといった複合機などの内部で起動若しくは動作するバックグランド・ジョブが生じる可能性がある。また、メンテナンス作業中に、顧客の緊急のコピーなどのように使用者が複合機などの操作パネル上で直接指示して要求するフォアグランド・ジョブが生じる可能性もある。これらのメンテナンス作業中の割り込みプリントに対応すると、メンテナンス・カウンタに、控除対象外の画像形成回数が計数され、正確な控除を行なえなくなる。カスタマー・エンジニアが手計算で控除処理を行なおうとすると、計算はより煩雑となり計算ミスを犯し易い。また、メンテナンス作業中にファクシミリ受信を複数回行なうと、その分だけ計算間違いを起こす可能性が高まる。勿論、これらの割込みプリントは、カスタマー・エンジニアにとってメンテナンス作業の妨げになる。

例えば、メンテナンス作業中はジャックを外す、あるいはＬＡＮを切断して、割込みプリントなどのジョブの起動を抑制することによって、カスタマー・エンジニアはメンテナンス作業に集中できるとともに、控除処理を正確に行ない易くなる。また、ネットワーク・プリントやフォアグランド・ジョブは、顧客にメンテナンス作業中の起動を控えてもらい、メンテナンス終了後に顧客が改めてジョブを再起動すればよい。しかしながら、ファクシミリ受信プリントのようなジョブは重要性や緊急性が高く、メンテナンスというベンダ側の都合で受信できなくするという不利益を顧客に及ぼすことは好ましくない。また、送信元のファクシミリがリダイヤル起動中に受信処理できなければ、データが消失してしまい、回復不能になってしまう。

メンテナンス作業中であっても、ファクシミリ受信やその他の重要性や緊急性の高いジョブは起動すべきである。そして、これらの割込みプリントによる画像形成回数は、控除対象から外して通常のビリング・カウントを行なうべきである。控除処理が正確に行なわれないと、顧客にとってもベンダにとっても不利益をもたらす。

例えば、カウンタに猶予値を設定する画像形成装置について提案がなされている（例えば、特許文献６を参照のこと）。この場合、カウンタ値が０になるまではテスト目的の画像形成動作の実行が許され、顧客をカウンタ値の不公平の増大による不利益から解放することができるが、控除対象となる画像形成回数に応じて正確に控除処理を行なっている訳ではない。

特開２００３−２４４３７５号公報 特開平６−９５４６３号公報 特開平８−１５２８２６号公報 特開２０００−３５２９１２号公報 特開２００３−９４７８３号公報 特開２００３−１５４８７号公報

本発明の目的は、メンテナンス時におけるテスト・コピーなどの画像形成回数をビリング・カウンタで計数される通常の画像形成回数から適正に控除処理することができる、優れた画像形成装置及び画像形成方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、メンテナンス作業中にフォアグランド又はバックグランドで発生するジョブの要求に対応しながら適正な控除処理を行なうことができる、優れた画像形成装置及び画像形成方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、メンテナンス作業中に生じるバックグランド・ジョブによる割込みプリントを実行しながら適正な控除処理を行なうことができる、優れた画像形成装置及び画像形成方法、並びにコンピュータ・プログラムを提供することにある。

本発明は、上記課題を参酌してなされたものであり、その第１の側面は、画像情報を出力する画像形成装置であって、フォアグランド又はバックグランドのジョブ要求に応じて画像情報を媒体上に形成する画像形成手段と、前記画像形成手段が実行した画像形成回数をビリング・カウントするカウンタと、当該装置のメンテナンス作業中に起動可能なジョブの種別の設定を受容する起動ジョブ可否設定手段と、ジョブ要求並びにメンテナンス作業の開始及び終了の指示を含んだ指示操作の入力を受容する入力手段と、前記入力手段からのメンテナンス作業の開始及び終了の指示操作に応じてメンテナンス作業モードの開始及び終了を行なう動作制御手段と、前記カウンタによるビリング・カウント動作を制御するカウンタ制御手段と、メンテナンス作業中にジョブ要求が発生したときに、前記起動ジョブ可否設定手段により起動可能と設定されたジョブの起動を許可するジョブ起動許可手段とを具備することを特徴とする画像形成装置である。

リース契約の画像形成装置においては、ベンダがビリング・カウンタで画像形成回数をカウントして顧客に使用料を請求するという利用形態がとられる。また、多くの場合、ベンダとの間ではカスタマー・エンジニアが定期的に画像形成装置に設置場所に訪問してメンテナンスを行なうというメンテナンス契約が交わされる。

そして、メンテナンス作業時に実施するテスト・プリントもビリング・カウンタでカウントするとメンテナンス契約の請求金額は顧客にとって不利な金額となることから、適正に控除処理する必要がある。例えばメンテナンス時には通常のカウンタを停止して、テスト・コピーをカウントするためのメンテナンス用カウンタを別に持つことが考えられる。しかしながら、メンテナンス作業中であっても、バックグランド・ジョブやフォアグランド・ジョブが発生し、割込みプリントなどによりメンテナンス用カウンタの値が不正確となる可能性がある。

また、メンテナンス作業中はジャックを外してバックグランドでジョブが発生しないようにすることで、カスタマー・エンジニアはメンテナンス作業に集中できるとともに、控除処理を正確に行なうことができるが、ファクシミリ受信プリントのように重要性や緊急性が高いジョブをベンダ側の都合で抑制すると、顧客の受ける不利益は過大となる。

そこで、本発明の第１の側面に係る画像形成装置においては、当該装置のメンテナンス作業中に起動可能なジョブの種別をあらかじめ設定して、メンテナンス作業モード下でジョブ要求が発生したときに、前記起動ジョブ可否設定手段により起動可能と設定されたジョブのみ起動を許可するようにした。したがって、ジョブの重要性や緊急性に応じてメンテナンス作業中に起動可能なジョブの種別をあらかじめ設定しておくことにより、カスタマー・エンジニアがメンテナンス作業に集中できる環境を極力確保しながら、ファクシミリ受信プリントのような重要性や緊急度の高いジョブを適宜起動させ、顧客の利益を守ることができる。

画像形成装置は、ファクシミリ機能として複数の回線を接続するケースがあり、メンテナンス作業中のジョブを規制するために回線を抜くと、メンテナンス作業終了時に元通りに回線を接続する手間が非常に大変である。本発明によれば、回線を抜く必要がないので、このような事態を回避することができる。

また、メンテナンス作業の開始時に前記カウンタによるビリング・カウントを停止し、メンテナンス作業の終了時に前記カウンタによるビリング・カウントを再開するとともに、メンテナンス作業中に前記ジョブ起動許可手段により起動されたジョブの実行による画像形成回数をビリング・カウントするようにしてもよい。このような場合、メンテナンス作業中にカスタマー・エンジニアが行なうテスト・プリントや各種報告通知（のためのプリント）などを控除の対象として顧客の利益を保ちながら、メンテナンス作業中に顧客の都合により発生した、緊急のコピーやＰＣプリントなどの割込みジョブによる画像形成回数を控除の対象から外して、適正な控除処理を行なうことができる。

前記起動ジョブ可否設定手段は、当該装置のメンテナンス作業中の起動が許可した各ジョブを実行したときの画像形成回数をビリング・カウントするかどうかを設定するようにしてもよい。すなわち、メンテナンス作業中に起動可能なジョブの種別とともに、起動が許可されているジョブを実行したときの画像形成回数が控除の対象となるかどうかを併せて設定し、より正確な控除処理を行なうことができる。

前記起動ジョブ可否設定手段は、当該装置のメンテナンス作業中の起動可能に設定するジョブを、ファクシミリ受信プリントのように一部のバックグランド・ジョブに制限するようにして、カスタマー・エンジニアのメンテナンス作業に集中できる環境を整えることができる。

このような場合、前記カウンタ制御手段は、メンテナンス作業中は前記カウンタによるビリング・カウントを停止し、前記ジョブ起動許可手段により起動されたバックグランド・ジョブの実行による画像形成回数をビリング・カウントして、控除処理を行なうようにすればよい。

ここで、メンテナンス作業中にカウンタを停止すると正確なビリングを把握できなくなるという問題がある。そこで、前記カウンタ制御手段は前記カウンタによりすべてのジョブの画像形成回数をビリング・カウントさせ、前記カウンタとは別に、メンテナンス作業中にフォアグランドで指示されたジョブをカウントするメンテナンス用カウンタをさらに備えるようにしてもよい。これによって、カウンタにより正確なビリングを把握することができるとともに、メンテナンス作業中のテスト・コピーや各種報告レポートなどフォアグランドで指示されるジョブをメンテナンス用カウンタでカウントし、ビリングから正確に控除処理することができる。

また、画像形成装置は、メンテナンス作業開始時の前記カウンタの値を訪問メーターとして保持する訪問メーター保持手段と、メンテナンス作業終了時の前記カウンタの値を終了メーターとし、訪問メーターと終了メーターを基にメンテナンス作業による控除対象となるメンテナンス作業メーター値を算出する控除処理手段と、前記の訪問メーター及び終了メーターの値を基にサービス・レポートや来歴表などのメンテナンス結果報告通知を行なう報告通知手段をさらに備え、各メーター値を自動で計算して、図２５や図２６に示した報告書にプリントするようにしてもよい。

このような場合、サービス・レポートや来歴表などをプリントするときには、これらのプリントのカウント値はビリング・カウンタには反映されていない。そこで、前記控除処理手段がメンテナンス結果報告通知のためにプリントする画像形成回数の予測値を終了メーター値に加算してメンテナンス作業メーター値を算出することで、正確なメーター値を報告書にプリントすることができる。

また、前記控除処理手段は、メンテナンス作業中に実行したジョブの画像形成回数をカウントしたメンテナンス用カウンタの値を用い、終了メーターの値からテスト・コピーに相当する値を減算することで、辻褄の合う訪問メーターの値を算出することができる。

具体的には、前記カウンタ制御手段は、前記カウンタによりすべてのジョブの画像形成回数をビリング・カウントさせるとともに、メンテナンス作業開始時の前記カウンタの値を訪問メーターとして保持しておき、メンテナンス作業終了時の前記カウンタの値を終了メーターとし、訪問メーターと終了メーターを基にメンテナンス作業による控除対象となるメンテナンス作業メーター値を算出する。

あるいは、前記カウンタ制御手段は、前記カウンタを用いてすべてのジョブの画像形成回数をビリング・カウントさせて、メンテナンス作業終了時の前記カウンタの値を終了メーターとするとともに、前記カウンタとは別のメンテナンス用カウンタを用いてメンテナンス作業中に実行したジョブの画像形成回数をカウントし、前記控除処理手段は、前記終了メーターの値と前記メンテナンス用カウンタの値とを基に訪問メーターの値を算出する。

また、前記控除処理手段は、前記報告通知手段によるメンテナンス結果報告通知の画像形成回数の予測値を終了メーター値に加算してメンテナンス作業メーター値を算出するようにしてもよい。

また、画像形成装置は、訪問メーター、終了メーター、メンテナンス作業メーターの各値を外部の装置に通知する通知手段をさらに備えていてもよい。このような場合、ネットワーク上に控除処理データベースを構築して、各画像形成装置のメンテナンスを行なった際の訪問メーター、終了メーター、メンテナンス作業メーターの各値を一元的に管理することができる。

メンテナンス結果報告通知のためのプリントを行なう途中でジャムなどの障害が発生したときに、通常のジョブと同様に再開すると、控除処理手段が算出するメンテナンス作業メーター値すなわち控除対象のカウント値が正確でなくなる。そこで、前記報告通知手段は、メンテナンス結果報告通知のためのプリントを行なう際にジャム若しくはその他の障害が発生したときに、ジョブを中止して再度起動するようにすればよい。

また、メンテナンス結果報告通知のためのプリントを行なう最中に割込みプリントなどが行なわれると、控除処理手段が算出するメンテナンス作業メーター値すなわち控除対象のカウント値が正確でなくなる。そこで、前記ジョブ起動許可手段は、前記報告通知手段がメンテナンス結果報告通知を行なっている最中は、ジョブの起動を禁止するようにすればよい。また、メンテナンス結果報告通知の優先順位を、ユーザが通常指示できるジョブよりも高く設定することで、ジョブの割り込みを抑制することができる。

また、本発明の第２の側面は、フォアグランド又はバックグランドのジョブ要求に応じて画像情報を媒体上に形成するとともに、カウンタを用いて画像形成回数をビリング・カウントするための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、メンテナンス作業中に起動可能なジョブの種別の設定を受容する起動ジョブ可否設定手順と、メンテナンス開始指示に応じてメンテナンス作業モードに遷移するメンテナンス開始手順と、メンテナンス作業下でジョブ要求が発生したときに、前記起動ジョブ可否手順により起動可能と設定されたジョブのみ起動を許可するジョブ起動許可手順と、メンテナンス作業モード下で、前記カウンタによるビリング・カウントを停止するとともに、メンテナンス作業中に前記ジョブ起動許可手順により起動されたジョブの実行による画像形成回数をビリング・カウントする控除カウント手順と、メンテナンス終了指示に応じてメンテナンス作業モードから通常モードに復帰するメンテナンス終了手順を実行させることを特徴とするコンピュータ・プログラムである。

本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る画像形成装置と同様の作用効果を得ることができる。

本発明によれば、メンテナンス時におけるテスト・コピーなどの画像形成回数をビリング・カウンタで計数される通常の画像形成回数から適正に控除処理することができる、優れた画像形成装置及び画像形成方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、メンテナンス作業中にフォアグランド又はバックグランドで発生するジョブの要求に対応しながら適正な控除処理を行なうことができる、優れた画像形成装置及び画像形成方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、メンテナンス作業中に生じるバックグランド・ジョブによる割込みプリントを実行しながら適正な控除処理を行なうことができる、優れた画像形成装置及び画像形成方法、並びにコンピュータ・プログラムを提供することができる。

本発明に係る画像形成装置によれば、メンテナンス作業中に顧客の都合により発生した、緊急のコピーやＰＣプリントなどの割込みジョブによる画像形成回数をメンテナンス用カウンタから減ずることで、非控除分を正確に特定でき、適正な控除処理を行なうことができる。

また、本発明によれば、メンテナンス結果の報告を通知するために行なうプリントの画像形成回数を含メーター正確な控除処理を行なうことができる。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

以下、図面を参照しながら本発明の実施形態について詳解する。

図１には、カスタマー・エンジニアによる複合機のメンテナンス情報を一元管理するＦＷＳ（Ｆｉｅｌｄ Ｗｏｒｋ Ｓｕｐｐｏｒｔ）システムの全体構成を模式的に示している。

画像形成装置は、複写機能の他に、プリンタやファクシミリ、コンテンツ・サービスなど複数の機能を搭載した複合機である。以下で説明する実施形態では、特にベンダとの間でリース契約並びにメンテナンス契約がなされた画像形成装置を対象としており、カスタマー・エンジニアが定期的に画像形成装置に設置場所に訪問してメンテナンスが実施される。複合機は、インターネットや公衆電話網などの広域ネットワークに接続されている。同図では、図面の簡素化のため、画像形成装置を１台しか描いていないが、現実には無数の画像形成装置が存在する。

画像形成装置は、利用者からのジョブ要求に応じて、コピー、プリント、ネットワーク・プリント、スキャン、ファクシミリ、メール、メディア・プリント、コンテンツ・プリントといったジョブを実行することができる。個々のジョブが単独で要求される他、スキャン＋プリント、コンテンツのダウンロード＋プリントといったように２以上のジョブを組み合わせたマルチジョブが要求されることもある。画像形成装置がジョブを実行することにより利用者にはサービスが提供され、そのサービスの対価として利用者には料金が課金される（この意味において、画像形成装置における「ジョブの実行」と「サービスの提供」はほぼ同義である）。

複合機は、ベンダとのリース契約により、利用者のオフィスやコンビニエンス・ストアなどに設置されている。利用者は、複合機に装備されている操作パネル上からコピー、ファクシミリ送信又は受信、ネットワーク・プリント、コンテンツ・ダウンロードといったジョブを直接入力することができる。あるいは、パーソナル・コンピュータなどからネットワーク経由で要求するジョブを複合機に転送することもできる。

複合機にはビリング・カウンタが取り付けられており、コピーやプリントなどのジョブを実行する度に画像形成回数がカウントされ、カウント値に基づいて利用者に課金される使用料が算出される。カウント方法は、単純に排出した用紙の枚数を計数する他、用紙サイズや白黒／カラーなど画像形成モードの相違に応じた計数方法を採り入れることもできる。

複合機の画像形成エンジンは例えば電子写真プロセスで構成される。複合機上に自動濃度調整機能が搭載されていても、設置されている環境（温度や湿度など）や、サプライの状態（感光体の疲労）などの経時変化などの影響により画質が変化する。そこで、カスタマー・エンジニアが定期的に画像形成装置に設置場所に訪問してメンテナンスを行なうようにメンテナンス契約がベンダと利用者との間で交わされている。

この複合機は、インターネットなどの広域ネットワークを介して、ベンダが設置するＦＷＳサーバに接続される。カスタマー・エンジニアが訪問し、複合機のメンテナンス作業を行なった際に、複合機（若しくは複合機に接続されるメンテナンス用端末）からＦＷＳサーバに各種のメンテナンス情報を通知（すなわち報告）する。これによって、ベンダ側では複合機の状況を把握することができるとともに、適切なメンテナンスの実施、消耗品の自動発注処理、メーターのカウント値を把握して自動請求などの処理を利用者に提供することができる。

図２には、複合機１００のハードウェア構成を模式的に示している。以下、当該装置１００内の各部について説明する。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、当該装置１００内の動作を統括的に制御する中央コントローラであり、オペレーティング・システムが提供する実行環境下でプログラムを制御し、コピーやファクシミリ送受信、ネットワーク・プリントといった各種の画像形成動作や、画像形成処理に伴う対価の課金処理などに関して主たる制御を行なう。また、本実施形態では、メンテナンス動作の開始及び終了を行なうメンテナンス処理や、メンテナンス作業中に要求されたジョブの起動の可否を判断するジョブ起動可否判断処理、通常のジョブ実行時やメンテナンス作業中のジョブ実行時の画像形成回数をビリング・カウントするビリング・カウント処理などのプログラムを実行する。メンテナンス・カウンタ処理などによって、通常のビリング・カウンタに対する適正な控除処理を行なうことができるが、この点の詳細は後述に譲る。ＣＰＵ１０１は、バス１０２を介して当該装置１００内の各機器と相互接続されている。

ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３は、読み出し専用の半導体メモリ装置で構成され、ネットワーク・プリントといったサービス提供動作やサービス実行に伴う対価の課金処理などを実行するための各制御プログラムや固定データなどが恒久的に書き込まれている。例えば、上述したメンテナンス処理や、ジョブ起動可否判断処理、ビリング・カウント処理などを実行するファームウェアがＲＯＭ１０３に格納されている。勿論、フラッシュ・メモリなどのように格納データを電気的な書き換え可能なデバイスを用いてＲＯＭ１０３を構成することもでき、必要に応じて適宜プログラムや固定データの更新を行なうようにしてもよい。また、固定データとは、複合機１００を物理的に識別するシリアル番号、製造番号、製造年月日、製造工場名などの書き換える必要のない固有情報である。

ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０４は、書き換え可能な半導体メモリ装置で構成され、ＣＰＵ１０１で実行する制御プログラムをＲＯＭ１０２からロードしたり、プログラム実行中の環境変数やシステム変数を一時格納したりするなど、プログラム動作のためのシステム・メモリとして使用される。また、画像処理のためのページ・メモリとして、ＲＡＭ１０４を使用することができる。

ＮＶＲＡＭ（Ｎｏｎ−Ｖｏｌａｔｉｌｅ ＲＡＭ）１０５は、フラッシュ・メモリのように無電源状態でも記憶内容を消失しない書き換え可能メモリで構成され、セキュリティ・データやその他の不揮発性データ、画質調整、各種カウンタ（後述）、各種設定パラメーター、サービス実行時の各種履歴、サービスの対価を課金した履歴などを格納するために使用される。

ＨＤＤ１０６は、磁気記録式の固定ディスクからなる大容量外部記憶装置であり、原稿から読み取った画像データを蓄積したり、画像形成処理実行時の各種のジョブ履歴を保存したり、さらにはＣＰＵ１０１において実行するプログラムをインストールしたりするために使用される。

画像処理部１０７は、原稿から読み取った画像データ、あるいはネットワーク経由でダウンロードした画像データなどに対し、伸張圧縮処理や、画質調整などの各種画像処理を施す。例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）を用いて画像処理部１０７を構成することができる。

図示の複合機１００は、ユーザ・インターフェース１０９として、液晶ディスプレイなどからなる表示部１１０と、スタート／ストップ／テンキーなどのハードウェア・キーを備えた（あるいは表示部１１０を兼ねたタッチパナルからなる）操作部１１１を備え、これらはＵＩインターフェース１０８を介してバス１０２に接続されている。但し、ＵＩインターフェース１０８を介さず、ＣＰＵ１０１がユーザ・インターフェース１０９を直接制御するように構成することも可能である。

利用者は、ユーザ・インターフェース１０９を介して、コピーやファクシミリ送受信、コンテンツ・ダウンロードといったジョブの指示を直接入力することができる。

また、カスタマー・エンジニアは、ユーザ・インターフェース１０９を介して、メンテナンス作業の起動や終了、メンテナンス作業中のテスト・プリント、各種報告レポートのプリント及びＦＷＳサーバへのネットワーク送信、メンテナンス作業中の割込みプリントなどの指示を入力することができる。

通信インターフェース１１２を経由して、各種の外部装置やネットワーク・インターフェースなどがバス１０２に接続されている。

ＬＡＮインターフェース１１３は、１０／１０００Ｂａｓｅ−Ｔなど、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ：米国電気電子技術者境界）が定メーター所定のプロトコルに従って複合機１００をネットワーク接続するＬＡＮポートを提供する。無線ＬＡＮを含めることもできる。複合機１００は、ＬＡＮ越しにインターネットなどの外部ネットワークに接続し、所望の情報資源にアクセスすることができる。また、複合機１００は、ユーザが使用するパーソナル・コンピュータ（ＰＣ）や携帯端末（いずれも図示しない）から、コピーやファクシミリ送受信、コンテンツ探索やその他のコンテンツ処理、ネットワーク・プリントといった、各種のサービスの内容を規定するジョブ指示書を受信し、指示に従ってサービスを実行することができる。 また、本実施形態では、ＬＡＮインターフェース１１３を通じて、インターネット上のＦＷＳサーバに接続される。そして、カスタマー・エンジニアが複合機のメンテナンス作業を行なった際にＦＷＳサーバに各種のメンテナンス情報を通知することができる。

複合機１００には、ＩＣカードに対して非接触・近距離通信を行なうために、ＩＣカード読み書き装置が装備され、ＲＳ２３２Ｃあるいはその他のシリアル・インターフェース１１４経由でバス１０２に接続されている。ＩＣカードとＩＣカード読み書き装置間では、電磁結合、電磁誘導、あるいは電波通信などの方式による伝送路上で、所定の相互認証処理を経て、高い耐タンパ性を保ちながら非接触・近距離通信を行なうことができる。複合機１００は、サービスの対価をＩＣカードから課金したり、ＩＣカードのチャージを行なったりする。

ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インターフェース１１５は、例えばＵＳＢ１．１又はＵＳＢ２．０に準拠し、周辺機器を外部接続し、あるいはパーソナル・コンピュータなどにローカル接続する際に使用することができる。例えば、カスタマー・エンジニアは、メンテナンス用の端末（図示しない）を、ＵＳＢインターフェース１１５を介して複合機１０に接続することができる。

モデム１１６は、コンピュータ上の信号と公衆回線上の信号の相互変換を行なう変復調装置からなり、ファクシミリなどの公衆回線への接続を行ない、通常のファクシミリ送受信や、時刻指定送信、その他の各種のファクシミリ機能を提供する。

コインキット１１７は、コインや紙幣などの現金を受け取る受け取り口と、受け取り口を介して投入された現金を蓄積する現金蓄積部と、投入金額を計数するとともに課金し徴収した額を減算して残額を算出する演算部と、残額若しくは現在徴収している金額を表示する表示部を備えている。

デバイス・インターフェース１１８は、例えばＲＳ４２２などで構成され、複合機１００を構成する各種機器をバス１０２に接続するためのインターフェース・プロトコルを実現する。

複合機を構成する機器として、例えば原稿から画像を読み取る読取装置部１１９と、画像を用紙上に印刷出力する印刷装置部１２０が挙げられる。

読取装置部１１９は、一般的には、原稿を載せるプラテンと画像読み取りを行なうスキャンの組み合わせで構成され、自動原稿読取装置であってもよい。読み取り画像は、適宜画像処理部１０７において画像処理が施され、印刷装置部１２０に画像出力され、あるいはＨＤＤ１０６に保存される。

印刷装置部１２０は、例えば電子写真方式のプリント・エンジン部を備えている。電子写真プロセスは、電子写真感光体に対する帯電、スキャンした原稿イメージの露光、現像すなわち感光体へのトナー重畳、用紙へのトナー転写及びトナー定着、感光体のクリーニングという複数のサブプロセスからなる。但し、プリント・エンジンの構成自体は本発明の要旨に直接関連しないので、ここではこれ以上説明しない。

印刷装置部１２０によって印字された用紙が排出されると、排出用紙格納部１２１に格納される。排出用紙格納部１２１は、一般的な排紙トレイを用いて構成することもできる。

図３には、複合機上の動作を制御するためのソフトウェア構成を模式的に示している。同図に示すように、制御ソフトウェアは、オペレーティング・システム（ＯＳ）層と、ミドルウェア層と、機能モジュール層と、アプリケーション層で構成される。

ＯＳは、組み込み用のリアルタイムＯＳであり、汎用的なものから複合機用に製作されたものなどを使用することができる。

ミドルウェアは、ＯＳと機能モジュールとの仲立ちを行なう層であり、汎用ＯＳの上位に位置し、ハードウェア固有の影響などを抑え、ジョブや機能モジュールといった上位モジュールに共通のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供するモジュール群である。このようなソフトウェア階層を介在させることにより、複合機１００内のハードウェアやＯＳの変更を行なった際に、機能モジュールやジョブ・レベルの階層への実装の変更などの影響を抑えることができる。

システム・マネージャ（Ｓｙｓｔｅｍ Ｍａｎａｇｅｒ）は、状態・リソース管理、ジョブ管理、ファイル管理、バッファ管理、タイマ管理、ジョブ履歴など各種ログ管理といった、複合機１００の中核を管理するモジュールであり、これらの管理機能への機能モジュールへの提供も行なう。

デバイス・ドライバ並びにライブラリは、機能モジュールに対して、外部システムやハードウェアの持つ機能を提供するモジュール群であり、各種プロトコルや各種デバイスの下位レベルでの制御を行なう。

本実施形態では、複合機１００は、モードという概念により、通常の使用状態、メンテナンス用の特殊状態、診断機能を実施する特殊状態などを管理している。モード・ライブラリ（Ｍｏｄｅ Ｌｉｂｒａｒｙ）は、この管理機能を各機能モジュールに提供する。

メーラ（Ｍａｉｌｅｒ）は、一般的な電子メールのプロトコル機能を提供し、例えばＩＦＡＸの送受信や、ＦＷＳサーバとの通信を行なう。

ＤＶライブラリは、ＤＶ用紙のプリント枚数、すなわち、カウンタ制御機能（後述）を提供する。アクセサリ・ドライバ（Ａｃｃｅｓｓｏｒｙ Ｄｒｉｖｅｒ）は、カード・リーダなどの認証機器や管理機器のドライバである。

また、デバイス・ドライバやライブラリには、さらに、ファクシミリの通信モデム制御、ＬＡＮ制御、ＨＤＤアクセス制御、読取装置１１９や印刷装置１２０、ユーザ・インターフェース１０９などとのインターフェース制御を行なうモジュール（図示しない）がある。

機能モジュールは、リクエスト処理や、ユーザ・インターフェース１０９との通信処理、アプリケーションを実現するための画像処理、リモートのデバイスに各種状態などを通知するモジュール群で構成される。以下、機能モジュール群の個々のモジュールについて説明する。

リクエスト・マネージャ（Ｒｅｑｕｅｓｔ Ｍａｎａｇｅｒ）は、リクエスト処理とユーザ・インターフェース１０９との通信処理を行なう。出力装置コントローラ（ＯｕｔｐｕｔＤｅｖｉｃｅ Ｃｏｎｔ）は、印刷装置の制御を行なう。入力装置コントローラ（Ｉｎｐｕｔ Ｄｅｖｉｃｅ Ｃｏｎｔ）は、読取装置の制御を行なう。スプール・コントローラ（ＳｐｏｏｌＣｏｎｔ）は、蓄積の制御を行なう。Ｄｅｃｏｍｐｏｓｅｒは、プリント・データの印刷可能、中間表現への変換処理を行なう。報告書ジェネレータ（Ｒｅｐｏｒｔ Ｇｅｎ）は、メンテナンス作業終了の際のサービス・レポートや保守完了報告書などの各種レポート作成処理を行なう。ファクシミリ・コントローラ（ＦａｘＣｏｎｔ）は、ファクシミリ通信制御を行なう。認証マネージャ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒ）は、認証管理を行なう。ＨＴＴＰ Ｃｏｎｔｒｏｌｌｅｒは、ＨＴＴＰプロトコルによるリモートのデバイスに各種状態などの通知処理を行なう。ＳＮＭＰコントローラ（ＳＮＭＰＣｏｎｔｒｏｌｌｅｒ）は、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）によるリモートのデバイスに各種状態などの通知処理を行なう。ＬＡＮコントローラ（ＬＡＮＣｏｎｔ）は、ＬＡＮ上での通信制御を行なう。

アプリケーションは、コピーやファクシミリ、スキャナといったユーザに対して提供する機能処理の層である。

例えば、ＩＣカードによる認証を行なう場合、アクセサリ・ドライバからユーザの認証操作指示とカード・リーダが読み取ったＩＣカード内の情報に関するモジュール間メッセージ通知があると、認証ドライバは、ＮＶＲＡＭ１０５に格納されているユーザ管理テーブルにアクセスして、認証処理を行なう。

また、その後、コピーがユーザから指示されると、その指示をユーザ・インターフェース１０９経由で受け取ったリクエスト・マネージャが、原稿サイズや用紙サイズなどの設定値をチェックしてコピー・ジョブ起動情報として設定し、システム・マネージャのＡＰＩを使用して、状態・リソース管理情報などコピー起動に必要なシステムの情報をチェックする。そして、問題が無ければアプリケーションを起動の要求をシステム・マネージャに行なう。システム・マネージャは、スケジューリング制御を行ない、所定のスケジュールでアプリケーションを起動する。

その結果、アプリケーション層のコピーが起動状態になり、コピーが入力装置コントローラに現行の読取制御指示、スプール・コントローラにその読み取った画像データの蓄積処理の指示、出力装置コントローラへのプリント制御指示を行なうことにより、ユーザにコピー機能を提供する。

複合機のメンテナンス契約では、請求金額が利用者にとって不利とならないよう、メンテナンス作業時に実行するテスト・プリントや各種レポートのプリントの分を適正に控除処理する必要があり、このため、ビリング・カウンタの他に、メンテナンス作業中の画像形成回数をカウントするメンテナンス・カウンタが備えられる。本発明では、メンテナンス作業中に割込みプリントが発生した場合であっても正確に控除処理を実施する点に特徴がある。以下では、メンテナンス作業の流れと併せて控除処理の詳細について説明する。

メンテナンス作業は、メンテナンス開始指示、メンテナンス作業中、メンテナンス終了指示というフェーズで構成される。各フェーズにおける概略動作は以下の通りである。

メンテナンス開始指示：
ＣＥ（カスタマー・エンジニア）パスワード入力
メンテナンス・モード移行→メンテナンス・モード・フラグを設定する
メンテナンス開始処理
メンテナンス・カウンタ動作開始
レポート作成のためのメンテナンス内容入力
メンテナンス・モード移行終了

メンテナンス作業中：
Ｐａｓｓｉｖｅ Ｓｅｒｖｉｃｅが要求されたら、起動可否をチェック
起動不可１→受付拒否、要求したユーザにその旨通知
起動不可２→起動不可のまま受付、待ちジョブ扱いにする
起動可能→ジョブ起動
→起動ジョブのプリントはメンテナンス・カウンタに加算しない。ビリング・カウンタのみ。
Ａｃｔｉｖｅ Ｓｅｒｖｉｃｅは、メンテナンス用と判断し、ビリング・カウンタ及びメンテナンス・カウンタを増加
ここで、Ｐａｓｓｉｖｅ Ｓｅｒｖｉｃｅとはバックグランドで起動するサービスである。他方、Ａｃｔｉｖｅ Ｓｅｒｖｉｃｅは操作部１１１上の操作を通じて利用者が直接要求したサービスであり、即時的に起動する必要がある。したがって、メンテナンス作業中に操作部１１１から指示されたＡｃｔｉｖｅ Ｓｅｒｖｉｃｅは、カスタマー・エンジニアがメンテナンスのために要求したものだと判断することができる。

メンテナンス終了指示
レポート作成処理→サービス・レポート、機械来歴表（後者は選択可）
サービス・レポート作成処理
モード移行時の入力内容からレポート項目作成
機械来歴表作成処理
モード移行時の入力内容からレポート項目作成
ＦＷＳサーバへ通知
なお、機械来歴表とは、カスタマー・エンジニアがメンテナンス作業の履歴を記述して機械を点検した結果を残すもので、メーターの情報などの多くの項目がサービス・レポートと共通する。

図４には、本実施形態に係る複合機におけるメンテナンス動作の概略的な手順をフローチャートの形式で示している。

まず、所定のメンテナンス・モード移行処理（後述）を実施して、複合機はノーマル・モードからメンテナンス・モードに移行する（ステップＳ１）。

メンテナンス・モード下で、ジョブ起動要求があると（ステップＳ２）、所定のジョブ起動判断処理（後述）を実施して（ステップＳ３）、ジョブの起動の可否を判断する（ステップＳ４）。

そして、ジョブの起動が許可されたら、当該ジョブを実行した後（ステップＳ５）、ジョブの修了処理を行なう（ステップＳ６）。ジョブの実行は一般的な事項のため、ここでは説明を省略する。また、ジョブの終了処理については後述に譲る。

その後、メンテナンス終了指示がカスタマー・エンジニアから入力されるまで（ステップＳ７）、ステップＳ２に戻り、メンテナンス・モード下で、ジョブの起動制御を継続して行なう。

そして、メンテナンス終了指示があると、所定のノーマル・モードへの移行処理（後述）を実施して（ステップＳ８）、本処理ルーチン全体を終了する。

図５には、ステップＳ１で実行される、メンテナンス・モードへ移行するための処理手順をフローチャートの形式で示している。また、図６には、メンテナンス・モード移行時の動作シーケンスを示している。

カスタマー・エンジニアがメンテナンス・モードに入るための所定の操作（例えば、操作部１１１上でのスタート・ボタンの長時間押下など）を行なうと、ユーザ・インターフェース１０９は、メンテナンス・モードに移行する操作を指示されたと判断し、パスワードの入力を要求する。

このパスワードが要求されると、ユーザ・インターフェース１０９並びにリクエスト・マネージャを経て認証マネージャがＣＥ（カスタマー・エンジニア）パスワードのチェックを行なう。そして、認証の結果がＯＫであれば、メンテナンス処理を行なうためメンテナンス・モード移行する処理を開始する。

リクエスト・マネージャは、モード・ライブラリをコールしてモードを移行要求する。この際、ほぼ同時に、ユーザ・インターフェース１０９にモード移行状態に入ったことを通知する。この通知を受けたユーザ・インターフェース１０９は、操作部１１１をロック状態にする。何故なら、この状態では、ユーザ・インターフェース１０９などのユーザのリクエストをロックしておかないと、モード移行処理とユーザの要求がクロスすることがあるからである。

具体的には、モード移行後に起動できないサービスが要求された場合、モード移行処理中は、モード移行が完了していないため、サービス起動の処理が開始される。他方で、モード移行処理が完了してしまうと、そのサービスは起動できない矛盾した状態になる。このようなケースを避けるために、上記のようにリクエストをロックしている。なお、このような処理は、ユーザ・インターフェース１０９だけでなく、ＬＡＮ経由でリクエストを受け付けるＬＡＮコントローラなども同様である。

次に、現在の複合機の各種の状態が、メンテナンス・モードに移行する条件を満たしているかエントリ条件のチェックを行なう（ステップＳ１１）。どのような条件をチェックすべきかは設計事項なので、ここでは説明を省略する。

このエントリ条件を満たしていなければ、移行不可としてユーザ・インターフェース１０９を介してカスタマー・エンジニアに、そのことを通知する（ステップＳ１６）。

また、エントリ条件を満たしている場合は、メンテナンス・モードにいることを示すフラグをオンにして（ステップＳ１２）、メンテナンス・カウンタ（後述の表１１を参照のこと）を起動、すなわちリセットしてカウント可能な状態にする（ステップＳ１３）。そして、エントリ条件を満たしたという結果を、関連する（上記モード移行状態を通知した）モジュールに通知する。

次に、メンテナンスに関する以下のような項目を、ユーザ・インターフェース１０９から入力する（ステップＳ１４）。

・処置目的（定期点検、故障診断、消耗品交換、その他（））
・処置内容（ＸＸ交換、ジャム除去、部品交換、ファームウェアのバージョン更新、その他）
・不具合内容（コメント記載、エラー履歴、ジョブ履歴より選択）

そして、入力されたこのようなメンテナンス情報をＮＶＲＡＭ１０５に書き込み、一時保持する（ステップＳ１５）。

以上のステップが終了すると、メンテナンス・モードへの移行が完了した旨を、ユーザ・インターフェース１０９を介してカスタマー・エンジニアに通知し、表示部１１０をメンテナンス・モード表示にする。通常、メンテナンス・モードでは、それと分かるように白黒反転表示状態などにする。

メンテナンス・モード下では、カスタマー・エンジニアは、ハードウェア部品の点検、交換作業以外に、動作確認と画質確認のために、テスト・コピーやテスト・プリント、エラー履歴レポート、ジョブ履歴レポートをプリントしたりする。

この際、顧客のＰＣプリントや、顧客の取引先のファクシミリ受信プリントといった割込みプリントが発生する可能性がある。このため、割込みプリントのプリント枚数を非控除扱いにするための適正な控除処理を行なうにはメンテナンス・カウンタを更新する必要がある。

次に、メンテナンス作業中の上記サービスの起動可否判断、カウント処理について説明するが、これに先立ち、このサービス制御とこの制御を行なうためのパラメータについて説明する。

本実施形態に係る複合機１００のソフトウェアは以下に示す、ＵＲＰ、ＳＣＢ、ＶＤＰという３種類のパラメータを制御に使用する。図７には、各パラメーターの使用方法を概念的に示している。但し、同図では、ファクシミリ送信時のモニタ・レポートを生成する事例を示している。

ＵＲＰ（Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｐａｒａｍｅｔｅｒ）は、ユーザ（顧客）が、ユーザ・インターフェース１０９を操作してスタートを指示したとき、その操作によって設定するパラメータである。例えば、用紙サイズ、部数、倍率などのジョブ・リクエストに必要なパラメータがこれに該当する。

ＳＣＢ（Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）は、サービス制御を行なうためのパラメータのことであり、例えば、ジョブ状態、ジョブの起動可能モード、リソース情報などがこれに相当する。

ＶＤＰ（Ｖｉｒｔｕａｌ Ｄｉｓｐｌａｙ Ｐａｒａｍｅｔｅｒ）は、ＵＲＰを基に生成されるパラメータで、ジョブの動作過程において、変化のあったパラメータを所定のタイミングで変更する。ユーザ・インターフェース１０９や、ＨＴＴＰ、ＳＮＭＰなどの通知は、所定のタイミングでこれを参照することで、リアルタイムにジョブの状態を通知することができる。

また、図示しないが、アプリケーションのジョブ履歴用に、ＪＬＰというパラメータも備えている。ＪＬＰ（Ｊｏｂ Ｌｏｇ Ｐａｒａｍｅｔｅｒ）は、サービス終了時にジョブの履歴をとるために生成されるパラメータで、ＵＲＰの一部とＳＣＢとＶＤＰをコピーして生成される。このＪＬＰは、ＦＩＦＯで制御されてＮＶＲＡＭ１０５に格納される。ＪＬＰが所定量を超えるとＨＤＤ１０６に移され、新たなジョブ履歴は再びＮＶＲＡＭ１０５に格納される。

図８には、ＵＲＰの概略構成を示している。図示の通り、ＵＲＰは、アプリケーション種別で共通部分と固有部分で構成される。

共通部分にはＵＲＰ自身のＩＤ、タイプ、エラーコードを持つ。パラメーター・チェック・エラー時には、ＵＲＰしか作成されないので、前述したＪＬＰにコピーする一部とは、この理由による共通部分のコピーとなる。表１には、ＵＲＰのアプリケーション種別共通部分の具体的なデータ構成例を示している。

また、ＵＲＰの固有部分には、コピーやファクシミリ送信のように、アプリケーション毎のユーザ設定パラメータを持つ。コピー並びにファクシミリ送信における固有部分の具体的なデータ構成例をそれぞれ表２並びに表３に示しておく。

図９には、ＳＣＢの概略構成を示している。図示の通り、ＳＣＢも、ＵＲＰと同様に、アプリケーション種別で共通部分と固有部分で構成される。表４には、ＳＣＢのアプリケーション種別共通部分の具体的なデータ構成例を示している。

また、ＳＣＢの固有部分は、アプリケーションの状態、タイプ、停止（Ｓｔｏｐ）や保留の種別、エラーコード、ＳＣＢのＩＤ、各パラメータへのポインタ情報などを備え、さらにフェーズ管理の情報を備える。表５には、ＳＣＢのアプリケーション種別固有部分の具体的なデータ構成例（但し、コピーの場合）を示している。

図１０には、ＶＤＰの概略構成を示している。図示の通り、ＶＤＰも、ＵＲＰやＳＣＢと同様に、アプリケーション種別で共通部分と固有部分で構成される。表６には、ＶＤＰのアプリケーション種別共通部分の具体的なデータ構成例を示している。

ＶＤＰは、ＵＲＰを基に生成され、例えばコピーの場合、総プリント数（原稿枚数×部数）、読み込み済み枚数、プリント済み枚数などの経過情報などを追加し、アプリケーションの現在状況を示すデータを有する。表７には、ＶＤＰのアプリケーション種別固有部分の具体的なデータ構成例（但し、コピーの場合）を示している。

ここで、図７に戻って、上記の３種類のパラメータとアプリケーション制御の関係について説明する。

ユーザによって操作部１１１上でＦａｘメニューが選択され、宛先などが選択され、スタート・ボタンが押下されると、ユーザの選択したパラメータは、リクエスト・マネージャに通知される。

リクエスト・マネージャは、ＵＲＰを生成し、上記のユーザが選択したパラメータと自動設定をＵＲＰに設定するとともに、不正なパラメータが無いかチェックをする。そして、パラメータに問題が無ければ、システム・マネージャのＡＰＩを介して、ＳＣＢ及びＶＤＰの確保を行なう。なお、パラメータ・チェックはリクエスト・マネージャが行なうが、当然ユーザ・インターフェース１０９のレベルでも禁則処理は行なう。

ＳＣＢ及びＶＤＰの確保とチェック期間は、タスク・スイッチはせず、リクエスト・マネージャが処理を占有する。理由は、リソース（後述）の確保・チェックの際に、タスク・スイッチすると、タスク・スイッチした間に、次のステップで確保予定のリソースが確保不可状態になるケースなど、制御上煩雑な状況になる可能性があるためである。さらに、ＳＣＢとＶＤＰの確保とチェックの処理は、最も外側のモジュールで実施した方が、クロス・シーケンスの発生がないため、リクエスト・マネージャで処理する。

ＳＣＢは、ＵＲＰを基に生成されるが、さらに、システム・マネージャがあらかじめ有するリソース情報とフェーズ情報を加えて設定する。リソース情報は、排他リソースと、マシン状態リソースと、アプリケーション・ユニーク・リソースの３種類に大別される。

排他リソースは、プリント・エンジン、スキャナ、モデムの公衆回線など、使用中は占有状態になるため、排他的な利用しかできない資源や、共有に制限のあるセマフォ資源（例えば、画像処理の符号化処理の多重度など）である。

マシン状態リソースは、アプリケーション管理用のメモリ、蓄積用のメモリの容量などのソフトウェア資源、複合機がアプリケーション規制のモードあることを示すモード・リソースである。

アプリケーション・ユニーク・リソースは、特定のアプリケーション起動に付随するリソース情報であり、コピー・カード未装着、度数、残金不足などのアプリケーション・ユニークなリソースが該当する。アプリケーションのフェーズ移行条件などもこのリソースに入る。

上記のリソースの説明は、組み込み制御上、一般的なことであるので、本発明の要旨に関わる部分以外の説明は省略する。

本発明のポイントの１つであるメンテナンス・モード時におけるアプリケーション起動の禁止は、ＳＣＢを生成するときに、システム・マネージャが有するリソース情報のうち、モード・リソースのアプリケーション規制情報を基に生成される。以下の表８には、アプリケーション毎の規制情報を記述したジョブ一覧表を示している。同表では、アプリケーション毎にレコードが設けられ、起動不可となるモードや、メンテナンス・モード下でジョブを実行したときに画像形成回数が控除されるか（すなわち控除対象のジョブであるか）が記載される。例えば、アプリケーション「コピー」は、ダイアグ（診断）モードとリモート・メンテナンス・モードのときには禁止され、また、メンテナンス・モードで実行したコピーは控除の対象となっていることが判る。

表８によれば、アプリケーション毎に起動不可となるモードや控除対象であるかどうかを確認する早見表となる。これに対し、モード毎に起動が禁止されるアプリケーションを確認する早見表形式を表９に示す。同表からは、例えば、メンテナンス・モード下では、ＰＣプリントやＰＣプリント・セキュリティ受信などのアプリケーションの起動が禁止されていることを確認できる。

また、表９には、モード毎に起動が禁止されるアプリケーションを確認する早見表形式を示している。同表からは、例えば、メンテナンス・モード下では、ＰＣプリントやＰＣプリント・セキュリティ受信などのアプリケーションの起動が禁止されていることを確認できる。

表８及び表９に示すようにアプリケーションの規制情報を用いることによって、ジョブの重要性や緊急性に応じてメンテナンス作業中に起動可能なジョブの種別をあらかじめ設定しておくことができる。また、メンテナンス作業中の起動が許可されているジョブを実行したときの画像形成回数が控除の対象となるかどうかを併せて設定しておくことができる。

このような情報は、ＳＣＢ生成時に表４のｐｈａｓｅ Ｉｎｆｏ［ｘ］．ＭｃＳｔａｔｕｓ ｒｅｓ（ｘはＳｅｒｖｉｃｅを構成するフェーズ数）に格納され、この情報を基にメンテナンス作業中に起動可否が判定される。例えば、ファクシミリ送信のＳＣＢの該パラメータを設定する際には、表８に示されるように、メンテナンス、ダイアグ、リモート・メンテナンス中は起動が不可という情報が設定される。さらに、起動したアプリケーションが控除対象又は非控除対象のいずれであるかは、同様にシステム・マネージャが有するリソース情報のモード・リソースのアプリケーション規制情報からＡｐｌ ＣｏｕｎｔＳｔａｔｕｓに設定される。

次に、生成したリソース情報に基づき、最初のフェーズが、ＡｃｔｉｖｅかＰａｓｓｉｖｅかの判断を行なう。何故なら、Ａｃｔｉｖｅは、直ぐに起動する必要があるフェーズなので、直ぐに、リソースの確保とジョブ起動可能か否かの判断(以下では、「リソース・チェック」と呼ぶ)を行なう。他方、Ｐａｓｓｉｖｅは、後に起動しても構わないものなので、その時点では、リソースの確保と判断を行なわない。

Ｐａｓｓｉｖｅな場合は、フェーズの以降の都度、現フェーズのリソースの解放と次フェーズのリソース・チェックが生じる。これに対し、Ａｃｔｉｖｅな場合は、連続したＡｃｔｉｖｅなフェーズのリソース・チェックを最初のフェーズのリソース・チェック時に行なう。

ＡｃｔｉｖｅとＰａｓｓｉｖｅの違いは、上記だけでなく、スケジューリングにもあり、それぞれ専用の待ちキューに配される。且つ、特定のイベントで起動したときにはＡｃｔｉｖｅ、所定（例えば１秒）の単位で起動可否をチェックするときはＰａｓｓｉｖｅとなっている。

表１０には、図７に示したファクシミリ送信のＳＣＢのリソース判断に関わる一部の内容を示している。スキャン・コントローラが最初に行なう「Ｓｃａｎ＆蓄積」フェーズ（表１０中のＳｃａｎ＆Ｓｔｏｒｅ）はＡｃｔｉｖｅ（表１０中の表記はＡＣＴ）であるので、リクエスト・マネージャの起動要求処理の中で、モード・リソースのチェック、ＶＤＰの生成、排他リソースの確保、蓄積用メモリの確保の順に従ってリソースの確保とチェックを行なう。

まず、モード・リソースのチェックにより、ＳＣＢに設定された起動不可モードから、起動不可のモードであるか否か判断する。ここで、起動可能であれば次のステップに進むが、起動不可能であれば起動できずに終了する。

例えば、ファクシミリ送信の場合、表８の設定に従い、メンテナンス・モードでの起動が不可であるという情報が表１０に示すようにＳＣＢに設定されているため、起動不可となり終了する。他方、コピーやファクシミリ受信などは、メンテナンス・モードでは起動不可でないので、そのような情報はＳＣＢに設定されず、起動可能と判断し、次にステップに進む。

次いで、ＶＤＰの生成を行なう。既にアプリケーション管理としては、ＵＲＰとＳＣＢを確保しているので、ＶＤＰを生成できれば、管理用のメモリを確保しそのチェックが完了したことになる。管理用メモリを確保できなければ、起動できずに終了する。

次いで、スキャナ（すなわち読取装置部１１９）、ＲＡＭ１０４、ＨＤＤ１０６といった排他リソースの確保を行なう。排他リソースを確保することができれば次のステップへ進むが、確保できなければ起動できずに終了する。

次いで、ＯＳのファイル・システムを利用してファイルを生成することにより、蓄積用のメモリを確保する。ここで、蓄積用メモリを確保することができれば次のステップへ進むが、確保できなければ、メモリ不足と判断し起動できずに終了する。

以降のフェーズでもＡｃｔｉｖｅなフェーズがあれば、上記の排他リソースの確保を行なう。図７に示した例では、Ｐａｓｓｉｖｅであるので、この処理は行なわないが、コピーで且つ蓄積処理を行なわずにプリントする場合は、すべてのフェーズがＡｃｔｉｖｅになるので、起動要求時にすべての判断を行なう。

以上により、リソースの確保及びチェックが行なわれる。なお、最初のフェーズがＰａｓｓｉｖｅの場合は、リソースの確保及びチェックは行なわない。

続いて、ＳＣＢをスケジューリングの待ちキューに入れる。待ちキューは、Ｉｄｌｅ、Ｒｅａｄｙ−Ａｃｔｉｖｅ、Ｒｅａｄｙ−Ｐａｓｓｉｖｅ、Ｒｕｎの他、Ｗａｉｔ（時刻指定）キューなどで構成される。

Ｉｄｌｅは、未使用のＳＣＢのリンクであり、複合機１００のハードウェア構成でソフトウェアが受付可能のアプリケーションの最大数に等しいキューの個数となるよう設計される。また、Ｒｅａｄｙ−ＡｃｔｉｖｅはＡｖｔｉｖｅなアプリケーションのＳＣＢのリンクであり、Ｒｅａｄｙ−ＰａｓｓｉｖｅはＰａｓｓｉｖｅなアプリケーションのＳＣＢのリンクである。Ｒｕｎは、実行状態のアプリケーションのＳＣＢのリンクであり、複合機１００のハードウェア構成でソフトウェアが同時実行可能な最大数になるようキューの数が設計される。

図７に示した例では、ファクシミリ送信はＲｅａｄｙ−Ａｃｔｉｖｅに配される。

そして、リクエスト・マネージャは、システム・マネージャに対し、アプリ起動要求を行なう。システム・マネージャは、このイベントをトリガにして、スケジューリングを行なう。

最初のフェーズがＡｃｔｉｖｅな場合、既にリソース・チェックは済んでいるので、アプリケーションをＲｕｎキューに変更して、Ｆａｘモジュールにジョブ起動指示を出す。Ｆａｘモジュールは、このイベントを受け取ると、ＳＣＢを基に各フェーズの制御を、スキャナ・コントローラ、ファクス・コントローラ、報告書ジェネレータ、プリンタ・コントローラなどそれぞれの機能モジュールに指示し、その結果をＶＤＰに反映させる。

各フェーズの実行中、Ｆａｘなどのアプリケーションは、ＳＣＢのアプリケーション固有情報のみ、システム・マネージャはＳＣＢの共通情報のみをそれぞれ更新することで、ＳＣＢの排他制御を実現している。

そして、各フェーズの終了時には、アプリケーション状態通知がシステム・マネージャに通知される。システム・マネージャは、これをトリガに次のフェーズ起動処理に移る。

次のフェーズがＰａｓｓｉｖｅの場合、現リソースを解放し、次フェーズのリソース・チェックを行ない、ＳＣＢをＲｅａｄｙ−Ｐａｓｓｉｖｅキューに入れる。また、次のフェーズがＡｃｔｉｖｅの場合は、既にリソースはリクエスト・マネージャの起動要求処理のときに実施済みなので、リソース・チェックは行なわず、そのまま次フェーズの処理を開始する。

図７に示した例では、以降の読出＆通信、レポート作成＆蓄積、読出＆ＰプリントはすべてＰａｓｓｉｖｅなフェーズとして処理される。

以上の処理が終了すると、アプリケーションは、ＳＣＢとＶＤＰの内容を基にＪＬＰを生成して、処理を終了する。

図１１には、メンテナンス・モード中にバックグランド・ジョブが発生したときに実行される、ジョブ起動の可否を判断するための処理手順をフローチャートの形式で示している。当該処理ルーチンは、図４に示したフローチャートのステップＳ３で実行される処理に相当する。

まず、ＵＲＰを設定し（ステップＳ２１）、ＵＲＰパラメータのチェックを行なう（ステップＳ２２）。ここで、ＵＲＰパラメータ・チェックに失敗すると、ジョブ起動不可という結果を返す（ステップＳ２６）。

一方、ＵＲＰパラメータのチェックに成功すると、続いてＳＣＢを設定し（ステップＳ２３）、リソース・チェックを行なう（ステップＳ２４）。リソース・チェックに成功すると、ジョブ起動許可という結果を返す（ステップＳ２５）。また、リソース・チェックに失敗すると、ジョブ起動不可という結果を返す（ステップＳ２６）。

図１２には、ステップＳ２４で行なわれるリソース・チェック処理の手順をフローチャートの形式で示している。

まず、モード・リソース・チェック処理を行ない（ステップＳ３１）、チェック結果を判別する（ステップＳ３２）。ここで、モード・リソース・チェックに失敗すると、リソース・チェックに失敗した旨の結果を返す。

続いて、ＶＤＰの生成処理を行ない（ステップＳ３３）、ＶＤＰを無事に生成することができたかどうかを判別する（ステップＳ３４）。ここで、ＶＤＰの生成に失敗すると、リソース・チェックに失敗した旨の結果を返す。

続いて、排他リソースの確保を行ない（ステップＳ３５）、排他リソースを無事に確保することができたかどうかを判別する（ステップＳ３６）。ここで、排他リソースの確保に失敗すると、リソース・チェックに失敗した旨の結果を返す。

続いて、蓄積用メモリの確保を行ない（ステップＳ３７）、蓄積用メモリを無事に確保することができたかどうかを判別する（ステップＳ３８）。ここで、蓄積用メモリの確保に失敗すると、リソース・チェックに失敗した旨の結果を返す。

なお、ステップＳ３３におけるＶＤＰの生成処理、ステップＳ２５における排他リソースの確保処理、並びにステップＳ３７における蓄積用メモリの確保処理は一般的な処理なので、詳細な説明は省略する。

図１３には、ステップＳ３１で実行されるモード・リソース・チェックの処理手順をフローチャートの形式で示している。

まず、現在のモード及びモード読出しを行なう（ステップＳ４１）。

次いで、モード移行中かどうかをチェックする（ステップＳ４２）。ここで、モード移行中であれば、モード・リソース・チェックに失敗した旨の結果を返す。

次いで、起動不可モードかどうかをチェックする（ステップＳ４３）。ここで、起動不可モードであれば、モード・リソース・チェックに失敗した旨の結果を返す。

また、以上のチェックに成功した場合には、モード・リソース・チェックに成功した旨の結果を返す。

図１４には、メンテナンス・モード中に起動したジョブを終了するための処理手順をフローチャートの形式で示している。当該処理ルーチンは、図４に示したフローチャートのステップＳ６で実行される処理に相当する。

まず、ＶＤＰを最終更新し（ステップＳ５１）、次いで、ＶＤＰ値を反映させてＳＣＢを採集更新する（ステップＳ５２）。

次いで、ＪＰＬを獲得し（ステップＳ５３）、ＪＰＬをセットする（ステップＳ５４）。ＪＰＬはリングバッファ制御されており、最も古いログを獲得し、そこに今回終了したジョブの情報を書き込む。

そして、ＶＤＰ並びにＳＣＢを解放してから、排他リソースを解放し、本処理ルーチンを終了する。

次に、カウンタ処理について説明する。プリントに係る処理は、通常のプリント、複写機、複合機と同様であるので、ここでは説明は省略する。

図１５には、ファクシミリ送信してからモニタ・レポートを生成する場合を例にとって、カウンタ処理シーケンスとＤＶライブラリにおける処理フローを示している。また、表１１には、カウンタの一覧を示している。

プリンタ・コントローラより１頁プリント完了のプリント処理経過通知を受信したＦａｘモジュールは、ＳＣＢの現在のプリント枚数などのパラメータを適宜、更新した後、カウンタ制御用のＤＶライブラリをコールする。

このとき、ＳＣＢのパラメータを基に、控除／非控除の区分、アプリケーション種別、プリントした用紙サイズ、プリント時のカラーモードをＤＶライブラリに渡す。

ＤＶライブラリは、表１１に示したように、対象アプリケーション、カラー種別、ビリングかメンテナンスかのカウンタ種別、用紙サイズ区分に応じた複数のカウンタをＮＶＲＡＭ１０５に保持して制御しており、渡されたパラメータに基づいて、増加させるカウンタを特定して増加させる。

ビリングかメンテナンスかのカウンタ種別は、ビリングが控除及び非控除を含むすべてのビリング・カウントを行なうカウンタで、メンテナンス・カウンタがメンテナンスなどにより控除対象となるプリント枚数をカウントするカウンタである。

なお、表１１中の「サービス上のメーター区分」は、顧客に通知するメーターの区分を示している。このメーターの区分は、
・メーター１ Ｆｕｌｌ Ｃｏｌｏｒ（フルカラー）
・メーター２ Ｓｉｍｐｌｅ Ｃｏｌｏｒ（単色カラー）
・メーター３ ＢＷ（白黒）
となっており、操作者が操作部１１１上で操作して、メーターの値を確認する操作を行なうと、各メーター区分のカウント値を集計して、表示部１１０に表示するものである。

また、用紙サイズ区分は、カウント単位や課金単位の異なる用紙サイズを所定の用紙サイズ基準に判定し区分するためのものである。本実施形態では、Ａ３サイズを基準として、Ａ３以上、Ａ３未満の区分とした。このように、用紙サイズ区分に対応することで、外部クライアントやサーバのソフトウェアと連携して、より詳細な集計情報を提供することが可能である。

上記メーター１〜３の各集計を行なうときには、カウンタ毎のカウント単位を合わせるため、Ａ３未満の区分を基準とし、Ａ３以上のカウント値を所定倍（本実施形態では２倍）して集計する。

例えば、図１５に示した例では、モニタ・レポートは、自動で起動されるレポートなのでＳＣＢのアプリケーション種別は自動レポートが設定されている。したがって、表１１における対象アプリケーションＰｒｉｎｔ、Ｒｅｐｏｒｔのカウンタがカウント・アップの対象となる。

さらに、モニタ・レポートは、カラー種別は白黒（表１１中の表記はＢＷ）、控除種別は非控除、用紙サイズはＡ４サイズのパラメータがＳＣＢに設定されており、これらのパラメータが上記対象アプリケーションの情報とともにＤＶライブラリに渡され、増加させるべきカウンタＩＤ０１０のビリング・カウンタを特定できる。

また、メンテナンス中にカスタマー・エンジニアがＡ３サイズのチャートをテスト・コピーした場合には、アプリケーション種別はコピー、カラー種別はＦｕｌｌ Ｃｏｌｏｒ、控除種別は控除、用紙サイズ区分はＡ３以上となり、増加させるカウンタＩＤ０１３のビリング・カウンタ及びカウンタＩＤ０１５のメンテナンス・カウンタを特定できる。

次に、メンテナンス作業が終了した際の処理について説明する。

操作部１１１上での所定の操作（例えば、スタート・ボタンの長時間押下、メンテナンス終了用のタッチパネル上のボタン押下など）により、メンテナンス終了動作に入る。図１６には、メンテナンス作業が終了した際のモード移行を開始するための処理手順をフローチャートの形式で示している。これは、図４に示したフローチャートのステップＳ８に相当する。

ユーザ・インターフェース１０９は、メンテナンス終了指示を受けると、これをリクエスト・マネージャに通知する。システム・マネージャは、リクエスト・マネージャを介して、メンテナンス終了指示を受けたことを認識すると、ユーザ・インターフェース１０９や、ＬＡＮ、モデムなどのアプリケーションの起動要求を受けるモジュールに起動要求のロックを通知する（ステップＳ６１）。これは、レポートにカウンタ値の計算処理が入るため（後述）、メンテナンス終了処理をする際に、これ以上はカウント値の変更が発生しないよう、ジョブ要求を一旦閉めるためである。さらにユーザ・インターフェース１０９は、割込みキーの受付も禁止し、該処理中に新たなプリント処理が発生しないようにする。

次に、カスタマー・エンジニアに対し、ユーザ・インターフェース１０９を介して、サービス・レポートのみプリントするのか、あるいはサービス・レポートとともに機械来歴表もプリントするのか、確認入力を求める（ステップＳ６２）。

機械来歴表を作成しない場合には、サービス・レポートの作成処理を行なう（ステップＳ６７）。機械来歴表を作成する場合は、サービス・レポートの作成処理を実行してから（ステップＳ６３）、機械来歴表の作成処理を実行する（ステップＳ６４）。

次にレポート作成時に格納した各項目を読出し、テキスト・データに変換する。
これにＦＷＳサーバ宛ての電子メール・ヘッダを作成して暗号化し、電子メールとしてＦＷＳサーバに通知する（ステップＳ６５）。

以上で、メンテナンス終了に伴う作業が終了するので、次にノーマル・モードに移行する処理を行ない、メンテナンス・モードにいることを示すフラグ情報、メンテナンス・カウンタをリセットして、ノーマル・モードに移行する（ステップＳ６６）。

サービス・レポートの作成処理では、サービス・レポート記載項目をユーザ・インターフェース１０９に順次表示しながら、内容の確認、追加入力、変更を行なう。但し、顧客先に設置した複合機の固有情報は変更しない。図１７には、ステップＳ６３並びにＳ６７で実行される、サービス・レポート作成処理の手順をフローチャートの形式で示している。

ＲＯＭ１０３又はＮＶＲＡＭ１０５より情報を読み出し（ステップＳ７１）、表示部１１０に表示して（ステップＳ７２）、その内容の確認を行なう。ここで確認する項目として、顧客管理ＩＤ、機種コード、機械番号、サービス区分などを挙げることができる。上記の各項目をカスタマー・エンジニアが確認（承認）すると（ステップＳ７３）、これをＲＡＭ１０４に一旦格納してレポート中の該当欄に印字できるように保持する（ステップＳ７４）。

レポート中の項目を印刷のために保持するには、ＲＡＭ１０４や、ＮＶＲＡＭ１０５、ＨＤＤ１０６を利用することができる。ＮＶＲＡＭ１０５やＨＤＤ１０６などのように電源断を伴うような異常が発生した場合でも、該項目のデータを保持できる記憶手段であることが好ましい。

次いで、メンテナンス作業開始時の情報を読み出し（ステップＳ７５）、当該メンテナンス情報から自動設定する項目を設定する（ステップＳ７６）。

メンテナンス作業開始時の情報から内容を設定し、確認する項目として、目的コードとエラーコードを挙げることができる。目的コードは、入力した処置目的（定期点検、故障診断、消耗品交換、その他）から設定され、不具合情報処置内容を確認する。また、エラーコードは、入力した不具合内容（コメント記載、エラー履歴、ジョブ履歴より選択）から設定され、エラー履歴から不具合発生時のエラーコードを設定する。

また、メンテナンス情報から自動で設定する項目として、不具合情報処置内容と、次回作業メモを挙げることができる。不具合情報処置内容には、エラー内容と処置コードが含まれる。エラー内容として、エラーコードに対応する、あらかじめ格納されたエラー内容を記載する。処置内容として、処置コードと、エラーコードに対応する、あらかじめ格納された処置コードと処置内容を記載する。追加の処置が必要な場合は、処置内容を操作部１１０などから追加入力する。また、点検やＲＯＭ１０３内のファームウェアのバージョン更新などの場合には、エラーコードが無いので、コードと内容を追加入力する。次回作業メモには、使用部品、消耗品理由数量使用部品、消耗品理由数量などが記載される。これらは、エラーコードに対応する、あらかじめ格納された交換部品を設定する。これにより、ＦＷＳサーバへインプットする際に、自動で、部品発注が行なわれる。追加部品がある場合は、追加入力する。手持ちに部品があり作業完了した場合は、部品の削除を行なう。

なお、メンテナンス情報として追加入力する項目として、カスタマー・エンジニアの社員番号、メンテナンスの受付年月日、受付時刻、作業現場までの移動時間、訪問年月日、メンテナンス作業の開始時刻及び終了時刻、障害切分時間、診断・修理・点検時間などを挙げることができる。訪問年月日並びに開始時刻は、メンテナンス・モードに入った日時を自動設定してもよい。また、障害切分時間に診断・修理・点検時間を加えた時間を全作業時間の範囲で設定するようユーザ・インターフェース１０９から通知する。さらに、顧客から受けたミスコピー情報も控除の対象となるため、ミスコピーをカウントするメーター１、メーター２、メーター３を入力する。

そして、メンテナンス情報及びメンテナンス情報から自動設定される項目を表示部１１０に表示して（ステップＳ７７）、その内容の確認を行なう。上記の各項目をカスタマー・エンジニアが確認（承認）すると（ステップＳ７８）、これらをＲＡＭ１０４に一旦格納してレポート中の該当欄に印字できるように保持する（ステップＳ７９）。また、承認が取れない場合には、変更項目の設定処理を行ない（ステップＳ９２）、ステップＳ５７に戻って、項目表示と確認を再度行なう。

次いで、メーター情報を読み出して（ステップＳ８０）、終了メーターの算出処理（ステップＳ８１）、メンテナンス作業メーターの算出処理（ステップＳ８２）、訪問時メーターの算出処理（ステップＳ８３）を行なう。

そして、自動計算されたこれらメーター情報を表示部１１０に表示して（ステップＳ６４）、その内容の確認を行なう。上記の各項目をカスタマー・エンジニアが確認（承認）すると（ステップＳ８５）、これらをＲＡＭ１０４に一旦格納してレポート中の該当欄に記入し、ＨＤＤ１０６に蓄積する（ステップＳ８６）。また、承認が取れない場合には、メーター情報の変更項目の設定処理を行ない（ステップＳ９３）、ステップＳ８３に戻って、項目表示と確認を再度行なう。

次いで、別途手書き入力する項目を表示部１０９に表示して（ステップＳ８７）、カスタマー・エンジニアに操作部１１０からの手書き入力を促す。別途、手書きで入力する項目は帰社時刻などである。そして、手書き入力が行なわれると（ステップＳ８８）、これらをＲＡＭ１０４に一旦格納してレポート中の該当欄に記入し、ＨＤＤ１０６に蓄積する（ステップＳ８９）。

そして、ステップＳ７４、Ｓ７９、Ｓ８６、Ｓ８９により書き込まれた情報を用いてレポートを作成し、ＨＤＤ１０６に蓄積する（ステップＳ９０）。この後、読み出し及びプリント・フェーズに移行し、サービス・レポートをプリントする（ステップＳ９１）。また、機械来歴表の作成が指示されている場合は、上記サービス・レポートと同様に作成するが、ここでは説明を省略する。

図１８には、ステップＳ８１で実行される終了メーター算出処理の詳細な手順をフローチャートの形式で示している。

まず、カウンタＩＤ、終了メーター１、終了メーター２、終了メーター３を初期化する。具体的には、終了メーター１、終了メーター２、終了メーター３を０にリセットし、最初のカウンタＩＤ００１から処理を行うようにする（ステップＳ１０１）。

次に、終了メーターで集計するのはビリング・カウンタのみなので、カウンタのカウント種別がビリングであるかどうかを判定する（ステップＳ１０２）。ビリングで無い場合には、全カウンタに対して集計作業が済んだかどうかを判断し（ステップＳ１１４）、ビリングの場合には、カウンタのメーター区分が区分１か判定する（ステップＳ１０３）、メーター区分１で無い場合には、メーター区分２の判定を行う（ステップＳ１０７）。

メーター区分１である場合には、用紙サイズ区分を判定し（ステップＳ１０４）、Ａ３以上のサイズである場合には、既に述べたようにカウント値を２倍して終了メーター１を集計し（ステップＳ１０５）、Ａ３未満の場合は、そのまま終了メーター１を集計する（ステップＳ１０６）。

同様に、メーター区分２の場合にも、用紙サイズ区分を判定し（ステップＳ１０８）、Ａ３以上のサイズでの終了メーター２の集計（ステップＳ１０９）、Ａ３未満の場合は、そのまま終了メーター２を集計する（ステップＳ１１０）。

メーター区分１でも２でもない場合は、メーター区分３として、同様に、用紙サイズ区分を判定し（ステップＳ１１１）、Ａ３以上のサイズでの終了メーター２の集計（ステップＳ１１２）、Ａ３未満の場合は、そのまま終了メーター３を集計する（ステップＳ１１３）。

以上の処理が終わると、全カウンタに対して集計作業が済んだか判断し（ステップＳ１１４）、集計が済んでいない場合は、次のカウンタＩＤのカウンタ（ステップＳ１１５）に対して、カウント種別の判定（ステップＳ１０２）から、同様の処理を行い、そうでない場合は、メーターの補正処理を行い（ステップＳ１１６）終了メーター１、終了メーター２、終了メーター３の集計が終了する。

メーターの補正処理とは、各終了メーターにこれから実施するサービス・レポートや機械来歴表の予想されるビリング・カウント値を加算し補正する処理であるが、その詳細については後述に譲る。

図１９には、ステップＳ８２で実行されるメンテナンス・メーター算出処理の詳細な手順をフローチャートの形式で示している。

集計の考え方は、終了メーターの集計処理を同様で、カウンタＩＤ、メンテナンス・メーター１、メンテナンス・メーター２、メンテナンス・メーター３を初期化（ステップＳ１２１）する。

次に、メンテナンス・メーターで集計するのはメンテナンス・カウンタのみなので、カウンタのカウント種別がメンテナンスであるかどうか判定する（ステップＳ１２２）、メンテナンスで無い場合には、全カウンタに対して集計作業が済んだかどうかを判断する（ステップＳ１３４）。

また、カウンタ種別がメンテナンスの場合には、続いてカウンタのメーター区分が区分１か判定する（ステップＳ１２３）、メーター区分１で無い場合には、メーター区分２の判定を行なう（ステップＳ１２７）。

メーター区分１である場合には、用紙サイズ区分を判定し（ステップＳ１２４）、Ａ３以上のサイズでのメンテナンス・メーター１を集計（ステップＳ１２５）、Ａ３未満の場合は、そのままメンテナンス・メーター１を集計する（ステップＳ１２６）。

同様に、メーター区分２の場合にも、用紙サイズ区分を判定し（ステップＳ１２８）、Ａ３以上のサイズでのメンテナンス・メーター２の集計（ステップＳ１２９）、Ａ３未満の場合は、そのままメンテナンス・メーター１を集計する（ステップＳ１３０）。

メーター区分１でも２でもない場合は、メーター区分３として、同様に、用紙サイズ区分を判定し（ステップＳ１３１）、Ａ３以上のサイズでのメンテナンス・メーター２の集計（ステップＳ１３２）、Ａ３未満の場合は、そのままメンテナンス・メーター１を集計する（ステップＳ１３３）。

以上の処理が終わると、全カウンタに対して集計作業が済んだか判断し（ステップＳ１３４）、集計が済んでいない場合は、次のカウンタＩＤのカウンタ（ステップＳ１３５）に対して、カウント種別の判定（ステップＳ１２２）から、同様の処理を行ない、そうでない場合は、メーターの補正処理を行ない（ステップＳ１３６）、メンテナンス・メーター１、メンテナンス・メーター２、メンテナンス・メーター３の集計が終了する。

図２０には、図１８に示したフローチャートのステップＳ１１６、並びに図１９に示したフローチャートのステップＳ１３６で実行されるメーター補正処理の手順をフローチャートの形式で示している。

メーター補正処理は、機械来歴表のプリント指示をされているかチェックし（ステップＳ１４１）、機械来歴表がプリント指示されていない場合には、サービス・レポートのメーター確定及び増加処理を行なう（ステップＳ１４２）。

また、機械来歴表がプリント指示されている場合には、サービス・レポートのメーター確定及び増加処理（ステップＳ１４３）と、機械来歴表のメーター確定及び増加処理（ステップＳ１４４）とを行ない、メーターの補正処理を終了する。

図２１には、メーター確定及び増加処理の手順をフローチャートの形式で示している。

メーター確定及び増加処理では、まず、システム・マネージャが有するリソース情報などとしてプログラム上に格納されているＳｅｒｖｉｃｅの起動パラメータ（「アプリケーション種別」、「カラー種別」、「控除種別」（控除、非控除の区別）、「プリント枚数」（レポート系のＳｅｒｖｉｃｅは予めプリント枚数が定まっている）、「用紙サイズ」（レポートをプリントする用紙サイズ））をサービス・レポートと機械来歴表との指定に基づいて、対応するＳｅｒｖｉｃｅの起動パラメータを読出す（ステップＳ１５１）。

表１１に示すカウンタの一覧から明らかなように、読み出したパラメータから「アプリケーション種別」、「カラー種別」、「控除種別」（控除、非控除の区別）、「用紙サイズ区分」（用紙サイズより特定）を判定し、実際にプリント時に増加されるカウンタＩＤを特定する（ステップＳ１５２）。

次に、レポートのプリント枚数とそのカウンタの「用紙サイズ区分」の所定倍数値、本実施例では既に述べたように２倍を基に、実際のプリント時にカウンタの増加値を算出する（ステップＳ１５３）。

次に、メーターの区分Ｎ（Ｎ＝１〜３）は、カウンタＩＤから一意に特定できるため、これを基に、終了メーターＮ、メンテナンス・メーターＮのいずれか指定されたメーターを特定し（ステップＳ１５４）、先の確定したカウンタの増加分を加算してメーターを増加補正（ステップＳ１５５）する。

図２２には、ステップＳ８３で実行される訪問時メーター算出処理の詳細な手順をフローチャートの形式で示している。

訪問メーターは、各訪問メーターＮについて、終了メーターＮとメンテナンス・メーターＮの差分を取ることで、算出することができる（ステップＳ１６１、ステップＳ１６２、ステップＳ１６３）。

なお、図１７に示したサービス・レポートの作成処理手順では、ステップＳ７４、Ｓ７９、Ｓ８６、Ｓ８９の後に、サービス・レポートなどをプリントするためのレポートを作成したが、このアプリケーションの起動をステップＳ８０より前に行なうようにしてもよい。この場合、アプリケーションの起動と用紙サイズが確定し、スケジューリングがされた時点で「メーター値確定及びレポート開始指示待ち」まで、アプリケーションが実行開始待ち状態になるよう制御する。

このような変形例の場合、実行開始待ち状態のアプリケーションのＳＣＢから、図２０に示す補正のためのパラメータを読み出し、そのパラメータに基づき、各メーターの算出処理が終了し、ステップＳ８９の処理の終了が確定した時点で、実行開始待ち状態を解除して、レポート作成を開始する。

通常、自動レポートなどでは、レポートプリントの用紙サイズに適合する用紙がトレイに格納されていない場合、自動でプリント可能な他の用紙サイズを選択してプリント可能である。上記の変形例では、このようなケースでも、ＳＣＢにその選択した他の用紙サイズが格納されるため、その用紙サイズに応じたメーターの補正処理が可能となる。

さらに、トレイ内の用紙残量を検知するセンサーがある装置の場合、用紙残量が間もなく無くなることセンサーが検知している状況で、同様に他のサイズの用紙選択をすることで、レポート中の用紙切れを低減し、且つ、その用紙サイズに応じたメーターの補正処理が可能とする。

サービス・レポートのプリントを行なう際、レポートのプリントの優先順位を高に設定して処理する。これは、レポートのプリントを行なう最中に割込みプリントなどが行なわれると、控除対象のメーター値が正確でなくなるので、優先順位高く設定することで、ジョブの割り込みを抑制するためである。

また、サービス・レポート作成時や機械来歴表作成時にジャムが発生すると正確なメーターがカウントできないので、サービス・レポートのメーター計算からすべて実行し直す。

サービス・レポートの事例は図２５に示した通りである。同図に示した例では、テクニカル・センタ行と、お客様控の２枚のみだが、図示しない営業所控え、発行者控え（いずれも基本的な内容はテクニカル・センタ行と同様）が必要な場合、プリント枚数は４枚となる。

図２３には、図１６に示したフローチャートのステップＳ４５で実行される、ＦＷＳサーバへサービス・レポートを通知するための処理手順をフローチャートの形式で示している。

図１７に示したサービス・レポート作成処理において格納した各項目を読み出すと（ステップＳ１７１）、これらレポート・データをテキスト・データに変換する（ステップＳ１７２）。

次いで、このテキスト・データにＦＷＳサーバ宛ての電子メール・ヘッダを作成して（ステップＳ１７３）、さらにこのメール文書を暗号化して（ステップＳ１７４）、電子メールとしてＦＷＳサーバに送信する（ステップＳ１７５）。

図２３に示した処理手順によりＦＷＳサーバへのサービス・レポートを通知することで、メンテナンス終了に伴う作業が終了すると、続いてノーマル・モードに移行する処理を行なう。図２４には、図１６に示したフローチャートのステップＳ４６で実行される、モード移行処理の手順をフローチャートの形式で示している。

この移行処理では、まず、エントリ条件のチェックを行なう（ステップＳ１８１）。このチェックに失敗すると、モード移行が不可であるという結果を返す（ステップＳ１８５）。

一方、エントリ条件のチェックに成功した場合には、次いで、メンテナンス・モードにいることを示すフラグ情報をリセットし（ステップＳ１８２）、さらにメンテナンス・カウンタをリセットし（ステップＳ１８３）、保持されているメンテナンス情報をクリアして（ステップＳ１８４）、ノーマル・モードに移行する。

以上の構成により、カスタマー・エンジニアが顧客先でのメンテナンス作業を行なっている際に、画質や動作確認のためのテスト・コピー起動したときには控除用としてカウントされる一方、顧客のＰＣプリントを起動禁止にすることで、メンテナンス作業への影響をなくすとともに、顧客の取引先からのファクシミリ受信プリントを起動して非控除としてカウントすることにより、各種アプリケーションを起動でき、適切にカウンタをカウントできるようになる。

以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

上述した実施形態の応用例として、メンテナンス・カウンタを用意せず、メンテナンス状態では、カウンタを停止し、非控除のジョブが起動された場合のみ、カウンタの動作を再開するようにしてもよい。この場合は、サービス・レポートのメンテナンス作業による控除の項目は不要になる。このような構成は単純で、実装し易い。但し、カウンタを停止してしまうため、枚数によりライフを計算している消耗品の正確なライフ計算ができなくなるという点に留意されたい。

また、ＦＷＳサーバに対する通知を行なう場合は、電子情報による情報インプットが行なわれるため、営業所控えや発行者控えのためのサービス・レポートを発行しないようにしてもよい。また、レポート、来歴表作成時のジャムについても、最終的なＦＷＳサーバへの送信データ作成時にメーター値を再計算して通知するようにしてもよい。このようにすれば、ＦＷＳサーバへは正確な数値が通知されるため、プリントしてレポート、来歴表は手書き修正でことが足りる。

上述した実施形態では、メンテナンス状態で、ＰＣプリントを起動しなかった。但し、定期的な点検などメンテナンス中に複合機の電源オフ／オン、リブートを伴わないレベルの保守であれば、ＰＣプリント・ジョブを起動し、プリント・データの受信及び蓄積フェーズまでを実施し、これ以降のプリント・フェーズの処理は実施しないようにＰａｓｓｉｖｅの待ちキューに配するようスケジューリング制御を実施してもよい。加えて、上述した実施形態のように禁止できる制御と選択できるようにしてもよい。上述した実施形態の場合、ＰＣプリントは起動拒否されるので、顧客はメンテナンス終了後、再度、プリント指示をしなくてはならないが、このような制御であれば、受信してプリント処理を待ち状態にしているので、再指示の必要が無い上、メンテナンス終了後、直ちにジョブが実行できるメリットがある。

また、表８のようなテーブルに基づくようなメンテナンス中の起動可否判断をして起動可能なアプリケーションのみを起動するだけでも、従来よりも適切なビリング・カウントを実現できる。さらに、起動アプリケーション毎にメンテナンス中に起動可能なものにビリング・カウントするか否か、例えば、本実施例のような控除、非控除の情報を持つことで、より適切にビリング・カウントすることができる。

また、表８のようなテーブルに基づくようなメンテナンス中の起動可否判断で、特定のアプリケーションは禁止するものの、重要性の高いファクシミリ受信などのアプリケーションは起動可能と設定し制御することで、重要性の高いファクシミリ受信は起動するという使用者のメリットと、重要性の低いバックグランドのアプリケーションを規制してメンテナンス作業に集中できるというＣＥ（カスタマー・エンジニア）のメリットをそれぞれ提供できる。更には、メンテナンス中に起動されたアプリケーションを通常通りカウントするだけでも、より適切なビリング・カウントも実現できる。

また、表８のようなテーブルに基づくようなメンテナンス中の起動可否判断で、メンテナンス中に起動されたフォアグランドのジョブ用のメンテナンス・カウンタを表１１のように持ち、これにカウントすることで、より適切な控除作業を提供できる。

また、上述した実施形態では、終了メーターとメンテナンス・メーターから訪問時のメーター値を算出したが、メンテナンス作業開始時の各カウンタの値を訪問時のカウンタとして保持することで、メンテナンスに要した控除分のメーター値を、メンテナンス作業終了時のカウント値と訪問時のカウント値の差分から算出して通知することも可能である。

なお、本明細書では、図３のようなソフトウェア構成や名称を示したが、複合機の制御ソフトウェアは、このような構成に限定されるものではない。また、ジョブの起動制御についても、ＳＣＢというパラメータブロックに必要な情報を格納した後に各種の判定を行なっているが、表８に相当するテーブルとアプリケーション名から直接起動可否を判断する制御方法など、メンテナンス中の起動可否が判断できる制御方法であれば特に限定されない。

また、表１１に示すカウンタについても、メンテナンス用のカウンタといった要旨を除き、装置、方法、システムに適用したカウンタ制御で構わない。例えば、用紙サイズ区分毎にカウンタを設けなくても、用紙サイズ毎のカウント増加値を設定するような制御（Ａ４：１カウント、Ａ３：２カウントなど）であっても構わないし、白黒のプリントしか出来ないものでは、カラー種別などの項目が無くても構わない。

要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。

図１は、カスタマー・エンジニアによる複合機のメンテナンス情報を一元管理するＦＷＳシステムの全体構成を模式的に示した図である。 図２は、複合機１００のハードウェア構成を模式的に示した図である。 図３は、複合機上の動作を制御するためのソフトウェア構成を模式的に示した図である。 図４は、メンテナンス動作の概略的な手順を示したフローチャートである。 図５は、複合機１００がメンテナンス・モードへ移行するための処理手順を示したフローチャートである。 図６は、複合機１００のメンテナンス・モード移行時の動作シーケンスを示した図である。 図７は、複合機１００内で使用されるパラメータの概念を説明するための図である。 図８は、ＵＲＰの概略的なデータ構成を示した図である。 図９は、ＳＣＢの概略的なデータ構成を示した図である。 図１０は、ＶＤＰの概略的なデータ構成を示した図である。 図１１は、メンテナンス・モード中にバックグランド・ジョブが発生したときのジョブ起動の可否を判断するための処理手順を示したフローチャートである。 図１２は、リソース・チェック処理の手順を示したフローチャートである。 図１３は、モード・リソース・チェックの処理手順を示したフローチャートである。 図１４は、ジョブ終了処理の手順を示したフローチャートである。 図１５は、カウンタ処理シーケンスとＤＶライブラリにおける処理フローを示した図である。 図１６は、メンテナンス作業が終了した際のモード移行を開始するための処理手順を示したフローチャートである。 図１７は、サービス・レポート作成処理の手順を示したフローチャートである。 図１８は、終了メーター算出処理の詳細な手順を示したフローチャートである。 図１９は、メンテナンス・メーター算出処理の詳細な手順を示したフローチャートである。 図２０は、メーター補正処理の手順を示したフローチャートである。 図２１は、メーター確定及び増加処理の手順を示したフローチャートである。 図２２は、訪問時メーター算出処理の詳細な手順を示したフローチャートである。 図２３は、ＦＷＳサーバへサービス・レポートを通知するための処理手順を示したフローチャートである。 図２４は、メンテナンス・モードからノーマル・モードへ復帰するためのモード移行処理の手順を示したフローチャートである。 図２５は、サービス・レポートの構成例を示した図である。 図２６は、保守完了報告書の構成例を示した図である。

符号の説明

１００…複合機
１０１…ＣＰＵ
１０２…バス
１０３…ＲＯＭ
１０４…ＲＡＭ
１０５…ＮＶＲＡＭ
１０６…ＨＤＤ
１０７…画像処理部
１０８…ＵＩインターフェース
１０９…ユーザ・インターフェース
１１０…表示部
１１１…操作部
１１２…通信インターフェース
１１３…ＬＡＮインターフェース
１１４…シリアル・インターフェース
１１５…ＵＳＢインターフェース
１１６…モデム
１１７…コインキット
１１８…デバイス・インターフェース
１１９…読取装置部
１２０…印刷装置部
１２１…排出用紙格納部

Claims (27)

1. 画像情報を出力する画像形成装置であって、
   フォアグランド又はバックグランドのジョブ要求に応じて画像情報を媒体上に形成する画像形成手段と、
   前記画像形成手段が実行した画像形成回数をビリング・カウントするカウンタと、
   当該装置のメンテナンス作業中に起動可能なジョブの種別の設定を受容する起動ジョブ可否設定手段と、
   ジョブ要求並びにメンテナンス作業の開始及び終了の指示を含んだ指示操作の入力を受容する入力手段と、
   前記入力手段からのメンテナンス作業の開始及び終了の指示操作に応じてメンテナンス作業モードの開始及び終了を行なう動作制御手段と、
   前記カウンタによるビリング・カウント動作を制御するカウンタ制御手段と、
   メンテナンス作業モード下でジョブ要求が発生したときに、前記起動ジョブ可否設定手段により起動可能と設定されたジョブの起動を許可するジョブ起動許可手段と、
   を具備することを特徴とする画像形成装置。
2. 前記カウンタ制御手段は、メンテナンス作業の開始時に前記カウンタによるビリング・カウントを停止し、メンテナンス作業の終了時に前記カウンタによるビリング・カウントを再開するとともに、メンテナンス作業中に前記ジョブ起動許可手段により起動されたジョブの実行による画像形成回数をビリング・カウントする、
   ことを特徴とする請求項１に記載の画像形成装置。
3. 前記起動ジョブ可否設定手段は、当該装置のメンテナンス作業中の起動を許可した各ジョブを実行したときの画像形成回数をビリング・カウントするかどうかを設定する、
   ことを特徴とする請求項２に記載の画像形成装置。
4. 前記起動ジョブ可否設定手段は、バックグランド・ジョブの中から当該装置のメンテナンス作業中の起動可能なジョブを設定する、
   ことを特徴とする請求項１に記載の画像形成装置。
5. 前記カウンタ制御手段は、メンテナンス作業中は前記カウンタによるビリング・カウントを停止し、前記ジョブ起動許可手段により起動されたバックグランド・ジョブの実行による画像形成回数をビリング・カウントする、
   ことを特徴とする請求項４に記載の画像形成装置。
6. 前記カウンタ制御手段は、前記カウンタによりすべてのジョブの画像形成回数をビリング・カウントさせ、
   メンテナンス作業中にフォアグランドで指示されたジョブの画像形成回数をカウントするメンテナンス用カウンタをさらに備える、
   ことを特徴とする請求項１に記載の画像形成装置。
7. 前記カウンタ制御手段は、前記カウンタによりすべてのジョブの画像形成回数をビリング・カウントさせ、
   メンテナンス作業開始時の前記カウンタの値を訪問メーターとして保持する訪問メーター保持手段と、
   メンテナンス作業終了時の前記カウンタの値を終了メーターとし、訪問メーターと終了メーターを基にメンテナンス作業による控除対象となるメンテナンス作業メーター値を算出する控除処理手段と、
   前記の訪問メーター及び終了メーターの値を基にメンテナンス結果報告通知を行なう報告通知手段と、
   をさらに備えることを特徴とする請求項１に記載の画像形成装置。
8. 前記カウンタ制御手段は、前記カウンタを用いてすべてのジョブの画像形成回数をビリング・カウントさせて、メンテナンス作業終了時の前記カウンタの値を終了メーターとするとともに、前記カウンタとは別のメンテナンス用カウンタを用いてメンテナンス作業中に実行したジョブの画像形成回数をカウントし、
   前記控除処理手段は、前記終了メーターの値と前記メンテナンス用カウンタの値とを基に訪問メーターの値を算出し、
   前記訪問メーター及び終了メーターの値を基にメンテナンス結果通知を行なう報告通知手段をさらに備える、
   ことを特徴とする請求項１に記載の画像形成装置。
9. 前記控除処理手段は、前記報告通知手段によるメンテナンス結果報告通知の画像形成回数の予測値を終了メーター値に加算してメンテナンス作業メーター値を算出する、
   ことを特徴とする請求項７又は８のいずれかに記載の画像形成装置。
10. 前記の訪問メーター、終了メーター、メンテナンス作業メーターの各値を、控除処理を管理する外部装置に通知する通知手段をさらに備える、
    ことを特徴とする請求項７に記載の画像形成装置。
11. 前記報告通知手段は、メンテナンス結果報告通知を行なう際にジャム若しくはその他の障害が発生したときに、ジョブを中止して再度起動する、
    ことを特徴とする請求項７に記載の画像形成装置。
12. 前記ジョブ起動許可手段は、前記報告通知手段がメンテナンス結果報告通知を行なっている最中は、ジョブの起動を禁止する、
    ことを特徴とする請求項７に記載の画像形成装置。
13. メンテナンス結果報告通知の優先順位を、ユーザが通常指示できるジョブよりも高く設定する、
    ことを特徴とする請求項１２に記載の画像形成装置。
14. フォアグランド又はバックグランドのジョブ要求に応じて画像情報を媒体上に形成するとともに、カウンタを用いて画像形成回数をビリング・カウントする画像形成方法であって、
    メンテナンス作業中に起動可能なジョブの種別の設定を受容する起動ジョブ可否設定ステップと、
    メンテナンス開始指示に応じてメンテナンス作業モードに遷移するメンテナンス開始ステップと、
    メンテナンス作業下でジョブ要求が発生したときに、前記起動ジョブ可否ステップにおいて起動可能と設定されたジョブのみ起動を許可するジョブ起動許可ステップと、
    メンテナンス終了指示に応じてメンテナンス作業モードから通常モードに復帰するメンテナンス終了ステップと、
    を具備することを特徴とする画像形成方法。
15. 通常モード下でのジョブの実行による画像形成回数をビリング・カウントする第１のビリング・カウント・ステップと、
    メンテナンス作業モード下でメンテナンス作業中に前記ジョブ起動許可ステップにおいて起動されたジョブの実行による画像形成回数をビリング・カウントする第２のビリング・カウント・ステップと、
    をさらに備えることを特徴とする請求項１４に記載の画像形成方法。
16. 前記起動ジョブ可否設定ステップでは、メンテナンス作業中の起動を許可した各ジョブを実行したときの画像形成回数をビリング・カウントするかどうかを設定する、
    ことを特徴とする請求項１５に記載の画像形成方法。
17. 前記起動ジョブ可否設定ステップでは、バックグランド・ジョブの中から当該装置のメンテナンス作業中の起動可能なジョブを設定する、
    ことを特徴とする請求項１４に記載の画像形成方法。
18. メンテナンス作業中は前記カウンタによるビリング・カウントを停止するステップと、
    前記ジョブ起動許可ステップにより起動されたバックグランド・ジョブの実行による画像形成回数をビリング・カウントするステップと、
    をさらに備えることを特徴とする請求項１７に記載の画像形成方法。
19. 前記カウンタによりすべてのジョブの画像形成回数をビリング・カウントさせ、
    メンテナンス作業中にフォアグランドで指示されたジョブの画像形成回数をメンテナンス用カウンタでカウントするステップをさらに備える、
    ことを特徴とする請求項１７に記載の画像形成方法。
20. 前記カウンタによりすべてのジョブの画像形成回数をビリング・カウントさせ、
    メンテナンス作業開始時の前記カウンタの値を訪問メーターとして保持する訪問メーター保持ステップと、
    メンテナンス作業終了時の前記カウンタの値を終了メーターとし、訪問メーターと終了メーターを基にメンテナンス作業による控除対象となるメンテナンス作業メーター値を算出する控除処理ステップと、
    前記の訪問メーター及び終了メーターの値を基にメンテナンス結果報告通知を行なう報告通知ステップと、
    をさらに備えることを特徴とする請求項１４に記載の画像形成方法。
21. すべてのジョブの画像形成回数をビリング・カウントして、メンテナンス作業終了時におけるカウンタ値を終了メーターとするビリング・カウント・ステップと、
    メンテナンス作業中に実行したジョブの画像形成回数をカウントするメンテナンス用カウント・ステップと、
    前記終了メーターの値と前記メンテナンス用カウント・ステップにおけるカウント値とを基に訪問メーターの値を算出する訪問メーター算出ステップと、
    前記訪問メーター及び終了メーターの値を基にメンテナンス結果通知を行なう報告通知ステップと、
    をさらに備えることを特徴とする請求項１４に記載の画像形成方法。
22. 前記控除処理ステップでは、前記報告通知ステップにおけるメンテナンス結果報告通知の画像形成回数の予測値を終了メーター値に加算してメンテナンス作業メーター値を算出する、
    ことを特徴とする請求項２０又は２１のいずれかに記載の画像形成方法。
23. 前記の訪問メーター、終了メーター、メンテナンス作業メーターの各値を、控除処理を管理する外部装置に通知する通知ステップをさらに備える、
    ことを特徴とする請求項２０に記載の画像形成方法。
24. 前記報告通知・ステップにおいてメンテナンス結果報告通知を行なう際にジャム若しくはその他の障害が発生したときに、ジョブを中止して再度起動する、
    ことを特徴とする請求項２０に記載の画像形成方法。
25. 前記ジョブ起動許可ステップでは、前記報告通知・ステップにおいてメンテナンス結果報告通知を行なっている最中は、ジョブの起動を禁止する、
    ことを特徴とする請求項２０に記載の画像形成方法。
26. ユーザが通常指示できるジョブよりも高い優先順位でメンテナンス結果報告通知を実行する、
    ことを特徴とする請求項２５に記載の画像形成方法。
27. フォアグランド又はバックグランドのジョブ要求に応じて画像情報を媒体上に形成するとともに、カウンタを用いて画像形成回数をビリング・カウントするための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
    メンテナンス作業中に起動可能なジョブの種別の設定を受容する起動ジョブ可否設定手順と、
    メンテナンス開始指示に応じてメンテナンス作業モードに遷移するメンテナンス開始手順と、
    メンテナンス作業下でジョブ要求が発生したときに、前記起動ジョブ可否手順により起動可能と設定されたジョブのみ起動を許可するジョブ起動許可手順と、
    メンテナンス作業モード下で、前記カウンタによるビリング・カウントを停止するとともに、メンテナンス作業中に前記ジョブ起動許可手順により起動されたジョブの実行による画像形成回数をビリング・カウントする控除カウント手順と、
    メンテナンス終了指示に応じてメンテナンス作業モードから通常モードに復帰するメンテナンス終了手順と、
    を実行させることを特徴とするコンピュータ・プログラム。
    

Images