JP4861631B2 - 利用者認証装置、画像形成装置、利用者認証方法及び利用者認証プログラム - Google Patents

Description

本発明は、利用者認証装置、画像形成装置、利用者認証方法及び利用者認証プログラムに関するものであり、特に、認証が行われた利用者に対して機能の実行を許可する技術に関するものである。

従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、ＵＮＩＸ（Ｒ）などの汎用ＯＳ上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。

ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、それぞれエンジン制御、メモリ制御およびシステム制御などを別個におこなっているので、重複処理という無駄が生じていた。

このため、特許文献１では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分（プラットホーム）として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。

また、特許文献２では、印刷装置に搭載される印刷制御ソフトウェアを、オブジェクト指向設計による複数のソフトウェア部品から構成し、かかる部品群の協調動作により印刷処理をおこなうこととしている。

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

しかしながら、この特許文献１で開示されている発明は、ハードウェアを制御する処理部分を共通化するものであり、各アプリケーションの内部処理全般を共通化するものではなく、さらには共通化した上で内部処理を機能に応じたクラスに分割していないため、内部処理全般の開発効率が良くないという問題がある。つまり、複合機上のアプリケーションには、開発効率の向上を図るためには内部処理を共通化して特徴のある機能をクラスとして分割することで改善の余地が残されている。

たとえば、利用者が装置に備えられた機能を使用するために認証を行う場合、機能毎の認証を共通化した上で、利用者の身分に基づいて認証を行い、正当に認証が行われた場合には機能毎に実行できる旨を示す許可証データを発行し、許可証データで利用者が機能毎に実行できるか否か保持することも可能である。

また、特許文献２で開示されている発明は、印刷制御ソフトウェアをオブジェクト指向設計による複数のソフトウェア部品から構成したものであり、利用者の認証を行ってから機能を使用するまでの流れを制御するソフトウェア部品を開示したものではない。したがって、多機能化により機能毎に利用者が実行可能な権限を有するか否か判断する複合機において、特許文献２で開示されている発明を応用して、利用者の認証に対応するソフトウェア部品を作成したとしても、利用者の認証を行ってから機能を使用するまでの処理を効率よく制御することは容易でない。

これらのことから、複合機に搭載されるアプリケーションの利用者の認証を行ってから機能を使用するまでの処理をいかにして効率よく実現するかが大きな課題となっている。なお、かかる課題は複合機についてのみ生じるものではなく、たとえば、複数の機能を有し、かつ所定の身分を有する利用者が認証を行った場合に、機能毎に実行を許可する利用者認証装置を形成するような場合にも同様に生ずる課題である。

本発明は、上述した従来技術による問題点を解消するためになされたものであり、利用者が機能を使用する際の認証処理を効率よく制御することができる利用者認証装置、画像形成装置、利用者認証方法及び利用者認証プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、機能の使用を要求した利用者毎に対応して生成される被認証者オブジェクトと、前記利用者の個人証明の照合に用いる認証情報を管理し、前記被認証者オブジェクトに対応付けて生成される複数個保持可能な身分証オブジェクトと、前記身分証オブジェクトが管理する前記認証情報を用いた前記個人証明の照合で、機能を使用できる利用者であることを確認された際、当該身分証オブジェクトと対応付けられた前記機能が複数存在する場合、当該機能毎に生成される、当該機能の使用が許可されたことを示す前記複数のチケットオブジェクトと、を備えたことを特徴とする。

また、請求項２にかかる発明は、請求項１にかかる発明において、前記チケットオブジェクトを生成する要求を受け付けた際、前記身分証オブジェクトが管理する前記認証情報を用いて前記個人証明の照合を行い、前記機能を使用できる利用者であること確認された際、前記身分証オブジェクトと対応付けられた前記機能毎に、前記チケットオブジェクトを生成する利用者情報管理手段と、をさらに備え、前記身分証オブジェクトは、さらに前記利用者情報管理手段に対して、前記チケットオブジェクトの生成を要求することを特徴とする。

また、請求項３にかかる発明は、請求項２にかかる発明において、前記利用者情報管理手段は、前記機能を使用できる前記利用者であることを示す識別情報を管理し、前記身分証オブジェクトが管理する前記認証情報と該識別情報を用いて、前記機能を使用できる前記利用者の照合を行うアカウントオブジェクトと、前記身分証オブジェクトから前記チケットオブジェクトを生成する要求を受け付けて前記アカウントオブジェクトにより前記機能を使用できる前記利用者であることが確認された場合に前記チケットオブジェクトを生成する発行オブジェクトと、を備えたことを特徴とする。

また、請求項４にかかる発明は、請求項２又は３にかかる発明において、前記身分証オブジェクトで示される前記個人証明で実行可能な前記機能を管理する機能制限手段と、を備え、前記利用者情報管理手段は、前記身分証オブジェクトから前記チケットオブジェクトを生成する要求を受け付けた際、前記身分証オブジェクトが管理する前記認証情報を用いて前記個人証明の照合を行い、前記機能を使用できる前記利用者である場合に、前記機能制限手段が管理している、前記身分証オブジェクトと対応付けられた前記機能毎に、前記チケットオブジェクトを生成することを特徴とする。

また、請求項５にかかる発明は、請求項２〜４のいずれか一つにかかる発明において、前記機能制限手段は、さらに前記被認証者オブジェクトが予め定められた最大認証者数以上生成されていた場合に、前記被認証者オブジェクトの生成を制限することを特徴とする。

また、請求項６にかかる発明は、請求項１〜５のいずれか一つにかかる発明において、前記身分証オブジェクトは、前記機能を使用する要求を受け付け、前記機能を使用する要求を受け付けた場合に、前記機能に対応する前記チケットオブジェクトが生成されているか否か判断し、前記チケットオブジェクトが生成されている場合に前記機能を使用することが可能であることを出力することを特徴とする。

また、請求項７にかかる発明は、請求項１〜６のいずれか一つにかかる発明において、前記チケットオブジェクトは、前記機能を使用できる期間を示す有効期限を管理し、前記機能の使用が有効であるか否かの確認を受け付けた際、前記有効期限を経過しているか否か判断し、前記有効期限を経過していない場合に前記機能の使用が許可されている旨を出力し、前記身分証オブジェクトは、前記機能を使用する要求を受け付け、前記機能に対応する前記チケットオブジェクトが生成されている場合に、前記チケットオブジェクトに対して前記機能を使用する許可が有効であるか否かの確認を行うことを特徴とする。

また、請求項８にかかる発明は、機能の使用を要求した利用者毎に対応して生成される被認証者オブジェクトと、前記利用者の個人証明の照合に用いる認証情報を管理し、前記被認証者オブジェクトに対応付けて生成される複数個保持可能な身分証オブジェクトと、前記身分証オブジェクトが管理する前記認証情報を用いた前記個人証明の照合で、機能を使用できる利用者であることを確認された際、当該身分証オブジェクトと対応付けられた前記機能が複数存在する場合に、当該機能毎に生成される、当該機能の使用が許可されたことを示す前記複数のチケットオブジェクトと、を備えたことを特徴とする。

また、請求項９にかかる発明は、機能の使用を要求した利用者を示す被認証者オブジェクトを生成する利用者生成ステップと、前記利用者生成ステップで生成された前記被認証者オブジェクトで示される前記利用者の個人証明の照合に用いる認証情報を保持する身分証オブジェクトを生成する個人証明情報生成ステップと、前記個人証明情報生成ステップで生成された前記身分証オブジェクトが保持する前記認証情報を用いて前記利用者の前記個人証明の照合を行い、機能を使用できる利用者であることを確認された際、当該身分証オブジェクトと対応付けられた前記機能が複数存在する場合、当該身分証オブジェクトと対応付けられた前記機能毎に、当該機能の使用が許可されたことを示すチケットオブジェクトを生成する許可情報生成ステップと、を有することを特徴とする。

また、請求項１０にかかる発明は、請求項９にかかる発明において、利用者から前記機能を使用する要求を受け付けた場合、要求として受け付けた前記機能に対応した前記チケットオブジェクトが前記許可情報生成ステップで生成されているか否か確認し、生成されていた場合に前記機能の使用を許可する確認ステップ、をさらに有することを特徴とする。

また、請求項１１にかかる発明は、請求項１０にかかる発明において、前記許可情報が保持する有効期限より、前記機能の使用の許可が有効か否か判断する判断ステップ、をさらに有することを特徴とする。

また、請求項１２にかかる発明は、請求項９〜１１のいずれか一つにかかる発明において、前記利用者生成ステップは、予め定められた最大認証者数以上の前記利用者情報が生成されていた場合、前記利用者情報の生成を行わないことを特徴とする。

また、請求項１３にかかる発明は、請求項９〜１２のいずれか一つに記載された利用者認証方法をコンピュータで実行させることを特徴とする。

請求項１にかかる発明によれば、機能と対応して生成された複数のチケットオブジェクトが、利用者から機能を使用する要求を受け付けた際に機能を使用できるか否か判断するため、機能を使用する場合に行われる認証処理を効率よく制御することができるという効果を奏する。

また、請求項２にかかる発明によれば、利用者情報管理手段で、チケットオブジェクトの生成を一括管理するので信頼性が向上するという効果を奏する。

また、請求項３にかかる発明によれば、照合を行うアカウントオブジェクトと、チケットオブジェクトを生成する要求を受け付ける発行オブジェクトとを分けたことで、信頼性が向上するという効果を奏する。

また、請求項４にかかる発明によれば、機能制限手段が個人証明で実行可能な機能を管理して、これを用いて利用者情報管理手段がチケットオブジェクトを生成するため、個人証明に適したチケットオブジェクトが生成されることになり、信頼性が向上するという効果を奏する。

また、請求項５にかかる発明によれば、生成される被認証者オブジェクトが制限されるため、機能を使用することができる利用者を制限できるため、ハードウェアに係る負担を軽減できるという効果を奏する。

また、請求項６にかかる発明によれば、チケットオブジェクトが生成されている場合に限り、チケットオブジェクトに対応した機能を使用することができるので、信頼性が向上するという効果を奏する。

また、請求項７にかかる発明によれば、有効期限を経過した場合は機能を使用することできないため、信頼性が向上するという効果を奏する。

また、請求項８にかかる発明によれば、機能と対応して生成されたチケットオブジェクトで、利用者から機能を使用する要求を受け付けた際に機能を使用できるか否か判断できるため、利用者が機能を使用する際の認証処理を効率よく制御することができるという効果を奏する。

