JP6042766B2 - 電子取引システム、電子取引方法、及びプログラム - Google Patents

Description

本発明は、電子取引の技術に関する。

商品等の受発注に伴う売買契約等の各種の契約を伴う取引、特に、企業間での継続的な取引では、電子証明書を利用した電子商取引が普及してきている。ここでは、電子証明書（もしくは電子証明書を用いた電子署名）により、電子商取引契約の主体である企業やユーザ、利用端末、文書等を認証したり証明したりすることが行われる。

これに関連した技術として、例えば、特開２０１１−４５０１６号公報（特許文献１）には、複数の端末装置に共通して発行された端末証明書と所定サービスの提供を可能にするサービス証明書および所定サービスの提供契約を個別に識別可能な契約識別コードを対応付けた契約情報を予め記憶し、端末証明書で認証された端末装置から受け取った契約識別コードに対応するサービス証明書を端末装置に送信するサーバ装置と、端末証明書を予め記憶し、所定サービスの提供契約が成立した後に成立した契約識別コードを取得し、端末証明書を用いてサーバ装置から認証されると、サーバ装置から契約識別コードに対応するサービス証明書を受信する端末装置と、を具備する通信システムが記載されている。これにより、インターネット経由でサービス提供する際に、電子証明書を利用してサービス提供先及びサービス提供に使用する機器を認証して、機器・サーバ間で安全かつ簡易に通信を行うことを可能とするものである。

また、特開平１０−３２７１４７号公報（特許文献２）には、サービス提供装置から契約内容を含む契約情報を契約者である各サービス享受者のサービス享受装置に送信し、契約情報を受信した各サービス享受装置で契約情報にサービス享受者の署名を付けた一者署名付き契約情報を作成してサービス提供装置に送信し、サービス提供装置では各サービス享受装置から送信された一者署名付き契約情報を受信し、まとめて一つの文書にし、サービス提供者の署名を付けたサービス提供者署名付き契約情報を作成し、保管するとともに各サービス享受装置に送信することで、オープンなネットワーク環境において電子商取引に必要な認証・公証サービスを実現する技術が記載されている。

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

電子商取引における契約処理を支援するための電子契約システムを構築する際に、電子証明書を用いてユーザや利用端末、文書等の認証や証明を行うためには、電子証明書を発行する認証局が必要となるが、その際、いわゆる認定認証局を用いる場合と非認定認証局を用いる場合とが考えられる。

認定認証局とは、いわゆる電子署名法における認証業務認定制度により認定された認証局を指す。一般的に認定認証局を用いる場合、電子証明書自体の安全性・信頼性は比較的高いものの、証明書取得手続きが煩雑かつ高額で取得者の負荷が高いことから、広く普及しにくい状況がある。一方で、認定認証局以外の非認定認証局を用いる場合は、安全性・信頼性が劣る場合があり得ることから、同様に広く普及しにくい状況があるものの、証明書取得手続きは認証局を運営する事業者に依存するとはいえ比較的容易であるため、利用の容易さという点では優る。

電子証明書を用いた電子署名により契約処理を行う電子契約システムを構築する際に、証明書の発行主体としてコストの観点や柔軟な対応などの利用の容易さを考慮して非認定認証局を用いる場合でも、以下の課題が生じ得る。例えば、企業等において、多忙な決裁権者が直接決裁処理を行う代わりに部下等の担当者が代理で決裁する（例えば、契約書に電子署名する）ような処理がよく行われる。このとき、相手方にとっては、当該決裁（電子署名）が本当に決裁権者本人により、もしくは決裁権者の意思に基づいて行われたものであるのか、担当者が独断で行ったものかが分からないため、相手方は契約を否認されるのではないかというリスクを負いつつ契約を締結せざるを得ない状況となる。

また、電子契約による電子商取引の仕組み・サービスを導入する企業にとっては、例えば、取引先と基本契約を締結してサービスを利用可能とする毎に、当該取引先についての電子証明書を非認定認証局から取得して渡す（もしくは当該取引先が個別に非認定認証局から取得する）必要があり、運用が煩雑となる。また、取引先にとっては、基本契約を締結した企業が複数あった場合に、これらの企業毎に電子契約により電子商取引を行う仕組みやシステムが異なる場合には、それぞれの企業毎にシステムを使い分ける必要が生じ、運用が煩雑となる。

そこで本発明の目的は、電子契約などの電子的な取引サービスの導入企業や取引先の運用負荷を低減するとともに、取引先がサービス導入企業との間で安全に電子契約の締結などの電子的な取引を行うことを可能とする電子取引システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による電子取引システムは、第１の取引主体と第２の取引主体との間の電子取引を支援するシステムであって、１つ以上の前記第１の取引主体毎の、前記第１の取引主体についての電子取引に係る文書に対して電子署名を行う電子署名部と、前記第１の取引主体についての前記文書に対して電子署名を行う際の承認処理を行う署名申請処理部と、前記各第１の取引主体についての前記文書を保持する文書記録部と、を有するものである。

前記署名申請処理部は、前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に、第１の承認画面のアドレス情報を含む第１の電子メッセージを作成して前記第１の承認権者に送付し、前記第１の承認画面を介して前記第１の承認権者から入力された承認結果を取得し、全ての前記第１の承認権者から承認する旨の結果を取得した場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行う。ここで、前記署名申請処理部は、前記第１の承認権者からの承認結果を受け付ける際に、前記第１の承認画面を介して、前記第１の承認権者が承認を行うために必要な前記第１の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第１の承認権者による承認を許可する。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、電子取引サービスの導入企業や取引先の運用負荷を低減するとともに、取引先がサービス導入企業との間で安全に電子取引を行うことが可能となる。

本発明の実施の形態１である電子取引システムの構成例について概要を示した図である。 本発明の実施の形態１における非認定認証局を用いた電子取引サービスの構成例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業が電子取引サービスを利用可能となるまでの処理の流れの例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業が潜在的な取引先から見積依頼を受けた場合の処理の流れの例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業と取引先との間で個別取引の契約が締結される場合の処理の流れの例について概要を示した図である。 本発明の実施の形態１における文書に電子署名を行うために必要な所定の承認を得るための電子署名申請処理の流れの例について概要を示した図である。 本発明の実施の形態２における電子署名申請処理の流れの例について概要を示した図である。 本発明の実施の形態３におけるサービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。 本発明の実施の形態３におけるサービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの別の例について概要を示した図である。 従来技術における認定認証局を用いた電子契約サービスの構成例について概要を示した図である。 従来技術における非認定認証局を用いた電子契約サービスの構成例について概要を示した図である。 従来技術における非認定認証局を用いた電子契約サービスの他の構成例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。本発明の実施の形態では、電子取引サービスとして、主に電子契約を例に挙げて説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

図１１は、従来技術における認定認証局を用いた電子契約サービスの構成例について概要を示した図である。この場合は、電子契約により電子商取引を行うための取引基本契約を締結したサービス導入企業（図中では「Ａ社（３００ａ’）」）と、取引先（図中では「取引先２（４０２’）」）が、それぞれ、電子契約システム１０１を運営するサービスベンダと電子契約サービスの利用契約を締結することで、電子契約システム１０１を介して契約を締結することが可能となる。

