デジタル契約システム
【課題】簡便な方法で電子的な契約を取り交わして電子契約書を保存する。
【解決手段】端末３１から正式認証情報が送信された場合に限り、端末３１から契約書ファイルをデジタル契約サーバ４に送信させ、ストレージサーバ６に保存する。端末３２から正式認証情報又は仮認証情報が送信された場合に限り、契約書ファイルを端末３２に送信して受諾者に閲覧させる。端末３２において契約について受諾の旨が入力され、その情報がデジタル契約サーバ４に送信される。契約書ファイルには、送信のログ記録及び契約受諾の旨のログ記録が書き込まれ、更新された契約書ファイルについてタイムスタンプサーバ８がタイムスタンプを行い、タイムスタンプファイルがストレージサーバ６に保存される。端末３２から仮認証情報が送信された案件であって所定期間内に本人認証書類を受領していない案件について、削除手段がタイムスタンプファイルをストレージサーバ６から削除する。
【解決手段】端末３１から正式認証情報が送信された場合に限り、端末３１から契約書ファイルをデジタル契約サーバ４に送信させ、ストレージサーバ６に保存する。端末３２から正式認証情報又は仮認証情報が送信された場合に限り、契約書ファイルを端末３２に送信して受諾者に閲覧させる。端末３２において契約について受諾の旨が入力され、その情報がデジタル契約サーバ４に送信される。契約書ファイルには、送信のログ記録及び契約受諾の旨のログ記録が書き込まれ、更新された契約書ファイルについてタイムスタンプサーバ８がタイムスタンプを行い、タイムスタンプファイルがストレージサーバ６に保存される。端末３２から仮認証情報が送信された案件であって所定期間内に本人認証書類を受領していない案件について、削除手段がタイムスタンプファイルをストレージサーバ６から削除する。
【発明の詳細な説明】
【技術分野】
【０００１】
本願の発明は、当事者間での契約を電子契約書として作成して保存するデジタル契約システムに関するものである。
【背景技術】
【０００２】
産業の各分野においてＩＴ（情報技術）の利用が進んでいるが、契約の分野ではあまり進んでいない。この理由の一つには、契約書は、当事者同士の意思を確認する法律文書であり、証拠としての価値等を考慮すると、紙によるものによらざえるを得ないという面があるからである。
【０００３】
しかしながら、数多くの契約を日常的に行っている会社においては、契約の締結、契約書の管理等において非常に多くの手間を要しており、煩雑となっている。例えば、建設業界では、各種工事の発注・受注において請負契約が日常的になされており、大量の契約書が日常的に取り交わされている。また、別の例としては、マンション販売を行う大手デベロッパーでは、年に数百棟単位またはそれ以上のマンション販売をしており、同数の契約を購入者との間で締結している。このような会社では、多数の契約書の管理が必要になっており、その手間が著しく煩雑となっている。このような契約締結や契約書の管理にＩＴを上手く利用することができれば、煩雑さが解消し、業務の効率化に著しい効果があげられるものと考えられる。
【０００４】
一方、インターネットに代表されるＩＴコミュニケーションにおいては、現実に多くの契約が成立している。ネットショッピングにおける商品やサービスの購入等が典型的な例である。これら契約においては、購入ボタン等が押されることをもって購入の意思表示がされたと取り扱うものである。しかし、契約書と呼べるものを取り交わす訳ではないので、契約の存在を示す証拠の保存の観点では十分ではない面がある。即ち、万が一紛争になった場合の立証上の問題や、税務上の理由で契約内容を証する際の問題がある。
【０００５】
電子商取引等において電子的な契約書を作成する場合、デジタル署名（電子署名）が利用される。一般的なデジタル署名である公開鍵方式の場合、認証局は、公開鍵と秘密鍵を発行するとともに、住民票等の本人確認書類の提出を条件に電子証明書（公開鍵証明書）を発行する。署名者が署名対象の電子契約書を秘密鍵を用いて暗号化し、電子証明書を添付することで、書類が電子的に署名されたことになる。相手先は、公開鍵を利用して電子契約書を復号し、契約内容を確認する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−３０９７８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したようなデジタル署名を利用したデジタル契約は、電子証明書の取得に時間が掛かり煩雑であるため、短期間のうちに契約を成立させて契約書を残す必要があるビジネスの現場では、非常に使いづらいものとなっている。特に、当事者の一方が、普段はあまり契約をしていない中小企業であるとか個人である場合、電子証明書を保有していないことが多いため、この問題が顕著である。
【０００８】
マンション販売を例に取り上記の点を説明すると、モデルルーム等を訪れた顧客（個人）がマンションを気に入り購入しようと思った場合、売り主と売買契約を結ぶことになる。この際、仮に電子契約書を作成して契約しようとした場合、両者が電子契約書にデジタル署名をする必要があるので、両者が電子証明書を取得している必要がある。売り主側は、会社（デベロッパーのようなマンション販売業者）である場合、電子証明書を予め取得して日常的に使用していることが多いが、購入者は個人であり、電子証明書を取得していないケースが多い。この場合、マンション購入のためにデジタル署名を行うことになる。デジタル署名は、住民票等の本人確認書類を郵送し、所定の審査をした後、電子証明書を発行してもらい、電子証明書をパソコンにインストールすることで行われる。したがって、マンションの販売・購入に両者が合意した後にこのような手間と時間が必要になる。
【０００９】
このように手間と時間が掛かるようでは、契約書の管理が容易であるとは言っても、電子契約書によらない紙ベースの契約書によることを選択してしまう場合が多い。販売会社の方が電子契約書によると決めているような場合、そのような時間と手間が掛かるとの説明を受けた購入者（個人）は購入自体を見送ってしまうこともあり得る。
本願の発明は、上記のような課題を解決するために為されたものであり、簡便な方法で電子的な契約を取り交わして電子契約書を保存することができるシステムを提供する技術的意義を有するものである。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本願の請求項１記載の発明は、当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末にネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報が真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えているという構成を有する。
また、上記課題を解決するため、請求項１２記載の発明は、当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末とのネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件について、その後に申し入れ者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件であって申し入れ者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって受諾者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えているという構成を有する。
【発明の効果】
【００１１】
以下に説明する通り、本願発明によれば、デジタル契約書によって契約が取り交わされ、デジタル契約書を保管する形なので、契約案件の管理や整理が容易である。その上、契約書ファイルと契約書がアップロードされて契約が受諾された旨を記録したファイルとについてタイムスタンプが付与されて保存されるので、ある時点において確かに契約が成立して契約書がに存在したことや契約書が改ざんされていないことの証明について高い信頼性が得られる。また、受諾者が本人認証をされていない段階でも受諾させてタイムスタンプを付与することが可能であり、システム上で契約を締結することが可能である。その場合も、その後に本人認証書類が届かない案件についてはタイムスタンプファイルが削除されるので、問題は生じない。
【図面の簡単な説明】
【００１２】
【図１】本願発明の実施形態に係るデジタル契約システムの概略図である。
【図２】デジタル契約サイトのトップページの一例について示した概略図である。
【図３】会員登録ページの一例について示した概略図である。
【図４】会員情報ＤＢＦの構造の一例を示した概略図である。
【図５】案件情報ＤＢＦの構造の一例を示した概略図である。
【図６】会員トップページの一例について示した概略図である。
【図７】ファイルアップロードページの一例について示した概略図である。
【図８】案件情報入力ページの一例について示した概略図である。
【図９】アップロードプログラムの概略について示したフローチャートである。
【図１０】アップロードプログラムの動作について示した概略図である。
【図１１】通知メールの一例について示した概略図である。
【図１２】ログ記録がされた契約書ファイルの一例を概略的に示した図である。
【図１３】閲覧用認証ページの概略図である。
【図１４】受諾処理プログラムの概略を示したフローチャートである。
【図１５】受諾のログ記録が追加されたログ付き契約書フィアルの内容の一例について示した概略図である。
【図１６】管理用メニューページの一例について示した概略図である。
【図１７】認証書類受領情報入力ページの一例について示した概略図である。
【図１８】督促メール送信プログラムの概略を示したフローチャートである。
【図１９】督促メールの一例について示した概略図である。
【図２０】申し入れ者宛督促メールの一例について示した概略図である。
【図２１】会員トッププログラムの概略を示したフローチャートである。
【図２２】本願発明の別の実施形態の主要部を示した概略図である。
【図２３】受諾者の仮会員登録を申し入れ者ができるようにした実施形態における案件情報入力ページの一例の概略図である。
【図２４】相手先会員登録ページの一例について示した概略図である。
【発明を実施するための形態】
【００１３】
次に、本願発明を実施するための形態（以下、実施形態）について説明する。図１は、本願発明の実施形態に係るデジタル契約システムの概略図である。図１に示すデジタル契約システムは、ネットワークを介してデジタル契約を締結させてデジタル契約書を保存するサービス（以下、本サービス）を提供するものである。ネットワークとしてはインターネット１が想定されており、デジタル契約システム（以下、単にシステムという）は、インターネット１に接続されたコンピュータ群によって構成されている。コンピュータ群は、不図示のファイアウォールを介してインターネット１に接続されたイントラネット２上に設けられている。イントラネット２は、契約の申し入れ者によって操作される第一の端末３１と受諾者によって操作される第二の端末３２とに対し、インターネット１を介して接続されている。また、インターネット１上にはタイムスタンプ局が設けられている。タイムスタンプ局はタイムスタンプサーバ８を有しており、タイムスタンプサーバ８はインターネット１を介してデジタル契約システムとつながっている。
【００１４】
コンピュータの幾つかはサーバコンピュータであり、その主要なものは、本サービスの提供のためのサイト（以下、デジタル契約サイト）を提供するウェブサーバ（以下、デジタル契約サーバ）４である。この他、認証サーバ５、ストレージサーバ６等が設けられている。図１は、サーバの機能として概念的に表示したものであり、二以上のサーバの機能が一つのサーバコンピュータで兼用して実現されることもある。また、イントラネット２上には、管理用クライアント７が設けられている。管理用クライアント７は、本システムを運営して本サービスを提供する会社（以下、運営会社）内の担当者によって操作されるクライアントコンピュータである。
【００１５】
本サービスの提供は、概略的には以下のようなステップで行われる。まず、本サービスの提供を受けるには、会員登録が必要になっており、少なくとも申し入れ者が正式な会員登録をした状態で本サービスの提供が開始される。正式会員登録をすると、デジタル契約サイトの会員トップページへのアクセスが可能となる。会員トップページでは、システムを利用した契約案件の進捗状況を確認することができる。
【００１６】
本システムを利用した契約の締結は、会員登録をした一方の当事者がデジタル文書としての契約書のファイル（以下、契約書ファイル）をシステムにアップロードすることで始まる。このアップロードは、その当事者がその契約を申し入れる意思表示であり、したがって、正式な会員登録は、本人認証をした上でなされ、それを前提にアップロードが許容される。また、契約の受諾側については、少なくとも仮の会員登録がされていることが必要であり、申し入れ者は受諾者に対して予め本システムにアクセスして仮会員登録するよう依頼しておく。
【００１７】
契約書ファイルがアップロードされると、システムは、受諾確認用の契約書ファイルの生成、受諾者への通知メールの生成と送信等を行う。通知メールは、契約書ファイルがアップロードされた旨を知らせるメールであり、受諾者が操作する第二の端末３２に送信される。受諾者は、第二の端末３２によってデジタル契約サイトにアクセスして契約書ファイルを開き、受諾ボタンをクリックして契約を成立させる。
この間のシステムにおける処理は、契約書ファイル自体にログ記録されており、受諾ボタンがクリックされると、システムは、ログ記録付きの契約書ファイルについてタイムスタンプ手段にタイムスタンプ要求を発し、返信されるタイムスタンプファイルを保存する。その後、仮会員登録をした受諾者から本人認証書類の到着を待ち、所定期間過ぎても到着しない場合、本人認証ができないとしてそのタイムスタンプファイルを削除する処理を行う。
【００１８】
次に、上記のようなサービスを提供するシステムの各部について詳説する。
まず、デジタル契約サーバ４について説明する。デジタル契約サーバ４は、ウェブサーバであり、会員登録ページ、会員トップページ等の提供を行うものである。デジタル契約サーバ４は、各ページを提供するＨＴＭＬファイルやデータの受け渡しを行うサーバプログラムを備えている。各ページを提要するＨＴＭＬファイルは、デジタル契約サーバ４の保存部（ハードディスク等）に保存されている。このようなウェブサーバは、市販のウェブサーバソフトウェアをサーバコンピュータに実装することで実現できるので、細部の詳細な説明は割愛する。
【００１９】
図２は、デジタル契約サイトのトップページの一例について示した概略図である。図２に示すように、トップページには、本サービスの概要やメリットについて解説した欄が設けられているとともに、会員登録ページへのリンクボタン（会員登録ボタン）４１や会員登録されている者のためのログインボタン４２が設けられている。
本システムにおいて会員登録は、本人認証をした上で行われる。本システムでは、本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存部する正式認証情報発行保存手段と、本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段とが設けられている。これらの手段は、会員登録ページを提供するデジタル契約サーバ４と、認証情報を保存する認証サーバ５等によって構成されている。
【００２０】
図３は、会員登録ページの一例について示した概略図である。図３に示す会員登録ページは、会員ＩＤ及びパスワードの入力欄、法人・個人の選択欄、氏名（法人の場合には法人名）の入力欄等が設けられている。この例では、会員ＩＤとしては連絡用のメールアドレスを兼用して入力するようになっている。また、パスワードとしては、字数や使用できる文字の種類に制限はあるものの、入力者が任意のパスワードを設定して入力できるようになっている。
【００２１】
認証サーバ５には、データベースファイルを管理するデータベース管理プログラム（ＤＢＭＳ））が実装されている。ＤＢＭＳによって管理されるデータベースファイル（ＤＢＦ）として、会員情報をデータベース化したデータベースファイル（以下、会員情報ＤＢＦ）が保存されている。
図４は、会員情報ＤＢＦの構造の一例を示した概略図である。図４に示すように、会員情報ＤＢＦは、「会員ＩＤ」（本実施形態ではメールアドレス）、「正仮種別」、「法人個人種別」、「仮登録日」、「仮パスワード」、「正式登録日」、「正式パスワード」、「名前」、「住所」、「電話番号」等のフィールドからなるレコードが多数登録されるファイルとなっている。図３に示す会員登録ページの各欄が正しく入力されて送信ボタン４３がクリックされると、入力された情報が認証サーバ５に送られ、会員情報ファイルに新規レコードが追加されて記録されるようプログラミングされている。
【００２２】
尚、図３に示す会員登録ページでの入力による登録の段階では、まだ仮登録の状態であり、送信ボタンがクリックされた日は「仮登録日」のフィールドに記録され、「正仮種別」の欄には、仮登録である旨の情報が記録される。図３に示すように、会員登録ページには、ここでの登録は仮登録であり、正式な申し込み書と本人認証書類の提出を待って正式登録がされるので、申し込み書及び本人認証書類の所定期間内に郵送して欲しい旨のメッセージが表示されるようになっている。
【００２３】
本人認証書類とは、法人であれば登記簿謄本及び印鑑証明であるし、個人であれば住民票及び印鑑証明ということになる。申し込み書には、署名欄及び実印の捺印欄が設けられている。運営会社の担当者は、上記仮登録の後、署名及び実印を捺印した申し込み書と本人認証書類が所定期間内に届くかどうかチェックしており、届いた場合には、正式な会員ＩＤ及びパスワードを発行する。この部分については二通りのやり方がある。
一つは、会員ＩＤ及び正式パスワードを記載した書面を本人しか受領できない郵便で送るやり方である。会員ＩＤ及び正式パスワードは、契約の際の本人の意思を確認するもの（実印に相当するもの）であるので、本人のみが受領できるようにする。
【００２４】
もう一つのやり方は、上記仮登録の際の任意に決めたパスワードを他人に知らせないようにしてもらい、そのパスワードと同じパスワードを申し込み書に記載してもらうやり方である。申し込み書には、同様に署名欄及び実印の捺印欄を設けられているとともに、任意のパスワードを記載する欄が設けられる。申し込み書に署名及び実印捺印をした上、任意のパスワードを記載し、申し込み書とともに本人認証書類を運営会社に送付するようにする。この運営会社宛の送付は、パスワードが漏洩しないように親展扱いの書留郵便等にすることが望ましい。尚、この場合、正式パスワードは、仮登録の際の同じものとなるので、会員情報ＤＢＦについては、図４に示すように「正式パスワード」と「仮パスワード」の二つを設ける必要はなく、単に一つのパスワードを登録するフィールドを設けるだけにしても良い。
この後者のやり方の場合、運営会社としては、パスワードを本人に知らせる必要が無いので、本人のみ受領郵便のような高額な郵送料が要らなくなり、コスト的な面でメリットが大きい。
【００２５】
署名及び実印の捺印をした申し込み書と本人認証書類が運営会社に届くと、運営会社の担当者は、申し込み書と本人認証書類の内容を確認し、正しく本人認証できたと判断すると、管理用クライアント７を操作し、会員情報ＤＢＦを開く。そして、仮登録されている該当レコードの「正仮種別」のフィールドに正式会員である旨の情報を上書きして記録するとともに、「正式会員登録日」のフィールドに認証日を入力する。これで正式会員として登録がされたことになる。このようにして正式な会員登録（本人認証付きの会員登録）をすると、会員専用のページへのアクセスしてサービスの提供を受けることが可能となる。パスワードをシステム上で発行する構成の場合、正式パスワードが自動生成され、会員情報ＤＢＦの該当レコードに記録される。この場合の正式パスワードは、本人のみが受領できる郵便で郵送される。
尚、図４に示すように、会員情報ＤＢＦの各レコードには、「使用有無」という名前のフィールドが設けられている。このレコードには、仮会員登録の段階で受諾者としてシステムを利用したか否かの情報が記録されるようになっている。これは、後述するように、仮パスワードの融通性を下げるための技術構成である。
【００２６】
次に、会員向け各種サービスを提供するためのシステムの構成について説明する。契約締結を仲介するためになされる会員向けの各種サービスの管理のため、本実施形態のシステムは、各契約案件の情報を登録したデータベースファイル（以下、案件情報ＤＢＦ）を備えている。図５は、案件情報ＤＢＦの構造の一例を示した概略図である。
図５に示すように、案件情報ＤＢＦは、「案件ＩＤ」、「案件名」、「申し入れ者会員ＩＤ」、「申し入れ者名前」、「情報保存期間」、「受諾者会員ＩＤ」、「受諾者名前」、「受諾者正仮別」、「契約書ファイル名」、「アップロード日時」、「ファイル保存場所」、「受諾日時」、「本人認証書類受領日」等のフィールドから成るレコードを多数登録したデータベースファイルとなっている。また、図示はされていないが、タイムスタンプ要求を発した日時である「タイムスタンプ日時」のフィールドも設けられている。
【００２７】
会員向けのサービスの提供を受けるには、会員としてのログインが必要である。即ち、図２に示すように、トップページにはログインボタン４２が設けられている。ログインボタン４２をクリックすると、本人認証ページ（会員ＩＤ及びパスワードを入力させるページ）が表示されるようになっている。本人認証ページには送信ボタンが設けられており、送信ボタンには、会員トップページを表示するプログラム（以下、会員トッププログラム）の起動コマンドが埋め込まれている。本人認証ページにおいて会員ＩＤ及びパスワードが入力されて送信ボタンがクリックされると、会員トッププログラムが起動する。会員トッププログラムは、入力された会員ＩＤ及びパスワードを会員情報ＤＢＦ内のデータと照合してが正しいかどうか（正式な会員登録における会員ＩＤ及びパスワードに一致するかどうか）判断し、正しければ、会員トップページのＨＴＭＬファイルを送って端末に表示させる。この際、会員トッププログラムは、後述するように案件情報ＤＢＦを検索して必要な情報を収集してＨＴＭＬファイルに嵌め込む。尚、会員ＩＤは後の処理のためにメモリ変数に一時的に格納される。会員ＩＤとしては、本実施形態では、メールアドレスが兼用されている。
【００２８】
図６は、会員トップページの一例について示した概略図である。図６に示すように、会員トップページは、自分が関係している契約案件のシステム上の処理状況をリスト表示して知らせるページであるとともに、会員に提供される各種サービスの窓口となるページである。
【００２９】
次に、契約書ファイルのアップロードについて説明する。本実施形態のシステムは、第一の端末３１から契約書ファイルをインターネット１を介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段を備えている。契約書ファイル送信手段は、デジタル契約サーバ４と、デジタル契約サーバ４に実装されたアップロードプログラム等によって構成されている。
契約書ファイルのアップロードは、契約を申し入れる行為であり、契約書ファイルをデジタル契約サーバ４に送信させ、デジタル契約サーバ４経由でストレージサーバ６に保存するとともに、この際、その契約案件の情報を入力させて案件情報ＤＢＦに登録するステップである。契約書ファイルのアップロードは、作成された契約書ファイルをＨＴＭＬに変換し、必要な情報を嵌め込んだ上でデジタル契約サーバ４にアップロードするステップである。そして、この契約書ファイルのアップロードの際、相手先（受諾者）に契約書アップがアップロードされた旨を通知するメール（以下、通知メール）が送信されるようになっている。
【００３０】
より具体的に説明すると、図６に示すように、会員トップページには、「新規契約書登録」と表記されたコマンドボタン（以下、契約書登録ボタン）４４が設けられている。契約書登録ボタン４４は、契約書ファイルをデジタル契約サーバ４に送信させ、ストレージサーバ６に保存するためのページ（以下、ファイルアップロードページ）へのリンクが埋め込まれている。
【００３１】
図７は、ファイルアップロードページの一例について示した概略図である。
図７に示すように、ファイルアップロードページには、契約書ファイルを選択する欄（以下、ファイル選択欄）が設けられている。この部分は、ファイルアップロードページにアクセスした端末に保存されているファイルを指定する欄であり、「参照」と表記されたコマンドボタン（参照ボタン）４５をクリックすることで、ハードディスクやＵＳＢメモリ等に保存された契約書ファイルを指定するようになっている。
ファイルアップロードページには、「ファイルのアップロード」と表記されたボタン（以下、アップロードボタン）４６が設けられている。アップロードボタン４６には、案件情報入力ページへのリンクが埋め込まれている。
【００３２】
図８は、案件情報入力ページの一例について示した概略図である。図８に示すように、案件情報入力ページには、案件名入力欄、相手先メールアドレス入力欄、契約金額入力欄等が設けられている。前述したように、契約書ファイルをアップロードする時点では、受諾者は少なくとも仮会員登録していることが必要であり、相手先メールアドレス入力欄には、受諾者の仮会員登録又は正式会員登録におけるメールアドレスが入力される。申し入れ者は、予めこのメールアドレスを聞いておき、それを入力する。
【００３３】
受諾者が会員登録を全くしていない場合、受諾者は予め第二の端末３２を操作して本サイトにアクセスし、仮の会員登録をする。この部分の構成は、前述した申し入れ者についての仮会員登録の場合と同様である。受諾者は、自分のメールアドレスを会員ＩＤとして入力し、任意のパスワードを自分で設定して入力した上で仮会員登録をする。会員情報ＤＢＦにおいて新規レコードが追加され、入力されたメールアドレスが「会員ＩＤ」のフィールドに記録され、入力された仮パスワードが「仮パスワード」のフィールドに記録される。「正仮種別」のフィールドに仮会員である旨の情報が記録される。「使用有無」のフィールドについては、使用無しの旨の情報がデフォルト値であり、そのまま状態でこの新規レコードが登録される。
【００３４】
図８に示すように、案件情報入力ページには送信ボタン４９が設けられている。この送信ボタン４９には、アップロードプログラムの起動コマンドが埋め込まれている。アップロードプログラムは、送信された契約書ファイルをストレージサーバ６への保存に加え、契約書ファイルの変換、案件情報の登録、通知メールの送信等を行うプログラムである。図９及び図１０を使用してアップロードプログラムの詳細について説明する。図９はアップロードプログラムの概略について示したフローチャート、図１０はアップロードプログラムの動作について示した概略図である。
【００３５】
図９に示すように、アップロードプログラムは、まず、入力された各案件情報をメモリ変数に格納する。次に、アップロードプログラムは、受諾者の会員登録（正又は仮）がされているかどうか判断する。具体的には、入力された相手先メールアドレスを検索キーにして会員情報ＤＢＦを検索し、「会員ＩＤ」のフィールドの値がこのメールアドレスに一致するレコードがあるかどうか判断する。もし一致するレコードが無ければ、受諾者は正式会員でも仮会員でもないことになるので、「該当するメールアドレスがシステムに登録されておらず、受諾者は会員登録されていないようです。受諾者に対して仮会員登録をするよう依頼して下さい。契約書ファイルのアップロードは受諾者が仮会員登録をした後に可能になります。」というようなエラーメッセージを第一の端末３１に表示した後、プログラムを終了させる。入力されたメールアドレスが「会員ＩＤ」のフィールドの値に一致するレコードがあった場合、「正仮種別」のフィールドの値を読み出して正会員か仮会員かを判断し、仮会員であった場合、「使用有無」のフィールドの値を読み出す。この値が「有」であった場合、別の案件で過去に既にシステムを利用したにも関わらずまだ正式登録がされていない会員であり、本実施形態ではシステムの利用ができないので、「受諾者がまだ仮会員登録の段階であって既に別の案件でシステムを利用しているので、契約書ファイルをアップロードできません。」というようなエラーメッセージを送信し、プログラムを終了させる。
【００３６】
受諾者が正式会員か、又は仮会員で過去にシステムの利用が無い場合には、契約書ファイルのアップロードを許可して情報の登録を行う。即ち、アップロードプログラムは、読み出したメールアドレス及び正仮種別の値をメモリ変数に格納する。次に、アップロードプログラムは、受諾者が仮会員である場合、会員ＩＤ（メールアドレス）で会員情報ＤＢＦを検索し、該当するレコードの「使用有無」のフィールドに「有」の値を記録する。次に、アップロードプログラムは、案件情報ＤＢＦに新規レコードを追加し、メモリ変数から情報を読み出して新規レコードの各フィールドに記録する。この際、案件ＩＤを自動生成し、「案件ＩＤ」のフィールドに記録する。受諾者が仮会員である場合、「受諾者正仮別」のフィールドにその旨の情報を記録する。
【００３７】
次に、アップロードプログラムは、契約書ファイルを送信してきた送信元（第一の端末３１）の端末識別情報を案件情報ＤＢＦに記録する。図５に示すように、案件情報ＤＢＦの各レコードには、「送信元端末情報」という名前のフィールドが設けられている。端末識別情報として本実施形態ではＩＰアドレスを記録するようになっており、アップロードプログラムは、セッションの環境変数からＩＰアドレスを取得し、「送信元端末情報」のフィールドに記録する。
次に、アップロードプログラムは、送信された契約書ファイルをそのままマスタファイルとしてストレージサーバ６の保存部の所定の場所に保存する。例えば、案件ＩＤの名前でディレクトリを新たに生成し、そこを保存場所とする。そして、この保存場所の情報を、追加した新規レコードの「ファイル保存場所」のフィールドに記録する。
【００３８】
次に、アップロードプログラムは、契約書ファイルの変換を行う。この変換は、契約書ファイルをインターネット１上で受諾者が閲覧できるようにするとともに、受諾意思の確認用のボタン（以下、受諾ボタン）を契約書ファイル内に嵌め込むためのものである。
本実施形態では、アップロードプログラムは契約書ファイルをＨＴＭＬファイルに変換するようプログラミングされている。図１０に概略的に示すように、アップロードプログラムは、送信された契約書ファイル（文書ファイル）のテキスト部分をＨＴＭＬファイルの本体部分に嵌め込み、その下に受諾ボタン５０を嵌め込むようプログラミングされている。このようなプログラミングは、ワードプロセッサソフトウェアのマクロ機能を利用すれば容易に実現できるので、詳細な説明は割愛する。尚、受諾ボタン５０には、後述する受諾処理プログラムの起動コマンドが埋め込まれるようになっている。この際、生成した案件ＩＤを引数にして渡すように起動コマンドが記述される。
【００３９】
アップロードプログラムは、このようにして変換された契約書ファイル（以下、変換済み契約書ファイル）は、ストレージサーバ６の保存部の所定の場所（契約書ファイルと同じディレクトリでも良い）に保存する。次に、アップロードプログラムは、図９に示すように、通知メールの生成と送信を行う。通知メールは、契約書ファイルがアップロードされたのでアクセスして欲しい旨を伝えるメールである。図１１は、通知メールの一例について示した概略図である。
【００４０】
デジタル契約サーバ４の保存部には、通知メール用のテンプレートファイル（以下、メールテンプレート）が保存されている。メールテンプレートは、受諾者が仮会員か正式会員かで異なるものが使用されるようになっており、それぞれ保存されている。アップロードプログラムは、メモリ変数から正仮会員種別の値を取り出して仮会員か正式会員かを判断する。仮会員であれば仮会員用のメールテンプレートを読み出し、正式会員であれば正式会員用メールテンプレートを読み出し、必要事項を嵌め込んで通知メールを作成する。
【００４１】
図１１に示すように、通知メールには、システムの会員になっている者から、ある契約についての申し入れがあり、契約書ファイルがアップロードされた旨、契約を受諾する意思があれば、システムにアクセスして契約書の内容を確認し、受諾ボタンをクリックして欲しい旨等が記載されている。アクセス用のＵＲＬ（ハイパーリンク）も埋め込まれる。これは定型のものであり、これに続く部分に案件名や申し入れ者名等の具体的な案件情報が記載されるようになっている。案件名は、メモリ変数から読み出して嵌め込む。申し入れ者名は、ログインの際に入力された会員ＩＤをメモリ変数から読み出し、会員情報ＤＢＦを検索して取得し、それを嵌め込む。
【００４２】
図１１に示す通知メールは、受諾者が仮会員登録された者である場合の例である。この場合、アップロードプログラムは、受諾者の会員ＩＤをメモリ変数から読み出し、図１１に示すように通知メールに嵌め込む。この場合、図１１に示すように、通知メールには、この登録情報は仮のものであり、後日、本人認証書類の提出が必要である旨のメッセージを併せて記載する。受諾者が正式会員登録された者である場合（正式会員用のメールテンプレートの場合）は、このようなメッセージは記載されていない。誤ったメール送信等を考慮し、この契約案件に身に覚えがない場合にはシステムにアクセスせずに所定の連絡先に知らせて欲しい旨のメッセージも記載されるようになっている。
アップロードプログラムは、このようにして通知メールを生成した後、メモリ変数から受諾者のメールアドレス（会員ＩＤ）を読み出し、このアドレスを送信先にして通知メールを送信する。
【００４３】
次に、アップロードプログラムは、契約書ファイルがアップロードされた旨のログ記録を行う。ここでのログ記録は、契約書ファイルが申し入れ者からアップロードされた旨の記録であり、法律的には契約の申し入れが申し入れ者からあったことを意味する。本実施形態における大きな特徴点の一つは、このログ記録が契約書ファイル自体に行われる点である。
【００４４】
図１２を使用してより具体的に説明する。図１２は、ログ記録がされた契約書ファイルの一例を概略的に示した図である。図１２に示すように、アップロードプログラムは、送信された契約書ファイル（文書ファイル）において、最終頁の後にさらに頁を追加する処理を行い、この追加した頁にテキストでログ記録をする。記録される情報は、申し入れ者の会員ＩＤ（メールアドレス）、会社名（個人の場合は氏名）、アップロード日時、送信元端末識別情報である。アップロード日時は、アップロードの際のアクセスにおける環境変数から取得する。送信元端末識別情報は、前述したように、本実施形態では送信元（第一の端末３１）のＩＰアドレスである。
【００４５】
このようにしてログ記録をした後、契約書ファイルを別のファイル名にし、ストレージサーバ６の保存部の所定のパスに保存する。この契約書ファイルは、ログ記録付きの契約書ファイルであり、以下、ログ付き契約書ファイルと呼ぶ。ログ付き契約書ファイルのファイル名は、後から容易に読み出せるように、予め定められたやり方で名前等が決定される。例えば、案件ＩＤをファイル名にしたり、案件ＩＤをディレクトリ名にしてその下に保存するといったやり方である。このようにしてログ付き契約書ファイルを保存すると、アップロードプログラムは終了である。上記説明から解るように、デジタル契約サーバ４及びアップロードプログラムは、契約書ファイルの保存と契約書ファイルのアップロード送信のログ記録の保存を行う契約書ファイル保存手段を構成している。
【００４６】
次に、本システムは、保存された契約書ファイルを第二の端末３２に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、契約書ファイルを閲覧した受諾者が第二の端末３２において当該契約について受諾の旨の入力をした際、インターネット１を介してその旨の情報を受信する受諾情報受信手段と、受諾情報受信手段が受諾の旨の情報を受信した際、その契約案件の契約書ファイルの内容と受諾の旨の情報についてタイムスタンプ手段に対してタイムスタンプ要求を送信するとともにその受信のログ記録を保存部に保存する受諾情報処理手段とを備えている。
【００４７】
まず、契約書ファイル閲覧手段について説明する。契約書ファイル閲覧手段は、デジタル契約サーバ４等によって構成されている。デジタル契約サーバ４の保存部には、契約書ファイル閲覧用の認証ページ（以下、閲覧用認証ページ）を表示するためのＨＴＭＬファイルが保存されている。図１３は、閲覧用認証ページの概略図である。図１１に示す通知メールに記載されたアクセス用のＵＲＬは、案件ＩＤを渡しつつ閲覧用認証ページを開くコマンドとなっている。
【００４８】
閲覧用認証ページは、開かれた際、渡された案件ＩＤをメモリ変数に一次的に格納するようになっている。図１３に示すように、閲覧用認証ページには、会員ＩＤとパスワードの入力欄が設けられており、正式会員の場合には正式会員としてのパスワードを入力し、仮会員の場合には、仮会員登録の場合に自分が任意に設定したパスワードを入力して欲しい旨のメッセージが表示されるようになっている。閲覧用認証ページには、送信ボタン５１が設けられている。デジタル契約サーバ４には、変換済み契約書ファイルを送信して閲覧させる契約書ファイル閲覧プログラムが実装されている。送信ボタン５１には、契約書ファイル閲覧プログラムの起動コマンドが埋め込まれている。
【００４９】
契約書ファイル閲覧プログラムは、メモリ変数から案件ＩＤを読み出し、案件ＩＤを検索キーにして案件情報ＤＢＦを検索し、入力された会員ＩＤ及びパスワードが正しいかどうか判断する。この際、「受諾者正仮種別」のフィールドの値を読み出して受諾者が正式会員か仮会員かを判断する。正式会員であれば、会員ＩＤを認証サーバ５に送り、入力されたパスワードが「正式パスワード」と一致するかどうかを判断させる。仮会員であれば、会員ＩＤを認証サーバ５に送り、会員情報ＤＢＦの該当レコードの「使用有無」のフィールドを読み出す。このフィールドの値が「有り」であれば、別の案件で既に仮登録を使用しているので、「この会員ＩＤによる登録は仮登録の段階であり、別の案件でシステムを利用されていて、その別の案件ではまだ本人認証されておりません。したがって、本件でのシステムの利用はできません。別の案件で要請されている本人認証書類の送付がされ、正式会員となった後に改めてアクセスしてください。」というようなエラーメッセージを送信し、プログラムを終了する。「使用有無」のフィールドが「無し」の値であれば、閲覧を許可し、その案件の契約書ファイルをストレージサーバ６から読み出し、アクセスしてきた第二の端末３２に送信する。これにより、契約書ファイル閲覧プログラムは終了である。
【００５０】
第二の端末３２に表示される変換済み契約書ファイルは、当然ながら図１０に示されるものと同様である。即ち、図１０に示すように、変換済み契約書ファイルを表示すると、契約内容を記載した部分の末尾に、受諾ボタン５０が表示されるようになっている。デジタル契約サーバ４には、第二の端末３２から送信された受諾の旨の情報を受信して処理する受諾処理プログラムが実装されており、受諾ボタン５０には受諾処理プログラムの起動コマンドが埋め込まれている。受諾ボタン５０は、案件ＩＤを引数にして受諾処理プログラムを起動するようになっている。即ち、前述したアップロードプログラムは、案件ＩＤを引数にして受諾処理プログラムを起動するコマンドを埋め込む形で受諾ボタン５０を通知メールに嵌め込むようプログラミングされている。
【００５１】
次に、受諾情報受信手段、受諾情報処理手段及びタイムスタンプファイル保存手段について説明する。これらの手段は、デジタル契約サーバ４及びデジタル契約サーバ４に実装された受諾処理プログラム等によって構成されている。
図１４は、受諾処理プログラムの概略を示したフローチャートである。図１４に示すように、受諾処理プログラムは、案件ＩＤを引数にして案件情報ＤＢＦを検索し、該当するレコードの「受諾日時」のフィールドに受信日時（アクセスの環境変数から取得）を記録する。また、受諾処理プログラムは、受諾端末情報の記録も行う。受諾者端末識別情報は、受諾の旨を送信した第二の端末３２を識別する情報であり、契約書ファイルの送信元（第一の端末３１）と同様、本実施形態ではＩＰアドレスとなっている。受諾処理プログラムは、セッションの環境変数からＩＰアドレスを取得し、「受諾端末情報」のフィールドに記録する。
【００５２】
次に、受諾処理プログラムは、該当する案件のログ付き契約書ファイルを開き、ログ記録をさらに追加する。図１５は、受諾のログ記録が追加されたログ付き契約書フィアルの内容の一例について示した概略図である。図１５に示すように、ログ記録用に追加した頁の最終行の次に追記する形で、受諾者の会員ＩＤ（メールアドレス）、法人名（個人の場合は氏名）、受諾日時（上記受信日時）、受諾端末情報を記録するようになっている。これらログ記録の後、ログ付き契約書ファイルを同じファイル名で同じ場所に保存（即ち上書き）する。
【００５３】
次に、受諾処理プログラムは、タイムスタンプ手段に対しタイムスタンプ要求を送信する。タイムスタンプ手段は、本実施形態のシステムにおいて作成されるログ付き契約書ファイルについてタイムスタンプを付与するもので、ログ付き契約書ファイルの内容とそれが存在していた日時を証明する手段である。タイムスタンプ手段は、タイムスタンプ要求を受信すると、ログ付き契約書ファイルの非改ざん性と存在日時を証明するためのファイル（以下、タイムスタンプファイルと呼ぶ）を返信する。本実施形態のシステムは、このタイムスタンプファイルを保存し、後に必要になった時に開いて契約内容の真正さを確認するようにしている。具体的に説明すると、本実施形態では、ログ付き契約書ファイルのハッシュ値を送信してタイムスタンプ要求をするようになっており、タイムスタンプ手段は、ハッシュ値と日時情報を統合して生成するタイムスタンプトークンをタイムスタンプファイルとして返信するようになっている。タイムスタンプトークンは、いわゆる公開鍵で復号されるもので、元データ（ここではログ付き契約書ファイル）から同様のアルゴリズムで生成したハッシュ値と比較して真正かどうかが検証されるファイルである。したがって、本実施形態では、タイムスタンプトークンをタイムスタンプファイルとしてストレージサーバ６に保存するようになっている。
【００５４】
タイムスタンプ手段は、図１に示すように、具体的にはタイムスタンプ局に設置されたタイムスタンプサーバ８である。タイムスタンプ局は、タイムスタンプサービスを提供する会社によって運営されている。タイムスタンプサーバ８は、インターネット１を介して送信されたタイムスタンプ要求を受信することが可能となっている。受諾処理プログラムは、ログ付き契約書ファイルを所定のアルゴリズムで暗号化してハッシュ値を生成し、ハッシュ値をタイムスタンプサーバ８に送信しながらタイムスタンプ要求を送信する。ログ付き契約書ファイルをＰＤＦのようなイメージファイルにしてからハッシュ値を生成するようにする場合もある。タイムスタンプサーバ８では、送信されたハッシュ値に対して時刻情報（国際標準時）を結合し、タイムスタンプトークンを返信する。受諾処理プログラムは、返信されたタイムスタンプトークンをストレージサーバ６の保存部の所定のディレクトリに保存する。これで受諾処理プログラムは終了である。
【００５５】
尚、ハッシュ値の生成やタイムスタンプサーバ８へのタイムスタンプ要求については、タイムスタンプ局を運営する会社から適宜のプラグインプログラムが提供されているので（例えば、アマノビジネスソリューションズ（株）から提供されているe-timing EVIDENCE 3161 for Acrobat）、適宜組み込むことで上記処理を実現することができる。タイムスタンプトークンの復号や元データとの照合（検証）についても同様であり、提供されたプラグインプログラムを実装することによって行える。
【００５６】
次に、削除手段について説明する。本システムは、受諾者が仮登録の段階で受諾した場合であって所定期間内に受諾者から本人認証書類が届かなかった場合に、タイムスタンプファイルを削除する削除手段を備えている。本実施形態では、削除手段は、本人認証書類が届いた旨の情報（以下、認証書類受領）が案件情報ＤＢＦに登録されているもの以外は所定期間経過後にすべて自動的に削除するようになっており、削除手段は、この削除を行うプログラム（以下、削除プログラム）と、削除プログラムを実行するデジタル契約サーバ４等によって構成されている。
【００５７】
まず、認証書類受領情報の登録について説明する。本システムは、受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段を備えている。管理用クライアント７は、認証書類受領情報の登録を含む管理用プログラムを実行するための管理用メニューページを表示できるようになっている。メニューページは、管理用クライアント７の保存部（ハードディスク等）に保存されているページファイルによるものであっても良いし、デジタル契約サーバ４に管理用のページを設け、そこにアクセスして取得するようにしても良い。
【００５８】
図１６は、管理用メニューページの一例について示した概略図である。図１６に示すように、管理用メニューページには、「認証書類受領登録」と表記されたコマンドボタン５２がある。このコマンドボタン５２がクリックされると、案件ＩＤを入力するページ（案件ＩＤ入力ページ）が表示されるようになっている。案件ＩＤ入力ページには、ＯＫボタンが設けられており、ＯＫボタンには、認証書類受領情報入力ページを表示するためのプログラムの起動コマンドが埋め込まれている。このプログラムは、入力された案件ＩＤをメモリ変数に格納するとともに案件ＩＤを引数にして案件情報ＤＢＦを検索し、該当するレコードの「案件名」、「申し入れ者名前」、「受諾者名前」等のフィールドの情報を読み出し、認証書類受領情報入力ページに組み込んで認証書類受領情報入力ページを管理用クライアント７に表示するプログラムとなっている。
【００５９】
図１７は、認証書類受領情報入力ページの一例について示した概略図である。図１７に示すように、認証書類受領情報入力ページは、入力した案件ＩＤや、案件情報ＤＢＦから取得した案件名、当事者の名前等の情報を確認のため表示するようになっている。
そして、認証書類受領ページには、各認証書類が正しく受領されているときに入力される確認入力欄（この例ではチェックボックス）が設けられており、各確認入力欄が入力された状態でＯＫボタン５３がクリックされると、内容確認用のページが表示されるようになっている。このページには登録ボタンが設けられており、登録ボタンには、案件情報ＤＢＦ及び会員情報ＤＢＦへの登録用のプログラムの起動コマンドが埋め込まれている。このプログラムは、案件ＩＤをメモリ変数から読み出して案件情報ＤＢＦを検索し、該当するレコードの「受諾者認証日」のフィールドに、管理用クライアント７の内蔵時計（いわゆるシステム時刻）から日にちデータを取得して記録する。このプログラムは、次に正式会員登録の処理をする。会員情報ＤＢＦの当該レコードの「正仮種別」に正式会員である旨の情報を上書きして記録する。パスワードとしては、仮登録の際に受諾者が任意に設定した仮パスワードをそのまま正式なパスワードとする。これは、前述したように、パスワードの通知の手間とコストが省けるからである。その後、正式会員登録を通知する書面をプリントアウトすれば、プログラムは終了である。運営会社の担当者は、書面を本人のみが受領できる郵便で受諾者に送付する。受諾者は、以後は正式会員として本システムにアクセスできることになる。尚、正式パスワードとしては、仮パスワードとは別に自動生成するようにしても良い。この場合、通知する書面に正式パスワードを記載し、本人のみ受領できる郵便で送付する。
【００６０】
一方、本実施形態のシステムは、仮会員登録の受諾者が受諾してから一定期間以内に受諾者の本人認証書が届いていない案件について督促メールを送る督促メール送信手段が設けられている。本実施形態では、督促メール送信手段は、デジタル契約サーバ４と、デジタル契約サーバ４に実装された督促メール送信プログラム等によって構成されている。また、デジタル契約サーバ４の記憶部には、申し入れ者宛の督促メールのテンプレートファイル（以下、申し入れ者用メールファイル）と、受諾者宛の督促メールのテンプレートファイル（以下、受諾者用メールファイル）とが記憶されている。
【００６１】
図１８は、督促メール送信プログラムの概略を示したフローチャートである。本実施形態では、受諾者が受諾してから（受諾ボタンをクリックしてから）例えば二週間以内に本人認証書類を送付するルールとなっており、督促メールは、二週間経過の時点で自動的に送信されるようになっている。
より具体的に説明すると、督促メール送信プログラムは、一日一回所定の時刻（例えば午前０時）に自動実行されるプログラムとなっている。この時刻が到来すると、督促メール送信プログラムは、案件情報ＤＢＦの最初のレコードにポインタを移動させ、「受諾者正仮別」のフィールドに仮会員である旨の値が記録されており、「受諾日時」のフィールドに値があり（Ｎｕｌｌ値ではなく）、受諾日時から二週間（１４日）以上経過しており、且つ「受諾者認証書類受領日」のフィールドがＮｕｌｌ値であるかどうか判断する。これらの条件がすべて成立する場合、「申し入れ者会員ＩＤ」のフィールドの値を読み込んでメモリ変数に格納するとともに、「受諾者会員ＩＤ」のフィールドの値を別のメモリ変数に格納する。
【００６２】
次に、督促メール送信プログラムは、デジタル契約サーバ４の保存部から申し入れ者用メールファイルを読み出す。案件ＩＤ、案件名、受諾者名前等の情報を案件情報ＤＢＦの当該レコードから読み出して申し入れ者用メールファイルに嵌め込み、督促メールを生成する。そして、申し入れ者のメールアドレス（申し入れ者会員ＩＤ）を宛先としてメール送信をする。督促メール送信プログラムは、受諾者についても同様にメール送信を行う。即ち、受諾者用メールファイルを開き、案件ＩＤ、案件名、申し入れ者名前等の情報を案件情報ＤＢＦから読み出して嵌め込み、受諾者会員ＩＤのメールアドレスに送信する。
その後、督促メール送信プログラムは、ポインタを次のレコードに移動させ、同様の条件が成立するか判断する。成立すれば、同様に督促メールを申し入れ者と受諾者とに送る。このようにして、条件が成立するレコード（案件）について督促メールを送り、最後のレコードまで処理をすると、督促メール送信プログラムは終了である。
【００６３】
図１９は、このようにして送信された督促メールの一例について示した概略図である。図１９では、受諾者宛の通知メールとなっている。図１９に示すように、受諾者宛の督促メールでは、期間が過ぎても本人認証書類が届いていないので、早急に送付して欲しい旨、所定期間（本実施形態では受諾から三週間以内）に送付されないと契約がシステム上認証されないことになり契約書が破棄される旨のメッセージが記載される。契約書が破棄されるとは、削除手段によってタイムスタンプファイルが削除されることである。
また、図２０は、申し入れ者宛督促メールの一例について示した概略図である。図２０に示すように、申し入れ者宛督促メールでは、アップロードされた契約書ファイルの案件について、受諾者から本人認証書類の送付がないので、このままでは契約書が破棄される旨、破棄を望まないのであれば、受諾者に連絡を取り、本人認証書類を送付するよう伝えて欲しい旨のメッセージが記載されている。
【００６４】
次に、削除手段を構成する削除プログラムについて説明する。削除プログラムは、本実施形態では、デジタル契約サーバ４に実装されたプログラムであり、あるタイミングで自動実行されるプログラムとなっている。削除プログラムは、例えば毎日午前１時に自動実行されるようにすることができる。この時刻が到来すると、削除プログラムは、案件情報ＤＢＦの最初のレコードにポインタを移動させる。「受諾者正仮別」のフィールドに仮会員である旨の情報が記録されており、「受諾日時」のフィールドに値があり（Ｎｕｌｌ値ではなく）、受諾日時から三週間（２１日）以上経過しており、且つ「受諾者認証日」のフィールドがＮｕｌｌ値であるかどうか判断する。これらの条件がすべて成立する場合、削除プログラムはそのレコードの案件のタイムスタンプファイルをストレージサーバ６から削除する。即ち、そのレコードの「ファイル保存場所」のフィールドを読み取り、それにしたがってストレージサーバ６の該当ディレクトリからタイムスタンプファイルを削除する。尚、案件情報ＤＢＦのレコード自体は、後で参照する場合もあるので、そのまま残しておく。案件情報ＤＢＦの各レコードには、本人認証書類が届かずにタイムスタンプファイルが削除された案件を特定するための情報を記録するフィールドとして「無認証削除」という名前のフィールドが設けられており、削除プログラムは、このフィールドに真値を記録して削除の記録を残しておく。
【００６５】
削除プログラムは、順次ポインタを次のレコードに移動させ、同様の処理を繰り返す。最後のレコードまで処理が終わると、削除プログラムは終了である。このような削除プログラムにおいて、実際のレコードの削除はストレージサーバ６上のＤＢＭＳが行うので、本実施形態の削除手段は、削除プログラム、デジタル契約サーバ４、ＤＢＭＳ、ストレージサーバ６、管理用クライアント７等によって構成されている。尚、削除プログラムによる削除処理は、法律的には、当事者の一方の本人認証がされなかったということであるので、最初から契約が無かったという扱い（契約不成立擬制）になる。
【００６６】
上記のようなプロセスで処理される各契約案件については、各会員において処理状況を閲覧することが可能となっている。この閲覧には、契約が完了した案件（契約書ファイルにタイムスタンプが付与されて保存されている状態）についての閲覧も含まれる。
図６に示すように、会員トップページは、上から順に四つのエリアに区切られている。即ち、大きくは、上下に「契約未完了一覧」と表記されたエリア（以下、未完了エリア）と「契約完了一覧」のエリア（以下、完了エリア）に分かれている。未完了エリアは、「自分から相手」と表記されたエリアと、「相手から自分」と表記されたエリアに分かれている。「自分から相手」と表記されたエリアは、この会員が申し入れ者として契約書ファイルを送った案件がリスト表示されるエリアである（以下、未完了申し入れ者エリアと呼ぶ）。「相手から自分」と表記されたエリアは、この会員に対して契約が申し込まれた（契約書ファイルが送られた）案件がリスト表示されるエリアである（以下、未完了受諾者エリア）と呼ぶ。完了エリアについても同様であり、「自分から相手」と表記されたエリア（以下、完了済み申し入れ者エリア）には、この会員が申し入れ者である契約案件のうち契約が完了したもののリストが表示され、「相手から自分」と表記されたエリア（以下、完了済み受諾者エリア）には、この会員が契約を申し込まれた案件のうち契約が完了したもののリストが表示されるようになっている。
【００６７】
また、各エリアにおいて、各案件の情報を表示したリストの各行の末尾には、「表示」と記載されたコマンドボタン（表示ボタン）５７と「削除」と記載されたコマンドボタン（削除ボタン）５８がそれぞれ設けられている。表示ボタン５７は、その行の案件の契約書ファイルを表示するものであり、削除ボタン５８は、その案件の情報が会員トップページに表示されないようにするものである。
前述したように、図４に示すトップページにおいてログインボタンがクリックされると、会員ＩＤ及びパスワードが入力するページが表示され、これらが正しく入力されて送信ボタンがクリックされると、会員トッププログラムが起動する。
【００６８】
図２１は、会員トッププログラムの概略を示したフローチャートである。図２１に示すように、会員トッププログラムは、案件情報ＤＢＦを開き、最初のレコードにポインタを移動させる。そして、入力された会員ＩＤをメモリ変数から読み出し、その会員ＩＤが「申し入れ者会員ＩＤ」の値に一致するかどうか判断する。一致する場合には、この会員が契約を申し入れた案件ということになる。この場合、会員トッププログラムは、そのレコードの「受諾日時」の欄がＮｕｌｌ値かどうか判断する。Ｎｕｌｌ値であれば、その案件は受諾者がまだ受諾していない案件である。この場合、会員トッププログラムは、そのレコードの「案件ＩＤ」、「案件名」、「受諾者名前」のフィールドの値をそれぞれ読み出す。そして、会員トップページ表示用のＨＴＭＬファイル（以下、会員トップ用ファイル）の所定の箇所に、「案件名」のフィールドの値と、「受諾者名前」のフィールドの値を嵌め込む。この際の所定の箇所とは、図４に示す未完了申し入れ者エリアである。「受諾日時」のフィールドがＮｕｌｌ値でない場合、受諾者が受諾した案件であるので、会員トッププログラムは、そのレコードの「案件ＩＤ」、「案件名」、「受諾者名前」のフィールドの値をそれぞれ読み出し、完了済み申し入れ者エリアに表示されるよう会員トップ用ファイルに嵌め込む。
【００６９】
一方、そのレコードにおいて、入力された会員ＩＤが「申し入れ者会員ＩＤ」には一致しない場合、会員トッププログラムは、「受諾者会員ＩＤ」に一致するかどうか判断する。一致する場合、その案件は契約を申し入れられた案件ということになる。この場合、会員トッププログラムは、「受諾日時」の欄がＮｕｌｌ値である場合、その案件はまだ受諾していない案件であるので、会員トッププログラムは、そのレコードの案件の「案件ＩＤ」、「案件名」、「申し入れ者名前」のフィールドの値をそれぞれ読み出し、未完了受諾者エリアに表示される会員トップ用ファイルに嵌め込む。また、「受諾日時」がＮｕｌｌ値でない場合、受諾した案件であるので、会員トッププログラムは、そのレコードの「案件ＩＤ」、「案件名」、「申し入れ者名前」のフィールドの値をそれぞれ読み出し、完了済み受諾者エリアに表示される会員トップ用ファイルに嵌め込む。
【００７０】
上記各案件情報の嵌め込みの際、各表示ボタン５７や各削除ボタン５８の嵌め込みも自動的に行われる。より具体的に説明すると、未完了の案件については未完了案件表示プログラムがデジタル契約サーバ４に実装されており、完了済みの案件については完了済み案件表示プログラムがデジタル契約サーバ４に実装されている。会員トッププログラムは、例えば未完了申し入れ者エリアに各案件情報を嵌め込む際、案件ＩＤを引数にして未完了案件表示プログラムを起動するコマンドが埋め込まれた状態で各表示ボタン５７を末尾に嵌め込むようにする。未完了受諾者エリアも同様で、案件ＩＤを引数にして未完了案件表示プログラムを起動するよう各表示ボタン５７を埋め込む。完了済み申し入れ者エリアについては、会員トッププログラムは、案件ＩＤを引数にして完了済み案件表示プログラムを起動するコマンドが埋め込まれた状態で表示ボタン５７を埋め込む。完了済み受諾者エリアについても同様である。また、デジタル契約サーバ４には、特定の案件のレコードを案件情報ＤＢＦから削除する案件削除プログラムが実装されている。各削除ボタンは、その行に表示された案件の案件ＩＤを引数にてい案件削除プログラムを実行するコマンドが埋め込まれた状態で嵌め込まれるようになっている。
【００７１】
会員トッププログラムは、このようにして、いずれかの条件に該当する場合にいずれかのエリアに契約案件の情報が表示されるよう会員トップ用ファイルに情報を嵌め込む。順次ポインタを次ぎのレコードに移動しながら、同様の判断と、該当する場合の情報の嵌め込みを繰り返す。一つのエリアに既に一つの案件の情報が嵌め込まれている場合、次の案件の情報はその下に表示されるようにする。即ち、各案件がリストの形で表示されるようにする。最後のレコードまで処理が終了すると、会員トッププログラムは、各情報を嵌め込んだ会員トップ用ファイルを、アクセスしてきた端末に送って表示させる。これで、会員トッププログラムは終了である。
【００７２】
会員トップページの未完了申し入れ者エリア又は未完了受諾者エリアにおいて、いずれかの表示ボタン５７がクリックされると、その案件の案件ＩＤを引数にして未完了案件表示プログラムが起動される。未完了案件表示プログラムは、案件ＩＤに従ってログ付き契約書ファイルをストレージサーバ６から読み取り、アクセスしてきた端末に送信して表示させる。
完了済み申し入れ者エリア又は完了済み受諾者エリアにおける表示ボタン５７については、タイムスタンプが付与された案件の契約内容の閲覧であるため、上記とは異なる構成となっている。即ち、完了済み案件表示プログラムは、タイムスタンプファイルとしてのタイムスタンプトークンを利用して検証を行いつつログ付き契約書ファイルを表示するプログラムとなっている。
【００７３】
より具体的に説明すると、完了済み案件表示プログラムには、タイムスタンプトークンを利用して検証を行う検証プログラムがプラグインプログラムとして組み込まれている。完了済み案件プログラムは、渡された案件ＩＤに従って該当する案件のログ付き契約書ファイルをストレージサーバ６から読み取って開く。検証プログラムは、ログ付き契約書ファイルを所定のアルゴリズムで暗号化し、ハッシュ値を得る。また、該当する案件のタイムスタンプトークがストレージサーバ６から読み出され、同様に検証プログラムが所定のアルゴリズムでハッシュ値を得る。検証プログラムは、二つのハッシュ値が一致するかどうは判断し、一致すれば改ざんはないとして真正である旨の戻り値を出す。完了済み案件表示プログラムは、真正である旨の戻り値があると、アクセスしてきた端末に対し、読み出したログ付き契約書ファイルにそのファイルが真正である検証された旨のメッセージを添えて送信し、端末に表示させる。尚、万が一ハッシュ値が一致しない場合、真正でない旨の戻り値が出力されるので、完了済み案件表示プログラムは、ログ付き契約書ファイルを送信するが、一致しない旨のエラーメッセージを端末に返信して表示させる。
【００７４】
また、本実施形態のシステムは、システムの利用料を課金する際の特徴的な構成を備えている。以下、この点について説明する。
前述したように、本サイトは会員制であるので、本システムの利用料金は、月額の会員料金（基本料金）がベースになっている。そして、これに利用量に応じた料金（従量料金）が付加される料金体系になっている。基本料金は、正式会員としての登録がされたときから課金され、退会するまで課金される。従量料金の課金において特徴的なのは、契約金額に応じた額の課金や情報の保存期間に応じた額の課金がされるようになっている点である。
【００７５】
より具体的に説明すると、図８に示すように、案件情報入力ページには、契約金額入力欄５９が設けられている。また、図５に示すように、案件情報ＤＢＦの各レコードには、「契約金額」のフィールドが設けられている。図８に示す送信ボタン４９がクリックされると、アップロードプログラムは、契約金額入力欄５９に入力されている数字を案件情報ＤＢＦの当該レコード（新規に追加したレコード）の「契約金額」のフィールドに記録するようになっている。
【００７６】
一方、図１６に示すように、管理用メニューページには、「契約金額課金処理」と表記されたコマンドボタン（以下、契約金額課金処理ボタン）６１が設けられている。契約金額課金処理ボタン６１には、契約金額に応じた課金処理を行うためのページ（以下、契約金額課金処理ページ）へのリンクが埋め込まれている。
契約金額課金処理ページは、図示は省略するが、契約が成立した案件（受諾ボタンがクリックされた案件）であって契約金額課金処理がされていない案件の情報がリスト表示されるようになっている。具体的には、案件情報ＤＢＦには、契約金額課金処理が済んだことを示す情報を記録するフィールド（図５中不図示）が設けられており、このフィールドに偽値が記録されていて且つ受諾日がＮｕｌｌ値ではないレコードを検索してリスト表示するプログラムがデジタル契約サーバに実装されている。
【００７７】
契約金額課金処理ページに表示されたリストの各行には、「契約金額チェック」と表記されたコマンドボタンが設けられている。このコマンドボタンには、該当する案件の契約書ファイルに記載された契約金額(以下、ファイル内記載金額）と、案件情報入力ページで入力された契約金額（案件情報ＤＢＦに記録されている契約金額、以下、入力金額）との間に違いがないかチェックするためのプログラム（以下、契約金額チェックプログラム）起動コマンドが埋め込まれている。契約金額チェックプログラムについては、幾つかの異なった構成が考えられるが、例えば、入力金額の数字に一致するテキストが契約書ファイル内にあるかどうかテキスト検索するプログラムが考えられる。契約金額は契約書に必ず記載されるものであるから、案件情報入力ページで正しく入力されていれば、同一のテキスト（契約金額の数字）が契約書ファイル内に存在する筈である。したがって、曖昧検索等の機能を適宜使用しながら、同一のテキストがあるかどうか判断し、あれば、入力金額が正しいとする。
【００７８】
もし、検索の結果、同一テキストが契約書ファイル内にないと判断された場合、契約金額チェックプログラムは、契約金額の訂正入力ページを管理用クライアント７に表示する。訂正入力ページには、入力金額とファイル内記載金額が一致しなかった旨のメッセージを表示するととにに、契約書ファイルを管理用クライアント７を別ウインドウで表示するコマンドボタンと、契約金額を訂正して入力する訂正入力欄が設けられている。担当者は、契約書ファイルの内容を別ウインドで見ながら、正しい契約金額を確認し、訂正入力欄に入力する。訂正入力ページには、登録ボタンが設けられており、登録ボタンがクリックされると、訂正入力欄で入力された金額が当該案件のレコードの「契約金額」の欄に上書きされて登録されるようになっている。
【００７９】
入力金額とファイル内記載金額の整合性チェックについては、上記テキスト一致で判断するやり方の他、入力金額が消費税抜きで入力され、ファイル内記載金額が税込みで記載されている可能性もあるので、入力金額に消費税を加算した上で一致するものがあるか検索するようにしても良い。また、入力金額が年額で入力され、ファイル内記載金額が月額で記載されている場合もあるので、入力金額を１／１２した上で一致するものがあるかどうか検索するようにしても良い。消費税を加算した上での検索や１／１２にした上での検索も、プログラムによって自動化できるのは勿論である。
【００８０】
また、図８に示すように、案件情報入力ページには、情報保存期間入力欄６０が設けられている。また、案件情報ＤＢＦの各レコードには、「情報保存期間」のフィールド（図５中不図示）が設けられている。情報保存期間とは、契約に関する情報の保存期間であるが、重要なのはタイムスタンプファイルであり、その保存期間ということである。この他、案件情報ＤＢＦにおける当該レコードの保存期間も含めることがある。図８に示す送信ボタン４９がクリックされると、アップロードプログラムは、情報保存期間入力欄６０に入力されている値を案件情報ＤＢＦの当該レコード（新規に追加したレコード）の「情報保存期間」のフィールドに記録するようになっている。
【００８１】
一方、図１６に示すように、管理用メニューページには、月次請求処理と表記されたコマンドボタン（以下、月次請求ボタン）６２が設けられている。月次請求ボタン６２には、デジタル契約サーバに実装されている月次請求プログラムの起動コマンドが埋め込まれている。
本実施形態では、正式会員登録をしていることによる料金は無料で、システムの利用があった場合（システムを利用して契約を締結させた場合）のみ利用料金がかかる取り決めとなっている。即ち、月次請求プログラムは、各会員ＩＤを順次検索キーにして案件情報ＤＢＦを検索し、その月のシステム利用がされているかどうかレコードの情報から判断し、利用がされている場合のみ課金用ファイルを生成して課金情報を記録するプログラムとなっている。
【００８２】
より具体的に説明すると、月次請求プログラムは、会員情報ＤＢＦに記録されている最初の会員ＩＤを検索キーにして案件情報ＤＢＦを検索し、その月に新たに成立した案件のレコード（「受諾日」の値が〆月の期間に入っているレコード）があるかどうか判断し、あれば、課金用ファイルを新たに生成する。課金用ファイルは、例えばストレージサーバ６の保存部に保存されるファイルである。そして、契約金額に応じた利用料金と、情報保存期間に応じた従量料金とを課金用ファイルに記録する。即ち、「契約金額」のフィールドの値を読み取り、その金額に一定の割合（例えば３％）を乗じた金額を利用料金とする。保存期間に応じた料金としては、例えば、３年までは定額の５千円とし、以降は１ヶ月当たり１０円というような従量料金が考えられる。この場合、「情報保存期間」のフィールドには、３年を越える分の月数が記録されるようにしておき、月時請求プログラムがその値を読み出して従量料金を自動計算する。このようにして算出ないし決定した契約金額依存料金と保存期間依存料金とを、生成した課金用ファイルに記録する。
【００８３】
月次請求プログラムは、案件情報ＤＢＦ内の全てのレコードを検索し、別の案件についてその月に新たに成立していればその案件についても契約金額依存料金と保存期間依存料金を算出ないし決定し課金用ファイルに追加して記録する。すべてのレコードについて検索した後、次に、案件情報ＤＢＦの最初のレコードに戻り、今度は受諾者会員ＩＤが一致するレコードがあるかどうか検索する。一致するレコードがあれば、受諾者としての利用料金（これについては従量料金はない）を課金用ファイルに追加して記録する。尚、申し入れ者としての利用が無く受諾者としての利用のみの場合には、ここで新たに課金用ファイルを生成し、課金情報を記録する。受諾者会員ＩＤについても同様に全てのレコードに検索を行い、別の一致するレコードがあれば、同様に受諾者としての利用料金を課金用ファイルに追加して記録する。
【００８４】
このようにして一つの会員ＩＤについて利用の有無のチェックと利用がある場合の利用料金の課金用ファイルへの記録をした後、月次請求プログラムは、会員情報ＤＢＦに記録されている次の会員ＩＤについて、同様に案件情報ＤＢＦを検索し、利用がある場合の課金用ファイルの生成と記録とを同様に行う。
月次請求プログラムは、上記のような作業を全ての会員ＩＤについて行う。そして、各課金用ファイルにおいてその月の合計の請求金額が計算され、各課金用ファイルが各会員宛の請求書としてそれぞれ印刷されると、月次請求プログラムは終了である。
尚、上記例において、受諾者の利用料金についても、契約金額に応じた料金としても良いし、情報保存期間に応じた料金を追加しても良い。また、システムの利用の有無にかかわらず、正式会員登録をしている限り基本料金を課金するようにしても良い。さらに、基本料金は、仮の会員登録の時点から発生するとしても良い。
【００８５】
以上説明した構成を有する本実施形態のデジタル契約システムの動作について、以下に説明する。申し入れ者は、本人認証書類を運営会社に送って予め正式な会員登録をしておく。そして、受諾者との間で契約内容に合意したらワープロソフトを使用してデジタルファイルとしての契約書ファイルを作成する。契約書ファイルは、弁護士のような専門家が作成する場合もある。作成された契約書ファイルは、申し入れ者が操作する第一の端末３１のの保存部（ハードディスクやＵＳＢメモリ等）に保存される。また、本システムの利用に際しては受諾者も少なくとも仮の会員登録をしていることが必要であり、申し入れ者は受諾者に対してこの点を伝え、本サイトにアクセスして仮会員登録をしておくよう要請する。受諾者は、この要請に応じて仮会員登録をする。受諾者は、この際に入力、送信した自分のメールアドレス（会員ＩＤ）を申し入れ者に伝えておく。また、自分で設定した任意の仮パスワードは、後のアクセスの際や正式会員登録の際に必要になるので、忘れないようにしておく。
【００８６】
申し入れ者は、第一の端末３１を操作し、ブラウザによりインターネット１を介してデジタル契約サイトにアクセスし、図２に示すトップページにおいてログインボタン４２をクリックする。そして、会員ＩＤ及びパスワード（正式なパスワード）を入力して本人認証された正式な会員としてログインする。
ログイン後に第一の端末３１に表示される会員トップページ（図３）において、契約書登録ボタン４４をクリックする。そして、表示されるファイルアップロードページ（図７）において、ファイル選択欄の参照ボタン４５をクリックして契約書ファイルを指定した後、アップロードボタン４６をクリックする。そして、表示される案件情報入力ページで、案件名や受諾者メールアドレスを入力する。受諾者メールアドレスは、受諾者の会員ＩＤ（正式又は仮）としてのメールアドレスである。
【００８７】
申し入れ者は、案件情報入力ページで所定事項を入力した後、送信ボタン４９をクリックし、アップロードプログラムを起動させる。アップロードプログラムは、契約書ファイルを第一の端末３１からデジタル契約サーバ４に送信させ、デジタル契約サーバ４は、送信された契約書ファイルをマスタファイルとしてストレージサーバ６の保存部に保存する。そして、入力された案件情報は、案件情報ＤＢＦに追加される新規レコードに記録される。次に、アップロードプログラムは、契約書ファイルのＨＴＭＬファイルへの変換と受諾ボタン５０の埋め込みを行い、変換済み契約書ファイルをストレージサーバ６の保存部に保存する。その後、アップロードプログラムは、通知メール（図１１）の生成と受諾者のメールアドレスへの送信を行い、さらに契約書ファイルへのログ記録を行い、ログ付き契約書ファイルをストレージサーバ６の保存部に保存する。
【００８８】
受諾者は、第二の端末３２において通知メールを受信し、通知メールの内容を確認する。そして、記載されているＵＲＬをクリックする。この結果、閲覧用認証ページ（図１３）が第二の端末３２に表示される。受諾者は、閲覧用認証ページにおいて会員ＩＤ及びパスワードを入力する。受諾者が仮会員登録の段階である場合には仮パスワードを入力し、正式会員である場合、正式会員としてのパスワードを入力する。
会員ＩＤ及びパスワードが正しく入力されて送信ボタン５１がクリックされると、契約書ファイル閲覧プログラムが動作し、第二の端末３２宛に該当案件の変換済み契約書ファイルが送信される。受諾者は、第二の端末３２上に表示される変換済み契約書ファイルを閲覧し、契約内容を確認する。契約内容が受諾できるようであれば、受諾ボタン５０がクリックされる。これにより受諾処理プログラムが動作し、受諾の旨を案件情報ＤＢＦの該当レコードに記録するとともにログ付き契約書ファイルにログ記録を追記してファイルを更新し、さらにタイムスタンプ手段にタイムスタンプ要求を送信する。タイムスタンプ手段は、送信されたハッシュ値に時刻情報を統合してタイムスタンプトークンを返信する。受諾処理プログラムは、受信したタイムスタンプトークンをタイムスタンプファイルとしてストレージサーバ６に保存する。
【００８９】
受諾者が仮会員登録の段階である場合、受諾者は所定期間内に本人認証書類を運営会社に送付する。運営会社の担当者は、送付された本人認証書類を確認し、本人認証できると判断した場合は、管理用クライアント７を操作し、認証書類受領情報の登録を行う。これで、一連のデジタル契約手続きが終了したことになる。
受諾者が仮会員登録の段階であり、且つ所定期間内に本人認証書類が届かない場合、督促メール送信手段により督促メールが受諾者と申し入れ者の双方に送信される。その後の所定期間内に本人認証書類が届けば、上記のように認証書類受領情報登録が行われるが、届かない場合、削除手段が自動的にタイムスタンプファイルを削除し、案件情報ＤＢＦには契約不成立擬制の旨の情報が登録される。
【００９０】
上記のようなデジタル契約手続きのステップを踏みながら、正式会員である場合、会員トップページに適宜アクセスし、自分が関わっている契約案件の進捗状況を閲覧する。即ち、図２に示すトップページでログインボタン４２をクリックし、会員ＩＤ及びパスワードを入力して会員トップページを端末に表示する。そして、例えば自分が申し入れ者で、未完了のものの契約内容を確認したいのであれば、未完了申し入れ者エリアに表示されている案件のうちいずれかの案件を表示した行における表示ボタン５７をクリックする。これにより、その案件のログ付き契約書ファイルが端末に表示される。自分が受諾者である案件の場合には、未完了受諾者エリアに表示されているいずれかの表示ボタン５７をクリックする。
【００９１】
また、自分が申し入れ者で契約済みの案件については、完了済み申し入れ者エリアのいずれかの案件の表示ボタン５７をクリックする。これにより、完了済み案件表示プログラムが起動し、検証プログラムが実行されて改ざんが無いかどうかを表示しつつログ付き契約書ファイルが端末に表示される。自分が受諾者である場合、完了済み受諾者エリアのいずれかの案件の表示ボタン５７をクリックする。
何らかの事情で契約を破棄した場合や、管理の必要が無くなった案件については、会員において適宜削除処理をする。即ち、図６に示す会員トップページにおいて、削除する案件の削除ボタン５８をクリックし、情報を案件情報ＤＢＦから削除する。尚、会員情報ＤＢＦとしてマスターデータと会員用のデータの二つを容易しておき、案件削除プログラムは、会員用のデータの方だけにおいてレコードを削除するようにしても良い。この場合、会員トッププログラムは、会員用のデータに基づいて会員トップページを表示するようプログラミングされる。
【００９２】
以上の構成及び動作に係る本実施形態のデジタル契約システムによれば、デジタル契約書によって契約が取り交わされ、デジタル契約書を保管する形なので、契約案件の管理や整理が容易である。その上、デジタル契約書はタイムスタンプが付与されて保存されるので、ある時点において確かに契約が成立し契約書が存在したことや契約書が改ざんされていないことの証明について高い信頼性が得られる。
また、相手側が仮会員登録の段階、即ち本人認証をしていない段階でも契約書をアップロードして相手側に受諾ボタンをクリックさせてタイムスタンプを付与することが可能であり、システム上で契約を締結することが可能である。その場合も、所定期間内に本人認証書類が届かない案件についてはタイムスタンプファイルを削除して契約が無かったことにできるので、問題は生じない。
【００９３】
前述したように、従来のデジタル契約の場合、契約に先立って電子証明書を取得しておく必要があり、そのためには認証局に本人認証書類を事前に送って電子証明書を発行してもらう必要がある。このために手間がかかり、契約成立のチャンスを逃してしまうこともあり得る。即ち、ある案件について上記のようなメリットがあるためにデジタル契約にしょうとし、受諾者にその旨を伝えたとする。この際、受諾者は電子証明書を取得していないと従来はデジタル契約できない。このため、電子証明書の取得を面倒がり、契約を見合わせてしまうこともある。そうなるとまずいので、申し入れ者も従来の書面での契約を選択することになってしまい、デジタル契約のメリットを享受することができなくなる。一方、本実施形態では、受諾者側が仮会員登録の段階でも契約を締結することができるので、このような問題はない。尚、仮会員登録の段階でも契約を締結することができるという点は、本システムの利用のハードルが低いことを意味し、その普及を促進する効果もある。
【００９４】
また、本実施形態では、受諾者が仮会員登録の場合であって所定期間内に本人認証書類が届かない場合にはタイムスタンプファイルを自動的に削除する削除手段が設けられているので、本人認証書類が届かない案件のタイムスタンプファイルをいちいち削除する手間が省ける。そして、所定期間内に本人認証書類が届かない案件について督促メールが自動で送られるので、いちいち督促メールを手動で送る手間が省ける。さらに、督促メールは、申し入れ者にも送信されるので、申し入れ者からも本人認証書類の送付を要請してもらうことができる。このため、契約不成立擬制の扱いになってしまう可能性を少なくすることができる。
【００９５】
尚、タイムスタンプ付き契約書ファイルは、紙の契約書を保管していた場合とほぼ同等の法律的効果を持つし、税務上も同様の証拠価値を有する。この際、タイムスタンプ付き契約書ファイルは、印紙税法上の「文書」には該当しないので、印紙を貼る必要がない（物理的に貼ることができない）。つまり、印紙代がかからない点で低コストになる。この点は、日常的に大量の契約を取り交わしている会社や個人にとって極めて有益である。尚、上述したように、本実施形態では、会員登録自体にかかる料金は無料で、システムの利用に応じた金額のみが請求される仕組みとなっている。この利用料金を、印紙税よりも十分に安い金額（例えば印紙税の半額）としておけば、システムの利用は一層促進されるものと考えられる。
【００９６】
また、上記実施形態では、契約書ファイル内に当該契約書ファイルをアップロードしたログ記録（誰がいつアップロードしたか）と、当該契約書ファイルの内容について受諾者が受諾した旨のログ記録（誰がいつ受諾したか）とが書き込まれ、これらログ記録を含んだ状態で契約書ファイルのタイムスタンプ要求がされている。これは、契約の成立（申し入れの意思表示と受諾の意思表示）を示す情報とその契約内容の情報の双方についてタイムスタンプを要求しているのであり、それらについてタイムスタンプファイルが返信され、それが保存される。即ち、契約の存在とその内容の否改ざん性のみならず契約の成立自体についてもタイムスタンプで立証されることになる。このため、本システムの利用価値は極めて高くなっている。
【００９７】
そして、上記ログ記録には、契約書ファイルの送信元である第一の端末３１の端末識別情報としてのＩＰアドレスの記録が含まれており、また受諾の旨を送信した第二の端末３２の識別情報としてのＩＰアドレスの記録が含まれている。即ち、誰がどの端末を使用して申し入れを行い、誰がどの端末を使用して受諾したかという情報が記録され、そについてタイムスタンプが付与されるようになっている。したがって、端末の特定についてのタイムスタンプで立証されるので、本システムの利用価値がさらに高くなっている。つまり、Ａというものが、例えば111.222.33.44というＩＰアドレスの端末を保有していたことが判っていて、タイムスタンプ付きの契約書ファイルに、1111.222.33.44からその契約書ファイルが送信された旨が記録されていれば、Ａという者がその契約書ファイルを送信したことの蓋然性が高いと推認されるのである（そのこと自体、契約書ファイルにログ記録されているが）。 尚、端末識別情報としてＩＰアドレスではなくマックアドレスをログ記録するようにしても良い。
【００９８】
また、契約の成立に関するタイムスタンプについては、契約書ファイルと別のファイルとで行うようにすることも可能である。例えば、契約書アップロードのログ記録をしたファイルと、契約について受諾した旨のログ記録をしたファイルとを別に設け、契約書ファイルとともにこれらファイルについてタイムスタンプ要求を発しても良い。アップロードのログ記録ファイルと受諾のログ記録ファイルとは一つのファイルにしても良い。このような技術構成によっても同様の結果が得られる。但し、契約書ファイルとログ記録ファイルとについて内容を関連づける技術手段が別途必要である。例えば、ログ記録ファイルとの双方に案件ＩＤが自動的に書き込まれるようにし、案件ＩＤで関連づける構成である。上記実施形態の構成は、このような関連づけが不要な点で技術構成がシンプルになるメリットがある。
【００９９】
上記実施形態では、申し入れ者（契約書ファイルをアップする者）は正式会員でなければならない（本人認証されていなければならない）としたが、仮会員登録の段階でも可能とするようにしても良い。この場合も、所定期間内に本人認証書類が届かない場合、申し入れ者宛に督促メールが届くようにし、それでも本人認証書類が届かない場合、削除手段がタイムスタンプファイルを削除して案件情報ＤＢＦに無認証削除の登録をするようにする。この場合は、受諾者に削除した旨を通知する方が好ましい。尚、申し入れ者が仮会員登録の段階で契約書ファイルをアップする場合、受諾者は正式会員登録をしている場合もあり、また受諾者も仮会員登録の段階である場合もある。後者の場合、双方の本人認証書類が所定期間内に届かない限り、タイムスタンプファイルは削除され、契約不成立擬制の扱いということになる。
【０１００】
尚、本人認証書類が届かない状態でタイムスタンプファイルを保存したままとしておくこと（契約不成立擬制をしないこと）の問題として、幾つかの重要な問題が考えられる。例えば、実在しない人物の名前で契約をしたり（架空契約）、他人の名前で勝手に契約したり（成りすまし）、という問題である。別の問題としては、申し入れ者が受諾者の名前を勝手に入力して送信する場合である（受諾者の名前は架空の場合もあり、自在する人の名前を勝手に入力する場合もある）。これは、いわば契約のでっち上げということになる。いずれの場合も、真正な本人認証書類を運営会社に送ることができないので、タイムスタンプファイルは削除され、契約不成立擬制という扱いになる。本実施形態の削除手段は、上記のような悪意のある違法なシステムの利用を防止するという点で重要な技術的意義を有する。
【０１０１】
本願発明のデジタル契約システムで提供されるサービス（本サービス）は、上記実施形態のようにそれ専門のウェブサイトにおいて提供される場合の他、あるサイトの付帯サービスとして提供することも可能である。この場合、このあるサイト（以下、便宜上、通常サイトと呼ぶ）において商品又はサービスが顧客に提供されていて、その商品又はサービスの提供において顧客との間で契約を結ぶ場合のように、この通常サイトの運営者自体が契約の当事者の場合があり得る。この場合の好適な構成としては、顧客側から見た場合、その通常サイトにおいて本サービスが提供されているかのようにすることが考えられる。この構成の一例について、以下に説明する。
【０１０２】
上記のような構成の一例として、本サービスをいわゆるＡＳＰとして通常サイトの運営者に提供することが考えられる。即ち、上記アップロードプログラム等の各種プログラムや会員トップページ等の各ページを提供する各ＨＴＭＬファイルを通常サイトの運営者に提供し、自己のサーバに実装してもらうようにすることが考えられる。この場合は、通常サイトの運営者において本願発明のデジタル契約システムが構築されることになる。別の構成としては、サーバは、本サービスを提供する運営会社のものとしておき、通常サイトのサーバ（以下、提供先サーバ）から本サービスの運営会社のサーバ（以下、提供元サーバ）に遷移させて本サービスを提供することができる。この場合に好適なのは、顧客側にはサーバ遷移を意識させないようにすることであり、恰も通常サイトにおいて本サービスが提供されているように見せることである。
【０１０３】
図２２を使用して、より具体的に説明する。図２２は、本願発明の別の実施形態の主要部を示した概略図である。図２２に示す例は、通常サイトが不動産仲介会社のサイトとなっている。
図２２（１）に示すように、この提供先サイトのあるページには、「デジタル契約システムログイン」と表記されたコマンドボタン（ログインボタン）５４が設けられており、ログインボタン５４をクリックすることで、本人認証ページが表示され、会員ＩＤ及びパスワードが正しく入力されて送信ボタンがクリックされると、図２２（２）に示すデジタル契約のページ（以下、契約ページ）が表示されるようになっている。
【０１０４】
図２２（１）のページ自体は、提供先サーバによって提供されているものであるが、本人認証ページや図２２（２）の契約ページは、提供元サーバによって提供されている。即ち、図２２（１）のページのログインボタン５４には、提供先サーバへのリンクが埋め込まれており、提供先サーバに保存された本人認証ページを開くコマンドが埋め込まれている。
この場合、図２２（１）と（２）とを比較すると分かるように、端末に表示されるページで異なるのは、中央の大きなフレーム（メインフレーム）内の情報のみであり、その他のメニューバー等は全く同じように表示されるようになっている。これは、通常サイトの運営者からＨＴＭＬファイルを提供してもらい、メインフレーム内の情報のみを提供元で書き換えて提供しているからである。
契約ページのコンテンツ自体は、図７に示すファイルアップロードページや図８に示す案件情報入力ページと同様である。契約書ファイルを指定し、相手先のメールアドレスを案件情報として入力した上で送信ボタン５５をクリックするページとなっている。
【０１０５】
また、ログイン後には、自分が関与している案件の状況を閲覧できるようになっている。即ち、契約ページには、「状況閲覧」と表示されたコマンドボタン（以下、状況閲覧ボタン）５６が設けられている。状況閲覧ボタン５６をクリックすると、各案件の状況が閲覧できるようになっている。状況閲覧のためのページについては、図示は省略するが、図６に示す会員トップページと同様であり、完了、未完了に分け、さらに申し入れ者、受諾者に分け、四つのエリアにおいて契約案件がリスト表示されるようになっている。そして、アップロードボタン等も同様に設けられている。
【０１０６】
このような構成の利用例について説明すると、例えば、顧客が不動産仲介会社の営業所を訪れ、不動産の説明を受け、売買契約を結ぶことを決心したとする。担当者は、営業所の窓口に設置されている第一の端末３１を操作し、デジタル契約サイトにアクセスする。そして、顧客からメールアドレスを聞き、顧客の仮会員登録をする。この際、顧客に任意の仮パスワードを決めてもらい、それを入力して会員情報ＤＢＦに登録されるようにする。いったんログアウトした後、不動産仲介会社の会員ＩＤ及び正式パスワードでもう一度ログインを行う。そして、契約書ファイルを選択した上で送信ボタンをクリックし、契約書ファイルをアップロードする。この際、相手先メールアドレスとして、仮会員登録の際に入力したメールアドレスを入力する。アップロードプログラムは、前述したようにログ付き契約書ファイルの保存や通知メールの送信等を行う。
【０１０７】
顧客は、自宅に戻り、パソコンで通知メールを受信し、記載されているＵＲＬをクリックしてサイトにアクセスする。この際、営業所で決めた仮パスワードを入力し、ログインする。そして、変換済み契約書ファイルをダウンロードして受諾ボタン５０をクリックする。この結果、受諾処理プログラムが動作し、タイムスタンプ要求が送信されてタイムスタンプファイルがストレージサーバ６に保存される。契約はこれで成立したことになり、その後、顧客が本人認証書類を提供元の会社に送る。これにより、システムがタイムスタンプファイルを削除して契約不成立擬制をすることが避けられる。尚、本人認証書類については、顧客が提供先会社（不動産仲介会社）に提出し、提供先会社が書類を確認した上で提供元会社に転送するようにしても良い。
尚、不動産仲介会社の担当者が第一の端末１を操作して各契約案件の状況を閲覧する際には、状況閲覧ボタン５６がクリックされるが、他の顧客の情報が見られれしまうのは適切ではないので、第一の端末３１のディスプレイが顧客の目に触れない状態で行われることが好ましい。
【０１０８】
上記各実施形態において、仮会員登録における仮パスワードの性質について説明する。上記説明から解るように、仮パスワードは、本人認証をしていない段階で発行されるものであり、高い融通性を持たせることは好ましくない。このため、上述した各実施形態では、一契約案件限りにおいてのパスワードとしている。即ち、会員情報ＤＢＦの各レコードに「使用有無」のフィールドが設けられており、このフィールドの値をチェックすることによって過去に使用歴のある仮パスワードについては使用できない（真正とは判断しない）構成となっている。
【０１０９】
仮パスワードが他の案件でも使えるようになってしまう場合の問題は、幾つか考えられる。例えば、ある案件で契約の受諾者となり、仮会員登録のために任意の仮パスワードを自分で設定してシステムに登録したとする（又はシステムで自動生成されてシステムから通知されたとする）。その案件については仮パスワードでアクセスして変換済み契約書ファイルをダウンロードして受諾ボタンをクリックするのであるが、この仮パスワードがシステム上で他の案件にも使えるようなものであるとすると、この者は仮パスワードで別の案件の契約書ファイルをアップロードできることになる。この場合、その別の案件についても所定期間内に本人認証書類が届かない限り削除するようにシステムを構成すれば良いのであるが、システムの構成が複雑になる問題があるし、悪意を持った者が仮パスワードの段階で大量に契約書ファイルをアップロードしてシステムに攻撃を加えるような事態も考えられる。このような点を考慮し、上記各実施形態では、一つの契約案件の受諾者という場合についてのみ、仮パスワードが有効であるようにしている。
【０１１０】
但し、本システムの利用を促進するため、正式会員登録の前の仮登録の段階で契約書ファイルのアップロードを認めることもあり得る。即ち、前述したように、正式会員になるために仮会員登録をするが、この段階で契約書ファイルのアップロードが可能なようにシステムを構成することもできる。この場合も、所定期間内に本人認証書類が届かない場合には、真正な本人からの契約の申し入れが無かったと扱うことになり、タイムスタンプファイルは削除される。また、仮パスワードの段階での契約書ファイルのアップロードについては、申し入れ者の正式会員登録（本人認証）が済んだ後に受諾者への通知メールを送信するとか、又はタイムスタンプ要求を送信するというような構成とすることがより好ましい。尚、仮会員登録の段階で何件もの契約書ファイルをアップロードできるとすると、上述したような悪意の利用が考えられるので、１件のみの契約書ファイルのアップロードに限るようにすることが好ましい。
【０１１１】
尚、上記説明から解るように、本願発明の実施形態としては、申し入れ者も受諾者も仮会員登録の段階で為される構成が採用されることもある。この場合は、双方について所定期間内に本人認証書類が届かなければ、タイムスタンプファイルを削除して契約不成立擬制の扱いをすることになる。
【０１１２】
また、仮パスワードの融通性を下げる技術構成としては、上記の他、仮パスワードの有効時間を設定し、この時間内にアクセスが無かったら仮パスワードを無効とすることも考えられる。具体的には、通知メール内のハイパーリンクがクリックされてデジタル契約サーバ４にアクセスがあった際、そのセッション日時を取得し、その日時と、案件情報ＤＢＦに記録されているアップロード日時とを比較して、それが所定時間内（例えば２４時間内）でなければ、その仮パスワードは真正ではないとするようにプログラミングすることが考えられる。もしくは、仮会員登録の際の日時が会員情報ＤＢＦの当該レコードに記録されるようにし、仮会員登録の日時と比較して所定時間内であればその仮パスワードが真正であるとようプログラミングしても良い。
【０１１３】
また、別の例としては、第一の端末３１から契約書ファイルをアップロードしたセッションが維持されている場合に限り、仮パスワードが有効であるとすることもできる。例えば、不動産仲介会社の例で言えば、受諾者は仮会員登録の際に自分の携帯電話のメールアドレスを会員ＩＤとして送信して登録しておき、契約書ファイルのアップロードの際、このアドレスを相手先メールアドレスとして入力する。アップロードプログラムは、契約書ファイルのアップロード送信のセッションにおいて、アクセスの環境変数からセッションを特定できる情報（例えば送信元のＩＰアドレスとセッション開始日時）を取得してメモリ変数に格納しておく。通知メールは顧客の携帯電話に届き、顧客は、届いた通知メールを開いて同様に受諾ボタンをクリックする。この間、担当者は、会員トップページからログアウトしないように（セッションを維持するように）しておく。受諾情報処理プログラムは、デジタル契約サーバ４に対して維持されている全アクセスをチェックし、ＩＰアドレスとセッション開始日時がメモリ変数のものと一致するかどうか判断する。一致するものがあれば、セッションが維持されているとして、その仮パスワードが真正であるとする。
【０１１４】
上記各実施形態では、会員情報ＤＢＦは認証サーバ５に保存され、契約書ファイルや案件情報ＤＢＦ等の契約に関する情報はストレージサーバ６に保存されるよう構成された。これは、会員情報ＤＢＦは個人情報やパスワード等の個人情報を記録しているため、より高いセキュリティを確保する必要があるからであるが、会員情報ＤＢＦ等をストレージサーバ６に保存するようにしストレージサーバ６に認証サーバ５の役割も持たせる構成が採用されることもある。
【０１１５】
また、上記各実施形態では、削除手段はタイムスタンプファイルを自動的に削除するものであったが、自動的ではない構成もあり得る。例えば、本システムの運営会社の担当者が管理用クライアント７を操作し、あるトリガーとなる信号をデジタル契約サーバ４に送り、これによってサーバ上の削除プログラムが動作する構成であっても良い。また、所定期間過ぎても本人認証書類が届いていない案件を随時チェックし、管理用クライアント７を操作して一件ずつ削除する構成であっても良い。この場合、削除手段は、管理用クライアント７と、レコードを特定して削除するストレージサーバ６上のＤＢＭＳとによって構成される。
【０１１６】
尚、契約書ファイル、ログ付き契約書ファイル、タイムスタンプファイルの保存や読み出しについては、ストレージサーバ６内の場所の情報（ディレクトリ）を案件情報ＤＢＦに登録して利用する場合の他、ファイル名の付け方をルール化し、それに従って保存や読み出しをするようにしても良い。例えば、契約書ファイルのファイル名として案件ＩＤを兼用するとのルールを設定し、それに従って契約書ファイルの保存や読み出しをするようにする。
【０１１７】
また、上記各実施形態において、契約書アップロードに際して受諾者が少なくとも仮会員登録されていなければならず、仮会員登録は受諾者が予め自ら第二の端末３２により行うと説明したが、受諾者の仮会員登録を申し入れ者がやるようにしても良い。以下、この実施形態について説明する。
図２３は、受諾者の仮会員登録を申し入れ者ができるようにした実施形態における案件情報入力ページの一例の概略図である。図２３に示すように、この実施形態では、受諾者が会員登録されていない場合には仮会員登録をして欲しい旨のメッセージが表示されるようになっており、受諾者が会員登録されていない場合に仮会員登録させるためのコマンドボタン（以下、受諾者仮会員登録ボタン）４７が設けられている。受諾者仮会員登録ボタン４７には、相手先会員登録ページへのリンクが埋め込まれている。
【０１１８】
図２４は、相手先会員登録ページの一例について示した概略図である。図２４に示すように、相手先会員登録ページには、まず、ここでの会員登録は仮のものであり、正式には受諾者から本人認証書類（法人であれば登記簿謄本＋印鑑証明、個人であれば住民票＋印鑑証明）の提出が必要な旨のメッセージが表示される。そして、相手先会員登録ページには、受諾者についての各情報（法人・個人の別、名前、住所等）を入力する欄がそれぞれ設けられている。相手先会員登録ページには、確認ボタン４８が設けられており、確認ボタン４８には、確認ページへのリンクが埋め込まれている。確認ページでは、入力された情報が確認のために表示されるようになっているとともに、登録ボタンが設けられている。登録ボタンには、入力された情報をメモリ変数に一時的に格納するとともに会員情報ＤＢＦに新規レコードを追加して登録するプログラム（受諾者仮会員登録プログラム）の起動コマンドが埋め込まれている。
【０１１９】
受諾者仮会員登録プログラムは、追加した新規レコードの各フィールドに、相手先会員登録ページで入力された情報を記録して登録する。この際、会員ＩＤについては、同様にメールアドレスを兼用するが、メールアドレスは申し入れ者が入力しておりメモリ変数に格納されているので、それを読み出して会員情報ＤＢＦの新規レコードに記録する。また、この新規レコードの「正仮種別」のフィールドには、仮会員登録である旨の情報が記録される。受諾者仮会員登録プログラムは、次に仮パスワードを自動生成し、会員情報ＤＢＦの新規レコードの「仮パスワード」のフィールドに記録すれば、終了である。その後、案件情報入力ページに戻り、送信ボタン４９をクリックして契約書ファイルをアップロードする。尚、正式会員の者を誤って仮会員登録してしまないよう、入力されたメールアドレスで最初に会員情報ＤＢＦを検索し、正式会員登録されている者であるかどうかチェックし、正式会員登録されていれば、その旨のエラーメッセージを送信してプログラムを終了するようにすることが望ましい。
【０１２０】
この実施形態では、通知メールには、申し入れ者によって仮会員登録された旨と、自動生成された仮パスワードとが記載されている。そして、契約書ファイル閲覧用のＵＲＬが記載されているとともに、アクセスした際には仮パスワードを入力してログインして欲しい旨が記載されている。受諾者は、記載されている仮パスワードを入力してログインした後、契約書ファイルを閲覧する。
【０１２１】
この実施形態では、仮パスワードをメールで通知するので、セキュリティの面で多少問題がある。この問題を無いようにした構成として、仮パスワードを自動生成するのではなく、やはり受諾者において任意に設定してもらうようにする構成が考えられる。即ち、通知メールを受けて受諾者がアクセスした際、ログイン画面で任意のパスワードを設定するようにしても良い。また、個人情報の入力についても、申し入れ者が行うのではなく、通知メールを受けた受諾者が契約書ファイルの閲覧のためにアクセスした際に行う構成であっても良い。但し、申し入れ者が受諾者の個人情報を入力する構成の方が、受諾者の労力が少なくて済み、申し入れ者が受諾者に対して本システムの利用を促すという意味では（本システムの普及を促進する意味では）好適である。
尚、上記各実施形態において、会員ＩＤとしては、メールアドレスを兼用する構成の他、文字や数字を組み合わせたものをシステムが自動生成する構成であっても良く、利用者において任意に設定するものであっても良い。任意に設定する場合は、他に同じものが登録されていないかをチェックした上で登録を許可するプログラムが実装される。
【符号の説明】
【０１２２】
１ インターネット
２ イントラネット
３１ 第一の端末
３２ 第二の端末
４ デジタル契約サーバ
５ 認証サーバ
６ ストレージサーバ
７ 管理用クライアント
８ タイムスタンプサーバ
【技術分野】
【０００１】
本願の発明は、当事者間での契約を電子契約書として作成して保存するデジタル契約システムに関するものである。
【背景技術】
【０００２】
産業の各分野においてＩＴ（情報技術）の利用が進んでいるが、契約の分野ではあまり進んでいない。この理由の一つには、契約書は、当事者同士の意思を確認する法律文書であり、証拠としての価値等を考慮すると、紙によるものによらざえるを得ないという面があるからである。
【０００３】
しかしながら、数多くの契約を日常的に行っている会社においては、契約の締結、契約書の管理等において非常に多くの手間を要しており、煩雑となっている。例えば、建設業界では、各種工事の発注・受注において請負契約が日常的になされており、大量の契約書が日常的に取り交わされている。また、別の例としては、マンション販売を行う大手デベロッパーでは、年に数百棟単位またはそれ以上のマンション販売をしており、同数の契約を購入者との間で締結している。このような会社では、多数の契約書の管理が必要になっており、その手間が著しく煩雑となっている。このような契約締結や契約書の管理にＩＴを上手く利用することができれば、煩雑さが解消し、業務の効率化に著しい効果があげられるものと考えられる。
【０００４】
一方、インターネットに代表されるＩＴコミュニケーションにおいては、現実に多くの契約が成立している。ネットショッピングにおける商品やサービスの購入等が典型的な例である。これら契約においては、購入ボタン等が押されることをもって購入の意思表示がされたと取り扱うものである。しかし、契約書と呼べるものを取り交わす訳ではないので、契約の存在を示す証拠の保存の観点では十分ではない面がある。即ち、万が一紛争になった場合の立証上の問題や、税務上の理由で契約内容を証する際の問題がある。
【０００５】
電子商取引等において電子的な契約書を作成する場合、デジタル署名（電子署名）が利用される。一般的なデジタル署名である公開鍵方式の場合、認証局は、公開鍵と秘密鍵を発行するとともに、住民票等の本人確認書類の提出を条件に電子証明書（公開鍵証明書）を発行する。署名者が署名対象の電子契約書を秘密鍵を用いて暗号化し、電子証明書を添付することで、書類が電子的に署名されたことになる。相手先は、公開鍵を利用して電子契約書を復号し、契約内容を確認する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−３０９７８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したようなデジタル署名を利用したデジタル契約は、電子証明書の取得に時間が掛かり煩雑であるため、短期間のうちに契約を成立させて契約書を残す必要があるビジネスの現場では、非常に使いづらいものとなっている。特に、当事者の一方が、普段はあまり契約をしていない中小企業であるとか個人である場合、電子証明書を保有していないことが多いため、この問題が顕著である。
【０００８】
マンション販売を例に取り上記の点を説明すると、モデルルーム等を訪れた顧客（個人）がマンションを気に入り購入しようと思った場合、売り主と売買契約を結ぶことになる。この際、仮に電子契約書を作成して契約しようとした場合、両者が電子契約書にデジタル署名をする必要があるので、両者が電子証明書を取得している必要がある。売り主側は、会社（デベロッパーのようなマンション販売業者）である場合、電子証明書を予め取得して日常的に使用していることが多いが、購入者は個人であり、電子証明書を取得していないケースが多い。この場合、マンション購入のためにデジタル署名を行うことになる。デジタル署名は、住民票等の本人確認書類を郵送し、所定の審査をした後、電子証明書を発行してもらい、電子証明書をパソコンにインストールすることで行われる。したがって、マンションの販売・購入に両者が合意した後にこのような手間と時間が必要になる。
【０００９】
このように手間と時間が掛かるようでは、契約書の管理が容易であるとは言っても、電子契約書によらない紙ベースの契約書によることを選択してしまう場合が多い。販売会社の方が電子契約書によると決めているような場合、そのような時間と手間が掛かるとの説明を受けた購入者（個人）は購入自体を見送ってしまうこともあり得る。
本願の発明は、上記のような課題を解決するために為されたものであり、簡便な方法で電子的な契約を取り交わして電子契約書を保存することができるシステムを提供する技術的意義を有するものである。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本願の請求項１記載の発明は、当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末にネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報が真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えているという構成を有する。
また、上記課題を解決するため、請求項１２記載の発明は、当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末とのネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件について、その後に申し入れ者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件であって申し入れ者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって受諾者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えているという構成を有する。
【発明の効果】
【００１１】
以下に説明する通り、本願発明によれば、デジタル契約書によって契約が取り交わされ、デジタル契約書を保管する形なので、契約案件の管理や整理が容易である。その上、契約書ファイルと契約書がアップロードされて契約が受諾された旨を記録したファイルとについてタイムスタンプが付与されて保存されるので、ある時点において確かに契約が成立して契約書がに存在したことや契約書が改ざんされていないことの証明について高い信頼性が得られる。また、受諾者が本人認証をされていない段階でも受諾させてタイムスタンプを付与することが可能であり、システム上で契約を締結することが可能である。その場合も、その後に本人認証書類が届かない案件についてはタイムスタンプファイルが削除されるので、問題は生じない。
【図面の簡単な説明】
【００１２】
【図１】本願発明の実施形態に係るデジタル契約システムの概略図である。
【図２】デジタル契約サイトのトップページの一例について示した概略図である。
【図３】会員登録ページの一例について示した概略図である。
【図４】会員情報ＤＢＦの構造の一例を示した概略図である。
【図５】案件情報ＤＢＦの構造の一例を示した概略図である。
【図６】会員トップページの一例について示した概略図である。
【図７】ファイルアップロードページの一例について示した概略図である。
【図８】案件情報入力ページの一例について示した概略図である。
【図９】アップロードプログラムの概略について示したフローチャートである。
【図１０】アップロードプログラムの動作について示した概略図である。
【図１１】通知メールの一例について示した概略図である。
【図１２】ログ記録がされた契約書ファイルの一例を概略的に示した図である。
【図１３】閲覧用認証ページの概略図である。
【図１４】受諾処理プログラムの概略を示したフローチャートである。
【図１５】受諾のログ記録が追加されたログ付き契約書フィアルの内容の一例について示した概略図である。
【図１６】管理用メニューページの一例について示した概略図である。
【図１７】認証書類受領情報入力ページの一例について示した概略図である。
【図１８】督促メール送信プログラムの概略を示したフローチャートである。
【図１９】督促メールの一例について示した概略図である。
【図２０】申し入れ者宛督促メールの一例について示した概略図である。
【図２１】会員トッププログラムの概略を示したフローチャートである。
【図２２】本願発明の別の実施形態の主要部を示した概略図である。
【図２３】受諾者の仮会員登録を申し入れ者ができるようにした実施形態における案件情報入力ページの一例の概略図である。
【図２４】相手先会員登録ページの一例について示した概略図である。
【発明を実施するための形態】
【００１３】
次に、本願発明を実施するための形態（以下、実施形態）について説明する。図１は、本願発明の実施形態に係るデジタル契約システムの概略図である。図１に示すデジタル契約システムは、ネットワークを介してデジタル契約を締結させてデジタル契約書を保存するサービス（以下、本サービス）を提供するものである。ネットワークとしてはインターネット１が想定されており、デジタル契約システム（以下、単にシステムという）は、インターネット１に接続されたコンピュータ群によって構成されている。コンピュータ群は、不図示のファイアウォールを介してインターネット１に接続されたイントラネット２上に設けられている。イントラネット２は、契約の申し入れ者によって操作される第一の端末３１と受諾者によって操作される第二の端末３２とに対し、インターネット１を介して接続されている。また、インターネット１上にはタイムスタンプ局が設けられている。タイムスタンプ局はタイムスタンプサーバ８を有しており、タイムスタンプサーバ８はインターネット１を介してデジタル契約システムとつながっている。
【００１４】
コンピュータの幾つかはサーバコンピュータであり、その主要なものは、本サービスの提供のためのサイト（以下、デジタル契約サイト）を提供するウェブサーバ（以下、デジタル契約サーバ）４である。この他、認証サーバ５、ストレージサーバ６等が設けられている。図１は、サーバの機能として概念的に表示したものであり、二以上のサーバの機能が一つのサーバコンピュータで兼用して実現されることもある。また、イントラネット２上には、管理用クライアント７が設けられている。管理用クライアント７は、本システムを運営して本サービスを提供する会社（以下、運営会社）内の担当者によって操作されるクライアントコンピュータである。
【００１５】
本サービスの提供は、概略的には以下のようなステップで行われる。まず、本サービスの提供を受けるには、会員登録が必要になっており、少なくとも申し入れ者が正式な会員登録をした状態で本サービスの提供が開始される。正式会員登録をすると、デジタル契約サイトの会員トップページへのアクセスが可能となる。会員トップページでは、システムを利用した契約案件の進捗状況を確認することができる。
【００１６】
本システムを利用した契約の締結は、会員登録をした一方の当事者がデジタル文書としての契約書のファイル（以下、契約書ファイル）をシステムにアップロードすることで始まる。このアップロードは、その当事者がその契約を申し入れる意思表示であり、したがって、正式な会員登録は、本人認証をした上でなされ、それを前提にアップロードが許容される。また、契約の受諾側については、少なくとも仮の会員登録がされていることが必要であり、申し入れ者は受諾者に対して予め本システムにアクセスして仮会員登録するよう依頼しておく。
【００１７】
契約書ファイルがアップロードされると、システムは、受諾確認用の契約書ファイルの生成、受諾者への通知メールの生成と送信等を行う。通知メールは、契約書ファイルがアップロードされた旨を知らせるメールであり、受諾者が操作する第二の端末３２に送信される。受諾者は、第二の端末３２によってデジタル契約サイトにアクセスして契約書ファイルを開き、受諾ボタンをクリックして契約を成立させる。
この間のシステムにおける処理は、契約書ファイル自体にログ記録されており、受諾ボタンがクリックされると、システムは、ログ記録付きの契約書ファイルについてタイムスタンプ手段にタイムスタンプ要求を発し、返信されるタイムスタンプファイルを保存する。その後、仮会員登録をした受諾者から本人認証書類の到着を待ち、所定期間過ぎても到着しない場合、本人認証ができないとしてそのタイムスタンプファイルを削除する処理を行う。
【００１８】
次に、上記のようなサービスを提供するシステムの各部について詳説する。
まず、デジタル契約サーバ４について説明する。デジタル契約サーバ４は、ウェブサーバであり、会員登録ページ、会員トップページ等の提供を行うものである。デジタル契約サーバ４は、各ページを提供するＨＴＭＬファイルやデータの受け渡しを行うサーバプログラムを備えている。各ページを提要するＨＴＭＬファイルは、デジタル契約サーバ４の保存部（ハードディスク等）に保存されている。このようなウェブサーバは、市販のウェブサーバソフトウェアをサーバコンピュータに実装することで実現できるので、細部の詳細な説明は割愛する。
【００１９】
図２は、デジタル契約サイトのトップページの一例について示した概略図である。図２に示すように、トップページには、本サービスの概要やメリットについて解説した欄が設けられているとともに、会員登録ページへのリンクボタン（会員登録ボタン）４１や会員登録されている者のためのログインボタン４２が設けられている。
本システムにおいて会員登録は、本人認証をした上で行われる。本システムでは、本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存部する正式認証情報発行保存手段と、本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段とが設けられている。これらの手段は、会員登録ページを提供するデジタル契約サーバ４と、認証情報を保存する認証サーバ５等によって構成されている。
【００２０】
図３は、会員登録ページの一例について示した概略図である。図３に示す会員登録ページは、会員ＩＤ及びパスワードの入力欄、法人・個人の選択欄、氏名（法人の場合には法人名）の入力欄等が設けられている。この例では、会員ＩＤとしては連絡用のメールアドレスを兼用して入力するようになっている。また、パスワードとしては、字数や使用できる文字の種類に制限はあるものの、入力者が任意のパスワードを設定して入力できるようになっている。
【００２１】
認証サーバ５には、データベースファイルを管理するデータベース管理プログラム（ＤＢＭＳ））が実装されている。ＤＢＭＳによって管理されるデータベースファイル（ＤＢＦ）として、会員情報をデータベース化したデータベースファイル（以下、会員情報ＤＢＦ）が保存されている。
図４は、会員情報ＤＢＦの構造の一例を示した概略図である。図４に示すように、会員情報ＤＢＦは、「会員ＩＤ」（本実施形態ではメールアドレス）、「正仮種別」、「法人個人種別」、「仮登録日」、「仮パスワード」、「正式登録日」、「正式パスワード」、「名前」、「住所」、「電話番号」等のフィールドからなるレコードが多数登録されるファイルとなっている。図３に示す会員登録ページの各欄が正しく入力されて送信ボタン４３がクリックされると、入力された情報が認証サーバ５に送られ、会員情報ファイルに新規レコードが追加されて記録されるようプログラミングされている。
【００２２】
尚、図３に示す会員登録ページでの入力による登録の段階では、まだ仮登録の状態であり、送信ボタンがクリックされた日は「仮登録日」のフィールドに記録され、「正仮種別」の欄には、仮登録である旨の情報が記録される。図３に示すように、会員登録ページには、ここでの登録は仮登録であり、正式な申し込み書と本人認証書類の提出を待って正式登録がされるので、申し込み書及び本人認証書類の所定期間内に郵送して欲しい旨のメッセージが表示されるようになっている。
【００２３】
本人認証書類とは、法人であれば登記簿謄本及び印鑑証明であるし、個人であれば住民票及び印鑑証明ということになる。申し込み書には、署名欄及び実印の捺印欄が設けられている。運営会社の担当者は、上記仮登録の後、署名及び実印を捺印した申し込み書と本人認証書類が所定期間内に届くかどうかチェックしており、届いた場合には、正式な会員ＩＤ及びパスワードを発行する。この部分については二通りのやり方がある。
一つは、会員ＩＤ及び正式パスワードを記載した書面を本人しか受領できない郵便で送るやり方である。会員ＩＤ及び正式パスワードは、契約の際の本人の意思を確認するもの（実印に相当するもの）であるので、本人のみが受領できるようにする。
【００２４】
もう一つのやり方は、上記仮登録の際の任意に決めたパスワードを他人に知らせないようにしてもらい、そのパスワードと同じパスワードを申し込み書に記載してもらうやり方である。申し込み書には、同様に署名欄及び実印の捺印欄を設けられているとともに、任意のパスワードを記載する欄が設けられる。申し込み書に署名及び実印捺印をした上、任意のパスワードを記載し、申し込み書とともに本人認証書類を運営会社に送付するようにする。この運営会社宛の送付は、パスワードが漏洩しないように親展扱いの書留郵便等にすることが望ましい。尚、この場合、正式パスワードは、仮登録の際の同じものとなるので、会員情報ＤＢＦについては、図４に示すように「正式パスワード」と「仮パスワード」の二つを設ける必要はなく、単に一つのパスワードを登録するフィールドを設けるだけにしても良い。
この後者のやり方の場合、運営会社としては、パスワードを本人に知らせる必要が無いので、本人のみ受領郵便のような高額な郵送料が要らなくなり、コスト的な面でメリットが大きい。
【００２５】
署名及び実印の捺印をした申し込み書と本人認証書類が運営会社に届くと、運営会社の担当者は、申し込み書と本人認証書類の内容を確認し、正しく本人認証できたと判断すると、管理用クライアント７を操作し、会員情報ＤＢＦを開く。そして、仮登録されている該当レコードの「正仮種別」のフィールドに正式会員である旨の情報を上書きして記録するとともに、「正式会員登録日」のフィールドに認証日を入力する。これで正式会員として登録がされたことになる。このようにして正式な会員登録（本人認証付きの会員登録）をすると、会員専用のページへのアクセスしてサービスの提供を受けることが可能となる。パスワードをシステム上で発行する構成の場合、正式パスワードが自動生成され、会員情報ＤＢＦの該当レコードに記録される。この場合の正式パスワードは、本人のみが受領できる郵便で郵送される。
尚、図４に示すように、会員情報ＤＢＦの各レコードには、「使用有無」という名前のフィールドが設けられている。このレコードには、仮会員登録の段階で受諾者としてシステムを利用したか否かの情報が記録されるようになっている。これは、後述するように、仮パスワードの融通性を下げるための技術構成である。
【００２６】
次に、会員向け各種サービスを提供するためのシステムの構成について説明する。契約締結を仲介するためになされる会員向けの各種サービスの管理のため、本実施形態のシステムは、各契約案件の情報を登録したデータベースファイル（以下、案件情報ＤＢＦ）を備えている。図５は、案件情報ＤＢＦの構造の一例を示した概略図である。
図５に示すように、案件情報ＤＢＦは、「案件ＩＤ」、「案件名」、「申し入れ者会員ＩＤ」、「申し入れ者名前」、「情報保存期間」、「受諾者会員ＩＤ」、「受諾者名前」、「受諾者正仮別」、「契約書ファイル名」、「アップロード日時」、「ファイル保存場所」、「受諾日時」、「本人認証書類受領日」等のフィールドから成るレコードを多数登録したデータベースファイルとなっている。また、図示はされていないが、タイムスタンプ要求を発した日時である「タイムスタンプ日時」のフィールドも設けられている。
【００２７】
会員向けのサービスの提供を受けるには、会員としてのログインが必要である。即ち、図２に示すように、トップページにはログインボタン４２が設けられている。ログインボタン４２をクリックすると、本人認証ページ（会員ＩＤ及びパスワードを入力させるページ）が表示されるようになっている。本人認証ページには送信ボタンが設けられており、送信ボタンには、会員トップページを表示するプログラム（以下、会員トッププログラム）の起動コマンドが埋め込まれている。本人認証ページにおいて会員ＩＤ及びパスワードが入力されて送信ボタンがクリックされると、会員トッププログラムが起動する。会員トッププログラムは、入力された会員ＩＤ及びパスワードを会員情報ＤＢＦ内のデータと照合してが正しいかどうか（正式な会員登録における会員ＩＤ及びパスワードに一致するかどうか）判断し、正しければ、会員トップページのＨＴＭＬファイルを送って端末に表示させる。この際、会員トッププログラムは、後述するように案件情報ＤＢＦを検索して必要な情報を収集してＨＴＭＬファイルに嵌め込む。尚、会員ＩＤは後の処理のためにメモリ変数に一時的に格納される。会員ＩＤとしては、本実施形態では、メールアドレスが兼用されている。
【００２８】
図６は、会員トップページの一例について示した概略図である。図６に示すように、会員トップページは、自分が関係している契約案件のシステム上の処理状況をリスト表示して知らせるページであるとともに、会員に提供される各種サービスの窓口となるページである。
【００２９】
次に、契約書ファイルのアップロードについて説明する。本実施形態のシステムは、第一の端末３１から契約書ファイルをインターネット１を介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段を備えている。契約書ファイル送信手段は、デジタル契約サーバ４と、デジタル契約サーバ４に実装されたアップロードプログラム等によって構成されている。
契約書ファイルのアップロードは、契約を申し入れる行為であり、契約書ファイルをデジタル契約サーバ４に送信させ、デジタル契約サーバ４経由でストレージサーバ６に保存するとともに、この際、その契約案件の情報を入力させて案件情報ＤＢＦに登録するステップである。契約書ファイルのアップロードは、作成された契約書ファイルをＨＴＭＬに変換し、必要な情報を嵌め込んだ上でデジタル契約サーバ４にアップロードするステップである。そして、この契約書ファイルのアップロードの際、相手先（受諾者）に契約書アップがアップロードされた旨を通知するメール（以下、通知メール）が送信されるようになっている。
【００３０】
より具体的に説明すると、図６に示すように、会員トップページには、「新規契約書登録」と表記されたコマンドボタン（以下、契約書登録ボタン）４４が設けられている。契約書登録ボタン４４は、契約書ファイルをデジタル契約サーバ４に送信させ、ストレージサーバ６に保存するためのページ（以下、ファイルアップロードページ）へのリンクが埋め込まれている。
【００３１】
図７は、ファイルアップロードページの一例について示した概略図である。
図７に示すように、ファイルアップロードページには、契約書ファイルを選択する欄（以下、ファイル選択欄）が設けられている。この部分は、ファイルアップロードページにアクセスした端末に保存されているファイルを指定する欄であり、「参照」と表記されたコマンドボタン（参照ボタン）４５をクリックすることで、ハードディスクやＵＳＢメモリ等に保存された契約書ファイルを指定するようになっている。
ファイルアップロードページには、「ファイルのアップロード」と表記されたボタン（以下、アップロードボタン）４６が設けられている。アップロードボタン４６には、案件情報入力ページへのリンクが埋め込まれている。
【００３２】
図８は、案件情報入力ページの一例について示した概略図である。図８に示すように、案件情報入力ページには、案件名入力欄、相手先メールアドレス入力欄、契約金額入力欄等が設けられている。前述したように、契約書ファイルをアップロードする時点では、受諾者は少なくとも仮会員登録していることが必要であり、相手先メールアドレス入力欄には、受諾者の仮会員登録又は正式会員登録におけるメールアドレスが入力される。申し入れ者は、予めこのメールアドレスを聞いておき、それを入力する。
【００３３】
受諾者が会員登録を全くしていない場合、受諾者は予め第二の端末３２を操作して本サイトにアクセスし、仮の会員登録をする。この部分の構成は、前述した申し入れ者についての仮会員登録の場合と同様である。受諾者は、自分のメールアドレスを会員ＩＤとして入力し、任意のパスワードを自分で設定して入力した上で仮会員登録をする。会員情報ＤＢＦにおいて新規レコードが追加され、入力されたメールアドレスが「会員ＩＤ」のフィールドに記録され、入力された仮パスワードが「仮パスワード」のフィールドに記録される。「正仮種別」のフィールドに仮会員である旨の情報が記録される。「使用有無」のフィールドについては、使用無しの旨の情報がデフォルト値であり、そのまま状態でこの新規レコードが登録される。
【００３４】
図８に示すように、案件情報入力ページには送信ボタン４９が設けられている。この送信ボタン４９には、アップロードプログラムの起動コマンドが埋め込まれている。アップロードプログラムは、送信された契約書ファイルをストレージサーバ６への保存に加え、契約書ファイルの変換、案件情報の登録、通知メールの送信等を行うプログラムである。図９及び図１０を使用してアップロードプログラムの詳細について説明する。図９はアップロードプログラムの概略について示したフローチャート、図１０はアップロードプログラムの動作について示した概略図である。
【００３５】
図９に示すように、アップロードプログラムは、まず、入力された各案件情報をメモリ変数に格納する。次に、アップロードプログラムは、受諾者の会員登録（正又は仮）がされているかどうか判断する。具体的には、入力された相手先メールアドレスを検索キーにして会員情報ＤＢＦを検索し、「会員ＩＤ」のフィールドの値がこのメールアドレスに一致するレコードがあるかどうか判断する。もし一致するレコードが無ければ、受諾者は正式会員でも仮会員でもないことになるので、「該当するメールアドレスがシステムに登録されておらず、受諾者は会員登録されていないようです。受諾者に対して仮会員登録をするよう依頼して下さい。契約書ファイルのアップロードは受諾者が仮会員登録をした後に可能になります。」というようなエラーメッセージを第一の端末３１に表示した後、プログラムを終了させる。入力されたメールアドレスが「会員ＩＤ」のフィールドの値に一致するレコードがあった場合、「正仮種別」のフィールドの値を読み出して正会員か仮会員かを判断し、仮会員であった場合、「使用有無」のフィールドの値を読み出す。この値が「有」であった場合、別の案件で過去に既にシステムを利用したにも関わらずまだ正式登録がされていない会員であり、本実施形態ではシステムの利用ができないので、「受諾者がまだ仮会員登録の段階であって既に別の案件でシステムを利用しているので、契約書ファイルをアップロードできません。」というようなエラーメッセージを送信し、プログラムを終了させる。
【００３６】
受諾者が正式会員か、又は仮会員で過去にシステムの利用が無い場合には、契約書ファイルのアップロードを許可して情報の登録を行う。即ち、アップロードプログラムは、読み出したメールアドレス及び正仮種別の値をメモリ変数に格納する。次に、アップロードプログラムは、受諾者が仮会員である場合、会員ＩＤ（メールアドレス）で会員情報ＤＢＦを検索し、該当するレコードの「使用有無」のフィールドに「有」の値を記録する。次に、アップロードプログラムは、案件情報ＤＢＦに新規レコードを追加し、メモリ変数から情報を読み出して新規レコードの各フィールドに記録する。この際、案件ＩＤを自動生成し、「案件ＩＤ」のフィールドに記録する。受諾者が仮会員である場合、「受諾者正仮別」のフィールドにその旨の情報を記録する。
【００３７】
次に、アップロードプログラムは、契約書ファイルを送信してきた送信元（第一の端末３１）の端末識別情報を案件情報ＤＢＦに記録する。図５に示すように、案件情報ＤＢＦの各レコードには、「送信元端末情報」という名前のフィールドが設けられている。端末識別情報として本実施形態ではＩＰアドレスを記録するようになっており、アップロードプログラムは、セッションの環境変数からＩＰアドレスを取得し、「送信元端末情報」のフィールドに記録する。
次に、アップロードプログラムは、送信された契約書ファイルをそのままマスタファイルとしてストレージサーバ６の保存部の所定の場所に保存する。例えば、案件ＩＤの名前でディレクトリを新たに生成し、そこを保存場所とする。そして、この保存場所の情報を、追加した新規レコードの「ファイル保存場所」のフィールドに記録する。
【００３８】
次に、アップロードプログラムは、契約書ファイルの変換を行う。この変換は、契約書ファイルをインターネット１上で受諾者が閲覧できるようにするとともに、受諾意思の確認用のボタン（以下、受諾ボタン）を契約書ファイル内に嵌め込むためのものである。
本実施形態では、アップロードプログラムは契約書ファイルをＨＴＭＬファイルに変換するようプログラミングされている。図１０に概略的に示すように、アップロードプログラムは、送信された契約書ファイル（文書ファイル）のテキスト部分をＨＴＭＬファイルの本体部分に嵌め込み、その下に受諾ボタン５０を嵌め込むようプログラミングされている。このようなプログラミングは、ワードプロセッサソフトウェアのマクロ機能を利用すれば容易に実現できるので、詳細な説明は割愛する。尚、受諾ボタン５０には、後述する受諾処理プログラムの起動コマンドが埋め込まれるようになっている。この際、生成した案件ＩＤを引数にして渡すように起動コマンドが記述される。
【００３９】
アップロードプログラムは、このようにして変換された契約書ファイル（以下、変換済み契約書ファイル）は、ストレージサーバ６の保存部の所定の場所（契約書ファイルと同じディレクトリでも良い）に保存する。次に、アップロードプログラムは、図９に示すように、通知メールの生成と送信を行う。通知メールは、契約書ファイルがアップロードされたのでアクセスして欲しい旨を伝えるメールである。図１１は、通知メールの一例について示した概略図である。
【００４０】
デジタル契約サーバ４の保存部には、通知メール用のテンプレートファイル（以下、メールテンプレート）が保存されている。メールテンプレートは、受諾者が仮会員か正式会員かで異なるものが使用されるようになっており、それぞれ保存されている。アップロードプログラムは、メモリ変数から正仮会員種別の値を取り出して仮会員か正式会員かを判断する。仮会員であれば仮会員用のメールテンプレートを読み出し、正式会員であれば正式会員用メールテンプレートを読み出し、必要事項を嵌め込んで通知メールを作成する。
【００４１】
図１１に示すように、通知メールには、システムの会員になっている者から、ある契約についての申し入れがあり、契約書ファイルがアップロードされた旨、契約を受諾する意思があれば、システムにアクセスして契約書の内容を確認し、受諾ボタンをクリックして欲しい旨等が記載されている。アクセス用のＵＲＬ（ハイパーリンク）も埋め込まれる。これは定型のものであり、これに続く部分に案件名や申し入れ者名等の具体的な案件情報が記載されるようになっている。案件名は、メモリ変数から読み出して嵌め込む。申し入れ者名は、ログインの際に入力された会員ＩＤをメモリ変数から読み出し、会員情報ＤＢＦを検索して取得し、それを嵌め込む。
【００４２】
図１１に示す通知メールは、受諾者が仮会員登録された者である場合の例である。この場合、アップロードプログラムは、受諾者の会員ＩＤをメモリ変数から読み出し、図１１に示すように通知メールに嵌め込む。この場合、図１１に示すように、通知メールには、この登録情報は仮のものであり、後日、本人認証書類の提出が必要である旨のメッセージを併せて記載する。受諾者が正式会員登録された者である場合（正式会員用のメールテンプレートの場合）は、このようなメッセージは記載されていない。誤ったメール送信等を考慮し、この契約案件に身に覚えがない場合にはシステムにアクセスせずに所定の連絡先に知らせて欲しい旨のメッセージも記載されるようになっている。
アップロードプログラムは、このようにして通知メールを生成した後、メモリ変数から受諾者のメールアドレス（会員ＩＤ）を読み出し、このアドレスを送信先にして通知メールを送信する。
【００４３】
次に、アップロードプログラムは、契約書ファイルがアップロードされた旨のログ記録を行う。ここでのログ記録は、契約書ファイルが申し入れ者からアップロードされた旨の記録であり、法律的には契約の申し入れが申し入れ者からあったことを意味する。本実施形態における大きな特徴点の一つは、このログ記録が契約書ファイル自体に行われる点である。
【００４４】
図１２を使用してより具体的に説明する。図１２は、ログ記録がされた契約書ファイルの一例を概略的に示した図である。図１２に示すように、アップロードプログラムは、送信された契約書ファイル（文書ファイル）において、最終頁の後にさらに頁を追加する処理を行い、この追加した頁にテキストでログ記録をする。記録される情報は、申し入れ者の会員ＩＤ（メールアドレス）、会社名（個人の場合は氏名）、アップロード日時、送信元端末識別情報である。アップロード日時は、アップロードの際のアクセスにおける環境変数から取得する。送信元端末識別情報は、前述したように、本実施形態では送信元（第一の端末３１）のＩＰアドレスである。
【００４５】
このようにしてログ記録をした後、契約書ファイルを別のファイル名にし、ストレージサーバ６の保存部の所定のパスに保存する。この契約書ファイルは、ログ記録付きの契約書ファイルであり、以下、ログ付き契約書ファイルと呼ぶ。ログ付き契約書ファイルのファイル名は、後から容易に読み出せるように、予め定められたやり方で名前等が決定される。例えば、案件ＩＤをファイル名にしたり、案件ＩＤをディレクトリ名にしてその下に保存するといったやり方である。このようにしてログ付き契約書ファイルを保存すると、アップロードプログラムは終了である。上記説明から解るように、デジタル契約サーバ４及びアップロードプログラムは、契約書ファイルの保存と契約書ファイルのアップロード送信のログ記録の保存を行う契約書ファイル保存手段を構成している。
【００４６】
次に、本システムは、保存された契約書ファイルを第二の端末３２に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、契約書ファイルを閲覧した受諾者が第二の端末３２において当該契約について受諾の旨の入力をした際、インターネット１を介してその旨の情報を受信する受諾情報受信手段と、受諾情報受信手段が受諾の旨の情報を受信した際、その契約案件の契約書ファイルの内容と受諾の旨の情報についてタイムスタンプ手段に対してタイムスタンプ要求を送信するとともにその受信のログ記録を保存部に保存する受諾情報処理手段とを備えている。
【００４７】
まず、契約書ファイル閲覧手段について説明する。契約書ファイル閲覧手段は、デジタル契約サーバ４等によって構成されている。デジタル契約サーバ４の保存部には、契約書ファイル閲覧用の認証ページ（以下、閲覧用認証ページ）を表示するためのＨＴＭＬファイルが保存されている。図１３は、閲覧用認証ページの概略図である。図１１に示す通知メールに記載されたアクセス用のＵＲＬは、案件ＩＤを渡しつつ閲覧用認証ページを開くコマンドとなっている。
【００４８】
閲覧用認証ページは、開かれた際、渡された案件ＩＤをメモリ変数に一次的に格納するようになっている。図１３に示すように、閲覧用認証ページには、会員ＩＤとパスワードの入力欄が設けられており、正式会員の場合には正式会員としてのパスワードを入力し、仮会員の場合には、仮会員登録の場合に自分が任意に設定したパスワードを入力して欲しい旨のメッセージが表示されるようになっている。閲覧用認証ページには、送信ボタン５１が設けられている。デジタル契約サーバ４には、変換済み契約書ファイルを送信して閲覧させる契約書ファイル閲覧プログラムが実装されている。送信ボタン５１には、契約書ファイル閲覧プログラムの起動コマンドが埋め込まれている。
【００４９】
契約書ファイル閲覧プログラムは、メモリ変数から案件ＩＤを読み出し、案件ＩＤを検索キーにして案件情報ＤＢＦを検索し、入力された会員ＩＤ及びパスワードが正しいかどうか判断する。この際、「受諾者正仮種別」のフィールドの値を読み出して受諾者が正式会員か仮会員かを判断する。正式会員であれば、会員ＩＤを認証サーバ５に送り、入力されたパスワードが「正式パスワード」と一致するかどうかを判断させる。仮会員であれば、会員ＩＤを認証サーバ５に送り、会員情報ＤＢＦの該当レコードの「使用有無」のフィールドを読み出す。このフィールドの値が「有り」であれば、別の案件で既に仮登録を使用しているので、「この会員ＩＤによる登録は仮登録の段階であり、別の案件でシステムを利用されていて、その別の案件ではまだ本人認証されておりません。したがって、本件でのシステムの利用はできません。別の案件で要請されている本人認証書類の送付がされ、正式会員となった後に改めてアクセスしてください。」というようなエラーメッセージを送信し、プログラムを終了する。「使用有無」のフィールドが「無し」の値であれば、閲覧を許可し、その案件の契約書ファイルをストレージサーバ６から読み出し、アクセスしてきた第二の端末３２に送信する。これにより、契約書ファイル閲覧プログラムは終了である。
【００５０】
第二の端末３２に表示される変換済み契約書ファイルは、当然ながら図１０に示されるものと同様である。即ち、図１０に示すように、変換済み契約書ファイルを表示すると、契約内容を記載した部分の末尾に、受諾ボタン５０が表示されるようになっている。デジタル契約サーバ４には、第二の端末３２から送信された受諾の旨の情報を受信して処理する受諾処理プログラムが実装されており、受諾ボタン５０には受諾処理プログラムの起動コマンドが埋め込まれている。受諾ボタン５０は、案件ＩＤを引数にして受諾処理プログラムを起動するようになっている。即ち、前述したアップロードプログラムは、案件ＩＤを引数にして受諾処理プログラムを起動するコマンドを埋め込む形で受諾ボタン５０を通知メールに嵌め込むようプログラミングされている。
【００５１】
次に、受諾情報受信手段、受諾情報処理手段及びタイムスタンプファイル保存手段について説明する。これらの手段は、デジタル契約サーバ４及びデジタル契約サーバ４に実装された受諾処理プログラム等によって構成されている。
図１４は、受諾処理プログラムの概略を示したフローチャートである。図１４に示すように、受諾処理プログラムは、案件ＩＤを引数にして案件情報ＤＢＦを検索し、該当するレコードの「受諾日時」のフィールドに受信日時（アクセスの環境変数から取得）を記録する。また、受諾処理プログラムは、受諾端末情報の記録も行う。受諾者端末識別情報は、受諾の旨を送信した第二の端末３２を識別する情報であり、契約書ファイルの送信元（第一の端末３１）と同様、本実施形態ではＩＰアドレスとなっている。受諾処理プログラムは、セッションの環境変数からＩＰアドレスを取得し、「受諾端末情報」のフィールドに記録する。
【００５２】
次に、受諾処理プログラムは、該当する案件のログ付き契約書ファイルを開き、ログ記録をさらに追加する。図１５は、受諾のログ記録が追加されたログ付き契約書フィアルの内容の一例について示した概略図である。図１５に示すように、ログ記録用に追加した頁の最終行の次に追記する形で、受諾者の会員ＩＤ（メールアドレス）、法人名（個人の場合は氏名）、受諾日時（上記受信日時）、受諾端末情報を記録するようになっている。これらログ記録の後、ログ付き契約書ファイルを同じファイル名で同じ場所に保存（即ち上書き）する。
【００５３】
次に、受諾処理プログラムは、タイムスタンプ手段に対しタイムスタンプ要求を送信する。タイムスタンプ手段は、本実施形態のシステムにおいて作成されるログ付き契約書ファイルについてタイムスタンプを付与するもので、ログ付き契約書ファイルの内容とそれが存在していた日時を証明する手段である。タイムスタンプ手段は、タイムスタンプ要求を受信すると、ログ付き契約書ファイルの非改ざん性と存在日時を証明するためのファイル（以下、タイムスタンプファイルと呼ぶ）を返信する。本実施形態のシステムは、このタイムスタンプファイルを保存し、後に必要になった時に開いて契約内容の真正さを確認するようにしている。具体的に説明すると、本実施形態では、ログ付き契約書ファイルのハッシュ値を送信してタイムスタンプ要求をするようになっており、タイムスタンプ手段は、ハッシュ値と日時情報を統合して生成するタイムスタンプトークンをタイムスタンプファイルとして返信するようになっている。タイムスタンプトークンは、いわゆる公開鍵で復号されるもので、元データ（ここではログ付き契約書ファイル）から同様のアルゴリズムで生成したハッシュ値と比較して真正かどうかが検証されるファイルである。したがって、本実施形態では、タイムスタンプトークンをタイムスタンプファイルとしてストレージサーバ６に保存するようになっている。
【００５４】
タイムスタンプ手段は、図１に示すように、具体的にはタイムスタンプ局に設置されたタイムスタンプサーバ８である。タイムスタンプ局は、タイムスタンプサービスを提供する会社によって運営されている。タイムスタンプサーバ８は、インターネット１を介して送信されたタイムスタンプ要求を受信することが可能となっている。受諾処理プログラムは、ログ付き契約書ファイルを所定のアルゴリズムで暗号化してハッシュ値を生成し、ハッシュ値をタイムスタンプサーバ８に送信しながらタイムスタンプ要求を送信する。ログ付き契約書ファイルをＰＤＦのようなイメージファイルにしてからハッシュ値を生成するようにする場合もある。タイムスタンプサーバ８では、送信されたハッシュ値に対して時刻情報（国際標準時）を結合し、タイムスタンプトークンを返信する。受諾処理プログラムは、返信されたタイムスタンプトークンをストレージサーバ６の保存部の所定のディレクトリに保存する。これで受諾処理プログラムは終了である。
【００５５】
尚、ハッシュ値の生成やタイムスタンプサーバ８へのタイムスタンプ要求については、タイムスタンプ局を運営する会社から適宜のプラグインプログラムが提供されているので（例えば、アマノビジネスソリューションズ（株）から提供されているe-timing EVIDENCE 3161 for Acrobat）、適宜組み込むことで上記処理を実現することができる。タイムスタンプトークンの復号や元データとの照合（検証）についても同様であり、提供されたプラグインプログラムを実装することによって行える。
【００５６】
次に、削除手段について説明する。本システムは、受諾者が仮登録の段階で受諾した場合であって所定期間内に受諾者から本人認証書類が届かなかった場合に、タイムスタンプファイルを削除する削除手段を備えている。本実施形態では、削除手段は、本人認証書類が届いた旨の情報（以下、認証書類受領）が案件情報ＤＢＦに登録されているもの以外は所定期間経過後にすべて自動的に削除するようになっており、削除手段は、この削除を行うプログラム（以下、削除プログラム）と、削除プログラムを実行するデジタル契約サーバ４等によって構成されている。
【００５７】
まず、認証書類受領情報の登録について説明する。本システムは、受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段を備えている。管理用クライアント７は、認証書類受領情報の登録を含む管理用プログラムを実行するための管理用メニューページを表示できるようになっている。メニューページは、管理用クライアント７の保存部（ハードディスク等）に保存されているページファイルによるものであっても良いし、デジタル契約サーバ４に管理用のページを設け、そこにアクセスして取得するようにしても良い。
【００５８】
図１６は、管理用メニューページの一例について示した概略図である。図１６に示すように、管理用メニューページには、「認証書類受領登録」と表記されたコマンドボタン５２がある。このコマンドボタン５２がクリックされると、案件ＩＤを入力するページ（案件ＩＤ入力ページ）が表示されるようになっている。案件ＩＤ入力ページには、ＯＫボタンが設けられており、ＯＫボタンには、認証書類受領情報入力ページを表示するためのプログラムの起動コマンドが埋め込まれている。このプログラムは、入力された案件ＩＤをメモリ変数に格納するとともに案件ＩＤを引数にして案件情報ＤＢＦを検索し、該当するレコードの「案件名」、「申し入れ者名前」、「受諾者名前」等のフィールドの情報を読み出し、認証書類受領情報入力ページに組み込んで認証書類受領情報入力ページを管理用クライアント７に表示するプログラムとなっている。
【００５９】
図１７は、認証書類受領情報入力ページの一例について示した概略図である。図１７に示すように、認証書類受領情報入力ページは、入力した案件ＩＤや、案件情報ＤＢＦから取得した案件名、当事者の名前等の情報を確認のため表示するようになっている。
そして、認証書類受領ページには、各認証書類が正しく受領されているときに入力される確認入力欄（この例ではチェックボックス）が設けられており、各確認入力欄が入力された状態でＯＫボタン５３がクリックされると、内容確認用のページが表示されるようになっている。このページには登録ボタンが設けられており、登録ボタンには、案件情報ＤＢＦ及び会員情報ＤＢＦへの登録用のプログラムの起動コマンドが埋め込まれている。このプログラムは、案件ＩＤをメモリ変数から読み出して案件情報ＤＢＦを検索し、該当するレコードの「受諾者認証日」のフィールドに、管理用クライアント７の内蔵時計（いわゆるシステム時刻）から日にちデータを取得して記録する。このプログラムは、次に正式会員登録の処理をする。会員情報ＤＢＦの当該レコードの「正仮種別」に正式会員である旨の情報を上書きして記録する。パスワードとしては、仮登録の際に受諾者が任意に設定した仮パスワードをそのまま正式なパスワードとする。これは、前述したように、パスワードの通知の手間とコストが省けるからである。その後、正式会員登録を通知する書面をプリントアウトすれば、プログラムは終了である。運営会社の担当者は、書面を本人のみが受領できる郵便で受諾者に送付する。受諾者は、以後は正式会員として本システムにアクセスできることになる。尚、正式パスワードとしては、仮パスワードとは別に自動生成するようにしても良い。この場合、通知する書面に正式パスワードを記載し、本人のみ受領できる郵便で送付する。
【００６０】
一方、本実施形態のシステムは、仮会員登録の受諾者が受諾してから一定期間以内に受諾者の本人認証書が届いていない案件について督促メールを送る督促メール送信手段が設けられている。本実施形態では、督促メール送信手段は、デジタル契約サーバ４と、デジタル契約サーバ４に実装された督促メール送信プログラム等によって構成されている。また、デジタル契約サーバ４の記憶部には、申し入れ者宛の督促メールのテンプレートファイル（以下、申し入れ者用メールファイル）と、受諾者宛の督促メールのテンプレートファイル（以下、受諾者用メールファイル）とが記憶されている。
【００６１】
図１８は、督促メール送信プログラムの概略を示したフローチャートである。本実施形態では、受諾者が受諾してから（受諾ボタンをクリックしてから）例えば二週間以内に本人認証書類を送付するルールとなっており、督促メールは、二週間経過の時点で自動的に送信されるようになっている。
より具体的に説明すると、督促メール送信プログラムは、一日一回所定の時刻（例えば午前０時）に自動実行されるプログラムとなっている。この時刻が到来すると、督促メール送信プログラムは、案件情報ＤＢＦの最初のレコードにポインタを移動させ、「受諾者正仮別」のフィールドに仮会員である旨の値が記録されており、「受諾日時」のフィールドに値があり（Ｎｕｌｌ値ではなく）、受諾日時から二週間（１４日）以上経過しており、且つ「受諾者認証書類受領日」のフィールドがＮｕｌｌ値であるかどうか判断する。これらの条件がすべて成立する場合、「申し入れ者会員ＩＤ」のフィールドの値を読み込んでメモリ変数に格納するとともに、「受諾者会員ＩＤ」のフィールドの値を別のメモリ変数に格納する。
【００６２】
次に、督促メール送信プログラムは、デジタル契約サーバ４の保存部から申し入れ者用メールファイルを読み出す。案件ＩＤ、案件名、受諾者名前等の情報を案件情報ＤＢＦの当該レコードから読み出して申し入れ者用メールファイルに嵌め込み、督促メールを生成する。そして、申し入れ者のメールアドレス（申し入れ者会員ＩＤ）を宛先としてメール送信をする。督促メール送信プログラムは、受諾者についても同様にメール送信を行う。即ち、受諾者用メールファイルを開き、案件ＩＤ、案件名、申し入れ者名前等の情報を案件情報ＤＢＦから読み出して嵌め込み、受諾者会員ＩＤのメールアドレスに送信する。
その後、督促メール送信プログラムは、ポインタを次のレコードに移動させ、同様の条件が成立するか判断する。成立すれば、同様に督促メールを申し入れ者と受諾者とに送る。このようにして、条件が成立するレコード（案件）について督促メールを送り、最後のレコードまで処理をすると、督促メール送信プログラムは終了である。
【００６３】
図１９は、このようにして送信された督促メールの一例について示した概略図である。図１９では、受諾者宛の通知メールとなっている。図１９に示すように、受諾者宛の督促メールでは、期間が過ぎても本人認証書類が届いていないので、早急に送付して欲しい旨、所定期間（本実施形態では受諾から三週間以内）に送付されないと契約がシステム上認証されないことになり契約書が破棄される旨のメッセージが記載される。契約書が破棄されるとは、削除手段によってタイムスタンプファイルが削除されることである。
また、図２０は、申し入れ者宛督促メールの一例について示した概略図である。図２０に示すように、申し入れ者宛督促メールでは、アップロードされた契約書ファイルの案件について、受諾者から本人認証書類の送付がないので、このままでは契約書が破棄される旨、破棄を望まないのであれば、受諾者に連絡を取り、本人認証書類を送付するよう伝えて欲しい旨のメッセージが記載されている。
【００６４】
次に、削除手段を構成する削除プログラムについて説明する。削除プログラムは、本実施形態では、デジタル契約サーバ４に実装されたプログラムであり、あるタイミングで自動実行されるプログラムとなっている。削除プログラムは、例えば毎日午前１時に自動実行されるようにすることができる。この時刻が到来すると、削除プログラムは、案件情報ＤＢＦの最初のレコードにポインタを移動させる。「受諾者正仮別」のフィールドに仮会員である旨の情報が記録されており、「受諾日時」のフィールドに値があり（Ｎｕｌｌ値ではなく）、受諾日時から三週間（２１日）以上経過しており、且つ「受諾者認証日」のフィールドがＮｕｌｌ値であるかどうか判断する。これらの条件がすべて成立する場合、削除プログラムはそのレコードの案件のタイムスタンプファイルをストレージサーバ６から削除する。即ち、そのレコードの「ファイル保存場所」のフィールドを読み取り、それにしたがってストレージサーバ６の該当ディレクトリからタイムスタンプファイルを削除する。尚、案件情報ＤＢＦのレコード自体は、後で参照する場合もあるので、そのまま残しておく。案件情報ＤＢＦの各レコードには、本人認証書類が届かずにタイムスタンプファイルが削除された案件を特定するための情報を記録するフィールドとして「無認証削除」という名前のフィールドが設けられており、削除プログラムは、このフィールドに真値を記録して削除の記録を残しておく。
【００６５】
削除プログラムは、順次ポインタを次のレコードに移動させ、同様の処理を繰り返す。最後のレコードまで処理が終わると、削除プログラムは終了である。このような削除プログラムにおいて、実際のレコードの削除はストレージサーバ６上のＤＢＭＳが行うので、本実施形態の削除手段は、削除プログラム、デジタル契約サーバ４、ＤＢＭＳ、ストレージサーバ６、管理用クライアント７等によって構成されている。尚、削除プログラムによる削除処理は、法律的には、当事者の一方の本人認証がされなかったということであるので、最初から契約が無かったという扱い（契約不成立擬制）になる。
【００６６】
上記のようなプロセスで処理される各契約案件については、各会員において処理状況を閲覧することが可能となっている。この閲覧には、契約が完了した案件（契約書ファイルにタイムスタンプが付与されて保存されている状態）についての閲覧も含まれる。
図６に示すように、会員トップページは、上から順に四つのエリアに区切られている。即ち、大きくは、上下に「契約未完了一覧」と表記されたエリア（以下、未完了エリア）と「契約完了一覧」のエリア（以下、完了エリア）に分かれている。未完了エリアは、「自分から相手」と表記されたエリアと、「相手から自分」と表記されたエリアに分かれている。「自分から相手」と表記されたエリアは、この会員が申し入れ者として契約書ファイルを送った案件がリスト表示されるエリアである（以下、未完了申し入れ者エリアと呼ぶ）。「相手から自分」と表記されたエリアは、この会員に対して契約が申し込まれた（契約書ファイルが送られた）案件がリスト表示されるエリアである（以下、未完了受諾者エリア）と呼ぶ。完了エリアについても同様であり、「自分から相手」と表記されたエリア（以下、完了済み申し入れ者エリア）には、この会員が申し入れ者である契約案件のうち契約が完了したもののリストが表示され、「相手から自分」と表記されたエリア（以下、完了済み受諾者エリア）には、この会員が契約を申し込まれた案件のうち契約が完了したもののリストが表示されるようになっている。
【００６７】
また、各エリアにおいて、各案件の情報を表示したリストの各行の末尾には、「表示」と記載されたコマンドボタン（表示ボタン）５７と「削除」と記載されたコマンドボタン（削除ボタン）５８がそれぞれ設けられている。表示ボタン５７は、その行の案件の契約書ファイルを表示するものであり、削除ボタン５８は、その案件の情報が会員トップページに表示されないようにするものである。
前述したように、図４に示すトップページにおいてログインボタンがクリックされると、会員ＩＤ及びパスワードが入力するページが表示され、これらが正しく入力されて送信ボタンがクリックされると、会員トッププログラムが起動する。
【００６８】
図２１は、会員トッププログラムの概略を示したフローチャートである。図２１に示すように、会員トッププログラムは、案件情報ＤＢＦを開き、最初のレコードにポインタを移動させる。そして、入力された会員ＩＤをメモリ変数から読み出し、その会員ＩＤが「申し入れ者会員ＩＤ」の値に一致するかどうか判断する。一致する場合には、この会員が契約を申し入れた案件ということになる。この場合、会員トッププログラムは、そのレコードの「受諾日時」の欄がＮｕｌｌ値かどうか判断する。Ｎｕｌｌ値であれば、その案件は受諾者がまだ受諾していない案件である。この場合、会員トッププログラムは、そのレコードの「案件ＩＤ」、「案件名」、「受諾者名前」のフィールドの値をそれぞれ読み出す。そして、会員トップページ表示用のＨＴＭＬファイル（以下、会員トップ用ファイル）の所定の箇所に、「案件名」のフィールドの値と、「受諾者名前」のフィールドの値を嵌め込む。この際の所定の箇所とは、図４に示す未完了申し入れ者エリアである。「受諾日時」のフィールドがＮｕｌｌ値でない場合、受諾者が受諾した案件であるので、会員トッププログラムは、そのレコードの「案件ＩＤ」、「案件名」、「受諾者名前」のフィールドの値をそれぞれ読み出し、完了済み申し入れ者エリアに表示されるよう会員トップ用ファイルに嵌め込む。
【００６９】
一方、そのレコードにおいて、入力された会員ＩＤが「申し入れ者会員ＩＤ」には一致しない場合、会員トッププログラムは、「受諾者会員ＩＤ」に一致するかどうか判断する。一致する場合、その案件は契約を申し入れられた案件ということになる。この場合、会員トッププログラムは、「受諾日時」の欄がＮｕｌｌ値である場合、その案件はまだ受諾していない案件であるので、会員トッププログラムは、そのレコードの案件の「案件ＩＤ」、「案件名」、「申し入れ者名前」のフィールドの値をそれぞれ読み出し、未完了受諾者エリアに表示される会員トップ用ファイルに嵌め込む。また、「受諾日時」がＮｕｌｌ値でない場合、受諾した案件であるので、会員トッププログラムは、そのレコードの「案件ＩＤ」、「案件名」、「申し入れ者名前」のフィールドの値をそれぞれ読み出し、完了済み受諾者エリアに表示される会員トップ用ファイルに嵌め込む。
【００７０】
上記各案件情報の嵌め込みの際、各表示ボタン５７や各削除ボタン５８の嵌め込みも自動的に行われる。より具体的に説明すると、未完了の案件については未完了案件表示プログラムがデジタル契約サーバ４に実装されており、完了済みの案件については完了済み案件表示プログラムがデジタル契約サーバ４に実装されている。会員トッププログラムは、例えば未完了申し入れ者エリアに各案件情報を嵌め込む際、案件ＩＤを引数にして未完了案件表示プログラムを起動するコマンドが埋め込まれた状態で各表示ボタン５７を末尾に嵌め込むようにする。未完了受諾者エリアも同様で、案件ＩＤを引数にして未完了案件表示プログラムを起動するよう各表示ボタン５７を埋め込む。完了済み申し入れ者エリアについては、会員トッププログラムは、案件ＩＤを引数にして完了済み案件表示プログラムを起動するコマンドが埋め込まれた状態で表示ボタン５７を埋め込む。完了済み受諾者エリアについても同様である。また、デジタル契約サーバ４には、特定の案件のレコードを案件情報ＤＢＦから削除する案件削除プログラムが実装されている。各削除ボタンは、その行に表示された案件の案件ＩＤを引数にてい案件削除プログラムを実行するコマンドが埋め込まれた状態で嵌め込まれるようになっている。
【００７１】
会員トッププログラムは、このようにして、いずれかの条件に該当する場合にいずれかのエリアに契約案件の情報が表示されるよう会員トップ用ファイルに情報を嵌め込む。順次ポインタを次ぎのレコードに移動しながら、同様の判断と、該当する場合の情報の嵌め込みを繰り返す。一つのエリアに既に一つの案件の情報が嵌め込まれている場合、次の案件の情報はその下に表示されるようにする。即ち、各案件がリストの形で表示されるようにする。最後のレコードまで処理が終了すると、会員トッププログラムは、各情報を嵌め込んだ会員トップ用ファイルを、アクセスしてきた端末に送って表示させる。これで、会員トッププログラムは終了である。
【００７２】
会員トップページの未完了申し入れ者エリア又は未完了受諾者エリアにおいて、いずれかの表示ボタン５７がクリックされると、その案件の案件ＩＤを引数にして未完了案件表示プログラムが起動される。未完了案件表示プログラムは、案件ＩＤに従ってログ付き契約書ファイルをストレージサーバ６から読み取り、アクセスしてきた端末に送信して表示させる。
完了済み申し入れ者エリア又は完了済み受諾者エリアにおける表示ボタン５７については、タイムスタンプが付与された案件の契約内容の閲覧であるため、上記とは異なる構成となっている。即ち、完了済み案件表示プログラムは、タイムスタンプファイルとしてのタイムスタンプトークンを利用して検証を行いつつログ付き契約書ファイルを表示するプログラムとなっている。
【００７３】
より具体的に説明すると、完了済み案件表示プログラムには、タイムスタンプトークンを利用して検証を行う検証プログラムがプラグインプログラムとして組み込まれている。完了済み案件プログラムは、渡された案件ＩＤに従って該当する案件のログ付き契約書ファイルをストレージサーバ６から読み取って開く。検証プログラムは、ログ付き契約書ファイルを所定のアルゴリズムで暗号化し、ハッシュ値を得る。また、該当する案件のタイムスタンプトークがストレージサーバ６から読み出され、同様に検証プログラムが所定のアルゴリズムでハッシュ値を得る。検証プログラムは、二つのハッシュ値が一致するかどうは判断し、一致すれば改ざんはないとして真正である旨の戻り値を出す。完了済み案件表示プログラムは、真正である旨の戻り値があると、アクセスしてきた端末に対し、読み出したログ付き契約書ファイルにそのファイルが真正である検証された旨のメッセージを添えて送信し、端末に表示させる。尚、万が一ハッシュ値が一致しない場合、真正でない旨の戻り値が出力されるので、完了済み案件表示プログラムは、ログ付き契約書ファイルを送信するが、一致しない旨のエラーメッセージを端末に返信して表示させる。
【００７４】
また、本実施形態のシステムは、システムの利用料を課金する際の特徴的な構成を備えている。以下、この点について説明する。
前述したように、本サイトは会員制であるので、本システムの利用料金は、月額の会員料金（基本料金）がベースになっている。そして、これに利用量に応じた料金（従量料金）が付加される料金体系になっている。基本料金は、正式会員としての登録がされたときから課金され、退会するまで課金される。従量料金の課金において特徴的なのは、契約金額に応じた額の課金や情報の保存期間に応じた額の課金がされるようになっている点である。
【００７５】
より具体的に説明すると、図８に示すように、案件情報入力ページには、契約金額入力欄５９が設けられている。また、図５に示すように、案件情報ＤＢＦの各レコードには、「契約金額」のフィールドが設けられている。図８に示す送信ボタン４９がクリックされると、アップロードプログラムは、契約金額入力欄５９に入力されている数字を案件情報ＤＢＦの当該レコード（新規に追加したレコード）の「契約金額」のフィールドに記録するようになっている。
【００７６】
一方、図１６に示すように、管理用メニューページには、「契約金額課金処理」と表記されたコマンドボタン（以下、契約金額課金処理ボタン）６１が設けられている。契約金額課金処理ボタン６１には、契約金額に応じた課金処理を行うためのページ（以下、契約金額課金処理ページ）へのリンクが埋め込まれている。
契約金額課金処理ページは、図示は省略するが、契約が成立した案件（受諾ボタンがクリックされた案件）であって契約金額課金処理がされていない案件の情報がリスト表示されるようになっている。具体的には、案件情報ＤＢＦには、契約金額課金処理が済んだことを示す情報を記録するフィールド（図５中不図示）が設けられており、このフィールドに偽値が記録されていて且つ受諾日がＮｕｌｌ値ではないレコードを検索してリスト表示するプログラムがデジタル契約サーバに実装されている。
【００７７】
契約金額課金処理ページに表示されたリストの各行には、「契約金額チェック」と表記されたコマンドボタンが設けられている。このコマンドボタンには、該当する案件の契約書ファイルに記載された契約金額(以下、ファイル内記載金額）と、案件情報入力ページで入力された契約金額（案件情報ＤＢＦに記録されている契約金額、以下、入力金額）との間に違いがないかチェックするためのプログラム（以下、契約金額チェックプログラム）起動コマンドが埋め込まれている。契約金額チェックプログラムについては、幾つかの異なった構成が考えられるが、例えば、入力金額の数字に一致するテキストが契約書ファイル内にあるかどうかテキスト検索するプログラムが考えられる。契約金額は契約書に必ず記載されるものであるから、案件情報入力ページで正しく入力されていれば、同一のテキスト（契約金額の数字）が契約書ファイル内に存在する筈である。したがって、曖昧検索等の機能を適宜使用しながら、同一のテキストがあるかどうか判断し、あれば、入力金額が正しいとする。
【００７８】
もし、検索の結果、同一テキストが契約書ファイル内にないと判断された場合、契約金額チェックプログラムは、契約金額の訂正入力ページを管理用クライアント７に表示する。訂正入力ページには、入力金額とファイル内記載金額が一致しなかった旨のメッセージを表示するととにに、契約書ファイルを管理用クライアント７を別ウインドウで表示するコマンドボタンと、契約金額を訂正して入力する訂正入力欄が設けられている。担当者は、契約書ファイルの内容を別ウインドで見ながら、正しい契約金額を確認し、訂正入力欄に入力する。訂正入力ページには、登録ボタンが設けられており、登録ボタンがクリックされると、訂正入力欄で入力された金額が当該案件のレコードの「契約金額」の欄に上書きされて登録されるようになっている。
【００７９】
入力金額とファイル内記載金額の整合性チェックについては、上記テキスト一致で判断するやり方の他、入力金額が消費税抜きで入力され、ファイル内記載金額が税込みで記載されている可能性もあるので、入力金額に消費税を加算した上で一致するものがあるか検索するようにしても良い。また、入力金額が年額で入力され、ファイル内記載金額が月額で記載されている場合もあるので、入力金額を１／１２した上で一致するものがあるかどうか検索するようにしても良い。消費税を加算した上での検索や１／１２にした上での検索も、プログラムによって自動化できるのは勿論である。
【００８０】
また、図８に示すように、案件情報入力ページには、情報保存期間入力欄６０が設けられている。また、案件情報ＤＢＦの各レコードには、「情報保存期間」のフィールド（図５中不図示）が設けられている。情報保存期間とは、契約に関する情報の保存期間であるが、重要なのはタイムスタンプファイルであり、その保存期間ということである。この他、案件情報ＤＢＦにおける当該レコードの保存期間も含めることがある。図８に示す送信ボタン４９がクリックされると、アップロードプログラムは、情報保存期間入力欄６０に入力されている値を案件情報ＤＢＦの当該レコード（新規に追加したレコード）の「情報保存期間」のフィールドに記録するようになっている。
【００８１】
一方、図１６に示すように、管理用メニューページには、月次請求処理と表記されたコマンドボタン（以下、月次請求ボタン）６２が設けられている。月次請求ボタン６２には、デジタル契約サーバに実装されている月次請求プログラムの起動コマンドが埋め込まれている。
本実施形態では、正式会員登録をしていることによる料金は無料で、システムの利用があった場合（システムを利用して契約を締結させた場合）のみ利用料金がかかる取り決めとなっている。即ち、月次請求プログラムは、各会員ＩＤを順次検索キーにして案件情報ＤＢＦを検索し、その月のシステム利用がされているかどうかレコードの情報から判断し、利用がされている場合のみ課金用ファイルを生成して課金情報を記録するプログラムとなっている。
【００８２】
より具体的に説明すると、月次請求プログラムは、会員情報ＤＢＦに記録されている最初の会員ＩＤを検索キーにして案件情報ＤＢＦを検索し、その月に新たに成立した案件のレコード（「受諾日」の値が〆月の期間に入っているレコード）があるかどうか判断し、あれば、課金用ファイルを新たに生成する。課金用ファイルは、例えばストレージサーバ６の保存部に保存されるファイルである。そして、契約金額に応じた利用料金と、情報保存期間に応じた従量料金とを課金用ファイルに記録する。即ち、「契約金額」のフィールドの値を読み取り、その金額に一定の割合（例えば３％）を乗じた金額を利用料金とする。保存期間に応じた料金としては、例えば、３年までは定額の５千円とし、以降は１ヶ月当たり１０円というような従量料金が考えられる。この場合、「情報保存期間」のフィールドには、３年を越える分の月数が記録されるようにしておき、月時請求プログラムがその値を読み出して従量料金を自動計算する。このようにして算出ないし決定した契約金額依存料金と保存期間依存料金とを、生成した課金用ファイルに記録する。
【００８３】
月次請求プログラムは、案件情報ＤＢＦ内の全てのレコードを検索し、別の案件についてその月に新たに成立していればその案件についても契約金額依存料金と保存期間依存料金を算出ないし決定し課金用ファイルに追加して記録する。すべてのレコードについて検索した後、次に、案件情報ＤＢＦの最初のレコードに戻り、今度は受諾者会員ＩＤが一致するレコードがあるかどうか検索する。一致するレコードがあれば、受諾者としての利用料金（これについては従量料金はない）を課金用ファイルに追加して記録する。尚、申し入れ者としての利用が無く受諾者としての利用のみの場合には、ここで新たに課金用ファイルを生成し、課金情報を記録する。受諾者会員ＩＤについても同様に全てのレコードに検索を行い、別の一致するレコードがあれば、同様に受諾者としての利用料金を課金用ファイルに追加して記録する。
【００８４】
このようにして一つの会員ＩＤについて利用の有無のチェックと利用がある場合の利用料金の課金用ファイルへの記録をした後、月次請求プログラムは、会員情報ＤＢＦに記録されている次の会員ＩＤについて、同様に案件情報ＤＢＦを検索し、利用がある場合の課金用ファイルの生成と記録とを同様に行う。
月次請求プログラムは、上記のような作業を全ての会員ＩＤについて行う。そして、各課金用ファイルにおいてその月の合計の請求金額が計算され、各課金用ファイルが各会員宛の請求書としてそれぞれ印刷されると、月次請求プログラムは終了である。
尚、上記例において、受諾者の利用料金についても、契約金額に応じた料金としても良いし、情報保存期間に応じた料金を追加しても良い。また、システムの利用の有無にかかわらず、正式会員登録をしている限り基本料金を課金するようにしても良い。さらに、基本料金は、仮の会員登録の時点から発生するとしても良い。
【００８５】
以上説明した構成を有する本実施形態のデジタル契約システムの動作について、以下に説明する。申し入れ者は、本人認証書類を運営会社に送って予め正式な会員登録をしておく。そして、受諾者との間で契約内容に合意したらワープロソフトを使用してデジタルファイルとしての契約書ファイルを作成する。契約書ファイルは、弁護士のような専門家が作成する場合もある。作成された契約書ファイルは、申し入れ者が操作する第一の端末３１のの保存部（ハードディスクやＵＳＢメモリ等）に保存される。また、本システムの利用に際しては受諾者も少なくとも仮の会員登録をしていることが必要であり、申し入れ者は受諾者に対してこの点を伝え、本サイトにアクセスして仮会員登録をしておくよう要請する。受諾者は、この要請に応じて仮会員登録をする。受諾者は、この際に入力、送信した自分のメールアドレス（会員ＩＤ）を申し入れ者に伝えておく。また、自分で設定した任意の仮パスワードは、後のアクセスの際や正式会員登録の際に必要になるので、忘れないようにしておく。
【００８６】
申し入れ者は、第一の端末３１を操作し、ブラウザによりインターネット１を介してデジタル契約サイトにアクセスし、図２に示すトップページにおいてログインボタン４２をクリックする。そして、会員ＩＤ及びパスワード（正式なパスワード）を入力して本人認証された正式な会員としてログインする。
ログイン後に第一の端末３１に表示される会員トップページ（図３）において、契約書登録ボタン４４をクリックする。そして、表示されるファイルアップロードページ（図７）において、ファイル選択欄の参照ボタン４５をクリックして契約書ファイルを指定した後、アップロードボタン４６をクリックする。そして、表示される案件情報入力ページで、案件名や受諾者メールアドレスを入力する。受諾者メールアドレスは、受諾者の会員ＩＤ（正式又は仮）としてのメールアドレスである。
【００８７】
申し入れ者は、案件情報入力ページで所定事項を入力した後、送信ボタン４９をクリックし、アップロードプログラムを起動させる。アップロードプログラムは、契約書ファイルを第一の端末３１からデジタル契約サーバ４に送信させ、デジタル契約サーバ４は、送信された契約書ファイルをマスタファイルとしてストレージサーバ６の保存部に保存する。そして、入力された案件情報は、案件情報ＤＢＦに追加される新規レコードに記録される。次に、アップロードプログラムは、契約書ファイルのＨＴＭＬファイルへの変換と受諾ボタン５０の埋め込みを行い、変換済み契約書ファイルをストレージサーバ６の保存部に保存する。その後、アップロードプログラムは、通知メール（図１１）の生成と受諾者のメールアドレスへの送信を行い、さらに契約書ファイルへのログ記録を行い、ログ付き契約書ファイルをストレージサーバ６の保存部に保存する。
【００８８】
受諾者は、第二の端末３２において通知メールを受信し、通知メールの内容を確認する。そして、記載されているＵＲＬをクリックする。この結果、閲覧用認証ページ（図１３）が第二の端末３２に表示される。受諾者は、閲覧用認証ページにおいて会員ＩＤ及びパスワードを入力する。受諾者が仮会員登録の段階である場合には仮パスワードを入力し、正式会員である場合、正式会員としてのパスワードを入力する。
会員ＩＤ及びパスワードが正しく入力されて送信ボタン５１がクリックされると、契約書ファイル閲覧プログラムが動作し、第二の端末３２宛に該当案件の変換済み契約書ファイルが送信される。受諾者は、第二の端末３２上に表示される変換済み契約書ファイルを閲覧し、契約内容を確認する。契約内容が受諾できるようであれば、受諾ボタン５０がクリックされる。これにより受諾処理プログラムが動作し、受諾の旨を案件情報ＤＢＦの該当レコードに記録するとともにログ付き契約書ファイルにログ記録を追記してファイルを更新し、さらにタイムスタンプ手段にタイムスタンプ要求を送信する。タイムスタンプ手段は、送信されたハッシュ値に時刻情報を統合してタイムスタンプトークンを返信する。受諾処理プログラムは、受信したタイムスタンプトークンをタイムスタンプファイルとしてストレージサーバ６に保存する。
【００８９】
受諾者が仮会員登録の段階である場合、受諾者は所定期間内に本人認証書類を運営会社に送付する。運営会社の担当者は、送付された本人認証書類を確認し、本人認証できると判断した場合は、管理用クライアント７を操作し、認証書類受領情報の登録を行う。これで、一連のデジタル契約手続きが終了したことになる。
受諾者が仮会員登録の段階であり、且つ所定期間内に本人認証書類が届かない場合、督促メール送信手段により督促メールが受諾者と申し入れ者の双方に送信される。その後の所定期間内に本人認証書類が届けば、上記のように認証書類受領情報登録が行われるが、届かない場合、削除手段が自動的にタイムスタンプファイルを削除し、案件情報ＤＢＦには契約不成立擬制の旨の情報が登録される。
【００９０】
上記のようなデジタル契約手続きのステップを踏みながら、正式会員である場合、会員トップページに適宜アクセスし、自分が関わっている契約案件の進捗状況を閲覧する。即ち、図２に示すトップページでログインボタン４２をクリックし、会員ＩＤ及びパスワードを入力して会員トップページを端末に表示する。そして、例えば自分が申し入れ者で、未完了のものの契約内容を確認したいのであれば、未完了申し入れ者エリアに表示されている案件のうちいずれかの案件を表示した行における表示ボタン５７をクリックする。これにより、その案件のログ付き契約書ファイルが端末に表示される。自分が受諾者である案件の場合には、未完了受諾者エリアに表示されているいずれかの表示ボタン５７をクリックする。
【００９１】
また、自分が申し入れ者で契約済みの案件については、完了済み申し入れ者エリアのいずれかの案件の表示ボタン５７をクリックする。これにより、完了済み案件表示プログラムが起動し、検証プログラムが実行されて改ざんが無いかどうかを表示しつつログ付き契約書ファイルが端末に表示される。自分が受諾者である場合、完了済み受諾者エリアのいずれかの案件の表示ボタン５７をクリックする。
何らかの事情で契約を破棄した場合や、管理の必要が無くなった案件については、会員において適宜削除処理をする。即ち、図６に示す会員トップページにおいて、削除する案件の削除ボタン５８をクリックし、情報を案件情報ＤＢＦから削除する。尚、会員情報ＤＢＦとしてマスターデータと会員用のデータの二つを容易しておき、案件削除プログラムは、会員用のデータの方だけにおいてレコードを削除するようにしても良い。この場合、会員トッププログラムは、会員用のデータに基づいて会員トップページを表示するようプログラミングされる。
【００９２】
以上の構成及び動作に係る本実施形態のデジタル契約システムによれば、デジタル契約書によって契約が取り交わされ、デジタル契約書を保管する形なので、契約案件の管理や整理が容易である。その上、デジタル契約書はタイムスタンプが付与されて保存されるので、ある時点において確かに契約が成立し契約書が存在したことや契約書が改ざんされていないことの証明について高い信頼性が得られる。
また、相手側が仮会員登録の段階、即ち本人認証をしていない段階でも契約書をアップロードして相手側に受諾ボタンをクリックさせてタイムスタンプを付与することが可能であり、システム上で契約を締結することが可能である。その場合も、所定期間内に本人認証書類が届かない案件についてはタイムスタンプファイルを削除して契約が無かったことにできるので、問題は生じない。
【００９３】
前述したように、従来のデジタル契約の場合、契約に先立って電子証明書を取得しておく必要があり、そのためには認証局に本人認証書類を事前に送って電子証明書を発行してもらう必要がある。このために手間がかかり、契約成立のチャンスを逃してしまうこともあり得る。即ち、ある案件について上記のようなメリットがあるためにデジタル契約にしょうとし、受諾者にその旨を伝えたとする。この際、受諾者は電子証明書を取得していないと従来はデジタル契約できない。このため、電子証明書の取得を面倒がり、契約を見合わせてしまうこともある。そうなるとまずいので、申し入れ者も従来の書面での契約を選択することになってしまい、デジタル契約のメリットを享受することができなくなる。一方、本実施形態では、受諾者側が仮会員登録の段階でも契約を締結することができるので、このような問題はない。尚、仮会員登録の段階でも契約を締結することができるという点は、本システムの利用のハードルが低いことを意味し、その普及を促進する効果もある。
【００９４】
また、本実施形態では、受諾者が仮会員登録の場合であって所定期間内に本人認証書類が届かない場合にはタイムスタンプファイルを自動的に削除する削除手段が設けられているので、本人認証書類が届かない案件のタイムスタンプファイルをいちいち削除する手間が省ける。そして、所定期間内に本人認証書類が届かない案件について督促メールが自動で送られるので、いちいち督促メールを手動で送る手間が省ける。さらに、督促メールは、申し入れ者にも送信されるので、申し入れ者からも本人認証書類の送付を要請してもらうことができる。このため、契約不成立擬制の扱いになってしまう可能性を少なくすることができる。
【００９５】
尚、タイムスタンプ付き契約書ファイルは、紙の契約書を保管していた場合とほぼ同等の法律的効果を持つし、税務上も同様の証拠価値を有する。この際、タイムスタンプ付き契約書ファイルは、印紙税法上の「文書」には該当しないので、印紙を貼る必要がない（物理的に貼ることができない）。つまり、印紙代がかからない点で低コストになる。この点は、日常的に大量の契約を取り交わしている会社や個人にとって極めて有益である。尚、上述したように、本実施形態では、会員登録自体にかかる料金は無料で、システムの利用に応じた金額のみが請求される仕組みとなっている。この利用料金を、印紙税よりも十分に安い金額（例えば印紙税の半額）としておけば、システムの利用は一層促進されるものと考えられる。
【００９６】
また、上記実施形態では、契約書ファイル内に当該契約書ファイルをアップロードしたログ記録（誰がいつアップロードしたか）と、当該契約書ファイルの内容について受諾者が受諾した旨のログ記録（誰がいつ受諾したか）とが書き込まれ、これらログ記録を含んだ状態で契約書ファイルのタイムスタンプ要求がされている。これは、契約の成立（申し入れの意思表示と受諾の意思表示）を示す情報とその契約内容の情報の双方についてタイムスタンプを要求しているのであり、それらについてタイムスタンプファイルが返信され、それが保存される。即ち、契約の存在とその内容の否改ざん性のみならず契約の成立自体についてもタイムスタンプで立証されることになる。このため、本システムの利用価値は極めて高くなっている。
【００９７】
そして、上記ログ記録には、契約書ファイルの送信元である第一の端末３１の端末識別情報としてのＩＰアドレスの記録が含まれており、また受諾の旨を送信した第二の端末３２の識別情報としてのＩＰアドレスの記録が含まれている。即ち、誰がどの端末を使用して申し入れを行い、誰がどの端末を使用して受諾したかという情報が記録され、そについてタイムスタンプが付与されるようになっている。したがって、端末の特定についてのタイムスタンプで立証されるので、本システムの利用価値がさらに高くなっている。つまり、Ａというものが、例えば111.222.33.44というＩＰアドレスの端末を保有していたことが判っていて、タイムスタンプ付きの契約書ファイルに、1111.222.33.44からその契約書ファイルが送信された旨が記録されていれば、Ａという者がその契約書ファイルを送信したことの蓋然性が高いと推認されるのである（そのこと自体、契約書ファイルにログ記録されているが）。 尚、端末識別情報としてＩＰアドレスではなくマックアドレスをログ記録するようにしても良い。
【００９８】
また、契約の成立に関するタイムスタンプについては、契約書ファイルと別のファイルとで行うようにすることも可能である。例えば、契約書アップロードのログ記録をしたファイルと、契約について受諾した旨のログ記録をしたファイルとを別に設け、契約書ファイルとともにこれらファイルについてタイムスタンプ要求を発しても良い。アップロードのログ記録ファイルと受諾のログ記録ファイルとは一つのファイルにしても良い。このような技術構成によっても同様の結果が得られる。但し、契約書ファイルとログ記録ファイルとについて内容を関連づける技術手段が別途必要である。例えば、ログ記録ファイルとの双方に案件ＩＤが自動的に書き込まれるようにし、案件ＩＤで関連づける構成である。上記実施形態の構成は、このような関連づけが不要な点で技術構成がシンプルになるメリットがある。
【００９９】
上記実施形態では、申し入れ者（契約書ファイルをアップする者）は正式会員でなければならない（本人認証されていなければならない）としたが、仮会員登録の段階でも可能とするようにしても良い。この場合も、所定期間内に本人認証書類が届かない場合、申し入れ者宛に督促メールが届くようにし、それでも本人認証書類が届かない場合、削除手段がタイムスタンプファイルを削除して案件情報ＤＢＦに無認証削除の登録をするようにする。この場合は、受諾者に削除した旨を通知する方が好ましい。尚、申し入れ者が仮会員登録の段階で契約書ファイルをアップする場合、受諾者は正式会員登録をしている場合もあり、また受諾者も仮会員登録の段階である場合もある。後者の場合、双方の本人認証書類が所定期間内に届かない限り、タイムスタンプファイルは削除され、契約不成立擬制の扱いということになる。
【０１００】
尚、本人認証書類が届かない状態でタイムスタンプファイルを保存したままとしておくこと（契約不成立擬制をしないこと）の問題として、幾つかの重要な問題が考えられる。例えば、実在しない人物の名前で契約をしたり（架空契約）、他人の名前で勝手に契約したり（成りすまし）、という問題である。別の問題としては、申し入れ者が受諾者の名前を勝手に入力して送信する場合である（受諾者の名前は架空の場合もあり、自在する人の名前を勝手に入力する場合もある）。これは、いわば契約のでっち上げということになる。いずれの場合も、真正な本人認証書類を運営会社に送ることができないので、タイムスタンプファイルは削除され、契約不成立擬制という扱いになる。本実施形態の削除手段は、上記のような悪意のある違法なシステムの利用を防止するという点で重要な技術的意義を有する。
【０１０１】
本願発明のデジタル契約システムで提供されるサービス（本サービス）は、上記実施形態のようにそれ専門のウェブサイトにおいて提供される場合の他、あるサイトの付帯サービスとして提供することも可能である。この場合、このあるサイト（以下、便宜上、通常サイトと呼ぶ）において商品又はサービスが顧客に提供されていて、その商品又はサービスの提供において顧客との間で契約を結ぶ場合のように、この通常サイトの運営者自体が契約の当事者の場合があり得る。この場合の好適な構成としては、顧客側から見た場合、その通常サイトにおいて本サービスが提供されているかのようにすることが考えられる。この構成の一例について、以下に説明する。
【０１０２】
上記のような構成の一例として、本サービスをいわゆるＡＳＰとして通常サイトの運営者に提供することが考えられる。即ち、上記アップロードプログラム等の各種プログラムや会員トップページ等の各ページを提供する各ＨＴＭＬファイルを通常サイトの運営者に提供し、自己のサーバに実装してもらうようにすることが考えられる。この場合は、通常サイトの運営者において本願発明のデジタル契約システムが構築されることになる。別の構成としては、サーバは、本サービスを提供する運営会社のものとしておき、通常サイトのサーバ（以下、提供先サーバ）から本サービスの運営会社のサーバ（以下、提供元サーバ）に遷移させて本サービスを提供することができる。この場合に好適なのは、顧客側にはサーバ遷移を意識させないようにすることであり、恰も通常サイトにおいて本サービスが提供されているように見せることである。
【０１０３】
図２２を使用して、より具体的に説明する。図２２は、本願発明の別の実施形態の主要部を示した概略図である。図２２に示す例は、通常サイトが不動産仲介会社のサイトとなっている。
図２２（１）に示すように、この提供先サイトのあるページには、「デジタル契約システムログイン」と表記されたコマンドボタン（ログインボタン）５４が設けられており、ログインボタン５４をクリックすることで、本人認証ページが表示され、会員ＩＤ及びパスワードが正しく入力されて送信ボタンがクリックされると、図２２（２）に示すデジタル契約のページ（以下、契約ページ）が表示されるようになっている。
【０１０４】
図２２（１）のページ自体は、提供先サーバによって提供されているものであるが、本人認証ページや図２２（２）の契約ページは、提供元サーバによって提供されている。即ち、図２２（１）のページのログインボタン５４には、提供先サーバへのリンクが埋め込まれており、提供先サーバに保存された本人認証ページを開くコマンドが埋め込まれている。
この場合、図２２（１）と（２）とを比較すると分かるように、端末に表示されるページで異なるのは、中央の大きなフレーム（メインフレーム）内の情報のみであり、その他のメニューバー等は全く同じように表示されるようになっている。これは、通常サイトの運営者からＨＴＭＬファイルを提供してもらい、メインフレーム内の情報のみを提供元で書き換えて提供しているからである。
契約ページのコンテンツ自体は、図７に示すファイルアップロードページや図８に示す案件情報入力ページと同様である。契約書ファイルを指定し、相手先のメールアドレスを案件情報として入力した上で送信ボタン５５をクリックするページとなっている。
【０１０５】
また、ログイン後には、自分が関与している案件の状況を閲覧できるようになっている。即ち、契約ページには、「状況閲覧」と表示されたコマンドボタン（以下、状況閲覧ボタン）５６が設けられている。状況閲覧ボタン５６をクリックすると、各案件の状況が閲覧できるようになっている。状況閲覧のためのページについては、図示は省略するが、図６に示す会員トップページと同様であり、完了、未完了に分け、さらに申し入れ者、受諾者に分け、四つのエリアにおいて契約案件がリスト表示されるようになっている。そして、アップロードボタン等も同様に設けられている。
【０１０６】
このような構成の利用例について説明すると、例えば、顧客が不動産仲介会社の営業所を訪れ、不動産の説明を受け、売買契約を結ぶことを決心したとする。担当者は、営業所の窓口に設置されている第一の端末３１を操作し、デジタル契約サイトにアクセスする。そして、顧客からメールアドレスを聞き、顧客の仮会員登録をする。この際、顧客に任意の仮パスワードを決めてもらい、それを入力して会員情報ＤＢＦに登録されるようにする。いったんログアウトした後、不動産仲介会社の会員ＩＤ及び正式パスワードでもう一度ログインを行う。そして、契約書ファイルを選択した上で送信ボタンをクリックし、契約書ファイルをアップロードする。この際、相手先メールアドレスとして、仮会員登録の際に入力したメールアドレスを入力する。アップロードプログラムは、前述したようにログ付き契約書ファイルの保存や通知メールの送信等を行う。
【０１０７】
顧客は、自宅に戻り、パソコンで通知メールを受信し、記載されているＵＲＬをクリックしてサイトにアクセスする。この際、営業所で決めた仮パスワードを入力し、ログインする。そして、変換済み契約書ファイルをダウンロードして受諾ボタン５０をクリックする。この結果、受諾処理プログラムが動作し、タイムスタンプ要求が送信されてタイムスタンプファイルがストレージサーバ６に保存される。契約はこれで成立したことになり、その後、顧客が本人認証書類を提供元の会社に送る。これにより、システムがタイムスタンプファイルを削除して契約不成立擬制をすることが避けられる。尚、本人認証書類については、顧客が提供先会社（不動産仲介会社）に提出し、提供先会社が書類を確認した上で提供元会社に転送するようにしても良い。
尚、不動産仲介会社の担当者が第一の端末１を操作して各契約案件の状況を閲覧する際には、状況閲覧ボタン５６がクリックされるが、他の顧客の情報が見られれしまうのは適切ではないので、第一の端末３１のディスプレイが顧客の目に触れない状態で行われることが好ましい。
【０１０８】
上記各実施形態において、仮会員登録における仮パスワードの性質について説明する。上記説明から解るように、仮パスワードは、本人認証をしていない段階で発行されるものであり、高い融通性を持たせることは好ましくない。このため、上述した各実施形態では、一契約案件限りにおいてのパスワードとしている。即ち、会員情報ＤＢＦの各レコードに「使用有無」のフィールドが設けられており、このフィールドの値をチェックすることによって過去に使用歴のある仮パスワードについては使用できない（真正とは判断しない）構成となっている。
【０１０９】
仮パスワードが他の案件でも使えるようになってしまう場合の問題は、幾つか考えられる。例えば、ある案件で契約の受諾者となり、仮会員登録のために任意の仮パスワードを自分で設定してシステムに登録したとする（又はシステムで自動生成されてシステムから通知されたとする）。その案件については仮パスワードでアクセスして変換済み契約書ファイルをダウンロードして受諾ボタンをクリックするのであるが、この仮パスワードがシステム上で他の案件にも使えるようなものであるとすると、この者は仮パスワードで別の案件の契約書ファイルをアップロードできることになる。この場合、その別の案件についても所定期間内に本人認証書類が届かない限り削除するようにシステムを構成すれば良いのであるが、システムの構成が複雑になる問題があるし、悪意を持った者が仮パスワードの段階で大量に契約書ファイルをアップロードしてシステムに攻撃を加えるような事態も考えられる。このような点を考慮し、上記各実施形態では、一つの契約案件の受諾者という場合についてのみ、仮パスワードが有効であるようにしている。
【０１１０】
但し、本システムの利用を促進するため、正式会員登録の前の仮登録の段階で契約書ファイルのアップロードを認めることもあり得る。即ち、前述したように、正式会員になるために仮会員登録をするが、この段階で契約書ファイルのアップロードが可能なようにシステムを構成することもできる。この場合も、所定期間内に本人認証書類が届かない場合には、真正な本人からの契約の申し入れが無かったと扱うことになり、タイムスタンプファイルは削除される。また、仮パスワードの段階での契約書ファイルのアップロードについては、申し入れ者の正式会員登録（本人認証）が済んだ後に受諾者への通知メールを送信するとか、又はタイムスタンプ要求を送信するというような構成とすることがより好ましい。尚、仮会員登録の段階で何件もの契約書ファイルをアップロードできるとすると、上述したような悪意の利用が考えられるので、１件のみの契約書ファイルのアップロードに限るようにすることが好ましい。
【０１１１】
尚、上記説明から解るように、本願発明の実施形態としては、申し入れ者も受諾者も仮会員登録の段階で為される構成が採用されることもある。この場合は、双方について所定期間内に本人認証書類が届かなければ、タイムスタンプファイルを削除して契約不成立擬制の扱いをすることになる。
【０１１２】
また、仮パスワードの融通性を下げる技術構成としては、上記の他、仮パスワードの有効時間を設定し、この時間内にアクセスが無かったら仮パスワードを無効とすることも考えられる。具体的には、通知メール内のハイパーリンクがクリックされてデジタル契約サーバ４にアクセスがあった際、そのセッション日時を取得し、その日時と、案件情報ＤＢＦに記録されているアップロード日時とを比較して、それが所定時間内（例えば２４時間内）でなければ、その仮パスワードは真正ではないとするようにプログラミングすることが考えられる。もしくは、仮会員登録の際の日時が会員情報ＤＢＦの当該レコードに記録されるようにし、仮会員登録の日時と比較して所定時間内であればその仮パスワードが真正であるとようプログラミングしても良い。
【０１１３】
また、別の例としては、第一の端末３１から契約書ファイルをアップロードしたセッションが維持されている場合に限り、仮パスワードが有効であるとすることもできる。例えば、不動産仲介会社の例で言えば、受諾者は仮会員登録の際に自分の携帯電話のメールアドレスを会員ＩＤとして送信して登録しておき、契約書ファイルのアップロードの際、このアドレスを相手先メールアドレスとして入力する。アップロードプログラムは、契約書ファイルのアップロード送信のセッションにおいて、アクセスの環境変数からセッションを特定できる情報（例えば送信元のＩＰアドレスとセッション開始日時）を取得してメモリ変数に格納しておく。通知メールは顧客の携帯電話に届き、顧客は、届いた通知メールを開いて同様に受諾ボタンをクリックする。この間、担当者は、会員トップページからログアウトしないように（セッションを維持するように）しておく。受諾情報処理プログラムは、デジタル契約サーバ４に対して維持されている全アクセスをチェックし、ＩＰアドレスとセッション開始日時がメモリ変数のものと一致するかどうか判断する。一致するものがあれば、セッションが維持されているとして、その仮パスワードが真正であるとする。
【０１１４】
上記各実施形態では、会員情報ＤＢＦは認証サーバ５に保存され、契約書ファイルや案件情報ＤＢＦ等の契約に関する情報はストレージサーバ６に保存されるよう構成された。これは、会員情報ＤＢＦは個人情報やパスワード等の個人情報を記録しているため、より高いセキュリティを確保する必要があるからであるが、会員情報ＤＢＦ等をストレージサーバ６に保存するようにしストレージサーバ６に認証サーバ５の役割も持たせる構成が採用されることもある。
【０１１５】
また、上記各実施形態では、削除手段はタイムスタンプファイルを自動的に削除するものであったが、自動的ではない構成もあり得る。例えば、本システムの運営会社の担当者が管理用クライアント７を操作し、あるトリガーとなる信号をデジタル契約サーバ４に送り、これによってサーバ上の削除プログラムが動作する構成であっても良い。また、所定期間過ぎても本人認証書類が届いていない案件を随時チェックし、管理用クライアント７を操作して一件ずつ削除する構成であっても良い。この場合、削除手段は、管理用クライアント７と、レコードを特定して削除するストレージサーバ６上のＤＢＭＳとによって構成される。
【０１１６】
尚、契約書ファイル、ログ付き契約書ファイル、タイムスタンプファイルの保存や読み出しについては、ストレージサーバ６内の場所の情報（ディレクトリ）を案件情報ＤＢＦに登録して利用する場合の他、ファイル名の付け方をルール化し、それに従って保存や読み出しをするようにしても良い。例えば、契約書ファイルのファイル名として案件ＩＤを兼用するとのルールを設定し、それに従って契約書ファイルの保存や読み出しをするようにする。
【０１１７】
また、上記各実施形態において、契約書アップロードに際して受諾者が少なくとも仮会員登録されていなければならず、仮会員登録は受諾者が予め自ら第二の端末３２により行うと説明したが、受諾者の仮会員登録を申し入れ者がやるようにしても良い。以下、この実施形態について説明する。
図２３は、受諾者の仮会員登録を申し入れ者ができるようにした実施形態における案件情報入力ページの一例の概略図である。図２３に示すように、この実施形態では、受諾者が会員登録されていない場合には仮会員登録をして欲しい旨のメッセージが表示されるようになっており、受諾者が会員登録されていない場合に仮会員登録させるためのコマンドボタン（以下、受諾者仮会員登録ボタン）４７が設けられている。受諾者仮会員登録ボタン４７には、相手先会員登録ページへのリンクが埋め込まれている。
【０１１８】
図２４は、相手先会員登録ページの一例について示した概略図である。図２４に示すように、相手先会員登録ページには、まず、ここでの会員登録は仮のものであり、正式には受諾者から本人認証書類（法人であれば登記簿謄本＋印鑑証明、個人であれば住民票＋印鑑証明）の提出が必要な旨のメッセージが表示される。そして、相手先会員登録ページには、受諾者についての各情報（法人・個人の別、名前、住所等）を入力する欄がそれぞれ設けられている。相手先会員登録ページには、確認ボタン４８が設けられており、確認ボタン４８には、確認ページへのリンクが埋め込まれている。確認ページでは、入力された情報が確認のために表示されるようになっているとともに、登録ボタンが設けられている。登録ボタンには、入力された情報をメモリ変数に一時的に格納するとともに会員情報ＤＢＦに新規レコードを追加して登録するプログラム（受諾者仮会員登録プログラム）の起動コマンドが埋め込まれている。
【０１１９】
受諾者仮会員登録プログラムは、追加した新規レコードの各フィールドに、相手先会員登録ページで入力された情報を記録して登録する。この際、会員ＩＤについては、同様にメールアドレスを兼用するが、メールアドレスは申し入れ者が入力しておりメモリ変数に格納されているので、それを読み出して会員情報ＤＢＦの新規レコードに記録する。また、この新規レコードの「正仮種別」のフィールドには、仮会員登録である旨の情報が記録される。受諾者仮会員登録プログラムは、次に仮パスワードを自動生成し、会員情報ＤＢＦの新規レコードの「仮パスワード」のフィールドに記録すれば、終了である。その後、案件情報入力ページに戻り、送信ボタン４９をクリックして契約書ファイルをアップロードする。尚、正式会員の者を誤って仮会員登録してしまないよう、入力されたメールアドレスで最初に会員情報ＤＢＦを検索し、正式会員登録されている者であるかどうかチェックし、正式会員登録されていれば、その旨のエラーメッセージを送信してプログラムを終了するようにすることが望ましい。
【０１２０】
この実施形態では、通知メールには、申し入れ者によって仮会員登録された旨と、自動生成された仮パスワードとが記載されている。そして、契約書ファイル閲覧用のＵＲＬが記載されているとともに、アクセスした際には仮パスワードを入力してログインして欲しい旨が記載されている。受諾者は、記載されている仮パスワードを入力してログインした後、契約書ファイルを閲覧する。
【０１２１】
この実施形態では、仮パスワードをメールで通知するので、セキュリティの面で多少問題がある。この問題を無いようにした構成として、仮パスワードを自動生成するのではなく、やはり受諾者において任意に設定してもらうようにする構成が考えられる。即ち、通知メールを受けて受諾者がアクセスした際、ログイン画面で任意のパスワードを設定するようにしても良い。また、個人情報の入力についても、申し入れ者が行うのではなく、通知メールを受けた受諾者が契約書ファイルの閲覧のためにアクセスした際に行う構成であっても良い。但し、申し入れ者が受諾者の個人情報を入力する構成の方が、受諾者の労力が少なくて済み、申し入れ者が受諾者に対して本システムの利用を促すという意味では（本システムの普及を促進する意味では）好適である。
尚、上記各実施形態において、会員ＩＤとしては、メールアドレスを兼用する構成の他、文字や数字を組み合わせたものをシステムが自動生成する構成であっても良く、利用者において任意に設定するものであっても良い。任意に設定する場合は、他に同じものが登録されていないかをチェックした上で登録を許可するプログラムが実装される。
【符号の説明】
【０１２２】
１ インターネット
２ イントラネット
３１ 第一の端末
３２ 第二の端末
４ デジタル契約サーバ
５ 認証サーバ
６ ストレージサーバ
７ 管理用クライアント
８ タイムスタンプサーバ
【特許請求の範囲】
【請求項１】
当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末にネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報が真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えていることを特徴とするデジタル契約システム。
【請求項２】
前記契約書アップロード手段は、その契約書ファイルがアップロードされた旨を当該契約書ファイル内にログ記録するものであって、前記受諾情報処理手段は、受諾者が受諾した旨をその契約書ファイル内にログ記録するものであり、前記受諾情報処理手段は、これらログ記録がされた契約書ファイルについて前記タイムスタンプ要求を送信するものであることを特徴とする請求項１記載のデジタル契約システム。
【請求項３】
前記契約書アップロード手段は、その契約書ファイルをアップロード送信した前記第一の端末を識別する情報を当該契約書ファイル内にログ記録するものであって、前記受諾情報処理手段は、受諾の旨を送信した前記第二の端末を識別する情報を当該契約書ファイル内にログ記録するものであり、前記受諾情報処理手段は、これらログ記録がされた契約書ファイルについて前記タイムスタンプ要求を送信するものであることを特徴とする請求項２記載のデジタル契約システム。
【請求項４】
前記受諾情報処理手段は、前記第二の端末から仮認証情報が送信された際、その仮認証情報が発行された際に送信された契約書ファイルで契約しようとしてる案件についてのみその仮認証情報が真正に送信されたものとする手段であることを特徴とする請求項１、２又は３記載のデジタル契約システム。
【請求項５】
前記受諾情報処理手段は、前記第二の端末から仮認証情報が送信された際、その仮認証情報が発行されてから又は前記契約書ファイルのアップロード送信がされてから所定の時間内である場合に限りその仮認証情報が真正に送信されたものとする手段であることを特徴とする請求項１、２又は３記載のデジタル契約システム。
【請求項６】
前記受諾情報処理手段は、前記第一の端末から契約書ファイルがアップロード送信された後、前記第二の端末から仮認証情報が送信された際、当該契約書ファイルをアップロード送信したセッションが維持されている場合に限りその仮認証情報が真正であるとする手段であることを特徴とする請求項１、２又は３記載のデジタル契約システム。
【請求項７】
前記仮認証情報発行手段は、前記契約書がアップロード送信される際、前記第一の端末において受諾者の情報を申し入れ者に入力させて送信させることで当該受諾者の仮認証情報を発行して保存部に保存する手段であることを特徴とする請求項１乃至６いずれかに記載のデジタル契約システム。
【請求項８】
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって本人認証書類を受領していない案件について、前記削除手段が前記タイムスタンプファイルを保存部から削除する前に、本人認証書類の提出を督促する督促メールを前記第二の端末に送信する督促メール送信手段を備えていることを特徴とする請求項１乃至７いずれかに記載のデジタル契約システム。
【請求項９】
前記督促メール送信手段は、当該案件について契約書ファイルをアップロード送信した前記第一の端末に対しても前記督促メールを送信するものであることを特徴とする請求項８記載のデジタル契約システム。
【請求項１０】
システムの利用料金を請求するためのファイルである課金用ファイルを生成して保存部に保存する手段が設けられており、
前記案件情報ファイルに保存された情報には、各契約案件における契約金額の情報が含まれており、
前記契約書ファイルが前記第一の端末からアップロード送信される際、当該契約書ファイルで契約しようとしている案件の契約金額の情報を前記第一の端末において入力させて送信させ、前記案件情報ファイルに保存する手段が設けられており、
特定の契約案件について、前記案件情報ファイルに保存されている契約金額と、その契約案件の契約書ファイルに実際に記載されている契約金額とが一致するかをチェックするためのプログラムと、契約金額が一致する場合に、契約金額に応じた金額を課金用ファイルに記録するプログラムとを備えていることを特徴とする請求項１乃至９いずれかに記載のデジタル契約システム。
【請求項１１】
システムの利用料金を請求するためのファイルである課金用ファイルを生成して保存部に保存する手段が設けられており、
前記案件情報ファイルに保存された情報には、各契約案件における前記タイムスタンプファイルの保存期間が含まれており、
前記契約書ファイルが前記第一の端末からアップロード送信される際、当該契約書ファイルで契約しようとしている案件について前記タイムスタンプファイルの保存期間の情報を第一の端末において入力させて送信させ、前記案件情報ファイルに保存する手段が設けられており、
特定の契約案件について、前記案件情報ファイルに保存されている保存期間の情報に応じて料金を算出又は決定して課金用ファイルに記録するプログラムとを備えていることを特徴とする請求項１乃至１１いずれかに記載のデジタル契約システム。
【請求項１２】
当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末とのネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件について、その後に申し入れ者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件であって申し入れ者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって受諾者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えていることを特徴とするデジタル契約システム。
【請求項１】
当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末にネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報が真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えていることを特徴とするデジタル契約システム。
【請求項２】
前記契約書アップロード手段は、その契約書ファイルがアップロードされた旨を当該契約書ファイル内にログ記録するものであって、前記受諾情報処理手段は、受諾者が受諾した旨をその契約書ファイル内にログ記録するものであり、前記受諾情報処理手段は、これらログ記録がされた契約書ファイルについて前記タイムスタンプ要求を送信するものであることを特徴とする請求項１記載のデジタル契約システム。
【請求項３】
前記契約書アップロード手段は、その契約書ファイルをアップロード送信した前記第一の端末を識別する情報を当該契約書ファイル内にログ記録するものであって、前記受諾情報処理手段は、受諾の旨を送信した前記第二の端末を識別する情報を当該契約書ファイル内にログ記録するものであり、前記受諾情報処理手段は、これらログ記録がされた契約書ファイルについて前記タイムスタンプ要求を送信するものであることを特徴とする請求項２記載のデジタル契約システム。
【請求項４】
前記受諾情報処理手段は、前記第二の端末から仮認証情報が送信された際、その仮認証情報が発行された際に送信された契約書ファイルで契約しようとしてる案件についてのみその仮認証情報が真正に送信されたものとする手段であることを特徴とする請求項１、２又は３記載のデジタル契約システム。
【請求項５】
前記受諾情報処理手段は、前記第二の端末から仮認証情報が送信された際、その仮認証情報が発行されてから又は前記契約書ファイルのアップロード送信がされてから所定の時間内である場合に限りその仮認証情報が真正に送信されたものとする手段であることを特徴とする請求項１、２又は３記載のデジタル契約システム。
【請求項６】
前記受諾情報処理手段は、前記第一の端末から契約書ファイルがアップロード送信された後、前記第二の端末から仮認証情報が送信された際、当該契約書ファイルをアップロード送信したセッションが維持されている場合に限りその仮認証情報が真正であるとする手段であることを特徴とする請求項１、２又は３記載のデジタル契約システム。
【請求項７】
前記仮認証情報発行手段は、前記契約書がアップロード送信される際、前記第一の端末において受諾者の情報を申し入れ者に入力させて送信させることで当該受諾者の仮認証情報を発行して保存部に保存する手段であることを特徴とする請求項１乃至６いずれかに記載のデジタル契約システム。
【請求項８】
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって本人認証書類を受領していない案件について、前記削除手段が前記タイムスタンプファイルを保存部から削除する前に、本人認証書類の提出を督促する督促メールを前記第二の端末に送信する督促メール送信手段を備えていることを特徴とする請求項１乃至７いずれかに記載のデジタル契約システム。
【請求項９】
前記督促メール送信手段は、当該案件について契約書ファイルをアップロード送信した前記第一の端末に対しても前記督促メールを送信するものであることを特徴とする請求項８記載のデジタル契約システム。
【請求項１０】
システムの利用料金を請求するためのファイルである課金用ファイルを生成して保存部に保存する手段が設けられており、
前記案件情報ファイルに保存された情報には、各契約案件における契約金額の情報が含まれており、
前記契約書ファイルが前記第一の端末からアップロード送信される際、当該契約書ファイルで契約しようとしている案件の契約金額の情報を前記第一の端末において入力させて送信させ、前記案件情報ファイルに保存する手段が設けられており、
特定の契約案件について、前記案件情報ファイルに保存されている契約金額と、その契約案件の契約書ファイルに実際に記載されている契約金額とが一致するかをチェックするためのプログラムと、契約金額が一致する場合に、契約金額に応じた金額を課金用ファイルに記録するプログラムとを備えていることを特徴とする請求項１乃至９いずれかに記載のデジタル契約システム。
【請求項１１】
システムの利用料金を請求するためのファイルである課金用ファイルを生成して保存部に保存する手段が設けられており、
前記案件情報ファイルに保存された情報には、各契約案件における前記タイムスタンプファイルの保存期間が含まれており、
前記契約書ファイルが前記第一の端末からアップロード送信される際、当該契約書ファイルで契約しようとしている案件について前記タイムスタンプファイルの保存期間の情報を第一の端末において入力させて送信させ、前記案件情報ファイルに保存する手段が設けられており、
特定の契約案件について、前記案件情報ファイルに保存されている保存期間の情報に応じて料金を算出又は決定して課金用ファイルに記録するプログラムとを備えていることを特徴とする請求項１乃至１１いずれかに記載のデジタル契約システム。
【請求項１２】
当事者間での契約をデジタルデータによって行わせるデジタル契約システムであって、
申し入れ者によって操作される第一の端末と受諾者によって操作される第二の端末とのネットワークを介して接続されているサーバコンピュータと、
各契約案件の情報を記録した案件情報ファイルを含む各種ファイルを保存した保存部と、
本人認証書類の受領した後にその本人認証書類によって特定される者に対して正式認証情報を発行し、発行された正式認証情報を保存部に保存する正式認証情報発行保存手段と、
本人認証書類を受領していない段階で特定の者に対して仮認証情報を発行し、発行された仮認証情報を保存部に保存する仮認証情報発行保存手段と、
第一の端末から契約書ファイルをネットワークを介してサーバコンピュータにアップロード送信させる契約書ファイル送信手段と、
契約書ファイル送信手段により契約書ファイルがアップロード送信された際、契約書ファイルを保存部に保存する契約書ファイル保存手段と、
保存部に保存された契約書ファイルを第二の端末に送信して受諾者に閲覧させる契約書ファイル閲覧手段と、
契約書ファイルを閲覧した受諾者が第二の端末において当該契約について受諾の旨の入力をした際、ネットワークを介してその旨の情報を受信する受諾情報受信手段と、
受諾情報受信手段が受諾の旨の情報を受信した際、契約書ファイルと、契約書ファイルがアップロード送信された旨及び契約内容について受諾者が受諾した旨を記録したファイルとについてタイムスタンプ手段に対してタイムスタンプ要求を送信する受諾情報処理手段と、
タイムスタンプ要求を受信したタイムスタンプ手段が、タイムスタンプ要求送信時における前記各ファイルの存在とその内容の非改ざん性を証明するためのファイルであるタイムスタンプファイルを返信した際、そのタイムスタンプファイルを受信して保存部に保存するタイムスタンプファイル保存手段と
を備えており、
前記契約書ファイルアップロード手段は、前記第一の端末から申し入れ者の正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記契約書ファイルを保存するものであり、
前記受諾情報処理手段は、前記第二の端末から正式認証情報又は仮認証情報のいずれかが真正に送信された場合に限り、前記タイムスタンプ要求を送信するものであり、
さらに、
前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件について、その後に申し入れ者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第一の端末から仮認証情報が送信されて前記契約書ファイルを保存した案件であって申し入れ者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と、
前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件について、その後に受諾者の本人認証書類を受領した旨の情報を案件情報ファイルに記録して登録する認証書類受領情報登録手段と、
案件情報ファイルに記録された情報に従い、前記第二の端末から仮認証情報が送信されて前記タイムスタンプ要求を送信した案件であって受諾者の本人認証書類を受領していない案件について、前記タイムスタンプファイルを保存部から削除する削除手段と
を備えていることを特徴とするデジタル契約システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２０１２−１４５９９６（Ｐ２０１２−１４５９９６Ａ）
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願番号】特願２０１１−１６７８（Ｐ２０１１−１６７８）
【出願日】平成２３年１月７日（２０１１．１．７）
【出願人】（５０９１５１９４６）
【Ｆターム（参考）】
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願日】平成２３年１月７日（２０１１．１．７）
【出願人】（５０９１５１９４６）
【Ｆターム（参考）】
[ Back to top ]