CN102483833B - 移动对话系统和移动内容传递方案 - Google Patents

Abstract

本发明涉及一种对用于无线和非无线设备的音频和视频文件进行传输、传递、回放和内容管理的方法、系统和产品，以及一种新的减互联网协议(Internet‑less protocol)，用于向诸如移动电话等等的便携电子设备进行这样的传输。

Description

移动对话系统和移动内容传递方案

相关申请

本申请是提交于2009年2月4日的第12/322,537号美国申请的部分继续申请，其是提交于2002年6月6日的第10/183,756号且目前为第7,548,875号美国专利的部分继续申请，该申请要求提交于2001年6月27日的第60/301,681号的美国临时申请、提交于2001年7月3日的第60/303,115号美国临时申请、提交于第2001年8月14日的第60/312,450号美国临时申请，以及提交于2001年10月26日的第60/343,159号美国临时申请的优先权，在此结合这些申请的全部作为参考。

技术领域

本发明涉及用于无线和非无线设备对音频和视频文件进行传输、传递(delivery)、回放和内容管理的方法、系统和产品，以及用于向诸如蜂窝电话等等的可便携电子设备进行这样的传输的新的减互联网协议(Internet-less protocol)。

附图说明

图1是移动购物搜索引擎和购买向导；

图2是旅途预约场景；

图3是移动股票交易场景；

图4是多模态对话系统架构；

图5是服务器侧架构；

图6是客户机侧组件；

图7是信息流；

图8是通信流；

图9是横向面向服务系统(horizontal service oriented system)组件；

图10是内容管理系统；

图11是内容发现和传递系统；

图12是用于移动多媒体应用的双处理器系统。

具体实施方式

在此所考虑的是用于移动通信系统设计的各种方法，其利用电话启动协议(telephone-initiated protocol)的效率，诸如在提交于2009年2月4日的第12/322,537号的共同未决申请中所揭示的内容，在此结合作为参考，并且结合不同的输入/输出机制的优势，而不是受到其局限性的约束。

对于将移动设备的益处带入大众商务市场至关重要的是更为自然的通信方式。对本示例或者“M.800移动对话系统”的应用使得用户能够经由语音、键盘和甚至图形或视频提供不同的输入。

例如，经常在收听指令时，客户可能希望再次收听这些指令。多模式接口提供了灵活性，以选择适合于该任务和目的的最为方便的交互模式。

M.800移动对话系统还包括移动下载管理服务器(Mobile Download ManagerServer)，这是一种强大的内容传递方案，其提供了高级终端用户(superior end-use)的购物体验。其管理到移动设备的全部类型的可下载内容，包括Java^TM应用程序、ringbones、游戏、图片等等的采购、打包和传递。

订户在单次观看时接入整个内容类目(content catalog)。这种单次的观看使得内容供应商将内容合并成单个绑定(bundle)。订户能够通过从他们的WAP或者Web浏览器观看的一种直观并且易用的界面浏览、选择、购买以及下载任意形式的内容。

下载管理器将直接接入新的或者现有的内容提供给用户并且提供一键购买(one-click purchasing)的服务以及总是最新内容的服务的用户。当客户在客户的移动电话上打开内容列表时，该内容列表被自动更新到手机上。

M.800移动对话系统将在未来几年中具有重大的发展，将益处带给移动商务(m-business)和终端用户。随着移动手持设备越来越普及，移动信息接入和远程事务处理迅速变得越来越普遍。

商业价值

M.800移动对话系统改进了大多数移动服务(诸如移动购物、购买向导(BuyingGuides)、移动产品类目(Mobile Product Catalogs)、移动目录(Mobile Directories)、个人信息管理，和统一消息(unified messaging))的可用性。应用服务供应商可使用移动对话接口提供范围广泛的个性化和差异化的发售。呼叫中心的应用和企业数据服务；诸如账户管理、经纪账户(brokerage account)、客户服务以及销售能力自动化提供了仅语音的接口。使用移动对话接口，可容易地通过结合多输入和输出设备接入和输入信息，尤其是在使用小型设备的时候。

