JP2021005328A - 帳票文書生成システム、帳票文書生成方法、サーバおよびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】テンプレート情報とユーザーに指定されるデータによって動的に生成されるＷｅｂ帳票に追記されたユーザー入力を含めて電子文書として帳票文書を保存することを可能とする。【解決手段】帳票文書生成システムにおいて、クライアント端末は、Ｗｅｂブラウザにて表示されている帳票文書上におけるユーザー入力を受け付け、前記ユーザー入力を受け付けた帳票文書の保存要求をサーバに送信し、前記ユーザー入力を画像化して画像データを生成し、前記画像データと、前記帳票文書上における前記ユーザー入力の位置情報とを所定の格納場所に格納し、前記サーバは、前記クライアント端末から前記保存要求を受信した際に、前記所定の格納場所を示す情報を発行し、前記クライアント端末に通知し、前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成し、前記新たな帳票文書を保存する。【選択図】 図９

Description

本発明は、帳票文書生成システム、帳票文書生成方法、サーバおよびその制御方法、並びにプログラムに関する。

昨今、ペーパーレス化による業務の効率化や省資源化を目的として、紙媒体の情報を文書データに置き換えることにより電子化を促進する企業が増加している。また、業務データの管理や各種処理を行う形態として、クラウドサービスの利用が普及し始めている。ユーザーは、クライアント端末のＷｅｂブラウザを用いて、クラウドサービスが提供するＷｅｂページ上で電子化された帳票文書データを閲覧する。さらに、業務フローに応じて閲覧している帳票文書データを編集・印刷するような利用ケースの増加が予想される。そのため、Ｗｅｂページ上で帳票文書データを扱う場合、帳票システムで一般的に利用されるＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）形式のデータではなく、よりＷｅｂとの親和性が高いＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）等の形式を使用することが想定される。

このような状況において、クラウドサービス側で帳票文書全体を生成完了してからＷｅｂブラウザに表示する構成において、特にページ数の多い業務帳票では、Ｗｅｂページ上で閲覧できるまでユーザーが待たされる可能性がある。そのため、文書全体が生成され送信されるのを待つのではなく、帳票文書を所定のページ単位毎に分割してＰＤＦを生成し、各分割ＰＤＦを夫々ＳＶＧ等に変換する。そして、変換完了したページから順に素早く受信してＷｅｂブラウザに表示する。また、Ｗｅｂブラウザに表示した帳票文書に対して後からユーザー入力を追記することも可能である。帳票データに対するユーザー入力の一例として、申し込みや帳票文書の内容を確認済みである旨を示す署名が挙げられる。

このような帳票文書生成システムにおいて、クライアント端末のＷｅｂブラウザに表示したＷｅｂ帳票をＷｅｂブラウザ上で入力されたユーザー入力と共に電子文書として保存したいことが想定される。例えば、販売員による保険営業において、タブレット端末に表示した保険契約申込画面からユーザーが契約する際に、申込文書を証跡として残すため電子文書として保存する。ＳＶＧは容易に書き換え可能なため保存の用途に適しておらず、保存用途にはＰＤＦが適している。そのため、ＰＤＦ形式の帳票文書を保存用として改めて生成することが考えられる。例えば、特許文献１には、クライアント端末で撮影した画像データやユーザーの自署データを既存のレイアウトテンプレートに基づいて成形したＰＤＦファイルを生成する技術が提示されている。

特開２０１７−１５１９１３号公報

しかしながら、特許文献１におけるＷｅｂ帳票は、テンプレート情報とユーザーに指定されるデータによって動的に生成されるため、ユーザーに指定されるデータ量によって自署データの出力ページ番号や出力座標が変わる可能性がある。また、ユーザー入力にはユーザーがＷｅｂ帳票上に自由に追記するような手書き入力やラインマーカーなど、どこに入力されるかが予め分からない入力も存在する。

本願発明では、テンプレート情報とユーザーに指定されるデータによって動的に生成されるＷｅｂ帳票に追記されたユーザー入力を含めて電子文書として帳票文書を保存することを可能とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、Ｗｅｂブラウザを備えるクライアント端末と、前記Ｗｅｂブラウザにて閲覧可能な帳票文書を生成するサーバとを含んで構成される帳票文書生成システムであって、前記クライアント端末は、前記Ｗｅｂブラウザにて表示されている帳票文書上におけるユーザー入力を受け付ける受け付け手段と、前記ユーザー入力を受け付けた帳票文書の保存要求を前記サーバに送信する送信手段と、前記受け付け手段にて受け付けたユーザー入力を画像化して画像データを生成する画像化手段と、前記画像化手段にて生成した画像データと、前記帳票文書上における前記ユーザー入力の位置情報とを所定の格納場所に格納する格納手段とを有し、前記サーバは、前記クライアント端末から前記保存要求を受信した際に、前記所定の格納場所を示す情報を発行し、前記クライアント端末に通知する通知手段と、前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成する生成手段と、前記生成手段にて生成された新たな帳票文書を保存する保存手段とを有する。

本発明によれば、テンプレート情報とユーザーに指定されるデータによって動的に生成されるＷｅｂ帳票に追記されたユーザー入力を含めて電子文書として帳票文書を保存することができる。

本願発明の一実施形態に係るシステム構成の例を示す図。 本願発明の一実施形態に係るハードウェア構成の例を示す図。 本願発明の一実施形態に係るソフトウェア構成の例を示す図。 第１の実施形態に係るオーバレイ処理のフローチャート。 第１の実施形態に係るデータ変換処理のフローチャート。 第１の実施形態に係るインデックスファイルの例を示す図。 第１の実施形態に係る出力ページ情報ファイルの例を示す図。 第１の実施形態に係る画像情報ファイルの例を示す図。 第１の実施形態に係る帳票保存処理を示すシーケンス図。 第１の実施形態に係る業務サーバの業務画面の例を示す図。 第１の実施形態に係るＷｅｂ帳票画面の例を示す図。 第２の実施形態に係る画像変換処理のフローチャート。 第２の実施形態に係る保存コンテンツ選択画面の例を示す図。 第３の実施形態に係る画像変換処理のフローチャート。 第３の実施形態に係る出力ページ情報ファイルの例を示す図。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１の実施形態＞
［システム構成］
図１は、本発明の一実施形態に係る帳票文書生成システムとしてのシステム構成の例を示す図である。図１において、クライアント端末１０２は、有線または無線ＬＡＮを介してローカルネットワーク１０１に接続され、ローカルネットワーク１０１を介してインターネット１００にアクセスし、１０４〜１０６のサーバにアクセスする。クライアント端末１０２は、例えばデスクトップパソコン、ノートパソコン、スマートフォンやタブレットＰＣ等が該当する。クライアント端末１０２は、Ｗｅｂブラウザ等のプログラムを実行する環境を内蔵している。なお、クライアント端末１０２は、１台のみを示しているが、複数台のクライアント端末１０２が含まれてよい。

業務サーバ１０３は、ユーザー業務情報を管理するサーバである。本実施形態では、一例として、業務サーバ１０３で業務情報を管理し、販売員が業務サーバ１０３の情報を用いて顧客に対して営業を行うユースケースを想定して説明する。業務サーバ１０３は、クライアント端末１０２からのリクエストに応じて業務情報の表示と、帳票データ生成指示を行うための画面を提供する。なお、図１において、業務サーバ１０３は、ローカルネットワーク１０１内に位置した構成として示しているが、インターネット１００上に配置され、インターネット１００を介してクライアント端末１０２と接続してもよい。

帳票生成サーバ１０４は、業務サーバ１０３から業務情報を受け取り、オーバレイ出力処理、並びに帳票閲覧プログラムの生成処理を実行する。具体的には、帳票生成サーバ１０４は、テキストデータであるフィールドデータファイルと所定のフォーム情報を含むフォーム情報ファイルとを重ね合わせて印刷ページを生成する。そして、帳票生成サーバ１０４は、仮想プリンタ（不図示）に指示して上記生成された印刷ページをＰＤＦファイルとして生成する。さらに、帳票生成サーバ１０４は、生成した帳票文書を閲覧可能とする帳票閲覧プログラム（不図示）を生成する。本実施形態において、帳票閲覧プログラムとは、ネットワークを介して配信可能な、Ｗｅｂブラウザ上で動作するＷｅｂアプリケーションである。多くの場合、これらのＷｅｂアプリケーションは、Ｗｅｂページを表現するマッシュアップ言語（ＨＴＭＬ：Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、及びＷｅｂブラウザ上で動作するプログラミング言語（ＪａｖａＳｃｒｉｐｔ）により動作するアプリケーションである。Ｗｅｂブラウザ上で動作するＷｅｂアプリケーション以外、コンピュータシステム上で実行するアプリケーションでも良い。

帳票生成サーバ１０４は、フォーム情報ファイルに業務情報を重ね合わせて帳票文書を生成し管理する。そして、帳票生成サーバ１０４は、変換サーバ１０５に対して、生成した帳票文書をＷｅｂ帳票文書に変換するリクエストを行う。また、帳票生成サーバ１０４は、クライアント端末１０２から帳票文書の保存リクエストを受け付ける。帳票生成サーバ１０４は、クライアント端末１０２のＷｅｂブラウザ３２１でＷｅｂ帳票文書に追記されたユーザー入力を画像化することにより得られる画像ファイルを帳票文書に挿入し、新たに帳票文書として作成し、ストレージサーバ１０６に保存する。ここでの帳票文書上にて行われるユーザー入力の詳細は、後述する。

