JP4459001B2 - 情報処理装置、電子署名付加方法、ならびにプログラム、記憶媒体 - Google Patents

Description

本発明は、ネットワークより受信したデータに対して変換・整形・フィルタリングなどの処理を施し、当該処理後のデータに電子署名を付加してネットワークに返信する情報処理装置における処理技術に関するものである。

一般クライアントからサーバに特定の形式のデータを送信し、サーバでその入力データに対して変換・整形・フィルタリングなどの処理を施し、その結果の出力データに対して電子署名を付加して一般クライアントに返信するネットワークシステムが一般に知られている（例えば特許文献１参照）。当該ネットワークシステムにおいては、通常、サーバは一般クライアントの正当性をそのＩＰアドレスによって認証することとしている。このため、一旦サーバと一般クライアントとの間の通信が確立すると、入力データや出力データに関しては確認・認証のプロセスを経ることなく、一律に電子署名が付加されることとなる。
特開２００２−２１５８２７号公報

しかしながら、サーバに送信される入力データが、すべて正しいデータであるとは限らず、例えば、一般クライアントの操作者が誤ってありえない値を入力してしまったり、あるいは正当な操作者の離席中に悪意ある第三者が不正に利益を得る目的で不当な入力を行ったりすることもあり、こうした不適当な入力データがサーバに送信されることもある。

また、入力データとして正しいデータがサーバに送信された場合であっても、サーバでの変換・整形・フィルタリング処理に何らかの不具合があり、出力データに異常な値が挿入される可能性もある。

ところが、このようにして得られた不適当な出力データであっても、一旦電子署名が付加されてしまうと、一般クライアント側では、当該データには電子署名が付加されているため法的根拠を持つデータとして認識することとなる。これは、サーバを管理運営する個人あるいは企業にとって潜在的な脅威であり、サーバにおける入力データ・出力データに対しても確認・認証プロセスを経たうえで電子署名がなされることが望ましい。

本発明は、上記課題に鑑みてなされたものであり、ネットワークより受信したデータに所定の処理を施した後、電子署名を付加する情報処理装置において、不適当なデータに対して電子署名が付加されるのを回避することを目的とする。

上記の目的を達成するために本発明に係る情報処理装置は以下のような構成を備える。即ち、
ネットワークより受信した操作者の入力データを帳票フォームに流し込んで帳票データを生成した後、該帳票データに電子署名を付加して該ネットワークに送信する情報処理装置であって、
前記入力データと前記帳票データとを解析する解析手段と、
前記解析手段により解析された前記入力データの内容が、予め設定された複数の条件のそれぞれを満たすか否かを所定のＤＢに問い合わせて判定し、前記解析手段により解析された前記帳票データの形式が、予め設定された複数の条件のそれぞれを満たすか否かを判定する判定手段と、
前記複数の条件のうち、前記判定手段により、前記入力データの内容及び前記帳票データの形式のそれぞれが満たしていないと判定された条件のランクに応じて、前記帳票データに付加する電子署名に用いる署名鍵を選択し、当該選択した署名鍵を用いて前記帳票データに電子署名を付加する付加手段とを備える。

ネットワークより受信したデータに所定の処理を施した後、電子署名を付加する情報処理装置において、不適当なデータに対して電子署名が付加されるのを回避することが可能となる。

以下、必要に応じて添付図面を参照しながら本発明の一実施形態を詳細に説明する。

図１は、本発明の一実施形態にかかる情報処理装置のハードウェア構成を示す図であり、当該情報処理装置は後述する損害保険見積帳票発行システム（図４）において、Ｗｅｂサーバ及び監視クライアントとして機能する。また、後述する損害保険見積帳票発行システム（図４）には、さらに一般クライアントが接続されているが、当該一般クライアントも同様のハードウェア構成を有しているものとする。

情報処理装置１００は、ＣＰＵなどの中央処理装置１２と、ＲＡＭおよびＲＯＭなどのメモリから構成される主記憶装置１３、ＦＤドライブやＨＤドライブなどから構成される外部メモリ１５、キーボードおよびマウスなどのポインティングデバイスから構成される入力装置１１、ＣＲＴディスプレイなどから構成される表示装置１４、プリンタなどの印刷装置１７、およびネットワーク１８に接続する外部入出力インターフェイス１６とからその主要部が構成される。損害保険見積帳票発行システムには、かかるハードウェア構成を有する一般クライアントならびにＷｅｂサーバ、監視クライアントがネットワーク１８を介して相互に接続されている。

