事件更新管理系統的製作方法

2023-05-10 06:14:16

專利名稱：事件更新管理系統的製作方法
技術領域：
本發明涉及管理網站更新的系統和方法。更具體地，本發明涉及預訂有 關網站的新內容或經過改變的內容的更新和通知並將其發送到移動服務用戶 的系統和方法。
背景技術：
網際網路技術的快速發展以及隨後的經濟活動在網際網路上的擴展已經導致 引入數字資訊時代的網際網路的迅速成長。現在，網際網路是同時將信息擴散到大量人群的最快的方法。從2000年以來，網絡用戶數量的增加己經超過一倍 以上，並且根據網際網路世界統計數字(Internet World Stats)的統計，到2006 年，網際網路的用戶將超過十億二千萬。還有相當大的擴展餘地，而所發生的 這些成長中的相當大的方面將通過使用無線應用進入網際網路。移動和無線設 備已經大規模地擴展了市場。根據市場研究機構Garter的研究，在2005年， 全球手機銷售達到兩億另五百萬部。最近，據估計全球有十五億全球移動通 信系統(GSM)的用戶，到2010年，該數字將規劃提高到三十億。此外， 最新的數字顯示，在2006年，智能行動裝置的全球裝運量提高55%,與一 年前相比，智慧型電話裝運量提高75%，集中於從手提設備向多功能匯集設備 的轉變。
網際網路本身也已經轉變成很多公司的大市場行為的戰場。某些最大的公 司已經通過網際網路利用低成本廣告宣傳的高效率特性以及進行電子商業活動 而不斷成長。網際網路也已經向傳統的銷售和新聞傳播概念提出挑戰並進行革 命性的變革。此外，諸如博客和社會網絡的在線團體的發展進一步預期將 來的網際網路的形態。因此，由於在線可達到的信息的絕對數量，保持對互聯 網上的新事件和更新的跟蹤對網絡用戶而言逐漸成為一項巨大的任務。
近來，已經有允許網絡用戶對其感興趣的網站的可得到的更新保持跟蹤 的系統。由這些系統使用的技術被稱為"推出警示"，因為任何時候可得到
更新都將推出各種更新的片段。因此，推出警示系統允許可以信任的應用服 務器向網絡用戶主動發送人格化的內容。推出警示系統補充網際網路用戶請求 來自網站的特定信息的傳統的"推出"模型。為了從網站接收網絡用戶感興 趣的更新，用戶必須首先預訂來自網站的警示更新。該過程相當於在郵政目 錄上註冊郵政接收的過程。通常，諸如用戶名，電子郵箱地址或行動電話號 碼的信息由網際網路用戶通過由網站提供的警示註冊表提供。然後，所收集的 信息被記錄在後端伺服器所有的資料庫中，該信息通常由網站管理人員管理 和操作。
當前的推出警示系統的一般的問題在於網站管理人員實體維護資料庫以 確保用戶信息的精確性。因此，對於大資料庫，所要求的將要被實行的維護 工作巨大且麻煩。雖然這些推出警示系統可由大組織機構管理，但其成本和 複雜性使所述推出警示系統對於小網站操作人員，個人博客出版者等不能適 應。另外，當前的推出警示系統被主要應用於僅向電子郵箱地址發送更新。
隨著行動裝置的擴展及其"永遠接通，永遠為用戶"的特性，已經有不 斷增加數量的喜歡通過其行動裝置接收警示的網絡用戶。例如在不久的將來 的電視節目中的警示最好在該節目廣播之前約15到30分鐘發送到用戶的移 動設備。與經常在適當的時間不能閱讀的電子郵件相比，該行動裝置很可能 總是和用戶在一起並且總是接通。還有對於諸如拍賣出價警示，會議備忘錄 等的移動警示的其他應用，這樣的警示最好通過短消息服務(SMS)消息，
多媒體消息服務(MMS)消息或無線應用協議(WAP)推出消息發送。盡 管使用移動警示有明顯的優點，但還有很多原因使移動警示沒有像幾乎無處 不在的電子郵件警示一樣由網站管理者廣泛實施。
實施移動警示的一般的問題在於發送移動警示的累積的高成本。通常， 為了發送移動警示，移動警示發送者必須是移動服務提供者的預訂者並擁有 發送移動警示需要的相對技術含量的設備，或具有通過移動服務提供者的網 絡向接收者傳遞消息的一些其他手段。在任何一種情況下都有對於發送者涉 及的不可補償的成本問題。發送移動警示可能使發送者負擔沒有明確的收益 可能性的可觀數量的成本。例如，對於諸如自由廣播的廣告支持的電視臺， 自由的基於網絡的電子郵件服務提供者和個人博客出版者的操作者沒有明確 的刺激以通過移動警示通知其廣播節目，新電子郵件或博客更新的預訂者。 僅可應用於非常選擇性條件的基於工作的替代方案作為接收者支付的模 型存在，該模型中消息的接收者為接收消息支付相當數量的費用，而發送者 不付費。例如涉及移動手機彩鈴或移動手機壁報的行動電話內容提供者通常 採用接收者支付的業務模型。行動電話用戶在其每月電話帳單中為移動內容 支付費用，收益在移動服務提供者和行動電話內容提供者之間分享。因此， 將要向行動電話用戶收取的費用的精確數量和在移動服務提供者和行動電話 內容提供者之間分享的其收益的百分比已經通過協議預先議定。該協議要求 行動電話內容提供者承擔一定的最小數量的行動電話消息並要求承擔將要由 行動電話內容公司向移動服務提供者支付的費用。此外，行動電話內容提供 者也被要求進行客戶系統集成工作以將其系統互連到移動服務提供者的網絡 上。基於工作的替代方案存在若干問題，尤其在對於低數量，非贏利的發送 者方面。
一個問題在於該模型不適用於數量小的發送者，因為例如幾十、幾百或
幾千的一定的最小數量的移動警示必須由消息發送者承擔。；另一個問題是 當該模型基於向接收者收取相當數量的費用然後分享收益時，對於不使用移 動警示機構銷售內容的小網站所有者沒有關係。進一步，希望作為非贏利服 務提供移動警示的小網站所有者可能發現預支付的承擔費用在財務上是不合 理的。該模型的還有一個問題是，消息發送者必須將其系統與移動服務提供 者的消息發送系統形成整體，這對於消息發送者和移動服務提供者都涉及更 多的事件，工作量和成本。最後，該方法經常成為消息發送者虛假支付行為 的犧牲品，因此負面影響移動服務提供者和行動電話客戶之間的關係。
上述方法有時取決於向移動服務提供者提交將要向其收取服務費用的移 動電話預訂者的數量目錄的消息發送者。當其內容可以由用戶通過其他移動 服務提供者的網絡或從發送者的網站(由用戶在發送者的網站上直接輸入其 移動號碼)經由電話呼叫請求時，這是行動電話僅是內容的接收者的結果。 取決於所使用的技術，在接收者收到其行動電話帳單並對帳單上的相關收費 提出質疑之前，移動服務提供者因此不能容易確定消息發送者主張的接收者 目錄的合法性。以後的質疑解決過程則使移動服務提供者和作為終端客戶的 消息接收者之間的關係趨於緊張。
對於所有上述問題都存在的還有一個問題是，通常，消息發送者也將需 要與各個移動服務提供者的一個協議，消息發送者希望向該移動服務提供者 的預訂者傳遞消息。由於大多數移動服務提供者都有其自己的消息發送系統 和合法的合同，因此分別與各個移動服務提供者籤署合同以及與其互連對於 消息發送者是既費時，昂貴又不現實的。為了解決該問題，若干組織提供一 種服務，其中消息發送者與其中一個組織籤署合同，並且該組織與大多數移 動服務提供者建立關係並且處理合同和技術的各種問題。但是，這些組織要 求收取費用，該費用要為每次發送的消息支付，因此該費用甚至往往比如果 消息發送者與移動服務提供者直接籤署合同而向移動服務提供者支付的費用 更高。因此，以這樣的方式使用中間服務提供者對於消息發送者也是既昂貴 又不現實的。
另一個問題是對於消息接收者在相關於退出接收消息方面的明確度的缺
失。這在預訂諸如每日笑話(joke-of-the-day)服務時尤其重要，在該每日笑 話服務中，消息發送者按日向消息接收者收取按日向接收者的行動裝置發送 笑話的費用。由於該服務不是一次性業務，因此必須有消息接收者終止服務 的明確的方法。還有，使接收者不再預訂的從服務退出的機制明確也不符合 消息發送者的利益。另外，在移動警示中包括詳細的退出信息也是技術上的 挑戰，尤其是當移動警示通過SMS發送時更是如此，因為SMS有內容必須 被包括在其中的160字符的限制。
因此，當前系統的缺點證實了對向接收者傳遞移動警示的系統和方法的 需求，該系統和方法不需要接收者支付接收移動警示的相當數量的費用，並 且最好不需要消息發送者支付發送移動警示的費用，同時能夠向儘可能多的 移動服務提供者的預訂者發送移動警示。另外，該系統和方法最好易於使用 和易於集成，使幾乎沒有技術知識或能力的終端用戶發送移動警示成為可行， 同時該系統和方法最好是可計量的並且適合於符合可能希望以更複雜的業務 規則傳遞更複雜的消息的大組織的需求。還有另一個要求是該系統和方法最 好包括諸如接收者的接收移動警示的請求的檢驗的合法性參數，因此將移動 垃圾郵件減至最小並且提供明確的退出機制，使接收者防止一個或多個消息 發送者發送其移動警示更容易。

