JP2004213075A - Business form issuing apparatus, and electronic business form system using the same - Google Patents

Business form issuing apparatus, and electronic business form system using the same Download PDF

Info

Publication number
JP2004213075A
JP2004213075A JP2002378319A JP2002378319A JP2004213075A JP 2004213075 A JP2004213075 A JP 2004213075A JP 2002378319 A JP2002378319 A JP 2002378319A JP 2002378319 A JP2002378319 A JP 2002378319A JP 2004213075 A JP2004213075 A JP 2004213075A
Authority
JP
Japan
Prior art keywords
file
data
xrt
server
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002378319A
Other languages
Japanese (ja)
Inventor
Hiroaki Naokawa
裕昭 直川
Kiyotaka Shimoide
清孝 霜出
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kyocera Document Solutions Inc
Original Assignee
Kyocera Mita Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kyocera Mita Corp filed Critical Kyocera Mita Corp
Priority to JP2002378319A priority Critical patent/JP2004213075A/en
Publication of JP2004213075A publication Critical patent/JP2004213075A/en
Pending legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To provide a business form issuing apparatus which can reduce the storage capacity of a business form and facilitate the management of multiple kinds of business forms, and to provide an electronic business form system which uses it. <P>SOLUTION: An XRT file 124 which is a business form file, a component XRT file 126, which is components data of the business form, and an external resource file 127 are stored in a storage device 115 as separate files. These are combined, and the business form data are created. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
この発明は、領収書、請求書、在庫管理表、生命保険の提案書、チケットその他の有価証券などに代表される各種の帳票を発行するための帳票発行装置およびそれを用いた電子帳票システムに関する。
【０００２】
【従来の技術】
インターネット上に置かれたサーバに、複雑な背景画像、罫線、文字およびイメージ等からなる固定的な帳票フォームデータを蓄積しておくとともに、帳票フォームデータ上に設定されたフィールドに取り込むべきユーザデータを特定するための情報を、インターネットに接続されたパーソナルコンピュータから上記サーバに送信する構成の電子帳票システムが提案されている（たとえば特許文献１）。サーバでは、帳票フォームのフィールドにユーザデータを取り込んでオーバレイすることにより帳票のイメージデータが作成され、この帳票イメージデータがインターネットを介して上記パーソナルコンピュータへと送信されるようになっている。パーソナルコンピュータのユーザは、受信した帳票イメージデータを、プリンタで印刷することによって、所望の帳票を得ることができる。
【０００３】
【特許文献１】
特開２００２−１６３５９６号公報
【０００４】
【発明が解決しようとする課題】
帳票フォームは、必要とされる帳票ごとにページ単位で作成されており、サーバでは、それぞれの帳票フォームに対応したユーザデータを埋め込んで、帳票イメージデータを作成する。
【０００５】
サーバには、一般に、複数種類の帳票に対応した複数の帳票フォームファイルが記憶装置に記憶されている。たとえば１つの企業が顧客のためなどに発行する複数種類の帳票には、社名部分、社章部分、会社のロゴ部分などのように、複数種類の帳票に共通な領域が存在している。しかし、帳票フォームはページ単位で作成されるため、共通部分についても、それぞれの帳票フォームごとにデータが作成され、記憶装置に記憶されている。これにより記憶装置の記憶容量が圧迫されるという問題がある。
【０００６】
また、社章や社名の変更などのように複数種類の帳票フォームに共通の部分に対して共通の変更を施すべきときには、複数種類の帳票のフォームファイルに対して個々に編集作業を漏れなく行わなければならず、作業効率が非常に悪く、かつ変更が漏れなく行われているかどうかを管理することも困難であった。
【０００７】
そこで、この発明の目的は、帳票フォームの記憶容量を削減することができ、また複数種類の帳票フォームの管理が容易になる帳票発行装置およびこれを用いた電子帳票システムを提供することである。
【０００８】
【課題を解決するための手段および発明の効果】
上記の目的を達成するための請求項１記載の発明は、複数種類の帳票フォームデータ（１２４）を記憶する帳票フォームデータ記憶手段（１１５，１２００）と、複数種類の帳票フォームデータ内に共通に設定された部品配置領域（エリア領域またはイメージ領域）にリンクされた部品データ（１２６，１２７）を記憶する部品データ記憶手段（１１５，１２００）と、帳票の種類を指定した帳票データ要求を受け付ける帳票データ要求受付手段（１１７，１３１）と、この帳票データ要求受付手段によって受け付けられた帳票データ要求に対応する帳票フォームデータを上記帳票フォームデータ記憶手段から読み出し、かつ、この読み出された帳票フォームデータ内に設定された部品配置領域にリンクされた部品データを上記部品データ記憶手段から読み出し、これらの帳票フォームデータおよび部品データを結合して帳票データを生成する帳票データ生成手段（１３１，１３２）とを含むことを特徴とする帳票発行装置である。なお、括弧内の英数字は後述の実施形態における対応構成要素等を表す。以下、この項において同じ。
【０００９】
この構成によれば、複数種類の帳票フォームデータ内に共通に設定された部品配置領域に部品データ記憶手段に記憶された部品データがリンクされている。帳票の種類を指定した帳票データ要求が受け付けられると、帳票フォームデータとその帳票フォームデータ内に設定された部品配置領域にリンクされた部品データとが結合されることにより、帳票データが生成される。したがって、この帳票データに基づいて用紙上に印刷出力を行えば、所望の帳票を得ることができる。
【００１０】
部品データを帳票フォームデータとは別に記憶しておくことによって、複数種類の帳票フォームデータに共通に使用される部品データの分だけ記憶容量を削減することができる。また、部品データに対して必要な編集を行えば、実質的に複数種類の帳票フォームを一括して編集したことになり、いずれかのフォームについての変更漏れなどが生じることがない。これにより、帳票フォームの管理が容易になる。
【００１１】
さらに、個々の帳票フォームデータの作成の際に、共通部分を個々に作成する必要がないので、帳票フォームデータの作成も容易になる。
【００１２】
請求項２記載の発明は、上記部品データ記憶手段は、部品データにリンクされた部品配置領域が設定された部品フォームデータ（１２６）を上記帳票フォームデータのための部品データとして記憶していることを特徴とする請求項１記載の帳票発行装置である。
【００１３】
この構成により、たとえば、イメージデータ、テキストデータ、ユーザデータ（ユーザの要求に応じて個々の帳票毎に変化するデータ）が埋め込まれるフィールドなど複数種類の部品を任意に組み合わせたような複雑な形態の部品データを部品フォームとして保存しておき、このような部品フォームを帳票フォームデータと組み合わせることができる。これにより、種々の形式の部品を部品フォームデータとして帳票フォームデータから分離して記憶しかつ管理することができる。
【００１４】
むろん、部品データは、イメージデータやテキストデータなどの単一形式のデータからなるものであってもよい。
【００１５】
請求項３記載の発明は、上記帳票発行装置は、ネットワークに接続されたサーバ（１０）であり、上記帳票データ要求受付手段は、上記ネットワークに接続されたクライアント（２０）から送られてくる帳票データ要求を受信する手段（１１７）を含み、上記帳票発行装置は、さらに、上記帳票データを上記ネットワークを介して上記クライアントに送出する手段（１１７）を含むことを特徴とする請求項１または２記載の帳票発行装置である。
【００１６】
また、請求項４記載の発明は、請求項３記載の帳票発行装置と、上記ネットワークに接続され、上記帳票データ要求を当該ネットワークを介して上記帳票発行装置に送信する手段（２２１）、および上記帳票発行装置から上記ネットワークを介して送られてくる上記帳票データを受信する手段（２１１）を有するクライアント（２０）とを含むことを特徴とする電子帳票システムである。
【００１７】
これらの構成によれば、クライアントからネットワークを介してサーバに帳票データを要求することにより、当該サーバである帳票発行装置からクライアントへと帳票データが送られ、クライアントに接続されたプリンタから出力される。帳票データは、サーバにおいて一括管理されている帳票フォームデータおよびこれにリンクされた部品データを有しているから、いずれのクライアントにおいても、統一された形式の帳票を発行できる。
【００１８】
なお、請求項１または２の発明は、ネットワークに接続されていない独立した帳票発行装置として用いることもできる。この場合、たとえば、帳票データ生成手段によって生成された帳票データに基づいて印刷データが作成されて、印刷装置に与えられることによって、帳票を作成することができる。
【００１９】
【発明の実施の形態】
以下では、この発明の実施の形態を、添付図面を参照して詳細に説明する。
目次
１．電子帳票システムの全体構成
２．サーバの構成
２−１．サーバのハードウェア構成
２−２．帳票データ作成のために使用されるファイル等
２−３．サーバの機能的構成
３．クライアントの構成
３−１．クライアントのハードウェア構成
３−２．クライアントの機能的構成
４．電子帳票システム全体の動作
５．帳票データファイル（ＸＲＦファイル）の説明
６．帳票画像の生成
７．部品ＸＲＴファイルの使用態様
８．ＸＲＦリーダの動作
９．部品ＸＲＴファイルの作成
１０．ユーザデータに応じた外観の変更
１０−１．ユーザデータに応じた画像部品の選択
１０−２．ユーザデータに応じた描画オブジェクトの特性変更
１１．帳票フォームの構成要素ファイルのキャッシュが可能な実施形態
１２．クライアントにおける描画オブジェクトの特性変更
１３．ユーザの認証が可能な実施形態
１４．その他の実施形態
１．電子帳票システムの全体構成
図１は、この発明の一実施形態に係る電子帳票システムの全体構成を示すブロック図である。この電子帳票システムは、たとえば、各地に多くの事業所（支所や営業所等）が設置されている会社等の事業体において、業務上使用する帳票（社内で使用したり、顧客や取引先に渡したりするものなど）を統括的に管理するようにしたシステムである。
【００２０】
この帳票システムは、インターネット、社内のイントラネット、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）などのネットワーク（以下、代表してインターネットの場合について説明するが、他の形態のネットワークの場合も同様である。）に接続されたサーバ１０と、同じくインターネットに接続された複数のクライアント２０とを含む。サーバ１０は、大規模な処理を行うことのできるコンピュータであって、インターネットと通信可能に接続されている。クライアント２０は、各事業所に設置されているパーソナルコンピュータであって、インターネットと通信可能に接続されている。したがって、サーバ１０とクライアント２０とは、インターネットを利用することによって、互いにデータの送受信を行うことができる。クライアント２０には、帳票の印刷を行うためのプリンタ３０が接続されている。クライアント２０とプリンタ３０とは、プリンタケーブルを介して接続されていてもよいし、ローカルエリアネットワークを介して接続され、このローカルエリアネットワークに接続された複数のクライアント２０によってプリンタ３０が共有されるようになっていてもよい。
【００２１】
たとえば、保険会社の場合を例にとると、業務上必要な帳票は、２０００〜３０００種類であるといわれている。各事業所において、それらの帳票を個別に管理し、かつ、事業所間で統一を図るには相当の労力を要する。そこで、この電子帳票システムでは、サーバ１０が全ての帳票フォームを管理し、クライアント２０からの要求に応じて、帳票データを提供するようになっている。
【００２２】
各事業所で帳票が必要となった場合、ユーザはクライアント２０を操作することによって、必要としている帳票の種類およびそれに記入すべき事項を指定した帳票データ要求を、インターネットを介してサーバ１０へと送信することができる（矢印Ａ１）。クライアント２０は、サーバ１０から送信された帳票データ要求に基づいて、ユーザの必要としている帳票の帳票データを作成し、それをインターネットを介してクライアント２０へと返信する（矢印Ａ２）。帳票データを受け取ったクライアント２０は、この帳票データを印刷用データに展開し、プリンタ３０で印刷することができる。こうして、ユーザは所望の帳票を入手することになる。
【００２３】
この電子帳票システムによって、各事業所は、帳票の管理作業（更新など）から解放されるとともに、個々のクライアント２０を利用することで、所望の帳票を容易に作成できる。さらに、クライアント２０からサーバ１０にアクセスすることによって、会社全体の帳票の使用状況を詳細に把握できるようにすることも可能なので、クライアント２０を利用することによって、その会社全体の営業状況や財務状況等を把握可能とすることもできる。
1. ２．サーバの構成
２−１．サーバのハードウェア構成
図２は、サーバ１０の電気的な構成を示すブロック図である。サーバ１０には、ＣＰＵ１１０、ＲＯＭ１１１、ＲＡＭ１１２、入力装置１１３、表示装置１１４、記憶装置１１５および通信制御装置１１８が備えられており、これらはバス１１６で互いに接続されている。ＣＰＵ１１０は、ＲＯＭ１１１に格納されているプログラムに基づいて、ＲＯＭ１１１、ＲＡＭ１１２、入力装置１１３、表示装置１１４および記憶装置１１５の相互間でのデータの送受を制御したり、入力装置１１３、表示装置１１４、記憶装置１１５および通信制御装置１１８の制御を行ったりしており、通信制御装置１１８を介してインターネットとの間の接続を制御するようになっている。
【００２４】
サーバ１０は大規模で複雑な処理を行う場合があるので、高性能であるＣＰＵ１１０を用いることが望ましい。また、ＣＰＵ１１０の代わりに、ＭＰＵ（microprocessor）を用いた構成であってもよい。
【００２５】
入力装置１１３は、キーボードやポインティングデバイス等からなり、その操作信号はＣＰＵ１１０に与えられるようになっている。表示装置１１４は、ＣＲＴや液晶表示パネルのような二次元画像表示の可能なものであり、ＣＰＵ１１０からの表示信号に応じた画像表示を行う。
【００２６】
記憶装置１１５は、ハードディスク装置等から構成されており、サーバ１０にとって必要なデータやアプリケーションプログラムを記憶しておく記憶媒体として使用される。ＣＰＵ１１０は、必要に応じて、データを記憶装置１１５に記憶させたり、記憶装置１１５に記憶されているデータを読み取って使用したりすることができるようになっている。
２−２．帳票データ作成のために使用されるファイル等
図３は、記憶装置１１５に記憶されているファイルを説明するためのブロック図である。記憶装置１１５は、ＸＭＬ（Extensible Markup Language）ファイルの解析を行うためのＸＭＬパーサ１２０と、ＸＭＬファイルとＸＭＬアプリケーションのデータのやり取りを制御するＤＯＭ（Document Object Model）ファイルまたはＳＡＸ（Simple API for XML）ファイル１２１とを記憶している。サーバ１０上で動作するＸＭＬアプリケーションプログラムもこの記憶装置１１５に記録されていて、ＣＰＵ１１０によって読み取られて実行されるが、図３では図示を省略してある。
【００２７】
記憶装置１１５は、さらに、顧客等の個人データであるユーザデータを保管管理しているユーザデータベース１２８、帳票フォームの固定画部分（背景、レイアウト、イメージ、描画オブジェクト、テキスト、バーコード等）を規定する独自形式ファイルであるＸＲＴファイル１２４と、帳票フォーム中にエリアを指定して組み込み可能な同様の固定画部分を規定する独自形式ファイルである部品ＸＲＴファイル１２６と、帳票フォーム中に組み込み可能な外部リソースファイル１２７（イメージデータ）と、ＸＲＴファイルまたは部品ＸＲＴファイル中に設定されたフィールドの数、順序およびデータ型等を表すフィールド情報１２５と、フィールドとユーザデータとを対応付けるＤＴＤ（Document Type Definition）ファイル１２３とを記憶しており、これらを構成要素として、帳票データファイルとしてのＸＲＦファイルが作成される。
【００２８】
ＸＲＦファイルは、独自形式のファイルであり、帳票フォームとユーザデータとを合成したイメージデータ（ビットマップデータやＰＤＦファイルなど）ではなく、帳票を構成する構成要素データ等を一纏めにして格納したファイルである。このＸＲＦファイルに基づき、クライアント２０において、帳票フォームおよびユーザデータを合成した表示用および印刷用のイメージデータが作成されることになる。したがって、この電子帳票システムでは、サーバ１０から、ＸＲＦファイル形式で、帳票データがクライアント２０に送信されるから、イメージデータ形式の帳票データを送信する場合に比較してファイル容量が格段に小さく、さらに、圧縮処理を行えば、ファイル容量をさらに小さくできる。これにより、ネットワークのトラフィックを低減できる。
【００２９】
ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６および外部リソースファイル１２７は、作図アプリケーション等を用いて予め作成され、記憶装置１１５にそれぞれ複数種類記憶されている。ユーザデータ１２８も記憶装置１１５に予め記憶されている。また、ＸＲＴファイル１２４とフィールド情報１２５とは、一対一に対応付けられて記憶されている。外部リソースファイル１２７は、図形や写真等がスキャナ装置等に光学的に読み取られることによって作成されたイメージデータファイルである。部品ＸＲＴファイル１２６は、ＸＲＴファイル内に埋め込まれるエリアを構成する別のＸＲＴファイルであり、ＸＲＴファイルに配置可能な構成要素からなる。この部品ＸＲＴファイル１２６は、複数のＸＲＴファイルに共通して用いる部分のみをエリアを指定して登録し、複数の帳票で共有して用いるファイルである。部品ＸＲＴファイル内にエリアを指定して、別の部品ＸＲＴファイルを埋め込むこともできる。
【００３０】
ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６、外部リソースファイル１２７およびユーザデータ１２８は、帳票データファイルとしてのＸＲＦファイルのいわば構成部品であり、これらのファイルまたはデータ群は、記憶装置１１５の所定の記憶領域に記憶されて、部品サーバ１２００を構成している。ＸＲＦファイルの構成要素のうち、ユーザデータ１２８以外のものが、帳票フォームの構成要素である。
２−３．サーバの機能的構成
図４は、サーバ１０の機能的な構成を説明するためのブロック図である。サーバ１０には、ＣＰＵ１１０がＲＯＭ１１１や記憶装置１１５に記憶されているプログラムを実行することによって実現される複数の機能処理部が実質的に備えられている。より具体的には、サーバ１０は、制御部１３０と、この制御部１３０によって制御されるアプリケーションサーバ１１７とを備えている。アプリケーションサーバ１１７は、サーバ１０とクライアント２０との間で行われる送受信の制御を行うアプリケーションプログラムによって実現され、ユーザからの要求を受け付けて業務システムの処理に橋渡しする機能と、Ｗｅｂサーバ（ＨＴＴＰサーバ）としての機能を併せ持つ。
【００３１】
アプリケーションサーバ１１７は、ＨＴＭＬ（Hyper Text Markup Language）等で記述されたファイル（図示せず）を有している。このファイルは、サーバ１０とクライアント２０とのインターネットを介する接続が確立されると、アプリケーションサーバ１１７からクライアント２０へと送信される。アプリケーションサーバ１１７は、そのファイルに応答してクライアント２０が送出する帳票データ要求を受信することができるようになっている。受信された帳票データ要求は、制御部１３０に与えられる。
【００３２】
サーバ１０には、さらに、要求データ解析部１３１と、データ収集・結合処理部１３２とが設けられており、これらは、制御部１３０によって制御されている。要求データ解析部１３１は、サーバ１０にインストールされてビジネスロジックを実行する業務アプリケーションによって実現される機能処理部であり、クライアント２０から与えられる帳票データ要求（帳票の種類およびユーザデータを特定する情報を含む。）を解析し、その帳票データ要求に対応した帳票データファイル（ＸＲＦファイル）の部品（構成要素データ）である、ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６、外部リソースファイル１２７およびユーザデータ１２８を特定する。また、要求データ解析部１３１は、帳票データ要求に対応する帳票データを作成するための情報（パラメータやコマンドを含む。）をＸＭＬで記述したＸＭＬファイルである帳票生成情報ファイルを自動作成する。
【００３３】
この帳票生成情報ファイルには、帳票データ要求の解析によって特定された帳票データファイル部品（ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６、外部リソースファイル１２７およびユーザデータ１２８）のファイル情報も含まれている。さらに、要求データ解析部１３１は、帳票データ要求に含まれる情報によって特定されたユーザデータをＸＭＬファイルまたはＣＳＶ（Comma Separated Value）ファイルの形式のユーザデータファイルに変換することができる。
【００３４】
データ収集・結合処理部１３２には、ＸＭＬアプリケーション１３３が含まれている。ＸＭＬアプリケーション１３３は、ＸＭＬファイルに記述された内容を解釈して実行することのできるアプリケーションプログラム、たとえばＪａｖａ（登録商標）であり、サーバ１０に予めインストールされて、実行可能となっている。したがって、データ収集・結合処理部１３２にＸＭＬファイルである帳票生成情報ファイルが与えられると、ＸＭＬアプリケーション１３３が、これを解釈して実行する。
【００３５】
ＸＭＬアプリケーション１３３は、要求データ解析部１３１が生成する帳票生成情報ファイルに基づいて帳票データファイルとしてのＸＲＦファイルを作成するＸＲＦファイル作成部１３４と、同じく帳票データファイルとしてのＰＤＦファイルを作成するＰＤＦ（Portable Document Format）ファイル作成部１３５とを有している。
【００３６】
ＸＲＦファイル作成部１３４は、要求データ解析部１３１が生成する帳票生成情報ファイル中の帳票データファイル部品（ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６、外部リソースファイル１２７およびユーザデータ１２８）についてのファイル情報を参照し、これらのファイルを記憶装置１１５内の部品サーバ１２００から読み取る。そして、ＸＲＦファイル作成部１３４は、これらの読み取ったファイルを結合して、帳票データファイルとしてのＸＲＦファイルを作成する。データ収集・結合処理部１３２は、さらに、このＸＲＦファイルをアプリケーションサーバ１１７へと受け渡す。
【００３７】
同様に、ＰＤＦファイル作成部１３４は、要求データ解析部１３１が生成する帳票生成情報ファイル中の帳票データファイル部品（ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６、外部リソースファイル１２７およびユーザデータ１２８）についてのファイル情報を参照し、これらのファイルを記憶装置１１５内の部品サーバ１２００から読み取る。そして、ＰＤＦファイル作成部１３５は、これらの読み取ったファイルを結合し、イメージデータに展開してＰＤＦファイルを作成し、アプリケーションサーバ１１７へと受け渡す。
【００３８】
したがって、サーバ１０に帳票データ要求が与えられると、要求データ解析部１３１によって、帳票データ要求に対応する帳票データを作成するための情報（パラメータ、コマンドなど）がＸＭＬで記述された帳票生成情報ファイルが作成される。そして、ＸＭＬアプリケーション１３３が、この帳票生成情報ファイルを解釈して実行することにより、帳票データファイルであるＸＲＦファイルまたはＰＤＦファイルが作成される。その後、このＸＲＦファイルまたはＰＤＦファイルが、アプリケーションサーバ１１７からクライアント２０へと送信されるようになっている。
３．クライアントの構成
３−１．クライアントのハードウェア構成
図５は、クライアント２０の電気的な構成の一例を示すブロック図である。クライアント２０には、ＣＰＵ２１０、ＲＯＭ２１１、ＲＡＭ２１２、入力装置２１３、表示装置２１４、記憶装置２１７（ハードディスクドライブなど）、ネットワークインタフェース２１５および入出力インタフェース（Ｉ／Ｏ）２１８が備えられており、これらはバス２１６で互いに接続されている。ＣＰＵ２１０は、ＲＯＭ２１１および記憶装置２１７に格納されているプログラムに基づいて、ＲＯＭ２１１、ＲＡＭ２１２、入力装置２１３、表示装置２１４、ネットワークインタフェース２１５および入出力インタフェース２１８の相互間でのデータの送受を制御したり、入力装置２１３、表示装置２１４およびネットワークインタフェース２１５の制御を行ったりしている。
【００３９】
入力装置２１３は、キーボードやポインティングデバイスからなり、その操作信号はＣＰＵ２１０に与えられるようになっている。表示装置２１４は、ＣＲＴや液晶表示パネル等の二次元画像表示装置からなり、ＣＰＵ２１０からの表示信号に応じた画像表示をすることができるようになっている。
【００４０】
ＣＰＵ２１０は、ネットワークインタフェース２１５を介してインターネットと接続されている。このため、ＣＰＵ２１０は、インターネットを介して、サーバ１０へ帳票データ要求を送信することができる。
【００４１】
また、入出力インタフェース２１８を介して、プリンタ３０を接続することができ、このプリンタ３０に印刷用データを与えることができる。クライアント２０とプリンタ３０とがローカルエリアネットワークを介して接続されている場合には、プリンタ接続用の入出力インタフェース２１８として、ネットワークアダプタを用いればよい。
３−２．クライアントの機能的構成
図６は、クライアント２０の機能的構成を説明するためのブロック図である。クライアント２０は、ＣＰＵ２１０がＲＯＭ２１１や記憶装置２１７に記憶されているプログラムを実行することによって実現される複数の機能処理部を実質的に備えている。具体的には、クライアント２０は、ネットワークインタフェース２１５を制御する制御部２２０を備えている。制御部２２０は、ネットワークインタフェース２１５を制御することにより、インターネットを介してサーバ１０から送信されるファイルを受信する。
【００４２】
クライアント２０には、さらに、Ｗｅｂブラウザ２２１、ＸＲＦリーダ２２２およびプリンタドライバ２２３が備えられており、これらは制御部２２０によって制御されるようになっている。
【００４３】
Ｗｅｂブラウザ２２１は、たとえばInternet Explorer(注：商標)のような一般に市販されているＷｅｂページ閲覧用のアプリケーションプログラムであり、クライアント２０に予めインストールされて実行可能とされている。Ｗｅｂブラウザ２２１が起動されると、ＨＴＭＬ等のファイルを閲覧するための画面が表示装置２１４に表示されるようになっている。Ｗｅｂブラウザ２２１は、インターネット上の様々なサーバ（サーバ１０を含む。）から、ＨＴＭＬ等で記述されたファイルを受信し、このファイルをＷｅｂブラウザ２２１の表示ウィンドウ内に表示する。このＷｅｂブラウザ２２１の表示ウィンドウがアクティブ状態のときに、ユーザによって入力装置２１３が操作されると、その操作情報はＷｅｂブラウザ２２１に与えられるようになっている。入力された情報は、Ｗｅｂブラウザ２２１内に表示され、さらに所定の入力操作によって、ＨＴＭＬファイル等の送信元のサーバに送信される。
【００４４】
さらにＷｅｂブラウザ２２１は、インターネット上のサーバ（サーバ１０を含む。）から、ＰＤＦファイルを受信することができ、この受信したＰＤＦ形式のファイルをＷｅｂブラウザ２２１内に表示させることができる。より具体的には、Ｗｅｂブラウザ２２１がＰＤＦファイルを受信すると、アドインソフトのＰＤＦファイル閲覧プログラム（アクロバットリーダ：商標）が起動（Ｗｅｂブラウザ２２１のウィンドウ内での内部起動）されるようになっている。
【００４５】
Ｗｅｂブラウザ２２１によってＰＤＦファイルが表示されているときに、ユーザが入力装置２１３に対して所定の操作を行うと、プリンタドライバ２２３の印刷設定ダイアログが開き、この印刷設定ダイアログで適宜設定操作を行うと、ＰＤＦ形式のファイルが印刷用データに変換されてプリンタドライバ２２３に受け渡され、このプリンタドライバ２２３から印刷用データがプリンタ３０に送信されることにより、ＰＤＦファイルの印刷が行われるようになっている。
【００４６】
また、ユーザは入力装置２１３を操作することによって、Ｗｅｂブラウザ２２１上でＵＲＬ（Uniform Resource Locator）を指定することができる。ＵＲＬとは、ＨＴＭＬ等で記述されたファイルやＰＤＦ形式のファイルを提供しているサーバの位置（インターネット上の位置）を特定するための情報である。Ｗｅｂブラウザ２２１は、ＵＲＬが指定されたサーバから、ＨＴＭＬで記述されたファイルやＰＤＦ形式のファイルを受信することができる。なお、この実施形態の電子帳票システムを利用するときは、Ｗｅｂブラウザ２２１のＵＲＬ入力欄に、サーバ１０のＵＲＬが入力されることになる。
【００４７】
ＸＲＦリーダ２２２は、サーバ１０から送信されてくるＸＲＦファイルを表示することができるアプリケーションプログラムであり、クライアント２０に予めインストールされて実行可能となっている。たとえば、ＸＲＦリーダ２２２をＷｅｂブラウザ２２１のヘルパーアプリケーションとして設定しておくことにより、Ｗｅｂブラウザ２２１がＸＲＦファイルを受信したときに、ＸＲＦリーダ２２２を自動的に起動（Ｗｅｂブラウザ２２１とは別のウィンドウでの外部起動）させることができる。ＸＲＦリーダ２２２が起動すると、ＸＲＦファイルの閲覧画面が表示装置２１４に表示される。この閲覧画面にＸＲＦファイルが表示されている時に、ユーザが入力装置２１３に対して所定の入力操作を行うと、ＸＲＦファイルから印刷用のイメージファイルが作成されて、これに基づいて、プリンタ３０からの印刷がされるようになっている。
【００４８】
この実施形態では、ＸＲＦリーダ２２２は、印刷制御部２２２ａを内蔵しており、プリンタドライバ２２３の設定画面とは別の独自のダイアログから印刷条件の設定を行ってプリンタ３０の動作を制御できる。印刷時には、印刷制御部２２ａから、印刷用データがプリンタドライバ２２３に引き渡され、このプリンタドライバ２２３からプリンタ３０にイメージデータが送られるようになっている。
【００４９】
ＸＲＦリーダ２２２の印刷制御部２２２ａは、ユーザによる印刷指示に応答して、印刷ダイアログを表示する。この印刷ダイアログ内において、ユーザは、印刷部数や用紙サイズ等の各種の設定を行うことができ、その設定の後に、印刷開始を指示することができる。印刷開始が指示されると、印刷制御部２２２ａは、印刷ダイアログを閉じて、印刷中であることを表す印刷中ダイアログを表示する。この印刷中ダイアログ内には、印刷を中断するためのキャンセルボタンが設けられており、このキャンセルボタンを操作することによって、印刷を中断できるようになっている。印刷が完了すると（印刷データのプリンタ３０への送出が完了すると）、印刷制御部２２２ａは印刷中ダイアログを閉じる。
【００５０】
なお、ＸＲＴファイルの作成時に、印刷用紙サイズ等の指定が同時に行われ、ＸＲＴファイルは印刷条件に関する情報を有しているので、印刷条件の設定は必ずしも必要ではない。
【００５１】
ＸＲＦファイル内には、ＸＲＦリーダ２２２の動作（画面表示動作や印刷動作）を規定する各種のパラメータを含ませることができる。このパラメータには、クライアントにおけるＸＲＦファイルの保存の可否、印刷の可否、画面表示の可否、印刷ダイアログの表示の可否、印刷中ダイアログの表示の可否などをそれぞれ表すものを任意に含ませることができる。これにより、クライアント２０においてＸＲＦファイルを記憶装置２１７に保存することを制限（禁止）したり、ＸＲＦファイルの印刷や画面表示を制限（禁止）したり、印刷ダイアログが表示されないようにしたり、印刷中ダイアログが表示されないようにしたりすることができる。
【００５２】
これにより、領収書等の帳票の不正発行を防止できる。すなわち、ＸＲＦファイルの保存を禁止することで、ＸＲＦファイルを再利用した帳票の不正発行を防止できる。また、印刷を禁止することで、たとえば、特定人に対してのみ帳票の印刷を許可したりすることができる。さらに、画面表示を禁止することで、表示画像をクリップして帳票データを不正にコピーする行為を制限できる。また、印刷ダイアログの表示をしないようにすれば、複数枚の帳票が不正に出力されることを防止できる。さらに、印刷中ダイアログを表示しないようにすれば、印刷中断によって、不完全状態の帳票が出力されたときに、この不完全な帳票が不正使用されることを防止できる。
４．電子帳票システム全体の動作
図７は、サーバ１０およびクライアント２０により構成される電子帳票システムの概念的な構成を説明するためのブロック図であり、図８は、帳票データ要求の入力を受け付けるための受付画面をＷｅｂブラウザ２２１により表示した例を示す図である。
【００５３】
ユーザ（事業所の営業担当者など）は、帳票が必要となった場合、クライアント２０のＷｅｂブラウザ２２１を起動して、サーバ１０のＵＲＬを指定する。すると、Ｗｅｂブラウザ２２１は、サーバ１０のアプリケーションサーバ１１７からＨＴＭＬ等で記述されたファイルを受信し、図８のような画面を表示する。この画面上で、Ｗｅｂブラウザ２２１は、ユーザの必要としている帳票に関する要求の入力を受け付けることができる。そして、入力装置２１３の操作により、Ｗｅｂブラウザ２２１上で所定の送信操作が行われることによって、入力内容に対応した帳票データ要求が、たとえば、ＣＧＩまたはＪａｖａ（登録商標）アプレットによってアプリケーションサーバ１１７へと送信される。
【００５４】
Ｗｅｂブラウザ２２１は、ＵＲＬ入力部２３０と表示部２３１とを有している。ＵＲＬ入力部２３０にサーバ１０のＵＲＬが入力されると、Ｗｅｂブラウザ２２１は、サーバ１０からＨＴＭＬファイル等で記述されたファイルを受信し、そのファイルを表示部２３１に表示させる。
【００５５】
図８の例では、表示部２３１の中央部に、選択項目一覧として、帳票の種類、月度および会社名の各一覧が表示されている。表示部２３１の下部には、「戻る」ボタン２３２、「送信」ボタン２３３、「印刷」ボタン２３４および「キャンセル」ボタン２３５が表示されている。
【００５６】
ユーザは、入力装置２１３を操作することによって、帳票の種類、月度および会社名の各一覧表示の中から、所望の帳票の条件をそれぞれ選択することができる。この表示例では、「領収書」、「８月度」、「○○株式会社」がそれぞれ選択されている。つまり、「○○株式会社宛の８月度分の領収書」が選択されている。選択されている項目は、表示色を異ならせたり、反転表示をしたりして、非選択項目と区別して表示されるようになっている。
【００５７】
また、Ｗｅｂブラウザ２２１にはポインタ（図示せず）が表示されており、ユーザが入力装置２１３（主にポインティングデバイス）の操作を行うことによって、このポインタを各ボタン２３２〜２３５上へ移動し、これらのボタン２３２〜２３５を押す（クリック）ことができるようになっている。「戻る」ボタン２３２が押されると、別のＨＴＭＬファイル等が読み込まれ、表示部２３１にはこの表示例とは異なる表示がされる。たとえば、直前に表示されていたＨＴＭＬファイル等が表示されてもよいし、電子帳票システムのメニュー画面が表示されてもよい。
【００５８】
一方、「印刷」ボタン２３４が押されると、そのときに選択されている帳票の条件を含む帳票データ要求が、サーバ１０へと送信されるようになっている。また、「キャンセル」ボタン２３５が押されると、表示部２３１に表示されている画面上での各項目の選択状態がクリアされるようになっている。
【００５９】
「送信」ボタン２３３は、別の帳票の条件入力を継続して行いたい場合に操作されるボタンである。たとえば、ユーザが複数の帳票を作成したい場合に、一枚分ずつ帳票の条件を選択して「印刷」ボタン２３４を押す操作を繰り返すと、サーバ１０から帳票データを受信してプリンタ３０から一枚の帳票が出力されてから、次の帳票の印刷データがプリンタ３０に与えられるまでに、空き時間が生じる。この空き時間中に、帳票とは別の印刷データ（たとえば、ローカルエリアネットワーク上でプリンタ３０を共有しているほかのユーザからの印刷データ）が、プリンタ３０に与えられることがある。すると、プリンタ３０から出力される帳票と帳票との間に、その印刷データが印刷された用紙が混じりこんでしまう。したがって、ユーザはプリンタ３０から出力される帳票等を一枚一枚確認して、印刷指示した帳票以外の用紙を取り除かなくてはならない。
【００６０】
この問題は、「送信」ボタン２３３を用いることによって回避される。すなわち、「送信ボタン」２３３が押されると、そのときに選択されている帳票の条件を含む帳票データ要求がサーバ１０のアプリケーションサーバ１１７から要求データ解析部１３１に受け渡され、サーバ１０内のＲＡＭ１１２または記憶装置１１５に蓄積される。そして、ユーザは別の帳票の条件を選択することができるようになる。必要とされる帳票の数の回数だけ同様の操作が繰り返されることにより、それらの帳票の条件に対応した帳票データ要求が同様にしてサーバ１０に蓄積されていく。その後、最後の帳票の条件を選択した後に、「印刷」ボタン２３４が押されると、そのときにＷｅｂブラウザ２２１上で選択されている帳票の条件を含む帳票データ要求がアプリケーションサーバ１１７に送信され、要求データ解析部１３１に受け渡されてＲＡＭ１１２に蓄積される。
【００６１】
それとともに、要求データ解析部１３１は、ＲＡＭ１１２に蓄積された複数の帳票データ要求を一つのジョブとしてまとめて複数ページの帳票データを作成するための処理を実行する。これにより、データ収集・結合処理部１３２などの働きによって、複数の帳票データ要求に対応する帳票データ（複数ページの帳票データ）が作成され、これがアプリケーションサーバ１１７から、クライアント２０へと送信される。これにより、クライアント２０は、プリンタ３０に対して、複数ページの帳票の印刷データを連続的に与えるから、上述の問題を回避できる。
【００６２】
図７を再び参照して、クライアント２０からサーバ１０へは、ユーザが必要としている帳票の条件の指定などを含む帳票データ要求が送信される（矢印Ｂ１）。この帳票データ要求は、アプリケーションサーバ１１７によって受信され、要求データ解析部１３１に受け渡される。要求データ解析部１３１は、この帳票データ要求に対応する帳票データを生成するための情報をＸＭＬで記述したＸＭＬファイル（帳票生成情報ファイル）を作成する。また、要求データ解析部１３１は、帳票データ要求中の帳票の条件などのようなユーザからの指定情報に基づいて、これに対応する特定のユーザデータを部品サーバ１２００から読み出すとともに、このユーザデータをＸＭＬファイルまたはＣＳＶファイルに変換することにより、ユーザデータファイルを作成する。
【００６３】
なお、通常、ユーザデータは、サーバ１０側に保存されており、クライアント２０からの帳票データ要求中で指定された条件（たとえば、顧客の名前、生年月日等）によって特定されたユーザデータが部品サーバ１２００から読み出されるのであるが、場合によっては、帳票データ要求中で指定された条件に合致する数値が、業務アプリケーションである要求データ解析部１３１によって生成され、この数値がユーザデータとされることもある。
【００６４】
要求データ解析部１３１によって生成された帳票生成情報ファイルは、データ収集・結合処理部１３２に受け渡される（矢印Ｂ３）。また、ユーザデータファイルも、データ収集・結合処理部１３２に受け渡される（矢印Ｂ４）。
【００６５】
図９は、要求データ解析部１３１によって帳票生成情報ファイルとして作成されるＸＭＬファイルの一例を示す図である。帳票生成情報ファイル１４０は、ＸＭＬファイルからなり、テキスト形式で記述されているファイルである。そのため、サーバ１０の管理者は、帳票生成情報ファイル１４０の内容を容易に理解することができる。したがって、サーバ１０の管理者は、サーバ１０で実際に行われる処理内容を把握することができるので、サーバ１０の保守や管理を容易に行うことができる。
【００６６】
帳票生成情報ファイル１４０は、帳票データを生成する際の設定等を行うパラメータが記述されている条件設定記述部１４１と、帳票データ要求に対応する帳票データであるＸＲＦファイルの構成要素データ（ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６、外部リソースファイル１２７、ＤＴＤファイル１２３およびユーザデータ１２８）を特定するための情報が記述されているＸＲＦファイル特定情報記述部１４２とから構成されている。
【００６７】
条件設定記述部１４１は、サーバ１０からＸＲＦファイル形式の帳票データを出力するか、またはＰＤＦファイル形式の帳票データを出力するかの出力ファイルモードが記述される出力ファイルモード記述部１４１１、帳票データに使用される文字の種類が記述される外字ファイル情報記述部１４１２、クライアント２０におけるＸＲＦリーダ２２２の動作に関する設定事項（パラメータ）が記述されるＸＲＦリーダ動作設定記述部１４１３、およびプリンタ３０の印刷動作の制御に関する設定事項（パラメータ）が記述されるプリンタ動作設定記述部１４１４を含む。
【００６８】
上述のとおり、データ収集・結合処理部１３２によって生成される帳票データファイルであるＸＲＦファイル内には、ＸＲＦリーダ２２２の動作（画面表示動作や印刷動作）を規定する各種のパラメータを含ませることができる。このパラメータが、帳票生成情報ファイル１４０のＸＲＦリーダ動作設定記述部１４１３に記述され、データ収集・結合処理部１３２によって、ＸＲＦファイルに埋め込まれることになる。
【００６９】
このように、帳票生成情報ファイル１４０にはそれほど多くの記述がされているわけではないが、電子帳票システム全体の動作の設定が可能となっている。
【００７０】
また、帳票生成情報ファイル１４０はＸＭＬファイルであるので、サーバ１０の管理者は、帳票生成情報ファイル１４０を容易に変更することができる。したがって、この電子帳票システムに異常等が発生した場合、その異常に速やかに対処することができる。また、帳票生成情報ファイル１４０を編集することによって、この電子帳票システムに新たな動作を追加することなども容易に行うことができる。
【００７１】
図７を再び参照して、データ収集・結合処理部１３２は、帳票生成情報ファイル（ＸＭＬファイル）とユーザデータファイル（ＸＭＬファイルまたはＣＳＶファイル）とを受信すると、ＸＭＬパーサ１２０と、ＤＯＭファイルまたはＳＡＸファイル１２１とを記憶装置１１５から読み取ることによって（矢印Ｂ５）、ＸＭＬアプリケーション１３３を起動（作動）させる。
【００７２】
帳票生成情報ファイル１４０の出力ファイルモード記述部１４１１において、ＸＲＦファイル形式が帳票データの出力ファイルモードとして指定されているとき（またはＰＤＦファイル形式が指定されていないとき）には、ＸＭＬアプリケーション１３３のＸＲＦファイル作成部１３４は、帳票生成情報ファイル１４０を解釈して、部品サーバ１２００から、ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６および外部リソースファイル１２７を必要に応じて読み取って収集し（矢印Ｂ６）、これらのファイル群およびユーザデータファイルを結合することによって、ＸＲＦファイルを作成する。作成されたＸＲＦファイルは、要求データ解析部１３１に受け渡され、さらに、アプリケーションサーバ１１７から、クライアント２０へと送信されて（矢印Ｂ１０）、ＸＲＦリーダ２２２によって処理される。クライアント２０のユーザは、ＸＲＦリーダ２２２の印刷制御部２２２ａの機能を利用して、ＸＲＦファイルを印刷用データに展開させ、このデータをプリンタドライバ２２３を介してプリンタ３０に送信させ、このプリンタ３０から帳票を出力させることができる。ただし、ＸＲＦファイル中に、印刷を禁止するパラメータが含まれている場合には、印刷不可の状態となる。
【００７３】
一方、帳票生成情報ファイル１４０の出力ファイルモード記述部１４１１において、ＰＤＦファイル形式が帳票データの出力ファイルモードとして指定されているときには、ＸＭＬアプリケーション１３３のＰＤＦファイル作成部１３５は、帳票生成情報ファイル１４０を解釈して、部品サーバ１２００から、ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６および外部リソースファイル１２７を必要に応じて読み取って収集し（矢印Ｂ６）、これらのファイル群およびユーザデータファイルを結合し、さらにイメージデータに展開してＰＤＦファイルを作成する。こうして得られたＰＤＦファイルは、要求データ解析部１３１に受け渡され、さらに、アプリケーションサーバ１１７を介して、クライアント２０のＷｅｂブラウザ２２１に与えられる（矢印Ｂ８）。Ｗｅｂブラウザ２２１がこの受信したＰＤＦファイルを表示しているときに、ユーザによって入力装置２１３の所定操作が行われると、ＰＤＦ形式の帳票データに対応する印刷データが作成され、プリンタドライバ２２３を介して、プリンタ３０へ送信される（矢印Ｂ９）。
【００７４】
図１０は、帳票生成情報ファイルおよびユーザデータファイルを受信したデータ収集・結合処理部１３２の動作を説明するためのフローチャートである。データ収集・結合処理部１３２は、帳票生成情報ファイルとユーザデータファイルとを受信すると、記憶装置１１５からＸＭＬパーサ１２０を読み取る（ステップＳ１）。このＸＭＬパーサ１２０は、データ収集・結合処理部１３２が受信した帳票生成情報ファイル（ＸＭＬファイル）の解析を行う。
【００７５】
ＸＭＬパーサ１２０によって帳票生成情報ファイルが解析されると、その解析内容に従って、その帳票生成情報ファイルがＲＡＭ１１２上に展開される（ステップＳ２）。そして、記憶装置１１５からＤＯＭファイルまたはＳＡＸファイル１２１が読み取られる（ステップＳ３）。
【００７６】
その後、ＸＭＬアプリケーション１３３が起動される（ステップＳ４）。ＸＭＬアプリケーション１３３は、ＤＯＭファイルまたはＳＡＸファイル１２１を利用することによって、ＲＡＭ１１２上に展開された帳票生成情報ファイルを参照し、この帳票生成情報ファイルに基づいて動作する。
【００７７】
図１１は、ＸＭＬアプリケーション１３３の動作を説明するためのフローチャートである。ＸＭＬアプリケーション１３３が起動すると、帳票生成情報ファイル１４０の出力ファイルモード記述部１４１１において、出力ファイルモードがＰＤＦファイル形式に指定されているか否かが判別される（ステップＳ５）。出力ファイルモード記述部１４１１にＰＤＦファイル形式を指定する記述がない場合（ステップＳ５のＮＯ）、ＸＲＦファイル作成部１３４の働きにより、ＸＲＦファイルが作成される（ステップＳ６）。帳票生成情報ファイル１４０の出力ファイルモード記述部１４１１にＰＤＦファイル形式を指定する記述がある場合（ステップＳ５のＹＥＳ）、ＰＤＦファイル作成部１３５の働きにより、ＰＤＦファイルが作成される（ステップＳ７）。こうして作成されたＸＲＦファイルまたはＰＤＦファイルは、帳票データファイルとして、クライアント２０へ送信される（ステップＳ８）。
【００７８】
図７を再び参照して、ＸＭＬアプリケーション１３３によって作成されたＸＲＦファイル１５０が、アプリケーションサーバ１１７を介してＸＲＦリーダ２２２（ＸＲＦファイルの受信によりＷｅｂブラウザ２２１がヘルパーアプリケーションとして起動）に送信されると（矢印Ｂ１０）、ＸＲＦリーダ２２２は、このＸＲＦファイル１５０から帳票画像のイメージデータを作成し、表示装置２１４に表示する。そして、ＸＲＦリーダ２２２上で印刷のための操作が行われると、帳票画像の印刷用データがプリンタドライバ２２３を介してプリンタ３０に送信され、帳票が用紙上に印刷される。
【００７９】
このように、サーバ１０からインターネット等の通信網を介して、クライアント２０へＸＲＦファイル１５０が提供される。そして、クライアント２０側において、ＸＲＦファイル１５０を帳票画像のイメージデータに展開することにより、クライアント２０のユーザは、所望の帳票を手に入れることができる。ＸＲＦファイル１５０は、展開後の帳票画像（イメージデータ）に比べてデータ容量が小さい。このため、通信網上で伝送されるデータ量を低減させることができる。つまり、サーバ１０がクライアント２０へとＸＲＦファイル１５０を送信することによって、ネットワーク上で伝送されるデータ量を減少させつつ、ユーザの所望する帳票を提供することができる。
５．帳票データファイル（ＸＲＦファイル）の説明
図１２は、ＸＲＦファイルの主要な構成要素の１つであるＸＲＴファイル１２４の構成を説明するための概念図である。記憶装置１１５の部品サーバ１２００には、複数のＸＲＴファイル１２４が記憶されている。ＸＲＴファイル１２４は、帳票の背景部分やレイアウトなどの固定部分をページ毎に規定するフォームファイルである。ＸＭＬアプリケーション１３３は、帳票生成情報ファイル１４０のＸＲＦファイル特定情報記述部１４２によって特定されるＸＲＴファイル１２４を、記憶装置１１５から読み取る。クライアント２０のＷｅｂブラウザ２２１から同時に処理すべき複数の帳票データ要求を受信した場合、要求データ解析部１３１は、複数ページの帳票データに関する帳票生成情報を記述した帳票生成情報ファイルを作成してデータ収集・結合処理部１３２に与える。この場合、ＸＭＬアプリケーション１３３は、帳票生成情報ファイル内に記述された個々の帳票ページに対応したＸＲＦファイル特定情報記述部１４２を参照し、それぞれの記述に従って、複数のＸＲＴファイル１２４を記憶装置１１５から読み取り、複数ページの帳票に対応した帳票データファイルを作成する。
【００８０】
図１３は、ＸＲＴファイル１２４の構成を説明するためのブロック図である。ＸＲＴファイル１２４は、フォームファイルであり、帳票フォーム上に固定配置される固定部品（枠線、罫線、アンダーライン、テキスト（文字や数字）、イメージ、描画オブジェクト等）の配置位置および種類その他の属性情報（プロパティ）を記述した固定部品プロパティ１４３Ａと、帳票フォーム上に配置された順に自動的に連番が付されるフィールドの配置位置を含む属性情報（プロパティ）を記述したフィールドプロパティ１４４Ａと、部品ＸＲＴファイルが配置された領域であるエリアの配置位置、大きさ、リンクされる部品ＸＲＴファイル名等の属性情報（プロパティ）を記述したエリアプロパティ１４５Ａとを有している。フィールドは、ユーザデータに応じて変化する文字列、数値、イメージ等の可変情報（個々の帳票毎に変動する情報）を埋め込むための領域であり、ＸＲＴファイル中に予め設定されている。
【００８１】
固定部品がテキストの場合には、このようなテキストは、ＸＲＴファイル上に直接記述されている。また、固定部品がイメージの場合には、対応するイメージファイルのパスおよびファイル名がプロパティとしてＸＲＴファイル上に記述され、そのイメージファイルは、部品サーバ１２００内に外部リソースファイルとして格納されている。固定部品が描画オブジェクトの場合には、その形状、配置位置、色、大きさ等のプロパティがＸＲＴファイルに記述されている。
【００８２】
部品ＸＲＴファイルは、ＸＲＴファイルと同形式のファイルであり、１ページの帳票フォームを定義したファイルではなく、ＸＲＴファイル中に設定されたエリアに埋め込まれる点においてのみ、通常のＸＲＴファイルと異なる。したがって、部品ＸＲＴファイルの構成は、ＸＲＴファイルの構成と同様である。むろん、部品ＸＲＴファイルのなかにエリアを設定し、このエリアに別の部品ＸＲＴを埋め込むこともできる。
【００８３】
ＸＲＴファイル１２４は、通常、固定部品プロパティ１４３Ａと、１つ以上のフィールドに関するフィールドプロパティ１４４Ａを有しているが、エリアプロパティ１４５Ａは必ずしも有しているとは限らない。またＸＲＴファイル１２４にはフィールドがない場合もある。
【００８４】
図１４は、ＸＲＴファイル１２４の具体的な構成例を示す図である。図１４(a)(b)(c)に示すＸＲＴファイル１２４Ａ，１２４Ｂ，１２４Ｃは、いずれも、共通の罫線・枠線・アンダーライン・文字・数字・イメージ・描画オブジェクト等の固定部品１４３と、共通のフィールド１４４（宛名フィールド、年月日フィールド、金額フィールド、摘要フィールド）とが設定された領収書のフォームファイルであり、それらのプロパティの記述を含む。そして、同図(b)に示すＸＲＴファイル１２４Ｂは、同図(a)のＸＲＴファイル１２４Ａの構成に加えて、エリア１４５が右下部に設定されていて、このエリアのプロパティを含む。また、同図(c)に示すＸＲＴファイル１２４Ｃは、同図(a)のＸＲＴファイル１２４Ａの構成に加えて、固定部品（文字列・イメージ・描画オブジェクト等）１４６を右下部に有している。
【００８５】
図１４(a)(b)(c)に示す各ＸＲＴファイル１２４Ａ，１２４Ｂ，１２４Ｃは、記憶装置１１５にそれぞれ別々に記憶されている。したがって、サーバ１０は、様々な形態の領収書をクライアント２０へと提供することができる。
【００８６】
図１５は、ＸＲＦファイルの構成を説明するためのブロック図である。ＸＲＦファイル１５０は、ＤＴＤファイル１２３と、ＸＲＴファイル１２４と、ＸＲＴファイル１２４と一対一に対応付けられているフィールド情報１２５と、ユーザデータファイル１５１とから構成されている。ＸＲＦファイル１５０に含まれるＸＲＴファイル１２４にエリアが設定されている場合、このＸＲＦファイル１５０はさらに、エリアと同数の部品ＸＲＴファイル１２６（各エリア領域にリンクされた部品ＸＲＴファイル）を含んでいる。また、ＸＲＦファイル１５０に含まれているＸＲＴファイル１２４が、イメージデータに対応付けられたフィールドを有している場合や、固定部品としてイメージが貼り付けられる内容となっている場合、そのＸＲＦファイル１５０はさらに、そのようなイメージに対応した外部リソースファイル１２７を含んでいる。
６．帳票画像の生成
図１６は、ＸＲＦファイルに基づいて帳票画像が生成される過程を説明するための図解的な流れ図である。ＸＲＴファイル１２４には、６つのフィールド１４４と、イメージが直接貼り付けられた１つの固定部品１４６とを有している。したがって、このＸＲＴファイル１２４を有するＸＲＦファイル１５０は、ＤＴＤファイル１２３と、フィールド情報１２５と、ユーザデータファイル１５１と、１つの外部リソースファイル１２７（イメージファイル）とを含んでいる。また、ユーザデータファイル１５１は、クライアント２０からユーザが入力指定した内容対応した帳票データ要求によって特定されたユーザデータを記録したファイルであって、たとえば、「１４，８，３０，○○株式会社，１００，０００，書籍代として」というように、各フィールド領域１４４に挿入されるべき情報を区切り記号（この例ではカンマ「，」で区切った形式（いわゆるＣＳＶ形式））で記録している。
【００８７】
なお、通常は、帳票データ要求において指定された条件に従って、部品サーバ１２００から適切なユーザデータが読み出されるが、クライアント２０から、各フィールドに書き込むべき内容が直接指定される場合もありうる。
【００８８】
フィールド情報１２５は、ＸＲＴファイル１２４に設定されたフィールド１４４とＤＴＤファイルとの関連を表し、個々のフィールドのデータ型（文字、数値、バーコード、イメージ等）やフィールドを設定した順番、およびフィールドの数を表す情報である。ＤＴＤファイルには、フィールド情報を介して、個々のフィールドと、ユーザデータとを対応付けるための情報が記述されている。フィールドのデータ型が、文字、数値またはバーコードのように数値等での表現が可能な場合には、個々のフィールドに対応するデータはユーザデータとして部品サーバ１２００に記憶される。また、フィールドのデータ型が、イメージの場合には、ユーザデータはイメージファイルのパスおよびファイル名を含み、そのイメージファイルは、外部リソースファイルとして部品サーバ１２００に記憶されている。
【００８９】
作図アプリケーションを用いて予めＸＲＴファイルを作成するとき、個々のフィールドのプロパティがＸＲＴファイルに記述され、このプロパティには、フィールドを設定した順番が記述される。このフィールドの設定時に、フィールド情報が生成されることになる。
【００９０】
ＤＴＤファイル１２３は、フィールド領域１４４にユーザデータを対応付けるための対応付け情報を格納している。ＸＲＦリーダ２２２およびＰＤＦファイル作成部１３５は、ＤＴＤファイル１２３を参照し、フィールド情報１２５および個々のフィールドのプロパティ（とくにフィールドの設定順に関する情報）に従って、ユーザデータおよび外部リソースファイル１２７を各フィールドに埋め込んでイメージデータに展開する。
【００９１】
たとえば、図１６のＸＲＴファイル１２４において、１番目に設定されたフィールド１に、ユーザデータファイル１５１の１番目の情報である「１４」が、２番目に設定されたフィールド２にはユーザデータファイル１５１の２番目の情報である「８」が、３番目に設定されたフィールド３にはユーザデータファイル１５１の３番目の情報である「３０」が、４番目に設定されたフィールド４にはユーザデータファイル１５１の４番目の情報である「○○株式会社」が、５番目に設定されたフィールド５にはユーザデータファイル１５１の５番目の情報である「１００，０００」が、６番目に設定されたフィールド６にはユーザデータファイル１５１の６番目の情報である「書籍代として」がそれぞれ埋め込まれる。ただし、個々のフィールドの設定順とユーザデータとの対応付けは、ＤＴＤファイル１２３に記述されるので、フィールドの設定順序と、ユーザデータの並び順とが整合している必要はない。
【００９２】
また、ＸＲＦリーダ２２２およびＰＤＦファイル作成部１３５は、帳票フォーム中の固定部品１４３を、ＸＲＴファイル１２４に記述されたプロパティに従ってイメージデータに展開する。さらに、固定部品１４６のように、イメージが貼り付けられる領域については、外部リソースファイル（イメージファイル）を埋め込んで展開する。
【００９３】
このようにして帳票画像が作成される。この作成された帳票画像は、ＸＲＦリーダ２２２においては、表示用イメージデータに変換され、さらに印刷操作がされると、印刷用データに変換されて、プリンタドライバ２２３を介してプリンタ３０に与えられる。
７．部品ＸＲＴファイルの使用態様
図１７は、部品ＸＲＴファイル１２６の使用例を説明するための概念図である。この概念図において、ＸＲＦファイル１５２，１５３は、１つの部品ＸＲＴファイル１２６に共通にリンクされたエリアを有するＸＲＴファイルを含む。
【００９４】
ＸＭＬアプリケーション１３３のＸＲＦファイル作成部１３４は、帳票生成情報ファイル１４０に基づいて、記憶装置１１５の部品サーバ１２００から、帳票データ要求に対応したＸＲＴファイル１２４を読み出し、さらに、このＸＲＴファイル１２４にリンクされた部品ＸＲＴファイル１２６を部品サーバ１２００から読み取り、これらを結合することによって、ＸＲＦファイル１５２，１５３を作成する。
【００９５】
図１７の例では、記憶装置１１５に記憶されている１つの部品ＸＲＴファイル１２６が、ＸＲＦファイル１５２および１５３の生成のために共通に用いられている。このように、複数のＸＲＦファイルにおいて共通して使用される部品ＸＲＴファイル１２６が存在することがある。たとえば、会社印や社名の画像またはテキストに対応した部品ＸＲＴファイル１２６を予め作成して記憶装置１１５の部品サーバ１２００に格納しておけば、サーバ１０が種々の帳票データ（ＸＲＦファイル１５０）を提供するために記憶装置１１５内に確保すべき記憶容量を低減できる。
【００９６】
部品ＸＲＴファイルには、固定部品（文字列、数値、バーコード、イメージ）を配置したり、フィールドを設定したり、さらに他の部品ＸＲＴファイルにリンクされたエリアを設定したりすることができる。そのため、部品ＸＲＴファイルを用いることにより、多様な形態の帳票部品を作成することができ、複数種類の帳票フォームで共用される様々な部品を予め作成しておくことができる。
８．ＸＲＦリーダの動作
図１８は、ＸＲＦファイル１５０を受信したＸＲＦリーダ２２２の表示例を示す図である。クライアント２０において、サーバ１０からＸＲＦファイル１５０を受信し、これをＸＲＦファイルリーダ２２２を用いて閲覧すると、ＸＲＦリーダ２２２には、ＸＲＦファイル１５０から作成された帳票画像２４０と、「前ページへ」ボタン２４１と、「次ページへ」ボタン２４２と、「印刷」ボタン２４３と、「キャンセル」ボタン２４４とが表示される。これらのボタン２４０〜２４４は、入力装置２１３を用いて操作（クリック）することができる。
【００９７】
複数ページの帳票を含む帳票データに対応したＸＲＦファイル１５０をＸＲＦリーダ２２２が受信しても、ＸＲＦリーダ２２２は、帳票画像２４０を一枚ずつしか表示することができない。そのため、「前ページへ」ボタン２４１や、「次ページへ」ボタン２４２を押すことによって、帳票画像２４０を１枚ずつ閲覧することができるようになっている。帳票画像２４０が表示されているときに、「印刷」ボタン２４３が押されると、印刷ダイアログボックスが開き、この印刷ダイアログボックスにおいて印刷条件が設定された後に、印刷開始を指示する操作が行われることにより、ＸＲＦリーダ２２２は、その帳票画像２４０に対応する印刷データをプリンタドライバ２２３を介してプリンタ３０へと送信する（図７の矢印Ｂ１１）。これにより、プリンタ３０からその帳票画像２４０が用紙上に印刷されて出力される。
【００９８】
「キャンセル」ボタン２４４を押すことによって、帳票の印刷を取りやめることができるが、「印刷」ボタン２４３が押された後には、印刷ダイアログボックスが開くから、この印刷ダイアログボックスを閉じるまで、「キャンセル」ボタン２４４は操作することができない。
【００９９】
なお、ＸＲＦリーダ２２２の画面は、上記のような画面内にボタン類の設けられたものではなく、メニューバーに矢印ボタンなどが設けられたものでもよい。
【０１００】
印刷ダイアログボックスから印刷の開始を指示すると、印刷ダイアログボックスは自動的に閉じられ、印刷中であることを表す印刷中ダイアログボックスが現れる。帳票の種類（たとえば、領収書）によっては、この印刷中ダイアログボックスをシステムモーダルダイアログボックスとする設定が可能である。この場合には、この印刷ダイアログボックスを閉じるまでは、オペレーティングシステムの操作も含めて、他の操作を行うことができないようにされていてもよい。つまり、一旦、印刷処理が開始されると、その印刷処理が終了するまでは、他の操作が不可能となり、途中で印刷動作をキャンセルすることができないようにされてもよい。これにより、不完全状態の帳票が作成されて、これが不正使用されるなどという事態を回避できる。印刷処理が完了（たとえば、印刷データの出力完了やプリンタからの印刷完了通知の受信）すると、印刷中ダイアログは自動的に閉じられる。
【０１０１】
受信したＸＲＦファイル１５０内に画面表示を禁止するパラメータが含まれている場合には、帳票画像２４０は表示されず、ボタン２４１〜２４４のみが表示される。これにより、画面上で帳票画像データがコピーされたりすることが防がれ、印刷出力のみが可能となる。
【０１０２】
また、受信したＸＲＦファイル１５０内に、印刷を禁止するパラメータが含まれている場合には、たとえば、印刷ボタン２４３が操作不可能状態（たとえばグレーアウト表示状態）となり、印刷操作を行うことができない状態となる。
【０１０３】
さらに、受信したＸＲＦファイル１５０内に、印刷ダイアログの表示を不許可とするパラメータが含まれていれば、印刷ボタン２４３が操作されても、印刷ダイアログは表示せずに、バックグラウンドで印刷処理が行われる。これにより、複数部数の帳票が印刷されたりすることを防止できる。
【０１０４】
また、受信したＸＲＦファイル１５０内に、印刷中ダイアログの表示を禁止するパラメータが含まれていれば、印刷中ダイアログを表示することなく、印刷処理が行われる。印刷中ダイアログボックス内に印刷を途中中断するための中断ボタンが設けられている場合には、印刷中ダイアログの表示をしないことで、帳票印刷の途中中断を防止できる。
【０１０５】
さらに、受信したＸＲＦファイル１５０内に、ＸＲＦファイルの保存を禁止するパラメータが含まれていれば、ＸＲＦリーダ２２２によるＸＲＦファイルの保存ができない状態とされる。
９．部品ＸＲＴファイルの作成
図１９は、部品ＸＲＴファイルの利用の態様を説明するための概念図である。帳票フォームを形成するＸＲＴファイルおよびこのＸＲＴファイル内にエリアを指定して貼り付けられる部品ＸＲＴファイルは、作図アプリケーションを用いて予め作成され、サーバ１０の部品サーバ１２００に記憶されている。作図アプリケーションでは、ＸＲＴファイルの作成時にエリアを確保し、そのエリア内で部品ＸＲＴファイルを作成することができる。このようにして作成された部品ＸＲＴファイルは、別のＸＲＴファイルまたは部品ＸＲＴファイル上に貼り付けて再利用することができる。
【０１０６】
エリアを確保すると、ＸＲＴファイルにエリアプロパティが記述される。このエリアプロパティは、エリアの大きさおよびＸＲＴファイル内での位置情報を含む。
【０１０７】
既存の部品ＸＲＴファイルをＸＲＴファイルに取り込むときには、ＸＲＴファイルの内容を表示した作画アプリケーションの画面上でアクティブなカーソル位置に部品ＸＲＴファイルが貼り付く。このとき、エリアプロパティがＸＲＴファイルに記述される。このエリアプロパティは、部品ＸＲＴファイルが貼り付いている位置と、エリアの大きさの情報を含む。この場合のエリアの大きさは、当該部品ＸＲＴファイルを最初に作成したときに確保されたエリアの大きさに等しい。
【０１０８】
図１９に示された部品ＸＲＴファイル１６１は、固定部品としてのイメージファイルが貼り付けられた領域１６２と、テキストデータが貼り付けられた領域１６３とを含む。この例では、領域１６２には、ＸＸＸ株式会社のロゴを表すイメージファイルが貼り付けられており、領域１６３には、「ＸＸＸ株式会社，０１−２３４５−６７８９」というテキストデータが貼り付けられている。上述のとおり、部品ＸＲＴファイルには、ＸＲＴファイルの場合と同様に、フィールドを設定することができ、このフィールド内に文字や数値等のユーザデータを貼り付けたり、イメージデータを貼り付けたりすることもできる。
【０１０９】
図２０は、部品ＸＲＴファイル１２６の利用態様を説明するための概念図である。ＸＲＦファイル１７１，１７２，１７３，１７４は、それぞれ、記憶装置１１５に記憶されている部品ＸＲＴファイル１６１に共通にリンクされたエリアをそれぞれ有するＸＲＴファイルを含むものとする。
【０１１０】
たとえば、図１９に示すように、領域１６３の「ＸＸＸ株式会社，０１−２３４５−６７８９」というテキストデータを、「ＸＸＸ株式会社，０１−２３４５−６７８０」というテキストデータに変更する必要が生じた場合を想定する。
【０１１１】
このとき、サーバ１０の管理者は、作図アプリケーションを用いることによって、部品ＸＲＴファイル１６１の領域１６３のテキストデータを編集して、「ＸＸＸ株式会社，０１−２３４５−６７８０」へと変更することができる。この変更された部品ＸＲＴファイル１６１は、作図アプリケーションによって、たとえば、記憶装置１１５に上書き保存される。領域１６２のイメージファイルの変更も同様にして行える。
【０１１２】
変更後の部品ＸＲＴファイル１６１が記憶装置１１５に記憶されると、その後に部品ＸＲＴファイル１６１を構成要素として含むＸＲＦファイルが生成されたとき、そのＸＲＦファイルは変更後の部品ＸＲＴファイル１６１を構成要素として含むことになる。
【０１１３】
したがって、サーバ１０の管理者は、部品ＸＲＴファイル１２６を編集することにより、部品ＸＲＴファイル１２６を用いて生成される複数種類の帳票に対して、その編集結果を共通に反映させることができる。
１０．ユーザデータに応じた外観の変更
１０−１．ユーザデータに応じた画像部品の選択
図２１は、ユーザデータに応じて帳票の外観を変更するための機能を備えたサーバ１０の構成例を説明するためのブロック図である。この図２１において、図４に示された構成部分と同等の部分には、図４の場合と同一符号を付して、その説明を省略する。
このサーバ１０の業務アプリケーションは、上述の要求データ解析部１３１の機能のほかに、ユーザデータに応じて適切なイメージファイルを決定し、そのイメージファイルのパスおよびファイル名を帳票生成情報ファイルに記述するイメージファイル設定部１３６の機能が備えられている。
【０１１４】
要求データ解析部１３１は、ユーザデータに応じて複数のイメージファイルから選択された１つのイメージファイルを貼り付けるべき領域が設定されたＸＲＴファイルを帳票データファイルの構成要素とすべき帳票生成情報を生成する場合がある。この場合、要求データ解析部１３１は、クライアント２０からの帳票データ要求に応じて読み出されたユーザデータをイメージファイル設定部１３６に引き渡す。イメージファイル設定部１３６は、引き渡されたユーザデータに基づいて、ＸＲＴファイル中の当該領域に貼り付けるべきイメージファイルを特定し、そのファイルのパス名およびファイル名を帳票生成情報ファイル中に記述する。
【０１１５】
図２２は、イメージファイル設定部１３６の機能を説明するための概念図である。図２３は、サーバ１０からクライアント２０へと提供される帳票データ（ＸＲＦファイル）の一例を説明するための概念図である。
【０１１６】
図２２の概念図において、帳票データの構成要素であるＸＲＴファイル１８０には、データ型として文字または数値を指定した１４個のフィールド１８１，１８２と、イメージが貼り付けられた領域１８３と、複数のイメージから選択された１つのイメージが貼り付けられるように設定された領域１８４とが設定されている。一方、記憶装置１１５には、イメージファイル１８５，１８６，１８７，１８８，１８９および１８１０が記憶されているものとする。領域１８３には、イメージファイル１８５が固定部品として貼り付けられている。
【０１１７】
イメージファイル設定部１３６は、クライアント２０から与えられる帳票データ要求によって特定されたユーザデータのデータ値に応じて、イメージファイル１８６〜１８１０のいずれかを、フィールド１８４に貼り付けるべきイメージファイルとして特定する。たとえば、イメージファイル設定部１３６は、１４番目の入力データのデータ値が、「０」以上「５００，０００」未満であればイメージファイル１８６を、「５００，００１」以上「１，０００，０００」未満であればイメージファイル１８７を、「１，０００，００１」以上「１，５００，０００」未満であればイメージファイル１８８を、「１，５００，００１」以上「２，０００，０００」未満であればイメージファイル１８９を、「２，０００，００１」以上「２，５００，０００」未満であればイメージファイル１８１０を、領域１８４に埋め込むべきイメージファイルとして特定する情報（パスおよびファイル名）を帳票生成情報ファイル１４０中に記述するようにその動作が設定されている。
【０１１８】
この実施形態では、イメージファイル１８６〜１８１０は、互いに長さの異なる横長の帯状図形と、「現在庫金額」という文字列とでそれぞれ構成されている。帯状図形の長さは、在庫金額の多少を視覚的に表している。必要に応じて、帯状図形部分および／または文字列部分の色を異ならせておいてもよい。たとえば、在庫金額過小や在庫金額過多に対応したイメージファイル１８６，１８１０などの帯状図形部分を赤色とし、適正在庫金額に対応したイメージファイル１８８の帯状図形部分を緑色とし、他のイメージファイル１８７，１８９は黄色としたりすれば、在庫の多少を一目で把握できる。
【０１１９】
たとえば図２３に示すように、１４番目のユーザデータのデータ値が「１９６９９６０」であるとする。すると、イメージファイル設定部１３６は、領域１８４に埋め込むべきイメージファイルのパスおよびファイル名として、イメージファイル１８９のパスおよびファイル名を帳票生成情報ファイル１４０に記述する。
【０１２０】
その後、ＸＭＬアプリケーション１３３が、この帳票生成情報ファイル１４０をもとにＸＲＦファイルまたはＰＤＦファイルを作成する。作成されたＸＲＦファイル１５０を、ＸＲＦリーダ２２２で表示したものが、図２３に示す帳票画像１８１１である。
【０１２１】
帳票画像１８１１は、「８月度在庫管理表」を示す帳票画像である。この帳票画像１８１１は、イメージファイル１８５および１８９によって、８月現在の在庫金額が適正範囲であることを、視覚的に理解しやすい内容となっている。
【０１２２】
イメージファイル設定部１３６がイメージファイルを選択するときの条件値は、サーバの管理者によって変更可能であるようになっていてもよい。また、その条件値の判断対象となるユーザデータの設定の変更も行うことができるようになっていてもよい。さらに、イメージファイル設定部１３６によって特定されるイメージファイル（外部リソースファイル）の設定も変更できるようになっていてもよい。
【０１２３】
このように、ユーザデータに応じて外観を異ならせた帳票を作成することができる。しかも、１つの帳票フォームに選択的に用いられる複数のイメージファイルを、帳票フォームのデータとは別に記憶するようにしているから、記憶装置１１５の記憶容量を圧迫することがない。
【０１２４】
なお、上記の例では、特定の領域に、ユーザデータの値に応じて選択されたイメージファイルが貼り付けられる例について説明したが、同様の構成および処理によって、帳票フォームファイルであるＸＲＴファイルに設定されたエリアのプロパティをユーザデータに応じて変化させることにより、複数の部品ＸＲＴファイル（部品フォーム）のうちのいずれかをユーザデータの値に応じて選択して、当該エリアにリンクすることもできる。これによっても、ユーザデータに応じて多様に外観を異ならせた帳票を作成できる。
１０−２．ユーザデータに応じた描画オブジェクトの特性変更
図２４は、ユーザデータに応じて帳票の外観を異ならせるために用いられるサーバ１０の他の構成例を説明するためのブロック図である。この図２４において、図４に示された各部に対応する部分には、図４の場合と同一符号を付して、その説明を省略する。
【０１２５】
このサーバ１０の業務アプリケーションは、上述の要求データ解析部１３１としての機能のほかに、描画オブジェクト（線、円、長方形、多角形、円弧、扇形等の図形データ）のプロパティを変更するプロパティ変更処理部１３７としての機能を有している。
【０１２６】
クライアント２０からの帳票データ要求に対応したＸＲＴファイルには、固定部品としての描画オブジェクトが貼り付けられている場合がある。そして、この実施形態では、特定の描画オブジェクトについて、ユーザデータに基づくプロパティの自動変更が行えるようになっている。
【０１２７】
ＸＲＴファイルを作図アプリケーションを用いて作成するとき、描画オブジェクトを帳票フォーム上に配置することができる。作図アプリケーションは、描画オブジェクトを編集するためのエディタ機能を有していて、たとえば、マウスのドラッグ操作によって、所望の形状の描画オブジェクトを選択して帳票上の所望の位置に配置したり、同じくマウスのドラッグ操作などで当該描画オブジェクトの形状や大きさを変更したりすることができる。こうして作成された描画オブジェクトは、帳票フォーム上での貼り付け位置、大きさ、線種（外形線など）および色などのプロパティを有することになる。これらのプロパティは、作図アプリケーション上で、プロパティ編集ダイアログへの記入によって変更することができる。このようにして生成されるプロパティがＸＲＴファイルに記述されている。
【０１２８】
図２５は、長方形の図形に対応した描画オブジェクトのプロパティ編集ダイアログの表示例を示す図である。このプロパティ編集ダイアログには、長方形オブジェクトの左上頂点の横方向に関する位置データ１９１と、長方形の左上頂点の縦方向に関する位置データ１９２と、長方形の横の長さデータ１９３と、長方形の縦の長さデータ１９４とが表示されるようになっている。
【０１２９】
この例では、長方形の左上頂点の横位置データ１９１は「８７．５」、縦方向位置データ１９２は「６．７７１」、横の長さデータ１９３は「２５．２６」、縦の長さデータ１９４は「１７．９６９」となっている。各データ１９１〜１９４の値が変更されると、長方形の描画オブジェクトの位置、大きさおよび形状（縦横の長さの比）が変化する。
【０１３０】
描画オブジェクトのプロパティ編集ダイアログには、さらに、オブジェクト名設定部１９５と、「ＯＫ」ボタン１９６と、「キャンセル」ボタン１９７とが含まれている。これらのボタンは、マウス等で操作（クリック）できる。「ＯＫ」ボタン１９６を操作することで、プロパティの各値が確定し、デフォルト値としてＸＲＴファイルに書き込まれることになる。
【０１３１】
プロパティ変更処理部１３７は、クライアント２０からの帳票データ要求に対応したユーザデータの値に基づいて、ＸＲＴファイル中の特定の描画オブジェクトに関して、適切なプロパティ値を定め、当該描画オブジェクトのプロパティ値をその値に変更するように指示するためのコマンドを帳票生成情報ファイルに記述する。たとえば、プロパティ中のデータ１９１〜１９４の値をユーザデータに対応する値に変更するためのコマンドを帳票生成情報ファイルに記入する。
【０１３２】
このようにして、ユーザデータの値に応じて位置、大きさおよび形状（必要に応じてさらに色）を変化させるためのコマンドを含む帳票生成情報ファイルが作成されて、データ収集・結合処理部１３２に与えられることになる。
【０１３３】
図２６は、ユーザデータの値に応じて描画オブジェクトのプロパティが変更されることによる長方形図形の変形を説明するための概念図である。クライアント２０からの帳票データ要求に対応した帳票フォームファイル（ＸＲＴファイル）に長方形描画オブジェクトのプロパティが記述されている場合を想定する。そして、当該長方形描画オブジェクトのデフォルトプロパティとして、横方向位置データ１９１が「８７．５」、縦方向における位置データ１９２が「６．７７１」、横方向長さデータ１９３が「２５．２６」、縦方向長さデータ１９４が「１７．９６９」にそれぞれ設定されているものとする。
【０１３４】
たとえば、要求データ解析部１３１による解析の結果、帳票データ要求に対応したユーザデータＡが「７５％」という値である場合、プロパティ変更処理部１３７は、上記長方形描画オブジェクトの横方向長さデータ１９３を、「２５．２６」から、「２５．２６」の７５％分に相当する「１８．９４５」へと変更するためのコマンドを作成して帳票生成情報ファイルに書き込む。これにより、データ収集・結合処理部１３２のＸＭＬアプリケーション１３３がそのコマンドを解釈することにより、ＸＲＴファイルを変更し、当該長方形描画オブジェクトのプロパティが変更されたＸＲＴファイルを作成する。これにより、クライアント２０のＸＲＦリーダでは、横方向長さを「２２．７３４」とした長方形図形のイメージデータが展開されることになる。
【０１３５】
また、帳票データ要求に対応するユーザデータＢが「９０％」という値である場合、プロパティ変更処理部１３７は、上記基本の長方形描画オブジェクトの横方向長さデータ１９３を、「２５．２６」から、「２５．２６」の９０％分に相当する「２２．７３４」へと変更するためのコマンドを作成して帳票生成情報ファイルに記入する。これに応じて、ＸＭＬアプリケーション１３３によって、ＸＲＴファイルが変更され、当該長方形描画オブジェクトのプロパティが変更される。これにより、クライアント２０のＸＲＦリーダでは、横方向長さを「２２．７３４」とした長方形図形のイメージデータが展開されることになる。
【０１３６】
このようにして、ユーザデータの値に応じたプロパティ（とくに形態に関するプロパティ）の描画オブジェクトを有するＸＲＴファイルを自動生成することができる。
【０１３７】
図２７は、サーバ１０からクライアント２０へ提供される帳票データの一例を説明するための概念図である。クライアント２０からサーバ１０に送信された帳票データ要求（とくに帳票の種類を指定する部分）に対応した帳票フォームファイルであるＸＲＴファイル１９１１には、フィールド１９１２，１９１３が設定されており、さらに、領域１９１４にイメージデータ１９１７が貼り付けられ、領域１９１５，１９１６にはそれぞれ長方形描画オブジェクト１９８（デフォルトのプロパティを有するもの）が貼り付けられているものとする。領域１９１４にリンクされたイメージファイル１９１７は記憶装置１１５に記憶されていて、ＸＲＴファイルには、イメージのプロパティとして、そのイメージファイル１９１７のパスおよびファイル名が記述されている。また、描画オブジェクト１９８はそのプロパティがＸＲＴファイルに記述されている。
さらに、プロパティ変更処理部１３６が、領域１９１５，１９１６に貼り付けられた基本の長方形描画オブジェクト１９８のプロパティを、ユーザデータ（たとえば、フィールド１９１２，１９１３に対応するもの）に応じた値に変更するためのコマンドを帳票生成情報ファイル中に記述するものとする。
【０１３８】
一方、帳票データ要求に基づいて特定されたユーザデータとして「７５％，９０％」が部品サーバ１２００から読み出されて、業務アプリケーションに与えられている場合を想定する。要求データ解析部１３１は、フィールド１９１２に最初のユーザデータ「７５％」が埋め込まれ、フィールド１９１３に２番目のユーザデータ「９０％」が埋め込まれるように、ユーザデータファイルを作成する。プロパティ変更処理部１３６は、領域１９１５，１９１６の描画オブジェクト１９８のプロパティをユーザデータ「７５％，９０％」に応じてそれぞれ変更すべきことを表すコマンドを生成し、このコマンドを帳票生成情報ファイルに記入する。プロパティ変更後の長方形描画オブジェクトを参照符号１９９，１９１０でそれぞれ示す。
【０１３９】
上記のようにして自動生成された帳票生成情報ファイル１４０は、ＸＭＬアプリケーション１３３によって解釈され、その結果、ＸＲＴファイル１９１１において領域１９１５，１９１６の長方形描画オブジェクトのプロパティが変更され、この変更後のＸＲＴファイルを含むＸＲＦファイル１５０が作成される。このＸＲＦファイル１５０は、ＸＲＴファイル１９１１（描画オブジェクトのプロパティが変更されたもの）、イメージファイル１９１７、およびユーザデータなどを構成要素データとして含むことになる。このＸＲＦファイル１５０を、アプリケーションサーバ１１７を介してクライアント２０に送信し、ＸＲＦリーダ２２２で表示させることにより、帳票画像１９１９が得られる。
【０１４０】
帳票画像１９１９は、商品Ａ，Ｂとの在庫品の在庫率を示す帳票データである。この帳票画像１９１９は、イメージファイル１９１７および長方形描画オブジェクト１９９，１９１０によって、商品Ａ，Ｂとの在庫品の在庫率が視覚的に表されており、直感的に理解しやすい外観を呈している。
【０１４１】
ここでは、ユーザデータの値に対応して長方形の横方向長さを変更する例について説明したが、縦方向長さを変化させたり、併せて描画オブジェクトの色をユーザデータの値に応じて変化させたりしてもよい。また、ここでは、百分率で表されるユーザデータに対応するように描画オブジェクトのプロパティを変更させることとしたが、プロパティ変更処理部１３６に予め基準値を設けておき、ユーザデータと基準値との比較結果（たとえば、基準値とユーザデータとの差の大小）に応じて、描画オブジェクトのプロパティを変化させるような構成であってもよい。
むろん、基本となる描画オブジェクトの形状は、長方形に限らず、円形、円弧、扇形などの他の形状であってもよい。
【０１４２】
図２８は、ユーザデータに応じて描画オブジェクトのプロパティを変更する機能を実現した電子帳票システムの構成を説明するためのブロック図である。クライアント２０からの帳票データ要求は、Ｗｅｂブラウザ２２１から、アプリケーションサーバ１１７を介して、要求データ解析部１３１に与えられる（矢印Ｃ１）。要求データ解析部１３１は、帳票要求データに対応したユーザデータを記憶装置１１５から読み出す（矢印Ｃ３）。
【０１４３】
帳票データ要求に対応する帳票フォーム（ＸＲＴファイル）に、ユーザデータによるプロパティ変更の対象となる描画オブジェクトが貼り付けられている場合、要求データ解析部１３１は、ユーザデータをプロパティ変更処理部１３７に与える（矢印Ｃ３）。
【０１４４】
プロパティ変更処理部１３７は、与えられたユーザデータに応じて、対象となる描画オブジェクトのプロパティを変更するためのコマンドを作成して帳票生成情報ファイル中に記入する（矢印Ｃ４）。
【０１４５】
要求データ解析部１３１は、また、帳票データ要求に対応する帳票データを作成するための帳票生成情報ファイル１４０と、ユーザデータ１５１とをデータ収集・結合処理部１３２へと送信する（矢印Ｃ７）。この帳票生成情報ファイル１４０には、帳票フォームファイル（ＸＲＴファイル）中の描画オブジェクトのプロパティを変更すべきことを指示するコマンドが含まれている。
【０１４６】
帳票生成情報ファイル１４０と、ユーザデータ１５１とを受信したデータ収集・結合処理部１３２は、記憶装置１１５からＸＭＬパーサ１２０と、ＤＯＭファイルまたはＳＡＸファイル１２１とを読み取ることによって（矢印Ｃ８）、ＸＭＬアプリケーション１３３を起動させる。ＸＭＬアプリケーション１３３は、帳票生成情報ファイル１４０に基づいて、ＤＴＤファイル１２３、ＸＲＴファイル１２４、フィールド情報１２５、部品ＸＲＴファイル１２６および外部リソースファイル１２７を記憶装置１１５から読み取ることによって（矢印Ｃ９）、ＸＲＦファイル１５０を作成する。このとき、上記プロパティ変更処理部１３７が生成したコマンドに従って、ＸＲＴファイル中の描画オブジェクトのプロパティが変更される。
【０１４７】
帳票生成情報ファイル１４０の出力ファイルモード記述部に、ＰＤＦファイル形式の指定がなければ、ＸＭＬアプリケーション１３３のＸＲＦファイル作成部１３４によってＸＲＦファイルが作成され、このＸＲＦファイルが、要求データ解析部１３１に引き渡される。このＸＲＦファイルは、アプリケーションサーバ１１７を介して、ＸＲＦリーダ２２２（ＸＲＦファイルの受信によりＷｅｂブラウザ２２１がヘルパーアプリケーションとして起動）に送信される（矢印Ｃ１３）。ＸＲＦリーダ２２２がこの受信したＸＲＴファイル１５０を表示しているときに、入力装置１１３の所定操作が行われると、帳票の印刷データがプリンタドライバ２２３を介してプリンタ３０に送信され、このプリンタ３０から帳票が用紙上に印刷出力される（矢印Ｃ１４）。このようにして、ユーザデータに応じてプロパティ（とくに形態）が変更された描画オブジェクトが埋め込まれた状態の帳票を得ることができる。
【０１４８】
帳票生成情報ファイル１４０の出力ファイルモード記述部において、ＰＤＦファイル形式が指定されている場合には、ＸＭＬアプリケーション１３３のＰＤＦファイル作成部１３５は、ＸＲＴファイルに対応したフォームのイメージデータを展開し、さらに、このイメージデータにユーザデータ、イメージおよび描画オブジェクトを展開して埋め込む。このようにして得られたＰＤＦファイルは、要求データ解析部１３１に引き渡され、アプリケーションサーバ１１７を介して、クライアント２０のＷｅｂブラウザ２２１に与えられる（矢印Ｃ１１）。Ｗｅｂブラウザ２２１が、この受信したＰＤＦファイルを表示しているときに、ユーザによって入力装置１１３の所定操作が行われると、帳票の印刷データが作成されてプリンタドライバ２２３を介し、プリンタ３０に与えられ、このプリンタ３０から帳票が印刷出力されることになる（矢印Ｃ１２）。
【０１４９】
なお、クライアント２０からの帳票データ要求に対応した帳票フォームファイル（ＸＲＴファイル）が、ユーザデータに応じて必ずプロパティが変更される描画オブジェクトを有する場合には、要求データ解析部１３１は、帳票フォームファイル（ＸＲＴファイル）のファイル名から、描画オブジェクトのプロパティの変更が必要であると判断して、プロパティ変更処理部１３７にユーザデータを引き渡すようになっていてもよい。
【０１５０】
また、帳票によっては、描画オブジェクトのプロパティを変更せずに、デフォルト値を使用するか、描画オブジェクトのプロパティを変更するかをクライアント２０から指定（帳票データ要求に指定情報を含ませる。）させる場合も考えられる。このような場合には、要求データ解析部１３１は、クライアント２０からの指定の有無を最初に判断して、描画オブジェクトのプロパティを変更しないことが指定されていれば、プロパティ変更処理部１３７によるコマンドの作成をスキップするようにすればよい。
１１．帳票フォームの構成要素ファイルのキャッシュが可能な実施形態
図２９は、この発明の他の実施形態に係る電子帳票システムの全体構成を示すブロック図である。この実施形態では、サーバ１０と、複数のプロキシサーバ４０とがインターネットに接続されている。サーバ１０は、大規模な処理を行うことのできるコンピュータであって、インターネットと通信可能に接続されている。プロキシサーバ４０は、記憶手段を有するパーソナルコンピュータであって、たとえばオフィスやビル毎に設置されている。
【０１５１】
プロキシサーバ４０には、ＬＡＮ（ローカルエリアネットワーク）５０が接続されている。ＬＡＮ５０には、たとえばオフィス内に設置された複数のクライアント２０やプリンタ３０が接続されている。クライアント２０は、オフィス等に設置されているパーソナルコンピュータである。そして、クライアント２０は、ＬＡＮ５０に接続されている他のクライアント２０と、互いにデータの送受を行うことができるようになっており、プリンタ３０を共有している。
【０１５２】
プロキシサーバ４０は、インターネットとＬＡＮ５０とを通信可能に接続することができる。したがって、サーバ１０とクライアント２０とは、プロキシサーバ４０を介して、互いにデータの送受を行うことができるようになっている。
【０１５３】
この実施形態では、ＸＲＦファイルの構成要素がプロキシサーバ４０にキャッシュされるようになっており、クライアント２０は、ＸＲＦファイルの構成要素ファイルのうちプロキシサーバ４０にキャッシュされていないもののみをサーバ１０から受信してＸＲＦファイルをクライアント２０側で作成する。これにより、ネットワークの負荷の軽減が図られている。しかも、構成要素データの単位でキャッシュが行われるから、クライアント２０から全く同一内容の帳票の要求が出された場合だけでなく、異なる内容の帳票であっても、構成要素データの一部が共通していれば、キャッシュにヒットすることになるから、キャッシュの効率がよくなる。これにより、ネットワークの負荷を効率的に低減できる。
【０１５４】
図３０は、この実施形態におけるサーバ１０の構成例を説明するためのブロック図である。図３０のブロック図において、図４に示された各部と同等の構成部には図４の場合と同一符号を付してその説明を省略する。
【０１５５】
記憶装置１１５は、ＸＭＬパーサと、ＤＯＭファイルまたはＳＡＸファイルと、ＤＴＤファイルとを記憶している。記憶装置１１５は、さらに、各複数種類のＸＲＴファイルと、フィールド情報と、部品ＸＲＴファイルと、外部リソースファイルとを記憶している。この構成における記憶装置１１５は、ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイルのそれぞれと一対一に対応付けられている更新日時情報をさらに記憶している。更新日時情報とは、ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイルのそれぞれが、記憶装置１１５に最後に記憶された日時（最終更新日時）を示す情報である。
【０１５６】
サーバ１０の管理者は、作図アプリケーションを使用することにより、ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイル１２７を必要に応じて編集し、更新後のファイルを記憶装置１１５に上書きしたり、別名のファイルとして書き込んだりすることができる。このとき、各ファイルに対応付けて、当該ファイルが最後に記憶装置１１５に書き込まれた時間が、更新日時情報として記憶装置１１５に併せて書き込まれる。
【０１５７】
サーバ１０の業務アプリケーションは、要求データ解析部１３１の機能と、ＸＲＦファイルの個々の構成要素データについてキャッシュの可否を表す情報（フラグ）を付加するキャッシュ禁止データ設定部１３１３との機能を有している。この業務アプリケーションは、ＸＭＬアプリケーション１３３からなる帳票生成情報ファイル読取部１３１１と連携して動作する。
【０１５８】
要求データ解析部１３１は、クライアント２０からの帳票データ要求に基づいて帳票生成情報ファイルおよびユーザデータファイルを作成するとともに、帳票生成情報ファイルを帳票生成情報ファイル読取部１３１１に与える。これにより、ＸＭＬアプリケーション１３３が起動され、ＤＯＭファイルまたはＳＡＸファイルを介してＸＭＬパーサが呼び出される。
【０１５９】
ＸＭＬアプリケーション１３３は、このＸＭＬパーサを介してＸＭＬファイル形式で記述された帳票生成情報ファイルを解釈し、その解釈結果に従って、帳票データに対応するＸＲＦファイルを構成するＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイルを特定するための情報（たとえば、パスおよびファイル名）と一対一に対応付けられている更新日時情報を記憶装置１１５から読み取ることができる。
【０１６０】
そして、ＸＭＬアプリケーション１３３は、帳票生成情報ファイルに記述されている、ＸＲＦファイル（帳票データ）の構成ファイル特定情報（たとえばパスおよびファイル名。帳票フォームデータ特定情報）と、それらのファイルの更新日時情報とをまとめて、更新日時情報の記述を加えた帳票生成情報ファイルを生成する。ＸＭＬアプリケーション１３３は、この更新日時情報付き帳票生成情報ファイルを要求データ解析部１３１に引き渡す。要求データ解析部１３１は、この帳票生成情報ファイルを、ユーザデータファイルとともに、アプリケーションサーバ１１７を介してクライアント２０に送信することができる。
【０１６１】
要求データ解析部１３１は、クライアント２０から、ＸＲＦファイルの構成要素ファイルの送信を要求するファイル送信要求をアプリケーションサーバ１１７が受け付けたときに、要求されたファイル（ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）を記憶装置１１５から読み取ることができる。そして、これらの読み取ったファイルを、アプリケーションサーバ１１７を介して、クライアント２０に与えることができる。
【０１６２】
要求されたファイルがクライアント２０に送信されるときに、その要求されたファイル（ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）は、プロキシサーバ４０に記憶（キャッシュ）される。このキャッシュされるファイルは、その属性として、更新日時情報を有している。
【０１６３】
たとえば、会社印等を含むような帳票は、クライアント側でキャッシュすると、不正に使用されるおそれがある。そのため、帳票そのものが重要なものである場合や、会社印等の重要なイメージ等を含む帳票については、少なくともその重要部分を構成するファイルのキャッシュができないように、キャッシュ禁止情報が帳票生成情報ファイルに記入される。
【０１６４】
具体的には、キャッシュ禁止データ設定部１３１３は、クライアント２０からの帳票データ要求に対応した帳票データが、キャッシュ禁止データ設定部１３１３によってキャッシュ禁止設定のされたファイルを含む場合に、帳票データの構成要素ファイル（ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル。すなわち、帳票フォームの構成要素ファイル）の全部または一部のキャッシュを禁止するパラメータを帳票生成情報ファイルに埋め込む。これにより、プロキシサーバ４０にキャッシュされるＸＲＴファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイルを制限することができるようになっている。
【０１６５】
以下は、キャッシュ禁止設定のためのパラメータを含む帳票生成情報ファイルの形式例である。
<？XML version="1.0"？>
<DOCUMENTINFO>
<!-パラメータ情報-- >
<PARAMETER>
<OUTPUTMODE>XRF or PDF</OUTPUTMODE>
<FSETNAME>Accessor設定ファイル</FSETNAME>
<FORMNAME>帳票ファイル名</FORMNAMAE>
<CASHMODE>キャッシュの可否</CASHMODE>
<COPIES>部数</COPIES>
<FEEDER>給紙トレイ</FEEDER>
<OUTPRINTER>出力先プリンタ</OUTPRINTER>
・・・・・・
<REQUESTNAME>ログ出力時のユーザ名</REQUESTNAME>
<USERNAME>セキュリティ用のユーザ名</USERNAME>
<PASSWORD>セキュリティ用のパスワード</PASSWORD>
</PARAMETER>
<XRT>
<XRTFILE>XRTファイル名を指定</XRTFILE>
<XMLDATA>
<XMLFILE>XMLファイル名</XMLFILE>
</XMLDATA>
</XRT>
ユーザデータは、帳票毎に異なるのが一般的であるから、キャッシュの必要がない。したがって、ユーザデータファイルについては、たとえば、帳票生成情報ファイル中にキャッシュを禁止するためのパラメータを記述するか、クライアント２０側のアプリケーションによる処理によって、ユーザデータをキャッシュ対象外とするようにしておけばよい。
【０１６６】
図３１は、この実施形態の電子帳票システムにおけるクライアント２０の構成例を説明するためのブロック図である。図３１において、図６に示された各部と同等の構成部分には、図６の場合と同一符号を付して示し、その説明を省略する。
【０１６７】
クライアント２０には、データ結合処理部２２９と、キャッシュ判定部２２４とが備えられている。データ結合処理部２２９と、キャッシュ判定部２２４とは、制御部２２０によって制御されている。
【０１６８】
データ結合処理部２２９およびキャッシュ判定部２２４は、ＸＭＬアプリケーションによって実現される機能処理部である。これらのうち、データ結合処理部２２９は、サーバ１０から与えられる帳票生成情報ファイルを解釈し、ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイル、外部リソースファイルおよびユーザデータを結合して、帳票データファイルであるＸＲＦファイルを作成する。
【０１６９】
一方、キャッシュ判定部２２４は、サーバ１０から与えられる帳票生成情報ファイルに記述されているＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイル、すなわち帳票データとしてのＸＲＦファイルを構成する構成要素ファイル（ただしユーザデータ以外）が、プロキシサーバ４０に記憶されているか否かを判別する。帳票生成情報ファイルによって特定されるＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよびイメージファイルが、プロキシサーバ４０に記憶されていないと判別された場合、キャッシュ判定部２２４は、それらのファイルを特定した不足ファイル送信要求をサーバ１０へ送信する。
【０１７０】
また、キャッシュ判定部２２４は、帳票生成情報ファイルにより示されるＸＲＴファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイルがプロキシサーバ４０に記憶されていると判別した場合、帳票生成情報ファイル中に記述されているそれらのファイルの更新日時情報と、プロキシサーバ４０に記憶されている対応ファイルの更新日時情報とが一致するか否かを判別する。いずれかの構成要素ファイルについて、帳票生成情報ファイルに記述されている更新日時情報と、プロキシサーバ４０に記憶されているファイルの更新日時情報とが一致しないと判別された場合、キャッシュ判定部２２４は、そのファイルを特定した不足ファイル送信要求を、Ｗｅｂブラウザ２２１を介してサーバ１０へ送信する。
【０１７１】
キャッシュ判定部２２４は、送信要求を送信する際に、帳票生成情報ファイル内にキャッシュを禁止するパラメータがあるかどうかを調べ、キャッシュを禁止するパラメータが記述されている場合には、Ｗｅｂブラウザ２２１から送信要求を発信する際に、ＨＴＴＰプロトコルの設定により、プロキシサーバ４０におけるキャッシュを抑止させる。
【０１７２】
図３２は、図３０のサーバ１０および図３１のクライアント２０から構成されている電子帳票システムの動作を説明するためのブロック図である。クライアント２０のユーザが入力装置２１３を操作して所要情報をＷｅｂブラウザ２２１に入力すると、入力内容に対応した帳票データ要求が、Ｗｅｂブラウザ２２１から、アプリケーションサーバ１１７を介して、要求データ解析部１３１に与えられる（矢印Ｅ１）。
【０１７３】
要求データ解析部１３１では、Ｗｅｂブラウザ２２１から与えられる帳票データ要求をもとに、帳票生成情報ファイルを作成する。また、要求データ解析部１３１は、帳票データ要求のユーザが指定したデータ部分に基づき、サーバ１０に蓄積されているユーザデータを特定して、ユーザデータファイルを作成する。そして、要求データ解析部１３１は、帳票生成情報ファイルと、ユーザデータファイルとを、帳票生成情報ファイル読取部１３１１に与える（矢印Ｅ２）。もしも、帳票データ要求に対応する帳票データが、キャッシュ禁止の設定された構成要素データを含む場合には、キャッシュ禁止を表すパラメータがキャッシュ禁止データ設定部１３１３によって帳票生成情報ファイル内に書き込まれる。
【０１７４】
帳票生成情報ファイル読取部１３１１に、帳票生成情報ファイル１４０とユーザデータファイル１５１とが与えられると、記憶装置１１５からＸＭＬパーサと、ＤＯＭファイルまたはＳＡＸファイルとが読み取られ、ＸＭＬアプリケーション１３３が起動する。ＸＭＬアプリケーション１３３は、帳票生成情報ファイルに基づいて、帳票データ要求に対応するＸＲＴファイルの構成要素ファイルのファイル名およびそのファイルの更新日時情報を記憶装置１１５から読み取り（矢印Ｅ３）、更新日時情報付きの帳票生成情報ファイルを作成して、アプリケーションサーバ１１７から、クライアント２０のキャッシュ判定部２２４へと送信する（矢印Ｅ４）。このとき、ユーザデータファイルも併せて送信される。
【０１７５】
帳票生成情報ファイルを受信したキャッシュ判定部２２４は、プロキシサーバ４０に記憶されている構成要素ファイル（ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）のうち、帳票生成情報ファイルに記述されているファイルを特定する。さらに、その特定されたプロキシサーバ４０上の構成要素ファイルの更新日時情報と、帳票生成情報ファイルに示された構成要素ファイルの更新日時情報とが一致する構成要素ファイルを特定し、プロキシサーバ４０に対してその送信を要求する（矢印Ｅ５）。これに応じて、キャッシュ判定部２２４によって特定されて送信要求された構成要素ファイルが、プロキシサーバ４０から、クライアント２０のデータ結合処理部２２９へと与えられる（矢印Ｅ６）。
【０１７６】
また、キャッシュ判定部２２４は、帳票生成情報ファイルに示されている構成要素ファイル（ＤＴＤファイル、ＸＲＴファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）のうち、プロキシサーバ４０から与えられなかった構成要素ファイルを特定した不足ファイル送信要求を、Ｗｅｂブラウザ２２１およびアプリケーションサーバ１１７を介して、要求データ解析部１３１に送信する（矢印Ｅ７）。このとき、プロキシサーバ４０におけるキャッシュの可／不可が、帳票生成情報ファイル中に記述されたパラメータに従って、ＨＴＴＰプロトコルにおいて設定される。
【０１７７】
不足ファイル送信要求を受信した要求データ解析部１３１は、この不足ファイル要求に対応する構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル１２７）を記憶装置１１５から読み取る（矢印Ｅ８）。そして、この読み取った構成要素ファイルを、アプリケーションサーバ１１７から、プロキシサーバ４０およびＷｅｂブラウザ２２１を介して、データ結合処理部２２９に与える（矢印Ｅ９）。不足ファイル送信要求をＷｅｂブラウザ２２１から発信するときのＨＴＴＰプロトコルによって、キャッシュの禁止が設定されていた場合には、サーバ１０から送信されてきた構成要素ファイルは、プロキシサーバ４０にキャッシュされない。キャッシュの禁止が設定されていなかった場合には、サーバ１０から送信されてきた構成要素ファイルは、プロキシサーバ４０にキャッシュされる。
【０１７８】
プロキシサーバ４０にキャッシュされた構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）は、プロキシサーバ４０に接続された全てのクライアント２０が共通して使用することができる。そのため、この電子帳票システム全体で使用される構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）を各クライアント２０に効率良く分配することができる。
【０１７９】
データ結合処理部２２９は、サーバ１０およびプロキシサーバ４０から与えられた構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイル）およびユーザデータファイルを結合することによって、帳票データとしてのＸＲＦファイルを作成する。より具体的には、帳票生成情報ファイルに記述されているＸＲＴファイルを取得し、このＸＲＴファイルに部品ＸＲＴファイルやイメージデータなどを結合させ、各フィールドに対応したユーザデータを結合することによって、ＸＲＦファイルが作成される。
【０１８０】
こうして作成されたＸＲＦファイルは、ＸＲＦリーダ２２２に与えられるようになっている（矢印Ｅ１０）。ＸＲＦファイルを受け渡されたＸＲＦリーダ２２２は、ＸＲＦファイルをイメージデータに展開することによって帳票画像を作成して、その表示を行う。この帳票画像の表示が行われているときに、入力装置２１３から所定の印刷指示操作が行われると、帳票画像に対応する印刷データが作成されて、プリンタドライバ２２３を介して、プリンタ３０へと送信される（矢印Ｅ１１）。これにより、プリンタ３０からその帳票画像を担持した用紙が出力される。
【０１８１】
なお、サーバ１０からクライアント２０へ帳票生成情報ファイルおよびユーザデータファイルを送信する代わりに、実データを伴わないＸＲＦファイルを送信してもよい。すなわち、通常のＸＲＦファイルは、フォームファイルであるＸＲＴファイルと、これにリンクされる部品ＸＲＴファイル、外部リソースファイルおよびユーザデータなどの実データを有しているが、これらの実データを省いたＸＲＦファイルを帳票生成情報ファイルの代わりに用いることもできる。むろん、この場合のＸＲＦファイルには、その構成要素ファイルのファイル名と、それらのファイルの各更新日時情報と、必要に応じてキャッシュ禁止設定のためのパラメータが記述されることになる。
【０１８２】
また、ＸＲＦファイルの構成要素データのキャッシュは、クライアント２０において行うこともできる。たとえば、クライアント２０の記憶装置２１７内にキャッシュ領域を設け、このキャッシュ領域をキャッシュ手段として用いて、帳票データ（ＸＲＦファイル）の構成要素ファイルをキャッシュするようにしてもよい。この場合には、帳票生成情報ファイル中におけるキャッシュ禁止設定のためのパラメータに従い、クライアント２０の内部処理によって、キャッシュするかどうかが決められることになる。ユーザデータのキャッシュは一般に不要であるから、クライアント２０側のアプリケーションの設定により、ユーザデータのキャッシュを行わないようにしておけばよい。
【０１８３】
ただし、プロキシサーバの方が一般に保存容量が大きいからより多くのキャッシュデータを保存でき、キャッシュの効率が増加する。また、複数のクライアント２０が共通のキャッシュ領域を共有することになるから、個々のクライアント２０でキャッシュを行う場合に比較して、キャッシュの効率が良くなる。
【０１８４】
なお、キャッシュするデータをＷｅｂブラウザからＨＴＴＰプロトコルを利用して取得すると、プロキシサーバを利用している場合には、取得したデータは自動的にプロキシサーバにキャッシュされるのであるが、ＨＴＴＰプロトコルを用いて、プロキシサーバにキャッシュをさせない設定を行うことができる。
１２．クライアントにおける描画オブジェクトの特性変更
図３３は、図２９の構成の電子帳票システムにおいて用いられるサーバ１０の他の構成例を説明するためのブロック図である。この図３３において、上述の図３０に示された各部と同等の機能を有する部分には、図３０の場合と同一符号を付して示す。クライアント２０側の構成は図３１の場合と同様であるので、以下の説明では、図３１を併せて参照する。
【０１８５】
この実施形態では、クライアント２０において、ユーザデータに応じたプロパティを有する描画オブジェクトを帳票フォームに埋め込む処理が行われ、その描画オブジェクトを埋め込んだ帳票データであるＸＲＦファイルがクライアント２０において作成される。
【０１８６】
サーバ１０側の業務アプリケーションは、要求データ解析部１３１の機能とともに、クライアント２０からの帳票データ要求によって特定されたユーザデータに応じたプロパティを有する描画オブジェクトをＸＲＴファイル中に位置指定して書き込むためのコマンド（描画オブジェクト書込コマンド）を帳票生成情報ファイルに書き込む描画オブジェクト書込コマンド生成部１３８の機能を有している。
【０１８７】
一方、クライアント２０側では、ＸＭＬアプリケーションで構成されるデータ結合処理部２２９によって、帳票生成情報ファイル中の描画オブジェクト書込コマンドが解釈されて実行される。これにより、ＸＲＴファイルに対して、当該コマンドにおいて指定された描画オブジェクトのプロパティ（配置位置、形状、大きさなど）が書き込まれる。つまり、データ結合処理部２２９は、描画オブジェクト書込コマンドを解釈し、描画オブジェクトをＸＲＴファイルに書き込む機能を有する。
【０１８８】
図３４は、図３３のサーバ１０および図３１のクライアント２０から構成されている電子帳票システムの構成を説明するためのブロック図である。クライアント２０のユーザが入力装置２１３を操作して所要情報をＷｅｂブラウザ２２１に入力すると、入力内容に対応した帳票データ要求が、Ｗｅｂブラウザ２２１から、アプリケーションサーバ１１７を介して、要求データ解析部１３１に与えられる（矢印Ｄ１）。
【０１８９】
要求データ解析部１３１では、Ｗｅｂブラウザ２２１から与えられる帳票データ要求をもとに、帳票生成情報ファイルを作成する。また、要求データ解析部１３１は、帳票データ要求によって特定されるユーザデータを記憶装置１５から読み出して、ユーザデータファイルを作成する。
【０１９０】
また、帳票データ要求に対応する帳票フォーム（ＸＲＴファイル）が、ユーザデータに応じてプロパティを定めた描画オブジェクトを埋め込むべき帳票フォームである場合、描画オブジェクト書込コマンド生成部１３８は、要求データ解析部１３１からユーザデータを得て（矢印Ｄ３）、このユーザデータに対応したプロパティの描画オブジェクトを帳票フォーム中に配置を指定して埋め込むための描画オブジェクト書込コマンドを帳票生成情報ファイルに書き込む（矢印Ｄ４）。
【０１９１】
もしも、帳票データ要求に対応する帳票データが、キャッシュ禁止の設定された構成要素データを含む場合には、キャッシュ禁止データ設定部１３１３（図３４では図示を省略した。）によって、キャッシュ禁止を表すパラメータが帳票生成情報ファイル内に書き込まれる。
【０１９２】
要求データ解析部１３１は、描画オブジェクト書込コマンドや各種のパラメータなどが記述された帳票生成情報ファイルと、ユーザデータファイルとを、帳票生成情報ファイル読取部１３１１に与える（矢印Ｄ５）。
【０１９３】
帳票生成情報ファイル読取部１３１１に、帳票生成情報ファイルとユーザデータファイルとが与えられると、記憶装置１１５から、ＸＭＬパーサと、ＤＯＭファイルまたはＳＡＸファイルとが読み取られ、ＸＭＬアプリケーション１３３が起動する。ＸＭＬアプリケーション１３３は、帳票生成情報ファイル１４０に基づいて、帳票データ要求に対応するＸＲＴファイルの構成要素ファイルのファイル名およびそのファイルの更新日時情報を記憶装置１１５から読み取り（矢印Ｄ６）、更新日時情報付きの帳票生成情報ファイルを作成して、アプリケーションサーバ１１７から、クライアント２０のキャッシュ判定部２２４へと送信する（矢印Ｄ７）。このとき、ユーザデータファイルも併せてクライアント２０へと送信され、データ結合処理部２２９に与えられる。
【０１９４】
帳票生成情報ファイルを受信したキャッシュ判定部２２４は、プロキシサーバ４０に記憶されている構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）のうち、帳票生成情報ファイルに記述されているファイルを特定する。さらに、その特定されたプロキシサーバ４０上の構成要素ファイルの更新日時情報と、帳票生成情報ファイルに示された構成要素ファイルの更新日時情報とが一致する構成要素ファイルを特定し、その送信を要求する（矢印Ｄ８）。これに応じて、プロキシサーバ４０は、キャッシュ判定部２２４によって特定されて送信要求された構成要素ファイルを、クライアント２０のデータ結合処理部２２９に与える（矢印Ｄ９）。
【０１９５】
また、キャッシュ判定部２２４は、帳票生成情報ファイルに示されている構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）のうち、プロキシサーバ４０から与えられなかった構成要素ファイルを特定した不足ファイル送信要求を、Ｗｅｂブラウザ２２１およびアプリケーションサーバ１１７を介して、要求データ解析部１３１に送信する（矢印Ｄ１０）。このとき、個々の構成要素ファイルについて、プロキシサーバ４０におけるキャッシュの可／不可が、ＨＴＴＰプロトコルにおいて設定される。
【０１９６】
不足ファイル送信要求を受信した要求データ解析部１３１は、この不足ファイル要求に対応する構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）を記憶装置１１５から読み取る（矢印Ｄ１１）。そして、この読み取った構成要素ファイルを、アプリケーションサーバ１１７から、プロキシサーバ４０およびＷｅｂブラウザ２２１を介して、データ結合処理部２２９に与える（矢印Ｄ１２）。不足ファイル送信要求をＷｅｂブラウザ２２１から発信するときのＨＴＴＰプロトコルによって、キャッシュの禁止が設定されていた場合には、サーバ１０から送信されてきた構成要素ファイルは、プロキシサーバ４０にキャッシュされず、また、キャッシュの禁止が設定されていなかった場合には、サーバ１０から送信されてきた構成要素ファイルはプロキシサーバ４０にキャッシュされる。
【０１９７】
データ結合処理部２２９は、サーバ１０およびプロキシサーバ４０から与えられた構成要素ファイル（ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルまたは外部リソースファイル）およびユーザデータを結合し、さらに、帳票生成情報ファイル中の描画オブジェクト書込コマンドに従って、ＸＲＴファイル中に新たな描画オブジェクトを書き込むことによって、帳票データとしてのＸＲＦファイルを作成する。
【０１９８】
作成されたＸＲＦファイルは、ＸＲＦリーダ２２２に与えられるようになっている（矢印Ｄ１８）。ＸＲＦファイルを受け渡されたＸＲＦリーダ２２２は、ＸＲＦファイルをイメージデータに展開することによって帳票画像を作成して、その表示を行う。この帳票画像の表示が行われているときに、入力装置２１３から所定の印刷指示操作が行われると、帳票画像に対応する印刷データが作成されて、プリンタドライバ２２３を介して、プリンタ３０へと送信される（矢印Ｄ１９）。これにより、プリンタ３０からその帳票画像を担持した用紙が出力される。このようにして、ユーザデータに応じたプロパティ（とくに形態）を有する描画オブジェクトが埋め込まれた状態の帳票を得ることができる。
【０１９９】
また、クライアント２０側では、既存の描画オブジェクトのプロパティを変更する処理ではなく、帳票生成情報ファイル中のコマンドに基づいて新たな描画オブジェクトを生成する処理がＸＭＬアプリケーションによって行われるようになっているから、ビジネスロジックを必要としない。したがって、複数のクライアント２０におけるプログラムの保守および管理が容易になる。
【０２００】
しかも、プロキシサーバ４０をキャッシュとして利用し、ＸＲＦファイルの構成要素データをプロキシサーバ４０から取得し、クライアント２０においてＸＲＦファイルを作成する構成であるので、ネットワークの負荷を著しく軽減することができる。
【０２０１】
なお、この構成例の場合にも、サーバ１０からクライアント２０へ帳票生成情報ファイルを送信する代わりに、実データを伴わないＸＲＦファイルを送信してもよい。
【０２０２】
また、ＸＲＦファイルの構成要素データのキャッシュをクライアント２０において行うようにしてもよい。
１３．ユーザの認証が可能な実施形態
図３５は、この発明のさらに他の実施形態におけるサーバ１０の構成例を説明するためのブロック図である。図３５において、上述の図４に示された各部と同等の構成部分には、図４の場合と同一符号を付して示し、その説明を省略する。
【０２０３】
この実施形態の電子帳票システムは、上述の図２９に示された構成と同様な全体構成を有している。ただし、この実施形態の電子帳票システムでは、帳票データの要求や出力ができるクライアント端末が予め設定され、クライアントの認証を行うことによって、特定の端末以外では帳票データの要求や帳票の出力を制限できるようになっている。
【０２０４】
サーバ１０には、業務アプリケーションの機能処理部としての認証部１３１４およびログ作成部１３１５が備えられており、これらは制御部１３０によって制御されている。
【０２０５】
認証部１３１４は、記憶装置１１５に予め記憶された、クライアント２０の管理者の「ユーザ名」および「パスワード」を参照する。そして、サーバ１０とクライアント２０とのインターネットを介する接続が確立されている間に、クライアント２０からクライアント２０の管理者の「ユーザ名」および「パスワード」がサーバ１０に与えられると、認証部１３１４は、クライアント２０から与えられた「ユーザ名」および「パスワード」が、記憶装置１１５に記憶されている「ユーザ名」および「パスワード」と一致するか否かを判別する。それらが一致すると判別されると、クライアント２０の管理者は、入力装置２１３から所定の操作を行うことによって、そのクライアント２０に提供を許可する帳票の設定を行うことができる。すなわち、特定のクライアント２０を、特定の帳票を出力するための端末として設定できる。
【０２０６】
このような設定が行われると、認証部１３１４は、そのクライアント２０に当該帳票の帳票データの送信を行うことを許可する送信許可情報であるＣｏｏｋｉｅを送信する。このＣｏｏｋｉｅは、サーバ１０から、クライアント２０に送信されると、クライアント２０の記憶装置２１７に記憶されるようになっている。Ｃｏｏｋｉｅを受信したクライアント２０が、そのＣｏｏｋｉｅの送信元であるサーバと再びインターネットを介して接続されると、クライアント２０は、Ｃｏｏｋｉｅをそのサーバ１０に与えるようになっている。
【０２０７】
また、ユーザが、帳票データの送信許可を表すＣｏｏｋｉｅを有するクライアント２０を使用することによって、サーバ１０に接続すると、そのＣｏｏｋｉｅは、アプリケーションサーバ１１７を介して認証部１３１４に与えられる。そして、認証部１３１４は、クライアント２０から送信されてくるＣｏｏｋｉｅの内容に応じて、そのクライアント２０に提供することのできる帳票データを提供し、その他の帳票データについては、送信を制限する。
【０２０８】
一方、帳票データの送信許可を表すＣｏｏｋｉｅを有するクライアント２０と、サーバ１０とのインターネットを介する接続が確立されている間に、クライアント２０からクライアント２０の管理者の「ユーザ名」および「パスワード」がサーバ１０に与えられることがある。このとき、認証部１３１４は、クライアント２０から与えられた「ユーザ名」および「パスワード」が、認証部１３１４に記憶されている「ユーザ名」および「パスワード」と一致するか否かを判別する。その一致が確認された後、クライアント２０の管理者が入力装置２１３から所定の解除操作を行うと、そのクライアント２０への提供が許可されていた帳票データの送信許可の設定を解除することができるようになっている。その送信許可設定が解除されると、認証部１３１４は、そのクライアント２０に、帳票データの送信許可設定を解除したＣｏｏｋｉｅを送信することができる。
【０２０９】
ユーザが、帳票画像の送信許可設定が解除された状態（すなわち、送信許可設定のされていない状態）のＣｏｏｋｉｅを有する（またはそのようなＣｏｏｋｉｅを有しない）クライアント２０を使用することによって、サーバ１０に接続すると、帳票データの送信許可設定のない当該Ｃｏｏｋｉｅは、アプリケーションサーバ１１７を介して認証部１３１４に与えられる（またはＣｏｏｋｉｅが与えられない）。帳票データの送信許可設定のないＣｏｏｋｉｅを受信した（またはＣｏｏｋｉｅを受信しなかった）認証部１３１４は、要求された帳票データをクライアント２０に送信することを禁止する。
【０２１０】
ログ作成部１３１５は、ＸＭＬアプリケーション１３３によって作成されたＸＲＦファイルやＰＤＦファイルをクライアント２０へ送信した日時情報を記憶装置１１５に記憶させることができる。つまり、サーバ１０からクライアント２０へと送信された帳票データファイルの送信記録（ログ）を作成することができる。
【０２１１】
図３６は、この実施形態におけるクライアント２０の構成例を説明するためのブロック図である。この図３６において、図６に示された各部と同等の構成部分には図６の場合と同一符号を付して示し、その説明を省略する。
【０２１２】
この構成では、クライアント２０に記憶装置２１７が設けられている。記憶装置２１７は、サーバ（サーバ１０を含む）から制御部２２０に与えられるＣｏｏｋｉｅを記憶しておくことができる。また、以前にＣｏｏｋｉｅが与えられたサーバ（サーバ１０を含む）との間の接続が再び確立された場合には、制御部２２０は、そのサーバから以前に与えられたＣｏｏｋｉｅを記憶装置２１７から読み出して、そのサーバに送信する。
【０２１３】
クライアント２０にはさらに、表示制御部２２５と、ログ作成部２２６と、出力情報表示禁止部２２７と、ユーザ認証部２２８とが備えられており、これらは制御部２２０によって制御されている。
【０２１４】
表示制御部２２５は、帳票データ要求がサーバ１０に送信されて帳票印刷の指示がされてから、その帳票データ要求に対応する帳票画像がプリンタ３０によって印刷され終わるまでの間、表示装置２１４の表示画面をシステムモーダル画面に固定させ、入力装置２１３から制御部２３０への操作信号を無効化する。
【０２１５】
ログ作成部２２６は、帳票データ要求が当該クライアント２０からサーバ１０に送信された日時情報と、サーバ１０から与えられるＸＲＦファイルやＰＤＦファイルを受信した日時情報と、印刷データをプリンタ３０に送信した日時情報と、プリンタ３０から与えられる印刷データの印刷完了を示す印刷終了信号を受信した日時情報と、その帳票種類の情報とを含むログ（帳票出力記録）を記憶装置２１７に記憶させることができる。また、クライアント２０の管理者は、入力装置２１３から所定の操作を行うことによって、記憶装置２１７に記憶されているログを閲覧することができるようになっている。
【０２１６】
出力情報表示禁止部２２７は、ＸＲＦファイル内のパラメータの設定に応じて、帳票画像の表示を禁止するための制御を行う。
【０２１７】
クライアント２０のユーザのユーザ名およびパスワードは、記憶装置２１７に記憶され、ユーザ認証部２２８によって管理されるようになっている。そして、入力装置２１３から入力されるユーザ名およびパスワードが、記憶装置２１７に記憶されているユーザ名およびパスワードに一致するか否かを判別することができるようになっている。入力装置２１３から入力されたユーザ名およびパスワードが、ユーザ認証部２２８によって、記憶装置２１７に記憶されているユーザ名およびパスワードに一致すると判別されない限り、ユーザはクライアント２０を使用して帳票の出力を行うことができないようになっている。
【０２１８】
図３７は、図３５のサーバ１０および図３６のクライアント２０から構成される電子帳票システムの概念的な構成を説明するためのブロック図であり、図３８は、帳票データ送信許可の設定を受け付けるための受付画面をＷｅｂブラウザ２２１により表示した例を示す図であり、図３９は、帳票データ要求の入力を受け付けるための受付画面（メニュー画面）をＷｅｂブラウザ２２１により表示した例を示す図である。
【０２１９】
クライアント２０の管理者は、Ｗｅｂブラウザ２２１のＵＲＬ入力部にサーバ１０のＵＲＬを入力して、入力装置２１３から所定の操作を行うことによって、アプリケーションサーバ１１７からＨＴＭＬファイル等を受信して、Ｗｅｂブラウザ２２１の表示部２３１に、図３８に示すような表示を行わせることができる。図３８は、サーバ１０からクライアント２０へ提供する領収書の帳票データの送信許可設定を受け付けるための受付画面である。表示部中央付近には、クライアント２０の管理者のユーザ名を入力させるためのユーザ名入力部２３６と、クライアント２０の管理者のパスワードを入力させるためのパスワード入力部２３７とが表示されている。ユーザ名入力部２３６およびパスワード入力部２３７の下部には、「端末に指定」ボタン２３８と、「端末指定解除」ボタン２３９とが表示されている。また、この受付画面において、Ｗｅｂブラウザ２２１にはポインタ（図示せず）が表示されており、ユーザが入力装置２１３（主にポインティングデバイス）の操作を行うことによって、このポインタをボタン２３８または２３９上へ移動し、ボタン２３８または２３９を押す（クリック）ことができるようになっている。
【０２２０】
ユーザ名入力部２３６にクライアント２０の管理者のユーザ名が、パスワード入力部２３７にクライアント２０の管理者のパスワードが、それぞれ入力されて、「端末に指定」ボタン２３８が押されると（矢印Ｆ１）、認証部１３１４は、認証処理を行い、ユーザ名およびパスワードが事前に登録されたものと一致することを条件に、領収書の帳票データの送信許可を表すＣｏｏｋｉｅ（端末識別情報としての登録ＩＤを含む）を、そのクライアント２０へと送信するようになっている（矢印Ｆ２）。クライアント２０は、そのＣｏｏｋｉｅを記憶装置２１７に記憶するようになっている。これにより、当該クライアント２０は、領収書の帳票データの受信が可能な端末として設定されることになる。なお、ユーザの認証は、指紋や掌紋等を用いたバイオメトリック認証やＩＤカードを用いた認証により行うようにしてもよい。
【０２２１】
一方、クライアント２０の記憶装置２１７に領収書の帳票データの送信許可を表すＣｏｏｋｉｅが記憶されている時に、そのクライアント２０によってユーザ名入力部２３６にクライアント２０の管理者のユーザ名が、パスワード入力部２３７にクライアント２０の管理者のパスワードがそれぞれ入力されて、「端末指定解除」ボタン２３９が押されると（矢印Ｇ１）、認証部１３１４は、認証処理を実行し、ユーザ名およびパスワードが事前に登録されたものと一致することを条件に、領収書の帳票データの送信許可を解除した内容のＣｏｏｋｉｅを、そのクライアント２０へと送信するようになっている（矢印Ｇ２）。クライアント２０は、そのＣｏｏｋｉｅを記憶装置２１７に記憶するようになっている。これにより、当該クライアント２０は、領収書の帳票データの受信ができない状態となる。
【０２２２】
ユーザが、Ｗｅｂブラウザ２２１のＵＲＬ入力部２３０にサーバ１０のＵＲＬを入力すると、記憶装置２１７に記憶されている全てのＣｏｏｋｉｅが認証部１３１４に送信される（矢印Ｆ３）。認証部１３１４は、クライアント２０から与えられるＣｏｏｋｉｅに応じて、ＨＴＭＬ等で記述されたファイルを選択するようになっている。そして、アプリケーションサーバ１１７は、そのＨＴＭＬ等で記述されたファイルをクライアント２０へと送信する（矢印Ｆ４）。したがって、クライアント２０からサーバ１０に与えられるＣｏｏｋｉｅの内容に応じて、クライアント２０の表示装置２１４に表示される内容が異なるようになっている。
【０２２３】
たとえば、サーバ１０から与えられたＣｏｏｋｉｅを何も有していないクライアント２０、または領収書帳票データの送信許可のないＣｏｏｋｉｅが記憶装置２１７に記憶されているクライアント２０とサーバ１０とがインターネットを介して接続されると、クライアント２０のＷｅｂブラウザ２２１の表示部２３１には、図３９(a)に示すような画面が表示される。図３９(a)の画面では、そのクライアント２０には領収書の帳票データの提供ができない旨が表示されている。その後、そのクライアント２０のＷｅｂブラウザ２２１の表示部２３１には、図３９(b)に示すような画面が表示される。
【０２２４】
図３９(b)には帳票の種類を選択するメインメニュー画面の例が示されており、この例では、Ｗｅｂブラウザ２２１の表示部２３１には、「提案書」ボタン２３１０、「申込書」ボタン２３１１、「領収書」ボタン２３１２および「受領書」ボタン２３１３が表示されている。「領収書」ボタン２３１２は、たとえば、グレーアウト（操作不能状態を表す表示状態。図中では斜線を付して表す。）されて操作不能状態とされていて、押すことができないようになっている。つまり、ユーザは、「領収書」ボタン２３１２にリンクされたＷｅｂページに入ることができず、領収書の帳票データ要求をサーバ１０に送信することができない。なお、「領収書」ボタン２３２１を操作不能とする代わりに、認証されていない端末から「領収書」ボタン２３２１が操作された場合に、サーバ１０から、領収書印刷不可の端末であることを通知する画面を表示させるためのＨＴＭＬファイル等を送出するようにしてもよい。
【０２２５】
一方、帳票データの送信許可が設定されたＣｏｏｋｉｅを有するクライアント２０のＷｅｂブラウザ２２１のＵＲＬ入力部２３０にサーバ１０のＵＲＬを入力すると、図３９(c)に示すような画面が表示される。図３９(c)の画面では、Ｗｅｂブラウザ２２１の表示部２３１には、「提案書」ボタン２３１０、「申込書」ボタン２３１１、「領収書」ボタン２３１２および「受領書」ボタン２３１３が表示されている。いずれのボタンも操作可能状態とされ、ユーザは、サーバ１０から提供可能な全ての帳票データ（提案書、申込書、領収書および受領書）の要求をサーバ１０に送信することができる。
【０２２６】
このように、クライアント２０からサーバ１０へと送信されるＣｏｏｋｉｅの内容に応じて、帳票データ要求が制限されることがある。ユーザは、この制限の範囲内において、帳票データ送信要求を要求データ解析部１３１へと送信することができる（図３７の矢印Ｆ５）。
【０２２７】
要求データ解析部１３１に帳票データ要求が与えられると、要求データ解析部１３１は、この帳票データ要求に対応する帳票データを生成するための情報（コマンドやパラメータ）をＸＭＬで記述した帳票生成情報ファイルを作成する。また、要求データ解析部１３１は、帳票データ要求に対応するユーザデータを記憶装置１１５から読み出してユーザデータファイルを作成する。
【０２２８】
要求データ解析部１３１によって生成された帳票生成情報ファイルおよびユーザデータファイルは、データ収集・結合処理部１３２に送信される（矢印Ｆ６，Ｆ７）。
【０２２９】
データ収集・処理結合部１３２は、帳票生成情報ファイルとユーザデータファイルとを受信すると、ＸＭＬパーサと、ＤＯＭファイルまたはＳＡＸファイルとを記憶装置１１５から読み取ることによって（矢印Ｆ８）、ＸＭＬアプリケーション１３３を起動させる。
【０２３０】
帳票生成情報ファイルの出力ファイルモード記述部に、帳票データの出力ファイルモードとしてＰＤＦファイル形式が指定されていなければ、ＸＭＬアプリケーション１３３のＸＲＦファイル作成部１３４は、帳票生成情報ファイルに基づいて、ＸＲＴファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイル１２７を必要に応じて記憶装置１１５から読み取って収集し（矢印Ｆ９）、それらを結合し、さらにユーザデータを結合することによって、ＸＲＦファイルを作成する。
【０２３１】
作成されたＸＲＦファイルは、アプリケーションサーバ１１７から、クライアント２０へ送信され（矢印Ｆ１３）、ＸＲＦリーダ２２２によって処理される。ＸＲＦリーダ２２２は、ＸＲＦファイルから帳票画像を作成する。そして、その帳票画像に対応する印刷データを作成して、プリンタドライバ２２３を介して、プリンタ３０へと送信する（矢印Ｆ１４）。
【０２３２】
帳票生成情報ファイル１４０の出力ファイルモード記述部１４１１に、帳票データの出力ファイルモードとしてＰＤＦファイル形式が指定されている場合、ＸＭＬアプリケーション１３３のＰＤＦファイル作成部１３５は、帳票生成情報ファイルに基づいて、ＸＲＴファイルファイル、ＤＴＤファイル、フィールド情報、部品ＸＲＴファイルおよび外部リソースファイル１２７を必要に応じて記憶装置１１５から読み取って収集し（矢印Ｆ９）、それらを結合し、さらにユーザデータを結合して、帳票のイメージデータに展開することにより、ＰＤＦファイルを作成する。このＰＤＦファイルは、アプリケーションサーバ１１７を介して、クライアント２０のＷｅｂブラウザ２２１に与えられるようになっている（矢印Ｆ１１）。Ｗｅｂブラウザ２２１がこの受信したＰＤＦファイルを表示しているときに、ユーザによって入力装置２１３の所定の操作が行われると、ＰＤＦ形式の帳票データに対応する印刷データが作成されて、プリンタドライバ２２３から、プリンタ３０へ送信される（矢印Ｆ１２）。
【０２３３】
ＸＲＦファイルまたはＰＤＦファイルがアプリケーションサーバ１１７からクライアント２０へ送信されると、ログ作成部１３１５は、ＸＲＦファイルまたはＰＤＦファイルをクライアント２０へ送ったことを表すログを作成して記憶装置１１５に書き込む。このログには、日時、ジョブ名、帳票番号、帳票名、枚数、証跡管理の要否などが含まれる。
【０２３４】
図４０は、クライアント２０の制御動作を説明するためのフローチャートである。クライアント２０は、ユーザ認証部２２８によって、入力装置２１３から入力されるユーザ名およびパスワードが、記憶装置２１７に記憶されているユーザ名およびパスワードに一致しない限り、帳票出力のための操作を行うことができないようになっている。入力装置２１３から入力されるユーザ名およびパスワードと、記憶装置２１７に記憶されているユーザ名およびパスワードとが一致すると（ステップＳ１０）、制御部２２０によって、プリンタ３０が印刷可能状態か否かが判別されるようになっている（ステップＳ１１）。プリンタ３０が印刷可能状態でなければ（ステップＳ１１でＮｏ）、表示装置２１４にエラー表示がされ（ステップＳ２８）、強制終了する。この場合、ユーザは、プリンタ３０が印刷可能となるまで待つか、管理者に連絡してプリンタ３０の異常を知らせるか、または帳票の印刷をキャンセルする。
【０２３５】
プリンタ３０が印刷可能状態である場合（ステップＳ１１でＹｅｓ）、ユーザの所望する帳票データ要求の入力が受け付けられ、その入力された帳票データ要求がサーバ１０へと送信される（ステップＳ１２）。そして、ログ作成部２２６によって、送信ログが作成されて記憶装置２１７に記憶される（ステップＳ１３）。この送信ログは、帳票データ要求をサーバ１０へと送信した日時、ジョブ名、帳票番号、帳票名、枚数、証跡管理の要否などの情報を含む。
【０２３６】
その後、ＸＲＦファイル中のパラメータの設定に従い、出力情報表示設定部２２５によって、表示装置２１４の表示画面は、システムモーダル画面に固定され（ステップＳ１４）、一切の入力操作を受け付けず、帳票印刷をキャンセルできない状態とされて、バックグラウンドで印刷処理が行われる。システムモーダル画面は、ユーザが所望する帳票データの要求を入力した画面であってもよい。
【０２３７】
このように、ユーザは、帳票データの要求を入力した後に、クライアント２０を操作することができない。したがって、帳票の印刷途中で印刷処理をキャンセルして未印字状態の帳票や印刷が不完全な状態の帳票を出力したりすることはできず、このような未印字状態の帳票等が不正使用されたりすることを防止できる。
【０２３８】
帳票データ要求がサーバ１０に送信された後に、クライアント２０はサーバ１０からＸＲＦファイルを受信し（ステップＳ１５）、ログ作成部２２６によって、ＸＲＦファイルまたはＰＤＦファイルの受信に関する受信ログが作成されて記憶装置２１７に記憶される（ステップＳ１６）。この受信ログは、受信日時、ジョブ名、帳票番号、帳票名、枚数、証跡管理の要否などの情報を含む。
【０２３９】
一方、ＸＲＦファイル内のパラメータの設定に従い、出力情報表示禁止部２２７によって、帳票画像の表示が禁止される（ステップＳ１７）。これにより、表示装置２１４に表示された帳票画像をコピーして帳票を作成するなどという不正を防止できる。
【０２４０】
その後、ＸＲＦリーダ２２２が起動されて、ＸＲＦリーダ２２２によって、そのＸＲＦファイルから帳票画像が自動的に作成される（ステップＳ１８）。そして、制御部２２０によって、プリンタ３０が印刷可能であるか否か判別される（ステップＳ１９）。プリンタ３０が印刷不可能である場合は（ステップＳ１９でＮｏ）、システムモーダル画面が終了され（ステップＳ２７）、入力操作が可能な状態となる。そして、エラー表示がされ（ステップＳ２８）、印刷処理が強制終了する。
【０２４１】
プリンタ３０が印刷可能である場合は（ステップＳ１９でＹｅｓ）、ＸＲＦリーダ２２２によって、帳票画像に対応する印刷データが作成されて、その印刷データがプリンタ３０へ送出される（ステップＳ２０）。そして、ログ作成部２２６によって、印刷データ送出ログが作成されて記憶装置２１７に格納される（ステップＳ２３１）。印刷データ送出ログは、印刷データ送出が完了（スプールからプリンタへのデータ出力完了）した日時、ジョブ名、スプール出力結果などの情報を含む。
【０２４２】
一方、バックグラウンド処理によって、印刷データがプリンタ３０に送出された後、プリンタ３０からその印刷データを印刷した旨の印刷完了通知がクライアント２０に与えられる（ステップＳ２２）。
【０２４３】
そして、ログ作成部２２６によって、印刷完了ログが作成されて記憶装置２１７に記憶される（ステップＳ２３）。そして、システムモーダル画面が終了し（ステップＳ２５）、入力操作が可能な状態に戻る。印刷完了ログは、印刷完了通知を受信した日時、ジョブ名、枚数、トレイ情報、用紙情報、出力結果などの情報を含む。
【０２４４】
上記のように印刷処理の各ステップでログを作成しているので、印刷処理中に不具合が発生したときに、どの時点で不具合が発生したのかを特定することができる。これにより、たとえば、印刷が本当にできなかったのか、それとも、印刷ができたにもかかわらず出力された用紙が紛失したのかを特定でき、帳票の不正使用を効果的に防止できる。
【０２４５】
なお、Ｃｏｏｋｉｅを用いて端末を認証する代わりに、領収書等の特定の帳票の印刷を許可した端末であることを判定するためのファイルを記憶装置２１７に記憶させておき、appletにより当該ファイルが端末に存在するかどうかを判別することにより端末の認証を行うようにしてもよい。
１４．その他の実施形態
上述の実施形態では、サーバ１０とクライアント２０とは、インターネットを介してデータのやり取りを行うとしたが、会社等が有する専用のネットワークを用いてデータのやり取りを行う構成であってもよい。
【０２４６】
また、同一ビル内や同一オフィス内にクライアント２０が多数存在する場合、サーバ１０はそのビルやオフィス内に設置されて、そのビル内やオフィス内のクライアント２０を管理する構成であってもよい。このとき、サーバ１０とクライアント２０とは、インターネットを介してデータのやり取りを行うのではなく、ＬＡＮを介してデータのやりとりを行う構成であってもよい。
【０２４７】
さらに、サーバ１０はインターネット等のネットワークに１台のみ存在している必要はなく、複数のサーバ１０がネットワークに接続されている構成であってもよい。
【０２４８】
その他、特許請求の範囲に記載された事項の範囲で種々の設計変更を施すことが可能である。
【図面の簡単な説明】
【図１】この発明の一実施形態に係る電子帳票システムの全体構成を示すブロック図である。
【図２】サーバの電気的な構成を示すブロック図である。
【図３】サーバの記憶装置に記憶されているファイルを説明するためのブロック図である。
【図４】サーバの機能的な構成を説明するためのブロック図である。
【図５】クライアントの電気的な構成の一例を示すブロック図である。
【図６】クライアントの機能的構成を説明するためのブロック図である。
【図７】サーバおよびクライアントにより構成される電子帳票システムの概念的な構成を説明するためのブロック図である。
【図８】帳票データ要求の入力を受け付けるための受付画面をＷｅｂブラウザにより表示した例を示す図である。
【図９】要求データ解析部によって帳票生成情報ファイルとして作成されるＸＭＬファイルの一例を示す図である。
【図１０】帳票生成情報ファイルおよびユーザデータファイルを受信したデータ収集・結合処理部の動作を説明するためのフローチャートである。
【図１１】ＸＭＬアプリケーションの動作を説明するためのフローチャートである。
【図１２】ＸＲＦファイルの主要な構成要素の１つであるＸＲＴファイルの構成を説明するための概念図である。
【図１３】ＸＲＴファイルの構成を説明するためのブロック図である。
【図１４】ＸＲＴファイルの具体的な構成例を示す図である。
【図１５】ＸＲＦファイルの構成を説明するためのブロック図である。
【図１６】ＸＲＦファイルに基づいて帳票画像が生成される過程を説明するための図解的な流れ図である。
【図１７】部品ＸＲＴファイルの典型的な利用態様を説明するための概念図である。
【図１８】ＸＲＦファイルを受信したＸＲＦリーダの表示例を示す図である。
【図１９】部品ＸＲＴファイルの編集例を説明するための概念図である。
【図２０】部品ＸＲＴファイルを用いることの効果を説明するための概念図である。
【図２１】ユーザデータに応じて帳票の外観を変更するための機能を備えたサーバ構成例を説明するためのブロック図である。
【図２２】ユーザデータに応じたイメージファイルの選択を説明するための概念図である。
【図２３】サーバからクライアントへと提供される帳票データ（ＸＲＦファイル）の一例を説明するための概念図である。
【図２４】ユーザデータに応じて帳票の外観を異ならせるために用いられるサーバの他の構成例を説明するためのブロック図である。
【図２５】長方形の図形に対応した描画オブジェクトのプロパティ編集ダイアログの表示例を示す図である。
【図２６】ユーザデータの値に応じて描画オブジェクトのプロパティが変更されることによる長方形図形の変形を説明するための概念図である。
【図２７】サーバからクライアントへ提供される帳票データの一例を説明するための概念図である。
【図２８】ユーザデータに応じて描画オブジェクトのプロパティを変更する機能を実現した電子帳票システムの構成を説明するためのブロック図である。
【図２９】この発明の他の実施形態に係る電子帳票システムの全体構成を示すブロック図である。
【図３０】この実施形態におけるサーバの構成例を説明するためのブロック図である。
【図３１】この実施形態の電子帳票システムにおけるクライアントの構成例を説明するためのブロック図である。
【図３２】図３０のサーバおよび図３１のクライアントから構成されている電子帳票システムの動作を説明するためのブロック図である。
【図３３】図２９の構成の電子帳票システムにおいて用いられるサーバの他の構成例を説明するためのブロック図である。
【図３４】図３３のサーバおよび図３１のクライアントから構成されている電子帳票システムの構成を説明するためのブロック図である。
【図３５】この発明のさらに他の実施形態におけるサーバの構成例を説明するためのブロック図である。
【図３６】図３５の実施形態におけるクライアントの構成例を説明するためのブロック図である。
【図３７】図３５のサーバおよび図３６のクライアントから構成される電子帳票システムの概念的な構成を説明するためのブロック図である。
【図３８】帳票データ送信許可の設定を受け付けるための受付画面をＷｅｂブラウザにより表示した例を示す図である。
【図３９】帳票データ要求の入力を受け付けるための受付画面（メニュー画面）をＷｅｂブラウザにより表示した例を示す図である。
【図４０】クライアントの制御動作を説明するためのフローチャートである。
【符号の説明】
１０ サーバ
１１５ 記憶装置
１１７ アプリケーションサーバ
１２００ 部品サーバ
１３０ 制御部
１３１ 要求データ解析部
１３２ データ収集・結合処理部
１３３ ＸＭＬアプリケーション
１３４ ＸＲＦファイル作成部
１３５ ＰＤＦファイル作成部
１３６ イメージファイル設定部
１３７ プロパティ変更処理部
１３８ 描画オブジェクト書込コマンド生成部
１３１３ キャッシュ禁止データ設定部
１３１１ 帳票生成情報ファイル読取部
１３１４ 認証部
１３１５ ログ作成部
２０ クライアント
２１３ 入力装置
２１４ 表示装置
２１５ ネットワークインタフェース
２２０ 制御部
２２１ Ｗｅｂブラウザ
２２２ ＸＲＦリーダ
２２２ａ 印刷制御部
２２３ プリンタドライバ
２２４ キャッシュ判定部
２２５ 表示制御部
２２６ ログ作成部
２２７ 出力情報表示禁止部
２２８ ユーザ認証部
２２９ データ結合処理部
３０ プリンタ
４０ プロキシサーバ
５０ ＬＡＮ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a form issuing device for issuing various forms represented by receipts, invoices, inventory management tables, life insurance proposals, tickets and other securities, and an electronic form system using the same. .
[0002]
[Prior art]
A fixed form data consisting of complex background images, ruled lines, characters, images, etc. is stored on a server on the Internet, and user data to be imported into the fields set on the form data is stored. There has been proposed an electronic report system configured to transmit information for identification from a personal computer connected to the Internet to the server (for example, Patent Document 1). The server creates the image data of the form by taking the user data into the fields of the form and overlaying the form, and the image data of the form is transmitted to the personal computer via the Internet. The user of the personal computer can obtain a desired form by printing the received form image data with a printer.
[0003]
[Patent Document 1]
JP-A-2002-163596
[0004]
[Problems to be solved by the invention]
The form is created in page units for each required form, and the server embeds user data corresponding to each form to create form image data.
[0005]
Generally, a server stores a plurality of form files corresponding to a plurality of types of forms in a storage device. For example, in a plurality of types of forms issued by one company for customers, there are areas common to the plurality of types of forms, such as a company name portion, a company emblem portion, and a company logo portion. However, since the form is created on a page basis, data is also created for each form for the common part and stored in the storage device. This causes a problem that the storage capacity of the storage device is squeezed.
[0006]
Also, when a common change should be made to the common part of multiple types of form forms, such as a change of company emblem or company name, perform the editing work individually on the form files of multiple types of forms. It was very inefficient and it was difficult to manage whether changes were made without omission.
[0007]
SUMMARY OF THE INVENTION It is an object of the present invention to provide a form issuing apparatus capable of reducing the storage capacity of form forms and facilitating management of a plurality of types of form forms, and an electronic form system using the same.
[0008]
Means for Solving the Problems and Effects of the Invention
According to a first aspect of the present invention, there is provided a form data storage means (115, 1200) for storing a plurality of types of form data (124), and a common form data storage means for a plurality of types of form data. A component data storage means (115, 1200) for storing component data (126, 127) linked to a set component placement area (area area or image area), and a form for receiving a form data request specifying a type of the form Data request receiving means (117, 131), and form data corresponding to the form data request received by the form data request receiving means are read from the form data storage means, and the read form data is read out. The part data linked to the part placement area set in the Reading from the means, a slip issuing apparatus characterized by including the form data generating means for generating form data by combining these continuous form data and the component data (131, 132). It should be noted that the alphanumeric characters in parentheses indicate corresponding components and the like in embodiments described later. Hereinafter, the same applies in this section.
[0009]
According to this configuration, the component data stored in the component data storage unit is linked to the component placement area commonly set in a plurality of types of form data. When a form data request specifying a form type is received, the form data is generated by combining the form data with the component data linked to the component placement area set in the form data. . Therefore, a desired form can be obtained by printing out on paper based on the form data.
[0010]
By storing the component data separately from the form data, the storage capacity can be reduced by the amount of the component data commonly used for a plurality of types of form data. In addition, if necessary editing is performed on the component data, a plurality of types of form forms are substantially edited in a lump, and there is no omission of any change in any of the forms. This facilitates management of the form.
[0011]
Furthermore, since it is not necessary to individually create a common part when creating each form data, it is easy to create the form data.
[0012]
In the invention according to claim 2, the component data storage means stores component form data (126) in which a component arrangement area linked to the component data is set as component data for the form data. 2. The form issuing device according to claim 1, wherein:
[0013]
According to this configuration, for example, a complex form such as a field in which image data, text data, and user data (data that changes for each individual form according to a user's request) are embedded is arbitrarily combined. The component data can be stored as a component form, and such a component form can be combined with the form data. As a result, various types of parts can be stored and managed as part form data separately from the form data.
[0014]
Of course, the component data may be data of a single format such as image data or text data.
[0015]
According to a third aspect of the present invention, the form issuing device is a server (10) connected to a network, and the form data request receiving means is a form sent from a client (20) connected to the network. 3. The apparatus according to claim 1, further comprising means for receiving a data request, wherein said form issuing apparatus further includes means for transmitting said form data to said client via said network. It is a form issuing device described.
[0016]
According to a fourth aspect of the present invention, there is provided the form issuing device according to the third aspect, means (221) connected to the network, for transmitting the form data request to the form issuing device via the network. A client (20) having means (211) for receiving the form data sent from the form issuing device via the network.
[0017]
According to these configurations, the form data is sent from the form issuing device which is the server to the client by requesting the form data from the client to the server via the network, and is output from the printer connected to the client. . Since the form data includes form data managed collectively in the server and component data linked to the form data, any client can issue a form in a unified format.
[0018]
The invention according to claim 1 or 2 can also be used as an independent form issuing device not connected to a network. In this case, for example, a form can be created by generating print data based on the form data generated by the form data generating means and giving the print data to the printing apparatus.
[0019]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
table of contents
1. Overall structure of electronic report system
2. Server configuration
2-1. Server hardware configuration
2-2. Files used for creating form data
2-3. Functional configuration of server
3. Client configuration
3-1. Client hardware configuration
3-2. Functional configuration of client
4. Operation of the entire electronic form system
5. Explanation of form data file (XRF file)
6. Generating report images
7. Usage of part XRT file
8. XRF reader operation
9. Creating a part XRT file
10. Change appearance according to user data
10-1. Selection of image parts according to user data
10-2. Changing the characteristics of drawing objects according to user data
11. An embodiment capable of caching component files of a form
12. Changing the characteristics of drawing objects on the client
13. Embodiment in which user authentication is possible
14． Other embodiments
1. Overall structure of electronic report system
FIG. 1 is a block diagram showing the overall configuration of an electronic form system according to one embodiment of the present invention. This electronic form system can be used, for example, in a business entity such as a company where many business offices (branches and sales offices) are set up in various places, for business use (for internal use, for customers and business partners). This is a system that manages the system in a centralized manner.
[0020]
This form system uses a network such as the Internet, an intranet in a company, a LAN (local area network), and a WAN (wide area network) (hereinafter, the case of the Internet is representatively described, but the same applies to networks of other forms. .), And a plurality of clients 20 also connected to the Internet. The server 10 is a computer capable of performing large-scale processing, and is communicably connected to the Internet. The client 20 is a personal computer installed at each business office, and is communicably connected to the Internet. Therefore, the server 10 and the client 20 can transmit and receive data to and from each other by using the Internet. A printer 30 for printing a form is connected to the client 20. The client 20 and the printer 30 may be connected via a printer cable or may be connected via a local area network so that the printer 30 is shared by a plurality of clients 20 connected to the local area network. It may be.
[0021]
For example, taking the case of an insurance company as an example, it is said that there are 2000 to 3000 forms required for business. In each office, considerable effort is required to manage these forms individually and to unify them among the offices. Therefore, in this electronic form system, the server 10 manages all form forms and provides form data in response to a request from the client 20.
[0022]
When a report is required at each business office, the user operates the client 20 to send a report data request specifying the type of report required and items to be filled in to the server 10 via the Internet. It can be transmitted (arrow A1). The client 20 creates the form data of the form required by the user based on the form data request transmitted from the server 10 and returns it to the client 20 via the Internet (arrow A2). The client 20 that has received the form data can develop the form data into print data and print it with the printer 30. Thus, the user obtains the desired form.
[0023]
With this electronic form system, each business establishment is free from form management work (such as updating), and can easily create a desired form by using the individual client 20. Further, by accessing the server 10 from the client 20, it is possible to grasp in detail the usage status of the form of the entire company. Therefore, by using the client 20, the business status and financial status of the entire company are obtained. Etc. can be grasped.
1. 2. Server configuration
2-1. Server hardware configuration
FIG. 2 is a block diagram illustrating an electrical configuration of the server 10. The server 10 includes a CPU 110, a ROM 111, a RAM 112, an input device 113, a display device 114, a storage device 115, and a communication control device 118, which are connected to each other by a bus 116. The CPU 110 controls transmission and reception of data between the ROM 111, the RAM 112, the input device 113, the display device 114, and the storage device 115 based on a program stored in the ROM 111, and controls the input device 113, the display device 114, It controls the storage device 115 and the communication control device 118, and controls connection to the Internet via the communication control device 118.
[0024]
Since the server 10 may perform a large-scale and complicated process, it is desirable to use a high-performance CPU 110. Further, a configuration using an MPU (microprocessor) instead of the CPU 110 may be used.
[0025]
The input device 113 includes a keyboard, a pointing device, and the like, and an operation signal thereof is provided to the CPU 110. The display device 114 is capable of displaying two-dimensional images, such as a CRT or a liquid crystal display panel, and performs image display according to a display signal from the CPU 110.
[0026]
The storage device 115 includes a hard disk device and the like, and is used as a storage medium for storing data and application programs necessary for the server 10. The CPU 110 can store data in the storage device 115 or read and use data stored in the storage device 115 as necessary.
2-2. Files used for creating form data
FIG. 3 is a block diagram for explaining files stored in the storage device 115. The storage device 115 includes an XML parser 120 for analyzing an Extensible Markup Language (XML) file, and a DOM (Document Object Model) file or SAX (Simple API for XML) for controlling exchange of data between the XML file and the XML application. File 121 is stored. An XML application program operating on the server 10 is also recorded in the storage device 115 and is read and executed by the CPU 110, but is not shown in FIG.
[0027]
The storage device 115 further defines a user database 128 that stores and manages user data as personal data of customers and the like, and fixed image portions (background, layout, image, drawing object, text, barcode, etc.) of the form. XRT file 124, which is a unique format file, a part XRT file 126, which is a unique format file that defines a similar fixed image portion that can be incorporated by designating an area in the form, and an external component that can be incorporated in the form. Resource file 127 (image data), field information 125 indicating the number, order, data type, etc. of fields set in the XRT file or component XRT file, and a DTD (Document Type Definition) file for associating fields with user data 123 and remember Ri, these as components, XRF file as form data file is created.
[0028]
The XRF file is a file of a unique format, and is not a file of image data (bitmap data, PDF file, etc.) obtained by combining a form and user data, but a file in which constituent data of a form are collectively stored. is there. Based on the XRF file, the client 20 creates display and print image data obtained by synthesizing the form and user data. Therefore, in this electronic form system, the form data is transmitted from the server 10 to the client 20 in the form of an XRF file, so that the file size is much smaller than when the form data in the form of image data is transmitted. By performing the compression process, the file capacity can be further reduced. As a result, network traffic can be reduced.
[0029]
The XRT file 124, the field information 125, the component XRT file 126, and the external resource file 127 are created in advance using a drawing application or the like, and a plurality of types are stored in the storage device 115, respectively. The user data 128 is also stored in the storage device 115 in advance. The XRT file 124 and the field information 125 are stored in a one-to-one correspondence. The external resource file 127 is an image data file created by optically reading a figure or a photograph by a scanner or the like. The part XRT file 126 is another XRT file that configures an area embedded in the XRT file, and includes components that can be arranged in the XRT file. The component XRT file 126 is a file in which only a portion commonly used by a plurality of XRT files is registered by designating an area and shared by a plurality of forms. It is also possible to embed another part XRT file by specifying an area in the part XRT file.
[0030]
The DTD file 123, the XRT file 124, the field information 125, the part XRT file 126, the external resource file 127, and the user data 128 are so-called constituent parts of the XRF file as the form data file, and these files or data groups are stored. The component server 1200 is stored in a predetermined storage area of the device 115. Among the components of the XRF file, those other than the user data 128 are the components of the form.
2-3. Functional configuration of server
FIG. 4 is a block diagram for explaining a functional configuration of the server 10. The server 10 is substantially provided with a plurality of function processing units that are realized by the CPU 110 executing a program stored in the ROM 111 or the storage device 115. More specifically, the server 10 includes a control unit 130 and an application server 117 controlled by the control unit 130. The application server 117 is realized by an application program that controls transmission and reception performed between the server 10 and the client 20, a function of receiving a request from a user and bridging to processing of a business system, and a Web server (HTTP server). It also has the function of
[0031]
The application server 117 has a file (not shown) described in HTML (Hyper Text Markup Language) or the like. This file is transmitted from the application server 117 to the client 20 when a connection between the server 10 and the client 20 via the Internet is established. The application server 117 can receive the form data request sent from the client 20 in response to the file. The received form data request is provided to the control unit 130.
[0032]
The server 10 is further provided with a request data analysis unit 131 and a data collection / combination processing unit 132, which are controlled by the control unit 130. The request data analysis unit 131 is a function processing unit implemented by a business application installed in the server 10 and executing business logic, and is a form data request (information for specifying a form type and user data) given from the client 20. ), And the DTD file 123, the XRT file 124, the field information 125, the component XRT file 126, and the external resources, which are the components (component data) of the form data file (XRF file) corresponding to the form data request. The file 127 and the user data 128 are specified. Further, the request data analysis unit 131 automatically creates a form generation information file which is an XML file in which information (including parameters and commands) for creating form data corresponding to the form data request is described in XML.
[0033]
This form generation information file includes files of form data file components (DTD file 123, XRT file 124, field information 125, component XRT file 126, external resource file 127, and user data 128) specified by analyzing the form data request. Information is also included. Further, the request data analysis unit 131 can convert the user data specified by the information included in the form data request into a user data file in an XML file or a CSV (Comma Separated Value) file.
[0034]
The data collection / combination processing unit 132 includes an XML application 133. The XML application 133 is an application program that can interpret and execute the contents described in the XML file, for example, Java (registered trademark), and is installed in the server 10 in advance and is executable. Therefore, when a form generation information file, which is an XML file, is provided to the data collection / combination processing unit 132, the XML application 133 interprets and executes it.
[0035]
The XML application 133 includes an XRF file creation unit 134 that creates an XRF file as a form data file based on a form creation information file created by the request data analysis unit 131, and a PDF (also a PDF file that creates a form data file). Portable Document Format) file creation unit 135.
[0036]
The XRF file creation unit 134 creates the form data file components (the DTD file 123, the XRT file 124, the field information 125, the component XRT file 126, the external resource file 127, and the user data) in the form creation information file generated by the request data analysis unit 131. With reference to the file information of 128), these files are read from the component server 1200 in the storage device 115. Then, the XRF file creation unit 134 combines these read files to create an XRF file as a form data file. The data collection / combination processing unit 132 further passes the XRF file to the application server 117.
[0037]
Similarly, the PDF file creation unit 134 creates a form data file component (DTD file 123, XRT file 124, field information 125, component XRT file 126, external resource file 127) in the form creation information file generated by the request data analysis unit 131. With reference to the file information about the user data 128), these files are read from the component server 1200 in the storage device 115. Then, the PDF file creating unit 135 combines these read files, develops the data into image data, creates a PDF file, and transfers the PDF file to the application server 117.
[0038]
Therefore, when a form data request is given to the server 10, the request data analysis unit 131 creates a form generation information file in which information (parameters, commands, etc.) for creating form data corresponding to the form data request is described in XML. Is created. Then, the XML application 133 interprets and executes the form generation information file to create an XRF file or a PDF file that is a form data file. Thereafter, the XRF file or the PDF file is transmitted from the application server 117 to the client 20.
3. Client configuration
3-1. Client hardware configuration
FIG. 5 is a block diagram illustrating an example of an electrical configuration of the client 20. The client 20 includes a CPU 210, a ROM 211, a RAM 212, an input device 213, a display device 214, a storage device 217 (such as a hard disk drive), a network interface 215, and an input / output interface (I / O) 218. At 216 they are connected to each other. The CPU 210 controls transmission and reception of data among the ROM 211, the RAM 212, the input device 213, the display device 214, the network interface 215, and the input / output interface 218 based on the programs stored in the ROM 211 and the storage device 217. , The input device 213, the display device 214, and the network interface 215.
[0039]
The input device 213 includes a keyboard and a pointing device, and an operation signal thereof is given to the CPU 210. The display device 214 includes a two-dimensional image display device such as a CRT or a liquid crystal display panel, and can display an image according to a display signal from the CPU 210.
[0040]
The CPU 210 is connected to the Internet via a network interface 215. For this reason, the CPU 210 can transmit the form data request to the server 10 via the Internet.
[0041]
Further, a printer 30 can be connected via the input / output interface 218, and print data can be given to the printer 30. When the client 20 and the printer 30 are connected via a local area network, a network adapter may be used as the printer connection input / output interface 218.
3-2. Functional configuration of client
FIG. 6 is a block diagram for explaining the functional configuration of the client 20. The client 20 substantially includes a plurality of function processing units that are realized by the CPU 210 executing a program stored in the ROM 211 or the storage device 217. Specifically, the client 20 includes a control unit 220 that controls the network interface 215. The control unit 220 receives the file transmitted from the server 10 via the Internet by controlling the network interface 215.
[0042]
The client 20 further includes a web browser 221, an XRF reader 222, and a printer driver 223, which are controlled by the control unit 220.
[0043]
The Web browser 221 is a commercially available Web page browsing application program such as Internet Explorer (Note: trademark), for example, and is installed in the client 20 in advance and is executable. When the Web browser 221 is activated, a screen for browsing a file such as HTML is displayed on the display device 214. The Web browser 221 receives a file described in HTML or the like from various servers (including the server 10) on the Internet, and displays the file in a display window of the Web browser 221. When the user operates the input device 213 while the display window of the Web browser 221 is in an active state, the operation information is given to the Web browser 221. The input information is displayed in the Web browser 221, and is transmitted to a transmission source server such as an HTML file by a predetermined input operation.
[0044]
Further, the Web browser 221 can receive a PDF file from a server (including the server 10) on the Internet, and can display the received PDF file in the Web browser 221. More specifically, when the Web browser 221 receives the PDF file, a PDF file browsing program (acrobat reader: trademark) of the add-in software is started (internally started in the window of the Web browser 221). .
[0045]
When the user performs a predetermined operation on the input device 213 while the PDF file is displayed by the Web browser 221, a print setting dialog of the printer driver 223 is opened. The file in the PDF format is converted into print data and transferred to the printer driver 223, and the print data is transmitted from the printer driver 223 to the printer 30, whereby the PDF file is printed. I have.
[0046]
Further, the user can designate a URL (Uniform Resource Locator) on the Web browser 221 by operating the input device 213. The URL is information for specifying a position (a position on the Internet) of a server that provides a file described in HTML or the like or a file in a PDF format. The Web browser 221 can receive a file described in HTML or a file in PDF format from a server whose URL is specified. When using the electronic form system of this embodiment, the URL of the server 10 is entered in the URL entry field of the Web browser 221.
[0047]
The XRF reader 222 is an application program that can display an XRF file transmitted from the server 10, and is installed in the client 20 in advance and is executable. For example, by setting the XRF reader 222 as a helper application of the Web browser 221, the XRF reader 222 is automatically started when the Web browser 221 receives an XRF file (in a window different from the Web browser 221). External activation). When the XRF reader 222 is activated, an XRF file browsing screen is displayed on the display device 214. When the user performs a predetermined input operation on the input device 213 while the XRF file is displayed on the browsing screen, an image file for printing is created from the XRF file, and the printer 30 Is printed.
[0048]
In this embodiment, the XRF reader 222 has a built-in print control unit 222a, and can control the operation of the printer 30 by setting print conditions from a unique dialog different from the setting screen of the printer driver 223. At the time of printing, print data is delivered from the print control unit 22a to the printer driver 223, and image data is sent from the printer driver 223 to the printer 30.
[0049]
The print control unit 222a of the XRF reader 222 displays a print dialog in response to a print instruction from the user. In this print dialog, the user can make various settings such as the number of copies and the paper size, and can instruct printing start after the settings. When print start is instructed, the print control unit 222a closes the print dialog and displays a printing dialog indicating that printing is being performed. A cancel button for interrupting the printing is provided in the printing dialog, and printing can be interrupted by operating the cancel button. When the printing is completed (when the transmission of the print data to the printer 30 is completed), the print control unit 222a closes the printing dialog.
[0050]
When the XRT file is created, the printing paper size and the like are specified at the same time. Since the XRT file has information on the printing conditions, the setting of the printing conditions is not always necessary.
[0051]
The XRF file can include various parameters that define the operation (screen display operation or printing operation) of the XRF reader 222. This parameter can arbitrarily include a parameter indicating whether the client can save the XRF file, whether to print, whether to display the screen, whether to display the print dialog, whether to display the dialog during printing, and the like. . This restricts (prohibits) saving the XRF file in the storage device 217 in the client 20, restricts (prohibits) printing and screen display of the XRF file, prevents a print dialog from being displayed, and prints during printing. You can prevent the dialog from being displayed.
[0052]
As a result, unauthorized issuance of a form such as a receipt can be prevented. In other words, by prohibiting the storage of the XRF file, it is possible to prevent unauthorized issuance of a form that reuses the XRF file. In addition, by prohibiting printing, for example, only a specific person can be allowed to print a form. Further, by prohibiting screen display, it is possible to restrict the act of clipping the displayed image and illegally copying the form data. If the print dialog is not displayed, it is possible to prevent a plurality of forms from being incorrectly output. Furthermore, if the printing-in-progress dialog is not displayed, it is possible to prevent the incomplete form from being illegally used when the incomplete form is output due to the interruption of printing.
4. Operation of the entire electronic form system
FIG. 7 is a block diagram for explaining a conceptual configuration of an electronic form system constituted by the server 10 and the client 20. FIG. 8 shows a reception screen for receiving an input of a form data request by the Web browser 221. FIG. 7 is a diagram showing an example displayed by the following.
[0053]
When a user (such as a salesperson at a business office) needs a form, the user activates the Web browser 221 of the client 20 and specifies the URL of the server 10. Then, the Web browser 221 receives the file described in HTML or the like from the application server 117 of the server 10, and displays a screen as shown in FIG. On this screen, the Web browser 221 can receive an input of a request for a form required by the user. When a predetermined transmission operation is performed on the Web browser 221 by operating the input device 213, a form data request corresponding to the input content is transmitted to the application server 117 by, for example, a CGI or a Java (registered trademark) applet. Sent.
[0054]
The Web browser 221 has a URL input unit 230 and a display unit 231. When the URL of the server 10 is input to the URL input unit 230, the Web browser 221 receives a file described in an HTML file or the like from the server 10, and causes the display unit 231 to display the file.
[0055]
In the example of FIG. 8, in the center of the display unit 231, a list of form types, monthly degrees, and company names is displayed as a selection item list. At the lower part of the display unit 231, a “return” button 232, a “send” button 233, a “print” button 234, and a “cancel” button 235 are displayed.
[0056]
By operating the input device 213, the user can select desired form conditions from the list display of the form type, month, and company name. In this display example, “Receipt”, “August”, and “XX Corporation” are selected. In other words, "Receipt for August for XX Corporation" is selected. The selected item is displayed differently from non-selected items by changing the display color or highlighting.
[0057]
A pointer (not shown) is displayed on the Web browser 221. When the user operates the input device 213 (mainly a pointing device), the pointer is moved to each of the buttons 232 to 235. These buttons 232 to 235 can be pressed (clicked). When the "return" button 232 is pressed, another HTML file or the like is read, and a display different from this display example is displayed on the display unit 231. For example, an HTML file or the like displayed immediately before may be displayed, or a menu screen of the electronic form system may be displayed.
[0058]
On the other hand, when the “print” button 234 is pressed, a form data request including the condition of the form selected at that time is transmitted to the server 10. When the “cancel” button 235 is pressed, the selection state of each item on the screen displayed on the display unit 231 is cleared.
[0059]
The “send” button 233 is a button that is operated when it is desired to continue inputting conditions for another form. For example, when the user wants to create a plurality of forms, if the operation of selecting the form conditions one by one and pressing the “print” button 234 is repeated, the form data is received from the server 10 and one form is received from the printer 30. After the form is output, there is an idle time from when the print data of the next form is given to the printer 30. During this idle time, print data different from the form (for example, print data from another user sharing the printer 30 on the local area network) may be given to the printer 30. Then, the paper on which the print data is printed is mixed between the forms output from the printer 30. Therefore, the user must check each sheet output from the printer 30 one by one, and remove sheets other than the sheet for which printing was instructed.
[0060]
This problem is avoided by using the "send" button 233. That is, when the “send button” 233 is pressed, the form data request including the condition of the form selected at that time is passed from the application server 117 of the server 10 to the request data analysis unit 131, and the RAM 112 in the server 10 Alternatively, it is stored in the storage device 115. Then, the user can select another form condition. By repeating the same operation as many times as the required number of forms, form data requests corresponding to the conditions of these forms are accumulated in the server 10 in the same manner. Thereafter, when the "print" button 234 is pressed after selecting the last form condition, a form data request including the form condition selected on the Web browser 221 at that time is transmitted to the application server 117, The data is passed to the request data analysis unit 131 and stored in the RAM 112.
[0061]
At the same time, the request data analysis unit 131 executes a process for collecting a plurality of form data requests stored in the RAM 112 as one job to create a plurality of pages of form data. As a result, form data (form data of a plurality of pages) corresponding to a plurality of form data requests is created by the operation of the data collection / combination processing unit 132 and the like, and this is transmitted from the application server 117 to the client 20. This allows the client 20 to continuously provide the printer 30 with the print data of the form of a plurality of pages, thereby avoiding the above-described problem.
[0062]
Referring again to FIG. 7, a form data request including designation of form conditions required by the user is transmitted from client 20 to server 10 (arrow B1). This form data request is received by the application server 117 and passed to the request data analysis unit 131. The request data analysis unit 131 creates an XML file (form generation information file) in which information for generating the form data corresponding to the form data request is described in XML. Further, the request data analysis unit 131 reads specific user data corresponding to the form from the component server 1200 based on specification information from the user such as a condition of the form in the form data request, and reads the user data. A user data file is created by converting the file into an XML file or a CSV file.
[0063]
Normally, the user data is stored on the server 10 side, and the user data specified by the conditions (for example, customer name, date of birth, etc.) specified in the form data request from the client 20 is stored in the component Although read from the server 1200, in some cases, a numerical value matching the condition specified in the form data request is generated by the request data analysis unit 131, which is a business application, and this numerical value is used as user data. There is also.
[0064]
The form generation information file generated by the request data analysis unit 131 is transferred to the data collection / combination processing unit 132 (arrow B3). The user data file is also passed to the data collection / combination processing unit 132 (arrow B4).
[0065]
FIG. 9 is a diagram showing an example of an XML file created as a form generation information file by the request data analysis unit 131. The form generation information file 140 is an XML file, and is a file described in a text format. Therefore, the administrator of the server 10 can easily understand the contents of the form generation information file 140. Therefore, since the administrator of the server 10 can grasp the contents of the processing actually performed in the server 10, the maintenance and management of the server 10 can be easily performed.
[0066]
The form generation information file 140 includes a condition setting description section 141 in which parameters for performing settings and the like at the time of generating form data are described, and component data of an XRF file that is form data corresponding to the form data request (XRT file 124, field information 125, a component XRT file 126, an external resource file 127, a DTD file 123, and an XRF file specifying information description section 142 in which information for specifying the user data 128 is described.
[0067]
The condition setting description unit 141 includes an output file mode description unit 1411, in which an output file mode describing whether to output form data in the XRF file format from the server 10 or form data in the PDF file format is described. An external character file information description section 1412 that describes the type of character used, an XRF reader operation setting description section 1413 that describes settings (parameters) related to the operation of the XRF reader 222 in the client 20, and a print operation of the printer 30 A printer operation setting description section 1414 in which setting items (parameters) related to control are described.
[0068]
As described above, the XRF file, which is the form data file generated by the data collection / combination processing unit 132, may include various parameters that specify the operation (screen display operation or printing operation) of the XRF reader 222. it can. These parameters are described in the XRF reader operation setting description section 1413 of the form generation information file 140, and are embedded in the XRF file by the data collection / combination processing section 132.
[0069]
As described above, although not so much description is included in the form generation information file 140, the operation of the entire electronic form system can be set.
[0070]
Further, since the form generation information file 140 is an XML file, the administrator of the server 10 can easily change the form generation information file 140. Therefore, when an abnormality or the like occurs in the electronic form system, the abnormality can be promptly dealt with. Further, by editing the form generation information file 140, a new operation can be easily added to the electronic form system.
[0071]
Referring to FIG. 7 again, upon receiving the form generation information file (XML file) and the user data file (XML file or CSV file), the data collection / combination processing unit 132 receives the XML parser 120, the DOM file or the SAX file. By reading the file 121 from the storage device 115 (arrow B5), the XML application 133 is started (operated).
[0072]
In the output file mode description section 1411 of the form generation information file 140, when the XRF file format is specified as the output file mode of the form data (or when the PDF file format is not specified), the XRF of the XML application 133 is specified. The file creation unit 134 interprets the form generation information file 140 and reads and collects the DTD file 123, the XRT file 124, the field information 125, the component XRT file 126, and the external resource file 127 from the component server 1200 as necessary. Then, an XRF file is created by combining the file group and the user data file (arrow B6). The created XRF file is transferred to the request data analysis unit 131, further transmitted from the application server 117 to the client 20 (arrow B10), and processed by the XRF reader 222. The user of the client 20 uses the function of the print control unit 222a of the XRF reader 222 to develop the XRF file into print data, transmits this data to the printer 30 via the printer driver 223, and A form can be output. However, if the XRF file contains a parameter that prohibits printing, printing is disabled.
[0073]
On the other hand, when the PDF file format is specified as the output file mode of the form data in the output file mode description section 1411 of the form generation information file 140, the PDF file creation section 135 of the XML application 133 converts the form generation information file 140 to The DTD file 123, the XRT file 124, the field information 125, the component XRT file 126, and the external resource file 127 are read and collected as needed from the component server 1200 (arrow B6). The data files are combined and further developed into image data to create a PDF file. The PDF file thus obtained is transferred to the request data analysis unit 131, and is further provided to the Web browser 221 of the client 20 via the application server 117 (arrow B8). When the user performs a predetermined operation on the input device 213 while the Web browser 221 is displaying the received PDF file, print data corresponding to the form data in the PDF format is created, and the print data is created via the printer driver 223. Is transmitted to the printer 30 (arrow B9).
[0074]
FIG. 10 is a flowchart for explaining the operation of the data collection / combination processing unit 132 that has received the form generation information file and the user data file. Upon receiving the form generation information file and the user data file, the data collection / combination processing unit 132 reads the XML parser 120 from the storage device 115 (Step S1). The XML parser 120 analyzes the form generation information file (XML file) received by the data collection / combination processing unit 132.
[0075]
When the form generation information file is analyzed by the XML parser 120, the form generation information file is developed on the RAM 112 in accordance with the contents of the analysis (step S2). Then, the DOM file or the SAX file 121 is read from the storage device 115 (step S3).
[0076]
Thereafter, the XML application 133 is activated (Step S4). By using the DOM file or the SAX file 121, the XML application 133 refers to the form generation information file expanded on the RAM 112 and operates based on the form generation information file.
[0077]
FIG. 11 is a flowchart for explaining the operation of the XML application 133. When the XML application 133 is started, it is determined in the output file mode description section 1411 of the form generation information file 140 whether or not the output file mode is specified in the PDF file format (step S5). If there is no description specifying the PDF file format in the output file mode description section 1411 (NO in step S5), the XRF file creation section 134 creates an XRF file (step S6). If the output file mode description section 1411 of the form generation information file 140 has a description designating the PDF file format (YES in step S5), the PDF file creation section 135 creates a PDF file (step S7). The XRF file or PDF file created in this way is transmitted to the client 20 as a form data file (step S8).
[0078]
Referring to FIG. 7 again, when the XRF file 150 created by the XML application 133 is transmitted to the XRF reader 222 (the Web browser 221 is activated as a helper application by receiving the XRF file) via the application server 117 ( Arrow B10), the XRF reader 222 creates image data of a form image from the XRF file 150 and displays it on the display device 214. Then, when an operation for printing is performed on the XRF reader 222, print data of the form image is transmitted to the printer 30 via the printer driver 223, and the form is printed on paper.
[0079]
As described above, the XRF file 150 is provided from the server 10 to the client 20 via the communication network such as the Internet. By expanding the XRF file 150 into image data of a form image on the client 20 side, the user of the client 20 can obtain a desired form. The XRF file 150 has a smaller data capacity than the spreadsheet image (image data) after expansion. Therefore, the amount of data transmitted on the communication network can be reduced. In other words, the server 10 transmits the XRF file 150 to the client 20, so that the form desired by the user can be provided while reducing the amount of data transmitted on the network.
5. Explanation of form data file (XRF file)
FIG. 12 is a conceptual diagram for explaining the configuration of the XRT file 124, which is one of the main components of the XRF file. A plurality of XRT files 124 are stored in the component server 1200 of the storage device 115. The XRT file 124 is a form file that defines a fixed portion such as a background portion and a layout of a form for each page. The XML application 133 reads the XRT file 124 specified by the XRF file specification information description section 142 of the form generation information file 140 from the storage device 115. When a plurality of form data requests to be processed simultaneously are received from the Web browser 221 of the client 20, the request data analysis unit 131 creates a form generation information file describing form generation information relating to a plurality of pages of form data, and collects data. -It is given to the combination processing unit 132. In this case, the XML application 133 refers to the XRF file specifying information description section 142 corresponding to each form page described in the form generation information file, and stores a plurality of XRT files 124 from the storage device 115 in accordance with each description. Read and create a form data file corresponding to a multi-page form.
[0080]
FIG. 13 is a block diagram for explaining the configuration of the XRT file 124. The XRT file 124 is a form file, and arranges positions and types of fixed components (frames, ruled lines, underlines, texts (characters and numbers), images, drawing objects, etc.) fixedly arranged on a form, and other attributes. A fixed component property 143A describing information (property), a field property 144A describing attribute information (property) including an arrangement position of a field to which a serial number is automatically assigned in the order of arrangement on the form, and a component It has an area property 145A that describes attribute information (properties) such as the layout position, size, and linked component XRT file name of the area in which the XRT file is placed. The field is an area for embedding variable information (information that varies for each form) such as a character string, a numerical value, and an image that changes according to user data, and is set in the XRT file in advance.
[0081]
If the fixed component is text, such text is described directly on the XRT file. When the fixed component is an image, the path and file name of the corresponding image file are described as properties on the XRT file, and the image file is stored in the component server 1200 as an external resource file. When the fixed part is a drawing object, properties such as its shape, arrangement position, color, and size are described in the XRT file.
[0082]
The component XRT file is a file of the same format as the XRT file, and differs from a normal XRT file only in that it is not a file defining a one-page form but is embedded in an area set in the XRT file. Therefore, the configuration of the component XRT file is the same as the configuration of the XRT file. Of course, an area can be set in the part XRT file, and another part XRT can be embedded in this area.
[0083]
The XRT file 124 usually has a fixed component property 143A and a field property 144A for one or more fields, but does not necessarily have the area property 145A. The XRT file 124 may not have any fields.
[0084]
FIG. 14 is a diagram illustrating a specific configuration example of the XRT file 124. Each of the XRT files 124A, 124B, and 124C shown in FIGS. 14A, 14B, and 14C has a fixed part 143 such as a common ruled line, frame line, underline, character, numeral, image, or drawing object. This is a receipt form file in which common fields 144 (address field, date field, amount field, description field) are set, and includes descriptions of their properties. The XRT file 124B shown in FIG. 13B has an area 145 set at the lower right in addition to the configuration of the XRT file 124A shown in FIG. The XRT file 124C shown in FIG. 13C has a fixed part (character string, image, drawing object, etc.) 146 at the lower right in addition to the configuration of the XRT file 124A shown in FIG. .
[0085]
The XRT files 124A, 124B, and 124C shown in FIGS. 14A, 14B, and 14C are separately stored in the storage device 115. Therefore, the server 10 can provide various forms of receipts to the client 20.
[0086]
FIG. 15 is a block diagram for explaining the configuration of the XRF file. The XRF file 150 includes a DTD file 123, an XRT file 124, field information 125 associated with the XRT file 124 one-to-one, and a user data file 151. When an area is set in the XRT file 124 included in the XRF file 150, the XRF file 150 further includes the same number of component XRT files 126 (component XRT files linked to each area) as the number of areas. When the XRT file 124 included in the XRF file 150 has a field associated with the image data or has a content in which an image is pasted as a fixed component, the XRF file 150 Further includes an external resource file 127 corresponding to such an image.
6. Generating report images
FIG. 16 is an illustrative flowchart for explaining a process of generating a form image based on an XRF file. The XRT file 124 has six fields 144 and one fixed part 146 on which an image is directly pasted. Therefore, the XRF file 150 having the XRT file 124 includes the DTD file 123, the field information 125, the user data file 151, and one external resource file 127 (image file). The user data file 151 is a file in which the user data specified by the form data request corresponding to the content input and specified by the user from the client 20 is recorded. For example, “14, 8, 30, OO Corporation, For example, information to be inserted into each field area 144 is recorded in a delimiter (in this example, a format separated by a comma "," (so-called CSV format), such as "100,000, as a book fee."
[0087]
Normally, appropriate user data is read from the component server 1200 in accordance with the conditions specified in the form data request. However, contents to be written in each field may be directly specified from the client 20.
[0088]
The field information 125 indicates the relationship between the field 144 set in the XRT file 124 and the DTD file, and indicates the data type (character, numeric value, barcode, image, etc.) of each field, the order in which the fields are set, and the field Information representing a number. The DTD file describes information for associating individual fields with user data via field information. If the data type of the field can be represented by a numerical value such as a character, a numerical value, or a bar code, data corresponding to each field is stored in the component server 1200 as user data. When the data type of the field is image, the user data includes the path and file name of the image file, and the image file is stored in the component server 1200 as an external resource file.
[0089]
When an XRT file is created in advance using a drawing application, properties of individual fields are described in the XRT file, and the order in which the fields are set is described in the properties. When this field is set, field information is generated.
[0090]
The DTD file 123 stores association information for associating the user data with the field area 144. The XRF reader 222 and the PDF file creating unit 135 embed the user data and the external resource file 127 in each field according to the field information 125 and the properties of the individual fields (particularly, information on the setting order of the fields) with reference to the DTD file 123. To expand to image data.
[0091]
For example, in the XRT file 124 of FIG. 16, “14”, which is the first information of the user data file 151, is stored in the field 1 set first, and the user data file 151 is stored in the field 2 set second. Of the user data file 151 is "30" which is the third information of the user data file 151, and "8" which is the second information of the user data file. In the field 5 where the fourth information of the file 151 is “XX Corporation”, the fifth information of the user data file 151 is “100,000” and the sixth is set. In the field 6, the sixth information of the user data file 151, "as a book fee" is embedded. However, since the correspondence between the setting order of each field and the user data is described in the DTD file 123, it is not necessary that the field setting order and the user data arrangement order match.
[0092]
Further, the XRF reader 222 and the PDF file creation unit 135 develop the fixed component 143 in the form into image data in accordance with the property described in the XRT file 124. Further, for an area where an image is pasted, such as the fixed part 146, an external resource file (image file) is embedded and expanded.
[0093]
Thus, a form image is created. The created form image is converted into display image data in the XRF reader 222, and is further converted into print data when a printing operation is performed, and is provided to the printer 30 via the printer driver 223.
7. Usage of part XRT file
FIG. 17 is a conceptual diagram for describing an example of use of the component XRT file 126. In this conceptual diagram, XRF files 152 and 153 include XRT files having areas commonly linked to one component XRT file 126.
[0094]
The XRF file creation unit 134 of the XML application 133 reads the XRT file 124 corresponding to the form data request from the component server 1200 of the storage device 115 based on the form generation information file 140, and is linked to the XRT file 124. The XRF files 152 and 153 are created by reading the component XRT file 126 from the component server 1200 and combining them.
[0095]
In the example of FIG. 17, one component XRT file 126 stored in the storage device 115 is commonly used for generating XRF files 152 and 153. As described above, there may be a part XRT file 126 commonly used in a plurality of XRF files. For example, if a component XRT file 126 corresponding to an image or text of a company seal or company name is created in advance and stored in the component server 1200 of the storage device 115, the server 10 provides various form data (XRF file 150). Therefore, the storage capacity to be secured in the storage device 115 can be reduced.
[0096]
In the component XRT file, fixed components (character strings, numerical values, barcodes, images) can be arranged, fields can be set, and areas linked to other component XRT files can be set. Therefore, by using the part XRT file, various forms of form parts can be created, and various parts shared by a plurality of types of form forms can be created in advance.
8. XRF reader operation
FIG. 18 is a diagram illustrating a display example of the XRF reader 222 that has received the XRF file 150. When the client 20 receives the XRF file 150 from the server 10 and browses it using the XRF file reader 222, the XRF reader 222 displays a form image 240 created from the XRF file 150 and a “previous page” button. 241, a “next page” button 242, a “print” button 243, and a “cancel” button 244 are displayed. These buttons 240 to 244 can be operated (clicked) using the input device 213.
[0097]
Even if the XRF reader 222 receives the XRF file 150 corresponding to the form data including the form of a plurality of pages, the XRF reader 222 can only display the form image 240 one by one. Therefore, by pressing a “previous page” button 241 or a “next page” button 242, the form images 240 can be browsed one by one. When the “print” button 243 is pressed while the form image 240 is displayed, a print dialog box is opened, and after setting print conditions in the print dialog box, an operation for instructing start of printing is performed. Accordingly, the XRF reader 222 transmits print data corresponding to the form image 240 to the printer 30 via the printer driver 223 (arrow B11 in FIG. 7). As a result, the form image 240 is printed on paper and output from the printer 30.
[0098]
By pressing the “Cancel” button 244, printing of the form can be canceled. However, after the “Print” button 243 is pressed, the print dialog box opens. Button 244 cannot be operated.
[0099]
Note that the screen of the XRF reader 222 does not have buttons provided in the screen as described above, but may have an arrow button or the like provided on a menu bar.
[0100]
When the start of printing is instructed from the print dialog box, the print dialog box is automatically closed and a printing dialog box indicating that printing is being performed appears. Depending on the type of form (for example, a receipt), it is possible to set this dialog box during printing as a system modal dialog box. In this case, other operations including the operation of the operating system may not be performed until the print dialog box is closed. That is, once the printing process is started, other operations are disabled until the printing process is completed, and the printing operation may not be canceled in the middle. As a result, it is possible to avoid a situation in which a form in an incomplete state is created and is illegally used. When the printing process is completed (for example, when the output of the print data is completed or the printing completion notification is received from the printer), the printing dialog is automatically closed.
[0101]
If the received XRF file 150 includes a parameter for prohibiting screen display, the form image 240 is not displayed, and only the buttons 241 to 244 are displayed. This prevents the form image data from being copied on the screen, and allows only print output.
[0102]
If the received XRF file 150 contains a parameter that prohibits printing, for example, the print button 243 becomes inoperable (for example, grayed out) and cannot be printed. It becomes.
[0103]
Furthermore, if the received XRF file 150 includes a parameter that prohibits the display of the print dialog, even if the print button 243 is operated, the print dialog is not displayed and the print processing is performed in the background. Done. Thereby, printing of a plurality of forms can be prevented.
[0104]
If the received XRF file 150 includes a parameter for prohibiting the display of the printing dialog, the printing process is performed without displaying the printing dialog. In the case where an interrupt button for interrupting printing is provided in the printing dialog box, the printing dialog is not displayed, thereby preventing the form printing from being interrupted.
[0105]
Further, if the received XRF file 150 includes a parameter for inhibiting the storage of the XRF file, the XRF reader 222 cannot save the XRF file.
9. Creating a part XRT file
FIG. 19 is a conceptual diagram for explaining a mode of using a component XRT file. The XRT file that forms the form and the component XRT file that is pasted by designating an area in the XRT file are created in advance using a drawing application and stored in the component server 1200 of the server 10. In a drawing application, an area can be secured when an XRT file is created, and a part XRT file can be created in that area. The component XRT file created in this manner can be reused by pasting it on another XRT file or component XRT file.
[0106]
When the area is secured, the area property is described in the XRT file. This area property includes the size of the area and position information in the XRT file.
[0107]
When importing an existing part XRT file into the XRT file, the part XRT file is pasted at the active cursor position on the screen of the drawing application displaying the contents of the XRT file. At this time, the area property is described in the XRT file. This area property includes information on the position where the component XRT file is pasted and the size of the area. In this case, the size of the area is equal to the size of the area secured when the component XRT file is first created.
[0108]
The part XRT file 161 shown in FIG. 19 includes an area 162 on which an image file as a fixed part is pasted, and an area 163 on which text data is pasted. In this example, an image file representing the logo of XXX is pasted on the area 162, and text data “XXX, 01-2345-6789” is pasted on the area 163. . As described above, a field can be set in the component XRT file, as in the case of the XRT file, and user data such as characters and numerical values can be pasted in this field, and image data can be pasted. You can also.
[0109]
FIG. 20 is a conceptual diagram for explaining a use mode of the component XRT file 126. The XRF files 171, 172, 173, and 174 include XRT files each having an area commonly linked to the component XRT file 161 stored in the storage device 115.
[0110]
For example, as shown in FIG. 19, when it is necessary to change the text data “XXX Corporation, 01-2345-6789” in the area 163 to the text data “XXX Corporation, 01-2345-6780” Is assumed.
[0111]
At this time, the administrator of the server 10 can edit the text data in the area 163 of the component XRT file 161 by using the drawing application and change the text data to “XXX Corporation, 01-2345-6780”. . The changed part XRT file 161 is overwritten and stored in the storage device 115 by the drawing application, for example. The image file in the area 162 can be changed in the same manner.
[0112]
After the changed component XRT file 161 is stored in the storage device 115, when an XRF file including the component XRT file 161 as a component is generated, the XRF file includes the changed component XRT file 161 as a component. Will be included.
[0113]
Therefore, by editing the component XRT file 126, the administrator of the server 10 can reflect the editing result on a plurality of types of forms generated using the component XRT file 126 in common.
10. Change appearance according to user data
10-1. Selection of image parts according to user data
FIG. 21 is a block diagram illustrating a configuration example of the server 10 having a function of changing the appearance of a form according to user data. In FIG. 21, parts that are the same as the parts shown in FIG. 4 are given the same reference numerals as in FIG. 4, and descriptions thereof will be omitted.
The business application of the server 10 determines an appropriate image file according to the user data in addition to the function of the request data analysis unit 131 described above, and describes the path and file name of the image file in the form generation information file. The function of the image file setting unit 136 is provided.
[0114]
The request data analysis unit 131 generates form generation information in which an XRT file in which an area to which one image file selected from a plurality of image files is to be pasted according to user data is set as a component of the form data file. May be. In this case, the request data analysis unit 131 transfers the user data read in response to the form data request from the client 20 to the image file setting unit 136. The image file setting unit 136 specifies an image file to be pasted to the area in the XRT file based on the transferred user data, and describes the path name and file name of the file in the form generation information file.
[0115]
FIG. 22 is a conceptual diagram for explaining the function of the image file setting unit 136. FIG. 23 is a conceptual diagram for explaining an example of the form data (XRF file) provided from the server 10 to the client 20.
[0116]
In the conceptual diagram of FIG. 22, an XRT file 180, which is a component of the form data, includes fourteen fields 181 and 182 in which characters or numerical values are designated as data types, an area 183 on which an image is pasted, and a plurality of fields. An area 184 is set so that one image selected from the images is pasted. On the other hand, it is assumed that the storage device 115 stores image files 185, 186, 187, 188, 189, and 1810. In the area 183, an image file 185 is pasted as a fixed component.
[0117]
The image file setting unit 136 specifies one of the image files 186 to 1810 as an image file to be pasted into the field 184 according to the data value of the user data specified by the form data request given from the client 20. For example, if the data value of the fourteenth input data is “0” or more and less than “500,000”, the image file setting unit 136 sets the image file 186 to “500,001” or more and “1,000,000”. If it is less than “1,000,001” or more and less than “1,500,000”, the image file 188 is written. If it is “1,500,001” or more and less than “2,000,000”, If there is, the information (path and file name) for specifying the image file 189 as an image file to be embedded in the area 184 if the image file 189 is equal to or more than “2,000,001” and less than “2,500,000” is recorded. The operation is set as described in the generation information file 140.
[0118]
In this embodiment, each of the image files 186 to 1810 is composed of a horizontally long band-shaped figure having a different length from each other and a character string “current amount of money”. The length of the band-shaped figure visually represents the amount of the stock amount. If necessary, the color of the band-shaped figure portion and / or the character string portion may be different. For example, the band-shaped figure portions such as the image files 186 and 1810 corresponding to the under-stock amount or the excessive stock amount are set to red, the band-shaped figure portion of the image file 188 corresponding to the appropriate stock amount is set to green, and the other image files 187 and 189 are used. If you change the color to yellow, you can grasp the amount of inventory at a glance.
[0119]
For example, as shown in FIG. 23, it is assumed that the data value of the fourteenth user data is “1969960”. Then, the image file setting unit 136 describes the path and file name of the image file 189 in the form generation information file 140 as the path and file name of the image file to be embedded in the area 184.
[0120]
After that, the XML application 133 creates an XRF file or a PDF file based on the form generation information file 140. A form image 1811 shown in FIG. 23 shows the created XRF file 150 displayed by the XRF reader 222.
[0121]
The form image 1811 is a form image showing the “August inventory management table”. The form image 1811 has contents that make it easy to visually understand that the stock amount as of August is within the appropriate range by the image files 185 and 189.
[0122]
The condition value when the image file setting unit 136 selects an image file may be changeable by an administrator of the server. Further, the setting of the user data for which the condition value is to be determined may be changed. Further, the setting of the image file (external resource file) specified by the image file setting unit 136 may be changed.
[0123]
In this way, it is possible to create a form having a different appearance according to the user data. In addition, since a plurality of image files selectively used for one form are stored separately from the data of the form, the storage capacity of the storage device 115 is not squeezed.
[0124]
In the above example, an example in which the image file selected according to the value of the user data is pasted in the specific area has been described. However, the same configuration and processing are used to set the image file in the XRT file which is the form file. By changing the property of the selected area according to the user data, any of a plurality of component XRT files (component forms) can be selected according to the value of the user data and linked to the area. . In this way, it is also possible to create forms with variously different appearances according to the user data.
10-2. Changing the characteristics of drawing objects according to user data
FIG. 24 is a block diagram for explaining another configuration example of the server 10 used for changing the appearance of the form according to the user data. In FIG. 24, portions corresponding to the respective portions shown in FIG. 4 are denoted by the same reference numerals as in FIG. 4, and description thereof will be omitted.
[0125]
The business application of the server 10 performs, in addition to the function as the above-described request data analysis unit 131, property change processing for changing the properties of drawing objects (graphic data such as lines, circles, rectangles, polygons, arcs, and sectors). It has a function as the unit 137.
[0126]
In some cases, a drawing object as a fixed component is pasted on the XRT file corresponding to the form data request from the client 20. In this embodiment, the properties of a specific drawing object can be automatically changed based on the user data.
[0127]
When an XRT file is created using a drawing application, drawing objects can be arranged on a form. The drawing application has an editor function for editing a drawing object. For example, a drawing object having a desired shape is selected and arranged at a desired position on a form by dragging a mouse. The shape and size of the drawing object can be changed by a drag operation or the like. The drawing object created in this way has properties such as a pasting position, a size, a line type (such as an outline) and a color on the form. These properties can be changed by filling in the property edit dialog on the drawing application. The properties generated in this way are described in the XRT file.
[0128]
FIG. 25 is a diagram showing a display example of a property editing dialog of a drawing object corresponding to a rectangular figure. In this property edit dialog, there are position data 191 of the upper left vertex of the rectangular object in the horizontal direction, position data 192 of the upper left vertex of the rectangle in the vertical direction, horizontal length data 193 of the rectangle, and vertical length of the rectangle. The data 194 is displayed.
[0129]
In this example, the horizontal position data 191 of the upper left vertex of the rectangle is “87.5”, the vertical position data 192 is “6.771”, the horizontal length data 193 is “25.26”, and the vertical length data 194 is “17.969”. When the values of the data 191 to 194 are changed, the position, size and shape (ratio of length and width) of the rectangular drawing object change.
[0130]
The drawing object property editing dialog further includes an object name setting section 195, an “OK” button 196, and a “Cancel” button 197. These buttons can be operated (clicked) with a mouse or the like. By operating the “OK” button 196, each value of the property is determined, and is written to the XRT file as a default value.
[0131]
The property change processing unit 137 determines an appropriate property value for a specific drawing object in the XRT file based on the value of the user data corresponding to the form data request from the client 20, and sets the property value of the drawing object to the property value. The command to instruct to change the value is described in the form generation information file. For example, a command for changing the values of the data 191 to 194 in the property to values corresponding to the user data is entered in the form generation information file.
[0132]
In this manner, a form generation information file including a command for changing the position, size, and shape (and color as necessary) according to the value of the user data is created, and the data collection / combination processing unit 132 Will be given to
[0133]
FIG. 26 is a conceptual diagram for explaining deformation of a rectangular figure due to a change in a property of a drawing object according to the value of user data. It is assumed that a property of a rectangular drawing object is described in a form file (XRT file) corresponding to a form data request from the client 20. As default properties of the rectangular drawing object, the horizontal position data 191 is “87.5”, the vertical position data 192 is “6.771”, the horizontal length data 193 is “25.26”, and the vertical position data 193 is “25.26”. It is assumed that the direction length data 194 is set to “17.969”.
[0134]
For example, as a result of the analysis by the request data analysis unit 131, if the user data A corresponding to the form data request has a value of “75%”, the property change processing unit 137 determines that the horizontal length data 193 Is changed from “25.26” to “18.945” which is equivalent to 75% of “25.26”, and written in the form generation information file. As a result, the XML application 133 of the data collection / connection processing unit 132 interprets the command, thereby changing the XRT file and creating an XRT file in which the properties of the rectangular drawing object have been changed. As a result, the XRF reader of the client 20 develops rectangular image data with the horizontal length of “22.734”.
[0135]
If the user data B corresponding to the form data request has a value of “90%”, the property change processing unit 137 converts the horizontal length data 193 of the basic rectangular drawing object from “25.26” to “25.26”. , A command for changing to “22.734” corresponding to 90% of “25.26” is created and entered in the form generation information file. In response, the XML application 133 changes the XRT file and changes the properties of the rectangular drawing object. As a result, the XRF reader of the client 20 develops rectangular image data with the horizontal length of “22.734”.
[0136]
In this way, it is possible to automatically generate an XRT file having a drawing object of a property (particularly, a property related to the form) according to the value of the user data.
[0137]
FIG. 27 is a conceptual diagram for explaining an example of the form data provided from the server 10 to the client 20. Fields 1912 and 1913 are set in an XRT file 1911 which is a form form file corresponding to a form data request (particularly, a part for designating a form type) transmitted from the client 20 to the server 10. It is assumed that image data 1917 is pasted to the area 1915, and a rectangular drawing object 198 (having default properties) is pasted to the areas 1915 and 1916, respectively. The image file 1917 linked to the area 1914 is stored in the storage device 115, and the path and file name of the image file 1917 are described in the XRT file as properties of the image. The properties of the drawing object 198 are described in the XRT file.
Furthermore, the property change processing unit 136 changes the property of the basic rectangular drawing object 198 pasted on the areas 1915 and 1916 to a value corresponding to the user data (for example, one corresponding to the fields 1912 and 1913). Is described in the form generation information file.
[0138]
On the other hand, it is assumed that “75%, 90%” is read from the component server 1200 as the user data specified based on the form data request and given to the business application. The request data analysis unit 131 creates a user data file such that the first user data “75%” is embedded in the field 1912 and the second user data “90%” is embedded in the field 1913. The property change processing unit 136 generates a command indicating that the properties of the drawing objects 198 in the areas 1915 and 1916 should be changed according to the user data “75%, 90%”, and stores this command in the form generation information file. Fill out. The rectangle drawing objects after the property change are indicated by reference numerals 199 and 1910, respectively.
[0139]
The form generation information file 140 automatically generated as described above is interpreted by the XML application 133. As a result, the properties of the rectangular drawing objects in the areas 1915 and 1916 are changed in the XRT file 1911. Is generated. The XRF file 150 includes an XRT file 1911 (in which the properties of the drawing object have been changed), an image file 1917, and user data as component data. By transmitting the XRF file 150 to the client 20 via the application server 117 and displaying the XRF file 150 on the XRF reader 222, a form image 1919 is obtained.
[0140]
The form image 1919 is form data indicating a stock ratio of stock items with the products A and B. The form image 1919 visually indicates the stock ratio of the stock items with the products A and B by the image file 1917 and the rectangular drawing objects 199 and 1910, and has an appearance that is easy to understand intuitively.
[0141]
Here, the example in which the horizontal length of the rectangle is changed in accordance with the value of the user data has been described, but the vertical length is changed, and the color of the drawing object is also changed in accordance with the value of the user data. Or you may be. Here, the property of the drawing object is changed so as to correspond to the user data expressed as a percentage. However, a reference value is provided in advance in the property change processing unit 136, and the user data and the reference value are compared. The configuration may be such that the properties of the drawing object are changed according to the comparison result (for example, the magnitude of the difference between the reference value and the user data).
Needless to say, the shape of the basic drawing object is not limited to a rectangle, but may be another shape such as a circle, an arc, or a sector.
[0142]
FIG. 28 is a block diagram for explaining a configuration of an electronic form system that realizes a function of changing a property of a drawing object according to user data. The form data request from the client 20 is given from the Web browser 221 to the request data analysis unit 131 via the application server 117 (arrow C1). The request data analysis unit 131 reads out the user data corresponding to the form request data from the storage device 115 (arrow C3).
[0143]
When a drawing object to be changed in properties by user data is pasted on a form (XRT file) corresponding to the form data request, the request data analysis unit 131 provides the user data to the property change processing unit 137. (Arrow C3).
[0144]
The property change processing unit 137 creates a command for changing the property of the target drawing object according to the given user data, and writes it in the form generation information file (arrow C4).
[0145]
The request data analysis unit 131 also sends the form generation information file 140 for creating the form data corresponding to the form data request and the user data 151 to the data collection / combination processing unit 132 (arrow C7). The form generation information file 140 includes a command for instructing that the properties of the drawing object in the form form file (XRT file) should be changed.
[0146]
The data collection / combination processing unit 132, which has received the form generation information file 140 and the user data 151, reads the XML parser 120 and the DOM file or the SAX file 121 from the storage device 115 (arrow C8). 133 is started. The XML application 133 reads the DTD file 123, the XRT file 124, the field information 125, the component XRT file 126, and the external resource file 127 from the storage device 115 on the basis of the form generation information file 140 (arrow C9). Create 150. At this time, the properties of the drawing object in the XRT file are changed according to the command generated by the property change processing unit 137.
[0147]
If the PDF file format is not specified in the output file mode description section of the form generation information file 140, an XRF file is created by the XRF file creation section 134 of the XML application 133, and this XRF file is delivered to the request data analysis section 131. It is. The XRF file is transmitted to the XRF reader 222 (the Web browser 221 is activated as a helper application by receiving the XRF file) via the application server 117 (arrow C13). When a predetermined operation of the input device 113 is performed while the XRF reader 222 is displaying the received XRT file 150, print data of the form is transmitted to the printer 30 via the printer driver 223, and the printer 30 The form is printed out on paper (arrow C14). In this way, it is possible to obtain a form in which the drawing object whose property (particularly the form) has been changed according to the user data is embedded.
[0148]
If the PDF file format is specified in the output file mode description section of the form generation information file 140, the PDF file creation section 135 of the XML application 133 expands the image data of the form corresponding to the XRT file, The user data, the image, and the drawing object are developed and embedded in the image data. The PDF file thus obtained is delivered to the request data analysis unit 131, and is provided to the Web browser 221 of the client 20 via the application server 117 (arrow C11). If the user performs a predetermined operation on the input device 113 while the Web browser 221 is displaying the received PDF file, the form print data is created and given to the printer 30 via the printer driver 223. The form is printed out from the printer 30 (arrow C12).
[0149]
If the form file (XRT file) corresponding to the form data request from the client 20 has a drawing object whose properties are always changed according to the user data, the request data analysis unit 131 sets the form data From the file name of the (XRT file), it may be determined that the property of the drawing object needs to be changed, and the user data may be passed to the property change processing unit 137.
[0150]
Further, depending on the form, the client 20 may specify whether to use the default value or change the property of the drawing object without changing the property of the drawing object (the specification information is included in the form data request). Is also conceivable. In such a case, the request data analysis unit 131 first determines whether or not there is a designation from the client 20, and if it is specified that the property of the drawing object is not changed, the request by the property change processing unit 137 May be skipped.
11. An embodiment capable of caching component files of a form
FIG. 29 is a block diagram showing the overall configuration of an electronic form system according to another embodiment of the present invention. In this embodiment, the server 10 and a plurality of proxy servers 40 are connected to the Internet. The server 10 is a computer capable of performing large-scale processing, and is communicably connected to the Internet. The proxy server 40 is a personal computer having storage means, and is installed, for example, for each office or building.
[0151]
A LAN (local area network) 50 is connected to the proxy server 40. The LAN 50 is connected to a plurality of clients 20 and printers 30 installed in an office, for example. The client 20 is a personal computer installed in an office or the like. The client 20 can transmit and receive data to and from another client 20 connected to the LAN 50, and shares the printer 30.
[0152]
The proxy server 40 can communicably connect the Internet and the LAN 50. Therefore, the server 10 and the client 20 can exchange data with each other via the proxy server 40.
[0153]
In this embodiment, the components of the XRF file are cached in the proxy server 40, and the client 20 transmits only the component files of the XRF file that are not cached in the proxy server 40 from the server 10. The received XRF file is created on the client 20 side. As a result, the load on the network is reduced. In addition, since the cache is performed in units of the component data, not only when the client 20 issues a request for a form having exactly the same contents but also when the forms have different contents, a part of the component data is shared. If so, the cache will be hit and the efficiency of the cache will be improved. As a result, the load on the network can be reduced efficiently.
[0154]
FIG. 30 is a block diagram for explaining a configuration example of the server 10 in this embodiment. In the block diagram of FIG. 30, components that are the same as the components shown in FIG. 4 are given the same reference numerals as in FIG. 4, and description thereof is omitted.
[0155]
The storage device 115 stores an XML parser, a DOM file or a SAX file, and a DTD file. The storage device 115 further stores a plurality of types of XRT files, field information, component XRT files, and external resource files. The storage device 115 in this configuration further stores update date and time information that is associated one-to-one with each of the DTD file, XRT file, field information, component XRT file, and external resource file. The update date and time information is information indicating the date and time when the DTD file, XRT file, field information, component XRT file, and external resource file were last stored in the storage device 115 (last updated date and time).
[0156]
The administrator of the server 10 edits the DTD file, the XRT file, the field information, the component XRT file, and the external resource file 127 as necessary by using the drawing application, and overwrites the updated file on the storage device 115. Or write as an alias file. At this time, in association with each file, the time at which the file was last written to the storage device 115 is also written to the storage device 115 as update date and time information.
[0157]
The business application of the server 10 has a function of the request data analysis unit 131 and a function of a cache prohibition data setting unit 1313 that adds information (flag) indicating whether or not each component data of the XRF file can be cached. I have. This business application operates in cooperation with the form generation information file reading unit 1311 including the XML application 133.
[0158]
The request data analysis unit 131 creates a form generation information file and a user data file based on the form data request from the client 20, and provides the form generation information file to the form generation information file reading unit 1311. As a result, the XML application 133 is started, and the XML parser is called via the DOM file or the SAX file.
[0159]
The XML application 133 interprets the form generation information file described in the XML file format via the XML parser, and according to the interpretation result, a DTD file, an XRT file, field information, and an XRF file corresponding to the form data. The update date and time information that is associated one-to-one with information (for example, a path and a file name) for specifying the component XRT file and the external resource file can be read from the storage device 115.
[0160]
Then, the XML application 133 sends the configuration file specifying information (eg, path and file name; form form data specifying information) of the XRF file (form data) described in the form generation information file, and the update date and time information of those files. To generate a form generation information file to which the description of the update date and time information is added. The XML application 133 delivers this form generation information file with update date and time information to the request data analysis unit 131. The request data analysis unit 131 can transmit this form generation information file to the client 20 via the application server 117 together with the user data file.
[0161]
When the application server 117 receives a file transmission request for requesting transmission of a component file of the XRF file from the client 20, the request data analysis unit 131 transmits the requested file (DTD file, XRT file, field information, component An XRT file or an external resource file) can be read from the storage device 115. Then, these read files can be provided to the client 20 via the application server 117.
[0162]
When the requested file is transmitted to the client 20, the requested file (DTD file, XRT file, field information, component XRT file or external resource file) is stored (cached) in the proxy server 40. This cached file has update date / time information as its attribute.
[0163]
For example, if a form including a company seal or the like is cached on the client side, there is a possibility that the form will be used illegally. Therefore, in the case where the form itself is important, or in the case of a form including an important image such as a company seal, at least the cache prohibition information is stored in the form generation information file so that the file constituting the important part cannot be cached. Is filled in.
[0164]
More specifically, when the form data corresponding to the form data request from the client 20 includes the file for which the cache prohibition is set by the cache prohibition data setting unit 1313, the cache prohibition data setting unit 1313 A parameter for prohibiting caching of all or a part of an element file (DTD file, XRT file, field information, component XRT file or external resource file, that is, a form element file) is embedded in the form generation information file. Thus, the XRT file, field information, component XRT file, or external resource file cached in the proxy server 40 can be restricted.
[0165]
The following is an example of the format of a form generation information file including a parameter for setting cache prohibition.
<? XML version = "1.0"? >
<DOCUMENTINFO>
<!-Parameter information->
<PARAMETER>
<OUTPUTMODE> XRF or PDF </ OUTPUTMODE>
<FSETNAME> Accessor setting file </ FSETNAME>
<FORMNAME> Form file name </ FORMNAMAE>
<CASHMODE> Cache availability </ CASHMODE>
<COPIES> number of copies </ COPIES>
<FEEDER> Paper tray </ FEEDER>
<OUTPRINTER> Destination printer </ OUTPRINTER>
...
<REQUESTNAME> User name for log output </ REQUESTNAME>
<USERNAME> User name for security </ USERNAME>
<PASSWORD> Password for security </ PASSWORD>
</ PARAMETER>
<XRT>
<XRTFILE> Specify XRT file name </ XRTFILE>
<XMLDATA>
<XMLFILE> XML file name </ XMLFILE>
</ XMLDATA>
</ XRT>
Generally, the user data is different for each form, and thus does not need to be cached. Therefore, for the user data file, for example, a parameter for prohibiting caching may be described in the form generation information file, or the user data may be excluded from the object of caching by processing by the application on the client 20 side. Good.
[0166]
FIG. 31 is a block diagram for explaining a configuration example of the client 20 in the electronic form system of this embodiment. In FIG. 31, components that are the same as the components shown in FIG. 6 are given the same reference numerals as in FIG. 6, and description thereof is omitted.
[0167]
The client 20 includes a data combination processing unit 229 and a cache determination unit 224. The data combination processing unit 229 and the cache determination unit 224 are controlled by the control unit 220.
[0168]
The data combination processing unit 229 and the cache determination unit 224 are function processing units realized by the XML application. Among these, the data combination processing unit 229 interprets the form generation information file provided from the server 10 and combines the DTD file, the XRT file, the field information, the component XRT file, the external resource file, and the user data to form the form data Create an XRF file that is a file.
[0169]
On the other hand, the cache determination unit 224 is configured to configure a DTD file, an XRT file, field information, a component XRT file, and an external resource file described in a form generation information file provided from the server 10, that is, an XRF file as form data. It is determined whether or not the element file (other than the user data) is stored in the proxy server 40. When it is determined that the XRT file, the field information, the component XRT file, and the image file specified by the form generation information file are not stored in the proxy server 40, the cache determination unit 224 determines the missing file specifying those files. A transmission request is transmitted to the server 10.
[0170]
When the cache determining unit 224 determines that the XRT file, the field information, the component XRT file, and the external resource file indicated by the form generation information file are stored in the proxy server 40, the cache determination unit 224 describes the XRT file, the field information, the component XRT file, and the external resource file in the form generation information file. Then, it is determined whether or not the update date and time information of those files and the update date and time information of the corresponding file stored in the proxy server 40 match. If it is determined that the update date and time information described in the form generation information file does not match the update date and time information of the file stored in the proxy server 40 for any one of the component files, the cache determination unit 224 determines Then, it transmits the missing file transmission request specifying the file to the server 10 via the Web browser 221.
[0171]
When transmitting the transmission request, the cache determination unit 224 checks whether or not there is a parameter for prohibiting caching in the form generation information file. If the parameter for prohibiting caching is described, the Web browser 221 When transmitting the transmission request, the cache in the proxy server 40 is suppressed by the setting of the HTTP protocol.
[0172]
FIG. 32 is a block diagram for explaining the operation of the electronic form system including the server 10 of FIG. 30 and the client 20 of FIG. When the user of the client 20 operates the input device 213 to input required information to the Web browser 221, a form data request corresponding to the input content is transmitted from the Web browser 221 to the request data analysis unit 131 via the application server 117. (Arrow E1).
[0173]
The request data analysis unit 131 creates a form generation information file based on the form data request given from the Web browser 221. Further, the request data analysis unit 131 specifies the user data stored in the server 10 based on the data part specified by the user of the form data request, and creates a user data file. Then, the request data analysis unit 131 gives the form generation information file and the user data file to the form generation information file reading unit 1311 (arrow E2). If the form data corresponding to the form data request includes component data for which cache prohibition is set, a parameter indicating cache prohibition is written into the form generation information file by the cache prohibition data setting unit 1313.
[0174]
When the form generation information file reading unit 1311 is provided with the form generation information file 140 and the user data file 151, an XML parser, a DOM file or a SAX file is read from the storage device 115, and the XML application 133 is started. The XML application 133 reads the file name of the component file of the XRT file corresponding to the form data request and the update date / time information of the file from the storage device 115 based on the form generation information file (arrow E3), and adds the update date / time information. Then, the form generation information file is created and transmitted from the application server 117 to the cache determination unit 224 of the client 20 (arrow E4). At this time, the user data file is also transmitted.
[0175]
The cache determination unit 224 that has received the form generation information file stores the form generation information file among the constituent element files (DTD file, XRT file, field information, component XRT file, or external resource file) stored in the proxy server 40. Identify the described file. Further, a component file in which the update date and time information of the specified component file on the proxy server 40 matches the update date and time information of the component file indicated in the form generation information file is specified. It requests the transmission (arrow E5). In response, the component file specified by the cache determination unit 224 and requested to be transmitted is provided from the proxy server 40 to the data combination processing unit 229 of the client 20 (arrow E6).
[0176]
In addition, the cache determination unit 224 determines, from among component files (DTD file, XRT file, field information, component XRT file, or external resource file) indicated in the form generation information file, a configuration that is not provided from the proxy server 40. The missing file transmission request specifying the element file is transmitted to the request data analysis unit 131 via the Web browser 221 and the application server 117 (arrow E7). At this time, the availability of the cache in the proxy server 40 is set in the HTTP protocol according to the parameters described in the form generation information file.
[0177]
Upon receiving the missing file transmission request, the request data analysis unit 131 reads a component file (XRT file, DTD file, field information, component XRT file, or external resource file 127) corresponding to the missing file request from the storage device 115 ( Arrow E8). Then, the read component file is provided from the application server 117 to the data combination processing unit 229 via the proxy server 40 and the Web browser 221 (arrow E9). If caching prohibition is set by the HTTP protocol when transmitting a missing file transmission request from the Web browser 221, the component file transmitted from the server 10 is not cached in the proxy server 40. If the prohibition of caching has not been set, the component file transmitted from the server 10 is cached in the proxy server 40.
[0178]
The component files (XRT file, DTD file, field information, component XRT file, or external resource file) cached in the proxy server 40 can be commonly used by all clients 20 connected to the proxy server 40. . Therefore, component files (XRT file, DTD file, field information, component XRT file, or external resource file) used in the entire electronic form system can be efficiently distributed to each client 20.
[0179]
The data combination processing unit 229 combines the constituent element files (XRT file, DTD file, field information, component XRT file and external resource file) and the user data file provided from the server 10 and the proxy server 40 to form the form data. Create an XRF file as More specifically, an XRT file described in a form generation information file is acquired, a part XRT file, image data, and the like are combined with the XRT file, and user data corresponding to each field is combined, thereby obtaining an XRF file. A file is created.
[0180]
The XRF file thus created is provided to the XRF reader 222 (arrow E10). The XRF reader 222 that has received the XRF file creates a form image by expanding the XRF file into image data and displays the form image. When a predetermined print instruction operation is performed from the input device 213 while the form image is being displayed, print data corresponding to the form image is created and transmitted to the printer 30 via the printer driver 223. It is transmitted (arrow E11). As a result, paper carrying the form image is output from the printer 30.
[0181]
Instead of transmitting the form generation information file and the user data file from the server 10 to the client 20, an XRF file without actual data may be transmitted. That is, a normal XRF file has an XRT file which is a form file and actual data such as a component XRT file linked thereto, an external resource file, and user data. A file can be used instead of the form generation information file. Needless to say, the XRF file in this case describes the file names of the component files, the update date and time information of those files, and the parameters for setting cache inhibition as required.
[0182]
The caching of the component data of the XRF file can also be performed in the client 20. For example, a cache area may be provided in the storage device 217 of the client 20, and the component area of the form data (XRF file) may be cached using this cache area as a cache unit. In this case, whether or not to cache is determined by the internal processing of the client 20 according to the parameter for setting cache prohibition in the form generation information file. Since caching of user data is generally unnecessary, caching of user data may be prevented by setting an application on the client 20 side.
[0183]
However, since the proxy server generally has a larger storage capacity, it can store more cache data, and the efficiency of the cache increases. Further, since a plurality of clients 20 share a common cache area, the cache efficiency is improved as compared with the case where caching is performed by individual clients 20.
[0184]
When data to be cached is acquired from a Web browser using the HTTP protocol, the acquired data is automatically cached in the proxy server when a proxy server is used. Setting to prevent the proxy server from caching.
12. Changing the characteristics of drawing objects on the client
FIG. 33 is a block diagram for explaining another configuration example of the server 10 used in the electronic document system having the configuration of FIG. In FIG. 33, the portions having the same functions as those shown in FIG. 30 are denoted by the same reference numerals as in FIG. Since the configuration of the client 20 is the same as that of FIG. 31, the following description will also refer to FIG.
[0185]
In this embodiment, a process of embedding a drawing object having a property corresponding to user data in a form is performed in the client 20, and an XRF file as form data in which the drawing object is embedded is created in the client 20.
[0186]
The business application on the server 10 side, along with the function of the request data analysis unit 131, writes a drawing object having a property corresponding to the user data specified by the form data request from the client 20 in the XRT file by specifying the position. It has the function of a drawing object write command generation unit 138 that writes a command (drawing object write command) to the form generation information file.
[0187]
On the client 20 side, the drawing object write command in the form generation information file is interpreted and executed by the data combination processing unit 229 constituted by the XML application. As a result, the properties (arrangement position, shape, size, etc.) of the drawing object specified by the command are written in the XRT file. That is, the data combination processing unit 229 has a function of interpreting the drawing object write command and writing the drawing object in the XRT file.
[0188]
FIG. 34 is a block diagram illustrating the configuration of an electronic form system including the server 10 of FIG. 33 and the client 20 of FIG. When the user of the client 20 operates the input device 213 to input required information to the Web browser 221, a form data request corresponding to the input content is transmitted from the Web browser 221 to the request data analysis unit 131 via the application server 117. (Arrow D1).
[0189]
The request data analysis unit 131 creates a form generation information file based on the form data request given from the Web browser 221. Further, the request data analysis unit 131 reads the user data specified by the form data request from the storage device 15 and creates a user data file.
[0190]
If the form (XRT file) corresponding to the form data request is a form in which a drawing object whose properties are determined according to the user data is to be embedded, the drawing object write command generation unit 138 outputs the request data analysis unit. The user data is obtained from arrow 131 (arrow D3), and a drawing object write command for embedding the drawing object of the property corresponding to the user data in the form by designating the form is written in the form generation information file (arrow D4). ).
[0191]
If the form data corresponding to the form data request includes component data for which cache prohibition is set, a parameter indicating cache prohibition is set by the cache prohibition data setting unit 1313 (not shown in FIG. 34). Is written in the form generation information file.
[0192]
The request data analysis unit 131 gives the form generation information file in which the drawing object write command and various parameters are described and the user data file to the form generation information file reading unit 1311 (arrow D5).
[0193]
When a form generation information file and a user data file are provided to the form generation information file reading unit 1311, an XML parser, a DOM file or a SAX file is read from the storage device 115, and the XML application 133 is activated. The XML application 133 reads the file name of the component file of the XRT file corresponding to the form data request and the update date / time information of the file from the storage device 115 based on the form generation information file 140 (arrow D6), and updates the date / time information. A form generation information file with a tag is created and transmitted from the application server 117 to the cache determination unit 224 of the client 20 (arrow D7). At this time, the user data file is also transmitted to the client 20 and given to the data combination processing unit 229.
[0194]
The cache determination unit 224 that has received the form generation information file stores the form generation information file among the component files (XRT file, DTD file, field information, component XRT file, or external resource file) stored in the proxy server 40. Identify the described file. Further, it specifies a component file whose update date information of the specified component file on the proxy server 40 matches the update date information of the component file indicated in the form generation information file, and requests transmission of the component file. (Arrow D8). In response, the proxy server 40 provides the component file specified by the cache determination unit 224 and requested to be transmitted to the data combination processing unit 229 of the client 20 (arrow D9).
[0195]
In addition, the cache determination unit 224 is configured not to receive, from the proxy server 40, a configuration element file (XRT file, DTD file, field information, component XRT file, or external resource file) indicated in the form generation information file. The missing file transmission request specifying the element file is transmitted to the request data analysis unit 131 via the Web browser 221 and the application server 117 (arrow D10). At this time, whether or not each component file can be cached in the proxy server 40 is set in the HTTP protocol.
[0196]
Upon receiving the missing file transmission request, the request data analysis unit 131 reads from the storage device 115 the component file (XRT file, DTD file, field information, component XRT file, or external resource file) corresponding to the missing file request (arrow). D11). The read component file is provided from the application server 117 to the data combination processing unit 229 via the proxy server 40 and the Web browser 221 (arrow D12). If the prohibition of caching is set by the HTTP protocol at the time of transmitting the insufficient file transmission request from the Web browser 221, the component file transmitted from the server 10 is not cached in the proxy server 40, and If the prohibition of caching is not set, the component file transmitted from the server 10 is cached in the proxy server 40.
[0197]
The data combination processing unit 229 combines the constituent element files (XRT file, DTD file, field information, component XRT file or external resource file) and user data provided from the server 10 and the proxy server 40, and further forms report generation information. By writing a new drawing object in the XRT file in accordance with the drawing object write command in the file, an XRF file as form data is created.
[0198]
The created XRF file is provided to the XRF reader 222 (arrow D18). The XRF reader 222 that has received the XRF file creates a form image by expanding the XRF file into image data and displays the form image. When a predetermined print instruction operation is performed from the input device 213 while the form image is being displayed, print data corresponding to the form image is created and transmitted to the printer 30 via the printer driver 223. It is transmitted (arrow D19). As a result, paper carrying the form image is output from the printer 30. In this way, it is possible to obtain a form in which a drawing object having a property (particularly a form) according to the user data is embedded.
[0199]
Further, on the client 20 side, instead of processing for changing the properties of the existing drawing object, processing for generating a new drawing object based on the command in the form generation information file is performed by the XML application. Does not require business logic. Therefore, maintenance and management of the program in the plurality of clients 20 are facilitated.
[0200]
Moreover, since the proxy server 40 is used as a cache, the component data of the XRF file is acquired from the proxy server 40, and the client 20 creates the XRF file, the load on the network can be significantly reduced.
[0201]
Also in this configuration example, instead of transmitting the form generation information file from the server 10 to the client 20, an XRF file without actual data may be transmitted.
[0202]
Further, the client 20 may cache the component data of the XRF file.
13. Embodiment in which user authentication is possible
FIG. 35 is a block diagram for explaining a configuration example of the server 10 according to still another embodiment of the present invention. 35, the same components as those shown in FIG. 4 described above are denoted by the same reference numerals as in FIG. 4, and the description thereof is omitted.
[0203]
The electronic form system of this embodiment has the same overall configuration as the configuration shown in FIG. 29 described above. However, in the electronic form system of this embodiment, a client terminal capable of requesting and outputting form data is set in advance, and by authenticating the client, the request of form data and the output of the form can be restricted except for a specific terminal. It has become.
[0204]
The server 10 includes an authentication unit 1314 and a log creation unit 1315 as function processing units of the business application, and these are controlled by the control unit 130.
[0205]
The authentication unit 1314 refers to the “user name” and “password” of the administrator of the client 20 stored in the storage device 115 in advance. When the “user name” and “password” of the administrator of the client 20 are given to the server 10 from the client 20 while the connection between the server 10 and the client 20 via the Internet is established, the authentication unit 1314 It is determined whether or not the “user name” and “password” given by the client 20 match the “user name” and “password” stored in the storage device 115. If it is determined that they match, the administrator of the client 20 can perform a predetermined operation from the input device 213 to set a form that the client 20 is permitted to provide. That is, the specific client 20 can be set as a terminal for outputting a specific form.
[0206]
When such a setting is performed, the authentication unit 1314 transmits to the client 20 Cookie, which is transmission permission information for permitting transmission of the form data of the form. When the Cookie is transmitted from the server 10 to the client 20, the Cookie is stored in the storage device 217 of the client 20. When the client 20 receiving the Cookie is again connected to the server that transmitted the Cookie via the Internet, the client 20 gives the Cookie to the server 10.
[0207]
When the user connects to the server 10 by using the client 20 having a cookie indicating permission to transmit the form data, the cookie is provided to the authentication unit 1314 via the application server 117. Then, the authentication unit 1314 provides the form data that can be provided to the client 20 according to the contents of the cookie transmitted from the client 20, and restricts the transmission of the other form data.
[0208]
On the other hand, while the connection between the client 20 having the Cookie indicating transmission permission of the form data and the server 10 via the Internet is established, the “user name” and “password” of the administrator of the client 20 are changed from the client 20. It may be given to the server 10. At this time, the authentication unit 1314 determines whether the “user name” and “password” given by the client 20 match the “user name” and “password” stored in the authentication unit 1314. After the match is confirmed, when the administrator of the client 20 performs a predetermined release operation from the input device 213, the setting of the permission to transmit the form data that has been permitted to be provided to the client 20 can be released. It has become. When the transmission permission setting is released, the authentication unit 1314 can transmit to the client 20 a Cookie for which the transmission permission setting of the form data has been released.
[0209]
By using the client 20 having a Cookie (or not having such a Cookie) in a state where the transmission permission setting of the form image is released (that is, a state in which the transmission permission is not set), the user can use the server 10. When the Cookie is connected to the Cookie, the Cookie for which the form data transmission permission setting is not given is given to the authentication unit 1314 via the application server 117 (or the Cookie is not given). The authentication unit 1314 that has received the Cookie for which the form data transmission permission setting has not been set (or did not receive the Cookie) prohibits the transmission of the requested form data to the client 20.
[0210]
The log creating unit 1315 can cause the storage device 115 to store the date and time information when the XRF file or PDF file created by the XML application 133 is transmitted to the client 20. That is, a transmission record (log) of the form data file transmitted from the server 10 to the client 20 can be created.
[0211]
FIG. 36 is a block diagram for explaining a configuration example of the client 20 in this embodiment. 36, the same components as those shown in FIG. 6 are denoted by the same reference numerals as in FIG. 6, and the description thereof will be omitted.
[0212]
In this configuration, the storage device 217 is provided in the client 20. The storage device 217 can store a Cookie provided from the server (including the server 10) to the control unit 220. When the connection with the server (including the server 10) to which the Cookie has been previously given is re-established, the control unit 220 reads out the Cookie previously given from the server from the storage device 217. And send it to that server.
[0213]
The client 20 further includes a display control unit 225, a log creation unit 226, an output information display prohibition unit 227, and a user authentication unit 228, which are controlled by the control unit 220.
[0214]
The display control unit 225 displays the form on the display device 214 from the time when the form data request is transmitted to the server 10 and the form printing is instructed until the form image corresponding to the form data request is completely printed by the printer 30. The screen is fixed to the system modal screen, and an operation signal from the input device 213 to the control unit 230 is invalidated.
[0215]
The log creation unit 226 determines the date and time information when the form data request was transmitted from the client 20 to the server 10, the date and time when the XRF file or PDF file received from the server 10 was received, and the date and time when the print data was transmitted to the printer 30. The log (form output record) including the information, the date and time information when the print end signal indicating the completion of the printing of the print data given from the printer 30 is received, and the information on the form type can be stored in the storage device 217. Further, the administrator of the client 20 can browse logs stored in the storage device 217 by performing a predetermined operation from the input device 213.
[0216]
The output information display prohibition unit 227 performs control to prohibit display of a form image in accordance with the setting of the parameter in the XRF file.
[0219]
The user name and password of the user of the client 20 are stored in the storage device 217 and managed by the user authentication unit 228. Then, it is possible to determine whether or not the user name and password input from the input device 213 match the user name and password stored in the storage device 217. Unless the user authentication unit 228 determines that the user name and password input from the input device 213 match the user name and password stored in the storage device 217, the user can output the form using the client 20. You can't do that.
[0218]
FIG. 37 is a block diagram for explaining a conceptual configuration of an electronic form system including the server 10 of FIG. 35 and the client 20 of FIG. 36. FIG. 38 is a diagram for accepting the setting of form data transmission permission. FIG. 39 is a diagram illustrating an example in which the web browser 221 displays the reception screen (menu screen) for receiving the input of the form data request.
[0219]
The administrator of the client 20 receives the HTML file or the like from the application server 117 by inputting the URL of the server 10 into the URL input unit of the Web browser 221 and performing a predetermined operation from the input device 213, and The display unit 231 of FIG. 221 can perform a display as shown in FIG. FIG. 38 is a reception screen for receiving the transmission permission setting of the form data of the receipt provided from the server 10 to the client 20. Near the center of the display unit, a user name input unit 236 for inputting the user name of the administrator of the client 20 and a password input unit 237 for inputting the password of the administrator of the client 20 are displayed. Below the user name input section 236 and the password input section 237, a “designate terminal” button 238 and a “terminal designation release” button 239 are displayed. In the reception screen, a pointer (not shown) is displayed on the Web browser 221. When the user operates the input device 213 (mainly a pointing device), the pointer is displayed on the button 238 or 239. And the button 238 or 239 can be pressed (clicked).
[0220]
When the user name of the manager of the client 20 is input to the user name input section 236 and the password of the administrator of the client 20 is input to the password input section 237, and the "designate terminal" button 238 is pressed (arrow F1). The authentication unit 1314 performs an authentication process, and on the condition that the user name and the password match those registered in advance, a Cookie (registered ID as terminal identification information) indicating permission to transmit the form data of the receipt. Is transmitted to the client 20 (arrow F2). The client 20 stores the Cookie in the storage device 217. As a result, the client 20 is set as a terminal capable of receiving the form data of the receipt. The authentication of the user may be performed by biometric authentication using a fingerprint or a palm print, or authentication using an ID card.
[0221]
On the other hand, when the Cookie indicating transmission permission of the receipt form data is stored in the storage device 217 of the client 20, the client 20 inputs the user name of the administrator of the client 20 to the user name input section 236 by the password input section. When the password of the administrator of the client 20 is input to 237 and the “terminal designation release” button 239 is pressed (arrow G1), the authentication unit 1314 executes an authentication process, and the user name and password are registered in advance. On the condition that the received data matches the cookie, the Cookie of the content whose transmission permission of the form data of the receipt has been released is transmitted to the client 20 (arrow G2). The client 20 stores the Cookie in the storage device 217. As a result, the client 20 is in a state where it cannot receive the form data of the receipt.
[0222]
When the user inputs the URL of the server 10 into the URL input unit 230 of the Web browser 221, all the cookies stored in the storage device 217 are transmitted to the authentication unit 1314 (arrow F3). The authentication unit 1314 selects a file described in HTML or the like according to the Cookie provided from the client 20. Then, the application server 117 transmits the file described in the HTML or the like to the client 20 (arrow F4). Therefore, the content displayed on the display device 214 of the client 20 differs depending on the content of the cookie given from the client 20 to the server 10.
[0223]
For example, the client 20 having no Cookie provided by the server 10 or the Cookie having no permission to transmit receipt form data stored in the storage device 217 and the client 20 and the server 10 are connected via the Internet. Upon connection, a screen as shown in FIG. 39A is displayed on the display unit 231 of the Web browser 221 of the client 20. On the screen of FIG. 39 (a), it is displayed that the client 20 cannot provide the form data of the receipt. Thereafter, a screen as shown in FIG. 39B is displayed on the display unit 231 of the Web browser 221 of the client 20.
[0224]
FIG. 39 (b) shows an example of a main menu screen for selecting a form type. In this example, a “proposal” button 2310 and an “application” button are displayed on the display unit 231 of the Web browser 221. 2311, a “receipt” button 2312 and a “receipt” button 2313 are displayed. The “receipt” button 2312 is, for example, grayed out (display state indicating an inoperable state; indicated by diagonal lines in the drawing) and is inoperable, and cannot be pressed. . That is, the user cannot enter the Web page linked to the “receipt” button 2312, and cannot transmit the form data request for the receipt to the server 10. When the "receipt" button 2321 is operated from an unauthenticated terminal instead of disabling the "receipt" button 2321, the server 10 notifies the terminal that the receipt cannot be printed. An HTML file or the like for displaying a screen to be displayed may be transmitted.
[0225]
On the other hand, when the URL of the server 10 is input to the URL input unit 230 of the Web browser 221 of the client 20 having the Cookie to which the form data transmission permission is set, a screen as shown in FIG. 39C is displayed. In the screen of FIG. 39C, a “Proposal” button 2310, an “Application” button 2311, a “Receipt” button 2312, and a “Receipt” button 2313 are displayed on the display unit 231 of the Web browser 221. I have. All buttons are in an operable state, and the user can transmit to the server 10 requests for all the form data (proposal, application, receipt, and receipt) that can be provided from the server 10.
[0226]
As described above, the form data request may be restricted according to the content of the cookie transmitted from the client 20 to the server 10. The user can transmit the form data transmission request to the request data analysis unit 131 within the range of this restriction (arrow F5 in FIG. 37).
[0227]
When a form data request is given to the request data analysis section 131, the request data analysis section 131 writes information (commands and parameters) for generating form data corresponding to the form data request in a form generation information file in XML. Create Further, the request data analysis unit 131 reads out user data corresponding to the form data request from the storage device 115 and creates a user data file.
[0228]
The form generation information file and the user data file generated by the request data analysis unit 131 are transmitted to the data collection / combination processing unit 132 (arrows F6 and F7).
[0229]
Upon receiving the form generation information file and the user data file, the data collection / processing combination unit 132 reads the XML parser and the DOM file or the SAX file from the storage device 115 (arrow F8), and starts the XML application 133. Let it.
[0230]
If the PDF file format is not specified as the output file mode of the form data in the output file mode description section of the form generation information file, the XRF file creation section 134 of the XML application 133 generates an XRT file based on the form generation information file. , DTD file, field information, component XRT file, and external resource file 127 are read from the storage device 115 as needed and collected (arrow F9), and they are combined, and the XRF file is combined by further combining the user data. create.
[0231]
The created XRF file is transmitted from the application server 117 to the client 20 (arrow F13), and is processed by the XRF reader 222. The XRF reader 222 creates a form image from the XRF file. Then, print data corresponding to the form image is created and transmitted to the printer 30 via the printer driver 223 (arrow F14).
[0232]
When the PDF file format is specified as the output file mode of the form data in the output file mode description section 1411 of the form generation information file 140, the PDF file creation section 135 of the XML application 133 performs the processing based on the form generation information file. The XRT file file, the DTD file, the field information, the component XRT file, and the external resource file 127 are read and collected from the storage device 115 as needed (arrow F9), and they are combined, and further, the user data is combined, and To create a PDF file. This PDF file is provided to the Web browser 221 of the client 20 via the application server 117 (arrow F11). When the user performs a predetermined operation on the input device 213 while the Web browser 221 is displaying the received PDF file, print data corresponding to the form data in the PDF format is created, and the printer driver 223 Is transmitted to the printer 30 (arrow F12).
[0233]
When the XRF file or the PDF file is transmitted from the application server 117 to the client 20, the log creating unit 1315 creates a log indicating that the XRF file or the PDF file has been sent to the client 20, and writes the log into the storage device 115. This log includes date and time, job name, form number, form name, number of sheets, necessity of trail management, and the like.
[0234]
FIG. 40 is a flowchart for explaining the control operation of the client 20. The client 20 can perform an operation for form output by the user authentication unit 228 unless the user name and password input from the input device 213 match the user name and password stored in the storage device 217. I cannot do it. If the user name and password input from the input device 213 match the user name and password stored in the storage device 217 (step S10), the control unit 220 determines whether the printer 30 is in a printable state. Is performed (step S11). If the printer 30 is not in a printable state (No in step S11), an error is displayed on the display device 214 (step S28), and the process is forcibly terminated. In this case, the user waits until the printer 30 is ready to print, contacts the administrator to notify the printer 30 of an abnormality, or cancels printing of the form.
[0235]
When the printer 30 is in a printable state (Yes in step S11), an input of a form data request desired by the user is accepted, and the input form data request is transmitted to the server 10 (step S12). Then, a transmission log is created by the log creation unit 226 and stored in the storage device 217 (step S13). This transmission log includes information such as the date and time when the form data request was transmitted to the server 10, the job name, the form number, the form name, the number of sheets, and the necessity of trail management.
[0236]
Thereafter, in accordance with the setting of the parameters in the XRF file, the display screen of the display device 214 is fixed to the system modal screen by the output information display setting unit 225 (step S14), no input operation is accepted, and the form printing is canceled. It is determined that the printing process cannot be performed, and the printing process is performed in the background. The system modal screen may be a screen on which a user inputs a request for desired form data.
[0237]
Thus, the user cannot operate the client 20 after inputting the request for the form data. Therefore, it is not possible to cancel the printing process in the middle of printing a form and output a form in an unprinted state or a form incompletely printed. Can be prevented.
[0238]
After the form data request is transmitted to the server 10, the client 20 receives the XRF file from the server 10 (step S15), and the log creating unit 226 creates a reception log related to the reception of the XRF file or the PDF file, and stores the received log in the storage device. 217 (step S16). The reception log includes information such as a reception date and time, a job name, a form number, a form name, the number of sheets, and necessity of trail management.
[0239]
On the other hand, according to the setting of the parameter in the XRF file, the display of the form image is prohibited by the output information display prohibiting unit 227 (step S17). Accordingly, it is possible to prevent a fraud such as copying a form image displayed on the display device 214 to create a form.
[0240]
Thereafter, the XRF reader 222 is activated, and the XRF reader 222 automatically creates a form image from the XRF file (step S18). Then, the control unit 220 determines whether the printer 30 is capable of printing (step S19). If the printer 30 cannot perform printing (No in step S19), the system modal screen is terminated (step S27), and an input operation is enabled. Then, an error message is displayed (step S28), and the printing process is forcibly terminated.
[0241]
If the printer 30 is capable of printing (Yes in step S19), the XRF reader 222 creates print data corresponding to the form image, and sends the print data to the printer 30 (step S20). Then, a print data sending log is created by the log creating unit 226 and stored in the storage device 217 (step S231). The print data transmission log includes information such as the date and time when the print data transmission is completed (the data output from the spool to the printer is completed), the job name, and the spool output result.
[0242]
On the other hand, after the print data is sent to the printer 30 by the background processing, a print completion notification that the print data has been printed is given to the client 20 from the printer 30 (step S22).
[0243]
Then, the log creation unit 226 creates a print completion log and stores it in the storage device 217 (step S23). Then, the system modal screen ends (step S25), and the state returns to a state where an input operation is possible. The print completion log includes information such as the date and time when the print completion notification is received, the job name, the number of sheets, tray information, paper information, output results, and the like.
[0244]
Since the log is created in each step of the printing process as described above, when a malfunction occurs during the printing process, it is possible to specify at which point the malfunction occurred. Thus, for example, it is possible to specify whether printing was not really performed or whether the output paper was lost despite printing, and illegal use of a form can be effectively prevented.
[0245]
Instead of authenticating the terminal using Cookie, a file for determining that the terminal is a terminal permitted to print a specific form such as a receipt is stored in the storage device 217, and the file is determined by applet. The terminal may be authenticated by determining whether or not the terminal exists.
14． Other embodiments
In the above embodiment, the server 10 and the client 20 exchange data via the Internet. However, the server 10 and the client 20 may exchange data using a dedicated network of a company or the like.
[0246]
When many clients 20 exist in the same building or the same office, the server 10 may be installed in the building or the office to manage the clients 20 in the building or the office. At this time, the server 10 and the client 20 may exchange data via a LAN instead of exchanging data via the Internet.
[0247]
Further, it is not necessary that only one server 10 exists in a network such as the Internet, and a configuration in which a plurality of servers 10 are connected to the network may be employed.
[0248]
In addition, various design changes can be made within the scope of the matters described in the claims.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an overall configuration of an electronic form system according to an embodiment of the present invention.
FIG. 2 is a block diagram illustrating an electrical configuration of a server.
FIG. 3 is a block diagram for explaining a file stored in a storage device of a server.
FIG. 4 is a block diagram illustrating a functional configuration of a server.
FIG. 5 is a block diagram illustrating an example of an electrical configuration of a client.
FIG. 6 is a block diagram illustrating a functional configuration of a client.
FIG. 7 is a block diagram for explaining a conceptual configuration of an electronic form system constituted by a server and a client.
FIG. 8 is a diagram showing an example in which a reception screen for receiving input of a form data request is displayed by a Web browser.
FIG. 9 is a diagram illustrating an example of an XML file created as a form generation information file by a request data analysis unit.
FIG. 10 is a flowchart illustrating an operation of a data collection / combination processing unit that receives a form generation information file and a user data file.
FIG. 11 is a flowchart illustrating the operation of an XML application.
FIG. 12 is a conceptual diagram illustrating the configuration of an XRT file, which is one of the main components of the XRF file.
FIG. 13 is a block diagram illustrating a configuration of an XRT file.
FIG. 14 is a diagram illustrating a specific configuration example of an XRT file.
FIG. 15 is a block diagram illustrating a configuration of an XRF file.
FIG. 16 is an illustrative flowchart for explaining a process of generating a form image based on an XRF file;
FIG. 17 is a conceptual diagram for explaining a typical use mode of a component XRT file.
FIG. 18 is a diagram illustrating a display example of an XRF reader that has received an XRF file.
FIG. 19 is a conceptual diagram for describing an example of editing a component XRT file.
FIG. 20 is a conceptual diagram for describing the effect of using a component XRT file.
FIG. 21 is a block diagram for explaining a server configuration example provided with a function for changing the appearance of a form according to user data.
FIG. 22 is a conceptual diagram for explaining selection of an image file according to user data.
FIG. 23 is a conceptual diagram illustrating an example of form data (XRF file) provided from a server to a client.
FIG. 24 is a block diagram for explaining another configuration example of a server used to change the appearance of a form according to user data.
FIG. 25 is a diagram illustrating a display example of a property editing dialog of a drawing object corresponding to a rectangular figure.
FIG. 26 is a conceptual diagram for explaining deformation of a rectangular figure caused by changing a property of a drawing object according to a value of user data.
FIG. 27 is a conceptual diagram illustrating an example of form data provided from a server to a client.
FIG. 28 is a block diagram for describing a configuration of an electronic form system that realizes a function of changing a property of a drawing object according to user data.
FIG. 29 is a block diagram showing the overall configuration of an electronic form system according to another embodiment of the present invention.
FIG. 30 is a block diagram for explaining a configuration example of a server in this embodiment.
FIG. 31 is a block diagram illustrating a configuration example of a client in the electronic form system according to the embodiment.
FIG. 32 is a block diagram for explaining the operation of an electronic form system including the server of FIG. 30 and the client of FIG. 31;
FIG. 33 is a block diagram for explaining another configuration example of the server used in the electronic document system having the configuration of FIG. 29;
FIG. 34 is a block diagram for explaining a configuration of an electronic form system including the server of FIG. 33 and the client of FIG. 31;
FIG. 35 is a block diagram illustrating a configuration example of a server according to still another embodiment of the present invention.
36 is a block diagram for describing a configuration example of a client in the embodiment of FIG. 35.
FIG. 37 is a block diagram illustrating a conceptual configuration of an electronic form system including the server of FIG. 35 and the client of FIG. 36;
FIG. 38 is a diagram showing an example in which a reception screen for receiving the setting of form data transmission permission is displayed by a Web browser.
FIG. 39 is a diagram showing an example in which a reception screen (menu screen) for receiving an input of a form data request is displayed by a Web browser.
FIG. 40 is a flowchart illustrating a control operation of the client.
[Explanation of symbols]
10 Server
115 Storage
117 Application Server
1200 Parts Server
130 control unit
131 Request Data Analysis Unit
132 Data collection and combination processing unit
133 XML application
134 XRF file creation unit
135 PDF file creation unit
136 Image file setting section
137 Property change processing unit
138 drawing object write command generation unit
1313 Cache prohibited data setting unit
1311 Form generation information file reading unit
1314 Authentication Department
1315 Log creation unit
20 clients
213 Input device
214 display device
215 Network Interface
220 control unit
221 Web Browser
222 XRF reader
222a print control unit
223 Printer Driver
224 Cache determination unit
225 Display control unit
226 Log creation unit
227 Output information display prohibition unit
228 User authentication unit
229 Data merge processing unit
30 Printer
40 proxy server
50 LAN

