JP2017135590A - 電子契約の管理システム、方法およびプログラム - Google Patents

Abstract

【課題】金融機関が法人取引先と契約手続を行うための電子契約システム、電子契約方法およびプログラムを提供する。【解決手段】電子契約システムは、契約データに基づいて電子契約文書を生成し、契約データの状態情報に基づいて契約データおよび電子契約文書を顧客から参照可能にする手段と、ログインユーザの属性情報に基づいて、それぞれの属性情報に対応した画面表示制御を行い、契約データの情報に基づいて、署名者の情報を表示する手段と、任意の種類のハッシュ関数を用いて電子署名を行う対象の電子契約文書に基づいてハッシュ値を生成し、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成し、署名者の電子証明書および公開鍵を電子契約文書にセットすることにより電子署名を行う手段と、ログインユーザの属性情報および電子契約文書の種別に応じて、電子署名が行われたことを示すスタンプを生成し、電子契約文書にスタンプを付加する手段を備える。【選択図】図１６

Description

本発明は、一般的に言えば、電子契約の管理システム、方法およびプログラムに関する。より詳細に言えば、本発明は、金融機関が法人取引先と契約手続を行うための電子契約の管理システム、方法およびプログラムに関する。本発明は、作成済みの契約書を破棄するための電子契約の破棄システム、方法およびプログラムに関する。本発明は、契約手続において債務者および保証人、並びに契約内容の確認者を識別した上で必要な処理を制御可能な電子契約における電子署名システム、方法およびプログラムに関する。

金融機関の基本的な業務として、預金業務や為替業務以外に貸付業務が知られている。貸付は、その内容によりいくつかの種類に分けられる。証書貸付は、顧客から証書（金銭消費貸借約定書）の差入を受けることにより行う貸付であり、法人向け設備資金などの長期資金の貸付などで利用される。手形貸付は、顧客から約束手形の差入を受けることにより行う貸付であり、法人の運転資金などの短期資金の貸付などで利用される。特殊当座借越は、手形・小切手用の決済用口座である当座勘定を用いずに、金融機関が一定の極度額まで当座借越により行う貸付である。特殊当座借越は、特殊当座貸越と呼ばれることもある。

貸付業務は、顧客に資金を貸し付けるため貸し倒れリスクが常に存在する。このため、顧客の信用状態、資金使途、融資期間、金額などの様々な要素を考慮し、金融機関内部の審査手続（「稟議」とも呼ぶ）を経て貸付可否の判断が行われ、貸付が実行される。より具体的に言えば、金融機関内の法人顧客の担当者は、顧客から融資の申込を受付けると、顧客の信用状態（現在の業績、財務状況、過去の融資時の返済状況など）をチェックし、貸付の可否を判断する。貸付可と判断したら、所定の決裁権限を持つ上役に融資の実行を申請し、決裁を受ける。決裁後、金融機関内の法人顧客の担当者は、証書（金銭消費貸借約定書）を作成して法人顧客に手交し、必要書類（例えば、印鑑登録証明書、商業登記簿謄本、署名済みの金銭消費貸借約定書など）を徴求して内容に誤りがないかどうかを確認する。担保がある場合には抵当権の設定なども行う。その後、金融機関内で各種事務処理（例えば、起票、検印、記帳、印字照合など）が行われた上で融資が実行される。

このように従来の融資業務は、金融機関の担当者が顧客を往訪して証書を手交し、必要書類を受領するなど人手を介することが多かったため、金融機関が顧客との間で融資取引を行う際の融資契約の締結プロセスの一部に使用される電子融資契約システムが提案されていた（特許文献１）。

一方、金融機関が顧客に提供するインターネットベースのサービスは、顧客に広く利用されつつある。このようなインターネットベースのサービスとして、法人向けインターネットバンキング、法人向け外国為替サービス、インターネットディーリングシステムなどが知られており、これらのサービスのためのポータルサービス（例えば、本件特許出願人の一が提供する、Ｖａｌｕｅ Ｄｏｏｒ（登録商標））も知られている。上述したように、融資契約に関わる業務は、人手に頼る部分が相対的に大きかったため、融資契約の電子化サービスに対するニーズが高まってきつつある。

特開２００５−２２２２６８号公報

従来の融資業務は、電子化されていない部分が多かったため、法人顧客、金融機関の営業店および事務処理部門での負担が過大となっていた。特許文献１のような電子融資契約システムが提案されていたものの、仮に、金融機関の実務に落とし込んだ場合には、不都合な部分も多く、そのままでは実務がうまく廻らないものであった。

また、一旦契約書を作成し、法人顧客が署名・押印したとしても、その後、契約書を破棄して、必要に応じて再度契約書を作成して法人顧客の署名・押印を得なければならない事態が発生することもあり、そのような場合には、法人顧客および金融機関の間で付加的な負担が発生していた。

さらに、契約書が法人顧客内で確認・署名される場合、契約者として債務者および保証人（例えば、連帯保証人）が関与し、また、必要に応じて、契約書の内容をチェックする確認者（例えば、経理部門、法務部門）が関与するので、それぞれの役割に応じて契約締結プロセスを円滑に進める必要もあった。

本発明は、このような課題に鑑みてなされたものであり、金融機関が法人取引先と契約手続を行うための電子契約システム、電子契約方法およびプログラムを提供することを目的とする。また、本発明は、既契約の電子契約書を破棄するための電子契約システム、電子契約方法およびプログラムを提供することを目的とする。さらに、本発明は、契約手続において債務者および保証人などの署名者、並びに契約内容の確認者を識別した上で必要な処理を制御可能な電子契約システム、電子契約方法およびプログラムを提供することを目的とする。

上記の課題を解決するために、本発明の一態様に係る、金融機関と顧客の間で締結される電子契約文書を取り扱う電子契約システムは、契約データに基づいて電子契約文書を生成し、かつ前記契約データの状態情報に基づいて前記契約データおよび前記電子契約文書を顧客から参照可能にする契約データ処理手段と、ログインユーザの属性情報に基づいて、それぞれの属性情報に対応した画面表示制御を行い、かつ前記契約データの情報に基づいて、署名者の情報を表示する画面制御処理手段と、任意の種類のハッシュ関数を用いて電子署名を行う対象の前記電子契約文書に基づいてハッシュ値を生成し、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成し、前記署名者の電子証明書および公開鍵を前記電子契約文書にセットすることにより電子署名を行う電子署名手段と、前記ログインユーザの前記属性情報および前記電子契約文書の種別に応じて、前記電子署名が行われたことを示すスタンプを動的に生成し、前記電子契約文書に前記スタンプを付加するスタンプ処理手段を備える。

また、本発明の一態様に係る、金融機関と顧客の間で締結される電子契約文書を取り扱う電子契約システムによって実行される方法は、契約データに基づいて電子契約文書を生成し、かつ前記契約データの状態情報に基づいて前記契約データおよび前記電子契約文書を顧客から参照可能にすることと、ログインユーザの属性情報に基づいて、それぞれの属性情報に対応した画面表示制御を行い、かつ前記契約データの情報に基づいて、署名者の情報を表示することと、任意の種類のハッシュ関数を用いて電子署名を行う対象の前記電子契約文書に基づいてハッシュ値を生成し、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成し、前記署名者の電子証明書および公開鍵を前記電子契約文書にセットすることにより電子署名を行うことと、前記ログインユーザの前記属性情報および前記電子契約文書の種別に応じて、前記電子署名が行われたことを示すスタンプを動的に生成し、前記電子契約文書に前記スタンプを付加することを備える。

本発明によれば、融資契約を始めとする各種契約手続が、金融機関と法人取引先との間で業務の流れに即して円滑に行われるようになる。本発明によれば、作成済みの契約書を破棄して、必要に応じて再度契約書を作成することが金融機関と法人取引先との間で円滑に行われるようになる。本発明によれば、債務者、保証人、確認者などといった法人顧客内での役割に応じて契約手続きを行えるようになる。

本発明によれば、従来の融資業務において作成される金銭消費貸借約定書に必要であった印紙代も不要になるため、顧客満足度が高まるという効果も得られる。本発明では、電子署名（デジタル署名、単に、署名ということもある）を利用しているので、否認防止という効果も得られる。

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。
本発明に係る電子契約システムを含むシステム全体の概要図である。 本発明に係る電子契約システムのシステム構成図である。 認証局サーバによる電子証明書および鍵ペア（公開鍵−秘密鍵）作成についての処理フローを説明する図である。 金融機関の法人顧客担当者による契約書の作成、顧客の署名者（および必要な場合には、確認者）による契約内容確認および電子署名、並びに金融機関内での融資事務連携処理についての処理フローを説明する図である。 契約書の一覧を表示する契約情報リストの一例を示す図である。 契約データを入力・選択するための契約情報の画面例を示す図である。 顧客マスタのデータ構造の一例を説明する図である。 利用者マスタのデータ構造の一例を説明する図である。 契約書ＤＢのデータ構造の一例を説明する図である。 顧客によって参照される契約書詳細の画面例を示す図である。 顧客によって参照される契約手続開始の画面例を示す図である。 顧客によって参照される契約手続の画面例を示す図である。 電子署名が行われたことを示す例示的なスタンプを示す図である。 顧客に確認者が存在する場合の処理フローを説明する図である。 電子署名がなされた契約書を破棄する際の処理フローについて説明する図である。 本発明に係る電子契約システムの機能ブロックを説明する図である。

