JP4580008B2

JP4580008B2 - ネットワークシステム及びその制御方法

Info

Publication number: JP4580008B2
Application number: JP2008209258A
Authority: JP
Inventors: 清隆三浦; 晃上田; 恒博塚田; 保幸津久井; 敬松下; 正樹田村
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1999-01-29
Filing date: 2008-08-15
Publication date: 2010-11-10
Anticipated expiration: 2020-01-20
Also published as: JP2009020898A

Description

本発明は、例えば電話網等のネットワークを介して接続されたクライアント及びサーバを含むネットワークシステム及びその制御方法に関するものである。

インターネットの急速な発展とＷｅｂサーバの林立に伴い、業務処理のＷｅｂ化が推進されている。Ｗｅｂサーバとは、ＨＴＴＰ(Hyper Text Transfer Protocol)やＦＴＰ(File Transfer Protocol)等をサポートする、ネットワークに接続されたコンピュータなどを指し、ＵＲＬ(Uniform Resource Locator)で指定された、ＨＴＭＬ(Hyper text Markup Language)などで記述された文書データファイル等を、要求に応じてネットワーク上のクライアントに送信することができる。

一方、パーソナルコンピュータ等のクライアントコンピュータでは、ＨＴＭＬで記述されたデータ（ＨＴＭＬ文書）を表示する機能を持つＷｅｂブラウザと呼ばれるアプリケーションプログラム（単にブラウザとも呼ぶ）を用いて、Ｗｅｂサーバから受信したＨＴＭＬ文書を表示する。ブラウザは、単にＨＴＭＬ文書を表示するのみならず、ＨＴＭＬの記述に従って、画面上でデータを入力させ、それをＷｅｂサーバに返送する機能を持つのが普通である。なお、Ｗｅｂ化とは、クライアントからＵＲＬを指定してサーバとのデータ交換を行えるようにすることを指す。

Ｗｅｂ化された業務システムでは、クライアントコンピュータは情報の表示及び入力が可能なブラウザを搭載し、オペレータはブラウザをユーザインターフェースとして表示及び入力等の業務処理を遂行する。この際には、クライアント上のブラウザから入力された情報をＷｅｂサーバが受け取り、サーバ内で加工して再びブラウザに送信し、そこで表示を行う等の動作を必要なだけ行って結果を得るというような手順で業務が遂行される。

このように、Ｗｅｂブラウザにサーバからドキュメントや画像等のデータを渡す場合には、Ｗｅｂサーバのファイルシステムにおける、クライアントからアクセス可能な特定のディレクトリ（ＨＴＴＰ用語でのドキュメントルートを指す。以下ディレクトリと呼ぶ）にこれらのデータファイルを置く。そのファイルをクライアントが要求したなら、クライアントにはそのファイルのＵＲＬを渡す。クライアントではそのＵＲＬを指定してＦＴＰなどを用いれば、所望のファイルがサーバからクライアントに送信される。

特開平１０−２３２８９９号公報

このようなブラウザ経由の業務処理において問題となっているのは、通常の業務処理には欠かせないプリント処理に関する部分である。プリント処理における第１の問題点として、特に帳票等、フォーマットに従った美しいプリントを行うことが、ブラウザを用いては実現できなかった。通常のブラウザはプリント機能を有するものの、この機能は、ブラウザによって画面に表示されたイメージのハードコピーを、ブラウザ配下のプリンタでプリントするものである。このプリント方式では、用紙サイズを越えるイメージの印刷や、複数ページの印刷におけるページ区切り等の問題もあり、美しいプリントは得られない。また、表示されるデータがドットイメージデータを含む場合、そのデータを美しく印刷することは到底望むことはできない。

第２に、クライアントはネットワーク上に分散しており、多くのクライアントがひとつのサーバに対して処理の要求を発行すれば、サーバの負荷が高まり、クライアントの待ち時間が長くなるばかりか、甚だしい場合には、サーバがダウンすることすらあり得る。

特に、このようなネットワークシステムにおいては、クライアントからの要求に対するサーバからの応答データは、要求データが伝送されたネットワーク経路と同じ経路を通ってクライアントに返され、また、プリントデータである応答データは、要求データに比較すると、そのサイズは圧倒的に大きい場合が多い。このため、クライアントからの要求が殺到すると、サーバからの応答データの通信量がネットワークを占有してしまい、サーバに処理余力があるにもかかわらず、クライアントからの要求がサーバに届きにくくなる。

第３に、サーバにおける障害が発生した場合、サービスが全面的に停止してしまうことになり、業務処理の停止という重大な事態を引き起こすこともあり得るという問題点がある。

第４に、クライアント配下のプリンタからサーバから受信したデータをプリントする場合、クライアント配下に複数のプリンタが接続されている場合は、印刷すべきデータがデフォルトプリンタから正しく印刷できるとは限らないという問題があった。

第５に、従来のプリント方式では、用紙サイズを越えるイメージを含む場合、複数ページにまたがる場合等の印刷において、ページ区切りによって１つの画像が複数ページに分割されてしまったり、さらに分割される位置が印字される内容とは無関係であるため、数字の上下が別の用紙に印字されてしまう等、使い勝手の良い、美しい出力結果が得られていなかった。

さらに、この方式では、Ｗｅｂサーバのディレクトリに置かれたファイルは、そのサーバと接続可能なあらゆるクライアントから参照可能となってしまい、情報の安全性に問題がある。特に、Ｗｅｂサーバとクライアント間が広域のネットワークである場合など、通信される情報を秘匿する必要がある。特に、業務処理上重要なデータのプリント処理の場合は、処理を要求したユーザ以外の他者によってプリントできないような機能が必要である。また、送信されるデータの種類によっては秘匿性よりも処理速度を要求する場合もあるので、選択的に秘匿すべきである。

従来、通信される情報を秘匿する場合には、盗聴されにくいプロトコル技術が用いられているが、システム全体で対応しないと利用することができないという問題がある。
例えば、ネットワークプリンタをこのようなネットワークプリントシステムに使用しようとした場合、そのネットワークプリンタ自身が暗号・復号化のプロトコルに対応していないと利用できない。

加えて、印刷しようとする帳票のフォーマットがある期日より無効になる、もしくは変更されるような場合等において、旧式フォーマットの利用に制限をかけ、ユーザが印刷しないように促す機能が望まれている。

また、Ｗｅｂブラウザの動作設定によっては、Ｗｅｂサーバ上でのファイル名やＵＲＬを基本としたキャッシュ機能を持っている場合がある。このような場合、そのＷｅｂブラウザを使用してサーバにデータの要求を行うと、例えばサーバがファイル名を変えないままその内容を更新しているような場合、Ｗｅｂブラウザではキャッシュしたファイルを開いてしまうために、最新のファイルを入手できないといった問題も生じ得る。

さらに、サーバからクライアントに送信された印刷データをクライアント側で印刷する際に、印刷させようとしているプリンタが他からの印刷要求等でビジー状態にある時、その印刷処理が終了するまで次の印刷を待たなければならない。少しでも早く印刷結果を得たいような場合では、近くに設置されている他のプリンタに処理を移管することで、クライアント側の印刷処理を分散することが望まれている。また、複数存在するプリンタの中からユーザが印刷しようとする帳票の種類に応じて最適な条件を自動的に選択する機能が望まれている。

本発明は上記問題点に鑑みてなされたもので、Ｗｅｂブラウザを用いて高品質の画像を出力できるネットワークプリントシステム及び情報処理及びその制御方法を提供することを目的とする。

また、サーバの負荷を軽減してクライアントを待たせず、またシステムダウンの可能性を低減したネットワークプリントシステム及び情報処理装置及びその制御方法を提供することを目的とする。

また、サーバが一部停止しても、全面的に処理を停止させないネットワークプリントシステム及びネットワークサーバ装置及びその制御方法を提供することを目的とする。

また、サーバから受信したデータに適したプリンタから印刷を行うネットワークプリントシステム及び情報処理装置及びその制御方法を提供することを目的とする。

本発明はまた、一般のクライアントから参照できない場所にファイルを保存し、そのファイルを作成する都度そのファイルの作成を指示したクライアントにそのファイルを送信することで、不特定のクライアントからのデータの参照を不可能とし、また、最新のファイルをクライアントに渡すことのできるネットワークプリントシステム及び情報処理装置及びその制御方法を提供することを目的とする。

本発明は、また、Ｗｅｂサーバからクライアントに対して送信されるプリント画像を暗号化する手段をサーバ側に設け、復号化する手段をクライアント側の付加的なプログラムに設けることによって、より秘匿された通信を可能にしたネットワークプリントシステム及びその制御方法を提供することを目的とする。

本発明は、また、印刷処理の有効期限、印刷可能な回数といった制限情報を保持するデータベースを設けることにより、帳票データの使用を制限する事が可能なネットワークプリントシステム及びその制御方法を提供することを目的とする。

本発明は、また、クライアント側に設置される各プリンタの処理状況に応じて選択したプリンタに印刷を指示することにより、印刷結果が早く得られるネットワークプリントシステム及びその制御方法を提供することを目的とする。

さらに本発明の別の目的は、印刷しようとしている帳票データを解析し、過去の印刷履歴を元に最適の印刷条件を自動的に選択することにより、設定に関するユーザの負担を軽減するとともに、設定の誤りを防止することのできるネットワークプリントシステム及びその制御方法を提供することにある。

さらに本発明の別の目的は、サーバからの応答データの通るネットワーク経路を、要求データの通るネットワーク経路と異なる経路選択を可能にすることにより、クライアントからの要求が届きにくくなることを抑制したネットワークプリントシステム及びその制御方法を提供することにある。

上記目的を達成するために、本発明は次のような構成からなる。すなわち、
サーバとクライアントを接続したネットワークプリントシステムであって、
クライアント装置は、サーバから受信した、可変データを表示用の形式で記述した画像を表示するとともに、表示されたデータの印刷を指示する指示手段を有し、
サーバ装置は、
テンプレートデータを格納する格納手段と、
前記クライアント装置からの指示及びクライアント装置に送信したデータに応じて、前記格納手段からテンプレートデータを読み出す手段と、
読み出されたテンプレートデータと前記クライアント装置で表示されている可変データとを合成して印刷データを生成する生成手段と、
前記印刷データをプリンタ装置から印刷させる出力手段とを有する。

また、前記サーバ装置は複数個備えられ、前記クライアント装置からの前記指示手段による指示を受けて、複数個の前記サーバ装置のうち、指示に応じた処理をどのサーバに割り当てるか決定する負荷分散手段を更に備える。

また、前記負荷分散手段は、指示に応じた処理を、予め登録しておいた順序で複数個の前記サーバに割り当てる。

また、前記負荷分散手段は、指示に応じた処理を、複数個の前記サーバのうち、未完の処理がもっとも少ないサーバに割り当てる。

また、前記負荷分散手段は、複数個の前記サーバそれぞれの状態を保持する保持手段を更に備え、前記サーバそれぞれの状態に応じて前記保持手段の内容を更新すると共に、前記保持手段の内容を参照して、使用可能状態にないサーバに対しては、前記指示に応じた処理を割り当てない。

また、前記サーバ装置それぞれは、稼働可能となった場合にその旨前記負荷分散手段に通知し、前記負荷分散手段は、該通知を受信すると前記保持手段の内容を、前記通知を発行したサーバが使用可能であるものとして更新する。

また、前記クライアント装置は、印刷の指示と共に、前記プリンタ装置として、前記クライアント装置が有しているプリンタ装置を用いるか、前記サーバ装置が有しているプリンタを用いるかを指定する手段を更に有し、前記出力手段は、
前記指定に応じて、生成された印刷データをサーバから印刷出力するか、あるいは前記クライアントに送信する。

また、前記クライアント装置は、さらに、印刷出力するための複数のプリンタ装置と、該複数のプリンタのなかから、前記サーバから受信した印刷データに適したプリンタを選択する手段とを有し、前記サーバから印刷データを受信した場合、前記選択されたプリンタにより受信した印刷データを出力する。

また、前記クライアント装置は、前記サーバ装置に対して所望のデータを表示する旨の指示を送信する表示指示手段を更に有し、前記クライアント装置は、前記表示指示手段を受信すると、指示されたデータを表示形式に編集して前記クライアントに送信する。

また、前記負荷分散手段は複数個備えられ、前記クライアント装置は、複数の負荷分散手段から所望のひとつを選択して、前記指示手段による指示を発行する。

あるいは、本発明は次のような構成からなる。すなわち、
クライアント装置と接続された情報処理装置であって、
テンプレートデータを格納する格納手段と、
前記クライアント装置からの指示及びクライアント装置に送信したデータに応じて、前記格納手段からテンプレートデータを読み出す読み出し手段と、
読み出されたテンプレートデータと前記クライアント装置で表示されている可変データとを合成して印刷データを生成する生成手段と、
前記印刷データをプリンタ装置から印刷させる出力手段とを有する画像生成部を備える。

また、前記画像生成部は複数備えられ、前記クライアント装置からの指示を受けて、前記指示に応じた処理をどの画像生成部に割り当てるか決定する負荷分散手段を更に備える。

また、前記負荷分散手段は、指示に応じた処理を、予め登録しておいた順序で前記複数の画像生成部に割り当てる。

また、前記負荷分散手段は、指示に応じた処理を、複数の前記画像生成部のうち、未完の処理がもっとも少ない画像生成部に割り当てる。

また、前記負荷分散手段は、複数の画像生成部それぞれの状態を保持する保持手段を更に備え、前記複数の画像生成部それぞれの状態に応じて前記保持手段の内容を更新すると共に、前記保持手段の内容を参照して、使用可能状態にない画像生成部に対しては、前記指示に応じた処理を割り当てない。

また、前記画像生成部それぞれは、稼働可能となった場合にその旨前記負荷分散手段に通知し、前記負荷分散手段は、該通知を受信すると前記保持手段の内容を、前記通知を発行したサーバが使用可能であるものとして更新する。

上記目的を達成するために、本発明は次のような構成からなる。すなわち、クライアント装置と、該クライアント装置から指定される名称に従ってファイルを前記クライアント装置に送信できるサーバ装置とをネットワークを介して接続したネットワークシステムであって、
クライアント装置は、
サーバ装置に対して画像ファイルの生成及び、生成された画像ファイルもしくは当該画像ファイルへの参照パスの送信を要求するリクエストを送信するリクエスト送信手段を有し、
サーバ装置は、
前記ネットワークを介して前記クライアント装置により送信された前記リクエストを受信する受信手段と、
前記受信手段により受信されたリクエストに応じて画像ファイルを生成する生成手段と、
前記生成手段により生成された画像ファイルを格納領域に格納する格納手段と、
前記受信手段により受信されたリクエストを解析し、前記クライアント装置が画像ファイルの送信と画像ファイルへの参照パスの送信のどちらを要求しているかを判断する判断手段と、
前記クライアント装置が画像ファイルの送信を要求していると前記判断手段により判断された場合には、前記生成された画像ファイルを前記格納領域のうち不特定のクライアント装置からアクセス不可能な領域に格納するように前記格納手段を制御し、また前記クライアント装置が画像ファイルへの参照パスを要求していると前記判断手段により判断された場合には、前記生成された画像ファイルを前記格納領域のうち不特定のクライアント装置からアクセス可能な領域に格納するよう前記格納手段を制御する格納制御手段と、
前記クライアント装置が画像ファイルの送信を要求していると前記判断手段により判断された場合には、前記格納領域のうち前記不特定のクライアント装置からアクセス不可能な領域に格納された画像ファイルを前記クライアント装置に対して送信し、前記クライアント装置が画像ファイルへの参照パスを要求していると前記判断手段により判断された場合には、前記格納領域のうち前記不特定のクライアント装置からアクセス可能な領域に格納された画像ファイルへの参照パスを前記クライアント装置に対して送信する送信手段と、を有する。

あるいは、本発明は次のような構成からなる。すなわち、ネットワーク上に接続されたプリンタ装置を用いて、予め定められたテンプレートデータと、このテンプレートデータと組み合わせられる可変データとから構成される文書のプリント要求或いはプリントを行なう文書の表示要求を発行するクライアント装置と、クライアント装置と通信可能に接続され、プリント要求に基づいたプリント用データ又は表示要求に基づいた表示用データを生成し、クライアントに送信するサーバ装置とを有するネットワークプリントシステムにおいて、
プリント要求に基づく処理を行なう際、予め登録された権限データに基づいて、プリント用データの生成を行なわないか、生成するプリント用データの内容を変更させるサーバ装置を備える

