JP4877412B2 - 手続システムの端末装置及び記憶媒体 - Google Patents

Description

本発明は、ネットワークを利用した保険契約などの手続システムに関する。

保険の契約は保険代理店を通じて行われることが多い。従来、保険代理店は保険会社と専用線で接続された端末装置を備え、その端末装置を利用して契約のための必要な処理を行っていた。即ち、契約者が保険代理店を訪問し、必要な事項を決定、指定すると、保険代理店の担当者が前述の端末装置を操作して申込書及び契約書を作成する。申込書の控え及び契約書は一部が契約者に渡される。また、申込書及び契約書の原本は郵便などにより保険会社へ送られる一方、申込及び契約データは専用線を介して保険会社へ送られ、契約が計上される。

本発明に関連する技術が特許文献１乃至３に記載されている。

特開平１１−２９６５９９号公報 特開２０００−０５９３５３号公報 特開平１１−３２４３３６号公報

しかし、代理店において作成された申込データや契約データが保険会社へ送られるまでに、誤って変更されたり、意図的に改竄されたりすることが起こりうる。また、悪質な場合には架空の保険契約を作り上げることも起こりうる。

本発明は以上の点に鑑みてなされたものであり、代理店やユーザからサービス提供会社へ送信される手続データの改竄や架空の手続のねつ造を牽制することが可能な手続システムを提供することを目的とする。

本発明の１つの観点では、手続システムの端末装置は、入力部と、記憶部と、前記入力部を通じて入力された必要事項に基づいて、申込者の手続データを作成する手続データ作成手段と、前記手続データを対象とする演算処理により第１の電子署名を作成し、前記記憶部に保存する第１署名手段と、前記手続データを契約書類としてプリントアウトするプリント手段と、前記プリント手段によるプリント時刻及びプリント回数を示すプリントデータを作成し、前記記憶部に保存するプリントデータ作成手段と、少なくとも前記手続データ、前記第１の電子署名、前記プリントデータを対象とする演算処理により第２の電子署名を作成し、前記記憶部に保存する第２署名手段と、前記手続データ、前記第１の電子署名、前記プリントデータ、および前記第２の電子署名を前記記憶部から読み出し、送信データとしてサーバ装置へ送信する送信手段と、を備え、前記手続データ作成手段は、前記第１署名手段により第１の電子署名が作成された時点以後の前記手続データの内容変更を不能とすることを特徴とする。

上記の手続システムの端末装置の一態様では、前記手続データ作成手段は、前記プリント手段に対するプリント指示が入力された時点以後の前記手続データの内容変更を不能とする。

上記の手続システムの端末装置の他の一態様では、前記手続データ作成手段は、前記送信データを前記サーバ装置へ送信する指示が入力された時点以降の前記手続データの内容変更を不能とする。

上記の手続システムの端末装置の他の一態様は、前記手続データに手続番号を付与する手段をさらに備え、前記手続データ作成手段は、前記手続データに前記手続番号が付与された時点以降の前記手続データの内容変更を不能とする。

上記の手続システムの端末装置の他の一態様では、前記手続データ作成手段は、前記手続データの入力フィールドを書き込み不能とすることにより内容変更を不能とする。

上記の手続システムの端末装置の他の一態様では、前記手続データ作成手段は、前記手続データを画像データ化することにより内容変更を不能とする。

本発明の他の観点では、入力部及び記憶部を備えるコンピュータにより読みとり可能な記憶媒体は、前記入力部を通じて入力された必要事項に基づいて、申込者の手続データを作成し、前記記憶部に保存する手続データ作成手段、前記手続データを対象とする演算処理により第１の電子署名を作成し、前記記憶部に保存する第１署名手段、前記手続データを契約書類としてプリントアウトするプリント手段、前記プリント手段によるプリント時刻及びプリント回数を示すプリントデータを作成し、前記記憶部に保存するプリントデータ作成手段、少なくとも前記手続データ、前記第１の電子署名、前記プリントデータを対象とする演算処理により第２の電子署名を作成し、前記記憶部に保存する第２署名手段、前記手続データ、前記第１の電子署名、前記プリントデータ、および前記第２の電子署名を前記記憶部から読み出し、送信データとしてサーバ装置へ送信する送信手段、として前記コンピュータを機能させるプログラムを記憶し、前記手続データ作成手段は、前記第１署名手段により第１の電子署名が作成された時点以後の前記手続データの内容変更を不能とする。