其它优势

基于移动对话系统的移动购物应用程序使得购买者能够在进入店铺购买之前，通过产品的条码或图片搜索和对比在线产品信息，获得产品标识和调查产品信息。移动购买向导和产品类目可将条目预留在店铺中，同时让人返回家中以便进行更详细的在线调查，如图1所示。使用移动对话系统的移动商业可改善客户使用移动设备的体验，并且促进移动商业的发展和接受度。

应用场景

场景1.移动智能购物

实时的基于视频的产品标识和个性化的产品检验器(Personalized ProductChecker)。

移动对话产品检验器使得购买者能够在进入店铺购买之前，通过他们的条码、视频或者图片来搜索和对比在线产品信息(Online Product Information)，获得产品标识，并且调查产品信息。移动购物搜索引擎和购买向导将条目预留在店铺中，同时让人返回家中以便进行更详细的在线调查，如图1所示。

场景2.旅程预定。语音+GUI(图形用户界面)

显示座位选择图表(并不是简单的“窗口或过道”)；

使用语音或者键盘输入PIN码并进行对说话者的验证；

使用音频或者视频进行通知；

可将信息保存用于后续使用。

这种场景在图2中示出。

正如所示出的，用户不是被束缚在特定通道的表示中，而流程交互变得私人化并且使体验最优化。这样的多模式输出是多媒体的示例，在此不同的模态是接近于同步的。

场景3.移动股票交易

这个示例表明了当人们能够利用便捷的语音输入，并且还在同一会话中的视频显示上观看详细信息时你的体验是如何更加自然和个性化的。

这种场景在图3中示出。

附加的特征，诸如对说话者的验证、对视频信息的交互性显示(例如图表)、音频/视频通知等，可使得交互更为自然。人们并不被限制在特定的用户接口，而是能够挖掘出具有多个同步接口的优势。

系统结构

一种示例系统可具有服务器-客户机的架构。客户机部分可基本包括两部分：

输入部分和输出部分，输入部分向服务器发送用户的交互，诸如语音、文本、图片和视频输入，输出部分展示从服务器上接收到的结果。

服务器侧可包括执行系统关键任务的不同模块。图4说明了，服务器可具有从用户收集不同输入，并将其转发给对话和交互管理器(DAIM)的输入部分。该DAIM模块处理该输入并且与应用特定模块交互以向用户生成结果。该结果可被转发给输出模块，该输出模块使得用户查询的结果可以最适宜的方式体现。

服务器侧

系统的服务器部分可包括在优选实施例中的五个主要自主模块(或者服务器)，或者更多的模块(未示出)，其如图5所示经由被称为Hub的中心引导模块(centralfacilitator module)进行通信。这些不同的服务器模块需要彼此通信，以执行特定的任务。为了处理这些消息，使用了Hub。Hub将模块化便利地提供给系统。

基于服务逻辑性，消息在服务器模块之间依据特定的准则分配。

这些消息通常是不同步的，这意味着这些模块不能期望立即接收响应。需要特定的功能性的模块可将这项任务移交给Hub，然后Hub将得知将该请求转发给哪个模块。这弥补了性能模块化，对模块的分配和无缝整合，其构成了Hub。

语音服务器

语音服务器是处理语音模态(voice modality)的模块。在两个方向上均处理交互。例如，来自用户的话音输入可通过ASR(自动语音识别)模块翻译，并且从该系统向用户输出的语音可应用TTS(文本到语音)模块以建立同步的语音。

语音服务器可支持分组交换的和电路交换的语音传输。基于分组的版本是VoIP方案。其简单地复制了音频输入并将其转换成标准PCM格式，并且将其通过在客户机和服务器之间的TCP/IP套接字(TCP/IP socket)连接进行转发。

