JP4663245B2 - 電子装置、画像処理装置、遠隔管理システム、プログラム及び認証方法 - Google Patents

Description

この発明は、操作や要求に伴う認証方式に特徴を有する電子装置および画像処理装置、上記のような電子装置に通信機能を設けた通信装置と管理装置とをネットワークによって接続して構成する遠隔管理システム、上記のような電子装置を制御するコンピュータに必要な機能（この発明に係わる機能）を実現させるためのプログラム、ならびに上記のような電子装置による認証方法に関する。

従来から、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始めとする電子装置において、管理情報や機密情報等へのアクセスを制限したり、装置の使用を制限したりするため、パスワード等によって認証を行い、アクセス権限を有すると認めた者のみにアクセスを許可することが行われている（特許文献１及び２参照）。このようにすることにより、無権限者による重要な情報へのアクセスや装置の使用を防止し、セキュリティの向上を図ることができる。
特開平６−４６１９０号公報（特に明細書の００６０段落） 特開平７−５８８６６号公報

また、このような電子装置に通信機能を持たせて通信装置とし、コンピュータ等の制御装置と接続してこれらの装置を制御することが行われている。
例えば画像処理装置の場合には、顧客のオフィス等に設置した装置をサービスセンタ内の監視端末装置と公衆回線によって通信可能にし、その監視端末装置によって顧客先の装置の状態を監視する監視システムが知られている。（特許文献３参照）
特開平６−２３７３３０号公報

さらに、近年のネットワーク技術の進歩に伴い、このような監視システムを、ＬＡＮ（ローカルエリアネットワーク）やインタネット等のネットワークを活用して装置の状態を管理する管理システムとして構成することが試みられ、このような技術について本件出願人は過去に特許出願を行っている（特願２００２−２７６５２４，特願２００２−３２９７６３等）。

ところで、上述のような電子装置において認証を行う場合、ユーザがこの認証に必要なパスワード等の認証情報を入力するためのインタフェースとしては、装置に備えた操作部の他、ネットワークに接続されたコンピュータ等も考えられる。また、操作部であっても、タッチパネル式やリモコン式等、様々な形態が考えられる。そして、このような複数のユーザインタフェースから指示を行うことができることはもはや当然の要求となっている。また、同じネットワークを介して指示を行う場合でも、携帯端末とＰＣ（パーソナルコンピュータ）とでは画面のサイズが異なり、表示できる内容が異なるので、これに対応してユーザインタフェースの多様化が進んでいる。さらに、このような電子装置を管理システムの被管理装置とする場合には、管理装置の認証を行うため、管理装置からも認証情報の入力を受け付ける必要がある。

従来は、このように複数のインタフェースから認証情報を受け付けることが可能な場合においても、各インタフェースから受け付ける認証情報を用いる認証処理は、そのインタフェースの制御手段が行っていた。例えば、操作部からある機能の使用権限を認証するためのパスワードの入力を受け付けた場合、操作部制御手段が認証処理を行い、その機能を提供するための制御部にその認証結果を伝える等である。また、操作部制御手段における認証が成功した場合のみ、対象の機能に関する指示を受け付けるための画面を操作部に設けた操作パネルに表示させることにより、その機能の使用を許可する、等の制御も行われていた。

このような制御は、認証情報の入力を受け付けるインタフェースが１つである場合には特に問題を生じなかった。しかし、入力を受け付けるインタフェースが複数になった場合には、認証機能及びこれを実行するためのプログラム等をインタフェース毎に設ける必要が生じ、処理が複雑になり、処理負荷が大きくなると共に、開発に要する労力も大きく、コストアップにつながるという問題があった。また、認証条件を変更する場合等も、全てのインタフェースについて再設計が必要となり、労力とコストがかかるという問題もあった。

この発明は、このような問題を解決し、入力された認証情報による認証処理を行う電子装置において、認証処理に要する処理負荷を低減し、また装置の設計・開発にかかる労力やコストを低減することを目的とする。

上記の目的を達成するため、この発明の電子装置は、操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを設け、認証情報の入力を受け付ける認証情報受付手段として、上記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手段と、上記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手段とを設け、上記第１の認証情報受付手段から受け付けた上記第１の認証情報についての認証処理及び上記第２の認証情報受付手段から受け付けた上記第２の認証情報についての認証処理を行う認証手段を設け、上記認証手段が上記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と上記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、その認証処理によって認証した相手に対して上記認証手段がアクセスを許可する情報の範囲が異なるようにしたものである。
このような電子装置において、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、上記ハードウェア資源と上記各アプリケーション制御手段との間に介在し、複数の上記アプリケーション制御手段からの上記ハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段とを設け、上記認証手段を上記サービス制御手段に設けるとよい。

さらに、上記認証手段を、上記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、上記ネットワーク通信手段を介して受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う手段とするとよい。

さらに、上記認証手段に、上記第１の認証情報による認証処理を行った場合にはその電子装置を設置しているユーザに公開すべき内部情報に対してアクセスを許可し、上記第２の認証情報による認証処理を行った場合には上記ネットワーク通信手段による通信先に公開すべき外部情報に対してアクセスを許可する手段を設けるとよい。
さらに、上記ネットワークを介して通信可能な管理装置から遠隔管理のための要求を受け付けてこれに対する応答を返す手段を設け、上記外部情報は、上記遠隔管理を行う管理者に公開すべき情報とするとよい。

さらにまた、管理用パスワードを記憶する手段を設け、上記認証手段に、その管理用パスワードを用いて上記第１の認証情報による認証処理を行った場合には上記内部情報に代えて上記外部情報に対してアクセスを許可する手段を設けるとよい。

また、この発明の画像処理装置は、操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段と、画像データを処理する画像処理手段とを設けた画像処理装置において、認証情報の入力を受け付ける認証情報受付手段として、上記操作部からパスワードの入力を受け付ける第１の認証情報受付手段と、上記ネットワーク通信手段によって公開鍵暗号を用いた認証処理に用いる認証情報の入力を受け付ける第２の認証情報受付手段とを設け、パスワードによる認証処理を行う手段と、公開鍵暗号を用いた認証処理を行う手段とを含む、上記操作部から入力を受け付けたパスワードによる認証処理を行った場合にはその画像処理装置を設置しているユーザに公開すべき内部情報に対してアクセスを許可し、上記ネットワーク通信手段によって入力を受け付けた認証情報によって公開鍵暗号を用いた認証処理を行った場合には上記ネットワーク通信手段による通信先に公開すべき外部情報に対してアクセスを許可する認証手段を設けたものである。
このような画像処理装置において、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、上記ハードウェア資源と上記各アプリケーション制御手段との間に介在し、複数の上記アプリケーション制御手段からの上記ハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段とを設け、上記認証手段を、上記サービス制御手段に設けるとよい。

さらに、上記画像処理手段によって画像データを処理した回数をカウントするカウント手段と、その手段によるカウント値、その画像処理装置の動作ログ、および上記画像データを記憶する手段とを設け、上記画像データを上記内部情報とし、上記カウント値及び上記動作ログを上記外部情報とするとよい。
あるいは、上記画像データを外部装置に送信する画像データ送信手段と、その画像処理装置の動作ログおよび上記画像データ送信手段による画像データの送信先情報を記憶する手段とを設け、上記送信先情報を上記内部情報とし、上記動作ログを上記外部情報とするとよい。

また、この発明の遠隔管理システムは、管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、上記各通信装置において、操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを設け、認証情報の入力を受け付ける認証情報受付手段として、上記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手段と、上記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手段とを設け、上記第１の認証情報受付手段から受け付けた上記第１の認証情報についての認証処理及び上記第２の認証情報受付手段から受け付けた上記第２の認証情報についての認証処理を行う認証手段を設け、上記認証手段が上記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と上記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、その認証処理によって認証した相手に対して上記認証手段がアクセスを許可する情報の範囲が異なるようにしたものである。
このような遠隔管理システムにおいて、上記通信装置に、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、上記ハードウェア資源と上記各アプリケーション制御手段との間に介在し、複数の上記アプリケーション制御手段からの上記ハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段とを設け、その通信装置において、上記認証手段を上記サービス制御手段に設けるとよい。

さらに、上記通信装置の上記認証手段を、上記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、上記ネットワーク通信手段を介して受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う手段とするとよい。

さらに、上記通信装置の上記認証手段に、上記第１の認証情報による認証処理を行った場合には上記通信装置を設置しているユーザに公開すべき内部情報に対してアクセスを許可し、上記第２の認証情報による認証処理を行った場合には上記管理装置による遠隔管理を行う管理者に公開すべき外部情報に対してアクセスを許可する手段を設けるとよい。

また、この発明のプログラムは、操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを有する電子装置を制御するコンピュータを、それぞれ認証情報の入力を受け付ける認証情報受付手段である、上記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手段及び上記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手段と、上記第１の認証情報受付手段から受け付けた上記第１の認証情報についての認証処理及び上記第２の認証情報受付手段から受け付けた上記第２の認証情報についての認証処理を行う認証手段として機能させるためのプログラムであって、上記認証手段が上記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と上記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、その認証処理によって認証した相手に対して上記認証手段がアクセスを許可する情報の範囲が異なることを特徴とするプログラムである。
このようなプログラムにおいて、上記コンピュータを、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、上記ハードウェア資源と上記各アプリケーション制御手段との間に介在し、複数の上記アプリケーション制御手段からの上記ハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段として機能させるためのプログラムを含め、上記認証手段の機能を、上記サービス制御手段の機能の一部として設けるとよい。

さらに、上記認証手段の機能を、上記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、上記ネットワーク通信手段を介して受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う機能とするとよい。

また、この発明の認証方法は、操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを有する電子装置における認証方法であって、上記電子装置に、それぞれ認証情報の入力を受け付ける認証情報受付手順である、上記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手順及び上記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手順と、上記第１の認証情報受付手順で受け付けた上記第１の認証情報についての認証処理及び上記第２の認証情報受付手順で受け付けた上記第２の認証情報についての認証処理を共通の認証手段によって行う認証手順とを実行させ、上記認証手順で上記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と上記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、その認証処理によって認証した相手に対して上記認証手段がアクセスを許可する情報の範囲を異なるものとさせるようにしたものである。
このような認証方法において、上記電子装置が、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、上記ハードウェア資源と上記各アプリケーション制御手段との間に介在し、複数の上記アプリケーション制御手段からの上記ハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段とを有する電子装置であり、上記認証手段が、上記サービス制御手段に設けられている認証手段であるとよい。

さらに、上記認証手順を、上記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、上記ネットワーク通信手段から受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う手順とするとよい。

以上のようなこの発明の電子装置、画像処理装置、遠隔管理システム、あるいは認証方法によれば、認証処理に要する処理体系をコンパクトにまとめ、また設計変更の際に改変すべき部分を最低限に抑えることができるので、認証処理に係る処理負荷を低減すると共に、装置の設計・開発にかかる労力やコストを低減することができる。
また、この発明のプログラムによれば、コンピュータに電子装置を制御させてこのような電子装置の特徴を実現し、同様な効果を得ることができる。

〔実施形態：図１乃至図１８〕
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明の電子装置の実施形態である画像処理装置と、その画像処理装置の通信相手となる外部装置とによって構成した通信システムの構成例について説明する。図１は、その通信システムの構成の一例を示す図である。

図１に示すように、この通信システムは、画像処理装置１００と外部装置１２０とを、ネットワーク１３０によって接続した構成である。ここで、画像処理装置１００は、ネットワークを介して外部装置と通信を行うネットワーク通信手段を有する通信装置であり、例えばプリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置等の機能を備えたデジタル複合機等の画像処理装置が考えられる。また、外部装置１２０としては、この画像処理装置１００をウェブブラウザ等を用いて制御するＰＣや、管理センタ等に配置され、多数の画像処理装置１００を集中的に遠隔管理するための管理装置等が考えられる。ネットワーク１３０としては、ＬＡＮ（ローカルエリアネットワーク）やインターネットあるいは公衆回線を始め、無線、有線を問わず種々の通信経路が考えられる。画像処理装置１００と外部装置１２０との間に通信を仲介する装置が介在していてもよい。また、複数の画像処理装置（電子装置）が共通の外部装置と通信可能な構成でもよい。

このような通信システムにおいて、画像処理装置１００と外部装置１２０とは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
すなわち、画像処理装置１００では、外部装置１２０への要求を生成してこれを外部装置１２０へ引き渡し、この要求に対する応答を取得できる一方で、外部装置１２０は、画像処理装置１００への要求を生成してこれを画像処理装置１００へ引き渡し、この要求に対する応答を取得できるようになっている。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ，ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。

次に、このような画像処理装置１００の物理的構成について図２を用いて説明する。
図２は、画像処理装置１００内の物理的構成の一例を示すブロック図である。同図に示すように、画像処理装置１００は、コントローラボード２００、ＨＤＤ（ハードディスクドライブ）２０１、ＮＶ−ＲＡＭ（不揮発性ＲＡＭ）２０２、ＰＩ（パーソナルインタフェース）ボード２０３、ＰＨＹ（物理メディアインタフェース）２０４、操作パネル２０５、プロッタ／スキャナエンジンボード２０６、電源ユニット２０７、フィニッシャ２０８、ＡＤＦ（自動原稿給送装置）２０９、給紙バンク２１０、その他周辺機２１１を備えている。これらのユニットは、それぞれがこの画像処理装置１００におけるハードウェア資源である。

ここで、コントローラボード２００は、制御手段に該当し、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備え、ＰＣＩ−ＢＵＳ（Peripheral Components Interconnect-Bus）２１２を介して各機能を制御している。また、ＨＤＤ２０１は、記憶手段に該当する。また、ＮＶ−ＲＡＭ２０２は、記憶手段に該当し、不揮発性メモリであって、例えば、フラッシュメモリ等が該当する。これらの記憶手段には、この画像処理装置１００の制御に使用する各種プログラムや、動作ログ、画像データ、後述する画像形成枚数のカウント値、画像データ送信手段による画像データの送信先情報を始め、認証処理に用いる照合用のパスワードや証明書、鍵、設定パラメータ等を含む、各種のデータを記憶する。