本発明によれば、クライアントのＷｅｂブラウザを用いて作成した帳票データ等の画像を、高品質の画像として、クライアントあるいはサーバいずれからも印刷することができる。

また、プリントデータはサーバにより生成されるため、クライアントでは特別な処理を行うためのプログラムを用意する必要がない。また、このため、クライアントの処理性能は低くてもかまわず、安価にクライアントを提供することができる。

また、サーバの負荷を軽減できるため、クライアントを待たせず、快適な印刷処理を実現できる。またシステムダウンの可能性を低減することができる。

また、サーバの負荷の分散を、サーバにより行われている処理に応じて最適に行うことができる。

また、サーバが一部停止しても、全面的に処理を停止させることがなく、また停止したサーバが復旧した場合、そのサーバに対して、利用者が特別な指示を与えなくとも処理が分散される。このために、障害に強く、しかも、最適な負荷分散が可能なネットワークプリントシステム及びネットワークサーバ装置及びその制御方法を提供できる。

また、クライアントでは、サーバから受信したプリントデータに適したプリンタから印刷を行うことができる。

以上説明したように、本発明によれば、一般のクライアントから参照できない場所にファイルを保存し、そのファイルを作成する都度そのファイルの作成を指示したクライアントにそのファイルを送信することで、不特定のクライアントからのデータの参照を不可能とし、また、最新のファイルをクライアントに渡すことができる。

さらに、サーバでは、かつて生成されたデータファイルを記憶しておき、改めて生成要求を受信した場合にはそのデータファイルを返すため、よけいな処理を行わず、資源を節約することができる。また処理速度を向上させることができる。

さらに、クライアントから、データの生成を要求すると共に、生成されたデータを不特定のクライアントにアクセス可能とするか否か指定できる。

図１は、本発明の実施形態に係るネットワークプリントシステムのソフトウエアブロック図である。ここでは、サーバ、クライアントともに１台ずつ示している。

＜ネットワークシステムの構成例＞
図１において、クライアント１０１は、パーソナルコンピュータ等の情報処理装置である。クライアント１０１には、データ入出力部１０２、プリント出力部１０３、Ｗｅｂブラウザ１１４、画像表示部１１５、プリントデータ解析部１１６等が含まれる。

データ入出力部１０２は、電話回線やＬＡＮ等のネットワーク１０５を介してサーバ１０６とデータを交換するもので、ＨＴＴＰより低いプロトコルレイヤの処理を行う。プリント出力部１０３は、所定の形式で記述されたプリントデータをプリンタ１０４の出力形式に従ったデータ形式に変換してプリンタ１０４から出力するほか、サーバ等から受信したプリンタの出力形式のデータをスプールしてプリンタ１０４により印刷させる。

Ｗｅｂブラウザ１１４は、データ入出力部１０２を介してサーバから受信したＨＴＭＬ文書を、画像表示部１１５を介してディスプレイ１１７で表示したり、あるいは、図示しないキーボードなどの入力デバイスを介した操作に応じてプリント出力部１０３を介して印刷する。さらに、表示しているＨＴＭＬ文書データに、画面上で何らかのデータを入力する旨の記述が含まれれば、ユーザにその記述に相当する欄への入力を行わせる。また、それを入力されたデータをサーバに送信する旨の記述があり、その記述に従ってユーザが操作を行えば、入力されたデータをサーバに送信する。なおこれらの記述は、一般に入手可能な代表的なＷｅｂブラウザによりサポートされている。プリントデータ解析部１１６は、サーバ等から受信したプリントデータを解析し、クライアント１０１に接続されているプリンタ１０４で対応可能な形式のデータであるかの判定を行なうことができる。

クライアント１０１とサーバ１０６とを接続するネットワーク１０５の形態としては、ＬＡＮ、インターネットあるいは無線等、Ｗｅｂ環境の通信手順に対応するものであれば、その種類は問わない。

サーバ１０６は、少なくともＨＴＴＰ及びＦＴＰをサポートするＷｅｂサーバであり、クライアントと同様、パーソナルコンピュータ等の情報処理装置である。サーバ１０６は、サーバ１０６がＷｅｂサーバとして機能するためのネットワーク通信制御部１０７を含み、これを介してクライアント１０１にデータを送信し、あるいはクライアント１０１からデータを受信する。

帳票テンプレート格納部１０８は、帳票プリントを行う為の帳票テンプレート等を格納する。なお、テンプレートデータは、クライアントがサーバから読み出したＨＴＭＬ文書に対応して予め設定され、格納されているものとする。従って、サーバが帳票テンプレートに対応づけられるＨＴＭＬ文書をクライアントに送信した場合、その文書に対応する識別子をサーバは記憶しておく。また、帳票テンプレート格納部に格納されるテンプレートも、テンプレート毎にＨＴＭＬ文書と対応する識別子を付して格納する。

データ格納部１０９はデータベース等であり、各業務用データが格納されている。このデータは予め格納されたものであっても良いし、ブラウザを介してクライアントから入力されたものであってもよい。データ処理部１１０には、各業務に従ったアプリケーションプログラムが格納されている。画像生成部１１１は、帳票のイメージデータを、フォーム及びそこにオーバーレイされるデータを組み合わせ、プリント出力部１１２で解釈可能な所定の形式で作成する。プリント出力部１１２は、画像生成部で作成されたデータをプリンタ１１３が出力できる形式に変換し、プリンタから出力させたり、あるいは生成されたデータをデータファイルとして出力することができる。プリント出力部１１２は一般にはプリンタドライバと呼ばれている。

図８はクライアント及びサーバとして使用可能な情報処理装置の構成を示すハードウエア構成図である。図１のクライアント１０１及びサーバ１０６の構成は、図８の構成において、メモリ１０１ｂに格納されたプログラムを、ＣＰＵ１０１ａにより実行することで実現される。また、図１の構成を実現するためのプログラムは、ハードディスク等の外部メモリ１０１ｃに格納される。外部メモリ１０１ｃは、フロッピディスクやＣＤＲＯＭ等の取り外し可能な記憶媒体を用いるものであっても良い。また、データ格納部１０９あるいは帳票テンプレート格納部１０８は、外部メモリ１０１ｃの一部領域として実現することができる。

ディスプレイ１１７（クライアント１０１の場合）には、画像が表示され、Ｉ／Ｏインターフェース１０１ｄを介してネットワーク１０５やプリンタ１０４（１１３）に接続される。また、キーボードやポインティングデバイス１０１ｅにより、オペレータは必要な入力を行う。

＜帳票の印刷処理＞
次に、本発明の特徴である、ブラウザからのプリント指示及びそれに対するサーバの処理について述べる。
通常クライアント１０１のブラウザ１１４とサーバ１０６のデータ処理部１１０の間では、ブラウザからのデータの受付、解析、また場合によっては、受付データに応じてデータ格納部１０９からのデータ検索、結果のブラウザへの返信などの処理が行われる。この時、ＨＴＭＬ文書に、ブラウザからボタンによる入力を行わせてその結果をサーバに送信するよう記述しておけば、ブラウザ１１４はボタンを表示し、ブラウザのユーザがボタンを押す等の操作をした時に、サーバへのデータの送信を行う。サーバでは、クライアントに送信したＨＴＭＬ文書に基づいて受信データを解析し、必要があればブラウザへ応答する。

図２は、ブラウザにより表示された業務処理に係るＨＴＭＬ文書の一例である。図２において、ウインドウ２０１は、ディスプレイ１１７に表示されるブラウザ１１４のウインドウである。タイトルエリア２０２には表示される文書に付されたタイトルが表示される。エリア２０３および２０４にはブラウザ１１４のコマンドがツールバーやボタン等の形式で表示されている。ブラウザに表示されている内容を印刷する為のコマンドも通常これらエリアに表示される。エリア２０５は、接続するＷｅｂサーバのアドレスや文書のＵＲＬ等を入出力するＵＲＬフィールドである。ＨＴＭＬ文書はここで入力されるＵＲＬにより指定される。

選択欄２０６および２０７は、クライアントユーザが選択する為のフィールドである。ボタン２０８は表示ボタンである。帳票イメージ２０９は、エリア２０５に入力された文書アドレスに応じたＨＴＭＬ文書がサーバから読み出されて表示されたものである。また、このＨＴＭＬ文書には、帳票イメージ２０９の他、印刷ボタン２１０とサーバ印刷ボタン２１１が含まれている。

クライアント１０１からサーバ１０６の文書を読み出す場合、まずクライアントでブラウザプログラム１１４を起動する。このブラウザ自体は市販品でよい。ブラウザ１１４が起動されると、タイトルエリア２０２〜ＵＲＬフィールド２０５迄が表示され、その他の欄は空白あるいは予め設定されたＵＲＬで指定される文書が表示される。ここで、図２のように"http://202.228.102"が指定されると、欄２０６〜２１１を含むＨＴＭＬ文書がサーバから読み出されて表示される。

この画面上でユーザがポインティングデバイスやキーボードによって選択欄２０６，２０７から所望の値を選択し、表示ボタン２０８を押すと、読み出したいデータが確定し、選択された個人及び表種別がサーバに送信される。サーバ１０６では、指定されたＵＲＬにおいて、選択された個人名及び表種類をキーとしてデータ格納部１０９を検索し、データを獲得する。データには、そのデータを表示すべき形式を指定するための形式識別子が含まれている。

サーバではこの識別子に対応する形式で検索したデータを表示するためのＨＴＭＬ文書を作成し、クライアントに送信する。ここで、形式識別子に応じたＨＴＭＬ文書は、予め可変データを除いて残りの部分を記述しておき、可変データの部分に後述するデータのインデックスを、インデックスとして認識できるように挿入しておく。サーバからクライアントに送信する文書は、この形式の文書のインデックスの部分に、検索されたデータをインデックス毎に対応づけて挿入して作成される。なお、この表示の手順は、第６の実施形態において図面を参照して詳しく説明する。

クライアントでは、受信したデータを図２のように表示する。クライアントのユーザがこれらを表示した状態でサーバ印刷ボタン２１１あるいは印刷ボタン２１０を押すと、次のような手順で文書がサーバあるいはクライアントから印刷される。

＜サーバにより印刷を行う際の手順＞
次に、図２の状態でサーバ印刷ボタン２１１が押された場合の動作を説明する。印刷も、ＨＴＭＬ文書と同様に、形式識別子に対応したテンプレートにデータを挿入して印刷すべき文書を作成する。サーバ印刷ボタン２１１が押されると、サーバ印刷ボタンが押されたことを示す情報がサーバ１０６に送信される。サーバでは、印刷を要求してきたクライアント１０１に送信してあるデータに付された形式識別子を基に、帳票テンプレート格納部１０８に格納されている図形データを各帳票のテンプレートとして検索する。各帳票テンプレートは、形式識別子から検索できるように格納されている。

図３は、印刷される帳票テンプレートの一例である。図３において、帳票テンプレートである図形データを説明する。図形データは固定データと可変データに分類される。帳票タイトルの文字列３０１、枠および日にち等を示す数字、文字列３０２及び、文字列、枠３０３は固定データである。また、ｎｘｘ及びｓｘｘ（ｘｘは整数）で示される文字列３０４及び３０５には、データベース等より検索された値がはめ込まれる可変データである。

一方、図４は、図３の図形データにはめ込まれるべき可変データのテーブルである。図４において、列４０１は、図３の可変データｓ１，ｎ１，ｎ２…ｎ５１を示すインデックスである。列４０２は、表示する文字のサイズを示している。列４０３は、実際の数あるいは文字列である。図３の帳票イメージと図４のデータを、インデックスを対応づけてマージすることにより、帳票の図形データが作成される。また、形式識別子４０４はこのテーブルに含まれるデータを表示すべき帳票テンプレートを示すデータであり、このテーブルの場合には図３の帳票テンプレートを示すデータが格納されている。

次に、図３の帳票テンプレートと図４のデータのマージ処理を、図５のフローチャートを用いて説明する。
なお、本説明において、印刷ボタンがブラウザにより表示されている状況では、ブラウザのウィンドウにおいても、印刷される帳票を形どったイメージは表示されており、ブラウザに帳票イメージを表示するためのデータは、サーバのデータ格納部１０９から検索され、サーバのメモリ内に存在しているものとする。

図５は、ブラウザウィンドウ２０１（図２）においてサーバ印刷ボタン２１１が押されたことを示す情報をサーバが受信したことにより、サーバにおいて実行される処理を示すフローチャートである。図５に示された処理のうち、ステップＳ５０１〜５０４はデータ処理部１１０により、ステップＳ５０５〜５０６は画像処理部１１１により、ステップＳ５０７はプリント出力部１１２により実行される。

まず、ステップＳ５０１でボタンが押されたことがサーバに通知されると、ステップＳ５０２においてサーバ内では印刷に使用する帳票を検索する。サーバには、使用する帳票テンプレートに対応する形式識別子がクライアントに送信済みのＨＴＭＬ文書データに対応づけて記憶されているため、この形式識別子を用いて直ちに検索可能である。

ステップＳ５０３では、帳票テンプレート格納部１０８から検索された帳票テンプレートとマージすべき可変データ欄の位置を検知する。例えば、可変データの位置を、固定データを記述した部分とは別個に、データごとにインデックスに対応つけて記述してあれば、可変データ部分に含まれるインデックスによって簡単に各可変データの位置を認識できる。そして、図４に示した可変データテーブルから、インデックス及びサイズの部分の抽出をする。帳票に対応した可変データテーブルはクライアントから表示要求が出された時点で読み出され、サーバに保存されている。

次に、ステップＳ５０４でインデックスデータを作成する。すなわち、すでに保存されている可変データテーブル中の値（列４０３に含まれる値）を、そのインデックスに応じて、ステップＳ５０３で抽出した可変データの位置に合わせて記述する。こうして、可変データ部分を記述したインデックスデータができる。

次に、ステップＳ５０５において、画像生成部１１１により、ステップＳ５０２で得られた帳票テンプレートの固定データ部分と、ステップＳ５０４で作成したインデックスデータとをマージさせる。ステップＳ５０６では、画像生成部１１１により、ステップＳ５０５でマージされたデータから、実際の画像形式、すなわちプリント出力部１１２にて解釈可能な形式で記述されたデータを作成する。ステップＳ５０７では、ステップＳ５０６で作成したデータを、プリンタ１１３で出力可能な例えばページ記述言語のプリントイメージに変換し、外部メモリ１０１ｃ等に設けられたプリントスプールに出力する。こうして、帳票テンプレートとデータとが合成されてサーバ１０６のプリンタ１１３から出力される。

＜クライアントにより印刷を行う際の手順＞
図６は、図２の印刷ボタン２１０が押された場合のサーバ１０６の処理手順を示すフローチャートである。
まず、ステップＳ７０１でボタンが押されたことがサーバに通知されると、ステップＳ７０２においてサーバ内では使用される帳票を検索する。サーバには、使用する帳票テンプレートに対応する形式識別子がクライアントに送信済みのＨＴＭＬ文書データに対応づけて記憶されているため、この形式識別子を用いて直ちに検索可能である。

ステップＳ７０３では、帳票テンプレート格納部１０８から検索された帳票テンプレートとマージすべき可変データ欄の位置を検知する。例えば、可変データの位置を、固定データを記述した部分とは別個に、データごとにインデックスに対応つけて記述してあれば、可変データ部分に含まれるインデックスによって簡単に各可変データの位置を認識できる。そして、図４に示した可変データテーブルから、インデックス及びサイズの部分の抽出をする。帳票に対応した可変データテーブルはクライアントから表示要求が出された時点で読み出され、サーバに保存されている。

次に、ステップＳ７０４でインデックスデータを作成する。すなわち、すでに保存されている可変データテーブル中の値（列４０３に含まれる値）を、そのインデックスに応じて、ステップＳ７０３で抽出した可変データの位置に合わせるようにして記述する。こうして、可変データ部分を記述したインデックスデータができる。

次に、ステップＳ７０５において、画像生成部１１１により、ステップＳ７０２で得られた帳票テンプレートの固定データ部分と、ステップＳ７０４で作成したインデックスデータとをマージさせる。ステップＳ７０６では、画像生成部１１１により、ステップＳ７０５でマージされたデータから、実際の画像形式、すなわちプリント出力部１０３にて解釈可能な形式で記述されたデータを作成させる。ステップＳ７０７では、ステップＳ７０６で作成したデータを、クライアントに対して送信する。