GUI服务器

GUI服务器处理视频模态，视频模态意味着分别将图形和文本输出给用户并从用户接收到输入。GUI服务器在客户机和其它服务器模块之间起到网管的作用。来自用户的输入被接收，并经由多模态服务器转发给对话服务器。基于来自用户查询的反馈，体现结果的视频、图形和文本被GUI服务器处理。该GUI服务器使用web服务器来显示图形和文本。

下载管理服务器(Download Manager Server)

下载管理服务器可被指派成更新和管理客户内容列表，并且在客户的手持机上在空中更新新的服务和信息。该服务器侧应用产生内容列表，用于下载并存储到客户的移动电话，并支持在网站和移动电话之间的直接通信，用于以一种成本高效的分组快速且高效地存储和传递任意数据绑定(data bundle)。

下载管理器将对新的或者现存的内容的直接接入提供给用户，并提供一键购买(one-click purchasing)的服务以及总是最新内容的服务给客户。当客户在客户的移动电话上打开内容列表时，该内容列表被自动地更新到手持机。

对话服务器

对话服务器模块(也被称为对话管理器)是该系统的另一个重要的且优选的部分。对话管理器从多模态服务器接收用户的查询。基于这些输入，对话服务器提取用户交互的含义。而且，对话管理器与数据库服务器交互，以生成对于用户查询的应答。最后的步骤是体现该查询响应并且将该信息转发给用户，该信息包括话音、图形和视频。

数据库服务器和数据库

数据库服务器是针对特定的应用，并且应该尽量通用以能够支持各种各样的应用。该数据库服务器起到在对话服务器和数据库之间的连接链路的作用。

客户机侧

基本上，多模态客户机包括语音客户机和GUI客户机，两者被结合在独立软件产品中。例如，这种软件可被开发成用于Windows移动平台，诸如Microsoft Windows Mobile5.0或者更高版本。

图6示出了不同组件的逻辑概况，客户机包括连接管理器、GUI客户机和语音客户机。

连接管理器提供了在语音客户机，GUI客户机，及经由网络从而与多模态服务器之间的接口。该客户机使用P2P与服务器通信。

语音客户机处理语音模态，即，其接收并转发来自用户的语音命令，并输出来自多模态服务器的同步语音。

GUI客户机较为复杂。其包括网页浏览器，网页浏览器检索包括图形用户界面的网页以及由此提供的应用。其还处理其它来自用户的可用输入，即，当用户点击在网页上的图标时，被敲击的图标的坐标作为用户的输入被收集并转发给多模态服务器，并且在此后进行处理。

信息和通信流

图7说明了在用户、客户机和服务器之间的交互模式，以及在系统的模块之间的信息流。

该信息流是基于用户的查询。这些输入被转发到它们各自的服务器模块。在用户点击下GUI服务器登录，并且语音服务器执行DTMF或者语音识别，并且提取出其基本含义。接下来这些输入被移交给多模态服务器，其采用了定时器机制来收集在指定的时间窗内的输入信号。

进一步地，当时间窗期满时，多模态服务器接受最多的同时输入，其将这些输入传给对话服务器。对话服务器竞争多模态集成(multimodal integration)，并且基于这种处理，将试图产生对该查询的响应。为了精心得到响应，对话服务器可查询数据库服务器。数据库服务器在数据库中进行查找，并将结果返回对话模块。

然后通过对话管理器对该结果进行处理，以产生可向用户呈现的响应。该响应被移交给多模态服务器，其将该信息分割成不同的模态，即，图形和话音，它们分别经由GUI和语音服务器被发送出去。

图7示出了客户机需要在客户机和服务器之间设定两个逻辑通道。一个通道用于传输语音模态，而另一个通道用于传输数据。