また、ＰＩボード２０３とＰＨＹ２０４は、ネットワーク通信手段に該当し、外部との通信を行うためのものであって、例えば、通信ボード等が該当する。ＰＩボード２０３はＲＳ４８５規格に準拠したインタフェースを備え、ラインアダプタを介して公衆回線に接続している。なお、上述したように、このＰＩボード２０３を用いて画像処理装置１００と仲介装置１０１とを接続することも可能である。ＰＨＹ２０４は、ＬＡＮを介して外部装置と通信を行うためのインタフェースである。これらのＰＩボード２０３とＰＨＹ２０４は、画像データを外部装置に送信する画像データ送信手段としても機能させることができる。

また、操作パネル２０５は、例えば多数のキー及びタッチパネルを積層した液晶ディスプレイによって構成され、操作部及び表示部に該当する。
プロッタ／スキャナエンジンボード２０６は、画像データに基づいて用紙に画像を形成する画像形成手段や、原稿の画像データを読み取る画像読取手段といった画像処理手段に該当する。さらに、この画像形成手段によって画像形成した用紙の枚数をカウントするカウント手段も備えている。また、画像処理手段によって画像データを処理した回数をカウントすることも考えられる。この場合、コピー回数やスキャン回数等をカウントすることになる。

ここで、同図中のＥＮＧＲＤＹは、エンジン側の各種初期設定が完了して、コントローラボード２００とコマンドの送受信の準備ができたことをコントローラボード２００側に通知するための信号線である。また、ＰＷＲＣＴＬは、エンジンへの電源供給をコントローラボード２００側から制御するための信号線である。これら信号線の動作に関しては後述する。次に、画像処理装置１００におけるソフトウェア構成を図３を用いて説明する。

図３は、画像処理装置１００のソフトウェア構成の一例を示すブロック図である。当該画像処理装置１００のソフトウェア構成は、最上位のアプリケーションモジュール（アプリ）層、その下位のサービスモジュール層からなる。そして、これらのソフトウェアを構成するプログラムはＨＤＤ２０１やコントローラボード２００上のＲＡＭに記憶され、必要に応じて読み出されてコントローラボード２００上のＣＰＵによって実行される。そしてＣＰＵは、これらのプログラムを必要に応じて実行することにより、この発明による各機能（アプリケーション制御手段，サービス制御手段，認証情報受付手段，認証手段，その他の手段としての機能）を実現することができる。

特に、アプリケーションモジュール層のソフトウェアは、ＣＰＵをハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段として機能させるためのプログラムによって構成され、サービスモジュール層のソフトウェアは、ＣＰＵを、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段として機能させるためのプログラムによって構成される。
またＯＳ３２０は、ＵＮＩＸ（登録商標）などのオペレーティングシステムであり、サービスモジュール層及びアプリケーションモジュール層の各プログラムをそれぞれプロセスとして並列実行する。

サービスモジュール層には、オペレーションコントロールサービス（ＯＣＳ）３００、エンジンコントロールサービス（ＥＣＳ）３０１、メモリコントロールサービス（ＭＣＳ）３０２、ネットワークコントロールサービス（ＮＣＳ）３０３、ファクスコントロールサービス（ＦＣＳ）３０４、カスタマーサポートシステム（ＣＳＳ）３０５、システムコントロールサービス（ＳＣＳ）３０６、システムリソースマネージャ（ＳＲＭ）３０７、イメージメモリハンドラ（ＩＭＨ）３０８、デリバリーコントロールサービス（ＤＣＳ）３１６、ユーザコントロールサービス（ＵＣＳ）３１７、データエンクリプションセキュリティサービス（ＤＥＳＳ）３１８、サーティフィカットコントロールサービス（ＣＣＳ）３１９を実装している。更に、アプリケーションモジュール層には、コピーアプリ３０９、ファクスアプリ３１０、プリンタアプリ３１１、スキャナアプリ３１２、ネットファイルアプリ３１３、ウェブアプリ３１４、ＮＲＳ（ニューリモートサービス）アプリ３１５を実装している。

これらを更に詳述する。
ＯＣＳ３００は、操作部２０９を制御するモジュールである。
ＥＣＳ３０１は、ハードウェアリソース等のエンジンを制御するモジュールである。
ＭＣＳ３０２は、メモリ制御をするモジュールであり、例えば、画像メモリの取得及び開放、ＨＤＤ２１０の利用等を行う。
ＮＣＳ３０３は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
ＦＣＳ３０４は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。

ＣＳＳ３０５は、公衆回線を介してデータを送受信する際のデータの変換等をするモジュールであり、また公衆回線を介した遠隔管理に関する機能をまとめたモジュールである。
ＳＣＳ３０６は、コマンドの内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理及び終了管理を行うモジュールである。
ＳＲＭ３０７は、システムの制御及びリソースの管理を行うモジュールである。
ＩＭＨ３０８は、一時的に画像データを入れておくメモリを管理するモジュールである。

ＤＣＳ３１６は、ＨＤＤ２０１やＮＶ−ＲＡＭ２０２等に記憶している（する）画像ファイル等をＳＭＴＰ（Simple Mail Transfer Protocol）やＦＴＰ（File Transfer Protocol）を用いて送受信するモジュールである。
ＵＣＳ３１７は、ユーザが登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
ＤＥＳＳ３１８は、ＰＫＩやＳＳＬを利用した各ユニットあるいは外部装置の認証や、通信の暗号化を行うモジュールである。
ＣＣＳ３１９は、この画像処理装置１００に入力された認証情報について認証処理を行うモジュールであり、この発明の特徴に係るモジュールであるが、詳細は後述する。

コピーアプリ３０９は、コピーサービスを実現するためのアプリケーションプログラムである。
ファクスアプリ３１０は、ファクスサービスを実現するためのアプリケーションプログラムである。
プリンタアプリ３１１は、プリンタサービスを実現するためのアプリケーションプログラムである。

スキャナアプリ３１２は、スキャナサービスを実現するためのアプリケーションプログラムである。
ネットファイルアプリ３１３は、ネットファイルサービスを実現するためのアプリケーションプログラムである。
ウェブアプリ３１４は、ウェブサービスを実現するためのアプリケーションプログラムである。
ＮＲＳアプリ３１５は、ネットワークを介してデータを送受信する際のデータの変換や、ネットワークを介した遠隔管理に関する機能（外部装置１２０との通信に係わる機能を含む）を実現するためのアプリケーションプログラムである。そして、外部装置からネットワーク経由で受信したデータを、各アプリにおける処理に適したデータ構造体に変換する機能も有する。詳細は後述する。
なお、説明の都合上、以下の説明において、ＣＰＵが以上のような各プログラムに従って動作することによって実行する処理について、それらのプログラムが処理を実行するものとして説明する。

ここで、上述したＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号との動作を図４を用いて説明する。
図４の（Ａ）は機器の立ち上がり時のＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号の動作の一例を示している。ＡＣ−ＰＯＷＥＲのＡＣ電源をＯＮにすると電源供給が開始され、これと同時にＥＮＧＲＤＹ信号はＨｉｇｈになる。この状態ではエンジン側との通信はできない。なぜなら、エンジン側の初期設定が完了していないからである。そして、一定期間経過後にエンジン側の初期設定が完了し、ＥＮＧＲＤＹ信号がＬｏｗになった段階でエンジン側との通信が可能となる。

次に、同図（Ｂ）は省エネモードに移行した時のＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号の動作の一例を示している。省エネモードに移行するため、コントローラボード２００によりＰＷＲＣＴＬ信号をＯＦＦにする。これと同時に電源供給もおちる。これに伴って、ＥＮＧＲＤＹ信号は、Ｈｉｇｈとなり省エネモードに移行する。次に、省エネモードから復帰する場合を同図（Ｃ）に示す。

同図（Ｃ）は、省エネモードから復帰する時のＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号の動作の一例を示している。上記（Ｂ）の省エネモードから復帰する際には、コントローラボード２００によりＰＷＲＣＴＬ信号をＯＮにする。これと同時に電源供給もされる。しかし、上記の（Ａ）で示したように、エンジン側の初期設定が完了するまで、ＥＮＧＲＤＹ信号はＨｉｇｈの状態であり、初期設定が完了するとエンジン側との通信が可能となり、Ｌｏｗとなる。

次に、上述した画像処理装置１００のソフトウェアの構成に含まれるＮＲＳアプリ３１５の内部構成を図５を用いて更に説明する。
図５は、ＮＲＳアプリの構成の一例を示す機能ブロック図である。同図に示すように、ＮＲＳアプリ３１５は、アプリケーションモジュール層とＮＣＳ３０３との間で処理をおこなっている。ウェブサーバ機能部５００は、外部から受信した要求に関する応答処理を行う。ここでの要求は、例えば、構造化言語であるＸＭＬ（Extensible Markup Language）形式で記載された、ＳＯＡＰ（Simple Object Access Protocol）によるＳＯＡＰリクエストであることが考えられる。ウェブクライアント機能部５０１は、外部への要求を発行する処理を行う。ｌｉｂｘｍｌ５０２は、ＸＭＬ形式で記載されたデータを処理するライブラリであり、ｌｉｂｓｏａｐ５０３は、ＳＯＡＰを処理するライブラリである。また、ｌｉｂｇｗｗｗ５０４は、ＨＴＴＰを処理するライブラリであり、ｌｉｂｇｗ＿ｎｃｓ５０５は、ＮＣＳ３０３との間の処理をするライブラリである。

上記のＳＯＡＰリクエストは、ＰＨＹ２０４によって受信され、ＳＯＡＰヘッダとＳＯＡＰボディを含むＳＯＡＰドキュメントがＨＴＴＰメッセージの形でＮＣＳ３０３を介してＮＲＳアプリ３１５に渡される。そして、ＮＲＳアプリ３１５において、ｌｉｂｓｏａｐ５０３を用いてＳＯＡＰドキュメントからＳＯＡＰボディを取り出し、ｌｉｂｘｍｌ５０２を用いてＳＯＡＰボディを解釈してＤＯＭ（Document Object Model）ツリーを生成し、ウェブサーバ機能部５００がこれを各アプリにおける処理に適したデータ構造体に変換した上でＳＯＡＰボディに含まれるコマンドに対応したアプリに渡す。
データ構造体については、例えばアプリのプログラムがＣ言語で記載されている場合にはＣ言語の構造体データであり、この構造体データを引数としてアプリのプログラムをコールすることによってアプリにデータを渡すことができる。

次に、このような基本的な機能を有する図１に示した通信システムにおける動作である、画像処理装置１００における認証動作およびそのために必要な構成について説明する。
まず、この認証動作の概略について説明する。図６は、図１に示した画像処理装置１００においてパスワードによる認証を行う場合の処理手順について説明するための図である。

この画像処理装置１００は、図６に示すように、認証情報であるパスワードの入力を、操作部である操作パネル２０５からの入力操作あるいはネットワーク通信手段として機能するＰＨＹ２０４による受信という２つのインタフェースによって受け付けることができる。前者の場合には、画像処理装置１００のコントローラボード２００に備えたＣＰＵ（以後単に「ＣＰＵ」と言った場合にはこのＣＰＵを指すものとする）がＯＣＳ３００を実行することにより第１の認証情報受付手段として機能し、後者の場合には、ＣＰＵがＮＣＳ３０３を実行することにより第２の認証情報受付手段として機能する。
なお、認証情報を受け付けるインタフェースが２つより多くてもよいことは、もちろんである。また、インタフェースの種類も操作パネル２０５とＰＨＹ２０４に限られることはない。

まず、前者の場合の処理について説明する。
各アプリケーションプログラム（アプリ）又はモジュール（図３の３０１〜３０６，３０９〜３１８）は、操作パネル２０５から認証の必要な動作の実行の指示を受けると、ＯＣＳ３００に対してパスワード入力画面を表示するように要求する（矢印Ａ）。すると、ＯＣＳ３００はこれに応じて操作パネル２０５の表示を制御してパスワード入力画面を表示させ（矢印Ｂ）、パスワードの入力を受け付け（矢印Ｃ）、これをアプリに渡す（矢印Ｄ）。パスワード入力画面は、例えば図７に示すようなものである。
アプリは、このパスワードを受け取ると、これをＣＣＳ３１９に渡して認証処理を要求し（矢印Ｅ）、ＣＣＳ３１９は渡されたパスワードを記憶手段に記憶している所定のパスワードと比較して認証処理を行い、その結果をアプリに返す（矢印Ｆ）。

そして、アプリは、認証が成功していれば（パスワードが正しいものであれば）、実行モジュール（ＥＣＳ３０１，ＦＣＳ３０４，ＤＣＳ３１６等のサービス層のソフトウェア）に対して、指示された動作の実行に必要な指示を行う（矢印Ｇ）。実行モジュールはこれに応じてハードウェア資源に動作を実行させ、その結果をアプリに返す（矢印Ｈ）。アプリはこれに応じて結果画面の表示をＯＣＳ３００に要求し（矢印Ａ）、結果画面を操作パネル２０５に表示させる。
認証が失敗していれば（パスワードが正しいものでなければ）、アプリは実行モジュールに指示を出す代わりにＯＣＳ３００に対してエラー画面の表示を要求し（矢印Ａ）、エラー画面を操作パネル２０５に表示させる。
また、認証が必要ない動作の実行の指示を受けた場合には、アプリはパスワードの入力画面の表示や認証処理を要求することなく、実行モジュールに対して指示された機能の実行に必要な指示を発し、帰ってきた結果に対応してＯＣＳ３００に結果画面の表示を要求し、操作パネルにこれを表示させるのみである。

一方、コマンドをネットワーク経由で受信する場合、この画像処理装置１００は全てのコマンドについて認証処理を行うようにしている。そして、実行を要求するコマンドと認証情報であるパスワードとを、１つのＳＯＡＰドキュメントに含める形でＨＴＴＰメッセージとして受信し、受信したパスワードで認証が成功した場合に、同じＳＯＡＰドキュメントに含まれるコマンドの実行を許可するようにしている。
ＳＯＡＰドキュメントは、例えば構造化言語によるＸＭＬ形式で記述することができるが、このＳＯＡＰドキュメントのフォーマットは、例えば図８及び図９に示すものとすることができる。

