JP4355639B2 - 画像処理装置およびその制御方法 - Google Patents

Description

本発明は、Ｗｅｂブラウザを備えた画像処理装置およびその制御方法に関する。

周知のように、ＨＴＭＬ（Hypertext Markup Language）によって表現された文書データをＨＴＴＰ（Hypertext Transfer Protocol）によって供給するＷｅｂサーバと、ＷｅｂサーバからＨＴＴＰによってＨＴＭＬデータを取得し表示するクライアントであるＷｅｂブラウザによってインターネットは発展した。

Ｗｅｂサーバの最も基本的な機能は、クライアントからＨＴＴＰによって送信されるファイルの取得要求に対する応答として、要求されたファイルを返信するファイル転送サービスである。ここで、Ｗｅｂサーバは、基本的には、当該サーバに格納されている静的なファイルを単に読み出して返信するが、この基本機能に加えて、クライアントからのＨＴＴＰ要求（ＧＥＴメソッドやＰＯＳＴメソッド）に呼応して、データを動的に生成し返信する場合もある。

このように、Ｗｅｂサーバが動的にＨＴＴＰ応答を生成する処理は、サーバサイド処理と呼ばれる。サーバサイド処理は、Ｗｅｂサーバから、ＣＧＩ（Common Gateway Interface）仕様や、Ｊａｖａ（登録商標）のためのＳｅｒｖｌｅｔ仕様などに従って実装された外部ソフトウェアに委譲されて実現されることがある。これらのインターフェース仕様に従ってＷｅｂサーバから処理を委譲される外部ソフトウェアは、サーバマシンの実行形式プログラム、Ｊａｖａ（登録商標）などの仮想機械命令で記述されたプログラム、または、インタプリタによって実行されるテキスト形式のスクリプトとして実装される。インタプリタ（スクリプト実行環境）によって実行されるテキスト形式のスクリプトの具体例として、シェルスクリプト、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＰＨＰ（Personal HomePageまたは、PHP: Hypertext Preprocessor）などのスクリプトが用いられている。サーバサイド処理のためにＷｅｂサーバと連携するスクリプトを提供することを、サーバサイドスクリプティングと呼ぶ。

ＨＴＭＬのＦＯＲＭ要素によって、ＨＴＭＬ文書は、ユーザからの入力を求めるための書式を表現することができる。ＦＯＲＭに基づく書式がＷｅｂブラウザ上に表示され、ユーザが書式への入力を行い、ユーザがサブミットを指示すると、書式に入力されたデータが、ＨＴＴＰ要求（ＧＥＴメソッドまたはＰＯＳＴメソッド）としてＷｅｂサーバ側に送信される。したがって、Ｗｅｂサーバがクライアントに送るＨＴＭＬ文書を、サーバサイド処理に対するユーザの指示を受け入れることが可能な書式を含むように構成することによって、ユーザがＷｅｂブラウザを介してサーバサイド処理と対話する、一種のユーザインターフェースを提供することができる（ユーザが書式内に入力指定したクライアント側のファイルをサーバ側にアップロードするように書式を構成することもできる）。サーバサイド処理は、単にＨＴＴＰ応答を動的に生成するだけでなく、副作用としてユーザに何らかのサービスを提供するための処理を実行することができる。

このようにして、ユーザは、Ｗｅｂブラウザを介して、サーバ側に存在するビジネスロジックやバックエンドサービスなどを利用できる。ＨＴＭＬを一種のユーザインターフェース記述言語として用い、処理の大半がサーバ側で実行されるサービスのユーザインターフェース処理のみをクライアント側のＷｅｂブラウザに担当させる分散システムのモデルが多用されている（このようなモデルにおける軽量のクライアントのことを、シンクライアント（Thin Client）と呼ぶ）。

一方、Ｗｅｂブラウザ側でコンピューティング処理を行うクライアントサイド処理もよく知られている。クライアントサイド処理では、Ｗｅｂブラウザからの要求に応じて、何らかの処理を行うためのソフトウェアがＷｅｂサーバからクライアント側に返信され、Ｗｅｂブラウザに組み込まれた処理系上で当該ソフトウェアが実行される。この場合、動的な文書生成やユーザとの対話は、Ｗｅｂブラウザにおいて動作するクライアントサイド処理によって達成され、必ずしもサーバ側と通信する必要はない。Ｊａｖａ（登録商標）の仮想機械命令で記述され、Ｊａｖａ（登録商標） Ａｐｐｌｅｔのインターフェース仕様に従って実装されたオブジェクト形式のプログラムは、プラグインなどとしてＷｅｂブラウザに組み込まれたＪａｖａ（登録商標）仮想機械の上で動作する。また、テキストベースのスクリプティング言語としては、これまで多くのＷｅｂブラウザにＪａｖａＳｃｒｉｐｔ（登録商標）インタプリタが組み込まれている。クライアントサイドＪａｖａＳｃｒｉｐｔ（登録商標）は、Ｗｅｂブラウザで定義するＤＯＭ（Document Object Model）とＪａｖａＳｃｒｉｐｔ（登録商標）インタプリタのスクリプト機能を組み合わせたものである。Ｊａｖａ（登録商標） Ａｐｐｌｅｔなどのアプローチに比べ、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語によるアプローチは、テキストベースであるために、ＨＴＭＬなどのマークアップ言語との親和性が高く、ＨＴＭＬ文書コンテンツの提供者が簡便に「実行可能なコンテンツ」を提供できる長所がある。また、クライアントサイドＪａｖａＳｃｒｉｐｔ（登録商標）のインタプリタは、Ｗｅｂブラウザが内部的に文書を扱うためのデータ構造であるＤＯＭと連携するように構成されているため、Ｗｅｂブラウザに表示される文書そのものを操作して動的な情報やユーザインターフェースをユーザに簡単に提供することができる。

ＪａｖａＳｃｒｉｐｔ（登録商標）言語のコア部分は、ＥＣＭＡ（European Computer Manufacturers Association）において、ＥＣＭＡＳｃｒｉｐｔとして標準化された。クライアントサイド処理ならびにＪａｖａＳｃｒｉｐｔ（登録商標）の詳細は、たとえば「ＪａｖａＳｃｒｉｐｔ第３版」David Flanagan著、村上列監訳、オライリー・ジャパン発行（２０００年）［”Java Script The Definitive Guide, Third Edition”, David Flanagan, O’Reilly, 1998］などを参照。

ＤＯＭは、ＨＴＭＬなどのマークアップ言語で記述された文書の構造をオブジェクトとして扱うためのオブジェクトモデルである。Ｎｅｔｓｃａｐｅ ＮａｖｉｇａｔｏｒやＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）などの個々のＷｅｂブラウザは、ＪａｖａＳｃｒｉｐｔ（登録商標）などのクライアントサイド処理のために、従来からそれぞれの実装に固有のＤＯＭを提供していた。ＤＯＭ仕様は、Ｗ３Ｃ（World Wide Ｗｅｂ Consortium）で標準化が行われ、個々のＷｅｂブラウザの実装においても標準仕様に準拠したインターフェースを利用可能となってきている。

また、汎用デスクトップコンピュータ用のＷｅｂブラウザでは、プラグインやダイナミックリンクライブラリやネイティブ機械コードに基づくオブジェクトなどを取り込んでＷｅｂブラウザの実行形式に動的に結合することによって、Ｗｅｂブラウザ自体の機能を拡張しようとしている。

たとえば、特許文献１には、サーバサイド処理（ＣＧＩ）による装置制御が開示されている。

また、特許文献２〜５には、デジタル複合機に内蔵されたＷｅｂプルプリント機能が開示されている。組み込みＷｅｂプルプリント機能とは、Ｗｅｂブラウザが備えるものと同様のＨＴＴＰによるデータ取得機構とＨＴＭＬ等のレンダリング機構を備え、ユーザが指定したＵＲＬ（Uniform Resorce Locator）から取得したコンテンツをプリント出力する機能である。

さらに、さまざまな組み込み装置において、ファームウェア中にＪａｖａ（登録商標）の仮想機械を備え、仮想機械のオブジェクト形式（バイトコード）で記述されたプログラムをサーバから取得し、動的にロードし、実行できるシステムが知られている。
特開平１１−１８７０６１号公報 特開平１１−１３４１２５号公報 特開平１１−２１２７５１号公報 特開平１１−３２７８３４号公報 特開２０００−１９４５３１号公報

ところで、組み込み装置のファームウェアに組み込まれたＷｅｂブラウザには、汎用デスクトップコンピュータ用のＷｅｂブラウザとは異なる活用が求められる。なぜならば、一般に組み込み装置の計算資源（ＣＰＵ、メモリ、外部記憶、ディスプレイのサイズ・解像度、キーボードやポインティングデバイスなど）は、汎用デスクトップコンピュータよりも機能的・性能的に劣る場合が多いからである。また、汎用デスクトップコンピュータが、さまざまな種類の仕事をこなすために、机に置かれ、ユーザが椅子に座って落ち着いて操作するものである一方、たとえば複合機であれば、オフィスの一角に置かれ、複数のスタッフが共用するといったように、特定のシチュエーションや利用形態において利用されるべきものだからである。組み込み装置に内蔵されたＷｅｂブラウザを用いて、一般的なインターネットのネットサーフィンやブラウジングを行うことは、不可能ではないにせよ、最適な用途とはいえない。

したがって、組み込み装置に内蔵されたＷｅｂブラウザの活用においては、組み込み装置が本来持つ固有の機能に連動して、最適に適応したコンテンツをブラウジングすることが求められる。

組み込みブラウザの活用事例としては、消耗品販売、マニュアル参照、装置診断などのサービスの利用がある。たとえば、複合機に組み込まれたＷｅｂブラウザが、装置の販売元が提供するポータルページを表示した際に、もしその装置のトナー残量が少なければ動的にトナーのオンライン購入を勧める案内を表示するなど、顧客環境における固有の装置利用に密着した、きめの細かいサービスの提供が有効である。また、装置組み込みのＷｅｂブラウザから、その装置の最新マニュアルや事例集やノウハウ集などが公開されているページを表示した際に、その装置あるいは装置に現に装着されているオプション群に関連する情報を選択的に表示するような、きめの細かいサービスの提供も有効である。さらに、装置のメンテナンスや修理などを行うときには、装置に組み込まれたファームウェアが内部データとして管理する多種多様なパラメータを参照または変更したり、ファームウェアに作り込まれた複数の診断コードやセットアップコードなどを適切な順序と組み合わせで呼び出したりしなければならない場合が多い。しかも、これらはオプションユニットの装着状況やファームウェアのバージョンによって適切な処置が異なる場合もある。ノウハウの蓄積に伴って最適な処置が変更される場合もある。したがって、エンドユーザや現場のカスタマーエンジニアがすべてを把握して、最適な処置を行うことは、困難であるか、また多大なコストを要する。このような装置の管理作業に関して、顧客環境において装置の組み込みブラウザからサービス会社が提供する装置管理情報のページにアクセスすると、その装置の現状を動的に反映した最適な作業マニュアルを見ることができ、さらに装置の種類や状況に応じて、サービス会社の内部で最新のノウハウに従って周到に用意した、装置内部のパラメータの参照・変更や診断コード・セットアップコードの組み合わせの実行指示などを行うためのユーザインターフェースページが表示できると、きわめて便利である。

これらの例から明らかなように、組み込みブラウザからのアクセスに最適化した、装置の機能や状態と連動した動的なコンテンツの提供を、サーバ側の対応によって柔軟に拡張できる形で行うことが望まれる。ただし、プライバシーの観点からユーザは装置の情報がサーバ側（コンテンツ提供者側）に通知されることを望まない場合がある。この場合には、ＣＧＩのようなサーバサイド処理は適さないので、クライアントサイド処理によって達成する必要がある。

また、外部からネットワーク経由で取得されるコンテンツが、装置の機能や状態と十分に連携できることと同時に、組み込み装置のセキュリティーを脅かさないことの両立に配慮しなければならない。

さらに、組み込み装置に内蔵されたブラウザは、リアルタイムＯＳ上のファームウェアとして実装される場合がほとんどであるため、汎用デスクトップコンピュータ用のブラウザとは異なり、プラグインやダイナミックリンクライブラリやネイティブ機械コードに基づくオブジェクトなどを取り込んで、ブラウザの実行形式に動的に結合することによって、ブラウザ自体の機能拡張を達成することは困難である。したがって、ブラウザそのものの機能は、システムの出荷時に予め固定した上で、装置の機能や状態と連携する動的なコンテンツの提供をサーバ側の対応によって柔軟に拡張可能な形で達成することが求められる。

しかし、上記特許文献１の装置では、サーバサイド処理（ＣＧＩ）による装置制御であり、上記組み込みブラウザ上でのクライアントスクリプティングによる装置制御には触れられていない。

また、Ｊａｖａ（登録商標）仮想機械などによるアプローチは、上述のように、ＨＴＭＬなどテキストベースのマークアップ言語との親和性と、プログラムからそのプログラムを組み込んだ（または関連付けた）元の文書のＤＯＭに対するアクセス性などにおいて、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプトによるアプローチに比べて劣るため、装置組み込みブラウザを利用した分散システムを提供するためのコンテンツ提供者にとって手軽さに欠ける。

本発明は、この点に着目してなされたものであり、組み込みブラウザからのアクセスに対応して、組み込み装置固有の機能や状態と連動して適応した動的なコンテンツをサーバ側の対応によって簡易に柔軟に拡張できるサービスとして供給すること可能とし、さらにクライアント側情報のプライバシーやセキュリティーが守られるＷｅｂブラウザ内蔵画像処理装置およびその制御方法を提供することを目的とする。

上記目的を達成するため、請求項１に記載の画像処理装置は、画像入力手段あるいは画像出力手段の少なくともいずれかを備える画像処理装置であって、少なくともマークアップ言語によって記述された文書データであって、その中にスクリプトまたはスクリプトを参照する情報の埋め込まれた文書データを含むＷｅｂコンテンツデータをロードし、該ロードされたＷｅｂコンテンツデータに基づいて画面情報を生成し、該画面情報を表示手段に表示するブラウザ手段と、前記画像入力手段あるいは前記画像出力手段のいずれかを用いた画像処理の実行を制御する制御手段と、前記制御手段が前記画像処理の実行を制御するのに伴い生成される履歴情報を記憶する記憶手段と、前記ロードされたＷｅｂコンテンツデータに含まれる文書データを解釈し、該文書データに埋め込まれたスクリプトまたはスクリプトを参照する情報によって特定されるスクリプトを処理するスクリプト処理手段と、前記スクリプト処理手段による前記スクリプトの処理に基づいて、前記記憶手段に記憶された情報を取得する取得手段とを有し、前記ブラウザ手段は、前記取得手段が取得した情報を前記画面情報に反映させて前記表示手段へ表示することを特徴とする。

上記目的を達成するため、請求項１１に記載の制御方法は、画像入力手段あるいは画像出力手段の少なくともいずれかを備える画像処理装置を制御する制御方法であって、少なくともマークアップ言語によって記述された文書データであって、その中にスクリプトまたはスクリプトを参照する情報の埋め込まれた文書データを含むＷｅｂコンテンツデータをロードし、該ロードされたＷｅｂコンテンツデータに基づいて画面情報を生成し、該画面情報を表示手段に表示するブラウザステップと、前記画像入力手段あるいは前記画像出力手段のいずれかを用いた画像処理の実行を制御する制御ステップと、前記ロードされたＷｅｂコンテンツデータに含まれる文書データを解釈し、該文書データに埋め込まれたスクリプトまたはスクリプトを参照する情報によって特定されるスクリプトを処理するスクリプト処理ステップと、前記スクリプト処理ステップによる前記スクリプトの処理に基づいて、前記制御ステップにおいて前記画像処理の実行が制御されるのに伴い生成される履歴情報を記憶する記憶手段に記憶された情報を取得する取得ステップとを有し、前記ブラウザステップでは、前記取得ステップによって取得された情報を前記画面情報に反映させて前記表示手段へ表示することを特徴とする。

請求項１に記載の発明によれば、Ｗｅｂコンテンツデータを表示手段に表示する場合に、Ｗｅｂコンテンツデータに含まれる文書データに埋め込まれたスクリプト、またはスクリプトを参照するデータによって特定されるスクリプトを実行することによって、制御手段が画像処理の実行を制御するのに伴い生成される履歴情報を記憶する記憶手段に記憶される情報を取得し、取得した情報をブラウザ手段が表示手段へ表示させる画面情報へ反映させることができるので、サーバ側には単一のコンテンツを準備するだけで、画像処理装置の構成や状態に応じて適切なコンテンツを選択的に提示することが可能となる。また、動的なコンテンツの生成は、主としてクライアントサイド処理によってなされるので、クライアント側情報のプライバシーやセキュリティーを守ることができる。

また、請求項１１に記載の発明も、請求項１に記載の発明と同様の効果が得られる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。

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

本実施の形態の画像処理システムは、アプリケーションサービスプロバイダ（ＡＳＰ）サイト１５３、広域ネットワーク１５２およびユーザサイト１５１から構成されている。

広域ネットワーク１５２の一例としては、インターネットである。その他に、インターネット上の仮想プライベートネットワーク（ＶＰＮ）や、専用のプライベートネットワークでもよい。

ＡＳＰサイト１５３は、広域ネットワーク１５２を介して、ユーザサイト１５１に所定のサービスを提供する。ＡＳＰサイト１５３が提供するサービスとしては、たとえば、情報の提供、作成、検索、蓄積、認証、配布、印刷、出版、管理、翻訳、委託などがある。また、官公庁手続や各種の電子商取引などもある。