情報処理装置１００は、基本Ｉ／Ｏプログラム、ＯＳおよび制御プログラム（後述する入力処理ＣＧＩプログラム、帳票オーバーレイプログラム、ＰＤＦ生成プログラム、ＰＤＦ解析プログラム、自動電子署名の可否を判定するプログラム等）を中央処理装置１２が実行することにより動作する。基本Ｉ／Ｏプログラムは主記憶装置１３に書き込まれており、ＯＳは外部メモリ１５に書き込まれている。そして情報処理装置１００の電源がＯＮされたときに、基本Ｉ／Ｏプログラム中のＩＰＬ(イニシャル・プログラム・ローディング)機能により外部メモリ１５からＯＳが主記憶装置１３に読み込まれ、ＯＳの動作が開始される。

本実施形態の場合は、制御プログラムおよび関連データはＦＤ（不図示）中に記録されており、その記録されている内容の構成を図２に示す。

同図に示すように制御プログラム２０３及び関連データ２０４は、ボリューム情報２０１、ディレクトリ情報２０２とともに記録されており、ＦＤに記録された制御プログラム２０３及び関連データ２０４は、ＦＤを通じて情報処理装置１００にロードすることができる。このＦＤを外部メモリ１５にセットすると、ＯＳおよび基本Ｉ／Ｏプログラムの制御の下に制御プログラム２０３および関連データ２０４がＦＤから読み出され、主記憶装置１３にロードされて動作可能となる（図３は、制御プログラム２０３が主記憶装置１３にロードされ実行可能となった状態のメモリマップを示す）。

なお、本実施形態では、ＦＤから制御プログラム２０３及び関連データ２０４を直接主記憶装置１３にロードして実行させる例を示したが、この他にＦＤから制御プログラム及び関連データをいったん外部メモリ１５に格納(インストール)しておき、本制御プログラムを動作させる際に外部メモリ１５から主記憶装置１３にロードするようにしてもよい。また本制御プログラムを記録する媒体は、ＦＤ以外にＣＤ−ＲＯＭ、ＩＣメモリカードなどであってもよい。さらに本制御プログラムを読取専用のＲＯＭに記録しておき、これをメモリマップの一部をなすように構成し、直接中央処理装置１２で実行することも可能である。

図４は、本発明の一実施形態にかかる情報処理装置（Ｗｅｂサーバ及び監視クライアント）を備える損害保険見積帳票発行システムの構成ならびに処理の流れを示す図である。

同図に示すように、損害保険見積帳票発行システムは、インターネットにより相互に接続されたＷｅｂサーバ（４１０）と一般クライアント（４００）と監視クライアント（４３０）とから構成される。なお、同図に示す損害保険見積発行システムでは、本発明の一実施形態にかかる情報処理装置の機能を、Ｗｅｂサーバと監視クライアントとに分けて構成することとしているが、本発明は特にこのような形態に限られるものではなく、一体として構成してもよい。

一般クライアント（４００）においてその操作者はＷｅｂブラウザ（４０１）を起動し、Ｗｅｂサーバ（４１０）にある損害保険会社の損害保険加入申込ページにアクセスする。Ｗｅｂサーバ（４１０）では、当該アクセスに基づいて損害保険加入申込ページをＷｅｂサーバ（４１０）に送信し（ステップＳ４１１）、Ｗｅｂブラウザ（４０１）上に表示する。当該損害保険加入申込ページには、損害保険の申込に必要な情報を入力するためのテキストボックスやチェックボックスが配置されており、一般クライアント（４００）の操作者は、必要事項の入力を行い、当該入力データ（第１のデータ）をＷｅｂサーバ（４１０）に送信する。Ｗｅｂサーバ（４１０）上で動作する入力処理ＣＧＩプログラムがこの入力データ（Ｄ４１２）を所定のＩＤと関連付けて保存する（ステップＳ４１２）。また、あわせて入力データを受信した日時を当該ＩＤとともにログとして保存する。

