消息通知的制作方法

专利名称：消息通知的制作方法
技术领域：
本发明涉及到电信领域，且特别地涉及到消息传送(messaging)。
背景技术：
背景技术的下列描述可包括见解、发现、理解或披露、或者与与披露一起的关联， 其在本发明之前为相关技术所未知但由本发明提供。本发明的一些这样的贡献可在下面被具体地指出，而本发明的其它这样的贡献将会从它们的上下文变得显而易见。通信技术的演进，特别是基于IP的通信技术和终端用户装置，已使得能实现多用途通信可能性、以及不同服务的引入。例如，消息传送已从具有非常有限大小的文本串短消息演进为能够传递不具有大小限制的多媒体内容的各种消息传送服务。此外，消息传送可以是双向对话类型的消息传送、诸如即时消息传送或聊天，或单向消息传送、称为“单触发 (one shot)”或者“单独”消息传送。基本上差异在于在双向消息传送中，消息的接收者按近乎实时的方式接收消息；但是在单向消息传送中，接收者可按近乎实时的方式接收消息， 或者消息可暂时地存储在接收者的网络中以待稍后进行传递。消息的延迟传递的原因可以是，用户无法、或不愿意对其进行接收，即，接收者可处于离线状态或暂时失去到网络的连接、或者接收者的服务设置可指示用户在此刻不希望被打扰，由此指示例如保持(hold)消息。这样的消息在本文中称为等待消息。一些消息传送服务，诸如使用SIMPLE (用于即时消息传送和现场支持扩展的会话发起协议)的即时消息传送、或者融合(converged) IP (互联网协议)消息传送(CPM)，提供了用于传递等待消息的备选方案(alternative)。例如，取决于接收者的设置，消息特征和 /或服务供应商策略，等待消息可被自动地推送给接收者，或者接收者可接收关于等待消息的通知并且随后决定是取回(retrieve)、删除一个或多个延迟的消息或是将其存储到用户的网络存储装置。然而，问题在于，选择不同的备选方案用于通知内的不同消息，是一种迭代过程。 例如，如果用户希望在基于SIP (会话发起协议)的消息传送系统诸如CPM中删除两个等待消息并且取回一个等待消息，则用户打开通知、从待删除的通知消息进行选择，随后选择删除动作，该删除动作在用户正使用的用户装备中用触发用于延迟消息的删除功能，该删除功能关闭该通知、并且在SIP REFER请求中向地址deleteOhostname发送删除指令。随后用户再次打开通知，从通知选择待取回的(多个)消息，并且选择取回动作，取回动作在用户装备中触发用于延迟消息的取回功能，该取回功能关闭该通知、在SIP INVITE请求中向地址deferred@hostname发送取回指令。

发明内容
本发明的目的在于，使得用户能一次传送消息专用(message-specific)、很可能不同的处理指令，其中该用户已接收到关于等待消息(其被延迟或出于另一原因而等待)的通知。本发明的目的是借助于如独立权利要求中所主张的方法、设备、系统和计算机程序、以及计算机可读存储介质而实现的。本发明的优选实施例在从属权利要求中披露。优点在于，“一次”解决方案有助于使得系统的复杂度最小化，并且其可以减少系统的信令负荷。