これらの図を見て分かるように、コマンドの実行を要求するＳＯＡＰドキュメントは、それがコマンド実行要求であることを示す種別情報、認証情報であるパスワード、要求の番号を示すコールＩＤ、実行を要求するコマンドの内容情報を含む。なお、パスワードは、平文のままネットワークに流すとセキュリティ上問題があるため、ビットシフトやビット反転等の簡単なものでもよいので、暗号化した状態で送受信するようにするとよい。また、コマンドの内容情報には、実行を要求するコマンドの名称、引数等の情報が含まれる。
なお、コマンドには、画像処理装置１００にプリント等の目に見える何らかの動作を行うことを要求するものの他、設定変更やデータの取得等、データに対するアクセスを求めるものも含むものとする。例えば、図２３に示した課金カウンタ取得要求は、「課金カウンタ取得」というコマンドの実行要求である。

図８に示したようなコマンドの実行要求は、ＰＨＹ２０４が受信する時点ではＩＰ（Internet Protocol）パケットの状態である。これをＮＣＳ３０３が受けとって（矢印Ｉ）つなげ、ＨＴＴＰメッセージ（内容はＳＯＡＰドキュメント）の形にし、ＮＲＳアプリ３１５に渡す（矢印Ｊ）。ＮＲＳアプリ３１５は、このＨＴＴＰメッセージからＳＯＡＰボディーの部分のＸＭＬドキュメントを取り出し（矢印Ｋ）、さらにそのタグを解釈してパスワードを取得する。そして、ＣＣＳ３１９に渡して認証処理を要求し（矢印Ｌ）、ＣＣＳ３１９は渡されたパスワードを記憶手段に記憶している所定のパスワードと比較して認証処理を行い、その結果をＮＲＳアプリ３１５に返す（矢印Ｍ）。

そして、ＮＲＳアプリ３１５は、認証が成功していれば、コマンドを実行させるべく、ＳＯＡＰボディーに含まれるデータをＤＯＭツリーを経てアプリにおける処理に適したデータ構造体の形式に変換し、コマンドの実行に適したアプリに渡す（矢印Ｎ）。これらの処理において、ＣＰＵがＮＲＳアプリ３１５を実行することにより、構造化言語解釈手段として機能する。
アプリは、これに応じて実行モジュールに対してコマンドの実行に必要な動作を指示する（矢印Ｏ）。実行モジュールはこれに応じてハードウェア資源に動作を実行させ、その結果をアプリに返す（矢印Ｐ）。アプリはこの結果をデータ構造体としてＮＲＳアプリ３１５に返す（矢印Ｑ）。

以後はコマンドの実行要求に対する応答の送信過程であるが、基本的には受信時の逆の工程である。すなわち、ＮＲＳアプリ３１５がデータ構造体からＳＯＡＰボディーとなるＸＭＬドキュメントを作成し、続いてＳＯＡＰヘッダを付加してＳＯＡＰドキュメントを作成し、これをＮＣＳ３０３に渡す（矢印Ｒ，Ｓ）。ＮＣＳ３０３は、これをＨＴＴＰメッセージとしてＩＰパケットに分割し、ＰＨＹ２０４を介してコマンド実行要求の送信元に対して応答として送信する（矢印Ｔ）。
ＣＣＳ３１９での認証が成功しなかった場合には、上記と同様の工程でその旨の応答をコマンド実行要求の送信元に対して送信する。
以上のように、この画像処理装置１００においては、パスワードの入力を操作パネル２０５から受け付けた場合もネットワークを介して受け付けた場合も、パスワードを共通のＣＣＳ３１９に渡し、ここで認証処理を行うようにしている。このようなＣＣＳ３１９は、ＣＰＵをパスワードによる認証処理を行う手段として機能させるためのプログラムを含むものである。

図１０には、画像処理装置１００において公開鍵暗号を用いた認証動作を行う場合の処理手順を示す。
ネットワークを介してコマンドの実行要求を受け付ける場合、公開鍵暗号を用いた認証（以下「ＰＫＩ認証」ともいう。ＰＫＩは「Public Key Infrastructure」の略）を行うこともできる。
ここで、この画像処理装置１００におけるＰＫＩ認証の手順について簡単に説明する。
図１に示した通信システムを構成する各装置には、所定の認証局が発行した自己の公開鍵及び私有鍵と共に、その所定の認証局がそれらの鍵を発行したことを示す証明データを記憶させておく。

そして、装置同士がＰＫＩ認証を行おうとする場合、まず通信相手の証明データを取得し、公開鍵を渡してもよい相手か否かを判断する。例えば、通信相手も自己と同じ認証局が発行した証明データを記憶している場合に渡してもよいと判断することができる。
渡してもよいと判断した場合、自己の公開鍵を通信相手の装置に送信して記憶させる。逆に、通信相手からもその相手の公開鍵を取得して記憶する（このとき、通信相手側でも同じように証明データによって公開鍵を渡してもよい相手か否かを判断するようにしてもよい）。従って、ＰＫＩ認証を行う場合には、自己の公開鍵及び私有鍵の他に、互いの通信相手の公開鍵も記憶していることになる。

なお、公開鍵を渡す際に、公開鍵と共に証明データも渡せば、通信相手はその証明データによってその公開鍵の発行元を認識することができるので、これを基に公開鍵の正当性について判断することができる。また、公開鍵の発行元と通信し、その発行元が本当にその公開鍵を発行したか否かを問い合わせることもできる。
また、証明データには、鍵を発行した認証局の情報の他、鍵を持つ装置の機種、機番、その装置のユーザ等の情報を含めるようにしてもよい。この場合において、証明データを認証や判断に用いる場合、その一部の情報のみを参照して行うようにしてもよい。例えば、同じ認証局から発行されたものであれば、他の情報は一致しなくても公開鍵を渡してよいと判断する等である。

次に、上述のように公開鍵の交換が行われた状態において、認証を要求する側は、まず自己の私有鍵で所定のデータを暗号化して通信相手に対して送信する。通信相手の装置はこれを受信すると、送信してきたデータをその送信元の装置のものとして記憶している公開鍵で復号化できるか否かによって認証処理を行う。復号化が成功すれば認証成功であり、データが正しい送信元から送られてきたものであることを認識できる。
すると、これに対する応答として、認証が成功したことを示すデータを、自己の（認証する側の装置の）私有鍵で暗号化して送信元に返す。送信元の（認証を要求する側の）装置は、通信相手の公開鍵を記憶しているので、応答データをこの公開鍵で復号化し、これが成功すれば、正しい通信相手によって認証されたことを認識できる。

図１に示した通信システムにおいては、このように、ＰＫＩ認証を行う場合、認証を要求する側とこれに応じて認証を行う側で、互いが互いを認証するようにしている。そしてこの場合、認証を要求する側が自己の私有鍵で暗号化して送信するデータが認証情報であり、ここでは、このデータに以後の通信における暗号化方式を示すデータを含めるようにし、一度認証した後は、一つのセッションが終わるまでは再度の認証を行わず、認証情報に含まれる暗号化方式を用いて通信を行うようにする方式を採用している。
暗号化方式を示すデータとしては、例えば共通鍵暗号による暗号化方式を指定するデータとこれに用いる共通鍵のデータが考えられる。このような共通鍵は、セッション毎に作成するようにするとよい。また、暗号化を行わないことを示すデータも考えられる。この場合には、通信は暗号化せず、暗号は認証のみに用いることになる。

なお、上述した公開鍵の交換は、ＰＫＩ認証を要求する度に行った方が、より正確な認証を行うことができる。また、この場合には、公開鍵の交換時に証明データも交換するようにすれば、これによって一定の認証処理が済んだと捉えることができるので、認証情報の送信は、通信相手から受け取った公開鍵で暗号化して行うようにすることができる。このようにした場合には、その認証データの送り手がどの装置であるかを認証することはできないが、証明データによってある程度は示されているので特に問題はなく、一方で、認証情報の中身を通信相手の装置以外に見られないようにすることができる。
しかし、一度公開鍵を交換した後は、その公開鍵を記憶しておき、これを用いるようにすれば、以後改めて交換を行わなくても、認証情報による認証処理には支障がない。また、このようにすると通信量が少なくて済み、処理も単純である。そこで、説明を簡単にするため、ＰＫＩ認証についての以後の説明においては、一度公開鍵を交換した後はその公開鍵を記憶しておくものとし、これを記憶した状態で認証に関する処理を開始するものとして説明する。

ＰＫＩ認証を行うか否かは、ＰＨＹ２０４がどのポートからその要求に係るＨＴＴＰメッセージを受信したかによって判断することができる。例えば、図１０に示す例では、ポート４４３をＰＫＩ認証を行うポートとして予め設定しておき、このポートから受信したＨＴＴＰメッセージについてＰＫＩ認証を行うようにしている。
この場合、画像処理装置１００にコマンドの実行要求を送信する外部装置は、ＰＫＩ認証を求める場合、まずその外部装置が自己の私有鍵を用いて暗号化したデータを認証情報として画像処理装置１００のポート４４３に送信する。

画像処理装置１００側では、ＰＨＹ２０４が受信したＩＰ（Internet Protocol）パケットをＮＣＳ３０３が受けとって（矢印ａ）つなぎ合わせ、ＨＴＴＰメッセージの形にするが、ＮＣＳ３０３はポート４４３で受信したデータについてはＰＫＩ認証に供する取り扱いを行い、ＨＴＴＰメッセージが認証情報であるとＣＣＳ３１９に渡して認証処理を要求する（矢印ｂ）。
ＣＣＳ３１９ではこの認証情報を、送信元の装置のものとして記憶している公開鍵と、暗号化／復号化モジュールであるＤＥＳＳ３１８とを用いて復号化し、正常に復号化できれば認証が成功したものとし、できなければ認証が失敗したものとする。そして、この認証結果をＮＣＳ３０３に返す。認証が成功した場合には復号後のデータも返す（矢印ｃ）。ＮＣＳ３０３はこれを受け取ると、その認証結果を自己の私有鍵で暗号化して送信元の外部装置に通知すると共に（矢印ｄ）、認証が成功した場合には、復号後のデータに含まれる暗号化方式を、認証済みの暗号化方式として記憶する。

外部装置は、受け取った通知を画像処理装置１００のものとして記憶している公開鍵によって復号化する。そして、これが成功すれば、確かに画像処理装置１００からの応答であることがわかる。そして、これが認証が成功した旨の通知であれば、次にコマンドの実行要求を、認証済みの暗号化方式によって暗号化して画像処理装置１００のポート４４３に対して送信する。ＰＨＹ２０４がこれをＩＰパケットとして受信してＮＣＳ３０３に渡し（矢印ｅ）、ＮＣＳはこれをつなげてＨＴＴＰＳ（Hypertext Transfer Protocol Security）メッセージとし、これを認証済みの暗号化方式に対応する方式でＤＥＳＳ３１８を用いて復号化してＨＴＴＰメッセージ（内容はＳＯＡＰドキュメント）を取得し（矢印ｆ）、ＮＲＳアプリ３１５に渡す（矢印ｇ）。
以下、ＮＲＳアプリ３１５がこれをデータ構造体の形式に変換した上でアプリに渡して実行モジュールに動作を実行させ、帰ってきた応答をＨＴＴＰメッセージに変換する過程（矢印ｈ乃至ｍ）は、図６を用いて説明したパスワード認証の場合と同様である。ただし、ここでは既に認証は済んでいるので、新たに認証処理を行うことはない。

ここで、既に認証が済んでいるか否かの判断は、例えば、ＮＣＳ３０３がＰＫＩ認証により認証済みのコマンド実行要求に係るＳＯＡＰドキュメントをＮＲＳアプリ３１５に渡す場合にその旨を示すフラグを立てておくようにし、ＮＲＳアプリ３１５が渡されたＳＯＡＰドキュメントを処理する際にこのフラグを参照するようにして行うことができる。
あるいは、図６に示したパスワード認証のためのＮＲＳアプリと、図１０に示すＰＫＩ認証のためのＮＲＳアプリとを別々に用意し、ＮＣＳ３０３が認証方式に応じてＳＯＡＰドキュメントを渡すＮＲＳアプリを選択するようにしてもよい。この場合は、パスワード認証のためのＮＲＳアプリは必ずＣＣＳ３１９に認証を要求し、ＰＫＩ認証のためのＮＲＳアプリはＣＣＳ３１９に認証を要求しないようにする。

ＮＲＳアプリ３１５が変換して生成したＳＯＡＰドキュメントは、ＮＣＳ３０３に渡し（矢印ｎ）、ＮＣＳ３０３が受信時と同じ暗号化方式で暗号化して、これをＨＴＴＰＳメッセージとしてＩＰパケットに分割し、ＰＨＹ２０４を介してコマンド実行要求の送信元に対して応答として送信する（矢印ｏ，ｐ）。
以後、同様の手順によってコマンドの実行要求を受け付け、実行して応答を返す。なお、ＮＣＳ３０３が認証の期限を定めるようにし、認証の期限が切れた場合には、再度認証情報の送信を要求するようにするとよい。
このように、ＣＣＳ３１９はＣＰＵを公開鍵暗号を用いた認証処理（ＰＫＩ認証の処理）を行う手段として機能させるためのプログラムを含むものである。

また、図１０には、ＰＨＹ２０４がポート８０からデータを受信した場合の処理も示している。ポート８０は認証処理を行わないポートとして設定してあり、この場合には、ＰＨＹ２０４が受信したＩＰパケットをＮＣＳ３０３に渡してつなぎ合わせ、ＨＴＴＰメッセージとしたあと（矢印ｑ）、そのままＮＲＳアプリ３１５に渡す（矢印ｒ）。そして、上述した認証処理ありの場合と同様に以下の矢印ｈ乃至ｍで示す処理を行い、ＮＲＳアプリ３１５が変換して生成したＳＯＡＰドキュメントは、ＮＣＳ３０３に渡し（矢印ｓ）、これをＨＴＴＰメッセージとしてＩＰパケットに分割し、ＰＨＹ２０４を介してコマンド実行要求の送信元に対して応答として送信する（矢印ｔ）。