次に入力処理ＣＧＩプログラムは入力データ（Ｄ４１２）から必要な計算を行い、比較検討が行いやすいように解析して、当該入力データ解析結果（Ｄ４１３）を保存する（ステップＳ４１３）。

次に帳票オーバレイプログラムが入力データ（Ｄ４１２）および入力データ解析結果（Ｄ４１３）を指定の損害保険商品の見積帳票フォーム（Ｄ４１４）に流し込んでオーバレイする（ステップＳ４１４）。次にＰＤＦ生成プログラムがオーバレイ済みの見積帳票フォームをＰＤＦ形式に変換し、ステップＳ４１５にてＰＤＦファイル（Ｄ４１５）として上述のＩＤタグと関連付けて保存する（当該ＰＤＦファイルは出力データ（第２のデータ）として、後に電子署名が付加されることとなる）。

次にＰＤＦ解析プログラムはＰＤＦファイル（Ｄ４１５）を解析し、入力データ（Ｄ４１２）や入力データ解析結果（Ｄ４１３）が埋め込まれる部分にある文字列を抽出し、この結果をＰＤＦファイル解析結果（Ｄ４１６）として保存する（ステップＳ４１６）。

次に自動電子署名の可否を判定するプログラムが、入力データ解析結果（Ｄ４１３）およびＰＤＦファイル解析結果（Ｄ４１６）に不審な点がないか（所定の条件を満たすか）を検査して判定を行う（ステップＳ４１７。なお当該判定処理の詳細は図５を用いて後述する）。なお、このときの判定結果は上述のＩＤタグとともにログとして保存される。

判定結果がＯＫであれば（ステップＳ４１７で「Ｙｅｓ」であれば）ステップＳ４１８に進み、入力データ解析結果（Ｄ４１３）にしたがって署名用暗号鍵を自動選択し、ステップＳ４１９にてＰＤＦファイル（Ｄ４１５）に電子署名を付加する。

ステップＳ４２０では当該電子署名が付加されたＰＤＦファイルを一般クライアント（４００）に送信して一連の処理を完了する（ステップＳ４２０）。

一方、自動電子署名の可否の判定結果がＮＧであった場合（ステップＳ４１７で「Ｎｏ」であった場合）、ステップＳ４２１に進み、監視クライアント（４３０）に対して、入力データ解析結果（Ｄ４１３）及びＰＤＦファイル解析結果（Ｄ４１６）とともに判定依頼を送信する。ステップＳ４３１にて監視クライアント（４３０）がこの判定依頼を受信すると、ステップＳ４３２にて入力データ解析結果（Ｄ４１３）とＰＤＦファイル解析結果（Ｄ４１６）を表示装置１４に表示し、さらに監視クライアント（４３０）の操作者（承認者）に電子署名についての許否の指示を促すダイアログを表示する。承認者はこれを受けて入力データ解析結果（Ｄ４１３）とＰＤＦファイル解析結果（Ｄ４１６）を判定し、電子署名についての許否の指示を入力する（ステップＳ４３３）。

ステップＳ４３４では、承認者による入力について判断し、電子署名について許可しない旨の指示であった場合には、ステップＳ４３７に進み、当該承認者による入力結果（電子署名についての許否の情報）をＷｅｂサーバ（４１０）に送信する（ステップＳ４３７）。Ｗｅｂサーバ（４１０）では、監視クライアント（４３０）より送信された電子署名についての許否の情報（ここでは電子署名について許可しない旨の指示）を受信し、ステップＳ４２３にて電子署名を実行しないと判断し、ステップＳ４２４にて見積不可を表すページを一般クライアント（４００）に送信する。なお、このとき受信した電子署名についての許否の情報は、上述のＩＤとともにログとして保存される。

一方、ステップＳ４３４において承認者による入力について判断した結果、電子署名について許可する旨の指示であった場合には、ステップＳ４３５に進み、署名鍵の一覧を表示し、承認者にその選択を促す。承認者により選択された署名鍵の番号が入力されると（ステップＳ４３６）、ステップＳ４３７にて当該署名鍵の番号と、電子署名についての許否の情報とをＷｅｂサーバ（４１０）に送信する（ステップＳ４３７）。