Claims (4)

複数種類の帳票フォームデータを記憶する帳票フォームデータ記憶手段と、
複数種類の帳票フォームデータ内に共通に設定された部品配置領域にリンクされた部品データを記憶する部品データ記憶手段と、
帳票の種類を指定した帳票データ要求を受け付ける帳票データ要求受付手段と、
この帳票データ要求受付手段によって受け付けられた帳票データ要求に対応する帳票フォームデータを上記帳票フォームデータ記憶手段から読み出し、かつ、この読み出された帳票フォームデータ内に設定された部品配置領域にリンクされた部品データを上記部品データ記憶手段から読み出し、これらの帳票フォームデータおよび部品データを結合して帳票データを生成する帳票データ生成手段とを含むことを特徴とする帳票発行装置。A form data storage means for storing a plurality of types of form data;
Component data storage means for storing component data linked to a component placement area commonly set in a plurality of types of form form data;
A form data request receiving means for receiving a form data request specifying a form type;
The form data corresponding to the form data request received by the form data request receiving means is read from the form data storage means, and is linked to the component arrangement area set in the read form data. And a form data generating means for reading the part data from the part data storage means and combining the form data and the part data to generate form data. 上記部品データ記憶手段は、部品データにリンクされた部品配置領域が設定された部品フォームデータを上記帳票フォームデータのための部品データとして記憶していることを特徴とする請求項１記載の帳票発行装置。2. The form issuance according to claim 1, wherein said part data storage means stores part form data in which a part arrangement area linked to the part data is set as part data for said form form data. apparatus. 上記帳票発行装置は、ネットワークに接続されたサーバであり、
上記帳票データ要求受付手段は、上記ネットワークに接続されたクライアントから送られてくる帳票データ要求を受信する手段を含み、
上記帳票発行装置は、さらに、上記帳票データを上記ネットワークを介して上記クライアントに送出する手段を含むことを特徴とする請求項１または２記載の帳票発行装置。The form issuing device is a server connected to a network,
The form data request receiving means includes means for receiving a form data request sent from a client connected to the network,
3. The form issuing apparatus according to claim 1, wherein the form issuing apparatus further includes a unit that sends the form data to the client via the network. 請求項３記載の帳票発行装置と、
上記ネットワークに接続され、上記帳票データ要求を当該ネットワークを介して上記帳票発行装置に送信する手段、および上記帳票発行装置から上記ネットワークを介して送られてくる上記帳票データを受信する手段を有するクライアントとを含むことを特徴とする電子帳票システム。A form issuing device according to claim 3,
A client connected to the network and having means for transmitting the form data request to the form issuing apparatus via the network, and means for receiving the form data transmitted from the form issuing apparatus via the network; An electronic form system comprising:
JP2002378319A 2002-12-26 2002-12-26 Business form issuing apparatus, and electronic business form system using the same Pending JP2004213075A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002378319A JP2004213075A (en) 2002-12-26 2002-12-26 Business form issuing apparatus, and electronic business form system using the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002378319A JP2004213075A (en) 2002-12-26 2002-12-26 Business form issuing apparatus, and electronic business form system using the same