在图8中详细描述了客户机和服务器之间的通信。在上面已经描述了步骤1至6。在步骤7，多模态服务器产生网页/wap页，该网页被加载到网络服务器/wap服务器。同时，将消息发送到客户机的软件，告知其以给定的URL下载该网页。具有嵌入的网页浏览器的客户机发送标准HTTP请求以检索所产生的网页。在步骤10，多模态系统转发由用户查询的结果精心生成的语音响应。优选地在同一时刻，在客户机上显示呈现该结果的视觉模态的网页。对于用户的体验来说，这两个输出的同步和用户输入的同步一样重要。

优选系统的要求

现在阐述对于移动多模态客户机-服务器系统的优选要求。以上所阐述的示例体现了人们可能具有的和多模态系统能够提供的服务的不同状况和不同需求。基于这些场景，这些要求集中在功能性和性能要求上：

多模态平台优选地为通用平台，其能够在其上实现一系列的服务。

多模态平台优选地使得第三方服务供应商能够通过该移动运营商的多模态平台来提供他们的服务。

具有优势的是，多模态系统的客户机部分较简单，对于末端用户仅需要最少的安装设置。

优选要求列表

要求描述

表1对于多模态系统的优选要求

多模态结合

在本发明的背景下，多模态意味着使用多于一种模态。这意味着，当对于某服务给定输入时，用户优选地能够使用多于一种模式。同样地，该系统优选地能够使用多于一种模态对用户给出输出。对于多模态的定义并不意味着设定了任何关于这些模态是否被同时地或者有顺序地使用的限制。

万维网联盟(W3C)定义了结合多模态输入和输出的三种不同方式：有顺序的、非协调同时的(uncoordinated simultaneous)和经协调同时的(coordinated simultaneous)多模态输入/输出。对这三种场景进行区分是具有优势的，因为它们的实现的复杂性非常不同。

有顺序的多模态输入/输出

来自不同模态的输入和输入被分开地翻译(interpret)，但是在任何给定的时刻仅有单个的、指定的输入模式被激活，这是多模态交互的最简单的形式。

无协调同时的多模态输入/输出

在这种状况下，若干并行输入模式同时被激活。这意味着这些用户在每一个对话阶段可选择他们优选的输入模式，但是依次仅有一种模式被选择用于处理。在每一轮中可依据不同的准则决定使用哪种模式，诸如，以第一模式开始，或者该种模式比其它模式优先。

经协调同时的多模态输入/输出

这是最为先进的交互形式。而且在此有多于一种的输入模式是同时可用的，但是与非协调同时模式相反，在此来自不同模态的所有输入被收集在一个时间窗内并进行翻译。在经协调同时模式下，将这些事件进行结合以向多模态系统产生查询。

同时的电路交换和分组交换连接

近些年来，已经发现了多种新的有前途的方法，能够使同时的电路和分组交换连接用于GSM网络。

表2GPRS分类

这种技术被称为双传输模式(DTM)并且对于该主题已经做出了很多的研究。本方法并不需要有两个无线收发机，这使其更为合理并且有成本效率。在UMTS中，由于所使用的无线接口，通过空中接口实现支持多个、平行的承载是相当容易的。这能够使电路和分组交换连接同时进行。UMTS设备能够工作在不同的操作模式下，见表3。

表3UMTS操作模式

移动操作系统

如今在市场上存在若干具有不同操作系统和连接选项的移动终端。新型的所谓智能电话以及PDA和移动电话之间的融合导致了高度高级的终端，能够完成复杂的任务。

主要有两种OS，它们显然成为了移动终端的主流：由诺基亚(Nokia)、索爱(SonyEricsson)、松下(Panasonic)、西门子AG(Siemens AG)所拥有的塞班(Symbian)系统，以及，由微软(Microsoft)提供的移动视窗(Windows Mobile)系统。

