專(zhuān)利名稱(chēng)：終端中完全一樣的通知消息的處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及終端中完全一樣的(duplicate)通知消息的處理方法，尤其涉及終端中支持多媒體消息傳送服務(wù)(MMS)的完全一樣的通知消息的處理方法。
背景技術(shù)：
目前，在無(wú)線(xiàn)終端市場(chǎng)上，WAP(無(wú)線(xiàn)應(yīng)用協(xié)議)1.x標(biāo)準(zhǔn)已經(jīng)建立好并且已經(jīng)用于無(wú)線(xiàn)數(shù)據(jù)服務(wù)，這些標(biāo)準(zhǔn)可以為終端提供IP處理和互聯(lián)網(wǎng)服務(wù)。
WAP方法主要提供一種基于簡(jiǎn)單文本菜單的服務(wù)，該服務(wù)是針對(duì)低帶寬、低規(guī)格的終端優(yōu)化而成的。此外，在GSM或IS-41中使用的SMS(短消息服務(wù))執(zhí)行一種文本格式、約100個(gè)字節(jié)的短消息轉(zhuǎn)移服務(wù)。
MMS就是從上述基于文本的服務(wù)提供中衍生出來(lái)的，并且允許用戶(hù)接收多樣的高品質(zhì)多媒體內(nèi)容。其系統(tǒng)由用于執(zhí)行IP網(wǎng)絡(luò)連接和多媒體消息處理的MMS代理/中繼服務(wù)器以及用于存儲(chǔ)和管理消息的服務(wù)器共同構(gòu)成。
MMS代理/中繼服務(wù)器使用SMTP(簡(jiǎn)單消息轉(zhuǎn)移協(xié)議)和HTTP(超文本轉(zhuǎn)移協(xié)議)分別連接到目前在IP網(wǎng)路上執(zhí)行的郵件服務(wù)和WAP服務(wù)。此外，SMTP協(xié)議還用于連接到其它MMS代理/中繼服務(wù)器。
圖1示出了常規(guī)的MMS協(xié)議棧。如圖所示，MMS終端10使用WSP(無(wú)線(xiàn)對(duì)話(huà)協(xié)議)和HTTP協(xié)議，以便通過(guò)WAP網(wǎng)關(guān)20連接到MMS代理/中繼服務(wù)器(在下文中稱(chēng)之為MMS服務(wù)器)30。
MMS服務(wù)器30使用SMTP協(xié)議(該協(xié)議目前普遍被看作郵件協(xié)議)連接到其它MMS服務(wù)器。下面將解釋MMS服務(wù)的過(guò)程。
首先，通過(guò)使用SMTP協(xié)議，發(fā)送方的終端接收一個(gè)相連的多媒體文件的郵件消息，該郵件消息是消息發(fā)送者通過(guò)互聯(lián)網(wǎng)發(fā)送過(guò)來(lái)的。發(fā)送方的終端參照相應(yīng)的郵件接收配置文件來(lái)解析該郵件消息，并且轉(zhuǎn)換該郵件消息中的媒體內(nèi)容(文本和圖像)以便針對(duì)接收方的終端達(dá)到最優(yōu)化。
配置信息包含接收方終端的使用信息，比如MMS支持的可用性、分辨率、所支持顏色的數(shù)目、存儲(chǔ)器容量等。
接下來(lái)，MMS服務(wù)器30通知終端有消息到了。此時(shí)，MMS服務(wù)器30可以通過(guò)使用HTTP協(xié)議將通知消息(M-notification.ind)發(fā)送給與WAP G/W(網(wǎng)關(guān))相連的接收方終端，或者通過(guò)連接到現(xiàn)存的SMSC(短消息服務(wù)中心)以文本消息格式通知接收方終端有消息到了。
通知消息包含URI(統(tǒng)一資源指示符)信息，多媒體消息就存儲(chǔ)在該URI信息中。為了管理通知消息，可以使用預(yù)留轉(zhuǎn)移方法，該方法通過(guò)使用定時(shí)技術(shù)可以在發(fā)送者所期望的時(shí)間點(diǎn)發(fā)送消息。
已收到該通知消息的接收方終端首先發(fā)送一個(gè)針對(duì)該通知消息的響應(yīng)消息(M-Notify resp.ind)，并且能夠接收、拒絕、或刪除相應(yīng)的消息。
當(dāng)接收方終端接收消息時(shí)，它借助HTTP GET方法通過(guò)使用相應(yīng)消息的URI來(lái)訪(fǎng)問(wèn)MMS服務(wù)器。接下來(lái)，MMS服務(wù)器通過(guò)WSP對(duì)話(huà)包裹好轉(zhuǎn)換后的消息并且將其發(fā)送到接收方終端。相反，MMS服務(wù)器能夠?qū)l(fā)送方終端所創(chuàng)建的多媒體消息(M-send.req)轉(zhuǎn)換為郵件格式或MMS消息，之后通過(guò)互聯(lián)網(wǎng)或MMS支持終端將其發(fā)送出去。
上述過(guò)程在圖2中示出。圖2示出了常規(guī)的MMS交易流。當(dāng)想發(fā)送多媒體消息的發(fā)送方終端11將一則M-send.req消息發(fā)送到MMS服務(wù)器30時(shí)，MMS服務(wù)器30將相應(yīng)的響應(yīng)消息M-Send.conf發(fā)送給發(fā)送方終端11，并且同時(shí)還向接收方終端12發(fā)送一則用于通知多媒體消息到達(dá)的通知消息M-Notification。
接收方終端12向MMS服務(wù)器30發(fā)送一則針對(duì)通知消息M-Notification的響應(yīng)消息M-Notyfyresp.ind，或者通過(guò)GetReq請(qǐng)求而接收實(shí)際的多媒體消息M-retrieve.conf。如果接收方終端12接收到多媒體消息M-retrieve.conf，則它將相應(yīng)的響應(yīng)消息M-Acknowledge.ind發(fā)送給MMS服務(wù)器30。
之后，如果接收方終端12請(qǐng)求關(guān)于MMS服務(wù)器30是否已經(jīng)將相應(yīng)的消息發(fā)送給接收方終端12的信息，則MMS服務(wù)器30將確認(rèn)消息M-Delivery.ind發(fā)送給接收方終端12。
目前，為了支持上述多媒體服務(wù)，使用了MMSC V1.0版本的MMS服務(wù)器。MMSC V1.0版本的MMS服務(wù)器30僅使用SMS進(jìn)棧功能，以便向接收方終端12發(fā)送一則用于通知有多媒體消息到達(dá)的通知消息。此時(shí)，MMSC V1.0版本的MMS服務(wù)器30并不檢查該通知消息實(shí)際上是否已經(jīng)被發(fā)送到接收方終端12，原因在于沒(méi)有將該通知消息發(fā)送到接收方終端12的幾率相對(duì)較低。
因此，即使該通知消息沒(méi)有到達(dá)接收方終端12，MMSC V1.0版本的MMS服務(wù)器30也不會(huì)再次發(fā)送通知消息，從而使消息到達(dá)的可靠性較低。因此，為了增大消息到達(dá)的可靠性，使MMS服務(wù)器的版本從MMSC V1.0變?yōu)镸MSCV1.X的趨勢(shì)在不斷增大。
版本MMSC V1.X使用重試機(jī)制。該重試機(jī)制在每一個(gè)重試周期中都會(huì)向接收方終端發(fā)送一則通知消息，直到它確認(rèn)該通知消息已經(jīng)到達(dá)接收方終端。
根據(jù)該重試機(jī)制，MMS服務(wù)器在下列時(shí)刻會(huì)停止通知消息M-Notification的發(fā)送(1)當(dāng)MMS服務(wù)器接收到HTTP GET請(qǐng)求(該請(qǐng)求具有和通知消息相同的URI)的時(shí)候；以及(2)當(dāng)MMS服務(wù)器接收到通知消息響應(yīng)(該響應(yīng)具有和通知消息相同的交易ID)的時(shí)候。
參照?qǐng)D3，可以看到MMSC V1.0版本的MMS服務(wù)器和MMSC V1.X版本的MMS服務(wù)器之間的服務(wù)提供過(guò)程中的差別。
圖3中的(a)示出了MMSC V1.0的MMS服務(wù)器31和接收方終端12之間的通信。該服務(wù)器通過(guò)使用SMS進(jìn)棧將通知消息M-Notification.ind發(fā)送到接收方終端。因?yàn)镸MSC V1.0版本的MMS服務(wù)器31沒(méi)有使用重試機(jī)制，所以它僅發(fā)送通知消息，而并不涉及接收方終端12實(shí)際上是否已經(jīng)接收到該通知消息。
另一方面，圖3中的(b)示出了MMSC V1.X版本的MMS服務(wù)器32和接收方終端12之間的通信。MMSC V1.X版本的服務(wù)器32通過(guò)重試機(jī)制將通知消息M-Notification.ind發(fā)送到接收方終端12。例如，MMS服務(wù)器32根據(jù)特定的重試周期將Notification.ind發(fā)送到接收方終端12，直到在將該通知消息M-Notification.ind發(fā)送到該終端之后接收到針對(duì)該通知消息的響應(yīng)消息NotifyResp.ind。
因此，如果將MMSC V1.X版本應(yīng)用于MMS服務(wù)器32，則接收方終端12可以接收到來(lái)自MMS服務(wù)器32的通知消息，其接收失敗的幾率很小。
然而，如果在下載多媒體消息之前接收到完全一樣的通知消息并且由該終端發(fā)送的響應(yīng)消息已丟失，則該終端并不發(fā)送針對(duì)該完全一樣的通知消息的響應(yīng)消息，因此會(huì)連續(xù)地接收該通知消息。即，可能出現(xiàn)接收方終端接收到太多不想要的消息的問(wèn)題。
當(dāng)下載好多媒體消息之后又接收到完全一樣的通知消息時(shí)，因?yàn)楝F(xiàn)存的通知消息已經(jīng)被刪除，所以接收方終端將該完全一樣的通知消息確認(rèn)為新的通知消息。結(jié)果，有可能出現(xiàn)這樣的情況，用戶(hù)將需要為接收到相同的多媒體消息而付雙倍的錢(qián)。
另外，一旦接收方終端連續(xù)地接收完全一樣的通知消息，則接收方終端重復(fù)接收和刪除通知消息的過(guò)程，從而使電池壽命縮短了。

