CN103004229A - 数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置 - Google Patents

数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置 Download PDF

Info

Publication number
CN103004229A
CN103004229A CN2011800354532A CN201180035453A CN103004229A CN 103004229 A CN103004229 A CN 103004229A CN 2011800354532 A CN2011800354532 A CN 2011800354532A CN 201180035453 A CN201180035453 A CN 201180035453A CN 103004229 A CN103004229 A CN 103004229A
Authority
CN
China
Prior art keywords
data
content
dispensing
delivered
client
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
CN2011800354532A
Other languages
English (en)
Inventor
渡部秀一
高桥真毅
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.)
Sharp Corp
Original Assignee
Sharp Corp
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 Sharp Corp filed Critical Sharp Corp
Publication of CN103004229A publication Critical patent/CN103004229A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • 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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • 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/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • 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/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting

Abstract

本发明提供一种数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置，在以利用多部分MIME格式的HTTP来对内容数据进行配送的数据配送系统中，服务器侧代理根据同一请求的产生频度等，使用广播路径和通信路径来进行相适应的片段分割配送。客户端侧代理中，在收到通信路径的响应消息之后，对被配送的、来自通信路径的数据和来自广播路径的数据的信息(路径识别、同步信息)进行相适应的合并处理。

Description

数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置
技术领域
本发明涉及多媒体数据配送技术，更具体而言，涉及对适合于利用数据传输协议的通信、广播协同配送的、高效的多媒体数据配送进行实现的数据配送系统及数据配送方法。
背景技术
近年来，对以动态图像的内容、实时的视频、音频为代表的多媒体数据配送的需求正在提高。互联网上提供的超文本系统即World Wide Web(也简称为Web)正被广泛利用来作为对这些多媒体数据(文本、静态图像、动态图像等)进行配送的方法。World Wide Web是基于客户端服务器模型的系统。当客户端、即用户终端在World Wide Web上获取网页等资源时，利用网页来从World Wide Web服务器中获取多媒体数据。此时，使用HTTP(HyperText Transfer Protocol：超文本传输协议)来作为用来进行文件传输的协议。而对于能够简便地使用该HTTP对视频进行利用的机制的要求也在提高，并探讨了各种配送方式。
这里，首先对HTTP进行简单的说明。HTTP是用于在客户端与内容服务器之间进行多媒体数据传输的协议。利用HTTP的数据的交换格式的基本结构为：“报头部”+“划分(空行)”+“数据部”。报头部中描述了与数据的内容有关的信息、控制信息。数据部中描述了数据主体。
当内容服务器中有想要获取的内容数据时，客户端利用HTTP从客户端向内容服务器发送消息。在对内容数据进行要求的请求消息中，基本上没有“数据部”，因此发送“报头部”和表示报头部的终止的“划分(空行)”。当内容服务器中接受到来自客户端的内容要求的请求时，通过接收到的“报头部”所指定的信息来提取被请求的页面信息，并将“数据部”中储存了提取出的页面信息的响应消息(“报头部”+“划分(空行)”+“数据部”)配送给客户端。
接着对利用HTTP配送的数据结构进行说明。图29是用于对现有的包含片段视频格式的MP4文件格式的数据结构进行说明的图。片段(fragment)是将内容数据分割成规定长度后整理成可配送格式的单位数据。以片段单位来对数据进行处理，从而使得数据的筛选、分离、合成较为容易。构成MP4文件的片段包括：起始部分的片段2901，该片段2901包含moov报头，该moov报头对用于进行视频重放的整体信息(初始化信息等)进行储存；以及除此之外剩下的片段2902，该片段2902包含moof报头，该moof报头对用于对各片段内的数据进行重放的信息进行储存。另外，一个片段包括一个报头和与该报头相对应的媒体数据部的mdat。一个MP4文件包括一个以上的片段。
专利文献1中记载了使用MPEG的ISO Base Media File Format的片段视频格式(Fragmented Movie)的配送方式。在片段视频格式中，将与整个动态图像有关的数据、和与按照某种基准分割得到的分割动态图像数据相对应的元数据描述在文件的起始部分，之后对与元数据对应的分割动态图像数据进行记录。这里，所谓元数据，并非指分割动态图像数据自身，而是指与分割动态图像数据相关联的信息，例如包含在数据中的视频的数量、动态图像大小、编码方式、比特率、数据位置、时间标记等。下面同样地，按照时间序列依次对分割动态图像数据的元数据、和所对应的分割动态图像数据进行记录。通过将一个分割动态图像数据与其元数据的组合作为一个块来进行处理，能够预先得知数据大小，因此也能够灵活运用在HTTP等文件传输的协议中。在该专利文献1中，为了减轻配送侧的处理负担、通信网络的通信量等，当从网络摄像机向多个重放装置配送视频时，采用在两者之间配置了代理的系统结构，并经由该代理，将从网络摄像机向各重放装置进行配送的视频信号的主数据相同的数据作为单独数据配送给客户端。
此外，还讨论了使用传输频带被始终确保的卫星广播的传输路径来将高画质、高音质的内容同时配送给多个观众的高速下载的服务。将通信中使用的IP包格式的文件数据载入到广播波中并进行下载广播的方式也逐渐被开始采用，例如，ARIB STD-B45“高级宽带卫星数字广播中的下载方式”(非专利文献1)已被标准化并公开。该标准是以广播和通信进行协同为前提制定而成的标准，规定为如下混合型的方式：使用广播传输路径来对需求较高的内容进行同时配送，并使用通信传输路径对单独请求的内容(许可等)进行单独配送。
现有技术文献
专利文献
专利文献1：日本公开专利公报“特开2007-173987号公报(2007年7月5日公开)”
非专利文献
非专利文献1：“高级宽带卫星数字广播中的下载方式”，[online]，无线工业及商贸联合会，平成22年4月26日，ARIB STD-B45，[平城22年7月8日检索]，<URL:HTTP://www.arib.or.jp/english/html/overview/doc/2-STD-B45v1_0.pdf>(“高度広帯域衛星デジタル放送におけるダウンロード方式”、[online]、社団法人電波産業会、平成22年4月26日、ARIB STD-B45、[平成22年7月8日検索]、インターネット<URL:HTTP://www.arib.or.jp/english/html/overview/doc/2-STD-B45v1_0.pdf>)
发明内容
发明所要解决的技术问题
然而，若仅仅是像上述专利文献1那样利用现有的通信对内容数据进行同时配送的方式，在抑制通信网络通信量的增大这方面会有局限性，尤其在对实时视频进行配送等情况下会成为问题。对于多个观众从各自的TV终端(客户端)同时向广播站侧的内容服务器发出对同一内容数据的收视要求等情况，由于内容服务器会分别向使用者配送同一内容数据，因此会遗留如下问题：通信网络的通信量会急剧增大，通信速度会变得极其缓慢。
此外，以上述非专利文献1为代表，建立了以广播和通信进行协同为前提、利用广播对内容数据进行同时配送的配送方式，但配送方式本身在广播和通信之间是独立的。即，并没有用于对分别从通信路径和广播路径接收到的数据进行协同、同步的机制，也无法对例如从两者接收到的数据进行组合并作为一个内容来进行处理等。
为解决上述问题，现提出本发明，其目的在于提供一种数据配送系统及数据配送方法，当从内容服务器侧的代理向客户端侧的代理配送数据时，对通信路径和广播路径进行相适应的利用来分散同时配送时的负担，由此来抑制通信网络的通信量。
解决技术问题所采用的技术方案
本发明所涉及的数据配送系统包括：数据配送装置，该数据配送装置通过规定的格式，以媒体段单位对多个内容数据进行配送；配送侧数据中继装置，该配送侧数据中继装置与所述数据配送装置、通信网络和广播网络相连接，经由所述广播网络和所述通信网络中的至少任意一个网络，对由所述数据配送装置配送的所述内容数据进行配送；接收侧数据中继装置，该接收侧数据中继装置与所述通信网络和所述广播网络相连接，将由所述配送侧数据中继装置配送的所述内容数据配送给接收终端装置；以及接收终端装置，该接收终端装置能够对由所述接收侧数据中继装置配送的所述内容数据进行接收，其特征在于，所述配送侧数据中继装置根据来自接收终端装置的数据要求，来对所述广播网络和所述通信网络进行相适应的分割配送。
本发明所涉及的数据配送方法包括：数据配送步骤，在该数据配送步骤中，通过规定的格式，以媒体段单位对多个内容数据进行配送；配送侧数据中继步骤，在该配送侧数据中继步骤中，经由广播网络及通信网络中的至少任意一个网络，对通过所述数据配送步骤配送的所述内容数据进行配送；接收侧数据中继步骤，在该接收侧数据中继步骤中，对通过所述配送侧数据中继步骤从所述通信网络及所述广播网络配送的所述内容数据进行配送；以及接收步骤，在该接收步骤中，对通过所述接收侧数据中继步骤配送的所述内容数据进行接收，其特征在于，在所述配送侧数据中继步骤中，根据数据要求，来对所述广播网络和所述通信网络进行相适应的分割配送。
本发明所涉及的配送侧数据中继装置是在经由网络将内容从数据配送装置配送到接收终端装置的数据配送系统中、从所述数据配送装置接收所述接收终端装置所要求的内容并将其配送给所述接收终端装置的配送侧数据中继装置，其特征在于，包括：第一发送单元，该第一发送单元利用第一配送路径对所述内容进行配送；第二配送单元，该第二配送单元利用与所述第一配送路径不同的第二配送路径对所述内容进行配送；以及选择单元，该选择单元选择使用所述第一发送单元及所述第二发送单元中的哪一个发送单元来对所述接收终端装置所要求的所述内容进行配送。
根据上述结构，当选择单元将接收终端装置所要求的内容配送给接收终端装置时，能够选择第一发送单元或第二发送单元中的某一个。由此，能够对两个发送单元进行相适应的选择来发送内容。
本发明所涉及的接收侧数据中继装置是在经由网络将内容从数据配送装置配送到接收终端装置的数据配送系统中、对所配送的所述内容进行接收并将其发送给所述接收终端装置的配送侧数据中继装置，其特征在于，包括：第一接收单元，该第一接收单元对利用第一配送路径配送的所述内容进行接收；第二接收单元，该第二接收单元通过与所述第一配送路径不同的第二配送路径，对以不同于所述第一配送路径的发送数据格式配送的所述内容进行接收；以及格式统一单元，该格式统一单元对无论利用所述第一接收单元及所述第二接收单元中的哪一个接收单元所接收到的内容，都以相同的发送数据格式向所述接收终端装置进行发送。
根据上述结构，格式统一单元将使用不同的通信路径并以不同的发送数据格式配送的内容生成为相同的发送数据格式，并将其发送给接收终端装置。由此，接收终端装置不会得知该内容是使用哪种路径、以哪种发送数据格式来进行配送，并能对该内容进行利用。
发明效果
在本发明所涉及的数据配送系统及数据配送方法中，当从内容服务器侧的代理向客户端侧的代理配送数据时，能够对通信路径和广播路径进行相适应的利用来分散同时配送时的负担，并能抑制通信网络的通信量。
本发明的其它目的、特征以及优点可以通过以下所示的记载来充分了解。此外，本发明的优点应该可以从参照附图的以下说明中清楚地获知。
附图说明
图1是表示本发明实施方式1所涉及的数据配送系统的整体结构的系统结构图。
图2是本发明实施方式1所涉及的客户端侧和服务器侧的代理的功能框图。
图3是用于对本发明实施方式1所涉及的媒体段进行说明的图。
图4是用于对本发明实施方式1所涉及的多部分格式进行说明的图。
图5是用于对本发明实施方式1所涉及的、服务器中有最初的内容要求的请求时的响应路径切换处理进行说明的序列图。
图6是用于对本发明实施方式1所涉及的、服务器中有最初的内容要求的请求时的响应路径切换处理时所收发的HTTP消息进行说明的图。
图7是用于对本发明实施方式1所涉及的、在已有内容要求的请求时、在内容要求频度较低的情况下的响应路径切换处理进行说明的序列图。
图8是用于对本发明实施方式1所涉及的、在已有内容要求的请求时、在内容要求频度较低的情况下进行响应路径切换处理时所收发的HTTP消息进行说明的图。
图9是用于对本发明实施方式1所涉及的、在已有内容要求的请求时、在内容要求频度较高的情况下的响应路径切换处理进行说明的序列图。
图10是用于对本发明实施方式1所涉及的、在已有内容要求的请求时、在内容要求频度较高的情况下进行响应路径切换处理时所收发的HTTP消息进行说明的图。
图11是用于对本发明实施方式1所涉及的从广播路径进行配送的响应进行说明的图。
图12是用于对本发明实施方式1所涉及的用于进行广播路径的使用者确认的HTTP消息进行说明的图。
图13是用于对本发明实施方式1所涉及的、已在利用广播路径进行配送的过程中切换到其它内容的切换处理进行说明的序列图。
图14是用于对在本发明实施方式2所涉及的、在将广播配送的开始时刻定为可使用时刻的情况下的处理进行说明的序列图。
图15是用于对在本发明实施方式2所涉及的、在将广播配送的开始时刻定为可使用时刻的情况下进行处理时所收发的HTTP消息进行说明的图。
图16是用于对在本发明实施方式2所涉及的、在将广播配送的开始时刻定为可使用时刻的情况下进行处理时所收发的HTTP消息进行说明的图。
图17是用于对在本发明实施方式2所涉及的、在将广播配送的结束时刻定为可使用时刻的情况的处理进行说明的序列图。
图18是用于对在本发明实施方式2所涉及的、用于将广播配送的结束时刻定为可使用时刻来进行通知的消息进行说明的图。
图19是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下的处理进行说明的序列图。
图20是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所收发的HTTP消息进行说明的图。
图21是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所收发的HTTP消息进行说明的图。
图22是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所收发的HTTP消息进行说明的图。
图23是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时从广播路径配送的响应进行说明的图。
图24是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所收发的HTTP消息进行说明的图。
图25是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行合成处理后所配送的HTTP消息进行说明的图。
图26是本发明实施方式4所涉及的、在客户端侧代理与多个客户端相连的情况下的功能框图。
图27是表示本实施方式5所涉及的、使用了移动设备的无线接入通信网络的数据配送系统的整体结构的系统结构图。
图28是用于对本发明实施方式5所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所收发的HTTP消息进行说明的图。
图29是对现有的包含片段视频格式的MP4文件格式的数据结构进行说明的图。
具体实施方式
以下根据表示本发明实施方式的附图对本发明进行详细叙述。
[实施方式1]
本发明的实施方式1对如下示例进行说明：使用HTTP的协议来进行客户端和内容服务器之间的通信，并使用由多部分MIME格式的HTTP消息对片段化的内容数据进行配送的系统，通过广播网络和通信网络的协同来进行内容数据的配送。
图1是表示本发明实施方式1所涉及的数据配送系统的整体结构的系统结构图。本发明的数据配送系统是客户端服务器型的系统，包括：多个客户端(接收终端装置)101(101-1～n)；与各个客户端相连接并接受来自客户端的请求的客户端侧的代理(接收侧数据中继装置)102(102-1～n)；对来自各个客户端侧的多个代理102(102-1～n)的内容要求的请求进行代理应答的代理(配送侧数据中继装置)103；以及与代理103相连接、对多个内容进行管理、并对来自客户端并经由代理的请求进行应答的内容服务器(数据配送装置)104。在本发明的数据配送系统中，可以选择性的使用通信路径(通信网络，第二配送路径)和广播路径(广播网络，第一配送路径)两者来作为配送路径。
服务器侧的代理103根据通信路径的状况，来决定使用通信路径和广播路径中的哪一条路径来进行配送，并且具备切换通信路径的功能。
另外，客户端侧的多个代理102(102-1～n)具备如下功能：根据内容服务器侧的代理103所指示的配送路径，来接收各个配送数据，并通过广播网络和通信网络两者的协同，将被配送的内容数据作为一个内容数据配送给客户端。
有关本数据配送系统，典型的是，假设服务器104和代理103相当于广播站，客户端101和代理102相当于电视接收机。客户端侧代理102可以如图中虚线那样内置于电视接收机中，也可以作为与电视接收机独立的外部设备来准备。例如，当今接收数字广播的大多数电视接收机都具备在接受广播的同时接受通信的接口。即，具备广播的接收部和通信的接收部。可以容易地假设出上述电视接收机中内置有代理。对于将客户端侧代理内置于电视接收机的情况，客户端和与客户端相连的客户端侧代理一一对应。当然，对于客户端侧代理是外部设备的情况，一个客户端侧代理可以与多个客户端相连。
然而，由于在本发明的实施方式1中，主要对客户端侧代理102与服务器侧代理103之间的数据、消息的收发进行说明，因此若无特别说明，以与客户端侧代理102相连的客户端101为单个的情况进行说明。系统中存在多个包括被图中虚线所包围的客户端101、代理102的电视接收机(101-1～n，102-1～n)。
另外图1中内容服务器104只连接了一台代理103，但也可以采用服务器侧具有多个代理的结构。例如，可以在每个进行配送的广播网络的广播站中准备代理，也可以根据服务器中所存放的内容的类别分别进行准备。此外，也可以使代理103与多个内容服务器104相连接。
图2是对本发明实施方式1所涉及的数据配送系统中客户端侧代理102、服务器侧代理103两者的内部功能结构的一个例子进行图示的功能框图。
客户端侧代理102包括：从客户端101处接收请求的接收部201；将消息发送给服务器侧代理的发送部202；通过通信路径对来自服务器侧代理的请求进行接收的接收部(第二接收单元)203；通过广播路径对来自服务器侧代理的请求进行接收的接收部(第一接收单元)204；对来自通信路径的响应消息进行解释、接收来自通信路径、广播路径的各个消息数据、并对消息进行合成的处理部(格式统一单元)205；处理部205对消息数据进行缓存的缓存部206；以及向客户端配送响应消息的发送部207。另外，消息的合成是用来统一成相同数据格式、使得无论是通过广播路径及通信路径中的哪一个路径所接收到的数据、都能够在客户端中进行相同处置的处理。这里，不对通过通信路径接收到的消息(多部分MIME格式的消息)进行合成而将其直接传输到客户端，并将通过广播路径(IP数据播送)接收到的数据合成为多部分MIME格式的消息。由此，无论使用哪一种通信路径，客户端接收到的都是多部分MIME格式的消息。
服务器侧代理103包括：从客户端侧代理接收请求的接收部301；向服务器104发送消息的发送部302；对接收到的请求进行监视的监视部303；对来自服务器104的请求进行接收的接收部304；接受来自监视部303的通知、对接收部304的响应消息进行分解、并面向通信路径、广播路径对数据格式进行整理、并根据路径对响应消息进行分配的处理部305(选择单元)；处理部305对来自服务器104的响应进行缓存的缓存部306；将由处理部305整理成面向通信路径的数据格式的响应信息配送给通信路径的发送部(第二发送单元)307；以及将由处理部305整理成面向广播路径的数据格式的响应信息配送给广播路径的发送部(第一发送单元)308。
图3是用于说明本发明实施方式1所涉及的媒体段(Media segment)的图。将一个HTTP消息中所存放的片段的组定义为媒体段。在服务器侧代理103与客户端侧代理102之间，以媒体段的单位来进行消息的收发。本发明中，为了对内容数据进行处理，将如图29中所描述的片段的数据结构作为基本结构。图3中，将内容划分为规定长度的片段，将内容的起始设为fragment0，其后用fragment1、……、fragment(N-1)、fragmentN、……、fragment(2N-1)、fragment(2N)、……等来表示。图3中所描述的内容(content)的最初的媒体段(content/0)包括从fragment0到fragment(N-1)的N个片段。内容的第二个媒体段(content/1)包括从fragmentN到fragment(2N-1)的N个片段。以下同样地，到内容的最后一个数据为止，媒体段同样包括N个片段。
当最后一个媒体段所对应的片段数量不足N个时，插入与不足的量相对应的虚拟用的片段。或者，也可以仅将最后一个媒体段设为只有有效的片段数量。由于在内容的起始片段：fragment0中也带有内容整体长度的信息，因此能够由该值来计算出最后一个媒体段所包含的片段的数量。
图4是用于对从本发明实施方式1所涉及的数据配送系统中所使用的客户端发送的请求、和来自经由内容服务器侧的代理103来进行配送的内容服务器104的多部分格式的响应进行说明的图。
图4(a)表示从客户端发送的请求的HTTP消息的一个例子。这是使用“GET”命令来描述HTTP消息的请求的例子，该命令向服务器要求“content1”的内容中的第“0”个媒体段的数据。此外，所使用的通信协议为“HTTP”的“1.1”版本。“Accept”的请求报头字段用于指定响应中可接受的媒体类型。这里，用响应来请求MP4文件格式的视频信号：“video/mp4”、或者多部分MIME格式的媒体段：“multipart/media-segment”。
图4(b)表示了由采用多部分MIME格式的HTTP响应消息来记载一个媒体段时的一个例子，一个媒体段包括10个片段。401是HTTP响应消息的“报头部”。接下来的空行是“划分”，接着所记载的是“数据部”。“数据部”为了使代理内的HTTP响应消息的分解、合成容易进行，将内容片段的二进制数据部分编码为MIME(Multipurpose Internet Mail Extensions：多用途互联网邮件扩充)格式的数据，并以多部分格式记载在HTTP的消息中，并将其用作HTTP响应消息。本发明的说明中所使用的多部分格式是指在一个HTTP消息的“数据部”中、对由报头部的“boundary=”所指定的字符串“BOUNDARY”所划分的多个部分数据、在本实施方式中为片段进行记载的HTTP消息的格式。402-1的部分是第一个片段。402-2的部分是第二个片段，连续进行记载直到402-10的第十个片段，从而构成一个媒体段的HTTP响应消息。另外，图4(b)的例子中将一个片段的时间长度设为1秒，将1个媒体段的时间长度设为10秒。下文的实施方式的附图及说明以此为基础来进行。但实际上，片段的长度、媒体段的长度可以任意设定。
图5是用于对本发明实施方式1所涉及的数据配送系统中、在服务器中有最初的内容要求的请求时的响应路径切换处理进行说明的序列图。在S501(S表示“步骤”，以下相同)中，当内容服务器104中有想看的内容时，客户端101向内容服务器104发送内容要求的请求。从客户端101发出的请求通过通信路径经由客户端侧代理102，从客户端侧代理102发送至进行内容服务器的代理处理的服务器侧代理103(S502)。当服务器侧代理103的接收部301接收到请求时，在监视部303中进行如下确认：是否已接收过相同请求，所对应的响应是否已缓存在缓存306中，即，过去有无接收过。此外，确认对相同内容的要求频度(S503)。
要求的频率是对在规定时间内发送来多少请求相同内容的要求进行测量的标准，规定频度=次数/时间。在本实施方式中，假设相同请求集中在同一时间段内，且目的在于在这种状况下对广播路径进行有效利用并进行最合适的内容配送，因此对要求的频率进行利用。即，在本实施方式中，当检测到产生了通信网络的通信量较大时所产生的、要求频度较高这一现象时，选择利用广播路径进行配送。由此，能抑制通信网络的通信量并实现高效的内容配送。另外，进行检测的现象可以是通信网络的通信量较大时所产生的现象，但不限于此例。例如，在利用通信路径对片段进行配送后，在收到对下片一段的请求之前的期间比通常情况要长的情况下，认为通信网络的通信量较大，因此也可以对该期间超过规定阈值的情况进行检测。
图5中，由于尚未接收到对相同内容的请求，因此服务器侧代理103的处理部305接受到来自监视部303的要求频度的通知：“要求频度低(无)”，并通过发送部302将接收部301中所接收到的、来自客户端101的请求发送给内容服务器104(S504)。
内容服务器104将与来自客户端101的请求相对应的、包含多部分MIME格式的内容数据的响应返回至服务器侧代理103(S505)。此时，由于相同内容的要求频率不高，因此服务器侧代理103的处理部305选择利用通信路径对响应进行配送而非广播路径。用接收部304接收到来自内容服务器104的响应的服务器侧代理103的处理部305通过发送部(通信路径)307并利用通信路径来将该响应返回至客户端侧代理102(S506)。客户端侧代理102将接收到的响应返回至客户端101(S507)。客户端101对内容进行重放(S508)。客户端101对下一个内容数据进行请求(S509)。
图6是用于对图5的序列图所示的本发明实施方式1所涉及的数据配送系统的动作中、服务器中有最初的内容要求的请求时的响应路径切换处理时所收发的HTTP消息进行说明的图。
图6(a)的M501(M表示“HTTP消息”，以下相同)表示从图5的S501的客户端101使用通信路径向内容服务器104进行发送的HTTP请求消息的一个例子。该请求消息M501是图5中从客户端101经由客户端侧代理102及服务器侧代理103发送给内容服务器104的HTTP请求消息，且在各个设备之间、通信S501、S502、S504中发送相同的M501。
图6(b)的M505表示从图5的内容服务器104使用通信路径向客户端101进行配送的多部分MIME格式的HTTP响应消息的一个例子。该响应消息是图5中从内容服务器104经由服务器侧代理103及客户端侧代理102配送给客户端101的HTTP响应消息，在各个设备间的通信S505、S506、S507中发送相同的M505。
图6(c)的M509表示从图5的客户端101使用通信路径向内容服务器104进行发送的第二个媒体段的HTTP响应消息的一个例子。虽然图5中仅描述了从客户端101向客户端侧代理102配送请求的S509，但该请求也和S501同样，是从客户端101经由客户端侧代理102及服务器侧代理103发送给内容服务器104的HTTP请求消息，且是在各个设备间进行发送的请求消息。
图7是用于对本发明实施方式1所涉及的数据配送系统中、在已有内容要求的请求时、在内容要求频度较低的情况下的响应路径切换处理进行说明的序列图。表示在已从其它客户端接收了相同内容要求的请求、且来自多个客户端的同一内容要求的频度不高的状况下所进行的处理。
从客户端101向内容服务器104发送内容要求的请求。将内容要求的请求首先从客户端101发送给客户端侧代理102(S701)。将客户端侧代理102所接收到的内容要求的请求从客户端侧代理102发送给服务器侧代理103(S702)。服务器侧代理103的接收部301对经由客户端侧代理102发送来的、来自客户端101的内容要求的请求进行接收。接收到所述请求后，服务器侧代理103的监视部303确认如下内容：是否已接收过相同请求，所对应的响应是否已缓存在缓存306中，即，过去有无接收过。此外，确认对相同内容的要求频度(S703)。
图7中的状态为：内容服务器104中已有来自其它客户端的内容要求的请求，且服务器侧代理103已对最初的内容要求返回了响应。也就是对应于同一内容要求的响应已存放在缓存306中的状态。并且，假设确认出同一内容要求的频度较低。
服务器侧代理103的处理部305接受到来自监视部303的要求频度的通知：“要求频度较低”，并选择通信路径对响应进行配送而非广播路径。由于缓存306中已经存放了相对应的响应，因此服务器侧代理103的处理部305不对内容服务器104发送请求，而从缓存部306中提取已缓存的响应，并通过发送部(通信路径)307，经由客户端侧代理102，将响应配送给客户端101(S704、S705)。客户端101接收到多部分MIME格式的HTTP响应消息后，提取内容数据，并对内容即视频进行重放(S706)。接着，客户端101经由客户端侧代理102向内容服务器104配送下一个媒体段的请求(S707)。
图8是用于对图7的序列图所示的本发明实施方式1所涉及的数据配送系统的动作中、在已有内容要求的请求时、在内容要求频度较低的情况下进行响应路径切换处理时所收发的HTTP消息进行说明的序列图。
图8(a)的M701表示从图7的客户端101使用通信路径向内容服务器104进行发送的HTTP请求消息的一个例子。如图7所示，该请求最终没有被发送给内容服务器104。该请求消息是从图7的客户端101经由客户端侧代理102发送给服务器侧代理103的HTTP请求消息，在各个设备间的S701、S702中发送相同的请求M701。
图8(b)的M704表示从图7的服务器侧代理103使用通信路径向客户端101进行配送的多部分MIME格式的HTTP响应消息的一个例子。该响应消息是已从图7的内容服务器104接受了来自其它客户端的请求并将其向服务器侧代理103配送过一次的响应消息，且服务器侧代理103已将该响应保存在缓存306中。当服务器侧代理103接收到来自客户端101的同一内容要求时，将代替内容服务器104进行代理应答，经由客户端侧代理102将保存在缓存306中的响应配送给发送了内容要求的请求的客户端101。对于该HTTP响应消息，在各个设备间的S704、S705中配送相同的M704。
图8(c)的M707表示从图7的客户端101使用通信路径向内容服务器104进行发送的第二个媒体段的HTTP响应消息的一个例子。该请求最终也没有被发送给内容服务器104。虽然图7中仅描述了从客户端101向客户端侧代理102发送请求的S707，但该请求也和S701同样，是从客户端101经由客户端侧代理102发送给服务器侧代理103的HTTP请求消息。
图9是用于对在本发明实施方式1所涉及的数据通信系统中、在已有内容要求的请求时、在内容要求频度较高的情况下的响应路径切换处理进行说明的图。表示已从其它客户端接收了相同内容要求的请求、且来自多个客户端的同一内容要求的频度较高的状况下的处理。
内容要求的请求从客户端101被发送给内容服务器104。如图9所示，该请求最终没有被发送给内容服务器104。内容要求的请求首先从客户端101配送给客户端侧代理102(S901)。客户端侧代理102所接收到的内容要求的请求从客户端侧代理102被发送给服务器侧代理103(S902)。当服务器侧代理103的接收部301接收到经由客户端侧代理102发送来的、来自客户端101的内容要求的请求时，在监视部303中进行如下确认：是否已接收过相同请求(即，所对应的响应是否已缓存在缓存306中)，即，过去有无进行过接收。此外，确认对相同内容的要求的频度(S903)。
假设已接收到多个相同的请求，且，接收S902的请求导致要求频度超过了规定的阈值。即，这里预先对要求频度的阈值进行设定，并通过将该阈值与当前频度进行比较来判断要求频度的高低。此时，由于与请求对应的响应消息已缓存在缓存部306中，因此不向内容服务器104发送请求。而且，服务器侧代理103的处理部305接受到来自监视部303的要求频度的通知：“要求频度较高”，不仅选择通信路径，也选择广播路径来对响应进行配送，并执行以下处理。
首先，在服务器侧代理103的处理部305中，对如下内容进行确认：是否已在利用广播路径对与接收到的请求相对应的响应进行配送的过程中(S904)。若不在进行配送的过程中，则对广播路径进行确认和确保，并开始利用广播路径对接着响应S906之后的内容数据进行配送。若已在进行配送的过程中，则对该广播路径进行确认。另外，由于通过对使用状况进行监视来判断是否终止利用广播路径的配送，因此不一定要与要求频度的变动同步。因此，需要确认是否已在利用广播路径进行配送的过程中(S904)。使用状况的监视将在后文中阐述。
接着，由于与来自客户端101的请求相对应的响应已保存在缓存306中，因此服务器侧代理103的处理部305不向内容服务器104发出请求，而从缓存306中提取已缓存的响应。然后，由服务器侧代理103的处理部305向所提取出的响应附加根据来自监视部303的要求频度的通知而选择的路径信息。这里，由于“要求频度较高”而选择了广播路径，处理部305在与请求相对应的响应消息的报头中附加表示S904中所确认或确保的广播路径的、以下的广播路径的信息(S905)。
X-Alternative-Path：broadcast-ipdatacast
X-Broadcast-Channel：1
X-Ipdatacast-Address：200.1.1.1
具体的响应消息的例子如后文图10(b)所示。处理器305将表示利用广播路径来进行发送的信息(X-Alternative-Path：broadcast-ipdatacast)与在上述S904中所确认或确保的广播路径的信息、即、用于对发送数据的广播路径进行识别的信息(X-Broadcast-Channel：1)、以及用于在该广播路径内对数据进行识别的信息(X-Ipdatacast-Address：200.1.1.1)一起附加到HTTP的响应消息的报头部分。通信路径的发送部307使用通信路径将报头附加有广播路径信息的响应配送给客户端侧代理102(S906)。
上述表示广播路径的信息的例子表示了利用IP数据播送来进行的广播配送的例子。如后文所述，是对包含多部分化后的内容数据的响应消息进行IP分组化、并将其作为目的地址200.1.1.1来配送给信道1的例子。客户端侧代理102利用目的地址对IP包进行识别。也可以将信道信息替换成直接指定频带的信息。另外，这些广播配送所利用的信道和IP地址可以在服务器侧代理103中预先进行设定，也可以由服务器侧代理103掌握各个信道的空闲信息等，并在每次配送时决定。此外，当客户端的终端是可移动的移动设备时，可以使用移动设备所搭载的位置信息通知功能(Geolocation API等)来获取客户端终端的当前位置，并由服务器侧代理103来决定最适合于客户端当前位置的广播路径、信道、IP地址。
此外，虽然图中没有表示，但也可以使用数字广播的数据广播所使用的数据轮播方式来对包含内容数据的响应消息进行广播配送。对于这种情况，报头中所追加的信息的例子如下所示。
X-Alternative-Path：broadcast-datacarrousel
X-Broadcast-Channel：1
X-Dataevent-Id：200
这是将包含多部分化后的内容数据的响应消息封装成轮播源，并将其作为事件ID200配送给信道1的例子。客户端侧代理102以事件ID对轮播源进行识别。
当客户端侧代理102的处理部205从服务器侧代理103接收到附加了路径信息的响应消息时，将S905中所附加的报头从响应消息中删除。客户端侧代理102的处理部205将删除了路径信息的响应发送给客户端101(S907)。
客户端101接收到多部分MIME格式的HTTP响应消息后，提取内容数据，并对内容即视频进行重放(S908)。
此外，客户端侧代理102的处理部205参照S905中所附加的报头的信息，然后，识别并获取利用广播路径而传输来的数据(S910)。识别过程中利用了各IP包中所附加的IP数据播送地址(目的地址)。另外，虽然图中没有表示，但由于广播配送中不需要进行路径(routing)处理，因此，对于起始以外的IP包的报头，也可以用表示是与起始包相同的报头的情况的标识符来替换(该处理降低了报头的数据量)，并利用该标识符来对IP包进行识别。然后，客户端侧代理102的处理部205将接收到的数据合成为多部分格式的响应消息(S911)。
另外，此时，在经由广播来进行配送的响应消息中附加以下内容并进行发送：表示在利用前需要在服务器侧代理103中进行验证的信息(Cache-Control：proxy-revalidate)、以及验证所使用的识别标签信息(ETag：“abcde”)。具体的响应消息的例子如后文图11所示。(另外，这里，为便于说明，服务器侧代理103中的处理中首次出现了识别标签信息ETag，但ETag原本是内容服务器104对各个消息所附加的标签信息。因此，虽然没有在本实施方式的各图中示出，但可以认为在从内容服务器104配送的响应消息中分别预先附加了ETag。此外，对于未附加ETag的情况，也可以由服务器侧代理103来附加独有的标签、例如X-proxy-ETag。由于附加了该表示需要进行验证的信息，客户端侧代理102为了对合成后的响应S911是否有效进行验证，必定会向服务器侧代理103发送验证请求(S912)。对于验证请求，服务器侧代理103根据请求消息中所记载的识别标签信息来确认响应S911是否有效，当确认有效时，将表示有效的响应配送给客户端侧代理102(S914)。与此同时，服务器侧代理103通过对该验证请求的接收状态进行监视，来判断利用广播路径进行发送的内容数据在客户端中被利用到何种程度。此外，若没有收到验证请求，则判断为没有客户端在接收利用广播路径进行发送的内容，并终止利用广播路径的配送。另外，可以根据例如在预先设定的期间内、未接收到验证请求的状态是否持续，来判断是否是未收到验证请求的状况。
客户端101向客户端侧代理102发送与内容服务器104相对的下一个媒体段的请求(S909)，并接受相对应的响应(S915)，对内容进行重放(S916)。此时，如图9所示，对于客户端侧代理102中的动作，仅将通过广播路径收到的响应返回至客户端101，客户端101的请求不会被发送给服务器侧代理103及内容服务器104。此外，S909中所配送的请求不一定要与S910～S914的处理同步，也可以在返回与S909的请求相对的响应S915之前完成S910～S914的处理。
图10至图12是用于对图9的序列图所示的本发明实施方式1所涉及的数据配送系统的动作中、在已有内容要求的请求时、在内容要求频度较高的情况下进行响应路径切换处理时所收发的HTTP消息及广播路径上的配送数据进行说明的图。
图10(a)的M901表示在图9的S901中从客户端101使用通信路径向内容服务器104进行发送的HTTP请求消息的一个例子。如图9所示，该请求没有被发送给内容服务器104。该请求消息是从图9的客户端101经由客户端侧代理102发送给服务器侧代理103的HTTP请求消息，并且在各个设备间的S901、S902中发送相同的请求M901。
图10(b)的M906表示在图9的S906中从服务器侧代理103使用通信路径向客户端侧代理102进行配送的多部分MIME格式的HTTP响应消息的一个例子。该响应消息中，除表示广播路径的报头部信息以外的响应消息是根据来自其它客户端的请求、从图9的内容服务器104向服务器侧代理103配送过一次的响应消息，服务器侧代理103将该响应保存在缓存306中。服务器侧代理103在接收到来自客户端101的同一内容要求时，将代替内容服务器104来进行代理应答，并将保存在缓存306中的响应配送给请求了内容的、客户端101的客户端侧代理102。而且此时，处理部305通过S903的要求频度的确认来从监视部303接受内容的要求频度较高这一通知，选择播放路径，并在S905中将表示上述播放路径的路径信息附加到响应消息M906的报头部分中。
图10(c)的M907表示在图9的S907中从客户端侧代理102使用通信路径向客户端101进行配送的多部分MIME格式的HTTP响应消息的一个例子。该响应消息是当客户端侧代理102接收到S906中从图9的服务器侧代理103配送来的、附加了路径信息的响应消息时、在处理部205中将S905中所附加的所有路径信息删除、并重新生成的响应消息。
图11是用于对在图9的序列图所示的本发明实施方式1所涉及的数据配送系统的动作中、利用广播路径进行配送的响应的数据格式进行说明的图。在图9的S910中，对多部分MIME格式的HTTP响应消息进行IP分组化，由此生成数据M910，利用IP数据播送来进行广播配送。图11表示要配送的HTTP消息与IP分组化所形成的广播配送数据M910之间的关系。IP包包括储存了IP数据播送地址的报头部分和对想要传输的数据主体进行储存的净荷数据。净荷数据中将要求了响应消息的、原先的请求消息所指定的URI即请求数据URI、要配送的HTTP响应消息的报头部的数据、以及消息的数据部的各个片段的数据分别划分为一个或多个IP包来进行储存。片段数据储存的数据量与媒体段对应。此外，在每个片段数据中划分出IP包来进行储存，从而具有以下优点：即使在广播配送过程中失去了一部分数据，但只要对与所失去的数据相对应的片段数据以外的数据进行复原，就能对内容进行重放。
而且，如上所述，在该要配送的HTTP响应消息中，包括表示在利用前需要在服务器侧代理103中进行验证的信息(Cache-Control：proxy-revalidate)、以及验证所使用的识别标签信息(ETag：“abcde”)。
图12也同样是用于对在图9的序列图所示的本发明实施方式1所涉及的数据配送系统的动作中所收发的HTTP消息进行说明的图。特别地，图12(a)、(b)表示为了对利用广播路径进行发送的数据进行使用者确认而使用的HTTP消息的例子。
图12(a)的M912表示为了验证图9的S911中所合成的响应是否有效、在S912中使用通信路径从客户端侧代理102向服务器侧代理103进行发送的、用于验证的HTTP请求消息的一个例子。在该例中，以询问服务器侧代理103中是否有附加了与ETag“abcde”相同识别标签信息的响应消息的形式来进行验证。(若有相同的响应消息，则确认为客户端侧服务器102中的响应消息是从服务器侧代理103中得到的，即，判断为有效)
图12(b)的M914是图9的表示S912的验证请求的验证结果的S914的响应，表示使用通信路径从服务器侧代理103向客户端侧代理102进行发送的HTTP响应消息的一个例子。在该例中，示出了在服务器侧代理103中具有相同的响应消息的情况。
图12(c)的M915是与图9的S909相对的S915的响应，表示从客户端侧代理102向客户端101进行配送的多部分MIME格式的响应消息的一个例子。
如上所述，在本实施方式的数据配送系统中，利用要求频度来对内容的配送路径进行相适应的切换，由此，如果能判断为要求少到不会压迫通信频带，则利用通信路径来高速地发送内容数据，如果是要求多到会压迫通信频带的状况，则经由广播来对内容进行同时配送。由此，能够实现兼顾了内容的传输速度和通信频带的状态两者的、最合适的内容配送。
接着，利用图13对本发明实施方式1所涉及的数据配送系统中、将接收到的内容切换为已在利用广播路径进行配送过程中的其它内容时的处理进行说明。
图13是用于对本发明实施方式1所涉及的数据配送系统中、将接收内容切换为已在利用广播路径进行配送过程中的其它内容时的切换处理(切换时刻)进行说明的序列图。
客户端101请求对所配送的内容进行切换。具体而言，在SD01、SD02中，发送将图9的M901的“/content1/0”变更为“/content2/0”后的请求。(即，客户端要将所接收的内容从内容1切换到内容2。)这里，与图9的说明同样地，在SD03中对新要求的内容2的要求频度进行确认，且确认的结果是，判断为要求频度较高，在SD04中对内容2是否已在利用广播路径进行配送过程中进行确认，且在本实施方式中假设已在进行配送，在SD05中，将表示SD04中所确认的已在进行配送过程中的广播路径的信息附加到响应的报头，并经由SD06、SD07，将(包含“/content2/0”的片段的)多部分格式的响应消息返回至客户端101。
这里，与图9的说明同样地，客户端侧代理102可以切换为利用广播路径来接收配送数据，但利用广播路径的配送存在数据接收以及对接收数据进行重放非常耗时的问题。例如，在获取通过广播路径来进行配送的数据的过程中，从依次流过的数据中找出起始的数据可能会消耗很多时间。此外，还存在如下等问题：例如，对于进行与重放时间对应的实时数据的配送等利用广播路径的情况，即使客户端为了解码开始时的初始缓冲提早要求起始数据，也无法仅对起始数据进行高速的接收。因此，在本实施方式1的图13中，在对所接收的内容进行切换时，客户端侧代理102对开始解码所需要的那部分数据量进行判断，即使已利用广播路径对数据进行配送，也会利用通信路径重复执行SD08～SD11的步骤从而接收解码开始所需要的那部分数据。对图13的SD08～SD11的处理重复规定的次数，从而通过通信路径高速地传输起始数据，因此能降低客户端在切换接收(重放，收视)内容时的数据等待,客户端101能够快速地开始重放。
通过如上所述的实施方式1的结构，利用通信对要求较少的内容进行高速的数据配送，并且经由广播来对具有多个要求的内容进行同时配送，从而抑制通信网络的通信量的增大。此外，在对内容进行切换时，仅对于起始数据经由通信来进行高速传输，由此来减少内容切换时的等待。本发明以利用HTTP的通信为基础，从客户端来看像是正在进行利用HTTP的一对一通信。
[实施方式2]
本发明的实施方式2对如下示例进行说明：使用HTTP的协议来进行客户端与内容服务器之间的通信，在利用格式化成多部分MIME格式的HTTP消息对片段化的内容数据进行配送的系统中，在经由广播网络进行配送时，向客户端通知广播配送的配送时刻。与实施方式1同样地，参照图1、图2的系统结构图、功能模块图，来对本实施方式所涉及的数据配送系统的整体结构以及代理内部的功能模块结构进行说明。
图14是用于对在本发明实施方式2所涉及的数据配送系统中、将广播配送的开始时刻定为可使用时刻(可开始重放时刻)情况下的处理进行说明的序列图。
当内容服务器104中有想看的内容时，客户端101向内容服务器104配送内容要求的请求(SE01)。从客户端101发出的请求通过通信路径并经由客户端侧代理102，从客户端侧代理102传输至对内容服务器进行代理处理的服务器侧代理103(SE02)。当服务器侧代理103的接收部301接收到请求时，在监视部303中对是否已接收过相同请求进行确认，图14中，由于尚未接收过对同一内容的请求，因此服务器侧代理103的处理部305利用发送部302将接收部301所接收到的、来自客户端101的请求发送给内容服务器104(SE03)。
内容服务器104将与来自客户端101的请求相对应的、包含多部分MIME格式的内容数据(媒体段)的响应返回至服务器侧代理103(SE04)。服务器侧代理103的处理部305选择规定时刻下的、利用广播路径的响应配送，而非通信路径，并向来自内容服务器104的响应附加所配送的路径信息和时刻信息(配送开始时刻、配送结束时刻)，并将其发送给客户端侧代理102(SE06)。客户端侧代理102从接收到的响应中提取出时刻信息，并利用响应消息来对客户端101进行可使用时刻的通知(SE07)。服务器侧代理103在SE06中对最初的媒体段的数据进行配送后，向内容服务器104请求下一个媒体段的数据(SE08)。内容服务器104用多部分MIME格式的HTTP响应消息来发送对SE08的响应(SE09)。之后，服务器侧代理103在接收完一个内容数据之前，反复执行SE08、SE09的步骤。
在利用SE07的响应而接受到可使用时刻的通知后，客户端101在经过所指定的可使用时刻后，再次向客户端侧代理102发送请求(SE10)。
图14是将利用广播路径的内容数据的配送开始时间指定为可利用时刻的例子。即，在客户端侧代理102中，当经过可使用时刻后，利用广播路径另行对储存有内容数据片段的响应消息进行接收、合成，并开始向客户端101返回响应消息。
若过了配送的开始时刻，则客户端侧代理102对利用广播路径传输来的媒体段数据进行识别，并依次进行获取。识别过程中利用了后面叙述的各IP包中所附加的IP数据播送地址。然后，将接收到的数据合成为多部分MIME格式的HTTP响应消息(SE15)。
此时，在经由广播来进行配送的响应消息中附加以下内容并进行发送：表示在利用前需要在服务器侧代理103中进行验证的信息、以及验证所使用的识别标签信息。在图11及实施方式1中的验证处理的说明中已对此进行了详细的说明。由此，客户端侧代理102向服务器侧代理103发送用于对合成后的响应SE15是否有效进行验证的请求(SE16)，且服务器侧代理103向客户端侧代理102返回表示有效的响应(SE18)。通过上述验证处理，服务器侧代理103能够对利用广播路径来发送的内容数据是否正在被客户端所利用进行监视，并能用于终止配送的判断等。然而，在本实施方式中，由于预先指定了配送结束时刻，因此该监视的处理不是必须的。
客户端侧代理102用多部分MIME格式的HTTP响应消息将利用通信路径的SE06中向客户端101进行配送的最初的媒体段数据作为对SE10的响应来进行配送(SE11)。客户端101利用所接收到的SE11的响应来提取内容数据(片段的数据)，并开始对内容、即视频进行重放(SE12)。之后，客户端101向内容服务器104请求下一个媒体段数据(SE13)。
由于客户端代理102从上述过了配送开始时刻的时刻起一直在另行进行媒体段数据的获取，因此客户端侧代理102在收到来自客户端101的请求的时刻将已经获取并合成的媒体段数据的响应消息配送给客户端101(SE19)。客户端101从接收到的响应消息中提取内容数据(片段的数据)，并接着SE12的重放对所提取出的数据进行重放(SE20)。之后，在对内容、即视频的重放结束之前，重复执行SE13到SE20的步骤。然而，如上所述，从SE13、SE19和SE14到SE18的处理不同步。
图15及图16是用于对在图14所示的本发明实施方式2所涉及的数据配送系统的动作中、在将广播配送的开始时刻定为可使用时刻(可开始重放时刻)的情况下进行处理时所收发的HTTP消息进行说明的图。
图15(a)的ME01表示图14的SE01、SE02、SE03、SE10的HTTP请求消息的一个例子。图15(b)的ME04表示图14的SE04、SE11的多部分MIME格式的HTTP响应消息的一个例子。图15(c)的ME06表示附加有图14的SE06的路径信息和时刻信息的多部分MIME格式的HTTP响应消息的一个例子。
X-Alternative-Path：broadcast-ipdatacast
X-Broadcast-Channel：1
X-Ipdatacast-Address=200.1.1.1
与实施方式1同样地，表示广播路径的路径信息。此外，
X-Ipdatacast-Starttime：03:00:00
表示利用广播路径的数据配送的开始时刻，
X-Ipdatacast-Endtime：04:00:00
表示利用广播路径的数据配送的结束时刻。
图16(a)的ME07表示进行图14的SE07的可使用时刻的通知的HTTP响应消息的一个例子。在该例中，利用X-available-time:来将图15(c)的ME06中所记录的时刻信息中的配送开始时刻的值设定为可使用时刻(可开始重放时刻)。图16(b)的ME08表示图14的SE08、SE13的HTTP请求消息的一个例子。图16(c)的ME09表示图14的SE09、SE19的多部分MIME格式的HTTP响应消息的一个例子。图16(d)的ME14表示利用了图14的SE14中所配送的IP数据播送的、多部分MIME格式的HTTP响应消息的广播配送数据的一个例子，且在这里与图11的M910相同。图16(e)的ME16表示图14的SE16的验证的HTTP请求消息的一个例子。图16(f)的ME18表示与图14的SE16的验证请求相对的SE18中的HTTP响应消息的一个例子。
接着，表示将广播配送的结束时刻而非广播配送开始时刻设为可使用时刻时的例子。
图17是用于对在本发明实施方式2所涉及的数据配送系统中、将广播配送的结束时刻定为可使用时刻(可开始重放时刻)的情况下的处理进行说明的序列图。
SH01到SH06的动作与上述在图14中进行说明的SE01到SE06的动作相同。接着，客户端侧代理102从所接收到的响应中提取时刻信息，并利用响应消息来对客户端101进行可使用时刻的通知(SH07)，这里，将所通知的时刻设定为配送的结束时刻。
服务器侧代理103在SH06中对最初的媒体段的数据进行配送后，向内容服务器104请求下一个媒体段的数据(SH08)。内容服务器104用多部分MIME格式的HTTP响应消息来发送对SH08的响应(SH09)。之后，服务器侧代理103在接收完一个内容数据之前，重复执行SH08、SH09的步骤。
客户端侧代理102在经过配送开始时刻后(未图示)，对利用广播路径传输来的SH09以后的媒体段数据进行识别，并依次进行获取(SH10)。如上所述，识别过程中利用了各IP包中所附加的IP数据播送地址。然后，将所接收到的数据依次合成为多部分MIME格式的HTTP响应消息(SH11)。
此时，在经由广播来进行配送的响应消息中附加以下内容并进行发送：如上所述的、表示在利用前需要在服务器侧代理103中进行验证的信息、以及验证所使用的识别标签信息。由此，客户端侧代理102向服务器侧代理103发送用于对合成后的响应SH11是否有效进行验证的请求(SH12)，且服务器侧代理103向客户端侧代理102返回表示有效的响应(SH14)。通过上述验证处理，服务器侧代理103能够对利用广播路径进行发送的内容数据是否正在被客户端所利用进行监视，并能用于配送终止的判断等。然而，在本实施方式中，由于预先指定了配送结束时刻，因此该监视的处理不是必须的。然后，客户端侧服务器在接收完一个内容数据前重复执行SH10～SH14的步骤，并在配送的结束时刻(即，向客户端101通知的可使用时刻)之前完成所有内容数据的获取。
在SH07的响应中接受到可使用时刻的通知后，客户端101在经过被指定的可使用时刻后，向客户端侧代理102发送请求(SH15)。客户端侧代理102用多部分MIME格式的HTTP响应消息来将SH06中利用通信路径向客户端101进行配送的最初的媒体段数据作为对SH15的响应来进行配送(SH16)。客户端101通过接收到的SH16的响应来提取内容数据(片段的数据)，并开始重放(SH17)。之后，客户端101向内容服务器104请求下一个媒体段数据(SH18)，并从客户端侧代理102接收响应(SH19)，从接收到的响应中提取内容数据，并接着SH17的重放对提取出的数据进行重放(SH20)。这些响应数据可以在可使用时刻=配送结束时刻之前，在客户端侧代理102中得到。之后，在对内容的重放结束之前，重复执行SH18到SH20的步骤。
图18是用于对在图17的序列图所示的本发明实施方式2所涉及的数据配送系统的动作中、将广播配送的结束时刻作为可使用时刻(可开始重放时刻)来进行通知时的消息进行说明的图。
图18(a)的MH07表示在图17的SH07中进行可使用时刻的通知的HTTP响应消息的一个例子。在该例中，利用X-available-time:来将图15(c)的ME06中所记录的时刻信息中的配送结束时刻的值设定为可使用时刻(可开始重放时刻)。
图14、图17表示在与实施方式1同样利用广播路径对内容数据进行配送的情况下、进一步对规定的配送时刻进行设定并进行配送的案例。对最初的各个客户端101的请求(SE01、SH01)返回可使用的时刻(SE07、SH07)，对可使用时刻后的再请求(SE10、SE13、SH15、SH18)返回客户端侧代理102中已缓存的多部分格式的响应(SE11、SE19、SH16、SH19)。
可使用时刻可以是图14、图17中的两种情况。
图14表示了如下情况：将广播配送的开始时刻定为可使用时刻来向客户端101进行通知，客户端侧代理102一边进行利用广播的接收，一边依次向客户端101返回响应。面向数据的配送时刻与重放时刻同步的实时传输的IP数据播送配送的情况等。
图17表示如下情况：将广播配送的结束时刻定为可使用时刻来向客户端101进行通知(即，在可使用时刻，客户端侧代理102已对所有数据完成了接收及验证)，并依次对客户端101的请求返回储存有接收完的数据的响应。面向可以在下载结束后进行重放的下载型广播配送的情况等。
由此，在本实施方式2的数据配送系统中，可以实现利用通信路径、广播路径来协同进行的内容数据的配送。
[实施方式3]
本发明的实施方式3对如下示例进行说明：使用HTTP的协议来进行客户端与内容服务器之间的通信，并在利用多部分MIME格式的HTTP消息对片段化的内容数据进行配送的系统中，经由广播网络对数据量较多的视频数据进行配送，经由通信网络对数据量较少的音频数据进行配送。与实施方式1同样地，可以参照图1、图2的系统结构图、功能模块图来对本实施方式所涉及的数据配送系统的整体结构、以及代理内部的功能模块结构进行说明。
图19是用于对本发明实施方式3所涉及的、利用广播来配送视频数据、利用通信来配送音频数据时的处理进行说明的图。
对于内容数据中的视频数据，使用广播路径来将其共通地从服务器侧代理103发送给客户端侧代理102，仅对于音频数据利用通信来个别地进行发送。假设在进行多种语言内容的配送等。
因此，构成媒体段的片段包括存储有同一时刻的视频数据的片段fragment1-XXv、以及储存有音频数据的片段fragment1-XXa(SJ10、SJ23等)。
图19是对已有相同内容的要求、已在经由广播来对构成内容的视频数据进行配送、并且客户端101对尚未要求完的、包含日语(ja)的音频数据的内容提出新的要求时的序列进行图示的例子。在SJ03中，确认正在利用广播路径对视频数据进行配送的过程中。在SJ04中，进一步对所要求的日语(ja)音频数据是否已接收完进行确认，且由于尚未接收，故服务器侧代理103向内容服务器104请求音频数据(SJ05)。内容服务器104以多部分MIME格式的HTTP响应消息的形式将音频数据配送给服务器侧代理103。服务器侧代理103通过从内容服务器104接收到的响应消息，来提取音频数据，并生成与缓存完的视频数据进行合成后得到的多部分MIME格式的HTTP响应消息(SJ07)，并在该消息中附加路径信息(SJ08)。服务器侧代理103将附加有路径信息的多部分MIME格式的HTTP响应消息配送给客户端侧代理102(SJ09)。
与实施方式1同样地，在SJ08中将对内容数据进行配送的广播路径的信息附加到从服务器侧代理103发送到客户端侧代理102的响应消息的报头中，在本实施方式中，附加有表示利用广播路径仅对视频数据进行配送的信息(X-Alternative-Path：broadcast-ipdatacast；video-only)。
与之前的实施方式同样地，通过广播路径获取视频数据(SJ13)，将其复原为消息的格式(SJ14)，并进行验证(SJ15、SJ17)。因此，向视频数据中附加用于验证的信息(ETag：“abcde”、Cache-Control：proxy-revalidate)来进行传输。
对于音频数据，则是个别地发出请求(SJ18)，并收到响应(SJ21)。然后，在客户端侧代理102中生成与验证完的视频数据合并后的多部分MIME格式的响应消息(SJ22)，并将其发送给客户端101(SJ23)。客户端101对此进行重放(SJ24)。
由此，在本实施方式的数据配送系统中，仅对需要个别进行发送的数据(在本实施方式中为音频数据)经由通信来进行发送，并经由广播来对公共的数据(在本实施方式中为视频数据)同时进行配送，从而能够实现不压迫通信频带的最合适的内容配送。另外，虽然本实施方式中例举了视频数据和音频数据的例子，但在本方式中可以配送的数据组合不限于此。例如，也可以得到如下案例：将包含视频、音频的内容数据作为公共的数据而经由广播来进行配送，且仅将字幕数据利用通信来进行配送。
图20、图21、图22是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所配送的HTTP消息进行说明的图。
图20(a)的MJ01表示图19的SJ01、SJ02的HTTP请求消息的一个例子。图20(b)的MJ05表示图19的SJ05中用于对音频数据进行请求的HTTP请求消息的一个例子。图20(c)的MJ06表示图19的SJ06的多部分MIME格式的HTTP响应消息的一个例子。
图21(a)的MJ09表示图19的SJ09中附加有路径信息的多部分MIME格式的HTTP响应消息的一个例子。
图22(a)的MJ10表示图19的SJ10的多部分MIME格式的HTTP响应消息的一个例子。图22(b)的MJ12表示图19的SJ12中用于对下一个媒体段进行请求的HTTP请求消息的一个例子。
图23是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时从广播路径进行配送的响应进行说明的图。
在图23的SJ13中，对多部分MIME格式的HTTP响应消息进行IP分组化，由此生成数据MJ13，并进行利用IP数据播送的广播配送。图11表示要配送的HTTP消息与IP分组化所形成的广播配送数据MJ13之间的关系。IP包包括储存有IP数据播送地址的报头部分和对想要传输的数据主体进行储存的净荷数据。在净荷数据中，将要求了响应消息的、原先的请求消息所指定的URI即请求数据URI、要配送的HTTP响应消息的报头部的数据、以及消息的数据部的各个片段的数据分别划分为一个或多个IP包来进行储存。片段数据储存的数据量与媒体段对应。此外，在每个片段数据中划分出IP包来进行储存，从而具有以下优点：即使在广播配送中失去了一部分数据的情况下，但只要对与所失去的数据相对应的片段数据以外的数据进行复原，就能对内容进行重放。
而且，如上所述，在该要配送的HTTP响应消息中包括：表示在利用前需要在服务器侧代理103中进行验证的信息(Cache-Control：proxy-revalidate)；以及验证中所使用的识别标签信息(ETag：“abcde”)。
图24是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行处理时所配送的HTTP消息进行说明的图。
图24(a)的MJ15表示图19的SJ15中用于进行验证的HTTP请求消息的一个例子。图24(b)的MJ17表示图19的SJ17中用于进行验证的HTTP响应消息的一个例子。图24(c)的MJ18表示图19的SJ18、SJ19中用于对下一个媒体段的音频数据进行请求的HTTP请求消息的一个例子。图24(d)的MJ20表示图19的SJ20、SJ21的多部分MIME格式的HTTP响应消息的一个例子。
图25是用于对本发明实施方式3所涉及的、在利用广播来配送视频数据、利用通信来配送音频数据的情况下进行合成处理后所配送的HTTP消息进行说明的图。
图25(a)的MJ23表示图19中利用SJ23的响应从客户端侧代理102向客户端101进行配送的多部分MIME格式的HTTP响应消息的一个例子。在该响应的数据中记载有图19的SJ23的、在SJ22中对从广播路径接收到的视频数据和从通信路径接收到的音频数据进行合成后得到的数据。
[实施方式4]
本发明实施方式4对客户端侧的代理与多个客户端相连的情况进行说明。使用HTTP的协议来进行客户端与内容服务器之间的通信，在利用多部分MIME格式的HTTP消息对片段化的内容数据(媒体段单位)进行配送的系统中，利用广播路径对数据量较多的视频数据进行配送，利用通信路径对数据量较少的音频数据进行配送。
图26是本发明实施方式4所涉及的、在客户端侧代理105与多个客户端相连的情况下的功能框图。
在客户端侧代理105与多个客户端相连的案例中，客户端侧代理105也包括监视部2601，并进行缓存管理。对于已接收完的请求，不向内容服务器进行请求，而由客户端侧代理105对已缓存的响应进行代理应答。
[实施方式5]
以上，在实施方式1到4中，将电视接收机假设为客户端的装置，并假设经由通信网络及广播网络来对内容数据进行配送。另一方面，近来，移动电话等移动设备也开始搭载以移动数字电视(one seg)为代表的电视广播接收功能，这些设备中也可以找到与电视接收机同样的、能够应用本发明(可以经由通信网络及广播网络来对内容数据进行接收)的客户端装置。
而且，在移动电话等移动环境的通信网络中，作为与广播同样的实现同时配送的方式，存在利用通信网络的多播配送。3GPP(Third GenerationPartnership Project：第三代合作伙伴计划)所规定的MBMS(MultimediaBroadcast and Multicast Service：多媒体广播多播业务)是其中之一，其在无线接入通信网络上进行与广播相类似的数据的同时配送。
可以说对于向多个终端同时进行广播配送而言，MBMS是高效率的方式。然而，当终端数较少时，效率不一定好。即，若进行接收的移动电话、移动设备(客户端)的数量较少，则利用单播配送来向各个终端进行配送有时能更高速地完成数据配送，效率更高。然而，对于上述情况，现有技术中由于无法在配送侧得知连接的状况，因此，预先对连接的终端数量进行估计，在配送侧决定进行单播配送还是MBMS配送，并进行配送。即，在估计错误等情况下，会进行效率较低的内容配送。
因此，在本实施方式中，将上述实施方式1到4中所说明的、经由通信网络和广播网络的切换配送的控制扩大到无线接入通信网络中的、单播配送和MBMS多播配送的切换配送的控制。
图27是表示本实施方式5所涉及的、使用了移动设备的无线接入通信网络的数据配送系统的整体结构的系统结构图。
在本数据配送系统中，采用以下结构：即，对于核心网络，多个无线接入网络RAN(Radio Access Network)：RAN-1～m经由代理108与内容服务器104相连接，该RAN-1～m分别与多个客户端装置(移动电话、移动设备)相连接。内容服务器104及服务器侧代理108是构成核心网络的节点。另外，客户端装置(移动电话、移动设备)采用内置有客户端本身(指客户端应用等)106-1～n和代理107-1～n的结构。
由于客户端装置是移动设备，因此在使用时连接到RAN，若不使用则切断连接。即，对于各个RAN，在某个时刻，在该时刻下与其连接的客户端装置的数量是可变的。此外，当客户端装置从某个RAN移动到不同的RAN中时，所连接的客户端装置的数量也会变化。
因此，可能会发生如下情况：在某一时刻下，对于连接有多个客户端装置的RAN，利用MBMS进行配送来同时发送内容数据的效率更好，另一方面，在某一时刻下，对于所连接的客户端装置的数量较少的RAN，对各个客户端装置的每个客户端装置进行单播配送的效率更好。
因此，本实施方式的数据配送系统内的服务器侧代理108对与本身相连接的各个RAN的连接状况(连接中的客户端的数量)进行监视，对于各个RAN中进行数据配送的配送模式，判断是由利用HTTP的单播模式来进行配送，还是由利用MBMS的多播模式来进行配送，并进行切换。即，在本实施方式中，可以认为来自可能成为配送目标的候选的连接中的客户端数较多的RAN的请求较为集中，因此对于上述RAN，利用多播模式来进行配送。另一方面，可以认为来自可能成为配送目标的候选的连接中的客户端数较少的RAN的请求并不那么集中，因此对于上述RAN，利用单播模式来进行配送。然后，根据连接中的客户端数量的增减来对这些模式进行适当的切换。另外，可以预先设定成为基准的阈值，并可由所检测出的连接中的客户端数量是否超过该阈值来判断客户端数量的多少。上述配送模式的切换利用与实施方式1到4中所说明的、从通信路径到广播路径的切换相同的机制来进行。
即，在根据连接状况的监视结果、判定为将某个RAN内的配送从单播模式切换到多播模式的情况下，服务器侧代理108将MBMS配送的路径信息附加到HTTP响应消息的报头中，并将其经由客户端侧代理107发送给该RAN内的客户端装置106，对之后的内容数据开始进行MBMS配送。
图28中表示在切换为利用MBMS的多播配送的时刻之前的、从服务器侧代理108向客户端侧代理107所配送的多部分MIME格式的HTTP消息响应消息的一个例子。这是与实施方式1中在从通信网络切换到广播网络的时刻之前所配送的M906相对应的响应消息，作为广播路径的替代，附加了表示MBMS多播配送的路径信息的报头、即X-Alternative-Path：……中间省略……session_name=multicast_content1。具体可参照图28(a)MR01。之后的动作与实施方式1等中所说明的动作相同。
以上，在本实施方式所涉及的使用了移动接入通信网络的数据配送系统中，根据各个RAN的客户端装置的连接状态，来将数据配送方式适当切换为单播、多播，由此来实现最合适的内容配送。这里，假设客户端装置是移动电话、移动设备。
另外，在本实施方式的上述说明中，假设与服务器侧代理108相连的RAN有多个，并将这些RAN作为以分开的、例如设置在物理上不同的位置的基站为基点而形成的RAN等来进行了说明，但本实施方式也可以应用于如下情况：对于一个RAN所连接的客户端装置，根据各个客户端装置的要求状态将其分为多个组，并由上述各个组虚拟地形成多个RAN。
在本发明实施方式的说明中，将影片片段(movie fragment)设为1秒，将媒体段设为10秒来进行了说明，但影片片段的期间长度不限于1秒，另外，媒体段的期间长度也不限于10秒。即，例如，可以根据MPEG-4的编码单位即GOP(Group of Picture：画面组)将影片片段的期间长度设为0.5秒，也可以设为2秒等更长的期间。此外，内容服务器104也可以采用以下结构：即，能根据HTTP消息的产生频度适当地将媒体段的期间长度变更为用户所设定的长度。即，根据目的、状况，用户也可以将媒体段的期间长度设为30秒或1分钟等，以对请求消息及响应消息的产生频度进行抑制，或者，在频繁产生切换的情况下，也可以设为5秒等，以快速地进行响应。而且，也可以使影片片段的长度可变，或使媒体段的长度可变。
此外，在极端情况下，如果是将内容数据划分为规定的长度来进行处理而得的数据格式，即使是影片片段以外的数据格式，也可以应用本发明。即，本发明的通信系统所处理的数据格式不限于影片片段格式。例如，也可以使用MPEG-2的PES(Packetized Elementary Stream：打包的基本码流)包、MPEG-2TS(Transport Stream：传送流)的TS包来构成本发明的通信系统。即，本发明的通信系统对每个划分为规定长度的单位数据(PES包、TS包)以多部分MIME格式来将内容数据储存在HTTP消息中。由此，代理服务器即使不读取多部分的各部分中所记录的数据的内容，也能够利用HTTP消息的报头信息等来对所储存的数据进行过滤、处理。
另外，应当认为这里所公开的实施方式1到5的方式在所有方面均为例示，并不是限制性的。可认为本发明的范围并不是由上述说明来表示，而是由权利要求的范围来表示，包含与权利要求的范围同等的意义及范围内的所有变更。
(总结)
如上所述，现有技术存在如下问题：在利用流媒体的同时配送中，同样的消息在通信网络上流动，通信量增大。此外，采用相同的机制来对广播路径和通信路径进行利用，简单地将通过不同路径而接收到的数据连接起来，甚至没有用于对数据进行协同、同步的机制。
因此，上述数据配送系统中，在利用多部分MIME格式的HTTP、并以媒体段单位对内容数据进行配送的前提下，在服务器侧代理中，根据同一请求的产生频度等，使用广播路径和通信路径来进行适当的片段分割通信。此外，在客户端侧代理中，在收到通信路径的响应消息之后，对被配送的、来自通信路径的数据和来自广播路径的数据的信息(路径识别、同步信息)进行相适应的合并处理。而且，对于在利用广播进行配送的过程中进行其它内容要求的情况，仅将内容切换后的起始数据经由通信来进行高速传输。
(本发明的优选实施方式)
本发明所涉及的数据配送系统包括：数据配送装置，该数据配送装置通过规定的格式，以媒体段单位对多个内容数据进行配送；配送侧数据中继装置，该配送侧数据中继装置与所述数据配送装置、通信网络和广播网络相连接，经由所述广播网络和所述通信网络中的至少任意一个网络，对由所述数据配送装置配送的所述内容数据进行配送；接收侧数据中继装置，该接收侧数据中继装置与所述通信网络和所述广播网络相连接，将由所述配送侧数据中继装置配送的所述内容数据配送给接收终端装置；以及接收终端装置，该接收终端装置能够对由所述接收侧数据中继装置配送的所述内容数据进行接收，其特征在于，所述配送侧数据中继装置根据来自接收终端装置的数据要求，来对所述广播网络和所述通信网络进行相适应的分割配送，优选为所述规定的格式为HTTP。
本发明所涉及的配送侧数据中继装置的特征在于，包括：第一发送单元，该第一发送单元利用第一配送路径对内容进行配送；第二配送单元，该第二配送单元利用与所述第一配送路径不同的第二配送路径对内容进行配送；以及选择单元，该选择单元选择使用所述第一发送单元及所述第二发送单元中的哪一个发送单元来对接收终端装置所要求的内容进行配送，优选为所述第一配送路径是经由广播网络的通信路径，所述第二配送路径是经由通信网络的通信路径，所述配送侧数据中继装置还包括检测单元，该检测单元对所述通信网络的通信量较大时所产生的规定的现象的产生进行检测，当所述检测单元检测出所述现象的产生时，所述选择单元选择利用所述第一发送单元来对该内容进行配送。
根据上述结构，当通信网络的通信量较大时，能够利用广播网络来对内容进行发送，因此能够抑制通信网络中通信量的增大。
另外，对于所述配送侧数据中继装置，优选为所述第一配送路径是经由广播网络的通信路径，所述第二配送路径是经由通信网络的通信路径，当所述选择单元选择通过所述第一发送单元来对所述内容进行配送时，附加用于从广播网络获取该内容的信息，并利用所述第一发送单元对该内容进行配送。
根据上述结构，附加用于从广播网络获取内容的信息，并利用广播网络对该内容进行配送。由此，接收终端装置能够从广播网络中获取所述信息，并获取该内容。
另外，优选为当所述配送侧数据中继装置的所述选择单元选择利用所述第一发送单元对所述内容进行配送时，附加表示需要对本装置发出验证该内容有效性的要求的信息，并利用所述第一发送单元对该内容进行配送，在由所述第一发送单元进行配送之后，根据对本装置发出的验证要求的接收状况，来终止由所述第一发送单元进行的配送。
根据上述结构，能够对利用第一发送单元进行配送的内容的有效性进行验证。此外，由于根据内容的验证要求的接收状况来终止由第一发送单元所进行的配送，因此，对于例如超过一定时间未接收到验证要求、很可能不在利用广播网络进行内容获取的情况，能够终止利用广播网络的配送。
在所述内容被分割为多个片段的情况下，所述选择单元也可以选择通过所述第一发送单元对所述多个片段中的一部分片段进行配送，并通过所述第二发送单元对其它片段进行配送。
根据上述结构，能够灵活运用第一、第二配送路径各自的特性来对一个内容进行配送。例如，可以想到以下情况：第一配送路径的通信速度较慢但适合大量的数据发送，第二配送路径的通信速度较快但不适合对大量的数据进行发送。根据上述结构，在上述情况下，可以利用第二发送单元来对多个片段中的、数据大小较小、应该提前发送的片段进行配送，并利用第一发送单元来对数据大小较大的片段进行发送。
另外，优选为所述第一配送路径可以是对内容进行多播的通信路径，所述第二配送路径可以是对内容进行单播的通信路径，对于这种情况，当成为所述内容的配送目标的候选的所述接收终端装置的数量超过规定阈值时，所述选择单元选择利用所述第一发送单元来对所述内容进行配送，当所述接收终端装置的数量在所述阈值以下时，所述选择单元利用所述第二发送单元来对所述内容进行配送。
根据上述结构，当内容的配送目标在规定阈值以下、预想为配送要求比较少时，对内容进行单播。此外，当内容的配送目标超过规定阈值、估计会接收到大量的配送要求时，对内容进行多播。因此，能够根据状况利用合适的通信路径来进行内容的配送。
另外，优选为本发明所涉及的接收侧数据中继装置包括：第一接收单元，该第一接收单元对利用第一配送路径配送的内容进行接收；第二接收单元，该第二接收单元通过与所述第一配送路径不同的第二配送路径，对以不同于所述第一配送路径的发送数据格式配送的内容进行接收；以及格式统一单元，该格式统一单元对无论利用所述第一接收单元及所述第二接收单元中的哪一个接收单元所接收到的内容，都以相同的发送数据格式向所述接收终端装置进行发送，对于所述内容被分割成多个片段的情况，当利用所述第一接收单元来接收所述多个片段中的一部分片段、并利用所述第二接收单元来接收其它片段时，所述格式统一单元将接收到的各个片段的发送数据格式进行统一，并合成为一个内容来发送给所述接收终端装置。
根据上述结构，即使在利用第一接收单元和第二接收单元接收到多个片段的情况下，也对所接收到的各个片段的发送数据格式进行统一，并合成为一个内容。由此，接收终端装置不会得知构成该内容的各个片段是利用不同的路径及数据格式来进行配送的，能够将该内容作为一个内容来利用。
发明的详细说明项中完成的具体实施方式或实施例都只是为了阐明本发明的技术内容，不应狭义地解释为只限于这样的具体示例，可在本发明的精神和下面所记载的权利要求书的范围内，进行各种变更后加以实施。
工业上的实用性
本发明所涉及的数据配送系统及数据配送方法是多媒体数据配送技术，更具体而言，能够在适合于利用数据传输协议的通信、广播协同配送的、高效的多媒体数据配送中应用。
标号说明
101-1～101-n、106-1～106-n  客户端(接收终端装置)
102、102-1～102-n  客户端侧代理(接收侧数据中继装置)
105、107-1～107-n  客户端侧代理(接收侧数据中继装置)
103、108  服务器侧代理(配送侧数据中继装置)
104  内容服务器(数据配送装置)
201  接收部
203  接收部(第二接收单元)
204  接收部(第一接收单元)
301、304  接收部
202、207  发送部
302  发送部
307  发送部(第二发送单元)
308  发送部(第一发送单元)
303、2601  监视部
205  处理部(格式统一单元)
305、2602  处理部(选择单元)
206、306  缓存部
RAN-1～RAN-m  无线接入网络

Claims (11)

1.一种数据配送系统，包括：
数据配送装置，该数据配送装置通过规定的格式，以媒体段单位对多个内容数据进行配送；
配送侧数据中继装置，该配送侧数据中继装置与所述数据配送装置、通信网络和广播网络相连接，经由所述广播网络和所述通信网络中的至少任意一个网络，对由所述数据配送装置配送的所述内容数据进行配送；
接收侧数据中继装置，该接收侧数据中继装置与所述通信网络和所述广播网络相连接，将由所述配送侧数据中继装置配送的所述内容数据配送给接收终端装置；以及
接收终端装置，该接收终端装置能够对由所述接收侧数据中继装置配送的所述内容数据进行接收，其特征在于，
所述配送侧数据中继装置根据来自接收终端装置的数据要求，来对所述广播网络和所述通信网络进行相适应的分割配送。
2.一种数据配送方法，包括：
数据配送步骤，在该数据配送步骤中，通过规定的格式，以媒体段单位对多个内容数据进行配送；
配送侧数据中继步骤，在该配送侧数据中继步骤中，经由广播网络及通信网络中的至少任意一个网络，对通过所述数据配送步骤配送的所述内容数据进行配送；
接收侧数据中继步骤，在该接收侧数据中继步骤中，对通过所述配送侧数据中继步骤并经由所述通信网络及所述广播网络中的至少任意一个网络来配送的所述内容数据进行配送；以及
接收步骤，在该接收步骤中，对通过所述接收侧数据中继步骤配送的所述内容数据进行接收，其特征在于，
在所述配送侧数据中继步骤中，根据数据要求，来对所述广播网络和所述通信网络进行相适应的分割配送。
3.如权利要求1所述的数据配送系统，其特征在于，
所述规定的格式为HTTP。
4.一种配送侧数据中继装置，所述配送侧数据中继装置是在经由网络将内容从数据配送装置配送到接收终端装置的数据配送系统中、从所述数据配送装置接收所述接收终端装置所要求的内容并将其配送给所述接收终端装置的配送侧数据中继装置，其特征在于，包括：
第一发送单元，该第一发送单元利用第一配送路径对所述内容进行配送；
第二配送单元，该第二配送单元利用与所述第一配送路径不同的第二配送路径对所述内容进行配送；以及
选择单元，该选择单元选择使用所述第一发送单元及所述第二发送单元中的哪一个发送单元来对所述接收终端装置所要求的所述内容进行配送。
5.如权利要求4所述的配送侧数据中继装置，其特征在于，
所述第一配送路径是经由广播网络的通信路径，所述第二配送路径是经由通信网络的通信路径，
所述配送侧数据中继装置还包括检测单元，该检测单元对所述通信网络的通信量较大时所产生的规定的现象的产生进行检测，
当所述检测单元检测出所述现象的产生时，所述选择单元选择利用所述第一发送单元来对该内容进行配送。
6.如权利要求4或5所述的配送侧数据中继装置，其特征在于，
所述第一配送路径是经由广播网络的通信路径，所述第二配送路径是经由通信网络的通信路径，
当所述选择单元选择通过所述第一发送单元来对所述内容进行配送时，附加用于从广播网络获取该内容的信息，并利用所述第一发送单元对该内容进行配送。
7.如权利要求5或6所述的配送侧数据中继装置，其特征在于，
当所述选择单元选择利用所述第一发送单元对所述内容进行配送时，附加表示需要对本装置发出验证该内容有效性的要求的信息，并利用所述第一发送单元对该内容进行配送，
在由所述第一发送单元进行配送之后，根据对本装置发出的验证要求的接收状况，来终止由所述第一发送单元进行的配送。
8.如权利要求4至7的任一项所述的配送侧数据中继装置，其特征在于，
所述内容被分割成多个片段，
所述选择单元选择通过所述第一发送单元对所述多个片段中的一部分片段进行配送，并通过所述第二发送单元对其它片段进行配送。
9.如权利要求4所述的配送侧数据中继装置，其特征在于，
所述第一配送路径是对内容进行多播的通信路径，所述第二配送路径是对内容进行单播的通信路径，
当成为所述内容的配送目标的候选的所述接收终端装置的数量超过规定阈值时，所述选择单元选择利用所述第一发送单元来对所述内容进行配送，当所述接收终端装置的数量在所述阈值以下时，所述选择单元选择利用所述第二发送单元来对所述内容进行配送。
10.一种接收侧数据中继装置，所述接收侧数据中继装置是在经由网络将内容从数据配送装置配送到接收终端装置的数据配送系统中、对所配送的所述内容进行接收并将其发送给所述接收终端装置的接收侧数据中继装置，其特征在于，包括：
第一接收单元，该第一接收单元对利用第一配送路径配送的所述内容进行接收；
第二接收单元，该第二接收单元通过与所述第一配送路径不同的第二配送路径，对以不同于所述第一配送路径的发送数据格式配送的所述内容进行接收；以及
格式统一单元，该格式统一单元对无论利用所述第一接收单元及所述第二接收单元中的哪一个接收单元所接收到的内容，都以相同的发送数据格式向所述接收终端装置进行发送。
11.如权利要求10所述的接收侧数据中继装置，其特征在于，
所述内容被分割成多个片段，
当利用所述第一接收单元来接收所述多个片段中的一部分片段、并利用所述第二接收单元来接收其它片段时，所述格式统一单元将接收到的各个片段的发送数据格式进行统一，并合成为一个内容来发送给所述接收终端装置。
CN2011800354532A 2010-07-20 2011-07-19 数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置 Pending CN103004229A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2010-162557 2010-07-20
JP2010162557 2010-07-20
PCT/JP2011/066355 WO2012011467A1 (ja) 2010-07-20 2011-07-19 データ配信システム、データ配信方法、配信側データ中継装置、及び受信側データ中継装置

Publications (1)

Publication Number Publication Date
CN103004229A true CN103004229A (zh) 2013-03-27

Family

ID=45496887

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2011800354532A Pending CN103004229A (zh) 2010-07-20 2011-07-19 数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置

Country Status (5)

Country Link
US (1) US20130124683A1 (zh)
EP (1) EP2597825A4 (zh)
JP (1) JPWO2012011467A1 (zh)
CN (1) CN103004229A (zh)
WO (1) WO2012011467A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105247872A (zh) * 2013-07-03 2016-01-13 索尼公司 用于分配至少一个内容版本的方法、信息提供系统及接收设备
CN106233737A (zh) * 2014-03-26 2016-12-14 耐瑞唯信有限公司 电视信道集的传输优化方法
CN109845276A (zh) * 2016-10-27 2019-06-04 索尼公司 信息处理装置和信息处理方法

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2012011449A1 (ja) * 2010-07-20 2013-09-09 シャープ株式会社 プロキシサーバ、中継方法、通信システム、中継制御プログラム、および記録媒体
JP5967480B2 (ja) * 2012-07-23 2016-08-10 パナソニックＩｐマネジメント株式会社 コンテンツ伝送システム、コンテンツ伝送方法、送信装置、送信方法、送信プログラム、及び受信装置
US9491784B2 (en) * 2012-07-31 2016-11-08 Apple Inc. Streaming common media content to multiple devices
US9596192B2 (en) 2013-03-15 2017-03-14 International Business Machines Corporation Reliable link layer for control links between network controllers and switches
US9407560B2 (en) 2013-03-15 2016-08-02 International Business Machines Corporation Software defined network-based load balancing for physical and virtual networks
US9444748B2 (en) * 2013-03-15 2016-09-13 International Business Machines Corporation Scalable flow and congestion control with OpenFlow
US9769074B2 (en) 2013-03-15 2017-09-19 International Business Machines Corporation Network per-flow rate limiting
US9609086B2 (en) 2013-03-15 2017-03-28 International Business Machines Corporation Virtual machine mobility using OpenFlow
JP6007152B2 (ja) * 2013-06-12 2016-10-12 株式会社日立製作所 通信システム及び通信システムの冗長化の方法
JP2014241520A (ja) * 2013-06-12 2014-12-25 日本放送協会 送信システム、情報送信装置、プラットフォーム装置及び受信装置
US10984175B2 (en) 2013-08-09 2021-04-20 Yottaa Inc. Systems and methods for dynamically modifying a requested web page from a server for presentation at a client
US20150088970A1 (en) 2013-09-20 2015-03-26 Yottaa Inc. Systems and methods for managing loading priority or sequencing of fragments of a web object
US10110541B2 (en) * 2013-10-17 2018-10-23 International Business Machines Corporation Optimization of posting in social networks using content delivery preferences comprising hashtags that correspond to geography and a content type associated with a desired time window
CN105659623B (zh) * 2013-10-30 2019-04-26 索尼公司 发送装置、发送方法、接收装置以及接收方法
KR20160120605A (ko) 2015-04-08 2016-10-18 한국전자통신연구원 하이브리드망에서의 미디어 서비스 송수신 장치 및 방법
CN104980340A (zh) * 2015-06-25 2015-10-14 走遍世界（北京）信息技术有限公司 服务器的切换方法及装置
US10063657B2 (en) * 2015-10-13 2018-08-28 Sap Portals Israel Ltd Managing identical data requests
CN107483970B (zh) * 2016-06-08 2020-09-18 华为技术有限公司 一种确定热门直播视频的方法及设备
JP6472478B2 (ja) * 2017-04-07 2019-02-20 キヤノン株式会社 映像配信装置、映像配信方法及びプログラム
WO2020173878A1 (en) * 2019-02-27 2020-09-03 British Telecommunications Public Limited Company Multicast assisted delivery
US11711274B2 (en) * 2020-02-11 2023-07-25 International Business Machines Corporation Request response based on a performance value of a server
GB2598295B (en) 2020-08-19 2023-02-22 British Telecomm Content delivery
WO2024029497A1 (ja) * 2022-08-04 2024-02-08 株式会社Ｎｔｔドコモ 仮想空間提供システム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020025777A1 (en) * 2000-08-31 2002-02-28 Yukihiro Kawamata Information distributing method, information receiving method, information distribution system, information distribution apparatus, reception terminal and storage medium
US20030221014A1 (en) * 2002-05-24 2003-11-27 David Kosiba Method for guaranteed delivery of multimedia content based on terminal capabilities
US20040042479A1 (en) * 2000-06-20 2004-03-04 Steve Epstein Unicast/multicast architecture
US20050044174A1 (en) * 2003-04-11 2005-02-24 Sun Microsystems, Inc. Multi-node computer system where active devices selectively initiate certain transactions using remote-type address packets
US20090024749A1 (en) * 2005-04-07 2009-01-22 Mediacast, Inc. Adaptive file delivery with transparency capability system and method
US20100179987A1 (en) * 2009-01-13 2010-07-15 Viasat, Inc. Content set based pre-positioning

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001283015A (ja) * 2000-03-29 2001-10-12 Nippon Columbia Co Ltd コンテンツデータ配信システムおよび方法
US20030121047A1 (en) * 2001-12-20 2003-06-26 Watson Paul T. System and method for content transmission network selection
JP2005051562A (ja) * 2003-07-29 2005-02-24 Matsushita Electric Ind Co Ltd コンテンツ送信方法及び装置、並びにこれらを用いたコンテンツ配信システム
JP2007173987A (ja) 2005-12-19 2007-07-05 Canon Inc マルチメディアデータ送受信システム、及び装置、又はプログラム
US7992175B2 (en) * 2006-05-15 2011-08-02 The Directv Group, Inc. Methods and apparatus to provide content on demand in content broadcast systems
US20090276815A1 (en) * 2008-04-30 2009-11-05 Echostar Technologies L.L.C. Systems, methods and apparatus for democratic allocation of bandwidth
JP5262675B2 (ja) * 2008-12-19 2013-08-14 富士通株式会社 映像配信システムおよびユニキャスト型多地点映像配信方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040042479A1 (en) * 2000-06-20 2004-03-04 Steve Epstein Unicast/multicast architecture
US20020025777A1 (en) * 2000-08-31 2002-02-28 Yukihiro Kawamata Information distributing method, information receiving method, information distribution system, information distribution apparatus, reception terminal and storage medium
US20030221014A1 (en) * 2002-05-24 2003-11-27 David Kosiba Method for guaranteed delivery of multimedia content based on terminal capabilities
US20050044174A1 (en) * 2003-04-11 2005-02-24 Sun Microsystems, Inc. Multi-node computer system where active devices selectively initiate certain transactions using remote-type address packets
US20090024749A1 (en) * 2005-04-07 2009-01-22 Mediacast, Inc. Adaptive file delivery with transparency capability system and method
US20100179987A1 (en) * 2009-01-13 2010-07-15 Viasat, Inc. Content set based pre-positioning

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
STIJIN DE VUYST、KRZYSZTOF TWORUS、SABINE WITTERVRONGEL ET AL.: "Analysis of Stop-and-Wait ARQ for a wireless channel", 《4OR》 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105247872A (zh) * 2013-07-03 2016-01-13 索尼公司 用于分配至少一个内容版本的方法、信息提供系统及接收设备
CN105247872B (zh) * 2013-07-03 2019-04-09 索尼公司 用于分配至少一个内容版本的方法、信息提供系统及接收设备
CN106233737A (zh) * 2014-03-26 2016-12-14 耐瑞唯信有限公司 电视信道集的传输优化方法
CN109845276A (zh) * 2016-10-27 2019-06-04 索尼公司 信息处理装置和信息处理方法
US11115335B2 (en) 2016-10-27 2021-09-07 Saturn Licensing Llc Information processing device and information processing method

Also Published As

Publication number Publication date
WO2012011467A1 (ja) 2012-01-26
EP2597825A4 (en) 2015-04-15
US20130124683A1 (en) 2013-05-16
EP2597825A1 (en) 2013-05-29
JPWO2012011467A1 (ja) 2013-09-09

Similar Documents

Publication Publication Date Title
CN103004229A (zh) 数据配送系统、数据配送方法、配送侧数据中继装置、及接收侧数据中继装置
US8705511B2 (en) System and method for synchronous transmission of content
CN106165434B (zh) 一种用于获取媒体数据的方法及计算机可读介质
KR101484843B1 (ko) 멀티미디어 전송 시스템에서 미디어 전송 패킷 전송 방법 및 장치
CN101505317B (zh) 流式媒体中断与恢复系统
EP2574004B1 (en) Method, apparatus and system for improving synchronization efficiency of really simple syndication service
US20130212231A1 (en) Method, apparatus and system for dynamic media content insertion based on http streaming
CN105187847B (zh) 一种分布式网络电视直播方法、装置、视频网关及系统
US20040063400A1 (en) System and method of providing mobile phone broadcasting service using cbs
CN103036889A (zh) 一种自适应的流媒体播放方法及其播放系统
US9369508B2 (en) Method for transmitting a scalable HTTP stream for natural reproduction upon the occurrence of expression-switching during HTTP streaming
CN101518027A (zh) 用于富媒体流式传输的基于xml的内容分段的系统和方法
CN103999428A (zh) 用于在混合网络中传送多媒体数据的装置和方法
RU2010134094A (ru) Способ передачи содержания и устройство дисплея
CN104902343A (zh) 一种传输和播放音视频与消息的方法、服务器及终端
CN103269331A (zh) 选择可播放码率内容的方法和装置
US20110082943A1 (en) P2p network system and data transmitting and receiving method thereof
CN101540886B (zh) 一种视频点播业务的实现方法、系统及归属流媒体服务器
CN101981928A (zh) 多层消息过滤
CN105656910A (zh) 媒体传输服务器、媒体传输系统、用户终端和媒体传输方法
KR20160077066A (ko) 송신 장치, 송신 방법, 수신 장치, 및 수신 방법
CN105325005A (zh) 内容供应装置、内容供应方法、程序、终端装置以及内容供应系统
CN102333209A (zh) 应用于视频监控系统的数据传输方法及设备
US10110972B2 (en) Transmitting device, transmitting method, receiving device, and receiving method
CN104581424B (zh) 一种流媒体传输方法、相关设备和系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20130327