直到最近，塞班OS成为用于高级移动终端的主流操作系统。这是因为世界上最大的移动电话生产商中的一些，诸如诺基亚和爱立信，在它们的智能电话中使用了这种OS。尽管用户具有相同的平台，但是每一个生产商采用了它们专有的图形用户界面。当微软决定转向移动终端市场时，显然它们将成为强大的竞争者。大多数PC用户都熟悉Windows的OS。许多用户将自然乐于在他们的移动终端上具有相同的界面以及接入相同的服务和应用。

移动Windows 6的发布带来了不同的版本，一种版本称为智能电话版，而另一种称为袖珍PC版(PocketPC)。这些版本之间的主要差异是，它们适合于两种不同类型的高端移动终端。智能电话版更类似于具有按键和屏幕的常规的移动电话。袖珍PC版本则被研发成用于具有触摸感应屏幕的PDA。

移动内容传递方案

现代的移动内容传递方案应用了横向面向服务架构(horizontal ServiceOriented Architecture)方案。图9说明了典型的系统组件。

优选的系统组件

移动交互服务器(MIS)：提供了设备辨认最优化设备，其给出发现门户组件(discovery portlet)，且保持设备的配置文件(profile)以及它们支持的数字媒体格式。

履行管理器(Fulfillment Manager)：通过基于内容类型和目标设备，确定适当的下载机制，提供对跨越接入通道(access channel)范围的可下载内容的传递，并且随后确保完成下载本身。

用户门户(User Portal)：用于发现可用内容的构架并能够迅速与运营商的现有的计费和消息传递平台整合的设施。

内容管理系统：提供来自提交和获得的完整内容生命周期管理，制定类目和验证，对数字媒体进行公开和最终弃用。

在图10中说明了通过本发明的系统提供的功能。

内容发现和传递在用户门户环境的背景之内进行，在此终端用户接入并使用由运营商供给的服务和内容。

内容管理在运营商管理的环境之内进行，在此内容供应商与运营商一起管理向用户门户环境的内容提交、认可和公开。

以下参考图11更详细地描述通过单独的组件提供的功能，以及与典型的运营商环境中其它组件的整合和交互。

在用户门户环境下的内容发现和传递

用户门户基于终端用户的服务订阅、所配置的优先选项，以及他们正在使用来接入用户门户的设备的能力，向终端用户提供了对一组可用服务的接入。用户门户基于设备能力，通过识别用户设备、访问用户服务订阅配置，以及适当地给出所订阅的服务，动态地生成对终端用户可用服务的定制视图。用户门户使得终端用户能够从某范围的设备接入服务，这些设备包括PC浏览器、PDA浏览器、WAP和移动电话浏览器等。

在用户门户之内提供的服务中包括内容下载服务，诸如铃声下载、壁纸下载、java游戏下载、音乐和视频下载等。这些下载服务被实现成在用户门户之内的“门户组件”，使终端用户能够“发现”可用于下载到他们的设备上的内容，并且随后对该内容启动购买(如果可用)并且‘传递’(下载)到他们的设备上。

内容发现

单独的内容发现门户组件利用通过用户门户提供的设备认知构架(device-awareframework)，以确保仅将适于终端用户设备的内容呈现为可用于下载。例如，和弦式的铃声将仅在该终端用户的设备支持它们时在发现门户组件中示出。该发现门户组件还利用给出用户门户功能的多通道设备，以确保最佳的呈现和用户与该门户组件本身的交互。

在用户门户之内整合的内容传递构架(Content Delivery Framework)提供了具有附加通用能力的发现门户组件，附加通用能力能够进行内容发现处理，包括：

用于基于设备特征、特定内容格式、关键字、服务器关联性等进行查询和识别可用的发布内容的接口；

能够检索价格信息以呈现给终端用户的接口；

一旦发现完成，则自身启动传递内容的能力。

