專利名稱：使用多個傳遞媒體的成批通信過程的制作方法
技術(shù)領(lǐng)域：
本發(fā)明通常涉及成批通信，尤其涉及用于使用多個傳遞媒體成批通信的方法和系統(tǒng)。
背景技術(shù)：
商家、公司和機構(gòu)(以下簡稱為始發(fā)者)出于各種原因使用與其客戶、供應(yīng)商和其它方(以下簡稱為接收者)的成批通信。一般而言，使用一個以下媒體執(zhí)行所述成批通信平信、電子郵件、傳真和發(fā)送到接收者的移動電話的短消息業(yè)務(wù)(SMS)消息。
通信始發(fā)者與其接收者具有不同類型的成批通信，范圍從專門銷售通信到連續(xù)傳遞諸如發(fā)票、報表和催告通知的基本信息。一般而言，所述成批通信具有以下公共元素獨立提供接收者信息的列表，所述列表通常必需從公司數(shù)據(jù)庫或記賬系統(tǒng)中提取；使用文檔模板的形式；來自所述接收者列表的數(shù)據(jù)被合并、或覆蓋到所述模板文檔上；以及最終的“合并”文檔被傳遞到客戶。
與接收者的通信可能始發(fā)于所述始發(fā)者的不同部門或?qū)嶓w，并被依據(jù)所使用通信媒體類型以不同方式執(zhí)行。在執(zhí)行所述各種通信時，所述始發(fā)者依據(jù)始發(fā)者是經(jīng)由平信、電子郵件、傳真還是SMS發(fā)送信息，使用不同接口和技術(shù)。所述始發(fā)者可能選擇內(nèi)部托管相關(guān)通信所需的一些或所有技術(shù)，但在其它情況下所述始發(fā)者也可能外辦所述通信。
存在郵件合并軟件應(yīng)用，用于生成信封的地址標簽，以及合并和打印信件。始發(fā)者可能還具有安裝于內(nèi)部的專用系統(tǒng)和打印部門，以管理水陸路郵件合并。郵寄機構(gòu)為始發(fā)者提供了外辦其水陸路郵件要求的能力。一般而言，定制手稿被寫入從所述始發(fā)者的數(shù)據(jù)庫提取的地圖數(shù)據(jù)，并將所提取的數(shù)據(jù)覆蓋到預先打印的紙面材料上。
傳真機器具有存儲列表并進行成批消息傳遞的能力。依據(jù)通信大小，可使用諸如微軟Outlook的工具來執(zhí)行成批電子郵件發(fā)送。所述應(yīng)用使用戶能夠?qū)?shù)據(jù)庫的數(shù)據(jù)字段并入微軟Word文檔，然后將合并后文檔經(jīng)由其郵件合并工具電郵給接收者列表。除了微軟Outlook和微軟Word之外的其它軟件應(yīng)用具有類似的功能。對于此領(lǐng)域內(nèi)的軟件應(yīng)用而言，傳真插件和傳真打印驅(qū)動器等必須安裝在網(wǎng)絡(luò)或所述軟件所安裝的工作站上。商家或公司還提供成批傳真和電子郵件業(yè)務(wù)。一些需要始發(fā)者為不同接收者提供個人化文檔；其它執(zhí)行始發(fā)者的數(shù)據(jù)合并。企業(yè)資源計劃(ERP)和記賬軟件可能還支持在所述應(yīng)用或軟件程序包內(nèi)電郵或傳真的能力。然而，這通常適合于單個通信(即在商務(wù)過程內(nèi)的特定點從所述程序包內(nèi)部發(fā)送單個電子郵件或傳真)，而不允許成批的個性化和傳遞。
始發(fā)者可能會使其系統(tǒng)適合于經(jīng)由載體發(fā)出SMS消息。一般而言，這是通過使用“電郵到SMS”型服務(wù)而得以執(zhí)行的，所述“電郵到SMS”型服務(wù)使得電子郵件被發(fā)送到指定地址，以特定方式格式化，然后作為SMS消息轉(zhuǎn)發(fā)到移動電話。始發(fā)者可能能夠成批外辦SMS消息發(fā)送，但通常并不提供，或不支持第三方產(chǎn)品提供合并來自與其它傳遞機制相同的數(shù)據(jù)庫的個人化數(shù)據(jù)的能力。
存在通常能夠?qū)㈦娮余]件轉(zhuǎn)發(fā)到傳真或SMS的有限合并業(yè)務(wù)。除此之外，所述業(yè)務(wù)并不提供格式化和合并功能。所述業(yè)務(wù)并不允許在使用相同接收者列表和數(shù)據(jù)庫時，為不同傳遞機制指定特定的格式化規(guī)則，且并不支持水陸路郵件作為一種傳遞選項。
MessagingDirect(來自ACI)提供電子快遞。電子快遞是一種直接的電子記賬和支付解決方案。這些工具尋求以電子傳遞的速度、效率和靈活性組合傳統(tǒng)的直接企業(yè)對企業(yè)的紙面交易。兩者還嘗試通過直接的電子商務(wù)便利流線型商業(yè)過程數(shù)字簽名、合法約束和安全遞送的端到端電子交易，例如賬單、報表、發(fā)票、確認書、保單。整個商務(wù)過程旨在在線交易，使得電子交易直接在商家與其客戶、合伙者和供應(yīng)商之間流過電子信道。所述MessaingDirect系統(tǒng)并不支持電子郵件、傳真或水陸路郵件傳遞的統(tǒng)一接口。所述MessagingDirect產(chǎn)品需要所有接收者登記到所述業(yè)務(wù)。
MessageReach和傳真郵件合并(來自Xpedite)具有用于不同媒體的不同供應(yīng)，但并不同時個人化和傳遞單個接收者列表到多個媒體。
Pulse Enterprise(來自Esker軟件)是另一個相似應(yīng)用，但并不支持逐步升級，也不被作為ASP模型(或網(wǎng)絡(luò)業(yè)務(wù))提供，且不支持水陸路郵件傳遞。Pulse Enterprise還需要傳真插件等與軟件一起安裝。使用Pulse Enterprise的公司必須將所述軟件和硬件安裝在其環(huán)境內(nèi)，并管理Pulse Enterprise以及傳真、SMS、電子郵件接口等。Pulse Enterprise包括一般文本識別TM(GDR)部分。一般文本識別TM尋求自動將文本和打印流數(shù)據(jù)轉(zhuǎn)換為多種電子格式，并處理所述文檔，將其傳遞到任何接收設(shè)備。
因此，明顯存在著對于一種自動化業(yè)務(wù)的需要，所述自動化業(yè)務(wù)使始發(fā)者能夠?qū)⒁粋€成批通信業(yè)務(wù)與單個公共接口一起使用，并再利用相同的接收者數(shù)據(jù)組，從而能夠經(jīng)由所有現(xiàn)有不同媒體執(zhí)行到接收者的成批通信，所述媒體包括常規(guī)或水陸路郵件、電子郵件、傳真和SMS(以及其它任何將來可能會出現(xiàn)的新傳遞媒體)。此外，明顯存在著對于一種自動化業(yè)務(wù)的需要，所述自動化業(yè)務(wù)使始發(fā)者能夠基于每個接收者對于接收所述信息的偏好，管理消息到接收者的傳遞，而所述始發(fā)者無需安裝和管理特定于特殊傳遞類型的技術(shù)，所述偏好包括如果所述信息在第一媒體上失敗則如何傳遞所述信息。此外，明顯存在著對于一種自動化業(yè)務(wù)的需要，所述自動化業(yè)務(wù)能夠基于所述接收者的偏好，格式化數(shù)據(jù)，并經(jīng)由單個接口將數(shù)據(jù)傳遞到傳遞媒體(傳真、電子郵件、SMS、紙面和歸檔)的整個頻譜。

發(fā)明內(nèi)容
根據(jù)本發(fā)明第一方面，提供了一種用于經(jīng)由多個傳遞媒體將信息成批通信到接收者的方法，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送。優(yōu)選的是，這包括擴展到未來其它新媒體類型的能力。經(jīng)由單個接口接收包括關(guān)于接收者的信息的用于分配的信息。所接收的信息可能包括一個或多個模板文檔和特定于每個接收者的數(shù)據(jù)(包括可嵌入圖像數(shù)據(jù))。通過基于所述接收者的傳遞偏好，將指定的一個所述傳遞媒體用于每個所述接收者，傳送至少一個基于所接收信息的文檔。
優(yōu)選的是，所述方法包括的步驟是，將一個不同的所述傳遞媒體用于所述指定傳遞媒體傳輸失敗的一個或多個接收者的每一個，逐步升級傳輸所述至少一個文檔。所述至少一個文檔可能被轉(zhuǎn)換為適合于每個接收者的所述指定一個或所述一個不同傳遞媒體的格式。然后可以使用所述指定一個或所述一個不同傳遞媒體，將格式化后文檔發(fā)送到用于傳輸?shù)妮d體。來自所述載體的關(guān)于傳輸?shù)膱蟾婵赡鼙惶幚頌?，為每個接收者提供關(guān)于所述文檔傳遞的狀態(tài)信息。而所述逐步升級步驟可能依據(jù)所述狀態(tài)信息。
所述方法可能還包括步驟將所述一個或多個模板文檔和特定于每個接收者的數(shù)據(jù)(可選地包括特定于每個接收者的圖像數(shù)據(jù))合并，以為每個所述接收者提供所述至少一個文檔。所述方法可能還包括步驟為每個傳遞媒體確定文檔模板類型，并為所述文檔模板類型選擇合并過程。特定于每個接收者的數(shù)據(jù)可能被提供給對應(yīng)的合并過程。所述傳遞媒體可能包括歸檔，以便利接收者在未來某個時刻對所合并模板文檔的附加拷貝的請求。
本發(fā)明其它方面還包括一種用于基于上述方法，經(jīng)由多個傳遞媒體將信息成批通信到接收者的系統(tǒng)和計算機程序，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送(并能夠擴展到其它新媒體類型)。以下將詳細描述本發(fā)明的這些和其它方面。