画像処理装置１００にこのようなポートを設けることも可能ではあるが、何の認証も行わずにネットワーク経由でコマンド実行要求を送信して動作させることができるとするとセキュリティ上問題があるので、上記のポート８０のような場合でも、図６に示したようなパスワードによる認証を行うようにするとよい。
なお、以上のようにネットワークを介して認証情報を受信する場合、この認証情報は、外部装置１２０自身が生成したものでないことを妨げない。例えば、所定の認証サーバで認証を受けたという証明や、それに伴って発行される識別情報等でもよい。また、認証サーバ自身が画像処理装置１００に認証情報を送信し、コマンドの実行要求を代行することも可能である。

次に、上述の認証動作に関連する具体的な処理について、フローチャートとシーケンス図を用いて説明する。なお、以下のフローチャートに示す処理は、ＣＰＵがＯＣＳ３００，ＮＣＳ３０３，ＮＲＳアプリ３１５，ＣＣＳ３１９を始めとする種々のプログラムを実行することによって実現されるものである。そして、以下のフローチャートには、ＣＰＵが全体としてどのような動作を行うかを示しており、従ってステップによって実際に処理を行うためのプログラムが異なることになる。
まず図１１のフローチャートに、比較例として、従来の認証方式に係る処理を示す。この従来の場合には、ＣＣＳ３１９は用いておらず、操作パネルから入力されたパスワードの認証はＯＣＳ３００が行う構成となっている。また、この処理は、便宜上ＳＴＡＲＴから開始するように図示しているが、実際には図３に示した各ソフトウェアによって種々のイベントに応じて行われる一連の制御動作うちの一部分を取り出して示したものである。

図１１の示す処理の場合、ユーザが操作部においてコピー，ファクス，プリンタ，スキャナ等のいずれかの機能を選択し、ＯＣＳ３００がこの操作を検出して対応するアプリに渡すと、ステップＳ１からの処理が開始され、ステップＳ１でアプリがＯＣＳ３００に初期画面の表示を要求する。
次のステップＳ２では、ＯＣＳ３００がこの要求に応じて操作パネル２０５を制御して初期画面を表示させると共に、ユーザの操作を受け付ける。そして、受け付けた操作内容をアプリに渡す。

ステップＳ３では、アプリがこの操作内容を取得して、認証が必要な機能が選択されたか否か判断する。そして選択されていれば、ステップＳ４で既に認証が済んでいるか否か判断する。この判断は、後述する認証済みフラグを参照することによって行うことができる。そして、済んでいなければ、ステップＳ５に進み、ＯＣＳ３００に対し、操作に対応した次の画面（選択された機能についての操作を受け付ける画面）の表示と、その表示前の認証処理を要求する。
すると、ＯＣＳ３００はこれに応じてステップＳ６で操作パネル２０５に図７に示したようなパスワード入力画面を表示させ、パスワードの入力を受け付ける。そして、ユーザがパスワードを入力すると、ステップＳ７でこれを記憶しているパスワードと比較して認証処理を行う。

ステップＳ８でその結果を判断し、正しいパスワードであれば認証が成功したものとしてステップＳ９に進み、ＲＡＭに記憶している認証済みフラグをＯＮにして、操作パネル２０５を操作しているユーザが認証されたことを示す。そして、ステップＳ１０に進み、ステップＳ５でアプリから要求された次画面を操作パネル２０５に表示させ、ユーザが選択した機能についての操作を受け付けて操作内容をアプリに渡す。

次のステップＳ１１では、アプリがこの操作内容を取得して、必要な実行モジュールに対し、その操作内容に対応した動作（コピー，画像データ送信，設定変更等）を実行するように指示を行い、ハードウェア資源の動作を制御させて操作内容に対応した動作を実行させる。そして、実行モジュールからその動作の実行結果を取得する。その後、ステップＳ１２でその実行結果に応じてＯＣＳ３００に対して結果画面の表示を要求する。そして、処理はステップＳ２に戻り、ＯＣＳ３００が操作パネルにその画面を表示させ、ユーザから次の操作を受け付け、処理を繰り返す。

ステップＳ８で認証が失敗した場合、すなわちパスワードが正しいものでなかった場合には、ステップＳ１３に進んでＯＣＳが操作パネル２０５にエラー画面を表示させ、ステップＳ２に戻ってユーザから次の操作を受け付け、処理を繰り返す。
ステップＳ３で認証が必要でないと判断したか、あるいはステップＳ４で認証済みと判断した場合には、ステップＳ１４に進み、ステップＳ２で受け付けた操作に対応した次の画面（選択された機能についての操作を受け付ける画面）の表示をＯＣＳ３００に要求し、ステップＳ１０以降の処理を行う。

図１２に、図１１のフローチャートに示した処理による処理シーケンスの一例を示す。
図１２に示す例では、まずアプリがＯＣＳ３００に対して初期画面の表示を要求する（Ｓ１０１）。ＯＣＳ３００はこれに応じて操作パネル２０５に初期画面を表示させると共に操作を受け付け（Ｓ１０２）、その操作内容をアプリに渡す（Ｓ１０３）。アプリは、この操作が認証が必要な機能の選択であると判断すると（Ｓ１０４）、ＯＣＳ３００に対し、次画面の表示と、その前に認証処理を行うことを要求する（Ｓ１０５）。
ＯＣＳ３００はこれに応じてパスワード入力画面を操作パネル２０５に表示させてパスワードの入力を受け付け（Ｓ１０６）、そのパスワードを用いて認証処理を行う（Ｓ１０７）。

以下の（ａ）は認証が成功した場合の処理であり、この場合にはＳ１０５の要求に従って操作パネル２０５に次画面を表示し、次の操作を受け付ける（Ｓ１０８）。そして、受け付けた操作内容をアプリに渡す（Ｓ１０９）。アプリは、これに応じて操作内容に係る処理を実行させるべく、必要な実行モジュールに対して動作の実行を指示し（Ｓ１１０）、実行モジュールはこれに応じてハードウェア資源を制御して動作を実行させ（Ｓ１１１）、その結果をアプリに返す（Ｓ１１２）。
アプリは、その結果に応じてＯＣＳ３００に対して結果画面の表示を要求し（Ｓ１１３）、ＯＣＳ３００は操作パネル２０５にその結果画面を表示させる（Ｓ１１４）。
（ｂ）は認証が失敗した場合の処理であり、この場合にはＯＣＳ３００が操作パネル２０５に認証が失敗した旨のエラー画面を表示させる。

従来は、以上の図１１及び図１２に示すような処理により、認証が必要な場合には操作パネルへ２０５の表示を制御するＯＣＳ３００によって認証処理を行い、認証が成功した場合のみ認証が必要な機能に係る指示を受け付けるための画面を表示し、失敗した場合にはその画面を表示しないようにしていた。そして、このようにすることにより、認証が失敗した場合には認証が必要な機能に係る指示を受け付けることが無いようにし、受け付けた指示は全て実行するようにしても、結果的に認証が必要な機能は認証に成功した者のみに実行させることができるようにしていた。
しかし、このような方式は、操作パネル２０５からパスワードの入力を受け付ける場合のみに適用可能なものであり、例えばネットワーク経由等、別のインタフェースからも認証情報を受け付けることを考えた場合には、全く別に認証手段を設けなければならず、設計に労力を要し、処理負担も大きくなるという問題があった。

次に、図１３のフローチャートに、この実施形態の画像処理装置における認証に係る処理のうち、操作パネルからパスワードの入力を受け付ける場合の処理を示す。この処理は、図６の矢印Ａ乃至Ｈに対応する処理である。
この場合も、図１１に示す処理の場合と同様、ユーザが操作部においてコピー，ファクス，プリンタ，スキャナ等のいずれかの機能を選択し、ＯＣＳ３００がこの操作を検出して対応するアプリに渡すと、ステップＳ２１からの処理が開始され、ステップＳ２１でアプリがＯＣＳ３００に初期画面の表示を要求する。
次のステップＳ２２で、ＯＣＳ３００がこの要求に応じて操作パネル２０５を制御して表示部に初期画面を表示させ、ユーザの操作を受け付け、受け付けた操作内容をアプリに渡す点も、従来の場合と同様である。

しかし、ステップＳ２３の判断では、アプリは、認証が必要な動作が選択されたか否か判断する。すなわち、この画像処理装置においては、認証の成否によって画面表示の許可／不許可を決定するのではなく、動作実行の許可／不許可を決定するようにしているので、認証の要否の判定も、機能の選択ではなく動作の指示の内容をもとに行うのである。ただし、画面の切り換えも動作の１つとして取り扱い、この動作の実行に認証が必要と判断すれば、ステップＳ２３の判断はＹＥＳとなる。

ステップＳ２３の判断がＹＥＳであれば、ステップＳ２４に進んでアプリがＯＣＳ３００にパスワード受け付け画面の表示を要求する。そして、ステップＳ２５でＯＣＳ３００がこれに応じて操作パネル２０５に図７に示したようなパスワード受付画面を表示させ、パスワードの入力を受け付けて、これをアプリに渡す。
次のステップＳ２６では、アプリがＣＣＳ３１９にそのパスワードを渡し、認証処理を要求する。そして、ステップＳ２７ではＣＣＳ３１９がこれに応じて受け取ったパスワードを記憶しているパスワードと比較して認証処理を行い、その結果をアプリに返す。

ステップＳ２８ではアプリが認証が成功したか否か判断し、成功していればステップＳ２９に進み、必要な実行モジュールに対し、ステップＳ２２で受け付けた操作内容に対応した動作を実行するように指示を行い、ハードウェア資源の動作を制御させて操作内容に対応した動作を実行させる。そして、実行モジュールからその動作の実行結果を取得する。その後、ステップＳ３０でその実行結果に応じてＯＣＳ３００に対して結果画面の表示を要求する。そして、処理はステップＳ２２に戻り、ＯＣＳ３００が操作パネルに結果画面を表示させ、ユーザから次の操作を受け付け、処理を繰り返す。

ステップＳ２８で認証が失敗したと判断した場合には、ステップＳ３１に進み、ＯＣＳ３００に対してエラー画面の表示を要求してステップＳ２２に戻る。この場合にはＯＣＳ３００は操作パネルにエラー画面を表示する。
なお、以上の処理において、認証が必要な動作を指示するたびにパスワードの入力を要求されるのはユーザにとって面倒であるから、一度認証が成功した後は、所定期間経過あるいは所定の操作がなされる等の条件が満たされるまで、再度の認証は要求しないようにしてもよい。一般的に、画像処理装置の操作パネルからの操作は、同一人が継続して行うことが多いため、このようにしても大きな問題はない。

図１４に、図１３のフローチャートに示した処理による処理シーケンスの一例を示す。
図１４に示す例では、まずアプリがＯＣＳ３００に対して初期画面の表示を要求する（Ｓ２０１）。ＯＣＳ３００はこれに応じて操作パネル２０５に初期画面を表示させると共に操作を受け付け（Ｓ２０２）、その操作内容をアプリに渡す（Ｓ２０３）。アプリは、この操作が認証が必要な動作の指示であると判断すると（Ｓ２０４）、ＯＣＳ３００に対し、パスワード受付画面の表示を要求する（Ｓ２０５）。
ＯＣＳ３００はこれに応じてパスワード入力画面の操作パネル２０５に表示させてパスワードの入力を受け付け（Ｓ２０６）、そのパスワードをアプリに渡す（Ｓ２０７）。

すると、アプリは受け取ったパスワードをＣＣＳ３１９に渡し、認証を要求する（Ｓ２０８）。ＣＣＳ３１９はそのパスワードによって認証処理を行い（Ｓ２０９）、認証結果をアプリに返す（Ｓ２１０）。
以下の（ａ）は認証が成功した場合の処理であり、この場合にはアプリはＳ２０３で受け取った操作内容に係る動作を実行させるべく、必要な実行モジュールに対して動作の実行を指示し（Ｓ２１１）、実行モジュールはこれに応じてハードウェア資源を制御して動作を実行させ（Ｓ２１２）、その結果をアプリに返す（Ｓ２１３）。
アプリは、その結果に応じてＯＣＳ３００に対して結果画面の表示を要求し（Ｓ２１４）、ＯＣＳ３００は操作パネル２０５にその結果画面を表示させる（Ｓ２１５）。

（ｂ）は認証が失敗した場合の処理であり、この場合には、アプリはＯＣＳ３００に対して認証失敗を示すエラー画面の表示を要求し（Ｓ２１６）、ＯＣＳ３００は操作パネル２０５にそのエラー画面を表示させる（Ｓ２１７）。
画像処理装置１００においては、以上の図１３及び図１４に示すような処理により、操作パネル２０５から認証が必要な動作を指示された場合にＣＣＳ３１９によって認証処理を行い、認証が成功した場合のみ動作の実行を許可するようにしている。

次に、図１５のフローチャートに、この実施形態の画像処理装置における認証に係る処理のうち、ネットワークを介してパスワードの入力を受け付ける場合の処理を示す。この処理は、図６の矢印Ｉ乃至Ｔに対応する処理である。この図においても、ステップによって実際に処理を行うためのプログラムが異なること、実際には図３に示した各ソフトウェアによって種々のイベントに応じて行われる一連の制御動作うちの一部分を取り出して示したものであることは、図１１等の場合と同様である。

この画像処理装置１００においては、ネットワークを介してデータを送受信する場合、ネットワーク通信手段として機能するＰＨＹ２０４がＩＰパケットを外部装置とやり取りすることによって行う。そして、ＰＨＹ２０４がＩＰパケットを受信した場合、ＮＣＳ３０３がこれを受け取ってつなぎ合わせ、メッセージやファイル等の意味のあるデータを生成する。そして、これがＨＴＴＰメッセージとして送信されてきたＳＯＡＰドキュメントである場合、外部装置１２０からのコマンド実行要求であると考えられる。この画像処理装置１００は、外部装置（あるいはその外部装置のユーザ）を認証する方式として、パスワードによる認証とＰＫＩ認証の２つを用意しているが、ＰＫＩ認証を行うのは、所定のポートから受信したデータに対してのみとしているので、そのポート以外のポートから上記のＳＯＡＰドキュメントを受信した場合、ＣＰＵは図１５のフローチャートに示す処理を開始する。