内容发现门户组件典型地利用查询所公开的内容的能力，以确保以以下两种方式中的一种来发现内容：1)向终端用户呈现一系列菜单，并且通过选择内容的类目引导终端用户的路径，直到他们找到他们感兴趣的一条特定内容。这些菜单是通过发现门户组件动态生成的，确保了仅将已经基于终端用户设备的能力过滤的内容选择呈现给终端用户。通过类目、格式、流行度对内容的菜单进行组织和呈现；以及，2)将匹配搜索准则的可用内容的列表呈现给终端用户。同样地，这些内容基于终端用户设备的能力被过滤。

事实上，取决于对单独的发现门户组件的实现、在网络本身之下运营商采用的期望的商业模型和该运营商提供的能力，用户在内容发现期间的体验可能大不相同。而且，在启动完整内容版本的传递之前，可向终端用户提供对内容进行预览或抽样的能力，并且，取决于内容类型和运营商选定的商业模式，可向终端用户提供可选的价格选项，例如免费、包月费率的无限铃声下载、10张壁纸5美元、单独的java游戏2美元，以及额外的游戏等级每个25美分等。

网络能力的局限性可能使其不能提供预付费下载，不能提供对使用WAP推送信息(WAP Push)的内容的传递，或者不能提供发现用于其它终端用户的内容的能力。

发现门户组件本身优选地被设计成确保简单且强制的用户体验。

内容传递

一旦终端用户完成内容发现处理并且确认将处理对内容的传递，则启动传递处理。对所选定内容的传递在很大程度上可以取决于该终端用户所要求的内容类型、该终端用户设备的能力以及该内容被发现的方式。

例如，如果使用与将要向其传递内容的设备同一个设备完成发现，则该内容可在同样的会话中通过重新引导该终端用户的浏览器或应用管理器拉入该内容而被直接传递。备选地，该内容可使用诸如WAP推送信息的机制被单独地向该终端用户设备发送。

包括内容下载服务(Content Download service)的用户门户尚未讨论。移动交互服务器被部署在用户门户构架之内，以在一定范围的设备上提供用户门户和相关联服务的设备识别以及最佳呈现。

用户门户构架与在运营商的部署环境内的不同元件整合，使得在内容发现和传递期间对它们进行利用。典型地，用户门户与运营商的短消息服务中心(SMSC)和WAP推送信息代理网关(PPG)、预付费和后付费的计费平台，以及运营商供应(operator’sprovisioning)和客户服务(customer care)的平台进行整合。该用户门户还被整合到内容管理系统。

履行管理器

在移动内容传递架构内，履行管理器促进内容传递处理。其基于内容和目标设备确保对请求下载的终端用户进行授权以下载该内容，确定要使用的适宜的下载机制，并且确保该下载本身的完成。

其与计费和统计生成组件(statistical generation components)相接口，以能够确认计费并确保对下载的跟踪，并且在适当时，还处理来自J2ME设备的安装报告。

在该履行管理器之内的商业逻辑可被定制成与运营商的商业模型看齐。例如，计费确认可在内容传递前出现，或者可仅在下载完成后出现。商业逻辑也可以在预付费和后付费订户之间改变。

履行管理器通常是基于J2EE客户机供应标准(J2EE Client Provisioningstandards)的。其提供了抽象的适配器模型，用于供应许多内容类型以及支持许多供应模型。该履行管理器有利于向发现设备进行直接传递，并且还通过使用来自运营商网络的可用的WAP推送信息设施能够实现到设备的传递来支持基于PC的发现。

该履行管理器提供了用于MIDP OTA以及OMA OTA的特定适配器，提供了通用下载适配器，以处理所有其它的下载，例如图片、音频文件等的直接下载，并能够容易地扩展为在需要时支持额外的适配器。

内容管理

移动内容传递系统利用内容管理套件(Content Management Suite)的核心组件：

内容服务器：存储由内容供应商提供，并随后向站点高速缓存服务(Site CashingServices)发布的内容；

高速缓存服务：存储可用于从用户门户上的发现门户组件上下载的所发布的内容。因为相关联的数据库存储了用于描述被存储在站点高速缓存服务中的内容以及物理上由外部内容供应商托管的内容的元数据。

