CN101061730A - 移动消息传送系统及方法 - Google Patents

Abstract

本发明提供了利用移动装置(如蜂窝电话和个人数字助理(PDA))进行消息传送的系统和方法，更具体地说，涉及利用移动装置将多媒体进行消息传送的系统和方法。在一个方面，提供了允许移动用户在正在进行的基础上通过将多媒体进行消息传送MMS(如用文本、图象、视频和/或音频进行消息传送)与另一装置的用户合作的系统和方法。例如，在一个实施例中由移动和非移动装置产生的多媒体消息在把消息和相关联元信息作为“文档”(或其部分)远离消息发送器和接受器存留(即存储)之前自动用元信息(如作者、日期、时间和/或位置)标记。这些文档即使在消息传递给接受器之后也保留在远程存储中，这允许基于元信息例如来搜索和/或分类和访问消息以便以后参照、修正和/或再用多媒体内容。此外，发送器和接受器可指定为文档参与者，由此建立了创建参与者之间的消息传送共同体的关联。

Description

移动消息传送系统及方法

相关申请的交叉引用

本发明要求享有于2004年9月21日提交的、序列号为No.60/611746以及2005年5月26日提交的、序列号为No 60/685304的美国临时专利申请的权益，这些申请在此通过引用被完整地包含于本文中。

技术领域

本发明的实施例涉及利用移动装置(如蜂窝电话和个人数字助理(PDA))进行消息传送的系统和方法，更具体地说涉及利用移动装置将多媒体进行消息传送的系统和方法。

背景技术

传统意义上，利用移动装置来对多媒体(如文本、图象、视频和音频)进行消息传送很麻烦并且在许多情况下是不可能的。例如，短消息业务(SMS)限制为传送160个或更少字符的文本消息。虽然多媒体消息传送业务(MMS)允许传送文本以及其他媒体，但是MMS缺乏存留性，它是在消息已交付给接受器之后距离发送器和接受器对消息进行的远程存储。具体而言，在消息经由MMS交付后，负责交付的服务器不保留消息复本以便例如以后参照或再用多媒体内容。因此，移动用户通过利用MMS而在正在进行的基础上与另一个户合作的能力是非常有限的。此外，经由因特网协议(IP)信道(如经由IP多媒体子系统(IMS)或通过移动装置上运行的浏览器)把多媒体交付到移动装置的常规方法在交付时间和网络连接可靠性方面可得到很大地改进。

因此，希望提供解决利用移动装置将媒体进行消息传送的常规系统的这些和其他缺点的移动消息传送系统和方法。

发明内容

本发明实施例涉及利用移动装置对多媒体进行消息传送的改进的系统和方法。通过便于多媒体合作、提高内容交付效率和/或网络可靠性，和/或提升终端用户功能性来改进提供给移动用户的消息传送经历。例如，移动用户的消息传送经历可与提供给桌面和其他非移动装置的消息传送经历相比或超过它，就使用和功能性的简易性而言在传统意义上超过了移动装置的消息传送经历。

在一个方面，提供了允许移动用户通过多媒体消息传送(如用文本、图象、视频和/或音频进行消息传送)在正在进行的基础上与其他装置的用户合作的系统和方法。例如，在一个实施例中，由移动和非移动装置产生的多媒体消息在把消息和相关联的元信息作为“文档”(或其部分)距离消息发送器和接受器远程存留(即存储)之前，自动用识别元信息(如作者、日期、时间和/或位置)进行标记。这些文档即使在消息传递给接受器之后也保留在远程存储中，它允许基于元信息来例如搜索和/或分类以及访问消息以便以后参照、修正和/或再用多媒体内容。此外发送器和接受器可设计为文档参与者，由此建立了创建参与者之间的消息传送共同体的关联。相同共同体的成员(即相同文档中的参与者)可具有特定于该共同体的各种功能性，例如开始与共同体其他成员的实时通信(如用户从其中两个用户均参与的文档中的参与者的列表中选择另一用户的在线ID)，向共同体的所有其他成员发送消息并确定当前哪些共同体成员访问形成共同体的基础的文档。因此，参与多个文档的用户可以是多个消息传送共同体的成员。

如这里所用到的，文档包括任何一类或多类多媒体(以及可选地还有相关联的元信息)，它们在发送器和接受器之间传递，并在传递之后距离发送器和接受器远程存储。文档可以分布方式或以任何其他合适的方法远程存储在单个位置。在优选实施例中，每个文档包括一个或多个称为“分段”的关联的消息(如第一分段包括从发送器到一个或多个接受器的多媒体消息和识别发送器的元信息，而其他分段包括来自接受器的多媒体响应和识别接受器的信息)。可在分段的元信息中获得同一文档的分段存留于远程站点的顺序。此元信息(如时间标记)可用来例如以参与者之间的多媒体对话发生的顺序或以用户定义的顺序重放该多媒体对话。可选地是，还可提供可由具有此文档的访问权的用户选择的历史文件。历史文件可包括例如按照分段在远程站点存留的顺序识别文档的分段(如由它们相关联的元信息)的内容表。用户可从内容表中选择条目以导航到文档中的对应分段。

在另一实施例中，提供了一个允许不同装置的用户同时写到(如添加或修改)已存储的文档(如存留远离装置存储的文档的分段)的附加功能。这与传统方法相反，它采用锁定机制来授予对所存储的内容的许可，在该机制中在给定时间只有一个用户可访问/修改所存储的内容以及请求写访问内容的随后用户增加到队列中。

在其他实施例中，提供了社会联网协议，允许在文档中与参与者相关联的几方(如文档参与者的“朋友”或“朋友的朋友”)访问文档和其相关联的多媒体内容(可选的还有元信息)。这样的一方还可例如在该方将附加到文档的响应进行消息传送时成为文档参与者。

在另一方面，提供了便于多媒体消息交付给移动装置的系统和方法。例如，在一个实施例中基于XML的多媒体消息用减小消息尺寸的XML“短码”进行编码，由此减小了由发送设备编码的XML的量以及接收设备译码的XML的量，这是把消息传递给接受器所需要的。具体而言，当消息中XML树或子树的结构遵守默认结构(如当负责播放消息并运行于接受器的装置上的客户端应用包括保持从消息到消息静态的工具条或其他图形用户接口(GUI)方面时)，定义树或子树结构的消息的编码部分可用表示该结构的缩减码代替。可提前确定或在消息流期间确定针对其定义短码的具体的树或子树。例如安装在客户端装置上的客户端应用可已经包括或可在安装时获得短码定义。作为备选或附加，可针对出现在消息传送流的树或子树以on-the-fly方式定义短码(如响应确定子树是否已在消息流中出现了超过阈值次数如一次来针对子树定义短码)。在定义短码时，短码定义可提供给文档参与者的消息传送设备和/或负责消息的远程存储的服务器。在优选实施例中，XML短码是netomatic标记语言(nml)短码，其中nml是2002年11月28日公布的序列号为20020178164的美国公布、题为“在计算机网络上共享、管理以及传递信息”中描述的XML构造语言，该文献通过引用而被完整地结合于此。

在另一实施例中，只有文档中的一部分在给定时间传递给移动装置。例如，文档的一个或多个分段可基于通信网络的带宽和/或等待时间，和/或移动装置的处理和/或存储能力而传递给移动装置。文档的另一个或多个分段可在随后的传送中传递给移动装置。这些分段可以是“自我意识的(self aware)”，因为它们包括移动装置重编文档所需要的所有信息。

在另一实施例中，在消息的文本部分传递给装置的同时把消息的非文本多媒体作为内嵌ASCII编码二进制资产传递给移动装置。ASCII编码资产可被压缩以减小消息尺寸。相反，交付多媒体消息给移动装置的常规方法涉及把消息的文本部分交付给装置，其中文本部分包括一系列对非文本媒体的引用。随后，响应对来自移动装置的媒体的单独请求把每个非文本媒体交付给该装置。多个对信息的请求可由于一个或多个请求未被服务器接收或由于移动装置接收的内容中的传送错误而导致出错。多个信息请求还会增加网络延迟(即等待时间)。

在另一实施例中，移动装置可通过“懒惰的”推式和/或拉式通知协议与多媒体服务器进行通信，其中移动装置和多媒体服务器仅在装置或服务器经历了状态变化时才进行通信。例如，当移动装置的发起状态变化时(如装置“上线”或“离线”)，装置可向服务器发送(推出)一字节的通知来指示此发起状态(以及其他“存在”信息如“忙”、“离开”、“打字”、“空闲”等)。通知还可用作来自服务器的消息请求(拉)和/或其他更新，如请求其他移动用户(如移动用户的朋友列表中所列的用户)的存在信息。在另一示例中，服务器可在更新变得可用时把关于此更新的警告发送(推送)给移动装置。这种懒惰的推和/或拉式协议使利用移动装置进行消息传送所需的网络业务量最小，因此缩短了例如网络等待时间。