以下、本発明の実施形態について詳細に説明する。本明細書では、電子契約締結サービスを提供する金融機関１と当該サービスを利用する顧客２との間における電子契約締結処理、すなわち、金融機関１の担当者による契約データの作成および提示、顧客２による契約内容の承認および電子署名、並びに金融機関１内での融資事務連携処理に至る各種処理について最初に説明する。換言すれば、顧客２に対する貸付についての稟議承認後の融資契約締結業務および事務プロセスについて最初に説明する。そのため、契約書を作成する前段階の業務、すなわち、顧客２から融資の申込を受け、金融機関１内で融資の可否を判断するための稟議がなされ、融資可との決裁が下りるまでの業務についての説明は省略することとする（後述する案件番号９１２は、稟議の起案時に採番され、それぞれの稟議を識別するために使用される）。その後、一旦作成され、電子署名がなされた契約書を破棄する事態が生じた際の処理について説明していくこととする。なお、本明細書では、金融機関１と顧客２の間での融資契約を例にして説明するが、本発明は融資契約に限定使用されることはなく、金融機関１と顧客２の間での各種契約手続にも適用可能であることは言うまでもない。

図１は、本発明に係る電子契約システム１００を含むシステム全体の概要図である。金融機関１は銀行などの金融機関であり、顧客２は法人や個人事業主などである。金融機関１は、勘定系システムやインターネットバンキングシステム（不図示）などの周知のシステムを有しており、図１に示すように、本発明に係る電子契約システム１００をさらに有している。電子契約システム１００は、１または複数の金融機関端末１１０と相互に通信可能であり、電子契約締結サービスに関する各種アプリケーションを金融機関端末１１０に提供することができる。金融機関端末１１０は、営業店における法人顧客の担当者および本店の審査部の担当者など、金融機関１内の予め定められた者により使用される。電子契約システム１００と金融機関端末１１０は、金融機関１内の専用線やＬＡＮなどの周知の有線／無線ネットワークを介して相互に通信可能である。

顧客２は、法人の代表者、法人内で予め定められた権限を付与された者、および個人事業主など予め定められた者が利用可能な端末である、１または複数の顧客端末１２０を有する。顧客端末１２０は、インターネット１３０などの周知のネットワークを介して電子契約システム１００と相互に通信可能であり、電子契約システム１００によって提供される電子契約締結サービスに関する各種アプリケーションを利用することができる。顧客端末１２０は、ＩＣカードから各種情報を読み取り可能なリーダ１２１と接続可能であり、リーダ１２１によってＩＣカードから読み出された各種情報を受信して利用することができる。なお、本明細書では、ＩＣカードを一例として説明するが、各種情報を記憶可能な代替記憶媒体が利用されてもよい。また、本明細書では、顧客端末１２０と電子契約システム１００の間のネットワークの一例としてインターネット１３０を説明するが、他の代替ネットワークを利用するようにしてもよい。

電子契約システム１００は、周知のネットワーク１５０を介して認証局サーバ１４０と相互に通信可能である。法人の代表者、法人内で予め定められた権限を付与された者、および個人事業主などのための電子証明書および鍵ペア（公開鍵−秘密鍵）の作成依頼が電子契約システム１００から認証局サーバ１４０に送信されると、認証局サーバ１４０は、依頼を受けた者の電子証明書および鍵ペアを生成して電子契約システム１００に送信することができる。本明細書では、電子証明書および鍵ペア（公開鍵−秘密鍵）は、電子署名のプロセスにおいて使用される。電子証明書については、その時々において相対的に安全性が高いと言われている暗号アルゴリズム（例えば、ある時代では、ＳＨＡ−２５６およびＲＳＡ２０４８）が利用されて、署名用の電子証明書が発行される。なお、鍵ペア（公開鍵−秘密鍵）および電子証明書は、リーダ１２１により読み取り可能なＩＣカードなどの記憶媒体に格納されて、顧客２の法人の代表者、法人内で予め定められた権限を付与された者、および個人事業主などに渡され、また、後述する暗証番号（ＰＩＮ）は、金融機関１の担当者から顧客２の法人の代表者、法人内で予め定められた権限を付与された者、および個人事業主などに直接手交されるなどセキュリティに配慮した受け渡しがなされてもよい。なお、金融機関１において電子契約システム１００を利用する者の電子証明書および鍵ペア（公開鍵−秘密鍵）については、予め認証局サーバ１４０によって生成されているものとする。

図２は、本発明に係る電子契約システム１００のシステム構成図である。図２に示すように、電子契約システム１００は、一般的なコンピュータと同様に、バス２１０などによって相互に接続された制御部２０１、主記憶部２０２、補助記憶部２０３、インターフェース（ＩＦ）部２０４および出力部２０５を備えることができる。電子契約システム１００はまた、ファイル／データベースとして、顧客マスタ２０６、利用者マスタ２０７および契約書ＤＢ２０８を備えることができる。

制御部２０１は、中央処理装置（ＣＰＵ）とも呼ばれ、電子契約システム１００内の各構成要素の制御やデータの演算を行い、また、補助記憶部２０３に格納されている各種プログラムを主記憶部２０２に読み出して実行することができる。主記憶部２０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶することができる。補助記憶部２０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

図２の実施形態では、制御部２０１、主記憶部２０２および補助記憶部２０３を同一のサーバコンピュータ内に設ける実施形態について説明したが、他の実施形態として、電子契約システム１００は、制御部２０１、主記憶部２０２および補助記憶部２０３を複数個使用することにより、複数のサーバコンピュータによる並列分散処理を実現するように構成されることもできる。また、他の実施形態として、電子契約システム１００用の複数のサーバを設置し、複数サーバが一つの補助記憶部２０３を共有する実施形態にすることも可能である。

ＩＦ部２０４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供することができる。出力部２０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供することができる。

顧客マスタ２０６は、顧客２の基礎情報を格納する顧客マスタファイルであり、ＣＩＦ（Customer Information File）とも言われるマスタファイルである。顧客２が金融機関１との取引を新規に行う場合には、顧客マスタ２０６に顧客情報が登録される。

図７は、顧客マスタ２０６のデータ構造の一例を説明する図である。図７に示すように、顧客マスタ２０６は、店番号７０１、取引先番号７０２、銀行口座情報７０３、および属性情報７０４を含むことができるが、これらのデータ項目に限定されることはなく他の任意のデータ項目も含むことが可能である。例えば、顧客マスタ２０６は、届出印鑑の印影、所有する法人用クレジットカードの種類、暗証番号、過去の融資記録などの情報を含むように構成されてもよく、顧客が同一金融機関内の複数の営業店に口座を保有する場合に、それらの口座を結びつける共通番号（例えば、「名寄せ」処理などの際に利用可能な識別番号）を含むように構成されてもよい。このような共通番号は、顧客２を識別するための番号として使用されることが可能なため、他の金融機関の顧客マスタにも格納されることが可能である。かかる場合には、当該共通番号に基づいて、複数の金融機関が保有する顧客の情報を関連付けることも可能となる。また、顧客マスタ２０６は、顧客の口座情報の共通データ項目として、複数のアプリケーションで利用されることができる。

店番号７０１は、顧客２を管理するそれぞれの営業店を識別する番号であり、取引先番号７０２は、当該営業店における顧客識別番号である。店番号７０１および取引先番号７０２を合わせてＣＩＦ番号（取引先番号ともいう）と呼ぶこともできる。すなわち、図７では、店番号７０１および取引先番号７０２を異なるデータ項目で示したが、両者を合わせて１つのデータ項目でＣＩＦ番号を構成することもできる。また、他の実施形態として、取引先番号７０２のみを銀行内で利用可能な顧客識別番号として利用することも可能であり、かかる場合には、ある取引先番号７０２は、複数の営業店に存在することはなく、その銀行内で唯一無二の番号として使用される。

銀行口座情報７０３は、顧客２の銀行口座の情報であり、店番号、科目、口座番号、口座名義などの情報を含むことができる。属性情報７０４は、顧客２の会社名、カナ氏名、代表取締役、住所、連絡先などの情報を含むことができる。

図２に戻って説明すると、利用者マスタ２０７は、顧客２において電子契約システム１００を、署名者または確認者として利用する者の情報を格納するマスタファイルである。署名者は、債務者および保証人（例えば、連帯保証人）を含む。確認者は、契約書の内容をチェックするために顧客２内で指名された者（例えば、部長、経理担当課長など）である。顧客２の新たな署名者および確認者が電子契約システム１００を利用する場合には、利用者マスタ２０７に情報が追加され、一方、電子契約システム１００の既存の利用者の情報に変更がある場合（例えば、人事異動などにより署名者や確認者ではなくなる場合）には、当該利用者の情報に不使用フラグが立てられたり、所属部門や役職などの情報がアップデートされたりする。なお、本発明の一実施形態では、顧客２内で指名された確認者の全員が契約書の内容を確認する必要はなく、それぞれの契約書に関して指定された人数の確認者が確認すればよい。例えば、ある法人内で４名の確認者が指定されている（つまり、利用者マスタ２０７に４名の確認者が登録されている）とき、ある契約書については２名の確認で構わない場合、その４名のうち任意の２名が確認をすればよい。

