專利名稱：取消已發(fā)彩信的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及無線通信的多媒體彩信應(yīng)用領(lǐng)域，特別涉及取消已發(fā)彩 信的方法。
背景技術(shù)：
隨著無線通信技術(shù)的發(fā)展，如今人們已經(jīng)可以通過發(fā)送彩信來互相
傳遞和共享圖片，音視頻等多種媒體。彩信的傳輸承載在HTTP或WSP上， 包括消息頭和消息體。網(wǎng)絡(luò)中的實(shí)體通過解析彩信消息頭中的信息來控 制彩信的發(fā)送和接收，消息體中則包含了用戶通過彩信傳輸?shù)膬?nèi)容。在 OMA和3GPP規(guī)范中，彩信技術(shù)已經(jīng)定義了一些頭部的消息域，可以實(shí) 現(xiàn)定時(shí)，轉(zhuǎn)發(fā)，閱讀報(bào)告等多種特殊功能。
一個(gè)基本的彩信業(yè)務(wù)系統(tǒng)如附圖2所示，在現(xiàn)有的系統(tǒng)中，網(wǎng)絡(luò)側(cè)的 彩信中心通過代理和存儲(chǔ)服務(wù)器采用存儲(chǔ)-轉(zhuǎn)發(fā)機(jī)制來傳輸彩信數(shù)據(jù)。當(dāng) 一個(gè)用戶發(fā)送一條彩信后，如果這條彩信是定時(shí)彩信，將被暫存在源端 代理存儲(chǔ)服務(wù)器上，當(dāng)定時(shí)結(jié)束或是普通的彩信時(shí)，源端代理存儲(chǔ)服務(wù) 器將彩信轉(zhuǎn)發(fā)到目標(biāo)端代理存儲(chǔ)服務(wù)器存儲(chǔ)。接收終端在收到從目標(biāo)端 代理存儲(chǔ)服務(wù)器發(fā)來的一條Push通知消息后，將自動(dòng)或手動(dòng)地從目標(biāo)端 服務(wù)器下載該彩
盡管目前OMA規(guī)范中己經(jīng)定義了相當(dāng)多的彩信特殊功能，但是對(duì)用 戶比較常用的一種彩信取消功能卻尚未被定義和實(shí)現(xiàn)?？梢栽O(shè)想如下的 場景，用戶可能會(huì)在發(fā)送出一條彩信之后才發(fā)現(xiàn)自己的編輯有誤，或是 后悔不該發(fā)送這條彩信給對(duì)方，而在目前的彩信應(yīng)用中，用戶是無法將 已發(fā)出的彩信取消掉的。在某些情況下，這很可能會(huì)給用戶帶來一定的 困擾和麻煩。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種取消已發(fā)彩信的方法。 為實(shí)現(xiàn)上述目的， 一種取消已發(fā)彩信的方法，包括步驟 用戶發(fā)出一條彩信，然后發(fā)出取消請(qǐng)求到源端服務(wù)器； 源端服務(wù)器在彩信未被轉(zhuǎn)發(fā)之前對(duì)存儲(chǔ)的彩信執(zhí)行刪除并返回結(jié)
果；
如果彩信已被源端服務(wù)器轉(zhuǎn)發(fā)到目標(biāo)端服務(wù)器，則源端服務(wù)器轉(zhuǎn)發(fā) 取消請(qǐng)求到目標(biāo)端服務(wù)器；
目標(biāo)端服務(wù)器在彩信未被下載之前對(duì)存儲(chǔ)的彩信執(zhí)行刪除并返回結(jié)
果；
如果彩信已被下載到接收終端，目標(biāo)端服務(wù)器發(fā)送取消請(qǐng)求到接收 終端；
接收終端對(duì)存儲(chǔ)的所述彩信執(zhí)行刪除或由用戶決定是否刪除并返回 結(jié)果。
本發(fā)明給出了一種新的取消已發(fā)彩信業(yè)務(wù)的實(shí)現(xiàn)方法，可以幫助用 戶取消掉他發(fā)錯(cuò)或后悔發(fā)出的彩信，主要是通過源端和目標(biāo)端的彩信終 端和服務(wù)器之間的消息交互來實(shí)現(xiàn)的。這個(gè)新型的彩信功能為用戶提供 了可在任意時(shí)刻取消已發(fā)彩信的途徑，滿足了用戶一定的需求。作為一 個(gè)可選功能使現(xiàn)有的彩信業(yè)務(wù)更加完善，并且與現(xiàn)有彩信規(guī)范和業(yè)務(wù)兼 容。


