JP2011044791A - 画像処理装置、及びその制御方法 - Google Patents

Abstract

【課題】 サービスマンによる保守作業をデバイス組み込みのＷｅｂブラウザから行わせる際に、サービスマン以外のユーザによるアクセスは禁止して、より確実にサービスマンからのアクセスのみを許可したい。
【解決手段】 保守用Ｗｅｂアプリケーションは、要求元のクライアントに対して、サービスモード中であるかどうかの確認を行なう。
【選択図】 図１２

Description

本発明は、ネットワークを介して接続された画像処理装置を含む情報処理システムに関するものである。

インターネット技術の発展と普及に伴い、ＰＣなどの情報処理装置がネットワーク上のＷｅｂサーバと接続され、Ｗｅｂサーバにより提供される操作画面を、情報処理装置が備えるＷｅｂブラウザ上に表示することが知られている。

この場合、情報処理装置のＷｅｂブラウザがＷｅｂサーバに対して操作画面を要求し、Ｗｅｂサーバ上のＷｅｂアプリケーションが情報処理装置からの要求に応えて、Ｗｅｂブラウザに操作画面を表示させるためのＨＴＭＬファイルを情報処理装置に送信する。情報処理装置のＷｅｂブラウザは、受信したＨＴＭＬファイルを解析し、受信したＨＴＭＬファイルの記述に基づいた操作画面を表示する。

更に、Ｗｅｂブラウザに表示された操作画面を介してユーザが指示を入力すると、入力された指示をＷｅｂブラウザがＷｅｂサーバに対して通知する。そして、この通知を受けたＷｅｂサーバ上のＷｅｂアプリケーションは、入力された指示に従って処理を実行する。

組み込みシステムの分野においても、装置が装置本来の機能に加えてウェブサーバ機能を兼ね備え、装置のユーザインタフェースを遠隔のウェブブラウザに提供するＷｅｂアプリケーションを持つ画像処理装置が製品化されている。

また、装置が装置本来の機能に加えてウェブクライアント機能を兼ね備え、装置の機能に役立てる技術が知られている。こうした装置の例として例えば、ウェブブラウザを組み込んだ画像処理装置がある。例えば特許文献１では、画像処理装置に組み込んだＷｅｂブラウザの表示画面中に原稿をスキャンするためのボタンを表示して、スキャンした画像を直接アップロードすることを可能にした画像処理装置が提案されている。

特開２００５−１４９３２０号公報

複写機、複合機などの画像処理装置では、ユーザが保守業者と保守契約を結び、定期的あるいは不具合発生時にサービスマンがユーザ先に出向き画像処理装置の保守作業を行なうことが一般に行われている。複合機はネットワーク機能を兼ね備えている場合が多く、サービスマンは保守用のPCをユーザのネットワーク環境に接続して各種保守作業（不具合調査、調整、作業報告書の作成など）を行っている。

しかしながら、近年セキュリティに気を使うユーザが増えており、サービスマンがユーザ先に出向いてもサービスマンのＰＣをユーザのネットワーク環境に接続することは許されないケースが増えている。そこで、画像処理装置の保守や、保守後の作業報告書作成を行うためのＷｅｂアプリケーションを画像処理装置本体に組み込む手法が考えられている。そして同じく画像処理装置に組み込まれた保守作業者用のＷｅｂブラウザからこれらのＷｅｂアプリケーションにアクセスすることによって作業を行なう。（なお、保守用Ｗｅｂアプリケーションが組み込まれた画像処理装置と、Ｗｅｂブラウザが組み込まれた画像処理装置は同じものであっても、別のものであっても良い。）
この場合、保守作業用のＷｅｂアプリケーションは保守作業者以外には見せられない情報が含まれている場合が多いため、ＰＣで動作する一般のＷｅｂブラウザからのアクセスはできないようにしなければならないという課題がある。保守用Ｗｅｂアプリケーションがアクセスされた際に、パスワード入力を促すようにすることも考えられるが、複数の画像処理装置を保守する場合などは何度もパスワードを入力しなければならなくなり作業効率が低くなる問題がある。

上記課題を解決するため本発明の情報処理システムは、
Ｗｅｂブラウザを持つ第一の画像処理装置と、該Ｗｅｂブラウザからの操作要求を受け付けるＷｅｂサーバ手段とを持つ第二の画像処理装置から成る情報処理システムであって、
前記第一の画像処理装置は、
前記第二の画像処理装置から問い合わせに対して応答する応答手段を持ち、
前記第二の画像処理装置は、
前記Ｗｅｂサーバ手段がＷｅｂクライアントからの操作要求を受けると、前記操作要求が、特定の装置に組み込まれたＷｅｂブラウザからの要求に対してのみ許可するべき操作に対する要求であるか否かを判断する第一の判断手段と、
前記判断手段によって、前記操作要求が、特定の装置に組み込まれたＷｅｂブラウザからの要求に対してのみ許可するべき操作に対する要求であると判断されると、前記クライアントに対して通信して問い合わせ、前記操作要求を行ったクライアントが特定の装置に組み込まれたＷｅｂブラウザであるか否かを判断する第二の判断手段と、
前記第二の判断手段によって、前記操作要求を行ったクライアントが特定の装置に組み込まれたＷｅｂブラウザであると判断された場合は操作要求を受け付け、そうで無い場合は操作要求を受け付けないように制御する制御手段と
を備えることを特徴とする。

パスワード等の入力を必要とせずに、確実にサービスマンからのアクセスだけを許可できるので利便性が高い。

本発明の実施の形態に係る画像処理装置を含むシステムの全体構成を示すブロック図である。 図１の画像処理装置１１０のソフトウェア構成を示すブロック図である。 図１の画像処理装置１１０の詳細構成を示すブロック図である。 図１の画像処理装置１１０の外観図である。 図１の操作部１１２の外観構成を示す図である。 図１の操作部１１２の詳細構成を示すブロック図である。 ウェブブラウザモジュール２１１のソフトウェア構成を示すブロック図である。 サービスモードパスワード入力画面の例を示す図である。 サービスモード画面の例を示す図である。 ＵＩインタフェース２０１によってＬＣＤ５０１に表示されるウェブブラウザの画面構成を示す図である。 本発明の第１実施の形態における、処理の手順を示すフローチャートである。 本発明の第２実施の形態における、処理の手順を示すフローチャートである。 本発明の第３実施の形態における、処理の手順を示すフローチャートである。 画像処理装置１１０のＷｅｂブラウザによって表示される画面の例を示す図である。 ホストコンピュータ１０１のＷｅｂブラウザによって表示される画面の例を示す図である。

