电子文档流通系统和电子文档流通方法与流程

本发明涉及电子文档流通系统和电子文档流通方法，该电子文档流通方法可构造不仅为企业/机构而且为个人和小公司提供可靠性的电子文档流通系统。

背景技术：
一般，基于企业/机构的个体独特规定，电子文档流通仅在特定行业集团或者社团中限制性执行。此外，存在的问题在于，电子邮件用作一般个人之间或者个人与企业/机构之间的辅助手段而没有考虑可靠电子流通概念，或者仅在个人、个体企业或者小公司访问企业网站时进行在线交流。因此，可以预期，不仅可拥有预定规模流通系统的企业，而且个人、个体企业或者小公司可建立基于电子文档流通的基础设施，该基础设施保证流通可靠性。

技术实现要素：
【技术问题】本发明致力于提供不仅允许可拥有预定规模流通系统的企业/机构而且还允许个人和小公司建立可靠性的电子文档流通系统和电子文档流通方法。【技术方案】根据本发明示例性实施方式的电子文档流通系统包括：收发实体，基于电子邮件地址发送和接收消息并且通过流通通讯服务器来流通电子文档，所述流通通讯服务器发行和管理消息发送/接收的流通证书；流通中心，登记/管理收发实体的电子邮件地址、设定收发实体之间的电子文档流通路径、将电子文档的标准格式提供给收发实体、当在收发实体之间流通电子文档的过程中发生错误时通过代理服务器发送消息并发行流通证书；以及可靠的第三方存储机构，接收和存储流通证书。在根据本发明示例性实施方式的电子文档流通系统中，在包括收发实体和流通中心的电子文档流通系统中流通电子文档的方法包括以下步骤：（a）步骤：允许发送实体获取与接收实体的地址信息对应的物理地址信息并然后将带有附加电子文档的消息发送到物理地址；（b）步骤：允许接收消息的接收实体根据接收消息与发送实体的兼容性验证结果来发行接收证书或者错误证书，且将证书传送到收发实体；以及（c）步骤：允许发送消息到接收实体但发送失败的发送实体请求流通中心通过代理服务器发送消息，且允许接收用于通过代理服务器发送消息的请求的流通中心发行发送证书，以将证书传送到发送实体且将消息发送到接收实体，且然后执行步骤（b）。【有益效果】具有上述构造和方法的本发明可建立不仅允许企业/机构而且允许个人和小公司建立可靠性的电子文档流通系统。附图说明图1为示出了根据本发明示例性实施方式的电子文档流通系统的构造示例的示图。图2为示出了图1的流通通讯服务器的示图。图3为示出了图1的流通客户端的示图。图4为示出了图1的地址目录服务器的示图。图5为示出了图1的电子文档格式寄存器的示图。图6为示出了图1的流通中继服务器的示图。图7为示出了图1的外接网关的示图。图8为示出了图1的电子文档流通系统中认证电子邮件地址的实施范围的示图。图9为示出了根据本发明示例性实施方式的认证电子邮件地址的申请/发行和操作系统的示图。图10、图11和图13为示出了在本发明示例性实施方式中流通电子文档时消息安全性的示图。图14至图17为示出了在本发明示例性实施方式中消息收发处理器的示图。图18为示出了根据本发明示例性实施方式的物理地址获得过程的示图。图19至图21为示出了根据本发明示例性实施方式的流通中继支持过程的示图。图22至图24为示出了根据本发明示例性实施方式的诸如认证电子邮件地址登记的管理过程的示图。图25和图26为示出了根据本发明示例性实施方式的电子文档格式申请过程的示图。图27是示出了根据本发明另一示例性实施方式的当收发实体用作接收器时在电子文档流通集线器报告垃圾消息的处理的示图。图28是示出了根据本发明另一示例性实施方式的当收发实体用作接收器时用于检查是否实时地拒绝接收通信方的处理的示图。图29是示出了根据本发明另一示例性实施方式的当收发实体用作接收器时用于定期地检查是否实时地拒绝接收通信方的处理的示图。图30和图31为根据本发明示例性实施方式的电子文档读取服务的概念图。图32为根据本发明示例性实施方式的外接网关服务器的概念图。图33为示出了在本发明示例性实施方式中流通连接到外部系统的电子文档的过程的示图。图34至图36是示出了根据本发明示例性实施方式的垃圾消息处理过程的示图。图37-51是示出了根据本发明另一个示例性实施方式的流通消息服务器系统的示图。图52-56是示出了根据本发明另一示例性实施方式的应用于电子文档流通系统和方法的通信协议的示图。图57和图58是示出了根据本发明另一示例性实施方式的电子文档形式寄存器的示图。图59是示出了根据本发明另一示例性实施方式的应用于电子文档流通系统的电子文档打包的示图。图60-66是示出了根据本发明另一示例性实施方式的流通客户端应用的示图。具体地，图65是示出了根据本发明另一示例性实施方式的用于认证流通消息服务器系统以作为认证的电子邮件地址被登记的处理的示图。图67至图71为示出了在根据本发明示例性实施方式的电子文档流通系统下用于使元件操作为彼此链接以流通电子文档的通信协议的配置的示图。图72至图76为示出了在根据本发明示例性实施方式的电子文档流通系统下错误处理方法的示图。图77至图84为示出了在根据本发明示例性实施方式的电子文档流通系统中流通通讯服务器和地址目录服务器之间的连接接口的示图。图85至图99为示出了在根据本发明示例性实施方式的电子文档流通系统中流通通讯服务器之间的连接接口的示图。图100至图115为示出了在根据本发明示例性实施方式的电子文档流通系统中流通客户端和流通通讯服务器之间的连接接口的示图。图116至图118为示出了在根据本发明示例性实施方式的电子文档流通系统中流通通讯服务器和流通中继服务器之间的连接接口的示图。图119A为示出了表37的邮政流通系统的示图，图119B为示出了表37的电子邮件流通系统的示图，图119C为示出了表37的电子文档互换（EDI）流通系统的示图，以及图119D为示出了表37的工作相关系统流通系统的示图。图120A为示出了表38的自动处理方法的示图，以及图120B为示出了表38的半自动处理方法的示图。图121A为示出了表39的网站（web）方法的示图，以及图121B为示出了表39的应用程序方法的示图。具体实施方式【最佳实施方式】下文中，将参考附图和表描述根据本发明示例性实施方式的电子文档流通系统和电子文档流通方法。图1示出了根据本发明示例性实施方式的电子文档流通系统的构造示例。参考图1，根据本发明示例性实施方式的电子文档流通系统包括：收发实体101，通过流通通讯服务器来流通电子文档，所述流通通讯服务器基于电子邮件地址发送和接收消息，且发行和管理消息发送/接收的流通证书；电子文档流通中心102，登记/管理收发实体101的电子邮件地址、设定收发实体101之间的电子文档流通路径、将电子文档标准格式提供给收发实体101以及当在收发实体101之间流通电子文档过程中发生错误时，由收发实体的代理服务器发送消息且发行流通证书；以及可靠的第三方存储机构（认证电子文档存储器）103，接收和存储流通证书。收发实体101的流通通讯服务器将发送/接收消息与每个用户的状态信息一起存储于消息箱中，并将消息发送和接收记录存储于在预定时段内无法编辑和删除的介质中，且发行消息发送和接收的流通证书以请求第三方存储机构存储流通证书。流通通讯服务器与地址目录服务器连接，以允许收发实体101使用登记、搜索、编辑和删除电子邮件地址的功能。此外，流通通讯服务器将已存储达预定时间段以上的消息转移到外部存储装置来存储。电子邮件地址包括：收发实体101的用户识别标记，其通过电子文档流通中心102的地址目录服务器发行；附加识别（identification），其为需要时由收发实体101自主赋予的唯一值且为收发实体101中的唯一值；以及分割符号，位于用户识别标记和附加识别标记之间。电子文档流通中心102包括电子文档格式寄存器。电子文档格式寄存器执行包括电子文档标准格式信息登记、删除和编辑的管理。此外，电子文档格式寄存器另外根据上下文（context）对电子文档标准格式分类，且执行包括对使用电子文档标准格式的上下文进行的登记和编辑的管理。电子文档流通中心102包括流通中继服务器，当在收发实体101之间流通电子文档过程期间发生错误时，流通中继服务器通过代理服务器发送消息，且发行流通证书。当收发实体101请求流通中继服务器发送消息时，在通过代理服务器发送消息之后，流通中继服务器发行发送证书到请求发送消息的收发实体101。如果所请求消息发送失败，那么流通中继服务器发送错误消息到请求发送消息的收发实体101。电子文档流通中心102包括与外部系统连接的外接网关服务器。外接网关服务器包括流通通讯服务器，该流通通讯服务器基于电子邮件地址发送/接收消息。外接网关服务器提供外接系统和电子文档流通系统之间的发送/接收电子邮件地址验证/转换功能、外接系统和电子文档流通系统之间的消息验证/转换功能、应用于外接系统和电子文档流通系统之间的电子文档的安全性验证/转换功能以及验证和转换外接系统和电子文档流通系统之间的电子文档兼容性的功能。将参考图1至图118详细描述根据本发明示例性实施方式的具有上述构造的电子文档流通系统及使用该电子文档流通系统的电子文档流通方法。在本发明的详细描述中，将省略图1的参考标号。【电子文档流通系统的结构】为了保证电子文档流通的可靠性和稳定性，根据本发明的电子文档流通系统需要满足以下要求（1）至（7）。（1）参与流通系统的收发实体和发送方/接收方需要使用预定方法发送/接收电子文档，且同意管理机构或者电子文档提供商的服务等级协议（SLA）。（2）允许对参与流通系统的收发实体和认证发送方/接收方进行识别，且需要防止电子文档流通动作被拒绝。（3）作为用于区别流通系统中收发实体和认证的发送方/接收方的信息的认证电子邮件地址需要以公司或者个人为单位给出，且通过登记机构来登记和管理。（4）当在流通系统中流通电子文档时，需要生成流通证书，且将流通证书发送并存储于参与流通动作的发送实体以及第三方存储机构中。（5）即使所有电子文档流通动作都基于P2P（点对点）通信执行，也需要提供由于各种环境因素导致通信失败时支持流通的系统。（6）不仅需要支持流通系统中各方之间的电子文档交换，而且需要支持诸如电子文档读取服务的各种附加服务。（7）需要提供支持与除流通系统外的外部系统连接的网关。基于认证的电子邮件地址以及在具有流通通讯服务器的收发实体之间发送/接收电子文档的P2P通信来执行根据本发明的电子文档流通系统。图1中示出了根据本发明的电子文档流通系统的结构，且系统中的元件将在下表1和表2中描述。此外，主要过程将在下表3中描述。【表1】【表2】【表3】【电子文档流通系统的元件】（1）流通通讯服务器流通通讯服务器为设置于收发实体中的通讯系统，且在电子文档流通中起着核心作用。流通通讯服务器需要在物理上具有一个电子邮件地址（IP地址），但是发行和管理较低级别用户的多个用户账户。为了管理用户账户，流通通讯服务器需要管理每个用户账户的消息箱。流通通讯服务器负责安全可靠地管理用户的账户和消息箱。流通通讯服务器的功能概念示于图2中，且其功能将在下表4中描述。【表4】除表4中描述的功能外，以下（1）到（4）原理需要在服务器系统管理中遵守，以提高流通通讯服务器的可靠性。（1）系统管理者无法看到或者主动删除个人的消息箱。（2）与服务器系统管理相关的记录信息在10年或者更长年限内无法主动删除且存储于不变介质中。（3）系统管理者无法主动更改认证流通通讯服务器解决方案的基本功能。（4）需要创建与系统管理相关的操作准则，且需要根据准则执行管理。（2）流通客户端流通客户端为代表参与流通系统中的发送方/接收方提供UI（用户界面）的应用程序，诸如消息发送和接收、接收电子文档的读取和管理。流通客户端无法独立发送/接收文档，且需要不可避免地与流通通讯服务器连接。流通客户端请求通过流通通讯服务器发送消息或者查询通过流通通讯服务器接收到的消息。流通通讯服务器管理每个用户账户的消息箱。流通客户端需要通过检查用户账户信息只访问所接收文档中存储于其自己账户中的消息。根据收发实体的请求，流通客户端可实施为C/S型应用程序或者web型屏幕。流通客户端的功能概念在图3中示出，且其功能将在以下表5中描述。【表5】（3）地址目录服务器地址目录服务器为管理发送/接收实体以及经认证的发送方/接收方的地址信息并且提供物理地址的系统。地址目录服务器提供诸如以下功能（1）和（2）的基本功能：（1）管理和提供接收实体的流通通讯服务器的物理地址（IP地址）（2）管理诸如对经认证的电子地址的信息进行的登记和编辑功能另外，地址目录服务器基本上具有管理白名单信息的功能，且从用户接收关于垃圾消息的报告，且基于报告管理黑名单信息。地址目录服务器通过门户网站屏幕和流通通讯服务器将与认证电子地址相关的信息提供给收发实体或者经认证的发送方/接收方，且相关申请方可通过连接接口使用由地址目录服务器提供的服务。地址目录服务器的功能概念在图4中示出，且其功能将在以下表6中描述。【表6】（4）电子文档格式寄存器电子文档格式寄存器为由电子文档流通中心提供的系统，以使用收发实体之间的预定标准电子文档来自动处理或者利用电子表格型电子文档。电子文档格式寄存器提供：服务器引擎，其管理电子文档格式；接口，其提供允许流通客户端搜索和下载电子文档格式的功能；以及门户网站界面。电子文档格式寄存器的功能概念在图5中示出，且其功能将在以下表7中描述。【表7】（5）流通中继服务器流通中继服务器为设置于电子文档流通中心中以当在流通系统中进行收发实体之间的电子文档流通过程期间发生错误时，通过发送实体的代理服务器发送消息的系统。流通中继服务器具有作为流通通讯服务器的功能，以提供基本电子文档收发服务。此外，流通中继服务器为流通通讯服务器提供流通中继服务器的独特服务，诸如在最终失败的情况下通过连接接口进行的中继请求接收和错误消息发送。流通中继服务器的功能概念在图6中示出，且其功能将在以下表8中描述。【表8】（7）经认证的电子邮件地址收发实体以及参与流通系统中的认证发送方/接收方需要接收唯一认证的电子邮件地址。认证电子邮件地址由井号【#】、数字【0到9】、连字符【-】和句点【.】的组合构成。与认证电子邮件地址的构成系统相关的原理如以下（1）到（3）：（1）作为前部“#”，为了用户便利，可选择性使用由字符【A-Z】【a-z】、韩文字母表【完整韩文字母表，2350个字母】、数字【0-9】、连字符【-】和句点【.】组合构成的附加用户标识符。在此情况下，附加用户标识符可由电子文档流通通讯服务器管理。（2）认证电子邮件地址的附加用户标识符不应以连字符或者句点开头或者结尾，且其长度设定为30个字节或者更短。（3）作为认证电子邮件地址的附加用户标识符，可能不使用可能破坏社会习俗或者公共道德的字符和数字组合或者由管理机构负责人确定的其它受限符号。认证电子邮件地址和IP地址（其为实际物理地址（流通通信服务器的实际物理地址））之间的相关性关系只由地址目录服务器管理。认证电子邮件地址和流通通讯服务器的实际物理地址具有1：1或者N：1关系。因此，一个认证电子邮件地址不具有多个物理地址。紧邻“#”的公司/组织/个人应当负有接收认证电子邮件地址的信息（文档）的法律责任。此外，为了方便公司/组织/个人，根据附加用户标识符划分流通。因此，收发实体应当具有根据附加用户标识符流通的责任。在此情况下，收发实体需要准备与附加用户标识符对应的用户认证的策略和管理知识，且根据知识透彻管理用户认证。此外，当收发实体参与流通系统之前与管理机构签订关于SLA的协议时，收发实体需要包括具有内部标识符的认证电子邮件地址的内容。流通系统中认证电子邮件地址的实施范围将在图8中示出。附加用户标识符需要是收发实体的唯一值。单个收发实体基本上负责施加附加用户标识符。此外，收发实体负责根据附加用户标识符进行电子文档流通。因此，如果发生问题，那么收发实体需要解决问题。附加用户标识符不包括在流通系统的实施范围中，但可由具有管理代理的SLA定义。为了企业操作便利，附加用户标识符用于流通电子文档，且仅用于企业内部信息，而无需登记在地址目录服务器中。作为如上所述的认证电子邮件地址的其它示例，可允许以下结构。认证电子邮件地址=ID+分割符号+登记者这里，“ID”由英语（或者韩文字母表或者数字）、连字符【-】和句点【.】组合构成，“分割符号”为#，以及“登记者”由英语（或者韩文字母表或者数字）和句点【.】组合构成。“swconvergence#mke.go.kr”为认证电子邮件地址的示例。在以上示例中，“swconvergence”表示政府机构部门名称，“mke”表示政府机构，“go”表示属性，以及“kr”表示国家。认证电子邮件地址的申请/发行和操作系统在图9中示出，且与此相关的构造将在以下表11中描述。【表11】【消息安全性】流通系统中最重要部分之一为发送消息的安全性，其要求（1）防止发送/接收的拒绝，（2）发送消息的完整性保证，（3）发送方认证以及（4）发送消息的机密性保证。其中，（1）到（3）通过发送消息的发送方的数字签名来支持，且（4）通过加密发送消息来提供。当在流通通讯服务器之间流通电子文档时所应用的安全性（其为流通系统的基础）支持消息数字签名和加密，如图10所示。网络加密需要施加于每个部分以保护发送。内容的数字签名为每个应用程序的独特部分。其描述将省略。在本发明中，基本上，利用接收方公钥进行加密。如果没有接收方的认证证书，或者接收方为内部接收方，那么只可选择接收实体加密。此外，在消息发送期间，消息连同对消息的认证信息一起发送到流通通讯服务器。在此情况下，流通通讯服务器主要使用认证信息来认证客户端。此外，流通通讯服务器采用不同认证方法，诸如基于IP/PW的认证、基于令牌信息的SSO（单独签字）认证以及基于认证证书的数字签名，以认证流通客户端。下文中，将详细描述数字签名方法。当流通通讯服务器与其它系统（其它流通通讯服务器、地址目录服务器或者流通中继服务器）连接时，需要基于其自己的证书进行数字签名。用于连接流通系统中组成要素的所有流通消息基本上都被数字签名。然而，流通客户端和流通通讯服务器之间的数字签名为可选，且数字签名只应用于基于证书的用户认证方法。在此情况下，流通通讯服务器负责用户认证、完整性和防止拒绝流通客户端的流通消息的发送/接收。下文中，将详细描述加密方法。流通系统中附加文档可在发送方选择加密之后发送以保护文档，为了文档机密性执行加密，但是不同于网络加密。因此，在应用网络加密之后，可另外加密流通文档。待加密部分可为（1）从发送方的流通客户端到接收方的流通通讯服务器或者（2）从发送方的流通客户端到接收方的流通客户端，如图10所示。如果接收方为认证发送方/接收方，且证书登记在地址目录服务器中，那么在从发送方到接收方的部分（2）中进行加密。否则，在从发送方到接收实体的部分（1）中进行加密。当加密附加文档时，如果在从发送方到接收实体的部分（1）中保持加密，那么发送方需要加密文档，以在发送方的流通通讯服务器、接收方的流通通讯服务器以及接收方的流通客户端的三个步骤中解码文档。如果在从发送方到接收实体的部分（2）中保持加密，那么发送方需要加密文档，以解码发送方的流通通讯服务器以及接收方的流通通讯服务器。如果加密附加电子文档，那么发送实体和接收实体的流通通讯服务器在加密状态下存储电子文档，以管理记录。因此，如果发送方/接收方想要基于解码文档来验证流通证书，那么解码电子文档以验证流通证书。出于这个原因，流通通讯服务器需要一直管理撤销证书的私钥以及访问私钥的密码。下文中，将描述加密方法中加密的概要。如果发送方确定流通系统中正在流通的消息的机密性被确保，那么需要遵守以下加密处理。在国内外作为标准使用的以由IETFRFC3852“CMS（加密消息语法）”建议的内容信息结构为代表的封装包数据内容类型用作密文。※RFC3852CMS1）IETF为定义互联网操作协议标准（诸如TCP/IP）的主要代理。IETF由IAB（互联网架构委员会，互联网技术改进互联网协议的监督机构）监督。IETF成员从个人或者互联网协会组织成员选择。在IETF中创建的标准以RFC类型为代表，且基于RFC标准文档作出国内外许多基于PKI的解决方案（各种认证系统、时间戳或者第三方存储机构大小）。2）CMS（加密消息语法）基于由RSA公司首先创建的“PKCS#7v1.5”来创建。RFC2630利用由IETF标准化的RFC标准来创建。在第一PKCS#7中，只提供密钥传送（用于加密的对称密钥使用RSA交付给另一方）方法。与之相比，在RFC2630的CMS中，添加密钥协议（使用DH算法交付密钥的方法）。3）此后，在2002年建立RFC3369，其中分离算法部分且应用各种密钥管理方法。然而，报告出RFC3369的各种问题，因此最终修正版本为在本发明中应用的RFC3852。作为另外应用标准，在创建密文或者与算法对应的参数时，在内容加密（将实际发送的电子税务发票封装包）中使用的算法遵循IETFRFC3370“加密消息语法（CMS）算法”和IETFRFC4010“SEED加密算法在加密消息语法（CMS）中的使用”。下文中，将描述加密方法中的加密目标数据。参考图11，待交付消息的加密目标为以下（1）和（2）。（1）在第二MIME中输入的流通信息（2）输入主文本实际内容的消息体块的<文本>区以及附加文档消息体块中的文本以及附加文档被单独加密，且包括在相应位置中。第一加密目标为将交付给接收方的主文本内容，且在XML体块中<文本>部分中具有值。接着，将描述目标数据的配置方法。数据遵循ASN.1基本编码规则（BER），且遵守区分编码规则（DER）。下文中，将描述加密方法中加密证书的获得和验证。为了创建密文，需要获得解码实际数据的接收方侧证书。为了获得证书，发送方需要连接到地址目录服务器以获得接收方（或者接收实体）证书。在此情况下，根据所获得证书为接收实体的证书还是认证的接收方的证书，来改变保持机密性的部分。如果发送方选择发送消息加密，那么发送方基于所获得的接收方（或者接收实体）证书进行加密，且发送消息到接收方。即使在消息发送期间发生错误，使得请求流通中继中心发送消息，也发送消息而无需更改加密内容。【网络安全性】为了保持发送方和接收方之间流通的消息的机密性，SSL（安全套接字层）应用于（流通客户端与通讯发送方的流通通讯服务器之间、发送方和接收方的流通通讯服务器之间以及接收方的流通通讯服务器与接收方的流通客户端之间）的电子文档流通的所有部分，以用于网络安全性。【消息收发过程】流通系统中的当事方之间以及系统之间存在各种任务过程。在流通系统中存在最基本消息收发过程，且提供各种过程以支持基本消息收发过程。消息收发过程为在发送方和接收方之间直接发送和接收消息且与另一方交换文档（如邮件或者电子邮件）的过程。为了在发送方和接收方之间发送/接收消息，提供四个步骤的过程（1）获得接收方的物理地址和安全性信息，（2）发送消息和确认发送，（3）确认接收方接收任务以及（4）发行和存储流通证书。在此情况下，在流通证书的过程中，根据待证明的内容，可更改详细过程的流程。其基本流程在图14中示出，且在以下表22中详细描述。【表22】消息收发过程被分为发送过程和接收过程。此外，根据流通客户端和流通通讯服务器之间的连接方法，发送过程被分为同步发送和异步发送。下文中，将参考图15和表23描述同步消息收发过程。当发送实体的流通客户端请求流通通讯服务器发送消息时，同步消息收发过程为实时发送消息到接收实体的流通通讯服务器且从发送方的流通通讯服务器同步接收应答的过程。根据同步过程，流通客户端立即检查发送结果，使得可简化任务过程的定义。同步消息收发过程将在以下表23中详细描述。【表23】下文中，将参考图16和表24描述异步消息收发过程。当发送实体的流通客户端请求流通通讯服务器发送消息时，异步发送过程只验证发送请求对于流通通讯服务器的有效性，且然后返回请求的接收确认消息到流通客户端。消息实时发送到接收实体的流通通讯服务器，且通过发送实体的流通通讯服务器同步接收对其的响应。当发送消息费时时使用异步过程，使得客户端可以不等待响应，例如，当待发送消息量大或者一个消息指定多个接收方时。异步消息收发过程将在以下表24中详细描述。【表24】下文中，将详细描述消息接收过程。文档接收方通过流通客户端接收消息的过程在图17中示出，且将在以下表25中描述过程。当接收方的流通通讯服务器从发送方接收消息时，流通通讯服务器发送接收证书作为其响应，且将文档存储于最后接收方的消息箱中。流通客户端频繁请求接收消息列表到流通通讯服务器。如果有新接收消息，那么流通客户端接收接收消息列表作为响应消息，且通过请求保留消息的消息获得接收文档。【表25】【物理地址获取过程】参与流通系统的发送实体在发送消息到另一方之前需要基于认证电子邮件地址获悉实际物理地址信息。此外，为了加密要另外附加的文档，发送实体需要知道地址目录服务器中接收方的公钥信息。获取认证电子邮件地址的物理地址的基本步骤如下1）到4）：1）发送实体查询地址目录服务器，以获得物理地址信息以及基于接收实体的地址信息获得安全性信息2）地址目录服务器接收/验证发送实体的查询，且然后处理查询3）发送实体基于所接收物理地址设定路径，以发送消息到接收实体4）接收实体的流通通讯服务器接收消息，以根据用户账户或者内部标识符在内部流通消息此外，在流通系统中获得认证电子邮件地址的物理地址的方法分为以下两个方法（1）和（2）。（1）在流通客户端输入接收方地址信息时，请求地址目录服务器搜索以获得物理地址和接收方公钥的方法：1）以事先检查认证电子邮件地址的有效性，2）当流通客户端和流通通讯服务器（发送实体）之间需要消息加密时（2）在流通客户端请求流通通讯服务器发送消息之后，流通通讯服务器从地址目录服务器获得物理地址的方法获得认证电子邮件地址的物理地址以及安全性信息的过程在图19中示出。【流通中继支持过程】流通系统基本上执行发送实体和接收实体之间的直接通信（P2P）。然而，另外，如果由于网络以及接收实体的流通通讯服务器的错误而在消息流通中发生故障，那么提供通过代理服务器中继/执行流通的中继过程以为了用户便利以及稳定支持流通。当由于从发送实体发送消息到接收实体的过程中发生错误，而发送失败时，电子文档流通中心中的流通中继服务器通过发送实体的代理服务器委托/发送消息，以证实发送实体的发送且减轻发送实体的系统负担。图23示出了其基本流程，以及图24示出了流通中继服务器中继消息的过程。以下表26描述流通中继过程的步骤。【表26】【流通证书的存储过程】作为与流通系统中执行的所有流通动作相关的结果，流通证书不可避免地创建，从而存储于第三方存储机构中。这是因为，可以通过将具有流通证据的流通证书存储于法律认可的第三方存储机构中来建立法律推定。存储流通证书的过程是与电子文档流通分开的过程，但是为证实流通动作事实的支持过程。因此，所有流通通讯服务器需要成为能够预先接收和存储流通证书的特定第三方存储机构成员。此外，如果发送实体想要电子文档内容的认证，那么除流通证书之外，实体消息可存储于第三方存储机构中。第三方存储机构需要包括以下两个另外系统（1）和（2），以接收和存储流通证书。（1）第三方存储机构提供商的流通通讯服务器：流通系统中用流通通讯服务器收发流通证书所需的系统（2）第三方存储机构连接客户端模块：与第三方存储机构连接接口通信以通过第三方存储机构提供商的流通通讯服务器将所接收的流通证书存储于第三方存储机构中的模块然而，如果第三方存储机构提供商也充当电子文档提供商，那么可以不另外需要流通通讯。图28示出了存储收发实体和第三方存储机构提供商之间的流通的过程，且流通证书存储过程的步骤将在以下表27中描述。【表27】【管理过程，诸如认证电子邮件地址的登记】收发实体需要申请和登记认证电子邮件地址以参与流通系统，且登记机构和管理机构需要登记和管理与认证电子邮件地址相关的信息。认证电子邮件地址管理过程包括与认证电子邮件地址相关的诸如登记、变更和删除的管理过程以及黑名单/白名单管理过程。管理机构允许认证电子邮件地址登记机构管理认证电子邮件地址，以有效管理认证电子邮件地址。登记机构执行以下任务（1）到（4）。（1）检查任务，诸如认证电子邮件地址的申请人识别（2）认证电子邮件地址登记方的登记信息变更任务（3）任务支持，诸如认证电子邮件地址的登记取消（4）与认证电子邮件地址的管理相关的其它任务管理机构可选择满足要求的第三方存储机构以及电子文档提供商中任何一个作为登记机构。下文中，将描述登记认证电子邮件地址的过程。想要参与流通系统的企业/机构/个人需要申请认证的电子邮件地址，且登记机构检查和处理申请信息并通知结果。相关过程在图22中示出。下文中，将描述变更认证电子邮件地址的登记信息的过程。即使与已经登记的认证电子邮件地址相关的信息由于各种原因变更，身份需要保持，以使得拥有者的电子邮件地址和信息未变更。用于变更与认证电子邮件地址相关的信息的权限授权给登记机构处理。在此情况下，关于信息变更的记录信息需要根据管理机构和登记机构之间的服务级别协议（SLA）来存储。与其相关的过程在图23中示出。参考图23，只可通过当事方变更认证电子邮件地址。在个人情况下，认证电子邮件地址、登记号和名称无法变更。因此，个人撤销认证电子邮件地址，且然后新创建新地址。在企业情况下，认证电子邮件地址无法变更。如果登记号（营业执照号码）和企业名称变更，那么需要利用相应信息变更时接收的新证书来变更认证电子邮件地址。图24示出了变更登记机构的过程。参考图24，如果登记机构变更，那么需要执行1）从现有登记机构的撤销过程；以及2）通过新登记机构的新登记过程。在此情况下，需要请求地址目录服务器暂时保持认证电子邮件地址。当撤销所有认证电子邮件地址时，认证电子邮件地址被选择性暂时保持，使得当登记机构变更时，地址目录服务器可将认证电子邮件地址保存一预定时段。下文中，将描述更新、暂停和删除认证电子邮件地址的过程。已经登记的认证电子邮件地址需要根据设定使用期限来更新。在登记认证电子邮件地址之后，拥有者需要在基于服务策略结束设定的使用期限之前更新认证电子邮件地址。如果拥有者未更新认证电子邮件地址，那么拥有者失去认证电子邮件地址的所有权，且认证电子邮件地址自动取消。此外，即使认证电子邮件地址还未到期，如果登记者想要停止使用或者取消电子邮件地址，那么需要提供此功能。【电子文档格式申请过程】这个过程的目的在于，在流通消息之后增加使用率。根据这个过程，包括在消息中的电子文档在企业内部系统中被自动或者半自动处理。流通通讯服务器只在当事方之间进行收发，且流通客户端提供接口，以使得发送方/接收方容易使用待收发消息。在随后步骤中，利用消息中的电子文档。电子文档格式寄存器或者电子文档格式提供有效操作电子文档使用步骤的方法。根据流通系统流通的文档类型没有特定限制。图像、办公文档或者电影是可以使用的。然而，为了提高用户便利性，在流通系统中另外建议以文本形式创建文档的功能。上述附加功能引入电子文档交换功能，以使得基于收发实体之间约定的电子文档格式收发文档数据，以自动转换通过接收实体的内部系统接收的电子文档。以下两个方法（1）和（2）可用于电子文档格式。（1）利用电子文档流通中心中的电子文档格式寄存器的方法。主要使用标准化电子文档，诸如电子税务发票（2）共享通过收发实体之间协议获得的电子文档格式的方法。主要使用为特定企业指定的非标准化电子文档下文中，如下将详细描述电子文档格式寄存器的使用。在搜索登记在电子文档格式寄存器中的电子文档格式之后，企业、组织或者个人用户将电子文档格式登记于流通客户端中以使用电子文档格式。通过以下两个方法（1）和（2）使用电子文档格式寄存器。（1）在电子文档格式寄存器中直接搜索电子文档以从流通客户端导入电子文档的方法（2）从电子文档格式登记网站搜索电子文档并将电子文档下载在本地PC中，且然后将电子文档登记于流通客户端中以使用电子文档的方法因为电子文档格式寄存器登记/利用标准化电子文档格式，所以管理机构需要系统地操作/管理电子文档格式寄存器，且电子文档格式寄存器可具有以下标准（1）到（3）。（1）用户需要通过电子文档格式登记网站申请。需要根据网站提供的格式和程序进行申请。（2）登记/申请的电子文档需要通过管理机构检查来登记（3）个人电子文档需要基于系统上下文来分类【表28】图25示出了利用电子文档格式寄存器的过程的基本流程。具体地，图25A示出了电子文档格式寄存器与流通客户端直接连接，且图25B示出了使用电子文档格式寄存器网站。在以下表29中，描述利用直接连接到流通客户端的表格的过程。【表29】在以下表30中，描述利用电子文档格式寄存器网站的过程。【表30】下文中，将描述协定的电子文档格式的使用。使用协定的电子文档格式以流通为企业操作的网站中的特定企业指定的格式，以和与特定企业相关的各方做生意。图26示出了使用协定的电子文档格式的过程，且与图26相关的过程将在以下表31中描述。【表31】【垃圾消息处理过程】在流通系统中，发送方通过认证的流通通讯服务器执行发送，且接收方通过认证的流通通讯服务器执行接收。因此，如果发送垃圾邮件，那么流通系统具有使发送方负责的基础设施。然而，特定发送方可在电子文档提供商中建立用户账户，且使用用户账户发送商业信息。当前验证方法只可验证系统的技术内容，使得在初级阶段难以根除垃圾消息。为了阻止垃圾消息流通，流通系统提供基于认证名单管理的白名单或者具有恶意企图的黑名单（诸如垃圾邮件），以提高流通系统的安全性和可靠性。报告垃圾消息并确认发送方的功能为基本功能。因此，所有流通通讯服务器必须建立所述功能。下文中，将描述报告垃圾消息的方法。垃圾消息报告过程的步骤将在以下表32中描述。【表32】如果接收方确定接收消息为垃圾消息，那么接收方通过图27所示的过程将垃圾消息报告给地址目录服务器。白名单和黑名单的作用如下：（1）白名单：仅记录被发送流通通讯服务器认证且正式登记的通讯服务器信息（2）黑名单：如果发送方地址登记为垃圾发送方，那么发送方登记为黑名单如果通过同一流通通讯服务器登记于黑名单中的垃圾邮件地址重复生成，那么管理机构确定取消流通通讯服务器认证，取消认证以及从白名单删除垃圾邮件地址。下文中，将描述当接收垃圾消息时的处理方法。当接收消息时，接收实体检查地址目录服务器的白名单和黑名单，以确认发送方是否为可靠且合法的用户，且然后确定是否拒绝接收。在接收消息时可实时检查发送方，或者通过作为接收方的流通通讯服务器中的缓存来管理的定期检查方法来检查发送方。（1）实时检查过程：接收实体在接收消息时确定发送实体的地址是否登记于地址目录服务器中的白名单和黑名单中，且然后确定是否拒绝接收。【表33】图28示出了实时检查垃圾消息的过程。（2）定期检查过程：接收方从地址目录服务器定期接收白名单和黑名单，且据此自主管理和确定发送方地址是否登记于白名单和黑名单中，且然后确定是否拒绝接收消息。【表34】图29示出了定期检查过程以管理流通通讯服务器和地址目录服务器之间的垃圾消息。【错误处理过程】流通系统中发生的错误类型分为以下（1）和（2）。（1）同步响应的错误发生：在同步响应错误的情况下，请求方等待，直至接收到请求消息的处理结果，使得请求方立即通知错误（2）异步响应的错误发生：请求方发送请求内容，且随后接收请求的处理结果，使得需要另外错误处理。下文中，将描述同步错误处理方法。因为同步发送的所有错误都可被发送方立即检查到，所以基本上重新发送消息。根据参与流通系统的企业或者机构的系统策略来确定重新发送方法。然而，基本上，如果发送相同消息，那么设定相同消息ID值来发送消息。同步错误处理类型为如下（1）到（4）：（1）请求消息发送失败：在由发送方发送消息的过程中发生发送错误，使得请求消息未发送到接收方。发送方通过发送重试的超时或者网络错误消息来通知发送失败。（2）响应消息接收失败：即使发送方正常发送消息，在从接收方接收响应消息的过程中发生错误。响应消息接收失败没有与（1）“请求消息发送失败”区分开，使得通过相同方法处理错误，但是因为接收方正常接收请求消息，所以处理方法不同。（3）错误消息接收：即使发送方正常发送消息，但在由接收方处理消息的过程中发生错误。在此情况下，可根据错误消息类型，改变发送方的处理方法。（4）三级同步错误：其中流通客户端通过流通通讯服务器与另一个流通通讯服务器、地址目录服务器和流通中继中心连接的三个实体之间的消息流通支持连接类型中的同步连接方法，以立即检查最终结果。在这个过程中，如果在连接流通通讯服务器和接收方的步骤中发生错误，那么流通通讯服务器立即发生错误，且然后将错误作为响应消息发送到流通通讯服务器。下文中，将描述异步错误处理方法。其中流通客户端通过流通通讯服务器与另一个流通通讯服务器、地址目录服务器和流通中继中心连接的三个实体之间的消息流通可支持异步方法中的连接，使得流通客户端根据最后接收方的情况独立地操作。发送方可以不立即检查异步发送的最终错误，异步发送不同于同步发送。因此，在最终检查错误时针对流通客户端生成错误消息，以允许流通客户端接收错误消息。【电子文档读取服务】电子文档读取服务为提供存储于发送方系统或者第三方存储机构中待读取的电子文档而不是在发送方和接收方之间直接交换电子文档的服务。电子文档读取服务实际上使用现有流通系统。在此情况下，发送方不是将包括电子文档的消息，而是包括读取存储于发送方系统或者第三方存储机构中的电子文档的读取权限的消息发送到接收方。与其相关的程序为如下。（1）接收方公钥获得（2）电子文档存储（3）应用安全性的证书创建，安全性诸如有读取权限和DRM（4）读取权限证书发送和发送确认（5）接收方对电子文档的读取（6）流通（读取）证书或者读取证据的发行和存储电子文档读取服务可分类为发送方使用其自己系统的方法和发送方使用第三方的方法。图30示出了发送方使用利用自己系统的电子文档读取服务的流程，且图30中示出的程序将在以下表35中描述。【表35】为了提供上述服务，发送方需要包括能够提供电子文档读取服务的系统以及流通系统。图31示出了发送实体利用第三方来使用电子文档读取服务的流程，且图31中示出的程序将在表36中描述。【表36】【企业中与系统的连接方法】企业/机构内部创建和存储各种电子文档，且通过各种方法与外部企业/机构交换电子文档。可通过离线（诸如邮件）或者通过电子邮件或者工作相关系统来交换电子文档。当连接到企业/机构内部时，流通系统如表37和图119中示出那样相互连接。【表37】基于认证电子地址的流通系统可通过以下方法与企业/机构内部连接。下文中，将描述与内部系统连接的方法。当企业或者机构安装流通通讯服务器并将内部系统中流通客户端开发为系统集成（SI）时，主要使用与内部系统连接的方法。细节将在以下表38中描述，且其附图在图120中示出。【表38】下文中，将描述未与内部系统连接的方法。未与内部系统连接的方法适用于从电子文档提供商接收用户账户以使用用户账户的认证发送方/接收方，且是这样一种方法：即，使用由电子文档提供商提供的web型流通客户端或者将由电子文档提供商流通的流通客户端应用程序安装于本地PC中以使用流通客户端应用程序的方法。细节将在以下表39中描述，且附图在图121中示出。【表39】根据web方法、用户访问和处理网站，个人用户不需要将程序安装于本地PC中。根据应用程序方法，个人用户下载安装程序且将程序安装于本地PC中，以访问流通通讯服务器来使用程序。在根据如上所述的本发明示例性实施方式的电子文档流通系统和电子文档流通方法中，为了流通电子文档，需要诸如流通通讯服务器、流通客户端和流通中继服务器的组件，且在电子文档流通的整体流程中这些组件需要相互连接。因此，这些组件被操作为相互连接，并且需要定义用于连接的通信协议、消息交换方法和连接消息结构。下文中，定义用于组件之间连接的共同基础通信协议和消息交换方法，且根据连接类型的消息结构被定义为所建议的标准。因此，本发明允许在不同环境下且通过不同开发方法和互操作性建立的组件之间的平滑连接。【连接的基本通信协议】在基于认证电子地址的电子文档流通系统下，在组件之间流通信息和电子文档所需的电子文档流通连接接口中，流通连接消息是基于“ebXML消息服务v2.0标准”（下文中，称为ebMS），且分层扩展定义为更广义形式。基于ebXML的结构由独立但有密切关系的诸如SOAP、带附件、安全性和可靠性的SOAP的元素构成。“连接的基本通信协议”（下文中，基本通信协议）定义流通系统中基于这些基本元素所需且被构造为元素被有机重组的形式的元素。基本通信协议通过形成消息的封装、消息封装包配置、消息安全性以及发送和接收消息的消息收发来构成。下文中，将描述基本协议配置中的消息封装。流通连接消息的整个消息结构应用ebMSv2.0标准。基本通信协议中定义的消息具有两个逻辑MIME部分。第一MIME部分被称为标头容器，且包括SOAP消息。SOAP消息由标头和体块构成。第二或者后续MIME部分被称为净荷容器，且包括应用程序级消息和附加文档。以下将详细描述第一MIME部分。在本部分中，描述用于流通消息（消息的路由相关信息、SOAP消息交换模式、数字签名、错误信息以及在第二时间添加的数据位置信息）的共同信息。第二MIME部分将对每个连接接口的请求以及响应消息附加。根据连接接口类型，确定第三或者后续MIME部分存在性。当使用流通系统交付电子文档或者证书时，第二MIME包括在第三MIME部分中。流通连接消息的基本构造在图67中示出。参考图67，（1）“SOAP-ENV：标头”由根据流通协议标准的消息标头和签名信息构成，（2）“SOAP-ENV：体块”包括由流通协议标准定义的Manifest组成要素信息和用户登录信息，（3）“发送容器#1（净荷容器#1）”包括请求消息和响应消息。根据连接接口类型以及请求、响应或者错误消息的存在性来定义业务文档的详细内容，以及（4）在“发送容器#2（净荷容器#2）”中，根据连接接口类型将待附加的文档从净荷容器#2按顺序输入。下文中，将描述基本协议配置中的消息封装包配置。所有扩展元素的内容需要限制于基于SOAP标准的可用名称空间。本发明中定义的所有ebXMLSOAP扩展元素的内容需要限制于ebXMLSOAP封装包扩展名称空间。名称空间的申明可包括在SOAP封装包、标头或者体块元素中，或者直接包括在每个SOAP扩展元素中。SOAP封装包将SOAP消息中各种名称空间申明为SOAP消息的根项目。待申明名称空间为如下。【表44】项目名称空间URLSOAPhttp://schemas.xmlsoap.org/soap/envelope/数字签名http://www.w3.org/2000/09/xmldsig#Xlinkhttp://www.w3.org/1999/xlinkXsihttp://www.w3.org/2001/XMLSchema-instance消息封装包的架构结构在表35中示出，且消息封装包示例将在以下表45中描述。【表45】SOAP标头元素包括扩展元素（1）到（4）作为封装包元素的第一子元素。（1）消息标头：基本元素，包括消息的路由信息（至/自）以及与消息有关的其它上下文信息（2）同步应答：指示收发消息的方法为同步的元素（3）签名：指示SOAP消息的数字签名值以及附加文档的元素（4）错误名单：元素，当在处理消息过程（诸如消息语法验证和消息数字签名验证）中发生错误时，输入错误的细节，以返回错误消息。SOAP体块元素包括诸如Manifest的扩展元素作为SOAP封装包的第二子元素。Manifest为指示位于不同位置（诸如净荷容器或者web）中的数据的元素。Manifest元素需要参考净荷容器。Manifest元素为由一个或者多个参考元素构造的复杂元素。每个参考元素作为包括在净荷容器中的（多个）净荷文档一部分被包括，或者区分与消息相关的数据，所述数据为可由URL访问的远程资源。建议在SOAP体块中不加载净荷数据。Manifest的目的为如下（1）和（2）。（1）允许容易和直接访问与ebXML消息相关的特定净荷（2）为了确定应用程序是否处理净荷而无需解析Manifest元素具有以下属性和元素（1）到（3）。（1）一个id属性（2）一个版本属性（3）一个或者多个参考元素参考元素为由以下子元素（1）和（2）构造的复杂元素。（1）0或者多个架构元素：与（多个）架构有关的信息，该架构定义与父参考元素区分的即时文档（2）0或者多个描述元素：由父参考元素引用的净荷对象的描述参考元素为【XLINK】的简单链接。XLINK为W3C的当前候选推荐（CR）。这里，提供XLINK以阐明关联关系的描述。根据实施要求，不一定使用XLINK过程或者引擎，但是可能有用。参考元素除上述元素的内容之外还包括以下属性内容（1）到（5）。（1）id：参考元素的XMLID（2）xlink型：此属性定义元素为XLINK简单链接。本属性具有固定值“简单”（3）xlink：href：此基本属性为所引用净荷对象的URI值。此属性是基于【XLINK】规范的简单链接（4）xlink：role：此属性区分净荷对象或者描述净荷对象目的的资源。如果存在此属性，那么此属性需要具有基于【XLINK】规范的可用URI值（5）可能存在其它有效名称空间属性。接收MSH可忽略外部名称空间属性而不是以上定义的属性如果参考项目具有描述参考项目（例如，XML架构、DTD或者数据库架构）的（多个）架构，那么架构元素需要作为参考元素的子元素存在。这用来区分架构和版本，且定义由父参考元素区分的净荷对象。架构元素具有以下属性（1）和（2）。（1）位置：架构的基本URI（2）版本：架构的版本标识符如果xlink：href属性包括URI，URI为内容id（URI架构“cid“），那么具有内容id的MIME需要在消息的净荷容器中表达。否则，具有MimeProbem作为errorCode的错误以及作为严重性的错误需要发送到发送方。如果xlink：href属性不包括URI，URI为内容id（URI架构“cid“），那么不解译URI，且因此根据实施确定是否发送错误。如果确定发送错误，那么具有MimeProbem作为errorCode的错误以及作为严重性的错误需要发送到发送方。以下表46表示具有一个净荷MIME体块部分的消息的典型Manifest。【表46】下文中，将描述基本协议配置中消息的详细组成。消息标头元素为基本元素，表达在所有ebXML消息中且表达为SOAP标头元素的子元素。消息标头元素为由以下子元素构成的复杂元素。消息标头的元素结构将在以下表47中描述。【表47】消息标头的架构结构在图36中示出，且消息标头的项目代码表将在以下表48中描述，以及每个业务的服务/动作项目将在以下表49中描述。【表48】【表49】流通连接消息需要以数字方式签名，以应对在收发过程中可能发生的各种危险因素。因此，签名元素需要作为SOAP标头的子元素存在。流通连接消息中的整个SOAP消息以及包括在净荷容器中的消息和附加文档需要为数字签名的对象。签名对象信息被整理为包括在数字签名信息中。根据【XMLDSIG】标准执行数字签名的过程为如下（1）到（4）。（1）在SOAP封装包中创建具有SignatureMethod、CanonicalizationMethod的SignedInfo元素以及参考元素和基本净荷对象，如在【XMLDSIG】中定义的-在SignedInfo较低级处的第一参考项目具有整个SOAP消息作为目标，使得“”在URI值中描述。-自第二参考项目，重复描述尽可能多的净荷容器数。在此情况下，URI值描述在附加文档的MIME标头中定义的内容ID值。（整理目标为不包括MIME标头的内容部分）（2）在规范化之后，基于在SignedInfo中指定的算法计算SignedInfo的SignatureValue，如在【XMLDSIG】中指定（3）创建签名元素，该签名元素包括SignedInfo、KeyInfo和SignatureValue元素，如在【XMLDSIG】中指定（4）SOAP标头的签名包括在SOAP标头元素中在数字签名时使用的算法信息为如下。算法基本上遵循W3C算法部分（6.0算法），即“XML签名语法和处理”（RFC3275）。此外，为了支持国内独特算法，使用在TTAS.IF-RFC3075“XML-签名语法和处理”（电信技术协会，2004年）中定义的算法。接着，将描述用在流通协议中的算法列表。为了在收发消息时尽量减少数字签名创建和验证过程中的歧义，不同于以下所列（1）到（5）的算法的使用被限制。（1）数字签名名称空间【表52】<...xmlns:ds="http://www.w3.org/2000/09/xmldsig#"...>（2）散列（摘要）用于减少数据的算法遵守经认证的证明系统的相关规定【表53】（3）数字签名（签名）用于对消息进行数字签名的算法遵守经认证的证明系统的相关规定【表54】（4）规范化；由于在物理上可不同表达逻辑相同文档的XML的特性，数字签名值对于相同文档可以是不同的。为了防止以上现象，需要执行规范化过程。在规范化中，使用省略注释的规范化XML。【表55】（5）转换；即使存在各种转换算法作为经过对整个XML数据中的待签名数据进行的处理和选择的过程的算法，但在各种转换算法中只可使用三个算法。第一算法为封装签名转换，这是因为数字签名遵守包括在签名目标中的形式，第二算法为上述规范化，以及第三算法为选择签名目标信息的Xpath过滤。【表56】当在通信协议处理（诸如消息语法验证或者消息数字签名验证）过程中发生错误时，在标头较低级中创建ErrorList元素且同步返回到发送方。当生成ErrorList元素时，RefToMessageId必须存在于消息标头元素中，且RefToMessageId需要指定发生错误的消息的消息ID。ErrorList元素具有以下属性（1）到（5）。（1）id属性（2）SOAPmustUnderstand属性（3）版本属性（4）highestSeverity属性（5）一个或者多个错误元素如果没有错误报告，那么应当不存在ErrorList元素。ErrorList的结构在图38中示出。highestSeverity属性指示所有错误元素的最严重状态。具体地，如果错误元素设定严重性为错误，那么highestSeverity设定为错误。否则，highestSeverity设定为警告。错误元素具有以下属性（1）到（6）。（1）id属性；id属性用于唯一区分文档中的ErrorList元素。（2）codeContext属性；codeContext属性表示名称空间或者错误代码的架构，且应当为URI。此属性的默认值为urn：oasis：names：tc：ebxml-msg：service：errors。如果此属性中没有默认值，那么规范实施指示使用错误代码。（3）错误代码属性；基本错误代码属性指示具有错误的消息的错误本质（4）严重性属性；作为基本属性的严重性属性指示错误严重性。有效值为警告和错误。警告指示在转换过程中通常创建其它消息，而不管错误如何。错误指示在消息中存在不可恢复错误且在转换过程中不再创建其它消息。（5）位置属性；位置属性指示存在错误的消息部分。如果错误存在于ebXML元素中且元素为“well-formed”，那么位置属性的内容需要为【Xpointer】。（6）描述属性；描述元素的内容通过在xml：lang属性中定义的语言提供错误的描述性解释。一般地，该消息通过验证XML解析器或者消息的软件来生成。这意味着，内容由创建错误元素的软件销售商或者开发者定义。如果在基于流通协议进行收发消息过程中发生错误，那么通知错误的收发实体需要将错误通知给其他方。待报告错误包括消息结构错误、通讯错误和安全性错误。与属于比本发明中定义的流通协议更低层的数据通信协议（诸如HTTP和Socket）相关的错误需要通过由数据通信协议支持的标准机制发现和报告，且不使用在本发明中定义的错误报告机制。错误代码根据错误目标和错误类型来分类，且其细节将在以下表59中描述。【表59】下文中，将描述在HTTP绑定方法中通过HTTP进行的消息发送方法。下文中，将描述HTTP绑定方法中的HTTP响应代码。在本发明中，为了返回HTTP级别的响应代码，需要使用在【RFC2616】中定义的HTTP响应代码。主要响应代码将在以下表61中描述。【表61】下文中，将描述HTTP绑定方法中的HTTP发送安全性方法。流通系统中流通通讯服务器和流通通讯服务器之间的发送或者流通通讯服务器和流通客户端之间的发送需要使用HTTP/S（安全超文本传输协议）来处理，HTTP/S必须使用SSL（安全套接字层）V3.0用于网络发送安全。在根据本发明的流通系统中发生的错误类型大致分为同步响应错误发生和异步响应错误发生。在同步响应错误的情况下，请求方等待，直至接收到请求消息的处理结果，使得请求方立即意识到错误。与之相比，在异步响应错误的情况下，只有在交付请求内容之后请求方才接收到处理结果，使得需要另外错误处理。下文中，将描述错误处理方法中的同步错误处理方法。通讯服务器、其它流通通讯服务器、地址目录服务器、流通客户端和流通中继服务器中两个流通实体之间的所有消息流通为同步流通。此外，根据连接类型，其中流通客户端通过一流通通讯服务器连接到其它流通通讯服务器、地址目录服务器和流通中继服务器的三个实体之间的消息流通为同步或者异步连接。所有同步发送错误可由发送方立即检查到，使得根本上重新发送消息。根据参与流通系统的企业或者机构的系统策略来确定重新发送方法。然而，根本上，通过设定相同消息ID值再次发送相同消息。通过利用相同消息ID发送消息，不仅在发送时发生错误时，而且在接收方成功接收消息之后同步发送响应消息过程中发生错误时，通知冗余消息以防止冗余处理相同请求。根据连接类型，同步错误发送方和接收方可为流通通讯服务器、地址目录服务器、流通客户端和流通中继服务器。（1）错误消息发送失败：当发送方发送消息时发生发送错误，使得请求消息未交付给接收方。发送方通过发送重试超时或者网络错误消息来识别发送失败。图39示出了当请求消息发送失败时的过程，且处理程序为如下1）到3）。1）在由消息发送方发送过程中发生发送错误。在大多数情况下，这个错误由网络错误导致2）如果发送方接收到错误消息，诸如HTTP错误，那么发送方请求需要重新发送相同消息3）只有当从接收方接收到接收确认消息时，发送方才认可发送成功。（2）响应消息接收失败：即使发送方正常发送消息，当从接收方接收响应消息时也会发生错误。在发送方位置，响应消息接收失败与（1）的请求消息发送失败不区分，使得通过相同方法处理错误。然而，因为接收方正常接收请求消息，所以处理方法不同于发送方的处理方法。图42示出了与响应消息接收失败相关的过程，且处理程序将描述为如下1）到3）。1）即使消息正常交付给接收方，但发送方从接收方未接收到接收确认消息时2）在此情况下，发送方识别为发送失败错误，且利用相同消息ID将相同消息重新发送到接收方3）如果所接收文档的消息ID与先前所接收消息相同，那么接收方发送指示冗余接收的接收确认消息且内部处理消息。（3）错误消息接收：即使发送方正常发送消息，当接收发送消息的接收方处理消息时发生错误。在此情况下，根据错误消息类型，改变发送方的处理方法。关于通信协议的错误类型是指上述“ErrorList”项目。此外，在对每个连接接口的请求消息进行内部处理过程中发生的错误是指连接接口的消息结构。图41示出了与错误消息接收相关的过程，且处理程序为如下1）到3）。1）即使将发送到接收方的消息正确地交付，但在发送消息错误而导致接收到错误消息时2）在此情况下，一般地，发送方重新创建请求消息且然后重新发送消息。然而，根据错误类型，可改变消息处理3）当发送方重新发送请求消息时，待发送消息的消息ID不需要与先前消息相同且根据任务情况不同地处理。（4）三级同步错误：在流通客户端通过流通通讯服务器连接到其它另一个流通通讯服务器、地址目录服务器和流通中继中心的三个实体之间的消息流通支持连接方法中的同步连接方法，以立即检查最终结果。在这个过程期间，如果在流通通讯服务器和接收方的连接步骤中发生错误，那么流通通讯服务器立即生成错误，且然后将错误作为响应消息发送到其它另一个流通通讯服务器。图42示出了与三级同步错误相关的过程，且处理程序为如下1）到3）。1）即使在流通客户端在与流通通讯服务器连接时发送消息的过程中发送成功，但在发送消息到流通通讯服务器附近的接收方（地址目录服务器、其它流通通讯服务器或者流通中继服务器）的过程中也会发生错误2）在此情况下，错误是指在流通通讯服务器和接收方之间同步发送期间发生的所有错误3）在流通通讯服务器通知错误并将错误消息作为响应消息交付给流通客户端时，流通通讯服务器生成针对流通客户端的错误消息由流通通讯服务器创建的错误消息用以下表62的结构构造。【表62】下文中，将描述错误处理方法中的异步错误处理方法。其中流通客户端通过流通通讯服务器连接到其它另一个流通通讯服务器、地址目录服务器和流通中继服务器的三个实体之间的消息流通支持连接方法中适用于最终接收方情况的异步连接方法。异步发送的最终错误可不由发送方立即检查，异步发送不同于同步发送。因此，在流通通讯服务器最终检查到错误且允许流通客户端接收错误消息时，流通通讯服务器生成针对流通客户端的错误消息。图43示出了与异步错误处理方法相关的过程，且处理方法为如下1）到4）。1）即使在流通客户端与流通通讯服务器连接的情况下发送消息的过程中发送成功，但在发送消息到流通通讯服务器附近的接收方（地址目录服务器、其它另一个流通通讯服务器或者流通中继服务器）的过程中也发生错误2）在此情况下，错误是指在流通通讯服务器和接收方之间的同步发送期间发生的所有错误3）在重试之后最终识别错误且然后将错误消息交付给流通客户端邮箱时，流通通讯服务器生成针对流通客户端的错误消息4）流通客户端通过接收在其邮箱中的错误消息将先前请求消息的错误在请求接收消息的过程中通知给流通通讯服务器由流通通讯服务器生成的错误消息由以下表63的结构构造。【表63】【流通通讯服务器和地址目录服务器之间的连接接口】地址目录服务器为管理经认证的电子邮件地址的系统，认证的电子邮件地址在流通系统中是非常基本的且在电子文档流通中是不可避免地为必要的。流通通讯服务器和地址目录服务器之间的连接接口大致分为两个功能。第一功能为与登记机构的认证电子邮件地址的登记任务相关的接口，第二功能为与流通通讯服务器物理地址查询/响应并报告垃圾邮件的任务相关的接口。用于登记机构的认证电子邮件地址的登记任务的接口可分离。然而，电子文档提供商或者第三方存储机构服务器为登记机构，使得接口功能插入在流通通讯服务器中。在此情况下，在设置于收发实体中的流通通讯服务器中，未插入与认证电子邮件地址登记相关的连接接口。流通通讯服务器和地址目录服务器之间的接口功能将在以下表64中描述。【表64】下文将描述流通通讯服务器和地址目录服务器之间的接口的详细信息。首先，流通通讯服务器和地址目录服务器之间的接口的共同事实为如下（1）和（2）。（1）请求消息的消息标头扩展发送实体的数字签名信息需要被交付，以包括在从发送实体的流通通讯服务器发送到地址目录服务器的请求消息的第一MIME部分的SOAP消息中。此外，地址目录服务器验证用于SOAP消息数字签名的证书拥有者是否与发送实体匹配（VID验证）所需的发送实体的附加信息（CorpNum、RValue）也被交付以包括在其中。发送实体的附加信息需要作为扩展元素位于请求消息的SOAP消息中消息标头元素的较低级处（任何##其它位置）。扩展元素结构将在以下表65中描述。【表65】（2）整个消息结构在流通通讯服务器和地址目录服务器之间的连接接口中，SOAP消息位于消息的第一MIME部分，且请求和响应的流通消息位于第二MIME部分。流通通讯服务器和地址目录服务器之间的SOAP结构在图44中示出。下文中，将描述在流通通讯服务器和地址目录服务器之间接口中，认证电子邮件地址的登记。与认证电子邮件地址登记相关的消息交换流程在图45中示出。请求流通消息结构将在以下表67中描述。【表67】响应流通消息的结构将在以下表69中描述。【表69】下文中，将描述在介于流通通讯服务器和地址目录服务器之间的接口中，变更认证电子邮件地址信息的接口。变更认证电子邮件地址信息的接口为允许电子文档提供商请求地址目录服务器变更登记于地址目录服务器中的认证发送方/接收方的认证电子邮件地址且接收响应的接口。在发送包括待变更的用户信息和认证电子邮件地址信息的请求消息之后，电子文档提供商接收地址目录服务器的变更结果作为响应消息。与认证电子邮件地址变更过程相关的消息交换流程在图46中示出。请求流通消息结构将在以下表71中描述。【表71】响应流通消息的结构将在以下表73中描述。【表73】在图73中，如果ResultCode输入为失败（0），那么与错误原因对应的错误代码输入为ErrorCode。下文中，将描述在介于流通通讯服务器和地址目录服务器之间的接口中，删除认证电子邮件地址信息的接口。删除认证电子邮件地址信息的接口为允许电子文档提供商请求地址目录服务器删除登记于地址目录服务器中的认证发送方/接收方的认证电子邮件地址信息且接收响应的接口。在发送包括待删除的用户信息和认证电子邮件地址信息的请求消息之后，电子文档提供商接收地址目录服务器的删除结果作为响应消息。与认证电子邮件地址的删除过程相关的消息交换流程在图47中示出。请求流通消息结构将在以下表75中描述。【表75】响应流通消息的结构将在以下表77中描述。【表77】在图114中，如果ResultCode输入为失败（0），那么与错误原因对应的错误代码输入为ErrorCode。下文中，将描述在介于流通通讯服务器和地址目录服务器之间的接口中，搜索物理地址信息的接口。搜索物理地址信息的接口为允许电子文档提供商或者收发实体请求地址目录服务器，以请求与电子文档接收方的认证电子邮件地址信息对应的物理地址信息且接收响应的接口。在发送包括电子文档接收方的认证电子邮件地址的请求消息以及证书请求之后，电子文档提供商从地址目录服务器接收电子文档接收方的物理地址信息（IP地址或者域名地址）以及证书信息作为响应消息。与物理地址信息搜索过程相关的消息交换流程在图48中示出。请求流通消息结构将在以下表79中描述。【表79】响应流通消息的结构将在以下表81中描述。【表81】下文中，将描述在介于流通通讯服务器和地址目录服务器之间接口中，报告垃圾消息的接口。报告垃圾消息的接口为允许电子文档提供商或者收发实体将垃圾消息报告给地址目录服务器的接口。在发送包括垃圾发送方的认证电子邮件地址以及垃圾消息信息的请求消息之后，接口从地址目录服务器接收是否接受垃圾报告作为响应消息。如果有关所报告垃圾消息是否为垃圾的确定完成，那么地址目录服务器使用介于流通通讯服务器之间连接接口的“消息发送”接口通知处理结果。与垃圾消息报告和接受过程相关的消息交换流程在图49中示出。请求流通消息的结构将在以下表83中描述。【表83】响应流通消息的结构将在以下表85中描述。【表85】在表85中，请注意，ResultCode为垃圾报告消息的简单接受处理结果。下文中，将描述在介于流通通讯服务器和地址目录服务器之间接口中，通知白名单的接口。通知白名单的接口为将白名单（收发实体名单以及参与流通系统的发送方/接收方的认证电子邮件地址）通知给收发实体的接口。与白名单通知相关的消息交换流程在图50中示出。请求流通消息结构将在以下表87中描述。【表87】响应流通消息的结构将在以下表89中描述。【表89】在表89中，请注意，ResultCode为垃圾报告消息的简单接受处理结果。下文中，将描述在介于流通通讯服务器和地址目录服务器之间接口中，通知黑名单的接口。通知黑名单（接收拒绝名单）的接口为将黑名单通知给收发实体的接口。通知的黑名单用于由收发实体管理黑名单。与黑名单通知相关的消息交换流程在图84中示出。请求流通消息结构将在以下表91中描述。【表91】响应流通消息的结构将在以下表93中描述。【表93】【流通通讯服务器之间的连接接口】流通通讯服务器根本上与由其它收发实体或者其它电子文档提供商建立的流通通讯服务器连接，以发送/接收消息。除以上基本功能外，流通通讯服务器具有在第三方存储机构提供商的流通通讯服务器与其它通讯服务器之间传送流通证书以将流通证书存储于第三方存储机构中的连接功能。流通通讯服务器之间的连接接口为用于在通讯服务器之间发送/接收消息和流通证书的协议，且被分类为以下表95中描述的接口。【表95】下文将描述流通通讯服务器之间接口的详细信息。首先，流通通讯服务器之间接口的共同事实为如下（1）。（1）请求和响应消息的消息标头扩展发送方的数字签名信息需要交付以包括在SOAP消息中，所述SOAP消息为流通通讯服务器之间的连接接口的消息的第一MIME部分。此外，验证用于SOAP消息数字签名的证书拥有者是否与发送方匹配（VID验证）所需的发送方的附加信息（CorpNum、RValue）也被交付以包括在其中。发送方的附加信息需要作为扩展元素位于请求和响应消息的SOAP消息中消息标头元素的较低级处（任何##其它位置）。扩展元素结构将在以下表96中描述。【表96】下文中，将描述介于流通通讯服务器之间接口中的消息发送接口。当一个流通通讯服务器发送消息到另一个流通通讯服务器时，使用消息发送接口。消息发送接口的消息结构在图85中示出。交换消息时的请求格式在图53中示出。在如图53所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求流通消息位于第二MIME部分中，以及由用户附加的文档位于第三或者后续MIME部分中。请求流通消息结构将在以下表98中描述。【表98】在表98中，如果为了交付文档，体块没有必要，那么文本可省略。交换消息时的响应格式在图87中示出。在如图87所示的整个消息结构中，SOAP消息位于第一MIME部分中，响应流通消息位于第二MIME部分中，以及接收证书位于第三MIME部分中。如果在处理请求消息过程中发生错误，那么不产生第三MIME部分。响应流通消息结构将在以下表100中描述。【表100】在表100中，如果DocType为错误（9），那么不产生接收证书所位于的第三MIME部分。下文中，将描述介于流通通讯服务器之间的接口中的流通证书交付接口。当流通通讯服务器发送读取证书到另一个流通通讯服务器时，使用流通证书交付接口。此外，当流通中继服务器接收发送电子文档到接收流通通讯服务器的请求且然后发送所接收到的接收证书到发送请求流通通讯服务器作为响应消息时，使用流通证书发送接口。与流通证书交付处理相关的消息交换流程在图88中示出。流通证书交付请求格式在图89中示出。在如图89所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求流通消息位于第二MIME部分中，以及流通证书位于第三MIME部分中。请求流通消息结构将在以下表102中描述。【表102】流通证书发送响应格式在图90和91中示出（图90示出了在成功情况下的流通证书发送响应，图91示出了失败情况下的流通证书发送响应）。在如图57所示的整个消息结构中，如果请求消息处理成功，那么仅接收确认ACKSOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。响应流通消息结构将在以下表104中描述。表104仅对应处理结果失败时。【表104】下文中，将描述介于流通通讯服务器之间的接口中的流通证书存储请求接口。当收发实体的流通通讯服务器请求第三方存储机构的流通通讯服务器存储流通证书以将流通证书存储于第三方存储机构中时，使用流通证书存储请求接口。在接口中的响应消息中，仅包括接收确认信息。作为流通证书存储于第三方存储机构中的结果所发行的初始登记证书，通过使用将在下文描述的第三方存储机构存储结果交付接口交付到存储请求流通通讯服务器。与流通证书存储请求处理相关的消息交换流程在图92中示出。流通证书存储请求格式在图93中示出。在如图93所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求流通消息位于第二MIME部分中，以及流通证书位于第三MIME部分中。请求流通消息结构将在以下表105中描述。【表105】流通证书存储响应格式在图94和95中示出（图94示出了成功情况下的流通证书存储响应，图95示出了失败情况下的流通证书存储响应）。在如图94和95所示的整个消息结构中，如果请求消息的处理成功，那么仅接收确认ACKSOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。响应流通消息结构将在以下表107中描述。表107仅对应处理结果失败时。【表107】下文中，将描述介于流通通讯服务器之间接口中的第三方存储机构存储结果交付接口。当第三方存储机构提供商的流通通讯服务器将流通证书存储于第三方存储机构中且然后将作为结果所接收的初始登记证书发送到请求存储流通证书的流通通讯服务器时，使用第三方存储机构存储结果交付接口。与第三方存储机构存储结果交付处理相关的消息交换流程在图96中示出。第三方存储机构存储结果交付格式在图97中示出。在如图97所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求流通消息位于第二MIME部分中，以及第一登记证书位于第三MIME部分中。如果在将流通证书存储于第三方存储机构的过程中发生错误，那么不产生第三MIME部分。请求流通消息结构将在以下表108中描述。【表108】在表108中，如果DocType为错误（9），那么不产生初始登记证书位于的第三MIME部分。第三方存储机构存储结果响应格式在图98和99中示出（图98示出了成功情况下的流通证书发送响应，图99示出了失败情况下的流通证书发送响应）。在如图98和99所示的整个消息结构中，如果请求消息处理成功，那么仅接收确认ACKSOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。响应流通消息结构将在以下表110中描述。表110仅对应处理结果失败时。【表110】【流通客户端和流通通讯服务器之间的连接接口】流通通讯服务器与请求实际电子文档流通的用户（内部发送方/接收方或者认证发送方/接收方）的系统（流通客户端）连接，并需要为用户提供基本文档收发功能。流通客户端和流通通讯服务器之间的连接接口为允许流通客户端首先与流通通讯服务器通信以发送和接收电子文档的协议，且分类为如以下表111中描述的接口。【表111】下文将描述流通客户端和流通通讯服务器之间接口的细节。首先，流通客户端和流通通讯服务器之间连接接口的共同事实为如下（1）。（1）请求消息的消息标头扩展用户的数字签名信息需要交付以包括在SOAP消息中，所述SOAP消息为从流通客户端发送到流通通讯服务器的请求消息的第一MIME部分。此外，验证用于SOAP消息数字签名的证书拥有者是否与对应用户匹配（VID验证）所需的附加用户信息（IDN、RValue）也被交付以包括在其中。对应信息需要作为扩展元素位于请求消息的SOAP消息中消息标头元素的较低级处（任何##其它位置）。此外，将添加对于使用相同证书的多个内部用户的个人认证信息。扩展元素结构将在以下表112中描述。【表112】下文中，将描述介于流通客户端和流通通讯服务器之间连接接口中的消息发送请求接口。当流通客户端发送消息到流通通讯服务器以通过流通通讯服务器发送消息时，使用消息发送请求接口。流通客户端的消息发送处理流程在图100中示出。流通客户端的消息发送请求格式在图101中示出。在如图101所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求流通消息位于第二MIME部分中。如果存在由用户附加的文档，那么文档位于第三或者后续MIME部分中。请求流通消息结构将在以下表114中描述。【表114】在表114中，如果为了交付文档的目的，体块没有必要，那么文本可省略。流通客户端消息发送响应格式在图102和103中示出（图102示出了成功情况下的流通证书发送响应，图103示出了失败情况下的流通证书发送响应）。在如图102和103所示的整个消息结构中，如果请求消息处理成功，那么仅接收确认ACKSOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。响应流通消息结构将在以下表116中描述。表116对应只有当处理结果失败时。【表116】下文中，将描述介于流通客户端和流通通讯服务器之间的连接接口中的消息列表请求接口。当流通客户端请求在流通通讯服务器中接收到的消息列表时，使用消息列表请求接口。流通客户端的消息列表处理流程在图67中示出。流通客户端的消息列表请求格式在图105中示出。在如图105所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求流通消息位于第二MIME部分中。请求流通消息结构将在以下表117中描述。【表117】流通客户端的消息列表响应格式在图67中示出。在如图67所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应流通消息（在流通通讯服务器中接收的流通消息的列表）位于第二MIME部分中。响应流通消息结构将在以下表119中描述。【表119】下文中，将描述在介于流通客户端和流通通讯服务器之间连接接口中的消息详细信息请求接口。当流通客户端请求由流通通讯服务器接收的特定消息和附加文档时，使用消息详细信息请求接口。流通客户端的详细信息请求处理流程在图106中示出。流通客户端的消息详细信息请求格式在图70中示出。在如图70所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求流通消息的体块位于第二MIME部分中。请求流通消息结构将在以下表121中描述。【表121】消息详细信息响应格式在图109中示出。在如图109所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应流通消息（流通消息的详细信息）位于第二MIME部分中。如果存在附加文档，那么附加文档依次位于第三或者后续MIME部分中。响应流通消息结构将在以下表123中描述。【表123】下文中，将描述在介于流通客户端和流通通讯服务器之间连接接口中的垃圾消息报告接口。当流通客户端将垃圾消息报告给流通通讯服务器时，使用垃圾消息报告接口。流通通讯服务器将垃圾消息报告给地址目录服务器，且然后将结果交付给流通客户端。流通客户端的垃圾消息报告处理流程在图73中示出。流通客户端的垃圾消息报告格式在图111中示出。在如图74所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求流通消息位于第二MIME部分中。请求流通消息结构将在以下表125中描述。【表125】流通客户端的垃圾消息响应格式在图112中示出。在如图112所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应流通消息（在流通通讯服务器中接收到的流通消息列表）位于第二MIME部分中。响应流通消息结构将在以下表127中描述。【表127】在表127中，请注意，ResultCode指示垃圾报告消息的简单接受结果。下文中，将描述在介于流通客户端和流通通讯服务器之间连接接口中的物理地址搜索接口。当流通客户端请求流通通讯服务器搜索物理地址时，使用物理地址搜索接口。流通通讯服务器搜索物理地址，且然后将结果交付给地址目录服务器。与物理地址搜索处理相关的消息交换流程在图113中示出。物理地址搜索请求格式在图114中示出。在如图114所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求流通消息位于第二MIME部分中。请求流通消息结构将在以下表129中描述。【表129】物理地址搜索响应格式在图115中示出。在如图115所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应流通消息（在流通通讯服务器中接收的流通消息列表）位于第二MIME部分中。响应流通消息结构将在以下表131中描述。【表131】请注意，甚至在对于多个RAddress中一些或者全部正常进行搜索时，但是发生不存在地址错误时，ResultCode输入为成功（1），这与另一个接口不同。*RAddress被描述为，不管ResultCode成功（1）/失败（0）以及是否存在RAddress，RAddress输入在IsExit中，IsExit为属性信息。*当IsExit值为存在（1）时，输入Endpoint和Cert*由于请求消息错误而不解析RAddress，RAddress可省略（因此，Endpoint和Cert将省略）*如果ResultCode输入为失败（0），即，发生不同于不存在地址错误的其他错误，那么ErrorCode输入与错误原因对应的错误代码【流通通讯服务器和流通中继服务器之间的连接接口】流通中继服务器为当在电子文档流通系统中流通通讯服务器之间直接发送电子文档的过程中发生错误，使得发送失败时，通过发送流通通讯服务器的代理服务器发送电子文档的系统。流通中继服务器由国家工业促进局管理，且当在P2P流通过程中发生错误时，可支持与流通中继服务器连接的所有流通通讯服务器。流通通讯服务器和流通中继服务器之间的连接接口为允许流通通讯服务器请求流通中继服务器发送电子文档的协议，且分类为以下表133中描述的接口。【表133】首先，流通通讯服务器和流通中继服务器之间连接接口的共同事实如下（1）。（1）请求消息的消息标头扩展流通通讯服务器的数字签名信息需要交付以包括在SOAP消息中，所述SOAP消息为介于流通通讯服务器和流通中继服务器之间的连接接口的第一MIME部分。此外，流通通讯服务器验证用于SOAP消息数字签名的证书拥有者是否与对应通讯服务器匹配（VID验证）所需的流通通讯服务器的附加信息（CorpNum、RValue）也被交付以包括在其中。流通通讯服务器的附加信息需要作为扩展元素位于SOAP消息中消息标头元素的较低级处（任何##其它位置）。扩展元素结构将在以下表134中描述。【表134】下文中，将描述在介于流通通讯服务器和流通中继服务器之间连接接口中的消息发送请求接口。当在从流通通讯服务器发送消息到其它另一个流通通讯服务器的过程中在其它另一个流通通讯服务器处发生接收错误时，使用消息发送请求接口以请求流通中继服务器发送消息且发行发送证书。流通中继服务器立即返回流通通讯服务器的消息发送请求的接受结果，且使用上述“流通证书发送接口”将在发送消息到接收流通通讯服务器之后接收到的接收证书发送到发送请求流通通讯服务器。消息中继处理流程在图116中示出。消息中继请求消息格式在图117中示出。在如图117所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求流通消息位于第二MIME部分中。如果存在由用户附加的文档，那么文档位于第三或者后续MIME部分中。请求流通消息结构将在以下表136中描述。【表136】在表136中，如果为了交付文档，体块没有必要，那么文本可省略。消息中继响应消息格式在图118中示出。在如图118所示的整个消息结构中，SOAP消息位于第一MIME部分中，响应流通消息位于第二MIME部分中，以及发送证书位于第三MIME部分中。如果在处理请求消息过程中发生错误，那么不产生第三MIME部分。响应流通消息结构将在以下表138中描述。【表138】在表138中，如果DocType为错误（9），那么不产生发送证书位于的第三MIME部分。下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档流通系统及使用该电子文档流通系统的电子文档流通方法的另一个示例。【电子文档流通系统的结构和电子文档流通方法】基于P2P通信流通电子文档，其中P2P通信允许遵守可靠流通标准的企业/机构彼此直接发送/接收电子文档。根据本发明的用于进行P2P通信的电子文档流通系统的基本元件为基于支持介于管理地址信息的地址目录服务器与每个收发实体之间流通的标准的流通通讯服务器系统。如果只提供地址目录服务器和流通通讯服务器系统，那么配备允许企业或者机构流通电子文档的基本结构。此外，发行用于证明发送方/接收方之间的文档流通的流通证书，且同时流通证书存储于第三方存储机构（认证电子文档存储机构）中，以为流通建立法律依据。除基本元件外，根据本发明的电子文档流通系统包括：流通客户端应用程序（APP），用于为用户接口提供文档收发功能，以允许一般用户（企业/机构、个人）容易流通文档；电子文档格式寄存器，用于提供标准文档格式以提高创建文档的便利性；以及公共部门连接网关，用于作为另外配置元件为管理机构中继电子文档。在上述电子文档流通系统中执行的基本过程将在以下表140中描述。【表140】【电子文档流通系统的组成要素】下文将更系统地描述电子文档流通系统的元件。为了建立电子文档流通，首先，作为流通的主要主体（principalagent）的“（1）收发实体”需要存在，且收发实体需要包括“（2）流通通讯服务器系统”，流通通讯服务器系统遵守流通通讯服务器标准以流通文档。此外，作为电子文档流通基本构造的“（3）地址目录服务器”登记和管理收发实体的认证电子邮件地址，且需要存在用户。基于以上基本构造，提供“（4）流通客户端应用程序”以为用户提供流通便利性，且另外提供支持连接行政/公共机构的“（5）公共部门连接网关”以及管理文档格式的“（6）电子文档格式寄存器”。下文中，将详细描述上述组成元件。（1）收发实体在电子文档流通的基本基础组件中，作为流通标准的单元为收发实体。收发实体根据参与流通的角色充当发送方或者接收方，且这些实体根据流通协议通过流通通讯服务器系统来流通文档（信息）。参与流通的所有收发实体根据流通通讯标准建立能够收发文档的流通通讯服务器系统，且然后将流通通讯服务器系统的物理地址信息登记于地址目录服务器中以为参与电子文档流通创建基础。在此情况下，每个收发实体具有实际流通用户，实际流通用户具有至少一个较低级别的认证电子邮件地址。电子文档流通中被标示为收发实体的实体限于通过国家工业促进局建立遵守通讯服务器标准的系统且然后接收标准兼容性和互操作性的认证的实体。为了证实流通，（1）在通过认证收发实体流通电子文档之后，（2）流通证书需要根据标准发行且存储于第三方存储机构中。在此情况下，收发实体被分类为作为合法拥有者和电子文档负责人负责直接发送电子文档的实体；以及作为实际拥有者和流通电子文档负责人的用户代理服务的实体。在此情况下，如果电子文档拥有者为直接发送电子文档的收发实体，那么只有通过接收流通通讯服务器系统的标准兼容性和互操作性认证且将流通证书稳定地存储于第三方存储机构中，电子文档拥有者才可作为收发实体参与流通。与之相比，如果收发实体负责通过作为第三方的电子文档拥有者（用户）的代理服务器发送电子文档，那么收发实体需要证明，收发实体稳定且可靠地管理发送消息且管理和认证用户信息。为了确保第三方流通的稳定性和可靠性，暂时地，执行第三方流通的收发实体仅限于第三方存储机构提供商。（2）流通通讯服务器系统流通通讯服务器系统需要建立消息收发功能以及搜索与接收方有关的地址信息以及与地址目录服务器有关的安全性相关信息的功能，以基于流通通讯服务器标准流通电子文档（信息）。流通通讯服务器系统物理上具有一个电子邮件地址（IP地址），但可发行或者管理较低级别用户的多个用户账户，且每个用户账户具有一个认证电子邮件地址。流通通讯服务器系统需要管理每个用户账户的电子文档邮箱，以管理用户账户，且流通通讯服务器系统作为用户账户代表负责稳定且可靠的进行电子文档流通。为了作为收发实体参与电子文档流通，流通通讯服务器系统被认证是否适合实施根据本发明的要求，且在与其它解决方案的互操作性中没有问题。认证流通通讯服务器系统的标准兼容性和互操作性的认证系统管理认证的收发实体。此外，如果地址目录服务器请求在登记认证电子邮件地址的过程中确认是否认证，那么认证系统返回结果。根据如图65所示的以下过程，通过认证电子邮件地址来认证和登记流通通讯系统。首先，充当收发实体的企业/机构或者个人用户根据技术标准来建立流通通讯服务器系统。接着，通过由认证测试床提供的自动验证设备来认证建立的流通通讯服务器系统的标准兼容性和互操作性。接着，完成验证的收发实体请求认证测试床进行认证测试。接着，如果根据认证测试床的测试过程的系统认证结果为“合格”，那么收发实体准备用于登记认证电子邮件地址的下一个程序。接着，认证测试床将与通过认证检查的收发实体有关的信息交付给地址目录服务器，且地址目录服务器利用所述信息作为地址登记条件。接着，收发实体请求地址目录服务器发行唯一ID，以登记认证的流通通讯服务器系统。接着，如果流通通讯服务器系统完全登记在地址目录服务器中，那么流通通讯服务器系统可参与电子文档流通。接着，在完成认证流通通讯服务器系统之后，用户账户为开放。在代表性认证电子邮件地址的情况下，请求用户账户用认证电子邮件地址登记。（3）地址目录服务器为了参与可靠的电子文档流通，所有用户需要接收唯一电子邮件地址。（4）流通客户端应用程序流通客户端应用程序是指提供UI的应用程序，诸如文档发送和接收、接收文档读取以及参与文档流通的用户管理。流通客户端应用程序不独立发送/接收文档，而是需要与流通通讯服务器系统连接。通过流通客户端应用程序创建或者附加的文档使用流通通讯服务器系统交付给用户，搜索通过流通通讯服务器系统接收的文档。如果流通通讯服务器系统通过用户账户管理收发邮箱，那么流通客户端应用程序通过检查用户账户信息只可访问接收文档中的相应文档。根据用户请求，流通客户端应用程序可实施为C/S型应用程序或者web型屏幕。（5）公共部门连接网关不能接受电子文档流通的行政或者公共机构执行这样的功能：即在电子文档流通系统下通过公共部门连接网关用民营企业、机构或者个人接替行政或者公共机构。（6）电子文档格式寄存器想要使用流通通讯服务器系统发送电子文档的用户可使用office工具直接创建待发送文档。电子文档格式寄存器为支持管理（诸如文档格式登记和管理、文档格式搜索、读取和下载），以当登记和管理标准文档格式以支持允许用户容易创建电子文档时由用户应用程序（诸如流通客户端应用程序）使用的系统。电子文档格式寄存器提供管理文档标准格式的服务器引擎；以及允许客户端应用程序（APP）搜索和下载文档标准格式的标准接口，且然后插入内部程序以使用文档标准格式。【电子文档流通方法】电子文档流通中流通电子文档的整个过程大致分为“（1）流通之前的事先准备步骤”、“（2）电子文档流通步骤”、“（3）流通证实步骤”。下文中，将详细描述上述三个步骤。此外，将详细描述“文档收发方法”、“流通证实方法”和“垃圾消息处理方法”。（1）流通之前的事先准备步骤-电子文档格式寄存器管理者使用电子文档格式寄存器登记待使用的标准文档格式。-收发参与者确定是否为了可靠流通而自主建立流通通讯服务器系统，或者打开先前建立的流通通讯服务器系统中的用户账户以使用流通通讯服务器系统。如果为了可靠流通自主建立流通通讯服务器系统，那么建立用于收发电子文档的流通通讯服务器系统，且然后通过认证机构对流通通讯服务器系统的标准兼容性和互操作性进行认证测试。此后，收发参与者访问地址目录服务器以申请和接收经认证的流通通讯服务器系统的收发实体ID，然后自主登记和管理内部实际用户的内部标识符，并基于标准文档格式（可选）将标准文档格式创建功能插入用于文档创建功能的客户端应用程序。与之相比，如果使用包括允许第三方流通的流通通讯服务器系统的收发实体，那么收发参与者请求通过流通通讯服务器系统打开企业/机构/个人的用户账户，且然后将用户账户的认证电子邮件地址信息登记于地址目录服务器中。此后，收发参与者将标准文档格式创建功能插入于客户端应用程序中，以便一般用户基于标准文档格式（可选）使用文档创建功能。（2）电子文档流通步骤○文档发送方-文档发送方使用文字处理器选择待流通文档或者创建待发送文档。-接收文档的另一方的地址信息以及待交付文档，选择是否加密文档和是否进行数字签名（对附加交付文档而不是发送消息执行加密和数字签名，且这个过程为可选）-流通客户端应用程序基于与地址目录服务器连接的接收方的认证电子邮件地址，获得物理地址信息和加密用公钥信息（视情况，如果流通客户端应用程序不获得物理地址，那么流通通讯服务器执行这个过程）-流通客户端应用程序基于接收方地址信息（物理地址信息和认证电子邮件地址都为可用）请求发送到流通通讯服务器○发送方的流通通讯服务器-如果在流通客户端应用程序中请求的发送请求消息不是接收方物理地址信息，那么流通通讯服务器基于地址目录服务器的认证电子邮件地址来查询接收方的收发实体的物理地址信息-电子文档被封装为在流通协议标准中定义的消息结构-基于发送方的流通通讯服务器的证书对消息进行数字签名-基于终端物理地址信息将消息发送到接收方○接收方的流通通讯服务器-在接收消息之后，验证消息且从消息提取文档-包括接收证书的消息发送到发送方作为同步响应（3）流通证实步骤-接收方在接收用于文档接收确认的文档时，创建“接收证书”且将接收证书交付给发送方。接收接收证书的发送方将接收证书存储于第三方存储机构中。如果有来自发送方的请求，那么接收方将接收文档交付给文档实际负责人（用户），且然后在负责人检查接收文档时创建“读取证书”以将读取证书交付给发送方。接收“读取证书”的文档发送方将“读取证书”存储于第三方存储机构中（只有当有来自发送方的请求时，发行读取证书）。-当发送方尝试将文档交付给接收方但尝试失败时，发送方请求作为客观第三方的电子文档流通中心以证实发送尝试，且接收发送请求的电子文档流通中心发行“发送证书”以证实发送请求的接收，并将发送证书交付给发送请求方。接收发送证书的发送请求方将“发送证书”存储于第三方存储机构中。○文档收发方法发送方和接收方通过流通通讯服务器系统电子流通文档。流通通讯服务器系统根据流通协议，发送/接收电子文档。所有消息由发送确认和接收确认（或者接收证书）消息组合构造，以用于可靠消息流通，且通过地址目录服务器获得接收方物理地址信息。○流通证实方法“流通证实”是指关于与使用可靠方法的电子文档流通相关的发送、接收或者读取的事件证实。在此情况下，为与电子文档流通相关的动作发行的证书统称为“流通证书”。流通通讯服务器系统在发送和接收时发行流通证书，以证实发送和接收动作，且将发行的流通证书存储于第三方存储机构中以用作流通动作证据材料。流通通讯服务器系统证实发送、接收和读取电子文档的事件，且为事件创建流通证书。流通证书包括流通证书的识别信息、流通证书创建时间和到期时间、流通证书策略和流通证实目标。电子文档发送的流通证书由电子文档流通中心创建，且流通证实目标包括发送方的识别信息、接收方的识别信息、流通识别信息、文档识别信息和电子文档发送请求时间。电子文档接收的流通证书由接收电子文档的接收方创建，且流通证实目标包括发送方识别信息、接收方识别信息、流通识别信息、文档识别信息、电子文档发送时间和电子文档接收时间。电子文档读取的流通证书由检查电子文档接收的用户创建，且流通证实目标包括发送方识别信息、接收方识别信息、流通识别信息、文档识别信息、电子文档发送时间、电子文档接收时间和电子文档检查时间。如上所述创建的流通证书通过NPKI或者GPKI证书来数字签名，且所创建的流通证书交付给电子文档发送方。所有流通证书优选存储于第三方存储机构中。○垃圾消息处理方法电子文档流通具有基础结构，其中，基本上，发送方通过认证流通通讯服务器系统发送电子文档，且接收方也基于认证流通通讯服务器系统接收电子文档，使得发送方为此负责。然而，垃圾发送方可打开流通通讯服务器系统中的用户账户，且使用该用户账户发送电子文档。此外，当前认证系统只认证系统的技术内容。因此，如果垃圾发送方建立流通通讯服务器系统，在技术上认证流通通讯服务器系统，以及然后使用流通通讯服务器系统作为垃圾发送单元，那么在初始阶段难以阻止任何企图。因此，为了解决以上问题，在根据本发明的标准文档流通基础设施中，根据用户报告方法提供基于认证名单管理的白名单以及基于垃圾目标名单管理的黑名单系统，且应用允许接收方拒绝通过这个系统接收的处理以防止垃圾消息。报告垃圾消息和检查发送方的功能是基本的，因此所有流通通讯服务器需要必须建立这些功能。如果接收方确定接收消息为垃圾消息，那么接收方根据图27所示的过程将垃圾消息报告给电子文档流通中心的地址目录服务器，且与其相关的处理程序如下。首先，如果接收方确定在接收消息时，该消息为垃圾消息，那么接收方通过流通通讯服务器系统将该消息作为垃圾消息报告给地址目录服务器。接着，接受来自流通通讯服务器系统的垃圾消息报告的地址目录服务器返回指示接受的确认消息。接着，作为管理地址目录服务器的主要机构的国家IT产业促进机构分析消息且调查发送方，以检查和确定是否将发送方的认证电子邮件地址添加为黑名单。接着，如果发送方被确定为黑名单候选方，那么地址目录服务器将对应的认证电子邮件地址添加到黑名单，且然后将黑名单添加通知给发送方。接着，地址目录服务器将垃圾消息请求处理结果交付给垃圾报告方（接收方）。在上述处理程序中，仅被认证且正式登记的通讯服务器系统的信息记录在白名单中。相反，当发送方地址登记为垃圾发送方时，所述地址登记在黑名单中。如果重复产生通过相同流通通讯服务器系统登记于黑名单中的垃圾地址，那么电子文档流通中心确定是否取消对相应通讯服务器系统的认证，且然后取消认证并从白名单删除垃圾地址。当接收消息时，接收方检查地址目录服务器的白名单和黑名单，以确认发送方是否为可靠且合法的用户，从而确定是否拒绝接收。发送方检查方法包括在接收时的实时检查方法以及通过在接收方的流通通讯服务器中以缓存类型管理的名单来检查发送方的定期检查方法。在实时检查发送方的过程中，如图28所示，在接收方接收消息时，确定发送方地址是登记在地址目录服务器中的白名单还是黑名单中，且然后确定是否拒绝接收。下文将描述实时检查发送方的细节。首先，如果接收消息，那么接收方的流通通讯服务器系统将检查请求消息交付给地址目录服务器以检查发送方是否为合法用户。接着，地址目录服务器检查请求用户的地址信息是否包括在白名单中。接着，如果地址不在白名单中，那么地址目录服务器立即返回结果消息到检查请求方，所述结果消息指示请求用户为非登记用户。如果地址包括在白名单中，那么地址目录服务器检查对应地址是否登记在黑名单中。接着，地址目录服务器将是否登记在黑名单中的结果消息返回到检查请求方。接着，如果接收方从地址目录服务器接收到指示发送方不是合法用户（不包括在白名单中或者登记在黑名单中）的结果消息，那么接收方将接收消息自主处理为垃圾消息，且然后记录和存储从地址目录服务器接收的处理结果消息以及垃圾消息接收记录。接着，垃圾消息处理记录需要存储达一个月或者更长时间，以确认对于对应发送方的接收拒绝合法性。此外，在定期检查发送方的过程中，如图29所示，接收方预先从地址目录服务器接收白名单和黑名单，自主管理白名单和黑名单，以及藉此确定发送方地址是否登记在白名单和黑名单中以确定是否拒绝消息接收。下文将描述定期检查发送方的过程细节。首先，接收方的流通通讯服务器系统预先向地址目录服务器请求最新白名单和最新黑名单，且自主管理白名单和黑名单。在此情况下，如果名单变更，那么交付是否请求自动通知。即使请求名单变更事件的自动通知，导入地址目录服务器中最新名单的请求也定期执行，使得名单信息差异最多为一天。接着，如果白名单和黑名单变更，那么地址目录服务器将变更细节广播给请求变更通知的用户。接着，接收名单变更事件的用户的流通通讯服务器系统修改被自主管理的名单信息以同步于该名单。接着，如果接收到消息，那么接收方检查自主管理的名单以检查是否为地址目录服务器的合法用户。接着，作为检查自主管理的名单的结果，如果确定发送方不是合法用户（不包括在白名单中或者登记在黑名单中），那么接收方将接收消息自主处理为垃圾消息且记录和存储垃圾消息接收记录。接着，垃圾消息处理记录需要存储达一个月或者更长时间，以确认对于对应发送方的接收拒绝合法性。【流通通讯服务器系统】下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档流通系统的流通通讯服务器系统。流通通讯服务器系统大致由消息发送、消息接收、接收消息的邮箱管理、消息安全性（用户认证、文档加密/解码）、收发记录管理、地址目录服务器连接、消息验证、内部系统连接接口、流通证书发行和管理以及第三方存储机构连接构造。图37示出了流通通讯服务器系统的构造。参考图37，将如下详细描述流通通讯服务器系统的组件（1）到（9）。（1）消息发送/接收-根据流通协议发送和接收消息。（2）每个用户的账户（邮箱）管理-发送或者接收消息根据用户账户或者内部标识符存储于每个账户的邮箱中。-对于存储于邮箱中的发送文档，管理四个阶段状态信息，包括“发送过程”、“发送完成”、“发送失败”和“负责人完成接收”。在此情况下，“发送过程”的状态是指当在发送文档之后未从接收方接收到响应时的状态，“发送完成”状态是指从接收方的流通通讯服务器系统接收到“接收证书”时的状态，“发送失败”状态是指由于在接收流通通讯服务器系统内部发生错误或者在收发过程中发生网络错误导致返回SOAP故障消息时的状态，以及“负责人完成接收”状态是指当发送流通通讯服务器系统从接收方接收到用于证实负责人检查文档的“读取证书”时的状态。-对于存储于每个用户账户的邮箱中的接收文档，管理四个阶段状态信息，包括“验证错误”、“接收确认之前”、“接收确认”和“读取确认”。在此情况下，“验证错误”状态是指在验证接收消息的基本结构中发生错误时的状态，“接收确认之前”状态是指在接收文档负责人读取邮箱中的接收文档列表之前的状态，“接收确认”状态是指接收文档负责人已经读取邮箱中的接收文档列表时的状态，以及“读取确认”状态是指接收文档负责人已经读取接收文档的细节时的状态，接收方的流通通讯服务器系统在此时发行“读取证书”，且然后将“读取证书”交付给发送方。-如果从接收用户接收到删除请求，那么物理删除相应的接收文档。-在邮箱中，发送文档、发送的接收确认消息以及接收负责人的接收确认消息具有连接信息以相互连接。（3）地址目录服务器连接-流通通讯服务器系统根据由地址目录服务器提供的地址信息登记和搜索处理来管理地址信息。-流通通讯服务器系统包括可调用由地址目录服务器提供的服务的客户端功能。换言之，流通通讯服务器系统提供远程调用由地址目录服务器提供的地址信息登记、搜索、编辑和删除功能的服务客户端功能。（4）消息安全性（用户认证、文档加密/解码）-流通通讯服务器系统基本上执行由流通协议建议的消息安全性功能（消息数字签名、签名验证）。（5）发送/接收记录管理-流通通讯服务器系统必须存储/管理发送/接收记录达至少一年或者更长时间。-关于待存储的发送/接收记录的信息包括发送记录和接收记录。发送记录包括消息id、相关消息id、发送方（包括用户账户）、接收方、发送时间以及发送文档的哈希值。接收记录包括发送方、接收方（包括用户账户）、接收时间以及接收文档的哈希值。（6）流通证书发行和管理-流通通讯服务器系统发行和管理流通证书，以证实文档发送和接收事件的内容。-发行的流通证书被请求存储于第三方存储机构中，同时证书被交付以确保可靠性。-在发行流通证书之后，流通通讯服务器系统管理存储于第三方存储机构中的流通证书的记录。流通证书的发行记录包括流通证书id、流通证书发行时间、相关消息id、流通证书原件（可选）以及在将流通证书存储于第三方存储机构中之后接收到的存储密钥信息。（7）消息封装过程（封装、解析、提取）-流通通讯服务器系统在发送发送文档之前，将发送文档封装为在流通协议中定义的消息结构。-流通通讯服务器系统利用在流通协议中定义的消息结构来解析（语法分析）接收文档，并提取必要信息。（8）请求存储流通证书-为了请求存储流通证书，一般收发实体将第三方存储机构存储请求消息发送到第三方存储机构的流通通讯服务器系统（远程存储请求）。-如果接收到认证电子文档存放处存储请求消息，那么第三方存储机构的流通通讯服务器系统调用存储请求客户端，以将流通证书存储于第三方存储机构中。-如果第三方存储机构的流通通讯服务器系统直接创建流通证书，那么第三方存储机构的流通通讯服务器系统直接调用第三方存储机构的存储请求客户端（本地存储请求）。-用于请求存储流通证书的客户端根据第三方存储机构的收发连接接口标准请求第三方存储机构存储流通证书。（9）附加服务-流通通讯服务器系统流通流通客户端应用程序管理并且管理流通客户端应用程序管理版本。-流通通讯服务器系统执行消息流通管理（记录或者统计信息）。-流通通讯服务器系统执行系统管理（系统监控或者环境信息）。-流通通讯服务器系统执行文档格式管理。如果根据本发明的包括上述组件（1）到（9）的流通通讯服务器系统应用于第三方存储机构，如图38所示，那么当存储流通证书时，流通证书存储请求模块调用根据第三方存储机构连接接口标准开发的连接接口客户端，以请求存储流通证书。如果根据本发明的包括上述组件（1）到（9）的流通通讯服务器系统应用于一般收发实体（一般企业实体），如图39所示，那么通过这样的方法存储流通证书：即，该方法将用于存储流通证书的请求消息发送到第三方存储机构的流通通讯服务器系统并接收处理结果。使用根据本发明的包括上述组件（1）到（9）的流通通讯服务器系统在发送方和接收方之间直接流通的过程由四个步骤构成，包括“（1）获得接收方物理信息和安全性信息”、“（2）发送消息和确认发送”、“（3）确认任务接收方的接收”和“（4）发行和存储流通证书”。将参考图40详细描述所述四个步骤。（1）接收方物理地址和安全性信息获取-发送方系统请求物理地址信息和安全性信息（如果需要发送消息的接收密码），其中实际消息基于另一方的地址信息交付给地址目录服务器以获得物理地址信息和安全性信息。-在流通客户端应用程序向地址目录服务器请求接收方物理地址信息和安全性信息之后，接收方物理地址信息被交付给流通通讯服务器。-接收方地址信息可只使用用户id（例如，居民登记号码或者企业登记号码）来获得，用户id只有当接收方允许发送方基于id搜索地址信息时才是可用的。如果发送方已经知道接收方物理地址信息和安全性信息，那么这个过程可省略。（2）消息发送和发送确认在根据流通协议标准来封装消息之后，发送方基于流通通讯服务器系统的证书进行数字签名。-流通通讯服务器系统发送以先前获得的物理地址封装且数字签名的消息。-接收消息的流通通讯服务器系统验证基本封装结构、数字签名有效性和发送方适用性（对于验证的详细内容，请参考“2.4.6消息验证”），且然后创建用于接收确认的接收证书或者错误消息。-接收流通通讯服务器系统将创建的响应消息发送到发送方。-发送和发送确认过程由同步消息处理构造。（3）任务接收方的确认接收-如果发送方在发送消息时，请求任务接收方负责人的读取确认消息，那么接收方必须创建用于证实负责人读取确认的读取证书，以在确认企业消息接收时将读取证书交付给发送方。-如果接收方将负责人读取确认的读取证书消息发送到消息发送方，那么消息发送方同步发送接收确认消息。（4）流通证书发行和存储-如果需要每个步骤流通的证据，那么发送方根据所述步骤发行接收证书、读取证书和发送证书并将证书存储于第三方存储机构中，以确保流通法律证据的基础。使用根据本发明的流通通讯服务器系统在发送方和接收方之间直接流通消息的过程除了执行上述“（1）获得接收方物理信息和安全性信息”、“（2）发送消息和确认发送”、“（3）任务接收方的确认接收”和“（4）发行和存储流通证书”之外，还执行“（5）错误处理”。参考图90至图92，下文将详细描述错误处理功能。（5）错误处理功能流通通讯服务器系统的所有消息收发过程都是基于同步处理。因此，因为所有发送错误由发送方检查，所以基本上消息重新发送。通过设定相同MessageId值来重新发送相同消息，使得在成功接收消息之后，即时在在发送接收确认消息过程中发生错误时，接收方可通知冗余消息。即使在请求消息发送失败时，流通通讯服务器系统遵循如图41所示的处理流程图。换言之，当在由消息发送方发送消息的过程中由于网络错误而发生发送错误时，如果发送方接收到错误消息（诸如HTTP错误），那么发送方请求重新发送相同消息。只有当发送方接收到接收确认消息时，发送方识别发送成功。当响应消息接收失败时，流通通讯服务器系统遵循如图42所示的处理流程图。换言之，即使消息正常交付给接收方，如果发送方未从接收方接收到接收确认消息，那么发送方识别为发送失败错误，并利用相同MessageId将相同消息重新发送到接收方。如果接收文档的MessageId与先前接收的消息相同，那么接收方发送接收确认消息作为冗余接收并执行内部处理。当错误消息接收失败时，流通通讯服务器系统遵循如图43所示的处理流程图。换言之，即使正确交付从发送方发送到接收方的消息，但当由于发送消息错误而作为响应接收到错误消息时，发送方根据错误类型不同地处理消息。然而，根据重新请求发送的消息MessageId不需要为相同，但根据企业情况可改变。将如下详细描述在如上所述根据本发明的流通通讯服务器系统中基本需要的“（1）消息收发功能”、“（2）接收消息邮箱管理功能”、“（3）消息安全性功能”、“（4）收发记录管理功能”、“（5）地址目录服务器连接功能”、“（6）消息验证功能”、“（7）内部系统连接接口功能”和“（8）流通证书发行和管理功能”。（1）消息收发由流通通讯服务器系统收发消息的基本过程遵循如上所述根据本发明的“电子文档流通方法”的“文档收发方法”。作为收发消息基础的消息交换类型是基于消息流通协议的同步响应，且可形成发送消息和接收确认消息、发送消息和接收错误消息、发送消息和企业响应消息（包括接收确认消息的含义）的构造。消息收发类型包括两个类型，包括发送和接收确认响应消息的组合以及发送和企业响应消息的组合。消息收发类型为发送和接收确认响应消息的组合时的处理流程在图44中示出。发送消息和接收确认（或者接收错误）消息由SOAP（简单对象访问协议）请求-响应组合构成，且发送消息及其响应消息通过将发送消息MessageId插入于待发送的响应消息的RefToMessageId中来连接，其细节将参考下文将描述的【流通协议】描述。消息收发类型为发送和企业响应消息的组合时的处理流程在图95中示出。发送消息以及包括接收确认（或者接收错误）消息的响应消息由SOAP请求-响应组合构成。在接收方接收消息且然后实时创建对与内部系统有关的业务处理的响应文档之后，响应文档和接收确认ACK消息包括在响应消息中以交付给发送方。发送消息及其响应消息通过将发送消息MessageId插入于待发送响应消息的RefToMessageId中来连接，其细节将参考下文将描述的【流通协议】描述。收发消息的结构具有如图46所示的多部分-MIME结构。SOAP消息插入于第一MIME部分中，且待发送文档插入于第二或者后续MIME部分中。由SOAP标头和SOAP体块构成的SOAP封装包插入于第一MIME中。用于收发消息的消息标头、数字签名、接收确认消息、同步发送标记和错误消息插入于SOAP标头中。此外，在第二MIME部分中，插入待交付给消息接收方的文档（信息）。如果负责人的接收确认消息交付，那么文档插入于这个位置中。在第三MIME部分中，如果有两个以上文档（信息）待交付给消息接收方，那么文档依次插入于第三或者后续MIME部分中。（2）接收消息邮箱管理如果接收到消息，那么流通通讯服务器系统将接收消息存储于每个账户的邮箱中。接收消息邮箱针对一个或者多个用户账户是分开的，以存储和管理消息。接收消息邮箱需要提供根据用户请求（新接收消息存在性、接收消息读取、接收消息下载以及接收消息删除）执行所需过程的接口，并以标准化方式返回结果。为了使由流通通讯服务器系统管理的用户账户取得包括在电子文档流通中的认证电子邮件地址的资格，流通通讯服务器系统需要满足认证要求以具有可靠用户账户（要求将由独立评估指导手册定义，目前，人们认识到，只有第三方存储机构满足认证要求）。因此，允许个人或者企业（机构）获得电子文档流通中认证电子邮件地址的方法包括以下两个方法。第一方法为自主建立流通通讯服务器系统并认证流通通讯服务器系统以将获得的收发实体ID登记于地址目录服务器中的方法。第二方法为在另外满足在认证流通通讯服务器系统中具有可靠用户账户的要求的收发实体中打开邮箱以接收用户ID且然后将用户ID登记于地址目录服务器中的方法。（3）消息安全性发送消息安全性被分为用于确保完整性的数字签名以及用于确保机密性的加密/解码。通过流通通讯服务器系统发送的消息分为SOAP消息和附加文档。在此情况下，附加文档在流通客户端应用程序中已经被加密，且只有用于收发消息的标头信息包括在SOAP封装包中，使得在流通通讯服务器系统中不执行另外加密过程，但在消息收发过程中执行防止伪造的数字签名过程。数字签名方法和详细程序参考下文将描述的【流通协议】。（4）收发记录管理流通通讯服务器系统需要管理收发记录信息，以在将来引起与发送/接收相关的纠纷或者问题时检查记录。记录信息不仅可包括与收发动作有关的信息，而且包括实际发送/接收文档。如果实际文档存储于第三方存储机构中，那么仅存储从第三方存储机构接收的登记证书而不存储文档原件。（5）地址目录服务器连接使用由地址目录服务器提供的服务连接接口，流通通讯服务器系统与地址目录服务器连接。地址目录服务器提供两种地址搜索服务、地址登记服务和地址变更服务。流通通讯服务器系统基本上提供地址搜索服务中“与认证电子邮件地址相关的物理地址搜索服务”功能。除搜索服务外，根据是否使用流通被通讯服务器系统以较低级别登记/管理为企业或者个人的认证电子邮件地址的用户账户，来确定是否使用地址登记服务和地址变更服务。如果流通通讯服务器系统登记/管理的用户账户被认证，从而被登记为认证电子邮件地址，因为流通通讯服务器系统通过代理服务器执行认证电子邮件地址的登记和变更服务，所以连接地址目录服务器的相应服务。（6）消息验证当流通通讯服务器系统发送/接收消息时，接收方在接收消息时验证消息有效性，与图47所示的过程相似，在验证消息有效性之后，只有消息通过验证时，接收方才将消息接收确认消息交付给发送方。否则，接收方发送关于接收消息的错误消息。验证目标：接收消息的架构验证（验证是否根据流通协议正确封装接收消息）、消息完整性验证（验证接收消息的数字签名值以验证消息为完整而无伪造）以及消息发送方验证（验证用于数字签名的证书拥有者是否与消息发送方相同，以认证对消息进行数字签名的发送方是否与消息上表示的发送方相同）。（7）内部系统连接接口流通通讯服务器系统提供标准化收发接口，以允许内部系统通过流通通讯服务器系统发送和接收文档。接口细节将参考下文将描述的【流通客户端应用程序】描述。（8）流通证书发行和管理流通证书的基本条件为（1）通过发送和接收流通通讯服务器系统创建流通证书，（2）通过基于GPKI和NPKI证书执行数字签名来创建流通证书，和（3）基于电子文档流通动作创建流通证书（在此情况下，如果当电子文档流通一次时交付一个或者多个电子文档，那么创建一个流通证书并分配ID以识别相应流通，以流通一个电子文档，且藉此通过流通创建流通证书）。当发行流通证书时，认为：（1）因为由个人收发实体创建流通证书的序列号，所以使用20字节随机数以给予唯一性，这不同于现有证书的标准，（2）未定义流通证书的更新和撤销，（3）创建流通证书和流通客户端应用程序的流通通讯服务器系统的系统时间始终保持当前时间，以及（4）流通证书策略只使用在技术标准中定义的OID和名称。流通证书发行过程在图48中示出，且流通证书类型以及创建流通证书所需的基本信息在以下表141中描述，以及获得流通证书基本信息的方法将在以下表142中描述。【表141】【表142】流通证书由收发实体创建，且使用收发实体的NPKI和GPKI证书来数字签名。作为流通证书的基本结构，使用CMS标准的SignedData结构，且使用与证书等同的内容标识符。流通证书的内容类型如下。流通证书的基本字段如下：下文将描述如上所述的流通证书基本字段的细节。（1）版本-版本指示流通证书结构的版本。版本设定为流通证书v2，且dataHash用在目标字段中。ARCVersion::=INTEGER{v1(1),v2(2)}（2）序列号-序列号指示流通证书的识别信息。流通证书由接收电子文档的收发实体创建，使得序列号识别号码为无用。此外，当重新安装收发实体的流通客户端时，很难保持序列号。因此，流通证书的识别信息使用20字节随机数。因此，为了处理流通证书，应当能够处理20字节随机数。SerialNumber::=INTEGER（3）发行方、证书发行方-输入发行流通证书的发行方的证书识别值。此字段的值需要具有与对流通证书数字签名的签名方的证书中SubjectName字段相同的值。（4）dateOfIssue，发行证书日期-dateOfIssue指示发行方发行流通证书的时间。（5）dateOfExpire，证书到期日期-dateOfExpire是指流通证书的到期日期。（6）策略，证书策略-策略是指流通证书的策略。根据证书类型，改变所有流通证书中的策略OID，且仅使用存储于技术标准中的值。-根据块中证书类型，流通证书具有一个OID。-Qualifier值在UserNotice>ExplicitText>DisplyText中表示为UTF8字符型，并使用特定句子。-根据流通证书类型，使用以下表143中表示的策略信息。【表143】证书类型策略OIDQualifier发送证书1.2.410.200032.2.?.1发送证书接收证书1.2.410.200032.2.?.2接收证书接收确认证书1.2.410.200032.2.?.3接收确认证书（7）requestInfo，证书请求消息信息-这个字段设定为空（NULL）。RequestInfo::=CHOICE{arcCertRequestARCCertRequest,nullNULL}（8）目标，证实目标-指定所有流通电子文档的哈希值。这个字段必须使用流通信息方法。用于opRecord和orgAndIssued、dataHash字段的结构是指第三方存储机构的“证书格式和操作程序技术标准”。-关于流通电子文档的信息包括在流通信息（DistributionInfos）字段中。（1）-1senderAdd，认证电子邮件地址-这个字段指示发送方的认证电子邮件地址。（1）-2receiverAdd，接收方的认证电子邮件地址-这个字段指示接收方的认证电子邮件地址。（1）-3dateOfSend，发送日期和时间-这个字段指示发送方发送电子文档的时间。-在发送证书情况下，dateOfSend指定发送方请求发送到电子文档流通中心的时间。-发送证书只包括这个字段，但不包括dateOfReceive和dateOfReceiveConfirm。（1）-4dateOfReceive，接收日期和时间-这个字段指示接收方接收电子文档的时间。这个时间需要等于或者早于证书创建时间。接收证书和读取证书需要包括这个字段。相反，发送证书不包括这个字段。（1）-5dateOfReceiveConfirm，读取日期和时间-这个字段指示接收方接收和检查电子文档的时间。这个时间需要等同于或者滞后于接收日期和时间且等同于或者早于证书创建时间。读取证书需要包括这个字段。相反，发送证书和接收证书不包括这个字段。（1）-6distributionId，流通识别值-这个字段指示电子文档流通的识别值。为了创建这个字段，创建和使用20字节随机数。这个字段值指示分配给电子文档流通的流通消息的识别值。（1）-7numberOfFiles，流通文件数-在流通中可交付一个或者多个电子文档，且这个字段指示在一个流通中交付的文件数。（1）-8distributedFileInfos，流通文档信息-在流通中可交付一个或者多个电子文档，且所有待交付文档的信息需要包括在这个字段中。（1）-8-1fileHashedData，文件哈希信息-这个字段指示流通和交付电子文档的哈希值。（1）-8-2fileId，文件识别值-当识别值分配给待流通电子文档时，指定用于对应文档的识别值。文件识别值由发送方创建且需要在将电子文档交付给接收方时一起交付。接收方将交付文件识别值应用于这个字段。-发送方使用uuid方法创建这个字段。-这个字段可选择性使用，但是如果fileName字段未使用，那么这个字段必须使用并推荐字段使用。（1）-8-3fileName，文件名称-这个字段指示待流通电子文档的文件名称。文件名称由发送方指定，且需要在将电子文档交付给接收方时一起交付。接收方将交付文件识别值应用于这个字段。-这个字段可选择性使用，但是如果fileID字段未使用，那么这个字段必须使用。上述与流通证书时间信息相关的一致性标准将在以下表144中描述。【表144】时间信息顺序为发送日期和时间<接收日期和时间≤读取日期和时间≤证书发行日期<证书到期日期。当验证流通证书时，需要检查以上顺序。流通证书验证包括证书结构验证、证书数字签名验证、证书主要字段检查以及证书时间信息一致性验证。证书结构验证为验证证书是否与ASN.1中定义的相同的过程。证书数字签名验证为验证应施加于流通证书的数字签名的过程。证书主要字段检查包括检查版本字段值是否为v2的版本字段检查、检查目标字段是否为hashData的目标字段检查、验证用于数字签名的证书DN是否与证书基本字段的DN相同的发行方信息验证、检查requestInfo字段是否为Null的requestInfo字段检查、检查distributionInfos扩展字段是否存在且判定为真的扩展字段检查、检查numberOfFiles字段值是否等于distributionInfos扩展字段中DistributedFile数目的文件数检查、检查目标字段哈希值是否等于distributionInfos扩展字段的哈希值的目标字段哈希值检查以及根据时间信息一致性验证准则验证的时间信息一致性验证。证书时间信息一致性验证基于流通证书时间信息一致性验证准则来验证。同时，流通认证是指认证在使用可靠方法流通电子文档的过程中出现的发送、接收和接收确认事实的动作。流通认证在单独应用程序中执行，但是在流通证书查看器和流通认证API中不执行。如果对流通证书认证另外执行流通认证，那么将执行以下。-流通证书验证：验证流通证书。-流通证书策略检查：检查流通证书策略OID以及发送、接收和接收确认Qualifier值。-发送方地址检查：检查发送电子文档的收发实体地址是否正确。-接收方地址检查：检查接收电子文档的收发实体地址是否正确。-发送日期和时间检查：检查发送方发送电子文档的时间是否正确。-接收日期和时间检查：检查接收方接收电子文档的时间是否正确。-接收确认日期和时间检查：检查接收方确认电子文档接收的时间是否正确。-流通ID检查：检查分配给个人流通情况的流通ID是否正确。如果发送方和接收方分开存储和管理流通ID，那么可比较和管理流通ID。-流通文件标识符或者文件名称检查：检查待流通文件ID或者名称是否正确。如果发送方和接收方分开存储和管理文件ID和文件名称，那么可比较和管理文件ID和文件名称。-流通文件哈希值检查：检查待流通文件的哈希值是否等于扩展字段的DistributedFile字段值。在此情况下，流通证书中指定的哈希算法用于比较哈希值和字段值。同时，流通证书的配置文件将在以下表145中描述。应当考虑，将RSA2048位和SHA256算法应用于数字签名，在signedData结构中必须包括证书，且在signerInfos字段中只包括一个signerInfor。【表145】在如上所述将流通证书与第三方存储机构连接的方法中，请求将流通证书存储于第三方存储机构中，同时发行流通证书以确保发行流通证书的可靠性。在第三方存储机构提供商的流通通讯服务器系统的情况下，流通证书存储过程在图49中示出。第三方存储机构连接模块直接请求将从流通通讯服务器系统发行的流通证书直接存储于第三方存储机构中。第三方存储机构连接模块由流通证书存储请求模块和第三方存储机构连接接口客户端模块构成。根据现有第三方存储机构连接接口模块标准，流通证书存储于第三方存储机构中。在一般收发实体的流通通讯服务器系统的情况下，流通证书存储过程在图50中示出。为了请求第三方存储机构提供商存储所发行的流通证书，请求消息交付给第三方存储机构提供商的流通通讯服务器系统。从外部接收存储请求的第三方存储机构提供商的流通通讯服务器系统请求通过第三方存储机构连接接口将流通证书存储于第三方机构中。第三方存储机构连接模块请求第三方存储机构根据现有第三方存储机构连接接口模块标准来存储流通证书。收发实体将流通证书存储于第三方存储机构中的详细处理在图51中示出，且下文将描述细节。○流通证书登记-当流通证书存储于第三方存储机构中时，可通过第三方存储机构提供商和收发实体之间协议来指定存储机构。存储机构使用证书将流通证书存储于第三方存储机构中。○第三方存储机构的存储请求过程类型-第三方存储机构提供商可提供同步处理和异步处理中至少一个，且根据由待连接第三方存储机构提供商提供的方法来连接流通通讯服务器。-情况1：同步处理过程（当发送方请求存储流通证书时，同步执行完成流通证书登记于第三方存储机构中之后的发行登记证书的所有过程，使得发送方的流通通讯服务器接收登记证书作为同步响应消息。因为请求的响应消息为第三方存储机构的最终登记结果，所以如果发生存储请求错误，那么通过发送方的流通通讯服务器进行重新处理。）-情况2：异步处理过程（如果发送方请求第三方存储机构流通通讯服务器存储流通证书，那么第三方存储机构流通通讯服务器首先验证请求消息有效性，然后接受存储请求。第三方存储机构提供商需要将根据存储请求消息登记于第三方存储机构中的待发行登记证书交付给发送方的流通通讯服务器，发送方为第一存储请求方。因为第三方存储机构提供商负责将登记证书登记于接受存储请求的第三方存储机构中，所以如果发生存储错误，那么也通过第三方存储机构提供商进行重新处理。）【流通协议】下文中，将详细描述应用于如上所述根据本发明示例性实施方式的电子文档流通系统和方法的流通协议。在应用于根据本发明示例性实施方式的电子文档流通系统和方法的流通协议的描述中，将以顺次描述“（1）消息封装”、“（2）消息封装包配置”和“（3）HTTP绑定”。（1）消息封装流通协议的消息结构应用ebMSv2.0标准，且具有两个逻辑MIME部分。第一MIME部分包括SOAP消息且称为标头容器。SOAP消息由标头和体块构成。第二MIME部分为0个或者多个另外MIME部分且也称为净荷容器。第二MIME部分包括应用程序级附加文档。流通消息的基本结构在图52中示出，且遵守诸如简单对象访问协议（SOAP）1.1和带附件SOAP消息的标准。流通消息封装包的MIME标头的所有组成要素遵守带附件SOAP消息的标准。此外，消息封装包中的内容类型MIME标头必须具有与包括SOAP消息文档的MIME体块部分的MIME媒体类型相同的类型属性。根据SOAP标准的SOAP消息的MIME类型需要具有“text/xml”值。根部分需要包括Content-IDMIME标头，Content-IDMIME标头具有基于【RFC2045】的结构，且除Multipart/相关媒体类型的基本参数外，开始参数（在【RFC2387】中可选）需要始终存在。下文中，在描述根据本发明的流通消息时，消息封装包的路由体块部分定义为标头容器。标头容器包括一个SOAP消息作为MIME体块部分，如带附件的SOAP消息规范中所定义的。根据SOAP标准，标头容器的MIME内容类型标头需要具有“text/xml”值。内容类型标头可包括“字符集”属性。MIME字符集属性用于区分用于创建SOAP消息的字符组。这个属性的语义在【XMLMedia】中明确表达的text/xml的“字符集参数/编码审议”中描述。有效值列表可在http://www.iana.org/中找到。如果MIME字符集属性包括内容类型标头，那么MIME字符集属性需要等同于SOAP消息的编码说明部分。此外，MIME字符集属性不包括当创建SOAP消息时与编码冲突的值。当这个文档被编码时，{UTF-8}必须用于使兼容性最大化。然而，由于为从text/xml【XMLMedia】演绎的媒体类型所定义的处理规则，这个MIME属性不具有默认值。根据带附件SOAP消息的标准，消息封装包中可包括0或者多个净荷容器。如果消息封装包包括应用程序净荷，那么消息封装包必须包括在净荷容器中。如果消息封装包不包括应用程序净荷，那么净荷容器不存在。净荷容器的内容通过SOAP体块中ebXML消息Manifest元素来区分。基于【RFC2045】标准，根据本发明的流通消息的所有MIME部分可包括另外MIME标头。在实施中，本发明中未定义的MIME标头可忽略，且未识别的MIME标头应当忽略。例如，在实施中，内容长度可包括在消息中。然而，包括内容长度的消息的接收方可忽略内容长度。（2）消息封装包配置基于SOAP标准，所有扩展元素的内容需要限于可用名称空间。本发明中定义的所有ebXMLSOAP扩展元素的内容需要限于ebXMLSOAP封装包扩展名称空间。名称空间的说明部分可包括在SOAP封装包、标头或者体块元素中，或者直接包括在每个SOAP扩展元素中。SOAP封装包将SOAP消息中各种Namespace申明为SOAP消息的根项目。待申明Namespace为如以下表150。【表150】消息封装包的架构结构在图102中示出。以下将顺次描述作为SOAP封装包元素的子元素的SOAP标头元素和SOAP体块元素。SOAP标头元素为SOAP封装包元素的第一子元素，且包括扩展元素，诸如MessageHeader、SyncReply、Signature和ErrorList。MessageHeader为基本元素，包括消息路由选择信息（至/自）以及与消息有关的其它上下文信息，SyncReply为将基本发送状态指示给下一个SOAP节点的元素，Signature为指示基于【XMLDSIG】的数字签名的元素，【XMLDSIG】标记与消息相关的数据，以及ErrorList为具有针对先前消息所报告的且只有报告先前消息错误时使用的错误列表的元素。下文将描述MessageHeader元素的细节。MessageHeader元素为表达于所有ebXML消息中且表示SOAP标头元素的子元素的基本元素。MessageHeader元素为由以下子元素构成的复杂元素。MessageHeader的元素结构将在以下表152中描述，且MessageHeader的架构结构在图54中示出。【表152】SyncReply是指同步发送，且包括id属性、版本属性、SOAPactor属性（必须具有“http://schemas.xmlsoap.org/soap/actor/next”值）和SOAPmustUnderstand属性值。Signature元素需要作为SOAP标头的子元素存在，这是因为流通消息需要被数字签名以应对上述危险因素。根据【XMLDSIG】标准进行数字签名的过程如下。首先，创建具有SignatureMethod、CanonicalizationMethod的SignedInfo元素以及Reference元素以及SOAP封装包中的基本净荷对象，如【XMLDSIG】中定义。接着，在规范化之后，基于在如【XMLDSIG】中指定的SignedInfo中指定的算法计算SignedInfo的SignatureValue。接着，创建包括SignedInfo、KeyInfo（推荐）和SignatureValue元素的Signature元素，，如【XMLDSIG】中指定。接着，SOAP标头的Signature元素包括在SOAP标头元素中。如上所述在数字签名时使用的算法信息如下。算法基本上遵循W3C“XML签名语法和处理”（RFC3275）的算法部分（6.0算法）。此外，为了支持国内独特算法，使用在TTAS.IF-RFC3075“XML签名语法和处理”（电信技术协会，2004年）中定义的算法。用于根据本发明的流通协议中的算法列表包括数字签名NameSpace、哈希（Digest）、数字签名（Signature）、规范化和转换。为了在发送/接收消息时在创建和验证数字签名的过程中使歧义最小化，优选不使用不同于以下列表的算法。SHA1和SHA256可用作用于减少数据的算法，且示例将在以下表155中描述。由于物理上可不同地表示逻辑相同的文档的XML特性，数字签名值对于相同文档可能为不同。为了防止以上现象，需要进行规范化处理。。即使有各种转换算法作为经过对整个XML数据中待签名数据进行处理和选择的过程的算法，在各种转换算法中仅可使用三个算法。第一算法为封装包签名转换，这是因为数字签名遵守包括在签名目标中的形式，第二算法为上述规范化，以及第三算法为Xpath过滤，Xpath过滤选择签名目标信息。数字签名语法的结构在图55中示出。只有当在接收消息以处理消息的过程中发生错误时，ErrorList位于标头较低级别中。当产生ErrorList元素时，RefToMessageId必须存在于MessageHeader元素中，且RefToMessageId需要指定发生错误的消息MessageID。ErrorList元素具有诸如id属性、SOAPmustUnderstand属性、版本属性、highestSeverity属性的属性以及一个或者多个Error元素。ErrorList结构在图56中示出。在此情况下，如果没有错误报告，那么ErrorList元素不应当存在。highestSeverity属性指示所有Error元素的最严重状态。具体地，如果Error元素将严重性设定为Error，那么highestSeverity设定为Error。否则，highestSeverity设定为警告。Error元素具有id属性、codeContext属性、errorCode属性、严重性属性、位置属性和描述属性。id属性用于唯一区分文档中的ErrorList元素。codeContext属性表示errorCodes的名称空间或者架构，且应当为URI。这个属性的默认值为urn:oasis:names:tc:ebxml-msg:service:errors。如果这个属性没有默认值，那么规范实施指示使用errorCodes。作为基本属性的errorCode属性指示具有错误的消息的错误存在性。下文将描述errorCode有效值以及代码含义。作为基本属性的严重性属性指示错误严重性。有效值为警告和错误。警告指示不管错误，正常创建在会话过程中的其它消息。错误指示在消息中不存在恢复错误以及在会话过程中不再创建其它消息。位置属性指示存在错误的消息部分。如果ebXML元素中存在错误且元素为“良好形成”，那么位置属性的内容需要为【Xpointer】。描述属性的内容通过xml:lang属性中定义的语言提供错误的描述性解释。一般地，这个消息由验证XML解析器或者消息的软件产生。这意味着，内容由创建Error元素的软件销售商或者开发者定义。如果在基于流通协议收发消息的过程中发生错误，那么通知错误的收发实体需要将错误报告给其它另一方。待报告错误包括消息结构错误、可靠通讯错误和安全性错误。与属于比本发明中定义的流通协议更低层的数据通信协议（诸如HTTP和Socket）相关的错误通过数据通信协议支持的标准机制来发现和报告，且不使用本发明中定义的错误报告机制。错误代码通过错误目标和错误类型来分类，且其细节将在以下表161中描述。【表161】SOAP体块元素包括诸如Manifest的扩展元素作为SOAP封装包的第二子元素。Manifest为指示位于不同位置（诸如净荷容器或者web）中的数据的元素。Manifest元素为由一个或者多个Reference元素构成的复杂元素。Reference元素中每个作为净荷容器中包括的（多个）净荷文档的一部分被包括，或者区分与作为由URL可访问的远程资源的消息相关的数据。建议在SOAP正文中不加载净荷数据。Manifest的目的在于允许与ebXML消息相关的特定净荷被容易且直接访问，并允许在无需解析的情况下确定应用程序是否处理净荷。Manifest元素具有一个id属性、一个版本属性以及一个或者多个Reference元素。Reference元素为由子元素（包括0或者多个架构元素以及0或者多个描述元素）构造的复杂元素。在此情况下，0或者多个架构元素为与（多个）架构有关的信息，架构定义与父Reference元素区别的即时文档。此外，0或者多个描述元素为针对由父Reference元素引用的净荷对象的描述。Reference元素为【XLINK】的简单链接。根据实施要求，XLINK处理或者引擎并不一定使用，但可能有用。除上述元素的内容外，Reference元素还包括属性内容，诸如id、xlink-type、xlink:href、xlink:role。其它有效名称空间属性可能存在。接收MSH可忽略不同于以上定义的属性的外部名称空间属性。在此情况下，id为Reference元素的XMLID，xlink-type将元素定义为XLINK简单链接且具有“简单”固定值。xlink:href为所引用净荷对象的URI值且基于简单链路【XLINK】规范。xlink:role区分净荷对象或者描述净荷对象目的的资源。如果这个属性存在，那么这个属性需要具有基于【XLINK】规范的URI值。如果参考项目具有描述参考项目的（多个）架构（例如，XML架构、DTD或者数据库架构），那么Schema元素需要作为Reference元素的子元素存在。这用于区分架构和版本，且定义由父Reference元素区分的净荷对象。Schema元素具有诸如位置和版本的属性。在此情况下，位置为架构的基本URI，且版本为架构的版本标识符。如果xlink:href属性包括URI，URI为内容id（URI架构“cid”），那么具有内容id的MIME需要表达在消息的净荷容器中。否则，具有MimeProbem作为errorCode且Error作为severity的错误需要发送到发送方。如果xlink:href属性不包括URI，URI为内容id（URI架构“cid”），那么URI不被解释，因此根据实施确定是否发送错误。如果确定发送错误，那么具有MimeProbem作为errorCode且Error作为severity的错误需要发送到发送方。以下表162表示具有一个净荷MIME体块部分的消息的典型Manifest。【表162】（3）HTTP绑定在通过HTTP发送消息的方法中的HTTP绑定示例将在以下表163中描述。【表163】在本发明中，为了返回HTTP级别的响应代码，需要使用在【RFC2616】中定义的HTTP响应代码。主要响应代码将在以下表164中描述。【表164】【电子文档格式寄存器】下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档流通系统的电子文档格式寄存器。电子文档格式寄存器为允许收发实体创建、登记和管理在电子文档流通中流通文档所需的格式的系统。电子文档格式寄存器包括格式创建单元、格式登记单元和格式管理单元以及标准连接模块。格式创建单元包括PDF转换模块和PDF格式设计器。PDF转换模块提供将一般格式转换为PDF的功能（例如，创建标准PDF-A）。PDF格式设计器提供创建可写格式PDF的功能以及文档安全性功能，诸如二维条形码和防复制标记。格式登记单元提供允许用户登记格式（例如，一般格式，诸如HWP或者MS-Word）的功能。格式管理单元提供允许格式管理器登记和管理格式的功能，并提供每个类别的登记功能以及每个版本的记录管理功能。此外，提供控制每个格式查看时段、查看次数和打印次数的设定功能。标准连接模块提供与流通客户端应用程序连接的功能。此外，还提供格式列表搜索功能和文件下载功能。根据本发明的电子文档格式寄存器的格式登记过程在图57中示出。使用格式设计器，将标准电子文档创建为FormPDF，且基本要求将在以下表165中描述。【表165】在标准电子文档的结构中，要求距离文档下边缘大约5cm的距离。根据数据量可改变条形码大小，防复制标记大小为3>1.3且根据格式形状适当地设置。标准连接模块（标准接口）允许用户搜索和下载格式并在流通客户端应用程序中创建格式，且提供给包括在流通客户端应用程序中的WebUS（用户接口）。标准连接模块提供搜索每个类别、格式列表以及文件下载的功能。【电子文档封装】下文中，将详细描述应用于如上所述根据本发明示例性实施方式的电子文档流通系统和方法的电子文档封装。电子文档封装为允许收发实体在电子文档流通中流通文档所需的通讯系统标准。电子文档封装由标准电子文档和附加文档构造，且由标准电子文档的元数据构造。基于PDF-A创建标准电子文档，且通过诸如文档安全性功能的信息来构造元数据。附加文档不被转换为PDF，而而实际上封装到原件中。标准电子文档通过用户证书来数字签名，且在封装之后，电子文档封装包被数字签名以包括在封装包中。图59示出了电子文档封装包结构。参考图59，根据本发明的电子文档封装包结构包括封装包标头、元数据、标准电子文档、附加文档和数字签名数据。其详细组成要素将在以下表27至表31中描述。封装包标头包括整个封装包结构信息。元数据包括标准电子文档的文档安全性功能的信息，且还包括诸如文档读取次数、打印次数的信息以及二维条形码信息。标准电子文档以标准PDF-A型构造，且二维条形码数据包括在PDF文件中的图像区中，以及数字签名数据包括在标准PDF签名数据区中。附加文档不是标准电子文档，而是典型文档。因此，从应用文档安全性功能的目标排除附加文档。使用包括在封装中的用户证书，数字签名数据对封装数据进行数字签名。【表166】编号组成要素备注1整个文件大小2元数据大小3标准电子文档大小4附加文件数5附加文件大小【表167】编号组成要素备注1读取次数2打印次数3存储功能4文本提取功能5临时存储/导入功能6文档类型7二维条形码大小(横向)【表168】编号组成要素备注1PDF文件【表169】编号组成要素备注1附加文件【表170】编号组成要素备注1数字签名数据验证电子文档封装的方法包括（1）验证电子文档封装数字签名的方法、（2）验证标准电子文档的方法和（3）验证打印电子文档的方法，下文将描述所述方法。（1）验证电子文档封装数字签名的方法-当处理数字签名封装时，客户端应用程序验证数字签名。只有当验证成功时，客户端应用程序才将标准电子文档交付给电子文档查看器。-此外，客户端应用程序支持手动数字签名验证功能，以当发生纠纷时验证数字签名。（2）验证标准电子文档的方法-当读取标准电子文档时，电子文档查看器验证数字签名。只有当数字签名验证成功时，在电子文档查看器中读取文件。（3）验证打印电子文档的方法-使用另外提供的验证程序和平板扫描仪，验证二维条形码中的数字签名数据，并通过肉眼比较原始文档内容和打印文档内容。同时，因为需要根据最终接收电子文档的用户的打印机模式，产生防复制标记，所以防复制标记不包括在封装中。【流通客户端应用程序】下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档流通系统的流通客户端应用程序。为了允许企业或者个人基于认证电子邮件地址发送/接收文档（信息），需要提供支持发送/接收的用户接口（下文中简称为UI）的应用程序。作为发送/接收消息的通讯引擎，如果与电子邮件相比，流通通讯服务器系统充当邮件服务器，那么流通客户端应用程序（下文中简称为APP）充当类似于邮件客户端的用户应用程序，提供邮件客户端以允许用户与邮件服务器连接来发送/接收电子邮件。图60示出了流通客户端APP的结构图。参考图60，作为在想要使用流通通讯服务器系统交换文档的一般用户的UI环境下的应用程序，流通客户端APP基本上包括“（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）电子文档格式下载过程”作为附加过程。流通客户端APP与充当服务器的流通服务器系统连接以发送和接收文档。此外，流通客户端APP与电子文档格式登记服务器连接以登记标准文档格式。（1）文档发送过程流通客户端APP通过与流通客户端APP连接的流通通讯服务器系统发送电子文档到其它“收发实体”的步骤在图61中示出，且处理程序如下。首先，流通客户端APP创建待发送到接收方的消息。在此情况下，附加通过发送方预先创建的文档或者通过由流通客户端APP提供的文字处理器创建的文档并指定接收方，且然后创建消息。接着，在输入接收方地址信息之后，调用流通通讯服务器系统的发送接口以请求发送消息。接着，发送方的流通通讯服务器系统根据发送过程发送消息到接收方，且然后从接收方接收关于接收的响应消息（接收证书或者接收错误）。接着，发送方的流通通讯服务器系统接收关于接收的响应消息，且然后将响应消息作为对发送的响应交付给流通客户端APP。这里，第一步骤至第四步骤是基本的，且第二步骤至第四步骤同步执行。接着，如果发送方的流通通讯服务器系统从接收方接收包括读取证书的消息，读取证书确认接收负责人读取，发送流通通讯服务器系统返回接收响应消息，且将接收消息存储于用户邮箱中。接着，第一发送方的流通客户端APP向连接的流通通讯服务器系统请求接收文档。接着，发送方的流通通讯服务器系统将存储于邮箱中的接收文档列表交付给请求接收文档的用户的流通客户端APP。这里，第五步骤至第七步骤为只有当在发送第一消息时请求接收负责人读取确认时执行的选择性且可选程序。（2）文档接收过程流通客户端APP从其它“收发实体”接收电子文档的过程在图62中示出，且其处理程序将描述如下。首先，如果接收到消息，那么接收方的流通通讯服务器系统返回接收消息的接收响应消息到接收方，并将接收消息存储于用户邮箱中。接着，接收方的流通客户端APP登录所连接的流通通讯服务器系统以请求接收文档。接着，接收方的流通通讯服务器系统交付存储于请求接收文档的用户邮箱中的接收文档列表。这里，第二步骤和第三步骤为同步。接着，如果接收方请求从接收消息列表读取消息的详细信息，那么流通客户端APP将包括对应消息的附加文档的详细信息发送到流通通讯服务器系统。接着，如果最初发送方请求接收负责人读取确认，那么在用户请求接收文档的详细信息时，接收方的流通通讯服务器系统将包括读取证书的消息发送到对应消息的发送方。接着，接收方的流通通讯服务器系统接收在第五步骤中发送的负责人读取确认消息（读取证书）的接收响应消息。（3）电子文档格式下载过程流通客户端APP下载电子文档格式的过程在图63中示出，且其处理程序将描述如下。首先，流通客户端APP与电子文档格式登记服务器直接连接以请求搜索文档格式。在此情况下，基于由电子文档格式登记服务器提供的标准连接接口执行连接。接着，电子文档格式登记服务器返回关于搜索文档的信息作为结果。这里，第一步骤和第二步骤为同步。接着，流通客户端APP将搜索格式列表展示给用户以选择格式。接着，流通客户端APP请求电子文档格式登记服务器下载选定电子文档格式。接着，电子文档格式登记服务器返回请求格式到流通客户端APP。接着，流通客户端APP登记待插入的下载电子文档格式以用于文字处理器中。由上述流通客户端APP的流通通讯服务器系统提供的接口类型包括用户认证（登录）、退出、消息发送请求、接收消息获得、详细消息信息请求和消息删除。流通客户端APP和流通通讯服务器系统的连接方法（1）到（5）将描述如下。（1）流通通讯服务器系统的连接协议由流通客户端APP的流通通讯服务器系统提供的连接接口是基于与流通通讯服务器系统的收发协议相同的协议。在此情况下，流通客户端APP和流通通讯服务器系统提供单向同步通信，如图64所示，这不同于流通通讯服务器系统之间的发送/接收，且在它们之间使用消息数字签名认证或者用户认证方法。发送消息实际上使用流通通讯服务器系统的消息结构，用户信息以及请求消息和响应消息由图66所示的结构构造。其详细描述如下。-SOAP标头：根据基于如上所述【流通协议】配置的任务类型，流通客户端APP和流通通讯服务器系统可充当发送方或者接收方。SOAP标头包括消息标头和签名信息。-SOAP正文：包括上述【流通协议】中定义的Manifest元素信息和用户登录信息。-发送文档容器#1：在接收消息详细信息的情况下，包括消息发送请求、接收消息获得和正文文档（内容）。-发送文档容器#2：在从#2依次接收消息详细信息的情况下，包括消息发送请求和附加文档。SOAP标头结构将在以下表171中描述，消息标头结构将在以下表172中描述，SOAP正文结构将在以下表173中描述，以及正文消息结构将在以下表174中描述。【表171】【表172】【表173】【表174】（2）消息发送请求下文将描述在发送消息时由流通客户端APP交付给流通通讯服务器系统的基本信息。在完全发送之后存储于邮箱中的发送文档具有以下表175描述的四个状态信息步骤。【表175】（3）接收消息获取流通客户端APP通过与流通通讯服务器系统连接的登录用户账户读取接收消息的动作与在流通通讯服务器系统中删除消息的动作分开。以下两个状态信息步骤根据消息接收过程来管理。-接收用户是否读取邮箱中的接收文档列表-接收用户是否读取接收文档的细节（4）详细消息信息请求如果用户想要基于接收文档列表读取细节，那么流通客户端APP请求流通通讯服务器系统的消息详细信息。接收详细信息请求的流通通讯服务器系统将诸如消息的详细属性信息和消息附加文档的所有消息内容交付给流通客户端APP作为响应消息。（5）消息删除如果用户请求删除，那么流通客户端APP将文档删除请求交付给流通通讯服务器系统，且将结果通知给用户。当用户删除文档时，是否给予作为垃圾箱概念的临时删除功能为流通客户端APP的附加功能，而不是实际服务器上的动作。因此，流通客户端APP的开发者可确定是否提供临时删除功能，但必须提供请求流通通讯服务器系统删除的功能。【记录介质】根据本发明的电子文档流通方法可在通用数字计算机中实施，通用数字计算机使用由在计算机中可执行的程序创建的计算机可读记录介质来操作程序。计算机可读记录介质包括磁性存储介质（例如，ROM、软盘、硬盘或者磁带）、光学读取介质（例如，CD-ROM、DVD或者光学数据存储装置）和载波（例如，通过互联网传输）。下文中，以下将描述如上所述本发明中的地址目录服务器的另一个实施方式。【地址目录服务器】所有用户需要接收唯一电子邮件地址以参与可靠电子文档流通。电子邮件地址由以下结构表示。电子邮件地址：内部分隔符+间隔标记+唯一登记地址电子邮件地址示例为“gdhong#nipa.kr”。为了方便内部处理，电子邮件地址的内部分隔符由唯一登记地址拥有者选择性添加，如有必要，内部分隔符可省略。电子邮件地址的间隔标记为位于唯一登记地址之前或者存在于内部标识符和唯一登记地址之间的标记。例如，可使用“#”，如有必要，可使用其它标记。电子邮件地址的唯一登记地址为由企业/机构/个人请求发行的唯一ID值，且唯一登记地址的单位为发送和接收的法律责任单位。唯一登记地址为在收发实体自主建立流通通讯服务器之后或者通过电子文档第三方流通代理机构发行的唯一登记地址，且为电子地址的基本构造。收发实体对于其自己的流通通讯服务器系统具有实际物理地址（IP地址）。然而，物理地址与电子邮件地址不具有相关关系，物理地址和电子邮件地址具有1：N关系。一个电子邮件地址不具有多个物理地址。与间隔标记相邻存在的企业/机构/个人负责关于电子邮件地址的信息（电子文档）的合法接收，且为了方便企业/机构/个人，划分通过内部标识符的流通。因此，企业/机构/个人为此负责。电子文档流通系统中电子邮件地址的含义表示为图3所示的电子文档流通系统参与者的关系图。如上所述，将如下再次描述包括内部标识符和唯一登记地址的电子邮件地址。（1）内部标识符-不管地址目录服务器，由收发实体自主发行和管理内部标识符。-内部标识符为收发实体中的唯一值且可省略。-企业/机构/个人主要负责分配内部标识符的方法，且通过内部标识符的电子文档流通不具有基于电子文档流通的基础系统中的正式含义。-如果唯一登记地址为正式登记于地址目录服务器中的实体，使得负责接收的政府/公共部门/企业/机构/团体/个人打开第三方流通收发实体中的账户，那么为了方便企业任务，内部标识符被用于流通电子文档，且不登记在地址目录服务器中，而只是用作企业内部的信息。（2）唯一登记地址-参与电子文档流通系统中以流通电子文档的政府/公共部门/企业/机构/团体/个人自主建立流通通讯服务器系统，且然后接收唯一登记地址作为收发实体，或者通过第三方流通（通过代理服务器流通）代理机构接收唯一登记地址。-唯一登记地址的唯一性在发行时由地址目录服务器确认，以便不冗余发行。-政府/公共部门/企业/机构/团体/个人的唯一登记地址的配置方法由认证电子邮件地址管理机构策略来确定。如上所述的电子邮件地址基本上以两个级别管理。在认证电子邮件地址的最高部分，存在管理地址目录服务器的认证电子邮件地址首席管理者的机构（例如，国家IP产业促进机构），并且认证电子邮件地址首席管理者发行和管理较低收发实体的唯一电子邮件地址。在认证电子邮件地址首席管理者的较低收发实体中，能够进行第三方流通（通过代理服务器流通）的收发实体打开想要第三方流通的用户登记地址，且然后将地址信息登记在地址目录服务器中。在此情况下，为了保证用户唯一登记地址值的唯一性，需要从地址目录服务器确认冗余性。在电子邮件地址中，不管地址目录服务器如何，不是正式用户而是为了任务便利在内部发行和使用的内部标识符由收发实体自主发行和管理。发行电子邮件地址的系统在图4中示出，且图4所示元素的角色将在以下表184中描述。【表184】发行电子邮件地址的过程在图5中示出。用户（企业）可直接访问由地址目录服务器提供的屏幕，以登记或者编辑地址或者通过流通通讯服务器系统（由系统提供的网站）接收电子邮件地址，流通通讯服务器系统通过代理服务器发行经认证的电子邮件地址。参与流通的用户需要在发送消息到其它方之前基于电子邮件地址获悉实际物理地址信息，且进一步获取接收方的公钥信息，以加密所附文档。在电子文档流通过程中获取电子邮件地址的物理地址的过程为必要步骤，且发送方查询地址目录服务器，以基于接收方的地址信息获取接收方的物理地址信息和安全信息。如果发送方基于物理地址将发送文档交付给接收方，那么接收方的流通通讯服务器系统基于接收方地址信息接收发送文档，以根据用户账户或者内部标识符内部流通接收文档。获取电子邮件地址的物理地址和安全信息的过程在图6中示出。在电子文档流通中为了基于认证的电子邮件地址发送文档到接收方，有如下两个方法：（1）流通客户端APP在输入接收方地址信息时获取与地址目录服务器有关的必要信息，且然后请求流通通讯服务器基于搜索到的实际物理地址信息来发送文档，以及（2）流通客户端APP请求流通通讯服务器基于接收方的认证电子邮件地址来发送文档，并且在流通通讯服务器发送文档之前，流通通讯服务器获取地址目录服务器的物理地址和安全信息，且然后将文档发送到接收方。两个方法的过程在图7中示出。地址目录服务器提供远程服务，以使得流通通讯服务器系统搜索地址信息或者通过代理服务器发行地址。由地址目录服务器提供的服务包括地址搜索服务、地址登记服务和地址变更服务，且提供基于流通协议标准的以下服务接口。地址搜索服务为地址目录服务器将与认证电子邮件地址对应的物理地址信息（例如，IP地址和域名地址）以及公钥信息返回给搜索请求方的服务。一般地，地址搜索服务用于在发送方发送文档之前获取接收方的实际地址信息以及用于加密的安全信息。在此情况下，请求消息和响应消息的角色将在以下表185中描述。【表185】地址登记服务为提供用于不仅通过由地址目录服务器提供的UI而且从远程位置登记用户的认证电子邮件地址的服务。地址目录服务器接收用户信息和认证电子邮件地址信息作为用于登记信息的请求消息，且然后接收结果作为响应消息。地址登记服务的请求消息需要交付以包括请求方的数字签名信息，且地址目录服务器验证包括在请求消息中的用户信息是否与用于数字签名的认证信息相同。在此情况下，请求消息和响应消息的角色将在以下表186中描述。【表186】地址变更服务为远程服务，该远程服务提供允许用户直接和远程变更登记用户的地址信息的功能。地址变更服务将变更请求消息与待变更信息一起发送到地址目录服务器，并接收结果作为响应消息。地址变更服务的请求消息需要传送以包括请求方的数字签名信息。地址目录服务器验证包括在请求消息中的用户信息是否与用于数字签名的证书信息相同。在此情况下，请求消息和响应消息的角色将在以下表187中描述。【表187】