図８は、利用者マスタ２０７のデータ構造の一例を説明する図である。利用者マスタ２０７は、利用者ＩＤ８０１、パスワード（ＰＷ）８０２、役職および名称８０３、署名者フラグ８０４、確認者フラグ８０５、不使用フラグ８０６、契約タイプ８０７、店番号７０１、および取引先番号７０２を含むことができるが、これらのデータ項目に限定されることはなく他の任意のデータ項目も含むことが可能である。店番号７０１および取引先番号７０２は、顧客マスタ２０６内のデータ項目と同一であり、これらのデータ項目により、利用者がどの顧客２の利用者であるのかを識別することができる。

利用者ＩＤ８０１は、顧客２における電子契約システム１００の利用者を識別するための識別子であり、ＰＷ８０２は、利用者ＩＤ８０１に対して関連付けられる認証用パスワードである。利用者ＩＤ８０１およびＰＷ８０２は、電子契約システム１００の認証処理にて使用されるが、金融機関１が有する他のシステム（例えば、法人向けインターネットバンキング）のＩＤおよびＰＷと同一にしてもよいし、あるいは異なるようにしてもよい。なお、金融機関１において電子契約システム１００を利用する者のパスワードなどの情報は、金融機関１内で様々なアプリケーションを利用する際に利用されるマスタテーブルに格納されていてもよく、あるいは、利用者マスタ２０７に必要な人の情報が格納されていてもよく、特に限定されることはない。

役職および名称８０３は、顧客２における役職、例えば、代表取締役、部長、経理担当課長などを示し、かつ名称、例えば、会社名や個人名を示す。役職および名称８０３は、所属部門を示してもよい。署名者フラグ８０４は、その者が署名者として指定されているかどうかを示し、署名者として指定されている場合、債務者の署名者であるのか、あるいは保証人の署名者であるのかをさらに示す。確認者フラグ８０５は、その者が確認者として指定されているかどうかを示す。本発明に係る電子契約システム１００では、契約事前確認機能が利用可能である。例えば、契約の内容をチェックする部署や担当者と、契約を締結する部署や担当者が異なるケースで先に確認者の確認を完了したい場合、確認フラグに所定の値が設定されている確認者が契約の内容を確認し、その後、署名者が契約の内容を承認して署名することができる機能が利用可能である。不使用フラグ８０６は、当該利用者ＩＤ８０１が使用されているかどうかを示し、上述のように、既存の利用者の情報に変更がある場合に利用されるフラグである。

契約タイプ８０７は、利用者ＩＤ８０１の契約種類を示し、例えば、法人としての立場と個人としての立場の両方を一つの利用者ＩＤにまとめた「法個両用タイプ」、法人としての立場のみを表す「法人限定タイプ」、個人としての立場のみを示す「個人限定タイプ」、契約内容確認権限者による確認が完了しない限り債務者・保証人が電子署名できない場合に利用される「事前契約確認タイプ」などが存在する。

法個両用タイプの利用者ＩＤ８０１は、契約書の債務者欄に「債務者（法人）」として電子署名を行い、保証人欄に「保証人（個人）」として電子署名を行うことができる。これにより、一の利用者ＩＤ８０１で電子契約システム１００にログインした後、まず、債務者として電子署名をすることができ、その後、ログアウトすることなく、保証人として電子署名することができるようになる。具体的に言えば、法個両用タイプの契約をしている利用者が電子契約システム１００にログインすると、図１１の債務者署名ボタン１１０４および保証人署名ボタン１１０５の両方のボタンがイネーブル（有効）になるので、それぞれの立場で順に電子署名を行うことができる。本発明では、後述するスタンプについても、予め用意されたスタンプを電子文書に付加するのではなく、債務者としてのスタンプ、および保証人としてのスタンプの両方が生成され、電子文書に付加されることが可能である。

法人限定タイプの利用者ＩＤ８０１は、契約書の債務者欄に「債務者（法人）」として電子署名を行い、保証人としての電子署名は行うことができない。個人限定タイプの利用者ＩＤは、例えば、代表取締役の親族が個人として保証人になるケースなどで利用されうるものであり、契約書の保証人欄に「保証人（個人）」として電子署名を行うことができる。これらのタイプの利用者ＩＤ８０１でログインすると、図１１の債務者署名ボタン１１０４および保証人署名ボタン１１０５のうちの対応するボタンがイネーブル（有効）になるので、その立場で電子署名を行うことができる。

事前契約確認タイプの利用者ＩＤ８０１は、確認者であるので電子署名を行うことはできないが、当該ＩＤ８０１を持つ契約内容確認権限者による確認が完了しない限り債務者・保証人は電子署名できないことを望む場合に利用される。事前契約確認タイプの利用者ＩＤ８０１は、例えば、顧客２内の経理部長など所定の権限を持つ者が有することが望ましい。

図２に戻って説明すると、契約書ＤＢ２０８は、契約書に含まれるデータおよび電子文書としての契約書を格納するデータベースである。本発明の他の実施形態では、電子文書を電子契約システム１００内の他の場所に保管しておき、契約書ＤＢ２０８は、当該電子文書の格納場所を示す情報を記憶するようにしてもよい。

図９は、契約書ＤＢ２０８のデータ構造の一例を説明する図である。契約書ＤＢ２０８は、電子契約管理番号９０１、店番号・取引先番号９０２、顧客名９０３、債務者・保証人９０４、契約条件９０５、署名者９０６、確認者９０７、電子文書９０８、破棄フラグ９０９、破棄署名者９１０、ステータス９１１および案件番号９１２を含むことができるが、これらのデータ項目に限定されることはなく他の任意のデータ項目も含むことが可能である。

電子契約管理番号９０１は、契約書（例えば、金銭消費貸借約定書）を識別する識別子であり、電子契約書作成時に電子契約システム１００によって採番される番号である。店番号・取引先番号９０２は、いわゆる、ＣＩＦ番号とも呼ばれるものであり、顧客を識別する識別子である。顧客名９０３は、当該顧客の顧客名称を示す。債務者・保証人９０４は、契約における、１または複数の債務者、および１または複数の保証人を示す。契約書の種類によっては、保証人は連帯保証人であってよいし、保証人が存在しない場合もある。契約条件９０５は、借入金額、資金の使途、最終返済期限、借入利率、弁済方法・利息支払方法などの融資条件を示すが、本明細書で示した項目以外にも契約書の種類・内容に応じて含まれうる他の項目も示すことができる。署名者９０６は、当該契約を締結する１または複数の債務者および保証人であって、契約書に対して電子署名を行う者を含むことができる。署名者９０６において設定される債務者および保証人は、利用者マスタ２０７に登録されている者の中から指定されることが可能である。電子文書９０８に対する電子署名が行われた場合には、署名者９０６の該当する債務者・保証人に署名済みの識別子が付加される。なお、本発明の一実施形態では、署名者９０６は、金融機関１が電子署名を行ったことを示すように構成されてもよい。かかる場合には、署名者９０６は、顧客２の１または複数の債務者および保証人、並びに金融機関１の電子署名を行った者を含むように構成されうる。

確認者９０７は、署名者が契約書の内容を承認・署名する前に契約内容を確認する人数を含むことができ、人数が設定されている場合には契約書の確認を行った１または複数の者を示すこともできる。確認者９０７に人数の情報が格納されている場合、当該契約書は確認者による確認作業が必要な契約書であることが示される。また、確認者９０７が１または複数の確認者を示す場合、顧客２の中で利用者マスタ２０７に確認者として登録されている者（例えば、確認者フラグ８０５に所定の値が設定されている者）のうち、その者が当該契約書の確認作業を行ったことが示される。確認者９０７は、例えば、契約の内容をチェックする部署・担当者と、契約を締結する部署・担当者が違うケースにおいて、確認者による契約内容の確認作業が完了しない限り、署名者の署名が行えないようにする（契約事前確認機能）際に使用するデータ項目である。確認者９０７は、金融機関１によって当該契約書の確認者の人数が指定されない場合には、Ｎｕｌｌ値となる。電子文書９０８に対する確認が行われた場合に、確認者９０７の該当する確認者に、確認作業が完了したことを示す確認済みの識別子が付加される。

電子文書９０８は、電子契約システム１００によって生成される契約書の電子文書（例えば、ＰＤＦファイル）を示す。本発明の他の実施形態では、電子文書９０８には、電子文書の保管場所の情報が格納されており、実際の電子文書は、電子契約システム１００内の記憶媒体内の任意の場所に存在していてよい。