在将参考附图更详细描述的下列不同实施例中，其中
图1示出了简化的架构，其提供了根据实施例的设备的消息传送和示意图； 图2是图示出在根据实施例的服务器中形成的通知的流程图； 图3是图示出在根据实施例的服务器中等待消息的消息处理功能的流程图； 图4是图示出在根据实施例的用户装置中的功能的流程图；以及图5和6图示出消息处理指令的实例；以及图7图示出根据实施例的信令实例。
具体实施例方式现在将会参考附图在下文中更全面地描述本发明的示例性实施例，其中示出了本发明的一些但非全部实施例。实际上，本发明可以许多不同形式体现，并且不应理解为限于本文中陈述的实施例；而是，提供这些实施例从而使得此公开将会满足可适用的法律要求。 尽管此说明书可在若干位置提到“一种”、“一个”、或“一些”实施例，这不一定意味着每个这样的提到是指同一实施例，或者该特征仅适用于单一实施例。不同实施例的单个特征也可组合起来以提供其它实施例。本发明的实施例可适用于任何用户装置(S卩，用户装备)、消息传送服务器、对应的部件、对应的设备、和/或任何通信系统或者支持与等待消息有关的不同用户选择的不同通信系统的任何组合。通信系统可以是无线通信系统、或是利用固定网络和无线网络二者的通信系统。特别是在无线通信中的通信系统以及设备的所使用协议和规范迅速发展。这样的发展可需要对于实施例的额外改变。因此，所有词语和表达应被广义地解释，并且旨在例解、而非限制实施例。在下面，作为实施例可适用于的架构的例子，将会使用融合IP消息传送CPM使能器(enabler)架构来描述不同实施例、然而无需将实施例限于这样的架构。CPM的一般架构在图1中图示出。图1是简化的架构，其仅仅示出在下面关于用于描述不同实施例的某些功能实体以及元件。所示的实体和元件是逻辑单元，其实现可与所示的不同。图1中所示的连接是逻辑连接；实的物理际连接可以不同。对于本领域技术人员显而易见的是，CPM也包括其它功能和结构。应领会到的是，用在或用于消息传送的功能、结构、元件和协议是与实际发明不相关的。因此，它们不需要在本文中更详细地加以讨论。通过限定水平使能器(其构建于SIP/IP核心设施系统100的顶上)，CPM使能器(图 1中未示出)提供了框架。此框架包括一组功能组件以及接口，它们已被设计成促进容易地部署促成现有的和未来的通信服务。例如，CPM使能器支持了 完全的即时消息传送、其它 IP多媒体消息传送、无线一键通(push to talk over cellular)、以及在多地址和多装置 110 (仅在图1中示出一个)环境中与传统移动消息传送服务的透明互通(interworking)。所有基于CPM的服务将会使用功能组件，诸如参与功能PF120、消息存储服务器150(其提供例如用于用户的消息的用户专用的网络存储)、以及由框架提供的接口。非CPM通信服务需要互通功能130，其在CPM使能器和用以与框架进行通信的不同技术之间提供适配/映射。 针对互通，可能还需要互通选择功能140，其选择执行实际互通的互通功能。然而，CPM的细节不是基本的，并且因此在本文中没有更详细加以说明或例解。在 0MA-AD-CPM-Vl_0-20090320-D 的 2009 年 3 月 20 日的文档 “Converged IP Messaging Architecture, Draft Version 1. 0OMA-TS-CPM_System_ Description-Vl_0-20090320-D 的 2009 年 3 月 20 日的文档"OMA Converged IP Messaging System Description, Draft Version 1，0”、以及 0MA-RD-CPM-V1_0-20090202_D 的 2009 ^Ξ 2 ^ 2 H W^1 "Converged IP Messaging Requirements, Draft Version 1. 0"
露了对于CPM的更详细描述，这些文档通过援引而合并入本文中。用户装置110例解了一个类型的设备，用户可利用其来接收消息、通知和给出指令。用户装置110指的是计算装置，其包括在具有或者没有用户识别模块(SIM)的情况下运行的固定通信装置、无线移动通信装置，包括但不限于下列类型的装置移动电话、智能手机、个人数字助理(PDA)、手持机、膝上型计算机、台式计算机和固定电话。用户装置110 配置成执行按一实施例如下描述的一个或多个用户装置功能，且其可配置成执行来自不同实施例的功能。为此，用户装备包括消息传送客户端单元MCU 111，其用来根据下面所述的一个或多个实施例提供功能以形成并传输用于等待传递的消息的处理指令。消息传送客户端单元可以是CPM客户端的一部分。此外，用户装置可包括其它客户端，并且其包括不同的接口，诸如接收单元112、发送单元113和用户接口 114。用户接口可首先向用户示出处理指令备选方案，随后示出关于等待消息的信息，并且随后使得用户选择该处理指令备选方案将要应用于的消息，或者用户可逐消息地提供有处理指令备选方案(即，选项)，从而使得用户为每个消息选定备选方案。然而，其如何实现对于本发明不重要。用户的家庭网络200包括参与功能PF 120，其充当用户的网络侧代理 (surrogate)，包括了与用户可具有的多个CPM客户端的交互的协调。参与功能可被看作是用户专用的功能组件，其可暂时将等待传递给用户的消息存储于存储器124中。参与功能与其存储器表示称为消息传送服务器的网络节点(或计算设备)，并且在下面使用了术语 “消息传送服务器”。消息传送服务器120配置成执行按一实施例如下描述的一个或多个消息传送服务器功能，且其可配置成执行来自不同实施例的功能。为此，消息传送服务器包括消息处理单元MHU 121，其用来根据下面所述的一个或多个实施例提供功能以接收用于等待消息的处理指令。消息处理单元121还可以配置成根据下面所述一个或多个实施例形成通知。此外，消息传送服务器可包括其它处理单元和功能，并且其包括不同的接口，诸如接收单元122和发送单元123。应领会到的是，消息存储服务器提供了永久性用户专用的存储装置，而消息传送服务器仅提供了在所有用户之中共享的临时缓冲器。尽管设备(即用户装置、消息传送服务器、消息存储服务器、互通功能和互通选择功能)已被描述为一个实体，它们(在图1中未示出)可在一个或多个物理或逻辑的实体中实现。单元和功能可以是软件和/或软件-硬件和/或固件部件(不能消除地记录在诸如只读存储器这样的介质上，或体现在硬接线的计算机电路中)。
设备可一般地包括处理器(图1中未示出)、控制器、控制单元、微控制器等，其与设备的各接口和存储器相连。一般地，处理器是中央处理单元，但是处理器可以是额外的运算处理器。消息传送客户端单元111、和/或延迟消息处理单元121可配置为计算机或处理器、或诸如单片计算机元件这样的微处理器、或为芯片组，其至少包括存储器，用于提供用于算术运算的存储区域；和运算处理器，用于执行算术运算。消息客户端单元111、和/或消息处理单元121可包括一个或多个计算机处理器、专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)JP /或以这样的方式被编程以便执行一个或多个实施例的一个或多个功能的其它硬件部件。接收单元和传输单元各自提供了设备中的接口，接口包括传送器和/或接收器、 或者用于接收和/或传输信息(诸如数据、内容、控制信息、消息)并且执行必要功能的对应器件，从而使得可接收和/或传输用户数据、内容、控制信息、信令和/或消息。接收和发送单元可包括一组天线，其数目不限于任何特定数目。设备一般可包括易失性和/或非易失性的存储器并且通常存储着内容、数据等。 例如，存储器可存储计算机程序代码，诸如软件应用(例如，用于消息处理单元或者消息传送客户端单元)或者操作系统、信息、数据、内容等，以便处理器根据实施例执行与设备的操作相关联的步骤。存储器例如可以是随机存取存储器、硬盘驱动器、或者其它固定数据存储器或者存储装置。此外，存储器或其部分，可以是以可拆卸方式连接至设备的可移除存储
ο应领会到的是，设备可包括用在或用于消息传送、以及其它信息传输的其它单元。 然而，其与实际发明不相关，且因此，它们不需要在此处进行更详细讨论。下面披露了不同的实施例，假定用户具有等待消息、并且发送了关于它们的通知。 存在着等待消息、或触发发送通知的事件的原因不重要，并且因此它们在此处没有详细加以描述。在用户具有多个装置的情况下，通知可发送给它们中的一个、一些、或所有。然而， 下面为清楚起见假设了仅存在通知发送给其的一个用户装置。图2图示了消息传送服务器的功能，或者更确切地，在将要形成通知的情形中、即在无请求的情况下没有直接地传递消息或推送等待消息的情形中，消息处理单元的功能。在存在着等待消息和诸如用户有空或愿意接收消息这样的事件发生的情形中，图 2开始。随后将要形成通知(步骤201)。因此，在步骤202中，则消息传送服务器获得关于通知将要发送到的(多个)用户装置的能力、用户专用的限制的信息(若有的话)。关于能力的信息可从用户装置的注册信息获得，或通过使用标准化的或所有者方法而获取。用户专用的限制是由用户设定的设置，并且它们可以是以装置专用的方式(device-specifically) 而设定的、或取决于消息性质(诸如大小或内容类型)而设定的。装置能力的实例包括存储器资源、对于消息中的(多个)媒体类型的支持、所支持的图像/音乐呈现、所支持的文本支持/字母表、处理能力、和视频编码。应领会的是，也可考虑到其它特征，诸如关于用户装置连接性的信息、可适用的服务提供商设置(诸如那些与消息传递有关的服务提供商设置)、 和/或参与传输消息的网络的性质。随后，消息传送服务器在步骤203中取得消息，并且在步骤204中通过将消息特征 /特性(大小、媒体类型等)与所获得的装置能力和用户专用的限制进行比较而确定针对此特定消息的可允许的处理指令备选方案。当已确定了可允许的备选方案时，在步骤205中消息传送服务器向通知的主体(body)添加消息的元数据及可允许的备选方案(或对它们的 (多个)指示)。如果已针对所有等待消息确定了可允许的备选方案(步骤206)，则在步骤207 中发送了通知。否则，过程回到步骤203，并且取得下一消息。通知可以是带内(in-band)通知或者带外(out-of band)通知。带内通知可以是 SIP NOTIFY，或者对应消息，其在主体中例如具有指示有多少消息在等待的概要、以及针对每个消息的元数据。元数据是对消息进行综述和识别的首部(header)。首部(元数据)优选地包含消息标识符、或对应信息，可用其在消息传送服务器中识别出特定消息，并且首部还可包含下列字段的一个或多个去往、来自、主题、日期、大小和优先权。同样的信息可在带外通知中发送，带外通知可以是例如作为去往用户的装置的短消息而发送的消息。在另一实施例中，消息传送服务器配置成不用元数据来指示可允许的备选方案， 条件是所有备选方案可允许。取决于实现方式，用户装置在缺失了对备选方案的指示的情况下可示出所有处理备选方案，或者用户装置可包括一组默认的备选方案，用户装置配置成在没有对备选方案的指示的情况下使用该组默认的备选方案。在另一实施例中，用户装置配置成基于所接收的元数据确定什么备选方案可能用于对应的消息，并且配置成允许用户仅在它们之中进行选择。应领会到的是，存在这样的实施例，其中没有考虑到装置能力、装置连接性、消息特征、服务供应商策略和/或用户专用限制，但是提供给用户的所有处理指令备选方案可以是相同的，而不管装置和/或消息性质。最简言之，通知形成过程仅包含向通知添加关于等待消息的元数据。图3图示出了消息传送服务器的功能，或者更精确地，图示出了当根据实施例从用户装置接收到指令时消息处理单元的功能。在实施例中，假定，在一个资源列表中接收了所有处理指令，诸如图5所述。应领会到的是，消息处理单元可配置成应用其它处理指令(诸如用于暂时存储期满且导致消息被删除的计时器)，但是它们与所图示的实例不相关并且在本文中没有加以描述。在图示的实例中，假定，发现了所有消息、且没有错误情形发生。错误情形的实例是，如果存在要传递到用户装置的消息，则没有从用户装置接收到会话建立确认。这些错误情形是与所例解的实施例不相关的，并且因此在本文中没有加以描述。当消息传送服务器接收(步骤301)消息处理文档、或关于如何处理一个或多个等待消息的其它对应指令时，则在步骤302中，其取得消息标识符、或对应信息、以及对应指令。如果指令是“保持(ke印)”(步骤303)，则在步骤304，消息传送服务器继续将消息存储在临时缓冲器中。换言之，没有对消息做任何事。取决于实现方式，计时器可更新，和 /或再在稍后通知该消息。如果指令是“存储”(步骤305)，则在步骤306中，消息被传递给用户的网络存储装置。如果指令是“删除”(步骤307)，则在步骤308中，从临时缓冲器删除了消息(无需用户见到/听到其)。如果指令是“互通”(步骤309)，则在步骤310中，消息传送服务器检查该指令是否包含指示要使用什么互通功能的扩展标记。如果没有标记、或者标记指示消息传送服务器或网络可决定，在步骤311中，消息传递到互通选择功能用于进一步传递到适当的互通功能。如果存在着指示将要使用什么互通功能的标记(步骤310)，则在步骤312中，消息被传递给对应的互通功能。如果在实施例中指令不是任何上述指令，则随后“取回”指令，并且在步骤313中， 消息被临时打标记用于取回传递(retrieval delivery)。从步骤302开始(即，从取得消息标识符开始)的上述过程、或对应信息、以及对应指令被重复，直至处理了所有指令(步骤314)。随后在步骤315中，检查了是否存在被标记用于取回传递的任何消息，并且若有的话，在步骤316中建立该会话，被标记用于取回传递的(多个)消息在步骤317中被传递， 且该会话在步骤318中终止。如果不存在被标记用于取回传递的消息(步骤315)，则该过程终止(步骤319)。在本发明的另一实施例中，没有使用扩展标记，并且经由互通选择功能将具有“互通”指令的所有消息传递至互通功能。换言之，忽略步骤310和312。在另一实施例中，如果扩展标记指示将要使用什么互通功能(S卩，步骤311中的回答为“是”)，则互通选择功能没有被绕过，而是消息与指示一起被转发至互通选择功能，从而使得互通选择功能可以进行最终选择。尽管未提及，应领会到的是，在传递了消息之后，从临时缓冲器将其删除。图4图示了用户装置的处理指令功能，或更确切地，根据实施例的消息传送客户端单元的功能。在步骤401中，用户装置接收关于等待消息的通知。如上所述，通知可以是带内通知或带外通知，并且其可以是SIP NOTIFY,或者是在主体中例如具有指示有多少消息在等待的摘要的对应消息、以及优选地对消息进行综述和识别的针对每个消息的首部(即，消息的元数据)。在某些时刻，向用户装置的用户示出了主体(通知的内容)，要么是因为用户专门指示如此，或是由于某些其它事件。不相关的是什么导致将要示出该内容。响应于“用户已选定一个消息的元数据”的检测(步骤403)，在步骤404中向用户示出了不同的处理备选方案。在例解的实例中，处理备选方案包括“取回”、“保持”、“存储”、“互通”和“删除”，这些备选方案的意思如上所述。响应于用户选择这些备选方案之一，在步骤405中接收该选择， 并且在步骤406中形成了与元数据(或与消息标识符)以及该选择的关联。然后在步骤407 中检查了是否每个元数据具有选择(即，关联)，并且如果没有，则随后在步骤408中检查了是否接收到了指示用户不希望继续的用户指令。如果用户希望继续(即没有接收到相矛盾的指令)，则过程进展到步骤403以检测出用户已选定了另一消息的元数据。如果每个元数据具有一种选择(步骤407)或者用户不希望继续(步骤408)，则在步骤409中用户装置形成(汇编)了一种消息处理文档，其使用关联来提供针对特定消息的指令。利用图5和6描述了消息处理文档的实例。随后用户装置在步骤410中产生了一种 SIP INVITE请求，该请求在多部件/混合主体中具有SDP (会话描述协议)描述以用于在用户装置与消息传送服务器之间的会话，并且随后用户装置在步骤411中将消息处理文档添加到该请求的多部件/混合主体，并且在步骤412中用户装置包括了 要么在该请求中在一种需要首部字段中的、或者在一种接收接触首部中的互联网媒体类型的消息处理文档，并且随后在步骤413中将该请求发送至家庭网络中的消息传送服务器，该请求被寻址至例如insert_server_functionihostname0 互联网媒体类型的实 歹Ij包括"application/vnd. cpm. message-handl ing+xml，，。在另一实施例中，当产生SIP INVITE时，用户装置可检查是否至少一次选择了备选方案“取回”。如果是，则用户装置如上所述继续，并且如果否，则SIP INVITE中的SDP描述(或没有SDP描述)可指示SIP INVITE用于发送处理指令并且没有请求会话建立。在该实施例中，通过检查是否SIP INVITE也用于会话建立，而在消息传送服务器中替换了步骤 315。在另一实施例中，当发送SIP INVITE之后，用户装置可配置成检查是否至少一次选择了备选方案“取回”。如果是，则用户装置继续进行会话建立，接收消息并且随后终止会话。如果否，则用户装置取消会话建立。图5图示出根据实施例的消息处理指令的实例。在实例中，消息处理指令是基于 XML (可扩展标记语言)1. 0文档的系统消息并且使用UTF-8编码(UTF是通用字符集转换格式)，由5-1标示出。文档利用XML命名空间以用于识别出系统管理文档和文档片断。实际消息处理文档500开始于根元素5-2，该根元素限定了命名空间5-21并且包括多个分支元素5-3。每个分支元素包括“MSG-ID”属性，该“MSG-ID”属性包含与由“处理” 属性指示的所请求的处理指令相关的消息的独特特性。消息处理文档可以用CPM中的互联网媒体类型“application/vnd. cpm. message-id+xml”识别。在其它架构中，可使用另一类型的互联网媒体类型。一种提供在图5中图示出的关于消息处理文档形式的正式说明的对应XML模式如下
< xml version:” ,0* encodirig="UIF-i" > <xs:scherna brgelNamespa:e="iim:CMTB:xmtepm:message-teiidter" xroln s ；xs="hllp ://wwwm3 ,org/2001IXMLSche ma" xml ns="um;oma :xml ； qam; message· handler" eJemenlF0rmDeiau!l="qualiliect" a_byteFormDefaurt=*__a_ecf>
<*s:eteraerit name^message-tiandter" type=*HancHifiiType7> <xs;complexType me="HandliiigType*> <xs:sequence>
<xs:efemeni Oame=Ieg" Iype=IegType" maxOccursi="unbounc!ecl"/> <xs:any namesp e=*iiolhe f pnocessConlen Is=Iax" HinOccurs=-CT max0ccyrs="unbciuii3eci*/>
</x$:$ec{iierice><xs:anyAttribyle namespace="#iolher·* processCwtenls^lax"^ </xs:comp!exType>
<Ks:complexType name="legType"> <xs:setjuence>
<xs:any namespaci="##othif" processConteri Is=Iax" m)ntt5curs="0p maKOc5ci rs="uribouncieiJ"l>
<lxs:sequence>
<xs;atlributfi rema="MSG-ID" lyp§="xs;anyURr use='raquire(i7> <xs:attibule reme="Handltre}" type="xs:slrifig' use="required"'>
<xs:simplelype>
<xs:resfrictioii tese=*xs:strins*>
<xs:enumeraliofi value=*RETRI E VE "/> < ^enumeration val账*KEEP"I> <xs.eriumeratiori va Iue-* STOR E*/> <xs:enumeratiofi value=" INTERW0RK7> <xs:eriuiTiefalcw VaIye=OlSCARD'^
<lxs:restriclion> </*s:simpleT^pe> <xs;anyAtlribule namespace=*##otier* processCortenls=1aO </xs:compte*Type>
脚、
实施例的优点在于所有项处于一个主体中。图6图示出根据另外实施例的消息处理指令的另一实例。在该实例中，消息处理指令与图5中所示不同之处在于用于“取回”的处理指令以它们自己的主体被保持为一种资源列表，但是其它处理指令是在与图5所描述的主体相比相似的主体中。换言之，消息处理指令是基于XML (可扩展标记语言)1. 0文档的系统消息并且使用UTF-8编码(UTF是通用字符集转换格式)，由6-1标示出。实际消息处理文档600包括两部分资源列表(第一主体6-6)包括以根元素6-4开始的列表元素6-5，并且消息处理文档(第二主体6-7)包括分支元素6-3且以根元素6-2开始，两种根元素都开始于命名空间 6-21。每个列表和分支元素包括“MSG-ID”属性，该“MSG-ID”属性包含与由“处理”属性指示的所请求的处理指令相关的消息的独特标识。消息处理文档可以用CPM中的互联网媒体类型“application/vnd. cpm. message-id+xml”识别。在其它架构中，可使用另一类型的互联网媒体类型。实施例的优点在于，可以重新使用用于取回消息的“application/ resource-list+xml"内容类型的现有技术主体，而没有改变。应领会到的是，在此外的实施例中，可形成消息处理指令，从而使得存在着用于每个不同指令备选方案的单独主体，或者它们中的一些可具有公共主体以及一些它们的自有主体。例如，“存储”和“保持”可具有公共主体，但是“取回”、“删除”和“互通”是它们自有主体。
尽管在图5和6中没有示出，但SIP INVITE请求也包含对将要形成的会话进行描述的信息，以传送具有“取回”作为其指令的的消息。图7图示了根据本发明的实施例的信令，在其中处理指令包括用于“取回”的单独主体以及用于其它处理备选方案的单独主体的情况下。参看图7，用户装置接收通知7-1。通知可以是SIP NOTIFY并且在所图示的实例中，其通告了 有四个消息Ml、M2、M3和M4在等待。在点7_2中，用户装置接收用户输入， 该用户输入指示将要取回消息M2和M4，抛弃消息Ml和M3。因此，在点7_3中，用户装置形成了一种处理指令，其包含针对M2和M4的列表限定和针对Ml和M3的分支限定。随后用户装置发送处理指令7-3。处理指令可以是SIP INVITE。在点7-4中，当消息传送服务器接收处理指令7-3时，其取得第一主体，检测出存在着列表限定，并且因此需要建立起一种会话，该会话在处理指令7-3中加以描述。因而， 消息传送服务器发送诸如SIP 200 OK之类的接收7-5，并且在点7-4中取回消息M2和M4。 在从用户装置接收确认(acknowledgement) 7-6 (诸如SIP ACK)以用于消息发送会话，则消息发送服务器在消息7-8中发送(点7-7)消息M2和M4，诸如MSRP (消息会话中继协议) SEND。当用户装置已接收到了消息M2和M4，则用户装置通过发送消息7_9(诸如MSRP 0K) 而确认了该接收。在接收到“接收”之后，消息传送服务器通过发送消息7-11 (诸如SIP BYE)而终止了(点7-10)会话，并且用户装置确认会话将会通过发送消息7-12 (诸如SIP 200 0K)而终止。同时或之后，消息传送服务器在点7-13中取得第二主体，并且逐个分支地使得分支限定通过。在此实例中，消息传送服务器从临时存储装置删除了消息Ml和M3。如果没有消息要取回，则消息传送服务器可通过发送指定类型的消息而确认处理指令，所述指定类型的消息指示指令被接收、但是没有建立起会话。在另一实施例中，如果没有与消息相关联的指令，S卩，形成了资源列表，从而使得其包含在通知中发送过的所有相同的标识符，但是用户尚未提供用于一种消息的任何指令，消息传送服务器可配置成使用默认值诸如“保持”，或者将消息处理为“未通知的”。默认值可以是用户专用的或者服务提供商专用的，并且其可取决于消息内容、大小、用户装置能力，等等。正如可以从以上实例看到的，本发明不限于CPM，但其可在利用SIP或对应平台的任何系统中实现。一种实例包括SIMPLE即时消息传送系统。上面给出的处理指令备选方案仅仅是示例性的，并且仅可使用它们中的一些，或者，作为它们的补充、或它们中的一些的补充，可使用一些其它处理指令诸如“转发”，或者针对相同目的可使用另一术语。例如，在上述术语中，“删除”和“抛弃”已被用于相同目的。 换言之，处理指令备选方案一点不受限制。尽管在上面已描述了实施例，但是为清楚起见，假定一个消息具有一个处理指令， 其应被理解为一个消息可具有多于一个处理指令，并且消息传送服务器执行它们。例如， 可仅有一个等待消息，并且用户指示将消息转发给另一用户，并且另外对其进行存储或将其取回。以上在图2至7中描述的步骤/点、消息、信息交换和相关功能不是呈绝对时间次序的，并且一些步骤/点或功能可被执行和/或消息可被发送，这是同时地发生的、或者以与给定情况不同的次序地发生的。例如，消息可被传递给用户装置，同时其它消息被删除或存储。其它功能也可在点或功能之间或者在步骤/点内执行，并且其它消息也可在图示的消息之间发送，诸如发送确认。一些功能或步骤/点或者步骤/点的部分也可被省去、或者由对应的功能或步骤/点或者步骤/点的部分所替代。此外，利用不同实施例描述的功能、 步骤/点和/或消息可被组合以获得另外的实施例。消息仅仅是示例性的并且甚至可包括若干单独消息以用于传送相同信息。另外，消息也可包含其它信息。取决于有关的网络技术，除了以上所述那些，其它实体可参与信令。尽管在上面已经描述了实施例，假定消息传送服务器在用户的家庭网络中，则应当领会到一种解决方案是可能的，在该解决方案中，等待消息存储于家庭网络以外的另一网络中、并且消息传送服务器位于这样一种网络中，且该解决方案可使用以上描述而直截了当地实现。本文中描述的技术可通过多种装置实现，从而使得实现利用实施例描述的消息传送服务器或者对应用户装置的一个或多个功能的设备不仅包括了现有技术装置、而且包括用于实现利用实施例所描述的对应设备的一个或多个功能的装置，并且其可包括用于每个单独功能的单独装置、或者装置可配置成执行两个或更多功能。例如，这些技术可能以硬件(一个或多个设备)、固件(一个或多个设备)、软件(一个或多个模块)或它们的组合而实现。针对固件或软件，实现方式可以是通过执行本文中所描述功能的模块而进行的。软件代码可存储在任何适当的(一个或多个)处理器/计算机可读数据存储介质或(一个或多个) 存储器单元或(一个或多个)制造的制品中，并且由一个或多个处理器/计算机执行。数据存储介质或存储器单元可在处理器/计算机内部或外部实现，在外部的情况下其能够以通信的方式经由如本领域中已知的多种装置而耦合到处理器/计算机。将会对本领域技术人员显而易见的是，随着技术进步，能够以多种方式实现本发明的概念。本发明及其实施例不限于上述实例，但可在权利要求书的范畴内变化。
权利要求
1.一种方法，包括接收指示至少两个消息正在等待传递的通知； 经由用户接口提供用于消息的可选择的处理指令； 接收用于第一消息的第一处理指令来作为用户输入；接收用于第二消息的第二处理指令来作为用户输入，第二处理指令不同于第一处理指令；形成包含所接收的处理指令的请求；以及发送该请求。
2.一种方法，包括接收指示至少一个消息正在等待传递的通知；经由用户接口提供用于消息的可选择的处理指令；接收用于消息的第一处理指令和第二处理指令来作为用户输入；形成包含所接收的处理指令的请求；以及发送该请求。
3.一种方法，包括发送指示至少两个消息正在等待传递的通知；接收包含至少两个不同类型的消息专用处理指令的请求；以及根据对应的消息专用处理指令来处理每个消息。
4.如权利要求3所述的方法，还包括基于消息性质、用户装置能力和用户专用指令中的至少一个而为待通知的消息确定可选择的处理指令；在发送通知之前，以消息专用的方式向通知添加处理指令备选方案、或者对处理指令备选方案的指示。
5.如权利要求1、2、3或4所述的方法，其中针对每个所通知的消息，通知包含元数据， 该元数据至少包括识别消息的信息。
6.如权利要求1、2、3、4或5所述的方法，其中包含处理指令的请求包含一个主体中的消息专用处理指令。
7.如权利要求1、3、4或5所述的方法，其中包含处理指令的请求包含用于待传递消息的第一主体和用于其它处理指令的第二主体。
8.如前述权利要求中任一项所述的方法，其中消息专用处理指令指示以下之一传递、保持于临时存储装置中、存储于非临时存储装置中、互通和删除。
9.如权利要求8所述的方法，其中指示互通的消息专用处理指令还包括指示待使用的互通功能的标记。
10.一种计算机程序，包括程序代码器件，配置成当程序运行在计算装置上时执行如方法权利要求1至9中所述的任何步骤。
11.一种计算机可读存储介质，具有记录于其上的如权利要求10中所述的程序。
12.—种设备，包括器件以便执行如方法权利要求1至9中任一项所述的方法。
13.一种设备，包括用户接口器件，用于接收用户选择，该用户选择是关于等待传递的消息的两个或多个处理指令备选方案中的哪一个被选择用于消息；用来响应于所接收的用户选择而向请求添加消息专用处理指令的器件；以及用来响应于设备检测出将不再会接收到用户选择而发送请求的器件。
14.如权利要求13所述的设备，还包括用于对指示消息等待传递的通知进行接收的器件，该通知包含消息专用元数据和消息专用处理指令备选方案；以及用于经由用户接口器件以消息专用的方式向用户提供消息专用处理指令备选方案的器件。
15.如权利要求13或14所述的设备，还包括用于基于设备性质确定消息专用处理指令备选方案的器件。
16.如权利要求13、14或15所述的设备，其中用于添加的器件配置成添加消息专用处理指令作为一个主体中的请求列表。
17.如权利要求13、14或15所述的设备，其中用于添加的器件配置成添加指示取回的消息专用处理指令作为所述请求的一个主体中的请求列表，并且添加其它消息专用处理指令作为所述请求的另一主体中的请求列表。
18.一种设备，包括用于接收与等待传递的消息有关的请求的器件，所述请求包含至少两个不同类型的消息专用处理指令；以及用于根据对应的消息专用处理指令来处理每个消息的器件。
19.如权利要求18所述的设备，所述设备还包括用于形成关于等待的消息的通知的器件，对每个所通知的消息，所述通知包含元数据， 该元数据至少包括识别消息的信息；以及用于发送通知的器件。
20.如权利要求19所述的设备，所述设备还包括用来基于消息性质、用户装置能力和用户专用指令中的至少一个而为待通知的消息确定针对消息的可选择处理指令的器件；其中用于形成的器件配置成以消息专用的方式，向通知添加由用于确定的器件所确定的处理指令备选方案、或者对处理指令备选方案的指示。
21.一种设备，包括用户接口，配置成接收用户选择，该用户选择是关于等待传递的消息的两个或多个处理指令备选方案中的哪一个被选择用于消息；以及消息传送客户端单元，配置成响应于所接收的用户选择而向请求添加消息专用处理指令；配置成检测出将不再会接收到用户选择，以及配置成发送包含不同的所选择处理指令的请求。
22.如权利要求21所述的设备，其中设备包括处理器，该处理器配置成包括消息传送客户端单元。
23.如权利要求12、13、14、15、16、17、21或22所述的设备，其中所述设备是用户装置。
24.一种设备，包括接收器，配置成接收请求，所述请求包含两个或多个不同的消息专用处理指令； 消息处理单元，配置成根据针对消息的所接收的消息专用处理指令而处理消息。
25.如权利要求M所述的设备，其中设备包括处理器，该处理器配置成包括消息处理单元。
26.如权利要求18、19、20、对或25中的任一项所述的设备，所述设备是网络节点，包括参与功能或消息传送服务器。
27.—种系统，包括如权利要求12、13、14、15、16、17、21、22或23中任一项所述的第一设备，以及如权利要求18、19、20、24、25或沈中任一项所述的第二设备。
28.如权利要求27所述的系统，该系统支持融合互联网协议消息传送和/或即时消息传送。
全文摘要
一种机制，使得用户能向负责处理等待消息的网络实体一次传送(7-3)消息专用的、很可能不同的处理指令，其中该用户的用户装置已接收关于等待传递的消息、被延迟或出于另一原因而等待的消息的通知。
文档编号H04L12/58GK102461095SQ200980159665
公开日2012年5月16日 申请日期2009年4月2日 优先权日2009年4月2日
发明者哈鲁纳 A., 罗纳特 H. 申请人:诺基亚西门子通信公司