上記の記憶媒体を端末装置などに装着し、コンピュータによりプログラムを実行することにより、その端末装置を本発明の手続システムとして動作させることができる。

以上説明したように、本発明の手続システムによれば、手続データの不正な改変を困難にすることができる。

本発明の実施形態にかかる手続システムの概略構成を示す図である 契約データの不正改変を検出する方法を示す図である。 保険契約手続きの流れを示すフローチャートである。 図３に示す契約データの構成を示す図である。 図３に示す契約データの構成を示す他の図である。 図３の保険契約手続き中に代理店端末に表示される画面例を示す。 図３の保険契約手続き中に代理店端末に表示される他の画面例を示す。 図３の保険契約手続き中に代理店端末に表示されるさらに他の画面例を示す。 契約書類及び契約データの不正処理を検出する方法を示す。 契約書類及び契約データの不正処理を検出する他の方法を示す。 契約書類及び契約データの不正処理を検出するさらに他の方法を示す。 本発明にかかる手続システムの他の概略構成を示す図である。

以下、図面を参照して本発明の好適な実施の形態について説明する。
図１に、本実施形態による手続システムの概略構成を示す。本実施形態においては、契約者６がある保険会社の代理店を訪問し、海外旅行傷害保険の契約を行う場合を想定している。保険会社の代理店には代理店端末２と、プリンタ３と、ライトワンスメディア４とが配置される。代理店端末２は、汎用パーソナルコンピュータにより構成することができ、ＣＤ−ＲＯＭなどの記憶媒体９に記憶された保険契約プログラムを実行することにより手続システムの代理店端末として機能する。プリンタ３は申込書や契約書をプリントアウトするために利用される。ライトワンスメディア４は、例えばＣＤ−Ｒなど一度のみ書き込みが可能（一度書き込みしたデータの書き換えは不可能）な媒体である。代理店端末２はネットワーク７を介してＡ社サーバ１を介して保険会社サーバ５と接続されており、ネットワーク７の１つの好適な例はインターネットである。Ａ社サーバ１は、代理店端末を利用して行われた契約データなどを受け取り、バックアップなどを管理すると共に保険会社へ送る処理を行う。

まず、契約手続きの流れを概説する。契約者（申込者）６は代理店の店舗を訪問し、店員の案内に従って保険契約を行う。即ち、契約者６は契約に必要な事項を店員に伝え、店員は代理店端末２を操作して必要事項を入力して申込データを作成する。申込データはプリンタ３により紙に出力され、申込書となる。契約者はこの申込書に署名、捺印を行い店員に渡す。店員は申込書の１部を契約者用控えとして契約者へ渡す。次に、店員は代理店端末２を操作し、申込データに基づいて契約データを作成し、プリンタから契約書として出力する。契約書の写しは契約者へ渡される。こうして、契約者は申込書の控えと契約書をもらい、代理店での手続きを終える。なお、契約データは申込データの内容を含むものとする。

店員は作成された契約データをネットワーク７を通じ、Ａ社サーバ１を介して保険会社サーバ５へ送信する。また、代理店の店員はプリントアウトした申込書及び契約書（以下、「契約書類」と呼ぶ。）を原本として保険会社へ渡す。これは、郵送又は人手を介して行われる。保険会社は契約書類の内容と、ネットワーク７を介して受け取った契約データの内容とを照合し、契約後に変更や改竄が行われていないかを確認する。両者が一致すれば適正な契約であるとして処理する。

本実施形態においては、主として代理店で契約書類及び契約データが作成されてから保険会社により受領されるまでの間に生じうる故意又は不意の変更や不正な改竄（以下、まとめて単に「改変」と呼ぶ。）を検出することを目的とする。そのため、代理店における契約書類及び契約データの作成時にそのような改変を防止するためのいくつかの防止対策を施す。代理店において生じ得る改変は、大別して、実際に行われた契約の内容を改竄してから保険会社へ計上する場合（タイプ１）と、現実には存在していない架空の契約を作り上げる場合（タイプ２）とが考えられる。本実施形態では、それぞれのタイプの改変について防止策が施されている。なお、上記のような改変には、代理店内における店員の処理に起因して行われるものの他に、ネットワーク７上で送信される間に契約データに対して行われるものも考えられるが、そのような改変も本実施形態の手法により検出することが可能である。

