JP2007060336A - 電子割印システム - Google Patents

Abstract

【課題】 電子契約行為において、契約書に添付される資料が大容量である場合、公証システムの文書保管庫へ、契約書本体と各添付資料のハッシュ値とを紐付けて保管することにより、契約書類一式の原本性を証明するシステムを提供する。
【解決手段】 電子文書に付された電子署名が認証された場合、タイムスタンプを付与して保管する公証サービス１００を利用する電子割印システムであって、ユーザ端末１の記憶部２には、契約書類１式を構成する契約書本体と、１以上の添付書類とを分離した上で記憶し、処理部３は、添付書類毎に計算したハッシュ値に電子署名を付加した添付書類別ＸＭＬファイルを作成し、これらのＸＭＬファイルと契約書本体とを一括してエンコードした文書に電子署名を付加したＸＭＬ化契約書類ファイルを作成し、このＸＭＬ化契約書類ファイルを公証サービスのサーバに送信する。
【選択図】 図１

Description

電子契約行為において、契約書に添付される資料が大容量である場合、電子公証システム提供者側の文書保管庫へ、契約書本体と添付資料のハッシュ値とを紐付けて保管することにより、添付資料を含む契約書類の原本性を証明する電子割印システムに関する。

電子文書の公証および保管サービスの提供がビジネスとして行われるようになってきた。本出願人もこのようなビジネスに提供するための公証システムを、特願２００４−１５９２９２において提案している。以下に、この特願２００４−１５９２９２に記載の発明について概要を説明する。

図３は、特願２００４−１５９２９２に記載の公証システムのシステム構成例を示す図である。エンドユーザ側端末１０１は、公証システム１００のフロント機能１０２から、文書証明・タイムスタンプ機能１０３、証明書・署名検証機能１０４、電子文書長期保管機能１０５を利用する。
フロント機能１０２は、ユーザ側端末１０１からの指令により、文書証明・タイムスタンプ機能１０３、証明書・署名検証機能１０４、電子文書長期保管機能１０５のそれぞれを用いて、電子的な公証のための一連の処理を行う。つまり、フロント機能１０２は、公証システム１００を統合して機能させるものである。

次に、フロント機能１０２が統括する各機能について説明する。
まず、文書証明・タイムスタンプ機能１０３は、電子公証機能を提供する。この電子公証機能は、電子公証証明の発行、およびそれを長期間にわたり検証可能にするためのセキュアな保管という手段によって、電子データあるいは電子文書の長期にわたる存在証明を行うものである。
また、文書証明・タイムスタンプ機能１０３は、タイムスタンプを利用した時刻付与機能による公証も行う。ここで、タイムスタンプを利用した公証とは、電子データあるいは電子文書が、ある特定日時以前に存在していたこと、及び当該特定日時以降改ざんされていないことを証明するものである。なお、このタイムスタンプは、システム１００の外部にある時刻配信サーバ１０６から配信される正確な日時を用いて行われる。

次に、証明書・署名検証機能１０４について説明する。この機能１０４によって、電子証明書および電子署名付文書の有効性が検証される。このシステム１００の外部又は内部には、電子証明書や電子署名の検証を行う認証局のサーバ１０７が存在するが、証明書・署名検証機能１０４は、この認証局サーバ１０７と協調して、検証機能を実行する。

次に、電子文書長期保管機能１０５について説明する。この機能１０５は、電子文書の原本性確保を実現するために、電子文書を、安全に長期間保存するものである。原本性確保のために、原本へのすべてのアクセスをログに記録し、そのログによって改ざんされていないことを証明する。また、電子文書の所有者であっても、設定した期間内に文書の削除を不可能としている。

以上の各機能からなる公証システム１００は、次のような動作をする。
まず、図４に従い、このシステム１００の基本動作を説明する。
ユーザ端末１０１は、システム１００に対し、電子証明書を用いたログインを行う（Ｓ２０１）。この電子証明書を用いたログインでは、通常のＩＤとパスワードなどを用いてログインを行ったとき、ユーザ端末１０１は、例えば、送られてくる画面の指示に従って電子証明書をアップロードする。システム１００は、この電子証明書を用いて、証明書・署名検証機能１０４において、この電子証明書を発行した認証局１０７を利用して、誰がログインを行ったかを厳密に検証する（Ｓ２０２）。