發(fā)明內(nèi)容
本發(fā)明的提出著力解決背景技術(shù)中所提及的諸多問(wèn)題。
本發(fā)明可以提供一種消息處理方法，在僅當(dāng)有來(lái)自接收方終端的響應(yīng)或確認(rèn)時(shí)才將發(fā)送方終端所發(fā)送的數(shù)據(jù)傳輸?shù)浇邮辗浇K端的數(shù)據(jù)傳輸系統(tǒng)中，該方法可以防止接收方終端連續(xù)地接收到請(qǐng)求響應(yīng)或確認(rèn)的消息。
此外，本發(fā)明可以提供一種在終端中處理完全一樣的通知消息的方法，在利用重試機(jī)制的多媒體消息服務(wù)提供系統(tǒng)中，該方法可以處理不需要的完全一樣的通知消息。
為了實(shí)現(xiàn)這些根據(jù)本發(fā)明各個(gè)方面所得的特征，如本文具體化和寬泛描述的那樣，提供了一種用在支持多媒體消息傳送服務(wù)(MMS)的終端中的消息處理方法，該方法包括如下步驟接收來(lái)自MMS服務(wù)器的通知消息，該通知消息用于通知多媒體消息的接收情況；如果該通知消息被確定為完全一樣的通知消息，則根據(jù)是否下載了與該完全一樣的通知消息相對(duì)應(yīng)的多媒體消息，來(lái)刪除該通知消息；以及如果作為上述確定的結(jié)果該通知消息不是完全一樣的通知消息，則發(fā)送一則針對(duì)該通知消息的響應(yīng)消息或一則用于請(qǐng)求該多媒體消息的消息。
另外，提供了一種根據(jù)本發(fā)明來(lái)提供多媒體消息傳送服務(wù)(MMS)的方法，該方法包括如下步驟MMS服務(wù)器向終端發(fā)送一則通知消息Noti1，該通知消息Noti1用于通知已接收到多媒體消息；該終端向該MMS服務(wù)器發(fā)送一個(gè)針對(duì)該通知消息的響應(yīng)；除非該MMS服務(wù)器在重試周期內(nèi)接收到該響應(yīng)，否則向該終端重新發(fā)送通知消息Noti2；如果該終端在下載好該多媒體消息之后接收到Noti2，則用Noti2替代Noti1；以及該終端向該MMS服務(wù)器發(fā)送一個(gè)針對(duì)Noti2的響應(yīng)。
另外，提供了一種根據(jù)本發(fā)明的終端，該終端包括接收器，用于接收通知消息，該通知消息用于通知有多媒體消息到達(dá)；數(shù)據(jù)庫(kù)管理模塊，用于管理該通知消息的刪除或存儲(chǔ)，該通知消息的刪除或存儲(chǔ)都是根據(jù)接收到的通知消息是否是完全一樣的以及該多媒體消息是否已經(jīng)下載好來(lái)決定的；數(shù)據(jù)庫(kù)，用于根據(jù)來(lái)自數(shù)據(jù)庫(kù)管理模塊的指令來(lái)存儲(chǔ)通知消息；存儲(chǔ)器，該存儲(chǔ)器具有消息處理模塊，該消息處理模塊用于提供針對(duì)接收到的通知消息的響應(yīng)；以及處理器，用于與接收器和存儲(chǔ)器配合起來(lái)處理消息。