変換サーバ１０５は、帳票生成サーバ１０４から帳票文書の変換リクエストを受け付けて、Ｗｅｂ帳票文書を生成する。Ｗｅｂ帳票文書とは、Ｗｅｂページ上で扱うＳＶＧ等の形式の帳票文書である。

ストレージサーバ１０６は、ファイル管理、保存を行うサーバであり、クライアント端末１０２、帳票生成サーバ１０４、変換サーバ１０５からのファイルアップロード／ダウンロードを受け付ける。ストレージサーバ１０６は、ファイルのライフサイクルを管理する機能を有し、保存後一定時間経過したファイルを自動的に削除する。本実施形態では、所定のファイルパスに保存したファイルは、保存後一日以上経過すると自動的に削除されるものとする。以降、ライフサイクル管理機能により自動的に削除される領域を「ライフサイクル管理領域」と記載する。

なお、本実施形態では、予めユーザー管理者が各サーバに次の情報を保存しておくものとする。すなわち、業務サーバ１０３に業務情報データを保存し、帳票生成サーバ１０４に顧客データに対応するフォーム情報ファイルを保存する。また、本実施形態では、業務サーバ１０３、帳票生成サーバ１０４、変換サーバ１０５、およびストレージサーバ１０６をそれぞれ別個に示したが、これらの全体もしくは一部が同一のサーバ（サービス）として提供されてもよい。また、各サーバは、負荷分散等の観点から複数の装置にて構成されてもよい。

［ハードウェア構成］
図２は、本実施形態に係る、クライアント端末１０２、業務サーバ１０３、帳票生成サーバ１０４、変換サーバ１０５、およびストレージサーバ１０６として動作可能な情報処理装置のハードウェア構成の例を示す図である。なお、以下に示すハードウェア構成は一例であり、装置ごとに異なる構成を備えていてもよい。

図２において、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明に係る各種処理を実現するためのプログラムを実行する。ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２は、不揮発性の記憶領域であり、例えば、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）などのプログラムが格納されている。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０１のワーク領域として利用されたり、本発明に係る処理を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりする。ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０４は、基本ソフトウェアであるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やソフトウェアモジュールが記憶されている間接記憶装置である。関節記憶装置は、ＳＳＤ（ソリッドステートドライブ）などの他の記憶装置であってもよい。入力装置２０５は、不図示のキーボードやポインティングデバイスやタッチジェスチャ検出デバイスなどである。出力装置２０６は、例えば、表示部であるディスプレイが該当する。入力装置２０５と出力装置２０６は、タッチスクリーンディスプレイのような一体型モジュールでも構わない。Ｉ／Ｆ２０７は、各ネットワークに接続するためのインタフェースである。

これらハードウェアでは、起動後、ＣＰＵ２０１によりＢＩＯＳが実行され、ＯＳがＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。ＣＰＵ２０１は、ＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に随時、実行可能にロードする。各種ソフトウェアモジュールは、各デバイスの協調によりＣＰＵ２０１によって実行され動作する。また、Ｉ／Ｆ２０７はインターネット１００やローカルネットワーク１０１などのネットワークに接続されており、ＯＳの動作に従ってＣＰＵ２０１により制御され、上述した通信手段による通信を実現する。

［ソフトウェア構成］
図３は、本実施形態に係る、クライアント端末１０２、業務サーバ１０３、帳票生成サーバ１０４、変換サーバ１０５、およびストレージサーバ１０６のソフトウェア構成の例を示す図である。各サーバソフトウェア構成と、各サーバが扱う管理情報について説明する。本実施形態において、各サーバは、図２に示すような情報処理装置のハードウェア構成により実現されるものとして説明する。

（業務サーバ）
業務サーバ１０３は、Ｗｅｂ画面Ｉ／Ｆ３３１、業務情報管理部３３２、およびストレージ３３３を含んで構成される。各ソフトウェアモジュールは、図２で示すようなＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂ画面Ｉ／Ｆ３３１は、業務サーバ１０３のユーザーインタフェースを提供するものであり、クライアント端末１０２のＷｅｂブラウザ３２１からの要求に応じて、業務情報を表示する画面を生成して返す。業務情報管理部３３２は、業務情報をストレージ３３３に記憶して管理する。これらの情報は、業務サーバ１０３の外部メモリではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバに記憶するように構成することもできる。

業務サーバ１０３の業務情報管理部３３２が管理している顧客情報の例を表１に示す。

表１に示す顧客情報は、帳票を生成する際に使用するデータテーブルである。本実施形態では、顧客を一意に識別するための顧客ＩＤ（識別子）、氏名、住所、生年月日、および、連絡先を含む情報を保持している。帳票を生成するために必要なデータは、本実施形態の顧客情報に限らず、製品の在庫や納品情報、入出金情報等、様々な物が想定される。

また、業務サーバ１０３の業務情報管理部３３２が管理している帳票情報の例を表２に示す。

表２に示す帳票情報は、帳票を生成する際に使用する帳票テンプレート情報を保持するデータテーブルである。帳票情報を一意に識別するための帳票ＩＤ（識別子）、画面表示用の帳票名、および、帳票生成サーバ１０４で管理されているフォーム情報ファイルを特定するための帳票テンプレートＩＤを含んで構成される。

業務サーバ１０３のＷｅｂ画面Ｉ／Ｆ３３１は、クライアント端末１０２のＷｅｂブラウザ３２１から帳票プレビュー指示を受け付ける。その帳票プレビュー指示に基づいて、業務情報管理部３３２は、該当の顧客情報と、帳票情報の帳票テンプレートＩＤを帳票生成サーバ１０４に送信し、帳票生成のリクエストを行う。

（帳票生成サーバ）
帳票生成サーバ１０４は、Ｗｅｂサーバ３４１、帳票情報管理部３４２、オーバレイ部３４３、保存文書生成部３４４、および、ストレージ３４５を含んで構成される。各ソフトウェアモジュールは、図２で示すようなＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂサーバ３４１は、帳票生成サーバ１０４の各種インタフェースを提供し、クライアント端末１０２のＷｅｂブラウザ３２１や、業務サーバ１０３からのリクエストを受付け、そのリクエストに対する応答を返す。帳票情報管理部３４２は、帳票テンプレート情報、および、帳票データ情報をストレージ３４５に格納して管理する。保存文書生成部３４４は、クライアント端末１０２のＷｅｂブラウザ３２１でＷｅｂ帳票文書に追記（記入）されたユーザー入力を画像化した画像ファイルを帳票文書に挿入し保存用の帳票文書を生成する。

帳票生成サーバ１０４の帳票情報管理部３４２が管理している帳票テンプレート情報の例を表３に示す。

表３に示す帳票テンプレート情報は、帳票生成サーバ１０４が管理するフォーム情報ファイルのデータテーブルである。本実施形態では、フォーム情報ファイルをストレージサーバ１０６にファイルとして保持している。帳票テンプレートＩＤはフォーム情報ファイルを一意に識別するＩＤ（識別子）であり、表２に示した業務サーバ１０３で管理される帳票情報の帳票テンプレートＩＤに対応する。帳票テンプレートＵＲＬは、帳票テンプレートのフォーム情報ファイルが格納された位置情報（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を示す。本実施形態では、帳票テンプレートＵＲＬは、ストレージサーバ１０６にて提供される格納場所を示している。ここでは、帳票生成サーバ１０４は、フォーム情報ファイルが格納されているストレージサーバ１０６の格納場所にアクセスできるものとする。

Ｗｅｂサーバ３４１は、業務サーバ１０３からの帳票生成リクエストを受け付けると、そのリクエストに含まれる顧客情報と、帳票テンプレートＩＤを基にオーバレイ部３４３にオーバレイ出力を指示する。オーバレイ部３４３は、該当の帳票テンプレート情報の帳票テンプレートＵＲＬにアクセスしてフォーム情報ファイルをストレージサーバ１０６から取得してフォーム情報を取り出す。さらに、オーバレイ部３４３は、該当の顧客情報と取得したフォーム情報を重ね合わせてオーバレイ出力することで、ＰＤＦファイルを生成する。

また、帳票生成サーバ１０４の帳票情報管理部３４２は、生成したＰＤＦファイルを、ストレージサーバ１０６のライフサイクル管理領域に出力する。帳票生成サーバ１０４の帳票情報管理部３４２は、出力したＰＤＦファイルとともにＰＤＦファイルの情報を記述したオーバレイインデックスファイルと、オーバレイした結果である各出力データの出力座標等を記述した出力ページ情報ファイルを管理する。なお、オーバレイインデックスファイルと出力ページ情報ファイルについては後述する。さらに、帳票生成サーバ１０４の帳票情報管理部３４２は、出力したＰＤＦファイルの情報を変換サーバ１０５に送信し、Ｗｅｂ帳票文書への変換リクエストを行う。

帳票生成サーバ１０４の帳票情報管理部３４２が管理し、ストレージ３４５に保持する帳票データ情報の例を表４に示す。

