(57)【要約】【課題】大量のページを含むフィールドデータを印刷する場合、配信ファイルのダウンロード及び事前のフィールドデータ解析処理に時間を取られるため、最初のページの印刷までに遅延が発生するという問題点があった。【解決手段】サーバでは、フィールドデータを所定データ量単位に複数のブロックに分割し、その分割した各ブロックのフィールドデータごとに配信ファイルを作成し、先頭の配信ファイルに後続のフィールドデータを含む配信ファイルがあるか否かを示す情報を付加した配信ファイルを作成してクライアントに送信する。クライアントでは、その配信ファイルを受信と、先頭の配信ファイルに後続の配信ファイルがあることが示されている場合、各配信ファイルごとに前記サーバに後続の配信ファイルを要求し、各配信ファイルごとにオーバレイ印刷用のデータを生成する。【選択図】    図６
2005050044.tif 000002
【特許請求の範囲】
【請求項１】
サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷する印刷システムであって、
前記サーバは、
フィールドデータを所定データ量単位に複数のブロックに分割する分割手段と、
前記分割手段により分割された各ブロックのフィールドデータごとに配信情報を作成し、先頭の配信情報に後続のフィールドデータを含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成手段と、
前記配信情報作成手段により作成された配信情報を前記クライアントに送信する送信手段とを有し、
前記クライアントは、
前記サーバから送信される前記配信情報を受信する受信手段と、
前記受信手段により受信した前記先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求手段と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成手段と、を有することを特徴とする印刷システム。
【請求項２】
前記サーバは、前記配信情報要求手段による要求ごとに各配信情報を送信することを特徴とする請求項１に記載の印刷システム。
【請求項３】
前記所定データ量は、前記サーバとクライアントとの間のデータ通信容量に基づいて決定されることを特徴とする請求項１又は２に記載の印刷システム。
【請求項４】
前記所定データ量は、前記クライアントにおけるデータ処理能力に基づいて決定されることを特徴とする請求項１又は２に記載の印刷システム。
【請求項５】
前記サーバは、前記クライアントと接続された後、前記クライアントに対してデータ要求項目を入力するためのＵＩ画面データを送信することを特徴とする請求項１乃至４のいずれか１項に記載の印刷システム。
【請求項６】
サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷する印刷システムであって、
前記サーバは、
前記クライアントからの要求項目を複数の要求項目単位に分割する分割手段と、
前記分割手段により分割された各要求項目ごとに配信情報を作成し、先頭の配信情報に後続の要求項目を含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成手段と、
前記配信情報作成手段により作成された配信情報を前記クライアントに送信する送信手段とを有し、
前記クライアントは、
前記サーバから送信される前記配信情報を受信する受信手段と、
前記受信手段により受信した前記先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求手段と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成手段と、を有することを特徴とする印刷システム。
【請求項７】
前記サーバは、前記配信情報要求手段による要求ごとに各配信情報を送信することを特徴とする請求項６に記載の印刷システム。
【請求項８】
前記後続の要求項目を含む配信情報があるか否かを示す情報はＵＲＬで記述されていることを特徴とする請求項６又は７に記載の印刷システム。
【請求項９】
クライアントにフォームとフィールドデータとを送信して前記クライアントでオーバレイ印刷させるサーバであって、
フィールドデータを所定データ量単位に複数のブロックに分割する分割手段と、
前記分割手段により分割された各ブロックのフィールドデータごとに配信情報を作成し、先頭の配信情報に後続のフィールドデータを含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成手段と、
前記配信情報作成手段により作成された配信情報を前記クライアントに送信する送信手段と、
前記クライアントからの要求に応じて、前記後続のフィールドデータを含む各配信情報を順次送信する手段と、を有することを特徴とするサーバ。
【請求項１０】
サーバから送信されるフォームとフィールドデータとに基づいてオーバレイ印刷する印刷制御装置であって、
前記サーバから送信される配信情報を受信する受信手段と、
前記受信手段により受信した先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求手段と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成手段と、を有することを特徴とする印刷制御装置。
【請求項１１】
サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷する印刷制御方法であって、
フィールドデータを所定データ量単位に複数のブロックに分割する分割工程と、
前記分割工程で分割された各ブロックのフィールドデータ毎に配信情報を作成し、先頭の配信情報に後続のフィールドデータを含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成工程と、
前記配信情報作成工程で作成された配信情報を前記サーバから前記クライアントに送信する送信工程と、
前記サーバから送信される前記配信情報を受信する受信工程と、
前記受信工程で受信した前記先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求工程と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成工程と、を有することを特徴とする印刷制御方法。
【請求項１２】
前記サーバは、前記配信情報要求手段による要求ごとに各配信情報を送信することを特徴とする請求項１１に記載の印刷制御方法。
【請求項１３】
前記所定データ量は、前記サーバとクライアントとの間のデータ通信容量に基づいて決定されることを特徴とする請求項１１又は１２に記載の印刷制御方法。
【請求項１４】
前記所定データ量は、前記クライアントにおけるデータ処理能力に基づいて決定されることを特徴とする請求項１１又は１２に記載の印刷制御方法。
【請求項１５】
前記サーバは、前記クライアントと接続された後、前記クライアントに対してデータ要求項目を入力するためのＵＩ画面データを送信することを特徴とする請求項１１乃至１４のいずれか１項に記載の印刷制御方法。
【請求項１６】
サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷する印刷制御方法であって、
前記クライアントからの要求項目を複数の要求項目単位に分割する分割工程と、
前記分割工程で分割された各要求項目ごとに配信情報を作成し、先頭の配信情報に後続の要求項目を含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成工程と、
前記配信情報作成工程で作成された配信情報を前記サーバから前記クライアントに送信する送信工程と、
前記サーバから送信される前記配信情報を受信する受信工程と、
前記受信工程で受信した前記先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求工程と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成工程と、を有することを特徴とする印刷制御方法。
【請求項１７】
前記サーバは、前記配信情報要求工程による要求ごとに各配信情報を送信することを特徴とする請求項１６に記載の印刷制御方法。
【請求項１８】
前記後続の要求項目を含む配信情報があるか否かを示す情報はＵＲＬで記述されていることを特徴とする請求項１６又は１７に記載の印刷制御方法。
【請求項１９】
請求項１１乃至１８のいずれか１項に記載の印刷制御方法を実行することを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷するサーバ及び印刷制御装置、印刷システム及び印刷制御方法に関するものである。
【０００２】
【従来の技術】
フォーム及びフィールドデータをサーバで管理し、そのサーバからクライアントに対してフォームを配信することによって、クライアントではそれらを使ったオーバレイ印刷を行うことができるシステムが提案されている。このとき、サーバからクライアントに送信されるデータは、フォーム及びフィールドデータを適宜圧縮或いは暗号化し、それらを結合し一つに纏めたものである。この一つに纏められてクライアントに配信されるデータのことを、以後単に「配信ファイル」と称することにする。このようなサーバ・クライアント間での配信によるオーバレイ印刷の一例が、例えば特許文献１に記載されている。
【０００３】
【特許文献１】
特開２００２−１６３５９６号公報
【０００４】
【発明が解決しようとする課題】
一般に、事務書類などの印刷に利用される帳票印刷システムでは、印刷物が大量のページをもつことがある。特に、利用範囲が拡大しているＷｅｂを利用した帳票配信技術においては、前述の配信ファイルを利用してフォーム及びフィールドデータをクライアントに送信するため、その配信ファイル自体が巨大になる傾向がある。
【０００５】
ここで、フォーム及びフィールドデータがそれぞれ別個に生成され、単純にそれらを別個に圧縮及び必要に応じて暗号化し、単に結合させた図５のような構造のファイルを配信ファイルとするシステムでは、クライアントは配信ファイルを受信した後、その配信ファイルを分解し復号することによって、元々の結合される前の形にフォームやフィールドデータを戻してオーバレイ処理を行う必要がある。
【０００６】
ところで、このようなシステムでは、クライアントで扱うフィールドデータは、データの値だけ、或いはデータの値とそれに挿入さるべきフォーム上の関連図形名を記されただけの、単純なフォーマットとなっている。後者については、例えばフォーム上に「Ｆｉｅｌｄ＿Ａ」という名前の図形があるとすると、フィールドデータ中に「＜Ｆｉｅｌｄ＿Ａ＞＝１０００」と記載することにより、その図形の文字列内容が「１０００」という値に置き換わる、という動作を想定している。フィールドデータ中には、このような、名前と値のペアが羅列された単純な記述があるのみである。そのためクライアントでは、フィールドデータを、結び付けられるフォームに合わせて、オーバレイ処理に適した内部的なデータ形態に解析し直す必要がある。これによって、クライアントは自身の内部で、フォーム中でのフィールドデータの位置やフォント、文字の配置などを決めることができ、それによってフォームとフィールドデータのオーバレイを実行し、印刷装置に印刷出力を行うことが可能になる。この解析処理のことを「フィールドデータ解析」と称する。
【０００７】
ところが、フィールドデータの量が多くなればなるほど、ダウンロードに要する時間が長くなるだけでなく、クライアントでのフィールドデータ解析処理により多くの時間を要するようになる。そのため事務書類のように、数万ページといった大部の印刷処理においては、フィールドデータ解析の時間だけで、かなりの時間を要することになる。
【０００８】
従って、大量のページを含むフィールドデータを印刷する場合、配信ファイルのダウンロード及び事前のフィールドデータ解析処理に時間を取られるため、最初のページの印刷までに遅延が発生するという問題点があった。
【０００９】
本発明は上記問題点に鑑みてなされたもので、大量のデータを含むフィールドデータを印刷する場合でも、遅延を少なくしてオーバレイ印刷を行うことができるサーバ及び印刷制御装置、印刷システム及び印刷制御方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記目的を達成するために本発明の印刷システムは以下のような構成を備える。即ち、
サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷する印刷システムであって、
前記サーバは、
フィールドデータを所定データ量単位に複数のブロックに分割する分割手段と、
前記分割手段により分割された各ブロックのフィールドデータごとに配信情報を作成し、先頭の配信情報に後続のフィールドデータを含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成手段と、
前記配信情報作成手段により作成された配信情報を前記クライアントに送信する送信手段とを有し、
前記クライアントは、
前記サーバから送信される前記配信情報を受信する受信手段と、
前記受信手段により受信した前記先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求手段と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成手段とを有することを特徴とする。
【００１１】
上記目的を達成するために本発明の印刷制御方法は以下のような工程を備える。即ち、
サーバからクライアントに送信されるフォームとフィールドデータとに基づいて、前記クライアントでオーバレイ印刷する印刷制御方法であって、
フィールドデータを所定データ量単位に複数のブロックに分割する分割工程と、
前記分割工程で分割された各ブロックのフィールドデータ毎に配信情報を作成し、先頭の配信情報に後続のフィールドデータを含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成工程と、
前記配信情報作成工程で作成された配信情報を前記サーバから前記クライアントに送信する送信工程と、
前記サーバから送信される前記配信情報を受信する受信工程と、
前記受信工程で受信した前記先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求工程と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成工程とを有することを特徴とする。
【００１２】
上記目的を達成するために本発明の印刷制御装置は以下のような構成を備える。即ち、
サーバから送信されるフォームとフィールドデータとに基づいてオーバレイ印刷する印刷制御装置であって、
前記サーバから送信される配信情報を受信する受信手段と、
前記受信手段により受信した先頭の配信情報に後続の配信情報があることが示されている場合、各配信情報ごとに前記サーバに後続の配信情報を要求する配信情報要求手段と、
前記各配信情報ごとにオーバレイ印刷用のデータを生成するオーバレイ印刷データ生成手段とを有することを特徴とする。
【００１３】
上記目的を達成するために本発明のサーバは以下のような構成を備える。即ち、クライアントにフォームとフィールドデータとを送信して前記クライアントでオーバレイ印刷させるサーバであって、
フィールドデータを所定データ量単位に複数のブロックに分割する分割手段と、
前記分割手段により分割された各ブロックのフィールドデータごとに配信情報を作成し、先頭の配信情報に後続のフィールドデータを含む配信情報があるか否かを示す情報を付加した配信情報を作成する配信情報作成手段と、
前記配信情報作成手段により作成された配信情報を前記クライアントに送信する送信手段と、
前記クライアントからの要求に応じて、前記後続のフィールドデータを含む各配信情報を順次送信する手段とを有することを特徴とする。
【００１４】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。
【００１５】
本実施の形態は、罫線や文字等を含む電子的な定型文書であるフォーム、及びそれに付随して定型部位を埋めるデータ、及びそれを印刷した結果である帳票の配信と印刷を行うシステムに係るものである。特にＬＡＮやＷＡＮ及びインターネットなどのネットワークを介して接続されたサーバ及びクライアントを含むコンピュータシステムにおいて、クライアントからの要求によってサーバからクライアントへ電子データを配信し、それをクライアント側のアプリケーションによって印刷装置を使用して印刷する帳票印刷システムを対象とし、その際のファーストページ（一枚目）の印刷出力を高速化する帳票印刷制御装置の場合で説明する。尚、本実施の形態では、罫線などのような常に定型の要素（フォーム）と、その定型部分に埋め込む各書類毎に異なるデータ部（フィールドデータ）とに分かれたファイル群を、目的とする印刷処理に供するものとする。これらそれぞれの電子的なデータ要素を、これ以後単に「フォーム」、「フィールドデータ」と称する。またこれらを重ね合わせて一つの文書として完成することを「オーバレイ」、特に文書として用紙に印刷することを「オーバレイ印刷」と称する。また、オーバレイ印刷を行った結果として得られる用紙としての定型文書を「帳票」と称することとする。
【００１６】
図１は、本発明の一実施の形態に係る帳票印刷システムのクライアント及びサーバのハードウェア構成を示すブロック図で、これらサーバ及びクライアントはハードウェアとしては同じ構成を有し、通信機能を備えるパーソナルコンピュータなどの情報処理端末と同等のものである。
【００１７】
本実施の形態に係るサーバ及びクライアントは、ＣＰＵ１２を含む中央処理装置と、ＲＡＭ及びＲＯＭなどを含むメモリ１３、ＦＤドライブやＨＤドライブなどを含む外部メモリ１５、キーボード及びマウスなどのポインティングデバイス等を備える入力装置１１、ＣＲＴディスプレイなどを備える表示装置１４、及び外部ネットワーク１７に接続する入出力インターフェース１６を備えている。このようなクライアント及びサーバがネットワーク１７に接続されて、帳票印刷システムが構築されている。
【００１８】
図２は、本発明の実施の形態１に係る帳票印刷システムのネットワーク構成を表すブロック図である。
【００１９】
Ｗｅｂサーバ２１ではＷｅｂアプリケーションサーバ２２が稼動しており、それに対してインターネットやＬＡＮ／ＷＡＮといったネットワーク１７を介してクライアント２３のＷｅｂブラウザ２４が接続されている。また、このネットワーク１７には、サーバ２１及びクライアント２３からアクセス可能な印刷機器（プリンタ）２５が接続されている。尚、この印刷機器２５は、クライアント２３又はＷｅｂサーバ２１に直接接続されているものであっても構わない。
【００２０】
本実施の形態に係る帳票印刷システムのサーバ２１及びクライアント２３は、基本Ｉ／Ｏプログラム、ＯＳ及びアプリケーションプログラムをＣＰＵ１２が実行することにより動作する。この基本Ｉ／Ｏプログラムは、メモリ１３に書き込まれており、ＯＳは外部メモリ１５に書き込まれている。そして、Ｗｅｂサーバ２１又はクライアント２３の電源がオンされた時に、基本Ｉ／Ｏプログラム中のＩＰＬ（イニシャル・プログラム・ローディング）機能により、外部メモリ１５からＯＳが読み出されてメモリ１３のＲＡＭに書き込まれ、ＣＰＵ１２の制御の下にＯＳによる動作が開始される。
【００２１】
図３は、本実施の形態に係る外部メモリ１５のメモリマップを説明する図である。
【００２２】
この外部メモリ１５に記憶された制御プログラム及び関連データは、ＯＳ及び基本Ｉ／Ｏプログラムの制御の下で、外部メモリ１５から読み出されてメモリ１３のＲＡＭにロードされて動作可能となる。
【００２３】
図４は、これら制御プログラムや関連データがメモリ１３のＲＡＭにロードされて実行可能となった状態におけるＲＡＭのメモリマップを示す図である。
【００２４】
尚、本実施の形態では、外部メモリ１５から制御プログラム及び関連データを直接メモリ１３にロードして実行させる例を示したが、本発明はこれに限定されるものでなく、外部メモリ１５である、例えばＦＤからプログラム及び関連データを一旦、外部メモリ１５のハードディスクに格納（インストール）しておき、そのプログラムを動作させる際に、そのプログラムをハードディスクからメモリ１３にロードするようにしてもよい。また、この制御プログラムを記憶している記憶媒体は、ＦＤ以外にＣＤ−ＲＯＭ、ＩＣメモリカードなどであっても良い。
更に、この制御プログラムを読取専用のＲＯＭに記憶しておき、これをＣＰＵ１２からみたメモリマップの一部をなすように構成し、直接ＣＰＵ１２で実行することも可能である。
【００２５】
また本実施の形態では、Ｗｅｂサーバ２１は、一般的なＨＴＭＬ文書などの送受信を受け持つＷｅｂサーバとしての機能と、ビジネスロジックを担当するＷｅｂアプリケーションサーバとしての機能分担を想定している。本実施の形態では、クライアント２３のＷｅｂブラウザ２４からの要求に対して、Ｗｅｂサーバ２１は、指定されたフォーム、及びそれに埋め込まれるべきフィールドデータを準備する。通常、フィールドデータは、データベースなどを用いてＷｅｂアプリケーションサーバ２２の処理により準備される帳票の定型部以外の部位を埋めるテキストデータであるが、それに付随する画像ファイルなどのリソースファイル（例えば、後述する図５の５０５）を含む場合もある。またＷｅｂアプリケーションサーバ２２では、それら帳票処理に必要なフィールドデータ（もし必要であればリソースファイルも）を用意した後、それらを圧縮或いは暗号化し、更に、帳票をファイル処理又は印刷処理するための付加情報をヘッダ（例えば、後述する図５の５０１）として付加して一つのファイルに結合する。
【００２６】
ここでいうファイル処理とは、Ｗｅｂサーバ２１において、それぞれ結合されているファイルの圧縮方法や暗号化方法を記述しておき、それらを利用してクライアント２３で元のファイルに復元する処理である。また印刷処理するための付加情報とは、クライアント２３で印刷する際に利用する印刷機器名や、印刷部数や給紙口などといった、印刷機器２５による印刷機能を指定するものである。
【００２７】
これらの情報が結合された配信ファイルでは、特徴的なデータ列（例えば、「−−−−−−−−−−−−−−−−−−−−−−−−−−−−」というような文字列など）で区切られたり、或いはファイルヘッダに、各情報の開始及び終了オフセットバイト数などが記述されている。従って、そのヘッダを参照することにより、クライアント２３は、簡単な処理で、元の情報のそれぞれに分解して復号・伸張することが可能である。こうして各種の情報とファイルとが結合されてできた配信ファイルは、クライアント２３で処理できる特定のＭＩＭＥタイプのデータとして、Ｗｅｂサーバ２１からクライアント２３にネットワーク１７を介して配信される。
【００２８】
図５は、本実施の形態に係る配信ファイルの一例を示す図である。ここでは、「−−−−−−−−−−−−−−−−−−−−−−−−−−［区切り線］」という文字列を、各情報の区切り記号として用いたファイル形式で示している。
【００２９】
図において、５０１は配信ファイルのヘッダ、５０２は、圧縮された埋め込みデータファイル（フィールドデータ）を示し、これは帳票の定型部以外の部位を埋めるテキストデータ等で構成されている。５０３は帳票１のフォームデータ、５０４は帳票２のフォームデータである。これらフォームデータ５０３，５０４はいずれも圧縮されている。５０５は、グラフを示すリソースファイル（ＪＰＥＧファイル）である。
【００３０】
以上説明した前提条件に基づいて、本実施の形態に係る処理を図６のフローチャートを参照して説明する。
【００３１】
図６は、本実施の形態１に係る帳票印刷システムにおける処理の流れを説明するための流れ図である。尚、これら処理を実行するプログラムは、サーバ２１及びクライアント２３の外部メモリ１５に記憶されており、実行時にメモリ１３にロードされて実行される。
【００３２】
本実施の形態におけるオーバレイ処理は、クライアント２３のＷｅｂブラウザ２４から、Ｗｅｂサーバ２１に対してオーバレイ用のリクエストを送信するところから始められる。
【００３３】
まずステップＳ１で、クライアント２３のＷｅｂブラウザ２４は、ネットワーク１７を介してＷｅｂサーバ２１と接続される。この接続は、ネットワークを介するクライアント・サーバとしての接続を意味している。これによりステップＳ２で、Ｗｅｂサーバ２１は、帳票フォームの具体的に要求するための入力画面をＷｅｂブラウザ２４に返す。これによりクライアント２３の表示装置１４には、その入力画面（ＵＩ画面）が表示される。
【００３４】
次にステップＳ３で、Ｗｅｂブラウザ２４を通じて、クライアント２３のユーザは、その入力画面を使用して、適宜、所望する情報を入力する。そしてステップＳ４で、その入力された帳票処理要求をサーバ２１に送信する。
【００３５】
この要求を受け取ったＷｅｂサーバ２１は、Ｗｅｂアプリケーションサーバ２２に処理を渡す。これによりＷｅｂアプリケーションサーバ２２は、ステップＳ５で、その要求に含まれる事項を解析し、それに適合したデータ検索を行う。このデータ検索において、フォーム、フィールドデータ、及び必要に応じてリソースファイルが準備される。特にフィールドデータは、データベース等との接続により、フォーム或いは関連データを抽出することに伴って生成されるのが一般的である。ここで生成されたフィールドデータのデータ量が所定の基準サイズ以上である場合、ステップＳ６で、Ｗｅｂアプリケーションサーバ２２は、そのフィールドデータを適当なサイズに分割する。ここで分割する基準となるデータサイズは、フィールドデータの解析に係るクライアント２３におけるヘルパーアプリケーションの負荷を考慮して決定されても良く、或いは通信経路のデータ伝送容量を考慮して決定されても良い。
【００３６】
次にステップＳ７に進み、Ｗｅｂアプリケーションサーバ２２は、その分割したフィールドデータを基に、それに関連付けられるべきフォームと共に、適宜圧縮処理や暗号化処理などを施し、一つに結合して図５に示すような配信ファイルを生成する。尚、ここでフィールドデータが分割された場合は、その分割された数分だけ、この配信ファイルが生成されて、一時的にＷｅｂサーバ２１に保存される。尚、本実施の形態では、フォームファイルは常に配信ファイルに含まれるものとして説明するが、クライアント２３が、その配信されたフォームファイルを保持しておき、必要に応じて、不足しているフォームだけをＷｅｂサーバ２１に随時要求して取得するような仕組みを用いても構わない。
【００３７】
こうして配信ファイルが生成されるとステップＳ８に進み、その生成した配信ファイル群の名前を、フィールドデータの分割の順序に従って順番に並べた配信ファイルリストを生成する。そしてステップＳ９に進み、Ｗｅｂアプリケーションサーバ２２は、最初に配信すべき配信ファイル、即ち、先頭の部分のフィールドデータを含む第一配信ファイルのヘッダ部に、それに続く生成しただけの配信ファイルの位置をリストとして順に記述しておく。そしてＷｅｂサーバ２１は、まず最初に、その第一配信ファイルをクライアント２３に送信する。
【００３８】
図７は、第一配信ファイルのヘッダ部に記載される配信ファイルリストの記載例を示す図である。
【００３９】
その配信ファイルのサーバ２１上での位置が、ＵＲＬとして「，」で区切られる形でリストに記載されている。図７の例では、サーバ２１のアドレスは「ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ」であり、そのフォームデータは、そのサーバのフォルダ「ｆｏｒｍｌｉｓｔ」に格納されており、各配信ファイルはそれぞれ「ｄｅｌｉｖｅｒ２．ｔｍｐ」，「ｄｅｌｉｖｅｒ３．ｔｍｐ」，「ｄｅｌｉｖｅｒ４．ｔｍｐ」の名称で、このフォルダ「ｆｏｒｍｌｉｓｔ」内に格納されていることがわかる。
【００４０】
こうして第一配信ファイルが送信されると、クライアント２３のＷｅｂブラウザ２４は、その配信ファイルを受け取った後ステップＳ１０に進み、その特定のＭＩＭＥ型に適合したヘルパーアプリケーションを起動し、その起動パラメータとして配信ファイル名を渡す。通常、この配信ファイルは、Ｗｅｂブラウザ２４の一時ファイルとして、キャッシュファイル保存先にダウンロードされている。このヘルパーアプリケーションは、クライアント２３の外部メモリ１５に記憶されており、このヘルパーアプリケーションが起動されるときは、外部メモリ１５からメモリ１３のＲＡＭにダウンロードされてＣＰＵ１２の制御の下に実行される。
【００４１】
ステップＳ１１では、この配信ファイル名を受け取ったヘルパーアプリケーションが、そのファイルを使用して帳票の印刷処理を開始する。ここではまずステップＳ１２で、配信ファイルを解析する。この解析処理で、配信ファイルのヘッダ部分を読み取り、それに続く配信ファイルリストを取り出す。またヘッダ部からは他に、印刷時に利用するプリンタ名や印刷部数などの印刷処理用の情報も取り出すのが一般的である。こうして取り出された情報は、ヘルパーアプリケーションによってメモリ１３のワークエリアに保持される。更に、ヘルパーアプリケーションは、配信ファイルの中に包含されているフィールドデータ（５０２，５０５）とフォーム（５０３，５０４）を取り出し、それぞれ環境によって決められている格納フォルダ（外部メモリ１５）に保存する。但し、条件によっては、これらの内容を実ファイルに保存せず、メモリ１３で処理を行うこともセキュリティ上の観点から効果的である。
【００４２】
次にステップＳ１３に進み、取り出されたフォームとフィールドデータとを利用して、ヘルパーアプリケーションはオーバレイ印刷を実行する。こうして印刷処理が終了し、印刷データがスプールされた時点で、ヘルパーアプリケーションは、ステップＳ１２で取り出したファイルリストから、続く配信ファイルの名前を取り出し（ステップＳ１４）、このファイルを取得すべく、ステップＳ１５でＷｅｂサーバ２１に次の配信ファイルを要求し、これに対してステップＳ１６で、Ｗｅｂサーバ２１は、その要求された名前の配信ファイルをクライアント２３に送信する。この送信が無事終了した時点でステップＳ１７に進み、Ｗｅｂサーバ２１は、その配信ファイルをＷｅｂサーバ２１から削除する。
【００４３】
このときヘルパーアプリケーションは、Ｗｅｂブラウザ２４からの起動ではなく、直接Ｗｅｂサーバ２１とやり取りを行っているので、ステップＳ１８で、直接、次の配信ファイルを受け取る。そしてステップＳ１９に進み、その受け取った配信ファイルを、先ほどの第一配信ファイルと同様に解析し、フィールドデータとフォームを取り出して、これらを利用して続きのオーバレイ印刷を実行する（ステップＳ２０）。そしてステップＳ１４に進み、ヘルパーアプリケーションは、その次の配信ファイルをファイルリストから取り出して同様の処理を繰り返す。こうしてステップＳ１４で、後続の配信ファイルがないと判断すると、この処理を終了する。このようにしてヘルパーアプリケーションは、配信ファイルリストに含まれる全てのファイルのオーバレイ印刷処理を実行することにより、全体として大部となる一連のオーバレイ印刷を完了することができる。
【００４４】
以上説明したように本実施の形態１によれば、大量のページを含むフィールドデータを印刷する際における、配信ファイルのダウンロード、及びフィールドデータの解析により最初のページの印刷が遅れるという不具合を解消できるという効果がある。
【００４５】
尚、前述の実施の形態１では、配信ファイルのヘッダに、後続の配信ファイルの名前を全て記載するようにしたが、全ての名前を一度に列挙する形ではなく、一つの配信ファイルにその次の配信ファイルの名前のみを記載するという方法でも構わない。
【００４６】
このようにすることにより、配信ファイルの先頭に全ての配信ファイル名を記載する場合、ヘルパーアプリケーションは、その名前のリストを全処理が終了するまで保持し管理しなければならないが、一つの配信ファイルには次の一つの名前しか書かない場合、一つのリクエストを処理している間は一つの名前のみを管理すればよいため処理の簡便化が計れる。
【００４７】
［実施の形態２］
次に本発明の実施の形態２について説明する。この実施の形態２では、サーバ２１側で、クライアント２３からのリクエストを論理的に分割し、その分割した各リクエストをＵＲＬ付きのリクエストリストとしてサーバ２１からクライアント２３に送信し、クライアント２３のヘルパーアプリケーションから動的にリクエストを発信して、その度にＷｅｂアプリケーションサーバ２２が配信ファイルを生成して送信することにより、各リクエストごとにオーバレイ印刷を行うようにしている。
【００４８】
図８は、本発明の実施の形態２に係る処理を説明する流れ図である。図８において、ステップＳ２１〜Ｓ２５までは、前述の実施の形態１の図６のステップＳ１〜Ｓ５と同であるため、その説明を省略する。尚、これら処理を実行するプログラムは、サーバ２１及びクライアント２３の外部メモリ１５に記憶されており、実行時にメモリ１３にロードされて実行される。
【００４９】
ステップＳ２５で、クライアント２３からの要求を解析したＷｅｂアプリケーションサーバ２２は、そのリクエストが適当な大きさになるように、リクエストをロジック的に分割する。この意味は、一つ一つのリクエスト自体が適当なサイズのフィールドデータを含有するような配信ファイルを生成できるように、元々のリクエストを論理的に分解するものである。この点、前述の実施の形態１のように、フィールドデータ自体を直接分割するものとは異なっている。
【００５０】
こうして分割されたリクエストは、各々の小さな単位のリクエストを表すパラメータ付きＵＲＬとなるが、ステップＳ２７では、そのＵＲＬを、リクエストの順序を保ったままリクエストリストとして第一配信ファイルのヘッダに記述する。
【００５１】
図９は、この実施の形態２における配信ファイルのヘッダの一例を示す図である。
【００５２】
この図９の例では、サーバ２１のアドレスは「ｓｅｒｖｅｒ．ｃｏｍ」であり、「ｃｇｉ？ｓｔａｒｔ−ｄａｔａ−ｒｅｃｏｒｄ＝２００１」により、取り出すフィールドデータの先頭が２００１レコード目であることを指示し、「＆ｅｎｄ−ｄａｔａ−ｒｅｃｏｒｄ＝４０００」により、４０００レコード目までを指定することによって、次のリクエストでクライアント２３のヘルパーアプリケーションが受け取る配信ファイルのフィールドデータの分割部分を表現している。以下、同様に、「ｃｇｉ？ｓｔａｒｔ−ｄａｔａ−ｒｅｃｏｒｄ＝４００１」により、取り出すフィールドデータの先頭が４００１レコード目であることを指示し、「＆ｅｎｄ−ｄａｔａ−ｒｅｃｏｒｄ＝６０００」により６０００レコード目までを、次のアドレスにより、取り出すフィールドデータの先頭６００１レコード目から８０００レコード目までを指定している。
【００５３】
尚、図９では、非常に単純化した形でリクエストを記述しており、実際のリクエストは、より複雑なパラメータを使用した指定が行われる。
【００５４】
こうしてステップＳ２８で、このような第一配信ファイルをＷｅｂサーバ２１からクライアント２３に送信すると、それを受け取ったＷｅｂブラウザ２４は、ステップＳ２９で、その配信ファイルをヘルパーアプリケーションに渡して、そのヘルパーアプリケーションを起動する（ステップＳ３０）。こうしてヘルパーアプリケーションが起動されるとステップＳ３１に進み、その受信した配信ファイルを解析し、ステップＳ３２で、オーバレイ印刷を行う。ここで配信ファイルのヘッダ部から、続くリクエストのＵＲＬリストを取り出して保持しておくことは言うまでもない。
【００５５】
次にステップＳ３３に進み、オーバレイ印刷の後、第一配信ファイルから取り出したリクエストＵＲＬリストの続きがあるかどうかをみる。あればステップＳ３４に進み、そのリクエストをＷｅｂサーバ２１に発信する。これによりＷｅｂアプリケーションサーバ２２は、初回のリクエストと同様に、ステップＳ３５でその要求を解析し、ステップＳ３６で、新たな配信ファイルを生成して、直接、ヘルパーアプリケーションに送信する。
【００５６】
これによりヘルパーアプリケーションはステップＳ３４で、その配信ファイルを受信し、ステップＳ３８で、その受信した新たな配信ファイルを解析する。次にステップＳ３９に進み、前回の配信ファイルと同様にしてオーバレイ印刷を実行する。そしてステップＳ３３に戻り、この処理をリクエストＵＲＬがなくなるまで繰り返す。
【００５７】
このように本実施の形態２によれば、Ｗｅｂサーバ２１は、フィールドデータを論理的に分割することにより、各リクエスト分のフィールドデータを切り出し配信ファイル化する処理が省略できる。また、全配信ファイルを一時ファイルとしておき、それを管理する必要がなくなる。
【００５８】
また前述の実施の形態では、ヘルパーアプリケーションという、Ｗｅｂブラウザ２４とは別個のプログラムによって実行される場合で説明したが、これはＷｅｂブラウザ２４にて動作するプラグイン形式のプログラムによって実行されても良い。
【００５９】
また、Ｗｅｂブラウザ２４と同期して動作し、通信に関する部分をＷｅｂブラウザ２４に肩代わりさせることによって、ヘルパー又はプラグインが直接サーバ２１とやり取りをせずに動作を実現させても構わない。これにより、Ｗｅｂブラウザ２４と一体となった動作によって、ユーザが利用する際の操作のシームレス化に効果がある。
【００６０】
［実施の形態３］
図１０は、本発明の実施の形態３に係る帳票印刷システムのネットワーク構成を表すブロック図で、前述の実施の形態と共通する部分は同じ記号で示している。
【００６１】
Ｗｅｂサーバ２１は、それを負荷分散機として任意複数台のＷｅｂアプリケーションサーバ２２ａ，２２ｂが稼動しており、それに対してインターネットやＬＡＮ／ＷＡＮといったネットワーク１７を通じて、クライアント２３のＷｅｂブラウザ２４が接続を行なう。また同じくネットワーク１７に、サーバ２１及びクライアント２３からアクセス可能な印刷機器２５が備えられている。尚、この印刷機器２５は、クライアント２３又はＷｅｂサーバ２１又はＷｅｂアプリケーションサーバ２２ａ，２２ｂに直接接続されているものであっても良い。
【００６２】
尚、これらサーバ２１及びクライアント２３は、基本Ｉ／Ｏプログラム、ＯＳ及びプログラムをＣＰＵ１２が実行することにより動作する。ここで基本Ｉ／Ｏプログラムはメモリ１３に書き込まれており、ＯＳは外部メモリ１５に書き込まれている。そして、サーバ２１、クライアント２３の電源がオンされたときに、基本Ｉ／Ｏプログラム中のＩＰＬ（イニシャル・プログラム・ローディング）機能により、外部メモリ１５からＯＳがメモリ１３に読み込まれてＯＳの動作が開始される。
【００６３】
尚、この場合のメモリマップは、前述の実施の形態１に係る図３及び図４と同じであるため、その説明を省略する。
【００６４】
図１１は、本発明の実施の形態３に係る帳票システムにおける処理を説明する流れ図である。尚、これら処理を実行するプログラムは、サーバ２１及びクライアント２３の外部メモリ１５に記憶されており、実行時にメモリ１３にロードされて実行される。本実施の形態３で扱うオーバレイ処理は、クライアント２３のＷｅｂブラウザ２４によって、Ｗｅｂサーバ２１にオーバレイ用のリクエストを送信することから開始される。
【００６５】
まずステップＳ４１で、クライアント２３のＷｅｂブラウザ２４は、Ｗｅｂサーバ２１と接続される。この接続は、ネットワーク１７を介したクライアント・サーバ接続を意味している。次にステップＳ４２で、Ｗｅｂサーバ２１は、リクエスト送信のための入力画面（ＵＩ）をクライアント２３のＷｅｂブラウザ２４に返す。次にステップＳ４３に進み、クライアント２３は、その画面を表示装置１４に表示する。そしてＷｅｂブラウザ２４を通じて、クライアント２３のユーザにより、リクエストに対応する情報が入力されるとステップＳ４４に進み、帳票処理要求を発行する。
【００６６】
この要求を受け取ったＷｅｂサーバ２１は、ステップＳ４５で、複数の負荷分散用アプリケーションサーバの中から、この時点でサーバの負荷やリクエスト内容などに基づいて、その処理を行うのに最適なＷｅｂアプリケーションサーバ２２ａ又は２２ｂに処理を渡す。これによりステップＳ４６で、その選択されたＷｅｂアプリケーションサーバ（例えば２２ａ）は、そのリクエストに含まれるデータを解析し、それに適合したデータ検索を行う。このデータ検索において、フォーム、フィールドデータ及び、必用に応じてソースファイルが準備される。特にフィールドデータは、データベースなどとの接続によりデータを抽出されることによって生成されるのが一般的である。尚、ここで前述の実施の形態１と同様に、ここで生成されたフィールドデータのデータ量が所定サイズ以上である場合、Ｗｅｂアプリケーションサーバ２２ａは、そのフィールドデータを適当なサイズに分割し（ステップＳ４７）、第一回目の処理分を取り出す。また、それに引き続いてステップＳ４８で、クライアント２３で引き続き処理されるべきフィールドデータなどに関する情報をリクエストＩＤとして保持しておく。ここでは、まず全体としてのフィールドデータの抽出条件や、何度目の通信ではどのような範囲のフィールドデータを返すべきか、などの詳細な情報をリクエストＩＤと関連付けて保持しておく。尚、ステップＳ４７で分割するための基準となる所定サイズは、フィールドデータの解析に要するクライアント２３のヘルパーアプリケーションの負荷を考慮して決定されても良く、或いはネットワーク１７のデータ伝送容量を考慮して決定されても良い。
【００６７】
このようにフィールドデータが分割された場合、アプリケーションサーバ２２ａは、現在生成した配信ファイルに引き続いて、クライアント２３が配信ファイルの要求を、現在選択されているアプリケーションサーバ２２ａに送信できるように、負荷分散機が理解できる形で、リクエストパラメータを含んだＵＲＬを配信ファイルの先頭に記す。
【００６８】
図１２は、本実施の形態３に係るＵＲＬの一例を示す図である。
【００６９】
図１２において、アプリケーションサーバの名前（Ａ）と、そのサーバで処理されるべきリクエストＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ＝１２３４５６７）及びリクエストの第何番目（ｒｅｑｕｅｓｔ＝２：２番目）かが記述されている。これに従って、負荷分散機となるＷｅｂサーバ２１は、アプリケーションサーバ２２ａに、後続のリクエストを伝えることができる。これによりアプリケーションサーバ２２ａは、そのリクエストＩＤに基づいて、リクエストの現在までの処理分を考慮し、続いて実行されるべき配信ファイルを生成することができる。このようにしてアプリケーションサーバ２２ａは、それら分割したフィールドデータを基に、それに関連付けられるべきフォームとともに、適宜圧縮処理や暗号化処理などを施し、一つのファイルとして結合された、前述の図５に示す配信ファイルを生成してクライアント２３に送信する（ステップＳ４９）。
【００７０】
クライアント２３のＷｅｂブラウザ２４は、この配信ファイルを受け取るとステップＳ５１に進み、その特定のＭＩＭＥ型に適合したヘルパーアプリケーションを起動し、その起動パラメータとして配信ファイル名を渡す。尚、通常、この配信ファイルは、Ｗｅｂブラウザ２４の一時ファイルとしてキャッシュファイル保存先にダウンロードされている。次にステップＳ５２に進み、この配信ファイル名を受け取ったヘルパーアプリケーションは、そのファイルを使用して帳票の印刷処理を開始し、まず、ヘルパーアプリケーションは配信ファイルを解析する。この解析処理で、配信ファイルのヘッダ部を読み取り、図１２に例示したような、リクエストＵＲＬ文字列を取り出す（ステップＳ５３）。また、このヘッダ部からは他に、印刷時に利用するプリンタ名や印刷部数などの印刷処理用の情報も取り出すのが一般的である。これら取り出された情報は、ヘルパーアプリケーションによってメモリ１３に保持される。更に、このヘルパーアプリケーションは、配信ファイルの中に包含されているフィールドデータとフォームとを取り出し、それぞれ環境によって決められている格納フォルダに保存する。但し、条件によっては、これらの内容を実ファイルに保存せず、メモリ１３上で処理することもセキュリティ上の観点からは効果的である。
【００７１】
こうしてオーバレイデータが作成されるとステップＳ５４に進み、フォームとフィールドデータを利用してオーバレイ印刷を実行する。この印刷処理が終了するとステップＳ５５に進み、印刷データがスプールされた時点で、ステップＳ５２で取り出したリクエストＵＲＬ文字列があるかどうかを調べ、あれば後続の配信ファイルを取得するためＷｅｂサーバ２１にリクエストを送信する（ステップＳ５６）。
【００７２】
これによりＷｅｂサーバ２１は、その指定されたＵＲＬから、リクエストを引き継ぐべきＷｅｂアプリケーションサーバ（２２ａ又は２２ｂ）の名前、及びリクエストＩＤ等を取り出し、該当のアプリケーションサーバ（前述の例では２２ａ）に処理を引き渡す（ステップＳ５７）。こうして処理を引き継いだアプリケーションサーバ２２ａは、ステップＳ５８で、そのリクエストＩＤから、ここで生成すべき内容のフィールドデータを生成し、それを基に、その続きとなる新しい配信ファイルを、前述のステップＳ４９の場合と同様にして生成する。そしてそれをクライアント２３に送信する（ステップＳ５９）。
【００７３】
これによりヘルパーアプリケーションは、ステップＳ６０で、直接、続きの配信ファイルを受け取ることができる。そしてステップＳ５２に進み、前述したようにして、その受信した配信ファイルを、先ほどの第一配信ファイルと同様に解析し、以後同様の処理によって次のリクエストＵＲＬを取得し（ステップＳ５３）、オーバレイ印刷を実行する（ステップＳ５４）。そして、後続のリクエストがなくなると、この処理を終了する。
【００７４】
このようにしてヘルパーアプリケーションは、配信ファイルに埋め込まれるリクエストＵＲＬがなくなるまでオーバレイ処理を繰り返し実行する。これにより、全体としては大部となる一連のオーバレイ印刷を完了することができる。
【００７５】
尚、前述の実施の形態３では、配信ファイルのヘッダ中のリクエストＵＲＬにサーバ２１が負荷分散した先のアプリケーションサーバ名が記述されていたが、これはｃｏｏｋｉｅを利用してもかまわない。このように公知の技術であるｃｏｏｋｉｅを利用することにより、アプリケーションサーバの特定を行うための情報を簡便にＷｅｂサーバ２１に伝えることができる。
【００７６】
また、前述の実施の形態３でも説明したように、配信ファイルのヘッダ部には、ヘルパーアプリケーションから動的にリクエストを生成して、そのたびにＷｅｂアプリケーションサーバが配信ファイルを生成するように、リクエストパラメータを含むＵＲＬを列記する形式でもよい。その場合、第一配信ファイルのヘッダ部に全てのリクエストＵＲＬが記述されており、かつそのリクエストの内容は、特定のアプリケーションサーバにおいてセッション管理さるべき内容ではなく、どのアプリケーションサーバでも解釈し、次の配信ファイルを生成するために独立して利用できるものであればよい。
【００７７】
そのヘッダ記述例としては、例えば図１３に示すような例が挙げられる。ここでは見易さのために、複数の配信ファイルで形成されるべき全体のフィールドデータのＤＢ抽出条件を「ｆｉｅｌｄ＿ｅｘｔｒａｃｔ＿ｔｅｒｍ＝［Ａ］」という条件式で表している。
ここで［Ａ］は複雑な条件式となることが想像される。そのような条件式で抽出できるフィールドデータ全体に対して、レコードの先頭を指示する「ｓｔａｒｔ−ｄａｔａ−ｒｅｃｏｒｄ」と、レコードの最後を指示する「ｅｎｄ−ｄａｔａ−ｒｅｃｏｒｄ」の組を複数記載することで、全体の抽出条件［Ａ］と、それを分割したそれぞれのリクエストで何番から何番までのフィールドの組（レコード）を処理するかを表現している。
【００７８】
このように、全体条件と、データの範囲とを指定することにより、複数のアプリケーションサーバのうちどれにリクエストが飛んでも、正しく処理できるようになっている。
【００７９】
このような構成によれば、負荷分散機を挟んでアプリケーションサーバ２２ａ，２２ｂを特定して処理を行う必要はない。これにより、クライアント２３は単にＷｅｂサーバ２１に対してリクエストを送信すればよく、Ｗｅｂサーバ２１では、単にその送信されたリクエストを処理すればよい。即ち、リクエストの処理ごとに負荷の低いサーバに処理を依頼するという負荷分散の仕組みが有効に利用できる。
【００８０】
これによれば、負荷分散機を導入しているシステムにおいても、その仕組みをより有効に利用しつつ、複数の配信ファイルに分割した一連のオーバレイ印刷が実行可能である。
【００８１】
これによれば、もし、配信ファイルの順序が特に重要でない場合は、クライアント２３で複数スレッドなどを用いて第一配信ファイルに記述された複数のリクエストＵＲＬを並行して実行することもできる。よって、複数のリクエストを並列に処理することにより、負荷分散サーバを効率的に動作させながら配信ファイルを取得できるため、全体としてのオーバレイ印刷処理を完了するまでの時間が速くなる。
【００８２】
［実施の形態４］
次に本発明の実施の形態４について説明する。尚、この実施の形態４に係るシステムのハードウェア構成および、配信ファイルのデータ構成等は前述の実施の形態１と同様であるため、その説明を省略する。
【００８３】
図１４は、本実施の形態４に係る帳票処理システムにおける処理を説明するフローチャートで、この処理の流れは前述の図８の場合（実施の形態２）とほぼ同様である。
【００８４】
本実施の形態４に係るオーバレイ処理は、クライアント２３のＷｅｂブラウザ２４によってＷｅｂサーバ２１にオーバレイ用のリクエストを送信するところから始められる。まずステップＳ６１で、クライアント２３のＷｅｂブラウザ２４は、Ｗｅｂサーバ２１と接続され、ステップＳ６２で、Ｗｅｂサーバ２１はリクエスト送信のための入力画面をＷｅｂブラウザ２４に返す。クライアント２３では、このＷｅｂブラウザ２４を通じて、ユーザが適宜リクエストに適した情報を入力し（ステップＳ６３）、ステップＳ６４で帳票処理要求を発行する。
【００８５】
この要求を受け取ったＷｅｂサーバ２１は、Ｗｅｂアプリケーションサーバ２２に処理を渡す。これによりまずステップＳ６５で、Ｗｅｂアプリケーションサーバ２２は、そのリクエストに含まれる要求を解析し、それに適合したデータ検索を行う。このデータ検索において、フォーム、フィールドデータおよびリソースファイルが準備される。特にフィールドデータは、データベースなどとの接続によりデータを抽出されることによって生成されるのが一般的である。
【００８６】
次にステップＳ６６に進み、要求を解析したＷｅｂアプリケーションサーバ２２は、そのリクエストが適当な大きさになるように、そのリクエストを論理的に分割する。この意味は、一つ一つのリクエスト自体が適当なサイズのフィールドデータを含むような配信ファイルを生成できるように、元々のリクエストを論理的に分解するものである。こうして分割されたリクエストは、各々の小さな単位のリクエストを表すパラメータつきＵＲＬとなるが、そのＵＲＬは、リクエストの順序を保ったままリクエストリストとして第一配信ファイルのヘッダに記述される。
【００８７】
図１５は、この実施の形態４に係るＵＲＬを説明する図である。
【００８８】
この例では、ＵＲＬにリクエストパラメータとして、取り出すフィールドデータの範囲（２００１レコード目から４０００レコード目までの指定など）を含めることによって、次のリクエストで、クライアント２３のヘルパーアプリケーションが受け取る配信ファイルのフィールドデータの分割部分を表現している。尚、この図１５では、非常に単純化した形でリクエストを記述しているが、現実のリクエストについては、より複雑なパラメータ指定が行われる。
【００８９】
このように分割した後、その内の最初の分割分のリクエストに従って、Ｗｅｂアプリケーションサーバ２２は配信ファイルを生成し、そのヘッダに前述のようにリクエストリストを記述する（ステップＳ６７）。次にステップＳ６８に進み、こうして作成された第一配信ファイルを、Ｗｅｂサーバ２１からクライアント２３に送信する。
【００９０】
これを受信したＷｅｂブラウザ２４は、ステップＳ６９で、その配信ファイルをヘルパーアプリケーションに渡し、そのヘルパーアプリケーションを起動する（ステップＳ７０）。次にステップＳ７１で、ヘルパーアプリケーションは配信ファイルを解析し、ステップＳ７２で、エラーがあるかどうかを調べ、エラーがあればステップＳ８０に進み、エラーがなければステップＳ７３に進んで、オーバレイ印刷を行う。ステップＳ７４では、このオーバレイ印刷でエラーがあるかどうかを調べ、エラーがあればステップＳ８０のエラー処理に移行する。
【００９１】
またステップＳ７３でオーバレイ印刷を行った印刷データはスプーラに送られる。この印刷データはスプーラで受信される（ステップＳ８２）。
【００９２】
またステップＳ７４でエラーでない場合はステップＳ７５に進み、このスプーリングデータの識別子を、ヘルパーアプリケーションはメモリ１３に保存する。これ以後、この識別子は、印刷処理が複数回起動される場合、そのメモリ１３に追加して保存される。
【００９３】
なお、ステップＳ７１の解析処理において、配信ファイルのヘッダ部から、続くリクエストのＵＲＬリストを取り出して保持しておくことは前述の実施の形態１，２でも説明した通りである。
【００９４】
こうしてオーバレイ印刷を実行した後、ステップＳ７６に進み、第一配信ファイルから取り出したリクエストＵＲＬリストの続きがあるかどうかをみる。続きがあればステップＳ７７に進み、ヘルパーアプリケーションは、そのリクエストをＷｅｂサーバ２１に発信する。これによりＷｅｂアプリケーションサーバ２２は、初回のリクエストと同様にして、その要求を解析し（ステップＳ８６）、次にステップＳ８７で、新たな配信ファイルを生成して、直接、ヘルパーアプリケーションに送信する。
【００９５】
これによりヘルパーアプリケーションは、ステップＳ７８で、その新たな配信ファイルを受信し、前述の配信ファイルの場合と同様に、それを解析してオーバレイ印刷を実行する。この処理を、リクエストＵＲＬがなくなるまで繰り返し実行する。
【００９６】
一方、スプーラは、ステップＳ８２で受信したデータを保持しておき、ステップＳ８４で、スプールデータが残っている場合はステップＳ８５に進み、バックグラウンドで印刷処理を繰り返す。
【００９７】
またステップＳ８０で実行されるエラー処理は、ヘルパーアプリケーション内の処理であり、ステップＳ７５でメモリ１３に保存されたスプーリングデータの識別子を取り出せるかを調べ（ステップＳ８０）、取り出せる識別子が存在すればステップＳ８１に進み、スプーラに対してスプーリングデータの識別子を指定して、その印刷データの削除を依頼する（ステップＳ８３）。これによりスプーラは、ステップＳ８４で、そのスプーラ中に、その識別子の印刷データが残存しているかどうかを調べ、残存していれば、その印刷データを削除する（ステップＳ８５）。
【００９８】
この実施の形態４では、エラーの場合は全ての印刷機器２５のスプールデータを削除したうえで終了していたが、スプールデータを削除せずに終了することももちろん可能である。これにより、印刷出力できるところまでは出力して、処理を終了させることができる。
【００９９】
また上述の実施の形態では、次の配信ファイルを受信する処理で失敗した場合に直ちにエラー処理に移っていたが、再度要求し直して、リトライを実行する方法も採れる。これにより、複数のＷｅｂアプリケーションサーバが起動している場合、再要求時に、ビジーでないサーバにリクエストを転送できるなどの効果がある。
【０１００】
［他の実施の形態］
本発明の目的は前述したように、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ，ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１０１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれている。
【０１０２】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含む。
【０１０３】
【発明の効果】
以上説明したように本発明によれば、大量のデータを含むフィールドデータを印刷する場合でも、遅延を少なくしてオーバレイ印刷を行うことができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るサーバ及びクライアントのハードウェアの構成を示すブロック図である。
【図２】本実施の形態に係る帳票印刷システムのネットワーク構成を示す図である。
【図３】本実施の形態に係るクライアント或いはサーバの外部メモリのメモリマップを示す図である。
【図４】本実施の形態に係るクライアント或いはサーバのメモリのメモリマップを示す図である。
【図５】本実施の形態における配信ファイルの一例を示す図である。
【図６】本発明の実施の形態１に係る帳票印刷システムにおける処理の流れを説明する流れ図である。
【図７】本実施の形態１に係る配信ファイルのヘッダの具体例を示す図である。
【図８】本発明の実施の形態２に係る帳票印刷システムにおける処理の流れを説明する流れ図である。
【図９】本実施の形態２に係る配信ファイルのヘッダの具体例を示す図である。
【図１０】本発明の実施の形態３に係る帳票印刷システムのネットワーク構成を示す図である。
【図１１】本発明の実施の形態３に係る帳票印刷システムにおける処理の流れを説明する流れ図である。
【図１２】本実施の形態３に係る配信ファイルのヘッダの具体例を示す図である。
【図１３】本実施の形態３に係る配信ファイルのヘッダの他の具体例を示す図である。
【図１４】本発明の実施の形態４に係る帳票印刷システムにおける処理の流れを説明する流れ図である。
【図１５】本実施の形態４に係る配信ファイルのヘッダの具体例を示す図である。
【図１】
2005050044.tif 000003
【図２】
2005050044.tif 000004
【図３】
2005050044.tif 000005
【図４】
2005050044.tif 000006
【図５】
2005050044.tif 000007
【図６】
2005050044.tif 000008
【図７】
2005050044.tif 000009
【図８】
2005050044.tif 000010
【図９】
2005050044.tif 000011
【図１０】
2005050044.tif 000012
【図１１】
2005050044.tif 000013
【図１２】
2005050044.tif 000014
【図１３】
2005050044.tif 000015
【図１４】
2005050044.tif 000016
【図１５】
2005050044.tif 000017