以下に、本発明の実施形態を説明する。

（第１の実施形態）
図１は本発明の第１実施の形態に係る画像処理装置を含むシステムの全体構成を示すブロック図である。

ホストコンピュータ１０１、画像処理装置１１０，１２０，１３０などの複数のネットワーク機器と、ネットワーク機器群が接続されているＬＡＮ１００から構成される。

画像処理装置１１０は、画像の入出力と送受信および各種の画像処理を行う複合機（ＭＦＰ；Multi Function Peripheral）である。画像処理装置１１０は、画像入力デバイスであるスキャナ１１３、画像出力デバイスであるプリンタ１１４、コントロールユニット１１１、およびユーザインタフェースである操作部１１２を備える。スキャナ１１３、プリンタ１１４、操作部１１２は、それぞれ、コントロールユニット１１１に接続され、コントロールユニット１１１からの命令によって制御される。コントロールユニット１１１は、ＬＡＮ１００に接続されている。

各画像処理装置１２０，１３０は、画像処理装置１１０と同様の機器構成を有し、それらは同様にＬＡＮ１００に接続されている。画像処理装置１２０は、スキャナ１２３、プリンタ１２４、操作部１２２、およびスキャナ１２３、プリンタ１２４、操作部１２２のそれぞれを制御するコントロールユニット１２１を備える。また、画像処理装置１３０は、スキャナ１３３、プリンタ１３４、操作部１３２、およびスキャナ１３３、プリンタ１３４、操作部１３２を制御するコントロールユニット１３１を備える。

ホストコンピュータ１０１は、ＬＡＮ１００に接続されている。ホストコンピュータ１０１は、後述するようにウェブブラウザを備え、画像処理装置１１０，１２０，１３０から受信したＨＴＭＬファイルに基づいて、画像処理装置１１０，１２０，１３０のスタータスなどを表示する。

次に、画像処理装置１１０のソフトウェア構成について図２を参照しながら説明する。図２は図１の画像処理装置１１０のソフトウェア構成を示すブロック図である。ここでは、各画像処理装置１１０，１２０，１３０のソフトウェア構成は、同じであるので、画像処理装置１１０のソフトウェア構成を説明するものとする。

画像処理装置１１０においては、ユーザインタフェース（以下、ＵＩ）モジュール２０１が搭載されている。このＵＩモジュール２０１は、オペレータが画像処理装置１１０に対する各種操作・設定を行う際に、機器とユーザ操作との仲介を行うモジュールである。このＵＩモジュール２０１は、オペレータの操作に従い、後述の各種モジュールに入力情報を転送して処理の依頼、またはデータの設定などを行う。

また、アドレスブック（Address-Book）モジュール２０２が搭載されており、このモジュール２０２は、データの送付先、通信先などを管理するデータベースモジュールである。アドレスブックモジュール２０２が管理するデータに関しては、ＵＩモジュール２０１からの操作によりデータの追加、削除、取得が可能である。また、アドレスブックモジュール２０２は、オペレータの操作により後述の各モジュールにデータの送付・通信先情報を与える。

また、ウェブサーバモジュール（Web-Serverモジュール）２０３が搭載されている。このモジュール２０３は、Ｗｅｂサーバ機能と、Ｗｅｂサーバ機能の上で動作する各種Ｗｅｂアプリケーションから構成される。ウェブクライアント（例えばホストコンピュータ１０１）からの要求により、画像処理装置１１０の管理情報をウェブクライアントに通知したり、各種処理を行うものである。後述する保守用のＷｅｂアプリケーションもこのウェブサーバモジュール２０３に含まれる。

また、ウェブブラウザ（Web Browser）モジュール２１１が搭載されており、このモジュールは、インターネットまたはイントラネット上の各種ウェブサイト（ホームページ）の情報を読み込んで表示を行うものである。このウェブブラウザモジュール２１１の詳細な構成は後述する。

統合送信部（Universal-Send）モジュール２０４は、データの配信を司るモジュールであり、このモジュール２０４は、ＵＩモジュール２０１を介してオペレータによって指示されたデータを、同様にして指示された通信（出力）先に配布する。また、統合送信部（Universal-Send）モジュール２０４は、オペレータにより本機器のスキャナ機能を使用して配布データの生成が指示された場合は、制御ＡＰＩモジュール２１８を介して機器を動作させ、データの生成を行う。統合送信部モジュール２０４は、出力先にプリンタが指定された際に実行されるモジュール（P550）２０５と、通信先にE-mailアドレスが指定された際に実行されるモジュール（E-mail）２０６と、出力先にデータベースが指定された際に実行される（DB）モジュール２０７と、出力先に本機器と同様の画像処理装置が指定された際に実行される（DP）モジュール２０８とを含む。

リモートコピースキャン（Remote-Copy-Scan）モジュール２０９は、画像処理装置１１０のスキャナ機能を使用して画像情報を読み取り、読み取った画像情報をネットワーク等で接続された他の画像処理装置に出力する。これによって、画像処理装置単体で実現しているコピー機能を他の画像処理装置を使って行うことを可能にする。

リモートコピープリント（Remote-Copy-Print）モジュール２１０は、ネットワーク等で接続された他の画像処理装置で得られた画像情報を、本画像処理装置１１０のプリンタ機能を使用して出力する。これによって、画像処理装置単体で実現しているコピー機能を他の画像処理装置を使って行うことを可能にする。

ＨＴＴＰモジュール２１２は、画像処理装置１１０がＨＴＴＰによる通信を行なう際に使用され、後述のＴＣＰ／ＩＰ通信モジュール２１６を使って、ウェブサーバモジュール２０３やウェブブラウザモジュール２１１に通信機能を提供する。また、このモジュール２１２は、ＨＴＴＰをはじめとするウェブで用いられる各種プロトコルに対応し、特にセキュリティ対応したプロトコルによる通信機能を提供する。

また、ｌｐｒモジュール２１３が搭載されており、このモジュールは、後述のＴＣＰ／ＩＰ通信モジュール２１６を使って、統合送信部モジュール２０４内のモジュール２０５に通信機能を提供するものである。