表４に示す帳票データ情報は、帳票生成サーバ１０４で管理される帳票文書データについてのデータテーブルである。オーバレイＩＤは、業務サーバ１０３から帳票生成リクエストを受け付けた際に帳票情報管理部３４２が発行するＩＤ（識別子）であって、オーバレイ処理を一意に識別可能なＩＤである。オーバレイインデックスファイルＵＲＬは、オーバレイ部３４３が生成するＰＤＦファイルに関する情報を記載したインデックスファイルにアクセスするためのＵＲＬである。オーバレイ処理を開始した時点で、オーバレイ部３４３がオーバレイインデックスファイルを生成する。オーバレイインデックスファイルについては後述する。出力ページ情報ファイルＵＲＬは、オーバレイ部３４３が生成するオーバレイ処理でのみ取得できる情報を記載した出力ページ情報ファイルにアクセスするためのＵＲＬである。オーバレイ処理を開始した時点で、オーバレイ部３４３が出力ページ情報ファイルを生成する。出力ページ情報ファイルについては後述する。変換ＩＤは、帳票生成サーバ１０４が変換サーバ１０５に対して変換リクエストを発行した際に、変換サーバ１０５が発行し応答として返すＩＤであって、変換処理を一意に識別可能なＩＤである。変換インデックスファイルＵＲＬは、変換インデックスファイルを取得するためのＵＲＬである。変換インデックスファイルについては後述する。

帳票生成サーバ１０４は、変換サーバ１０５に対して変換ＩＤを指定して変換情報取得リクエストを行う。応答として変換インデックスファイルＵＲＬが変換サーバ１０５から返された場合、帳票生成サーバ１０４は、その情報を帳票データ情報にて対応付けて保持する。

帳票生成サーバ１０４のＷｅｂサーバ３４１は、クライアント端末１０２から帳票文書保存リクエストを受け付けると、リクエストに含まれるオーバレイＩＤをもとにオーバレイ処理を特定し、画像アップロードＵＲＬを生成する。画像アップロードＵＲＬとは、クライアント端末１０２のＷｅｂブラウザ３２１が生成した画像ファイルをアップロードするためのＵＲＬである。オーバレイ処理を特定した時点で、保存文書生成部３４４が画像情報ファイルを生成する。画像情報ファイルについては後述する。Ｗｅｂサーバ３４１は、クライアント端末１０２から画像ファイルのアップロード完了通知を受け付ける。アップロード完了通知を受け付けると、Ｗｅｂサーバ３４１は、リクエストに含まれているオーバレイＩＤをもとに該当帳票データ情報からオーバレイインデックスファイルＵＲＬと画像情報ファイルＵＲＬにアクセスする。そして、Ｗｅｂサーバ３４１は、取得したオーバレイインデックスファイルに記述されているＰＤＦファイルと画像情報ファイルに記載されている画像ファイルを取得する。保存文書生成部３４４は、取得したＰＤＦファイルと画像ファイル、画像情報ファイルに記載されている画像ファイルの挿入位置情報を基に保存用帳票文書を生成する。

（変換サーバ）
変換サーバ１０５は、Ｗｅｂサーバ３５１、変換情報管理部３５２、データ変換部３５３、および、ストレージ３５４を含んで構成される。各ソフトウェアモジュールは、図２で示したようなＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂサーバ３５１は、変換サーバ１０５の各種インタフェースを提供し、帳票生成サーバ１０４から帳票文書の変換リクエスト、および、変換情報取得リクエストを受け付け、リクエストに対する応答を返す。変換情報管理部３５２は、変換情報をストレージ３５４に格納して管理する。

変換情報管理部３５２が管理しストレージ３５４に保持する変換情報の例を表５に示す。

表５に示す変換情報は、変換情報管理部３５２で管理される変換処理についてのデータテーブルである。変換ＩＤは、帳票生成サーバ１０４から変換リクエストを受け付けた際に、変換情報管理部３５２が発行するＩＤ（識別子）であって、変換処理を一意に識別可能なＩＤである。オーバレイインデックスファイルＵＲＬは、変換対象のファイルに関する情報が記載されたインデックスファイルにアクセスするためのＵＲＬであって、帳票生成サーバ１０４から変換リクエストを受け付けた際に受け取る。オーバレイインデックスファイルについては後述する。変換インデックスファイルＵＲＬは、変換インデックスファイルにアクセスするためのＵＲＬである。変換処理を開始した時点で、データ変換部３５３が変換インデックスファイルを生成する。変換インデックスファイルについては後述する。

データ変換部３５３は、オーバレイインデックスファイルを定期的に取得する。そして、データ変換部３５３は、オーバレイインデックスファイルに記述されている変換対象のデータを取得して変換を行い、その結果を変換インデックスファイルに記述する。また、変換サーバ１０５は、帳票生成サーバ１０４から変換ＩＤを指定した変換情報取得リクエストを受け付けると、変換情報管理部３５２が該当の変換情報を抽出して返す。

（ストレージサーバ）
ストレージサーバ１０６は、Ｗｅｂサーバ３６１、ファイル情報管理部３６２、およびストレージ３６３を含んで構成される。各ソフトウェアモジュールは、図２で示したようなＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

ストレージサーバ１０６のＷｅｂサーバ３６１は、ストレージサーバ１０６の各種インタフェースを提供する。ファイル情報管理部３６２は、ファイル情報を管理し、Ｗｅｂサーバ３６１で受け付けたリクエストに応じてファイルの入出力を行う。ストレージ３６３は、ファイル情報やストレージサーバ１０６が受信したファイルを格納する。

ファイル情報管理部３６２が管理するファイル情報の例を表６に示す。

表６に示すファイル情報は、ファイル情報管理部３６２で管理されるストレージサーバ１０６に保存されるファイルの情報である。データＵＲＬは、ストレージサーバ１０６に保存するファイルを一意に識別するＵＲＬである。ファイルパスは、ストレージ３６３上のファイルパスでありファイルの格納場所を示す。データＵＲＬに対するリクエストをＷｅｂサーバ３６１で受け付け、ファイル情報管理部３６２が該当するファイル情報を更新し、ストレージ３６３のファイル操作を行う。例えば、ストレージサーバ１０６に対してファイル操作を要求するクライアントは、データＵＲＬに対してＨＴＴＰ ＧＥＴメソッドをリクエストすることで対応するファイルをウンロード可能である。また、データＵＲＬに対してＨＴＴＰ ＰＵＴメソッドにファイル添付してリクエストすることでファイルをアップロードして保存可能である。さらに、データＵＲＬに対してＨＴＴＰ ＤＥＬＥＴＥメソッドをリクエストすることで対応するファイルを削除可能である。

［インデックスファイル］
次に、帳票生成サーバ１０４のオーバレイ実行時、および、変換サーバ１０５の変換実行時にそれぞれ生成され、逐次更新が行われるインデックスファイルについて説明する。なお、本実施形態において、オーバレイインデックスファイル、および変換インデックスファイルは、同じ構造を有するものとして説明する。

図６において、インデックスファイル６００〜６３０は、帳票生成サーバ１０４と、変換サーバ１０５が夫々、オーバレイ出力処理、データ変換処理を実行する際に生成、更新を行うインデックスファイルの例を時系列に示したものである。帳票生成サーバ１０４、及び、変換サーバ１０５はまず、処理が開始された時点で、ストレージサーバ１０６のライフサイクル管理領域にインデックスファイルを生成する。この時点では、初期状態として、インデックスファイル６００の状態となる。本実施形態では、インデックスファイルは、ＪＳＯＮファイル形式を採用し、「ｄａｔａＬｉｓｔ」をキーとする処理結果のデータＵＲＬのリストと、「ｅｎｄ」をキーとする処理完了フラグから構成される。

本実施形態では、オーバレイ出力結果をＰＤＦファイルとし、ファイル出力単位は１ページ毎とする。例えば、３ページの帳票に対して３つのＰＤＦファイルを出力する。ただし、ファイル出力単位は１ページ毎とする必要はなく、複数ページ固定、全体ページ数から計算した値等、オーバレイ部３４３で制御可能であればこれに限らない。また、変換サーバ１０５による変換処理もオーバレイ出力結果のＰＤＦファイル単位で変換を行う。

帳票生成サーバ１０４、および変換サーバ１０５は夫々の処理開始時に、初期状態のインデックスファイル６００を生成する。この時、ファイルは生成されていないため、「ｄａｔａＬｉｓｔ」は要素が空であり、処理結果を示す「ｅｎｄ」の値はｆａｌｓｅである。この後、帳票生成サーバ１０４、および変換サーバ１０５は夫々、順次処理を実行し、処理結果のファイルをストレージサーバ１０６のライフサイクル管理領域にアップロードし、そのデータＵＲＬを「ｄａｔａＬｉｓｔ」に追加する。インデックスファイル６１０は、１ファイル目がアップロードされた状態を示す。インデックスファイル６２０は、２ファイル目がアップロードされた状態を示す。さらに、帳票生成サーバ１０４、および変換サーバ１０５は夫々、最後のページである３ファイル目の処理結果のファイルをアップロードした時点で、インデックスファイルをインデックスファイル６３０の状態に更新する。インデックスファイル６３０は、「ｄａｔａＬｉｓｔ」に３ファイル目に対応するデータＵＲＬが追加されているとともに、処理完了フラグ「ｅｎｄ」がｔｒｕｅに更新されている。

変換サーバ１０５は、オーバレイインデックスファイルをストレージサーバ１０６から取得して参照することで、帳票生成サーバ１０４のオーバレイ出力の進捗を知ることができる。そのため、変換サーバ１０５は、オーバレイ出力が完了しているＰＤＦファイルから変換処理を開始することができる。また、クライアント端末１０２は、変換インデックスファイルをストレージサーバ１０６から取得して参照することで、変換サーバ１０５の変換処理の進捗を知ることができ、変換が完了しているＷｅｂ帳票文書をダウンロードして表示することができる。