このとき、サービス導入企業と取引先がそれぞれ個別に認定認証局２０１に対して電子証明書の取得申請を行い、電子契約サービスで用いるための電子証明書を取得する。なお、他の企業等（図中では「Ｂ社（３００ｂ’）」や「取引先１（４０１’）」、「取引先３（４０３’）」など）が新たに電子契約サービスを利用する場合は、個別に電子契約システム１０１を運営するサービスベンダと電子契約サービスの利用契約を締結し、認定認証局２０１から電子証明書を取得する。このように、電子契約サービスを利用するサービス導入企業や取引先がそれぞれ個別に電子証明書取得処理を行う必要があり、費用面、手続面で大きな負荷となる。

図１２は、従来技術における非認定認証局を用いた電子契約サービスの構成例について概要を示した図である。この例では、電子契約サービスを導入して電子契約により電子商取引を行うサービス導入企業（図中では「Ａ社」、「Ｂ社」）が、それぞれ、システムベンダ１０１’により個別に開発された電子契約システム（図中では「Ａ社電子契約システム（１００ａ）」、「Ｂ社電子契約システム（１００ｂ）」）により、取引基本契約を締結した各取引先（図中では「取引先１（４０１’）」〜「取引先３（４０３’）」）と電子契約を締結して電子商取引を行う。電子契約の際に用いる電子証明書は、各サービス導入企業（電子契約システム）がそれぞれ非認定認証局２００から取得する。取引基本契約を締結した各取引先が用いる電子証明書について取得して発行するという登録業務を行う構成とすることも可能である。

図１２の例では、「取引先２（４０２’）」については、「Ａ社」と「Ｂ社」の双方と取引基本契約を締結しており、双方と電子契約により電子商取引を行うことが可能である。しかしながら「Ａ社電子契約システム（１００ａ）」と「Ｂ社電子契約システム（１００ｂ）」は個別に開発された別システムであるため、それぞれのインタフェースや仕様等は必ずしも同一とは限らない。従って、「取引先２（４０２’）」にとっては、取引の相手方が「Ａ社」であるか「Ｂ社」であるかによって電子契約システムを使い分ける必要があり、煩雑である。

図１３は、従来技術における非認定認証局を用いた電子契約サービスの他の構成例について概要を示した図である。この例では、上述の図１２の構成において各サービス導入企業が個別に保有していた電子契約システム（「Ａ社電子契約システム（１００ａ）」、「Ｂ社電子契約システム（１００ｂ）」）の機能を、システムベンダ１０１’がＡＳＰ（Application Service Provider）としてネットワーク経由でサービスとして提供する構成としたものである。サービス導入企業（図中では「Ａ社（３００ａ’）」、「Ｂ社（３００ｂ’）」）のシステム運用の負荷は低減されるものの、「取引先２（４０２’）」が電子契約システムを使い分ける必要があることなどは図１２の例の場合と同様である。

＜実施の形態１＞
本発明の実施の形態１は、電子契約を含む電子取引サービスを提供する、すなわち取引主体間の電子取引を支援する電子取引システムである。本発明の実施の形態１である電子取引システムは、上記のような課題に対応するため、非認定認証局に対する証明書登録業務（本人確認、証明書の発行要求および配布）を、サービス導入企業や取引先に代わって一括して行うことで、サービス導入企業のシステム運用の負荷を低減させる。また、電子取引システムは、全てのサービス導入企業が共通に利用可能なシステムとして構成することで、取引の相手方のサービス導入企業に関わらず、取引先が電子取引システムを使い分けることを不要とする。また、電子取引システムは、電子取引システムが保管する契約書等の文書に対してサービス導入企業や取引先が電子証明書を利用して電子署名を行う際に、承認権者の意思に基づいて承認が行われることを保証するような電子署名申請プロセスを有することで、取引先がサービス導入企業との間で安全に電子契約を締結することを可能とする。

［システム構成］
図１は、本発明の実施の形態１である電子取引システムの構成例について概要を示した図である。電子取引システム１００は、例えば、電子取引サービスを提供するシステムベンダ等の企業により運営され、サーバ機器やクラウドコンピューティング環境における仮想サーバ等により構成される情報処理システムである。

この電子取引システム１００は、図示しないインターネット等のネットワークを介して、非認定認証局２００や、サービス導入企業（図中では「Ａ社」〜「Ｃ社」）の個別システムであるサービス導入企業個別システム３００（図中の「Ａ社個別システム（３００ａ）」〜「Ｃ社個別システム（３００ｃ）」を総称する）、各サービス導入企業の取引先（図中では「取引先１」〜「取引先５」）の個別システムである取引先システム４００（図中の「取引先１システム（４０１）」〜「取引先５システム（４０５）」を総称する）と通信により接続可能な構成を有する。

電子取引システム１００は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System：データベース管理システム）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムとして実装される、インタフェース部１１０、署名申請処理部１２０、電子署名部１３０（図中の「Ａ社電子署名部（１３０ａ）」〜「Ｃ社電子署名部（１３０ｃ）」を総称する）、証明書登録処理部１４０、取引先管理部１５０、ユーザ管理部１６０、および文書管理部１７０などの各部を有する。なお、これら各部は、電子取引システム１００のサブシステムや、独立したシステムとして実装されていてもよい。

インタフェース部１１０は、電子取引システム１００による電子取引サービスのユーザに対する操作画面等のユーザインタフェースを提供する機能を有する。例えば、インタフェース部１１０は、図示しないＷｅｂサーバプログラムを利用して、ユーザが利用する情報処理端末上のＷｅｂブラウザに対して画面を表示させる。

署名申請処理部１２０は、サービス導入企業や取引先のシステムや担当者から電子取引システム１００が保管する文書に対する電子署名の申請を受け付けて、指定された承認権者に対して承認依頼を行い、全ての承認権者から承認された場合に、後述する電子署名部１３０により対象の文書に対する電子署名を行うという一連の署名申請処理を行う機能を有する。署名申請処理部１２０は、各承認権者に対する承認依頼や承認結果などの承認状況については、データベースやファイルテーブルにより実装される承認状況テーブル（ＴＢ）１２３に記録する。なお、署名申請処理の詳細については後述する。

署名申請処理部１２０は、さらに、署名申請処理の中で用いられる生体認証を実行する機能を有する生体認証処理部１２１、および、指定されたアドレスに対して指定された文書を電子的なメッセージ（単に「メッセージ」あるいは「電子メッセージ」とも呼ぶ。）により送付する機能を有するメッセージ処理部１２２などをさらに有している。これらの各機能については一般的な公知のサーバやプログラム、ライブラリなどを適宜利用することができる。

生体認証処理部１２１は、例えば、承認権者などの使用する端末からユーザＩＤ及び生体情報を取得し、当該取得したユーザＩＤに対応する生体情報を後述するユーザテーブル（ＴＢ）１６１から特定し、取得した生体情報と特定した生体情報を照合することで、承認権者などのユーザの認証を行う。なお、生体情報としては、例えば、指紋、声紋、掌紋、静脈、虹彩などを用いることができる。また、生体認証の方法や手順は、生体情報を用いたものであれば、上記の例に限られない。上記の例では、ユーザＩＤ及び生体情報の入力を必要とする認証方法（ＩＤ付き生体認証）であるが、生体情報のみを入力する（ＩＤレス生体認証）を用いてもよい。ＩＤレス生体認証では、一致する生体情報が登録されていれば、認証が成功したと判断される。

