專利名稱：用于路由環(huán)和垃圾郵件檢測的兩用計數(shù)器的制作方法
技術(shù)領(lǐng)域：
本發(fā)明總地涉及在網(wǎng)絡(luò)中進行可疑業(yè)務(wù)模式的檢測。更特別地，本發(fā)明涉及在基于例如源和目的地地址和/或時序的無線消息收發(fā)網(wǎng)絡(luò)中進行這樣的檢測。
背景技術(shù)：
垃圾郵件是困擾很多當(dāng)前通信網(wǎng)絡(luò)且特別是電信網(wǎng)絡(luò)的一個問題。如此處所使用的，“垃圾郵件”包括來自與無線設(shè)備(如移動電話)相關(guān)聯(lián)的一個或一小組始發(fā)號碼的大量消息收發(fā)，其經(jīng)常包含不想要的或不期望的內(nèi)容。垃圾郵件經(jīng)常采取從單個源地址到多個接收者的非常大數(shù)目的消息的形式，且可能由通過連接到計算機或無線調(diào)制解調(diào)器的手持電話機向無線網(wǎng)絡(luò)發(fā)送消息的應(yīng)用引起。此外，垃圾郵件可定義為從單個源發(fā)送到單個目的地地址的大數(shù)目的消息，而沒有相反方向上的對應(yīng)消息。雖然在傳統(tǒng)意義上未嚴(yán)格考慮垃圾郵件，但這可能構(gòu)成例如運營商可能希望被警告的消息收發(fā)網(wǎng)絡(luò)的類似拒絕服務(wù)的誤用，或其還可能指示不期望的“路由環(huán)”。
如此處所使用的，術(shù)語“路由環(huán)”指一個運營商、例如移動電話網(wǎng)絡(luò)提供商認出一號碼不在其系統(tǒng)中并將有關(guān)該號碼的呼叫或消息轉(zhuǎn)發(fā)到另一網(wǎng)絡(luò)所籍由的情況，或邏輯地橋接不同網(wǎng)絡(luò)的中介。但是，該中介(或另一網(wǎng)絡(luò))認出該號碼屬于始發(fā)的運營商的系統(tǒng)并將該消息發(fā)送回。此路由和重路由可無限繼續(xù)。
不期望的環(huán)路可經(jīng)常發(fā)生在號碼可攜性(NP)的背景中，籍此，消息交換環(huán)境中的兩個實體、例如一無線運營商和一運營商間的銷售商在給定的時刻具有對于特定電話號碼的不同路由信息。例如，運營商間的銷售商可能已通過實時移植(porting)/集中(pooling)數(shù)據(jù)饋送接收并處理了用于一電話號碼的移植事件的通知，但是無線運營商由于多種原因還未更新其本地路由信息以反映該通知。此沖突可導(dǎo)致上述消息或路由環(huán)。
在這種情況下，運營商將(不正確地)確定例如寄送到一電話號碼的短消息服務(wù)(SMS)消息在其網(wǎng)絡(luò)之外，且將相應(yīng)地將該消息傳送到運營商間的銷售商用于遞送。該銷售商(或中介)將(正確地)確定該電話號碼已移植到該運營商且因此應(yīng)由該運營商服務(wù)，且將相應(yīng)地將該消息返回給運營商用于遞送。然后該消息將無限來回反彈而不被發(fā)送到期望的接收者。
垃圾郵件和路由環(huán)都為運營商和客戶帶來了問題。期望的是，識別、在通信網(wǎng)絡(luò)內(nèi)減少并可能甚至消除垃圾郵件和路由環(huán)。這在處理如SMS消息的數(shù)據(jù)的無線通信網(wǎng)絡(luò)內(nèi)特別期望。

發(fā)明內(nèi)容
在一個示范性實施例中，本發(fā)明涉及一種用于在消息收發(fā)網(wǎng)絡(luò)內(nèi)對不期望情況進行檢測的方法。該方法包括接收消息并識別該消息的源。如果用于該源的數(shù)據(jù)庫中的條目還未被創(chuàng)建，則在用于該源的數(shù)據(jù)庫中創(chuàng)建條目。用于該源的源計數(shù)器設(shè)置為1且為該源創(chuàng)建時間戳。如果用于該源的數(shù)據(jù)庫中的條目以前已被創(chuàng)建，則源計數(shù)器增加1且更新時間戳。然后在一預(yù)定時間段內(nèi)，源計數(shù)器與源閾值進行比較，且如果源計數(shù)器超過源閾值，則觸發(fā)源告警。