［出力ページ情報ファイル］
次に、帳票生成サーバ１０４のオーバレイ実行時に生成し、逐次更新を行う出力ページ情報ファイルについて説明する。出力ページ情報は、Ｗｅｂ帳票画面を構築する際に利用する情報である。オーバレイ実行時に取得できる、オーバレイで利用した帳票テンプレートの情報やオーバレイの結果帳票に出力されたデータの出力座標等を持つ。本実施形態では、クライアント端末１０２のＷｅｂブラウザ３２１でＷｅｂ帳票文書にユーザー入力として署名を行うための署名欄の位置情報を保持する。Ｗｅｂブラウザ３２１は、ブラウザ画面上でのタッチイベントの座標情報と出力ページ情報ファイルに記載された署名欄の出力座標の情報から、署名欄がクリックされたことを検知して入力モードへの切り替えを行い、Ｗｅｂ帳票文書へのユーザー入力を実現する。なお、ユーザー入力として、例えば、ＨＴＭＬ５で導入されたｃａｎｖａｓを利用することにより、各種コンテンツを容易に追記可能である。なお、ユーザー入力の方法はこれに限定するものではなく、公知の方法を利用可能である。

図７において、出力ページ情報ファイル７００〜７３０は、帳票生成サーバ１０４がオーバレイ出力処理を実行する際に生成、更新を行う出力ページ情報ファイルの例を時系列に示したものである。帳票生成サーバ１０４はまず、処理が開始された時点で、ストレージサーバ１０６のライフサイクル管理領域に出力ページ情報ファイルを生成する。この時点では、初期状態として、出力ページ情報ファイル７００の状態となる。本実施形態では、出力ページ情報ファイルは、ＪＳＯＮファイル形式を採用し、「ｐａｇｅｓ」をキーとするオーバレイ時に取得可能な出力ページに関連する情報のリストと、「ｅｎｄ」をキーとする処理完了フラグから構成される。本実施形態では、出力ページに関連する情報としてページ番号（「ｐａｇｅＮｏ」）、ページ生成に利用したテンプレートＩＤ（「ｆｏｒｍＮａｍｅ」）、当該ページに署名欄が存在する場合は署名欄のＩＤと位置情報（「ｓｉｇｎａｔｕｒｅｓ」）を情報として持つ。

帳票生成サーバ１０４は、オーバレイ処理開始時に、初期状態の出力ページ情報ファイル７００を生成する。この時、帳票は生成されていないため、「ｐａｇｅｓ」は要素が空であり、処理結果を示す「ｅｎｄ」の値はｆａｌｓｅである。この後、帳票生成サーバ１０４は順次処理を実行しオーバレイの実行結果を「ｐａｇｅｓ」に追加する。出力ページ情報ファイル７１０は、１ファイル目のオーバレイが完了した状態を示す。出力ページ情報ファイル７２０は、２ファイル目がオーバレイ完了した状態を示す。さらに、帳票生成サーバ１０４は、最後のページである３ファイル目のオーバレイ処理が完了した時点で、出力ページ情報ファイルを出力ページ情報ファイル７３０の状態に更新する。出力ページ情報ファイル７３０は、「ｐａｇｅｓ」に３ファイル目に対応する出力ページ情報が追加されているとともに、処理完了フラグ「ｅｎｄ」がｔｒｕｅに更新されている。

クライアント端末１０２は、出力ページ情報ファイルをストレージサーバ１０６から取得して参照することで、帳票テンプレートで定義された署名欄の入力位置を知ることができる。具体的には、出力ページ情報ファイル７３０に示される「ｓｉｇｎａｔｕｒｅｓ」の情報に基づいて、署名欄のＩＤおよび位置情報を取得することができる。

［画像情報ファイル］
次に、帳票生成サーバ１０４がクライアント端末１０２から帳票文書保存リクエスト受信時に生成する画像情報ファイルについて説明する。画像情報は、保存用の帳票文書を生成するために、クライアント端末１０２で保存されたユーザー入力の画像を挿入する際に利用する情報である。画像情報ファイルは、クライアント端末１０２のＷｅｂブラウザ３２１上で追記されたユーザー入力情報を画像化する際に取得できる位置情報等を持つ。本実施形態では、画像化したユーザー入力情報が帳票の何ページ目に追記されていたかを示すページ番号、帳票上のどの位置に追記されていたかの座標情報、および、変換された画像のファイル名の情報を保持する。

図８において、画像情報ファイル８００は、帳票生成サーバ１０４がクライアント端末１０２から帳票文書保存リクエスト受信時に生成する画像情報ファイルの例を示している。ｃｏｎｖｅｒｔＩｄ８０１は、クライアント端末１０２から受信した帳票保存リクエストに含まれるオーバレイＩＤを保持する。ｉｍａｇｅｓ８０２は、複数の画像情報ブロック８０３から構成される。画像情報ブロック８０３は、クライアント端末１０２のＷｅｂブラウザ３２１上で入力されたユーザー入力を画像化した画像についての情報をまとめたブロックである。クライアント端末１０２のＷｅｂブラウザ３２１上でユーザー入力が複数存在する場合、保存するユーザー入力の数だけ画像情報ブロック８０３を追記する。ｐａｇｅＮｏ８０４は、クライアント端末１０２のＷｅｂブラウザ上で追記されたユーザー入力が何ページ目の帳票に対して入力された情報であるか示す。座標情報８０５は、ユーザー入力が帳票上のどの位置に入力された情報であるか「ｌｅｆｔ」「ｔｏｐ」「ｗｉｄｔｈ」「ｈｅｉｇｈｔ」の値を保持する。ｆｉｌｅＮａｍｅ８０６は、クライアント端末１０２のＷｅｂブラウザ上で入力されたユーザー入力を画像化した画像データのアップロード先の情報を示す。

［処理フロー］
以降、本実施形態に係る各処理のフローについて説明する。

（オーバレイ処理）
図４は、本実施形態に係るクライアント端末１０２のＷｅｂブラウザ３２１が業務サーバ１０３に帳票プレビューリクエストを発行し、帳票生成サーバ１０４がオーバレイ出力処理を開始し、変換サーバ１０５へ変換リクエストを行うまでの流れを示す図である。本フローは、ユーザーがＷｅｂブラウザ３２１に表示した画面において帳票プレビュー要求操作を実行することによって開始される。併せて、クライアント端末１０２のＷｅｂブラウザ３２１にて表示される画面構成および画面遷移についても説明する。

ユーザーによりＷｅｂブラウザ３２１に表示された業務画面１０００の帳票プレビューボタン１０３０が押下されると、Ｓ４．１．１にて、Ｗｅｂブラウザ３２１は、顧客ＩＤと帳票情報１０２０で選択されている帳票情報の帳票ＩＤを含めて、帳票プレビューリクエストを業務サーバ１０３に送信する。

図１０は、クライアント端末１０２のＷｅｂブラウザ３２１から、業務サーバ１０３にアクセスして業務データを表示した場合の業務画面１０００の例である。業務画面１０００には、業務サーバ１０３が保持する顧客情報１０１０と帳票情報１０２０が表示されている。また、帳票情報１０２０は、帳票情報として登録されている帳票情報のうちのひとつを選択可能な帳票選択ドロップダウンリストである。帳票プレビューボタン１０３０は、帳票プレビュー要求操作を行うためのボタンである。

Ｓ４．１．２にて、業務サーバ１０３の業務情報管理部３３２は、Ｓ４．１．１にてクライアント端末１０２から受信した帳票プレビューリクエストに含まれる顧客ＩＤ、帳票ＩＤに該当する顧客情報、帳票テンプレートＩＤを指定して、帳票生成サーバ１０４に帳票生成リクエストを送信する。

Ｓ４．１．３にて、帳票生成サーバ１０４は、帳票生成リクエストを受信すると、帳票情報管理部３４２がオーバレイＩＤを発行して帳票データ情報に登録する。さらに、帳票生成サーバ１０４は、帳票生成リクエストに対する応答としてオーバレイＩＤを、業務サーバ１０３へ返す。

Ｓ４．１．４にて、業務サーバ１０３は、クライアント端末１０２のＷｅｂブラウザ３２１に対してオーバレイＩＤを返す。

また、帳票生成サーバ１０４の帳票情報管理部３４２は、Ｓ４．１．３と並行して、帳票生成リクエストに含まれる帳票テンプレートＩＤを基に帳票テンプレート情報から帳票テンプレートＵＲＬを取得する。そして、帳票情報管理部３４２は、取得した帳票テンプレートＵＲＬを用いて、顧客情報とともに、オーバレイ部３４３にオーバレイ出力指示を行う。オーバレイ部３４３は、オーバレイ出力指示を受けると、オーバレイインデックスファイル（インデックスファイル６００）と出力ページ情報ファイル７００を生成する。そして、オーバレイ部３４３は、生成したファイルを、ストレージサーバ１０６のライフサイクル管理領域にアップロードする（Ｓ４．２．１．１〜Ｓ４．２．１．２）。なお、ストレージサーバ１０６のライフサイクル管理領域は、予め規定され、その位置情報は、帳票生成サーバ１０４とストレージサーバ１０６間で共有されているものとする。

Ｓ４．２．２にて、オーバレイ部３４３は、Ｓ４．２．１．１でアップロードしたオーバレイインデックスファイル（インデックスファイル６００）のデータＵＲＬを含む変換リクエストを変換サーバ１０５に送信する。