在另一实施例中，移动装置可在对服务器的单次呼叫中进行多次信息请求。例如，单次呼叫可包括针对来自存在接口的存在信息的第一请求和针对来自预定接口的辛迪加(syndicated)内容的第二请求。相反，常规方法发出单独的呼叫，每个请求一次。类似于懒惰的推和/或拉式协议，这也减小了利用移动装置进行消息传送所需的网络业务量。

在另一实施例，辛迪加内容(如新闻馈送)通过中间服务器从辛迪加内容服务器传递给移动装置。当移动装置请求辛迪加内容时，中间服务器向该装置发送存储器(中间服务器的存储器或诸如由第三方内容提供商接管的服务器之类的其他存储器)中存储辛迪加内容的位置的参照(链接)。例如，该装置随后可通过参照访问内容，而不必下载和存储内容其本身。这样，避免了双重的内容存储以及从辛迪加内容服务器对内容的检索，因而减小了网络业务量。这与需要每个用户的装置访问并直接从内容服务器下载内容的常规方法相反。

另一方面，提供了提高提供给移动装置的用户的功能性的各种功能性。这种功能性可至少部分地由来自移动装置上的存储器或在移动装置由终端用户购买时驻留在该装置上的存储器中的客户端应用提供，该应用可从因特网下载并在移动装置上安装。在另一示例中，在无客户端方法中可通过移动装置的资源(如浏览器和/或媒体播放器)而不是专用的客户端应用提供消息传送功能性。

在一个实施例中，可提供文档级存在信息(作为用户存在的信息的备选或附加)，该信息指示例如文档是否可用于查看、文档是否已经改变、谁在访问文档或对文档进行工作和/或该文档最近更新是何时。例如当移动用户激活客户端应用时，该用户可看到以一个或多个文档的显示来呈示，其中该用户是参与者或已被邀请与刚刚描述的以文档为中心的特征的一个或多个一同参与。

在另一实施例中，可提供允许用户记录、回放以及编辑消息和消息线程的功能性。例如，基于存储在远程站点上的多媒体内容的元信息，可给提供用户选项以搜索消息内容。此外，元信息实现了消息回放，例如用户可基于时间、日期和/或位置过滤消息的选择性回放。

在另一实施例中，可提供“消息推送(push-to-message)”功能性，以便把消息发送给当前离线的用户、针对特定日期和时间和/或地理位置安排消息的交付和/或当用户检索到消息时连接用户(以及零个或多个其他用户)。

虽然主要结合移动装置来描述本发明实施例的上述特征，但这些特征还可应用到利用非移动装置(如桌面计算机)的消息传送中。

附图说明

为更好地理解本发明，结合附图对以下说明进行参照，附图中类似的附图标记指类似的部分，并且附图中：

图1是根据本发明实施例的多媒体消息传送系统的图；

图2A是根据本发明实施例的非移动装置上运行的多媒体客户端应用提供的屏幕抓拍，其中显示了由服务器存留于存储器的文档。

图2B是图2A中显示的相同文档的屏幕抓拍，如根据本发明的实施例由运行在移动装置上的多媒体内容应用所显示；

图3是根据本发明消息传送媒体所涉及的说明性步骤的流程图；

图4显示了根据本发明的实施例在文档创建时元信息的插入；

图5是移动装置显示屏幕的屏幕抓拍，其中响应于多媒体服务器的单次呼叫将七副图象传送给移动装置；

图6显示了把作为内嵌压缩ASCII编码二进制资产的多媒体内容传递给其上安装了多媒体客户端应用的移动装置的交付时间与把相同消息传递给HTML浏览器所需要的交付时间的比较；

图7显示了根据本发明的实施例一字节通知的流程图；

图8显示了根据本发明的实施例的客户端服务器接口的动态级联；以及

图9和图10显示了根据本发明的实施例经由中间服务器的内容辛迪加的交付。

具体实施方式

本发明的实施例涉及为终端用户提供无缝经历的装置不可知和网络不可知的多媒体消息传送环境，而不考虑用户从移动装置、桌面装置、置顶装置还是从其他装置进行消息传送。在此环境里，装置可跨过不同网络和/或协议例如Web(HTTP)、SMTP/POP/IMAP、SIP、CDMA和GSM(GPRS、EDGE)相互进行消息传送。

图1显示了系统100的实施例，该系统包括服务器102(各自包括一个或多个服务器接口104和存储器106)和用户设备108(例如一个或多个移动装置如蜂窝电话和个人数字助理(PDA)和/或非移动装置如桌面计算机)。系统100还包括网关110、再现引擎112、HTTP/电邮服务器114、负载均衡器116和第三方网关118。例如，本发明的实施例可允许移动或非移动装置的用户查看移动用户的存在信息以便确定移动用户的发起状态(如在线、离线、忙、离开、打字、空闲等)，并使移动用户进行涉及多媒体如文本、图象、音频和视频的通信。在用户设备108之间传递的消息(以及可选的还有与消息相关联的元信息)由服务器104作为文档(或其部分)存留(存储)在存储器106中，以便例如在未来的消息中稍后进行参照和/或再用多媒体内容。当系统100中的文档是基于nml的文档时，系统100在其各个部件上可用“netomat”修饰语(如netomat服务器102)标记。

移动和非移动装置可通过采用客户端或无客户端的方法联网到系统100。在前面情况下，例如在装置的用户从因特网下载客户端之后可将客户端应用安装在该装置上。例如，移动装置的客户端可以是用Java写的小脚本应用(即当移动装置是java使能的装置)。在一个实施例中，这种应用可采用J2ME MIDP 2.0平台来创建，该平台还可包括具有MMAPI(多媒体API)和WMA(无线消息传送API)支持的MIDP 1.0平台。例如，客户端的大小可从50k到150k，这取决于安装客户端的具体移动装置。在另一实施例中，移动客户端可以是XHTML用户内容管理接口。用于非移动装置的客户端应用的例子包括Java 1.4应用、Java1.1小程序、宏媒体动画6.0小程序或XHTML用户内容管理接口。无客户端装置可通过利用驻留在装置上而非专用客户端应用上的资源(如浏览器、文本消息传送和/或媒体播放器)联网到系统100。通常，安装有客户端应用以便多媒体消息传送的装置与无客户端的装置相比可具有增强的消息传送能力。例如，无客户端装置可支持这里所说的可能除了XML“短码”和内嵌压缩ASCII编码二进制资产之外的所有功能性。

服务器102负责管理所有的入站和出站请求(如请求更新或把消息传递给移动用户108或从其传递消息)、与存储器106接口以及提供服务器接口104。在一个实施例中，服务器102是J2EE应用服务器。

服务器接口104可给移动和非移动装置108提供改变的信息并可允许装置108以统一的方式连接到服务器102。例如，接口104可包括以下接口的一个或多个：上传资产接口(UAI)、管理资产接口(MAI)、版本接口(VI)、通知接口(NI)、存在接口(PI)、预定接口(SUI)、准许和投票接口(PTI)、邀请接口(II)、用户数据管理接口(UDMI)、访问管理接口(AMI)、搜索接口(SI)和web服务接口(WSI)。

UAI可负责给服务器上传所有文本和二进制资产。MAI接口负责用户资产的远程管理、例如访问存留在远程站点上的分段以及参照新文档中的分段，由此再用多媒体内容。VI可负责所有更新的版本制定并针对文档分段产生历史文件。NI可负责通知用户更新他们的空间(其包括源于用户的文档(如消息线程)以及用户仅是其中的参与者的文档)。PI可负责存在信息、例如指示列于用户的朋友列表上的每一方的发起状态的信息以及其他存在信息。SUI可负责内容的辛迪加。PTI可负责设定和得到对用户的内容的读和写访问的准许。II可负责对用户的空间的一次邀请，它可设定与PTI不同的准许设置。UDMI可负责管理用户数据、如简档和地址簿。AMI可负责用户的内容的关键字保护和关键字管理。SI可负责查询用户数据和用户内容(如搜索系统100的所有用户公共可用的信息和内容或搜索私人信息如只对文档参与者可用的信息)。WSI可负责把web服务集成到运行于用户设备108上的客户端应用中。例如，WSI可采用简单对象访问协议(SOAP)协议进行通信并可具有Web服务描述语言(WSDL)的内置支持。