なお、このステップでは、説明を簡単にするためにデータをクライアントに送信するとしているが、実際には作成されたデータそのものをクライアントに送信せず、作成されたデータファイルのＵＲＬをクライアント（Ｗｅｂブラウザ１１４）に送る。クライアントでは、Ｗｅｂブラウザが受信したＵＲＬを用いて、ＨＴＴＰでなくＦＴＰを利用してデータファイルの送信を要求し、サーバからクライアントに印刷データファイルが渡される。

図７は、図６のステップＳ７０７でサーバにより送信されたデータを受信したクライアントによる処理手順を示すフローチャートである。
まず、ステップＳ８０１において、受信したデータをプリントデータ解析部１１６により解析し、受信したデータに適したプリンタを見つけてそこから印刷させる。本実施形態の構成では、図１に示すようにプリンタは１台しかないため、そのプリンタ１０４から印刷される。ステップＳ８０２では、プリント出力部１０３によりプリンタ１０４で出力可能なプリントイメージを生成する。それをステップＳ８０３で例えば外部メモリ１０１ｃに設けられたプリントスプールに格納し、順次出力させる。そして、受信したデータが終了するまでステップＳ８０１からＳ８０３の処理を繰り返し行う。
以上の手順により、クライアントからＷｅｂブラウザ１１４を用いて出力データを指定し、適当な形式で印刷を行わせることができる。

また、印刷用に作成された帳票テンプレートを用いて帳票を印刷することにより、表示された帳票を印刷する場合と異なり、Ｗｅｂブラウザを用いて作成した画像を、高品質の印刷物として出力可能である。
また、サーバでもクライアントでも、いずれのプリンタからでも高品質の帳票を利用者の都合に応じて印刷させることができる。

また、帳票テンプレートを保持するのはサーバのみであり、データとの合成もサーバで行っているため、クライアントは、市販のＷｅｂブラウザを用意しておきさえすれば、サーバから高品質の帳票を印刷できる。
またこのためにクライアントの負荷が軽く、処理能力の低い安価なパーソナルコンピュータをクライアントとして利用できる。
なお、本実施形態では、帳票テンプレートはデータに応じて決まるものとしたが、テンプレートをデータとは独立して選ぶようにすること可能である。

また、出力されるデータはデータベースから検索されるものとしたが、Ｗｅｂブラウザを用いてクライアントの利よす脂入力させることもできる。この場合には入力されたデータを帳票テンプレートと合成して印刷させることもできる。
なお、クライアントにおけるプリント出力部１０３は、プリンタ１０４が解釈可能な形式のデータを生成する機能を有すると説明したが、本実施形態のように、サーバにおいてクライアントのプリンタ１０４が解釈可能な形式で記述されたデータを生成する場合には、この機能を有している必要はなく、単に受信したデータをプリンタスプールに格納する機能のみを有していればよい。

また、クライアントがデータを選択すると、それに対応してその表示フォーマットも決まるものとして説明したが、表示フォーマットをデータとは独立して指定できるようにすることもできる。この場合には、図２に示したブラウザウィンドウにフォーマット指定用のスイッチを設け、そのスイッチでフォーマットを指定させる。サーバではこの指定に応じたテンプレートを検索して印刷のために使用する。また、ブラウザからフォーマットを指定する場合には、可変データテーブル（図４）の形式識別子４０４は不要となる。

［第２の実施形態］
本実施形態は、第１の実施形態に係るネットワークプリントシステムシステムにおけるサーバを３階層構成とし、負荷分散を行ったことを特徴とする。
図９は、本実施形態に係るネットワークプリントシステムのソフトウェアブロック図である。

図９において、クライアント１０１は図１に示したものと同じ構成を有するため、説明は省略する。また、図９においては、図１のサーバ１０６との対比を容易にするため、サーバ１０６が有するソフトウェアブロックと同一機能を有するソフトウェアブロックは同一の参照数字を付した。
Ｗｅｂサーバ９０１は情報処理装置であり、そのネットワーク通信制御部１０７は図１におけるサーバ１０６のそれと同じ機能を果たす。負荷分散制御部９０２は、後述する画像生成サーバ９０８，９０９に、第１の実施形態における画像生成部等の処理を分散して行わせるための制御を行なう。ネットワーク９０７はウェブサーバ９０１、画像生成サーバ９０８、９０９を相互に接続する。

画像生成サーバ９０８と９０９とは同じ構成を有しており、やはり図８のような構成を有するコンピュータで構成される。そして、図１のＷｅｂサーバ１０６から、ＨＴＴＰレイヤの処理を行うネットワーク通信制御部１０７を除いた構成を有する。ネットワーク９０７には通信インターフェース９１０を介して接続されており、Ｗｅｂサーバ９０１とのデータの交換が可能となっている。画像生成サーバ９０８，９０９は、データ及び帳票テンプレートの検索やデータと帳票テンプレートの合成、及びそのデータをプリントイメージに変換すること、及びそれを印刷出力する処理を行う。すなわち、Ｗｅｂサーバ９０１はクライアント１０１の要求を画像生成サーバ９０８、９０９に振り分ける、あるいは、画像生成サーバからの応答をクライアントに渡す処理を行う。

次に、図１０に示すフローチャートを用いて、画像生成部１１１を持つ画像生成サーバ９０８、９０９をＷｅｂサーバ９０１によって制御する手順について説明する。一般にＷｅｂシステムでは、サーバとクライアント間の１回の要求、応答で１つのセッションは終了してしまう。この様なシステムの中で、セッションを保つ為の方法として、サーバの位置情報を示すＵＲＬの中にセッションＩＤを導入しておく方法がある。このセッション番号をクライアント及びサーバ双方で保持することにより、何往復にもわたる要求／応答があってもそれをひとつのセッションとして認識できる。

図１０は、このセッションＩＤを用いて、画像生成サーバに処理を振り分ける処理手順の例である。
ステップＳ１００１で、あるクライアントからのリクエストを受け付けると、指定されたＵＲＬにセッションＩＤが付加されているか否かを判定する（ステップＳ１００２）。もしＵＲＬ中にセッションＩＤが付加されていない場合は、このクライアントからのセッション開始とみなし、ステップＳ１００３でこの要求に対してセッションＩＤを付与する。このセッションＩＤ付のＵＲＬは、以後の処理が終了した後クライアント側に返される。また後述するが、セッションごとにそのセッションを行なう画像生成サーバを割り振り、Ｗｅｂサーバ９０１はセッションと対応する画像生成サーバを記憶している。

クライアントは開始されているセッションについての要求を行なう場合には、ステップＳ１００３で付与されたセッションＩＤをＵＲＬに付加するように構成されている。従って、ステップＳ１００２で、ＵＲＬ中にセッションＩＤが付加されていると判定された場合、すなわち、クライアントからの要求がセッション開始ではなく、すでに開始されているセッションであると判定された場合には、ステップＳ１００７に移行し、セッションＩＤに対応する画像生成サーバへ再アクセスを行う事になる。

次に、ステップＳ１００４では、Ｗｅｂサーバ９０１内で保持している分散設定テーブル９０３を参照し、使用する画像生成サーバを決定する。分散設定テーブル９０３の例を図１１に示す。図１１の欄１１０２には、分散を行うコンピュータ（本実施形態においては画像生成サーバ）のアドレスが記述され、１１０１にアドレスとペアーのインデックスが記述される。ここではアドレスとしてＩＰアドレスが記述されている。

この分散設定テーブル９０３は、Ｗｅｂサーバ９０１の起動時に負荷分散制御部９０２の管理するメモリ内に読み込まれる。また、分散設定テーブル９０３の欄１１０３及び１１０４には、最も最近使用された画像生成部を持つコンピュータ、すなわち画像生成サーバのインデックス（”９９”）及び、本テーブル上でのオフセットアドレスを保持しておく。

したがって、図１１の例では、Ｗｅｂサーバ９０１はインデックスが１〜４の４台の画像生成用サーバを配下におさめており、最近処理依頼を行ったのはインデックス２の画像生成サーバである状態を示している。
もし新たなクライアントからのリクエストを受け付けた際には、最後に使用された画像生成サーバの次のサーバ、すなわちインデックス３の画像生成サーバを使用する。このようにして、ステップＳ１００４において、次に使用する画像生成サーバが決定され、ステップＳ１００５では、最後に使用された画像生成サーバの欄１１０４が更新される。

ステップＳ１００６では、クライアントにより指定されたＵＲＬに対し、ステップＳ１００３で付加したセッションＩＤの他、ステップＳ１００４で決定された処理依頼先の画像生成サーバのアドレスをも付加して記憶する。これにより、以後のクライアントからサーバへのアクセスに際し、ＵＲＬ及びセッションＩＤを受けとったなら、その処理を行う画像生成サーバも特定出来る様になる。

ステップＳ１００７では、ステップＳ１００４で決定された画像生成サーバに対してクライアントの指定した処理を依頼する。
ステップＳ１００８のサーバ内処理待ちでは、画像生成サーバに依頼した処理が終了し、その旨応答が返されるまで待つ。画像生成サーバで行われる処理は、第１の実施形態において、Ｗｅｂサーバ１０６が行っている帳票データの作成や出力と同様である。

すなわち、クライアントからのプリント処理である場合もあり、プリントを行わない表示処理（後述）の場合もある。サーバプリント要求であれば、画像生成サーバ内処理において、データと帳票テンプレートとを合成した画像データのプリント出力まで行われる。クライアントにおけるプリント要求であれば、クライアントのプリンタ１０４で実行可能な形式のプリントイメージの生成までを行なう（あるいは、プリント出力部１０３がプリントイメージを作成できる形式のデータの生成までを行なう）。表示要求であれば表示内容に即したＨＴＭＬ文書が作成される。

図１２は、図１１のステップＳ１００８において、Ｗｅｂサーバ９０１から処理依頼された画像生成サーバにより遂行される処理手順を示すフローチャートである。
Ｗｅｂサーバ９０１から処理依頼を受信すると、ステップＳ１２０１でそれがサーバにおけるプリント要求か判定する。そうであれば、ステップＳ１２０６において、図５のステップＳ５０２以降と同様の処理を行い、帳票を印刷出力する。

一方、サーバにおけるプリント要求でなければ、ステップＳ１２０２においてクライアントにおけるプリント要求、すなわちプリントデータ作成依頼であるか判定する。そうであれば、図６のステップＳ７０２からの処理を行う。ただし、ステップＳ７０７におけるデータ転送は、クライアントに対してではなくＷｅｂサーバ９０１に対して行われる。

サーバにおけるプリント要求でも、クライアントにおけるプリント要求でもなければ、依頼は表示要求であるものとして、ステップＳ１２０３でデータを検索してステップＳ１２０４でＨＴＭＬ文書として編集し、ステップＳ１２０５でそのＨＴＭＬ文書をＷｅｂサーバ９０１に送信する。なお、ここではＷｅｂ９０１から依頼される処理はこの３種類に限ったが、その他の要求があるならば、画像生成サーバにそれに対応した機能を付加すれば、簡単に要求に対応できる。
画像生成サーバでの処理が終了した旨の通知を受けるか、処理結果を受信すると、Ｗｅｂサーバ９０１はステップＳ１００９において、プリントが完了した旨の応答や、あるいは作成されたデータを、クライアント１０１に返送する。

以上のように、クライアントからの一連の要求にはセッションＩＤが与えられ、その要求を処理する画像生成サーバが決定される。また、新たなセッションの発生毎に、最後に使用した画像生成サーバの次に負荷分散テーブルに配置された（最後に使用した画像生成サーバがテーブルの最後に位置する場合には最初のサーバに戻って）画像生成サーバを使用するよう決定されるため、クライアントからの一連の要求を、ひとつの画像生成サーバにより処理でき、処理の継続性を保持できると共に、各画像生成サーバの負荷が軽減される。

［第２の実施形態の変形例１］
第２の実施形態におけるシステムを基に、さらにきめ細かい負荷の分散を行うこともできる。すなわち、本変形例においては、複数の画像生成サーバ間における負荷分散を行なうことを特徴とする。
この変形例におけるシステム構成は、第２の実施形態と同じく、図９のブロック図によって示される。

次に、図１３、図１４を用いて、画像生成サーバの処理を分散する仕組みについて説明する。
図１３は、本変形例における負荷分散を制御するために用いられる分散設定テーブル９０３’を示している。このテーブルが第２の実施形態における分散設定テーブル９０３に替えて用いられる。テーブル分散設定テーブル９０３’においては、画像生成サーバの数（或いは、画像生成部の数）に相当する個数のインデックスがあり、各インデックス毎に画像生成サーバを識別するための識別アドレスを保有する。識別アドレスとしては、例えばネットワーク接続のためのＩＰアドレスやホスト名、ＨＴＴＰ接続のためのＵＲＬ等が用いられる。分散設定テーブル９０３’が、Ｗｅｂサーバ９０１内に格納され、サーバの起動時に、図９の負荷分散制御部９０５の管理するメモリ内に読み込まれる。

分散設定テーブル９０３’では、分散設定テーブル９０３と比較して、各インデックスに対して、識別アドレスと共に負荷係数１４０３を持ち、最後に使用されたサーバの識別子を持たない点で異なる。本変形例では、この負荷係数１４０３はクライアントからの要求が割り当てられ、かつ処理が終了していない要求の数である。

Ｗｅｂサーバ９０１は、あるクライアントから要求があった時、分散設定テーブル９０３’を参照して、最も負荷が軽いとみなされる画像生成サーバを選択して処理を依頼する。図１４に示すフローチャートを用いて、Ｗｅｂサーバ９０１が分散設定テーブル９０３’における負荷係数を用いてクライアントから要求された処理を行なう処理手順を説明する。なお、以下の説明においては、クライアントからの要求は新しいセッションによって処理されるものとする。

ステップＳ１５０１で、あるクライアントからのリクエストを受け付ける。ステップＳ１５０２では、分散設定テーブル９０３’を参照し、負荷係数が一番小さい画像生成部を検索する。図１３の例では、符号１４０４で示されるインデックス４の画像生成サーバがそれに相当する。ステップＳ１５０３で、その画像生成サーバに処理を依頼することを決定する。
なお、負荷係数が最小の画像生成部が複数ある場合には、任意の条件でその中の１つを選択するように構成することができる。

ステップＳ１５０４では、分散設定テーブル９０３’の、選択された画像生成サーバに対応する負荷係数を１加算する。ステップＳ１５０５で選択された画像生成サーバに処理を依頼し、ステップＳ１５０６でサーバ内の処理が終了するのを待つ。ステップＳ１５０６において画像生成サーバが行なう処理手順は、第２の実施形態と同様である。

画像生成サーバから処理終了の通知を受けるか、処理結果のデータを受信すると、その画像生成サーバに対応する分散設定テーブル９０３’の負荷係数を１減ずる（ステップＳ１５０７）。なお、図１４の手順はクライアントからの要求を受け付けるたびに起動されるため、処理が終了していない画像生成サーバに対しても、次の処理依頼を発行することがあり得る。これは、第２の実施形態においても同様である。

そして、ステップＳ１５０８で、クライアントに処理が終了したことを通知する（要求がプリントデータ作成、表示データ生成であれば、処理結果のデータを送信する）。

（分散設定テーブルへの登録処理）
図１５は、分散設定テーブルに画像生成サーバの識別アドレスの新規登録を行うための処理手順を示すフローチャートである。この手順は、画像生成サーバが備えたキーボードなどからの入力により実行されても良いし、Ｗｅｂサーバからの新規登録メッセージにより実行されても良い。

ステップＳ１６０１では、画像生成部の登録の要求を受け付ける。この要求メッセージには要求元の画像生成サーバの識別アドレスが含まれている。

ステップＳ１６０２では分散設定テーブルを参照する。識別アドレスが登録されていなければステップＳ１６０３で新規の登録と判断して、ステップＳ１６０４で分散設定テーブルに新規インデックスとともに識別アドレスを登録して処理を終了する。なお、新規登録時の負荷係数は０とする。
一方、ステップＳ１６０２におけるテーブル参照の結果、既登録であれば何もせずに処理を終了する。このようにして、新規の画像生成サーバがネットワーク９０７に接続された場合、それをＷｅｂサーバの分散設定テーブルに登録できる。

以上の説明したように、本変形例によれば、処理中の要求が他のサーバに比べて少ない画像生成サーバに新たな処理依頼が発行されるため、各画像生成サーバの負荷は均一化される。このため、負荷の分散が効果的になされ、システム全体の処理効率が向上する。