Ｓ４．２．３にて、オーバレイ部３４３は、帳票テンプレートＵＲＬにアクセスしてフォーム情報ファイルを取得し、顧客情報と重ね合わせてオーバレイ処理を開始する。

Ｓ４．２．４．１にて、オーバレイ部３４３は、オーバレイ出力結果としてＰＤＦファイル（ＰＤＦ０１）を出力する。

Ｓ４．２．４．２にて、オーバレイ部３４３は、Ｓ４．２．４．１にて生成したＰＤＦファイル（ＰＤＦ０１）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

Ｓ４．２．４．３にて、オーバレイ部３４３は、Ｓ４．２．４．２にてアップロードしたＰＤＦファイル（ＰＤＦ０１）のデータＵＲＬを「ｄａｔａＬｉｓｔ」に追記したオーバレイインデックスファイル（インデックスファイル６１０）を、Ｓ４．２．１．１と同じデータＵＲＬにアップロードする。これにより、ストレージサーバ１０６のライフサイクル管理領域において、オーバレイインデックスファイルの内容が更新される。

Ｓ４．２．４．４にて、オーバレイ部３４３は、Ｓ４．２．４．１のオーバレイ実行時に取得できる出力ページ情報を、「ｐａｇｅｓ」に追記した出力ページ情報ファイル７１０を、Ｓ４．２．１．２と同じデータＵＲＬにアップロードする。これにより、ストレージサーバ１０６のライフサイクル管理領域において、出力ページ情報ファイルの内容が更新される。

続いて、オーバレイ部３４３は、次のオーバレイ処理（Ｓ４．２．５．１）の出力結果ＰＤＦ（ＰＤＦ０２）をストレージサーバ１０６のライフサイクル管理領域にアップロードする（Ｓ４．２．５．２）。さらに、オーバレイ部３４３は、Ｓ４．２．５．２にてアップロードしたＰＤＦファイル（ＰＤＦ０２）のデータＵＲＬを「ｄａｔａＬｉｓｔ」に追記したオーバレイインデックスファイル（インデックスファイル６２０）をアップロードする（Ｓ４．２．５．３）。同様に、オーバレイ部３４３は、オーバレイ実行時に取得できる情報を「ｐａｇｅｓ」に追記した出力ページ情報ファイル７２０をアップロードする（Ｓ４．２．５．４）。

Ｓ４．２．６．１にて、オーバレイ部３４３は、最後のページ単位のオーバレイ処理を行う。ここでは、３ページ目を最後のページとして説明する。Ｓ４．２．６．１にて、帳票生成サーバ１０４のオーバレイ部３４３は、オーバレイ出力結果としてＰＤＦファイル（ＰＤＦ０３）を出力する。

Ｓ４．２．６．２にて、オーバレイ部３４３は、Ｓ４．２．６．１にて生成したＰＤＦファイル（ＰＤＦ０３）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

さらに、Ｓ４．２．６．３にて、オーバレイ部３４３は、「ｄａｔａＬｉｓｔ」にＳ４．２．６．２にてアップロードしたＰＤＦファイル（ＰＤＦ０３）のデータＵＲＬを追加する。さらに、オーバレイ部３４３は、処理完了フラグ「ｅｎｄ」を、完了を表す値であるｔｒｕｅに更新する。そして、オーバレイ部３４３は、そのオーバレイインデックスファイル（インデックスファイル６３０）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

同様に、Ｓ４．２．６．４にて、帳票生成サーバ１０４のオーバレイ部３４３は、「ｐａｇｅｓ」にＳ４．２．６．１のオーバレイ時に取得した情報を追加する。さらに、オーバレイ部３４３は、処理完了フラグ「ｅｎｄ」を、完了を表す値であるｔｒｕｅに更新した出力ページ情報ファイル７３０をアップロードする。

本実施形態では、３ページから構成される帳票を例に挙げて説明したが、ページ数が更に多い場合や、オーバレイ出力単位が多い場合には、Ｓ４．２．５．１〜Ｓ４．２．５．４の処理が繰り返される。

一方、Ｓ４．２．２にて変換リクエストを受け付けた変換サーバ１０５は、変換情報管理部３５２で、変換ＩＤを発行して応答として帳票生成サーバ１０４へ返すとともに、受け取ったオーバレイインデックスファイルＵＲＬと合わせて変換情報として登録する。また、変換情報管理部３５２は、データ変換部３５３にオーバレイインデックスファイルＵＲＬを渡し、変換指示を行う。データ変換部３５３は、変換指示を受けると、初期状態の変換インデックスファイル（インデックスファイル６００）を生成してストレージサーバ１０６のライフサイクル管理領域にアップロードする（Ｓ４．３．１）。さらに、変換サーバ１０５は、そのデータＵＲＬを該当の変換情報に登録する。

帳票生成サーバ１０４は、Ｓ４．２．２の変換リクエストの応答として、変換サーバ１０５から返された変換ＩＤをキーとして、変換サーバ１０５に定期的に変換情報の取得を行う（Ｓ４．４．１）。ここでの取得間隔は特に限定するものではない。Ｓ４．４．１の応答で得られる変換情報の変換インデックスファイルＵＲＬに値が存在した場合、帳票生成サーバ１０４は、該当する帳票データ情報の変換インデックスファイルＵＲＬを更新し、Ｓ４．４．１における定期的な変換情報の取得処理を終了する。

一方、クライアント端末１０２のＷｅｂブラウザ３２１は、Ｓ４．１．４で業務サーバ１０３からオーバレイＩＤを受け取った後、そのオーバレイＩＤを指定して定期的に帳票生成サーバ１０４へ帳票データ情報の取得を行う（Ｓ４．５．１）。ここでの取得間隔は特に限定するものではない。Ｓ４．５．１の応答に出力ページ情報ファイルＵＲＬと変換インデックスファイルＵＲＬが含まれる場合、Ｗｅｂブラウザ３２１は、Ｓ４．５．１における定期的な帳票データ情報の取得処理を終了する。Ｗｅｂブラウザ３２１は、出力ページ情報ファイルＵＲＬ、変換インデックスファイルＵＲＬが取得できたタイミングでそれぞれのファイルの取得を開始する。この時、Ｗｅｂブラウザ３２１が取得する変換インデックスファイルの内容は、変換サーバ１０５で並列に行われている変換処理の進捗によって、図６に示したインデックスファイル６００〜６３０のいずれかの状態となる。

（データ変換処理）
図５は、本実施形態に係る変換サーバ１０５のデータ変換と、クライアント端末１０２がＷｅｂ帳票文書を取得して表示するまでのフローを示す図である。本フローにおける、変換サーバ１０５のデータ変換は、図４のＳ４．２．２において帳票生成サーバ１０４から変換リクエストを受信することによって開始される。本フローのクライアント端末１０２のＷｅｂ帳票文書表示フローは、Ｗｅｂブラウザ３２１がＳ４．５．１における定期的な帳票データ情報の取得処理を終了し、出力ページ情報ファイルと変換インデックスファイルの取得を開始することによって始まる。

変換サーバ１０５が図４のＳ４．２．２において帳票生成サーバ１０４から変換リクエストを受け付けると、変換サーバ１０５のデータ変換部３５３は、変換処理を開始する。

Ｓ５．１にて、データ変換部３５３は、帳票生成サーバ１０４から受信した変換リクエストにて指定されるオーバレイインデックスファイルＵＲＬにアクセスし、オーバレイインデックスファイルをダウンロードする。

Ｓ５．１．１．１にて、データ変換部３５３は、Ｓ５．１にてダウンロードしたオーバレイインデックスファイルを参照する。そして、「ｄａｔａＬｉｓｔ」にオーバレイ済みのデータＵＲＬが存在した場合（インデックスファイル６１０）、データ変換部３５３は、そのデータＵＲＬにアクセスし、ＰＤＦファイル（ＰＤＦ０１）を取得する。

次に、Ｓ５．１．１．２にて、データ変換部３５３は、Ｓ５．１．１．１にて取得したＰＤＦファイル（ＰＤＦ０１）をＷｅｂ帳票文書へ変換する。ここでは、ＰＤＦ形式からＳＶＧ形式に変換するものとする。

Ｓ５．１．１．３にて、データ変換部３５３は、Ｓ５．１．１．２にて生成したＷｅｂ帳票文書（ＳＶＧ０１）をストレージサーバ１０６のライフサイクル管理領域にアップロードする。

さらに、Ｓ５．１．１．４にて、データ変換部３５３は、アップロードしたＷｅｂ帳票文書（ＳＶＧ０１）のデータＵＲＬを変換インデックスファイルの「ｄａｔａＬｉｓｔ」に追記し、Ｓ４．３．１と同じデータＵＲＬにアップロードする。これにより、ストレージサーバ１０６のライフサイクル管理領域において、変換インデックスファイルの内容が更新される。

以降、データ変換部３５３は、定期的にオーバレイインデックスファイルＵＲＬにアクセスし、オーバレイインデックスファイルを確認する。そして、Ｓ５．１．２．１〜Ｓ５．１．２．４、Ｓ５．１．３．１〜Ｓ５．１．３．４の処理を順次実行する。

オーバレイインデックスファイルの処理完了フラグ「ｅｎｄ」がｔｒｕｅであった場合（インデックスファイル６３０）、データ変換部３５３は、「ｄａｔａＬｉｓｔ」に含まれるデータＵＲＬすべてに対しての変換処理が完了した際に（Ｓ５．１．３．４）、変換インデックスファイルの処理完了フラグ「ｅｎｄ」をｔｒｕｅに更新する。

