TWI385983B - Multi-type message sending device - Google Patents

Description

多種類訊息發送裝置

本發明係關於一種多種類訊息發送裝置，特別為一種具備隨開即用性質，以及利用視覺化介面的操作方式來提供訊息發送、管理、報表檢視，並具備可程式化之多功能應用程式介面模組。

對於一個企業而言，使用訊息於企業的營運作業是非常頻繁，但隨著訊息技術的發展，訊息溝通交流的方式越來越多，例如：電腦、電話、手機、郵件、多媒體影音等，複雜性已超過企業可掌控。企業使用這些個別獨立的訊息傳遞方式，往往是缺乏規劃，以往想要發送SMS、WAP Push、MMS、E-mail等不同種類訊息時，必須分別添購不同設備、建置不同系統或是使用電信/網路公司的相關服務。

自行建置必須投入大量研發、維護人力，不符投資效益；使用電信/網路公司提供的相關服務，固然可以節省研發、維護成本，但是目前市面上卻少見整合多種類訊息發送服務又具備操作簡單的視覺化介面，除此之外，企業用戶更在意的是資料安全性的問題，諸如有些商業機密相關的訊息傳遞，因傳送紀錄儲存於服務供應商的資料庫而有外洩的可能，使企業對於電信/網路公司提供的訊息傳送服務的應用，多了幾分的顧慮。

如能提供申購流程及設定一次購足、操作簡易、功能完整的服務與有效整合解決方案之隨開即用性質的系統，將這些訊息的傳遞方式整合起來，使訊息能安全、方便、有效、全面地相互傳遞，為企業使用者提供隨心所欲使用方式，可提高企業員工產能和工作效率，並安全即時掌握來自各通訊管道的重要訊息。

由此可見，上述習用方式仍有諸多缺失，實非一良善之設計，而亟待加以改良；本案發明人鑑於上述習用方式所衍生的各項缺點，乃亟思加以改良創新，並經多年苦心孤詣潛心研究後，終於成功研發完成多種類訊息發送裝置。

本發明之目的係提供一種具隨開即用性質的多種類訊息發送裝置，具有多種類訊息發送的操作介面、帳號管理的操作介面、資源管理及系統屬性設定的操作介面、發訊狀態查詢的操作介面、通訊錄管理的操作介面、罐頭訊息管理的操作介面、系統維運的操作介面。

本發明之次一目的係提供一種具備可程式化之多功能服務介面，加速企業內部流程整合之開發時程。

本發明之次一目的係提供一種具備元件狀態資訊收集及檢視的功能，達到系統維運的目的。

達成上述發明目的之多種類訊息發送裝置，係由儲存發訊訂單、發訊紀錄及輔助功能服務資料之一資料庫，以及提供服務之一網頁伺服器模組、一訊息代理器模組、一多功能服務應用程式介面模組、一元件狀態代理器模組等組成；用以執行訊息發送流程、元件狀態收集及檢視流程；其執行訊息發送流程係利用網頁伺服器模組、訊息代理器模組、多功能服務應用程式介面模組及資料庫，並搭配電信服務商特碼帳號、電信服務商訊息介接閘道來發送多種類訊息；元件狀態收集及檢視流程，係利用特定指令透過網路通訊方式收集本裝置發訊元件、電信服務商訊息介接閘道的狀態資訊，再搭配不同顏色燈號(例如：紅、橙、綠)以視覺化方式呈現元件狀態資訊。

