(57)【要約】【課題】様々な表示形式で情報を表示する表示データを提供するにあたり、必要とする記憶容量の低減を図ることができる情報処理装置の提供を目的とする。【解決手段】ネットワークを介して接続されている端末からの要求に応じ、前記端末に所定の情報を表示させる表示データを送信する情報処理装置であって、前記所定の情報の前記表示データにおける表示形式を格納し、圧縮されている複数の圧縮表示形式定義ファイルと、前記複数の圧縮表示形式定義ファイルのうち所定の前記圧縮表示形式定義ファイルを所定のタイミングで解凍し、表示形式定義データを生成するファイル解凍手段と、前記ファイル解凍手段が生成した前記表示形式定義データを適用して前記表示データを生成する表示データ生成手段とを有することを特徴とする。【選択図】        図２
2004200906.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続されている端末からの要求に応じ、前記端末に所定の情報を表示させる表示データを送信する情報処理装置であって、
前記所定の情報の前記表示データにおける表示形式を格納し、圧縮されている複数の圧縮表示形式定義ファイルと、
前記複数の圧縮表示形式定義ファイルのうち所定の前記圧縮表示形式定義ファイルを所定のタイミングで解凍し、表示形式定義データを生成するファイル解凍手段と、
前記ファイル解凍手段が生成した前記表示形式定義データを適用して前記表示データを生成する表示データ生成手段とを有することを特徴とする情報処理装置。
【請求項２】
前記ファイル解凍手段は、前記情報処理装置の操作パネルの表示に対応した前記圧縮表示形式定義ファイルを、前記端末から最初の前記要求を受信するまでに解凍することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記ファイル解凍手段は、前記端末からの要求に対応した前記圧縮表示形式定義ファイルを解凍することを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
前記端末からの要求に対応した前記圧縮表示形式定義ファイルが既に解凍されているかを判断する解凍済み判断手段を更に有し、
前記表示データ生成手段は、前記解凍済み判断手段の判断結果に基づいて前記表示形式定義データを適用して前記表示データを生成することを特徴とする請求項３記載の情報処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置に関し、特にＷｅｂサーバの機能を有する情報処理装置に関する。
【０００２】
【従来の技術】
近年では、インターネット上で種々の情報を提供するための表示データであるＷｅｂページにおいて、デザインや情報の表示形式をユーザにあわせて提供するものが見受けられる。同一の情報を異なる表示形式で表示する顕著な例としては、異なる言語による表示が挙げられる。即ち、Ｗｅｂページを利用するユーザは、それぞれ同じ言語を使うとは限らず、様々な言語で情報を見るのが一般的である。あるユーザは日本語での表示を要求し、別のユーザは英語やフランス語等による表示を要求する。
【０００３】
一方、最近では画像処理装置のような組み込み機器において、機器のステータスや、保管された文書情報、スプールされているジョブ、ＦＡＸやｅ−ｍａｉｌ等に使用されるアドレス帳を、ネットワークを介して接続される端末等にＷｅｂページによって提供するものが存在する。Ｗｅｂページによってこれらの情報を提供する利点としては、端末側には汎用的なＷｅｂブラウザがあれば特別なソフトウェアをインストールしなくても良い、端末側のプラットフォームに依存しない、機器の側にいなくとも遠隔地において情報を確認できる等が挙げられる。このような機器によって提供されるＷｅｂページにおいても、一般的なＷｅｂサーバによるものと同様、同一の情報をユーザによって異なる言語や表示形式により表示できることが望ましい。
【０００４】
そのためには、言語種別ごと、または表示形式ごとにＷｅｂページ、又は、Ｗｅｂページに配置する文字列等を格納したリソースファイル等を予め機器に保持しておく必要がある。
【０００５】
【特許文献１】
特開平９−１８１９１４号公報
【特許文献２】
特開平９−２４４９０１号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、一般に、Ｗｅｂページやリソースファイルのようなテキストデータは、改行、タブ及びインデント等のように可読性を向上させるための制御コードが入力されることが多いため、何らかのプログラム言語で記述されたプログラムに比べてファイルサイズが大きくなりがちである。
【０００７】
従って、言語種別や表示形式ごとにＷｅｂページやリソースファイルを保持するのは，メモリ容量の制約を強く受ける組み込み機器にとって負担が大きいという問題がある。
【０００８】
本発明は、上記の点に鑑みてなされたものであって、様々な表示形式で情報を表示する表示データを提供するにあたり、必要とする記憶容量の低減を図ることができる情報処理装置の提供を目的とする。
【０００９】
【課題を解決するための手段】
そこで、上記課題を解決するため、本発明は、請求項１に記載されるように、ネットワークを介して接続されている端末からの要求に応じ、前記端末に所定の情報を表示させる表示データを送信する情報処理装置であって、前記所定の情報の前記表示データにおける表示形式を格納し、圧縮されている複数の圧縮表示形式定義ファイルと、前記複数の圧縮表示形式定義ファイルのうち所定の前記圧縮表示形式定義ファイルを所定のタイミングで解凍し、表示形式定義データを生成するファイル解凍手段と、前記ファイル解凍手段が生成した前記表示形式定義データを適用して前記表示データを生成する表示データ生成手段とを有することを特徴とする。
【００１０】
このような情報処理装置では、情報の表示形式を格納した複数のファイルを圧縮して保持し、実際に必要な、又は必要となる可能性が高い圧縮表示形式ファイルのみを解凍して表示データを生成することができるため、様々な表示形式で情報を表示する表示データを提供するにあたり、必要とする記憶容量の低減を図ることができる。
【００１１】
また、本発明は、請求項２に記載されるように、前記ファイル解凍手段は、前記情報処理装置の操作パネルの表示に対応した前記圧縮表示形式定義ファイルを、前記端末から最初の前記要求を受信するまでに解凍することを特徴とする。
【００１２】
このような情報処理装置では、複数の圧縮表示形式定義ファイルの中で、利用する可能性が高い圧縮形式定義ファイルを、端末から最初の表示データの送信要求を受信するより前に予め解凍しておくため、端末の要求に対するレスポンスの悪化を防止することができる。
【００１３】
また、本発明は、請求項３に記載されるように、前記ファイル解凍手段は、前記端末からの要求に対応した前記圧縮表示形式定義ファイルを解凍することを特徴とする。
【００１４】
このような情報処理装置では、端末からＷｅｂページの送信要求を受信する際に、要求された表示データの生成に必要な圧縮表示形式定義ファイルのみを解凍するため、記憶領域の容量を節約することができる。
【００１５】
また、本発明は、請求項４に記載されるように、前記端末からの要求に対応した前記圧縮表示形式定義ファイルが既に解凍されているかを判断する解凍済み判断手段を更に有し、前記表示データ生成手段は、前記解凍済み判断手段の判断結果に基づいて前記表示形式定義データを適用して前記表示データを生成することを特徴とする。
【００１６】
このような情報処理装置では、端末から要求された表示データの生成に必要な圧縮表示形式定義ファイルが既に解凍されている場合は、解凍された表示形式定義データを使用して表示データを生成するため、端末に対するレスポンスの悪化を防止することができる。
【００１７】
【発明の実施の形態】
以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態においては、画像処理装置を情報処理装置の一例として説明する。図１は、本発明の実施の形態における画像処理装置の機能構成例を示す図である。図１において、画像処理装置１０は、プロッタエンジン１０２３及びスキャナエンジン１０２４等の個別の画像処理を行うためのハードウェア資源と、エンジン制御ボード１０２２と、ＯＳ１０２１と、システム管理サービス１０１６と、ネットワークサービス１０１７と、メモリ管理サービス１０１８と、オペパネ管理サービス１０１９と、エンジン管理サービス１０２０と、コピーアプリ１０１１、ファックスアプリ１０１２、プリンタアプリ１０１３及びＷｅｂアプリ１０１４等の各種アプリケーションとから構成される。
【００１８】
エンジン制御ボード１０２２は、プロッタエンジン１０２３及びスキャナエンジン１０２４等の画像処理装置１０の個別機能を制御し、エンジンＩ／Ｆ（インタフェース）を通して、エンジン制御ボード１０２２の機能をＯＳ１０２１等に提供する。
【００１９】
ＯＳ１０２１は、ＵＮＩＸ（登録商標）等のオペレーティング・システムであり、コピーアプリ１０１１、ファックスアプリ１０１２等、アプリケーションとして実装されている各種ソフトウェアをプロセスとして並列実行する。
【００２０】
システム管理サービス１０１６、ネットワークサービス１０１７、メモリ管理サービス１０１８、オペパネ管理サービス１０１９、及びエンジン管理サービス１０２０は、ＡＰＩ（Application Programming Interface）を通して、コピーアプリ１０１１等の上位アプリケーションにそれぞれの機能と提供するものである。即ち、システム管理サービス１０１６は、システム管理に関する機能を提供し、ネットワークサービス１０１７は、ネットワーク通信に関する機能を提供する。また、メモリ管理サービス１０１８は、メモリ管理に関する機能を提供し、オペパネ管理サービス１０１９は、画像処理装置１０に設置された操作パネル（オペパネ）に関する機能を提供する。更に、エンジン管理サービス１０２０は、エンジン制御ボード１０２２を介してプロッタエンジン１０２３やスキャナエンジン１０２４を制御するための機能を提供する。
【００２１】
コピーアプリ１０１１は、コピー用アプリケーションであり、ファックスアプリ１０１２は、ファクシミリ用アプリケーションである。プリンタアプリ１０１３は、ページ記述言語（ＰＤＬ）、ＰＣＬ及びポストスクリプト（ＰＳ）を有するプリンタ用アプリケーションである。また、Ｗｅｂアプリ１０１４は、本発明の特徴が実装されているアプリケーションであり、画像処理装置１０にネットワークを介して接続されるＷｅｂクライアントに対して各種の情報を提供するためのアプリケーションである。
【００２２】
次に、本発明の第一の実施の形態について説明する。図２は、本発明の第一の実施の形態におけるＷｅｂサーバとしての画像処理装置の機能構成例を示す図である。図２において画像処理装置１０は、ＲＯＭ１１、ＲＡＭ１２、初期化プログラム１３、解凍プログラム１４、Ｗｅｂサーバプログラム１５、Ｗｅｂアプリケーション１６、及びＸＳＬＴプロセッサ１７等から構成される。
【００２３】
Ｗｅｂサーバプログラム１５は、一般にＨＴＴＰｄ（HTTP daemon）と呼ばれるプログラムに相当するものであり、画像処理装置１０をＷｅｂサーバとして機能させるためのものである。Ｗｅｂサーバプログラム１５は、Ｗｅｂクライアント１００からのＨＴＴＰリクエストに応じて、Ｗｅｂアプリケーション１６を起動し、Ｗｅｂアプリケーション１６が生成したＨＴＭＬ形式等のＷｅｂページをＨＴＴＰレスポンスとしてＷｅｂクライアント１００に送信する。なお、Ｗｅｂサーバプログラム１５は、図１において、ネットワークサービス１０１７の機能の一部として実装されている。
【００２４】
Ｗｅｂアプリケーション１６は、Ｗｅｂクライアント１００から要求された処理を実行することにより、Ｗｅｂクライアント１００に表示させる表示情報を取得、あるいは生成するプログラムである。Ｗｅｂアプリケーション１６は、Ｗｅｂサーバプログラム１５から呼び出され、表示情報を取得又は生成するための所定の処理を実行し、その処理結果をＸＭＬ形式の表示情報データ２１０として生成する。なお、ここで生成される表示情報データ２１０は、表示の際に言語に依存する情報は、その情報を識別するためのコード（以下、「情報識別コード」という。）によって記述されている。
【００２５】
Ｗｅｂアプリケーション１６は、更に、後述するＸＳＬＴプロセッサ１７に表示情報データ２１０をＷｅｂページ２２０に変換させ、Ｗｅｂページ２２０をＷｅｂサーバプログラム１５に対して出力する。なお、Ｗｅｂアプリケーション１６は、図１において、Ｗｅｂアプリ１０１４に相当するものである。
【００２６】
図３は、Ｗｅｂアプリケーションの生成する表示情報データの例を示す図である。図３においては、Ｗｅｂアプリケーション１６が、画像処理装置１０に関連する情報を表示情報データ２１０として出力した場合の例を示している。表示情報データ２１０においてｌａｎｇ要素（ｌａｎｇタグで囲まれている要素）２１１は、表示情報データ２１０をどの言語のＷｅｂページ２２０に変換すべきかを示す。本実施の形態において「ｊａ」の記載は、日本語に変換すべきことを意味する。Ｗｅｂアプリケーション１６は、Ｗｅｂクライアント１００からの要求に従って、ｌａｎｇ要素の値を決定する。即ち、Ｗｅｂクライアント１００から、日本語のＷｅｂページに対するＵＲＬが要求された場合は、ｌａｎｇ要素の値を「ｊａ」とし、英語のＷｅｂページに対するＵＲＬが要求された場合は、英語に対応した値である「ｅｎ」をｌａｎｇ要素の値とする。
【００２７】
ｒｅｓｕｌｔ要素２１２は、Ｗｅｂアプリケーション１６の処理結果のステータスを示す。ここで「ＳＵＣＣＥＳＳ」は、処理が正常終了したことを示す。ｓｅｔｔｉｎｇ要素２１３は、画像処理装置１０の設定情報が記載されている要素であり、複数のｉｔｅｍ要素から構成される。各ｉｔｅｍ要素は、更に、設定情報の属性名を示すＮａｍｅ要素と、その値を示すＶａｌｕｅ要素とから構成される。
【００２８】
即ち、ｉｔｅｍ要素２１４より属性「Ｓ＿ＮＡＭＥ」の値は、「Ｍｙ  Ｐｒｉｎｔｅｒ」であることが分かる。同じくｉｔｅｍ要素２１５及びｉｔｅｍ要素２１６より、属性「Ｓ＿ＧＲＯＵＰ」の値は、「ＲＲＲ」であり、属性「Ｓ＿ＣＯＭＭＥＮＴ」の値は「Ｃｏｌｏｒ  Ｐｒｉｎｔｅｒ」であることが分かる。ここで「Ｓ＿ＮＡＭＥ」、「Ｓ＿ＧＲＯＵＰ」及び「Ｓ＿ＣＯＭＭＥＮＴ」が表示情報識別コードに該当し、言語によって表示形式が異なる情報である。
【００２９】
図２に戻り、ＸＳＬＴプロセッサ１７は、Ｗｅｂアプリケーション１６から呼び出され、Ｗｅｂアプリケーション１６から引き渡された表示情報データ２１０を、ＲＡＭ上１２に格納されている言語リソースデータ２３０及びＲＯＭ１１２に格納されている書式定義ファイル２４０に従ってＷｅｂページに変換するものである。
【００３０】
ここで、言語リソースデータ２３０とは、表示情報データ２１０において記述されている情報識別コードに対する表示形式としての表示用の文字列（以下、「表示文字列」とい。）が登録されているＸＭＬ形式のデータである。言語リソースデータ２３０は、日本語、英語、仏語、独語等の言語種別毎に一つのデータとして存在する。従って、言語種別ごとの言語リソースデータ２３０には、同一の情報識別コードに対してそれぞれの言語による表示文字列が登録されている。
【００３１】
図４は、日本語用の言語リソースデータの例を示す図である。図４の記述２３１において、情報識別コード「Ｓ＿ＴＩＴＬＥ」に対する日本語による表示文字列は「設定」であることが定義されている。同様に「Ｓ＿ＮＡＭＥ」、「Ｓ＿ＧＲＯＵＰ」、「Ｓ＿ＣＯＭＭＥＮＴ」、「Ｓ＿ＣＯＮＤ」それぞれに対する表示文字列は、「プリンタ名」、「グループ」、「コメント」、「状態」として定義されている。
【００３２】
また、図５は、英語用の言語リソースデータの例を示す図である。図５の記述２３２において、情報識別コード「Ｓ＿ＴＩＴＬＥ」に対する英語による表示文字列は「Ｓｅｔｔｉｎｇｓ」であることが定義されている。同様に「Ｓ＿ＮＡＭＥ」、「Ｓ＿ＧＲＯＵＰ」、「Ｓ＿ＣＯＭＭＥＮＴ」、「Ｓ＿ＣＯＮＤ」それぞれに対する表示文字列は、「ＰｒｉｎｔｅｒＮａｍｅ」、「Ｇｒｏｕｐ」、「Ｃｏｍｍｅｎｔ」、「Ｃｏｎｄｉｔｏｎ」として定義されている。
【００３３】
また、書式定義ファイル２４０とは、表示情報データ２１０をＷｅｂページ２２０に変換する際の、表示情報データ２１０内の情報識別コードを言語リソースデータ２３０に定義されている表示文字列に置換するための定義や、Ｗｅｂページ２２０のレイアウト等を規定するための定義がされているファイルであり、ＸＳＬ（eXtensible Stylesheet Language）等によって実装されている。また、書式定義ファイル２４０は、言語の別を問わずＷｅｂページの書式ごとに一つのファイルとして存在する。即ち、同一の書式定義ファイル２４０を利用して様々な言語によるＷｅｂページ２２０を生成することができる。
【００３４】
図６及び図７は、書式定義ファイルの例を示す図である。図６と図７とで一つの書式定義ファイル２４０を示している。図６の記述２４１には、Ｗｅｂクライアント１００のＷｅｂブラウザのタイトルバーに表示する文字列のＷｅｂページ２２０への出力（以下単に「出力」という。）が定義されている。但し、出力する文字列が直接記されているのではなく、記述２４１１に示されるように、情報識別コード「Ｓ＿ＴＩＴＬＥ」によって定義されている。即ち、情報識別コード「Ｓ＿ＴＩＴＬＥ」を入力パラメータとして、後述する多言語変換テンプレート（ＳｔｒｉｎｇＧｅｎｅｒａｔｏｒ）を呼び出し、言語リソースデータ２３０に定義されている情報識別コード「Ｓ＿ＴＩＴＬＥ」に対応する表示文字列をタイトル文字列として出力する旨が定義されている。従って、図４より、日本語の場合は「設定」という文字列が、英語の場合は図５より「Ｓｅｔｔｉｎｔｇｓ」という文字列がＷｅｂブラウザのタイトルバーに表示する文字列として出力される。
【００３５】
図７の記述２４２には、Ｗｅｂページ２２０内のタイトルとして表示する文字列の出力が定義されている。記述２４２においても記述２４１と同様に、情報識別コード「Ｓ＿ＴＩＴＬＥ」を入力パラメータとして多言語変換テンプレート（ＳｔｒｉｎｇＧｅｎｅｒａｔｏｒ）を呼び出すことにより、言語リソースデータ２３０に定義されている情報識別コード「Ｓ＿ＴＩＴＬＥ」に対応する表示文字列をＷｅｂページ内のタイトル文字列として出力する旨が定義されている。
【００３６】
記述２４３には、表示情報データ２１０の各ｉｔｅｍ要素の出力が定義されている。即ち、記述２４３１にはｉｔｅｍ要素内のＮａｍｅ要素に記されている情報識別コードに対する表示文字列の出力が定義されており、記述２４３２には、ｉｔｅｍ要素内のＶａｌｕｅ要素に記されている文字列の出力が定義されている。なお、記述２４３１におけるＮａｍｅ要素については、多言語変換テンプレート（ＳｔｒｉｎｇＧｅｎｅｒａｔｏｒ）を呼び出すことにより、言語リソースデータ２３０に定義されている各Ｎａｍｅ要素における情報識別コードに対応する表示文字列を出力する旨が定義されている。
【００３７】
図６の記述２４４には、多言語変換テンプレート（ＳｔｒｉｎｇＧｅｎｅｒａｔｏｒ）が定義されている。記述２４４１において、表示情報データ２１０内のｌａｎｇ要素１２を参照し、情報識別コードの変換に利用すべき言語リソースデータ２３０の名前を特定している。なお記述２４４１における定義は、言語リソースファイル名が、「ｒｅｓｏｕｒｃｅ＿＜ｌａｎｇ要素１２の文字列＞．ｘｍｌ」という形式に従っていることを前提とした例である。従って、日本語用の言語リソースデータ２３０の名前は、ｒｅｓｏｕｒｃｅ＿ｊａ．ｘｍｌ、英語用の言語リソースデータ２３０の名前は、ｒｅｓｏｕｒｃｅ＿ｅｎ．ｘｍｌである。
【００３８】
記述２４４２においては、情報識別コードに対応する表示文字列を言語リソースファイルから検索し、出力している。
【００３９】
ＸＳＬＴプロセッサ１７は、上述した書式定義ファイル２４０及び言語リソースデータ２３０に従って、表示情報データ２１０をＷｅｂページ２２０に変換する。
【００４０】
図８は、日本語用の言語リソースデータを適用して生成したＷｅｂページの表示例を示す図である。図８のＷｅｂブラウザ１１１において、タイトルバー文字列１１２及びＷｅｂページタイトル１１３は「設定」と日本語で表示されている。また、各属性名についても、「プリンタ名」、「グループ」、「コメント」と日本語で表示されているのが分かる。これらの文字列は全て日本語用の言語リソースデータ２３０から取得したものである。
【００４１】
図９は、英語用の言語リソースデータを利用して生成されたＷｅｂページの表示例を示す図である。図９のＷｅｂブラウザ１２１において、タイトルバー文字列１２２及びＷｅｂページタイトル１２３は「Ｓｅｔｔｉｎｇｓ」と英語で表示されている。また、各属性名についても、「ＰｒｉｎｔｅｒＮａｍｅ」、「Ｇｒｏｕｐ」、「Ｃｏｍｍｅｎｔ」と英語で表示されているのが分かる。これらの文字列は全て英語用の言語リソースデータ２３０から取得したものである。なお、図９のＷｅｂページは、図８のＷｅｂページと同一の書式定義ファイル２４０を適用して生成されている。
【００４２】
図２に戻り、ＲＯＭ１１は、圧縮言語リソースファイル２５０、書式定義ファイル２４０等を格納している記憶装置である。圧縮言語リソースファイル２５０とは、言語リソースデータ２３０が圧縮されたファイルである。従って、圧縮言語リソースファイル２５０は、言語種別ごとに一つのファイルとして存在する。ＲＡＭ１２は、圧縮言語リソースファイル２５０が解凍されて生成される言語リソースデータ２３０の格納先の記憶装置である。
【００４３】
初期化プログラム１３は、画像処理装置１０が起動する際に呼び出され、解凍プログラム１４を呼び出すプログラムである。解凍プログラム１４は、ＲＯＭ１１に格納されている圧縮言語リソースファイル２５０を言語リソースデータ２３０としてＲＡＭ１２上に解凍するプログラムである。
【００４４】
Ｗｅｂクライアント１００は、画像処理装置１０とネットワークを介して接続されている端末であり、Ｗｅｂブラウザを備えている。従って、ユーザは、Ｗｅｂブラウザ１００を利用することにより、画像処理装置１０に対しＷｅｂページ２２０の送信を要求し、画像処理装置１０から送信されたＷｅｂページ２２０を閲覧することができる。
【００４５】
以下、図２の画像処理装置１０の処理手順について説明する。図１０は、第一の実施の形態における画像処理装置の処理を説明するためのフローチャートである。
【００４６】
ステップＳ１０において、画像処理装置１０が、その起動時に初期化プログラム１３を呼び出すと、初期化プログラム１３は、解凍プログラム１４を呼び出す（Ｓ１１）。ステップＳ１１に続いてステップＳ１２に進み、解凍プログラム１４は、画像処理装置１０の操作パネルでの利用言語をオペパネ管理サービス１０１９から取得する。
【００４７】
ここで、操作パネルでの利用言語（以下、「オペパネ言語」という。）とは、操作パネルにおいて表示対象となっている言語をいう。即ち、画像処理装置１０は、操作パネルの表示を様々な言語によって行うことが可能である。但し、画像処理装置１０は、実際の操作パネルへの表示は、複数の利用可能な言語の中から予めユーザによって選択された言語によって行う。従って、例えば、画像処理装置１０において利用可能な言語が、日本語、英語、仏語、独語等であった場合に、オペパネ言語が日本語と英語に設定されていたとすると、ステップＳ１２において、解凍プログラム１４は、日本語と英語がオペパネ言語であると認識する。
【００４８】
ステップＳ１２に続いてステップＳ１３に進み、解凍プログラム１４は、オペパネ言語に対応する圧縮言語リソースファイル２５０をＲＯＭ１１から取り出し、圧縮言語リソースファイル２５０を解凍した結果生成される言語リソースデータ２３０を格納するためのメモリ領域をＲＡＭ１２に確保する（Ｓ１４）。ステップＳ１４に続いてステップＳ１５に進み、解凍プログラム１４は、圧縮言語リソースファイル２５０を解凍し、言語リソースデータ２３０としてＲＡＭ１２に格納する。
【００４９】
上述した処理により、例えばオペパネ言語が日本語と英語だった場合は、日本語と英語用の圧縮言語リソースファイル２５０が解凍され、それぞれの言語リソースデータ２３０がＲＡＭ１２に格納されることになる。従って、この後、画像処理装置１００が、Ｗｅｂクライアント１００から日本語、又は英語のＷｅｂページ２２０を要求するＨＴＴＰリクエストを受信すると、ＸＳＬＴプロセッサ１７は、既にＲＡＭ１２に格納されている日本語又は英語用の言語リソースデータ２３０を利用してＷｅｂページ２２０を生成する。なお、生成したＷｅｂページ２２０は、Ｗｅｂサーバプログラム１５によってＷｅｂクライアント１００に送信される。
【００５０】
上述したように第一の実施の形態における画像処理装置１０によれば、ＲＯＭ１１には言語リソースデータ２３０を圧縮して圧縮言語リソースファイル２５０として格納するため、ＲＯＭ１１の容量を節約することができる。また、ＲＡＭ１２には、利用可能な全ての言語に対応した言語リソースデータ２３０を解凍しておくのではなく、オペパネ言語に対応した言語リソースデータ２３０のみを解凍しておくため、ＲＡＭ１２の容量も節約することができる。
【００５１】
通常、Ｗｅｂクライアント１００を利用して画像処理装置１０に対してＷｅｂページ２２０を要求するユーザは、実際に画像処理装置１０を操作パネルによって操作するユーザと同一である場合が多い。ユーザは、自分が普段利用する画像処理装置１０の情報を知りたいために画像処理装置１０にアクセスするからである。従って、起動時に解凍される圧縮言語リソースファイル２５０が、オペパネ言語に対応するもののみであっても、ユーザが要求するＷｅｂページ２２０の言語もほとんどオペパネ言語と同じであるため、Ｗｅｂクライアント１００からの要求受信時に、改めて圧縮言語リソースファイル２５０を解凍しなければならないという状況の発生を低く抑えることができ、Ｗｅｂクライアント１００に対するレスポンスの悪化を防止することもできる。
なお、解凍プログラム１４は、必ずしも画像処理装置１０の起動と同時に初期化プログラムから呼び出される必要はなく、Ｗｅｂクライアント１００からＷｅｂサーバプログラム１５に最初のＷｅｂページ２２０の送信要求（ＨＴＴＰ（HyperText Transfer Protocol）リクエスト）があるまでに呼び出されればよい。従って、例えば、Ｗｅｂサーバプログラム１５がその起動時に解凍プログラム１４を呼び出してもよい。
【００５２】
次に本発明の第二の実施の形態について説明する。図１１は、本発明の第二の実施の形態におけるＷｅｂサーバとしての画像処理装置の機能構成例を示す図である。図１１中、図２と同一部分には同一符号を付し、その説明は省略する。なお、第一の実施の形態における画像処理装置１０においては、初期化プログラム１３が解凍プログラム１４を呼び出していたが（図２）、第二の実施の形態における画像処理装置１０は、ＸＳＬＴプロセッサ１７が解凍プログラム２４の呼び出しを行う（図１１）。以下、図１１の画像処理装置１０の処理手順について説明する。図１２は、第二の実施の形態における画像処理装置の処理を説明するためのフローチャートである。
【００５３】
ステップＳ２０において、画像処理装置１０のＷｅｂサーバプログラム１５が、Ｗｅｂクライアント１００からＷｅｂページ２２０の送信を要求するＨＴＴＰリクエストを受信する。ステップＳ２０に続いてステップＳ２１に進み、Ｗｅｂサーバプログラム１５がＨＴＴＰリクエストに対応するＷｅｂアプリケーション１６を呼び出すと、Ｗｅｂアプリケーション１６は所定の処理を実行し、処理結果として表示情報データ２１０を生成する。
【００５４】
ステップＳ２１に続いてステップＳ２２に進み、Ｗｅｂアプリケーション１６は、処理結果としての表示情報データ２１０をＷｅｂページ２２０に変換すべく、表示情報データ２１０とそれに対応する書式定義ファイル２４０を指定してＸＳＬＴプロセッサ１７を呼び出す。
【００５５】
ステップＳ２２に続いてステップＳ２３進み、ＸＳＬＴプロセッサ１７が、表示情報データ２１０のｌａｎｇ要素２１１を参照して、Ｗｅｂページ２２０の生成に必要な言語リソースデータ２３０を判断し、その圧縮言語リソースファイル２５０の解凍を解凍プログラム１４に要求すると、解凍プログラム１４は、指定された圧縮言語リソースファイル２５０をＲＯＭ１１から検索する。例えば、表示情報データ２１０のｌａｎｇ要素２１１の値が「ｊａ」だった場合は、日本語用の圧縮言語リソースファイル２５０の解凍が解凍プログラム１４に要求される。
【００５６】
ステップＳ２４及びステップＳ２５において、解凍プログラム１４は、第一の実施の形態におけるステップＳ１４及びステップＳ１５における手順と同様の手順で、ＸＳＬＴプログラム１４によって指定された圧縮言語リソースファイル２５０を解凍し、言語リソースデータ２３０をＲＡＭ１２に格納する。
【００５７】
ステップＳ２５に続いてステップＳ２６に進み、ＸＳＬＴプロセッサ１７は、書式定義ファイル２４０とＲＡＭ１２に格納された言語リソースデータ２３０とを適用して表示情報データ２１０をＷｅｂページ２２０に変換する。ステップＳ２６に続いてステップＳ２７に進み、ＸＳＬＴプロセッサ１７は、ＲＡＭ１２において、言語リソースデータ２３０が格納されているメモリ領域を解放することにより、言語リソースデータ２３０をＲＡＭ１２内から削除する。
【００５８】
ステップＳ２７に続いてステップＳ２８に進み、Ｗｅｂサーバプログラム１５は、Ｗｅｂアプリケーション１６から受け取ったＷｅｂページ２２０をＷｅｂクライアント１００に送信する。
【００５９】
上述したように、第二の実施の形態における画像処理装置１０によれば、ＲＯＭ１１には圧縮された圧縮言語リソースファイル２５０を格納しておくため、ＲＯＭ１１の容量を節約することができる。また、画像処理装置１０は、Ｗｅｂクライアント１００からのＨＴＴＰリクエストを受信した際に、Ｗｅｂクライアント１００が要求する言語に対応した圧縮言語リソースファイル２５０のみをＲＡＭ１２に解凍し、Ｗｅｂページ２２０の生成が完了したらＲＡＭ１２における言語リソースデータ２３０のメモリ領域を解放するため、ＲＡＭ１２の領域を節約することができる。
【００６０】
なお、第二の実施の形態における画像処理装置１０において、第一の実施の形態におけるようにオペパネ言語に対応する圧縮言語リソースファイル２５０を、Ｗｅｂクライアント１００から最初のＷｅｂページ２２０の送信要求を受信するまでに解凍しておいてもよい。それによって、Ｗｅｂクライアント１００からオペパネ言語と同一の言語によるＷｅｂページの送信を要求された場合は、迅速にレスポンスすることができる。
【００６１】
次に本発明の第三の実施の形態について説明する。図１３は、第三の実施の形態における画像処理装置の処理を説明するためのフローチャートである。なお、第三の実施の形態における画像処理装置１０の機能構成例は、図１１における第二の実施の形態における画像処理装置１０と同様である。
【００６２】
ステップＳ３０において、画像処理装置１０のＷｅｂサーバプログラム１５がＷｅｂクライアント１００からＨＴＴＰリクエストを受信すると、第二の実施の形態におけるステップＳ２１からステップＳ２３の手順と同様の手順をステップＳ３１からＳ３３において実行し、解凍プログラム１４を呼び出す。
【００６３】
ステップＳ３３に続いてステップＳ３４に進み、解凍プログラム１４は、解凍を要求された圧縮言語リソースファイル２５０をキャッシュ管理テーブルから検索し、解凍対象の圧縮言語リソースファイル２５０がキャッシュ管理テーブルに登録されているか否かを判断する。キャッシュ管理テーブルの詳細については後述するが、キャッシュ管理テーブルは、既に解凍されＲＡＭ１２に格納されている圧縮言語リソースファイル２５０の一覧を管理しているものである。解凍対象の圧縮言語リソースファイル２５０がキャッシュ管理テーブルに登録されている場合、即ち、既にＲＡＭ１２に解凍されている場合はステップＳ３８に進み、登録されていない場合、即ちまだ解凍されていない場合はステップＳ３５に進む。
【００６４】
ステップＳ３５及びステップＳ３６において、解凍プログラム１４は、第二の実施の形態におけるステップＳ２４及びステップＳ２５における手順と同様の手順で、指定された圧縮言語リソースファイル２５０を解凍し、言語リソースデータ２３０をＲＡＭ１２に格納する。
【００６５】
ステップＳ３６に続いてステップＳ３７に進み、解凍プログラム１４は、解凍した圧縮言語リソースファイル２５０をキャッシュ管理テーブルに登録する。
【００６６】
ステップＳ３７以降、ステップＳ３８及びステップＳ３９において、画像処理装置１０は、第二の実施の形態におけるステップＳ２６及びＳ２８と同様の手順でＷｅｂページ２２０を生成し、生成したＷｅｂページ２２０をＷｅｂクライアント１００に送信する。
【００６７】
更に、ステップＳ３４及びＳ３７等におけるキャッシュ管理テーブルの検索、更新処理の詳細について説明する。なお、キャッシュ管理テーブルは図１４に示すようなリスト構造を利用して実装することができる。
【００６８】
図１４は、リスト構造によるキャッシュ管理テーブルの実装例を示す図である。図１４において、リスト５０は、キャッシュエントリ５０１、５０２及び５０３を有している。各キャッシュエントリは、圧縮言語リソースファイル２５０のファイル名である「ファイル名」と、その圧縮言語リソースファイル２５０が解凍されたＲＡＭ１２上のアドレスである「ＲＡＭ上のアドレス」と、「次のエントリへのポインタ」とをデータ項目として有している。
【００６９】
以下、キャッシュ管理テーブルを図１４のようなリスト構造で実装した場合のキャッシュ管理テーブルの検索、更新処理の詳細について説明する。図１５は、キャッシュ管理テーブルの検索及びＬＲＵ法による更新処理を説明するためのフローチャートである。なお、図１５のフローチャートは、図１３のフローチャートにおけるステップＳ３４からＳ３７までの処理に該当する。
【００７０】
ステップＳ１００において、解凍プログラム１４は、リスト５０から最初のキャッシュエントリを取り出し、キャッシュエントリのファイル名が解凍対象の圧縮言語リソースファイル２５０のファイル名と同じかどうか判断する（Ｓ１０１）。ファイル名が同じ場合はステップＳ１０２に進み、ファイル名が異なる場合はステップＳ１０３に進む。
【００７１】
ステップＳ１０３において、解凍プログラム１４は、既に取り出したキャッシュエントリの「次のエントリへのポインタ」を参照することにより、リスト５０から次のキャッシュエントリを取り出す。ステップＳ１０３に続いてステップＳ１０４に進み、解凍プログラム１４は、キャッシュエントリがもう存在しないかどうかを判断する。この判断は、既に取り出したキャッシュエントリの「次のエントリポインタ」の値がＮＵＬＬか否かによって行うことができ、解凍プログラム１４は、「次のエントリへのポインタ」の値がＮＵＬＬだったら次のキャッシュエントリは存在しないと判断する。
【００７２】
キャッシュエントリが存在する場合は、ステップＳ１０１に進み、再び解凍対象のファイル名とキャッシュエントリのファイル名を比較する。ファイル名が同一の場合は、解凍対象の圧縮言語リソースファイル２５０は既にＲＡＭ１２に解凍されているため、ステップＳ１０２に進み、現在処理対象のキャッシュエントリをリスト５０の先頭に繋ぎかえて処理を終了する。ここで、処理対象のキャッシュエントリをリスト５０の先頭とするのは、次回の検索の際に、今回使用された言語リソースデータ２３０に対するキャッシュエントリを最初の比較対象とするためである。なお、処理を終了する際に解凍プログラム１４は、解凍された言語リソースデータ２３０のＲＡＭ１２上におけるアドレスをキャッシュエントリから取り出して、呼び出し元のＸＳＬＴプロセッサ１７に対して通知する。
【００７３】
ステップＳ１０４において、リスト５０内に解凍対象とする圧縮言語リソースファイル２５０に対応するキャッシュエントリを発見することができなかった場合はステップＳ１０５に進み、解凍プログラム１４は、解凍対象の圧縮言語リソースファイル２５０をＲＯＭ１１から解凍し、ＲＡＭ１２に格納する。この処理は、図１３におけるステップＳ３５及びステップＳ３６に対応する。
【００７４】
ステップＳ１０５に続いてステップＳ１０６に進み、解凍プログラム１４は、ステップＳ１０５においてＲＡＭ１２に格納された言語リソースデータ２３０に対応するキャッシュエントリを生成し、リスト５０の先頭に追加する。
【００７５】
ステップＳ１０６に続いてステップＳ１０７に進み、解凍プログラム１４は、リスト５０のキャッシュエントリの数が所定の上限を超えているかどうかを判断する。この上限はＲＡＭ１２の容量等に応じて適宜定めればよい。上限を超えていない場合はそのまま処理を終了し、超えている場合は、リスト５０の末尾のキャッシュエントリを削除し、さらにその直前のエントリの「次のエントリへのポインタ」の値をＮＵＬＬにして、処理を終了する。ここで、末尾のキャッシュエントリを削除の対象とするのは、最も長い間利用されていない言語リソースデータ２３０をＲＡＭ１２から削除するためである。なお、処理を終了する際に解凍プログラム１４は、新たに解凍した言語リソースデータ２３０のＲＡＭ１２上におけるアドレスを、呼び出し元のＸＳＬＴプロセッサ１７に対して通知する。
【００７６】
図１５においては、リスト５０においてキャッシュエントリの数の上限を超えた場合は、最も長い間使用されていないキャッシュエントリが削除、即ち最も長い間使用されていない言語リソースデータ２３０をＲＡＭ１２から削除するようにしているが（ＬＲＵ（Least Recentry Used）法）、リスト５０内において最初に生成されたキャッシュエントリを削除、即ち解凍された時期が最も早い言語リソースデータ２３０をＲＡＭ１２から削除するようにしてもよい（ＦＩＦＯ（First-In First-Out）法）。その場合のフローチャートを図１６に示す。
【００７７】
図１６は、キャッシュ管理テーブルの検索及びＦＩＦＯ法による更新処理を説明するためのフローチャートである。図１６において、解凍プログラム１４は、解凍対象とする圧縮言語リソースファイル２５０に対応するキャッシュエントリを見つけた場合には（Ｓ２０１でＹｅｓの場合）、そのキャッシュエントリをリスト５０の先頭にすることなく処理を終了する。また、新たに圧縮言語リソースファイル２５０を解凍し（Ｓ２０４）、それに対するキャッシュエントリを生成した際には、そのキャッシュエントリはリストの末尾に追加する（Ｓ２０５）。更に、キャッシュエントリの数が上限を超えた場合には（Ｓ２０６でＹｅｓの場合）、先頭のキャッシュエントリを削除する（ＳＳ２０７）。これにより、ＦＩＦＯ法によりリスト５０を更新することができる。
【００７８】
上述したように、第三の実施の形態における画像処理装置１０によれば、ＲＯＭ１１には圧縮されたデータである圧縮言語リソースファイル２５０を格納するため、ＲＯＭ１１の容量を節約することができる。また、画像処理装置１０は、Ｗｅｂクライアント１００からのＨＴＴＰリクエストを受信した際に、ＨＴＴＰリクエストの応答としてのＷｅｂページ２２０の生成に必要な圧縮言語リソースファイル２５０のみをＲＡＭ１２に解凍するため、ＲＡＭ１２の領域を節約することができる。更に、一度解凍した圧縮言語リソースファイル２５０は、言語リソースデータ２３０としてＲＡＭ１２に格納されているため、以降、Ｗｅｂクライアント１００からの要求に対して同じ言語リソースデータ２３０を利用する場合は、レスポンスの悪化を防止することができる。
【００７９】
なお、上述したそれぞれの実施の形態においては、情報識別コードに対して言語種別ごとに表示文字列を定義した例について説明したが、本発明の適用範囲は言語種別の相違によって表示文字列を変化させる場合のみに限られない。例えば、Ｗｅｂクライアント１００がアクセスしてきた時間によって表示文字列を変化させてもよい（挨拶を表示する場合等）。この場合は、言語種別ごとに保持していた圧縮言語リソースファイル２５０を時間帯ごとに用意すればよい（朝用リソース、昼用リソース、夜用リソース等）。また、情報識別コードに対する表示形式は文字列だけでなく、イメージデータでもよい。この場合は、イメージデータを圧縮して保持しておくことにより、本実施の形態と同様の効果を得ることができる。
【００８０】
また、上述したそれぞれの実施の形態においては、Ｗｅｂサーバとして画像処理装置を適用した例について説明したが、本発明は、Ｗｅｂサーバとして機能するその他の機器に適用してもよい。
【００８１】
以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００８２】
【発明の効果】
上述の如く、本発明によれば、情報処理装置において、様々な表示形式で情報を表示する表示データを提供するにあたり、必要とする記憶容量の低減を図ることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態における画像処理装置の機能構成例を示す図である。
【図２】本発明の第一の実施の形態におけるＷｅｂサーバとしての画像処理装置の機能構成例を示す図である。
【図３】Ｗｅｂアプリケーションの生成する表示情報データの例を示す図である。
【図４】日本語用の言語リソースデータの例を示す図である。
【図５】英語用の言語リソースデータの例を示す図である。
【図６】書式定義ファイルの例を示す図である。
【図７】書式定義ファイルの例を示す図である。
【図８】日本語用の言語リソースデータを適用して生成したＷｅｂページの表示例を示す図である。
【図９】英語用の言語リソースデータを適用して生成したＷｅｂページの表示例を示す図である。
【図１０】第一の実施の形態における画像処理装置の処理を説明するためのフローチャートである。
【図１１】本発明の第二の実施の形態におけるＷｅｂサーバとしての画像処理装置の機能構成例を示す図である。
【図１２】第二の実施の形態における画像処理装置の処理を説明するためのフローチャートである。
【図１３】第三の実施の形態における画像処理装置の処理を説明するためのフローチャートである。
【図１４】リスト構造によるキャッシュ管理テーブルの実装例を示す図である。
【図１５】キャッシュ管理テーブルの検索及びＬＲＵ法による更新処理を説明するためのフローチャートである。
【図１６】キャッシュ管理テーブルの検索及びＦＩＦＯ法による更新処理を説明するためのフローチャートである。
【符号の説明】
１０            画像処理装置
１１            ＲＯＭ
１２            ＲＡＭ
１３            初期化プログラム
１４            解凍プログラム
１５            Ｗｅｂサーバプログラム
１６            Ｗｅｂアプリケーション
１７            ＸＳＬＴプロセッサ
１００          端末
２１０          表示情報
２２０          Ｗｅｂページ
２３０          言語リソースデータ
２４０          書式定義ファイル
２５０          圧縮言語リソースファイル
１０１１        コピーアプリ
１０１２        ファックスアプリ
１０１３        プリンタアプリ
１０１４        Ｗｅｂアプリ
１０１６        システム管理サービス
１０１７        ネットワークサービス
１０１８        メモリ管理サービス
１０１９        オペパネ管理サービス
１０２０        エンジン管理サービス
１０２１        ＯＳ
１０２２        エンジン制御ボード
１０２３        プロッタエンジン
１０２４        スキャナエンジン
【図１】
2004200906.tif 000003
【図２】
2004200906.tif 000004
【図３】
2004200906.tif 000005
【図４】
2004200906.tif 000006
【図５】
2004200906.tif 000007
【図６】
2004200906.tif 000008
【図７】
2004200906.tif 000009
【図８】
2004200906.tif 000010
【図９】
2004200906.tif 000011
【図１０】
2004200906.tif 000012
【図１１】
2004200906.tif 000013
【図１２】
2004200906.tif 000014
【図１３】
2004200906.tif 000015
【図１４】
2004200906.tif 000016
【図１５】
2004200906.tif 000017
【図１６】
2004200906.tif 000018