一方、クライアント端末１０２のＷｅｂブラウザ３２１は、Ｓ４．５．１の応答で、帳票データ情報の出力ページ情報ファイルＵＲＬと変換インデックスファイルＵＲＬを取得後、変換インデックスファイルＵＲＬに定期的にアクセスする。そして、Ｗｅｂブラウザ３２１は、変換インデックスファイルをダウンロードする。Ｓ５．２．１にて「ｄａｔａＬｉｓｔ」にＵＲＬが存在した場合（インデックスファイル６１０、６２０、６３０）、Ｗｅｂブラウザ３２１は、そのデータＵＲＬからＷｅｂ帳票文書をダウンロードし、図１１に示すＷｅｂ帳票画面１１００に表示する。Ｗｅｂブラウザ３２１は、変換インデックスファイルの処理完了フラグ「ｅｎｄ」がｔｒｕｅとなった時点（インデックスファイル６３０）でＳ５．２．１の処理を終了する。

図１１は、Ｗｅｂブラウザ３２１に表示されるＷｅｂ帳票画面１１００の例である。Ｗｅｂ帳票画面１１００は、クライアント端末１０２のＷｅｂブラウザ３２１がＳ５．２．１、Ｓ５．２．１．１〜Ｓ５．２．１．３でＷｅｂ帳票文書を取得し、表示した画面である。Ｗｅｂ帳票文書１１２０は、Ｗｅｂブラウザ３２１が取得したＷｅｂ帳票文書を描画したものである。データ１１２１は、表示されているＷｅｂ帳票文書１１２０に対してユーザーが追記したデータであり、本実施形態では署名情報を例に挙げる。Ｗｅｂ帳票文書１１２０に対してユーザーが追記するデータは、Ｓ５．２．２で取得した出力ページ情報に定義された署名領域を選択することによりユーザー入力モードに遷移し、その状態においてユーザー入力を受け付けることで取得される。帳票文書上にて入力可能なユーザー入力としては、署名、チェックボックス、手書きメモ、ラインマーカーなどが挙げられる。しかし、ユーザー入力の種類は特に限定するものでは無く、業務内容に応じて入力可能なコンテンツが制御されてよい。入力されたユーザー入力は、ＳＶＧに変換してＤＯＭに追加する。ＤＯＭとはＤｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌであり、ＤＯＭに追加とはＨＴＭＬの要素に対し変換してデータをＳＶＧタグとして追加することを指す。なお、Ｗｅｂブラウザ上での入力、入力したデータのＳＶＧ形式の変換処理については公知であるため、説明は省略する。

ページ情報１１１０は、取得したＷｅｂ帳票文書のページ数と現在表示中のページ数を示し、Ｓ５．２．１．１〜Ｓ５．２．１．３の処理進捗に従って変化する。保存ボタン１１３０は、帳票生成サーバ１０４に対して帳票文書の保存要求を実行するためのボタンである。

図４と図５のフローは、夫々のインデックスファイルの状態と内容を起点としており、帳票生成サーバ１０４のオーバレイ処理、変換サーバ１０５のデータ変換処理、およびクライアント端末１０２のＷｅｂ帳票文書の表示は並列して動作することができる。以下、オーバレイ処理、変換処理、Ｗｅｂ帳票文書表示が並列動作について説明する。

帳票生成サーバ１０４は、オーバレイインデックスファイルをアップロード（図４のＳ４．２．１）した後、ＰＤＦ０１の処理が完了すると、Ｓ４．２．４．３でデータＵＲＬを追加（インデックスファイル６１０）する。続けて、帳票生成サーバ１０４は、ＰＤＦ０２に対する処理を開始する。

このタイミングで、Ｓ５．１で定期的にオーバレイインデックスファイルを確認している変換サーバ１０５は、ＰＤＦ０１のデータＵＲＬが追加されたことを検知する。そして、変換サーバ１０５は、ＰＤＦ０１をＳＶＧ０１へ変換する処理を開始する（Ｓ５．１．１．１〜Ｓ５．１．１．４）。また、変換サーバ１０５は、ＳＶＧ０１に対する処理が完了すると、Ｓ５．１．１．４にて変換インデックスファイルにＳＶＧ０１のデータＵＲＬを追加（インデックスファイル６１０）する。そして、変換サーバ１０５は、Ｓ５．１にてＰＤＦ０２のデータＵＲＬが追加されたことを検知するとＰＤＦ０２に対する処理を行う。

さらに、クライアント端末１０２は、Ｓ４．５．１の応答として得られた変換インデックスファイルＵＲＬに定期的にアクセスし、変換インデックスファイルを確認する（Ｓ５．２．１）。Ｓ４．５．１で変換インデックスファイルＵＲＬが応答されるのは、Ｓ４．３．１で変換サーバ１０５が変換インデックスファイルを生成し、Ｓ４．４．１の応答として帳票生成サーバ１０４がそれを受け取ったタイミング以降となる。

クライアント端末１０２は、変換インデックスファイルにＳＶＧ０１のデータＵＲＬが追加されたことを検知すると、Ｓ５．２．１．１でＳＶＧ０１を取得し、Ｗｅｂ帳票画面１１００に表示する。

また、帳票生成サーバ１０４は、ＰＤＦ０１に対する処理の後、ＰＤＦ０２、ＰＤＦ０３を継続して処理し、オーバレイインデックスファイルを更新する。

一方、変換サーバ１０５は、Ｓ５．１の確認を継続し、オーバレイインデックスファイルの更新を検知すると、ＳＶＧ０２、ＳＶＧ０３の変換処理を行い、変換インデックスファイルを更新する。

さらに、クライアント端末１０２は、Ｓ５．２．１の確認を継続し、変換インデックスファイルの更新を検知すると、内容に応じてＳＶＧ０２、ＳＶＧ０３のデータを取得し、Ｗｅｂ帳票画面１１００に表示する。

（帳票保存処理）
図９は、本実施形態に係るクライアント端末１０２のＷｅｂブラウザ３２１からの帳票保存処理要求と、帳票生成サーバ１０４の帳票保存処理のシーケンスを示す図である。本シーケンスは、ユーザーがＷｅｂ帳票画面１１００に表示される保存ボタン１１３０を押下することによって開始される。

Ｓ９０１にて、ユーザーにより保存ボタン１１３０が押下されると、クライアント端末１０２のＷｅｂブラウザ３２１は、ユーザー入力のデータの画像化を行う。例えば、クライアント端末１０２は、Ｗｅｂブラウザ３２１上で動作するＪａｖａｓｃｒｉｐｔプログラムを用いてＳＶＧ要素の一覧を取得する。クライアント端末１０２は、取得したＳＶＧ要素がユーザー入力か否かを判定し、ユーザー入力である場合、ＳＶＧ要素をＰＮＧ画像に変換する。ここで、ユーザー入力であるか否かの判定は、ＳＶＧ要素のｉｄ属性を基に判断する。ＳＶＧ要素の追加時にユーザー入力であることが識別できるｉｄとすることで実現可能である。

Ｓ９０２にて、クライアント端末１０２のＷｅｂブラウザ３２１は、帳票生成サーバ１０４に対して帳票保存リクエストを行う。このとき、クライアント端末１０２のＷｅｂブラウザ３２１は、Ｓ４．１．４で受け取ったオーバレイＩＤとＳ９０１で画像化したデータのページ番号、座標情報、画像ファイル名をリクエストに含める。

Ｓ９０３にて、帳票生成サーバ１０４の保存文書生成部３４４は、クライアント端末１０２から帳票保存リクエストを受信すると、当該リクエストに含まれるオーバレイＩＤとＳ９０１で画像化したデータの出力ページ番号、出力座標、画像ファイル名を取得する。

Ｓ９０４にて、保存文書生成部３４４は、画像アップロードＵＲＬを生成する。保存文書生成部３４４は、画像情報ファイルを生成し、ストレージサーバ１０６に保存する。さらに、保存文書生成部３４４は、帳票データ情報に画像情報ファイルＵＲＬを追加する。

Ｓ９０５にて、保存文書生成部３４４は、Ｓ９０４にて生成した画像アップロードＵＲＬをレスポンスに含め、クライアント端末１０２のＷｅｂブラウザ３２１に帳票保存リクエストに対する応答として返す。画像アップロードＵＲＬとは、クライアント端末１０２のＷｅｂブラウザ３２１が生成した画像ファイルをアップロードするためのＵＲＬである。ここでは、ストレージサーバ１０６の所定の格納場所が用いられるものとする。

Ｓ９０６にて、クライアント端末１０２のＷｅｂブラウザ３２１は、Ｓ９０１にて生成した画像ファイルを帳票生成サーバ１０４にて指定された画像アップロードＵＲＬに対して送信する。

Ｓ９０７にて、Ｗｅｂブラウザ３２１は、画像ファイルのアップロードが終了した後、帳票生成サーバ１０４に対して画像アップロード完了通知を行う。このとき、クライアント端末１０２のＷｅｂブラウザ３２１は、オーバレイＩＤを通知に含める。

Ｓ９０８にて、保存文書生成部３４４は、クライアント端末１０２から取得したオーバレイＩＤからオーバレイ処理を特定し、帳票データ情報からオーバレイインデックスファイルＵＲＬと画像情報ファイルＵＲＬを取得する。そして、保存文書生成部３４４は、取得したＵＲＬにアクセスしてオーバレイインデックスファイルと画像情報ファイルをダウンロードする。