网关110是服务器侧的应用，其可创建本发明实施例的多媒体消息传送系统和其他通信系统之间的网桥。例如，网关110可包括一个或多个以下网关：SMS/MMS网关(SMSG)、电子邮件(电邮)网关(eMailG)、存在网关(PresenceG)、即时消息传送网关(IMG)、内容流网关(CSG)和搜索网关(SG)。SMSG允许来自装置108的SMS和MMS消息由服务器102作为分段存留到存储器106中。eMailG允许把基于文本的电邮消息和具有附件的电邮消息集成到存储器106存留的文档中。PresenceG允许与其他基于存在的系统、如Jabber或Wireless Village、循规蹈矩和/或简单的系统集成(因此采用了来自这些系统的存在信息)。IMG允许与基于即时消息的系统如Jabber、AIM、Wireless Village和ICQ集成。CSG允许与流式技术集成(如流式音频和视频)。SG允许与现有搜索技术如Google和MSN搜索集成。例如，在用户设备108上显示的图形用户接口(GUI)(如与运行于设备108上的客户端应用相关联的GUI)中输入的搜索词语可由SG转换为搜索技术可识别的格式，并随后提供给搜索技术。由搜索技术返回的搜索结果可转换成合适的格式(如XML构造语言nml)，并在使用户设备108显示此结果之前用元信息(如指示用于搜索的搜索技术的的源信息和/或与搜索技术的搜索结果一起提供的任何元信息)标记。

服务器102通常向用户设备108发送SMS(文本)或因特网协议(IP)分组通知以警告该设备例如netomat消息或更新(如更新存在信息和/或更新辛迪加内容)可用。关于SMS消息，消息的具体的形式和内容可根据通知所针对的装置是客户端还是无客户端装置而变。为此，netomat服务器102可在存储器106中存储或者访问安装有客户端(如移动装置)的装置列表。

例如，响应服务器102确定出移动装置108是无客户端装置，服务器102可经由SMS向该装置发送通知，其中SMS通知指示可从服务器102得到新消息和/或更新信息。SMS通知可包括例如文档(或其一部分)或其他内容，如由服务器102存留在存储器106中的辛迪加内容的外部链接。自动地在接收以无线应用协议(WAP)推出消息形式的通知时(例如)或响应于用户选择链接，无客户端移动装置的浏览器可访问并为用户播放文档或辛迪加内容(如在移动装置的显示区域中显示视频、文本或图象，经由移动装置的扬声器传送音频或它们的组合)。还可显示其中用户可输入和递交文本以便消息传送响应的一个或多个字段。在另一示例中，系统100可允许无客户端移动装置的用户用SMS消息响应通知，其可作为文本分段由服务器102存留在存储器106中。

或者，响应于服务器102确定出移动装置108安装了客户端应用以便进行多媒体消息传送，服务器102可向装置发送在通知首部中包括客户端应用的端口号的SMS通知。这在移动装置接收到消息时可触发客户端应用的自动启动。一旦启动，客户端应用便可访问由服务器102存留于存储器106的文档(在SMS通知中可提供的链接)并允许用户发出多媒体消息响应。此外，当客户端应用处于发起状态时，消息或更新的通知可由服务器102通过IP信道而不是经由SMS发送。为此，服务器102可存储或访问指示其上安装有客户端的移动装置中的哪些处于发起状态的数据。以下结合对一字节的“懒惰”推或拉式通知的描述提供了有关由服务器102确定运行于移动装置108上的客户端应用是否在发起状态的其他细节。

系统100中的再现引擎112可以是显示和/或操纵系统中由用户设备108消息传送的多媒体内容和/或其他内容(如辛迪加内容)的软件模块。例如，再现引擎112可在物理空间中生成公共显示，如电子广告牌或音乐会投影。备选地或另外，再现引擎112可在因特网页(如万维网页)上发布内容。内容的发布和处理可实时发生，如从移动和桌面装置投票或轮询。再现引擎还可根据用户的静态输入产生类似电影的动漫经历，在此意义上，再现引擎可自动按照分段在远程站点存留的顺序回放文档的这些分段。

图2A是由在例如根据本发明的桌面装置上显示的多媒体客户端应用提供的说明性显示的屏幕抓拍。在图2A中，为用户显示由服务器102存留于存储器106中的文档。更具体地说，图2A提供了用户空间的概况，其可概念化为其中用户是文档参与者的文档集合(即用户具有著作权的文档集合)。如图所示，目前在显示屏内选择了题为“MIKE′S 25TH”的文档202。因此为用户显示了文档202的分段204、206和208，每个分段包括含有文本和图象和对应元信息(如作者、日期和时间)的多媒体。该显示还可包括各种可选择的选项。还提供了选项210、212和214以便允许用户分别选择文档“IT′SA GIRL”、“HAPPY BI…”以及“DECEMBE…”进行显示。可提供选项216以便允许用户创建新文档。回复字段218可允许用户向当前文档202的参与者递交针对通信的多媒体响应。如图所示，可从装置的本地存储(“MY COMPUTER”选项220)或远程存储中(如在专用于存储用户特定的内容(“My Gallery”选项222)的存储器106中)的分配中选择多媒体(如图象)以包括在响应中。“FunStuff”选项226可允许用户访问来自远程存储的第三方多媒体内容(如辛迪加内容)。预览(Preview)窗口224可允许用户在发送多媒体消息之前预览图象。选项228可指示要参与文档中的两个新的邀请是用户可用的。选择选项218可允许用户查看邀请和/或关于邀请的发送器的简档信息。选择接受邀请可导致对应的文档及其相关联的信息出现在显示屏中。

图2B是图2A中显示的相同文档202的屏幕抓拍，如根据本发明的实施例由运行于移动装置上的多媒体内容应用所显示的。移动用户可用的选项可以与图2A的示例中提供给用户的那些类似或相同。然而，由于移动装置的显示屏更小，因此可能需要用户例如滚动显示来访问选项。

图3是根据本发明消息传送媒体所需的说明性步骤的流程图300。在步骤302上，服务器102可从用户设备108(如移动用户设备)接收打算传递给一个或多个接受器(如移动用户设备的另一安装)的媒体消息。在步骤304上，服务器102可把媒体消息作为文档存储在(如远离媒体消息的一个或多个接受器和发送器的)存储器106中。在步骤306上，服务器102可把消息传递给一个或多个消息接受器。例如，服务器102可通过向接受器传送文档邀请或其他通知来通知该接收器接收消息，并可响应于接受该邀请的接受器把消息传递给接受器。把消息传递给接受器包括发送链接给远程存储的消息和/或传送(如流出)所有消息或消息的一部分给接受器设备。在优选实施例中，来自消息的多媒体内容最好作为压缩的ASCII二进制编码资产传递给接受器，以下将结合图5和图6对这进行描述。在步骤308上，服务器306可在把远程存储器中的文档传递给一个或多个接受器之后维护它，这可允许未来的消息中参照和/或再用文档(及其多媒体内容)。在一个实施例中，服务器102可把已经接受邀请加入文档或让消息作为分段附加到文档的用户指定为文档中的参与者，由此在用户之间创建了关联。此关联可建立用户的共同体，这些用户可具有特定于该共同体的功能。

在本发明的一个方面中，提供了允许移动用户108通过多媒体消息传送(如消息传送文本、图象视频和/或音频)与其他基于移动的装置的用户合作的系统和方法。例如，由移动和非移动装置108产生的多媒体消息可在服务器102把消息和相关联元信息作为文档(如或者文档的分段)存留在远离消息发送器和接受器的存储器106中之前用识别元信息(如作者、日期、时间和/或位置)自动标记。作为另一示例，可提供单个附加的功能，它允许不同装置108的用户同时写到(如添加或修改)存储的文档中(如把分段存留到远离装置存储的文档)的。在另一示例中，可提供社会联网协议(如“朋友的朋友”协议)，它允许存储的文档和它们相关联的多媒体内容(以及可选地还有元信息)由除了最初的消息接受器以外的其他方进行访问。现在更详细地描述这些特征。

消息传送内容的自动元信息标记

Web资源包含提供关于作者身份、链接、关键字和描述符的信息的元标签。此信息用于文档的搜索和机器处理。目前用于这方面的一种方法是RDF，它是XML的扩展，提供了具有用于著作、操纵和搜索机器产生的元数据的工具的框架，这些元数据随后可由其他机器有效地处理。

目前通过如RDF标签的方法提供元数据需要一些人为输入(例如明确地支持信息或输入标签)。然而，自动插入标签是描述通信系统中创建的文档的量所必要的，特别是在其中多媒体消息传送系统允许经由分段附加操作同时更新(以下更详细描述)的本发明的实施例中，情况尤其如此。