本發明係整合多種類訊息的發訊功能，並提供視覺化的操作介面，降低企業導入訊息溝通發送的門檻。若以發送SMS為例，用戶以用戶帳號登入後，(一)輸入SMS傳送內容，如果事先有建立該帳號專屬之罐頭訊息，則可以選取罐頭訊息，插入在傳送內容中、(二)可使用自通訊錄名單選取已建立之群組或是成員、自行輸入受訊號碼，每一受訊號碼以”，”分隔、匯入受訊檔案方式，文字檔，每一行一筆電話號碼等方式輸入受訊號碼、(三)可以選擇立即與預約傳送、(四)可以以小時為單輸入重送期限位、(五)如果選擇發送前必須預覽發送，則當傳送訊息時，系統必須先顯示該筆SMS之傳送內容以及受訊號碼和姓名，當再次確定傳送時，系統將會送出簡訊；如果選擇取消，則系統會回到原先使用者輸入之狀態。如果沒有選擇預覽發送時，一旦傳送訊息，系統就會立即傳送訊息到受訊號碼手機、(六)訊息傳送完成後，系統會顯示傳送情形，同時也必須將此發訊記錄存入資料庫，提供查詢。

若以元件狀態資訊檢視呈現為例，當使用者點選「元件狀態」功能時，(一)網頁伺服器模組會驅動元件狀態代理器模組去收集諸如訊息代理器模組、電信服務商訊息閘道器的狀態資訊，(二)等待相關狀態資訊回傳後，將這些資訊搭配紅、橙、綠燈號以視覺化方式呈現，紅燈代表元件停止運作或無法確定狀態；橘燈代表元件負載稍重或訊息擁塞；綠燈代表元件運作順暢。

請參閱圖一，為本發明多種類訊息發送裝置的架構圖，由圖中可知，本發明主要包括有網頁伺服器模組1、資料庫2、訊息代理器模組3、多功能服務應用程式介面模組4、元件狀態代理器模組5；訊息發送者6可藉由本裝置之網頁伺服器模組1進行訊息發送流程；企業資訊系統7可連接本裝置之多功能服務應用程式介面模組4，與本裝置互動；本裝置之訊息代理器模組3連接電信服務商訊息閘道器8，將訊息發送者6發送之訊息傳送給接收終端9，並將其執行狀態透過本裝置之元件狀態代理器模組5顯示於網頁伺服器。

請參閱圖二及圖三，圖二為本發明之訊息傳送流程之UML(Unified Modeling Language，統一塑模語言)循序圖，圖三為該訊息傳送流程之狀態轉換圖；其訊息傳送流程之步驟包含：

a.訊息發送者6透過本裝置之網頁伺服器模組1來發訊，或是企業資訊系統7透過本裝置之多功能服務應用程式介面模組4來發訊；

b.若發訊參數格式正確，將發訊訂單新增至資料庫2、受訊清單寫入佇列，回報訊息發送者/企業資訊系統接受發訊及受訊數；

c.訊息代理器模組3，定時至資料庫2查詢是否有已達發訊時間的訂單；

d.若有，則訊息代理器模組3會根據訂單內容至佇列讀取相對應之受訊清單，傳送至電信服務商訊息閘道器8，將傳送結果更新至資料庫2及寫入每筆門號；

e.訊息代理器模組3定時至資料庫2查詢每筆門號受訊狀態；

f.若有未達最終狀態(傳送中)的紀錄，則傳送至電信服務商訊息閘道器8查詢受訊狀態，並且將已達最終狀態之受訊結果更新至資料庫2。

而如圖三顯示訊息傳送流程中之狀態轉換過程，圖中之過程，0表示傳送失敗，1表示傳送成功；圖中之過程如下述：

S0.網頁伺服器產生發訊訂單至資料庫，設定發送時間，進行S1；

S1.訊息代理器模組3至資料庫2(如圖二)撈取發訊訂單，將訊息傳送至電信服務商訊息閘道器8(如圖二)，傳送失敗進行S2，傳送成功進行S3；

S2.傳送至電信服務商訊息閘道器8(如圖二)失敗，設定完成時間；

S3.傳送至電信服務商訊息閘道器8(如圖二)成功，讀取失敗的傳送狀態進行S4，讀取成功的傳送狀態進行S5；

S4.訊息代理器模組3(如圖二)讀取失敗的傳送狀態，設定完成時間；