また、請求項９にかかる発明によれば、機能と対応して生成されたチケットオブジェクトで、利用者から機能を使用する要求を受け付けた際に機能を使用できるか否か判断できるため、利用者が機能を使用する際の認証処理を効率よく制御することができるという効果を奏する。

また、請求項１０にかかる発明によれば、チケットオブジェクトが生成されていた場合に限り機能の使用を許可するため、信頼性が向上するという効果を奏する。

また、請求項１１にかかる発明によれば、有効期限を経過していない場合に限り機能の使用を許可するため、信頼性が向上するという効果を奏する。

また、請求項１２にかかる発明によれば、生成される被認証者オブジェクトの数が制限されるため、ハードウェアに係る負担を軽減できるという効果を奏する。

また、請求項１３にかかる発明によれば、コンピュータに読み取らせて実行することによって、請求項９から１２のいずれか一つに記載された利用者認証方法をコンピュータの利用で実現することができ、これら各利用者認証方法と同様の効果を奏する。

以下に添付図面を参照して、この発明にかかる利用者認証装置、画像形成装置、利用者認証方法及び利用者認証プログラムの最良な実施の形態を詳細に説明する。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、利用者の認証処理をおこなう各種装置に適用することができる。

（第１の実施の形態）
まず、本発明の第１の実施の形態に係る画像形成装置（以下「複合機」と言う）１の概要について図１、図２、図３、図１５および図１６を用いて説明する。図１は、本実施の形態に係る複合機１を取り巻くネットワーク環境を説明するためのネットワーク図であり、図２は、図１に示した複合機１のハードウェア構成を示すブロック図であり、図３は、図１に示した複合機１のソフトウェアとハードウェアの関係を説明するための概念図である。そして図１５は、複合機に搭載されるソフトウェア構成の変遷を説明するための説明図であり、図１６は、従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。

図１に示すように、近年のネットワーク化の進展により、オフィスなどに設けられたＰＣ（Personal Computer）などの機器は、ＬＡＮ（Local Area Network）などのネットワークに接続され、相互に通信することが通常となった。たとえば、本図に示したように、かかるネットワークには、クライアントＰＣ、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ、ＦＴＰ（File Transfer Protocol）サーバ、サーバＰＣなどが接続され、電子メールの送受信やファイル転送をすることができ、モデム接続された配信サーバは、オフィス外のファックス装置と通信することができる。

このようなネットワーク化の進展に伴い、複合機１もかかるネットワークに接続され、ＰＣ等の機器と相互に通信することが可能となり、ハードディスク等の記憶装置を内蔵することで、いわゆるネットワーク複合機へと進化し、ユーザの様々なニーズに応えることができるようになった。

具体的には、複合機１は、通常のコピー機能に加えて、クライアントＰＣからの印刷要求により文書データ等を印刷するプリンタ機能、クライアントＰＣからのファックス要求により文書データ等をサーバＰＣに接続されたモデムを経由して他のオフィスのファックス機器に送信するファックス機能、受信したファックス文書やコピー文書を内蔵したハードディスクに蓄積する蓄積機能などを有している。このような多くの機能を実現するために、従来からの複合機に搭載されるソフトウェアは規模が大きくなり、かつ複雑なものとなる。それにともない、それらのソフトウェアの開発と維持管理のための工数も大幅に増大している。そこで本実施の形態にかかる複合機１に搭載されるソフトウェアでは、開発と維持管理のための工数を減少させる。なお、複合機１に搭載されるソフトウェアの構成については後述する。

図２は、かかる複合機１のハードウェア構成を示すブロック図である。本図に示すように、この複合機１は、コントローラ１０とエンジン部（Engine）６０とをＰＣＩ（Peripheral Component Interconnect）バスで接続した構成となる。コントローラ１０は、複合機１全体の制御と描画、通信、図示しない操作部からの入力を制御するコントローラである。エンジン部６０は、ＰＣＩバスに接続可能なプリンタエンジンなどであり、たとえば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部６０には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。

コントローラ１０は、ＣＰＵ１１と、ノースブリッジ（ＮＢ）１３と、システムメモリ（ＭＥＭ−Ｐ）１２と、サウスブリッジ（ＳＢ）１４と、ローカルメモリ（ＭＥＭ−Ｃ）１７と、ＡＳＩＣ（Application Specific Integrated Circuit）１６と、ハードディスクドライブ（ＨＤＤ）１８とを有し、ノースブリッジ（ＮＢ）１３とＡＳＩＣ１６との間をＡＧＰ（Accelerated Graphics Port）バス１５で接続した構成となる。また、ＭＥＭ−Ｐ１２は、ＲＯＭ（Read Only Memory）１２ａと、ＲＡＭ(Random Access Memory)１２ｂとをさらに有する。

ＣＰＵ１１は、複合機１の全体制御をおこなうものであり、ＮＢ１３、ＭＥＭ−Ｐ１２およびＳＢ１４からなるチップセットを有し、このチップセットを介して他の機器と接続される。

ＮＢ１３は、ＣＰＵ１１とＭＥＭ−Ｐ１２、ＳＢ１４、ＡＧＰ１５とを接続するためのブリッジであり、ＭＥＭ−Ｐ１２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩマスタおよびＡＧＰターゲットとを有する。

ＭＥＭ−Ｐ１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ１２ａとＲＡＭ１２ｂとからなる。ＲＯＭ１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。

ＳＢ１４は、ＮＢ１３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。このＳＢ１４は、ＰＣＩバスを介してＮＢ１３と接続されており、このＰＣＩバスには、ネットワークインターフェース（Ｉ／Ｆ）部なども接続される。

ＡＳＩＣ１６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）であり、ＡＧＰ１５、ＰＣＩバス、ＨＤＤ１８およびＭＥＭ−Ｃ１７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ１６は、ＰＣＩターゲットおよびＡＧＰマスタと、ＡＳＩＣ１６の中核をなすアービタ（ＡＲＢ）と、ＭＥＭ−Ｃ１７を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のＤＭＡＣ（Direct Memory Access Controller）と、エンジン部６０との間でＰＣＩバスを介したデータ転送をおこなうＰＣＩユニットとからなる。このＡＳＩＣ１６には、ＰＣＩバスを介してＦＣＵ（Fax Control Unit）３０、ＵＳＢ（Universal Serial Bus）４０、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インターフェース５０が接続される。

ＭＥＭ−Ｃ１７は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＨＤＤ（Hard Disk Drive）１８は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。

ＡＧＰ１５は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、ＭＥＭ−Ｐ１２に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。

図３は、かかる複合機１のハードウェアおよびソフトウェアの構成を示した概念図であり、具体的には、後述する本実施の形態の特徴部分である認証管理部２１１を含む統合アプリケーション１１０と、ソフトウェア１００およびハードウェア１５０の階層関係を示している。本図に示すように、ハードウェア１５０は、ハードウェアリソース１５１を有し、このハードウェアリソース１５１は、スキャナ１５１ａ、プロッタ１５１ｂ、ＨＤＤ（Hard Disk Drive）１５１ｃ、ネットワーク１５１ｄおよびその他のリソース１５１ｅを有する。なお、その他のリソース１５１ｅは、１５１ａ〜１５１ｄ以外のハードウェアリソース１５１のことであり、たとえば、操作パネルなどの入出力デバイスを示す。

図４は、複合機１の操作パネル４００の一例を示した図である。本図に示したように、かかる操作パネル４００は、初期設定キー４０１、コピーキー４０２、コピーサーバーキー４０３、プリンタキー４０４、送信キー４０５、テンキー４０６、クリア／ストップキー４０７、スタートキー４０８、予熱キー４０９、リセットキー４１０および液晶タッチパネル４２０を有する。このような構成を有する操作パネル４００でユーザが所定の操作を行った場合に、統合アプリケーション１１０に含まれている本実施の形態の特徴である各クラスを実体化したオブジェクトが動作する。

例えば、初期設定キー４０１をタッチすると、液晶タッチパネル４２０に初期設定用のメニューが表示され、かかるメニューにおいては、収納される用紙サイズなどを設定することができる。また、コピーをしたい場合にはコピーキー４０２を、コピー結果を複合機１に蓄積したい場合にはコピーサーバーキー４０３を、プリンタに係る操作をおこないたい場合には、プリンタキー４０４を、ファックスや蓄積画像などの送信をしたい場合には送信キー４０５を、それぞれタッチすると、液晶タッチパネル４２０に対応したメニューが表示される。

図３に戻り、かかるハードウェア１５０に搭載されるソフトウェア１００は階層化されており、オペレーティングシステム１０３の上層にはサービス層１０２が構築され、このサービス層１０２の上層にはアプリケーション層１０１が構築されている。そして、サービス層１０２は、各ハードウェアリソース（１５１ａ〜１５１ｅ）を制御するドライバーに相当する、スキャナ制御部１０２ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、配信／メール送受信制御部１０２ｄ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇを有する。

ここで、図３に示したソフトウェア１００が、かかる階層構造をとるに至った経緯について、図１５および図１６を用いて説明する。図１５は、複合機に搭載されるソフトウェア構成の変遷を示す説明図である。図１５のサービス層分離前アプリケーション１５０１に示すように、多機能化した複合機に搭載されるソフトウェアは、コピーアプリケーション、ＦＡＸアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成され、図３に示したオペレーティングシステム１０３上で動作していた。

しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー（サービス層１０２）を含んでいたため、各アプリケーションには重複した処理が存在していた。その結果、各アプリケーションの規模は大きなものとなっていた。

そこで、図１５のサービス層分離後アプリケーション１５０２に示すように、サービス層分離前アプリケーション１５０１のサービス層相当部分を括りだしてサービス層１０２にするとともに、各アプリケーションは、このサービス層１０２の上層であるアプリケーション層１０１に構築する構成とした。かかる階層化構成をとることで、各アプリケーションはスリム化され開発労力も軽減された。

しかしながら、複合機のネットワーク化、多機能化がさらに進展するに従って、各アプリケーションに共通処理部分が存在することが問題となってきた。具体的には、アプリケーション層１０１の各アプリケーション、たとえば、コピーアプリケーションやスキャナアプリケーションなどは、それぞれ、スキャナ制御部１０２ａや蓄積制御部１０２ｃといったドライバーと通信をおこなう処理や、各種機能が取り扱うデータの流れを制御するストリーム制御などの同様な処理を内部に有していた。このように、同様な処理を各アプリケーションが有していると、各アプリケーションの開発規模が大きくなるとともに、サービス層の仕様変更に対する各アプリケーションの改修規模が大きくなることが問題となってきた。