内容服务：一种通往元数据库的接口，使得发现门户组件能够使用内容连接器以搜索可用的发布的内容，该内容用于适于呈现给终端用户的特定内容，以用于可能的下载。

网络发布器：由内容管理者(content administrator)使用的工具，以管理内容的生命周期。这些处理被模型化成能够使内容被提交、分类、认可、公开，和弃用(如果合适的话)的定制工作流程。元数据对象模型被用于完整地描述内容，使公开内容能够用于发现和下载。该元数据描述了关于内容本身的基本细节，诸如内容类型、格式和大小，以及叙述信息，诸如作者、标题和类别，使得单独的发现门户组件能够有效地使用内容服务接口来过滤内容，用于向终端用户呈现。

媒体服务：提供了对所提交内容的自动重现以及将所提交的内容转换成备选格式和大小，执行自动的元数据提取，并且提供了可扩展插件构架(plug-in framework)，其能够整合DRM工具包、图形服务等。

内容供应商

为了有利于通过外部内容供应商进行内容提交，内容供应商门户可被部署在运营商的管理环境中。内容供应商门户提供了接口，诸如内容管理网页应用和/或可由内容供应商使用来将内容提交和更新到内容服务器的FTP服务器。内容供应商将使用网页应用填写描述该内容的基于网络的表格，本质上为元数据大纲(meta-data schema)，并且随后将该内容上载到内容服务器上。内容供应商将使用FTP服务器上载内容和描述用于内容的元数据的XML文件。

优选的无线设备要求，双处理器架构

在第7,548,875号美国专利中，描述了具有多媒体DSP子系统的无线通信设备。这种双处理器架构非常适于处理大多数高要求的多媒体应用，包括实时视频处理。该架构已经通过利用低功率、可编程DSP和强大的RISC(精简指令集运算)的通用处理器被大大增强和优化。

由于对应用的需求、在两个处理器之间对应用的任务进行划分是很关键的。当任务被分派给最适于处理它们的处理器时，将优化系统的速度和吞吐量。将任务最优化地分派给适宜的处理器将减少针对每一个任务所需的处理器周期数量，依次地，减少从电池中消耗的电力，并且延长了该移动设备的可用寿命。

图12示出了将移动视频应用映射到双处理器架构上的有效方法，该双处理器架构被最优化成提供用于要求无线多媒体应用，并且同时通过消耗更少的电力延长移动设备的电池寿命所需要的处理能力。

涉及移动视频应用的任务可被划分成控制、传输和媒体解码。控制和传输任务包括处理实时流协议(Real-Time StreamingProtocol，RTSP)以及实时协议(Real-TimeProtocol，RTP)，这是一种媒体传输机制。因为这些任务没有计算上的强度，因此，通用RISC处理器就可适于执行这些任务。

媒体解码任务包括解码视频比特流、高质量的音频解码，和其它信号处理任务。这些处理具有计算上的强度。因此，高性能、低功率的DSP非常适合媒体解码任务。

当处理视频应用时，无线信号通过调制解调器进入系统。通用RISC处理器处理RTP/RTSP协议处理并且解复用音频和视频数据。这些无线信号然后被变换成基元比特流(elementary bit stream)，并且被转发给DSP内部随机访问存储器(RAM)。

为了使系统的处理需求最小化，视频应用使用当前的帧或图像，以外推出后续的帧。帧一次被转移一个宏块(macro-block)，从帧缓冲器进入DSP内部RAM，在此处其被合并到其它信息中，并且作为当前帧被发送到显示器。

如果数据不能以及时的方式被移动穿过系统，将浪费这两个处理器的处理能力。直接存储器存取(DMA)连接被用于避免I/O瓶颈，其可能使视频应用失效。所有的DMA通道都接入所有共享存储器，确保高效的内部数据流。加速数据结构的移动需要DMA的能力，因为较大的图形图像必须快速地并且不断地从外部存储器被转移到内部存储器。

