專利名稱：阻塞不需要的消息的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種用于阻塞不需要的消息的方法和系統(tǒng)。
這種方法或系統(tǒng)還可以應用在移動無線系統(tǒng)中，諸如在GSM(全球移動通信系統(tǒng))系統(tǒng)中。
除了語音電話之外，移動無線系統(tǒng)GSM也提供了可能性來發(fā)送或接收直至160個字符長度的短文本消息。該業(yè)務稱為SMS(短消息業(yè)務)，并在第三代合伙項目(3GPP)的技術規(guī)程TS 23.040版本5.4.0，發(fā)布(Release)5，“群終端技術規(guī)程；短消息業(yè)務(SMS)的技術實現(xiàn)”中得到了闡述。
對于諸如UMTS(通用移動電信系統(tǒng))的下一代(2.5G和3G)的移動無線系統(tǒng)，當今標準化了移動消息業(yè)務的具有多媒體能力的方案，所謂的MMS(多媒體報文傳送業(yè)務)業(yè)務。在第三代合伙項目(3GPP)的技術規(guī)程TS 22.140版本5.2.0，發(fā)布5，“群業(yè)務和系統(tǒng)特征技術規(guī)程；業(yè)務特征；階段1；多媒體報文傳送業(yè)務(MMS)”，和TS 23.140版本5.3.0，發(fā)布5，“群終端；多媒體報文傳送業(yè)務(MMS)，功能說明；階段2”中，詳細說明了該MMS業(yè)務。以下為了更好地區(qū)別于SMS的文本消息，將具有多媒體內(nèi)容的消息稱為MM。與SMS相反，在MMS中取消了純粹文本內(nèi)容的限制。在MMS中可以按照個人的喜好將文本格式化，以及將音頻內(nèi)容和視頻內(nèi)容納入消息中。一個MM因此可以由不同文件類型(例如音頻或靜止圖像)的，或文件格式(在靜止圖像中例如所謂的“圖形交換格式”GIP或“聯(lián)合攝影專家組”標準JPEG)的多個MM元素所組成。
附