破棄フラグ９０９は、契約書の内容が変更になり、契約書自体を破棄することになった場合に所定の値をセットするためのフラグである。破棄署名者９１０は、契約書を破棄したことに対する電子署名を行う者を示す。破棄の電子署名は、金融機関１および顧客２の双方が行いうるため、破棄署名者９１０は、破棄した者のデータを金融機関１および顧客２の双方に関して有するように構成されてもよい。ステータス９１１は、契約書のデータに対する現在の状態を示し、例えば、担当者が作成中であることを示す「起案中」、担当者の作成が完了し、上役の承認待ちであることを示す「提示待ち」、顧客の署名が済んでいないことを示す「署名待ち」、顧客の署名が行われ、実行処理に渡す前段階であることを示す「事務管理連携待ち」、顧客２に対する貸付が実行されたことを示す「貸付実行済み」などのステータスがある。案件番号９１２は、稟議の起案時に採番され、それぞれの稟議を識別するために使用される番号である。電子契約管理番号９０１および案件番号９１２により、どの稟議に基づく貸付のための契約書なのかを把握できるようになり、その反対に、ある契約書の元になった稟議を突き止めることもできるようになる。

次に、顧客２から依頼を受けて金融機関１が新たな利用者を利用者マスタ２０７に追加する処理を、図３を参照しながら説明する。

図３は、認証局（ＣＡ：certification authority）サーバ１４０による電子証明書および鍵ペア（公開鍵−秘密鍵）作成についての処理フローを説明する図である。

Ｓ３０１にて、電子契約システム１００は、顧客２からの利用者ＩＤ作成申込を受けて利用者ＩＤ８０１を生成し、利用者マスタ２０７に利用者ＩＤ８０１、ＰＷ８０２、役職および名称８０３を格納し、署名者フラグ８０４または確認者フラグ８０５、契約タイプ８０７や店番号７０１・取引先番号７０２も格納する。なお、利用者ＩＤ作成申込は、顧客２の署名者または確認者の本人確認資料とともに金融機関１の法人顧客担当に対して手交で行われても良いし、あるいは顧客端末１２０から電子契約システム１００に対して予め定められたフローに従った申込が行われ、金融機関１の担当者がその作成申込を確認するようにしてもよい。

Ｓ３０２にて、電子契約システム１００は、利用者ＩＤ作成申込を受けた当該利用者の電子証明書および鍵ペア（公開鍵−秘密鍵）の作成依頼を認証局サーバ１４０に送信する。電子証明書（certificate）には、名前や所属などの個人情報、およびその人の公開鍵が記載されており、認証局サーバ１４０による電子署名が行われている。すなわち、電子証明書は、その公開鍵がその署名者のものであることを示すものである。鍵ペア（公開鍵−秘密鍵）は、本発明に係る電子契約システム１００によって実行される電子契約に利用される、公開鍵と秘密鍵のペアである。

電子署名の仕組みについて説明する。電子署名は、印鑑の捺印やサインに相当する機能をコンピュータの世界で実現するための技術である。本発明に係る電子契約システム１００はまず、任意の種類のハッシュ関数を用いて電子文書９０８に基づいてハッシュ値を作成することができる。電子契約システム１００は、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成することができる。その後、電子契約システム１００は、署名者の電子証明書および公開鍵を電子文書９０８にセットすることにより、電子署名を行う。公開鍵は、対応する秘密鍵を持つ利用者が署名を行ったことを検証するために使用することができる鍵であり、電子署名されたデータが公開鍵で復号できれば、その公開鍵のペアである秘密鍵を持つ利用者が署名を行ったことになる。なお、署名者の電子証明書および鍵ペア（公開鍵−秘密鍵）は、ＩＣカードなどに格納されていて、リーダ１２１によって読み出されて、電子契約システム１００において利用されうる。

Ｓ３０３にて、電子契約システム１００は、認証局サーバ１４０によって生成された当該利用者の電子証明書および鍵ペア（公開鍵−秘密鍵）を受信し、電子契約システム１００内に格納することができる。受信した電子証明書および鍵ペア（公開鍵−秘密鍵）は、ＩＣカードなどの記憶媒体に格納されて、金融機関１から顧客２の署名者本人に送付されうる。また、秘密鍵を利用する際の暗証番号（ＰＩＮ）については、金融機関１の法人顧客担当者から顧客２の署名者本人に対して直接手交されてよい。なお、暗証番号（ＰＩＮ）は、電子署名を行う際に必要となるものであり、顧客２の署名者本人により変更可能である。

図４は、金融機関１の法人顧客の担当者による契約書の作成、顧客２の署名者（および必要な場合には、確認者）による契約内容確認および電子署名、並びに金融機関１内での融資事務連携処理についての処理フローを説明する図である。なお、本発明に係る電子契約システム１００では、契約書は、金融機関１の法人顧客の担当者によってのみ作成され、それ以外の者（例えば、顧客２）によって作成されることはない。

Ｓ４０１にて、金融機関１の法人顧客の担当者は、金融機関端末１１０を介して電子契約システム１００にアクセスする。当該アクセスに応答して、電子契約システム１００は、金融機関端末１１０に図５に例示するような契約情報リスト５００を提供することができる。

図５に例示される契約情報リスト５００は、契約書の一覧を表示することができる。契約書は、契約を締結する前段階のもの、および契約締結後のものを含むことができ、検索条件に従って表示される契約書の一覧は変動しうる。契約情報リスト５００は、金融機関１の法人顧客の担当者の所属部門・店により表示される契約情報が制御されうる。

Ｓ４０１にて、金融機関１の法人顧客の担当者は、金融機関端末１１０を介して図５に示される作成ボタンを押下する。作成ボタンが押下されると、電子契約システム１００は、図６に例示されるような契約情報６００の画面を金融機関端末１１０に提供することができる。契約情報６００は、稟議の際に採番された案件番号、契約書の識別番号である電子契約管理番号、担当する営業店、顧客２の口座情報、顧客名称などの基本情報６０１、債務者および保証人情報６０２、契約条件６０３、並びに署名者選択欄６０４、および確認者数指定欄６０５を備えることができる。契約情報６００に含まれるデータ項目は、顧客マスタ２０６、利用者マスタ２０７および契約書ＤＢ２０８に格納されている情報に基づいて設定可能であり、また、契約書の種類・内容に応じて変動しうるものであり、署名者および確認者の数も利用者マスタ２０７に格納されている当該顧客の利用者の範囲内で任意に設定することができる。例えば、署名者選択欄６０４では、債務者または保証人として電子署名する者を利用者マスタ２０７に登録されている者の中から選択可能である。このため、金融機関１は、顧客２の中で債務者、保証人となってもらいたい者を署名者選択欄６０４で指定することができる。また、確認者数指定欄６０５では、金融機関１側で確認者の数を指定することができる。利用者マスタ２０７に顧客２の確認者として登録されている者が指定された数よりも多くいたとしても、その契約書についてはその数の確認者だけが内容を確認すればよい。例えば、顧客２に確認者が４名いたとして、確認者数指定欄６０５で２名指定されている場合には、４名のうちの任意の２名が確認を行えばよい。さらに、本発明の一実施形態では、署名者に対する説明資料を添付することも可能である（例えば、図１０、１１に示した「特定保証についてのご説明（個人向け）」という名前のファイル）。確認者は、署名者が署名する前に契約書の内容を確認する者を設定しておきたい場合に使用されうる。契約情報６００の各データ項目が入力または選択され、登録・作成ボタンが押下されると、電子契約システム１００は、当該入力または選択された契約データに基づいて電子文書９０８を作成し、契約書ＤＢ２０８に各データが登録される。

Ｓ４０２にて、金融機関１の法人顧客の担当者の上役が契約情報リスト５００の画面上で任意の契約データを選択して表示ボタンを押下し、契約情報６００の画面上で契約データおよび電子文書（例えば、契約書のＰＤＦファイル）の内容を確認し、承認ボタン（不図示）を押下するとステータス９１１が「署名待ち」に変更されて、当該契約データおよび電子文書が顧客２に開示されることになる。より詳細に言えば、上役が金融機関端末１１０を使用して電子契約システム１００にアクセスし、電子契約システム１００は、契約情報リスト５００を金融機関端末１１０に提供する。契約情報リスト５００のステータス欄は、契約書のデータに対する現在の状態を示すことができ、例えば、上述したように「起案中」、「提示待ち」、「署名待ち」、「事務管理連携待ち」および「貸付実行済み」などのステータスが存在する。上役は、金融機関端末１１０を使用して契約情報リスト５００に表示されている、ステータスが「提示待ち」である契約書のデータを選択して表示ボタンを押下し、契約情報６００を参照して契約書の内容を確認した上で、承認ボタン（不図示）を押下することができる。承認ボタンが押下されると、当該契約書のデータのステータスが「署名待ち」に変更され、顧客２の署名者や確認者は、顧客端末１２０を使用して電子契約システム１００にアクセスした際に当該契約書のデータおよび電子文書を参照することができるようになる。すなわち、この「署名待ち」のステータスは、顧客２の署名者（例えば、債務者、保証人など）による署名待ちの状態であることを示す。

参照される電子文書の一例を、図１３を参照しながら説明する。図１３は、電子文書に対して電子署名が行われたことを示す４つの種類のスタンプ、すなわち、新規契約の際の金融機関１による電子署名の場合のスタンプ１３０１、新規契約の際の顧客２による電子署名の場合のスタンプ１３０２、既存契約書の破棄の際の金融機関１による電子署名の場合のスタンプ１３０３、および既存契約書の破棄の際の顧客２による電子署名の場合のスタンプ１３０４を示している。