双处理器架构提出了在处理器之间发生冲突的问题，其可能在两个处理器竞争相同的处理器位置的时候发生。此外，通过用于在存储器中特定位置的两个处理器中的一个发起的存储器存取请求可以一次仅处理一个。由于业务量控制器(Traffic Controller)，该系统能够克服这些处理器之间的竞争，业务量控制器是该架构的固有部件。

业务量控制器是一种可编程仲裁机制，其设置在DSP、通用RISC处理器和外部接口之间。取决于被编程到业务量控制器中的算法，其将存储器存取区分出优先次序，并且解决可能发生的任何冲突。

误差校正。除了构建在像MPEG-4的现代压缩标准中的常用误差弹性工具(errorresilience tool)以外，在该系统中融入了后处理技术。这种技术跟随视频解码处理，并且使用已经通过在先前所提及的误差弹性工具被恢复的数据，以来自前面的帧的未被破坏的宏块取代被破坏的宏块。

误差校正处理在设备的IO通道上施加了压力，因为这些工具和技术经常要求处理器重新检查过去的帧以更为精确地推出当前帧。大的数据块在DSP处理器的外部存储器和其片上RAM(on-chip RAM)之间来回地流动。本系统能够克服这个问题，这是因为其具有许多的DMA通道，使得I/O成为瓶颈的可能性减少。

术语表

CMS API 内容管理系统应用编程接口

DB 数据库

DC 传送上下文(Delivery Context)

DRM 数字版权管理

FTP 文件传输协议

J2ME Java 2平台，微编辑

JSP Java服务器页面

OMA 开放移动联盟

MMS-C 多媒体消息服务中心

PORTLETS 在网页门户中管理和显示的用户接口组件

PDA 个人数字助理

SCP 服务控制点

SDP 服务传递平台

SMPP 短消息点对点协议

SMS-C 短消息服务中心

WAP 无线应用协议

WAP-GW 无线应用协议网关

WPPG WAP推送代理网关

XML 可扩展标记语言

在提交于2002年6月26日的第10/153,756号，标题为“Media Delivery Platform”的美国共同未决专利申请，现在为第7,548,875号美国专利中揭示了一种用于在本发明中使用的优选的方法和系统，在此结合其全文作为参考。

Claims (4)

1.一种移动电话，其发送和接收条码，该移动电话与具有经由中心引导hub模块通信的多个自主模块的服务器系统可操作地连接，该服务器系统包括：

GUI服务器，用于处理视频模态，视频模态意味着将图形和文本输出给所述移动电话并从所述移动电话接收到条码输入；

对话服务器，用于从多模态服务器接收查询，其中所述多模态服务器分别通过接口连接语音服务器和所述GUI服务器中的每一个，以处理多模态输入和输出；

下载管理服务器，用于更新和管理所述移动电话上的内容；

数据库服务器，其响应于用户输入，在数据库中进行条码查找，并将结果返回所述对话服务器；

其中，所述移动电话包括：

多模态客户机，其包括：

语音客户机，其处理语音模态，接收并转发来自所述移动电话的语音命令，并输出来自所述多模态服务器的同步语音；

GUI客户机，其处理视频模态，收集来自所述移动电话的条码输入并将其转发到所述多模态服务器；以及

连接管理器，用于提供所述语音客户机、所述GUI客户机，及经由网络与所述多模态服务器之间的接口。

2.如权利要求1所述的移动电话，其中所述移动电话是蜂窝电话。

3.如权利要求1或2所述的移动电话，其中所述移动电话配置有多个处理器，包括可编程数字信号处理器和精简指令集运算处理器。

4.如权利要求1所述的移动电话，其中所述移动电话包括多媒体数字信号处理器，该多媒体数字信号处理器配置成接收和处理通过正交频分复用调制传送的压缩的音频和/或视频数据文件。