Publications (1)

Publication Number Publication Date
JP2004213075A true JP2004213075A (en) 2004-07-29

Family

ID=32815228

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002378319A Pending JP2004213075A (en) 2002-12-26 2002-12-26 Business form issuing apparatus, and electronic business form system using the same

Country Status (1)

Country Link
JP (1) JP2004213075A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006065827A (en) * 2004-08-30 2006-03-09 Toramatsu Shintani Business form holding, business form editing and business form sharing program
JP2009075723A (en) * 2007-09-19 2009-04-09 Nec Corp Document processor, document processing method, program, and data structure of document file
US8667383B2 (en) 2010-03-09 2014-03-04 David Schnitt Unified electronic forms management system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006065827A (en) * 2004-08-30 2006-03-09 Toramatsu Shintani Business form holding, business form editing and business form sharing program
JP2009075723A (en) * 2007-09-19 2009-04-09 Nec Corp Document processor, document processing method, program, and data structure of document file
US8667383B2 (en) 2010-03-09 2014-03-04 David Schnitt Unified electronic forms management system

Similar Documents

Publication Publication Date Title
US6883981B2 (en) Printing control method and apparatus
US7688459B2 (en) Document processing method
US7929157B2 (en) Information processing apparatus and method
US7606823B2 (en) Document processing apparatus and method
US8775313B2 (en) Printing control method, apparatus and storage medium therefor, and printing system
US8089653B2 (en) Document processing apparatus, method and program for variable printing with document file dividing
JP4110147B2 (en) Information leakage prevention method, information processing apparatus and driver program for realizing the method
US7379950B2 (en) Document processing method, program and apparatus for processing a document file in pages
JP4900937B2 (en) Information processing apparatus, control method therefor, and program
JP2003091407A (en) Information processing system, its display method, its program and recording medium
US20100131566A1 (en) Information processing method, information processing apparatus, and storage medium
US20030184806A1 (en) Displaying of print layout
JP2004213072A (en) Business form data server and electronic business form system using the same
US20050137883A1 (en) Business form issuing apparatus and electronic business form system
US20050137885A1 (en) Business form data generating apparatus and electronic business form system
JP4164488B2 (en) Information leakage prevention method, information processing apparatus and driver program for realizing the method
US20030051625A1 (en) Information processing method, information processing apparatus, and printing appartus
JP2004213075A (en) Business form issuing apparatus, and electronic business form system using the same
JP4126227B2 (en) Form issuing device and electronic form system using the same
JP2004213070A (en) Apparatus for issuing business form, and electronic business form system using the same
JP2004213074A (en) Apparatus for issuing business form, and electronic business form system using the apparatus
JP2004213073A (en) Apparatus for generating business form data, and electronic business form system using the same
JP2004213071A (en) Device for generating business form data, and electronic business form system using the same
US8526026B2 (en) Document processing apparatus, document processing method, and program for preventing the printing of multiple unauthorized copies
JP3399461B2 (en) Printing system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050608

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070904

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080108