この処理においては、まずステップＳ４１でＮＣＳ３０３が受信したＳＯＡＰドキュメントをＮＲＳアプリ３１５に渡す。次に、ステップＳ４２でＮＲＳアプリ３１５がこのＳＯＡＰドキュメント（ＳＯＡＰヘッダとＳＯＡＰボディーからなる）から、ＸＭＬドキュメントであるＳＯＡＰボディーを取得する。このＳＯＡＰボディーには、図８及び図９に示したように、外部装置が実行を要求するコマンドの情報と、認証に用いるパスワードの情報が含まれている。そして、ステップＳ４３でＳＯＡＰボディーのタグを解釈してこのパスワードを認証情報として取得する。すなわち、ここではパスワードを<authority>タグの要素としているので、図８に示したようなＳＯＡＰドキュメントから、ＳＯＡＰボディーを示す<Body>タグの中の、パスワードを示す<authority>タグの内容を取得する。<authority>タグが存在しない場合には、パスワードがないという情報を取得する。

そして、ステップＳ４４でそのパスワードをＣＣＳ３１９に渡し、認証処理を要求する。そして、ステップＳ４５ではＣＣＳ３１９がこれに応じて受け取ったパスワードを記憶しているパスワードと比較して認証処理を行い、その結果をＮＲＳアプリ３１５に返す。
ステップＳ４６ではＮＲＳアプリ３１５が認証が成功したか否か判断し、成功していればステップＳ４７に進み、実行を要求されているコマンドの情報を、そのコマンドを実行すべきアプリに渡す。例えばプリントコマンドであればプリンタアプリ３１１に渡す。このコマンドの情報は、ＳＯＡＰドキュメントのタグを解釈することにより取得できるが、ここでは、ＳＯＡＰドキュメントに含まれる情報の構造を解釈してＤＯＭツリーを生成した上で、これをアプリにおける処理に適したデータ構造体、例えばアプリがＣ言語で作成されている場合にはＣ言語で用いるデータ構造体、に変換してからアプリに渡すものとする。このようにすることにより、アプリのプログラムはＳＯＡＰドキュメントにおけるデータ形式を全く意識せずに作成することができるので、作成の労力を低減し、低コスト化を図ることができる。

次のステップＳ４８では、データ構造体を受け取ったアプリが、必要な実行モジュールに対してコマンドに係る動作を実行するように指示を行い、ハードウェア資源の動作を制御させてコマンドに係る動作を実行させる。そして、実行モジュールからその動作の実行結果を取得し、その実行結果をＮＲＳアプリ３１５に返す。その後、ステップＳ４９でＮＲＳアプリ３１５がこの応答をＤＯＭツリーを経てＳＯＡＰボディーのＸＭＬドキュメントに変換し、さらにＳＯＡＰヘッダを付加してＳＯＡＰドキュメントを生成してＮＣＳ３０３に渡す。そして、ステップＳ５１でＮＣＳがこのＳＯＡＰドキュメントをＰＨＹ２０４を介してＨＴＴＰメッセージとしてコマンド実行要求の送信元に対して応答として送信して終了する。

ステップＳ４６で認証が成功していなかった場合には、ステップＳ５０でＮＲＳアプリ３１５が認証が失敗した旨のエラー応答をＳＯＡＰボディーとしたＳＯＡＰドキュメントを生成してＮＣＳ３０３に渡し、ステップＳ５１ではＮＣＳがこのメッセージを応答として送信する。
なお、ここでは受信するＳＯＡＰドキュメントがコマンド実行要求でない場合については考慮していないが、他のＳＯＡＰドキュメントを受信することも考えられる場合には、ステップＳ４２の後でＳＯＡＰドキュメントがコマンド実行要求であるか否か判断し、コマンド実行要求である場合のみその後の処理を行い、そうでない場合にはその内容に合った他の処理を行うようにするとよい。

図１６に、図１５のフローチャートに示した処理による処理シーケンスの一例を示す。
図１６に示す例では、まずＮＣＳ３０３がＰＨＹ２０４から受け取ったＩＰパケットをつなぎ合わせてＳＯＡＰドキュメントを生成し（Ｓ３０１）、これをＮＲＳアプリ３１５に渡す（Ｓ３０２）。ＮＲＳアプリはこのＳＯＡＰドキュメントからＳＯＡＰボディーのＸＭＬドキュメントを取得し（Ｓ３０３）、そのタグを解釈してパスワードの情報を取得する（Ｓ３０４）。そして、パスワードをＣＣＳ３１９に渡して認証を要求する（Ｓ３０５）。ＣＣＳ３１９はこれに応じてパスワードによる認証処理を行い（Ｓ３０６）、認証結果をＮＲＳアプリ３１５に返す（Ｓ３０７）。

以下の（ａ）は認証が成功した場合の処理であり、この場合にはＮＲＳアプリ３１５はＳＯＡＰボディーに含まれる、実行を要求されたコマンドの情報をアプリにおける処理に適したデータ構造体に変換し（Ｓ３０８）、そのコマンドを実行すべきアプリに渡す（Ｓ３０９）。そして、アプリはこのコマンドに係る動作を実行させるべく、必要な実行モジュールに対して動作の実行を指示し（Ｓ３１０）、実行モジュールはこれに応じてハードウェア資源を制御して動作を実行させ（Ｓ３１１）、その結果をアプリに返す（Ｓ３１２）。アプリは受け取った実行結果をデータ構造体の形式でＮＲＳアプリ３１５に渡す（Ｓ３１３）。

すると、ＮＲＳアプリ３１５はこの実行結果をＸＭＬドキュメントに変換して応答のＳＯＡＰボディーとし、これを含むＳＯＡＰドキュメントを生成し（Ｓ３１４）、これをＮＣＳ３０３に渡す（Ｓ３１５）。ＮＣＳはこのＳＯＡＰドキュメントを応答のＨＴＴＰメッセージとして、コマンド実行要求の送信元に対して送信する。
認証が失敗した場合には、Ｓ３０８からＳ３１３までの処理は行わず、Ｓ３１４からＳ３１６までの処理によって認証失敗を示すＸＭＬドキュメントをＳＯＡＰボディーとして含むＳＯＡＰドキュメントを、応答のＨＴＴＰメッセージとして送信する。
画像処理装置１００においては、以上の図１５及び図１６に示すような処理により、ネットワーク経由でパスワードと共にコマンドの実行要求を受信した場合にもＣＣＳ３１９によって認証処理を行い、認証が成功した場合のみコマンドの実行を許可するようにしている。

次に、図１７のフローチャートに、この実施形態の画像処理装置における認証に係る処理のうち、ネットワークを介して受信するコマンド実行要求についてＰＫＩ認証を行う場合の処理を示す。この処理は、図１０の矢印ａ乃至ｐに対応する処理である。この図においても、ステップによって実際に処理を行うためのプログラムが異なること、実際には図３に示した各ソフトウェアによって種々のイベントに応じて行われる一連の制御動作うちの一部分を取り出して示したものであることは、図１１等の場合と同様である。
この画像処理装置１００においては、図１５についての説明で述べた通り、所定のポート（例えばポート４４３とすることができる）から受信したデータについてはＰＫＩ認証を行うようにしているので、そのポートからＨＴＴＰメッセージ（暗号化データの場合にはＨＴＴＰＳメッセージ）を受信した場合、ＣＰＵは図１７のフローチャートに示す処理を開始する。

この処理においては、まずステップＳ６１でＮＣＳ３０３が受信したメッセージが認証情報に係るものか否か判断する。すなわち、ＰＫＩ認証においては、認証を要求する相手はまず自己の私有鍵を用いて暗号化したデータを認証情報として送信してくるので、受信したデータがこのデータであるか否か判断する。この判断は、ヘッダ等を参照して行うことができる。
そして、認証情報であれば、ステップＳ６２に進み、その認証情報をＣＣＳ３１９に渡して認証処理を要求する。

次のステップＳ６３ではＣＣＳ３１９がその認証情報を用いて認証処理を行う。具体的には、送信元の装置の識別情報をもとに、その装置のものとして記憶している公開鍵を取得し、認証情報をその公開鍵で復号化する。復号化が成功すれば認証成功であり、復号化が失敗した場合には認証失敗である。この判断は、復号化処理時のエラー有無や復号化処理で得られたデータのチェックビットによるチェック等により行うことができる。
そしてここでは、送信元の装置は、以後の通信に用いる暗号化方式を示すデータとして、共通鍵暗号による暗号化方式を指定するデータとこれに用いる共通鍵のデータを暗号化して送信してくるものとし、このステップでの復号化によってこのデータを取得することができる。そしてＣＣＳ３１９は、認証結果と、認証が成功していればこの暗号化方式のデータをＮＣＳ３０３に返す。なお、認証のみを必要とし、通信に暗号化を必要としない場合には、暗号化方式のデータを、暗号化を行わない旨を示すデータとすることもできる。

ステップＳ６４では、ＮＣＳ３０３が認証に成功したか否か判断する。成功していればステップＳ６５に進み、認証結果と共に返された暗号化方式のデータを、以後の通信に使用するため、認証済みの暗号化方式として記憶し、ステップＳ６６で認証情報の送信元に認証結果を通知する。ステップＳ６４で失敗していれば、そのままステップＳ６６に進んで認証が失敗した旨の認証結果を通知する。これらの通知は、画像処理装置１００の私有鍵によって暗号化して送信する。なお、ステップＳ６５で記憶させた暗号化方式には無効化タイミングを定めるとよく、この無効化タイミングは、セッションの終了、所定時間経過等を基準に定めるとよい。
認証情報の送信元では、認証結果を受信すると、これを画像処理装置１００のものとして記憶している公開鍵によって復号化する。そして、復号化が成功すれば、確かに画像処理装置１００からの応答であることがわかる。そして、これが認証が成功した旨の通知であれば、以後認証情報として伝えた暗号化方式で暗号化したデータを画像処理装置１００に対して送信する。

一方、ステップＳ６１で認証情報でない場合には、ステップＳ６７に進んで認証済みの暗号化方式があるか否か判断する。すなわち、ステップＳ６５で記憶され、まだ有効になっている暗号化方式があるか否か判断する。あれば、ステップＳ６８に進んでＮＣＳ３０３が受信したメッセージ（通常は暗号化されているＨＴＴＰＳメッセージ、暗号化されていない場合にはＨＴＴＰメッセージ）についてその方式に従って復号化処理を行い、ＳＯＡＰドキュメントを生成する。
ステップＳ６９では復号化が正常に完了したか否か判断し、成功していればステップＳ７０に進んで生成したＳＯＡＰドキュメントをＮＲＳアプリ３１５に渡す。

そして、ステップＳ７１でＮＲＳアプリ３１５がこのＳＯＡＰドキュメント（ＳＯＡＰヘッダとＳＯＡＰボディーからなる）から、ＸＭＬドキュメントであるＳＯＡＰボディーを取得する。このＳＯＡＰボディーには、図８及び図９に示したものと同様に、外部装置が実行を要求するコマンドの情報が含まれているが、ここでは認証にパスワードは用いないので、パスワードは含まれていない。

次のステップＳ７２では、図１５のステップＳ４７の場合と同様、ＮＲＳアプリ３１５が、実行を要求されているコマンドの情報をアプリにおける処理に適したデータ構造体に変換してそのコマンドを実行すべきアプリに渡す。ステップＳ７３でデータ構造体を受け取ったアプリが実行モジュールに対して必要な指示を行い、コマンドに係る動作を実行させてその動作の実行結果を取得し、その実行結果をＮＲＳアプリ３１５に返すことも、図１５のステップＳ４８の場合と同様である。次のステップＳ７４でＮＲＳアプリ３１５がこの応答をＳＯＡＰボディーとするＳＯＡＰドキュメントを生成してＮＣＳ３０３に渡すことも、図１５のステップＳ４９の場合と同様である。

そして、ステップＳ７５で、これを受け取ったＮＣＳ３０３は認証済みの暗号化方式で暗号化を行い、ＨＴＴＰＳメッセージとしてＰＨＹ２０４を介してコマンド実行要求の送信元に対して応答として送信して終了する。
ステップＳ６７で認証済みの暗号化データがなかった場合あるいはステップＳ６９で復号化が正常に行えなかった場合には、ステップＳ７６でＮＣＳ３０３がデータの送信元に対して受信したデータが適当なものでない旨のエラー応答を送信して処理を終了する。

図１８に、図１７のフローチャートに示した処理による処理シーケンスの一例を示す。
図１８に示す例では、まずＮＣＳ３０３が（ＰＨＹ２０４経由で）認証情報を受信すると（Ｓ４０１）、これをＣＣＳ３１９に渡して認証処理を要求する（Ｓ４０２）。ＣＣＳ３１９はこの認証情報に対して認証処理を行い（Ｓ４０３）、その結果をＮＣＳ３０３に返す（Ｓ４０４）。そして、ＮＣＳ３０３はこの認証結果を認証情報の送信元に通知する（Ｓ４０５）。

認証が成功していると、認証情報の送信元は次に暗号化データを送信してくるので、ＮＣＳ３０３がこれを（ＰＨＹ２０４経由で）受信すると（Ｓ４０６）、復号化処理を行ってＳＯＡＰドキュメントを生成し（Ｓ４０７）、これをＮＲＳアプリ３１５に渡す（Ｓ４０８）。
ＮＲＳアプリはこのＳＯＡＰドキュメントからＳＯＡＰボディーのＸＭＬドキュメントを取得し（Ｓ４０９）、このＳＯＡＰボディーに含まれる実行を要求されたコマンドの情報をアプリにおける処理に適したデータ構造体に変換し（Ｓ４１０）、そのコマンドを実行すべきアプリに渡す（Ｓ４１１）。そして、アプリはこのコマンドに係る動作を実行させるべく、必要な実行モジュールに対して動作の実行を指示し（Ｓ４１２）、実行モジュールはこれに応じてハードウェア資源を制御して動作を実行させ（Ｓ４１３）、その結果をアプリに返す（Ｓ４１４）。アプリは受け取った実行結果をデータ構造体の形式でＮＲＳアプリ３１５に渡す（Ｓ４１５）。

すると、ＮＲＳアプリ３１５はこの実行結果をＸＭＬドキュメントに変換して応答のＳＯＡＰボディーとし、これを含むＳＯＡＰドキュメントを生成し（Ｓ４１６）、これをＮＣＳ３０３に渡す（Ｓ４１７）。ＮＣＳはこのＳＯＡＰドキュメントを暗号化し（Ｓ４１８）、応答のＨＴＴＰＳメッセージとして、コマンド実行要求の送信元に対して送信する（Ｓ４１９）。
認証が失敗した場合には、認証情報の送信元は暗号化データを送信しないので、当然Ｓ４０６以降の処理は行わない。

