本發(fā)明涉及電子文檔流通系統(tǒng)和電子文檔流通方法，該電子文檔流通方法可構(gòu)造不僅為企業(yè)/機構(gòu)而且為個人和小公司提供可靠性的電子文檔流通系統(tǒng)。

背景技術(shù)：
一般，基于企業(yè)/機構(gòu)的個體獨特規(guī)定，電子文檔流通僅在特定行業(yè)集團或者社團中限制性執(zhí)行。此外，存在的問題在于，電子郵件用作一般個人之間或者個人與企業(yè)/機構(gòu)之間的輔助手段而沒有考慮可靠電子流通概念，或者僅在個人、個體企業(yè)或者小公司訪問企業(yè)網(wǎng)站時進行在線交流。因此，可以預(yù)期，不僅可擁有預(yù)定規(guī)模流通系統(tǒng)的企業(yè)，而且個人、個體企業(yè)或者小公司可建立基于電子文檔流通的基礎(chǔ)設(shè)施，該基礎(chǔ)設(shè)施保證流通可靠性。

技術(shù)實現(xiàn)要素：
【技術(shù)問題】本發(fā)明致力于提供不僅允許可擁有預(yù)定規(guī)模流通系統(tǒng)的企業(yè)/機構(gòu)而且還允許個人和小公司建立可靠性的電子文檔流通系統(tǒng)和電子文檔流通方法。【技術(shù)方案】根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)包括：收發(fā)實體，基于電子郵件地址發(fā)送和接收消息并且通過流通通訊服務(wù)器來流通電子文檔，所述流通通訊服務(wù)器發(fā)行和管理消息發(fā)送/接收的流通證書；流通中心，登記/管理收發(fā)實體的電子郵件地址、設(shè)定收發(fā)實體之間的電子文檔流通路徑、將電子文檔的標(biāo)準(zhǔn)格式提供給收發(fā)實體、當(dāng)在收發(fā)實體之間流通電子文檔的過程中發(fā)生錯誤時通過代理服務(wù)器發(fā)送消息并發(fā)行流通證書；以及可靠的第三方存儲機構(gòu)，接收和存儲流通證書。在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)中，在包括收發(fā)實體和流通中心的電子文檔流通系統(tǒng)中流通電子文檔的方法包括以下步驟：（a）步驟：允許發(fā)送實體獲取與接收實體的地址信息對應(yīng)的物理地址信息并然后將帶有附加電子文檔的消息發(fā)送到物理地址；（b）步驟：允許接收消息的接收實體根據(jù)接收消息與發(fā)送實體的兼容性驗證結(jié)果來發(fā)行接收證書或者錯誤證書，且將證書傳送到收發(fā)實體；以及（c）步驟：允許發(fā)送消息到接收實體但發(fā)送失敗的發(fā)送實體請求流通中心通過代理服務(wù)器發(fā)送消息，且允許接收用于通過代理服務(wù)器發(fā)送消息的請求的流通中心發(fā)行發(fā)送證書，以將證書傳送到發(fā)送實體且將消息發(fā)送到接收實體，且然后執(zhí)行步驟（b）?！居幸嫘Ч烤哂猩鲜鰳?gòu)造和方法的本發(fā)明可建立不僅允許企業(yè)/機構(gòu)而且允許個人和小公司建立可靠性的電子文檔流通系統(tǒng)。附圖說明圖1為示出了根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)的構(gòu)造示例的示圖。圖2為示出了圖1的流通通訊服務(wù)器的示圖。圖3為示出了圖1的流通客戶端的示圖。圖4為示出了圖1的地址目錄服務(wù)器的示圖。圖5為示出了圖1的電子文檔格式寄存器的示圖。圖6為示出了圖1的流通中繼服務(wù)器的示圖。圖7為示出了圖1的外接網(wǎng)關(guān)的示圖。圖8為示出了圖1的電子文檔流通系統(tǒng)中認(rèn)證電子郵件地址的實施范圍的示圖。圖9為示出了根據(jù)本發(fā)明示例性實施方式的認(rèn)證電子郵件地址的申請/發(fā)行和操作系統(tǒng)的示圖。圖10、圖11和圖13為示出了在本發(fā)明示例性實施方式中流通電子文檔時消息安全性的示圖。圖14至圖17為示出了在本發(fā)明示例性實施方式中消息收發(fā)處理器的示圖。圖18為示出了根據(jù)本發(fā)明示例性實施方式的物理地址獲得過程的示圖。圖19至圖21為示出了根據(jù)本發(fā)明示例性實施方式的流通中繼支持過程的示圖。圖22至圖24為示出了根據(jù)本發(fā)明示例性實施方式的諸如認(rèn)證電子郵件地址登記的管理過程的示圖。圖25和圖26為示出了根據(jù)本發(fā)明示例性實施方式的電子文檔格式申請過程的示圖。圖27是示出了根據(jù)本發(fā)明另一示例性實施方式的當(dāng)收發(fā)實體用作接收器時在電子文檔流通集線器報告垃圾消息的處理的示圖。圖28是示出了根據(jù)本發(fā)明另一示例性實施方式的當(dāng)收發(fā)實體用作接收器時用于檢查是否實時地拒絕接收通信方的處理的示圖。圖29是示出了根據(jù)本發(fā)明另一示例性實施方式的當(dāng)收發(fā)實體用作接收器時用于定期地檢查是否實時地拒絕接收通信方的處理的示圖。圖30和圖31為根據(jù)本發(fā)明示例性實施方式的電子文檔讀取服務(wù)的概念圖。圖32為根據(jù)本發(fā)明示例性實施方式的外接網(wǎng)關(guān)服務(wù)器的概念圖。圖33為示出了在本發(fā)明示例性實施方式中流通連接到外部系統(tǒng)的電子文檔的過程的示圖。圖34至圖36是示出了根據(jù)本發(fā)明示例性實施方式的垃圾消息處理過程的示圖。圖37-51是示出了根據(jù)本發(fā)明另一個示例性實施方式的流通消息服務(wù)器系統(tǒng)的示圖。圖52-56是示出了根據(jù)本發(fā)明另一示例性實施方式的應(yīng)用于電子文檔流通系統(tǒng)和方法的通信協(xié)議的示圖。圖57和圖58是示出了根據(jù)本發(fā)明另一示例性實施方式的電子文檔形式寄存器的示圖。圖59是示出了根據(jù)本發(fā)明另一示例性實施方式的應(yīng)用于電子文檔流通系統(tǒng)的電子文檔打包的示圖。圖60-66是示出了根據(jù)本發(fā)明另一示例性實施方式的流通客戶端應(yīng)用的示圖。具體地，圖65是示出了根據(jù)本發(fā)明另一示例性實施方式的用于認(rèn)證流通消息服務(wù)器系統(tǒng)以作為認(rèn)證的電子郵件地址被登記的處理的示圖。圖67至圖71為示出了在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)下用于使元件操作為彼此鏈接以流通電子文檔的通信協(xié)議的配置的示圖。圖72至圖76為示出了在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)下錯誤處理方法的示圖。圖77至圖84為示出了在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)中流通通訊服務(wù)器和地址目錄服務(wù)器之間的連接接口的示圖。圖85至圖99為示出了在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)中流通通訊服務(wù)器之間的連接接口的示圖。圖100至圖115為示出了在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)中流通客戶端和流通通訊服務(wù)器之間的連接接口的示圖。圖116至圖118為示出了在根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)中流通通訊服務(wù)器和流通中繼服務(wù)器之間的連接接口的示圖。圖119A為示出了表37的郵政流通系統(tǒng)的示圖，圖119B為示出了表37的電子郵件流通系統(tǒng)的示圖，圖119C為示出了表37的電子文檔互換（EDI）流通系統(tǒng)的示圖，以及圖119D為示出了表37的工作相關(guān)系統(tǒng)流通系統(tǒng)的示圖。圖120A為示出了表38的自動處理方法的示圖，以及圖120B為示出了表38的半自動處理方法的示圖。圖121A為示出了表39的網(wǎng)站（web）方法的示圖，以及圖121B為示出了表39的應(yīng)用程序方法的示圖。具體實施方式【最佳實施方式】下文中，將參考附圖和表描述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)和電子文檔流通方法。圖1示出了根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)的構(gòu)造示例。參考圖1，根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)包括：收發(fā)實體101，通過流通通訊服務(wù)器來流通電子文檔，所述流通通訊服務(wù)器基于電子郵件地址發(fā)送和接收消息，且發(fā)行和管理消息發(fā)送/接收的流通證書；電子文檔流通中心102，登記/管理收發(fā)實體101的電子郵件地址、設(shè)定收發(fā)實體101之間的電子文檔流通路徑、將電子文檔標(biāo)準(zhǔn)格式提供給收發(fā)實體101以及當(dāng)在收發(fā)實體101之間流通電子文檔過程中發(fā)生錯誤時，由收發(fā)實體的代理服務(wù)器發(fā)送消息且發(fā)行流通證書；以及可靠的第三方存儲機構(gòu)（認(rèn)證電子文檔存儲器）103，接收和存儲流通證書。收發(fā)實體101的流通通訊服務(wù)器將發(fā)送/接收消息與每個用戶的狀態(tài)信息一起存儲于消息箱中，并將消息發(fā)送和接收記錄存儲于在預(yù)定時段內(nèi)無法編輯和刪除的介質(zhì)中，且發(fā)行消息發(fā)送和接收的流通證書以請求第三方存儲機構(gòu)存儲流通證書。流通通訊服務(wù)器與地址目錄服務(wù)器連接，以允許收發(fā)實體101使用登記、搜索、編輯和刪除電子郵件地址的功能。此外，流通通訊服務(wù)器將已存儲達預(yù)定時間段以上的消息轉(zhuǎn)移到外部存儲裝置來存儲。電子郵件地址包括：收發(fā)實體101的用戶識別標(biāo)記，其通過電子文檔流通中心102的地址目錄服務(wù)器發(fā)行；附加識別（identification），其為需要時由收發(fā)實體101自主賦予的唯一值且為收發(fā)實體101中的唯一值；以及分割符號，位于用戶識別標(biāo)記和附加識別標(biāo)記之間。電子文檔流通中心102包括電子文檔格式寄存器。電子文檔格式寄存器執(zhí)行包括電子文檔標(biāo)準(zhǔn)格式信息登記、刪除和編輯的管理。此外，電子文檔格式寄存器另外根據(jù)上下文（context）對電子文檔標(biāo)準(zhǔn)格式分類，且執(zhí)行包括對使用電子文檔標(biāo)準(zhǔn)格式的上下文進行的登記和編輯的管理。電子文檔流通中心102包括流通中繼服務(wù)器，當(dāng)在收發(fā)實體101之間流通電子文檔過程期間發(fā)生錯誤時，流通中繼服務(wù)器通過代理服務(wù)器發(fā)送消息，且發(fā)行流通證書。當(dāng)收發(fā)實體101請求流通中繼服務(wù)器發(fā)送消息時，在通過代理服務(wù)器發(fā)送消息之后，流通中繼服務(wù)器發(fā)行發(fā)送證書到請求發(fā)送消息的收發(fā)實體101。如果所請求消息發(fā)送失敗，那么流通中繼服務(wù)器發(fā)送錯誤消息到請求發(fā)送消息的收發(fā)實體101。電子文檔流通中心102包括與外部系統(tǒng)連接的外接網(wǎng)關(guān)服務(wù)器。外接網(wǎng)關(guān)服務(wù)器包括流通通訊服務(wù)器，該流通通訊服務(wù)器基于電子郵件地址發(fā)送/接收消息。外接網(wǎng)關(guān)服務(wù)器提供外接系統(tǒng)和電子文檔流通系統(tǒng)之間的發(fā)送/接收電子郵件地址驗證/轉(zhuǎn)換功能、外接系統(tǒng)和電子文檔流通系統(tǒng)之間的消息驗證/轉(zhuǎn)換功能、應(yīng)用于外接系統(tǒng)和電子文檔流通系統(tǒng)之間的電子文檔的安全性驗證/轉(zhuǎn)換功能以及驗證和轉(zhuǎn)換外接系統(tǒng)和電子文檔流通系統(tǒng)之間的電子文檔兼容性的功能。將參考圖1至圖118詳細描述根據(jù)本發(fā)明示例性實施方式的具有上述構(gòu)造的電子文檔流通系統(tǒng)及使用該電子文檔流通系統(tǒng)的電子文檔流通方法。在本發(fā)明的詳細描述中，將省略圖1的參考標(biāo)號?！倦娮游臋n流通系統(tǒng)的結(jié)構(gòu)】為了保證電子文檔流通的可靠性和穩(wěn)定性，根據(jù)本發(fā)明的電子文檔流通系統(tǒng)需要滿足以下要求（1）至（7）。（1）參與流通系統(tǒng)的收發(fā)實體和發(fā)送方/接收方需要使用預(yù)定方法發(fā)送/接收電子文檔，且同意管理機構(gòu)或者電子文檔提供商的服務(wù)等級協(xié)議（SLA）。（2）允許對參與流通系統(tǒng)的收發(fā)實體和認(rèn)證發(fā)送方/接收方進行識別，且需要防止電子文檔流通動作被拒絕。（3）作為用于區(qū)別流通系統(tǒng)中收發(fā)實體和認(rèn)證的發(fā)送方/接收方的信息的認(rèn)證電子郵件地址需要以公司或者個人為單位給出，且通過登記機構(gòu)來登記和管理。（4）當(dāng)在流通系統(tǒng)中流通電子文檔時，需要生成流通證書，且將流通證書發(fā)送并存儲于參與流通動作的發(fā)送實體以及第三方存儲機構(gòu)中。（5）即使所有電子文檔流通動作都基于P2P（點對點）通信執(zhí)行，也需要提供由于各種環(huán)境因素導(dǎo)致通信失敗時支持流通的系統(tǒng)。（6）不僅需要支持流通系統(tǒng)中各方之間的電子文檔交換，而且需要支持諸如電子文檔讀取服務(wù)的各種附加服務(wù)。（7）需要提供支持與除流通系統(tǒng)外的外部系統(tǒng)連接的網(wǎng)關(guān)?；谡J(rèn)證的電子郵件地址以及在具有流通通訊服務(wù)器的收發(fā)實體之間發(fā)送/接收電子文檔的P2P通信來執(zhí)行根據(jù)本發(fā)明的電子文檔流通系統(tǒng)。圖1中示出了根據(jù)本發(fā)明的電子文檔流通系統(tǒng)的結(jié)構(gòu)，且系統(tǒng)中的元件將在下表1和表2中描述。此外，主要過程將在下表3中描述?！颈?】【表2】【表3】【電子文檔流通系統(tǒng)的元件】（1）流通通訊服務(wù)器流通通訊服務(wù)器為設(shè)置于收發(fā)實體中的通訊系統(tǒng)，且在電子文檔流通中起著核心作用。流通通訊服務(wù)器需要在物理上具有一個電子郵件地址（IP地址），但是發(fā)行和管理較低級別用戶的多個用戶賬戶。為了管理用戶賬戶，流通通訊服務(wù)器需要管理每個用戶賬戶的消息箱。流通通訊服務(wù)器負責(zé)安全可靠地管理用戶的賬戶和消息箱。流通通訊服務(wù)器的功能概念示于圖2中，且其功能將在下表4中描述?！颈?】除表4中描述的功能外，以下（1）到（4）原理需要在服務(wù)器系統(tǒng)管理中遵守，以提高流通通訊服務(wù)器的可靠性。（1）系統(tǒng)管理者無法看到或者主動刪除個人的消息箱。（2）與服務(wù)器系統(tǒng)管理相關(guān)的記錄信息在10年或者更長年限內(nèi)無法主動刪除且存儲于不變介質(zhì)中。（3）系統(tǒng)管理者無法主動更改認(rèn)證流通通訊服務(wù)器解決方案的基本功能。（4）需要創(chuàng)建與系統(tǒng)管理相關(guān)的操作準(zhǔn)則，且需要根據(jù)準(zhǔn)則執(zhí)行管理。（2）流通客戶端流通客戶端為代表參與流通系統(tǒng)中的發(fā)送方/接收方提供UI（用戶界面）的應(yīng)用程序，諸如消息發(fā)送和接收、接收電子文檔的讀取和管理。流通客戶端無法獨立發(fā)送/接收文檔，且需要不可避免地與流通通訊服務(wù)器連接。流通客戶端請求通過流通通訊服務(wù)器發(fā)送消息或者查詢通過流通通訊服務(wù)器接收到的消息。流通通訊服務(wù)器管理每個用戶賬戶的消息箱。流通客戶端需要通過檢查用戶賬戶信息只訪問所接收文檔中存儲于其自己賬戶中的消息。根據(jù)收發(fā)實體的請求，流通客戶端可實施為C/S型應(yīng)用程序或者web型屏幕。流通客戶端的功能概念在圖3中示出，且其功能將在以下表5中描述?！颈?】（3）地址目錄服務(wù)器地址目錄服務(wù)器為管理發(fā)送/接收實體以及經(jīng)認(rèn)證的發(fā)送方/接收方的地址信息并且提供物理地址的系統(tǒng)。地址目錄服務(wù)器提供諸如以下功能（1）和（2）的基本功能：（1）管理和提供接收實體的流通通訊服務(wù)器的物理地址（IP地址）（2）管理諸如對經(jīng)認(rèn)證的電子地址的信息進行的登記和編輯功能另外，地址目錄服務(wù)器基本上具有管理白名單信息的功能，且從用戶接收關(guān)于垃圾消息的報告，且基于報告管理黑名單信息。地址目錄服務(wù)器通過門戶網(wǎng)站屏幕和流通通訊服務(wù)器將與認(rèn)證電子地址相關(guān)的信息提供給收發(fā)實體或者經(jīng)認(rèn)證的發(fā)送方/接收方，且相關(guān)申請方可通過連接接口使用由地址目錄服務(wù)器提供的服務(wù)。地址目錄服務(wù)器的功能概念在圖4中示出，且其功能將在以下表6中描述?！颈?】（4）電子文檔格式寄存器電子文檔格式寄存器為由電子文檔流通中心提供的系統(tǒng)，以使用收發(fā)實體之間的預(yù)定標(biāo)準(zhǔn)電子文檔來自動處理或者利用電子表格型電子文檔。電子文檔格式寄存器提供：服務(wù)器引擎，其管理電子文檔格式；接口，其提供允許流通客戶端搜索和下載電子文檔格式的功能；以及門戶網(wǎng)站界面。電子文檔格式寄存器的功能概念在圖5中示出，且其功能將在以下表7中描述。【表7】（5）流通中繼服務(wù)器流通中繼服務(wù)器為設(shè)置于電子文檔流通中心中以當(dāng)在流通系統(tǒng)中進行收發(fā)實體之間的電子文檔流通過程期間發(fā)生錯誤時，通過發(fā)送實體的代理服務(wù)器發(fā)送消息的系統(tǒng)。流通中繼服務(wù)器具有作為流通通訊服務(wù)器的功能，以提供基本電子文檔收發(fā)服務(wù)。此外，流通中繼服務(wù)器為流通通訊服務(wù)器提供流通中繼服務(wù)器的獨特服務(wù)，諸如在最終失敗的情況下通過連接接口進行的中繼請求接收和錯誤消息發(fā)送。流通中繼服務(wù)器的功能概念在圖6中示出，且其功能將在以下表8中描述?！颈?】（7）經(jīng)認(rèn)證的電子郵件地址收發(fā)實體以及參與流通系統(tǒng)中的認(rèn)證發(fā)送方/接收方需要接收唯一認(rèn)證的電子郵件地址。認(rèn)證電子郵件地址由井號【#】、數(shù)字【0到9】、連字符【-】和句點【.】的組合構(gòu)成。與認(rèn)證電子郵件地址的構(gòu)成系統(tǒng)相關(guān)的原理如以下（1）到（3）：（1）作為前部“#”，為了用戶便利，可選擇性使用由字符【A-Z】【a-z】、韓文字母表【完整韓文字母表，2350個字母】、數(shù)字【0-9】、連字符【-】和句點【.】組合構(gòu)成的附加用戶標(biāo)識符。在此情況下，附加用戶標(biāo)識符可由電子文檔流通通訊服務(wù)器管理。（2）認(rèn)證電子郵件地址的附加用戶標(biāo)識符不應(yīng)以連字符或者句點開頭或者結(jié)尾，且其長度設(shè)定為30個字節(jié)或者更短。（3）作為認(rèn)證電子郵件地址的附加用戶標(biāo)識符，可能不使用可能破壞社會習(xí)俗或者公共道德的字符和數(shù)字組合或者由管理機構(gòu)負責(zé)人確定的其它受限符號。認(rèn)證電子郵件地址和IP地址（其為實際物理地址（流通通信服務(wù)器的實際物理地址））之間的相關(guān)性關(guān)系只由地址目錄服務(wù)器管理。認(rèn)證電子郵件地址和流通通訊服務(wù)器的實際物理地址具有1：1或者N：1關(guān)系。因此，一個認(rèn)證電子郵件地址不具有多個物理地址。緊鄰“#”的公司/組織/個人應(yīng)當(dāng)負有接收認(rèn)證電子郵件地址的信息（文檔）的法律責(zé)任。此外，為了方便公司/組織/個人，根據(jù)附加用戶標(biāo)識符劃分流通。因此，收發(fā)實體應(yīng)當(dāng)具有根據(jù)附加用戶標(biāo)識符流通的責(zé)任。在此情況下，收發(fā)實體需要準(zhǔn)備與附加用戶標(biāo)識符對應(yīng)的用戶認(rèn)證的策略和管理知識，且根據(jù)知識透徹管理用戶認(rèn)證。此外，當(dāng)收發(fā)實體參與流通系統(tǒng)之前與管理機構(gòu)簽訂關(guān)于SLA的協(xié)議時，收發(fā)實體需要包括具有內(nèi)部標(biāo)識符的認(rèn)證電子郵件地址的內(nèi)容。流通系統(tǒng)中認(rèn)證電子郵件地址的實施范圍將在圖8中示出。附加用戶標(biāo)識符需要是收發(fā)實體的唯一值。單個收發(fā)實體基本上負責(zé)施加附加用戶標(biāo)識符。此外，收發(fā)實體負責(zé)根據(jù)附加用戶標(biāo)識符進行電子文檔流通。因此，如果發(fā)生問題，那么收發(fā)實體需要解決問題。附加用戶標(biāo)識符不包括在流通系統(tǒng)的實施范圍中，但可由具有管理代理的SLA定義。為了企業(yè)操作便利，附加用戶標(biāo)識符用于流通電子文檔，且僅用于企業(yè)內(nèi)部信息，而無需登記在地址目錄服務(wù)器中。作為如上所述的認(rèn)證電子郵件地址的其它示例，可允許以下結(jié)構(gòu)。認(rèn)證電子郵件地址=ID+分割符號+登記者這里，“ID”由英語（或者韓文字母表或者數(shù)字）、連字符【-】和句點【.】組合構(gòu)成，“分割符號”為#，以及“登記者”由英語（或者韓文字母表或者數(shù)字）和句點【.】組合構(gòu)成。“swconvergence#mke.go.kr”為認(rèn)證電子郵件地址的示例。在以上示例中，“swconvergence”表示政府機構(gòu)部門名稱，“mke”表示政府機構(gòu)，“go”表示屬性，以及“kr”表示國家。認(rèn)證電子郵件地址的申請/發(fā)行和操作系統(tǒng)在圖9中示出，且與此相關(guān)的構(gòu)造將在以下表11中描述?！颈?1】【消息安全性】流通系統(tǒng)中最重要部分之一為發(fā)送消息的安全性，其要求（1）防止發(fā)送/接收的拒絕，（2）發(fā)送消息的完整性保證，（3）發(fā)送方認(rèn)證以及（4）發(fā)送消息的機密性保證。其中，（1）到（3）通過發(fā)送消息的發(fā)送方的數(shù)字簽名來支持，且（4）通過加密發(fā)送消息來提供。當(dāng)在流通通訊服務(wù)器之間流通電子文檔時所應(yīng)用的安全性（其為流通系統(tǒng)的基礎(chǔ)）支持消息數(shù)字簽名和加密，如圖10所示。網(wǎng)絡(luò)加密需要施加于每個部分以保護發(fā)送。內(nèi)容的數(shù)字簽名為每個應(yīng)用程序的獨特部分。其描述將省略。在本發(fā)明中，基本上，利用接收方公鑰進行加密。如果沒有接收方的認(rèn)證證書，或者接收方為內(nèi)部接收方，那么只可選擇接收實體加密。此外，在消息發(fā)送期間，消息連同對消息的認(rèn)證信息一起發(fā)送到流通通訊服務(wù)器。在此情況下，流通通訊服務(wù)器主要使用認(rèn)證信息來認(rèn)證客戶端。此外，流通通訊服務(wù)器采用不同認(rèn)證方法，諸如基于IP/PW的認(rèn)證、基于令牌信息的SSO（單獨簽字）認(rèn)證以及基于認(rèn)證證書的數(shù)字簽名，以認(rèn)證流通客戶端。下文中，將詳細描述數(shù)字簽名方法。當(dāng)流通通訊服務(wù)器與其它系統(tǒng)（其它流通通訊服務(wù)器、地址目錄服務(wù)器或者流通中繼服務(wù)器）連接時，需要基于其自己的證書進行數(shù)字簽名。用于連接流通系統(tǒng)中組成要素的所有流通消息基本上都被數(shù)字簽名。然而，流通客戶端和流通通訊服務(wù)器之間的數(shù)字簽名為可選，且數(shù)字簽名只應(yīng)用于基于證書的用戶認(rèn)證方法。在此情況下，流通通訊服務(wù)器負責(zé)用戶認(rèn)證、完整性和防止拒絕流通客戶端的流通消息的發(fā)送/接收。下文中，將詳細描述加密方法。流通系統(tǒng)中附加文檔可在發(fā)送方選擇加密之后發(fā)送以保護文檔，為了文檔機密性執(zhí)行加密，但是不同于網(wǎng)絡(luò)加密。因此，在應(yīng)用網(wǎng)絡(luò)加密之后，可另外加密流通文檔。待加密部分可為（1）從發(fā)送方的流通客戶端到接收方的流通通訊服務(wù)器或者（2）從發(fā)送方的流通客戶端到接收方的流通客戶端，如圖10所示。如果接收方為認(rèn)證發(fā)送方/接收方，且證書登記在地址目錄服務(wù)器中，那么在從發(fā)送方到接收方的部分（2）中進行加密。否則，在從發(fā)送方到接收實體的部分（1）中進行加密。當(dāng)加密附加文檔時，如果在從發(fā)送方到接收實體的部分（1）中保持加密，那么發(fā)送方需要加密文檔，以在發(fā)送方的流通通訊服務(wù)器、接收方的流通通訊服務(wù)器以及接收方的流通客戶端的三個步驟中解碼文檔。如果在從發(fā)送方到接收實體的部分（2）中保持加密，那么發(fā)送方需要加密文檔，以解碼發(fā)送方的流通通訊服務(wù)器以及接收方的流通通訊服務(wù)器。如果加密附加電子文檔，那么發(fā)送實體和接收實體的流通通訊服務(wù)器在加密狀態(tài)下存儲電子文檔，以管理記錄。因此，如果發(fā)送方/接收方想要基于解碼文檔來驗證流通證書，那么解碼電子文檔以驗證流通證書。出于這個原因，流通通訊服務(wù)器需要一直管理撤銷證書的私鑰以及訪問私鑰的密碼。下文中，將描述加密方法中加密的概要。如果發(fā)送方確定流通系統(tǒng)中正在流通的消息的機密性被確保，那么需要遵守以下加密處理。在國內(nèi)外作為標(biāo)準(zhǔn)使用的以由IETFRFC3852“CMS（加密消息語法）”建議的內(nèi)容信息結(jié)構(gòu)為代表的封裝包數(shù)據(jù)內(nèi)容類型用作密文?！鵕FC3852CMS1）IETF為定義互聯(lián)網(wǎng)操作協(xié)議標(biāo)準(zhǔn)（諸如TCP/IP）的主要代理。IETF由IAB（互聯(lián)網(wǎng)架構(gòu)委員會，互聯(lián)網(wǎng)技術(shù)改進互聯(lián)網(wǎng)協(xié)議的監(jiān)督機構(gòu)）監(jiān)督。IETF成員從個人或者互聯(lián)網(wǎng)協(xié)會組織成員選擇。在IETF中創(chuàng)建的標(biāo)準(zhǔn)以RFC類型為代表，且基于RFC標(biāo)準(zhǔn)文檔作出國內(nèi)外許多基于PKI的解決方案（各種認(rèn)證系統(tǒng)、時間戳或者第三方存儲機構(gòu)大?。?。2）CMS（加密消息語法）基于由RSA公司首先創(chuàng)建的“PKCS#7v1.5”來創(chuàng)建。RFC2630利用由IETF標(biāo)準(zhǔn)化的RFC標(biāo)準(zhǔn)來創(chuàng)建。在第一PKCS#7中，只提供密鑰傳送（用于加密的對稱密鑰使用RSA交付給另一方）方法。與之相比，在RFC2630的CMS中，添加密鑰協(xié)議（使用DH算法交付密鑰的方法）。3）此后，在2002年建立RFC3369，其中分離算法部分且應(yīng)用各種密鑰管理方法。然而，報告出RFC3369的各種問題，因此最終修正版本為在本發(fā)明中應(yīng)用的RFC3852。作為另外應(yīng)用標(biāo)準(zhǔn)，在創(chuàng)建密文或者與算法對應(yīng)的參數(shù)時，在內(nèi)容加密（將實際發(fā)送的電子稅務(wù)發(fā)票封裝包）中使用的算法遵循IETFRFC3370“加密消息語法（CMS）算法”和IETFRFC4010“SEED加密算法在加密消息語法（CMS）中的使用”。下文中，將描述加密方法中的加密目標(biāo)數(shù)據(jù)。參考圖11，待交付消息的加密目標(biāo)為以下（1）和（2）。（1）在第二MIME中輸入的流通信息（2）輸入主文本實際內(nèi)容的消息體塊的<文本>區(qū)以及附加文檔消息體塊中的文本以及附加文檔被單獨加密，且包括在相應(yīng)位置中。第一加密目標(biāo)為將交付給接收方的主文本內(nèi)容，且在XML體塊中<文本>部分中具有值。接著，將描述目標(biāo)數(shù)據(jù)的配置方法。數(shù)據(jù)遵循ASN.1基本編碼規(guī)則（BER），且遵守區(qū)分編碼規(guī)則（DER）。下文中，將描述加密方法中加密證書的獲得和驗證。為了創(chuàng)建密文，需要獲得解碼實際數(shù)據(jù)的接收方側(cè)證書。為了獲得證書，發(fā)送方需要連接到地址目錄服務(wù)器以獲得接收方（或者接收實體）證書。在此情況下，根據(jù)所獲得證書為接收實體的證書還是認(rèn)證的接收方的證書，來改變保持機密性的部分。如果發(fā)送方選擇發(fā)送消息加密，那么發(fā)送方基于所獲得的接收方（或者接收實體）證書進行加密，且發(fā)送消息到接收方。即使在消息發(fā)送期間發(fā)生錯誤，使得請求流通中繼中心發(fā)送消息，也發(fā)送消息而無需更改加密內(nèi)容。【網(wǎng)絡(luò)安全性】為了保持發(fā)送方和接收方之間流通的消息的機密性，SSL（安全套接字層）應(yīng)用于（流通客戶端與通訊發(fā)送方的流通通訊服務(wù)器之間、發(fā)送方和接收方的流通通訊服務(wù)器之間以及接收方的流通通訊服務(wù)器與接收方的流通客戶端之間）的電子文檔流通的所有部分，以用于網(wǎng)絡(luò)安全性。【消息收發(fā)過程】流通系統(tǒng)中的當(dāng)事方之間以及系統(tǒng)之間存在各種任務(wù)過程。在流通系統(tǒng)中存在最基本消息收發(fā)過程，且提供各種過程以支持基本消息收發(fā)過程。消息收發(fā)過程為在發(fā)送方和接收方之間直接發(fā)送和接收消息且與另一方交換文檔（如郵件或者電子郵件）的過程。為了在發(fā)送方和接收方之間發(fā)送/接收消息，提供四個步驟的過程（1）獲得接收方的物理地址和安全性信息，（2）發(fā)送消息和確認(rèn)發(fā)送，（3）確認(rèn)接收方接收任務(wù)以及（4）發(fā)行和存儲流通證書。在此情況下，在流通證書的過程中，根據(jù)待證明的內(nèi)容，可更改詳細過程的流程。其基本流程在圖14中示出，且在以下表22中詳細描述?！颈?2】消息收發(fā)過程被分為發(fā)送過程和接收過程。此外，根據(jù)流通客戶端和流通通訊服務(wù)器之間的連接方法，發(fā)送過程被分為同步發(fā)送和異步發(fā)送。下文中，將參考圖15和表23描述同步消息收發(fā)過程。當(dāng)發(fā)送實體的流通客戶端請求流通通訊服務(wù)器發(fā)送消息時，同步消息收發(fā)過程為實時發(fā)送消息到接收實體的流通通訊服務(wù)器且從發(fā)送方的流通通訊服務(wù)器同步接收應(yīng)答的過程。根據(jù)同步過程，流通客戶端立即檢查發(fā)送結(jié)果，使得可簡化任務(wù)過程的定義。同步消息收發(fā)過程將在以下表23中詳細描述?！颈?3】下文中，將參考圖16和表24描述異步消息收發(fā)過程。當(dāng)發(fā)送實體的流通客戶端請求流通通訊服務(wù)器發(fā)送消息時，異步發(fā)送過程只驗證發(fā)送請求對于流通通訊服務(wù)器的有效性，且然后返回請求的接收確認(rèn)消息到流通客戶端。消息實時發(fā)送到接收實體的流通通訊服務(wù)器，且通過發(fā)送實體的流通通訊服務(wù)器同步接收對其的響應(yīng)。當(dāng)發(fā)送消息費時時使用異步過程，使得客戶端可以不等待響應(yīng)，例如，當(dāng)待發(fā)送消息量大或者一個消息指定多個接收方時。異步消息收發(fā)過程將在以下表24中詳細描述?！颈?4】下文中，將詳細描述消息接收過程。文檔接收方通過流通客戶端接收消息的過程在圖17中示出，且將在以下表25中描述過程。當(dāng)接收方的流通通訊服務(wù)器從發(fā)送方接收消息時，流通通訊服務(wù)器發(fā)送接收證書作為其響應(yīng)，且將文檔存儲于最后接收方的消息箱中。流通客戶端頻繁請求接收消息列表到流通通訊服務(wù)器。如果有新接收消息，那么流通客戶端接收接收消息列表作為響應(yīng)消息，且通過請求保留消息的消息獲得接收文檔?！颈?5】【物理地址獲取過程】參與流通系統(tǒng)的發(fā)送實體在發(fā)送消息到另一方之前需要基于認(rèn)證電子郵件地址獲悉實際物理地址信息。此外，為了加密要另外附加的文檔，發(fā)送實體需要知道地址目錄服務(wù)器中接收方的公鑰信息。獲取認(rèn)證電子郵件地址的物理地址的基本步驟如下1）到4）：1）發(fā)送實體查詢地址目錄服務(wù)器，以獲得物理地址信息以及基于接收實體的地址信息獲得安全性信息2）地址目錄服務(wù)器接收/驗證發(fā)送實體的查詢，且然后處理查詢3）發(fā)送實體基于所接收物理地址設(shè)定路徑，以發(fā)送消息到接收實體4）接收實體的流通通訊服務(wù)器接收消息，以根據(jù)用戶賬戶或者內(nèi)部標(biāo)識符在內(nèi)部流通消息此外，在流通系統(tǒng)中獲得認(rèn)證電子郵件地址的物理地址的方法分為以下兩個方法（1）和（2）。（1）在流通客戶端輸入接收方地址信息時，請求地址目錄服務(wù)器搜索以獲得物理地址和接收方公鑰的方法：1）以事先檢查認(rèn)證電子郵件地址的有效性，2）當(dāng)流通客戶端和流通通訊服務(wù)器（發(fā)送實體）之間需要消息加密時（2）在流通客戶端請求流通通訊服務(wù)器發(fā)送消息之后，流通通訊服務(wù)器從地址目錄服務(wù)器獲得物理地址的方法獲得認(rèn)證電子郵件地址的物理地址以及安全性信息的過程在圖19中示出?！玖魍ㄖ欣^支持過程】流通系統(tǒng)基本上執(zhí)行發(fā)送實體和接收實體之間的直接通信（P2P）。然而，另外，如果由于網(wǎng)絡(luò)以及接收實體的流通通訊服務(wù)器的錯誤而在消息流通中發(fā)生故障，那么提供通過代理服務(wù)器中繼/執(zhí)行流通的中繼過程以為了用戶便利以及穩(wěn)定支持流通。當(dāng)由于從發(fā)送實體發(fā)送消息到接收實體的過程中發(fā)生錯誤，而發(fā)送失敗時，電子文檔流通中心中的流通中繼服務(wù)器通過發(fā)送實體的代理服務(wù)器委托/發(fā)送消息，以證實發(fā)送實體的發(fā)送且減輕發(fā)送實體的系統(tǒng)負擔(dān)。圖23示出了其基本流程，以及圖24示出了流通中繼服務(wù)器中繼消息的過程。以下表26描述流通中繼過程的步驟。【表26】【流通證書的存儲過程】作為與流通系統(tǒng)中執(zhí)行的所有流通動作相關(guān)的結(jié)果，流通證書不可避免地創(chuàng)建，從而存儲于第三方存儲機構(gòu)中。這是因為，可以通過將具有流通證據(jù)的流通證書存儲于法律認(rèn)可的第三方存儲機構(gòu)中來建立法律推定。存儲流通證書的過程是與電子文檔流通分開的過程，但是為證實流通動作事實的支持過程。因此，所有流通通訊服務(wù)器需要成為能夠預(yù)先接收和存儲流通證書的特定第三方存儲機構(gòu)成員。此外，如果發(fā)送實體想要電子文檔內(nèi)容的認(rèn)證，那么除流通證書之外，實體消息可存儲于第三方存儲機構(gòu)中。第三方存儲機構(gòu)需要包括以下兩個另外系統(tǒng)（1）和（2），以接收和存儲流通證書。（1）第三方存儲機構(gòu)提供商的流通通訊服務(wù)器：流通系統(tǒng)中用流通通訊服務(wù)器收發(fā)流通證書所需的系統(tǒng)（2）第三方存儲機構(gòu)連接客戶端模塊：與第三方存儲機構(gòu)連接接口通信以通過第三方存儲機構(gòu)提供商的流通通訊服務(wù)器將所接收的流通證書存儲于第三方存儲機構(gòu)中的模塊然而，如果第三方存儲機構(gòu)提供商也充當(dāng)電子文檔提供商，那么可以不另外需要流通通訊。圖28示出了存儲收發(fā)實體和第三方存儲機構(gòu)提供商之間的流通的過程，且流通證書存儲過程的步驟將在以下表27中描述。【表27】【管理過程，諸如認(rèn)證電子郵件地址的登記】收發(fā)實體需要申請和登記認(rèn)證電子郵件地址以參與流通系統(tǒng)，且登記機構(gòu)和管理機構(gòu)需要登記和管理與認(rèn)證電子郵件地址相關(guān)的信息。認(rèn)證電子郵件地址管理過程包括與認(rèn)證電子郵件地址相關(guān)的諸如登記、變更和刪除的管理過程以及黑名單/白名單管理過程。管理機構(gòu)允許認(rèn)證電子郵件地址登記機構(gòu)管理認(rèn)證電子郵件地址，以有效管理認(rèn)證電子郵件地址。登記機構(gòu)執(zhí)行以下任務(wù)（1）到（4）。（1）檢查任務(wù)，諸如認(rèn)證電子郵件地址的申請人識別（2）認(rèn)證電子郵件地址登記方的登記信息變更任務(wù)（3）任務(wù)支持，諸如認(rèn)證電子郵件地址的登記取消（4）與認(rèn)證電子郵件地址的管理相關(guān)的其它任務(wù)管理機構(gòu)可選擇滿足要求的第三方存儲機構(gòu)以及電子文檔提供商中任何一個作為登記機構(gòu)。下文中，將描述登記認(rèn)證電子郵件地址的過程。想要參與流通系統(tǒng)的企業(yè)/機構(gòu)/個人需要申請認(rèn)證的電子郵件地址，且登記機構(gòu)檢查和處理申請信息并通知結(jié)果。相關(guān)過程在圖22中示出。下文中，將描述變更認(rèn)證電子郵件地址的登記信息的過程。即使與已經(jīng)登記的認(rèn)證電子郵件地址相關(guān)的信息由于各種原因變更，身份需要保持，以使得擁有者的電子郵件地址和信息未變更。用于變更與認(rèn)證電子郵件地址相關(guān)的信息的權(quán)限授權(quán)給登記機構(gòu)處理。在此情況下，關(guān)于信息變更的記錄信息需要根據(jù)管理機構(gòu)和登記機構(gòu)之間的服務(wù)級別協(xié)議（SLA）來存儲。與其相關(guān)的過程在圖23中示出。參考圖23，只可通過當(dāng)事方變更認(rèn)證電子郵件地址。在個人情況下，認(rèn)證電子郵件地址、登記號和名稱無法變更。因此，個人撤銷認(rèn)證電子郵件地址，且然后新創(chuàng)建新地址。在企業(yè)情況下，認(rèn)證電子郵件地址無法變更。如果登記號（營業(yè)執(zhí)照號碼）和企業(yè)名稱變更，那么需要利用相應(yīng)信息變更時接收的新證書來變更認(rèn)證電子郵件地址。圖24示出了變更登記機構(gòu)的過程。參考圖24，如果登記機構(gòu)變更，那么需要執(zhí)行1）從現(xiàn)有登記機構(gòu)的撤銷過程；以及2）通過新登記機構(gòu)的新登記過程。在此情況下，需要請求地址目錄服務(wù)器暫時保持認(rèn)證電子郵件地址。當(dāng)撤銷所有認(rèn)證電子郵件地址時，認(rèn)證電子郵件地址被選擇性暫時保持，使得當(dāng)?shù)怯洐C構(gòu)變更時，地址目錄服務(wù)器可將認(rèn)證電子郵件地址保存一預(yù)定時段。下文中，將描述更新、暫停和刪除認(rèn)證電子郵件地址的過程。已經(jīng)登記的認(rèn)證電子郵件地址需要根據(jù)設(shè)定使用期限來更新。在登記認(rèn)證電子郵件地址之后，擁有者需要在基于服務(wù)策略結(jié)束設(shè)定的使用期限之前更新認(rèn)證電子郵件地址。如果擁有者未更新認(rèn)證電子郵件地址，那么擁有者失去認(rèn)證電子郵件地址的所有權(quán)，且認(rèn)證電子郵件地址自動取消。此外，即使認(rèn)證電子郵件地址還未到期，如果登記者想要停止使用或者取消電子郵件地址，那么需要提供此功能?！倦娮游臋n格式申請過程】這個過程的目的在于，在流通消息之后增加使用率。根據(jù)這個過程，包括在消息中的電子文檔在企業(yè)內(nèi)部系統(tǒng)中被自動或者半自動處理。流通通訊服務(wù)器只在當(dāng)事方之間進行收發(fā)，且流通客戶端提供接口，以使得發(fā)送方/接收方容易使用待收發(fā)消息。在隨后步驟中，利用消息中的電子文檔。電子文檔格式寄存器或者電子文檔格式提供有效操作電子文檔使用步驟的方法。根據(jù)流通系統(tǒng)流通的文檔類型沒有特定限制。圖像、辦公文檔或者電影是可以使用的。然而，為了提高用戶便利性，在流通系統(tǒng)中另外建議以文本形式創(chuàng)建文檔的功能。上述附加功能引入電子文檔交換功能，以使得基于收發(fā)實體之間約定的電子文檔格式收發(fā)文檔數(shù)據(jù)，以自動轉(zhuǎn)換通過接收實體的內(nèi)部系統(tǒng)接收的電子文檔。以下兩個方法（1）和（2）可用于電子文檔格式。（1）利用電子文檔流通中心中的電子文檔格式寄存器的方法。主要使用標(biāo)準(zhǔn)化電子文檔，諸如電子稅務(wù)發(fā)票（2）共享通過收發(fā)實體之間協(xié)議獲得的電子文檔格式的方法。主要使用為特定企業(yè)指定的非標(biāo)準(zhǔn)化電子文檔下文中，如下將詳細描述電子文檔格式寄存器的使用。在搜索登記在電子文檔格式寄存器中的電子文檔格式之后，企業(yè)、組織或者個人用戶將電子文檔格式登記于流通客戶端中以使用電子文檔格式。通過以下兩個方法（1）和（2）使用電子文檔格式寄存器。（1）在電子文檔格式寄存器中直接搜索電子文檔以從流通客戶端導(dǎo)入電子文檔的方法（2）從電子文檔格式登記網(wǎng)站搜索電子文檔并將電子文檔下載在本地PC中，且然后將電子文檔登記于流通客戶端中以使用電子文檔的方法因為電子文檔格式寄存器登記/利用標(biāo)準(zhǔn)化電子文檔格式，所以管理機構(gòu)需要系統(tǒng)地操作/管理電子文檔格式寄存器，且電子文檔格式寄存器可具有以下標(biāo)準(zhǔn)（1）到（3）。（1）用戶需要通過電子文檔格式登記網(wǎng)站申請。需要根據(jù)網(wǎng)站提供的格式和程序進行申請。（2）登記/申請的電子文檔需要通過管理機構(gòu)檢查來登記（3）個人電子文檔需要基于系統(tǒng)上下文來分類【表28】圖25示出了利用電子文檔格式寄存器的過程的基本流程。具體地，圖25A示出了電子文檔格式寄存器與流通客戶端直接連接，且圖25B示出了使用電子文檔格式寄存器網(wǎng)站。在以下表29中，描述利用直接連接到流通客戶端的表格的過程?！颈?9】在以下表30中，描述利用電子文檔格式寄存器網(wǎng)站的過程?！颈?0】下文中，將描述協(xié)定的電子文檔格式的使用。使用協(xié)定的電子文檔格式以流通為企業(yè)操作的網(wǎng)站中的特定企業(yè)指定的格式，以和與特定企業(yè)相關(guān)的各方做生意。圖26示出了使用協(xié)定的電子文檔格式的過程，且與圖26相關(guān)的過程將在以下表31中描述?！颈?1】【垃圾消息處理過程】在流通系統(tǒng)中，發(fā)送方通過認(rèn)證的流通通訊服務(wù)器執(zhí)行發(fā)送，且接收方通過認(rèn)證的流通通訊服務(wù)器執(zhí)行接收。因此，如果發(fā)送垃圾郵件，那么流通系統(tǒng)具有使發(fā)送方負責(zé)的基礎(chǔ)設(shè)施。然而，特定發(fā)送方可在電子文檔提供商中建立用戶賬戶，且使用用戶賬戶發(fā)送商業(yè)信息。當(dāng)前驗證方法只可驗證系統(tǒng)的技術(shù)內(nèi)容，使得在初級階段難以根除垃圾消息。為了阻止垃圾消息流通，流通系統(tǒng)提供基于認(rèn)證名單管理的白名單或者具有惡意企圖的黑名單（諸如垃圾郵件），以提高流通系統(tǒng)的安全性和可靠性。報告垃圾消息并確認(rèn)發(fā)送方的功能為基本功能。因此，所有流通通訊服務(wù)器必須建立所述功能。下文中，將描述報告垃圾消息的方法。垃圾消息報告過程的步驟將在以下表32中描述?！颈?2】如果接收方確定接收消息為垃圾消息，那么接收方通過圖27所示的過程將垃圾消息報告給地址目錄服務(wù)器。白名單和黑名單的作用如下：（1）白名單：僅記錄被發(fā)送流通通訊服務(wù)器認(rèn)證且正式登記的通訊服務(wù)器信息（2）黑名單：如果發(fā)送方地址登記為垃圾發(fā)送方，那么發(fā)送方登記為黑名單如果通過同一流通通訊服務(wù)器登記于黑名單中的垃圾郵件地址重復(fù)生成，那么管理機構(gòu)確定取消流通通訊服務(wù)器認(rèn)證，取消認(rèn)證以及從白名單刪除垃圾郵件地址。下文中，將描述當(dāng)接收垃圾消息時的處理方法。當(dāng)接收消息時，接收實體檢查地址目錄服務(wù)器的白名單和黑名單，以確認(rèn)發(fā)送方是否為可靠且合法的用戶，且然后確定是否拒絕接收。在接收消息時可實時檢查發(fā)送方，或者通過作為接收方的流通通訊服務(wù)器中的緩存來管理的定期檢查方法來檢查發(fā)送方。（1）實時檢查過程：接收實體在接收消息時確定發(fā)送實體的地址是否登記于地址目錄服務(wù)器中的白名單和黑名單中，且然后確定是否拒絕接收?！颈?3】圖28示出了實時檢查垃圾消息的過程。（2）定期檢查過程：接收方從地址目錄服務(wù)器定期接收白名單和黑名單，且據(jù)此自主管理和確定發(fā)送方地址是否登記于白名單和黑名單中，且然后確定是否拒絕接收消息?！颈?4】圖29示出了定期檢查過程以管理流通通訊服務(wù)器和地址目錄服務(wù)器之間的垃圾消息?！惧e誤處理過程】流通系統(tǒng)中發(fā)生的錯誤類型分為以下（1）和（2）。（1）同步響應(yīng)的錯誤發(fā)生：在同步響應(yīng)錯誤的情況下，請求方等待，直至接收到請求消息的處理結(jié)果，使得請求方立即通知錯誤（2）異步響應(yīng)的錯誤發(fā)生：請求方發(fā)送請求內(nèi)容，且隨后接收請求的處理結(jié)果，使得需要另外錯誤處理。下文中，將描述同步錯誤處理方法。因為同步發(fā)送的所有錯誤都可被發(fā)送方立即檢查到，所以基本上重新發(fā)送消息。根據(jù)參與流通系統(tǒng)的企業(yè)或者機構(gòu)的系統(tǒng)策略來確定重新發(fā)送方法。然而，基本上，如果發(fā)送相同消息，那么設(shè)定相同消息ID值來發(fā)送消息。同步錯誤處理類型為如下（1）到（4）：（1）請求消息發(fā)送失?。涸谟砂l(fā)送方發(fā)送消息的過程中發(fā)生發(fā)送錯誤，使得請求消息未發(fā)送到接收方。發(fā)送方通過發(fā)送重試的超時或者網(wǎng)絡(luò)錯誤消息來通知發(fā)送失敗。（2）響應(yīng)消息接收失敗：即使發(fā)送方正常發(fā)送消息，在從接收方接收響應(yīng)消息的過程中發(fā)生錯誤。響應(yīng)消息接收失敗沒有與（1）“請求消息發(fā)送失敗”區(qū)分開，使得通過相同方法處理錯誤，但是因為接收方正常接收請求消息，所以處理方法不同。（3）錯誤消息接收：即使發(fā)送方正常發(fā)送消息，但在由接收方處理消息的過程中發(fā)生錯誤。在此情況下，可根據(jù)錯誤消息類型，改變發(fā)送方的處理方法。（4）三級同步錯誤：其中流通客戶端通過流通通訊服務(wù)器與另一個流通通訊服務(wù)器、地址目錄服務(wù)器和流通中繼中心連接的三個實體之間的消息流通支持連接類型中的同步連接方法，以立即檢查最終結(jié)果。在這個過程中，如果在連接流通通訊服務(wù)器和接收方的步驟中發(fā)生錯誤，那么流通通訊服務(wù)器立即發(fā)生錯誤，且然后將錯誤作為響應(yīng)消息發(fā)送到流通通訊服務(wù)器。下文中，將描述異步錯誤處理方法。其中流通客戶端通過流通通訊服務(wù)器與另一個流通通訊服務(wù)器、地址目錄服務(wù)器和流通中繼中心連接的三個實體之間的消息流通可支持異步方法中的連接，使得流通客戶端根據(jù)最后接收方的情況獨立地操作。發(fā)送方可以不立即檢查異步發(fā)送的最終錯誤，異步發(fā)送不同于同步發(fā)送。因此，在最終檢查錯誤時針對流通客戶端生成錯誤消息，以允許流通客戶端接收錯誤消息?！倦娮游臋n讀取服務(wù)】電子文檔讀取服務(wù)為提供存儲于發(fā)送方系統(tǒng)或者第三方存儲機構(gòu)中待讀取的電子文檔而不是在發(fā)送方和接收方之間直接交換電子文檔的服務(wù)。電子文檔讀取服務(wù)實際上使用現(xiàn)有流通系統(tǒng)。在此情況下，發(fā)送方不是將包括電子文檔的消息，而是包括讀取存儲于發(fā)送方系統(tǒng)或者第三方存儲機構(gòu)中的電子文檔的讀取權(quán)限的消息發(fā)送到接收方。與其相關(guān)的程序為如下。（1）接收方公鑰獲得（2）電子文檔存儲（3）應(yīng)用安全性的證書創(chuàng)建，安全性諸如有讀取權(quán)限和DRM（4）讀取權(quán)限證書發(fā)送和發(fā)送確認(rèn)（5）接收方對電子文檔的讀?。?）流通（讀?。┳C書或者讀取證據(jù)的發(fā)行和存儲電子文檔讀取服務(wù)可分類為發(fā)送方使用其自己系統(tǒng)的方法和發(fā)送方使用第三方的方法。圖30示出了發(fā)送方使用利用自己系統(tǒng)的電子文檔讀取服務(wù)的流程，且圖30中示出的程序?qū)⒃谝韵卤?5中描述。【表35】為了提供上述服務(wù)，發(fā)送方需要包括能夠提供電子文檔讀取服務(wù)的系統(tǒng)以及流通系統(tǒng)。圖31示出了發(fā)送實體利用第三方來使用電子文檔讀取服務(wù)的流程，且圖31中示出的程序?qū)⒃诒?6中描述。【表36】【企業(yè)中與系統(tǒng)的連接方法】企業(yè)/機構(gòu)內(nèi)部創(chuàng)建和存儲各種電子文檔，且通過各種方法與外部企業(yè)/機構(gòu)交換電子文檔?？赏ㄟ^離線（諸如郵件）或者通過電子郵件或者工作相關(guān)系統(tǒng)來交換電子文檔。當(dāng)連接到企業(yè)/機構(gòu)內(nèi)部時，流通系統(tǒng)如表37和圖119中示出那樣相互連接?！颈?7】基于認(rèn)證電子地址的流通系統(tǒng)可通過以下方法與企業(yè)/機構(gòu)內(nèi)部連接。下文中，將描述與內(nèi)部系統(tǒng)連接的方法。當(dāng)企業(yè)或者機構(gòu)安裝流通通訊服務(wù)器并將內(nèi)部系統(tǒng)中流通客戶端開發(fā)為系統(tǒng)集成（SI）時，主要使用與內(nèi)部系統(tǒng)連接的方法。細節(jié)將在以下表38中描述，且其附圖在圖120中示出。【表38】下文中，將描述未與內(nèi)部系統(tǒng)連接的方法。未與內(nèi)部系統(tǒng)連接的方法適用于從電子文檔提供商接收用戶賬戶以使用用戶賬戶的認(rèn)證發(fā)送方/接收方，且是這樣一種方法：即，使用由電子文檔提供商提供的web型流通客戶端或者將由電子文檔提供商流通的流通客戶端應(yīng)用程序安裝于本地PC中以使用流通客戶端應(yīng)用程序的方法。細節(jié)將在以下表39中描述，且附圖在圖121中示出?！颈?9】根據(jù)web方法、用戶訪問和處理網(wǎng)站，個人用戶不需要將程序安裝于本地PC中。根據(jù)應(yīng)用程序方法，個人用戶下載安裝程序且將程序安裝于本地PC中，以訪問流通通訊服務(wù)器來使用程序。在根據(jù)如上所述的本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)和電子文檔流通方法中，為了流通電子文檔，需要諸如流通通訊服務(wù)器、流通客戶端和流通中繼服務(wù)器的組件，且在電子文檔流通的整體流程中這些組件需要相互連接。因此，這些組件被操作為相互連接，并且需要定義用于連接的通信協(xié)議、消息交換方法和連接消息結(jié)構(gòu)。下文中，定義用于組件之間連接的共同基礎(chǔ)通信協(xié)議和消息交換方法，且根據(jù)連接類型的消息結(jié)構(gòu)被定義為所建議的標(biāo)準(zhǔn)。因此，本發(fā)明允許在不同環(huán)境下且通過不同開發(fā)方法和互操作性建立的組件之間的平滑連接。【連接的基本通信協(xié)議】在基于認(rèn)證電子地址的電子文檔流通系統(tǒng)下，在組件之間流通信息和電子文檔所需的電子文檔流通連接接口中，流通連接消息是基于“ebXML消息服務(wù)v2.0標(biāo)準(zhǔn)”（下文中，稱為ebMS），且分層擴展定義為更廣義形式?；趀bXML的結(jié)構(gòu)由獨立但有密切關(guān)系的諸如SOAP、帶附件、安全性和可靠性的SOAP的元素構(gòu)成?！斑B接的基本通信協(xié)議”（下文中，基本通信協(xié)議）定義流通系統(tǒng)中基于這些基本元素所需且被構(gòu)造為元素被有機重組的形式的元素?；就ㄐ艆f(xié)議通過形成消息的封裝、消息封裝包配置、消息安全性以及發(fā)送和接收消息的消息收發(fā)來構(gòu)成。下文中，將描述基本協(xié)議配置中的消息封裝。流通連接消息的整個消息結(jié)構(gòu)應(yīng)用ebMSv2.0標(biāo)準(zhǔn)?；就ㄐ艆f(xié)議中定義的消息具有兩個邏輯MIME部分。第一MIME部分被稱為標(biāo)頭容器，且包括SOAP消息。SOAP消息由標(biāo)頭和體塊構(gòu)成。第二或者后續(xù)MIME部分被稱為凈荷容器，且包括應(yīng)用程序級消息和附加文檔。以下將詳細描述第一MIME部分。在本部分中，描述用于流通消息（消息的路由相關(guān)信息、SOAP消息交換模式、數(shù)字簽名、錯誤信息以及在第二時間添加的數(shù)據(jù)位置信息）的共同信息。第二MIME部分將對每個連接接口的請求以及響應(yīng)消息附加。根據(jù)連接接口類型，確定第三或者后續(xù)MIME部分存在性。當(dāng)使用流通系統(tǒng)交付電子文檔或者證書時，第二MIME包括在第三MIME部分中。流通連接消息的基本構(gòu)造在圖67中示出。參考圖67，（1）“SOAP-ENV：標(biāo)頭”由根據(jù)流通協(xié)議標(biāo)準(zhǔn)的消息標(biāo)頭和簽名信息構(gòu)成，（2）“SOAP-ENV：體塊”包括由流通協(xié)議標(biāo)準(zhǔn)定義的Manifest組成要素信息和用戶登錄信息，（3）“發(fā)送容器#1（凈荷容器#1）”包括請求消息和響應(yīng)消息。根據(jù)連接接口類型以及請求、響應(yīng)或者錯誤消息的存在性來定義業(yè)務(wù)文檔的詳細內(nèi)容，以及（4）在“發(fā)送容器#2（凈荷容器#2）”中，根據(jù)連接接口類型將待附加的文檔從凈荷容器#2按順序輸入。下文中，將描述基本協(xié)議配置中的消息封裝包配置。所有擴展元素的內(nèi)容需要限制于基于SOAP標(biāo)準(zhǔn)的可用名稱空間。本發(fā)明中定義的所有ebXMLSOAP擴展元素的內(nèi)容需要限制于ebXMLSOAP封裝包擴展名稱空間。名稱空間的申明可包括在SOAP封裝包、標(biāo)頭或者體塊元素中，或者直接包括在每個SOAP擴展元素中。SOAP封裝包將SOAP消息中各種名稱空間申明為SOAP消息的根項目。待申明名稱空間為如下?！颈?4】項目名稱空間URLSOAPhttp://schemas.xmlsoap.org/soap/envelope/數(shù)字簽名http://www.w3.org/2000/09/xmldsig#Xlinkhttp://www.w3.org/1999/xlinkXsihttp://www.w3.org/2001/XMLSchema-instance消息封裝包的架構(gòu)結(jié)構(gòu)在表35中示出，且消息封裝包示例將在以下表45中描述?！颈?5】SOAP標(biāo)頭元素包括擴展元素（1）到（4）作為封裝包元素的第一子元素。（1）消息標(biāo)頭：基本元素，包括消息的路由信息（至/自）以及與消息有關(guān)的其它上下文信息（2）同步應(yīng)答：指示收發(fā)消息的方法為同步的元素（3）簽名：指示SOAP消息的數(shù)字簽名值以及附加文檔的元素（4）錯誤名單：元素，當(dāng)在處理消息過程（諸如消息語法驗證和消息數(shù)字簽名驗證）中發(fā)生錯誤時，輸入錯誤的細節(jié)，以返回錯誤消息。SOAP體塊元素包括諸如Manifest的擴展元素作為SOAP封裝包的第二子元素。Manifest為指示位于不同位置（諸如凈荷容器或者web）中的數(shù)據(jù)的元素。Manifest元素需要參考凈荷容器。Manifest元素為由一個或者多個參考元素構(gòu)造的復(fù)雜元素。每個參考元素作為包括在凈荷容器中的（多個）凈荷文檔一部分被包括，或者區(qū)分與消息相關(guān)的數(shù)據(jù)，所述數(shù)據(jù)為可由URL訪問的遠程資源。建議在SOAP體塊中不加載凈荷數(shù)據(jù)。Manifest的目的為如下（1）和（2）。（1）允許容易和直接訪問與ebXML消息相關(guān)的特定凈荷（2）為了確定應(yīng)用程序是否處理凈荷而無需解析Manifest元素具有以下屬性和元素（1）到（3）。（1）一個id屬性（2）一個版本屬性（3）一個或者多個參考元素參考元素為由以下子元素（1）和（2）構(gòu)造的復(fù)雜元素。（1）0或者多個架構(gòu)元素：與（多個）架構(gòu)有關(guān)的信息，該架構(gòu)定義與父參考元素區(qū)分的即時文檔（2）0或者多個描述元素：由父參考元素引用的凈荷對象的描述參考元素為【XLINK】的簡單鏈接。XLINK為W3C的當(dāng)前候選推薦（CR）。這里，提供XLINK以闡明關(guān)聯(lián)關(guān)系的描述。根據(jù)實施要求，不一定使用XLINK過程或者引擎，但是可能有用。參考元素除上述元素的內(nèi)容之外還包括以下屬性內(nèi)容（1）到（5）。（1）id：參考元素的XMLID（2）xlink型：此屬性定義元素為XLINK簡單鏈接。本屬性具有固定值“簡單”（3）xlink：href：此基本屬性為所引用凈荷對象的URI值。此屬性是基于【XLINK】規(guī)范的簡單鏈接（4）xlink：role：此屬性區(qū)分凈荷對象或者描述凈荷對象目的的資源。如果存在此屬性，那么此屬性需要具有基于【XLINK】規(guī)范的可用URI值（5）可能存在其它有效名稱空間屬性。接收MSH可忽略外部名稱空間屬性而不是以上定義的屬性如果參考項目具有描述參考項目（例如，XML架構(gòu)、DTD或者數(shù)據(jù)庫架構(gòu)）的（多個）架構(gòu)，那么架構(gòu)元素需要作為參考元素的子元素存在。這用來區(qū)分架構(gòu)和版本，且定義由父參考元素區(qū)分的凈荷對象。架構(gòu)元素具有以下屬性（1）和（2）。（1）位置：架構(gòu)的基本URI（2）版本：架構(gòu)的版本標(biāo)識符如果xlink：href屬性包括URI，URI為內(nèi)容id（URI架構(gòu)“cid“），那么具有內(nèi)容id的MIME需要在消息的凈荷容器中表達。否則，具有MimeProbem作為errorCode的錯誤以及作為嚴(yán)重性的錯誤需要發(fā)送到發(fā)送方。如果xlink：href屬性不包括URI，URI為內(nèi)容id（URI架構(gòu)“cid“），那么不解譯URI，且因此根據(jù)實施確定是否發(fā)送錯誤。如果確定發(fā)送錯誤，那么具有MimeProbem作為errorCode的錯誤以及作為嚴(yán)重性的錯誤需要發(fā)送到發(fā)送方。以下表46表示具有一個凈荷MIME體塊部分的消息的典型Manifest。【表46】下文中，將描述基本協(xié)議配置中消息的詳細組成。消息標(biāo)頭元素為基本元素，表達在所有ebXML消息中且表達為SOAP標(biāo)頭元素的子元素。消息標(biāo)頭元素為由以下子元素構(gòu)成的復(fù)雜元素。消息標(biāo)頭的元素結(jié)構(gòu)將在以下表47中描述?！颈?7】消息標(biāo)頭的架構(gòu)結(jié)構(gòu)在圖36中示出，且消息標(biāo)頭的項目代碼表將在以下表48中描述，以及每個業(yè)務(wù)的服務(wù)/動作項目將在以下表49中描述。【表48】【表49】流通連接消息需要以數(shù)字方式簽名，以應(yīng)對在收發(fā)過程中可能發(fā)生的各種危險因素。因此，簽名元素需要作為SOAP標(biāo)頭的子元素存在。流通連接消息中的整個SOAP消息以及包括在凈荷容器中的消息和附加文檔需要為數(shù)字簽名的對象。簽名對象信息被整理為包括在數(shù)字簽名信息中。根據(jù)【XMLDSIG】標(biāo)準(zhǔn)執(zhí)行數(shù)字簽名的過程為如下（1）到（4）。（1）在SOAP封裝包中創(chuàng)建具有SignatureMethod、CanonicalizationMethod的SignedInfo元素以及參考元素和基本凈荷對象，如在【XMLDSIG】中定義的-在SignedInfo較低級處的第一參考項目具有整個SOAP消息作為目標(biāo)，使得“”在URI值中描述。-自第二參考項目，重復(fù)描述盡可能多的凈荷容器數(shù)。在此情況下，URI值描述在附加文檔的MIME標(biāo)頭中定義的內(nèi)容ID值。（整理目標(biāo)為不包括MIME標(biāo)頭的內(nèi)容部分）（2）在規(guī)范化之后，基于在SignedInfo中指定的算法計算SignedInfo的SignatureValue，如在【XMLDSIG】中指定（3）創(chuàng)建簽名元素，該簽名元素包括SignedInfo、KeyInfo和SignatureValue元素，如在【XMLDSIG】中指定（4）SOAP標(biāo)頭的簽名包括在SOAP標(biāo)頭元素中在數(shù)字簽名時使用的算法信息為如下。算法基本上遵循W3C算法部分（6.0算法），即“XML簽名語法和處理”（RFC3275）。此外，為了支持國內(nèi)獨特算法，使用在TTAS.IF-RFC3075“XML-簽名語法和處理”（電信技術(shù)協(xié)會，2004年）中定義的算法。接著，將描述用在流通協(xié)議中的算法列表。為了在收發(fā)消息時盡量減少數(shù)字簽名創(chuàng)建和驗證過程中的歧義，不同于以下所列（1）到（5）的算法的使用被限制。（1）數(shù)字簽名名稱空間【表52】<...xmlns:ds="http://www.w3.org/2000/09/xmldsig#"...>（2）散列（摘要）用于減少數(shù)據(jù)的算法遵守經(jīng)認(rèn)證的證明系統(tǒng)的相關(guān)規(guī)定【表53】（3）數(shù)字簽名（簽名）用于對消息進行數(shù)字簽名的算法遵守經(jīng)認(rèn)證的證明系統(tǒng)的相關(guān)規(guī)定【表54】（4）規(guī)范化；由于在物理上可不同表達邏輯相同文檔的XML的特性，數(shù)字簽名值對于相同文檔可以是不同的。為了防止以上現(xiàn)象，需要執(zhí)行規(guī)范化過程。在規(guī)范化中，使用省略注釋的規(guī)范化XML。【表55】（5）轉(zhuǎn)換；即使存在各種轉(zhuǎn)換算法作為經(jīng)過對整個XML數(shù)據(jù)中的待簽名數(shù)據(jù)進行的處理和選擇的過程的算法，但在各種轉(zhuǎn)換算法中只可使用三個算法。第一算法為封裝簽名轉(zhuǎn)換，這是因為數(shù)字簽名遵守包括在簽名目標(biāo)中的形式，第二算法為上述規(guī)范化，以及第三算法為選擇簽名目標(biāo)信息的Xpath過濾?！颈?6】當(dāng)在通信協(xié)議處理（諸如消息語法驗證或者消息數(shù)字簽名驗證）過程中發(fā)生錯誤時，在標(biāo)頭較低級中創(chuàng)建ErrorList元素且同步返回到發(fā)送方。當(dāng)生成ErrorList元素時，RefToMessageId必須存在于消息標(biāo)頭元素中，且RefToMessageId需要指定發(fā)生錯誤的消息的消息ID。ErrorList元素具有以下屬性（1）到（5）。（1）id屬性（2）SOAPmustUnderstand屬性（3）版本屬性（4）highestSeverity屬性（5）一個或者多個錯誤元素如果沒有錯誤報告，那么應(yīng)當(dāng)不存在ErrorList元素。ErrorList的結(jié)構(gòu)在圖38中示出。highestSeverity屬性指示所有錯誤元素的最嚴(yán)重狀態(tài)。具體地，如果錯誤元素設(shè)定嚴(yán)重性為錯誤，那么highestSeverity設(shè)定為錯誤。否則，highestSeverity設(shè)定為警告。錯誤元素具有以下屬性（1）到（6）。（1）id屬性；id屬性用于唯一區(qū)分文檔中的ErrorList元素。（2）codeContext屬性；codeContext屬性表示名稱空間或者錯誤代碼的架構(gòu)，且應(yīng)當(dāng)為URI。此屬性的默認(rèn)值為urn：oasis：names：tc：ebxml-msg：service：errors。如果此屬性中沒有默認(rèn)值，那么規(guī)范實施指示使用錯誤代碼。（3）錯誤代碼屬性；基本錯誤代碼屬性指示具有錯誤的消息的錯誤本質(zhì)（4）嚴(yán)重性屬性；作為基本屬性的嚴(yán)重性屬性指示錯誤嚴(yán)重性。有效值為警告和錯誤。警告指示在轉(zhuǎn)換過程中通常創(chuàng)建其它消息，而不管錯誤如何。錯誤指示在消息中存在不可恢復(fù)錯誤且在轉(zhuǎn)換過程中不再創(chuàng)建其它消息。（5）位置屬性；位置屬性指示存在錯誤的消息部分。如果錯誤存在于ebXML元素中且元素為“well-formed”，那么位置屬性的內(nèi)容需要為【Xpointer】。（6）描述屬性；描述元素的內(nèi)容通過在xml：lang屬性中定義的語言提供錯誤的描述性解釋。一般地，該消息通過驗證XML解析器或者消息的軟件來生成。這意味著，內(nèi)容由創(chuàng)建錯誤元素的軟件銷售商或者開發(fā)者定義。如果在基于流通協(xié)議進行收發(fā)消息過程中發(fā)生錯誤，那么通知錯誤的收發(fā)實體需要將錯誤通知給其他方。待報告錯誤包括消息結(jié)構(gòu)錯誤、通訊錯誤和安全性錯誤。與屬于比本發(fā)明中定義的流通協(xié)議更低層的數(shù)據(jù)通信協(xié)議（諸如HTTP和Socket）相關(guān)的錯誤需要通過由數(shù)據(jù)通信協(xié)議支持的標(biāo)準(zhǔn)機制發(fā)現(xiàn)和報告，且不使用在本發(fā)明中定義的錯誤報告機制。錯誤代碼根據(jù)錯誤目標(biāo)和錯誤類型來分類，且其細節(jié)將在以下表59中描述?！颈?9】下文中，將描述在HTTP綁定方法中通過HTTP進行的消息發(fā)送方法。下文中，將描述HTTP綁定方法中的HTTP響應(yīng)代碼。在本發(fā)明中，為了返回HTTP級別的響應(yīng)代碼，需要使用在【RFC2616】中定義的HTTP響應(yīng)代碼。主要響應(yīng)代碼將在以下表61中描述?！颈?1】下文中，將描述HTTP綁定方法中的HTTP發(fā)送安全性方法。流通系統(tǒng)中流通通訊服務(wù)器和流通通訊服務(wù)器之間的發(fā)送或者流通通訊服務(wù)器和流通客戶端之間的發(fā)送需要使用HTTP/S（安全超文本傳輸協(xié)議）來處理，HTTP/S必須使用SSL（安全套接字層）V3.0用于網(wǎng)絡(luò)發(fā)送安全。在根據(jù)本發(fā)明的流通系統(tǒng)中發(fā)生的錯誤類型大致分為同步響應(yīng)錯誤發(fā)生和異步響應(yīng)錯誤發(fā)生。在同步響應(yīng)錯誤的情況下，請求方等待，直至接收到請求消息的處理結(jié)果，使得請求方立即意識到錯誤。與之相比，在異步響應(yīng)錯誤的情況下，只有在交付請求內(nèi)容之后請求方才接收到處理結(jié)果，使得需要另外錯誤處理。下文中，將描述錯誤處理方法中的同步錯誤處理方法。通訊服務(wù)器、其它流通通訊服務(wù)器、地址目錄服務(wù)器、流通客戶端和流通中繼服務(wù)器中兩個流通實體之間的所有消息流通為同步流通。此外，根據(jù)連接類型，其中流通客戶端通過一流通通訊服務(wù)器連接到其它流通通訊服務(wù)器、地址目錄服務(wù)器和流通中繼服務(wù)器的三個實體之間的消息流通為同步或者異步連接。所有同步發(fā)送錯誤可由發(fā)送方立即檢查到，使得根本上重新發(fā)送消息。根據(jù)參與流通系統(tǒng)的企業(yè)或者機構(gòu)的系統(tǒng)策略來確定重新發(fā)送方法。然而，根本上，通過設(shè)定相同消息ID值再次發(fā)送相同消息。通過利用相同消息ID發(fā)送消息，不僅在發(fā)送時發(fā)生錯誤時，而且在接收方成功接收消息之后同步發(fā)送響應(yīng)消息過程中發(fā)生錯誤時，通知冗余消息以防止冗余處理相同請求。根據(jù)連接類型，同步錯誤發(fā)送方和接收方可為流通通訊服務(wù)器、地址目錄服務(wù)器、流通客戶端和流通中繼服務(wù)器。（1）錯誤消息發(fā)送失?。寒?dāng)發(fā)送方發(fā)送消息時發(fā)生發(fā)送錯誤，使得請求消息未交付給接收方。發(fā)送方通過發(fā)送重試超時或者網(wǎng)絡(luò)錯誤消息來識別發(fā)送失敗。圖39示出了當(dāng)請求消息發(fā)送失敗時的過程，且處理程序為如下1）到3）。1）在由消息發(fā)送方發(fā)送過程中發(fā)生發(fā)送錯誤。在大多數(shù)情況下，這個錯誤由網(wǎng)絡(luò)錯誤導(dǎo)致2）如果發(fā)送方接收到錯誤消息，諸如HTTP錯誤，那么發(fā)送方請求需要重新發(fā)送相同消息3）只有當(dāng)從接收方接收到接收確認(rèn)消息時，發(fā)送方才認(rèn)可發(fā)送成功。（2）響應(yīng)消息接收失敗：即使發(fā)送方正常發(fā)送消息，當(dāng)從接收方接收響應(yīng)消息時也會發(fā)生錯誤。在發(fā)送方位置，響應(yīng)消息接收失敗與（1）的請求消息發(fā)送失敗不區(qū)分，使得通過相同方法處理錯誤。然而，因為接收方正常接收請求消息，所以處理方法不同于發(fā)送方的處理方法。圖42示出了與響應(yīng)消息接收失敗相關(guān)的過程，且處理程序?qū)⒚枋鰹槿缦?）到3）。1）即使消息正常交付給接收方，但發(fā)送方從接收方未接收到接收確認(rèn)消息時2）在此情況下，發(fā)送方識別為發(fā)送失敗錯誤，且利用相同消息ID將相同消息重新發(fā)送到接收方3）如果所接收文檔的消息ID與先前所接收消息相同，那么接收方發(fā)送指示冗余接收的接收確認(rèn)消息且內(nèi)部處理消息。（3）錯誤消息接收：即使發(fā)送方正常發(fā)送消息，當(dāng)接收發(fā)送消息的接收方處理消息時發(fā)生錯誤。在此情況下，根據(jù)錯誤消息類型，改變發(fā)送方的處理方法。關(guān)于通信協(xié)議的錯誤類型是指上述“ErrorList”項目。此外，在對每個連接接口的請求消息進行內(nèi)部處理過程中發(fā)生的錯誤是指連接接口的消息結(jié)構(gòu)。圖41示出了與錯誤消息接收相關(guān)的過程，且處理程序為如下1）到3）。1）即使將發(fā)送到接收方的消息正確地交付，但在發(fā)送消息錯誤而導(dǎo)致接收到錯誤消息時2）在此情況下，一般地，發(fā)送方重新創(chuàng)建請求消息且然后重新發(fā)送消息。然而，根據(jù)錯誤類型，可改變消息處理3）當(dāng)發(fā)送方重新發(fā)送請求消息時，待發(fā)送消息的消息ID不需要與先前消息相同且根據(jù)任務(wù)情況不同地處理。（4）三級同步錯誤：在流通客戶端通過流通通訊服務(wù)器連接到其它另一個流通通訊服務(wù)器、地址目錄服務(wù)器和流通中繼中心的三個實體之間的消息流通支持連接方法中的同步連接方法，以立即檢查最終結(jié)果。在這個過程期間，如果在流通通訊服務(wù)器和接收方的連接步驟中發(fā)生錯誤，那么流通通訊服務(wù)器立即生成錯誤，且然后將錯誤作為響應(yīng)消息發(fā)送到其它另一個流通通訊服務(wù)器。圖42示出了與三級同步錯誤相關(guān)的過程，且處理程序為如下1）到3）。1）即使在流通客戶端在與流通通訊服務(wù)器連接時發(fā)送消息的過程中發(fā)送成功，但在發(fā)送消息到流通通訊服務(wù)器附近的接收方（地址目錄服務(wù)器、其它流通通訊服務(wù)器或者流通中繼服務(wù)器）的過程中也會發(fā)生錯誤2）在此情況下，錯誤是指在流通通訊服務(wù)器和接收方之間同步發(fā)送期間發(fā)生的所有錯誤3）在流通通訊服務(wù)器通知錯誤并將錯誤消息作為響應(yīng)消息交付給流通客戶端時，流通通訊服務(wù)器生成針對流通客戶端的錯誤消息由流通通訊服務(wù)器創(chuàng)建的錯誤消息用以下表62的結(jié)構(gòu)構(gòu)造。【表62】下文中，將描述錯誤處理方法中的異步錯誤處理方法。其中流通客戶端通過流通通訊服務(wù)器連接到其它另一個流通通訊服務(wù)器、地址目錄服務(wù)器和流通中繼服務(wù)器的三個實體之間的消息流通支持連接方法中適用于最終接收方情況的異步連接方法。異步發(fā)送的最終錯誤可不由發(fā)送方立即檢查，異步發(fā)送不同于同步發(fā)送。因此，在流通通訊服務(wù)器最終檢查到錯誤且允許流通客戶端接收錯誤消息時，流通通訊服務(wù)器生成針對流通客戶端的錯誤消息。圖43示出了與異步錯誤處理方法相關(guān)的過程，且處理方法為如下1）到4）。1）即使在流通客戶端與流通通訊服務(wù)器連接的情況下發(fā)送消息的過程中發(fā)送成功，但在發(fā)送消息到流通通訊服務(wù)器附近的接收方（地址目錄服務(wù)器、其它另一個流通通訊服務(wù)器或者流通中繼服務(wù)器）的過程中也發(fā)生錯誤2）在此情況下，錯誤是指在流通通訊服務(wù)器和接收方之間的同步發(fā)送期間發(fā)生的所有錯誤3）在重試之后最終識別錯誤且然后將錯誤消息交付給流通客戶端郵箱時，流通通訊服務(wù)器生成針對流通客戶端的錯誤消息4）流通客戶端通過接收在其郵箱中的錯誤消息將先前請求消息的錯誤在請求接收消息的過程中通知給流通通訊服務(wù)器由流通通訊服務(wù)器生成的錯誤消息由以下表63的結(jié)構(gòu)構(gòu)造?！颈?3】【流通通訊服務(wù)器和地址目錄服務(wù)器之間的連接接口】地址目錄服務(wù)器為管理經(jīng)認(rèn)證的電子郵件地址的系統(tǒng)，認(rèn)證的電子郵件地址在流通系統(tǒng)中是非?；镜那以陔娮游臋n流通中是不可避免地為必要的。流通通訊服務(wù)器和地址目錄服務(wù)器之間的連接接口大致分為兩個功能。第一功能為與登記機構(gòu)的認(rèn)證電子郵件地址的登記任務(wù)相關(guān)的接口，第二功能為與流通通訊服務(wù)器物理地址查詢/響應(yīng)并報告垃圾郵件的任務(wù)相關(guān)的接口。用于登記機構(gòu)的認(rèn)證電子郵件地址的登記任務(wù)的接口可分離。然而，電子文檔提供商或者第三方存儲機構(gòu)服務(wù)器為登記機構(gòu)，使得接口功能插入在流通通訊服務(wù)器中。在此情況下，在設(shè)置于收發(fā)實體中的流通通訊服務(wù)器中，未插入與認(rèn)證電子郵件地址登記相關(guān)的連接接口。流通通訊服務(wù)器和地址目錄服務(wù)器之間的接口功能將在以下表64中描述?！颈?4】下文將描述流通通訊服務(wù)器和地址目錄服務(wù)器之間的接口的詳細信息。首先，流通通訊服務(wù)器和地址目錄服務(wù)器之間的接口的共同事實為如下（1）和（2）。（1）請求消息的消息標(biāo)頭擴展發(fā)送實體的數(shù)字簽名信息需要被交付，以包括在從發(fā)送實體的流通通訊服務(wù)器發(fā)送到地址目錄服務(wù)器的請求消息的第一MIME部分的SOAP消息中。此外，地址目錄服務(wù)器驗證用于SOAP消息數(shù)字簽名的證書擁有者是否與發(fā)送實體匹配（VID驗證）所需的發(fā)送實體的附加信息（CorpNum、RValue）也被交付以包括在其中。發(fā)送實體的附加信息需要作為擴展元素位于請求消息的SOAP消息中消息標(biāo)頭元素的較低級處（任何##其它位置）。擴展元素結(jié)構(gòu)將在以下表65中描述?！颈?5】（2）整個消息結(jié)構(gòu)在流通通訊服務(wù)器和地址目錄服務(wù)器之間的連接接口中，SOAP消息位于消息的第一MIME部分，且請求和響應(yīng)的流通消息位于第二MIME部分。流通通訊服務(wù)器和地址目錄服務(wù)器之間的SOAP結(jié)構(gòu)在圖44中示出。下文中，將描述在流通通訊服務(wù)器和地址目錄服務(wù)器之間接口中，認(rèn)證電子郵件地址的登記。與認(rèn)證電子郵件地址登記相關(guān)的消息交換流程在圖45中示出。請求流通消息結(jié)構(gòu)將在以下表67中描述?！颈?7】響應(yīng)流通消息的結(jié)構(gòu)將在以下表69中描述?！颈?9】下文中，將描述在介于流通通訊服務(wù)器和地址目錄服務(wù)器之間的接口中，變更認(rèn)證電子郵件地址信息的接口。變更認(rèn)證電子郵件地址信息的接口為允許電子文檔提供商請求地址目錄服務(wù)器變更登記于地址目錄服務(wù)器中的認(rèn)證發(fā)送方/接收方的認(rèn)證電子郵件地址且接收響應(yīng)的接口。在發(fā)送包括待變更的用戶信息和認(rèn)證電子郵件地址信息的請求消息之后，電子文檔提供商接收地址目錄服務(wù)器的變更結(jié)果作為響應(yīng)消息。與認(rèn)證電子郵件地址變更過程相關(guān)的消息交換流程在圖46中示出。請求流通消息結(jié)構(gòu)將在以下表71中描述?！颈?1】響應(yīng)流通消息的結(jié)構(gòu)將在以下表73中描述?！颈?3】在圖73中，如果ResultCode輸入為失?。?），那么與錯誤原因?qū)?yīng)的錯誤代碼輸入為ErrorCode。下文中，將描述在介于流通通訊服務(wù)器和地址目錄服務(wù)器之間的接口中，刪除認(rèn)證電子郵件地址信息的接口。刪除認(rèn)證電子郵件地址信息的接口為允許電子文檔提供商請求地址目錄服務(wù)器刪除登記于地址目錄服務(wù)器中的認(rèn)證發(fā)送方/接收方的認(rèn)證電子郵件地址信息且接收響應(yīng)的接口。在發(fā)送包括待刪除的用戶信息和認(rèn)證電子郵件地址信息的請求消息之后，電子文檔提供商接收地址目錄服務(wù)器的刪除結(jié)果作為響應(yīng)消息。與認(rèn)證電子郵件地址的刪除過程相關(guān)的消息交換流程在圖47中示出。請求流通消息結(jié)構(gòu)將在以下表75中描述?！颈?5】響應(yīng)流通消息的結(jié)構(gòu)將在以下表77中描述?！颈?7】在圖114中，如果ResultCode輸入為失敗（0），那么與錯誤原因?qū)?yīng)的錯誤代碼輸入為ErrorCode。下文中，將描述在介于流通通訊服務(wù)器和地址目錄服務(wù)器之間的接口中，搜索物理地址信息的接口。搜索物理地址信息的接口為允許電子文檔提供商或者收發(fā)實體請求地址目錄服務(wù)器，以請求與電子文檔接收方的認(rèn)證電子郵件地址信息對應(yīng)的物理地址信息且接收響應(yīng)的接口。在發(fā)送包括電子文檔接收方的認(rèn)證電子郵件地址的請求消息以及證書請求之后，電子文檔提供商從地址目錄服務(wù)器接收電子文檔接收方的物理地址信息（IP地址或者域名地址）以及證書信息作為響應(yīng)消息。與物理地址信息搜索過程相關(guān)的消息交換流程在圖48中示出。請求流通消息結(jié)構(gòu)將在以下表79中描述?！颈?9】響應(yīng)流通消息的結(jié)構(gòu)將在以下表81中描述?！颈?1】下文中，將描述在介于流通通訊服務(wù)器和地址目錄服務(wù)器之間接口中，報告垃圾消息的接口。報告垃圾消息的接口為允許電子文檔提供商或者收發(fā)實體將垃圾消息報告給地址目錄服務(wù)器的接口。在發(fā)送包括垃圾發(fā)送方的認(rèn)證電子郵件地址以及垃圾消息信息的請求消息之后，接口從地址目錄服務(wù)器接收是否接受垃圾報告作為響應(yīng)消息。如果有關(guān)所報告垃圾消息是否為垃圾的確定完成，那么地址目錄服務(wù)器使用介于流通通訊服務(wù)器之間連接接口的“消息發(fā)送”接口通知處理結(jié)果。與垃圾消息報告和接受過程相關(guān)的消息交換流程在圖49中示出。請求流通消息的結(jié)構(gòu)將在以下表83中描述?！颈?3】響應(yīng)流通消息的結(jié)構(gòu)將在以下表85中描述。【表85】在表85中，請注意，ResultCode為垃圾報告消息的簡單接受處理結(jié)果。下文中，將描述在介于流通通訊服務(wù)器和地址目錄服務(wù)器之間接口中，通知白名單的接口。通知白名單的接口為將白名單（收發(fā)實體名單以及參與流通系統(tǒng)的發(fā)送方/接收方的認(rèn)證電子郵件地址）通知給收發(fā)實體的接口。與白名單通知相關(guān)的消息交換流程在圖50中示出。請求流通消息結(jié)構(gòu)將在以下表87中描述。【表87】響應(yīng)流通消息的結(jié)構(gòu)將在以下表89中描述?！颈?9】在表89中，請注意，ResultCode為垃圾報告消息的簡單接受處理結(jié)果。下文中，將描述在介于流通通訊服務(wù)器和地址目錄服務(wù)器之間接口中，通知黑名單的接口。通知黑名單（接收拒絕名單）的接口為將黑名單通知給收發(fā)實體的接口。通知的黑名單用于由收發(fā)實體管理黑名單。與黑名單通知相關(guān)的消息交換流程在圖84中示出。請求流通消息結(jié)構(gòu)將在以下表91中描述?！颈?1】響應(yīng)流通消息的結(jié)構(gòu)將在以下表93中描述?！颈?3】【流通通訊服務(wù)器之間的連接接口】流通通訊服務(wù)器根本上與由其它收發(fā)實體或者其它電子文檔提供商建立的流通通訊服務(wù)器連接，以發(fā)送/接收消息。除以上基本功能外，流通通訊服務(wù)器具有在第三方存儲機構(gòu)提供商的流通通訊服務(wù)器與其它通訊服務(wù)器之間傳送流通證書以將流通證書存儲于第三方存儲機構(gòu)中的連接功能。流通通訊服務(wù)器之間的連接接口為用于在通訊服務(wù)器之間發(fā)送/接收消息和流通證書的協(xié)議，且被分類為以下表95中描述的接口。【表95】下文將描述流通通訊服務(wù)器之間接口的詳細信息。首先，流通通訊服務(wù)器之間接口的共同事實為如下（1）。（1）請求和響應(yīng)消息的消息標(biāo)頭擴展發(fā)送方的數(shù)字簽名信息需要交付以包括在SOAP消息中，所述SOAP消息為流通通訊服務(wù)器之間的連接接口的消息的第一MIME部分。此外，驗證用于SOAP消息數(shù)字簽名的證書擁有者是否與發(fā)送方匹配（VID驗證）所需的發(fā)送方的附加信息（CorpNum、RValue）也被交付以包括在其中。發(fā)送方的附加信息需要作為擴展元素位于請求和響應(yīng)消息的SOAP消息中消息標(biāo)頭元素的較低級處（任何##其它位置）。擴展元素結(jié)構(gòu)將在以下表96中描述?！颈?6】下文中，將描述介于流通通訊服務(wù)器之間接口中的消息發(fā)送接口。當(dāng)一個流通通訊服務(wù)器發(fā)送消息到另一個流通通訊服務(wù)器時，使用消息發(fā)送接口。消息發(fā)送接口的消息結(jié)構(gòu)在圖85中示出。交換消息時的請求格式在圖53中示出。在如圖53所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，請求流通消息位于第二MIME部分中，以及由用戶附加的文檔位于第三或者后續(xù)MIME部分中。請求流通消息結(jié)構(gòu)將在以下表98中描述?！颈?8】在表98中，如果為了交付文檔，體塊沒有必要，那么文本可省略。交換消息時的響應(yīng)格式在圖87中示出。在如圖87所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，響應(yīng)流通消息位于第二MIME部分中，以及接收證書位于第三MIME部分中。如果在處理請求消息過程中發(fā)生錯誤，那么不產(chǎn)生第三MIME部分。響應(yīng)流通消息結(jié)構(gòu)將在以下表100中描述?！颈?00】在表100中，如果DocType為錯誤（9），那么不產(chǎn)生接收證書所位于的第三MIME部分。下文中，將描述介于流通通訊服務(wù)器之間的接口中的流通證書交付接口。當(dāng)流通通訊服務(wù)器發(fā)送讀取證書到另一個流通通訊服務(wù)器時，使用流通證書交付接口。此外，當(dāng)流通中繼服務(wù)器接收發(fā)送電子文檔到接收流通通訊服務(wù)器的請求且然后發(fā)送所接收到的接收證書到發(fā)送請求流通通訊服務(wù)器作為響應(yīng)消息時，使用流通證書發(fā)送接口。與流通證書交付處理相關(guān)的消息交換流程在圖88中示出。流通證書交付請求格式在圖89中示出。在如圖89所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，請求流通消息位于第二MIME部分中，以及流通證書位于第三MIME部分中。請求流通消息結(jié)構(gòu)將在以下表102中描述?！颈?02】流通證書發(fā)送響應(yīng)格式在圖90和91中示出（圖90示出了在成功情況下的流通證書發(fā)送響應(yīng)，圖91示出了失敗情況下的流通證書發(fā)送響應(yīng)）。在如圖57所示的整個消息結(jié)構(gòu)中，如果請求消息處理成功，那么僅接收確認(rèn)ACKSOAP消息位于第一MIME部分中。在錯誤情況下，SOAP消息位于第一MIME部分中，且錯誤響應(yīng)消息位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表104中描述。表104僅對應(yīng)處理結(jié)果失敗時。【表104】下文中，將描述介于流通通訊服務(wù)器之間的接口中的流通證書存儲請求接口。當(dāng)收發(fā)實體的流通通訊服務(wù)器請求第三方存儲機構(gòu)的流通通訊服務(wù)器存儲流通證書以將流通證書存儲于第三方存儲機構(gòu)中時，使用流通證書存儲請求接口。在接口中的響應(yīng)消息中，僅包括接收確認(rèn)信息。作為流通證書存儲于第三方存儲機構(gòu)中的結(jié)果所發(fā)行的初始登記證書，通過使用將在下文描述的第三方存儲機構(gòu)存儲結(jié)果交付接口交付到存儲請求流通通訊服務(wù)器。與流通證書存儲請求處理相關(guān)的消息交換流程在圖92中示出。流通證書存儲請求格式在圖93中示出。在如圖93所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，請求流通消息位于第二MIME部分中，以及流通證書位于第三MIME部分中。請求流通消息結(jié)構(gòu)將在以下表105中描述?！颈?05】流通證書存儲響應(yīng)格式在圖94和95中示出（圖94示出了成功情況下的流通證書存儲響應(yīng)，圖95示出了失敗情況下的流通證書存儲響應(yīng)）。在如圖94和95所示的整個消息結(jié)構(gòu)中，如果請求消息的處理成功，那么僅接收確認(rèn)ACKSOAP消息位于第一MIME部分中。在錯誤情況下，SOAP消息位于第一MIME部分中，且錯誤響應(yīng)消息位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表107中描述。表107僅對應(yīng)處理結(jié)果失敗時?！颈?07】下文中，將描述介于流通通訊服務(wù)器之間接口中的第三方存儲機構(gòu)存儲結(jié)果交付接口。當(dāng)?shù)谌酱鎯C構(gòu)提供商的流通通訊服務(wù)器將流通證書存儲于第三方存儲機構(gòu)中且然后將作為結(jié)果所接收的初始登記證書發(fā)送到請求存儲流通證書的流通通訊服務(wù)器時，使用第三方存儲機構(gòu)存儲結(jié)果交付接口。與第三方存儲機構(gòu)存儲結(jié)果交付處理相關(guān)的消息交換流程在圖96中示出。第三方存儲機構(gòu)存儲結(jié)果交付格式在圖97中示出。在如圖97所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，請求流通消息位于第二MIME部分中，以及第一登記證書位于第三MIME部分中。如果在將流通證書存儲于第三方存儲機構(gòu)的過程中發(fā)生錯誤，那么不產(chǎn)生第三MIME部分。請求流通消息結(jié)構(gòu)將在以下表108中描述?！颈?08】在表108中，如果DocType為錯誤（9），那么不產(chǎn)生初始登記證書位于的第三MIME部分。第三方存儲機構(gòu)存儲結(jié)果響應(yīng)格式在圖98和99中示出（圖98示出了成功情況下的流通證書發(fā)送響應(yīng)，圖99示出了失敗情況下的流通證書發(fā)送響應(yīng)）。在如圖98和99所示的整個消息結(jié)構(gòu)中，如果請求消息處理成功，那么僅接收確認(rèn)ACKSOAP消息位于第一MIME部分中。在錯誤情況下，SOAP消息位于第一MIME部分中，且錯誤響應(yīng)消息位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表110中描述。表110僅對應(yīng)處理結(jié)果失敗時?！颈?10】【流通客戶端和流通通訊服務(wù)器之間的連接接口】流通通訊服務(wù)器與請求實際電子文檔流通的用戶（內(nèi)部發(fā)送方/接收方或者認(rèn)證發(fā)送方/接收方）的系統(tǒng)（流通客戶端）連接，并需要為用戶提供基本文檔收發(fā)功能。流通客戶端和流通通訊服務(wù)器之間的連接接口為允許流通客戶端首先與流通通訊服務(wù)器通信以發(fā)送和接收電子文檔的協(xié)議，且分類為如以下表111中描述的接口。【表111】下文將描述流通客戶端和流通通訊服務(wù)器之間接口的細節(jié)。首先，流通客戶端和流通通訊服務(wù)器之間連接接口的共同事實為如下（1）。（1）請求消息的消息標(biāo)頭擴展用戶的數(shù)字簽名信息需要交付以包括在SOAP消息中，所述SOAP消息為從流通客戶端發(fā)送到流通通訊服務(wù)器的請求消息的第一MIME部分。此外，驗證用于SOAP消息數(shù)字簽名的證書擁有者是否與對應(yīng)用戶匹配（VID驗證）所需的附加用戶信息（IDN、RValue）也被交付以包括在其中。對應(yīng)信息需要作為擴展元素位于請求消息的SOAP消息中消息標(biāo)頭元素的較低級處（任何##其它位置）。此外，將添加對于使用相同證書的多個內(nèi)部用戶的個人認(rèn)證信息。擴展元素結(jié)構(gòu)將在以下表112中描述。【表112】下文中，將描述介于流通客戶端和流通通訊服務(wù)器之間連接接口中的消息發(fā)送請求接口。當(dāng)流通客戶端發(fā)送消息到流通通訊服務(wù)器以通過流通通訊服務(wù)器發(fā)送消息時，使用消息發(fā)送請求接口。流通客戶端的消息發(fā)送處理流程在圖100中示出。流通客戶端的消息發(fā)送請求格式在圖101中示出。在如圖101所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且請求流通消息位于第二MIME部分中。如果存在由用戶附加的文檔，那么文檔位于第三或者后續(xù)MIME部分中。請求流通消息結(jié)構(gòu)將在以下表114中描述。【表114】在表114中，如果為了交付文檔的目的，體塊沒有必要，那么文本可省略。流通客戶端消息發(fā)送響應(yīng)格式在圖102和103中示出（圖102示出了成功情況下的流通證書發(fā)送響應(yīng)，圖103示出了失敗情況下的流通證書發(fā)送響應(yīng)）。在如圖102和103所示的整個消息結(jié)構(gòu)中，如果請求消息處理成功，那么僅接收確認(rèn)ACKSOAP消息位于第一MIME部分中。在錯誤情況下，SOAP消息位于第一MIME部分中，且錯誤響應(yīng)消息位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表116中描述。表116對應(yīng)只有當(dāng)處理結(jié)果失敗時?！颈?16】下文中，將描述介于流通客戶端和流通通訊服務(wù)器之間的連接接口中的消息列表請求接口。當(dāng)流通客戶端請求在流通通訊服務(wù)器中接收到的消息列表時，使用消息列表請求接口。流通客戶端的消息列表處理流程在圖67中示出。流通客戶端的消息列表請求格式在圖105中示出。在如圖105所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且請求流通消息位于第二MIME部分中。請求流通消息結(jié)構(gòu)將在以下表117中描述?！颈?17】流通客戶端的消息列表響應(yīng)格式在圖67中示出。在如圖67所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且響應(yīng)流通消息（在流通通訊服務(wù)器中接收的流通消息的列表）位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表119中描述。【表119】下文中，將描述在介于流通客戶端和流通通訊服務(wù)器之間連接接口中的消息詳細信息請求接口。當(dāng)流通客戶端請求由流通通訊服務(wù)器接收的特定消息和附加文檔時，使用消息詳細信息請求接口。流通客戶端的詳細信息請求處理流程在圖106中示出。流通客戶端的消息詳細信息請求格式在圖70中示出。在如圖70所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且請求流通消息的體塊位于第二MIME部分中。請求流通消息結(jié)構(gòu)將在以下表121中描述?！颈?21】消息詳細信息響應(yīng)格式在圖109中示出。在如圖109所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且響應(yīng)流通消息（流通消息的詳細信息）位于第二MIME部分中。如果存在附加文檔，那么附加文檔依次位于第三或者后續(xù)MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表123中描述?！颈?23】下文中，將描述在介于流通客戶端和流通通訊服務(wù)器之間連接接口中的垃圾消息報告接口。當(dāng)流通客戶端將垃圾消息報告給流通通訊服務(wù)器時，使用垃圾消息報告接口。流通通訊服務(wù)器將垃圾消息報告給地址目錄服務(wù)器，且然后將結(jié)果交付給流通客戶端。流通客戶端的垃圾消息報告處理流程在圖73中示出。流通客戶端的垃圾消息報告格式在圖111中示出。在如圖74所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且請求流通消息位于第二MIME部分中。請求流通消息結(jié)構(gòu)將在以下表125中描述?！颈?25】流通客戶端的垃圾消息響應(yīng)格式在圖112中示出。在如圖112所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且響應(yīng)流通消息（在流通通訊服務(wù)器中接收到的流通消息列表）位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表127中描述?！颈?27】在表127中，請注意，ResultCode指示垃圾報告消息的簡單接受結(jié)果。下文中，將描述在介于流通客戶端和流通通訊服務(wù)器之間連接接口中的物理地址搜索接口。當(dāng)流通客戶端請求流通通訊服務(wù)器搜索物理地址時，使用物理地址搜索接口。流通通訊服務(wù)器搜索物理地址，且然后將結(jié)果交付給地址目錄服務(wù)器。與物理地址搜索處理相關(guān)的消息交換流程在圖113中示出。物理地址搜索請求格式在圖114中示出。在如圖114所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且請求流通消息位于第二MIME部分中。請求流通消息結(jié)構(gòu)將在以下表129中描述?！颈?29】物理地址搜索響應(yīng)格式在圖115中示出。在如圖115所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且響應(yīng)流通消息（在流通通訊服務(wù)器中接收的流通消息列表）位于第二MIME部分中。響應(yīng)流通消息結(jié)構(gòu)將在以下表131中描述?！颈?31】請注意，甚至在對于多個RAddress中一些或者全部正常進行搜索時，但是發(fā)生不存在地址錯誤時，ResultCode輸入為成功（1），這與另一個接口不同。*RAddress被描述為，不管ResultCode成功（1）/失?。?）以及是否存在RAddress，RAddress輸入在IsExit中，IsExit為屬性信息。*當(dāng)IsExit值為存在（1）時，輸入Endpoint和Cert*由于請求消息錯誤而不解析RAddress，RAddress可省略（因此，Endpoint和Cert將省略）*如果ResultCode輸入為失敗（0），即，發(fā)生不同于不存在地址錯誤的其他錯誤，那么ErrorCode輸入與錯誤原因?qū)?yīng)的錯誤代碼【流通通訊服務(wù)器和流通中繼服務(wù)器之間的連接接口】流通中繼服務(wù)器為當(dāng)在電子文檔流通系統(tǒng)中流通通訊服務(wù)器之間直接發(fā)送電子文檔的過程中發(fā)生錯誤，使得發(fā)送失敗時，通過發(fā)送流通通訊服務(wù)器的代理服務(wù)器發(fā)送電子文檔的系統(tǒng)。流通中繼服務(wù)器由國家工業(yè)促進局管理，且當(dāng)在P2P流通過程中發(fā)生錯誤時，可支持與流通中繼服務(wù)器連接的所有流通通訊服務(wù)器。流通通訊服務(wù)器和流通中繼服務(wù)器之間的連接接口為允許流通通訊服務(wù)器請求流通中繼服務(wù)器發(fā)送電子文檔的協(xié)議，且分類為以下表133中描述的接口?！颈?33】首先，流通通訊服務(wù)器和流通中繼服務(wù)器之間連接接口的共同事實如下（1）。（1）請求消息的消息標(biāo)頭擴展流通通訊服務(wù)器的數(shù)字簽名信息需要交付以包括在SOAP消息中，所述SOAP消息為介于流通通訊服務(wù)器和流通中繼服務(wù)器之間的連接接口的第一MIME部分。此外，流通通訊服務(wù)器驗證用于SOAP消息數(shù)字簽名的證書擁有者是否與對應(yīng)通訊服務(wù)器匹配（VID驗證）所需的流通通訊服務(wù)器的附加信息（CorpNum、RValue）也被交付以包括在其中。流通通訊服務(wù)器的附加信息需要作為擴展元素位于SOAP消息中消息標(biāo)頭元素的較低級處（任何##其它位置）。擴展元素結(jié)構(gòu)將在以下表134中描述?！颈?34】下文中，將描述在介于流通通訊服務(wù)器和流通中繼服務(wù)器之間連接接口中的消息發(fā)送請求接口。當(dāng)在從流通通訊服務(wù)器發(fā)送消息到其它另一個流通通訊服務(wù)器的過程中在其它另一個流通通訊服務(wù)器處發(fā)生接收錯誤時，使用消息發(fā)送請求接口以請求流通中繼服務(wù)器發(fā)送消息且發(fā)行發(fā)送證書。流通中繼服務(wù)器立即返回流通通訊服務(wù)器的消息發(fā)送請求的接受結(jié)果，且使用上述“流通證書發(fā)送接口”將在發(fā)送消息到接收流通通訊服務(wù)器之后接收到的接收證書發(fā)送到發(fā)送請求流通通訊服務(wù)器。消息中繼處理流程在圖116中示出。消息中繼請求消息格式在圖117中示出。在如圖117所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，且請求流通消息位于第二MIME部分中。如果存在由用戶附加的文檔，那么文檔位于第三或者后續(xù)MIME部分中。請求流通消息結(jié)構(gòu)將在以下表136中描述?！颈?36】在表136中，如果為了交付文檔，體塊沒有必要，那么文本可省略。消息中繼響應(yīng)消息格式在圖118中示出。在如圖118所示的整個消息結(jié)構(gòu)中，SOAP消息位于第一MIME部分中，響應(yīng)流通消息位于第二MIME部分中，以及發(fā)送證書位于第三MIME部分中。如果在處理請求消息過程中發(fā)生錯誤，那么不產(chǎn)生第三MIME部分。響應(yīng)流通消息結(jié)構(gòu)將在以下表138中描述?！颈?38】在表138中，如果DocType為錯誤（9），那么不產(chǎn)生發(fā)送證書位于的第三MIME部分。下文中，將詳細描述如上所述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)及使用該電子文檔流通系統(tǒng)的電子文檔流通方法的另一個示例?！倦娮游臋n流通系統(tǒng)的結(jié)構(gòu)和電子文檔流通方法】基于P2P通信流通電子文檔，其中P2P通信允許遵守可靠流通標(biāo)準(zhǔn)的企業(yè)/機構(gòu)彼此直接發(fā)送/接收電子文檔。根據(jù)本發(fā)明的用于進行P2P通信的電子文檔流通系統(tǒng)的基本元件為基于支持介于管理地址信息的地址目錄服務(wù)器與每個收發(fā)實體之間流通的標(biāo)準(zhǔn)的流通通訊服務(wù)器系統(tǒng)。如果只提供地址目錄服務(wù)器和流通通訊服務(wù)器系統(tǒng)，那么配備允許企業(yè)或者機構(gòu)流通電子文檔的基本結(jié)構(gòu)。此外，發(fā)行用于證明發(fā)送方/接收方之間的文檔流通的流通證書，且同時流通證書存儲于第三方存儲機構(gòu)（認(rèn)證電子文檔存儲機構(gòu)）中，以為流通建立法律依據(jù)。除基本元件外，根據(jù)本發(fā)明的電子文檔流通系統(tǒng)包括：流通客戶端應(yīng)用程序（APP），用于為用戶接口提供文檔收發(fā)功能，以允許一般用戶（企業(yè)/機構(gòu)、個人）容易流通文檔；電子文檔格式寄存器，用于提供標(biāo)準(zhǔn)文檔格式以提高創(chuàng)建文檔的便利性；以及公共部門連接網(wǎng)關(guān)，用于作為另外配置元件為管理機構(gòu)中繼電子文檔。在上述電子文檔流通系統(tǒng)中執(zhí)行的基本過程將在以下表140中描述?！颈?40】【電子文檔流通系統(tǒng)的組成要素】下文將更系統(tǒng)地描述電子文檔流通系統(tǒng)的元件。為了建立電子文檔流通，首先，作為流通的主要主體（principalagent）的“（1）收發(fā)實體”需要存在，且收發(fā)實體需要包括“（2）流通通訊服務(wù)器系統(tǒng)”，流通通訊服務(wù)器系統(tǒng)遵守流通通訊服務(wù)器標(biāo)準(zhǔn)以流通文檔。此外，作為電子文檔流通基本構(gòu)造的“（3）地址目錄服務(wù)器”登記和管理收發(fā)實體的認(rèn)證電子郵件地址，且需要存在用戶?；谝陨匣緲?gòu)造，提供“（4）流通客戶端應(yīng)用程序”以為用戶提供流通便利性，且另外提供支持連接行政/公共機構(gòu)的“（5）公共部門連接網(wǎng)關(guān)”以及管理文檔格式的“（6）電子文檔格式寄存器”。下文中，將詳細描述上述組成元件。（1）收發(fā)實體在電子文檔流通的基本基礎(chǔ)組件中，作為流通標(biāo)準(zhǔn)的單元為收發(fā)實體。收發(fā)實體根據(jù)參與流通的角色充當(dāng)發(fā)送方或者接收方，且這些實體根據(jù)流通協(xié)議通過流通通訊服務(wù)器系統(tǒng)來流通文檔（信息）。參與流通的所有收發(fā)實體根據(jù)流通通訊標(biāo)準(zhǔn)建立能夠收發(fā)文檔的流通通訊服務(wù)器系統(tǒng)，且然后將流通通訊服務(wù)器系統(tǒng)的物理地址信息登記于地址目錄服務(wù)器中以為參與電子文檔流通創(chuàng)建基礎(chǔ)。在此情況下，每個收發(fā)實體具有實際流通用戶，實際流通用戶具有至少一個較低級別的認(rèn)證電子郵件地址。電子文檔流通中被標(biāo)示為收發(fā)實體的實體限于通過國家工業(yè)促進局建立遵守通訊服務(wù)器標(biāo)準(zhǔn)的系統(tǒng)且然后接收標(biāo)準(zhǔn)兼容性和互操作性的認(rèn)證的實體。為了證實流通，（1）在通過認(rèn)證收發(fā)實體流通電子文檔之后，（2）流通證書需要根據(jù)標(biāo)準(zhǔn)發(fā)行且存儲于第三方存儲機構(gòu)中。在此情況下，收發(fā)實體被分類為作為合法擁有者和電子文檔負責(zé)人負責(zé)直接發(fā)送電子文檔的實體；以及作為實際擁有者和流通電子文檔負責(zé)人的用戶代理服務(wù)的實體。在此情況下，如果電子文檔擁有者為直接發(fā)送電子文檔的收發(fā)實體，那么只有通過接收流通通訊服務(wù)器系統(tǒng)的標(biāo)準(zhǔn)兼容性和互操作性認(rèn)證且將流通證書穩(wěn)定地存儲于第三方存儲機構(gòu)中，電子文檔擁有者才可作為收發(fā)實體參與流通。與之相比，如果收發(fā)實體負責(zé)通過作為第三方的電子文檔擁有者（用戶）的代理服務(wù)器發(fā)送電子文檔，那么收發(fā)實體需要證明，收發(fā)實體穩(wěn)定且可靠地管理發(fā)送消息且管理和認(rèn)證用戶信息。為了確保第三方流通的穩(wěn)定性和可靠性，暫時地，執(zhí)行第三方流通的收發(fā)實體僅限于第三方存儲機構(gòu)提供商。（2）流通通訊服務(wù)器系統(tǒng)流通通訊服務(wù)器系統(tǒng)需要建立消息收發(fā)功能以及搜索與接收方有關(guān)的地址信息以及與地址目錄服務(wù)器有關(guān)的安全性相關(guān)信息的功能，以基于流通通訊服務(wù)器標(biāo)準(zhǔn)流通電子文檔（信息）。流通通訊服務(wù)器系統(tǒng)物理上具有一個電子郵件地址（IP地址），但可發(fā)行或者管理較低級別用戶的多個用戶賬戶，且每個用戶賬戶具有一個認(rèn)證電子郵件地址。流通通訊服務(wù)器系統(tǒng)需要管理每個用戶賬戶的電子文檔郵箱，以管理用戶賬戶，且流通通訊服務(wù)器系統(tǒng)作為用戶賬戶代表負責(zé)穩(wěn)定且可靠的進行電子文檔流通。為了作為收發(fā)實體參與電子文檔流通，流通通訊服務(wù)器系統(tǒng)被認(rèn)證是否適合實施根據(jù)本發(fā)明的要求，且在與其它解決方案的互操作性中沒有問題。認(rèn)證流通通訊服務(wù)器系統(tǒng)的標(biāo)準(zhǔn)兼容性和互操作性的認(rèn)證系統(tǒng)管理認(rèn)證的收發(fā)實體。此外，如果地址目錄服務(wù)器請求在登記認(rèn)證電子郵件地址的過程中確認(rèn)是否認(rèn)證，那么認(rèn)證系統(tǒng)返回結(jié)果。根據(jù)如圖65所示的以下過程，通過認(rèn)證電子郵件地址來認(rèn)證和登記流通通訊系統(tǒng)。首先，充當(dāng)收發(fā)實體的企業(yè)/機構(gòu)或者個人用戶根據(jù)技術(shù)標(biāo)準(zhǔn)來建立流通通訊服務(wù)器系統(tǒng)。接著，通過由認(rèn)證測試床提供的自動驗證設(shè)備來認(rèn)證建立的流通通訊服務(wù)器系統(tǒng)的標(biāo)準(zhǔn)兼容性和互操作性。接著，完成驗證的收發(fā)實體請求認(rèn)證測試床進行認(rèn)證測試。接著，如果根據(jù)認(rèn)證測試床的測試過程的系統(tǒng)認(rèn)證結(jié)果為“合格”，那么收發(fā)實體準(zhǔn)備用于登記認(rèn)證電子郵件地址的下一個程序。接著，認(rèn)證測試床將與通過認(rèn)證檢查的收發(fā)實體有關(guān)的信息交付給地址目錄服務(wù)器，且地址目錄服務(wù)器利用所述信息作為地址登記條件。接著，收發(fā)實體請求地址目錄服務(wù)器發(fā)行唯一ID，以登記認(rèn)證的流通通訊服務(wù)器系統(tǒng)。接著，如果流通通訊服務(wù)器系統(tǒng)完全登記在地址目錄服務(wù)器中，那么流通通訊服務(wù)器系統(tǒng)可參與電子文檔流通。接著，在完成認(rèn)證流通通訊服務(wù)器系統(tǒng)之后，用戶賬戶為開放。在代表性認(rèn)證電子郵件地址的情況下，請求用戶賬戶用認(rèn)證電子郵件地址登記。（3）地址目錄服務(wù)器為了參與可靠的電子文檔流通，所有用戶需要接收唯一電子郵件地址。（4）流通客戶端應(yīng)用程序流通客戶端應(yīng)用程序是指提供UI的應(yīng)用程序，諸如文檔發(fā)送和接收、接收文檔讀取以及參與文檔流通的用戶管理。流通客戶端應(yīng)用程序不獨立發(fā)送/接收文檔，而是需要與流通通訊服務(wù)器系統(tǒng)連接。通過流通客戶端應(yīng)用程序創(chuàng)建或者附加的文檔使用流通通訊服務(wù)器系統(tǒng)交付給用戶，搜索通過流通通訊服務(wù)器系統(tǒng)接收的文檔。如果流通通訊服務(wù)器系統(tǒng)通過用戶賬戶管理收發(fā)郵箱，那么流通客戶端應(yīng)用程序通過檢查用戶賬戶信息只可訪問接收文檔中的相應(yīng)文檔。根據(jù)用戶請求，流通客戶端應(yīng)用程序可實施為C/S型應(yīng)用程序或者web型屏幕。（5）公共部門連接網(wǎng)關(guān)不能接受電子文檔流通的行政或者公共機構(gòu)執(zhí)行這樣的功能：即在電子文檔流通系統(tǒng)下通過公共部門連接網(wǎng)關(guān)用民營企業(yè)、機構(gòu)或者個人接替行政或者公共機構(gòu)。（6）電子文檔格式寄存器想要使用流通通訊服務(wù)器系統(tǒng)發(fā)送電子文檔的用戶可使用office工具直接創(chuàng)建待發(fā)送文檔。電子文檔格式寄存器為支持管理（諸如文檔格式登記和管理、文檔格式搜索、讀取和下載），以當(dāng)?shù)怯浐凸芾順?biāo)準(zhǔn)文檔格式以支持允許用戶容易創(chuàng)建電子文檔時由用戶應(yīng)用程序（諸如流通客戶端應(yīng)用程序）使用的系統(tǒng)。電子文檔格式寄存器提供管理文檔標(biāo)準(zhǔn)格式的服務(wù)器引擎；以及允許客戶端應(yīng)用程序（APP）搜索和下載文檔標(biāo)準(zhǔn)格式的標(biāo)準(zhǔn)接口，且然后插入內(nèi)部程序以使用文檔標(biāo)準(zhǔn)格式。【電子文檔流通方法】電子文檔流通中流通電子文檔的整個過程大致分為“（1）流通之前的事先準(zhǔn)備步驟”、“（2）電子文檔流通步驟”、“（3）流通證實步驟”。下文中，將詳細描述上述三個步驟。此外，將詳細描述“文檔收發(fā)方法”、“流通證實方法”和“垃圾消息處理方法”。（1）流通之前的事先準(zhǔn)備步驟-電子文檔格式寄存器管理者使用電子文檔格式寄存器登記待使用的標(biāo)準(zhǔn)文檔格式。-收發(fā)參與者確定是否為了可靠流通而自主建立流通通訊服務(wù)器系統(tǒng)，或者打開先前建立的流通通訊服務(wù)器系統(tǒng)中的用戶賬戶以使用流通通訊服務(wù)器系統(tǒng)。如果為了可靠流通自主建立流通通訊服務(wù)器系統(tǒng)，那么建立用于收發(fā)電子文檔的流通通訊服務(wù)器系統(tǒng)，且然后通過認(rèn)證機構(gòu)對流通通訊服務(wù)器系統(tǒng)的標(biāo)準(zhǔn)兼容性和互操作性進行認(rèn)證測試。此后，收發(fā)參與者訪問地址目錄服務(wù)器以申請和接收經(jīng)認(rèn)證的流通通訊服務(wù)器系統(tǒng)的收發(fā)實體ID，然后自主登記和管理內(nèi)部實際用戶的內(nèi)部標(biāo)識符，并基于標(biāo)準(zhǔn)文檔格式（可選）將標(biāo)準(zhǔn)文檔格式創(chuàng)建功能插入用于文檔創(chuàng)建功能的客戶端應(yīng)用程序。與之相比，如果使用包括允許第三方流通的流通通訊服務(wù)器系統(tǒng)的收發(fā)實體，那么收發(fā)參與者請求通過流通通訊服務(wù)器系統(tǒng)打開企業(yè)/機構(gòu)/個人的用戶賬戶，且然后將用戶賬戶的認(rèn)證電子郵件地址信息登記于地址目錄服務(wù)器中。此后，收發(fā)參與者將標(biāo)準(zhǔn)文檔格式創(chuàng)建功能插入于客戶端應(yīng)用程序中，以便一般用戶基于標(biāo)準(zhǔn)文檔格式（可選）使用文檔創(chuàng)建功能。（2）電子文檔流通步驟○文檔發(fā)送方-文檔發(fā)送方使用文字處理器選擇待流通文檔或者創(chuàng)建待發(fā)送文檔。-接收文檔的另一方的地址信息以及待交付文檔，選擇是否加密文檔和是否進行數(shù)字簽名（對附加交付文檔而不是發(fā)送消息執(zhí)行加密和數(shù)字簽名，且這個過程為可選）-流通客戶端應(yīng)用程序基于與地址目錄服務(wù)器連接的接收方的認(rèn)證電子郵件地址，獲得物理地址信息和加密用公鑰信息（視情況，如果流通客戶端應(yīng)用程序不獲得物理地址，那么流通通訊服務(wù)器執(zhí)行這個過程）-流通客戶端應(yīng)用程序基于接收方地址信息（物理地址信息和認(rèn)證電子郵件地址都為可用）請求發(fā)送到流通通訊服務(wù)器○發(fā)送方的流通通訊服務(wù)器-如果在流通客戶端應(yīng)用程序中請求的發(fā)送請求消息不是接收方物理地址信息，那么流通通訊服務(wù)器基于地址目錄服務(wù)器的認(rèn)證電子郵件地址來查詢接收方的收發(fā)實體的物理地址信息-電子文檔被封裝為在流通協(xié)議標(biāo)準(zhǔn)中定義的消息結(jié)構(gòu)-基于發(fā)送方的流通通訊服務(wù)器的證書對消息進行數(shù)字簽名-基于終端物理地址信息將消息發(fā)送到接收方○接收方的流通通訊服務(wù)器-在接收消息之后，驗證消息且從消息提取文檔-包括接收證書的消息發(fā)送到發(fā)送方作為同步響應(yīng)（3）流通證實步驟-接收方在接收用于文檔接收確認(rèn)的文檔時，創(chuàng)建“接收證書”且將接收證書交付給發(fā)送方。接收接收證書的發(fā)送方將接收證書存儲于第三方存儲機構(gòu)中。如果有來自發(fā)送方的請求，那么接收方將接收文檔交付給文檔實際負責(zé)人（用戶），且然后在負責(zé)人檢查接收文檔時創(chuàng)建“讀取證書”以將讀取證書交付給發(fā)送方。接收“讀取證書”的文檔發(fā)送方將“讀取證書”存儲于第三方存儲機構(gòu)中（只有當(dāng)有來自發(fā)送方的請求時，發(fā)行讀取證書）。-當(dāng)發(fā)送方嘗試將文檔交付給接收方但嘗試失敗時，發(fā)送方請求作為客觀第三方的電子文檔流通中心以證實發(fā)送嘗試，且接收發(fā)送請求的電子文檔流通中心發(fā)行“發(fā)送證書”以證實發(fā)送請求的接收，并將發(fā)送證書交付給發(fā)送請求方。接收發(fā)送證書的發(fā)送請求方將“發(fā)送證書”存儲于第三方存儲機構(gòu)中?！鹞臋n收發(fā)方法發(fā)送方和接收方通過流通通訊服務(wù)器系統(tǒng)電子流通文檔。流通通訊服務(wù)器系統(tǒng)根據(jù)流通協(xié)議，發(fā)送/接收電子文檔。所有消息由發(fā)送確認(rèn)和接收確認(rèn)（或者接收證書）消息組合構(gòu)造，以用于可靠消息流通，且通過地址目錄服務(wù)器獲得接收方物理地址信息?！鹆魍ㄗC實方法“流通證實”是指關(guān)于與使用可靠方法的電子文檔流通相關(guān)的發(fā)送、接收或者讀取的事件證實。在此情況下，為與電子文檔流通相關(guān)的動作發(fā)行的證書統(tǒng)稱為“流通證書”。流通通訊服務(wù)器系統(tǒng)在發(fā)送和接收時發(fā)行流通證書，以證實發(fā)送和接收動作，且將發(fā)行的流通證書存儲于第三方存儲機構(gòu)中以用作流通動作證據(jù)材料。流通通訊服務(wù)器系統(tǒng)證實發(fā)送、接收和讀取電子文檔的事件，且為事件創(chuàng)建流通證書。流通證書包括流通證書的識別信息、流通證書創(chuàng)建時間和到期時間、流通證書策略和流通證實目標(biāo)。電子文檔發(fā)送的流通證書由電子文檔流通中心創(chuàng)建，且流通證實目標(biāo)包括發(fā)送方的識別信息、接收方的識別信息、流通識別信息、文檔識別信息和電子文檔發(fā)送請求時間。電子文檔接收的流通證書由接收電子文檔的接收方創(chuàng)建，且流通證實目標(biāo)包括發(fā)送方識別信息、接收方識別信息、流通識別信息、文檔識別信息、電子文檔發(fā)送時間和電子文檔接收時間。電子文檔讀取的流通證書由檢查電子文檔接收的用戶創(chuàng)建，且流通證實目標(biāo)包括發(fā)送方識別信息、接收方識別信息、流通識別信息、文檔識別信息、電子文檔發(fā)送時間、電子文檔接收時間和電子文檔檢查時間。如上所述創(chuàng)建的流通證書通過NPKI或者GPKI證書來數(shù)字簽名，且所創(chuàng)建的流通證書交付給電子文檔發(fā)送方。所有流通證書優(yōu)選存儲于第三方存儲機構(gòu)中。○垃圾消息處理方法電子文檔流通具有基礎(chǔ)結(jié)構(gòu)，其中，基本上，發(fā)送方通過認(rèn)證流通通訊服務(wù)器系統(tǒng)發(fā)送電子文檔，且接收方也基于認(rèn)證流通通訊服務(wù)器系統(tǒng)接收電子文檔，使得發(fā)送方為此負責(zé)。然而，垃圾發(fā)送方可打開流通通訊服務(wù)器系統(tǒng)中的用戶賬戶，且使用該用戶賬戶發(fā)送電子文檔。此外，當(dāng)前認(rèn)證系統(tǒng)只認(rèn)證系統(tǒng)的技術(shù)內(nèi)容。因此，如果垃圾發(fā)送方建立流通通訊服務(wù)器系統(tǒng)，在技術(shù)上認(rèn)證流通通訊服務(wù)器系統(tǒng)，以及然后使用流通通訊服務(wù)器系統(tǒng)作為垃圾發(fā)送單元，那么在初始階段難以阻止任何企圖。因此，為了解決以上問題，在根據(jù)本發(fā)明的標(biāo)準(zhǔn)文檔流通基礎(chǔ)設(shè)施中，根據(jù)用戶報告方法提供基于認(rèn)證名單管理的白名單以及基于垃圾目標(biāo)名單管理的黑名單系統(tǒng)，且應(yīng)用允許接收方拒絕通過這個系統(tǒng)接收的處理以防止垃圾消息。報告垃圾消息和檢查發(fā)送方的功能是基本的，因此所有流通通訊服務(wù)器需要必須建立這些功能。如果接收方確定接收消息為垃圾消息，那么接收方根據(jù)圖27所示的過程將垃圾消息報告給電子文檔流通中心的地址目錄服務(wù)器，且與其相關(guān)的處理程序如下。首先，如果接收方確定在接收消息時，該消息為垃圾消息，那么接收方通過流通通訊服務(wù)器系統(tǒng)將該消息作為垃圾消息報告給地址目錄服務(wù)器。接著，接受來自流通通訊服務(wù)器系統(tǒng)的垃圾消息報告的地址目錄服務(wù)器返回指示接受的確認(rèn)消息。接著，作為管理地址目錄服務(wù)器的主要機構(gòu)的國家IT產(chǎn)業(yè)促進機構(gòu)分析消息且調(diào)查發(fā)送方，以檢查和確定是否將發(fā)送方的認(rèn)證電子郵件地址添加為黑名單。接著，如果發(fā)送方被確定為黑名單候選方，那么地址目錄服務(wù)器將對應(yīng)的認(rèn)證電子郵件地址添加到黑名單，且然后將黑名單添加通知給發(fā)送方。接著，地址目錄服務(wù)器將垃圾消息請求處理結(jié)果交付給垃圾報告方（接收方）。在上述處理程序中，僅被認(rèn)證且正式登記的通訊服務(wù)器系統(tǒng)的信息記錄在白名單中。相反，當(dāng)發(fā)送方地址登記為垃圾發(fā)送方時，所述地址登記在黑名單中。如果重復(fù)產(chǎn)生通過相同流通通訊服務(wù)器系統(tǒng)登記于黑名單中的垃圾地址，那么電子文檔流通中心確定是否取消對相應(yīng)通訊服務(wù)器系統(tǒng)的認(rèn)證，且然后取消認(rèn)證并從白名單刪除垃圾地址。當(dāng)接收消息時，接收方檢查地址目錄服務(wù)器的白名單和黑名單，以確認(rèn)發(fā)送方是否為可靠且合法的用戶，從而確定是否拒絕接收。發(fā)送方檢查方法包括在接收時的實時檢查方法以及通過在接收方的流通通訊服務(wù)器中以緩存類型管理的名單來檢查發(fā)送方的定期檢查方法。在實時檢查發(fā)送方的過程中，如圖28所示，在接收方接收消息時，確定發(fā)送方地址是登記在地址目錄服務(wù)器中的白名單還是黑名單中，且然后確定是否拒絕接收。下文將描述實時檢查發(fā)送方的細節(jié)。首先，如果接收消息，那么接收方的流通通訊服務(wù)器系統(tǒng)將檢查請求消息交付給地址目錄服務(wù)器以檢查發(fā)送方是否為合法用戶。接著，地址目錄服務(wù)器檢查請求用戶的地址信息是否包括在白名單中。接著，如果地址不在白名單中，那么地址目錄服務(wù)器立即返回結(jié)果消息到檢查請求方，所述結(jié)果消息指示請求用戶為非登記用戶。如果地址包括在白名單中，那么地址目錄服務(wù)器檢查對應(yīng)地址是否登記在黑名單中。接著，地址目錄服務(wù)器將是否登記在黑名單中的結(jié)果消息返回到檢查請求方。接著，如果接收方從地址目錄服務(wù)器接收到指示發(fā)送方不是合法用戶（不包括在白名單中或者登記在黑名單中）的結(jié)果消息，那么接收方將接收消息自主處理為垃圾消息，且然后記錄和存儲從地址目錄服務(wù)器接收的處理結(jié)果消息以及垃圾消息接收記錄。接著，垃圾消息處理記錄需要存儲達一個月或者更長時間，以確認(rèn)對于對應(yīng)發(fā)送方的接收拒絕合法性。此外，在定期檢查發(fā)送方的過程中，如圖29所示，接收方預(yù)先從地址目錄服務(wù)器接收白名單和黑名單，自主管理白名單和黑名單，以及藉此確定發(fā)送方地址是否登記在白名單和黑名單中以確定是否拒絕消息接收。下文將描述定期檢查發(fā)送方的過程細節(jié)。首先，接收方的流通通訊服務(wù)器系統(tǒng)預(yù)先向地址目錄服務(wù)器請求最新白名單和最新黑名單，且自主管理白名單和黑名單。在此情況下，如果名單變更，那么交付是否請求自動通知。即使請求名單變更事件的自動通知，導(dǎo)入地址目錄服務(wù)器中最新名單的請求也定期執(zhí)行，使得名單信息差異最多為一天。接著，如果白名單和黑名單變更，那么地址目錄服務(wù)器將變更細節(jié)廣播給請求變更通知的用戶。接著，接收名單變更事件的用戶的流通通訊服務(wù)器系統(tǒng)修改被自主管理的名單信息以同步于該名單。接著，如果接收到消息，那么接收方檢查自主管理的名單以檢查是否為地址目錄服務(wù)器的合法用戶。接著，作為檢查自主管理的名單的結(jié)果，如果確定發(fā)送方不是合法用戶（不包括在白名單中或者登記在黑名單中），那么接收方將接收消息自主處理為垃圾消息且記錄和存儲垃圾消息接收記錄。接著，垃圾消息處理記錄需要存儲達一個月或者更長時間，以確認(rèn)對于對應(yīng)發(fā)送方的接收拒絕合法性?！玖魍ㄍㄓ嵎?wù)器系統(tǒng)】下文中，將詳細描述如上所述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)的流通通訊服務(wù)器系統(tǒng)。流通通訊服務(wù)器系統(tǒng)大致由消息發(fā)送、消息接收、接收消息的郵箱管理、消息安全性（用戶認(rèn)證、文檔加密/解碼）、收發(fā)記錄管理、地址目錄服務(wù)器連接、消息驗證、內(nèi)部系統(tǒng)連接接口、流通證書發(fā)行和管理以及第三方存儲機構(gòu)連接構(gòu)造。圖37示出了流通通訊服務(wù)器系統(tǒng)的構(gòu)造。參考圖37，將如下詳細描述流通通訊服務(wù)器系統(tǒng)的組件（1）到（9）。（1）消息發(fā)送/接收-根據(jù)流通協(xié)議發(fā)送和接收消息。（2）每個用戶的賬戶（郵箱）管理-發(fā)送或者接收消息根據(jù)用戶賬戶或者內(nèi)部標(biāo)識符存儲于每個賬戶的郵箱中。-對于存儲于郵箱中的發(fā)送文檔，管理四個階段狀態(tài)信息，包括“發(fā)送過程”、“發(fā)送完成”、“發(fā)送失敗”和“負責(zé)人完成接收”。在此情況下，“發(fā)送過程”的狀態(tài)是指當(dāng)在發(fā)送文檔之后未從接收方接收到響應(yīng)時的狀態(tài)，“發(fā)送完成”狀態(tài)是指從接收方的流通通訊服務(wù)器系統(tǒng)接收到“接收證書”時的狀態(tài)，“發(fā)送失敗”狀態(tài)是指由于在接收流通通訊服務(wù)器系統(tǒng)內(nèi)部發(fā)生錯誤或者在收發(fā)過程中發(fā)生網(wǎng)絡(luò)錯誤導(dǎo)致返回SOAP故障消息時的狀態(tài)，以及“負責(zé)人完成接收”狀態(tài)是指當(dāng)發(fā)送流通通訊服務(wù)器系統(tǒng)從接收方接收到用于證實負責(zé)人檢查文檔的“讀取證書”時的狀態(tài)。-對于存儲于每個用戶賬戶的郵箱中的接收文檔，管理四個階段狀態(tài)信息，包括“驗證錯誤”、“接收確認(rèn)之前”、“接收確認(rèn)”和“讀取確認(rèn)”。在此情況下，“驗證錯誤”狀態(tài)是指在驗證接收消息的基本結(jié)構(gòu)中發(fā)生錯誤時的狀態(tài)，“接收確認(rèn)之前”狀態(tài)是指在接收文檔負責(zé)人讀取郵箱中的接收文檔列表之前的狀態(tài)，“接收確認(rèn)”狀態(tài)是指接收文檔負責(zé)人已經(jīng)讀取郵箱中的接收文檔列表時的狀態(tài)，以及“讀取確認(rèn)”狀態(tài)是指接收文檔負責(zé)人已經(jīng)讀取接收文檔的細節(jié)時的狀態(tài)，接收方的流通通訊服務(wù)器系統(tǒng)在此時發(fā)行“讀取證書”，且然后將“讀取證書”交付給發(fā)送方。-如果從接收用戶接收到刪除請求，那么物理刪除相應(yīng)的接收文檔。-在郵箱中，發(fā)送文檔、發(fā)送的接收確認(rèn)消息以及接收負責(zé)人的接收確認(rèn)消息具有連接信息以相互連接。（3）地址目錄服務(wù)器連接-流通通訊服務(wù)器系統(tǒng)根據(jù)由地址目錄服務(wù)器提供的地址信息登記和搜索處理來管理地址信息。-流通通訊服務(wù)器系統(tǒng)包括可調(diào)用由地址目錄服務(wù)器提供的服務(wù)的客戶端功能。換言之，流通通訊服務(wù)器系統(tǒng)提供遠程調(diào)用由地址目錄服務(wù)器提供的地址信息登記、搜索、編輯和刪除功能的服務(wù)客戶端功能。（4）消息安全性（用戶認(rèn)證、文檔加密/解碼）-流通通訊服務(wù)器系統(tǒng)基本上執(zhí)行由流通協(xié)議建議的消息安全性功能（消息數(shù)字簽名、簽名驗證）。（5）發(fā)送/接收記錄管理-流通通訊服務(wù)器系統(tǒng)必須存儲/管理發(fā)送/接收記錄達至少一年或者更長時間。-關(guān)于待存儲的發(fā)送/接收記錄的信息包括發(fā)送記錄和接收記錄。發(fā)送記錄包括消息id、相關(guān)消息id、發(fā)送方（包括用戶賬戶）、接收方、發(fā)送時間以及發(fā)送文檔的哈希值。接收記錄包括發(fā)送方、接收方（包括用戶賬戶）、接收時間以及接收文檔的哈希值。（6）流通證書發(fā)行和管理-流通通訊服務(wù)器系統(tǒng)發(fā)行和管理流通證書，以證實文檔發(fā)送和接收事件的內(nèi)容。-發(fā)行的流通證書被請求存儲于第三方存儲機構(gòu)中，同時證書被交付以確?？煽啃?。-在發(fā)行流通證書之后，流通通訊服務(wù)器系統(tǒng)管理存儲于第三方存儲機構(gòu)中的流通證書的記錄。流通證書的發(fā)行記錄包括流通證書id、流通證書發(fā)行時間、相關(guān)消息id、流通證書原件（可選）以及在將流通證書存儲于第三方存儲機構(gòu)中之后接收到的存儲密鑰信息。（7）消息封裝過程（封裝、解析、提取）-流通通訊服務(wù)器系統(tǒng)在發(fā)送發(fā)送文檔之前，將發(fā)送文檔封裝為在流通協(xié)議中定義的消息結(jié)構(gòu)。-流通通訊服務(wù)器系統(tǒng)利用在流通協(xié)議中定義的消息結(jié)構(gòu)來解析（語法分析）接收文檔，并提取必要信息。（8）請求存儲流通證書-為了請求存儲流通證書，一般收發(fā)實體將第三方存儲機構(gòu)存儲請求消息發(fā)送到第三方存儲機構(gòu)的流通通訊服務(wù)器系統(tǒng)（遠程存儲請求）。-如果接收到認(rèn)證電子文檔存放處存儲請求消息，那么第三方存儲機構(gòu)的流通通訊服務(wù)器系統(tǒng)調(diào)用存儲請求客戶端，以將流通證書存儲于第三方存儲機構(gòu)中。-如果第三方存儲機構(gòu)的流通通訊服務(wù)器系統(tǒng)直接創(chuàng)建流通證書，那么第三方存儲機構(gòu)的流通通訊服務(wù)器系統(tǒng)直接調(diào)用第三方存儲機構(gòu)的存儲請求客戶端（本地存儲請求）。-用于請求存儲流通證書的客戶端根據(jù)第三方存儲機構(gòu)的收發(fā)連接接口標(biāo)準(zhǔn)請求第三方存儲機構(gòu)存儲流通證書。（9）附加服務(wù)-流通通訊服務(wù)器系統(tǒng)流通流通客戶端應(yīng)用程序管理并且管理流通客戶端應(yīng)用程序管理版本。-流通通訊服務(wù)器系統(tǒng)執(zhí)行消息流通管理（記錄或者統(tǒng)計信息）。-流通通訊服務(wù)器系統(tǒng)執(zhí)行系統(tǒng)管理（系統(tǒng)監(jiān)控或者環(huán)境信息）。-流通通訊服務(wù)器系統(tǒng)執(zhí)行文檔格式管理。如果根據(jù)本發(fā)明的包括上述組件（1）到（9）的流通通訊服務(wù)器系統(tǒng)應(yīng)用于第三方存儲機構(gòu)，如圖38所示，那么當(dāng)存儲流通證書時，流通證書存儲請求模塊調(diào)用根據(jù)第三方存儲機構(gòu)連接接口標(biāo)準(zhǔn)開發(fā)的連接接口客戶端，以請求存儲流通證書。如果根據(jù)本發(fā)明的包括上述組件（1）到（9）的流通通訊服務(wù)器系統(tǒng)應(yīng)用于一般收發(fā)實體（一般企業(yè)實體），如圖39所示，那么通過這樣的方法存儲流通證書：即，該方法將用于存儲流通證書的請求消息發(fā)送到第三方存儲機構(gòu)的流通通訊服務(wù)器系統(tǒng)并接收處理結(jié)果。使用根據(jù)本發(fā)明的包括上述組件（1）到（9）的流通通訊服務(wù)器系統(tǒng)在發(fā)送方和接收方之間直接流通的過程由四個步驟構(gòu)成，包括“（1）獲得接收方物理信息和安全性信息”、“（2）發(fā)送消息和確認(rèn)發(fā)送”、“（3）確認(rèn)任務(wù)接收方的接收”和“（4）發(fā)行和存儲流通證書”。將參考圖40詳細描述所述四個步驟。（1）接收方物理地址和安全性信息獲取-發(fā)送方系統(tǒng)請求物理地址信息和安全性信息（如果需要發(fā)送消息的接收密碼），其中實際消息基于另一方的地址信息交付給地址目錄服務(wù)器以獲得物理地址信息和安全性信息。-在流通客戶端應(yīng)用程序向地址目錄服務(wù)器請求接收方物理地址信息和安全性信息之后，接收方物理地址信息被交付給流通通訊服務(wù)器。-接收方地址信息可只使用用戶id（例如，居民登記號碼或者企業(yè)登記號碼）來獲得，用戶id只有當(dāng)接收方允許發(fā)送方基于id搜索地址信息時才是可用的。如果發(fā)送方已經(jīng)知道接收方物理地址信息和安全性信息，那么這個過程可省略。（2）消息發(fā)送和發(fā)送確認(rèn)在根據(jù)流通協(xié)議標(biāo)準(zhǔn)來封裝消息之后，發(fā)送方基于流通通訊服務(wù)器系統(tǒng)的證書進行數(shù)字簽名。-流通通訊服務(wù)器系統(tǒng)發(fā)送以先前獲得的物理地址封裝且數(shù)字簽名的消息。-接收消息的流通通訊服務(wù)器系統(tǒng)驗證基本封裝結(jié)構(gòu)、數(shù)字簽名有效性和發(fā)送方適用性（對于驗證的詳細內(nèi)容，請參考“2.4.6消息驗證”），且然后創(chuàng)建用于接收確認(rèn)的接收證書或者錯誤消息。-接收流通通訊服務(wù)器系統(tǒng)將創(chuàng)建的響應(yīng)消息發(fā)送到發(fā)送方。-發(fā)送和發(fā)送確認(rèn)過程由同步消息處理構(gòu)造。（3）任務(wù)接收方的確認(rèn)接收-如果發(fā)送方在發(fā)送消息時，請求任務(wù)接收方負責(zé)人的讀取確認(rèn)消息，那么接收方必須創(chuàng)建用于證實負責(zé)人讀取確認(rèn)的讀取證書，以在確認(rèn)企業(yè)消息接收時將讀取證書交付給發(fā)送方。-如果接收方將負責(zé)人讀取確認(rèn)的讀取證書消息發(fā)送到消息發(fā)送方，那么消息發(fā)送方同步發(fā)送接收確認(rèn)消息。（4）流通證書發(fā)行和存儲-如果需要每個步驟流通的證據(jù)，那么發(fā)送方根據(jù)所述步驟發(fā)行接收證書、讀取證書和發(fā)送證書并將證書存儲于第三方存儲機構(gòu)中，以確保流通法律證據(jù)的基礎(chǔ)。使用根據(jù)本發(fā)明的流通通訊服務(wù)器系統(tǒng)在發(fā)送方和接收方之間直接流通消息的過程除了執(zhí)行上述“（1）獲得接收方物理信息和安全性信息”、“（2）發(fā)送消息和確認(rèn)發(fā)送”、“（3）任務(wù)接收方的確認(rèn)接收”和“（4）發(fā)行和存儲流通證書”之外，還執(zhí)行“（5）錯誤處理”。參考圖90至圖92，下文將詳細描述錯誤處理功能。（5）錯誤處理功能流通通訊服務(wù)器系統(tǒng)的所有消息收發(fā)過程都是基于同步處理。因此，因為所有發(fā)送錯誤由發(fā)送方檢查，所以基本上消息重新發(fā)送。通過設(shè)定相同MessageId值來重新發(fā)送相同消息，使得在成功接收消息之后，即時在在發(fā)送接收確認(rèn)消息過程中發(fā)生錯誤時，接收方可通知冗余消息。即使在請求消息發(fā)送失敗時，流通通訊服務(wù)器系統(tǒng)遵循如圖41所示的處理流程圖。換言之，當(dāng)在由消息發(fā)送方發(fā)送消息的過程中由于網(wǎng)絡(luò)錯誤而發(fā)生發(fā)送錯誤時，如果發(fā)送方接收到錯誤消息（諸如HTTP錯誤），那么發(fā)送方請求重新發(fā)送相同消息。只有當(dāng)發(fā)送方接收到接收確認(rèn)消息時，發(fā)送方識別發(fā)送成功。當(dāng)響應(yīng)消息接收失敗時，流通通訊服務(wù)器系統(tǒng)遵循如圖42所示的處理流程圖。換言之，即使消息正常交付給接收方，如果發(fā)送方未從接收方接收到接收確認(rèn)消息，那么發(fā)送方識別為發(fā)送失敗錯誤，并利用相同MessageId將相同消息重新發(fā)送到接收方。如果接收文檔的MessageId與先前接收的消息相同，那么接收方發(fā)送接收確認(rèn)消息作為冗余接收并執(zhí)行內(nèi)部處理。當(dāng)錯誤消息接收失敗時，流通通訊服務(wù)器系統(tǒng)遵循如圖43所示的處理流程圖。換言之，即使正確交付從發(fā)送方發(fā)送到接收方的消息，但當(dāng)由于發(fā)送消息錯誤而作為響應(yīng)接收到錯誤消息時，發(fā)送方根據(jù)錯誤類型不同地處理消息。然而，根據(jù)重新請求發(fā)送的消息MessageId不需要為相同，但根據(jù)企業(yè)情況可改變。將如下詳細描述在如上所述根據(jù)本發(fā)明的流通通訊服務(wù)器系統(tǒng)中基本需要的“（1）消息收發(fā)功能”、“（2）接收消息郵箱管理功能”、“（3）消息安全性功能”、“（4）收發(fā)記錄管理功能”、“（5）地址目錄服務(wù)器連接功能”、“（6）消息驗證功能”、“（7）內(nèi)部系統(tǒng)連接接口功能”和“（8）流通證書發(fā)行和管理功能”。（1）消息收發(fā)由流通通訊服務(wù)器系統(tǒng)收發(fā)消息的基本過程遵循如上所述根據(jù)本發(fā)明的“電子文檔流通方法”的“文檔收發(fā)方法”。作為收發(fā)消息基礎(chǔ)的消息交換類型是基于消息流通協(xié)議的同步響應(yīng)，且可形成發(fā)送消息和接收確認(rèn)消息、發(fā)送消息和接收錯誤消息、發(fā)送消息和企業(yè)響應(yīng)消息（包括接收確認(rèn)消息的含義）的構(gòu)造。消息收發(fā)類型包括兩個類型，包括發(fā)送和接收確認(rèn)響應(yīng)消息的組合以及發(fā)送和企業(yè)響應(yīng)消息的組合。消息收發(fā)類型為發(fā)送和接收確認(rèn)響應(yīng)消息的組合時的處理流程在圖44中示出。發(fā)送消息和接收確認(rèn)（或者接收錯誤）消息由SOAP（簡單對象訪問協(xié)議）請求-響應(yīng)組合構(gòu)成，且發(fā)送消息及其響應(yīng)消息通過將發(fā)送消息MessageId插入于待發(fā)送的響應(yīng)消息的RefToMessageId中來連接，其細節(jié)將參考下文將描述的【流通協(xié)議】描述。消息收發(fā)類型為發(fā)送和企業(yè)響應(yīng)消息的組合時的處理流程在圖95中示出。發(fā)送消息以及包括接收確認(rèn)（或者接收錯誤）消息的響應(yīng)消息由SOAP請求-響應(yīng)組合構(gòu)成。在接收方接收消息且然后實時創(chuàng)建對與內(nèi)部系統(tǒng)有關(guān)的業(yè)務(wù)處理的響應(yīng)文檔之后，響應(yīng)文檔和接收確認(rèn)ACK消息包括在響應(yīng)消息中以交付給發(fā)送方。發(fā)送消息及其響應(yīng)消息通過將發(fā)送消息MessageId插入于待發(fā)送響應(yīng)消息的RefToMessageId中來連接，其細節(jié)將參考下文將描述的【流通協(xié)議】描述。收發(fā)消息的結(jié)構(gòu)具有如圖46所示的多部分-MIME結(jié)構(gòu)。SOAP消息插入于第一MIME部分中，且待發(fā)送文檔插入于第二或者后續(xù)MIME部分中。由SOAP標(biāo)頭和SOAP體塊構(gòu)成的SOAP封裝包插入于第一MIME中。用于收發(fā)消息的消息標(biāo)頭、數(shù)字簽名、接收確認(rèn)消息、同步發(fā)送標(biāo)記和錯誤消息插入于SOAP標(biāo)頭中。此外，在第二MIME部分中，插入待交付給消息接收方的文檔（信息）。如果負責(zé)人的接收確認(rèn)消息交付，那么文檔插入于這個位置中。在第三MIME部分中，如果有兩個以上文檔（信息）待交付給消息接收方，那么文檔依次插入于第三或者后續(xù)MIME部分中。（2）接收消息郵箱管理如果接收到消息，那么流通通訊服務(wù)器系統(tǒng)將接收消息存儲于每個賬戶的郵箱中。接收消息郵箱針對一個或者多個用戶賬戶是分開的，以存儲和管理消息。接收消息郵箱需要提供根據(jù)用戶請求（新接收消息存在性、接收消息讀取、接收消息下載以及接收消息刪除）執(zhí)行所需過程的接口，并以標(biāo)準(zhǔn)化方式返回結(jié)果。為了使由流通通訊服務(wù)器系統(tǒng)管理的用戶賬戶取得包括在電子文檔流通中的認(rèn)證電子郵件地址的資格，流通通訊服務(wù)器系統(tǒng)需要滿足認(rèn)證要求以具有可靠用戶賬戶（要求將由獨立評估指導(dǎo)手冊定義，目前，人們認(rèn)識到，只有第三方存儲機構(gòu)滿足認(rèn)證要求）。因此，允許個人或者企業(yè)（機構(gòu)）獲得電子文檔流通中認(rèn)證電子郵件地址的方法包括以下兩個方法。第一方法為自主建立流通通訊服務(wù)器系統(tǒng)并認(rèn)證流通通訊服務(wù)器系統(tǒng)以將獲得的收發(fā)實體ID登記于地址目錄服務(wù)器中的方法。第二方法為在另外滿足在認(rèn)證流通通訊服務(wù)器系統(tǒng)中具有可靠用戶賬戶的要求的收發(fā)實體中打開郵箱以接收用戶ID且然后將用戶ID登記于地址目錄服務(wù)器中的方法。（3）消息安全性發(fā)送消息安全性被分為用于確保完整性的數(shù)字簽名以及用于確保機密性的加密/解碼。通過流通通訊服務(wù)器系統(tǒng)發(fā)送的消息分為SOAP消息和附加文檔。在此情況下，附加文檔在流通客戶端應(yīng)用程序中已經(jīng)被加密，且只有用于收發(fā)消息的標(biāo)頭信息包括在SOAP封裝包中，使得在流通通訊服務(wù)器系統(tǒng)中不執(zhí)行另外加密過程，但在消息收發(fā)過程中執(zhí)行防止偽造的數(shù)字簽名過程。數(shù)字簽名方法和詳細程序參考下文將描述的【流通協(xié)議】。（4）收發(fā)記錄管理流通通訊服務(wù)器系統(tǒng)需要管理收發(fā)記錄信息，以在將來引起與發(fā)送/接收相關(guān)的糾紛或者問題時檢查記錄。記錄信息不僅可包括與收發(fā)動作有關(guān)的信息，而且包括實際發(fā)送/接收文檔。如果實際文檔存儲于第三方存儲機構(gòu)中，那么僅存儲從第三方存儲機構(gòu)接收的登記證書而不存儲文檔原件。（5）地址目錄服務(wù)器連接使用由地址目錄服務(wù)器提供的服務(wù)連接接口，流通通訊服務(wù)器系統(tǒng)與地址目錄服務(wù)器連接。地址目錄服務(wù)器提供兩種地址搜索服務(wù)、地址登記服務(wù)和地址變更服務(wù)。流通通訊服務(wù)器系統(tǒng)基本上提供地址搜索服務(wù)中“與認(rèn)證電子郵件地址相關(guān)的物理地址搜索服務(wù)”功能。除搜索服務(wù)外，根據(jù)是否使用流通被通訊服務(wù)器系統(tǒng)以較低級別登記/管理為企業(yè)或者個人的認(rèn)證電子郵件地址的用戶賬戶，來確定是否使用地址登記服務(wù)和地址變更服務(wù)。如果流通通訊服務(wù)器系統(tǒng)登記/管理的用戶賬戶被認(rèn)證，從而被登記為認(rèn)證電子郵件地址，因為流通通訊服務(wù)器系統(tǒng)通過代理服務(wù)器執(zhí)行認(rèn)證電子郵件地址的登記和變更服務(wù)，所以連接地址目錄服務(wù)器的相應(yīng)服務(wù)。（6）消息驗證當(dāng)流通通訊服務(wù)器系統(tǒng)發(fā)送/接收消息時，接收方在接收消息時驗證消息有效性，與圖47所示的過程相似，在驗證消息有效性之后，只有消息通過驗證時，接收方才將消息接收確認(rèn)消息交付給發(fā)送方。否則，接收方發(fā)送關(guān)于接收消息的錯誤消息。驗證目標(biāo)：接收消息的架構(gòu)驗證（驗證是否根據(jù)流通協(xié)議正確封裝接收消息）、消息完整性驗證（驗證接收消息的數(shù)字簽名值以驗證消息為完整而無偽造）以及消息發(fā)送方驗證（驗證用于數(shù)字簽名的證書擁有者是否與消息發(fā)送方相同，以認(rèn)證對消息進行數(shù)字簽名的發(fā)送方是否與消息上表示的發(fā)送方相同）。（7）內(nèi)部系統(tǒng)連接接口流通通訊服務(wù)器系統(tǒng)提供標(biāo)準(zhǔn)化收發(fā)接口，以允許內(nèi)部系統(tǒng)通過流通通訊服務(wù)器系統(tǒng)發(fā)送和接收文檔。接口細節(jié)將參考下文將描述的【流通客戶端應(yīng)用程序】描述。（8）流通證書發(fā)行和管理流通證書的基本條件為（1）通過發(fā)送和接收流通通訊服務(wù)器系統(tǒng)創(chuàng)建流通證書，（2）通過基于GPKI和NPKI證書執(zhí)行數(shù)字簽名來創(chuàng)建流通證書，和（3）基于電子文檔流通動作創(chuàng)建流通證書（在此情況下，如果當(dāng)電子文檔流通一次時交付一個或者多個電子文檔，那么創(chuàng)建一個流通證書并分配ID以識別相應(yīng)流通，以流通一個電子文檔，且藉此通過流通創(chuàng)建流通證書）。當(dāng)發(fā)行流通證書時，認(rèn)為：（1）因為由個人收發(fā)實體創(chuàng)建流通證書的序列號，所以使用20字節(jié)隨機數(shù)以給予唯一性，這不同于現(xiàn)有證書的標(biāo)準(zhǔn)，（2）未定義流通證書的更新和撤銷，（3）創(chuàng)建流通證書和流通客戶端應(yīng)用程序的流通通訊服務(wù)器系統(tǒng)的系統(tǒng)時間始終保持當(dāng)前時間，以及（4）流通證書策略只使用在技術(shù)標(biāo)準(zhǔn)中定義的OID和名稱。流通證書發(fā)行過程在圖48中示出，且流通證書類型以及創(chuàng)建流通證書所需的基本信息在以下表141中描述，以及獲得流通證書基本信息的方法將在以下表142中描述?！颈?41】【表142】流通證書由收發(fā)實體創(chuàng)建，且使用收發(fā)實體的NPKI和GPKI證書來數(shù)字簽名。作為流通證書的基本結(jié)構(gòu)，使用CMS標(biāo)準(zhǔn)的SignedData結(jié)構(gòu)，且使用與證書等同的內(nèi)容標(biāo)識符。流通證書的內(nèi)容類型如下。流通證書的基本字段如下：下文將描述如上所述的流通證書基本字段的細節(jié)。（1）版本-版本指示流通證書結(jié)構(gòu)的版本。版本設(shè)定為流通證書v2，且dataHash用在目標(biāo)字段中。ARCVersion::=INTEGER{v1(1),v2(2)}（2）序列號-序列號指示流通證書的識別信息。流通證書由接收電子文檔的收發(fā)實體創(chuàng)建，使得序列號識別號碼為無用。此外，當(dāng)重新安裝收發(fā)實體的流通客戶端時，很難保持序列號。因此，流通證書的識別信息使用20字節(jié)隨機數(shù)。因此，為了處理流通證書，應(yīng)當(dāng)能夠處理20字節(jié)隨機數(shù)。SerialNumber::=INTEGER（3）發(fā)行方、證書發(fā)行方-輸入發(fā)行流通證書的發(fā)行方的證書識別值。此字段的值需要具有與對流通證書數(shù)字簽名的簽名方的證書中SubjectName字段相同的值。（4）dateOfIssue，發(fā)行證書日期-dateOfIssue指示發(fā)行方發(fā)行流通證書的時間。（5）dateOfExpire，證書到期日期-dateOfExpire是指流通證書的到期日期。（6）策略，證書策略-策略是指流通證書的策略。根據(jù)證書類型，改變所有流通證書中的策略O(shè)ID，且僅使用存儲于技術(shù)標(biāo)準(zhǔn)中的值。-根據(jù)塊中證書類型，流通證書具有一個OID。-Qualifier值在UserNotice>ExplicitText>DisplyText中表示為UTF8字符型，并使用特定句子。-根據(jù)流通證書類型，使用以下表143中表示的策略信息。【表143】證書類型策略O(shè)IDQualifier發(fā)送證書1.2.410.200032.2.?.1發(fā)送證書接收證書1.2.410.200032.2.?.2接收證書接收確認(rèn)證書1.2.410.200032.2.?.3接收確認(rèn)證書（7）requestInfo，證書請求消息信息-這個字段設(shè)定為空（NULL）。RequestInfo::=CHOICE{arcCertRequestARCCertRequest,nullNULL}（8）目標(biāo)，證實目標(biāo)-指定所有流通電子文檔的哈希值。這個字段必須使用流通信息方法。用于opRecord和orgAndIssued、dataHash字段的結(jié)構(gòu)是指第三方存儲機構(gòu)的“證書格式和操作程序技術(shù)標(biāo)準(zhǔn)”。-關(guān)于流通電子文檔的信息包括在流通信息（DistributionInfos）字段中。（1）-1senderAdd，認(rèn)證電子郵件地址-這個字段指示發(fā)送方的認(rèn)證電子郵件地址。（1）-2receiverAdd，接收方的認(rèn)證電子郵件地址-這個字段指示接收方的認(rèn)證電子郵件地址。（1）-3dateOfSend，發(fā)送日期和時間-這個字段指示發(fā)送方發(fā)送電子文檔的時間。-在發(fā)送證書情況下，dateOfSend指定發(fā)送方請求發(fā)送到電子文檔流通中心的時間。-發(fā)送證書只包括這個字段，但不包括dateOfReceive和dateOfReceiveConfirm。（1）-4dateOfReceive，接收日期和時間-這個字段指示接收方接收電子文檔的時間。這個時間需要等于或者早于證書創(chuàng)建時間。接收證書和讀取證書需要包括這個字段。相反，發(fā)送證書不包括這個字段。（1）-5dateOfReceiveConfirm，讀取日期和時間-這個字段指示接收方接收和檢查電子文檔的時間。這個時間需要等同于或者滯后于接收日期和時間且等同于或者早于證書創(chuàng)建時間。讀取證書需要包括這個字段。相反，發(fā)送證書和接收證書不包括這個字段。（1）-6distributionId，流通識別值-這個字段指示電子文檔流通的識別值。為了創(chuàng)建這個字段，創(chuàng)建和使用20字節(jié)隨機數(shù)。這個字段值指示分配給電子文檔流通的流通消息的識別值。（1）-7numberOfFiles，流通文件數(shù)-在流通中可交付一個或者多個電子文檔，且這個字段指示在一個流通中交付的文件數(shù)。（1）-8distributedFileInfos，流通文檔信息-在流通中可交付一個或者多個電子文檔，且所有待交付文檔的信息需要包括在這個字段中。（1）-8-1fileHashedData，文件哈希信息-這個字段指示流通和交付電子文檔的哈希值。（1）-8-2fileId，文件識別值-當(dāng)識別值分配給待流通電子文檔時，指定用于對應(yīng)文檔的識別值。文件識別值由發(fā)送方創(chuàng)建且需要在將電子文檔交付給接收方時一起交付。接收方將交付文件識別值應(yīng)用于這個字段。-發(fā)送方使用uuid方法創(chuàng)建這個字段。-這個字段可選擇性使用，但是如果fileName字段未使用，那么這個字段必須使用并推薦字段使用。（1）-8-3fileName，文件名稱-這個字段指示待流通電子文檔的文件名稱。文件名稱由發(fā)送方指定，且需要在將電子文檔交付給接收方時一起交付。接收方將交付文件識別值應(yīng)用于這個字段。-這個字段可選擇性使用，但是如果fileID字段未使用，那么這個字段必須使用。上述與流通證書時間信息相關(guān)的一致性標(biāo)準(zhǔn)將在以下表144中描述?！颈?44】時間信息順序為發(fā)送日期和時間<接收日期和時間≤讀取日期和時間≤證書發(fā)行日期<證書到期日期。當(dāng)驗證流通證書時，需要檢查以上順序。流通證書驗證包括證書結(jié)構(gòu)驗證、證書數(shù)字簽名驗證、證書主要字段檢查以及證書時間信息一致性驗證。證書結(jié)構(gòu)驗證為驗證證書是否與ASN.1中定義的相同的過程。證書數(shù)字簽名驗證為驗證應(yīng)施加于流通證書的數(shù)字簽名的過程。證書主要字段檢查包括檢查版本字段值是否為v2的版本字段檢查、檢查目標(biāo)字段是否為hashData的目標(biāo)字段檢查、驗證用于數(shù)字簽名的證書DN是否與證書基本字段的DN相同的發(fā)行方信息驗證、檢查requestInfo字段是否為Null的requestInfo字段檢查、檢查distributionInfos擴展字段是否存在且判定為真的擴展字段檢查、檢查numberOfFiles字段值是否等于distributionInfos擴展字段中DistributedFile數(shù)目的文件數(shù)檢查、檢查目標(biāo)字段哈希值是否等于distributionInfos擴展字段的哈希值的目標(biāo)字段哈希值檢查以及根據(jù)時間信息一致性驗證準(zhǔn)則驗證的時間信息一致性驗證。證書時間信息一致性驗證基于流通證書時間信息一致性驗證準(zhǔn)則來驗證。同時，流通認(rèn)證是指認(rèn)證在使用可靠方法流通電子文檔的過程中出現(xiàn)的發(fā)送、接收和接收確認(rèn)事實的動作。流通認(rèn)證在單獨應(yīng)用程序中執(zhí)行，但是在流通證書查看器和流通認(rèn)證API中不執(zhí)行。如果對流通證書認(rèn)證另外執(zhí)行流通認(rèn)證，那么將執(zhí)行以下。-流通證書驗證：驗證流通證書。-流通證書策略檢查：檢查流通證書策略O(shè)ID以及發(fā)送、接收和接收確認(rèn)Qualifier值。-發(fā)送方地址檢查：檢查發(fā)送電子文檔的收發(fā)實體地址是否正確。-接收方地址檢查：檢查接收電子文檔的收發(fā)實體地址是否正確。-發(fā)送日期和時間檢查：檢查發(fā)送方發(fā)送電子文檔的時間是否正確。-接收日期和時間檢查：檢查接收方接收電子文檔的時間是否正確。-接收確認(rèn)日期和時間檢查：檢查接收方確認(rèn)電子文檔接收的時間是否正確。-流通ID檢查：檢查分配給個人流通情況的流通ID是否正確。如果發(fā)送方和接收方分開存儲和管理流通ID，那么可比較和管理流通ID。-流通文件標(biāo)識符或者文件名稱檢查：檢查待流通文件ID或者名稱是否正確。如果發(fā)送方和接收方分開存儲和管理文件ID和文件名稱，那么可比較和管理文件ID和文件名稱。-流通文件哈希值檢查：檢查待流通文件的哈希值是否等于擴展字段的DistributedFile字段值。在此情況下，流通證書中指定的哈希算法用于比較哈希值和字段值。同時，流通證書的配置文件將在以下表145中描述。應(yīng)當(dāng)考慮，將RSA2048位和SHA256算法應(yīng)用于數(shù)字簽名，在signedData結(jié)構(gòu)中必須包括證書，且在signerInfos字段中只包括一個signerInfor。【表145】在如上所述將流通證書與第三方存儲機構(gòu)連接的方法中，請求將流通證書存儲于第三方存儲機構(gòu)中，同時發(fā)行流通證書以確保發(fā)行流通證書的可靠性。在第三方存儲機構(gòu)提供商的流通通訊服務(wù)器系統(tǒng)的情況下，流通證書存儲過程在圖49中示出。第三方存儲機構(gòu)連接模塊直接請求將從流通通訊服務(wù)器系統(tǒng)發(fā)行的流通證書直接存儲于第三方存儲機構(gòu)中。第三方存儲機構(gòu)連接模塊由流通證書存儲請求模塊和第三方存儲機構(gòu)連接接口客戶端模塊構(gòu)成。根據(jù)現(xiàn)有第三方存儲機構(gòu)連接接口模塊標(biāo)準(zhǔn)，流通證書存儲于第三方存儲機構(gòu)中。在一般收發(fā)實體的流通通訊服務(wù)器系統(tǒng)的情況下，流通證書存儲過程在圖50中示出。為了請求第三方存儲機構(gòu)提供商存儲所發(fā)行的流通證書，請求消息交付給第三方存儲機構(gòu)提供商的流通通訊服務(wù)器系統(tǒng)。從外部接收存儲請求的第三方存儲機構(gòu)提供商的流通通訊服務(wù)器系統(tǒng)請求通過第三方存儲機構(gòu)連接接口將流通證書存儲于第三方機構(gòu)中。第三方存儲機構(gòu)連接模塊請求第三方存儲機構(gòu)根據(jù)現(xiàn)有第三方存儲機構(gòu)連接接口模塊標(biāo)準(zhǔn)來存儲流通證書。收發(fā)實體將流通證書存儲于第三方存儲機構(gòu)中的詳細處理在圖51中示出，且下文將描述細節(jié)?！鹆魍ㄗC書登記-當(dāng)流通證書存儲于第三方存儲機構(gòu)中時，可通過第三方存儲機構(gòu)提供商和收發(fā)實體之間協(xié)議來指定存儲機構(gòu)。存儲機構(gòu)使用證書將流通證書存儲于第三方存儲機構(gòu)中?！鸬谌酱鎯C構(gòu)的存儲請求過程類型-第三方存儲機構(gòu)提供商可提供同步處理和異步處理中至少一個，且根據(jù)由待連接第三方存儲機構(gòu)提供商提供的方法來連接流通通訊服務(wù)器。-情況1：同步處理過程（當(dāng)發(fā)送方請求存儲流通證書時，同步執(zhí)行完成流通證書登記于第三方存儲機構(gòu)中之后的發(fā)行登記證書的所有過程，使得發(fā)送方的流通通訊服務(wù)器接收登記證書作為同步響應(yīng)消息。因為請求的響應(yīng)消息為第三方存儲機構(gòu)的最終登記結(jié)果，所以如果發(fā)生存儲請求錯誤，那么通過發(fā)送方的流通通訊服務(wù)器進行重新處理。）-情況2：異步處理過程（如果發(fā)送方請求第三方存儲機構(gòu)流通通訊服務(wù)器存儲流通證書，那么第三方存儲機構(gòu)流通通訊服務(wù)器首先驗證請求消息有效性，然后接受存儲請求。第三方存儲機構(gòu)提供商需要將根據(jù)存儲請求消息登記于第三方存儲機構(gòu)中的待發(fā)行登記證書交付給發(fā)送方的流通通訊服務(wù)器，發(fā)送方為第一存儲請求方。因為第三方存儲機構(gòu)提供商負責(zé)將登記證書登記于接受存儲請求的第三方存儲機構(gòu)中，所以如果發(fā)生存儲錯誤，那么也通過第三方存儲機構(gòu)提供商進行重新處理。）【流通協(xié)議】下文中，將詳細描述應(yīng)用于如上所述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)和方法的流通協(xié)議。在應(yīng)用于根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)和方法的流通協(xié)議的描述中，將以順次描述“（1）消息封裝”、“（2）消息封裝包配置”和“（3）HTTP綁定”。（1）消息封裝流通協(xié)議的消息結(jié)構(gòu)應(yīng)用ebMSv2.0標(biāo)準(zhǔn)，且具有兩個邏輯MIME部分。第一MIME部分包括SOAP消息且稱為標(biāo)頭容器。SOAP消息由標(biāo)頭和體塊構(gòu)成。第二MIME部分為0個或者多個另外MIME部分且也稱為凈荷容器。第二MIME部分包括應(yīng)用程序級附加文檔。流通消息的基本結(jié)構(gòu)在圖52中示出，且遵守諸如簡單對象訪問協(xié)議（SOAP）1.1和帶附件SOAP消息的標(biāo)準(zhǔn)。流通消息封裝包的MIME標(biāo)頭的所有組成要素遵守帶附件SOAP消息的標(biāo)準(zhǔn)。此外，消息封裝包中的內(nèi)容類型MIME標(biāo)頭必須具有與包括SOAP消息文檔的MIME體塊部分的MIME媒體類型相同的類型屬性。根據(jù)SOAP標(biāo)準(zhǔn)的SOAP消息的MIME類型需要具有“text/xml”值。根部分需要包括Content-IDMIME標(biāo)頭，Content-IDMIME標(biāo)頭具有基于【RFC2045】的結(jié)構(gòu)，且除Multipart/相關(guān)媒體類型的基本參數(shù)外，開始參數(shù)（在【RFC2387】中可選）需要始終存在。下文中，在描述根據(jù)本發(fā)明的流通消息時，消息封裝包的路由體塊部分定義為標(biāo)頭容器。標(biāo)頭容器包括一個SOAP消息作為MIME體塊部分，如帶附件的SOAP消息規(guī)范中所定義的。根據(jù)SOAP標(biāo)準(zhǔn)，標(biāo)頭容器的MIME內(nèi)容類型標(biāo)頭需要具有“text/xml”值。內(nèi)容類型標(biāo)頭可包括“字符集”屬性。MIME字符集屬性用于區(qū)分用于創(chuàng)建SOAP消息的字符組。這個屬性的語義在【XMLMedia】中明確表達的text/xml的“字符集參數(shù)/編碼審議”中描述。有效值列表可在http://www.iana.org/中找到。如果MIME字符集屬性包括內(nèi)容類型標(biāo)頭，那么MIME字符集屬性需要等同于SOAP消息的編碼說明部分。此外，MIME字符集屬性不包括當(dāng)創(chuàng)建SOAP消息時與編碼沖突的值。當(dāng)這個文檔被編碼時，{UTF-8}必須用于使兼容性最大化。然而，由于為從text/xml【XMLMedia】演繹的媒體類型所定義的處理規(guī)則，這個MIME屬性不具有默認(rèn)值。根據(jù)帶附件SOAP消息的標(biāo)準(zhǔn)，消息封裝包中可包括0或者多個凈荷容器。如果消息封裝包包括應(yīng)用程序凈荷，那么消息封裝包必須包括在凈荷容器中。如果消息封裝包不包括應(yīng)用程序凈荷，那么凈荷容器不存在。凈荷容器的內(nèi)容通過SOAP體塊中ebXML消息Manifest元素來區(qū)分。基于【RFC2045】標(biāo)準(zhǔn)，根據(jù)本發(fā)明的流通消息的所有MIME部分可包括另外MIME標(biāo)頭。在實施中，本發(fā)明中未定義的MIME標(biāo)頭可忽略，且未識別的MIME標(biāo)頭應(yīng)當(dāng)忽略。例如，在實施中，內(nèi)容長度可包括在消息中。然而，包括內(nèi)容長度的消息的接收方可忽略內(nèi)容長度。（2）消息封裝包配置基于SOAP標(biāo)準(zhǔn)，所有擴展元素的內(nèi)容需要限于可用名稱空間。本發(fā)明中定義的所有ebXMLSOAP擴展元素的內(nèi)容需要限于ebXMLSOAP封裝包擴展名稱空間。名稱空間的說明部分可包括在SOAP封裝包、標(biāo)頭或者體塊元素中，或者直接包括在每個SOAP擴展元素中。SOAP封裝包將SOAP消息中各種Namespace申明為SOAP消息的根項目。待申明Namespace為如以下表150?！颈?50】消息封裝包的架構(gòu)結(jié)構(gòu)在圖102中示出。以下將順次描述作為SOAP封裝包元素的子元素的SOAP標(biāo)頭元素和SOAP體塊元素。SOAP標(biāo)頭元素為SOAP封裝包元素的第一子元素，且包括擴展元素，諸如MessageHeader、SyncReply、Signature和ErrorList。MessageHeader為基本元素，包括消息路由選擇信息（至/自）以及與消息有關(guān)的其它上下文信息，SyncReply為將基本發(fā)送狀態(tài)指示給下一個SOAP節(jié)點的元素，Signature為指示基于【XMLDSIG】的數(shù)字簽名的元素，【XMLDSIG】標(biāo)記與消息相關(guān)的數(shù)據(jù)，以及ErrorList為具有針對先前消息所報告的且只有報告先前消息錯誤時使用的錯誤列表的元素。下文將描述MessageHeader元素的細節(jié)。MessageHeader元素為表達于所有ebXML消息中且表示SOAP標(biāo)頭元素的子元素的基本元素。MessageHeader元素為由以下子元素構(gòu)成的復(fù)雜元素。MessageHeader的元素結(jié)構(gòu)將在以下表152中描述，且MessageHeader的架構(gòu)結(jié)構(gòu)在圖54中示出?！颈?52】SyncReply是指同步發(fā)送，且包括id屬性、版本屬性、SOAPactor屬性（必須具有“http://schemas.xmlsoap.org/soap/actor/next”值）和SOAPmustUnderstand屬性值。Signature元素需要作為SOAP標(biāo)頭的子元素存在，這是因為流通消息需要被數(shù)字簽名以應(yīng)對上述危險因素。根據(jù)【XMLDSIG】標(biāo)準(zhǔn)進行數(shù)字簽名的過程如下。首先，創(chuàng)建具有SignatureMethod、CanonicalizationMethod的SignedInfo元素以及Reference元素以及SOAP封裝包中的基本凈荷對象，如【XMLDSIG】中定義。接著，在規(guī)范化之后，基于在如【XMLDSIG】中指定的SignedInfo中指定的算法計算SignedInfo的SignatureValue。接著，創(chuàng)建包括SignedInfo、KeyInfo（推薦）和SignatureValue元素的Signature元素，，如【XMLDSIG】中指定。接著，SOAP標(biāo)頭的Signature元素包括在SOAP標(biāo)頭元素中。如上所述在數(shù)字簽名時使用的算法信息如下。算法基本上遵循W3C“XML簽名語法和處理”（RFC3275）的算法部分（6.0算法）。此外，為了支持國內(nèi)獨特算法，使用在TTAS.IF-RFC3075“XML簽名語法和處理”（電信技術(shù)協(xié)會，2004年）中定義的算法。用于根據(jù)本發(fā)明的流通協(xié)議中的算法列表包括數(shù)字簽名NameSpace、哈希（Digest）、數(shù)字簽名（Signature）、規(guī)范化和轉(zhuǎn)換。為了在發(fā)送/接收消息時在創(chuàng)建和驗證數(shù)字簽名的過程中使歧義最小化，優(yōu)選不使用不同于以下列表的算法。SHA1和SHA256可用作用于減少數(shù)據(jù)的算法，且示例將在以下表155中描述。由于物理上可不同地表示邏輯相同的文檔的XML特性，數(shù)字簽名值對于相同文檔可能為不同。為了防止以上現(xiàn)象，需要進行規(guī)范化處理。。即使有各種轉(zhuǎn)換算法作為經(jīng)過對整個XML數(shù)據(jù)中待簽名數(shù)據(jù)進行處理和選擇的過程的算法，在各種轉(zhuǎn)換算法中僅可使用三個算法。第一算法為封裝包簽名轉(zhuǎn)換，這是因為數(shù)字簽名遵守包括在簽名目標(biāo)中的形式，第二算法為上述規(guī)范化，以及第三算法為Xpath過濾，Xpath過濾選擇簽名目標(biāo)信息。數(shù)字簽名語法的結(jié)構(gòu)在圖55中示出。只有當(dāng)在接收消息以處理消息的過程中發(fā)生錯誤時，ErrorList位于標(biāo)頭較低級別中。當(dāng)產(chǎn)生ErrorList元素時，RefToMessageId必須存在于MessageHeader元素中，且RefToMessageId需要指定發(fā)生錯誤的消息MessageID。ErrorList元素具有諸如id屬性、SOAPmustUnderstand屬性、版本屬性、highestSeverity屬性的屬性以及一個或者多個Error元素。ErrorList結(jié)構(gòu)在圖56中示出。在此情況下，如果沒有錯誤報告，那么ErrorList元素不應(yīng)當(dāng)存在。highestSeverity屬性指示所有Error元素的最嚴(yán)重狀態(tài)。具體地，如果Error元素將嚴(yán)重性設(shè)定為Error，那么highestSeverity設(shè)定為Error。否則，highestSeverity設(shè)定為警告。Error元素具有id屬性、codeContext屬性、errorCode屬性、嚴(yán)重性屬性、位置屬性和描述屬性。id屬性用于唯一區(qū)分文檔中的ErrorList元素。codeContext屬性表示errorCodes的名稱空間或者架構(gòu)，且應(yīng)當(dāng)為URI。這個屬性的默認(rèn)值為urn:oasis:names:tc:ebxml-msg:service:errors。如果這個屬性沒有默認(rèn)值，那么規(guī)范實施指示使用errorCodes。作為基本屬性的errorCode屬性指示具有錯誤的消息的錯誤存在性。下文將描述errorCode有效值以及代碼含義。作為基本屬性的嚴(yán)重性屬性指示錯誤嚴(yán)重性。有效值為警告和錯誤。警告指示不管錯誤，正常創(chuàng)建在會話過程中的其它消息。錯誤指示在消息中不存在恢復(fù)錯誤以及在會話過程中不再創(chuàng)建其它消息。位置屬性指示存在錯誤的消息部分。如果ebXML元素中存在錯誤且元素為“良好形成”，那么位置屬性的內(nèi)容需要為【Xpointer】。描述屬性的內(nèi)容通過xml:lang屬性中定義的語言提供錯誤的描述性解釋。一般地，這個消息由驗證XML解析器或者消息的軟件產(chǎn)生。這意味著，內(nèi)容由創(chuàng)建Error元素的軟件銷售商或者開發(fā)者定義。如果在基于流通協(xié)議收發(fā)消息的過程中發(fā)生錯誤，那么通知錯誤的收發(fā)實體需要將錯誤報告給其它另一方。待報告錯誤包括消息結(jié)構(gòu)錯誤、可靠通訊錯誤和安全性錯誤。與屬于比本發(fā)明中定義的流通協(xié)議更低層的數(shù)據(jù)通信協(xié)議（諸如HTTP和Socket）相關(guān)的錯誤通過數(shù)據(jù)通信協(xié)議支持的標(biāo)準(zhǔn)機制來發(fā)現(xiàn)和報告，且不使用本發(fā)明中定義的錯誤報告機制。錯誤代碼通過錯誤目標(biāo)和錯誤類型來分類，且其細節(jié)將在以下表161中描述?！颈?61】SOAP體塊元素包括諸如Manifest的擴展元素作為SOAP封裝包的第二子元素。Manifest為指示位于不同位置（諸如凈荷容器或者web）中的數(shù)據(jù)的元素。Manifest元素為由一個或者多個Reference元素構(gòu)成的復(fù)雜元素。Reference元素中每個作為凈荷容器中包括的（多個）凈荷文檔的一部分被包括，或者區(qū)分與作為由URL可訪問的遠程資源的消息相關(guān)的數(shù)據(jù)。建議在SOAP正文中不加載凈荷數(shù)據(jù)。Manifest的目的在于允許與ebXML消息相關(guān)的特定凈荷被容易且直接訪問，并允許在無需解析的情況下確定應(yīng)用程序是否處理凈荷。Manifest元素具有一個id屬性、一個版本屬性以及一個或者多個Reference元素。Reference元素為由子元素（包括0或者多個架構(gòu)元素以及0或者多個描述元素）構(gòu)造的復(fù)雜元素。在此情況下，0或者多個架構(gòu)元素為與（多個）架構(gòu)有關(guān)的信息，架構(gòu)定義與父Reference元素區(qū)別的即時文檔。此外，0或者多個描述元素為針對由父Reference元素引用的凈荷對象的描述。Reference元素為【XLINK】的簡單鏈接。根據(jù)實施要求，XLINK處理或者引擎并不一定使用，但可能有用。除上述元素的內(nèi)容外，Reference元素還包括屬性內(nèi)容，諸如id、xlink-type、xlink:href、xlink:role。其它有效名稱空間屬性可能存在。接收MSH可忽略不同于以上定義的屬性的外部名稱空間屬性。在此情況下，id為Reference元素的XMLID，xlink-type將元素定義為XLINK簡單鏈接且具有“簡單”固定值。xlink:href為所引用凈荷對象的URI值且基于簡單鏈路【XLINK】規(guī)范。xlink:role區(qū)分凈荷對象或者描述凈荷對象目的的資源。如果這個屬性存在，那么這個屬性需要具有基于【XLINK】規(guī)范的URI值。如果參考項目具有描述參考項目的（多個）架構(gòu)（例如，XML架構(gòu)、DTD或者數(shù)據(jù)庫架構(gòu)），那么Schema元素需要作為Reference元素的子元素存在。這用于區(qū)分架構(gòu)和版本，且定義由父Reference元素區(qū)分的凈荷對象。Schema元素具有諸如位置和版本的屬性。在此情況下，位置為架構(gòu)的基本URI，且版本為架構(gòu)的版本標(biāo)識符。如果xlink:href屬性包括URI，URI為內(nèi)容id（URI架構(gòu)“cid”），那么具有內(nèi)容id的MIME需要表達在消息的凈荷容器中。否則，具有MimeProbem作為errorCode且Error作為severity的錯誤需要發(fā)送到發(fā)送方。如果xlink:href屬性不包括URI，URI為內(nèi)容id（URI架構(gòu)“cid”），那么URI不被解釋，因此根據(jù)實施確定是否發(fā)送錯誤。如果確定發(fā)送錯誤，那么具有MimeProbem作為errorCode且Error作為severity的錯誤需要發(fā)送到發(fā)送方。以下表162表示具有一個凈荷MIME體塊部分的消息的典型Manifest。【表162】（3）HTTP綁定在通過HTTP發(fā)送消息的方法中的HTTP綁定示例將在以下表163中描述。【表163】在本發(fā)明中，為了返回HTTP級別的響應(yīng)代碼，需要使用在【RFC2616】中定義的HTTP響應(yīng)代碼。主要響應(yīng)代碼將在以下表164中描述?！颈?64】【電子文檔格式寄存器】下文中，將詳細描述如上所述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)的電子文檔格式寄存器。電子文檔格式寄存器為允許收發(fā)實體創(chuàng)建、登記和管理在電子文檔流通中流通文檔所需的格式的系統(tǒng)。電子文檔格式寄存器包括格式創(chuàng)建單元、格式登記單元和格式管理單元以及標(biāo)準(zhǔn)連接模塊。格式創(chuàng)建單元包括PDF轉(zhuǎn)換模塊和PDF格式設(shè)計器。PDF轉(zhuǎn)換模塊提供將一般格式轉(zhuǎn)換為PDF的功能（例如，創(chuàng)建標(biāo)準(zhǔn)PDF-A）。PDF格式設(shè)計器提供創(chuàng)建可寫格式PDF的功能以及文檔安全性功能，諸如二維條形碼和防復(fù)制標(biāo)記。格式登記單元提供允許用戶登記格式（例如，一般格式，諸如HWP或者MS-Word）的功能。格式管理單元提供允許格式管理器登記和管理格式的功能，并提供每個類別的登記功能以及每個版本的記錄管理功能。此外，提供控制每個格式查看時段、查看次數(shù)和打印次數(shù)的設(shè)定功能。標(biāo)準(zhǔn)連接模塊提供與流通客戶端應(yīng)用程序連接的功能。此外，還提供格式列表搜索功能和文件下載功能。根據(jù)本發(fā)明的電子文檔格式寄存器的格式登記過程在圖57中示出。使用格式設(shè)計器，將標(biāo)準(zhǔn)電子文檔創(chuàng)建為FormPDF，且基本要求將在以下表165中描述?！颈?65】在標(biāo)準(zhǔn)電子文檔的結(jié)構(gòu)中，要求距離文檔下邊緣大約5cm的距離。根據(jù)數(shù)據(jù)量可改變條形碼大小，防復(fù)制標(biāo)記大小為3>1.3且根據(jù)格式形狀適當(dāng)?shù)卦O(shè)置。標(biāo)準(zhǔn)連接模塊（標(biāo)準(zhǔn)接口）允許用戶搜索和下載格式并在流通客戶端應(yīng)用程序中創(chuàng)建格式，且提供給包括在流通客戶端應(yīng)用程序中的WebUS（用戶接口）。標(biāo)準(zhǔn)連接模塊提供搜索每個類別、格式列表以及文件下載的功能?！倦娮游臋n封裝】下文中，將詳細描述應(yīng)用于如上所述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)和方法的電子文檔封裝。電子文檔封裝為允許收發(fā)實體在電子文檔流通中流通文檔所需的通訊系統(tǒng)標(biāo)準(zhǔn)。電子文檔封裝由標(biāo)準(zhǔn)電子文檔和附加文檔構(gòu)造，且由標(biāo)準(zhǔn)電子文檔的元數(shù)據(jù)構(gòu)造。基于PDF-A創(chuàng)建標(biāo)準(zhǔn)電子文檔，且通過諸如文檔安全性功能的信息來構(gòu)造元數(shù)據(jù)。附加文檔不被轉(zhuǎn)換為PDF，而而實際上封裝到原件中。標(biāo)準(zhǔn)電子文檔通過用戶證書來數(shù)字簽名，且在封裝之后，電子文檔封裝包被數(shù)字簽名以包括在封裝包中。圖59示出了電子文檔封裝包結(jié)構(gòu)。參考圖59，根據(jù)本發(fā)明的電子文檔封裝包結(jié)構(gòu)包括封裝包標(biāo)頭、元數(shù)據(jù)、標(biāo)準(zhǔn)電子文檔、附加文檔和數(shù)字簽名數(shù)據(jù)。其詳細組成要素將在以下表27至表31中描述。封裝包標(biāo)頭包括整個封裝包結(jié)構(gòu)信息。元數(shù)據(jù)包括標(biāo)準(zhǔn)電子文檔的文檔安全性功能的信息，且還包括諸如文檔讀取次數(shù)、打印次數(shù)的信息以及二維條形碼信息。標(biāo)準(zhǔn)電子文檔以標(biāo)準(zhǔn)PDF-A型構(gòu)造，且二維條形碼數(shù)據(jù)包括在PDF文件中的圖像區(qū)中，以及數(shù)字簽名數(shù)據(jù)包括在標(biāo)準(zhǔn)PDF簽名數(shù)據(jù)區(qū)中。附加文檔不是標(biāo)準(zhǔn)電子文檔，而是典型文檔。因此，從應(yīng)用文檔安全性功能的目標(biāo)排除附加文檔。使用包括在封裝中的用戶證書，數(shù)字簽名數(shù)據(jù)對封裝數(shù)據(jù)進行數(shù)字簽名?！颈?66】編號組成要素備注1整個文件大小2元數(shù)據(jù)大小3標(biāo)準(zhǔn)電子文檔大小4附加文件數(shù)5附加文件大小【表167】編號組成要素備注1讀取次數(shù)2打印次數(shù)3存儲功能4文本提取功能5臨時存儲/導(dǎo)入功能6文檔類型7二維條形碼大小(橫向)【表168】編號組成要素備注1PDF文件【表169】編號組成要素備注1附加文件【表170】編號組成要素備注1數(shù)字簽名數(shù)據(jù)驗證電子文檔封裝的方法包括（1）驗證電子文檔封裝數(shù)字簽名的方法、（2）驗證標(biāo)準(zhǔn)電子文檔的方法和（3）驗證打印電子文檔的方法，下文將描述所述方法。（1）驗證電子文檔封裝數(shù)字簽名的方法-當(dāng)處理數(shù)字簽名封裝時，客戶端應(yīng)用程序驗證數(shù)字簽名。只有當(dāng)驗證成功時，客戶端應(yīng)用程序才將標(biāo)準(zhǔn)電子文檔交付給電子文檔查看器。-此外，客戶端應(yīng)用程序支持手動數(shù)字簽名驗證功能，以當(dāng)發(fā)生糾紛時驗證數(shù)字簽名。（2）驗證標(biāo)準(zhǔn)電子文檔的方法-當(dāng)讀取標(biāo)準(zhǔn)電子文檔時，電子文檔查看器驗證數(shù)字簽名。只有當(dāng)數(shù)字簽名驗證成功時，在電子文檔查看器中讀取文件。（3）驗證打印電子文檔的方法-使用另外提供的驗證程序和平板掃描儀，驗證二維條形碼中的數(shù)字簽名數(shù)據(jù)，并通過肉眼比較原始文檔內(nèi)容和打印文檔內(nèi)容。同時，因為需要根據(jù)最終接收電子文檔的用戶的打印機模式，產(chǎn)生防復(fù)制標(biāo)記，所以防復(fù)制標(biāo)記不包括在封裝中?！玖魍蛻舳藨?yīng)用程序】下文中，將詳細描述如上所述根據(jù)本發(fā)明示例性實施方式的電子文檔流通系統(tǒng)的流通客戶端應(yīng)用程序。為了允許企業(yè)或者個人基于認(rèn)證電子郵件地址發(fā)送/接收文檔（信息），需要提供支持發(fā)送/接收的用戶接口（下文中簡稱為UI）的應(yīng)用程序。作為發(fā)送/接收消息的通訊引擎，如果與電子郵件相比，流通通訊服務(wù)器系統(tǒng)充當(dāng)郵件服務(wù)器，那么流通客戶端應(yīng)用程序（下文中簡稱為APP）充當(dāng)類似于郵件客戶端的用戶應(yīng)用程序，提供郵件客戶端以允許用戶與郵件服務(wù)器連接來發(fā)送/接收電子郵件。圖60示出了流通客戶端APP的結(jié)構(gòu)圖。參考圖60，作為在想要使用流通通訊服務(wù)器系統(tǒng)交換文檔的一般用戶的UI環(huán)境下的應(yīng)用程序，流通客戶端APP基本上包括“（1）用戶認(rèn)證”、“（2）消息創(chuàng)建”、“（3）消息列表查詢和細節(jié)內(nèi)容讀取功能”和“（4）流通通訊服務(wù)器系統(tǒng)連接”。除以上基本功能外，客戶端APP還可提供以下功能：“（5）管理基本信息和環(huán)境信息”、“（6）管理消息文件夾”、“（7）管理文檔格式”和“（8）文字處理器”，用于收發(fā)消息和管理由應(yīng)用程序開發(fā)者選擇性提供的應(yīng)用程序。（1）用戶認(rèn)證-在流通客戶端APP與流通通訊服務(wù)器系統(tǒng)連接之前，流通通訊服務(wù)器系統(tǒng)檢查用戶賬戶，且然后接收登錄會話信息。-流通客戶端APP的用戶認(rèn)證方法包括基于證書（公共和私有都允許）的用戶認(rèn)證以及基于ID/PW的用戶認(rèn)證。（2）消息創(chuàng)建功能-流通客戶端APP需要提供用戶接口，用戶接口可創(chuàng)建新消息且與流通通訊服務(wù)器系統(tǒng)連接來將創(chuàng)建的文檔交付給接收方。-當(dāng)調(diào)用流通通訊服務(wù)器系統(tǒng)的發(fā)送接口發(fā)送消息時，提供消息創(chuàng)建功能以輸入不同于由所需基本信息中環(huán)境信息預(yù)先設(shè)定的值的項目。（3）消息列表查詢功能和細節(jié)內(nèi)容讀取功能-通訊服務(wù)器系統(tǒng)管理消息以分為發(fā)送消息和接收消息。流通客戶端APP必須提供查詢與用戶賬戶對應(yīng)的消息列表的功能，以及當(dāng)用戶想要基于登錄用戶賬戶查看與流通通訊服務(wù)器系統(tǒng)連接來查看消息細節(jié)時，讀取包括附加文檔的消息的所有詳細信息的功能。（4）流通通訊服務(wù)器系統(tǒng)連接-流通客戶端APP的最重要功能為與流通通訊服務(wù)器系統(tǒng)連接來收發(fā)消息的功能。流通客戶端APP通過消息發(fā)送功能以及由流通通訊服務(wù)器系統(tǒng)提供的接收消息讀取接口基于登錄賬戶發(fā)送和接收消息。（5）基本信息和環(huán)境信息管理-客戶端APP提供管理發(fā)送消息時基本所需的環(huán)境信息的功能。因為流通客戶端APP不是獨立存在的應(yīng)用程序，所以流通客戶端可參與與流通通訊服務(wù)器系統(tǒng)連接的基于流通的基礎(chǔ)設(shè)施中。因此，基本上設(shè)定和管理與流通通訊服務(wù)器系統(tǒng)基本連接所需的流通通訊服務(wù)器系統(tǒng)連接信息（流通通訊服務(wù)器系統(tǒng)地址信息）。-此外，與文檔格式寄存器連接的登記服務(wù)器信息管理或者流通客戶端APP系統(tǒng)環(huán)境的附加信息管理可定義為根據(jù)應(yīng)用程序開發(fā)范圍提供。（6）消息文件夾管理-由流通通訊服務(wù)器系統(tǒng)管理的消息基本上分為待管理的發(fā)送消息和接收消息。發(fā)送和接收消息根據(jù)處理狀態(tài)管理狀態(tài)信息。作為每個消息的狀態(tài)信息，發(fā)送消息管理諸如發(fā)送之前、發(fā)送完成、發(fā)送失敗和負責(zé)人完成接收的狀態(tài)。接收消息管理諸如驗證錯誤、接收確認(rèn)之前和讀取確認(rèn)的狀態(tài)。流通客戶端APP基于由流通通訊服務(wù)器系統(tǒng)提供的基本狀態(tài)信息來管理消息文件夾，以將消息文件夾提供給用戶。-流通客戶端APP基于收發(fā)文件夾來劃流通送消息和接收消息，以根據(jù)由流通通訊服務(wù)器系統(tǒng)提供的狀態(tài)信息基本上將消息狀態(tài)通知給用戶。然而，此外，應(yīng)用程序開發(fā)者提供刪除消息郵箱（諸如發(fā)件箱或者垃圾箱），或者由應(yīng)用程序開發(fā)者選擇性提供允許用戶直接定義和管理文件夾的功能。因此，其描述將省略。（7）文檔格式管理功能-流通通訊服務(wù)器系統(tǒng)不限制附加到待發(fā)送消息的文檔格式。因此，收發(fā)目標(biāo)文檔包括任何類型文件，諸如一般文本文件、辦公文件、XML文檔或者多媒體文件。然而，為了方便用戶利用任務(wù)中的流通客戶端APP，支持基于格式創(chuàng)建文檔的功能可另外提供給基本文檔。流通客戶端APP可提供通過寄存器標(biāo)準(zhǔn)接口搜索和下載由文檔格式寄存器提供的文檔格式且然后基于下載文檔創(chuàng)建文檔以附加到消息的功能。-流通客戶端APP與由電子文檔流通中心提供的文檔格式寄存器連接來管理文檔格式，或者獨立建立文檔格式管理系統(tǒng)以與這個系統(tǒng)連接來管理文檔。將參考如上所述【電子文檔格式寄存器】描述來描述與由電子文檔流通中心提供的文檔格式寄存器連接來搜索和下載格式的方法。（8）文字處理器-文字處理器為創(chuàng)建單元，其允許流通客戶端APP支持用戶基于通過文檔格式管理功能下載的格式來創(chuàng)建文檔。當(dāng)使用由電子文檔流通中心提供的文檔格式寄存器時，參考如上所述【電子文檔格式寄存器】設(shè)計文字處理器。如果自主建立文檔格式管理系統(tǒng)，那么根據(jù)格式管理系統(tǒng)設(shè)計文字處理器。流通客戶端APP的基本處理包括“（1）文檔發(fā)送過程”和“（2）文檔接收過程”。提供“（3）電子文檔格式下載過程”作為附加過程。流通客戶端APP與充當(dāng)服務(wù)器的流通服務(wù)器系統(tǒng)連接以發(fā)送和接收文檔。此外，流通客戶端APP與電子文檔格式登記服務(wù)器連接以登記標(biāo)準(zhǔn)文檔格式。（1）文檔發(fā)送過程流通客戶端APP通過與流通客戶端APP連接的流通通訊服務(wù)器系統(tǒng)發(fā)送電子文檔到其它“收發(fā)實體”的步驟在圖61中示出，且處理程序如下。首先，流通客戶端APP創(chuàng)建待發(fā)送到接收方的消息。在此情況下，附加通過發(fā)送方預(yù)先創(chuàng)建的文檔或者通過由流通客戶端APP提供的文字處理器創(chuàng)建的文檔并指定接收方，且然后創(chuàng)建消息。接著，在輸入接收方地址信息之后，調(diào)用流通通訊服務(wù)器系統(tǒng)的發(fā)送接口以請求發(fā)送消息。接著，發(fā)送方的流通通訊服務(wù)器系統(tǒng)根據(jù)發(fā)送過程發(fā)送消息到接收方，且然后從接收方接收關(guān)于接收的響應(yīng)消息（接收證書或者接收錯誤）。接著，發(fā)送方的流通通訊服務(wù)器系統(tǒng)接收關(guān)于接收的響應(yīng)消息，且然后將響應(yīng)消息作為對發(fā)送的響應(yīng)交付給流通客戶端APP。這里，第一步驟至第四步驟是基本的，且第二步驟至第四步驟同步執(zhí)行。接著，如果發(fā)送方的流通通訊服務(wù)器系統(tǒng)從接收方接收包括讀取證書的消息，讀取證書確認(rèn)接收負責(zé)人讀取，發(fā)送流通通訊服務(wù)器系統(tǒng)返回接收響應(yīng)消息，且將接收消息存儲于用戶郵箱中。接著，第一發(fā)送方的流通客戶端APP向連接的流通通訊服務(wù)器系統(tǒng)請求接收文檔。接著，發(fā)送方的流通通訊服務(wù)器系統(tǒng)將存儲于郵箱中的接收文檔列表交付給請求接收文檔的用戶的流通客戶端APP。這里，第五步驟至第七步驟為只有當(dāng)在發(fā)送第一消息時請求接收負責(zé)人讀取確認(rèn)時執(zhí)行的選擇性且可選程序。（2）文檔接收過程流通客戶端APP從其它“收發(fā)實體”接收電子文檔的過程在圖62中示出，且其處理程序?qū)⒚枋鋈缦?。首先，如果接收到消息，那么接收方的流通通訊服?wù)器系統(tǒng)返回接收消息的接收響應(yīng)消息到接收方，并將接收消息存儲于用戶郵箱中。接著，接收方的流通客戶端APP登錄所連接的流通通訊服務(wù)器系統(tǒng)以請求接收文檔。接著，接收方的流通通訊服務(wù)器系統(tǒng)交付存儲于請求接收文檔的用戶郵箱中的接收文檔列表。這里，第二步驟和第三步驟為同步。接著，如果接收方請求從接收消息列表讀取消息的詳細信息，那么流通客戶端APP將包括對應(yīng)消息的附加文檔的詳細信息發(fā)送到流通通訊服務(wù)器系統(tǒng)。接著，如果最初發(fā)送方請求接收負責(zé)人讀取確認(rèn)，那么在用戶請求接收文檔的詳細信息時，接收方的流通通訊服務(wù)器系統(tǒng)將包括讀取證書的消息發(fā)送到對應(yīng)消息的發(fā)送方。接著，接收方的流通通訊服務(wù)器系統(tǒng)接收在第五步驟中發(fā)送的負責(zé)人讀取確認(rèn)消息（讀取證書）的接收響應(yīng)消息。（3）電子文檔格式下載過程流通客戶端APP下載電子文檔格式的過程在圖63中示出，且其處理程序?qū)⒚枋鋈缦?。首先，流通客戶端APP與電子文檔格式登記服務(wù)器直接連接以請求搜索文檔格式。在此情況下，基于由電子文檔格式登記服務(wù)器提供的標(biāo)準(zhǔn)連接接口執(zhí)行連接。接著，電子文檔格式登記服務(wù)器返回關(guān)于搜索文檔的信息作為結(jié)果。這里，第一步驟和第二步驟為同步。接著，流通客戶端APP將搜索格式列表展示給用戶以選擇格式。接著，流通客戶端APP請求電子文檔格式登記服務(wù)器下載選定電子文檔格式。接著，電子文檔格式登記服務(wù)器返回請求格式到流通客戶端APP。接著，流通客戶端APP登記待插入的下載電子文檔格式以用于文字處理器中。由上述流通客戶端APP的流通通訊服務(wù)器系統(tǒng)提供的接口類型包括用戶認(rèn)證（登錄）、退出、消息發(fā)送請求、接收消息獲得、詳細消息信息請求和消息刪除。流通客戶端APP和流通通訊服務(wù)器系統(tǒng)的連接方法（1）到（5）將描述如下。（1）流通通訊服務(wù)器系統(tǒng)的連接協(xié)議由流通客戶端APP的流通通訊服務(wù)器系統(tǒng)提供的連接接口是基于與流通通訊服務(wù)器系統(tǒng)的收發(fā)協(xié)議相同的協(xié)議。在此情況下，流通客戶端APP和流通通訊服務(wù)器系統(tǒng)提供單向同步通信，如圖64所示，這不同于流通通訊服務(wù)器系統(tǒng)之間的發(fā)送/接收，且在它們之間使用消息數(shù)字簽名認(rèn)證或者用戶認(rèn)證方法。發(fā)送消息實際上使用流通通訊服務(wù)器系統(tǒng)的消息結(jié)構(gòu)，用戶信息以及請求消息和響應(yīng)消息由圖66所示的結(jié)構(gòu)構(gòu)造。其詳細描述如下。-SOAP標(biāo)頭：根據(jù)基于如上所述【流通協(xié)議】配置的任務(wù)類型，流通客戶端APP和流通通訊服務(wù)器系統(tǒng)可充當(dāng)發(fā)送方或者接收方。SOAP標(biāo)頭包括消息標(biāo)頭和簽名信息。-SOAP正文：包括上述【流通協(xié)議】中定義的Manifest元素信息和用戶登錄信息。-發(fā)送文檔容器#1：在接收消息詳細信息的情況下，包括消息發(fā)送請求、接收消息獲得和正文文檔（內(nèi)容）。-發(fā)送文檔容器#2：在從#2依次接收消息詳細信息的情況下，包括消息發(fā)送請求和附加文檔。SOAP標(biāo)頭結(jié)構(gòu)將在以下表171中描述，消息標(biāo)頭結(jié)構(gòu)將在以下表172中描述，SOAP正文結(jié)構(gòu)將在以下表173中描述，以及正文消息結(jié)構(gòu)將在以下表174中描述?！颈?71】【表172】【表173】【表174】（2）消息發(fā)送請求下文將描述在發(fā)送消息時由流通客戶端APP交付給流通通訊服務(wù)器系統(tǒng)的基本信息。在完全發(fā)送之后存儲于郵箱中的發(fā)送文檔具有以下表175描述的四個狀態(tài)信息步驟。【表175】（3）接收消息獲取流通客戶端APP通過與流通通訊服務(wù)器系統(tǒng)連接的登錄用戶賬戶讀取接收消息的動作與在流通通訊服務(wù)器系統(tǒng)中刪除消息的動作分開。以下兩個狀態(tài)信息步驟根據(jù)消息接收過程來管理。-接收用戶是否讀取郵箱中的接收文檔列表-接收用戶是否讀取接收文檔的細節(jié)（4）詳細消息信息請求如果用戶想要基于接收文檔列表讀取細節(jié)，那么流通客戶端APP請求流通通訊服務(wù)器系統(tǒng)的消息詳細信息。接收詳細信息請求的流通通訊服務(wù)器系統(tǒng)將諸如消息的詳細屬性信息和消息附加文檔的所有消息內(nèi)容交付給流通客戶端APP作為響應(yīng)消息。（5）消息刪除如果用戶請求刪除，那么流通客戶端APP將文檔刪除請求交付給流通通訊服務(wù)器系統(tǒng)，且將結(jié)果通知給用戶。當(dāng)用戶刪除文檔時，是否給予作為垃圾箱概念的臨時刪除功能為流通客戶端APP的附加功能，而不是實際服務(wù)器上的動作。因此，流通客戶端APP的開發(fā)者可確定是否提供臨時刪除功能，但必須提供請求流通通訊服務(wù)器系統(tǒng)刪除的功能?！居涗浗橘|(zhì)】根據(jù)本發(fā)明的電子文檔流通方法可在通用數(shù)字計算機中實施，通用數(shù)字計算機使用由在計算機中可執(zhí)行的程序創(chuàng)建的計算機可讀記錄介質(zhì)來操作程序。計算機可讀記錄介質(zhì)包括磁性存儲介質(zhì)（例如，ROM、軟盤、硬盤或者磁帶）、光學(xué)讀取介質(zhì)（例如，CD-ROM、DVD或者光學(xué)數(shù)據(jù)存儲裝置）和載波（例如，通過互聯(lián)網(wǎng)傳輸）。下文中，以下將描述如上所述本發(fā)明中的地址目錄服務(wù)器的另一個實施方式?！镜刂纺夸浄?wù)器】所有用戶需要接收唯一電子郵件地址以參與可靠電子文檔流通。電子郵件地址由以下結(jié)構(gòu)表示。電子郵件地址：內(nèi)部分隔符+間隔標(biāo)記+唯一登記地址電子郵件地址示例為“gdhong#nipa.kr”。為了方便內(nèi)部處理，電子郵件地址的內(nèi)部分隔符由唯一登記地址擁有者選擇性添加，如有必要，內(nèi)部分隔符可省略。電子郵件地址的間隔標(biāo)記為位于唯一登記地址之前或者存在于內(nèi)部標(biāo)識符和唯一登記地址之間的標(biāo)記。例如，可使用“#”，如有必要，可使用其它標(biāo)記。電子郵件地址的唯一登記地址為由企業(yè)/機構(gòu)/個人請求發(fā)行的唯一ID值，且唯一登記地址的單位為發(fā)送和接收的法律責(zé)任單位。唯一登記地址為在收發(fā)實體自主建立流通通訊服務(wù)器之后或者通過電子文檔第三方流通代理機構(gòu)發(fā)行的唯一登記地址，且為電子地址的基本構(gòu)造。收發(fā)實體對于其自己的流通通訊服務(wù)器系統(tǒng)具有實際物理地址（IP地址）。然而，物理地址與電子郵件地址不具有相關(guān)關(guān)系，物理地址和電子郵件地址具有1：N關(guān)系。一個電子郵件地址不具有多個物理地址。與間隔標(biāo)記相鄰存在的企業(yè)/機構(gòu)/個人負責(zé)關(guān)于電子郵件地址的信息（電子文檔）的合法接收，且為了方便企業(yè)/機構(gòu)/個人，劃分通過內(nèi)部標(biāo)識符的流通。因此，企業(yè)/機構(gòu)/個人為此負責(zé)。電子文檔流通系統(tǒng)中電子郵件地址的含義表示為圖3所示的電子文檔流通系統(tǒng)參與者的關(guān)系圖。如上所述，將如下再次描述包括內(nèi)部標(biāo)識符和唯一登記地址的電子郵件地址。（1）內(nèi)部標(biāo)識符-不管地址目錄服務(wù)器，由收發(fā)實體自主發(fā)行和管理內(nèi)部標(biāo)識符。-內(nèi)部標(biāo)識符為收發(fā)實體中的唯一值且可省略。-企業(yè)/機構(gòu)/個人主要負責(zé)分配內(nèi)部標(biāo)識符的方法，且通過內(nèi)部標(biāo)識符的電子文檔流通不具有基于電子文檔流通的基礎(chǔ)系統(tǒng)中的正式含義。-如果唯一登記地址為正式登記于地址目錄服務(wù)器中的實體，使得負責(zé)接收的政府/公共部門/企業(yè)/機構(gòu)/團體/個人打開第三方流通收發(fā)實體中的賬戶，那么為了方便企業(yè)任務(wù)，內(nèi)部標(biāo)識符被用于流通電子文檔，且不登記在地址目錄服務(wù)器中，而只是用作企業(yè)內(nèi)部的信息。（2）唯一登記地址-參與電子文檔流通系統(tǒng)中以流通電子文檔的政府/公共部門/企業(yè)/機構(gòu)/團體/個人自主建立流通通訊服務(wù)器系統(tǒng)，且然后接收唯一登記地址作為收發(fā)實體，或者通過第三方流通（通過代理服務(wù)器流通）代理機構(gòu)接收唯一登記地址。-唯一登記地址的唯一性在發(fā)行時由地址目錄服務(wù)器確認(rèn)，以便不冗余發(fā)行。-政府/公共部門/企業(yè)/機構(gòu)/團體/個人的唯一登記地址的配置方法由認(rèn)證電子郵件地址管理機構(gòu)策略來確定。如上所述的電子郵件地址基本上以兩個級別管理。在認(rèn)證電子郵件地址的最高部分，存在管理地址目錄服務(wù)器的認(rèn)證電子郵件地址首席管理者的機構(gòu)（例如，國家IP產(chǎn)業(yè)促進機構(gòu)），并且認(rèn)證電子郵件地址首席管理者發(fā)行和管理較低收發(fā)實體的唯一電子郵件地址。在認(rèn)證電子郵件地址首席管理者的較低收發(fā)實體中，能夠進行第三方流通（通過代理服務(wù)器流通）的收發(fā)實體打開想要第三方流通的用戶登記地址，且然后將地址信息登記在地址目錄服務(wù)器中。在此情況下，為了保證用戶唯一登記地址值的唯一性，需要從地址目錄服務(wù)器確認(rèn)冗余性。在電子郵件地址中，不管地址目錄服務(wù)器如何，不是正式用戶而是為了任務(wù)便利在內(nèi)部發(fā)行和使用的內(nèi)部標(biāo)識符由收發(fā)實體自主發(fā)行和管理。發(fā)行電子郵件地址的系統(tǒng)在圖4中示出，且圖4所示元素的角色將在以下表184中描述。【表184】發(fā)行電子郵件地址的過程在圖5中示出。用戶（企業(yè)）可直接訪問由地址目錄服務(wù)器提供的屏幕，以登記或者編輯地址或者通過流通通訊服務(wù)器系統(tǒng)（由系統(tǒng)提供的網(wǎng)站）接收電子郵件地址，流通通訊服務(wù)器系統(tǒng)通過代理服務(wù)器發(fā)行經(jīng)認(rèn)證的電子郵件地址。參與流通的用戶需要在發(fā)送消息到其它方之前基于電子郵件地址獲悉實際物理地址信息，且進一步獲取接收方的公鑰信息，以加密所附文檔。在電子文檔流通過程中獲取電子郵件地址的物理地址的過程為必要步驟，且發(fā)送方查詢地址目錄服務(wù)器，以基于接收方的地址信息獲取接收方的物理地址信息和安全信息。如果發(fā)送方基于物理地址將發(fā)送文檔交付給接收方，那么接收方的流通通訊服務(wù)器系統(tǒng)基于接收方地址信息接收發(fā)送文檔，以根據(jù)用戶賬戶或者內(nèi)部標(biāo)識符內(nèi)部流通接收文檔。獲取電子郵件地址的物理地址和安全信息的過程在圖6中示出。在電子文檔流通中為了基于認(rèn)證的電子郵件地址發(fā)送文檔到接收方，有如下兩個方法：（1）流通客戶端APP在輸入接收方地址信息時獲取與地址目錄服務(wù)器有關(guān)的必要信息，且然后請求流通通訊服務(wù)器基于搜索到的實際物理地址信息來發(fā)送文檔，以及（2）流通客戶端APP請求流通通訊服務(wù)器基于接收方的認(rèn)證電子郵件地址來發(fā)送文檔，并且在流通通訊服務(wù)器發(fā)送文檔之前，流通通訊服務(wù)器獲取地址目錄服務(wù)器的物理地址和安全信息，且然后將文檔發(fā)送到接收方。兩個方法的過程在圖7中示出。地址目錄服務(wù)器提供遠程服務(wù)，以使得流通通訊服務(wù)器系統(tǒng)搜索地址信息或者通過代理服務(wù)器發(fā)行地址。由地址目錄服務(wù)器提供的服務(wù)包括地址搜索服務(wù)、地址登記服務(wù)和地址變更服務(wù)，且提供基于流通協(xié)議標(biāo)準(zhǔn)的以下服務(wù)接口。地址搜索服務(wù)為地址目錄服務(wù)器將與認(rèn)證電子郵件地址對應(yīng)的物理地址信息（例如，IP地址和域名地址）以及公鑰信息返回給搜索請求方的服務(wù)。一般地，地址搜索服務(wù)用于在發(fā)送方發(fā)送文檔之前獲取接收方的實際地址信息以及用于加密的安全信息。在此情況下，請求消息和響應(yīng)消息的角色將在以下表185中描述?！颈?85】地址登記服務(wù)為提供用于不僅通過由地址目錄服務(wù)器提供的UI而且從遠程位置登記用戶的認(rèn)證電子郵件地址的服務(wù)。地址目錄服務(wù)器接收用戶信息和認(rèn)證電子郵件地址信息作為用于登記信息的請求消息，且然后接收結(jié)果作為響應(yīng)消息。地址登記服務(wù)的請求消息需要交付以包括請求方的數(shù)字簽名信息，且地址目錄服務(wù)器驗證包括在請求消息中的用戶信息是否與用于數(shù)字簽名的認(rèn)證信息相同。在此情況下，請求消息和響應(yīng)消息的角色將在以下表186中描述。【表186】地址變更服務(wù)為遠程服務(wù)，該遠程服務(wù)提供允許用戶直接和遠程變更登記用戶的地址信息的功能。地址變更服務(wù)將變更請求消息與待變更信息一起發(fā)送到地址目錄服務(wù)器，并接收結(jié)果作為響應(yīng)消息。地址變更服務(wù)的請求消息需要傳送以包括請求方的數(shù)字簽名信息。地址目錄服務(wù)器驗證包括在請求消息中的用戶信息是否與用于數(shù)字簽名的證書信息相同。在此情況下，請求消息和響應(yīng)消息的角色將在以下表187中描述?！颈?87】