在一个实施例中，本发明采用自动标记元信息来描述每个文档或其一部分。例如在每个文档包括一个或多个分段的优选实施例中，文档内的每个分段可用指示创建位置、日期和分段的作者的元信息标记。就移动装置而言，位置信息可基于例如全球定位系统(GPS)测量的移动装置的全球位置、移动装置的标识符(如蜂窝ID)和/或基于用户的输入(如用户在纽约州的用户指示)产生。非移动装置的位置信息可基于GPS或响应于用户输入(如其中用户陈述了用户的装置所在的邮政区码的用户的用户简档)。基于元信息，可搜索、编辑和组织分段和文档，这些变化可由其他用户查看。

自动标记元信息有助于确保更新的信息正确地被标记以便以后使用。在一个实施例中，在消息发送给服务器102之前运行于用户设备108上的客户端应用可用作者、日期、时间和位置标记新消息(所有这些是发送装置的功能)。在另一实施例中(如当消息从无客户端装置发送时)，服务器102可在把消息存留在存储器106中或把该内容传送到分布式布置的另一服务器之前用元信息标记消息。图4显示了根据本发明的实施例在创建文档时元信息的插入。具体而言，文档的分段用分段名称＝“fragment”，作者姓名＝“Maciej”，日期和时间＝“27-Jul-04 16:21PM MST”和位置信息＝“Paris”和“:::Latitude：19degress-45minutes-32.4seconds-north:::Longitude：155degrees-27minutes-22.8seconds-west:::Altitude：2300feet”来标记。这些分段随后追加到可包括一个或多个之前的其他分段形式的关联消息的文档上。

具有一次追加操作的全局用户管理文件系统

系统100可提供可从任何装置108全局访问的内容管理系统，并可提供搜索、分类、发送、删除、共享和再用多媒体资产的能力。相反，常规文件系统对正在读取或更新的文件的访问进行“锁定”，同时把对于那些文件的其他请求增加到队列中。锁定访问需要额外的处理时间和服务器存储器，并可导致更新丢失、实际未保存下来以进行上传的数据变化和重新读取更新的文件的问题。

系统100提供的全局文件系统提供了避免了以上问题的简单而有效的更新文件的方式。在优选实施例中，由于所有文档可通过追加新分段而不是覆盖现有分段来改变，因此文档内的随机写实际上是不存在的。因此一旦被写入，则文档里的分段便是只读的，而且对于大部分是顺序读取的。全局文件系统可以是基于域的系统，其按目录分级组织文件并通过域内的路径名来识别它们，如路径：

/m/a/c/iej/travel/index.v45.nml

其可设在域内：

http：//www.netomat.net

全局文件系统支持标准的打开、关闭、删除、读取和写入操作，以及分段追加，其允许多个装置108在保证每个装置的追加的完整性的同时把分段同时追加到文档。

此分段方法比传统分布文件系统简单的多，因此更易于扩展并具有更好的容错能力。分段方法还有助于避免在不同终端用户装置之间进行数据同步的需要。这些问题均由当前的基于web的协议(如WebDAV)而产生，该协议通过利用锁定机制允许用户共同编辑、发布和管理Web资源，但是也容易出现扩展性问题并且不提供分段追加功能性。

在消息传送流和协议层内建立社会联网协议

目前的社会联网应用提供了许多用来识别用户之间的交换或关系的途径，也提供了鼓励用户构成社会网络的特征。在一个实施例中，本发明通过对交互模式更细致的研究而促进了社会联网。

本发明针对给定的一套移动装置基于装置之间的实际交互操作提供了自动定义合适的社会规则有时也称为社会契约的方法。例如，用户创建的文档可采用“朋友的朋友”协议链接，其只允许互相认识或已经彼此介绍的人来发送和接收消息，该消息随后可作为分段追加到文档上。

例如，朋友的文档可在消息由接收方接收(即与忽略或删除相反由接收方访问)时创建，由此在发送方和接收方之间创建了“信任链接”。通常，此信任链接将仅针对即时文档是有效的，也就是说不将让接收方访问发送器所参与的其他私人文档，反之亦然。这样，朋友的朋友的网络可由于在用户之间的正进行的通信/合作而有组织地生长。

作为另一示例，朋友的列表(有时也称为伙伴列表)可以是用户建立的或自动由服务器接口104的邀请、预定和通知处理而产生的。

还可提供作为由用户创建的用户数据的集合的简档来表示和描述它们自身，不过可允许用户隐藏或限制对他们的简档的访问。简档用来识别网络内的用户。系统100可支持多媒体简档以及在某通信期间简档的“反向查询”，这意味着(例如)消息接受器在从发送器接收消息之前可查看消息发送器的简档。简档是用户的公共简档。

变化的信任度可属于不同的社会链接。例如，可在朋友的列表的成员之间指示最大的信任度。这种变化的信任和/或其他用户偏好可用来过滤系统100允许交付给用户的要加入社会网络的邀请类型。例如，系统100可允许把一方的邀请交付给用户，除非基于例如分布列表或主题标签的属性(类似于用于电邮的SPAM阻塞)确定出消息是该反对的。

系统100自动进行创建社会协议的处理。因为系统上的每个消息均标记有元信息、被存储起来(除非用户删除它)并且可搜索以便稍后使用，所以系统100可追踪网络中出现的任何社会结。重要的是要注意此能力仅可应用于消息分段之间的链接，以及注意如何访问消息而不是消息的内容。

在本发明的另一方面，提供了促使多媒体消息交付给移动装置的系统和方法。例如，基于XML的多媒体消息可利用XML“短码”进行编码，它减少了发送器编码的XML的量以及接受器译码的XML的量，这对于把消息传递给接受器是必需的。在另一实施例中，只有文档的一部分可在给定时间根据例如通信网络的带宽和/或等待时间和/或移动装置的处理和/或存储能力传递给移动(或非移动)装置。在另一实施例中，消息的非文本多媒体可作为内嵌ASCII编码二进制资产传递给移动装置，同时消息的文本部分传递给装置。在另一实施例中，移动用户108可通过“懒惰”的推和/或拉式通知协议与服务器102通信，其中移动装置108和服务器102仅在装置或服务器经历状态变化时通信。在另一实施例中，移动装置108可在一次请求中向多个服务器接口104发出多次呼叫信息。在另一实施例中，服务器102可在辛迪加内容服务器(如提供新闻馈送的)和一个或多个移动装置108之间用作中间件。这可避免内容存储器的重复并减少了网络流量。现在更详细地描述这些特征。

缩减的编码-XML短码

本发明的实施例提供了尤其是在无线网络上更有效地传送基于XML的文档的方法。虽然传送大小的减少是所有通信方法的目标，但对于其中效率受低带宽和高系统开销影响的资源有限的装置如移动电话而言，它是主要考虑因素。本发明在不需要其他编码软件的情况下减少了文档大小，由此减小了传送大小并且避免了编码和译码文档的计算负担。

现有消息传送系统有赖于在网络上更有效传送编码数据的两种方法。这两种方法是二进制编码和二进制压缩。两种方法就解释编码的传输所需的系统开销而言均具有效率作用。

二进制编码方法如WBXML(无线二进制XML)，其编码文件为二进制格式。二进制编码的缺点包括处理用户设备和多媒体服务器上的与编码和译码相关联的系统开销以及处理用于存储编码/译码软件的其他存储器的系统开销。

数据压缩是用于减小存储和传送文档所需要的系统开销和网络带宽的另一传统方法。由于采用二进制编码，因此数据压缩需要解译，由此在每个装置上需要压缩/解压缩软件，以及在传送/再现处理中由于压缩/解压缩而引入了等待时间。

在一个实施例中，本发明提供了第三个解决方案，它通过识别可再用的标记语言和用短码替代该语言而不需要XML编码。在多数情况下，这比二进制编码和数据压缩更有效。本发明减少了文档大小，节约了网络带宽，并且不需要其他软件，由此节约了装置上的存储空间并且不需要系统开销处理。在其中系统100传送基于nml(netomatic标记语言)的文档的优选实施例中，短码是(nml)短码。nml是以上结合美国公布No.20020178164描述的遵守XML的语言。

nml短码表示一个或许多个nml编码单元。短码把nml单元的基础结构分解成单个编码单元。短码可用来代替任何nml树/子树。短码在应用识别出nml单元的默认值时被插入，并且当那些值在nml应用的生命周期内保持一致时。短码由现有分析程序和解释程序处理，现有分析程序和解释程序允许更有效地处理复杂文档而不需要额外的预处理。

例如，nml<toolbar>单元包含定义nml应用的用户接口的单元和属性；属性如布局、看和感觉以及功能。以下显示了具有子单元和属性的<toolbar>定义的示例：

<toolbar type＝″all″>

  <formContainer name＝″AddImage″id＝″003″>

    <submit action＝″http：//mobile.netomat.net/account/addImage.jsp″

    target＝″ImageForm″method＝″GET″id＝″01″name＝″Add Image″>

    </submit>

  </formContainer>

</toolbar>