また、ＳＭＴＰモジュール２１４が搭載されており、このモジュールは、後述のＴＣＰ／ＩＰ通信モジュール２１６を使って、統合送信部モジュール２０４内のE-mailモジュール２０６に通信機能を提供する。

また、ＳＬＭ（Salutation-Manager）モジュール２１５が搭載されている。このモジュールは、後述のＴＣＰ／ＩＰ通信モジュール２１６を使って、統合送信部モジュール２０４内のモジュール２１７およびモジュール２１８と、リモートコピースキャンモジュール２０９と、リモートコピープリントモジュール２１０とのそれぞれに通信機能を提供する。

ＴＣＰ／ＩＰ通信モジュール２１６は、ネットワークドライバ２１７を用いて、前述の各種モジュールにネットワーク通信機能を提供する。ネットワークドライバ２１７は、ネットワークに物理的に接続される部分を制御するものである。

制御ＡＰＩ２１８は、統合送信部モジュール２０４などの上流モジュールに、後述のジョブマネージャモジュール（Job-Manager）２１９などの下流モジュールに対するインタフェースを提供するものである。これによって、上流および下流のモジュール間の依存関係が軽減され、それぞれの流用性を高めることができる。また、制御ＡＰＩ２１８は前述のＴＣＰ／ＩＰ通信モジュール２１６を用いて、ネットワーク上のクライアントからの要求を受け付け、問い合わせに対する応答や要求に応じた制御も行う。

ジョブマネージャモジュール（Job-Manager）２１９は、前述の各種モジュールから制御ＡＰＩ２１８を介して指示される様々な処理を解釈し、後述の各モジュール２２０，２２４，２２６に指示を与えるものである。また、ジョブマネージャモジュール２１９は、画像処理装置１１０内で実行されるハード的な処理を一元管理するものである。

モジュール２２０は、コーデックマネージャ（CODEC-Manager）モジュールであり、このモジュールは、ジョブマネージャモジュール２１９が指示する処理の中で、データの各種圧縮・伸長を管理・制御するものである。

また、ＦＢＥエンコーダモジュール（FBE-Encoder）２２１が搭載されている。このモジュールは、ジョブマネージャモジュール２１９や後述のスキャンマネージャ（Scan-Manager）モジュール２２４によって実行されたスキャン処理によって読み込まれたデータを、ＦＢＥフォーマットを用いて圧縮する。

さらに、ＪＰＥＧコーデックモジュール（JPEG-CODEC）２２２が搭載されている。このモジュールは、ジョブマネージャモジュール２１９やスキャンマネージャモジュール２２４によって実行されたスキャン処理、またはプリントマネージャ（Print-Manager）モジュール２２６によって実行された印刷処理において、読み込まれたデータのＪＰＥＧ圧縮および印刷データのＪＰＥＧ展開処理を行うものである。

また、ＭＭＲコーデック（MMR-CODEC）モジュール２２３が搭載されている。このモジュールは、ジョブマネージャモジュール２１９やスキャンマネージャモジュール２２４によって実行されたスキャン処理、またはプリントマネージャモジュール２２６によって実行された印刷処理において、読み込まれたデータのＭＭＲ圧縮および印刷データのＭＭＲ伸長処理を行うものである。

スキャンマネージャ（Scan-Manager）モジュール２２４は、ジョブマネージャモジュール２１９が指示するスキャン処理を管理・制御するものである。スキャンマネージャモジュール２２４と画像処理装置１１０に内部的に接続しているスキャナ１１３との間の通信が、ＳＣＳＩドライバ２２５を介して行われる。

プリントマネージャ（Print−Manager）モジュール２２６は、ジョブマネージャモジュール２１９が指示する印刷処理を管理・制御するものである。プリントマネージャモジュール２２６とプリンタ１１４との間のインタフェースがエンジンインタフェース（Engine-I/F）モジュール２２７により提供される。

また、パラレルポートドライバ２２８が搭載されており、パラレルポートを介して不図示の出力機器にデータを出力する際のＩ／Ｆを提供する。

次に、画像処理装置１１０の構成について図３を参照しながら説明する。図３は図１の画像処理装置１１０の詳細構成を示すブロック図である。ここでは、各画像処理装置１１０，１２０，１３０の構成は、同じであるので、画像処理装置１１０の構成を説明するものとする。

画像処理装置１１０は、図３に示すように、装置全体を制御するコントロールユニット１１１を備える。コントロールユニット１１１は、画像入力デバイスであるスキャナ１１３や画像出力デバイスであるプリンタ１１４を接続し、これらを制御する一方、ＬＡＮや公衆回線と接続され、これらを介して画像情報やデバイス情報の入出力を行うものである。

コントロールユニット１１１は、ＣＰＵ３０１を有し、ＣＰＵ３０１は、システムバス３０７を介して、ＲＡＭ３０２、ＲＯＭ３０３、ＨＤＤ（ハードディスク装置）３０４、イメージバスＩ／Ｆ３０５、操作部Ｉ／Ｆ３０６、ネットワークＩ／Ｆ３０８、およびモデム３０９と接続される。

ＲＡＭ３０２は、ＣＰＵ３０１の作業領域を提供するためのメモリであり、また、画像データを一時記憶するための画像メモリとしても使用される。ＲＯＭ３０３はブートＲＯＭであり、ＲＯＭ３０３には、システムのブートプログラムが格納されている。ＨＤＤ３０４には、システムソフトウェア、画像データなどが格納される。

操作部Ｉ／Ｆ３０６は、操作部１１２との間で入出力を行うためのインタフェースであり、操作部１１２に表示する画像データを操作部１１２に対して出力し、ユーザが操作部１１２を介して入力した情報を、ＣＰＵ３０１に伝送するなどの役割を果たす。

ネットワークＩ／Ｆ３０８は、ＬＡＮと接続され、ＬＡＮに対して情報の入出力を行う。モデム３０９は、公衆回線と接続され、公衆回線に対して情報の入出力を行う。

イメージバスＩ／Ｆ３０５は、システムバス３０７と画像データを高速で転送する画像バス３１０とを接続し、データ構造を変換するバスブリッジである。

画像バス３１０には、ＲＩＰ（ラスタイメージプロセッサ）３１１、デバイスＩ／Ｆ３１２、スキャナ画像処部３１３、プリンタ画像処理部３１４、画像回転部３１５、および画像圧縮部３１６が接続されている。

