CN101390367A - 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式 - Google Patents

针对移动广播/多播流式服务器的使用而扩展富媒体容器格式 Download PDF

Info

Publication number
CN101390367A
CN101390367A CNA2007800067851A CN200780006785A CN101390367A CN 101390367 A CN101390367 A CN 101390367A CN A2007800067851 A CNA2007800067851 A CN A2007800067851A CN 200780006785 A CN200780006785 A CN 200780006785A CN 101390367 A CN101390367 A CN 101390367A
Authority
CN
China
Prior art keywords
information
alc
media file
flute
iso base
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CNA2007800067851A
Other languages
English (en)
Inventor
R·维丹撒姆
V·塞特卢尔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Inc
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Priority to CN201510372735.1A priority Critical patent/CN105024852B/zh
Publication of CN101390367A publication Critical patent/CN101390367A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26283—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for associating distribution time parameters to content, e.g. to generate electronic program guide data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

对ISO基媒体文件格式进行扩展，以支持ALC作为广播协议。本发明还提供了对ESG的扩展，以包括特定于移动广播/多播网络上的SVG传输的元数据。在容器文件格式中引入了“BMFDP提示跟踪”，其中所需的文件元数据位于这些提示跟踪中。本发明可以在诸如较长卡通动画的预览、交互式移动电视服务、在线企业数据馈送、在线聊天服务以及卡拉OK节目的应用中使用。

Description

针对移动广播/多播流式服务器的使用而扩展富媒体容器格式
技术领域
本发明总体上涉及扩展ISO基媒体文件格式，以包括异步分层编码(ALC)作为广播/多播协议，同时流式传输富媒体内容。更具体地，本发明涉及包含文件会话描述协议(SDP)、元数据以及提示跟踪，以用于使用ALC的富媒体内容的广播/多播下载。
背景技术
本小节意在为权利要求书中记载的发明提供背景和上下文。这里的描述可能包括那些可追求的概念，但这些概念未必是先前已经构思或追求的。因此，除非在此指明，否则在本节中描述的内容不构成相对于本申请的说明书和权利要求书的现有技术，并且将内容包括在本节中并不意味着该内容是现有技术。
富媒体内容通常是指图形上丰富并且包含复合(或多个)媒体(包括文本、图形、视频和音频)、并且优选地通过单个接口来递送的内容。对于可视地递送实时内容的富媒体而言，特别是在MBMS和分组交换流式传输(PSS)服务架构内，富媒体内容的流式传输正变得日益重要。多媒体广播多播服务(MBMS)流式传输服务有助于在3G环境中将流行的实时内容资源有效地递送至多个接收者。内容可以是预先录制的或者是从在线馈送生成的。
目前，存在用于呈现富媒体的若干已有系统，特别是在Web服务领域内。Scalable Vector Graphics(可伸缩矢量图形，SVG)Mobile 1.2是一种用于在XML中描述二维图形的语言。可伸缩矢量图形允许三种类型的图形对象：矢量图形形状(例如，包括直线和曲线的路径)，多媒体(诸如，光栅图像、视频等)以及文本。SVG图可以是交互式的(使用文档对象模型(DOM)事件模型)和动态的。动画可以声明式地(即，通过在SVG内容内嵌入SVG动画)或通过脚本来定义和触发。可以使用补充脚本语言来实现SVG的复杂应用，其中补充脚本语言访问SVG宏文档对象模型(uDOM)，uDOM提供对所有元素、属性和性质的完全访问。可以为任意SVG图形对象指派丰富的事件句柄。由于其兼容性以及其他Web标准(诸如，复合文档格式(CDF))的使用，可以在相同的网页内同时对XHTML和SVG元素执行类似于脚本的特征。
同步多媒体集成语言(SMIL)版本2.0支持交互式视听觉呈现的简单创作。SMIL通常用于“富媒体”/多媒体呈现，该呈现将流式的音频和视频与图像、文本或者任何其他媒体类型集成在一起。
对于CDF，目前正在努力结合分离的组件语言(例如，来自独立词汇表的基于XML的语言、元素和属性)，诸如XHTML、SVG、MathML和SIML，其关注点在于用户接口标记。在结合用户接口标记时，必须解决单个标记规范没有解决的特定问题。这些问题包括：在标记之间传播事件，以及将绘制或者用户交互模型与结合文档相结合。
目前，实时传输协议(RTP)是用于流式递送连续媒体(诸如，音频、视频和SVG)的优选传输层协议。RTP被用于单播流式传输(例如，3GPP PSS、3GPP2 MSS(多媒体流式传输服务))、广播/多播流式传输(例如，3GPP多媒体广播/多播服务(MBMS)、3GPP2BCMCS(广播多播服务))以及富媒体会议应用。
异步分层编码(ALC)是极其可伸缩和可靠的内容递送协议。ALC是用于任意二进制对象的可靠多播递送的基础协议。ALC在3GPP2BCMCS和OMA BAC BCAST中被用作广播/多播文件递送的强制性协议。现在将文件元数据(在通过单向传输的文件递送(FLUTE)中作为文件递送表(FDT)的一部分来携带)作为OMA BCAST电子服务向导(ESG)的一部分递送至客户端。根据服务向导数据模型将该元数据划分为各个ESG段。将段标识为：服务、计划、内容、访问、会话描述、购买项、购买数据、购买通道、服务向导上下文、服务向导递送描述符以及预览数据。现有技术图3中示出了OMA BCASTESG数据模型。ESG通常在ALC会话之前递送到客户端。因此，客户端在ALC会话开始之前具有文件元数据。如果在ALC会话期间需要更新文件元数据，则可以通过使用ESG递送/更新通道来更新包含文件元数据的那些ESG段。因此，文件元数据更新不是在ALC会话的带内(in-band)执行的。
FLUTE构建在ALC之上并且定义了FDT，其中FDT存储与ALC会话中递送的文件相关联的元数据。FLUTE还提供FDT的带内递送以及更新的机制。3GPP MBMS和DVB-H IPDC采用FLUTE作为广播/多播文件递送的强制性协议。
除上述内容之外，还存在ISO基媒体文件容器格式，用于富媒体内容的存储以及该内容随后通过HTTP、FLUTE和RTP的传输。2005年9月1日递交的美国临时专利申请No.60/713,303以及2005年6月27日递交的美国临时专利申请No.60/694,440中详细描述了这些格式，在此引入上述两个专利申请的全部内容作为参考。然而，目前尚没有用于包括ALC作为广播协议的机制，特别是用于存储ESG中的文件元数据的机制。
直到最近，用于移动设备的应用仍是基于文本的，其交互性有限。然而，随着更多的无线设备配备了彩色显示器和更先进的图形绘制库，用户日益要求来自其无线应用的富媒体体验。对于移动终端来说，特别是在MBMS、PSS和MMS服务的领域中，实时富媒体内容流式服务至关重要。
SVG被设计用以描述与分辨率无关的2D矢量图形，允许使用从SMIL借用的事件模型和动画概念的交互性。SVG还允许无限的缩放性，并增强了移动设备的用户接口的能力。此外，SVG支持类似于SMIL媒体元素的媒体元素的嵌入。
可以将所有嵌入的媒体划分为两个部分：离散媒体(例如，图像)和连续媒体(例如，音频、视频)。连续媒体元素在其时间容器内定以了其自己的时间线(timeline)。因此，SVG越发重要，并且变成了驱动多媒体呈现的核心元素之一，特别是对于诸如移动电视的富媒体服务、交通信息、天气、新闻的在线更新等。SVG是基于XML的，其允许与其他已有web技术的更透明的集成。
对于广播/多播网络上的富媒体流式传输，可以使用RTP来递送诸如音频、视频和SVG场景/更新的连续媒体。然而，如前所述，SVG呈现还包括离散媒体，并且其目前是使用文件下载协议而不是RTP来递送离散媒体。ALC和FLUTE是目前用于广播/多播网络上文件递送的优选传输层协议。广播/多播流式服务器应当能够通过从富媒体容器文件读取内容来生成富媒体分组(RTP和ALC，或者RTP和FLUTE)。容器文件可以包括：(1)用于连续媒体的媒体跟踪，即，SVG跟踪、音频跟踪、视频跟踪、光栅图像等；(2)保持同步信息的提示跟踪；以及(3)内部嵌入的离散媒体。
广播/多播流式传输服务器创建RTP分组，以通过使用媒体跟踪和提示跟踪来携带连续媒体。服务器还需要创建ALC或者FLUTE分组，以携带内部嵌入的离散媒体。服务器还确定获取外部引用的离散媒体的一些或全部，并使用ALC或者FLUTE将其发送给客户端。在接收之后，这些图像：(a)在播放相应的SVG内容时可用被绘制；或者(b)可以通过用户交互而被本地存储/高速缓存和绘制。这带来满意的用户体验，并且无需来自客户端的其他同时点对点(PtP)连接。然而，该优化没有排除同时PtP连接的可能性，而是仅仅最小化了同时PtP连接的可能性。如果这些离散媒体(例如，CNN肖像)不可以随意访问，则富媒体应用可以确保仅在用户购买了图像时才会绘制该图像(即，数字版权管理(DRM)权利)。由此，外部引用的离散媒体文件被广播给了所有用户，而不论用户是否订购了该文件的访问。对于没有订购这些文件的用户而言，这些文件的广播下载浪费了无线和存储器资源。对于订购这些文件的用户，这些文件的广播下载减少了无线资源的利用，并且也增强了它们的用户体验。为了创建ALC或者FLUTE分组，服务器需要与离散媒体(图像)文件相关联的元数据。还需要在富媒体容器文件中包含这些文件元数据。
发明内容
本发明解决了缺乏用于将此元数据存储在富媒体容器文件中的机制这一问题。本发明包括：扩展ISO基媒体文件格式以支持ALC作为广播协议，以及扩展ESG以包括特定于移动广播/多播网络上的SVG传输的元数据。在容器文件格式中引入了“BMFDP提示跟踪”，所需的文件元数据位于这些提示跟踪中。
在多种用例中，富媒体服务可以得益于使用ALC作为协议。这些使用包括：较长卡通动画的预览，交互式移动电视服务，在线企业数据馈送，在线聊天服务以及卡拉OK节目。因为此前没有将ALC特定的内容包括在ISO基媒体文件格式中的方案，因此包含ALC促进了更好的利用：能够在富媒体会话期间将带外信息发送至3G移动设备以用于下载应用。本发明为提供交互式和动态富媒体流式传输以及渐进式下载的服务提供了益处，可以在多种多样的产品中结合本发明，并且可以在诸如3GPP MBMS、3GPP2BCMCS、DVD-H IPDC以及OMA BCAST的服务中使用本发明。
通过下文结合附图进行的详细描述，本发明的这些和其他优点和特征以及本发明操作的组织和方式将变得显而易见，其中，贯穿下文描述的多个附图，相同的元素具有相同的标号。
附图说明
图1是示出了如何可以将ALC特定的信息包含在ISO基媒体文件格式中以便使用RTP和ALC协议来实现富媒体广播/多播流式传输/下载服务的图示；
图2是用于移动广播/多播网络上的富媒体流式传输和文件下载的协议栈的图示；
图3是OMA BCAST ESG的传统数据模型的图示；
图4是可以在本发明的实现中使用的电子设备的透视图；以及
图5是图4的移动电话的电话电路的示意图。
具体实施方式
本发明包括：扩展ISO基媒体文件格式以支持ALC作为广播协议，以及扩展ESG以包括特定于移动广播/多播网络上的SVG传输的元数据。在容器文件格式中引入“BMFDP提示跟踪”，其中所需的文件元数据位于这些提示跟踪中。
本发明的实现涉及扩展ISO基媒体文件格式，以支持ALC协议用于传输。这包括：(1)在ISO基媒体文件格式中添加用于ALC的会话描述信息；(2)扩展ISO基媒体文件格式，以包括用于ESG的元数据信息；以及(3)扩展ISO基媒体文件格式，以便包括提示跟踪信息，以形成ALC分组用于传输。
图1是如何可以将ALC特定的信息包含在ISO基媒体文件格式中以便使用RTP和ALC协议来实现富媒体广播/多播流式传输/下载服务的图示。从图1中可以看出，将富媒体110(具有离散和连续媒体的SVG)、SDP信息115、基于ALC的元数据信息120以及用于ALC分组化的提示跟踪信息125输入到了ISO基媒体文件生成器130中，生成器130产生富媒体ISO基媒体文件135。将富媒体ISO基媒体文件135提供给富媒体服务器140。富媒体服务器140继而向富媒体播放器160传送(1)离散文件(ESG)的元数据145；(2)会话描述信息150；以及(3)RTP和ALC分组155，富媒体播放器160继而可以对编码信息进行解码以用于后续展示。图2示出了用于移动广播/多播网络上的富媒体流式传输和文件下载的协议栈。应当理解，尽管此处的文字和示例可能特别地描述了编码过程，然而本领域的技术人员将会容易地理解：同样的概念和原理也适用于相应的解码过程，反之亦然。
下面将描述SVG嵌入媒体的能力，以及富媒体传输的不同传输情况。该信息提供了使用ALC作为富媒体下载协议的基础，并提供了本发明所要解决的问题的范围。SVG支持类似于SMIL媒体元素的媒体元素。如上所述，可以将所有的嵌入媒体划分为两部分：离散媒体和连续媒体。诸如图像的离散媒体是使用“image(图像)”元素嵌入SVG的，例如：
<image x＝＂200＂y＝＂200＂width＝＂100px＂height＝＂100px＂xlink：href＝＂myimage.png＂>
以下是包含诸如音频和视频的连续媒体的示例：
<audio xlink：href＝”1.ogg”volume＝”0.7”type＝”audio/vorbis”begin＝”mybutton.click”
repeatCount＝”3”/>
<video xlink：href＝”ski.avi”volume＝”.8”type＝”video/x-msvideo”x＝”10”y＝”170”/>
SVG还可以嵌入其他SVG文档，这些SVG文档继而可以通过嵌套来嵌入更多的SVG文档。动画元素规定提供同步动画矢量图形的外部嵌入的SVG文档或者SVG文档段。类似于视频元素，动画元素是图形化对象，其大小由其x、y、width(宽度)和height(高度)属性确定。以下是一个这样的示例：
<animation begin＝＂1＂dur＝＂3＂repeatCount＝＂1.5＂fill＝＂freeze＂x＝＂100＂y＝＂100＂
xlink：href＝＂myIcon.svg＂/>
类似地，可以内部或外部地引用SVG中的媒体。虽然上面的示例是内部引用的，但是以下示例示出了外部引用的媒体：
<animate attributeName＝”xlink：href”values＝”http://www.example.com/images/1.png；
                                                 http://www.example.com/images/2.png；
                                                 http://www.example.com/images/3.png”
                                          begin＝”15s”dur＝”30s”/>