［第３の実施形態］
次に、本発明の第３の実施形態にかかるネットワークプリントシステムについて説明する。本実施形態のシステムは、第２の実施形態と同じく画像生成サーバを複数用いたネットワークシステムであって、画像生成サーバに障害が発生した場合に他のサーバで代替処理を行うことを特徴とする。

図１６は、本実施形態に係るシステムの構成を示すソフトウェアブロック図である。図１６において、クライアント１０１は第１又は第２の実施形態のそれと同じものである。Ｗｅｂサーバ４１０１は、第２の実施形態のＷｅｂサーバ９０１とほぼ同様の構成を有するが、分散設定テーブル４１１１を管理するための監視部４１０４を有する点で異なる。ネットワーク通信制御部１０７及び負荷分散制御部９０２に関しては、第２実施形態のそれらと同様の機能を果たす。

画像生成サーバ４１０５及び４１０８は、画像生成サーバの状態を監視部４１０４に通知する通知部４１０７を有すこと以外は、画像生成部１１１をはじめとして、図９に示した第２の実施形態における画像生成サーバ９０８、９０９と同様の構成を有している。

図１７は、本実施形態において画像生成サーバの分散を制御するために用いられる分散設定テーブル４１１１を示している。分散設定テーブル４１１１においては、画像生成サーバに相当する個数のインデックスがあり、各インデックス毎に画像生成サーバ部を識別するための識別アドレスとステータス情報を持つ。

識別アドレスとしては、例えばネットワーク接続のためのＩＰアドレスやホスト名、ＨＴＴＰ接続のためのＵＲＬ等が用いられる。また、ステータス情報は画像生成サーバがＷｅｂサーバからの画像生成要求を受け取れる状態にあるかどうかを示すフラグであり、受け取れる状態にある画像生成サーバに対しては欄４００４、４００５、４００６で示されるように“ＯＫ”が入り、受け取れない状態にある画像生成サーバに対しては欄４００７で示されるように“ＮＧ”が入る。

このような分散設定テーブル４１１１がＷｅｂサーバ４１０１内に格納され、サーバの起動時に、負荷分散制御部９０２の管理するメモリ内に読み込まれる。なお、第２の実施形態における分散設定テーブル９０３あるいはその変形例１の分散設定テーブル９０３のように、最後に使用されたサーバを示す欄や、負荷係数欄をさらに設けてもよい。この場合には、サーバの代替処理とは別に、サーバの負荷分散が第２実施形態及びその変形例で説明したように行われる。

（代替処理）
次に、図１８に示すフローチャートを用いて、画像生成サーバに障害等が発生して利用できない場合の代替処理について説明する。この処理はＷｅｂサーバの負荷分散制御部９０２及び監視部４１０４により行われるため、図では処理の流れが理解しやすいように、左側に負荷分散制御部９０２による処理を、右側に監視部４１０４による処理を示す。

図１８のフローチャートは、あるクライアントからの要求を受け付けてから、適当な画像生成サーバを選択し、その画像生成サーバに処理を依頼し、依頼先の画像生成サーバに障害が発生もしくは検出された場合に、代替の画像生成サーバを選択して要求のあった処理を完了させるまでの手順を示す。

ステップＳ４２０２であるクライアントからのリクエストを受け付けると、ステップＳ４２０３において、負荷分散制御部９０２は、監視部４１０４にどの画像生成サーバに処理依頼可能であるか（ステータスが“ＯＫ”で画像生成サーバがあるか）の問い合わせを行なう。

ステップＳ４２０４で、監視部４１０４は分散設定テーブル４１１１を参照し、ステータスがＯＫである画像生成サーバを検索し、その情報を負荷分散制御部に返す。図１７に示した分散設定テーブルの例では、インデックス１〜３までの画像生成サーバのステータスが”ＯＫ”であるが、本実施形態においては先頭の欄４００４で示されるインデックス１の画像生成サーバの情報を負荷分散制御部に応答するものとする。分散設定テーブルに負荷係数の項目がある場合には、ステータスが”ＯＫ”で、かつもっとも負荷係数が小さい画像生成サーバの情報が返送される。

ステップＳ４２０５で、ステップＳ４２０４で選択された画像生成サーバに処理を依頼することを決定し、ステップＳ４２０６でその画像生成サーバに処理を依頼して、画像生成サーバでの処理終了を待つ。

画像生成サーバによる処理が終了すると、ステップＳ４２０７で処理の結果を判断する。ステップＳ４２０６で依頼した処理が画像生成サーバで正常終了していなければ、画像生成サーバの通知部４１０７によって負荷分散制御部９０２に異常終了した旨が通知される。異常終了であれば、負荷分散制御部９０２は監視部４１０４に異常終了した画像生成サーバのアドレスあるいはインデックスを知らせる。ステップＳ４２０８では、監視部４１０４は、分散設定テーブル４１１１の、該当画像生成サーバのステータス欄に使用不可であることを示す”ＮＧ”を記入する。

そして、再度ステップＳ４２０３に戻って、監視部４１０４に処理依頼可能な画像生成サーバの問い合わせを行なう。この場合、異常終了した画像生成サーバはステップＳ４２０８でステータスが”ＮＧ”に変更されているので、別の画像生成サーバが選択される。以後、正常終了結果が得られるまで、同様の処理を繰り返す。

ステップＳ４２０６で依頼した処理が正常終了すれば、画像生成処理の結果（又はプリント終了の通知）を画像生成サーバから受信して処理はそのまま終了する。しかし、負荷分散制御部９０２が監視部４１０４に対して処理が正常終了したことを通知するようにしてもよい。また、ステップＳ４２０６で依頼された処理の結果は、通知部４１０７が直接監視部４１０４に通知しても構わない。

このようにして処理を終えると、Ｗｅｂサーバは画像生成サーバから受けた処理結果あるいは処理終了通知を、その処理を要求したクライアントに対して送信する。その際、代替処理を行なった場合にはその旨をクライアントに通知するようにしても良い。

以上説明したように、処理が異常終了した場合には他の画像生成サーバで処理を行なうことにより、より安定したシステムの構築が可能になる。
さらに、異常終了した画像生成サーバに対応する分散設定テーブルのステータスは”ＮＧ”となるため、以後の処理で使用されることがなく、処理に支障をきたすことがなくなる。

（復帰処理）
次に、図１９に示すフローチャートを用いて、障害等により分散設定テーブルのステータスが”ＮＧ”とされた画像生成サーバが再度利用可能になった場合の処理手順を説明する。
図１９においても、その処理を実行する場所が理解しやすいように、左には画像生成サーバで行なわれる処理を、右にＷｅｂサーバで行なわれる処理を示している。
以下の処理は、障害が発生して使用できなくなっていた画像処理サーバが利用可能になったとき、例えば、障害状態から復帰して再起動されたときに実行され、Ｗｅｂサーバがその画像生成サーバを再度利用可能な状態にすることを目的とする。

ステップＳ４３０１で、使用できなかった、あるいは使用されていなかったある画像処理サーバが使用可能になったとする。使用可能になる要因としては、障害後の再起動や、新規に起動された場合、再起動なしに障害から復帰した場合など任意である。

利用可能になった画像処理サーバは、ステップＳ４３０２で監視部４１０４へ利用可能になったことを通知する。
ステップＳ４３０３において、監視部４１０４は分散設定テーブル４１１１を参照して、ステップＳ４１０２で受信した通知の送信元である画像処理サーバを検索する。

ステップＳ４３０４で、検索の結果、既に該当する画像処理サーバが登録されているかどうかを判断する。登録されていない場合は、新規登録と判断してステップＳ４３０５で分散設定テーブル４１１１に該当画像処理サーバを登録する。一方、既に登録されていた場合は、ステップＳ４３０５の登録処理をスキップする。

ステップＳ４３０６では、分散設定テーブルにおける該当画像処理サーバのステータスを”ＯＫ”にする。新規登録がなされた画像生成サーバについては単に”ＯＫ”が書き込まれるが、例えば、図１７に示す分散設定テーブル４１１１のインデックス４に対応する画像生成サーバが利用可能になった場合には、ステータス欄４００７で示されるステータスを”ＮＧ”が”ＯＫ”に変更される。

以上説明したように、本実施形態によれば、処理中に異常を来した画像生成サーバは、分散設定テーブルのステータスが”ＮＧ”に書き換えられて使用可能な画像生成サーバからはずされる。そして、再起動した時点で分散設定テーブルにおけるそのサーバのステータスが”ＮＧ”から”ＯＫ”に書き換えられ、今後の処理で利用されるようになる。

このため、オペレータがネットワークプリントシステムから使用できない画像生成サーバの切り離しや、復旧した画像生成サーバの再接続を行わなくとも、自動的に画像生成サーバの使用停止／使用再開が可能となる。このため、画像生成サーバを効率よく使用でき、分散処理の効率が向上する。
また、ある画像生成サーバが異常終了した場合でも、他の画像生成サーバで代替処理することにより、より安定度の高いシステムを提供することができる。

［第４の実施形態］
次に本発明の第４の実施形態に係るネットワークプリントシステムを説明する。本実施形態に係るシステムは、クライアントに複数のプリンタが接続され、Ｗｅｂブラウザの利用者がクライアントで帳票の印刷を指定した際に、クライアントで適切なプリンタを選択するシステムである。

図２０は、本実施形態に係るネットワークプリントシステムの構成を示すブロック図である。本システムは、ブラウザが動作しているクライアントの配下にプリンタが複数台存在する構成を有する。
図２０において、クライアント１２０１は、上述の実施形態におけるクライアントと同様、Ｗｅｂブラウザが動作しているコンピュータである。データ入出力部１２０２はサーバ１２１３とのデータ通信を行う。Ｗｅｂブラウザ１２１５は、第１の実施形態のＷｅｂブラウザ１１４と同じでよい。プリントデータ解析部１２０３は、クライアントに送付されたプリント用データを解析する。第１〜第３のプリント出力部１２０４、１２０５、１２０６は、プリント用データを実際のプリントイメージに変換し、プリンタにデータを送信する。プリンタ１２０７〜１２１０は、クライアント１２０１に直接又はネットワーク１２１１を介して接続されたプリンタを示す。ネットワーク１２１１は、クライアントとプリンタとを接続している。

ネットワーク１２１２は、図１のネットワーク１０５と同様、クライアント１２０１とサーバ１０６とを接続する。サーバ１０６は、図１に示す第１の実施形態のものと同一の構成を有するＷｅｂサーバであるため、同じ構成要素には同じ参照数字を付して重複する説明は省く。すなわち、本実施形態のシステム構成は、図１に示した第１の実施形態のシステム構成と、クライアントに複数のプリンタが接続されている点を除いて同一である。このため、クライアントはプリンタ毎に対応する複数のプリント出力部１２０４〜１２０６を有している。

通常は、Ｗｅｂブラウザから、帳票データのクライアントによる印刷が指示された場合、第１の実施形態において説明したように、画像生成部１１１において帳票テンプレートとそれと組み合わされるデータとが合成され、プリント出力部１１２において、その合成データに基づきページ記述言語（ＰＤＬ(Page Discription Language)）の様式に従ったプリントデータファイルが生成され、このプリントデータファイル（又はそのＵＲＬ）がクライアントに送信される。

この送信されたＰＤＬファイルは、クライアント１２０１のプリント出力部１２０４〜１２０６のいずれかによりプリンタに出力される。この時、望まれることは、サーバのプリント出力部１１２で作成したＰＤＬの形式と、クライアントに接続されたプリンタが解釈できるＰＤＬの形式が同一であることである。ただし、ＰＤＬには、多くの種類があり、また時とともに変更、更新されているのが現実であり、画像生成部１１２が生成できる形式と、クライアントに接続されたプリンタの解釈できる形式とが一致しないケースも多い。そこで、本実施形態では、クライアントのプリントデータ解析部１２０３にプリント出力部を選択する機構、すなわちプリンタを選択する機構を設け、できる限り正しくＰＤＬを解釈できるプリンタを選択できるようにしたことを特徴とする。

以下、図２１に示すフローチャートを用いて、本実施形態におけるプリントデータ解析部１２０３の動作を説明する。
まずステップＳ１３０１において、サーバ１０６より転送されてきたプリントデータファイルを受け取る。プリントデータファイルのヘッダ部分には、ＰＤＬの名称及びそのバージョンが書き込まれている為、ステップＳ１３０２ではそのヘッダ情報を解析し、ステップＳ１３０３にてそのＰＤＬの名称及びバージョンを保持しておく。

ステップＳ１３０４では、プリントデータ解析部１２０３におけるクライアント、すなわち自己の配下に複数存在するであろうプリンタの情報を解析する。すなわち、プリンタドライバであるプリント出力部１２０４〜１２０６の解析を行う。ステップＳ１３０５では、ステップＳ１３０４で解析したプリント出力部が、受信したプリントデータに対応しているか、厳密には、一致しているかをチェックする。もし一致している場合は、プリントデータをそのプリント出力部に送信する（ステップＳ１３０７）。この場合には、選択されたプリント出力部に対応したプリンタから、厳密な出力結果が得られる（ステップＳ１３０８）。

また、ステップＳ１３０５にて、プリントデータとプリント出力部とが一致しなかった場合は、存在する他のプリント出力部の解析を行う。ステップＳ１３０６にて、すべてのプリント出力部の解析が終了したと判断された場合には、予め設定されているデフォルトのプリント出力部へデータを転送し（ステップＳ１３０９）、デフォルトプリンタからプリント出力を行なう（ステップＳ１３１０）。この場合には、プリント出力部のＰＤＬがプリントデータファイルを記述したＰＤＬと一致していないため、望まれる出力が、正確に出力される保証はない。場合によってはＰＤＬの不一致により、プリント出力不可能の場合もある。

以上説明したように、本実施形態においては、クライアントに複数のプリンタが備えられている場合、サーバから受信したプリントデータを正しく解釈できるプリンタを自動的に選択し、正確な出力結果を得ることができる。

［第５の実施形態］
次に図２２を参照して、本発明の第５の実施形態に係るネットワークプリントシステムについて説明する。本実施形態は、ネットワーク上に複数のＷｅｂサーバを有することを特徴とする。

図２２は本実施形態に係るネットワークプリントシステムの構成を示す図である。システムの各構成要素については第１又は第２の実施形態において説明したものと同様である。すなわち、クライアント１７０１，１７１１は、図１及び図９のクライアント１０１と同じ構成であり、Ｗｅｂサーバ１７０３，１７１３は、図９のＷｅｂサーバ９０１と同様である。また、画像生成サーバ１７０８，１７１８は、図９の画像生成サーバ９０８，９０９と同じものである。
また、図２２のシステムにおいても、第１の実施形態と同様に、クライアントで表示された帳票データの印刷を指示すると、そのデータとそれに組み合わされる帳票テンプレートとが画像生成サーバで合成され、サーバあるいはクライアントから印刷することができる。したがって、クライアント及びＷｅｂサーバが複数存在する点においてのみ、図２２の構成と図９の構成は異なっている。

図２２において、クライアント１７０１はネットワーク１７０２を通じてＷｅｂサーバ１７０３に接続する。Ｗｅｂサーバ１７０３は画像生成サーバ１７０８，１７１８に接続している。各画像生成サーバは、Ｗｅｂサーバから受信した依頼に従ってプリントデータや表示用のＨＴＭＬ文書データを生成して（プリント依頼の場合はプリント出力を行ない、終了通知を）依頼元のＷｅｂサーバに返送する。そのデータは、再度ネットワーク１７０２を通じて要求元のクライアント１７０１に返される。

同様に、クライアント１７１１はネットワーク１７１２を通じてＷｅｂサーバ１７０３に接続し、処理要求を行なうことができる。この場合、Ｗｅｂサーバ１７０３は、クライアント１７０１からの処理要求を受信した場合と同様な処理を行う。

このように、Ｗｅｂサーバは複数のクライアントから処理要求を受け取り、処理を行うことが可能であるが、接続クライアント数が増え、並行して処理を行わなければならなくなると処理速度が低下する。

そこでクライアント１７１１がネットワーク１７１４を通じてＷｅｂサーバ１７１３にも接続し、Ｗｅｂサーバ１７１３の資源を利用することによりＷｅｂサーバ１７０３にかかる負荷を下げることが可能になる。ネットワーク１７０２，１７１２，１７１４を電話網等を介したネットワークにしておけば、ネットワークの切換えは、単に接続先のＷｅｂサーバを切り替えるだけでよい。すなわち、クライアントのＷｅｂブラウザから、接続したいＷｅｂサーバのＵＲＬを切り替えて指定すればよい。

