JP5194271B2 - 情報処理装置 - Google Patents

Description

本発明は、Ｗｅｂクライアントからの遠隔操作を可能にするＷｅｂサーバ機能を備えた情報処理装置に関する。

下記特許文献１には、コンピュータの汎用ブラウザで、ネットワークを介して接続されたディジタル複合装置の動作状況を監視するとともにその動作を制御可能なディジタル複合装置が開示されている。

このディジタル複合装置は、ＨＴＴＰサーバと、ＨＴＴＰサーバ上で起動されるＣＧＩスクリプトとを備え、クライアントからのリクエストとは無関係にＨＴＴＰサーバ側でディジタル複合装置の動作状況を示すＨＴＭＬファイルを常時更新しておき、クライアントからのリクエストに基づきこのファイルをクライアントへ送信してクライアント側で動作状況をリアルタイムで監視できるようにしている。

また、クライアントからのリクエストに基づきＣＧＩスクリプトを起動させて、メモリ内のアクセス履歴ファイルを読み込み、その内容を統計処理し、処理結果のＨＴＭＬファイルを作成し、ＨＴＴＰサーバを介してクライアントに送信している。

さらに、クライアントからのリクエストに基づきＣＧＩスクリプトを起動させて、ディジタル複合装置の動作を制御している。
特許第３８６２３７２号公報

しかし、サーバサイドでＣＧＩプログラムを起動させるためには、クライアントサイドで必ずＣＧＩプログラムのパスを指定しなければならず、ＣＧＩプログラムでテンプレートファイルを使用する場合にはクライアントサイドでさらにこのテンプレートファイルのパスも指定しなければならない。これらの指定は、サーバからクライアントに送信されるＨＴＭＬファイルや、このＨＴＭＬファイルを生成するためのテンプレートファイルなどのテキストファイルに記述されており、サーバサイドのテキストファイルの記述を複雑にする原因となる。

本発明の目的は、このような問題点に鑑み、サーバサイドの記憶手段に格納されるテキストファイルの記述を簡単化することが可能な情報処理装置を提供することにある。

本発明の第１態様では、
プロセッサと、
プログラムと設定データとが格納され、該プロセッサに結合された記憶手段と、
を備え、該プログラムがＷｅｂサーバとＷｅｂアプリケーションとを含む情報処理装置において、
該設定データには実質的に仮想ファイルパス又は仮想ディレクトリパスが含まれ、
該Ｗｅｂサーバは、該プロセッサに対し、クライアントからのリクエストＵＲＩに含まれるパスが該設定データ中の仮想ファイルパスと一致し又は該設定データ中の仮想ディレクトリパス以下のものであるか否かという第１判定を実質的に行わせ、肯定判定した場合には該Ｗｅｂアプリケーションに制御を移す第１振分部を有する。

ここに「実質的に〜含まれ」とは、仮想ファイルパス又は仮想ディレクトリパスに対応した実パスが含まれていてもよいことを意味する。また、「判定を実質的に行わせ」とは仮想ファイルパス又は仮想ディレクトリパスに対応した実パスを用いて判定する場合を含む意味である。

本発明による情報処理装置の第２態様では、第１態様において、該第１振分部は該プロセッサに対し、該ファイル名の拡張子が特定のものであるか否かという第２判定を行わせ、該第２判定で否定判定した場合に該第１判定を行わせる。

本発明による情報処理装置の第３態様では、第２態様において、該Ｗｅｂサーバはさらに、該プロセッサに対し、指定されたパスの静的リソースをリクエストボディとして取得させる静的リソース処理部を有し、
該第１振分部は該プロセッサに対し、該第２判定で否定判定し且つ該第１判定で否定判定した場合に、該リクエストＵＲＩに含まれるパスを指定して該静的リソース処理部に制御を移させる。

本発明による情報処理装置の第４態様では、第１乃至３態様のいずれか１つにおいて、該Ｗｅｂアプリケーションは、
該プロセッサに対し、指定されたパスのテンプレートファイルに基づきリスポンスボディを生成させるＧＥＴ処理制御部と、
該プロセッサに対し、該リクエストＵＲＩに含まれるパスのファイル名がプログラムファイル名であるか否かという第３判定を行わせ、否定判定した場合には該パスを指定して該ＧＥＴ処理制御部に制御を移させる第２振分部とを有する。

本発明による情報処理装置の第５態様では、第４態様において、該第３判定では、該リクエストＵＲＩに含まれるパスのファイル名が複数のプログラムファイル名のいずれでもない場合に、該リクエストＵＲＩに含まれるパスのファイル名がプログラムファイル名でないと判定する。

本発明による情報処理装置の第６態様では、第４又は５態様において、該第１振分部と該第２振分部と該ＧＥＴ処理制御部とが同一プロセス内で実行される。

上記第１態様の構成によれば、Ｗｅｂサーバにおいて、クライアントからのリクエストＵＲＩに含まれるパスが設定データ中の仮想ファイルパスと一致し又は該設定データ中の仮想ディレクトリパス以下のものと判定されれば、Ｗｅｂアプリケーションに制御が移るので、Ｗｅｂアプリケーションに制御を移すためのプログラムファイルパスを省略でき、これによりサーバサイドの記憶手段に格納されるテキストファイルの記述を簡単化することができるという効果を奏する。

上記第２態様の構成によれば、この省略を行わない場合、第１振分部での判定処理が速くなるという効果を奏する。

上記第３態様の構成によれば、この省略を行っても、誤りなく静的リソース処理部に制御を移させることができるという効果を奏する。

上記第４態様の構成によれば、この省略を行った場合、指定されたパスのテンプレートファイルに基づきリスポンスボディを生成させるＧＥＴ処理制御部に制御が移るので、このパスを指定すればよいという効果を奏する。

上記第５態様の構成によれば、この省略を行わなくてもよいので、省略してもＧＥＴ処理制御部で処理されることが明らかな場合のみ省略することができるという効果を奏する。

上記第６態様の構成によれば、第１振分部処理部と第２振分部処理部とＧＥＴ処理制御部との連携を容易に行うことができ、処理を高速化できるとともにメモリを節約できるという効果を奏する。

本発明の他の目的、構成及び効果は以下の説明から明らかになる。

図１５は、本発明の実施例１に係る画像形成システムのハードウエア概略ブロック図である。

情報処理装置としての画像形成装置１０は、コピー、プリント、ＦＡＸ送受信及び電子メール送信を行うことが可能な複合機である。画像形成装置１０は、ＨＴＴＰに従ったＷｅｂサーバマシンとしても機能し、イントラネット内のホストコンピュータの汎用ブラウザによる画像形成装置１０の遠隔操作が可能となっている。

画像形成装置１０では、ＭＰＵ１１にインターフェイス１２を介してＰＲＯＭ１３、ＤＲＡＭ１４、操作パネル１５、プリンタ１６、スキャナ１７、ＮＩＣ（Network Interface Card）１８及びＦＡＸモデム１９が接続されている。図１５では簡単化のため、複数のインターフェイスを１つのブロックで示している。