ＲＩＰ３１１は、ＬＡＮから受信されたＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ３１２は、スキャナ１１３およびプリンタ１１４とコントロールユニット１１１とを接続し、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部３１３は、入力画像データに対し補正、加工、編集などを行う。プリンタ画像処理部３１４は、プリント出力画像データに対して、プリンタの補正、解像度変換などを行う。画像回転部３１５は、画像データの回転を行う。画像圧縮部３１６は、多値画像データに対してはJPEG圧縮伸長処理を行い、２値画像データに対してはJBIG，MMR，MHなどの圧縮伸長処理を行う。

上記の構成を備える画像処理装置の外観について図４を参照しながら説明する。ここでは、各画像処理装置１１０，１２０，１３０の外観構成は、同じであるので、画像処理装置１１０の外観構成を説明するものとする。

画像処理装置１１０において、スキャナ１１３は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサ（図示せず）を走査することによって、ラスタイメージデータを生成する。使用者が原稿用紙を原稿フィーダ４０５のトレイ４０６にセットして、操作部１１２において読み取りの起動を指示すると、コントローラユニット１１１のＣＰＵ３０１がスキャナ１１３に指示を与える。そして、原稿フィーダ４０５が原稿用紙を１枚ずつフィードし、スキャナ１１３は原稿フィーダ４０５からフィードされた原稿画像の読み取り動作を行う。

プリンタ１１４は、ラスタイメージデータを用紙上の印刷するものであり、その印刷方式として、感光体ドラムや感光体ベルトを用いた電子写真方式が用いられている。なお、印刷方式として、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式などの他の方式を用いてもよいことはいうまでもない。プリンタ１１４のプリント動作は、ＣＰＵ３０１からの指示によって起動される。プリンタ１１４は、異なる用紙サイズまたは異なる用紙向きを選択可能なように複数の給紙段を有し、それぞれに対応した用紙カセット４０１，４０２，４０３が搭載される。また、排紙トレイ４０４が設けられており、この排紙トレイ４０４には、印字し終わった用紙が排紙される。

次に、操作部１１２の構成について図５を参照しながら説明する。図５は図１の操作部１１２の外観構成を示す図である。

操作部１１２は、図５に示すように、ＬＣＤ上にタッチパネルシート５０２が貼られているＬＣＤ表示部５０１を有する。このＬＣＤ表示部５０１には、システムの操作画面およびソフトキーが表示されるとともに、表示されているキーが押されると、押された位置を示す位置情報がＣＰＵ３０１に伝えられる。

また、操作部１１２には、スタートキー５０５、ストップキー５０３、ＩＤキー５０７、リセットキー５０４の各種ハードキーが設けられている。スタートキー５０５は、原稿画像の読み取り動作の開始を指示するためのキーであり、スタートキー５０５の中央部には、緑と赤の２色ＬＥＤ表示部５０６が設けられている。２色ＬＥＤ表示部５０６は、その色によってスタートキー５０５が使用可能な状態にあるか否かを表す。ストップキー５０３は、稼働中の動作を止めるためのキーである。ＩＤキー５０７は、使用者のユーザＩＤを入力するときに用いられるキーである。リセットキー５０４は操作部１１２からの設定を初期化するときに用いられるキーである。

次に、操作部１１２の構成について図６を参照しながら説明する。図６は図１の操作部１１２の詳細構成を示すブロック図である。

操作部１１２は、図６に示すように、操作部Ｉ／Ｆ３０６を介してシステムバス３０７に接続される。システムバス３０７には、上述したように、ＣＰＵ３０１、ＲＡＭ３０２、ＲＯＭ３０３、ＨＤＤ３０４などが接続されている。

操作部Ｉ／Ｆ３０６は、ユーザからの入力を制御するための入力ポート６０１と、画面出力デバイスを制御するための出力ポート６０２とを有する。入力ポート６０１は、タッチパネル５０２、各種ハードキー５０３，５０４，５０５，５０７を含むキー群からのユーザ入力をＣＰＵ３０１に渡す。ＣＰＵ３０１は、ユーザ入力の内容と制御プログラムとに基づいて表示画面データを生成し、出力ポート６０２を介して、ＬＣＤ表示部５０１に表示画面を出力する。また、ＣＰＵ３０１は、出力ポート６０２を介して必要に応じてＬＥＤ表示部５０６を制御する。

次に、ウェブブラウザモジュール２１１のソフトウェア構成について図７を参照しながら説明する。図７はウェブブラウザモジュール２１１のソフトウェア構成を示すブロック図である。

ウェブブラウザモジュール２１１は、図７に示すように、プロトコル処理部８０１、コンテンツパーサ８０２、ＤＯＭ構築部８０３、ＤＯＭ処理部８０４、レイアウトエンジン８０７、スタイルシートパーサ８０６、レンダラ８０８、スクリプトインタプリタ８０５およびイベント処理部８０９を含む。

プロトコル処理部８０１は、ＨＴＴＰモジュール２１２を介して、他のネットワークノードとの間に接続を確立し通信する。この通信においては、ＵＲＬによって記述されたリソースに対してＨＴＴＰ要求が発行され、その応答が得られる。この過程で、各種符号化形式に則した通信データの符号化・復号化も行われる。

コンテンツパーサ８０２は、プロトコル処理部８０１からＨＴＭＬ，ＸＭＬ，ＸＨＴＭＬなどの表現形式で表現されたコンテンツデータを受け取り、字句解析および構文解析して解析木を生成する。

ＤＯＭ構築部８０３は、コンテンツパーサ８０２から解析木を受け取り、コンテンツデータの構造に対応したDocument Object Model（DOM）の構築を行う。従来のＨＴＭＬは、文法上様々な省略を許し、バリエーションが多岐に渡る。さらに現実世界で運用されているコンテンツは、整形式でも妥当でもない場合が多い。そこで、ＤＯＭ構築部８０３は、他の一般的なウェブブラウザと同様に、文法的に妥当でないコンテンツデータの正しい論理構造を推論し、妥当なＤＯＭの構築を試みる。

ＤＯＭ処理部８０４は、ＤＯＭ構築部８０３が構築したＤＯＭをオブジェクト群の入れ子関係を表現するツリー構造としてメモリ上に保持管理する。ウェブブラウザの各種処理は、このＤＯＭを中心に実現される。