ＡＳＰサイト１５３は、ローカルエリアネットワーク（ＬＡＮ）１５４およびサーバ１５５を含んでいる。

ＬＡＮ１５４は、ＡＳＰサイト１５３内部のネットワークであり、サイト１５３内のネットワーク機器を接続する。また、ＬＡＮ１５４は、図示しないルータなどを介して、広域ネットワーク１５２と接続されている。

サーバ１５５上では、ＡＳＰが提供するサービスを実現するためのソフトウェアプロセス群が稼動している。このソフトウェアプロセス群を構成するソフトウェアモジュールには、以下がある。すなわち、クライアントからのＨＴＴＰプロトコルによる要求に応答してＨＴＭＬなどのコンテンツを伝送するＨＴＴＰサーバ、ＨＴＴＰ要求に応じてＨＴＴＰサーバにより実行され、所定の処理と動的に変化するＨＴＴＰ応答を行う、ＣＧＩプログラムやＳｅｒｖｌｅｔなどの形態で実装されたＷｅｂアプリケーション群、ＣＧＩプログラムやＳｅｒｖｌｅｔなどが所定の処理を実行するために用いられる、電子商取引プログラムなどのビジネスロジック群とバックエンドのデータベース管理システムである。

ユーザサイト１５１は、ホストコンピュータ１０１と、画像処理装置１１０，１２０および１３０などの複数のネットワーク機器と、ネットワーク機器群が接続されるＬＡＮ１００とから構成される。ユーザサイト１５１のＬＡＮ１００は、図示しないルータなどを介して、広域ネットワーク１５２に接続されている。ルータは、いわゆる防火壁（firewall）の機能も果たす。すなわち、外部ネットワークからの攻撃からユーザサイト１５１を守るために、パケットフィルタリングなどを行う。また、アドレス管理上の理由などのために、ネットワークアドレス変換やネットワークポート変換を行う場合もある。ルータのこれらの機能のために、ユーザサイト１５１と外部ネットワークとの間の通信には制限がつけられている。すなわち、多くの場合、いくつかの特定のプロトコルによる通信だけが可能となっている。たとえば、内部から外部に向かって確立されるＨＴＴＰ接続は、一般に許可されている通信の例であり、これは、このような一般的なＷｅｂベースの技術に基づくアプリケーションサービスの提供が有効である理由のひとつとなっている。

なお、画像処理装置１１０，１２０および１３０はいずれも、本実施の形態の組み込み装置に相当するが、各画像処理装置１１０，１２０および１３０は、それぞれ同様に構成されているため、説明の都合上、画像処理装置１１０のみを本実施の形態の組み込み装置とする。

画像処理装置１１０は、画像の入出力と送受信および各種の画像処理を行う複合機（ＭＦＰ：Multi Function Peripheral）であり、画像入力デバイスであるリーダ部１１３、画像出力デバイスであるプリンタ部１１４、制御ユニット（Controller Unit）１１１およびユーザインターフェースである操作部１１２から構成される。

リーダ部１１３、プリンタ部１１４および操作部１１２は、それぞれ、制御ユニット１１１に接続されて、制御ユニット１１１からの命令によって制御される。制御ユニット１１１は、ＬＡＮ１００などのネットワーク伝送手段に接続されている。

また、ＬＡＮ１００には、画像処理装置１１０と同様の機器構成をもつ、他の画像処理装置１２０および１３０が接続されている。画像処理装置１２０は、スキャナ部１２３、プリンタ部１２４および操作部１２２から構成されており、それらが制御ユニット１２１に接続されて、制御される。また、画像処理装置１３０は、スキャナ部１３３、プリンタ部１３４および操作部１３２から構成されており、それらが制御ユニット１３１に接続されて、制御される。

また、ホストコンピュータ１０１は、ＬＡＮ１００等のネットワーク伝送手段に接続されている。ホストコンピュータ１０１は、後述するようにＷｅｂブラウザを備え、各画像処理装置１１０，１２０，１３０から受信したＨＴＭＬファイルに基づいて、各画像処理装置１１０，１２０，１３０のステータスなどを表示する。また、サーバ１５５にＨＴＴＰ接続してサービスの提供を受ける。

図２は、画像処理装置１１０のソフトウェア構成を示すブロック図である。なお、他の画像処理装置１２０および１３０のソフトウェア構成も、画像処理装置１１０と同様である。

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

アドレスブック（Address-Book）モジュール２０２は、データの送付先や通信先等を管理するデータベースモジュールである。アドレスブックモジュール２０２が管理するデータは、ＵＩモジュール２０１からの操作により、データの追加、削除、取得が行われる。また、アドレスブックモジュール２０２は、ユーザの操作により後述の各モジュールにデータの送付・通信先情報を与える。

Ｗｅｂサーバ（Web Server）モジュール２０３は、Ｗｅｂクライアント（たとえば、ホストコンピュータ１０１）からの要求により、ＨＴＭＬなどで記述された情報をＨＴＴＰで提供する。

統合送信部（Universal Send）モジュール２０４は、データの配信を司るモジュールである。このモジュール２０４は、ＵＩモジュール２０１を介してユーザによって指示されたデータを、同様にして指示された通信（出力）先に配布する。また、ユーザにより、画像処理装置１１０のスキャナ機能を使用して配布データの生成が指示された場合は、後述の制御ＡＰＩモジュール２１８を介して画像処理装置１１０を動作させ、データの生成を行う。

Ｐ５５０モジュール２０５は、統合送信部モジュール２０４内で、出力先にプリンタが指定された際に実行されるモジュールである。Ｅ−ｍａｉｌモジュール２０６は、統合送信部モジュール２０４内で、通信先にＥ−ｍａｉｌアドレスが指定された際に実行されるモジュールである。データベース（ＤＢ）モジュール２０７は、統合送信部モジュール２０４内で、出力先にデータベースが指定された際に実行されるモジュールである。モジュール２０８は、統合送信部モジュール２０４内で、出力先に画像処理装置１１０と同様の画像処理装置が指定された際に実行されるモジュールである。

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

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

Ｗｅｂブラウザ（Ｗｅｂ Browser）モジュール２１１は、インターネットまたはイントラネット上の各種Ｗｅｂサイト（ホームページ）の情報を読み込んで表示を行うモジュールである。Ｗｅｂブラウザの詳細な構成は、後述する。

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

ＬＰＲモジュール２１３は、ＴＣＰ／ＩＰ通信モジュール２１６を使って、統合送信部モジュール２０４内のプリンタモジュール２０５に通信機能を提供するものである。

ＳＭＴＰ（Simple Mail Transfer Protocol）モジュール２１４は、ＴＣＰ／ＩＰ通信モジュール２１６を使って、統合送信部モジュール２０４内のＥ−ｍａｉｌモジュール２０６に通信機能を提供する。

ＳＬＭ（Salutation Manager）モジュール２１５は、ＴＣＰ／ＩＰ通信モジュール２１６を使って、統合送信部モジュール２０４内のデータベースモジュール２０７およびＤＰモジュール２０８と、リモートコピースキャンモジュール２０９と、リモートコピープリントモジュール２１０とに通信機能を提供する。

ＴＣＰ／ＩＰ通信モジュール２１６は、後述のネットワークドライバ２１７を用いて、前述の各種モジュールにネットワーク通信機能を提供する。

ネットワークドライバ２１７は、ネットワークに物理的に接続される部分を制御するものである。

制御ＡＰＩモジュール２１８は、統合送信部モジュール２０４等の上流モジュールに、後述のジョブマネージャ（Job Manager）モジュール２１９等の下流モジュールに対するインターフェースを提供するものである。これによって、上流および下流のモジュール間の依存関係が軽減され、それぞれの流用性を高めることができる。

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

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

エンコーダモジュール２２１は、ジョブマネージャモジュール２１９や後述のスキャンマネージャ（Scan Manager）モジュール２２４によって実行されたスキャン処理によって読み込まれたデータを、所定のエンコード手法を用いて圧縮するものである。

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

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

情報埋め込み画像コーデック（IEI CODEC）モジュール２２９は、ジョブマネージャモジュール２１９やスキャンマネージャモジュール２２４によって実行されたスキャン処理、あるいはプリントマネージャモジュール２２６によって実行された印刷処理において、読み込まれた画像データに埋め込まれた情報のデコード、および印刷画像データへの情報埋め込みを行うものである。画像データへの情報の埋め込みは、バーコードやデジタル透かし（デジタルウォーターマーク）などの符号化技術を用いて行う。また、像域分離とＯＣＲ（Optical Character Reader）技術によって画像データの画像中の文字を認識しテキストデータに変換する文字認識も、一種の復号化技術としてサポートする。さらにラスタイメージプロセッサを用いたテキストから画像データへの変換と、変換した画像データとオリジナル画像データとの重ね合わせ（オーバレイ）も、一種の符号化技術（情報埋め込み技術）としてサポートする。

スキャンマネージャ（Scan Manager）モジュール２２４は、ジョブマネージャモジュール２１９が指示するスキャン処理を管理・制御するものである。

ＳＣＳＩ（Small Computer System Interface）ドライバ２２５は、スキャンマネージャモジュール２２４と、画像処理装置１１０に内部的に接続しているスキャナ部との間の通信を取り持つものである。

プリントマネージャ（Print Manager）モジュール２２６は、ジョブマネージャモジュール２１９が指示する印刷処理を管理・制御するものである。

エンジンインターフェース（Engine I/F）モジュール２２７は、プリントマネージャモジュール２２６と印刷部との間のインターフェースを提供する。

パラレルポートドライバ２２８は、Ｗｅｂサーバモジュール２０３のリファレンスプリント機能や、Ｗｅｂブラウザモジュール２１１のＷｅｂプルプリント機能などのデータプリント機能がパラレルポートを介して不図示の出力機器にデータを出力する際のＩ／Ｆ（インターフェース）を提供する。

図３は、画像処理装置１１０の詳細なハードウェア構成を示すブロック図である。

制御ユニット１１１は、画像入力デバイスであるリーダ部１１３や、画像出力デバイスであるプリンタ部１１４と接続し、一方ではＬＡＮや公衆回線（ＷＡＮ）と接続することで、画像情報やデバイス情報の入出力を行うコントローラである。

ＣＰＵ３０１は、画像処理装置１１０の装置全体を制御するコントローラである。

ＲＡＭ３０２は、ＣＰＵ３０１が動作するために使用するシステムワークメモリである。また、ＲＡＭ３０２は、画像データを一時記憶するための画像メモリでもある。

ＲＯＭ３０３は、ブートＲＯＭであり、システムのブートプログラムが格納されている。

ＨＤＤ３０４は、ハードディスクドライブで、システムソフトウェアや画像データを格納する。

操作部Ｉ／Ｆ３０６は、操作部（ＵＩ）１１２との間のインターフェースを司り、操作部１１２のディスプレイ（図示せず）に表示する画像データを操作部１１２に対して出力する。また、ユーザが操作部１１２を介して入力した情報を、ＣＰＵ３０１に伝える役割も果たす。

ネットワーク（Network）Ｉ／Ｆ３０８は、ＬＡＮ１００との接続を司り、ＬＡＮ１００を介して情報の入出力を行う。

モデム（MODEM）３０９は、公衆回線との接続を司り、公衆回線を介して情報の入出力を行う。

以上のデバイス３０１〜３０６，３０８および３０９が、システムバス３０７上に配置されている。

画像バスＩ／Ｆ（Image Bus I/F）３０５は、システムバス３０７と、画像データを高速に転送する画像バス３１０とを接続するとともに、画像データのデータ構造を変換するバスブリッジである。

画像バス３１０は、ＰＣＩ（Peripheral Component Interconnect）バスまたはＩＥＥＥ１３９４で構成される。

画像バス３１０には、以下のデバイス３１１〜３１６が配置されている。

ラスターイメージプロセッサ（ＲＩＰ）３１１は、ネットワークから送信されたＰＤＬ（Page Description Language）コードをビットマップイメージに展開する。また、ＰＤＬ以外にも、たとえばＰＤＦ（Portable Document Format）データや各種アプリケーション固有のアプリケーションデータをビットマップイメージに展開するダイレクトプリントのための処理も行う。

デバイスＩ／Ｆ部３１２は、画像入出力デバイスであるリーダ部１１３およびプリンタ部１１４と、制御ユニット１１１とを接続し、画像データの同期系／非同期系の変換を行う。

スキャナ画像処理部３１３は、入力画像データに対し補正、加工、編集を行う。

プリンタ画像処理部３１４は、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。

画像回転部３１５は、画像データの回転を行う。

画像圧縮部３１６は、多値画像データに対してはＪＰＥＧ圧縮伸長処理を行い、二値画像データに対してはＪＢＩＧ（Joint Bi-level Image experts Group），ＭＭＲ，ＭＨ（Modified Huffman）の圧縮伸長処理を行う。

図４は、画像処理装置１１０の外観を示す図である。

画像入力デバイスであるリーダ部１１３は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサ（図示せず）を走査することによって、ラスターイメージデータを生成する。

ユーザが、原稿用紙を原稿フィーダ４０５のトレイ４０６にセットして、操作部１１２において原稿画像の読み取りを指示すると、前記図３のＣＰＵ３０１は、リーダ部１１３に指示を与え、これに応じて、フィーダ４０５は、原稿用紙を１枚ずつフィードし、リーダ部１１３は、原稿画像の読み取り動作を行う。

画像出力デバイスであるプリンタ部１１４は、ラスターイメージデータを用紙上に印刷する。その印刷方式としては、感光体ドラムや感光体ベルトを用いた電子写真方式や、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式を採用しても構わない。なお、プリント動作は、ＣＰＵ３０１からの指示に応じてなされる。

プリンタ部１１４は、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセット４０１，４０２および４０３を備えている。また、排紙トレイ４０４は、印字し終わった用紙を受けるものである。

図５は、操作部１１２の詳細な外観を示す図である。

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

スタートキー５０５は、原稿画像の読み取り動作を開始する場合等に用いられる。スタートキー５０５の中央部には、緑と赤の２色のＬＥＤからなるＬＥＤ表示部５０６が設けられ、その色によってスタートキー５０５が使える状態にあるかどうかが示される。

ストップキー５０３は、稼働中の動作を止める働きをする。

ＩＤキー５０７は、ユーザＩＤを入力するときに用いられる。

リセットキー５０４は、操作部１１２からの設定を初期化するときに用いられる。

図６は、操作部１１２の詳細な機能構成を示すブロック図である。

上述したように、操作部１１２は、操作部Ｉ／Ｆ３０６を介してシステムバス３０７に接続され、システムバス３０７には、ＣＰＵ３０１、ＲＡＭ３０２、ＲＯＭ３０３およびＨＤＤ３０４が接続されている。ＣＰＵ３０１は、ＲＯＭ３０３とＨＤＤ３０４に記憶された制御プログラム等に基づいてシステムバス３０７に接続される各種デバイスとのアクセスを総括的に制御する。また、ＣＰＵ３０１は、デバイスＩ／Ｆ３１２を介して接続されるリーダ部１１３から入力情報を読み込み、デバイスＩ／Ｆ３１２を介して接続されるプリンタ部１１４に出力情報としての画像信号を出力する。ＲＡＭ３０２は、ＣＰＵ３０１の主メモリであり、ワークエリア等として機能する。

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

図７は、画像処理装置１１０に組み込まれたアプリケーションの動作を説明するためのネットワーク構成の一例を示すブロック図である。

同図において、装置４３００は、リモートコピーにおける受信側（プリント側）の複合機器である。装置４３５０は、統合送信部モジュール２０４から同報配信される画像データを受信してプリントする、たとえばレーザビームプリンタ（ＬＢＰ）などのプリンタ機器である。装置４４００は、リモートプリントの受信側（プリント側）のデバイスである。装置４４５０は、同報配信される画像データを受信し格納するグループウェアサーバである。装置４５００および４６００は、同報配信される二値画像データを受信し格納する画像データベースサーバである。装置４５５０は、同報配信される電子メールを受信し格納するメールサーバである。装置４６５０は、情報コンテンツを有するＷｅｂサーバである。装置４７００は、ＷｅｂサーバなどにアクセスするＷｅｂブラウザである。

（ＵＩアプリケーション）
ＵＩモジュール２０１の詳細は、前述した通りであるので、ここではアドレスブックモジュール２０２について説明する。

アドレスブックモジュール２０２は、画像処理装置１１０の不揮発性メモリ、たとえばバッテリバックアップされたメモリやハードディスクなどに保存されていて、その中にはネットワーク接続された機器の特徴が記載されている。具体的には、以下に列挙するような情報がアドレスブックモジュール２０２に含まれている。すなわち、
（１）機器の正式名やエイリアス名
（２）機器のネットワークアドレス
（３）機器が処理可能なネットワークプロトコル
（４）機器が処理可能なドキュメントフォーマット
（５）機器が処理可能な圧縮タイプ
（６）機器が処理可能なイメージ解像度
（７）プリンタ機器の場合は給紙可能な紙サイズおよび給紙段の情報
（８）サーバ機器の場合はドキュメントを格納可能なフォルダ名
などである。

以下に説明する各アプリケーションは、アドレスブックモジュール２０２に記載された情報に基づいて、配信先の特徴を判別できる。また、アドレスブックモジュール２０２は、編集可能であるとともに、ネットワーク内のサーバなどに保存されているものがダウンロードされて使用される。または、直接参照することも可能である。

（リモートコピーアプリケーション）
リモートコピースキャンモジュール２０９で実行されるリモートコピーアプリケーションは、アドレスブックモジュール２０２によって認識可能な配信先に指定された機器が処理可能な解像度情報に従って、スキャナで読み取った二値画像データをＭＭＲ圧縮かつＴＩＦＦ（Tagged Image File Format）化した後、ＳＬＭモジュール２１５を介してネットワーク上の複合機器４３００などに送信する。

