(57)【要約】【課題】  データに所定の処理を施した後、電子署名を付加する情報処理装置において、不適当なデータに対して電子署名が付加されるのを回避することを目的とする。【解決手段】  ネットワークより受信した入力データ（Ｄ４１２）を処理しＰＤＦファイル（Ｄ４１５）を生成した後、電子署名を付加して該ネットワークに送信するＷｅｂサーバ（４１０）および監視クライアント（４３０）における電子署名付加方法であって、入力データ（Ｄ４１２）とＰＤＦファイル（４１５）とを表示する工程（ステップＳ４３２）と、ＰＤＦファイル（Ｄ４１５）に対する電子署名について許否の指示を入力する工程（ステップＳ４３３）と、ＰＤＦファイル（Ｄ４１５）に対する電子署名について許可する旨の指示が入力された場合に、ＰＤＦファイル（Ｄ４１５）に電子署名を付加する工程（ステップＳ４１９）とを備える。【選択図】  図４
2006101218.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークより受信した第１のデータを処理し第２のデータを生成した後、該第２のデータに電子署名を付加して該ネットワークに送信する情報処理装置であって、
前記第１のデータと前記第２のデータとを表示する表示手段と、
前記第２のデータに対する電子署名についての許否の指示を入力する入力手段と、
前記入力手段より、前記第２のデータに対する電子署名について許可の指示が入力された場合に、前記第２のデータに電子署名を付加する付加手段と
を備えることを特徴とする情報処理装置。
【請求項２】
ネットワークより受信した第１のデータを処理し第２のデータを生成した後、該第２のデータに電子署名を付加して該ネットワークに送信する情報処理装置であって、
前記第１のデータと前記第２のデータとを解析する解析手段と、
前記解析手段による解析結果が、予め設定された条件を具備するか否かを判定する判定手段と、
前記判定手段により、前記条件を具備すると判定された場合に、前記第２のデータに電子署名を付加する付加手段と
を備えることを特徴とする情報処理装置。
【請求項３】
前記第１のデータを受信した日時と、前記入力手段により入力された前記電子署名についての許否の指示とを所定のＩＤとともにログとして保存する第１の保存手段と、
前記第１のデータと前記第２のデータとを前記ＩＤと関連付けて保存する第２の保存手段と
を備えることを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記第１のデータを受信した日時と、前記判定手段による判定結果とを所定のＩＤとともにログとして保存する第１の保存手段と、
前記第１のデータと前記第２のデータとを前記ＩＤと関連付けて保存する第２の保存手段と
を備えることを特徴とする請求項２に記載の情報処理装置。
【請求項５】
前記付加手段は、
前記解析手段による前記第１のデータに対する解析結果が、予め設定されたいずれの条件を具備するかによって、前記第２のデータに付加する電子署名に用いる署名鍵の種類を変更することを特徴とする請求項２に記載の情報処理装置。
【請求項６】
前記付加手段は、
前記解析手段による前記第２のデータに対する解析結果が、予め設定されたいずれの条件を具備するかによって、前記第２のデータに付加する電子署名に用いる署名鍵の種類を変更することを特徴とする請求項２に記載の情報処理装置。
【請求項７】
ネットワークより受信した第１のデータを処理し第２のデータを生成した後、該第２のデータに電子署名を付加して該ネットワークに送信する電子署名付加方法であって、
前記第１のデータと前記第２のデータとを表示する表示工程と、
前記第２のデータに対する電子署名についての許否の指示を入力する入力工程と、
前記入力工程より、前記第２のデータに対する電子署名について許可の指示が入力された場合に、前記第２のデータに電子署名を付加する付加工程と
を備えることを特徴とする電子署名付加方法。
【請求項８】
ネットワークより受信した第１のデータを処理し第２のデータを生成した後、該第２のデータに電子署名を付加して該ネットワークに送信する電子署名付加方法であって、
前記第１のデータと前記第２のデータとを解析する解析工程と、
前記解析工程による解析結果が、予め設定された条件を具備するか否かを判定する判定工程と、
前記判定工程により、前記条件を具備すると判定された場合に、前記第２のデータに電子署名を付加する付加工程と
を備えることを特徴とする電子署名付加方法。
【請求項９】
請求項７または請求項８のいずれかに記載の電子署名付加方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項１０】
請求項７または請求項８のいずれかに記載の電子署名付加方法をコンピュータによって実現させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークより受信したデータに対して変換・整形・フィルタリングなどの処理を施し、当該処理後のデータに電子署名を付加してネットワークに返信する情報処理装置における処理技術に関するものである。
【背景技術】
【０００２】
一般クライアントからサーバに特定の形式のデータを送信し、サーバでその入力データに対して変換・整形・フィルタリングなどの処理を施し、その結果の出力データに対して電子署名を付加して一般クライアントに返信するネットワークシステムが一般に知られている（例えば特許文献１参照）。当該ネットワークシステムにおいては、通常、サーバは一般クライアントの正当性をそのＩＰアドレスによって認証することとしている。このため、一旦サーバと一般クライアントとの間の通信が確立すると、入力データや出力データに関しては確認・認証のプロセスを経ることなく、一律に電子署名が付加されることとなる。
【特許文献１】特開２００２−２１５８２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、サーバに送信される入力データが、すべて正しいデータであるとは限らず、例えば、一般クライアントの操作者が誤ってありえない値を入力してしまったり、あるいは正当な操作者の離席中に悪意ある第三者が不正に利益を得る目的で不当な入力を行ったりすることもあり、こうした不適当な入力データがサーバに送信されることもある。
【０００４】
また、入力データとして正しいデータがサーバに送信された場合であっても、サーバでの変換・整形・フィルタリング処理に何らかの不具合があり、出力データに異常な値が挿入される可能性もある。
【０００５】
ところが、このようにして得られた不適当な出力データであっても、一旦電子署名が付加されてしまうと、一般クライアント側では、当該データには電子署名が付加されているため法的根拠を持つデータとして認識することとなる。これは、サーバを管理運営する個人あるいは企業にとって潜在的な脅威であり、サーバにおける入力データ・出力データに対しても確認・認証プロセスを経たうえで電子署名がなされることが望ましい。
【０００６】
本発明は、上記課題に鑑みてなされたものであり、ネットワークより受信したデータに所定の処理を施した後、電子署名を付加する情報処理装置において、不適当なデータに対して電子署名が付加されるのを回避することを目的とする。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために本発明に係る情報処理装置は以下のような構成を備える。即ち、
ネットワークより受信した第１のデータを処理し第２のデータを生成した後、該第２のデータに電子署名を付加して該ネットワークに送信する情報処理装置であって、
前記第１のデータと前記第２のデータとを表示する表示手段と、
前記第２のデータに対する電子署名についての許否の指示を入力する入力手段と、
前記入力手段より、前記第２のデータに対する電子署名について許可の指示が入力された場合に、前記第２のデータに電子署名を付加する付加手段とを備える。
【発明の効果】
【０００８】
ネットワークより受信したデータに所定の処理を施した後、電子署名を付加する情報処理装置において、不適当なデータに対して電子署名が付加されるのを回避することが可能となる。
【発明を実施するための最良の形態】
【０００９】
以下、必要に応じて添付図面を参照しながら本発明の一実施形態を詳細に説明する。
【００１０】
図１は、本発明の一実施形態にかかる情報処理装置のハードウェア構成を示す図であり、当該情報処理装置は後述する損害保険見積帳票発行システム（図４）において、Ｗｅｂサーバ及び監視クライアントとして機能する。また、後述する損害保険見積帳票発行システム（図４）には、さらに一般クライアントが接続されているが、当該一般クライアントも同様のハードウェア構成を有しているものとする。
【００１１】
情報処理装置１００は、ＣＰＵなどの中央処理装置１２と、ＲＡＭおよびＲＯＭなどのメモリから構成される主記憶装置１３、ＦＤドライブやＨＤドライブなどから構成される外部メモリ１５、キーボードおよびマウスなどのポインティングデバイスから構成される入力装置１１、ＣＲＴディスプレイなどから構成される表示装置１４、プリンタなどの印刷装置１７、およびネットワーク１８に接続する外部入出力インターフェイス１６とからその主要部が構成される。損害保険見積帳票発行システムには、かかるハードウェア構成を有する一般クライアントならびにＷｅｂサーバ、監視クライアントがネットワーク１８を介して相互に接続されている。
【００１２】
情報処理装置１００は、基本Ｉ／Ｏプログラム、ＯＳおよび制御プログラム（後述する入力処理ＣＧＩプログラム、帳票オーバーレイプログラム、ＰＤＦ生成プログラム、ＰＤＦ解析プログラム、自動電子署名の可否を判定するプログラム等）を中央処理装置１２が実行することにより動作する。基本Ｉ／Ｏプログラムは主記憶装置１３に書き込まれており、ＯＳは外部メモリ１５に書き込まれている。そして情報処理装置１００の電源がＯＮされたときに、基本Ｉ／Ｏプログラム中のＩＰＬ(イニシャル・プログラム・ローディング)機能により外部メモリ１５からＯＳが主記憶装置１３に読み込まれ、ＯＳの動作が開始される。
【００１３】
本実施形態の場合は、制御プログラムおよび関連データはＦＤ（不図示）中に記録されており、その記録されている内容の構成を図２に示す。
【００１４】
同図に示すように制御プログラム２０３及び関連データ２０４は、ボリューム情報２０１、ディレクトリ情報２０２とともに記録されており、ＦＤに記録された制御プログラム２０３及び関連データ２０４は、ＦＤを通じて情報処理装置１００にロードすることができる。このＦＤを外部メモリ１５にセットすると、ＯＳおよび基本Ｉ／Ｏプログラムの制御の下に制御プログラム２０３および関連データ２０４がＦＤから読み出され、主記憶装置１３にロードされて動作可能となる（図３は、制御プログラム２０３が主記憶装置１３にロードされ実行可能となった状態のメモリマップを示す）。
【００１５】
なお、本実施形態では、ＦＤから制御プログラム２０３及び関連データ２０４を直接主記憶装置１３にロードして実行させる例を示したが、この他にＦＤから制御プログラム及び関連データをいったん外部メモリ１５に格納(インストール)しておき、本制御プログラムを動作させる際に外部メモリ１５から主記憶装置１３にロードするようにしてもよい。また本制御プログラムを記録する媒体は、ＦＤ以外にＣＤ−ＲＯＭ、ＩＣメモリカードなどであってもよい。さらに本制御プログラムを読取専用のＲＯＭに記録しておき、これをメモリマップの一部をなすように構成し、直接中央処理装置１２で実行することも可能である。
【００１６】
図４は、本発明の一実施形態にかかる情報処理装置（Ｗｅｂサーバ及び監視クライアント）を備える損害保険見積帳票発行システムの構成ならびに処理の流れを示す図である。
【００１７】
同図に示すように、損害保険見積帳票発行システムは、インターネットにより相互に接続されたＷｅｂサーバ（４１０）と一般クライアント（４００）と監視クライアント（４３０）とから構成される。なお、同図に示す損害保険見積発行システムでは、本発明の一実施形態にかかる情報処理装置の機能を、Ｗｅｂサーバと監視クライアントとに分けて構成することとしているが、本発明は特にこのような形態に限られるものではなく、一体として構成してもよい。
【００１８】
一般クライアント（４００）においてその操作者はＷｅｂブラウザ（４０１）を起動し、Ｗｅｂサーバ（４１０）にある損害保険会社の損害保険加入申込ページにアクセスする。Ｗｅｂサーバ（４１０）では、当該アクセスに基づいて損害保険加入申込ページをＷｅｂサーバ（４１０）にある送信し（ステップＳ４１１）、Ｗｅｂブラウザ（４０１）上に表示する。当該損害保険加入申込ページには、損害保険の申込に必要な情報を入力するためのテキストボックスやチェックボックスが配置されており、一般クライアント（４００）の操作者は、必要事項の入力を行い、当該入力データ（第１のデータ）をＷｅｂサーバ（４１０）にある送信する。Ｗｅｂサーバ（４１０）上で動作する入力処理ＣＧＩプログラムがこの入力データ（Ｄ４１２）を所定のＩＤと関連付けて保存する（ステップＳ４１２）。また、あわせて入力データを受信した日時を当該ＩＤとともにログとして保存する。
【００１９】
次に入力処理ＣＧＩプログラムは入力データ（Ｄ４１２）から必要な計算を行い、比較検討が行いやすいように解析して、当該入力データ解析結果（Ｄ４１３）を保存する（ステップＳ４１３）。
【００２０】
次に帳票オーバレイプログラムが入力データ（Ｄ４１２）および入力データ解析結果（Ｄ４１３）を指定の損害保険商品の見積帳票フォーム（Ｄ４１４）に流し込んでオーバレイする（ステップＳ４１４）。次にＰＤＦ生成プログラムがオーバレイ済みの見積帳票フォームをＰＤＦ形式に変換し、ステップＳ４１５にてＰＤＦファイル（Ｄ４１５）として上述のＩＤタグと関連付けて保存する（当該ＰＤＦファイルは出力データ（第２のデータ）として、後に電子署名が付加されることとなる）。
【００２１】
次にＰＤＦ解析プログラムはＰＤＦファイル（Ｄ４１５）を解析し、入力データ（Ｄ４１２）や入力データ解析結果（Ｄ４１３）が埋め込まれる部分にある文字列を抽出し、この結果をＰＤＦファイル解析結果（Ｄ４１６）として保存する（ステップＳ４１６）。
【００２２】
次に自動電子署名の可否を判定するプログラムが、入力データ解析結果（Ｄ４１３）およびＰＤＦファイル解析結果（Ｄ４１６）に不審な点がないか（所定の条件を満たすか）を検査して判定を行う（ステップＳ４１７。なお当該判定処理の詳細は図５を用いて後述する）。なお、このときの判定結果は上述のＩＤタグとともにログとして保存される。
【００２３】
判定結果がＯＫであれば（ステップＳ４１７で「Ｙｅｓ」であれば）ステップＳ４１８に進み、入力データ解析結果（Ｄ４１３）にしたがって署名用暗号鍵を自動選択し、ステップＳ４１９にてＰＤＦファイル（Ｄ４１５）に電子署名を付加する。
【００２４】
ステップＳ４２０では当該電子署名が付加されたＰＤＦファイルを一般クライアント（４００）に送信して一連の処理を完了する（ステップＳ４２０）。
【００２５】
一方、自動電子署名の可否の判定結果がＮＧであった場合（ステップＳ４１７で「Ｎｏ」であった場合）、ステップＳ４２１に進み、監視クライアント（４３０）に対して、入力データ解析結果（Ｄ４１３）及びＰＤＦファイル解析結果（Ｄ４１６）とともに判定依頼を送信する。ステップＳ４３１にて監視クライアント（４３０）がこの判定依頼を受信すると、ステップＳ４３２にて入力データ解析結果（Ｄ４１３）とＰＤＦファイル解析結果（Ｄ４１６）を表示装置１４に表示し、さらに監視クライアント（４３０）の操作者（承認者）に電子署名についての許否の指示を促すダイアログを表示する。承認者はこれを受けて入力データ解析結果（Ｄ４１３）とＰＤＦファイル解析結果（Ｄ４１６）を判定し、電子署名についての許否の指示を入力する（ステップＳ４３３）。
【００２６】
ステップＳ４３４では、承認者による入力について判断し、電子署名について許可しない旨の指示であった場合には、ステップＳ４３７に進み、当該承認者による入力結果（電子署名についての許否の情報）をＷｅｂサーバ（４１０）に送信する（ステップＳ４３７）。Ｗｅｂサーバ（４１０）では、監視クライアント（４３０）より送信された電子署名についての許否の情報（ここでは電子署名について許可しない旨の指示）を受信し、ステップＳ４２３にて電子署名を実行しないと判断し、ステップＳ４２４にて見積不可を表すページを一般クライアント（４００）に送信する。なお、このとき受信した電子署名についての許否の情報は、上述のＩＤとともにログとして保存される。
【００２７】
一方、ステップＳ４３４において承認者による入力について判断した結果、電子署名について許可する旨の指示であった場合には、ステップＳ４３５に進み、署名鍵の一覧を表示し、承認者にその選択を促す。承認者により選択された署名鍵の番号が入力されると（ステップＳ４３６）、ステップＳ４３７にて当該署名鍵の番号と、電子署名についての許否の情報とをＷｅｂサーバ（４１０）に送信する（ステップＳ４３７）。
【００２８】
Ｗｅｂサーバ（４１０）ではその結果を受信し（ステップＳ４２２）、ステップＳ４２３にて電子署名を実行すると判断し、ステップＳ４１９に進む。
【００２９】
ステップＳ４１９では、選択された署名鍵番号に対応する署名鍵でＰＤＦファイル（Ｄ４１５）に電子署名を付加し、これを一般クライアント（４００）に送信して一連の処理を完了する（ステップＳ４２０）。
【００３０】
続いて図５を用いて、自動電子署名の可否を判定する処理の詳細について説明する。図５は自動で電子署名を付加してもよいかを判定するルーチンの詳細なフローチャートである。このフローチャートは大きく２つのパートに分かれる。一つは入力データ（Ｄ４１２）の妥当性のチェックおよび裏づけ調査である。これは主に各種のＤＢへの問い合わせという形で確認を積み上げて信頼性を上げるという手法をとっている。もう一つがＰＤＦ形式に変換後に流し込んだ出力データ（ＰＤＦファイルＤ４１５）が正確に表示されるようになっているかのチェックである。特に文書の効力を保証するための文字列（申込人を特定するための住所および氏名、文書の発効日、受取額と支払額）については厳しくチェックするようになっている。以下に具体的に述べる。
【００３１】
ステップＳ５０１では、入力データ（Ｄ４１２）に含まれる「住所」を全国の住所ＤＢに問い合わせる。次にステップＳ５０２において、Ｗｅｂサーバ（４１０）にある当該住所が実在の住所であるか否かを判定する。実在の住所であると判定された場合には、ステップＳ５０３に進む。一方、実在の住所でないと判定された場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００３２】
ステップＳ５０３では、入力データ（Ｄ４１２）に含まれる「電話番号」が固定電話の電話番号であるかを判定し、固定電話の電話番号であると判定された場合には、ステップＳ５０４に進む。一方、固定電話の電話番号でないと判定された場合には、ステップＳ５１６に進み、自動電子署名不可の判定結果を返す。
【００３３】
ステップＳ５０４では、入力データ（Ｄ４１２）に含まれる「電話番号」の市外局番の市町村名をＤＢに問い合わせる。ステップＳ５０５では、「住所」の欄に記載された市町村名と、「電話番号」の市外局番に基づいて検索された市町村名とが一致するか否かを判定する。一致する場合には、ステップＳ５０６に進む。一方、一致しない場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００３４】
ステップＳ５０６では、入力された保険料の振込口座が実在するか全銀協のＤＢに問い合わせる。ステップＳ５０８では、Ｗｅｂサーバ（４１０）にある振込口座が実在するか否かを判定し、実在する場合にはステップＳ５０９に進む。一方、振込口座が実在しない場合には、ステップＳ５１６に進み、自動電子署名不可の判定結果を返す。
【００３５】
ステップＳ５０９では、生成されたＰＤＦファイル（Ｄ４１５）に記載された申込氏名が折り返されていないか否かを判定し、折り返されていなければステップＳ５１０に進む。一方、折り返されていると判定された場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００３６】
ステップＳ５１０では、ＰＤＦファイル（Ｄ４１５）に記載された申込氏名が表示領域内に収まっているか否かを判定し、収まっている場合にはステップＳ５１１に進む。一方、収まっていない場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００３７】
ステップＳ５１２では、ＰＤＦファイル（Ｄ４１５）に記載された保険料が表示領域内に収まっているか否かを判定し、収まっていると判定された場合には、ステップＳ５１３に進む。一方、収まっていないと判定された場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００３８】
ステップＳ５１３では、ＰＤＦファイル（Ｄ４１５）に記載された保険料が毎月１０万円以内であるか否かを判定し、１０万円以内であった場合にはステップＳ５１４に進む。一方、１０万円を越えていた場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００３９】
ステップＳ５１４では、ＰＤＦファイル（Ｄ４１５）に記載された保険支払額が１０００万円以内か否かを判定し、１０００万円以内であれば、ステップＳ５１５に進み自動電子署名可の判定結果を返す。一方、１０００万円を越えていた場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。
【００４０】
なお、図５では入力データ及び出力データ（ＰＤＦファイル）が予め設定された条件を全て具備する場合に、自動電子署名可の判定結果を返すこととしているが、特にこれに限られず、例えば、設定された条件を入力データ・出力データ別にランク付けし、入力データ・出力データ別に一部に条件を具備していない項目があった場合に、当該具備していない条件のランクに応じて、ステップＳ４１８にて選択される署名用暗号鍵を変えるように構成してもよい。
【００４１】
以上の説明から明らかなように、本実施形態にかかるＷｅｂサーバおよび監視クライアントは、電子署名を実行するにあたり、入力データと出力データとを承認者が目視にて確認および承認できるように構成されているため（ステップＳ４３２、４３３）、不適当な出力データに電子署名が付加されることがなくなる。
【００４２】
また、一定の条件を満たした入力データと出力データのセットに対しては、自動的に電子署名を行うことで（ステップＳ４１７〜４１９）、電子署名承認者に確認を求める件数を減らし、電子署名実行承認者の確認負荷を軽減することが可能となる。
【００４３】
さらに、電子署名の記録（入力データの受信日時のログ、電子署名についての許否の指示のログ、自動電子署名の可否の判定結果のログ、ならびに入力データ、出力データ）を残すことで出力データが悪用された場合に法的に対応できる証拠を保管することが可能である。加えて、入力データおよび出力データの内容が満たしている条件をランク付けし、出力データに付加する電子署名の署名鍵を変えることで、出力データが悪意ある第三者に渡った場合の法的な脅威を軽減することも可能になる。
【００４４】
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００４５】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００４６】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００４７】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００４８】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００４９】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００５０】
【図１】損害保険見積帳票発行システムを構成する一般クライアント、Ｗｅｂサーバ、監視クライアントの各情報処理装置に共通するハードウェア構成を示す図である。
【図２】制御プログラムおよび関連データの記録媒体中の構成図である。
【図３】制御プログラムが主記憶装置にロードされ実行可能となった状態のメモリマップを示す。
【図４】本発明の一実施形態にかかる情報処理装置（Ｗｅｂサーバ及び監視クライアント）を備える損害保険見積帳票発行システムの構成ならびに処理の流れを示す図である。
【図５】電子署名付加の是非を判定する処理の流れを示すフローチャートである。
【図１】
2006101218.tif 000003
【図２】
2006101218.tif 000004
【図３】
2006101218.tif 000005
【図４】
2006101218.tif 000006
【図５】
2006101218.tif 000007