ＰＲＯＭ１３は、例えばフラッシュメモリであり、これにはマルチプロセス及びマルチスレッドの機能を備えた汎用ＯＳ(オペレーティングシステム)、Ｗｅｂサーバ及びＷｅｂアプリケーション（画像形成処理プログラムを含む）並びに後述の各種データが格納されている。ＯＳは、例えばLinux（登録商標）である。

ＤＲＡＭ１４は、ワークエリア用であり、マルチプロセス及びマルチスレッドのインスタンス並びにリクエストメッセージ、リスポンスメッセージ及びこれらに関係したデータが格納され、解放される。操作パネル１５は、設定値又は指示を入力し、設定画面や状態などを表示させるためのものである。プリンタ１６は、コピー及びファックス送信での画像入力用である。スキャナ１７は、プリントエンジン並びに用紙の給紙部、搬送部及び排紙部を備え、ＤＲＡＭ１４内に生成されたビットマップデータが供給され、このデータに基づいて感光ドラムに静電潜像を形成し、この像をトナーで現像し、トナー像を用紙に転写し定着させ、排紙する。ＮＩＣ１８は、ケーブル又は無線の通信媒体を介して複数のＷｅｂクライアントマシーン２０、２１、・・・に結合される。ＦＡＸモデム１９は、公衆回線網２８を介して任意のＦＡＸ装置２９に結合される。

図１は、主に画像形成装置１０のソフトウエア構成を示す機能ブロック図である。

画像形成装置１０では、ＰＲＯＭ１３（図１５）内に、プログラムとして、ＯＳ３０と、その上層のｉｎｅｔｄ３１、ｈｔｔｐｄ３２、メール送信サーバ３３、メインＷｅｂサーバ３４、Ｗｅｂアプリケーション３５及びＤＢＭＳ（database management system）３６とを備え、データとして、静的リソース３７と、ＨＴＭＬテンプレートファイル３８と、バッファサイズテーブル３９と、言語テーブルファイル４０と、データベース４１と、コンフィグレーションファイル４２とを備えている。

ｉｎｅｔｄ３１、ｈｔｔｐｄ３２及びメール送信サーバ３３は汎用プログラムである。ｉｎｅｔｄ３１及びｈｔｔｐｄ３２中の文字"ｄ"は、バックグラウンドで動作するデーモンであることを示しており、それぞれプロセスとして動作する。メインＷｅｂサーバ３４、Ｗｅｂアプリケーション３５及びＤＢＭＳ３６は１つのプロセスとして動作する。

ｉｎｅｔｄ３１を用いている理由は、既存の資産を有効利用してメインＷｅｂサーバ３４の構成を簡単化するためである。ｉｎｅｔｄ３１は、定義ファイルに記述された１つ以上のポートを監視するのでスーパーサーバと称されており、クライアントとの間でＴＣＰ接続が確立する毎に、そのポート番号に対応した、定義ファイルに記述されているプログラムを起動させる。本実施例では、ｉｎｅｔｄ３１は８０番のポートのみ監視し、クライアントとの間でＴＣＰ接続が確立する毎にｈｔｔｐｄ３２を起動させる。ｉｎｅｔｄ３１は、セキュリティ機能（フィルタ）も備えており、本実施例では、定義ファイルに記述されたローカルＩＰアドレスを持つクライアントからの接続要求のみ受け付ける。

ｈｔｔｐｄ３２を用いている理由は、これを用いないとｉｎｅｔｄ３１が接続要求を受け付ける毎にメインＷｅｂサーバ３４が起動されることになるからである。メインＷｅｂサーバ３４は、システム起動時に１回起動させれば、後述のように、メインＷｅｂサーバ３４内でリクエスト毎にスレッドが生成されて並行処理が可能となっており、リクエスト毎にプロセスを生成するよりもメモリを節約することができる。

本実施例１によれば、既存の資産を有効利用してメモリ資源節約型メインＷｅｂサーバの構成を簡単化しその開発期間を短縮することができるという効果を奏する。

ｈｔｔｐｄ３２は、起動されると、ｉｎｅｔｄ３１でＴＣＰ接続が確立したクライアントからのリクエストメッセージを、Ｗｅｂクライアントマシーン２０からＮＩＣ１８及びＯＳ３０を介し受け取り、パイプでメインＷｅｂサーバ３４に渡した後、ＤＲＡＭ１４上から消滅する。すなわち、ｈｔｔｐｄ３２は、仲介役としてのみ機能する。このため、この仲介に必要な機能のみコンパイルされて用いられ、これによりメモリをさらに節約することができるという効果を奏する。

メインＷｅｂサーバ３４では、ＨＴＴＰ処理スレッド生成部３４０が、ｈｔｔｐｄ３２からのリクエストメッセージを受け取ってＨＴＴＰ処理スレッド３４１を生成し、このメッセージの識別子をＨＴＴＰ処理スレッド３４１のコンストラクタに引き渡し、ＨＴＴＰ処理スレッド３４１を起動させる。

ＨＴＴＰ処理スレッド３４１は、このメッセージをパースし、メッセージに含まれているリクエストＵＲＩ中のパス及びＧＥＴメソッドの場合のクエリ文字列、各フィールド名とその値、ＰＯＳＴメソッドの場合には変数名とその値（本明細書及び特許請求の範囲では、ＰＯＳＴメソッドにおいて、ＧＥＴメソッドの場合のクエリ文字列に対応するものもクエリ文字列と称す）を、予め定めた構造体の変数の対応する要素に代入し、この構造体変数（以下、Ｓ変数と称す。）の識別子（以下、Ｓ識別子と称す。）を引数として処理粗振分部３４２を呼び出す。

以下の処理では、リクエストメッセージ中の情報が、Ｓ変数の対応する要素を介して用いられ、これにより以下の複数の処理のそれぞれが簡単になる。リクエストＵＲＩ中のパスが格納されたＳ変数の要素をＳ変数．パス、クエリ文字列が格納されたＳ変数の要素をＳ変数．クエリ文字列と表記する。
図３は、処理粗振分部３４２による処理を示すフローチャートである。以下、カッコ内は図中の識別符号である。

（Ｓ０）Ｓ変数．パスを読取る。

（Ｓ１）このパスに含まれるファイル名の拡張子が"cgi"であればステップＳ２へ進み、そうでなければステップＳ３へ進む。

（Ｓ２）Ｓ識別子を引数としてＷｅｂアプリケーション３５を呼出し、図３の処理を終了する。

（Ｓ３）ステップＳ０で読取ったパスが、コンフィグレーションファイル４２内のフォースファイル項目に記述された、ファイル名に一致し又はディレクトリのパス以下のものである場合には、ステップＳ２へ進み、そうでなければステップＳ４へ進む。すなわち、リクエスト対象を示すパスが所定パスであればＣＧＩプログラムのうち、後述のget.cgiに対するリクエストであるとみなす。

（Ｓ４）Ｓ識別子を引数として静的リソース処理部３４３を呼び出す。

静的リソース処理部３４３はこれに応答して、Ｓ変数．パスで識別されるファイルの内容を静的リソース３７からＤＲＡＭ１４上に読出し、その識別子を、対応するＨＴＴＰ処理スレッド３４１に引き渡す。ＨＴＴＰ処理スレッド３４１はこれに応答して、このファイルの内容にリスポンスヘッダを付加し、リスポンスメッセージとして、ＯＳ３０及びＮＩＣ１８を介しＷｅｂクライアントマシーン２０へこのメッセージを送信する。