レイアウトエンジン８０７は、ＤＯＭ処理部８０４が保持するオブジェクト群のツリー構造に応じて、各オブジェクトの表示上の表現（プレゼンテーション）を再帰的に決定し、結果的に文書全体のレイアウトを得る。各オブジェクトの表示上の表現は、文書の中に埋め込まれた記述または文書からリンクされた別ファイル中の記述によって、Cascading Style Sheet（CSS）などのスタイルシート形式で明示的に指定される場合がある。また、レイアウトエンジン８０７は、スタイルシートパーサ８０６によるスタイルシートの解析結果を反映して文書のレイアウトを決定する。

スタイルシートパーサ８０６は、コンテンツの文書に関連付けられたスタイルシートを解析する。

レンダラ８０８は、レイアウトエンジン８０７が決定した文書のレイアウトに応じて、ＬＣＤ５０１に表示するためのGraphical User Interface（GUI）データを生成する。生成されたＧＵＩデータは、ＵＩインタフェース２０１によってＬＣＤ５０１に表示される。

イベント処理部８０９は、操作部１１２上のタッチパネルシート５０２や各キーなどに対してユーザが行った操作のイベントを受信して、各イベントに対応した処理を行う。また、イベント処理部８０９は、制御ＡＰＩ２１８から装置やジョブなどの状態遷移イベントを受信して、各イベントに対応した処理を行う。ＤＯＭ処理部８０４が管理するＤＯＭのツリー構造には、オブジェクトのクラス毎およびオブジェクトインスタンス毎に各種イベントに対応するイベントハンドラが登録されている。イベント処理部８０９は、生起したイベントに応じて、ＤＯＭ処理部８０４が管理するオブジェクト群の中からそのイベントの処理を担当するべきオブジェクトを決定し、イベントを配信する。イベントを配信されたオブジェクトは、そのイベントに対応するイベントハンドラのアルゴリズムに応じて、各種の処理を実行する。イベントハンドラの処理には、ＤＯＭ処理部８０４が保持するＤＯＭの更新、レイアウトエンジンに対する再描画指示、プロトコル処理部８０１に対するＨＴＴＰ要求発行の指示、制御ＡＰＩ２１８の呼び出しによる画像処理装置機能の制御、などがある。

スクリプトインタプリタ８０５は、Java（登録商標）Script（ECMA Script）などのスクリプトを解釈し実行するインタプリタである。スクリプトは、文書に埋め込まれたり、または文書からリンクされた別ファイル中に記述されたりして、ＤＯＭに対する操作などを行う。コンテンツの提供者は、スクリプトによって、提供する文書の動的な挙動をプログラムできる。（「ＪＡＶＡ（登録商標）ＳＣＲＩＰＴ」）
次に、サービスマンが保守作業を行なうために画像処理装置１１０に設けられているサービスモードについて説明する。サービスモードは、サービスマンのみが使用可能な処理を行うためのモードである。サービスモードにはパスワードが設けられており、このパスワードを知っているサービスマンのみが画像処理装置をサービスモードにすることができる。なお、サービスモードのパスワードはサービスマンが設定・変更可能である。パスワードが設定されると一方向ハッシュ関数によってパスワードのハッシュ値求めＨＤＤ３０４に保存しておく。

サービスマンは画像処理装置１１０の保守作業を行うためのサービスモードに入るため、予め定められた操作を行なう。予め定められた操作とは例えば特定キーを長押しする等である。予め定められた操作が行なわれるとＵＩモジュール２０１によりＬＣＤ５０１に図８の画面が表示される。サービスマンはソフトキーボード８０１を用いてサービスモードのパスワードの入力を行う。パスワードが入力されると、一方向ハッシュ関数によってハッシュ値を計算し、ＨＤＤ３０４に保持されている値と一致しているかによって正しいパスワードか否かを判定する。

正しいパスワードが入力されると、ＬＣＤ５０１に図９の画面を表示する。なお、入力されたパスワードは一時的にＲＡＭ３０２に保持しておく。図９の９０１は保守作業を行なうためのＷｅｂブラウザを起動するためのボタンであり、押し下げされると後述するＷｅｂブラウザ画面を表示する。９０２は保守用のその他の作業を行なうためのボタンであり、押し下げされるとその他保守作業を行なうための画面を表示する。９０３が押されるとサービスモードを終了して、通常のモードに戻る。この時、ＲＡＭ３０２に保持していたパスワードを破棄する。

次に、ボタン９０１が押し下げられた時に表示されるウェブブラウザの画面構成について図１０を参照しながら説明する。ボタン９０１が押下げられると、ウェブブラウザモジュール２１１がＵＩモジュール２０１の機能を使用して、ＬＣＤ５０１に図１０に示すウェブブラウザの画面を表示する。この画面ではＵＲＬ入力フィールド９０２、ＯＫボタン９０３、プログレスバー９０４、コンテンツ表示領域９０５、戻るボタン９０６、進むボタン９０７、リロードボタン９０８、中止ボタン９０９、およびステータス領域９１０が表示される。

ＵＲＬ入力フィールド１００２は、ユーザが所望のリソースのＵＲＬを入力するフィールドであり、当該フィールドをユーザが押すと、文字入力を行うための仮想的なフルキーボード（不図示）が表示される。ユーザは、仮想的なフルキーボード上に配置されたキートップを模したソフトキーによって所望の文字列を入力することができる。

ＯＫボタン１００３は入力したＵＲＬ文字列を確定するソフトキーである。ＵＲＬが確定されると、ウェブブラウザモジュール２１１は、当該リソースの取得を行うためのＨＴＴＰ要求を発行する。プログレスバー１００４は、ＨＴＴＰ要求応答によるコンテンツ取得処理の進捗状況を示す。コンテンツ表示領域１００５は、取得したリソースが表示される領域である。戻るボタン１００６は、コンテンツ表示の履歴をさかのぼり、現時点で表示しているコンテンツの前に表示したコンテンツを表示し直すためのソフトキーである。進むボタン１００７は、コンテンツ表示の履歴をさかのぼって表示しているときに、下時点で表示しているコンテンツの後に表示したコンテンツの表示に戻るためのソフトキーである。リロードボタン１００８は、現時点で表示しているコンテンツの再取得と再表示を行う。中止ボタン１００９は、実行中のコンテンツ取得処理を中止するソフトキーである。