例如，以上编码的树结构可表示如下：

因此，每当需要用户接口时不传送此结构(如以上树所表示的)的整个<toolbar>定义，而是发送短码。

如下是用于这种情况下的短码：

<toolbar type＝″all″/>

<toolbar>短码隐藏了定义布局、看和感觉以及功能性的属性。通过在工具条单元的最初传送中提供属性值“类型＝全部”，而把属于该单元的子树标记为符合条件的短码。下次在应用接收具有如以上示例的“类型＝all”的属性的<toolbar>单元时，该应用把<toolbar>识别为短码。

在另一示例中，可采用短码<slideshow>来产生一序列图象，如下简单编码所示。应当注意，在如何把这序列图象再现给屏幕的客户端应用时可它移至客户端应用。例如，图象可预加载并通过用下一图象替代这一副图象来循环，或者一旦该项被选择的话它们可一个接一个地显示于可滚动的区域中。

<slideshow x＝″10″y＝″10″width＝″150″height＝″136″period＝″9000″>

    <image src＝″/107-0784_IMG20634.JPG″y＝″24″width＝″150″height＝″112″/>

    <image src＝″/107-0785_IMG20633.JPG″y＝″24″width＝″150″height＝″112″/>

    <image src＝″/107-0786_IMG20632.JPG″y＝″24″width＝″150″height＝″112″/>

    <image src＝″/107-0787_IMG20631.JPG″y＝″24″width＝″150″height＝″112″/>

    <image src＝″/107-0788_IMG20630.JPG″y＝″24″width＝″150″height＝″112″/>

    <image src＝″/107-0789_IMG20629.JPG″y＝″24″width＝″150″height＝″112″/>

</slideshow>

因此，重复的编码由识别属性标记，并且在随后的通信中不重新发送冗余编码。采用此方法，可缩短码大块的消息交换，从而有效地减小了通过网络传送的文件的大小。在一些情况下，短码可在通过预定的短码消息交换之前指定。如果客户端应用不识别短码，则客户端应用可向服务器102发送消息，并且随后重复的编码将被完整地发送。

任意长度的多媒体消息和消息线程的交付

在另一实施例中，本发明消除了与通过具有有限带宽和较长的等待时间的网络把大型文件和任意长度消息交付给具有有限存储的装置相关联的问题。例如，XML更具体地说是遵循XML的语言nml提供了用以创建“大块”文档的简单的解决方案，作为更复杂的方法的备选例如有把XML分段重新编排到文档中的XML分段规范。

在nml的情况下，对文档大小没有限制，nml分段提供了按大块交付文档的灵活性；即与完整的文档相反数据大块属于更大的文档。

分段是文档的一部分并且足够小以便它可交付到例如可能具有有限存储器和处理能力的移动装置108。一次交付分段的数量可基于网络吞吐量和装置能力。系统100可通过网络加载随后的分段，从而表现出文档在本地被滚动。

在一个实施例中，本发明提供了在合适的情况下基于网络带宽和装置108交付1至n个分段的能力。对于可传送的分段的数量没有上限。所传送分段的默认数量可作为用户偏好而被动态覆盖。

nml分段可包含0个或多个nml对象(单元)，nml对象定义为时间和空间中的对象，意指它们包含定义作者的属性(如前所述的元信息)、最近修改的日期/时间标记和其地理位置(在可用时)。图4显示了nml分段。

此元信息使nml分段成为“自我意识”的，意指需要重新编排此文档的信息包含在它们自身的分段里。分段不需要分段外的任何规则或知识。任何两个nml分段可基于此自我意识进行分类。

内嵌压缩的ASCII编码的二进制资产

由于移动网络不断扩展，因此也的确需要更快、更高效地并且用户友好地向具有小屏幕特征且容易受到不可靠网络连接和较低的带宽的影响的装置交付格式化多媒体显示。跨过移动和固定网络交换消息中的多媒体的现有方法在与本发明比较时需要指数级地更高数量的客户端/服务器呼叫/响应，因此对网络有更高的要求，使传送会话遭网络故障影响以及使用户等待更长的时间。

常规移动应用如电话浏览器需要以下步骤来加载多媒体文件、如包含图象的HTML或XHTML。第一步，响应于用户对HTML文件的请求必须加载HTML文件。接下来，必须加载HTML文件中每个嵌入的图象，其中每个嵌入的图象要求单独的用户请求。MMS和其他消息传送系统采用类似的步骤。多次呼叫信息可由于一次或多次呼叫未由服务器接收或由于移动装置接收的内容中的传送错误而导致错误。

在一个实施例中，不像常规系统系统100通过不进行多次呼叫和减小消息尺寸而高效地把多媒体内容交付给移动装置108。具体而言，移动装置108的单次呼叫使得服务器102传送包含ASCII编码的nml文件和压缩多媒体资产(如由服务器102压缩和编码的)。当压缩时，ASCII编码和压缩文件小了百分之十二到三十。另外的百分之十的优点通过减小每次TCP/IP连接所需的系统开销(即通过减小呼叫/响应次数)来获得。交付一个消息中包含多个资产的消息的能力导致更快速的交付并且交付明显改进的用户经历。系统100仅适用于其中需要减少受到网络不可靠性和较差连接的影响的移动环境。系统100还通过限制服务器必须响应的呼叫数量来节约服务器102的资源。例如，图5是移动装置显示屏的屏幕抓拍，其中响应于服务器102的单次呼叫把七副图象502-514(以及相关联的文本)传送到移动装置(图1)。

图6是显示了把包括五副图象(大小总共为50k)的内容作为内嵌压缩的ASCII编码二进制资产交付给其上安装了多媒体客户端应用的移动装置所需的交付时间(其中消息是nml消息)与发送相同内容到移动装置的HTML浏览器所需的交付时间(在没有进行ASCII编码二进制资产的内嵌压缩的情况下)的比较。更具体地说，如果在28.8kbps线路上交付，交付压缩的ASCII编码二进制资产需要48.4秒，而交付相同内容到HTML浏览器需要66.5秒。

以下显示了针对包括三副图象的nml文件的说明性编码。在此示例中，内嵌消息利用包括LZ77算法和Huffman编码的组合的标准数据压缩算法进行压缩，并被编码为Base64。一副内嵌图象(如1272字节)比JPG格式的原始图象(如1564字节)更小。

＜？xml version＝″1.0″encoding＝″ISO-8859-1″？＞
＜nml＞
＜img enc＝″base64″id＝″mzw:::userpic″src＝″user/profile/photo_smallthumb.jpg″x＝″0″
y＝″0″＞
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJ
ChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKCh
MoGhYaKCgoKCgo
KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAA.
RCAAYACADASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtR
AAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRo1
JicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKT1JWW
15iZmqKjpKWm

p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+T15ufo6erx8vP09fb3+Pn6/8QA
HwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBA
QAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOE18RcYGRomJygPKjU2Nzg
5OkNERUZHSE1K
U1RVV1dYYWVpjZGVmZ2hpanN0dXZ3eH16goOEhYaHiImKkpOU1ZaXmJmaoqOkpaanq
KmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxE
APwD58u7C
6upHeCOeQKOSnPPoB3rv/DfgfwxNaIPEuq3Ud4RnbbFFVPY5DZ+owKqJo8Nkkk9vf7tq8
q0eS3Pq
D7+1Yime7u50EG0DLIWcAMAPU4/zxXA5tqyO2NOK3Ra8XeHLLRp0ewuVu7Fv1SR1A
ZTjgHsfr7Hg
VyOqKGhQLyM5xmuotop77RLoXCPBBDIsquehGCDjt3rDMbbf3UcsiEnay9CP85raKsY1
Ensei6B4
HZvD15qGoXrx3scXnR2cagNt/vMeencAccZIr1rxbgSjIIKthQ4B5z0wevTpRRS1BXLhNpH
U+HdI
fXdO1PS7qWaz1EbFZnO5IypCmN1GcA1gN3Y99j0rk5tG1Pwprw07UJInUSeU/lybo+cfNnH
HBB/Oi
iuunBPQ6Mbh4wpKotz//2Q＝
＜/img＞
＜img enc＝″base64″id＝″mzw:::userpic″src＝″user2/profile/photo_smallthumb.jpg″x＝″0″
y＝″0″＞
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJ
ChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKCh
MoGhYaKCgoKCgo
KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAA
RCAAYACADASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtR
AAAgEDAwIEAwUFBAQA

