专利名称：本地内容代替单播的数据流系统的制作方法
技术领域：
本发明涉及在如互联网的数据网上的流内容信息领域。本发明特别涉及但不是专门涉及“互联网广播”。
在如J.Alvear的“Q&A with Time Bratton，President ofTuneTo.com(与TuneTo.com的总裁Time Bratton的问答)”，流媒体新闻组，http//www.tuneto.com/company/news_snm991123.cfm中可以找到“互联网广播”的描述。“互联网广播”涉及在互联网上从服务器到听众的流数据内容。有时，为后面更快地播放数据可以预先下载到听众缓存中。但是，因为术语“互联网广播”一般用于本领域中，其将也用于这里。典型的互联网广播站的内容包括语音和音乐。语音可以是音乐节目主持人(DJ)或其他演播室聊天。
内容的实时流受如由RealNetworks公司生成的RealAudioTM程序的影响。这个流通常是高度压缩的数据内容，允许声音信号通过消费者家里的拨号连接接收。拨号典型地小于56k比特/秒带宽，这意味着相对“最初”的CD源材料(4 4.1k采样/秒×16比特/采样×2个信道)需要非常高的压缩比。
互联网“广播站”与传统“广播”站不同在于基于互联网的站不发送广播流。这意味着连接到站的每个人连接一个唯一的插口并且在UDP(用户数据报)、TCP(传输控制协议)，或RTP(实时传输协议)上发送独立的“流”。因此在服务器上的负载按访问站的听众的数量成比例增加。
而且大多数广播站在一天播放选定数量的曲目。这些曲目从通常按星期为基础而改变的“播放列表”中选择。这意味着在一些天里，许多内容是重复的。
一般，互联网广播在发送之前压缩。这可以导致不是最佳声音质量的有损耗的发送。
本发明的一个目的是减少内容流需要的带宽，并且改进流内容用户的体验质量。因为用高质量的本地内容替换较低质量的单播(unicast)，所以在实现这些目的。
有利的，在发送机里生成至少第一个内容流以及至少一个描述符来实现这些目的。发送机发送第一种或第二种类型的传输数据。第一种类型的传输数据包括第一个以及至少第二个内容流以及描述符。例如缺省地或者响应于指示缺少对应第二种数据流的用户存储内容的第一种类型用户响应而发送第一种类型的传输数据。第二种类型的传输数据包括第一个内容流以及描述符。响应于指示存在对应第二种数据流的用户存储内容的第二种类型用户响应而发送第二种类型的传输数据。
现在，超过一万个广播站在互联网上广播。通过互联网听音乐已经成为流行的娱乐。通过到消费者家里的拨号连接的音频信号实时流要求相对于CD源材料非常高的压缩比。典型的，广播内容包括点缀着主持人独白的音乐。广播在互联网上流动，其中每个用户得到一个唯一的插口并且发送单独的数据流。结果，服务器上的负载正比于用户数。大多数广播节目从按星期为基础改变的播放列表中选择曲目。也就是，在几天里大部分内容是重复的。发明者假设播放设备是一个用于例如，记录在以前下载的或CD上存在的记录的音乐内容的存储器，因此仅需要发送音乐的识别符。该设备向站发送其在播放本地拷贝或替代物，因此服务器只需要流播放主持人的声音。应用于整个听众的基础上这导致每个用户的带宽大量减少。音乐可以头天晚上陆续到达用户的存储设备上来随着时间扩展带宽需求并且在典型的流行时间段中优化使用。优选的，两个单独信道用于主持人的声音以及音乐内容以避免缓存DJ谈论的音乐。
下列合并在这里供参考-1999年7月1日Mark Hoffberg等人提出的美国序号09/345,339(律师案卷号PHA23,700)CONTENT-DRIVEN SPEECH-OR AUDIO-BROWSER(内容驱动的语音或音频浏览器)。这个文档涉及用于基于其典型内容分类互联网上提供音频(例如语音和音乐)流的万维网站点或资源的方法。提供音频流的万维网资源由其资源类型识别。资源类型利用指示文件格式，如“.ram”、“.tsp”或“.swa”的其URL中的类型扩展名来确定。这个扩展能够，例如在点击超级连接时在用户浏览器中自动打开正确的软件应用程序(或“插件程序”)。因此，可以基于其URL识别互联网上的相关资源。如果通过URL文件扩展名不可用，则由资源的HTTP头中提供的MIME类型或内容类型信息确定资源类型。考虑资源的国家域扩展名，例如对于荷兰是“.nl”或对于俄罗斯是“.ru”，可以进一步优化URL的分析，例如如果一个人对特定国家语言的音频内容感兴趣。一找到相应的资源，也就是提供音频流的地方，就从相应服务器取回资源的文件并且基于其音频内容进行分析。可以使用语音识别或音乐(音调/节奏)识别软件来搜索并且按例如，语言、音乐风格、非商业等分类这些站。语音识别软件能够确定不同种类音乐的调号，因此能够通过这种软件进行音乐分类。例如，古典音乐典型地有不同于摇滚音乐的声音识别调号。服务器可专用于分类数据库中的站或频道，类似PlanetSearch或Altavista为文本文档所做的。可以并行使用一个或多个万维网爬行者来自动获取提供音频的万维网站点以便使搜索引擎识别它们。除此之外，可以由爬行者评估资源的服务器的连接质量，例如连接速度，可靠性等。例如，分类服务器会向具有宽带接入(例如ISDB、电缆、T1)的用户推荐更高连接速度的资源。类似于PlanetSearch的或Alta vista的为文本的，提供音频浏览器来基于特定的音频搜索标准哪些特殊页面返回用户来提供互联网音频万维网站点的可搜索集合。替代的，可以利用分类方法(Yahoo专长于精选并且将站点指定到分类中)来在服务器处分类站并且使其通过搜索引擎可访问。一旦站点被分类，用户向服务器提供询问输入并且接收表示与询问输入(例如，给我一个播放类似音乐的法语站)相匹配的频道的URL列表。作为替代或支持这一点，服务器基于存储在服务器上的用户描述文件，例如利用飞利浦电子的SmartConnect基础架构为用户提供定制电子节目指导。
-Mark Hoffberg提出的美国专利5,963,957(律师案卷号PHA23,241)“BIBLIOGRAPHIC MUSIC DATA BASE WITH NORMALIZED MUSICALTHEMES(基于标准音乐主旋律的目录音乐数据)。这个专利文档特别讨论了音乐主旋律的节奏信息或音调信息如何可以用来识别主旋律。节奏信息包括时间调号(节拍)以及主旋律的加重。时间调号确定到小节的拍子的数量。重音确定哪些拍子得到重音以及哪些不得到。例如，在音乐乐谱中符号68是指示节拍到小节是6个拍子并且第八个音符得到一个拍子。弗拉门科民歌音乐有各种不同的风格，每个由其康巴斯(compàs)(节奏的重音模式)确定。典型的弗拉门科民歌音乐的例子是阿格历亚斯(Alegrias)、布鲁历亚斯(Bulerìas)、辛格历亚斯(Siguiriyas)和索拉历亚斯(Soleares)，都有12个拍子到小节。在阿格历亚斯、布鲁历亚斯和索拉历亚斯中，第三、第六、第八、第十和第十二个拍子是重音。在辛格历亚斯风格中强调第一、第三、第五、第八和第十一个拍子。在这个系统中节奏重音模式用做输入数据以便取回与由节奏表示的主题相关的目录信息。例如，节奏重音模式作为基本单调的重音和非重音声音的序列输入系统。然后由，例如在时间域里变化高度的拍子或最高点的序列表示输入数据。连续的最高点之间的相对距离表示模式的时间方面并且相对高度表示模式的重音。中间的拍子和休止符的顺序由数字字表示。字可以按字典顺序存储以便快速并且顺序检索。如果音调信息和/或节奏信息可用于识别单个音乐主旋律，则其也可以用于或多或少准确地识别特定风格的音乐。
-1999年11月4日由Eugene Shteyn提出的美国序号09/433,257(律师案卷号PHA 23,782)PARTITIONING OF MP3 CONTENT FILE FOREMULATING STREAMING(用于模仿流的MP3内容文件分区)。这个文档涉及将电子内容文件分成多个部分。每个部分或者段需要一个相对短的下载时间。因此，播放等待时间由第一部分的下载时间决定。单个部分的大小由通信带宽，例如通过用于等待时间检查的是否可达(pinging)来决定。客户设备/应用接收关于内容的控制信息。这个控制信息包括，例如，关于整个文件的大小和存储器位置以及其在服务器上各部分的信息。如果客户端不能够处理分离的数据，其按传统方法继续，也就是下载整个文件并且然后将其播放。在客户端能够处理部分内容的情况下，其使用关于各部分的相应控制信息以便在播放的同时继续下载数据。数据播放，也称为“表演”，是计算密集的，因为其需要多个解码操作。数据下载是带宽密集的。因此，同时播放和下载不显著地竞争相同的系统资源。下载和处理之间的这种分离可以有效地用于多处理和/或多线程环境中。
其他的目的和优点在下面将变得显而易见。现在本发明将参考下列附图利用无限制的例子进行描述。
图1是显示听众到互联网广播提供者的连接的示意图。
图2a显示用于捕获演播室增加的内容的设备。
图2b显示用于组织适合本发明的音乐符号的设备。
图3显示用于将来自互联网广播站的内容发送到互联网上的设备。
图4显示在接收位置用于处理根据图3生成的信号的设备。
图5显示描述图4的框403的操作的流程图。
图6a、6b、和6c显示本发明使用的数据格式。
图7a显示根据本发明适合于用于视频和音频数据的听众设备。
图7b显示根据本发明适合于用于视频和音频数据的发送机设备。
一般，通过这个描述，如果一项描述为用软件实现，其可以同等地用硬件实现。
图1是互联网广播站的示意图。在101显示音频内容的创建。该站可以是一个传统的广播站，其额外地在互联网上提供广播，或者其可以仅是互联网站。内容以数字和压缩格式发送到万维网服务器102。万维网服务器管理来自听众的请求并且通过为其提供到站内容的连接来响应。这个内容是字节的连续流，以固定速率(平均)提供数据并且允许来自站的内容传达给听众。这个字节流通常称为“流”。并且术语“流媒体”用于描述以这种方式通过互联网发送的内容。
从万维网服务器102，提供多个数据的传输流1...N通过通信链路103到互联网104。连接可以是任何合适的类型，如T1、T3、光纤等。这些的每个有不同的潜在吞吐量，但是在所有情况下该吞吐量有一个上限。传输流1...N的带宽必须满足条件 换句话说，各个流的带宽之和必须小于链路103的整个带宽。这个整个带宽限制了数据的传输流的数量。因此，如果各个传输流的带宽可以减少，则流的数量就可以增加。
万维网服务器102将传输流发送到听众的互联网地址，每个听众得到相应的流。术语“单播”这里用于指示为每个听众提供一个单独的连接，与“组播”或“广播”相反，其分别指示消息从一个节点发送到许多点，或一个节点到所有点。组播和广播消息一般不在互联网上使用，因为路由这些消息有问题。
然后互联网服务提供商104将传输流1...N分离到各个听众站点105，也可以认为是收发信机。这里术语“听众”和“用户”指接收内容的设备，而不是收听的实际的人。
广播站101和设备102以及105的每个至少有一个本地存储器，106、107、108...109。本地存储器106-109可用于存储内容或软件。软件可以有许多目的，包括本发明的各个方面的实现。
虽然这里本发明是关于互联网广播进行描述的，其等价地适用于其他的流媒体系统，如视频系统，其也可以使用来自自动唱片点唱机的本地内容。在视频域内容的一个合适本地源的例子是基于硬盘的录音机，如飞利浦Tivo HDD产品。
发送设备图2a和2b显示用于提供适合本发明使用的内容的广播站的配置。
在图2a中生成演播室内容。一般这是DJ对麦克风201说的，虽然也可以同等地捕获其他演播室声音。替代的，记录的声音，如声音效果，可等价地获得或合并作为演播室声音的一部分。在202，演播室声音被数字化并且然后在203压缩。然后压缩的数字化信号在线头A处可用。在线头A处可用的格式典型地是Real Media格式或WindowsMedia格式，这是在互联网上用于发送来自广播站的内容的流行流格式。但是，技术人员可以发明任何合适的格式。
图2b显示与音乐源204相关的电路。这个音乐源204典型地是广泛商业化可用的一些产品，如商业CD或磁带。在205如果需要音乐被数字化。数字化并不总是必须的—并且因此显示为一个虚框—因为许多音乐记录，例如CD的，已经数字化。在206音乐被压缩。
在现有技术中，组合的演播室和音乐内容已经一起压缩，而根据本发明他们要单独压缩。在线头B提供压缩的、数字化的音乐。除此之外，在207生成音乐以及对本发明有用的额外的信息，如状态信息的标记并且在线头C提供。
“音乐标记&状态信息”是关于音乐源204的信息内容的元信息。在CD的情况下，这将是包括“CD ID”的识别符。ID是从播放的磁盘获得(或利用其生成的)，如互联网上存在的CDDB分类所做的(参见http//cddb.org或http//www.techtv.com/callforhelp/projects/jump/0，3652，2189035，00.html中的描述)。除了CD ID，优选的使用来自磁盘的曲目号提供播放歌曲的唯一标识符。其他状态信息包括-曲目流逝的时间(因此本地播放可以同步并且由代替流内容)；以及-播放速度改变信息(给出站稍微改变音乐的播放速度的灵活性，有助于混合其他内容或使歌曲符合可用的时间，等)。
在音乐由不是CD的源提供的情况下，然后站通常创建自己的识别符标记。然后典型地需要在对这个站唯一的标记和CD识别符之间区分。内容的这后一种分类，例如可以是新闻报告，访谈、音乐人的“演播室会话”或甚至是商业广告。通过标记内容，可能指示远程听众的设备第一次接收到内容时进行缓存。然后，在下面的几个小时、几天或几月里，内容不需要从该站流到这个特定的设备。
在A、B和C提供的三个信号作为三个组件发送到万维网服务器。图3显示来自和去往万维网服务器的设备供给信号。而多路复用器单元显示为独立于万维网服务器，并且也独立于图2a&b的组件，实际上图2和3中所有的项目都共同存在于服务器上，也许除了实际的麦克风和互联网本身。类似的，各种组件作为技术人员的设计选择，可合并成单个处理器的功能。
多路复用器或其他合适的控制器301取得来自图2a和2b的电路的输出的信号A(DJ内容)和C(标记)以及可选的B(音乐内容)以便生成单个的传输数据流“流1”。可利用如MPEG4的协议发送组合流的不同组件。是否包括B依赖于来自听众的提供给控制消息分发器304的控制信号。
调度程序303可以用取得多个组件(任意类型)并且将其“多路复用”成单一字节流的软件实现。三个组件被标记，因此可以在远端“去多路复用”。这可以根据MPEG4标准或由技术人员发明的任何其他类似方法完成。
一共N个多路复用器301...302，生成N个数据流。这可以由单独的模块，或执行N个合并处理的单个处理器实现。
对于每个数据流N，输入A、B和C可以相同。替代的，演播室可以为不同的听众混合更多的定制数据流。例如，可能有超过一个DJ，每个有独特的风格，或甚至不同的音乐选择。
多路复用器301...302还接收通过万维网服务器102中的控制消息分发器304传递的控制信号。这个控制信号来自用户并且典型地指示输入B是否可以忽略，如果听众有当前播放音乐的本地拷贝。控制消息分发器按如下这样做-从由听众发送到服务器的消息中提取命令和听众识别符。
-选择创建听众正在接收的流的多路复用器。
-向该多路复用器发送命令，控制该多路复用器正在复用的流。
在仅有音频的节目的情况下，有效的命令是“发送流A+C”和“发送流A+B+C”。
来自多路复用器301...302的流(流1...流N)传递给万维网服务器102的调度程序部分303。调度程序303有将流格式化为用于在305通过互联网发送的合适格式的任务。典型的这需要-加入目的地的IP(互联网协议)地址，-将流放在TCP或UDP分组的有效负荷中，-处理发送确认，-检查链路丢失，以及-使需要发送给不同听众的不同流多路复用和负载均衡。
在http//apache.org处可以找到适合于执行这些功能的服务器的例子。Apache万维网服务器是基于NCSA http万维网服务器的公共域万维网服务器。其从已有的NCSA代码加上各种补丁发展而来。称为补丁的服务器，因此得名Apache服务器。
除此之外万维网服务器的控制消息分发器304需要处理从听众处回来的其他请求306，如请求在数据流中丢弃或增加(B)信道，或启动或停止流。然后万维网服务器利用标准协议，如活动服务器技术、servlet接口或CGI接口将这些命令传递给多路复用器软件元件。
听众设备图4显示组成听众105的组件，听众有两个主要部分1)接收流内容并且转换回模拟信号所需的功能413，以及2)实现音频自动唱片点唱机所需的功能406。
这两部分的独立的现有技术产品有用于流内容接收的RealNetworks公司的Real PlayerTM；以及提供自动唱片点唱机功能的RealNetworks公司的Real JukeboxTM。
框406显示安排在流媒体播放器里以便实现本发明的音频自动唱片点唱机中存在的功能。音频自动唱片点唱机的功能406也适合于在由流媒体播放器，例如，通过本地网络或专有总线控制的另一个单独设备(或程序)中。一般，优选地在两个产品之间创建连接，而不是在流媒体播放器中复制自动唱片点唱机的功能并且需要音乐分类和曲目索引从已有的自动唱片点唱机导入流媒体播放器中。
在Windows环境里，众所周知一个应用可以通过称为COM(组件对象模型)的机制暴露其功能用于包含在另一个里。类似的功能在其他平台上可用，并且通过使用如SOAP(简单对象访问协议)、Java Beans和CORBA(通用对象请求代理结构)的技术真正跨平台。在消费电子领域，可能只依赖于HAVi提供自动唱片点唱机和流设备之间的连接。HAVi利用上载的java代码从设备到设备，来将一个设备的功能暴露给另一个。
有利的，自动唱片点唱机功能是可编程的以便拒绝记录流媒体的内容。例如，如果互联网广播站寻找记录广告材料用于用户以后播放，则用户可能想要拒绝接受在自动唱片点唱机存储器中占用不必要空间的这样的记录。而且，来自站的内容的质量一般没有用户所有的内容的质量高，并且用户可能不想在自动唱片点唱机中记录低质量的内容。
在自动唱片点唱机中涉及其他功能，没有在这张图中显示以便不使图变得模糊—例如，将数字数据转换回模拟音频的框，或者用于实现自动唱片点唱机的用户接口的硬件/软件。
在现有技术中，流接收机和音频自动唱片点唱机流行地主要作为PC上的软件组件。但是，两者也可以作为单独的硬件，如传统的消费电子设备。在两种情况下可能两个单独的产品一起使用来实现本发明，或两个产品组合成一个新产品。再次组合的产品可以是运行在处理器上的软件应用程序或者其可以是单独的硬件，如更传统的消费电子设备。
IP链路软件401是连接这个设备和互联网的标准的组件，因此数据流可以在IP网上接收。可能包括如调制解调器、PPP(点到点)链路等。允许发送请求以便允许设备连接到站并且允许对三个信号组件(A)、(B)和(C)的多路复用的控制，如图2和3所述。
去多路复用器或demux402取得包含三个组件(A)、(B)和(C)的来自互联网的内容流，加上关于如何将其从流中分离的细节。合适在这里使用的关于多路复用方案的文章可以在下面找到http//www.cselt.it/ufv/leonardo/paper/isce96.htm#Multiplexing_and_Synchronization_of_AVOs，关于这个主题的进一步信息可以在http//mpeg.org找到。
在图5的流程图中进一步描述控制软件403。在框501，软件从流中获取元信息(如对图2的详细描述)来寻找当前哪个音乐在被流处理。在502，利用自动唱片点唱机406里的目录408将识别符与自动唱片点唱机发存储器407的内容相比较，看这个以及类似的音乐是否已经本地存储。
如果流处理的音乐或者可接受的替代物已经本地存储，则控制软件按如下做-在503，通过互联网，利用IP链路软件401将信号发送回万维网服务器。这指示服务器102停止向听众发送流里的音乐(B)(如图3中所述)；-在504，指示听众的混合器411选择引用的输入输入1和输入3；以及-在505，指示自动唱片点唱机模块406利用状态信息(在图3的描述中提到)正确地用本地拷贝代替流拷贝来开始播放合适的内容。
如果流处理的音乐或合适的替代物(例如，基于风格或表演的演员)当前没有本地存储，则控制软件有选项来启动自动唱片点唱机模块记录流。在506是否这样做的决定基于在流本身中发送的元信息，也就是，站有选项请求听众存储当前内容。但是，这不是全部在流设备的控制中，因为自动唱片点唱机不是必须在流接收机的控制下。如果自动唱片点唱机是独立于流接收机的单独产品，则可能不存在这样的控制。类似地消费者可配置自动唱片点唱机来拒绝到流接收机的存储访问。但是，如果这个站没有请求自动唱片点唱机中存储器的能力，则控制软件按如下做-在507，指示自动唱片点唱机模块406开始记录当前内容；-在508，在自动唱片点唱机406的目录408中插入内容的识别符(与内容在元数据中发送)使得内容能够在后面的某个时候被检索；以及-指示混合器411使用引用的输入输入1和输入2。
解压缩器404和405接收压缩的数字流并且将其解压缩。听众需要这些元件中的两个，一个用于DJ流(A)并且一个用于音乐(B)。
混合器411从站中取得流，输入1和输入2并且从本地自动唱片点唱机中取得输入3。然后混合器将信号组合成一个数字音频流，准备好在412转换回模拟音频。混合器如上所述，有能力在控制软件403的控制下使音乐的合适源渐显或渐弱。混合器是通用组件。混合或者在数字或模拟域完成并且简单地包括到混合器的每个数字输入的值加在一起，来创建单一的数字信号。在英特尔AC-97芯片结构中可找到硬件混合器的一个例子，参见通常在PC中找到的http//developer.intel.com/ial/scalableplatforms/audio。
数模转换器412是标准类型，并且将数字信号转换回模拟信号。为了提供足够的功率放大来驱动扬声器以便用户可以听站发送的内容，大概需要增加一个未示出的功率放大级。
图6A和6B显示由框207提供的数据的数据格式，其中域定义为如下表所指示。虽然这里描述了特定的数据格式，本领域的普通技术人员可能发明本发明可用的任意数量的替代数据格式。
图6a的格式，格式1，包括识别当前流播放的音乐的所有需要的域。这个较长的分组每秒应该发送一次或两次。图6b的分组格式，格式2，小得多并且仅包括时间戳信息，允许听众将其本地播放与流内容同步，以便考虑听众处的无缝转变。这个较短的分组应该每十分之一秒或五分之一秒被重复发送。在这种情况下流看上去象图6C，其包括对于格式1的每个实例的格式2的几个实例。通过一秒仅发送一次或两次较大的分组，C信道的带宽需要可以保持很低。
视频实现虽然在互联网广播和音频内容方面已经表达了详细描述，但是其等价地适用于如视频的其他类型的内容。
图7b显示类似于图3的发送机，根据本发明其中音频和视频数据都存在。在这种情况下，有五个数据流A、B、C、D和E。流A和B，与前面一样，分别对应于预先记录的音频内容和演播室音频内容。流D和E分别对应于预先记录的视频内容和演播室视频内容。流C再次对应于描述符数据，其被做必要的格式化以便使听众能够确定是否用本地数据替换视频数据的预先记录部分。五个流A、B、C、D和E单独压缩，并且然后由多路复用器710-711合并。如以前，对每个听众必须有单独的多路复用器，考虑图的简洁只显示了两个。调度程序713确定数据到互联网的显示顺序。控制消息分发器714分发来自听众的是否需要流A和/或D，或者是否可用本地内容替换一个或另一个或两者的指示。
图7a显示类似于图4的用于视频情况的听众设备。由图7b的设备生成的流到达IP链路软件701，进而提供给去多路复用器702。然后恢复单独压缩的流A、B、D和E并且提供给解压缩器706，其向混合器704和705提供未压缩的版本。混合器704和705在控制软件703的控制下选择流A和D或来自自动唱片点唱机功能707的本地内容。显然这里有多个可能的置换。
-所有流A、B、D和E可能存在并且结果所有内容可来自互联网。
-流B、D和E可能存在。在这种情况下，本地存储的音频内容可以与来自互联网的演播室音频内容B混合以便在708提供音频输出，其中实际音频由人类用户生成。在这种情况下，所有的视频内容将来自互联网，并且在709提供给人类用户，其中为用户生成实际视频。
-流A、B和E可能存在。在这种情况下，所有的音频内容将来自互联网，但是有些视频内容本地提供。
-只有B和E存在，在这种情况下有些视频和有些音频内容本地提供。
通过阅读本发明，对于本领域的技术人员修改是显而易见的。例如，识别某个流内容的标记可以多少在流内容之前发送，以便如果本地存储，使用户的设备能够识别并且检索匹配的内容。例如，可以使用电子节目向导(EPG)方法实现这一点。但是，典型的，在上述DJ或演播室聊天例子中，一方面的音乐内容和另一方面的演播室或商业广告交替。发送与演播室聊天流一起的内容描述符给予用户的本地网络时间来决定是否要播放本地存储的内容。这样的修改涉及在互联网广播和内容流的设计、制造和使用中已知的其他特性并且可用于代替或附加到这里已经描述的特性。虽然在这个申请中权利要求已经阐明为特性的特定组合，应该理解本申请公开内容的范围也包括明确的或隐含的在这里公开的任何新颖的特性或新颖的特性组合或任何广义性，无论是否其如本发明所做的减轻了任何或全部的相同技术问题。因此申请人提醒注意在本申请或源于此的任何进一步申请的进行期间对这些特性可以阐明新的权利要求。
在这里使用的词“包含”、“包括”不应该被看作排除额外的元件。这里使用的单数的词“一个”不应该被看作排除多个元件。
权利要求
1.一种用于通过数据网向终端用户的接收机提供传输数据流的系统，所述系统有-适合于生成第一个内容流(图2，在项目A)的第一个生成器；-访问数据用于生成第二个内容流(图2，在项目B)；-适合于为第二个内容流生成描述符的第二个生成器(207)；-多路复用器，其适合于响应于接收机指示存在在接收机本地存储并且对应第二个内容流的内容，而发送包括第一个内容流、第二个内容流及描述符的第一种类型传输数据流，或者其中不存在第二个内容流并且包括第一个内容流和描述符的第二种传输数据流。
2.用于处理通过数据网由发送机流发送的内容数据的接收机，所述接收机包括-适合于接收和/或发送数据的数据通道；-适合于执行下列操作的处理单元；-在数据通道检测进入的传输数据流；-从传输流中分离出至少第一个内容流和控制数据；-在控制数据的控制下，或者将第一个内容流与来自传输数据流的至少第二个内容流混合，或者将第一个内容流与来自接收机本地的源的内容流混合；以及-为数据通道提供适合于使发送机提供合适的传输内容流的指示。
3.如权利要求2的接收机，其中处理单元还适合于执行下列操作在控制数据的控制下，记录至少第一个和第二个内容流的至少一部分以便后来用作本地内容流。
4.如权利要求2的接收机，其中处理单元适合于记录控制数据。
5.如权利要求2的接收机，其中控制数据包括记录识别符、播放速度指示器以及流逝的时间信息。
6.一种传输内容流，包括-包括至少一部分想要单播的内容流；以及-适合于使用户能够将内容流与本地存储的数据混合以便重新生成想要的单播的控制数据。
7.如权利要求6的传输内容流，其中控制数据还适合于使用户能够记录用于后来播放的部分，这种记录基本上与当前播放同时进行。
8.如权利要求7的传输内容流，其中控制数据包括记录识别符、播放速度以及流逝的时间信息。
9.一种用于提供传输内容流的方法包括-生成至少一个第一内容流；-生成至少一个描述符；-响应用户输入，发送以下内容中的一个-响应第一种类型的用户输入指示缺少对应于至少一个第二个数据流的用户存储的内容，包括第一个流以及至少一个第二个流及描述符的第一种类型的传输数据流；以及-响应第二种类型的用户输入指示存在对应于至少一个第二个流的用户存储的内容，包括第一个流和描述符的第二种类型的传输数据流。
10.如权利要求9的方法，其中描述符包括用于使用户能够重新生成包括第一个内容流和用户存储内容的合并的单播的控制数据。
11.如权利要求10的方法，其中控制数据包括记录识别符、播放速度和流逝的时间信息。
12.如权利要求9的方法，其中描述符包括用于指示用户记录至少第一个和/或第二个流的一部分用于在用户播放该部分的同时在用户设备中本地缓存的控制数据。
13.如权利要求9的方法，其中同时提供多个传输内容流，根据用户需求所述传输内容流中的至少两个在内容方面不同。
14.一种用于处理流内容的方法，包括-在数据通道检测传输数据流；-从传输流中分离至少第一个内容流和控制数据；-在控制数据的控制下，或者将第一个内容流与来自传输数据流的至少一个第二个内容流混合用于播放，或者将第一个内容流与本地内容流混合用于播放；-为数据通道提供适合于使发送机提供合适的传输内容流的本地内容指示。
15.一种通过数据网使客户端能够处理内容的方法，所述方法包括-确定客户端是否有本地可用的内容的第一部分；-发送包括内容的另一部分和控制数据的传输流，其中控制数据使客户端能够将第一部分和另一部分混合。
全文摘要
通过用本地存储的内容代替单播内容可以节省互联网广播传输中的带宽。本地存储的内容与来自互联网广播站的演播室内容混合。内容流中的控制数据指示听众的客户端使用本地内容与演播室内容。可以由本地内容替换的演播室内容、记录内容以及控制数据在发送之前单独压缩。本地存储的内容可由自动唱片点唱机模块或本地网络中的另一个源提供。发送和接收技术适合于包括视频的任何类型的流媒体。
文档编号H04H20/82GK1462535SQ02801329
公开日2003年12月17日 申请日期2002年2月13日 优先权日2001年2月21日
发明者R·B·萨加尔 申请人:皇家菲利浦电子有限公司