以下、図面を参照し、本発明の実施形態について説明する。以下の説明において、認証課金装置とは、認証装置と課金装置をまとめて表現するものであり、まとめて表現する必要が特にない場合、それぞれ認証装置、課金装置と表現する。
図1を用いて、MFP1に搭載されているプログラムについて説明する。図1には、MFP1のプログラム群2と、ハードウェア資源4とが示されている。
MFP1は、電源投入とともにアプリケーション層5およびコントローラ層6を起動する。例えばMFP1は、アプリケーション層5およびコントローラ層6のプログラムを、ハードディスク装置(以下、HDD65と記す)などから読み出し、読み出した各プログラムをメモリ領域に転送して起動する。ハードウェア資源は、スキャナエンジン51と、プロッタエンジン52と、後述するFCU68と、SRAM99と、HDD65とを含む。
また、プログラム群2は、UNIX(登録商標)などのオペレーティングシステム(以下、OSと記す)上に起動されているアプリケーション層5とコントローラ層6とを含む。アプリケーション層5は、プリンタ、コピー、ファックスおよびスキャナなどの画像形成に係るユーザーサービスにそれぞれ固有の処理を行うプログラムや、ドライバ群50を含む。
アプリケーション層5は、プリンタ用のアプリケーションであるプリンタアプリ20と、コピー用アプリケーションであるコピーアプリ21と、ファックス用アプリケーションであるファックスアプリ22と、スキャナ用アプリケーションであるスキャナアプリ23と、ネットファイルアプリ24とを含む。さらに、アプリケーション層5は、SDK(Software Development Kit)アプリ26と、VAS(Virtual Application Service)25とを含む。
また、コントローラ層6は、アプリケーション層5からの処理要求を解釈してハードウェア資源の獲得要求を発生するコントロールサービス層7と、1つ以上のハードウェア資源の管理を行ってコントロールサービス層7からの獲得要求を調停するシステムリソースマネージャ(以下、SRMと記す)40と、SRM40からの獲得要求に応じてハードウェア資源の管理を行うハンドラ層8とを含む。
コントロールサービス層7は、ネットワークコントロールサービス(以下、NCSと記す)30、デリバリーコントロールサービス(以下、DCSと記す)31、エンジンコントロールサービス(以下、ECSと記す)34、メモリコントロールサービス(以下、MCSと記す)35、ユーザーインフォメーションコントロールサービス(以下、UCSと記す)37、システムコントロールサービス(以下、SCSと記す)38、認証課金コントロールサービス(以下、CCSと記す)39など、一つ以上のサービスモジュールを含むように構成されている。なお、CCS39は、認証課金サービス手段に対応する。
なお、コントローラ層6は予め定義されている関数により、アプリケーション層5からの処理要求を受信可能とするGW−API43を有するように構成されている。OSは、アプリケーション層5およびコントローラ層6の各プログラムをプロセスとして並列実行する。
NCS30のプロセスは、ネットワークI/Oを必要とするアプリケーションに対して共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。
例えばNCS30は、ネットワークを介して接続されるネットワーク機器とのデータ通信をhttpd(HyperText Transfer Protocol Daemon)により、HTTP(HyperText Transfer Protocol)で制御する。
DCS31のプロセスは、蓄積文書の配送などの制御を行う。ECS34のプロセスは、スキャナエンジン51、プロッタエンジン52などのエンジンの制御を行う。MCS35のプロセスは、メモリの取得および解放、HDD65の利用などのメモリ制御を行う。UCS37のプロセスは、ユーザー情報の管理を行う。
SCS38のプロセスは、アプリケーション管理、操作部制御、システム画面表示、LED表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行う。
SRM40のプロセスは、SCS38と共にシステムの制御およびハードウェア資源の管理を行うものである。例えばSRM40のプロセスは、スキャナエンジン51やプロッタエンジン52などのハードウェア資源を利用する上位層からの獲得要求に従って調停を行い、実行制御する。
具体的に、SRM40のプロセスは獲得要求されたハードウェア資源が利用可能であるかを判定し、利用可能であれば獲得要求されたハードウェア資源が利用可能である旨を上位層に通知する。また、SRM40のプロセスは上位層からの獲得要求に対してハードウェア資源を利用するためのスケジューリングを行い、例えば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成などの要求内容を直接実施している。
また、ハンドラ層8はFCU68の管理を行うファックスコントロールユニットハンドラ(以下、FCUHと記す)41と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ(以下、IMHと記す)42とを含む。SRM40およびFCUH41は、予め定義されている関数によりハードウェア資源に対する処理要求を送信可能とし、PCIが用いられたエンジンI/F44を利用して、ハードウェア資源に対する処理要求を行う。
以上説明したソフトウェアで、各アプリは、後述する認証画面の表示/非表示の指示、認証設定の通知、課金設定の通知をCCS39に対して行う。認証設定通知を受けたCCS39は、設定された内容に応じた認証状態を応答する。SCS38は、画面の表示制御を行う。SRM40は、プロセス実行に伴う課金タイミングの指示を行う。UCS37は、アドレス帳ユーザーの情報取得を行い、CCS39に提供する。NCS30は、ネットワーク認証情報の取得を行う。
図2は、MFP1の一実施例のハードウェア構成図を示している。MFP1は、コントローラボード60と、オペレーションパネル53と、FCU68と、スキャナエンジン51と、プロッタエンジン52とを含む。また、FCU68は、G3規格対応ユニット69と、G4規格対応ユニット70とを有する。
また、コントローラボード60は、CPU61と、ASIC66と、HDD65と、ローカルメモリ(MEM−C)64と、システムメモリ(MEM−P)63と、ノースブリッジ(以下、NBと記す)62と、サウスブリッジ(以下、SBと記す)73と、NIC74(Network Interface Card)と、USBデバイス75と、IEEE1394デバイス76と、セントロニクスデバイス77とを含む。
オペレーションパネル53は、コントローラボード60のASIC66に接続されている。また、SB73と、NIC74と、USBデバイス75と、IEEE1394デバイス76と、セントロニクスデバイス77は、NB62にPCIバスで接続されている。
また、FCU68と、スキャナエンジン51と、プロッタエンジン52は、コントローラボード60のASIC66にPCIバスで接続されている。
なお、コントローラボード60は、ASIC66にローカルメモリ64、HDD65などが接続されると共に、CPU61とASIC66とがCPUチップセットのNB62を介して接続されている。このように、NB62を介してCPU61とASIC66とを接続すれば、CPU61のインタフェースが公開されていない場合に対応できる。
なお、ASIC66とNB62とはPCIバスを介して接続されているのでなく、AGP(Accelerated Graphics Port)67を介して接続されている。このように、図1のアプリケーション層5やコントローラ層6を形成する一つ以上のプロセスを実行制御するため、ASIC66とNB62とを低速のPCIバスでなくAGP35を介して接続し、パフォーマンスの低下を防いでいる。
CPU61は、MFP1の全体制御を行うものである。CPU61は、NCS30、DCS31、ECS34、MCS35、UCS37、CCS39、SCS38、SRM40、FCUH41およびIMH42をOS上にそれぞれプロセスとして起動して実行させると共に、アプリケーション層5を形成するプリンタアプリ20、コピーアプリ21、ファックスアプリ22、スキャナアプリ23、ネットファイルアプリ24、SDKアプリ26を起動して実行させる。
NB62は、CPU61、システムメモリ63、SB73およびASIC66を接続するためのブリッジである。システムメモリ63は、MFP1の描画用メモリなどとして用いるメモリである。ローカルメモリ64はコピー用画像バッファ、符号バッファとして用いるメモリである。システムメモリ63とローカルメモリ64は、図1のSRAM99に対応する。また、SB73は、NB62とPCIバス、周辺デバイスとを接続するためのブリッジである。
ASIC66は、画像処理用のハードウェア要素を有する画像処理用途向けのICである。HDD65は、画像データの蓄積、文書データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積などを行うためのストレージである。また、オペレーションパネル53は、ユーザーからの入力操作を受け付けると共に、ユーザーに向けた表示を行う操作部である。
以上のハードウェア構成に、必要に応じて認証課金装置が加わる。本実施の形態では、認証課金装置として、キーカードを用いるものと、コインラックと、マルチファンクション(以下、MFと記す)カードと、キーカウンターがある。これらは、認証課金手段に対応する。
次に、CCS39について詳細な説明をする。CCSとはCertification and charge Control Serviceの略であり、従来SCSが行っていた認証/課金/利用者制限機能と、同等の機能を達成し、セキュリティ強化に対応するためのアクセスロールに伴い、認証された個人に対応した利用可能機能(利用不可能機能)に関する情報(以下、制限情報と記す)を発行するものである。そして、新たな認証/課金方法が登場した時に、容易に拡張できるようにしたものである。
図3には、CCS39のスレッド構成が示されている。CCS39のスレッド構成は、共通処理モジュールであるCCSメインスレッド110と、認証課金モジュール群120(以下、認証課金モジュールまたは認証課金モジュール群をCCMと記すこともある)と、I/Oモジュール130からなっている。
CCSメインスレッド110は、アプリや他のモジュールのインタフェースであり、認証管理、課金管理、画面生成などを行う。生成された画面は、オペレーションパネル53に表示される。
次に、認証課金モジュール群120について説明する。認証課金モジュール群120は、個人認証スレッド124と、キーカウンタースレッド123と、外部課金装置スレッド122と、ユーザーコードスレッド121の各認証課金モジュールで構成され、認証方法に応じた認証管理、課金管理、画面生成を行う。これらの認証課金モジュールは、各認証課金装置ごとに設けられるが、基本的には同一の構成からなるのスレッドであり、どのスレッドで動作するかを示す指示により、各認証課金モジュールとして動作する。このことについては、後に詳しい説明をする。
個人認証スレッド124は、Basic認証とWindows(登録商標)認証とLDAP認証を行う。ユーザーコードスレッド121は、ユーザーコードを用いた認証を行う。キーカウンタースレッド123は、認証課金装置としてキーカウンターを用いる場合に対応するスレッドである。
外部課金装置スレッド122は、認証課金装置として、キーカード、コインラック、MFキーカードを用いる場合に対応するスレッドである。
次に、課金や認証に関する情報を入出力するI/Oモジュール130について説明する。I/Oモジュール130は、機器内アドレス帳I/Oスレッド134と、NTサーバI/Oスレッド135と、LDAPサーバI/Oスレッド136と、外部課金I/Oスレッド132と、MFキーカードI/Oスレッド131と、キーカウンターI/Oスレッド133で構成され、アプリケーション層5やサービス層7の各モジュールや各認証課金装置と通信して、各機器の認証状態を受信したり、認証要求を発行したりする。
機器内アドレス帳I/Oスレッド134は、機器内アドレス帳に関する通信を行う。この機器内アドレス帳とは、UCS37を介して得られるユーザーのアドレスに関する情報である。NTサーバI/Oスレッド135は、上述したWindows(登録商標)認証を行うサーバと通信を行うスレッドである。LDAPサーバI/Oスレッド136は、上述したLDAP認証を行うサーバと通信を行うスレッドである。
外部課金I/Oスレッド132は、外部課金装置キーカードコインラックと通信を行う。この外部課金装置キーカードコインラックとは、キーカードを用いて使用する場合や、コインラックを用いて使用する場合のデバイスである。MFキーカードI/Oスレッド131は、MFキーカード課金装置と通信を行う。このMFキーカードとは、上記キーカードにさらに種々の機能を持たせたものである。キーカウンターI/Oスレッド133は、キーカウンター142と通信を行う。
以上がCCS39のスレッド構成である。次に、各CCMが指示されたスレッドとして動作する様子を、図4を用いて説明する。
図4は、CCMがCCS39から指示された動作をするために、各種パラメータを取得し、指示された動作をするための最終的な形態までを示す図である。この図4には、CCMの生成段階160と、認証課金装置データテーブル150と、CCM制御パラメータ151と、課金管理161と、認証管理162と、画面制御163とが示されている。
生成段階160では、指示されたCCMとして動作するための認証方法が選択される。その後、CCMは、認証課金装置データテーブル150からパラメータを取得する。認証課金装置データテーブル150は、ユーザーコードパラメータと、キーカードパラメータと、キーカウンターパラメータと、MFキーカードパラメータと、コインラックパラメータで構成される。これらのパラメータは、上述した各認証課金装置に関する情報である。
次に、CCMは、CCM制御パラメータ151から共通パラメータを取得する。共通パラメータには、認証パラメータと、課金パラメータと、制限画面固定部パラメータと使用するI/Oで構成される。
各パラメータに対応して、課金管理161と、認証管理162と、画面制御163が生成される。課金管理161は、課金の管理ならびに実行を行う。認証管理162は、認証情報を受信と認証の通知を行う。また、認証管理162は、画面制御163からの認証問い合わせに対応する。画面制御163は、オペレーションパネルからのキーイベントを受け付け、そのキーイベントに対応した画面描画処理やキーイベントの発行を行い、キーイベントにより、情報が確定すると、認証管理162へ問い合わせを行う。
次に、図5を用いて基本的な認証シーケンスについて説明する。図5は、アプリ100と、CCS39と、認証課金装置140と、ECS34と、SRM40との間で行われる処理を示すシーケンス図である。
ステップS1で、アプリ100は、CCS39に利用登録を行う。この利用登録とは、アプリ100がCCSを利用するための登録であり、通常はアプリの起動時に行われる。この通知は、あるアプリが実行する機能に必要な認証や課金に関する情報を要求するためのものである。例えば、コピーアプリが、ドキュメントボックスモジュールを用いた処理を実行するために、コピーとドキュメントボックスに関する認証課金設定情報が欲しい、などが通知される。
ステップS1で利用登録を通知されたCCS39は、もし、認証課金装置が接続されていないなど、認証課金装置が使えない場合、ステップS2に示されるように、認証NGをアプリ100に通知する。また、認証課金装置が使用可能となっていた場合は認証OKをアプリ100に通知する。
CCS39は、ステップS3でアプリ100に認証要/不要情報を通知する。この通知は、ある機能を実行する際に、どのような認証が必要となっているかを通知するものである。例えば、コピーのモノクロ機能に対しては、認証方法1による制限がかかっている、などが通知される。この認証方法1などの認証方法は、後に説明する。
次のステップS4で、CCS39は、アプリ100に課金要/不要情報を通知する。この通知は、ある機能を実行する際に、どのような課金処理が必要となっているかを通知するものである。例えば、コピーのモノクロ印刷を実行する場合に、認証方法1で課金を実行する必要がある、などが通知される。
これらの情報に基づき、アプリ100は、ステップS5で、CCS39に対し、認証画面の表示を要求し、CCS39は、画面を表示する。このステップSS5の通知は、アプリ100が、ある機能を実行したいと思ったが、その機能の実行に必要な認証状態が認証OKとなっていない場合に、その旨を操作パネルに表示してユーザーに認証取得指示を促すために行われる。
例えば、この要求は、コピーアプリがモノクロ印刷を実行したいが、認証方法1の認証状態がOKとなっていないので、認証方法1に対応した利用制限画面の表示をCCS39に要求する、などのためのものである。
ここで、認証課金装置140から、CCS39に対し、ステップS6で、装置の状態が通知される。そして、CCS39は、ステップS7で、アプリ100に対し認証OKを通知する。
認証OKを通知されたアプリ100は、ステップS8で、CCS39に対し、認証画面の消去を要求し、CCS39は、画面を消去する。
アプリ100では、ジョブの実行が開始され、各種エンジンを動作させるため、ステップS9で、ECS34にジョブが渡される。このとき、ステップS4で、課金が必要であることが通知されている場合、ジョブの情報として、後述する課金情報も通知される。このジョブとは無関係の課金は、例外的にCCS39に直接課金を指示する場合もある。
ECS34は、ステップS10で、プロセスを通知し、SRM40は、課金が必要な場合、ステップS11で、CCS39に課金の指示を行う。CCS39は、ステップS12で、認証課金装置140に課金指示を通知する。
以上が基本的な認証シーケンスである。詳細なシーケンスについては後に説明する。次に、上述した課金情報について説明する。課金情報には、認証方法の番号、エンジンを制御するためのパラメータ、課金装置の接続状態をチェックするかどうか、加算カウントか減算カウントかどうか、キーカウンターでカウントするかキーカードでカウントするかどうか、そしてユーザーID情報が含まれる。
次に、上述したシーケンス図におけるデータ内容の詳細を記した図6を用いてアプリ100、CCS39、SCS/SRM141の間のやり取りについて説明する。まず、SCS/SRM141は、ステップS101で、認証設定通知要求をCCS39に通知する。次に、CCS39は、属性情報通知段階に対応するステップS102で、アプリ100に認証設定通知を通知する。その後、CCS39は、ステップS103で、SCS/SRM141に認証設定通知完了応答を通知する。
なお、「デバイス1+属性情報」のように、デバイスと属性情報の組が、認証方法に対応するとともに、図5のステップS3の認証要不要の通知で通知される内容である。また、「デバイス1+カウント先情報」のようにデバイスとカウント先情報の組が、図5のステップS4の課金要不要情報の通知で通知される内容である。また、属性情報は、後に説明する認証方法詳細通知で通知される内容である。
認証設定通知を通知されたアプリ100は、認証画面判断段階に対応するステップS104で、属性情報による判断を行う。また、ステップS105で、アプリ100は、認証状態により、ステップS106の認証画面表示要求をCCS39に通知する。CCS39は、ステップS107で、認証画面表示通知をSCS/SRM141に通知する。SCS/SRM141は、描画指示を行い、ステップS108で、CCS39に認証画面準備要求を通知する。CCS39は、画面属性の変更を行い、ステップS109で認証画面準備完了応答をSCS/SRM141に通知し、SCS/SRM141は、認証画面表示段階に対応する画面描画を行う。
また、SCS/SRM141からCCS39へ、ステップS110で、外部課金状態通知が通知される。外部課金状態通知を通知されたCCS39は、外部課金状態を認証状態としてステップS111でアプリ100に通知する。
なお、図中に示される「デバイス1」、「デバイス2」などは、認証方法を区別するために便宜的に用いているIDで認証課金装置の具体的な種類を示すものではない。認証課金装置の具体的な種類は抽象化され、抽象化された種類は、図中の属性情報で示される。
認証方法を表している。
次に、上述した構成で行われる認証の一例を、図7〜9に示された表を用いて説明する。これらの表は、認証の種類を表す認証方法と、それに対応する備考が示された表である。
図7に示される認証は、単独で行われる認証の例を示すものであり、40種類の認証方法が示されている。また、図8、9に示される認証は、図8に示される認証と図9に示される認証とを組み合わせて行われる組合せ認証の例を示すものであり、この場合、図8には23種類、図9には9種類の認証方法があるので、認証の総数は207種類となる。
次に、図6で説明した各アプリへの認証設定通知について説明する。上述したように、CCSは、各アプリに対して、SP/UP設定をもとに、どの機能を行うのにどの認証方法が必要なのかを示す認証設定を通知する。ここで、SP/UP設定とは、MFPの保守や点検などを行うサービス担当者や、ユーザーの側で設定された設定内容を示す。この設定内容は、例えば、モノクロコピー印刷にはキーカウンター認証が必要、カラーコピー印刷にはキーカウンター認証とユーザーコード認証が必要などという内容である。
ここで通知される認証設定は、認証を必要とする機能に関する情報のみが通知される。機能の制限は、認証以外にユーザーログインにともなう機能制限などもあるが、直接認証に絡まない制限情報は、認証設定として通知せず、機能制限として別途通知する。なお、機能制限とは、認証状態としてはOKであるが、ユーザー個別の事情による機能の制限である。
このようなSP/UP設定に基づき、CCSは登録してきたアプリに対して機能毎の認証設定を通知する。この認証設定の例を、図10を用いて説明する。図10には、認証が必要な機能と、その機能に対応した認証方法が示されている。例えばフルカラー印刷は、認証方法1または認証方法2で認証を行うことで、実行することが可能となる。なお、「認証方法1または認証方法2」とは、認証方法1または認証方法2のいずれか1つの認証方法を選択して認証することを示しており、この選択はアプリが行う。
アプリに認証装置の種類を意識させないために、ユーザーコードやキーカウンターなどというような直接的な認証方法の名称は提示されず、上記のように「認証方法1」、「認証方法2」といった抽象的な名称が提示される。なお、SP/UPが変更された場合は、認証設定を変更して登録しているアプリに通知される。また、UPで設定される値は、具体的に、個人認証の方法(ローカル/Windows(登録商標)/LDAP/ユーザーコード/認証しない)、ユーザーコード認証(する/しない)、キーカウンター認証(する/しない)、外部課金装置認証(する/しない)がある。SPで設定される値には、具体的には、外部課金装置の種類(加算式キーカード/MFキーカード)などがある。
図11は、CCS、アプリ、認証装置間での認証設定の様子を示す図である。CCS39は、各アプリ170から登録されると、上述したSP/UP設定値171に基づき認証設定を各アプリ170に対して通知する。
また、認証装置C172からはユーザーログインにともなう機能制限や、認証装置D173からは、IDカード挿入に伴う機能制限などがCCS39に通知される。
図12は、CCS、アプリ、認証装置間での認証設定における関係図である。図12には、図11と同様に、各アプリ170と、CCS39と、各認証装置114とが示されている。
CCS39は、図12に示されるように、各認証装置114から通知された認証状態を各アプリ170に通知する。また、CCS39は、各認証装置から認証に必要な情報を受信認証状態として記憶しておく。機能の実行に認証装置の認証が必要なアプリに対して、認証OK/NG情報を通知する。なお、機能の実行にどの認証が必要かは、上述したようにSP/UP設定情報を元に判定する。
次に、認証画面について説明する。CCSは、MFPの利用制限状態に応じた認証画面を生成する。この生成した画面の表示はアプリの指示により行われる。この認証画面には、キーカードの挿入要求など課金方法の認証要求画面や、ユーザーログイン画面などがある。
このように、認証画面を生成するCCSであるが、CCSで、アプリの振舞いや制限されている機能の種類を直接意識した画面を持つ事はしない。これは、直接意識した画面を持つことになると、アプリが追加されたり、機能の制限が新しく増える度に対応する画面を持つ事になるため、CCSの拡張性が著しく下がるためである。
以下、CCSが生成する認証画面を、図面を用いて説明する。図13は、フルカラーのコピーを、コインラック、キーカウンター、ユーザーコードのいずれか1つで認証を行うための画面を示す。
図13の画面には、定型文表示欄180と、機能表示欄181と、認証ボタン112と、解除ボタン183とが示されている。
このように、定型文表示欄180と機能表示欄181とを別々に設けることにより、それぞれ欄に表示する文字列を独立して指定することができる。また、定型文表示欄180と機能表示欄181のそれぞれに表示される文字列は、一方を変更すると他方に影響を与えるような関連性がないため、各表示欄に表示する文字列の差し替えも容易となる。
定型文表示欄180について説明する。図13に示されるように、定型文表示欄180に表示される文章は、「下記の機能を使用する場合は、いずれかの制限を解除してください」である。このように、「下記の機能」を用いることにより、機能に依存しない表示を行うことが可能となる。
次に、機能表示欄181について説明する。機能表示欄181は、アプリから指定された機能名称に対応した文字列(上記の例ではフルカラー)を表示する欄である。このように、CCSは、アプリから指示された文字列を表示する欄を用意しておき、その欄に指示された文字列を表示するようになっている。
次に、認証ボタン112について説明する。認証ボタン112は、機能に対応した認証ボタンが表示される。図13の場合、3つの認証ボタンが表示されている。1つの認証で良いときは、認証ボタンが1つ表示される。
解除ボタン183は、表示されている画面を消すためのボタンである。この解除ボタン183が押された時の動作仕様は、そのボタンの表示を指示した各アプリの判断にまかせられる。そのため、アプリからは制限画面の表示要求時に、「ボタンの有無」、「ボタンに表示させる文字列」、「ボタン押下時にアプリに通知するイベント種類」を指定してもらう。
その他、機能の制限にともなった認証画面を表示するかどうかは、アプリの判断にまかせる。この場合、例えばその機能の選択キーを半輝度にしたり、表示自体やめてしまうという仕様も考えられるが、この仕様に関してCCSは指示を行わない。
また、認証画面上のボタン押下時の効果、例えば、両面機能に認証にともなう制限がかかっていた場合、「認証画面のボタン押下によって片面モードに切り換える」、「設定の変更は行わず元の画面に戻る」、「ジョブリセットする」などはアプリの判断にまかせる。この時、キーイベントをアプリに飛ばす事になるので、あらかじめキーイベント番号をアプリに指示してもらう。
以上が画面の基本的な内容である。以下、各種認証画面を説明する。図14に示される画面は、認証装置がコインラックの場合の画面である。コインラックの場合、画面には、定型文表示欄180と、機能表示欄181と、ジョブリセットボタン187とが表示される。ジョブリセットボタン187は、ジョブをリセットする場合のボタンである。
図15に示される画面は、認証をユーザーコードで行う場合の画面である。ユーザーコードの場合、画面には、定型文表示欄180と、機能表示欄181と、ユーザーコード入力欄184と、クリアボタン185と、#ボタン186と、解除ボタン183とが表示される。ユーザーコード入力欄184は、ユーザーがユーザーコードを入力する欄である。クリアボタン185は、ユーザーコードを誤入力したときなど、ユーザーコードを消去する場合のボタンである。#ボタン186は、「#」を入力するためのボタンである。
図16に示される画面は、認証装置がキーカードを用いる場合の画面である。キーカードの場合、画面には、定型文表示欄180と、機能表示欄181と、解除ボタン183とが表示される。
図17に示される画面は、ログオン画面である。ログオン画面には、定型文表示欄180と、ユーザー名入力欄188と、パスワード入力欄189と、キャンセルボタン190と、ログオンボタン191とが表示される。
ユーザー名入力欄188は、ユーザー名を入力し、その後、入力ボタンを押下することで、ユーザー名を入力するようになっている。パスワード入力欄189は、パスワードを入力し、その後、入力ボタンを押下することで、パスワードを入力するようになっている。ユーザー名とパスワードを入力すると、ログオンボタン191でログオンする。ログオンしない場合は、キャンセルボタン190でこの画面を消去することができる。
上述した画面が認証画面の一例である。このように、認証画面は、制限がかかっている機能名が、別途指定できるようになっており、新しい認証方法の組み合わせが発生した時も、機能名称を差し替えるだけの画面となっている。
なお、組合せ認証の場合、上記画面を連続して表示するようにする。例えば、最初の認証がユーザーコードであり、次の認証がコインラックまたはキーカウンターの場合、まず、図15で示したユーザーコードでの認証画面を表示し、認証がOKであれば、次に、図18に示される認証画面を表示するようにする。図18に示される認証画面は、図12で示した複数の認証装置のうち、いずれか1つの認証を行うための画面である。
以上説明したように、CCSはアプリの指示により画面を生成するが、アプリは既に認証が終えている場合は、認証画面の生成を要求しない。例えば、機能と認証の関係が、図10に示した関係であるとし、認証状態が、図19に示される状態であるとする。
図19に示される表は、各種認証の認証状態を示すもので、その認証方法で認証されているかどうかを示す表であり、この表に示される情報は、CCSが保持するとともに、アプリに通知される。
アプリは、この表に基づき、画面表示を行うかどうかを判断する。今の場合、図19により、認証方法1と4が認証されているため、図10に示される白黒印刷以外の機能の実行は、認証が不要である。図20は、機能と、その機能の実行に必要な認証状態を示すものであり、上述した内容が示されている。この図20に示される表に基づき、アプリはCCSに画面の生成の指示を行うかどうか決定する。
次に、利用可能機能について説明する。CCSが通知する認証設定とは、原則として認証が不足している事を通知ための設定である。ところが、アクセスロールなどでは、認証状態はOKとなっているが、ユーザー個々の機能制限属性によりMFPの利用に制限がかかる場合がある。
この制限された機能の実行に際し、本実施の形態におけるMFPは、認証結果が判明した際に、機能に制限がかかっている事を表示するだけで新しい認証を求めないシステムであるため、認証結果を受け取った各アプリが画面を表示するという仕様となっている。
そのため、CCSでは、認証結果(認証OK/NG)を通知する際に「利用可能機能」も合わせて通知する。以下、具体例をあげて説明する。
まず、図21を用いてシステム設定について説明する。システム設定とは、MFPにおける認証の基本的な設定である。図21に示されるシステム設定の表は、個人認証設定はローカルアドレス帳で認証することを示し、フルカラーはキーカードで認証することを示し、白黒はキーカードまたはキーカウンターで認証することを示し、2色並びに単色は設定されていないことを示している。
このような場合の認証設定を示すのが、図22である。図22には、機能または操作と、それらに対応する認証方法が示されている。例えば、図22では、フルカラーの認証方法は、認証方法1であり、パネル使用ジョブ操作の認証方法は、認証方法3であることが示されている。
このように、アプリに対しては、認証方法を具体的な認証方法ではなく、番号で通知するようになっているため、CCSは、具体的な認証方法の詳細を管理している。図23は、CCSが管理している具体的な認証方法の詳細を示す図である。
この図は、認証方法と、その認証方法に対応する認証内容と、認証画面に表示する文字列が示されている。図に示されるように、例えば、認証方法2の認証内容は、キーカウンターであり、認証画面に表示する文字列は、「キーカウンターをセットしてください」であることが示されている。他の認証方法も同様となっている。
次に、個人が特定される認証について説明する。個人が特定される認証では、認証を取得したユーザーが使用できる機能が制限されている場合がある。図24は、ログオンしたユーザーの設定内容が示されている。この設定内容は、ユーザー属性と、カラーなどの機能と、コピーアプリの実行許可の項目に対するユーザーの設定が示されているものである。
図24の場合、ユーザー属性は一般であり、カラーと2色が不可であり、白黒と単色が可能であり、コピーアプリ実行許可が可であることが示されている。
このように、ユーザーがログオンした場合、CCSは、認証方法がログオンである認証方法3の認証状態をOKとし、ログオンしたユーザーの利用可能機能を認証設定通知とは別に通知する。
図25は、このとき通知される内容を示すものである。図25に示される利用可能機能は、図24で説明したユーザーの設定に基づくものであり、例えば、フルカラーが不可、コピーアプリ機能は、可というようになっている。
この利用可能機能と、認証設定と認証状態に基づき、アプリはどの機能が実行可能かを判断する。その判定結果を示したのが、図26である。この図26には、単色とコピーアプリ機能が実行可能となっている。この判定は、認証NGまたは利用不可であれば実行不可能となるものである。従って、例えば白黒は、利用可であっても、認証方法1または認証方法2の認証にOKが出ていないため、実行不可能となっている。
実行不可能となっているものをユーザーが実行しようとした場合、実行に際し、以下のルールで画面表示を行う。
まず、新たに認証を要求する場合は、CCSに対して認証画面の表示要求を通知する。また、認証以外の理由により機能利用制限がかかっている場合は、アプリ自らが機能が制限されている事を表示する。この表示として、例えばボタンを半輝度にするなり、メッセージを表示することがあるが、表示の仕方はアプリが決定する。
機能利用制限は、認証方法がOKとなったときのパラメータとして発行される。複数の認証方法で異なる機能利用制限が発行された場合は、アプリは各機能利用制限のAND条件で機能が利用できるかどうかを判断する。AND条件のため、一つでも利用制限が不可となっていた場合は、その機能は利用できないものとする。
次に、各アプリへの課金方法の通知について説明する。CCSは、各アプリに対して、SP/UP設定に基づき、ある機能を実行するのにどの課金方法の設定が必要なのか(課金設定)を通知する。例えば、モノクロコピー印刷にはキーカウンターへの課金が必要、カラーコピー印刷にはキーカウンター+ユーザーコードへの課金が必要、などである。
この課金設定の通知は、上述したように、まずシステム起動時、アプリがCCSに登録を行い、CCSがSP/UP設定値に基づき、登録してきたアプリに対してモード毎の課金方法設定を通知するようになっている。
この通知される課金設定の例を、図27を用いて説明する。図27に示される表は、課金が必要な機能と、その課金方法を示すものである。図27において、例えば、フルカラー印刷の場合、課金方法は、認証方法1または認証方法2となっている。なお、図27の例では、課金方法が認証方法となっているが、これは、今の場合、課金方法に指定する認証方法は、認証設定で通知されている方法の一部となっていることと、課金を行うためには、必ず当該課金装置の認証が完了している必要があるため、自動的に実行には認証が必要となるためである。課金方法と認証方法が異なる場合は、例えば課金方法1など、他の名称が用いられる。
このように、アプリに課金装置の種類を意識させないために、ユーザーコードとかキーカウンターというような直接的な認証方法の名称は提示せず、認証方法1、認証方法2といった抽象的な名称で指示する。
なお、一つの機能に複数の認証方法を割り当てる事も可能である。この場合、アプリは先に認証された方法を課金方法として使用する。ただし、アプリによっては、認証デバイス毎に使用優先度が決まっているものがあるため、そういうアプリには、認証装置の種類を抽象化しているCCSが優先度を決定してアプリに通知する。
また、CCSは、SP/UPが変更された場合は、新しいSP/UP設定に対応した課金設定を、登録されているアプリに通知する。
以上説明した登録、課金設定の様子を示したのが図28である。CCSは、各アプリ170から登録されると、上述したSP/UP設定値171に基づき課金設定を各アプリ170に対して通知する。
次に、課金装置へのカウント実行処理について、図29を用いて説明する。ステップS201で、CCS39が、アプリ100に対してモード別の課金方法を指示する。ステップS202で、アプリ100がECS34に対して課金方法を決定してジョブを渡す。
課金方法として複数の認証方法が使用できる場合、アプリ100またはECS34は先に認証が完了した方法で課金を行うよう指示する。ステップS203で、ECS34は、SCS/SRM141に、プロセスを渡す。このプロセスのプロセス情報にカウント指示要求が付加されている。ステップS204で、SCS/SRM141はCCS39にプロセスを渡す。プロセス情報に付加されている課金方法にて、CCSが適宜タイミングを見計らって、ステップS205でカウント処理を行う
このような課金設定がアプリに通知されている状態で、認証方法1への課金処理が設定されていた場合、CCSは図30に示される認証方法関連付けテーブルを内部で保持しているため、認証方法1への課金処理を行う。
図30に示される認証方法関連付けテーブルは、課金方法種類と実体とを対応付けるものである。この認証方法関連付けテーブルによって、ある認証方法に対応する認証方法実体は、認証方法関連付けテーブルで認証方法に対応しているポインタが指すアドレスを参照することにより得られる。
ここで、CCS内部のデータとそれらの管理について説明する。図31は、利用登録リストである。この利用登録リストは、要求元と、クライアントIDと、必要アプリ情報からなる利用登録情報のリストとなっており、登録元に関する情報を保持するためのものである。
利用登録情報において、要求元は、登録を要求した要求元である。クライアントIDは、要求元に割り当てられたIDである。必要アプリ情報は、要求元が必要とするアプリである。
この利用登録情報は、アプリが登録した際に作成される情報である。図31では、要求元がコピー、プリンタ、スキャナの例が示されている。
次に、図32を用いて認証課金設定リストについて説明する。この認証課金設定リストは、機能名と方法名からなる認証課金設定情報のリストであり、機能名と、その機能に必要な認証方法を対応させるものである。また、認証課金設定リストは、初期設定とSP設定に基づき作成され、電源投入時または設定内容の変更時に更新される。
図32には、例としてコピー用とプリンタ用の認証課金設定リストが示されている。例えば、コピー用の認証課金設定情報の方法名に示されるように、方法名が複数指定できるようになっている。また、認証課金設定リストは、図31の利用登録リストの要求元と、関連付けられている。
次に、図33を用いて方法テーブルについて説明する。この方法テーブルは、方法名と、実デバイス1と、実デバイス2からなるテーブルであり、認証方法と実体とを対応付けるものである。例えば、認証方法2は、実デバイス1がキーカウンターで、実デバイス2がユーザーコードであることが示されている。この方法テーブルも、初期設定とSP設定に基づき作成され、電源投入時または設定内容の変更時に更新される。また、方法テーブルは、図32の方法名と、関連付けられている。
次に、図34を用いて実デバイス管理リストについて説明する。この実デバイス管理リストは、実デバイス名と、CCM名と、認証タイプ情報と、状態からなる実デバイス管理情報のリストであり、実デバイスに関連する情報を示すものである。実デバイス管理リストの状態は、キーカウンターに示されるように、複数の状態を持つことができる。
この実デバイス管理リストは、初期設定とSP設定に基づき作成され、電源投入時、設定内容の変更時、CCMからの状態通知などにより更新される。また、実デバイス管理情報は、図33の実デバイス1,2と、関連付けられている。
以上説明したデータのうち、認証方法関連付けテーブルと方法テーブルを除く他のリストは、必要に応じて作成されるデータであるので、作成するごとにメモリを確保するほうがリソースを無駄にしない。その場合のデータの管理方法は、確保した各メモリをチェーンでつなぐなどの方法がある。
次に、シーケンス図について説明する。まず、図35を用いて、CCSがサービス登録を行なって、認証画面を表示するまでの処理を説明する。
ステップS301で、CCS39が起動するとSCS/SRM141へサービス登録を行なう。登録後、ステップS303で、CCS39は、システム設定通知を通知される。このとき、OCS32がレディ状態であれば、OCS32は、ステップS302で、SCS/SRM141へOCSレディを通知する。CCS39は、ステップS304で、SCS/SRM141からOCSレディを通知される。
このOCSレディには、システム画面を作成する為のルートハンドルがセットされている。CCS39はこれを通知されると、認証画面で利用するウィンドウとアイテムの作成を行なう。ほとんどのウィンドウやアイテムは、このタイミングで作成される。
アプリ100が起動すると、ステップS305でSCS/SRM141に対してアプリ登録を行ない、SCS/SRM141は、ステップS306でシステム設定通知をアプリ100に通知する。
アプリ100は、ステップS307で、CCS39に対しても利用登録を行なう。CCS39は、ステップS308で、登録を行なったアプリ100に対して認証設定通知を通知する。
キーカード200は、ステップS309で、課金可能状態通知をSCS/SRM141に通知する。SCS/SRM141は、通知された課金可能状態通知をステップS310で、外部課金状態としてCCS39に通知する。CCS39は、ステップS311で、認証状態通知をアプリ100に通知する。
認証設定と認証状態を通知されたアプリは、キーカード200の認証状態で制限するべき機能を判断し、ステップS312で、CCS39に認証画面表示要求を通知する。
認証画面表示要求を通知されたCCS39は、詳細な制限情報を保持し、ステップS313で、SCS/SRM141へは要求のあったアプリと表示ON/OFFの表示に関する表示情報を通知する。この表示情報は、アプリの数だけSCS/SRM141が保持する。CCS39では、詳細な制限情報を保持する。
ステップS314で、OCSレディを受けたアプリ100はアプリ画面の作成を行ない、ステップS315で、初期画面レディをSCS/SRM141に通知する。SCS/SRM141は、ステップS316で、アプリ100に操作部オーナー移行要求を通知する。アプリ100は、ステップS317で、操作部オーナー移行応答をSCS/SRM141に通知する。
SCS/SRM141は、操作部オーナー移行応答が完了する直後に、SCS/SRM141が保持しているアプリの表示情報を用いて、ステップS318でCCS39へ画面準備を要求する。CCS39は、この要求で認証画面に表示するウィンドウを選択し、表示するべきアイテムを選択して、ウィンドウやアイテムハンドルの表示属性をOPENやCLOSEに変更する。
CCS39は描画処理(PAINT)を行なわず、ステップS319で、表示したいウィンドウハンドルをセットした画面準備完了をSCS/SRM141に通知する。ウィンドウハンドルがセットされていれば、SCS/SRM141では描画処理(PAINT)を行なう。ウィンドウハンドルがセットされていなければ、何も行なわない。今の場合、ウィンドウハンドルがセットされていることを想定しているので、SCS側で描画処理が行なわれる。
次に、加算式の外部課金装置を使った場合の認証基本動作について、図36を用いて説明する。加算式とは、使用に応じて金額を加算する方式であり、その外部課金装置の例として、キーカードが挙げられる。
ステップS401で外部課金装置201は、CCS39へ状態通知を通知する。アプリ100は、ステップS402で、CCS39に利用登録を行う。このとき、認証に利用する設定情報を指定してCCS39へ登録する。
CCS39は、ステップS403でアプリ100に認証方法詳細通知を通知する。この通知は、使用される可能性のある認証方法の数だけ行われる。この認証方法詳細通知で通知される内容は、後述する。アプリ100は、通知された認証方法詳細通知の内容をもとに、個々の認証方法がどんな制御を行うべきものかを記憶する。
次に、CCS39は、ステップS404でアプリ100に認証設定通知を通知する。この通知も、認証が必要な機能の数だけ通知される。
CCS39は、外部課金装置201から通知された状態通知から、ステップS405で、アプリ100に認証状態通知を通知する。このとき通知されるのは、まだ外部課金装置201にキーカードが挿入されていないため、キーカードNGという内容である。なお、ここでキーカードNGと記しているが、実際にはキーカードと名称を用いず、認証方法Xという名称が用いられる。また、条件識別IDとは、認証方法で条件を設定するために、条件に割り当てるIDであり、条件内容で定まるものではない。条件を設定する認証方法ではない場合、条件識別IDは、無効を示す0x0000となる。
アプリ100は、CCS39にステップS406で認証画面表示要求を通知する。この通知は、アプリ100が認証設定通知と認証状態通知から認証方法を決定する。そして、その認証方法の状態が、今の場合NGのため、アプリ100は、CCS39に認証画面の表示を通知する。
CCS39は、認証画面を表示する。その後、CCS39は、ステップS407で外部課金装置201からキーカードが挿入されたことが状態通知として通知される。これにより、CCS39は、ステップS408で、アプリ100に対し、キーカードが挿入された内容の認証状態通知を通知する。
アプリ100は、ステップS409で、先ほど表示した認証画面の表示を終了させるため、CCS39に認証画面表示要求を通知する。CCS39は、認証画面を非表示とする。
キーカードが抜けると、外部課金装置201は、ステップS410で、キーカードが抜けたことを状態通知としてCCS39に通知する。CCS39は、ステップS411でアプリ100にキーカードが抜けたことにより認証NGとなったことを認証状態通知で通知する。アプリ100は、ステップS412で、CCS39に再び認証画面を表示させるため、認証画面表示要求を通知し、CCS39は、認証画面を再び表示させる。
上述した認証方法詳細通知の通知内容について説明する。認証方法詳細通知で通知されるパラメータは、7種類ある。1つめは、認証NG発生時に、実行中のモードをリセットするかどうかを示すパラメータである。2つめは、認証NG発生時に、読み取り動作、FAX印刷動作、FAX送信処理を停止するかどうかを示すパラメータである。3つめは、カラーモード別、用紙サイズ別、ユーザー別に認証が取得できるかどうかを示すパラメータである。
4つめは、ユーザーが認証画面上にて、3つめの条件を指示する事ができるかどうかを示すパラメータである。5つめは、一度取得した認証を、他の動作にも使用できるかどうかを示すパラメータである。例えば、ユーザーコードは一度ユーザーを特定すれば、ユーザーコードがクリアされるまでは、次動作のジョブにも使用できる。
6つめは、取得した認証を破棄するタイミングを示すパラメータである。このタイミングとして、例えば省エネ移行時、初期設定に入った時、機能を実行開始した後などがある。7つめは、読み取りと印刷の動作が並行処理可能な認証方法かどうかを示すパラメータである。これは、コインラックなど、コピー実行時に印刷できない状況が発生した場合、読み取りだけ先行する事はできず、必ず読み取りと印刷とが同期して処理される課金装置に対応するためである。
次に、減算式の外部課金装置を使った場合の認証基本動作について、図37を用いて説明する。減算式とは、所定金額から使用に応じて金額を減算する方式であり、その外部課金装置の例として、コインラックが挙げられる。この場合、加算式とは異なり、減算可能かどうかの判断が必要となるなど、処理が増えることになる。
ステップS501で外部課金装置201は、CCS39へ状態通知を通知する。アプリ100は、ステップS502で、CCS39に利用登録を行う。このとき、認証に利用する設定情報を指定してCCS39へ登録する。
CCS39は、ステップS503でアプリ100に認証方法詳細通知を通知する。この通知は、使用される可能性のある認証方法の数だけ行われる。アプリ100は、通知された認証方法詳細通知の内容をもとに、個々の認証方法がどんな制御を行うべきものかを記憶する。
次に、CCS39は、ステップS405でアプリ100に認証設定通知を通知する。この通知も、認証が必要な機能の数だけ通知される。
CCS39は、外部課金装置201から通知された状態通知から、ステップS505で、アプリ100に認証状態通知を通知する。このとき通知されるのは、まだ外部課金装置201にキーカードが挿入されていないため、キーカードNGという内容である。なお、ここでキーカードNGと記しているが、実際にはキーカードと名称を用いないのは先ほどと同様である。
次に、アプリ100は、ステップS506で、認証条件設定をCCS39に通知する。このときの認証条件は、白黒のA4という条件で、その条件識別IDは、0x0001である。これは、減算式の外部課金装置は、上記認証条件の設定が必要なため通知されるものである。CCS39は、通知された認証条件を記憶する。そして、ステップS507で、外部課金装置201に状態問合せを通知し、ステップS508で、外部課金装置201から状態通知が通知される。通知された外部課金装置201の状態を、CCS39は、ステップS509でアプリ100に通知する。
通知を受けたアプリ100は、ステップS510で、CCS39に認証画面表示要求を通知する。通知を受けたCCS39は、認証画面を表示し、ステップS511で、アプリ100にキーカードOKを意味する認証状態通知を通知する。このとき、条件識別IDは、0x0000である。
キーカードが挿入されることにより、ステップS512で、外部課金装置201からCCS39へ状態通知が通知され、CCS39は、ステップS513で、アプリ100に認証状態通知を通知する。このとき、条件識別IDは、0x0001である。これにより、条件が満たされるので、アプリ100は、ステップS514で、CCS39に認証画面表示要求を通知する。通知を受けたCCS39は、認証画面を非表示とする。
次に、条件が変更され、白黒からフルカラーとなったとする。このとき、アプリ100は、ステップS515で、フルカラーでA4という条件を設定するため、CCS39に認証条件設定を通知する。このときの条件識別IDは、先ほどと同じく0x0001である。ここで、例えば0x0002という異なるIDを用いた場合、白黒A4に割り当てた0x0001の条件が満たされた場合も通知されることになる。
認証条件設定を通知されたCCS39は、認証条件を記憶し、ステップS516で外部課金装置201に状態問合せを通知する。外部課金装置201は、ステップS517で、状態をCCS39に通知する。そして、CCS39は、外部課金装置201から通知された状態に基づき、ステップS518で、アプリ100に認証状態通知を通知する。今の場合、キーカードNGという内容が通知される。
そこで、アプリ100は、ステップS519で、CCS39に認証画面表示要求を通知する。通知を受けたCCS39は、認証画面を表示する。ここで、キーカードが抜かれたため、外部課金装置201はステップS520で、状態通知をCCS39に通知する。CCS39は、ステップS521で、キーカードがNGとなったことを、アプリ100に認証状態通知として通知する。そこで、アプリ100は再びCCS39に認証画面表示要求をCCS39に通知し、CCS39は認証画面を表示する。
次に、リモート操作における認証の基本動作について、図38を用いて説明する。リモート操作とは、例えば、ネットワーク越しにPCからの操作などである。
キーカードが挿入された外部課金装置201は、ステップS601で、CCS39に状態を通知する。CCS39は、ステップS602で、アプリ100に認証状態通知を通知する。動作モードが白黒A4と決定されると、アプリ100は、ステップS603で、認証条件設定とCCS39に通知する。このときの認証条件は、白黒A4である。これに対し、CCS39は、ステップS604で、認証OKを示す認証状態通知をアプリ100に通知する。
OKを通知されたアプリ100は、ジョブをスタートする。ここで、動作モードがフルカラーA4に決定されると、アプリ100は、ステップS605で、CCS39に認証条件設定を通知する。このときの認証条件は、フルカラーA4であり、条件識別IDは、0x0002である。これに対し、CCS39は、ステップS606で、認証OKを示す認証状態通知をアプリ100に通知する。
OKを通知されたアプリ100は、ジョブをスタートする。そこで、キーカードが抜かれると、外部課金装置201は、ステップS607で、CCS39に状態通知を通知する。CCS39は、ステップS608で、認証NGを示す認証状態通知をアプリ100に通知する。このときの条件識別IDは、0x0000である。また、CCS39は、ステップS609で、認証NGを示す認証状態通知をアプリ100に通知する。このときの条件識別IDは、0x0001である。さらにCCS39は、ステップS610で、認証NGを示す認証状態通知をアプリ100に通知する。このときの条件識別IDは、0x0002である。
このように、条件識別IDの分だけ認証状態が通知される。これらの通知を受けて、アプリ100は、ステップS611で、認証条件IDを破棄する通知である認証条件破棄をCCS39に通知する。このとき破棄される認証条件IDは、0x0002である。これに対し、CCS39は、ステップS612で、アプリ100に認証条件破棄確定結果を通知する。このとき、破棄されたことを示す破棄OKが通知される。
そこで再びキーカードが挿入されると、外部課金装置201は、ステップS613で、CCS39に状態通知を通知する。CCS39は、ステップS614で、認証OKを示す認証状態通知をアプリ100に通知する。このときの条件識別IDは、0x0000である。また、CCS39は、ステップS616で認証OKを示す認証状態通知をアプリ100に通知する。このときの条件識別IDは、0x0001である。