可以通过SVG内容中的内部或外部URL来链接嵌入的媒体元素。在这种情况下，内部URL表示ISO基媒体文件本身内的文件路径。外部URL表示ISO基媒体文件外部的文件路径，其存在于包含源SVG文件的相同服务器上或者存在于其他服务器上。本发明涉及针对内部嵌入的离散媒体的ALC传输机制。相应地，会话描述协议(SDP)是针对内部嵌入媒体而制定的。
在此讨论的传输机制是针对驻留在相同或其他服务器上的离散媒体和连续媒体而提供的。这些媒体可以是原始格式，或者是ISO基媒体文件格式。然而，应当采取适当的步骤来确保这些媒体元素在传输和呈现期间的适当同步。
对于下载，离散嵌入媒体和连续嵌入媒体二者都可以通过HTTP、FLUTE或者ALC来传输，这取决于其是点对点的还是广播。然而，在广播流式传输情况下，只有连续媒体可以通过RTP来传输。出于该原因，可以想到以下传输组合：(1)离散媒体的广播流式传输+HTTP下载；(2)离散媒体的单播流式传输+HTTP下载；(3)离散媒体的广播流式传输+FLUTE/ALC下载；以及(4)离散媒体的单播流式传输+FLUTE/ALC下载。本发明涉及项目(3)和(4)。此外，可以通过以下手段来明确地传输离散媒体文件：(1)经由ALC/FLUTE会话将其预先传输至UE；(2)在流式传输会话之前通过点对点承载将其传输至每个客户端，其方式类似于在MBMS会话之前将安全密钥发送至客户端的方法；(3)如果由足够的无线资源可用，则具有独立于RTP传输会话的平行ALC/FLUTE传输会话；或者(4)由于有限的无线资源而具有非并行的传输会话来传输所有数据。每个传输会话或者包含ALC/FLUTE数据，或者包含RTP数据。
下面将描述本发明的第一实现，涉及使用盒子(box)来存储会话描述协议(SDP)信息。SDP是用于规定会话描述的通用实用格式。可以使用ALC分组来传输场景描述，以及离散和/或连续的嵌入媒体，这取决于其是纯下载情况还是与RTP流式传输会话共享。在先于ALC会话开始发送的ESG中指明内部嵌入媒体的URI。用于ALC的SDP描述的语法类似于FLUTE的语法，并且已经在互联网草案“SDPDescriptors for FLUTE”中定义。
可以存在各种用于ALC的描述格式。SDP如下定义。按照SDP的要求，将SDP中存在的文本恰当地格式化为一系列行，每行由<crlf>结束。对于SVG场景的传输、场景更新以及离散嵌入媒体，将出现这种情况。2005年9月1日递交的美国临时专利申请No.60/713,303中详细描述了不同级别(呈现、影片、跟踪、项目)的用于FLUTE的盒子。然而，同样可以针对广播下载来归纳为相同的盒子，以便包括ALC。因此，盒子的前缀是“BMFDP”(广播多播文件下载协议)，以便更为一般，以存储用于ALC或者FLUTE的SDP。还要添加称为“protocol(协议)”的标志，以指明盒子是用于FLUTE还是ALC。以下是四个不同级别的盒子：
(a)呈现BMFDP信息。呈现级别提示信息容器在“phib”盒子中定义，其专用于ALC或者FLUTE。在通过ALC或者FLUTE来发送当前呈现中的所有内容时，可以使用它。
aligned(8)class BMFDPpresentationhintinformation extends box(‘bdph’){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        char sdptext[]；
}
(b)项目BMFDP信息。项目级别提示信息容器在“ihib”盒子中定义，其专用于ALC或者FLUTE。在通过ALC或者FLUTE来发送当前项目中的所有内容时，可以使用它。
aligned(8)class BMFDPitemhintinformation extends box(‘bdih’){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        char sdptext[]；
}
(c)影片广播下载信息。影片级别提示信息容器在“hnti”盒子中定义，其专用于ALC或者FLUTE。在通过ALC或者FLUTE来发送当前影片中的全部内容时，可以使用它。
aligned(8)class BMFDPmoviehintinformation extends box(‘bdmh’){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        char sdptext[]；
}
(d)跟踪广播下载信息。跟踪级别提示信息容器在“hnti”盒子中定义，其专用于ALC或者FLUTE。在通过ALC或者FLUTE来发送当前跟踪中的全部内容时，可以使用它
aligned(8)class BMFDPtrackhintinformation extends box(‘bdth’){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        char sdptext[]；
}
在ALC+RTP传输系统中，可以将针对ALC和RTP流的SDP信息结合在一起。这种情况可以发生在SVG媒体包含离散和连续嵌入媒体二者时。离散媒体通过ALC传输，并且连续媒体通过RTP传输。继而可以将SDP信息保存在后续盒子中。2005年9月1日递交的美国临时专利申请No.60/713,303定义了不同级别的(例如，呈现、影片、项目)用于FLUTE+RTP的盒子。然而，可以针对广播下载归纳相同的盒子，以同样地包括ALC。因此，盒子的前缀是“BMFDP”以便更为通用，以存储针对ALC+RTP或者FLUTE+RTP的SDP。称为“protocol”的标志指明盒子是用于FLUTE的还是用于ALC的。以下是三个不同级别的盒子：
(a)呈现SDP信息
aligned(8)class BMFDPrtppresentationhintinformation extends box(‘bdrp‘){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        chars   dptext[]；
}
(b)影片SDP信息
aligned(8)class BMFDPrtpmoviehintinformation extends box(‘bdrm‘){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        chars   dptext[]；
}
(c)项目SDP信息
aligned(8)class BMFDPrtpitemhintinformation extends box(‘bdri‘){
        uint protocol；//0 for ALC，1 for FLUTE
        uint(32)descriptionformat＝‘sdp‘；
        charsdptext[]；
}
本发明的第二实现涉及使用盒子来存储元数据信息。为了使用广播/多播文件下载协议(ALC/FLUTE)来传输内部嵌入的离散媒体，需要服务器还传输一些对应于该离散媒体的元数据。由此，本发明的该实现包括将该元数据封装到ISO基媒体文件格式中。
如果使用FLUTE作为广播协议，则将元数据作为FDT的一部分来发送，或者，如果将ALC与OMA BCAST ESG结合使用，则将元数据作为OMA BCAST ESG的一部分来发送。EDG提供用于描述与将要在数字移动广播服务中通过ALC来发送的文件相关联的各种元数据的机制。此外，当通过PtM和/或PtP通道下载ESG时，ESG规定了服务向导递送单元(SGDU)和服务向导递送描述符(SGDD)的使用，以用于ESG的一致性控制。
在广播/多播文件下载期间更新的元数据可以带内或带外地执行。带内元数据更新使用FLUTE的FDT来执行，其中FDT实例ID标识了FDT中元数据的最新版本。如果将元数据作为ALC中的SGDU对象来通过信号传输，则根据SGDU或者SG段版本系统来更新ESG。对于新SGDU的PtM传输，存在两个选项。在第一选项中，在独立的ALC会话中发送新的SGDU对象。在第二选项中，将新SGDU对象添加到作为原始ALC会话的相同ALC会话中。
美国临时专利申请No.60/713,303描述了通过定义盒子来存储FDT实例的数据而对ISO基媒体文件格式进行扩展。然而，可以针对广播下载(同样包括ALC)来归纳同样的盒子以存储元数据。如第一实现中一样，盒子的前缀是“BMFDP”，以便更为通用，以存储针对广播/多播下载的元数据。用于广播/多播下载的任何协议都需要这些文件参数。如下所述，针对所有四个级别(即，呈现、影片、跟踪和项目)定义了盒子。
(a)呈现元数据信息。呈现级别元数据容器在“bdph”或者“bdrp”盒子中定义，其分别专用于ALC/FLUTE或者ALC/FLUTE+RTP传输方案。
aligned(8)class BMFDPpresentationmetadatainformation extends box(‘bmpm’){
                String       Content-Location；
                unsignedLong Content-Length；
                unsignedLong Transfer-Length；
                String       Content-Type’
                String       Content-Encoding；
                Base64Binary Content-MD5；
}
可以通过ISO/IEC 15444-12：2005中的小节8.44.7中定义的URL表单来引用嵌入媒体资源的Content-Location(内容地址)。
(b)项目元数据信息。项目级别元数据容器在“bdih”或者“bdri”盒子中定义，其分别专用于ALC/FLUTE或者ALC/FLUTE+RTP传输方案。
aligned(8)class BMFDPitemmetadatainformation extends box(‘bmim’){
              String       Content-Location；
              unsignedLong Content-Length；
              unsignedLong Transfer-Length；
              String       Content-Type’
              String       Content-Encoding；
              Base64Binary Content-MD5；
}
(c)影片元数据信息。影片级别元数据容器在“hnti”盒子中定义，其专用于ALC/FLUTE。
aligned(8)class BMFDPmoviemetadatainformation extends box(‘bmmm’){
                String       Content-Location；
                unsignedLong Content-Length；
                unsignedLong Transfer-Length；
                String       Content-Type’
                String       Content-Encoding；
                Base64Binary Content-MD5；
}
(d)跟踪元数据信息。跟踪级别元数据容器在“bdth”盒子中定义，其专用于ALC/FLUTE。在通过ALC/FLUTE来发送当前跟踪中的所有内容时，可以使用它。
aligned(8)class BMFDPtrackmetadatainformation extends box(‘bmtm’){
                String       Content-Location；
                unsignedLong Content-Length；
                unsignedLong Transfer-Length；
                String       Content-Type’
                String       Content-Encoding；
                Base64Binary Content-MD5；
}
本发明的第三实现涉及使用盒子来存储提示跟踪信息。归纳提示跟踪结构是为了支持多个数据格式中的提示采样。提示跟踪采样包含构建正确类型的分组报头所需的任何数据。提示跟踪采样还包含指向属于分组的数据块的指针。这种数据可以是SVG、连续嵌入媒体和离散嵌入媒体。
提示跟踪采样不是提示跟踪盒子结构的一部分，虽然它们通常位于同一文件中。提示跟踪数据引用盒子(“dref”)和采样表盒子(“stbl”)被用以查找针对特定采样的文件规范和字节偏移。提示跟踪采样数据是字节对齐的，并且总是大端字节序(big-endian)格式的。
下面将讨论针对ALC的提示跟踪格式。美国临时专利中请No.60/713,303描述了不同级别的(例如，呈现、影片、跟踪、项目)用于FLUTE提示跟踪信息的盒子。然而，可以针对广播下载归纳同样的盒子，以同样地包括ALC。由此，盒子的前缀可以是“BMFDP”，以便更为通用，以存储针对ALC或者FLUTE的提示跟踪信息。
类似于RTP提示跟踪的层级，定义了BMFDPHintSampleEntry和BMFDPsample。此外，还定义了一些相关结构和构造符。还添加了“protocol”来指明盒子是用于FLUTE的还是用于ALC的。
(a)采样描述格式。BMFDP提示跟踪是具有“bmfd”的采样描述中的条目格式的提示跟踪(媒体句柄“hint”)。BMFDPHintSampleEntry被包含在SampleDescriptionBox(‘stsd’)中。
class BMFDPHintS ampleEntry()extends SampleEntry(bmfd‘){
       uint protocol；// 0 for ALC，1 for FLUTE
       uint(16)          hinttrackversion＝1；
       uint(16)          highestcompatibleversion＝1；
       uint(32)          maxpacketsize；
       box       additionaldata[]；//optional
}
字段“hinttrackversion”、“highestcompatibleversion”和“maxpacketsize”具有与ISO/IEC 15444-12：2005规范的小节10.2中描述的“RtpHintSampleEntry”中相同的解释。其他数据是来自“timescaleentry”和“timeoffset”的一组盒子，其在ISO/IEC15444-12：2005的小节10.2中参考。这些盒子对于ALC/FLUTE是可选的。
(b)采样格式。提示跟踪中的每个BMFDPsample(BMFDP采样)将分别生成一个或多个BMFDP分组。与RTP采样相比，BMFDP采样不具有其自己特定的时间戳，而是顺序地发送。考虑TimeToSampleBox中保存的采样增量(sample-delta)，如果BMFDP采样代表嵌入媒体或SVG内容的段，则当前媒体/SVG的第一采样与在前媒体/SVG的最后采样之间的sample-delta与当前和在前媒体/SVG所属于的场景/更新的开始时间之间的差异具有相同的值。针对当前媒体/SVG中的连续采样的其余部分的sample-delta是零。然而，如果BMFDP采样代表整个媒体或者SVG内容，则此BMFDP采样之后将不具有增量等于0的后继采样(包含来自同一媒体/SVG的后继数据)。因此，对于当前BMFDP采样，仅存在一个采样增量。
每个采样包含两个区域：组成分组的指令，以及在发送这些分组时所需的任何其他数据(例如，媒体数据的加密版本)。应当注意，根据采样大小表可知采样的大小。
aligned(8)class BMFDPsample{
        uint protocol；//0 for ALC，1 for FLUTE
        unsigned int(16)        packetcount；
        unsigned int(16)        reserved；
        BMFDPpacket packets[packetcount]；
        byte        extradata[]；             //optional
}
(c)分组条目格式。分组条目表中的每个分组具有以下结构：
aligned(8)class BMFDPpacket{
        uint protocol；//0 for ALC，1 for FLUTE
        BMFDPheader bmfdp_header；
        unsigned int(16)  entrycount；
        dataentry         constructors[entrycount]；
}
“bmfdp_header”包含用于当前BMFDP分组的报头。“entry_count”是随后构造符的计数，其中构造符是用来构造BMFDP分组的结构。
aligned(8)class BMFDPheader{
        uint protocol；//0 for ALC，1 for FLUTE
        UDPheader        header；
        LCTheader        lct_header；
        variable         FEC_payload_ID；
}
FEC_payload_ID由必须在会话描述中传送的FEC编码ID来确定。
class pseudoheader{
        unsigned int(32)source_address；
        unsigned int(32)destination_address；
        unsigned int(8)zero；
        unsigned int(8)protocol；
        unsigned int(16)UDP_length；
}
class UDPheader{
        pseudoheader pheader；
        unsigned int(16)source_port；
        unsigned int(16)destination_port；
        unsigned int(16)length；
        unsigned int(16)checksum；
}
 class LCTheader{
        unsigned int(4)V_bits；
        unsigned int(2)C_bits；
        unsigned int(2)reserved；
        unsigned int(1)S_bit；
        unsigned int(2)O_bits；
        unsigned int(1)H_bit；
        unsigned int(1)T_bit；
        unsigned int(2)R_bit；
        unsigned int(2)A_bit；
        unsigned int(2)B_bit；
        unsigned int(8)header_length；
        unsigned int(8)codepoint
        unsigned int((C_bits+1)*32)congestion_control_information；
        unsigned int(S_bit*32+H_bit*16)transport_session_identifier；
        unsigned int(O_bits*32+H_bit*16)transport_object_identifier；//For EXT FDT，
TOI＝0
        if(T_bit＝＝1){
                unsigned int(32)sender_current_time；
        }
        if(T_bit＝＝1){
                 unsigned int(32)expected_residual_time；
        }
            if(header_length>(32+(C_bits+1)*32+S_bit*32+H_bit*16+O_bits*32+
     H_bit*16)){
                    LCTheaderextentions header_extention；
             }
     }
     class LCTheaderextentions{
          unsigned int(8)header_extention_type；//192-EXT_FDT，193-EXT_CENC，64-
     EXT_FTI
          if(header_extention_type<＝127){
                  unsigned int(8)header_extention_length；
          }
          if(header_extention_type＝＝64){
                 unsigned int(48)transfer_length；
if((FEC_encoding_ID＝＝0)‖(FEC_encoding_ID＝＝128)‖(FEC_encoding_ID＝＝130)){
                     unsigned int(16)encoding_symbol_length；
                     unsigned int(32)max_source_block_length；
             }
             else if((FEC_encoding_ID>＝128)‖(FEC_encoding_ID<＝255)){
                      unsigned int(16)FEC_instance_ID；
             }
               else if(FEC_encoding_ID＝＝129){
                       unsigned int(16)encoding_symbol_length；
                       unsigned int(16)max_source_block_length；
                       unsigned int(16)max_num_of_encoding_symbol；
                }
       }
       else if(header_extention_type＝＝192){
             unsigned int(4)version＝1；
             unsigned int(20)FDT_instance_ID；
       }
       else if(header_extention_type＝＝193){
             unsigned int(8)content_encoding_algorithm；//ZLIB，DEFLATE，GZIP
             unsigned int(16)reserved＝0；
       }
       else{
             byte other_extentions_content[]；
       }
}
下面使用的FEC_encoding_ID必须在会话描述中通过信号发送。header_extension_type＝64对于LAC和FLUTE二者都有效。其用于EXT_FTI，即携带FEC对象传输信息的报头扩展。header_extension_type＝192仅对于FLUTE有效。其用于EXT_FDT，即通知特定的FLUTE分组包含FDT实例而不是文件作为有效载荷这一事实的报头扩展。header_extension_type＝193仅对于FLUTE有效。其用于EXT_CENC，即指明FDT实例所使用的内容编码的报头扩展。
(d)构造符格式。存在各种构造符形式。为了更容易的迭代，每个构造符是16个字节。第一字节是联合辨别符。该结构基于ISO/IEC15444-12：2005中的小节10.3.2。
aligned(8)class BMFDPconstructor(type){
        uint protocol；//0 for ALC，1 for FLUTE
        unsigned int(8)constructor_type＝tyPe；
}
aligned(8)class BMFDPnoopconstructor extends BMFDPconstructor(0)
{
        uint(8)pad[15]；
}
aligned(8)class BMFDPimmediateconstructor extends BMFDPconstructor(1)
{
        unsigned int(8)count；
        unsigned int(8)data[count]；
        unsigned int(8)pad[14-count]；
}
aligned(8)class BMFDPsampleconstructor extends BMFDPconstructor(2)
{
        signed int(8)   trackrefindex；
        unsigned int(16)length；
        unsigned int(32)samplenumber；
        unsigned int(32)sampleoffset；
        unsigned int(16)bytesperblock＝1；
        unsigned int(16)samplesperblock＝1；
}
aligned(8)class BMFDPsampledescriptionconstructor extends BMFDPconstructor(3)
{
        signed int(8)   trackrefindex；
        unsigned int(16)length；
        unsigned int(32)sampledescriptionindex；
        unsigned int(32)sampledescriptionoffset；
        unsigned int(32)reserved；
}
aligned(8)class BMFDPitemconstructor extends BMFDPconstructor(4)
{
        unsigned int(16)item_ID；
        unsigned int(16)extent_index；
        unsigned int(64)data_offset；//offset in byte within extent
        unsigned int(32)data_length； //length in byte within extent
}
aligned(8)class BMFDPxmlboxconstructor extends BMFDPconstructor(5)
{
        unsigned int(64)data_offset；//offset in byte within XMLBox or BinaryXMLBox
        unsigned int(32)data_length；
        unsigned int(32)reserved；
}
FDT数据是整个FLUTE/ALC数据流的一部分。该数据是以FLUTE分组的形式在FLUTE会话期间带内传输的，或者是使用ESG或者通过其他手段在ALC会话期间带外传输的。使用在此定义的构造符来将SGDU映射到ALC分组。下面提供了构造符的语法：
aligned(8)class ALCsgduconstructor extends BMFDPconstructor(6)
{
      unsigned int(2)sgdu_box；                  //0-′sgdp′，1-′sgdm′，2-′sgdi′，3-′sgdt′
      if((sgdu_box＝＝0)‖(sgdu_box＝＝1)‖(sgdu_box＝＝2)){
            unsigned int(30)instance_index；//index of the SGDU
            unsigned int(64)data_offset；   //offset in byte within the given SGDU
            unsigned int(32)data_length；   //length in byte within the given SGDU
      }else{
            unsigned int(64)data_offset；   //offsetinbyte within the given SGDU box
            unsigned int(32)data_length；  //length in byte within the given SGDU box
            bit      pad[30]；            //padding bits
      }
}
下面讨论针对ALC+RTP来使用提示跟踪。在呈现期间同时传输RTP和BMFDP(ALC/FLUTE)分组二者的情况下，针对RTP和BMFDP的构造符二者都要使用。使用RTP分组来传输连续媒体和SVG内容，而使用BMFDP分组来传输离散媒体。对于这种情况，使用不同的提示系统。这种系统可以按照恰当的时间顺序来结合所有RTP以及BMFDP采样。
美国临时专利申请No.60/713,303描述了不同层级的用于FLUTE+RTP提示跟踪信息的盒子。然而，可以针对广播下载归纳相同的盒子，以便同样地包括ALC。由此，下面的盒子以“BMFDP”为前缀，以便更为通用。
为了促进BMFDP和RTP分组的生成以用于呈现，下面定义了用于BMFDP+RTP的提示跟踪格式。类似于RTP和BMFDP提示跟踪的层级，定义了BMFDPRtpHintSampleEntry和BMFDPRTPsample。此外，TimeToSampleBox中的数据给出了每个分组的时间信息。
(a)采样描述格式。BMFDP+RDP提示跟踪是具有“frhs”的采样描述中的条目格式的提示跟踪(媒体句柄“hint”)；BMFDPRtpHintSampleEntry在SampleDescriptionBox“stsd”中定义。
class BMFDPRtpHintSampleEntry()extends SampleEntry(‘brhs‘){
       uint protocol；//0 for ALC，1 for FLUTE
       uint(16)  hinttrackversion＝1；
       uint(16)  highestcompatibleversion＝1；
       uint(32)  maxpacketsize；
       box       additionaldata[]；
}
hinttrackversion(提示跟踪版本)目前是1。最高兼容版本字段规定了该跟踪向后兼容的最旧版本。maxpacketsize(最大分组大小)指明了该跟踪将生成的最大分组的大小。其他数据是一组盒子(“tims”和“tsro”)，其在ISO基媒体文件格式中定义。
(b)采样格式。BMFDPRTSample在MediaDataBox(“mdat”)中定义。该盒子包含多个BMFDP采样、RTP采样、可能的FDT/SGDU和SDP信息以及任何其他数据。一个BMFDPRTSample可以包含一个FDT/SGDU数据、SDP数据、BMFDP采样或者RTP采样。包含BMFDP采样的BMFDPRTSample在此仅用来传输离散媒体。这样的媒体总是嵌入在SVG呈现中的场景或场景更新中。其开始时间与其所属的场景/场景更新的开始时间相同。BMFDP采样没有其自己特定的时间戳，而是顺序地发送，紧随在其所属的场景/场景更新的RTP采样之后。因此，在TimeToSampleBox中，针对离散媒体的BMFDPRTSample的采样增量全部设置为0。其连续的顺序代表了其发送时间顺序。
UE可能具有有限的功率，并且在任意时刻可以只支持一个传输会话，并且BMFDP会话和RTP会话需要一个接一个的交替。在紧接着一个完成之后另一个将开始。这种情况下，使用下面的description_text1、description_text2和description_text3字段来提供用于每个会话的SDP和FDT/SGDU信息。
aligned(8)class BMFDPRTPSample{
        uint protocol；//0 for ALC，1 for FLUTE
        unit(2)            sample_type；
        unsigned int(6)    reserved；
        if(sample_type＝＝0){
//FDT instance info for the FLUTE samples or SGDU info for the ALC//samples
                  char       metadatatext[]；
        }
        else if(sample_type＝＝1){
                char     sdptext[]；//SDP infoforthe samples
        }
        else if(sample_type＝＝2&&protocol＝＝0){
                BMFDPsample alc_sample；
        }
        else if(sample_type＝＝2 & & protocol＝＝1){
                BMFDPsample flute_sample；
        }
        else{
                RTPsample     rtp_sample；
        }
        byte extradata[]；
}
除上述之外，本发明还有若干其他潜在的实现。下面讨论一些这种备选实现。本发明的第四实现类似于上文讨论的第一实现。然而，可以存储诸如DCCPtext的其他描述格式，在这种情况下，sdptext字段将相应改变。第五实现类似于第二实现。然而，在该实施方式中，单个段字段可以包含ESG中的全部段数据。应用继而可以选择是将该数据划分为针对文件还是所有级别的不同字段。
本发明的多个潜在实现在多个方面类似于上面讨论的第三实现，其具有各种差异。例如，可以重新定义其他级别的“hnti”盒子，以便例如包含呈现级别或者项目级别的会话信息。对于用于ALC的提示跟踪信息的采样描述格式，hinttrackversion和highestcompatibleversion字段可以具有不同的值，并且除了maxpacketsize字段之外还可以添加minpacketsize字段。对于用于ALC的提示跟踪格式的采样格式，可以通过删除预留字段使packetcount字段变为32位。对于用于ALC的提示跟踪格式的分组条目格式，不同报头盒子(BMFDPheader、UDPheader、LCTheader等)的层级结构可以不同。对于用于ALC的提示跟踪格式的构造符格式，ALCsgdutconstructor语法可以针对每个sgdu_box的独立的字段定义，BMFDPitemconstructor可以通过item_name来替换item_id，BMFDPxmlboxconstructor可以通过删除预留字段使data_length字段变为64字节，并且BMFDPxmlboxconstructor可以使data_length字段变为16字节并将预留字段调节为64字节。对于用于ALC+RTP的提示跟踪，BMFDPRtpHintSampleEntry可以使hinttrackversion和highestcompatibleversion字段具有不同的值，BMFDPRtpHintSampleEntry除了maxpacketsize字段之外还可以添加minpacketsize，并且BMFDPRTPSample盒子可以具有针对每个sample_type(采样类型)的独立的字段定义。
在多个使用情况中，富媒体服务可以得益于使用ALC作为协议。第一用例涉及较长卡通动画的预览。本发明的服务允许最终用户在确定他或她想要完整地观看的卡通之前，渐进式地下载每个卡通的较小部分。
本发明的第二用例涉及交互式移动电视服务。通过本发明，可以在最终用户界面中一起递送富媒体内容的确定性绘制和行为。内容可以包括音频-视频内容、文本、图形、图像以及电视和无线电频道。服务必须提供对单个应用或服务中的内容的传统导航，并且服务必须允许本地或远程设置中的同步交互，诸如投票和个性化(例如，相关的菜单或子菜单，广告，以及最终用户简档或者服务订购的功能中的内容)。可以通过与iTV移动服务中可用的四个服务和子服务相对应的四个步骤来描述这种使用情况：马赛克菜单显示电视频道景观，电子节目向导和相关iTV服务的触发，iTV服务，以及个性化菜单(诸如“体育新闻”)。
本发明的第三用例涉及在线企业数据馈送的使用。该服务例如包括：提供实时报价流式传输的证券报价机，具有技术指示符的一日图表，新闻监控，天气提示，图表，商业更新，体育比分等。
本发明的第四用例涉及在线聊天服务。在线聊天服务可以包含在web摄像机、视频频道或者富媒体博客服务中。最终用户可以进行注册，保存其姓名并交换消息。在线聊天服务中的消息动态地出现，伴有最终用户提供的富媒体数据。聊天服务可以是专用的，或者同时在一个或多个多通道上是公共的。将来自其他用户的新消息动态地提示给最终用户。可以在不重新载入整个页面的情况下进行服务内消息的动态更新。
本发明的第五用例涉及卡拉OK服务。卡拉OK服务显示伴随有歌曲的语音的音乐电视频道或者视频片段目录，其中在歌词的文本字符上具有类似于流动的动画(例如，字体颜色的平滑过渡，文字滚动，等等)。最终用户可以通过选择交互式按钮来下载他或她选择的歌曲以及完整的动画。类似的系统可以用于电影或电视表演或片段的再制定。
图4和图5示出了其中可以实现本发明的一个代表性电子设备12。然而，应当理解，并非意在将本发明限于一种特定类型的电子设备。图4和图5的电子设备12包括：外壳30，液晶显示器形式的显示器32，小键盘34，麦克风36，耳机38，电池40，红外端口42，天线44，智能卡46(根据本发明的一个实施方式，其形式是UICC)，读卡器48，无线接口电路52，编解码器电路54，控制器56以及存储器58。各个电路和元件是本领域内公知的所有类型，例如Nokia系列移动电话中的类型。
本发明是在方法步骤的总体上下文中描述的，在个实施方式中，可以通过包括由网络化环境中的计算机执行的计算机可执行指令(诸如程序代码)的程序产品来实现本发明。一般地，程序模块包括执行特定任务或者实现特定的抽象数据类型的例行程序、程序、对象、组件、数据结构等。计算机可执行指令、关联的数据结构以及程序模块代表了用于执行在此公开的方法步骤的程序代码的示例。这些可执行指令或者数据结构的特定序列代表了用于实现在这些步骤中描述的功能的相应动作的示例。
可以通过标准编程语言来实现本发明的软件和web实现，其中标准编程技术具有基于规则的逻辑或者其他逻辑，以实现各种数据库搜索步骤、相关步骤、比较步骤和决策步骤。应当注意，这里和权利要求中使用的词语“组件”和“模块”意在涵盖使用一行或多行软件代码和/或硬件实现和/或用于接收手工输入的装置的实现。
出于说明和描述的目的，已经给出了对本发明实施方式的上述描述。该描述并非意在详尽或是将本发明限于所公开的精确形式，并且根据上述启示可以进行修改和变形，或者可以在对本发明的实践中获得修改和变形。挑选和描述实施方式是为了解释本发明的原理及其实践应用，以便使本领域的技术人员能够按照适于预期的特定用途来使用本发明的各种实施方式以及进行各种修改。

