"電子文書を流通するシステムにおいて、電子アドレスを基盤にメッセージを送受信し、メッセージ送受信に対する流通証明書を発給および管理する流通メッセージングサーバを介して電子文書を流通する送受信個体と;前記送受信個体の電子アドレスを登録/管理し、前記送受信個体間の電子文書の流通経路を設定し、前記送受信個体に電子文書の標準書式を提供し、送受信個体間の電子文書の流通過程でエラーが発生した時に、メッセージ転送を代行し、流通証明書を発給する流通ハブ;および流通証明書の伝達を受けて保管し、信頼できる第3者保管機関;を含むことを特徴とする電子文書流通システム。前記送受信個体の流通メッセージングサーバは、送受信したメッセージは、ユーザ別に状態情報を含んでメッセージ箱に保管し、メッセージ送受信履歴を編集および削除が不可能な媒体に所定期間保管し、メッセージ送受信に対する流通証明書を発給して前記第3者保管機関に保管を依頼し、前記流通ハブのアドレスディレクトリサーバとの連係を通じて前記送受信個体に電子アドレスの登録および検索、修正、削除を含む機能を使えるようにし、所定期間以上保管されたメッセージを外部格納装置に移管して保管することを特徴とする、請求項1に記載の電子文書流通システム。前記電子アドレスは、前記送受信個体が前記流通ハブのアドレスディレクトリサーバを介して発給を受けたユーザ識別記号と;前記送受信個体が必要な場合に自体的に付与する固有な値であり、該当送受信個体内で固有な値である追加識別記号;および前記ユーザ識別記号と追加識別記号との間に位置する区分記号;を含むことを特徴とする、請求項1に記載の電子文書流通システム。電子文書流通に対する主体は、固有登録アドレスの発給を受けたユーザであることを特徴とする、請求項3に記載の電子文書流通システム。前記区分記号はであることを特徴とする、請求項3に記載の電子文書流通システム。前記流通ハブは電子文書の書式登録機を備え、前記電子文書の書式登録機は、電子文書の標準書式の登録、削除、および情報修正を含む管理を遂行し、電子文書の標準書式を文脈contextに応じてさらに分類し、電子文書の標準書式が使用され得る文脈contextに対する登録、修正を含む管理を遂行することを特徴とする、請求項1に記載の電子文書流通システム。前記電子文書の書式登録機は、文書様式を管理するサーバエンジン;および送受信個体を使用するユーザが文書様式を検索しダウンロードして使用できるようにする標準インターフェース;を含み、前記送受信個体は、送受信個体を使用するユーザが流通メッセージングサーバを介してメッセージを送受信できるようにするユーザインターフェースである流通クライアントアプリケーションをさらに備え、前記流通クライアントアプリケーションを使用するユーザは、前記電子文書の書式登録機の標準インターフェースを介して文書書式を検索しダウンロードした後に、該当文書書式を利用して電子文書を生成することを特徴とする、請求項6に記載の電子文書流通システム。前記流通ハブは、送受信個体間の電子文書の流通過程でエラーが発生した時に、メッセージ転送を代行し、流通証明書を発給する流通中継サーバを備え、前記流通中継サーバは、送受信個体からメッセージ転送の依頼を受ければ、メッセージ転送を代行した後に、メッセージ転送を依頼した送受信個体に送信証明書を発給し、依頼を受けたメッセージ転送を失敗した時には、メッセージ転送を依頼した送受信個体にエラーメッセージを転送することを特徴とする、請求項1に記載の電子文書流通システム。前記流通ハブは、外部システムとの連係のための外部連係ゲートウェイサーバを備え、前記外部連係ゲートウェイサーバは、電子アドレスを基盤にメッセージを送受信する流通メッセージングサーバを備え、連係した外部システムと電子文書流通システム間の送受信電子アドレスの検証/変換機能と、連係した外部システムと電子文書流通システム間のメッセージの検証/変換機能、連係した外部システムと電子文書流通システム間の電子文書に適用された保安の検証/変換機能、連係した外部システムと電子文書流通システム間の電子文書の適合性を検証し相互間に変換する機能を提供することを特徴とする、請求項1に記載の電子文書流通システム。電子アドレス登録代行機関がアドレスディレクトリサーバに電子アドレスを登録要請して応答を受けるのに用いられる第1インターフェースと;電子アドレス登録代行機関がアドレスディレクトリサーバに登録された電子アドレス情報に対する変更を要請して応答を受けるのに用いられる第2インターフェース;および電子アドレス登録代行機関がアドレスディレクトリサーバに登録された電子アドレス情報の削除を要請して応答を受ける第3インターフェース;が備えられ、前記電子アドレス登録代行機関は、第1インターフェースを介して電子アドレスの申請者情報および電子アドレス情報を要請メッセージに含ませて転送した後に、アドレスディレクトリサーバの登録処理結果を応答メッセージとして受信し、前記電子アドレス登録代行機関は、第2インターフェースを介して変更しようとするユーザ情報および電子アドレス情報を要請メッセージに含ませて転送した後に、アドレスディレクトリサーバの変更処理結果を応答メッセージとして受信し、前記電子アドレス登録代行機関は、第3インターフェースを介して削除しようとするユーザ情報および電子アドレス情報を要請メッセージに含ませて転送した後に、アドレスディレクトリサーバの削除処理結果を応答メッセージとして受信することを特徴とする、請求項1に記載の電子文書流通システム。前記電子アドレス登録代行機関または送受信個体がアドレスディレクトリサーバに電子文書受信者の電子アドレスに該当する物理アドレス情報とメッセージ保安処理のための公認認証書情報を要請して応答を受けるのに用いられる第4インターフェースが備えられ、電子アドレス登録代行機関または送受信個体の流通メッセージングサーバは、電子文書受信者の電子アドレスおよび公認認証書の要請有無を要請メッセージに含ませて転送した後に、アドレスディレクトリサーバから電子文書受信者の物理アドレス情報および公認認証書情報を応答メッセージとして受信することを特徴とする、請求項10に記載の電子文書流通システム。送受信個体の流通メッセージングサーバまたは電子アドレス登録代行機関の流通メッセージングサーバは、メッセージ転送、流通証明書の伝達、流通証明書の保管要請、および第3者保管機関の保管結果伝達に用いる第5インターフェースを備えることを特徴とする、請求項1に記載の電子文書流通システム。送受信個体内のユーザは、ユーザインターフェースである流通クライアントアプリケーションを備え、送受信個体の流通メッセージングサーバは、電子文書流通を要請するユーザのための流通クライアントアプリケーションと連係して、ユーザに文書送受信機能を提供する第6インターフェースを備え、前記第6インターフェースは、メッセージ転送の要請、メッセージ目録の要請、メッセージ詳細情報の要請、スパムメッセージ申告、および物理アドレス情報の検索機能を流通クライアントユーザに提供することを特徴とする、請求項1に記載の電子文書流通システム。送受信個体と流通ハブを含む電子文書流通システムで電子文書を流通する方法において、a送信個体は、受信個体のアドレス情報に対応する物理アドレス情報を流通ハブを介して獲得した後に、電子文書を添付したメッセージを前記物理アドレスに転送するステップと;bメッセージを受信した受信個体は、受信メッセージおよび送信個体に対する適合性の検証結果に応じて受信証明書またはエラー証明書を発給して送信個体に伝達するステップ;およびc受信個体にメッセージを転送したものの失敗した送信個体は、流通ハブにメッセージ転送の代行を依頼し、メッセージ転送の代行依頼を受けた流通ハブは、送信証明書を発給して送信個体に伝達し、受信個体にメッセージを転送した後に前記bステップを遂行するステップ;を含む電子文書流通方法。前記aステップは、a1送信個体は、受信個体の電子アドレス情報を基準に受信個体に対する物理アドレス情報および保安情報を流通ハブのアドレスディレクトリサーバに問い合わせるステップと;a2前記アドレスディレクトリサーバは、送信個体の問い合わせを受信して検証した後に、電子アドレスがホワイトリストにある場合、電子アドレスに対応する物理アドレス情報を送信個体に提供するステップ;およびa3前記送信個体は、電子文書を添付したメッセージを前記アドレスディレクトリサーバから提供された物理アドレス情報を基準に経路設定をして受信個体に転送するステップ;を含むことを特徴とする、請求項14に記載の電子文書流通方法。前記bステップ後に、受信証明書を受信した送信個体は、受信証明書の適合性を検証し、検証した情報を受信証明書に添付した後、受信証明書を自体保管すると同時に、第3者保管機関に保管依頼することを特徴とする、請求項14に記載の電子文書流通方法。前記cステップは、c1受信個体にメッセージを転送したものの失敗した送信個体は、流通ハブにメッセージ転送の代行を依頼するステップと;c2流通ハブはメッセージ転送を始めるが、転送失敗時には、所定の時間間隔で再試し、メッセージ転送に最終的に失敗した場合には、送信個体に転送失敗メッセージを伝達するステップと;c3メッセージを正常に受信した受信個体は、受信証明書を発給して流通ハブに転送するステップ;およびc4電子文書の受信者が電子文書を閲覧した場合、受信個体は、閲覧証明書を発給して、流通ハブを経ることなく送信個体に直接転送するステップ;を含むことを特徴とする、請求項14に記載の電子文書流通方法。送信者または受信者の役割をする送受信個体と電子文書流通ハブを含む電子文書流通システムで電子文書を流通する方法において、a送信者は、受信者の電子アドレス情報を獲得するステップと;b送信者は、送信する文書を予め定められたメッセージ構造体にパッケージングしたメッセージを生成した後に受信者の電子アドレスに転送するステップと;c前記bステップで転送失敗した場合に、送信者は、電子文書流通ハブにメッセージ転送を依頼し、メッセージ転送の依頼を受けた電子文書流通ハブは、送信証明書を発給して送信者に伝達した後にメッセージ転送を代行するステップと;d受信者は、送信者または電子文書流通ハブから受信したメッセージを検証し、検証が通過すれば、受信したメッセージから文書を抽出し、受信証明書を発給して送信者に伝達するステップと;e送信者は、伝達を受けた受信証明書を信頼できる第3者保管機関を活用して保管するステップ;およびf受信者は、抽出した文書を文書担当者に伝達するステップ;を含む電子文書流通方法。前記aステップ前には、g送信者および受信者は、文書流通のための流通メッセージングサーバを構築するか、3者流通が可能な流通メッセージングサーバを保有した送受信個体を利用するかについて決定するステップと;h前記gステップで文書流通のための流通メッセージングサーバを構築すると決めた場合には、送信者および受信者は、文書流通のための流通メッセージングサーバを構築した後に、認証機関を介して流通メッセージングサーバの認証テストを遂行し、電子文書流通ハブのアドレスディレクトリサーバに接続した後、送受信個体としての電子アドレスの発給を受けた後に、内部の実ユーザのために自体的に内部区分子を登録し管理するステップと;i前記gステップで3者流通が可能な流通メッセージングサーバを保有した送受信個体を利用すると決めた場合には、送信者および受信者は、3者流通が可能な流通メッセージングサーバを介して電子アドレスの開設を要請した後に、電子アドレス情報を電子文書流通ハブのアドレスディレクトリサーバに登録するステップ;およびj前記hステップまたはiステップ後に、前記送信者は、電子文書流通ハブの電子文書の書式登録機から文書書式を検索しダウンロードして登録するステップ;を含み、前記bステップ前には、送信する文書を選択するか、または前記jステップで登録した文書書式を利用して送信する文書を作成するkステップがさらに遂行されることを特徴とする、請求項18に記載の電子文書流通方法。コンピュータで読み取り可能な記録媒体において、請求項14~19のいずれか1項による方法を実現するプログラムが格納される記録媒体。本発明は、前記のような従来の問題点を解決するためのものであり、本発明の目的は、一定規模の電子文書流通システムを保有できる企業/機関などと共に一般個人、小企業にも信頼性が確保できる電子文書流通システムおよび電子文書流通方法を提供することにある。前記のような目的を有する本発明の好ましい実施形態による電子文書流通システムは、電子文書を流通するシステムにおいて、電子アドレスを基盤にメッセージを送受信し、メッセージ送受信に対する流通証明書を発給および管理する流通メッセージングサーバを介して電子文書を流通する送受信個体と;前記送受信個体の電子アドレスを登録/管理し、前記送受信個体間の電子文書の流通経路を設定し、前記送受信個体に電子文書の標準書式を提供し、送受信個体間の電子文書の流通過程でエラーが発生した時に、メッセージ転送を代行し、流通証明書を発給する流通ハブ;および流通証明書の伝達を受けて保管し、信頼できる第3者保管機関;を含む。前記のような目的を有する本発明の好ましい実施形態による電子文書流通システムは、送受信個体と流通ハブを含む電子文書流通システムで電子文書を流通する方法において、a送信個体は、受信個体のアドレス情報に対応する物理アドレス情報を流通ハブを介して獲得した後に、電子文書を添付したメッセージを前記物理アドレスに転送するステップと;bメッセージを受信した受信個体は、受信メッセージおよび送信個体に対する適合性の検証結果に応じて受信証明書またはエラー証明書を発給して、送信個体に伝達するステップ;およびc受信個体にメッセージを転送したものの失敗した送信個体は、流通ハブにメッセージ転送の代行を依頼し、メッセージ転送の代行依頼を受けた流通ハブは、送信証明書を発給して送信個体に伝達し、受信個体にメッセージを転送した後に、前記bステップを遂行するステップ;を含む。前記のような構成および方法を有する本発明は、企業/機関などと共に個人、小企業にも信頼性が確保できる電子文書流通体系を構築することが可能な効果がある。以下、添付した図面および表を参照し、本発明の好ましい実施形態による電子文書流通システムおよび電子文書流通方法について説明すれば、次の通りである。図1は本発明の好ましい実施形態による電子文書流通システムの構成例を示す。図1を参照すれば、本発明の好ましい実施形態による電子文書流通システムは、電子アドレスを基盤にメッセージを送受信し、メッセージ送受信に対する流通証明書を発給および管理する流通メッセージングサーバを介して電子文書を流通する送受信個体101と;前記送受信個体101の電子アドレスを登録/管理し、前記送受信個体101間の電子文書の流通経路を設定し、前記送受信個体101に電子文書の標準書式を提供し、送受信個体101間の電子文書の流通過程でエラーが発生した時に、メッセージ転送を代行し、流通証明書を発給する電子文書流通ハブ102;および流通証明書の伝達を受けて保管し、信頼できる第3者保管機関公電所公認電子文書保管所103;を含んで構成される。前記送受信個体101の流通メッセージングサーバは、送受信したメッセージはユーザ別に状態情報を含ませてメッセージ箱に保管し、メッセージ送受信履歴を編集および削除が不可能な媒体に所定期間保管し、メッセージ送受信に対する流通証明書を発給して前記第3者保管機関に保管を依頼し、前記電子文書流通ハブ102のアドレスディレクトリサーバとの連係を通じて前記送受信個体101に電子アドレスの登録および検索、修正、削除を含む機能を使えるようにし、所定期間以上保管されたメッセージを外部格納装置に移管して保管する。前記電子アドレスは、前記送受信個体101が前記電子文書流通ハブ102のアドレスディレクトリサーバを介して発給を受けたユーザ識別記号と;前記送受信個体101が必要な場合に自体的に付与する固有な値であり、該当送受信個体101内において固有な値である追加識別記号;および前記ユーザ識別記号と追加識別記号との間に位置する区分記号;を含む。前記電子文書流通ハブ102は、電子文書の書式登録機を備え、前記電子文書の書式登録機は、電子文書の標準書式の登録、削除、および情報修正を含む管理を遂行し、電子文書の標準書式を文脈contextに応じてさらに分類し、電子文書の標準書式が使用され得る文脈contextに対する登録、修正を含む管理を遂行する。前記電子文書流通ハブ102は、送受信個体101間の電子文書の流通過程でエラーが発生した時に、メッセージ転送を代行し、流通証明書を発給する流通中継サーバを備え、前記流通中継サーバは、送受信個体101からメッセージ転送の依頼を受ければ、メッセージ転送を代行した後に、メッセージ転送を依頼した送受信個体101に送信証明書を発給し、依頼を受けたメッセージ転送を失敗した時には、メッセージ転送を依頼した送受信個体101にエラーメッセージを転送する。前記電子文書流通ハブ102は、外部システムとの連係のための外部連係ゲートウェイサーバを備え、前記外部連係ゲートウェイサーバは、電子アドレスを基盤にメッセージを送受信する流通メッセージングサーバを備え、連係した外部システムと電子文書流通システム間の送受信電子アドレスの検証/変換機能と、連係した外部システムと電子文書流通システム間のメッセージの検証/変換機能、連係した外部システムと電子文書流通システム間の電子文書に適用された保安の検証/変換機能、連係した外部システムと電子文書流通システム間の電子文書の適合性を検証し相互間に変換する機能を提供する。上述したような構成を有する本発明の好ましい実施形態による電子文書流通システムおよびこれを利用した電子文書流通方法について図1~図118を参照して詳細に説明すれば、次の通りである。以下、本発明について詳細に説明する際に図1の図面符号は省略する。[電子文書流通システムの構造]電子文書流通の信頼性および安全性を保障するために、本発明による電子文書流通システムの流通体系が備えなければならない要件は次の1~7の通りである。1流通体系に参加する送受信個体および送受信者は事前に定義された方式で電子文書を送受信するべきであり、管理機関または電子文書中継者のサービスレベル協約SLAに同意するべきである。2流通体系内に参加する送受信個体および公認送受信者は身元確認が可能であるべきであり、電子文書の流通行為はその事実に対する否認防止が可能であるべきである。3流通体系において送受信個体および公認送受信者を識別するための情報である公認電子アドレスは法人または個人単位で付与され、登録機関によって登録および管理されるべきである。4流通体系内での電子文書の流通時、流通証明書は必ず生成されるべきであり、流通行為に参加した送信個体および第3者保管機関に転送および保管されるべきである。5全ての電子文書の流通行為はP2PPeertoPeer通信を基本とするが、様々な環境的な要因のために通信に失敗した場合、これを支援するための体系があるべきである。6流通体系内において当事者間の電子文書の交換だけでなく、電子文書閲覧サービスなどの様々な付加サービスも支援されるべきである。7流通体系以外の外部システムとの連係を支援するゲートウェイが提供されるべきである。本発明による電子文書流通システムは公認電子アドレスを基盤にし、流通メッセージングサーバを所有している送受信個体間に電子文書をやり取りするP2P通信を基本とする。このような本発明による電子文書流通システムの構造は図1の通りであり、システム内の構成要素に対する説明は下記表1および表2の通りであり、主要プロセスは下記表3の通りである。[電子文書流通システムの構成要素]1流通メッセージングサーバ流通メッセージングサーバは、送受信個体内にあるメッセージングシステムであって、電子文書流通の核心的な役割を担当する。流通メッセージングサーバは物理的に1つの電子アドレスIPAddressを有するが、下位のユーザのために複数のユーザアカウントを発給し管理できなければならない。各ユーザアカウントを管理するために、流通メッセージングサーバはユーザアカウント別にメッセージ箱を管理するべきであり、流通メッセージングサーバはユーザのアカウントとメッセージ箱を安全で信頼性のあるように管理する責任がある。流通メッセージングサーバの機能概念図は図2の通りであり、機能に対する説明は下記表4の通りである。上記表4に開示された機能の以外に、流通メッセージングサーバの信頼性を向上させるためには、サーバシステム管理において、次の1~4のような原則を遵守するべきである。1システム管理者は、個人のメッセージ箱を見たり任意に削除したりすることはできない。2サーバシステム管理と関連した履歴情報は任意に削除することができず、不変更媒体などに10年以上保管するべきである。3システム管理者は、認証された流通メッセージングサーバソルーションの基本機能などを任意に変更することができない。4システム管理と関連した業務指針を作成し、それに応じて管理がなされるべきである。2流通クライアント流通クライアントは、流通体系内に参加する送受信者のために、メッセージの送信および受信、受信された電子文書の閲覧および管理などのUIUserInterfaceを提供するアプリケーションである。流通クライアントは、独自に文書を送受信することができず、必ず流通メッセージングサーバと連係しなければならない。流通クライアントは、流通メッセージングサーバを介してメッセージ転送を要請するか、流通メッセージングサーバを介して受信されたメッセージを照会する。流通メッセージングサーバは、ユーザアカウント別にメッセージ箱を管理し、流通クライアントは、受信文書中のユーザアカウント情報の確認を通じて本人のアカウントに保管されているメッセージにのみアクセスが可能であるべきである。流通クライアントは、送受信個体の要求に応じて、C/S形態のアプリケーションまたはウェブ形態の画面に実現することができる。流通クライアントの機能概念図は図3の通りであり、機能に対する説明は下記表5の通りである。3アドレスディレクトリサーバアドレスディレクトリサーバは、送受信個体と公認送受信者に対するアドレス情報を管理し、物理アドレスを提供するためのシステムである。アドレスディレクトリサーバは、次の1および2のような基本機能を提供する。1受信個体の流通メッセージングサーバの物理アドレスIPアドレスの管理および提供2公認電子アドレスの情報を登録、修正するなどの管理機能さらに、アドレスディレクトリサーバは、ホワイトリスト情報を管理する機能を基本的に有し、ユーザからスパムメッセージに対する申告を受け付け、これを基準にブラックリスト情報を管理する。アドレスディレクトリサーバは、ウェブポータル画面を介して公認電子アドレスと関連した情報を送受信個体または公認送受信者に提供し、連係インターフェースを介して流通メッセージングサーバおよび関連アプリケーションがアドレスディレクトリサーバから提供するサービスを利用することができる。アドレスディレクトリサーバの機能概念図は図4の通りであり、機能に対する説明は下記表6の通りである。4電子文書の書式登録機電子文書の書式登録機は、送受信個体間に事前に約束された標準電子文書を利用して自動で処理するか、e-Form形態の電子文書などを活用できるように、電子文書流通ハブから提供するシステムである。電子文書の書式登録機は、電子文書の書式を管理するサーバエンジンと流通クライアントがこれを検索およびダウンロードできるように機能を提供するインターフェースとウェブポータルインターフェースなどを提供する。電子文書の書式登録機の機能概念図は図5の通りであり、機能に対する説明は下記表7の通りである。5流通中継サーバ流通中継サーバは、電子文書流通ハブ内にあるシステムであり、流通体系において送受信個体間の電子文書の流通過程でエラーが発生した時、送信個体の代わりにメッセージ転送を代行するシステムである。流通中継サーバは内部的に流通メッセージングサーバの機能を内蔵しているので、これによって基本的な電子文書の送受信サービスを提供するだけでなく、流通中継サーバのみが有する中継依頼の受付および最終失敗時のエラーメッセージの転送などのサービスを連係インターフェースを介して流通メッセージングサーバに提供する。流通中継サーバの機能概念図は図6の通りであり、機能に対する説明は下記表8の通りである。6外部連係ゲートウェイサーバ外部連係ゲートウェイサーバは、既存に運用されているか、流通体系内に含まれ難い外部システムと流通体系が連係するための信頼性のある通路役割をするシステムである。公共部門の場合、行政情報共同利用センターまたは電子文書流通支援センターなどを通じて苦情や民生に係る書類などを電子的に流通しているが、このようなシステムと連係するためのチャネルとして外部連係ゲートウェイサーバを活用することができる。公共部門だけでなく、その他の外部システムとも連係するためのチャネル役割を遂行することができる。外部連係ゲートウェイサーバの機能概念図は図7の通りであり、機能に対する説明は下記表9の通りである。7公認電子アドレス流通体系に参加する送受信個体と公認送受信者は固有の公認電子アドレスの発給を受けるべきである。公認電子アドレスは、sharp[]、数字[0-9]、ハイフン[-]、ピリオド[。]の組み合わせで構成する。公認電子アドレスの構成体系は下記表10の通りである。公認電子アドレスの構成体系と関連した原則は次の1~3の通りである。1の前部分はユーザの便宜のために、文字[A-Z][a-z]、ハングル[完成されたハングル文字2,350字]、数字[0-9]、ハイフン[-]、ピリオド[。]の組み合わせで構成されたユーザ追加識別記号を選択的に使うことができる。この場合、ユーザ追加識別記号は、電子文書流通メッセージングサーバにおいて自体管理する。2公認電子アドレスのユーザ追加識別記号は、ハイフンまたはピリオドで始まったり終わったりしてはいけず、長さは30バイト以下にする。3公認電子アドレスのユーザ追加識別記号としては、社会的慣習、美風良俗を害する文字および数字の組み合わせ、その他の管理機関長が定める制限記号は使えない。公認電子アドレスと実の物理アドレス流通メッセージングサーバの実の物理アドレスであるIPAddressとは、連関関係に対してはアドレスディレクトリサーバを通してのみ管理される。公認電子アドレスと流通メッセージングサーバの実の物理アドレスは1:1またはN:1の関係を有し、これにより、1つの公認電子アドレスがいくつかの物理アドレスを有する場合は存在しない。公認電子アドレスに対する情報文書の法的な受信責任はの後に存在する企業/機関/個人が持つべきであり、ユーザ追加識別記号による配付は企業/機関/個人が便宜のために区分したものであるため、送受信個体はユーザ追加識別記号による配布に対して自体的に責任を負わなければならない。この場合、送受信個体は、ユーザ追加識別記号に該当するユーザ認証に対する政策および管理要領を準備するべきであり、要領に応じて徹底的に管理するべきである。さらに、送受信個体は、流通体系に参加するに先立ち、管理機関とサービスレベル協約SLAを締結し、内部区分子を含む公認電子アドレス内容を含ませて締結しなければならない。流通体系内で公認電子アドレスが有する効力範囲は図8のように表現することができる。ユーザ追加識別記号は、送受信個体内で固有な値でなければならない。ユーザ追加識別記号に対する付与方式は個別の送受信個体が責任を負うことを基本とし、ユーザ追加識別記号による電子文書の配付も送受信個体が責任を負うべきであり、問題発生時には送受信個体が解決しなければならない。このようなユーザ追加識別記号は流通体系の効力範囲には含まれないが、管理機関とのサービスレベル協約SLAなどによって規定を受けられる。ユーザ追加識別記号は、企業の業務便宜のために電子文書を分配するための用途として使われ、アドレスディレクトリサーバに登録せずに企業内部の情報としてのみ使用する。上述したような公認電子アドレスの他例として、次のような構造が可能である。公認電子アドレス=ID区分記号登録者ここで、前記IDは英文またはハングル、数字、ハイフン[-]、およびピリオド[。]などが組み合わせられて構成され、前記区分記号はであり、前記登録者は英文またはハングル、数字とピリオド[。]が組み合わせられて構成される。このような公認電子アドレスの一例としてswconvergencemke.go.krがあり、このような例を構成するにおいて、swconvergenceは政府機関の部署名、mkeは政府機関、goは特性、krは国家を示すようにした。公認電子アドレスの申請/発給と運営体系は図9の通りであり、これと関連した構成要素に対する説明は下記表11の通りである。8電子文書情報パッケージ電子文書情報パッケージは、メッセージ内部に含まれている電子文書に対するメタデータを明示することにより、グループウェアなどのような企業の内部システムで該当電子文書を自動で登録したり処理したりすることを支援するために必要である。電子文書情報パッケージは、メッセージ流通における必須要素ではないため、業務上、必要なところだけに選択的に使われることができる。但し、使用時には次の12および2のような要件を遵守するべきである。1電子文書情報パッケージは、メッセージに含まれる電子文書とは別個のファイル形態で転送されるべきである。2電子文書情報パッケージは、XMLファイル形態で提供されるべきである。電子文書情報パッケージのメタデータは下記表12の通りである。[メッセージ保安]流通体系で最も重要な部分中の1つが転送メッセージに対する保安である。流通されるメッセージに対する保安としては、1送受信事実に対する否認防止、2転送メッセージに対する無欠性の保障、3転送相手方に対する認証、および4転送メッセージに対する機密性の保障が要求されるが、この中、1、2、3は転送メッセージに対する転送者の電子署名で支援することができ、4は転送メッセージに対する暗号化を通じて提供されるべきである。流通体系の最も基本となる流通メッセージングサーバ間の電子文書流通において適用される保安は、図10のようにメッセージの電子署名と暗号化を支援している。各区間には転送保安のためにネットワーク暗号化が適用されるべきである。コンテンツに対する電子署名はアプリケーション別の固有領域であり、本発明を説明するにおいては言及しない。そして、本発明では、受信者の公開キーで暗号化をするのが基本であるが、受信者の認証書がない場合または受信者が内部送受信者である場合には、受信個体の暗号化だけを選択可能である。また、メッセージ転送過程において、メッセージに対する認証情報を含ませて流通メッセージングサーバに転送し、この時、認証情報は、流通メッセージングサーバがクライアントを認証するための用途として主に使われる。また、流通メッセージングサーバが流通クライアントを認証するために認証書基盤の電子署名の他に、ID/PW基盤、SSOSingleSignOnによるトークン情報基盤などの様々な認証方式を採択することができる。以下、電子署名方法について詳細に説明すれば、次の通りである。流通メッセージングサーバは、他のシステム他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通中継サーバとの連係時、必ず自身の公認認証書を基盤に電子署名がなされるべきである。流通体系内の構成要素間の連係のための全ての流通メッセージは基本的に電子署名がなされるべきであるが、流通クライアントと流通メッセージングサーバ間の電子署名は選択事項であり、認証書基盤のユーザ認証方式である場合にのみ電子署名を適用する。但し、この場合、流通メッセージングサーバは、流通クライアントとの流通メッセージに対するユーザ認証、無欠性、送受信事実の否認防止に対する全ての責任を負わなければならない。以下、暗号化方案について詳細に説明すれば、次の通りである。流通体系で添付される文書は、保安のために転送者が暗号化を選択した後、転送が可能である。この部分は文書に対する機密性のための部分であり、ネットワーク暗号化とは区別され、ネットワーク暗号化が適用された場合にも流通文書をさらに暗号化することができる。暗号化する区間は、図10のように、1送信者の流通クライアントから受信者の流通メッセージングサーバ、または2送信者の流通クライアントから受信者の流通クライアントまでとなる。受信者が公認送受信者であり、公認認証書をアドレスディレクトリサーバに共に登録しておいた場合には、2送信者から受信者までの区間において暗号化を遂行し、そうではない場合には、1送信者から受信個体までの区間において暗号化が遂行される。添付する文書を暗号化する時、送信者は、1送信者から受信個体までの区間において暗号化が維持される場合には、送信者の流通メッセージングサーバ、受信者の流通メッセージングサーバ、受信者の流通クライアントなどの3ステップにおいて全て復号化が可能となるように暗号化をするべきである。2送信者から受信個体までの区間において暗号化が維持されるべきである場合には、送信者は、送信者の流通メッセージングサーバと受信者の流通メッセージングサーバが復号化が可能となるように暗号化をするべきである。送信個体と受信個体の流通メッセージングサーバは、添付された電子文書が暗号化された場合には、暗号化された状態で履歴管理のために保管し、送受信者が復号化された文書を基準に流通証明書を検証しようとする時に復号化をして検証できなければならない。このために流通メッセージングサーバは、廃棄された認証書の個人キーおよび個人キーへのアクセスのためのパスワードを続けて管理しなければならない。以下、暗号化方案において、暗号化の概要を説明すれば、次の通りである。流通体系で流通されるメッセージが送信者によって機密性を保障するべきであると判断された場合には、必ず次のような暗号化過程を遵守しなければならない。暗号文は、国内外で各種標準として使われるIETFRFC3852CMSCryptographicMessageSyntaxから提示するContentInfo構造体で表現されたEnveloped-DataContentTypeを使う。※RFC3852CMS1IETFは、TCP/IPのようなインターネット運営プロトコルの標準を定義する主体である。IETFはIABInternetArchitectureBoard、インターネットの技術的進化に対するInternetSocietyの監督機構の監督を受け、IETF構成員はInternetSocietyの個人または組織の構成員から選抜される。IETFにおいて製作された標準はRFCの形態で表され、国内外の多くのPKI基盤のソリューション各種の認証システム、タイムスタンプ、第3者保管機関の規格などはこのようなRFC標準文書を基盤に作られる。2CMSCryptographicMessageSyntaxは最初にRSA社が作成したPKCS7v1.5を根幹に作られ、これをIETFにおいて規格化したRFC標準で作成したものがRFC2630である。最初のPKCS7にはkeytransfer暗号化に用いられた対称キーを、RSAを利用して相手方に伝達方式だけがあったが、RFC2630のCMSにおいてはkeyagreementDHアルゴリズムを利用してキーを伝達する方式などが追加された。3その後、アルゴリズム部分を別途に分離および様々なキー管理技法を適用したRFC3369が2002年度に制定されたが、RFC3369の内容中の問題となる部分が多く報告されており、これを最終修正したバージョンが本発明に適用したRFC3852である。追加適用標準として、暗号文の生成時、ContentEncryption実際に転送される電子税金計算書パッケージにおいて使われるアルゴリズムおよびアルゴリズムに該当するパラメータなどは、IETFRFC3370CryptographicMessageSyntaxCMSAlgorithmおよびIETFRFC4010UseoftheSEEDEncryptionAlgorithminCryptographicMessageSyntaxCMSに従う。以下、暗号化方案において、暗号化対象データについて説明すれば、次の通りである。図11を参照すれば、伝達されるメッセージの暗号化対象は次の1および2の通りである。1メッセージの2番目のMIMEに入る流通情報2メッセージ本文の内容中、本文の実内容が入る<Text>領域と添付文書メッセージ本文にあるTextおよび添付文書は各々独立に暗号化され、該当位置に収録される。1番目の暗号化対象は受信者に伝達しようとする本文内容であり、XML本文中の<Text>項目内の値を対象とする。次は、対象データの構成方法である。データはASN.1BasicEncodingRulesBERを従い、DistinguishedEncodingRulesDERを遵守するようにする。上記表13のMainTextはテキスト形態の本文内容である。2番目以後の暗号化対象データは、3番目のMIMEから添付される添付文書であり、各添付文書の単位に独立に暗号化された後、該当MIMEに入る。次は、対象データの構成方法であり、データ構成は、1番目の暗号化方式と同様にASN.1BasicEncodingRulesBERを従い、DistinguishedEncodingRulesDERを遵守しなければならない。上記表14のAttachedDocはbinary形態の添付される文書である。以下、暗号化方案において、暗号化処理手続きおよび構造を説明すれば、次の通りである。下記表15は、RFC3852のEnvelopedDataの構成である。表15において、versionはRFC3852のsyntaxversionnumber構成に従う。iginatorInfoはkeymanagementアルゴリズムを利用せず、CRLを転送する必要がないので使わないRFC3852に定義されている。現在利用できる暗号用認証書のアルゴリズムがRSAであるため、RecipientInfosのKeyTransRecipientInfoを通じて受信者が復号化できるキーcontent-encryptionkeyを伝達する。encryptedContentInfoには、内部に定義されたAlgorithmIdentifierのアルゴリズムを基盤に暗号化したMainTextまたはAttachedDocを入れる。unprotectedAttrsは、このバージョンでは別途に利用しないため、送信者側においては管理の目的で値を入れることができるが、受信者側においてはこれを解いてみたり値を利用したりする必要はない。次の1および2は、RFC3852のEnvelopedDataの生成における主要部分に対する説明である。1EncryptedContentInfoの生成-ContentTypeは、id-data暗号化されたデータがどのような情報であるかを知らせる区分子-OID-情報であるを入れる。-contentEncryptionAlgorithmは、実際の暗号化に使われた対称キーアルゴリズム情報を入れる。-encryptedContentの入力は、上記で定義されたTaxInvoicePackageのDERエンコードされた値をcontentEncryptionAlgorithmに定義されたアルゴリズム方式で暗号化したOCTETSTRINGBinary値である。2RecepientInfoの生成-復号化をする対象が、送信個体、受信個体は必須であり、受信者は公認認証書がある場合にのみ可能であるため、実際RecipientInfosは下位にRecipientInfoを最小2つから最大3つまで持つようになる。-暗号用認証書がRSAを利用するため、ktri相手方RSA公開キーなどを利用してデータを暗号化した対称キーを送る方式のみを利用して構成するようにする。以下、暗号化方案において、メッセージに対するOID定義を説明する。メッセージ構成のためのObjectIdentifierは次の1および2の通りである。1EnvelopedDataType:RFC3852CMSにおいて実際データを伝達するフォーマットはContentInfoという構造体であり、内部にあるデータがどのようなデータであるかを確認できるようにContentTypeに入れる情報である。2EncryptedContentInfoのContentType:暗号化されたデータを入れる構造体であるEncryptedContentInfo構造体において、内部にあるデータがどのようなデータであるかを確認できるようにContentTypeに入れる情報である。以下、暗号化方案において、暗号化アルゴリズムを説明する。暗号化に使われるアルゴリズムは、大きく、2つに区分される。1対象データを直接暗号化するのに使う対称キーアルゴリズム2対称キーを受信者のみが復号化できるように伝達する公開キーアルゴリズム公開キーアルゴリズムは、使われる認証書がGPKIまたはNPKI体系の暗号用認証書であるため、RSA基盤のアルゴリズムを利用するようになり、対称キーアルゴリズムに対しては、必ず、下に属した対称キー暗号アルゴリズムの3種類SEED、ARIA、3DESのうちの1つを選択して使用するべきである。送信者側は、対称キー暗号アルゴリズムの3種類のうちの1つだけを支援しても関係ないが、受信者側は、3種類のアルゴリズムに対して全て支援可能でなければならない。1非対称キーアルゴリズムRSA:ランダムに生成され、データを暗号化した対称キー情報を相手方に安全に暗号化して伝達するのに使われ、例題は下記表20の通りである。2対称キーアルゴリズムSEED、ARIA、3DES:ランダムに生成され、実際の伝達データを暗号化するのに使われ、例題は下記表21の通りである。以下、暗号化方案において、暗号化用認証書の獲得と検証について説明する。暗号文生成のためには、実際データを復号化しようとする受信者側の認証書を獲得してこそ可能である。認証書の獲得のために、送信者は、アドレスディレクトリサーバに連係して、受信者または受信個体に対する認証書を獲得しなければならない。この時、獲得した認証書が受信個体の認証書であるか、公認受信者の認証書であるかによって機密性が維持される区間が変わる。送信者は、転送メッセージに対して暗号化を選択した場合、獲得した受信者または受信個体の認証書に基づいて暗号化を遂行した後、受信者にメッセージを転送する。メッセージ転送過程でエラーが発生して、流通中継ハブにメッセージ転送を依頼する場合にも、暗号化された内容は変更せずにそのまま伝達する。以下、暗号化方案において、EnvelopedDataの構成について説明する。図12は実際に受信者に伝達される暗号化された本文を示し、実際値の連係関係についてより正確に把握できるはずである。-ContentInfo:RFC3852に表現されたものであり、RFC3852の構成データであるSignedData、EnvelopedData、EncryptedDataなどを入れる一種のコンテナーである。構造体のcontentTypeは、contentがどのような情報であるかを示す。本指針では、id-envelopedDataという区分子ObjectIdentifierを入れるべきである。-EnvelopedData:暗号化情報を伝達するための構造体前節の説明を参照-EncryptedContentInfo:暗号化された情報を保管する構造体である。構造体のcontentTypeは、encryptedContentがどのような情報であるかを示す。本指針では、id-dataという区分子ObjectIdentifierを入れるべきである。contentEncryptionAlgorithmは、SEED、ARIA、3DES中の1つに対する区分子OIDを入れるべきであり、encryptedContentにランダムに生成された秘密キーを利用して該当アルゴリズムで暗号化したデータをOCTETSTRINGバイナリデータに入れる。-RecipientInfo:どのような方法を利用して受信者が復号化するかを選択する構造体である。本指針では、KeyTransRecipientInfoを利用しなければならない。-KeyTransRecipientInfo:受信者が復号化できるように上記で述べたencryptedContentを暗号化したランダムな秘密キーを、受信者の公開キーを利用して暗号化して伝達するのに利用する構造体である。暗号化した秘密キーはencryptedKeyに入れ、誰の公開キーを利用したかに対する情報であるRecipientIdentifierおよび秘密キーを暗号化するのに利用したアルゴリズム情報であるKeyEncryptionAlgorithmIdentifierなどを含む。以下、復号化方案について説明する。暗号化された電子文書を受信した受信者は、図12を通じて説明する手続きに応じて暗号化された本文と添付文書を復号化する。受信者は、暗号化された本文と添付文書を各々復号化することにより、平文形態の本文と添付文書を得ることができる。-1ステップ:暗号文からEnvelopedData構造を抽出し、これを読み込む。-2ステップ:EnvelopedData構造体から復号用情報構造体RecipientInfoを抽出した後、抽出した復号用情報構造体から暗号化された対称キー情報KeyTransRecipientInfoを得る。-3ステップ:受信者は、暗号化された対称キー情報から抽出したencryptedKeyを受信者の個人キー認証書の公開キーとマッピングされるを通じて復号化することにより、本文および添付文書を暗号化する時に使った対称キーを得る。-4ステップ:1ステップで抽出したEnvelopedData構造体から本文または添付文書の暗号化された構造体を得る。-5ステップ:3ステップを通じて獲得した対称キーを利用して4ステップで抽出した暗号化された本文または添付文書を復号化する。-6ステップ:最終的に復号化された本文と添付文書を獲得する。[ネットワーク保安]送信者と受信者間に流通されるメッセージの機密性のために電子文書流通の全区間メッセージング送信者の流通クライアントと流通メッセージングサーバ間、送信者と受信者の流通メッセージングサーバ間、受信者の流通メッセージングサーバと流通クライアント間において、ネットワーク保安のためにSSLSecureSocketsLayerを適用する。[メッセージ送受信プロセス]流通体系内の関係者間、システム間には様々な業務プロセスが存在する。流通体系内で最も基本的なメッセージ送受信プロセスがあり、これを支援するための色々なプロセスが存在する。メッセージ送受信プロセスは、送信者と受信者間にメッセージを直接やり取りする形態で郵便やe-メールのように相手方に文書が交換されるプロセスである。送信者と受信者間にメッセージを送受信するために、1受信者に対する物理アドレスおよび保安情報の獲得、2メッセージ転送および転送確認、3業務受信者の受信確認、4流通証明書の発給および保管の4ステップのプロセスからなる。この時、流通証明書に対するプロセスは、証明を受けようとする内容に応じて詳細プロセスの流れが変われるが、これに対する基本的な流れを図14で提示しており、詳細な説明は下記表22の通りである。メッセージ送受信プロセスは、転送プロセスと受信プロセスに区分することができ、転送プロセスは、流通クライアントと流通メッセージングサーバ間の連係方式によって同期式転送と非同期式転送に細分化される。以下、図15および表23を参照し、同期式メッセージ送受信プロセスについて説明すれば、次の通りである。同期式メッセージ送受信プロセスは、送信個体の流通クライアントが流通メッセージングサーバに転送を要請すれば、これを受信個体の流通メッセージングサーバにリアルタイムで転送し、これに対する応答を送信者の流通メッセージングサーバを介して同期式で返してもらうプロセスである。同期式プロセスは、転送に対する結果を即刻に流通クライアントが確認することができるので、業務プロセスに対する定義が単純になる。このような同期式メッセージ送受信プロセスに対する詳細な説明は下記表23の通りである。以下、図16および表24を参照し、非同期式メッセージ送受信プロセスについて説明すれば、次の通りである。非同期式転送プロセスは、送信個体の流通クライアントが流通メッセージングサーバに転送を要請すれば、流通メッセージングサーバに転送要請に有効性有無だけを検証した後、要請に対する受信確認メッセージを流通クライアントに返す。これを受信個体の流通メッセージングサーバにリアルタイムで転送し、これに対する応答を送信個体の流通メッセージングサーバを介して同期式で返してもらうプロセスである。非同期式プロセスは、転送しようとするメッセージの容量が大きかったり、1つのメッセージに対して複数の受信者を指定したりする場合のように、メッセージ転送に対する時間が多くかかるためにクライアントが応答を待つことが困難な状況で使う。このような同期式メッセージ送受信プロセスに対する詳細な説明は下記表24の通りである。以下、メッセージ受信プロセスについて詳細に説明すれば、次の通りである。文書受信者が流通クライアントを介してメッセージを受信するプロセスは図17の通りであり、プロセスに対する説明は下記表25の通りである。受信者の流通メッセージングサーバが送信者からメッセージを受信すれば、これに対する応答として受信証明書を転送し、最終受信者のメッセージ箱に文書を入れておく。流通クライアントは、随時に流通メッセージングサーバに受信されたメッセージに対する目録を要請し、新たに受信されたメッセージがあれば、受信メッセージ目録を応答メッセージとして受けるようになり、この中、詳細情報を要請するメッセージを通じて受信文書をGetする。[物理アドレス獲得プロセス]流通体系に参加する送信個体は、相手方にメッセージを転送する前に、公認電子アドレス情報に基づいて物理的な実アドレス情報を必ず知るべきであり、付加的に添付する文書を暗号化するためには、アドレスディレクトリサーバにある受信者の公開キー情報を獲得しなければならない。公認電子アドレスの物理アドレスを獲得する手続きは必須ステップとして下記の1~4がある。1送信個体は、受信個体のアドレス情報を基準に受信個体に対する物理アドレス情報および保安情報の獲得のためにアドレスディレクトリサーバに問い合わせる2アドレスディレクトリサーバは、送信個体の問い合わせを受信/検証した後、これを処理3送信個体は、受信した物理アドレスを基準に経路設定をして、受信個体にメッセージ転送4受信個体の流通メッセージングサーバは、これを受けて、ユーザアカウントまたは内部区分子に応じてメッセージを内部的に分配また、流通体系において、公認電子アドレスの物理アドレスを獲得する方式は2つに区分することができ、下記の1および2の通りである。1流通クライアントが受信者のアドレス情報を入力する時点でアドレスディレクトリサーバに検索要請をして、物理アドレスと受信者の公開キーを持ってくる方式:1公認電子アドレスの有効性を事前にチェックするためのものである、2流通クライアントと流通メッセージングサーバ送信個体間にメッセージ暗号化が必要な時2流通クライアントが流通メッセージングサーバにメッセージ送信を要請した後、流通メッセージングサーバがアドレスディレクトリサーバから物理アドレスを持ってくる方式公認電子アドレスの物理アドレスおよび保安情報の獲得プロセスは図19の通りである。[流通中継支援プロセス]流通体系は、送信個体と受信個体間の直接通信P2Pを基本とする。しかし、付加的にネットワーク、受信個体の流通メッセージングサーバのエラーなどによってメッセージ流通に障害が発生した場合、ユーザの便宜および流通の円滑な支援のために流通を中継/代行する中継プロセスを提供する。送信個体がメッセージを受信個体に転送する過程でエラーが発生して転送が失敗する場合に、電子文書流通ハブ内の流通中継サーバは、送信個体を代行してメッセージを委託/転送することによって送信個体の転送事実を立証し、送信個体のシステム的な負担を減らす役割を遂行する。図23はこれに対する基本的な流れを提示し、図24は流通中継サーバがメッセージを中継するプロセスを示している。下記表26は流通中継プロセスを段階的に説明している。[流通証明書などの保管プロセス]流通体系内で行われる全ての流通行為と関連し、その結果として、流通証明書は必ず生成され、第3者保管機関に保管されなければならない。これは、流通証跡を含んだ流通証明書を法的に認められた第3者保管機関に保管することにより、流通事実に対する法的推定力が確保できるためである。流通証明書を保管するプロセスは、電子文書流通とは別個のプロセスであって、流通行為事実を証明するための支援プロセスである。そのために、全ての流通メッセージングサーバは、事前に流通証明書を受信、保管できる機能を備えた特定第3者保管機関に加入するべきである。さらには、送信個体が電子文書の内容証明を望む場合、流通証明書の以外にメッセージ全体を第3者保管機関に保管することもできる。第3者保管機関が流通証明書を受信して保管するためには、次の1および2のような2つの付加的なシステムを具備しなければならない。1第3者保管機関事業者の流通メッセージングサーバ:流通体系内の流通メッセージングサーバと流通証明書を送受信するために必要なシステム2第3者保管機関連係クライアントモジュール:第3者保管機関事業者の流通メッセージングサーバを介して受信した流通証明書を第3者保管機関に保管するために第3者保管機関連係インターフェースと通信するためのモジュール但し、第3者保管機関事業者が電子文書中継者を兼ねる場合には、流通メッセージングサーバは追加的に必要ではなくなる。図28は送受信個体と第3者保管機関事業者間の流通証明書を保管するプロセスを示しており、流通証明書保管プロセスを段階的に説明すれば、下記表27の通りである。[公認電子アドレス登録などの管理プロセス]送受信個体が流通体系に参加するためには、公認電子アドレスを申請して登録を受けるべきであり、登録代行機関および管理機関は、公認電子アドレスと関連した情報の登録などを管理するべきである。公認電子アドレス情報の管理プロセスには、公認電子アドレスと関連した登録、変更、削除などに対する管理プロセスとブラックリスト/ホワイトリストの管理プロセスがある。管理機関は、公認電子アドレスの効率的な管理のために、公認電子アドレスの登録代行機関を設けて公認電子アドレスを管理する。登録代行機関は、次の1~4のような業務を遂行する。1公認電子アドレス申請者の身元確認などの審査業務2公認電子アドレス登録者の登録情報の変更業務3公認電子アドレスの登録抹消などの業務支援4その他の公認電子アドレスの管理と関連した業務管理機関は、登録代行機関として第3者保管機関および電子文書中継者のうちから要件を満足する者を選定することができる。以下、公認電子アドレス登録プロセスについて説明すれば、次の通りである。流通体系に参加しようとする企業/機関/個人などは公認電子アドレスを申請するべきであり、登録代行機関は申請された情報を審査、処理して結果を通知するべきである。これと関連したプロセスは図22の通りである。以下、公認電子アドレス登録情報の変更プロセスについて説明すれば、次の通りである。既に登録された公認電子アドレスと関連した情報は色々な事情のために変更し得るが、但し、公認電子アドレスと所有者情報は同一性を維持しなければならないため、変更することはできない。公認電子アドレスと関連した情報変更に対する権限は、登録代行機関に委任して処理するようにする。但し、情報変更に対する履歴情報を管理機関と登録代行機関間のサービスレベル協約SLAに応じて保管しなければならない。これと関連したプロセスは図23の通りであり、図23を参照すれば、公認電子アドレスの変更は本人だけが可能である。個人の場合、公認電子アドレス、登録番号、名前は変更不可であるため、公認電子アドレスを脱退し、新規で生成しなければならない。そして、企業の場合、公認電子アドレスは変更不可であり、登録番号事業者登録番号および商号名は、変更時、必ず該当情報に変更してもらった新規公認認証書と共に変更しなければならない。図24は登録代行機関の変更プロセスを示し、このような図24を参照すれば、登録代行機関を変更しようとする場合には、1既存の登録代行機関から脱退、2新規な登録代行機関を介した新規登録過程を経なければならない。この場合、アドレスディレクトリサーバに公認電子アドレスの一時留保を要請できなければならない。アドレスディレクトリサーバは、全ての公認電子アドレスの脱退時、公認電子アドレスの一時留保を選択できるようにすることにより、登録代行機関の変更時に一定期間公認電子アドレスを維持できるようにする。以下、公認電子アドレスの更新および使用停止、削除のプロセスについて説明すれば、次の通りである。既に登録された公認電子アドレスは、設定した使用年限に合わせて更新しなければならない。公認電子アドレスの登録後、サービス政策に基づいて設定しておいた使用年限が過ぎる前に所有者が更新するべきである。仮に所有者が更新しなければ、公認電子アドレスに対する所有権を失い、公認電子アドレスは自動抹消される。さらには、公認電子アドレスの満了期間にならなくても申請者が使用停止や抹消を望む場合、これに対する機能を提供するべきである。[電子文書の書式適用プロセス]このプロセスは、メッセージ流通以後のステップの活用度を高めるためのプロセスである。メッセージ内に含まれている電子文書を、企業の内部システムにおいて、自動または半自動化された方式で処理するためのものである。流通メッセージングサーバは、当事者間のメッセージ送受信機能を専担し、流通クライアントは、送受信するためのメッセージを送受信者が利用しやすいようにインターフェースを提供する。その後のステップは、メッセージ内にある電子文書を活用するステップである。電子文書の書式登録機や電子文書の書式は電子文書の活用段階をより効率的に運用するための方法などを提供する。流通体系に応じて流通される文書の様式には制限はない。イメージ、オフィス文書、動画などが可能であるが、ユーザの便宜性を高めるために、流通体系においては書式形態の文書作成機能を付加的に提示する。このような付加機能は電子文書交換EDI機能を導入したものであり、送受信個体間に約束された電子文書フォーマットを基盤に文書データを送受信して、受信個体の内部システムにおいて受信した電子文書を自動で変換処理できるようにした。電子文書の書式は次の1および2のような2つの方式で活用可能である。1電子文書流通ハブにある電子文書の書式登録機を活用する方式で電子税金計算書のように標準化された電子文書の書式を主に使用2送受信個体間に合意した電子文書の書式を共有して活用する方式で特定企業に特化した非標準化された電子文書の書式を主に使用以下、電子文書の書式登録機の活用について詳細に説明すれば、次の通りである。企業、機関や個人ユーザは、電子文書の書式登録機に登録された電子文書の書式を検索した後、流通クライアントに登録して使える。電子文書の書式登録機を活用する方式は、次の1および2のような2つの方式がある。1流通クライアントから直接電子文書の書式登録機にある電子文書を検索して持ってくる方式2電子文書の書式登録機サイトから電子文書を検索してローカルPCにダウンロード後、流通クライアントに登録して使う方式電子文書の書式登録機は、標準化された電子文書の書式を登録/活用するため、管理機関が体系的に運営/管理しなければならず、次の1~3のような基準を有し得る。1ユーザは、電子文書の書式登録機サイトを通して申請しなければならない。申請はサイトから提供するフォーマットと手続きに従わなければならない。2登録/申請した電子文書は管理機関の審査を経て登録されるべきである。3各々の電子文書は体系的なコンテキスト文脈を基盤に分類されるべきである。図25は電子文書の書式登録機を活用するプロセスに対する基本的な流れを提示し、具体的には、図25aは電子文書の書式登録機と流通クライアントが直接連係する場合を示し、図25bは電子文書の書式登録機サイトを利用する場合を示している。下記表29は、流通クライアントと直接連係して書式を活用するプロセスについて示す。下記表30は電子文書の書式登録機サイトを活用するプロセスについて示す。以下、合意した電子文書の書式活用について説明すれば、次の通りである。特定企業に限定された書式を、企業が運営するサイトなどにおいて書式を配布して、特定企業と関連した当事者と取り引きをするための目的で使うためのものである。図26は合意した電子文書の書式を利用する手続きを示しており、図26と関連したプロセスに対する説明は下記表31の通りである。[スパムメッセージの処理プロセス]流通体系において、送信者は認証された流通メッセージングサーバを介して転送をし、受信者もこれを通じて受信するので、スパムが発送された時、送信者に責任を問える基盤構造を有している。しかし、特定送信者が電子文書中継者にユーザアカウントを開設し、これを利用して商業的な目的のためのメッセージなどを転送する場合がある。現在の認証方式がシステムの技術的内容に対する認証だけを対象にしているため、スパムメッセージなどを初期に根本的に遮断することが容易ではない状況である。このようなスパムメッセージなどの流通を遮断するために、流通体系においては、認証目録管理基盤のホワイトリスト、スパムや悪意的な意図を有したブラックリストを管理できる体系を提供して、流通体系の安全性と信頼性を向上させるようにする。スパムメッセージ申告および送信相手方に対する確認のための機能は必須機能であり、全ての流通メッセージングサーバはこの機能を必ず構築しなければならない。以下、スパムメッセージ申告方案について説明すれば、次の通りである。スパムメッセージの申告手続きを段階的に説明すれば、下記表32の通りである。受信者は、受信したメッセージがスパムメッセージと判断されれば、図27のようなプロセスによってスパムメッセージをアドレスディレクトリサーバに申告する。ホワイトリストとブラックリストの役割は次の通りである。1ホワイトリスト:送信流通メッセージングサーバが認証を受けて正式に登録されたメッセージングサーバに対する情報のみが記録される2ブラックリスト:転送者のアドレスがスパム発送者として登録された場合、ブラックリストに登録される※同一の流通メッセージングサーバを介してブラックリストに登録されるスパムアドレスが重複して発生する場合、管理機関は、流通メッセージングサーバに対する認証取り消しの有無を判断した後、認証を取り消し、ホワイトリストから削除することができる。以下、スパムメッセージ受信時の処理方案について説明すれば、次の通りである。受信個体は、メッセージ受信時、送信相手方が信頼できるほどの正当なユーザであるか否かを確認するために、アドレスディレクトリサーバのホワイトリストとブラックリストを確認した後、受信拒否をするか否かを決定する。送信者に対する確認は、受信時点で1リアルタイムで確認するか、受信者の流通メッセージングサーバシステムにCache形態で管理している目録を通じて確認する2周期的な確認方法がある。1リアルタイム確認プロセス:受信個体は、メッセージを受信する時点でアドレスディレクトリサーバに送信個体のアドレスがホワイトリスト、ブラックリストに登録されているか否かを判断した後、メッセージに対する受信拒否の可否を決定する。図28はスパムメッセージをリアルタイムで確認するプロセスを示す。2周期的な確認プロセス:受信者は、アドレスディレクトリサーバからホワイトリストとブラックリストを周期的にもらって自体管理し、これを基盤に送信者のアドレスがホワイトリスト、ブラックリストに登録されたか否かを判断した後、メッセージに対する受信拒否の可否を決定図29は流通メッセージングサーバとアドレスディレクトリサーバ間のスパムメッセージ管理のために周期的に確認を行うプロセスを示す。[エラー処理プロセス]流通体系において、エラー発生類型は下記の1と2を含む2つに区分される。1同期式応答に対するエラー発生:同期式応答に対するエラーの場合は、要請メッセージに対する処理結果を受ける時まで要請者は待機している状態であるので、エラーを直ちに認知可能2非同期式応答に対するエラー発生:要請者は、要請内容のみを伝達した後、それに対する処理結果をその後に受けるので、追加的なエラー処理が行われるべきである以下、同期式エラー処理方案について説明すれば、次の通りである。同期式転送に対する全てのエラーは、転送者が直ちに確認可能であるので、再転送することを基本とする。再転送方式については流通体系に参加する企業や機関のシステム政策に応じて決定されるが、同一のメッセージ転送に対しては同一のMessageId値を設定して再度送ることを基本とする。同期式エラー処理と関連した類型は次の1~4の通りである。1要請メッセージの送信失敗:送信者がメッセージを転送する過程で転送エラーが発生して、受信者に要請メッセージが伝達できなかった場合であり、送信者は、転送試みに対するtimeoutまたはネットワークエラーメッセージなどを通じて送信失敗を認知するようになる。2応答メッセージの受信失敗:送信者がメッセージを正常に転送したが、受信者から応答メッセージを受ける過程でエラーが発生した場合である。1要請メッセージの送信失敗と区分されないのでエラーに対して同一の方式で処理するが、受信者は要請メッセージを正常に受けたので処理方式が異なる。3エラーメッセージの受信:送信者がメッセージを正常に転送したが、受信者がメッセージを処理する過程でエラーが発生した場合である。この場合、送信者の処理方式はエラーメッセージの類型に応じて異なる。43段階同期式エラー:流通クライアントが流通メッセージングサーバを介して他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通中継ハブと連係する3個体間のメッセージ流通は、連係類型中、最終結果を即刻に確認するために同期式で連係する方案を支援する。この過程で流通メッセージングサーバと受信者間の連係ステップでエラーが発生すれば、流通メッセージングサーバは、即刻にエラーを発生させた後、これを流通メッセージングサーバに応答メッセージとして伝達するべきである。以下、非同期式エラー処理方案について説明すれば、次の通りである。流通クライアントが流通メッセージングサーバを介して他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通中継サーバと連係する3個体間のメッセージ流通は、流通クライアントが最終受信者の状況に独立に運営できるように非同期式方式の連係を支援したりもする。非同期式転送に対する最終エラーは同期式転送とは異なり、転送者が直ちに確認できないため、流通メッセージングサーバが最終的にエラーを確認した時点で流通クライアントのためのエラーメッセージを発生させ、これを流通クライアントが受信できるようにするべきである。[電子文書閲覧サービス]電子文書閲覧サービスは、送信者と受信者間に電子文書を直接やり取りする交換の形態ではない、送信者のシステムまたは第3者保管機関に保管されている電子文書を閲覧できるように提供するサービスである。電子文書閲覧サービスは既存の流通体系をそのまま利用する。但し、送信者は、受信者に電子文書を含んだメッセージを転送するのではなく、送信者システムまたは第3者保管機関に保管されている電子文書を閲覧できる閲覧権限を含んだメッセージを転送することが特徴である。これと関連した手続きは次の通りである。1受信者の公開キー獲得2電子文書の保管3閲覧権限およびDRMなどの保安が適用された証書生成4閲覧権限などの証書の転送および転送確認5受信者による電子文書の閲覧6流通閲覧証明書または閲覧証跡の発給および保管電子文書閲覧サービスは、送信者が自体システムを利用する方法と第3者を利用する方法に区分することができる。図30は送信者が自体システムを活用して電子文書閲覧サービスを利用する流れを提示しており、図30で明示している手続きについて説明すれば、下記表35の通りである。上記のようなサービスを提供するために、送信者は、流通体系の以外に電子文書閲覧サービスを提供できるシステムを具備しなければならない。図31は送信個体が第3者を活用して電子文書閲覧サービスを利用する流れを示しており、図31で提示している手続きについて説明すれば、下記表36の通りである。[企業内のシステムとの連係方法]企業/機関は、内部的に様々な電子文書を生産し保管したり、外部の企業/機関などと様々な方式で電子文書をやりとりしたりする。郵便などのようなオフラインで交換したり、e-メールや業務関連システムで交換したりする。これらの各々の流通体系は、企業/機関の内部と連係する時、下記表37および図119のような方式で連係する。公認電子アドレス基盤の電子文書流通体系は、次のような方式で企業/機関の内部と連係することができる。以下、内部システムと連動する方式について説明すれば、次の通りである。内部システムと連動する方式は、主に企業や機関において流通メッセージングサーバを設置する時に使用する形態で、流通クライアントを内部システムにシステム統合SI形態で開発する方式であり、詳細な説明および図は下記表38および図120の通りである。以下、内部システムと連動しない方式について説明すれば、次の通りである。内部システムと連動しない方式は、主に電子文書中継者からユーザアカウントの発給を受けて利用する公認送受信者に好適な形態であり、電子文書中継者が提供するウェブ形態の流通クライアントを利用するか、電子文書中継者が配布する流通クライアントアプリケーションをローカルPCに設置して利用する方式であり、詳細な説明および図面は下記表39および図121の通りである。[外部システムとの連係方案]流通体系は、自体システムとインターネットを基盤に流通ネットワークを有する。電子文書流通は流通体系内だけで行われるので制約がある。流通体系は、直接連結されていないシステムとの電子文書流通のために外部連係ゲートウェイサーバを設けている。外部連係ゲートウェイサーバの基本概念図は図32の通りである。外部連係ゲートウェイサーバは中間経由地の役割を遂行する。一方は流通体系のための流通メッセージングサーバなどを有しており、他方は外部システムとの連係のための各々のアダプターを有している。このように、外部システムと連係するためには、業務的な要素と技術的な要素を考慮しなければならない。業務的な要素は、連係と関連した業務手続き、方法などに対する当事者間の合意により、管理機関と外部連係システム管理機関は相互間にサービスレベル協約SLAを結ばなければならない。技術的な要素は、連係と関連して必要なユーザ認証、メッセージング、メッセージフォーマットなどと関連した技術要素をいう。外部システムと連係をするための技術的な原則を整理すれば、次の1~6の通りである。1アドレス送信者は、中間経由地アドレスと最終目的地アドレスを記載するべきである。2ユーザ認証送信者は、外部システムが送信者を認証できるようにユーザ情報を提供するべきである。事前に外部システムに加入している場合、外部システムの認証識別子を使える。3メッセージ分解組み立て受信したメッセージを分解して外部システムに合せたメッセージに組み立てるべきである。4メッセージ保安などメッセージに適用された暗号化、DRMなどに対する保安などを検証/変換するべきである。5メタデータ情報メッセージ内に含まれてメッセージおよび電子文書の関連情報を検証/変換するべきである。6外部連係システムに対する識別流通体系と連係する外部システムは追加や変更することができる。外部システムに対する情報はアドレスディレクトリサーバにおいて管理し、流通メッセージングサーバにおいては、必要な場合、アドレスディレクトリサーバに問い合わせして処理しなければならない。外部システムと連係して電子文書が流通される手続きは図33の通りである。上述したような本発明の好ましい実施形態による電子文書流通システムおよびこれを用いた電子文書流通方法において、電子文書流通が行われるためには、アドレスディレクトリサーバ、流通メッセージングサーバ、流通クライアント、流通中継サーバのような構成要素が必要であり、これらの構成要素は、電子文書流通の全体的な流れの中で互いに連係しなければならない。このように各構成要素間において互いに連係して動作するためには、連係のための通信プロトコル、メッセージ交換方式、連係メッセージ構造などが定義されなければならない。以下では、各構成要素間の連係のために先ず共通の基盤通信プロトコルおよびメッセージ交換方式を定義し、各連係類型別のメッセージ構造を標準で定義して提示し、これにより、本発明は、相異なる環境および開発方法によって構築された構成要素間の連係が円滑になって、相互運用を可能にすることができる。[連係のための基盤通信プロトコル]公認電子アドレス基盤の電子文書の流通体系下で、各構成要素間の情報および電子文書を流通するために必要な電子文書流通連係インターフェースにおいて、流通連係メッセージはebXMLMessageServicesv2.0規格以下、ebMSを基盤にし、これを階層的に拡張してより一般化された形態で定義される。ebXML基盤の構造は、SOAP、SOAPwithAttachment、Security、そしてReliabilityなど、独立的ではあるが、互いに密接な関係のある要素で構成されている。連係のための基盤通信プロトコル以下、基盤通信プロトコルは、このような基本要素を基盤に流通体系で必要な要素を定義し、これを有機的に再組み合わせした形態で構成される。基盤通信プロトコルは、転送しようとするメッセージを構成するパッケージング、メッセージ封筒の構成、メッセージ保安、そして最終的にメッセージを転送し受信するメッセージ送受信で構成される。以下、基盤プロトコル構成において、メッセージパッケージングについて説明すれば、次の通りである。流通連係メッセージの全体メッセージ構造はebMSv2.0規格を準用する。本基盤通信プロトコルで定義するメッセージは2つの論理的なMIMEPartを有する。1番目のMIMEPartはヘッダコンテナーと呼ばれ、SOAPメッセージを含んでおり、SOAPメッセージは再びHeaderとBodyとから構成される。2番目のMIMEPartからはペイロードコンテナーと呼ばれ、アプリケーションレベルのメッセージおよび添付文書を含む。1番目のMIMEPartに対する詳細説明は下記で述べる。この領域には、メッセージ流通のための共通情報メッセージのルーティング関連情報、SOAPメッセージ交換パターン、電子署名、エラー情報、および2番目に添付されるデータに対する位置情報などが記述される。2番目のMIMEPartは各連係インターフェース別の要請および応答メッセージを添付し、この連係インターフェースの類型に応じて、3番目以後のMIMEPartの存在有無が決定される。流通体系を利用して電子文書や証明書を伝達する時、3番目のMIMEPartに含まれる。流通連係メッセージの基本的な構造は図34の通りであり、図34において、1SOAP-ENV:Headerは流通プロトコル規格に応じて構成され、MesageHeaderおよびSignature情報で構成され、2SOAP-ENV:BODYは流通プロトコル規格で定義されたMainfest要素情報およびユーザログイン情報が入り、3転送コンテナー1ペイロードコンテナー1は要請メッセージおよび応答メッセージを含む部分であり、連係インターフェースの類型および要請、応答、エラーメッセージの有無に応じてビジネス文書の詳細内容が定義され、4転送コンテナー2ペイロードコンテナー2は連係インターフェースの類型に応じて添付されるべき文書がペイロードコンテナー2から順次入る。このような流通連係メッセージは、SimpleObjectAccessProtocolSOAP1.1、およびSOAPMessageswithAttachmentのような標準規格を遵守しなければならない。図34において、流通連係メッセージの全てのMIMEHeader要素は、SOAPMessageswithAttachments規格を遵守しなければならない。さらに、メッセージ内のContent-TypeMIMEHeaderは、必ずSOAPメッセージ文書を含むMIMEBody部分のMIMEメディア類型と同一のtype属性を有するべきである。SOAP規格に応じたSOAPメッセージのMIME類型は、text/xml値を有するべきであるとなっている。ルート部分は、[RFC2045]に準ずる構造を有するContent-IDMIMEHeaderを含むことと、Multipart/Relatedメディア類型に対する必須のパラメータに追加して、startパラメータ[RFC2387]においては選択事項が常に存在しなければならない。multipart/relatedメッセージパッケージのMIMEHeaderの例題は下記表40の通りである。図34において、1番目のMIMEPartヘッダコンテナーは必ずSOAPメッセージを含むべきである。ヘッダコンテナーのMIMEContent-Typeheaderは、SOAP規格に応じ、text/xml値を有するべきである。Content-Typeヘッダはcharset属性を含むべきであり、例題は下記表41の通りである。そして、MIMEcharset属性は、SOAPメッセージを生成するのに用いられる文字群を識別するために使われる。MIMEcharset属性値とヘッダコンテナーに位置するSOAPメッセージのエンコード宣言部は必ず一致するべきであり、その値はUTF-8であるべきである。ヘッダコンテナーの例題は下記表42の通りである。図34において、ペイロードコンテナーの個数は、連係インターフェース種類に応じて異なり得る。各ペイロードコンテナーは、ebMS規格に応じ、SOAPBody内のManifest要素によって参照されるべきである。例題は下記表43の通りである。図34において、本発明で必須要素として指定したMIMEHeaderの他、実現便宜上、MIMEHeaderを追加することも可能である。この時、追加されるMIMEHeaderは必ず[RFC2045]に明示された項目でなければならない。しかし、追加的なMIMEHeaderに対しては、これを追加しない側がこれを認知し解釈する必要はない。以下、基盤プロトコル構成において、メッセージ封筒の構成について説明すれば、次の通りである。SOAP規格に準じて全ての拡張要素内容は、有効なネームスペースに限定されるべきである。本発明で定義された全てのebXMLSOAP拡張要素内容は、ebXMLSOAPEnvelope拡張ネームスペースに限定されるべきである。ネームスペース宣言部は、SOAPEnvelop、HeaderまたはBody要素に含まれているか、各SOAP拡張要素に直接含まれていてもよい。SOAPEnvelopは、SOAPメッセージのRoot項目でSOAPメッセージ内の各種Namespaceを宣言する。宣言するべきNamespaceは次の通りである。メッセージ封筒スキーマ構造は図35の通りであり、メッセージ封筒の例題は下記表45の通りである。SOAPHeader要素は、SOAPEnvelop要素の1番目の子要素として次の1~4のような拡張要素を含む。1MessageHeader:メッセージのルーティング情報To/From、などとメッセージに関する他の文脈情報を含む必須要素2SyncReply:メッセージを送受信する方式が同期式であることを示す要素3Signature:SOAPメッセージおよび添付文書に対する電子署名値を示す要素4ErrorList:メッセージ構文の検証、メッセージ電子署名の検証などのメッセージを処理する過程でエラーが発生して、エラーメッセージを返す時に該当エラー内訳を入れる要素SOAPBody要素は、SOAPEnvelope要素の2番目の子要素としてManifestのような拡張要素を含む。Manifestは、ペイロードコンテナーまたはウェブのように他の場所に位置したデータを示す要素である。Manifest要素は、ペイロードコンテナーを参照するために必ず存在しなければならない。Manifest要素は、1個以上のReference要素で構成された複合要素である。各Reference要素は、ペイロードコンテナーに含まれたペイロード文書の一部として含まれるか、URLにアクセス可能な遠距離のリソースであるメッセージに関連したデータを識別する。SOAPBodyには、ペイロードデータをのせないように勧告している。Manifestの目的は次の1および2の通りである。1ebXMLメッセージと関連した特定のペイロードを容易で直接的にアクセスできるようにする2パーシング作業がなくてもアプリケーションがペイロードを処理できるか否かを判断できるようにするManifest要素は、次の1~3のような属性と要素とから構成されている。11個のid属性21個のversion属性31個以上のReference要素Reference要素は、次の1~2のような下位要素で構成された複合要素である。10個以上のSchema要素:親Reference要素から識別されたインスタンス文書を定義するスキーマに対する情報20個以上のDescription要素:親参照要素によってReferenceされたペイロードオブジェクトに対する説明Reference要素は、それ自体が[XLINK]の単純リンクである。XLINKは、現在W3Cの候補勧告案CRである。ここで、XLINKが使われたことは、連関関係の説明を明確にするための用語として提供されていることを知らせる。XLINKプロセッサまたはエンジンの使用が必須ではないが、実現要求事項によっては有用である。Reference要素は、上記で提供された要素の内容と共に次の1~5のような属性内容を含んでいる。1id:Reference要素に対するXMLID2xlink-type:この属性はXLINK単純リンクで要素を定義。これは、simpleという固定された値を有する3xlink:href:この必須属性は参照されたペイロードオブジェクトのURI値。これは、[XLINK]明細の単純リンクに準ずるものであるべきである4xlink:role:この属性は、ペイロードオブジェクトやその目的を説明するリソースを識別。存在するのであれば、[XLINK]明細に準ずる有効なURI値を有するべきである5この他に他の有効ネームスペースの属性が存在することができる。受信MSHは、上記で定義されたものの以外に外部のネームスペース属性は無視することができるSchema要素は、参照する項目がそれを記述するスキーマを有しているのであれば例:XMLSchema、DTD、またはDatabaseSchema、そのSchema要素は、Reference要素の子要素として存在しなければならない。これは、スキーマとバージョンを識別する方法として使われ、親Reference要素によって識別されるペイロードオブジェクトを定義する。Schema要素は、次の1および2のような属性を有する。1location:スキーマの必須URI2version:スキーマのバージョン識別子xlink:href属性がcontentidURIschemecidであるURIを含んでいれば、そのcontent-idを有するMIMEはメッセージのペイロードコンテナーに表現されるべきである。そうでなければ、errorCodeをMimeProblemに、severityをErrorにするエラーを発信当事者に伝達するべきである。xml:href属性がcontentidURIschemecidであるURIを含んでいなければ、URIは解釈されず、実現に応じて、エラーを伝達するべきか否かを決定しなければならない。エラーが伝達されるべきであると決定されれば、errorCodeをMimeProblemに、severityをErrorにするエラーを発信当事者に伝達するべきである。下記表46は典型的な1個のペイロードMIMEBody部分を有するメッセージのMainfestを示す。以下、基盤プロトコル構成において、メッセージの細部構成要素について説明すれば、次の通りである。MessageHeader要素は、全てのebXMLメッセージに表現されるべき必須要素であり、必ずSOAPHeader要素の子要素として表現されるべきである。MessageHeader要素は、次のような下位要素で構成された複合要素である。MessageHeaderのElement構造は下記表47の通りである。MessageHeaderのスキーマ構造は図36の通りであり、MessageHeader項目コード表は下記表48の通りであり、業務別Service/Action項目は下記表49の通りである。MessageHeaderの例示は下記表50の通りである。SyncReplyが存在するのであれば、同期式送信であることを意味し、次の1~4の属性を有する。1id属性2version属性3SOAPactor属性必ずhttp://schemas.xmlsoap.org/soap/actor/next値を有するべきである4SOAPmustUnderstand属性SyncReply要素の例題は下記表51の通りである。流通連係メッセージは、送受信過程で生じ得る様々な危険要素に対応するために必ず電子的に署名されなければならない。したがって、Signature要素がSOAPHeaderの子要素として必ず存在するべきである。流通連係メッセージにおいて電子署名の対象となる部分は、SOAPメッセージ全体とペイロードコンテナーに含まれたメッセージおよび添付文書である。各署名対象情報はDigestされ、電子署名情報内に各々含まれる。[XMLDSIG]規格に応じて電子署名を遂行する過程は次の1~4の通りである。1SOAPEnvelopeにSignatureMethod、CanonicalizationMethod、Reference要素を有したSignedInfo要素と、必須ペイロードオブジェクトを[XMLDSIG]に規定された通りに生成-SignedInfo下位の1番目のReference項目は、SOAPメッセージ全体を対象にするので、URI値にを記述する。-2番目のReference項目からは、ペイロードコンテナーの個数だけ反復て記述するようにし、この時、URI値は添付文書のMIMEHeaderに定義されたcontentID値を記述するDigest対象は、MimeHeaderを除いたContent部分である。2正規化した後、[XMLDSIG]に指定された通り、SignedInfoに指定されたアルゴリズムを基準にSignedInfoのSignatureValueを算出3[XMLDSIG]に指定された通り、SignedInfo、KeyInfo、SignatureValue要素を含むSignature要素を生成4SOAPHeaderのSignature要素をSOAPHeader要素に含ませる電子署名時に使われるアルゴリズム情報は次の通りである。アルゴリズムは、W3CXML-SignatureSyntaxandProcessingRFC3275のアルゴリズム部分6.0Algorithmsに基本的に従う。また、国内固有のアルゴリズムを支援するために、TTAS.IF-RFC3075拡張性生成言語の電子署名構文と処理XML-SignatureSyntaxandProcessing韓国情報通信技術協会、2004年で定義されたアルゴリズムを利用する。次は流通プロトコルにおいて利用するアルゴリズム目録である。メッセージ送受信時、電子署名の生成および検証過程における曖昧性を最小化するために、次の1~5目録以外のアルゴリズムはその使用を制限する。1電子署名Namespace2ハッシュDigest;データを縮約するのに使われるアルゴリズムは、公認認証体系の関連規定を遵守するようにする。3電子署名Signature;メッセージの電子署名時に使われるアルゴリズムは、公認認証体系の関連規定を遵守するようにする。4正規化Canonicalization;論理的に同一の文書に対して物理的に色々な表現が可能なXMLの特性のため、同じ文書に対して電子署名値が異に出ることがある。このような現象を防止するために必ず正規化過程を経なければならない。正規化は、注釈のない正規XMLCanonicalXML、omitscommentsを使うようにする。5変換Transform;全体XMLデータ中の実際の署名対象となるデータを加工し選択する過程を経るアルゴリズムとして様々な変換アルゴリズムが存在するが、その中の3つだけを利用するようにする。第1は電子署名が署名対象内に含まれる形式に従うのでEnvelopedSignature変換であり、第2は前記で説明した正規化Canonicalization、そして第3は署名対象情報を選択するXPathフィルタリングXPathFilteringである。電子署名構文の構造は図37の通りであり、電子署名されたメッセージの例題は下記表57の通りである。ErrorList要素は、メッセージ構文の検証、メッセージ電子署名の検証などの通信プロトコル処理過程でエラーが発生する場合に、Header下位に生成して送信者に同期式で返すべきである。ErrorList要素が生成される場合には、必ずMessageHeader要素内にRefToMessageIdが存在するべきであり、RefToMessageIdはエラーが発生したメッセージのMessageIdを指し示すべきである。ErrorList要素は次の1~5のような属性を有する。1id属性2SOAPmustUnderstand属性3version属性4highestSeverity属性51個以上のError要素報告されるエラーがなければ、ErrorList要素は存在してはいけない。ErrorListの構造は図38の通りである。highestSeverity属性は、全てのError要素の最も深刻な状態を示す。特に、あるError要素がseverityをErrorに設定していれば、highestSeverityはErrorに設定するべきであり、そうではない場合には、highestSeverityをWarningに設定するべきである。Error要素は次の1~6のような属性を有する。1id属性;id属性は文書内でErrorList要素を唯一に識別する役割をする。2codeContext属性;codeContext属性はerrorCodesのネームスペースまたはスキーマを示す。これは必ずURIでなければならない。この属性の基本値はurn:oasis:names:tc:ebxml-msg:service:errorsである。この属性に基本値がなければ、その明細の実現はerrorCodesを使用するということを示す。3errorCode属性;必須errorCode属性はエラーを持つメッセージのエラーが有した本質を指示する。4severity属性;必須属性であるseverity属性はエラーの深刻性を示す。有効な値はWarningおよびErrorのようである。Warningは、エラーは存在するが、対話中の他のメッセージは正常に生成されることを示し、Errorは、復旧不可能なエラーがメッセージに存在し、対話中にこれ以上他のメッセージは生成されないことを示す。5location属性;location属性はエラーが存在するメッセージ部分を示す。仮にエラーがebXML要素内に存在し、要素がwell-formedであれば、location属性の内容は[Xpointer]であるべきである。6Description属性;Description要素の内容は、xml:lang属性において定義された言語でエラーの叙述的な説明を提供する。通常、これは、XMLパーサーやメッセージを検証するソフトウェアが生成したメッセージとなる。この意味は、この内容はError要素を生成したソフトウェアの販売者や開発者によって定義されるということを意味する。ErrorListの例題は下記表58の通りである。流通プロトコルを基盤にメッセージを送受信する過程でエラーが発生すれば、エラーを認知した送受信個体は相手方にエラー内容を報告しなければならない。報告するべきエラーは、メッセージ構造エラー、メッセージングエラー、および保安エラーのようである。本発明で定義する流通プロトコルより下位レイヤーに属するHTTPおよびSocketのようなデータ通信プロトコルと関連したエラーは、データ通信プロトコルにおいて支援する標準メカニズムによって発見し報告されるべきであり、本発明で定義するエラー報告メカニズムは使わない。エラーコードはエラー対象および類型別に区分され、詳しい内容は下記表59の通りである。以下、HTTPバインディング方案において、HTTPを通じたメッセージ転送方案について説明すれば、次の通りである。HTTPバインディングの例題は下記表60の通りである。以下、HTTPバインディング方案において、HTTPResponseコードについて説明すれば、次の通りである。本発明において、HTTPレベルの応答コードを返すために、[RFC2616]に定義されたHTTP応答コードを利用しなければならない。主な応答コードは下記表61の通りである。以下、HTTPバインディング方案において、HTTP転送の保安方案について説明すれば、次の通りである。流通体系内の全ての流通メッセージングサーバと流通メッセージングサーバ間の転送や流通メッセージングサーバと流通クライアント間の転送は、ネットワーク転送保安のために、必ずSSLSecureSocketLayerV3.0を利用したHTTP/SSecureHypertextTransferProtocolを使って処理するべきである。本発明による流通体系において、エラーの発生類型は、大きく、同期式応答に対するエラー発生の場合と非同期式応答に対するエラー発生の場合に区分される。同期式応答に対するエラーの場合は、要請メッセージに対する処理結果を受ける時まで、最初の要請者は待機している状態であるのでエラーを直ちに認知することができるが、非同期式応答に対するエラーは、要請者は要請内容だけを伝達した後、それに対する処理結果を後で受けるので、追加的なエラー処理が行われるべきである。以下、エラー処理方案において、同期式エラー処理方案について説明すれば、次の通りである。流通メッセージングサーバと他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通クライアント、流通中継サーバ間の2個体間の全てのメッセージ流通は同期式方式の流通である。この他にも、流通クライアントが流通メッセージングサーバを介して他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通中継サーバと連係する3個体間のメッセージ流通は、連係類型に応じて同期式または非同期式方式で連係する。同期式転送に対する全てのエラーは転送者が直ちに確認可能であるので再転送することを基本とする。再転送方式に対しては、流通体系に参加する企業や機関のシステム政策に応じて決定されるが、同一のメッセージ転送に対しては同一のMessageId値を設定して再び送ることを基本とする。同一のMessageId値でメッセージを送ることにより、メッセージ転送過程のエラーが転送時点のエラーではなく、受信者が受信成功後に同期式で応答メッセージを転送する過程でエラーが発生した場合に対しても、重複メッセージ受信を検知することによって同一の要請を重複して処理することを防止する。同期式エラーの送信者と受信者は、各々連係類型に応じ、流通メッセージングサーバ、アドレスディレクトリサーバ、流通クライアント、流通中継サーバであってもよい。1要請メッセージの送信失敗:送信者がメッセージを転送する過程で転送エラーが発生して、受信者に要請メッセージが伝達できない場合であり、送信者は転送試みに対するtimeoutまたはネットワークエラーメッセージなどを通じて送信失敗を認知するようになる。図39は要請メッセージ送信失敗時のプロセスを示しており、処理手続きは下記の1~3の通りである。1メッセージ送信者が転送する過程で転送エラーが発生する場合であって、多くの場合がネットワークエラーによって発生する2送信者は、HTTPエラーのようなエラーメッセージを受けると、同一のメッセージを再び再転送要請するべきである3送信者は受信者に受信確認メッセージを受けた場合にのみ転送成功として認識する2応答メッセージの受信失敗:送信者がメッセージを正常に転送したが、受信者から応答メッセージを受ける過程でエラーが発生した場合である。送信者の立場では、1要請メッセージの送信失敗と区分できないのでエラーに対して同一の方式で処理するが、受信者は要請メッセージを正常に受けたので処理方式が異なる。図40は応答メッセージの受信失敗と関連したプロセスを示し、処理手続きは下記の1~3の通りである。1メッセージが受信者に正常に伝達されたが、送信者が受信者から受信確認メッセージを受けていない場合2この場合、送信者は送信失敗エラーとして認識し、受信者に同一のメッセージを同一のMessageIdで再転送するようになる3受信者は、受信した文書のMessageIdが以前の受信メッセージと同一である場合には、重複受信として受信確認メッセージを送った後に内部処理3エラーメッセージ受信:送信者がメッセージを正常に転送したが、転送したメッセージを受信した受信者がメッセージを処理する過程でエラーが発生した場合である。この場合、送信者の処理方式はエラーメッセージの類型に応じて異なる。通信プロトコル上のエラー類型は、上述したErrorList項目を、各連係インターフェース別に要請メッセージに対する内部処理過程で発生したエラーに対しては、各連係インターフェースのメッセージ構造を参照する。図41はエラーメッセージ受信と関連したプロセスについて示し、処理手続きは下記の1~3の通りである。1送信者が受信者に転送したメッセージが正確に伝達されたが、転送メッセージそのものに誤りがあって、エラーメッセージの応答を受けた場合2この場合、送信者は、要請メッセージを再生成した後にメッセージを再転送することが一般的であるが、エラー類型に応じてメッセージ処理を異にすることができる3送信者が要請メッセージを再転送する時、転送するメッセージのMessageIdは同一である必要はなく、業務状況に応じて異に処理することができる43段階同期式エラー:流通クライアントが流通メッセージングサーバを介して他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通中継サーバと連係する3個体間のメッセージ流通は、連係類型中、最終的な結果を即刻に確認するために同期式で連係する方案を支援する。この過程中、流通メッセージングサーバと受信者間の連係ステップでエラーが発生すれば、流通メッセージングサーバは、即刻にエラーを発生させた後、これを流通メッセージングサーバに応答メッセージとして伝達しなければならない。図42は3段階同期式エラーと関連したプロセスについて示し、処理手続きは下記の1~3の通りである。1流通クライアントが流通メッセージングサーバと連係してメッセージ転送をするステップにおいては転送成功をしたが、流通メッセージングサーバの次の受信者アドレスディレクトリサーバ、他の流通メッセージングサーバ、流通中継サーバなどに転送する過程でエラーが発生する2この時のエラーは、流通メッセージングサーバと受信者間の同期式転送において発生する全てのエラーの場合を指し示す3流通メッセージングサーバは、エラーを認知した時点で流通クライアントのためのエラーメッセージを発生させ、これを流通クライアントに応答メッセージとして伝達する流通メッセージングサーバが生成するエラーメッセージは下記表62のような構造で構成される。以下、エラー処理方案において非同期式エラー処理方案について説明すれば、次の通りである。流通クライアントが流通メッセージングサーバを介して他の流通メッセージングサーバ、アドレスディレクトリサーバ、流通中継サーバと連件する3個体間のメッセージ流通は、連係類型中、流通クライアントユーザが最終受信者の状況に独立に運営できるように非同期式方式の連係を支援したりもする。非同期式転送に対する最終エラーは同期式転送とは異なり、転送者が直ちに確認することができないので、流通メッセージングサーバが最終的にエラーを確認した時点で流通クライアントのためのエラーメッセージを発生させ、これを流通クライアントが受信できるようにする。図43は非同期式エラー処理方案と関連したプロセスを示し、処理方案は下記の1~4の通りである。1流通クライアントが流通メッセージングサーバと連係してメッセージ転送をするステップにおいては転送成功をしたが、流通メッセージングサーバの次の受信者アドレスディレクトリサーバ、他の流通メッセージングサーバ、流通中継サーバなどに転送する過程でエラーが発生する2この時のエラーは流通メッセージングサーバと受信者間の同期式転送において発生する全てのエラーの場合を指し示す3流通メッセージングサーバは、再試し後、最終的にエラーを認知した時点で流通クライアントのためのエラーメッセージを発生させた後、流通クライアントの受信箱に伝達する4流通クライアントが流通メッセージングサーバに受信メッセージを要請するステップにおいて、自身の受信箱に受信されたエラーメッセージを通じて以前の要請メッセージに対するエラーを認知する流通メッセージングサーバが生成するエラーメッセージは下記表63のような構造で構成される。[流通メッセージングサーバとアドレスディレクトリサーバ間の連係インターフェース]アドレスディレクトリサーバは、流通体系で最も基本となる公認電子アドレス情報を管理しているシステムであり、電子文書流通において必ず必要なシステムである。流通メッセージングサーバとアドレスディレクトリサーバ間の連係インターフェースは、大きく、2つに機能が区分される。第1は登録代行機関との公認電子アドレスの登録などの業務に関するインターフェースであり、第2は流通メッセージングサーバとの物理アドレスの問い合わせ/応答、スパム申告などの業務に関するインターフェースである。上記の登録代行機関との公認電子アドレスの登録などの業務に関するインターフェースは別に区分することができるが、登録代行機関を電子文書中継者または第3者保管機関事業者が行うため、流通メッセージングサーバ内にインターフェース機能を挿入した。但し、送受信個体に設置される流通メッセージングサーバには、公認電子アドレスの登録などと関連した連係インターフェースは入らない。流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェース機能は下記表64の通りである。このような流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースの詳細内容について説明すれば、次の通りである。先ず、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、共通事項について説明すれば、次の1および2の通りである。1要請メッセージのMessageHeader拡張送信個体の流通メッセージングサーバがアドレスディレクトリサーバに送信する要請メッセージの1番目のMIMEPartのSOAPメッセージ内には送信個体の電子署名情報が含まれて伝達されるべきであり、アドレスディレクトリサーバがSOAPメッセージの電子署名に使われた認証書の所有者が該当送信個体と一致するかを検証VID検証するのに必要な追加的な送信個体の情報CorpNum、RValueも含まれて伝達されるべきである。追加的な送信個体の情報は、要請メッセージのSOAPメッセージ内のMessageHeader要素の下位に拡張要素anyother位置として位置するべきである。拡張要素の構造は下記表65の通りであり、拡張要素の例示は下記表66の通りである。2全体メッセージ構造流通メッセージングサーバとアドレスディレクトリサーバ間の連係インターフェースは、メッセージの1番目のMIMEPartにはSOAPメッセージが位置し、2番目のMIMEPartには該当要請および応答に対する流通メッセージが位置する。流通メッセチンサーバとアドレスディレクトリサーバ間のSOAP構造は図44の通りである。以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、公認電子アドレスの登録について説明すれば、次の通りである。公認電子アドレスの登録処理と関連したメッセージ交換流れは図45の通りである。要請流通メッセージの構造は下記表67の通りであり、メッセージの例題は下記表68の通りである。応答流通メッセージの構造は下記表69の通りであり、メッセージの例題は下記表70の通りである。以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、公認電子アドレス情報の変更インターフェースについて説明すれば、次の通りである。公認電子アドレス情報の変更インターフェースは、電子文書中継者がアドレスディレクトリサーバに登録された公認送受信者の公認電子アドレス情報に対する変更を要請して応答を受けるインターフェースであり、変更しようとするユーザ情報および公認電子アドレス情報を要請メッセージに含ませて転送した後、アドレスディレクトリサーバの変更処理の結果を応答メッセージとして受信する。公認電子アドレス情報の変更処理と関連したメッセージ交換流れは図46の通りである。要請流通メッセージの構造は下記表71の通りであり、メッセージの例題は下記表72の通りである。応答流通メッセージの構造は下記表73の通りであり、メッセージの例題は下記表74の通りである。図73において、ErrorCodeは、ResultCodeが失敗0として入力された場合、エラー原因に該当するエラーコードを入力以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、公認電子アドレスの削除インターフェースについて説明すれば、次の通りである。公認電子アドレスの削除インターフェースは、電子文書中継者がアドレスディレクトリサーバに登録された公認送受信者の公認電子アドレス情報の公認電子アドレス情報に対する削除を要請して応答を受けるインターフェースであり、削除しようとするユーザ情報および公認電子アドレス情報を要請メッセージに含ませて転送した後、アドレスディレクトリサーバの削除処理の結果を応答メッセージとして受信する。公認電子アドレスの削除処理と関連したメッセージ交換流れは図47の通りである。要請流通メッセージの構造は下記表75の通りであり、メッセージの例題は下記表76の通りである。応答流通メッセージの構造は下記表77の通りであり、メッセージの例題は下記表78の通りである。表77において、ErrorCodeは、ResultCodeが失敗0として入力された場合、エラー原因に該当するエラーコードを入力。以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、物理アドレス情報の検索インターフェースについて説明すれば、次の通りである。物理アドレス情報の検索インターフェースは、電子文書中継者または送受信個体がアドレスディレクトリサーバに電子文書受信者の公認電子アドレスに該当する物理アドレス情報とメッセージ保安処理のための公認認証書情報を要請して応答を受けるインターフェースであり、電子文書受信者の公認電子アドレスおよび公認認証書の要請有無を要請メッセージに含ませて転送した後、アドレスディレクトリサーバから電子文書受信者の物理アドレス情報IPアドレスまたはDomainアドレスおよび公認認証書情報を応答メッセージとして受信する。物理アドレス情報の検索処理と関連したメッセージ交換流れは図48の通りである。要請流通メッセージの構造は下記表79の通りであり、メッセージの例題は下記表80の通りである。応答流通メッセージの構造は下記表81の通りであり、メッセージの例題は下記表82の通りである。以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、スパムメッセージの申告受付インターフェースについて説明すれば、次の通りである。スパムメッセージの申告受付インターフェースは、電子文書中継者または送受信個体がアドレスディレクトリサーバにスパムメッセージを申告するインターフェースであり、スパム送信者の公認電子アドレスとスパムメッセージ情報を要請メッセージに含ませて転送した後、アドレスディレクトリサーバからスパム申告の受付有無を応答メッセージとして受信する。アドレスディレクトリサーバは、申告受付されたスパムメッセージに対するスパム有無の判断が完了すれば、流通メッセージングサーバ相互間の連係インターフェースのメッセージ転送インターフェースを使って処理結果を通知する。スパムメッセージの申告受付処理と関連したメッセージ交換流れは図49の通りである。要請流通メッセージの構造は下記表83の通りであり、メッセージの例題は下記表84の通りである。応答流通メッセージの構造は下記表85の通りであり、メッセージの例題は下記表86の通りである。以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、ホワイトリスト通知インターフェースについて説明すれば、次の通りである。ホワイトリスト通知インターフェースは、送受信個体にホワイトリスト流通体系に参加する送受信個体および送受信者の公認電子アドレス目録を通知するためのインターフェースである。ホワイトリスト通知と関連したメッセージ交換流れは図50の通りである。要請流通メッセージの構造は下記表87の通りであり、メッセージの例題は下記表88の通りである。応答流通メッセージの構造は下記表89の通りであり、メッセージの例題は下記表90の通りである。以下、流通メッセージングサーバとアドレスディレクトリサーバ間のインターフェースにおいて、ブラックリスト通知インターフェースについて説明すれば、次の通りである。ブラックリスト通知インターフェースは、送受信個体にブラックリスト受信拒否リストを通知するためのインターフェースである。通知されたブラックリストは、送受信個体によってブラックリストの管理に使われる。ブラックリスト通知と関連したメッセージ交換流れは図51の通りである。要請流通メッセージの構造は下記表91の通りであり、メッセージの例題は下記表92の通りである。応答流通メッセージの構造は下記表93の通りであり、メッセージの例題は下記表94の通りである。[流通メッセージングサーバ相互間の連係インターフェース]流通メッセージングサーバは、基本的に他の送受信個体または電子文書中継者が構築した流通メッセージングサーバとメッセージ送受信のために連係をしなければならない。このような基本機能の他に、流通証明書を第3者保管機関に保管するために第3者保管機関事業者の流通メッセージングサーバと他のメッセージングサーバ間には、流通証明書の伝達連係機能もさらに提供されるべきである。流通メッセージングサーバ相互間の連係インターフェースは、メッセージングサーバ相互間のメッセージおよび流通証明書を送受信するためのプロトコルとして、下記表95のようなインターフェースに区分される。このような流通メッセージングサーバ相互間のインターフェースの詳細内容について説明すれば、次の通りである。先ず、流通メッセージングサーバ相互間のインターフェースにおいて、共通事項について説明すれば、次の1の通りである。1要請および応答メッセージのMessageHeader拡張流通メッセージングサーバ相互間の連係インターフェースメッセージの1番目のMIMEPartであるSOAPメッセージ内には送信者の電子署名情報が含まれて伝達されるべきであり、受信者がSOAPメッセージの電子署名に使われた認証書の所有者が該当送信者と一致するかを検証VID検証するのに必要な追加の送信者の情報CorpNum、RValueも含まれて伝達されるべきである。追加の送信者の情報は、要請および応答メッセージのSOAPメッセージ内のMessageHeader要素の下位に拡張要素anyother位置として位置するべきである。拡張要素の構造は下記表96の通りであり、スキーマ構造は下記表97の通りである。以下、流通メッセージングサーバ相互間のインターフェースにおいて、メッセージ転送インターフェースについて説明すれば、次の通りである。メッセージ転送インターフェースは、流通メッセージングサーバが他の流通メシジングサーバにメッセージを転送する時に使われる。メッセージ転送において、メッセージ交換流れは図52の通りである。メッセージ交換時の要請フォーマットは図53の通りであり、図53のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージ、そしてユーザが添付した文書がある場合には3番目のMIMEPartから位置する。要請流通メッセージの構造は下記表98の通りであり、実際の例示は次の通りである。メッセージ交換時の応答フォーマットは図54の通りであり、図54のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには応答流通メッセージ、そして3番目のMIMEPartには受信証明書が位置する。仮に要請メッセージに対する処理過程でエラーが発生したとすれば、3番目のMIMEPartは生成しない。応答流通メッセージの構造は下記表100の通りであり、実際の例示は下記表101の通りである。以下、流通メッセージングサーバ相互間のインターフェースにおいて、流通証明書の伝達インターフェースについて説明すれば、次の通りである。流通証明書の伝達インターフェースは、流通メッセージングサーバが他の流通メッセージングサーバに閲覧証明書を転送する時に使われる。また、流通中継サーバが電子文書転送の依頼を受けて受信流通メッセージングサーバに送信した後、応答メッセージとして受信した受信証明書を転送依頼流通メッセージングサーバに転送する時にも使われる。流通証明書伝達処理と関連したメッセージ交換流れは図55の通りである。流通証明書の伝達要請のフォーマットは図56の通りであり、図56のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージ、そして3番目のMIMEPartには流通証明書が位置する。要請流通メッセージの構造は下記表102の通りであり、実際の例示は下記表103の通りである。流通証明書の伝達応答のフォーマットは図5757aは成功の場合、57bはエラーの場合の通りであり、図57のような全体メッセージ構造において、要請メッセージに対する処理が成功である場合、1番目のMIMEPartに受信確認AcknowledgementSOAPメッセージだけが位置し、エラーの場合は、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartにはエラー応答流通メッセージが位置する。応答流通メッセージの構造は下記表104の通りであり、表104は処理結果がエラーの場合にだけ該当される。以下、流通メッセージングサーバ相互間のインターフェースにおいて、流通証明書の保管要請インターフェースについて説明すれば、次の通りである。流通証明書の保管要請インターフェースは、送受信個体の流通メッセージングサーバが流通証明書を第3者保管機関に保管するために、第3者保管機関事業者の流通メッセージングサーバに流通証明書に対する保管要請をする時に使われる。本インターフェース上の応答メッセージには受信確認情報だけが含まれ、流通証明書を第3者保管機関に保管した結果として発給を受けた最初登録証明書は、後述する第3者保管機関の保管結果の伝達インターフェースを使って保管要請流通メッセージングサーバに伝達する。流通証明書の保管要請処理と関連したメッセージ交換流れは図58の通りである。流通証明書の保管要請のフォーマットは図59の通りであり、図59のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージ、そして3番目のMIMEPartには流通証明書が位置する。要請流通メッセージの構造は下記表105の通りであり、実際の例示は下記表106の通りである。流通証明書の保管応答のフォーマットは、図6060aは成功の場合、60bはエラーの場合の通りであり、図60のような同じ全体メッセージ構造において、要請メッセージに対する処理が成功の場合、1番目のMIMEPartに受信確認AcknowledgementSOAPメッセージだけが位置し、エラーの場合は、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartにはエラー応答流通メッセージが位置する。応答流通メッセージの構造は下記表107の通りであり、表107は処理結果がエラーの場合だけに該当される。以下、流通メッセージングサーバ相互間のインターフェースにおいて、第3者保管機関の保管結果の伝達インターフェースについて説明すれば、次の通りである。第3者保管機関の保管結果の伝達インターフェースは、第3者保管機関事業者の流通メッセージングサーバが第3者保管機関に流通証明書を保管した後、該当結果として受信した最初登録証明書を、流通証明書の保管を要請した流通メッセージングサーバに送信する時に使われる。第3者保管機関の保管結果の伝達処理と関連したメッセージ交換流れは図61の通りである。第3者保管機関の保管結果伝達のフォーマットは図62の通りであり、図62のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージ、そして3番目のMIMEPartには最初登録証明書が位置する。仮に流通証明書を第3者保管機関に保管する過程でエラーが発生したとすれば、3番目のMIMEPartは生成しない。要請流通メッセージの構造は下記表108の通りであり、実際の例示は下記表109の通りである。第3者保管機関の保管結果応答のフォーマットは図6363aは成功の場合、63bはエラーの場合の通りであり、図63のような全体メッセージ構造において、要請メッセージに対する処理が成功である場合は、1番目のMIMEPartに受信確認AcknowledgementSOAPメッセージだけが位置し、エラーの場合は、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartにはエラー応答流通メッセージが位置する。応答流通メッセージの構造は下記表110の通りであり、表110は処理結果がエラーの場合だけに該当される。[流通クライアントと流通メッセージングサーバ間の連係インターフェース]流通メッセージングサーバは、実際に電子文書流通を要請するユーザ内部送受信者または公認送受信者のためのシステム流通クライアントと連係して、ユーザに文書送受信の基本機能を提供しなければならない。流通クライアントと流通メッセージングサーバ間の連係インターフェースは、流通クライアントが電子文書を送信し受信するために、一次的に流通メッセージングサーバと通信するためのプロトコルとして、下記表111のようなインターフェースに区分される。流通クライアントと流通メッセージングサーバ間の連係インターフェースの詳細内容を説明すれば、次の通りである。先ず、流通クライアントと流通メッセージングサーバ間の連係インターフェースの共通事項について説明すれば、次の1の通りである。1要請メッセージのMessageHeader拡張流通クライアントが流通メッセージングサーバに送信する要請メッセージの1番目のMIMEPartであるSOAPメッセージ内にはユーザの電子署名情報が含まれて伝達されるべきであり、流通メッセージングサーバがSOAPメッセージの電子署名に使われた認証書の所有者が該当ユーザと一致するかを検証VID検証するのに必要な追加のユーザの情報IDN、RValueも含まれて伝達されるべきである。該当情報は、要請メッセージのSOAPメッセージ内のMessageHeader要素の下位に拡張要素anyother位置として位置するべきである。また、同一認証書を使う複数の内部ユーザに対する個別の認証情報が追加されてもよい。拡張要素の構造は下記表112の通りであり、拡張要素の例示は下記表113の通りである。以下、流通クライアントと流通メッセージングサーバ間の連係インターフェースにおいて、メッセージ転送要請インターフェースについて説明すれば、次の通りである。メッセージ転送要請インターフェースは、流通クライアントが流通メッセージングサーバを介してメッセージを転送するために流通メッセージングサーバにメッセージを転送する時に使われる。流通クライアントのメッセージ転送処理の流れは図64の通りである。流通クライアントのメッセージ転送要請のフォーマットは図65の通りであり、図65のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージが位置する。そして、ユーザが添付した文書がある場合、3番目のMIMEPartから位置する。要請流通メッセージの構造は下記表114の通りであり、実際の例示は下記表115の通りである。流通クライアントのメッセージ転送応答のフォーマットは図6666aは成功の場合、66bはエラーの場合の通りであり、図66のような全体メッセージ構造において、要請メッセージに対する処理が成功の場合は、1番目のMIMEPartに受信確認AcknowledgementSOAPメッセージだけが位置し、エラーの場合は、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartにはエラー応答流通メッセージが位置する。応答流通メッセージの構造は表116の通りであり、表116は処理結果がエラーの場合にだけ該当される。以下、流通クライアントと流通メッセージングサーバ間の連係インターフェースにおいて、メッセージ目録要請インターフェースについて説明すれば、次の通りである。メッセージ目録要請インターフェースは、流通クライアントが流通メッセージングサーバに受信されたメッセージ目録を要請する時に使われる。流通クライアントのメッセージ目録処理の流れは図67の通りである。流通クライアントのメッセージ目録要請のフォーマットは図68の通りであり、図68のような全体メッセージ構造において1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージが位置する。要請流通メッセージの構造は下記表117の通りであり、実際の例示は下記表118の通りである。流通クライアントのメッセージ目録応答のフォーマットは表67の通りであり、表67のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには応答流通メッセージ流通メッセージングサーバに受信された流通メッセージ目録が位置する。応答流通メッセージの構造は下記表119の通りであり、実際の例示は下記表120の通りである。以下、流通クライアントと流通メッセージングサーバ間の連係インターフェースにおいて、メッセージ詳細情報の要請インターフェースについて説明すれば、次の通りである。メッセージ詳細情報の要請インターフェースは、流通クライアントが流通メッセージングサーバに受信された特定メッセージと添付文書を要請する時に使われる。流通クライアントの詳細情報の要請処理流れは図69の通りである。流通クライアントのメッセージ詳細情報要請のフォーマットは図70の通りであり、図70のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージ本文が位置する。要請流通メッセージの構造は下記表121の通りであり、実際の例示は下記表122の通りである。流通クライアントのメッセージ詳細情報応答のフォーマットは図72の通りであり、図72のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには応答流通メッセージ流通メッセージの詳細情報、そして添付文書がある場合、3番目のMIMEPartから順に位置する。応答流通メッセージの構造は下記表123の通りであり、実際の例示は下記表124の通りである。以下、流通クライアントと流通メッセージングサーバ間の連係インターフェースにおいて、スパムメッセージ申告インターフェースについて説明すれば、次の通りである。スパムメッセージ申告インターフェースは、流通クライアントが流通メッセージングサーバにスパムメッセージを申告する時に使われる。流通メッセージングサーバは、アドレスディレクトリサーバにスパムメッセージを申告後、結果を流通クライアントに伝達する。流通クライアントのスパムメッセージ申告処理の流れは図73の通りである。流通クライアントのスパムメッセージ申告のフォーマットは図74の通りであり、図74のような全体メッセージ構造において1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージが位置する。要請流通メッセージの構造は下記表125の通りであり、メッセージの例題は下記表126の通りである。流通クライアントのスパムメッセージ応答のフォーマットは図75の通りであり、図75のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには応答流通メッセージ流通メッセージングサーバに受信された流通メッセージ目録が位置する。応答流通メッセージの構造は下記表127の通りであり、メッセージの例題は下記表128の通りである。以下、流通クライアントと流通メッセージングサーバ間の連係インターフェースにおいて、物理アドレス検索インターフェースについて説明すれば、次の通りである。物理アドレス検索インターフェースは、流通クライアントが流通メッセージングサーバに物理アドレス検索を要請する時に使う。流通メッセージングサーバは、アドレスディレクトリサーバに物理アドレスを検索後、結果を伝達する。物理アドレス検索処理と関連し、メッセージ交換の流れは図76の通りである。物理アドレス検索要請メッセージのフォーマットは図77の通りであり、図77のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージが位置する。要請流通メッセージの構造は下記表129の通りであり、メッセージの例題は下記表130の通りである。物理アドレスの検索応答メッセージのフォーマットは図78の通りであり、図78のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには応答流通メッセージ流通メッセージングサーバに受信された流通メッセージ目録が位置する。応答流通メッセージの構造は下記表131の通りであり、実際の例示は下記表132の通りである。[流通メッセージングサーバと流通中継サーバ間の連係インターフェース]流通中継サーバは、電子文書流通体系で流通メッセージングサーバ間に直接電子文書を転送する過程でエラーが発生して転送が失敗した場合、送信流通メッセージングサーバを代行して電子文書転送を遂行するシステムである。流通中継サーバは情報通信産業振興院が管理しており、全ての流通メッセージングサーバは流通中継サーバと連係してP2P流通過程でのエラー時の支援を受けることができる。流通メッセージングサーバと流通中継サーバ間の連係インターフェースは、流通メッセージングサーバが流通中継サーバに電子文書転送を依頼するためのプロトコルとして、下記表133のようなインターフェースに区分される。先ず、流通メッセージングサーバと流通中継サーバ間の連係インターフェースの共通事項について説明すれば、次の1の通りである。1要請メッセージのMessageHeader拡張流通メッセージングサーバと流通中継サーバ間の連係インターフェースメッセージの1番目のMIMEPartであるSOAPメッセージ内には流通メッセージングサーバの電子署名情報が含まれて伝達されるべきであり、流通中継サーバがSOAPメッセージの電子署名に使われた認証書の所有者が該当流通メッセージングサーバと一致するかを検証VID検証するのに必要な追加の流通メッセージングサーバの情報CorpNum、RValueも含まれて伝達されるべきである。追加の流通メッセージングサーバの情報は、SOAPメッセージ内のMessageHeader要素の下位に拡張要素anyother位置として位置するべきである。拡張要素の構造は下記表134の通りであり、拡張要素の例示は下記表135の通りである。以下、流通メッセージングサーバと流通中継サーバ間の連係インターフェースのメッセージ転送依頼インターフェースについて説明すれば、次の通りである。メッセージ転送依頼インターフェースは、流通メッセージングサーバが他の流通メッセージングサーバにメッセージを転送する過程で他の流通メッセージングサーバ側の受信エラーが発生した場合、流通中継サーバにメッセージ転送を依頼し、送信証明書の発給を受ける時に使われる。流通中継サーバは、流通メッセージングサーバのメッセージ転送依頼に対する受付結果だけを直ちにリターンし、受信流通メッセージングサーバにメッセージを転送した後、受信した受信証明書は、上述した流通証明書伝達インターフェースを使って転送依頼流通メッセージングサーバに転送する。メッセージ中継処理の流れは図79の通りである。メッセージ中継要請メッセージのフォーマットは図80の通りであり、図80のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには要請流通メッセージが位置する。そして、ユーザが添付した文書がある場合、3番目のMIMEPartから位置する。要請流通メッセージの構造は下記表136の通りであり、実際の例示は下記表137の通りである。メッセージ中継応答メッセージのフォーマットは図81の通りであり、図81のような全体メッセージ構造において、1番目のMIMEPartにはSOAPメッセージ、2番目のMIMEPartには応答流通メッセージ、そして3番目のMIMEPartには受信証明書が位置する。仮に要請メッセージに対する処理過程でエラーが発生したとすれば、3番目のMIMEPartは生成しない。応答流通メッセージの構造は下記表138の通りであり、実際の例示は下記表139の通りである。以下、上述したような本発明の好ましい実施形態による電子文書流通システムおよびこれを用いた電子文書流通方法の他の実施形態について詳細に説明すれば、次の通りである。[電子文書流通システムの構造および電子文書流通プロセス]電子文書の流通は、信頼流通のための規格を遵守する企業/機関が直接に互いに電子文書をやりとりするP2P通信を基本とする。このようなP2P通信を遂行するための本発明による電子文書流通システムの基本要素は、アドレス情報を管理しているアドレスディレクトリサーバと各送受信個体間の流通ができるように支援する標準規格基盤の流通メッセージングサーバシステムである。このようなアドレスディレクトリサーバと流通メッセージングサーバシステムさえあれば、企業や機関が電子文書を流通できる基本構造は備えた状態であり、これに送受信者間の文書流通を証明するために流通証明書を発給すると同時に、これを第3者保管機関公電所;公認電子文書保管所に保管することにより、流通に対する法的根拠を確保することができる。本発明による電子文書流通システムは、前記基本要素の他にも、一般ユーザ企業/機関、個人が容易に電子文書を流通できるようにするためには、文書送受信機能に対するユーザインターフェースを提供する流通クライアントアプリケーションAPP、文書作成の便宜性を向上させるために標準文書様式を提供する電子文書の書式登録機、行政機関と電子文書を中継するための公共部門連係ゲートウェイなどが追加構成要素として備えられる。前記のような電子文書流通システムにおいて発生する基本的なプロセスは下記の表140の通りである。[電子文書流通システムの各構成要素]電子文書流通システムを構成する要素をより体系的に説明すれば、次の通りである。電子文書流通が行われるためには先ず流通の主体となる1送受信個体が存在するべきであり、各送受信個体は文書を流通するために流通メッセージングサーバ規格を遵守する2流通メッセージングサーバシステムを保有するべきである。また、電子文書流通の基本構成要素として、各送受信個体およびユーザの公認電子アドレスを登録、管理する3アドレスディレクトリサーバが存在するべきである。このような基本構成要素に基づいてユーザに流通便宜性を提供するために4流通クライアントAPPが提供されるべきであり、行政/公共機関の連係を支援する5公共部門連係ゲートウェイと文書の書式を管理する6電子文書の書式登録機が付加的に提供されるべきである。前記のような各構成要素に対して順に詳細に説明すれば、次の通りである。1送受信個体電子文書流通の基盤インフラ構成要素中、流通の基準となる単位が送受信個体であるが、送受信個体は流通に参加する役割に応じて送信者Senderまたは受信者Receiverを共に遂行するようになり、この個体は流通メッセージングサーバシステムを介して流通プロトコル規格に応じて文書情報を流通する。流通に参加する全ての送受信個体は、流通メッセージング規格に応じて文書を送受信できる流通メッセージングサーバシステムを構築した後、流通メッセージングサーバシステムの物理アドレス情報をアドレスディレクトリサーバに登録することにより、電子文書流通に参加できる基盤を作ることになる。この時、各送受信個体は、下位に1つ以上の公認電子アドレスを有する実の流通ユーザを有するようになる。電子文書流通において、送受信個体として認められる個体は、メッセージングサーバ規格を遵守したシステムを構築した後、情報通信産業振興院によって標準適合性と相互運用性の認証を受けた個体に限定され、流通を証明するためには、1認証を受けた送受信個体を介して電子文書が流通された後、2標準規格に合わせて流通証明書を発給して第3者保管機関に保管するべきである。この時、送受信個体は、電子文書に対する法的所有者および責任者として直接電子文書転送の責任を負う個体と、流通される電子文書の実所有者であり、責任者であるユーザのために電子文書を代行する個体に区分される。電子文書の所有者が直接電子文書を転送する送受信個体である場合には、流通メッセージングサーバシステムの標準適合性と相互運用性の認証を受け、流通証明書を安全に第3者保管機関に保管することだけでも送受信個体に参加することができる。しかし、電子文書所有者ユーザを代行して3者転送の責任を負わなければならない送受信個体である場合には、送受信個体が安全で信頼性のある方法で転送メッセージを管理し、ユーザ情報を管理し認証するかに対する部分まで立証しなければならない。3者流通の安全性および信頼性を保障するために、一時的にこのような3者流通が可能な送受信個体としては第3者保管機関事業者のみに限定する。2流通メッセージングサーバシステム流通メッセージングサーバシステムは、流通メッセージングサーバ規格に基づいて電子文書情報を流通するために、メッセージの送受信機能とアドレスディレクトリサーバと連係して受信者に対するアドレス情報および保安関連情報を検索する機能を必ず構築するべきである。流通メッセージングサーバシステムは、物理的に1つの電子アドレスIPAddressを有するが、下位のユーザのために複数のユーザアカウントを発給し管理することができ、ユーザアカウントは各々1つの公認電子アドレスを有するようになる。流通メッセージングサーバシステムは、各ユーザアカウントを管理するためにユーザアカウント別に電子文書の私書箱を管理するべきであり、流通メッセージングサーバシステムは、このユーザアカウントを代表して安全で信頼性のある電子文書流通の責任を持つようになる。このような流通メッセージングサーバシステムが電子文書流通内に送受信個体として参加するためには、本発明による要件に好適に実現されているのか、他のソリューションとの相互運用に問題がないのかの認証を受ける過程を経なければならない。流通メッセージングサーバシステムに対する標準適合性および相互運用性を認証する認証システムは、認証された送受信個体を管理するべきであり、アドレスディレクトリサーバが公認電子アドレスを登録する過程で認証通過有無の確認を要請すれば、その結果を返すべきである。流通メッセージングサーバシステムが認証を受けて公認電子アドレスとして登録をするためには、図82および下記のような手続きに従わなければならない。先ず、送受信個体になろうとする企業/機関または個人ユーザは、本技術規格に合わせて流通メッセージングサーバシステムを構築する。次に、認証テストベッドが提供する自動化された検証ツールを通じて構築された流通メッセージングサーバシステムの標準適合性および相互運用性を検証する。次に、自体検証を全て完了した送受信個体は、認証テストベッドに認証試験を要請する。次に、認証テストベッドのテスト手続きに応じてシステムに対する認証を終えた後、結果が通過となれば、送受信個体は、公認電子アドレス登録のための次の手続きを準備する。次に、認証テストベッドは、認証審査を通過した送受信個体に対する情報をアドレスディレクトリサーバに伝達し、アドレスディレクトリサーバは、この情報をアドレス登録の条件として活用する。次に、送受信個体は、認証通過した流通メッセージングサーバシステムを登録するために、アドレスディレクトリサーバに固有のID発給を申請する。次に、流通メッセージングサーバシステムがアドレスディレクトリサーバに登録が完了すれば、流通メッセージングサーバシステムは、電子文書流通に参加できるようになる。次に、流通メッセージングサーバシステムの認証が完了すれば、ユーザアカウントを開設し、代表公認電子アドレスである場合に、ユーザアカウントは公認電子アドレスに登録要請をする。3アドレスディレクトリサーバ信頼できる電子文書流通に参加するために、全てのユーザは固有の電子アドレスの発給を受けるべきである。4流通クライアントAPP流通クライアントAPPは、文書流通に参加するユーザたちのために、文書送信および受信、受信文書の閲覧および管理などのUIを提供するアプリケーションを指し示す。流通クライアントAPPは、独自に文書を送受信することはできず、必ず流通メッセージングサーバシステムと連係しなければならない。流通クライアントAPPにおいて作成されたり添付されたりした文書は、流通メッセージングサーバシステムに伝達されて転送を要請するようになり、流通メッセージングサーバシステムを介して受信された文書を照会するようになる。流通メッセージングサーバシステムがユーザアカウントを通じて送受信の私書箱を管理する場合であれば、流通クライアントAPPは、受信文書中のユーザアカウント情報の確認を通じて該当文書にのみアクセスが可能である。流通クライアントAPPは、ユーザの要求によってC/S形態のアプリケーションに実現することもでき、ウェブ形態の画面に実現することもできる。5公共部門連係ゲートウェイ電子文書流通を収容し難い行政および公共機関の場合、公共部門連係ゲートウェイを介して行政、公共機関と電子文書の流通体系下の民間企業、機関、個人間の文書を中継する役割を遂行する。6電子文書の書式登録機電子文書の書式登録機は、流通メッセージングサーバシステムを利用して電子文書を転送しようとするユーザがOfficeツールを利用して直接転送文書を作成することもできるが、ユーザがより容易に電子文書を生成できるように支援するために、標準文書様式を登録し管理しつつ、流通クライアントAPPのようなユーザ用アプリケーションが利用できるように文書様式の登録および管理、文書様式の検索、閲覧、およびダウンロード、文書様式の削除などの管理を支援するシステムである。電子文書の書式登録機は、文書標準様式を管理するサーバエンジンとクライアントアプリケーションAPPがこれを検索し、ダウンロードした後に内部プログラムにプラグインPlug-Inして使えるようにする標準インターフェースを提供する。[電子文書流通方法]電子文書流通において電子文書を流通するための全体プロセスは、1流通前の事前準備ステップ、2電子文書の流通ステップ、3流通のための証明ステップの3ステップに大きく区分して見ることができる。以下では、前記3ステップに対する詳細な説明と共に、文書送受信方案と流通証明方案とスパムメッセージ処理方案について詳細に説明する。1流通前の事前準備ステップ-電子文書の書式登録機の管理者は、電子文書の書式登録機を利用して、使用する標準文書の書式を登録する。-送受信参加者は、自体的に信頼流通のための流通メッセージングサーバシステムを構築するか、既に構築された流通メッセージングサーバシステムにユーザアカウントを開設して使用するかを決定する。自体的に信頼流通のための流通メッセージングサーバシステムを構築する場合には、電子文書の送受信のための流通メッセージングサーバシステムを構築した後、認証機関を介して流通メッセージングサーバシステムの標準適合性、相互運用性に対する認証テストを遂行した後、アドレスディレクトリサーバに接続した後、認証された流通メッセージングサーバシステムのための送受信個体IDを申請し発給を受けた後、内部の実ユーザのために自体的に内部区分子を登録して管理し、標準文書の書式基盤の文書作成機能を利用するために一般ユーザのためのクライアントアプリケーションに標準文書の書式作成機能をプラグインPlug-Inする選択的事項。これに対し、3者流通が可能な流通メッセージングサーバシステムを保有した送受信個体を利用する場合には、流通メッセージングサーバシステムを介して企業/機関/個人のためのユーザアカウント開設を要請した後、ユーザアカウントに対する公認電子アドレス情報をアドレスディレクトリサーバに登録した後、標準文書の書式基盤の文書作成機能を利用するために一般ユーザのためのクライアントアプリケーションに標準文書様式の作成機能をプラグインPlug-Inする選択的事項。2電子文書の流通ステップ○文書送信者-文書送信者は、流通する文書を選択するか、文書作成機を通じて転送する文書を作成する。-文書受信相手方のアドレス情報および伝達文書、文書暗号化の有無および電子署名の有無を選択する暗号化および電子署名は、転送メッセージではない、添付する伝達文書を対象にし、この手続きは選択的事項である。-流通クライアントAPPは、アドレスディレクトリサーバに連係して受信相手方の公認電子アドレスを基盤に物理アドレス情報および暗号化のための公開キー情報を獲得する選択的事項であり、流通クライアントAPPが物理アドレスを獲得しない場合、流通メッセージングサーバがこの作業を遂行する。-流通クライアントAPPは、流通メッセージングサーバに受信者のアドレス情報を基盤に転送要請をする物理アドレス情報または公認電子アドレスの両方とも可能。○送信者の流通メッセージングサーバ-流通クライアントAPPから要請した転送要請メッセージが受信者に対する物理アドレス情報ではない場合、流通メッセージングサーバは、公認電子アドレスを基盤に受信者の送受信個体に対する物理アドレス情報をアドレスディレクトリサーバに問い合わせる。-電子文書を流通プロトコル規格で定義されたメッセージ構造体にパッケージングする。-送信者の流通メッセージングサーバの公認認証書を基盤にメッセージに電子署名をする。-受信者の物理アドレス情報にメッセージを転送する。○受信者の流通メッセージングサーバ-メッセージ受信後、受信メッセージ検証し、メッセージから文書を抽出する。-同期式応答で受信証明書を含むメッセージを送信者に転送する。3流通のための証明ステップ-受信者は、文書受信事実の確認のために文書受信時点で受信証明書を生成した後に送信者に伝達するべきであり、これを受信した文書送信者は、受信証明書を第3者保管機関に保管する。-送信者が要求する場合、受信者は、受信文書を実文書担当者ユーザに伝達した後、担当者が受信文書を確認した時点で閲覧証明書を生成して送信者に伝達し、閲覧証明書を受信した文書送信者は閲覧証明書を第3者保管機関に保管する閲覧証明書の発給は送信者の要請がある場合にのみ適用される。-送信者が受信者に文書伝達を試みたものの、失敗した場合には、送信試みに対して証明するために客観的3者である電子文書流通ハブに文書転送を依頼し、転送依頼を受けた電子文書流通ハブは、転送依頼を受けたことを立証するために送信証明書を発給して送信依頼者に伝達し、これを受信した送信依頼者は、送信証明書を第3者保管機関に保管する。○文書送受信方案流通メッセージングサーバシステムを介して送信者と受信者は文書を電子的に流通する。流通メッセージングサーバシステムは流通プロトコルに応じて電子文書を送受信し、信頼メッセージ流通のために全てのメッセージは転送と受信確認または受信証明書メッセージの組み合わせからなり、受信者に対する物理アドレス情報はアドレスディレクトリサーバを介して獲得するようになる。○流通証明方案流通証明とは電子文書流通と関連した送信、受信、閲覧に対して該当事実を信頼性のある方法で証明することをいい、この時、電子文書流通と関連した行為に対して発給する証明書を通称して流通証明書という。流通メッセージングサーバシステムは、送信、受信に対する行為立証のために送信および受信時点で流通証明書を発給し、発給した流通証明書を公認電子文書第3者保管機関に保管することにより、流通行為に対する証明資料として活用できるようにする。流通メッセージングサーバシステムは、電子文書の送信、受信、閲覧に対する事実を証明し、各事実に対する流通証明書を生成し、流通証明書は、流通証明書の識別情報、流通証明書の生成時刻および満了時刻、流通証明書政策および流通証明対象を含む。電子文書送信に対する流通証明書は、電子文書流通ハブが生成し、流通証明対象に発信者の識別情報、受信者の識別情報、流通識別情報、文書識別情報、電子文書の送信依頼時刻を含む。電子文書受信に対する流通証明書は、電子文書を受信した受信者が生成し、流通証明対象に発信者の識別情報、受信者の識別情報、流通識別情報、文書識別情報、電子文書の送信時刻、電子文書の受信時刻を含む。電子文書閲覧に対する流通証明書は、電子文書を受信確認したユーザが生成し、流通証明対象に発信者の識別情報、受信者の識別情報、流通識別情報、文書識別情報、電子文書の送信時刻、電子文書の受信時刻、電子文書の受信確認時刻を含むべきである。このように生成された流通証明書はNPKIまたはGPKI認証書で電子署名されるべきであり、生成された流通証明書は電子文書送信者に伝達されるべきであり、全ての流通証明書は第3者保管機関に保管されることが好ましい。○スパムメッセージの処理方案電子文書流通は、基本的に送信者が認証された流通メッセージングサーバシステムを介して転送をし、受信者もこれを基本に受信するため、スパムを発送した時に転送者に責任を問える基盤構造を有する。しかし、スパム発送者が流通メッセージングサーバシステムにユーザアカウントを開設し、これを利用して転送する場合があり得る。また、現在の認証方式がシステムの技術的内容に対する認証のみを対象にしており、スパム発送者が流通メッセージングサーバシステムを構築し、これを技術的に認証した後にスパム発送手段として使用した時には、初期に根本的に遮断するのが容易ではない状況である。したがって、このような問題点を解決するために、本発明による標準文書流通のインフラにおいては、認証目録管理基盤のホワイトリスト、ユーザの申告方式によるスパム対象目録管理基盤のブラックリストの体系を提供し、このような体系によって受信者が受信拒否できるプロセスを適用してスパムメッセージを防止できるようにする。スパムメッセージの申告および送信相手方に対する確認のための機能は必須機能であり、全ての流通メッセージングサーバはこの機能を必ず構築しなければならない。受信者は、受信したメッセージがスパムメッセージであると判断されれば、図83に示すようなプロセスによってスパムメッセージを電子文書流通ハブのアドレスディレクトリサーバに申告し、これと関連した処理手続きは次の通りである。先ず、受信者がメッセージを受信した時点でスパムメッセージであると判断すれば、受信者は、流通メッセージングサーバシステムを介してアドレスディレクトリサーバに該当メッセージを受信メッセージとして申告する。次に、流通メッセージングサーバシステムからスパムメッセージの申告を受け付けしたアドレスディレクトリサーバは、受付済みの確認メッセージを返す。次に、アドレスディレクトリサーバを管理する主体である情報通信産業振興院は、該当メッセージを分析し、送信者に対する調査を通じ、送信者の公認電子アドレスに対してブラックリストに追加するか否かを審査し判断する。次に、最終的にブラックリスト対象者に確定されれば、アドレスディレクトリサーバは、該当公認電子アドレスをブラックリストに追加した後、送信者にブラックリスト追加に対する内容を通知する。次に、アドレスディレクトリサーバは、スパムメッセージ要請に対する処理結果をスパム申告者受信者に伝達する。前記のような処理手続きにおいて、ホワイトリストは、送信流通メッセージングサーバシステムが認証を受けて正式に登録されたメッセージングサーバシステムに対する情報のみが記録され、ブラックリストは、転送者のアドレスがスパム発送者として登録された場合に登録され、同一の流通メッセージングサーバシステムを介してブラックリストに登録されるスパムアドレスが重複発生する場合には、電子文書流通ハブにおいて該当流通メッセージングサーバシステムに対する認証取り消し有無を判断した後、認証を取り消し、ホワイトリストから削除することができる。受信者は、メッセージ受信時、送信相手方が信頼できるほどの正当なユーザであるかを確認するためにアドレスディレクトリサーバのホワイトリストとブラックリストを確認した後、受信拒否をするか否かを決定する。送信者に対する確認は、受信時点でリアルタイムで確認をするか、受信者の流通メッセージングサーバシステムにCache形態で管理している目録を通じて確認する周期的な確認方法がある。リアルタイムで送信者に対する確認を遂行するプロセスは、図84に示すように、受信者がメッセージを受信する時点でアドレスディレクトリサーバに送信者のアドレスがホワイトリスト、ブラックリストに登録されたか否かを判断した後にメッセージに対する受信拒否の可否を決定し、このようにリアルタイムで送信者に対する確認を遂行するプロセスの詳細な処理手続きは次の通りである。先ず、受信者の流通メッセージングサーバシステムは、メッセージを受信すれば、アドレスディレクトリサーバに正当なユーザであるかを確認するために確認要請メッセージを伝達する。次に、アドレスディレクトリサーバは、要請を受けたユーザのアドレス情報がホワイトリストに含まれているか否かを確認する。次に、該当アドレスがホワイトリストになければ、アドレスディレクトリサーバは、直ちに確認要請者に登録されていないユーザであることを結果メッセージとして返し、ホワイトリストにあれば、再び該当アドレスがブラックリストに登録されたアドレスであるか否かを確認する。次に、アドレスディレクトリサーバは、確認要請者にブラックリストへの登録有無に対する結果メッセージを返す。次に、受信者は、アドレスディレクトリサーバから送信者が正当なユーザではないというホワイトリストにないか、ブラックリストに登録された場合結果メッセージを受けた場合には、受信メッセージを自体的にスパムメッセージとして処理した後、アドレスディレクトリサーバから受けた処理結果メッセージとスパムメッセージの受信履歴を記録し保管する。次に、スパムメッセージに対する処理履歴は必ず1ヶ月以上保管することにより、該当送信者に対する受信拒否の正当性を確認できるようにする。そして、周期的に送信者に対する確認を遂行するプロセスは、図85に示すように、受信者は事前にアドレスディレクトリサーバからホワイトリストとブラックリストをもらって自体的に管理し、これを基盤に送信者のアドレスがホワイトリスト、ブラックリストに登録されたか否かを判断した後にメッセージに対する受信拒否の可否を決定し、このように周期的に送信者に対する確認を遂行するプロセスの詳細な処理手続きは次の通りである。先ず、受信者の流通メッセージングサーバシステムは、予めアドレスディレクトリサーバから最新のホワイトリストとブラックリストを要請した後に自体的に管理する。この時、リストの変動事項の発生時、自動通知の要請有無を共に伝達する。このような変動事項発生の自動通知を要請した場合にも、アドレスディレクトリサーバに最新リストを持ってくるための要請を周期的に行うことにより、リスト情報が最大限1日以上の差が生じないようにする。次に、アドレスディレクトリサーバは、ホワイトリストおよびブラックリストに変動事項が発生すれば、変動通知の要請をしたユーザに変動内訳をブロードキャスティングbroadcastingする。次に、リストに対する変動事項を受けたユーザ流通メッセージングサーバシステムは、自体管理するリスト情報を修正することによって同期化させる。次に、受信者は、メッセージを受信すれば、アドレスディレクトリサーバに正当なユーザであるか否かを確認するために、自体管理するリストを確認する。次に、受信者は、自体管理するリストをチェックした結果、送信者が正当なユーザではないとホワイトリストにないか、ブラックリストに登録された場合判断した場合には、受信メッセージを自体的にスパムメッセージとして処理した後、スパムメッセージの受信履歴を記録し保管する。次に、スパムメッセージに対する処理履歴は必ず1ヶ月以上保管することにより、該当送信者に対する受信拒否の正当性を確認できるようにする。[流通メッセージングサーバシステム]以下では、上述したような本発明の好ましい実施形態による電子文書流通システムの流通メッセージングサーバシステムと関連して詳細に説明する。流通メッセージングサーバシステムは、大きく、メッセージ送信、メッセージ受信、受信メッセージに対する私書箱管理、メッセージ保安ユーザ認証、文書の暗号/復号化など、送受信履歴の管理、アドレスディレクトリサーバ連係、メッセージ検証、内部システム連係インターフェース、流通証明書の発給および管理、第3者保管機関連係などで構成される。図86は流通メッセージングサーバシステムの構造を示し、このような図86を参照し、流通メッセージングサーバシステムの構成要素の各々1~9について詳細に説明すれば、次の通りである。1メッセージ送受信-流通プロトコルに応じてメッセージを送信し受信する。2ユーザ別のアカウント私書箱管理-送受信したメッセージをユーザアカウントまたは内部区分子に応じてアカウント別の私書箱に保管する。-私書箱に保管した送信文書に対し、送信中、送信完了、送信失敗、担当者の受信完了を含む4ステップの状態情報を管理する。この時、送信中の状態は文書転送後に受信者から何の応答を受けていない状態であり、送信完了の状態は受信者の流通メッセージングサーバシステムから受信証明書を受けた状態であり、送信失敗の状態は受信流通メッセージングサーバシステム内部においてエラーが発生してSOAPFaultメッセージをリターンするか、送受信過程でネットワークエラーが発生した場合であり、担当者の受信完了の状態は送信流通メッセージングサーバシステムが受信者から担当者の文書を確認したことを証明する閲覧証明書を受けた場合である。-ユーザアカウント別の私書箱に保管された受信文書に対し、検証エラー、受信確認前、受信確認、閲覧確認を含む4ステップの状態情報を管理する。この時、検証エラーの状態は受信したメッセージに対する基本構造の検証においてエラーが発生した状態であり、受信確認前の状態は受信文書担当者が私書箱の受信文書目録を読む前であり、受信確認の状態は受信文書担当者が私書箱の受信文書目録を読んだ状態であり、閲覧確認の状態は受信文書担当者が受信文書に対する詳細内容を閲覧した状態であって、この時点で受信者の流通メッセージングサーバシステムは閲覧証明書を発給した後に送信者に伝達する。-受信ユーザによって削除要請が届くと、該当受信文書を物理的に削除処理する。-私書箱において、送信文書、送信に対する受信確認メッセージ、受信担当者の受信確認メッセージは互いに連関されるように連関情報を有する。3アドレスディレクトリサーバ連係-アドレスディレクトリサーバが提供するアドレス情報の登録および検索プロセスに応じてアドレス情報を管理する。-アドレスディレクトリサーバが提供するサービスを呼び出しできるクライアント機能を含む。すなわち、アドレスディレクトリサーバが提供するアドレス情報の登録、検索、修正、削除機能を遠隔から呼び出すサービスクライアント機能を提供する。4メッセージ保安ユーザ認証、文書の暗号/復号化など-流通プロトコルにおいて提示するメッセージ保安機能メッセージの電子署名、署名検証を基本的に遂行する。5送受信履歴の管理-流通メッセージングサーバシステムは、送受信履歴に対して最小1年以上は必ず保管/管理する。-保管する送受信履歴に対する情報は送信履歴と受信履歴であり、送信履歴はメッセージid、連関メッセージid、送信者ユーザアカウント含む、受信者、送信時間、送信文書に対するハッシュ値を含み、受信履歴は送信者、受信者ユーザアカウント含む、受信時間、受信文書に対するハッシュ値を含む。6流通証明書の発給および管理-流通メッセージングサーバシステムは、文書の送受信事実に対する内容を証明できるように流通証明書を発給し管理する。-発給された流通証明書は、伝達を受けた後、直ちに第3者保管機関に保管依頼することによってその信頼性が保証される。-発給された後に第3者保管機関に保管された流通証明書の履歴を管理し、流通証明書の発給履歴は、流通証明書id、流通証明書の発給時刻、連関メッセージid、流通証明書原本選択的、第3者保管機関の保管後に受信した保管-key情報を含む。7メッセージのパッケージ処理Packaging、Parsing、Extracting-送信文書を転送前に流通プロトコルで定義されたメッセージ構造にパッケージングPackagingする。-受信した文書を流通プロトコルで定義されたメッセージ構造によってパーシングParsing、構文解釈し、必要な情報を抽出Extractingする。8流通証明書の保管要請-一般送受信個体が流通証明書を保管要請するためには、第3者保管機関の流通メッセージングサーバシステムに第3者保管機関への保管要請メッセージを転送する遠隔保管要請。-第3者保管機関の流通メッセージングサーバシステムは、公認電子文書保管所の保管要請メッセージを受信すれば、第3者保管機関に流通証明書保管のための保管要請Clientを呼び出す。-第3者保管機関の流通メッセージングサーバシステムが直接流通証明書を生成した場合には、生成時点で第3者保管機関への保管要請Clientを直接呼び出すローカル保管要請。-流通証明書の保管要請のためのClientは、第3者保管機関の送受信連係インターフェース規格に応じて第3者保管機関に保管を要請する。9付加サービス-流通クライアントAPP管理の配布、バージョン管理などを遂行する。-メッセージ流通管理履歴、統計情報などを遂行する。-システム管理システムモニタリング、環境情報などを遂行する。-文書様式Formの管理を遂行する。前記のような1~9の構成要素を有する本発明による流通メッセージングサーバシステムを図87のように第3者保管機関に適用した場合には、流通証明書を保管する時に流通証明書の保管要請モジュールは、第3者保管機関連係インターフェースの規格に応じて開発された連係インターフェースクライアントを呼び出して保管要請をする。前記のような1~9の構成要素を有する本発明による流通メッセージングサーバシステムを図88のように一般送受信個体一般事業者に適用した場合には、流通証明書を保管する時に第3者保管機関事業者の流通メッセージングサーバシステムに流通証明書の保管を要請するメッセージを転送し、処理結果を受ける方式で処理する。前記のような1~9の構成要素を有する本発明による流通メッセージングサーバシステムを利用して送信者と受信者間に直接メッセージを流通するプロセスは、1受信者に対する物理アドレスおよび保安情報の獲得、2メッセージ転送および転送確認、3業務受信者の受信確認、4流通証明書の発給および保管を含む4ステップからなり、このような4ステップと関連し、図89を参照して詳細に説明すれば、次の通りである。1受信者に対する物理アドレスおよび保安情報の獲得-送信者のシステムは、相手方に対するアドレス情報に基づいて実際メッセージが伝達されるべき物理アドレス情報および保安情報送信メッセージに対する受信暗号を必要とする場合をアドレスディレクトリサーバに要請することによってこれを獲得する。-受信者に対する物理アドレスおよび保安情報は、流通クライアントAPPがアドレスディレクトリサーバに要請した後に、受信者の物理アドレス情報を流通メッセージングサーバに伝達するようにする。-ユーザに対するid例:住民登録番号、事業者登録番号などだけで受信者に対するアドレス情報を獲得することもできるが、この場合には、受信者が送信者にid基盤のアドレス情報検索を許容した場合にのみ可能である。送信者が受信者の物理アドレス情報および保安情報を既に知っている場合には、この手続きは省略可能である。2メッセージ転送および転送確認-送信者は、メッセージを流通プロトコル規格に合わせてパッケージングした後、流通メッセージングサーバシステムの公認認証書を基盤に電子署名を遂行する。-流通メッセージングサーバシステムは、先に獲得した物理アドレスにパッケージングし電子署名されたメッセージを転送する。-メッセージを受信した受信流通メッセージングサーバシステムは、メッセージの基本パッケージング構造、電子署名に対する有効性、送信者に対する適合性検証に対する詳細内容は2.4.6メッセージ検証部分を参照を検証した後、受信確認のための受信証明書またはエラーメッセージを生成する。-受信流通メッセージングサーバシステムは、生成した応答メッセージを送信者に転送する。-転送と転送確認の過程は同期式メッセージ処理でなされる。3業務受信者の受信確認-送信者がメッセージ転送時点で業務受信者の担当者の閲覧確認メッセージを要請した場合には、受信者は、メッセージに対する業務的な受信確認時点で送信者に必ず担当者の閲覧確認を証明できる閲覧証明書を生成し、これを転送しなければならない。-受信者がメッセージ送信者に担当者の閲覧確認のための閲覧証明書メッセージを送れば、元のメッセージ送信者にこれに対する受信確認メッセージを同期式で送る。4流通証明書の発給および保管-各ステップ別に流通に対する証明を受けようとする場合、送信者は各ステップに応じて受信、閲覧、送信に対する証明書を発給し、これを第3者保管機関に保管することによって流通に対する法的証明の根拠を確保する。本発明による流通メッセージングサーバシステムを利用して送信者と受信者間に直接メッセージを流通するプロセスは、前記のような1受信者に対する物理アドレスおよび保安情報の獲得、2メッセージ転送および転送確認、3業務受信者の受信確認、4流通証明書の発給および保管の他に5エラー処理も遂行するが、図90~図92を参照し、エラー処理機能と関連して詳細に説明すれば、次の通りである。5エラー処理機能流通メッセージングサーバシステムの全てのメッセージ送受信プロセスは同期式処理を基本とする。したがって、転送に対する全てのエラーは転送者が確認可能であるので再転送することを基本とし、同一のメッセージ転送は同一のMessageId値を設定して再び送ることにより、受信者が受信成功後に受信確認メッセージの転送過程でのエラーに対しても重複メッセージ受信を検知できるようにする。流通メッセージングサーバシステムは、要請メッセージの送信に失敗した場合に、図90のような処理フローチャートに従う。すなわち、メッセージ送信者が転送する過程でネットワークエラーなどによって転送エラーが発生した場合に、送信者は、HTTPエラーのようなエラーメッセージを受けると、同一のメッセージを再び再転送するように要請し、送信者は、受信者に受信確認メッセージを受けた場合にのみ転送成功として認識する。流通メッセージングサーバシステムは、応答メッセージの受信に失敗した場合に、図91のような処理フローチャートに従う。すなわち、メッセージが受信者に正常に伝達されたものの、送信者が受信者から受信確認メッセージを受けていない場合に、送信者は、送信失敗エラーとして認識し、受信者に同一のメッセージを同一のMessageIdに再転送するようになり、受信者は、受信した文書のMessageIdが以前の受信メッセージと同一である場合には、重複受信として受信確認メッセージを送った後に内部処理をする。流通メッセージングサーバシステムは、エラーメッセージの受信に失敗した場合に、図92のような処理フローチャートに従う。すなわち、送信者が受信者に転送したメッセージが正確に伝達されたものの、転送メッセージそのものに誤りがあってエラーメッセージの応答を受けた場合に、送信者はエラー類型に応じてメッセージ処理を異にし、再要請時に転送するメッセージのMessageIdは同一である必要はなく、業務状況に応じて異に処理することができる。上述したような本発明による流通メッセージングサーバシステムにおいて必須に要求される機能である、1メッセージ送受信、2受信メッセージ私書箱の管理、3メッセージ保安、4送受信履歴の管理、5アドレスディレクトリサーバ連係、6メッセージ検証、7内部システム連係インターフェース、8流通証明書の発給および管理機能について詳細に説明すれば、次の通りである。1メッセージ送受信流通メッセージングサーバシステムがメッセージを送受信する基本プロセスは、上述した本発明による[電子文書流通方法]の文書送受信方案を従う。メッセージ送受信のための基本となるメッセージ交換類型はメッセージ流通プロトコルの同期式応答を基本とし、送信メッセージと受信確認メッセージ、送信メッセージと受信エラーメッセージ、送信メッセージとビジネス的な応答メッセージ受信確認メッセージの意味を含むの構成からなってもよい。メッセージ送受信の類型としては、送信と受信確認応答メッセージの組み合わせと、送信とビジニーズ応答メッセージの組み合わせを含む2つの類型がある。メッセージ送受信の類型が送信と受信確認応答メッセージの組み合わせである場合の処理流れは図93の通りであり、送信メッセージと受信確認または受信エラーメッセージはSOAPSimpleObjectAccessProtocolRequest-Responseの組み合わせからなり、送信メッセージとそれに対する応答メッセージは送信メッセージのMessageIdを応答メッセージのRefToMessageIdに入れて送ることによって連関関係を持つようにするが、これと関連した詳細な説明は後述する[流通プロトコル]を参照する。メッセージ送受信の類型が送信とビジネス応答メッセージの組み合わせである場合の処理流れは図94の通りであり、送信メッセージと受信確認または受信エラーメッセージを含む応答メッセージはSOAPRequest-Responseの組み合わせからなり、受信者がメッセージを受信した後、内部システムにリアルタイムで連係してビジネス処理した応答文書を生成した後、応答文書と受信確認ACKメッセージを共に応答メッセージにのせて送信者に伝達し、送信メッセージとそれに対する応答メッセージは送信メッセージのMessageIdを応答メッセージのRefToMessageIdに入れて送ることによって連関関係を持つようにするが、これと関連した詳細な説明は後述する[流通プロトコル]を参照する。送受信されるメッセージの構造は図95に示すようにMultiPart-MIME構造を有し、1番目のMIME部分にはSOAPメッセージが、2番目のMIMEからは転送しようとする文書が入る。1番目のMIMEにはSOAPヘッダとSOAPBodyとから構成されたSOAPEnvelopeが入り、SOAPヘッダはメッセージ送受信のためのメッセージヘッダ情報、電子署名、受信確認メッセージ、同期式の転送表示、エラーメッセージなどが入る。そして、2番目のMIMEにはメッセージ受信者に伝達する文書情報が入り、担当者の受信確認メッセージを伝達する場合にこの位置に入る。そして、3番目のMIMEは、メッセージ受信者に伝達する文書情報が2つ以上である場合、3番目のMIMEから順次入る。2受信メッセージ私書箱の管理流通メッセージングサーバシステムは、メッセージを受信すれば、受信メッセージをアカウント別に私書箱に格納する。受信メッセージ私書箱は1つ以上のユーザアカウント別に区分されてメッセージを格納管理し、ユーザの要請新しい受信メッセージの存在有無、受信メッセージの閲覧、受信メッセージのダウンロード、受信メッセージの削除などに応じて必要な処理後、結果を返すインターフェースを必ず標準化された方式で提供しなければならない。流通メッセージングサーバシステムが管理するユーザアカウントが電子文書流通に含まれる公認電子アドレスとして資格を持つためには、流通メッセージングサーバシステムは、信頼ユーザアカウントを持つための認証要件今後、別途の評価指針によって要件を定義することであり、現時点では第3者保管機関のみがこの認証要件を充足したものとして認めるを通過しなければならない。したがって、個人または企業機関が電子文書流通において公認電子アドレスを獲得するための方案としては次のような2つの方案がある。第1方案は、自体的に流通メッセージングサーバシステムを構築し、認証を受けた後に獲得した送受信個体IDをアドレスディレクトリサーバに登録することであり、第2方案は、認証を受けた流通メッセージングサーバシステム中、信頼ユーザアカウントを有する要件を追加的に充足した送受信個体に私書箱を開設して、ユーザIDの発給を受けた後、これをアドレスディレクトリサーバに登録することである。3メッセージ保安転送メッセージに対する保安は、無欠性保障のための電子署名と機密性保障のための暗号/復号化に分けられる。流通メッセージングサーバシステムを介して転送されるメッセージはSOAPメッセージと添付文書に分けられる。この時、添付文書は流通クライアントAPPにおいて既に暗号化されている状態であり、SOAPEnvelopeには単にメッセージ送受信のためのヘッダ情報だけが含まれるので、流通メッセージングサーバシステムにおいては、追加的な暗号化過程を経ず、メッセージの送受信過程で偽変造防止のための電子署名過程は遂行する。電子署名方式および細部手続きは後述する[流通プロトコル]を参照する。4送受信履歴の管理流通メッセージングサーバシステムは、今後、送受信に関連した紛争が発生したり問題が提起されたりする時、これを確認するために送受信に対する履歴情報を管理しなければならない。履歴情報は、送受信行為に対する情報だけでなく、実際に送受信した文書に対する情報も管理するべきであるが、実文書を第3者保管機関に保管した場合には、文書の原本ではない第3者保管機関から受けた登録証明書のみを保管することも可能である。5アドレスディレクトリサーバ連係流通メッセージングサーバシステムは、アドレスディレクトリサーバが提供するサービス連係インターフェースを使って、アドレスディレクトリサーバと連係をする。アドレスディレクトリサーバは、2種類のアドレス検索サービスとアドレス登録サービス、アドレス変更サービスを提供するが、流通メッセージングサーバシステムは、アドレス検索サービス中、公認電子アドレスに対する物理アドレス検索サービスの連係機能は必須に提供する。検索サービスの他にアドレス登録およびアドレス変更サービスは、流通メッセージングサーバシステムが下位に登録/管理するユーザアカウントを企業や個人の公認電子アドレスとして使用できるか否かに応じて使用可否が決定される。流通メッセージングサーバシステムが登録/管理するユーザアカウントが公認電子アドレスとして登録可能となるように認証を受けた場合には、公認電子アドレスに対する登録および変更サービスを代行しなければならないので、アドレスディレクトリサーバの該当サービスを連係する。6メッセージ検証-流通メッセージングサーバシステムがメッセージを送受信する時、受信者は、メッセージの受信時点でメッセージの有効性に対する検証を遂行し、図96に示すプロセスのように、受信者は、メッセージの有効性検証をした後、検証に通過した場合にのみメッセージの受信確認メッセージを送信者に伝達し、そうではない場合には、受信メッセージに対するエラーメッセージを転送する。-検証対象:受信メッセージのスキーマ検証受信メッセージが流通プロトコルに応じて正確にパッケージングされたかを検証、メッセージの無欠性検証受信したメッセージの電子署名値を検証することによって、メッセージの偽変造が発生せずに無欠であるかを検証、メッセージ送信者の検証メッセージに電子署名をした送信者がメッセージに表記された送信者と一致するかを認証するために電子署名に使われた認証書とメッセージの送信者が同一であるかを検証7内部システム連係インターフェース流通メッセージングサーバシステムは、内部システムが流通メッセージングサーバシステムを介して文書を転送し受信できるように送受信のための標準化されたインターフェースを提供するべきである。このインターフェースに対する詳細な内容は後述する[流通クライアントAPP]を参照する。8流通証明書の発給および管理流通証明書の基本要件は、1流通証明書は発信および受信流通メッセージングサーバシステムが生成するということと、2流通証明書はGPKIおよびNPKI認証書を基盤に電子署名して生成されるということと、3流通証明書は電子文書の流通行為を基準に生成この時、1回の電子文書の流通時に1つ以上の電子文書が伝達される場合、1つの流通証明書を生成し、1つの電子文書流通のためには必ず該当流通を識別できるIDが付与され、これを基準にした流通で流通証明書を生成するされるということである。流通証明書の発給時点で考慮しなければならない内容は、1流通証明書の一連番号は個別の送受信個体が生成するので、唯一性の付与のために、既存の証明書の規格とは異なって20byte乱数を使用するということと、2流通証明の更新および廃止は定義しないということと、3流通証明書を生成する流通メッセージングサーバシステムおよび流通クライアントAPPのシステム時刻は常に現在時刻を維持しなければならないということと、4流通証明書政策は技術規格で定義されたOIDおよび名称だけを使用するということである。流通証明書の発給プロセスは図97に示す通りであり、流通証明書の類型および生成に必要な必須情報は下記表141の通りであり、流通証明書の必須情報の獲得方法は下記表142の通りである。流通証明書は送受信個体が生成し、送受信個体のNPKIおよびGPKI認証書を利用して電子署名し、流通証明書の基本構造はCMS標準のSignedData構造を使用し、証明書と同一のコンテンツ識別子を使用する。流通証明書のcontentTypeは次の通りである。id-kiec-arcCertReseponseOBJECTIDENTIFIER::={iso1member-body2korea410kiec200032certificate22}ARCCertResponse::=CHOICE{arcCertInfo[0]EXPLICITARCCertInfo,arcErrorNotice[1]EXPLICITARCErrorNotice}流通証明書の基本フィールドは次の通りである。ARCCertInfo::=SEQUENCE{version[0]EXPLICITARCVersionDEFAULTv1,serialNumberSerialNumber,issuerGeneralNames,dateOfIssueGeneralizedTime,dateOfExpireDateOfExpiration,policyARCCertificatePolicies,requestInfoRequestInfo,targetTargetToCertify,extionsions[1]EXPLICITExtensionsOPTIONAL}前記のような流通証明書の基本フィールドについて詳細に説明すれば、次の通りである。1version、バージョン-流通証明書構造のバージョンを示す。流通証明書のためにはv2に設定するべきであり、targetフィールドにdataHashを使う。ARCVersion::=INTEGER{v11,v22}2SerialNumber、一連番号-流通証明書の識別情報を示す。流通証明書は、電子文書を受信した送受信個体が生成するので、一連番号方式の識別番号は意味がない。また、送受信個体の流通クライアントが再設置されるなどの場合には、一連番号の維持が不可能である。したがって、流通証明書の識別情報は20byte乱数を使う。流通証明書を処理するためには20byte乱数を処理できなければならない。SerialNumber::=INTEGER3issuer、証明書の発給者-流通証明書を発給する発給者の認証書識別値を入れる。本フィールドの値は流通証明書を電子署名した署名者の認証書内のSubjectNameフィールドと同一の値を有しなければならない。4dateOfIssue、証明書の発給日-発給者が流通証明書を発給した時点を示す。5dateOfExpire、証明書の効力満期日-流通証明書の満了時点を示す。6policy、証明書政策-流通証明書政策を示す。全ての流通証明書内の政策OIDは証明書の種類に応じて異なり、技術規格において格納した値のみを使用するべきである。-流通証明書は証明書の種類に応じて一括的に1つのOIDを有する。-Qualifier値としてはUserNotice>ExplicitText>DisplyTextにUTF8String形式で表され、指定された文章を使う。-流通証明書の類型に応じて下記表143のような政策情報を使用するべきである。7requestInfo、証明書要請メッセージ情報-本フィールドはnullに設定する。RequestInfo::=CHOICE{arcCertRequestARCCertRequest、nullNULL}8target、証明対象-流通された全体電子文書のハッシュ値を指定する。本フィールドは必ずdistributionInfos方式を使用するべきである。opRecordおよびorgAndIssued、dataHashフィールドに対する構造は、第3者保管機関の証明書フォーマットおよび運用手続き技術規格を参照する。-流通される電子文書に対する情報はDistributionInfosフィールドに含まれる。TargetToCertify::=CHOICE{opRecord[0]EXPLICITOperationRecord,orgAndIssued[1]EXPLICITOriginalAndIssuedDocumentInfo,dataHash[2]EXPLICITHashedDataInfodistributionInfos[10]EXPLICITDistributionInfos}DistributionInfos::=SEQUENCEOFDistributionInfoDistributionInfo::=SEQUENCE{senderAddGeneralNames,receiverAddGeneralNames,dateOfSendGeneralizedTime,dateOfReceive[0]EXPLICITGeneralizedTimeOPTIONAL,dateOfReceiveConfirm[1]EXPLICITGeneralizedTimeOPTIONAL,distributionIdINTEGER,numberOfFilesINTEGER,distributedFileInfosDistributedFileInfos}1-1senderAdd、公認電子アドレス-送信者の公認電子アドレスを示す。1-2receiverAdd、受信者の公認電子アドレス-受信者の公認電子アドレスを示す。1-3dateOfSend、送信日時-送信者が電子文書を発送した時点を示す。-送信証明書の場合、送信者が電子文書流通ハブに送信依頼した時刻を指定する。-送信証明書は本フィールドのみを含むべきであり、dateOfReceiveおよびdateOfReceiveConfirmは含んではいけない。1-4dateOfReceive、受信日時-受信者が電子文書を受信した時点を示す。該当時点は証明書を生成した時点より同じであるか以前であるべきである。受信証明書および閲覧証明書は必ず本フィールドを含むべきである。送信証明書は本フィールドを含んではいけない。1-5dateOfReceiveConfirm、閲覧日時-受信者が電子文書を受信して確認した時点を示す。該当時点は受信日時より同じであるか以後であるべきであり、証明書を生成した時点より同じであるか以前であるべきである。閲覧証明書は必ず本フィールドを含むべきである。送信証明書および受信証明書は必ず本フィールドを含んではいけない。1-6distributionId、流通識別値-電子文書の流通件に対する識別値を示す。本フィールドの生成のために20byte乱数を生成して使う。本フィールド値は、電子文書流通に対して流通メッセージに付与される識別値を意味する。1-7numberOfFiles、流通ファイル個数-流通時に1つ以上の電子文書が伝達されてもよく、本フィールドは1回の流通で伝達されるファイルの個数を示す。1-8distributedFileInfos、流通文書情報-流通時に1つ以上の電子文書が伝達されてもよく、本フィールドには伝達される全ての文書に対する情報が含まれるべきである。DistributedFileInfos::=SEQUENCEOFDistributedFileDistributedFile::=SEQUENCE{fileHashedDataHashedDataInfo、fileId[0]UTF8StringOPTIONAL、fileName[1]UTF8StringOPTIONAL}1-8-1fileHashedData、ファイルハッシュ情報-本フィールドは流通して伝達された電子文書に対するハッシュ値を示す。1-8-2fileId、ファイル識別値-流通される電子文書に識別値を付与した場合に該当文書に対する識別値を指定する。ファイル識別値は送信者が生成し、電子文書を受信者に伝達する時に共に伝達されるべきである。受信者は、伝達を受けたファイル識別値を利用して本フィールドに適用するべきである。-送信者は、本フィールドの生成のためにuuid方式で生成するべきである。-本フィールドは選択的に使われてもよいが、fileNameフィールドを使用しない場合には必ず使われるべきであり、fieldフィールドの使用を勧告する。1-8-3fileName、ファイル名-流通される電子文書に対するファイル名を示す。ファイル名は送信者が指定し、電子文書を受信者に伝達する時に共に伝達されるべきである。受信者は、伝達を受けたファイル識別値を利用して本フィールドに適用するべきである。-本フィールドは選択的に使われてもよいが、fileIDフィールドを使用しない場合には必ず使われるべきである。上述したような流通証明書の時刻情報関連の整合性基準は下記表144の通りである。時刻情報の順序は発送日時<受信日時≦閲覧日時≦証明書の発給日<証明書の効力満期日であり、流通証明書の検証時に時刻情報が前記順序に沿っているか否かを確認しなければならない。流通証明書の検証は、証明書構造の検証、証明書の電子署名の検証、証明書の主要フィールドの確認、証明書の時刻情報の整合性の検証を含む。証明書構造の検証は、証明書がASN.1で定義されたものと同一であるかを検証する過程である。証明書の電子署名の検証は、流通証明書に適用された電子署名を検証する過程である。証明書の主要フィールドの確認は、versionフィールド値がv2であるかを確認するバージョンフィールドの確認、targetフィールドがhashDataであるかを確認するtargetフィールドの確認、電子署名に使われた認証書のDNと証明書の基本フィールドのDNが同一であるかを検証する発給者情報の検証、requestInfoフィールドがNullであるかを確認するrequestInfoフィールドの確認、distributionInfos拡張フィールドが存在するかを確認し、criticalがTRUEであるかを確認する拡張フィールドの確認、numberOfFilesフィールドの値とdistributionInfos拡張フィールド内のDistributedFileの個数が同一であるかを確認するファイル個数の確認、targetフィールドのハッシュ値とdistributionInfos拡張フィールドのハッシュ値が同一であるかを確認するtargetフィールドハッシュ値の確認、流通証明書の時刻情報の整合性の検証基準に応じて検証する時刻情報の整合性の検証を含む。証明書の時刻情報の整合性の検証は、流通証明書の時刻情報の整合性の検証基準に応じて検証する。一方、流通証明は、電子文書の流通過程で発生した発信、受信、受信確認に対する事実に対して信頼性のある方式で証明する行為をいう。流通証明は別途の応用プログラムで遂行し、流通証明書ビューアーおよび流通証明APIにおいては遂行しない。流通証明は、流通証明書の検証に追加的に遂行しようとする場合に、次の内容を遂行する。-流通証明書の検証:流通証明書の検証を遂行する。-流通証明書政策の確認:発信、受信、受信確認に対する流通証明書政策OIDおよびQualifier値を確認する。-送信者のアドレス確認:電子文書を発送した送受信個体のアドレスが正確であるかを確認する。-受信者のアドレス確認:電子文書を受信した送受信個体のアドレスが正確であるかを確認する。-発送日時の確認:送信者が電子文書を発送した時刻が正確であるかを確認する。-受信日時の確認:受信者が電子文書を受信した時刻が正確であるかを確認する。-受信確認日時の確認:受信者が電子文書を受信確認した時刻が正確であるかを確認する。-流通IDの確認:流通個別件に付与された流通IDが正確であるかを確認する。送信者および受信者が流通IDを別途に保管して管理する場合、これを比較して管理することができる。-流通ファイルの識別子またはファイル名の確認:流通されるファイルのIDまたはファイル名が正確であるかを確認する。送信者および受信者がファイルIDおよびファイル名を別途に保管して管理する場合、これを比較して管理することができる。-流通ファイルのハッシュ値の確認:流通対象となるファイルの各々のハッシュ値と拡張フィールドのDistributedFileフィールドの値が同一であるかを確認する。この時に使うハッシュアルゴリズムは流通証明書内に指定されたもので遂行して比較する。一方、流通証明書プロファイルは下記表145の通りであり、考慮する事項は、電子署名はRSA2048bitおよびSHA256アルゴリズムを適用するということと、signedData構造において認証書は必ず含まれるべきであるということと、signerInfosフィールドには1つのsignerInfoだけが含まれるということである。上述したような流通証明書を第3者保管機関と連係する方案は、流通証明書を発給すると同時に第3者保管機関に格納保管依頼することにより、発給された流通証明書の信頼性が保証されるものである。第3者保管機関事業者の流通メッセージングサーバシステムの場合の流通証明書の保管プロセスは図98の通りであり、流通メッセージングサーバシステムにおいて発給した流通証明書を直接第3者保管機関連係モジュールを介して第3者保管機関内部に保管要請をし、第3者保管機関連係モジュールは流通証明書の保管要請モジュールと第3者保管機関連係インターフェースクライアントモジュールとから構成され、既存の第3者保管機関連係インターフェース規格に応じて第3者保管機関に保管される。一般送受信個体の流通メッセージングサーバシステムの場合の流通証明書の保管プロセスは図99の通りであり、発給された流通証明書の保管のために第3者保管機関事業者に要請をするために第3者保管機関事業者の流通メッセージングサーバシステムに要請メッセージを伝達し、外部から流通証明書の保管要請を受けた第3者保管機関事業者の流通メッセージングサーバシステムは第3者保管機関連係モジュールを介して第3者保管機関の内部に保管要請をし、第3者保管機関連係モジュールは既存の第3者保管機関連係インターフェース規格に応じて第3者保管機関に保管要請をする。送受信個体が流通証明書を第3者保管機関に保管する詳細処理は図100に示すような手続きからなり、詳細な説明は次の通りである。○流通証明書登録者-第3者保管機関に流通証明書を保管する時に、第3者保管機関事業者と送受信個体間の契約によって保管代行者を指定することができ、第3者保管機関事業者は保管代行者が登録者となって保管代行者の公認認証書を基盤に流通証明書を保管するようになる。○第3者保管機関への保管要請プロセスの類型-第3者保管機関事業者は同期式または非同期式処理のうちの1つ以上を提供するべきであり、流通メッセージングサーバは連係しようとする第3者保管機関事業者が提供する方式に応じて連係する。-Case1:同期式処理プロセス送信者が流通証明書の保管要請時、第3者保管機関に登録が完了した後に登録証明書が発給される全てのプロセスが同期式で行われることにより、送信者の流通メッセージングサーバは同期式応答メッセージで登録証明書の伝達を受ける。要請に対する応答メッセージが最終的な第3者保管機関の登録結果であるため、保管要請に対するエラー発生時の再処理は送信者の流通メッセージングサーバが遂行するべきである-Case2:非同期式処理プロセス送信者が第3者保管機関の流通メッセージングサーバに流通証明書の保管要請をすれば、第3者保管機関の流通メッセージングサーバが先に要請メッセージの有効性を検証した後、保管要請を受け付ける。第3者保管機関事業者は、保管要請メッセージに応じて、第3者保管機関に登録し発給を受けた登録証明書を最初保管要請者である送信者の流通メッセージングサーバに伝達するべきである。受け付けた保管要請に対して第3者保管機関に登録することは第3者保管機関事業者の責任であるため、保管エラー発生時の再処理も第3者保管機関事業者が遂行するべきである[流通プロトコル]以下では、上述したような本発明の好ましい実施形態による電子文書流通システムおよび方法に適用される流通プロトコルについて詳細に説明する。本発明の好ましい実施形態による電子文書流通システムおよび方法に適用される流通プロトコルを説明するにおいて、1メッセージパッケージング、2メッセージ封筒構成、3HTTPバインディングについて順に説明する。1メッセージパッケージング流通プロトコルのメッセージ構造はebMSV2.0規格を準用し、2つの論理的なMIMEパートを持つ。1番目のMIMEパートは、SOAPメッセージを含み、ヘッダコンテナーと呼ばれ、SOAPメッセージは、HeaderとBodyとから構成され、2番目のMIMEパートは、0個以上の追加のMIMEパートであって、ペイロードコンテナーと呼ばれるが、アプリケーションレベルの添付文書を含む。このような流通メッセージの基本的な構造は図101の通りであり、SimpleObjectAccessProtocolSOAP1.1および、SOAPMessageswithAttachmentのような標準規格を遵守する。流通メッセージパッケージの全てのMIMEHeader要素は、SOAPMessageswithAttachments規格を遵守する。さらに、メッセージパッケージ内のContent-TypeMIMEHeaderは、必ずSOAPメッセージ文書を含むMIMEBody部分のMIMEメディア類型と同一のtype属性を有する。SOAP規格によれば、SOAPメッセージのMIMEメディア類型はtext/xml値を有するべきであるとなっている。ルート部分は、[RFC2045]に準ずる構造を有するContent-IDMIMEヘッダを含み、Multipart/Relatedメディア類型に対する必須のパラメータに追加して、startパラメータ[RFC2387]においては選択事項が常に存在するべきである。multipart/relatedメッセージパッケージのMIMEヘッダの例題は次の表146の通りである。以下では、本発明による流通メッセージについて説明するにおいて、メッセージパッケージのルートBody部分をHeaderヘッダコンテナーと定義する。Headerコンテナーは、MIMEBody部分として、SOAPMessageswithAttachment明細で定義したように1つのSOAPメッセージを含む。ヘッダコンテナーのMIMEContent-Typeheaderは、SOAP規格に応じ、text/xml値を有するべきである。Content-Typeヘッダはcharset属性を含んでもよく、例題は次の表147の通りである。MIMEcharset属性は、SOAPメッセージを生成するのに用いられる文字群を識別するために使われる。この属性の意味論は、[XMLMedia]に明示されたtext/xmlのcharsetparameter/encodingconsiderationに説明されている。有効な値の目録はhttp://www.iana.org/から探すことができる。仮に2つが全て含まれていれば、MIMEcharset属性はSOAPメッセージのエンコード宣言部と同一であるべきである。仮に提供されているとすれば、MIMEcharset属性は、SOAPメッセージを生成する時にエンコードと相反する値を含んでいてはいけない。この文書をエンコードする時は、最大限の互換性のために、必ず[UTF-8]を使用するべきである。text/xml[XMLMedia]から導き出したメディア類型のために定義された処理規則のためにこのMIME属性は基本値を有しない。ヘッダコンテナーの例題は下記表148の通りである。SOAPMessageswithAttachments規格に応じて、メッセージパッケージ内には0個以上のペイロードコンテナーが含まれてもよい。仮にメッセージパッケージがアプリケーションペイロードを含んでいるのであれば、これは、必ずペイロードコンテナーに含まれるべきである。仮に、メッセージパッケージがアプリケーションペイロードを含んでいないのであれば、ペイロードコンテナーを表示してはいけない。各ペイロードコンテナーの内容物は、SOAPBody内のebXMLメッセージのManifest要素によって識別されなければならない。ebXMLメッセージサービスの明細は、アプリケーションペイロードの構造と内容物に対し、いかなる規定もいかなる方法の制約も定めていない。ペイロードは、simple-plain-textオブジェクトまたは複雑に重なった色々な部分のオブジェクトもなり得る。ペイロードオブジェクトの構造と構成に対する明細は、ebXMLメッセージサービスを使用する業務プロセスや情報交換をどのように定義するかによって変わり得る。ペイロードコンテナーの例題は次の表149の通りである。本発明による流通メッセージの全てのMIME部分は、[RFC2045]規格に準ずる追加のMIMEヘッダを含むことができる。実現時には、この発明で定義されていないMIMEヘッダを無視することもでき、識別できないMIMEヘッダらは必ず無視するべきである。例えば、実現時にcontent-lengthをメッセージに含むことができるが、content-lengthが表れているメッセージの受給者はこれを無視することもできる。2メッセージ封筒構成SOAP規格に準じて全ての拡張要素内容は有効なネームスペースに限定されるべきである。本発明で定義された全てのebXMLSOAP拡張要素内容は、ebXMLSOAPEnvelope拡張ネームスペースに限定されるべきである。ネームスペース宣言部は、SOAPEnvelope、HeaderまたはBody要素に含まれているか、各SOAP拡張要素に直接含まれてもよい。SOAPEnvelopeは、SOAPメッセージのRoot項目としてSOAPメッセージ内の各種Namespaceを宣言する。宣言するべきNamespaceは次の表150の通りである。メッセージ封筒のスキーマ構造は図102の通りであり、メッセージ封筒の例題は下記表151の通りである。SOAPEnvelope要素の子要素であるSOAPHeader要素とSOAPBody要素について順に詳細に説明すれば、次の通りである。SOAPHeader要素はSOAPEnvelope要素の1番目の子要素であり、MessageHeader、SyncReply、Signature、ErrorListのような拡張要素を含む。MessageHeaderはメッセージのルーティング情報To/From、などとメッセージに関する他の文脈情報を含む必須要素であり、SyncReplyは次のSOAPノードに行く必須転送状態を示す要素であり、Signatureはメッセージと関連したデータを署名する[XMLDSIG]に準ずる電子署名を表示する要素であり、ErrorListは以前のメッセージを対象に報告されたエラー目録を入れた要素であり、以前のメッセージに対するエラーを報告する時にのみ使用されるが、このようなMessageHeaderの要素の各々について詳細に説明すれば、次の通りである。MessageHeader要素は、全てのebXMLメッセージに表現されるべき必須要素として、必ずSOAPHeader要素の子要素として表現されるべきである。MessageHeader要素は次のような下位要素で構成された複合要素であり、MessageHeaderのelement構造は下記表152の通りであり、MessageHeaderのスキーマ構造は図103の通りである。SyncReply要素は同期式送信を意味するものであって、id属性、version属性、SOAPactor属性必ずhttp://schemas.xmlsoap.org/soap/actor/next値を有するべきである、SOAPmustUnderstand属性値を有し、SyncReply要素の例題は次の表153の通りである。Signature要素はSOAPHeaderの子要素として必ず存在するべきであるが、これは、流通メッセージは上記で言及した危険要素に対応するために必ず電子的に署名されるべきであるためである。[XMLDSIG]規格に応じて電子署名を遂行する過程は次の通りである。先ず、SOAPEnvelopeにSignatureMethod、CanonicalizationMethod、Reference要素を有したSignedInfo要素と必須ペイロードオブジェクトを[XMLDSIG]に規定された通りに生成する。次に、正規化した後、[XMLDSIG]に指定された通り、SignedInfoに指定されたアルゴリズムを基準にSignedInfoのSignatureValueを算出する。次に、[XMLDSIG]に指定された通り、SignedInfo、KeyInfo勧告事項、SignatureValue要素を含むSignature要素を生成する。次に、SOAPHeaderのSignature要素をSOAPHeader要素に含ませる。上述したような電子署名時に使われるアルゴリズム情報は次の通りである。アルゴリズムは、W3CXML-SignatureSyntaxandProcessingRFC3275のアルゴリズム部分6.0Algorithmsを基本的に従う。また、国内固有のアルゴリズムを支援するために、TTAS.IF-RFC3075拡張性生成言語の電子署名構文と処理XML-SignatureSyntaxandProcessing韓国情報通信技術協会、2004年で定義されたアルゴリズムを利用する。本発明による流通プロトコルにおいて利用するアルゴリズム目録は、電子署名NameSpace、ハッシュDigest、電子署名Signature、正規化Canonicalization、変換Transformを含む。メッセージ送受信時の電子署名の生成および検証過程における曖昧性を最小化するために、次の目録以外のアルゴリズムは使用しないことが好ましい。電子署名のNamespaceの例題は次の表154の通りである。データを縮約するのに利用するアルゴリズムとしてSHA1とSHA256を利用することができ、例題は次の表155の通りである。但し、HA1は公認認証書の暗号体系の高度化が完全に適用される時点である2012年からはその使用が制限される。メッセージ電子署名時に使われるアルゴリズムはRSAwithSHA1、RSAwithSHA256であり、例題は次の表156の通りである。但し、RSAwithSHA1を利用する場合は、公認認証書の暗号体系の高度化が完全に適用される時点である2012年からはその使用が制限される。論理的に同一な文書に対して物理的に色々な表現が可能なXMLの特性のため、同じ文書に対して電子署名値が異に出ることがあるので、このような現象を防止するために必ず正規化Canonicalization過程を経るべきであり、例題は次の表157の通りである。正規化は、注釈のない正規XMLCanonicalXML、omitscommentsを使う。全体XMLデータ中の実際の署名対象となるデータを加工し選択する過程を経るアルゴリズムとして様々な変換アルゴリズムが存在するが、その中の3つだけを利用するようにする。第1は電子署名が署名対象内に含まれる形式に従うのでEnvelopedSignature変換であり、第2は前記で説明した正規化Canonicalization、そして第3は署名対象情報を選択するXPathフィルタリングXPathFilteringであり、例題は次の表158の通りである。電子署名構文の構造は図104の通りであり、上述した方式の通りに電子署名が遂行されたメッセージの例題は次の表159の通りである。Errorlist要素は、メッセージを受信して処理過程を遂行する時、エラーが発生する場合にのみHeaderの下位に位置する。ErrorList要素が生成される場合には、必ずMessageHeader要素内にRefToMessageIdが存在するべきであり、RefToMessageIdは、エラーが発生したメッセージのMessageIdを指し示さなければならない。ErrorList要素はid属性、OAPmustUnderstand属性、version属性、highestSeverity属性、1つ以上のError要素のような属性を有し、ErrorListの構造は図105の通りである。この時、報告されるエラーがなければ、ErrorList要素は存在してはいけない。highestSeverity属性は、全てのError要素の最も深刻な状態を表示する。特に、あるError要素がseverityをErrorに設定していれば、highestSeverityはErrorに設定するべきであり、そうではない場合には、highestSeverityをWarningに設定するべきである。Error要素は、id属性、codeContext属性、errorCode属性、severity属性、location属性、Description属性を有する。id属性は、文書内において、ErrorList要素を唯一に識別する役割をする。codeContext属性は、errorCodesのネームスペースまたはスキーマを示す。これは、必ずURIでなければならない。この属性の基本値は、urn:oasis:names:tc:ebxml-msg:service:errorsである。この属性に基本値がなければ、その明細の実現はerrorCodesを使うということを示す。必須属性であるerrorCode属性は、エラーを持つメッセージのエラーが有した本質を指示する。errorCodeの有効な値とコードの意味は下記で説明する。必須属性であるseverity属性はエラーの深刻性を示す値であって、有効な値はWarning、Errorがあるが、Warningは、エラーが存在するが、対話中の他のメッセージは正常に生成されることを示し、Errorは、復旧不可能なエラーがメッセージに存在し、対話中にこれ以上他のメッセージは生成されないことを示す。location属性は、エラーが存在するメッセージ部分を指し示す。仮にエラーがebXML要素内に存在し、要素がwell-formedであれば、location属性の内容は[Xpointer]でなければならない。Description属性の内容は、xml:lang属性において定義された言語でエラーの叙述的な説明を提供する。通常、これは、XMLパーサーやメッセージを検証するソフトウェアが生成したメッセージとなる。この意味は、この内容はError要素を生成したソフトウェアの販売者や開発者によって定義されるということを意味する。ErrorListの例題は次の表160の通りである。流通プロトコルを基盤にメッセージを送受信する過程でエラーが発生すれば、エラーを認知した送受信個体は相手方にエラー内容を報告するべきであり、報告するべきエラーはメッセージ構造エラー、信頼メッセージングエラー、保安エラーを含む。本発明で定義する流通プロトコルより下位レイヤーに属するHTTPおよびSocketのようなデータ通信プロトコルと関連したエラーは、データ通信プロトコルにおいて支援する標準メカニズムによって発見し報告されるべきであり、本発明で定義するエラー報告メカニズムは使わない。エラーコードはエラー対象および類型別に区分され、詳しい内容は次の表161の通りである。一方、SOAPBody要素はSOAPEnvelope要素の2番目の子要素であり、Manifestのような拡張要素を含み、Manifestはペイロードコンテナーまたはウェブのように他の場所に位置したデータを示す要素である。Manifest要素は、1個以上のReference要素で構成された複合要素である。各Reference要素は、ペイロードコンテナーに含まれたペイロード文書の一部として含まれるか、URLにアクセス可能な遠距離のリソースであるメッセージに関連したデータを識別する。SOAPBodyにはペイロードデータをのせないことが好ましく、Manifestの目的は、XMLメッセージと関連した特定のペイロードを容易に直接にアクセスできるようにすることと、パーシング作業がなくてもアプリケーションがペイロードを処理できるか否かを判断できるようにすることである。Manifest要素は、次のような1個のid属性、1個のversion属性および1個以上のReference要素で構成されている。Reference要素は、0個以上のSchema要素および0個以上のDescription要素を含む下位要素で構成された複合要素である。この時、0個以上のSchema要素は親Reference要素から識別されたインスタンス文書を定義するスキーマに対する情報であり、0個以上のDescription要素:親参照要素によってReferenceされたペイロードオブジェクトに対する説明である。Reference要素は、それ自体が[XLINK]の単純リンクである。XLINKプロセッサまたはエンジンの使用が必須ではないが、実現要求事項によっては有用である。Reference要素は、上記で提供された要素の内容と共に、id、xlink-type、xlink:href、xlink:roleのような属性内容を含んでおり、この他に他の有効ネームスペースである属性が存在することができ、受信MSHは上記で定義したものの以外に外部のネームスペース属性は無視することができる。この時、idはReference要素に対するXMLIDであり、xlink-typeはXLINK単純リンクで要素を定義し、simpleという固定された値を有し、xlink:hrefは参照されたペイロードオブジェクトのURI値であり、[XLINK]明細の単純リンクに準ずるものであるべきである。そして、xlink:roleはペイロードオブジェクトやその目的を説明するリソースを識別するものであって、存在するのであれば、[XLINK]明細に準ずる有効なURI値を有しなければならない。Schema要素は、参照する項目がそれを記述するスキーマを持っているのであれば例:XMLSchema、DTD、またはDatabaseSchema、そのSchema要素はReference要素の子要素として存在しなければならない。これは、スキーマとバージョンを識別する方法として使われ、親Reference要素によって識別されるペイロードオブジェクトを定義する。Schema要素は、locationおよびversionのような属性を有する。この時、locationはスキーマの必須URIであり、versionはスキーマのバージョン識別子である。xlink:href属性がcontentidURIschemecidであるURIを含んでいれば、そのcontent-idを有するMIMEはメッセージのペイロードコンテナーに表現されているか、そうでなければ、errorCodeをMimeProblemに、severityをErrorにするエラーを発信当事者に伝達するべきである。xml:href属性がcontentidURIschemecidであるURIを含んでいなければ、URIは解釈されず、実現に応じてエラーを伝達するべきか否かを決定しなければならない。エラーが伝達されるべきであると決定されれば、errorCodeをMimeProblemに、severityをErrorにするエラーを発信当事者に伝達するべきである。下記の表162は典型的な1個のペイロードMIMEBody部分を有するメッセージのManifestを示す。3HTTPバインディングHTTPを通してメッセージを転送する方案において、HTTPバインディング例題は次の表163の通りである。本発明による流通プロトコルにおいて、HTTPレベルの応答コードを返すために、[RFC2616]で定義されたHTTP応答コードを利用するべきであり、主要応答コードは次の表164の通りである。[電子文書の書式登録機]以下では、上述したような本発明の好ましい実施形態による電子文書流通システムの電子文書の書式登録機と関連して詳細に説明する。電子文書の書式登録機は、電子文書流通において、送受信個体が文書を流通するために必要な書式を生成、登録、管理できるシステムである。電子文書の書式登録機は、書式生成機、書式登録機、書式管理機、および標準連係モジュールで構成される。書式生成機はPDF変換モジュールとPDFFormDesignerとからなり、PDF変換モジュールは一般書式をPDFに変換する機能例:標準PDF-Aで生成を提供し、PDFFormDesignerは入力可能なFormPDFを生成できる機能を提供し、2次元バーコードおよびコピー防止マークなどの文書保安機能を提供する。書式登録機は、ユーザが書式例:ハングル、MS-Wordなどの一般書式を登録できる機能を提供する。書式管理機は、書式管理者が書式を登録、管理できる機能を提供し、カテゴリー別の登録、バージョン別の履歴管理機能を提供し、書式別の閲覧期間、閲覧回数、印刷回数の制御などの設定機能を提供する。標準連係モジュールは、流通クライアントアプリケーションと連係できる機能を提供し、書式リスト、検索機能を提供し、ファイルダウンロード機能を提供する。本発明による電子文書の書式登録機の書式登録プロセスは図106の通りである。標準電子文書はFormdesignerを利用してFormPDFで生成し、必須要件は下記表165の通りである。標準電子文書の構造は文書下段に5cm程度の空間確保が必要であり、バーコード大きさはデータ量に応じて可変的であり、コピー防止マーク大きさは3>1.3にし、位置は書式模様に応じて適切な位置に配置し、その一例は図107の通りである。標準連係モジュール標準インターフェースは、流通クライアントアプリケーションからユーザが書式を検索しダウンロードして書式を生成できるようにし、WebUIUserInterfaceに提供して流通クライアントアプリケーションに含まれるようにし、カテゴリー別の検索、書式目録、ファイルダウンロードなどの機能を提供する。[電子文書パッケージング]以下では、上述したような本発明の好ましい実施形態による電子文書流通システムおよび方法に適用される電子文書パッケージングと関連して詳細に説明する。電子文書パッケージングは、電子文書流通において、送受信個体が文書を流通するために必要なメッセージングシステムの規格である。電子文書パッケージングは標準電子文書、添付文書で構成され、標準電子文書に対するメタデータで構成されている。標準電子文書はPDF-Aを基盤に生成され、メタデータは文書保安機能などの情報で構成されている。添付文書は、PDFに変換せずに原本そのままパッケージングする。標準電子文書は、ユーザの公認認証書で電子署名し、パッケージング後、電子文書パッケージを電子署名してパッケージに含ませる。図108は電子文書パッケージの構造を示しており、このような図108を参照すれば、本発明による電子文書のパッケージ構造はパッケージヘッダ、メタデータ、標準電子文書、添付文書、電子署名データを含み、各々の細部的な構成要素は下記表27~表31の通りである。パッケージヘッダはパッケージ全体の構造情報を含み、メタデータは標準電子文書の文書保安機能情報を含み、文書の閲覧回数、印刷回数、2次元バーコード情報などの情報を含み、標準電子文書は標準PDF-A形式で構成され、PDFファイル内のイメージ領域に2Dバーコードデータを含み、標準PDFSignedData領域に電子署名データを含み、添付文書は標準電子文書ではない非定型文書であるため、文書保安機能の適用対象から除外し、個別的な電子署名は除外し、電子署名データはパッケージングされたデータをユーザの公認認証書を使って電子署名してパッケージングに含ませる。電子文書パッケージングを検証する方案としては1電子文書パッケージングの電子署名の検証方案、2標準電子文書の検証方案、3印刷された電子文書の検証方案があり、各方案について説明すれば、次の通りである。1電子文書パッケージングの電子署名の検証方案-クライアントAppは、電子署名パッケージングを処理する時に電子署名を検証し、検証を成功した場合にのみ標準電子文書を電子文書ビューアーに伝達する。-また、手動の電子署名の検証機能を支援して、紛争発生時に電子署名の検証ができるようにする。2標準電子文書の検証方案-電子文書ビューアーは、標準電子文書を閲覧する時に電子署名の検証を遂行し、成功した場合にのみ電子文書ビューアーにおいてファイルを閲覧できるようにする。3印刷された電子文書の検証方案-別途に提供される検証プログラムとフラットベッドスキャナを利用して、2次元バーコード内の電子署名データの検証、および原本の文書内容と印刷された文書内容とを肉眼で比較する。一方、コピー防止マークは、電子文書を最終に受けるユーザのプリンタパターンに応じて生成しなければならないので、パッケージングには含まれない。[流通クライアントアプリケーション]以下では、上述したような本発明の好ましい実施形態による電子文書流通システムの流通クライアントアプリケーションと関連して詳細に説明する。企業または個人が公認電子アドレスに基づいて文書情報を送受信するためには、これを支援するためのユーザインターフェースUserInterface、以下、UIというを提供するアプリケーションが必要である。流通メッセージングサーバシステムがメッセージをやりとりするためのメッセージングエンジンとしてe-メールと比較した時にメールサーバのような役割をするのであれば、流通クライアントアプリケーション以下、APPというは、ユーザがe-メールサーバと連係してe-メールをやりとりするために提供されるメールクライアントのようなユーザ用アプリケーションの役割をする。図109は流通クライアントAPPの構造図を示し、このような図109を参照すれば、流通クライアントAPPは、流通メッセージングサーバシステムを利用して文書を交換しようとする一般ユーザのためのUI環境のアプリケーションとして、基本的に1ユーザ認証、2メッセージ作成、3メッセージ目録の照会および詳細内容の閲覧機能、4流通メッセージングサーバシステム連係で構成される。クライアントAPPは、このような基本機能の他に追加的にメッセージ送受信およびアプリケーション管理のための5基本情報と環境情報の管理、6メッセージフォルダの管理、7文書書式の管理、8文書作成機などの機能を提供することができるが、これは、アプリケーション開発者によって選択的に提供される機能である。1ユーザ認証-流通クライアントAPPが流通メッセージングサーバシステムと連係する前に、流通メッセージングサーバシステムは、ユーザアカウントを確認した後にログインセッション情報を受けるべきである。-流通クライアントAPPがユーザ認証を受けるための方法としては、認証書公認または私設の全てを許容を基盤にしたユーザ認証、またはID/PWを基盤にしたユーザ認証などがある。2メッセージ作成機能-流通クライアントAPPは新規メッセージを作成できるユーザインターフェースを提供するべきであり、作成された文書を流通メッセージングサーバシステムと連係して受信相手方に伝達するべきである。-メッセージ作成機能は、メッセージを転送するために流通メッセージングサーバシステムの転送インターフェースを呼び出す時、必要な基本情報のうち、環境情報によって既に設定された値ではない項目は入力できるように提供しなければならない。3メッセージ目録の照会および詳細内容の閲覧機能-流通メッセージングサーバシステムは、メッセージを送信メッセージ、受信メッセージに区分して管理をする。流通クライアントAPPは、ログインされたユーザアカウントを基盤に流通メッセージングサーバシステムと連係して、ユーザアカウントに該当する各メッセージの目録を照会する機能と、メッセージの詳細内容を見ようとする時、添付文書を含んでメッセージの詳細情報を全て閲覧できる機能を必ず提供しなければならない。4流通メッセージングサーバシステム連係-流通クライアントAPPの最も重要な機能は、流通メッセージングサーバシステムと連係してメッセージを送受信する機能である。流通クライアントAPPは、流通メッセージングサーバシステムが提供するメッセージ送信機能と受信メッセージ読みインターフェースを介してログインしたアカウントを基盤にメッセージを転送し受信する。5基本情報と環境情報の管理-クライアントAPPは、メッセージの転送時に基本的に必要な環境情報を管理する機能を提供しなければならない。流通クライアントAPPは独立に存在するアプリケーションではないため、必ず流通メッセージングサーバシステムとの連係を通じて流通基盤のインフラに参加可能である。したがって、基本的に流通メッセージングサーバシステムとの連係のために必要な流通メッセージングサーバシステム連係情報流通メッセージングサーバシステムのアドレス情報を基本的に設定し管理しなければならない。-その他に文書の書式登録機との連係のための登録機サーバ情報の管理や、流通クライアントAPPのシステム環境に対する付加情報の管理は、アプリケーションの開発範囲に応じて定義して提供すれば良い。6メッセージフォルダの管理-流通メッセージングサーバシステムが管理するメッセージは、送信、受信メッセージを基本に分類して管理し、送受信メッセージは、各々の処理状態に応じて状態情報を管理する。各メッセージの状態情報として、送信メッセージは送信前、送信完了、送信失敗、担当者の受信完了の状態を、受信メッセージは検証エラー、受信確認前、受信確認、閲覧確認の状態を管理し、流通クライアントAPPは流通メッセージングサーバシステムが提供する基本状態情報に基づいてメッセージフォルダを管理してユーザに提供する。-流通クライアントAPPは、送受信フォルダを基準に送信と受信メッセージを区分して、流通メッセージングサーバシステムが提供する状態情報に応じ、ユーザに各メッセージの状態を知らせることを基本として提供しなければならない。しかし、その他にアウトボックス、ゴミ箱のような削除したメッセージ箱を提供したり、ユーザが直接フォルダを定義し管理できるようにする機能を提供したりすることは、アプリケーション開発者の選択事項であるので、本発明の説明では省略する。7文書書式の管理機能-流通メッセージングサーバシステムは、転送するメッセージに添付される文書の様式を制限しないため、送受信対象の文書としては、一般のテキストファイルから、オフィスファイル、XML文書、マルチメディアファイルなど、いかなる種類のファイルも全て可能である。しかし、ユーザが流通クライアントAPPを業務に活用するように便宜を提供するために、基本的な文書に対しては書式基盤に文書作成を支援する機能を付加的に提供することが可能である。流通クライアントAPPは、文書書式登録機から提供する文書書式を登録機の標準インターフェースを介して検索してダウンロードした後、ダウンロードした文書書式を基盤に文書を作成し、これをメッセージに添付して送る機能を提供することができる。-流通クライアントAPPは、電子文書流通ハブにおいて提供する文書書式登録機と連係し、該当文書書式登録機と連係して文書書式を管理することもでき、独自に文書書式の管理体系を構築し、この体系と連係して文書書式を管理する方法がある。電子文書流通ハブにおいて提供する文書書式登録機と連係して書式を検索しダウンロードする方法に対する詳細な内容は、上述した[電子文書の書式登録機]に対する説明を参照する。8文書作成機-文書作成機は、文書書式の管理機能を通じて流通クライアントAPPがダウンロードした書式を基盤にユーザが文書を作成できるように支援する作成機である。文書作成機は、電子文書流通ハブが提供する文書書式登録機を利用する場合には、上述した[電子文書の書式登録機]に対する説明を参照して設計すれば良く、自体的に文書書式の管理体系を構築した場合には、該当書式管理体系に応じて文書作成機を設計すれば良い。前記のような流通クライアントAPPの最も基本となるプロセスとしては1文書転送プロセス、2文書受信プロセスがあり、付加的なプロセスとしては3電子文書の書式ダウンロードプロセスがある。文書転送および文書受信のために、流通クライアントAPはサーバとなる流通メッセージングサーバシステムと連係し、標準文書様式の登録のためには、電子文書の書式登録機サーバと連係する。1文書転送プロセス流通クライアントAPPが連係した流通メッセージングサーバシステムを介して他の送受信個体に電子文書を転送するステップは図110の通りであり、処理手続きは下記の通りである。先ず、流通クライアントAPPを介して受信者に転送するメッセージを生成する。この時、メッセージは、既に送信者が作成した文書を添付するか、流通クライアントAPPが提供する文書作成機を通じて作成した文書を添付して、受信者を指定した後にメッセージを生成する。次に、受信者のアドレス情報を入力した後、流通メッセージングサーバシステムの転送インターフェースを呼び出すことによってメッセージ転送を要請する。次に、転送者の流通メッセージングサーバシステムは、転送プロセスに応じて受信者にメッセージを転送した後、受信者から受信に対する応答メッセージ受信証明書または受信エラーを受信する。次に、転送者の流通メッセージングサーバシステムは、受信に対する応答メッセージを受信した後、流通クライアントAPPに転送に対する応答として伝達する。ここで、第1~第4ステップは必須手続きであり、第2~第4ステップは必ず同期式で行われなければならない。次に、転送者の流通メッセージングサーバシステムが受信者から受信担当者の閲覧を確認する閲覧証明書を含むメッセージを受ければ、転送流通メッセージングサーバシステムは、受信に対する応答メッセージを返し、受信メッセージを該当ユーザの私書箱に保管する。次に、最初転送者の流通クライアントAPPは、連係した流通メッセージングサーバシステムに受信文書を要請する。次に、転送者の流通メッセージングサーバシステムは、私書箱に保管された受信文書目録を、受信文書を要請したユーザの流通クライアントAPPに伝達する。ここで、第5~第7ステップは選択的な事項であり、最初メッセージの転送時に受信担当者の閲覧確認を要請した場合にだけ発生する選択的な手続きである。2文書受信プロセス流通クライアントAPPが他の送受信個体から電子文書を受信するプロセスは図111の通りであり、処理手続きは次の通りである。先ず、受信者の流通メッセージングサーバシステムは、メッセージを受信すれば、受信したメッセージに対する受信応答メッセージを受信者に返し、受信メッセージを該当ユーザの私書箱に保管する。次に、受信者の流通クライアントAPPは、連係した流通メッセージングサーバシステムにログインした後、受信文書を要請する。次に、受信者の流通メッセージングサーバシステムは、受信文書を要請したユーザの私書箱に保管された受信文書目録を伝達する。ここで、第2~第3ステップは同期式である。次に、受信者が受信メッセージの目録において、メッセージに対する詳細情報を見ることを要請すれば、流通クライアントAPPは、流通メッセージングサーバシステムに該当メッセージの添付文書を含む詳細情報を伝達する。次に、最初転送者が受信担当者の閲覧確認を要請した場合、受信者の流通メッセージングサーバシステムは、ユーザが受信文書に対する詳細情報要請をした時点で、該当メッセージの送信者に閲覧証明書を含むメッセージを転送する。次に、受信者の流通メッセージングサーバシステムは、第5ステップで転送された担当者の閲覧確認メッセージ閲覧証明書に対する受信応答メッセージを受信する。3電子文書書式のダウンロードプロセス流通クライアントAPPが電子文書の書式をダウンロードするプロセスは図112の通りであり、処理手続きは次の通りである。先ず、流通クライアントAPPは、電子文書の書式登録機サーバに直接連係して、文書書式に対する検索を要請する。この時、電子文書の書式登録機サーバが提供する標準連係インターフェースを基盤に連係する。次に、電子文書の書式登録機サーバは、検索された文書書式に対する情報を結果として返す。この時、第1~第2ステップは同期式である。次に、流通クライアントAPPは、検索された書式目録をユーザに見せることにより、ユーザが書式を選択できるようにする。次に、流通クライアントAPPは、電子文書の書式登録機サーバに選択された電子文書の書式に対するダウンロードを要請する。次に、電子文書の書式登録機サーバは、要請を受けた書式を流通クライアントAPPに返す。次に、流通クライアントAPPは、ダウンロードした電子文書の書式を登録して、文書作成機で使えるようにPlug-Inする。前記のような流通クライアントAPPのために流通メッセージングサーバシステムが提供するインターフェースの類型としては、ユーザ認証ログイン、ログアウト、メッセージ転送の要請、受信メッセージGet、メッセージ詳細情報の要請、メッセージ削除がある。流通クライアントAPPと流通メッセージングサーバシステムの連係方案1~5について説明すれば、次の通りである。1流通メッセージングサーバシステムの連係プロトコル流通メッセージングサーバシステムが流通クライアントAPPのために提供する連係インターフェースは、流通メッセージングサーバシステムの送受信プロトコルと同一のプロトコルを基盤にする。但し、流通メッセージングサーバシステム間に送受信する場合とは異なり、流通クライアントAPPと流通メッセージングサーバシステムは図113のようにワンウェイOne-Way同期式通信だけを提供し、両者の間ではメッセージに対する電子署名認証またはユーザ認証の方式を使う。転送メッセージは流通メッセージングサーバシステムのメッセージ構造をそのまま活用するが、ユーザ情報および要請と応答メッセージは図114のような構造で構成され、詳細な説明は次の通りである。-SOAPHeader:流通クライアントAPPおよび流通メッセージングサーバシステムが業務類型に応じて送信者または受信者となって、上述した[流通プロトコル]に応じて構成され、messageHeaderおよびSignature情報で構成される。-SOAPBody:上述した[流通プロトコル]で定義されたManifest要素情報およびユーザログイン情報が入る。-転送文書コンテナー1:メッセージ転送の要請、受信メッセージGet、メッセージ詳細情報の受信の場合、本文の文書Contentsが入る。-転送文書コンテナー2:メッセージ転送の要請、メッセージ詳細情報の受信の場合、添付文書が2から順次入る。SOAPHeaderの構造は下記表171の通りであり、MessageHeaderの構造は下記表172の通りであり、SOAPBodyの構造は下記表173の通りであり、本文メッセージの構造は下記表174の通りである。2メッセージ転送の要請メッセージの転送時に流通クライアントAPPが流通メッセージングサーバシステムに伝達しなければならない基本情報は次の通りである。転送完了した後に私書箱に保管された送信文書は下記表175のように4ステップの状態情報を有する。要請メッセージの例題は下記表176の通りである。応答メッセージの例題は下記表177の通りである。3受信メッセージGet流通クライアントAPPが流通メッセージングサーバシステムと連係して、ログインしたユーザアカウントに受信メッセージを読んでくる行為と、流通メッセージングサーバシステムにおいてメッセージを削除する行為とは分離している。メッセージ受信の各プロセスに応じ、次のような2ステップの状態情報を管理しなければならない。-受信ユーザが私書箱の受信文書目録を閲覧したか否か-受信ユーザが受信文書に対する詳細内容を閲覧したか否か要請メッセージの例題は下記表178の通りである。応答メッセージの例題は下記表179の通りである。4メッセージ詳細情報の要請受信した文書目録を基盤にユーザが詳細内容を閲覧しようとする場合に、流通クライアントAPPは流通メッセージングサーバシステムのメッセージ詳細情報を要請する。詳細情報の要請を受けた流通メッセージングサーバシステムは、メッセージの詳細属性情報と該当メッセージの添付文書など、全てのメッセージ内容を流通クライアントAPPに応答メッセージとして伝達する。要請メッセージの例題は下記表180の通りである。応答メッセージの例題は下記表181の通りである。5メッセージ削除流通クライアントAPPは、ユーザが削除要請をする場合に、流通メッセージングサーバシステムに該当文書に対する削除要請を伝達し、その結果をユーザに知らせなければならない。ユーザの削除時、ゴミ箱概念の臨時削除機能の付与有無は、実際サーバ上での行為ではなく流通クライアントAPPの付加機能であるので、流通クライアントAPPの開発者が提供有無を決定することができるが、最終的に流通メッセージングサーバシステムに削除要請をする機能は必ず提供されるべきである。要請メッセージの例題は下記表182の通りである。応答メッセージの例題は下記表183の通りである。[記録媒体]一方、上述した本発明による電子文書流通方法はコンピュータにて実行できるプログラムで作成可能であり、コンピュータで読み取りできる記録媒体を利用してプログラムを動作させる汎用ディジタルコンピューターにて実現することができる。コンピュータで読み取りできる記録媒体は、マグネチック格納媒体例:ROM、フロッピーディスク、ハードディスク、磁気テープなど、光学的読み取り媒体例:CD-ROM、DVD、光データ格納装置などおよび搬送波例えば、インターネットを介した転送のような格納媒体を含む。以下、上述したような本発明において、アドレスディレクトリサーバと関連し、また他の実施形態について説明すれば、次の通りである。[アドレスディレクトリサーバ]信頼できる電子文書流通に参加するために全てのユーザは固有の電子アドレスの発給を受けるべきである。電子アドレスは次のような構造で表現される。電子アドレス:内部区分子区分記号固有登録アドレスこのような電子アドレスの一例としてgdhongnipa.krがある。前記電子アドレスの内部区分子は、固有登録アドレスの所有者が内部的な処理の便宜のために選択的に追加する情報であり、必要によっては省略可能である。前記電子アドレスの区分記号は、固有登録アドレスの前に位置するか、内部区分子と固有登録アドレスとの間に存在する記号であり、一例としてが可能であり、必要によっては他の記号が使える。前記電子アドレスの固有登録アドレスは、企業/機関/個人が発給要請した固有のID値であり、区分記号の後に存在する固有登録アドレス単位が送受信に対する法的な責任単位となる。このような固有登録アドレスは、送受信個体が流通メッセージングサーバを自体的に構築した後に発給を受けるか、または送受信個体が電子文書の3者流通代行機関を介して発給を受けた固有登録アドレスであって、電子アドレスの必須構成要素である。前記送受信個体は自身が保有した流通メッセージングサーバシステムに対する実際物理アドレスIPAddressを有するが、このような物理アドレスと前記電子アドレスは連関関係がなく、物理アドレスと電子アドレスは1:Nの関係を持つ。1つの電子アドレスがいくつかの物理アドレスを有する場合は存在しない。電子アドレスに対する情報電子文書の法的な受信責任は、区分記号の後に存在する企業/機関/個人が持つべきであり、内部区分子による配付は、企業/機関/個人が便宜のために区分したものであるので、自体的に責任を負わなければならない。電子文書流通システム内で電子アドレスが有する意味は、図3に示した電子文書流通システム参加者の関係図のように表現することができる。このように内部区分子と固有登録アドレスを有する電子アドレスに対してさらに整理すれば、次の通りである。1内部区分子-内部区分子は、アドレスディレクトリサーバとは関係なく、各送受信個体が自体的に発給し管理する。-内部区分子は、送受信個体内においては固有な値であるべきであり、省略可能な情報である。-内部区分子に対する付与方式は各企業/機関/個人が責任を持つことを基本とし、内部区分子による電子文書の配付も電子文書流通基盤のインフラ体系下で公式的な意味は持たない。-固有登録アドレスが受信に対する責任を負える政府/公共/法人/機関/団体/個人が3者流通可能な送受信個体にアカウントを開設し、公式的にアドレスディレクトリサーバに登録して使う個体であれば、内部区分子は企業の業務便宜のために電子文書を分配するための用途として使われ、アドレスディレクトリサーバに登録せず、企業内部の情報としてのみ使う。2固有登録アドレス-電子文書流通システムに参加して電子文書を流通しようとする政府/公共/法人/機関/団体/個人は、流通メッセージングサーバシステムを自体的に構築した後に送受信個体として固有登録アドレスの発給を受けるか、3者流通流通代行機関を介して固有登録アドレスの発給を受けなければならない。-固有登録アドレスは、発給時点でアドレスディレクトリサーバに固有登録アドレスの唯一性uniquenessを確認することにより、重複して発給されないように管理される。-政府/法人/機関/団体/個人の固有登録アドレスの構成方式は、公認電子アドレス管理総括の政策によって決定される。上述したような電子アドレスは基本的に2-levelによって管理される。公認電子アドレスの最上段にはアドレスディレクトリサーバを管理する公認電子アドレス管理総括例:情報通信産業振興院があり、公認電子アドレス管理総括は、下位送受信個体に対する固有登録アドレスを発給し、これを管理する。公認電子アドレス管理総括の下位送受信個体中の3者流通流通代行が可能な送受信個体は、3次流通を望むユーザに対する登録アドレスを開設した後、これに対するアドレス情報をアドレスディレクトリサーバに登録する。この時、ユーザ固有登録アドレス値の唯一性uniquenessを保障するために、必ずアドレスディレクトリサーバに重複有無を確認するべきである。電子アドレス中、公式的なユーザではなく、内部で業務便宜のために発給して使う内部区分子は、アドレスディレクトリサーバとは関係なく、各送受信個体が自体的に発給し管理する。電子アドレスを発給する体系は図4の通りであり、図4に示す各構成要素の役割は下記表184の通りである。電子アドレスを発給するプロセスは図5の通りであり、ユーザ企業が直接アドレスディレクトリサーバが提供する画面に接続してアドレスを登録したり修正したりする方法と、公認電子アドレスを代行発給する流通メッセージングサーバシステムシステムが提供するウェブサイトを介して発給を受ける方法がある。流通に参加するユーザは、相手方にメッセージを転送する前に電子アドレス情報に基づいて物理的な実アドレス情報を必ず知るべきであり、付加的に添付する文書を暗号化するためには受信者の公開キー情報も獲得しなければならない。電子文書流通プロセスにおいて、電子アドレスの物理アドレスを獲得する手続きは必須ステップであって、送信者は、受信者のアドレス情報を基準に受信相手方に対する物理アドレス情報および保安情報の獲得のためにアドレスディレクトリサーバに問い合わせる。この物理アドレスを基準に送信者が受信者に転送文書を伝達すれば、受信者の流通メッセージングサーバシステムは、これを受け、受信者のアドレス情報を基盤にユーザアカウントまたは内部区分子に応じて受信文書を内部的に分配する。電子アドレスの物理アドレスおよび保安情報の獲得プロセスは図6の通りである。電子文書流通において、公認電子アドレスを基盤に受信者に文書を転送するためには、1流通クライアントAPPが受信相手方のアドレス情報を入力する時点で、アドレスディレクトリサーバに連係して必要情報を獲得した後、検索された実の物理アドレス情報に基づいて流通メッセージングサーバに転送要請をする方法と、2流通クライアントAPPが受信者に対する公認電子アドレスを基盤に流通メッセージングサーバに転送要請をし、流通メッセージングサーバが転送前にアドレスディレクトリサーバに物理アドレスおよび保安情報を獲得した後、受信者に文書を転送する方法がある。このような2つの方法に対する手続きは図7に示す通りである。アドレスディレクトリサーバは、流通メッセージングサーバシステムがアドレス情報を検索したり、アドレス発給を代行したりできるように遠隔サービスを提供する。アドレスディレクトリサーバが提供するサービスはアドレス検索サービス、アドレス登録サービス、アドレス変更サービスがあり、流通プロトコル規格を基盤に次のようなサービスインターフェースを提供する。アドレス検索サービスは、アドレスディレクトリサーバが公認電子アドレスに該当する物理アドレス情報例:IPアドレス、Domainアドレスと公開キー情報を検索要請者に返すサービスであって、一般的に送信者が文書を転送する前に受信者の実際アドレス情報と暗号化のための保安情報を獲得するために使う。この時、要請メッセージと応答メッセージの役割は下記表185の通りである。アドレス登録サービスは、アドレスディレクトリサーバが提供するUIを通じてだけでなく、遠隔からもユーザの公認電子アドレスを登録できるように提供するサービスであって、ユーザ情報および公認電子アドレス情報を要請メッセージとして受けてアドレスディレクトリサーバが登録処理した後、これに対する結果を応答メッセージとして受信する。アドレス登録サービスに対する要請メッセージは必ず要請者に対する電子署名情報が含まれて伝達されるべきであり、アドレスディレクトリサーバは、要請メッセージに含まれたユーザ情報と電子署名に使われた認証書情報が同一であるかを検証しなければならない。この時、要請メッセージと応答メッセージの役割は下記表186の通りである。アドレス変更サービスは、登録されたユーザに対するアドレス情報を遠隔から直接ユーザが変更できるようにする機能を提供する遠隔サービスで、変更するべき情報を含んでアドレスディレクトリサーバに変更要請メッセージを転送し、これに対する結果を応答メッセージとして受信する。アドレス変更サービスに対する要請メッセージは必ず要請者に対する電子署名情報が含まれて伝達されるべきであり、アドレスディレクトリサーバは、要請メッセージに含まれたユーザ情報と電子署名に使われた認証書情報が同一であるかを検証しなければならない。この時、要請メッセージと応答メッセージの役割は下記表187の通りである。"