この問題を解決するため、図１５の共通ルーチン分離アプリケーション１５０３に示すように、かかる同様な処理（共通処理部分）を共通ルーチンとして括りだすことも考えられた。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化しようとするものであるため、共通ルーチン内部の処理は複雑なものとなってしまう。また、たとえば、プリンタアプリケーションなどの新規アプリケーションを追加する場合においては、かかる新規アプリケーションに適応するために、共通ルーチンの改修が必要となる。

しかし、共通ルーチンの内部処理は複雑であるため、改修要員が処理を把握することが困難となり、改修規模の増大や、改修ミスによる他のアプリケーションへの影響が懸念された。

そこで、図１５のオブジェクト指向アプリケーション１５０４に示すように、オブジェクト指向による設計手法（オブジェクトモデリング）により、かかる複数のアプリケーションを、統合アプリケーション１１０に統合することとした。具体的には、各アプリケーションの共通処理部分をオブジェクトモデルとして抽出し、このオブジェクトモデルの集合体から、統合アプリケーション１１０を構成する。そして、従来のコピー機能やスキャナ機能といった機能は、かかるオブジェクトモデルの協調関係によって実現する。

このような構成をとることにより、たとえばプリンタ機能のような新規機能の追加は、かかるオブジェクトモデルに属するクラスのサブクラス化などにより対処できる。このため、改修部分が明確となり、改修による他の機能への影響を小さくすることができる。また、オブジェクトモデリングによるプログラムは、従来の手続き型プログラムに比べて、処理の把握が容易であるため、改修要員が処理を把握することも容易となり、改修規模の削減や、改修ミスによる他のアプリケーションへの影響を小さくすることができる。

図１６は、図１５に示したサービス層分離後アプリケーション１５０２の段階における従来のアプリケーションの構成と、かかるアプリケーションとサービス層１０２の各ドライバーの関係を示した説明図である。本図に示すように、アプリケーション層１０１Ａは、コピーアプリケーション１２１、スキャナアプリケーション１２２、ファックスアプリケーション１２３およびプリンタアプリケーション１２４を有する。

たとえば、コピーアプリケーション１２１は、コピー機能を実現するために、スキャナ制御部１０２ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃおよびその他の制御部１０２ｇとデータの送受信をおこなう。また、ファックスアプリケーション１２３は、ファックス機能を実現するために、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇとデータの送受信をおこなう。このように、アプリケーション層１０１Ａの各アプリケーションとサービス層１０２の各ドライバー間の通信は、複雑なものとなっていた。

図３に戻り、上述したオブジェクトモデリングにより、アプリケーション層１０１に存在した複数のアプリケーションは、統合アプリケーション１１０に統合されている。そして、各アプリケーションが重複しておこなっていた各ドライバーとの通信処理は、統合アプリケーション１１０を構成する所定のオブジェクトモデルにおこなわせるように構成したことにより、アプリケーション層１０１のアプリケーションと、サービス層１０２の各ドライバー間の通信は、図１６と比較して単純になっている。

次に、統合アプリケーション１１０の内部構成について説明する。図５は、統合アプリケーション１１０の内部構成、及び統合アプリケーション１１０内における後述する本実施の形態の特徴的部分である認証管理部２１１の位置を示す説明図である。本図に示すように、統合アプリケーション１１０は、操作系サブシステム２０１と、管理系サブシステム２０２と、実行系サブシステム２０３とを有する。

操作系サブシステム２０１は、マンマシンインタフェースを担当するソフトウェア群である。具体的には、この操作系サブシステム２０１は、ユーザの要求を受け付ける処理と、この要求の実行を指示する処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。

管理系サブシステム２０２は、複合機１の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム２０２は、ハードウェアリソース１５１およびこのハードウェアリソース１５１が保持するデータ状態を管理するサービスをおこなう。

実行系サブシステム２０３は、ユーザからの要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム２０３は、コピー要求がなされた場合には、原稿の読み取りから成果物の出力までの処理をおこなう。

操作系サブシステム２０１、管理系サブシステム２０２および実行系サブシステム２０３は、必要に応じて相互に処理を依頼してその結果を送り合う。このようにそれぞれのサブシステムが協調し合って、統合アプリケーション１１０全体として複合機１に必要とされるサービスの提供をおこなう。

そして、管理系サブシステム２０２は、本実施の形態の特徴部分である認証管理部２１１を有する。この認証管理部２１１は、操作系サブシステム２０１から利用者の認証に関する要求又は複合機１で機能を実行する際に利用者が機能を実行できるか否かの要求を受け付け、利用者に関する認証を行い、機能が実行できる場合にその旨を実行系サブシステム２０３に出力する。

図６は、図５に示した各サブシステムを、ＵＭＬ（Unified Modeling Language）のクラス図（ＵＭＬクラス図）に置き換えた図である。ここで、ＵＭＬとは、ＯＭＧ（Object Management Group）が仕様を策定しているシステムモデリング言語であり、モデリングの成果を記述する記法を定義したものである。このＵＭＬは、オブジェクト指向によるソフトウェアの設計において広く用いられている。

図６に示すように、統合アプリケーション１１０は複数のパッケージを有し、また、この統合アプリケーション１１０自体もひとつのパッケージとなっている。ここで、パッケージとはＵＭＬモデルの各構成要素（シンボル）をグループ化したものであり、このパッケージは、左上にタブのついたフォルダ型のシンボルで表現される。また、各パッケージを相互に結ぶ直線は、各パッケージ間に処理依頼などの関連があることを示している。

図６に示したように、統合アプリケーション１１０は、操作系サブシステム２０１、管理系サブシステム２０２および実行系サブシステム２０３の３つのパッケージを内部に有するパッケージである。さらに、管理系サブシステム２０２は、認証管理部２１１のパッケージを内部に有するパッケージである。そして、操作系サブシステム２０１、管理系サブシステム２０２および実行系サブシステム２０３を相互に結ぶ直線は、各パッケージ間にメッセージ送受信などの関連があることを示している。なお、操作系サブシステム２０１、管理系サブシステム２０２および実行系サブシステム２０３のタブの右端に記された記号は、かかるパッケージがサブシステムであることを示すＵＭＬのシンボルである。

そして、本実施の形態の特徴部分である認証管理部２１１について詳細に説明する。なお、この認証管理部２１１は、オブジェクト指向に基づいて設計するにあたって、既存の処理を単純にオブジェクト化せず、機能追加や改修をより一層容易におこなうことができるようにオブジェクトモデルを構成した。

図７は、本実施の形態の特徴部分である認証管理部２１１で行われる処理の概念を示した概念図である。概念としては遊園地のような場所を想定している。本図に示すように「ゲート」は制限されていない「利用者」に限り入場させる。利用者の入場を制限する場合としては入場者数が最大入場者数を超えた場合などが考えられる。

そして、入場した利用者はゲート内部の施設（本発明の装置においては「機能」）を使用することが出来る。施設を使用する際に、「利用者」は「チケット発行所」に、本人であることを証明する「身分証」を提示する。「チケット発行所」は提示された「身分証」と、予め保持している「名簿」を対比して確認し、正当な「利用者」であると確認できた場合に「チケット」が発行される。このチケットは使用できる施設と対応しており、対応していない施設については使用することが出来ない。つまり「チケット」を提示することで対応する施設（本発明の装置においては「機能」）が使用できることになる。また、「チケット」は、「身分証」で保証された地位に基づいて発行されることになる。つまり、「身分証」で保証された地位が高ければ、より多くの施設が使用することができる。あるいは「身分証」で保証された地位の種類に応じて異なる施設が使用できることになる。

具体的な例としては、ゲート内部に施設Ａ、Ｂ、Ｃがあるとする。そして、利用者が身分証を提示して、チケットＡ及びチケットＢが発行された場合、利用者は、チケットＡに対応する施設ＡとチケットＢに対応する施設Ｂを使用することができる。しかし、施設Ｃは対応するチケットＣが発行されなかったので使用することが出来ない。

かかるモデルを認証管理部２１１に当てはめると次のようになる。すなわち、使用できる利用者のみログインを許可する「ゲート」が設置されている。そして、「ゲート」から入場した利用者であり、機能を使用する際に認証される「被認証者」が存在する。そして「被認証者」が本人であることを証明するために「身分証」を保持する。そして「被認証者」は、「身分証」による照合が正当である場合に発行される「チケット」を「身分証」と対応付けて保持する。そして「チケット発行所」は、「身分証」を提示した場合に、予め保持している「アカウント」を用いて本人であることが証明されたか否か確認し、確認できた場合に「チケット」を発行する。さらに「チケット発行所」は「身分証」により施設を使用できるか否か、予め保持している「アカウント」で確認を行う。

また、これらのクラスは大別すると３つの構成に分かれる。つまり、利用者が機能を使用できるか否かを管理する機能制限部と、利用者について予め登録された情報を保持し、個人証明による照合を行う登録情報管理部と、利用者及び利用者が保持している情報を管理する利用者機能管理部と、から構成されている。そして、機能制限部は「ゲート」を保持し、登録情報管理部は「チケット発行所」及び「アカウント」を保持し、利用者機能管理部は「被認証者」、「身分証」及び「チケット」を保持する。これらの構成及びクラスの説明については後述する。

また、利用者が複数の「身分証」を保持することも考えられる。現代社会においても、利用者が身分証として提示できるものは「免許証」、「社員証」及び「保険証」などのように複数存在し、使用する施設や乗り物に適した身分証を提示する必要がある。そこで、「被認証者」は「身分証」を複数保持することを可能にし、提示された「身分証」の種類に対応して異なる「チケット」が発行されることとする。

図８は、利用者が複数保持した身分証のうち任意の身分証を提示した場合にチケットが発行されるまでの処理の概念を示した概念図である。本図に示すように、ケース（１）として身分証Ｉを提示した場合では、チケット発行所で照合が行われた後にチケットＡ及びチケットＢが発行されることになる。そして、ケース（２）として身分証ＩＩを提示した場合では、チケット発行所で照合が行われた後にチケットＣが発行されることになる。このように身分証に応じて異なる種類のチケットが発行される。このため、本発明の認証管理部２１１では、同一利用者に対して複数のセキュリティレベルが設定できることになり、信頼性が向上する。

そして、上述したオブジェクトモデリングにより設計された認証管理部２１１で身分証という概念を用いて利用者の個人証明の照合を行う。利用者の個人証明とは、例えば利用者本人であることの証明を示し、より具体的な例としては「社員証」や「住民証」等が考えられる。

