CN101193334A - 取消已发彩信的方法 - Google Patents

Abstract

一种取消已发彩信的方法，包括步骤：用户发出一条彩信，然后发出取消请求到源端服务器；源端服务器在彩信未被转发之前对存储的彩信执行删除并返回结果；如果彩信已被源端服务器转发到目标端服务器，则源端服务器转发取消请求到目标端服务器；目标端服务器在彩信未被下载之前对存储的彩信执行删除并返回结果；如果彩信已被下载到接收终端，目标端服务器发送取消请求到接收终端；接收终端对存储的所述彩信执行删除或由用户决定是否删除并返回结果。本发明为用户提供了可在任意时刻取消已发彩信的途径，满足了用户一定的需求。作为一个可选功能使现有的彩信业务更加完善，并且与现有彩信规范和业务兼容。

Description

取消已发彩信的方法

技术领域

本发明涉及无线通信的多媒体彩信应用领域，特别涉及取消已发彩信的方法。

背景技术

随着无线通信技术的发展，如今人们已经可以通过发送彩信来互相传递和共享图片，音视频等多种媒体。彩信的传输承载在HTTP或WSP上，包括消息头和消息体。网络中的实体通过解析彩信消息头中的信息来控制彩信的发送和接收，消息体中则包含了用户通过彩信传输的内容。在OMA和3GPP规范中，彩信技术已经定义了一些头部的消息域，可以实现定时，转发，阅读报告等多种特殊功能。

一个基本的彩信业务系统如附图2所示，在现有的系统中，网络侧的彩信中心通过代理和存储服务器采用存储-转发机制来传输彩信数据。当一个用户发送一条彩信后，如果这条彩信是定时彩信，将被暂存在源端代理存储服务器上，当定时结束或是普通的彩信时，源端代理存储服务器将彩信转发到目标端代理存储服务器存储。接收终端在收到从目标端代理存储服务器发来的一条Push通知消息后，将自动或手动地从目标端服务器下载该彩

尽管目前OMA规范中已经定义了相当多的彩信特殊功能，但是对用户比较常用的一种彩信取消功能却尚未被定义和实现。可以设想如下的场景，用户可能会在发送出一条彩信之后才发现自己的编辑有误，或是后悔不该发送这条彩信给对方，而在目前的彩信应用中，用户是无法将已发出的彩信取消掉的。在某些情况下，这很可能会给用户带来一定的困扰和麻烦。

发明内容

本发明的目的是提供一种取消已发彩信的方法。

为实现上述目的，一种取消已发彩信的方法，包括步骤：

用户发出一条彩信，然后发出取消请求到源端服务器；

源端服务器在彩信未被转发之前对存储的彩信执行删除并返回结果；

如果彩信已被源端服务器转发到目标端服务器，则源端服务器转发取消请求到目标端服务器；

目标端服务器在彩信未被下载之前对存储的彩信执行删除并返回结果；

如果彩信已被下载到接收终端，目标端服务器发送取消请求到接收终端；

接收终端对存储的所述彩信执行删除或由用户决定是否删除并返回结果。

本发明给出了一种新的取消已发彩信业务的实现方法，可以帮助用户取消掉他发错或后悔发出的彩信，主要是通过源端和目标端的彩信终端和服务器之间的消息交互来实现的。这个新型的彩信功能为用户提供了可在任意时刻取消已发彩信的途径，满足了用户一定的需求。作为一个可选功能使现有的彩信业务更加完善，并且与现有彩信规范和业务兼容。

附图说明

图1是本发明的一个完整实施流程；

图2是一个现有的彩信业务的网络结构；

图3是本发明中新定义的消息M-Recall.req的包头结构；

图4是本发明中新定义的消息M-Recall.conf的包头结构；

图5是源端代理存储服务器彩信取消的流程；

图6是目标端代理存储服务器彩信取消的流程；

图7是接收终端彩信取消的流程；

图8是发送终端上的彩信取消菜单示意图。

具体实施方式

本发明中的彩信取消方法可以作为现有彩信系统的一个可选功能。所增加的消息主要是应用层上一个新的MMS PDU消息对，负责承载发送方用户的取消通知。此外，彩信终端和服务器也需要对该消息组装或解析并执行相应的处理。其中，发送终端需要为用户增加相关的彩信取消界面操作，而源端和目标端代理服务器需要能够解析和构建本专利中定义的新的彩信消息，并能删除存储在服务器上的彩信。具体实现方法如下：

(1)界面设计

发送终端需要提供对应的操作菜单或软键控件给用户选择取消哪条已发的彩信。例如，如附图8所示，当一条彩信被成功发出后，可能会被存储在本地的已发件箱(Sent box)，这时发件箱的菜单可以激活一个选项如“取消(Recall)”来供用户发起取消操作，当网络侧取消操作执行成功后，发件箱中的彩信可以被删除，并且不能再发起一次取消请求。