Claims (35)

1.一种用于将富媒体内容渐进式地提供给客户端设备的方法，包括：
按照ISO基媒体文件格式，从输入信息来编码ISO基媒体文件，其中所述输入信息包括：
可伸缩矢量图形，
用于ALC和FLUTE之一的文件元数据信息，以及
用于ALC和FLUTE分组化之一的提示跟踪信息；以及
在多个RTP分组和选自包括ALC分组和FLUTE分组的组的分组中将编码的ISO基媒体文件发送给所述客户端设备，所述ISO基媒体文件包括离散文件的元数据。
2.根据权利要求1所述的方法，其中，所述输入信息进一步包括：用于ALC和FLUTE之一的会话描述协议(SDP)信息，并且其中，所述ISO基媒体文件进一步包括会话描述信息。
3.根据权利要求1所述的方法，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息的多个SDP盒子。
4.根据权利要求1所述的方法，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP信息的多个SDP盒子。
5.根据权利要求1所述的方法，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE元数据信息的多个SDP盒子。
6.根据权利要求3所述的方法，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述多个SDP盒子用于包含ALC或者FLUTE信息以及RTP元数据信息。
7.根据权利要求1所述的方法，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE提示跟踪信息的多个SDP盒子。
8.根据权利要求7所述的方法，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述多个SDP盒子用于包含ALC或者FLUTE信息以及RTP提示跟踪信息。
9.一种用于将富媒体内容渐进式地提供给客户端设备的计算机程序产品，包括：
计算机代码，用于按照ISO基媒体文件格式，从输入信息来编码ISO基媒体文件，其中所述输入信息包括：
可伸缩矢量图形，
用于ALC和FLUTE之一的文件元数据信息，以及
用于ALC和FLUTE分组化之一的提示跟踪信息；以及
计算机代码，用于在多个RTP分组和选自包括ALC分组和FLUTE分组的组的分组中将编码的ISO基媒体文件发送给所述客户端设备，所述ISO基媒体文件包括离散文件的元数据。
10.根据权利要求9所述的计算机程序产品，其中，所述输入信息进一步包括：用于ALC和FLUTE之一的会话描述协议(SDP)信息，并且其中，所述ISO基媒体文件进一步包括会话描述信息。
11.根据权利要求9所述的计算机程序产品，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息的多个SDP盒子。
12.根据权利要求11所述的计算机程序产品，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP信息的多个SDP盒子。
13.根据权利要求9所述的计算机程序产品，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE元数据信息的多个SDP盒子。
14.根据权利要求13所述的计算机程序产品，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP元数据信息的多个SDP盒子。
15.根据权利要求9所述的计算机程序产品，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE提示跟踪信息的多个SDP盒子。
16.根据权利要求15所述的计算机程序产品，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP提示跟踪信息的多个SDP盒子。
17.一种电子设备，包括：
处理器；以及
存储器单元，其与处理器可通信地连接，并且包括：
计算机代码，用于按照ISO基媒体文件格式，从输入信息来编码ISO基媒体文件，其中所述输入信息包括：
可伸缩矢量图形，
用于ALC和FLUTE之一的文件元数据信息，以及
用于ALC和FLUTE分组化之一的提示跟踪信息；以及
计算机代码，用于在多个RTP分组和选自包括ALC分组和FLUTE分组的组的分组中将编码的ISO基媒体文件发送给所述客户端设备，所述ISO基媒体文件包括离散文件的元数据。
18.根据权利要求17所述的电子设备，其中，所述输入信息进一步包括：用于ALC和FLUTE之一的会话描述协议(SDP)信息，并且其中，所述ISO基媒体文件进一步包括会话描述信息。
19.根据权利要求17所述的电子设备，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息的多个SDP盒子。
20.根据权利要求19所述的电子设备，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP信息的多个SDP盒子。
21.根据权利要求17所述的电子设备，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE元数据信息的多个SDP盒子。
22.根据权利要求21所述的电子设备，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP元数据信息的多个SDP盒子。
23.根据权利要求17所述的电子设备，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE提示跟踪信息的多个SDP盒子。
24.根据权利要求23所述的电子设备，其中，所述可伸缩矢量图形包含离散媒体和连续媒体二者，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP提示跟踪信息的多个SDP盒子。
25.一种在客户端设备上展示富媒体内容的方法，包括：
从富媒体服务器接收多个RTP分组以及选自包括ALC分组和FLUTE分组的组的多个分组中的ISO基媒体文件，所述ISO基媒体文件包括离散文件的元数据；
解码所述ISO基媒体文件；以及
播放解码的ISO基媒体文件。
26.根据权利要求25所述的方法，其中，所述ISO基媒体文件进一步包括会话描述信息。
27.根据权利要求25所述的方法，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息的多个SDP盒子。
28.根据权利要求27所述的方法，其中，所述ISO基媒体文件是从包含离散媒体和连续媒体二者的可伸缩矢量图形而生成的，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP信息的多个SDP盒子。
29.根据权利要求25所述的方法，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE元数据信息的多个SDP盒子。
30.根据权利要求29所述的方法，其中，所述ISO基媒体文件是从包含离散媒体和连续媒体二者的可伸缩矢量图形而生成的，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP元数据信息的多个SDP盒子。
31.根据权利要求25所述的方法，其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE提示跟踪信息的多个SDP盒子。
32.根据权利要求31所述的方法，其中，所述ISO基媒体文件是从包含离散媒体和连续媒体二者的可伸缩矢量图形而生成的，并且其中，所述ISO基媒体文件包括用于包含ALC或者FLUTE信息以及RTP提示跟踪信息的多个SDP盒子。
33.一种用于将富媒体内容渐进式地提供给客户端设备的方法，包括：
按照ISO基媒体文件格式，从输入信息来创建ISO基媒体文件；
编码所述ISO基媒体文件；以及
将编码的ISO基媒体文件传输至所述客户端设备。
34.一种包含在计算机可读介质中的计算机程序产品，用于将富媒体内容渐进式地提供给客户端设备，所述计算机程序产品包括：
用于按照ISO基媒体文件格式，从输入信息来创建ISO基媒体文件的计算机代码；
用于编码所述ISO基媒体文件的计算机代码；以及
用于将编码的ISO基媒体文件传输至所述客户端设备的计算机代码。
35.一种电子设备，包括：
处理器；以及
存储器单元，其与所述处理器可通信地连接，并包括用于将富媒体内容渐进式地提供给客户端设备的计算机程序产品，所述计算机程序产品包括：
用于按照ISO基媒体文件格式，从输入信息来创建ISO基媒体文件的计算机代码；
用于编码所述ISO基媒体文件的计算机代码；以及
用于将编码的ISO基媒体文件传输至所述客户端设备的计算机代码。
CNA2007800067851A 2006-01-11 2007-01-11 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式 Pending CN101390367A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510372735.1A CN105024852B (zh) 2006-01-11 2007-01-11 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式的方法和装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US75825606P 2006-01-11 2006-01-11
US60/758,256 2006-01-11

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN201510372735.1A Division CN105024852B (zh) 2006-01-11 2007-01-11 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式的方法和装置