画像処理装置１００においては、以上の図１７及び図１８に示すような処理により、ネットワーク経由でコマンドの実行要求を受け付ける場合にＰＫＩ認証も行うことができるようにし、コマンドの実行要求の受け付けに先立って認証情報を受け付け、ＣＣＳ３１９によって認証処理を行い、認証が成功した場合のみコマンドの実行要求を受け付けて動作の実行を許可することができるようにしている。

以上説明してきたように、画像処理装置１００においては、認証処理を行うためにＣＣＳ３１９というサービスモジュールを用意し、ＣＰＵにこのプログラムを実行させることによって認証手段として機能させ、どのインタフェースから認証情報を受け付けたか、あるいはどの認証方式に係る認証情報を受け付けたかに関わらず、認証処理は全てその認証手段で行うようにしている。

そして、このように共通のモジュールによって認証処理を行うようにしたことにより、認証機能を、認証情報を受け付ける各インタフェースの制御手段（ここで説明した例では、ＣＰＵがＯＣＳ３００やＮＣＳ３０３を実行することによりこのような制御手段として機能する）に別々に持たせる必要がなくなり、処理体系をコンパクトにまとめることができる。また、認証の方式を変更や修正する場合でも、主にＣＣＳ３１９を変更すればよく、認証情報を受け付ける側の変更は、ＣＣＳ３１９に渡すデータの形式変更程度でよいので、容易に装置の機能や構成を変更することができる。
すなわち、認証処理に係る処理体系をコンパクトにまとめ、また設計変更の際に改変すべき部分を最低限に抑えることができるので、認証処理に要する処理負荷を低減すると共に、装置の設計・開発にかかる労力やコストを低減することができる。
また、新たに認証情報を受け付けるインタフェースを追加する場合でも、単に認証情報を適当な形式でＣＣＳ３１９に渡し、その結果を受け取ることができるようにするだけで、そのインタフェースから受け付けた認証情報について認証を行うことができるので、新たな機能を備えた装置の開発を容易に行うことができる。

上述した実施形態のように、認証情報を受け付けるインタフェースとして操作部とネットワーク通信手段とを用いるようにすれば、装置の設置先のユーザによる直接操作と、装置から離れた所にいるユーザや管理者からの遠隔操作の両方に対応できる。
また、ネットワークを介してパスワードを受け付ける場合に、構造化言語形式で記載された情報として受け付けるようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができる。ただし、この場合には構造化言語のデータ構成を解釈した上でパスワードを取り出し、認証処理に供する必要がある。

一方、公開鍵暗号を用いた認証に係る認証情報は、上述のように、他の情報と共に送信されてくるものではないので、構造化言語形式で記載する利点はあまりない。従って、むしろ受け付けたままの形式で認証処理に供することができるようにした方が、認証の際に構造化言語のデータ構成を解釈する必要がなく、処理を効率的にすることができる。
また、ここでは操作部からは認証情報としてパスワードのみを受け付ける一方、ネットワーク経由の場合にパスワードによる認証とＰＫＩ認証の両方を行うことができる例について説明したが、ネットワーク経由の場合の認証は、ＰＫＩ認証に限るようにしてもよい。パスワードよりＰＫＩ認証の方が認証情報を盗まれる可能性が低く、強いセキュリティを実現できるためである。また、認証情報を受け付けるインタフェース毎に認証方法を１種ずつに限るようにした方が、処理が簡略化でき、強いセキュリティが実現できる。ただし、認証をパスワード認証のみに限るような構成を妨げるものではない。
また、上述した実施形態において、装置本体と接続された２種類の操作部から認証情報の入力を受け付け、ＣＣＳ３１９によって各操作部から受け付けた認証情報についての認証処理を共通に行うような構成も可能であるが、このような場合には、画像処理装置１００にネットワークＩ／Ｆを設けることは必須ではない。

〔第１の変形例：図１９乃至図２４〕
次に、上述した通信システムの第１の変形例として、電子装置にネットワーク通信手段を設けた通信装置を被管理装置とする、通信装置の遠隔管理システムの構成例について説明する。図１９は、その遠隔管理システムの構成の一例を示す概念図である。
この遠隔管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像形成装置あるいは画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等の電子装置に通信機能を持たせた通信装置を被管理装置１０とする遠隔管理システムである。そして、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）によって接続された遠隔管理仲介装置である仲介装置１０１、更に仲介装置１０１とインタネット１０３（公衆回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置１０２を備え、管理センタ等に配置される当該管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。

なお、仲介装置１０１と被管理装置１０との接続は、ＬＡＮに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Small Computer System Interface）規格等に準拠したパラレル接続等によって行ってもよい。例えばＲＳ−４８５規格の場合には、仲介装置１０１に直列に５台までの被管理装置１０を接続することができる。
また、当該仲介装置１０１及び被管理装置１０は、その利用環境に応じて多様な階層構造を成す。

例えば、図１９に示す設置環境Ａでは、管理装置１０２とＨＴＴＰ（Hyper Text Transfer Protocol）による直接的なコネクションを確立できる仲介装置１０１ａが、被管理装置１０ａ及び１０ｂを従える単純な階層構造になっているが、同図に示す設置環境Ｂでは、４台の被管理装置１０を設置する為、１台の仲介装置１０１を設置しただけでは負荷が大きくなる。その為、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる仲介装置１０１ｂが、被管理装置１０ｃ及び１０ｄだけでなく、他の仲介装置１０１ｃを従え、この仲介装置１０１ｃが被管理装置１０ｅ及び１０ｆを更に従えるという階層構造を形成している。この場合、被管理装置１０ｅ及び１０ｆを遠隔管理するために管理装置１０２から発せられた情報は、仲介装置１０１ｂとその下位のノードである仲介装置１０１ｃとを経由して、被管理装置１０ｅ又は１０ｆに到達することになる。

また、設置環境Ｃのように、被管理装置１０に仲介装置１０１の機能を併せ持たせた仲介機能付被管理装置１１ａ，１１ｂを、別途仲介装置を介さずにインタネット１０３によって管理装置１０２に接続するようにしてもよい。
図示はしていないが、仲介機能付被管理装置１１の下位にさらに被管理装置１０を接続することもできる。
なお、各設置環境には、セキュリティ面を考慮し、ファイアウォール１０４を設置する。

このような遠隔管理システムにおいて、仲介装置１０１は、これに接続された被管理装置１０の制御管理のためのアプリケーションプログラムを実装している。
管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した被管理装置１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置１０も含め、この遠隔管理システムにおけるこれら各ノードは、ＲＰＣにより、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。

すなわち、仲介装置１０１又はこれと接続された被管理装置１０では、管理装置１０２への要求を生成してこれを管理装置１０２へ引き渡し、この要求に対する応答を取得できる一方で、管理装置１０２は、上記仲介装置１０１側への要求を生成してこれを仲介装置１０１側へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、仲介装置１０１に被管理装置１０に対して各種要求を送信させ、被管理装置１０からの応答を仲介装置１０１を介して取得することも含まれる。
なお、ＲＰＣを実現するために、ＳＯＡＰ等、上述のような種々のプロトコル（通信規格），技術，仕様などを利用することができる。

この送受信のデータ送受モデルを図２０の概念図に示す。なお、この図においては、ファイアウォール１０４の存在は考慮していない。
（Ａ）は、被管理装置１０で管理装置１０２に対する要求が発生したケースである。このケースでは、被管理装置１０が被管理装置側要求ａを生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこの要求に対する応答ａを返すというモデルになる。同図に示す仲介装置１０１は複数であるケースも想定できる（上記図１９に示す設置環境Ｂ）。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、管理装置１０２を、仲介装置１０１を経由して被管理装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
（Ｂ）は、管理装置１０２で被管理装置１０に対する要求が発生したケースである。このケースでは、管理装置１０２が管理装置側要求ｂを生成し、これを仲介装置１０１を経由して受け取った被管理装置１０が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。

次に、図１９に示す管理装置１０２の物理的構成について説明すると、当該管理装置１０２は、不図示のＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、ネットワークインタフェースカード（以下ＮＩＣという）等を備えている。
更に、図１９に示す仲介装置１０１の物理的構成について説明すると、当該仲介装置１０１は、不図示のＣＰＵ、ＲＯＭ、ＲＡＭ、不揮発性メモリ、ＮＩＣ等を備えている。
また、仲介機能付被管理装置１１については、仲介装置１０１の機能を実現するためにこれらのユニットを単に被管理装置１０に付加しても良いが、被管理装置１０に備えるＣＰＵ，ＲＯＭ，ＲＡＭ等のハードウェア資源を利用し、ＣＰＵに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置１０１の機能を実現することもできる。

以下、図１９に示した遠隔管理システムのより具体的な例として、この発明による電子装置の一例であり通信装置である画像処理装置を被管理装置とした、この発明による遠隔管理システムの一例である画像処理装置遠隔管理システムについて説明する。図２１は、その画像処理装置遠隔管理システムの構成の一例を示す概念図であるが、被管理装置１０を画像処理装置１００に、仲介機能付被管理装置１１を仲介機能付画像処理装置１１０に変更した点が図１９と相違するのみであるので、システムの全体構成についての説明は省略する。
画像処理装置１００は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、仲介機能付画像処理装置１１０は、画像処理装置１００に仲介装置１０１の機能を併せ持たせたものである。

次に、図２４に、管理装置１０２の概略構成例を示す。
この管理装置１０２は、モデム６１１，通信端末６１２，外部接続Ｉ／Ｆ６１３，操作者端末６１４，制御装置６１５，ファイルサーバ６１６等からなる。
モデム６１１は、図示しない公衆回線を介して機器利用者側（例えば画像処理装置を利用しているユーザ先）の仲介装置１０１又は画像処理装置１１０と通信するものであり、送受信するデータを変復調する。また、通信端末６１２は、モデム６１１による通信を制御するものである。そして、これらのモデム６１１と通信端末６１２により通信手段としての機能を果たす。

外部接続Ｉ／Ｆ６１３は、インタネット１０３あるいは専用線等によるネットワークを介した通信を行うためのインタフェースである。そして、ここを介して機器利用者側の仲介装置１０１又は画像処理装置１１０との通信を行う。また、セキュリティ管理のためのプロキシサーバ等を設けてもよい。
操作者端末６１４は、各種データの入力をオペレータによるキーボード等の入力装置上の操作により受け付ける。入力されるデータとしては、例えば、各機器利用者側の仲介装置１０１又は画像処理装置１１０と通信する際に使用するそれらのＩＰアドレスや電話番号（発呼先電話番号）等の顧客情報がある。

制御装置６１５は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。
ファイルサーバ６１６は、図示しないハードディスク装置等の記憶装置を備え、そこに各機器利用者側の仲介装置１０１および画像処理装置１１０のＩＰアドレスや電話番号、それらの装置から受信したデータ、管理対象の画像処理装置の識別情報、操作者端末６１４から入力されたデータ等の各種データをそれぞれデータベース（ＤＢ）として記憶している。

上述した構成を踏まえて、図２１の画像処理装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例について図２３を用いて説明する。図２３は、管理装置、仲介装置、及び画像処理装置間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。

この例においては、まず、仲介装置１０１は、管理装置１０２に対してポーリング（送信要求があるかどうかの問い合わせ）を行う（Ｓ６０１）。つまり、自己の識別情報である識別子を付加したポーリング用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして管理装置１０２へ送信する。図２１に示したように、仲介装置１０１と管理装置１０２との間にはファイアウォール１０４を設けているため、管理装置１０２から仲介装置１０１に向けて通信セッションを張る（通信を要求して通信経路を確立する）ことができないので、管理装置１０２から仲介装置１０１（あるいは仲介装置１０１を介して画像処理装置１００）に要求を送信したい場合でも、このように仲介装置１０１からのポーリングを待つ必要があるのである。

管理装置１０２は、仲介装置１０１から上記ＨＴＴＰメッセージを受信すると、課金カウンタ取得要求を示すＳＯＡＰドキュメントを生成し、該当する仲介装置１０１（受信したＳＯＡＰメッセージの送信元）へ、ポーリングに対する応答のＨＴＴＰメッセージとして送信する（Ｓ６０２）。このとき、受信したＨＴＴＰメッセージ内のＳＯＡＰドキュメントに付加された識別子に基づいて該当する仲介装置１０１を認識する。このように、ファイアウォール１０４の内側からの通信（ＨＴＴＰリクエスト）に対する応答（ＨＴＴＰレスポンス）であれば、ファイアウォールの外側から内側に対してデータを送信することができる。

仲介装置１０１は、管理装置１０２から上記ＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいて課金カウンタ取得要求を示すＳＯＡＰドキュメントを生成し、やはりＨＴＴＰメッセージとして自己に接続されている画像処理装置１００のＮＲＳアプリ３１５へ送信する（Ｓ６０３）。
ＮＲＳアプリ３１５は、仲介装置１０１からＨＴＴＰメッセージとして受信したＳＯＡＰドキュメントに記述されている課金カウンタ取得要求をＳＣＳ３０６へ通知する（Ｓ６０４）。
ＳＣＳ３０６は、ＮＲＳアプリ３１５から課金カウンタ取得要求の通知を受けると、ＮＶ−ＲＡＭ２０２に格納されている課金カウンタのデータを読み取る（Ｓ６０５）。そして、その読み取った課金カウンタのデータ（応答データ）をＮＲＳアプリ３１５へ引き渡す（Ｓ６０６）。

ＮＲＳアプリ３１５は、ＳＣＳ３０６から課金カウンタのデータを受け取る（取得する）と、その内容を示す課金カウンタ用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして仲介装置１０１へ送信する（Ｓ６０７）。
仲介装置１０１は、ＮＲＳアプリ３１５から課金カウンタ用のＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントをＨＴＴＰメッセージとして管理装置１０２へ送信する（Ｓ６０８）。
このように、上記通信シーケンスにより、データの送受信が行われる。