本明細書では、スタンプとは、署名者および電子契約文書の種別を識別する情報であると定義する。署名者は、債務者や保証人などの、電子署名を行う者を示す。電子契約文書の種別は、電子契約手続きの状況（例えば、新規または破棄）を示す。本明細書では、４つの種類のスタンプを例示しているが、一例にすぎない。電子署名が行われたことを示すスタンプは、債務者および保証人のそれぞれに応じて異なる標記であり、契約書の債務者および保証人として指定された者の数に応じて変動しうる。スタンプ１３０１は、Ｓ４０２にて承認ボタンが押下され、当該契約書のデータのステータスが「署名待ち」に変更されたとき、電子文書に対して電子署名が行われたことを明示するスタンプである。スタンプ１３０１は、電子契約管理番号９０１（図１３の例で言えば「＃００００００００４９７５」）を含むことができる。電子署名の詳細については、図３を参照しながら上述した通りである。スタンプ１３０１があることにより、金融機関１以外の者（例えば、顧客２）は、当該契約書が金融機関１によって作成されたものであることを明示的に識別することができる。

ここで、スタンプの生成処理について説明する。本発明におけるスタンプは、電子契約システム１００内に予め用意されたスタンプ（印影）ではなく、電子契約システム１００のログインユーザの属性および電子契約書の契約手続きの状況（例えば、新規、破棄など）に基づいて動的に生成される。このため、上述したように、本発明におけるスタンプは、顧客２内で債務者として指定された者、保証人として指定された者によって異なるように電子契約システム１００によって動的に生成され、また、債務者という立場は同じでも、法人としての立場と個人としての立場でスタンプの標記が異なるように電子契約システム１００によって動的に生成されうる。

より詳細に言えば、電子契約システム１００は、ログインユーザの所属が金融機関１である場合には、電子契約管理番号９０１に格納されている当該契約書の電子契約管理番号を含む、金融機関１用のスタンプ１３０１を生成することができる。例えば、スタンプ１３０１には、「＃００００００００４９７５」という電子契約管理番号が表示されているが、これはスタンプ１３０１が電子契約システム１００によって動的に生成されたものであることを示している。スタンプの形（例えば、丸型、角丸四角形型、楕円型など）自体は、金融機関１用のフォーマットとして予め用意されているものの中から任意のものが選択されてよく、また、金銭消費貸借約定書、特殊当座借越、手形貸付などの契約書の種類に応じて任意のものが選択されてよい。

また、電子契約システム１００は、ログインユーザの所属が顧客２である場合には、利用者マスタ２０７に格納されている役職および名称８０３と署名者フラグ８０４とを読み出し、読み出した役職および名称８０３と署名者フラグ８０４とに基づいて、当該契約書用の顧客２のスタンプを生成することができる。役職および名称８０３は、顧客２における役職、例えば、代表取締役、部長、経理担当課長などを示し、かつ名称、例えば、会社名や個人名を示すデータ項目である。署名者フラグ８０４は、その者が署名者として指定されているかどうかを示し、署名者として指定されている場合、債務者の署名者であるのか、あるいは保証人の署名者であるのかをさらに示すフラグである。電子契約システム１００は、役職および名称８０３と署名者フラグ８０４とに基づいて、スタンプ１３０２などの顧客２用のスタンプを動的に生成することができる。スタンプの形（例えば、丸型、角丸四角形型、楕円型など）自体は、顧客２用のフォーマットとして予め用意されているものの中から任意のものが選択されてよい。

スタンプ１３０２は、顧客２において債務者・保証人が契約内容を確認した後、電子文書に対して電子署名が行われたことを明示するスタンプである。スタンプ１３０２は、電子署名を行った者を識別する情報（図１３の例で言えば「Ｗａｋａｋｕｓａ Ｔａｒｏ」という名前）を含むことができる。スタンプ１３０２があることにより、顧客２以外の者（例えば、金融機関１）は、当該契約書が顧客２によって署名されたものであることを明示的に識別することができる。スタンプ１３０３は、既存の契約書を破棄しなければならない事態が生じた際、まず、金融機関１側で電子文書に対して破棄のための電子署名が行われたことを示すスタンプである。スタンプ１３０３は、破棄することを決めた稟議などの案件番号を含むように生成されてもよく、他の情報を含むように生成されてもよい。スタンプ１３０３があることにより、金融機関１以外の者（例えば、顧客２）は、当該契約書が金融機関１によって破棄されたことを明示的に識別することができる。スタンプ１３０４は、金融機関１が破棄した電子文書に対して顧客２により破棄のための電子署名が行われたことを示すスタンプである。スタンプ１３０４は、破棄の電子署名を行った者を識別する情報（図１３の例で言えば「Ｗａｋａｋｕｓａ Ｔａｒｏ」という名前）を含むことができる。スタンプ１３０４があることにより、顧客２以外の者（例えば、金融機関１）は、当該契約書が顧客２によって破棄されたことを明示的に識別することができる。

図４に戻って説明を続けると、Ｓ４０３にて、顧客２の署名者は、顧客端末１２０を使用して電子契約システム１００にアクセスする。当該アクセスに応答して、電子契約システム１００は、顧客２が署名しなければならない契約データの一覧を表示することができる。表示される契約データは、上述したステータスが「署名待ち」のデータである。表示される契約データの任意の一つが選択されると、電子契約システム１００は、図１０に例示するような契約書詳細１０００を顧客端末１２０に提供することができる。

図１０は、契約書の概要事項、契約書の電子文書、および金融機関１から顧客２に対する連絡事項などを含む契約書詳細１０００を示す図である。契約書詳細１０００は、債務者欄１００１、保証人欄１００２および確認者欄１００３を含むことができる。契約書の概要事項は、主たる契約者（債務者・保証人９０４の債務者のうちの主たる債務者がセットされる）、契約金額（契約条件９０５のうちの契約金額がセットされる）、契約日（契約条件９０５のうちの契約日がセットされる）、電子契約管理番号９０１、契約書ＰＤＦ（電子文書９０８の電子文書）、連絡事項・お知らせ事項（契約条件９０５のうちの連絡事項・お知らせ事項がセットされる）を備えることができる。また、図１３を参照しながら説明したように、電子文書９０８には、当該契約書が金融機関１によって作成されたものであることを明示的に示すためのスタンプ１３０１が表示されている。

債務者欄１００１は、図６の署名者選択６０４において選択された１または複数の債務者を表示することができる。図１０の例では、債務者として３名（株式会社若草商事、若草太郎、若草次郎）が指定されている。債務者欄１００１は、署名者９０６の該当する債務者に署名済みの識別子が付加されているかどうかに基づいて、既に署名を行った者と未だ署名を行っていない者を識別可能なように表示することができる（例えば、色やフォントを変える、表示領域を分ける、など）。債務者欄１００１は、全体として電子署名が済んでいるのか、あるいは未だ済んでいないのかを表示することもできる。

保証人欄１００２は、図６の署名者選択６０４において選択された１または複数の保証人を表示することができる。保証人は、契約書の種類によっては連帯保証人であってもよい。図１０の例では、連帯保証人として２名（若草太郎、若草次郎）が指定されている。保証人欄１００２は、署名者９０６の該当する保証人に署名済みの識別子が付加されているかどうかに基づいて、既に署名を行った者と未だ署名を行っていない者を識別可能なように表示することができる（例えば、色やフォントを変える、表示領域を分ける、など）。保証人欄１００２は、全体として電子署名が済んでいるのか、あるいは未だ済んでいないのかを表示することもできる。

確認者欄１００３は、図６の確認者数指定欄６０５において１または複数の確認者の数が指定された場合に表示されることが可能である。例えば、確認者数指定欄６０５にて「２名」と指定された場合、確認者欄１００３は、当該法人の中で確認者として利用者マスタ２０７に登録されている者を「確認可能者」として表示し、実際に確認した者を確認者の欄に表示することができる。あるいは、実際に確認した者のみを確認者欄１００３に表示するようにしてもよい。本発明に係る電子契約システム１００は、確認者が契約書の内容を確認して確認ボタンを押下した場合にのみ、債務者や保証人が署名者として電子署名を行うことができるように構成されることができる。上述したように、確認者９０７には実際に確認を行った者の情報が格納されているので、電子契約システム１００は、当該情報に基づいて、確認を行った者と行っていない者を識別可能なように表示することができる（例えば、色やフォントを変える、表示領域を分ける、など）。確認を行っていない者は利用者マスタ２０７に格納されている情報から取得することができる。

契約内容の確認後、顧客２の署名者は、顧客端末１２０を使用して図１０に示された契約手続ボタン１００４を押下することができる。また、戻るボタン１００５は、Ｓ４０３にて説明した、契約データの一覧を表示する画面に戻る際に使用されるボタンである。契約手続ボタン１００４が押下されると、電子契約システム１００は、図１１に示したような契約手続開始１１００の画面を顧客端末１２０に提供することができる。