發明內容
本文揭示的本發明的實施例提供事件更新管理系統。根據本發明的一個 方面提供一種事件更新管理系統，該事件更新管理系統包括數據模塊，匹配 模塊，處理模塊和警示模塊。數據模塊接收由主網絡伺服器提供的警示註冊 數據。警示註冊數據在移動服務用戶通過主網絡伺服器提交與事件對應的警 示註冊請求時產生。匹配模塊轉而將移動服務用戶與預先定義的包含多個移 動服務預訂者的目錄相匹配。當與多個移動服務預訂者之一匹配時，移動服 務用戶就是移動服務預訂者。然後處理模塊處理警示註冊數據並向存儲在事 件更新管理系統中的資料庫記錄該警示註冊數據。最後，警示模塊響應由主 網絡伺服器或由操作該主網絡伺服器的網站管理者提供的指令產生警示並將 其發送到移動服務用戶。


圖1為本發明的優選實施例中用於生成物體整體外表面的單組圖像和進 行檢測的系統的示意圖2為本發明中進行物體外表面檢測的系統的示意圖3為本發明優選實施例中檢測中用於分析物體的單組極坐標映射的圖
像數據的系統的示意圖4為本發明優選實施例中處理外表面圖像數據的方法的流程圖5是生成的圖像數據組以演示本發明的優選實施例；
圖6是本發明優選實施例中用於生成物體整體外表面和頂部的單個圖像
以及進行檢測的系統的示意圖7是本發明優選實施例中用於生成一幅物體整體外表面和頂部的圖像
以及進行檢測的系統的示意圖8是本發明優選實施例中通過使用錐形鏡生成物體整體外表面和頂部
的圖像的系統示意圖9是本發明優選實施例中用於生成物體整體外表面和頂部的圖像以及
進行檢測的系統的示意圖;
具體實施例方式
為了處理上文提出的問題，下文將敘述用於向為了通過移動警示接收網 站更新已經進行註冊的移動服務用戶提供更新和事件通知的事件更新管理系 統。本發明的實施例提供一種系統和方法，該系統和方法使網站的管理者在 由該網站管理者管理的網站上的有關內容發生變化時能向對接收警示感興趣 的移動服務用戶發送移動警示。所揭示的系統和方法處理來自移動用戶的警 示註冊請求以及來自網站管理者的警示發送請求，儲存警示註冊信息，向移 動服務用戶發送移動警示，以及向移動服務提供者，移動服務用戶和網站管 理者中的至少一個對象開出服務使用帳單。所揭示的系統和方法還進一步使 網站管理者以最低的成本或不需成本容易並迅速地使用該系統。
為了簡明的目的，下文對本發明的敘述限於向為了通過移動警示接收網 站更新已經進行註冊的移動服務用戶提供更新和事件通知的系統中的使用方 面。但是該限制並不從要求與向為了通過移動警示接收網站更新己經進行注 冊的移動服務用戶提供更新和事件通知的系統相似的操作性能的其他應用場 合排除本發明的各個實施例。作為對於本發明的實施例的基礎的操作和功能
原理在所有各個實施例中都是共同的。
下文敘述的本發明的各個實施例根據附圖1至附圖9，圖中相同的元件 被標以相同的參考數字。
參考圖1敘述本發明的一個實施例，圖中顯示說明事件更新管理系統100 的不同的系統元件之間的相互作用的框圖。事件更新管理系統IOO包括事件 管理伺服器102，主網絡伺服器104，移動服務用戶106 (下文稱為移動用戶) 和移動服務提供者108。事件管理伺服器102最好位於並預先安裝於應用服 務提供者的處所，其中應用服務提供者(未顯示)操作事件管理伺服器102 並通過第一組移動連結110將其連接到一個或多個移動服務提供者108。可 以有運行多個事件管理伺服器102，連接到多個不同的移動服務提供者108 和主網絡伺服器104以及為不同的移動用戶106服務的多個應用服務提供者。 移動用戶106是由移動服務提供者108提供的移動服務的預訂者或非預訂者， 操作事件管理伺服器102的應用服務提供者與該移動服務提供者108連接， 或者操作事件管理伺服器102的應用服務提供者具有與該移動服務提供者
108的合同。另外，至少一個移動服務提供者108可以具有應用服務提供者 的功能。多個事件管理伺服器102為了協作也互相連通。
事件管理伺服器102處理和記錄從主網絡伺服器104接收的移動警示注 冊信息。然後所接收的移動警示註冊信息可被記錄在事件管理伺服器102中 存儲的資料庫(未顯示)中。另外，事件管理伺服器102也提供使希望向移 動用戶106發送移動消息的網站管理者能籤署移動警示服務的協議的功能， 向網站管理者提供工具和/或用於向網站的訪問者提供註冊移動警示的能力 的代碼，還進一步向網站管理者提供用於管理其自己的存儲在事件管理系統 102中的帳戶的管理工具。術語"網站管理者"被廣泛地但非排他地使用以 指系統管理者或由例如允許用戶粘貼和共用圖片或發表博客的網站經營的用 戶個人網頁。在該情況下，帶有粘貼和共用圖片或發表博客的帳戶特權的用 戶則被考慮為"網站管理者"，而不論該用戶是否具有對經營其個人網頁的服 務器的管理權，只要用戶具有修改其由訪問者看到的個人網頁的權利即可。
事件管理伺服器102通過移動服務提供者108經由移動警示向移動用戶 106發送通知並從移動用戶106接收回應。移動服務提供者108最好是移動 用戶106的移動服務提供者108。該事件管理伺服器102最好進一步向移動 用戶106提供控制哪一個網站管理者可以在任何給定的周期內向其發送多少 警示的能力，包括臨時或永久阻擋來自該移動用戶106先前已經註冊其警示 的網站管理者的所有其他警示的能力。移動警示最好是短消息服務(SMS) 消息，多媒體消息服務(MMS)消息或無線應用協議(WAP)推動消息警示。 操作主網絡伺服器104的網站管理者已經與應用服務提供者預先籤署使用由 事件管理伺服器102提供的上述服務的合同。相似地，應用服務提供者也已 經與移動服務提供者108預先籤署傳遞移動警示的合同，該合同可以為移動 警示反向收費(接收者支付)。事件管理伺服器102的最後的重要功能是向移 動用戶106，移動服務提供者108和網站管理者開出由事件管理伺服器102 提供的上述服務的帳單。
主網絡伺服器104向在主網絡伺服器104上主持的網絡衝浪訪問網站(未 顯示)提供網頁。移動用戶106通過雙向有線連結或無線連結112訪問在主 網絡伺服器104上主持的網頁。由網站提供的網頁在內容上是複雜的和不同 的。對於與事件管理伺服器102連通的主網絡伺服器104，主網絡伺服器104
必須首先向事件管理伺服器102進行註冊。主網絡伺服器104通過有線的或
無線的雙向連結114與事件管理伺服器102連通。主網絡伺服器104也必須 用一組軟體應用編程界面(API)結構中定義的軟體功能預先編程並且與軟 件庫形成整體。軟體庫是由應用服務提供者提供的該組軟體應用編程界面 (API)結構中定義的功能的實施形式，以二進位的形式彙編。或者，主網 絡伺服器104可以通過簡單地將超文本標記語言(Hyper Text Markup Language: HTML)連結代碼模塊插入定義該網站的編程代碼，或通過在應用服務提供 者和網站管理者之間互相同意的其他技術手段與事件管理伺服器102連通。 應用服務提供者提供至少一組API結構，軟體庫和HTML連結代碼。
事件管理伺服器102通過其與移動服務提供者108的連接或合同發送通 知移動用戶106網站更新的移動警示，移動服務提供者108轉而通過第二組 移動連結116向移動用戶106傳遞移動警示。移動警示僅在網站管理者為指 令向移動用戶106發送警示而在事件管理伺服器102上進行記錄或由網站管 理者操作的計算機為基礎的系統用API和/或HTML代碼和/或由上述應用服 務提供者向網站管理者提供的其他技術手段自動在事件管理伺服器102上進 行記錄時發送。
網站管理者為了向作為由網站管理者操作的網站的訪問者並且進一步對 接收有關網站更新的移動警示感興趣的移動用戶106發送移動警示，網站管 理者需要通過填寫服務註冊表籤署由應用服務提供者提供的相關服務的合 同。網站管理者可以籤署成為低數量消息發送者或高數量消息發送者的合同。
圖2以定義低數量消息發送者的服務註冊表200 (下文稱為低數量表) 的輸入域的圖形格式描繪低數量表200。低數量表200包含定義網站管理者 名，網站管理者電子郵箱地址，網站名，網站URL，詢問號l，詢問號2， 支付細節，logo,國家代碼和聯繫電話。國家代碼和電話號碼為身份合法性， 質疑解決或其他溝通事項提供低數量消息發送者可以到達的聯繫點。logo最 好在logo輸入域下提交，該logo輸入域將附貼到移動用戶106在籤署與網 站管理者的移動警示服務的合同時看到的註冊表中，其中logo向網站管理者 提供製作註冊表的能力。此外，在詢問號1下，網站管理者被要求指出網站 管理者是否希望能向作為沒有與應用服務提供者的反向支付合同或相似協議 的移動服務提供者的預訂者的移動用戶106發送移動警示。如果網站管理者
決定向作為沒有與應用服務提供者的合同或相似協議的移動服務提供者的預 訂者的移動用戶106傳遞移動警示，則網站管理者被要求在詢問號2下進一 步決定是否支付作為發送移動警示的結果產生的費用或者是否向移動用戶
106收取接收移動警示的費用。進一步，如果網站管理者希望確定向作為沒 有與應用服務提供者的反向支付合同或相似協議的移動服務提供者108的預 訂者的包括不願意承擔接收移動警示的費用的移動用戶106發送移動警示， 則網站管理者可選擇支付所發送的移動警示的費用。然後網站管理者被要求 提供信用卡細節，財務信息或提供有關在支付細節下支付的其他模式的細節。
相似地，圖3以定義高數量消息發送者的服務註冊表300 (下文稱為高 數量表)的輸入域的圖形格式描繪高數量表300。高數量表300包含定義網 站管理者名，網站管理者的電子郵箱地址，網站名，網站URL，國家代碼和 聯繫電話。高數量表300的輸入域的定義與圖2所示的低數量表200的各個 相似輸入域的定義相似。
圖4顯示網站管理者與應用服務管理者籤署向移動用戶106發送移動警 示的合同的處理流程圖400。在步驟402，網站管理者接受由應用服務提供者 提出的使用事件更新管理系統100的條款和條件。網站管理者被要求決定是 否註冊為低數量消息發送者或高數量消息發送者，其中該決定然後在步驟 404中做出。
低數量消息發送者最好具有每月發送少於1000條消息的要求。對於低數 量消息發送者，最好自行完成註冊和激活過程，不需要來自應用服務提供者 的任何人工幹預。這是因為應用服務提供者最好預先確定，合理地產生與例 如通過垃圾郵件或風險信息提出的立即激活相關的業務風險，應用服務提供 者不承受低數量發送者通過移動警示服務的激活產生的任何額外成本。另外， 應用服務提供者可能替代地從其預訂者接收移動警示的移動服務提供者接收 支付。另外，為了化解業務風險，應用服務提供者也可以提出對於低數量消 息發送者的附加限制，例如限制低數量消息發送者被允許在給定的周期中或 向移動用戶106發送的最大數量的消息的任何組合。應用服務提供者也最好 假定低數量消息發送者具有有限的技術熟練程度或有限的技術資源，或者不 願意或不能在緊密的系統集成中進行投資。這樣的低數量消息發送者的實例 是寫博客者，寫博客者希望提供博客讀者，通過行動電話的更新警示，但缺
乏用以進行系統集成的技術能力。對於低數量消息發送者，應用服務提供者
最好能得到HTML連結代碼的自動產生的模塊，低數量消息發送者能夠容易
地將該模塊與使網站訪問者得到移動警示服務的網站的網頁集成到一起，允 許達到容易的實施方式。另外，應用服務提供者最好也能得到有關怎樣進行
HTML連結代碼集成的繪圖指導，例如指示在網頁中何處插入HTML代碼。
在其他方面高數量消息發送者最好具有每月發送多於1000條消息的要 求，對某些發送者可能要求每小時發送多於1000條消息。對於高數量消息發 送者，應用服務提供者最好可以決定投入達到一定因素的合法性所需要的時 間和工作量，諸如高數量消息發送者的身份，業務性質，公司註冊信息，財 務保證或為了處理業務風險的其他這樣的風險化解因素。作為進行合法性工 作的結果，應用服務提供者也可以對高數量消息發送者提出少量的或不同的 或不提出限制。此外，也假定高數量消息發送者具有技術資源以及使網站與 應用服務提供者的系統更緊密集成的興趣和能力，因此向高數量消息發送者 提供更高水平的定製能力和自動化。高數量消息發送者的非限制性實例是向 幾百萬網絡用戶提供服務的在線拍賣站點或在線免費電子郵件服務。在該實 例中，雖然移動服務提供者108最好可以要求電子的或紙質的標準合同文件， 但網站管理者不被要求與移動服務提供者108協商籤署消息發送合同。另外， 在向網站管理者提供的消息發送服務的激活之前不要求來自移動服務提供者 108的任何人工幹預。
如果網站管理者決定籤署協議成為低數量消息發送者，則網站管理者在 步驟406填寫低數量表200。在步驟408，網站管理者需要決定是否能向作為 與移動服務提供者沒有反向收費協議的移動服務提供者108的預訂者的移動 用戶106發送移動警示。通常，在上述方案下，由作為接收為移動用戶106 指定的移動警示的第一方的移動服務提供者108向應用服務提供者收取向移 動用戶106發送移動警示的費用。因此，應用服務提供者最好可以希望從低 數量消息發送者或籤署從低數量消息發送者接收移動警示的移動用戶106回 收所承受的費用，或者在其基礎上提高價格。
如果網站管理者決定在向不是與應用服務提供者有反向收費合同或類似 協議的移動服務提供者108的預訂者的移動用戶106傳遞移動警示方面有靈 活性，則應用服務提供者在步驟410請求低數量消息發送者存有一定的財務
保證金，提供可檢驗的信用卡細節或提供其他形式的財務保證，從而允許應 用服務提供者回收預期的費用。在步驟412，應用服務提供者檢驗由網站管 理者在步驟410提供的財務信息的合法性，並向網站管理者的信用卡收取預 先商定的指定數量的金額或進行從網站管理者的銀行帳戶直接劃款，或者從 事網站管理者和應用服務提供者之間互相原先同意的財務業務活動。條款和
條件已在步驟402和410由網站管理者認可，並且確定反向收費合同或類似
協議將在什麼程度上不覆蓋被傳遞的移動警示。
最後，在步驟414，應用服務提供者記錄在步驟412發生的業務結果。 該業務結果最好包括網站管理者是否被允許向作為與應用服務提供者沒有任 何反向收費合同或類似協議的移動服務提供者108的預訂者的移動用戶106 發送移動警示，將收取移動警示的費用的合法的各方，和低數量表200的注 冊信息。然後，應用服務提供者向網站管理者提供諸如HTML連結代碼，注 冊ID，密碼的信息和為了使用發送服務網站管理者最好需要的任何其他文 件。該信息最好由使用電子郵件，即時屏幕上操作，註冊郵政等的可行的手 段提供。然後應用服務提供者立即激活低數量消息發送者的消息發送服務。
如果網站管理者確定被要求的各項需要適合於高數量消息發送者，則網 站管理者在步驟420填寫高數量表300。當應用服務提供者已經確定高數量 消息發送者要求人工檢驗時，應用服務提供者的經認證的代表在步驟422與 網站管理者建立關係。應用服務提供者在步驟422確定網站管理者的需要， 獲得應用服務提供者要求的信息，並履行任何其他紙面工作要求。最後，在 步驟424，應用服務提供者檢驗從高消息發送者獲得的所有相關數據。當所 有要求的內部業務需要被履行時，應用服務提供者向網站管理者提供相關的 API，代碼，文件，用戶ID，密碼和為了使用消息發送服務網站管理者最好 需要的任何其他信息和工具。另外，在步驟424，應用服務提供者儲存相關 的信息，憑證和附屬於高消息發送者的文件，並且激活高數量消息發送者的 服務。
應用服務提供者在處理流程圖400中可以進一步包括網站管理者的身份 的檢驗過程(未顯示)，尤其是在最好不要求紙面工作的低數量消息發送者的 情況下。該檢驗過程最好至少包括請求低數量消息發送者的移動號碼，向該 移動號碼發送確認消息和要求該確認消息的回應的步驟。
對從網站接收更新感興趣的移動用戶106被要求通過填寫以定義警示注
冊表500的輸入域的圖形格式顯示警示註冊表500的圖5中描繪的在網站上 提供的警示註冊表500提交警示註冊請求。但是，為了防止濫用，應用服務 提供者可以預先定義對移動用戶106為了接收移動警示而向其註冊的網站數 的限制。警示註冊表500包括定義國家代碼，行動電話號碼，詢問號l，電 子郵箱地址和移動操作者的輸入域。該行動電話號碼定義用於向其發送移動 警示的行動電話號碼，該行動電話號碼最好屬於移動用戶106。另外，為了 解決假籤署的問題，事件管理伺服器102通過向該行動電話號碼發送確認消 息使警示註冊請求合法化。然後移動用戶106回發對合法化的回應。合法化 回應採取返回SMS的形式，或者將確認消息中發送的秘密代碼輸入到警示注 冊表500的另一部分，或者是方便的並且提供非否定的安全性的任何其他檢 驗形式。國家代碼定義行動電話在其中註冊的國家，通常是移動用戶106所 在國。電子郵箱地址定義屬於移動用戶106的電子郵箱地址，並且移動用戶 106也被要求在移動操作者輸入域中提供移動用戶106成為其預訂者的移動 服務提供者的名稱。
另外，在詢問號1下，如果移動用戶106的服務提供者108不具有與應 用服務提供者的反向收費合同或相似的協議，則移動用戶106決定是否支付 接收移動警示的可能的費用率。然後，如果移動用戶106同意所述安排，則 移動用戶106被要求提供信用卡信息，存儲保證金，或者在支付細節輸入域 中提供向應用服務提供者支付的其他模式的細節。最後，為了提供移動用戶 106退出移動警示服務的簡易方法，提供移動警示服務的網站最好應該被要 求在退出輸入域下包括退出信息，如圖5的警示註冊表500所示。
圖6顯示說明移動用戶106註冊用事件管理伺服器102接收網站更新的 移動警示的過程的流程圖。操作該網站的網站管理者是低數量消息發送者。 在步驟602，移動用戶106首先填寫並提交通過網站提供的警示註冊表500。 網站最好是移動用戶106對其規則基礎上的更新感興趣的網站。警示註冊表 500最好在低數量消息發送者的網站或應用服務提供者的網站或與應用服務 提供者相關的網站上運行，使通過填寫警示註冊表500產生的警示註冊信息 能夠傳遞到事件管理伺服器102。
當事件管理伺服器102接收到由主網絡伺服器104發送的警示註冊信息時，事件管理伺服器102在步驟604檢查所接收的警示註冊信息的合法性。 事件管理伺服器102在步驟606通過確定至少一個下列依據的履行進一步檢 查所存在的收費安排移動用戶106是應用服務提供者與其具有反向收費合 同或類似協議的一個移動服務提供者108的預訂者，或者主網絡伺服器104 的網站管理者是否己經表示向不是應用服務提供者與其具有反向收費合同或 類似協議的任何移動服務提供者108的預訂者的移動用戶106發送移動警示 的意願，移動用戶106是否不管其不是應用服務提供者與其具有反向收費合 同的一個移動服務提供者108的預訂者而已經表示接收移動警示的希望，以 及移動用戶106是否已經得到諸如信用卡信息，預先的保證金的有效的財務 保證，或者已經提供有關收取傳遞移動警示的費用的其他支付模式的細節。 如果不符合上述任何一個依據，則事件管理伺服器102在步驟608中通知移 動用戶106不能進行移動警示並且丟棄警示註冊信息。然後事件管理伺服器 102可以暫時禁止移動號碼用於進一步的移動警示，直至移動用戶106與其 籤署預訂關係的移動服務提供者108與應用服務提供者籤署反向收費合同或 類似協議。
但是，如果符合至少一個上述依據，則事件管理伺服器102在步驟610 向移動用戶106發回確認消息。該確認消息最好是SMS消息，MMS消息或 WAP推動消息之一。發送確認消息的目的是防止由於移動或垃圾電子郵件注 冊請求造成的假籤署。在接收到確認消息時有移動用戶106最好採取的兩種 類型的回應。第一種回應是移動用戶106被要求在接收到確認消息時進行一 定的行為，其中該行為最好是點擊用於警示註冊的行動裝置上顯示的頁面上 的連結，或者用SMS或MMS或其他移動消息回答，或者用文字，字符，數 字或它們的其他組合或在發送到移動用戶106的確認消息中規定的任何其他 方式通過網站本身回答。在接收到回應時，事件管理伺服器102在步驟612 進行到警示註冊合法化。第二種回應要求移動用戶106在接收到確認消息時 不進行所述行為。移動用戶106不點擊用於警示註冊的行動裝置上顯示的頁 面上的連結，或者不用SMS或MMS或其他移動消息回答，或者不以用文字， 字符，數字或它們的其他組合或在發送到移動用戶106的確認消息中規定的 任何其他方式回答。沒有接收到回應，事件管理伺服器102在步驟612進行 到警示註冊合法化。
警示註冊合法化用作收到移動用戶106被收取的接收移動警示的規定費 率的重要指示。通常該收取的費用與如果移動用戶106是相當於局部發送的
或在移動用戶106是其預訂者的移動服務提供者108的方向上發送的移動消 息的發送者時移動用戶106承受的，被放棄的，或包括在移動服務提供者108 對預訂者有效的移動消息免費包內的規則的費用一樣低。在最壞的情況下， 向移動用戶106提出接收移動警示的費用率或具體的收費，而不管移動服務 提供者108沒有與應用服務提供者的反向收費合同或類似的協議。移動服務 提供者108能夠提供消息發送服務的低費率，因為移動服務提供者108不承 受例如與內容合伙人籤署協議，整合和試驗費用支付關係等中相關的重要成 本。
在步驟612中做出確定警示註冊是否是由籤署協議時由移動用戶106使 用的移動號碼的持有者進行的真實的請求。如果警示註冊被確定為由移動或 電子垃圾郵件註冊請求導致的假籤署，則事件管理伺服器102在步驟614中 丟棄警示註冊信息。如果重複接收到某個行動電話號碼的失效的警示註冊， 則事件管理伺服器102可以在預先定義的時間周期內暫時禁止該行動電話號 碼用於進一步的警示註冊。當超過一個行動電話號碼能夠用於註冊移動警示 的預先定義的失效警示註冊數時則執行該禁止處理。用於解禁的預先定義的 時間周期最好被編程到例如24小時。但是，如果警示註冊被確定為真實，則 事件管理伺服器102在步驟616將所接收的警示註冊信息與註冊的日期和時 間一起記錄到存在於事件管理伺服器102的資料庫中。因此，警示註冊被認 為是非否定的。
當可從網站得到更新時，網站管理者在步驟608中向事件管理伺服器102 上進行記錄以指令事件管理伺服器102向移動用戶106發送移動警示。如果 多個移動用戶106例如通過人工輸入接收者的移動號碼或上傳文件中接收者 的號碼而為接收網站更新進行了註冊，則網站管理者最好被允許選擇移動警 示將要被傳遞到的接收者。網站管理者最好也被允許選擇發送到一個或所有 網站管理者希望將移動警示傳遞到的接收者的被發送消息。
然後在步驟620，事件管理伺服器102在發送移動警示之前檢查是否將 移動警示發送到移動用戶106的所有依據都已滿足。所述依據被相應地列出。 對每一個網站管理者選擇的已經為從特定網站接收移動警示實際上進行註冊
的移動用戶106進行檢驗。另外，移動用戶106向其進行預訂的移動服務提
供者108最好已經與應用服務提供者籤署反向收費合同或類似協議。或者，
網站管理者最好在消息發送服務註冊期間已經指出為發送移動警示進行支付
的意願，或者移動用戶106在移動警示註冊期間已經指出為接收移動警示進 行支付的意願。另外，還對若干其他規則進行檢查，這些規則最好包括限制 在特定時間周期內或向特定移動用戶106或兩者的組合網站被允許發送的移 動警示數的規則。最後，最好進行一次檢驗以確保移動警示將要被傳遞到的 移動用戶106不對消息發送者有導致特定的消息不被接受的任何限制以及可 能是為了向移動用戶106和網站管理者提供質量服務的利益而實施的任何規 則。
如果任何上述依據不符或檢驗失敗，則在步驟622中丟棄用於移動用戶 106的特定消息。但是，如果所有上述依據都符合，則在步驟624中事件管 理伺服器102向移動用戶106發送移動警示，其中移動警示通過由應用服務 提供者為移動用戶106預先限定的適當的移動服務提供者108發送。另外， 不考慮上述依據是否符合，事件管理伺服器102最好在存儲在事件管理服務 器102中的資料庫中記錄移動警示的性質，移動警示本身，發送狀態，傳遞 狀態和與該移動警示相關的任何其他信息。然後可以使該資料庫向網站管理 者開放。
相似地，圖7顯示說明移動用戶106用事件管理伺服器102為接收網站 更新註冊移動警示的過程的流程圖。操作網站的網站管理者是高數量消息發 送者。對於高數量消息發送者，網站需要用所提供的一組API結構預先編程 並且與軟體庫形成整體。這樣，與只能使用由應用服務提供者限定的基本固 定格式的低數量消息發送者相比，高數量消息發送者能夠高度靈活地定製發 送到移動用戶106的移動警示。在步驟702，移動用戶106填寫並提交在網 站上提供的警示註冊表500。網站最好是移動用戶106對其規則基礎上的更 新感興趣的網站。警示註冊表500最好在主網絡伺服器104上被主持，因為 警示註冊表500被高度靈活地定製以適合主網絡伺服器104的要求。
在步驟704，主網絡伺服器104檢査警示註冊表500是否被正確填寫， 將複製件存儲在主網絡伺服器104中並將警示註冊信息向前傳送到事件管理 伺服器102以檢查帳單和警示註冊的合法性，因為帳單信息和消息發送能力
僅與事件管理伺服器102相關。然後，在步驟706，事件管理伺服器102通
過檢查相應列出的至少一個依據的履行檢查所存在的帳單安排移動用戶
106是應用服務提供者與其有反向收費合同或類似協議的一個移動服務提供 者108的預訂者，或者主網絡伺服器104的網站管理者是否指出向不是應用 服務提供者與其有反向收費合同或類似協議的任何移動服務提供者108的預 訂者的移動用戶106發送移動警示的意願，以及上述網站管理者是否願意支 付發送移動警示的費用，不管移動用戶106是否是應用服務提供者與其有反 向收費合同的一個移動服務提供者108的預訂者移動用戶106是否指出接收 移動警示的希望，以及移動用戶106是否已經得到諸如信用卡信息，預先的 保證金的有效的財務保證，或者已經提供有關收取傳遞移動警示的費用的其 他支付模式的細節。
如果不符上述任何依據，則事件管理伺服器102在步驟708通知主網絡 伺服器104收費條件失敗。然後主網絡伺服器104在步驟708通知移動用戶 106不能進行移動警示並丟棄警示註冊信息。主網絡伺服器104以及事件管 理伺服器102也最好暫時禁止該移動號碼用於進一步的警示註冊，直至移動 用戶106向其預訂的移動服務提供者108與應用服務提供者籤署反向收費合 同或類似協議。但是，如果符合至少一個上述依據，則事件管理伺服器102 在步驟710向移動用戶106發回確認消息。該確認消息最好是SMS消息， MMS消息或WAP推動消息之一。發送確認消息的目的是防止由於移動或垃 圾電子郵件註冊請求造成的假籤署。在接收到確認消息時有移動用戶106最 好採取的兩種類型的回應。第一種回應是移動用戶106被要求在接收到確認 消息時進行一定的行為，其中該行為最好是點擊用於警示註冊的行動裝置上 顯示的頁面上的連結，或者用SMS或MMS或其他移動消息回答，或者用文 字，字符，數字或它們的其他組合或在發送到移動用戶106的確認消息中規 定的任何其他方式通過網站本身回答。在接收到回應時，事件管理伺服器102 在步驟712進行到警示註冊合法化。第二種回應要求移動用戶106在接收到 確認消息時不進行所述行為。移動用戶106不點擊用於警示註冊的行動裝置 上顯示的頁面上的連結，或者不用SMS或MMS或其他移動消息回答，或者 不以用文字，字符，數字或它們的其他組合或在發送到移動用戶106的確認 消息中規定的任何其他方式回答。沒有接收到回應，事件管理伺服器102在
步驟712進行到警示註冊合法化。
警示註冊合法化用作收到移動用戶106被收取的接收移動警示的規定費 率的重要指示。通常該收取的費用與如果移動用戶106是相當於局部發送的 或在移動用戶106是其預訂者的移動服務提供者108的方向上發送的移動消 息的發送者時移動用戶106承受的，被放棄的，或包括在移動服務提供者108 對預訂者有效的移動消息免費包內的規則的費用一樣低。在最壞的情況下， 向移動用戶106提出接收移動警示的費用率或具體的收費，而不管移動服務 提供者108沒有與應用服務提供者的反向收費合同或類似的協議。移動服務 提供者108能夠提供消息發送服務的低費率，因為移動服務提供者108不承 受例如與內容合伙人籤署協議，整合和試驗費用支付關係等中相關的重要成 本。
在步驟712中做出確定警示註冊是否是由籤署協議時由移動用戶106使 用的移動號碼的持有者進行的真實的請求。如果警示註冊被確定為由移動或 垃圾電子郵件註冊請求導致的假籤署，則事件管理伺服器102在步驟714中 將該信息返回到主網絡伺服器104。然後主網絡伺服器104在步驟716中丟 棄所接收到的警示註冊信息。如果重複接收到某個行動電話號碼的失效的警 示註冊，則事件管理伺服器102和主網絡伺服器104可以在預先定義的時間 周期內暫時禁止該行動電話號碼用於進一步的警示註冊。當超過一個移動電 話號碼能夠用於註冊移動警示的預先定義的失效註冊嘗試數時，則執行該禁 止處理。用於解禁的預先定義的時間周期最好被編程到例如24小時。但是， 如果警示註冊被確定為真實，則事件管理伺服器102在步驟718將所接收的 警示註冊信息與註冊的日期和時間一起記錄到存儲在事件管理伺服器102的 資料庫中。最好該信息也對主網絡伺服器104有效，使主網絡伺服器104能 夠管理該對於由主網絡伺服器104使用的業務規則適當的警示註冊信息。因 此，警示註冊被認為是非否定的。
當可從網站得到更新時，網站管理者在步驟720中向事件管理伺服器102 上進行記錄以指令事件管理伺服器102向移動用戶106發送移動警示。通常， 如果多個移動用戶106為接收網站更新進行了註冊，則對於高數量消息發送 者，網站管理者被允許選擇移動警示將要被傳遞到的接收者。或者，在主網 絡伺服器104上運行的軟體程序使用API或由應用服務提供者提供的其他代 碼自動向事件管理伺服器102進行註冊。然後軟體程序指令事件管理伺服器 102相關的移動用戶106發送移動警示。
事件管理伺服器102在發送移動警示之前在步驟722檢査是否將移動警 示發送到移動用戶106的所有依據都已滿足。所述依據被相應地列出。對每 一個由網站管理者選擇的為從特定網站接收移動警示實際上已進行註冊的移 動用戶106或API或相似的代碼進行檢驗。另夕卜，移動用戶106向其進行預 訂的移動服務提供者108最好已經與應用服務提供者籤署反向收費合同或類 似協議。或者，網站管理者最好在紙面工作中或者消息發送服務註冊期間已 經指出為發送移動警示進行支付的意願，或者移動用戶106在移動警示註冊 期間已經指出為接收移動警示進行支付的意願。另外，還對若干其他規則進 行檢查，這些規則最好包括限制在特定時間周期內或向特定移動用戶106或 兩者的組合網站被允許發送的移動警示數的規則。最後，最好進行一次檢驗 以確保移動警示將要被傳遞到的移動用戶106不對消息發送者有導致特定的 消息不被接受的任何限制以及可能是為了向移動用戶106和網站管理者提供 質量服務的利益而實施的任何規則。
如果任何上述依據不符或檢驗失敗，則在步驟724中丟棄用於移動用戶 106的特定消息。但是，如果所有上述依據都符合，則在步驟726中事件管 理伺服器102向移動用戶106發送移動警示，其中移動警示通過由應用服務 提供者為移動用戶106預先限定的適當的移動服務提供者108發送。另外， 不考慮上述依據是否符合，事件管理伺服器102最好在存儲在事件管理服務 器102中的資料庫中記錄移動警示的性質，移動警示本身，發送狀態，傳遞 狀態和與該移動警示相關的任何其他信息。然後可以使該資料庫向網站管理 者開放。
使移動用戶106能夠退出接收進一步的移動警示是事件更新管理系統 100的一個重要因素。圖8顯示圖形格式的退出表800，該格式定義退出表 800的輸入域。在退出表800中，移動用戶106被給予選擇輸入域下的用於 限制任何主網絡伺服器104暫時或永久向移動用戶106發送移動警示的選擇， 其中移動用戶106己先期來自各個相關的主網絡伺服器104的移動警示。通 常，警示註冊表500被要求帶有向退出表800的連結，因此使移動用戶106 能容易找到退出信息。在退出表800中，移動用戶106被要求提供用於該用
戶在其中註冊的移動服務的移動號碼信息，包括指出國家代碼，以及用於移 動警示註冊的移動號碼。然後事件管理伺服器102使用該號碼信息確定移動 用戶106先期是否已經為從規定的主網絡伺服器104接收移動警示進行註冊， 並且進一步使用該移動號碼信息使退出請求合法化。另外，移動用戶106也
被要求提供退出處理結束時向其發送退出請求狀態的電子郵箱地址。
圖9說明退出處理900的流程圖，其中在步驟902，移動用戶106經由 通過事件管理伺服器102提供移動警示的任何主網絡伺服器104或直接通過 訪問最好也是事件管理伺服器102的網站的應用服務提供者的網站提交退出 表800。然後在步驟904，應用服務提供者檢驗由移動用戶106提供的移動號 碼是否先期為從主網絡伺服器104接收移動警示進行註冊，而該移動用戶106 希望限制或者暫時或永久禁止該網站向其發送進一步的移動警示。在步驟 906中作出確定。如果確定移動用戶106沒有為從規定的主網絡伺服器104 接收移動警示進行註冊，則事件管理伺服器102最好通過網絡表回應頁通知 移動用戶106該移動用戶106沒有為從規定的主網絡伺服器104接收移動警 示進行過註冊。然後事件管理伺服器102在步驟908丟棄退出請求。但是， 如果確定移動用戶106為從規定的主網絡伺服器104接收移動警示進行過注 冊，則事件管理伺服器102確認請求退出的移動用戶106確實是移動用戶106 在退出表800中指定的移動號碼的持有者。為了防止對服務的欺詐性的或惡 作劇的終止，上述被要求的確認對合法的移動用戶106是很重要的。
為了確認移動用戶106的身份，事件管理伺服器102在步驟910中向由 移動用戶106在退出表800中指定的移動號碼發送確認消息。該確認過程與 圖6所示的步驟610到616相似。在步驟912，事件管理伺服器102確定退 出請求是否合法。如果退出請求不合法，則在步驟914中丟棄該退出請求並 最好通過由移動用戶106在退出表800中提供的電子郵箱地址通知移動用戶 106。由於退出處理中涉及的期限的原因，當移動用戶106初次提交退出表 800時在作為回應顯示的網頁上通知該移動用戶106所述狀態被認為是不現 實的。但是，如果退出請求合法，則該退出請求被記錄到事件管理伺服器102 的資料庫中。在最後的步驟916中，退出請求被立即激活，並通過由移動用 戶106在退出表800中提供的電子郵箱地址通知移動用戶106退出成功或服 務受到限制。由於退出處理中涉及的期限的原因，當移動用戶106初次提交
退出表800時在作為回應顯示的網頁上通知該移動用戶106所述狀態被認為 是不現實的。事件管理伺服器102也最好應該向相關的主網絡伺服器104發 送由移動用戶106授權的退出或服務限制的電子通知。
以上述方式，根據本發明的實施例敘述了用於向為接收網站更新已註冊 移動警示的移動用戶提供更新和事件通知的事件更新管理系統，用於處理有 關傳遞移動警示的當前的事件更新管理方法的上述缺點。雖然本文僅敘述了 本發明的一個實施例，但根據本文的揭示對於本技術領域的熟練人員顯而易 見的是，可以進行各種變化和修改而不背離本發明的範圍和精神。
權利要求
1.一種事件更新管理系統，其特徵在於，該系統包括用於接收由主網絡伺服器提供的警示註冊數據的數據模塊，當移動服務用戶通過主網絡伺服器提交相應於某個事件的警示註冊請求時產生該警示註冊數據；用於儲存該警示註冊數據的資料庫；和用於響應由操作主網絡伺服器的網站管理者提供的指令產生警示的警示模塊，所述指令與所述事件相關並且該警示模塊進一步用於相應於所述警示註冊數據向移動服務用戶發送警示。
2. 如權利要求1所述的事件更新管理系統，其特徵在於，該系統進一步包 括用於向移動服務用戶發送消息以確認由移動服務用戶通過主網絡服務 器提交的警示註冊請求的確認模塊，該消息為所述警示。
3. 如權利要求1所述的事件更新管理系統，其特徵在於，所述警示是短消 息服務(SMS)消息，多媒體消息服務(醒S)消息和無線應用協議(WAP) 推出消息中的一種消息。
4. 如權利要求1所述的事件更新管理系統，其特徵在於，用於主持網站的 主網絡伺服器用一組應用編程界面(API)功能和由事件更新管理系統提 供的原始碼之一預先編程。
5. 如權利要求4所述的事件更新管理系統，其特徵在於，所述一組應用編 程界面(API)功能定義由網站用於與事件更新管理系統連通的軟體互連 通功能。
6. 如權利要求l所述的事件更新管理系統，其特徵在於，其中主網絡服務 器預先下載軟體庫並將其與網站預先形成整體，該軟體庫由事件更新管 理系統提供。
7. 如權利要求1所述的事件更新管理系統，其特徵在於，所述軟體庫是所 述一組軟體應用編程界面(API)功能的軟體實施形式。
8. 如權利要求4所述的事件更新管理系統，其特徵在於，所述網站提供用 於警示註冊請求的警示註冊表。
9. 如權利要求8所述的事件更新管理系統，其特徵在於，所述警示註冊表包括用於獲取移動服務用戶的註冊細節和帳單細節中的至少一個細節的 用於從中產生警示註冊數據的輸入域。
10. 如權利要求1所述的事件更新管理系統，其特徵在於，警示模塊進一步 用於跟蹤向移動服務用戶發送的至少一個警示。
11. 如權利要求1所述的事件更新管理系統，其特徵在於，該系統進一步包 括多個帳戶，多個帳戶中的一個帳戶相應於操作主網絡伺服器的網站 管理者，用於提供與所述多個帳戶中的該一個帳戶相關的至少一個管理 功能，以及使網站管理者能夠指令警示模塊產生和向移動服務用戶發送
12. 如權利要求1所述的事件更新管理系統，其特徵在於，該系統進一步包 括..用於管理移動服務用戶和主網絡伺服器中的至少一方的帳單細節的帳單 模塊，該帳單細節相應於由警示模塊向移動服務用戶發送的警示。
13. 如權利要求l所述的事件更新管理系統，其特徵在於，警示註冊數據可 由移動服務用戶和主網絡伺服器中的一方訪問和編輯。
14. 一種事件更新管理方法，其特徵在於，該方法包括下列步驟由數據模塊接收由主網絡伺服器提供的警示註冊數據，當移動服務 用戶通過主網絡伺服器提交相應於某個事件的警示註冊請求時產生該警 示註冊數據；將該警示註冊數據記錄到資料庫中；響應從主網絡伺服器接收的指令產生警示，所述指令與所述事件相 關，和相應於所述警示註冊數據向移動服務用戶發送警示。
15. 如權利要求14所述的事件更新管理方法，其特徵在於，該方法進一步包 括提供用於向移動服務用戶發送消息以確認由移動服務用戶通過主網絡 伺服器提交的警示註冊請求的步驟，該消息為所述警示。
16. 如權利要求14所述的事件更新管理方法，其特徵在於，發送警示的步驟 包括如下步驟產生和發送作為警示的短消息服務(SMS)消息，多媒體消息服務 (麗S)消息和無線應用協議(WAP)推出消息中的一種消息。
17. 如權利要求14所述的事件更新管理方法，其特徵在於，該方法進一步包括由主網絡伺服器主持網站的步驟，該網站用一組應用編程界面(API)功能和由事件更新管理系統提供的原始碼之一預先編程。
18. 如權利要求17所述的事件更新管理方法，其特徵在於，由主網絡伺服器主持網站的的步驟包括如下步驟提供定義由網站用於與事件更新管理系統連通的軟體互連通功能的一組應用編程界面(API)功能。
19. 如權利要求17所述的事件更新管理方法，其特徵在於，由主網絡伺服器 主持網站的的步驟包括由事件更新管理系統提供軟體庫的步驟。
20. 如權利要求17所述的事件更新管理方法，其特徵在於，所述軟體庫是所 述一組軟體應用編程界面(API)功能的軟體實施形式。
21. 如權利要求17所述的事件更新管理方法，其特徵在於，由主網絡伺服器 主持網站的步驟包括由所述網站提供用於警示註冊請求的警示註冊表。
22. 如權利要求21所述的事件更新管理方法，其特徵在於，提供警示註冊表 的步驟包括如下步驟提供包括用於獲取移動服務用戶的註冊細節和帳單細節中的至少一 個細節的用於從中產生警示註冊數據的輸入域的警示註冊表。
23. 如權利要求14所述的事件更新管理方法，其特徵在於，發送警示的步驟 包括跟蹤向移動服務用戶發送的至少一個警示的步驟。
24. 如權利要求14所述的事件更新管理方法，其特徵在於，該方法進一步包 括如下步驟提供多個帳戶，多個帳戶中的一個帳戶相應於操作主網絡伺服器的 網站管理者，用於提供與所述多個帳戶中的該一個帳戶相關的至少一個 管理功能，以及使網站管理者能夠指令警示模塊產生和向移動服務用戶 發送警示。
25. 如權利要求14所述的事件更新管理方法，其特徵在於，該方法進一步包 括如下步驟管理移動服務用戶和主網絡伺服器中的至少一方的帳單細節，該帳 單細節相應於由警示模塊向移動服務用戶發送的警示。
26. 如權利要求14所述的事件更新管理方法，其特徵在於，該方法進一步包 括如下步驟允許由移動服務用戶和主網絡伺服器中的一方訪問警示註冊數據用 於編輯該警示註冊數據。
27. —種機器可讀媒介，其特徵在於，該機器可讀媒介具有存儲在其中的多 個編程指令，當執行所述編程指令時，該指令使機器由數據模塊接收由主網絡伺服器提供的警示註冊數據，當移動服務 用戶通過主網絡伺服器提交相應於某個事件的警示註冊請求時產生該警 示註冊數據；將該警示註冊數據記錄到資料庫中；響應從主網絡伺服器接收的指令產生警示，所述指令與所述事件相 關，和相應於所述警示註冊數據向移動服務用戶發送警示。
28. 如權利要求27所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器進一步提供用於向移動服務用戶發送消息以確認 由移動服務用戶通過主網絡伺服器提交的警示註冊請求的確認模塊，該 消息為所述警示。
29. 如權利要求27所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器產生和發送作為警示的短消息服務(SMS)消息， 多媒體消息服務(麗S)消息和無線應用協議(WAP)推出消息中的一種 消息。
30. 如權利要求27所述的機器可讀媒介，其特徵在於，其中當執行所述編程指令時，該指令使機器進一步要求由主網絡伺服器主持網站，該網站用 一組應用編程界面(API)功能和由事件更新管理系統提供的原始碼之 一預先編程。
31. 如權利要求30所述的機器可讀媒介，其特徵在於，其中當執行所述編程指令時，該指令使機器提供定義由網站用於與事件更新管理系統連通的 軟體互連通功能的一組應用編程界面(API)功能。
32. 如權利要求30所述的機器可讀媒介，其特徵在於，其中當執行所述編程指令時，該指令使機器通過事件更新管理系統提供軟體庫。
33. 如權利要求30所述的機器可讀媒介，其特徵在於，其中當執行所述編 程指令時，該指令使機器要求所述軟體庫成為所述一組軟體應用編程界 面(API)功能的軟體實施形式。
34. 如權利要求30所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器通過所述網站提供用於警示註冊請求的警示註冊表。
35. 如權利要求34所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器提供包括用於獲取移動服務用戶的註冊細節和帳 單細節中的至少一個細節的用於從中產生警示註冊數據的輸入域的警示 註冊表。
36. 如權利要求27所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器跟蹤向移動服務用戶發送的至少一個警示。
37. 如權利要求27所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器進一步提供多個帳戶，多個帳戶中的一個帳戶相 應於操作主網絡伺服器的網站管理者，用於提供與所述多個帳戶中的該 一個帳戶相關的至少一個管理功能，以及使網站管理者能夠指令警示模 塊產生和向移動服務用戶發送警示。
38. 如權利要求27所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器管理移動服務用戶和主網絡伺服器中的至少一方 的帳單細節，該帳單細節相應於由警示模塊向移動服務用戶發送的警不。
39. 如權利要求30所述的機器可讀媒介，其特徵在於，其中當執行所述編程 指令時，該指令使機器允許由移動服務用戶和主網絡伺服器中的一方訪 問警示註冊數據用於編輯該警示註冊數據。
全文摘要
網際網路的成長和擴展促進了各個公司以及客戶為了從廣告到電子商務到在線銷售到博客和新聞傳播的範圍的所有目的使用網際網路。網際網路是當前傳播信息的最快的方式。隨著無線時代的到來和行動裝置的擴展，網際網路被規劃更快地成長，尤其在移動無線應用領域。在不斷的發展中，終端用戶保持在網際網路上保持對新事件和更新的跟蹤成為重大的任務。但是允許移動服務用戶對其感興趣的網站的更新保持跟蹤的當前的事件更新管理系統有各種不易改變的缺點。本文揭示的本發明的實施例敘述了處理現存的事件更新管理系統面對的各種問題的系統和方法。
文檔編號G06F13/00GK101197727SQ20071016294
公開日2008年6月11日 申請日期2007年9月27日 優先權日2006年9月29日
發明者瓦倫·阿羅拉 申請人:無限智慧實驗室私人有限公司