本実施の形態では、ログイン方法、つまりユーザＩＤとパスワードを入力してログインするのか、印刷した枚数をカウントするキーカウンターを差し込んだのか、ＩＣカードをカードリーダに読み込ませてログインしたのか、又はコインラックに硬貨を投入したのか等により生成される身分証が異なることとする。また、ユーザＩＤとパスワードでログインした後、さらにキーカウンターを差し込むことで同一利用者が複数の身分証を保持することもある。具体的な例としては、ユーザＩＤとパスワードでログインする場合、操作系サブシステム２０１が、操作パネル４００又はクライアントＰＣからの利用者のユーザＩＤ及びパスワードの入力を受け付ける。そして、操作系サブシステム２０１がユーザＩＤ及びパスワードの入力を受け付けた場合、管理系サブシステム２０２の認証管理部２１１に出力し、ユーザＩＤ及びパスワードの入力を示すユーザコードという身分証が生成される。

図９は、上述したオブジェクトモデリングにより設計された認証管理部２１１のブロック構成、及びクラス構成をＵＭＬのクラスで示した図である。本図に示すように、認証管理部２１１は、機能制限部９１０と、登録情報管理部９２０と、利用者機能管理部９３０とを備えている。これにより、機能制限部９１０で操作系サブシステム２０１から入力を受け付け、登録情報管理部９２０で個人証明の照合が行われた場合、利用者機能管理部９３０が、利用者が機能できることを証明することで、利用者本人であることが証明された場合に、機能を実行するという制御が可能になる。

そして、機能制限部９１０は、機能を使用する際に利用者が入る（ログインする）ことを管理するゲートクラス９１１を備える。

また、登録情報管理部９２０は、本発明の利用者情報管理手段に相当し、利用者名と識別情報を対応付けて管理して利用者の照合を行うアカウントクラス９２２と、利用者から利用者本人であることを証明する身分証の提示を受け付けて機能を使用できることが確認できた場合にチケットを発行するチケット発行所クラス９２１と、を備える。

また、利用者機能管理部９３０は、利用者及びこの利用者に対応した個人証明を管理して、登録情報管理部９２０に対してチケットの発行の要求を行う利用者証明管理部９３１と、登録情報管理部９２０より発行されたチケットを管理する利用可能機能管理部９３２と、を備える。そして、利用者証明管理部９３１は、認証される対象となる利用者を示す被認証者クラス９３４と、利用者が保持する身分証を示し、チケット発行所クラス９２１に対してチケット発行の要求を行う身分証クラス９３３と、を備える。また、利用可能機能管理部９３２は、対応する機能が実行できることを証明するチケットクラス９３５を備える。なお、身分は利用者個人の社会的な地位や資格をいう以上、個人であることの証明である個人証明に含まれる概念となる。

各クラスを示す矩形は３段の区画を有し、上から、クラス名を示す名前区画、クラスが有するデータ（属性）を示す属性区画およびクラスが有する処理（操作）を示す操作区画と呼ばれる。たとえば、チケットクラス９３５を示す矩形の名前区画は、かかるクラスのクラス名が「チケット」であることを示し、属性区画は、かかるクラスが有する属性が、「機能種類」であることを示し、操作区画は、かかるクラスが有する操作が、「有効かどうか判断する」であることを示している。

このように、各クラスは、データ（属性）を所持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう処理（操作）を所持するための操作区画とを有している。これらのクラスは、プログラム（統合アプリケーション１１０）の一部として含まれるので、あらかじめＲＯＭ１２ａに格納されたこのプログラムが実行されると、各クラスはＲＡＭ１２ｂの所定領域に実体化され、属性区画に含まれる各データ（属性）がＲＡＭ１２ｂ上に展開される。したがって、クラスを実体化したオブジェクトは、ＲＡＭ１２ｂ上の各データ（属性）の書き込みおよび読み出しをすることが可能となる。

なお、属性や操作といったクラスの要素の左側に「−」記号を付した場合は、かかる要素は外部のクラスには非公開であることを示し、「＋」記号を付した場合は、かかる要素は外部のクラスに公開されていることを示す。また、操作については「変更（）」のように「（）」記号を付することが通例であり、「（引数１，引数２）」のように、かかる操作に引き渡す引数を記述する場合もある。

次に、図９に示した本実施の形態の特徴部分である認証管理部２１１が備える各クラスについて説明する。

ゲートクラス９１１は、複合機１を利用するユーザのログイン数を管理し、ゲートクラス９１１が有する最大認証者数より現在のログイン数が多いか否かにより、ユーザからのログイン要求を受け付けるか否か判断する。そして、ログイン要求を受け付けた場合は、ゲートオブジェクト９１１Ａがログイン要求を受け付けたユーザに対応する被認証者オブジェクト９３４Ａを生成する。さらに、ゲートオブジェクト９１１Ａは、操作系サブシステム２０１から機能を使用できるか否か確認を要求された場合、被認証者クラス９３４に問い合わせる。具体的には、このゲートクラス９１１は、属性として最大認証者数９１１ａと、制限範囲９１１ｂと、入場方法９１１ｃとを有し、操作として、入る（）９１１ｄと、入場者を確認する（）９１１ｅとを有する。なお、かかるゲートクラス９１１を実体化したオブジェクトが生成されると、最大認証者数９１１ａと、制限範囲９１１ｂと、入場方法９１１ｃはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。

最大認証者数９１１ａは、複合機１に同時にログインすることが出来る利用者の数を保持する。

制限範囲９１１ｂと、入場方法９１１ｃは、機能と認証に用いた身分証とを対応付けて保持する。図１０は、制限範囲９１１ｂと入場方法９１１ｃとの対応関係を示した図である。本図に示すように、制限範囲として、複合機１が保持する機能が示され、入場方法には利用者が認証に用いることが出来る身分証が示されている。制限範囲９１１ｂと、入場方法９１１ｃとを対応付けて保持することで、利用者の機能の使用を制限することができる。また、ゲートクラス９１１と、チケット発行所クラス９２１は、図９の点線矢印で示したような依存関係にあり、チケット発行所クラス９２１からゲートクラス９１１の機能として、制限範囲９１１ｂと入場方法９１１ｃの対応関係を呼び出すことができる。また、制限範囲９１１ｂと入場方法９１１ｃとの対応関係では、機能毎の入場方法だけでなく、複合機１全体に対する入場方法も保持する。

図９に戻り、入る（）９１１ｄは、操作系サブシステム２０１から利用者のログイン要求を受け付けて、被認証者オブジェクト９３４Ａを生成し、利用者の認証を被認証者オブジェクト９３４Ａに要求する。また、入る（）９１１ｄは、引数として後述する被認証者オブジェクト９３４Ａに設定される情報や身分証オブジェクト９３３Ａに設定される情報等を受け渡され、利用者の認証を行う際に用いる。

入場者を確認する（）９１１ｅは、操作系サブシステム２０１から、ログインした利用者からの機能を使用する要求をゲートオブジェクト９１１Ａが受け付けた場合に、機能を使用する要求を行った利用者に対応する被認証者オブジェクト９３４Ａに機能を使用する権利があるか確認を要求する。

被認証者クラス９３４は、本発明の利用者手段に相当し、ログインを要求してゲートオブジェクト９１１Ａから入場することが出来た利用者を特定する情報を管理し、利用者が行う認証や機能を実行する際に行われる確認等を制御する。具体的には、被認証者クラス９３４は、属性として、利用者名９３４ａ、状態９３４ｂを有し、操作として、認証を行う（）９３４ｃと、認証状態を確認する（）９３４ｄとを有している。なお、かかる被認証者クラス９３４を実体化したオブジェクトが生成されると、利用者名９３４ａはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。

利用者名９３４ａは、ログインを要求した利用者の利用者名を保持する。利用者名９３４ａとしては、例えばログインする要求と共に入力処理されたユーザＩＤ等とする。後述する認証を行う（）９３４ｃで呼び出された際に、引数として保持する情報から利用者名９３４ａが設定される。また、利用者名９３４ａは、ユーザＩＤに制限するものではない。例えば、複合機１に接続して利用した回数を保持するキーカウンターや、硬貨を入れて複合機１を利用するコインラック等の場合、利用者名９３４ａとしては‘Ｇｕｅｓｔ’や‘Ｆｒｅｅ’が設定される。

状態９３４ｂは、機能を使用する要求に対して、使用する要求を行った利用者が本物か否か確認に必要な状態９３４ｂを保持する。本実施の形態では、入力装置となる利用者のログインした操作パネル４００又はＰＣ等の情報を保持することで、本物か否か確認する。

図１１は、利用者が複合機１にログインする際に操作パネル４００に表示される画面の一例を示した図である。本図に示した画面が表示された後、利用者はログインするためにユーザ名及びパスワードが入力した後、‘ログイン’ボタン１１０２を押下する。これにより操作系サブシステム２０１がアカウント名及びパスワードを入力処理し、ゲートオブジェクト９１１Ａが被認証者オブジェクト９３４Ａを生成して、ユーザＩＤとパスワード、そして操作パネル４００から入力された旨が被認証者オブジェクト９３４Ａに入力される。そして、被認証者オブジェクト９３４Ａが保持する利用者名９３４ａにユーザＩＤが設定され、状態９３４ｂに操作パネル４００からログインした旨が設定される。そしてパスワードについては生成される身分証オブジェクト９３３Ａで保持することになる。

認証を行う（）９３４ｃは、ゲートオブジェクト９１１Ａから、利用者のログイン要求を受け付けた際に呼び出される。また、認証を行う（）９３４ｃが呼び出された場合、引数として利用者名９３４ａとして設定される情報や、後述する身分証オブジェクト９３３Ａに設定される情報等から、利用者名９３４ａを設定し、さらに身分証オブジェクト９３３Ａを生成して、身分証オブジェクト９３３Ａの身元確認する（）９３３ｃを呼び出す。

認証状態を確認する（）９３４ｄは、ゲートオブジェクト９１１Ａから利用者が機能を使用する際に行われる認証要求として呼び出され、機能を使用する旨を入力した入力装置と状態９３４ｂが保持する情報が一致するか否か判断し、一致した場合に利用者が本物であると判断し、後述する身分証オブジェクト９３３Ａに対して機能を使用できるか否か確認を要求する。