メッセージ処理部１２２は、電子的なメッセージとして、例えば、電子メール、携帯電話などの間で送受信されるショートメッセージ、コンピューター上の専用のアプリケーションなどの間で送受信されるメッセージ（インスタントメッセージとも呼ばれる。）などを用いることができる。なお、アドレス情報は、例えば、後述するユーザテーブル（ＴＢ）１６１から取得することができる。もちろん、電子的なメッセージは上記の例に限られない。

電子署名部１３０は、電子取引サービスの各導入企業についての電子契約等の取引に係る文書データについて、上述した署名申請処理部１２０によって各承認権者からの承認が得られた場合に、対象のサービス導入企業による電子署名を自動で行う機能を有する。このために、各電子署名部１３０は、それぞれ、対象のサービス導入企業について、サービス提供の開始に先立って、後述する証明書登録処理部１４０により非認定認証局２００から電子証明書の発行を受けてこれを保持しておくものとする。なお、本実施の形態では、電子署名部１３０をサービスの導入企業毎に個別に実装するものとしているが、サービス導入企業毎に個別に電子署名を行うことが可能であればまとめて実装することも可能である。

証明書登録処理部１４０は、サービス導入企業からの電子証明書の発行依頼を受けて、サービス導入企業もしくはその取引先についての電子証明書の発行依頼を非認定認証局２００に対して行う登録業務の機能を有する。証明書登録処理部１４０は、さらに、非認定認証局２００に対して証明書発行依頼を行う際に必要となる所定のフォーマットの帳票を作成して出力する帳票作成部１４１を有していてもよい。

取引先管理部１５０は、電子取引システム１００による電子取引サービスを利用する各サービス導入企業がそれぞれ取引基本契約を締結している取引先の情報を取引先テーブル（ＴＢ）１５１に保持するとともに、登録や更新等の管理を行う機能を有する。電子取引システム１００は、取引先管理部１５０により、この取引先ＴＢ１５１を参照することで、当該電子取引システム１００を介して、各サービス導入企業と、これらと取引基本契約を締結している取引先との間でのみ電子契約等の電子取引を行うことが可能となるよう制御することができる。

ユーザ管理部１６０は、電子取引システム１００にアクセスすることができるユーザについて、氏名や所属企業等の属性情報、ユーザＩＤやパスワードなどの認証情報、電子的なメッセージのアドレス情報、アクセス権限などの情報をユーザテーブル（ＴＢ）１６１に保持するとともに、登録や更新等の管理を行う機能を有する。さらに、ユーザ管理部１６０は、電子取引システム１００にアクセスすることができるユーザについて、ユーザＩＤと当該ユーザの生体情報を関連付けた生体認証情報を、ユーザＴＢ１６１に保持するとともに、登録や更新等の管理を行う機能を有する。なお、ＩＤレス生体認証の場合は、生体認証情報にはユーザＩＤは含まれなくてもよい。ここでのユーザは、電子取引システム１００の管理者等に加えて、各サービス導入企業や取引先の担当者や電子署名の際の承認権者などが含まれる。

文書管理部１７０は、電子取引システム１００を介して締結された電子契約等の取引に係る文書の原本を文書テーブル（ＴＢ）１７１に保管するとともに、アクセス権限のあるユーザからのアクセス要求に対して参照を許可する文書管理の機能を有する。当該機能についても、一般的な公知の文書管理システムやプログラム等を適宜利用することができる。なお、「保管する」や「保持する」は、「記録する」、「格納する」とも言える。

非認定認証局２００は、例えば、ＪＩＰＤＥＣ（登録商標：一般財団法人日本情報経済社会推協会））が運営するＪＣＡＮ（登録商標）仕様のパブリック証明書を発行するＪＣＡＮルート認証局などを利用することで、安価に電子証明書の発行を行うことが可能である。このとき、電子取引システム１００の運営企業がＪＩＰＤＥＣから認定（ＬＲＡ認定）を受けてＪＣＡＮ仕様の電子証明書の登録業務を行うことも可能である。なお、このようなパブリック証明書を利用せず、電子取引システム１００の運営企業が自ら非認定認証局２００を構築し、プライベートな電子証明書を発行するようにしてもよい。

各サービス導入企業個別システム３００（図中では「Ａ社個別システム（３００ａ）」〜「Ｃ社個別システム（３００ｃ）」）は、例えば、取引先との間で見積依頼の受付から見積提示、契約の締結、取引に至る一連の電子取引を実施する基幹連携システム等の情報処理システムである。また、各取引先システム４００（図中では「取引先１システム（４０１）」〜「取引先５システム（４０５）」）についても同様に、例えば、サービス導入企業との間で見積依頼から見積の受領、契約の締結、取引に至る一連の電子取引を実施する情報処理システムである。なお、取引先としては、例えば、サービス導入企業にとっての商品等の仕入先だけでなく、顧客などの販売先や保守会社などの委託先等、電子契約を締結する相手方となる企業等が広く含まれる。

図２は、本実施の形態における非認定認証局を用いた電子取引サービスの構成例について概要を示した図である。ここでは、電子取引システム１００がサービス導入企業（図中では「Ａ社（３００ａ’）」、「Ｂ社（３００ｂ’）」）からの依頼を受けて、非認定認証局２００に対する証明書登録業務を一括して行う構成をとることで、サービス導入企業および取引先（図中では「取引先１（４０１’）」〜「取引先３（４０３’）」）が個別に非認定認証局２００から証明書の発行を受ける処理を行うことを不要とする。

また、各サービス導入企業は、電子取引システム１００の運営企業と電子契約等を含む電子取引サービスの利用契約を締結することで、電子取引システム１００により電子契約等の電子取引に係る処理を行うことができるため、各サービス導入企業におけるシステム運用負荷を低減させることが可能となる。また、取引先ＴＢ１５１においてサービス導入企業毎に取引基本契約を締結している取引先の情報を一元的に管理する構成をとることで、取引先（図中では「取引先２（４０２’）」）にとっては相手方のサービス導入企業に関わらず同じ電子取引システム１００を利用することが可能となる。

［処理の流れ］
図３は、サービス導入企業が電子取引サービスを利用可能となるまでの処理の流れの例について概要を示した図である。まず、サービス導入企業が電子取引システム１００の運営企業に対して電子取引サービスの利用契約の申込を行い（Ｓ０１）、所定の要件を満たしていれば契約を締結する（Ｓ０２）。なお、上記の処理は、サービス導入企業および電子取引システム１００の運営企業の人手により行うものとして説明したが、サービス導入企業の個別システム３００と電子取引システム１００との間でシステム的に行うようにしてもよい。

サービス契約が締結されると、電子取引システム１００は、管理者等による手動もしくは自動で、対象のサービス導入企業の属性等の企業情報を、図示しないサービス導入企業マスタ等のテーブルや取引先ＴＢ１５１などに登録する（Ｓ０３）。予め対象のサービス導入企業の取引先が分かっている場合は、電子取引システム１００は、この時点で当該情報について取引先ＴＢ１５１に登録するようにしてもよい。さらに、電子取引システム１００は、管理者等による手動もしくは自動で、対象のサービス導入企業について、対応する電子署名部１３０を実装する（Ｓ０４）。例えば、対象のサービス導入企業用のプログラムやモジュール、サーバ等を適宜実装する。