本実施例１によれば、処理粗振分部３４２において、クライアントからのリクエストＵＲＩに含まれるパスがコンフィグレーションファイル４２内のフォースファイル項目に記述された仮想ファイルパスと一致し又は仮想ディレクトリパス以下のものと判定されれば、Ｗｅｂアプリケーション３５に制御が移るので、Ｗｅｂアプリケーション３５に制御を移すためのプログラムファイルパスを省略でき、これにより３７及び３８の記述を簡単化することができるという効果を奏する。

次に、処理粗振分部３４２によりＷｅｂアプリケーション３５が呼び出された場合の処理を説明する。図２は、主にＷｅｂアプリケーション３５の構成を示す機能ブロック図である。

この呼出は、Ｗｅｂアプリケーション３５の処理細振分部３５０に対して行われる。図４は、処理細振分部３５０による処理を示すフローチャートである。

ここで、従来ではＣＧＩプログラムのそれぞれがプロセスとして起動されていたが、本実施例１では、ＣＧＩプログラムのそれぞれを１つのプロセスの中の関数（サブルーチン）として起動することにより、プロセス間通信による遅延を防止するとともに、複数のＣＧＩプログラムでリソースを共有して、全体として必要なメモリサイズを削減している。すなわち、ＣＧＩ方式の利点を有効利用するとともに、その欠点を補っている。

（Ｓ１０、Ｓ１１）Ｓ変数．パスに含まれるファイル名本体（ファイル名から.cgiを除いた部分）が"login"であればＳ識別子を引数として認証制御部３５１を呼び出し、図４の処理を終了する。

（Ｓ１２、Ｓ１３）該ファイル名本体が"get"であればＳ識別子を引数としてＧＥＴ処理制御部３５２を呼び出し、図４の処理を終了する。

（Ｓ１４、Ｓ１５）該ファイル名本体が"set"であればＳ識別子を引数としてＳＥＴ処理制御部３５３を呼び出し、図４の処理を終了する。

（Ｓ１６、Ｓ１７）該ファイル名本体が"image"であればＳ識別子を引数としてイメージ処理制御部３５４を呼び出し、図４の処理を終了し、そうでなければ、すなわちフォースファイルであれば、ステップＳ１３へ進む。

図２に戻って、ＧＥＴ処理制御部３５２は、Ｓ変数．クエリ文字列に含まれるパスを引数としてＨＴＭＬトランスレータ３５５を呼び出す。例えば、リクエスト行がGET /cgi-bin/get.cgi?htmfile=/start/start.html HTTP/1.1である場合、Ｓ変数．クエリ文字列はhtmfile=/start/start.htmlであり、このパス/start/start.htmlは、ＨＴＭＬテンプレートファイルのパスである。ＨＴＭＬトランスレータ３５５はこの呼出に応答して、図５（Ａ）に示す処理を行う。

ここで、ＨＴＭＬテンプレートファイル３８の各々について、図５（Ｂ）に示す如く、そのパスとそのファイルサイズに対応したバイト数とを対応させたバッファサイズテーブル３９が予め作成されている。このバイト数は例えば、ファイルサイズ自体、ファイルサイズの１．１倍又はファイルサイズに２５６バイトを加えたものなどである。

（Ｓ２０）バッファサイズテーブル３９から、指定されたテンプレートファイルに対応したバイト数を読取る。

（Ｓ２１）図１に示すＯＳ３０のメモリマネージャ３０２を介し、ＤＲＡＭ１４上のこのバイト数の一時記憶領域を獲得する。

（Ｓ２２）テンプレートファイルから、ステートメント行カウンタＳＬＣが示す行のステートメントを読み込み、このカウンタＳＬＣを１だけインクリメントする。

（Ｓ２３）ステップＳ２２で読み込むべきステートメントが存在しなかった場合にはステップＳ２９へ進み、そうでなければステップＳ２４へ進む。

（Ｓ２４）ステートメントがディレクティブ（ＨＴＭＬトランスレータ３５５に対する指示文）であれば、後述のようにその処理を行う。

（Ｓ２５〜Ｓ２８）ステートメントがコンテキスト・トークン（以下、単にトークンと称す。）であれば、後述のようにこれを対応する文字列で置換したものを該一時記憶領域に書き込み、そうでなければステートメントをそのまま該一時記憶領域に書き込む。次に、ステップＳ２２へ戻る。

ステップＳ２５、Ｓ２７又はＳ２８においては、次の処理も行われる。

（Ｓ２Ａ、Ｓ２Ｂ）該一時記憶領域に書き込む際に、該一時記憶領域が不足して書き込めない場合には、メモリマネージャ３０２を介し、ステップＳ２０で取得したサイズの所定％、例えば１０％だけ、一時記憶領域を拡大させる。

図６は、図５（Ａ）のステップＳ２７の詳細を示すフローチャートである。

（Ｓ３０）トークンからトークンボディを抽出する。ここにトークンとは例えば、#l_NetworkSetting#又は#f_GetIPAddress#のように、トークン開始記号#とトークン終了記号#とを含む文字列である。トークンのうち、#と#の間の文字列を、トークンボディと称す。トークンボディの先頭部分は、トークンの種類を示しており、先頭２文字がl_、f_である場合、それぞれ言語トークン、関数トークンであることを示し、先頭３文字がmsgである場合、メッセージ・トークンであることを示す。

（Ｓ３１）トークンボディの先頭２文字がl_であればステップＳ３２へ進みf_であればステップＳ３６へ進み、先頭３文字がmsgであればステップＳ３９へ進む。

（Ｓ３２）トークン名をハッシュ値に変換する。ここにトークン名とは、言語トークンにおけるトークンボディ中の３文字目以降の文字列である。

言語テーブルファイル４０は、各国語の言語テーブルファイルを有し、各テーブルは、トークン名のハッシュ値とトークン名の値である文字列とが対応付けられている。

（Ｓ３３）ステップＳ３２で変換されたハッシュ値をキーとして、指定された言語テーブルファイルの内容を検索し、対応する値を得る。例えば、トークン名がNetworkSetingの場合、指定された言語が英語であれば"Network Setting" が得られ、日本語であれば"ネットワーク設定"が得られる。

指定された言語は、最初は既定値であり、後述のようにして変更され、langクッキーに保持され、lang値により言語テーブルファイル４０内の１つが指定される。例えば、lang=0は英語を示し、lang=2は日本語を示す。

（Ｓ３４）トークンをその値で変換する。例えばlang=0で言語トークンが#l_NetworkSetting#である場合、このトークンが"Network Setting"に変換される。

ここで、処理関数群３５６内の各関数の引数及び返り値の形式は統一されており、任意の関数funcは、Ｃ言語でfunc(chr **IN,chr ***OUT)と表される。引数IN及び返り値OUTはともに文字列の１次元動的配列である。INよりもOUTの方に記号*が１つ多く付加されているのは、返り値OUTの配列要素数を関数側で変更できるようにするため、すなわち関数側で動的配列にすることができるようにするためである。