圖1展示了已知的MMS網(wǎng)絡體系結(jié)構(gòu)。以下總是將所謂的“MMS用戶代理”稱為MMS UA。MMS UA可以涉及一種軟件程序，該軟件程序例如位于移動無線設備上，或位于連接到移動無線設備上的像膝上型計算機或類似物那樣的設備上，該移動無線設備或設備實現(xiàn)了MMS。附圖1中區(qū)別了用戶A和用戶B。相應地存在著MMS UA A和MMS UA B。在另外的網(wǎng)元中以下相應地通過附加字母“A”和“B”來區(qū)別元件A和B。此外，附圖1展示了兩個網(wǎng)元MMS R/S A或MMS R/S B，這些網(wǎng)元是所謂的“MMS中繼/服務器”。MMS R/S A或MMS R/S B涉及以下的網(wǎng)元，這些網(wǎng)元在MMS業(yè)務提供商SP的主管領域MMSE(多媒體報文傳送業(yè)務環(huán)境)中，將MMS功能性提供給各自的MMS UA使用。附圖1相應地展示了MMSE SPA或MMSE SPB。
MMS的一種獨特的特征是，在傳送MM時區(qū)別所謂的“推模式”和所謂的“拉模式”，在推模式中將到達的MM立即傳送給接收者，而在拉模式中首先將新到達的MM通知接收者，并且接收者隨即自己可以決策，他是否或何時將該MM下載到他的終端設備上。附圖2和3展示了在傳送MM時的拉模式和推模式之間的區(qū)別。在根據(jù)附圖2的拉模式中，關于存在著一個消息的通知首先從MMS R/S到達MMS UA上，反之在根據(jù)附圖3的推模式中立即傳輸消息。
附圖4展示了具有規(guī)定接口的已知的網(wǎng)絡體系結(jié)構(gòu)，這些接口用于將其它的網(wǎng)元連接到MMS R/S上。除了MMS UA和MMS R/S通過其彼此相連接的接口MM1之外，可以通過接口MM3將任意外部的計算機，即諸如E-Mail服務器、傳真服務器等等的服務器連接到MMS R/S上。用接口MM4來實現(xiàn)外界MMS業(yè)務提供商的連接。接口MM5將MMS R/S與網(wǎng)絡運營商的歸屬位置寄存器HLR相連接，在該歸屬位置寄存器HLR中存儲了每個客戶獨有的用戶數(shù)據(jù)。在此，HRL位于網(wǎng)絡運營商的主管領域中。接口MM6實現(xiàn)了一個或多個MMS用戶數(shù)據(jù)庫的連接。通過接口MM7實現(xiàn)了其它計算機的連接，多值業(yè)務提供商的這些計算機將多值業(yè)務提供給MMS用戶來使用。
MMS可以選擇性地獨有化。在獨有的用戶設置的基礎上，MMS R/S可以讓某些MM得到特別的處理。因此例如可以由MMS R/S直接地，即沒有MMS UA的通知地，將屬于某個MM范疇的MM，例如專用的MM，轉(zhuǎn)送到事先由用戶給出的E-Mail地址上。此外，也可以由MMS R/S自動清除在標題中載有某些關鍵字的MM，或?qū)碜阅硞€發(fā)送者的MM直接地，即以推模式，傳送到MMS UA上，而所有另外的MM的通常所希望的傳送機制是拉模式。除此之外，其它獨有的規(guī)則是可以設想的。
但是所有的規(guī)則都有以下的缺點，即MMS用戶已經(jīng)在MM的到達之前，必須在他的MMS業(yè)務提供商的MMSE中已規(guī)定了它們。這可以要么在合同簽訂時，要么在合同執(zhí)行期間，例如用電話，或甚至借助(移動的)“網(wǎng)絡瀏覽”來實現(xiàn)。通常在MMS用戶數(shù)據(jù)庫中來管理用于MMS的專用化的獨有的規(guī)則，MMS R/S通過接口MM6可以訪問該MMS用戶數(shù)據(jù)庫。
發(fā)送者在MMS中也具有匿名發(fā)送他的MM的可能性。與另外的業(yè)務的比較卻表明，個別地可能導致以不需要的廣告、侮辱和類似形式的濫用，在這些另外的業(yè)務中發(fā)送者對接收者可以保持匿名，例如像傳統(tǒng)的信件郵政那樣。在MMS中也不能排除具有匿名MM的濫用。
接收者雖然可以在他的MMS UA上放置過濾器，以便剔除從不需要的發(fā)送者送達他的MM。不過這具有以下的缺點，在通過昂貴的空中接口傳輸MM或通知之后才實現(xiàn)過濾器功能。按照與他的業(yè)務提供商的結(jié)算模式，在此時刻已將不需要地傳輸?shù)臄?shù)據(jù)給接收者記了賬。此外還存在著以下的缺點，即在匿名發(fā)送MM時缺少過濾準則。例如當發(fā)送者的身份對于MMS UA是未知時，或者當所給出的化名僅臨時地，即僅對于一個單個的MM可以分配給真正的發(fā)送者時，應該按照什么來過濾是未知的。
因此本發(fā)明所基于的任務在于，提供一種用于阻塞不需要的消息的方法和系統(tǒng)，該方法和系統(tǒng)有效地拒絕不需要的消息，并且此時將要通過昂貴的空中接口傳輸?shù)南⒌臄?shù)量保持最小。
根據(jù)本發(fā)明通過具有權(quán)利要求1所述特征的用于阻塞不需要的消息的方法，和通過具有權(quán)利要求14所述特征的用于阻塞不需要的消息的系統(tǒng)來解決該任務。此外，具有權(quán)利要求27所述特征的終端設備和具有權(quán)利要求28所述特征的發(fā)送裝置/接收裝置是該任務的一種解決方案。從屬權(quán)利要求分別規(guī)定了本發(fā)明的優(yōu)選和有利的實施形式。
用于阻塞不需要的消息的本發(fā)明方法具有以下的方法步驟-傳輸發(fā)送者的消息到發(fā)送機上。
-從發(fā)送機傳輸消息到業(yè)務提供商上，和-從業(yè)務提供商傳輸消息到接收者上，其中，由業(yè)務提供商來服務接收者。只有在發(fā)送者不在排除清單中的情況下，才實現(xiàn)將業(yè)務提供商的消息傳輸?shù)浇邮照呱?。發(fā)送者可以例如涉及一個MMS UA，而在發(fā)送機中可以涉及一個MMS R/S。優(yōu)選在業(yè)務提供商處來注冊接收者，即接收者與業(yè)務提供商有合同關系。通過該方法，未來通過空中接口向接收者僅傳輸不在排除清單中的發(fā)送者的消息。
優(yōu)選在業(yè)務提供商處來管理排除清單。這具有以下的優(yōu)點，即業(yè)務提供商始終知道，從給某些接收者或接收者群的傳輸中排除哪些發(fā)送者。在本發(fā)明的優(yōu)選的實施形式中，排除清單是接收者的專用的，即獨有地匯總的排除清單。在此情況下，業(yè)務提供商對于每個接收者管理著一個專用的排除清單，在進入的消息通過空中接口傳輸?shù)浇邮照呱现白稍冊撆懦鍐巍?br> 在本發(fā)明的一個其它的實施形式中，排除清單是一個對于所有的接收者和/或接收者群來考慮的通用的排除清單?？梢栽O想在業(yè)務提供商處來管理通用的排除清單。將以下的發(fā)送者錄入到該排除清單中，這些發(fā)送者的消息根本不應通過空中接口發(fā)送到任何接收者和/或接收者群上。在此，業(yè)務提供商可以按照自己的準則來決定，哪些人員或接收者可將發(fā)送者放置到相應的通用的排除清單中，或接收者群如何來劃分。專用的與通用的排除清單的組合也是可能的。
在本發(fā)明的一個改進方案中，如果接收者想讓一個發(fā)送者放置到排除清單上，他則通知業(yè)務提供商?？梢栽O想，接收者自己匯總他的排除清單。接收者為此通知業(yè)務提供商，他想讓哪個發(fā)送者放置到排除清單上。但是替代地也可以設想，只有業(yè)務提供商自己可以讓發(fā)送者放置到排除清單中。
在本發(fā)明的一個改進方案中，接收者匿名地接收消息，并且如果接收者想讓消息的發(fā)送者放置到排除清單上，他則通知業(yè)務提供商。在這種情況下發(fā)送者對于接收者是未知的。如果接收者仍然不想再從該發(fā)送者接收消息，例如因為涉及的是廣告消息，他則可將這一點通知業(yè)務提供商。發(fā)送者的名字對于業(yè)務提供商是已知的。但是他將該名字只是不轉(zhuǎn)送給接收者。對于業(yè)務提供商因此有可能將發(fā)送者的名字放置到排除清單上。
在本發(fā)明的一個改進方案中，接收者接收具有化名的消息，并且如果接收者想讓消息的發(fā)送者放置到排除清單上，他則通知業(yè)務提供商。類似于像在接收具有匿名發(fā)送者的消息時那樣，接收者在接收具有化名的消息時不知道誰是真正的發(fā)送者。如果他未來仍然不想從該發(fā)送者再收到消息，他則可將這又通知業(yè)務提供商，真正的發(fā)送者對于該業(yè)務提供商是已知的。因而業(yè)務提供商可以將該發(fā)送者放置到排除清單上，使得接收者未來不再從該發(fā)送者接收消息。因此又減輕了通向接收者的空中接口的負擔。
在一個優(yōu)選的實施形式中，將給業(yè)務提供商的通知構(gòu)成為獨立的短消息，即構(gòu)成為所謂的“摘要消息”。進一步優(yōu)選以信息元的形式將給業(yè)務提供商的通知集成在摘要消息中。
在一個其它的實施形式中，給業(yè)務提供商的通知被包含在MM中，尤其在該MM的有用數(shù)據(jù)中。
給業(yè)務提供商的通知也可以含有過濾器功能的其它信息，尤其是排除清單類型的和/或時間限制的其它信息。
在一個優(yōu)選的實施形式中，給業(yè)務提供商的通知含有識別信號，業(yè)務提供商可以從該識別信號中確定發(fā)送者的身份。如果接收者僅接收了匿名的消息，或具有化名的消息，則提出了以下的問題，接收者如何可以通知業(yè)務提供商，應將哪個發(fā)送者放置到排除清單上。在這種情況下，接收者用他的通知給業(yè)務提供商發(fā)送識別信號，通過該識別信號可以明確識別消息或發(fā)送者。在此，優(yōu)選將消息標記和/或化名用作識別信號。消息標記可以涉及對來自通知中的消息存儲位置的參考，即所謂的URI(通用資源標識符)，或者涉及來自MM的傳送中的消息ID，即所謂的消息ID。
也通過用于阻塞不需要的消息的系統(tǒng)來解決開始時提出的任務。該系統(tǒng)具有一個適用于傳輸發(fā)送者消息的發(fā)送機，一個適用于接收發(fā)送機的消息的業(yè)務提供商，和一個由業(yè)務提供商服務的接收者，其中，接收者適用于接收業(yè)務提供商的消息。在此，業(yè)務提供商適用于，只有發(fā)送者不在排除清單中的情況下，才傳輸消息到接收者上。
本發(fā)明還涉及用于本發(fā)明方法和/或用于本發(fā)明系統(tǒng)中的終端設備，尤其是移動無線終端設備。本發(fā)明也還涉及用于本發(fā)明方法中的，和/或用于本發(fā)明系統(tǒng)中的發(fā)送裝置/接收裝置，尤其是移動無線基站。
在本發(fā)明中有利的是，已經(jīng)在通知之前，或在傳送之前可以如下來分析研究到達的MMMM的發(fā)送者是否在接收者的專用的和/或公共的排除清單上。因此降低了(尤其通過空中接口的有限資源的)數(shù)據(jù)通信，這導致較低的成本。
此外有利的是，即使在匿名發(fā)送的MM的情況下，過濾器功能也在起作用，因為與接收者相反，發(fā)送者的身份對于MMS業(yè)務提供商是已知的。
最后有利的是，接收者在收到通知之后，或在MM的傳送之后隨時可以動態(tài)地將他的排除清單擴充新的錄入項。
以下通過參照附圖借助實施例來詳述本發(fā)明。在那里示出的特征和甚至上面已經(jīng)闡述的特征，不僅以所述的組合，而且甚至單個地，或以另外的組合都是本發(fā)明的發(fā)明點。
圖1展示了MMS網(wǎng)絡體系結(jié)構(gòu)；圖2展示了拉模式的示意圖；圖3展示了推模式的示意圖；圖4展示了MMS R/S和它的接口的示意圖；圖5展示了MM從MMS UA A發(fā)送到MMS UA B上的示意圖；以及圖6展示了匿名發(fā)送MM的示意圖。
在說明書的引言中已經(jīng)闡述了附圖1至4，使得可以在此舍棄重新的闡述。
附圖5展示了通過網(wǎng)元MMS R/S A和MMS R/S B，從用戶MMS UAA向用戶MMS UA B發(fā)送MM的實施例。在該實施例中，應該借助在第三代合伙項目(3GPP)的技術規(guī)程TS 23.140版本5.3.0，發(fā)布5，“群終端；多媒體報文傳送業(yè)務(MMS)；功能說明；階段2”中規(guī)定的所謂的“摘要消息”，即短消息，來闡述在所提及的數(shù)據(jù)傳輸單元之間的數(shù)據(jù)交換。一個摘要消息由至少一個信息元組成。在MMS中，發(fā)送者、即用戶A可以用摘要消息1通過空中接口MM1將MM發(fā)送到他的業(yè)務提供商A的環(huán)境MMSE中的MMS R/S A上。MMS R/S A用摘要消息2來確認正確接收了MMS UA A的MM。
用摘要消息對3(含有MM)和4(應答)來實現(xiàn)MM向接收者的業(yè)務領域B中的MMS R/S B的傳輸。在此之后，用摘要消息5將準備好用于下載的MM通知接收者，即用戶B。在該通知中含有作為參考的、MM的存儲位置的統(tǒng)一資源標記URI(通用資源標識符)。摘要消息6優(yōu)選用作為對于正確接收了給用戶MMS UA B的通知的確認，并且用來將由接收者所希望的傳送模式，即推模式或拉模式，通知MMS業(yè)務提供商。接收者，即用戶B，可以用摘要消息7啟動在MMS R/S B上準備好的MM的下載。然后借助摘要消息8來實現(xiàn)MM從MMS R/S B到MMSUA B上的傳送。除了MM本身之外，識別元素，即所謂的消息ID也是該摘要消息的組成部分，借助該消息ID稍后可以不僅由MMS R/S B，而且可以由接收者的MMS UA B明確地參考MM以用于其它的MMS功能性。由MMS UA B可以用摘要消息9將下載的結(jié)束通知MMS R/S B。
在MMS中發(fā)送者具有匿名發(fā)送他的MM的可能性。例如當用MMS來執(zhí)行意見詢問，或要求諸如債務咨詢、匿名的酗酒者等等的咨詢業(yè)務時，該功能則是有利的。為此必須在發(fā)送MM時，在摘要消息1中相應地放置一個信息元。
在此，僅對于MM的接收者保密發(fā)送者的地址。這意味著，在通知關于在摘要消息5中的準備好用于下載的新到達的MM時，和在下載摘要消息8中的MM時實現(xiàn)保密。在此，參與的MMS業(yè)務提供商還具有關于發(fā)送者身份的不受限制的知識。這是必要的，以便可以相應地對MM計費。
在發(fā)送者匿名的情況下，MMS業(yè)務提供商可以要么通過化名來替換所涉及摘要消息5和8的相應信息元中的發(fā)送者實際地址，要么讓其空著。替代地也可以設想，MMS業(yè)務提供商略去相應的信息元。
附圖6展示了從發(fā)送者發(fā)送消息#1到接收者上的實施例。發(fā)送者發(fā)送消息#1到業(yè)務提供商XY上。發(fā)送者雖然已申請了匿名，但是地址Andreas.Schmidt@XY.de對于業(yè)務提供商XY是已知的。業(yè)務提供商XY隨后通知接收者，消息是由匿名用戶提供。接收者借助數(shù)據(jù)請求指令來訪問業(yè)務提供商XY處的存儲位置。隨后由業(yè)務提供商XY用匿名的發(fā)送者標記發(fā)送消息到接收者上。
接收者可以作為對通知的反應，或作為對所傳送MM的反應來通知他的MMS業(yè)務提供商他未來不希望再從該MM的發(fā)送者收到MM，其方式是他向他的MMS業(yè)務提供商發(fā)送相應的詢問A。在此必須區(qū)分兩種情況1.發(fā)送者的身份是未知的如果MM的發(fā)送者保持匿名，則在一種實施形式中詢問A可以包含一個識別信號I，MMS業(yè)務提供商可以從該識別信號I中求出發(fā)送者的身份。作為對關于準備好了用于下載的新MM的通知的反應，可以采用MM的被包含在通知(根據(jù)附圖5的摘要消息5)中的存儲位置(URI)作為識別信號I。如果接收者的詢問A是對所傳送的MM(根據(jù)附圖5的摘要消息8)的反應，則可以使用MM的消息ID作為識別信號I。
如果MMS業(yè)務提供商通過臨時的化名已替換了發(fā)送者的實際地址，則也可以設想采用該化名作為識別信號I。但是由于按照3GPP的技術規(guī)程TS 23.140，版本5.3.0，發(fā)布5，不是必須地需要傳輸發(fā)送者地址的信息元，并且稍后有可能不能明確地將由MMS業(yè)務提供商臨時發(fā)放的化名分配給實際的發(fā)送者，所以優(yōu)選將URI或消息ID用作識別信號I。
2.發(fā)送者的身份是已知的如果發(fā)送者的身份是已知的，則作為替代URI(在通知之后)或替代消息ID(在傳送MM之后)的識別信號I，用詢問A也可以向MMS業(yè)務提供商傳送應錄入在這個/這些排除清單上的發(fā)送者的地址。但是由于按照3GPP的技術規(guī)程TS 23.140，版本5.3.0，發(fā)布5，不是必須地需要傳輸發(fā)送者地址的信息元，在這里也又適用應優(yōu)選將URI或消息ID用作識別信號I。
下表展示了，在詢問A中可以采用哪些識別信號I。
以下闡述本發(fā)明的其它的實施例。在消息方面分別涉及附圖5的流程。在此，在發(fā)送者方面實現(xiàn)MM的發(fā)送，其方式是發(fā)送者用摘要消息1通過接口MM1發(fā)送MM到他的MMS業(yè)務提供商的MMS領域A中的MMS R/S A上，其中，他有以下的可能性，通知他的MMS業(yè)務提供商，他是否或他希望對接收者隱匿他的身份。MMS R/S A用摘要消息2來確認正確接收了MM。如果有必要，則用摘要消息對3(含有MM)和4(含有應答)來實現(xiàn)將MM向接收者的MMS領域B中的MMS R/S B傳輸。
對于以下的實施例假設了，將發(fā)送者的身份通知了接收者，并且詢問A是對MM通知的反應。在接收了MMS業(yè)務提供商SP B的主管領域MMSE B中的MM之后，首先用摘要消息5將準備好用于下載的MM通知接收者。在該通知中含有了發(fā)送者的地址(可選擇的)，以及MM的URI(對存儲位置的參考)(必須的)。摘要消息6優(yōu)選用作為對由MMSUA B正確接收了通知的確認。
接收者借助題目和/或發(fā)送者的地址識別了，涉及的對于他是不重要的廣告信息，并且接收者因此向他的MMS業(yè)務提供商發(fā)送詢問A，以便安排將發(fā)送者的地址錄入到所謂的“黑名單”中，其中，將來自通知中的發(fā)送者的地址用作為識別信號I。MMS業(yè)務提供商SP可以直接將該發(fā)送者地址錄入到接收者的專用的“黑名單”中。在未來由接收者方的MMS業(yè)務提供商來清除該發(fā)送者的其它的MM，并且不再提供給接收者用于下載。接收者因而不再受發(fā)送者的不需要消息的煩擾。
在一個其它的實施例中假設了未將發(fā)送者的身份通知接收者，缺少了發(fā)送者地址的信息元，且詢問A是對MM通知的反應。在接收了MMS業(yè)務提供商B的主管領域MMSE B中的MM之后，首先用摘要消息5將準備好用于下載的MM通知接收者。在該通知中，基于發(fā)送者對匿名的愿望，不存在發(fā)送者地址。不過在通知中含有了事由(可選擇的)，和URI(對MM的存儲位置的參考，必須的)。在此，摘要消息6優(yōu)選用作為對由MMS UA B正確接收了通知的確認。
接收者在該實施例中借助題目或事由行識別了，涉及的是對于他不重要的廣告信息，并且接收者因此向他的MMS業(yè)務提供商發(fā)送詢問A，以便安排將發(fā)送者的地址錄入到“黑名單”中，其中，將來自通知中的MM的URI用作為識別信號I。MMS業(yè)務提供商可以借助URI求出發(fā)送者的身份，并且將他錄入到接收者的專用的黑名單中。在未來由接收者方的MMS業(yè)務提供商來清除該發(fā)送者的其它的MM，并不再提供給接收者用于下載。因而不再用該發(fā)送者的不需要的消息來煩擾接收者。
在一個其它的實施例中假設了未將發(fā)送者的身份通知接收者，發(fā)送者地址含有化名，并且詢問A是對MM的傳送的反應。在接收了MMS業(yè)務提供商B的主管領域MMSE B中的MM之后，首先用摘要消息5將準備好用于下載的MM通知接收者。在該實施例中，除了URI(對存儲位置的參考)之外，在通知中也含有化名(例如“Anonymer.Teilnehmer@XY.de“)作為發(fā)送者的地址。摘要消息6優(yōu)選用作為對由MMS UA B正確接收了通知的確認。
在被包含在通知中的信息的基礎上，接收者決策下載MM。為了啟動下載MM，由MMS UA B向MMS R/S B發(fā)送摘要消息7。借助摘要消息8實現(xiàn)從MMS R/S B向MMS UA B傳送MM。除了MM之外(也就是多媒體有用數(shù)據(jù))，用摘要消息8也傳輸作為發(fā)送者地址的化名(例如“Anonymer.Teilnehmer@XY.de”)和MM用的消息ID。由MMS UA B可以用摘要消息9將下載的成功結(jié)束通知MMS R/S B。如果接收者查明，他的下載MM的決策曾是錯誤的，因為它只含有侮辱而沒有可使用的內(nèi)容，他現(xiàn)在則可以向他的MMS業(yè)務提供商發(fā)送詢問A，以便安排將發(fā)送者地址錄入到黑名單中，其中，將來自摘要消息8的MM的(必須的)消息ID用作為識別信號I。MMS業(yè)務提供商SP B可以借助消息ID求出發(fā)送者的身份，并且將他錄入到接收者的專用的黑名單中。在未來由接收者方的MMS業(yè)務提供商來清除該發(fā)送者的其它的MM，并且不再提供給接收者用于下載。接收者不再由發(fā)送者的不需要的消息來煩擾，并且通過空中接口不向接收者B傳輸不必要的數(shù)據(jù)。
對于由接收者的MMS UA B向MMS業(yè)務提供商SP B的MMS R/S B發(fā)送詢問A，出現(xiàn)了下述的不同的可能性。
詢問A可以作為獨立的摘要消息來發(fā)送，該摘要消息(除了另外的信息之外)也含有識別信號I作為獨立的信息元。另外的信息例如可以是其它的過濾準則，相應的(例如專用或公共的)清單的說明，或所希望的過濾器功能的時間限制。
此外，在由第三代合伙項目(3GPP)中規(guī)定的已經(jīng)公開的摘要消息中，例如在附圖5中展示的所謂的“MM1_notification.RES”(參考6)，“MM1_retrieve.REQ”(參考7)，“MM1_acknowledgement.REQ”(參考9)中，或甚至在附圖5中未展示的摘要消息“MM1_read_reply_recipient.REQ”(用來傳送接收者的讀取確認)中，也可以傳送作為獨立信息元的詢問A。
最后也可以將詢問A作為一個MM之內(nèi)的有用數(shù)據(jù)來發(fā)送，理想地將該詢問A發(fā)送到MMS業(yè)務提供商的業(yè)務地址上，用于黑名單的更新。
優(yōu)選應在MMS業(yè)務提供商SP的主管領域MMSE中來管理黑名單，以便已經(jīng)在由相同的發(fā)送者通過昂貴的空中接口傳輸其它的MM之前，過濾器功能就在起作用。在此，可以優(yōu)選將黑名單作為MMS用戶數(shù)據(jù)庫的組成部分而通過接口MM6納入到MMS業(yè)務提供商SP的MMSE中(請參閱附圖4)。但是替代地，它也可以在另外的計算機上，或直接由MMS R/S來管理。
權(quán)利要求
1.用于阻塞不需要的消息(MM)的方法，具有以下的方法步驟-傳輸發(fā)送者(MMS UA A)的消息到發(fā)送機(MMS R/S A)，-從所述的發(fā)送機(MMS R/S A)傳輸消息到業(yè)務提供商(MMSE SPB)，和-從所述的業(yè)務提供商(MMSE SP B)傳輸消息到接收者(MMS UAB)，其中，由所述的業(yè)務提供商來服務該接收者(MMS UA B)，其特征在于，只有在所述的發(fā)送者不在排除清單中的情況下，才實現(xiàn)從所述的業(yè)務提供商傳輸消息到所述的接收者上。
2.按權(quán)利要求1的方法，其特征在于，在所述的業(yè)務提供商處來管理所述的排除清單。
3.按以上權(quán)利要求之一的方法，其特征在于，所述的排除清單是所述接收者的一種專用的、獨有的排除清單。
4.按權(quán)利要求2或3之一的方法，其特征在于，所述的排除清單是一種通用的排除清單，對于所有的接收者和/或接收者群考慮該排除清單。
5.按以上權(quán)利要求之一的方法，其特征在于，如果所述的接收者想讓一個發(fā)送者放置到所述的排除清單上，他則通知所述的業(yè)務提供商。
6.按以上權(quán)利要求之一的方法，其特征在于，所述的接收者匿名地接收消息，并且如果他想讓所述消息的發(fā)送者放置到所述的排除清單上，他則通知所述的業(yè)務提供商。
7.按以上權(quán)利要求之一的方法，其特征在于，所述的接收者接收具有化名的消息，并且如果他想讓所述消息的發(fā)送者放置到所述的排除清單上，他則通知所述的業(yè)務提供商。
8.按權(quán)利要求5至7之一的方法，其特征在于，所述的給業(yè)務提供商的通知構(gòu)成為獨立的摘要消息。
9.按權(quán)利要求8的方法，其特征在于，在所述的摘要消息中集成了信息元形式的給業(yè)務提供商的通知。
10.按權(quán)利要求5至9之一的方法，其特征在于，在多媒體消息(MM)中，尤其是在該多媒體消息的有用數(shù)據(jù)中，含有所述的給業(yè)務提供商的通知。
11.按權(quán)利要求5至10之一的方法，其特征在于，所述的給業(yè)務提供商的通知包含識別信號(I)，所述的業(yè)務提供商從該識別信號中可以確定所述發(fā)送者的身份。
12.按權(quán)利要求5至11之一的方法，其特征在于，所述的給業(yè)務提供商的通知含有過濾器功能的其它信息，尤其是所述排除清單的類型和/或時間限制。
13.按權(quán)利要求11的方法，其特征在于，將消息標記和/或所述的化名用作識別信號(I)。
14.用于阻塞不需要的消息(MM)的系統(tǒng)，具有-一個發(fā)送機(MMS R/S A)，該發(fā)送機適用于傳輸發(fā)送者(MMS UAA)的消息，-一個業(yè)務提供商(MMSE SP B)，該業(yè)務提供商適用于從所述的發(fā)送機(MMS R/S A)接收消息，和-一個由所述的業(yè)務提供商(MMSE SP B)服務的接收者(MMS UAB)，其中，所述的接收者適用于從所述的業(yè)務提供商(MMSE SP B)接收消息，其特征在于，所述的業(yè)務提供商適用于，只有在所述的發(fā)送者不在排除清單中的情況下，才向所述的接收者傳輸消息。
15.按權(quán)利要求14的系統(tǒng)，其特征在于，所述的業(yè)務提供商適用于管理所述的排除清單。
16.按權(quán)利要求14或15之一的系統(tǒng)，其特征在于，所述的排除清單是所述接收者的一種專用的、獨有的排除清單。
17.按權(quán)利要求14或15之一的系統(tǒng)，其特征在于，所述的排除清單是一種通用的排除清單，對于所有的接收者和/或接收者群考慮該排除清單。
18.按權(quán)利要求14至17之一的系統(tǒng)，其特征在于，所述的接收者，如果他想讓一個發(fā)送者放置到所述的排除清單上，則通知所述的業(yè)務提供商。
19.按權(quán)利要求14至18之一的系統(tǒng)，其特征在于，所述的接收者匿名地接收消息，并且如果他想讓所述消息的發(fā)送者放置到所述的排除清單上，他則通知所述的業(yè)務提供商。
20.按權(quán)利要求14至19之一的系統(tǒng)，其特征在于，所述的接收者接收具有化名的消息，并且如果他想讓所述消息的發(fā)送者放置到所述的排除清單上，他則通知所述的業(yè)務提供商。
21.按權(quán)利要求18至20之一的系統(tǒng)，其特征在于，所述的給業(yè)務提供商的通知構(gòu)成為獨立的摘要消息。
22.按權(quán)利要求21的系統(tǒng)，其特征在于，在所述的摘要消息中集成了信息元形式的給業(yè)務提供商的通知。
23.按權(quán)利要求18至22之一的系統(tǒng)，其特征在于，在多媒體消息(MM)中，尤其是在該多媒體消息的有用數(shù)據(jù)中，含有所述的給業(yè)務提供商的通知。
24.按權(quán)利要求18至23之一的系統(tǒng)，其特征在于，所述的給業(yè)務提供商的通知包含識別信號(I)，所述的業(yè)務提供商從該識別信號中可以確定所述發(fā)送者的身份。
25.按權(quán)利要求18至24之一的系統(tǒng)，其特征在于，所述的給業(yè)務提供商的通知含有過濾器功能的其它信息，尤其是所述排除清單類型和/或時間限制。
26.按權(quán)利要求24的系統(tǒng)，其特征在于，將消息標記和/或所述的化名用作識別信號(I)。
27.用于按權(quán)利要求1至13之一的方法中的，和/或用于按權(quán)利要求14至26之一的系統(tǒng)中的終端設備，尤其是移動無線終端設備。
28.用于按權(quán)利要求1至13之一的方法中的，和/或用于按權(quán)利要求14至26之一的系統(tǒng)中的發(fā)送裝置/接收裝置，尤其是移動無線基站。
全文摘要
本發(fā)明涉及一種用于阻塞不需要的消息(MM)的方法，具有以下的方法步驟傳輸發(fā)送者(MMSUAA)的消息到發(fā)送機(MMSR/SA)上；從發(fā)送機(MMSR/SA)傳輸消息到業(yè)務提供商(MMSESPB)上；和從業(yè)務提供商(MMSESPB)傳輸消息到接收者(MMSUAB)上，其中，由業(yè)務提供商來服務接收者。只有在發(fā)送者不在排除清單中的情況下，才實現(xiàn)從業(yè)務提供商傳輸消息到接收者上。優(yōu)選在業(yè)務提供商處管理排除清單。
文檔編號H04W4/12GK1675903SQ03818640
公開日2005年9月28日 申請日期2003年7月7日 優(yōu)先權(quán)日2002年8月2日
發(fā)明者A·施密德特, M·特勞伯格, S·范尼克爾克 申請人:西門子公司