その後、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示（例えば、Ｗｅｂブラウザ等により電子取引システム１００にアクセスして行う指示）に基づいて、電子取引システム１００に対して当該サービス導入企業についての電子証明書の発行申請を行う（Ｓ０５）。発行申請を受け付けた電子取引システム１００は、証明書登録処理部１４０により、必要に応じて帳票作成部１４１によって申請用帳票を作成した上で、非認定認証局２００に対して電子証明書の発行依頼を行う（Ｓ０６）。

発行依頼を受け付けた非認定認証局２００は、申請内容について所定の判定処理等を行った上で電子証明書を発行し（Ｓ０７）、電子取引システム１００に対して送付する（Ｓ０８）。電子取引システム１００は、受領した電子証明書を対象のサービス導入企業に対応する電子署名部１３０が利用可能なように保存する（Ｓ０９）。サービス導入企業が独自に電子署名を行えるように、電子証明書をサービス導入企業に対しても送付するようにしてもよい。

図４は、サービス導入企業が潜在的な取引先から見積依頼を受けた場合の処理の流れの例について概要を示した図である。まず、潜在的な取引先において、取引先システム４００もしくは担当者等の情報処理端末を介した指示（例えば、Ｗｅｂブラウザ等によりサービス導入企業個別システム３００にアクセスして行う指示）に基づいて、サービス導入企業個別システム３００に対して商品等の見積依頼を行う（Ｓ１１）。サービス導入企業個別システム３００は、依頼内容に基づいて自動もしくは担当者の手動により見積書を作成し（Ｓ１２）、これを電子取引システム１００に自動もしくは担当者の情報処理端末を介した指示に基づいてアップロードして登録依頼を行う（Ｓ１３）。電子取引システム１００は、文書管理部１７０により、アップロードされた見積書を文書ＴＢ１７１に登録する（Ｓ１４）。

さらに、サービス導入企業個別システム３００は、自動もしくは担当者の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、アップロードした見積書に電子署名を行うために必要な所定の承認を得るプロセスである電子署名申請処理を行う（Ｓ１５）。電子署名申請処理の内容については後述する。

電子署名申請処理により、見積書を作成したサービス導入企業において所定の承認権者による承認が得られた場合、電子取引システム１００は、対象のサービス導入企業に対応する電子署名部１３０により、対象の見積書に対して電子署名を行い（Ｓ１６）、これを対象の取引先システム４００もしくは担当者等から閲覧可能となるようアクセス権限等を設定する（Ｓ１７）。このとき、電子取引システム１００は、メッセージ処理部１２２により、電子署名がされた見積書が登録されて閲覧可能となった旨を取引先システム４００もしくは担当者等の情報処理端末に電子メール等のメッセージにより通知するようにしてもよい。

図４の例では、電子署名申請処理が完了したことにより（Ｓ１５）、見積書に電子署名を行って（Ｓ１６）これを閲覧可能としている（Ｓ１７）が、見積書を登録したとき（Ｓ１４）に予め電子署名を行っておき、電子署名申請処理が完了した時点で閲覧可能とする（アクセス制限を解除する）ようにしてもよい。

見積書が閲覧可能となった後、例えば、取引先の担当者等は、情報処理端末を使用して、電子取引システム１００に保管された見積書に対する閲覧要求を行う（Ｓ１８）。ここでは、例えば、情報処理端末上のＷｅｂブラウザ等を利用して、サービス導入企業個別システム３００のＷｅｂサイト等を経由して電子取引システム１００に対して閲覧要求を行うことができる。電子取引システム１００は、要求された見積書を文書ＴＢ１７１から取得して出力することで提示し（Ｓ１９）、取引先の担当者等は、情報処理端末を使用してこれを閲覧する（Ｓ２０）。

図５は、サービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。まず、サービス導入企業と取引先が取引の基本契約を締結する（Ｓ２１）。ここでの契約は書面等により行われるが、可能な場合にはサービス導入企業個別システム３００や取引先システム４００に対して、サービス導入企業や取引先の担当者が情報処理端末を利用してアクセスする等によりシステム的に行ってもよい。

取引基本契約が締結されると、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、対象の取引先についての情報の登録依頼を行う（Ｓ２２）。依頼を受けた電子取引システム１００は、取引先管理部１５０により対象の取引先の情報を対象のサービス導入企業と関連付けて取引先ＴＢ１５１に登録する（Ｓ２３）。

その後、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、対象の取引先についての電子証明書の発行申請を行う（Ｓ２４）。発行申請を受け付けた電子取引システム１００は、申請内容に基づいて、図３の例におけるステップＳ０６〜Ｓ０９での処理と同様の処理によって非認定認証局２００から電子証明書の発行を受け（Ｓ２５）、これを取引先（もしくは取引先システム４００）に対して送付する（Ｓ２６）。

取引先システム４００は、受領した電子証明書を電子署名の際に利用可能なように保存する（Ｓ２７）。なお、上記の証明書の配布処理は、サービス導入企業が新たな取引先と基本契約を締結したときの初回のみの処理であり、当該取引先に電子証明書が配布された後は不要である。

図６は、サービス導入企業と取引先との間で個別取引の契約が締結される場合の処理の流れの例について概要を示した図である。まず、取引先では、見積依頼のときと同様に、取引先システム４００もしくは担当者等の情報処理端末を介した指示に基づいて、サービス導入企業個別システム３００に対して契約の申込みを行う（Ｓ３１）。サービス導入企業個別システム３００は、申込内容や見積書の内容に基づいて自動もしくは担当者の手動により契約書を作成し（Ｓ３２）、これを電子取引システム１００に自動もしくは担当者の情報処理端末を介した指示に基づいてアップロードして登録依頼を行う（Ｓ３３）。

電子取引システム１００は、取引先ＴＢ１５１を参照して対象の取引先が登録されているかを確認した上で、すなわち、対象の取引先が電子取引サービスを利用可能である場合に、文書管理部１７０により、アップロードされた契約書を文書ＴＢ１７１に登録する（Ｓ３４）。さらに、サービス導入企業個別システム３００は、自動もしくは担当者からの指示に基づいて、電子取引システム１００に対して、アップロードした契約書に電子署名を行うために、図４の例におけるステップＳ１５と同様の電子署名申請処理を行う（Ｓ３５）。

電子署名申請処理により、契約書を作成したサービス導入企業において所定の承認権者による承認が得られた場合、電子取引システム１００は、対象のサービス導入企業に対応する電子署名部１３０により、対象の契約書に対して電子署名を行い（Ｓ３６）、当該契約書が対象の取引先システム４００もしくは担当者等から閲覧可能となるようアクセス権限等を設定する（Ｓ３７）。このとき、電子取引システム１００は、メッセージ処理部１２２により、電子署名がされた契約書が登録されて閲覧可能となった旨を取引先システム４００もしくは担当者等の情報処理端末に電子メール等のメッセージにより通知するようにしてもよい。