Ｗｅｂサーバ（４１０）ではその結果を受信し（ステップＳ４２２）、ステップＳ４２３にて電子署名を実行すると判断し、ステップＳ４１９に進む。

ステップＳ４１９では、選択された署名鍵番号に対応する署名鍵でＰＤＦファイル（Ｄ４１５）に電子署名を付加し、これを一般クライアント（４００）に送信して一連の処理を完了する（ステップＳ４２０）。

続いて図５を用いて、自動電子署名の可否を判定する処理の詳細について説明する。図５は自動で電子署名を付加してもよいかを判定するルーチンの詳細なフローチャートである。このフローチャートは大きく２つのパートに分かれる。一つは入力データ（Ｄ４１２）の妥当性のチェックおよび裏づけ調査である。これは主に各種のＤＢへの問い合わせという形で確認を積み上げて信頼性を上げるという手法をとっている。もう一つがＰＤＦ形式に変換後に流し込んだ出力データ（ＰＤＦファイルＤ４１５）が正確に表示されるようになっているかのチェックである。特に文書の効力を保証するための文字列（申込人を特定するための住所および氏名、文書の発効日、受取額と支払額）については厳しくチェックするようになっている。以下に具体的に述べる。

ステップＳ５０１では、入力データ（Ｄ４１２）に含まれる「住所」を全国の住所ＤＢに問い合わせる。次にステップＳ５０２において、Ｗｅｂサーバ（４１０）にある当該住所が実在の住所であるか否かを判定する。実在の住所であると判定された場合には、ステップＳ５０３に進む。一方、実在の住所でないと判定された場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

ステップＳ５０３では、入力データ（Ｄ４１２）に含まれる「電話番号」が固定電話の電話番号であるかを判定し、固定電話の電話番号であると判定された場合には、ステップＳ５０４に進む。一方、固定電話の電話番号でないと判定された場合には、ステップＳ５１６に進み、自動電子署名不可の判定結果を返す。

ステップＳ５０４では、入力データ（Ｄ４１２）に含まれる「電話番号」の市外局番の市町村名をＤＢに問い合わせる。ステップＳ５０５では、「住所」の欄に記載された市町村名と、「電話番号」の市外局番に基づいて検索された市町村名とが一致するか否かを判定する。一致する場合には、ステップＳ５０６に進む。一方、一致しない場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

ステップＳ５０６では、入力された保険料の振込口座が実在するか全銀協のＤＢに問い合わせる。ステップＳ５０８では、Ｗｅｂサーバ（４１０）にある振込口座が実在するか否かを判定し、実在する場合にはステップＳ５０９に進む。一方、振込口座が実在しない場合には、ステップＳ５１６に進み、自動電子署名不可の判定結果を返す。

ステップＳ５０９では、生成されたＰＤＦファイル（Ｄ４１５）に記載された申込氏名が折り返されていないか否かを判定し、折り返されていなければステップＳ５１０に進む。一方、折り返されていると判定された場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

ステップＳ５１０では、ＰＤＦファイル（Ｄ４１５）に記載された申込氏名が表示領域内に収まっているか否かを判定し、収まっている場合にはステップＳ５１１に進む。一方、収まっていない場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

ステップＳ５１２では、ＰＤＦファイル（Ｄ４１５）に記載された保険料が表示領域内に収まっているか否かを判定し、収まっていると判定された場合には、ステップＳ５１３に進む。一方、収まっていないと判定された場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

ステップＳ５１３では、ＰＤＦファイル（Ｄ４１５）に記載された保険料が毎月１０万円以内であるか否かを判定し、１０万円以内であった場合にはステップＳ５１４に進む。一方、１０万円を越えていた場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

ステップＳ５１４では、ＰＤＦファイル（Ｄ４１５）に記載された保険支払額が１０００万円以内か否かを判定し、１０００万円以内であれば、ステップＳ５１５に進み自動電子署名可の判定結果を返す。一方、１０００万円を越えていた場合には、ステップＳ５１６に進み自動電子署名不可の判定結果を返す。

なお、図５では入力データ及び出力データ（ＰＤＦファイル）が予め設定された条件を全て具備する場合に、自動電子署名可の判定結果を返すこととしているが、特にこれに限られず、例えば、設定された条件を入力データ・出力データ別にランク付けし、入力データ・出力データ別に一部に条件を具備していない項目があった場合に、当該具備していない条件のランクに応じて、ステップＳ４１８にて選択される署名用暗号鍵を変えるように構成してもよい。