次に、電子証明書を認証することで、ログインを許可される（Ｓ２０３）と、ユーザ端末１０１は、例えば、表示される画面上のメニュー等の選択などにより、電子文書の保管指示を行う（Ｓ２０４）とともに、目的の電子署名付電子文書をアップロードする（Ｓ２０５）。
公証システム１００では、証明書・署名検証機能１０４が、電子文書に付された電子署名の検証を行い（Ｓ２０６）、検証完了後、認証した場合には、文書証明・タイムスタンプ機能１０３が、タイムスタンプをつけ文書の存在証明を行い（Ｓ２０７）、タイムスタンプ付文書を電子文書長期保管機能１０５が保管する（Ｓ２０８）。ユーザ側端末１０１には、電子署名付電子文書の公証証明が送られる（Ｓ２０９）。

続いて、図５に従い、ユーザＡとユーザＢの２者間で電子署名を用いた契約を取り交わす処理の一例を説明する。
ユーザＡの端末（「ユーザ端末Ａ」という）は、電子証明書を利用したログインに成功するとシステム１００に対し、契約書の取り交わしであることを、メニュー選択等で指示する（Ｓ３０１）。システム１００からの送信画面による指示等により（Ｓ３０２）、契約の相手側であるユーザＢの情報と、契約書であるユーザＡの電子署名付電子文書をシステム１００に送る（Ｓ３０３）。システム１００では、証明書・署名検証機能１０４により電子署名を認証局１０７にアクセスすることで検証する。（Ｓ３０４）

次に、システム１００から、ユーザＢに対し、ユーザＡとユーザＢとの間での契約文書がある旨をメール等で通知する（Ｓ３０６）。
ユーザＢの端末（「ユーザ端末Ｂ」という）は、システム１００に電子証明書を利用したログインを行い（Ｓ３０７）、ユーザBの電子証明書が検証され、その結果認証されると（Ｓ３０８、Ｓ３０９）、ユーザ端末Ａからシステム１００に送られた電子文書（契約書）をユーザ端末Ｂに送る（Ｓ３１０）。これは、電子メールに暗号化した電子文書を添付して送ってもよいし、ユーザＢがシステム１００から電子文書をダウンロードしても良い。この電子文書にはユーザＡの電子署名が付されている。

ユーザ端末Ｂは、送られてきたユーザＡの電子署名付電子文書に対して、自分（ユーザＢ）の電子署名を追加して（Ｓ３１１）、システム１００に送信する（Ｓ３１２）。システム１００は、追加されたユーザＢによる電子署名を検証し（Ｓ３１３）、認証すると、文書証明・タイムスタンプ機能１０３によって、タイムスタンプによる公証を行う（Ｓ３１４）。このタイムスタンプが付されたユーザＡとユーザＢによる電子署名付きの電子文書は、電子文書長期保管機能１０５によって保管される（Ｓ３１５）。
ユーザ端末Ａとユーザ端末Ｂには、ユーザＡとユーザＢの電子署名付電子文書の公証証明が送信される（Ｓ３１６、Ｓ３１７）。このユーザＡとユーザＢの両者に送られた公証証明は、両者の署名した契約文書に対する公証である。
このように、システム１００においては、保管時に必ず電子署名等を検証した後、タイムスタンプによる公証で、その時点の存在証明ができるようにして保管している。これは、公証役場において、私文書である契約書を公正証書として保管することに相当する。