身分証クラス９３３は、本発明の個人証明情報手段に相当し、利用者本人であることを証明する際に用いられる情報を管理する。本実施の形態では利用者本人であることを証明する際に用いられる情報を認証情報９３３ｂとする。そして身分証クラス９３３は、後述するチケット発行所クラス９２１に対して上述した情報を用いて利用者の身元を証明し、チケットオブジェクト９３５Ａの発行を要求し、発行されたチケットオブジェクト９３５Ａを管理する。具体的には、身分証クラス９３３は、属性として、身分種類９３３ａと、認証情報９３３ｂとを有し、操作として、身元確認する（）９３３ｃと、チケットを受け取る（）９３３ｄと、権利を確認する（）９３３ｅとを有している。なお、かかる身分証クラス９３３を実体化したオブジェクトが生成されると、身分種類９３３ａと認証情報９３３ｂはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。

身分種類９３３ａは、利用者のログインした方法を身分証の種類として保持する。また、身分種類９３３ａは、換言すれば個人証明を照合する手段の種類ということになる。身分種類９３３ａの例としては、ユーザコード、キーカウンター、コインラック、キーカード等が考えられる。この身分種類９３３ａは、チケット発行所オブジェクト９２１Ａがチケットを発行する際に使用される。キーカードとはカードリーダにカードを読み込ませてログインを行った場合を示す。身分種類９３３ａを保持することで、同一の被認証者オブジェクト９３４Ａと対応付けられた複数の身分証オブジェクト９３３Ａを生成することを可能とする。

認証情報９３３ｂは、利用者の身元を証明する際に用いられる情報を保持する。また認証情報９３３ｂは、身分種類９３３ａにより設定される情報が異なり、例えばユーザコードの場合、利用者にログイン時に入力されたパスワードが設定される。また、キーカウンターあるいはコインラックの場合は、予め定められた文字列、例えば‘Ｇｕｅｓｔ’あるいは‘Ｆｒｅｅ’等が設定される。キーカードではカードのＲＯＭに予め記憶していた暗号鍵などとする。

身元確認する（）９３３ｃは、被認証者オブジェクト９３４Ａから呼び出され、認証情報９３３ｂを用いた身元の確認することとして、チケット発行所クラス９２１にチケットの発行を要求する。また、身元を確認する（）９３３ｃは、引数として利用者名９３４ａ及び身元を証明する際に用いられる情報を受け取り、身元を証明する際に用いられる情報を認証情報９３３ｂとして設定する。

チケットを受け取る（）９３３ｄは、後述するチケット発行所クラス９２１から生成されたチケットオブジェクト９３５Ａを受け取り、身分証オブジェクト９３３Ａと対応付けて保持する。

権利を確認する（）９３３ｅは、被認証者オブジェクト９３４Ａから呼び出され、利用者が機能を使用する権利が有するか機能に対応するチケットオブジェクト９３５Ａに有効かどうか判断を要求する。また、利用者が使用する機能に対応したチケットオブジェクト９３５Ａが生成されていない場合は、利用者は機能を使用する権利が無い旨のメッセージを被認証者オブジェクト９３４Ａに送信する。また、チケットオブジェクト９３５Ａから、有効であるとのメッセージを受信した場合、身分証オブジェクト９３３Ａは、利用者が機能を使用する権利がある旨のメッセージを被認証者オブジェクト９３４Ａに送信する。

図１２は、利用者が実行を要求した機能を使用する権利がない場合に液晶タッチパネル４２０上に表示される画面の一例を示した図である。本図に示すように、利用者に使用する権利を有していない旨１２０１を表示することで、利用者に機能を使用する権限を有していないことを認識させることができる。

チケット発行所クラス９２１は、身分証クラス９３３からチケット発行の要求を受け付け、利用者の身元を確認した場合にチケットオブジェクト９３５Ａを生成する。また、チケット発行所クラス９２１は、ゲートクラス９１１と依存関係にあるため、ゲートクラス９１１の機能を呼び出すことができる。具体的には、チケット発行所クラス９２１は、操作として、発行を要求する（）９２１aを有している。

発行を要求する（）９２１ａは、身分証クラス９３３から呼び出され、アカウントクラス９２２に呼び出した身分証クラス９３３と対応付けられた利用者の照合を要求し、照合により身元を確認できた場合にチケットオブジェクト９３５Ａを生成し、身分証オブジェクト９３３Ａと対応付ける。また、発行を要求する（）９２１ａは、引数として利用者名、認証情報及び身分種類を受け取り、利用者名と認証情報を照合するためにアカウントクラスに受け渡す。そして、アカウントクラスから身元が確認できた旨を受け取った場合、ゲートオブジェクト９１１Ａの機能を呼び出して、制限範囲９１１ｂと入場方法９１１ｃの対応関係から受け取った身分種類で使用することが可能な機能を特定し、特定された機能に対応したチケットを発行する。

アカウントクラス９２２は、チケット発行所クラス９２１から利用者の照合を受け付け、照合した結果をチケット発行所クラス９２１に送信する。具体的には、アカウントクラス９２２は、属性として、利用者名９２２ａと、識別情報９２２ｂとを属性として有し、操作として、照合する（）９２２ｃを有している。なお、かかるアカウントクラス９２２を実体化したオブジェクトが生成されると、利用者名９２２ａと識別情報９２２ｂはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。

利用者名９２２ａは、複合機１の機能を使用することができる利用者の利用者名を保持し、識別情報９２２ｂは、利用者名９２２ａの利用者であることを証明する情報を保持する。また、利用者名９２２ａ及び識別情報９２２ｂは、キーカウンターあるいはコインラックを示すものとして予め定められた文字列、例えば‘Ｇｕｅｓｔ’あるいは‘Ｆｒｅｅ’が設定されている。

照合する（）９２２ｃは、チケット発行所クラス９２１から呼び出され、利用者の照合を行う。具体的には、チケット発行所クラス９２１から呼び出された際に、照合する（）９２２ｃは、引数として受け取った利用者名及び認証情報が、属性として有する利用者名９２２ａと識別情報９２２ｂと一致するか否か判断する。そして、一致すると判断した場合は、チケット発行所クラス９２１に対して、身元が確認できた旨を送信する。一致しないと判断した場合は、チケット発行所クラス９２１に対して、身元が確認できなかった旨を送信する。

チケットクラス９３５は、本発明の許可情報手段に相当し、チケット発行所クラス９２１で身元が確認できた場合に生成され、操作系サブシステム２０１から機能を使用する要求があった場合、要求が有効かどうか判断して結果を送信する処理を行う。具体的には、属性として、機能種類９３５ａと、有効期限９３５ｂとを有し、操作として、有効かどうか判断する（）９３５ｃを有している。なお、かかるチケットクラス９３５を実体化したオブジェクトが生成されると、機能種類９３５ａはＲＡＭ１２ｂ上に展開されるので、これらのデータ（属性）の書き込みおよび読み出しをすることが可能となる。

機能種類９３５ａは、身分証クラス９３３において使用することができる機能の種類を保持する。具体的には、チケット発行所クラス９２１でチケットオブジェクト９３５Ａが生成された際に、呼び出されたゲートクラス９１１の制限範囲９１１ｂと入場方法９１１ｃの対応関係より、身分証クラス９３３の身分種類９３３ａで使用することができる機能の種類が設定されることになる。機能種類９３５ａを保持することで、チケットオブジェクト９３５Ａを機能毎に生成することを可能とする。

詳細な例としては、身分証クラス９３３の身分種類９３３ａがキーカードであった場合、図９で示した制限範囲９１１ｂと入場方法９１１ｃの対応関係より、コピーとスキャナとＤｏｃＢｏｘの機能を使用することができることになる。そこで、チケット発行所クラス９２１がチケットオブジェクト９３５Ａを生成する際、チケットオブジェクト９３５Ａが３つ生成され、生成されたチケットオブジェクト９３５Ａ毎に、コピー、スキャナ、ＤｏｃＢｏｘが設定される。

有効期限９３５ｂは、生成されたチケットオブジェクト９３５Ａを使用することが可能な有効期限を保持する。この有効期限９３５ｂは、チケット発行所クラス９２１でチケットオブジェクト９３５Ａが生成された際に生成された時間から予め定められた有効時間後を設定する。予め定められた有効時間は、利用者が使用していると考えられる時間として適した時間を設定する。

有効かどうか判断する（）９３５ｃは、身分証オブジェクト９３３Ａから呼び出され、チケットオブジェクト９３５Ａが有効かどうか判断する。具体的には、身分証オブジェクト９３３Ａが、利用者が使用を要求した機能に対応したチケットオブジェクト９３５Ａが有効かどうか判断する（）９３５ｃを呼び出す。そして、有効かどうか判断する（）９３５ｃが呼び出された場合、属性として有する有効期限９３５ｂを経過しているか否か確認する。有効かどうか判断する（）９３５ｃが、有効期限９３５ｂを経過していると判断した場合、有効では無い旨を身分証オブジェクト９３３Ａに送信する。また、有効期限９３５ｂ内と判断した場合、有効である旨を身分証オブジェクト９３３Ａに送信する。

次に、図９に示した各クラス間の関係について説明する。本図に示したように、各クラスを示す矩形を結ぶ直線は、その両端のクラス間に関係があることを表しており、この直線の両端付近の文字はクラスの役割を、数字はクラスの多重度をそれぞれ示している。ここで、役割とは、かかる直線の両端における、一方のクラスからみた、もう一方のクラスの役割や立場のことであり、多重度とは、かかる直線の両端のクラスから生成されるオブジェクト数の対応関係のことである。

たとえば、ゲートクラス９１１からみた被認証者クラス９３４の役割は「利用者」であり、被認証者クラス９３４からみたゲートクラス９１１の役割は「制限場所」であり、ゲートクラス９１１の多重度は「１」であり、被認証者クラス９３４の多重度は「０．．＊」である。ここで、「０．．＊」は、かかる被認証者クラス９３４の多重度が、０から上限数なしの範囲であることを示している。また、たとえば、「１．．３」の記載をした場合には、かかるクラスの多重度が、１〜３の範囲であることを示す。

まず、ゲートクラス９１１と被認証者クラス９３４とのクラス関係について説明する。ゲートクラス９１１は、被認証者クラス９３４からみると複合機１に対して機能を使用しようとしている利用者が入ることを制限する制限場所としての役割を有しており、一方、被認証者クラス９３４は、ゲートクラス９１１からみると入ることができた利用者としての役割を有している。このようなクラス関係によりゲートクラス９１１から生成された被認証者オブジェクト９３４Ａからの要求に応じて身元を確認し、確認された場合に複合機１の機能を使用することが可能となる。