関数トークンの場合にはこれがその関数名の関数の返り値*OUT[0]に変換される。メッセージ・トークン#msgX#(Xは自然数）の場合、これが関数の返り値*OUT[X]に変換される。

（Ｓ３５）トークンの値にはトークンを含めることができ、この値にトークンが含まれている場合にはステップＳ３０へ戻り、そうでなければ図６の処理を終了する。

（Ｓ３６、Ｓ３７）関数トークンに引数が含まれていれば、引数を抽出する。

引数は、クエリ文字列と同じ形式で記述され、デリミタとしての&により複数の引数を関数トークンに含むことができる。関数トークンにおけるトークンボディの３文字目以降&まで（&が無い場合は最後まで）を関数名と称す。例えば、関数トークン#f_func&arg1=XXX&arg2=YYY&arg3=ZZZ#は、関数名がfunc、引数名arg1の値がXXX、引数名arg2の値がYYY、引数名arg3の値がZZZであることを示す。一般に、引き数名argXの値は引数IN[X]に代入される。

（Ｓ３８）関数トークンに含まれる関数名の関数に、関数トークンに含まれる引数を渡して、この関数を呼び出す。次にステップＳ３４へ進む。

この関数は、図２の処理関数群３５６に含まれている。関数は、ＤＢＭＳ３６を介してデータベース４１内のデータを読出し又は変更することができる。このデータには、画像形成装置の各種設定値やトナー残量、印刷枚数などの状態が含まれている。

（Ｓ３９）メッセージ・トークン#msgX#からインデックスＸ（Ｘ≧０）を取り出し、ステップＳ３４へ進む。

例えば、関数トークン#f_getDHCPMode#で識別される関数getDHCPModeが*OUT[0]="#l_dhcp_on#"を返し、ステップＳ３４で#f_getDHCPMode#が#l_dhcp_on#で置換され、ステップＳ３５からステップＳ３０へ戻る。lang=0の場合、ステップＳ３３で"DHCP ON"が取得され、ステップＳ３４で#l_dhcp_on#が"DHCP ON"で置換され、lang=2の場合、ステップＳ３３で"DHCP オン"が取得され、ステップＳ３４で#l_dhcp_on#が"DHCP オン"で置換される。

したがって、トークンを変数と言語の両方に応じて適当に変換することができるという効果を奏する。

他の例として、lang=2の場合、言語トークン#l_jobnum_msg#が"現在処理中のジョブは#f_getJobNum#個です。"に変換され、さらに、関数トークン#f_getJobNum#が*OUT[0]="10"に変換され、結果として、言語トークンl_jobnum_msg#が"現在処理中のジョブは10個です。"に変換される。lang=0の場合、言語トークン#l_jobnum_msg#が"#f_getJobNum# jobs are being processed"に変換され、さらに、関数トークン#f_getJobNum#が*OUT[0]="10"に変換され、結果として、言語トークンl_jobnum_msg#が"10 jobs are being processed"に変換される。

したがって、英語と日本語で文章中の変数の値"10" の位置が異なっても対応できるという効果を奏する。

本実施例１によれば、Ｗｅｂアプリケーション３５に含まれる複数の関数の返り値の形式が統一されているので、Ｗｅｂアプリケーションの全体構成を簡単化することができるとともにチームによるソフトウエア設計が容易になるという効果を奏し、機能を拡張又は変更した製品の開発期間短縮に寄与するところが大きい。

また、複数の関数のそれぞれが関数側で返り値を複数にすることができるので、１つの関数を実行して得られる情報を複数箇所でそれぞれ異なる目的に用いることができ、複雑な構成を簡単化することができるという効果を奏する。

ＤＢＭＳ３６は主に、設定値の変更に対する制限を課すものであり、値の範囲を制限したり、同時に設定値を変更できるクライアント数を一人に制限する。

図１４（Ａ）及び（Ｂ）は、Ｗｅｂクライアントマシーン２０と画像形成装置１０との間のメッセージ送受概略を示すシーケンス図である。

図１４（Ａ）において、Ｗｅｂクライアントマシーン２０のブラウザ上から画像形成装置１０のサイトのトップ頁を要求し、画像形成装置１０がこれに応答して、Ｗｅｂクライアントマシーン２０のブラウザ上に例えば図９（Ａ）に示すような画面が表示される。この画面のＨＴＭＬファイルは、言語選択のフォームと、印刷画面又はＦＡＸ送信画面への移動を指示するフォームとを有している。

この言語選択フォームにおいて、ユーザがプルダウンメニュー中の項目（言語）を選択し、Ｇｏボタンを押下すると、選択した言語の情報を含むリクエストメッセージが画像形成装置１０へ送信され、図２において、処理細振分部３５０からＧＥＴ処理制御部３５２へ処理が移り、次いでＨＴＭＬトランスレータ３５５により、トップページのテンプレートファイルに含まれる言語トークンが、選択した言語の文字列に変換され、これがＧＥＴ処理制御部３５２に返される。ＧＥＴ処理制御部３５２は、このリスポンスボディに、選択した言語のクッキーフィールドを付加し、ＨＴＴＰ処理スレッド３４１を介し残りのリスポンスヘッダを付加して、リクエストメッセージを完成させる。ＨＴＴＰ処理スレッド３４１は、このリスポンスメッセージを、ＯＳ３０及びＮＩＣ１８を介して、Ｗｅｂクライアントマシーン２０へ送信する。これにより、Ｗｅｂクライアントマシーン２０のブラウザには、選択した言語で図９（Ａ）に示す内容が表示される。このＨＴＴＰ処理スレッド３４１は、この送信後に消滅する。

Ｗｅｂクライアントマシーン２０から画像形成装置１０へ送信されるこれ以降のリクエストメッセージには、選択した言語を示すクッキーがリクエストヘッダに含まれるので、ブラウザに表示される文字列の言語が、選択したものとなる。

上記画面移動のフォームにおいて、ユーザがＦＡＸ送信画面のラジオボタンを選択し、移動ボタンを押下すると、リクエストＵＲＩにget.cgiを含むリクエストメッセージが画像形成装置１０へ送信され、上記同様にして画像形成装置１０によりリスポンスメッセージが生成され、これがＷｅｂクライアントマシーン２０に送信されて、ブラウザ上に図９（Ｂ）に示すような画面が表示される。

ユーザが、プルダウンメニューでＦＡＸ送信の宛先を選択し、次いで参照ボタンをクリックしてブラウザに対しファイル選択ダイアログを表示させ、Ｗｅｂクライアントマシーン２０のハードディスクに格納されているファイルを選択して送信ファイルを特定し、ＦＡＸ送信ボタンを押下すると、選択した宛先と送信ファイルの内容とを含むリクエストメッセージが画像形成装置１０へ送信される。