システム１００を利用するユーザ端末１０１は、電子文書を図６に示すように処理をする。図７には、図６の処理によって作成される電子署名付ＸＭＬ文書５００を示す。
ユーザ側端末１０１は、ワープロソフト等で作成し蓄積しておいた電子文書をエンコード、すなわち、電子文書を一定の規則に基づいて符号化する（Ｓ４０１）。エンコードされた電子文書５０１を、１つのブロックとしてタグ５０２で囲み、タグ５０３で囲まれた基本情報を付与してＸＭＬ変換を行う（Ｓ４０２）。なお、基本情報とは、直接契約書とは関係なく、本システム用に付与される情報で、例えば、文書作成に用いたアプリケーションソフト、文書名、作成者、文書の種類、作成日等がある。
次に、ＸＭＬ変換後の文書に電子署名を行い（Ｓ４０３）、電子署名付のＸＭＬ文書を作成する。
ステップＳ４０３において、電子署名を行う対象は暗号化された１つのブロックである本文５０１であるので、ＸＭＬ文書に対する署名５０４は、各署名部分５０５が１つのブロックである原本部分５０１に直接触れることのないように独立している。そのため、追加して署名したとしても原本の改ざんとはならない。

特開２００２−２３２４８７号公報

以上の本出願人の発明のように、信頼しうる電子公証のための基盤が整えられつつある。しかし、このようなシステムを備えたサービスの利用に際し、問題がある。それは、公証サービスを提供する事業者が保存する電子ファイルの容量には制限があるということである。
ところが、例えば、社会基盤である高速道路や鉄道、ダムなどの大規模工事に関する契約書には、通常、数多くの設計図書や構造計算書、資材目録等が添付されている。これらの添付書類も含めた契約書類１式は、製本されるとすると数百ページ以上にもなり、これらを電子化するとなると、そのファイルサイズは数ＧＢから数十ＧＢ以上に及ぶことも珍しくない。
もし、このような大規模ファイルからなる契約書を、インターネット等のネットワークを介して、公証サービス事業者のサーバへ送信し、公証サービスの提供を受けようとすると、通信回線や事業者のサーバへの負荷が多大なものとなって、サービスが受けられないことも考えられる。

本発明は、このような問題点に鑑み、特願２００４−１５９２９２に記載の電子公証システムを利用することを前提としつつ、大規模サイズの添付書類を含む契約書類一式の原本性の保証を可能とする仕組みを提供することを目的とする。

一方、特開２００２−２３２４８７号公報に記載の発明は、メールの添付ファイルの内容を証明するファイル証明書を作成し、ファイル証明書に署名をすることにより添付ファイルとファイル証明書との関係及び内容を保証するものである。メール送受信に関するものなので、技術分野が異なるとはいえ、添付ファイルの内容を証明しようとする着眼において、本発明との類似性がある。
しかし、特開２００２−２３２４８７号記載の発明は、メール本文（本発明では契約書本体に相当する）に複数、かつ大規模サイズのファイル（本発明では複数の添付資料）が添付された場合の問題点を解決しようとするものではない。