契約手続開始１１００は、債務者欄１１０１、保証人欄１１０２、確認者欄１１０３、債務者署名ボタン１１０４、保証人署名ボタン１１０５、確認ボタン１１０６、および戻るボタン１１０７を備える。図１０で説明したのと同様に、契約手続開始１１００は、契約書の概要事項、契約書の電子文書、および金融機関１から顧客２に対する連絡事項なども備えることができる。

債務者欄１１０１は、債務者の署名が済んでいるかどうかを示すことができる。保証人欄１１０２は、保証人（連帯保証人を含む）の署名が済んでいるかどうかを示すことができる。確認者欄１１０３は、確認者による契約書の確認が済んでいるかどうかを示すことができる。債務者署名ボタン１１０４は、ログインユーザが利用者マスタ２０７において債務者の署名者として指定されている場合にイネーブルになるボタンであり、債務者署名ボタン１１０４が押下されると図１２に示される契約手続１２００の画面が表示される。保証人署名ボタン１１０５は、ログインユーザが利用者マスタ２０７において保証人の署名者として指定されている場合にイネーブルになるボタンであり、保証人署名ボタン１１０５が押下されると図１２に示される契約手続１２００の画面が表示される。確認ボタン１１０６は、ログインユーザが利用者マスタ２０７において確認者として指定されている者である場合にイネーブルになる（あるいは表示される）ボタンであり、確認者が契約内容を承認する場合に押下される。すなわち、確認者は、契約手続開始１１００において電子文書としての契約書（ＰＤＦ）を参照し、内容について問題ないと判断した場合には、確認ボタン１１０６を押下する。戻るボタン１１０７は、Ｓ４０３にて説明した、契約データの一覧を表示する画面に戻る際に使用されるボタンである。

図１２は、契約手続１２００の画面の一例である。契約手続１２００は、チェックボックス１２０１、署名ボタン１２０２および戻るボタン１２０３を備えることができる。チェックボックス１２０１は、署名にあたり債務者および保証人が契約書の内容を理解し、確認したかどうかを債務者および保証人が明示するために使用される。署名ボタン１２０２は、債務者および保証人が電子文書に対して電子署名を行うために使用される。署名ボタン１２０２は、ログインユーザが利用者マスタ２０７に債務者として指定されているか、あるいは保証人として指定されているかに応じて表示内容を変更することができる。戻るボタン１２０３は、契約手続開始１１００の画面に戻るために使用される。

図１０で説明したのと同様に、契約手続１２００は、契約書の概要事項、契約書の電子文書、および金融機関１から顧客２に対する連絡事項なども備えることができる。なお、図１２は、債務者署名ボタン１１０４が押下された場合を示しているので、署名ボタン１２０２には「債務者（法人）として署名」と表記されているが、保証人署名ボタン１１０５が押下された場合には、上述したように署名ボタン１２０２には「保証人として署名」と表記されることになる。すなわち、本発明に係る電子契約システム１００では、利用者マスタ２０７に格納されているログインユーザの情報にしたがって画面制御が行われる。

署名者が契約書の内容を確認した後、チェックボックス１２０１にチェックがつけられ、署名ボタン１２０２が押下されると、図３を参照しながら説明した「電子署名の仕組み」により電子署名の処理が行われる。電子署名を行う際には、暗証番号（ＰＩＮ）の入力が必要である。電子文書に対して電子署名が行われると、図１３を参照しながら上述したように、電子文書に対して債務者による電子署名が行われたことを示すスタンプ１３０２が電子契約システム１００によって電子文書上に表示されるようになる。なお、債務者が複数いる場合には、表示されるスタンプ１３０２は、それぞれの債務者に対応したものとなり、例えば、債務者 若草太郎には若草太郎用に生成されたスタンプ１３０２があり、債務者 若草次郎には若草次郎用に生成されたスタンプ１３０２がある（例えば、債務者の名前を含むスタンプ）。電子文書に対して指定された債務者および保証人の全てによる電子署名が行われた場合（かかる場合、全ての債務者および保証人のスタンプ１３０２が電子文書上に表示される）、顧客２による契約書の確認および署名が完了したことになり、ステータス９１１が「事務管理連携待ち」に変更されることになる。

再び、図４に戻ると、Ｓ４０４にて、金融機関１の法人顧客の担当者は「事務管理連携待ち」ステータスの契約データについて内容を確認し、融資実行実務（例えば、起票、検印、記帳、印字照合など）を担う事務処理部門にデータを渡してもよいと判断したら、図５に示した契約情報リスト５００から該当する契約データを選択し、実行依頼ボタンを押下する。実行依頼ボタンが押下されると、電子契約システム１００は、事務処理部門の担当者が当該契約データを扱えることができるようにステータス９１１を「事務管理連携待ち」から「事務管理連携済み」に更新することができる。また、貸金実行後には、ステータス９１１は「貸付実行済み」に更新される。このように、ステータス９１１は、契約書作成時から貸付実行後までのそれぞれの段階を示すことができる。ステータス９１１を参照することにより、例えば、署名済の電子契約書を元に貸金を実行した後、当該貸金が完済や譲渡若しくは解約となった場合、電子契約管理番号をキーに勘定（期中管理）を司るシステムから完済や譲渡の情報を連携し、そのステータスを顧客が電子契約の画面から確認することが可能となる。

次に、図１４を参照しながら顧客２に確認者が存在する場合の処理フローを説明する。Ｓ１４０１にて、電子契約システム１００は、顧客端末１２０に契約手続開始１１００の画面を提供する。電子契約システム１００は、電子契約管理番号９０１をキーにして契約書ＤＢ２０８に問い合わせを行い、確認者９０７に確認者の人数の情報が格納されているかどうかを判定する。確認者の人数の情報が格納されている場合にはＳ１４０２に処理が進み、一方、確認者の人数の情報が格納されていない場合にはＳ１４０４に処理が進む。

Ｓ１４０２にて、電子契約システム１００は、確認者９０７に確認を行った者の情報が上記した人数分格納されているかどうかを判定する。確認を行った者の情報が上記した人数分格納されている場合にはＳ１４０４に処理が進み、一方、そうでない場合にはＳ１４０３に処理が進む。

Ｓ１４０３にて、電子契約システム１００は、確認ボタン１１０６を表示し、イネーブル（有効）にし、一方、債務者署名ボタン１１０４および保証人署名ボタン１１０５をディセーブル（無効）にする。債務者署名ボタン１１０４および保証人署名ボタン１１０５は、ディセーブルであったとしても契約手続開始１１００の画面上で表示されていてもよい。確認者による確認が終了したら、確認ボタン１１０６が押下され、確認者９０７に確認を行った者の情報が付加される（例えば、「若草経理」という確認者の氏名が付加される）。

Ｓ１４０４にて、電子契約システム１００は、確認者９０７に、指定された人数分の確認者の情報が格納されているという判定に応答して、債務者署名ボタン１１０４および保証人署名ボタン１１０５をイネーブルにする。かかる場合、不要な追加の確認者による確認作業を防止するために、確認者ボタン１１０６は非表示になってもよいし、あるいはディセーブルになってもよい。Ｓ１４０５にて、上述したように、債務者および保証人によって電子文書に対して電子署名が行われる。

次に、図１５を参照しながら、電子署名がなされた契約書を破棄する際の処理フローについて説明する。契約書を破棄する場合とは、例えば、契約書締結後に急遽、代表取締役が変更になった場合、契約書締結後の急激な経済情勢の変化があった場合、などを始めとして、従来も発生していたものである。

Ｓ１５０１にて、電子契約を破棄するための稟議がなされた後、金融機関１内の法人顧客の担当者は、電子契約システム１００に金融機関端末１１０を介してアクセスする。電子契約システム１００は、顧客２との間で締結されている１または複数の契約の一覧（すなわち、図５に示した契約情報リスト５００）を金融機関端末１１０に提供することができる。金融機関１内の法人顧客の担当者は、契約情報リスト５００から破棄の対象となった契約データを選択し、契約破棄ボタンを押下する。契約破棄ボタンが押下されると、電子契約システム１００は、破棄フラグ９０９に破棄を示す値をセットし、破棄署名者９１０に金融機関１をセットする。その後、電子契約システム１００は、電子文書９０８に対して破棄の電子署名を行うことができる。金融機関１による破棄の電子署名が行われたことは、図１３のスタンプ１３０３によって示される。本発明の一実施形態では、破棄フラグ９０９に値をセットするとともに、電子文書９０８に対して破棄の電子署名を行ってスタンプ１３０３を付加することを説明したが、他の実施形態として、金融機関１では破棄フラグ９０９に値をセットするだけで、電子署名を行わない（すなわち、スタンプも付加しない）ようにすることも可能である。

Ｓ１５０２にて、電子契約システム１００は、ステータス９１１を「破棄待ち」に変更することができる。ステータス「破棄待ち」の契約データが顧客２に提示されることになるので、顧客２の債務者は、顧客端末１２０を介して電子契約システム１００にアクセスし、破棄対象の契約データの一覧を確認する。