契約書が閲覧可能となった後、例えば、取引先の担当者等は、情報処理端末を使用して、サービス導入企業個別システム３００のＷｅｂサイト等を経由して電子取引システム１００に保管された契約書に対する閲覧要求を行う（Ｓ３８）。このとき、閲覧可能な文書の一覧リストを電子取引システム１００に対して要求し、得られたリストの中から閲覧対象の契約書を選択する形とすることも可能である。この場合、電子取引システム１００は、文書管理部１７０により、対象の取引先がアクセス権限を有する文書のリストを文書ＴＢ１７１から抽出して提示する。閲覧要求を受けた電子取引システム１００は、要求された契約書を文書ＴＢ１７１から取得して出力することで提示し（Ｓ３９）、取引先の担当者等は、情報処理端末を使用してこれを閲覧し、必要に応じて内容の追記などを行う（Ｓ４０）。

その後、取引先では、自動もしくは担当者の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、契約書に電子署名を行うために、図４の例におけるステップＳ１５と同様の電子署名申請処理を行う（Ｓ４１）。電子署名申請処理により、取引先において所定の承認権者による承認が得られた場合、取引先システム４００は、対象の契約書に対して電子署名を行い（Ｓ４２）、署名された契約書を電子取引システム１００に対してアップロードして原本として保管するよう要求する（Ｓ４３）。電子取引システム１００は、受領した契約書を原本として文書ＴＢ１７１に保管する（Ｓ４４）。

なお、取引先による電子署名の処理（Ｓ４２）を、上記のステップＳ３６と同様に電子取引システム１００上で実施するようにして、電子署名申請処理（Ｓ４１）の承認結果と連携して実行させるようにしてもよい。

図７は、見積書や契約書等の文書に電子署名を行うために必要な所定の承認を得るための電子署名申請処理の流れの例について概要を示した図である。この処理は、例えば、上述の図４の例におけるステップＳ１５や、図６の例におけるステップＳ３５、Ｓ４１において行われる処理である。ここでは、サービス導入企業や取引先において契約等の取引業務を行う担当者等が情報処理端末を利用して電子取引システム１００にアクセスして手動で電子署名申請処理の指示を行う場合を例として示している。

まず、担当者は、担当者端末３１１を利用して電子取引システム１００に対して電子署名の対象となる文書のリストの照会要求を行う（Ｓ５１）。電子取引システム１００は、文書管理部１７０により、対象の担当者が属するサービス導入企業もしくは取引先が電子署名することが可能な文書（例えば、アクセス権限があり、電子署名が未だされていない文書）のリストを文書ＴＢ１７１から抽出して取得することで担当者端末３１１に提示する（Ｓ５２）。

担当者は、担当者端末３１１に提示された文書のリストから、電子署名を行う対象の文書（見積書や契約書）を選択し（Ｓ５３）、さらに、電子署名を行う際に承認を必要とする上長等の承認権者を１人以上選択する（Ｓ５４）。承認権者の選択の際には、例えば、電子取引システム１００においてユーザ管理部１６０により予めユーザＴＢ１６１にユーザ登録されている者（すなわち、電子取引システム１００にアクセス可能な者）から選択するようにしてもよい。その後、担当者端末３１１は、電子取引システム１００に対して電子署名申請の要求を行う（Ｓ５５）。当該要求には、選択された対象の文書を特定する情報と承認権者を特定する情報とが含まれる。

電子署名申請の要求を受けた電子取引システム１００は、署名申請処理部１２０により申請ＩＤを採番して、承認状況ＴＢ１２３に承認状況をトラッキングするためのエントリを登録した上で、メッセージ処理部１２２により、申請ＩＤと、対象の文書を特定するファイル名等の情報と、インタフェース部１１０により提供される承認画面にアクセスするためのアドレス情報であるＵＲＬ（Uniform Resource Locator）の情報とを含む承認要求のメッセージを承認権者毎に作成し、これをメッセージ処理部１２２により各承認権者のアドレスに送信する（Ｓ５６）。なお、インタフェース部１１０は、前記ＵＲＬへのアクセスを受け付けた場合、当該ＵＲＬに対応する承認画面を、アクセス元の端末に出力する。

各承認権者は、承認権者端末３１２により承認要求のメッセージを受領すると（Ｓ５７）、これに含まれる承認画面のＵＲＬにアクセスし、承認画面にログインし、当該承認画面において、申請ＩＤや文書の特定情報に基づいて電子取引システム１００に対して対象の文書に対する閲覧要求をそれぞれ行う（Ｓ５８）。なお、承認権者は、ログインの際、例えば、電子取引システム１００に対する通常のログインＩＤ（ユーザＩＤ等）とパスワードを入力するようにしてもよい。閲覧要求を受けた電子取引システム１００は、要求された文書を文書ＴＢ１７１から取得して出力することで承認画面に提示する（Ｓ５９）。

各承認権者は、それぞれ承認権者端末３１２を使用して文書の内容を確認する（Ｓ６０）。また、各承認権者は、それぞれ承認権者端末３１２に表示された承認対象の文書について承認／不承認の旨の入力を行い、承認結果を確定する旨の入力を行う（Ｓ６１）。このとき、電子取引システム１００は、インタフェース部１１０により、承認結果を確定する旨が入力された承認権者端末３１２の承認画面に、ユーザＩＤおよび生体情報の入力するフィールドなどを出力する。

各承認権者は、それぞれ承認権者端末３１２を使用して自身のユーザＩＤおよび生体情報を入力するとともに、電子取引システム１００に対して生体情報を送信する（Ｓ６２）。このとき承認権者端末３１２は、入力された承認権者のユーザＩＤおよび生体情報とともに、ステップＳ６１で入力された対象の文書の承認結果を示す情報を、電子取引システム１００に対して送信する。なお、生体情報の入力は、例えば、承認権者端末３１２に接続された静脈等の生体情報の読取装置を用いて実現することができる。また、本処理では、ユーザＩＤおよび生体情報に加えパスワードを入力させるようにしてもよいし、ＩＤレス生体認証の場合は生体情報のみを入力させるようにしてもよい。

電子取引システム１００は、インタフェース部１１０により承認画面を介して入力されたユーザＩＤおよび生体情報を受信すると、署名申請処理部１２０等により承認状況ＴＢ１２３と受信したユーザＩＤとに基づいて承認権者であることの確認を行うとともに、生体認証処理部１２１により、ユーザＴＢ１６１に含まれる生体認証情報と受信したユーザＩＤ及び生体情報とに基づいて、生体情報を照合する認証処理を行い、認証結果を承認状況ＴＢ１２３に記録する（Ｓ６３）。また、電子取引システム１００は、生体情報が合致する、すなわち認証結果が成功である場合は、署名申請処理部１２０により、承認画面を介して入力された承認結果を承認状況ＴＢ１２３に記録する（Ｓ６４）。なお、承認画面を介してさらにパスワードが入力される場合は、電子取引システム１００は、署名申請処理部１２０により、ユーザＴＢ１６１に含まれる認証情報と受信したユーザＩＤ及びパスワードとに基づいて、パスワードを照合する認証処理を行ってもよい。また、ＩＤレス生体認証の場合は、生体認証処理部１２１は、生体情報に基づいて認証処理を行えばよい。

全ての承認権者から受領した生体情報等の認証処理結果が成功であり、かつ、承認結果が承認を示している場合は、適切に承認がされたものとして、電子取引システム１００もしくは取引先システム４００による後続の電子署名の処理に移る。なお、例えば、所定の応答時間内に承認要求に対する承認を示す承認結果を電子取引システム１００が受領できなかった場合や、承認結果として不承認が含まれている場合や、第三者によるなりすまし等の理由により生体情報等の認証処理結果が失敗であった場合には、電子署名申請が拒絶されたものとして電子署名を行わないようにする。