次に、上記図２３と異なり、画像処理装置１００から仲介装置１０１を経て管理装置１０２へデータを送信する場合の通信シーケンスの一例について図２４を用いて説明する。
図２４は、画像処理装置から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、ＯＣＳ３００は、ユーザコールキーが押下された旨をＳＣＳ３０６へ通知する（Ｓ７０１）。
ＳＣＳ３０６は、ＯＣＳ３００からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をＮＲＳアプリ３１５へ通知する（Ｓ７０２）。

ＮＲＳアプリ３１５は、ＳＣＳ３０６からユーザコール要求の通知を受けると、ユーザコールを知らせるユーザコール情報であるユーザコール用のＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとして仲介装置１０１へ送信する（Ｓ７０３）。
仲介装置１０１は、ＮＲＳアプリ３１５からユーザコール用のＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントに自己の識別情報である識別子を付加し、そのＳＯＡＰドキュメントをやはりＨＴＴＰメッセージとして管理装置１０２に対して送信し、ユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のＳＯＡＰドキュメントを管理装置１０２へ通報する（Ｓ７０４）。この場合には、ファイアウォール１０４の内側から外側に向けての送信であるので、仲介装置１０１が自ら管理装置１０２に向けてセッションを張ってデータを送信することができる。
ここで、ステップＳ７０４の処理後のパターンを以下の（Ａ）から（Ｃ）に分けて説明する。

まず、（Ａ）において、管理装置１０２は、ユーザ先の仲介装置１０１からユーザコール用のＳＯＡＰドキュメントをＨＴＴＰメッセージとして受信し、その受信が正常に終了した場合には、その旨（ユーザコールが成功した旨）のコール結果を、正常に終了しなかった（異常に終了した）場合には、その旨（ユーザコールが失敗した旨）のコール結果を示すＳＯＡＰドキュメント生成し、ＨＴＴＰメッセージによる応答として通報元の仲介装置１０１へ送信する（Ｓ７０５）。
仲介装置１０１は、管理装置１０２からコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントを、やはりＨＴＴＰメッセージとしてユーザコールキーが押下された画像処理装置１００のＮＲＳアプリ３１５へ送信する（Ｓ７０６）。

ＮＲＳアプリ３１５は、仲介装置１０１からコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントが示すコール結果を解釈（判定）し、ＳＣＳ３０６へ通知する（Ｓ７０７）。
ＳＣＳ３０６は、コール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７０８）。

次に（Ｂ）において、仲介装置１０１は、規定時間（予め設定された所定時間）が経っても管理装置１０２から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果を示すＳＯＡＰドキュメントを生成し、ＨＴＴＰメッセージとしてＮＲＳアプリ３１５へ送信する（Ｓ７０９）。
ＮＲＳアプリ３１５は、失敗した旨のコール結果を示すＳＯＡＰドキュメントを受信すると、そのＳＯＡＰドキュメントに記述されている失敗した旨のコール結果を解釈し、ＳＣＳ３０６へ通知する（Ｓ７１０）。
ＳＣＳ３０６は、ＮＲＳアプリ３１５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。

ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１１）。
次に（Ｃ）において、ＮＲＳアプリ３１５は、規定時間が経っても仲介装置１０１から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をＳＣＳ３０６へ通知する（Ｓ７１２）。
ＳＣＳ３０６は、ＮＲＳアプリ３１５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１３）。

なお、ここでは管理装置１０２からファイアウォール１０４を越えて仲介装置１０１（あるいは仲介装置１０１を介して画像処理装置１００）にデータを送信するために、仲介装置１０１からのＨＴＴＰリクエストに対するレスポンスという形で送信を行う例について説明したが、ファイアウォール１０４を越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を利用して、送信したいデータを記載あるいは添付したメールを管理装置１０２から仲介装置１０１に送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。

以上のような遠隔管理システムにおいても、上述の実施形態の場合と同様な構成とし、同様な認証処理を行わせることにより、上述の実施形態の場合と同様な効果を得ることができる。この場合において、管理装置１０２がコマンド実行要求等の送信元となる外部装置に該当する。また、この遠隔管理システムにおける画像処理装置１００は仲介装置１０１を間に置いて管理装置１０２と通信するが、この場合でも直接通信する場合と同様な認証動作を行うことができる。
なお、このような遠隔管理システムについて、被管理装置，仲介装置，管理装置の構成及びこれらの接続形式は、以上説明したものに限られるものではない。これら各装置の間の通信も、有線，無線を問わず、各種通信回線（通信経路）を用いて行うことができる。

〔第２の変形例：図２５，図２６〕
次に、上述した実施形態の第２の変形例について説明する。この変形例は、上述の第１の変形例と組み合わせて適用すると好ましい。
この変形例においては、上述した実施形態において認証が成功した場合には必ずコマンドの実行を許可するようにしていたのに対し、認証が成功した場合でも所定の場合にはコマンドの実行を制限するようにした点が特徴である。

画像処理装置１００が記憶している情報は、その種類に応じて公開されるべき対象が異なることが考えられる。例えば、読み取った画像データ等の画像情報や、ＦＡＸによる画像データの送信先情報やアドレス帳等のユーザ情報は、画像処理装置１００の設置先のユーザが記憶させる情報であり、このユーザには公開されるべきものであるが、機密情報が含まれることも多いので、外部に公開することは適当でない。また、画像処理装置１００の遠隔管理や保守の契約を結ぶ場合において、画像処理装置１００にカウンタを設けて画像形成枚数をカウントし、このカウント値に応じて料金を課金することが行われるが、この場合のカウント値は、サービスを提供する管理者側には公開されるべき情報である一方、設置先のユーザがアクセスして改変できるようにすることは適当でない。動作ログについても、ユーザ側で改変できないようにした方が、管理者側で適切な管理を行うことができる場合が多いと考えられる。

そして、装置の設置先のユーザは、装置が近くにあることから、操作パネル２０５からパスワードを入力して認証を受けることが多く、管理者はネットワーク経由でアクセスして認証を受けることが多いと考えられる。さらに、管理者は数多くの装置にアクセスする必要があるため、機器毎に異なるパスワードよりも、一度発行された私有鍵をどの装置に対しても使用できるＰＫＩ認証を利用した方が効率的に管理を行うことができると考えられる。

そこで、例えば図２５に示すように、パスワードによる認証を行った場合にはユーザ情報や画像情報へのアクセスは許可する（○で示す）が管理情報へのアクセスは許可せず（×で示す）、ＰＫＩ認証を行った場合には逆に管理情報へのアクセスは許可するがユーザ情報と画像情報へのアクセスは許可しないようにして、パスワードによって認証を行った場合とＰＫＩ認証を行った場合とで、認証対象に対してアクセスを許可する情報を切り換えることができるようにするとよい。ここで、ユーザ情報や画像情報は、画像処理装置１００を設置しているユーザに公開すべき内部情報の例であり、管理情報は、画像処理装置１００の遠隔管理を行う管理者等の、ネットワークを介した通信先に公開すべき外部情報の例である。もちろん、内部情報と外部情報の両方に該当する情報があってもよい。
このようにすれば、ユーザは管理者の私有鍵を持たないため外部情報にアクセスすることができず、管理者はユーザが定めたパスワードを知らなければ内部情報にアクセスすることができない。従って、各々必要な情報のみにアクセス可能な状態となり、セキュリティを保ちながら遠隔管理を効率的に行うことができる。

なお、画像処理装置１００に管理用パスワードを記憶させておき、その管理用パスワードを用いてパスワードによる認証を行った場合には内部情報に代えて外部情報に対してアクセスを許可するようにしてもよい。このようにすれば、管理者等が装置の設置先を訪問して直接操作する場合でも、外部情報を参照して適切な保守作業を行うことができる。逆に、ＰＫＩ認証の場合も、ユーザであると認証した場合には内部情報に対するアクセスを許可するようにしてもよい。

アクセスを許可する情報を制限する方式としては、例えば、認証を要求する際にＣＣＳ３１９に、パスワードと共に実行を要求されたコマンドや、そのコマンドの実行に関与するアプリや実行モジュールの情報を渡し、認証処理にこれらの情報も加味することが考えられる。この場合、アクセスを許可できない情報を対象としたコマンドの場合には、パスワードが正しくても認証失敗とすることになる。
あるいは、コマンド及びそのコマンドの実行に関与するアプリや実行モジュール毎に、実行を許可してよいか否かの情報を認証の種類に応じて記憶しておき、ＣＣＳ３１９による認証が成功した後、ＮＲＳアプリ３１５がこの情報を参照して最終的な実行可否を判断するようにしてもよい。
これらの処理を組み合わせて判断するようにしてもよい。

図２６に、このようなアクセス制限を行う際に参照するデータの例を示す。この例では、認証方式毎に実行を許可するコマンドをテーブル形式で記憶しており、ＣＣＳ３１９やＮＲＳアプリ３１５がこのテーブルを参照することにより、認証方式に応じて、実行要求に係るコマンドが実行を許可してよいコマンドか否かを判断することができる。
なお、これらの場合において、内部情報と外部情報とを論理的あるいは物理的に別々のハードウェアに記憶させておくようにすると、コマンドに係る動作によって参照する情報が明確に区別でき、コマンド実行可否の判断が容易になる。
また、ここでは遠隔管理や保守を例として説明したが、内部情報と外部情報の区別は、この目的に限られるものではない。内部情報と外部情報に含まれる情報の種類も、上述したものに限られることはない。

〔その他の変形例：図２７乃至図３０〕
また、以上の実施形態においては、電子装置、あるいは被管理装置とする通信装置の例として通信機能を備えた画像処理装置について主に説明したが、この発明はこれに限られるものではなく、通信機能を備えたネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種電子装置に適用可能である。

例えば、図１９に示した遠隔管理システムにおいて、これらの各装置を被管理装置とし、図２７に示すような遠隔管理システムを構成することが考えられる。この図においては、仲介装置１０１を別途設ける被管理装置の例としてテレビ受像機１２ａや冷蔵庫１２ｂのようなネットワーク家電、および医療機器１２ｃ，自動販売機１２ｄ，計量システム１２ｅ，空調システム１２ｆを挙げている。そして、仲介装置１０１の機能を併せ持つ被管理装置の例として、自動車１３ａや航空機１３ｂを挙げている。また、自動車１３ａや航空機１３ｂのように広範囲を移動する装置においては、ファイアウォール１０４の機能も併せ持つようにすることが好ましい。このような遠隔管理システムやそのシステムにおいて被管理装置となる各装置にも、この発明はもちろん適用可能である。
そして、例えば自動車であれば距離メータや速度メータのような計器類の測定内容等を外部情報、カーナビゲーションシステムに登録した住所や目的地等を内部情報として、第２の変形例のようにアクセス可否を判断するようにすることが考えられる。

認証情報を受け付けるインタフェースについても、上述した操作パネルやウェブブラウザに限られるものではなく、認証処理の方式も、上述した方式に限られるものではない。
例えば、ＰＫＩ認証を行う場合において、ＳＳＬ（Secure Socket Layer）の技術を利用することも考えられる。通信システムを構成する２つのノードがこのＳＳＬに従った相互認証を行う場合の通信手順は、認証処理の部分に焦点を当てて説明すると、以下のようなものである。図２８は、通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図２８に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置に、ルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。

図２９にこれらの関係を示す。
図２９（ａ）に示すように、公開鍵Ａは、私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ）や有効期間等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Ａをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Ａである。

この公開鍵証明書Ａを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、公開鍵Ａの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Ａを用いて正常に復号化できれば、そのデータは、私有鍵Ａの持ち主から送信されたものであることがわかる。

ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図２９（ｂ）に示すように、ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。

図２８のフローチャートの説明に入る。なお、この図において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。

ここでは、通信装置Ａが通信装置Ｂに通信を要求するものとするが、この要求を行う場合、通信装置ＡのＣＰＵは、所要の制御プログラムを実行することにより、図２８の左側に示すフローチャートの処理を開始する。そして、ステップＳ５１１で通信装置Ｂに対して接続要求を送信する。
一方通信装置ＢのＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図２８の右側に示すフローチャートの処理を開始する。そして、ステップＳ５２１で第１の乱数を生成し、これを私有鍵Ｂを用いて暗号化する。そして、ステップＳ５２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。

通信装置Ａ側では、これを受信すると、ステップＳ５１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。
そして確認ができると、ステップＳ５１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。
その後、ステップＳ５１４でこれとは別に第２の乱数及び第３の乱数を生成する。そして、ステップＳ５１５で第２の乱数を私有鍵Ａを用いて暗号化し、第３の乱数を公開鍵Ｂを用いて暗号化し、ステップＳ５１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。第３の乱数の暗号化は、通信相手以外の装置に乱数を知られないようにするために行うものである。

通信装置Ｂ側では、これを受信すると、ステップＳ５２３でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると、ステップＳ５２４で、受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。
その後、ステップＳ５２５で私有鍵Ｂを用いて第３の乱数を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通の第１乃至第３の乱数が共有されたことになる。そして、少なくとも第３の乱数は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、ステップＳ５２６でクライアント装置に対して認証成功の応答を返す。

通信装置Ａ側では、これを受信すると、ステップＳ５１７で第１乃至第３の乱数から共通鍵を生成し、以後の通信の暗号化に用いるものとして認証処理を終了する。サーバ装置側でも、ステップＳ５２７で同様の処理を行って終了する。そして、以上の処理によって互いに通信を確立し、以後はステップＳ５１７又はＳ５２７で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行う。

このような処理を行うことにより、通信装置Ａと通信装置Ｂが互いに相手を認証した上で安全に共通鍵を交換することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第２の乱数を公開鍵Ａで暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。この場合、通信装置Ｂ側のステップＳ５２３及びＳ５２４の処理は不要になり、処理は図３０に示すようになる。このようにすると、通信装置Ｂが通信装置Ａを認証することはできないが、通信装置Ａが通信装置Ｂを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Ａに記憶させるのはルート鍵証明書のみでよく、私有鍵Ａ及び公開鍵証明書Ａは不要である。また、通信装置Ｂにはルート鍵証明書を記憶させる必要はない。