发送终端需要能够存储已发送彩信的Message ID，这是由源端服务器生成并加入到发送响应M-Send.conf消息中返回的。在发起彩信取消请求时，发送终端应该将这个ID插入到取消请求中，用以通知服务器待取消彩信的ID。

(2)消息结构

在现有的彩信传输消息基础上，在发送终端和源端代理服务器间构建一对新的MMS PDU消息对，M-Recall.req和M-Recall.conf，负责传输彩信取消请求并返回响应。这对新PDU的包头结构见附图3和附图4。其中，在M-Recall.req中的X-Mms-Recall-ID域等价于待取消彩信的MessageID。该ID与该彩信发送时响应消息M-Send.conf中的Message ID相同，也具有相同的格式，以此来标识待取消的彩信。

在M-Recall.conf中包含了服务器返回的取消响应状态域。X-Mms-Response-Status以及对应文本域X-Mms-Response-Text，用于表示取消操作的结果。其状态值与M-Delete.conf中的具有类似的格式，定义如下：

Response-status-Rec-value＝Value-length Status-count-value Response-status-value

Response-text-Rec-value＝Value-length Status-count-value Response-text-value

其中Response-status-value代表了状态值，Response-text-value代表了对应文本。二者的详细内容请参见OMA MMS Encapsulation Protocol规范的7.3.48，7.3.49以及9.1节。其在M-Recall.conf中的用法类似于M-Delete.conf。

M-Recall.req和M-Recall.conf必须具有统一的Transaction ID，以此来标识这是一对请求及响应。对于暂时性的请求失败，发送终端之后应该尝试重传相应的M-Recall.req，并保持Transaction ID不变。对于永久性的请求失败，发送终端不用重传取消请求，返回的M-Recall.conf中的状态文本域可以为终端用户提供错误原因。

此外，在源端和目标端代理服务器间，需要定义另一对请求响应消息来通知目标端服务器执行相应的取消操作。遵循3GPP中对代理服务器间通信的规范，定义MM4_recall.REQ和MM4_recall.RES两个消息，并且包含与M-Recall.req和M-Recall.conf相同的内容。其中，源端服务器在发现彩信已经转发到目标端后，将发送MM4_recall.REQ请求到目标端代理服务器，并由目标端服务器处理后返回相应的MM4_recall.RES响应，然后由源端服务器返回相应的M-Recall.conf。

(3)取消操作

由于发出的彩信可能存储在源端服务器，目标端服务器以及接收终端上面，因此下面需要分三种情形讨论，对于不同的存储点，应该如何操作来取消彩信：

1)在源端服务器取消彩信。如果发送的是定时彩信，将会在源端服务器上存储到设定时间后再被发出，因此这种情况下源端服务器有一定的时间来取消暂存的彩信。如果源端服务器支持本专利提出的取消功能，并且待取消彩信还未被转发，它需要能够识别上述新加的消息对并执行相应的操作来删除用户想取消的彩信。如附图5所示，流程如下：

101.发送取消请求

首先用户已经发出一条定时彩信并暂存在源端服务器上，然后发送终端发出取消请求M-Recall.req到源端代理服务器，携带待取消彩信的ID。

102.服务器是否支持

源端服务器检测是否支持取消业务，如果不支持，则返回unsupported响应。如果源端服务器支持取消业务，则在存储彩信的服务器上根据M-Recall.req中的Recall ID检索该彩信，并返回结果。

103.是否找到彩信

如果待取消彩信已经超时被转发到目标端，则源端服务器构建MM4_recall.REQ请求发送至目标端代理服务器。如果待取消彩信被找到，则服务器开始尝试删除。

104.是否删除成功

如果待取消彩信被成功删除，则返回ok的响应，否则返回失败的响应。

2)在目标端服务器取消彩信。如果彩信已经被发送到目标端服务器，并且目标端服务器接收到MM4_recall.REQ请求，则目标端服务器将执行彩信取消操作。这将依赖于待取消彩信是否已经被接收终端下载。如果已经下载，则目标端服务器需要通知接收终端来执行删除操作，如果待取消彩信还没有被下载到接收终端，则由目标端服务器负责删除暂存的彩信。如附图6所示，流程如下：

201.源端转发取消请求

取消请求由源端转发至目标端服务器，携带待取消彩信的ID。

202.服务器是否支持

目标端服务器检测是否支持取消业务，如果不支持，则返回unsupported响应。如果目标端服务器支持取消业务，则在存储彩信的服务器上根据转发请求中的ID检索该彩信，并返回结果。

203.是否找到彩信

如果待取消彩信已经被接收终端下载，则目标端服务器构建M-Cancel.req(现有消息，目标端服务器将把从MM4_recall.REQ中获得的ID放入M_Cancel.req头中的X-Mms-Cancel-ID项，并把M_Cancel.conf中的返回状态值放入到MM4_recall.RES中的对应域)请求发送至接收终端。如果待取消彩信被找到，则服务器开始尝试删除。

204.是否删除成功