圖l是本發(fā)明的一個(gè)完整實(shí)施流程；
圖2是一個(gè)現(xiàn)有的彩信業(yè)務(wù)的網(wǎng)絡(luò)結(jié)構(gòu)；
圖3是本發(fā)明中新定義的消息M-Recall.req的包頭結(jié)構(gòu)；
圖4是本發(fā)明中新定義的消息M-Recall.con飾包頭結(jié)構(gòu)；
圖5是源端代理存儲(chǔ)服務(wù)器彩信取消的流程；
圖6是目標(biāo)端代理存儲(chǔ)服務(wù)器彩信取消的流程； 圖7是接收終端彩信取消的流程；
圖8是發(fā)送終端上的彩信取消菜單示意圖。
具體實(shí)施例方式
本發(fā)明中的彩信取消方法可以作為現(xiàn)有彩信系統(tǒng)的一個(gè)可選功能。
所增加的消息主要是應(yīng)用層上一個(gè)新的MMS PDU消息對(duì)，負(fù)責(zé)承載發(fā)送
方用戶的取消通知。此外，彩信終端和服務(wù)器也需要對(duì)該消息組裝或解 析并執(zhí)行相應(yīng)的處理。其中，發(fā)送終端需要為用戶增加相關(guān)的彩信取消 界面操作，而源端和目標(biāo)端代理服務(wù)器需要能夠解析和構(gòu)建本專利中定 義的新的彩信消息，并能刪除存儲(chǔ)在服務(wù)器上的彩信。具體實(shí)現(xiàn)方法如
下
(1) 界面設(shè)計(jì)
發(fā)送終端需要提供對(duì)應(yīng)的操作菜單或軟鍵控件給用戶選擇取消哪條
已發(fā)的彩信。例如，如附圖8所示，當(dāng)一條彩信被成功發(fā)出后，可能會(huì)被 存儲(chǔ)在本地的己發(fā)件箱(Sentbox)，這時(shí)發(fā)件箱的菜單可以激活一個(gè)選項(xiàng) 如"取消(Recall)"來供用戶發(fā)起取消操作，當(dāng)網(wǎng)絡(luò)側(cè)取消操作執(zhí)行成 功后，發(fā)件箱中的彩信可以被刪除，并且不能再發(fā)起一次取消請(qǐng)求。
發(fā)送終端需要能夠存儲(chǔ)已發(fā)送彩信的Message ID，這是由源端服務(wù) 器生成并加入到發(fā)送響應(yīng)M-Send.conf消息中返回的。在發(fā)起彩信取消請(qǐng) 求時(shí)，發(fā)送終端應(yīng)該將這個(gè)ID插入到取消請(qǐng)求中，用以通知服務(wù)器待取 消彩信的ID。
(2) 消息結(jié)構(gòu)
在現(xiàn)有的彩信傳輸消息基礎(chǔ)上，在發(fā)送終端和源端代理服務(wù)器間構(gòu) 建一對(duì)新的MMSPDU消息對(duì)，M-Recall.req和M-Recall.conf，負(fù)責(zé)傳輸 彩信取消請(qǐng)求并返回響應(yīng)。這對(duì)新PDU的包頭結(jié)構(gòu)見附圖3和附圖4。其 中，在M-Recall.req中的X-Mms-Recall-ID域等價(jià)于待取消彩信的Message ID。該ID與該彩信發(fā)送時(shí)響應(yīng)消息M-Send.conf中的MessageID相同，也 具有相同的格式，以此來標(biāo)識(shí)待取消的彩信。
在M-Recall.conf中包含了服務(wù)器返回的取消響應(yīng)狀態(tài)域。X-Mms-Response-Status以及對(duì)應(yīng)文本域X-Mms-Response-Text，用 于表示取消操作的結(jié)果。其狀態(tài)值與M-Delete.ccmf中的具有類似的格式， 定義如下Response-status-Rec-value = Value-length Status-count-value Response-status-vdu6
Response-text-Rec隱value = Value-length Status-count-value Response-text-value
其中Response-status-value代表了狀態(tài)值，Response-text-value代表了對(duì) 應(yīng)文本。二者的詳細(xì)內(nèi)容請(qǐng)參見OMA MMS Encapsulation Protocol規(guī)范 的7.3.48， 7.3.49以及9.1節(jié)。其在M-Recall.conf中的用法類似于M-Delete.conf。
M-Recall.req和M-Recall.conf必須具有統(tǒng)一的Transaction ID，以此來標(biāo)識(shí)這是一對(duì)請(qǐng)求及響應(yīng)。對(duì)于暫時(shí)性的請(qǐng)求失敗，發(fā)送終端之后應(yīng)該 嘗試重傳相應(yīng)的M-Recall.req，并保持Transaction ID不變。對(duì)于永久性的 請(qǐng)求失敗，發(fā)送終端不用重傳取消請(qǐng)求，返回的M-Recall.conf中的狀態(tài) 文本域可以為終端用戶提供錯(cuò)誤原因。
此外，在源端和目標(biāo)端代理服務(wù)器間，需要定義另一對(duì)請(qǐng)求響應(yīng)消 息來通知目標(biāo)端服務(wù)器執(zhí)行相應(yīng)的取消操作。遵循3GPP中對(duì)代理服務(wù)器 間通信的規(guī)范，定義MM4—recall.REQ和MM4—recall.RES兩個(gè)消息，并且 包含與M-Recall.req和M-Recall.con湘同的內(nèi)容。其中，源端服務(wù)器在發(fā) 現(xiàn)彩信已經(jīng)轉(zhuǎn)發(fā)到目標(biāo)端后，將發(fā)送MM4jecall.REQ請(qǐng)求到目標(biāo)端代理 服務(wù)器，并由目標(biāo)端服務(wù)器處理后返回相應(yīng)的MM4—recall.RES響應(yīng)，然 后由源端服務(wù)器返回相應(yīng)的M-Recall.conf。
(3)取消操作
由于發(fā)出的彩信可能存儲(chǔ)在源端服務(wù)器，目標(biāo)端服務(wù)器以及接收終 端上面，因此下面需要分三種情形討論，對(duì)于不同的存儲(chǔ)點(diǎn)，應(yīng)該如何 操作來取消彩信
1)在源端服務(wù)器取消彩信。如果發(fā)送的是定時(shí)彩信，將會(huì)在源端服 務(wù)器上存儲(chǔ)到設(shè)定時(shí)間后再被發(fā)出，因此這種情況下源端服務(wù)器有一定 的時(shí)間來取消暫存的彩信。如果源端服務(wù)器支持本專利提出的取消功能， 并且待取消彩信還未被轉(zhuǎn)發(fā)，它需要能夠識(shí)別上述新加的消息對(duì)并執(zhí)行 相應(yīng)的操作來刪除用戶想取消的彩信。如附圖5所示，流程如下 101.發(fā)送取消請(qǐng)求
首先用戶已經(jīng)發(fā)出一條定時(shí)彩信并暫存在源端服務(wù)器上，然后發(fā)送
終端發(fā)出取消請(qǐng)求M-Recall.req到源端代理服務(wù)器，攜帶待取消彩信的 ID。
102.服務(wù)器是否支持
源端服務(wù)器檢測是否支持取消業(yè)務(wù)，如果不支持，則返回unsupported 響應(yīng)。如果源端服務(wù)器支持取消業(yè)務(wù)，則在存儲(chǔ)彩信的服務(wù)器上根據(jù)M-Recall.req中的Recall ID檢索該彩信，并返回結(jié)果。
103.是否找到彩信
如果待取消彩信已經(jīng)超時(shí)被轉(zhuǎn)發(fā)到目標(biāo)端，則源端服務(wù)器構(gòu)建 MM4一recall.REQ請(qǐng)求發(fā)送至目標(biāo)端代理服務(wù)器。如果待取消彩信被找 到，則服務(wù)器開始嘗試刪除。 104.是否刪除成功
如果待取消彩信被成功刪除，則返回ok的響應(yīng)，否則返回失敗的響應(yīng)。2)在目標(biāo)端服務(wù)器取消彩信。如果彩信已經(jīng)被發(fā)送到目標(biāo)端服務(wù)器，并 且目標(biāo)端服務(wù)器接收到MM4—recall.REQ請(qǐng)求，則目標(biāo)端服務(wù)器將執(zhí)行彩 信取消操作。這將依賴于待取消彩信是否已經(jīng)被接收終端下載。如果已 經(jīng)下載，則目標(biāo)端服務(wù)器需要通知接收終端來執(zhí)行刪除操作，如果待取 消彩信還沒有被下載到接收終端，則由目標(biāo)端服務(wù)器負(fù)責(zé)刪除暫存的彩 信。如附圖6所示，流程如下
201. 源端轉(zhuǎn)發(fā)取消請(qǐng)求 取消請(qǐng)求由源端轉(zhuǎn)發(fā)至目標(biāo)端服務(wù)器，攜帶待取消彩信的ID。
202. 服務(wù)器是否支持 目標(biāo)端服務(wù)器檢測是否支持取消業(yè)務(wù)，如果不支持，則返回
unsupported響應(yīng)。如果目標(biāo)端服務(wù)器支持取消業(yè)務(wù)，則在存儲(chǔ)彩信的服 務(wù)器上根據(jù)轉(zhuǎn)發(fā)請(qǐng)求中的ID檢索該彩信，并返回結(jié)果。
203. 是否找到彩信 如果待取消彩信已經(jīng)被接收終端下載，則目標(biāo)端服務(wù)器構(gòu)建M-Cancel.r叫(現(xiàn)有消息， 目標(biāo)端服務(wù)器將把從MM4—recall.REQ中獲得的ID 放入M—Cancel.req頭中的X-Mms-Cancel-ID項(xiàng)，并把Mj^ancel.conf中的返
回狀態(tài)值放入到MM4—recall.RES中的對(duì)應(yīng)域)請(qǐng)求發(fā)送至接收終端。如果 待取消彩信被找到，則服務(wù)器開始嘗試刪除。 204.是否刪除成功
如果待取消彩信被成功刪除，則返回ok的響應(yīng)，否則返回失敗的響 應(yīng)回源端服務(wù)器。
3)在接收終端取消彩信。如果彩信已經(jīng)被下載到接收終端，并且接收到 由目標(biāo)端服務(wù)器發(fā)來的M—Cancel.req，接收終端將根據(jù)其中的ID刪除之 前收到的彩信。當(dāng)然，作為一個(gè)可選功能，接收終端也可以讓用戶決定 是否禁止這一操作。如果取消操作被禁止，則返回失敗的響應(yīng)。刪除成 功后，接收終端返回M—Cancel.con佳ij目標(biāo)端服務(wù)器，然后再轉(zhuǎn)發(fā)到源端 服務(wù)器及發(fā)送終端。如附圖7所示，流程如下
301. 目標(biāo)端服務(wù)器發(fā)起取消請(qǐng)求
目標(biāo)端服務(wù)器發(fā)送M-Cancel.req至接收終端，在X-Mms-Cancel-ID 域中攜帶待取消彩信的1D。
302. 接收終端是否支持 接收終端檢測是否支持取消業(yè)務(wù)，如果不支持，比如接收端用戶禁
止這樣的操作，則返回Corrupted響應(yīng)。如果接收終端支持取消業(yè)務(wù)，則 在接收終端上根據(jù)轉(zhuǎn)發(fā)請(qǐng)求中的ID檢索該彩信并刪除，并返回結(jié)果。
303. 是否刪除成功
如果待取消彩信被成功找到并刪除，則返回ok的響應(yīng)，否則如果沒 有找到或刪除失敗則返回失敗的響應(yīng)回目標(biāo)端服務(wù)器。
整個(gè)彩信取消的流程如附圖1所示，包括了以上三種情況的消息傳 輸和處理。
下面給出一個(gè)在源端服務(wù)器上取消彩信的實(shí)施例的流程 假設(shè)用戶終端及網(wǎng)絡(luò)側(cè)的彩信中心服務(wù)器都支持本專利發(fā)明中的彩 信取消功能及消息，并且用戶已發(fā)出一條定時(shí)彩信到源端服務(wù)器上，并 設(shè)定1小時(shí)后發(fā)出。但是半小時(shí)后用戶后悔想取消該已發(fā)出的彩信。因此， 他通過終端界面上的已發(fā)件箱菜單發(fā)出取消請(qǐng)求。源端服務(wù)器接收到M-Recall.req請(qǐng)求后査找到該彩信并刪除成功，返回M-Recall.con徊發(fā)送終 端。這樣就完成了一個(gè)已發(fā)彩信的取消。
下面給出一個(gè)在目標(biāo)端服務(wù)器上取消彩信的實(shí)施例的流程 假設(shè)用戶終端及網(wǎng)絡(luò)側(cè)的彩信中心服務(wù)器都支持本專利發(fā)明中的彩 信取消功能及消息，并且用戶已發(fā)出一條彩信到源端服務(wù)器上并轉(zhuǎn)發(fā)至 目標(biāo)端服務(wù)器，但接收端用戶并沒有立即下載該彩信，這時(shí)發(fā)送端用戶 后悔想取消該已發(fā)出的彩信。因此，他通過終端界面上的已發(fā)件箱菜單
發(fā)出取消請(qǐng)求。源端服務(wù)器接收到M-Recan.req請(qǐng)求后査找到該彩信己 被轉(zhuǎn)發(fā)，因此發(fā)出MM4—recall.REQ到目標(biāo)端服務(wù)器。目標(biāo)端服務(wù)器查找 到該彩信并刪除成功，返回MM4一recall.RES至源端服務(wù)器，然后再返回 M-Recall.conf至發(fā)送終端。這樣就完成了一個(gè)已發(fā)彩信的取消。 下面給出一個(gè)在接收終端上取消彩信的實(shí)施例的流程 假設(shè)用戶終端及網(wǎng)絡(luò)側(cè)的彩信中心服務(wù)器都支持本專利發(fā)明中的彩 信取消功能及消息，并且用戶已發(fā)出一條彩信到源端服務(wù)器上并轉(zhuǎn)發(fā)至 目標(biāo)端服務(wù)器，接收端用戶立即下載了該彩信并且終端設(shè)定為允許網(wǎng)絡(luò) 側(cè)刪除本地的彩信，這時(shí)發(fā)送端用戶想取消該已發(fā)出的彩信。因此，他 通過終端界面上的己發(fā)件箱菜單發(fā)出取消請(qǐng)求。源端服務(wù)器接收到M-Recall.req請(qǐng)求后查找到該彩信己被轉(zhuǎn)發(fā)，因此發(fā)出MM4—recall.REQ到 目標(biāo)端服務(wù)器。目標(biāo)端服務(wù)器查找到該彩信已被下載，就發(fā)出M-Cancel.req至接收終端，接收終端找到該彩信并刪除成功，返回M-Cancel.conf至目標(biāo)端服務(wù)器，目標(biāo)端服務(wù)器返回MM4—recall.RES至源 端服務(wù)器，然后再返回M-Recall.conf至發(fā)送終端。這樣就完成了一個(gè)已 發(fā)彩信的取消。
權(quán)利要求
1.一種取消已發(fā)彩信的方法，包括步驟用戶發(fā)出一條彩信，然后發(fā)出取消請(qǐng)求到源端服務(wù)器；源端服務(wù)器在彩信未被轉(zhuǎn)發(fā)之前對(duì)存儲(chǔ)的彩信執(zhí)行刪除并返回結(jié)果；如果彩信已被源端服務(wù)器轉(zhuǎn)發(fā)到目標(biāo)端服務(wù)器，則源端服務(wù)器轉(zhuǎn)發(fā)取消請(qǐng)求到目標(biāo)端服務(wù)器；目標(biāo)端服務(wù)器在彩信未被下載之前對(duì)存儲(chǔ)的彩信執(zhí)行刪除并返回結(jié)果；如果彩信已被下載到接收終端，目標(biāo)端服務(wù)器發(fā)送取消請(qǐng)求到接收終端；接收終端對(duì)存儲(chǔ)的所述彩信執(zhí)行刪除或由用戶決定是否刪除并返回結(jié)果。
2. 根據(jù)權(quán)利要求l所述的方法，其特征在于所述發(fā)送終端包括操作菜單 或軟鍵控件。
3. 根據(jù)權(quán)利要求l所述的方法，其特征在于所述發(fā)送終端存儲(chǔ)已發(fā)送彩 信的Message ID。
4. 根據(jù)權(quán)利要求l所述的方法，其特征在于所述發(fā)送終端和源端服務(wù)器 之間有一7寸消息，M-Recall.req和M-Recall.conf。
5. 根據(jù)權(quán)利要求l所述的方法，其特征在于所述源端服務(wù)器和目標(biāo)端服 務(wù)器之間有一對(duì)消息，MM4—recall.REQ和MM4—recall.RES。
6. 根據(jù)權(quán)利要求4或5所述的方法，其特征在于所述消息MM4一recall.REQ 和MM4—recall.RES與消息M-RecalLreq和M-Recall.conf具有相同的內(nèi)容。
7. 根據(jù)權(quán)利要求4或5所述的方法，其特征在于所述消息對(duì)具有統(tǒng)一的 Transaction ID 。
8. 根據(jù)權(quán)利要求l所述的方法，其特征在于所述源端服務(wù)器或目標(biāo)端服 務(wù)器根據(jù)收到的取消請(qǐng)求刪除已存儲(chǔ)的彩信。
全文摘要
一種取消已發(fā)彩信的方法，包括步驟用戶發(fā)出一條彩信，然后發(fā)出取消請(qǐng)求到源端服務(wù)器；源端服務(wù)器在彩信未被轉(zhuǎn)發(fā)之前對(duì)存儲(chǔ)的彩信執(zhí)行刪除并返回結(jié)果；如果彩信已被源端服務(wù)器轉(zhuǎn)發(fā)到目標(biāo)端服務(wù)器，則源端服務(wù)器轉(zhuǎn)發(fā)取消請(qǐng)求到目標(biāo)端服務(wù)器；目標(biāo)端服務(wù)器在彩信未被下載之前對(duì)存儲(chǔ)的彩信執(zhí)行刪除并返回結(jié)果；如果彩信已被下載到接收終端，目標(biāo)端服務(wù)器發(fā)送取消請(qǐng)求到接收終端；接收終端對(duì)存儲(chǔ)的所述彩信執(zhí)行刪除或由用戶決定是否刪除并返回結(jié)果。本發(fā)明為用戶提供了可在任意時(shí)刻取消已發(fā)彩信的途徑，滿足了用戶一定的需求。作為一個(gè)可選功能使現(xiàn)有的彩信業(yè)務(wù)更加完善，并且與現(xiàn)有彩信規(guī)范和業(yè)務(wù)兼容。
文檔編號(hào)H04W8/22GK101193334SQ20061014560
公開日2008年6月4日 申請(qǐng)日期2006年11月22日 優(yōu)先權(quán)日2006年11月22日
發(fā)明者濤 曾 申請(qǐng)人:北京三星通信技術(shù)研究有限公司;三星電子株式會(huì)社