Ｓ１５０３にて、顧客２の債務者は、顧客端末１２０を介して、破棄対象の契約データの一覧から破棄署名をすべき契約データを選択し、破棄署名ボタンを押下することができる。破棄署名ボタンが押下されたことに応答して、電子契約システム１００は、破棄署名者９１０に顧客２の債務者をセットし、図１３に例示したようなスタンプ１３０４を電子文書９０８上に付けることができる。なお、債務者が複数存在する場合に、それぞれの債務者が破棄署名を行った場合には、それぞれの債務者に対応したスタンプ１３０４が表示されることになる。例えば、スタンプ１３０４は、破棄の電子署名を行った債務者「Ｗａｋａｋｕｓａ Ｔａｒｏ」を示している。

図１６は、本発明に係る電子契約システム１００の機能ブロックを説明する図である。電子契約システム１００は、認証局通信部１６０１、契約データ処理部１６０２、電子署名部１６０３、確認処理部１６０４、画面制御処理部１６０５、スタンプ処理部１６０６、実行処理依頼部１６０７、破棄処理部１６０８、顧客マスタ２０６、利用者マスタ２０７および契約書ＤＢ２０８を備える。

認証局通信部１６０１は、顧客２からの利用者ＩＤ作成申込を受けて利用者ＩＤ８０１を生成し、利用者マスタ２０７に利用者ＩＤ８０１、ＰＷ８０２、役職および名称８０３を格納し、署名者フラグ８０４または確認者フラグ８０５、契約タイプ８０７、店番号７０１、取引先番号７０２も格納することができる。認証局通信部１６０１は、利用者ＩＤ作成申込を受けた当該利用者の電子証明書および鍵ペア（公開鍵−秘密鍵）の作成依頼を認証局サーバ１４０に送信することができる。電子証明書には、名前や所属などの個人情報、およびその人の公開鍵が記載されており、認証局サーバ１４０による電子署名が行われている。鍵ペア（公開鍵−秘密鍵）は、本発明に係る電子契約システム１００によって実行される電子契約に利用される、公開鍵と秘密鍵のペアである。認証局通信部１６０１は、認証局サーバ１４０によって生成された当該利用者の電子証明書および鍵ペア（公開鍵−秘密鍵）を受信し、電子契約システム１００内に格納することができる。

契約データ処理部１６０２は、金融機関端末１１０から入力された契約データ（例えば、契約情報６００の画面上で入力されたデータ）を契約書ＤＢ２０８に格納することができ、契約データに基づいて電子文書９０８を生成して契約書ＤＢ２０８に格納することができ、ステータス９１１を更新することにより、契約データの開示範囲（例えば、金融機関１の法人顧客の担当者の部門（フロント部門ともいう）のみ、顧客２と金融機関１の両方、金融機関１のフロント部門および事務処理部門の両方、など）を制御することができる。このような制御を行うことにより、金融機関１側は、契約データおよび電子文書９０８が生成された段階で、顧客２に対して契約データおよび電子文書９０８を提示することができるようになる。

電子署名部１６０３は、任意の種類のハッシュ関数を用いて電子署名を行う対象の電子文書９０８に基づいてハッシュ値を生成し、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成することができる。電子署名部１６０３は、署名者の電子証明書および公開鍵を電子文書９０８にセットすることにより、電子署名を行うことができる。公開鍵は、対応する秘密鍵を持つ利用者が署名を行ったことを検証するために使用することができる鍵であり、電子署名されたデータが公開鍵で復号できれば、その公開鍵のペアである秘密鍵を持つ利用者が署名を行ったことになる。

電子署名部１６０３は、契約書ＤＢ２０８の破棄フラグ９０９を読み出し、破棄フラグ９０９が所定の値を示す契約データに関連付けられた電子文書９０８に対して破棄の電子署名を行うことができる。破棄の電子署名も、上記したのと同様に実行されうる。

確認処理部１６０４は、顧客２が利用する画面、例えば、契約書詳細１０００および契約手続開始１１００などにおいて当該契約書に対して確認者が存在する場合の画面表示を制御することができる。確認処理部１６０４は、契約書の電子契約管理番号９０１をキーにして契約書ＤＢ２０８に問い合わせを行い、確認者９０７に確認者の人数の情報が格納されているかどうかを判定し、さらに、確認者９０７に確認を行った者の情報が格納されているかどうかを判定することができる。これにより、確認処理部１６０４は、契約データの確認者９０７に確認者の人数の情報が格納されている場合に、図１１に例示されている債務者署名ボタン１１０４および保証人署名ボタン１１０５をディセーブルにすることができる。このディセーブルにする機能は、指定された人数の確認者が契約書の内容を確認した場合にのみ、債務者や保証人が署名者として電子署名を行うことができるようにするためである。確認処理部１６０４は、確認者９０７に、指定された人数分の確認者の情報が格納されているという判定に応答して、債務者署名ボタン１１０４および保証人署名ボタン１１０５をイネーブルにすることができる。確認処理部１６０４は、確認者欄１００３において、確認者９０７に確認を行った者の情報が格納されているかどうかに基づいて、１または複数の確認者が確認を行ったかどうか識別可能なように表示することができる（例えば、色やフォントを変える、表示領域を分ける、など）。また、図１０に例示されている確認者欄１００３、並びに図１１に例示されている確認者欄１１０３および確認ボタン１１０６は、契約データの確認者９０７に確認者がセットされているかどうかに基づいて表示されるかどうかが制御されうる。さらに、確認処理部１６０４は、確認者による確認が完了したことを示す信号を顧客端末１２０から受信したことに応答して、確認者９０７に確認を行った者の情報を格納することができる。

画面制御処理部１６０５は、選択された契約データを契約書ＤＢ２０８から読み出して、図１０に示した契約書詳細１０００、図１１に示した契約手続開始１１００および契約手続１２００の画面表示を制御することができる。画面制御処理部１６０５は、ログインユーザの属性（例えば、債務者、保証人、確認者）を判定し、判定された属性情報に基づいて画面上の表示項目を制御することができる。例えば、ログインユーザが顧客２の債務者であった場合には、債務者署名ボタン１１０４がイネーブルになるように、また、署名ボタン１２０２に「債務者（法人）として署名」との表記がされるように、画面制御処理部１６０５によって制御されうる。例えば、ログインユーザが顧客２の保証人であった場合には、保証人署名ボタン１１０５がイネーブルになるように、また、署名ボタン１２０２に「保証人として署名」との表記がされるように、画面制御処理部１６０５によって制御されうる。

画面制御処理部１６０５は、署名者９０６に指定されている債務者・保証人の情報に基づいて債務者欄１００１および保証人欄１００２の表示を制御することができる。例えば、署名者９０６に複数の債務者が指定されていれば、画面制御処理部１６０５は、指定された複数の債務者を債務者欄１００１に表示し、さらに、署名者９０６の該当する債務者に署名済みの識別子が付加されているかどうかに基づいて、既に署名を行った債務者と未だ署名を行っていない債務者を識別可能なように表示することができる（例えば、色やフォントを変える、表示領域を分ける、など）。画面制御処理部１６０５は、署名者９０６の該当する債務者の全てに署名済みの識別子が付加されているかどうかに基づいて、債務者欄１００１および保証人欄１００２にて、全体として電子署名が済んでいるのか、あるいは未だ済んでいないのかを表示することもできる。

スタンプ処理部１６０６は、金融機関１による電子署名のスタンプ１３０１、１３０３、および顧客２による電子署名のスタンプ１３０２、１３０４を生成し、生成したスタンプを電子文書９０８に付して契約書ＤＢ２０８を更新することができる。より詳細に言えば、スタンプ処理部１６０６は、ログインユーザの所属が金融機関１である場合には、電子契約管理番号９０１に格納されている当該契約書の電子契約管理番号を含む、金融機関１用のスタンプ１３０１を生成することができる。例えば、図１３のスタンプ１３０１には、「＃００００００００４９７５」という電子契約管理番号が表示されているが、これはスタンプ１３０１が電子契約システム１００によって動的に生成されたものであることを示している。スタンプの形（例えば、丸型、角丸四角形型、楕円型など）自体は、金融機関１用のフォーマットとして予め用意されているものの中から任意のものが選択されてよく、また、金銭消費貸借約定書、特殊当座借越、手形貸付などの契約書の種類に応じて任意のものが選択されてよい。

また、スタンプ処理部１６０６は、ログインユーザの所属が顧客２である場合には、利用者マスタ２０７に格納されている役職および名称８０３と署名者フラグ８０４とを読み出し、読み出した役職および名称８０３と署名者フラグ８０４とに基づいて、当該契約書用の顧客２のスタンプを生成することができる。役職および名称８０３は、顧客２における役職、例えば、代表取締役、部長、経理担当課長などを示し、かつ名称、例えば、会社名や個人名を示すデータ項目である。署名者フラグ８０４は、その者が署名者として指定されているかどうかを示し、署名者として指定されている場合、債務者の署名者であるのか、あるいは保証人の署名者であるのかをさらに示すフラグである。スタンプ処理部１６０６は、役職および名称８０３と署名者フラグ８０４とに基づいて、スタンプ１３０２などの顧客２用のスタンプを動的に生成することができる。スタンプの形（例えば、丸型、角丸四角形型、楕円型など）自体は、顧客２用のフォーマットとして予め用意されているものの中から任意のものが選択されてよい。このように、スタンプ処理部１６０６は、利用者マスタ２０７に問い合わせを行って、ログインユーザが署名者であるのかどうか、署名者であるのなら債務者であるのか、あるいは保証人であるのかを判定し、顧客２用のスタンプ１３０２、１３０４を生成することができる。生成されたスタンプ１３０１〜１３０４は、スタンプ処理部１６０６によって電子文書９０８に付されて契約書ＤＢ２０８に格納されることが可能である。