ステータス領域１０１０は、画像処理装置の各種機能からのメッセージを表示する領域である。このステータス領域１０１０には、ウェブブラウザ画面を表示中であっても、スキャナやプリンタや他の機能などから、ユーザの注意を促すためのメッセージを表示することができる。また、同様にウェブブラウザ機能からもメッセージの表示を行うことができる。ウェブブラウザ機能は、リンク先のＵＲＬ文字列、コンテンツのタイトル文字列、スクリプトによって指示されたメッセージなどを表示する。

次にウェブサーバモジュール２０３に含まれる保守用Ｗｅｂアプリケーションについて説明する。保守用ＷｅｂアプリケーションはＷｅｂブラウザからの要求を受けると、要求に応じて制御ＡＰＩ２１８を利用して各モジュールの状態を取得したり、各モジュールを制御したりして、その結果をＷｅｂブラウザに応答する。保守用Ｗｅｂアプリケーションが提供する機能は、例えば画像処理装置のシリアル番号や各種機能の状態、各種履歴情報の表示、各種調整用コマンドの実行、実行した保守作業の報告書の作成などである。

なお、保守用Ｗｅｂアプリケーションは予め画像処理装置に組み込まれたものであっても良いし、例えばJava（登録商標）などの言語で書かれたもので画像処理装置に追加インストールされたものであっても良い。

次に、本実施の形態の動作について図１１を参照しながら説明する。なお、ここでは、サービスマンは画像処理装置１１０を操作してサービスモードに入り、画像処理装置１１０のブラウザを用いて画像処理装置１２０のＷｅｂアプリケーションにアクセスして保守作業を行なうものとする。

図１１は実施形１の動作を表すフローチャートである。ステップＳ１１００〜ステップＳ１１０５は画像処理装置１１０のＷｅｂブラウザの処理を表す。ステップＳ１１０６からステップＳ１１０８は画像処理装置１１０の制御ＡＰＩ２１８の処理を表す。ステップＳ１１１０からステップ１１１６は画像処理装置１２０の保守用Ｗｅｂアプリケーションの処理を表す。

画像処理装置１１０のＷｅｂブラウザはステップＳ１１００から処理を開始する。ステップＳ１１０１において、ユーザ（サービスマン）からの入力を受け付ける。ステップＳ１１０２において、受け付けた入力がブラウザ終了の指示か否かを判断する。ブラウザ終了指示だった場合処理を終了する。ブラウザ終了指示でない場合、ステップＳ１１０３に進みユーザからの入力に従って保守用Ｗｅｂアプリケーションに操作要求を行う。ステップＳ１１０４においてＷｅｂアプリケーションからの応答を受信する。ステップＳ１１０５において受信した応答に従って画面表示してステップＳ１１０１に戻る。サービスマンによる操作に応じてＷｅｂブラウザは上記処理を繰り返す。

画像処理装置１１０の制御ＡＰＩ２１８はステップＳ１１０６から処理を開始する。ステップＳ１１０７において、特定装置かどうかの問い合わせを待つ。問い合わせがあるとステップＳ１１０８に進む。ステップＳ１１０８では応答を送信して、ステップＳ１１０７にもどる。

画像処理装置１２０の保守用ＷｅｂアプリケーションはステップＳ１１１０から処理を開始する。ステップＳ１１１１においてクライアントからの要求を受信する。ここでクライアントとは例えば画像処理装置１１０である。ステップＳ１１１２において受信した要求が特定のユーザのみに許可するべき操作に対する要求であるかどうかを判断する。特定ユーザにのみ許可すべき操作であるか否かの情報は、保守用Ｗｅｂアプリケーションが保持している。Ｓ１１１２の判断がＮＯであるならば、すなわちサービスマンのみに許可するのではなく、全てのユーザに許可してよい要求であればステップＳ１１１５に進む。Ｓ１１１２で、要求が特定のユーザすなわちサービスマンのみに許可するべき要求であると判断するとステップＳ１１１３に進む。ステップＳ１１１３において、クライアントに対して、クライアントが特定装置であるかどうかを確認する。ここで、特定装置であるかどうかの確認はＷｅｂアプリケーションがネットワーク１００を介して要求元のクライアントの制御ＡＰＩ２１８に対してアクセスすることによって行う。要求元のクライアントが画像処理装置１１０搭載のＷｅｂブラウザであれば制御ＡＰＩ２１８が適切な応答を返す。一方、要求元のクライアントが例えばコンピュータ１０１などで動作する汎用のＷｅｂブラウザであった場合、制御ＡＰＩ２１８に相当するモジュールが動作していないため応答か返ってこないことになる。したがって、要求クライアントが特定装置であるかどうかを判断することができる。ステップＳ１１１４において、要求元のクライアントが特定装置であるかどうかを判断する。ステップＳ１１１４の判断により特定装置であると判断すると、ステップＳ１１１５に進む。ステップＳ１１１５では要求された処理を実行してステップＳ１１１６に進む。一方ステップＳ１１１４において要求元は特定装置では無いと判断すると要求を実行せずにステップＳ１１１６に進む。ステップＳ１１１６では、結果をクライアントに応答する。すなわち、ステップＳ１１１５を経由して来た場合は、処理を実行した結果を表すデータを応答する。一方ステップＳ１１１５を経由していない場合は、要求された処理の実行が許可されていない旨を表すデータを応答する。

図１４は画像処理装置１１０のＷｅｂブラウザで画像処理装置１２０の保守用Ｗｅｂアプリケーションにアクセスした時に画像処理装置１１０の操作部に表示される画面の例である。一方、図１５はホストコンピュータ１０１に搭載のＷｅｂブラウザなど汎用のＷｅｂブラウザで同じ保守用Ｗｅｂアプリケーションにアクセスした時に表示される画面の例である。

このように、本実施の形態によれば、サービスマンのみアクセスを許可する保守用Ｗｅｂアプリケーションは特定の装置に組み込まれたＷｅｂブラウザからの処理要求のみを受け付ける。従って、一般のＰＣなどのＷｅｂブラウザからアクセスされてしまうことがなくなる。

（第２実施の形態）
次に、本発明の第２実施の形態について図１２に基づいて説明する。第一の実施形では、画像処理装置１１０のＷｅｂブラウザはサービスモードからのみ利用できるようにすることを想定したが、第二の実施形では画像処理装置１１０のＷｅｂブラウザは一般ユーザも利用可能であることを想定する。