このリクエストメッセージに含まれるリクエスト行は例えば、POST /cgi-bin/image.cgi HTTP/1.1であり、ファイル名がimage.cgiであるので、図２の処理細振分部３５０からイメージ処理制御部３５４へ制御が移る。このメッセージのリクエストボディに含まれるクエリ文字列は例えば、func=sendFax&arg0=sendfile.pdf&arg1=1&okhtmfile=OK.html&failhtmfile=NG.htmlであり、これは上記Ｓ変数．クエリ文字列に格納されている。イメージ処理制御部３５４は、Ｓ識別子をイメージ処理部３５７へ渡し、イメージ処理部３５７はこれに基づいて、IN[0]="sendfile.pdf",IN[1]="1"を引数として処理関数群３５６中の関数sendFaxを呼出す。関数sendFaxでは、処理関数群３５６内の設定値取得関数を介して、データベース４１から又は後述のクッキーから、ＦＡＸ送信に使用する設定値を取得する。この点は、ＦＡＸ送信以外のイメージ処理についても同様である。関数sendFaxは、取得した設定値を用い、送信ファイルsendfile.pdfの内容をＦＡＸ送信用の画像データに変換し、アドレス帳内の１番目の宛先へＦＡＸを送信する。

上記送信が正常に行われたか否かの情報は、関数sendFaxにおいて返り値*OUT[0]に代入され、これがイメージ処理部３５７を介してイメージ処理制御部３５４に返される。イメージ処理制御部３５４は、上記クエリ文字列に基づき、*OUT[0]="OK"であれば、テンプレートファイルOK.htmlのパスをＧＥＴ処理制御部３５２に与えてOK.htmファイルを生成させ、*OUT[0]="NG"であれば、テンプレートファイルNG.htmlのパスをＧＥＴ処理制御部３５２に与えてNG.htmファイルを生成させる。本実施例では、テンプレートファイルの拡張子をhtmlとし、これに基づいて作成されたファイルの拡張子をhtmとしている。

例えば図１１（Ａ）に示す如く、テンプレートファイルOK.htmlにはメッセージ・トークン#msg1#が含まれ、図１１（Ｃ）に示す如く、テンプレートファイルNG.htmlにはメッセージ・トークン#msg1#及び#msg2#が含まれており、メッセージ・トークン#msg1#及び#msg2#はＨＴＭＬトランスレータ３５５による図６のステップＳ３９及びＳ３４の処理により、それぞれ*OUT[1]及び*OUT[2]で置換される。これにより、テンプレートファイルOK.html及びNG.htmlからそれぞれ図１１（Ｂ）及び（Ｄ）に示すようなHTMLファイルOK.htm及びNG.htmがＧＥＴ処理制御部３５２により生成される。いずれの場合も、ＧＥＴ処理制御部３５２及びＨＴＴＰ処理スレッド３４１を介しリスポンスヘッダがこれに付加されて、Ｗｅｂクライアントマシーン２０へ送信される。

ＧＥＴ処理制御部３５２はまた、設定に応じて、送信完了又は送信失敗をユーザに通知するため、HTMLファイルOK.htm又はNG.htmの内容の電子メールを作成して、メール送信サーバ３３のメールボックスへ格納させる（図１０参照）。

本実施例１によれば、処理関数群３５６内の各関数の返り値の形式が上述のように統一されているので、同一テンプレートファイルOK.html及びNG.htmlに基づき、ＦＡＸ送信結果以外のイメージ処理結果又は設定値変更結果を示すリスポンスメッセージボディも作成することができ、構成が簡単になる。

また、処理の種類毎に異なるテンプレートファイルを用いても、関数の返り値とメッセージ・トークンとが統一的に対応づけられているので、例えば図１１（Ｅ）に示すように、処理結果のテンプレートファイルを容易に作成できるという効果を奏する。図１１（Ｆ）は、図１１（Ｅ）に示すテンプレートファイルOK.htmlに基づいて作成されたHTMLファイルOK.htmを示す。

図９（Ｂ）に戻って、プルダウンメニューに含まれる宛先の数は、後述する図９（Ｃ）画面を用いてユーザが追加又は削除することにより変化する。このような変化に対応して、図１２（Ａ）に示すようなテンプレートファイルが用いられる。このテンプレートファイルには、ｆｏｒディレクティブ<!-- for f_getCountOfAddress -->とｅｎｄ＿ｆｏｒディレクティブ<!-- end_for -->とが含まれる。ディレクティブは、その開始記号<!--及び終了記号-->で識別される。

ｆｏｒディレクティブとｅｎｄ＿ｆｏｒディレクティブとの間に配置されたステートメントに対する処理は、ｆｏｒディレクティブに含まれる繰り返し回数f_getCountOfAddressだけ繰り返される。この繰り返し回数は、定数であってもよいが、この例では、トークン識別記号#を省略した関数トークンf_getCountOfAddressが変数として用いられている。この関数トークンで識別される関数getCountOfAddressにより、アドレス帳に含まれる宛先の数が取得されて、その返り値*OUT[0]で関数トークンが置換される。

オプションタグに含まれるトークン"#f_m_Count&arg0=0#"中のf_m_は、関数Countが多価関数であることを示している。この関数は、上述の引数及び返り値の形式が統一された関数と同一であるが、ｆｏｒディレクティブでの繰り返しが何回目であるかを示す内部カウンタｉの値により、関数の取り扱いが異なる。カウンタｉが初期値０（繰り返し１回目）である場合のみこの関数が呼び出され、ｉ≧０の各ｉについて多価関数トークン"#f_m_Count&arg0=0#"が*OUT[i]で置換される。これらのことは、アドレス帳内のｉ番目の宛先を*OUT[i]に代入する多価関数トークン#f_m_getAddress#についても同様である。

ディレクティブは、上述の図５（Ａ）におけるステップＳ２５で処理される。図７は、このステップＳ２５での、主にｆｏｒディレクティブに対する処理の詳細を示すフローチャートである。

（Ｓ４０）ｆｏｒディレクティブ（for DIR）であればステップＳ４１へ進み、そうでなければステップＳ４Ｃへ進む。

（Ｓ４１）繰り返しカウンタｉに初期値０を代入し、また、処理対象のステートメントがテンプレートファイル内の何行目であるかを示す行カウンタＳＬＣの値をＳＬＣ０に代入して保存する。

（Ｓ４２）テンプレートファイルから、カウンタＳＬＣが示す行のステートメントを読み込み、この行カウンタを１だけインクリメントする。

（Ｓ４３）このステートメントに多価関数トークンが含まれていればステップＳ４４へ進み、そうでなければステップＳ４７へ進む。

（Ｓ４４、Ｓ４５）ｉ＝０のときのみ、処理関数群３５６内の、多価関数トークンで識別される関数を呼び出す。この際、多価関数トークンに引数が含まれていればこれを抽出してこの関数に引き渡す。例えば多価関数トークンが"#f_m_Count&arg0=0#"である場合、IN[0]="0"を引き渡して関数Countを呼び出す。関数Countの*OUT[i]は、in[0]を数値に変換しこれに値ｉを加えたものを文字型に変換したものである。

（Ｓ４６）多価関数トークンを*OUT[i]で置換し、ステップＳ４８へ進む。

（Ｓ４７）ステートメントに応じた処理を行う。

（Ｓ４８）end_forディレクティブであればステップＳ４９へ進み、そうでなければステップＳ４２へ戻る。

（Ｓ４９）繰り返しカウンタｉを１だけインクリメントする。

