JP4551009B2

JP4551009B2 - Server apparatus for online contract system and program therefor

Info

Publication number: JP4551009B2
Application number: JP2001053044A
Authority: JP
Inventors: 貴志鈴木; 圭司岩本; 早苗坂本
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2001-02-27
Filing date: 2001-02-27
Publication date: 2010-09-22
Anticipated expiration: 2021-02-27
Also published as: JP2002259849A

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネット上で電子フォーム及び電子署名を使用してオンライン契約手続を実行するシステムに関する。
【０００２】
【従来の技術】
近年の電子技術やネットワーク技術の進歩に伴い、従来は紙の書類で行われていた種々の手続をインターネット上で行う環境が整いつつある。例えば、官公庁への届出、申請などの手続や、保険、リースなどの契約手続を、電子書類と電子署名とを利用してオンラインで行うことが可能となりつつある。
【０００３】
【発明が解決しようとする課題】
このような環境下において、複数の者がオンラインである種の契約を行う場合には、共通の契約内容に対して、契約者全員が電子署名を利用して同意の意思表示を行うことになる。
【０００４】
しかし、同一の契約書データに対して、単純に複数の契約者が順に電子署名を付与する手法を採ると、後で契約を成立させるための検証を行う際、全員の電子署名を正しく検証できないという問題が生じる。例えば、契約者ＡとＢの間で契約を行う場合、契約者Ａが契約書データに対して必要事項（契約者Ａの氏名、住所など）を記入して電子署名を付与した場合、その電子署名は、契約者Ａの記入後の契約書データを対象として作成される。次に、そうして契約者Ａが必要事項を記入し、電子署名を付与した契約書データに対して、今度は契約者Ｂが必要事項を記入し、電子署名を付す。その結果、契約書データとしては、契約者Ａ及びＢが必要事項を記入した後のものが存在し、電子署名は契約者ＡとＢのものが存在することになる。
【０００５】
ここで、契約者Ｂの電子署名は契約者Ａ、Ｂの両者が必要事項を記入した後の契約書データを対象として作成されているので、正しく検証することができる。しかし、契約者Ａの電子署名は、前述のように契約者Ｂが必要事項を記入する前の契約書データを対象として作成されているので、契約者Ｂが必要事項を記入した後の契約書データを利用して正しく検証することはできない。
【０００６】
このように、複数の契約者間のオンライン契約を実現するためには、同一の契約書データに対して複数の者が必要事項を記入し、電子署名を付した際に、全ての契約者の電子署名を正しく検証することができるシステムが要求される。
【０００７】
本発明は、以上の点に鑑みてなされたものであり、同一の契約書データに対して行われた契約者全員の電子署名を正しく検証することにより、安全にオンライン契約手続を実現することが可能なシステム及びそのためのプログラムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
請求項１に記載の発明は、ネットワークを通じて契約者のクライアント端末と接続されたオンライン契約システムのサーバ装置において、契約情報を保存するデータベースと、契約内容フィールド及び複数の契約者入力フィールドを含む契約書データについて、前記契約内容フィールドを対象としてサーバの電子署名を作成して契約書データに付与し、契約者の入力が未だ行われていない状態の入力前契約書データとして契約者のクライアント端末へ送信する送信手段と、契約者が必要事項を入力し、契約者の電子署名を付した状態の入力後契約書データを前記クライアント端末から受信する受信手段と、全ての契約者から入力後契約書データを受信した時点で、前記サーバ及び各契約者の電子署名の対象となっているフィールドのデータを入力後契約書データから抽出し、各電子署名を検証する検証手段と、前記検証手段が全ての電子署名を正しく検証できた場合に契約を成立させる成立手段と、を備える。
【０００９】
上記のように構成された発明によれば、まず、契約書データにサーバの電子署名が付与されて入力前契約書データが作成され、これが契約者のクライアント端末へ送信される。契約者は必要事項を入力し、電子署名を付与し、入力後契約書データとしてサーバ装置へ送信する。サーバ装置はこれを受信する。全ての契約者にこの処理が行われた時点で、サーバ及び各契約者の電子署名の対象となっているフィールドのデータが入力後契約書データから抽出され、各電子署名の検証がなされる。全ての電子署名が正しく検証できれば、契約書データに対する改竄がなく、かつ、入力がそれぞれ契約者本人により行われたことがわかるので、契約が成立する。
【００１０】
請求項２に記載の発明は、請求項１に記載のサーバ装置において、入力前契約書データと入力後契約書データとを比較して契約書データの一致を検出する比較手段を備え、前記成立手段は、全ての契約者について、前記比較手段が契約書データの一致を検出し、かつ、前記検証手段が電子署名を正しく検証できた場合に、契約を成立させる。これにより、入力前契約書データと入力後契約書データとが一致すれば、契約書データに対する改竄がないことがわかり、契約者の電子署名の検証が正しく行われれば、入力が契約者本人により行われたことがわかるので、契約が成立する。
【００１１】
請求項３に記載の発明は、請求項１又は２に記載のサーバ装置において、前記送信手段、前記受信手段、前記検証手段及び前記成立手段が行った処理のログを前記データベースに保存するログ記録手段を備える。これにより、契約成立までの各段階の処理の記録を保存することができる。
【００１２】
請求項４に記載の発明は、請求項１乃至３のいずれかに記載のサーバ装置において、前記契約書データは、対応する電子フォームのデータを含む。これにより、契約書データを電子的な書類として正しく表示することができる。
【００１３】
請求項５に記載の発明は、請求項１乃至３のいずれかに記載のサーバ装置において、前記契約書データは、対応する電子フォームの識別情報を含む。これにより、契約書データを電子的な書類として正しく表示することを確保しつつ、契約書データ自体のデータ量を減らすことができる。
【００１４】
また、請求項６に記載の発明は、ネットワークを通じて契約者のクライアント端末と接続されたオンライン契約システムのサーバ装置において実行されるプログラムであって、前記サーバ装置を、契約内容フィールド及び複数の契約者入力フィールドを含む契約書データについて、前記契約内容フィールドを対象としてサーバの電子署名を作成して契約書データに付与し、契約者の入力が未だ行われていない状態の入力前契約書データとして契約者のクライアント端末へ送信する送信手段、契約者が必要事項を入力し、契約者の電子署名を付した状態の入力後契約書データを前記クライアント端末から受信する受信手段、全ての契約者から入力後契約書データを受信した時点で、前記サーバ及び各契約者の電子署名の対象となっているフィールドのデータを入力後契約書データから抽出し、各電子署名を検証する検証手段、前記検証手段が全ての電子署名を正しく検証できた場合に契約を成立させる成立手段、として動作させる。
【００１５】
上記のように構成された発明によれば、まず、契約書データにサーバの電子署名が付与されて入力前契約書データが作成され、これが契約者のクライアント端末へ送信される。契約者は必要事項を入力し、電子署名を付与し、入力後契約書データとしてサーバ装置へ送信する。サーバ装置はこれを受信する。全ての契約者にこの処理が行われた時点で、サーバ及び各契約者の電子署名の対象となっているフィールドのデータが入力後契約書データから抽出され、各電子署名の検証がなされる。全ての電子署名が正しく検証できれば、契約書データに対する改竄がなく、かつ、入力がそれぞれ契約者本人により行われたことがわかるので、契約が成立する。
【００１６】
請求項７に記載の発明は、請求項６に記載のプログラムにおいて、入力前契約書データと入力後契約書データとを比較して契約書データの一致を検出する比較手段として更に動作させ、前記成立手段は、全ての契約者について、前記比較手段が契約書データの一致を検出し、かつ、前記検証手段が電子署名を正しく検証できた場合に、契約を成立させる。これにより、入力前契約書データと入力後契約書データとが一致すれば、契約書データに対する改竄がないことがわかり、契約者の電子署名の検証が正しく行われれば、入力が契約者本人により行われたことがわかるので、契約が成立する。
【００１７】
請求項８に記載の発明は、請求項６または請求項７に記載のプログラムにおいて、前記契約書データは、対応する電子フォームのデータを含む。これにより、契約書データを電子的な書類として正しく表示することができる。
【００１８】
請求項９に記載の発明は、請求項６または請求項７に記載のプログラムにおいて、前記契約書データは、対応する電子フォームの識別情報を含む。これにより、契約書データを電子的な書類として正しく表示することを確保しつつ、契約書データのデータ量を減らすことができる。
【００２７】
【発明の実施の形態】
以下、図面を参照して本発明の好適な実施の形態について説明する。
【００２８】
図１は、本発明のオンライン契約システムによるオンライン契約手続の概要を示す。図１の例では、企業Ｂとユーザ甲との間である契約が行われる。企業Ｂは、例えば保険会社、リース会社など、ユーザとの間で契約を行う種々のものが該当する。企業Ｂ側は、契約者として例えば代表取締役などである個人乙が契約書に記名、署名などを行うものとする。
【００２９】
企業Ａは、企業Ｂとユーザ甲との間に入り、インターネットを使用してオンライン契約手続を実行する企業であり、契約手続を行うことにより、企業Ｂ及び／又はユーザ甲から所定のサービス料を得る場合がある。企業Ａは契約代行サーバを運営し、インターネットを通じて甲及び乙のクライアント端末と通信を行って契約手続のために必要な処理を実行する。
【００３０】
企業Ａのサーバ及び契約者のクライアント端末を含むオンライン契約システムの概略構成を図２に示す。図２において、企業Ａのサーバ１０と、契約者（甲、乙）のクライアント端末２０とがインターネット１を介して通信可能に接続されている。サーバ１０は、フォームＤＢ１１、マスターＤＢ１２、契約情報ＤＢ１３に接続される。フォームＤＢ１１は、契約に利用される電子フォームを蓄積している。電子フォームとは、通常の紙書類の契約書などを電子データとしたものであり、契約内容の記載や契約者の氏名記入欄などの枠やフィールドなどを示すデータである。電子フォームを利用して電子書類を作成する際には、契約者などが契約内容を記述した入力データを作成して電子フォームの対応するフィールドに挿入し、さらに契約者が氏名などの必要事項を対応するフィールドに入力することになるが、これら入力データは電子フォーム自体とは別のデータとして管理される。即ち、電子フォームと、それに対する入力データとを組み合わせることにより、１つの電子書類が作成されることになる。
【００３１】
本発明の場合、各種の契約書に対応する電子フォームがフォームＤＢ１１に保存されており、各種の契約内容を記述した入力データがマスターＤＢ１２に保存されている。サーバ１０はこれらを組み合わせることにより契約書の電子書類（以下、「契約書データ」と呼ぶ。）を作成し、契約者に提供することになる。
【００３２】
契約情報ＤＢ１３には、契約手続の完了までに発生する様々のデータが、契約処理の進行に伴って順次保存されていく。具体的には、契約者の要求により１つの契約手続が開始すると、まずそれに対する契約ＩＤが生成され契約情報ＤＢ１３に保存される。次に、以後の契約処理に伴って発生する種々のデータがこの契約ＩＤの下に蓄積されていく。契約情報ＤＢ１３に蓄積されるデータとしては、例えば、対象となる契約書データ、その契約書データにおいて使用されている電子フォーム自体又は電子フォームＩＤ、契約者の電子署名、契約成立を示すデータ、契約手続において契約者やサーバが行った手続のログデータ、などが含まれる。
【００３３】
また、サーバ１０には、後述する契約書データの処理や契約内容の検証処理などを実行するためのサーバアプリケーション１４（以下、「サーバアプリ」と呼ぶ。）が導入されている。なお、サーバアプリ１４は、コンピュータプログラムとして構成することができる。
【００３４】
一方、クライアント端末２０には、契約者としての必要事項の入力、電子署名の付与などの処理を実行するためのクライアントモジュール２２が導入されている。クライアントモジュールもコンピュータプログラムとして構成することができる。また、クライアント端末２０は、図示しないＩＣカードリーダにより契約者の所持するＩＣカード２１との間でデータの入出力が可能である。ＩＣカード２１には、例えば、契約者の電子署名の秘密鍵などが含まれている。従って、クライアントモジュール２２は、ユーザが電子署名を付与する際に、クライアント端末２０内又はＩＣカード２１中に存在する秘密鍵を使用して電子署名を作成する。
【００３５】
次に、図１及び２を参照して、オンライン契約手続の流れを概説する。図１の例においては、個人契約者甲と、企業Ｂに属する契約者乙との間である契約が行われる。企業Ａは、サーバ１０によりオンラインでその契約手続の補助、代行を行い、契約が完了するとそれを企業Ｂに報告する。
【００３６】
まず、契約者甲と企業Ｂとの間の契約に関して、企業Ａに代行依頼がなされると、サーバ１０は企業ＢのマスターＤＢから契約内容データを取得し、企業ＡのマスターＤＢ１２に保存する（ステップＳ０）。次に、サーバ１０はその契約内容データに対応する電子フォームをフォームＤＢ１１から取得し、両者を組み合わせて契約書データを作成し、契約者甲のクライアント端末２０へ送信する（ステップＳ１）。甲は、クライアント端末２０のクライアントモジュール２２を利用して、契約書データに必要事項（具体的には甲の氏名など）を入力し、甲の電子署名を付与してサーバ１０へ返信する（ステップＳ２）。
【００３７】
次に、サーバ１０は、甲の電子署名が付された契約書データを乙のクライアント端末２０へ送信する（ステップＳ３）。これに対し、乙は必要事項を入力し、乙の電子署名を付与してサーバ１０へ返信する（ステップＳＳ４）。サーバ１０は、こうして受け取った契約書データ及び電子署名を利用して、契約書の内容の改変の有無の検査ならびに甲及び乙の電子署名の検証などの処理（以下、「契約情報検証処理」とも呼ぶ。）を行う。本発明はこの契約情報検証処理に関連するものであり、その詳細は後述する。そして、サーバ１０における検証の結果、契約内容の改変がなく、甲及び乙の電子署名が正しいことが確認されると、サーバ１０は契約書データや甲、乙の電子署名データなどを契約情報ＤＢ１３に保存するとともに、企業Ｂに送信して契約成立の報告を行う（ステップＳ５）。企業Ｂは、契約成立したデータを企業Ｂの契約情報ＤＢに格納する（ステップＳ６）。
こうして、オンライン契約手続が完了する。
【００３８】
なお、サーバ１０は、契約手続中に行われた処理のログデータをとり、契約情報ＤＢ１３に保存することができる。これにより、サーバと契約者のクライアント端末との間でデータの送受信が行われた日時などの履歴を保存し、後に問題となった場合に参照などすることができる。
【００３９】
次に、サーバ１０と契約者のクライアント端末２０との間で行われる契約手続について詳細に説明する。契約手続は、サーバ１０が契約者に契約書データを提供し、契約者がこれに氏名などの必要事項を記入し、電子署名を付与することにより行われる。２者間の契約では、１人の契約者が必要事項を記入し、電子署名を付した後、さらにもう１人の契約者が必要事項を入力し、電子署名を付す。サーバ１０は、２人の契約者が必要事項を入力した契約書データ及び２人の契約者の電子署名の検証を行う。
【００４０】
サーバ１０が実行する契約情報検証処理においては、主として２つの事項について検証が行われる。１つは、「契約書データの原本性の確認」である。最初にサーバ１０から契約者に送信される契約書データには、契約内容が記載されている。契約書データが契約者に送信され、契約者が必要事項を記入し、電子署名を付してサーバ１０へ返信される間に、契約内容が契約者によって改竄されたり、又はインターネットによる送信中に第３者により改竄されたりしていないかを確認する必要がある。契約書データの原本性の確認はこのために行われる。もう１つは、「契約者（記入者）の確認」である。つまり、本人以外の者が偽って契約者になりすまして契約を行っていないかの確認である。この２つの検証を行うための方法を以下に説明する。
［１］第１の契約情報検証方法
以下に、第１の契約情報検証方法を説明する。第１の方法では、上記の「契約書データの原本性の確認」は、契約者が必要事項を入力する前後の契約書データ同士を比較することにより行う。また、「記入者の確認」は、付与された電子署名を復号化して検証することにより行う。なお、契約書データ同士を比較するために、企業Ａの契約情報ＤＢ１３は履歴管理機能を備えたものを使用する。また、契約書データの比較は、契約書データを構成する複数のフィールド単位で比較を行うことになる。
（１）原本性の確認
まず、契約書データの原本性の確認方法について説明する。サーバ１０はマスターＤＢ１２中の契約内容データとフォームＤＢ１１内の電子フォームから契約書データを作成すると、その写しを契約情報ＤＢ１３に保存してから契約者甲に送信する。契約者甲は、契約書データを受信し、契約内容を確認する。
【００４１】
図５の下部の例において、契約書データは、契約内容フィールド２４（図４（Ａ）の契約書データの「契約」及び「別表」の欄）と、第１契約者フィールド２５（契約者１の氏名・住所欄）と、第２契約者フィールド２６（契約者２の氏名・住所欄）とを含む。ここで、甲は、図４（Ａ）の左側に示すように甲の情報（氏名、住所）を第１契約者フィールドに入力して、甲の電子署名を付す。この時点では、第２契約者フィールド（乙の入力欄）は未だ空欄である。甲はクライアント端末２０を使用して、入力後の契約書データ（甲の電子署名付き）をサーバ１０へ返信する。
【００４２】
サーバ１０は、受信した契約書データ（甲の電子署名付き）をまず契約情報ＤＢ１３に格納する。次に、サーバ１０はサーバアプリ１４を実行することにより、先に契約情報ＤＢ１３に保存した、甲の入力前の契約書データ中の契約内容フィールドと、甲から受信した、甲の入力後の契約書データ中の契約内容フィールドとを比較する。両者が一致すれば、甲の入力・署名処理において、契約内容に改竄はなく、契約書データの原本性が確保されたと判断される。
【００４３】
次に、サーバ１０は、今度は甲の入力後の契約書データ（図４（Ａ）の左側の状態）を乙のクライアント端末２０へ送信する。乙は、契約内容を確認し、第２契約者フィールドに氏名、住所を入力し、乙の電子署名を付してサーバ１０へ返信する。サーバ１０は、乙の入力・署名後の契約書データ（乙の電子署名付き）を受信し、契約情報ＤＢ１３内に保存する。次に、サーバ１０はサーバアプリ１４を実行することにより、先に保存した甲の入力後の契約書データ中の契約内容フィールドと、乙の入力後の契約書データ中の契約内容フィールドとを比較する。両者が一致すれば、乙の入力・署名処理中にも、契約書データの原本性が保たれたことがわかる。
【００４４】
このように、第１実施例では、契約書データの原本性は、各契約者の入力前後における契約書データ中の契約内容フィールドを比較することにより検証する。
（２）記入者の検証
次に、第１実施例における電子署名の検証について説明する。第１実施例では、基本的に図３に示す署名パターン１により電子署名が付与される。
【００４５】
図３（Ａ）に示す署名パターン１を適用した場合、甲及び乙の電子署名は契約書データ全体（即ち、入力データ＋電子フォーム）に対して付与される。サーバ１０のサーバアプリ１４は、契約者のクライアント端末から契約書データ及び電子署名を受信すると、最新の電子署名のみを検証する。
【００４６】
まず、契約者の入力前の契約書データがサーバ１０から甲のクライアント端末２０へ送信されると、甲は自分の情報を入力し、入力後の契約書データに対して電子署名を付して、サーバ１０へ返信する。この時、甲のクライアント端末２０のクライアントモジュール２２は、甲の入力後の契約書データ全体を対象として甲の電子署名を作成する。サーバ１０はこれらを受信し、サーバアプリ１４により、受信した契約書データ（甲の入力後）を利用して甲の電子署名を検証する。検証が正しく行えれば、その契約書データは確かに甲により入力されたと判定される。
【００４７】
次に、サーバ１０は甲の入力後の契約書データを乙のクライアント端末２０に送信する。乙は、同様に自分の情報を入力し、電子署名を付してサーバ１０へ返信する。この時、乙のクライアント端末２０のクライアントモジュール２２は、乙の入力後の契約書データ全体を対象として乙の電子署名を作成する。サーバ１０は、乙の入力後の契約書データを使用して乙の電子署名を検証し、検証が正しく行えれば、その入力が乙によってなされたと判定する。こうして、契約者の電子署名の検証がなされる。
（３）処理フロー
次に、図６を参照して、第１の契約情報検証方法によるオンライン契約手続の流れを概説する。まず、サーバ１０はサーバアプリ１４により、電子フォームと契約内容データを組み合わせて契約書データ（オリジナルデータ）を作成し（ステップＳ１０）、契約情報ＤＢ１３に保存し（ステップＳ１２）、甲のクライアント端末２０へ送信する（ステップＳ１４）。甲は契約書データを受信し、氏名・住所を入力し、電子署名を付与し（ステップＳ１６）、サーバ１０へ返信する。サーバ１０は、受信した契約書データ及び甲の電子署名を契約情報ＤＢ１３に保存し、サーバアプリ１４により甲の電子署名の検証を行う（ステップＳ１８）。次に、サーバアプリ１４は、先に契約情報ＤＢ１３に保存された甲の入力前の契約書データと、甲のクライアント端末２０から受信した甲の入力後の契約書データとを比較して原本性の確認を行う（ステップＳ２０）。甲の電子署名の検証及び契約書データの原本性の確認が無事完了すると、サーバ１０は甲の入力後の契約書データ及び甲の電子署名を契約情報ＤＢ１３に保存する。
【００４８】
次に、サーバ１０は、甲の入力・署名後の契約書データを乙のクライアント端末２０へ送信する（ステップＳ２２）。乙はこれを受け取り、自分の氏名・住所を入力し、入力後のデータに乙の電子署名を付してサーバへ返信する（ステップＳ２４）。サーバ１０では、サーバアプリ１４が乙の署名を検証し（ステップＳ２６）、さらにステップＳ２０で契約情報ＤＢ１３に保存された乙の入力前の契約書データと、乙のクライアント端末２０から受信した乙の入力後の契約書データとを比較して原本性の確認を行う（ステップＳ２８）。こうして、原本性の確認及び署名の検証が完了すると、サーバ１０は契約書データ及び乙の電子署名を契約情報ＤＢ１３に保存し、契約成立とする。
【００４９】
このように、第１の契約情報検証方法によれば、契約情報ＤＢ１３に契約者の入力前の契約書データを保存し、それと入力後の契約書データとを比較することにより契約書データの改竄を検出して契約書データの原本性を確保する。また、契約者の入力後の契約書データに基づいて各契約者の電子署名を検証し、契約者（記入者）の検証を行う。これにより、契約者データの原本性と記入者の確認を同時に行うことができる。
【００５０】
なお、サーバ１０の契約情報ＤＢ１３内に保存された契約書データの改竄を検出する目的で、契約情報ＤＢ１３に契約書データを保存する際にはサーバ側の電子署名を付し、契約情報ＤＢ１３から契約書データを取り出す際にはサーバ側の電子署名による検証を行うようにサーバアプリ１４を構成することもできる。これにより、サーバ１０内における契約書データの改竄などを検出することができる。
［２］第２の契約情報検証方法
次に、第２の契約情報検証方法を説明する。第２の方法では、上記の「契約書データの原本性の確認」及び「契約者（記入者）の検証」をいずれも電子署名を利用して行う。なお、この方法では、契約者の入力前の契約書データを契約情報ＤＢ１３に保存する必要はないので、契約情報ＤＢ１３は履歴管理機能の無いものを使用できる。
（１）原本性の確認及び電子署名の検証
この方法では、基本的に図３（Ｂ）に示す署名パターン２を使用する。署名パターン２は、契約内容データ中の特定のフィールド及び電子フォームに対してサーバ側、甲及び乙が電子署名を付す方法である。
【００５１】
図４（Ｂ）に示すように、サーバ１０は、オリジナルの契約書データに対してサーバ側の電子署名を付して甲のクライアント端末２０へ送信する。この際、サーバの電子署名の対象となるのは、契約内容フィールドである。次に、甲は自分の情報を入力し、電子署名を付与する。この際、甲のクライアント端末２０のクライアントモジュール２２は、第１契約者フィールドを対象として甲の電子署名を作成する。これにより、甲の入力後の契約書データ、サーバの電子署名及び甲の電子署名がサーバ１０へ返信され、さらに乙のクライアント端末２０に送信される。乙が入力を行い、電子署名付与の指示をクライアント端末２０に入力すると、クライアントモジュール２２は、契約書データ全体を対象として乙の電子署名を作成する。よって、この時点では、甲及び乙の両者の入力後の契約書データに対して、サーバ、甲及び乙の３つの電子署名が付加された状態でサーバ１０へ送信される。
【００５２】
さて、サーバ１０のサーバアプリ１４は、まずサーバ署名の検証を行う。サーバ署名は契約内容フィールドのみを対象として作成されているので、甲及び乙の入力後であっても、契約内容フィールド中に改竄が無ければ正しく復号化できる。つまり、サーバ署名を検証することにより、契約内容の改竄を検出することができる。
【００５３】
サーバ署名の検証により、契約内容の改竄が無いと判定されると、次にサーバアプリ１４は甲の電子署名を検証する。甲の電子署名は第１契約者フィールドを対象として作成されているので、乙の入力後であっても、契約書データから第１契約者フィールドのみを抜き出して検証すれば正しい検証を行うことができる。こうして、甲の電子署名の検証に成功すると、第１契約者フィールドの記入者が確かに甲本人であることが確認できる。次に、サーバアプリ１４は、乙の電子署名を検証する。乙の電子署名は契約書データ全体について作成されているので、サーバアプリ１４は乙のクライアント端末２０から受信した契約書データ（甲、乙の入力後）を利用して乙の電子署名を検証する。検証に成功すれば、第２契約者フィールドの記入者が乙本人であることが確認できる。
（２）処理フロー
次に、図７を参照して第２の契約情報検証処理の流れを説明する。まず、サーバ１０において契約内容データと電子フォームとにより契約書データ（オリジナルデータ）が作成され、それに対するサーバの電子署名が付され（ステップＳ４０）、契約情報ＤＢ１３に保存される（ステップＳ４２）。次に、サーバ１０が契約書データを甲のクライアント端末２０へ送信する（ステップＳ４４）。甲は自分の氏名・住所を入力し、入力後の契約書データに対して電子署名を付してサーバ１０へ送る（ステップＳ４６）。このとき、クライアント端末２０上で甲が電子署名の付与を指示すると、クライアントモジュール２２は契約書データ中の第１契約者フィールド（甲の記入欄）を対象として電子署名を作成する。サーバ１０は、甲のクライアント端末２０から受け取った契約書データ及び甲の電子署名を契約情報ＤＢ１３に保存する（ステップＳ５０）。
【００５４】
次に、サーバ１０は、サーバ及び甲の署名が付与された契約書データを乙のクライアント端末２０へ送信する（ステップＳ５２）。乙は、第２契約者フィールドに自分の氏名・住所を入力し、電子署名付与の指示を入力する。これにより、クライアントモジュール２２は乙の入力後の契約書データに対して電子署名を作成し（ステップＳ５４）、サーバ１０へ返信する。サーバ１０は、乙のクライアント端末２０からデータを受信すると、前述のように、サーバの電子署名、甲の電子署名、乙の電子署名の順に署名を検証する。全ての署名の検証が正しく行われると、それは契約内容の原本性が保証され、かつ、甲及び乙本人が契約書データに必要事項を入力したことが確認されたことを示す。よって、サーバアプリ１４は契約書データ及びそれらの電子署名を契約情報ＤＢ１３に保存する（ステップＳ５８）。
【００５５】
なお、上記の例では、サーバの電子署名の対象を契約内容フィールド、甲の電子署名の対象を第１契約者フィールド、乙の電子署名の対象を契約書データ全体としているが、第２の契約情報検証方法では、甲の電子署名の対象となる部分が、乙の入力フィールドを含まないようにすれば、他の態様でもかまわない。こうすることにより、甲の電子署名の対象となる部分が乙の入力により変更することが無くなるので、甲の電子署名の検証を正しく行えるからである。よって、例えば、甲の電子署名の対象を契約内容フィールド＋第１契約者フィールドとすることもできる。また、乙の電子署名の対象は第２契約者フィールドのみでもよく、第２契約者フィールド＋契約内容フィールドでもよく、第２契約者フィールド＋第１契約者フィールドでもよい。
【００５６】
また、契約者が３人以上である場合でも同様の処理を適用することができる。即ち、ある契約者の電子署名が、その契約者より後に記入・署名する契約者のための契約者フィールドを含まない署名対象部分に対して作成されることを確保すれば、各契約者の電子署名を正しく検証することができる。
【００５７】
また、第１の契約情報検証方法の場合と同様に、契約情報ＤＢ１３中に契約書データを保存する際に、サーバ側で電子署名を付して、サーバ内における契約書データの改竄を検出可能とすることもできる。この場合の電子署名は、ステップＳ４０で使用した秘密鍵を用いてもよいし、それとは異なる秘密鍵を用いてもよい。
（３）変形例
次に、第２の契約情報検証方法において、別の署名パターンを使用する場合について説明する。上の例では、図３（Ｂ）に示す署名パターン２として、電子フォーム自体を含めて電子署名を付している。しかし、同種類の契約には同一の電子フォームが利用されることが多く、電子フォーム自体を契約書データに含めて契約情報ＤＢ１３に保存すると、保存すべき契約書データのデータ量が大きくなってしまう。そこで、図３（Ｃ）及び図４（Ｃ）に示すように、電子フォーム自体の代わりに、電子フォームを特定する紐付け情報（例えば電子フォームのＩＤなど）を契約書データに含める。即ち、署名パターン２の契約内容データ及び電子フォームの代わりに、契約内容データ及び対応する電子フォームの紐付け情報を利用して電子署名を作成する。これにより、各契約書データは電子フォーム自体を含まなくなるので、個々の契約書データの容量を小さくすることができ、契約情報ＤＢ１３の容量を効率的に使用することができる。これは、具体的にはクライアント端末２０のクライアントモジュールが電子署名を付与する際に、電子署名の対象として、電子フォーム自体の代わりに電子フォームの紐付け情報を利用するように構成すればよい。
【００５８】
なお、署名パターン３を使用した場合も、甲の電子署名の対象が乙の入力範囲を含まないようにすれば、甲及び乙の電子署名の対象を種々の態様で決めることができるのは同様である。
【００５９】
なお、上記の例では、第１の契約情報検証方法において署名パターン１を使用し、第２の契約情報検証方法において署名パターン２又は３を使用しているが、第１の契約情報検証方法において署名パターン２及び３を使用することも可能である。
【００６０】
また、クライアント端末がサーバから契約書データを受信した際に、まずその時点の契約書データに付されている電子署名を検証するように構成することもできる。これにより、契約者が正しい契約内容データに対して入力・署名することが確保される。これは、クライアントモジュール２２に電子署名の検証機能を含めることにより実現できる。具体的には、甲のクライアント端末でサーバの電子署名を検証し、乙のクライアント端末でサーバ及び甲の電子署名を検証することができる。
【００６１】
また、上記の例では、説明の便宜上、２者間の契約の場合について説明しているが、同様の処理により３者以上の間での契約手続も行うことができる。
【００６２】
【発明の効果】
以上説明したように、本発明によれば、契約内容の原本性を確保し、電子署名により契約者の認証を行うことにより、安全にオンライン契約手続を実行することができる。
【図面の簡単な説明】
【図１】本発明のシステムによるオンライン契約処理の概要を示す。
【図２】本発明のオンライン契約システムの概略構成図である。
【図３】本発明のオンライン契約手続において使用できる署名パターンを示す。
【図４】署名パターン１及び２における電子署名の方法を示す。
【図５】署名パターン３における電子署名の方法を示す。
【図６】第１の契約情報検証処理を示すフローチャートである。
【図７】第２の契約情報検証処理を示すフローチャートである。
【符号の説明】
１インターネット
１０サーバ
１１フォームＤＢ
１２マスターＤＢ
１３契約情報ＤＢ
２０クライアント端末[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a system for performing online contract procedures using electronic forms and electronic signatures on the Internet.
[0002]
[Prior art]
With recent advances in electronic technology and network technology, an environment for performing various procedures on the Internet, which has conventionally been performed with paper documents, is being prepared. For example, procedures such as notification and application to government offices and contract procedures such as insurance and lease can be performed online using electronic documents and electronic signatures.
[0003]
[Problems to be solved by the invention]
In such an environment, when multiple parties make a certain type of online contract, all contractors will use their electronic signatures to indicate their consent for common contract details. .
[0004]
However, if a method is used in which multiple contractors simply give digital signatures to the same contract document data in sequence, it is not possible to correctly verify the electronic signatures of all members when performing verification to establish a contract later. The problem arises. For example, when contracting between contractors A and B, if contractor A fills in the necessary information (name, address, etc. of contractor A) and gives an electronic signature to contract data, the electronic The signature is created for the contract document data after the contractor A has entered. Next, the contractor A fills in the necessary items, and the contractor B fills in the necessary items and attaches the electronic signature to the contract document data to which the electronic signature is added. As a result, the contract data exists after the contractors A and B have entered the necessary items, and the electronic signatures of the contractors A and B exist.
[0005]
Here, since the electronic signature of the contractor B is created for the contract document data after both the contractors A and B fill in the necessary items, it can be correctly verified. However, since the electronic signature of the contractor A is created for the contract data before the contractor B fills in the necessary items as described above, the contract after the contractor B fills in the necessary items. It cannot be verified correctly using data.
[0006]
In this way, in order to implement online contracts between multiple contractors, when multiple parties fill out the necessary information for the same contract data and attach electronic signatures, A system that can correctly verify an electronic signature is required.
[0007]
The present invention has been made in view of the above points, and it is possible to safely implement an online contract procedure by correctly verifying the electronic signatures of all the contractors performed on the same contract document data. An object is to provide a possible system and a program therefor.
[0008]
[Means for Solving the Problems]
  The invention according to claim 1 is a database device for storing contract information in a server device of an online contract system connected to a client terminal of a contractor through a network;Includes contract content field and multiple contractor input fieldsContract dataFor the contract content field, create an electronic signature of the server and assign it to the contract data,Pre-entry contract data with no contractor input yetTransmitting means for transmitting to the client terminal of the contractor, receiving means for receiving the contract document data from the client terminal after the input by the contractor inputting the necessary items and attaching the electronic signature of the contractor, At the time of receiving the contract document data after input from the contractor, the verification means for extracting the data of the server and the fields subject to the digital signature of each contractor from the contract document data after input and verifying each electronic signature And when the verification means can verify all electronic signatures correctly.Establishing means for establishing a contract.
[0009]
  According to the invention configured as described above,First, the electronic signature of the server is added to the contract data to create pre-input contract data, which is transmitted to the contractor's client terminal. The contractor inputs necessary items, assigns an electronic signature, and transmits it to the server apparatus as contract data after input. The server device receives this. When this processing is performed for all contractors, the data of the server and the fields that are the targets of the digital signatures of each contractor are extracted from the contract document data after input, and each digital signature is verified. If all the electronic signatures can be verified correctly, it is understood that the contract data has not been tampered with and that the input has been performed by the contractor himself / herself, and thus the contract is established.
[0010]
  The invention according to claim 2 is the server apparatus according to claim 1,Comparing means for detecting agreement between contract data by comparing pre-input contract data and post-input contract data, and the establishment means, for all contractors, the comparing means confirms agreement data agreement. If it is detected and the verification means can verify the electronic signature correctly, a contract is established. As a result, if the pre-input contract data matches the post-input contract data, it can be seen that there is no falsification of the contract data, and if the digital signature of the contractor is correctly verified, the input is made by the contractor himself / herself. Since it is known that the contract has been made, the contract is established.
[0011]
  The invention according to claim 3 is the server device according to claim 1 or 2,Log recording means for storing in the database a log of processing performed by the transmission means, the reception means, the verification means, and the establishment means; Thereby, it is possible to save a record of processing at each stage until the contract is established.
[0012]
  The invention according to claim 4 is the server apparatus according to any one of claims 1 to 3,The contract data includes corresponding electronic form data. Thereby, contract data can be correctly displayed as an electronic document.
[0013]
  The invention described in claim 54. The server apparatus according to claim 1, wherein the contract data includes identification information of a corresponding electronic form. Thereby, it is possible to reduce the data amount of the contract data itself while ensuring that the contract data is correctly displayed as an electronic document.
[0014]
The invention according to claim 6 is a program executed in a server apparatus of an online contract system connected to a client terminal of a contractor through a network, and the server apparatus includes a contract content field and a plurality of contractors. For contract data including an input field, a server electronic signature is created for the contract content field and attached to the contract data, and the contract is entered as contract data before input without the contractor's input yet. Sending means for transmitting to the client terminal of the contractor, receiving means for inputting the necessary information by the contractor and receiving the contract data after the input with the digital signature of the contractor input from all the contractors When the post-contract data is received, the fee that is the subject of the electronic signature of the server and each contractor. Extracting de data from the input after agreement data, verification means for verifying the electronic signature, the verification means established means for establishing a contract when correctly validate all electronic signature, to operate as.
[0015]
According to the invention configured as described above, first, the electronic signature of the server is added to the contract data, and the pre-input contract data is created and transmitted to the client terminal of the contractor. The contractor inputs necessary items, assigns an electronic signature, and transmits it to the server apparatus as contract data after input. The server device receives this. When this processing is performed for all contractors, the data of the server and the fields that are the targets of the digital signatures of each contractor are extracted from the contract document data after input, and each digital signature is verified. If all the electronic signatures can be verified correctly, it is understood that the contract data has not been tampered with and that the input has been performed by the contractor himself / herself, and thus the contract is established.
[0016]
According to a seventh aspect of the invention, in the program according to the sixth aspect, the pre-input contract document data is compared with the post-input contract data to detect a match between the contract data, The establishment means establishes a contract for all contractors when the comparison means detects agreement data agreement and the verification means can correctly verify the electronic signature. As a result, if the pre-input contract data matches the post-input contract data, it can be seen that there is no falsification of the contract data, and if the digital signature of the contractor is correctly verified, the input is made by the contractor himself / herself. Since it is known that the contract has been made, the contract is established.
[0017]
The invention according to claim 8 is the program according to claim 6 or 7, wherein the contract data includes data of a corresponding electronic form. Thereby, contract data can be correctly displayed as an electronic document.
[0018]
The invention according to claim 9 is the program according to claim 6 or claim 7, wherein the contract data includes identification information of a corresponding electronic form. Thereby, it is possible to reduce the data amount of the contract data while ensuring that the contract data is correctly displayed as an electronic document.
[0027]
DETAILED DESCRIPTION OF THE INVENTION
Preferred embodiments of the present invention will be described below with reference to the drawings.
[0028]
FIG. 1 shows an outline of an online contract procedure by the online contract system of the present invention. In the example of FIG. 1, a contract between the company B and the user A is performed. The company B corresponds to various types of contracts with users, such as an insurance company and a leasing company. On the company B side, for example, an individual B who is a representative director or the like as a contractor registers the name, signature, etc. on the contract.
[0029]
Company A is a company that enters between Company B and User A and executes an online contract procedure using the Internet. By performing the contract procedure, Company A receives a predetermined service fee from Company B and / or User A. You may get. Company A operates a contract agency server and communicates with the client terminals of Party A and Party B through the Internet to execute processing necessary for the contract procedure.
[0030]
FIG. 2 shows a schematic configuration of an online contract system including a server of company A and a client terminal of a contractor. In FIG. 2, the server 10 of the company A and the client terminal 20 of the contractor (Exhibitor A, B) are connected to be communicable via the Internet 1. The server 10 is connected to the form DB 11, the master DB 12, and the contract information DB 13. The form DB 11 stores electronic forms used for contracts. The electronic form is an electronic data such as a contract of a normal paper document, and is data indicating a frame or a field such as a description of the contract contents or a name entry column of the contractor. When creating an electronic document using an electronic form, the contractor creates input data describing the contract contents and inserts it into the corresponding field of the electronic form. Although input is made in the corresponding field, these input data are managed as data different from the electronic form itself. That is, one electronic document is created by combining an electronic form and input data corresponding thereto.
[0031]
In the present invention, electronic forms corresponding to various contracts are stored in the form DB 11, and input data describing various contract contents is stored in the master DB 12. By combining these, the server 10 creates an electronic document of the contract (hereinafter referred to as “contract data”) and provides it to the contractor.
[0032]
Various data generated until the completion of the contract procedure is sequentially stored in the contract information DB 13 as the contract process proceeds. Specifically, when one contract procedure is started at the request of the contractor, a contract ID is first generated and stored in the contract information DB 13. Next, various data generated in the subsequent contract processing are accumulated under the contract ID. The data stored in the contract information DB 13 includes, for example, target contract data, the electronic form itself or electronic form ID used in the contract data, the contractor's electronic signature, data indicating contract establishment, contract Log data of procedures performed by the contractor or server in the procedures are included.
[0033]
In addition, a server application 14 (hereinafter referred to as “server application”) for executing contract data processing, contract content verification processing, and the like, which will be described later, is introduced into the server 10. The server application 14 can be configured as a computer program.
[0034]
On the other hand, the client terminal 20 is provided with a client module 22 for executing processing such as inputting necessary items as a contractor and assigning an electronic signature. The client module can also be configured as a computer program. The client terminal 20 can input and output data with an IC card 21 possessed by a contractor by an IC card reader (not shown). The IC card 21 includes, for example, a contractor's electronic signature private key. Therefore, the client module 22 creates an electronic signature using a private key existing in the client terminal 20 or in the IC card 21 when the user gives the electronic signature.
[0035]
Next, the flow of the online contract procedure will be outlined with reference to FIGS. In the example of FIG. 1, a contract between the individual contractor A and the contractor B belonging to the company B is performed. The company A assists and substitutes the contract procedure online by the server 10 and reports it to the company B when the contract is completed.
[0036]
First, regarding the contract between the contractor A and the company B, when the agency A is requested to act on behalf of the company A, the server 10 acquires the contract content data from the master DB of the company B and stores it in the master DB 12 of the company A ( Step S0). Next, the server 10 acquires an electronic form corresponding to the contract content data from the form DB 11, creates a contract document data by combining both, and transmits it to the client terminal 20 of the contractor A (step S1). Using the client module 22 of the client terminal 20, the user inputs necessary items (specifically, the user's name, etc.) into the contract data, adds the electronic signature of the user, and returns it to the server 10 (step) S2).
[0037]
Next, the server 10 transmits the contract document data to which the former electronic signature is attached to the client terminal 20 of the second party (step S3). In response to this, the second party inputs necessary information, gives the second party's electronic signature, and returns it to the server 10 (step SS4). The server 10 uses the contract data and the electronic signature received in this manner to inspect whether or not the contents of the contract have been altered and to verify the electronic signatures of Party A and Party B (hereinafter referred to as “contract information verification process”). Call). The present invention relates to the contract information verification processing, and details thereof will be described later. As a result of verification in the server 10, if it is confirmed that there is no modification of the contract contents and the electronic signatures of Party A and Party B are correct, the server 10 stores the contract document data, Party A and Party B electronic signature data, etc. in the contract information DB 13 And is transmitted to the company B to report the conclusion of the contract (step S5). The company B stores the contracted data in the contract information DB of the company B (step S6).
Thus, the online contract procedure is completed.
[0038]
The server 10 can take log data of processing performed during the contract procedure and save it in the contract information DB 13. As a result, it is possible to save a history such as the date and time when data is transmitted and received between the server and the client terminal of the contractor, and refer to it when a problem occurs later.
[0039]
Next, the contract procedure performed between the server 10 and the client terminal 20 of the contractor will be described in detail. The contract procedure is performed when the server 10 provides contract data to the contractor, and the contractor fills in necessary information such as a name and gives an electronic signature. In a contract between two parties, one contractor fills in the necessary items and attaches an electronic signature, and then another contractor inputs necessary items and attaches the electronic signature. The server 10 verifies contract data in which necessary information is input by two contractors and electronic signatures of the two contractors.
[0040]
In the contract information verification process executed by the server 10, two items are mainly verified. One is “confirmation of originality of contract data”. The contract contents are first described in the contract document data transmitted from the server 10 to the contractor. While the contract data is transmitted to the contractor, the contractor fills in the necessary items, returns an electronic signature, and is sent back to the server 10, while the contract content is altered by the contractor or during transmission via the Internet It is necessary to confirm whether or not it has been tampered with by a third party. For this purpose, the originality of the contract data is confirmed. The other is “confirmation of contractor (entrant)”. In other words, it is a confirmation that a person other than the principal has falsely impersonated a contractor and has not made a contract. A method for performing these two verifications will be described below.
[1] First contract information verification method
Below, the 1st contract information verification method is demonstrated. In the first method, the above “confirmation of originality of contract data” is performed by comparing contract data before and after the contractor inputs necessary items. “Confirmation of writer” is performed by decrypting and verifying the attached electronic signature. In order to compare the contract data, the contract information DB 13 of the company A uses a history management function. Further, the comparison of the contract data is performed in units of a plurality of fields constituting the contract data.
(1) Confirmation of originality
First, a method for confirming the originality of contract data will be described. When the server 10 creates contract data from the contract content data in the master DB 12 and the electronic form in the form DB 11, the server 10 stores the copy in the contract information DB 13 and transmits it to the contractor A. Contractor A receives the contract data and confirms the contract contents.
[0041]
In the example at the bottom of FIG. 5, the contract data includes a contract content field 24 (“Contract” and “Annex” fields in FIG. 4A) and a first contractor field 25 (contractor 1). And the second contractor field 26 (name and address field of the contractor 2). Here, as shown on the left side of FIG. 4A, the user inputs information (name, address) of the user in the first contractor field and attaches the electronic signature of the user. At this point in time, the second contractor field (secondary input field) is still blank. Party A uses client terminal 20 to return the entered contract data (with electronic signature of Party A) to server 10.
[0042]
The server 10 first stores the received contract document data (with the electronic signature of Party A) in the contract information DB 13. Next, the server 10 executes the server application 14 to store the contract contents field in the contract data before the input of the former, which is stored in the contract information DB 13, and the contract after the input of the first received from the first. Compare the contract contents field in the document data. If the two match, it is determined that the contract contents have not been falsified and the originality of the contract data has been secured in the input / signature processing of Class A.
[0043]
Next, the server 10 transmits the contract document data (the state on the left side of FIG. 4A) after the input of the former to the client terminal 20 of the second party. The party B confirms the contents of the contract, enters the name and address in the second contractor field, attaches the electronic signature of the party B, and returns it to the server 10. The server 10 receives the contract document data (with the electronic signature of the second party) after being input and signed by the second party, and stores it in the contract information DB 13. Next, the server 10 executes the server application 14 to compare the contract content field in the contract data after the input of the former saved with the contract content field in the contract data after the input of the second party. To do. If the two match, it can be seen that the originality of the contract data was maintained during the input / signature processing of B.
[0044]
As described above, in the first embodiment, the originality of the contract data is verified by comparing the contract content fields in the contract data before and after each contractor input.
(2) Verification of entrants
Next, verification of the electronic signature in the first embodiment will be described. In the first embodiment, an electronic signature is basically given by the signature pattern 1 shown in FIG.
[0045]
When the signature pattern 1 shown in FIG. 3A is applied, the electronic signatures of Party A and Party B are given to the entire contract data (that is, input data + electronic form). When the server application 14 of the server 10 receives the contract data and the electronic signature from the client terminal of the contractor, the server application 14 verifies only the latest electronic signature.
[0046]
First, when the contract data before input of the contractor is transmitted from the server 10 to the client terminal 20 of the user A, the user inputs his information and attaches an electronic signature to the contract data after the input. Reply to the server 10. At this time, the client module 22 of the former client terminal 20 creates an electronic signature of the former for the entire contract document data after the input of the former. The server 10 receives these, and the server application 14 verifies the electronic signature of the former using the received contract data (after the input of the former). If the verification can be performed correctly, it is determined that the contract data has been input by the user.
[0047]
Next, the server 10 transmits the contract document data after the input of the former to the client terminal 20 of the second party. Similarly, B enters his / her information, attaches an electronic signature, and sends it back to the server 10. At this time, the client module 22 of the second client terminal 20 creates a second electronic signature for the entire contract data after the second input. The server 10 verifies the electronic signature of the second party using the contract data after the second party's input, and determines that the input has been made by the second party if the verification can be performed correctly. Thus, the electronic signature of the contractor is verified.
(3) Processing flow
Next, with reference to FIG. 6, the flow of the online contract procedure according to the first contract information verification method will be outlined. First, the server 10 creates contract data (original data) by combining the electronic form and the contract content data with the server application 14 (step S10), and stores it in the contract information DB 13 (step S12). (Step S14). The party A receives the contract data, inputs the name and address, gives an electronic signature (step S16), and returns it to the server 10. The server 10 stores the received contract document data and the electronic signature of the former in the contract information DB 13, and verifies the electronic signature of the former by the server application 14 (step S18). Next, the server application 14 compares the original contract data stored in the contract information DB 13 before input with the original contract data received from the client terminal 20 of the original A by comparing the original contract data. Is confirmed (step S20). When the verification of the electronic signature of Party A and the confirmation of the originality of the contract document data are successfully completed, the server 10 stores the contract document data and the electronic signature of Party A after the input of Party A in the contract information DB 13.
[0048]
Next, the server 10 transmits the contract document data after the input / signature of the former to the client terminal 20 of the second party (step S22). The second party receives this, inputs his / her name and address, attaches the second party's electronic signature to the input data, and returns it to the server (step S24). In the server 10, the server application 14 verifies the signature of the second party (step S 26), and further, the contract document data stored in the contract information DB 13 stored in the contract information DB 13 in step S 20 and the second version of the second party received from the second client terminal 20. The original document is confirmed by comparing with the contract data after the input (step S28). When the originality confirmation and signature verification are completed in this way, the server 10 saves the contract data and the electronic signature of the second party in the contract information DB 13 and establishes the contract.
[0049]
Thus, according to the first contract information verification method, the contract data before contractor input is stored in the contract information DB 13, and the contract data after input is compared with the contract data after falsification. To detect the originality of the contract data. Further, the digital signature of each contractor is verified based on the contract document data after the contractor inputs, and the contractor (entrant) is verified. Thereby, the originality of the contractor data and the confirmation of the writer can be performed at the same time.
[0050]
For the purpose of detecting falsification of the contract document data stored in the contract information DB 13 of the server 10, when the contract data is stored in the contract information DB 13, an electronic signature on the server side is added, and the contract information DB 13 When retrieving the contract data, the server application 14 can be configured so as to perform verification by the electronic signature on the server side. Thereby, falsification of contract data in the server 10 can be detected.
[2] Second contract information verification method
Next, the second contract information verification method will be described. In the second method, the above-described “confirmation of originality of contract data” and “verification of contractor (entrant)” are both performed using an electronic signature. In this method, it is not necessary to save the contract document data before the contractor's input in the contract information DB 13, so that the contract information DB 13 without a history management function can be used.
(1) Confirmation of originality and verification of electronic signature
In this method, a signature pattern 2 shown in FIG. 3B is basically used. The signature pattern 2 is a method in which the server side, Party A and Party B attach an electronic signature to a specific field and electronic form in the contract content data.
[0051]
As shown in FIG. 4B, the server 10 attaches an electronic signature on the server side to the original contract data and transmits it to the client terminal 20 of the former. At this time, the contract content field is the target of the electronic signature of the server. Next, Party A enters his information and gives an electronic signature. At this time, the client module 22 of the former client terminal 20 creates the former electronic signature for the first contractor field. As a result, the contract document data after the input of the user A, the electronic signature of the server, and the electronic signature of the user A are returned to the server 10 and further transmitted to the client terminal 20 of the second party. When the second party inputs and inputs an instruction to give an electronic signature to the client terminal 20, the client module 22 creates the second electronic signature for the entire contract data. Therefore, at this time, the contract data after the input of both Party A and Party B is transmitted to the server 10 with the three electronic signatures of the server, Party A and Party B added.
[0052]
Now, the server application 14 of the server 10 first verifies the server signature. Since the server signature is created only for the contract content field, it can be correctly decrypted even after the inputs of Party A and Party B if there is no falsification in the contract content field. That is, by verifying the server signature, it is possible to detect falsification of the contract contents.
[0053]
If it is determined by the verification of the server signature that the contract contents have not been tampered with, then the server application 14 verifies the electronic signature of the former. Since the electronic signature of Party A is created for the first contractor field, it is possible to perform correct verification by extracting only the first contractor field from the contract document data and verifying it even after the input of the second party. it can. Thus, if the verification of the electronic signature of the first party is successful, it can be confirmed that the person who filled in the first contractor field is the first person. Next, the server application 14 verifies the electronic signature of the second party. Since the second party's electronic signature is created for the entire contract data, the server application 14 verifies the second party's electronic signature using the contract data (after the first and second inputs) received from the second client terminal 20. . If the verification is successful, it can be confirmed that the person who fills in the second contractor field is the principal.
(2) Processing flow
Next, the flow of the second contract information verification process will be described with reference to FIG. First, contract data (original data) is created by the contract content data and the electronic form in the server 10, and the server's electronic signature is added to the contract data (step S40) and stored in the contract information DB 13 (step S42). Next, the server 10 transmits the contract document data to the client terminal 20 of the former (step S44). The user inputs his / her name and address, attaches an electronic signature to the contract data after the input, and sends it to the server 10 (step S46). At this time, if the user A gives an instruction to give an electronic signature on the client terminal 20, the client module 22 creates an electronic signature for the first contractor field (entry entry field) in the contract data. The server 10 stores the contract document data and the electronic signature of the first party received from the first client terminal 20 in the contract information DB 13 (step S50).
[0054]
Next, the server 10 transmits the contract document data to which the signature of the server and the former A is given to the client terminal 20 of the second party (step S52). B enters his / her name and address in the second contractor field, and inputs an instruction to give an electronic signature. As a result, the client module 22 creates an electronic signature for the contract document data after input by the second party (step S54), and returns it to the server 10. When the server 10 receives data from the client terminal 20 of the second party, the server 10 verifies the signature in the order of the electronic signature of the server, the first electronic signature of the first party, and the second electronic signature. If all signatures are verified correctly, it indicates that the originality of the contract has been guaranteed and that it has been confirmed that the user and the principal have entered the required information in the contract data. Therefore, the server application 14 stores the contract data and their electronic signatures in the contract information DB 13 (step S58).
[0055]
In the above example, the electronic signature target of the server is the contract content field, the electronic signature target of the former is the first contractor field, and the electronic signature target of the second party is the entire contract data. In the information verification method, other forms may be used as long as the part to be subject to the electronic signature of the former does not include the input field of the second party. By doing so, the part of the subject of the electronic signature of the first party is not changed by the input of the second party, so that the verification of the electronic signature of the first party can be performed correctly. Therefore, for example, the subject of the electronic signature of the former can be the contract content field + the first contractor field. The subject of the electronic signature of the second party may be only the second contractor field, the second contractor field + contract content field, or the second contractor field + first contractor field.
[0056]
The same processing can be applied even when there are three or more contractors. That is, if it is ensured that an electronic signature of a contractor is created for a part to be signed that does not include a contractor field for a contractor who fills and signs after the contractor, the electronic signature of each contractor The signature can be verified correctly.
[0057]
Similarly to the case of the first contract information verification method, when the contract data is stored in the contract information DB 13, it is possible to detect falsification of the contract data in the server by attaching an electronic signature on the server side. It can also be. In this case, for the electronic signature, the secret key used in step S40 may be used, or a different secret key may be used.
(3) Modification
Next, a case where another signature pattern is used in the second contract information verification method will be described. In the above example, an electronic signature including the electronic form itself is attached as the signature pattern 2 shown in FIG. However, the same electronic form is often used for the same type of contract. If the electronic form itself is included in the contract data and stored in the contract information DB 13, the amount of contract data to be stored increases. End up. Therefore, as shown in FIGS. 3C and 4C, instead of the electronic form itself, association information (for example, the ID of the electronic form) specifying the electronic form is included in the contract data. That is, instead of the contract content data and electronic form of the signature pattern 2, an electronic signature is created using the contract content data and the associated information of the electronic form. Thereby, since each contract document data does not include the electronic form itself, the capacity of each contract document data can be reduced, and the capacity of the contract information DB 13 can be used efficiently. Specifically, when the client module of the client terminal 20 gives an electronic signature, the electronic form linking information may be used instead of the electronic form itself as the target of the electronic signature.
[0058]
Even when signature pattern 3 is used, if the subject of the electronic signature of Party A does not include the input range of Party B, the subject of the electronic signature of Party A and Party B can be determined in various ways. It is.
[0059]
In the above example, signature pattern 1 is used in the first contract information verification method, and signature pattern 2 or 3 is used in the second contract information verification method. However, in the first contract information verification method, It is also possible to use signature patterns 2 and 3.
[0060]
Further, when the client terminal receives the contract data from the server, the electronic signature attached to the contract data at that time can be verified first. This ensures that the contractor inputs and signs the correct contract content data. This can be realized by including an electronic signature verification function in the client module 22. Specifically, the electronic signature of the server can be verified by the client terminal of the former, and the electronic signature of the server and the former can be verified by the client terminal of the second party.
[0061]
Further, in the above example, the case of a contract between two parties has been described for convenience of explanation, but a contract procedure between three or more parties can also be performed by the same processing.
[0062]
【The invention's effect】
As described above, according to the present invention, it is possible to safely execute an online contract procedure by securing the originality of the contract contents and authenticating the contractor with the electronic signature.
[Brief description of the drawings]
FIG. 1 shows an outline of online contract processing by a system of the present invention.
FIG. 2 is a schematic configuration diagram of an online contract system according to the present invention.
FIG. 3 shows signature patterns that can be used in the online contract procedure of the present invention.
FIG. 4 shows a digital signature method in signature patterns 1 and 2;
FIG. 5 shows an electronic signature method in signature pattern 3;
FIG. 6 is a flowchart showing a first contract information verification process.
FIG. 7 is a flowchart showing second contract information verification processing;
[Explanation of symbols]
1 Internet
10 servers
11 Form DB
12 Master DB
13 Contract information DB
20 Client terminal

Claims

In the server device of the online contract system connected to the client terminal of the contractor through the network,
A database for storing contract information;
Regarding contract data including a contract content field and a plurality of contractor input fields, a server electronic signature is created for the contract content field and assigned to the contract data, and the contractor has not yet been input. A transmission means for transmitting the contract data before input to the client terminal of the contractor,
A receiving means for receiving contract document data from the client terminal after entering the necessary information by the contractor and attaching the electronic signature of the contractor;
When the contract data after input from all contractors is received, the server and each contractor's field data subject to digital signature are extracted from the contract data after input, and each digital signature is verified. Verification means;
And a establishing unit that establishes a contract when all the electronic signatures are correctly verified by the verification unit.

Comparing means for comparing the contract data before input and the contract data after input to detect agreement data agreement ,
2. The establishment means according to claim 1, wherein, for all contractors, the comparison means establishes a contract when the comparison means detects agreement data agreement and the verification means can correctly verify the electronic signature. Server device.

The server apparatus according to claim 1, further comprising: a log recording unit that stores a log of processing performed by the transmission unit, the reception unit, the verification unit, and the establishment unit in the database.

The server apparatus according to claim 1, wherein the contract data includes data of a corresponding electronic form.

The server apparatus according to claim 1, wherein the contract data includes identification information of a corresponding electronic form.

  A program executed in a server device of an online contract system connected to a client terminal of a contractor through a network, the server device being
  Regarding contract data including a contract content field and a plurality of contractor input fields, a server electronic signature is created for the contract content field and assigned to the contract data, and the contractor has not yet been input. Means for sending to the contractor's client terminal as the pre-input contract data
  Receiving means for receiving contract document data from the client terminal after the input of the contractor's electronic signature with the contractor inputting necessary items,
  When the contract data after input from all contractors is received, the server and each contractor's field data subject to digital signature are extracted from the contract data after input, and each digital signature is verified. Verification means,
  A program that operates as an establishment unit that establishes a contract when the verification unit can correctly verify all the electronic signatures.

It is further operated as a comparison means for comparing the pre-input contract data and the post-input contract data to detect the agreement of the contract data,
7. The establishment means according to claim 6, wherein, for all contractors, the comparison means establishes a contract when the comparison means detects agreement data agreement and the verification means can correctly verify the electronic signature. program.

The program according to claim 6 or 7, wherein the contract data includes data of a corresponding electronic form.

The program according to claim 6 or 7, wherein the contract data includes identification information of a corresponding electronic form.