図１２は第二の実施形の処理を表すフローチャートである。ステップＳ１２００〜ステップＳ１２０５は画像処理装置１１０のＷｅｂブラウザの処理を表す。ステップＳ１２０６からステップＳ１２０９は画像処理装置１１０の制御ＡＰＩ２１８の処理を表す。ステップＳ１２１０からステップ１２１６は画像処理装置１２０の保守用Ｗｅｂアプリケーションの処理を表す。

本実施の形態は、図１２の処理以外は、上記第１実施の形態と同じ構成を有し、ここではその説明は省略する。

画像処理装置１２０のＷｅｂブラウザはステップＳ１２００から処理を開始する。ステップＳ１２０１において、ユーザ（サービスマン）からの入力を受け付ける。ステップＳ１２０２において、受け付けた入力がブラウザ終了の指示か否かを判断する。ブラウザ終了指示だった場合処理を終了する。ブラウザ終了指示でない場合、ステップＳ１２０３に進みユーザからの入力に従って保守用Ｗｅｂアプリケーションに操作要求を行う。ステップＳ１２０４においてＷｅｂアプリケーションからの応答を受信する。ステップＳ１２０５において受信した応答に従って画面表示してステップ１２０１に戻る。

サービスマンによる操作に応じてＷｅｂブラウザは上記処理を繰り返す。

画像処理装置１１０の制御ＡＰＩ２１８はステップＳ１２０６から処理を開始する。ステップＳ１２０７において、特定装置かどうかの問い合わせを待つ。問い合わせがあるとステップＳ１２０８に進む。ステップＳ１２０８で、動作モードを取得する。すなわち画像処理装置１１０がサービスモードに入っている状態であるか、そうでは無いかを取得する。

ステップＳ１２０９では前記ステップＳ１２０８で取得した動作モードを応答として送信して、ステップＳ１２０６にもどる。

画像処理装置１２０の保守用ＷｅｂアプリケーションはステップＳ１２１０から処理を開始する。ステップＳ１２１１においてクライアントからの要求を受信する。ここでクライアントとは例えば画像処理装置１１０となる。ステップＳ１２１２において受信した要求が特定のユーザのみに許可するべき操作に対する要求であるかどうかを判断する。Ｓ１２１２の判断がＮＯであるならば、すなわちサービスマンのみに許可するのではなく、全てのユーザに許可してよい要求であればステップＳ１２１５に進む。Ｓ１２１２の判断により、要求が特定のユーザすなわちサービスマンのみに許可するべき要求であると判断するとステップＳ１２１３に進む。ステップＳ１２１３において、クライアントに対して、クライアントの動作モードを問い合わせる。ここで、動作モードの問い合わせはＷｅｂアプリケーションがネットワーク１００を介して要求元のクライアントの制御ＡＰＩ２１８に対するアクセスすることによって行う。要求元のクライアントが画像処理装置１１０搭載のＷｅｂブラウザであれば制御ＡＰＩ２１８が適切な応答を返す。すなわち、画像処理装置１１０がサービスモードになっているか否かが応答として得られる。一方、要求元のクライアントが例えばコンピュータ１０１などで動作する汎用のＷｅｂブラウザであった場合、制御ＡＰＩ２１８に相当するモジュールが動作していないため応答か返ってこないことになる。ステップＳ１２１４において、要求元のクライアントが特定の動作モード（サービスモード）であるかどうかを判断する。ステップＳ１２１４の判断によりクライアントがサービスモードになっていると判断すると、ステップＳ１２１５に進む。ステップＳ１２１５では要求された処理を実行してステップＳ１２１６に進む。一方ステップＳ１２１４において要求元は特定の動作モード（サービスモード）になっていないと判断すると要求を実行せずにステップＳ１２１６に進む。ステップＳ１２１６では、結果をクライアントに応答する。すなわち、ステップＳ１２１５を経由して来た場合は、処理を実行した結果を表すデータを応答する。一方ステップＳ１２１５を経由していない場合は、要求された処理の実行が許可されていない旨を表すデータを応答する。

このように、本実施の形態によれば、保守用Ｗｅｂアプリケーションは、クライアントが特定の装置に組み込まれたＷｅｂブラウザであり、さらにクライアントがサービスモードになっている場合のみ処理要求のみを受け付ける。従って、特定のモードに入る手段を知っているユーザからの要求のみを受け付けるようにできるので、装置に組み込まれたＷｅｂブラウザを一般のユーザが使用することを許可している場合でも、適切にサービスマンからの要求のみを許可できる。

（第３実施の形態）
次に、本発明の第３実施の形態について図１３に基づいて説明する。

図１３は第三の実施形の処理を表すフローチャートである。ステップＳ１３００〜ステップＳ１３０５は画像処理装置１１０のＷｅｂブラウザの処理を表す。ステップＳ１３０６からステップＳ１３０９は画像処理装置１１０の制御ＡＰＩ２１８の処理を表す。ステップＳ１３１０からステップ１３１７は画像処理装置１２０の保守用Ｗｅｂアプリケーションの処理を表す。

本実施の形態は、図１３の処理以外は、上記第１実施の形態と同じ構成を有し、ここではその説明は省略する。

画像処理装置１２０のＷｅｂブラウザはステップＳ１３００から処理を開始する。ステップＳ１３０１において、ユーザ（サービスマン）からの入力を受け付ける。ステップＳ１３０２において、受け付けた入力がブラウザ終了の指示か否かを判断する。ブラウザ終了指示だった場合処理を終了する。ブラウザ終了指示でない場合、ステップＳ１３０３に進みユーザからの入力に従って保守用Ｗｅｂアプリケーションに操作要求を行う。ステップＳ１３０４においてＷｅｂアプリケーションからの応答を受信する。ステップＳ１３０５において受信した応答に従って画面表示してステップＳ１３０１に戻る。サービスマンによる操作に応じてＷｅｂブラウザは上記処理を繰り返す。

画像処理装置１１０の制御ＡＰＩはステップＳ１３０６から処理を開始する。ステップＳ１３０６において、特定装置かどうかの問い合わせを待つ。問い合わせがあるとステップＳ１３０７に進む。ステップＳ１３０７で、動作モードを取得する。すなわち画像処理装置１１０がサービスモードに入っている状態であるか、そうでは無いかを取得する。