次に、主としてタイプ１に対する防止策である、電子署名を付す手法を図２を参照して概説する。電子署名は一般的に以下のように行われる。署名者は、署名対象データをハッシュ関数で処理し、結果として得られるハッシュ値を署名者の秘密鍵（公開鍵暗号方式の場合）又は共通鍵（共通鍵暗号方式の場合）で暗号化する。この暗号化の結果得られるデータが電子署名と呼ばれ、対象となるデータと共に送信される。なお、「電子署名」とは一般的には公開鍵暗号方式によって暗号化したデータのみを指し、共通鍵暗号方式によるものを含まない場合もあるが、本明細書では両者を含めて電子署名と呼ぶ。受け取り側は予め署名者の公開鍵（公開鍵暗号方式の場合）又は共通鍵（共通鍵暗号方式）を所持しており、受け取った電子署名をその鍵で復号化してハッシュ値を得る。また、同時に受け取った署名対象データを同じハッシュ関数で処理してハッシュ値を計算し、電子署名の復号化により得られたハッシュ値と比較する。両者が一致すれば、署名者からのデータに改変が行われていないことが確認される。

さて、図２（Ａ）を参照し、店員が申込者との間で必要事項を代理店端末２に入力すると、契約データが作成される。契約データの内容について申込者の確認が得られると、店員は電子署名を行う。即ち、その契約データに対して、時刻などから生成される一意性のある値（ＩＤ、証券番号などとすることができる）を付加し、両データの集合について電子署名を作成、付加して保存する。その後、計上処理により、契約データ、ＩＤ及び電子署名を保険会社へ送信する。保険会社側では、持っている鍵で電子署名を復号化してハッシュ値を得る。次に、一緒に送信された契約データとＩＤの集合についてのハッシュ値を計算し、電子署名を復号化して得たハッシュ値と比較する。両者が一致すれば、契約データに対して改変が行われていないことが確認される。

ここで重要なことは、代理店において電子署名を行う際に使用する鍵に代理店の店員がアクセスできないようにすることである。本実施形態では代理店における改変防止を１つの目的としているので、代理店の人間が鍵にアクセスできると、契約データを改竄することができてしまう。従って、例えば代理店端末２において実行される保険契約プログラムにおいて、店員が電子署名の指示を行うと自動的に所定の鍵を使用して電子署名が行われるようにし、それ以外の方法では店員が電子署名を行うことができないようにしておくことが必要である。この要求が満されれば、代理店における電子署名で使用する鍵は、共通鍵であっても、代理店の秘密鍵であっても構わない。

さらに、本実施形態においては契約時に代理店端末２において行われる手続き、処理（以下、「イベント」と呼ぶ。）についてイベント履歴を記録する。この概要を図２（Ｂ）に示す。例えば、契約データを代理店端末２に保存した時刻、契約書原本のプリントアウト時刻、保険会社へ契約データを送信した時刻などをイベント履歴データとして記録しておく。即ち、イベントの内容を示すイベントＩＤとイベントの実行時刻とをイベント履歴データとして記録する。そして、契約データ及びイベント履歴データについて代理店端末２の保険契約プログラムに従って電子署名が作成、付加される。それらのデータはネットワーク７を通じ、Ａ社サーバ１を介して保険会社へ送信される。保険会社では、電子署名を復号化して契約データとイベント履歴データの内容を取得し、内容を調査する。例えば、各イベントが正しい順序で行われているか、イベントが不正に複数回行われてはいないか、などをチェックする。これにより、不正な改変を検出することができる。なお、Ａ社サーバは後述のように契約データのバックアップなど所定のデータを保存する。また、上記のイベント履歴データも保存し、その後の証明などに利用する。

次に、上述の対策を含む本実施形態の保険契約手続きについて図１、図３乃至８を参照して説明する。図３は保険契約手続きの流れを示すフローチャートであり、図４及び５は保険契約手続き中に作成される契約データの構成を概念的に示す。また、図６乃至８は保険契約手続き中に代理店端末２のディスプレイ上に表示される画面例である。