本発明は、このような目的を実現するために、認証局と協調して、電子文書に付された電子証明書や電子署名の検証を行い、認証された場合には、外部から供給される正確な時刻情報により電子文書にタイムスタンプを付与した上で、この電子文書を保管する公証サービスを利用する電子割印システムであって、電子契約の当事者であるユーザの端末と前記公証サービスのサーバとが、通信回線を介して接続し、前記ユーザの端末は、記憶部と処理部と電子書類保管部を備え、該記憶部には、契約書類１式を構成する契約書本体と、これに付随する１以上の添付書類とを分離した上で電子化して記憶し、前記処理部は、前記添付書類を前記記憶部から読み出し、添付書類毎にハッシュ値を生成し、電子署名を付加した署名済み添付書類ファイルを作成する。なお、容量によってはハッシュ値ではなく、添付書類自体に電子署名を付加した署名済み添付書類ファイルを作成してもよいし、ＸＭＬ形式の署名済み添付書類ファイルとしてもよい。この場合、添付書類の書類名や作成者などの基本情報タグを付加しても良い。また、最終的には契約書本体とを一括してエンコード後に電子署名を付与するため、ハッシュ値、あるいは添付書類自体への電子署名の付与は必須としなくてもよい。これら署名済み添付書類ファイルと、前記記憶部から読み出した契約書本体とを一括してエンコードし、このエンコードされた電子文書に電子署名を付加したＸＭＬ化契約書類ファイルを作成し、該ＸＭＬ化契約書類ファイルを前記公証サービスのサーバに送信し、該サーバから該ＸＭＬ化契約書類ファイルの公証証明を受信すると、前記電子書類保管部に、前記契約書本体並びに前記１以上の添付書類と、前記ＸＭＬ化契約書類ファイルと前記公証証明とを保管することを特徴とする。ただし、公証サービスのサーバから常に前記公証証明を受信することをできるようにすれば、前記電子書類保管部へ前記公証証明を保管する必要はなくなる。契約書本体と添付書類の紐付けは、契約書本体中にインデックスとして、添付書類の識別名（ファイル名、又は、添付書類を識別するためのコードなど）と添付書類のハッシュ値を埋め込む方法でも良い。また、インデックスを契約書本体中に埋め込むのではなく、契約書とは別ファイル（インデックスファイル）として生成し、契約書本体、インデックスファイル、および、各添付書類（署名済み添付書類ファイル）を一括してエンコードし、このエンコードされた電子文書に電子署名を付加したＸＭＬ化契約書類ファイルとしても良い。
ＸＭＬ化契約書類ファイルを生成するための、ファイル選択方法については、ファイルを個別に選択する方法でも良いし、フォルダ（または、ディレクトリ）単位で選択できる方法でも良い。
添付書類をハッシュ化するかどうかの選択については、全ての添付ファイルを無条件でハッシュ化してもよいし、添付ファイルサイズへ閾値を設け自動的に判定させてもよい。また、添付ファイル毎にハッシュ化するかどうかを選択してもよい。

また、本発明は、前記電子書類保管部を、書き換え不可能な記憶媒体（例えばCD-R、DVD-Rなどのライトワンスメディアタイプの記憶媒体）で実現してもよい。
「書き換え不可能な記憶媒体」とは、いったん書き込むと書き換えを不可能とする記憶媒体で、下記の実施形態のＤＶＤ−Ｒは、その一例である。
さらに、この記憶媒体に格納した内容をセキュアなデータベースに格納するようにしてもよい。

上述の電子割印システムの機能をコンピュータシステムに実現させるためのコンピュータプログラムも本発明である。

請求項１に記載の発明によれば、１つのＸＭＬ化契約書類ファイルに電子契約書本体と、付随する添付書類のハッシュ値とが格納されている。また、契約当事者の電子署名が付与されている。このＸＭＬ化契約書類ファイルが公証サービス事業者側で認証され、タイムスタンプを利用して公証を受けて保管される。そのため、契約書本体と添付書類のハッシュ値が紐付けされていることになる。このことは、紙の契約書と紙の添付書類とが同一契約に関する一連の書類であることを示す割印を押したことに相当する。したがって、契約書と１以上の添付書類、つまり、契約書類一式の原本性が担保される。

請求項２に記載の発明によれば、書き換え不可能な記憶媒体に公証証明、ＸＭＬ契約書類ファイル、並びに、契約書類一式を格納することによって、改ざんされたり、消去されたりすることを防止できる。また、同時に契約の相手方の分も格納媒体を作成し、相手方に渡すならば、通常の紙の契約書を取り交わすことに相当する。また、後述する方法により、契約相手側でも原本性の担保された格納媒体を作成できる。これも、通常の紙の契約書を取り交わすことに相当する。
請求項３に記載の発明によれば、契約書類一式データに迅速にアクセスできるので、検索性が向上し、担当者間のデータ共有、整合性のとれたデータ管理に適し、データの有効利用も図れる。

図１は、本発明の実施形態のシステム構成例を示した図である。
ユーザ端末１は、インターネットＮを介して、電子公証システム１００と接続している。
電子公証システム１００は、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ（公開鍵基盤））に基づいたシステムであり、ユーザ端末１は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）機能を使うプロトコルで、この電子公証システム１００との間の通信を行う。
電子公証システム１００は、本出願人による特願２００４−１５９２９２に記載された発明の実施例であり、詳細は、図３に示したとおりである。