（同報配信アプリケーション）
統合送信部モジュール２０４で実行される同報配信アプリケーションは、リモートコピーアプリケーションと違い、一度の画像スキャンで複数の配信先に画像を送信することが可能である。また、その配信先もプリンタ機器に限らず、サーバなどにも直接配信可能である。以下、配信先毎に説明する。

配信先の機器のネットワークプリンタプロトコルがＬＰＤ（Line Printer Daemon）であり、かつ、公知のプリント記述言語（ＰＤＬ）が処理可能であることがアドレスブックモジュール２０２から認識される場合は、同様にアドレスブックモジュール２０２から認識される配信先の機器の画像解像度に従って画像を読み取り、画像自体はエンコーダモジュール２２１により圧縮し、さらにＰＤＬ化して、ＬＰＲモジュール２１３により配信先のプリンタ機器４３５０などに送信する。

配信先の機器が、ＳＬＭにより通信可能であり、かつ、サーバである場合には、アドレスブックモジュール２０２からサーバアドレスおよびサーバのフォルダ指定を認識して、リモートコピーアプリケーションと同様に、スキャナにより読み取った二値画像データをＭＭＲ圧縮し、かつ、ＴＩＦＦ化し、ＳＬＭモジュール２１５を介してネットワーク上のサーバ４５５０や４５００などの特定フォルダに格納することが可能である。また、配信先のサーバが、ＪＰＥＧ圧縮された多値画像を処理可能だと判断される場合には、スキャナにより読み取った画像をＪＰＥＧ圧縮し、かつ、ＪＦＩＦ（JPEG File Interchange Format）化し、ＳＬＭモジュール２１５を介してネットワーク上のサーバ４６００などの特定フォルダに格納することが可能である。

配信先の機器が電子メールサーバの場合には、アドレスブックモジュール２０２に記載されたメールアドレスを認識して、スキャナにより読み取った二値画像データをＭＭＲ圧縮し、かつ、ＴＩＦＦ化し、ＳＭＴＰモジュール２１４を介して電子メールサーバ４５５０などに送信する。その後の配信は、電子メールサーバ４５５０により実行される。

（Ｗｅｂプルプリントアプリケーション）
Ｗｅｂブラウザモジュール２１１で実行されるＷｅｂプルプリントアプリケーションは、Ｗｅｂサーバ４６５０などのＷｅｂサイトの情報をプリントする。

（Ｗｅｂサーバアプリケーション）
Ｗｅｂサーバモジュール２０３で実行されるＷｅｂサーバアプリケーションは、ＨＴＭＬなどで記述された情報を、ＨＴＴＰモジュール２１２を介してＷｅｂブラウザ４７００などに提供する。Ｗｅｂサーバアプリケーションは、静的なＨＴＭＬ文書などの情報だけでなく、装置の管理情報を反映した文書を動的に生成して、Ｗｅｂブラウザ４７００などに提供する。この管理情報は、統合送信部モジュール２０４、リモートコピースキャンモジュール２０９、リモートコピープリントモジュール２１０および制御ＡＰＩモジュール２１８を介して取得され、ＨＴＴＰモジュール２１２、ＴＣＰ／ＩＰ通信モジュール２１６およびネットワークドライバ２１７を介して、Ｗｅｂクライアントに通知される。さらにまた、Ｗｅｂサーバモジュール２０３は、Ｗｅｂクライアントにリファレンスプリント機能も提供する。リファレンスプリントでは、ＷｅｂクライアントがＷｅｂサーバモジュール２０３に対して、ＨＴＴＰでＰＯＳＴ要求の内容として（またはＧＥＴ要求のパスの一部に埋め込んで）ＵＲＬ情報を送信する。Ｗｅｂサーバモジュール２０３は、ＵＲＬ情報を受信し、次に受信したＵＲＬの位置からＨＴＴＰによってデータを取得し、次に取得したデータをそのまま制御ＡＰＩモジュール２１８に渡すことによってプリントを行う。ＨＴＴＰによって取得可能な位置に、各種ＰＤＬなどで記述された、プリンタがプリント可能なデータが置かれている場合には、クライアントは、単にＵＲＬをＷｅｂサーバに指示するだけで、所望のプリントを行うことできる（データの実体を送信せず、「参照」を送信するだけでよい）。プリンタは、各種ＰＤＬで記述されたデータの他に、ＰＤＦのデータやアプリケーションデータを直接プリントするダイレクトプリント機能を備えることができるため、ネットワークのＷｅｂサーバに散在して配置された各種データを効率良くプリントすることができる。

図８は、Ｗｅｂブラウザモジュール２１１のソフトウェア構成を示すブロック図である。

プロトコル処理部８０１は、ＨＴＴＰモジュール２１２を介して、他のネットワークノードとの間に接続を確立し通信する。具体的には、ＵＲＬによって記述されたリソースに対してＨＴＴＰ要求を発行し、その応答を得る。この過程で、各種符号化形式に則した通信データの符号化・復号化も行う。プロトコル処理部８０１が、ＨＴＭＬなどのマークアップ言語で記述された構造を持つテキストデータと、その構造に埋め込まれる画像、スクリプトおよびスタイルなどのデータを取得すると、プロトコル処理部８０１は、そのデータをコンテンツパーサ８０２に引き渡す。一方、プロトコル処理部８０１が、ページ全体がひとつの画像データ形式や構造を持たないテキストデータ形式であるようなコンテンツを取得した場合には、プロトコル処理部８０１は、そのデータをレンダラ８０８に引き渡す。これに応じて、レンダラ８０８は、レンダリングを行い、そのレンダリング結果をＵＩモジュール２０１に表示させる。

さらに、プロトコル処理部８０１が、Ｗｅｂブラウザモジュール２１１によって処理できない形式のデータを取得した場合には、プロトコル処理部８０１は、後述する代替処理に委ねる判断を行い、そのデータを制御ＡＰＩモジュール２１８に引き渡す。

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

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

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

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

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

レイアウトエンジン８０７は、スタイルシートパーサ８０６によるスタイルシートの解析結果を反映して文書のレイアウトを決定する。

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

イベント処理部８０９は、操作部１１２上のタッチパネルシート５０２や各キーなどに対してユーザが行った操作のイベントを受信して、各イベントに対応した処理を行う。イベント処理部８０９はまた、制御ＡＰＩモジュール２１８から装置やジョブなどの状態遷移イベントを受信して、各イベントに対応した処理を行う。

ＤＯＭ処理部８０４が管理するＤＯＭのツリー構造には、オブジェクトのクラス毎、および、オブジェクトインスタンス毎に、各種イベントに対応するイベントハンドラが登録されている。

イベント処理部８０９は、生起したイベントに応じて、ＤＯＭ処理部８０４が管理するオブジェクト群の中から、そのイベントの処理を担当すべきオブジェクトを決定し、イベントを配信する。イベントの配信されたオブジェクトは、そのイベントに対応するイベントハンドラのアルゴリズムに応じて、各種の処理を実行する。イベントハンドラの処理には、ＤＯＭ処理部８０４が保持するＤＯＭの更新、レイアウトエンジン８０７に対する再描画指示、プロトコル処理部８０１に対するＨＴＴＰ要求発行の指示、制御ＡＰＩモジュール２１８の呼び出しによる画像処理装置機能の制御などがある。

スクリプトインタプリタ８０５は、ＪａｖａＳｃｒｉｐｔ（登録商標）やＥＣＭＡ Ｓｃｒｉｐｔなどのスクリプトを解釈し、実行するインタプリタである。スクリプトは、文書に埋め込まれたり、あるいは、文書からリンクされた別ファイル中に記述されたりして、ＤＯＭに対する操作などを行う。コンテンツの提供者は、スクリプトによって、提供する文書の動的な挙動をプログラムできる。

図９は、ＬＣＤ表示部５０１に表示されるＷｅｂブラウザの画面構成の一例を示す図である。

同図において、タブ９０１は、Ｗｅｂブラウザ機能と他の機能（コピー、ボックス、送信および拡張）との画面切り替えを行うためのものである。

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

ＯＫボタン９０３は、入力したＵＲＬ文字列を確定するソフトキーである。ＵＲＬが確定されると、Ｗｅｂブラウザモジュール２１１は、当該リソースの取得を行うためのＨＴＴＰ要求を発行する。

プログレスバー９０４は、ＨＴＴＰ要求応答によるコンテンツ取得処理の進捗状況を示すものである。

コンテンツ表示領域９０５は、取得したリソースが表示される領域である。

戻るボタン９０６は、ソフトキーであり、コンテンツ表示の履歴をさかのぼり、現時点で表示しているコンテンツの前に表示したコンテンツを表示し直すためのものである。

進むボタン９０７は、ソフトキーであり、コンテンツ表示の履歴をさかのぼって表示しているときに、現時点で表示しているコンテンツの後に表示したコンテンツの表示に進ませるためのものである。

リロードボタン９０８は、ソフトキーであり、現時点で表示しているコンテンツの再取得と再表示を行うためのものである。

中止ボタン９０９は、ソフトキーであり、実行中のコンテンツ取得処理を中止させるためのものである。

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

図１０は、ＨＴＴＰによる要求と応答の処理の流れの一例を示すシーケンス図である。

クライアント１００１は、ＨＴＴＰ要求を送信し、ＨＴＴＰ応答を受信するソフトウェアであり、画像処理装置１１０内蔵のＷｅｂブラウザや、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、携帯電話などで稼動する一般的なＷｅｂブラウザや、さらにＷｅｂブラウザと同様の方法でＷｅｂサーバにアクセスしてサービスの利用または中継を行う各種のソフトウェアに相当する。

サーバ１００２は、ＨＴＴＰ要求を受信して対応する処理を行い、さらにＨＴＴＰ応答を返信するソフトウェアであり、サーバ１５５上で稼動するソフトウェアをはじめとするＨＴＴＰサーバに相当する。

ＨＴＴＰ要求１００３では、クライアント１００１は、所望のリソースに対するＧＥＴ要求をサーバ１００２に送信する。リソースは、一般にＵＲＩ（Uniform Resorce Identifier）（特にＵＲＬ）形式によって指定される。サーバ１００２は、ＧＥＴ要求に指定されたリソースに対応するデータを取得、または、生成して、ＨＴＴＰ応答１００４によって返送する。ここで、指定されたリソースが静的なファイルに対応する場合には、サーバ１００２は、サーバ１５５のファイルシステムから該当するファイルを読み出して、そのデータを取得する。一方、指定されたリソースがＣＧＩプログラムやＳｅｒｖｌｅｔなどの処理に対応する場合には、サーバ１００２は、該当する処理を実行する。すなわち、サーバサイド処理が行われる。サーバサイド処理は、要求に対する応答を生成するものであるが、この過程で、所定のサービスを達成するために必要なビジネスロジックの実行や、バックエンドのデータベース管理システムへのアクセスなどの副作用が伴うこともある。そして、サーバサイド処理の結果として生成されたデータを返送する。たとえば、画像処理装置１１０の消耗品カタログを表示するためのリソースが指定された場合には、電子商取引のためのソフトウェアを実行し、データベースの中から用紙、トナー、部品の最新価格や在庫状況などのレコードを参照し、これらの情報をＨＴＭＬ形式またはＸＭＬ形式に整形して、カタログ文書データを生成する処理が行われる。

ＨＴＴＰ応答１００４で得られたデータが表示可能な形式である場合には、クライアント１００１は、そのコンテンツの表示を行う。得られたデータがＨＴＭＬ文書などであり、文書中に他のリソースへの参照情報（画像や埋め込みオブジェクトや他のＨＴＭＬ文書の取得元ＵＲＩなど）が埋め込まれていれば、Ｗｅｂブラウザは、参照される他のリソースを取得するためのＨＴＴＰ要求の送信を必要なだけ繰り返す。得られたデータがＨＴＭＬ文書などであれば、Ｗｅｂブラウザ上に表示されたページ中のハイパーテキストなど、リンク情報が埋め込まれたアンカーをユーザが選択するだけで、次々に新たなリソースの取得や表示を繰り返すことができる。

ＨＴＴＰ要求１００５は、ＰＯＳＴ要求である。ＨＴＭＬ文書がフォーム（ＦＯＲＭ）を含み、そのメソッドにＰＯＳＴが指定されている場合には、ユーザがフォームをサブミットすると、指定リソースに対するＰＯＳＴ要求が送信される。ＰＯＳＴ要求では、クライアント１００１からサーバ１００２に向けてデータを送信する（応答によってサーバ１００２からクライアント１００１に向けたデータの返信も行われる）。Ｗｅｂブラウザに表示されたフォームに、ユーザが入力した情報が符号化されて、ＰＯＳＴ要求によってサーバ１００２に送信される。サーバ１００２の指定リソースは、クライアント１００１から送られたデータを受信して処理を行い、ＨＴＴＰ応答１００６を生成して返信する。

ＨＴＴＰ要求としてクライアント１００１からサーバ１００２に送信されるメッセージ中に含まれるプロトコルヘッダのUser-Agent属性によって、クライアント１００１は、サーバ１００２に対して、自らがどのような種類のクライアントであるかを示すことができる。User-Agentの値には、組み込みＷｅｂブラウザの実装を識別するための固有の文字列が記述される。

ＨＴＴＰ応答としてサーバ１００１からクライアント１００２に返されるデータは、プロトコルヘッダのContent-Type属性によってそのデータ型が記述される。具体的に、Content-Typeには、データ型の記述子が、以下のように記述される。すなわち、ＨＴＴＰ応答によって、たとえばＨＴＭＬ文書を転送する場合には、
Content-Type: text/html; charset=Shift_JIS
などのように記述される。また、ＨＴＴＰ応答によって、たとえばＰＤＦ文書を転送する場合には、
Content-Type: application/pdf
のように記述される。

図１１は、サーバサイド処理とクライアントサイド処理の流れの一例を示す図である。

ＨＴＴＰ要求１００３では、クライアント１００１は、所望のリソースに対するＧＥＴ要求をサーバ１００２に送信する。リソースは、一般にＵＲＩ（特にＵＲＬ）形式によって指定される。サーバ１００２は、ＧＥＴ要求で指定されたリソースに対応するデータを取得、または、生成して、ＨＴＴＰ応答１００４によって返送する。ＨＴＴＰ応答１００４で得られたデータが表示可能な形式である場合には、クライアント１００１は、そのコンテンツの表示を行う。得られたデータがＨＴＭＬ文書などであれば、Ｗｅｂブラウザは、文書の解釈を行いながら、ＤＯＭ構築部８０３によってＤＯＭを構築する。文書にＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプトが埋め込まれている場合には、埋め込まれたスクリプトを、対応するスクリプトインタプリタにロードし、クライアントサイド処理を実行する。クライアントサイド処理では、スクリプトの内容次第でさまざまな処理を実行することができるが、たとえば、スクリプトが生成したデータを解析中の文書に挿入するなど、動的な文書操作が可能である。文書のｏｎｌｏａｄイベントに呼応するイベントハンドラがスクリプトインタプリタにロードされ、登録されていた場合、文書を構成するすべてのリソースが取得され、解析されたタイミングで、イベントハンドラのコードが実行される。この実行によって文書を操作することもできる。

さらに、タッチパネルなどのユーザ入力手段を操作することによって、文書や文書の要素にイベントを生起させたり、スクリプトインタプリタが監視するタイマのタイムアップなどのイベントが生起したりした場合に、イベントハンドラとしてロードされ、登録されたスクリプトのコードがあれば、それが実行される。

サーバサイド処理の場合と異なり、クライアントサイド処理の実行は、クライアント１００１側のスクリプトインタプリタによって処理されるため、ユーザ入力をサーバ１００２側まで伝える必要は必ずしもない。単純なコンピューティングによって達成される処理の場合、クライアントサイド処理で実現すれば、サーバ１００２との要求・応答の通信時間が省略できる分だけターンアラウンドタイムを改善できる。また、各クライアント１００１が処理を分担するため、サーバ１００２側のコンピューティング資源に負荷が集中することを避ける効果もある。特筆すべきは、処理の実現にサーバ１００２との対話的な通信が不要となるために、装置のユーザがプライバシーを求める情報をネットワークやサーバ１００２に送らずに装置の中にとどめたままで処理することが可能となる。

現実には、クライアントサイド処理とサーバサイド処理の両者を適切に組み合わせてサービスを実装する場合が多い。

図１２は、画像処理装置１１０を利用するユーザのユーザアカウントを管理するデータ構造の一例を示す図であり、ユーザアカウント情報のテーブルにおいて、各行は装置を利用し得る個々のユーザに対応している。

同図において、“ｓｙｓｔｅｍ”と“ｇｕｅｓｔ”は、画像処理装置１１０で内部的に用いる仮想的なユーザであり、それ以外は、実際に画像処理装置１１０を利用する実在のユーザ個人に対応している。

“ｓｙｓｔｅｍ”は、装置システムが所有者であるような資源を識別するために利用される。“ｇｕｅｓｔ”は、ユーザを認証しなくとも一部の資源が利用可能であるような運用を行う場合に、認証されていないユーザを表現するために利用される。各列は、それぞれ、以下の意味を持つ。

すなわち、ユーザ名の列は、ユーザを識別するための識別子である。同図では、文字列によって表現しているが、内部的には個々のユーザに対応する数値などで表現してもよい。

プライマリグループの列は、各ユーザが所属する既定のグループを表現する識別子である。各ユーザは、既定のグループに加えて他の複数のグループに所属することもできる。グループについては後述する。