次に、Ｓ９０９にて、保存文書生成部３４４は、Ｓ９０８にてダウンロードしたオーバレイインデックスファイルを参照し、「ｄａｔａＬｉｓｔ」に含まれる全てのデータＵＲＬにアクセスして全てのＰＤＦファイルを取得する。同様に、保存文書生成部３４４は、Ｓ９０８にてダウンロードした画像情報ファイルを参照し、「ｉｍａｇｅｓ」に含まれる全ての画像ファイルを取得する。

Ｓ９１０にて、保存文書生成部３４４は、画像ファイルとＰＤＦファイルの取得が全て成功したか否かを判定する。取得が成功したと判定された場合（Ｓ９１０にてＹＥＳ）Ｓ９１１へ進み、取得が失敗したと判定された場合（Ｓ９１０にてＮＯ）Ｓ９１４へ進む。

Ｓ９１１にて、保存文書生成部３４４は、Ｓ９０９にて取得したＰＤＦファイルをページ順に全て結合する。本実施形態では、ＰＤＦファイルを１ページ目から順に生成（Ｓ４．２．４．１、Ｓ４．２．５．１、Ｓ４．２．６．１）し、生成した各ＰＤＦファイルのファイル名にＰＤＦ０１、ＰＤＦ０２のようにシーケンシャルな番号を付与している。そのため、ＰＤＦファイルを結合する際は、ＰＤＦファイル名のシーケンシャルな番号をもとに１ページ目から順にファイルを結合する。なお、ページ順に結合する手段はこの方法に限定されるものではなく、例えば、オーバレイインデックスファイルにページ番号情報を記述する方法であってもよい。

Ｓ９１２にて、保存文書生成部３４４は、Ｓ９１１で結合されたＰＤＦに画像情報ファイルに記載された出力ページ番号、出力座標、画像ファイル名の情報を基に画像ファイルを挿入し、ユーザー入力を含めた保存用ＰＤＦファイルを生成する。

Ｓ９１３にて、保存文書生成部３４４は、Ｓ９１２にて生成した保存用ＰＤＦファイルをストレージサーバ１０６のライフサイクル管理領域に保存する。そして、Ｓ９１５へ進む。

Ｓ９１４にて、保存文書生成部３４４は、帳票保存処理にてエラーが発生したものとして、エラー終了する。そして、Ｓ９１５へ進む。

Ｓ９１５にて、保存文書生成部３４４は、帳票保存処理の結果をレスポンスに含め、クライアント端末１０２のＷｅｂブラウザ３２１に応答として返す。ここでの帳票保存処理の結果として、帳票保存処理の正常終了もしくはエラー終了のいずれかが返される。

Ｓ９１６にて、クライアント端末１０２のＷｅｂブラウザ３２１は、帳票生成サーバ１０４から受信した結果内容に応じて、保存完了画面（不図示）を表示する。帳票保存処理に失敗した場合はその旨を保存完了画面にメッセージとして表示する。そして、本処理フローを終了する。なお、ＰＤＦファイルを結合する処理、ＰＤＦファイルに画像を挿入する処理は公知であるため、説明は省略する。

本実施形態では、分割生成したＰＤＦファイル、ＳＶＧファイル、画像ファイル、および保存用ＰＤＦファイルを、ストレージサーバ１０６のライフサイクル管理領域にアップロードするため、これらファイルは一日経過すると削除される。しかしながら、各ファイルのライフサイクルはこれに限定されるものではない。例えば、保存用ＰＤＦファイルをストレージサーバ１０６により自動的に削除されないようにしてもよい。この場合、例えば、不図示の保存文書削除画面にてユーザーが削除指示操作を行い、クライアント端末１０２のＷｅｂブラウザ３２１が帳票生成サーバ１０４に保存文書削除リクエストを行う。これにより、帳票生成サーバ１０４がストレージサーバ１０６から該保存用ＰＤＦファイルを削除してよい。

以上、本実施形態によれば、クライアント端末１０２のＷｅｂブラウザ３２１が帳票生成サーバ１０４に文書保存リクエストを行う際に画像化したユーザー入力の情報（追記された帳票のページ番号、座標位置、画像ファイル名）を送る。これにより、テンプレート情報とユーザーに指定されるデータから動的に生成されるＷｅｂ帳票であっても、ユーザー入力を含めて電子文書として帳票を保存することができる。

＜第２の実施形態＞
クライアント端末１０２のＷｅｂブラウザ３２１上に追加入力される入力として、第１の実施形態では、署名情報を例に挙げて説明した。販売員による保険営業において、クライアント端末１０２として利用可能なタブレット上での入力は署名以外にも様々な入力が想定される。例えば、説明義務がある記載について販売員から説明を受けたか否かを示す、ユーザーがチェックするチェックボックスなどが挙げられる。他にも販売員が説明のポイントに着目してもらうためのラインマーカーや、ポイントをまとめた手書き入力などもある。これらの入力は、電子文書の保存時に全てを保存する必要はなく、保存目的に応じて何を保存できるか選択できることが望ましい。例えば、販売員が内部統制の為にＷｅｂ帳票を保存するのであれば顧客が入力した署名情報とチェックボックスの入力情報が保存できれば良い。一方、説明したＷｅｂ帳票を顧客に提供する為に電子文書を保存するのであれば、説明時に販売員が入力したラインマーカーや手書き入力の情報が保存できれば良い。

本実施形態について、図面を用いて説明する。なお、第１の実施形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

［画像変換処理］
図１２は、第２の実施形態に係るクライアント端末１０２のＷｅｂブラウザ３２１におけるユーザー入力の画像変換処理を示すフローチャートである。本フローはユーザーによりＷｅｂ帳票画面１１００の保存ボタン１１３０が押下されることによって開始される。

ユーザーにより保存ボタン１１３０が押下されると、Ｓ１２０１にて、クライアント端末１０２のＷｅｂブラウザ３２１は、保存コンテンツ選択画面１３０１を表示する。図１３は、Ｗｅｂブラウザ３２１に表示される保存コンテンツ選択画面１３０１の例である。保存対象コンテンツ一覧１３０２は、どのコンテンツタイプのユーザー入力を画像化し、帳票文書として保存するか選択可能として表示する一覧である。ここでは、チェックボックスにていずれのコンテンツを保存対象とするか否かを指定することができる。保存ボタン１３０３は、帳票生成サーバ１０４に対して帳票文書の保存要求を実行するためのボタンである。キャンセルボタン１３０４は、帳票生成サーバ１０４への保存要求を行わずにＷｅｂ帳票画面１１００へ戻るためのボタンである。なお、保存対象コンテンツ一覧１３０２には、ユーザーから追記されたコンテンツタイプのみを表示し、追記されていないコンテンツタイプについては表示しないような構成であってよい。

Ｓ１２０２にて、クライアント端末１０２は、Ｗｅｂブラウザ３２１上で動作するＪａｖａｓｃｒｉｐｔプログラムを用いてＳＶＧ要素の一覧を取得する。

Ｓ１２０３にて、クライアント端末１０２は、Ｓ１２０２で取得したＳＶＧ要素がＳ１２０１で保存コンテンツ選択画面１３０１にて指定された保存対象のコンテンツタイプであるか否かを判定する。例えば、ユーザー入力をＷｅｂ帳票上に追加する際にＳＶＧタグのｉｄ属性にコンテンツタイプを含めたｉｄとすることで取得したＳＶＧがどのコンテンツタイプであるか判定することができる。ここでは、Ｓ１２０２にて取得したＳＶＧに対して順に判定処理を行うものとする。保存対象であると判定された場合（Ｓ１２０３にてＹＥＳ）Ｓ１２０４へ進み、保存対象でないと判定された場合（Ｓ１２０３にてＮＯ）Ｓ１２０５へ進む。

Ｓ１２０４にて、クライアント端末１０２は、Ｓ１２０２にて取得したＳＶＧ要素をＰＮＧ画像に変換する。そして、Ｓ１２０５へ進む。

Ｓ１２０５にて、クライアント端末１０２は、Ｓ１２０２で取得したＳＶＧ要素のうち、未処理のＳＶＧ要素があるか否かを判定する。未処理のＳＶＧ要素がある場合（Ｓ１２０５にてＮＯ）Ｓ１２０３へ戻り、処理を繰り返す。Ｓ１２０２で取得した全てのＳＶＧ要素に対して処理が完了した場合（Ｓ１２０５のＹＥＳ）本処理フローを終了する。

以上、本実施形態では、クライアント端末１０２のＷｅｂブラウザ３２１上に追加入力された入力の種類に応じて電子文書として保存するか否かを選択する。これにより、第１の実施形態の効果に加え、電子文書の保存の目的に応じて必要なユーザー入力のみを含めた電子文書が保存可能となる。

＜第３の実施形態＞
上記実施形態で保存した電子文書を後日、印刷するようなユースケースが考えられる。上記実施形態でのユーザー入力の画像化の処理は、クライアント端末１０２で見ることを前提に保存を行っている。そのため、電子文書を印刷するサイズによっては、ユーザー入力の画像が劣化してしまう可能性がある。

そこで、本願発明の第３の実施形態では、オーバレイに利用する帳票テンプレートに定義されている印刷用紙サイズの情報を出力ページ情報ファイルに出力する。そして、ユーザー入力を画像化する際にＷｅｂ帳票の基となった帳票テンプレートの印刷用紙サイズの情報を踏まえて変換処理を行う。