圖1所示為根據(jù)本發(fā)明一示范性實施例的示范性消息計數(shù)器增加過程的流程圖；圖2所示為在網(wǎng)絡(luò)內(nèi)接收消息的時間線；圖3所示為根據(jù)本發(fā)明一示范性實施例使用滑動窗進行“垃圾收集”的流程圖；
圖4所示為路由環(huán)情況的圖；以及圖5所示為根據(jù)本發(fā)明一實施例的示范性跟蹤方法的流程圖。
具體實施例方式
在一優(yōu)選實施例中，本發(fā)明監(jiān)視移動通信用戶之間正在進行的消息業(yè)務(wù)以致力于識別可能構(gòu)成垃圾郵件的模式，如上面所定義的，或指示在一個網(wǎng)絡(luò)的兩部分間或在網(wǎng)絡(luò)間來回?zé)o止盡地發(fā)送消息的路由環(huán)。本領(lǐng)域技術(shù)人員會認識到本發(fā)明不應(yīng)僅限于移動通信用戶之間的業(yè)務(wù)，還可應(yīng)用于可能發(fā)生垃圾郵件或路由環(huán)的任何網(wǎng)絡(luò)。通過根據(jù)與本發(fā)明的原理一致的原理來監(jiān)視網(wǎng)絡(luò)，可以更快地識別、并因此更快地補救這種不期望情況的存在。
在其最基本的水平，本發(fā)明致力于以對于固定尺寸的時間窗合適的方式跟蹤兩個網(wǎng)絡(luò)間或單個網(wǎng)絡(luò)內(nèi)流動的所有消息的源和目的號碼(例如，電話號碼或地址)。在一優(yōu)選實施例中，數(shù)據(jù)庫或其他存儲庫存儲由特定源地址發(fā)送的消息的號碼和表示給定實例的創(chuàng)建時間的時間戳。當(dāng)消息通過該系統(tǒng)時，在數(shù)據(jù)庫中創(chuàng)建適當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)(如果對特殊源地址還不存在)且計數(shù)器增加，該計數(shù)器指示從該特定源地址發(fā)送的消息的數(shù)目。
該過程在圖1中示出。最初，在步驟100創(chuàng)建新消息(例如，來自移動電話的SMS)并從位置A發(fā)送到位置B。在步驟110，該系統(tǒng)檢查用于始發(fā)方A的數(shù)據(jù)庫中是否存在條目。如果條目不存在，則在步驟120創(chuàng)建新條目同時計數(shù)器置1，并創(chuàng)建時間戳。如果條目已存在，則在步驟130，計數(shù)器增加并更新時間戳。一旦計數(shù)器和時間戳被更新，就在步驟140執(zhí)行相對于閾值的檢查。如果計數(shù)器值(依賴于設(shè)置)達到或超過閾值，則在步驟150發(fā)出告警。但是，如果未越過閾值，則系統(tǒng)等待網(wǎng)絡(luò)內(nèi)或網(wǎng)絡(luò)間待發(fā)送的下一消息。
利用計數(shù)器和時間戳信息，根據(jù)本發(fā)明，通過使用以規(guī)則的間隔去除比固定窗尺寸舊的所有條目的垃圾收集方法，可以實施有效的固定尺寸的“跳窗(jumping window)”。例如，如果經(jīng)過了30分鐘且還未到閾值，則丟棄在這30分鐘跳窗期間收集的數(shù)據(jù)并重新啟動該過程。本方案具有非常有效的優(yōu)點，因為垃圾收集器例程每個時間段僅需比較一個整數(shù)值(例如，消息數(shù)目)以確定是否去除消息歷史數(shù)據(jù)。該方法的一個缺點在于固定的跳窗的性質(zhì)。消息風(fēng)暴(flurry)在整體上從單個源地址發(fā)送，可能超過所識別的垃圾郵件閾值，但是相對于垃圾收集短暫地發(fā)送，該風(fēng)暴的兩部分每個都保持低于閾值或檢測水平。
此情況在圖2中示出，其中圖示了在約7分鐘時段內(nèi)發(fā)送15個消息。后來，又有30個消息在半小時的最后15分鐘中發(fā)送。如果閾值設(shè)置為半小時內(nèi)50個消息，則典型的系統(tǒng)不會發(fā)出告警，因為垃圾收集會被設(shè)置為每半小時發(fā)生一次，因此在該時段期間擦除所有計數(shù)器信息。在下一半小時的開始，圖示出另外30個消息在第一個15分鐘內(nèi)被發(fā)送。因為垃圾收集發(fā)生在30分鐘標(biāo)記處，所以系統(tǒng)不將此檢測為垃圾郵件實例，即使如圖所示在30分鐘時段中發(fā)送了60個消息。實質(zhì)上，固定跳窗分裂成兩半，由此使該事件不被檢測到，否則會被檢測為垃圾郵件實例。表1示出利用固定窗的垃圾收集。
表1