AAF9AQIDAAQRBRIhMUEGEIFhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRo1
JicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaG1qc3R1dnd4eXqDhIWGh4iJipKT1JWW
15iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+T15ufo6erx8vP09fb3+Pn6/8QA
HwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBA
QAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOE18RcYGRomJygpKjU2Nzg
5OkNERUZHSE1K
U1RVV1dYWVpjZGVmZ2hpanN0dXZ3eH16goOEhYaHiImKkpOU1ZaXmJmaoqOkpaanq
KmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxE
APwD58u7C
6upHeCOeQKOSnPPoB3rv/DfgfwxNaIPEuq3Ud4RnbbFFVPY5DZ+owKqJo8Nkkk9vf7tq8
q0eS3Pq
D7+1Yime7u50EG0DLIWcAMAPU4/zxXA5tqyO2NOK3Ra8XeHLLRp0ewuVu7Fv1SR1A
ZTjgHsfr7Hg
VyOqKGhQLyM5xmuotop77RLoXCPBBDIsquehGCDjt3rDMbbf3UcsiEnay9CP85raKsY1
Ensei6B4
HZvD15qGoXrx3scXnR2cagNt/vMeencAccZIr1rxbgSjIIKthQ4B5z0wevTpRRS1BXLhNpH
U+HdI
tXdO1PS7qWaz1EbFZnO5IypCmN1GcAlgN3Y9j0rk5tG1Pwprw07UJInUSeU/lybo+cfNnH
HBB/Oi
iuunBPQ6Mbh4wpKotz//2Q＝
＜/img>
＜img enc＝″base64″id＝″mzw:::userpic″src＝″user3/profile/photo_smallthumb.jpg″x＝″0″
y＝″0″＞
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJ
ChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKCh
MoGhYaKCgoKCgo

KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAA
RCAAYACADASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtR
AAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRYS0fAkM2JyggkKFhcYGRol
JicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKT1JWW
15iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+T15ufo6erx8vP09fb3+Pn6/8QA
HwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBA
QAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOE18RcYGRomJygpKjU2Nzg
5OkNERUZHSE1K
U1RVV1dYWVpjZGVmZ2hpanN0dXZ3eH16goOEhYaHiImKkpOU1ZaXmJmaoqOkpaanq
KmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxE
APwD58u7C
6upHeCOeQKOSnPPoB3rv/DfgfwxNaIPEuq3Ud4RnbbFFVPY5DZ+owKqJo8Nkkk9vf7tq8
q0eS3Pq
D7+1Yime7u50EG0DLIWcAMAPU4/zxXA5tqyO2NOK3Ra8XeHLLRp0ewuVu7Fv1SR1A
ZTjgHsfr7Hg
VyOqKGhQLyM5xmuotop77RLoXCPBBDIsquehGCDjt3rDMbbf3UcsiEnay9CP85raKsY1
Ensei6B4
HZvD15qGoXrx3scXnR2cagNt/vMeencAccZIr1rxbgSjIIKthQ4B5z0wevTpRRS1BXLhNpH
U+HdI
fXdO1PS7qWaz1EbFZnO5IypCmN1GcA1gN3Y9j0rk5tG1Pwprw07UJInUSeU/lybo+cfNnH
HBB/Oi
iuunBPQ6Mbh4wpKotz//2Q＝
＜/img＞
＜/nml＞

以下显示了包括三副图象的HTML文件的参照的说明性编码。每个图象的大小是1564字节，并需要单独呼叫服务器。由此，为显示此文档，需要呼叫服务器四次(即一次请求文本和三次其他的请求，每副图象一次)。<html><head><title>Document containing three images</title></head><body><img src＝″user/profile/photo_smallthumb.jpg″alt＝＝″User picture″><img src＝″user2/profile/photo_smallthumb.jpg″alt＝″User picture″><img src＝″user3/profile/photo_smallthumb.jpg″alt＝″User picture″></body></html>

一字节的“懒惰”推或拉式通知

移动装置使用的迅速发展不断地对跨越移动和固定网络实现的消息传送系统提出越来越多的要求。就带宽和连接可靠性而言，目前的网络具有通常会导致消息丢失或被破坏的明显限制。目前的消息传送系统由于带宽和网络可靠性而面临若干问题。

在一个实施例中，本发明通过使消息交换所需的网络流量最小来为移动和固定网络提供更快速、更灵活的消息传送系统。本发明最大化了网络和装置资源(如带宽和存储)，同时允许用户选择他们下载到他们的装置的信息。

具体地说，本发明涉及控制消息和数据的交换的通知方法。本发明提供了巩固用户状态、更新、消息和/或其他信息的交付机制(如一字节交付机制)。一字节通知通过把装置状态信息与控制装置和服务器102之间的内容和消息的交付的信息聚集起来，使网络流量最小。相反，常规消息传送系统需要单独通知装置状态中的信令变化和数据中的信令变化。在常规消息传送系统中，与一字节通知方法相反其流量以千字节计量。

图7显示了根据本发明的实施例的一字节通知的流程图。在步骤A，用户设备向服务器发送指令(如终端用户定义的指令)以规定在例如文档改变或更新时(如当辛迪加内容的更新可用时或当用户已存留对该用户所参与的文档的响应时)通知用户设备。用户设备还可当更新可用时规定它是否将接收一字节通知的更新、更新的概要或实际更新本身。在步骤B，服务器接收指令。在步骤C，全局文件系统(以及其他设备如存在接口)向服务器提供更新，这些更新包括与用户偏好相关的更新。在步骤D，基于用户的偏好，服务器向用户设备“推”出用户的更新的一字节通知(警告)、更新概要或用户在步骤E接收的实际更新本身。对于警告或概要，在步骤F终端用户可选择忽略或下载更新。响应下载更新的请求，在步骤G服务器把更新推向用户设备，并在步骤H用户设备接收该内容。在另一实施例中，用户设备可执行“拉”通知过程，其中用户设备例如每隔“n”秒查询服务器以便请求更新服务器(如除了警告服务器有关用户设备的状态之外)。

根据本发明的一字节通知可采取各种形式。例如，在一个实施例中，8比特(一字节)通知可用于存储一个ASCII字符如Y、N、S或P，其中每个字符可表示特定内容的通知(或请求)(如只有有关辛迪加内容更新的通知)或任何/所有更新内容(如“Y”字符表示在没有规定更新类型的情况下更新可用的通知)。在另一实施例中，8比特可用来表示代表特定信息的状态编码，如0-99表示存在(如可用或繁忙)的状态信息，100-199表示文档的状态信息，而200-255表示错误编码。在另一实施例中，8比特可用来定义变化类型(如4比特)、如文档的有效日期的改变和与那些变化相关联的属性(4比特)、如指示变化是紧迫的或需要对变化进行确认或其他一些行为。

服务器接口的动态级联

服务器的请求必须正确地格式化以便服务器可读取请求和格式响应。其上安装了客户端应用的移动装置108可利用单次呼叫从各种服务器接口104请求信息。在另一实施例中，服务器可提供具有发送这种级联呼叫的选项的无客户端装置。采用常规方法，如CGI(普通网关接口)和HTTP，把这种请求分成多次呼叫，每个接口一次。相反，根据本发明的客户端应用可产生例如从存在接口和用户搜索的接口的请求信息的呼叫。单次呼叫可包括一系列传统HTTP呼叫，每个呼叫均有稍稍修改的导致服务器同时处理HTTP呼叫的理由。本发明以更有效的方式利用标准和协议(HTTP)。服务器可把所有请求的内容合并为它发送给请求装置的单次响应。

HTTP提供几个有用的客户端/服务器呼叫如把数据发送给服务器的HTTPPOST和请求响应的HTTPGET。复杂的系统需要有效的方法来发送多个复杂的请求。web应用通常由几个HTTPPOST请求和HTTPGET请求组成，例如HTTPPOST请求可用来把用户数据提交给服务器，另一HTTPPOST请求可用来登记任何用户。

为发送这种请求，客户端应用自动级联不同请求和响应，而不是给每个接口104发送单独的请求。接口是在客户端和服务器之间进行连接以便它们可交换信息的点。每个接口是接口继承了更高级接口的属性的层次结构的部分。这种继承通过组合多个接口的功能性而延伸了服务器接口104的能力，因为这些接口在单次请求期间可把更多消息传送给服务器；例如，在对服务器102的单次请求中接收用户状态和新用户数据。

例如，图8显示了根据本发明的实施例的动态级联服务器接口。如图所示，第一移动装置可在对服务器102单次完整的呼叫中访问其存在、版本和通知接口。第二移动装置可对服务器102的接口执行单独连续的呼叫。非移动装置可对预定和搜索接口执行单次集成的呼叫，以及对资产管理接口执行单独的呼叫。

作为另一示例，系统100中的存在接口与文档紧密耦合。人可即具有全局存在也可出现在文档或文档的集合里。具有存在的netomat文档变为生动的合作环境。如结合图1所述，存在接口(PI)负责用户的存在和可用性。通知接口(NI)负责通知用户他们的空间和他们参与的空间的更新。用户通知可采用拉或推式机制。通过邀请、预定和通知接口来创建并自动管理联系列表。PI接口可具有以下结构：