このように、本実施形態のシステムにおいては、複数の画像生成サーバ１７０８，１７１８を複数のＷｅｂサーバ１７０３とＷｅｂサーバ１７１３から共通して使用することが可能である。

画像生成サーバが１台しかなければ、Ｗｅｂサーバ１７０３，１７１３ともその画像生成サーバに対して画像生成の依頼を発行する。このため、特にスケジュール管理等は不要である。しかしながら、図２２のように複数の画像生成サーバが複数のＷｅｂサーバと接続されている場合、各Ｗｅｂサーバがどの画像生成サーバを使用するか決定する手順が必要となる。その手順としては、次のような例が考えられる。
（１）予めＷｅｂサーバと画像生成サーバとを対応づけておく。この場合、ひとつのＷｅｂサーバに対して複数の画像生成サーバが割り当てられれば、第２の実施形態あるいはその変形例の要領で、使用する画像生成サーバを決定する。
（２）図１１あるいは図１３に示した分散設定テーブルを各Ｗｅｂサーバで共有し、画像生成サーバを管理する。このためには、図１０のステップＳ１００５、
あるいは、図１４のステップＳ１５０４，Ｓ１５０６及び図１５のステップＳ１６０４で分散設定テーブルを更新する都度、各Ｗｅｂサーバは、更新したテーブルを他のＷｅｂサーバに送信しなければならない。

以上説明したように、本実施形態によれば、Ｗｅｂサーバを複数用意することで、各Ｗｅｂサーバの負荷を軽減し、システムとしての処理効率が向上したネットワークプリントシステムを実現することができる。

［第６の実施形態］
次に、本発明の第６の実施形態について説明する。図２３は、本実施形態に係るネットワークプリントシステムのソフトウエアブロック図であり、ここでは、サーバ、クライアントともに１台ずつ示している。第１の実施形態において説明した図１と図２３とを比較すると明らかなように、Ｗｅｂサーバ１２０が画像格納部１１８及び１１９を有すること以外、本実施形態に係るシステムと第１の実施形態に係るシステムとの構成は同一である。そのため、既に説明した構成についての説明はここでは省略する。

サーバ１２０が有する画像格納部１１８，１１９はハードディスク装置等、画像データを格納するための装置によって実現され、画像格納部１１８はクライアント１０１に公開されておらず、またクライアントからアクセスできない領域である。これに対して画像格納部１１９はクライアントに対して公開されており、クライアントが画像格納部１１９に含まれるファイルのＵＲＬを指定することで、そのファイルにアクセスできる。

＜表示要求の処理＞
本実施形態の処理を説明する前に、第１の実施形態において説明した、Ｗｅｂブラウザ１１４のウィンドウ（図２）画面上で表示ボタン２０８が押された場合の従来の処理を説明する。
図２４は、従来の手法による、表示時のサーバ及びクライアントによる処理手順のフローチャートである。以下に説明するように、この従来の処理では、クライアントに返されるべき生成された画像ファイルは、クライアントから参照可能な画像格納部１１９に置かれる。

図２４において、まず、クライアント１０１から、表示したい画像に関する情報を含んだ画像リクエスト（ステップＳ７２１０）が、ネットワーク通信制御部１０７を通じてＷｅｂサーバ１２０に送られる。

Ｗｅｂサーバではリクエストの内容が解析され、処理の実行が開始される（ステップＳ７２０２）。Ｗｅｂサーバ１２０は、必要な画像生成処理を、画像生成部１１１に依頼する（ステップＳ７２０３）。画像生成部１１１は依頼に基づく画像生成処理を行ない（ステップＳ７２９０）、その結果である生成画像は、Ｗｅｂサーバに送られ、Ｗｅｂサーバ中のクライアントから参照可能な画像格納部１１９に格納される（ステップＳ７２０４）。

なお、画像生成部１１１は他の実施形態において説明されているように、サーバ本体と通信可能に接続され、画像生成部の機能を有する独立したコンピュータ（画像生成サーバ）により実現されても良い。この場合には、ステップＳ７２９０はその画像生成サーバで実行される。

Ｗｅｂサーバ１２０はここで、図２５で表される構造を持ったデータブロック（ＨＴＭＬ文書）７２１９をネットワーク通信制御部１０７を通じてクライアント１０１に返す（ステップＳ７２０５）。このデータブロックは、ヘッダ部７２２０と内容部７２３０からなり、ヘッダ部７２２０には、内容部７２３０にはＨＴＭＬ文書が格納されていることが内容種別として記述されている。また、内容部のＨＴＭＬ文書中には、クライアント１０１の要求に対して生成された画像ファイルへの参照パス（/InetPub/wwwroot/img_dir/tem03.pdf）が埋め込まれている。

クライアント１０１では、データブロック７２１９を受け取ると、画像ファイルへの参照が埋め込まれていることを検出し、Ｗｅｂサーバ１２０に対してその参照パスに対応する画像ファイル転送要求を送信する（ステップＳ７２１１）。この画像ファイル転送要求を受けて、Ｗｅｂサーバは画像格納部１１９から画像ファイルを読み出し（ステップＳ７２０６）、図２６で示されるようなデータブロック７２３９として、クライアント１０１に転送する（ステップＳ７２０７）。

データブロック７２３９は、ヘッダ部７２４０と内容部７２５０からなり、ヘッダ部７２４０には、内容部７２５０に画像データが格納されていることが内容種別として記述されている。また、内容部７２５０には、生成された画像ファイルの内容が格納されている。クライアント１０１はデータブロック７２３９を受け取り（ステップＳ７２１２）、Ｗｅｂブラウザ１１４の画面内に受信した画像を表示する（ステップＳ７２１３）。

これに対して、本実施形態に係るシステムでは、Ｗｅｂサーバは、生成された画像をクライアントからは参照不可能な画像格納部１１８に置くようにすることにより、生成結果の画像ファイルに対する安全性を確保したものである。以下本実施形態における表示処理について、図２７のフローチャートを用いて説明する。

まず、クライアント１０１から、表示したい画像に関する情報を含んだ画像リクエスト（ステップＳ７３１０）が、ネットワーク通信制御部１０７を通じてＷｅｂサーバ１２０に送られる。
Ｗｅｂサーバではリクエストの内容が解析され、処理の実行が開始される（ステップＳ７３０２）。Ｗｅｂサーバ１２０は、必要な画像生成処理を画像生成部１１１に依頼する（ステップＳ７３０３）。画像生成部１１１は依頼に基づく画像生成処理を行ない（ステップＳ７２９０）、その結果である生成画像は、Ｗｅｂサーバ１２０に送られ、Ｗｅｂサーバ中のクライアントから参照不可能な画像格納部１１８に格納される（ステップＳ７３０４）。

ここで、いったん画像格納部１１８に画像ファイルを置くのは、要求を行なったクライアント１０１以外から生成結果の画像ファイルへのアクセスを行えないようにするためだけではなく、クライアント１０１から同一のユーザが同一の画像リクエストを発生した場合に、再度、画像生成部１１１に同じ画像の生成処理を要求することなく、画像格納部１１８にすでに格納されている画像ファイルをクライアント１０１に転送することで処理を高速化することを可能とするためでもある。

すなわち、従来の処理方法で安全性を確保するためには、例えば、あるユーザが偶然にも他のユーザの画像を読み出すのを防ぐために、画像の転送要求を行なったユーザが、画像格納部１１９に生成されたその画像を読み出した後に、すぐにその画像が削除される必要がある。そのため、同一ユーザが再度同一画像の生成を依頼した場合であっても再度処理を行なわねばならなかった。
しかし、本実施形態の構成では画像格納部１１８に生成画像を格納するため、生成した画像を削除する必要がなく、同一ユーザからの同一画像の転送依頼が発生した場合には、記憶された画像をそのまま転送すればよい。

さらにＷｅｂサーバ１２０は、図２６で表される構造を持ったデータブロック７２３９をネットワーク通信制御部１０７を通じてクライアント１０１に返す（ステップＳ７３０５）。前述の通り、データブロック７２３９は、ヘッダ部７２４０と内容部７２５０からなり、ヘッダ部７２４０には、内容部７２５０に画像データが格納されていることが内容種別として記述されている。また、内容部７２５０には、生成された画像ファイルの内容が格納されている。

本実施形態においては、生成結果の画像ファイルがクライアントからアクセス不可能な画像格納部１１８に格納されるため、前述の従来例のようにクライアントにファイルパスを送信することができない。従って、ファイルの生成が終了するとクライアントに直接画像ファイルを送信している。
クライアント１０１は、このデータブロック７２３９を受け取ると（ステップＳ７３１２）、ブラウザの画面内に、データブロックに埋め込まれた画像ファイルを基にして画像を表示する（ステップＳ７３１３）。

以上説明したように、本実施形態においては、クライアントからの要求に応じて生成した画像ファイルをクライアントからアクセス不可能な領域に格納し、その画像を生成する要求を発行したクライアントに対してのみ、当該画像を送信する。これにより、画像を格納したディレクトリを不特定のクライアントに公開しなくとも、画像生成を要求するクライアントに対しては確実に画像ファイルを送信できる。
また、クライアントのＷｅｂブラウザは、ＵＲＬを参照しないため受信した画像データをキャッシュせず、常にサーバから受信した画像を表示できる。

［第７の実施形態］
次に、本発明の第７の実施形態に係るネットワークプリントシステムにおける表示処理を、図２８のフローチャートを用いて説明する。
図２８において、図２７と同じ処理については同じステップ番号を付与し、その説明は省略する。第７の実施形態では、第６の実施形態と比較して以下の部分の動作を変更している。

リクエスト解析ステップ（ステップＳ７６０２）において、まず、クライアントからの画像リクエストから、ユーザーセッションを識別する。さらに、要求された画像生成がおなじユーザーセッションですでに実行されているものかどうかを、セッション・画像生成ジョブ対応表記憶部に記憶されたエントリを調べることにより決定する。セッション・画像生成ジョブ対応表記憶部は、処理中及び／又は処理済みのセッションと、そのセッションで要求のあった処理内容、処理結果、すなわち生成された画像ファイル等の格納位置を対応付けして記憶するものである。セッション・画像生成ジョブ対応表記憶部は図２３には示されていないが、後述する図３０のように、図２３に示すＷｅｂサーバ１２０にも含まれているものとする。

条件判断ステップ（ステップＳ７６５０）により、以前に実行されていた画像生成ジョブと同じ画像を要求していると判定された場合、すでに画像格納部１１８に格納されている生成画像ファイルを読み出す（ステップＳ７３０５）。なお、ステップＳ７６５０における判定は、セッションＩＤとクライアントからの要求の内容、例えば画像を生成させる指示や、そのパラメータが以前受信したものと一致していれば、以前に要求されていると判定できる。

Ｗｅｂサーバは、画像格納部１１８から読み出した画像ファイルを、第６の実施形態における処理と同様に、図２６で表される構造を持ったデータブロックに格納してクライアントに送信する（ステップＳ７３０５）。

一方、条件判断ステップ（ステップＳ７６５０）により、新しい画像生成ジョブであると判断された場合には、ステップＳ７３０４以降、第６の実施形態と同一の処理を行なう。

以上説明したように、本実施形態によれば、要求元のクライアントにのみ処理結果を送信するため、他のクライアントに処理結果をアクセスされるおそれがない上、クライアントから処理済みの要求と同じ要求を受信した場合には、以前の処理で生成した結果を返送することにより、サーバは同じ処理を繰り返し行う必要がないため、処理のための資源を節約できる他、処理の高速化が実現できる。

［第８の実施形態］
次に、本発明の第８の実施形態に係るネットワークプリントシステムにおける表示処理を、図２９のフローチャートを用いて説明する。
上述の第６及び第７の実施形態においては、処理結果の画像ファイルを強制的にクライアントから参照不可能な画像格納部１１８に格納していた。本実施形態においては、従来の方法と本発明による方法とのいずれを用いるかをクライアントから選択できるようにしたことを特徴とする。すなわち、画像生成処理が終了した時点で、画像ファイルをすぐに返送する（以下「内容渡し」という）か、画像ファイルへのパスを返送するかをクライアントから選択できる。
図２９において、Ｗｅｂサーバの処理で図２７と同じ処理については同じステップ番号を付与し、その説明は省略する。また、クライアントの処理は図２４における従来方法と同一であるため、やはりその説明は省略する。第８の実施形態では、第６の実施形態と比較して以下の部分の動作を変更している。

リクエスト解析ステップ（ステップＳ７７０２）において、まず、クライアント１０１からの画像生成リクエストから、内容渡しによる方法と、画像ファイルへの参照パスを渡す方法のどちらが要求されているのかを決定する。画像生成処理（ステップＳ７７０３、ステップＳ７３９０）を行った後、ステップＳ７７０２においてどのような応答方法が決定されたのかを調べる（ステップＳ７７５０）。

内容渡しによる方法が選択されていれば、ステップＳ７７０５に進んで、クライアント１０１から参照不可能な画像格納部１１８に生成された画像ファイルを格納した後、Ｗｅｂサーバ１２０は、この画像ファイルを、図２６で表される構造を持ったデータブロック７２３９の内容部に格納してクライアントに返す（ステップＳ７７０６，Ｓ７７０７）。

一方、ステップＳ７７５０において、画像ファイルへの参照パス渡しによる方法が選択されている場合は、ステップＳ７７０４に進んで、クライアント１０１から参照可能な画像格納部１１９に生成された画像ファイルを格納した後、Ｗｅｂサーバ１２０は、この画像データへの参照パスを含んだＨＴＭＬ文書を内容部に有する、図２５に示したデータブロック７２１９をクライアント１０１に返す（ステップＳ７７０５）。

データブロック７２１９を受信したクライアントは、図２４を用いて説明したように、内容部に含まれる参照パスを用いてＷｅｂサーバ１２０にファイル転送を要求し（ステップＳ７２１１）、Ｗｅｂサーバ１２０が画像格納部１１９から対応するファイルを読み出して転送する（ステップＳ７７０６、Ｓ７７０７）。そして、クライアントは受信した画像ファイルをブラウザ１１４の画面に表示する（ステップＳ７２１３）。
このように、本実施形態によれば、クライアントからの要求で応答方法を指定することによって、クライアント側から、画像ファイルの渡し方を指定でき、不特定のクライアントから画像ファイルにアクセス可能とすることもできるし、不可とすることもできる。

［第９の実施形態］
図３０は、第６乃至第８の実施形態に係るネットワークプリントシステムにおいて、図９に示した第２の実施形態のように、画像生成処理をＷｅｂサーバとは異なるコンピュータ上に配置して処理を分散させる場合の構成を示すブロック図である。

図３０において、クライアント７０９０は、図２３のクライアント１０１と同様の構成を有する。Ｗｅｂサーバ７０００は、負荷分散制御部７００５を有している点と、画像生成部を有していない点とを除いて、図２３のＷｅｂサーバ１２０と同様の構成である。

画像生成サーバ７００６及び７００９とは同じ構成を有しており、Ｗｅｂサーバ７０００やクライアント７０９０と同様のコンピュータ装置である。そして、Ｗｅｂサーバ１２０が有していた画像生成部１１１と同等の機能を有する画像生成部７００７及び７０１０が各画像生成サーバ７００６及び７０１０に設けられている。画像生成サーバ７００６及び７００９と、Ｗｅｂサーバ７０００は、ネットワーク７０８０を介して互いに通信可能に接続される。

画像生成部等の負荷分散を行う負荷分散制御部７００５は、ラウンドロビン方式や、各画像生成部の負荷を示す係数をカウントするなどの方法により、画像生成処理の負荷を、画像生成部７００７，７０１０を有する画像生成サーバ７００６及び７００９に振り分けて分散する。

図３０の構成においては、単に画像生成部を画像生成サーバとして独立させたものであり、画像生成部を使用するにあたって、画像生成処理の依頼の送信や生成された画像データの受信を、ネットワーク７０８０を介して行わねばならない点が第６乃至第８の実施形態と異なる点であり、Ｗｅｂサーバ及びクライアントによる制御手順そのものは、図２７，図２８，図２９で説明した手順と同様でよい。

［第９の実施形態の変形例１］
図３１は、図３０の構成において、画像生成部のみならず、生成された画像データを格納するための画像格納部（クライアントから参照できない）を画像生成サーバに持たせた構成のシステムを示す。