このような処理により、承認権者に負担をかけずに所定の承認権者により（もしくは所定の承認権者の意思に基づいて）承認処理が行われることを保証し、担当者等の第三者が承認者の承認を得ずに独断で電子署名を行うことを防ぐことができる。

以上に説明したように、本発明の実施の形態１である電子取引システム１００によれば、非認定認証局２００に対する証明書登録業務を、サービス導入企業や取引先に代わって一括して行うことで、サービス導入企業のシステム運用の負荷を低減することが可能となる。また、全てのサービス導入企業が共通に利用可能なシステムとして構成することで、取引の相手方のサービス導入企業に関わらず、取引先が電子取引システムを使い分けることが不要となる。また、電子取引システム１００が保管する契約書等の文書に対してサービス導入企業や取引先が電子証明書を利用して電子署名を行う際に、承認権者の意思に基づいて承認が行われることを保証するような電子署名申請処理プロセスを有することで、取引先がサービス導入企業との間で安全に電子契約の締結等の電子取引を行うことが可能となる。

また、本発明の実施の形態１である電子取引システム１００によれば、案件や文書の承認画面を設けて、この画面のＵＲＬの情報を承認要求に埋め込み、承認権者のシステムへのログインＩＤ（ユーザＩＤ等）と生体情報を入力させるようにする。すなわち、生体情報の認証が成功しないと、承認が許可されず、承認処理を行うことができないようにする。これにより、例えば、パスワード等が漏洩した場合でも、第三者に承認処理が行われることを防止し、適切な承認権者が承認を行うことを保証して、電子取引における取引の安全性などを向上することができる。

＜実施の形態２＞
上述した実施の形態１の電子取引システム１００では、図７の例に示したように、複数の承認権者に一斉に承認要求のメッセージを送信し、各承認権者が個別に承認処理を行って、全員が承認した場合に承認されたものとする非同期的な手順をとっているが、実施の形態２においては、承認順序に従ったワークフローによる同期的な手順をとる。
なお、システム構成や処理内容については、基本的に上記の実施の形態１に示した内容と同様であるため、再度の記載は省略するが、電子署名申請処理の相違点については、以下に説明する。

図８は、本実施の形態における電子署名申請処理の流れの例について概要を示した図である。電子署名申請処理において、最初に、担当者が担当者端末３１１を利用して署名対象の文書を選択し、さらに１人以上の承認権者（承認順序も設定するものとする）を選択して、電子取引システム１００に対して署名申請要求を行うところ（Ｓ７５）までは、実施の形態１の図７の例に示した電子署名申請処理のステップＳ５１〜Ｓ５５と同様であるため、説明は省略する。

電子署名申請の要求を受けた電子取引システム１００は、メッセージ処理部１２２により、申請ＩＤと、対象の文書を特定するファイル名等の情報と、これまでの承認権者（存在する場合）と、インタフェース部１１０により提供される承認画面にアクセスするためのＵＲＬの情報とを含む承認要求のメッセージを作成し、これを承認順序における次の承認権者のアドレスに送信する（Ｓ７６）。

ステップＳ７７〜Ｓ８４の処理は、基本的に実施の形態１の図７の例に示した電子署名申請処理のステップＳ５７〜Ｓ６４と同様であるため、説明は省略する。ただし、ステップＳ７７〜Ｓ８４の処理は、承認順序における対象の順番の承認者に関して実行される。

案件が承認された場合は、電子取引システム１００は、次の承認権者の承認処理を行うため、ステップＳ７６と同様に新たに次の承認権者に対して承認要求のメッセージを送信する（Ｓ８５）。以降の処理（Ｓ８６〜）は、上述したステップＳ７７〜Ｓ８４と同様である。

このように、承認権者毎に順にステップＳ７６〜Ｓ８４の一連の処理を繰り返すことで、承認処理のワークフローを構成することができる。ワークフローにおける承認状況は、例えば、担当者が担当者端末３１１を利用して電子取引システム１００にアクセスすることで、承認状況ＴＢ１２３の内容に基づいて得られる承認状況を随時確認することができる。なお、ワークフローの最後の承認権者、すなわち電子取引システム１００から発行された電子証明書を所有する承認権者が承認処理を行う際は、例えば、承認画面に「電子署名を実行してもよろしいですか？」のような確認メッセージを表示するのが望ましい。

以上に説明したように、本発明の実施の形態２である電子取引システム１００によっても、上述した実施の形態１と同様の効果が得られる。

＜実施の形態３＞
上述した実施の形態１の電子取引システム１００では、図５の例に示したような処理により、サービス導入企業が新たな取引先と取引の基本契約を締結した場合に、サービス導入企業の担当者等が取引先の情報を電子取引システム１００に登録し、電子証明書を発行させる仕組みを有している。これにより、システムの利便性を向上させている。

しかしながら、サービス導入企業が自社の責任で自由に取引先を電子取引システム１００に登録し、電子証明書を発行させることができる仕組みでは、例えば、架空の取引先の登録や、社内の与信審査を通過していない企業の取引先としての登録が可能となり、電子取引システム１００の安全性が損なわれることになる。

そこで、本発明の実施の形態３である電子取引システム１００は、サービス導入企業が取引先を新たに登録する際に承認処理を介することで、取引先の無制限の登録を防止し、システムの安全性を確保するものである。なお、システム構成や処理内容については、基本的に上記の実施の形態１に示した内容と同様であるため、再度の記載は省略するが、サービス導入企業による取引先の登録に係る処理の相違点については、以下に説明する。

図９は、本実施の形態における、サービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。ここでは、対象の取引先が、既に他のサービス導入企業との間で基本契約を締結し、電子取引システム１００を介して電子証明書の発行を受けている場合の例を示している。

まず、実施の形態１の図５の例におけるステップＳ２１と同様に、サービス導入企業と取引先が取引の基本契約を締結する（Ｓ９１）。取引基本契約が締結されると、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、対象の取引先についての登録情報の確認要求を行う（Ｓ９２）。ここでは、例えば、対象の取引先が既に所有している電子証明書のＩＤや、所有者の電子メールアドレス等のアドレス情報などを入力することで、対象の取引先を特定する。要求を受けた電子取引システム１００は、取引先管理部１５０から対象の取引先の情報を取得して提示する（Ｓ９３）。サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、取引先の登録情報の内容を確認する（Ｓ９４）。

その後、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、取引先の登録についての１人以上の承認権者（承認順序も設定するものとする）を選択する（Ｓ９５）。なお、承認権者には電子取引システム１００から発行された電子証明書の所有者を含めるものとする。選択された各承認権者について、実施の形態２の図８に示した署名申請処理におけるステップＳ７５（本実施の形態では署名申請要求ではなく取引先の登録に係る承認要求となる）以降の一連の処理と同様の処理により、複数の承認権者によってワークフローにより順に取引先の登録について承認する承認処理を行う（Ｓ９６）。各承認権者が承認を行う際、例えば、承認画面に「社内で与信審査等の審査を通過した正当な取引先であることを確認していますか？」のような確認メッセージを表示するのが望ましい。