以上の説明から明らかなように、本実施形態にかかるＷｅｂサーバおよび監視クライアントは、電子署名を実行するにあたり、入力データと出力データとを承認者が目視にて確認および承認できるように構成されているため（ステップＳ４３２、４３３）、不適当な出力データに電子署名が付加されることがなくなる。

また、一定の条件を満たした入力データと出力データのセットに対しては、自動的に電子署名を行うことで（ステップＳ４１７〜４１９）、電子署名承認者に確認を求める件数を減らし、電子署名実行承認者の確認負荷を軽減することが可能となる。

さらに、電子署名の記録（入力データの受信日時のログ、電子署名についての許否の指示のログ、自動電子署名の可否の判定結果のログ、ならびに入力データ、出力データ）を残すことで出力データが悪用された場合に法的に対応できる証拠を保管することが可能である。加えて、入力データおよび出力データの内容が満たしている条件をランク付けし、出力データに付加する電子署名の署名鍵を変えることで、出力データが悪意ある第三者に渡った場合の法的な脅威を軽減することも可能になる。

なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

損害保険見積帳票発行システムを構成する一般クライアント、Ｗｅｂサーバ、監視クライアントの各情報処理装置に共通するハードウェア構成を示す図である。 制御プログラムおよび関連データの記録媒体中の構成図である。 制御プログラムが主記憶装置にロードされ実行可能となった状態のメモリマップを示す。 本発明の一実施形態にかかる情報処理装置（Ｗｅｂサーバ及び監視クライアント）を備える損害保険見積帳票発行システムの構成ならびに処理の流れを示す図である。 電子署名付加の是非を判定する処理の流れを示すフローチャートである。

Claims (5)

1. ネットワークより受信した操作者の入力データを帳票フォームに流し込んで帳票データを生成した後、該帳票データに電子署名を付加して該ネットワークに送信する情報処理装置であって、
   前記入力データと前記帳票データとを解析する解析手段と、
   前記解析手段により解析された前記入力データの内容が、予め設定された複数の条件のそれぞれを満たすか否かを所定のＤＢに問い合わせて判定し、前記解析手段により解析された前記帳票データの形式が、予め設定された複数の条件のそれぞれを満たすか否かを判定する判定手段と、
   前記複数の条件のうち、前記判定手段により、前記入力データの内容及び前記帳票データの形式のそれぞれが満たしていないと判定された条件のランクに応じて、前記帳票データに付加する電子署名に用いる署名鍵を選択し、当該選択した署名鍵を用いて前記帳票データに電子署名を付加する付加手段と
   を備えることを特徴とする情報処理装置。
2. 前記入力データを受信した日時と、前記判定手段による判定結果とを所定のＩＤとともにログとして保存する第１の保存手段と、
   前記入力データと前記第２のデータとを前記ＩＤと関連付けて保存する第２の保存手段と
   を備えることを特徴とする請求項１に記載の情報処理装置。
3. ネットワークより受信した操作者の入力データを帳票フォームに流し込んで帳票データを生成した後、該帳票データに電子署名を付加して該ネットワークに送信する情報処理装置が実行する電子署名付加方法であって、
   解析手段が、前記入力データと前記帳票データとを解析する解析工程と、
   判定手段が、前記解析工程により解析された前記入力データの内容が、予め設定された複数の条件のそれぞれを満たすか否かを所定のＤＢに問い合わせて判定し、前記解析工程において解析された前記帳票データの形式が、予め設定された複数の条件のそれぞれを満たすか否かを判定する判定工程と、
   前記複数の条件のうち、前記判定工程において、前記入力データの内容及び前記帳票データの形式のそれぞれが満たしていないと判定された条件のランクに応じて、付加手段が、前記帳票データに付加する電子署名に用いる署名鍵を選択し、当該選択した署名鍵を用いて前記帳票データに電子署名を付加する付加工程と
   を備えることを特徴とする電子署名付加方法。
4. 請求項３に記載の電子署名付加方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
5. 請求項３に記載の電子署名付加方法をコンピュータによって実現させるための制御プログラム。

Images