そして、本図に示したように、認証管理部２１１が実行される場面において、ゲートクラス９１１をＲＡＭ１２ｂ上に展開（実体化）したオブジェクトは１個だけ存在し、このゲートクラス９１１よりログインを認められた利用者毎に生成される被認証者クラス９３４を実体化したオブジェクトは０個以上、上限数なしの範囲で存在する。

なお、ゲートクラス９１１を実体化したオブジェクトを複数個とせずに１個とし、複合機１の操作系サブシステム２０１からのログイン要求についての処理を一括して管理する。また、被認証者クラス９３４を実体化したオブジェクト数が０個とは、複合機１に対して利用者がログインしていない状態を示しており、また、かかるオブジェクト数の上限数は規定していないものの、当然に、ハードウェア仕様などによる制限を受けるものとする。

次に、被認証者クラス９３４と身分証クラス９３３との関係について説明する。被認証者クラス９３４は、認証方法毎に複数の身分証クラス９３３を保持し、身分証クラス９３３毎にチケットの発行を要求することができる。このため、被認証者クラス９３４と、身分証クラス９３３は、「保持者」と「身元証明」という関係をなしている。

また、被認証者オブジェクト９３４Ａは、ログイン要求を受け付けた利用者毎に生成される。そして、１個の被認証者オブジェクト９３４Ａは、認証方法毎に１以上複数の身分証オブジェクト９３３Ａを管理する。つまり、身分証オブジェクト９３３Ａは、１個の被認証者オブジェクト９３４Ａに対して１個以上ｎ個以下の範囲で存在する。なお、１個以上としたのはログイン要求時に被認証者オブジェクト９３４Ａと共に身分証オブジェクト９３３Ａが生成されるためである。身分証オブジェクト９３３Ａが１個以上生成される例としては、利用者がユーザコードでログインした後、さらにキーカウンターを複合機１に差し込んだ場合等が考えられる。

次に、ゲートクラス９１１とチケット発行所クラス９２１との関係について説明する。ゲートクラス９１１は、ゲートからログインした利用者に対して機能を使用するためにチケットを発行するチケット発行所クラス９２１まで案内する。また、チケット発行所クラス９２１は、ゲート内部に０又は１つ設置されている。このため、ゲートクラス９１１と、チケット発行所クラス９２１は、「案内元」と「案内先」という関係をなしている。なお、上述したように、ゲートクラス９１１とチケット発行所クラス９２１との間には依存関係が成立している。

また、ゲートクラス９１１から生成されたオブジェクトは、複合機１内部に１個だけ存在し、チケット発行所オブジェクト９２１Ａはゲートオブジェクト９１１Ａの案内先として０又は１個だけ存在する。なお、チケット発行所オブジェクト９２１Ａが０個の場合とは、例えばチケットが発行されなくても利用者が機能を使用することが出来る場合とする。

次に、身分証クラス９３３とチケット発行所クラス９２１との関係について説明する。チケット発行所クラス９２１は、身元が確認できた身分証クラス９３３毎にチケットを発行する。このため、身分証クラス９３３と、チケット発行所クラス９２１は、「証明証」と「証明場所」という関係をなしている。

また、チケット発行所オブジェクト９２１Ａは、複合機１の内部に０又は１個だけ存在し、身分証オブジェクト９３３Ａは、複合機１にログインした複数の利用者毎が複数保持することが出来る。つまり、チケット発行所オブジェクト９２１Ａは、１個の身分証オブジェクト９３３Ａに対して０又は１個の範囲で存在する。これに対して、身分証オブジェクト９３３Ａは、１個のチケット発行所オブジェクト９２１Ａに対して、０個以上ｎ個以下の範囲で存在する。

次に、チケット発行所クラス９２１と、アカウントクラス９２２との関係について説明する。チケット発行所クラス９２１は、利用者毎の身元の確認を可能にするために、アカウントクラス９２２を各利用者の身元の確認方法毎に保持している。このため、チケット発行所クラス９２１と、アカウントクラス９２２は、「保管場所」と「保管物」という関係をなしている。

また、チケット発行所オブジェクト９２１Ａは、複合機１の内部に０又は１個だけ存在し、アカウントオブジェクト９２２Ａは、身元の確認方法として複数保持されている。つまり、チケット発行所オブジェクト９２１Ａは、１個のアカウントオブジェクト９２２Ａに対して１個存在する。これに対して、アカウントオブジェクト９２２Ａは、１個のチケット発行所オブジェクト９２１Ａに対して０個以上ｎ個以下の範囲で存在する。

次に、身分証クラス９３３とチケットクラス９３５との関係について説明する。身分証クラス９３３は、利用者が行った身元の確認方法毎に生成されている。チケットクラス９３５は身分証クラス９３３で利用者が使用することが可能な機能毎に生成される。このため、身分証クラス９３３と、チケットクラス９３５は、「利用者」と「利用権」という関係をなしている。

また、身分証オブジェクト９３３Ａは、利用者が行った身元確認方法毎に存在し、チケットオブジェクト９３５Ａは、身元確認方法により使用することが認められる機能毎に生成される。つまり、身分証オブジェクト９３３Ａは、１個のチケットオブジェクト９３５Ａに対して１個存在する。これに対して、チケットオブジェクト９３５Ａは、１個の身分証オブジェクト９３３Ａに対して０個以上ｎ個以下の範囲で存在する。

このように、ゲートクラス９１１、被認証者クラス９３４、身分証クラス９３３、チケット発行所クラス９２１、アカウントクラス９２２及びチケットクラス９３５の各オブジェクトは、相互に関連し合い、協調することにより認証管理部２１１に必要な機能を実現することが可能となる。

次に、図９に示した各クラスの操作の実行手順について例をあげて説明する。図１３は、認証管理部２１１が利用者からのログインの要求を受け付けた際にチケットを発行するまでの操作の実行手順を示すＵＭＬシーケンス図である。

ここで、ＵＭＬシーケンス図について説明しておく。図１３の上部に並んだ矩形は、それぞれがクラスのオブジェクトを示している。各オブジェクトから下方に伸びた線は、各オブジェクトが生存していることを示す線（ライフライン）であり、上方から下方に向かって時間が流れているものとみなされる。この線上に存在する細長い矩形は、当該のオブジェクトが実際に活動している期間（活性期間）を示す。

各ライフラインの間を結ぶ横向きの矢印は、オブジェクトに含まれる操作の実行を示す。具体的には、この矢印は、矢印の元のオブジェクトが、矢印の先のオブジェクトに含まれる操作を呼び出すことを示す。また、矢印が自分自身のオブジェクトを指している場合は、オブジェクトが自分に含まれる操作を自身で呼び出すことを意味する。

図１３に示すように、利用者が複合機１を操作して、ログイン要求として利用者名及び認証情報を入力する。入力される利用者名及び認証情報は、利用者が行った身元の確認方法毎に異なる。例えば身元の確認方法毎がユーザコードの場合は、利用者名としてユーザコード、認証情報としてパスワードとなる（ステップＳ１３０１）。そして、操作系サブシステム２０１がゲートオブジェクト９１１Ａの入る（）９１１ｄを呼び出して、利用者のログインを要求する（ステップＳ１３０２）。そして、ゲートオブジェクト９１１Ａは、ログイン要求を受け付けた場合、最大認証者数９１１ａを超えるか否か判断する（ステップＳ１３０３）。最大認証者数９１１ａを超えないと判断した場合に、ゲートオブジェクト９１１Ａは、ログイン要求を行った利用者に対応付けて被認証者オブジェクト９３４Ａを生成する。また、生成は、すべてのオブジェクトが有する操作であり、生成することで各オブジェクトはＲＡＭ１２ｂ上に実体化される。また、最大認証者数９１１ａを超えると判断した場合は、ログイン要求を受けられないため処理を終了する。

被認証者オブジェクト９３４Ａを生成した場合、ゲートオブジェクト９１１Ａは、被認証者オブジェクト９３４Ａの認証を行う（）９３４ｃを呼び出して、ログインを要求した利用者の認証を要求する（ステップＳ１３０４）。この際、利用者名、認証情報、及び身元の確認方法などが引数として受け渡される。そして、受け渡された利用者名が、被認証者オブジェクト９３４Ａの利用者名９３４ａに設定される。

次に、被認証者オブジェクト９３４Ａは、利用者の認証を要求された場合、身分証オブジェクト９３３Ａを生成し、生成された身分証オブジェクト９３３Ａの身元確認する（）９３３ｃを呼び出し、利用者の身元の確認を要求する（ステップＳ１３０５）。この際、認証情報、身元の確認方法及び利用者名などが引数として受け渡される。そして、受け渡された身元の確認方法に対応した身分種類が身分証オブジェクト９３３Ａの身分種類９３３ａに設定され、受け渡された認証情報が認証情報９３３ｂに設定される。なお、身分証オブジェクト９３３Ａは、受け渡された身元の確認方法毎に生成される。

次に、身分証オブジェクト９３３Ａは、身元の確認が要求された場合、チケットオブジェクト９３５Ａの発行を要求する（）９２１ａを呼び出して、身分証オブジェクト９３３Ａに対応したチケットの発行を要求する（ステップＳ１３０６）。この際、利用者名、認証情報、身分種類が引数として受け渡される。

そして、チケット発行所オブジェクト９２１Ａは、チケットの発行を受け付けた場合、引数として受け渡された利用者名等の情報に対応したアカウントオブジェクト９２２Ａに対して、照合する（）９２２ｃを呼び出して、利用者が機能を使用することが出来るか否か照合を要求する（ステップＳ１３０７）。この際、利用者名、認証情報が引数として受け渡される。

次に、アカウントオブジェクト９２２Ａは、照合を要求された場合、受け渡された利用者名及び認証情報と、属性として有する利用者名９２２ａ及び識別情報９２２ｂとを比較し一致するか否か照合を行う（ステップＳ１３０８）。一致した場合は、身元が確認できた旨をチケット発行所オブジェクト９２１Ａに送信する。一致しなかった場合は、チケットを発行せずに終了する。

そして、身元が確認できた旨を受信したチケット発行所オブジェクト９２１Ａは、ゲートオブジェクト９１１Ａの機能を呼び出して、受け取った身分種類で使用することができる機能を特定する（ステップＳ１３０９）。そして、チケット発行所オブジェクト９２１Ａは、特定した機能毎にチケットオブジェクト９３５Ａを生成し、特定した機能に応じた機能種類９３５ａを設定する（ステップＳ１３１０）。