パスワードの列は、what-you-know型のユーザ認証によってユーザを認証するときに用いるパスワードである。スマートカードの機能によってユーザ認証を行うときには、この列の情報を用いなくてもよいし、またスマートカードと併用するＰＩＮ（Personal Identification Number）を格納するために用いてもよい。

電子メールアドレスの列は、各ユーザの電子メールアドレスを示している。

内線の列は、各ユーザの内線電話番号を示している。

この他、ユーザ毎の情報を登録するためにさまざまな列を追加してもよい。たとえば、ユーザのフルネームや、既定の機能や、既定のボックス内フォルダや、好みの設定などを登録する列を追加すれば、それらをユーザ毎に固有の情報として格納することができる。

図１３は、画像処理装置１１０を利用するユーザのグループを管理するデータ構造の一例を示す図であり、各行はユーザが所属し得る個々のグループに対応している。

グループは、ユーザの集合を表現するオブジェクトであり、組織の部門や役職および担う役割など、さまざまな集合を定義することができる。ユーザは、同時に複数のグループに所属できる。

グループ名の列は、グループを識別するための識別子である。同図では、文字列によって表現しているが、内部的には個々のグループに対応する数値などで表現してもよい。

メンバリストの列は、グループに所属するユーザたちを定義するリストを示している。本実施の形態では、“ｓｙｓｔｅｍ”は、ユーザシステムのプライマリグループとして用いるための仮想的なグループである。“ｇｕｅｓｔ”は、ユーザ認証を行わずに装置の利用を許す場合のゲストユーザに相当する。“ａｄｍｉｎ”は、装置の管理を行う管理者のグループである。“ｕｓｅｒ”は、装置にユーザアカウントを持つ全ユーザのグループである。“ｒｄ”と“ｓａｌｅｓ”は、組織の部門に相当するグループである。“ｍａｎａｇｅｒ”は、組織の役職に相当するグループである。“ｏｐｅｒａｔｏｒ”は、装置内部のデータのバックアップなど専門的な操作を行うための管理者に準ずる役割に相当するグループである。

図１４は、画像処理装置１１０を構成する各種資源を抽象化して表現したリソースクラスのデータ構造を示す模式図である。

リソースクラスは、装置オブジェクトモデルを構成する各種オブジェクトの設計図にあたるクラスの一例である。各装置オブジェクト（およびその設計図としてのクラス）は、内部にいくつかの特性（フィーチャ）を持っている。特性は、データや他のオブジェクトへの参照を保持する属性（またはプロパティ、データメンバ、変数などと呼ばれる）と、操作（またはメソッド、オペレーション、メンバ関数など）とを含んでいる。

装置オブジェクトとそのクラスは、スクリプトインタプリタがサポートする各種のスクリプト言語体系にバインドされ、それぞれの言語の構文と意味論によって利用できる。ＪａｖａＳｃｒｉｐｔ（登録商標）において、装置オブジェクトモデルのオブジェクトは、ＪａｖａＳｃｒｉｐｔ（登録商標）のオブジェクト型に対応付けられる。装置オブジェクトモデルのクラスは、ＪａｖａＳｃｒｉｐｔ（登録商標）的な意味でのクラスに対応付けられる。なお、他のスクリプト言語の多くと同様に、ＪａｖａＳｃｒｉｐｔ（登録商標）は、「強い型付け」された言語ではなく、Ｊａｖａ（登録商標）やＣ＋＋のような意味でのクラスという概念は持たない。ただし、クラスに相当するオブジェクトを定義し、そのオブジェクトのコンストラクタとプロトタイプオブジェクトを利用することで、クラスが持つ多くの概念を実質的に実現している。

リソースクラス１９０１は、画像処理装置１１０が扱うすべての資源に相当するクラスのスーパークラスである。リソースクラス１９０１は、複数のインスタンス属性とクラス属性とを保持できる。

オーナＩＤは、インスタンス属性であり、当該資源を所有するユーザの識別子を保持する。

グループＩＤは、インスタンス属性であり、当該資源の所有権を持つグループの識別子を保持する。

オーナへの読み出し許可は、インスタンス属性であり、オーナＩＤが示すユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

オーナへの書き込み許可は、インスタンス属性であり、オーナＩＤが示すユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

オーナへの実行許可は、インスタンス属性であり、オーナＩＤが示すユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

グループへの読み出し許可は、インスタンス属性であり、グループＩＤが示すグループに所属するユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

グループへの書き込み許可は、インスタンス属性であり、グループＩＤが示すグループに所属するユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

グループへの実行許可は、インスタンス属性であり、グループＩＤが示すグループに所属するユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

他者への読み出し許可は、インスタンス属性であり、ユーザＩＤが示すユーザにも、グループＩＤが示すグループに所属するユーザにも該当しないユーザが、当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

他者への書き込み許可は、インスタンス属性であり、ユーザＩＤが示すユーザにも、グループＩＤが示すグループに所属するユーザにも該当しないユーザが、当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

他者への実行許可は、インスタンス属性であり、ユーザＩＤが示すユーザにも、グループＩＤが示すグループに所属するユーザにも該当しないユーザが、当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

既定のオーナＩＤは、クラス属性であり、当該資源を所有するデフォルトのユーザの識別子を保持する。

既定のグループＩＤは、クラス属性であり、当該資源の所有権を持つデフォルトのグループの識別子を保持する。

オーナへの既定の読み出し許可は、クラス属性であり、オーナＩＤが示すユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

オーナへの既定の書き込み許可は、クラス属性であり、オーナＩＤが示すユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

オーナへの既定の実行許可は、クラス属性であり、オーナＩＤが示すユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

グループへの既定の読み出し許可は、クラス属性であり、グループＩＤが示すグループに所属するユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

グループへの既定の書き込み許可は、クラス属性であり、グループＩＤが示すグループに所属するユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

グループへの既定の実行許可は、クラス属性であり、グループＩＤが示すグループに所属するユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

他者への既定の読み出し許可は、クラス属性であり、ユーザＩＤが示すユーザにも、グループＩＤが示すグループに所属するユーザにも該当しないユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

他者への既定の書き込み許可は、クラス属性であり、ユーザＩＤが示すユーザにも、グループＩＤが示すグループに所属するユーザにも該当しないユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

他者への既定の実行許可は、クラス属性であり、ユーザＩＤが示すユーザにも、グループＩＤが示すグループに所属するユーザにも該当しないユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。

装置オブジェクトモデルを構成するオブジェクトを、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプトが扱うとき、スクリプトの権限は、Ｗｅｂブラウザを操作している実効ユーザの権限に等しいものとする。スクリプトにそのオブジェクトの読み出し権限がある場合のみ、スクリプトからの属性の読み出しが許可され、スクリプトにそのオブジェクトの書き込み権限がある場合のみ、スクリプトからの属性の変更が許可され、スクリプトにそのオブジェクトの実行権限がある場合のみ、スクリプトからの操作の呼び出しが許可される。さらに、以上説明した許可および既定の許可の属性において、「読み出し」、「書き込み」および「実行」の意味は、本リソースクラスを継承するサブクラスが表現する各種の資源毎に適切にその資源に固有のセマンティクスが追加定義される場合がある。

以上説明した許可のインスタンス属性と既定の許可のクラス属性とは、それぞれが対応している。ある資源のクラスからインスタンスを生成するときに、そのクラスの既定の許可のクラス属性を用いて生成されるインスタンスの、対応する許可のインスタンス属性を初期化する。または、ある資源のインスタンスに許可のインスタンス属性が未設定の場合に、そのインスタンスのクラスが保持している既定の許可のクラス属性を代わりに用いるように構成してもよい。

本実施の形態では、上記許可属性群によって資源のアクセス権限を表現したが、資源に相当するクラス毎に公知のアクセスコントロールリスト（ＡＣＬ）を保持することによって、資源のアクセス権限を表現するように構成してもよい。

図１５は、画像処理装置１１０を構成する各種資源間の継承関係を表すデータ構造の一例を示すクラス図である。

同図の各クラスは、オブジェクトを生成（インスタンス化）するために用いられる。これらのクラスによって生成されるオブジェクト群は、ＤＯＭ処理部８０４内部に保持され、スクリプトインタプリタ８０５がアクセスする装置オブジェクトモデルを構成する。

画像処理装置１１０が停止している間も、クラスとクラスとの間の関係は、バイト列にシリアライズされ、ＨＤＤ３０４中にファイルとして永続的に記憶されている。画像処理装置１１０の起動時と稼動中、制御ユニット１１１のＣＰＵ３０１によってこのファイルが読み込まれ、本クラス図に示すクラス群とそのインスタンスであるオブジェクト群がそれぞれ相互関係を保持したデータ構造としてＲＡＭ３０２内に動的に生成され、維持管理される。

リソース１９０１は、システム内の各種資源を抽象化したクラスであり、マルチユーザ対応された画像処理装置１１０のアクセス制御に用いられる。リソースクラスは、少なくとも前記図１４で説明した属性を備え、これらは、以下で説明するすべてのサブクラスに継承され、すべてのサブクラスが共通に持つ特性となる。

ユニット１９０２は、リソース１９０１のサブクラスであり、画像処理装置１１０を構成する物理的なユニットを抽象化したクラスである。

操作部ユニット１９０３、スキャナユニット１９０４、マーキングユニット１９０５、原稿給紙ユニット１９０６，１９０７および排紙ユニット１９０８は、それぞれユニット１９０２のサブクラスである。

外部インターフェースユニット１９４０は、ユニット１９０２のサブクラスであり、外部接続のためのインターフェースユニットを抽象化したクラスである。

画像処理システムネットワークユニット１９４１、ＵＳＢユニット１９４２および通信ユニット１９４３は、外部インターフェースユニット１９４０のサブクラスである。

リーダ部１９７１は、ユニット１９０２のサブクラスであり、リーダ部１１３に対応する。

プリンタ部１９７２は、ユニット１９０２のサブクラスであり、プリンタ部１１４に対応する。

装置１９７０は、ユニット１９０２のサブクラスであり、画像処理装置１１０に対応する。

外部ユニット１９４８は、ユニット１９０２のサブクラスであり、外部インターフェースユニットなどを介して装置に接続される外部ユニットを抽象化したクラスである。

トランスポート１９４５は、リソース１９０１のサブクラスであり、画像処理装置１１０がネットワークや通信回線などを介して他のノードと通信するための各種の通信経路を抽象化したクラスである。

ネットワークポート１９４６は、トランスポート１９４５のサブクラスであり、ネットワークインターフェースによって他のノードのプロセスと通信するための通信経路を抽象化したクラスである。ネットワークポート１９４６のインスタンスは、たとえばＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などのプロトコルとプロトコル毎のポート番号とによって特徴付けられる。

通信回線１９４７は、ファクスなどに用いられる通信回線によって他の装置と通信するための通信経路を抽象化したクラスである。通信回線１９４７のインスタンスは、たとえば電話交換回線網の回線に割り当てられた回線番号などによって特徴付けられる。

機能１９０９は、リソース１９０１のサブクラスであり、画像処理システムが提供する機能を抽象化したクラスである。

コピー機能１９１０は、機能１９０９のサブクラスであり紙原稿を紙に複写する機能を示す。さらに、白黒コピー１９１１とカラーコピー１９１２は、コピー機能１９１０のサブクラスである。

送信機能１９１３は、機能１９０９のサブクラスであり、デジタル文書データを各種のプロトコルによって送信する機能を示す。さらに、ファクス送信１９１４、電子メール送信１９１５、ファイル転送送信１９１６、ファイル共有送信１９１７およびデータベース入力送信１９１８は、送信機能１９１３のサブクラスであり、デジタル文書データをそれぞれに対応するプロトコルによって送信する機能を示す。

ボックス機能１９１９は、機能１９０９のサブクラスであり、原稿から読み取った画像データやＰＤＬ展開によって得られた文書データなどをシステム内のストレージに蓄積し、さらに蓄積された文書データの閲覧、プリント、送信、管理などを行う機能を示す。

ボックス格納１９５０は、ボックス機能１９１９のサブクラスであり、ボックス機能のうち、特に文書データなどをストレージに蓄積する機能を示す。

ボックス出力１９５１は、ボックス機能１９１９のサブクラスであり、ボックス機能のうち、特にストレージに蓄積された文書データを読み出して行うプリントや送信などの機能に相当する。

セキュアプリント１９５２は、ボックス機能１９１９のサブクラスであり、ボックス機能のうち、特にクライアントＰＣから受信したプリントデータをそのままプリントせず、一旦ストレージに蓄積し、ユーザが操作部１１２から明示的なプリント操作を行ったときにプリントする留め置きプリント機能に相当する。

受信機能１９２２は、機能１９０９のサブクラスであり、送信機能１９１３と同様の各種プロトコルによってデジタル文書データを受信し、その蓄積、転送、プリントなどを行う機能を示す。

スキャン機能１９５３は、機能１９０９のサブクラスであり、リーダ部１１３を用いて原稿画像を読み取り電子的な文書データ化する機能を示す。

プリント機能１９５４は、機能１９０９のサブクラスであり、クライアントＰＣなどから受信したプリントデータをプリンタ部１１４によってプリント出力する機能を示す。

ＬＩＰＳプリント１９５５は、プリント機能１９５４のサブクラスであり、クライアントＰＣなどから受信した、公知のＬＩＰＳ言語のＰＤＬデータを解釈展開し、プリント出力する機能を示す。

ＰｏｓｔＳｃｒｉｐｔプリント１９５６は、プリント機能１９５４のサブクラスであり、クライアントＰＣなどから受信した、公知のＰｏｓｔＳｃｒｉｐｔ言語のＰＤＬデータを解釈展開し、プリント出力する機能を示す。

ＰＣＬプリント１９５７は、プリント機能１９５４のサブクラスであり、クライアントＰＣなどから受信した、公知のＰＣＬ言語のＰＤＬデータを解釈展開し、プリント出力する機能を示す。

ジョブ１９２１は、リソース１９０１のサブクラスであり、機能１９０９の各種サービスに対応する実際のジョブを抽象化したクラスである。

ジョブリスト１９５８は、ジョブのインスタンスを複数格納可能なコンテナであり、実行中ジョブリストや中断中ジョブリストなど、一定の種類のジョブの集合を抽象化したクラスである。

履歴１９２２は、リソース１９０１のサブクラスであり、ジョブ１９２１のオブジェクトの実行や終了に関する情報や、システムの動作に伴って生起する各種事象に関する情報を含む、履歴情報のレコードを抽象化したクラスである。

履歴リスト１９５９は、履歴のインスタンスを複数格納可能なコンテナであり、ジョブ履歴やシステム履歴など、一定の種類の履歴の集合を抽象化したクラスである。

ボックス１９２３は、リソース１９０１のサブクラスであり、機能１９０９によって扱われるファイルシステムの管理単位を抽象化したクラスである。

フォルダ１９２４は、リソース１９０１のサブクラスであり、機能１９０９によって扱われるファイルシステムにおいて、複数のファイルをグルーピングするための管理構造を抽象化したクラスである。

文書１９２５は、リソース１９０１のサブクラスであり、機能１９０９によって扱われるファイルシステムにおける個々のファイル、すなわち各種のデジタル文書を抽象化したクラスである。

アドレス帳１９２６は、リソース１９０１のサブクラスであり、システムのユーザとユーザのグループを登録し、また、送信機能１９１３および受信機能１９２０などの機能において、アドレス情報を扱うために用いられるアドレスのリストを抽象化したクラスである。

受信転送ルール１９２７は、受信機能１９２０において受信文書を転送する際の、転送条件や転送宛先指定や挙動記述などのルール群を抽象化したクラスである。

設定１９２８は、リソース１９０１のサブクラスであり、システムの各種の動作を制御する動作パラメータの設定を抽象化したクラスである。さらに、ユーザ設定１９２９と管理者設定１９３０は、設定１９２８のサブクラスであり、それぞれエンドユーザ向けの設定と管理者向けの設定を示す。

暗号鍵・電子証明１９６０は、リソース１９０１のサブクラスであり、画像処理装置１１０が保持管理し、暗号処理、ユーザ認証、クライアント認証、サーバ認証などに用いる各種の電子的な鍵や署名や証明書などのデータを示す。暗号鍵・電子署名１９６０のインスタンスは、一般にセキュリティー上極度に重要であり、また、ユーザ個人毎に所有されるべき情報も含むため、厳格にアクセス制御されなければならない。

図１６は、画像処理装置１１０が扱う各種資源間の集約（aggregation）関係を表すデータ構造の一例を示すクラス図である。

同図の各クラスは、オブジェクトを生成（インスタンス化）するために用いられる。これらのクラスによって生成されるオブジェクト群は、ＤＯＭ処理部８０４内部に保持され、スクリプトインタプリタ８０５がアクセスする装置オブジェクトモデルを構成する。

画像処理装置１１０が停止している間も、クラスとクラスとの間の関係は、バイト列にシリアライズされ、ＨＤＤ３０４中にファイルとして永続的に記憶される。画像処理装置１１０の起動時と稼動中、制御ユニット１１１のＣＰＵ３０１によってこのファイルが読み込まれ、本クラス図に示すクラス群とそのインスタンスであるオブジェクト群が、それぞれ相互関係を保持したデータ構造としてＲＡＭ３０２内に動的に生成され、維持管理される。このデータ構造は、各種資源間の全体‐部分の集約関係を表現している。本実施の形態では、画像処理装置１１０に関連する各種の資源群を管理する負担を軽減するために、資源間の集約関係を定義する。ユニットとサブユニット（部分ユニット）や、コンテナとコンテンツなど、物理的および概念的に何らかの包含関係が認められ、その関係が資源管理に役立つものであれば導入する。