図３において、符号２０はデータマークであり、データマークで示された各時点（Ｄ１〜Ｄ５）での契約データの構成が対応する符号Ｄ１〜Ｄ５で図４及び５に示されている。符号２２乃至３１はイベント履歴記録タイミングを示す。即ち、代理店端末２の保険契約手続きにおいて、符号２２乃至３１が付された各ステップで行われた処理内容及びその処理の実行時刻がイベント履歴として逐次記録されていく。符号３２は電子透かし処理を行うステップを示し、符号３４はライトワンス記録処理を行うステップを示しているが、それらの詳細については後述する。

まず、契約者（申込者）６が代理店を訪れ、店員との話し合い後に契約を行う。店員は代理店端末２を操作して図６（Ａ）に示す入力画面を表示させる。そして、契約者６に必要事項を質問し、入力画面上の必要事項を入力していく（ステップＳ２）。店員が項目［Next］をクリックすることによりこの画面の入力が終了したことを指定すると、次に図６（Ｂ）に示す保険料計算画面が表示され、さらに入力が続けられる。そして、保険料に関する事項の入力が終了すると、店員は図６（Ｂ）の状態で［Next］を指定し、保険料に関する入力の終了を指示する。これにより、契約データの内容が決定し、この時点では図４（Ａ）に示す契約データのみが存在することになる。また、図６（Ｂ）に示す保険料計算画面で店員が［Next］を指定した時に、イベント内容として必要事項の入力ステップが終了したこと、及びその時刻がイベント履歴データとして記録される（図３の符号２２参照）。なお、イベント内容については、履歴を記録すべきイベントに対して予めイベントＩＤが付与されており、イベントＩＤと完了時刻とがイベント履歴データとして記録される。

こうして図６（Ａ）及び（Ｂ）に例示する事項の入力が完了すると、図７（Ａ）に示す契約内容確認画面が表示され、申込者に提示される（ステップＳ４）。申込者は内容を確認し、誤りがあれば訂正を店員に依頼する。申込者の確認が得られると、店員は［電子署名］を指定する（ステップＳ６）。これにより、まずその契約を示すＩＤ（証券番号となる）が生成される。また、これと同時に、入力画面上の入力フィールドをロックし、それ以降の入力ができないようにすることができる。これにより、電子署名付与後に不正に契約内容を改変することが防止される。電子署名の付与により入力フィールドがロックされた後に内容の変更が必要になった場合は、例えば「内容変更」ボタンなど（図示せず）を押すことにより入力フィールドのロックを解除するように構成することができる。

なお、電子署名の付与とＩＤの付与のタイミングが異なる方式を採用する場合には、契約ＩＤが付与されたタイミングで入力フィールドをロックするように構成することもできる。

こうして、前述のように、予め用意された鍵を使用して契約データとＩＤの集合に対して電子署名が生成され、付与される。電子署名後のデータは、図４（Ｂ）に示すように、契約データ、ＩＤ及び電子署名を含むことになる。また、符号２４に示すように、契約データの生成及び電子署名の生成・付与についてのイベント履歴が記録される。

電子署名が行われると、図７（Ｂ）に示すように［プリント］ボタンが表示され（図７（Ａ）の状態では［プリント］ボタンは未だ表示されていない）、契約書のプリントアウトが可能となる。逆に言えば、本実施形態の保険契約プログラムは、電子署名が完了する前には契約書をプリントアウトできないように作成されている。これは、電子署名前に契約内容をプリントアウトして契約者に渡した後、内容を改変して電子署名を付することにより、店員が不正な計上を行うことを防止するためである。

なお、上述のように電子署名付与時（ステップＳ６）に入力フィールドをロックしない場合は、［プリント］ボタンが押された時に入力フィールドをロックするように構成することもできる。これにより、データの内容とプリント出力された紙の契約書の内容が一致することが確保される。

店員は［プリント］ボタンを押して契約書をプリントアウトし（ステップＳ８）、一部を契約者控えとして契約者へ渡し、一部を原本として一時的に保存する。ここで、符号２６により示されるように、プリント処理についてのイベント履歴が記録される。また、プリント時刻及びプリント回数のデータが生成され、その結果この時点でのデータは図４（Ｃ）に示すようになる。また、プリント回数はプリントアウトされた契約書にも記される。例えば、プリント回数を意味する数字、記号、バーコードなどを契約書のある部分に印字する。これにより、後に保険会社でその契約書が何回目のプリントであるかを調べることができる。