附圖被包括在此以提供對(duì)本發(fā)明的進(jìn)一步理解，并且構(gòu)成了本說(shuō)明書(shū)的一部分。附圖示出了本發(fā)明的實(shí)施例并與相應(yīng)的描述一起用于解釋本發(fā)明的原理。
在附圖中圖1示出了常規(guī)的MMS協(xié)議棧；圖2示出了常規(guī)的MMS交易流；圖3示出了MMSC V1.0版本的MMS服務(wù)器和MMSC V1.X版本的MMS服務(wù)器的服務(wù)提供方法；圖4示出了在與MMS服務(wù)器進(jìn)行通信的終端中一種利用重試機(jī)制的消息處理方法；圖5示出了根據(jù)本發(fā)明用在終端中的通知消息處理方法；圖6是根據(jù)本發(fā)明的終端的方框圖；圖7示出了第一種接收到完全一樣的通知消息的情況以及根據(jù)本發(fā)明的消息處理方法；圖8示出了第二種接收到完全一樣的通知消息的情況以及根據(jù)本發(fā)明的消息處理方法；
圖9示出了第三種接收到完全一樣的通知消息的情況以及根據(jù)本發(fā)明的消息處理方法。
具體實(shí)施例方式
本發(fā)明的發(fā)明人已經(jīng)認(rèn)識(shí)到，現(xiàn)有技術(shù)中MMS終端內(nèi)的消息處理方法不適合用于與使用重試機(jī)制的MMS服務(wù)器進(jìn)行通信?；谶@種認(rèn)識(shí)，已開(kāi)發(fā)出下面的種種特征。
首先，參照?qǐng)D4，下文將描述MMS終端中的消息處理方法。
接收方終端接收來(lái)自網(wǎng)絡(luò)服務(wù)器(比如MMS服務(wù)器)的通知消息(S101)。該通知消息是一則用于通知由發(fā)送方終端分派的多媒體消息已經(jīng)到達(dá)MMS服務(wù)器的消息。
已接收到通知消息的終端確定該通知消息是否是完全一樣的通知消息(S102)。因?yàn)樵摻K端會(huì)將該通知消息存儲(chǔ)到數(shù)據(jù)庫(kù)中直到它下載好相應(yīng)的多媒體消息，所以可以將目前接收到的通知消息與數(shù)據(jù)庫(kù)中已經(jīng)存儲(chǔ)的通知消息進(jìn)行比較。
作為確定的結(jié)果，如果目前接收到的通知消息不是完全一樣的通知消息(即，在數(shù)據(jù)庫(kù)中不存在相同的通知消息)，則將它重新存儲(chǔ)到數(shù)據(jù)庫(kù)中(S104)。
接下來(lái)，檢查該終端的運(yùn)行模式是自動(dòng)檢索模式或延遲檢索模式(S105)。如果該終端處于自動(dòng)檢索模式，則在接收到通知消息之后將一則用于請(qǐng)求實(shí)際的多媒體消息的消息GetReq發(fā)送給MMS服務(wù)器(S106)。如果該終端處于延遲檢索模式，則在接收到通知消息之后將一則響應(yīng)消息M-NotifyResp.ind發(fā)送給MMS服務(wù)器以便通知已接收到該通知消息(S107)。同時(shí)，如果接收到的通知消息被確定為完全一樣的通知消息，則將它刪除(S103)。
至此，發(fā)明人已經(jīng)認(rèn)識(shí)到，因某些問(wèn)題的存在還可以進(jìn)一步改進(jìn)上述消息處理過(guò)程。
第一個(gè)問(wèn)題可能出現(xiàn)在步驟S103中。盡管已接收到第一個(gè)通知消息的終端已經(jīng)向MMS服務(wù)器發(fā)送了響應(yīng)消息，但是該響應(yīng)消息被弄丟了，此時(shí)，MMS服務(wù)器會(huì)發(fā)送第二個(gè)通知消息。此刻，該終端不得不向MMS服務(wù)器發(fā)送一則針對(duì)第二個(gè)通知消息的響應(yīng)消息或一則多媒體請(qǐng)求消息。但是，該終端無(wú)條件地忽略了任何完全一樣的通知消息(S103)，因此它可能會(huì)連續(xù)地接收完全一樣的通知消息。
第二個(gè)問(wèn)題可能出現(xiàn)在步驟S102中。在確定通知消息是否是完全一樣的那個(gè)步驟中，如果在下載好多媒體消息之后接收到完全一樣的通知消息，則出現(xiàn)了沒(méi)有將該通知消息恰當(dāng)?shù)卮_定為完全一樣的消息這樣的錯(cuò)誤。這是因?yàn)樵摻K端在下載好該多媒體消息之后就刪除了所存儲(chǔ)的通知消息。
因此，本發(fā)明提供了一種用在終端中的改進(jìn)的消息處理方法，該方法從利用重試機(jī)制的MMS服務(wù)器中接收到多媒體消息服務(wù)。
圖5示出了根據(jù)本發(fā)明一實(shí)施例用在終端中的一種通知消息處理方法。
首先，支持多媒體消息傳送服務(wù)的終端接收到從MMS服務(wù)器中發(fā)送過(guò)來(lái)的通知消息(S201)。該通知消息是一則用于通知由發(fā)送方終端發(fā)送過(guò)來(lái)的多媒體消息已經(jīng)到達(dá)MMS服務(wù)器的消息。
已接收到該通知消息的終端確定該通知消息是否是完全一樣的通知消息(S202)。所有的通知消息都具有交易標(biāo)識(shí)符(TID)，并且對(duì)于同一多媒體消息，MMS服務(wù)器發(fā)送具有相同TID的通知消息。因此，如果接收到的通知消息的TID等于先前接收到的通知消息的TID，則該終端將該接收到的通知消息確定為完全一樣的消息。
作為確定的結(jié)果，如果該通知消息是一則新多媒體消息的通知消息，則存儲(chǔ)它(S203)。此時(shí)，該通知消息可以在消息數(shù)據(jù)庫(kù)中存儲(chǔ)一段有限的時(shí)間(比如24小時(shí))(S203)。根據(jù)現(xiàn)有的消息處理方法，該終端將該通知消息存儲(chǔ)到數(shù)據(jù)庫(kù)中，之后當(dāng)下載好與該通知消息相對(duì)應(yīng)的多媒體消息時(shí)就將它刪除。因此，如果因網(wǎng)絡(luò)環(huán)境故障而在下載好多媒體消息之后又接收到通知消息，則無(wú)法確定新接收到的通知消息是否是完全一樣的消息，因?yàn)橄惹敖邮盏降耐ㄖ⒁驯粍h除。為了應(yīng)對(duì)這種情況，可以將通知消息設(shè)置成須存儲(chǔ)一段時(shí)限(比如24小時(shí))。無(wú)論網(wǎng)絡(luò)環(huán)境有多差，在一整天之后不太可能再接收到通知消息，正是基于該幾率才將存儲(chǔ)時(shí)間設(shè)置為24小時(shí)。
在一個(gè)實(shí)施例中，該終端可以在空閑模式中檢查在消息數(shù)據(jù)庫(kù)中所存儲(chǔ)的通知消息中是否有任何在24小時(shí)之前接收到的通知消息，并且刪除這樣的通知消息。
同時(shí)，如果接收到的通知消息被確定為完全一樣的消息，則檢查相應(yīng)的多媒體消息(MM)是否已經(jīng)下載好(S204)。如果相應(yīng)的多媒體消息已經(jīng)下載好，則可以立即刪除完全一樣的接收到的通知消息(S206)。然而，如果相應(yīng)的多媒體消息還沒(méi)有下載好，則只改變(更新)消息數(shù)據(jù)庫(kù)中所存儲(chǔ)的通知消息的接收時(shí)間(S205)。考慮到用戶(hù)可能不下載并查看已經(jīng)存儲(chǔ)到消息數(shù)據(jù)庫(kù)中的多媒體消息這種情況，只有通知消息的接收時(shí)間被改變并且被通知給用戶(hù)，使得用戶(hù)可以識(shí)別出最近接收到的多媒體消息。結(jié)果，有可能防止同一完全一樣的多媒體消息被存儲(chǔ)到消息數(shù)據(jù)庫(kù)中。
從步驟S202到步驟S206的過(guò)程可以在終端的數(shù)據(jù)庫(kù)(DB)管理器中執(zhí)行。即，數(shù)據(jù)庫(kù)管理器執(zhí)行如下處理步驟(1)在與數(shù)據(jù)庫(kù)中已經(jīng)存儲(chǔ)的通知消息相比較的情況下，辨別目前接收到的通知消息是否是完全一樣的消息；(2)只將非完全一樣的通知消息存儲(chǔ)到數(shù)據(jù)庫(kù)中；(3)當(dāng)接收到完全一樣的通知消息時(shí)，辨別相應(yīng)的多媒體消息是否已經(jīng)下載好；(4)在相應(yīng)的多媒體消息已經(jīng)下載好之后，刪除任何接收到的完全一樣的通知消息；以及(5)如果在相應(yīng)的多媒體消息下載好之前又接收到完全一樣的通知消息，則只改變?cè)撏ㄖ⒌慕邮諘r(shí)間。
根據(jù)接收到的通知消息是否是完全一樣的消息，數(shù)據(jù)庫(kù)管理器以不同的方式來(lái)處理通知消息。此外，針對(duì)所有接收到的通知消息，該終端向MMS服務(wù)器發(fā)送M-NotiResp.ind或GetReq。向MMS服務(wù)器發(fā)送M-NotiResp.ind或GetReq的處理步驟S207到S209可以在該終端的消息處理器中執(zhí)行。
首先，消息處理器確定該終端是處于終端檢索模式還是處于延遲檢索模式(S207)。在自動(dòng)檢索模式中，該終端向MMS服務(wù)器發(fā)送多媒體請(qǐng)求消息GetReq(S208)。在延遲檢索模式中，該終端向MMS服務(wù)器發(fā)送響應(yīng)消息M-NotiResp.ind(S209)。
即，因?yàn)楫?dāng)接收到通知消息時(shí)該終端無(wú)條件地向MMS服務(wù)器發(fā)送GetReq或M-NotiResp.ind，所以在沒(méi)有檢查該終端是否已經(jīng)接收到通知消息的情況下該MMS服務(wù)器不可能連續(xù)地發(fā)送相同的通知消息。
此時(shí)，MMS服務(wù)器可能接收到針對(duì)同一多媒體消息的GetReq或M-NotiResp.ind消息，這不會(huì)引起問(wèn)題，因?yàn)镸MS服務(wù)器在接收到GetReq或M-NotiResp.ind消息時(shí)會(huì)刪除具有相同TID的GetReq或M-NotiResp.ind消息。
圖6是根據(jù)本發(fā)明一實(shí)施例的終端的方框圖。如圖所示，終端300可以包括發(fā)送和接收單元310，用于與MMS服務(wù)器進(jìn)行通信；存儲(chǔ)器330，該存儲(chǔ)器330又包括用于管理接收到的消息的存儲(chǔ)和刪除的數(shù)據(jù)庫(kù)管理模塊331、用于控制消息傳輸?shù)南⑻幚砟K332、和用于存儲(chǔ)消息的消息數(shù)據(jù)庫(kù)333；以及處理器320，該處理器320與存儲(chǔ)器330、發(fā)送和接收單元310協(xié)作。
通過(guò)與支持多媒體消息傳送服務(wù)的服務(wù)器進(jìn)行通信，發(fā)送和接收單元310能夠接收到通知消息M-Notification.ind、多媒體消息M-retrieve.conf等，并且能夠發(fā)送針對(duì)通知消息的響應(yīng)消息M-NotifyResp.ind和用于請(qǐng)求多媒體消息的消息GetReq。
存儲(chǔ)器330可以包括數(shù)據(jù)庫(kù)管理模塊331、消息處理模塊332、和消息數(shù)據(jù)庫(kù)333。數(shù)據(jù)庫(kù)管理模塊331和消息處理模塊332包含可由處理器320執(zhí)行的指令。
數(shù)據(jù)庫(kù)管理模塊331包含用于執(zhí)行下列步驟的指令確定接收到的通知消息是否是完全一樣的消息；如果接收到的通知消息不是完全一樣的消息，則將接收到的通知消息存儲(chǔ)到消息數(shù)據(jù)庫(kù)333中；如果接收到的通知消息是完全一樣的消息，則確定多媒體消息是否已經(jīng)下載好；如果多媒體消息已下載好，則刪除該通知消息；以及如果多媒體消息還沒(méi)有下載好，則改變?cè)撏ㄖ⒌慕邮諘r(shí)間。
為了確定目前接收到的通知消息是否是完全一樣的消息，數(shù)據(jù)庫(kù)管理模塊331檢查其TID與先前接收到的通知消息相同的那個(gè)消息是否被存儲(chǔ)在消息數(shù)據(jù)庫(kù)333中。如果任何消息具有與先前接收到的消息相同的TID，則該消息是完全一樣的消息。
另外，數(shù)據(jù)庫(kù)管理模塊331在空閑模式中或當(dāng)接通電源時(shí)檢索消息數(shù)據(jù)庫(kù)333，并且刪除在24小時(shí)之前接收到的消息。無(wú)論網(wǎng)絡(luò)環(huán)境有多差，消息會(huì)在24小時(shí)內(nèi)到達(dá)，根據(jù)這樣的經(jīng)驗(yàn)，將消息存儲(chǔ)周期(它是一個(gè)可變的時(shí)間周期)設(shè)置為24小時(shí)。
消息處理模塊332包含用于執(zhí)行如下步驟的指令確定終端是處于自動(dòng)模式還是處于延遲模式；如果該終端處于自動(dòng)模式，則發(fā)送MM請(qǐng)求消息GetReq以及如果該終端處于延遲模式，則發(fā)送響應(yīng)消息M-NotifyResp.ind。對(duì)于所有的通知消息，消息處理模塊332都會(huì)響應(yīng)于MMS服務(wù)器，因?yàn)樗⒉淮_定接收到的通知消息是否是完全一樣的消息。
在下文中，將參照?qǐng)D7到9來(lái)描述當(dāng)處于自動(dòng)模式中的終端接收到完全一樣的通知消息時(shí)的消息處理方法。
圖7示出了第一種接收完全一樣的通知消息的情況以及根據(jù)本發(fā)明的消息處理方法。已接收到來(lái)自發(fā)送方終端(未示出)的多媒體消息的MMS服務(wù)器100向接收方終端200發(fā)送Noti1(M-Notification.ind)(S301)。接下來(lái)，接收方終端200向MMS服務(wù)器100發(fā)送多媒體請(qǐng)求消息GetReq1(S302)。然而，如果GetReq1丟失了并且沒(méi)有到達(dá)MMS服務(wù)器100，并且重試周期已經(jīng)過(guò)去，則MMS服務(wù)器100向接收方終端200重新發(fā)送通知消息Noti2(S303)。已接收到Noti2的接收方終端200改變通知消息的修改時(shí)間(S304)，并且將GetReq2發(fā)送給MMS服務(wù)器100(S305)。
盡管接收方終端200已經(jīng)向MMS服務(wù)器100發(fā)送了MM請(qǐng)求消息GetReq1，但是MMS服務(wù)器100沒(méi)有接收到。因此，接收方終端200連續(xù)地接收到完全一樣的通知消息，除非它因通知消息的完全一樣而向MMS服務(wù)器100發(fā)送GetReq1。因此，接收方終端200也針對(duì)完全一樣的通知消息發(fā)送GetReq。
圖8示出了第二種接收到完全一樣的通知消息的情況以及根據(jù)本發(fā)明的消息處理方法。當(dāng)接收方終端200接收來(lái)自MMS服務(wù)器100的通知消息Noti1時(shí)，接收方終端200向MMS服務(wù)器100發(fā)送MM請(qǐng)求消息GetReq1(S402)。同時(shí)，因?yàn)镸MS服務(wù)器100在發(fā)送Noti1之后的重試周期內(nèi)沒(méi)有接收到GetReq1，所以MMS服務(wù)器100發(fā)送Noti2(S403)。因此，接收方終端200接收到完全一樣的通知消息Noti2，并且因?yàn)榻邮辗浇K端200尚未接收到多媒體消息M-retrieve.conf，所以只改變?cè)撏ㄖ⒌慕邮諘r(shí)間(S404)。之后，接收方終端200向MMS服務(wù)器100重新發(fā)送多媒體請(qǐng)求消息(S405)，這不會(huì)引起任何問(wèn)題，因?yàn)镸MS服務(wù)器100在執(zhí)行TID比較之后忽略了完全一樣的多媒體請(qǐng)求消息。因此，接收方終端200只接收針對(duì)GetReq1的多媒體消息M-retrieve.conf(S406)。
對(duì)于第二種情況，已接收到完全一樣的通知消息的接收方終端200基本上無(wú)需向MMS服務(wù)器100發(fā)送MM請(qǐng)求消息GetReq1。然而，既然接收方終端200因GetReq1丟失了而無(wú)法知道MMS服務(wù)器是否發(fā)送了完全一樣的通知消息，或者因?yàn)镚etReq1到達(dá)得比預(yù)期要晚(在重試周期之后)而使MMS服務(wù)器100又發(fā)送了完全一樣的通知消息，那么接收方終端200在接收到Noti2時(shí)無(wú)條件地向MMS服務(wù)器100發(fā)送多媒體請(qǐng)求消息。即，接收方終端200處理第一種情況和第二種情況的方式相同。
圖9示出了第三種接收完全一樣的通知消息的情況以及根據(jù)本發(fā)明的消息處理方法。當(dāng)接收方終端200接收到通知消息Noti1時(shí)(S501)，它向MMS服務(wù)器發(fā)送MM消息GetReq1(S502)。同時(shí)，在重試周期內(nèi)沒(méi)有接收到GetReq1的MMS服務(wù)器100向接收方終端200重新發(fā)送通知消息(S503)。接下來(lái)，當(dāng)MMS服務(wù)器100接收到GetReq1時(shí)，它向接收方終端200發(fā)送多媒體消息M-retrieve.conf(S504)。
至此，接收方終端200在接收到多媒體消息M-retrieve.conf之后又接收到完全一樣的通知消息Noti2，并且立刻刪除該完全一樣的通知消息Noti2而不加存儲(chǔ)(S505)。可以看到Noti2是完全一樣的消息，因?yàn)榧词苟嗝襟w消息已經(jīng)下載好了，Noti1也尚未刪除。
如果接收方終端200在下載好多媒體消息之后又接收到完全一樣的通知消息，則盡管沒(méi)必要發(fā)送MM請(qǐng)求消息GetReq，但是仍可以發(fā)送GetReq。這是因?yàn)镸MS服務(wù)器100在接收到完全一樣的MM請(qǐng)求消息時(shí)會(huì)立刻將其刪除，并且并不會(huì)發(fā)送相同的多媒體消息。
如上所述，根據(jù)本發(fā)明的終端的優(yōu)點(diǎn)在于，響應(yīng)是針對(duì)完全一樣的通知消息和新的通知消息而發(fā)送的，所以沒(méi)有任何不需要的完全一樣的消息被重復(fù)接收。此外，根據(jù)本發(fā)明的終端并不接收不需要的完全一樣的通知消息，由此防止由重復(fù)接收和刪除不需要的消息而導(dǎo)致的電池消耗。
此外，該終端在下載好多媒體消息之后并不刪除通知消息，而是將該通知消息存儲(chǔ)一預(yù)定的時(shí)間周期。因此，可以看到，如果該終端在下載好多媒體消息之后又接收到與先前存儲(chǔ)的通知消息相同的通知消息，則該消息是完全一樣的通知消息。因此，有可能解決為相同的多媒體消息重復(fù)付費(fèi)的問(wèn)題，該問(wèn)題由多媒體消息下載好之后將接收到的完全一樣的通知消息識(shí)別為新的通知消息而引起。
權(quán)利要求
1.一種用在支持多媒體消息傳送服務(wù)(MMS)的終端中的消息處理方法，包括接收來(lái)自服務(wù)器的通知消息，所述通知消息用于通知已接收到多媒體消息；當(dāng)所述通知消息被確定為完全一樣的通知消息時(shí)，根據(jù)與所述通知消息相對(duì)應(yīng)的多媒體消息是否被下載來(lái)刪除所述通知消息；以及當(dāng)所述通知消息沒(méi)有被確定為完全一樣的通知消息時(shí)，發(fā)送所述通知消息的響應(yīng)消息和多媒體消息的請(qǐng)求消息之一。
2.如權(quán)利要求1所述的方法，其特征在于，所述刪除通知消息的步驟還包括如下步驟發(fā)送所述通知消息的響應(yīng)消息或用于請(qǐng)求多媒體消息的消息。
3.如權(quán)利要求1所述的方法，其特征在于，所述刪除通知消息的步驟還包括如下步驟如果與所述完全一樣的通知消息相對(duì)應(yīng)的多媒體消息尚未被下載，則改變所述通知消息的接收時(shí)間。
4.如權(quán)利要求1所述的方法，還包括如下步驟除非所述通知消息是完全一樣的消息，否則存儲(chǔ)所述通知消息。
5.如權(quán)利要求4所述的方法，還包括如下步驟將消息到達(dá)所用的最大時(shí)間周期設(shè)置為最大到達(dá)時(shí)間；以及在所存儲(chǔ)的通知消息中，刪除其最大到達(dá)時(shí)間已經(jīng)過(guò)了的消息。
6.如權(quán)利要求5所述的方法，其特征在于，所述刪除步驟是在空閑模式中執(zhí)行的。
7.如權(quán)利要求5所述的方法，其特征在于，所述刪除步驟是在啟動(dòng)所述終端時(shí)執(zhí)行的。
8.如權(quán)利要求1所述的方法，還包括如下步驟將消息到達(dá)所用的最大時(shí)間周期設(shè)置為最大到達(dá)時(shí)間；以及除非所述通知消息是完全一樣的消息，否則在所述最大到達(dá)時(shí)間期間存儲(chǔ)著所述通知消息。
9.如權(quán)利要求1所述的方法，還包括如下步驟如果所述通知消息的交易標(biāo)識(shí)符與所述終端中所存儲(chǔ)的另一個(gè)通知消息的交易標(biāo)識(shí)符相同，則將所述通知消息確定為完全一樣的通知消息。
10.一種用于提供多媒體消息傳送服務(wù)(MMS)的方法，包括如下步驟服務(wù)器向終端發(fā)送第一通知消息，從而通知已接收到多媒體消息；所述終端向所述服務(wù)器發(fā)送針對(duì)所述第一通知消息的響應(yīng)；除非所述服務(wù)器在重試周期內(nèi)接收到所述響應(yīng)，否則就向所述終端重新發(fā)送第二通知消息；如果所述終端在下載所述多媒體消息之后接收到所述第二通知消息，則用所述第二通知消息來(lái)替代所述第一通知消息；以及所述終端向所述服務(wù)器發(fā)送針對(duì)所述第二通知消息的響應(yīng)。
11.如權(quán)利要求10所述的方法，其特征在于，在替代步驟中，所述第一通知消息的接收時(shí)間被所述第二通知消息的接收時(shí)間所替代。
12.如權(quán)利要求10所述的方法，其特征在于，如果所述終端處于自動(dòng)檢索模式，則針對(duì)所述通知消息的響應(yīng)就是用于請(qǐng)求多媒體消息的消息。
13.如權(quán)利要求10所述的方法，其特征在于，如果所述終端處于延遲檢索模式，則針對(duì)所述通知消息的響應(yīng)就是針對(duì)所述通知消息的接收確認(rèn)消息。
14.如權(quán)利要求10所述的方法，還包括如下步驟在消息到達(dá)的最大時(shí)間周期期間，所述終端存儲(chǔ)著所述第一通知消息。
15.如權(quán)利要求10所述的方法，還包括如下步驟如果所述終端在下載所述多媒體消息之后接收到所述第二通知消息，則刪除所述第二通知消息。
16.一種終端，包括接收器，用于接收通知消息，所述通知消息用于通知有多媒體消息到達(dá)；數(shù)據(jù)庫(kù)管理模塊，所述數(shù)據(jù)庫(kù)管理模塊根據(jù)所述接收到的通知消息是否是完全一樣的消息以及所述多媒體消息是否已經(jīng)被下載，來(lái)管理所述通知消息的刪除和存儲(chǔ)；數(shù)據(jù)庫(kù)，所述數(shù)據(jù)庫(kù)根據(jù)來(lái)自所述數(shù)據(jù)庫(kù)管理模塊的指令，來(lái)存儲(chǔ)所述通知消息；存儲(chǔ)器，所述存儲(chǔ)器具有消息處理模塊，所述消息處理模塊用于提供針對(duì)所述接收到的通知消息的響應(yīng)；以及處理器，所述處理器用于與所述接收器和所述存儲(chǔ)器合作來(lái)處理消息。
17.如權(quán)利要求16所述的方法，其特征在于，所述數(shù)據(jù)庫(kù)管理模塊包含所述處理器執(zhí)行如下步驟所需的指令如果所述接收到的消息是完全一樣的消息，則當(dāng)所述多媒體已經(jīng)被下載時(shí)刪除所述通知消息；以及當(dāng)多媒體消息尚未被下載時(shí)，用新接收到的通知消息來(lái)替代現(xiàn)存的通知消息。
18.如權(quán)利要求16所述的方法，其特征在于，所述數(shù)據(jù)庫(kù)管理模塊包含所述處理器執(zhí)行如下步驟所需的指令如果所述接收到的通知消息不是完全一樣的消息，則將所述通知消息存儲(chǔ)到所述數(shù)據(jù)庫(kù)中。
19.如權(quán)利要求16所述的方法，其特征在于，所述數(shù)據(jù)庫(kù)管理模塊包含所述處理器執(zhí)行如下步驟所需的指令如果具有與所述接收到的通知消息相同的交易標(biāo)識(shí)符的通知消息被存儲(chǔ)到所述數(shù)據(jù)庫(kù)中，則確定完全一樣的消息被接收到了。
20.如權(quán)利要求16所述的方法，其特征在于，所述消息處理模塊包括所述處理器執(zhí)行如下步驟所需的指令不管所述接收到的通知消息是否是完全一樣的通知消息，都提供針對(duì)所述通知消息的響應(yīng)。
全文摘要
揭示了一種終端中完全一樣的通知消息的處理方法。該方法包括接收來(lái)自MMS服務(wù)器的通知消息，該通知消息用于通知多媒體消息的接收情況；當(dāng)該通知消息被確定為完全一樣的通知消息時(shí)，根據(jù)與該通知消息相對(duì)應(yīng)的多媒體消息是否被下載來(lái)刪除該通知消息；以及當(dāng)該通知消息不是完全一樣的通知消息時(shí)，發(fā)送該通知消息的響應(yīng)消息和多媒體消息的請(qǐng)求消息之一。
文檔編號(hào)H04M3/42GK1960516SQ20061014338
公開(kāi)日2007年5月9日 申請(qǐng)日期2006年11月2日 優(yōu)先權(quán)日2005年11月2日
發(fā)明者裴范奭 申請(qǐng)人:Lg電子株式會(huì)社