同図中の各クラスは、それぞれ図１５中の対応するクラスと同一である。対応するクラスには同一符号を付し、その詳細な説明は省略する。

装置１９７０は、便宜上、画像処理装置１１０の全体を表している。リーダ部１９７１は、装置１９７０の部分である。原稿給紙ユニット１９０６とスキャナユニット１９０４は、リーダ部１９７１の部分である。

操作部ユニット１９０３は、装置１９７０の部分である。

プリンタ部１９７２は、装置１９７０の部分である。給紙ユニット１９０７、マーキングユニット１９０５および排紙ユニット１９０８は、装置１９７０の部分である。

ネットワークユニット１９４１は、装置１９７０の部分である。ネットワークポート１９４６は、ネットワークユニット１９４１の部分である。

通信ユニット１９４３は、装置１９７０の部分である。通信回線１９４７は、通信ユニット１９４３の部分である。

ＵＳＢユニット１９４２は、装置１９７０の部分である。外部ユニットは１９４８の部分である。

ボックス１９２３は、装置１９７０の部分である。フォルダ１９２４は、ボックス１９２３の部分である。文書１９２５は、フォルダ１９２４の部分である。

ジョブリスト１９５８は、装置１９７０の部分である。ジョブ１９２１は、ジョブリスト１９５８の部分である。

履歴リスト１９５９は、装置１９７０の部分である。履歴１９２２は、履歴リスト１９５９の部分である。

図１７は、装置オブジェクトモデルのインスタンスを構成するオブジェクトの一部を示す図である。

同図において、各四角は、オブジェクト、すなわち各クラスのインスタンスを示す。各オブジェクトの近傍に付した番号は、そのオブジェクトに対応するクラスの符号を表している。

装置オブジェクトモデルを構成するオブジェクトは、そのクラスが備える特性、すなわち属性や操作を持っている。オブジェクトのクラスに定義された特性に加えて、抽象‐具体関係の親クラスの特性も継承によって持っている。たとえば、Deviceクラスのオブジェクトdeviceは、装置クラス１９７０に定義された特性と、その抽象クラスであるユニットクラス１９０２と、さらにその抽象クラスであるリソースクラス１９０１の特性を持っている。また、リソースクラスのさらに抽象クラスである、ＤＯＭのElementクラスやNodeクラス（不図示）および、ＪａｖａＳｃｒｉｐｔ（登録商標）の継承関係の最上位に位置するObjectクラス（不図示）からも特性を継承している。各オブジェクトは、その属性によってその部分オブジェクトを参照している。たとえばdeviceオブジェクトは、属性printerを持ち、この属性はプリンタ部クラス１９７２のインスタンスを参照する。

deviceオブジェクトは、装置クラス１９７０のインスタンスであり、以下の特性を持つ。

属性serialは、シリアル番号を表す。属性venderは、ベンダを表す。属性modelは、モデルを表す。以上は、ユニットクラス１９０２から継承した属性の一部である。

属性firstChildは、全体‐部分関係の子にあたる最初のオブジェクトを参照する。以上は、ＤＯＭのNodeクラスから継承した属性の一部である。

属性printerは、このオブジェクトの全体‐部分の子にあたるプリンタ部クラス１９７２のインスタンスを参照する。属性readerは、このオブジェクトの全体‐部分の子にあたるリーダ部クラス１９７１のインスタンスを参照する。属性communicationは、このオブジェクトの全体‐部分の子にあたる通信ユニットクラス１９４３のインスタンスを参照する。属性logは、このオブジェクトの全体‐部分の子にあたるログリストクラス１９５９のインスタンスを参照する。以上は、装置クラス１９７０で定義された属性の一部である。

操作diagは、画像処理装置１１０の自己診断を行う。以上は、ユニットクラス１９０２から継承した操作の一部である。

操作getNumberOfJobsは、画像処理装置１１０全体で実行中のジョブ数を返す。操作getCurrentUserは、装置を利用中のユーザを表すオブジェクトを返す。以上は、装置クラス１９７０で定義された操作の一部である。

操作getElementByIdは、このオブジェクトの全体‐部分関係の子にあたるオブジェクト群の中からidで指定したIDを持つオブジェクトを検索してその参照を返す。操作getElementsByTagNameは、このオブジェクトの全体‐部分関係の子にあたるオブジェクト群の中からnameで指定した名前を持つオブジェクト群を検索してそれらの参照のリストを返す。以上は、ＤＯＭのNodeクラスから継承した操作の一例である。

プリンタ部クラス１９７２のインスタンスであるオブジェクトは、以下の特性を持つ。

属性serial，vender，model，version，firstChildは、deviceオブジェクトと同様である。属性isOnlineは、プリンタ部１１４がオンラインであるとき真値になる述語である。属性finisherは、このオブジェクトの全体‐部分の子にあたる排紙ユニットクラス１９０８のインスタンスを参照する。属性paperSupplyは、このユニットの全体‐部分の子にあたる給紙ユニットクラス１９０７のインスタンスを参照する。属性markingは、このユニットの全体‐部分の子にあたるマーキングクラス１９０５のインスタンスを参照する。以上の属性は、プリンタ部クラス１９７２で定義された属性の一部である。

操作diag，getElementById，getElementsByTagNameは、deviceオブジェクトと同様である。操作getNumberOfJobsは、プリンタ部１１４で実行中のジョブ数を返す。操作getTotalCounterは、プリンタ部１１４でプリントした積算プリント数を返す。操作getTonerは、プリンタ部１１４が保持するトナー残量を返す。操作setOnlineは、プリンタ部１１４をオンライン状態にする。操作setOfflineは、プリンタ部１１４をオフライン状態にする。

図１８は、組み込みＷｅｂブラウザに組み込まれたＪａｖａＳｃｒｉｐｔ（登録商標）インタプリタがスクリプトの動作環境として提供するクライアントサイドオブジェクトの全体‐部分階層構造の一例を示す図である。

クライアントサイドのＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクトの全体‐部分階層において、最上位に位置するのは、Windowオブジェクトである。ブラウザのドキュメントを表示するウィンドウ（フレーム）に対応するオブジェクトが、Windowオブジェクトである。クライアントサイドのオブジェクトは、すべてWindowオブジェクトから参照されている。Windowオブジェクトは、言語処理系のスコープチェーンの先頭につながれているグローバルオブジェクトである。Windowオブジェクトは、属性documentや属性locationを備えている。属性documentは、対応するウィンドウに関連付けられたDocumentオブジェクトを参照する。属性locationは、対応するウィンドウに関連付けられたLocationオブジェクトを参照する。Windowオブジェクトは、他にも、属性frames[ ]も持つ。属性frames[ ]を利用すれば、元のウィンドウを構成する各フレームに対応するWindowオブジェクトを参照できる。たとえば、属性documentは、現在のウィンドウのDocumentオブジェクトを参照し、frames[1].documentは、現在のウィンドウの２番目の子フレームのDocumentオブジェクトを参照する。現在のウィンドウまたはそのほかのWindowオブジェクトから参照されるオブジェクトが自分以外のオブジェクトを参照することもできる。たとえば、Documentオブジェクトのforms[ ]配列を利用すると、文書中に表示する複数のＨＴＭＬフォームに対応するFormオブジェクトを参照できる。これらのフォームのうち、どれか１つを参照するためには、self.document.forms[0]のように記述する。

本実施の形態のＷｅｂブラウザでは、このオブジェクト階層の中に装置オブジェクトモデルを位置づけている。Windowオブジェクトの属性deviceは、装置オブジェクトのインスタンス（図１７のdeviceオブジェクト）を参照している。

以上のように構成された画像処理装置１１０が実行する制御動作を説明する。

図１９および図２０は、Ｗｅｂブラウザによってサーバから取得される文書の一例を示す図である。

同図の文書は、ＪａｖａＳｃｒｉｐｔ（登録商標）のコードが埋め込まれたＨＴＭＬ文書である。この文書をＷｅｂブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Ｗｅｂブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成されて表示される。たとえば、図２１および図２２は、動的に適応した文書のＷｅｂブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。

図１９の行７では、deviceオブジェクトのgetCurrentUser操作によって現在装置を利用中のユーザオブジェクトを取得し、そのname属性を読み出している。この結果、装置を利用中のユーザの名前（表示例では「山田太郎」）を文書に挿入している。

行９では、deviceオブジェクトのmodel属性によって装置のモデル名を読み出し、それ（表示例では「ＭＦＰ３２００」）を文書に挿入している。

行１２〜行３３では、装置を構成するサブユニット毎にそれらの実際の装着状況に応じて、その固有の装置にとって有益な情報を選択的に挿入している。

行１３では、deviceオブジェクトからreaderオブジェクトをたどり、readerオブジェクトのmodel属性を読み出して、装置を構成するリーダ部のモデルが「Ｓ５００」と等しいか否かを判定している。もし等しければ、行１４でさらにreaderオブジェクトからfeederオブジェクトをたどり、そのmodel属性を読み出して、リーダ部１１３に装着された原稿給紙ユニットのモデルが「ＤＦ０３」と等しいか否かを判定している。もし等しければ、行１５〜行２１で、この特定の原稿給紙ユニットに固有の関連情報を文書に挿入している。また、挿入する情報には、さらに詳細な情報源へのリンクが埋め込まれているが、行１９と行２０で、このリンクのＵＲＬも、device.reader.modelによって読み出した原稿給紙ユニットのモデルに応じて最適なＵＲＬを動的に生成し、最適なページへと誘導している。表示例の装置は、このモデルのリーダ部で構成され、かつ原稿給紙ユニットが装着されているため、下取りキャンペーンを紹介する情報が挿入されている。

行２４〜行３２では、装置を構成するプリンタ部のモデルが「Ｐ９９００」である場合の処理を記述している。表示例の装置は、このモデルのプリンタ部で構成されないため、表示例ではこの部分の情報は挿入されていない。

図２０の行３５〜行５６では、サーバ側が把握している、リリースされたファームウェアの最新バージョンと、実際の装置に組み込まれているファームウェアのバージョンとを比較し、もし古いバージョンが組み込まれたままであればカスタマーエンジニアによるアップグレード作業の手配を推奨する情報を選択的に文書に挿入している。

行３５では、サブユニット毎にリリースされた最新ファームウェアのバージョンを格納するための配列latestsを生成している。

行３６〜行４１では、操作部ユニット、プリンタ部、リーダ部、ネットワークユニット、通信ユニットおよびＵＳＢユニットのそれぞれのユニットについて、最新バージョンを表すversion属性と表示用のラベルを表すlabel属性を格納したオブジェクトを生成し、配列latestsにオブジェクト名をキーにした連想配列として格納している。

行４２〜行５５では、配列latestsの全要素のそれぞれに関して繰り返すループを構成している。

行４２では、配列latestsのある要素のキーを変数unitで指し示している。

行４３では、device[unit]という連想配列表記によってdeviceオブジェクトの属性にアクセスしている。たとえば、unitの値が文字列‘operationPanel’とすると、device[unit]は、device[“operationPanel”]を意味する。ＪａｖａＳｃｒｉｐｔ（登録商標）では、これはドット表記したdevice.operationPanelと同じ意味である。したがって、deviceオブジェクトのoperationPanel属性（プロパティ）に対するアクセスを意味する。これはすなわち、装置オブジェクトを構成する操作部ユニットオブジェクトである。この行では、device[unit]、すなわちあるユニットのオブジェクトがそのシステムの実際の装置オブジェクトモデルにおいて、未定義でもnull値でもなく、かつ、device[unit].version、すなわちそのユニットのオブジェクトのバージョンがlatests[unit].version、すなわち行３６〜行４１で配列に格納したそのユニット用ファームウェアの最新バージョンよりも小さい値であるか否かを判定している。この条件を満たした場合は、そのユニットの稼働中のファームウェアがリリースされている最新版よりも古いことを意味し、この場合は、行４４〜行５４で、カスタマーエンジニアによるファームウェアのバージョンアップ（ＲＯＭ交換など）の申請を促す情報を文書に挿入する。挿入する情報の中には、mailto:疑似プロトコルによるＵＲＬを参照するアンカーが埋め込まれている。図２１の表示において、このアンカーは、「サポートセンターにemailでお申し込み」のハイパーテキストとして表示されている。ユーザがこのハイパーテキストをポイントすると、Ｗｅｂブラウザから電子メールクライアント機能が呼び出される。ＵＲＬには、宛先アドレスsupport@canon.jpに加えて、subjectとbodyが符号化されているため、電子メールクライアント機能に宛先アドレスと題名と本文の初期値が引き渡される。

図２３は、このようにして起動した電子メールクライアントの画面例である。図示例では、コンテンツ提供者が指定した宛先アドレスが設定されている。また、実際の装置オブジェクトから取得したモデル名と装置のシリアル番号を含む題名が設定されている。さらに、より新しいバージョンのファームウェアが存在するサブユニットに関して、実際の装置オブジェクトから取得したサブユニットのモデル名とそのユニットに現在組み込まれているファームウェアのバージョンとが本文に設定されている。

図２０に戻り、行５９〜行６７では、稼働中の組み込み装置のその時点での消耗品残量を確認して、もし残量が少なければ、消耗品の発注を促し、オンライン発注ページへのリンクを表示するためのデータを文書に挿入している。

行５９では、操作device.printer.getToner()によって、装置オブジェクトを構成するプリンタ部オブジェクトのgetToner()メソッドを呼び出すことで、トナー残量の割合を得ている。

行６０では、トナー残量が１０％未満であるか否かを判定し、１０％未満であれば文書への挿入を行う。

行６１では、文書に挿入するＵＲＬを生成しているが、ここで属性device.printer.modelを読み出してＵＲＬに埋め込むことによって、ユーザが利用しているモデルに適合したトナーのオンライン販売ページに直接リンクしたＵＲＬを生成することができる。

行６２および行６３では、トナーの残量が少ないことの注意を促し、適合するトナーのオンライン販売ページに誘導するハイパーテキストを含むメッセージを文書に挿入している。

トナー残量が１０％以上ある場合は、図２１の表示例のようにこのメッセージは文書に含まれず、１０％未満の場合は、図２２の表示例のようにこのメッセージが文書に挿入される。

行７１では、サーバ側が提供する最新マニュアルへのリンクを生成している。device.model属性の値を読み出し、これを埋め込んだＵＲＬを生成し参照しているため、ユーザがこのリンクをたどると、利用中の装置に適合したマニュアルに直接到達できる。

図２１は、動的に適応した文書のＷｅｂブラウザ上での表示例であり、Ｗｅｂブラウザの前記コンテンツ表示領域９０５上での表示例を示している。

コンテンツの文書に記述されたメッセージ５００１の中には、スクリプトによって装置オブジェクトモデルから取得した、画像処理装置１１０を現在利用中のユーザ名（山田太郎）を挿入している。

コンテンツの文書に記述されたメッセージ５００２の中には、スクリプトによって装置オブジェクトモデルから取得した、装置のモデル名（ＭＦＰ３２００）を挿入している。

パラグラフ５００３では、スクリプトによって装置オブジェクトモデルから取得した、リーダ部１１３のモデルと原稿給紙ユニットのモデルとが情報提供の条件に合致しているかどうかを判定した結果、合致していたために、パラグラフ５００３が文書に挿入されている。また、このパラグラフ５００３に含まれるアンカーのＵＲＬは、装置オブジェクトモデルから取得した、原稿給紙ユニットのモデル名を含んでいるため、下線のリンクをユーザが選択すると当該ユニットの下取りキャンペーンページに直接遷移できる。

パラグラフ５００４では、スクリプトによって、コンテンツに記述したサブユニット群の最新ファームウェアのバージョンと、装置オブジェクトモデルから取得した実際に稼働中のサブユニット群のファームウェアのバージョンとを比較し、アップブレード可能なサブユニットが存在したために、パラグラフ５００４が文書に挿入されている。また、このパラグラフ５００４に含まれるリンクは、メール送信を行うためのＵＲＬを含んでいる。ＵＲＬ中には、コンテンツに記述された宛先アドレスに加えて、装置オブジェクトモデルから取得した装置のモデル、シリアル番号、アップグレード作業対象のユニット名、現在利用中のファームウェアバージョンの各情報を符号化してあるため、ユーザが下線のリンクを選択すると自動的にサポートセンターに必要な情報を伝える電子メールを生成することができる。

リンク５００５は、サーバに置かれた最新マニュアルページへのリンクである。このアンカーのＵＲＬには、コンテンツに記述された最新マニュアルのパスとともに装置オブジェクトモデルから取得した装置のモデル名の情報が符号化されているため、下線のリンクをユーザが選択すると、当該組み込み装置専用のマニュアルページに直接遷移できる。

図２２は、動的に適応した文書のＷｅｂブラウザ上での別の表示例であり、Ｗｅｂブラウザのコンテンツ表示領域９０５上での表示例を示している。この表示は、図２１を表示した同じ組み込み装置において、異なるタイミングで同じコンテンツを取得し表示した例を示している。

パラグラフ５１０１では、スクリプトが装置オブジェクトモデルのトナー残量取得操作を呼び出して取得した、その時点におけるトナー残量が、コンテンツのスクリプトに定義された規定の値（１０％）未満であるか否かを判定し、その結果、規定値未満であったために文書に挿入されている。このパラグラフ５１０１のメッセージには、スクリプトが装置オブジェクトモデルのトナー残量取得操作を呼び出して得た、その時点におけるトナー残量の値（８％）も、埋め込んで表示している。

図２３は、スクリプト処理によって動的に生成したＵＲＬに応じて起動した電子メール送信機能の画面例であり、電子メール送信画面は、前記操作部１１２に表示される。