なお、何らかの理由で契約内容の変更が必要となった場合は、店員は内容変更を指示し、処理はステップＳ２へ戻り、別の新規契約として最初から処理を行う。この際、それまでに行った契約は無効となる。この内容変更指示についてのイベント履歴が記録される。

一方、内容の変更ではなく、契約書の再プリントが必要となる場合がある。例えば、プリンタ３内で用紙がつまり、契約書が破れてしまった場合や店員が誤って契約書を破損してしまった場合などである。この場合、再プリント処理を行う。再プリントの指示についてもイベント履歴が記録される。再プリント処理では、まず、再プリントの理由を入力することが要求される（ステップＳ１２）。これは、後で保険会社側で再プリントの理由を審査し、不正に契約書がプリントされたことを検出するためである。店員が再プリント理由を入力すると再プリント理由データが生成される。また、理由問い合わせ及び再プリント理由の入力についてのイベント履歴が記録される。この時点でデータは図４（Ｄ）に示すようになる。そして、処理はステップＳ８へ戻り、契約書が再度プリントアウトされる。再プリント後は、図４（Ｄ）に示すデータ中のプリント時刻及びプリント回数の内容は更新されていることになる。

こうして、契約書が出力され契約者に渡されると、後は代理店と保険会社サーバとの間の処理となる。店員は、これまでの処理で作成されたデータに、その時点までのイベント履歴データを加え計上用データとしてセーブする（ステップＳ１０）。このとき、それらデータ全体に対して電子署名が付され、イベント履歴も記録される（符号３１）。よって、セーブされる計上用データは、再プリントがなされていない場合は図５（Ａ）のようになり、再プリントがなされた場合は図５（Ｂ）のようになる。

次に、計上用データはネットワーク７を通じ、Ａ社サーバ１を介して保険会社サーバ５へ送信される（ステップＳ１４）。なお、こうして手続データを含む形状用データが保険会社サーバ５へ送信される時に、手続データの入力フィールドをロックするように構成することもできる。この処理は、代理店端末２で実行される保険契約プログラムの内容により、１件ずつ送信するようにしても良いし、１日分をまとめて送信するようにしても良い。計上処理時の代理店端末２上の表示画面例を図８に示す。この状態で、店員は［個別計上］又は［一括計上］のいずれかを指定して計上処理を行う。

次に、代理店の店員はステップＳ８でプリントアウトした契約書原本を郵便などで保険会社へ送る（ステップＳ１６）。保険会社は、ステップＳ１４でネットワーク７を通じて送られた契約データと、郵送で送られた契約書類とを比べて内容を調査する（ステップＳ１８）。この調査は以下のように行われる。

まず、図５に示すように、契約データ（イベント履歴、プリント時刻及び回数などを含む）全体に対して付された電子署名データを復号化してハッシュ値を取得し、契約データ全体から計算したハッシュ値と比較する。両者が一致すれば、計上用データがセーブされた後に代理店内でもしくはネットワーク上で改変がなされていないことが確認できる。次に、契約データに含まれるイベント履歴の内容を調べ、イベントの順序やイベントの回数が適正であるかをチェックする。さらに、郵送された契約書類上に記されたプリント回数の部分をＯＣＲなどで読み取り、プリント回数データと比較する。両者が一致しなければ、不正に再プリントが行われたことが発見できる。

さらに、契約データ及びＩＤに対して付された電子署名を復号化してハッシュ値を取得し、契約データから計算したハッシュ値と比較して契約データの内容に改変がなされていないかを確認する。さらに、契約データの内容と契約書類の記載内容とを比較する。以上の検査により、不正な改変を高い信頼度で検出することができる。

不正な改変が発見された場合、保険会社はその契約を無効とする（ステップＳ２２）。一方、発見されない場合、その契約を有効なものとして処理する。以上により、保険契約処理が終了する。

なお、契約データの受け渡しなどの業務を行うＡ社サーバ１は、契約後に種々の形態でデータの管理を行うことができる。例えば、Ａ社サーバ１は契約データの原本を保管することができる。別の方法として、契約データのバックアップデータのみを保管し、原本を保険会社へ送ることもできる。また、原本及びバックアップデータは保管せず、付与された電子署名データのみを保管することもできる。さらには、それら全て又はいずれかの組み合わせを保管することもできる。Ａ社サーバは、こうして保管したデータについて後に契約者や保険会社などから請求があった場合に証明を行うことができる。