このシステムでは、Ｗｅｂサーバ１２０内に画像ファイルを格納する代わりに、画像生成サーバ７１０４または７１０８の画像格納部７１０７，７１１１に保存する。本変形例においてこれらの画像格納部は、クライアント７０９０からの参照は不可能な領域としているため、この構成により、第６又は第７の実施形態（図２７あるいは図２８の処理手順）で説明したような表示処理を実行することが可能である。

この場合、画像生成部での処理が終了したら、画像生成部が同じ画像生成サーバに含まれる画像格納部にファイルを格納してから、Ｗｅｂサーバに処理終了通知及び処理結果の画像ファイルの格納位置通知を行なうようにすればよい。

［第１０の実施形態］
次に、本発明の第１０の実施形態に係るネットワークプリントシステムについて説明する。本実施形態は、Ｗｅｂサーバからクライアントに送信される画像ファイルやプリントデータファイルを暗号化する手段をＷｅｂサーバに、暗号化ファイルを復号化する手段をクライアントに設けることにより、通信の秘匿性を高めたシステムに関する。

本実施形態において、Ｗｅｂサーバは例えば図１に示す構成を有しており、データ処理部１１０にファイル暗号化の機能を付加することによって、画像生成部１１１で生成された画像データやプリントデータを所定の方法で暗号化してクライアントに送信することが可能である。
暗号化方法及びその実現方法は任意であり、通常通信分野で用いられている方法を適用することができる。

図３２は、本実施形態におけるクライアントの構成を示すブロック図である。図において、５５０１はＣＰＵであり、後述する暗号化ファイルの復号化処理もＣＰＵによりプログラムを実行することで実現される。
５５０２は通信モジュールであり、図１におけるデータ入出力部１０２と同等の機能を有する。Ｗｅｂサーバと通信を行い表示データや印刷データを得る。

５５０３は受信データブロックであり、通信モジュール５５０２を介して受信したデータを格納するメモリブロックである。これはメモリブロックは所謂外部メモリで構成することもでき、その場合受信データブロックはデータファイルとなる。
復号データブロック５５０４は受信データブロックに記憶された暗号化ファイルの復号結果を格納するメモリブロックである。受信データブロック５５０３と同様、データファイルで構成しても構わない。

５５０５は印刷モジュールであり、復号したプリントデータをプリンタ５５０６に送る機能を持つモジュールであり、例えば印刷スプールやパラレルケーブル装置である。
５５０６はプリンタである。

５５０７は暗号を復号するための情報（復号キー）を保持する復号キーブロックである。復号キーブロック５５０７も他のデータブロック５５０３、５５０４と同様、メモリ領域やデータファイルで構成することができる。復号キーは、クライアントで動作するプログラムに予め埋め込んでおいたり、クライアントにプログラムをインストールするときにユーザが入力する方法等、任意の方法を選択できる。

次に、図３３に示すフローチャートを用いて、図３２に示したクライアントにおける復号化処理動作について説明する。以下の説明では、クライアントからクライアントのプリンタ５５０６での印刷要求をＷｅｂサーバに送信し、その結果としてＷｅｂサーバから暗号化されたプリントデータファイルを受信したものとする。

まず、ステップＳ５６０１で通信モジュール５５０２を通じてプリントデータファイルを受信し、受信データブロック５５０３にデータを格納する。前述の実施形態で説明したように、データファイルは、Ｗｅｂサーバから送られる場合や、クライアント側で動作するプログラムがＷｅｂサーバからダウンロードする場合があるが、本実施形態においてはいずれの場合でも構わない。

受信したデータの構成例を図３４に示す。
受信データはデータの内部構造を表すヘッダ部５７１０とプリントイメージそのものであるイメージ部５７１１から構成される。
さらに、ヘッダ部５７１０にはイメージ部５７１１の内容が暗号化されているか否かを表すフラグ領域５７０１を有し、暗号化されている場合にはＯＮが記述され、暗号化の種別を表す情報も記述される。

次に、ステップＳ５６０２で、受信したデータのヘッダ部５７１０のフラグ領域５７０１を参照し、イメージ部が暗号化されているか、どのような暗号化方法が用いられているかの情報を得る。
本実施形態においては受信したファイルが暗号化されているため、ステップＳ５６０３では、ステップＳ５６０２で得た情報を元に、復号キーを復号キーブロック５５０７から得る（ステップＳ５６０３）。

次いで、ステップＳ５６０３で得た復号キーを用いて、受信データブロック５５０３に格納された暗号化ファイルを復号化し、復号結果を復号データブロック５５０４に格納する（ステップＳ５６０４）。
そして、復号データブロックから順次復号化したデータを読み出し、印刷モジュール５５０５を介してプリンタ５５０６に出力する。

［第１１の実施形態］
次に、本発明の第１１の実施形態に係るネットワークプリントシステムについて説明する。本実施形態は、第１０の実施形態において、Ｗｅｂサーバから受信したデータが複数のデータブロックから構成される場合に特に有効に適用される。

例えば、複数のテキストデータや画像データからプリントデータが構成され、それらが個別にＷｅｂサーバからクライアントに送信される場合、テキストやイメージといったデータの種類の違いに応じて暗号化するかどうかを選択したり、暗号化の方法を切り替えることが考えられる。

なぜなら、暗号化自体長い処理時間を必要とする上、暗号化方法によっては復号するためにさらに多大な計算時間を要するものがあり、システムにとって無視できない負荷となりうるからである。また、処理時間が係ることによってクライアントのユーザも処理を待たされることになり、使い勝手が悪くなるという問題もある。

以下、図３５に示すフローチャートを用いて、本実施形態における復号化処理動作を説明する。復号化を行なうクライアントの構成は第１０の実施形態のものと同一でよい。図３５に示す処理も、図３３の処理と同様、クライアントのＣＰＵ５５０１が図示しない外部メモリやＲＯＭ等に記憶されたプログラムを実行することによって実現される。

また、以下の説明では、クライアントからクライアントのプリンタ５５０６での印刷要求をＷｅｂサーバに送信し、その結果としてＷｅｂサーバから個別に暗号化された複数のデータブロックから構成されるプリントデータファイルを受信するものとする。

ステップＳ５８０１は複数のプリントデータから構成されるある１つのプリントジョブの開始を意味する。例えば、複数ページからなるイメージを含むドキュメントの印刷である。
ステップＳ５８０２では、プリントジョブを構成する受信データが残っているかを判断する。

受信データがある場合は、ステップＳ５８０３でデータを受信し、受信データブロック５５０３にデータを格納する。
ステップＳ５８０４では、受信したデータブロックのヘッダ部のフラグ領域５７０１を参照し、そのデータブロックが暗号化されているか否か、そのデータブロックのデータ種別は何かについて情報を取得する。データ種別は図２５及び図２６で示したように、データブロックのヘッダ部を参照することによって判別できる。

ここで、復号キーの選択について図３６に示す復号キーブロック５５０７の構成例を用いて説明する。
復号キーブロック５５０７に含まれる復号キーの総数は任意であるが、本実施形態においては、復号キーブロック５５０７には、４つの複合キー（復号キー１、復号キー２、復号キー３、その他の復号キー）が格納されている。

図３５のステップＳ５８０４では、受信したデータの種類に応じて、図３２の復号キーブロックのどの復号キーを用いるかを決定する。例えば、テキストデータであれば復号キー１、イメージデータであれば復号キー２、というように予めシステム内で定義しておき、それに従う。

ステップＳ５８０６ではステップＳ５８０４で決定された復号キーを用いて受信データブロック５５０３に格納された暗号化データブロックを復号化し、復号化結果を復号データブロック５５０４に格納する。

ここで、本実施形態では、１つのジョブが複数のデータブロックで形成されるため、復号データファイルも複数存在する。従って、復号データブロック５５０４はデータが順次追加できるように構成される。
例えば、データを追加するたびに次回どのアドレスに書き込めば良いかというデータも同時に保持しておくという方法でデータを追加していくことが可能となる。

以後、ステップＳ５８０２からステップＳ５８０６までの処理を受信データが無くなるまで繰り返し、ステップＳ５８０２において受信データが無くなったことを検出したら、ステップＳ５８０７で復号データブロック５５０４から復号データを読み出して、ステップＳ５８０８で印刷モジュール５５０５を介してプリンタ５５０６に出力する。

［第１２の実施形態］
次に、本発明の第１２の実施形態に係るネットワークプリントシステムについて説明する。前述の第１０及び第１１の本実施形態に係るシステムでは、受信したデータブロックのヘッダ部から得た情報又はデータブロックのデータ種別によって復号化キーを決定していたが、本実施形態のシステムでは、復号化する際にＷｅｂブラウザとＷｅｂサーバの間で保持されるセッション情報に基づいた復号キーを用いることによって、更に秘匿性の高い通信が可能なネットワークプリントシステムを提供することを特徴とする。

図３７は本実施形態におけるＷｅｂサーバのシステムブロック図で、６６０１はＣＰＵを示し、以下で説明する処理のプログラムを実行する。６６０２は通信モジュールであり、図示しないクライアントとの間の通信を行う。６６０３はセッションＩＤブロック、６６０４は新規セッションＩＤブロックである。また、６６０５はセッションＩＤと復号化キーとを対応付けして記憶するメモリブロックである。

第２の実施形態において説明したように、一般にＷｅｂシステムは、サーバとクライアント間の１回の要求、応答でセッションは終了してしまい、クライアントを区別する仕組みはない。そのため、本実施形態においても、サーバの位置情報を示すＵＲＬの中にセッションＩＤを導入する方法を採用する。

図３８に示すフローチャートを用いて、セッションＩＤの導入処理について更に説明する。まず、ステップＳ６７０１で、あるクライアントから要求がを受け付けた時、そのＵＲＬにセッション番号が付加されているか否か、ステップＳ６７０２で判定する。もしＵＲＬ中にセッションＩＤが付加されていない場合は、このクライアントからの、新たなセッション開始とみなし、ステップＳ６７０３で新規セッションＩＤを生成し、ステップＳ６７０４でこの要求に対しそのセッションＩＤを付与する。このセッションＩＤ付のＵＲＬは、要求に対応した処理が終了した後、クライアント側に返され、同じクライアントが同セッション内でＷｅｂサーバに次の要求を行う場合は、セッションＩＤ付きのＵＲＬを持ってサーバへの再アクセスを行う事になる。

ステップＳ６７０３における新規セッションＩＤの生成は例えば次の手順で行われる。サーバは使用中セッションＩＤブロック６６０３に使用中のセッションＩＤを保持しておく。
ステップＳ６７０２において、セッションＩＤを含まないＵＲＬであると判定された場合、乱数を用いて新規セッションＩＤを生成し新規セッションＩＤブロック６６０４に保持する。

この値が使用中セッションＩＤ保持ブロック６６０３中になければ新規セッションＩＤとして認め、その値をブロック６６０３に格納し、かつその値をステップＳ６７０３においてＵＲＬに付加する。
乱数ではなく、単純にカウントアップで他のセッションＩＤと重複しない値を得ても構わないが、本実施形態ではセッションＩＤを暗号化処理に用いるため、乱数のほうがよりセキュリティを守る効果が期待できる。

次に、図３９に示すフローチャートを用いて、セッションＩＤを暗号化に用いる手順について説明する。
図４０はサーバ上で保持されるメモリブロック６６０５の構成を示す図である。図からわかるように、メモリブロック６６０５はテーブル構造を持つ。テーブルのキーは上述のセッションＩＤである。値は暗号を復号するときに必要な復号キーが格納される。

まず、ステップＳ６８０１において、Ｗｅｂサーバがクライアントからの要求に応答してプリント画像を生成したものとする。
次いでステップＳ６８０２で、Ｗｅｂサーバはこのセッションに付与されたセッションＩＤを用いて、後に暗号化されるプリント画像ファイルをクライアントで復号化するための復号キーを発生させる。ここで、復号キーは上述の通り乱数を用いるとより高い秘匿性が得られるため好ましい。

ステップＳ６８０３で、メモリブロック６６０５に、セッションＩＤをキーとし、復号キーを値としてテーブルにキーと値の組を格納する。
例えば、図４０に示す例では、キー１１２１に対して復号キーとしての値１８７７３７２１６が、キー４８２７に対し値９８６７３６２８が格納されている。セッションＩＤから復号キーを生成する方法は、予め定めた任意の方法を用いることができる。

ステップＳ６８０４で、復号キーで復号可能な暗号化によって、プリント画像データが暗号化され、クライアントに送信される。
ステップＳ６８０５で、クライアントが暗号化された画像データを受信する。
クライアントは、セッションＩＤを既に知っているため、ステップＳ６８０６で、そのセッションＩＤを用いてサーバに復号キーを問い合わせる。この際、セッションＩＤは特定のユーザからの持続した接続しか許さないので、他のユーザからの要求は拒絶される。

ステップＳ６８０７で、クライアントに対して復号キーが返されるので、クライアントは復号キーを用いて暗号化された画像データを復号することができ、直接或いはネットワークを介して接続されたプリンタから出力することが可能となる。

なお、本実施形態におけるクライアントの構成については特に述べなかったが、図３９のステップＳ６８０５〜Ｓ６８０８で説明した処理が可能であれば任意の構成のクライアントを用いることができる。例えば図３２に示す構成のクライアントを用い、図３９のステップＳ６８０５〜Ｓ６８０８で説明した処理をＣＰＵ５５０１で実行可能なプログラムを図示しない外部メモリ等に記憶しておけばよい。

［第１３の実施形態］
次に、本発明の第１３の実施形態に係るネットワークプリントシステムについて説明する。第１１及び第１２の実施形態においては、クライアント−Ｗｅｂサーバ間のセキュリティを高めたシステムについて説明したが、本実施形態はクライアントのユーザ間のセキュリティを高めたことを特徴とする。

すなわち、会社などの組織において、職制に応じて印刷、表示が可能な内容が異なることは珍しくない。以下、本実施形態に係るシステムにおいて、Ｗｅｂブラウザユーザの権限により、出力できる内容を制限する場合の処理について説明する。なお、本実施形態に係るシステムは、図１に示す構成において、Ｗｅｂサーバ１０６のデータ格納部１０９に後述する権限テーブルを有している構成により実現でき、以下の処理はサーバ１０６のＣＰＵ１０１ａ（図８）が外部メモリ１０１ｃに記憶されたプログラムを実行することで実施することができる。

まず、印刷処理全体を制限する場合の処理について、図４１に示すフローチャートを用いて説明する。
ステップＳ３７０１では、ユーザがＷｅｂブラウザ１１４（図１）を介してＷｅｂサーバ１０６にアクセス（ログイン要求）する。これに応答して、ステップＳ３７０２でサーバからユーザ認証を求める画面がブラウザに表示される為、ユーザは例えばユーザＩＤ、パスワード等を入力する。Ｗｅｂサーバのデータ処理部１１０では、入力されたユーザＩＤ及びパスワードをデータ格納部１０９に含まれる、ユーザ情報を格納するデータベースと照合する。

図４２に示すように、データ格納部１０９には、ユーザＩＤとその印刷権限が予め登録されており、このテーブルを参照することにより、ログインユーザの印刷権限を知ることができる。そして、以後このユーザから処理を要求されると、権限に基づく処理を行なう。

ステップＳ３７０３で、ユーザからＷｅｂサーバに対して新たなページの表示要求が行われたとする。Ｗｅｂサーバ１０６は、ここで、次に表示するページが印刷対象のページであるか否か、すなわちそのページに印刷ボタンが含まれるか否かを判定する。もし、印刷ボタンが含まれない通常のページであれば、ステップＳ３７０７に移行する。

一方、ステップＳ３７０４において印刷対象のページであると判断されたならば、ステップＳ３７０２で得て保持されているユーザ権限を参照し、印刷権限があると認められた場合は、印刷ボタンを含んだページ表示用データを送信する（ステップＳ３７０６）。権限がない場合は、ステップＳ３７０７であらかじめ用意してある印刷ボタン無しのページ表示用データを送信する。従って、印刷権限がないユーザから表示要求されたページには印刷ボタンがなく、帳票印刷は行われない。

もちろん、印刷ボタン表示のみをＯＮ、ＯＦＦできる場合には、送信するページ表示用データを共通として、印刷ボタン表示のみを権限の有無によって変更するように構成しても良い。

次に、帳票の項目毎に権限を設定する場合の処理について説明する。この場合、非権限者が操作した場合、一部の要点となるような項目は表示も印刷もされないようにすることができる。図４３は、第１の実施形態において説明した、帳票テンプレートの可変データテーブル（図３）の一部として、本実施形態で追加した項目を示す図である。