同図において、宛先アドレス５２０１には、コンテンツ提供者が指定した宛先アドレスが設定されている。題名５２０２には、実際の装置オブジェクトから取得したモデル名と装置のシリアル番号を含む題名が設定されている。本文５２０３には、より新しいバージョンのファームウェアが存在するサブユニットに関して、実際の装置オブジェクトから取得したサブユニットのモデル名とそのユニットに現在組み込まれているファームウェアのバージョンとが設定されている。

カスタマーエンジニアの出動を手配するために必要な情報が自動的に設定されているため、ユーザはこのまま電子メールを送信することもできるし、もし望むならメッセージを書き加えてから送信することもできる。

ボタン５２０４は、キャンセルボタンであり、送信を行わずに電子メール送信画面を閉じるときに使用する。

ボタン５２０５は、送信ボタンであり、電子メールの送信を行うときに使用する。

このように、本実施の形態の画像処理装置によれば、以下の効果が得られる。

すなわち、サービスを提供するサーバ側に単一のコンテンツを準備するだけで、システムの構成や状態に応じて適切な情報を選択的に提示する文書を提供することが可能となる。タイムリーな情報は、サーバ側コンテンツを更新し、ユーザが利用している固有の組み込み装置への適合は、ＪａｖａＳｃｒｉｐｔ（登録商標）のクライアントサイド処理によってＨＴＭＬの断片を生成してコンテンツ文書に挿入し、これらの組み合わせによって柔軟にきめの細かいサービスを提供することができる。たとえば、Ｗｅｂページコンテンツのパーソナライズ、装置の構成や動的な状態に応じた最適な提案に利用できる。また、動的に生成するＵＲＬに装置の構成や状態を反映することによって、情報提示やオンライン販売などのＷｅｂページの中からその装置にとって最適なページに直接遷移するためのリンクを表示するために利用できる（これまでは、必ずしも最適でない選択肢も並んだインデクス的ページへのリンクを表示することしかできず、ユーザにその中から最適な選択肢を選んでもらう手間がかかっていた）。また、ＵＲＬの生成によってサポートセンターへ送信する電子メールのひな形を提供するためにも利用できる。これらはすべて、たとえばＣＲＭ（Customer Relationship Management）のためにも有益である。

（第２の実施の形態）
次に、本実施の第２の形態に係る画像処理装置について説明する。

本実施の形態の画像処理装置は、上記第１の実施の形態の画像処理装置に対して、サーバから取得する文書の内容が異なるのみであるので、本実施の形態の画像処理装置を含むシステムのハードウェア構成およびソフトウェア構成は、すべて上記第１の実施の形態の画像処理装置を含むシステムのそれをそのまま使うことにする。

図２４〜図２６は、Ｗｅｂブラウザによってサーバから取得される文書の一例を示す図である。

同図の文書は、ＪａｖａＳｃｒｉｐｔ（登録商標）のコードが埋め込まれたＨＴＭＬ文書である。この文書をＷｅｂブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Ｗｅｂブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成されて表示される。図２７は、動的に適応した文書のＷｅｂブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。

図２４の行１８〜行２６では、オプションユニットである、排紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、排紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。排紙ユニットの装着状況は、装置オブジェクトモデルのdevice.printer.finisher属性に“null”以外の値がセットされている（つまりFinisherUnitクラスのオブジェクトを参照している）か否かによって判定している。なお、アンカーの内容は、そのユニット当該モデルの画像（ＨＴＭＬのＩＭＧ要素）によって表示している（図２７の領域５３０１）。未装着の場合は、半透明のユニットに「未装着」の文字を重ねた画像によって表示する。

行３１〜行３８では、同様に、オプションユニットである、原稿給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、原稿給紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。原稿給紙ユニットの装着状況は、装置オブジェクトモデルのdevice.reader.feeder属性に“null”以外の値がセットされている（つまりDocumentFeederUnitクラスのオブジェクトを参照している）か否かによって判定している。なお、アンカーの内容は、そのユニットの当該モデルの画像（ＨＴＭＬのＩＭＧ要素）によって表示している（図２７の領域５３０２）。未装着の場合は、半透明のユニットに「未装着」の文字を重ねた画像によって表示する。

図２５の行４３〜行５２では、同様に、オプションユニットである、給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、給紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。給紙ユニットの装着状況は、装置オブジェクトモデルのdevice.printer.paperSupply属性に“null”以外の値がセットされている（つまりPaperSupplyUnitクラスのオブジェクトを参照している）か否かによって判定している。なお、アンカーの内容は、そのユニットの当該モデルの画像（ＨＴＭＬのＩＭＧ要素）によって表示している。未装着の場合は半透明のユニットに「未装着」の文字を重ねた画像によって表示する（図２７の領域５３０５）。

行５９および行６０では、リーダ部１１３のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデルの画像によって表示している（図２７の領域５３０３）。

行６７および行６８では、プリンタ部１１４のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデルの画像によって表示している（図２７の領域５３０４）。

図２６の行７８および行７９では、リーダ部１１３のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデル名を含む箇条書きのテキストによって表示している（図２７の文字列５３０６）。

行８３〜行８６では、オプションユニットである、原稿給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示している。原稿給紙ユニットの装着状況は、装置オブジェクトモデルのdevice.reader.feeder属性に“null”以外の値がセットされている（つまりDocumentFeederUnitクラスのオブジェクトを参照している）か否かによって判定している。なお、アンカーの内容は、そのユニットの当該モデル名を含む箇条書きテキストによって表示している（図２７の文字列５３０７）。

行９０および行９１では、プリンタ部１１４のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデル名を含む箇条書きテキストによって表示している（図２７の文字列５３０８）。

行９５〜行９９では、オプションユニットである、給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデル名を含む箇条書きテキストによって表示する。図２７の表示例では、給紙ユニットが未装着であるため、このリンクの挿入は行われない。

行１０２〜行１０６では、オプションユニットである、排紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、排紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。排紙ユニットの装着状況は、装置オブジェクトモデルのdevice.printer.finisher属性に“null”以外の値がセットされている（つまりFinisherUnitクラスのオブジェクトを参照している）か否かによって判定している。なお、アンカーの内容は、そのユニット当該モデル名を含む箇条書きテキストによって表示している（図２７の文字列５３０９）。

図２７は、動的に適応したマニュアル文書のＷｅｂブラウザ上での表示例であり、Ｗｅｂブラウザのコンテンツ表示領域９０５上での表示例を示している。同図の説明は、図２３〜図２６の説明の中で併せて行っているので、省略する。

本実施の形態では、スクリプトのアルゴリズムによって、ユニットのモデルとオプションユニットの装着状況に応じて動的に文書の内容を切り替えるように構成したが、さらに動的な状態に応じた切り替えを行い、装置に発生しているエラーに応じて、そのエラーから回復するための手順を解説するマニュアルを表示することもできる。また、スクリプトのアルゴリズムによって、特定の装置のユーザによる利用パターンを、装置に記憶されている統計情報から解析し、その利用パターンにとって最適な「使いこなし」のガイドを表示するように構成することもできる。

本実施の形態の画像処理装置によれば、以下の効果が得られる。

すなわち、サービスを提供するサーバ側に単一のコンテンツを準備するだけで、システムを構成するユニットのモデルやオプションユニットの装着状態に応じて適切な情報を動的に提示する文書を提供することが可能となる。これにより、たとえば、組み込みブラウザによってブラウズしている、まさにその装置の状態にとって最適化した電子マニュアルなどを提供するために利用できる。

（第３の実施の形態）
次に、本実施の第３の形態に係る画像処理装置について説明する。

本実施の形態の画像処理装置は、前記第１の実施の形態の画像処理装置に対して、サーバから取得する文書の内容が異なるのみであるので、本実施の形態の画像処理装置を含むシステムのハードウェア構成およびソフトウェア構成は、すべて前記第１の実施の形態の画像処理装置を含むシステムのそれをそのまま使うことにする。

図２８および図２９は、Ｗｅｂブラウザによってサーバから取得される文書の一例を示す図である。

同図の文書は、ＪａｖａＳｃｒｉｐｔ（登録商標）のコードが埋め込まれたＨＴＭＬ文書である。この文書をＷｅｂブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Ｗｅｂブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成されて表示される。図３０は、動的に適応した文書のＷｅｂブラウザ上での表示例である。

また、スクリプトインタプリタにロードされたスクリプトには、Ｗｅｂブラウザ上に表示されている文書の要素に対するユーザの入力操作によって生起するＤＯＭイベントや、タイマーイベントなどに呼応するイベントハンドラスクリプトが含まれており、これらのイベントハンドラは、Ｗｅｂブラウザに文書が表示された後、各種のイベントに応じて実行される。イベントハンドラは、装置オブジェクトモデルに対する操作によって装置制御を行い、また、ＤＯＭに対する操作によってＨＴＭＬ文書の取得時に解釈され表示された文書の表示後の変更なども行う。

図３１および図３２は、文書取得時の表示完了後にあらためて動的に変更された文書のＷｅｂブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。

図２８の行５〜行２９では、関数diagを定義している。関数diagは、引数として各ユニットオブジェクトの参照unitを受け取り、そのユニットの自己診断コードを実行し、さらに、実行結果に基づいて既にＷｅｂブラウザに表示されている文書の編集を行う。

行６では、参照を与えられたunitオブジェクトにおいて定義された自己診断メソッドである操作diagを呼び出す（行５で定義しているdiag(unit)とは異なることに注意）。そして、診断結果として返される整数値をdiagResultに得ている。診断結果は“０”であれば正常であり、それ以外の数値はエラーコードを意味する。

行７では、ＤＯＭの操作によって、このＨＴＭＬ文書自身が持つ、diagDivというＩＤがつけられたＤＩＶ要素を検索し、その参照diagDivを得ている。

行８では、見つけたdiagDivに含まれる最初のＰ要素を検索し、その参照oldPを得ている。

行９では、新たにＰ要素を生成し、その参照pを得ている。

行１０では、行６で実行した診断の結果diagResultが正常であるか否かを判定し、正常であれば行１１および行１２を、異常であれば行１５〜行２６を実行する。

診断コードが正常に終了した場合、行１１では、「診断：正常です。」という文字列からなるＤＯＭのテキストノードを生成している。

行１２では、生成したテキストノードを、行９において生成したＰ要素の最初の子供として追加している。これにより、pのテキストに「診断：正常です。」の文字列が設定される。その後、行２８に進む。

一方、診断コードが異常となった場合、行１５では、診断結果のエラーコードdiagResultを埋め込んだ、障害サポートサイトのＵＲＬを構築する。

行１６では、診断エラーコードdiagResultを含み、異常を通告するメッセージの文字列からなるＤＯＭのテキストノードを生成している。もしエラーコードが“１９９”であれば、文字列は「診断：異常が検出されました。エラーコードは＃１９９です。より詳細な情報は」となる。

行１９では、生成したテキストノードを、行９において生成したＰ要素の最初の子供として追加している。

行２０では、新たにＡ要素を生成してその参照aを得ている。

行２１では、生成したＡ要素であるaにＨＲＥＦ属性を設定している。ＨＲＥＦ属性の値は、行１５で構築した障害サポートサイトのＵＲＬである。

行２２では、同じＵＲＬ文字列からなるＤＯＭのテキストノードを生成している。

行２３では、生成したテキストノードを、行２０で生成したＡ要素aの最初の子供として追加している。これによって、Ｗｅｂブラウザに表示されるリンクの、ユーザに見える文字列が、障害サポートサイトのＵＲＬとなる。

行２４では、ＨＲＥＦ属性とテキストノードを設定し終わったＡ要素aを、pの２番目の子供として追加している。

行２５では、「をご参照下さい。」という文字列からなるＤＯＭのテキストノードを生成している。

行２６では、生成したテキストノードを、pの３番目の子供として追加している。

行２８では、diagDivの最初のＰ要素を、これまで表示されていたoldPから新たに生成し構築したpに交換している。

関数diagは、図２９の行５９〜行７６のスクリプトから利用されている。

行５９では、device.printer.diagが未定義でも“null”でもないことを確認、すなわちプリンタ部の自己診断コードが登録されていることを確認している。登録されていれば、行６０では、「プリンタ」とラベルがつけられて、クリックイベントのイベントハンドラとして、プリンタ部オブジェクトを引数とした関数diagの呼び出しを登録したＦＯＲＭのボタンを、ＨＴＭＬ文書に挿入している。こうして、プリンタ部オブジェクトの自己診断コードを呼び出すためのボタンが表示される。

同様にして、行６２〜行６５で、もし自己診断コードが提供されていれば、排紙ユニットオブジェクトの自己診断を呼び出すためのボタンが表示される。

同様にして、行６６〜行６９で、もし自己診断コードが提供されていれば、給紙ユニットオブジェクトの自己診断を呼び出すためのボタンが表示される。

同様にして、行７０および行７１で、もし自己診断コードが提供されていれば、リーダ部オブジェクトの自己診断を呼び出すためのボタンが表示される。

同様にして、行７３〜行７６で、もし自己診断コードが提供されていれば、原稿給紙ユニットオブジェクトの自己診断を呼び出すためのボタンが表示される。

このスクリプトは、ＨＴＭＬ文書の取得直後の解釈時に実行されるため、ボタンは、Ｗｅｂブラウザに最初に表示されるページに表示される。ある特定の組み込み装置においてプリンタ部とリーダ部の診断コードが提供されている場合、図３０の表示例のように、プリンタとリーダのための各ボタン５４０１および５４０２が表示される。

診断コードの実行は、表示されたボタンをユーザがクリック（タッチパネルなのでタッチ）したタイミングで、イベントハンドラとして登録された関数diagによって実行される。たとえば、ユーザが「プリンタ」と書かれたボタン５４０１をタッチし、診断が終わり、異常が検出された場合、図３１の表示例の文５５０１のように、表示中の文書の一部を変更して（別の文書を再読み込みしているわけではないことに注意）、ユーザに異常を伝えるメッセージが標示される。

図２８の行３２〜行４１では、関数showPrinterStatusを定義している。

行３３および行３４では、この文書内のstatusDivというＩＤをつけられたＤＩＶ要素を検索し、その要素に含まれる最初のＰ要素の参照pを得ている。

行３５では、プリンタ部オブジェクトの要素isOnlineを読み出し、isOnlineの値が「真」の場合には、行３６でpの最初の子供（つまりテキストノード）のdata属性に「オンラインです。」の文字列を設定し、isOnlineの値が「偽」の場合には、行３９で「オフラインです。」の文字列を設定している。

関数showPrinterStatus()は、図２９の行５２のＨＴＭＬから利用されている。

行５２では、ＢＯＤＹ要素のｏｎＬｏａｄイベントに対するイベントハンドラとしてスクリプトを登録している。ｏｎＬｏａｄイベントハンドラは、文書を構成するすべてのデータのロード（展開、表示）が完了したタイミングで呼び出される。ハンドラでは、setIntervalによって、一定間隔で繰り返し生起するタイマーイベントハンドラの登録を行っている。この登録が行われると、10,000ミリ秒間隔で関数showPrinterStatusが呼び出されることになる。

Ｗｅｂブラウザが文書を表示した直後の状態では、図３０の表示例に示すように、statusDivには当初のＨＴＭＬ文書として記述されたまま（行８１）の文字列「状態取得中…」５４０３が表示されている。

約１０秒ほど経過すると、図３２の表示例の文字列５６０１のように、装置オブジェクトモデルから取得した装置の状態をユーザに提示し、その後この文書がブラウザに表示されている間は、１０秒間隔でその時点での状態表示を更新しつづける。

図２８の行４４〜行４８では、関数errorHandlerを定義している。関数errorHandlerは、引数eventを受け取る。

行４５および行４６では、この文書内のstatusDivというＩＤをつけられたＤＩＶ要素を検索し、その要素に含まれる最初のＰ要素の参照pを得ている。

行４７では、pの最初の子供（つまりテキストノード）のdata属性に、引数として受け取ったeventオブジェクトの属性unitと「:」とeventオブジェクトの属性messageをつないだ文字列を設定している。

関数errorHandlerは、行４９から利用されている。装置オブジェクトのエラーイベントを処理するためには、deviceオブジェクトのonerror属性にイベントハンドラ関数を登録すればよい。装置オブジェクトモデルは、装置制御とインターフェースして、装置制御に何らかのエラーが生じると、device.onerrorに登録された関数を呼び出す。その際、引数に渡すオブジェクトeventは、エラーに関連するユニットオブジェクトの参照unitやエラーを説明する文字列messageなどの属性を持つ。

図３０は、動的に適応した装置管理文書のＷｅｂブラウザ上での表示例であり、Ｗｅｂブラウザのコンテンツ表示領域９０５上での表示例を示している。

図３１は、文書取得時の表示完了後にあらためて動的に変更した装置管理文書のＷｅｂブラウザ上での表示例であり、Ｗｅｂブラウザのコンテンツ表示領域９０５上での表示例を示している。

図３２は、文書取得時の表示完了後にあらためて動的に変更した装置管理文書のＷｅｂブラウザ上での他の表示例であり、Ｗｅｂブラウザのコンテンツ表示領域９０５上での表示例を示している。

本実施の形態の画像処理装置によれば、以下の効果が得られる。

すなわち、スクリプトがＤＯＭを操作することで、文書解析時の挿入だけでなく、さらに動的な文書の編集ができる。

装置オブジェクトモデルのインターフェースを介して、スクリプトから装置やジョブを制御できる。

ＤＯＭイベントに呼応して装置オブジェクトモデルを操作するイベントハンドラを登録できる。ユーザからの入力やタイマーなどのイベントに応じて装置制御にアクセスすることができる。

装置オブジェクトモデルからのイベントを、ＤＯＭイベントを処理するのと同様にハンドリングできる。