Publications (1)

Publication Number Publication Date
CN101390367A true CN101390367A (zh) 2009-03-18

Family

ID=38256031

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201510372735.1A Expired - Fee Related CN105024852B (zh) 2006-01-11 2007-01-11 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式的方法和装置
CNA2007800067851A Pending CN101390367A (zh) 2006-01-11 2007-01-11 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201510372735.1A Expired - Fee Related CN105024852B (zh) 2006-01-11 2007-01-11 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式的方法和装置

Country Status (6)

Country Link
US (1) US7917644B2 (zh)
EP (2) EP2790380A1 (zh)
KR (1) KR100959574B1 (zh)
CN (2) CN105024852B (zh)
ES (1) ES2526814T3 (zh)
WO (1) WO2007080500A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101950427A (zh) * 2010-09-08 2011-01-19 东莞电子科技大学电子信息工程研究院 一种适用于移动终端的矢量线段轮廓化方法
WO2014079027A1 (en) * 2012-11-22 2014-05-30 Thomson Licensing Apparatus and method for extending tv services with rich media services

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1760933B1 (en) * 2004-08-06 2012-03-14 Panasonic Corporation Feedback control for multicast or broadcast services
FR2907627B1 (fr) * 2006-10-20 2008-12-19 Alcatel Sa Dispositif de selection de type de canal de transport pour la diffusion de contenus vers des terminaux de communication
US8391775B2 (en) * 2007-03-09 2013-03-05 Airbiquity Inc. Mobile digital radio playlist system
US8690670B2 (en) 2007-06-14 2014-04-08 Harmonix Music Systems, Inc. Systems and methods for simulating a rock band experience
US8678896B2 (en) 2007-06-14 2014-03-25 Harmonix Music Systems, Inc. Systems and methods for asynchronous band interaction in a rhythm action game
CN101359996B (zh) 2007-08-02 2012-04-04 华为技术有限公司 媒体业务呈现方法及通讯系统以及相关设备
WO2009024926A1 (en) * 2007-08-20 2009-02-26 Nokia Corporation Segmented metadata and indexes for streamed multimedia data
KR101418591B1 (ko) * 2007-10-05 2014-07-10 삼성전자주식회사 휴대 방송 시스템에서의 서비스 가이드 제공 방법 및 장치
EP2215842A2 (en) * 2007-12-03 2010-08-11 Nokia Corporation Systems and methods for storage of notification messages in iso base media file format
KR101481504B1 (ko) * 2007-12-26 2015-01-13 엘지전자 주식회사 서비스 가이드 정보 처리 방법 및 서비스 가이드 정보 처리장치
WO2009103851A1 (en) * 2008-02-22 2009-08-27 Nokia Corporation Apparatus and method of providing an integrated rich media environment
WO2009114111A2 (en) * 2008-03-12 2009-09-17 Packetvideo Corp. System and method for reformatting digital broadcast multimedia for a mobile device
CN102158811B (zh) * 2008-04-11 2013-10-09 华为技术有限公司 一种bcast中通知消息呈现方式的方法和装置
KR20090119412A (ko) * 2008-05-16 2009-11-19 엘지전자 주식회사 이동 단말기 및 이것의 방송 콘텐츠 구매 제어 방법
US8526350B2 (en) * 2008-05-23 2013-09-03 Qualcomm Incorporated Systems and methods for carrying broadcast services over a mobile broadcast network
WO2010006054A1 (en) * 2008-07-08 2010-01-14 Harmonix Music Systems, Inc. Systems and methods for simulating a rock and band experience
KR101525248B1 (ko) * 2008-07-16 2015-06-04 삼성전자주식회사 리치미디어 서비스를 제공하는 방법 및 장치
US20100037258A1 (en) * 2008-08-07 2010-02-11 Research In Motion Limited Mobile broadcasting system and method for enhancing mobile broadcasting services with rich media including an enhanced service guide
CN102144398A (zh) * 2008-10-28 2011-08-03 爱尔比奎特公司 对车辆内无线电设备中播放的音乐的购买
US9235572B2 (en) * 2008-10-31 2016-01-12 Disney Enterprises, Inc. System and method for updating digital media content
US8364657B2 (en) 2008-10-31 2013-01-29 Disney Enterprises, Inc. System and method for providing media content
WO2010058963A2 (ko) * 2008-11-18 2010-05-27 엘지전자 주식회사 비실시간 서비스 처리 방법 및 방송 수신기
US8904191B2 (en) 2009-01-21 2014-12-02 Microsoft Corporation Multiple content protection systems in a file
US8449360B2 (en) 2009-05-29 2013-05-28 Harmonix Music Systems, Inc. Displaying song lyrics and vocal cues
US8465366B2 (en) 2009-05-29 2013-06-18 Harmonix Music Systems, Inc. Biasing a musical performance input to a part
US8838332B2 (en) * 2009-10-15 2014-09-16 Airbiquity Inc. Centralized management of motor vehicle software applications and services
US8942888B2 (en) 2009-10-15 2015-01-27 Airbiquity Inc. Extensible scheme for operating vehicle head unit as extended interface for mobile device
US9002574B2 (en) 2009-10-15 2015-04-07 Airbiquity Inc. Mobile integration platform (MIP) integrated handset application proxy (HAP)
US8831823B2 (en) * 2009-10-15 2014-09-09 Airbiquity Inc. Centralized management of motor vehicle software applications and services
US9981193B2 (en) 2009-10-27 2018-05-29 Harmonix Music Systems, Inc. Movement based recognition and evaluation
US10357714B2 (en) * 2009-10-27 2019-07-23 Harmonix Music Systems, Inc. Gesture-based user interface for navigating a menu
CA2783592A1 (en) 2009-12-11 2011-06-16 Nokia Corporation Apparatus and methods for describing and timing representations in streaming media files
US8550908B2 (en) 2010-03-16 2013-10-08 Harmonix Music Systems, Inc. Simulating musical instruments
US8562403B2 (en) 2010-06-11 2013-10-22 Harmonix Music Systems, Inc. Prompting a player of a dance game
US9358456B1 (en) 2010-06-11 2016-06-07 Harmonix Music Systems, Inc. Dance competition game
US20110306397A1 (en) 2010-06-11 2011-12-15 Harmonix Music Systems, Inc. Audio and animation blending
US9024166B2 (en) 2010-09-09 2015-05-05 Harmonix Music Systems, Inc. Preventing subtractive track separation
US9438883B2 (en) * 2012-04-09 2016-09-06 Intel Corporation Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content
EP2859464B1 (en) 2012-06-08 2020-09-16 Airbiquity, Inc. Assessment of electronic sensor data to remotely identify a motor vehicle and monitor driver behavior
CN104919833B (zh) 2012-12-20 2019-11-08 爱尔比奎特公司 高效头单元通信集成
US9830621B2 (en) 2013-03-14 2017-11-28 Vdopia Inc. Systems and methods for layering content
US9781181B2 (en) * 2013-06-17 2017-10-03 Qualcomm Incorporated Multiple file delivery over unidirectional transport protocol sessions for a service
EP3036883B3 (en) 2014-02-24 2021-11-24 LG Electronics Inc. Apparatus for transmitting broadcast signals and method for transmitting broadcast signals
US9852114B2 (en) 2014-06-18 2017-12-26 Vmware, Inc. HTML5 graph overlays for application topology
US9836284B2 (en) 2014-06-18 2017-12-05 Vmware, Inc. HTML5 graph layout for application topology
US9740792B2 (en) * 2014-06-18 2017-08-22 Vmware, Inc. Connection paths for application topology
WO2016076773A1 (en) * 2014-11-12 2016-05-19 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for negotiating session descriptor parameters
TW201931863A (zh) * 2018-01-12 2019-08-01 圓剛科技股份有限公司 多媒體訊號的同步設備及其同步方法
CN113170238B (zh) * 2018-09-12 2023-08-01 诺基亚技术有限公司 用于视频编码和解码的装置、方法和计算机程序

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6516435B1 (en) * 1997-06-04 2003-02-04 Kabushiki Kaisha Toshiba Code transmission scheme for communication system using error correcting codes
CA2510709A1 (en) 2002-12-18 2004-07-01 Nokia Corporation Method of announcing sessions
US7979886B2 (en) * 2003-10-17 2011-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Container format for multimedia presentations
SE0302778D0 (sv) 2003-10-17 2003-10-17 Ericsson Telefon Ab L M Container format for multimedia presentations
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
US20050216472A1 (en) * 2004-03-29 2005-09-29 David Leon Efficient multicast/broadcast distribution of formatted data
US7536622B2 (en) * 2004-03-29 2009-05-19 Nokia Corporation Data repair enhancements for multicast/broadcast data distribution
AU2005256977B2 (en) * 2004-06-25 2010-03-11 Nokia Corporation File delivery session handling
EP1760933B1 (en) * 2004-08-06 2012-03-14 Panasonic Corporation Feedback control for multicast or broadcast services
US20070192818A1 (en) * 2004-10-12 2007-08-16 Mikael Bourges-Sevenier System and method for creating, distributing, and executing rich multimedia applications
US20060193337A1 (en) * 2005-02-25 2006-08-31 Toni Paila Device management broadcast operation
CN101243675B (zh) * 2005-06-27 2016-05-11 核心无线许可有限公司 用于动态丰富媒体场景的传送机制
US20070186005A1 (en) * 2005-09-01 2007-08-09 Nokia Corporation Method to embedding SVG content into ISO base media file format for progressive downloading and streaming of rich media content

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101950427A (zh) * 2010-09-08 2011-01-19 东莞电子科技大学电子信息工程研究院 一种适用于移动终端的矢量线段轮廓化方法
WO2014079027A1 (en) * 2012-11-22 2014-05-30 Thomson Licensing Apparatus and method for extending tv services with rich media services