次に、電子透かしを利用した改変検出手法について図９（Ａ）を参照して説明する。電子透かしとは、画像などのデータに対して、その一部の値を変更することにより透かしデータを挿入する手法であり、これを利用することによりプリントアウト後の契約書類の紙面上に施された改変を検出することができる。

上記の例において、ステップＳ８のプリントアウト時に、契約データ、ＩＤ（証券番号）、プリント時刻、プリント回数のハッシュ値を計算し、これを不可視透かしデータとして契約書の一部又は背景全体の画像データに挿入する。そして、電子透かしが挿入された画像が契約書の一部に含まれてプリントアウトされる。契約書は郵便で保険会社へ送られる。保険会社は、受け取った契約書から透かしデータ（ハッシュ値）を検出する。また、受け取った契約書の紙面上のデータをＯＣＲなどで読み取り、ハッシュ値を計算し、両者を比較する。一致すれば契約書紙面上への改変は無いと判断される。契約書紙面上で例えば、保険料の数字などに改変がなされていれば、改変後の契約データのハッシュ値は透かしに挿入されたハッシュ値とは異なるはずであり、これにより改変が検出できる。

次に、ライトワンスメディア４を使用した改変検出方法について説明する。ライトワンスメディアとは、例えばＣＤ−Ｒのように一度のみのデータ書き込みが可能な媒体である。図３に示す保険契約手続きにおいて、契約書の再プリント指示がなされた場合は、契約データ、理由データ及び電子署名の少なくともいずれかがライトワンスメディアに記録される。即ち、保険契約手続きの進行に伴って図４及び５に示すようにデータが作成されていくが、それらをライトワンスメディア４にも記録する。また、入力された再プリント理由も記録する。このライトワンスメディア４は、所定量のデータが記録されると保険会社により回収される。保険会社は、ライトワンスメディア４に記録された契約データを、ネットワーク７を通じて受け取った契約データ、並びに郵送された契約書類の内容と照合する。そして、ライトワンスメディア４に記録された契約データがいずれかと相違、矛盾している場合は改変が行われたと推測することができる。

具体的には先ず、ネットワーク７を通じて送信された契約データ又は郵送による契約書類の内容が、ライトワンスメディア内に記録された内容と一致するか否かを検査する。一致している場合は、次に内容的に矛盾が無いかどうかを検査する。ライトワンスメディア４に記録された内容は書き換え不能であるので、正しい内容とみなすことができる。よって、例えばプリントアウトされた後で契約書類上に改変がなされたり、ネットワーク７を通じて保険会社へ送信される前又は送信中に改変がなされた場合は、改変後の内容はライトワンスメディア４の内容とは一致しなくなる。これにより、契約書類及びネットワークを通じて送信される契約データに対する改変を検出することができる。また、図９（Ｂ）に示すように、再プリントが行われている場合に、再プリント前後の契約データ内容の変化と再プリント理由とが矛盾する場合なども改変があった可能性がある。

なお、ＣＤ−Ｒのように構造的に書き換え不能な記録媒体を使用する代わりに、構造的には書き換えが可能であるが書き換えを不能とする処理がなされている媒体（例えば、書き換え不能なように処理されたＩＣカードなど）を使用することもできる。

次に、タイプ２の改変、即ち、架空の契約をねつ造したことを検出する方法について説明する。

まず、１つの手法として、契約データに契約者の電子署名を付す方法を図１０を参照して説明する。この手法は公開鍵暗号方式を利用するものであり、契約者は自己の公開鍵及び秘密鍵を作成する。また、この公開鍵を予め認証局に登録して公開鍵証明書を取得しておくこともできる。図３に示す保険契約手続きのステップＳ６で、ＩＣカードや記録ディスクなどの媒体を代理店端末２に挿入するなどの手法により、契約データに対して秘密鍵で電子署名を行う。この電子署名は契約データと共にネットワーク７を介して保険会社へ送られる。また、プリントアウトされる契約書類の紙面上にこの電子署名を書き込む。保険会社は契約データを受け取り、契約者の公開鍵を入手して復号化し、ハッシュ値を比較することにより、その契約者自身が契約に同意したことを確認することができる。また、契約書類を受け取り、紙面に書き込まれた署名を検出することによっても、その契約者が確かに契約したことを確認することができる。なお、契約者が予め認証局に登録して公開鍵証明書を持っている場合は、それを契約データに添付して保険会社に送ることによりその契約者が実在することが確認できるので、架空の契約を検出することができる。