本実施形態では、契約当事者はＡ会社とＢ会社の２社であるものとし、図１のユーザ端末１Ａとユーザ端末１Ｂは、それぞれＡ会社とＢ会社の端末とする。なお、図１には２社の端末しか記載していないが、これに限るものではない。
ユーザ端末１は、記憶部２、処理部３、電子書類保管部４、インターネット等との通信インタフェース（図示せず）を備える。他に図示しないキーボードやマウス等の入力部、ディスプレイやプリンタ等の出力部も適宜備える。
電子書類保管部４として、本実施形態では、ユーザ端末１に外付け可能な記憶媒体であって、書き換え不可能な記憶媒体であるＤＶＤ−Ｒを用いる。
また、ユーザ側端末１は、データベースサーバ５（以下「ＤＢサーバ５」）と接続している。なお、ＤＢサーバ５は、ユーザ端末１と同一のコンピュータで構成されていてもよいし、ユーザ側端末１のＤＢサーバとユーザ側端末２のＤＢサーバが同一筐体であってもよい。

記憶部２は、作成途中あるいは完成した契約書類などを格納したり、本実施形態の電子割印システムにおけるユーザ端末１側の処理を記述したコンピュータプログラムや、各種パラメータを格納したりするものである。
処理部３は、本実施形態の電子割印システムにおけるユーザ端末１側の処理を行う。この処理部３の機能は、記憶部２に格納等したコンピュータプログラムを読み込み、メモリ上に展開し、これを図示しないＣＰＵによって実行する等の方法で実現される。

本実施形態では、Ａ社とＢ社とが、ある案件について契約を締結し、Ａ社側で契約書類一式を作成する場面を想定する。また、添付書類については、ＸＭＬ形式の署名済み添付書類ファイルを用いたＸＭＬ化契約書類ファイルを使用した場面を想定する。
図２に示すように、ユーザ端末１Aの記憶部２には、契約書類一式を構成する契約書本体６ａと、これに付随する添付書類６ｂ１、６ｂ２、６ｂ３が含まれるものとする。なお、この例では、添付書類は３種類だけであるが、特に制限を設けない。 これらの書類６ａ，６ｂ１、６ｂ２及び６ｂ３はいずれも、電子化されている。そして、各添付ファイルのファイルサイズは、１０ＧＢ，３ＫＢ、９００ＭＢとする。
また、添付ファイルは、そのサイズに応じて、ハッシュ化されるか否かを決め、その閾値を１ＭＢとした場合とする。。この閾値は、記憶部２にパラメータの一種として記憶させておくとよい。

公証システム１００を利用しようとする場合、従来であれば、ユーザ端末１Ａは，これらの４つの書類６ａ，６ｂ１、６ｂ２及び６ｂ３を一つの電子文書にまとめ、エンコードしたものを図７のタグ５０２で囲み、基本情報と電子署名とを付加してＸＭＬファイル化し、このＸＭＬファイルを公証システム１００宛に送信することになる。４つの書類のサイズが、いずれも大規模でなければ、これでよい。

しかし、ここで想定するように、添付書類にきわめてサイズの大きいものを含む場合は、これらを、一つのファイルにまとめてエンコードし、１個のＸＭＬファイルに変換した場合、このＸＭＬファイルのサイズは非常に大きなものとなる。これを、通信回線等を介して送信することは、回線や公証システム１００側のサーバの負荷を考えると現実的ではない。
かといって、大規模サイズの添付書類を除外するわけにはいかない。
また、契約書本体とは別に、１個の添付書類のみを、単独で１回、あるいは数回に分けて送信し、公証を受けるわけにもいかない。契約書類一式を構成する契約書本体と付随する添付書類とを、一括して同時に公証を受けなければ意味がないからである。

そのため、ユーザ端末１Ａの処理部３は、本発明の電子割印という考え方に基づき、公証システム１００に送信するＸＭＬ化契約書類ファイルを作成することとした。
以下、図２を参照しながら、処理部３を中心とした処理の流れを説明する。
なお、ユーザであるＡ社、B社は、認証局１０７から、既に電子証明書を取得していることを前提とする。