そして、チケット発行所オブジェクト９２１Ａは、チケットオブジェクト９３５Ａを生成した後に、身分証オブジェクト９３３Ａのチケットを受け取る（）９３３ｄを呼び出して、生成されたチケットオブジェクト９３５Ａと、チケットの発行の要求を行った身分証オブジェクト９３３Ａを対応付ける（ステップＳ１３１１）。そして、身分証オブジェクト９３３Ａに対応したチケットオブジェクト９３５Ａが発行されたものとして、処理を終了する。

上述したシーケンス図で示したように、本実施の形態では、利用者からログインを要求を受け付けた際の処理を行うにあたり、ゲートクラス９１１と、被認証者クラス９３４と、身分証クラス９３３と、チケット発行所クラス９２１と、アカウントクラス９２２と、チケットクラス９３５とから構成され、各クラスから生成されたオブジェクトでログイン要求からチケットの発行まで処理することで、ログイン要求を行った利用者が保持する身元の確認方法毎に適した機能の使用が許可されることになり、信頼性が向上する。また、オブジェクト指向設計により、かかる認証管理部２１１の仕組みを構築し、図７で示したような概念に基づいてオブジェクトモデリングをおこない、ログイン要求に必要なクラスとしてゲートクラス９１１と、被認証者クラス９３４と、身分証クラス９３３と、チケット発行所クラス９２１と、アカウントクラス９２２と、チケットクラス９３５を用いることで、かかる認証管理部２１１を実現したので、ソフトウェア開発者やソフトウェア保守要員が、認証管理部の構成と役割を容易に把握することができるとともに、汎用性及び信頼性の高い利用者の認証処理をおこなうことができる。

次に、図８に示した各クラスの操作の実行手順についてもう一つの例をあげて説明する。図１４は、認証管理部２１１が利用者から機能の実行の要求を受け付けた際の操作の実行手順を示すＵＭＬシーケンス図である。

図１４に示すように、利用者が複合機１を操作して、複合機１が有する所定の機能を実行する入力を行うと、操作系サブシステム２０１が所定の機能を利用する要求を受け付ける（ステップＳ１４０１）。そして操作系サブシステム２０１がゲートオブジェクト９１１Ａの入場者を確認する（）９１１ｅを呼び出して、機能を利用する要求と共に機能の利用を要求した利用者が機能を使用する権利があるか確認を要求する（ステップＳ１４０２）。なお、入場者を確認する（）９１１ｅの引数として、利用者が利用を要求した機能の情報や、入力を行った入力装置を特定する情報を受け渡す必要がある。

そして、ゲートオブジェクト９１１Ａは、被認証者オブジェクト９３４Ａに対して、認証状態を確認する（）９３４ｄを呼び出して、利用者の認証状態の確認を要求する（ステップＳ１４０３）。なお、認証情報を確認する（）９３４ｃの引数として、利用者が利用を要求した機能の情報や、入力を行った入力装置を特定する情報を受け渡す必要がある。

次に、被認証者オブジェクト９３４Ａは、認証状態の確認を要求された場合、設定された状態９３４ｂを用いて機能の使用を要求した利用者が本物か否か確認する（ステップＳ１４０４）。利用者が本物と確認できなかった場合は、処理を終了する。

そして、被認証者オブジェクト９３４Ａは、利用者が本物だと確認した場合、身分証オブジェクト９３３Ａの権利を確認する（）９３３ｅを呼び出して、利用者が機能を利用する権利があるかどうか確認を要求する（ステップＳ１４０５）。また、身分証オブジェクト９３３Ａが複数存在する場合、それぞれに対して確認を要求する。なお、権利を確認する（）９３３ｅの引数として、利用者が利用を要求した機能の情報を受け渡す必要がある。

そして、身分証オブジェクト９３３Ａが、チケットオブジェクト９３５Ａの有効かどうか判断する（）９３５ｃを呼び出して、チケットが有効かどうか確認を要求する（ステップＳ１４０６）。また、チケットオブジェクト９３５Ａが複数存在する場合、それぞれに対して確認を要求する。

次に、チケットオブジェクト９３５Ａは、利用者が利用を要求した機能と機能種類９３５ａが一致するか否か確認する（ステップＳ１４０７）。そして、有効期限９３５ｂを経過しているか否か確認する（ステップＳ１４０８）。チケットオブジェクト９３５Ａは、機能が一致しない場合または現在すでに有効期限９３５ｂを経過している場合に、有効で無い旨を身分証オブジェクト９３３Ａに送信する。また、チケットオブジェクト９３５Ａは、機能が一致し且つ現在既に有効期限９３５ｂを経過していない場合に有効である旨を身分証オブジェクト９３３Ａに送信する。

そして、身分証オブジェクト９３３Ａは、有効である旨を受信した場合に権利を有している旨を被認証者オブジェクト９３４Ａに送信し、有効で無い旨を受信した場合に権利を有していない旨を被認証者オブジェクト９３４Ａに送信する。

次に、被認証者オブジェクト９３４Ａは、身分証オブジェクト９３３Ａから権利を有している旨を受信した場合は、ゲートオブジェクト９１１Ａに対して、機能を利用できる状態である旨を送信する。権利を有している旨を受信できなかった場合は、機能を使用する権利が無かったものとして処理を終了する。なお、複数の身分証オブジェクト９３３Ａが生成されていた場合は、いずれか１つから権利を有している旨を受信していればよい。

そして、ゲートオブジェクト９１１Ａは、被認証者オブジェクト９３４Ａから機能を利用できる状態である旨を受信した場合、操作系サブシステム２０１に対して、利用者が要求した機能を実行できる旨を送信する（ステップＳ１４０９）。そして、操作系サブシステム２０１は、利用確認要求処理が終了したとして、実行系サブシステム２０３に対して機能の実行を要求する。

上述したシーケンス図で示したように、本実施の形態では、機能を使用する要求があった場合の処理にあたり、ゲートクラス９１１と、被認証者クラス９３４と、身分証クラス９３３と、チケットクラス９３５とから構成され、各クラスから生成されたオブジェクトで機能の利用の要求を受け付けてから、利用者が機能を利用する権利を有しているか否か確認し、権利を有している場合に実行系サブシステム２０３に機能を実行する旨を送信する。これにより身元を確認するために生成された身分証オブジェクト９３３Ａに対応付けられたチケットオブジェクト９３５Ａを用いて、利用者が機能を使用できるか否か確認できるので、複数の身元確認方法に応じて機能の実行を制御できるので、信頼性が向上する。また、オブジェクト指向設計により、かかる認証管理部の仕組みを構築し、図７で示したような概念に基づいてオブジェクトモデリングをおこない、機能を実行できる権利を有するか確認するために必要なクラスとしてゲートクラス９１１と、被認証者クラス９３４と、身分証クラス９３３と、チケットクラス９３５を用いることで、かかる認証管理部２１１を実現したので、ソフトウェア開発者やソフトウェア保守要員が、認証管理部の構成と役割を容易に把握することができるとともに、汎用性及び信頼性の高い利用者の認証処理をおこなうことができる。

なお、本実施の形態の画像形成装置で実行される認証管理プログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録して提供するよう構成してもよい。この場合、ＣＰＵ１１が上記記憶媒体から、認証管理プログラムを読み出してＭＥＭ−Ｐ１２上にロードすることで、画像形成装置に、上述した各ステップ、各手段または各部を実現させる。

また、認証管理プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するよう構成してもよい。さらに、かかる認証管理プログラムをインターネットなどのネットワーク経由で提供または配布するようにしてもよい。

上述した構成は、本発明の利用者認証装置の一例を示したものであり、上述した構成に制限するものではない。

そして、本実施の形態の認証管理部２１１は、オブジェクト毎に分割して設計し、上述した構成を備えることとした。これにより変更が生じた場合そのクラス等のみ変更を加えればよい。このため、従来は要件が増えた場合には設計者の作業量もこれに比例していたが、上述した構成を備えたことで作業量が低減される。

また、従来の認証管理を行う部分は、アプリケーション毎に設計されていたが、上述した構成を備えたことでアプリケーション毎という概念が無くなったため、設計の効率が向上した。さらにアプリケーション毎に利用者の認証を行う場合では、同一システムに同一利用者がアプリケーション毎に認証されることとなり、あるアプリケーションを使用している際には、他の利用者がログインした利用者になりすましてシステムを使用できるという問題があった。しかし、本実施の形態にかかる認証管理部２１１は、上述した構成を備えることでアプリケーション毎という概念が無くなったため、なりすまして使用できるという問題を解消し、信頼性が向上した。

上述した構成を備えることで、アプリケーションに相当する機能が追加された場合でも、新たに認証を行う部分を設計する必要なく、ゲートクラス９１１の制限範囲９１１ｂと入場方法９１１ｃ、及びチケットクラス９３５の機能種類９３５ａに追加するだけで認証の際の対応が可能となる。これにより新機能追加した場合の作業量が低減することとなる。

この認証管理部２１１の備えた構造は、実社会において、複数の施設が設置された広場に利用者がゲートから入場し、チケット発行所に利用者本人であることの証明するための身分証を提示することで、発行されたチケットを受け取り、さらにチケットを提示することで施設を利用することが出来る規則に類似している。また、この身分証及びチケットという概念は実社会状長く使用されているため、認証管理でも安定した構造で利用者の機能の利用を管理することができる。また、設計者または利用者は、身分証及びチケットの概念を直感的に把握できるため、設計または使用するまでの認識が容易になる。

以上のように、本発明にかかる利用者認証装置、画像形成装置、利用者認証方法及び利用者認証プログラムは、利用者の認証処理に有用であり、特に、ログインした利用者が機能を利用する権利を有するか否か判断する技術に適している。