ここで、契約者が秘密鍵で電子署名を行う際は、そのデータが代理店端末２内に残らないような処理を行うことが必要となる。代理店端末２に契約者の秘密鍵の複写データなどが残っていると、代理店の人間がその秘密鍵を使用して架空の契約を作ることができるからである。１つの方法として、例えば契約者のＩＣカード内に秘密鍵を記録し、ＩＣカード側に契約データを読み込んで暗号化を施し、その結果得られる電子署名のみを代理店端末２に送ることができる。なお、後述のように、代理店端末２がインターネットなどのネットワークを通じて契約者の端末と接続されている場合は、契約者は自己の端末上で電子署名を作成して代理店端末へ送ることができる。

また、契約者が公開鍵暗号方式を利用できない場合は、電話番号により契約者の存在確認を行うことができる。図１１（Ａ）に示すように、代理店は契約成立後に契約者に契約番号を伝えると共に、電話会社に登録されている電話番号で保険会社に電話して契約番号を告げるか、又は登録されている端末から発信して契約番号を送信するように依頼する。契約者が保険会社に電話をすると、保険会社はその発信元情報を得ることができる。よって、その電話番号に対して登録されている人物を電話会社に問い合わせる。登録されている人物が契約者と一致しない場合は、契約者本人以外による不正な契約であると判断される。契約者の端末から契約番号を送信する場合も同様に不正な契約を検出することができる。

さらに別の方法として、画像データを利用して本人確認をする手法を図１１（Ｂ）を参照して説明する。契約が成立して契約書をプリントアウトした後、店員は契約者が自らの顔写真付きの身分証明書を持った状態で契約者の顔画像をデジタルカメラなどにより撮影し、ＣＤ−Ｒなどのライトワンスメディアに契約データと共に記録する。保険会社では、この画像を開き、契約データ中の契約者の情報と画像中の身分証明書の情報とを照合し、さらに画像中の契約者の顔写真と身分証明書中の顔写真とを照合して、確かにその契約者による契約であることを確認することができる。なお、画像データをライトワンスメディアに記録する代わりに、ネットワークを介して直接保険会社へ送信することもできる。

上記の実施形態では、契約に伴う処理を実行するためのプログラムが代理店端末内に予め用意されており、契約処理後に契約データ及びイベント履歴データをＡ社サーバ１へ送るように構成している。その代わりに、契約処理のためのプログラムをＡ社サーバ１内に用意し、契約処理時には代理店端末２とＡ社サーバ１との間で必要な通信処理を行いつつ契約データ及びイベント履歴データを作成するように構成することもできる。

また、上記の説明では図１に示すように、契約者が代理店で契約を行う場合を示した。しかし、図１２に示すように、代理店端末２と契約者端末１０との間をネットワーク７を介して通信し、ネットワーク上で契約処理を行うこともできる。この場合、代理店端末装置２は、必要事項の入力フォームデータを契約者端末１０へ送信し、契約者自らが必要事項を入力して契約データを作成する。契約データ作成後は、図１の場合と同様に必要な電子署名などを行って契約手続きを進めることができる。また、契約者は署名・捺印の代わりに契約者端末装置を使用して電子署名を付すこともできる。

また、代理店を介さずに契約者が直接保険会社のウェブサイトなどにアクセスして契約手続を行う場合にも本発明を適用することができる。その場合は、契約者であるユーザの端末装置が代理店端末２と同様の機能を実行することになる。

また、上記の説明では契約データの不正な内容変更を防止するために、契約書の電子フォームの入力フィールドをロックする手法を挙げているが、その代わりに、契約データ自体を画像データ化することにより、以後の改変を防止することも可能である。

本発明は、各種の申込、契約などの手続を実行する手続システムに利用することができる。

１…Ａ社サーバ
２…代理店端末
３…プリンタ
４…ライトワンスメディア
５…保険会社サーバ
６…契約者
７…ネットワーク
９…記憶媒体
１０…契約者端末

Claims (12)