<hdlr value＝”prsnc”>

  <param name＝”avlblty”value＝”available”/>

  <param name＝”status”value＝”busy”/>

  <param name＝”mood”value＝”happy”/>

  <param name＝”ticket”value＝”

 VNdzTYIYkqF1Qo56sucz4ale1d/RvCRufnIFQRNfdTA＝”/>

  <param name＝”docroot”value＝”/maciej/NewYork/index.nml/>

  <param name＝”lng”value＝”eng”/>

  <param name＝”alias”value＝”Superwoman”/>

  <param name＝”contact”value＝”http：//mobile.netomat.net/maciej/profile”>

</hdlr>

NI接口可具有以下结构：<hdlr value＝”add”>

<param name＝”nmv”value＝”path_to_history_file”/>

<param name＝”ticket”value＝”VNdzTYIYkqF1Qo56sucz4ale1d/RvCRufnIFQRNfdTA＝”/>

<param name＝”user”value＝”user_name”/>

<param name＝”time”value＝”polling_or_push_time”/>

<param name＝”extends”value＝”PresenceInterface”/>

<param name＝”implements”value＝”Version”/></hdlr>

以下是采用具有级联的存在和通知接口的公共网关接口的简单的HTTP GET请求和服务器响应。通知接口继承存在接口并实现DocumentListener接口。