処理部３は、記憶部２から、まず添付書類６ｂ１を取り出す。この添付文書６ｂ１は、ファイルサイズが１０ＧＢであって、予め定めた閾値１ＭＢよりも大きいので、所定のハッシュ関数によってハッシュ値を求める。このハッシュ値と、この添付文書の書類名や作成者などの基本情報と、Ａ社の電子署名とを、それぞれタグで挟み、ＸＭＬファイル化し、添付書類別ＸＭＬファイル７ｂ１を作成する。
続いて、添付書類６ｂ２を取り出す。この添付文書６ｂ２は、ファイルサイズが３ＫＢであって、予め定めた閾値１ＭＢよりも小さいので、ファイル６ｂ２の内容そのものと、この添付文書の基本情報と、Ａ社の電子署名とを、それぞれタグで挟み、ＸＭＬファイル化し、添付書類別ＸＭＬファイル７ｂ２を作成する。
次に、添付書類６ｂ３を取り出す。この添付文書６ｂ３は、ファイルサイズが９００ＭＢであって、予め定めた閾値１ＭＢよりも大きいので、所定のハッシュ関数によってハッシュ値を求める。このハッシュ値と、この添付文書の書類名や作成者などの基本情報と、Ａ社の電子署名とを、それぞれタグで挟み、ＸＭＬファイル化し、添付書類別ＸＭＬファイル７ｂ３を作成する。

このようにして、処理部３は、記憶部２に存在する添付文書のＸＭＬ化を終える（Ｓ１）と、記憶部２から契約書本体６ａを取り出し、この契約書本体６ａのコピー７ａと、添付書類毎の添付書類別ＸＭＬファイル７ｂ１、７ｂ２および７ｂ３とを一括して一個の電子文書とし、この電子文書を所定の方式でエンコードする。このエンコードされた電子文書８にＸＭＬのタグを挟んだものに、基本情報９と、Ａ社の電子署名が付された電子署名欄１０とを、それぞれタグで挟んだものを付加してＸＭＬ化契約書類ファイル１１を作成する。これを公証システム１００に送信する（Ｓ２）。

このＸＭＬ化契約書類ファイル１１には、契約書本体と全添付ファイルのハッシュ値（ファイルサイズが小さいときは、添付ファイルの内容自体）とが格納されている。つまり、１個のＸＭＬ化契約書類ファイル１１において、契約書本体と添付書類とがリンクされていることになる。なお、この契約書本体と添付書類とのリンクは、紙の契約書類の場合の割印をイメージさせるものである。これが、本発明のシステムを、電子割印システムと名づけた所以である。
このように、契約書本体と添付書類のハッシュ値（あるいは、添付ファイル自体）とが、同時に電子公証の対象となり、契約書類一式の原本性が担保される。
添付ファイルのサイズがいかに大きくても、添付ファイル毎の添付書類別ＸＭＬファイル７ｂにはハッシュ値が格納されるので、添付ファイル毎の添付書類別ＸＭＬファイル７ｂのサイズは小さなものであり、添付ファイルの個数がいかに多くても、すべての添付ファイルの添付書類別ＸＭＬファイル７ｂを一括してできるＸＭＬ化契約書類ファイル１１も、公証システム１００への送信を困難にするような大規模なサイズとはならない。したがって、添付書類の数がいかに多くても、添付書類のサイズがいかに大きくても、ＸＭＬ化契約書類ファイル１１を送信し、電子公証を受けることが可能である。
Ａ社は生成したＸＭＬ化契約書類ファイル１１を公証システム１００に送る。公証システム１００では、証明書・署名検証機能１０４によりＡ社の電子署名を認証局１０７にアクセスすることで検証する。