以下將參照附圖描述本發(fā)明的一些實施例，在附圖中圖1是根據(jù)本發(fā)明實施例的說明用于處理消息的過程的詳細流程圖；圖2是根據(jù)本發(fā)明實施例的說明用于三種不同接入方法的業(yè)務(wù)接口的方框圖；圖3是根據(jù)本發(fā)明實施例的說明可插數(shù)據(jù)文件轉(zhuǎn)換器的方框圖；圖4是根據(jù)本發(fā)明實施例的說明文檔合并器的方框圖；圖5是根據(jù)本發(fā)明實施例的詳細流程圖，其說明用于處理接收者的偏好規(guī)則和每個接收者的對應(yīng)傳遞媒體的過程；圖6是根據(jù)本發(fā)明實施例的說明用于基于接收者偏好逐步升級處理的過程的詳細流程圖；圖7是根據(jù)本發(fā)明實施例的說明用于生成合并報告的過程；圖8是根據(jù)本發(fā)明實施例的接收者用于指定傳遞偏好的用戶接口的圖像捕捉；圖9是根據(jù)本發(fā)明實施例的說明合并和傳輸處理的并行性和流水線操作的框圖；圖10a-10c是根據(jù)本發(fā)明實施例的接收者列表XML方案的列表；圖11是根據(jù)本發(fā)明又一實施例的消息分配系統(tǒng)的方框圖；圖12是圖11系統(tǒng)引擎的方框圖；圖13描述了模板；圖14示出了包括在接收者記錄內(nèi)的改發(fā)/逐步升級信息；圖15是說明轉(zhuǎn)換網(wǎng)絡(luò)接口功能的規(guī)則的表；圖16示出了可能付諸實踐的屏幕上的登錄；圖17示出了主屏布局的實例；圖18示出了用于觀察用戶的管理控制板；圖19示出了企業(yè)接口作業(yè)提交屏；圖20示出了狀態(tài)報告的實例；圖21A和21B示出了作業(yè)配置控制板；
圖22示出了包括FTP接口所提交的消息發(fā)送的定義的文件；圖23是消息分配系統(tǒng)的體系結(jié)構(gòu)的方框圖；圖24示出了XML格式的接收者文件的實例；圖25是數(shù)據(jù)庫結(jié)構(gòu)的實體關(guān)系圖；圖26示出了紙面作業(yè)的配置參數(shù)的實例；圖27示出了Java_Mapping_Class_Resource記錄內(nèi)的一種資源類型的實例；圖28是說明作業(yè)執(zhí)行流的方框圖；圖29是包括成批接口、網(wǎng)絡(luò)接口和公共接口的系統(tǒng)的方框圖；以及圖30示出了接收者列表XML方案。
具體實施例方式
公開了一種方法、系統(tǒng)和計算機產(chǎn)品，用于基于接收者的傳遞偏好，并引入逐步升級，經(jīng)由多個傳遞媒體將信息成批通信給單個接收者組。優(yōu)選的是，所述方法、系統(tǒng)和計算機程序能夠?qū)I(yè)務(wù)作為網(wǎng)絡(luò)業(yè)務(wù)傳遞。此外，所述傳遞媒體包括水陸路郵件、電子郵件、加密郵件、傳真、SMS和歸檔(并適合于包括未來其它媒體類型)。在下文中，闡述了大量特定細節(jié)，包括通信網(wǎng)絡(luò)、通信協(xié)議、諸如MHTML、Postscrpt等的數(shù)據(jù)格式。但對于本領(lǐng)域技術(shù)人員而言，依據(jù)本公開，顯然可在并不背離本發(fā)明范圍和精神的情況下做出修改和/或替代。在其它情況下，本領(lǐng)域技術(shù)人員眾所周知的細節(jié)被省略，以使本發(fā)明清晰。
在本文的語境中，術(shù)語“逐步升級”、“逐步升級”、“正在逐步升級”和單詞“逐步升級”的其它形式是指改發(fā)。因此，短語“使用一個不同傳遞媒體逐步升級傳輸至少一個文檔”是指使用另一媒體改發(fā)所述傳輸。
所述接收者尤其規(guī)定偏好借助哪個媒體傳遞信息。此外，所述接收者能夠規(guī)定，如果使用優(yōu)選媒體無法實現(xiàn)所述傳遞，則借助哪種媒體傳遞信息。因此，如果傳遞失敗，則根據(jù)所述接收者的偏好逐步升級到不同媒體。優(yōu)選的是，使用以面向?qū)ο蠓绞介_發(fā)的、由多個子部分構(gòu)成的計算機軟件實施所述過程。指向所述軟件的所述用戶接口優(yōu)選的是被作為網(wǎng)絡(luò)業(yè)務(wù)傳遞。更優(yōu)選的是，所述軟件應(yīng)用被以Java和可擴展標示語言(XML)寫。以下將立即提供概述，然后參照附圖詳細描述具體實施方式
。
依據(jù)對于計算機存儲器內(nèi)的數(shù)據(jù)操作的算法和符號表示，明確或隱含說明具體實施方式
的一部分。所述算法描述和表示是本領(lǐng)域技術(shù)人員在數(shù)據(jù)處理領(lǐng)域內(nèi)用于將其工作內(nèi)容最有效傳遞給本領(lǐng)域其他技術(shù)人員的方法。算法在本文中通常被認為是導致所需結(jié)果的有條理的步驟順序。所述步驟需要物理數(shù)量的物理操作。一般而言，盡管并不必要，但所述數(shù)量采取能夠被存儲、傳送、組合、比較和操縱的電或磁信號的形式。有時出于公共使用的原因，所述信號被認為是比特、值、單元、符號、字符、術(shù)語、號碼等。
然而，以上類似的術(shù)語與適當?shù)奈锢砹肯嚓P(guān)，僅是適用于所述量的便利標簽。除非特別說明，從以下清晰可見，本領(lǐng)域技術(shù)人員應(yīng)當理解，本文使用諸如“計算”、“合并”、“計算”、“轉(zhuǎn)換”、“確定”、“比較”、“生成”、“選擇”、“輸出”等術(shù)語的段落參考這樣一種計算機系統(tǒng)或類似電子設(shè)備的作用和過程，所述計算機系統(tǒng)將所述計算機系統(tǒng)的寄存器和存儲器內(nèi)的以物理(電子)量表示的數(shù)據(jù)操縱并轉(zhuǎn)換為，所述計算機系統(tǒng)存儲器或寄存器或其它信息存儲、傳輸或顯示設(shè)備內(nèi)的以物理量類似表示的其它數(shù)據(jù)。
本技術(shù)規(guī)范還公開了一種用于執(zhí)行所述方法操作的裝置。所述裝置可能被出于所需目的而特別構(gòu)造，或是可能包括通用計算機或其它由存儲在所述計算機內(nèi)的計算機程序選擇性激活或重新配置的設(shè)備。本文所述的算法和顯示并不固然與任何特定計算機或其它裝置相關(guān)。各種通用機器都可與根據(jù)本文教義的程序一起使用。作為選擇，更多專用裝置構(gòu)造為執(zhí)行所需方法步驟都可能是適當?shù)?。例如，互?lián)網(wǎng)目錄服務(wù)器計算機可能被配置為，通過安裝用于執(zhí)行如下所述的計算、比較和選擇步驟的計算機程序，從而將所存儲的目錄批量載入。
此外，本技術(shù)規(guī)范還公開了一種計算機程序產(chǎn)品，其包括計算機可讀媒體，所述計算機可讀媒體具有存儲在其上的執(zhí)行方法操作的計算機程序。所述計算機可讀媒體此處包括任何用于在信源與目的地之間通信計算機程序的傳輸媒體。所述傳輸媒體可能包括存儲設(shè)備，例如磁或光盤、存儲器片或其它適合于與通用計算機接口的存儲設(shè)備。所述傳輸媒體可能還包括諸如互聯(lián)網(wǎng)系統(tǒng)內(nèi)示范的硬布線媒體，或諸如在GSM移動電話系統(tǒng)內(nèi)示范的無線媒體。所述計算機程序并不限于任何特定編程語言和實施方式。應(yīng)當理解的是，各種編程語言及其編碼可用于實施本文包括的公開教義。
在任何一個或多個附圖中，在參考具有相同參考標號的步驟和/或特征時，為說明起見，所述步驟和/或特征具有相同(多個)功能或(多個)操作，除非出現(xiàn)相反意向。
為了便于參考，將借助以下子標題闡述本發(fā)明A.第一實施例I.概述，II.消息處理，III.(多個)業(yè)務(wù)接口，IV.可插數(shù)據(jù)文件轉(zhuǎn)換器，V.文本合并器，VI.偏好規(guī)則過程，VII.發(fā)射機，VIII.載體接口，IX.逐步升級處理器，X.報告，XI傳輸/合并的并行性/流水線技術(shù)B.第二實施例I.概述，II.概念，III.網(wǎng)絡(luò)接口，
IV.系統(tǒng)體系結(jié)構(gòu)，V.數(shù)據(jù)文件結(jié)構(gòu)，VII.數(shù)據(jù)庫結(jié)構(gòu)，VIII.Java映射類和XSL模板，A.第一實施例I.概述根據(jù)本發(fā)明實施例的成批通信過程和系統(tǒng)的重要方面包括始發(fā)者可經(jīng)由單個接口并使用單個接收者列表，執(zhí)行與使用一個業(yè)務(wù)的接收者的成批通信，但可經(jīng)由包括常規(guī)(平)郵、電子郵件(加密和未加密)、傳真和SMS的所有當前可用媒體傳遞，并將文檔傳遞到托管文檔歸檔和檢索系統(tǒng)(并能夠擴展到未來其它媒體技術(shù))。
可為單個接收者規(guī)定傳遞偏好以及逐步升級規(guī)則。例如，接收者可規(guī)定所述接收者偏好經(jīng)由傳真接收通信，但如果傳真失敗，則所述信息優(yōu)選地通過水陸路郵件接收。這可在單個接收者層面以及總體層面上執(zhí)行。
存在一個對所述系統(tǒng)的應(yīng)用編程接口(API)。經(jīng)由所述一個API，可使用傳真、電子郵件、加密電子郵件、SMS、水陸路郵件和歸檔(以及其它未來可用媒體類型)執(zhí)行傳遞。
所述過程被以組件化方式設(shè)計，以容易適合于未來類型的傳遞媒體的集成(例如，WAP、其它無線等)。
單個接收者列表可用于傳遞到所有不同的目標媒體。所述接收者列表可以是任何格式，所述過程將所述列表轉(zhuǎn)換為XML。支持各種輸入接收者文件格式，數(shù)據(jù)轉(zhuǎn)換被執(zhí)行為XML格式。
可通過將所述接收者列表內(nèi)的字段用于所有不同傳遞媒體，執(zhí)行合并(個人化)。這包括個人化SMS文本消息、電子郵件主體和主題文本、以及Word、便攜式文檔格式(PDF)、超文本標示語言(HTML)和MIME-HTML(MHTML)的文檔合并。MIME表示多目的互聯(lián)網(wǎng)郵件擴展。通過將XML文檔格式和XSL和XSL-FO樣式表用于數(shù)據(jù)格式化和說明來支持文檔合并。
所述業(yè)務(wù)管理所有到包括水陸路郵件郵寄商店的載體以及托管歸檔業(yè)務(wù)的接口。軟件不必安裝在始發(fā)者處，也不必在所述始發(fā)者處管理?？梢詾橄嗤拿襟w類型支持不同的載體，而始發(fā)者可能規(guī)定其優(yōu)選載體。
提供了傳遞結(jié)果的集成報告，包括關(guān)于已發(fā)生的逐步升級的報告，以及所有接收者通過不同媒體類型的成功/失敗。提供了一種集成報告接口，其使得用戶能夠瀏覽單個接收者的消息發(fā)送和逐步升級狀態(tài)。
所述過程被設(shè)計用于“成批郵件發(fā)送”情況，其中以類似于其中大量接收者被常規(guī)水陸路郵件郵寄店作為目標的方法的方式，大量接收者被作為目標。
所述過程或系統(tǒng)使用以下一個或多個技術(shù)，以提供在其它消息發(fā)送業(yè)務(wù)中尚未發(fā)現(xiàn)的特征所述過程識別與接收者通信所需的公共單元，并逐步升級XML文檔內(nèi)的那些單元。所述單元包括接收者的傳遞偏好和一組逐步升級準則。使用簡化符號規(guī)定所述傳遞偏好和逐步升級準則。專有XML方案還被定義為描述XML文檔格式。
所述過程提供了一種可遠程接入的安全電子接口或公共接口。所述單個應(yīng)用編程接口(API)以一致方式支持所有形式的消息發(fā)送。所述公共接口可由文件傳送協(xié)議(FTP)或簡單對象訪問協(xié)議(SOAP)接入。所述接口還可經(jīng)由網(wǎng)絡(luò)用戶接口接入。
所述業(yè)務(wù)提供數(shù)據(jù)合并(個人化)能力，以使所述業(yè)務(wù)能夠?qū)⒔邮照邤?shù)據(jù)合并為各種文檔格式，包括PDF、HTML、MHTML、微軟Word和文本。所述業(yè)務(wù)優(yōu)選地使用可擴展樣式表語言格式化對象(XSL-FO)格式化引擎，來執(zhí)行所述數(shù)據(jù)合并。所述個人化能力包括個人化電子郵件消息以及經(jīng)由SMS發(fā)送的消息的主旨和主體文本。
所述API支持一種用于規(guī)定數(shù)據(jù)轉(zhuǎn)換器的機制。所述業(yè)務(wù)具有安裝在其內(nèi)的專用碼，其能夠動態(tài)寫和插入定制數(shù)據(jù)轉(zhuǎn)換器。所述數(shù)據(jù)轉(zhuǎn)換器取得任何格式的接收者數(shù)據(jù)(即從機構(gòu)的記賬或ERP系統(tǒng)提取)，并將所述接收者數(shù)據(jù)轉(zhuǎn)換為公共XML格式，以饋入消息發(fā)送引擎。
所述業(yè)務(wù)管理以下所有載體接口SMS、電子郵件、加密電子郵件、傳真、常規(guī)(平)郵和歸檔。這是通過在所述系統(tǒng)內(nèi)具有獨立的代碼層來執(zhí)行的，所述代碼層將公共載體接口提供給剩余的消息發(fā)送引擎。這還能夠使未來的媒體類型能夠容易地并入所述業(yè)務(wù)(例如WAP)。所述業(yè)務(wù)還可存儲所述始發(fā)者可能具有的關(guān)于載體選擇的偏好。
所述業(yè)務(wù)將所述一個單個組的輸入數(shù)據(jù)重復用于所有不同的文檔模板和傳遞媒體類型。所述業(yè)務(wù)通過執(zhí)行一個模塊或部分內(nèi)的文檔合并，以及格式化以顯示給獨立模塊內(nèi)的載體接口來執(zhí)行上述重復利用。
所述業(yè)務(wù)通過獲取從所述載體接收回的不同類型的報告，并將所述報告轉(zhuǎn)換為存儲在相關(guān)數(shù)據(jù)庫內(nèi)的公共格式，將單個、集成的報告接口提供給所述用戶。所述業(yè)務(wù)然后相對于單個消息接收者協(xié)調(diào)這些傳遞報告，以便跟蹤傳遞并驅(qū)動逐步升級進程。這使得所述業(yè)務(wù)能夠?qū)㈥P(guān)于單個消息成功和失敗的報告提供給所述用戶，并顯示已為單個接收者設(shè)置的逐步升級路徑。
所述業(yè)務(wù)還被以能夠?qū)崿F(xiàn)大量消息發(fā)送吞吐量的方式實施。所述業(yè)務(wù)通過將所述合并過程內(nèi)的步驟分為不同部分來執(zhí)行所述大量消息發(fā)送。所述部分然后被同時執(zhí)行，從而使得許多不同步驟得以同時執(zhí)行。
II.消息處理圖1示出了可在軟件內(nèi)實施的消息發(fā)送過程100。處理在步驟102內(nèi)開始。在步驟104中，經(jīng)由API接收接收者數(shù)據(jù)文件106、jobDescriptor.XML 108和模板文檔110。以下將詳細描述jobDescriptor.XML 108的細節(jié)。在步驟112中，所述作業(yè)參數(shù)被處理，而數(shù)據(jù)文件被輸入。在步驟114中，進行檢查以確定是否已指定數(shù)據(jù)轉(zhuǎn)換器。如果步驟114返回真(是)，則處理在步驟116內(nèi)繼續(xù)，并裝載所指定的客戶轉(zhuǎn)換器。在步驟118中，使用所述客戶轉(zhuǎn)換器將所述數(shù)據(jù)轉(zhuǎn)換為XML，處理然后在步驟120內(nèi)繼續(xù)。如果步驟114返回假(否)，則處理在步驟120內(nèi)繼續(xù)。
在步驟120中，驗證并語法分析XML接收者列表，然后將所述XML接收者列表存儲到數(shù)據(jù)庫。這生成了所存儲的接收者數(shù)據(jù)和傳遞偏好122。在步驟124中，接收者傳遞偏好被處理，并被分為不同媒體類型束。在步驟126中，進行檢查以為每個媒體類型確定文檔模板類型，并選擇對應(yīng)的文檔合并器。所述文檔模板對于特定媒體類型的所有接收者而言都是相同的。所述文檔合并器獲取每個單個接收者的數(shù)據(jù)，并將所述數(shù)據(jù)合并為文檔模板，以為所述接收者生成個人化文檔。所述文檔模板可能是XSL模板。作為選擇，支持MS Word模板和HTML模板。這是“模板類型”。依據(jù)所述模板類型，裝載不同的文檔合并器(XSL-FO合并器、MS Word合并器、HTML合并器等)。從步驟126開始，可能執(zhí)行一個或多個若干合并步驟或操作。所述合并步驟包括文本合并128、PDF合并130、Postscript合并132、HTML合并134和微軟Word合并136。本領(lǐng)域技術(shù)人員應(yīng)當理解，依據(jù)本公開，在并不背離本發(fā)明范圍和精神的情況下，可實踐其它類型的合并。接收者數(shù)據(jù)138被提供給合并步驟128-136。
處理從每個步驟128-136繼續(xù)到步驟140。在步驟140中，進行檢查以為接收者選擇傳遞載體。這得以執(zhí)行，是通過重新檢查先前處理接收者傳遞偏好步驟124的結(jié)果，并結(jié)合為所述作業(yè)始發(fā)者配置的每個媒體的優(yōu)選載體。所述兩條信息的組合被用于判定將使用的載體模塊。如果將發(fā)送傳真，則處理繼續(xù)通過包括步驟142-144的路徑。如果將發(fā)送電子郵件，則處理繼續(xù)通過包括步驟148-152的路徑。如果將發(fā)送水陸路郵件，則處理繼續(xù)通過包括步驟154-158的路徑。如果將發(fā)送SMS消息，則處理繼續(xù)通過包括步驟160-164的路徑。如果將歸檔所述文檔，則處理繼續(xù)通過包括步驟166-170的路徑。
對于傳真路徑而言，合并后的文檔在步驟142內(nèi)被轉(zhuǎn)換為位圖格式，優(yōu)選為TIFF。在步驟144中，所述TIFF格式文檔被發(fā)送到用于傳輸?shù)膫髡孑d體。在步驟146中，處理并語法分析所生成的傳真載體報告。在所述接收者列表上設(shè)置傳輸狀態(tài)。處理然后繼續(xù)到步驟172。
對于電子郵件路徑而言，在步驟148中，在需要時將合并后的文檔轉(zhuǎn)換為MHTML格式。通常，無需轉(zhuǎn)換為MHTML，因為所述文檔保持為PDF、HTML或微軟Word附件。在步驟150中，包括作為附件或作為嵌入MTHML的文檔的電子郵件消息被發(fā)送到用于傳輸?shù)碾娮余]件載體。在步驟152中，處理并語法分析所生成的電子郵件載體報告。在所述接收者列表上設(shè)置傳輸狀態(tài)。處理然后繼續(xù)到步驟172。
對于水陸路郵件路徑而言，在步驟154中，在需要時將合并后的文檔轉(zhuǎn)換為Postscript格式。在步驟156中，所述Postscript格式文檔被發(fā)送到用于傳輸?shù)某Ｒ?guī)水陸路郵件載體。在步驟158中，處理并語法分析所生成的水陸路郵件載體報告。在所述接收者列表上設(shè)置傳輸狀態(tài)。處理然后繼續(xù)到步驟172。
對于SMS消息路徑而言，在步驟160中，在需要時為SMS格式化合并后的文檔。在步驟162中，所述SMS格式文檔被發(fā)送到用于傳輸?shù)腟MS載體。在步驟164中，處理并語法分析所生成的SMS載體報告。在所述接收者列表上設(shè)置傳輸狀態(tài)。處理然后繼續(xù)到步驟172。
對于歸檔路徑而言，在步驟166中，在需要時格式化合并后文檔，以便歸檔。所述格式通常為PDF或Postscript，然而所述歸檔系統(tǒng)并不限于任何特定格式，因此所述格式取決于始發(fā)者的偏好。在步驟168中，格式化的文檔被發(fā)送到所述歸檔系統(tǒng)。在步驟170中，處理并語法分析所述歸檔系統(tǒng)所生成的報告。在所述接收者列表上設(shè)置傳輸狀態(tài)。處理然后繼續(xù)到步驟172。
在步驟172中，如果需要，依據(jù)接收者列表狀態(tài)和傳遞偏好176處理逐步升級。在步驟178中，進行檢查以確定是否需要任何逐步升級。如果步驟178返回真(是)，對于為其發(fā)生逐步升級的接收者，處理繼續(xù)到步驟174。否則，如果步驟178返回假(否)，則處理在步驟180中終止。
此處引入作為參考的澳大利亞臨時專利申請No.20029050435的在圖11和11A-11M的類圖內(nèi)描述了用于提供圖1過程100的軟件體系結(jié)構(gòu)。在澳大利亞臨時專利申請No.20029050435內(nèi)，圖11描述了圖11A-11M各部分的布置。類圖提供了應(yīng)用體系結(jié)構(gòu)，以及構(gòu)成應(yīng)用的各部分的詳細描述。所述部分包括逐步升級處理、狀態(tài)處理、作業(yè)提交和處理、合并、格式化和載體傳輸。所述方案通信所述體系結(jié)構(gòu)的若干方面。
以下將詳細描述所述過程的其它方面。
III.(多個)業(yè)務(wù)接口本發(fā)明實施例優(yōu)選地被提供為托管業(yè)務(wù)，通常被稱為應(yīng)用業(yè)務(wù)提供商(ASP)模型。優(yōu)選的是，三種不同的接入方法用于接入托管業(yè)務(wù)，并分別由三種不同接口部分支持。在圖2內(nèi)描述了所述業(yè)務(wù)接口200，其包括網(wǎng)絡(luò)業(yè)務(wù)接口(SOAP)210、FTP接口212和網(wǎng)絡(luò)圖形用戶接口(基于瀏覽器/HTML)214。所述三種外部接口部分210、212和214都使用相同的基礎(chǔ)公共接口部分216，優(yōu)選的是XML。
網(wǎng)絡(luò)業(yè)務(wù)是通用描述、發(fā)現(xiàn)和集成(UDDI)和網(wǎng)絡(luò)服務(wù)定義語言(WSDL)標準所描述的正式接口。所述托管業(yè)務(wù)提供了一種符合于此標準的接口210。FTP(文件傳送協(xié)議)是用于經(jīng)由互聯(lián)網(wǎng)傳送文件的公共協(xié)議。所述托管業(yè)務(wù)提供了FTP接口212，因為所述接口212是眾所周知的、始發(fā)者容易接入的接口。所述網(wǎng)絡(luò)圖形用戶接口214被用于使始發(fā)者能夠經(jīng)由圖形用戶接口手動地提交作業(yè)。
各種接口210、212、214是輕便的，將數(shù)據(jù)整理為公共格式，以提交給如圖2所示的基礎(chǔ)公共接口216。所述接口參數(shù)作為XML被傳送。XML方案已被定義為描述作業(yè)。所述方案提供了一種用于為不同媒體提供不同文檔模板、并為特定作業(yè)規(guī)定其它偏好的機制。表1示出了圖1的所述公共XML作業(yè)描述文件(“JobDescriptor”XML)108的格式，包括所述XML方案內(nèi)的重要標志。
表1
標志描述<job_type>job_type標志允許設(shè)置總體作業(yè)類型，定義所有接收者經(jīng)由其發(fā)送消息的媒體。所述標志優(yōu)先于預計與即將發(fā)生的逐步升級功能一起使用的transmission_rules標志，從而允許一組傳輸規(guī)則作為在作業(yè)層而非接收者層的逐步升級規(guī)則而被提供。
所支持的作業(yè)類型包括<job_ype>FAX ONLY</job_type>
<job_type>EMAIL ONLY</job_type>
<job_type>FAX AND EMAIL</job_type>
<job_type>FAX AND EMAIL AND SMS</job_type>
(…等——允許媒體的所有組合)<job_type>LIST PREFERENCE</job_type>
LIST PREFERENCE作業(yè)類型使用在接收者層面上設(shè)置的傳輸規(guī)則。詳見RecipientData.xml。
<transmission_rules>transmission_rules標志允許在作業(yè)層上定義一組傳輸規(guī)則。所述規(guī)則適用于所述特定作業(yè)的所有接收者，例如<transmission_rules>fe</transmission_rules>
<fax_template> 傳真模板標志允許為出于傳真?zhèn)鬏斈康纳傻奈臋n定義模板，例如<fax_template>AcmeRelativeImage.xsl</fax_template>
<email_template>電子郵件模板標志允許為出于電子郵件傳輸目的生成的文檔定義模板，例如<email_template>AcmeRelativeImage.xsl</email_template>
<paper_template>紙面模板標志允許為出于經(jīng)由傳統(tǒng)信件發(fā)送目的生成的文檔定義模板，例如
<paper_template>AcmeRelativeImage.xsl</paper_template>
<emai_body_template>電子郵件主體模板允許包括文本電子郵件主體，所述電子郵件主體被經(jīng)由電子郵件媒體發(fā)送到所有接收消息發(fā)送的接收者。所述標志包含作為電子郵件主體包括的文本數(shù)據(jù)。所述標志可能包括被定義的合并字段<<ff(merge_field_name)>>。所述合并字段標志的生成是通過按下alt鍵并鍵入0171來生成<<以及0187來生成>>，例如<email_body_template>
Dear<<ff_fistname>>，請找到包括的、您對月<<ff_month>>的陳述。
致意<<ff_creditmanager>>
</email_body_template>
<emai_subject_template>電子郵件主題模板允許包括文本電子郵件主題，所述電子郵件主題被經(jīng)由電子郵件媒體發(fā)送到所有接收消息發(fā)送的接收者。所述標志包含作為電子郵件主題包括的文本數(shù)據(jù)。所述標志可能包括被定義的合并字段<<ff(merge_field_name)>>。所述合并字段標志的生成是通過按下alt鍵并鍵入0171來生成<<以及0187來生成>>，例如<email_subject_template>
請找到被包括的您對<<ff_monty>>月的陳述。
</email_subject_template>
<sms_template>電子郵件主題模板允許包括的SMS消息主體被發(fā)送到接收者。所述標志包括作為SMS主體發(fā)送的文本數(shù)據(jù)，并可能包括被定義的合并字段<<ff_(merge_field_name)>>。所述合并字段標志的生成是通過按下alt鍵并鍵入0171來生成<<以及0187來生成>>，例如<sms_template>
您<<ff_monty>>月的陳述已被電郵給<<ff_emailaddress>>，
</sms_template>
<associated_image>相關(guān)圖像標志允許包括可能必需作為文本合并一部分的0-n個圖像，例如<assicuated_image>Acme.gif</associated_image>
<recipient_list> 接收者列表標志定義用于提供所有接收者細節(jié)和合并數(shù)據(jù)的所述接收者數(shù)據(jù)。更多信息請詳見RecepientData.xml，例如<recipient_list>AcmeSmall.xml</recipient_list>
IV.可插數(shù)據(jù)文件轉(zhuǎn)換器使用托管業(yè)務(wù)的始發(fā)者將包括關(guān)于作為目標的接收者的信息作為特定成批通信的部分提交。所述文件可能是從內(nèi)部數(shù)據(jù)庫或商家、機構(gòu)等的記賬系統(tǒng)中提取的。本發(fā)明實施例標準化XML輸入文件，因此數(shù)據(jù)轉(zhuǎn)換300將接收者列表文件310轉(zhuǎn)換為圖3所示的XML 314。例如，所述接收者列表文件310可能是文本或平面文件。這是使用數(shù)據(jù)文件轉(zhuǎn)換器312來執(zhí)行的，所述數(shù)據(jù)文件轉(zhuǎn)換器優(yōu)選的是使定制的轉(zhuǎn)換器能夠被插入基礎(chǔ)平臺的組件。于是，所述輸入文件的轉(zhuǎn)換對于所述業(yè)務(wù)的用戶而言是透明的。在本發(fā)明實施例中，數(shù)據(jù)轉(zhuǎn)換被實施為Java接口被定義為CustomMapperInterface所述Java接口具有以下所定義的方法ConvertFile(Hashmap hm，Destination d)所述JobDescriptor.xml輸入文件具有指示是否使用客戶映射器的“CustomlJavaMapping”標志，可規(guī)定轉(zhuǎn)換類別的“CustomJavaClassName”標志，以及可規(guī)定文件名的鍵控組的“JavaMappingFile”標志。
所述作業(yè)處理引擎使用Java的反射能力，以例示所述客戶Java轉(zhuǎn)換器類別，并將JavaMappingFile參數(shù)傳遞到Hashmap內(nèi)的客戶Java轉(zhuǎn)換器類別。
所述客戶Java類別然后處理文件參數(shù)，并生成轉(zhuǎn)換后文件。
V.文本合并器本發(fā)明實施例格式化數(shù)據(jù)，以傳遞到不同類型的媒體。圖4示出了如何相應(yīng)地處理文檔合并400。所述XML接收者列表410(對應(yīng)于圖3的列表314)和XSL或XSL-FO模板412被提供給文檔合并模塊或部分414，以便以所需格式，優(yōu)選的是PDF或HTML，生成文檔416。為了執(zhí)行所述說明格式化，所述XSL和XSL-FO標準被用于定義用于格式化和XML數(shù)據(jù)說明的規(guī)則。所述文檔合并模塊或部分414將所選擇XSL或XSL-FO模板412應(yīng)用于基礎(chǔ)XML接收者列表410，以生成傳輸?shù)剿鲇脩舻腜DF或HTML文檔416。
為了使單個接收者列表能夠用于基于所述接收者的傳遞偏好合并(個人化)和傳遞數(shù)據(jù)到各個不同媒體，圖10a、10b和10c定義和示出了特定XML接收者列表方案1000。盡管圖10示出了一種特定方案，但本領(lǐng)域技術(shù)人員應(yīng)當理解，依據(jù)本公開，在并不背離本發(fā)明精神和范圍的情況下，可對此方案做出修改和/或替換。所述方案1000被分為兩個主要子部分1.傳輸規(guī)則組，其描述不同媒體的接收者的尋址和偏好準則。
2.接收者數(shù)據(jù)部分，其包括被合并到所傳送文檔內(nèi)的數(shù)據(jù)?？筛鶕?jù)我們的XML方案構(gòu)造所述接收者數(shù)據(jù)部分。作為選擇，提供了一種XML數(shù)據(jù)子單元類型，其允許始發(fā)者根據(jù)其自己的XML方案構(gòu)造這部分接收者數(shù)據(jù)。
VI.偏好規(guī)則處理本發(fā)明實施例允許通過將特定符號用于定義偏好規(guī)則，為單個接收者規(guī)定偏好規(guī)則，包括復雜偏好規(guī)則。例如，本發(fā)明實施例使用符號(FS-P)來表示發(fā)送傳真和SMS，且如果兩者都失敗，則借助水陸路郵件(紙面)發(fā)送。優(yōu)選的是，用戶接口用于選擇傳遞偏好，而簡化符號用于規(guī)定傳遞偏好。表2詳細示出了傳遞媒體類型的規(guī)則符號表2媒體 符號傳真 F或f電子郵件 E或eSMS S或s紙面 P或p語音 V或v歸檔 A或a加密電子郵件(密碼)C或c將被確定的新媒體類型為了適合于優(yōu)先規(guī)則，以及將多個媒體類型組合為一個規(guī)則的能力，使用若干算符。列表偏好被規(guī)定為一系列以線(-)分隔的規(guī)則。所述線(-)指示，如果前面的規(guī)則失敗，則使用下一規(guī)則。如下所述，規(guī)則可能很簡單，例如規(guī)定單個媒體類型(例如F用于傳真)，或以加號(+)或冒號()算符分隔的一串媒體類型。圓括號“(”“)”用于封裝包括多個媒體類型的規(guī)則。
說明使用線(-)算符的簡單優(yōu)先規(guī)則的實例為E-F-P(1)此規(guī)則指示發(fā)送電子郵件(規(guī)則1)。如果規(guī)則1失敗(例如，如果并未指定電子郵件地址)，則發(fā)送傳真(規(guī)則2)。如果規(guī)則2失敗，則經(jīng)由基于紙面的媒體發(fā)送(規(guī)則3)。
如果兩種媒體類型被以加號(+)算符分隔，則這表示將信息發(fā)送到兩種所述特定媒體類型(無優(yōu)先順序)。如果兩者都無法發(fā)送，則所述規(guī)則失敗。例如規(guī)則(F+E)指示試圖發(fā)送電子郵件和傳真。如果既未提供傳真號碼，又未提供電子郵件地址，則所述規(guī)則失敗。
加號(+)算符和優(yōu)先算符(-)的組合的實例是(E+F)-P(2)此規(guī)則指示發(fā)送傳真和電子郵件。如果這兩種媒體都失敗(例如，因為未指定傳真號碼和電子郵件地址)，則線(-)算符發(fā)揮作用，處理移至指示以紙發(fā)送所述文檔的下一規(guī)則。
如果兩種媒體類型由冒號()算符分開，則這指示發(fā)送到兩種特定媒體類型(無優(yōu)先順序，即與加號(+)算符相同)。然而，如果無法發(fā)送到其中一個媒體，則此規(guī)則失敗。例如，(FE)指示試圖發(fā)送電子郵件和傳真。如果未提供傳真號碼，或未提供電子郵件地址，則此規(guī)則失敗。冒號()算符與優(yōu)先算符(-)組合的實例是(EF)-P(3)此規(guī)則指示發(fā)送傳真和電子郵件兩者。如果一種媒體失敗(例如，因為未指定傳真號碼或電子郵件地址)，則線(-)算符發(fā)揮作用，處理移至下一規(guī)則，其指示以紙發(fā)送所述文檔。
各個算符的優(yōu)先順序如下()，+，，-。首先評估圓括號，在冒號()之前評估加號(+)算符，這些都在線(-)之前評估。解釋使用所有不同算符，并說明優(yōu)先規(guī)則如何作用的復合規(guī)則的實例為(EF+S)-(PV)(4)在這種情況下，圓括號具有優(yōu)先級，因此首先評估規(guī)則(EF+S)。加號(+)的優(yōu)先級緊隨圓括號，因此然后評估規(guī)則F+S。這指示將信息發(fā)送到傳真和SMS。然后評估“”，因此接著評估規(guī)則E“F+S”。這指示將信息發(fā)送到電子郵件和“F+S”(這指示發(fā)送到傳真和SMS)。所述信息被發(fā)送到電子郵件、傳真和SMS三者。如果規(guī)則(F+S)失敗，則這是因為傳真和SMS都失敗。規(guī)則E“F+S”的失敗發(fā)生是因為電子郵件或“F+S”都失敗。如果整個第一規(guī)則E“F+S”失敗，則線(-)算符發(fā)揮作用，實踐下一規(guī)則(PV)。所述規(guī)則(PV)指示將信息發(fā)送到紙面和語音?？偠灾瑢嵗?4)的規(guī)則指示將信息發(fā)送到電子郵件、傳真和SMS媒體。如果電子郵件失敗(例如未指定電子郵件地址)，或SMS和傳真都失敗(例如無SMS和傳真號碼)，則所述信息被發(fā)送到紙面和語音。
在本發(fā)明實施例中，用戶接口部分或模塊允許快速輸入簡單傳遞組合，同時提供輸入復合規(guī)則的選項。圖8所示的用戶接口部分800被授權(quán)廣播選項，并包括用于每個媒體類型，包括傳真、電子郵件、SMS、語音和紙面，的若干記號框符(tick box)802。單選按鈕804被用于發(fā)送到所有媒體，并使用列表偏好。用戶可指定以框符文本條目806(例如(E+S)-F-P)跳過所述列表偏好的規(guī)則。
偏好規(guī)則處理器解釋接收者偏好，并為每個接收者確定發(fā)送到哪個傳遞媒體。圖5示出了一種用于處理偏好規(guī)則的方法500。XML格式的接收者數(shù)據(jù)510被提供給步驟512，其依據(jù)具體情況裝載第一或下一個接收者的偏好規(guī)則數(shù)據(jù)。在步驟514中，處理從先前處理結(jié)束的位置開始。在步驟516中，進行檢查以確定是否為處理保留了更多的字符。如果步驟516返回假(否)。則規(guī)則處理的當前一輪在步驟548中結(jié)束。否則，如果步驟516返回真(是)，則處理在步驟518中繼續(xù)。
在步驟518中，依據(jù)表示優(yōu)先算符或媒體符號的字符實施執(zhí)行分支。如果步驟518確定“(”或“)”，則處理繼續(xù)到步驟520。在步驟520中，進行檢查以確定包括何種圓括號類型。如果在步驟520中確定“(”，則處理繼續(xù)到步驟522，并記錄開括號(open parathensis)。否則，如果在步驟520中確定“)”，則處理繼續(xù)到步驟524。在步驟524中，記錄閉括號(close parathensis)，并生成一組先前規(guī)則組。從每個步驟522和524開始，處理繼續(xù)到步驟516。
如果步驟518確定當前符號為字母(F，E，S，P，A，C)，則處理繼續(xù)到步驟526。在步驟526中，進行檢查以確定所述字母為F、E、S、P、A還是C。如果步驟526返回F，則處理繼續(xù)到步驟528，接收者被加入傳真列表。如果步驟526返回E，則處理繼續(xù)到步驟530，接收者被加入電子郵件列表。如果步驟526返回C，則處理繼續(xù)到步驟532，接收者被加入加密電子郵件列表。如果步驟526返回P，則處理繼續(xù)到步驟534，接收者被加入水陸路郵件(紙面)列表。如果步驟526返回S，則處理繼續(xù)到步驟536，接收者被加入SMS列表。如果步驟526返回A，則處理繼續(xù)到步驟538，接收者被加入歸檔列表。從每個步驟528、530、532、534、536和538開始，處理繼續(xù)到步驟516。
如果步驟518確定當前字符是算符“”、“+”或“-”，則處理繼續(xù)到步驟540。在步驟540中，進行檢查以確定哪個算符為當前字符。如果步驟540返回“-”，則處理繼續(xù)到步驟542，記錄“-”符號之后的位置。處理然后繼續(xù)到步驟548。如果步驟540返回“-”，則處理繼續(xù)到步驟544，并記錄“-”(OR)算符。處理繼續(xù)到步驟516。如果步驟540返回“+”，則處理繼續(xù)到步驟546，并記錄“+”(AND)算符。處理然后繼續(xù)到步驟516。
VII.發(fā)射機所述發(fā)射機執(zhí)行數(shù)據(jù)的最終轉(zhuǎn)換，以顯示給載體接口。例如，對于傳真，從文檔合并過程輸出的PDF文檔被轉(zhuǎn)換為Tiff文件，以顯示給傳真載體。所述系統(tǒng)允許不同發(fā)射機被插入適合于不同載體的地方。
VIII.載體接口所述載體接口執(zhí)行最終的數(shù)據(jù)轉(zhuǎn)換，以及批處理為特定于載體的文件格式，以傳輸?shù)綖樘囟襟w類型所選擇的載體?？赡転椴煌d體接口插入備選載體，而載體的選擇可能被動態(tài)配置為始發(fā)者的用戶簡表的一部分。
IX.逐步升級處理器所述逐步升級過程檢查來自所述載體接口的響應(yīng)，并語法分析每個接收者的傳輸結(jié)果。如果傳輸失敗，則逐步升級過程使用接收者的偏好規(guī)則(經(jīng)由偏好規(guī)則處理器)來確定是否經(jīng)由不同媒體重試通信，并管理重新計劃經(jīng)由不同媒體傳輸數(shù)據(jù)的活動。圖6的流程圖示出了逐步升級處理600，尤其示出了電子郵件的逐步升級規(guī)則如何工作(電子郵件是最復雜的)。對于其它媒體類型而言，所述逐步升級簡單地基于從載體接收回的成功/失敗報告。
在圖6中，處理在步驟610中開始，其中嘗試將電子郵件發(fā)送到所述載體。在步驟612中，進行檢查以確定是否由于未知SMTP服務(wù)器而發(fā)生錯誤。如果步驟612返回真(是)，則處理在步驟624繼續(xù)。如果步驟612返回假(否)，則處理繼續(xù)到步驟614。在步驟614中，進行檢查以確定退回的電子郵件是否到達托管業(yè)務(wù)處的始發(fā)者的(客戶的)收件箱(Emdirect)。如果步驟614返回真(是)，則處理繼續(xù)到步驟622。在步驟622中，始發(fā)者人工指示發(fā)往接收者的電子郵件傳遞失敗。這優(yōu)選的是經(jīng)由網(wǎng)絡(luò)接口得以執(zhí)行。處理然后繼續(xù)到步驟624。如果步驟614返回假(N)，則處理繼續(xù)到步驟616。
在步驟616中，進行檢查以確定電子郵件打開期限是否已到期。如果步驟616返回假(否)，則處理繼續(xù)到步驟618。在步驟618中，處理等待，直至期限到期，然后處理繼續(xù)到步驟616。如果步驟616返回真(是)，則處理繼續(xù)到步驟620。在步驟620中，進行檢查以確定電子郵件跟蹤是否顯示所述電子郵件已打開。如果步驟620返回真(是)，則處理在步驟632終止，并不執(zhí)行逐步升級。如果步驟620返回假(否)，則處理繼續(xù)到步驟630。
在步驟624中，進行檢查以確定逐步升級是否需要始發(fā)者的批準。如果步驟624返回假(否)，則處理繼續(xù)到步驟630，并逐步升級到下一媒體類型。否則，如果步驟624返回真(是)，則處理繼續(xù)到步驟626。在步驟626中，進行檢查以確定是否已提供始發(fā)者批準。如果步驟626返回假(否)，則處理繼續(xù)到步驟628。在步驟628中，等待經(jīng)由網(wǎng)絡(luò)接口的人工始發(fā)者批準事件。處理然后繼續(xù)到步驟626。如果步驟626返回真(是)，則處理繼續(xù)到步驟630。以下將闡述過程的其它細節(jié)。
所述逐步升級處理提供了以下功能提供作為額外選項的逐步升級功能(在用戶層上被配置)、并相應(yīng)收費的能力。
在作業(yè)層上指定特定作業(yè)是否需要逐步升級的能力。
當在作業(yè)提交時選擇“列表偏好”時，根據(jù)接收者的傳遞偏好逐步升級工作的能力。
如果使用廣播選擇，而非“列表偏好”，逐步升級以遵循所指定選擇的能力(例如，電子郵件+傳真+紙面，首先嘗試電郵到所述接收者，然后如果電子郵件失敗，則實施傳真，如果傳真失敗，則實施紙面)始發(fā)者人工干預所述逐步升級過程，并人工指示將處理或不處理哪個逐步升級的能力。
用戶人工地將電子郵件標志為需要逐步升級的能力(因此始發(fā)者可了解到達的退回，然后前去網(wǎng)址，并將其標記為需要逐步升級)。
對于不同媒體類型而言，逐步升級準則如下。對于一些媒體類型而言，已描述了備選機制。當備選方案可用時，始發(fā)者選擇始發(fā)者可能應(yīng)用哪個逐步升級準則。這被配置為始發(fā)者的用戶偏好的一部分。
如果在預先規(guī)定數(shù)量的重試之后無法發(fā)送傳真，則逐步升級可能會發(fā)生。這可能歸因于各種原因，從無效的傳真號碼到網(wǎng)絡(luò)難以連接(NCN)到指定的傳真機。
如果在預先規(guī)定天數(shù)內(nèi)，接收者未跟蹤到電子郵件為打開，則可能發(fā)生逐步升級?？赡懿粫?zhí)行電子郵件退回的自動處理，但可能提供一種功能，由此作業(yè)提交者可人工指示特定電子郵件并未被成功發(fā)送(經(jīng)由網(wǎng)絡(luò)接口)。如果無法聯(lián)系到SMS號碼(號碼無效)，則逐步升級可能會發(fā)生。這取決于這種級別的報告是否可由移動業(yè)務(wù)提供商提供。
如果無法成功讀出水陸路郵件地址的條形碼，則逐步升級可能會發(fā)生。無法讀出水陸路郵件地址的條形碼，可能出于各種原因——例如可能沒有郵政編碼或郵政編碼無效，或特定街道的街道號無效。
以下字段在用戶配置屏上可用于存儲以下與逐步升級相關(guān)的用戶偏好如果無打開記錄則逐步升級電子郵件嗎？如果以上為是，則在逐步升級之前電子郵件必需未打開多少天？需要將電子郵件人工標記為需要經(jīng)由網(wǎng)絡(luò)接口逐步升級的能力嗎？在任何逐步升級實際發(fā)生之前需要人工干預嗎？對于已配置“逐步升級”的始發(fā)者而言，所有經(jīng)由網(wǎng)絡(luò)接口提交的作業(yè)自動開啟逐步升級。逐步升級根據(jù)所選擇的廣播偏好繼續(xù)，或如果列表偏好被選為廣播偏好，則逐步升級根據(jù)單個接收者的列表偏好繼續(xù)。
對于已配置逐步升級的始發(fā)者而言，經(jīng)由JobDescriptor.XML文件內(nèi)的FTP接口可得到附加選項。這是“逐步升級”標志。如果“逐步升級”標志被設(shè)置為“Y”，則逐步升級適用于所述作業(yè)。根據(jù)所選擇的廣播偏好繼續(xù)逐步升級，或如果列表偏好被選為廣播偏好，則根據(jù)單個接收者的列表偏好繼續(xù)逐步升級。
作業(yè)處理引擎跟蹤每個接收者的傳遞狀態(tài)，并在接收者的逐步升級事件發(fā)生時(例如接收到壞的傳真報告，或電子郵件在X天內(nèi)未打開，或用戶人工標記特定作業(yè)需要逐步升級)，使接收者沿著逐步升級路徑移動。
可能經(jīng)由網(wǎng)絡(luò)接口設(shè)置逐步升級電子郵件的人工標記。在提交作業(yè)之后，始發(fā)者能夠搜索所述作業(yè)，然后選擇“增加電子郵件逐步升級”按鈕。這為所述始發(fā)者提供了所有電子郵件接收者的列表，而所述始發(fā)者能夠檢查與所述始發(fā)者希望逐步升級的任何接收者鄰近的“逐步升級”框符。此顯示屏的目的主要是適合于所述始發(fā)者已接收到電子郵件退回，因此希望人工指示需要逐步升級的情況。此功能還適合于其它情況，其中始發(fā)者/發(fā)送者已預先了解所述接收者將不會接收電子郵件(例如——電子郵件到財務(wù)部，但了解到規(guī)則的電子郵件聯(lián)系在度假，因此希望發(fā)送傳真/信件，從而使得其替身接收到傳真/信件)。
逐步升級狀態(tài)在提交作業(yè)之后，用戶可在任何時候搜索作業(yè)，然后觀察所有所述接收者的當前狀態(tài)，以及所述接收者已逐步升級或正在等待始發(fā)者批準繼續(xù)逐步升級。還示出了逐步升級的原因(例如“3次重試之后傳真失敗”，“5天內(nèi)電子郵件未打開”，“街道地址的街道號碼無效”，“人工標記為逐步升級”等)。
逐步升級處理根據(jù)逐步升級狀態(tài)屏，如果始發(fā)者已在其簡表內(nèi)配置“人工干預”，則始發(fā)者能夠選擇“過程逐步升級”功能。這顯示等待逐步升級的接收者的列表。對于任何已發(fā)生逐步升級事件的接收者而言，存在著靠近于接收者狀態(tài)行的“繼續(xù)”檢查框符。所述始發(fā)者能夠標記(經(jīng)由“標記所有”按鈕)始發(fā)者希望繼續(xù)為其逐步升級的一些或所有接收者，然后按下“繼續(xù)所選擇逐步升級”按鈕。
消息重試根據(jù)逐步升級狀態(tài)屏，所述始發(fā)者還能夠選擇“重試消息”功能，其顯示等待逐步升級的接收者列表。除了逐步升級之外，所述始發(fā)者能夠相對于特定接收者選擇“重試”或“以修改后地址重試”。如果選擇“以修改后地址重試”，則首先將提示修改后傳真號碼、電子郵件地址或水陸路郵件地址的屏顯示給所述用戶。對于這兩種選擇而言，應(yīng)用然后繼續(xù)嘗試使用舊的或更新后細節(jié)重新發(fā)送到所述接收者。所述用戶可為其希望重新發(fā)送到的每個接收者執(zhí)行所述進程(每次執(zhí)行一個)。如果重新發(fā)送嘗試成功，則將不再處于逐步升級狀態(tài)。如果重新發(fā)送嘗試失敗，則接收者回復到等待逐步升級狀態(tài)。只要選擇“以修改后地址重試”，就還向始發(fā)者電郵原件的拷貝，以及修改后細節(jié)，以提醒始發(fā)者更新其自己的數(shù)據(jù)庫。
當一組接收者的逐步升級事件發(fā)生時，(歸因于接收到顯示失敗的傳真狀態(tài)報告，或用于指示電子郵件需要逐步升級的“打開”期限到期)，電子郵件被發(fā)送到提交所述作業(yè)的始發(fā)者。如果始發(fā)者已配置“人工干預”選項，則所述始發(fā)者然后能夠前進到網(wǎng)絡(luò)上的逐步升級狀態(tài)屏，以便人工繼續(xù)逐步升級。
X.報告部分報告部分負責從載體接口接收傳遞報告，并將所述傳遞報告組合為一個公共狀態(tài)格式，以存儲到相關(guān)數(shù)據(jù)庫內(nèi)。所述報告部分還包括始發(fā)者所使用的圖形接口和工具，以生成和觀察集成傳遞報告(經(jīng)由基于網(wǎng)絡(luò)的HTML接口觀察它們，或經(jīng)由電子郵件接收它們)。
圖7是說明如何語法分析不同載體報告、并將其存儲在數(shù)據(jù)庫內(nèi)，以使網(wǎng)址能夠?qū)⒓蓤蟾骘@示給始發(fā)者的過程700的流程圖。在步驟710中，通過提交消息發(fā)送作業(yè)開始處理。在步驟712中，接收信息被存儲在接收者數(shù)據(jù)的數(shù)據(jù)庫內(nèi)714。在步驟716中，消息被經(jīng)由FTP發(fā)送到載體。在步驟718中，經(jīng)由FTP從所述載體接收報告。在步驟720中，語法分析所述載體報告，并將接收者傳輸結(jié)果存儲到數(shù)據(jù)庫內(nèi)。傳輸在步驟722中結(jié)束。從步驟720開始，所述狀態(tài)在接收者數(shù)據(jù)庫內(nèi)被更新。
在獨立但相關(guān)的過程內(nèi)，用戶始發(fā)者可能在步驟726內(nèi)請求狀態(tài)報告。所述接收者數(shù)據(jù)庫內(nèi)更新后的狀態(tài)信息被提供給步驟726之后的步驟728。
XI.合并/傳輸?shù)牟⑿行?流水線以這樣一種方式設(shè)計托管業(yè)務(wù)，即組成合并和傳遞過程的子任務(wù)在可能的情況下同時運行。這種設(shè)計能夠?qū)崿F(xiàn)所述托管業(yè)務(wù)內(nèi)的高吞吐量，并使托管業(yè)務(wù)能夠提供其所支持的復雜逐步升級進程。圖9示出了不同部分902、904、906的多個實例900如何同時操作，以使數(shù)據(jù)吞吐量流線型。具體而言，合并模塊902的多個實例同時操作，并將輸出提供給多個并行發(fā)射機模塊904中的對應(yīng)一個。所述發(fā)射機模塊904反過來耦合到多個載體906中的對應(yīng)一個。
B.第二實施例I.概述本發(fā)明實施例提供了一種方法、系統(tǒng)和計算機產(chǎn)品(網(wǎng)絡(luò)業(yè)務(wù))，用于基于接收者的傳遞偏好、并引入如果傳遞失敗則根據(jù)接收者的偏好逐步升級到不同媒體，從而經(jīng)由多個傳遞媒體(傳真、電子郵件、SMS、水陸路郵件和歸檔)將信息成批通信給單個接收者組。以面向?qū)ο蠓绞介_發(fā)計算機軟件，從而使得其由多個子部分構(gòu)成。指向所述軟件的用戶接口優(yōu)選的是被作為網(wǎng)絡(luò)業(yè)務(wù)傳遞。
消息廣播業(yè)務(wù)使用以下技術(shù)(A)所述系統(tǒng)識別與客戶通信所需的公共單元，并逐步升級XML文檔內(nèi)的那些單元。所述單元包括客戶的傳遞偏好，以及一組改發(fā)準則。使用唯一簡化符號指定傳遞偏好和改發(fā)準則。專有XML方案已被定義為描述XML文檔格式。
(B)所述系統(tǒng)提供了可遠程接入和安全的電子接口。單個數(shù)據(jù)流以一致方式支持所有形式的消息發(fā)送?？山?jīng)由交互式網(wǎng)絡(luò)用戶接口提供所述數(shù)據(jù)流，或通過互聯(lián)網(wǎng)借助非交互式成批提交(借助FTP或其它協(xié)議)來提供所述數(shù)據(jù)流。
(C)所述系統(tǒng)支持一種用于指定數(shù)據(jù)轉(zhuǎn)換器的機制。所述系統(tǒng)具有安裝在內(nèi)的專用代碼，其能夠動態(tài)寫和插入定制的數(shù)據(jù)轉(zhuǎn)換器。所述數(shù)據(jù)轉(zhuǎn)換器取得任何格式的接收者數(shù)據(jù)(即從機構(gòu)的記賬或ERP系統(tǒng)提取)，并將所述數(shù)據(jù)轉(zhuǎn)換為公共XML格式，以饋入消息發(fā)送引擎。
(D)所述系統(tǒng)提供數(shù)據(jù)合并(個人化)能力，以使所述系統(tǒng)能夠?qū)⒔邮照邤?shù)據(jù)合并為各種文檔格式，包括PDF、HTML、TIFF、微軟Word和文本。所述系統(tǒng)使用XSL-FO格式化引擎來執(zhí)行所述數(shù)據(jù)合并。所述個人化能力包括個人化電子郵件消息的主旨和主體文本以及經(jīng)由SMS發(fā)送的消息的能力。
(E)所述系統(tǒng)管理以下所有載體接口SMS、電子郵件、傳真、常規(guī)(平)郵和歸檔。這是通過在所述系統(tǒng)內(nèi)具有獨立的代碼層來執(zhí)行的，所述代碼層將公共載體接口提供給剩余的消息發(fā)送引擎。這還使未來的媒體類型能夠容易地并入系統(tǒng)(例如WAP)。
(F)所述系統(tǒng)通過獲取從所述載體接收回的不同類型的報告、并將所述報告轉(zhuǎn)換為存儲在相關(guān)數(shù)據(jù)庫內(nèi)的公共格式，從而將單個集成報告接口提供給所述用戶。所述系統(tǒng)然后相對于單個消息接收者協(xié)調(diào)這些傳遞報告，以便跟蹤傳遞并驅(qū)動逐步升級進程。這使得所述系統(tǒng)能夠?qū)㈥P(guān)于單個消息成功和失敗的報告提供給所述用戶，并顯示已為單個接收者采取的逐步升級路徑。
(G)所述系統(tǒng)還被以能夠?qū)崿F(xiàn)大量消息發(fā)送吞吐量的方式實施。通過將所述合并過程內(nèi)的步驟分成不同部分來執(zhí)行所述大量消息發(fā)送。所述部分然后被同時執(zhí)行，從而使得許多不同步驟得以同時執(zhí)行。
·(A)能夠為單個接收者指定傳遞偏好，以及改發(fā)規(guī)則。例如，接收者可指定所述接收者偏好經(jīng)由傳真接收通信，但如果傳真失敗則借助水陸路郵件發(fā)送。
·(B)存在著一個借助其將接收者信息提供給所述系統(tǒng)的數(shù)據(jù)流。經(jīng)由所述一個流，可經(jīng)由傳真、電子郵件、SMS、水陸路郵件和歸檔中的任何一個執(zhí)行傳遞。
·(C)所述接收者列表可以是任何格式，所述系統(tǒng)將所述列表轉(zhuǎn)換為XML。
·(D)可使用所有不同傳遞媒體的接收者列表內(nèi)的字段，執(zhí)行合并(個人化)(包括個人化SMS文本消息、電子郵件主體和主題文本，以及Word、PDF、HTML和MHTML的文檔合并)。
·(E)所述系統(tǒng)管理到載體的所有接口(包括水陸路郵件郵寄商店和托管歸檔業(yè)務(wù))。無需在所述始發(fā)者處安裝或管理任何軟件。
·(F)單個接收者列表可用于傳遞到所有不同目標媒體。
·(G)傳遞結(jié)果的集成報告，包括關(guān)于已發(fā)生的逐步升級、以及所有接收者通過不同媒體類型的成功/失敗的報告。
·(H)所述系統(tǒng)被特意設(shè)計用于“成批郵件發(fā)送”情況，其中以類似于其中大量接收者被常規(guī)水陸路郵件郵寄店作為目標的方法的方式，大量接收者被作為目標。
·允許公司和機構(gòu)使用所述一個系統(tǒng)，經(jīng)由一個接口，并使用單個接收者列表，但經(jīng)由所有當前可用媒體傳遞執(zhí)行與其客戶的成批通信，所述可用媒體包括常規(guī)(平)郵、電子郵件(加密和未加密)、傳真和SMS、以及將文檔傳遞到托管文檔歸檔和檢索系統(tǒng)。
·其還支持單個接收者層面以及總體層面上的傳遞偏好和改發(fā)規(guī)則的技術(shù)規(guī)范。
·所述系統(tǒng)管理到傳真、電子郵件和SMS載體和常規(guī)(平)郵郵寄商店的接口。
·所述系統(tǒng)還支持各種輸入接收者文件格式，并將數(shù)據(jù)轉(zhuǎn)換為XML格式。
·所述系統(tǒng)通過將XML文檔格式以及XSL和XSL-FO樣式表用于數(shù)據(jù)格式化和說明來支持文檔合并。
·所述系統(tǒng)已被以實現(xiàn)大量消息吞吐量的方式實施。
·所述系統(tǒng)提供了集成報告接口，所述集成報告接口使得用戶能夠觀察單個接收者的消息發(fā)送和逐步升級狀態(tài)。
所述技術(shù)作為托管業(yè)務(wù)被提供，通常被稱為應(yīng)用業(yè)務(wù)提供商模型，或是以完全得到許可的形式被提供。存在三種不同的方法接入所述系統(tǒng)，所述三種不同接入方法由兩個不同接口部分支持。兩個外部接口部分都使用相同的基礎(chǔ)公共接口部分。圖29是描述包括成批接口3010、網(wǎng)絡(luò)接口3012和公共接口3020的系統(tǒng)3000。
A.網(wǎng)絡(luò)圖形用戶接口(基于瀏覽器/HTML)3012對于希望經(jīng)由圖形用戶接口人工提交作業(yè)的實體而言，基于網(wǎng)絡(luò)瀏覽器的HTML接口3012被提供給所述系統(tǒng)。
B.成批接口3010支持了通過互聯(lián)網(wǎng)的作業(yè)成批提交。這允許客戶的ERP系統(tǒng)將作業(yè)直接發(fā)送到所述系統(tǒng)。FTP(文件傳送協(xié)議)是用于經(jīng)由互聯(lián)網(wǎng)傳送文件的公共協(xié)議。所述業(yè)務(wù)提供了作為成批接口3010的FTP接口，因為所述接口是眾所周知的便于實體接入的接口?？赡苓€使用諸如通用描述、發(fā)現(xiàn)和集成(UDDI)以及網(wǎng)絡(luò)業(yè)務(wù)定義語言(WSDL)標準所描述的正式接口的其它提交接口。
C.公共接口3020各種接口3010、3012是輕便的，將數(shù)據(jù)整理為公共格式，以提交給如圖29所示的基礎(chǔ)公共接口3020。所述接口參數(shù)被作為XML傳送。
所述報告部分負責從所述載體接口接收傳遞報告，并將所述報告組合為一個公共狀態(tài)格式，以存儲在相關(guān)數(shù)據(jù)庫內(nèi)。所述部分還包括用戶用于生成和觀察集成傳遞報告的屏幕和工具(經(jīng)由基于網(wǎng)絡(luò)的HTML接口觀察它們，或經(jīng)由電子郵件接收它們)。圖7示出了如何語法分析不同的載體報告，并將其存儲在所述數(shù)據(jù)庫內(nèi)，以使所述網(wǎng)址能夠?qū)⒓蓤蟾骘@示給所述用戶。
為了提供一種使單個接收者列表能夠被用于合并(個人化)并傳遞數(shù)據(jù)給各個不同媒體的機制，基于接收者傳遞偏好，定義了一種特殊的XML方案。圖30示出了接收者列表XML方案。
關(guān)鍵不同點在于·消息分配系統(tǒng)是用于將消息廣播到幾百或幾千接收者的通用產(chǎn)品。
·數(shù)據(jù)可被以任何電子格式提交給所述消息分配系統(tǒng)，包括經(jīng)由許多接口的打印流，但并不僅限于此。
·所述消息可被廣泛地為每個接收者個人化。
·XML技術(shù)被用于定義支持有力合并功能的復雜消息模板。
·所述消息分配系統(tǒng)引入了被稱為數(shù)據(jù)轉(zhuǎn)換器或Java映射類的有力特征。這允許所述消息分配系統(tǒng)接受任何格式的接收者信息。
·消息可被同時發(fā)送到傳真、電子郵件、紙面或SMS?？扇菀椎丶尤胄旅襟w類型(例如PDA)。“歸檔”的輸出媒體類型(允許輸出消息被拷貝到歸檔)的設(shè)計正在發(fā)展中。
·每個接收者都可指定一種不同的媒體類型。因此，單個消息分配可被借助紙面發(fā)送到一些接收者，借助電子郵件發(fā)送到另外一些接收者，借助傳真發(fā)送到又一些接收者，等等。
·提供了“改發(fā)”特征。如果消息無法被傳遞到接收者的第一選擇媒體，則所述消息分配系統(tǒng)重試所指定的第二選擇，甚至是第三選擇。因此，例如，如果發(fā)往特定接收者的傳真?zhèn)鬏斒?，則所述消息分配系統(tǒng)自動嘗試借助電子郵件、紙面或其它發(fā)送。分別為每個接收者指定改發(fā)規(guī)則，或在需要時為整個作業(yè)全局地指定改發(fā)規(guī)則。
在本發(fā)明第二實施例中，如圖11所示公開了電子消息廣播系統(tǒng)。所述消息分配系統(tǒng)1100被特別設(shè)計為處理“一個到多個”情況，其中單個消息1110由所述消息分配系統(tǒng)1100(尤其是由系統(tǒng)引擎1120)接收，并被廣播到幾十、幾百或幾千個目的地1130。所述消息分配系統(tǒng)提供了將消息分別“適合于”發(fā)往每個接收者的功能。消息被經(jīng)由互聯(lián)網(wǎng)或借助專用通信鏈路接收和傳送。
消息可能包括文本、圖形、所嵌入音頻/視頻，實際上包括任何可電子表示的內(nèi)容。
所述消息分配系統(tǒng)可用于廣播各種信息，范圍從備忘錄和銷售材料到發(fā)票和報表。
圖12是詳細說明圖11的系統(tǒng)引擎1120的全面體系結(jié)構(gòu)的方框圖?；ヂ?lián)網(wǎng)接口1210耦合到應(yīng)用服務(wù)器1220，應(yīng)用服務(wù)器1220耦合到數(shù)據(jù)庫服務(wù)器1240。可使用PC硬件1232，例如使用微軟Windows2000操作系統(tǒng)來實施應(yīng)用1220。
所述應(yīng)用服務(wù)器1220包括Java虛擬機1228、JDBC 1230、ApacheTomcat網(wǎng)絡(luò)服務(wù)器1224以及JBoss應(yīng)用服務(wù)器1226。所述應(yīng)用服務(wù)器1220還包括含有Java程序和功能的應(yīng)用軟件1222。
所述數(shù)據(jù)庫服務(wù)器1240包括PC硬件1246上的操作系統(tǒng)級(例如微軟Windows 2000)、JDataConnect 1244和SQL服務(wù)器1242。
所述系統(tǒng)優(yōu)選的是在位于安全數(shù)據(jù)中心內(nèi)的計算機上運行。希望其它消息分配系統(tǒng)安裝在其它位置的數(shù)據(jù)中心內(nèi)。所述系統(tǒng)軟件1220優(yōu)選的是以Java編程語言寫，并可能包括多個第三方應(yīng)用程序包(其多數(shù)還被設(shè)計為用于Java平臺)。所述消息分配系統(tǒng)使用XML標準來表示數(shù)據(jù)。
所述消息分配系統(tǒng)可在廣泛的平臺上運行，例如所述系統(tǒng)可在使用微軟的Windows 2000的PC“應(yīng)用服務(wù)器”1232、1246上運行。所述Java程序環(huán)境由Apache Tomcat網(wǎng)絡(luò)服務(wù)器1224和JBoss應(yīng)用服務(wù)器1224提供。
所有不變數(shù)據(jù)被保持在經(jīng)由Java JDBC接口1230接入的另一PC“數(shù)據(jù)庫服務(wù)器”1240的消息分配系統(tǒng)數(shù)據(jù)庫內(nèi)。所述數(shù)據(jù)庫軟件可能是微軟的SQL服務(wù)器1242，其使用JDataConnect軟件1244來處理到消息分配系統(tǒng)服務(wù)器的鏈接。
II.概念所述消息分配系統(tǒng)優(yōu)選的是被實施為專門為大量消息發(fā)送市場開發(fā)的軟件。所述系統(tǒng)控制被稱為消息分配系統(tǒng)引擎的消息發(fā)送計算機。
所述消息分配系統(tǒng)從發(fā)送者接受消息(即，文本、圖形、聲音/視頻文件等的電子表示)，并將所述消息的拷貝分配給多個(幾十、幾百或幾千)接收者。一般而言，發(fā)送者是某個機構(gòu)，而接收者是個人或其它機構(gòu)。發(fā)送者可能是客戶，并由客戶id識別。在此文檔中，依據(jù)上下文可互換地使用術(shù)語“發(fā)送者”和“客戶”。所述消息的內(nèi)容可能被專門設(shè)計用于每個接收者，而消息的總體格式對于所有接收者而言一般都是類似的。例如，假設(shè)發(fā)送者是銀行，消息表示每月銀行報表。所述消息的總體格式(即所述銀行的名稱、銀行的標志、欄目標題等)對于所有接收者而言都是相同的，但細節(jié)(即接收者的名稱和地址、賬戶余額和單筆貸/借交易)對于每個接收者而言是不同的。
從發(fā)送者接受消息、并將所述消息的多個拷貝分配給接收者的整個過程被稱為作業(yè)。當作業(yè)完成時，所述消息分配系統(tǒng)自動為發(fā)送者準備作業(yè)狀態(tài)報告。所述報告總結(jié)作業(yè)的結(jié)果(即多少接收者消息被成功傳遞，以及多少接收者消息傳遞失敗)，并以單個接收者為基礎(chǔ)提供成功/失敗的細節(jié)(例如嘗試了多少次到特定接收者的傳遞，以及為何失敗)。
所述消息分配系統(tǒng)還準備一組包括關(guān)于每個接收者消息傳輸結(jié)果的更詳細信息的賬單記錄。所述賬單記錄被發(fā)送到計費系統(tǒng)，在計費系統(tǒng)中在月末將賬單記錄用于為客戶開發(fā)票。
每個用戶都被分配一個或多個消息分配系統(tǒng)賬戶(每個賬戶由賬戶id識別)。每個作業(yè)必須與賬戶相關(guān)。所述賬戶定義作業(yè)的特定操作特征(例如傳真紙的最大尺寸、所需打印質(zhì)量以及可使用的消息分配系統(tǒng)特征等)，且所述賬戶被用于計費過程，以確定對于所述作業(yè)向用戶收費多少?？蛻敉ǔ？赡軙⒍嘟M適當配置的賬戶指配給他企業(yè)內(nèi)的機構(gòu)單元(成本中心、部門或其它)。
發(fā)送者通常借助在線網(wǎng)絡(luò)接口與所述消息分配系統(tǒng)相互作用(即提交作業(yè)、檢索作業(yè)狀態(tài)報告等)。所述客戶任命其機構(gòu)內(nèi)的特定個人來執(zhí)行所述相互作用；所述個人被稱為用戶(其由客戶內(nèi)的唯一用戶id識別)。用戶借助諸如互聯(lián)網(wǎng)瀏覽器或Netscape接入網(wǎng)絡(luò)接口。
在一些情況下，作為網(wǎng)絡(luò)接口的備選，用戶可使用FTP文件傳送將作業(yè)通過互聯(lián)網(wǎng)提交給所述消息分配系統(tǒng)。在本文檔的后面將討論此選擇。
接收者可經(jīng)由多個由不同載體傳遞的不同媒體接收他的消息。所述媒體包括·電子郵件——所述消息分配系統(tǒng)將所述消息電子地發(fā)送到載體，所述載體將所述消息作為電子郵件發(fā)送到接收者的電子郵件地址，所述消息被嵌入電子郵件主體和/或作為附件。
·紙面——所述消息分配系統(tǒng)將所述消息電子地發(fā)送到載體，所述載體打印消息、將所打印消息置于信封內(nèi)并將所述消息通過郵寄系統(tǒng)郵寄給接收者。
·SMS——所述消息分配系統(tǒng)將所述消息電子地發(fā)送到載體，所述載體將所述消息作為文本傳遞到所述接收者的移動電話。
·傳真——所述消息分配系統(tǒng)將所述消息電子地發(fā)送到載體，所述載體將所述消息轉(zhuǎn)發(fā)到所述接收者的傳真機。
預計未來將引入其它媒體。所述系統(tǒng)體系結(jié)構(gòu)被設(shè)計為以最小努力支持引入新媒體?？赡軙嵤┰试S輸出消息被發(fā)送到檔案文件的“檔案”媒體。
所有上述媒體可唯一尋址。所述地址被稱為目的地id。
目的地id的格式對于每個媒體類型而言都是不同的。對于傳真機和移動電話而言，目的地id是電話號碼，對于紙面而言，目的地id是郵寄地址，而對于電子郵件而言，目的地id是電子郵件地址。因此，特定接收者可能具有以下目的地id，例如傳真目的地id +61 21234 5678SMS目的地id +61 438 987654紙面目的地id Mr P Jones，24 Waratah St，St Leonards，NSW，2065電子郵件idpioes@bigpond.com.au使用每種媒體類型的一個目的地id。以“每個接收者”為基礎(chǔ)指定目的地；在任何特定作業(yè)中，每個接收者可指定不同媒體和不同目的地。
為了啟動作業(yè)，用戶將模板文件和接收者文件提交給所述消息分配系統(tǒng)。作業(yè)可能需要一個或多個模板文件。模板文件僅包括單個模板。對于每個傳遞媒體而言，作業(yè)需要一個或多個模板。例如，處理SMS和電子郵件的作業(yè)可能需要一個模板用于SMS消息、五個模板用于電子郵件消息(一個用于電子郵件主題、一個用于電子郵件主體的文檔版本、一個用于電子郵件主體的HTML版本、一個用于兩個電子郵件附件的每個)。
以各種不同格式提供模板，包括Adobe Acrobat PDF(PDF)格式、TIFF圖像(TIF)格式、Postscript(PRN)格式、XML樣式表(XSL)格式、微軟Word(DOC)格式和簡單文本(TXT)格式。
每種模板描述消息的不變部分(即對于所有接收者而言都是相同的那些部分)。
特定模板類型(即僅DOC、XSL和TXT)是“可個人化”的(即，它們可選包括一個或多個“合并字段”)。XSL模板也可能附有“模板工具文件”。
·合并字段在所述模板內(nèi)被稱為“占位符”。每個合并字段都指示在所述消息分配系統(tǒng)為特定接收者生成消息時，特定于接收者的數(shù)據(jù)被插入的地方。因此，例如，模板可能包括被稱為“cust_name”“account_balance”和“date”的合并字段，其可能出現(xiàn)在如圖13所示的模板1300內(nèi)。
·為說明起見，圖13的實例示出了“chevron”字符劃界的合并字段。這是它們實際如何出現(xiàn)在DOC和TXT模板內(nèi)(而不是XSL模板內(nèi))。
·模板工具文件可能附帶XSL模板文件。這些包括圖形、聲音、視頻剪輯或其它多媒體文件。例如，如果銀行報表消息包括標志，則所述模板文件可能附帶包括適當圖形的圖像文件(可能被稱為“BandLogo.jpg””)。
作業(yè)需要一個或多個接收者文件。當接收到所述接收者文件時，所述消息分配系統(tǒng)將所述接收者文件一起集中或組合為單個文件。所述文件的內(nèi)容被稱為接收者列表。
所述接收者列表包括許多接收者記錄(通常幾百或幾千)。每個接收者記錄都可能包括描述消息的一個預定接收者的文本。接收者記錄可能包括以下信息·接收者信息——所述記錄包括一些關(guān)于接收者的基本信息，例如他的姓名和參考代碼。
·目的地id——對于每個可借助其將消息傳遞到所述接收者的媒體而言，都存在一個目的地id。因此，例如，如果接收者可能僅借助電子郵件或傳真接收消息，則所述接收者記錄僅包括電子郵件地址和傳真電話號碼；“紙面”和“SMS”的目的地id為空(指示無法借助郵件或SMS聯(lián)系接收者)。指定目的地id不是必然意味著使用所述id。在“目的地偏好信息”內(nèi)指定了用于傳遞特定消息的目的地id。
·合并值——接收者記錄包括對應(yīng)于所述模板文件內(nèi)“合并字段”的“合并值”。當消息分配系統(tǒng)為所述接收者生成消息時，所述合并值由所述消息分配系統(tǒng)置于所述合并字段內(nèi)。例如，模板可能包括被稱為“<<account_balance>>”的合并字段，而特定接收者記錄可能包括“$451.34”的合并值。當所述消息被傳遞到接收者時，文本“$451.34”，而非合并字段名稱出現(xiàn)在所述消息內(nèi)。
·目的地偏好信息——目的地偏好信息告知所述消息分配系統(tǒng)將所述消息發(fā)送到哪個目的地。
·對于每個接收者而言，最多指定數(shù)量(例如3)的傳遞嘗試可被指定為目的地偏好信息的一部分。每次嘗試都可指定到不同目的地id的最多特定數(shù)量(例如3)傳輸；第一次傳輸是主傳輸，而其它傳輸是拷貝傳輸。
·所述消息分配系統(tǒng)以第一次嘗試開始。所述系統(tǒng)同時發(fā)送主和拷貝傳輸。如果所述主傳輸無法到達所述接收者，則所述消息分配系統(tǒng)進行下一次嘗試。處理以這種方式繼續(xù)，直至主傳輸已成功完成，或直至所有嘗試都結(jié)束。
·以這種方式多次嘗試傳遞主傳輸被稱為改發(fā)?！翱截悺眰鬏?shù)娜魏问≡谒鱿⒎峙湎到y(tǒng)看來無關(guān)緊要，且并不導致改發(fā)。
·以上由圖14實例示出。接收者記錄1400指定圖14所示的嘗試和傳輸。所述消息分配系統(tǒng)首先將主傳輸發(fā)送給傳真，并同時將拷貝發(fā)送給電子郵件。如果所述主傳輸(即傳真)成功，則完成所述接收者的處理。
如果所述主傳輸失敗(例如，如果傳真號碼占線或不可得到)，則所述消息分配系統(tǒng)啟動嘗試序號2(即，所述系統(tǒng)嘗試將主傳輸發(fā)送到紙面，將拷貝發(fā)送給SMS)。這標記所述消息分配系統(tǒng)的處理的結(jié)束，因為并未指定第三次嘗試。
III.網(wǎng)絡(luò)接口用戶與所述消息分配系統(tǒng)之間的相互作用可能借助網(wǎng)絡(luò)瀏覽器接口實現(xiàn)。為了開始與所述消息分配系統(tǒng)相互作用，用戶簡單地起動網(wǎng)絡(luò)瀏覽器(例如微軟的互聯(lián)網(wǎng)瀏覽器或Netscape的瀏覽器)，并輸入適當?shù)腢RL。
輸入所述URL在所述用戶與消息分配系統(tǒng)引擎之間建立邏輯鏈接，并使圖16所示的“登陸屏”1600得以顯示。
以下將描述由所述消息分配系統(tǒng)顯示的屏幕以及如何使用。
客戶、用戶和賬戶所述網(wǎng)絡(luò)接口允許“用戶”(代表“客戶”，并在消息分配系統(tǒng)“賬戶”下操作)將作業(yè)提交給所述消息分配系統(tǒng)，并執(zhí)行其它操作。
在系統(tǒng)運營商的機構(gòu)內(nèi)，可能存在一組負責所述消息分配系統(tǒng)的操作控制以及支持消息分配系統(tǒng)的客戶的工作人員。他們在本文被稱為消息分配系統(tǒng)支持組。所述支持組具有所述系統(tǒng)的全面管理責任，尤其具有建立新客戶使用所述系統(tǒng)的作業(yè)。
當所述消息分配系統(tǒng)支持組的成員將新客戶引入所述系統(tǒng)時，所述組成員在消息分配系統(tǒng)數(shù)據(jù)庫內(nèi)生成以下項目·包括關(guān)于所述客戶的信息的單個“CUSTOMER”記錄，·若干“ACCOUNT”記錄，每個“ACCOUNT”記錄都包括關(guān)于所述客戶能夠使用的賬戶的信息，以及·描述管理員用戶(即具有特別特權(quán)的用戶)的一個或多個“USER”記錄·客戶的管理員用戶可能被允許生成所述客戶的一個或多個標準用戶(即不具有管理員特權(quán)的用戶)，因此標準用戶的管理在所述客戶的直接控制下。然而，管理員用戶可能僅由消息分配系統(tǒng)支持組生成。
所述消息分配系統(tǒng)保持與特定客戶相關(guān)的信息。所述信息可能包括客戶的賬戶信息、用戶信息以及關(guān)于所述客戶的用戶所提交的各個作業(yè)的信息。從接入控制的角度而言，所述信息可能包括并通常形成“封閉群”?？蛻舻挠脩魞H可接入關(guān)于與所述客戶相關(guān)的賬戶、用戶和作業(yè)的信息。所述用戶無法接入關(guān)于其它客戶的信息。這是所述消息分配系統(tǒng)的安全要求。
這可能有一個例外。所述消息分配系統(tǒng)支持組可能在所述消息分配系統(tǒng)內(nèi)以“控制”的客戶id登記為“特別客戶”。屬于此特別客戶的用戶(“控制用戶”)可能具有特別的權(quán)利，適合于所述消息分配系統(tǒng)支持組所執(zhí)行的監(jiān)管角色。特別地，僅對于控制用戶·管理員用戶可能得到授權(quán)，以接入和改變?nèi)魏慰蛻舻目蛻?、用戶和賬戶信息，并將作業(yè)提交給任何客戶，以及·標準用戶可能具有瀏覽(但不可改變)任何客戶的客戶、用戶和賬戶信息，并將作業(yè)提交給任何客戶，將電子郵件錯誤報告給任何客戶的能力。
控制用戶可能“模仿”任何指定客戶的用戶，并因而接入所述系統(tǒng)，如同所述控制用戶正代表所述客戶。當控制用戶以這種方式“模仿”客戶時，其被稱為代理客戶。
圖15的表1500總結(jié)了支配允許各種類型用戶執(zhí)行的網(wǎng)絡(luò)接口功能的規(guī)則。以下將提供圖15所示的功能描述。
圖15的以腳注“1”指示的功能是特定于客戶的。為所述指定代理客戶(即，所述控制用戶首先指定特定代理客戶，然后執(zhí)行功能)執(zhí)行所述功能。其它控制客戶功能無需首先指定代理客戶。至于圖15內(nèi)的腳注“2”，可能還允許用戶改變其自己用戶記錄上，而非其它用戶的USER記錄上的特定字段。
登錄圖16顯示了可能使用的登錄屏1600。所述用戶可能必需將客戶id、用戶id和密碼輸入登錄屏1600上。
屏幕布局一旦用戶成功登錄，則圖17的主屏1700被顯示，并保持顯示，直至用戶“取消”所述屏幕。所述主屏采取左邊主菜單的形式，在一些情況下，在頂端為一系列標記。圖17示出了方案。
左邊由主菜單占據(jù)(“主菜單”1、“主菜單”2等)。可能通過給所述選擇加黑邊框，突出當前所選擇的主菜單選項。(圖17內(nèi)的“主菜單”2)所述屏幕的頂端可能包括客戶名稱(其后是括號內(nèi)的客戶id)以及用戶姓名(其后是括號內(nèi)的用戶id)。所述用戶姓名和id識別當前登錄的用戶。所述客戶名稱和id可能指示“擁有”所述用戶的客戶，或如果所述客戶是“控制”，則指示代理客戶。代理客戶和管理員用戶可能被以斜體字顯示。
所述屏幕的剩余部分包括對應(yīng)于當前所選擇主菜單項目的控制板或控制板組(即一個或多個頂端相互重疊的控制板)。在控制板組的情況下，所述屏幕頂端的標記可能用于顯示(即在所述棧的頂端)所述組內(nèi)的單個控制板。每個控制板都包括含有描述文本、數(shù)據(jù)輸入字段、下拉菜單、單選按鈕、復選框和其它工具的信息。提交或取消所述控制板或調(diào)用幫助信息的按鈕可能位于所述按鈕處。
管理管理控制板組允許瀏覽、在一些情況下允許改變客戶的USER和ACCOUNT記錄。
圖18示出了用于瀏覽用戶的控制板實例。可能存在所述控制板的若干變量，一個用于正常用戶，一個用于客戶的(或控制)管理員用戶，一個用于所述USER記錄所代表的特定用戶。圖18示出了管理員用戶可見的控制板1800。
所述控制管理員用戶和客戶的管理員用戶可將信息輸入所述控制板上的任何字段。對于多數(shù)標準用戶而言，所有字段都是“只讀”的。對于此記錄應(yīng)用的標準用戶而言，除了“密碼”、“聯(lián)系”和“測試目的地”字段之外的所有字段都是“只讀”的。
多數(shù)字段與數(shù)據(jù)庫上USER記錄內(nèi)的字段存在“一對一”對應(yīng)關(guān)系。在“所述用戶可能向其提交作業(yè)的賬戶”的列表內(nèi)的所標記項目反映所述用戶的“USER_ACCOUNT_XREF”記錄。
提交消息分配系統(tǒng)作業(yè)用戶可能使用兩個接口中的一個將作業(yè)提交給消息分配系統(tǒng)。
·企業(yè)接口所述企業(yè)接口通常由擁有復雜計算機系統(tǒng)的大企業(yè)用于跟蹤和管理其客戶和供應(yīng)商。所述企業(yè)接口面向“基本郵件”，例如發(fā)票和報表。
·在這種情況下，消息格式趨向于復雜(并入標志和其它圖形)，但并不頻繁改變。這意味著適當模板的開發(fā)雖然是耗時的任務(wù)，但一旦完成就無需經(jīng)常重復。
·用于企業(yè)接口客戶的模板可能由消息分配系統(tǒng)支持組為客戶的技術(shù)規(guī)范開發(fā)的。完成的模板可能然后存儲于公司控制下的消息分配系統(tǒng)的數(shù)據(jù)庫內(nèi)。只要客戶運行作業(yè)，所述系統(tǒng)就會(通過引用適當作業(yè)類型)參考所述模板，但所述模板自身并不改變，而且實際上所述客戶無法修改所述模板。
·使用所述企業(yè)接口的客戶可能具有包括關(guān)于其供應(yīng)商、客戶、職員、伙伴等的聯(lián)系細節(jié)和其它信息的數(shù)據(jù)庫。因此，當所述客戶希望將消息經(jīng)由所述消息分配系統(tǒng)發(fā)送到各個接收者時，所述客戶可能相對于其自己的數(shù)據(jù)庫運行“數(shù)據(jù)庫提取”程序，以生成接收者文件。
·企業(yè)接口模板可能以XML樣式表(XSL)格式存儲。例外附件并不包括合并字段的電子郵件的情況可能是例外。它們可能被以Adobe Acrobat PDF格式指定。
·接收者文件格式廣泛改變，但所述消息分配系統(tǒng)在接收時將所述文件格式全部轉(zhuǎn)換為XML格式。
·作為使用所述企業(yè)接口的應(yīng)用的實例，考慮每月銀行報表作業(yè)。所述報表的大體格式(即標題、標志、樣板、文本等)并不由銀行規(guī)則地改變。所述格式可能由所述消息分配系統(tǒng)支持組為銀行的技術(shù)規(guī)范研發(fā)的一組XSL模板文件描述。然而，報表細節(jié)(客戶名稱、地址、交易細節(jié)、賬戶余額等)每月對于每個客戶是不同的。一般而言，所述報表細節(jié)由程序每月從銀行的主機數(shù)據(jù)庫中提取，然后被作為接收者文件轉(zhuǎn)發(fā)到所述消息分配系統(tǒng)。
·標準接口所述標準接口可能用于更小的不太復雜的作業(yè)。
·所述標準接口的用戶可能負責準備所述用戶自己的模板文件，只要所述用戶啟動作業(yè)就提供所述模板文件。這在所述模板相對簡單(例如可使用簡單字處理器準備的備忘錄、新聞稿和市場活動)的情況下是實用的。在這種情況下，其對于為每個消息分配新系統(tǒng)作業(yè)準備的新模板文件是共同的。
·在一些情況下(即其中涉及簡單的文本信息)，所述用戶可經(jīng)由標準接口在線輸入用戶的模板文件。在其它情況下，所述用戶可能脫機準備模板文件(例如，以微軟Word“DOC”格式)。
·接收者文件可能是“逗點分隔值”(CSV)格式，但可能由所述消息分配系統(tǒng)在接收時轉(zhuǎn)換為XML格式。
所述標準接口特別適合于這樣的客戶，其希望快速生成簡單備忘錄或銷售材料，并將所述消息廣播給其客戶。所述企業(yè)接口適合于穩(wěn)定應(yīng)用，例如報表和發(fā)票，其中所述格式持續(xù)一段時期，但在所述時期內(nèi)被重復使用。
表3和4以技術(shù)術(shù)語總結(jié)了所述兩個接口之間的區(qū)別。
表3特征