如表1所示，當(dāng)窗是固定的時，發(fā)生消息累積的不期望實例或垃圾郵件，因為消息的到達跨越兩個窗。為確保發(fā)出告警且檢測到這樣的垃圾郵件實例，優(yōu)選地實施滑動窗。此滑動窗利用更精細的數(shù)據(jù)結(jié)構(gòu)實施，在該數(shù)據(jù)結(jié)構(gòu)中，時間戳被時間戳的排序數(shù)組(或類似的數(shù)據(jù)結(jié)構(gòu))代替，每個時間戳相對于每一計數(shù)器增量。垃圾收集器從該數(shù)組去除比固定窗尺寸舊的所有條目，并相應(yīng)地遞減計數(shù)器。以此方式，只有當(dāng)計數(shù)器到達0時，才從哈希表去除完整的數(shù)據(jù)結(jié)構(gòu)。
因此，細化的方案可實施“滾動”窗。這需要更精細的數(shù)據(jù)結(jié)構(gòu)，其中時間戳和計數(shù)器被時間戳的容器一例如先進先出(FIFO)隊列或其他類似結(jié)構(gòu)代替。垃圾收集器從該容器去除比固定窗尺寸舊的所有條目。只有當(dāng)最后的元素從該容器去除時，該容器本身才從哈希表去除。這一使用滑動或滾動窗的增強的垃圾郵件檢測示出在表2。
表2