スタンプ処理部１６０６は、契約書ＤＢ２０８から破棄フラグ９０９および破棄署名者９１０を読み出し、破棄フラグ９０９が所定の値（例えば、破棄を示す値「１」）を示す契約データに関連付けられた電子文書９０８を抽出することができる。スタンプ処理部１６０６は、抽出した電子文書９０８に対して破棄の電子署名が行われたことを示すスタンプ１３０３、１３０４を生成して、当該電子文書９０８に付加することができる。スタンプ１３０３は、破棄署名者９１０が金融機関１であることを示す場合に付加され、スタンプ１３０４は、破棄署名者９１０が顧客２の債務者であることを示す場合に付加される。

実行処理依頼部１６０７は、選択された契約データに対する融資実行依頼を金融機関端末１１０から受信したことに応答して、事務処理部門の担当者が当該契約データを扱えることができるようにステータス９１１を「事務管理連携待ち」から「事務管理連携済み」に更新することができる。融資実行依頼は、図５の実行依頼ボタンが押下されたという条件でなされることが可能である。事務処理部門は、融資実行実務（例えば、起票、検印、記帳、印字照合など）を担うことができる。

破棄処理部１６０８は、電子署名がなされた契約書を破棄する処理を行うことができる。より詳細に言えば、破棄処理部１６０８は、金融機関端末１１０との通信に応答して、顧客２との間で締結されている１または複数の契約を金融機関端末１１０に提供することができる。破棄処理部１６０８は、破棄の対象となった契約データが金融機関１によって選択されて契約破棄ボタンが押下されたことを示す信号を受信したことに応答して、破棄フラグ９０９に所定の値（例えば、破棄を示す値「１」）をセットし、破棄署名者９１０に金融機関１をセットすることができる。破棄処理部１６０８は、当該契約データのステータス９１１を「破棄待ち」に変更することにより、当該契約データを顧客２に提示することができる。

破棄処理部１６０８は、顧客端末１２０との通信に応答して、金融機関１によって破棄の電子署名が既に行われている、１または複数の契約データを顧客端末１２０に提供することができる。破棄処理部１６０８は、そのうちの任意の契約データが顧客２によって選択されて契約破棄ボタンが押下されたことを示す信号を受信したことに応答して、破棄署名者９１０に顧客２の債務者をセットすることができる。なお、債務者が複数存在する場合には、破棄処理部１６０８は、破棄署名者９１０に顧客２のそれぞれの債務者を示す情報をセットすることができる。

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成および細部において訂正する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を採用することが可能である。

１ 金融機関
２ 顧客
１００ 電子契約システム
１１０ 金融機関端末
１２０ 顧客端末
１２１ リーダ
１３０、１５０ ネットワーク
１４０ 認証局サーバ
２０１ 制御部
２０２ 主記憶部
２０３ 補助記憶部
２０４ インターフェース（ＩＦ）部
２０５ 出力部
２０６ 顧客マスタ
２０７ 利用者マスタ
２０８ 契約書ＤＢ
５００ 契約情報リスト
６００ 契約情報
１０００ 契約書詳細
１１００ 契約手続開始
１２００ 契約手続
１６０１ 認証局通信部
１６０２ 契約データ処理部
１６０３ 電子署名部
１６０４ 確認処理部
１６０５ 画面制御処理部
１６０６ スタンプ処理部
１６０７ 実行処理依頼部

Claims (9)

1. 金融機関と顧客の間で締結される電子契約文書を取り扱う電子契約システムであって、
   契約データに基づいて電子契約文書を生成し、かつ前記契約データの状態情報に基づいて前記契約データおよび前記電子契約文書を顧客から参照可能にする契約データ処理手段と、
   ログインユーザの属性情報に基づいて、それぞれの属性情報に対応した画面表示制御を行い、かつ前記契約データの情報に基づいて、署名者の情報を表示する画面制御処理手段と、
   任意の種類のハッシュ関数を用いて電子署名を行う対象の前記電子契約文書に基づいてハッシュ値を生成し、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成し、前記署名者の電子証明書および公開鍵を前記電子契約文書にセットすることにより電子署名を行う電子署名手段と、
   前記ログインユーザの前記属性情報および前記電子契約文書の種別に応じて、前記電子署名が行われたことを示すスタンプを動的に生成し、前記電子契約文書に前記スタンプを付加するスタンプ処理手段と
   を備えた電子契約システム。
2. 前記電子契約システムは、
   前記契約データを格納する契約書ＤＢと、
   前記顧客において前記電子契約システムを署名者として利用する者の情報を格納する利用者マスタと
   をさらに備え、
   前記スタンプ処理手段は、
   前記ログインユーザの前記属性情報が前記金融機関であることを示す場合に、前記契約書ＤＢに格納されている前記電子契約文書の識別番号を使用して、前記金融機関用の前記スタンプを生成し、
   前記ログインユーザの前記属性情報が前記顧客であることを示す場合に、前記利用者マスタに格納されている役職および名称の情報、並びに署名者の情報を読み出し、読み出した役職および名称の情報、並びに署名者の情報に基づいて、前記顧客用の前記スタンプを生成する、
   請求項１に記載の電子契約システム。
3. 前記署名者の情報は、債務者および保証人のいずれかを示し、
   前記顧客用の前記スタンプは、前記署名者が前記債務者であるのか、前記保証人であるのかに応じて異なるように動的に生成される、
   請求項２に記載の電子契約システム。
4. 前記契約データを格納する契約書ＤＢと、
   前記顧客において前記電子契約システムを確認者として利用する者の情報を格納する利用者マスタと、
   前記電子契約文書の識別番号をキーにして前記契約書ＤＢに問い合わせを行うことにより、前記電子契約文書について確認者による確認作業が必要なものかどうかを判定し、さらに、前記電子契約文書について予め定められた数の確認者が確認したかどうかを判定する確認処理手段と
   をさらに備える、請求項１に記載の電子契約システム。
5. 前記確認処理手段は、
   前記電子契約文書について確認者による確認作業が必要なものであるとの判定に応答して、前記顧客において債務者および保証人として指定されている者が前記電子契約文書に対して電子署名を行うことができないように制御し、
   前記電子契約文書について予め定められた数の確認者が確認したとの判定に応答して、前記顧客において債務者および保証人として指定されている者が前記電子契約文書に対して電子署名を行うことができるように制御する、
   ようにさらに構成される、請求項４に記載の電子契約システム。
6. 前記顧客において前記電子契約システムを署名者および確認者のいずれかとして利用する者の情報を格納する利用者マスタと、
   前記顧客からの利用者マスタ作成依頼に応答して利用者情報を生成して前記利用者マスタに格納し、前記利用者マスタ作成依頼を受けた利用者の電子証明書および鍵ペアの作成依頼を認証局サーバに送信し、前記認証局サーバによって生成された前記利用者の前記電子証明書および前記鍵ペアを受信する認証局通信手段であって、受信した前記電子証明書は、前記署名者の電子証明書であり、受信した前記鍵ペアは、前記署名者の前記秘密鍵および前記公開鍵である、認証局通信手段と
   をさらに備える、請求項１に記載の電子契約システム。
7. 前記契約データに対する融資実行依頼を受信したことに応答して、前記金融機関内において融資実行実務を担う事務処理部門が前記契約データを扱えることができるように、前記契約データの前記状態情報を更新する実行処理依頼手段をさらに備える、請求項１に記載の電子契約システム。
8. 金融機関と顧客の間で締結される電子契約文書を取り扱う電子契約システムによって実行される方法であって、
   契約データに基づいて電子契約文書を生成し、かつ前記契約データの状態情報に基づいて前記契約データおよび前記電子契約文書を顧客から参照可能にすることと、
   ログインユーザの属性情報に基づいて、それぞれの属性情報に対応した画面表示制御を行い、かつ前記契約データの情報に基づいて、署名者の情報を表示することと、
   任意の種類のハッシュ関数を用いて電子署名を行う対象の前記電子契約文書に基づいてハッシュ値を生成し、署名者の秘密鍵を用いてハッシュ値をさらに暗号化して暗号化データを生成し、前記署名者の電子証明書および公開鍵を前記電子契約文書にセットすることにより電子署名を行うことと、
   前記ログインユーザの前記属性情報および前記電子契約文書の種別に応じて、前記電子署名が行われたことを示すスタンプを動的に生成し、前記電子契約文書に前記スタンプを付加することと
   を備える方法。
9. 請求項８に記載の方法をコンピュータに実行させるためのプログラム。