ＨＴＭＬ文書に組み込まれたスクリプトによってＤＯＭと装置オブジェクトモデルに対する操作を組み合わせることで、装置制御を行うユーザインターフェースをＨＴＭＬとスクリプトにより記述することができる。ＨＴＭＬのユーザインターフェース記述言語としての側面をサーバ側で動作するＷｅｂアプリケーションのユーザインターフェースだけでなく、クライアントサイドの装置サービスのユーザインターフェースを提供するためにも利用できる。ユーザインターフェース記述は、サーバ側のコンテンツとして準備し、装置のブラウザからの取得要求に応えて取得されるため、サービス提供者側で最新のコンテンツを提供できる。

これにより、たとえば、カスタマーエンジニアやユーザによる組み込み装置のメンテナンスを助けるために有効である。

（第４の実施の形態）
次に、本実施の第４の形態に係る画像処理装置について説明する。

本実施の形態の画像処理装置は、前記第１の実施の形態の画像処理装置に対して、サーバから取得する文書の内容が異なるのみであるので、本実施の形態の画像処理装置を含むシステムのハードウェア構成およびソフトウェア構成は、すべて前記第１の実施の形態の画像処理装置を含むシステムのそれをそのまま使うことにする。

図３３および図３４は、Ｗｅｂブラウザによってサーバから取得される文書の一例を示す図である。

同図の文書は、ＪａｖａＳｃｒｉｐｔ（登録商標）のコードが埋め込まれたＨＴＭＬ文書である。この文書をＷｅｂブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Ｗｅｂブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成され表示される。

また、スクリプトインタプリタにロードされたスクリプトには、Ｗｅｂブラウザ上に表示されている文書の要素に対するユーザの入力操作によって生起するＤＯＭイベントやタイマーイベントなどに呼応するイベントハンドラスクリプトが含まれており、これらのイベントハンドラは、Ｗｅｂブラウザに文書が表示された後で、各種のイベントに応じて実行される。イベントハンドラは装置オブジェクトモデルに対する操作によって装置制御を行い、また、ＤＯＭに対する操作によってＨＴＭＬ文書の取得時に解釈されて表示された文書の表示後の変更なども行う。

図３５は、本文書のＷｅｂブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。

図３３の行５〜行７では、関数createCounterReport()を定義している。

行６では、プリンタ部１１４が積算するプリントトータルカウンタの現在値を取得するために、device.printer.getTotalCounter()を呼び出し、それを、この文書に含まれるＦＯＲＭのテキスト入力要素counterに書き込む。テキスト入力要素counterは、図３４の行３１に記述されている。

図３３の行８〜行１０では、関数reportLog()を定義している。この関数は、引数messageを受け取る。

行９では、引数に渡されたmessageを、この文書に含まれるＦＯＲＭのテキスト領域要素logに追記して改行する。テキスト領域要素logは、図３４の行３６に記述されている。

図３３の行１１〜行１９では、関数createLogReport()を定義している。

行１２では、テキスト領域要素logの内容をクリアする。

行１３では、ＤＯＭと同様のＡＰＩを用いて装置オブジェクトモデルにアクセスすることで、ログリストクラス１９５９のオブジェクトを検索する。ログリストオブジェクトは複数存在し得るが、ここでは１番目のログリストオブジェクトへの参照をlogとして得る。

行１４では、ＤＯＭと同様のＡＰＩを用いて装置オブジェクトモデルにアクセスすることで、ログリストオブジェクトlogの全体‐部分関係の子にあたるノードの中からタグ名が“record” であるオブジェクト群を検索してそのリストへの参照をrecordsとして得る。

行１５〜行２１では、ループを構成し、recordsに含まれる各オブジェクトに対して、以下の処理を繰り返す。すなわち、行１６では、recordsに含まれる１つのオブジェクトを選択してrecordとして参照し、行１７と行１８では、ＤＯＭのＡＰＩであるrecord.getAttribute()によって、このレコードオブジェクトが持つＤＯＭ属性を調べる。もし属性facilityの値が “system” であり、かつ、属性levelの値が “notice” であれば、行１９で、このオブジェクトレコードの属性dateの値と、「：」と、このオブジェクトレコードの最初の子のdata属性とを結合した文字列を構築する。そして引数に構築した文字列を渡して関数reportLog()を呼び出す。

関数createCounterReport()とcreateLogReport()は、図３４の行２５と行４２のＨＴＭＬから利用されている。

行２５では、ＢＯＤＹ要素のｏｎＬｏａｄイベントに対するイベントハンドラとしてスクリプトを登録している。ｏｎＬｏａｄイベントハンドラは、文書を構成するすべてのデータのロード（展開、表示）が完了したタイミングで呼び出される。ハンドラでは、まずcreateCounterReport()の呼び出しを行い、ついでcreateLogReport()を呼び出している。また、行４２では、「更新」とラベル付けされたボタン入力要素updateButtonのｏｎＣｌｉｃｋイベントに呼応するイベントハンドラとしてスクリプトを登録している。こちらのハンドラもまったく同様に、まずcreateCounterReport()の呼び出しを行い、ついでcreateLogReport()を呼び出している。

Ｗｅｂブラウザが文書を表示した直後の状態では、ｏｎＬｏａｄイベントハンドラスクリプトの処理よって、プリンタ部１１４のトータルカウント値がテキスト入力要素counter（「カウンタ」）に入力され、system関連でかつnoticeレベルのログレコードオブジェクトのタイムスタンプとメッセージがテキスト領域要素log（「ログ」）に入力されている。したがって、図３６のような表示が得られる。その後、ユーザが「更新」ボタンを押すたびに、そのボタンのonClickイベントハンドラによってカウンタとログの各フィールドの内容表示が更新される。

この文書例では、さらに行４３において、ＨＴＭＬのＦＯＲＭを送信するためのｓｕｂｍｉｔ型の入力要素を記述している。この入力要素は、図３５の表示例において「送信」とラベル付けされたボタンに対応する。ユーザが「送信」ボタンを押すと、「カウンタ」ならびに「ログ」の内容がサーバ側にサブミットされる。すなわち、スクリプトが装置オブジェクトモデルにアクセスして得た結果を、ＦＯＲＭを介してサーバ側に引き渡すことができる。これにより、サーバサイド処理とクライアントサイド処理を連携させることが可能となり、ＤＯＭと装置オブジェクトモデルを組み合わせたスクリプトによる課題解決の機会が広がる。

ただし、その一方で、ユーザは組み込み装置内部に保持されている情報がやみくもに外部ネットワークに流出することを恐れる場合がある。さらに、ユーザがサブミットボタンを押さなかったとしても、スクリプトからボタンが押されたのと同じ状態を作り出す方法も存在する。したがって、組み込み装置のユーザ環境や運用形態によってはプライバシーの問題が一段と危惧される可能性がある。

そこで、スクリプトが装置オブジェクトモデルのいずれかに一度でもアクセスした場合、そのスクリプトが埋め込まれた文書に含まれるＦＯＲＭからのサブミットが指示されたときに、本当に送信処理を実行してもよいかユーザに確認する。図３６は、この確認ダイアログを示す。ＦＯＲＭのサブミット指示は、ＨＴＭＬ文書のＤＯＭイベントであり、ＤＯＭ管理部によって捕捉できる。また、スクリプトがアクセスする装置オブジェクトモデルも、ＤＯＭ管理部に組み込まれて管理されるので、ＤＯＭ管理部が、文書に含まれるスクリプトから装置オブジェクトモデルへのアクセスを監視できる。何らかのアクセスがなされると、ＤＯＭ管理部は、その文書がダーティであるものとマークする。ＤＯＭ管理部は、ＦＯＲＭのサブミット指示を捕捉すると、そのＦＯＲＭを含む文書がダーティであるものとマークされているか否かを判定し、ダーティであればサブミット指示の処理を中止させたり、ユーザに許可の確認を求めたりする。

図３５は、動的な装置レポート文書のＷｅｂブラウザ上での表示例であり、Ｗｅｂブラウザのコンテンツ表示領域９０５上に、図３３および図３４の文書を表示したものである。この文書の表示は、装置オブジェクトモデルのアクセスを反映して動的に適応され、また装置オブジェクトモデルに対する操作を起動するユーザインターフェース（「更新」ボタン）と、その結果をフィードバックするユーザインターフェース（「カウンタ」および「ログ」フィールド）を持ち、さらに、装置オブジェクトモデルのアクセス結果をＦＯＲＭのサブミット（「送信」ボタン）により送信する。

図３６は、装置オブジェクトモデルへのアクセスを行った文書からＦＯＲＭのサブミットを試みた場合に、ユーザにその許可を確認するために表示された確認ポップアップウィンドウの一例を示す図である。

本実施の形態では、スクリプトが装置オブジェクトモデルのいずれかに一度でもアクセスした場合、そのスクリプトが埋め込まれた文書に含まれるＦＯＲＭからのサブミットの許可をユーザに確認するように構成したが、この制限がきつすぎる場合、装置オブジェクトモデルのいくつかだけを選択的に監視の対象とするように構成することもできる。また、装置オブジェクトモデルを構成するオブジェクトたちが備える特性のうち、特定のメソッドの呼び出しや特定のプロパティのアクセスを監視して、これらが行われなかった文書からのＦＯＲＭのサブミットを許可する（つまり、ユーザに確認を求めない）ように構成してもよい。

また、許可の確認は、本実施の形態では、サブミットの度に行うように構成したが、あらかじめ許可または禁止を固定的に設定できるように構成してもよい。また、文書の獲得元ＵＲＬやＦＯＲＭの送信先ＵＲＬなどに基づくルールをあらかじめ設定しておき、その制約に基づいて許可または禁止を自動的に判断するように構成してもよい。

本実施の形態の画像処理装置によれば、以下の効果が得られる。

すなわち、ＤＯＭを扱うのと同様に、装置オブジェクトモデルを扱うことができる。どちらもテキストベースであり、また、一般のＷｅｂデザインを行う制作者は、スクリプトによるＤＯＭの操作には慣れ親しんでいるため、組み込み装置と連携するコンテンツを手軽に制作できる。

装置オブジェクトモデルの動的なノード、特に、たとえばログのレコードや複数装着可能な同一種類のオプションユニットなど、構造的な柔軟性も要するオブジェクトの集合をＤＯＭと同様の動的な木構造として探索・操作できる。

（第５の実施の形態）
次に、本実施の第５の形態に係る組み込み装置を適用した画像処理装置について説明する。

本実施の形態の画像処理装置を含む画像処理システムのハードウェア構成およびソフトウェア構成は、前記第１の実施の形態の画像処理装置を含む画像処理システムのハードウェア構成およびソフトウェア構成と一部異なるのみであるので、前記第１の実施の形態の画像処理装置を含む画像処理システムのハードウェア構成およびソフトウェア構成を一部変更および追加して用いることにする。そして、以下では、その差異についてのみ説明する。

図３７は、ＨＤＤ３０４の論理的な使用方法を示した図である。

本実施の形態においては、使用用途に応じて、ハードディスクの記憶領域をテンポラリ領域７０１とボックス領域７０２に論理的に分ける。テンポラリ領域７０１は、画像データの出力順序を変えたり、複数部出力においても一回のスキャンで出力したりできるようにするために、ＰＤＬの展開データやスキャナからの画像データを一時的に記憶する記憶領域である。ボックス領域７０２はボックス機能を使用するための記憶領域であり、領域７０３〜７０７のように、登録された数の小さな記憶領域に分割されている。各ボックスにはボックス名を付けることができる。ユーザはボックスを指定することで、ＰＤＬジョブやスキャンジョブを各ボックス内の文書として格納することができる。また、複数の文書をまとめて管理するためのフォルダを作ることもできる。さらに、ボックスに格納されている文書やフォルダを閲覧したり、プリントや送信したりすることもできる。

ボックス７０３〜７０７は、他の装置内資源と同様に、所有権を持つユーザやグループが割り当てられている。また、オーナであるユーザ（以下、「ユーザｕ」と言う）、所有するグループに所属するユーザ（以下、「ユーザｇ」と言う）、および、それらに属さない他のユーザ（以下、「ユーザｏ」と言う）の、三種類のユーザの各々に対して、それぞれ読み出し、書き込み、および実行の許可として、アクセス権が設定できる。フォルダおよび文書にも同様に、オーナとグループが割り当てられ、アクセス権を設定することができる。

図３８は、資源の一例として、文書資源インスタンスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。

ユーザが資源情報の参照または設定を指示すると、ＬＣＤ表示部５０１に同図のグラフィカルユーザインターフェース（ＧＵＩ）が表示される。

同図において、インスタンスフィールドは、現在選択している資源のインスタンスを示している。「技術調査報告書０１１０」は、当該文書資源のインスタンスにつけられた識別子、すなわち文書名である。

クラスフィールドは、現在選択している資源のクラスを示している。「文書」は当該資源が文書クラスのインスタンスであることを示している。

階層表示ボタンは、現在選択している資源のインスタンスとクラスの関係を階層表示するためのボタンである。詳細は後述する。

所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。

アクセス権設定領域は、現在選択している資源のアクセス権の設定を参照または設定するための領域である。本領域は、テーブルを表現しており、各行は、それぞれ、当該資源のインスタンスのオーナへの許可、グループへの許可、および、他者への許可の各状態を示している。各列は、それぞれ、読み出し、書き込み、および、実行の各許可状態を示している。行と列の交わった各フィールドが、当該資源のそれぞれ対応する属性の値を示している。

この例に限らず、装置オブジェクトモデルを構成するすべてのオブジェクトに関して、読み出し権限がある場合のみスクリプトからの属性の読み出しが許可され、書き込み権限がある場合のみスクリプトへの属性の変更が許可され、実行権限がある場合のみスクリプトからの操作の呼び出しが許可される。

さらに、各属性は資源毎にそれぞれ定義された意味を持つ。文書資源の読み出し許可は、当該文書を閲覧、プリント、送信することが可能であることを示す。文書資源の書き込み許可は、当該文書を編集して、書き換えたり、削除したりすることが可能であることを示す。文書資源の実行許可は、その文書を対象とするプリントや送信などの処理がジョブ記述形式のジョブスクリプトとして記憶され、その文書に対応づけられている場合に、ジョブスクリプトを実行することが可能であることを示す。

キャンセルボタンは、変更可能な値を変更していたとしても、その変更を無効にして、本ＧＵＩを閉じるためのボタンである。ＯＫボタンは、変更可能な値を変更していた場合に、その変更を有効にして、本ＧＵＩを閉じるためのボタンである。

当該文書を所有するユーザは、本ＧＵＩを用いることで、当該文書を所有するグループを自らが所属するグループの中から設定でき、また、オーナ、グループ、および、他者のそれぞれに対して適切な許可を設定できる。また、管理者設定に対する書き込み権限を持つユーザ（不図示の管理者設定資源クラスの属性には、adminグループのメンバに対する書き込み権限が与えられている）は、すべての属性を変更可能であるので、当該文書を所有するオーナの設定も変更できる。したがって、所望のアクセス制御を行うことができる。本実施の形態では、オーナは、当該文書に対するすべての操作が可能であり、オーナが所属するグループrd（組織の研究開発部門）のメンバに対しては、読み出し操作のみを許可し、それ以外のユーザに対しては、読み出しも含むすべての操作を禁じている。

なお、文書資源と関連する資源に、フォルダクラスとボックスクラスがある。フォルダは、複数の文書および複数の他のフォルダをコンテンツとして内包可能なコンテナであり、ボックスは、トップレベルのフォルダである。フォルダおよびボックスにおける許可は、読み出しがコンテナに内包されるコンテンツのリスト表示の許可を表し、書き込みがコンテナへのコンテンツの追加および削除の許可を表し、実行はコンテナ毎に登録可能なコンテンツに対するバッチ処理の実行の許可を表す。

図３９は、資源の他の一例として、カラーコピー機能資源インスタンスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。同図中、図３８と同様の構成については、説明を省略する。

図３９において、インスタンスフィールドは、現在選択している資源のインスタンスを示している。「＜無名インスタンス＞」は、当該カラーコピー機能資源のインスタンスにつけられた識別子、すなわち機能名である。本実施の形態では、カラーコピー機能クラスのインスタンスには、装置が自動的に生成した単一のインスタンスしか存在しないため、特定のインスタンス名を持たない、無名のインスタンスとなっている。

クラスフィールドは、現在選択している資源のクラスを示している。「カラーコピー」は、当該資源がカラーコピークラスのインスタンスであることを示している。

階層表示ボタンは、現在選択している資源のインスタンスとクラスの関係を階層表示するためのボタンである。詳細は後述する。

所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。

アクセス権設定領域が示す各属性は、資源毎にそれぞれ定義された意味を持つ。カラーコピー機能資源におけるセマンティクスは、スーパークラスである機能資源によって定義されている。機能資源の読み出し許可は、当該機能の状態をモニタリングすることが可能であることを示す。機能資源の書き込み許可は、当該機能の動作モードをシステムレベルで制御するための特殊設定を変更可能であることを示す。機能資源の実行許可は、その機能のジョブを起動可能であることを示す。

本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本ＧＵＩを用いることで、当該機能に対する許可を変更可能である。グループはsales（組織の販売部門）であり、このグループに所属するメンバだけにカラーコピー機能の利用が許可され、それ以外のユーザに対しては禁止されている。

図４０は、資源間の継承関係を表示し、カラーコピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。

ユーザが図３９の階層表示ボタンを押下すると、ＬＣＤ表示部５０１に図４０のＧＵＩが表示される。図４０中、図３９と同様の構成については、説明を省略する。