図に示すように、本実施形態においては可変データのインデックス毎に、権限による表示、印刷の可否が登録されている。図４３の可変データテーブルにおいて、３８０１の列は、テンプレートの可変データが埋め込まれる事を示すインデックスである。３８０２では、３８０１インデックスが示すエリアの名称であり、必ずしも必要ではないが、インデックスのみではデータの意味がわからないため、管理者等の作業のために設けられている。３８０３，３８０４，３８０５は、権限の種類により表示、印刷を行うか否かを示すフラグである。

図４３に示す例では、権限１を有するユーザは、全項目について表示及び印刷を行い、権限２を有するユーザは、部署名、性別、小計、合計は表示、印刷されるが社員番号及び氏名は表示、印刷されない。その他の権限を有するユーザは、性別と合計のみが表示、印刷されることになる。この可変データファイルは、Ｗｅｂサーバ内のデータ格納部１０９に格納される。また、各ユーザが有する権限の種類は、図４２に示したテーブルにおいて、印刷権限の欄を権限の種類の欄に置き換えた構成を有するテーブル等に予め登録されて、データ格納部に記憶しておく。

次に、図４４に示すフローチャートを用いて、図４３に示す設定がなされている状態でＷｅｂブラウザ画面で印刷ボタンが押された場合の、Ｗｅｂサーバ（画像生成部１１１）の動作を説明する。以下の説明においては、ユーザのログインが終了し、ユーザが有する権限の種類が既に取得されているものとする。

第１の実施形態で説明したように、印刷ボタンが押され（ステップＳ３９０１）、その通知を受信すると、Ｗｅｂサーバでは、このプリント処理で使用する帳票のテンプレートを検知する（ステップＳ３９０２）。ステップＳ３９０３では、Ｗｅｂサーバ内等にあるデータ格納部から帳票作成に必要な可変データテーブルを検索し、帳票テンプレートへのデータ埋め込みの準備を行う。

ここでは、印刷に使用する帳票テンプレートが図４３に示すデータテーブルに対応しているものとする。そして、帳票内における各項目の位置を検知（ステップＳ３９０３）するとともに、３８０１のインデックスＮ１，Ｎ２…に対応するデータの検索を行う。そして、ステップＳ３９０４にてユーザの権限情報を得ると同時に、図４３で可変データテーブルから、印刷項目のファイルを読み込む。

次のステップでは、インデックスの順に対応する値と図４３に示される印刷項目ファイルの権限情報との比較を行う。ステップＳ３９０５において、最初にインデックスを１（Ｎ１）にする。ステップＳ３９０６においてＮ１に対応するデータは、現状のユーザの権限で、印刷可能か否かをステップＳ３９０４で読み込んだ印刷項目ファイルより判定する。もしユーザが有する権限でＮ１が印刷可能であれば、ステップＳ３９０７において、すでに検索済みのＮ１に対応するデータを読み込み、ステップＳ３９０９において帳票テンプレートとマージ用のインデックスデータを作成する。

ステップＳ３９１０では、インデックスがすべて終了したか否かを判定する。終了していない場合は、Ｎの値をカウントアップし次の項目について判定する。ステップＳ３９０６において該当項目が印刷権限のない項目であった場合も、Ｎをカウントアップし次の項目についての判定を行う。したがって、印刷権限のない項目に関しては、インデックスデータは作成されず、ステップＳ３９１２において帳票として画像生成される時、インデックスデータの作成されていない項目については、なにも印刷されない（空白で印刷される）ことになる。
図４４においては印刷処理について説明したが、表示処理においても同様の処理によって対応することができる。

［第１４の実施形態］
次に、本発明の第１４の実施形態に係るネットワークプリントシステムについて説明する。
図４５は、本実施形態に係るネットワークプリントシステムの構成を示すソフトウェアブロック図である。第１の実施形態において図１に示した構成に対し、本実施形態の特徴である、クライアントから送られてきた印刷要求に対して制限をかける機能を追加した構成を有する。

図において、１０１はクライアント、１０５はネットワークであり、それぞれ図１におけるクライアント１０１、ネットワーク１０５と同一である。また、Ｗｅｂサーバ５１０３において、ネットワーク通信制御部１０７はＷｅｂサーバ１０６におけるネットワーク通信制御部１０７と同一である。

５１０５は後述するプリント情報解析部５１０６で解析された結果を元に、印刷を許可するか否かをクライアントに指示する機能を持つ、印刷制御部である。プリント情報解析部５１０６はクライアント１０１から送られてきた印刷データに制限がかかっているか否かを、後述するデータベース５１０７を参照し判断する機能を持つ。データベース５１０７は各帳票に設定されている制限情報を保持する。

図４６は、図４５のデータベース５１０７に保持されるデータを具体的に現したものである。登録済み帳票ファイルには、帳票５２０２が複数登録され、利用可能な帳票ごとに、印刷の制限情報を有している。期限情報５２０３はその帳票が利用期限であり、この期限を過ぎてからの印刷要求に対しては印刷を許可しない。回数情報５２０４はその帳票の印刷回数の上限を規定し、印刷回数がこの上限回数になると、それ以降の印刷要求に対しては印刷を行なわない。現在の印刷回数５２０５はその帳票がこれまでに印刷された回数を保持する。図４６においては、これら情報５２０３〜５２０５は帳票Ａに対応してのみ示されているが、実際には各帳票毎に対応して格納される。

次に、図４７に示すフローチャートを用いて、制限情報を用いた印刷か批判団処理について説明する。本処理は、クライアントからの印刷要求に対する処理の中で、実行される。例えば、第１の実施形態において説明したサーバ印刷処理（図５）において、サーバ印刷ボタンの押下検出（ステップＳ５０１）と帳票検索（ステップＳ５０２）の代わりに実行することができる。

まずステップＳ５３０１において、クライアントからＷｅｂサーバに対する印刷要求を受信する。次に、ステップＳ５３０２において、サーバ５１０３のプリント情報解析部５１０６が、クライアントから送られてきた印刷要求データを解析し、要求された印刷処理に用いる帳票の種類を検出する。そして、ステップＳ５３０７では、帳票の種類を元にデータベース５１０７を検索し、その帳票に対応する制限情報を参照する。印刷期限が設定されている場合には現在日時と期限情報５２０３とを比較し、期限を過ぎていたら印刷中止と判断する。

期限情報の設定がない場合もしくは期限内である場合には、印刷回数の制限が設定されている場合は現在の印刷回数５２０５と回数情報５２０４とをステップＳ５３０４において比較する。現在の印刷回数が回数情報に設定された回数と等しい場合には、印刷を実行すると上限回数を超えることになるので印刷中止と判断する。

回数制限の設定がない場合もしくは上限回数に満たない場合にはステップＳ５３０５で印刷実行の指示を印刷制御部５１０５に送り、データベース５１０７の使用した帳票に対応する印刷回数の値を１だけ加算する（ステップＳ５３０８）。ステップＳ５３０６ではステップＳ５３０３及びステップＳ５３０４のいずれかで印刷を許可しないと判断した場合、印刷中止の指示を印刷制御部５１０５に送る。

印刷中止と決定された場合、要求元のクライアントのＷｅｂブラウザ１１４の画面に、その旨を知らせるメッセージを表示するようにしても良い。また、印刷だけでなく、表示の時点で同じ様な制限をかけることもできる。この場合、表示自身を中止しても、第１３の実施形態で説明したように、印刷ボタンを除いた状態で表示するようにしても良い。

［第１５の実施形態］
次に、本発明の第１５の実施形態に係るネットワークプリントシステムについて説明する。
図４８は、本実施形態に係るネットワークプリントシステムの構成を示すブロック図である。本実施形態においては、Ｗｅｂサーバからプリントデータを複数存在するクライアントに選択的に配信することにより、クライアントにおける負荷を分散し、クライアントにおける出力処理を高速におこなうことを特徴とする。

図において、３４０１はネットワークを示しており、コンピュータ装置であるクライアントやプリンター等が接続されている。３４０２及び３４０３は第１の実施形態において説明したクライアント１０１（図１）と同一の構成を有するクライアントである。３４０４〜３４０７はそれぞれ異なる印字能力を持つプリンタを示し、プリンタ３４０４及び３４０５はそれぞれクライアント３４０２及び３４０３に接続されている。また、プリンタ３４０６及び３４０７はネットワーク３４０１に接続されている。

３４０８及び３４０９は第１の実施形態におけるネットワーク１０５と同様のネットワークであるが、利用するプリンタに応じて選択される経路が異なることを特徴とする。Ｗｅｂサーバ３４１０は第１の実施形態におけるＷｅｂサーバ１０６に、プリント情報を解析しプリントデータの送信先をしかるべきクライアントに振り分ける機能を付加したものである。ネットワーク通信制御部３４１１も同様に図１に示すネットワーク通信制御部１０７と同様である。

３４１２はネットワーク３４０１上に接続されているプリンタの印刷能力や負荷状態、および後述するＷｅｂサーバ３４１０のプリントデータ解析部３４１３からの情報を元に、印刷に最適なプリンタを自動的に選択し印刷要求を送信する印刷制御部である。

プリントデータ解析部３４１３はプリント情報を解析し、印刷要求のあった帳票の種類、印刷要求を出したユーザの情報等を元にどのプリンタを優先的に利用するべきかを印刷制御部３４１２に知らせると同時に、受け付けた印刷要求の情報を後述するデータベース３４１４に蓄積する。データベース３４１４は例えばリレーショナルデータベースであり、ネットワーク３４０１上に接続されているプリンタの種類や、過去に行なわれた印刷の情報を蓄積する。

図４９はデータベース３４１４に蓄積されるデータの例を示す図である。データベース３４１４は利用可能なプリンタの情報を蓄積したプリンタファイル部３５０１と、ユーザー毎に過去の印刷履歴を蓄積した印刷情報ファイル部３５０２とを有する。

プリンタファイル部３５０１には、クライアントが利用可能なプリンタ毎に、カラー印刷の可否、印字スピード、設置場所等の固有情報が格納される。また、印刷情報ファイル部３５０２には、各ユーザの印刷履歴情報として、これまでにどの帳票をどのプリンタで出力したか、その時の書式設定はどうなっていたかといった履歴を格納する。本実施形態においては、この履歴に基づいて次回の印刷要求時の設定が決定される。

次に、図５０に示すフローチャートを用いて、本実施形態に係るシステムにおける、印刷要求を受け付けてからプリントするプリンタを遠択するまでの処理を説明する。
まずステップＳ３６０１でいずれかのクライアントからＷｅｂサーバに対する印刷要求が発生し、Ｗｅｂサーバがこの要求を受け付ける。次いでＷｅｂサーバのプリントデータ解析部３４１３は、受け付けた印刷要求を解析し、印刷要求をしたユーザを特定する（ステップＳ３６０２）。そして、データベース３４１４の印刷情報ファイル部３５０２を参照し（ステップＳ３６０３）、このユーザーが行なった過去の印刷履歴を元に、選択するプリンタの候補を絞り込む（ステップＳ３６０４）。

プリンタの候補は、例えば過去所定回、例えば１０回の印刷要求において使用されたプリンタのうち、回数の多いものから所定数、例えば３台のプリンタを選択することによって決定することもできるし、単に前回使用したプリンタを選択するようにしても良い。

候補プリンタが選定されると、その候補をクライアントのＷｅｂブラウザ画面に表示させて、ユーザに選択を促す。この際、前回の印刷で利用したプリンタを優先的にデフォルトの選択状態とすることも可能である。ステップＳ３６０５でユーザのプリンタ選択結果を受信すると、ステップＳ３６０６では履歴に基づいて印刷の書式設定を自動的に決定する。

次いで、ステップＳ３６０７では印刷制御部３４１２が、使用が決定されたプリンタの状態を検出する。ステップＳ３６０８でピジー状態の時はデータベース３４１４のプリンタファイル部３５０１から、同等かそれ以上の機能を持つ他のプリンタを自動的に選択し、印刷ジョブを移管する（ステップＳ３６０９）。この場合、ユーザに印刷出力先が変更されたことを通知することが望ましい。

また、ビジー状態の場合、ユーザにその旨を通知するとともに、プリンタファイル部から他のプリンタを選択肢として与え、ユーザが選択したプリンタに印刷処理を移管するようにしても良い。
ステップＳ３６１０で最終的に選択されたプリンタに合わせて、Ｗｅｂサーバの画像生成部による印刷データ生成処理等の印刷処理が実施される。

上述の説明では、複数の候補を選定し、ユーザにその中から１台選択させるようにしたが、最も利用頻度の高いプリンタや、前回使用したプリンタを自動選択するように構成しても良い。
また、書式設定とビジー時の代替プリンタ選定処理を両方行なう場合について説明したが、いずれかのみを行なうようにしても良いことは言うまでもない。

［第１６の実施形態］
次に、本発明の第１６の実施形態に係るネットワークプリントシステムについて説明する。本実施形態に係るネットワークプリントシステムは、印刷しようとしている帳票データの内容にカラーデータを含むか否かで印刷に最適のプリンタを自動的に選択することを特徴とする。

また、印刷する文書のページ数が所定のページ数より多い場合、一つの文書を複数に分割し、複数のクライアントプリンタに印刷処理を分散させることを別の特徴とする。この際、文書をカラー・モノクロの種別によって分割し、それぞれに最適なプリンタを割り当てて印刷処理を分散させることも可能である。

本実施形態に係るネットワークプリントシステムは、第１５の実施形態において説明した図４８に示す構成により実現することができるため、構成の説明は省略する。
図５１は、本実施形態におけるデータベース３４１４’の内容を示す図である。第１５の実施形態において図４８に示したデータベース３４１４の構成に、分割印刷を行なうための情報である、環境情報ファイル部４４０３および印刷場所グループファイル部４４０４を追加した構成を有する。環境情報ファイル部４４０３は、印刷する文書のページ数が何枚を超えたら分割印刷を実行するか、複数のプリンタを使った分割印刷を行なう時に、どこに設置されているプリンタを利用するか等の情報を格納する。印刷場所グループファイル部４４０４は、分割印刷において利用するプリンタの範囲をグループ化した情報を格納する。

次に、図５２に示すフローチャートを用いて、本実施形態における印刷処理について説明する。図５２には、第１５の実施形態において図５０で説明した処理と同様、クライアントから印刷要求を受け付けてから、印刷を実行するプリンタを決定するまでの処理を示している。

まずステップＳ４５０１で、クライアントからの印刷要求をＷｅｂサーバが受け付ける。ステップＳ４５０２において、Ｗｅｂサーバのプリントデータ解析部３４１３（図４８）は、受け付けた印刷要求を解析し、要求を行なったユーザーの特定及び、印刷文書にカラーページが含まれるか否かを検出する。

カラーページが含まれる場合には、ステップＳ４５０３からステップＳ４５０４へ移行し、データベース３４１４のプリンタファイル部３５０１を参照して、利用できるプリンタの中からカラープリンタを抽出する。
一方、モノクロページのみの場合はステップＳ４５０３からステップＳ４５０５へ移行し、データベース３４１４’のプリンタファイル部３５０１を参照して、利用できるプリンタの中からモノクロプリンタを抽出する。

次いで、ステップＳ４５０６において、ユーザーの印刷履歴をデータベース３４１４’の印刷情報ファイル部３５０２を参照して、印刷書式を自動設定する。この処理は第１５の実施形態におけるステップＳ３６０６の処理と同一である。書式設定がすむと、ステップＳ４５０７で、印刷しようとする文書を分割印刷すべきどうかを判定する。すなわち、データベース３４１４’の環境情報ファイル部４４０３を参照し、印刷文書が分割すべき条件を満たすかどうかを判断する。

たとえば、印刷文書が分割条件であるページ数を超えるページ数を有している場合には、ステップＳ４５０７で分割印刷すべきと判断され、ステップＳ４５０８においてどのプリンタ群を用いて分割印刷を行なうかを設定する。この設定は、データベース３４１４’の印刷場所グループファイル部４４０４から適切なプリンタ群を選択することによって行なわれる。この選択に当たっては、プリントデータ解析部３４１３による解析結果（帳票の種類や、どのプリンタを優先的に使用すべきか等の情報）を考慮するとともに、ステップＳ４５０４及びＳ４５０５で抽出したプリンタを含むグループであり、カラーページを含む場合には、カラープリンタのみで構成されるグループを選択することが好ましい。さらに、印刷要求を行なったユーザから出力が行なわれるプリンタの距離が離れすぎないグループを選択することも好ましい。