ステップＳ１３０８ではさらに、特定のモードに入るために用いられたパスワードの情報を取得する。このパスワードは図８の画面においてユーザによって入力されＲＡＭに保持しておいたものである。

ステップＳ１３０９では、前記ステップＳ１３０７およびステップＳ１３０８で取得した動作モードとそのパスワードを応答として送信して、ステップＳ１３０６にもどる。

画像処理装置１２０の保守用ＷｅｂアプリケーションはステップＳ１３１０から処理を開始する。ステップＳ１３１１においてクライアントからの要求を受信する。ここでクライアントとは画像処理装置１１０となる。ステップＳ１３１２において受信した要求が特定のユーザのみに許可するべき操作に対する要求であるかどうかを判断する。Ｓ１３１２の判断がＮＯであるならば、すなわちサービスマンのみに許可するのではなく、全てのユーザに許可してよい要求であればステップＳ１３１６に進む。Ｓ１３１２の判断により、要求が特定のユーザすなわちサービスマンのみに許可するべき要求であると判断するとステップＳ１３１３に進む。ステップＳ１３１３において、クライアントに対して、クライアントの動作モードとそのモードに移行するために入力されたパスワードを問い合わせる。ここで、動作モードの問い合わせはＷｅｂアプリケーションがネットワーク１００を介して要求元のクライアントの制御ＡＰＩ２１８に対するアクセスすることによって行う。要求元のクライアントが画像処理装置１１０搭載のＷｅｂブラウザであれば制御ＡＰＩ２１８が適切な応答を返す。すなわち、画像処理装置１１０のモードがサービスモードであった場合、サービスモードに入るために入力されたパスワードが応答として得られる。一方、要求元のクライアントが例えばコンピュータ１０１などで動作する汎用のＷｅｂブラウザであった場合、制御ＡＰＩ２１８に相当するモジュールが動作していないため応答か返ってこないことになる。ステップＳ１３１４において、要求元のクライアントが特定の動作モード（サービスモード）であるかどうかを判断する。ステップＳ１３１４の判断により特定装置であると判断すると、ステップＳ１３１５に進む。ステップＳ１３１５では、取得したパスワードを使って画像処理装置１２０が特定のモードに移行できるか確認する。すなわち、クライアントから取得したパスワードを一方向ハッシュ関数で変換して、画像処理装置１２０のサービスモードパスワードのハッシュ値との比較を行う。ステップＳ１３１５で特定のモードに移行可能と判断すると、ステップＳ１３１６に進む。ステップＳ１３１６では要求された処理を実行してステップＳ１３１７に進む。一方ステップＳ１３１４において要求元は特定装置では無いと判断した場合や、ステップＳ１３１５において特定のモードに移行できないと判断すると、要求を実行せずにステップＳ１３１７に進む。ステップＳ１３１７では、結果をクライアントに応答して、ステップＳ１３１１に戻る。

このように、保守用Ｗｅｂアプリケーションは、実施形２の条件に加えて、画像処理装置１１０で入力されたパスワードで保守用Ｗｅｂアプリケーション側の画像処理装置１２０がサービスモードに移行できる場合のみ処理要求を受け付ける。本実施の形態によれば、画像処理装置１１０と画像処理装置１２０のサービスモードパスワードを同じ設定にして運用することにより、より確実にサービスマンからの要求のみを処理することができる。

なお、本提案書では、Ｗｅｂブラウザを持った画像処理装置１１０と保守用Ｗｅｂアプリケーションを持った画像処理装置１２０は同じ構成の画像処理装置であるとしたが、異なる構成の画像処理装置であっても良い。また、Ｗｅｂブラウザを持った画像処理装置１１０が、画像処理装置１１０自身の保守用Ｗｅｂアプリケーションにアクセスする構成であっても良い。

１００ ＬＡＮ
１１０，１２０，１３０ 画像処理装置
１０１ デスクトップコンピュータ
３０１ ＣＰＵ
３０３ ＲＯＭ
３０４ ＨＤＤ

Claims (3)

1. Ｗｅｂブラウザ（２１１）を持つ第一の画像処理装置（１１０）と、該Ｗｅｂブラウザからの操作要求を受け付けるＷｅｂサーバ手段（２０３）を持つ第二の画像処理装置（１２０）から成る情報処理システムであって、
   前記第一の画像処理装置は、
   前記第二の画像処理装置から問い合わせに対して応答する応答手段（２１８）を持ち、
   前記第二の画像処理装置は、
   前記Ｗｅｂサーバ手段（２０３）がＷｅｂクライアントからの操作要求を受けると、前記操作要求が、特定の装置に組み込まれたＷｅｂブラウザからの要求に対してのみ許可するべき操作に対する要求であるか否かを判断する第一の判断手段（Ｓ１１１２）と、
   前記判断手段によって、前記操作要求が、特定の装置に組み込まれたＷｅｂブラウザからの要求に対してのみ許可するべき操作に対する要求であると判断されると、前記クライアントに対して通信して問い合わせ、前記操作要求を行ったクライアントが特定の装置に組み込まれたＷｅｂブラウザであるか否かを判断する第二の判断手段（Ｓ１１１２）と、
   前記第二の判断手段によって、前記操作要求を行ったクライアントが特定の装置に組み込まれたＷｅｂブラウザであると判断された場合は操作要求を受け付け、そうで無い場合は操作要求を受け付けないように制御する制御手段（Ｓ１１１５）と
   を持つことを特徴とする情報処理システム。
2. 前記情報処理システムの前記第二の画像処理装置の第二の判断手段は、さらに
   前記クライアントに対して通信して問い合わせ、前記操作要求を行ったクライアントが特定のユーザのみが利用可能な特定のモードになっているか否かを判断する手段（Ｓ１２１４）を
   持つことを特徴とする請求項１の情報処理システム。
3. 前記情報処理システムの前記第二の画像処理装置は、さらに
   前記クライアントが前記特定のユーザのみが利用可能な特定のモードに入る際に入力されたパスワード情報を取得する手段（Ｓ１３１３）と、
   前記第二の判断手段によって、前記操作要求を行ったクライアントが特定のモードになっていると判断された場合は前記取得手段によって取得したパスワード情報を用いて操作要求を受け付け、そうで無い場合は操作要求を受け付けないように制御する制御手段（Ｓ１３１５）と
   持つことを特徴とする請求項１の情報処理システム。

Images