（Ｓ４Ａ）ｉの値がｆｏｒディレクティブ内で指定された値ｉｍａｘに等しければ図７の処理を終了し、そうでなければステップＳ４Ｂへ進む。

（Ｓ４Ｂ）ステートメント行カウンタＳＬＣにＳＬＣ０を代入し、ステップＳ４２へ戻る。

（Ｓ４Ｃ）他のディレクティブに対する処理を行って図７の処理を終了する。

このような処理を含む図５（Ａ）の処理により、図１２（Ａ）に示すテンプレートファイルに基づいて、図１２（Ｂ）に示すようなＨＴＭＬファイルがリスポンスボディとしてＨＴＭＬトランスレータ３５５により生成される。

図１２（Ａ）と図１２（Ｂ）とを比べると、簡単化されたテンプレートファイルで任意の項目数のプルダウンメニューを作成可能であることが明らかである。上記ｆｏｒディレクティブは、Ｃ言語等の命令文で用いられる他のｗｈｉｌｅ文やｄｏ−ｌｏｏｐなどの制御ループにも同様に適用可能である。

次に、ＳＥＴ処理の具体例として、アドレス帳内の項目（宛先）を追加、変更又は削除する処理を説明する。

図１４（Ｂ）は、図９（Ａ）の画面から図９（Ｂ）の画面へ移った後、「アドレス帳を開く」ボタンをクリックして図９（Ｃ）の画面へ移り、編集処理を行い、これが成功した場合を示す。

「アドレス帳を開く」ボタンをクリックして得られるリクエストメッセージに対応したリスポンスメッセージは、上述の図９（Ａ）で「移動」ボタンをクリックして得られるリクエストメッセージに対応したリスポンスメッセージと同様にして作成される。このメッセージのリスポンスボディは、図１３（Ａ）に示すテンプレートファイルに基づいてＨＴＭＬトランスレータ３５５により生成され、例えば図１３（Ｂ）に示すものである。図１３（Ａ）中のｆｏｒディレクティブ及び多価関数トークンは、図１２（Ａ）中のものと同様である。

図９（Ｃ）において、リストボックス内の項目をクリックして選択すると、この項目が反転表示されるとともに、クライアンドサイドのオンクリックイベントハンドラが呼び出されて、選択した項目が宛先ボックス内に表示される。ユーザが、この状態で「削除」のラジオボタンを選択し、または宛先ボックス内の文字列を変更して「変更」のラジオボタンを選択し、実行ボタンを押下すると、宛先ボックス内のデータと、選択した「変更」又は「削除」を示すデータと、図１３（Ｂ）に示すＦＯＲＭタグの属性値とを含むリクエストメッセージが、画像形成装置１０へ送信される。

画像形成装置１０では、このメッセージに対応した上述のＳ識別子を引数としてＳＥＴ処理制御部３５３が起動され、処理関数群３５６内の対応する関数及びＤＢＭＳ３６を介してデータベース４１内のアドレス帳データが更新又は削除される。

また、ユーザが、追加しようとする宛先を図９（Ｃ）の宛先ボックスに記入し、「追加」ラジオボタンを選択して実行ボタンを押下すると、前記と同様に、この宛先と、追加を示すデータと、図１３（Ｂ）に示すＦＯＲＭタグの属性値とを含むリクエストメッセージが画像形成装置１０へ送信され、ＳＥＴ処理制御部３５３、処理関数群３５６及びＤＢＭＳ３６を介しデータベース４１内のアドレス帳データに、この宛先が追加される。

設定値変更の他の例として、図９（Ｂ）に示す画面でＦＡＸ送信設定値ボタンを押下すると、そのリクエストメッセージに対応して、図１０に示すような画面を表示するためのリスポンスメッセージが画像形成装置１０からＷｅｂクライアントマシーン２０へ送信される。この画面には、ＦＡＸ受信までのコール回数選択ドロップダウンリスト、送信完了／失敗通知手段選択ドロップダウンリスト及びその宛先並びにアドレス帳選択ドロップダウンリストが表示されている。通知手段選択ドロップダウンリストには「ｅ−ｍａｉｌ」、「携帯電話」、「無し」の項目がある。

ここで、図２のデータベース４１には、クライアントのＩＤと通知手段ごとの宛先アドレスとが登録されており、図１０で宛先が「登録先」となっている場合には、この登録された宛先が用いられる。図１０で選択されたアドレス帳は、図９（Ｂ）及び（Ｃ）で用いられる。

設定値変更の種類には、マイ設定と共通設定とがある。マイ設定はクライアント毎の設定であり、共通設定は各クライアントに共通の設定である。

マイ設定は、共通設定の一部または全部を、共通設定を変更せずにクッキーによりユーザ毎に設定値を書き換えるものである。このクッキーの値は、処理関数群３５６内の設定値取得関数で用いられる。すなわち、この関数は、該当するものがクッキーにあればその値を取得し、無ければＤＢＭＳ３６を介しデータベース４１内の該当する設定値（共通設定値）を取得する。

共通設定は、データベース４１に格納された設定であり、クッキーにより書き換えられない項目の設定値として用いられる。すなわち、処理関数群３５６内の設定値取得関数は、マイ設定でクッキーにより個別に変更されない項目については、データベース４１内の共通設定値を取得する。

図１０に示す「共通」は、マイ設定において共通設定の値が用いられ（クッキーを使用しない）又は共通設定において変更しないことを示している。共通設定値の変更は、管理者権限でログインしている場合のみ許可される。管理者権限でログインしているか否かは、後述の認証クッキーで判定される。

なお、管理者権限でログインしている場合、処理関数群３５６内の設定値取得関数はデータベース４１内の共通設定値を取得する。

「変更」ボタンを押下すると、図１０に示す情報を含むリクエストメッセージが画像形成装置１０へ送信され、図２のＳＥＴ処理制御部３５３及びこれに関係した部分で、図８に示すような処理が行われる。

（Ｓ５０）ＳＥＴ処理制御部３５３は、Ｓ変数に基づいて例えば、IN[0]="my"（「マイ設定」）,IN[1]="common"（ＦＡＸ受信までのコール回数が「共通」）,IN[2]="e-mail"（通知手段が「e-mail」）,IN[3]="same"（宛先が「登録先」）,IN[4]="DesignDepartment"（アドレス帳が「DesignDepartment」） とし、ＦＡＸ送信設定値変更関数を呼び出す。

（Ｓ５１）ＦＡＸ送信設定値変更関数は、IN[0]に基づいて、共通設定とマイ設定のどちらが選択されたかを判定し、前者と判定した場合にはステップＳ５２へ進み、後者と判定した場合にはステップＳ５７へ進む。

（Ｓ５２）ＦＡＸ送信設定値変更関数は、認証クッキーに基づいて、管理者権限でログインしているか否かを判定し、肯定判定した場合にはステップＳ５３へ進み、そうでなければステップＳ５６へ進む。

（Ｓ５３）ＦＡＸ送信設定値変更関数は、IN[1]〜IN[4]の値で、ＤＢＭＳ３６を介しデータベース４１に格納されている対応する設定値を更新する。但し、IN[1]="common"であれば、ＦＡＸ受信までのコール回数を更新しない。また、IN[3]="same"であれば、通知先を更新しない。