実施の形態に係る複合機を取り巻くネットワーク環境を説明するためのネットワーク図である。 実施の形態に係る複合機のハードウェア構成を示すブロック図である。 実施の形態に係る複合機のソフトウェアとハードウェアの関係を説明するための概念図である。 実施の形態に係る複合機の操作パネルの一例を示した図である。 実施の形態に係る複合機の統合アプリケーションの内部構成、及び統合アプリケーション内における認証管理部の位置を示す説明図である。 実施の形態に係る複合機の統合アプリケーションの内部構成として示した各サブシステムについてのＵＭＬクラス図である。 複合機が有する認証管理部で行われる処理の概念を示した概念図である。 複合機が有する認証管理部で行われる処理として利用者が複数保持した身分証のうち任意の身分証を提示した場合にチケットが発行されるまでの処理の概念を示した概念図である。 オブジェクトモデリングにより設計された実施の形態に係る複合機の認証管理部のブロック構成、及びＵＭＬのクラス構成を示した図である。 実施の形態に係る複合機が有する認証管理部のゲートクラスが保持する制限範囲と入場方法との対応関係を示した図である。 実施の形態に係る複合機の液晶タッチパネル上に表示される利用者のログイン画面の一例を示した図である。 利用者が実行を要求した機能を使用する権利がない場合に液晶タッチパネル上に表示される画面の一例を示した図である。 実施の形態に係る複合機の認証管理部が利用者からのログインの要求を受け付けた際にチケットを発行するまでの操作の実行手順を示すＵＭＬシーケンス図である。 実施の形態に係る複合機の認証管理部が利用者から機能の実行の要求を受け付けた際の操作の実行手順を示すＵＭＬシーケンス図である。 複合機に搭載されるソフトウェア構成の変遷を説明するための説明図である。 従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。

符号の説明

１ 複合機
１０ コントローラ
１１ ＣＰＵ
１２ システムメモリ（ＭＥＭ−Ｐ）
１２ａ ＲＯＭ
１２ｂ ＲＡＭ
１３ ノースブリッジ（ＮＢ）
１４ サウスブリッジ（ＳＢ）
１５ ＡＧＰバス
１６ ＡＳＩＣ
１７ ローカルメモリ（ＭＥＭ−Ｃ）
１８ ハードディスクドライブ（ＨＤＤ）
２０ キーボード
３０ ＦＣＵ
４０ ＵＳＢ
５０ ＩＥＥＥ１３９４インターフェース
６０ エンジン部
１００ ソフトウェア
１０１、１０１Ａ アプリケーション層
１０２ サービス層
１０２ａ スキャナ制御部
１０２ｂ プロッタ制御部
１０２ｃ 蓄積制御部
１０２ｄ 配信／メール送受信制御部
１０２ｅ ＦＡＸ送受信制御部
１０２ｆ ネットワーク通信制御部
１０２ｇ その他の制御部
１０３ オペレーティングシステム
１１０ 統合アプリケーション
１２１ コピーアプリケーション
１２２ スキャナアプリケーション
１２３ ファックスアプリケーション
１２４ プリンタアプリケーション
１５０ ハードウェア
１５１ ハードウェアリソース
１５１ａ スキャナ
１５１ｂ プロッタ
１５１ｃ ＨＤＤ
１５１ｄ ネットワーク
１５１ｅ その他のリソース
２０１ 操作系サブシステム
２０２ 管理系サブシステム
２０３ 実行系サブシステム
２１１ 認証管理部
４００ 操作パネル
４０１ 初期設定キー
４０２ コピーキー
４０３ コピーサーバーキー
４０４ プリンタキー
４０５ 送信キー
４０６ テンキー
４０７ クリア／ストップキー
４０８ スタートキー
４０９ 予熱キー
４１０ リセットキー
４２０ 液晶タッチパネル
９１０ 機能制限部
９１１ ゲートクラス
９１１ａ 最大認証者数
９１１ｂ 制限範囲
９１１ｃ 入場方法
９１１ｄ 入る（）
９１１ｅ 入場者を確認する
９１１Ａ ゲートオブジェクト
９２０ 登録情報管理部
９２１ チケット発行所クラス
９２１ａ 発行を要求する
９２１Ａ チケット発行所オブジェクト
９２２ アカウントクラス
９２２ａ 利用者名
９２２ｂ 識別情報
９２２ｃ 照合する（）
９２２Ａ アカウントオブジェクト
９３０ 利用者機能管理部
９３１ 利用者証明管理部
９３２ 利用可能機能管理部
９３３ 身分証クラス
９３３ａ 身分種類
９３３ｂ 認証情報
９３３ｃ 身元確認する（）
９３３ｄ チケットを受け取る（）
９３３ｅ 権利を確認する（）
９３３Ａ 身分証オブジェクト
９３４ 被認証者クラス
９３４ａ 利用者名
９３４ｂ 状態
９３４ｃ 認証を行う（）
９３４ｄ 認証状態を確認する（）
９３４Ａ 被認証者オブジェクト
９３５ チケットクラス
９３５ａ 機能種類
９３５ｂ 有効期限
９３５ｃ 有効かどうか判断する（）
９３５Ａ チケットオブジェクト
１１０２ ‘ログイン’ボタン
１５０１ サービス層分離前アプリケーション
１５０２ サービス層分離後アプリケーション
１５０３ 共通ルーチン分離アプリケーション
１５０４ オブジェクト指向アプリケーション

Claims (13)

1. 機能の使用を要求した利用者毎に対応して生成される被認証者オブジェクトと、
   前記利用者の個人証明の照合に用いる認証情報を管理し、前記被認証者オブジェクトに対応付けて生成される複数個保持可能な身分証オブジェクトと、
   前記身分証オブジェクトが管理する前記認証情報を用いた前記個人証明の照合で、機能を使用できる利用者であることを確認された際、当該身分証オブジェクトと対応付けられた前記機能が複数存在する場合、当該機能毎に生成される、当該機能の使用が許可されたことを示す前記複数のチケットオブジェクトと、
   を備えたことを特徴とする利用者認証装置。
2. 前記チケットオブジェクトを生成する要求を受け付けた際、前記身分証オブジェクトが管理する前記認証情報を用いて前記個人証明の照合を行い、前記機能を使用できる利用者であること確認された際、前記身分証オブジェクトと対応付けられた前記機能毎に、前記チケットオブジェクトを生成する利用者情報管理手段と、をさらに備え、
   前記身分証オブジェクトは、さらに前記利用者情報管理手段に対して、前記チケットオブジェクトの生成を要求すること
   を特徴とする請求項１に記載の利用者認証装置。
3. 前記利用者情報管理手段は、
   前記機能を使用できる前記利用者であることを示す識別情報を管理し、前記身分証オブジェクトが管理する前記認証情報と該識別情報を用いて、前記機能を使用できる前記利用者の照合を行うアカウントオブジェクトと、
   前記身分証オブジェクトから前記チケットオブジェクトを生成する要求を受け付けて前記アカウントオブジェクトにより前記機能を使用できる前記利用者であることが確認された場合に前記チケットオブジェクトを生成する発行オブジェクトと、
   を備えたことを特徴とする請求項２に記載の利用者認証装置。
4. 前記身分証オブジェクトで示される前記個人証明で実行可能な前記機能を管理する機能制限手段と、を備え、
   前記利用者情報管理手段は、前記身分証オブジェクトから前記チケットオブジェクトを生成する要求を受け付けた際、前記身分証オブジェクトが管理する前記認証情報を用いて前記個人証明の照合を行い、前記機能を使用できる前記利用者である場合に、前記機能制限手段が管理している、前記身分証オブジェクトと対応付けられた前記機能毎に、前記チケットオブジェクトを生成すること
   を特徴とする請求項２又は３に記載の利用者認証装置。
5. 前記機能制限手段は、さらに前記被認証者オブジェクトが予め定められた最大認証者数以上生成されていた場合に、前記被認証者オブジェクトの生成を制限することを特徴とする請求項２乃至４のいずれか一つに記載の利用者認証装置。
6. 前記身分証オブジェクトは、前記機能を使用する要求を受け付け、前記機能を使用する要求を受け付けた場合に、前記機能に対応する前記チケットオブジェクトが生成されているか否か判断し、前記チケットオブジェクトが生成されている場合に前記機能を使用することが可能であることを出力することを特徴とする請求項１乃至５のいずれか１つに記載の利用者認証装置。
7. 前記チケットオブジェクトは、前記機能を使用できる期間を示す有効期限を管理し、前記機能の使用が有効であるか否かの確認を受け付けた際、前記有効期限を経過しているか否か判断し、前記有効期限を経過していない場合に前記機能の使用が許可されている旨を出力し、
   前記身分証オブジェクトは、前記機能を使用する要求を受け付け、前記機能に対応する前記チケットオブジェクトが生成されている場合に、前記チケットオブジェクトに対して前記機能を使用する許可が有効であるか否かの確認を行うことを特徴とする請求項１乃至６のいずれか１つに記載の利用者認証装置。
8. 機能の使用を要求した利用者毎に対応して生成される被認証者オブジェクトと、
   前記利用者の個人証明の照合に用いる認証情報を管理し、前記被認証者オブジェクトに対応付けて生成される複数個保持可能な身分証オブジェクトと、
   前記身分証オブジェクトが管理する前記認証情報を用いた前記個人証明の照合で、機能を使用できる利用者であることを確認された際、当該身分証オブジェクトと対応付けられた前記機能が複数存在する場合に、当該機能毎に生成される、当該機能の使用が許可されたことを示す前記複数のチケットオブジェクトと、
   を備えたことを特徴とする画像形成装置。
9. 機能の使用を要求した利用者を示す被認証者オブジェクトを生成する利用者生成ステップと、
   前記利用者生成ステップで生成された前記被認証者オブジェクトで示される前記利用者の個人証明の照合に用いる認証情報を保持する身分証オブジェクトを生成する個人証明情報生成ステップと、
   前記個人証明情報生成ステップで生成された前記身分証オブジェクトが保持する前記認証情報を用いて前記利用者の前記個人証明の照合を行い、機能を使用できる利用者であることを確認された際、当該身分証オブジェクトと対応付けられた前記機能が複数存在する場合、当該身分証オブジェクトと対応付けられた前記機能毎に、当該機能の使用が許可されたことを示すチケットオブジェクトを生成する許可情報生成ステップと、
   を有することを特徴とする利用者認証方法。
10. 利用者から前記機能を使用する要求を受け付けた場合、要求として受け付けた前記機能に対応した前記チケットオブジェクトが前記許可情報生成ステップで生成されているか否か確認し、生成されていた場合に前記機能の使用を許可する確認ステップ、をさらに有することを特徴とする請求項９に記載の利用者認証方法。
11. 前記許可情報が保持する有効期限より、前記機能の使用の許可が有効か否か判断する判断ステップ、をさらに有することを特徴とする請求項１０に記載の利用者認証方法。
12. 前記利用者生成ステップは、予め定められた最大認証者数以上の前記利用者情報が生成されていた場合、前記利用者情報の生成を行わないことを特徴とする請求項９乃至１１のいずれか１つに記載の利用者認証方法。
13. 請求項９乃至１２のいずれか一つに記載された利用者認証方法をコンピュータで実行させることを特徴とする利用者認証プログラム。

Images