表4模板格式

發(fā)送到載體的消息的對應(yīng)格式可能改變·每個紙面消息可能被作為postscript文件發(fā)送到所述載體·每個傳真文件可能被作為一個或多個TIFF文件(帶有包括在簡單文本格式的特別標題內(nèi)的“主題”信息)發(fā)送到載體·每個電子郵件消息可能被以復合格式發(fā)送到所述載體，其中-主旨可能被以簡單文本形式編碼在特殊控制文件內(nèi)，-HTML和文本主體可能被分別編碼為HTML文件和簡單文本文件，-企業(yè)接口附件可能被作為PDF文件發(fā)送，以及-標準接口附件可能被以與最初接收格式相同的格式發(fā)送。
·以上規(guī)則的一個例外是DOC格式的任何標準接口附件被以PDF格式發(fā)送到所述載體。
·所述標準接口所處理的HTML文件優(yōu)選的是完全獨立的(所述文件并不包括對于諸如圖像文件的外部工具的參考)。
·每個SMS消息都被以文本形式發(fā)送到移動電話。
所述用戶首先選擇所述作業(yè)在其下運行的賬戶。所述“下拉”菜單可能列出所述用戶得到授權(quán)使用的所有客戶(或代理客戶)的賬戶的名稱。當所述用戶點擊“提交”時，新的控制板被顯示，以反映(在所選擇賬戶內(nèi)指定的)企業(yè)接口或標準接口。
企業(yè)接口圖19示出了企業(yè)接口作業(yè)提交屏1900的布局。
·作業(yè)參考-所述作業(yè)參考字段可能是可選的。所述用戶可能輸入對其有意義的作業(yè)的名稱。所述名稱被顯示在所有與所述作業(yè)相關(guān)的報告上。
·作業(yè)類型-此字段向所述用戶提供作業(yè)類型的列表，每個所述作業(yè)類型都由對所述用戶有意義的名稱識別。所述用戶必須從所述列表中選擇一個項目。
-作業(yè)類型在所述消息分配系統(tǒng)數(shù)據(jù)庫內(nèi)表示為作業(yè)配置。每個作業(yè)配置都包括作業(yè)層信息，以及已由所述消息分配系統(tǒng)支持組預先準備、測試和存儲在所述數(shù)據(jù)庫內(nèi)的模板文件和模板工具文件的集合。
·接收者文件起初，可能向所述用戶提供一個文本輸入字段(帶有相關(guān)“瀏覽”和“上傳”按鈕)為了指定接收者文件，所述用戶點擊顯示瀏覽窗口的“瀏覽”按鈕。在所述用戶選擇所需文件之后，其文件路徑顯示在文本輸入字段內(nèi)。當所述用戶點擊“上傳”按鈕時，所述文件被上傳到所述消息分配系統(tǒng)，并出現(xiàn)在“上傳文件”列表內(nèi)。所述用戶可能以這種方式上傳用戶希望上傳的文件量。
-在“所上傳文件”列表一側(cè)的“刪除”按鈕可用于刪除所選擇的所上傳文件。
-所述消息分配系統(tǒng)的企業(yè)接口接受各種格式的接收者文件。所述接收者被轉(zhuǎn)換為XML格式，并以這種形式保持在轉(zhuǎn)換后形式數(shù)據(jù)庫內(nèi)。
·作業(yè)起動時間可能向所述用戶提供立即處理所述作業(yè)或?qū)⑺鲎鳂I(yè)安排為在以后日期和時間起動的選項。所述“日期”字段提供了將來最多30天的選擇。所述“時間”字段允許用戶指定精確到時分的起動時間。
所述用戶選擇“提交”來提交所述作業(yè)。在提交所述作業(yè)之后，所述消息分配系統(tǒng)定位所述模板、模板工具以及對應(yīng)于其數(shù)據(jù)庫內(nèi)所指定作業(yè)類型的其它作業(yè)信息。所述系統(tǒng)然后在需要時驗證接收者文件。如果在所述驗證過程期間內(nèi)遭遇錯誤，則所述消息分配系統(tǒng)錯誤地顯示接收者的細節(jié)。所述用戶然后校正所述錯誤，并重新提交所述作業(yè)。
觀察作業(yè)狀態(tài)報告用戶可能在作業(yè)被提交之后的任何時間請求作業(yè)狀態(tài)報告。所述消息分配系統(tǒng)從其數(shù)據(jù)庫上的信息得到所述作業(yè)的當前狀態(tài)，并將適當?shù)淖鳂I(yè)狀態(tài)報告顯示在所述屏幕上(如果用戶希望則用戶可打印)。
圖20的實例示出了使用企業(yè)接口提交的發(fā)票分配作業(yè)的全作業(yè)狀態(tài)報告2000(即包括所有四個選項)。所述報告2000可能被以“打印機友好”格式(白底黑色)顯示，并可能顯示在新的瀏覽器窗口內(nèi)。在所述實例內(nèi)，所述消息分配系統(tǒng)作業(yè)id是“34656”，而所述用戶所指配的作業(yè)參考是“發(fā)票3”。
所述作業(yè)被在22:21時在賬戶“基本郵件”下提交，而所述作業(yè)狀態(tài)報告被在4小時31分鐘之后生成(第二天早上2:52am)，同時所述作業(yè)仍然在“第二次嘗試”階段內(nèi)(如所述“作業(yè)狀態(tài)”指示)?？赡艿淖鳂I(yè)狀態(tài)是“處理并未開始”、“嘗試1正在進行中”、“嘗試2正在進行中”、“嘗試3正在進行中”、“完成”和各種錯誤狀態(tài)。所述作業(yè)指定763接收者，并被經(jīng)由所述企業(yè)接口提交。
所述報告的剩余部分指示生成所述報告時消息傳輸?shù)臓顟B(tài)。信息被分為三類·“主消息”信息涉及指定的每次嘗試在接收者記錄內(nèi)首先進行的傳輸。傳輸主消息的失敗潛在引起改發(fā)發(fā)生(即啟動下一次嘗試)。
·“拷貝消息”信息涉及并不觸發(fā)改發(fā)的其它所有傳輸。
·“電子郵件附件打開”僅指電子郵件附件的打開。
在實例報告2000內(nèi)，發(fā)送763個主消息，每個接收者一個。主消息中的12個失敗，并引起第二次嘗試。在763個主消息內(nèi)，兩個失敗(甚至是在嘗試任何指定的改發(fā)之后)。其它四個仍然未決(即已發(fā)送所述四個消息，但尚未確定傳遞狀態(tài))。其它94個“復制”消息被發(fā)送。在這些消息中，89個被成功傳遞，2個失敗，3個仍然未決。
所述報告的第二和第三段指定每個單個傳輸?shù)募毠?jié)。每個傳輸狀態(tài)都被以下述格式表示nn-mm-hh:mmd其中“nn”表示如下的傳輸狀態(tài)-“OK”指示成功。
-“IP”指示“正在進展中”。
-“NC”指示“未證實”(即假定OK，但未明確證實)?！癗C”狀態(tài)是電子郵件的特征，以下將解釋。
-“兩個數(shù)字”指示錯誤發(fā)生(數(shù)字指示失敗的原因)。
“mmm”是目的地媒體(EML、FAX、SMS或PAP)，“hh:mm”是傳遞或未傳遞的時間(或?qū)τ赟MS和紙面而言，傳輸?shù)捷d體的時間)，“d”是字包括在消息在后續(xù)日被傳遞(或無法傳遞)情況下的上標數(shù)字。數(shù)字“1”表示下一日，“2”表示再下一日等等。
在“主消息”段內(nèi)，其主消息傳輸失敗(即使是在若干次嘗試之后)，或仍然“正在進展中”的所有接收者被在報告的前端分組。其它由接收者參考排序。在“拷貝消息”段內(nèi)，接收者被以相同順序排列。所述報告的最后部分指示電子郵件附件打開的時間。每個附件都由“Xn”指示，其中“n”是識別所述段開始的圖例內(nèi)的附件的編號。上述報告2000僅僅是一個實例，在并不背離本發(fā)明精神和范圍的情況下可實踐許多改變。
作業(yè)配置(僅控制用戶)圖21A和21B的作業(yè)配置控制板2100可用于控制用戶，并用于在對應(yīng)于作業(yè)配置的所述消息分配系統(tǒng)內(nèi)增加、改變和刪除記錄群集?？赡軆H接入企業(yè)接口作業(yè)的作業(yè)配置。
在選擇“作業(yè)配置”主菜單選項之后，顯示選擇的控制板，以向所述用戶提供選擇現(xiàn)有作業(yè)配置或生成新作業(yè)配置的選擇。在完成所述控制板之后，顯示所述主作業(yè)配置控制板2100。
圖21A和21B的控制板2100顯示指定作業(yè)配置的完全細節(jié)。所述信息可能被格式化為若干由水平行分開的段。每個段都可能代表所述作業(yè)配置記錄群集內(nèi)的一個記錄。在所示的實例內(nèi)，所述作業(yè)配置包括JAVA_MAPPING_CLASS記錄、JAVA_MAPPING_CLASS_RESOURCE記錄、COFIG_DATA記錄、TEMPLATE記錄以及兩個TEMPLATE_ARTIFACT記錄。
每個段都示出了被輸入到所述記錄的文件的文件名，以及所述記錄內(nèi)其它字段的值。所述用戶可能在需要時改變字段。所述用戶可能還通過使用所述“輸入”按鈕前的“瀏覽”按鈕(可能調(diào)用所述用戶能夠從其選擇將要輸入的文件的“瀏覽”窗口)來輸入新文件(代替現(xiàn)有文件)。作為選擇，所述用戶可能使用“刪除”按鈕來刪除整個段(即刪除相關(guān)記錄)。
對于可重復的段而言，提供“增加一個新…記錄”按鈕來增加另一個空段。
在所述控制板底部的部分允許所述群集內(nèi)的文件被作為ZIP檔案輸出到指定文件。所述文件可能被以指定目錄(例如C\JobConfigurations)存儲在所述消息分配系統(tǒng)服務(wù)器上，并可能具有自動生成的名稱，即客戶名稱、作業(yè)配置顯示名稱(即作業(yè)類型)和日期的串接。直至用戶點擊“提交”按鈕方對所述數(shù)據(jù)庫做出改變。所述刪除按鈕允許在需要時刪除整個群集。
IV.FTP接口在特定情況下，客戶可能必需從其企業(yè)系統(tǒng)中生成接收者文件，并將所述文件發(fā)送到消息分配系統(tǒng)以便自動分配(即無需人工干預)。在這種情況下，所述網(wǎng)絡(luò)接口可能并不適合于其需要。所述消息分配系統(tǒng)因此允許“企業(yè)接口”式作業(yè)被借助FTP傳輸通過互聯(lián)網(wǎng)提交。所述FTP傳輸替代作業(yè)提交(以及相關(guān))屏幕。所述客戶、用戶和賬戶記錄應(yīng)當在所述FTP傳輸之前正確建立。
在FTP作業(yè)提交之后，用戶可能使用正常消息分配系統(tǒng)功能(即檢查作業(yè)狀態(tài)報告)，以監(jiān)控所述作業(yè)的過程。
為了經(jīng)由所述FTP接口提交作業(yè)，所述用戶使用FTP客戶程序，以將單個ZIP文件經(jīng)由互聯(lián)網(wǎng)發(fā)送到所述消息分配系統(tǒng)。所述傳輸過程可能被通過使用SSL安全來執(zhí)行，并需要所述用戶輸入FTP“用戶id”(其可能采取形式“ccccc-uuuuu”，其中“ccccc”是用戶的消息分配系統(tǒng)客戶id，而“uuuuu”是用戶的消息分配系統(tǒng)用戶id)以及FTP“密碼”(其可能與用戶的消息分配系統(tǒng)用戶密碼相同)。
所述ZIP文件包括以下文件·被稱為“jobcontrol.xml”的作業(yè)控制文件；以及·一個或多個在所述作業(yè)控制文件內(nèi)指定其名稱的接收者文件(見接收者文件)圖22示出了所述作業(yè)控制文件(jobcontrol.xml)2200的格式。所述文件內(nèi)的多數(shù)字段是其網(wǎng)絡(luò)接口同等物的對應(yīng)部分。測試屬性指定這是否為測試作業(yè)?？蛻艨赡苤付ㄎㄒ弧白鳂I(yè)參考”，從而使得客戶可隨后在“狀態(tài)報告”屏幕上識別所述作業(yè)。
V.系統(tǒng)體系結(jié)構(gòu)以下將描述所述消息分配系統(tǒng)的內(nèi)部體系結(jié)構(gòu)，包括選擇通過所述消息分配系統(tǒng)的主處理流。對于J2EE和Java網(wǎng)絡(luò)容件的全面了解是理想的，但對于理解以下描述并不重要。此段有時參考數(shù)據(jù)庫內(nèi)的表(或“記錄類型”)。它們的名稱被以大寫字母打印。所述記錄的功能和結(jié)構(gòu)的細節(jié)包括在段VII內(nèi)。
圖23是說明所述消息廣播系統(tǒng)2400的體系結(jié)構(gòu)的方框圖。所述系統(tǒng)2400包括前端2410和后端2420。用戶2402可使用模塊2412檢索作業(yè)狀態(tài)報告，使用所述標準接口2414提交作業(yè)，使用所述企業(yè)接口2416提交作業(yè)，所有都在所述前端2410內(nèi)。FTP文件2404可能被提供給所述企業(yè)接口2412。
在標準接口2414內(nèi)，從用戶2402接收信息，并上傳接收者列表和模板。調(diào)用“驗證”來檢查接收者列表。從所述用戶接收所述提交請求，并調(diào)用所述“提交”過程。
從接口2414，所述后端2420的標準作業(yè)提交處理器2424驗證或檢查輸入數(shù)據(jù)，并提交所述作業(yè)。這包括將所述接收者列表轉(zhuǎn)換為XML，并將所述作業(yè)存儲在所述作業(yè)隊列內(nèi)。處理然后在flux模塊2432處繼續(xù)。
所述企業(yè)接口從所述用戶2402接收作業(yè)信息，并上傳所述接收者列表。通過調(diào)用所述驗證過程來檢查所述接收者列表。從所述用戶接收所述提交請求，調(diào)用提交來處理所述請求。從所述接口2416，處理在所述企業(yè)作業(yè)提交處理器2426處繼續(xù)。其通過檢查所述輸入數(shù)據(jù)驗證所述接收者列表，并操作所述提交過程，所述提交過程將所述接收者列表轉(zhuǎn)換為XML，并將所述作業(yè)存儲在作業(yè)隊列內(nèi)。處理然后在flux2432內(nèi)繼續(xù)。處理器2424和2426的輸出是事件。作用然后從flux2462發(fā)生。
所述作用繼續(xù)到束處理器2450。模塊2452為每種媒體類型建立一個傳輸束，然后起動每個傳輸束的過程束線(a、b、c和d)。所述線被描述為A、B、C和D，并分別耦合到模塊2454、2456、2458和2460。每個所述模塊2454、2456、2458和2460都具有類似格式。例如，所述傳真?zhèn)鬏斒?454包括合并、格式化和傳送操作。紙面?zhèn)鬏斒?456、SMS傳輸束2458和電子郵件傳輸束2460具有類似設(shè)置。每個束模塊的輸出都被提供給各自的載體，例如作為載體的expedite 2462、EDI郵局2464、SMS通達2466和message通達2468。每個載體都將狀態(tài)報告提供回所述后端2420。Expedite 2462提供傳真狀態(tài)報告2442，EDI郵局2464提供紙面狀態(tài)報告2440，SMS通達2466提供SMS狀態(tài)報告2438，而message通達2468提供電子郵件狀態(tài)報告2436。
所述電子郵件狀態(tài)報告2436、SMS狀態(tài)報告2438、紙面狀態(tài)報告2440和傳真狀態(tài)報告2442被提供給狀態(tài)收集器模塊2434。所述模塊2434由Flux 2434周期性調(diào)用。其檢索由所述載體提供的狀態(tài)信息，并將其應(yīng)用于所述作業(yè)隊列。所述作業(yè)隊列2430具有作業(yè)和模板信息、接收者信息和狀態(tài)信息。所述作業(yè)隊列2430可將賬單記錄提供給所述計費系統(tǒng)2460，并將狀態(tài)信息更新給所述束處理器2450。所述作業(yè)隊列2430將輸出提供給所述狀態(tài)報告模塊2422，所述狀態(tài)報告模塊2422檢索狀態(tài)信息，優(yōu)選作為XML文檔。所述狀態(tài)報告模塊2422提供由所述前端2410內(nèi)的模塊2412檢索的作業(yè)狀態(tài)報告。所述用戶2402可檢索使用XSL樣式表格式化的所述XML狀態(tài)報告，并以打印機友好格式顯示所述XML狀態(tài)報告。以下將更為詳細地闡述這些和其它細節(jié)。
作業(yè)隊列所述作業(yè)隊列2430是所述消息分配系統(tǒng)2400的主要部分。所述隊列2430包括當前正在運行、等待運行或最近已完成的每個消息分配系統(tǒng)作業(yè)的細節(jié)。每個作業(yè)都由各種類型記錄的群集表示在數(shù)據(jù)庫內(nèi)。每個群集都以JOB記錄打頭。所述記錄包括作業(yè)自身的細節(jié)，所使用的模板，消息被發(fā)送到的接收者，合并字段和目的地。
在正常操作期間內(nèi)，所述消息分配系統(tǒng)2400在預定時間(例如每分鐘)掃描作業(yè)隊列2430，并提取正在運行或最近已完成的所有作業(yè)的細節(jié)。任何正顯示“控制臺”控制板的消息分配系統(tǒng)支持組瀏覽器接入所述數(shù)據(jù)提取，并使用所得到的數(shù)據(jù)，以顯示所述系統(tǒng)內(nèi)作業(yè)的當前狀態(tài)。這樣，所述消息分配系統(tǒng)支持組具有作業(yè)隊列2430的最新概覽。
所述支持組使用“作業(yè)控制”控制板所提供的功能來影響作業(yè)的處理(例如恢復錯誤作業(yè)，重新傳輸束文件等)。因此，所述作業(yè)隊列提供控制中心點，其可用于平滑所述系統(tǒng)2400的處理負載，迅速對客戶的請求做出反應(yīng)，并解決未預料到的問題，而不必從頭開始重新提交用戶的作業(yè)。
只要已驗證所述作業(yè)，且所述用戶經(jīng)由處理器2424或2426提交所述作業(yè)，作業(yè)即被放置在所述作業(yè)隊列2430內(nèi)。所述作業(yè)保持在所述隊列2430內(nèi)，直至已完成所述作業(yè)之后的一段時間(以便為所述用戶提供檢查所述作業(yè)所生成的作業(yè)狀態(tài)報告2422的時間)。其可能隨后由“回收站”過程刪除。
處理作業(yè)圖23示出了所述消息分配系統(tǒng)的高級體系結(jié)構(gòu)2400。較大框2400指示所述消息分配系統(tǒng)自身。數(shù)據(jù)結(jié)構(gòu)是模塊2434、2436、2438、2440、2442、2454、2456、2458和2460，而外部實體是模塊2402、2404、2460、2462、2464、2466和2468。過程由模塊2412、2414和2416(servlet和JSP)以及模塊2422、2424、2426、2434和2450(會話bean)描述。
所述系統(tǒng)2400基本上被分為兩半，前端2410和后端2420，而所述作業(yè)隊列2430代表它們之間的“橋”
·所述前端邏輯2410可能由在Tomcat容件內(nèi)運行的Java“JSP””和“servlet”提供。
·所述后端2420可能包括在JBoss容件內(nèi)運行的Java EJB“會話bean”(其使用EJB“實體bean”和其它Java對象)。
所述前端并不直接訪問所述數(shù)據(jù)庫，而是調(diào)用所述后端2420內(nèi)的會話bean執(zhí)行。
前端所述消息分配系統(tǒng)前端2410包括與處理所述用戶接口相關(guān)的邏輯。所述前端2410被設(shè)計為將快速響應(yīng)提供給用戶2402，因此可從前端2410排除冗長處理任務(wù)。
所述前端的主要功能是接收用戶2414、2416所提交的作業(yè)，并將其置于所述作業(yè)隊列2430上等待處理。圖示出了三個較重要的前端過程2412、2414、2416·經(jīng)由所述企業(yè)接口2416提交作業(yè)，·經(jīng)由所述標準接口2414提交作業(yè)，以及·請求作業(yè)狀態(tài)報告2412。
可能存在其它前端過程，但為簡化起見，所述過程并未包括在圖23內(nèi)。
每個“前端”過程(包括servlet和JSP的混合)具有執(zhí)行所有其數(shù)據(jù)庫檢索和更新的對應(yīng)“后端”會話bean。從數(shù)據(jù)庫接入/鎖定考慮，這允許所述前端2410通過釋放servlet和JSP來提供良好的交互式響應(yīng)。
Flux只要所述前端2410將作業(yè)放置于所述作業(yè)隊列2430上，所述“前端”(或更精確地說是所述前端的會話bean)觸發(fā)Flux事件2432。Flux是由SIMS軟件提供的事件調(diào)度工具。只要所述消息分配系統(tǒng)2400有效，所述調(diào)度工具即持續(xù)運行，作為Java虛擬機內(nèi)的獨立過程。所述工具將其自己的信息表保持在所述消息分配系統(tǒng)數(shù)據(jù)庫內(nèi)。這些由Flux2432整體管理。Flux模塊2432響應(yīng)于定時器或其它過程所觸發(fā)的事件，并對于每個采取預定義的作用。例如，當新作業(yè)被置于所述作業(yè)隊列2430上時，所述前端的會話bean定義將被立即(或如果所述用戶已預定隨后將運行的作業(yè)，則在某個未來的時間)觸發(fā)的Flux2432的事件。當觸發(fā)所述事件時，F(xiàn)lux2432調(diào)用所述“后端”2430內(nèi)的會話bean，以處理所述事件。
后端所述“后端”2420包括充當前端過程的“助手”的一組會話bean。所述后端會話bean執(zhí)行所述前端部分需要的數(shù)據(jù)庫接入操作。例如，·EnterpriseJobSubmissionProcessroBean.java執(zhí)行實施企業(yè)作業(yè)提交接口的servlet和JSP的數(shù)據(jù)庫操作。
·StatusReportBean.java從實施“作業(yè)狀態(tài)報告”功能的servlet和JSP所使用的數(shù)據(jù)庫收集狀態(tài)報告信息。
·AccountBean.java代表實施所述賬戶維持控制板的servlet和JSP執(zhí)行ACCOUNT記錄上的數(shù)據(jù)庫I/O。
所述后端2420還包括執(zhí)行所述消息分配系統(tǒng)2400的“實際工作”，即處理從所述作業(yè)隊列2430得到的作業(yè)的會話bean。作業(yè)的處理如下繼續(xù)1.所述消息分配系統(tǒng)2400掃描所述作業(yè)內(nèi)的所有RECIPIENT記錄，并為每個所述記錄識別鏈接到第一個ATTEMPT記錄的TRASMISSION記錄。每個都代表消息必須被作為第一次嘗試的一部分發(fā)送到的目的地。所述消息分配系統(tǒng)2400然后在存儲器內(nèi)生成若干傳輸束2454、2456、2458、2460(有時稱為“傳輸分組束”)。每個目的地媒體都存在一個傳輸束2454、2456、2458、2460(即，一個用于傳真，一個用于電子郵件等)，每個傳輸束包括若干傳輸分組。每個傳輸分組都包括關(guān)于帶有指向所述媒體的“第一次嘗試”目的地的接收者的信息。
因此，例如，如果特定RECIPIENT記錄在其第一次“嘗試”中指定到傳真和電子郵件的“傳輸”，則所述接收者的細節(jié)的拷貝在所述傳真?zhèn)鬏斒碗娮余]件傳輸束內(nèi)都出現(xiàn)。
2.所述傳輸束然后被在不同處理線上并行處理。每個傳輸束都被在三個階段內(nèi)處理合并階段——來自所述接收者記錄的合并值被替換為所述媒體的(多個)模板內(nèi)的適當合并字段，從而為每個接收者生成完全合并消息。
格式化階段——如果需要，將所述束內(nèi)的每個消息重新格式化為適當?shù)妮敵龈袷?例如用于傳真的TIFF)。
傳送階段——每個傳輸束都被寫入磁盤文件，然后被傳送到載體(例如用于傳真的Xpedite、用于電子郵件的MessageReach、用于紙面的EDI郵寄)，以向前傳輸?shù)狡淠康牡亍?br> 3.所述消息分配系統(tǒng)2400然后等待由所述載體提供的載體狀態(tài)報告。每個載體2462、2464、2466、2468生成每個所接收傳輸束的載體狀態(tài)報告。所述報告2436、2438、2440、2442將每次單個消息傳遞指示給接收者。載體狀態(tài)報告的檢索被稱為狀態(tài)收集2434。
4.所述消息分配系統(tǒng)2400使用各個載體狀態(tài)報告2436、2438、2440、2442內(nèi)的信息，以更新所述作業(yè)隊列2430內(nèi)的接收者狀態(tài)信息(保持在所述TRANSMISSION記錄內(nèi))。所述信息包括成功/失敗代碼、已完成的時間傳輸、所發(fā)送的頁/字節(jié)數(shù)量等。
一旦所述第一次“嘗試”的所有各種載體狀態(tài)報告已被接收，并置于所述作業(yè)隊列2430內(nèi)，所述消息分配系統(tǒng)2400即再次掃描所述作業(yè)隊列2430內(nèi)的接收者數(shù)據(jù)。如果存在著任何發(fā)往其的第一次嘗試主(即第一)傳輸失敗的接收者，則所述作業(yè)由消息分配系統(tǒng)2400(通過重復步驟1到4)使用其“第二次嘗試”傳輸來重新處理。如果所述兩次嘗試中的任何一次的主傳輸失敗，則以第三次嘗試傳輸再次重復所述過程。
在處理作業(yè)期間內(nèi)或之后的任何時間，所述客戶可能請求聯(lián)合“作業(yè)狀態(tài)報告”。這提供了所述作業(yè)細節(jié)的完全總結(jié)、接收者數(shù)量以及在此瞬間發(fā)送的每個消息的命運?？蛇x地，當作業(yè)完成時，所述用戶可將所述報告自動電郵給所述用戶。所述選擇被指示在賬戶記錄內(nèi)。所述消息分配系統(tǒng)可能生成一組計費記錄(一個用于到接收者的每次所嘗試的傳輸)，所述一組計費記錄包括每次傳輸嘗試的所有細節(jié)(即頁數(shù)、所發(fā)送的字節(jié)數(shù)、成功/失敗狀態(tài)等)，并將其發(fā)送到所述計費系統(tǒng)2460，其中所述記錄可能用于向客戶開發(fā)票。
VI.數(shù)據(jù)文件結(jié)構(gòu)以下將描述所述消息分配系統(tǒng)所使用的若干數(shù)據(jù)文件的格式。
模板文件可以各種格式提供模板文件，所述模板文件可分為兩組，即包括合并字段的模板文件和不包括合并字段的模板文件。
所述第一組可能包括XML樣式表(XSL)文件、微軟Word(DOC)文件和簡單文本(TXT)文件。
·XML樣式表(XSL)文件-XML樣式表是以XML符號表示的文件，所述XML符號精確描述文檔的格式(包括文本、圖像、頁邊距、標題、頁尾和其它工具)。所述文件還包括用于定義“合并字段”的規(guī)定。掃描接收者文件(XML格式)、提取每個接收者的“合并值”、將所述合并值與XSL樣式表組合以及為每個接收者生成輸出文檔(以稱為XSL:FO的格式)的過程，可能由被稱為Xalan(由Apache提供)的軟件產(chǎn)品執(zhí)行。XSL和XSL:FO的細節(jié)可在文檔內(nèi)找到可擴展樣式表語言(XSL)，版本1.0，W3C介紹，2001年10月15日，萬維網(wǎng)聯(lián)盟出版，在http//www.w3.org/TR/xsl內(nèi)可得到。
·微軟Word(DOC)文件-DOC文件可由微軟Word字處理器生成?！昂喜⒆侄巍笨杀辉谖臋n內(nèi)定義，并使用Word的標準“合并”功能以“合并值”替代。在所述消息分配系統(tǒng)內(nèi)，DOC模板的合并可能由微軟Word自身執(zhí)行。Word在Windows 2000控制下(即在Java虛擬機之外)作為直接執(zhí)行的獨立程序運行。所述消息分配系統(tǒng)可能使用微軟的DCOM功能與Word相互作用(即將模板和接收者文件傳遞到其并接收合并后結(jié)果)。
·文本文件(TXT)-文本文件是可能可選地包括合并字段的ASCII文本的簡單串。在適當?shù)牡胤?，允許“行末”字符(即<CR>和<LF>)，但不允許其它格式化的字符。
無法包括合并字段的其它模板類型包括·TIFF(TIF)文件TIFF文件包括位形形式的圖像。
·Adobe Acrobat文檔(PDF)文件所述文件的格式由Adobe發(fā)布。
·Postscript(PRN)文件Postscript文件被特別設(shè)計為驅(qū)動各種打印機(可能由所述消息分配系統(tǒng)用于生成指向紙面的輸出)。用戶通常通過將文本和其它信息輸入字處理器、然后將所述文件輸出到打印文件(其缺省狀態(tài)具有PRN的文件類型)，而非物理打印機，從而生成Postscript文件。
·HTML(HTM)文件HTML文件包括以HTML標示語言格式化的信息。
接收者文件所述企業(yè)接口2416的用戶以各種格式將文件提交給所述消息分配系統(tǒng)2400，而所述標準接口2414的用戶優(yōu)選地以“逗號分隔值”(CSV)格式提交所述文件。具體的Java類(數(shù)據(jù)轉(zhuǎn)換器的一部分)被用于在將所提交的文件置于所述作業(yè)隊列2430(在所述消息分配系統(tǒng)數(shù)據(jù)庫內(nèi))內(nèi)之前，將所述文件轉(zhuǎn)換為XML格式。所述類被保持在包括在所述數(shù)據(jù)庫中的作業(yè)配置的JAVA_MAPPING_CLASS內(nèi)。所述java映射類可能使用其它工具來輔助映射過程。這可能包括其它Java類、XFlat映射文件和XSL樣式表。所述工具被保持在包括在所述數(shù)據(jù)庫中的作業(yè)配置的JAVA_MAPPING_CLASS_RESOUCE內(nèi)。
XFlat映射文件是一組報表(以被稱為XFlat的格式轉(zhuǎn)換定義語言表示)，其可被提交給“XML轉(zhuǎn)換功能”，一種處理各種簡單格式轉(zhuǎn)換的程序。
XML格式XML格式的接收者文件包括若干<recipient>單元，每個接收者一個。圖24內(nèi)示出了這樣的一個文件2500(僅包括一個接收者)的實例。以下將簡要描述此實例內(nèi)的數(shù)據(jù)·個人細節(jié)“<personal-details>”單元包括指示接收者的標題、名和姓的子單元。它們在傳真“帶狀地址”內(nèi)使用(只要傳真被發(fā)送到接收者)，以及作為郵寄地址的第一行(當紙面郵件被發(fā)送到所述接收者時)?？蛇x的“<reference>”單元可用，其可能包括在所述消息分配系統(tǒng)所生成的作業(yè)狀態(tài)報告上出現(xiàn)的用戶指定文本的至多10個字符。所述發(fā)送者通常使用所述單元來以對接收者有意義的名稱(例如雇員編號、銀行賬戶號、醫(yī)療號等)識別所述接收者。
·目的地偏好“<destination-preference>”單元指定將用于所述接收者的目的地，以及在失敗情況下調(diào)用的改發(fā)選項。所述單元包括一個、兩個或三個“<attempt>”子單元。每個“<attempt>”子單元指定空格或逗號所分隔的一個、兩個或三個傳輸。每個“傳輸”都對應(yīng)于“<destination>”字段內(nèi)的“id”屬性，從而指示特定目的地。所指定的第一傳輸是“主”。在傳真的情況下，每次“傳輸”包括至多三次重試。
·目的地一個“<destination>”單元可能被允許用于每種媒體類型(如“媒體”屬性所指示的)。如果并未為特定媒體提供單元，則這意味著無法借助所述媒體到達接收者。所述“id”屬性被用作到先前所述“<attempt>”單元的鏈接，并可能包括任何便利的識別符。所述“<destination>”單元的子單元指定實際目的地自身。
允許兩種樣式的紙面地址。圖24示出了語法分析后的形式。未語法分析的地址也可被使用以下單元輸入·<address-line-1></address-line-1>
<address-line-2></address-line-2>
<address-line-6></address-line-6>
·接收者數(shù)據(jù)“<recipient-data>”單元包括合并字段。在以上實例中，存在代表發(fā)票上的單行的合并字段，這包括若干代表所述行內(nèi)信息項的子合并字段。然而，這僅是一個實例。所述“<recipient-data>”字段允許徹底的格式自由(倘若所述字段包括合式的XML)。
VII.數(shù)據(jù)庫結(jié)構(gòu)所述消息分配系統(tǒng)數(shù)據(jù)庫包括各種表。圖25是實體關(guān)系圖，2600示出了所述表和關(guān)系。在圖25中，數(shù)據(jù)庫表之間的“多到一”對應(yīng)關(guān)系由所述關(guān)系的“多”側(cè)上的“鳥足”指示。
以下將描述每個表(被稱為“記錄”或“實體”)與所述表內(nèi)的欄(有時稱為“字段”)。每個表都包括唯一主密鑰，優(yōu)選的是稱為“xxx_PK”(其中“xxx”是表的名稱)。所述密鑰是數(shù)據(jù)庫復制原因需要的，并通常是自動生成的。
客戶、賬戶和用戶所述消息分配系統(tǒng)具有關(guān)于客戶、賬戶和計費偏好的信息。所述消息分配系統(tǒng)僅需所述信息的子集。出于此原因，可能為客戶提供對于所述計費系統(tǒng)的直接在線接入，從而使得客戶對其賬戶和計費偏好具有直接控制(而所述消息分配系統(tǒng)子集在需要時被下載到所述消息分配系統(tǒng))。
數(shù)據(jù)可能被在所述消息分配系統(tǒng)與計費系統(tǒng)之間相互復制。如果這樣，則可能將保持在所述消息分配系統(tǒng)內(nèi)的所述數(shù)據(jù)的量可保持為最小。所述消息分配系統(tǒng)將與客戶相關(guān)的信息存儲為三個主實體，即客戶2610、用戶2612和賬戶2614。每個客戶“擁有”并管理其自己的用戶和賬戶組。以下將描述所述數(shù)據(jù)庫表和每個字段。
客戶所述表2610代表客戶，其是所述數(shù)據(jù)庫內(nèi)的其它所有實體鏈接到的“錨點”。
customer_PK自動生成的唯一主密鑰。
id客戶識別符。所述n個字符(n可能是8)的識別符唯一地識別所述客戶?？蛻舻拿總€用戶在登錄到所述消息分配系統(tǒng)時輸入所述客戶id。
name所述客戶的名稱(例如ABC銀行機構(gòu))。所述字段出現(xiàn)在各個屏幕以及關(guān)于所述客戶的報告上。
timezone_code識別所述客戶位于的時間區(qū)。
enabled指示所述客戶被啟用還是禁用的布爾標志。不允許禁用客戶接入所述消息分配系統(tǒng)(即所述客戶的所有用戶都無法登錄)。
enabled_change_time指示“enabled”標志最后改變的日期/時間。從所述數(shù)據(jù)庫刪除已經(jīng)禁用一段長的時期的客戶。
ftpJobSubmission如果所述客戶可經(jīng)由FTP提交作業(yè)，則設(shè)置為“真”。
用戶用戶記錄2612包括關(guān)于用戶(即接入所述消息分配系統(tǒng)的人)的信息。所述數(shù)據(jù)庫內(nèi)的所述表的實際名稱是“USER”。增加所述后下劃線字符，以避免與SQL保留字“user”的沖突。
user_PK自動生成的唯一主密鑰。
id用戶識別符。所述n個字符(n可能是8)的識別符唯一地識別所述用戶。所述用戶在登錄到所述消息分配系統(tǒng)時輸入所述用戶id。
name所述用戶名稱(例如Mary Smith)。所述字段出現(xiàn)在各個屏幕以及關(guān)于所述用戶的報告上。
password登錄時輸入的用戶密碼。
customer_FK鏈接到“擁有”所述用戶的客戶。
email，phone_number，fax_number，mobile_number這些字段可能包括所述用戶的聯(lián)系信息(從而使得所述消息分配系統(tǒng)支持組能夠在需要時聯(lián)系所述用戶)。
test_email，test_fax_number，test_sms_number這些字段包括將被用作測試作業(yè)目的地的所述用戶的電子郵件地址、傳真號碼和SMS電話號碼。
enabled指示所述用戶被啟用還是禁用的布爾標志。不允許禁用用戶接入所述消息分配系統(tǒng)。
enabled_change_time指示“enabled”標志最后改變的日期/時間?？赡軓乃鰯?shù)據(jù)庫刪除已經(jīng)禁用一段規(guī)定時期的客戶。
administrator指示所述用戶是否為管理員用戶的布爾標志。管理員用戶具有標準用戶無法得到的特定特權(quán)。
賬戶所述賬戶記錄2616包括關(guān)于賬戶的信息。每個賬戶2616都定義此賬戶下運行的作業(yè)的特征和限制。
account_PK自動生成的唯一主密鑰。
name賬戶名稱。這是對于作為賬戶催詢者的客戶有用的“有意義”名稱。
customer_FK到“擁有”所述賬戶的客戶的CUSTOMER記錄的鏈接。
enabled指示所述賬戶被啟用還是禁用的布爾標志。不允許禁用用戶接入所述消息分配系統(tǒng)。
enabled_change_time指示“enabled”標志最后改變的日期/時間?？赡軓乃鰯?shù)據(jù)庫刪除已經(jīng)禁用一段時期的賬戶。
enterprise指示所述賬戶需要標準接口還是企業(yè)接口用于作業(yè)提交。
product指示所述賬戶下可用的消息分配系統(tǒng)的代碼。
fax_carrier，fax_carrier_user，fax_carrier_password，email_carrier，email_carrier_user，email_carrier_password，sms_carrier，sms_carrier_user，sms_carrier_password，paper_carrier，paper_carrier_user，paper_carrier_password所述“xxx_carrier”字段包括將用于媒體“xxx”的所述載體的三個字符識別符。當前值是
用于Xpedite的XPD，用于EDI郵寄的EDI，用于MessageReach的MSR，用于SMSReach的SMR。
所述“xxx_carrier_user”和“xxx_carrier_password”字段由所述消息分配系統(tǒng)在借助FTP將文件傳送到所述載體時內(nèi)部使用的字段?？赡苁褂闷渌R別符，包括用于不同載體的識別符。
fax_quality傳真的輸出質(zhì)量(標準或增強型)。
fax_max_page_size以字節(jié)表示的傳真頁最大尺寸。
fax_cover_page指示是否生成在所述賬戶下提交的作業(yè)的傳真封面頁的布爾值。
fax_company，fax_address_1，fax_address_2，fax_address_3這些字段內(nèi)的公司名稱和地址被打印在每個傳真的封面頁上。
email_from_address所述消息分配系統(tǒng)生成的電子郵件到達的接收者來自的電子郵件地址。
email-timeout電子郵件未決的最大時間(優(yōu)選的是從作業(yè)嘗試開始的小時)。當?shù)竭_此時間時，假定所有未決電子郵件成功，且開始下一次嘗試。
email_job_status_address作業(yè)狀態(tài)報告被發(fā)送到的電子郵件地址。
USER A CCOUNT XREF所述“交叉參考”實體2614指定用戶2612和賬戶2616的單個有效組合。對于每個用戶而言，所述實體定義在所述用戶提交所述消息分配系統(tǒng)作業(yè)時所述用戶可能指定的賬戶。對于每個賬戶而言，所述實體2614定義可能使用所述實體的用戶。
user_account_xref_PK自動生成的唯一主密鑰。
user_FK到USER記錄的鏈接。
account_FK到ACCOUNT記錄的鏈接。
作業(yè)隊列所述作業(yè)隊列作為所述消息分配系統(tǒng)的相關(guān)數(shù)據(jù)庫2600內(nèi)的一組表存在。在圖25的實體關(guān)系圖內(nèi)，作業(yè)隊列實體是
2618，2632，2634，2640；2620，2622，2626，2628，2630；以及2636，2638，2642，2644，2646，2648，2650和2652。
一旦已生成作業(yè)隊列條目，就不會改變記錄2636、2638、2642、2644、2646、2648、2650、2652、2652、2620、2622、2624、2626、2628和2630，但有時會更新記錄2618、2632、2634和2640，以指示作業(yè)處理的狀態(tài)。
在作業(yè)提交時間建立記錄2636、2638、2642、2644、2646、2648、2650和2652。在對于所述標準接口的作業(yè)提交時間還建立所述記錄2620、2622、2624、2626、2628、2630，但在企業(yè)接口的情況下，當通過若干作業(yè)首先實施并保持所述作業(yè)時，所述記錄可能由所述消息分配系統(tǒng)支持組建立。
作業(yè)所述作業(yè)隊列層級的頂端是JOB記錄2618。在所述隊列內(nèi)存在用于每個作業(yè)的記錄，而所述JOB記錄2618構(gòu)成與作業(yè)相關(guān)的所有信息的“錨”記錄。
job_PKjobid是所述消息分配系統(tǒng)所生成的、唯一識別所述作業(yè)的數(shù)字識別符。所述識別符出現(xiàn)在與所述作業(yè)相關(guān)的輸出上(例如作業(yè)狀態(tài)報告)，并在所述用戶提交作業(yè)時顯示在“確認屏”上。
user-reference用戶生成的作業(yè)名稱，其被包括在各種消息分配系統(tǒng)/計費報告內(nèi)，并可能包括用戶希望的任何文本。
job_configuration_FK鏈接到所述作業(yè)的JOB_CONFIGURATION記錄。
account_FK鏈接到所述作業(yè)在其下運行的賬戶的ACCOUNT記錄。
user_FK鏈接到啟動所述作業(yè)的用戶的USER記錄。
submit_time提交所述作業(yè)的日期和時間。
fax_only表示“將傳真發(fā)送到所有具有所定義傳真地址的接收者”。
sms_only表示“將SMS消息發(fā)送到所有具有所定義SMS地址的接收者”。
email_only表示“將電子郵件發(fā)送到所有具有所定義電子郵件地址的接收者”。
fax_preferred表示“借助傳真(如果定義了傳真地址)發(fā)送到所有接收者，否則借助電子郵件”。
email_preferred表示“借助電子郵件(如果定義了電子郵件地址)發(fā)送到所有接收者，否則借助傳真”。
job_submission_folder各個作業(yè)工具(模板、接收者文件、傳輸束文件等)存儲其內(nèi)的文件夾的名稱。
master_status總體作業(yè)狀態(tài)。
master_change_timemaster_status最后被改變的日期和時間。
作業(yè)配置信息包括記錄類型JOB_CONFIGURATION 2620、TEMPLATE2624、TEMPLATE_ARTIFACT 2622、CONFIG_DATA 2626、JAVA_MAPPING_CLASS_RESOURCE 2628以及JAVA_MAPPING_CLASS 2630的記錄群集定義了作業(yè)所使用的各種工具和配置。
對于使用企業(yè)接口提交的作業(yè)而言，當所述消息分配系統(tǒng)支持組首先建立作業(yè)時定義所述記錄群集。所述記錄群集由許多作業(yè)使用，且對于每個作業(yè)都保持不變。所述群集包括各個數(shù)據(jù)文件的內(nèi)容(模板、圖像等)，每個文件可能都由所述消息分配系統(tǒng)支持組在所述群集被建立時作為二進制對象(BLOB)輸入到所述數(shù)據(jù)庫記錄。
對于使用標準接口提交的作業(yè)而言，在提交所述作業(yè)時生成所述記錄群集，且所述記錄群集與特定作業(yè)相關(guān)。所述模板可從所述群集內(nèi)查詢，而非實際上存儲在數(shù)據(jù)庫自身內(nèi)；所述模板被單獨保持為平面文件。
JOB CONFIGURATION所述記錄2620是作業(yè)配置記錄群集的“錨”。
job_configuration_PK自動生成的唯一主密鑰。
display_name這是作業(yè)配置的名稱，所述作業(yè)配置對于客戶有意義，并在作業(yè)提交屏(“作業(yè)類型”)上使用，以選擇作業(yè)配置。僅為企業(yè)接口作業(yè)定義所述字段。
enterprise指示所述作業(yè)配置是應(yīng)用于所述企業(yè)接口還是標準接口的布爾標志。
customer_FK鏈接到“擁有”所有使用所述作業(yè)配置的作業(yè)的CUSTOMER記錄。
TEMPLATE所述記錄2624定義了模板(即，可合并的微軟Word、XSL或文本文檔；或PDF、TIFF、HTML或postscript格式的不可合并文檔)。對于企業(yè)接口作業(yè)而言，所述模板2624自身作為二進制圖象保持在所述記錄內(nèi)。對于標準接口作業(yè)而言，所述模板2624被作為平面文件保持在數(shù)據(jù)庫之外(所述作業(yè)提交文件夾內(nèi))。
template_PK自動生成的唯一主密鑰。
filename構(gòu)成所述模板的文件的文件名。
filetype構(gòu)成所述模板的文件的文件類型。
attach_name此名稱是僅為電子郵件附件模板定義的，是在發(fā)送到所述接收者時提供給附件文件(不包括文件類型)的名稱。
media_type指示所述模板應(yīng)用的媒體。
fo_rendering_engine這是僅為紙面模板定義的，包括所述消息分配系統(tǒng)用于生成postscript輸出(當前為XEP或FOP)的FO翻譯引擎。
job_configuration_FK鏈接到JOB_CONFIGURATION記錄。
component_type指示所述模板定義的最終接收者消息的哪個部分。對于傳真而言，這可能是“主題”或“其它”。對于電子郵件而言，其可能是“主題”、“主體”或“附件”。對于紙面和SMS而言，其未被定義。
component_sequence這是如果component_type不是“附件”而定義的部分的序號。該字段表示所述消息內(nèi)的附件的序號。例如，四個附件的電子郵件消息的電子郵件附件被標號1、2、3和4。
template該字段僅對于企業(yè)接口模板而言有效，包括模板自身。(對于標準接口作業(yè)而言，所述模板保持在作業(yè)提交文件夾中的平面文件內(nèi)。)TEMPLATE ARTIFACT所述記錄2622指示所述JOB_CONFIGURATION 2620內(nèi)的TEMPLATE記錄2624所使用的圖像和其它多媒體文件。此記錄是為企業(yè)接口作業(yè)(其使用XSL模版)定義的。
template_artifact_PK自動生成的唯一主密鑰。
filename所述工具從那里被輸入的文件的文件名。
filetype所述工具從那里被輸入的文件的文件類型(通常為GIF或JPG)。
job_configuration_FK鏈接到JOB_CONFIGURATION記錄。
artifact包括所述工具自身。
CONFIG DATA所述記錄2626包括特定于媒體類型的配置數(shù)據(jù)。所述記錄用于紙面，并包括諸如使用哪個送紙器箱(paper feeder bins)、是否雙面打印等的信息。所述記錄是為企業(yè)接口作業(yè)定義的。
config_date_PK自動生成的唯一主密鑰。
filename所述配置數(shù)據(jù)從那里被輸入的文件的文件名。
filetype所述配置數(shù)據(jù)從那里被輸入的文件的文件類型(通常為TXT)。
media_type指示所述配置數(shù)據(jù)應(yīng)用于的媒體。
job_configuration_FK鏈接到JOB_CONFIGURATION記錄。
configuration所述配置數(shù)據(jù)自身。圖26是提交給EDI郵寄的紙面作業(yè)的典型配置2700的實例。
JAVA MAPPING CLASS所述記錄2630是必備的，并包括Java類，所述Java類用于將接收者文件轉(zhuǎn)換為XML(可能還使用一個或多個JAVA_MAPPING_CLASS_RESOURCE記錄)。標準接口作業(yè)使用CSV格式化后的接收者文件，因此所述作業(yè)使用被稱為“CSV映射類”的標準java映射類。
java_mapping_class_PK自動生成的唯一主密鑰。
filename所述java類別被從那里輸入的文件的文件名。
filetype所述java類別被從那里輸入的文件的文件類型(通常為CLASS)。
job_configuration_FK鏈接到JOB_CONFIGURATION記錄。
class包括java類別。
JAVA MAPPING CLASS RESOURCE此記錄2628是可選的，并包括所述Java映射類用于重新格式化所述接收者列表信息的資源對象。所述記錄2628可能包括任何類型的資源，例如所述XFlat語言(用于輸入到“XML轉(zhuǎn)換”產(chǎn)品)的其它java類別、XML樣式表或報表。
java_mapping_class_resource_PK自動生成的唯一主密鑰。
filename所述XFlat映射數(shù)據(jù)被從那里輸入的文件的文件名。
filetype所述Xflat映射數(shù)據(jù)被從那里輸入的文件的文件類型。
job_configuration_FK鏈接到JOB_CONFIGURATION記錄。
resource_data包括資源自身。
圖27示出了可能存儲在所述記錄內(nèi)的一種資源類型的實例2800。所述XFlat報表將CSV文件轉(zhuǎn)換為XML。在所述CSV文件中，每個記錄包括三個字段，表示“refno”、“name”和“salary”。
接收者信息RECEIPIENT、ATTEMPT、TRANSMISSION、MERGE_DATA、DESTINATION、PAPER_ADDRESS_PARSED、PAPER_ADDRESS_UNPARSED、PHONE_NUMBER記錄2636、2638、2640、2642、2644、2652、2650、2648、2646分別定義作業(yè)的接收者信息。
RECEIPIENT
每個所述記錄2636都表示一個接收者。
recipient_PK自動生成的唯一主密鑰。
job_FK鏈接到所述作業(yè)的JOB記錄。
Tjtle所述接收者的名稱(Mr、Mrs、Dr等)first_name所述接收者的名。
last_name所述接收者的姓。
user_data從用戶角度來看，通常用于識別所述接收者的用戶定義的數(shù)據(jù)。
ATTEMPT每個接收者可能存在最多三個ATTEMPT記錄2638。每一個都表示在所述接收者列表記錄內(nèi)指定的一個“<attempt>”。所述ATTEMPT記錄2638被編序號，從而可以正確順序接入所述記錄。所述ATTEMPT記錄的目的是分組其下的TRANSMISSION記錄。
attempt_PK自動生成的唯一主密鑰。
recipient_FK鏈接到RECIPIENT記錄。
seq_number此次嘗試的序號(1、2或3)。
TRANSMISSION每次嘗試可能存在最多三個TRANSMISSION記錄2640。每一個都代表在接收者列表記錄中的“<attempt>”單元內(nèi)指定的傳輸。所述TRANSMISSION記錄2640被編序號，從而可以正確順序接入所述記錄。第一個(序號始終為“1”)代表主傳輸(如果其失敗則引起改發(fā))。
當所述作業(yè)被置于作業(yè)隊列內(nèi)時建立以下字段tansmission_PK自動生成的唯一主密鑰。
destination_FK鏈接到DESTINATION記錄。
attempt_FK鏈接到ATTEMPT記錄。
account_FK鏈接到所述作業(yè)的ACCOUNT記錄。
recipient_FK鏈接到RECIPIENT記錄。
transmission_bundle_FK鏈接到TRANSMISSION_BUNDLE記錄。
job_FK鏈接到所述作業(yè)的JOB記錄。
attempt_no嘗試編號。
seq_number此次傳輸?shù)男蛱?1、2或3)。
State指示此次傳輸“尚未嘗試”(INACTIVE)，“成功完成”(即OK)，還是“完成失敗”(即誤碼)。
剩余字段在已嘗試傳輸時建立，并包括與傳輸成功/失敗相關(guān)的信息job_reference用戶對于所述作業(yè)的參考id。
user_data所述用戶對于所述接收者的參考id。
destination_address此次傳輸被發(fā)送到的電話號碼、電子郵件地址或紙面地址。
date_time_job_submitted提交作業(yè)的日期和時間。
date_time_message_dilivered所述消息被傳遞到接收者的日期和時間。
carrier_name載體的名稱(Xpedite等)。
carrier_reference_id載體的參考id(例如Xpedite的作業(yè)編號)。
medium所述傳輸被發(fā)送到的媒介(傳真、紙面等)。
size_of_message消息的字節(jié)總量。
destination_country所述消息被傳遞到的國家或區(qū)域。
delivery_success_failure_code指示所述傳輸成功或失敗原因的載體代碼。
MERGE DATA來自所述接收者記錄的合并數(shù)據(jù)2642被以XML文本形式存儲。
merge_data_PK自動生成的唯一主密鑰。
recipient_FK鏈接到RECIPIENT記錄。
merge_data包括作為一串XML格式化后的文本的合并數(shù)據(jù)自身。
DESTINATION對于每個接收者而言，每種媒體存在一個DESTINATION記錄2644(即最大為四個)。所述記錄包括“媒體id”(指示傳真、紙面、SMS或電子郵件)，并“指向”單個“子記錄”，所述“子記錄”為以下記錄類型中的一個。
destination_PK自動生成的唯一主密鑰。
recipient_FK鏈接到RECIPIENT記錄。
media-type指示所述目的地表示的媒體，從而指示所尋找目的地地址的類型(見以下)。
PAPER ADDRESS PARSED所述記錄2652包括未語法分析的紙面目的地地址。
paper_address_parsed_PK自動生成的唯一主密鑰。
destination_FK鏈接到DESTINATION記錄。
street_address街道號和名稱。
suburb城郊。
state州。
postcode郵編。
country國家PAPER ADDRESS UNPARSED所述記錄2650包括語法分析后的紙面目的地地址。
paper_address_parsed_PK自動生成的唯一主密鑰。
destination_FK鏈接到DESTINATION記錄。
address_line_1地址的行1。
address_line_2地址的行2。
address line 3地址的行3。
address_line_4地址的行4。
address_line_5地址的行5。
address_line_6地址的行1。
PHONE NUMBER此記錄2648包括電話號碼(即SMS或傳真的目的地地址)。
phone_number_PK自動生成的唯一主密鑰。
destination_FK鏈接到DESTINATION記錄。
country_code國家代碼。
area_code區(qū)號。
local_number電話號碼的剩余部分。
EMAIL ADDRESS此記錄2646包括電子郵件目的地地址。
email_address_PK自動生成的唯一主密鑰。
destination_FK鏈接到DESTINATION記錄。
email_address電子郵件地址。
is_valid指示所述地址語法是否有效的布爾值。
傳輸束信息當所述消息分配系統(tǒng)處理特定作業(yè)傳輸嘗試時，所述系統(tǒng)將接收者分為每個都指向特定媒體的“傳輸束”。每個傳輸束都被傳送到一個載體，所述傳輸?shù)拿\最終被從所述載體傳送回所述消息分配系統(tǒng)。為每個傳輸束生成TRANSMISSION_BUNDLE記錄2632，其用于跟蹤其狀態(tài)。
TRANSMISSION BUNDLE每個傳輸束都存在一個TRANSMISSION_BUNDLE記錄2632。所述記錄2632在生成所述束自身時生成，在從所述數(shù)據(jù)庫最終刪除所述作業(yè)時刪除。
transmission_bundle_PK自動生成的唯一主密鑰。
job_FK鏈接到所述作業(yè)的JOB記錄。
Attempt此次嘗試的序號(1、2或3)。
media_type指示此次傳輸束發(fā)往的媒體。
creation_time生成所述記錄的日期和時間。
bundle_status所述傳輸束的處理狀態(tài)。見段5.3.1。
status_change_timebundle_status最后改變的日期和時間。
CARRIER REFERENCE每個發(fā)送到用于特定媒體類型和作業(yè)id的載體的傳輸束都存在一個CARRIER_REFERENCE記錄2634。所述記錄2634在生成所述傳輸束文件自身時生成，在從所述數(shù)據(jù)庫最終刪除所述作業(yè)時刪除。
在多數(shù)情況下，一次嘗試僅為每個媒體類型生成一個傳輸束文件，但在一些情況下(例如發(fā)往Xpedite并超過10M字節(jié)的傳真束文件)，所述文件可能被分為若干獨立文件。出于此原因，每個TRANMISSION_BUNDLE記錄2632可能偶爾存在若干CARRIER_REFERENCE記錄2634。
carrier_reference_PK自動生成的唯一主密鑰。
transmission_bundle_FK鏈接到TRANSMISSION_BUNDLE記錄。
carrier_id所述載體提供的、唯一指示所述傳輸束文件的識別符。所述識別符可能由所述消息分配系統(tǒng)用于從所述載體輪詢反饋信息。所述字段的格式對于每個載體而言是不同的。
transmission_bundle_filename傳輸束文件的名稱。
statur_collected指示是否已從用于所述傳輸束文件的載體接收到載體狀態(tài)報告的布爾值。如果設(shè)置為“真”，則所述信息已被接收，并應(yīng)用于TRANSMISSION記錄。
其它NUMBER-GENERATOR這是用于將唯一作業(yè)id分配給新作業(yè)，并將唯一記錄密鑰分配給其它記錄的單個記錄2654。
number_generator_PK自動生成的唯一主密鑰。
job_number將被指配的下一個作業(yè)id。
general_number將被指配的下一個通用號碼(用作用于除JOB記錄之外的所有記錄的記錄密鑰)。
VIII.Java映射類和XSL模板所述消息分配系統(tǒng)被設(shè)計為一般化消息處理引擎。所述消息分配系統(tǒng)自身的“核心”被設(shè)計為將任何類型的消息廣播到任何目的地。然而，每個消息分配系統(tǒng)客戶的“作業(yè)類型”(aka“作業(yè)配置”)具有特別的處理特征。這分為兩個類別驗證和重新格式化從所述客戶接收的接收者文件，以及將合并值替換為所述模板內(nèi)的合并字段，以生成每個單獨特制的接收者消息。
所述處理類別分別稱為Java映射類處理和模板合并處理。這些處理類別都包括特定于每個客戶和作業(yè)類型的處理，以及作為用于在所述系統(tǒng)上建立新作業(yè)類型的進程一部分而開發(fā)的程序/樣式表。此外，程序/樣式表的開發(fā)可能由獨立于開發(fā)消息分配系統(tǒng)自身的組的開發(fā)組執(zhí)行。
圖28是作業(yè)執(zhí)行流的框圖，示出了作業(yè)處理路徑2900如何從消息分配系統(tǒng)“核心”2910傳送到Java映射類2930和模板2940，以及如何從Java映射類2930和模板2940傳送回消息分配系統(tǒng)“核心”2910。
所述消息分配系統(tǒng)2910的“核心”是不變的。所述系統(tǒng)軟件2910表示任何類型的消息分配系統(tǒng)作業(yè)能夠在其上運行的一般化平臺。特定于客戶的部分2930和2940對于每種作業(yè)類型而言是不同的。
在步驟2920中，所述用戶將作業(yè)提交給系統(tǒng)軟件2910。在步驟2912中集合所述作業(yè)信息。在Java映射類2930中，在步驟2932中驗證所述接收者列表。然后，在步驟2934中映射所述接收者列表。當在步驟2914中起動所述作業(yè)時，處理然后在系統(tǒng)軟件2910內(nèi)繼續(xù)。在步驟2916中，得到(“取得”)下一個接收者的合并字段。所述模板2940將所述接收者的合并值替代為所述模板的合并字段。所述消息被在步驟2918內(nèi)發(fā)送到接收者；并在步驟2916內(nèi)得到下一個接收者的合并數(shù)據(jù)。
Java映射類Java映射類2930(或稱為數(shù)據(jù)轉(zhuǎn)換器)是所述消息分配系統(tǒng)2900的有力特征。所述類2930允許以任何格式將客戶的接收者數(shù)據(jù)提供給所述消息分配系統(tǒng)。所述Java映射類2930是為特定客戶的作業(yè)特制的消息分配系統(tǒng)2910自身的附屬品。所述類2930將所有客戶的接收者列表轉(zhuǎn)換為在段VI.內(nèi)描述的消息分配系統(tǒng)的標準格式。所述類2930還提供了自動對客戶的接收者列表做出通用改變的能力。例如，Java映射類2930可能實施諸如“借助傳真發(fā)送到NSW內(nèi)的所有接收者，但借助電子郵件發(fā)送到其它接收者”的通用要求。每種作業(yè)類型存在一個java映射類2930(aka“作業(yè)配置”)，其功能是驗證2932從客戶接收的接收者文件，并將其轉(zhuǎn)換2930為所述消息分配系統(tǒng)的標準接收者列表格式。
所述類別2930提供兩個主要方法，即所述消息分配系統(tǒng)在必要時調(diào)用的“驗證”和“映射”。所述Java映射類2930自身被保持在數(shù)據(jù)庫內(nèi)(在JAVA_MAPPING_CLASS記錄內(nèi))，所述類別需要的各種資源(即XFlat方案和XSLT樣式表)同樣保持在數(shù)據(jù)庫內(nèi)(在JAVA_MAPPING_CLASS_RESOURCE記錄內(nèi))。
特別的Java映射類環(huán)境與其它消息分配系統(tǒng)類一樣，Java映射類的類文件并不存儲在JAR文件內(nèi)；所述文件作為作業(yè)配置的一部分保持在所述數(shù)據(jù)庫內(nèi)的JAVA_MAPPING_CLASS記錄內(nèi)。只要需要所述類文件，所述消息分配系統(tǒng)即自動將所述類文件從數(shù)據(jù)庫讀入存儲器，然后使用Java類裝載器(本文稱為“特別類裝載器”)的專門消息分配系統(tǒng)子類裝載文件。
Java虛擬機由用于載入所述類的類裝載器區(qū)別所有類別。特定類裝載器所載入的類僅能接入在此類裝載器的“類途徑”上特別指定的其它類別。所述Java虛擬機分為獨立“世界”。以相同類裝載器載入的所有類可相互直接接入，但一個“世界”內(nèi)的類無法輕易接入另一“世界”內(nèi)的類。術(shù)語“世界”在本文用于描述此概念。
所述Java特征已被特地用于限制Java映射類接入所述消息分配系統(tǒng)“核心”類別。Java映射類在與所述消息分配系統(tǒng)剩余部分不同的“世界”內(nèi)操作所述消息分配系統(tǒng)類的核心可接入所有標準Java SDK程序包(java.io、java.util等)，以及所有客戶開發(fā)的消息分配系統(tǒng)程序包。
Jav映射類可接入所有標準Java SDK程序包(java.io、java.util等)，以及專門的Java映射類程序包(com.system.mapper)。
因此，Java映射類被與所述消息分配系統(tǒng)“分離”，根本無法接入所述消息分配系統(tǒng)，因此無需對所述消息分配系統(tǒng)自身做出對應(yīng)改變即可增強或修改Java映射類。這顯著簡化了系統(tǒng)管理，并保護系統(tǒng)免于“欺詐”Java映射類。
所述消息分配系統(tǒng)自身及其Java映射類可被設(shè)想為相同Java虛擬機內(nèi)的獨立“島”。所述消息分配系統(tǒng)使用“反應(yīng)API”(普通方法調(diào)用不工作)將自變量傳送到Java映射類。
至于自變量傳送機制，作為實際實例，考慮企業(yè)作業(yè)的作業(yè)信息(作業(yè)id、作業(yè)參考、作業(yè)提交文件夾和接收者文件)被從所述消息分配系統(tǒng)傳送到Java映射類。
所述消息分配系統(tǒng)包括稱為“EnterpriseJobSubmission”的類，其包括所有信息和更多(以各種格式存儲，包括簡單串和其它消息分配系統(tǒng)定義的類)。明顯的策略是僅將企業(yè)作業(yè)提交對象傳送到Java映射類內(nèi)的“setJobSubmission”方法。這會失敗，因為所述Java映射類并不了解“EnterpriseJobSubmission”類，因為所述類的定義并未包括在提供給用于載入Java映射類的類裝載器的類路徑內(nèi)。簡而言之，所述Java映射類僅了解其自己“世界”內(nèi)的類；所述類對于所述消息分配系統(tǒng)的“世界”內(nèi)的類別一無所知。然而，每個Java映射類都了解稱為“EnterpriseJobSubmissionData”的類。所述類定義是Java映射類自己“世界”的一部分(因此并非所述消息分配系統(tǒng)的世界的一部分)。因此，在調(diào)用Java映射類之前，所述消息分配系統(tǒng)(使用特別類裝載器)生成EnterpriseJobSubmissionData的實例，并使用其“設(shè)置”方法將必要數(shù)據(jù)(即作業(yè)id、作業(yè)參考、作業(yè)提交文件夾和接收者文件)置于實例內(nèi)。所述消息分配系統(tǒng)必須借助反射調(diào)用所述設(shè)置方法，因為對象存在于其它“世界”內(nèi)。所述消息分配系統(tǒng)然后生成Java映射類自身的實例(再次使用專門的類裝載器)。最后，所述系統(tǒng)使用其“設(shè)置”方法中的一個，將企業(yè)作業(yè)提交數(shù)據(jù)對象傳送到Java映射類2930。
所述Java映射類2930可接入此對象，并以常用方式將所述對象存儲在其成員變量中的一個內(nèi)，因為所述對象在其自己的“世界”內(nèi)，而所述“世界”包括的所有對象是作為標準Java環(huán)境一部分的簡單對象(串、陣、文件等)。在所述消息分配系統(tǒng)與Java映射類2930之間信息傳送使用上述技術(shù)。
Java映射類方法企業(yè)接口作業(yè)的Java映射類必須擴展企業(yè)映射類(其反過來擴展映射類)，還必須實施客戶映射接口。這需要表5所示的方法表5