最終の承認権者（すなわち、電子証明書の所有者）により承認が行われると、電子取引システム１００は、取引先システム４００もしくは取引先の担当者の情報処理端末に対して、取引先として登録されることに対する承諾の要求を行う（Ｓ９７）。例えば、メッセージ処理部１２２によって電子メール等のメッセージを送信することにより要求を行うことができる。このとき、例えば、「（サービス導入企業）によって取引先として登録されてもよろしいですか？」などの確認メッセージを表示等するのが望ましい。

取引先では、取引先システム４００もしくは承認権者（すなわち電子証明書の所有者）の情報処理端末を介した指示に基づいて、取引先として登録されることに対する承諾／不承諾の入力を受け付けて電子取引システム１００に対して応答する（Ｓ９８）。電子取引システム１００は、承諾の応答を受けた場合は、取引先管理部１５０により、対象の取引先を新たに対象のサービス導入企業の取引先として関連付けて取引先ＴＢ１５１に登録する（Ｓ９９）。

図１０は、本実施の形態における、サービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの別の例について概要を示した図である。ここでは、対象の取引先が、未だいずれのサービス導入企業との間でも基本契約を締結しておらず、電子取引システム１００を介した電子証明書の発行を受けていない場合の例を示している。

まず、実施の形態１の図５の例におけるステップＳ２１と同様に、サービス導入企業と取引先が取引の基本契約を締結する（Ｓ１０１）。取引基本契約が締結されると、サービス導入企業では、図５の例におけるステップＳ２２と同様に、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、対象の取引先についての情報の登録依頼を行う（Ｓ１０２）。対象の取引先についての情報には、例えば、電子証明書の発行相手の電子メールアドレス等のアドレス情報や、企業情報などが含まれる。依頼を受けた電子取引システム１００は、取引先管理部１５０により対象の取引先の情報を対象のサービス導入企業と関連付けて取引先ＴＢ１５１に仮登録する（Ｓ１０３）。

その後、図９の例に示したステップＳ９５、９６の一連の処理と同様の処理により、サービス導入企業において選択された１人以上の承認権者によるワークフローにより、順に取引先の登録について承認する承認処理が行われる（Ｓ１０４、１０５）。

最終の承認権者（すなわち、電子証明書の所有者）により承認が行われると、電子取引システム１００は、取引先システム４００もしくは取引先の担当者の情報処理端末に対して、電子取引システム１００にアクセスするよう電子メール等のメッセージにより通知を行う（Ｓ１０６）。この通知には、例えば、ユーザ管理部１６０により発行された仮のログインＩＤ（ユーザＩＤ等）とパスワード、アクセス先のＵＲＬなどの情報が含まれる。

取引先では、担当者の情報処理端末等を介して電子取引システム１００にアクセスして初回のログイン処理を行う（Ｓ１０７）。電子取引システム１００は、正常にログインできた場合に、取引先システム４００もしくは取引先の担当者の情報処理端末に対して、取引先として登録されることに対する承諾の要求を行う（Ｓ１０８）。例えば、図９の例におけるステップＳ９７と同様に電子メール等のメッセージにより要求を行うことができる。また、ログイン後の画面に要求を表示するようにしてもよい。このとき、例えば、「（サービス導入企業）によって取引先として登録されてもよろしいですか？」などの確認メッセージを表示等するのが望ましい。

取引先では、取引先システム４００もしくは担当者等の情報処理端末を介した指示に基づいて、取引先として登録されることに対する承諾／不承諾の入力を受け付けて電子取引システム１００に対して応答する（Ｓ１０９）。電子取引システム１００は、承諾の応答を受けた場合は、取引先管理部１５０により、対象の取引先についてステップＳ１０３において取引先ＴＢ１５１に登録された仮登録を本登録に変更する（Ｓ１１０）。その後は、図５のステップＳ２４以降の処理と同様に、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子取引システム１００に対して、対象の取引先についての電子証明書の発行申請を行い（Ｓ１１１）、電子証明書の発行を受ける。

以上に説明したように、本発明の実施の形態３である電子取引システム１００によれば、サービス導入企業において取引先を新たに登録する際に、ワークフローによる承認処理を介するように制御し、また、取引先からも承認を得るようにすることで、取引先の無制限の登録を防止し、システムやサービスの安全性を確保することが可能となる。

なお、上記の本発明の各実施の形態では、電子取引として、主に電子契約について見積書や契約書等の文書を例示して説明した。しかし、電子取引は、契約に限られない。例えば、電子取引システム１００は、図４と同様の処理の流れで、一方の取引主体から請求書や連絡事項を記載した文書などの各種の一般的な書類の登録を受け付け、当該一方の取引主体による電子署名を行い、当該書類を他の取引主体に対して閲覧可能化することができる。また、例えば、電子取引システム１００は、図６と同様の処理の流れで、一方の取引主体から一般的な書類の登録を受け付け、当該一方の取引主体による電子署名を行い、当該書類を他の取引主体に対して閲覧可能化し、当該他の取引主体による電子署名を行い、保管することができる。

また、電子取引システム１００は、一般的な書類に限らず、いわゆる信書として扱われている文書を、電子的な信書として扱うようにしてもよい。電子的な信書についても、図４や図６と同様の処理の流れで実現することができる。

また、上記の本発明の各実施の形態では、主に企業と企業（ＢｔｏＢ）の間の取引を例に説明しているが、これに限定されるものではない。すなわち、電子取引システム１００は、企業と企業（ＢｔｏＢ）、企業と個人（ＢｔｏＣ）、個人と個人（ＣｔｏＣ）等の様々な取引主体の間の電子取引サービスを提供することができる。個人として電子取引サービスを使用する場合には、例えば国民一人一人を識別する識別番号をユーザＩＤとして使用すれば、より電子取引サービスの利便性や汎用性が高まる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１００…電子取引システム、１００ａ、ｂ…電子契約システム、１０１…電子契約システム、１０１’…システムベンダ、１１０…インタフェース部、１２０…署名申請処理部、１２１…生体認証処理部、１２２…メッセージ処理部、１２３…承認状況テーブル（ＴＢ）、１３０…電子署名部、１３０ａ〜ｃ…Ａ社〜Ｃ社電子署名部、１４０…証明書登録処理部、１４１…帳票作成部、１５０…取引先管理部、１５１、１５１ａ、ｂ…取引先テーブル（ＴＢ）、１６０…ユーザ管理部、１６１…ユーザテーブル（ＴＢ）、１７０…文書管理部、１７１…文書テーブル（ＴＢ）、
２００…非認定認証局、２０１…認定認証局、
３００…サービス導入企業個別システム、３００ａ〜ｃ…Ａ社〜Ｃ社個別システム、３００ａ’、ｂ’…Ａ社、Ｂ社、
４００…取引先システム、４０１〜４０５…取引先１〜５システム、４０１’〜４０３’…取引先１〜３

Claims (9)