Also Published As

Publication number Publication date
ES2526814T3 (es) 2015-01-15
US20070180133A1 (en) 2007-08-02
EP1974526B1 (en) 2014-10-29
EP1974526A1 (en) 2008-10-01
WO2007080500A1 (en) 2007-07-19
CN105024852A (zh) 2015-11-04
EP1974526A4 (en) 2012-11-28
US7917644B2 (en) 2011-03-29
KR20080083353A (ko) 2008-09-17
CN105024852B (zh) 2020-01-03
EP2790380A1 (en) 2014-10-15
KR100959574B1 (ko) 2010-05-27

Similar Documents

Publication Publication Date Title
CN101390367A (zh) 针对移动广播/多播流式服务器的使用而扩展富媒体容器格式
KR100927978B1 (ko) 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법
US7746882B2 (en) Method and device for assembling forward error correction frames in multimedia streaming
CN105812377B (zh) 用于动态丰富媒体场景的传送机制
CN101359996B (zh) 媒体业务呈现方法及通讯系统以及相关设备
CN101627607A (zh) 用于执行对富媒体内容和服务的动态更新的基于脚本的系统
CN106134146A (zh) 处理连续的多周期内容
CN1748426B (zh) 在流系统中发送和接收字体信息的方法
KR20070067193A (ko) 디지털 통신 시스템들을 통한 보조 콘텐츠 핸들링
US20050276495A1 (en) Method of providing digital audio broadcasting (DAB) slide show including interactive information, apparatus for processing the same, and DAB receiver
Herpel et al. MPEG-4 Systems: Elementary stream management
CN102177484B (zh) 提供基于结构化富媒体数据的用户界面的装置和方法
Dufourd et al. An MPEG standard for rich media services
Allamandri et al. Service platform for converged interactive broadband broadcast and cellular wireless
CN101529885B (zh) 富媒体流管理
Lee et al. Converged mobile TV services supporting rich media in cellular and DVB-H systems
JP2011526440A (ja) 電子サービスガイド情報を生成し応用する方法及び端末
KR100919231B1 (ko) 리치미디어 서비스를 위한 실시간 데이터 연동방법 및 그리치미디어 장치
Ridgway Open hypermedia and temporal linking with audio streams

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
ASS Succession or assignment of patent right