ここで、公証システム１００から、契約の相手方Ｂ社に対し、メール等で通知が行き、ＸＭＬ化契約書類ファイル１１の電子署名欄１０にＢ社の電子署名を追加して、公証システム１００に送信される。公証システム１００では、証明書・署名検証機能１０４によりＢ社、並びに、Ａ社の電子署名を認証局１０７にアクセスすることで検証する。認証されると、文書証明・タイムスタンプ機能１０３によって、タイムスタンプによる公証が行なわれる。このタイムスタンプが付されたＸＭＬ化契約書類ファイルは電子文書長期保管機能１０５によって保管される。また、ユーザ端末１Aとユーザ端末１ＢへはＸＭＬ化契約書類ファイルの公証証明が送られる。このように、契約当事者すべての署名が入った公証が作成されたことになる。また、Ａ社とＢ社は、公証システム１００から契約当事者の電子署名が付与されたＸＭＬ化契約書類ファイルを入手できる。
なお、Ｂ社と公証システム１００との間の処理は、図５に示す場合と同様なので、詳細な説明は省略する。

通常、契約の当事者同士は、契約書面に、それぞれ自己の署名捺印をして、これを公正証書とするが、公証システム１００からユーザ端末１Ａとユーザ端末１ＢにＸＭＬ化契約書類ファイルの公証証明１２が送信されてくるということは、Ａ社とＢ社が、公証役場で作成された公正証書を入手したことと同様の意義を持つ。

Ａ社のユーザ端末１Ａ、あるいは、Ｂ社のユーザ端末１Ｂは、記憶部２から読み出した契約書本体６ａと、添付書類６ｂ１，６ｂ２，６ｂ３、及び契約当事者の電子署名が付与されたＸＭＬ化契約書類ファイル１１とともに（Ｓ４，Ｓ５）、公証証明１２を一括して１枚のＤＶＤ−Ｒ４に格納する（Ｓ３）。ＤＶＤ−Ｒ４は、いったん書き込んだ後は、書き換えができないので、データの改ざんや、故意又は過失によるデータの消去を防止できる。したがって、契約書類のような重要な文書ファイルの保存に適している。
Ａ社のユーザ端末１Ａ、あるいは、Ｂ社のユーザ端末１Ｂは、同一内容を格納したＤＶＤ−Ｒ４をもう１枚作成し、これを契約相手先に渡すとよい。これは、同一の紙の契約書類一式を契約の相手方に渡すことに相当する。契約相手先は、必要とあれば、ＸＭＬ化契約書類ファイル１１内のエンコードされた電子文書８をデコードし、添付書類別ＸＭＬファイル７ｂのハッシュ値を取り出し、このハッシュ値によって、同一内容であることを確認することもできるし、ＤＶＤ−Ｒ４に格納されたＸＭＬ化契約書類ファイル１１と公証証明１２を公証システム１００に送信し、原本性を問い合わせることも可能である。また、契約当事者の電子署名が付与されたＸＭＬ化契約書ファイル１１と公証証明１２を公証システム１００から入手すれば、前記の同一内容であることの確認、並びに、公証システム１００を利用しての原本性の問い合せをすることにより、契約相手先でもＤＶＤ−Ｒ４を作成できることになる。

ユーザ端末１は、自己と接続するＤＢサーバ５に、ＤＶＤ−Ｒ４に格納されているものと同一内容を記憶させておくと、検索の際に便利である。また、ＤＢサーバから前記の同一内容であることの確認、並びに、公証システムを利用しての原本性の問い合わせをすることもできる。

前記の実施形態では、ユーザはＡ社とＢ社のみであったが、契約の締結は３者間以上で行われることも多い。その場合は、それぞれの当事者のユーザ端末１が、インターネットＮ等を介して、本発明のシステムを利用すればよく、ＸＭＬ化契約書類ファイル１１の電子署名欄１０には、各社の電子署名が付加される。

なお、前記のように開示された実施の形態はすべての点で例示であって、制限的なものではない。したがって、種々の変形が可能である。しかし、その変形が特許請求の範囲に記載された技術思想に基づくものである限り、その変形は本発明の技術的範囲に含まれる。