1. 第１の取引主体と第２の取引主体との間の電子取引を支援する電子取引システムであって、
   １つ以上の前記第１の取引主体毎の、前記第１の取引主体についての電子取引に係る文書に対して電子署名を行う電子署名部と、
   前記第１の取引主体についての前記文書に対して電子署名を行う際の承認処理を行う署名申請処理部と、
   前記各第１の取引主体についての前記文書を保持する文書記録部と、
   を有し、
   前記署名申請処理部は、
   前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に、第１の承認画面のアドレス情報を含む第１の電子メッセージを作成して前記第１の承認権者に送付し、前記第１の承認画面を介して前記第１の承認権者から入力された承認結果を取得し、全ての前記第１の承認権者から承認する旨の結果を取得した場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行い、
   前記第１の承認権者からの承認結果を受け付ける際に、前記第１の承認画面を介して、前記第１の承認権者が承認を行うために必要な前記第１の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第１の承認権者による承認を許可し、
   前記第１の取引主体についての前記文書について、対応する電子取引の相手方である前記第２の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第２の取引主体における１人以上の第２の承認権者毎に、第２の承認画面のアドレス情報を含む第２の電子メッセージを作成して前記第２の承認権者に送付し、前記第２の承認画面を介して前記第２の承認権者から入力された承認結果を取得し、全ての前記第２の承認権者から承認する旨の結果を取得した場合に、前記第２の取引主体において前記文書に対する電子署名を実施させ、
   前記第２の承認権者からの承認結果を受け付ける際に、前記第２の承認画面を介して、前記第２の承認権者が承認を行うために必要な前記第２の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第２の承認権者による承認を許可する、
   ことを特徴とする電子取引システム。
2. 請求項１に記載の電子取引システムにおいて、
   前記署名申請処理部は、
   前記第１の承認権者毎に、前記申請に含まれる承認順序に基づいて順に、前記第１の電子メッセージを作成して前記第１の承認権者に送付し、最終順序の前記第１の承認権者により承認する旨の結果を取得した場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行う、
   ことを特徴とする電子取引システム。
3. 請求項１又は２に記載の電子取引システムにおいて、
   前記署名申請処理部は、
   前記第２の承認権者毎に、前記申請に含まれる承認順序に基づいて順に、前記第２の電子メッセージを作成して前記第２の承認権者に送付し、最終順序の前記第２の承認権者により承認する旨の結果を取得した場合に、前記第２の取引主体において前記文書に対する電子署名を実施させる、
   ことを特徴とする電子取引システム。
4. 請求項１〜３のいずれか１項に記載の電子取引システムにおいて、
   さらに、前記各第１の取引主体が当該電子取引システムを介して電子取引を行うことが可能な前記第２の取引主体についての情報を保持する取引先記録部を有し、
   前記第１の取引主体についての前記文書について、対応する電子取引の相手方である前記第２の取引主体の情報が前記取引先記録部に登録されている場合にのみ、前記文書に対する電子署名および前記文書記録部への保持を許可する、
   ことを特徴とする電子取引システム。
5. 請求項４に記載の電子取引システムにおいて、
   前記第１の取引主体が当該電子取引システムを介して電子取引を行うことが可能な前記第２の取引主体についての情報を前記取引先記録部に記録する際に、前記第１の取引主体における第３の承認権者、および前記第２の取引主体における第４の承認権者による承認の入力を受け付けた場合にのみ記録を許可する、
   ことを特徴とする電子取引システム。
6. 請求項１〜５のいずれか１項に記載の電子取引システムにおいて、
   さらに、前記第１の取引主体もしくは前記第１の取引主体が当該電子取引システムを介して電子取引を行うことが可能な前記第２の取引主体に対する電子証明書の発行の要求を前記第１の取引主体から受け付けて、認証局に対して前記電子証明書の発行を依頼し、発行された前記電子証明書を、前記第１の取引主体もしくは前記第２の取引主体に対して配布する証明書登録処理部を有する、
   ことを特徴とする電子取引システム。
7. 請求項６に記載の電子取引システムにおいて、
   前記認証局は非認定認証局である、
   ことを特徴とする電子取引システム。
8. 第１の取引主体と第２の取引主体との間の電子取引を支援する電子取引システムにおける電子取引方法であって、
   前記第１の取引主体についての電子取引に係る文書に対して電子署名を行う際の承認処理を行う署名申請処理ステップと、
   １つ以上の前記第１の取引主体毎の、前記第１の取引主体についての前記文書に対して電子署名を行う電子署名ステップと、
   前記各第１の取引主体についての前記文書を保持する文書記録ステップと、
   を含み、
   前記署名申請処理ステップは、
   前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に、第１の承認画面のアドレス情報を含む第１の電子メッセージを作成して前記第１の承認権者に送付し、前記第１の承認画面を介して前記第１の承認権者から入力された承認結果を取得し、全ての前記第１の承認権者から承認する旨の結果を取得した場合に、前記第１の取引主体からの前記文書に対して前記第１の取引主体に対応する前記電子署名ステップを実行させ、
   前記第１の承認権者からの承認結果を受け付ける際に、前記第１の承認画面を介して、前記第１の承認権者が承認を行うために必要な前記第１の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第１の承認権者による承認を許可し、
   前記第１の取引主体についての前記文書について、対応する電子取引の相手方である前記第２の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第２の取引主体における１人以上の第２の承認権者毎に、第２の承認画面のアドレス情報を含む第２の電子メッセージを作成して前記第２の承認権者に送付し、前記第２の承認画面を介して前記第２の承認権者から入力された承認結果を取得し、全ての前記第２の承認権者から承認する旨の結果を取得した場合に、前記第２の取引主体において前記文書に対する電子署名を実施させ、
   前記第２の承認権者からの承認結果を受け付ける際に、前記第２の承認画面を介して、前記第２の承認権者が承認を行うために必要な前記第２の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第２の承認権者による承認を許可する、
   ことを特徴とする電子取引方法。
9. 第１の取引主体と第２の取引主体との間の電子取引を支援する電子取引システムのプログラムであって、
   １つ以上の前記第１の取引主体毎の、前記第１の取引主体についての電子取引に係る文書に対して電子署名を行う電子署名部と、
   前記第１の取引主体についての前記文書に対して電子署名を行う際の承認処理を行う署名申請処理部と、
   前記各第１の取引主体についての前記文書を保持する文書記録部として
   前記電子取引システムを機能させ、
   前記署名申請処理部は、
   前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に、第１の承認画面のアドレス情報を含む第１の電子メッセージを作成して前記第１の承認権者に送付し、前記第１の承認画面を介して前記第１の承認権者から入力された承認結果を取得し、全ての前記第１の承認権者から承認する旨の結果を取得した場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行い、
   前記第１の承認権者からの承認結果を受け付ける際に、前記第１の承認画面を介して、前記第１の承認権者が承認を行うために必要な前記第１の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第１の承認権者による承認を許可し、
   前記第１の取引主体についての前記文書について、対応する電子取引の相手方である前記第２の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第２の取引主体における１人以上の第２の承認権者毎に、第２の承認画面のアドレス情報を含む第２の電子メッセージを作成して前記第２の承認権者に送付し、前記第２の承認画面を介して前記第２の承認権者から入力された承認結果を取得し、全ての前記第２の承認権者から承認する旨の結果を取得した場合に、前記第２の取引主体において前記文書に対する電子署名を実施させ、
   前記第２の承認権者からの承認結果を受け付ける際に、前記第２の承認画面を介して、前記第２の承認権者が承認を行うために必要な前記第２の承認権者の生体情報を含む認証情報の入力を受け付け、前記認証情報に基づく認証処理が成功した場合に前記第２の承認権者による承認を許可する、
   ことを特徴とするプログラム。

Images