GET/account/cgi-
bin/gettime2.cgi？nmv＝/maciej/NewYork/index.nmv&time＝30&user＝maciej&r＝0.44471429
614350&extends＝PresenceInterface&implements＝DocumentListener2 HTTP/1.1
Accept：*/*
x-flash-version：7，0，19，0
Accepr-Encoding：gzip，deflate
User-Agent：Mozilla/4.0(compatible；MSIE 6.0；Windows NT 5.1；SV1；.NET CLR
1.1.4322)
Host：mobile.netomat.net
Connection：Keep-Alive
Cookie：JSESSIONID＝94A4AD4182586179AD64097BF51637B1.mobile-0
HTTP/1.1 200 OK
Date：Wed，03 Nov 2004 18:54:05 GMT
Server：Apache
Content-length：50
Keep-Alive：timeout＝15，max＝94
Connection：Keep-Alive
Content-Type：text/plain；charset＝ISO-8859-1
＜nmv path＝”/maciej/NewYork/index.nmv”＞
＜lm＞1099507331＜/lm＞
＜user type＝”br”＞maciej
＜param name＝”avlblty”value＝”available”/>
＜param name＝”status”value＝”busy”/＞
  <param name＝”mood”value＝”happy”/>
  <param name＝”ticket”value＝”
VNdzTYTYkqF1Qo56sucz4ale1d/RvCRufnIFQRNfdTA＝”/>

  ＜param name＝”docroot”value＝”/maciej/NewYork/index.nml”/＞
  ＜param name＝”lng”value＝”eng”/＞
  ＜param name＝”alias”value＝”Superwoman”/＞
  ＜param name＝”contact”value＝”http：//mobile.netomat.net/maciej/profile”＞
＜/user＞
＜/nmv＞

服务器响应返回最后修改的串以及文档装订的存在信息，′br′指示用户正在使用浏览器。

经由中间服务器交付的辛迪加内容

辛迪加内容指允许内容消费者订购内容制作人的馈送的技术。有许多种把辛迪加内容分布到客户端/服务器环境中的格式，包括RSS(真正简单的辛迪加)和ICE(信息和内容交换)。这些格式以更简单的方式把内容分配给订户，藉此必须针对每个用户从内容服务器加载内容。考虑有大量的内容订户，因此该分布的方法将给通信网络施加大量负载，产生瓶颈，并增大了存储需要。

在一个实施例，本发明提供了以使网络业务量最小、不需要内容重复并提供了可扩展的内容共享机制的方式把内容简单地分布到上百万用户的方法。

本发明以不同于传统方法的方式实现了辛迪加内容的交付。首先，从辛迪加内容服务器馈送的所有更新聚合到担当中间调度和把更新交付给装置108的服务器102。图9说明了订购方案。通过把所有馈送聚合到服务器102，订户从原始馈送解耦，由此消除了可与当前的下载请求同时出现的瓶颈。服务器102控制业务量和隔离装置108以免产生过大的网络业务量和瓶颈。

其次，辛迪加内容保留在通过请求装置共享的服务器102上，这进一步降低了网络业务量、可能存在的瓶颈以及存储要求。服务器102定期从一个或多个辛迪加服务器下载内容，并利用客户端应用警告装置108以及在内容可得时订购辛迪加内容。客户端可选择性地请求服务器优化以便交付给客户端的更新。如果客户端请求内容，服务器102拷贝内容的参照(链接)到客户端的netomat空间(如与辛迪加内容相关联的文档的分段)中，但把实际内容留在服务器上。

此外，一个用户可容易地与其他用户共享辛迪加内容。例如，当用户选择辛迪加内容时，该内容插入到消息流中并与其他用户共享。由此新闻馈送(例如)可动态插入到正在进行的对话中，并与其他即时共享而不需要额外的监护机制。用户随后可邀请任何其他用户来共享辛迪加内容馈送。图10说明了内容是如何共享的。通知被邀者随后需要更新可被忽略或下载的新闻馈送。

用户可在组内公告评论；由此打开对话和/或形成合作文档。当一组中的成员接收了订购馈送时，该组的所有成员也接收该馈送的通知。单个组的成员可选择接收或忽略馈送，进而加强组的社会性。由于与内容分布相关联的系统开销较低并可自动把内容插入到消息中，因此组可容易地容纳例如约百万人。

在本发明的另一方面，提供了提高移动用户关于移动消息传送的各种功能性。此功能性可至少部分地由运行于移动装置上的客户端应用提供。例如，这种客户端可在由终端用户购买时从因特网下载并安装在移动装置上或驻留在移动装置上的存储器中。在另一示例中，消息传送功能性可在无客户端的方法中通过除了专用客户端应用之外的资源(如浏览器和/或媒体播放器)来提供。在一个实施例中，可提供指示例如文档是否可用于查看、文档是否已发生变化、谁正访问文档或对文档进行工作和/或文档何时最后一次更新的文档级存在信息。在另一实施例中，可提供允许用户记录、回放和编辑消息和消息线程的功能性。例如，可向用户显示用以基于存储消息内容的元信息搜索在远程站点上存储的该内容的选项。在另一实施例中，可提供“消息推送”功能以便向目前离线的用户发送消息、安排在特定日期和时间和/或地理位置交付消息和/或当用户检索到消息时连接该用户(以及零个或多个其他用户)。下面更详细地描述这些特征。

意识到网络、存在和位置的文档

在通信网络中，存在通常理解为用户的在线或离线状态。常规存在的一个示例是即时消息传送，如AOL的即时消息传送系统和“伙伴列表”，其中服务器知道用户是在线还是离线，并且还可追踪存在的更多个细致状态如忙、离开、打字和空闲。在本系统中，焦点主要针对用户。

在一个实施例中，本发明介绍了称为文档级存在的新的存在类型。作为备选或附加的是，关于用户的存在信息，本发明允许系统100的用户找到文档并合作。文档存在向用户提供有关文档状态、位置和网络意识的有意义的信息。有适当许可权的用户可看见文档是否可用于查看、文档是否已经改变、谁在访问或在给定文档上工作、谁出现在在线会话中(消息线程)以及文档最近更新是什么时候。

如上所述，nml文档可包括元信息(如作者、位置和日期和时间标记)，它是服务器102已知的，并可由用户查询。在合作环境、如不同参与者所作的签名文档和管理增量变化里文档存在是重要的。如由全球定位系统(GPS)数据提供的位置意识提供了关于文档在哪创建的信息。网络意识基于文档被转移的位置和文档存在的状态赋予它们对象调节的能力；即，如由网络状态所指示的文档可交付或追加一个或多个它的分段。例如，当安装在移动装置上的客户端应用确定客户端将要或可能要丢弃数据分组(如基于网络带宽)时，客户端可请求服务器在给定时间里发送更少的分段。对于无客户端应用，服务器可在给定时间发送默认数量的分段(如1个分段)。

在正操作文档的任何部分时，系统意识到文档的存在和位置。该信息可由具有许可权的用户查询。例如，用户可查询谁在看以及谁在某天更改了内容。文档在时间和空间里是自我管理对象；文档级的存在增加有关什么包括文档以及它是如何被处理的另一间隔水平。

消息和消息线程的记录和回放功能性

传统多媒体如web站点、照片和流式媒体文件不允许用户编辑被传送的文档，并且仅允许进行过滤或识别需要的信息以及进行回放的有限的选项。

按文档中的信息出现的动画序列进行回放对于基于时间的媒体(如以每秒数帧显示的视频或演讲)而言通常被认为是更重要的事情，这与基于非时间的媒体(如消息传送线程和公告牌)相反。然而，访问和订购信息对于基于时间以及基于非时间的媒体二者而言均是重要的。

在一个实施例中，本发明允许任何消息交换或合作以有选择地记录和有选择地回放。本发明提供了搜索和选择功能以便用户可找到并选择需要的回放信息。例如，用户可基于元信息从头到尾回放整篇文档，如这里所述的元信息定义其中媒体的分段由服务器102存留到存储器106的顺序。作为另一示例，回放命令可基于在文档中的任意点上可能出现的用户编辑来进行改变、停止和开始。

由于文档的基础结构即分段集合而使得可以具有选择性的记录/回放功能。记录的对话由小尺寸的分段集合组成，它们每个已自动标记为元信息。消息交换可通过把过滤器应用于嵌入到分段中的元信息以及预定的设置来有选择地记录(如仅回放由给定作者在特定日期、特定位置和/或在特定时间期间产生的分段)。

回放功能通过按定义的顺序加载并显示分段而实现。回放的顺序和内容可通过把不同的过滤器应用于消息以及针对消息分类算法来实时地定义和重新定义，由此可实现在文档内的任何地方开始回放。

消息推送功能

可按如下提供消息推送功能：

Alert-and-message(警告并进行消息传送)使netomat用户在用户离线时向另一netomat用户发送即时消息。如果用户离线，则它们的移动装置上的netomat应用将自动发起，警告用户有该消息。目前的移动消息传送系统可通过采用推出注册机制来“唤醒”装置上的应用。类似地，该创新可“唤醒”netomat应用或在系统上加载消息以便稍后交付。可在任何时间例如立即、在两小时里或在两个月里安排唤醒应用。Alert-and-message元信息嵌入到文档自身当中而不是作为网络功能，这使得此信息可搜索并且更不易受到交付问题影响。

Schedule-to-deliver(安排交付)使netomat用户可指定消息交付的时间和地理位置。例如，netomat用户可创建在特定日期如“2010年10月1日”在某位置如“芝加哥奥黑尔机场”上交付给另一netomat用户的消息。用户还可安排在设定时间删除消息。Schedule-to-deliver元信息嵌入到文档自身当中，而不是作为使信息可搜索并且更不易受到交付问题影响的网络功能。

Connect-on-delivery(交付时连接)使用户和其他所选择的用户可在消息成功交付时连接到正接收的用户。例如，netomat用户能在生日那天发送消息祝贺另一用户。当生日这天用户接受消息时，其他几个用户同时连接祝贺过生日的用户。Connect-on-delivery元信息嵌入到文档自身当中，而不是作为网络功能，这使此信息可搜索并且更不易受到交付问题影响。

因此，可以看出本发明提供了针对利用移动装置进行多媒体消息传送的系统和方法。虽然这里就特定实施例进行了详细描述，但这仅通过举例说明的方式进行，并不意欲限制有关以下所附权利要求的范围。具体地说，发明人设想可进行不背离权利要求限定的本发明的精神和范围的各种替代、变更以及修改。其他方面、优点和修改被认为属于以下权利要求的范围。所提出的权利要求是这里公开的本发明的表示。此外，也预计到其他未要求权利的发明。发明人保留在以后的权利要求中追加这种发明的权利。

Claims (21)

1.一种在发送器和一个或多个接受器之间将媒体进行消息传送的方法，所述方法包括：

接收旨在用于传递给所述一个或多个接受器的媒体消息；

距离所述发送器和所述一个或多个接受器的用户设备将所述媒体消息作为文档进行远程存储；

将所述媒体消息传递给所述一个或多个接受器；和

在所述传递之后维护所述远程存储中的所述文档。

2.如权利要求1所述的方法，还包括指定所述发送器和所述一个或多个接受器作为所述文档中的参与者，由此创建所述发送器和所述一个或多个接受器之间的关联。

3.如权利要求1所述的方法，其中所述接收媒体消息的步骤包括接收含有从由文本、图象、音频和视频构成的媒体类型组中选择的两个或两个以上媒体类型的媒体消息。

4.如权利要求1所述的方法，其中所述发送器和所述一个或多个接受器中的至少一个的所述用户设备是移动装置。

5.如权利要求1所述的方法，还包括：

向文档参与者提供对所述文档的访问；和

响应来自所述文档参与者的请求，修改所述被访问的文档或远程存储含有来自所述被访问的文档的多媒体内容的新文档。

6.如权利要求1所述的方法，还包括：

提供第一文档参与者可凭此通过提交响应来写到所述文档的能力；和

提供第二文档参与者可凭此通过提交响应来同时写到所述文档的能力。

7.如权利要求1所述的方法，还包括基于预定准则将所述文档的访问权授予给用户子集。

8.如权利要求1所述的方法，其中所述接收的消息和所述传递的消息中的至少一个包括简化编码的树或子树的编码结构的短码。

9.如权利要求8所述的方法，还包括规定所述短码。

10.如权利要求1所述的方法，还包括：

接收来自文档参与者的对所述文档的请求，其中所述文档包括多个分段；和

响应所述请求仅将所述分段中的一部分传送给所述文档参与者。

11.如权利要求1所述的方法，其中将所述消息传递给所述一个或多个接受器的步骤包括交付作为内嵌压缩ASCII编码二进制资产的所述消息。

12.如权利要求1所述的方法，其中将所述消息传递给所述一个或多个接受器的步骤包括：

在接收所述消息之前维持与接受器的空闲通信状态；

响应接收所述消息，将指示所述消息的可用性的通知传送给所述接受器；和

响应接收来自所述接受器的对所述消息的请求而将所述消息传递给所述接受器。

13.如权利要求1所述的方法，还包括接收来自文档参与者的更新与所述文档相关联的信息的请求，其中所述请求在相同呼叫中与一个或多个额外请求同时被接收到。

14.如权利要求1所述的方法，还包括：

接收来自辛迪加内容服务器的辛迪加内容；

距离所述文档参与者远程存储所述辛迪加内容；和

向所述文档参与者中的至少一个提供所述辛迪加内容。

15.如权利要求1所述的方法，还包括向文档参与者提供文档级存在信息，所述文档级存在信息是从由指示文档是否已发生变化的信息和识别当前访问所述文档的文档参与者的信息构成的文档级存在信息组中选择的。

16.如权利要求1所述的方法，还包括：

在将所述消息(与元信息)作为所述文档进行存储之前利用所述元信息标记所述消息；以及

允许文档参与者基于所述元信息搜索远程存储的文档。

17.如权利要求1所述的方法，还包括向文档参与者提供消息推送功能性，所述消息推送功能性是从由向当前离线的另一文档参与者发送消息、安排在特定日期、时间和/或地理位置交付消息以及当另一文档参与者检索消息时在实时环境中连接到所述另一文档参与者所构成的功能性组中选择的。

18.一种在发送器和接受器之间将媒体进行消息传送的方法，所述方法包括：

接收旨在用于传递给所述接受器的媒体消息，其中所述接受器的用户设备是移动装置，并且所述媒体消息包括非文本媒体；和

将所述媒体消息传递给所述一个或多个接受器，其中所述非文本媒体作为一个或多个内嵌ASCII编码二进制资产传递给所述接受器。

19.一种在发送器和一个或多个接受器之间便于将媒体进行消息传送的服务器，所述服务器配置成：

接收旨在用于传递给所述一个或多个接受器的媒体消息；

距离所述发送器和所述一个或多个接受器的用户设备将所述媒体消息作为文档进行远程存储；

将所述媒体消息传递给所述一个或多个接受器；以及

在所述传递之后维护在所述远程存储中的所述文档。

20.一种含有驻留在本地存储器中的客户端应用的用户设备，所述客户端应用配置成：

向用户提供产生旨在用于传递给一个或多个接受器的媒体消息的能力；

将所述媒体消息传送给服务器，其中所述媒体消息距离所述用户设备和所述一个或多个接受器的用户设备远程存储，并在所述媒体消息传递给所述一个或多个接受器之后在所述远程存储中维护。

21.一种其上具有记录有计算机可执行程序代码的计算机可读媒体，其执行包括以下步骤的方法：

接收旨在用于传递给一个或多个接受器的媒体消息；

距离所述媒体消息的发送器和所述一个或多个接受器将所述媒体消息作为文档进行远程存储；

将所述媒体消息传递给所述一个或多个接受器；和

在所述传递之后维护所述远程存储中的所述文档。

Images