本実施形態について図面を用いて説明する。なお、第１および第２の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

［画像変換処理］
図１４は、第３の実施形態に係るクライアント端末１０２のＷｅｂブラウザ３２１におけるユーザー入力の画像変換処理を示すフローチャートである。本フローはユーザーによりＷｅｂ帳票画面１１００の保存ボタン１１３０が押下されることによって開始される。

ユーザーにより保存ボタン１１３０が押下されると、Ｓ１４０１にて、クライアント端末１０２は、Ｗｅｂブラウザ３２１上で動作するＪａｖａｓｃｒｉｐｔプログラムを用いてＳＶＧ要素の一覧を取得する。そして、クライアント端末１０２は、各ＳＶＧ要素が保存対象であるか否かを、ＳＶＧタグのｉｄ属性を基に判定する。ユーザー入力である情報を含めたｉｄとすることで取得したＳＶＧを画像化すべきか否かを判定することができる。このとき、第２の実施形態の構成のように、ユーザーにより、保存対象の指定を受け付けてもよい。

Ｓ１４０２にて、クライアント端末１０２は、Ｓ５．２．２で取得した出力ページ情報からＳＶＧ要素が存在するページで定義される用紙サイズ情報を取得する。図１５は、本実施形態における出力ページ情報ファイルの一例を示す。本実施形態では、オーバレイ実行時に、使用した帳票テンプレートで定義されている用紙サイズを取得し、出力ページ情報ファイルに「ｐａｐｅｒＳｉｚｅ」をキーとした情報１５０１を含む。

Ｓ１４０３にて、クライアント端末１０２は、Ｓ１４０２で取得した用紙サイズを基に、保存対象のコンテンツ（ＳＶＧ要素）の画像サイズを計算する。本実施形態では、Ｓ１４０２で取得した用紙サイズはｍｍで定義されているものとして説明する。一方、Ｗｅｂブラウザ３２１上に追記されたユーザー入力は、パーセント指定で座標位置を保持しているため、画像サイズのピクセル変換が行われる。クライアント端末１０２は、これらの情報に基づいて、画像サイズを決定する。

Ｓ１４０４にて、クライアント端末１０２は、Ｓ１４０１で取得したＳＶＧ要素をＳ１４０３で算出したサイズでＰＮＧ画像に変換する。例えば、クライアント端末１０２は、取得したＳＶＧ要素をｃａｎｖａｓに描画し、ｃａｎｖａｓの画像をＰＮＧファイルとして保存する。ここで、ＳＶＧ要素を描画するｃａｎｖａｓを定義する際に、Ｓ１４０３で取得したサイズが利用される。そして、本処理フローを終了する。

以上、本実施形態では、ユーザー入力を追記するＷｅｂ帳票作成に用いた帳票テンプレートに定義された印刷用紙サイズの情報を基にユーザー入力を画像化する。これにより、第１の実施形態の効果に加え、ユーザー入力が追記された電子文書を印刷してもユーザー入力が劣化せずに印刷可能となる。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０２…クライアント端末、１０３…業務サーバ、１０４…帳票生成サーバ、１０５…変換サーバ、１０６…ストレージサーバ

Claims (13)

1. Ｗｅｂブラウザを備えるクライアント端末と、前記Ｗｅｂブラウザにて閲覧可能な帳票文書を生成するサーバとを含んで構成される帳票文書生成システムであって、
   前記クライアント端末は、
   前記Ｗｅｂブラウザにて表示されている帳票文書上におけるユーザー入力を受け付ける受け付け手段と、
   前記ユーザー入力を受け付けた帳票文書の保存要求を前記サーバに送信する送信手段と、
   前記受け付け手段にて受け付けたユーザー入力を画像化して画像データを生成する画像化手段と、
   前記画像化手段にて生成した画像データと、前記帳票文書上における前記ユーザー入力の位置情報とを所定の格納場所に格納する格納手段と
   を有し、
   前記サーバは、
   前記クライアント端末から前記保存要求を受信した際に、前記所定の格納場所を示す情報を発行し、前記クライアント端末に通知する通知手段と、
   前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成する生成手段と、
   前記生成手段にて生成された新たな帳票文書を保存する保存手段と
   を有することを特徴とする帳票文書生成システム。
2. 前記ユーザー入力の位置情報は、帳票文書上における、座標、サイズ、および、ページ番号を含むことを特徴とする請求項１に記載の帳票文書生成システム。
3. 前記受け付け手段は、帳票文書上におけるユーザー入力として、複数の種類のコンテンツを受け付け可能であることを特徴とする請求項１または２に記載の帳票文書生成システム。
4. 前記ユーザー入力としての複数の種類のコンテンツは、署名、チェックボックス、手書きメモ、およびラインマーカーの少なくともいずれかを含むことを特徴とする請求項３に記載の帳票文書生成システム。
5. 前記クライアント端末は、前記複数の種類のコンテンツのうち、前記新たな帳票文書を生成する際に用いるコンテンツの指定を受け付ける指定手段を更に有することを特徴とする請求項３または４に記載の帳票文書生成システム。
6. 前記サーバは、帳票文書に対応付けて当該帳票文書を印刷する際の用紙サイズの情報を保持する保持手段を更に有し、
   前記クライアント端末は、前記ユーザー入力を受け付けた帳票文書に対応する用紙サイズの情報を取得する取得手段を更に有し、
   前記画像化手段は、前記取得手段にて取得した用紙サイズの情報に基づいて、前記受け付け手段にて受け付けたユーザー入力を画像化する際のサイズを決定することを特徴とする請求項１乃至５のいずれか一項に記載の帳票文書生成システム。
7. 前記所定の格納場所を示す情報は、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）であることを特徴とする請求項１乃至６のいずれか一項に記載の帳票文書生成システム。
8. 前記生成手段にて生成された新たな帳票文書を、異なるファイル形式に変換する変換手段を更に有することを特徴とする請求項１乃至７のいずれか一項に記載の帳票文書生成システム。
9. 前記生成手段は、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）形式にて新たな帳票文書を生成し、
   前記変換手段は、前記生成手段にて生成された新たな帳票文書をＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）形式に変換することを特徴とする請求項８に記載の帳票文書生成システム。
10. Ｗｅｂブラウザを備えるクライアント端末と、前記Ｗｅｂブラウザにて閲覧可能な帳票文書を生成するサーバとを含んで構成される帳票文書生成システムにおける帳票文書生成方法であって、
    前記クライアント端末において、前記Ｗｅｂブラウザにて表示されている帳票文書上におけるユーザー入力を受け付ける受け付け工程と、
    前記クライアント端末において、前記ユーザー入力を受け付けた帳票文書の保存要求を前記サーバに送信する送信工程と、
    前記サーバにおいて、前記クライアント端末から前記保存要求を受信した際に、所定の格納場所を示す情報を発行し、前記クライアント端末に通知する通知工程と、
    前記クライアント端末において、前記受け付け工程にて受け付けたユーザー入力を画像化して画像データを生成する画像化工程と、
    前記クライアント端末において、前記画像化工程にて生成した画像データと、前記帳票文書上における前記ユーザー入力の位置情報とを前記通知工程にて通知された前記所定の格納場所に格納する格納工程と
    前記サーバにおいて、前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成する生成工程と、
    前記サーバにおいて、前記生成工程にて生成された新たな帳票文書を保存する保存工程と
    を有することを特徴とする帳票文書生成方法。
11. クライアント端末が備えるＷｅｂブラウザにて閲覧可能な帳票文書を生成するサーバであって、
    前記クライアント端末から、前記Ｗｅｂブラウザ上でユーザー入力が行われた帳票文書の保存要求を受信した際に、所定の格納場所を示す情報を発行し、前記クライアント端末に通知する通知手段と、
    前記クライアント端末により前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成する生成手段と、
    前記生成手段にて生成された新たな帳票文書を保存する保存手段と
    を有し、
    前記所定の格納場所には、前記ユーザー入力を画像化して生成された画像データと、前記帳票文書上における前記ユーザー入力の位置情報とが格納されることを特徴とするサーバ。
12. クライアント端末が備えるＷｅｂブラウザにて閲覧可能な帳票文書を生成するサーバの制御方法であって、
    前記クライアント端末から、前記Ｗｅｂブラウザ上でユーザー入力が行われた帳票文書の保存要求を受信した際に、所定の格納場所を示す情報を発行し、前記クライアント端末に通知する通知工程と、
    前記クライアント端末により前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成する生成工程と、
    前記生成工程にて生成された新たな帳票文書を保存する保存工程と
    を有し、
    前記所定の格納場所には、前記ユーザー入力を画像化して生成された画像データと、前記帳票文書上における前記ユーザー入力の位置情報とが格納されることを特徴とする制御方法。
13. コンピューターを、
    Ｗｅｂブラウザを備えるクライアント端末から、前記Ｗｅｂブラウザ上でユーザー入力が行われた帳票文書の保存要求を受信した際に、所定の格納場所を示す情報を発行し、前記クライアント端末に通知する通知手段、
    前記クライアント端末により前記所定の格納場所に格納された情報と、前記帳票文書とを用いて、新たな帳票文書を生成する生成手段
    前記生成手段にて生成された新たな帳票文書を保存する保存手段
    として機能させ、
    前記所定の格納場所には、前記ユーザー入力を画像化して生成された画像データと、前記帳票文書上における前記ユーザー入力の位置情報とが格納されることを特徴とするプログラム。

Images