1. 手続システムの端末装置であって、
   入力部と、
   記憶部と、
   前記入力部を通じて入力された必要事項に基づいて、申込者の手続データを作成する手続データ作成手段と、
   前記手続データを対象とする演算処理により第１の電子署名を作成し、前記記憶部に保存する第１署名手段と、
   前記手続データを契約書類としてプリントアウトするプリント手段と、
   前記プリント手段によるプリント時刻及びプリント回数を示すプリントデータを作成し、前記記憶部に保存するプリントデータ作成手段と、
   少なくとも前記手続データ、前記第１の電子署名、前記プリントデータを対象とする演算処理により第２の電子署名を作成し、前記記憶部に保存する第２署名手段と、
   前記手続データ、前記第１の電子署名、前記プリントデータ、および前記第２の電子署名を前記記憶部から読み出し、送信データとしてサーバ装置へ送信する送信手段と、を備え、
   前記手続データ作成手段は、前記第１署名手段により第１の電子署名が作成された時点以後の前記手続データの内容変更を不能とすることを特徴とする手続システムの端末装置。
2. 前記手続データ作成手段は、前記プリント手段に対するプリント指示が入力された時点以後の前記手続データの内容変更を不能とすることを特徴とする請求項１に記載の手続システムの端末装置。
3. 前記手続データ作成手段は、前記送信データを前記サーバ装置へ送信する指示が入力された時点以降の前記手続データの内容変更を不能とすることを特徴とする請求項１に記載の手続システムの端末装置。
4. 前記手続データに手続番号を付与する手段をさらに備え、
   前記手続データ作成手段は、前記手続データに前記手続番号が付与された時点以降の前記手続データの内容変更を不能とすることを特徴とする請求項１に記載の手続システムの端末装置。
5. 前記手続データ作成手段は、前記手続データの入力フィールドを書き込み不能とすることにより内容変更を不能とする請求項２乃至４のいずれか一項に記載の手続システムの端末装置。
6. 前記手続データ作成手段は、前記手続データを画像データ化することにより内容変更を不能とする請求項２乃至４のいずれか一項に記載の手続システムの端末装置。
7. 入力部及び記憶部を備えるコンピュータにより読みとり可能な記憶媒体であって、
   前記入力部を通じて入力された必要事項に基づいて、申込者の手続データを作成し、前記記憶部に保存する手続データ作成手段、
   前記手続データを対象とする演算処理により第１の電子署名を作成し、前記記憶部に保存する第１署名手段、
   前記手続データを契約書類としてプリントアウトするプリント手段、
   前記プリント手段によるプリント時刻及びプリント回数を示すプリントデータを作成し、前記記憶部に保存するプリントデータ作成手段、
   少なくとも前記手続データ、前記第１の電子署名、前記プリントデータを対象とする演算処理により第２の電子署名を作成し、前記記憶部に保存する第２署名手段、
   前記手続データ、前記第１の電子署名、前記プリントデータ、および前記第２の電子署名を前記記憶部から読み出し、送信データとしてサーバ装置へ送信する送信手段、として前記コンピュータを機能させるプログラムを記憶し、
   前記手続データ作成手段は、前記第１署名手段により第１の電子署名が作成された時点以後の前記手続データの内容変更を不能とすることを特徴とする記憶媒体。
8. 前記手続データ作成手段は、前記プリント手段に対するプリント指示が入力された時点以後の前記手続データの内容変更を不能とすることを特徴とする請求項７に記載の記憶媒体。
9. 前記手続データ作成手段は、前記送信データを前記サーバ装置へ送信する指示が入力された時点以降の前記手続データの内容変更を不能とすることを特徴とする請求項７に記載の記憶媒体。
10. 前記手続データに手続番号を付与する手段としてさらに前記コンピュータを機能させ、
    前記手続データ作成手段は、前記手続データに前記手続番号が付与された時点以降の前記手続データの内容変更を不能とすることを特徴とする請求項７に記載の記憶媒体。
11. 前記手続データ作成手段は、前記手続データの入力フィールドを書き込み不能とすることにより内容変更を不能とする請求項８乃至１０のいずれか一項に記載の記憶媒体。
12. 前記手続データ作成手段は、前記手続データを画像データ化することにより内容変更を不能とする請求項８乃至１０のいずれか一項に記載の記憶媒体。

Images