請求項１に記載の発明によれば、１つのＸＭＬ化契約書類ファイルに電子契約書本体と、付随する添付書類のハッシュ値とが格納され、このＸＭＬ化契約書類ファイルが公証サービス事業者側で認証され、タイムスタンプを利用して公証を受けて保管される。そのため、契約書本体と添付書類のハッシュ値が紐付けされていることになる。このことは、紙の契約書と紙の添付書類とが同一契約に関する一連の書類であることを示す割印を押したことに相当する。したがって、契約書と１以上の添付書類、つまり、契約書類一式の原本性が担保される。

請求項２に記載の発明によれば、書き換え不可能な記憶媒体に公証証明を含む契約書類一式を格納することによって、改ざんされたり、消去されたりすることを防止できる。また、同時に契約の相手方の分も格納媒体を作成し、相手方に渡すならば、通常の紙の契約書を取り交わすことに相当する。
請求項３に記載の発明によれば、契約書類一式データに迅速にアクセスできるので、検索性が向上し、担当者間のデータ共有、整合性のとれたデータ管理に適し、データの有効利用も図れる。

本実施形態の電子割印システムのシステム構成例を示す図である。 本実施形態の処理の流れを説明する図である。 本発明で利用する電子公証システムのシステム構成を説明する図である。 本発明で利用する電子公証システムの文書保管の動作を説明する図である。 本発明で利用する電子公証システムの契約書成約の動作を説明する図である。 本発明で利用する電子公証システムにおける公証の対象となる文書をＸＭＬ文書に変換する処理を説明する図である。 本発明で利用する電子公証システムにおける公証の対象となるＸＭＬ文書の構造を説明する図である。

符号の説明

１（１Ａ、１Ｂ） ユーザ端末
２ 記憶部
３ 処理部
４ 電子書類保管部（ＤＶＤ−Ｒ）
５ データベース
７ｂ（７ｂ１，７ｂ２，７ｂ３） 添付書類別ＸＭＬファイル
１１ ＸＭＬ化契約書類ファイル
１２ 公証証明書
１００ 公証システム

Claims (4)

1. 電子証明書や電子署名の検証を行う認証局と協調して、電子文書に付された電子証明書や電子署名の検証を行い、認証された場合には、外部から供給される正確な時刻情報により電子文書にタイムスタンプを付与した上で、この電子文書を保管する公証サービスを利用する電子割印システムであって、
   電子契約の当事者であるユーザの端末と前記公証サービスのサーバとが、通信回線を介して接続し、
   前記ユーザの端末は、記憶部と処理部と電子書類保管部を備え、
   該記憶部には、契約書類１式を構成する契約書本体と、これに付随する１以上の添付書類とを分離した上で電子化して記憶し、
   前記処理部は、
   前記添付書類を前記記憶部から読み出し、添付書類毎に、格納されているデータについて計算したハッシュ値、あるいは格納されているデータ自体に契約当事者の電子署名を付加した添付書類別ＸＭＬファイルを作成し、
   これらの添付書類別ＸＭＬファイルと、前記記憶部から読み出した契約書本体とを一括してエンコードし、このエンコードされた電子文書に契約当事者の電子署名を付加したＸＭＬ化契約書類ファイルを作成し、
   該ＸＭＬ化契約書類ファイルを前記公証サービスのサーバに送信し、該サーバからＸＭＬ化契約書類ファイルの公証証明を受信すると、前記電子書類保管部に、前記契約書本体並びに前記１以上の添付書類と、前記ＸＭＬ化契約書類ファイルと前記公証証明を保管することを特徴とする電子割印システム。ただし、公証サービスのサーバから常に前記公証証明を受信することをできるようにすれば、前記電子書類保管部へ前記公証証明を保管する必要はなくなる。
2. 前記電子書類保管部は、書き換え不可能な記憶媒体であることを特徴とする、請求項１に記載の電子割印システム。
3. 前記記憶媒体に格納した内容をセキュアなデータベースに格納することを特徴とする、請求項２に記載の電子割印システム。
4. 請求項１〜３のいずれかに記載の電子割印システムの機能をコンピュータシステムに実現させるためのコンピュータプログラム。

Images