(57)【要約】【課題】  クライアントがサーバに対して印刷用データの取得を要求し印刷を実施するシステムにおいて、同一目的の同一データの転送を抑制して動作効率を向上させる。【解決手段】  クライアントにて印刷データを生成するネットワークプリントシステムに対して付加する仕組みは以下の通り；一時利用目的のフォームをクライアントに配信するか否かを制御する仕組み〜フォームの同一性を判断する仕組み、同一であった場合に転送するか否かを判断する仕組み〜、異なる印刷指示群に対して、特定の一時利用フォームをそれぞれ異なるものとして管理する仕組み。【選択図】  図１
2005084850.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に複数存在するプリント指示を行うクライアント端末、プリント用帳票フォームとプリント用データを格納できるＷｅｂサーバを具備するネットワークプリントシステムであり、
該クライアント端末にプリントイメージを作成できる画像生成部を持たせ、クライアント端末側で帳票プリントイメージを作成し出力することを特徴とするネットワークプリントシステムであり、
印刷指示毎に変化しない恒久利用目的のプリント用帳票フォームを唯１回、印刷指示毎に動的に変化する一時利用目的のプリント用帳票フォームを印刷指示毎にクライアントに配信することを特徴とするネットワークプリントシステムにおいて、
一時利用目的のプリント用帳票フォームを印刷指示間で共通に利用することを前提とした場合に効率よく配信することを特徴とする、ネットワークプリントシステム。
【請求項２】
特定の印刷指示群を表す識別子と動的に変化する一時利用目的のプリント用帳票フォームを関係付けてＷｅｂサーバで管理することを特徴とする、請求項１のネットワークプリントシステム。
【請求項３】
クライアントからの配信を要求されたプリント用帳票フォームの名前とサーバで管理する該フォームの名前が合致した場合に配信対象とせず配信効率を向上させることを特徴とする、請求項２のネットワークプリントシステム。
【請求項４】
請求項３において、合致の条件をプリント用帳票フォームのサイズとすることを特徴とするネットワークプリントシステム。
【請求項５】
請求項３において、合致の条件をプリント用帳票フォームの日付とすることを特徴とするネットワークプリントシステム。
【請求項６】
請求項３において、合致の条件をプリント用帳票フォームのチェックサムとすることを特徴とするネットワークプリントシステム。
【請求項７】
請求項３、４、５、６記載のプリント用帳票フォーム合致の条件を任意に組み合わせ、それを合致の条件とすることを特徴とする、請求項２のネットワークプリントシステム。
【請求項８】
プリント用帳票フォームは合致するが、最初の配信からの一定の経過を時間した場合は配信を再開することを特徴とする、請求項２のネットワークプリントシステム。
【請求項９】
請求項８において、配信再開のきっかけを固定の時刻とすることを特徴とするネットワークプリントシステム。
【請求項１０】
請求項８において、配信再開のきっかけを特定のファイルの配信要求とすることを特徴とするネットワークプリントシステム。
【請求項１１】
異なる印刷指示群において、一時利用目的のプリント用帳票フォームを異なるファイルとして扱うことを特徴とする、請求項２のネットワークプリントシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して帳票などのプリントを行う為のネットワークプリントシステムに関するものである。
【背景技術】
【０００２】
インターネットの急速な発展とＷｅｂサーバの林立に伴い、業務処理のＷｅｂ化が推進されている。ネットワークに接続されたパーソナルコンピュータ上には、情報の表示、及び入力が可能なＷｅｂブラウザを搭載するのみで、Ｗｅｂブラウザ経由による業務処理がひろく行われる様になっている。また、ブラウザによる業務を行う為には、ネットワーク上には、Ｗｅｂサーバが存在し、クライアントであるＷｅｂブラウザとの間で情報の交換が行われる。
【０００３】
ブラウザから入力された情報をサーバが受け取り、サーバ内で加工し再びブラウザに送信、表示を行う等の動作を繰り返し行い、結果を得るというような形式で業務が遂行される。
【０００４】
この中でプリント処理に関しては、クライアントから送られた印刷要求を元に、サーバ側でフォームデータを用いたオーバレイ処理を実現することにより、美しいプリント結果が得られるデータをクライアントに配信するシステムが提供されている。
【０００５】
この、ブラウザ経由のプリント処理における課題として、最終的なプリントイメージを生成する処理はすべてサーバ側で行われるため、Ｗｅｂの特徴である不特定多数からの集中的なリクエストに対して、サーバの負荷が大きくなるという点が挙げられている。さらに、プリントイメージの生成はサーバ側のプリンタドライバを利用して行われるため、そのイメージをクライアント側で印刷するには、サーバに存在するプリンタドライバと同一のものを用意する必要がある。また、サーバ側で生成したプリントイメージは内容によってはデータ量が大きくなる場合があり、クライアントへのデータ配信時にネットワークの負荷となることが想定される。
【０００６】
これを解決する手段として、特開２００２−３５１６４５において、サーバからプリント用帳票フォームとプリント用データをクライアントに転送し、クライアント側でプリント用イメージを生成するシステムが提案されており、印刷指示毎に変化しない恒久利用目的のプリント用帳票フォームと、印刷指示毎に動的に変化する一時利用目的のプリント用帳票フォームを区別して転送する仕組みをその特徴としている。
【０００７】
一方、動的に変化するデータを転送するとう視点では提案書（特開平１０−２４０４５８  セイコーエプソン）において、一定間隔で配信元データの更新を確認、更新されていれば転送を試みる仕組みが提案されている。
【特許文献１】特開２００２−３５１６４５
【特許文献２】特開平１０−２４０４５８
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ある一定時間内に、クライアントから複数の印刷指示を同時に発行する場合、配信対象が動的に変化する特徴を有する、一時利用目的の帳票フォームでありながらも、各印刷指示間で同一の意味を持つフォームファイルとして利用可能な機会が少なくないと考えられる。しかし提案書（提案番号１６５７４３６）では印刷指示毎にダウンロードする必要があり、そのサイズが大きいと転送負荷を無視できなくなる。一方、提案書（特開平１０−２４０４５８  セイコーエプソン）において動的に変化するデータを繰り返し転送せずキャッシュする仕組みが提案されているが、更新されていると必ず転送、利用する、という単純動作を繰り返すに過ぎず、各印刷指示の都合で更新後のデータを利用する、しないを細かに制御することが不可能である。
【課題を解決するための手段】
【０００９】
本発明は上記課題を解決する為に考案されたものであり、Ｗｅｂサーバにおいて、クライアントからの印刷指示群に対して予め付与する識別子を以って該印刷指示群の中で共通に利用する一時利用フォームを管理して、該識別子を伴って配信要求を出すクライアントへの配信実施・非実施を制御するものである。
【発明の効果】
【００１０】
本発明により、Ｗｅｂ環境下のネットワークプリントシステムにおいて、予め設定した内容にしたがって一時利用ファイルの配信をきめ細かく制御することが可能となり、ネットワークトラフィックの軽減、スループットの向上などに寄与する。
【発明を実施するための最良の形態】
【００１１】
提案書（提案番号１６５７４３６）におけるネットワークプリントシステムに、一時利用目的のフォームをクライアントに配信するか否かを制御する仕組み、異なる印刷指示群に対して、特定の一時利用フォームをそれぞれ異なるものとして管理する仕組みを付加したものである。
【実施例１】
【００１２】
図1は、本発明を実施するネットワークプリントシステムのソフトウエアブロック図である。１０１はＷｅｂサーバである情報処理装置である。１０２はデータベース等のデータ格納部であり、各業務用データが格納されている。１０３は、クライアントの要求に基づいて、画像生成に必要なデータ及び帳票フォームを合成、配信するためのデータを生成する部分である。１０４は、一時利用フォームの扱いに関するテーブルに基づきクライアントからの配信要求を処理する部分である。１０５はＷｅｂサーバである役割を行うネットワーク通信制御部である。１０６は、帳票プリントを行う為の帳票フォームの格納部分である。１０７は、サーバとクライアントがネットワークで接続されている事を示す。ネットワーク形態として、ＬＡＮ、インターネット、無線等、Ｗｅｂ環境の通信手順に対応するものであれば、その種類は問わない。
【００１３】
１０８はクライアントであるＰＣ等の情報処理装置である。１０９は、サーバに対してデータの入出力を行うブラウザである。１１０は、１０３によって生成された配信データを解析し、画像生成に必要なデータ及び帳票フォームを復元する、データ処理部である。１１１、１１２は、１１０によって復元された帳票フォームを格納する部分である。１１３は、決められた様式に従って帳票イメージを作成する画像生成部である。１１４は、画像生成部で作成されたデータをプリンタが出力できる形式に変換するプリント出力部であり、一般にはプリンタドライバと呼ばれている。１１５はプリンタである。
【実施例２】
【００１４】
図２を用いてサーバにおける配信判断処理を説明する。
サーバがリクエストを受け付け（２０１）、ＪＯＢ群ＩＤおよび配信要求フォームの情報を獲得し（２０２）する。ＪＯＢ群ＩＤとは、クライアントから送られる一連のリクエストに対して付与される識別子を意味し、この一連のリクエストに閉じた中では設定に応じて一時利用フォームを共有する、という前提をおいている。
【００１５】
続いて２０３でそのフォームファイルの配信要求が初めてかどうかをリクエストの内容から判断し、初めてでない場合は、同リクエストに格納される要求ファイル情報とサーバで管理するファイル情報から同一ファイル、かつ配信が必要か否かを判断する（２０４）。２０３で「初めて」または２０４で配信対象と判断された場合は、配信ファイルをロード（２０５）、配信データを生成して（２０６）、クライアントへ配信する（２０７）。
【００１６】
図３を用いてクライアントにおける配信要求情報の獲得および更新について説明する。
【００１７】
クライアントがサーバに配信要求するファイル名を抽出する（３０１）。そのファイルがＪＯＢ群ＩＤディレクトリに存在するか（つまり被配信実績があるか）どうかを判断する。被配信実績がある場合、“ＪＯＢ群ＩＤ／ファイル名”（”／”はパス区切り）として保存されているものとする。３０２が真であった場合、サーバで同一かつ配信要・不要の確認を実施するための情報を収集（３０３）し、サーバへ配信要求を出す（３０４）。サーバにおいて配信する・しないの判断の後、配信の必要がある場合に限りファイルが配信される。配信されたファイルを保存（”ＪＯＢ群ＩＤ／ファイル名”）し（３０５）、配信されたファイルに対して３０３に相当する情報を保存する（３０６）。
【実施例３】
【００１８】
図４を用いて、サーバにおけるクライアントからの配信要求に対する処理を説明する。４０１は一時利用フォームの名前、４０２はどの印刷指示かを区別する識別子（以降ＪＯＢ群ＩＤと記す）である。４０３から４０５は一時利用フォームが同一であることを判断する基準であり、４０３はファイルの日付、４０４はファイルのチェックサム、４０５はファイルのサイズで、それぞれ１が指定されていればそれが基準とすることを意味し、０が指定されていれば基準とはしないことを意味する。なお、チェックサムはその手法を問わない。またそれぞれＪＯＢ群ＩＤ毎に異なる値を設定することが可能である。４０６はクライアント上で一時保存されている一時利用フォームの有効性を決定する情報で、ここでクライアントの一時利用フォームが「無効」と判断された場合は配信要求された一時利用フォームをクライアントに配信する。
【００１９】
一時利用フォームの配信要求を、フォームの情報と共にサーバが受けたとする。クライアントからの配信要求については後述（実施例３）する。４０６において、１）０はクライアントから強制配信要求がきたらクライアントに一時保存されているフォームは「無効」と判断、２）”：”区切りの文字の場合は時刻を表し、サーバが要求を受けた時刻が設定されている時刻と比較して後（未来）の場合「無効」と判断、３）ファイル名の場合は、印刷指示群の中に配信判断対象とは別の配信要求対象としてその名前が指定されていたら「無効」と判断、４）１以上の数値の場合はクライアントから送信される、クライアントでの保存時間と照合され、後者が前者よりも大きい場合は「無効」と判断、「無効」と判断されたものはクライアントへの配信の対象とする。５）−１は照合対照としないことを意味する。
【００２０】
また、図４、ＪＯＢ群ＩＤ：０００３のように、複数の有効性判断（つまり配信する・しないの判断）を定義することも可能とする。この場合「無効」判定が少なくとも１つある場合は「無効」とする。しかし、システム要件によっては全て「有効」と判定された場合に「無効」としてもかまわず、その基準は任意とする。
【実施例４】
【００２１】
図６に示すクライアントからの配信要求を用いて、図４のテーブルの使われ方を例示する。
【００２２】
図６“１回目”はクライアントに一時利用フォームが存在しない状況において必ず配信する記述である。”ｆｍ−ｒｅｓｏｕｒｃｅｆｉｌｅｎａｍｅ”は配信要求指示を表す記号である。サーバに送信する情報は、ファイル名とＪＯＢ群ＩＤで、配信後クライアントに保存するファイル名は、例えば“１回目”例示の場合、配信要求ファイル名：Ａ．ｂｍｐ、ＪＯＢ群ＩＤ：０００１の場合０００１／Ａ．ｂｍｐ、ＪＯＢ群ＩＤ：０００２の場合は０００２／Ａ．ｂｍｐとなり、ＪＯＢ群毎に、つまり異なるアプリケーションで同一の一時利用フォームを別々に扱うことが可能となる。なお、”／”はパス区切り文字を表し、”０００１”または”０００２”ディレクトリを動的に作成、そこにＡ．ｂｍｐを保存することを意味する。
【００２３】
“２回目以降”は既にクライアントに対象のフォームダウンロード済である状況を意味し、“ファイル名、ＪＯＢ群ＩＤ、保存時間、ファイル作成日付、チェックサム、ファイルサイズ゛”それぞれの情報を配信要求としてサーバに投じる。”ｆｍ−ｒｅｓｏｕｒｃｅｆｉｌｅｎａｍｅ”は“１回目”と同等である。例えば“２回目以降”例示の場合、ファイル名：Ａ．ｂｍｐが４０１と、ＪＯＢ群ＩＤ：０００１が４０２とそれぞれ照合される。ここで合致した場合、続いて、ファイル作成日付情報：２００３：０６：１４：２０：３０、チェックサム：３２００、ファイルサイズ：５０１２がそれぞれ４０３、４０４、４０５に基づき同一性確認の情報として利用される。この場合は、図４に１がたっているファイル作成日付とサイズをもって、実際にサーバに保存されているＡ．ｂｍｐと同一性の確認をする。ここで同一であると確認された場合、続いてそれをクライアント上で引き続き有効とするか無効とするかの判断を実施する。４０６において値０が設定されているので、クライアントから強制配信要求があるかどうかの判断をし、要求があればＡ．ｂｍｐを配信対象とし、要求がなければ配信対象としない。保存時間：９００は照合先がないので無視される。強制配信要求の指定の方法はその種類を問わない。
【実施例５】
【００２４】
クライアントにて配信要求情報を生成する場合、図５に示すテーブルを利用する。例えばＡ．ｂｍｐをＪＯＢ群ＩＤ：０００１を伴って要求する場合、ファイル作成日付、チェックサム、ファイルサイズを図５に示すテーブルより取得、さらに、被配信時刻と配信要求時刻の差を計算、それを保存時間として、結果として図６“２回目以降”に例示されている情報を生成する。
【００２５】
なお、図５に示すテーブルは、配信時刻（５０２）を除きクライアントに一時保存されているフォームの情報をより早く獲得するための手段であり、必ずしも必要なものではない。配信時刻を除く情報がテーブルに存在しない場合はファイルを以下のパスで検索して、直接情報を取得する。
【００２６】
ＪＯＢ群ＩＤ／ファイル名
例示の場合０００１／Ａ．ｂｍｐとなる。
【００２７】
“／”はパス区切り文字を表す。配信された一時利用フォームは以下のパスに保存される。
【００２８】
ＪＯＢ群ＩＤ／ファイル名
例示の場合０００１／Ａ．ｂｍｐとなる。
【図面の簡単な説明】
【００２９】
【図１】本発明を実施するネットワークプリントシステムのブロック図
【図２】サーバにおける配信管理を説明するフローチャート
【図３】クライアントにおける配信要求を説明するフローチャート
【図４】サーバにおける一時利用ファイル管理テーブル
【図５】クライアントにおける一時利用ファイル管理テーブル
【図６】クライアントにおける配信要求例
【図１】
2005084850.tif 000003
【図２】
2005084850.tif 000004
【図３】
2005084850.tif 000005
【図４】
2005084850.tif 000006
【図５】
2005084850.tif 000007
【図６】
2005084850.tif 000008