（Ｓ５４）ＦＡＸ送信設定値変更関数は、IN[3]についてＤＢＭＳ３６が設定値変更を許可した場合には*OUT[0]に"OK"を代入し、禁止した場合には*OUT[0]に"NG"を代入するとともにその原因を示す文字列をＤＢＭＳ３６から取得して*OUT[1]に代入する。設定値変更関数からＳＥＴ処理制御部３５３にリターンする。

（Ｓ５５）ＳＥＴ処理制御部３５３は、*OUT[0]が"OK"、"NG"又は"NotAuth"であればそれぞれ、テンプレートファイルOK.html、NG.html又はNotAuth.htmlのパスを引数としてＧＥＴ処理制御部３５２を呼び出す。

ＧＥＴ処理制御部３５２はこれに応答して、ＨＴＭＬトランスレータ３５５を介しテンプレートファイルに基づいてＨＴＭＬファイルを作成させ、このファイルにリスポンスヘッダの一部を付加する。作成されたNotAuth.htmには、そのフォームにユーザのＩＤ及びパスワードの入力ボックスが記述されている。ＧＥＴ処理制御部３５２は、ＨＴＴＰ処理スレッド３４１を介して残りのリスポンスヘッダを付加させ、リスポンスメッセージとしてＷｅｂクライアントマシーン２０へ送信させ、図８の処理を終了する。

なお、ユーザのＩＤ及びパスワードは、画像形成装置１０のサイトのトップ頁でも入力させるようにしてもよい。

（Ｓ５６）*OUT[0]に"NotAuth"を代入し、ステップＳ５５へ進む。

（Ｓ５７）上記Ｓ識別子で識別される構造体変数の対応する要素の値、すなわち図１０の設定値の名前とその値の組をそれぞれ、値が「共通」又は「登録先」であるものを除き、クッキーにセットする。このクッキーは、ステップＳ５５において、ヘッダフィールドとされる。

（Ｓ５８）IN[1]が"common"でない場合、文字数等が条件を満たしているか否かを判定し、肯定判定した場合には*OUT[0]に"OK"を代入し、否定判定した場合には*OUT[0]に"NG"を代入するとともにその原因を示す文字列を*OUT[1]に代入する。次にステップＳ５５へ進む。

このような処理により、マイ設定と共通設定とを簡単かつ容易に行うことができるとともに、ユーザに応じたサービスを提供することができるという効果を奏する。

また、ＳＥＴ処理制御部３５３での処理が成功したか否かに応じて、ＧＥＴ処理制御部３５２を介しリスポンスボディを生成させるので、ＳＥＴ処理でＧＥＴ処理を有効利用してソフトウエア構成を簡単化することができるという効果を奏する。

なお、共通設定は、管理者権限で操作パネル１５を操作して直接変更することもできる。

また、ステップＳ５２で正当な権限がないと判定され、ブラウザ上のNotAuth.htm表示画面でユーザのＩＤ及びパスワードが入力されて、これに対応したデータがリクエストメッセージとして画像形成装置１０へ送信される。このメッセージのリクエスト行は例えば、POST /cgi-bin/login.cgi HTTP/1.1であり、上述のＳ識別子を引数として、図２において認証制御部３５１が起動される。

認証制御部３５１は、Ｓ変数の要素に格納されているユーザの前記データを引数として、処理関数群３５６内の関数Authを呼び出す。この関数は、ＤＢＭＳ３６を介し、このデータに対応したデータがデータベース４１内に登録されているか否かを判定し、肯定判定した場合には*OUT[0]に"OK"を代入し、否定判定した場合には*OUT[0]に"NotAuth"を代入する。認証制御部３５１は、*OUT[0]の内容に応じて、ＳＥＴ処理の場合と同様の処理を行う。ただし、認証制御部３５１は、*OUT[0]="OK"の場合、認証されたこと及び管理者権限が有るか否かを示す認証クッキー、例えば、Set-Cookie: login=admin_1068625073を、リスポンスヘッダフィールドとして、リスポンスボディに付加する。Ｗｅｂクライアントマシーン２０がこのクッキーを受け取った後は、Ｗｅｂクライアントマシーン２０から画像形成装置１０へリクエストメッセージが送信される毎に、これに該クッキーが含まれる。

本実施例１によれば、Ｗｅｂアプリケーション３５において、処理細振分部３５０により、クライアントからのリクエストＵＲＩに含まれるパスのファイル名に基づいて複数の処理制御部３５１〜３５４のいずれかに制御を移させ、複数の処理制御部３５１〜３５４のそれぞれが直接又は間接的に処理関数群３５６の中の少なくとも１つを介して処理を行わせるので、処理関数群３５６に新たな関数を追加したり、処理関数群３５６の中の１つ以上の関数を変更したり、複数の処理制御部３５１〜３５４に新たな処理制御部を追加することにより、容易に機能を拡張又は変更することができるという効果を奏し、新製品の開発期間短縮に寄与するところが大きい。

なお、本発明には外にも種々の変形例が含まれる。

例えば、上記実施例ではＣＧＩを用いた場合を説明したが、本発明はＣＧＩに限定されない処理の手法に特徴があるので、ＣＧＩの替わりにＡＳＰやＪＳＰなどを用いた構成であってもよい。

また、関数の返り値は、関数の値であってもよい。関数は、関数とサブルーチンを区別するプログラム言語におけるサブルーチン、又はクラスのメンバ関数などであってもよい。引数は、メンバ変数を介して関数へ引き渡す構成であってもよい。

さらに、テンプレートファイルはＨＴＭＬファイルを作成するためのものに限定されず、ＸＭＬファイルなどの他のファイルを作成するためのものであってもよい。

また、メッセージ・トークンは、メッセージ以外にも利用可能である。

また、図３のステップＳ３において、パスに含まれるファイル名の拡張子がテンプレートファイルであることを示している場合に、ステップＳ２へ進む構成であってもよい。図４において、ファイル名拡張子が"cgi"でなければステップＳ１３へ進むようにしてもよい。フォースファイル項目のパス及びこれと比較されるパスは、実パスであってもよい。

さらに、図３と図４の処理を１つにまとめた構成や、ＤＢＭＳ３６を用いない構成であってもよい。メインＷｅｂサーバ３４、Ｗｅｂアプリケーション３５及びＤＢＭＳ３６はそれぞれプロセスとして動作する構成であってもよい。

また、汎用のｉｎｅｔｄ３１及びｈｔｔｐｄ３２を用いずに、これらの機能をＨＴＴＰ処理スレッド生成部３４０に含めた構成であってもよい。

また、上記実施例では情報処理装置が画像形成装置である場合を説明したが、本発明はこれに限定されず、本発明は特許請求の範囲に記載された構成を含むものであればよい。