分割印刷を行なう場合には、生成したプリントファイルを分割印刷を行なうプリンタの台数や能力に応じて分割して送信する（ステップＳ４５１０）。分割印刷はプリンタ群に含まれる全てのプリンタを用いる必要はなく、ユーザーからの距離などに応じて任意の条件で選択することができる。
一方、分割印刷を行なわない場合には、例えば第１５の実施形態におけるステップＳ３６０７〜Ｓ３６０９（図５０）に相当する処理をステップＳ４５０９で行い、最適なプリンタを決定した後、そのプリンタに適切なプリントファイルの生成処理等の印刷処理が実行される（ステップＳ４５１０）。

もちろん、本実施形態においても、第１５の実施形態で行なったように、ステップＳ４５０４及びステップＳ４５０５抽出したプリンタの候補をユーザに提示し、ユーザが選択したプリンタを使用するようにしても良い。
また、分割印刷する場合やユーザが選択したプリンタがビジーで他のプリンタで印刷を実行する場合には、その旨を実行するプリンタ名等とともに通知することが好ましい。

（第１６の実施形態の変形例１）
図５２の処理においては、モノクロページとカラーページをそれぞれでまとめずに分割印刷していたのに対し、本変形例においては、カラーページとモノクロページをそれぞれでまとめて分割印刷することを特徴とする。
図５３に示すフローチャートを用いて、本変形例における印刷処理について説明する。図５３には、図５２で説明した処理と同様、クライアントから印刷要求を受け付けてから、印刷を実行するプリンタを決定するまでの処理を示している。

まずステップＳ４６０１で、クライアントからの印刷要求をＷｅｂサーバが受け付ける。次いで、ステップＳ４６０２で、印刷しようとする文書を分割印刷すべきどうかを判定する。すなわち、データベース３４１４’の環境情報ファイル部４４０３を参照し、印刷文書が分割すべき条件を満たすかどうかを判断する。たとえば、印刷文書が分割条件であるページ数を超えるページ数を有している場合には、分割印刷すべきと判断される。

一方、分割印刷を行なわない場合には、例えば第１５の実施形態におけるステップＳ３６０７〜Ｓ３６０９（図５０）に相当する処理をステップＳ４６０９で行い、最適なプリンタを決定した後、そのプリンタに適切なプリントファイルの生成処理等の印刷処理が実行される（ステップＳ４５１０）。

ステップＳ４５０２において、Ｗｅｂサーバのプリントデータ解析部３４１３（図４８）は、受け付けた印刷要求を解析し、要求を行なったユーザーの特定及び、印刷文書にカラーページが含まれるか否かを検出する。そして、カラーページが含まれる場合には、そのページをカラーページ群に、それ以外のページ（モノクロページ）はモノクロページ群にそれぞれ分割して、例えばＷｅｂサーバ３４１０（図４８）のデータ格納部に格納する（ステップＳ４６０４〜Ｓ４６０６）。

次いで、ステップＳ４５０６において、ユーザーの印刷履歴をデータベース３４１４’の印刷情報ファイル部３５０２を参照して、印刷書式を自動設定する。この処理は第１５の実施形態におけるステップＳ３６０６の処理と同一である。ステップＳ４６０８においては、ステップＳ４６０２におけるプリントデータ解析部３４１３による解析結果（帳票の種類や、どのプリンタを優先的に使用すべきか等の情報）を考慮するとともに、印刷文書がカラーページを含む場合にはカラープリンタを含むプリンタ群を選定する。

そして、ステップＳ４６０９において、ステップＳ４６０５により分割されたカラーページ群に対してはプリンタ群に含まれるカラープリンタを、ステップＳ４６０６により分割されたモノクロページにはモノクロ専用プリンタをそれぞれ選択する。ステップＳ４６１０においては、選択したプリンタに適切なプリントファイルの生成処理等の印刷処理が実行される。

［第１７の実施形態］
図５４は、本発明を実施するネットワークプリントシステムのソフトウエアブロック図である。図５４において、図１に示したネットワークプリントシステムと同じ構成には同じ参照数字を付し、その説明は省略する。

図１と図５４との比較から明らかなように、図５４の構成はＷｅｂサーバ６００が複数のネットワークインターフェース６１０〜６１２を有している以外は共通の構成を有している。また、図５４においてＷｅｂサーバのネットワークインターフェースは３つであるが、複数であれば数の制限はない。

複数の経路が存在するとき、実際にデータが通るネットワーク経路は、ネットワークを構成するルータなどのネットワーク機器の設定に依存する。つまりクライアントからＷｅｂサーバへのネットワーク経路は、ネットワーク機器の設定次第で、複数のネットワークインターフェース６１０〜６１２のいずれに到着するかが決定する。

一方、Ｗｅｂサーバからクライアントへのデータは、ネットワークインタフェース６１０〜６１２のいずれからデータを送出するかはＷｅｂサーバによって選択できるが、その後のクライアントまでのネットワーク経路はネットワーク機器の設定に依存する。

本実施形態におけるネットワークプリントシステムでは、クライアントからのデータは、Ｗｅｂサーバのある特定のネットワークインターフェースに到着するように、予めネットワークを構成するルータ等の設定をしておく。また、Ｗｅｂサーバの各々のネットワークインターフェースから出力されたデータの通る経路についても、クライアントから到着するデータの経路や、他のインターフェースからの経路と、ネットワーク負荷と言う観点から見て、干渉しないようにネットワークを構成する機器の設定しておく。

次に、図２に示したブラウザウィンドウにおいて、印刷ボタン２１０が押された後の動作を説明する。印刷ボタン２１０が押されると、印刷要求データは、予め設定したネットワーク経路を通って、Ｗｅｂサーバ６００の特定のネットワークインターフェースに到着する。Ｗｅｂサーバ内では、データ処理部１１０で要求データが解析・処理されたうえ、画像生成部１１１で画像が生成されることにより、クライアントへの応答データが整うことになる。

そして、ネットワーク通信制御部１０７は、クライアントへの応答データを送り出すネットワークインターフェースとして、クライアントからの要求データが到着した以外のものを選択して、データを送り返す。そうすることによって、この要求の送信元であるクライアントからの要求が伝達される経路とは別の経路でプリントデータが返送されることになり、同じクライアントから別の要求が連続して発生しても、その伝達をＷｅｂサーバからの応答データが阻害することはない。

（第１７の実施形態の変形例１）
図５５は、第１７の実施形態に係るネットワークプリントシステムの変形例を示すソフトウエアブロック図である。図５５は、図５４に示したネットワークプリントシステムの構成において、Ｗｅｂサーバに６２１のネットワーク負荷監視部が追加された構成を有する。ネットワーク負荷監視部６２１は、Ｗｅｂサーバに備わる複数のネットワークインターフェース６１０〜６１２の負荷を常時監視し、その状態を１０７のネットワーク通信制御部に通知する機能を有する。

本変形例において、クライアントからの要求データを受けてから、クライアントへの応答データを作成する処理の流れは、図５４を用いて上で説明した通りである。
本変形例では、Ｗｅｂサーバ６２０からクライアント１０１への応答データの送出にあたり、ネットワーク通信制御部１０７は、ネットワーク負荷監視部６２１に各インターフェース６１０〜６１２の負荷を問い合わせ、最も負荷の軽いインターフェースを利用してデータ送信を行う。

[他の実施形態]
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施形態におけるサーバの機能を実現するための、図５あるいは図６のプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。また、Ｗｅｂサーバの機能を実現するための図１０あるいは図１４及び図１５の手順のプログラムをコンピュータに供給しても達成できる。
また、画像生成サーバの機能を実現するための、図１２の手順のプログラムコードをコンピュータに供給しても達成できる。

また、本発明の目的は、前述した実施形態におけるサーバの機能を実現するための、図２４、図２５、図２８、図２９のプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。

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

プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。

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

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

ネットワークプリントシステムのブロック図である。クライアントのＷｅｂブラウザの表示画面例を示す図である。印刷される帳票のテンプレートとなる図形データの一例を示す図である。印刷される帳票と合成されるデータの一例を示す図である。第１実施形態におけるサーバによる帳票印刷の手順を示すフローチャートである。第１実施形態におけるクライアントによる帳票印刷の手順を示すフローチャートである。クライアントによるサーバからの受信データを印刷手順を示す図である。クライアント及びサーバの構成を示すブロック図である。第２及びその変形例における、複数の画像生成サーバを有するネットワークプリントシステムのブロック図である。分散した画像生成サーバへの処理依頼手順を示す、Ｗｅｂサーバによる処理のフローチャートである。第２実施形態における分散設定テーブルの一例を示す図である。処理依頼を受信した画像生成サーバによる処理手順のフローチャートである。第２実施形態の変形例における分散設定テーブルの一例を示す図である。第２の実施形態の変形例における、Ｗｅｂサーバにより実行される画像生成サーバの選択手順のフローチャートである。画像生成部を分散設定テーブルに登録する手順のフローチャートである。第３の実施形態におけるネットワークプリントシステムのブロック図である。第３の実施形態における分散設定テーブルの図である。第３の実施形態において、画像生成サーバのステータスをＮＧに変更する手順のフローチャートである。第３の実施形態において、利用できるようになった画像生成サーバのステータスをＯＫに変更する手順のフローチャートである。第４の実施形態におけるネットワークプリントシステムのブロック図である。第４の実施形態のクライアントにおいて、受信したデータに適合するプリンタを選択する手順のフローチャートである。第５の実施形態におけるネットワークプリントシステムのブロック図である。第６の実施形態に係るネットワークプリントシステムのブロック図である。従来例におけるサーバ及びクライアントによる画像生成の手順を示すフローチャートである。従来例において、画像データをクライアントからサーバに送信するためのデータブロックの図である。従来例において、画像データをクライアントからサーバに送信するためのデータブロックの図である。第６の実施形態におけるサーバ及びクライアントによる画像生成の手順を示すフローチャートである。第７の実施形態におけるサーバ及びクライアントによる画像生成の手順を示すフローチャートである。第８の実施形態におけるサーバ及びクライアントによる画像生成の手順を示すフローチャートである。第９の実施形態におけるシステム構成のブロック図である。第９の実施形態におけるシステム構成のブロック図である。本発明の第１０の実施形態におけるクライアントのブロック図である。本発明の第１０の実施形態の復号化方法を表すフローチャートである。本発明の第１０の実施形態の暗号化されたデータの構造を表すブロック図である。本発明の第１１の実施形態の復号化方法を表すフローチャートである。本発明の第１１の実施形態の復号キーブロックの構造を表すブロック図である。本発明の第１２の実施形態の構成を表すサーバのブロック図である。本発明の第１２の実施形態のセッション保持方法を表すフローチャートである。本発明の第１２の実施形態の復号化方法を表すフローチャートである。本発明の第１２の実施形態の復号キーの保持構造を表すメモリブロック図である。本発明の第１３の実施形態に係るネットワークプリントシステムにおける、ユーザ権限に基づく表示処理を示すフローチャートである。図４１の処理における、ユーザＩＤと印刷権限との対応を示すテーブルの例を示す図である。ユーザ権限とプリント表示項目の関係を示す可変データテーブルの構成例を示す図である。ユーザ権限に基づいて、帳票項目毎に処理の可否を設定する場合の処理を説明するフローチャートである。本発明の第１４の実施形態に係るネットワークプリントシステムのブロック図である。印刷制限情報を保持するデータベースの構造を示す図である。制限情報に基づく印刷可否判断処理の手順を示すフローチャートである。本発明の第１５の実施形態に係るネットワークプリントシステムのブロック図である。プリンタ情報等を保持するデータベース構造を示す図である。複数のプリンタを選択的に用いる印刷処理を説明するフローチャートである。本発明の第１６の実施形態に係るネットワークプリントシステムにおける、データベースの格納情報ついて説明する図である。分割印刷処理の手順を示すフローチャートである。分割印刷処理の別の手順を示すフローチャートである。本発明の第１７の実施形態に係るネットワークプリントシステムのソフトウエアブロック図である。本発明の第１７の実施形態の変形例に係るネットワークプリントシステムのソフトウエアブロック図である。

Claims

クライアント装置と、該クライアント装置から指定される名称に従ってファイルを前記クライアント装置に送信できるサーバ装置とをネットワークを介して接続したネットワークシステムであって、
クライアント装置は、
サーバ装置に対して画像ファイルの生成及び、生成された画像ファイルもしくは当該画像ファイルへの参照パスの送信を要求するリクエストを送信するリクエスト送信手段を有し、
サーバ装置は、
前記ネットワークを介して前記クライアント装置により送信された前記リクエストを受信する受信手段と、
前記受信手段により受信されたリクエストに応じて画像ファイルを生成する生成手段と、
前記生成手段により生成された画像ファイルを格納領域に格納する格納手段と、
前記受信手段により受信されたリクエストを解析し、前記クライアント装置が画像ファイルの送信と画像ファイルへの参照パスの送信のどちらを要求しているかを判断する判断手段と、
前記クライアント装置が画像ファイルの送信を要求していると前記判断手段により判断された場合には、前記生成された画像ファイルを前記格納領域のうち不特定のクライアント装置からアクセス不可能な領域に格納するように前記格納手段を制御し、また前記クライアント装置が画像ファイルへの参照パスを要求していると前記判断手段により判断された場合には、前記生成された画像ファイルを前記格納領域のうち不特定のクライアント装置からアクセス可能な領域に格納するよう前記格納手段を制御する格納制御手段と、
前記クライアント装置が画像ファイルの送信を要求していると前記判断手段により判断された場合には、前記格納領域のうち前記不特定のクライアント装置からアクセス不可能な領域に格納された画像ファイルを前記クライアント装置に対して送信し、前記クライアント装置が画像ファイルへの参照パスを要求していると前記判断手段により判断された場合には、前記格納領域のうち前記不特定のクライアント装置からアクセス可能な領域に格納された画像ファイルへの参照パスを前記クライアント装置に対して送信する送信手段と、を有することを特徴とするネットワークシステム。
前記送信手段はさらに、前記クライアント装置から前記画像ファイルへの参照パスを用いてファイル転送が要求されたことに応じて、前記格納領域のうち前記不特定のクライアント装置からアクセス可能な領域に格納された画像ファイルのうち、前記画像ファイルへの参照パスに対応した画像ファイルを前記クライアント装置に送信することを特徴とする請求項１に記載のネットワークシステム。
クライアント装置と、該クライアント装置から指定される名称に従ってファイルを前記クライアント装置に送信できるサーバ装置とをネットワークを介して接続したネットワークシステムの制御方法であって、
クライアント装置が、
サーバ装置に対して画像ファイルの生成及び、生成された画像ファイルもしくは当該画像ファイルへの参照パスの送信を要求するリクエストを送信するリクエスト送信工程と、
サーバ装置が、
前記ネットワークを介して前記クライアント装置により送信された前記リクエストを受信する受信工程と、
前記受信工程において受信されたリクエストに応じて画像ファイルを生成する生成工程と、
前記受信工程において受信されたリクエストを解析し、前記クライアント装置が画像ファイルの送信と画像ファイルへの参照パスの送信のどちらを要求しているかを判断する判断工程とを有し、
前記クライアント装置が画像ファイルの送信を要求していると前記判断工程において判断された場合には、前記生成された画像ファイルを格納領域のうち不特定のクライアント装置からアクセス不可能な領域に格納し、また前記クライアント装置が画像ファイルへの参照パスを要求していると前記判断工程において判断された場合には、前記生成された画像ファイルを前記格納領域のうち不特定のクライアント装置からアクセス可能な領域に格納する格納工程と、
前記クライアント装置が画像ファイルの送信を要求していると前記判断工程において判断された場合には、前記格納領域のうち前記不特定のクライアント装置からアクセス不可能な領域に格納された画像ファイルを前記クライアント装置に対して送信し、前記クライアント装置が画像ファイルへの参照パスを要求していると前記判断手段により判断された場合には、前記格納領域のうち前記不特定のクライアント装置からアクセス可能な領域に格納された画像ファイルへの参照パスを前記クライアント装置に対して送信する送信工程と、を有することを特徴とするネットワークシステムの制御方法。
前記サーバ装置が、前記クライアント装置から前記画像ファイルへの参照パスを用いてファイル転送が要求されたことに応じて、前記格納領域のうち前記不特定のクライアント装置からアクセス可能な領域に格納された画像ファイルのうち、前記画像ファイルへの参照パスに対応した画像ファイルを前記クライアント装置に送信する工程をさらに有することを特徴とする請求項３に記載のネットワークシステムの制御方法。