S5.訊息代理器模組3(如圖二)讀取成功的傳送狀態，設定完成時間。

請參閱圖四，為本發明之多功能服務應用程式介面模組提供企業資訊系統網路服務之介面架構圖，其中包含提供註冊與搜尋網路服務資訊的UDDI(Universal Description,Discovery,and Integration，通用描述、探索與整合)標準；描述網路服務的運作方式，以及指示企業資訊系統7(如圖一)與本模組4(如圖一)可能的互動方式之WSDL(Web Service Definition Language，服務描述語言)；在網路上交換結構化和型別資訊的一種簡易通訊協定SOAP(Simple Object Access Protocol，簡易物件通訊協定)；資料格式XML(eXtensible Markup Language，延伸標記語言)及網路協定HTTP(HyperText Transmission Protocol，簡易物件通訊協定)等，可以加速企業內部流程整合之開發時程。

如圖一、圖四所示，以上實施本發明之訊息發送流程之功能模組包括：網頁伺服器模組1、資料庫2、訊息代理器模組3、多功能服務應用程式介面模組4，其中網頁伺服器模組1，提供訊息發送者6操作介面，其功能至少包括：階層帳號管理功能，以資料庫2當作存取的資料員。帳號使用者可以查詢特定時間的執行、異動作業記錄；資源管理功能，提供管理電信服務商特碼帳號、設定諸如每月可傳送之訊息總量之帳號權限；訊息傳送功能，可提供傳送諸如SMS、WAP Push、MMS、E-mail等訊息種類之發訊功能、多元受訊者輸入方式；發訊狀態查詢功能，提供依權限、條件查詢、統計發訊紀錄。

通訊錄管理功能，提供依權限查詢、管理群組、成員等通訊錄資料。亦提供快速建立及備份通訊錄方式；罐頭訊息管理功能，提供依權限查詢、管理罐頭訊息；系統維運功能，提供初始安裝、系統資訊及屬性等設定功能，亦提供資料庫管理功能。

本發明之資料庫2，為網頁伺服器模組1及多功能服務應用程式介面模組4、訊息代理器模組3之資料儲存介面；它儲存了由網頁伺服器模組1所產生的帳號、電信服務商特碼帳號、群組、成員、群組成員隸屬、罐頭訊息、異動紀錄、發訊訂單資料等。提供訊息代理器模組3所需發訊訂單資料等，並儲存訊息代理器模組3發送訊息後的發送紀錄。

本發明之訊息代理器模組3，定時至資料庫2查詢是否有已達發訊時間的訂單，若有，則本模組會根據訂單內容至佇列讀取相對應之受訊清單傳送至電信服務商訊息閘道器8(傳送至接收終端9)，並且將傳送結果更新至資料庫2及寫入每筆門號之發訊紀錄；另外，本模組亦會定時至資料庫2查詢每筆門號受訊狀態，若有未達最終狀態(傳送中)的紀錄，則傳送至電信服務商訊息閘道器8查詢受訊狀態，並且將受訊結果更新至資料庫2。

本發明之多功能服務應用程式介面模組4提供的介接介面至少包括：訊息傳送介面，可提供傳送諸如SMS、WAP Push、MMS、E-mail等訊息種類之發訊介面；發訊狀態查詢介面，提供查詢發訊訂單、受訊紀錄之介面。查詢模式可以為單一或批次受訊狀態的查詢；通訊錄管理介面，提供查詢、管理群組、成員等通訊錄資料之介面；元件狀態監控介面，可提供諸如電信服務商訊息閘道器8狀態/流量、Proxy(代理器)、訊息代理器模組3等狀態資訊之查詢介面。