以上のような認証処理を行う場合において、共通鍵暗号方式による通信経路を確立した後でＩＤやパスワード等の識別情報を受信し、通信相手を認証するようにしてもよい。
また、公開鍵証明書に、書誌情報として発行先装置の識別情報を記載しておくようにすれば、ステップＳ５１２やＳ５２３の処理で公開鍵証明書の正当性を確認できた段階で、その識別情報をもとに、通信相手が適切な相手であるか否かを判断することができる。そして、その後乱数の復号化が成功すれば、通信相手が確かにその公開鍵証明書に記載された識別情報の持ち主であることがわかる。この場合においては、公開鍵証明書が認証情報に該当する。また、以上のような認証処理は、ＣＣＳ３１９がＤＥＳＳ３１８を利用して行うものである。

また、この発明によるプログラムは、上述のような電子装置を制御するコンピュータに、この発明による各機能（認証情報受付手段，認証手段，その他の手段としての機能）を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。このコンピュータは、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段とを有するコンピュータであるとよい。

また、このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

以上説明してきたように、この発明の電子装置、画像処理装置、遠隔管理システム、認証方法、あるいはプログラムによれば、認証処理に要する処理体系をコンパクトにまとめ、また設計変更の際に改変すべき部分を最低限に抑えることができるので、認証処理に係る処理負荷を低減すると共に、装置の設計・開発にかかる労力やコストを低減することができる。
従って、この発明を、電子装置あるいは電子装置を管理する遠隔管理システムに適用することにより、低コストの電子装置あるいは遠隔管理システムを提供することができる。

この発明の電子装置の実施形態である画像処理装置と、その画像処理装置の通信相手となる外部装置とによって構成した通信システムの構成例を示す図である。 その通信システムを構成する画像処理装置のハードウェア構成例を示すブロック図である。 その画像処理装置のソフトウェア構成例を示すブロック図である。 その画像処理装置におけるＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号について説明するための図である。 その画像処理装置におけるＮＲＳアプリの構成例を示す機能ブロック図である。 図１に示した画像処理装置においてパスワードによる認証を行う場合の処理手順について説明するための図である。 コマンド実行要求用のＳＯＡＰドキュメントのフォーマット例を示す図である。 そこに含まれる主要な情報について説明するための図である。 ＰＫＩ認証を行う場合の処理手順について説明するための図６と対応する図である。 操作パネルに表示するパスワード入力画面の表示例を示す図である。

画像処理装置における従来の認証方式に係る処理を示すフローチャートである。 図１１のフローチャートに示した処理による処理シーケンスの一例を示す図である。 図１に示した画像処理装置における認証に係る処理のうち、操作パネルからパスワードの入力を受け付ける場合の処理を示すフローチャートである。 図１３のフローチャートに示した処理による処理シーケンスの一例を示す図である。 図１に示した画像処理装置における認証に係る処理のうち、ネットワークを介してパスワードの入力を受け付ける場合の処理を示すフローチャートである。 図１５のフローチャートに示した処理による処理シーケンスの一例を示す図である。 図１に示した画像処理装置における認証に係る処理のうち、ネットワークを介して受信するコマンド実行要求についてＰＫＩ認証を行う場合の処理を示すフローチャートである。 図１７のフローチャートに示した処理による処理シーケンスの一例を示す図である。 この発明の実施形態の変形例に係る遠隔管理システムの構成例を示す概念図である。 その遠隔管理システムにおけるデータ送受モデルを示す概念図である。

図１９に示した遠隔管理システムにおいて画像処理装置を被管理装置とした場合の具体例として、画像処理装置遠隔管理システムの構成例を示す概念図である。 図２１に示した管理装置１０２の概略構成例を示すブロック図である。 図２１に示した画像処理装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例を示す図である。 図２１に示した画像処理装置から管理装置へデータを送信する場合の通信シーケンスの一例を示す図である。 この発明の実施形態の第２の変形例に係る、認証方式によるデータへのアクセス制限について説明するための図である。 このようなアクセス制限を行う際に参照するデータの例を示す図である。 図１９に示した遠隔管理システムの別の構成例を示す図である。 ２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図２８に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。 ２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図２８と対応する図である。

符号の説明

１０：被管理装置 １１：仲介機能付被管理装置
１００：画像処理装置 １０１：仲介装置
１０２：管理装置 １０３：インタネット
１０４：ファイアウォール
１１０：仲介機能付画像処理装置
１２０：外部装置 １３０：ネットワーク
２００：コントローラボード ２０１：ＨＤＤ
２０２：ＮＶ−ＲＡＭ ２０３：ＰＩボード
２０４：ＰＨＹ ２０５：操作パネル
２０６：プロッタ／スキャナエンジンボード
２０７：電源ユニット ２１２：ＰＣＩ−ＢＵＳ
３００：ＯＣＳ ３０１：ＥＣＳ
３０２：ＭＣＳ ３０３：ＮＣＳ
３０４：ＦＣＳ ３０５：ＣＳＳ
３０６：ＳＣＳ ３０７：ＳＲＭ
３０８：ＩＭＨ ３０９：コピーアプリ
３１０：ファクスアプリ ３１１：プリンタアプリ
３１２：スキャナアプリ
３１３：ネットファイルアプリ ３１４：ウェブアプリ
３１５：ＮＲＳアプリ ３１６：ＤＣＳ
３１７：ＵＣＳ ３１８：ＤＥＳＳ
３１９：ＣＣＳ
６０１：モデム ６０２：通信端末
６０３：プロキシサーバ ６０４：操作者端末
６０５：データベース ６０６：制御装置

Claims (20)

1. 操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを設け、
   認証情報の入力を受け付ける認証情報受付手段として、前記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手段と、前記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手段とを設け、
   前記第１の認証情報受付手段から受け付けた前記第１の認証情報についての認証処理及び前記第２の認証情報受付手段から受け付けた前記第２の認証情報についての認証処理を行う認証手段を設け、
   前記認証手段が前記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と前記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、該認証処理によって認証した相手に対して前記認証手段がアクセスを許可する情報の範囲が異なることを特徴とする電子装置。
2. 請求項１記載の電子装置であって、
   ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、前記ハードウェア資源と前記各アプリケーション制御手段との間に介在し、複数の前記アプリケーション制御手段からの前記ハードウェア資源に対する動作要求の受付，該動作要求の調停，および該動作要求に基づく動作の実行制御を行うサービス制御手段とを設け、
   前記認証手段を前記サービス制御手段に設けたことを特徴とする電子装置。
3. 請求項１又は２記載の電子装置であって、
   前記認証手段は、前記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、前記ネットワーク通信手段を介して受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う手段であることを特徴とする電子装置。
4. 請求項１乃至３のいずれか１項記載の電子装置であって、
   前記認証手段は、前記第１の認証情報による認証処理を行った場合には当該電子装置を設置しているユーザに公開すべき内部情報に対してアクセスを許可し、前記第２の認証情報による認証処理を行った場合には前記ネットワーク通信手段による通信先に公開すべき外部情報に対してアクセスを許可する手段を有することを特徴とする電子装置。
5. 請求項４記載の電子装置であって、
   前記ネットワークを介して通信可能な管理装置から遠隔管理のための要求を受け付けてこれに対する応答を返す手段を有し、
   前記外部情報は、前記遠隔管理を行う管理者に公開すべき情報であることを特徴とする電子装置。
6. 請求項４又は５記載の電子装置であって、
   管理用パスワードを記憶する手段を有し、
   前記認証手段は、該管理用パスワードを用いて前記第１の認証情報による認証処理を行った場合には前記内部情報に代えて前記外部情報に対してアクセスを許可する手段を有することを特徴とする電子装置。
7. 操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段と、画像データを処理する画像処理手段とを設けた画像処理装置であって、
   認証情報の入力を受け付ける認証情報受付手段として、前記操作部からパスワードの入力を受け付ける第１の認証情報受付手段と、前記ネットワーク通信手段によって公開鍵暗号を用いた認証処理に用いる認証情報の入力を受け付ける第２の認証情報受付手段とを設け、
   パスワードによる認証処理を行う手段と、公開鍵暗号を用いた認証処理を行う手段とを含み、前記操作部から入力を受け付けたパスワードによる認証処理を行った場合には当該画像処理装置を設置しているユーザに公開すべき内部情報に対してアクセスを許可し、前記ネットワーク通信手段によって入力を受け付けた認証情報によって公開鍵暗号を用いた認証処理を行った場合には前記ネットワーク通信手段による通信先に公開すべき外部情報に対してアクセスを許可する認証手段を有することを特徴とする画像処理装置。
8. 請求項７記載の画像処理装置であって、
   ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、前記ハードウェア資源と前記各アプリケーション制御手段との間に介在し、複数の前記アプリケーション制御手段からの前記ハードウェア資源に対する動作要求の受付，該動作要求の調停，および該動作要求に基づく動作の実行制御を行うサービス制御手段とを設け、
   前記認証手段を、前記サービス制御手段に設けたことを特徴とする画像処理装置。
9. 請求項７又は８記載の画像処理装置であって、
   前記画像処理手段によって画像データを処理した回数をカウントするカウント手段と、
   該手段によるカウント値、当該画像処理装置の動作ログ、および前記画像データを記憶する手段とを有し、
   前記画像データを前記内部情報とし、
   前記カウント値及び前記動作ログを前記外部情報としたことを特徴とする画像処理装置。
10. 請求項７又は８記載の画像処理装置であって、
    前記画像データを外部装置に送信する画像データ送信手段と、
    当該画像処理装置の動作ログおよび前記画像データ送信手段による画像データの送信先情報を記憶する手段とを有し、
    前記送信先情報を前記内部情報とし、
    前記動作ログを前記外部情報としたことを特徴とする画像処理装置。
11. 管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、
    前記各通信装置において、
    操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを設け、
    認証情報の入力を受け付ける認証情報受付手段として、前記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手段と、前記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手段とを設け、
    前記第１の認証情報受付手段から受け付けた前記第１の認証情報についての認証処理及び前記第２の認証情報受付手段から受け付けた前記第２の認証情報についての認証処理を行う認証手段を設け、
    前記認証手段が前記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と前記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、該認証処理によって認証した相手に対して前記認証手段がアクセスを許可する情報の範囲が異なることを特徴とする遠隔管理システム。
12. 請求項１１記載の遠隔管理システムであって、
    前記通信装置に、
    ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、
    前記ハードウェア資源と前記各アプリケーション制御手段との間に介在し、複数の前記アプリケーション制御手段からの前記ハードウェア資源に対する動作要求の受付，該動作要求の調停，および該動作要求に基づく動作の実行制御を行うサービス制御手段とを設け、
    該通信装置において、前記認証手段を前記サービス制御手段に設けたことを特徴とする遠隔管理システム。
13. 請求項１１又は１２記載の遠隔管理システムであって、
    前記通信装置の前記認証手段は、前記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、前記ネットワーク通信手段を介して受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う手段であることを特徴とする遠隔管理システム。
14. 請求項１１乃至１３のいずれか一項記載の遠隔管理システムであって、
    前記通信装置の前記認証手段は、前記第１の認証情報による認証処理を行った場合には前記通信装置を設置しているユーザに公開すべき内部情報に対してアクセスを許可し、前記第２の認証情報による認証処理を行った場合には前記管理装置による遠隔管理を行う管理者に公開すべき外部情報に対してアクセスを許可する手段を有することを特徴とする遠隔管理システム。
15. 操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを有する電子装置を制御するコンピュータを、
    それぞれ認証情報の入力を受け付ける認証情報受付手段である、前記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手段及び前記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手段と、
    前記第１の認証情報受付手段から受け付けた前記第１の認証情報についての認証処理及び前記第２の認証情報受付手段から受け付けた前記第２の認証情報についての認証処理を行う認証手段として機能させるためのプログラムであって、
    前記認証手段が前記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と前記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、該認証処理によって認証した相手に対して前記認証手段がアクセスを許可する情報の範囲が異なることを特徴とするプログラム。
16. 請求項１５記載のプログラムであって、
    前記コンピュータを、
    ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、
    前記ハードウェア資源と前記各アプリケーション制御手段との間に介在し、複数の前記アプリケーション制御手段からの前記ハードウェア資源に対する動作要求の受付，該動作要求の調停，および該動作要求に基づく動作の実行制御を行うサービス制御手段として機能させるためのプログラムを含み、
    前記認証手段の機能を、前記サービス制御手段の機能の一部として設けたことを特徴とするプログラム。
17. 請求項１５又は１６記載のプログラムであって、
    前記認証手段の機能は、前記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、前記ネットワーク通信手段を介して受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う機能であることを特徴とするプログラム。
18. 操作部と、ネットワークを介して外部装置と通信を行うネットワーク通信手段とを有する電子装置における認証方法であって、
    前記電子装置に、
    それぞれ認証情報の入力を受け付ける認証情報受付手順である、前記操作部から第１の認証情報の入力を受け付ける第１の認証情報受付手順及び前記ネットワーク通信手段によって第２の認証情報の入力を受け付ける第２の認証情報受付手順と、
    前記第１の認証情報受付手順で受け付けた前記第１の認証情報についての認証処理及び前記第２の認証情報受付手順で受け付けた前記第２の認証情報についての認証処理を共通の認証手段によって行う認証手順とを実行させ、
    前記認証手順で前記操作部から入力を受け付けた第１の認証情報によって認証処理を行った場合と前記ネットワーク通信手段によって入力を受け付けた第２の認証情報によって認証処理を行った場合とで、該認証処理によって認証した相手に対して前記認証手段がアクセスを許可する情報の範囲を異なるものとさせることを特徴とする認証方法。
19. 請求項１８記載の認証方法であって、
    前記電子装置は、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段と、前記ハードウェア資源と前記各アプリケーション制御手段との間に介在し、複数の前記アプリケーション制御手段からの前記ハードウェア資源に対する動作要求の受付，該動作要求の調停，および該動作要求に基づく動作の実行制御を行うサービス制御手段とを有する電子装置であり、
    前記共通の認証手段が、前記サービス制御手段に設けられている認証手段であることを特徴とする認証方法。
20. 請求項１８又は１９記載の認証方法であって、
    前記認証手順は、前記操作部から受け付けた第１の認証情報についてはパスワードによる認証処理を行い、前記ネットワーク通信手段から受け付けた第２の認証情報については公開鍵暗号を用いた認証処理を行う手順であることを特徴とする認証方法。

Images