如果待取消彩信被成功删除，则返回ok的响应，否则返回失败的响应回源端服务器。

3)在接收终端取消彩信。如果彩信已经被下载到接收终端，并且接收到由目标端服务器发来的M_Cancel.req，接收终端将根据其中的ID删除之前收到的彩信。当然，作为一个可选功能，接收终端也可以让用户决定是否禁止这一操作。如果取消操作被禁止，则返回失败的响应。删除成功后，接收终端返回M_Cancel.conf到目标端服务器，然后再转发到源端服务器及发送终端。如附图7所示，流程如下：

301.目标端服务器发起取消请求

目标端服务器发送M-Cancel.req至接收终端，在X-Mms-Cancel-ID域中携带待取消彩信的ID。

302.接收终端是否支持

接收终端检测是否支持取消业务，如果不支持，比如接收端用户禁止这样的操作，则返回Corrupted响应。如果接收终端支持取消业务，则在接收终端上根据转发请求中的ID检索该彩信并删除，并返回结果。

303.是否删除成功

如果待取消彩信被成功找到并删除，则返回ok的响应，否则如果没有找到或删除失败则返回失败的响应回目标端服务器。

整个彩信取消的流程如附图1所示，包括了以上三种情况的消息传输和处理。

下面给出一个在源端服务器上取消彩信的实施例的流程：

假设用户终端及网络侧的彩信中心服务器都支持本专利发明中的彩信取消功能及消息，并且用户已发出一条定时彩信到源端服务器上，并设定1小时后发出。但是半小时后用户后悔想取消该已发出的彩信。因此，他通过终端界面上的已发件箱菜单发出取消请求。源端服务器接收到M-Recall.req请求后查找到该彩信并删除成功，返回M-Recall.conf回发送终端。这样就完成了一个已发彩信的取消。

下面给出一个在目标端服务器上取消彩信的实施例的流程：

假设用户终端及网络侧的彩信中心服务器都支持本专利发明中的彩信取消功能及消息，并且用户已发出一条彩信到源端服务器上并转发至目标端服务器，但接收端用户并没有立即下载该彩信，这时发送端用户后悔想取消该已发出的彩信。因此，他通过终端界面上的已发件箱菜单发出取消请求。源端服务器接收到M-Recall.req请求后查找到该彩信已被转发，因此发出MM4_recall.REQ到目标端服务器。目标端服务器查找到该彩信并删除成功，返回MM4_recall.RES至源端服务器，然后再返回M-Recall.conf至发送终端。这样就完成了一个已发彩信的取消。

下面给出一个在接收终端上取消彩信的实施例的流程：

假设用户终端及网络侧的彩信中心服务器都支持本专利发明中的彩信取消功能及消息，并且用户已发出一条彩信到源端服务器上并转发至目标端服务器，接收端用户立即下载了该彩信并且终端设定为允许网络侧删除本地的彩信，这时发送端用户想取消该已发出的彩信。因此，他通过终端界面上的已发件箱菜单发出取消请求。源端服务器接收到M-Recall.req请求后查找到该彩信已被转发，因此发出MM4_recall.REQ到目标端服务器。目标端服务器查找到该彩信已被下载，就发出M-Cancel.req至接收终端，接收终端找到该彩信并删除成功，返回M-Cancel.conf至目标端服务器，目标端服务器返回MM4_recall.RES至源端服务器，然后再返回M-Recall.conf至发送终端。这样就完成了一个已发彩信的取消。

Claims (8)

1.一种取消已发彩信的方法，包括步骤：

用户发出一条彩信，然后发出取消请求到源端服务器；

源端服务器在彩信未被转发之前对存储的彩信执行删除并返回结果；

如果彩信已被源端服务器转发到目标端服务器，则源端服务器转发取消请求到目标端服务器；

目标端服务器在彩信未被下载之前对存储的彩信执行删除并返回结果；

如果彩信已被下载到接收终端，目标端服务器发送取消请求到接收终端；

接收终端对存储的所述彩信执行删除或由用户决定是否删除并返回结果。

2.根据权利要求1所述的方法，其特征在于所述发送终端包括操作菜单或软键控件。

3.根据权利要求1所述的方法，其特征在于所述发送终端存储已发送彩信的Message ID。

4.根据权利要求1所述的方法，其特征在于所述发送终端和源端服务器之间有一对消息，M-Recall.req和M-Recall.conf。

5.根据权利要求1所述的方法，其特征在于所述源端服务器和目标端服务器之间有一对消息，MM4_recall.REQ和MM4_recall.RES。

6.根据权利要求4或5所述的方法，其特征在于所述消息MM4_recall.REQ和MM4_recall.RES与消息M-Recall.req和M-Recall.conf具有相同的内容。

7.根据权利要求4或5所述的方法，其特征在于所述消息对具有统一的Transaction ID。

8.根据权利要求1所述的方法，其特征在于所述源端服务器或目标端服务器根据收到的取消请求删除已存储的彩信。

Images