請參閱圖五及圖六所示，分別為本發明之元件狀態呈現示意圖以及本發明之元件狀態代理器模組架構圖，係由元件狀態代理器模組5(如圖一)，透過網頁伺服器模組1的驅動而去收集訊息代理器模組3、電信服務商訊息閘道器8的狀態資訊，再將這些資訊搭配不同顏色燈號(如：紅、橙、綠燈號)以視覺化方式呈現；如紅燈代表元件停止運作或無法確定狀態(Fail N/A)；橘燈代表元件負載稍重或訊息擁塞(Congestion)；綠燈代表元件運作順暢(OK)。

請參閱圖六，為本發明之元件狀態代理器模組架構圖，其實施方式為以JMX標準實作，其中MBeanServer為一容器(Container)，上面承載各個不同監控狀態擷取協定的MBean(Managed Bean,JAVA專有名詞)，以自訂協定自訊息代理器模組3擷取狀態，或自訂的XML Over HTTP的協定自電信服務商訊息閘道器8擷取狀態，該協定之語法可以如下說明：

rsp_time：電信服務商訊息閘道器回應request的時間

status：電信服務商訊息閘道器的狀況，包含ok/fail/unknown

traffic：電信服務商訊息服務的傳送情形，包含

smooth：訊息服務順暢

heavy：訊息服務負載重

congestion：訊息服務壅塞

unknown：無法偵測狀態

description：狀態描述

本發明所提供之多種類訊息發送裝置，與其他習用技術相互比較時，更具有下列之優點：

1.本發明因裝置置放於企業內部網路，可提供資料更安全的傳遞，有效防止商業機密相關訊息外洩的可能。

2.本發明可整合各種類訊息發送於單一設備，快速導入多種類訊息發送的應用。

3.本發明提供企業資訊系統介接之多功能服務應用程式介面模組，可以加速企業內部流程整合之開發時程。

4.本發明具備元件狀態資訊收集及視覺化檢視的功能，提供使用者輕易的了解發訊流程的瓶頸。

上列詳細說明乃針對本發明之一可行實施例進行具體說明，惟該實施例並非用以限制本發明之專利範圍，凡未脫離本發明技藝精神所為之等效實施或變更，均應包含於本案之專利範圍中。

綜上所述，本案不僅於技術思想上確屬創新，並具備習用之傳統方法所不及之上述多項功效，已充分符合新穎性及進步性之法定發明專利要件，爰依法提出申請，懇請　貴局核准本件發明專利申請案，以勵發明，至感德便。

1．．．網頁伺服器模組

2．．．資料庫

3．．．訊息代理器模組

4．．．多功能服務應用程式介面模組

5．．．元件狀態代理器模組

6．．．訊息發送者

7．．．企業資訊系統

8．．．電信服務商訊息閘道器

9．．．接收終端

圖一為本發明多種類訊息發送裝置的架構圖；

圖二為本發明之訊息傳送流程之UML循序圖；

圖三為本發明之訊息傳送流程之狀態轉換圖；

圖四為本發明之多功能服務應用程式介面模組提供企業資訊系統網路服務之介面架構圖；

圖五為本發明之元件狀態呈現示意圖；以及

圖六為為本發明之元件狀態代理器模組架構圖。

1．．．網頁伺服器模組

2．．．資料庫

3．．．訊息代理器模組

4．．．多功能服務應用程式介面模組

5．．．元件狀態代理器模組

6．．．訊息發送者

7．．．企業資訊系統

8．．．電信服務商訊息閘道器

9．．．接收終端

Claims (7)