利用此滑動方法，由于數(shù)組搜索和相關(guān)計數(shù)器遞減相對于簡單整數(shù)比較的相對復(fù)雜性以及定期的垃圾收集，會遇到輕微的性能損失。還將發(fā)生存儲器空間的顯著增大。表2所述垃圾收集過程示出在圖3。如圖所示，在步驟300獲得下一隊列。該“隊列”，如此處所使用的，表示包含或容納動態(tài)改變的單獨條目組的數(shù)據(jù)結(jié)構(gòu)，每一單獨條目表示被觀測為源自特定源(A，B，...)的那些(SMS)消息。垃圾收集例程，其示范性實施例示出在圖3，在它完成工作時將重復(fù)通過隊列中的條目以訪問所有計數(shù)器/時間戳。接著，在步驟310，還獲得有關(guān)該隊列的時間戳。然后在步驟320檢查時間戳以查看它是落在預(yù)定窗尺寸內(nèi)部還是外部。如果時間戳落在該窗尺寸外部，則在步驟330去除時間戳。否則，過程返回到步驟300以得到下一隊列。但是因為時間戳數(shù)組總是排序的，可應(yīng)用非常有效的數(shù)組操作方法。為了獲得該結(jié)果，必須考慮存儲器空間的顯著增大。
在支持號碼可攜性的移動電話網(wǎng)絡(luò)環(huán)境中，一個運營商的用戶能夠帶走他的/她的當(dāng)前電話號碼并在另一運營商的網(wǎng)絡(luò)中使用它，以避免為了改變運營商而改變電話號碼。以前，運營商接收電話號碼的專用塊，使得他們的系統(tǒng)容易檢測什么號碼是他們的網(wǎng)絡(luò)的一部分以及什么號碼在他們的網(wǎng)絡(luò)之外。但是，現(xiàn)在用戶能將他們的號碼從一個運營商帶到下一個運營商，于是在用戶端簡化了從一個運營商到另一個運營商的改變。但是，如上所述，該號碼可攜性會為運營商帶來很多問題。
在號碼可攜性的情況下，用戶Y(參考圖4)將它的號碼從其始發(fā)運營商—運營商2，帶到新的運營商—運營商1。如圖4所示，當(dāng)也利用運營商1的用戶X發(fā)送消息到新增加到運營商1的用戶Y，由于多種原因，運營商1(不正確地)認為用戶Y在它的網(wǎng)絡(luò)之外。運營商1然后發(fā)送消息到中介I用于轉(zhuǎn)換該消息以確保在運營商間適當(dāng)傳輸。中介I隨后(正確地)認為用戶Y實際上是運營商1的網(wǎng)絡(luò)的一部分并將該消息發(fā)送回運營商1以發(fā)送到用戶Y。由于運營商和中介所具有的關(guān)于用戶Y的信息之間的差異，此路由和重路由將無限繼續(xù)。該差異導(dǎo)致路由環(huán)。如果中介I和運營商1都沒有機制以防止將消息發(fā)送回始發(fā)網(wǎng)絡(luò)，該消息將無限地留在該路由環(huán)中，或直到某些定時器到期，且實際將永不會到達它的目的地。
為了在單個源和目的地之間檢測路由環(huán)或過多的消息收發(fā)，需要跟蹤附加的信息。代替增量每個源地址的單個計數(shù)器，還優(yōu)選地配置用于每一源地址的數(shù)據(jù)結(jié)構(gòu)以包含用于每一目的地地址的單獨的計數(shù)器。為此，以前限定的數(shù)據(jù)結(jié)構(gòu)可修改為包含哈希表，或為了保持相同類型數(shù)據(jù)結(jié)構(gòu)而類似地索引為“容器”，由目的地地址索引。這允許該系統(tǒng)不僅僅跟蹤來自該源地址的消息的總量。修改的跟蹤方法在圖5中示出。
如圖5所示，使用步驟200所示的電話號碼，新消息從位置X發(fā)送到位置Y。如利用圖2的方法，系統(tǒng)檢查在步驟210是否已為X創(chuàng)建了條目。如果沒有，則在步驟220用索引X創(chuàng)建一新條目且計數(shù)器置1。因為這是用于X的新條目，可以假設(shè)沒有為Y創(chuàng)建子條目，所以在步驟240，用索引Y創(chuàng)建一新的子條目。但是如果存在條目，而不是在此時增加計數(shù)器，則在步驟230，系統(tǒng)檢查在X的主條目下是否存在用于Y的子條目。如果用于Y的子條目不存在，則在步驟240創(chuàng)建用于Y的新的子條目且計數(shù)器置1。如果用于Y的子條目存在，則在步驟250計數(shù)器增加且更新時間戳。在這一點，在步驟260計數(shù)器與閾值相比較，如果計數(shù)器大于該閾值，則在步驟270發(fā)出告警。如果不到該閾值，則系統(tǒng)等待下一消息，而不發(fā)出告警。
通過增加此附加數(shù)據(jù)，本發(fā)明的監(jiān)視機制可用幾種方式改變。第一，可為每個窗的消息的總數(shù)目以及每個目的地地址和窗的消息的數(shù)目配置不同閾值。第二，基于消息總數(shù)目的告警可包含不同目的地地址和相關(guān)消息計數(shù)的詳細細目。
如果引入此垃圾郵件/路由環(huán)檢測方法的網(wǎng)絡(luò)是分布式性質(zhì)的，可能沒有所有消息必須通過的單個點。在這種情況下，至少有2種方案。第一，遍布網(wǎng)絡(luò)的單獨硬件上的過程可使用共享設(shè)備，如固態(tài)盤，作為用于所有內(nèi)存儲器數(shù)據(jù)結(jié)構(gòu)的存儲介質(zhì)。盡管這確保經(jīng)過網(wǎng)絡(luò)的消息業(yè)務(wù)的精確計數(shù)，但與排他地在本地存儲器內(nèi)工作的過程相比，它可能顯著使性能劣化。如果業(yè)務(wù)分布在地理上分離的網(wǎng)絡(luò)中，則此方法也可能不實用。
在針對分布式網(wǎng)絡(luò)問題的第二方案中，相對于經(jīng)過網(wǎng)絡(luò)的業(yè)務(wù)總量限定的閾值可除以運用本發(fā)明的位置數(shù)目。例如，如果每小時100個消息被限定為每個源地址的閾值，則可配置具有每小時50個消息的閾值的兩個過程。盡管如果業(yè)務(wù)不是基于源地址負載平衡的，但此方法可導(dǎo)致若干錯誤告警，實踐表明對于合理的高閾值，通常的輪替(round-robin)負載平衡方法足以確保共享存儲器模型的良好近似。
因為使用上述監(jiān)視，合法使用消息收發(fā)網(wǎng)絡(luò)將導(dǎo)致錯誤告警，這實際上是不可避免的，所以系統(tǒng)可配置成向一直保持在存儲器中的“白名單”增加某些源或目的地地址或它們的組合。在白名單中具有匹配條目的消息即使它們超過配置的閾值也不產(chǎn)生告警。類似地，已知用于垃圾郵件消息的源地址可被放置在“黑名單”中，其用于丟棄來自這樣的地址的任何消息而不管閾值如何。
本發(fā)明前面公開的優(yōu)選實施例為圖示和說明的用途而提出。并不意圖窮舉或?qū)⒈景l(fā)明限制為所公開的精確形式。顯然對本領(lǐng)域技術(shù)人員按照上述公開可對此處所述實施例進行許多變更和修改。本發(fā)明的范圍僅由所附權(quán)利要求及其等價設(shè)置限定。
此外，在說明本發(fā)明的代表實施例時，本說明書將本發(fā)明的方法和/或過程表示為步驟的特定序列。但是，就該方法或過程不依賴于此處闡明的步驟的特定順序的程度而言，該方法或過程不應(yīng)局限于所述步驟的特定序列。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解，步驟的其他序列是可能的。所以，本說明書中闡明的步驟的特定順序不應(yīng)解釋為對權(quán)利要求的限制。此外，指向本發(fā)明的方法和/或過程的權(quán)利要求不應(yīng)局限于按所寫順序的步驟的性能，且本領(lǐng)域技術(shù)人員易于認識到，該序列可變化且仍保持在本發(fā)明的精神和范圍內(nèi)。
權(quán)利要求
1.一種用于在消息收發(fā)網(wǎng)絡(luò)內(nèi)對不期望情況進行檢測的方法，包括接收消息；識別所述消息源；如果用于所述源的數(shù)據(jù)庫中的條目還未被創(chuàng)建，則在用于所述源的數(shù)據(jù)庫中創(chuàng)建條目，將用于所述源的源計數(shù)器設(shè)置為1，并且創(chuàng)建用于所述源的時間戳；如果以前已在用于所述源的數(shù)據(jù)庫中創(chuàng)建條目，則所述源計數(shù)器增加1并且更新時間戳；將所述源計數(shù)器與源閾值進行比較；以及當(dāng)在預(yù)定量的時間期間所述源計數(shù)器超過所述源閾值時，觸發(fā)指示不期望情況的告警。
2.權(quán)利要求1的方法，進一步包括識別用于所述消息的目的地；如果用于所述目的地的數(shù)據(jù)庫中的條目還未被創(chuàng)建，則在用于所述目的地且相關(guān)于所述源的數(shù)據(jù)庫中創(chuàng)建子條目，并且將目的地計數(shù)器設(shè)置為1；如果以前已在用于所述目的地的數(shù)據(jù)庫中創(chuàng)建條目，則所述目的地計數(shù)器增加1；將所述目的地計數(shù)器與目的地閾值進行比較；以及當(dāng)在另一時間段期間所述目的地計數(shù)器超過所述目的地閾值時，則觸發(fā)目的地告警。
3.權(quán)利要求2的方法，其中所述源閾值和所述目的地閾值包括不同的值。
4.權(quán)利要求1的方法，其中所述消息是短消息系統(tǒng)消息。
5.權(quán)利要求1的方法，其中所述消息收發(fā)網(wǎng)絡(luò)允許號碼移植。
6.權(quán)利要求1的方法，其中所述消息收發(fā)網(wǎng)絡(luò)包括無線網(wǎng)絡(luò)。
7.權(quán)利要求1的方法，其中所述源包括網(wǎng)絡(luò)用戶，且所述目的地包括中間銷售商。
8.一種用于在消息收發(fā)網(wǎng)絡(luò)中對垃圾郵件事件進行檢測的方法，包括在所述消息收發(fā)網(wǎng)絡(luò)中對消息業(yè)務(wù)進行監(jiān)視；對于與消息相關(guān)聯(lián)的每一新的源地址，在數(shù)據(jù)庫中創(chuàng)建條目并將用于該源地址的源地址計數(shù)器設(shè)置為預(yù)定數(shù)并存儲對應(yīng)于接收所述消息的時間的時間戳，且對于重復(fù)的源地址，增加用于所述重復(fù)的源地址的所述源計數(shù)器并更新所述時間戳；將用于給定源地址的所述源計數(shù)器與源閾值進行比較；以及當(dāng)在預(yù)定量的時間期間所述源計數(shù)器超過所述源閾值時，觸發(fā)指示垃圾郵件事件的告警。
9.權(quán)利要求8的方法，其中所述消息業(yè)務(wù)包括短消息系統(tǒng)消息。
10.權(quán)利要求8的方法，其中所述消息收發(fā)網(wǎng)絡(luò)包括無線網(wǎng)絡(luò)。
11.權(quán)利要求8的方法，其中所述方法由邏輯地位于兩個電信服務(wù)提供商之間的中介執(zhí)行。
12.一種在電信網(wǎng)絡(luò)中對路由環(huán)進行檢測的方法，包括對通過互連至少兩個電信服務(wù)提供商的中介的消息業(yè)務(wù)進行監(jiān)視；當(dāng)消息業(yè)務(wù)通過所述中介時，在數(shù)據(jù)庫中創(chuàng)建條目，將源地址計數(shù)器設(shè)置為預(yù)定數(shù)并存儲對應(yīng)于第一消息通過所述中介的時間的時間戳，并且增加所述源地址計數(shù)器并當(dāng)所述第一消息每次再經(jīng)過所述中介時更新所述時間戳；當(dāng)消息業(yè)務(wù)通過所述中介時，在數(shù)據(jù)庫中創(chuàng)建條目，將目的地地址計數(shù)器設(shè)置為預(yù)定數(shù)并存儲對應(yīng)于第二消息通過所述中介的時間的時間戳，并且增加所述目的地地址計數(shù)器并當(dāng)所述第二消息每次經(jīng)過所述中介時更新所述時間戳；針對給定的源地址和給定的目的地地址分別將所述源地址計數(shù)器和目的地地址計數(shù)器與源地址閾值和目的地地址閾值進行比較；以及，在預(yù)定量的時間期間，當(dāng)所述源地址計數(shù)器和目的地地址計數(shù)器分別超過所述源地址閾值和目的地地址閾值時，觸發(fā)指示路由環(huán)的告警。
13.權(quán)利要求12的方法，其中所述源地址閾值和所述目的地地址閾值包括不同的值。
14.權(quán)利要求12的方法，其中所述消息業(yè)務(wù)包括短消息系統(tǒng)(SMS)消息。
15.權(quán)利要求12的方法，其中所述方法檢測由號碼移植性引起的路由環(huán)。
16.權(quán)利要求12的方法，其中所述電信網(wǎng)絡(luò)包括無線網(wǎng)絡(luò)。
全文摘要
一種用于在消息收發(fā)網(wǎng)絡(luò)內(nèi)對不期望情況進行檢測的方法。接收消息并識別該消息的源。如果用于該源的數(shù)據(jù)庫中的條目還未被創(chuàng)建，則創(chuàng)建條目。用于該源的源計數(shù)器然后設(shè)置為1且為該源創(chuàng)建時間戳。如果用于該源的數(shù)據(jù)庫中的條目以前已被創(chuàng)建，則該源計數(shù)器增加1且更新該時間戳。然后該源計數(shù)器與源閾值進行比較，且在預(yù)定量的時間期間如果該源計數(shù)器超過該源閾值，則觸發(fā)源告警?？蓪嵤┫鄬τ谠擃A(yù)定量的時間的滑動以考慮可由所設(shè)置的時間段遇到或分裂的總計數(shù)。本發(fā)明對檢測“垃圾郵件”事件和不期望的路由環(huán)特別有用。
文檔編號G06F15/16GK101048769SQ200580005372
公開日2007年10月3日 申請日期2005年2月15日 優(yōu)先權(quán)日2004年2月20日
發(fā)明者蒂洛·魯舍, 德里克·亨·基特·塔姆, 小羅伯特·C·洛弗爾 申請人:移動365