主に画像形成装置のソフトウエア構成を示す機能ブロック図である。 主に図１中のＷｅｂアプリケーションの構成を示す機能ブロック図である。 図１中の処理粗振分部による処理を示すフローチャートである。 図２中の処理細振分部による処理を示すフローチャートである。 （Ａ）は図２中のＨＴＭＬトランスレータによる処理を示すフローチャートであり、（Ｂ）はＨＴＭＬテンプレートファイルの各々についてそのパスとファイルサイズに対応したバイト数とを対応させたバッファサイズテーブルの説明図である。 図５（Ａ）中のステップＳ２７の詳細を示すフローチャートである。 図５（Ａ）中のステップＳ２５での、主にｆｏｒディレクティブに対する処理の詳細を示すフローチャートである。 図１０に示すブラウザ上の「変更」ボタン押下に応答した、画像形成装置のＳＥＴ処理制御部及びこれに関係した部分での処理を示すフローチャートである。 （Ａ）〜（Ｃ）はそれぞれ、クライアントのブラウザ上に表示されるトップ頁画面、ＦＡＸ送信画面及びアドレス帳編集画面を示す図である。 クライアントのブラウザ上に表示されるＦＡＸ送信設定値変更画面を示す図である。 （Ａ）は処理成功の場合に汎用される、メッセージ・トークンを含んだＨＴＭＬテンプレートファイルの説明図、（Ｂ）はこのＨＴＭＬテンプレートファイルに基づいてＨＴＭＬトランスレータにより生成されたＨＴＭＬファイルの説明図、（Ｃ）は処理失敗の場合に汎用される、メッセージ・トークンを含んだＨＴＭＬテンプレートファイルの説明図、（Ｄ）はこのＨＴＭＬテンプレートファイルに基づいてＨＴＭＬトランスレータにより生成されたＨＴＭＬファイルの説明図、（Ｅ）はＦＡＸ送信処理成功の場合に用いられる、メッセージ・トークンを含んだＨＴＭＬテンプレートファイルの説明図、（Ｆ）はこのＨＴＭＬテンプレートファイルに基づいてＨＴＭＬトランスレータにより生成されたＨＴＭＬファイルの説明図である。 （Ａ）は図９（Ｂ）に示す画面に対応したＨＴＭＬファイルを作成するための、多価関数トークンを含むＨＴＭＬテンプレートファイルの説明図、（Ｂ）はこのＨＴＭＬテンプレートファイルに基づいてＨＴＭＬトランスレータにより生成されたＨＴＭＬファイルの説明図である。 （Ａ）は図９（Ｃ）に示す画面に対応したＨＴＭＬファイルを作成するための、多価関数トークンを含むＨＴＭＬテンプレートファイルの説明図、（Ｂ）はこのＨＴＭＬテンプレートファイルに基づいてＨＴＭＬトランスレータにより生成されたＨＴＭＬファイルの説明図である。 （Ａ）は図９（Ａ）及び（Ｂ）に関係した、Ｗｅｂクライアントマシーンと画像形成装置との間のメッセージ送受概略を示すシーケンス図、（Ｂ）は図９（Ａ）〜（Ｃ）に関係した、Ｗｅｂクライアントマシーンと画像形成装置との間のメッセージ送受概略を示すシーケンス図である。 本発明の実施例１に係る画像形成システムのハードウエア概略ブロック図である。

符号の説明

１０ 画像形成装置
１１ ＭＰＵ
１２ インターフェイス
１３ ＰＲＯＭ
１４ ＤＲＡＭ
１５ 操作パネル
１６ プリンタ
１７ スキャナ
１８ ＮＩＣ
１９ ＦＡＸモデム
２０、２１ Ｗｅｂクライアントマシーン
２８ 公衆回線網
２９ ＦＡＸ装置
３０ ＯＳ
３００ ＮＩＣドライバ
３０１ メモリマネージャ
３１ ｉｎｅｔｄ
３２ ｈｔｔｐｄ
３３ メール送信サーバ
３４ Ｗｅｂサーバ
３４０ ＨＴＴＰ処理スレッド生成部
３４１ ＨＴＴＰ処理スレッド
３４２ 処理粗振分部
３４３ 静的リソース処理部
３５ Ｗｅｂアプリケーション
３５０ 処理細振分部
３５１ 認証制御部
３５２ ＧＥＴ処理制御部
３５３ ＳＥＴ処理制御部
３５４ イメージ処理制御部
３５５ ＨＴＭＬトランスレータ
３５６ 処理関数群
３５７ イメージ処理部
３６ ＤＢＭＳ
３７ 静的リソース
３８ ＨＴＭＬテンプレートファイル
３９ バッファサイズテーブル
４０ 言語テンプレートファイル
４１ データベース
４２ コンフィグレーションファイル

Claims (4)

1. プロセッサと、
   プログラムと設定データとテンプレートファイルとが格納され、該プロセッサに結合された記憶手段と、
   を備え、該プログラムがＷｅｂサーバとＷｅｂアプリケーションとを含む画像形成装置において、
   該設定データには実質的に仮想ファイルパス又は仮想ディレクトリパスが含まれ、
   該Ｗｅｂサーバは、該プロセッサに対し、リクエストＵＲＩに含まれるファイル名の拡張子が特定のものであるか否かという第１判定を行わせ、該第１判定で否定判定した場合に、該リクエストＵＲＩに含まれるパスが該設定データ中の仮想ファイルパスと一致し又は該設定データ中の仮想ディレクトリパス以下のものであるか否かという第２判定を実質的に行わせ、該第１判定又は該第２判定で肯定判定した場合には該Ｗｅｂアプリケーションに制御を移す第１振分部を有し、
   該Ｗｅｂアプリケーションは、
   ＧＥＴ処理制御部及びイメージ処理制御部を含む複数の処理制御部と、
   該プロセッサに対し、指定されたテンプレートファイル内のコンテキスト・トークンを対応する文字列で置換させてリスポンスメッセージボディを作成させるトランスレータと、
   該プロセッサに対し、該ファイル名の本体に基づいて、該複数の処理制御部のいずれかに制御を移させる第２振分部と、
   を有し、
   該ＧＥＴ処理制御部は、該プロセッサに対し、リクエストメッセージに含まれるクエリ文字列で定まるテンプレートファイル又は指定されたテンプレートファイルを指定して該トランスレータを呼び出させ、
   該イメージ処理制御部は、該プロセッサに対し、該クエリ文字列に含まれる関数及びその引数に基づいて該関数を呼び出すことにより該引数で指定されたイメージファイルの内容を処理させ、該クエリ文字列で指定されたテンプレートファイルのうちこの内容処理の成否に応じて定まるものを指定して該ＧＥＴ処理制御部に制御を移させる、
   ことを特徴とする画像形成装置。
2. 該第２振分部は、該プロセッサに対し、該ファイル名の本体が所定の複数の文字列のいずれでもないと判定した場合には該ＧＥＴ処理制御部に制御を移させる、
   ことを特徴とする請求項１に記載の画像形成装置。
3. 該Ｗｅｂサーバはさらに、該プロセッサに対し、該リクエストＵＲＩに含まれるパスの静的リソースをリクエストボディとして取得させる静的リソース処理部を有し、
   該第１振分部は該プロセッサに対し、該第１判定で否定判定し且つ該第２判定で否定判定した場合に、該静的リソース処理部に制御を移させる、
   ことを特徴とする請求項１又は２に記載の画像形成装置。
4. 該第１振分部と該第２振分部と該複数の処理制御部とが同一プロセス内で実行されることを特徴とする請求項１乃至３のいずれかに記載の画像形成装置。

Images