図４０において、最上段の領域は階層表示領域である。本階層表示領域には、抽象‐具体関係に基づく継承関係が、図１５と同様な階層表示によって表示されている。継承関係の表示において、それぞれの箱は資源のクラスまたはインスタンスを表現している。ユーザが操作部１１２上でいずれかの箱の領域を押下すると、そのクラスまたはインスタンスを選択することができる。背景が斜線の施された矩形で囲まれたクラスまたはインスタンスが、現在選択されている資源のクラスまたはインスタンスを示している。選択を変更すると、本ＧＵＩの以下の領域は、選択されたクラスまたはインスタンスに関する表示に切り替わる。図示例では、カラーコピークラスが選択されている。

所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。

アクセス権設定領域が示す各属性は、資源毎にそれぞれ定義された意味を持つ。カラーコピー機能資源におけるセマンティクスは、スーパークラスである機能資源によって定義されている。機能資源の読み出し許可は当該機能の状態をモニタリングすることが可能であることを示す。機能資源の書き込み許可は当該機能の動作モードをシステムレベルで制御するための特殊設定を変更可能であることを示す。機能資源の実行許可は、その機能のジョブを起動可能であることを示す。

本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本ＧＵＩを用いることで、当該機能に対する許可を変更可能である。グループはsales（組織の販売部門）であり、このグループに所属するメンバだけにカラーコピー機能の利用が許可され、それ以外のユーザに対しては禁止されている。

図４１は、資源間の継承関係を表示し、コピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。

ユーザが図４０の階層表示領域中でコピー機能クラスを表現する箱を押下すると、ＬＣＤ表示部５０１に図４１のＧＵＩが表示される。図４１中、図４０と同様の構成については説明を省略する。

図４１において、最上段の領域は階層表示領域である。図示例では、コピー機能クラスが選択されている。コピー機能クラスは、カラーコピー機能と白黒コピー機能を抽象化したスーパークラスであり、サブクラスたちに共通するデフォルトの属性値を継承するために用いられる。

本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本ＧＵＩを用いることで、当該機能に対する許可を変更可能である。グループはuser（すべてのユーザ）であり、装置にユーザアカウントを持つすべてのユーザに対してコピー機能の利用が許可され、それ以外のユーザ、すなわちguestユーザに対しては禁止されている。

図４２は、資源間の継承関係を表示し、白黒コピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。

ユーザが図４１の階層表示領域中で白黒コピー機能クラスを表現する箱を押下すると、ＬＣＤ表示部５０１に図４２のグラフィカルユーザインターフェース（ＧＵＩ）が表示される。図４２中、図４１と同様の構成については説明を省略する。

図４２において、最上段の領域は階層表示領域である。図示例では、白黒コピー機能クラスが選択されている。白黒コピー機能クラスは、コピー機能クラスを特殊化したサブクラスであり、スーパークラスであるコピー機能クラスからデフォルトの属性値を継承する。

本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本ＧＵＩを用いることで、当該機能に対する許可を変更可能である。グループは未設定であり、スーパークラスのコピー機能クラスからuser（すべてのユーザ）を継承する。

本アクセス権設定領域において、すべての許可属性は未設定である。したがって、スーパークラスのコピー機能クラスから各々に対応する許可属性値を継承する。

図４３は、資源間の集約関係を表示し、プリンタ部資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。

ＬＣＤ表示部５０１に同図のＧＵＩが表示される。同図中、図４０などと同様の構成については、説明を省略する。

図４３において、最上段の領域は、階層表示領域である。本階層表示領域には、全体‐部分関係に基づく集約関係が、図１６と同様な階層表示によって表示されている。集約関係の表示において、それぞれの箱は、資源のクラスまたはインスタンスを表現している。ユーザが操作部上でいずれかの箱の領域を押下すると、そのクラスまたはインスタンスを選択することができる。背景が斜線の施された矩形で囲まれたクラスまたはインスタンスが、現在選択されている資源のクラスまたはインスタンスを示している。選択を変更すると、本ＧＵＩの以下の領域は、選択されたクラスまたはインスタンスに関する表示に切り替わる。図示例では、プリンタ部が選択されている。

所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。

アクセス権設定領域が示す各属性は、資源毎にそれぞれ定義された意味を持つ。本実施の形態におけるプリンタ部１９７２は、その部分ユニットである、排紙ユニット１９０７、マーキングユニット１９０５および排紙ユニット１９０８をひとまとめに扱うためのユニットにすぎず、実際には、読み出し、書き込みまたは実行のいずれのアクセスも受けない。しかし、プリンタ部資源は、アクセス権設定属性を保持し、これを参照および設定可能である。本実施の形態では、プリンタ部の属性値を、その部分ユニットたちの既定の属性値として用いる。したがって、全体‐部分関係の子にあたる複数の部分ユニットの属性値を未設定にしておけば、それらの部分ユニットの未設定属性が、全体ユニットの対応する属性に連動する。

図４４は、資源間の集約関係を表示し、排紙ユニット資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。同図中、図４３と同様の構成については、説明は省略する。

図４４では、排紙ユニットが選択されている。排紙ユニット１９０８は、プリンタ部１９７２の部分ユニットである。

同図において、グループおよびアクセス権の各属性は、未設定であるため、プリンタ部資源の対応する属性が設定されているものとして扱っている。

図４５は、アクセス権違反エラー表示の一例を示す図である。

ユーザが行った処理がアクセス権の不足によって失敗したとき、ＬＣＤ表示部５０１に同図のＧＵＩが表示される。ＧＵＩのメッセージは、処理に必要な権限が不足していることをユーザに伝えるためのものである。また、メッセージは、失敗の原因となった資源とその資源に対して必要だった許可を表示している。ユーザが詳細ボタンを押下すると、エラーに関する情報をさらに詳しく表示する。詳細表示として、失敗との原因となった資源の情報（たとえば、図３９）を表示することもできる。ユーザがＯＫボタンを押下すると、本ＧＵＩが閉じる。

本実施の形態では、全体クラスとその部分クラス間の集約関係を表現する階層構造を保持し、各資源のアクセス権を示す属性に関して、全体クラスが部分クラスの属性の既定値を提供するように構成した。このため、部分クラスにおいて未設定の属性値を全体クラスから供給できるので、複数の部分的なクラスを持つ資源群に関して、それらを内包するクラスで一度属性値を設定するだけで各々の部分的な資源に対して共通のデフォルトのアクセス権を簡易に設定できる。また、必要に応じ、より部分的な資源（および、もしあればその部分クラス）に対して、共通のデフォルトとは異なる、特定のアクセス権を設定することもできる。

各資源のクラス間の全体‐部分の集約関係を階層的に表示するＧＵＩを備え、さらに、クラスの集約関係を参照しながら、各クラスおよびインスタンスのアクセス権情報を参照および設定するためのＧＵＩを備えた。このため、ユーザは各種資源間の集約関係をわかりやすく把握でき、把握した集約関係に基づき適切なアクセス権の設定を行うことが容易にできる。

なお、上記各実施の形態では、ＤＯＭは、ＨＴＭＬ文書のＤＯＭだけを取り上げて説明したが、ＸＨＴＭＬなど他のマークアップ言語によって記述された文書一般に対して本発明を適用可能である。たとえば、スクリプトからＳＶＧのＤＯＭを操作することによって、ＨＴＭＬだけから構成される文書よりもよりグラフィカルにリッチなユーザインターフェースと装置オブジェクトモデルの操作とを組み合わせることもできる。

また、ブラウザとサーバ間のプロトコルは、本実施の形態では、ＨＴＴＰを用いて説明したが、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）はもちろんのこと、今後も含めてＷｅｂ技術において一般に用いられるプロトコルであればどのプロトコルを利用してもよい。

さらに、本実施の形態では、スクリプトの実行に伴う処理の権限を、Ｗｅｂブラウザを利用中のユーザに基づいて決定したが、ユーザによらず、スクリプト用のアクセス権を一意的に決定したり、スクリプトに付加された署名などにより識別されるスクリプト提供者に基づいてアクセス権を決定したりするように構成してもよい。

また、本実施の形態では、オブジェクト毎にアクセス権限を設定したが、クラスに含まれる個々の操作毎に権限を設定するように構成してもよい。

なお、上述した各実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、たとえば、フレキシブルディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。また、通信ネットワークを介してサーバコンピュータからプログラムコードが供給されるようにしてもよい。

また、コンピュータが読出したプログラムコードを実行することにより、上述した各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって上述した各実施の形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって上述した各実施の形態の機能が実現される場合も含まれることは言うまでもない。

本発明の第１の実施の形態に係る組み込み装置を適用した画像処理装置を含む画像処理システムの全体構成を示すブロック図である。 図１の画像処理装置のソフトウェア構成を示すブロック図である。 図１の画像処理装置の詳細なハードウェア構成を示すブロック図である。 図１の画像処理装置の外観を示す図である。 図４中の操作部の詳細な外観を示す図である。 図５の操作部の詳細な機能構成を示すブロック図である。 図１の画像処理装置に組み込まれたアプリケーションの動作を説明するためのネットワーク構成の一例を示すブロック図である。 図２中のＷｅｂブラウザモジュールのソフトウェア構成を示すブロック図である。 図５中のＬＣＤ表示部に表示されるＷｅｂブラウザの画面構成の一例を示す図である。 ＨＴＴＰプロトコルによる要求と応答の処理の流れの一例を示すシーケンス図である。 サーバサイド処理とクライアントサイド処理の流れの一例を示す図である。 図１の画像処理装置を利用するユーザのユーザアカウントを管理するデータ構造の一例を示す図である。 図１の画像処理装置を利用するユーザのグループを管理するデータ構造の一例を示す図である。 図１の画像処理装置を構成する各種資源を抽象化して表現したリソースクラスのデータ構造の一例を示す模式図である。 図１の画像処理装置を構成する各種資源間の継承関係を表すデータ構造の一例を示すクラス図である。 図１の画像処理装置が扱う各種資源間の集約関係を表すデータ構造の一例を示すクラス図である。 装置オブジェクトモデルのインスタンスを構成するオブジェクトの一部を示す図である。 組み込みＷｅｂブラウザに組み込まれたＪａｖａＳｃｒｉｐｔ（登録商標 ）インタプリタがスクリプトの動作環境として提供するクライアントサイドオブジェクトの全体‐部分階層構造の一例を示す図である。 Ｗｅｂブラウザによってサーバから取得される文書の一例を示す図である。 図１９の続きの文書を示す図である。 動的に適応した文書のＷｅｂブラウザ上での表示例である。 動的に適応した文書のＷｅｂブラウザ上での別の表示例である。 スクリプト処理によって動的に生成したＵＲＬに応じて起動した電子メール送信機能の画面例である。 本発明の第２の実施の形態に係る組み込み装置を適用した画像処理装置のＷｅｂブラウザによってサーバから取得される文書の一例を示す図である。 図２４の続きの文書を示す図である。 図２５の続きの文書例を示す図である。 動的に適応したマニュアル文書のＷｅｂブラウザ上での表示例である。 本発明の第３の実施の形態に係る組み込み装置を適用した画像処理装置のＷｅｂブラウザによってサーバから取得される文書の一例を示す図である。 図２８の続きの文書を示す図である。 動的に適応した装置管理文書のＷｅｂブラウザ上での表示例である。 文書取得時の表示完了後にあらためて動的に変更された文書のＷｅｂブラウザ上での表示例である。 文書取得時の表示完了後にあらためて動的に変更された文書のＷｅｂブラウザ上での他の表示例である。 本発明の第４の実施の形態に係る組み込み装置を適用した画像処理装置のＷｅｂブラウザによってサーバから取得される文書の一例を示す図である。 図３３の続きの文書例を示す図である。 動的な装置レポート文書のＷｅｂブラウザ上での表示例である。 動的に適応した文書のＷｅｂブラウザ上での別の表示例である。 ＨＤＤの論理的な使用方法を示した図である。 資源の一例として、文書資源インスタンスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 資源の他の一例として、カラーコピー機能資源インスタンスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 資源間の継承関係を表示し、カラーコピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 資源間の継承関係を表示し、コピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 資源間の継承関係を表示し、白黒コピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 資源間の集約関係を表示し、プリンタ部資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 資源間の集約関係を表示し、排紙ユニット資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。 アクセス権違反エラー表示の一例を示す図である。

符号の説明

１１０ 画像処理装置
１２０ 画像処理装置
１３０ 画像処理装置
１０１ デスクトップコンピュータ
１００ ユーザサイトのローカルエリアネットワーク
１５５ サーバコンピュータ
１５４ アプリケーションサービスプロバイダサイトのローカルエリアネットワーク
１５１ ユーザサイト
１５２ 広域ネットワーク
１５３ アプリケーションサービスプロバイダサイト

Claims (13)

1. 画像入力手段あるいは画像出力手段の少なくともいずれかを備える画像処理装置であって、
   少なくともマークアップ言語によって記述された文書データであって、その中にスクリプトまたはスクリプトを参照する情報の埋め込まれた文書データを含むＷｅｂコンテンツデータをロードし、該ロードされたＷｅｂコンテンツデータに基づいて画面情報を生成し、該画面情報を表示手段に表示するブラウザ手段と、
   前記画像入力手段あるいは前記画像出力手段のいずれかを用いた画像処理の実行を制御する制御手段と、
   前記制御手段が前記画像処理の実行を制御するのに伴い生成される履歴情報を記憶する記憶手段と、
   前記ロードされたＷｅｂコンテンツデータに含まれる文書データを解釈し、該文書データに埋め込まれたスクリプトまたはスクリプトを参照する情報によって特定されるスクリプトを処理するスクリプト処理手段と、
   前記スクリプト処理手段による前記スクリプトの処理に基づいて、前記記憶手段に記憶された情報を取得する取得手段と
   を有し、
   前記ブラウザ手段は、前記取得手段が取得した情報を前記画面情報に反映させて前記表示手段へ表示することを特徴とする画像処理装置。
2. 前記ブラウザ手段は、前記取得手段が取得した前記記憶手段に記憶された情報に基づいて生成したデータを前記文書データ中に挿入し、前記生成したデータが挿入された前記文書データを含むＷｅｂコンテンツデータに基づいて画面情報を生成して前記表示手段に表示することを特徴とする請求項１に記載の画像処理装置。
3. 前記取得手段が取得した前記記憶手段に記憶された情報を前記画像処理装置の外部に出力する指示がユーザによってなされたときに、前記ブラウザ手段は、該指示に応じた外部出力の可否をユーザに確認することを特徴とする請求項１に記載の画像処理装置。
4. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置を利用しているユーザ名を示す情報を取得し、
   前記ブラウザ手段は、前記取得手段が取得したユーザ名を示す情報を前記画面情報に付加する
   ことを特徴とする請求項１に記載の画像処理装置。
5. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置のモデル名を示す情報を取得し、
   前記ブラウザ手段は、前記取得手段が取得した前記画像処理装置のモデル名を示す情報を前記画面情報に付加する
   ことを特徴とする請求項１に記載の画像処理装置。
6. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置を構成するユニットの装着状況を示す情報を取得し、
   前記ブラウザ手段は、前記取得手段が取得した前記ユニットの装着状況を示す情報を前記画面情報に付加する
   ことを特徴とする請求項１に記載の画像処理装置。
7. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置に組み込まれたファームウェアのバージョンを示す情報を取得し、
   前記ブラウザ手段は、前記取得手段が取得した前記ファームウェアのバージョンを示す情報を前記画面情報に付加する
   ことを特徴とする請求項１に記載の画像処理装置。
8. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置の消耗品の残量を示す情報を取得し、
   前記ブラウザ手段は、前記取得手段が取得した前記画像処理装置の消耗品の残量を示す情報を前記画面情報に付加する
   ことを特徴とする請求項１に記載の画像処理装置。
9. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置の診断結果を示す情報を取得し、
   前記ブラウザ手段は、前記取得手段が取得した前記画像処理装置の診断結果を示す情報を前記画面情報に付加する
   ことを特徴とする請求項１に記載の画像処理装置。
10. 前記取得手段は、前記記憶手段に記憶される前記画像処理装置のログを示す情報を取得し、
    前記ブラウザ手段は、前記取得手段が取得した前記画像処理装置のログを示す情報を前記画面情報に付加する
    ことを特徴とする請求項１に記載の画像処理装置。
11. 画像入力手段あるいは画像出力手段の少なくともいずれかを備える画像処理装置を制御する制御方法であって、
    少なくともマークアップ言語によって記述された文書データであって、その中にスクリプトまたはスクリプトを参照する情報の埋め込まれた文書データを含むＷｅｂコンテンツデータをロードし、該ロードされたＷｅｂコンテンツデータに基づいて画面情報を生成し、該画面情報を表示手段に表示するブラウザステップと、
    前記画像入力手段あるいは前記画像出力手段のいずれかを用いた画像処理の実行を制御する制御ステップと、
    前記ロードされたＷｅｂコンテンツデータに含まれる文書データを解釈し、該文書データに埋め込まれたスクリプトまたはスクリプトを参照する情報によって特定されるスクリプトを処理するスクリプト処理ステップと、
    前記スクリプト処理ステップによる前記スクリプトの処理に基づいて、前記制御ステップにおいて前記画像処理の実行が制御されるのに伴い生成される履歴情報を記憶する記憶手段に記憶された情報を取得する取得ステップと
    を有し、
    前記ブラウザステップでは、前記取得ステップによって取得された情報を前記画面情報に反映させて前記表示手段へ表示することを特徴とする制御方法。
12. 請求項１１に記載の制御方法を、コンピュータに実行させるためのプログラム。
13. 請求項１２に記載のプログラムを格納した、コンピュータ読み取り可能な記憶媒体。

Images