CN103124981A - 电子文档分发系统和电子文档分发方法 - Google Patents
电子文档分发系统和电子文档分发方法 Download PDFInfo
- Publication number
- CN103124981A CN103124981A CN2011800434518A CN201180043451A CN103124981A CN 103124981 A CN103124981 A CN 103124981A CN 2011800434518 A CN2011800434518 A CN 2011800434518A CN 201180043451 A CN201180043451 A CN 201180043451A CN 103124981 A CN103124981 A CN 103124981A
- Authority
- CN
- China
- Prior art keywords
- message
- distribution
- electronic document
- document
- communication server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000009826 distribution Methods 0.000 title claims abstract description 860
- 238000000034 method Methods 0.000 title claims abstract description 381
- 230000008569 process Effects 0.000 claims abstract description 210
- 238000003860 storage Methods 0.000 claims abstract description 60
- 238000004891 communication Methods 0.000 claims description 459
- 230000007246 mechanism Effects 0.000 claims description 138
- 230000004044 response Effects 0.000 claims description 137
- 238000007726 management method Methods 0.000 claims description 122
- 230000006870 function Effects 0.000 claims description 105
- 230000005540 biological transmission Effects 0.000 claims description 80
- 238000012545 processing Methods 0.000 claims description 46
- 230000008859 change Effects 0.000 claims description 35
- 238000012217 deletion Methods 0.000 claims description 17
- 230000037430 deletion Effects 0.000 claims description 17
- 238000012795 verification Methods 0.000 claims description 14
- 238000006243 chemical reaction Methods 0.000 claims description 8
- 238000012360 testing method Methods 0.000 claims description 8
- 238000003466 welding Methods 0.000 claims description 8
- 238000013519 translation Methods 0.000 claims description 6
- 239000000284 extract Substances 0.000 claims description 5
- 238000010276 construction Methods 0.000 claims description 3
- 206010000210 abortion Diseases 0.000 claims description 2
- 231100000176 abortion Toxicity 0.000 claims description 2
- 238000013475 authorization Methods 0.000 claims 1
- 230000000977 initiatory effect Effects 0.000 claims 1
- 239000000344 soap Substances 0.000 description 76
- 238000004422 calculation algorithm Methods 0.000 description 65
- 238000012790 confirmation Methods 0.000 description 53
- 238000010586 diagram Methods 0.000 description 43
- 238000007689 inspection Methods 0.000 description 29
- 238000005538 encapsulation Methods 0.000 description 28
- 230000001360 synchronised effect Effects 0.000 description 25
- 230000000875 corresponding effect Effects 0.000 description 21
- 230000009471 action Effects 0.000 description 14
- 230000008520 organization Effects 0.000 description 12
- 238000012546 transfer Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 230000002123 temporal effect Effects 0.000 description 7
- 230000007613 environmental effect Effects 0.000 description 6
- 230000033228 biological regulation Effects 0.000 description 5
- 238000000605 extraction Methods 0.000 description 5
- 230000014509 gene expression Effects 0.000 description 5
- 230000036299 sexual function Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 239000003795 chemical substances by application Substances 0.000 description 4
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 230000004069 differentiation Effects 0.000 description 4
- 210000000056 organ Anatomy 0.000 description 4
- 238000000926 separation method Methods 0.000 description 4
- 238000007630 basic procedure Methods 0.000 description 3
- 230000015572 biosynthetic process Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 230000008676 import Effects 0.000 description 3
- 238000007639 printing Methods 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 3
- VBMOHECZZWVLFJ-GXTUVTBFSA-N (2s)-2-[[(2s)-6-amino-2-[[(2s)-6-amino-2-[[(2s,3r)-2-[[(2s,3r)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-2-[[(2s)-2,6-diaminohexanoyl]amino]-5-(diaminomethylideneamino)pentanoyl]amino]propanoyl]amino]hexanoyl]amino]propanoyl]amino]hexan Chemical compound NC(N)=NCCC[C@@H](C(O)=O)NC(=O)[C@H](CCCCN)NC(=O)[C@H](CCCCN)NC(=O)[C@H]([C@@H](C)O)NC(=O)[C@H]([C@H](O)C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCN=C(N)N)NC(=O)[C@@H](N)CCCCN VBMOHECZZWVLFJ-GXTUVTBFSA-N 0.000 description 2
- 101000804902 Drosophila melanogaster Xaa-Pro aminopeptidase ApepP Proteins 0.000 description 2
- 101100217298 Mus musculus Aspm gene Proteins 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000000712 assembly Effects 0.000 description 2
- 238000000429 assembly Methods 0.000 description 2
- 230000002596 correlated effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005242 forging Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 108010068904 lysyl-arginyl-alanyl-lysyl-alanyl-lysyl-threonyl-threonyl-lysyl-lysyl-arginine Proteins 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- 244000004005 Nypa fruticans Species 0.000 description 1
- 235000005305 Nypa fruticans Nutrition 0.000 description 1
- 238000012152 algorithmic method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000032798 delamination Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 210000003141 lower extremity Anatomy 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000006386 memory function Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/40—Business processes related to the transportation industry
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/60—Business processes related to postal services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/214—Monitoring or handling of messages using selective forwarding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Entrepreneurship & Innovation (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Marketing (AREA)
- General Physics & Mathematics (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及电子文档分发系统和电子文档分发方法，所述电子文档分发方法可构造不仅为企业/机构而且为个人和小公司提供可靠性的电子文档分发系统。根据本发明的电子文档分发系统包括：收发实体，基于电子邮件地址收发消息且通过分发通讯服务器来分发电子文档，所述分发通讯服务器发行和管理消息收发的分发证书；分发中心，登记/管理收发实体的电子邮件地址，建立收发实体之间的电子文档分发路径，为收发实体提供电子文档标准格式，以及当在收发实体之间分发电子文档过程期间发生错误时，通过代理服务器发送消息，且发行分发证书；以及可靠的第三方存储机构，接收和存储分发证书。
Description
技术领域
本发明涉及电子文档分发系统和电子文档分发方法，该电子文档分发方法可构造不仅为企业/机构而且为个人和小公司提供可靠性的电子文档分发系统。
背景技术
一般，基于企业/机构的个体独特规定，电子文档分发仅在特定行业集团或者社团中限制性执行。
此外，存在的问题在于，电子邮件用作一般个人之间或者个人与企业/机构之间的辅助手段而没有考虑可靠电子分发概念，或者仅在个人、个体企业或者小公司访问企业网站时进行在线交流。
因此，可以预期，不仅可拥有预定规模分发系统的企业，而且个人、个体企业或者小公司可建立基于电子文档分发的基础设施，该基础设施保证分发可靠性。
发明内容
【技术问题】
本发明致力于提供不仅允许可拥有预定规模分发系统的企业/机构而且还允许个人和小公司建立可靠性的电子文档分发系统和电子文档分发方法。
【技术方案】
根据本发明示例性实施方式的电子文档分发系统包括：收发实体，基于电子邮件地址发送和接收消息并且通过分发通讯服务器来分发电子文档，所述分发通讯服务器发行和管理消息发送/接收的分发证书；分发中心，登记/管理收发实体的电子邮件地址、设定收发实体之间的电子文档分发路径、将电子文档的标准格式提供给收发实体、当在收发实体之间分发电子文档的过程中发生错误时通过代理服务器发送消息并发行分发证书；以及可靠的第三方存储机构，接收和存储分发证书。
在根据本发明示例性实施方式的电子文档分发系统中，在包括收发实体和分发中心的电子文档分发系统中分发电子文档的方法包括以下步骤：（a）步骤：允许发送实体获取与接收实体的地址信息对应的物理地址信息并然后将带有附加电子文档的消息发送到物理地址；（b）步骤：允许接收消息的接收实体根据接收消息与发送实体的兼容性验证结果来发行接收证书或者错误证书，且将证书传送到收发实体；以及（c）步骤：允许发送消息到接收实体但发送失败的发送实体请求分发中心通过代理服务器发送消息，且允许接收用于通过代理服务器发送消息的请求的分发中心发行发送证书，以将证书传送到发送实体且将消息发送到接收实体，且然后执行步骤（b）。
【有益效果】
具有上述构造和方法的本发明可建立不仅允许企业/机构而且允许个人和小公司建立可靠性的电子文档分发系统。
附图说明
图1为示出了根据本发明示例性实施方式的电子文档分发系统的构造示例的示图。
图2为示出了图1的分发通讯服务器的示图。
图3为示出了图1的分发客户端的示图。
图4为示出了图1的地址目录服务器的示图。
图5为示出了图1的电子文档格式寄存器的示图。
图6为示出了图1的分发中继服务器的示图。
图7为示出了图1的外接网关的示图。
图8为示出了图1的电子文档分发系统中认证电子邮件地址的实施范围的示图。
图9为示出了根据本发明示例性实施方式的认证电子邮件地址的申请/发行和操作系统的示图。
图10至图13为示出了在本发明示例性实施方式中分发电子文档时消息安全性的示图。
图14至图17为示出了在本发明示例性实施方式中消息收发处理器的示图。
图18为示出了根据本发明示例性实施方式的物理地址获得过程的示图。
图19至图21为示出了根据本发明示例性实施方式的分发中继支持过程的示图。
图22至图24为示出了根据本发明示例性实施方式的诸如认证电子邮件地址登记的管理过程的示图。
图25和图26为示出了根据本发明示例性实施方式的电子文档格式申请过程的示图。
图27至图29为示出了根据本发明示例性实施方式的垃圾消息处理过程的示图。
图30和图31为根据本发明示例性实施方式的电子文档读取服务的概念图。
图32为根据本发明示例性实施方式的外接网关服务器的概念图。
图33为示出了在本发明示例性实施方式中分发连接到外部系统的电子文档的过程的示图。
图34至图38为示出了在根据本发明示例性实施方式的电子文档分发系统下用于使元件操作为彼此链接以分发电子文档的通信协议的配置的示图。
图39至图43为示出了在根据本发明示例性实施方式的电子文档分发系统下错误处理方法的示图。
图44至图51为示出了在根据本发明示例性实施方式的电子文档分发系统中分发通讯服务器和地址目录服务器之间的连接接口的示图。
图52至图63为示出了在根据本发明示例性实施方式的电子文档分发系统中分发通讯服务器之间的连接接口的示图。
图64至图78为示出了在根据本发明示例性实施方式的电子文档分发系统中分发客户端和分发通讯服务器之间的连接接口的示图。
图79至图81为示出了在根据本发明示例性实施方式的电子文档分发系统中分发通讯服务器和分发中继服务器之间的连接接口的示图。
图82为示出了根据本发明另一个示例性实施方式的认证分发通讯服务器系统以登记为认证电子邮件地址的过程的示图。
图83为示出了根据本发明另一个示例性实施方式的当收发实体充当接收方时在电子文档分发中心处报告垃圾消息的过程的示图。
图84为示出了根据本发明另一个示例性实施方式的当收发实体充当接收方时实时检查是否拒绝接收通信方的过程的示图。
图85为示出了根据本发明另一个示例性实施方式当收发实体充当接收方时定期检查是否拒绝实时接收通信方的过程的示图。
图86至图100为示出了根据本发明另一个示例性实施方式的分发通讯服务器系统的示图。
图101至图105为示出了适用于根据本发明另一个示例性实施方式的电子文档分发系统和方法的分发协议的示图。
图106和图107为示出了根据本发明另一个示例性实施方式的电子文档格式寄存器的示图。
图108为示出了适用于根据本发明另一个示例性实施方式的电子文档分发系统和方法的电子文档封装的示图。
图109至图114为示出了根据本发明另一个示例性实施方式的分发客户端应用程序的示图。
图115为示出了根据本发明又一示例性实施方式的系统的示图，其中地址目录服务器发行电子邮件地址。
图116为示出了根据本发明又一示例性实施方式的地址目录服务器发行电子邮件地址的过程的示图。
图117和图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】
（6）外接网关服务器
外接网关服务器为充当可靠通道的系统，以将已经操作或者几乎不包括在分发系统中的外部系统与分发系统连接。
在公共部门的情况下，民政事务文档通过公共信息共享中心或者电子文档分发支持中心以电子方式分发。对于用于与系统连接的通道，可以使用外接网关服务器。外接网关服务器可充当通道以与除公共部门之外的其它外部系统连接。
外接网关服务器的功能概念在图7中示出，且其功能将在以下表9中描述。
【表9】
（7）经认证的电子邮件地址
收发实体以及参与分发系统中的认证发送方/接收方需要接收唯一认证的电子邮件地址。
认证电子邮件地址由井号【#】、数字【0到9】、连字符【-】和句点【.】的组合构成。
认证电子邮件地址的构成系统将在以下表10中描述。
【表10】
与认证电子邮件地址的构成系统相关的原理如以下（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】
（8）电子文档信息封装
需要电子文档信息封装来支持通过清楚描述包括在消息中的电子文档元数据来自动登记或者处理企业内部系统中的电子文档，诸如群件。
电子文档信息封装不是消息分发的基本元素。因此，电子文档信息封装可选择性用于必要任务。然而，如果使用电子文档信息封装，那么需要遵守以下要求（1）和（2）。
（1）电子文档信息封装需要作为与包括在消息中的电子文档不同的文件格式发送。
（2）电子文档信息封装需要作为XML文件格式提供。
电子文档信息封装的元数据将在以下表12中描述。
【表12】
【消息安全性】
分发系统中最重要部分之一为发送消息的安全性，其要求（1）防止发送/接收的拒绝，（2）发送消息的完整性保证，（3）发送方认证以及（4）发送消息的机密性保证。其中，（1）到（3）通过发送消息的发送方的数字签名来支持，且（4）通过加密发送消息来提供。
当在分发通讯服务器之间分发电子文档时所应用的安全性（其为分发系统的基础）支持消息数字签名和加密，如图10所示。网络加密需要施加于每个部分以保护发送。
内容的数字签名为每个应用程序的独特部分。其描述将省略。在本发明中，基本上，利用接收方公钥进行加密。如果没有接收方的认证证书，或者接收方为内部接收方，那么只可选择接收实体加密。此外，在消息发送期间，消息连同对消息的认证信息一起发送到分发通讯服务器。在此情况下，分发通讯服务器主要使用认证信息来认证客户端。此外，分发通讯服务器采用不同认证方法，诸如基于IP/PW的认证、基于令牌信息的SSO（单独签字）认证以及基于认证证书的数字签名，以认证分发客户端。
下文中，将详细描述数字签名方法。
当分发通讯服务器与其它系统（其它分发通讯服务器、地址目录服务器或者分发中继服务器）连接时，需要基于其自己的证书进行数字签名。用于连接分发系统中组成要素的所有分发消息基本上都被数字签名。然而，分发客户端和分发通讯服务器之间的数字签名为可选，且数字签名只应用于基于证书的用户认证方法。在此情况下，分发通讯服务器负责用户认证、完整性和防止拒绝分发客户端的分发消息的发送/接收。
下文中，将详细描述加密方法。
分发系统中附加文档可在发送方选择加密之后发送以保护文档，为了文档机密性执行加密，但是不同于网络加密。因此，在应用网络加密之后，可另外加密分发文档。
待加密部分可为（1）从发送方的分发客户端到接收方的分发通讯服务器或者（2）从发送方的分发客户端到接收方的分发客户端，如图10所示。如果接收方为认证发送方/接收方，且证书登记在地址目录服务器中，那么在从发送方到接收方的部分（2）中进行加密。否则，在从发送方到接收实体的部分（1）中进行加密。
当加密附加文档时，如果在从发送方到接收实体的部分（1）中保持加密，那么发送方需要加密文档，以在发送方的分发通讯服务器、接收方的分发通讯服务器以及接收方的分发客户端的三个步骤中解码文档。如果在从发送方到接收实体的部分（2）中保持加密，那么发送方需要加密文档，以解码发送方的分发通讯服务器以及接收方的分发通讯服务器。
如果加密附加电子文档，那么发送实体和接收实体的分发通讯服务器在加密状态下存储电子文档，以管理记录。因此，如果发送方/接收方想要基于解码文档来验证分发证书，那么解码电子文档以验证分发证书。出于这个原因，分发通讯服务器需要一直管理撤销证书的私钥以及访问私钥的密码。
下文中，将描述加密方法中加密的概要。
如果发送方确定分发系统中正在分发的消息的机密性被确保，那么需要遵守以下加密处理。
在国内外作为标准使用的以由IETF RFC3852“CMS（加密消息语法）”建议的内容信息结构为代表的封装包数据内容类型用作密文。
※RFC3852CMS
1）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。
作为另外应用标准，在创建密文或者与算法对应的参数时，在内容加密（将实际发送的电子税务发票封装包）中使用的算法遵循IETF RFC3370“加密消息语法（CMS）算法”和IETF RFC4010“SEED加密算法在加密消息语法（CMS）中的使用”。
下文中，将描述加密方法中的加密目标数据。
参考图11，待交付消息的加密目标为以下（1）和（2）。
（1）在第二MIME中输入的分发信息
（2）输入主文本实际内容的消息体块的<文本>区以及附加文档
消息体块中的文本以及附加文档被单独加密，且包括在相应位置中。
第一加密目标为将交付给接收方的主文本内容，且在XML体块中<文本>部分中具有值。
接着，将描述目标数据的配置方法。数据遵循ASN.1基本编码规则（BER），且遵守区分编码规则（DER）。
【表13】
表13的主文本（MainText）为文本类型主文本的内容。
第二或者更后加密目标数据为附加到第三MIME或者更后MIME的附加文档。第二或者更后加密目标数据在附加文档的单元中单独加密，且然后输入在对应MIME中。
接着，将描述目标数据的配置方法。数据遵循ASN.1基本编码规则（BER），且遵守区分编码规则（DER），其与第一加密方法相似。
【表14】
表14中附加文档（AttachedDoc）为二进制类型的附加文档。
下文中，将描述加密方法中加密过程和结构。
以下表15描述RFC 3852的封装包数据的构造。
【表15】
表15中，版本遵循语法版本号RFC 3852的构造。
因为不使用密钥管理算法，所以不使用OriginatorInfo，且CRL不需要被发送（RFC 3852中定义）。
因为当前可用的加密证书算法为RSA，所以交付由接收方通过RecipientInfos的KeyTransRecipientInfo解码的密钥（内容加密密钥）。
在encryptedContentInfo中，输入基于其中定义的算法标识符算法加密的主文本（MainText）或者附加文档（AttachedDoc）。
因为在本版本中未单独使用unprotectedAttrs，所以为了管理目的可在发送方侧插入值，但接收方不需要解码或者使用这个值。
创建RFC3852的封装包数据的主要部分将在以下（1）和（2）中描述。
（1）创建EncryptedContentInfo
【表16】
- id-数据（标识符-OID-指示哪个信息为加密数据的信息）作为内容类型（ContentType）输入。
- 实际用于加密的对称密钥算法信息作为内容加密算法（contentEncryptionAlgorithm）输入。
- 加密的内容（encryptedContent）的输入为通过根据在内容加密算法（contentEncryptionAlgorithm）中定义的算法方法对以上定义的TaxInvoicePackage的DER编码值加密来获得的OCTET STRING（二进制字符串）。
（2）接收信息（RecepientInfo）的创建
【表17】
-发送实体和接收实体需要加密。只有当接收方具有证书时，接收方才执行加密。因此，实际RecipientInfos具有至少两个或者最多3个较低级别RecipientInfos。
- 因为加密证书使用RSA，所以加密证书只有通过ktri（发送对称密钥的方法，使用另一方的RSA公钥来加密数据）来配置。
下文中，将描述加密方法中消息的OID定义。
用于配置消息的对象标识符为如下（1）和（2）。
（1）EnvelopedData类型：RFC3852 CMS中实际发送数据的格式为称为ContentInfo的结构，且EnvelopedData类型为以ContentType输入的信息，以检查哪个数据处于结构中。
【表18】
（2）EncryptedContentInfo的ContentType：以ContentType输入的信息，以检查哪个数据处于输入加密数据的EncryptedContentInfo结构中。
【表19】
下文中，将描述加密方法中的加密算法。
用于加密的算法主要分为两个。
（1）对称密钥算法，用于直接加密目标数据
（2）公钥算法，发送对称密钥以仅由接收方解码
因为待使用证书为GPKI或者NPKI系统的加密证书，所以公钥算法使用基于RSM的算法。此外，对于对称密钥算法，应当选择以下三个对称密钥加密算法（SEED、ARIA和3DES）中一个。
发送方仅可以支持对称密钥加密算法中一个，但是接收方需要支持三个算法中全部。
（1）不对称密钥算法（RSA）：随机生成以用于安全加密对称密钥信息，其中加密数据以发送到另一方，且其示例将在以下表20中描述。
【表20】
（2）对称密钥算法（SEED、ARIA、3DES）：随机生成以用于实际加密发送数据，且其示例将在以下表21中描述。
【表21】
下文中，将描述加密方法中加密证书的获得和验证。
为了创建密文，需要获得解码实际数据的接收方侧证书。为了获得证书，发送方需要连接到地址目录服务器以获得接收方（或者接收实体）证书。在此情况下，根据所获得证书为接收实体的证书还是认证的接收方的证书，来改变保持机密性的部分。
如果发送方选择发送消息加密，那么发送方基于所获得的接收方（或者接收实体）证书进行加密，且发送消息到接收方。即使在消息发送期间发生错误，使得请求分发中继中心发送消息，也发送消息而无需更改加密内容。
下文中，将描述加密方法中的封装包数据（EnvelopedData）的构造。
图12示出了实际发送到接收方的加密体块，因此可更清楚地理解实际值之间的连接关系。
-ContentInfo：在RFC3852中表示，且为其中输入有RFC3852的组成数据的SignedData、EnvelopedData、EncryptedData的容器（container）。结构的contentType指示哪个类型信息为内容。在本发明中，需要插入称为id-envelopedData的标识符（对象标识符）。
-EnvelopedData：用于交付加密信息的结构（参阅以上描述）。
-EncryptedContentInfo：存储加密信息的结构。结构的contentType指示哪个类型信息为encryptedContent。在本发明中，需要插入称为id-data的标识符（对象标识符）。在contentEncryptionAlgorithm中，需要插入针对SEED、ARIA和3DES中一个的标识符（OID）。此外，随机创建的密钥用于输入通过encryptedContent中算法加密的数据作为OCTET STRING（二进制数据）。
-RecipientInfo：允许接收方选择使用哪个方法来解码的结构。在本发明中，需要使用KeyTransRecipientInfo。
-KeyTransRecipientInfo：用于加密和交付通过使用接收方公钥对上述encryptedContent加密所获得的随机密钥的结构，以允许接收方解码。加密密钥在encryptedKey中输入，包括作为指示使用其公钥的信息的RecipientIdentifier以及作为用于加密密钥的算法信息的KeyEncryptionAlgorithmIdentifier。
下文中，将描述解码方法。
接收加密电子文档的接收方根据参考图12描述的处理对加密体块以及附加文档进行解码。接收方对加密体块和附加文档解码，以获得纯文本类型体块和附加文档。
-第一步骤：从待读出的密文提取EnvelopedData结构。
-第二步骤：从EnvelopedData结构提取解码信息结构（RecipientInfo），然后从提取的解码信息结构获得加密对称密钥信息（KeyTransRecipientInfo）。
-第三步骤：接收方通过从利用接收方私钥（可映射为证书公钥）加密的对称密钥信息提取的encryptedKey解码，来获得用于加密体块和附加文档的对称密钥。
-第四步骤：从在第一步骤中提取的EnvelopedData结构获得体块或者附加文档的加密结构。
-第五步骤：使用在第三步骤中获得的对称密钥对在第四步骤中提取的加密体块或者附加文档解码。
-第六步骤：获取最后解码的体块和附加文档。
【网络安全性】
为了保持发送方和接收方之间分发的消息的机密性，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中，以访问分发通讯服务器来使用程序。
【与内部系统的连接方法】
分发系统具有基于其自己系统和互联网的分发网络。电子文档可在分发系统中分发，使得可能存在限制。分发系统包括外接网关服务器，以将电子文档分发到未直接连接到分发系统的系统。
外接网关服务器的基本概念图在图32中示出。
外接网关服务器充当中途停留地。一个包括用于分发系统的分发通讯服务器，另一个包括用于与外部系统连接的适配器。
如上所述，为了与外部系统连接，需要考虑任务因素和技术因素。
任务因素为与各方之间的连接相关的任务程序或者方法协定。管理机构和外接系统管理机构需要相互制定服务等级协议（SLA）。
技术因素是指与连接所需的用户认证、通讯和消息格式相关的技术因素。
主要用于与外部系统连接的技术可归纳为以下（1）到（6）。
（1）（地址）发送方需要写入中途停留地的地址和最终目的地地址。
（2）（用户认证）发送方需要提供用户信息，使得外部系统认证发送方。如果发送方已预先成为外部系统成员，那么可使用外部系统的认证标识符。
（3）（消息拆分和组合）所接收消息被拆分，以组合为与外部系统兼容的消息
（4）（消息安全性）应用于消息的加密或者诸如DRM的安全性需要被验证/转换
（5）（元数据信息）消息以及包括在消息中的电子文档相关信息需要验证/转换
（6）（外接系统识别）与分发系统连接的外部系统可添加或者变更。关于外部系统的信息由地址目录服务器管理，且如果必要，分发通讯服务器查询地址目录服务器以处理信息。
分发与外部系统连接的电子文档的程序在图33中示出。
在根据如上所述的本发明示例性实施方式的电子文档分发系统和电子文档分发方法中，为了分发电子文档，需要诸如分发通讯服务器、分发客户端和分发中继服务器的组件，且在电子文档分发的整体流程中这些组件需要相互连接。因此，这些组件被操作为相互连接，并且需要定义用于连接的通信协议、消息交换方法和连接消息结构。
下文中，定义用于组件之间连接的共同基础通信协议和消息交换方法，且根据连接类型的消息结构被定义为所建议的标准。因此，本发明允许在不同环境下且通过不同开发方法和互操作性建立的组件之间的平滑连接。
【连接的基本通信协议】
在基于认证电子地址的电子文档分发系统下，在组件之间分发信息和电子文档所需的电子文档分发连接接口中，分发连接消息是基于“ebXML消息服务v2.0标准”（下文中，称为ebMS），且分层扩展定义为更广义形式。基于ebXML的结构由独立但有密切关系的诸如SOAP、带附件、安全性和可靠性的SOAP的元素构成。“连接的基本通信协议”（下文中，基本通信协议）定义分发系统中基于这些基本元素所需且被构造为元素被有机重组的形式的元素。
基本通信协议通过形成消息的封装、消息封装包配置、消息安全性以及发送和接收消息的消息收发来构成。
下文中，将描述基本协议配置中的消息封装。
分发连接消息的整个消息结构应用ebMS v2.0标准。基本通信协议中定义的消息具有两个逻辑MIME部分。
第一MIME部分被称为标头容器，且包括SOAP消息。SOAP消息由标头和体块构成。
第二或者后续MIME部分被称为净荷容器，且包括应用程序级消息和附加文档。
以下将详细描述第一MIME部分。在本部分中，描述用于分发消息（消息的路由相关信息、SOAP消息交换模式、数字签名、错误信息以及在第二时间添加的数据位置信息）的共同信息。
第二MIME部分将对每个连接接口的请求以及响应消息附加。根据连接接口类型，确定第三或者后续MIME部分存在性。当使用分发系统交付电子文档或者证书时，第二MIME包括在第三MIME部分中。
分发连接消息的基本构造在图34中示出。参考图34，（1）“SOAP-ENV：标头”由根据分发协议标准的消息标头和签名信息构成，（2）“SOAP-ENV：体块”包括由分发协议标准定义的Manifest组成要素信息和用户登录信息，（3）“发送容器#1（净荷容器#1）”包括请求消息和响应消息。根据连接接口类型以及请求、响应或者错误消息的存在性来定义业务文档的详细内容，以及（4）在“发送容器#2（净荷容器#2）”中，根据连接接口类型将待附加的文档从净荷容器#2按顺序输入。
分发连接消息需要遵守标准，诸如简单对象访问协议（SOAP）1.1以及带附件的SOAP消息。
在图34中，分发连接消息的MIME标头的所有组元需要符合带附件的SOAP消息标准。另外，消息中内容类型MIME标头必须具有与包括SOAP消息文档的MIME体块部分的MIME媒体类型相同类型的属性。根据SOAP标准的MIME类型SOAP消息需要具有“text/xml”值。路由部分需要包括具有基于【RFC2045】的结构的内容ID MIME标头，且除多部分/相关媒体类型的基本参数外，开始参数（在【RFC2387中可选】）需要始终存在。多部分/相关消息封装包的MIME标头示例将在以下表40中描述。
【表40】
参考图34，第一MIME部分标头容器需要包括SOAP消息。根据SOAP标准，标头容器的MIME内容类型标头需要具有“text/xml”值。内容类型标头需要包括“字符集”属性，且其示例将在表41中描述。MIME字符集属性用来区分用于创建SOAP消息的字符组。MIME字符集属性值以及位于标头容器中的SOAP消息的编码声明相互匹配，且其值需要为UTF-8。标头容器示例将在以下表42中描述。
【表41】
【表42】
参考图34，根据连接接口类型，可改变净荷容器数。根据ebMS标准，净荷容器中每个可称为SOAP体块中的Manifest。其示例将在以下表43中描述。
【表43】
参考图34，除本发明中定义为基本元素的MIME标头外，为方便起见，可添加MIME标头。在此情况下，添加的MIME标头需要为在【RFC2045】中清楚描述的项目。然而，添加的MIME标头不需要通过不添加MIME标头的一方进行通知或者分析。
下文中，将描述基本协议配置中的消息封装包配置。
所有扩展元素的内容需要限制于基于SOAP标准的可用名称空间。本发明中定义的所有ebXML SOAP扩展元素的内容需要限制于ebXMLSOAP封装包扩展名称空间。名称空间的申明可包括在SOAP封装包、标头或者体块元素中，或者直接包括在每个SOAP扩展元素中。
SOAP封装包将SOAP消息中各种名称空间申明为SOAP消息的根项目。待申明名称空间为如下。
【表44】
| 项目 | 名称空间URL |
| SOAP | http://schemas.xmlsoap.org/soap/envelope/ |
| 数字签名 | http://www.w3.org/2000/09/xmldsig# |
| Xlink | http://www.w3.org/1999/xlink |
| Xsi | http://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：参考元素的XML ID
（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】
消息标头示例将在表50中描述。
【表50】
如果存在同步应答（SyncReply），那么SyncReply指示同步发送且具有以下属性（1）到（4）。
（1）id属性
（2）版本属性
（3）SOAP 动作者属性（必须具有“http://schemas.xmlsoap.org/soap/actor/next”值）
（4）SOAP mustUnderstand属性
SyncReply元素示例将在以下表51中描述。
【表51】
分发连接消息需要以数字方式签名，以应对在收发过程中可能发生的各种危险因素。因此，签名元素需要作为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】
（2）散列（摘要）
用于减少数据的算法遵守经认证的证明系统的相关规定
【表53】
（3）数字签名（签名）
用于对消息进行数字签名的算法遵守经认证的证明系统的相关规定
【表54】
（4）规范化
；由于在物理上可不同表达逻辑相同文档的XML的特性，数字签名值对于相同文档可以是不同的。为了防止以上现象，需要执行规范化过程。在规范化中，使用省略注释的规范化XML。
【表55】
（5）转换
；即使存在各种转换算法作为经过对整个XML数据中的待签名数据进行的处理和选择的过程的算法，但在各种转换算法中只可使用三个算法。第一算法为封装签名转换，这是因为数字签名遵守包括在签名目标中的形式，第二算法为上述规范化，以及第三算法为选择签名目标信息的Xpath过滤。
【表56】
数字签名语法的结构在图37中示出，且数字签名的消息示例将在以下表57中描述。
【表57】
当在通信协议处理（诸如消息语法验证或者消息数字签名验证）过程中发生错误时，在标头较低级中创建ErrorList元素且同步返回到发送方。当生成ErrorList元素时，RefToMessageId必须存在于消息标头元素中，且RefToMessageId需要指定发生错误的消息的消息ID。
ErrorList元素具有以下属性（1）到（5）。
（1）id属性
（2）SOAP mustUnderstand属性
（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解析器或者消息的软件来生成。这意味着，内容由创建错误元素的软件销售商或者开发者定义。
ErrorList示例将在以下表58中描述。
【表58】
如果在基于分发协议进行收发消息过程中发生错误，那么通知错误的收发实体需要将错误通知给其他方。待报告错误包括消息结构错误、通讯错误和安全性错误。
与属于比本发明中定义的分发协议更低层的数据通信协议（诸如HTTP和Socket）相关的错误需要通过由数据通信协议支持的标准机制发现和报告，且不使用在本发明中定义的错误报告机制。
错误代码根据错误目标和错误类型来分类，且其细节将在以下表59中描述。
【表59】
下文中，将描述在HTTP绑定方法中通过HTTP进行的消息发送方法。HTTP绑定示例将在以下表60中描述。
【表60】
下文中，将描述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）的请求消息发送失败不区分，使得通过相同方法处理错误。然而，因为接收方正常接收请求消息，所以处理方法不同于发送方的处理方法。图40示出了与响应消息接收失败相关的过程，且处理程序将描述为如下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中描述，且扩展元素示例将在以下表66中描述。
【表65】
【表66】
（2）整个消息结构
在分发通讯服务器和地址目录服务器之间的连接接口中，SOAP消息位于消息的第一MIME部分，且请求和响应的分发消息位于第二MIME部分。
分发通讯服务器和地址目录服务器之间的SOAP结构在图44中示出。
下文中，将描述在分发通讯服务器和地址目录服务器之间接口中，认证电子邮件地址的登记。
与认证电子邮件地址登记相关的消息交换流程在图45中示出。
请求分发消息结构将在以下表67中描述，且消息示例将在以下表68中描述。
【表67】
【表68】
响应分发消息的结构将在以下表69中描述，且消息示例将在以下表70中描述。
【表69】
【表70】
下文中，将描述在介于分发通讯服务器和地址目录服务器之间的接口中，变更认证电子邮件地址信息的接口。
变更认证电子邮件地址信息的接口为允许电子文档提供商请求地址目录服务器变更登记于地址目录服务器中的认证发送方/接收方的认证电子邮件地址且接收响应的接口。在发送包括待变更的用户信息和认证电子邮件地址信息的请求消息之后，电子文档提供商接收地址目录服务器的变更结果作为响应消息。
与认证电子邮件地址变更过程相关的消息交换流程在图46中示出。
请求分发消息结构将在以下表71中描述，且消息示例将在以下表72中描述。
【表71】
【表72】
响应分发消息的结构将在以下表73中描述，且消息示例将在以下表74中描述。
【表73】
在图73中，如果ResultCode输入为失败（0），那么与错误原因对应的错误代码输入为ErrorCode。
【表74】
下文中，将描述在介于分发通讯服务器和地址目录服务器之间的接口中，删除认证电子邮件地址信息的接口。
删除认证电子邮件地址信息的接口为允许电子文档提供商请求地址目录服务器删除登记于地址目录服务器中的认证发送方/接收方的认证电子邮件地址信息且接收响应的接口。在发送包括待删除的用户信息和认证电子邮件地址信息的请求消息之后，电子文档提供商接收地址目录服务器的删除结果作为响应消息。
与认证电子邮件地址的删除过程相关的消息交换流程在图47中示出。
请求分发消息结构将在以下表75中描述，且消息示例将在以下表76中描述。
【表75】
【表76】
响应分发消息的结构将在以下表77中描述，且消息示例将在以下表78中描述。
【表77】
在图77中，如果ResultCode输入为失败（0），那么与错误原因对应的错误代码输入为ErrorCode。
【表78】
下文中，将描述在介于分发通讯服务器和地址目录服务器之间的接口中，搜索物理地址信息的接口。
搜索物理地址信息的接口为允许电子文档提供商或者收发实体请求地址目录服务器，以请求与电子文档接收方的认证电子邮件地址信息对应的物理地址信息且接收响应的接口。在发送包括电子文档接收方的认证电子邮件地址的请求消息以及证书请求之后，电子文档提供商从地址目录服务器接收电子文档接收方的物理地址信息（IP地址或者域名地址）以及证书信息作为响应消息。
与物理地址信息搜索过程相关的消息交换流程在图48中示出。
请求分发消息结构将在以下表79中描述，且消息示例将在以下表80中描述。
【表79】
【表80】
响应分发消息的结构将在以下表81中描述，且消息示例将在以下表82中描述。
【表81】
【表82】
下文中，将描述在介于分发通讯服务器和地址目录服务器之间接口中，报告垃圾消息的接口。
报告垃圾消息的接口为允许电子文档提供商或者收发实体将垃圾消息报告给地址目录服务器的接口。在发送包括垃圾发送方的认证电子邮件地址以及垃圾消息信息的请求消息之后，接口从地址目录服务器接收是否接受垃圾报告作为响应消息。如果有关所报告垃圾消息是否为垃圾的确定完成，那么地址目录服务器使用介于分发通讯服务器之间连接接口的“消息发送”接口通知处理结果。
与垃圾消息报告和接受过程相关的消息交换流程在图49中示出。
请求分发消息的结构将在以下表83中描述，且消息示例将在以下表84中描述。
【表83】
【表84】
响应分发消息的结构将在以下表85中描述，且消息示例将在以下表86中描述。
【表85】
在表85中，请注意，ResultCode为垃圾报告消息的简单接受处理结果。
【表86】
下文中，将描述在介于分发通讯服务器和地址目录服务器之间接口中，通知白名单的接口。
通知白名单的接口为将白名单（收发实体名单以及参与分发系统的发送方/接收方的认证电子邮件地址）通知给收发实体的接口。
与白名单通知相关的消息交换流程在图50中示出。
请求分发消息结构将在以下表87中描述，且消息示例将在以下表88中描述。
【表87】
【表88】
响应分发消息的结构将在以下表89中描述，且消息示例将在以下表90中描述。
【表89】
在表89中，请注意，ResultCode为垃圾报告消息的简单接受处理结果。
【表90】
下文中，将描述在介于分发通讯服务器和地址目录服务器之间接口中，通知黑名单的接口。
通知黑名单（接收拒绝名单）的接口为将黑名单通知给收发实体的接口。通知的黑名单用于由收发实体管理黑名单。
与黑名单通知相关的消息交换流程在图51中示出。
请求分发消息结构将在以下表91中描述，且消息示例将在以下表92中描述。
【表91】
【表92】
响应分发消息的结构将在以下表93中描述，且消息示例将在以下表94中描述。
【表93】
【表94】
【分发通讯服务器之间的连接接口】
分发通讯服务器根本上与由其它收发实体或者其它电子文档提供商建立的分发通讯服务器连接，以发送/接收消息。
除以上基本功能外，分发通讯服务器具有在第三方存储机构提供商的分发通讯服务器与其它通讯服务器之间传送分发证书以将分发证书存储于第三方存储机构中的连接功能。
分发通讯服务器之间的连接接口为用于在通讯服务器之间发送/接收消息和分发证书的协议，且被分类为以下表95中描述的接口。
【表95】
下文将描述分发通讯服务器之间接口的详细信息。
首先，分发通讯服务器之间接口的共同事实为如下（1）。
（1）请求和响应消息的消息标头扩展
发送方的数字签名信息需要交付以包括在SOAP消息中，所述SOAP消息为分发通讯服务器之间的连接接口的消息的第一MIME部分。此外，验证用于SOAP消息数字签名的证书拥有者是否与发送方匹配（VID验证）所需的发送方的附加信息（CorpNum、RValue）也被交付以包括在其中。
发送方的附加信息需要作为扩展元素位于请求和响应消息的SOAP消息中消息标头元素的较低级处（任何##其它位置）。
扩展元素结构将在以下表96中描述，且架构结构将在以下表97中描述。
【表96】
【表97】
下文中，将描述介于分发通讯服务器之间接口中的消息发送接口。
当一个分发通讯服务器发送消息到另一个分发通讯服务器时，使用消息发送接口。
消息发送中的消息交换流程在图52中示出。
交换消息时的请求格式在图53中示出。在如图53所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求分发消息位于第二MIME部分中，以及由用户附加的文档位于第三或者后续MIME部分中。
请求分发消息结构将在以下表98中描述，且示例将描述为如下。
【表98】
在表98中，如果为了交付文档，体块没有必要，那么文本可省略。
【表99】
交换消息时的响应格式在图54中示出。在如图54所示的整个消息结构中，SOAP消息位于第一MIME部分中，响应分发消息位于第二MIME部分中，以及接收证书位于第三MIME部分中。如果在处理请求消息过程中发生错误，那么不产生第三MIME部分。
响应分发消息结构将在以下表100中描述，且实际示例将在以下表101中描述。
【表100】
在表100中，如果DocType为错误（9），那么不产生接收证书所位于的第三MIME部分。
【表101】
下文中，将描述介于分发通讯服务器之间的接口中的分发证书交付接口。
当分发通讯服务器发送读取证书到另一个分发通讯服务器时，使用分发证书交付接口。此外，当分发中继服务器接收发送电子文档到接收分发通讯服务器的请求且然后发送所接收到的接收证书到发送请求分发通讯服务器作为响应消息时，使用分发证书发送接口。
与分发证书交付处理相关的消息交换流程在图55中示出。
分发证书交付请求格式在图56中示出。在如图56所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求分发消息位于第二MIME部分中，以及分发证书位于第三MIME部分中。
请求分发消息结构将在以下表102中描述，且实际示例将在以下表103中描述。
【表102】
【表103】
分发证书发送响应格式在图57中示出（图57A示出了在成功情况下的分发证书发送响应，图57B示出了失败情况下的分发证书发送响应）。在如图57所示的整个消息结构中，如果请求消息处理成功，那么仅接收确认ACK SOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。
响应分发消息结构将在以下表104中描述。表104仅对应处理结果失败时。
【表104】
下文中，将描述介于分发通讯服务器之间的接口中的分发证书存储请求接口。
当收发实体的分发通讯服务器请求第三方存储机构的分发通讯服务器存储分发证书以将分发证书存储于第三方存储机构中时，使用分发证书存储请求接口。在接口中的响应消息中，仅包括接收确认信息。作为分发证书存储于第三方存储机构中的结果所发行的初始登记证书，通过使用将在下文描述的第三方存储机构存储结果交付接口交付到存储请求分发通讯服务器。
与分发证书存储请求处理相关的消息交换流程在图58中示出。
分发证书存储请求格式在图59中示出。在如图59所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求分发消息位于第二MIME部分中，以及分发证书位于第三MIME部分中。
请求分发消息结构将在以下表105中描述，且实际示例将在以下表106中描述。
【表105】
【表106】
分发证书存储响应格式在图60中示出（图60A示出了成功情况下的分发证书存储响应，图60B示出了失败情况下的分发证书存储响应）。在如图60所示的整个消息结构中，如果请求消息的处理成功，那么仅接收确认ACK SOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。
响应分发消息结构将在以下表107中描述。表107仅对应处理结果失败时。
【表107】
下文中，将描述介于分发通讯服务器之间接口中的第三方存储机构存储结果交付接口。
当第三方存储机构提供商的分发通讯服务器将分发证书存储于第三方存储机构中且然后将作为结果所接收的初始登记证书发送到请求存储分发证书的分发通讯服务器时，使用第三方存储机构存储结果交付接口。
与第三方存储机构存储结果交付处理相关的消息交换流程在图61中示出。
第三方存储机构存储结果交付格式在图62中示出。在如图62所示的整个消息结构中，SOAP消息位于第一MIME部分中，请求分发消息位于第二MIME部分中，以及第一登记证书位于第三MIME部分中。如果在将分发证书存储于第三方存储机构的过程中发生错误，那么不产生第三MIME部分。
请求分发消息结构将在以下表108中描述，且实际示例将在以下表109中描述。
【表108】
在表108中，如果DocType为错误（9），那么不产生初始登记证书位于的第三MIME部分。
【表109】
第三方存储机构存储结果响应格式在图63中示出（图63A示出了成功情况下的分发证书发送响应，图63B示出了失败情况下的分发证书发送响应）。在如图57所示的整个消息结构中，如果请求消息处理成功，那么仅接收确认ACK SOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。
响应分发消息结构将在以下表110中描述。表110仅对应处理结果失败时。
【表110】
【分发客户端和分发通讯服务器之间的连接接口】
分发通讯服务器与请求实际电子文档分发的用户（内部发送方/接收方或者认证发送方/接收方）的系统（分发客户端）连接，并需要为用户提供基本文档收发功能。
分发客户端和分发通讯服务器之间的连接接口为允许分发客户端首先与分发通讯服务器通信以发送和接收电子文档的协议，且分类为如以下表111中描述的接口。
【表111】
下文将描述分发客户端和分发通讯服务器之间接口的细节。
首先，分发客户端和分发通讯服务器之间连接接口的共同事实为如下（1）。
（1）请求消息的消息标头扩展
用户的数字签名信息需要交付以包括在SOAP消息中，所述SOAP消息为从分发客户端发送到分发通讯服务器的请求消息的第一MIME部分。此外，验证用于SOAP消息数字签名的证书拥有者是否与对应用户匹配（VID验证）所需的附加用户信息（IDN、RValue）也被交付以包括在其中。
对应信息需要作为扩展元素位于请求消息的SOAP消息中消息标头元素的较低级处（任何##其它位置）。
此外，将添加对于使用相同证书的多个内部用户的个人认证信息。
扩展元素结构将在以下表112中描述，且扩展元素示例将在以下表113中描述。
【表112】
【表113】
下文中，将描述介于分发客户端和分发通讯服务器之间连接接口中的消息发送请求接口。
当分发客户端发送消息到分发通讯服务器以通过分发通讯服务器发送消息时，使用消息发送请求接口。
分发客户端的消息发送处理流程在图64中示出。
分发客户端的消息发送请求格式在图65中示出。在如图65所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求分发消息位于第二MIME部分中。如果存在由用户附加的文档，那么文档位于第三或者后续MIME部分中。
请求分发消息结构将在以下表114中描述，且实际示例将在以下表115中描述。
【表114】
在表114中，如果为了交付文档的目的，体块没有必要，那么文本可省略。
【表115】
分发客户端消息发送响应格式在图66中示出（图66A示出了成功情况下的分发证书发送响应，图66B示出了失败情况下的分发证书发送响应）。在如图66所示的整个消息结构中，如果请求消息处理成功，那么仅接收确认ACK SOAP消息位于第一MIME部分中。在错误情况下，SOAP消息位于第一MIME部分中，且错误响应消息位于第二MIME部分中。
响应分发消息结构将在以下表116中描述。表116对应只有当处理结果失败时。
【表116】
下文中，将描述介于分发客户端和分发通讯服务器之间的连接接口中的消息列表请求接口。
当分发客户端请求在分发通讯服务器中接收到的消息列表时，使用消息列表请求接口。
分发客户端的消息列表处理流程在图67中示出。
分发客户端的消息列表请求格式在图68中示出。在如图68所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求分发消息位于第二MIME部分中。
请求分发消息结构将在以下表117中描述，且实际示例将在以下表118中描述。
【表117】
【表118】
分发客户端的消息列表响应格式在图67中示出。在如图67所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应分发消息（在分发通讯服务器中接收的分发消息的列表）位于第二MIME部分中。
响应分发消息结构将在以下表119中描述，且实际示例将在以下表120中描述。
【表119】
【表120】
下文中，将描述在介于分发客户端和分发通讯服务器之间连接接口中的消息详细信息请求接口。
当分发客户端请求由分发通讯服务器接收的特定消息和附加文档时，使用消息详细信息请求接口。
分发客户端的详细信息请求处理流程在图69中示出。
分发客户端的消息详细信息请求格式在图70中示出。在如图70所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求分发消息的体块位于第二MIME部分中。
请求分发消息结构将在以下表121中描述，且实际示例将在以下表122中描述。
【表121】
【表122】
消息详细信息响应格式在图72中示出。在如图72所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应分发消息（分发消息的详细信息）位于第二MIME部分中。如果存在附加文档，那么附加文档依次位于第三或者后续MIME部分中。
响应分发消息结构将在以下表123中描述，且实际示例将在以下表124中描述。
【表123】
【表124】
下文中，将描述在介于分发客户端和分发通讯服务器之间连接接口中的垃圾消息报告接口。
当分发客户端将垃圾消息报告给分发通讯服务器时，使用垃圾消息报告接口。分发通讯服务器将垃圾消息报告给地址目录服务器，且然后将结果交付给分发客户端。
分发客户端的垃圾消息报告处理流程在图73中示出。
分发客户端的垃圾消息报告格式在图74中示出。在如图74所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求分发消息位于第二MIME部分中。
请求分发消息结构将在以下表125中描述，且消息示例将在以下表126中描述。
【表125】
【表126】
分发客户端的垃圾消息响应格式在图75中示出。在如图75所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应分发消息（在分发通讯服务器中接收到的分发消息列表）位于第二MIME部分中。
响应分发消息结构将在以下表127中描述，且消息示例将在以下表128中描述。
【表127】
在表127中，请注意，ResultCode指示垃圾报告消息的简单接受结果。
【表128】
下文中，将描述在介于分发客户端和分发通讯服务器之间连接接口中的物理地址搜索接口。
当分发客户端请求分发通讯服务器搜索物理地址时，使用物理地址搜索接口。分发通讯服务器搜索物理地址，且然后将结果交付给地址目录服务器。
与物理地址搜索处理相关的消息交换流程在图76中示出。
物理地址搜索请求格式在图77中示出。在如图77所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求分发消息位于第二MIME部分中。
请求分发消息结构将在以下表129中描述，且消息示例将在以下表130中描述。
【表129】
【表130】
物理地址搜索响应格式在图78中示出。在如图78所示的整个消息结构中，SOAP消息位于第一MIME部分中，且响应分发消息（在分发通讯服务器中接收的分发消息列表）位于第二MIME部分中。
响应分发消息结构将在以下表131中描述，且实际示例将在以下表132中描述。
【表131】
请注意，甚至在对于多个RAddress中一些或者全部正常进行搜索时，但是发生不存在地址错误时，ResultCode输入为成功（1），这与另一个接口不同。
*RAddress被描述为，不管ResultCode成功（1）/失败（0）以及是否存在RAddress，RAddress输入在IsExit中，IsExit为属性信息。
*当IsExit值为存在（1）时，输入Endpoint和Cert
*由于请求消息错误而不解析RAddress，RAddress可省略（因此，Endpoint和Cert将省略）
*如果ResultCode输入为失败（0），即，发生不同于不存在地址错误的其他错误，那么ErrorCode输入与错误原因对应的错误代码
【表132】
【分发通讯服务器和分发中继服务器之间的连接接口】
分发中继服务器为当在电子文档分发系统中分发通讯服务器之间直接发送电子文档的过程中发生错误，使得发送失败时，通过发送分发通讯服务器的代理服务器发送电子文档的系统。
分发中继服务器由国家工业促进局管理，且当在P2P分发过程中发生错误时，可支持与分发中继服务器连接的所有分发通讯服务器。
分发通讯服务器和分发中继服务器之间的连接接口为允许分发通讯服务器请求分发中继服务器发送电子文档的协议，且分类为以下表133中描述的接口。
【表133】
首先，分发通讯服务器和分发中继服务器之间连接接口的共同事实如下（1）。
（1）请求消息的消息标头扩展
分发通讯服务器的数字签名信息需要交付以包括在SOAP消息中，所述SOAP消息为介于分发通讯服务器和分发中继服务器之间的连接接口的第一MIME部分。此外，分发通讯服务器验证用于SOAP消息数字签名的证书拥有者是否与对应通讯服务器匹配（VID验证）所需的分发通讯服务器的附加信息（CorpNum、RValue）也被交付以包括在其中。
分发通讯服务器的附加信息需要作为扩展元素位于SOAP消息中消息标头元素的较低级处（任何##其它位置）。
扩展元素结构将在以下表134中描述，且扩展元素示例将在以下表135中描述。
【表134】
【表135】
下文中，将描述在介于分发通讯服务器和分发中继服务器之间连接接口中的消息发送请求接口。
当在从分发通讯服务器发送消息到其它另一个分发通讯服务器的过程中在其它另一个分发通讯服务器处发生接收错误时，使用消息发送请求接口以请求分发中继服务器发送消息且发行发送证书。分发中继服务器立即返回分发通讯服务器的消息发送请求的接受结果，且使用上述“分发证书发送接口”将在发送消息到接收分发通讯服务器之后接收到的接收证书发送到发送请求分发通讯服务器。
消息中继处理流程在图79中示出。
消息中继请求消息格式在图80中示出。在如图80所示的整个消息结构中，SOAP消息位于第一MIME部分中，且请求分发消息位于第二MIME部分中。如果存在由用户附加的文档，那么文档位于第三或者后续MIME部分中。
请求分发消息结构将在以下表136中描述，且实际示例将在以下表137中描述。
【表136】
在表136中，如果为了交付文档，体块没有必要，那么文本可省略。
【表137】
消息中继响应消息格式在图81中示出。在如图81所示的整个消息结构中，SOAP消息位于第一MIME部分中，响应分发消息位于第二MIME部分中，以及发送证书位于第三MIME部分中。如果在处理请求消息过程中发生错误，那么不产生第三MIME部分。
响应分发消息结构将在以下表138中描述，且实际示例将在以下表139中描述。
【表138】
在表138中，如果DocType为错误（9），那么不产生发送证书位于的第三MIME部分。
【表139】
下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档分发系统及使用该电子文档分发系统的电子文档分发方法的另一个示例。
【电子文档分发系统的结构和电子文档分发方法】
基于P2P通信分发电子文档，其中P2P通信允许遵守可靠分发标准的企业/机构彼此直接发送/接收电子文档。根据本发明的用于进行P2P通信的电子文档分发系统的基本元件为基于支持介于管理地址信息的地址目录服务器与每个收发实体之间分发的标准的分发通讯服务器系统。如果只提供地址目录服务器和分发通讯服务器系统，那么配备允许企业或者机构分发电子文档的基本结构。此外，发行用于证明发送方/接收方之间的文档分发的分发证书，且同时分发证书存储于第三方存储机构（认证电子文档存储机构）中，以为分发建立法律依据。
除基本元件外，根据本发明的电子文档分发系统包括：分发客户端应用程序（APP），用于为用户接口提供文档收发功能，以允许一般用户（企业/机构、个人）容易分发文档；电子文档格式寄存器，用于提供标准文档格式以提高创建文档的便利性；以及公共部门连接网关，用于作为另外配置元件为管理机构中继电子文档。
在上述电子文档分发系统中执行的基本过程将在以下表140中描述。
【表140】
【电子文档分发系统的组成要素】
下文将更系统地描述电子文档分发系统的元件。
为了建立电子文档分发，首先，作为分发的主要主体（principal agent）的“（1）收发实体”需要存在，且收发实体需要包括“（2）分发通讯服务器系统”，分发通讯服务器系统遵守分发通讯服务器标准以分发文档。此外，作为电子文档分发基本构造的“（3）地址目录服务器”登记和管理收发实体的认证电子邮件地址，且需要存在用户。
基于以上基本构造，提供“（4）分发客户端应用程序”以为用户提供分发便利性，且另外提供支持连接行政/公共机构的“（5）公共部门连接网关”以及管理文档格式的“（6）电子文档格式寄存器”。
下文中，将详细描述上述组成元件。
（1）收发实体
在电子文档分发的基本基础组件中，作为分发标准的单元为收发实体。收发实体根据参与分发的角色充当发送方或者接收方，且这些实体根据分发协议通过分发通讯服务器系统来分发文档（信息）。
参与分发的所有收发实体根据分发通讯标准建立能够收发文档的分发通讯服务器系统，且然后将分发通讯服务器系统的物理地址信息登记于地址目录服务器中以为参与电子文档分发创建基础。在此情况下，每个收发实体具有实际分发用户，实际分发用户具有至少一个较低级别的认证电子邮件地址。
电子文档分发中被标示为收发实体的实体限于通过国家工业促进局建立遵守通讯服务器标准的系统且然后接收标准兼容性和互操作性的认证的实体。为了证实分发，（1）在通过认证收发实体分发电子文档之后，（2）分发证书需要根据标准发行且存储于第三方存储机构中。
在此情况下，收发实体被分类为作为合法拥有者和电子文档负责人负责直接发送电子文档的实体；以及作为实际拥有者和分发电子文档负责人的用户代理服务的实体。在此情况下，如果电子文档拥有者为直接发送电子文档的收发实体，那么只有通过接收分发通讯服务器系统的标准兼容性和互操作性认证且将分发证书稳定地存储于第三方存储机构中，电子文档拥有者才可作为收发实体参与分发。
与之相比，如果收发实体负责通过作为第三方的电子文档拥有者（用户）的代理服务器发送电子文档，那么收发实体需要证明，收发实体稳定且可靠地管理发送消息且管理和认证用户信息。为了确保第三方分发的稳定性和可靠性，暂时地，执行第三方分发的收发实体仅限于第三方存储机构提供商。
（2）分发通讯服务器系统
分发通讯服务器系统需要建立消息收发功能以及搜索与接收方有关的地址信息以及与地址目录服务器有关的安全性相关信息的功能，以基于分发通讯服务器标准分发电子文档（信息）。分发通讯服务器系统物理上具有一个电子邮件地址（IP地址），但可发行或者管理较低级别用户的多个用户账户，且每个用户账户具有一个认证电子邮件地址。
分发通讯服务器系统需要管理每个用户账户的电子文档邮箱，以管理用户账户，且分发通讯服务器系统作为用户账户代表负责稳定且可靠的进行电子文档分发。
为了作为收发实体参与电子文档分发，分发通讯服务器系统被认证是否适合实施根据本发明的要求，且在与其它解决方案的互操作性中没有问题。
认证分发通讯服务器系统的标准兼容性和互操作性的认证系统管理认证的收发实体。此外，如果地址目录服务器请求在登记认证电子邮件地址的过程中确认是否认证，那么认证系统返回结果。
根据如图82所示的以下过程，通过认证电子邮件地址来认证和登记分发通讯系统。
首先，充当收发实体的企业/机构或者个人用户根据技术标准来建立分发通讯服务器系统。
接着，通过由认证测试床提供的自动验证设备来认证建立的分发通讯服务器系统的标准兼容性和互操作性。
接着，完成验证的收发实体请求认证测试床进行认证测试。
接着，如果根据认证测试床的测试过程的系统认证结果为“合格”，那么收发实体准备用于登记认证电子邮件地址的下一个程序。
接着，认证测试床将与通过认证检查的收发实体有关的信息交付给地址目录服务器，且地址目录服务器利用所述信息作为地址登记条件。
接着，收发实体请求地址目录服务器发行唯一ID，以登记认证的分发通讯服务器系统。
接着，如果分发通讯服务器系统完全登记在地址目录服务器中，那么分发通讯服务器系统可参与电子文档分发。
接着，在完成认证分发通讯服务器系统之后，用户账户为开放。在代表性认证电子邮件地址的情况下，请求用户账户用认证电子邮件地址登记。
（3）地址目录服务器
为了参与可靠的电子文档分发，所有用户需要接收唯一电子邮件地址。
（4）分发客户端应用程序
分发客户端应用程序是指提供UI的应用程序，诸如文档发送和接收、接收文档读取以及参与文档分发的用户管理。分发客户端应用程序不独立发送/接收文档，而是需要与分发通讯服务器系统连接。
通过分发客户端应用程序创建或者附加的文档使用分发通讯服务器系统交付给用户，搜索通过分发通讯服务器系统接收的文档。如果分发通讯服务器系统通过用户账户管理收发邮箱，那么分发客户端应用程序通过检查用户账户信息只可访问接收文档中的相应文档。
根据用户请求，分发客户端应用程序可实施为C/S型应用程序或者web型屏幕。
（5）公共部门连接网关
不能接受电子文档分发的行政或者公共机构执行这样的功能：即在电子文档分发系统下通过公共部门连接网关用民营企业、机构或者个人接替行政或者公共机构。
（6）电子文档格式寄存器
想要使用分发通讯服务器系统发送电子文档的用户可使用office工具直接创建待发送文档。电子文档格式寄存器为支持管理（诸如文档格式登记和管理、文档格式搜索、读取和下载），以当登记和管理标准文档格式以支持允许用户容易创建电子文档时由用户应用程序（诸如分发客户端应用程序）使用的系统。
电子文档格式寄存器提供管理文档标准格式的服务器引擎；以及允许客户端应用程序（APP）搜索和下载文档标准格式的标准接口，且然后插入内部程序以使用文档标准格式。
【电子文档分发方法】
电子文档分发中分发电子文档的整个过程大致分为“（1）分发之前的事先准备步骤”、“（2）电子文档分发步骤”、“（3）分发证实步骤”。下文中，将详细描述上述三个步骤。此外，将详细描述“文档收发方法”、“分发证实方法”和“垃圾消息处理方法”。
（1）分发之前的事先准备步骤
-电子文档格式寄存器管理者使用电子文档格式寄存器登记待使用的标准文档格式。
-收发参与者确定是否为了可靠分发而自主建立分发通讯服务器系统，或者打开先前建立的分发通讯服务器系统中的用户账户以使用分发通讯服务器系统。如果为了可靠分发自主建立分发通讯服务器系统，那么建立用于收发电子文档的分发通讯服务器系统，且然后通过认证机构对分发通讯服务器系统的标准兼容性和互操作性进行认证测试。此后，收发参与者访问地址目录服务器以申请和接收经认证的分发通讯服务器系统的收发实体ID，然后自主登记和管理内部实际用户的内部标识符，并基于标准文档格式（可选）将标准文档格式创建功能插入用于文档创建功能的客户端应用程序。与之相比，如果使用包括允许第三方分发的分发通讯服务器系统的收发实体，那么收发参与者请求通过分发通讯服务器系统打开企业/机构/个人的用户账户，且然后将用户账户的认证电子邮件地址信息登记于地址目录服务器中。此后，收发参与者将标准文档格式创建功能插入于客户端应用程序中，以便一般用户基于标准文档格式（可选）使用文档创建功能。
（2）电子文档分发步骤
○文档发送方
-文档发送方使用文字处理器选择待分发文档或者创建待发送文档。
-接收文档的另一方的地址信息以及待交付文档，选择是否加密文档和是否进行数字签名（对附加交付文档而不是发送消息执行加密和数字签名，且这个过程为可选）
-分发客户端应用程序基于与地址目录服务器连接的接收方的认证电子邮件地址，获得物理地址信息和加密用公钥信息（视情况，如果分发客户端应用程序不获得物理地址，那么分发通讯服务器执行这个过程）
-分发客户端应用程序基于接收方地址信息（物理地址信息和认证电子邮件地址都为可用）请求发送到分发通讯服务器
○发送方的分发通讯服务器
-如果在分发客户端应用程序中请求的发送请求消息不是接收方物理地址信息，那么分发通讯服务器基于地址目录服务器的认证电子邮件地址来查询接收方的收发实体的物理地址信息
-电子文档被封装为在分发协议标准中定义的消息结构
-基于发送方的分发通讯服务器的证书对消息进行数字签名
-基于终端物理地址信息将消息发送到接收方
○接收方的分发通讯服务器
-在接收消息之后，验证消息且从消息提取文档
-包括接收证书的消息发送到发送方作为同步响应
（3）分发证实步骤
-接收方在接收用于文档接收确认的文档时，创建“接收证书”且将接收证书交付给发送方。接收接收证书的发送方将接收证书存储于第三方存储机构中。
如果有来自发送方的请求，那么接收方将接收文档交付给文档实际负责人（用户），且然后在负责人检查接收文档时创建“读取证书”以将读取证书交付给发送方。接收“读取证书”的文档发送方将“读取证书”存储于第三方存储机构中（只有当有来自发送方的请求时，发行读取证书）。
-当发送方尝试将文档交付给接收方但尝试失败时，发送方请求作为客观第三方的电子文档分发中心以证实发送尝试，且接收发送请求的电子文档分发中心发行“发送证书”以证实发送请求的接收，并将发送证书交付给发送请求方。接收发送证书的发送请求方将“发送证书”存储于第三方存储机构中。
○文档收发方法
发送方和接收方通过分发通讯服务器系统电子分发文档。分发通讯服务器系统根据分发协议，发送/接收电子文档。所有消息由发送确认和接收确认（或者接收证书）消息组合构造，以用于可靠消息分发，且通过地址目录服务器获得接收方物理地址信息。
○分发证实方法
“分发证实”是指关于与使用可靠方法的电子文档分发相关的发送、接收或者读取的事件证实。在此情况下，为与电子文档分发相关的动作发行的证书统称为“分发证书”。
分发通讯服务器系统在发送和接收时发行分发证书，以证实发送和接收动作，且将发行的分发证书存储于第三方存储机构中以用作分发动作证据材料。
分发通讯服务器系统证实发送、接收和读取电子文档的事件，且为事件创建分发证书。分发证书包括分发证书的识别信息、分发证书创建时间和到期时间、分发证书策略和分发证实目标。
电子文档发送的分发证书由电子文档分发中心创建，且分发证实目标包括发送方的识别信息、接收方的识别信息、分发识别信息、文档识别信息和电子文档发送请求时间。
电子文档接收的分发证书由接收电子文档的接收方创建，且分发证实目标包括发送方识别信息、接收方识别信息、分发识别信息、文档识别信息、电子文档发送时间和电子文档接收时间。
电子文档读取的分发证书由检查电子文档接收的用户创建，且分发证实目标包括发送方识别信息、接收方识别信息、分发识别信息、文档识别信息、电子文档发送时间、电子文档接收时间和电子文档检查时间。
如上所述创建的分发证书通过NPKI或者GPKI证书来数字签名，且所创建的分发证书交付给电子文档发送方。所有分发证书优选存储于第三方存储机构中。
○垃圾消息处理方法
电子文档分发具有基础结构，其中，基本上，发送方通过认证分发通讯服务器系统发送电子文档，且接收方也基于认证分发通讯服务器系统接收电子文档，使得发送方为此负责。然而，垃圾发送方可打开分发通讯服务器系统中的用户账户，且使用该用户账户发送电子文档。此外，当前认证系统只认证系统的技术内容。因此，如果垃圾发送方建立分发通讯服务器系统，在技术上认证分发通讯服务器系统，以及然后使用分发通讯服务器系统作为垃圾发送单元，那么在初始阶段难以阻止任何企图。
因此，为了解决以上问题，在根据本发明的标准文档分发基础设施中，根据用户报告方法提供基于认证名单管理的白名单以及基于垃圾目标名单管理的黑名单系统，且应用允许接收方拒绝通过这个系统接收的处理以防止垃圾消息。
报告垃圾消息和检查发送方的功能是基本的，因此所有分发通讯服务器需要必须建立这些功能。
如果接收方确定接收消息为垃圾消息，那么接收方根据图83所示的过程将垃圾消息报告给电子文档分发中心的地址目录服务器，且与其相关的处理程序如下。
首先，如果接收方确定在接收消息时，该消息为垃圾消息，那么接收方通过分发通讯服务器系统将该消息作为垃圾消息报告给地址目录服务器。
接着，接受来自分发通讯服务器系统的垃圾消息报告的地址目录服务器返回指示接受的确认消息。
接着，作为管理地址目录服务器的主要机构的国家IT产业促进机构分析消息且调查发送方，以检查和确定是否将发送方的认证电子邮件地址添加为黑名单。
接着，如果发送方被确定为黑名单候选方，那么地址目录服务器将对应的认证电子邮件地址添加到黑名单，且然后将黑名单添加通知给发送方。
接着，地址目录服务器将垃圾消息请求处理结果交付给垃圾报告方（接收方）。
在上述处理程序中，仅被认证且正式登记的通讯服务器系统的信息记录在白名单中。相反，当发送方地址登记为垃圾发送方时，所述地址登记在黑名单中。如果重复产生通过相同分发通讯服务器系统登记于黑名单中的垃圾地址，那么电子文档分发中心确定是否取消对相应通讯服务器系统的认证，且然后取消认证并从白名单删除垃圾地址。
当接收消息时，接收方检查地址目录服务器的白名单和黑名单，以确认发送方是否为可靠且合法的用户，从而确定是否拒绝接收。发送方检查方法包括在接收时的实时检查方法以及通过在接收方的分发通讯服务器中以缓存类型管理的名单来检查发送方的定期检查方法。
在实时检查发送方的过程中，如图84所示，在接收方接收消息时，确定发送方地址是登记在地址目录服务器中的白名单还是黑名单中，且然后确定是否拒绝接收。下文将描述实时检查发送方的细节。
首先，如果接收消息，那么接收方的分发通讯服务器系统将检查请求消息交付给地址目录服务器以检查发送方是否为合法用户。
接着，地址目录服务器检查请求用户的地址信息是否包括在白名单中。
接着，如果地址不在白名单中，那么地址目录服务器立即返回结果消息到检查请求方，所述结果消息指示请求用户为非登记用户。如果地址包括在白名单中，那么地址目录服务器检查对应地址是否登记在黑名单中。
接着，地址目录服务器将是否登记在黑名单中的结果消息返回到检查请求方。
接着，如果接收方从地址目录服务器接收到指示发送方不是合法用户（不包括在白名单中或者登记在黑名单中）的结果消息，那么接收方将接收消息自主处理为垃圾消息，且然后记录和存储从地址目录服务器接收的处理结果消息以及垃圾消息接收记录。
接着，垃圾消息处理记录需要存储达一个月或者更长时间，以确认对于对应发送方的接收拒绝合法性。
此外，在定期检查发送方的过程中，如图85所示，接收方预先从地址目录服务器接收白名单和黑名单，自主管理白名单和黑名单，以及藉此确定发送方地址是否登记在白名单和黑名单中以确定是否拒绝消息接收。下文将描述定期检查发送方的过程细节。
首先，接收方的分发通讯服务器系统预先向地址目录服务器请求最新白名单和最新黑名单，且自主管理白名单和黑名单。在此情况下，如果名单变更，那么交付是否请求自动通知。即使请求名单变更事件的自动通知，导入地址目录服务器中最新名单的请求也定期执行，使得名单信息差异最多为一天。
接着，如果白名单和黑名单变更，那么地址目录服务器将变更细节广播给请求变更通知的用户。
接着，接收名单变更事件的用户的分发通讯服务器系统修改被自主管理的名单信息以同步于该名单。
接着，如果接收到消息，那么接收方检查自主管理的名单以检查是否为地址目录服务器的合法用户。
接着，作为检查自主管理的名单的结果，如果确定发送方不是合法用户（不包括在白名单中或者登记在黑名单中），那么接收方将接收消息自主处理为垃圾消息且记录和存储垃圾消息接收记录。
接着，垃圾消息处理记录需要存储达一个月或者更长时间，以确认对于对应发送方的接收拒绝合法性。
【分发通讯服务器系统】
下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档分发系统的分发通讯服务器系统。
分发通讯服务器系统大致由消息发送、消息接收、接收消息的邮箱管理、消息安全性（用户认证、文档加密/解码）、收发记录管理、地址目录服务器连接、消息验证、内部系统连接接口、分发证书发行和管理以及第三方存储机构连接构造。
图86示出了分发通讯服务器系统的构造。参考图86，将如下详细描述分发通讯服务器系统的组件（1）到（9）。
（1）消息发送/接收
-根据分发协议发送和接收消息。
（2）每个用户的账户（邮箱）管理
-发送或者接收消息根据用户账户或者内部标识符存储于每个账户的邮箱中。
-对于存储于邮箱中的发送文档，管理四个阶段状态信息，包括“发送过程”、“发送完成”、“发送失败”和“负责人完成接收”。在此情况下，“发送过程”的状态是指当在发送文档之后未从接收方接收到响应时的状态，“发送完成”状态是指从接收方的分发通讯服务器系统接收到“接收证书”时的状态，“发送失败”状态是指由于在接收分发通讯服务器系统内部发生错误或者在收发过程中发生网络错误导致返回SOAP故障消息时的状态，以及“负责人完成接收”状态是指当发送分发通讯服务器系统从接收方接收到用于证实负责人检查文档的“读取证书”时的状态。
-对于存储于每个用户账户的邮箱中的接收文档，管理四个阶段状态信息，包括“验证错误”、“接收确认之前”、“接收确认”和“读取确认”。在此情况下，“验证错误”状态是指在验证接收消息的基本结构中发生错误时的状态，“接收确认之前”状态是指在接收文档负责人读取邮箱中的接收文档列表之前的状态，“接收确认”状态是指接收文档负责人已经读取邮箱中的接收文档列表时的状态，以及“读取确认”状态是指接收文档负责人已经读取接收文档的细节时的状态，接收方的分发通讯服务器系统在此时发行“读取证书”，且然后将“读取证书”交付给发送方。
-如果从接收用户接收到删除请求，那么物理删除相应的接收文档。
-在邮箱中，发送文档、发送的接收确认消息以及接收负责人的接收确认消息具有连接信息以相互连接。
（3）地址目录服务器连接
-分发通讯服务器系统根据由地址目录服务器提供的地址信息登记和搜索处理来管理地址信息。
-分发通讯服务器系统包括可调用由地址目录服务器提供的服务的客户端功能。换言之，分发通讯服务器系统提供远程调用由地址目录服务器提供的地址信息登记、搜索、编辑和删除功能的服务客户端功能。
（4）消息安全性（用户认证、文档加密/解码）
-分发通讯服务器系统基本上执行由分发协议建议的消息安全性功能（消息数字签名、签名验证）。
（5）发送/接收记录管理
-分发通讯服务器系统必须存储/管理发送/接收记录达至少一年或者更长时间。
-关于待存储的发送/接收记录的信息包括发送记录和接收记录。发送记录包括消息id、相关消息id、发送方（包括用户账户）、接收方、发送时间以及发送文档的哈希值。接收记录包括发送方、接收方（包括用户账户）、接收时间以及接收文档的哈希值。
（6）分发证书发行和管理
-分发通讯服务器系统发行和管理分发证书，以证实文档发送和接收事件的内容。
-发行的分发证书被请求存储于第三方存储机构中，同时证书被交付以确保可靠性。
-在发行分发证书之后，分发通讯服务器系统管理存储于第三方存储机构中的分发证书的记录。分发证书的发行记录包括分发证书id、分发证书发行时间、相关消息id、分发证书原件（可选）以及在将分发证书存储于第三方存储机构中之后接收到的存储密钥信息。
（7）消息封装过程（封装、解析、提取）
-分发通讯服务器系统在发送发送文档之前，将发送文档封装为在分发协议中定义的消息结构。
-分发通讯服务器系统利用在分发协议中定义的消息结构来解析（语法分析）接收文档，并提取必要信息。
（8）请求存储分发证书
-为了请求存储分发证书，一般收发实体将第三方存储机构存储请求消息发送到第三方存储机构的分发通讯服务器系统（远程存储请求）。
-如果接收到认证电子文档存放处存储请求消息，那么第三方存储机构的分发通讯服务器系统调用存储请求客户端，以将分发证书存储于第三方存储机构中。
-如果第三方存储机构的分发通讯服务器系统直接创建分发证书，那么第三方存储机构的分发通讯服务器系统直接调用第三方存储机构的存储请求客户端（本地存储请求）。
-用于请求存储分发证书的客户端根据第三方存储机构的收发连接接口标准请求第三方存储机构存储分发证书。
（9）附加服务
-分发通讯服务器系统分发分发客户端应用程序管理并且管理分发客户端应用程序管理版本。
-分发通讯服务器系统执行消息分发管理（记录或者统计信息）。
-分发通讯服务器系统执行系统管理（系统监控或者环境信息）。
-分发通讯服务器系统执行文档格式管理。
如果根据本发明的包括上述组件（1）到（9）的分发通讯服务器系统应用于第三方存储机构，如图87所示，那么当存储分发证书时，分发证书存储请求模块调用根据第三方存储机构连接接口标准开发的连接接口客户端，以请求存储分发证书。
如果根据本发明的包括上述组件（1）到（9）的分发通讯服务器系统应用于一般收发实体（一般企业实体），如图88所示，那么通过这样的方法存储分发证书：即，该方法将用于存储分发证书的请求消息发送到第三方存储机构的分发通讯服务器系统并接收处理结果。
使用根据本发明的包括上述组件（1）到（9）的分发通讯服务器系统在发送方和接收方之间直接分发的过程由四个步骤构成，包括“（1）获得接收方物理信息和安全性信息”、“（2）发送消息和确认发送”、“（3）确认任务接收方的接收”和“（4）发行和存储分发证书”。将参考图89详细描述所述四个步骤。
（1）接收方物理地址和安全性信息获取
-发送方系统请求物理地址信息和安全性信息（如果需要发送消息的接收密码），其中实际消息基于另一方的地址信息交付给地址目录服务器以获得物理地址信息和安全性信息。
-在分发客户端应用程序向地址目录服务器请求接收方物理地址信息和安全性信息之后，接收方物理地址信息被交付给分发通讯服务器。
-接收方地址信息可只使用用户id（例如，居民登记号码或者企业登记号码）来获得，用户id只有当接收方允许发送方基于id搜索地址信息时才是可用的。
如果发送方已经知道接收方物理地址信息和安全性信息，那么这个过程可省略。
（2）消息发送和发送确认
在根据分发协议标准来封装消息之后，发送方基于分发通讯服务器系统的证书进行数字签名。
-分发通讯服务器系统发送以先前获得的物理地址封装且数字签名的消息。
-接收消息的分发通讯服务器系统验证基本封装结构、数字签名有效性和发送方适用性（对于验证的详细内容，请参考“2.4.6消息验证”），且然后创建用于接收确认的接收证书或者错误消息。
-接收分发通讯服务器系统将创建的响应消息发送到发送方。
-发送和发送确认过程由同步消息处理构造。
（3）任务接收方的确认接收
-如果发送方在发送消息时，请求任务接收方负责人的读取确认消息，那么接收方必须创建用于证实负责人读取确认的读取证书，以在确认企业消息接收时将读取证书交付给发送方。
-如果接收方将负责人读取确认的读取证书消息发送到消息发送方，那么消息发送方同步发送接收确认消息。
（4）分发证书发行和存储
-如果需要每个步骤分发的证据，那么发送方根据所述步骤发行接收证书、读取证书和发送证书并将证书存储于第三方存储机构中，以确保分发法律证据的基础。
使用根据本发明的分发通讯服务器系统在发送方和接收方之间直接分发消息的过程除了执行上述“（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）消息收发
由分发通讯服务器系统收发消息的基本过程遵循如上所述根据本发明的“电子文档分发方法”的“文档收发方法”。作为收发消息基础的消息交换类型是基于消息分发协议的同步响应，且可形成发送消息和接收确认消息、发送消息和接收错误消息、发送消息和企业响应消息（包括接收确认消息的含义）的构造。
消息收发类型包括两个类型，包括发送和接收确认响应消息的组合以及发送和企业响应消息的组合。
消息收发类型为发送和接收确认响应消息的组合时的处理流程在图93中示出。发送消息和接收确认（或者接收错误）消息由SOAP（简单对象访问协议）请求-响应组合构成，且发送消息及其响应消息通过将发送消息MessageId插入于待发送的响应消息的RefToMessageId中来连接，其细节将参考下文将描述的【分发协议】描述。
消息收发类型为发送和企业响应消息的组合时的处理流程在图94中示出。发送消息以及包括接收确认（或者接收错误）消息的响应消息由SOAP请求-响应组合构成。在接收方接收消息且然后实时创建对与内部系统有关的业务处理的响应文档之后，响应文档和接收确认ACK消息包括在响应消息中以交付给发送方。发送消息及其响应消息通过将发送消息MessageId插入于待发送响应消息的RefToMessageId中来连接，其细节将参考下文将描述的【分发协议】描述。
收发消息的结构具有如图95所示的多部分-MIME结构。SOAP消息插入于第一MIME部分中，且待发送文档插入于第二或者后续MIME部分中。
由SOAP标头和SOAP体块构成的SOAP封装包插入于第一MIME中。用于收发消息的消息标头、数字签名、接收确认消息、同步发送标记和错误消息插入于SOAP标头中。此外，在第二MIME部分中，插入待交付给消息接收方的文档（信息）。如果负责人的接收确认消息交付，那么文档插入于这个位置中。在第三MIME部分中，如果有两个以上文档（信息）待交付给消息接收方，那么文档依次插入于第三或者后续MIME部分中。
（2）接收消息邮箱管理
如果接收到消息，那么分发通讯服务器系统将接收消息存储于每个账户的邮箱中。接收消息邮箱针对一个或者多个用户账户是分开的，以存储和管理消息。接收消息邮箱需要提供根据用户请求（新接收消息存在性、接收消息读取、接收消息下载以及接收消息删除）执行所需过程的接口，并以标准化方式返回结果。
为了使由分发通讯服务器系统管理的用户账户取得包括在电子文档分发中的认证电子邮件地址的资格，分发通讯服务器系统需要满足认证要求以具有可靠用户账户（要求将由独立评估指导手册定义，目前，人们认识到，只有第三方存储机构满足认证要求）。
因此，允许个人或者企业（机构）获得电子文档分发中认证电子邮件地址的方法包括以下两个方法。第一方法为自主建立分发通讯服务器系统并认证分发通讯服务器系统以将获得的收发实体ID登记于地址目录服务器中的方法。第二方法为在另外满足在认证分发通讯服务器系统中具有可靠用户账户的要求的收发实体中打开邮箱以接收用户ID且然后将用户ID登记于地址目录服务器中的方法。
（3）消息安全性
发送消息安全性被分为用于确保完整性的数字签名以及用于确保机密性的加密/解码。通过分发通讯服务器系统发送的消息分为SOAP消息和附加文档。在此情况下，附加文档在分发客户端应用程序中已经被加密，且只有用于收发消息的标头信息包括在SOAP封装包中，使得在分发通讯服务器系统中不执行另外加密过程，但在消息收发过程中执行防止伪造的数字签名过程。数字签名方法和详细程序参考下文将描述的【分发协议】。
（4）收发记录管理
分发通讯服务器系统需要管理收发记录信息，以在将来引起与发送/接收相关的纠纷或者问题时检查记录。记录信息不仅可包括与收发动作有关的信息，而且包括实际发送/接收文档。如果实际文档存储于第三方存储机构中，那么仅存储从第三方存储机构接收的登记证书而不存储文档原件。
（5）地址目录服务器连接
使用由地址目录服务器提供的服务连接接口，分发通讯服务器系统与地址目录服务器连接。地址目录服务器提供两种地址搜索服务、地址登记服务和地址变更服务。分发通讯服务器系统基本上提供地址搜索服务中“与认证电子邮件地址相关的物理地址搜索服务”功能。
除搜索服务外，根据是否使用分发被通讯服务器系统以较低级别登记/管理为企业或者个人的认证电子邮件地址的用户账户，来确定是否使用地址登记服务和地址变更服务。如果分发通讯服务器系统登记/管理的用户账户被认证，从而被登记为认证电子邮件地址，因为分发通讯服务器系统通过代理服务器执行认证电子邮件地址的登记和变更服务，所以连接地址目录服务器的相应服务。
（6）消息验证
当分发通讯服务器系统发送/接收消息时，接收方在接收消息时验证消息有效性，与图96所示的过程相似，在验证消息有效性之后，只有消息通过验证时，接收方才将消息接收确认消息交付给发送方。否则，接收方发送关于接收消息的错误消息。
验证目标：接收消息的架构验证（验证是否根据分发协议正确封装接收消息）、消息完整性验证（验证接收消息的数字签名值以验证消息为完整而无伪造）以及消息发送方验证（验证用于数字签名的证书拥有者是否与消息发送方相同，以认证对消息进行数字签名的发送方是否与消息上表示的发送方相同）。
（7）内部系统连接接口
分发通讯服务器系统提供标准化收发接口，以允许内部系统通过分发通讯服务器系统发送和接收文档。接口细节将参考下文将描述的【分发客户端应用程序】描述。
（8）分发证书发行和管理
分发证书的基本条件为（1）通过发送和接收分发通讯服务器系统创建分发证书，（2）通过基于GPKI和NPKI证书执行数字签名来创建分发证书，和（3）基于电子文档分发动作创建分发证书（在此情况下，如果当电子文档分发一次时交付一个或者多个电子文档，那么创建一个分发证书并分配ID以识别相应分发，以分发一个电子文档，且藉此通过分发创建分发证书）。
当发行分发证书时，认为：（1）因为由个人收发实体创建分发证书的序列号，所以使用20字节随机数以给予唯一性，这不同于现有证书的标准，（2）未定义分发证书的更新和撤销，（3）创建分发证书和分发客户端应用程序的分发通讯服务器系统的系统时间始终保持当前时间，以及（4）分发证书策略只使用在技术标准中定义的OID和名称。
分发证书发行过程在图97中示出，且分发证书类型以及创建分发证书所需的基本信息在以下表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】
| 证书类型 | 策略OID | Qualifier |
| 发送证书 | 1.2.410.200032.2.?.1 | 发送证书 |
| 接收证书 | 1.2.410.200032.2.?.2 | 接收证书 |
| 接收确认证书 | 1.2.410.200032.2.?.3 | 接收确认证书 |
（7）requestInfo，证书请求消息信息
-这个字段设定为空（NULL）。
RequestInfo::=CHOICE{
arcCertRequest ARCCertRequest,
null NULL}
（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】
在如上所述将分发证书与第三方存储机构连接的方法中，请求将分发证书存储于第三方存储机构中，同时发行分发证书以确保发行分发证书的可靠性。
在第三方存储机构提供商的分发通讯服务器系统的情况下，分发证书存储过程在图98中示出。第三方存储机构连接模块直接请求将从分发通讯服务器系统发行的分发证书直接存储于第三方存储机构中。第三方存储机构连接模块由分发证书存储请求模块和第三方存储机构连接接口客户端模块构成。根据现有第三方存储机构连接接口模块标准，分发证书存储于第三方存储机构中。
在一般收发实体的分发通讯服务器系统的情况下，分发证书存储过程在图99中示出。为了请求第三方存储机构提供商存储所发行的分发证书，请求消息交付给第三方存储机构提供商的分发通讯服务器系统。从外部接收存储请求的第三方存储机构提供商的分发通讯服务器系统请求通过第三方存储机构连接接口将分发证书存储于第三方机构中。第三方存储机构连接模块请求第三方存储机构根据现有第三方存储机构连接接口模块标准来存储分发证书。
收发实体将分发证书存储于第三方存储机构中的详细处理在图100中示出，且下文将描述细节。
○分发证书登记
-当分发证书存储于第三方存储机构中时，可通过第三方存储机构提供商和收发实体之间协议来指定存储机构。存储机构使用证书将分发证书存储于第三方存储机构中。
○第三方存储机构的存储请求过程类型
-第三方存储机构提供商可提供同步处理和异步处理中至少一个，且根据由待连接第三方存储机构提供商提供的方法来连接分发通讯服务器。
-情况1：同步处理过程（当发送方请求存储分发证书时，同步执行完成分发证书登记于第三方存储机构中之后的发行登记证书的所有过程，使得发送方的分发通讯服务器接收登记证书作为同步响应消息。因为请求的响应消息为第三方存储机构的最终登记结果，所以如果发生存储请求错误，那么通过发送方的分发通讯服务器进行重新处理。）
-情况2：异步处理过程（如果发送方请求第三方存储机构分发通讯服务器存储分发证书，那么第三方存储机构分发通讯服务器首先验证请求消息有效性，然后接受存储请求。第三方存储机构提供商需要将根据存储请求消息登记于第三方存储机构中的待发行登记证书交付给发送方的分发通讯服务器，发送方为第一存储请求方。因为第三方存储机构提供商负责将登记证书登记于接受存储请求的第三方存储机构中，所以如果发生存储错误，那么也通过第三方存储机构提供商进行重新处理。）
【分发协议】
下文中，将详细描述应用于如上所述根据本发明示例性实施方式的电子文档分发系统和方法的分发协议。
在应用于根据本发明示例性实施方式的电子文档分发系统和方法的分发协议的描述中，将以顺次描述“（1）消息封装”、“（2）消息封装包配置”和“（3）HTTP绑定”。
（1）消息封装
分发协议的消息结构应用ebMS v2.0标准，且具有两个逻辑MIME部分。
第一MIME部分包括SOAP消息且称为标头容器。SOAP消息由标头和体块构成。第二MIME部分为0个或者多个另外MIME部分且也称为净荷容器。第二MIME部分包括应用程序级附加文档。
分发消息的基本结构在图101中示出，且遵守诸如简单对象访问协议（SOAP）1.1和带附件SOAP消息的标准。
分发消息封装包的MIME标头的所有组成要素遵守带附件SOAP消息的标准。此外，消息封装包中的内容类型MIME标头必须具有与包括SOAP消息文档的MIME体块部分的MIME媒体类型相同的类型属性。根据SOAP标准的SOAP消息的MIME类型需要具有“text/xml”值。
根部分需要包括Content-ID MIME标头，Content-ID MIME标头具有基于【RFC2045】的结构，且除Multipart/相关媒体类型的基本参数外，开始参数（在【RFC2387】中可选）需要始终存在。Multipart/相关消息封装包的MIME标头示例将在以下表146中描述。
【表146】
下文中，在描述根据本发明的分发消息时，消息封装包的路由体块部分定义为标头容器。标头容器包括一个SOAP消息作为MIME体块部分，如带附件的SOAP消息规范中所定义的。
根据SOAP标准，标头容器的MIME内容类型标头需要具有“text/xml”值。内容类型标头可包括“字符集”属性，且其示例将在表147中描述。
【表147】
MIME字符集属性用于区分用于创建SOAP消息的字符组。这个属性的语义在【XMLMedia】中明确表达的text/xml的“字符集参数/编码审议”中描述。有效值列表可在http://www.iana.org/中找到。
如果MIME字符集属性包括内容类型标头，那么MIME字符集属性需要等同于SOAP消息的编码说明部分。此外，MIME字符集属性不包括当创建SOAP消息时与编码冲突的值。
当这个文档被编码时，{UTF-8}必须用于使兼容性最大化。然而，由于为从text/xml【XMLMedia】演绎的媒体类型所定义的处理规则，这个MIME属性不具有默认值。
标头容器示例将在以下表148中描述。
【表148】
根据带附件SOAP消息的标准，消息封装包中可包括0或者多个净荷容器。如果消息封装包包括应用程序净荷，那么消息封装包必须包括在净荷容器中。
如果消息封装包不包括应用程序净荷，那么净荷容器不存在。净荷容器的内容通过SOAP体块中ebXML消息Manifest元素来区分。
ebXML消息服务规范不限制应用程序净荷的结构和内容。净荷可为简单明文对象或者复杂重叠的几个部分的对象。根据使用ebXML消息服务如何定义操作过程或者信息交换，可改变净荷对象的结构和配置规范。净荷容器示例将在以下表149中描述。
【表149】
基于【RFC2045】标准，根据本发明的分发消息的所有MIME部分可包括另外MIME标头。在实施中，本发明中未定义的MIME标头可忽略，且未识别的MIME标头应当忽略。例如，在实施中，内容长度可包括在消息中。然而，包括内容长度的消息的接收方可忽略内容长度。
（2）消息封装包配置
基于SOAP标准，所有扩展元素的内容需要限于可用名称空间。本发明中定义的所有ebXML SOAP扩展元素的内容需要限于ebXML SOAP封装包扩展名称空间。名称空间的说明部分可包括在SOAP封装包、标头或者体块元素中，或者直接包括在每个SOAP扩展元素中。
SOAP封装包将SOAP消息中各种Namespace申明为SOAP消息的根项目。待申明Namespace为如以下表150。
【表150】
消息封装包的架构结构在表102中示出，且消息封装包示例将在以下表151中描述。
【表151】
以下将顺次描述作为SOAP封装包元素的子元素的SOAP标头元素和SOAP体块元素。
SOAP标头元素为SOAP封装包元素的第一子元素，且包括扩展元素，诸如MessageHeader、SyncReply、Signature和ErrorList。
MessageHeader为基本元素，包括消息路由选择信息（至/自）以及与消息有关的其它上下文信息，SyncReply为将基本发送状态指示给下一个SOAP节点的元素，Signature为指示基于【XMLDSIG】的数字签名的元素，【XMLDSIG】标记与消息相关的数据，以及ErrorList为具有针对先前消息所报告的且只有报告先前消息错误时使用的错误列表的元素。下文将描述MessageHeader元素的细节。
MessageHeader元素为表达于所有ebXML消息中且表示SOAP标头元素的子元素的基本元素。MessageHeader元素为由以下子元素构成的复杂元素。MessageHeader的元素结构将在以下表152中描述，且MessageHeader的架构结构在图103中示出。
【表152】
SyncReply是指同步发送，且包括id属性、版本属性、SOAP actor属性（必须具有“http://schemas.xmlsoap.org/soap/actor/next”值）和SOAPmustUnderstand属性值。SyncReply元素示例将在以下表153中描述。
【表153】
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）、规范化和转换。为了在发送/接收消息时在创建和验证数字签名的过程中使歧义最小化，优选不使用不同于以下列表的算法。
数字签名NameSpace示例将在以下表154中描述。
【表154】
SHA1和SHA256可用作用于减少数据的算法，且示例将在以下表155中描述。在此情况下，自2012年“证书加密系统复杂性”完全适用时起限制使用SHA1。
【表155】
用于消息数字签名的算法为RSAwithSHA1和RSAwithSHA256，且示例将在以下表156中描述。在此情况下，自2012年“证书加密系统复杂性”完全适用时起限制RSAwithSHA1使用。
【表156】
由于物理上可不同地表示逻辑相同的文档的XML特性，数字签名值对于相同文档可能为不同。为了防止以上现象，需要进行规范化处理。在规范化中，使用注释省略的规范化XML。
【表157】
即使有各种转换算法作为经过对整个XML数据中待签名数据进行处理和选择的过程的算法，在各种转换算法中仅可使用三个算法。第一算法为封装包签名转换，这是因为数字签名遵守包括在签名目标中的形式，第二算法为上述规范化，以及第三算法为Xpath过滤，Xpath过滤选择签名目标信息。示例将在以下表158中描述。
【表158】
数字签名语法的结构在图104中示出，且如上所述数字签名消息的示例将在以下表159中描述。
【表159】
只有当在接收消息以处理消息的过程中发生错误时，ErrorList位于标头较低级别中。当产生ErrorList元素时，RefToMessageId必须存在于MessageHeader元素中，且RefToMessageId需要指定发生错误的消息MessageID。ErrorList元素具有诸如id属性、SOAP mustUnderstand属性、版本属性、highestSeverity属性的属性以及一个或者多个Error元素。ErrorList结构在图105中示出。在此情况下，如果没有错误报告，那么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元素的软件销售商或者开发者定义。
ErrorList示例将在以下表160中描述。
【表160】
如果在基于分发协议收发消息的过程中发生错误，那么通知错误的收发实体需要将错误报告给其它另一方。待报告错误包括消息结构错误、可靠通讯错误和安全性错误。
与属于比本发明中定义的分发协议更低层的数据通信协议（诸如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元素的XML ID，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）的功能。
格式管理单元提供允许格式管理器登记和管理格式的功能，并提供每个类别的登记功能以及每个版本的记录管理功能。此外，提供控制每个格式查看时段、查看次数和打印次数的设定功能。
标准连接模块提供与分发客户端应用程序连接的功能。此外，还提供格式列表搜索功能和文件下载功能。
根据本发明的电子文档格式寄存器的格式登记过程在图106中示出。
使用格式设计器，将标准电子文档创建为FormPDF，且基本要求将在以下表165中描述。
【表165】
在标准电子文档的结构中，要求距离文档下边缘大约5cm的距离。根据数据量可改变条形码大小，防复制标记大小为3>1.3且根据格式形状适当地设置。标准电子文档示例在图107中示出。
标准连接模块（标准接口）允许用户搜索和下载格式并在分发客户端应用程序中创建格式，且提供给包括在分发客户端应用程序中的Web US（用户接口）。标准连接模块提供搜索每个类别、格式列表以及文件下载的功能。
【电子文档封装】
下文中，将详细描述应用于如上所述根据本发明示例性实施方式的电子文档分发系统和方法的电子文档封装。
电子文档封装为允许收发实体在电子文档分发中分发文档所需的通讯系统标准。
电子文档封装由标准电子文档和附加文档构造，且由标准电子文档的元数据构造。基于PDF-A创建标准电子文档，且通过诸如文档安全性功能的信息来构造元数据。附加文档不被转换为PDF，而而实际上封装到原件中。
标准电子文档通过用户证书来数字签名，且在封装之后，电子文档封装包被数字签名以包括在封装包中。
图108示出了电子文档封装包结构。参考图108，根据本发明的电子文档封装包结构包括封装包标头、元数据、标准电子文档、附加文档和数字签名数据。其详细组成要素将在以下表27至表31中描述。
封装包标头包括整个封装包结构信息。元数据包括标准电子文档的文档安全性功能的信息，且还包括诸如文档读取次数、打印次数的信息以及二维条形码信息。标准电子文档以标准PDF-A型构造，且二维条形码数据包括在PDF文件中的图像区中，以及数字签名数据包括在标准PDF签名数据区中。附加文档不是标准电子文档，而是典型文档。因此，从应用文档安全性功能的目标排除附加文档。使用包括在封装中的用户证书，数字签名数据对封装数据进行数字签名。
【表166】
| 编号 | 组成要素 | 备注 |
| 1 | 整个文件大小 | |
| 2 | 元数据大小 | |
| 3 | 标准电子文档大小 | |
| 4 | 附加文件数 | |
| 5 | 附加文件大小 |
【表167】
| 编号 | 组成要素 | 备注 |
| 1 | 读取次数 | |
| 2 | 打印次数 |
| 3 | 存储功能 | |
| 4 | 文本提取功能 | |
| 5 | 临时存储/导入功能 | |
| 6 | 文档类型 | |
| 7 | 二维条形码大小(横向) |
【表168】
| 编号 | 组成要素 | 备注 |
| 1 | PDF文件 |
【表169】
| 编号 | 组成要素 | 备注 |
| 1 | 附加文件 |
【表170】
| 编号 | 组成要素 | 备注 |
| 1 | 数字签名数据 |
验证电子文档封装的方法包括（1）验证电子文档封装数字签名的方法、（2）验证标准电子文档的方法和（3）验证打印电子文档的方法，下文将描述所述方法。
（1）验证电子文档封装数字签名的方法
-当处理数字签名封装时，客户端应用程序验证数字签名。只有当验证成功时，客户端应用程序才将标准电子文档交付给电子文档查看器。
-此外，客户端应用程序支持手动数字签名验证功能，以当发生纠纷时验证数字签名。
（2）验证标准电子文档的方法
-当读取标准电子文档时，电子文档查看器验证数字签名。只有当数字签名验证成功时，在电子文档查看器中读取文件。
（3）验证打印电子文档的方法
-使用另外提供的验证程序和平板扫描仪，验证二维条形码中的数字签名数据，并通过肉眼比较原始文档内容和打印文档内容。
同时，因为需要根据最终接收电子文档的用户的打印机模式，产生防复制标记，所以防复制标记不包括在封装中。
【分发客户端应用程序】
下文中，将详细描述如上所述根据本发明示例性实施方式的电子文档分发系统的分发客户端应用程序。
为了允许企业或者个人基于认证电子邮件地址发送/接收文档（信息），需要提供支持发送/接收的用户接口（下文中简称为UI）的应用程序。作为发送/接收消息的通讯引擎，如果与电子邮件相比，分发通讯服务器系统充当邮件服务器，那么分发客户端应用程序（下文中简称为APP）充当类似于邮件客户端的用户应用程序，提供邮件客户端以允许用户与邮件服务器连接来发送/接收电子邮件。
图109示出了分发客户端APP的结构图。参考图109，作为在想要使用分发通讯服务器系统交换文档的一般用户的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连接的分发通讯服务器系统发送电子文档到其它“收发实体”的步骤在图110中示出，且处理程序如下。
首先，分发客户端APP创建待发送到接收方的消息。在此情况下，附加通过发送方预先创建的文档或者通过由分发客户端APP提供的文字处理器创建的文档并指定接收方，且然后创建消息。
接着，在输入接收方地址信息之后，调用分发通讯服务器系统的发送接口以请求发送消息。
接着，发送方的分发通讯服务器系统根据发送过程发送消息到接收方，且然后从接收方接收关于接收的响应消息（接收证书或者接收错误）。
接着，发送方的分发通讯服务器系统接收关于接收的响应消息，且然后将响应消息作为对发送的响应交付给分发客户端APP。
这里，第一步骤至第四步骤是基本的，且第二步骤至第四步骤同步执行。
接着，如果发送方的分发通讯服务器系统从接收方接收包括读取证书的消息，读取证书确认接收负责人读取，发送分发通讯服务器系统返回接收响应消息，且将接收消息存储于用户邮箱中。
接着，第一发送方的分发客户端APP向连接的分发通讯服务器系统请求接收文档。
接着，发送方的分发通讯服务器系统将存储于邮箱中的接收文档列表交付给请求接收文档的用户的分发客户端APP。
这里，第五步骤至第七步骤为只有当在发送第一消息时请求接收负责人读取确认时执行的选择性且可选程序。
（2）文档接收过程
分发客户端APP从其它“收发实体”接收电子文档的过程在图111中示出，且其处理程序将描述如下。
首先，如果接收到消息，那么接收方的分发通讯服务器系统返回接收消息的接收响应消息到接收方，并将接收消息存储于用户邮箱中。
接着，接收方的分发客户端APP登录所连接的分发通讯服务器系统以请求接收文档。
接着，接收方的分发通讯服务器系统交付存储于请求接收文档的用户邮箱中的接收文档列表。
这里，第二步骤和第三步骤为同步。
接着，如果接收方请求从接收消息列表读取消息的详细信息，那么分发客户端APP将包括对应消息的附加文档的详细信息发送到分发通讯服务器系统。
接着，如果最初发送方请求接收负责人读取确认，那么在用户请求接收文档的详细信息时，接收方的分发通讯服务器系统将包括读取证书的消息发送到对应消息的发送方。
接着，接收方的分发通讯服务器系统接收在第五步骤中发送的负责人读取确认消息（读取证书）的接收响应消息。
（3）电子文档格式下载过程
分发客户端APP下载电子文档格式的过程在图112中示出，且其处理程序将描述如下。
首先，分发客户端APP与电子文档格式登记服务器直接连接以请求搜索文档格式。在此情况下，基于由电子文档格式登记服务器提供的标准连接接口执行连接。
接着，电子文档格式登记服务器返回关于搜索文档的信息作为结果。
这里，第一步骤和第二步骤为同步。
接着，分发客户端APP将搜索格式列表展示给用户以选择格式。
接着，分发客户端APP请求电子文档格式登记服务器下载选定电子文档格式。
接着，电子文档格式登记服务器返回请求格式到分发客户端APP。
接着，分发客户端APP登记待插入的下载电子文档格式以用于文字处理器中。
由上述分发客户端APP的分发通讯服务器系统提供的接口类型包括用户认证（登录）、退出、消息发送请求、接收消息获得、详细消息信息请求和消息删除。
分发客户端APP和分发通讯服务器系统的连接方法（1）到（5）将描述如下。
（1）分发通讯服务器系统的连接协议
由分发客户端APP的分发通讯服务器系统提供的连接接口是基于与分发通讯服务器系统的收发协议相同的协议。在此情况下，分发客户端APP和分发通讯服务器系统提供单向同步通信，如图113所示，这不同于分发通讯服务器系统之间的发送/接收，且在它们之间使用消息数字签名认证或者用户认证方法。
发送消息实际上使用分发通讯服务器系统的消息结构，用户信息以及请求消息和响应消息由图114所示的结构构造。其详细描述如下。
-SOAP标头：根据基于如上所述【分发协议】配置的任务类型，分发客户端APP和分发通讯服务器系统可充当发送方或者接收方。SOAP标头包括消息标头和签名信息。
-SOAP正文：包括上述【分发协议】中定义的Manifest元素信息和用户登录信息。
-发送文档容器#1：在接收消息详细信息的情况下，包括消息发送请求、接收消息获得和正文文档（内容）。
-发送文档容器#2：在从#2依次接收消息详细信息的情况下，包括消息发送请求和附加文档。
SOAP标头结构将在以下表171中描述，消息标头结构将在以下表172中描述，SOAP正文结构将在以下表173中描述，以及正文消息结构将在以下表174中描述。
【表171】
【表172】
【表173】
【表174】
（2）消息发送请求
下文将描述在发送消息时由分发客户端APP交付给分发通讯服务器系统的基本信息。在完全发送之后存储于邮箱中的发送文档具有以下表175描述的四个状态信息步骤。
【表175】
请求消息示例将在以下表176中描述。
【表176】
响应消息示例将在以下表177中描述。
【表177】
（3）接收消息获取
分发客户端APP通过与分发通讯服务器系统连接的登录用户账户读取接收消息的动作与在分发通讯服务器系统中删除消息的动作分开。以下两个状态信息步骤根据消息接收过程来管理。
-接收用户是否读取邮箱中的接收文档列表
-接收用户是否读取接收文档的细节
请求消息示例将在以下表178中描述。
【表178】
响应消息示例将在以下表179中描述。
【表179】
（4）详细消息信息请求
如果用户想要基于接收文档列表读取细节，那么分发客户端APP请求分发通讯服务器系统的消息详细信息。接收详细信息请求的分发通讯服务器系统将诸如消息的详细属性信息和消息附加文档的所有消息内容交付给分发客户端APP作为响应消息。
请求消息示例将在以下表180中描述。
【表180】
响应消息示例将在以下表181中描述。
【表181】
（5）消息删除
如果用户请求删除，那么分发客户端APP将文档删除请求交付给分发通讯服务器系统，且将结果通知给用户。当用户删除文档时，是否给予作为垃圾箱概念的临时删除功能为分发客户端APP的附加功能，而不是实际服务器上的动作。因此，分发客户端APP的开发者可确定是否提供临时删除功能，但必须提供请求分发通讯服务器系统删除的功能。
请求消息示例将在以下表182中描述。
【表182】
响应消息示例将在以下表183中描述。
【表183】
【记录介质】
根据本发明的电子文档分发方法可在通用数字计算机中实施，通用数字计算机使用由在计算机中可执行的程序创建的计算机可读记录介质来操作程序。计算机可读记录介质包括磁性存储介质（例如，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】
Claims (20)
1.一种电子文档分发系统，包括：
收发实体，基于电子邮件地址发送和接收消息且通过分发通讯服务器分发电子文档，所述分发通讯服务器发行和管理消息发送/接收的分发证书；
分发中心，登记/管理所述收发实体的电子邮件地址、设定所述收发实体之间的电子文档分发路径、将电子文档的标准格式提供给所述收发实体，当在所述收发实体之间分发电子文档的过程中发生错误时，通过代理服务器发送所述消息，且发行分发证书；以及
可靠的第三方存储机构，接收和存储所述分发证书。
2.根据权利要求1所述的电子文档分发系统，其中，所述收发实体的分发通讯服务器将收发消息存储于邮箱中，以包括每个用户的状态信息，
将消息收发记录存储于介质中，所述介质不允许在预定时段内编辑和删除所述消息收发记录，
发行所述消息发送/接收的分发证书，以请求所述第三方存储机构存储所述分发证书，
允许所述收发实体与所述分发中心的地址目录服务器连接来使用登记、搜索、编辑和删除所述电子邮件地址的功能，以及
将存储达预定时段以上的消息移动到外部存储装置进行存储。
3.根据权利要求1所述的电子文档分发系统，其中，所述电子邮件地址包括：
用户识别标记，所述用户识别标记通过所述分发中心的地址目录服务器发行到所述收发实体；
附加识别标记，所述附加识别标记为所述收发实体根据需要自主分配的唯一值，且为所述收发实体的唯一值；以及
识别标记，设置于所述用户识别标记和所述附加识别标记之间。
4.根据权利要求3所述的电子文档分发系统，其中，电子文档分发的主要主体为接收唯一登记地址的用户。
5.根据权利要求3所述的电子文档分发系统，其中，所述识别标记为“#”。
6.根据权利要求1所述的电子文档分发系统，其中，所述分发中心包括电子文档格式寄存器，以及
所述电子文档格式寄存器执行包括对电子文档标准格式进行登记、删除以及信息编辑的管理，
此外，所述电子文档格式寄存器另外根据上下文对所述电子文档标准格式进行分类，且执行包括对使用电子文档标准格式的上下文进行登记和编辑的管理。
7.根据权利要求6所述的电子文档分发系统，其中，所述电子文档格式寄存器包括管理文档格式的服务器引擎以及允许使用所述收发实体搜索和下载所述文档格式的用户使用所述文档格式的标准接口，
所述收发实体还包括分发客户端应用程序，所述分发客户端应用程序为允许使用所述收发实体的用户通过所述分发通讯服务器发送/接收消息的用户接口，以及
使用所述分发客户端应用程序的用户通过所述电子文档格式寄存器的标准接口搜索和下载所述文档格式，且然后使用所述文档格式创建电子文档。
8.根据权利要求1所述的电子文档分发系统，其中，所述分发中心包括分发中继服务器，所述分发中继服务器用于当在所述收发实体之间分发电子文档过程期间发生错误时，通过代理服务器发送消息，且发行分发证书，
当所述收发实体请求所述分发中继服务器发送消息时，在通过所述代理服务器发送消息之后，所述分发中继服务器发行发送证书到请求消息发送的所述收发实体，如果所请求消息发送失败，那么发送错误消息到请求所述消息发送的所述收发实体。
9.根据权利要求1所述的电子文档分发系统，其中，所述分发中心包括与外部系统连接的外接网关服务器，以及
所述外接网关服务器包括分发通讯服务器，所述分发通讯服务器基于电子邮件地址发送/接收消息，所述外接网关服务器提供所述外接系统和所述电子文档分发系统之间的电子邮件地址验证/转换功能、所述外接系统和所述电子文档分发系统之间的消息验证/转换功能、施加于所述外接系统和所述电子文档分发系统之间的电子文档的安全性验证/转换功能以及所述外接系统和所述电子文档分发系统之间的电子文档的兼容性的验证和变换的功能。
10.根据权利要求1所述的电子文档分发系统，还包括：
第一接口，电子邮件地址登记机构使用所述第一接口来请求所述地址目录服务器登记所述电子邮件地址并接收响应；第二接口，所述电子邮件地址登记机构使用所述第二接口来请求对登记在所述地址目录服务器中的电子邮件地址进行变更并接收响应；以及第三接口，所述电子邮件地址登记机构使用所述第三接口请求删除登记在所述地址目录服务器中的电子邮件地址并接收响应，
其中，所述电子邮件地址登记机构通过所述第一接口发送包括电子邮件地址登记信息和电子邮件地址信息的请求消息，且然后接收所述地址目录服务器的登记结果作为响应消息，所述电子邮件地址登记机构通过所述第二接口发送包括电子邮件地址登记信息和待变更的电子邮件地址信息的请求消息，且然后接收所述地址目录服务器的变更结果作为响应消息，以及所述电子邮件地址登记机构通过所述第三接口发送包括电子邮件地址登记信息和待删除的电子邮件地址信息的请求消息，且然后接收所述地址目录服务器的删除结果作为响应消息。
11.根据权利要求10所述的电子文档分发系统，还包括：
第四接口，所述电子邮件地址登记机构或者所述收发实体使用所述第四接口来向所述地址目录服务器请求与所述电子文档的接收方的认证电子邮件地址信息对应的物理地址信息以及消息安全处理的证书信息，并接收响应，
在发送包括所述电子文档的接收方的认证电子邮件地址的请求消息之后，且不论是否请求证书，所述电子邮件地址登记机构或者所述收发实体的分发通讯服务器从所述地址目录服务器接收所述电子文档的接收方的物理地址信息以及证书信息作为响应消息。
12.根据权利要求1所述的电子文档分发系统，其中，所述收发实体的分发通讯服务器和所述电子邮件地址登记机构的分发通讯服务器包括第五接口，所述第五接口用于发送消息、交付所述分发证书、请求存储所述分发证书以及交付所述第三方存储机构的存储结果。
13.根据权利要求1所述的电子文档分发系统，其中，所述收发实体中的用户包括作为用户接口的分发客户端应用程序，
所述收发实体的分发通讯服务器包括第六接口，所述第六接口与请求电子文档分发的用户的分发客户端应用程序连接来向用户提供文档收发功能，以及
所述第六接口将请求发送消息、请求所述消息的列表、请求所述消息的细节、报告垃圾消息和搜索物理地址信息的功能提供给所述分发客户端用户。
14.一种在电子文档分发系统中分发电子文档的方法，所述电子文档分发系统包括收发实体和分发中心，所述方法包括以下步骤：
（a）步骤：允许发送实体获得与接收实体的地址信息对应的物理地址信息且然后将带有附加电子文档的消息发送到所述物理地址；
（b）步骤：允许接收消息的接收实体根据接收消息与所述发送实体的兼容性验证结果来发行接收证书或者错误证书，且将所述证书交付到所述收发实体；以及
（c）步骤：允许向所述接收实体发送消息但发送失败的发送实体请求所述分发中心通过代理服务器发送消息，且允许接收请求通过所述代理服务器发送消息的分发中心发行发送证书，以将所述证书交付到所述发送实体，且将所述消息发送到所述接收实体，且然后执行步骤（b）。
15.根据权利要求14所述的方法，其中，步骤（a）包括：
（a1）步骤：允许发送实体基于接收实体的地址信息，向地址目录服务器查询物理地址信息和安全性信息；
（a2）步骤：允许地址目录服务器接收/验证所述发送实体的查询，且然后在电子邮件地址包括在白名单的情况下，将与电子邮件地址对应的物理地址信息提供给所述发送实体；以及
（a3）步骤：允许所述发送实体基于从所述地址目录服务器接收的物理地址设定路径，以将带有附加电子文档的消息发送到所述接收实体。
16.根据权利要求14所述的方法，其中，在所述步骤（b）之后，接收所述接收证书的所述收发实体验证所述接收证书有效性，并将验证信息附加到所述接收证书，且然后将所述接收证书存储于其中并请求第三方存储机构存储所述接收证书。
17.根据权利要求14所述的方法，其中，所述步骤（c）包括：
（c1）步骤：允许向所述接收实体发送消息但发送失败的所述收发实体请求所述分发中心通过代理服务器发送消息；
（c2）步骤：允许所述分发中心启动消息发送，且在发送失败时，以预定间隔重试发送，如果消息发送最终失败，那么将发送失败消息发送到所述发送实体；
（c3）步骤：允许正常接收消息的接收实体发行所述接收证书且将所述接收证书发送到所述分发中心；以及
（c4）步骤：允许所述接收实体发行读取证书，以在电子文档的接收方读取电子文档的情况下，那么直接将所述读取证书发送给所述发送实体，而无需使用所述分发中心。
18.一种在电子文档分发系统中分发电子文档的方法，所述电子文档分发系统包括用作发送方或者接收方的收发实体以及电子文档分发中心，所述方法包括以下步骤：
（a）步骤：允许所述发送方获得所述接收方的电子邮件地址信息；
（b）步骤：允许所述发送方创建通过利用预定消息结构封装待发送文档所获得的消息，且然后将所述文档发送到所述接收方的电子邮件地址；
（c）步骤：如果步骤（b）的发送失败，那么允许所述发送方请求所述电子文档分发中心发送消息且允许所述电子文档分发中心发行所述发送证书并将所述发送证书交付到所述发送方，且然后通过代理服务器发送消息；
（d）步骤：允许所述接收方验证从所述发送方或者所述电子文档分发中心接收到的消息，且如果通过验证，那么从接收消息提取文档且发行所述接收证书以交付到所述发送方；
（e）步骤：允许所述发送方利用可靠的第三方存储机构来存储所交付的接收证书；以及
（f）步骤：允许所述接收方将所提取的文档交付到文档负责人。
19.根据权利要求18所述的方法，还包括：在步骤（a）之前，
（g）步骤：允许所述发送方和所述接收方确定是否建立用于文档分发的分发通讯服务器或者使用包括能够执行第三方分发的分发通讯服务器的收发实体；
（h）步骤：如果在步骤（g）中确定为建立用于文档分发的分发通讯服务器，那么允许所述发送方和所述接收方建立用于文档分发的分发通讯服务器，且然后通过认证机构执行分发通讯服务器的认证测试，且在作为收发实体接收电子邮件地址之后，通过访问电子文档分发服务器的地址目录服务器来登记和管理内部实际用户的内部标识符；
（i）步骤：如果在步骤（g）中确定为使用包括能够执行第三方分发的分发通讯服务器的收发实体，那么允许所述发送方和所述接收方请求通过能够执行第三方分发的分发通讯服务器打开电子邮件地址，且然后将电子邮件地址信息登记在所述电子文档分发中心的地址目录服务器中；以及
（j）步骤：在步骤（h）和步骤（i）之后，允许所述发送方从所述电子文档分发中心的电子文档格式寄存器中搜索、下载和登记文档格式；
在步骤（b）之前，还包括（k）步骤：使用在步骤（j）中登记的文档格式选择待发送文档或者创建待发送文档。
20.一种计算机可读记录介质，所述计算机可读记录介质中存储有用于执行根据权利要求14至19中任一项所述的方法的程序。
Applications Claiming Priority (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR10-2010-0065985 | 2010-07-08 | ||
| KR20100065985 | 2010-07-08 | ||
| KR10-2010-0131935 | 2010-12-21 | ||
| KR20100131936A KR20120005364A (ko) | 2010-07-08 | 2010-12-21 | 전자 주소, 및 전자문서 유통 시스템 |
| KR20100131935A KR20120005363A (ko) | 2010-07-08 | 2010-12-21 | 전자문서 유통 시스템 및 전자문서 유통 방법 |
| KR10-2010-0131936 | 2010-12-21 | ||
| KR1020110067185A KR101266086B1 (ko) | 2010-07-08 | 2011-07-07 | 전자문서 유통 시스템 |
| KR10-2011-0067185 | 2011-07-07 | ||
| PCT/KR2011/005027 WO2012005546A2 (ko) | 2010-07-08 | 2011-07-08 | 전자문서 유통 시스템 및 전자문서 유통 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103124981A true CN103124981A (zh) | 2013-05-29 |
| CN103124981B CN103124981B (zh) | 2016-12-07 |
Family
ID=45611562
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201180035945.1A Expired - Fee Related CN103080958B (zh) | 2010-07-08 | 2011-07-08 | 用于在分发电子文档的系统中产生/发行分发证书的方法 |
| CN201180043451.8A Expired - Fee Related CN103124981B (zh) | 2010-07-08 | 2011-07-08 | 电子文档流通系统和电子文档流通方法 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201180035945.1A Expired - Fee Related CN103080958B (zh) | 2010-07-08 | 2011-07-08 | 用于在分发电子文档的系统中产生/发行分发证书的方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (2) | US20130110919A1 (zh) |
| EP (2) | EP2602758B1 (zh) |
| JP (3) | JP2013535858A (zh) |
| KR (4) | KR20120005363A (zh) |
| CN (2) | CN103080958B (zh) |
| SG (3) | SG10201505317XA (zh) |
| WO (2) | WO2012005555A2 (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106685979A (zh) * | 2017-01-09 | 2017-05-17 | 北京信息科技大学 | 基于STiP模型的安全终端标识及认证方法及系统 |
| CN108804238A (zh) * | 2018-03-29 | 2018-11-13 | 中国工程物理研究院计算机应用研究所 | 一种基于远程过程调用的软总线通信方法 |
| CN108989055A (zh) * | 2018-08-31 | 2018-12-11 | 密信技术(深圳)有限公司 | 兼容不同类型文件的签名和加密方法、装置及存储介质 |
| CN109150516A (zh) * | 2018-08-31 | 2019-01-04 | 密信技术(深圳)有限公司 | 浏览器文件的签名及/或加密方法、装置、浏览器及介质 |
| CN110401555A (zh) * | 2018-04-25 | 2019-11-01 | Sap欧洲公司 | 用于生成适用性声明4适配器的可插入框架 |
| CN111651196A (zh) * | 2020-06-24 | 2020-09-11 | 腾讯科技（深圳）有限公司 | 文档发布方法、装置及服务器 |
| CN113126936A (zh) * | 2021-04-23 | 2021-07-16 | 深圳市爱商在线科技有限公司 | 一种适配多种文档类型的打印控件 |
| US20220021522A1 (en) * | 2020-07-20 | 2022-01-20 | Fujitsu Limited | Storage medium, relay device, and communication method |
| CN114626099A (zh) * | 2020-12-10 | 2022-06-14 | 富士通株式会社 | 计算机可读记录介质以及信息处理方法、设备和系统 |
Families Citing this family (77)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8826375B2 (en) * | 2008-04-14 | 2014-09-02 | Lookwithus.Com Inc. | Rich media collaboration system |
| US8083129B1 (en) * | 2008-08-19 | 2011-12-27 | United Services Automobile Association (Usaa) | Systems and methods for electronic document delivery, execution, and return |
| KR20120005363A (ko) * | 2010-07-08 | 2012-01-16 | 정보통신산업진흥원 | 전자문서 유통 시스템 및 전자문서 유통 방법 |
| SG193014A1 (en) * | 2011-09-30 | 2013-09-30 | Ranganath C Abeyweera | Method, system and apparatus for a communications client program and anassociated transfer server for onymous and secure communications |
| CN103067338B (zh) * | 2011-10-20 | 2017-04-19 | 上海贝尔股份有限公司 | 第三方应用的集中式安全管理方法和系统及相应通信系统 |
| CA2796540A1 (en) * | 2011-11-28 | 2013-05-28 | Pika Technologies Inc. | Transparent bridge device |
| US9367560B1 (en) * | 2011-12-14 | 2016-06-14 | Unboundid, Corp. | Method, system and apparatus for synchronizing changes in a directory service |
| EP2632097A1 (en) * | 2012-02-21 | 2013-08-28 | Lleidanetworks Serveis Telemàtics S.A. | Method for certifying delivery of SMS/MMS data messages to mobile terminals |
| US20130301830A1 (en) | 2012-05-08 | 2013-11-14 | Hagai Bar-El | Device, system, and method of secure entry and handling of passwords |
| US9736121B2 (en) * | 2012-07-16 | 2017-08-15 | Owl Cyber Defense Solutions, Llc | File manifest filter for unidirectional transfer of files |
| KR101223674B1 (ko) * | 2012-09-06 | 2013-01-22 | 토피도 주식회사 | 샵 메일 전송 기능을 갖는 이 메일 클라이언트 데몬 시스템 및 이를 이용한 샵 메일 전송 방법 |
| US20140082095A1 (en) * | 2012-09-17 | 2014-03-20 | Helen Y. Balinsky | Workflow monitoring |
| KR20140048415A (ko) * | 2012-10-12 | 2014-04-24 | 삼성전자주식회사 | 단말기의 전자편지지 다운로드서비스 제공 장치 및 방법 |
| US9357382B2 (en) * | 2012-10-31 | 2016-05-31 | Intellisist, Inc. | Computer-implemented system and method for validating call connections |
| KR102065390B1 (ko) | 2013-02-15 | 2020-01-13 | 엘지이노텍 주식회사 | 발광소자, 발광소자 패키지 및 라이트 유닛 |
| US8739243B1 (en) | 2013-04-18 | 2014-05-27 | Phantom Technologies, Inc. | Selectively performing man in the middle decryption |
| US10776384B1 (en) | 2013-04-30 | 2020-09-15 | Ping Identity Corporation | Method, server and system for criteria-based assured replication |
| US9021575B2 (en) | 2013-05-08 | 2015-04-28 | Iboss, Inc. | Selectively performing man in the middle decryption |
| US9160718B2 (en) | 2013-05-23 | 2015-10-13 | Iboss, Inc. | Selectively performing man in the middle decryption |
| US20140379584A1 (en) * | 2013-06-25 | 2014-12-25 | FraudFree Finance, LLC | Anti-fraud financial transaction method |
| US9009461B2 (en) | 2013-08-14 | 2015-04-14 | Iboss, Inc. | Selectively performing man in the middle decryption |
| KR101332607B1 (ko) * | 2013-09-02 | 2013-11-25 | 서호진 | 공인전자주소 기반 전자문서유통체계에서 샵 메일의 전달 및 전달된 샵 메일의 유효성 검사 시스템 및 방법 |
| US9710808B2 (en) * | 2013-09-16 | 2017-07-18 | Igor V. SLEPININ | Direct digital cash system and method |
| US20150135338A1 (en) | 2013-11-13 | 2015-05-14 | Fenwal, Inc. | Digital certificate with software enabling indicator |
| KR101425513B1 (ko) * | 2014-02-12 | 2014-08-05 | 주식회사 티모넷 | ＨＳＭ（Ｈａｒｄｗａｒｅ Ｓｅｃｕｒｉｔ Ｍｏｄｕｌｅ）과 인증 ＡＰＰＬＥＴ을 이용한 디바이스 인증 시스템 |
| US9130996B1 (en) | 2014-03-26 | 2015-09-08 | Iboss, Inc. | Network notifications |
| CN103997453B (zh) * | 2014-05-13 | 2018-03-30 | 北京奇虎科技有限公司 | 一种与应用相关的信息处理的方法和装置 |
| US9673998B2 (en) * | 2014-05-15 | 2017-06-06 | Futurewei Technologies, Inc. | Differential cache for representational state transfer (REST) API |
| US9906367B2 (en) * | 2014-08-05 | 2018-02-27 | Sap Se | End-to-end tamper protection in presence of cloud integration |
| CN105337950B (zh) | 2014-08-14 | 2019-02-19 | 阿里巴巴集团控股有限公司 | 一种表单填充方法及相关终端 |
| KR102295570B1 (ko) * | 2014-11-07 | 2021-08-30 | 주식회사 엘지유플러스 | 클라우드 프린팅 환경에서의 워터마크를 이용한 출력물 관리 방법 |
| KR102256642B1 (ko) * | 2014-12-04 | 2021-05-27 | 삼성전자주식회사 | 메시지 송수신 장치 및 메시지 송수신 방법 |
| US20160162991A1 (en) * | 2014-12-04 | 2016-06-09 | Hartford Fire Insurance Company | System for accessing and certifying data in a client server environment |
| US10079833B2 (en) * | 2015-03-30 | 2018-09-18 | Konica Minolta Laboratory U.S.A., Inc. | Digital rights management system with confirmation notification to document publisher during document protection and distribution |
| KR101709197B1 (ko) * | 2015-05-21 | 2017-02-22 | (주)데이터코리아 | 어플리케이션을 기반으로 채권잔액확인서를 송수신하는 방법 및 어플리케이션 |
| US10175977B2 (en) * | 2015-11-04 | 2019-01-08 | International Business Machines Corporation | User profile based code review |
| US10839378B1 (en) * | 2016-01-12 | 2020-11-17 | 21, Inc. | Systems and methods for performing device authentication operations using cryptocurrency transactions |
| US11212363B2 (en) | 2016-02-08 | 2021-12-28 | Microstrategy Incorporated | Dossier interface and distribution |
| US10791109B2 (en) * | 2016-02-10 | 2020-09-29 | Red Hat, Inc. | Certificate based expiration of file system objects |
| US10068074B2 (en) | 2016-03-25 | 2018-09-04 | Credly, Inc. | Generation, management, and tracking of digital credentials |
| US9680801B1 (en) | 2016-05-03 | 2017-06-13 | Iboss, Inc. | Selectively altering references within encrypted pages using man in the middle |
| US10291604B2 (en) * | 2016-06-03 | 2019-05-14 | Docusign, Inc. | Universal access to document transaction platform |
| US20180006823A1 (en) * | 2016-07-01 | 2018-01-04 | Qualcomm Incorporated | Multi-hop secure content routing based on cryptographic partial blind signatures and embedded terms |
| USRE49964E1 (en) * | 2016-10-04 | 2024-05-07 | Samsung Electronics Co., Ltd | Method and apparatus for transmitting a mission critical data message in a communication system |
| CN106789585A (zh) * | 2016-12-27 | 2017-05-31 | 沃通电子认证服务有限公司 | 可验证电子邮件发送时间的方法及装置 |
| JP6536609B2 (ja) * | 2017-03-17 | 2019-07-03 | 富士ゼロックス株式会社 | 管理装置及びドキュメント管理システム |
| US11126665B1 (en) | 2017-04-18 | 2021-09-21 | Microstrategy Incorporated | Maintaining dashboard state |
| KR101976665B1 (ko) * | 2017-04-25 | 2019-08-28 | 주식회사 포시에스 | 영상 출력 장치들을 활용한 전자문서 정보 처리 장치 및 그의 정보 처리 방법 |
| CN110419040A (zh) * | 2017-04-27 | 2019-11-05 | 惠普发展公司，有限责任合伙企业 | 用于履行服务操作的控制器 |
| US11544669B2 (en) * | 2017-06-26 | 2023-01-03 | Oracle Financial Services Software Limited | Computing framework for compliance report generation |
| CN107241341B (zh) * | 2017-06-29 | 2020-07-07 | 北京五八信息技术有限公司 | 访问控制方法及装置 |
| US11487868B2 (en) * | 2017-08-01 | 2022-11-01 | Pc Matic, Inc. | System, method, and apparatus for computer security |
| US20190089692A1 (en) | 2017-09-15 | 2019-03-21 | Pearson Education, Inc. | Time-based degradation of digital credentials in a digital credential platform |
| KR101951270B1 (ko) * | 2017-09-28 | 2019-02-22 | 주식회사 스마트솔루션 | 메신저 인증 서버를 이용한 문서 발송 시스템 및 그 방법 |
| US10803104B2 (en) | 2017-11-01 | 2020-10-13 | Pearson Education, Inc. | Digital credential field mapping |
| US10607291B2 (en) | 2017-12-08 | 2020-03-31 | Nasdaq Technology Ab | Systems and methods for electronic continuous trading of variant inventories |
| US10810350B2 (en) | 2018-01-05 | 2020-10-20 | Jpmorgan Chase Bank, N.A. | System and method for aggregating legal orders |
| CN108540528B (zh) * | 2018-03-07 | 2021-12-17 | 胡金钱 | 确认电子文书送达的方法及系统、计算机存储介质 |
| CN110324287B (zh) * | 2018-03-31 | 2020-10-23 | 华为技术有限公司 | 接入认证方法、装置及服务器 |
| RU2702505C1 (ru) * | 2018-08-07 | 2019-10-08 | Акционерное общество Инжиниринговая компания "АСЭ" (АО ИК "АСЭ") | Система управления электронным документооборотом |
| KR102158299B1 (ko) * | 2019-01-23 | 2020-09-21 | 소프트캠프 주식회사 | 영업비밀에 관한 네트워크 기반의 문서 보호시스템 |
| US10645197B1 (en) * | 2019-04-19 | 2020-05-05 | Clario Tech Limited | Method and a system for a secure link-up to a non-secure synchronous connection and a machine-readable carrier configured for performing the method |
| JP2021060915A (ja) * | 2019-10-09 | 2021-04-15 | 富士通株式会社 | 本人確認プログラム、制御装置及び本人確認方法 |
| JP7367443B2 (ja) * | 2019-10-09 | 2023-10-24 | 富士通株式会社 | 本人確認プログラム、管理装置及び本人確認方法 |
| CN113591439B (zh) * | 2020-04-30 | 2023-07-11 | 抖音视界有限公司 | 一种信息交互方法、装置、电子设备及存储介质 |
| JP2023522672A (ja) | 2020-04-30 | 2023-05-31 | 北京字節跳動網絡技術有限公司 | 情報インタラクション方法、装置、電子機器、および記憶媒体 |
| FR3110801A1 (fr) * | 2020-05-25 | 2021-11-26 | Orange | Procédé de délégation de la livraison de contenus à un serveur cache |
| KR102337673B1 (ko) | 2020-07-16 | 2021-12-09 | (주)휴먼스케이프 | 데이터 열람 검증 시스템 및 그 방법 |
| KR102337677B1 (ko) | 2020-07-16 | 2021-12-09 | (주)휴먼스케이프 | 디지털 검증 지문 삽입 시스템 및 그 방법 |
| TWI759908B (zh) * | 2020-10-15 | 2022-04-01 | 威聯通科技股份有限公司 | 產生授權允許名單的方法與利用其之資安系統 |
| KR102261527B1 (ko) | 2021-01-14 | 2021-06-08 | 성균관대학교산학협력단 | 인휠 모터를 장착한 차량의 토크 벡터링 제어 장치 및 방법 |
| US11556696B2 (en) * | 2021-03-15 | 2023-01-17 | Avaya Management L.P. | Systems and methods for processing and displaying messages in digital communications |
| KR102470713B1 (ko) * | 2021-04-29 | 2022-11-25 | (주)소프트제국 | 블록체인 did 기반 증명서 유통 서비스 제공 방법 및 장치 |
| JP2023018431A (ja) | 2021-07-27 | 2023-02-08 | 富士通株式会社 | 情報処理プログラム、情報処理装置、および情報処理方法 |
| KR102599089B1 (ko) * | 2021-10-06 | 2023-11-03 | 효성티앤에스 주식회사 | 전자문서 생성 방법 및 장치, 컴퓨터 판독 가능한 기록 매체 및 컴퓨터 프로그램 |
| KR102498461B1 (ko) * | 2022-04-25 | 2023-02-13 | 주식회사 디엠테크컨설팅 | 싱글사인온 제조정보 통합관리 시스템를 이용한 통합관리 방법 |
| KR102479174B1 (ko) * | 2022-07-05 | 2022-12-20 | (주)링크허브 | 보안 전자 서명 관리 시스템 및 그 방법 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6775771B1 (en) * | 1999-12-14 | 2004-08-10 | International Business Machines Corporation | Method and system for presentation and manipulation of PKCS authenticated-data objects |
| CN1926493A (zh) * | 2004-04-08 | 2007-03-07 | 国际商业机器公司 | 用于将证书链接到签名文件的方法和系统 |
| CN101326517A (zh) * | 2006-08-10 | 2008-12-17 | 韩国电子去来振兴阮 | 确保电子文档的真实性并发行证书的电子文档库系统和在该系统中执行的登记、读取、发行、传送、证书发行的方法 |
| KR20090027555A (ko) * | 2007-09-12 | 2009-03-17 | 한국전자거래진흥원 | 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을구현하는 프로그램이 저장된 기록매체 |
| KR20090027554A (ko) * | 2007-09-12 | 2009-03-17 | 한국전자거래진흥원 | 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체 |
Family Cites Families (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2887806B2 (ja) * | 1989-08-18 | 1999-05-10 | 富士ゼロックス株式会社 | ネットワークシステム及びメールゲートウエイ |
| JPH0535562A (ja) * | 1991-07-31 | 1993-02-12 | Toshiba Corp | 情報処理システムの文書管理装置 |
| GB2287619A (en) * | 1994-03-03 | 1995-09-20 | Ibm | Security device for data communications networks |
| JPH07297822A (ja) * | 1994-04-21 | 1995-11-10 | Hitachi Ltd | メッセージ伝送システム |
| JPH08307448A (ja) * | 1995-04-28 | 1996-11-22 | Nippon Telegr & Teleph Corp <Ntt> | 電子メールにおける受信通知方法およびその方法を適用した電子メール通信システム |
| JP3453459B2 (ja) | 1995-06-19 | 2003-10-06 | キヤノン株式会社 | 電子メールシステム及びその制御方法、並びに通信端末装置及びその制御方法 |
| US6327656B2 (en) * | 1996-07-03 | 2001-12-04 | Timestamp.Com, Inc. | Apparatus and method for electronic document certification and verification |
| US6584565B1 (en) * | 1997-07-15 | 2003-06-24 | Hewlett-Packard Development Company, L.P. | Method and apparatus for long term verification of digital signatures |
| CN1319218A (zh) * | 1998-09-21 | 2001-10-24 | 国际商业机器公司 | 提高电子交易安全性的方法 |
| JP2000183951A (ja) | 1998-12-18 | 2000-06-30 | Pfu Ltd | 暗号化システムおよび記録媒体 |
| AU6610300A (en) * | 1999-07-28 | 2001-02-19 | Terrance A. Tomkow | System and method for verifying delivery and integrity of electronic messages |
| US7966372B1 (en) * | 1999-07-28 | 2011-06-21 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
| IL138408A0 (en) * | 2000-04-07 | 2001-10-31 | Digitalsecu Co Ltd | Apparatus for and method of storing log data in communication network |
| JP2002082880A (ja) * | 2000-06-28 | 2002-03-22 | Oregadare Inc | メッセージの送受信管理方法及びメッセージの送受信管理システム |
| US20020059525A1 (en) * | 2000-11-10 | 2002-05-16 | Estes Timothy A. | Authenticating the contents of e-documents |
| US20090144382A1 (en) * | 2001-01-09 | 2009-06-04 | Benninghoff Iii Charles F | Method for certifying and unifying delivery of electronic packages |
| US8179555B2 (en) | 2002-03-08 | 2012-05-15 | Hewlett-Packard Development Company, L.P. | Printing and finishing capability for customized document production system and method |
| US7707624B2 (en) * | 2002-11-26 | 2010-04-27 | Rpost International Limited | System for, and method of, proving the transmission, receipt and content of a reply to an electronic message |
| JP4001047B2 (ja) * | 2003-04-23 | 2007-10-31 | 村田機械株式会社 | 中継装置 |
| JP2005108063A (ja) * | 2003-10-01 | 2005-04-21 | Hitachi Ltd | 暗号化データ変換装置を利用した電子自治体共用サーバ及び暗号化データ復号化装置を利用した電子自治体用端末 |
| KR100579147B1 (ko) | 2004-01-29 | 2006-05-12 | (주)드림투리얼리티 | 전자문서파일의 위변조 검증 전자문서관리시스템 및 그를이용한 방법 |
| EP1631023B1 (en) * | 2004-08-31 | 2006-10-11 | Opportunity Solutions A/S | System for handling electronic mail in a multiple user environment |
| KR100653512B1 (ko) | 2005-09-03 | 2006-12-05 | 삼성에스디에스 주식회사 | 전자문서 관리 및 보관 시스템, 이 시스템에서 수행되는전자문서의 등록방법 및 이용방법 |
| JP2007179145A (ja) * | 2005-12-27 | 2007-07-12 | Brother Ind Ltd | アドレス情報検索システム、およびアドレス情報検索プログラム |
| WO2008078366A1 (ja) * | 2006-12-22 | 2008-07-03 | Fujitsu Limited | データ検証装置、データ検証方法およびデータ検証プログラム |
| US20080168536A1 (en) * | 2007-01-10 | 2008-07-10 | Rueckwald Mark C | System and methods for reduction of unwanted electronic correspondence |
| CN101017544B (zh) * | 2007-02-15 | 2010-12-01 | 江苏国盾科技实业有限责任公司 | 含电子印章数字证书的合体印章签署认证方法 |
| WO2008120334A1 (ja) * | 2007-03-28 | 2008-10-09 | Fujitsu Limited | 証明書検証方法及び証明書検証装置 |
| KR100932266B1 (ko) * | 2007-10-12 | 2009-12-16 | 주식회사 하나은행 | 전자문서중계 서비스 제공 방법 |
| US8739292B2 (en) * | 2008-03-04 | 2014-05-27 | Apple Inc. | Trust exception management |
| US8732452B2 (en) | 2008-06-23 | 2014-05-20 | Microsoft Corporation | Secure message delivery using a trust broker |
| JP2010093354A (ja) * | 2008-10-03 | 2010-04-22 | Sanyo Electric Co Ltd | 通信装置 |
| US8255685B2 (en) * | 2009-03-17 | 2012-08-28 | Research In Motion Limited | System and method for validating certificate issuance notification messages |
| JP5105291B2 (ja) * | 2009-11-13 | 2012-12-26 | セイコーインスツル株式会社 | 長期署名用サーバ、長期署名用端末、長期署名用端末プログラム |
| KR20120005363A (ko) * | 2010-07-08 | 2012-01-16 | 정보통신산업진흥원 | 전자문서 유통 시스템 및 전자문서 유통 방법 |
-
2010
- 2010-12-21 KR KR20100131935A patent/KR20120005363A/ko active Search and Examination
- 2010-12-21 KR KR20100131936A patent/KR20120005364A/ko active Search and Examination
-
2011
- 2011-07-07 KR KR20110067188A patent/KR101364612B1/ko active IP Right Grant
- 2011-07-07 KR KR1020110067185A patent/KR101266086B1/ko active IP Right Grant
- 2011-07-08 EP EP11803832.2A patent/EP2602758B1/en not_active Not-in-force
- 2011-07-08 SG SG10201505317XA patent/SG10201505317XA/en unknown
- 2011-07-08 WO PCT/KR2011/005039 patent/WO2012005555A2/ko active Application Filing
- 2011-07-08 US US13/808,573 patent/US20130110919A1/en not_active Abandoned
- 2011-07-08 JP JP2013518281A patent/JP2013535858A/ja active Pending
- 2011-07-08 JP JP2013518282A patent/JP2013535859A/ja active Pending
- 2011-07-08 WO PCT/KR2011/005027 patent/WO2012005546A2/ko active Application Filing
- 2011-07-08 US US13/808,576 patent/US9143358B2/en not_active Expired - Fee Related
- 2011-07-08 EP EP11803841.3A patent/EP2592594B1/en not_active Not-in-force
- 2011-07-08 SG SG2013001870A patent/SG187006A1/en unknown
- 2011-07-08 SG SG2013001862A patent/SG187005A1/en unknown
- 2011-07-08 CN CN201180035945.1A patent/CN103080958B/zh not_active Expired - Fee Related
- 2011-07-08 CN CN201180043451.8A patent/CN103124981B/zh not_active Expired - Fee Related
-
2016
- 2016-07-08 JP JP2016135934A patent/JP2016195440A/ja active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6775771B1 (en) * | 1999-12-14 | 2004-08-10 | International Business Machines Corporation | Method and system for presentation and manipulation of PKCS authenticated-data objects |
| CN1926493A (zh) * | 2004-04-08 | 2007-03-07 | 国际商业机器公司 | 用于将证书链接到签名文件的方法和系统 |
| CN101326517A (zh) * | 2006-08-10 | 2008-12-17 | 韩国电子去来振兴阮 | 确保电子文档的真实性并发行证书的电子文档库系统和在该系统中执行的登记、读取、发行、传送、证书发行的方法 |
| KR20090027555A (ko) * | 2007-09-12 | 2009-03-17 | 한국전자거래진흥원 | 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을구현하는 프로그램이 저장된 기록매체 |
| KR20090027554A (ko) * | 2007-09-12 | 2009-03-17 | 한국전자거래진흥원 | 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체 |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106685979A (zh) * | 2017-01-09 | 2017-05-17 | 北京信息科技大学 | 基于STiP模型的安全终端标识及认证方法及系统 |
| CN108804238A (zh) * | 2018-03-29 | 2018-11-13 | 中国工程物理研究院计算机应用研究所 | 一种基于远程过程调用的软总线通信方法 |
| CN108804238B (zh) * | 2018-03-29 | 2022-03-04 | 中国工程物理研究院计算机应用研究所 | 一种基于远程过程调用的软总线通信方法 |
| CN110401555A (zh) * | 2018-04-25 | 2019-11-01 | Sap欧洲公司 | 用于生成适用性声明4适配器的可插入框架 |
| CN108989055A (zh) * | 2018-08-31 | 2018-12-11 | 密信技术(深圳)有限公司 | 兼容不同类型文件的签名和加密方法、装置及存储介质 |
| CN109150516A (zh) * | 2018-08-31 | 2019-01-04 | 密信技术(深圳)有限公司 | 浏览器文件的签名及/或加密方法、装置、浏览器及介质 |
| CN111651196A (zh) * | 2020-06-24 | 2020-09-11 | 腾讯科技（深圳）有限公司 | 文档发布方法、装置及服务器 |
| US20220021522A1 (en) * | 2020-07-20 | 2022-01-20 | Fujitsu Limited | Storage medium, relay device, and communication method |
| CN114626099A (zh) * | 2020-12-10 | 2022-06-14 | 富士通株式会社 | 计算机可读记录介质以及信息处理方法、设备和系统 |
| CN114626099B (zh) * | 2020-12-10 | 2024-09-17 | 富士通株式会社 | 计算机可读记录介质以及信息处理方法、设备和系统 |
| CN113126936A (zh) * | 2021-04-23 | 2021-07-16 | 深圳市爱商在线科技有限公司 | 一种适配多种文档类型的打印控件 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2592594A2 (en) | 2013-05-15 |
| KR20120005393A (ko) | 2012-01-16 |
| KR101364612B1 (ko) | 2014-02-20 |
| WO2012005555A2 (ko) | 2012-01-12 |
| WO2012005555A3 (ko) | 2012-05-31 |
| EP2602758B1 (en) | 2016-08-24 |
| JP2013535859A (ja) | 2013-09-12 |
| EP2592594B1 (en) | 2016-08-17 |
| JP2013535858A (ja) | 2013-09-12 |
| KR20120005363A (ko) | 2012-01-16 |
| US20130110919A1 (en) | 2013-05-02 |
| US20130117400A1 (en) | 2013-05-09 |
| EP2592594A4 (en) | 2014-05-14 |
| EP2602758A4 (en) | 2014-01-22 |
| CN103080958A (zh) | 2013-05-01 |
| CN103080958B (zh) | 2016-12-07 |
| KR20120005364A (ko) | 2012-01-16 |
| WO2012005546A2 (ko) | 2012-01-12 |
| JP2016195440A (ja) | 2016-11-17 |
| EP2602758A2 (en) | 2013-06-12 |
| SG187006A1 (en) | 2013-02-28 |
| CN103124981B (zh) | 2016-12-07 |
| SG10201505317XA (en) | 2015-08-28 |
| KR101266086B1 (ko) | 2013-05-27 |
| KR20120005392A (ko) | 2012-01-16 |
| US9143358B2 (en) | 2015-09-22 |
| WO2012005546A3 (ko) | 2012-05-31 |
| SG187005A1 (en) | 2013-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103124981B (zh) | 电子文档流通系统和电子文档流通方法 | |
| JP2013535858A5 (zh) | ||
| US7457848B2 (en) | Over-network resource distribution system and mutual authentication system | |
| AU2006206255B2 (en) | Data exchanges related to financial transactions over a public network | |
| US8627085B2 (en) | Customizable public key infrastructure and development tool for same | |
| US8032750B2 (en) | Method for establishing a secure e-mail communication channel between a sender and a recipient | |
| KR102660475B1 (ko) | 전자 신원확인 및 인증 서비스（ｅｉｄａｓ）를 위한 전자 계약을 인증하는 플랫폼 및 방법 | |
| US20060048210A1 (en) | System and method for policy enforcement in structured electronic messages | |
| US9391775B2 (en) | Signature method and device | |
| US20050033958A1 (en) | Method and system for secure transfer of electronic information | |
| JP2000196583A (ja) | 同報通信システム | |
| JP7449855B2 (ja) | 電子識別および信用サービス（ｅｉｄａｓ）のための電子通知の証明のプラットフォームおよび方法 | |
| WO1999060749A1 (fr) | Systeme de partage d'informations | |
| Tauber et al. | An interoperability standard for certified mail systems | |
| Boldrin et al. | ETSI EN 319 522-2 v1. 1.1:" Electronic Registered Delivery Services. Part 2: Semantic contents” | |
| Liao | Securing e-mail communication with XML technology | |
| KR20180134063A (ko) | 증명 전자 우편 서비스 방법 및 장치 | |
| Boldrin et al. | ETSI SR 019 530:" Rationalised framework of Standards for Electronic Delivery Applying Electronic Signatures" | |
| Tauber et al. | AN INTEROPERABILITY FRAMEWORK FOR CERTIFIED MAIL SYSTEMS |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: Seoul, South Kerean Applicant after: Korea Cyber Security Agency Address before: Seoul, South Kerean Applicant before: National IT Industry Promotion Agency |
|
| COR | Change of bibliographic data | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20161207 Termination date: 20210708 |