1. 一種多種類訊息發送裝置，包括：一網頁伺服器模組，係與一訊息發送者、一資料庫及一元件狀態代理模組相介接，提供訊息發送者操作介面；一資料庫，係與一訊息代理器模組與一多功能服務應用程式介面模組相介接，並儲存訊息發送相關的資料；一訊息代理器模組，將資料庫待發送之訊息傳送至一電信服務商訊息閘道器，並與一元件狀態代理器模組相介接；一多功能服務應用程式介面模組，係提供一企業資訊系統介接本裝置；以及一元件狀態代理器模組，接受網頁伺服器模組的請求，收集裝置元件及電信服務商訊息閘道器狀態資訊。
2. 如申請專利範圍第1項所述之一種多種類訊息發送裝置，其中該網頁伺服器模組提供訊息發送者操作介面，可包含：a.帳號管理，管理使用者存取資料庫之權限；b.資源管理，提供管理電信服務商特碼帳號、設定諸如每月可傳送之訊息總量等；c.訊息傳送，提供傳送諸如SMS、WAP Push、MMS、E-mail等訊息種類之發訊功能及多元受訊者輸入方式；d.發訊狀態查詢，提供依權限、條件查詢及統計發訊紀錄；e.通訊錄管理，提供通訊錄資料查詢、快速建立及備份通訊錄方式；f.罐頭訊息管理，提供依權限查詢、管理罐頭訊息；g.系統維運，提供初始安裝、系統資訊及屬性等設定功能，亦提供資料庫管理功能。
3. 如申請專利範圍第1項所述之多種類訊息發送裝置，其中該訊息代理器模組係定時至資料庫查詢是否有已達發訊時間的訂單，而將資料庫待發送之訊息傳送至電信服務商訊息閘道器。
4. 如申請專利範圍第1項所述之多種類訊息發送裝置，其中該訊息代理器模組更包含可查詢訊息受訊狀態，係定時至資料庫查詢每筆門號受訊狀態，若有未達最終狀態(傳送中)的紀錄，則傳送至電信服務商訊息閘道器查詢受訊狀態，並且將受訊結果更新至資料庫。
5. 如申請專利範圍第1項所述之多種類訊息發送裝置，其中該多功能服務應用程式介面模組提供企業資訊系統介接之介面，可包含：a.訊息傳送介面，可提供傳送諸如SMS、WAP Push、MMS、E-mail等訊息種類之發訊介面；b.發訊狀態查詢介面，可提供查詢發訊訂單、受訊紀錄之介面。查詢模式可以為單一或批次受訊狀態的查詢；c.通訊錄管理介面，提供查詢、管理群組、成員等通訊錄資料之介面；d.元件狀態監控介面，可提供諸如電信服務商訊息閘道器狀態/流量、Proxy、訊息代理器模組等狀態資訊之查詢介面。
6. 如申請專利範圍第1項所述之多種類訊息發送裝置，其中更包含使用該裝置之訊息發送方法，其步驟包含：a.訊息發送者透過本裝置之網頁伺服器模組或是企業資訊系統透過本裝置之多功能服務應用程式介面模組進行發訊；b.若發訊參數格式正確，將發訊訂單新增至資料庫、受訊清單寫入佇列，回報訊息發送者/企業資訊系統接受發訊及受訊數；c.訊息代理器模組，定時至資料庫查詢是否有已達發訊時間的訂單；d.若有，則訊息代理器模組會根據訂單內容至佇列讀取相對應之受訊清單傳送至電信服務商訊息閘道器，將傳送結果更新至資料庫及寫入每筆門號；e.訊息代理器模組定時至資料庫查詢每筆門號受訊狀態；f.若有未達最終狀態(傳送中)的紀錄，則傳送至電信服務商訊息閘道器查詢受訊狀態，並且將已達最終狀態之受訊結果更新至資料庫。
7. 如申請專利範圍第1項所述之多種類訊息發送裝置，其中更包含使用該裝置之元件狀態收集及檢視方法，其步驟包含：a.網頁伺服器模組會驅動元件狀態代理器模組去收集軟體/設備元件可為訊息代理器模組、電信服務商訊息閘道器等的狀態資訊；b.等待相關狀態資訊回傳後，將這些資訊搭配燈號以視覺化方式呈現，例如：紅燈代表元件停止運作或無法確定狀態；橘燈代表元件負載稍重或訊息擁塞；綠燈代表元件運作順暢。