以上公開了一種方法、系統(tǒng)和計算機程序產(chǎn)品，用于基于接收者的傳遞偏好，并引入逐步升級，從而經(jīng)由多個傳遞媒體將信息成批通信給單個接收者組。盡管已描述了少量的實施例，但對于本領(lǐng)域技術(shù)人員而言，依據(jù)本公開，顯然可在并不背離本發(fā)明精神和范圍的情況下進行修改和/或替換。
權(quán)利要求
1.一種用于經(jīng)由多個傳遞媒體將信息成批通信給接收者的方法，其中所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送，所述方法包括步驟經(jīng)由單個接口接收用于分配的信息，所述用于分配的信息包括關(guān)于接收者的信息；以及基于所述接收者的傳遞偏好，利用為每個所述接收者所指定的其中一個所述傳遞媒體，從而基于所述接收的信息而傳送至少一個文檔。
2.根據(jù)權(quán)利要求1的方法，還包括步驟對于借助指定的傳遞媒體向其傳輸失敗的一個或多個接收者，通過將一個不同的傳遞媒體用于所述多個接收者中的每一個，來逐步升級所述至少一個文檔的傳輸。
3.根據(jù)權(quán)利要求1的方法，其中所述接收的信息包括一個或多個模板文檔和特定于每個接收者的數(shù)據(jù)。
4.根據(jù)權(quán)利要求3的方法，還包括步驟將所述一個或多個模板文檔和所述特定于每個接收者的數(shù)據(jù)合并，以為每個接收者提供所述至少一個文檔。
5.根據(jù)權(quán)利要求4的方法，還包括步驟為每個傳遞媒體確定文檔模板類型，并為所述文檔模板類型選擇合并過程。
6.根據(jù)權(quán)利要求5的方法，其中所述特定于每個接收者的數(shù)據(jù)被提供給對應(yīng)的合并過程。
7.根據(jù)權(quán)利要求2的方法，還包括步驟將所述至少一個文檔轉(zhuǎn)換為適合于每個接收者的所述指定的一個或所述不同的一個的傳遞媒體的格式；以及使用所述指定的一個或所述不同的一個傳遞媒體，將所述格式化后的文檔發(fā)送到用于傳輸?shù)妮d體。
8.根據(jù)權(quán)利要求7的方法，還包括步驟處理來自所述載體的關(guān)于所述傳輸?shù)膱蟾?，以提供關(guān)于所述文檔到每個接收者的傳遞的狀態(tài)信息。
9.根據(jù)權(quán)利要求8的方法，其中所述逐步升級步驟依據(jù)所述狀態(tài)信息。
10.根據(jù)權(quán)利要求1的方法，其中所述傳遞媒體包括歸檔。
11.根據(jù)權(quán)利要求1的方法，其中所述傳遞媒體包括一個或多個新媒體類型。
12.一種用于經(jīng)由多個傳遞媒體將信息成批通信給接收者的系統(tǒng)，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送，所述系統(tǒng)包括單個接口，用于接收用于分配的信息，所述用于分配的信息包括關(guān)于接收者的信息；以及用于基于所述接收者的傳遞偏好，利用為每個所述接收者所指定的其中一個所述傳遞媒體，從而基于所述接收的信息而傳送至少一個文檔的裝置。
13.根據(jù)權(quán)利要求12的系統(tǒng)，還包括用于對于借助指定的傳遞媒體向其傳輸失敗的一個或多個接收者，通過將一個不同的傳遞媒體用于所述多個接收者中的每一個，來逐步升級所述至少一個文檔的傳輸?shù)难b置。
14.根據(jù)權(quán)利要求12的系統(tǒng)，其中所述接收的信息包括一個或多個模板文檔和特定于每個接收者的數(shù)據(jù)。
15.根據(jù)權(quán)利要求14的系統(tǒng)，還包括用于將所述一個或多個模板文檔和所述特定于每個接收者的數(shù)據(jù)合并，以為每個接收者提供所述至少一個文檔的裝置。
16.根據(jù)權(quán)利要求15的系統(tǒng)，還包括用于為每個傳遞媒體確定文檔模板類型，并為所述文檔模板類型選擇合并過程的裝置。
17.根據(jù)權(quán)利要求16的系統(tǒng)，其中對于所述特定于每個接收者的數(shù)據(jù)執(zhí)行對應(yīng)的合并處理。
18.根據(jù)權(quán)利要求13的系統(tǒng)，還包括用于將所述至少一個文檔轉(zhuǎn)換為適合于每個接收者的所述指定的一個或所述不同的一個傳遞媒體的格式的裝置；以及用于使用所述指定的一個或所述不同的一個傳遞媒體，將所述格式化后的文檔發(fā)送到用于傳輸?shù)妮d體的裝置。
19.根據(jù)權(quán)利要求18的系統(tǒng)，還包括用于處理來自所述載體的關(guān)于所述傳輸?shù)膱蟾?，以提供關(guān)于所述文檔到每個接收者的傳遞的狀態(tài)信息的裝置。
20.根據(jù)權(quán)利要求19的系統(tǒng)，其中所述用于逐步升級的裝置依據(jù)所述狀態(tài)信息。
21.根據(jù)權(quán)利要求12的系統(tǒng)，其中所述傳遞媒體包括歸檔。
22.根據(jù)權(quán)利要求12的系統(tǒng)，其中所述傳遞媒體包括一個或多個新媒體類型。
23.一種計算機程序產(chǎn)品，所述計算機程序產(chǎn)品包括計算機可讀媒體，所述計算機可讀媒體具有記錄在其內(nèi)的計算機程序，所述計算機程序用于經(jīng)由多個傳遞媒體將信息成批通信給接收者，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送，所述計算機程序產(chǎn)品包括經(jīng)由單個接口接收用以于分配的信息的計算機程序代碼單元，所述用于分配的信息包括關(guān)于接收者的信息；以及基于所述接收者的傳遞偏好，利用為每個所述接收者所指定的其中一個所述傳遞媒體，從而基于所述接收的信息而傳送至少一個文檔的計算機程序代碼單元。
24.根據(jù)權(quán)利要求23的計算機程序產(chǎn)品，還包括用于對于借助指定的傳遞媒體向其傳輸失敗的一個或多個接收者，通過將一個不同的傳遞媒體用于所述多個接收者中的每一個，來逐步升級所述至少一個文檔的傳輸?shù)挠嬎銠C程序代碼單元。
25.根據(jù)權(quán)利要求23的計算機程序產(chǎn)品，其中所述接收的信息包括一個或多個模板文檔和特定于每個接收者的數(shù)據(jù)。
26.根據(jù)權(quán)利要求25的計算機程序產(chǎn)品，還包括用于將所述一個或多個模板文檔和所述特定于每個接收者的數(shù)據(jù)合并，以為每個所述接收者提供所述至少一個文檔的計算機程序代碼單元。
27.根據(jù)權(quán)利要求26的計算機程序產(chǎn)品，還包括用于為每個傳遞媒體確定文檔模板類型，并為所述文檔模板類型選擇合并過程的計算機程序代碼單元。
28.根據(jù)權(quán)利要求27的計算機程序產(chǎn)品，其中對于所述特定于每個接收者的數(shù)據(jù)執(zhí)行對應(yīng)的合并處理。
29.根據(jù)權(quán)利要求24的計算機程序產(chǎn)品，還包括用于將所述至少一個文檔轉(zhuǎn)換為適合于每個接收者的所述指定的一個或所述不同的一個傳遞媒體的格式的計算機程序代碼單元；以及用于使用所述指定的一個或所述不同的一個傳遞媒體，將所述格式化后的文檔發(fā)送到用于傳輸?shù)妮d體的計算機程序代碼單元。
30.根據(jù)權(quán)利要求29的計算機程序產(chǎn)品，還包括用于處理來自所述載體的關(guān)于所述傳輸?shù)膱蟾妫蕴峁╆P(guān)于所述文檔到每個接收者的傳遞的狀態(tài)信息的計算機程序代碼單元。
31.根據(jù)權(quán)利要求30的計算機程序產(chǎn)品，其中所述用于逐步升級的計算機程序代碼單元依據(jù)所述狀態(tài)信息。
32.根據(jù)權(quán)利要求23的計算機程序產(chǎn)品，其中所述傳遞媒體包括歸檔。
33.根據(jù)權(quán)利要求23的計算機程序產(chǎn)品，其中所述傳遞媒體包括一個或多個新媒體類型。
34.一種用于經(jīng)由多個傳遞媒體將信息成批通信給接收者的方法，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送，所述方法參照附圖的圖1-10中任何一個被公開。
35.一種用于經(jīng)由多個傳遞媒體將信息成批通信給接收者的系統(tǒng)，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送，所述系統(tǒng)參照附圖的圖1-10中任何一個被公開。
36.一種用于經(jīng)由多個傳遞媒體將信息成批通信給接收者的計算機程序產(chǎn)品，所述傳遞媒體包括傳真、電子郵件、水陸路郵件和SMS消息發(fā)送，所述計算機程序產(chǎn)品參照附圖的圖1-10中任何一個被公開。
全文摘要
公開了一種用于經(jīng)由多個傳遞媒體將信息成批通信給接收者的方法(100)、系統(tǒng)和計算機程序產(chǎn)品。所述傳遞媒體包括傳真、電子郵件、水陸路郵件、SMS消息發(fā)送和歸檔(并適合于未來的新媒體類型)。單個接口用于接收包括一個或多個模板文檔(110)和特定于每個接收者的數(shù)據(jù)(106)的、用于分配的信息(106、108、110)。通過基于所述接收者的傳遞偏好(122、176)，將指定的一個傳遞媒體(144、150、156、162、168)用于每個所述接收者，從而基于所接收信息(106、108、110)傳送至少一個文檔。將一個不同的所述傳遞媒體用于借助所述指定傳遞媒體向其傳輸失敗的任何接收者，可能逐步升級(172、178)文檔的傳輸。所述逐步升級步驟(172、178)可能取決于來自載體的關(guān)于將所述文檔到每個接收者的傳遞的狀態(tài)信息(176)。
文檔編號H04L29/06GK1672158SQ03818096
公開日2005年9月21日 申請日期2003年7月29日 優(yōu)先權(quán)日2002年7月29日
發(fā)明者尼古拉斯·R·博德, 凱文·B·萊維尼, 羅伯特·西爾弗, 邁克爾·R·斯圖爾特, 亞歷山德拉·J·奧米利安, 保羅·H·吉恩斯, 邁克爾·馬卡姆 申請人:信風通信有限公司