Owner name: NOKIA 2011 PATENT TRUST CO.

Free format text: FORMER OWNER: NOKIA OY

Effective date: 20120409

C41 Transfer of patent application or patent right or utility model
C53 Correction of patent of invention or patent application
CB02 Change of applicant information

Address after: Delaware

Applicant after: 2011 Intellectual Property Asset Trust

Address before: Delaware

Applicant before: NOKIA 2011 patent trust

COR Change of bibliographic data

Free format text: CORRECT: APPLICANT; FROM: NOKIA 2011 PATENT TRUST CO. TO: 2011 INTELLECTUAL PROPERTY ASSET TRUST CO.

TA01 Transfer of patent application right

Effective date of registration: 20120409

Address after: Delaware

Applicant after: NOKIA 2011 patent trust

Address before: Espoo, Finland

Applicant before: NOKIA Corp.

ASS Succession or assignment of patent right

Owner name: CORE WIRELESS LICENSING S.A.R.L

Free format text: FORMER OWNER: 2011 INTELLECTUAL PROPERTY ASSET TRUST CORPORATION

Effective date: 20120509

C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20120509

Address after: Luxemburg Luxemburg

Applicant after: NOKIA Inc.

Address before: Delaware

Applicant before: 2011 Intellectual Property Asset Trust

C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20090318