CN103004133A - 代理服务器、中继方法、通信系统、中继控制程序、及记录介质 - Google Patents

Abstract

本发明的目的在于提供一种代理服务器、中继方法、通信系统、中继控制程序、及记录介质。代理（250）包括：当检测到来自代理（200）的视频要求时，将表示其自身能够代替服务器（300）来利用多播对视频进行发送的信息发送给该代理的处理部（251）；以及在接收到来自代理（200）的JOIN消息时将该代理登录到多播组中的处理部（253）。处理部（253）利用多播将缓存（252）中的视频中继给登录完的各个代理。

Description

代理服务器、中继方法、通信系统、中继控制程序、及记录介质

技术领域

本发明涉及发送装置的代理服务器及上述代理服务器的中继方法，在该发送装置的代理服务器及上述代理服务器的中继方法中，基于来自重放装置或来自重放装置的代理服务器这样的通信装置的要求，将从发送装置发送的数据中继给通信装置。本发明还涉及使计算机作为上述代理服务器进行动作的中继控制程序及对该中继控制程序进行存储的记录介质。而且，本发明还涉及至少包括上述代理服务器、通信装置和发送装置的通信系统。

背景技术

近年来，随着对互联网的需求急剧增长，希望不仅能看到由文本、静态图像等静态内容构成的网络（WEB）页面，还能通过接收流媒体配送来观看动态图像内容及音频内容的用户越来越多。

通常，文本数据、静态图像数据等静态内容是利用基于http(s)协议等的单播通信来进行发送和接收的。动态图像内容及音频内容也大多通过单播通信来进行发送和接收。

利用单播通信来对动态图像内容进行配送的配送方式可以例举如下：对MPEG（MovingPicture Expert Group：动态图像专家组）的MP4文件格式进行依次下载的配送方式（专利文献1）、使用了MPEG的ISO媒体文件格式（ISO Medi aFile Format）的片段视频格式的配送方式（专利文献2）。

由于单播通信的数据的发送和接收通常是在建立了通信源和通信目的地之间的连接之后再进行的，所以具有数据的发送和接收的可靠性较高的优点。

现有技术文献

专利文献

专利文献1：日本专利公开公报“特开2005-110244号公报(2005年4月21日公开)”

专利文献2：日本专利公开公报“特开2007-173987号公报(2007年7月5日公开)”

发明内容

发明所要解决的技术问题

然而，在上述现有的利用单播通信的配送方式中，如图23中的箭头所示，配送服务器分别向发出配送要求的各个客户端装置配送动态图像内容，因此，存在当一次从多个客户端装置接收到配送要求时、网络的频带负载升高的问题。此外，由于配送服务器需要一次与多个重放装置建立连接，因此也会有配送服务器本身的处理负担加重的问题。

鉴于上述问题，现提出本发明，其主要目的在于实现一种能够对从发送装置发送的数据所导致的网络的频带负载进行抑制的发送装置的代理服务器。

解决技术问题所采用的技术方案

为解决上述课题，本发明所涉及的代理服务器根据来自通信装置的要求，将从发送装置发送的内容缓存到存储部中，并将该内容中继给所述通信装置，其特征在于，包括：发送单元，当检测到所述通信装置通过单播通信向所述发送装置发出了表示应当发送内容的第一要求时，该发送单元向所述通信装置发送表示该代理服务器能够代替所述发送装置来通过多播通信对该内容进行发送的信息；登录单元，当从所述通信装置接收到表示应当使用多播通信来发送所述内容的第二要求时，该登录单元将所述通信装置登录到多播组中；以及中继单元，该中继单元使用多播通信将缓存在所述存储部中的该内容中继给登录在所述多播组中的各通信装置。

所述代理服务器能够以例如下述方式构成：所述第一要求是HTTP请求消息，所述发送单元对将所述信息作为报头信息包含在内的HTTP响应消息进行发送，所述报头信息包括表示所述多播组的地址的值。

根据上述结构，所述代理服务器根据来自通信装置的要求向通信装置发送表示其自身能够代替所述发送装置来通过多播通信对从所述发送装置发送的内容进行发送的信息。然后，对于所述代理服务器，当从所述通信装置接收到表示应当使用多播通信来发送所述内容的要求时，其自身代替所述发送装置使用多播通信向所述通信装置发送所述内容。

因此，当有多个通信装置向所述发送装置要求利用单播通信来配送内容时，所述代理服务器能够通过多播通信将内容配送给所述多个通信装置。

由此，当有多个通信装置向所述发送装置要求利用单播通信来配送内容时，与直接对通过单播通信从所述发送装置发送的各个内容进行中继的现有的代理服务器相比，本发明的代理服务器可以起到如下效果：能够对从发送装置发送的数据所导致的网络的频带负载进行抑制。

为解决上述课题，本发明所涉及的中继方法根据来自通信装置的要求，将从发送装置发送过来的内容缓存到存储部中，并将该内容中继给所述通信装置，其特征在于，包括：发送过程，在该发送过程中，当检测到所述通信装置通过单播通信向所述发送装置发出了表示应当发送内容的第一要求时，向所述通信装置发送表示该代理服务器能够代替所述发送装置来通过多播通信对该内容进行发送的信息；登录过程，在该登录过程中，当从所述通信装置接收到表示应当使用多播通信来发送所述内容的第二要求时，将所述通信装置登录到多播组中；以及中继过程，在该中继过程中，使用多播通信将缓存在所述存储部中的该内容中继给登录在所述多播组中的各通信装置。

根据上述结构，本发明的中继方法可以起到与本发明的代理服务器相同的作用效果。

发明效果

如上所述，本发明的代理服务器可以起到如下效果：能够对从发送装置发送的数据所导致的网络的频带负载进行抑制。

附图说明

图1是表示本发明实施方式所涉及的配送系统的整体结构的图。

图2是示意性表示图1配送系统1中，从配送服务器向客户端装置配送视频内容的期间中、各装置间的通信处理的图。

图3是表示构成图1的配送系统的各装置的详细结构的功能框图。

图4是示意性表示视频内容的位流和影片片段的关系的图。

图5是示意性表示媒体段（media segment）和影片片段(movie fragment)的关系的图。

图6是表示在图1的配送系统的各装置之间，从客户端装置发出视频内容的配送要求起、到结束对客户端装置配送视频内容为止所进行的所有处理过程的前半部分的序列图。

图7是表示在图1的配送系统的各装置之间，从客户端装置发出视频内容的配送要求起、到结束对客户端装置配设视频内容为止所进行的所有处理过程的后半部分的序列图。

图8是表示在图6及图7的序列所表示的处理过程中发送的消息的一个例子的图。（a）是表示客户端装置所发送的请求消息的图，（b）是表示配送服务器所发送的响应消息的图。

图9是表示在图6及图7的序列所表示的处理过程中发送的消息的另一个例子的图。（a）是表示配送服务器的代理服务器所发送的响应消息的图。（b）和（c）分别表示客户端装置的代理服务器所发送的HTTP消息格式的多播组的JOIN消息及LEAVE消息。

图10（a）～（c）是表示图1的配送系统中，从配送服务器的代理服务器向客户端装置的代理服务器发送的多播包的结构的图。

图11是具体表示图1的配送系统中，配送服务器的代理服务器如何将作为HTTP的响应消息而发送的视频内容的数据转换为多播包的图。

图12是示意性表示图1的配送系统中各装置之间的通信处理的图。（a）是发出配送要求的客户端装置的数量为三个时的图，（b）是发出配送要求的客户端装置的数量为三个时的图。

图13是表示图1的配送系统中，客户端装置从用户处接收到表示中断视频内容的重放的指示时，各装置间处理的流程的序列图。

图14是表示图1的配送系统中，客户端装置的代理服务器所包括的HTTP处理部的动作的流程图。

图15是表示图1的配送系统中，客户端装置的代理服务器所包括的多播处理部的动作的流程图。

图16表示图1的配送系统中，配送服务器的代理服务器所包括的HTTP处理部所进行的动作，是表示接收到将客户端装置的代理服务器设为发送目的地的响应消息时进行的动作的流程图。

图17是表示图1的配送系统中，客户端装置的代理服务器所包括的多播处理部的动作的流程图。

图18表示图1的配送系统中，配送服务器的代理服务器所包括的HTTP处理部所进行的动作，是表示接收到JOIN消息时进行的动作的流程图。

图19是表示图1的配送系统中客户端装置的动作的流程图。

图20是表示图1的配送系统中，当在多播通信的过程中缺失了多播包时发送给客户端装置的HTTP响应消息的一个例子的图。

图21是表示图1的配送系统中，当客户端装置同时对重放中的内容进行录像时，利用基于HTTP通信获取到的缺失部的影片片段、来对多播通信所造成的缺失的影片片段进行补全处理的流程图。

图22是表示图1的配送系统中，当从用户处接收到表示中断重放视频内容的指示时，客户端装置所进行的动作的流程图。

图23表示现有技术，是表示多个客户端装置的各客户端装置分别从配送服务器接收视频内容数据的配送系统的图。

图24是表示图1的配送系统中，在已经在进行多播配送的状态下、新的客户端装置发出了视频内容的配送要求时的动作例的序列图。

图25是表示图1的配送系统中，对客户端装置中重放的视频内容进行切换时的动作例的序列图。

具体实施方式

(实施方式1)

下面参照附图对本发明的一个实施方式所涉及的配送系统进行说明。

图1是表示本实施方式所涉及的配送系统1的整体结构的图。配送系统1包括：N台客户端装置100（100-1、100-2、…、100-N）；各个客户端装置100的代理即代理服务器200(200-1、200-2、…、200-N)；配送服务器300；以及配送服务器300的代理服务器250。

如图1所示，在配送系统1中，由代理服务器250和配送服务器300来形成配送侧网络（LAN），由客户端装置100-1～100-N和代理服务器200-1～200-N来形成重放侧网络（LAN）。此外，两个LAN被干线网络500隔开，干线网络500与各代理服务器200-1～200-N、250连接。

另外，在本实施方式中，假设干线网络500是在代理服务器200和代理服务器250之间未设置有路由器的网络。

此外，在配送系统1中，配送服务器300可以对多个信道的视频内容进行配送。然后，当客户端装置100经由未图示的操作部从用户处接收信道的指定时，由配送服务器300对所指定的信道的视频内容进行配送（下面也称为“目标视频内容”）。来自客户端装置100的配送要求及由配送服务器300配送的视频内容首先会被发送到相对应的代理服务器。

图2是示意性表示配送系统1中，从配送服务器300向客户端装置100-1～100-N配送视频内容的期间中、各装置间的通信处理的图。图2中向右及向左的细箭头表示基于HTTP协议（即，单播通信）的视频内容的要求及应答。此外，图2中，粗箭头表示利用多播通信的视频内容的传输。

如图2所示，在配送系统1的各个LAN内，使用数据传输协议之一的HTTP（Hypertext Transfer Protocol：超文本传输协议）协议的请求·响应的机制来对视频内容进行发送。此时，以HTTP协议所规定的MIME多部分格式（简称为“多部分格式（multipart）”）来进行视频内容的交换。

而且，如图2所示，在配送系统1中，视频内容在干线网络内通过多播通信来配送。通过使用多播通信，则代理服务器250只需发送一次数据（视频内容的包）就能够将该数据配送给属于发送目的地的多播组的多个代理服务器200。

下面，参照图3对客户端装置100、代理服务器200、代理服务器250及配送服务器300的详细结构进行说明。

（客户端装置100）

客户端装置100包括HTTP处理部101及重放部102。

HTTP处理部101按照后文阐述的媒体段（每隔一定时间对视频内容进行分割所得到的各个单位，在各图中简称为“MS”）单位将视频内容的配送要求（请求消息）发送给代理服务器200。

HTTP处理部101按照媒体段单位、并以多部分格式的响应消息的形式从代理服务器200接收视频内容，该响应消息将后文阐述的影片片段（片段）作为各部分。

重放部102通过对HTTP处理部101接收到的各媒体段进行读取，来对视频内容进行重放。

（代理服务器200）

代理服务器200包括HTTP处理部201、缓存部202及多播处理部203。

HTTP处理部201将从客户端装置100接收到的配送要求传输给将代理服务器200作为发送源的代理服务器250，或者从缓存部202中读取接收配送要求的数据并发送给客户端装置100。

缓存部202是对数据进行保存的缓存存储器。

多播处理部203向代理服务器250要求加入及退出多播组。此外，多播处理部203对通过多播通信传输过来的数据进行接收并将其转换为HTTP响应消息的格式。

（代理服务器250）

代理服务器250包括HTTP处理部251、缓存部252、多播处理部253及多播组信息存储部254。。

HTTP处理部251将从代理服务器200接收到的配送要求中继给配送服务器300。对于正在向规定台数以上的通信装置配送目标视频内容的情况，HTTP处理部251会对从配送服务器300发送至的目标视频内容的响应消息、来附加表示能对目标视频内容进行多播配送的报头信息，之后将其中继给代理服务器200。

而且，当存在属于应当对目标视频内容进行多播配送的多播组（下面也称为“目标多播组”）的代理服务器200时（即，当存在应当对目标视频内容进行多播配送的代理服务器200时），HTTP处理部251将代理服务器250本身作为请求方，依次从配送服务器300中获取目标视频内容的各个媒体段的响应消息，并将其缓存在缓存部252中。

缓存部252是对数据进行保存的缓存存储器。缓存部252对由配送服务器300发送的响应消息进行保存。

当从代理服务器200-i（i：1～N中的任意值）接收到加入目标多播组的要求时，多播处理部253将代理服务器200-i的地址作为属于目标多播组的地址记录在多播组信息存储部254中。此外，当从代理服务器200-i接收到退出目标多播组的要求时，多播处理部253将作为属于目标多播组的信息进行记录的代理服务器200-i的地址从多播组信息存储部254中删除。

而且，当存在应当进行目标视频内容的多播配送的代理服务器200时，多播处理部253依次将缓存部252中记录的HTTP的响应消息转换成可进行多播配送的格式的数据包（参照图10及图11,在后文中进行阐述）,并将其配送给应当进行多播配送的代理服务器200。

多播组信息存储部254是非易失性的存储器。多播组信息存储部254对根据每个视频内容所设定的多个多播组的各个多播组，来保存属于该多播组的发送目的地的通信装置的地址。

（配送服务器300）

配送服务器300包括HTTP处理部301及存储部302。

HTTP处理部301从存储部302中读取被要求配送的视频内容的媒体段，并将其作为多部分格式的响应消息来发送给代理服务器250，该多部分格式将影片片段作为各部分。

存储部302对多个信道的视频内容进行保存。

以上，对客户端装置100、代理服务器200、250及配送服务器300的详细结构进行了说明，但在对配送系统1的动作进行说明之前，先参照图4及图5对上述影片片段及媒体段进行如下的说明。

（关于媒体段及影片片段）

首先参照图4对影片段进行说明。

图4是示意性地表示视频内容的位流（Contents.mp4）和对位流进行分割、储存的各影片片段的关系的图。图5是示意性地表示媒体段和构成媒体段的各影片片段的关系的图。

如图4所示，位流被分割并储存在多个影片片段中。图中，mdat是分割后得到的位流数据。各个影片片段对应于以一定期间单位对位流进行划分后得到的单位部分。在本实施方式中，假设以ISO媒体文件格式(ISO MediaFile Format)规定的片段视频格式来作为影片片段。

MP4文件的位流中的起始影片片段（片段1）中包括moov报头41b。moov报头41b对与用于进行视频重放的整个位流有关的元信息(metadata)（初始化信息等）进行保存。MP4文件的位流中的后续影片片段（片段2、3、…）中包括moof报头42b。各影片片段的moof报头42b是用于对该影片片段的视频进行重放的元信息的报头。

各影片片段中，除报头以外还包括媒体数据（视频本身的数据）mdat。各影片片段的媒体数据mdat中分别储存有与该影片片段相对应的期间内的部分数据。例如，当片段是以1秒为单位对位流进行划分后得到的数据时，片段1的媒体数据mdat中储存有从开始重放视频内容起1秒内的视频数据。

接着参照图5对媒体段进行说明。

如图5所示，媒体段由多个影片片段构成。媒体段也与以一定期间单位对内容数据进行划分后得到的单位部分相对应。而且，在本实施方式中，将该媒体段作为一个响应数据中储存的内容数据来对待。即，媒体段是一次请求所获得的内容数据的单位。

此外，根据媒体段由多个影片片段构成可知，一个媒体段所对应的期间的长度是一个影片片段所对应的期间的长度的整数倍（然而，这是对于影片片段的长度固定的情况，若影片片段的长度可变，则不限于整数倍）。另外，在接下来说明的动作例中，将一个媒体段对所对应的期间设为30秒，并将一个影片片段所对应的期间的长度设为1秒来进行说明。

（配送系统1的动作例1）

接着，参照图6～图12对从客户端装置100发出目标视频内容的配送要求起、到对客户端装置100的目标视频内容的配送结束为止，配送系统1中进行的动作的一个具体例进行说明。

图6及图7分别是表示上述动作的前半部分及后半部分的序列图。

另外，在该动作例中，限定为代理服务器250的HTTP处理部251在对四台以上的装置配送目标视频内容的情况，附加表示能进行多播配送的报头信息。此外，假设在动作开始前，已对三台客户端装置100-2～100-4配送目标视频内容，且新的客户端装置100-1发出了目标视频内容的配送要求。

首先，客户端装置100-1向代理服务器200-1发送要求目标视频内容的起始媒体段的HTTP请求41（第一要求）（S01）。该请求41是图8(a)所示的数据，从图8(a)可知，客户端装置100-1以持久连接(KeepAlive)方式与代理服务器200-1连接。即，客户端装置100-1在接收到对请求41的响应后也保持连接状态。

接着，代理服务器200-1的HTTP处理部201在将自身的IP地址设定为发送源后，将从客户端装置100-1接收到的请求41发送给代理服务器250（S02）。然后，代理服务器250的HTTP处理部251以持久连接方式与配送服务器300连接，并将请求41中继给配送服务器300（S03）。

接收了请求41的配送服务器300的HTTP处理部301从存储部302中读取目标视频内容，生成图8(b)所示的响应消息51并发送给代理服务器250（S04）。

图8(b)中，响应消息51内的“www.sampl e.com”表示配送服务器300的主机域名，“content1”表示目标视频内容的文件名。此外，X-Segment-Fragment-Index：1/60表示媒体段的索引值。即，X-Segment-Fragment-Index：1/60表示：目标视频内容由60个媒体段构成，该响应消息是第一个媒体段的数据。

而且，“｛binary-data：fragment-01｝”～“｛binary-data：fragment-30｝”的部分表示构成第一个媒体段的30个影片片段。

接收了响应消息51的代理服务器250的HTTP处理部251对来自目标视频内容的客户端装置100的要求频度进行确认（S05）。即，HTTP处理部251对一定期间内所接收到的、针对同一目标视频内容的请求41的次数进行计数。这里，由于客户端装置100的台数是客户端装置100-1～100-4这四台，且要求频度达到一定程度以上，因此通过对响应消息51附加表示能进行多播配送的报头信息，来生成如图9(a)所示的响应消息51a（S06）。

图9(a)中被虚线框所包围的字符串（从“X-alternative-cast”开始的字符串）表示附加的报头信息。

X-alternative-cast的报头信息的格式如下。

<配送形式>://<配送地址>/<TTL>?session_id=<会话ID>?session_name=<会话名称>

其中，<配送形式>表示内容的配送方法，在图9(a)中表示多播配送，即“multicast”。此外，配送形式是多播配送时的<配送地址>（图9(a)中“224.1.1.1”）表示多播地址。多播地址通常描述D类IP多播组地址。

<TTL>表示数据包的有效期（time to Live）。其对网络内的传输范围进行设定。在代理服务器200和代理服务器250之间的网络中具有路由器情况下，在经由路由器来对多播数据进行配送时，需要将<TTL>设定为较大的值，但由于在本实施方式中，干线网络500中没有设置路由器，因此<TTL>的值为“1”。<会话ID>及<会话名称>用于对会话（sess ion）进行识别。

在S06的处理之后，HTTP处理部251将所生成的响应消息51a发送给代理服务器200-1（S07）。

若接收了响应消息51a的代理服务器200-1的HTTP处理部201确认有“X-alternative-cast”这一报头信息（S08），则将该情况通知给多播处理部203，并且将响应消息51a转换成原来的响应消息51发送给客户端装置100-1（S09）。另外，接收了响应消息51的客户端装置100-1的重放部102开始对目标视频内容进行重放。

之后，代理服务器200-1的HTTP处理部201向代理服务器250发送图9(b)所示的多播接收要求（要求加入目标多播组的JOIN消息（加入消息）42）（S10）。如图9(b)及图9(c)所示，JOIN消息42（第二要求）及后文阐述的LEAVE消息(退出消息)43是GET请求格式的HTTP消息。JOIN消息42及LEAVE消息43的报头部的X-alternative-multicast-set报头分别被附加了表示加入多播组的字符串及表示退出多播组的字符串。即，JOIN消息42被附加了“JOIN”，LEAVE消息43被附加了“LEAVE”。

接收了JOIN消息42的代理服务器250的HTTP处理部251发出响应消息，并将代理服务器200-1的地址作为属于目标多播组的地址记录在多播组信息存储部254中（S11）。

另一方面，在S10中接收了JOIN消息的HTTP处理部251对目标视频内容的媒体段进行获取（S12），并将其记录在缓存部252中（S13）。之后反复进行S12及S13的处理。即，S12及S13的处理是针对构成目标视频内容的所有媒体段来进行的。另外，对S12的处理进行重复的周期并没有特别限定。即，可以以小于一个媒体段在客户端装置100中的重放时间的周期来重复进行S12的处理。

另一方面，在步骤S11的处理结束后，多播处理器253依次将缓存部252中记录的媒体段的响应消息51转换为多播的包（S14）。

这里，参照图10及图11对S14的处理细节进行如下的说明。

首先参照图10对多播包的格式进行说明。

如图10（c）所示，多播包包括UDP报头部、RTP报头部和RTP数据部。下面参照图10(a)及图10(b)对多播包更具体的结构进行说明。

图10(a)表示构成多播包的UDP包的格式。UDP包的UDP报头部包括：多播包的发送源的端口号，多播包的发送目的地的端口号，UDP包的包长度，以及用于获取包的匹配性的校验码的字段。UDP包的数据部的长度是可变的。

图10(b)表示构成UDP包的数据（数据报：datagram）部分的RTP包的格式。RTP包的RTP数据部（有效载荷数据）中记录了响应消息51的一部分。

RTP包的RTP报头部中储存了表示多播包的发送顺序的序列编号和时间戳。这里，RTP包的时间戳中储存了一部分包含在该RTP包的RTP数据部中的响应消息51中的、最小时间戳（X-timestamp）的值。例如，当RTP数据部中包含与第二个媒体段相对应的响应消息51的一部分时，在RTP报头部的时间戳中储存“30”。

接着，参照图11对多播处理部253如何将HTTP的响应消息51转换为多播包进行具体的说明。

图11中的左侧部分示意性地表示了转换后的多播包52-1、52-2、52-3、…。图11中的右侧部分示意性地表示了HTTP的响应消息51（51-1、51-2…）内的报头部分的数据、和体部分(bodypart)的各部分的数据作为有效载荷数据储存在哪个多播包中。

若多播处理部253从缓存部252中读取到媒体段的响应消息51-1，则在响应消息51的Content-Location报头的字符串中提取“目标视频内容的文件名”及“媒体段的索引值”的部分（即，“/content1/1”），并作为有效载荷数据储存到最初的多播包52-1中。

然后，多播处理部253将消息51-1中的报头部分作为有效载荷数据储存到下一个多播包52-2中。

接着，多播处理部253将消息51-1的体部分的数据作为有效载荷数据储存到后续的多播包52-3…中。更具体而言，多播处理部253根据影片片段的数据大小来将各部分中包含的影片片段储存到一个或多个多播包52中。多播处理部253对消息51-2之后的各消息51也进行同样的处理。

另外，各部分中包含的影片片段的二进制数据必须以开头部分与多播包52的有效载荷（payload）的开头部分一致的方式储存在多播包52中。同样地，各部分中包含的影片片段的二进制数据必须以结尾部分与多播包52的有效载荷的结尾部分一致的方式储存在多播包52中。即，多个影片片段的二进制数据不会储存在一个多播包中。

此外，对于多播处理部253，在多播包的报头部分中，除了在上述UDP报头部、RTP报头部及RTP数据部中储存有适当的值以外，还在IP报头部中储存IP多播地址（多播组地址），即“224.1.1.1”。

多播处理部253依次将如上所述进行转换后的多播包52配送给代理服务器200-1（S15）。

代理服务器200-1的多播处理部203对在S15中配送的多个多播包52进行汇总，并转换为媒体段的响应消息51（S16），缓存到缓存部202中（S17）。之后反复进行S15～S17的处理。即，S12及S13的处理是针对构成目标视频内容的所有媒体段来进行的。

另一方面，客户端装置100-1接着向代理服务器200-1发送要求目标视频内容的第二个媒体段的HTTP请求41（S18）。

接收了请求41的代理服务器200-1的HTTP处理部201从缓存部202中读取第二个媒体段的响应消息51（S19）。另外，对于当尝试进行读取时缓存部202中未缓存有响应消息51的情况，HTTP处理部201会保持待机状态直到响应消息51被缓存，之后进行读取。

读取了响应消息51的HTTP处理部201将响应消息51发送给客户端装置100-1。对于接下来的第三个以后的媒体段也依次进行上述S18、S19的处理。

之后，假设配送服务器300从代理服务器250接收要求最后一个媒体段的请求41。

配送服务器300的HTTP处理部301将对通常的响应消息51的报头部附加了“Connection：Close”（连接：解除）这一报头后得到的响应消息51'作为最后一个媒体段的响应消息发送给代理服务器250（S20）。

当HTTP处理部251确认了响应消息51'的报头部中存在有“Connection：Close”这一字符串时，识别出与配送服务器300的连接状态被解除的情况（S21）。

然后，多播处理部253将缓存部252中缓存的响应消息51'转换为多播包52并发送给代理服务器200（S22）。

代理服务器200-1的多播处理部203对在S22中配送的多个多播包52进行汇总，并转换为媒体段的响应消息51'，来缓存到缓存部202中。另外，多播处理部203对所缓存的响应消息51'的报头部中存在有“Connection：Close”这一报头的情况进行确认。

若客户端装置100-1向代理服务器200-1发送要求下一个媒体段的HTTP请求41，则接收了请求41的代理服务器200-1的HTTP处理部201从缓存部202中读取该媒体段的响应消息51'。

若读取了响应消息51'的HTTP处理部201确认报头部中存在有“Connection：Close”这一报头（S23），则向客户端装置100-1发送响应消息51'，并解除与客户端装置100-1的连接状态（S24）。由此，客户端装置100-1识别出与代理服务器200的连接状态被解除。因此，在重放部102结束重放该响应消息51'的媒体段（即，目标视频内容的最后一个媒体段）的时刻，完成目标视频内容的重放。

另一方面，识别出响应消息51'的报头部中存在有“Connection：Close”这一报头的多播处理部203将该情况通知给HTTP处理部201，HTTP处理部201将图9（c）所示的多播接收结束通知（要求退出多播组的LEAVE消息）43发送给代理服务器250。

接收了LEAVE消息43的代理服务器250的HTTP处理部251发出响应，并确认接收到的消息是LEAVE消息43（S26）。

然后，HTTP处理部251将作为属于目标多播组的信息而进行记录的、多播组信息存储部254内的代理服务器200-1的地址删除（S27）。由此，代理服务器200-1不再属于应当对目标视频内容进行多播配送的多播组。

另外，对于客户端装置100-2～100-4及代理服务器200－2～200-4也同样地进行S22以后的处理。即，客户端装置100-2～100-4中也完成目标视频内容的视频重放，且代理服务器200-2～200-4不再属于应当对目标视频内容进行多播配送的多播组。

由此，属于目标多播组的所有装置都脱离目标多播组，因此，能够在对其它视频内容进行多播配送时，使用作为目标多播组的多播组地址而使用的“224.1.1.1”。

以上，使用图6及图7对配送系统1的动作例进行了说明。

然而，在S23中，假设HTTP处理部201及多播处理部203确认响应消息51'的报头部中存在有“Connection：Close”这一报头。但HTTP处理部201及多播处理部203也可以参照报头部的X-Media-Segment-index报头，来确认媒体段的索引值（图8(b)中的“1”）、与表示构成目标视频内容的媒体段的个数的值（图8(b)中的“60”）是否相同。然后，对于确认为相同值的情况，HTTP处理部201可以将该情况通知到多播处理部203，由此来使多播处理部203发送LEAVE消息。

（在利用客户端装置来对视频内容的重放进行中断时的配送系统1的动作）

接着，下文中参照图13说明客户端装置100-1根据来自用户的重放中断指示，来对目标视频内容的重放进行中断时的配送系统1的动作。这里，进行说明的前提是，客户端装置100-1是唯一一个从配送服务器300接收目标视频内容的配送的装置。

图13是表示客户端装置100-1从用户处接收到表示中断视频内容的重放的指示时，各装置间的处理的流程的序列图。

如图13所示，当通过未图示的操作部接收到重放中断指示时，客户端装置100-1的重放部102中断目标视频内容的重放。此外，HTTP处理部101将对要求下一个媒体段的HTTP请求41的报头部附加了“Connection：Close”这一报头后得到的请求41'发送给代理服务器200-1（S28）。

接收了请求41’的代理服务器200-1的HTTP处理部201对请求41’的报头部中附加有“Connection：Close”这一报头进行确认（S29）。然后，HTTP处理部201从缓存部202中读取媒体段的响应消息51，将其发送给客户端装置100-1，并解除与客户端装置100-1的连接状态。

此外，对附加有“Connection：Close”这一报头进行了确认的HTTP处理部201将附加有上述报头的情况通知给多播处理部203（S30）。另外，HTTP处理部201向代理服务器250发送图9（c）所示的要求从目标多播组中退出的LEAVE消息43（S31）。

接收到LEAVE消息43的代理服务器250的HTTP处理部251向代理服务器200发出响应，并确认所接收到的响应是LEAVE消息43（S32）。

然后，HTTP处理部251将作为属于目标多播组的信息而记录的、多播组信息存储部254内的代理服务器200-1的地址删除（S33）。由此，代理服务器200-1不再属于应当对目标视频内容进行多播配送的多播组。

若不存在属于目标多播组的装置，则多播处理部253向HTTP处理部通知该情况。然后，HTTP处理部251向报头部附加“Connection：Close”这一报头，并将HTTP消息发送给配送服务器300（S34）。由此，配送服务器300和代理服务器250的连接状态被解除。

以上，以动作例的形式对配送系统1整体的处理流程进行了说明，下面将参照图14～图22对构成配送系统1的各个装置的动作进行说明。

[代理服务器200的动作]

首先，对客户端装置100的代理服务器200的动作进行说明，但会分为HTTP处理部201和多播处理部203的动作来进行说明。

（HTTP处理部201的动作）

下面参照图14对HTTP处理部201的动作进行说明。图14是表示HTTP处理部201的动作的流程图。

如图14所示，HTTP处理部201从客户端装置100接收媒体段的请求41（S1101）。

接着，HTTP处理部201对缓存部202中是否缓存有一些数据进行判定（S1102）。

当判定为缓存部202中缓存有一些数据时（S1102为“是”），HTTP处理部201从在S1101中接收到的请求41中读出请求U RI（在图8(a)的例子中为“/content1/1”）（S1107）。然后，HTTP处理部201从缓存部202中读出与该请求URI相对应的响应消息（与图8(a)的例子中的“/content1/1”相对应的响应消息是例如文件名为content1的目标视频内容的起始媒体段的响应消息）（S1108）。之后，进入S1109。

另一方面，当判定为缓存部202中未缓存有任何数据（S1102中为“否”）时，HTTP处理部201向代理服务器250发送请求41（S1103），之后，从代理服务器250接收相对应的响应消息（S1104）。

HTTP处理部201对所接收到的响应消息中是否包含报头信息（X-alternative-cast报头）进行判定，该报头信息（X-alternative-cast报头）表示代理服务器250能够通过多播通信来发送该内容（S1105）。当判定为不包含报头信息（X-alternative-cast报头）时（S1105中为“否”），进入S1109，当判定为包含报头信息（X-alternative-cast报头）时（S1105中为“是”），进入S1106。

在S1106中，HTTP处理部201发出用于进行多播接收的指示（通知用于进行接收的多播地址），在S1118中，在HTTP处理部201与代理服务器250之间，发送和接收JOIN消息，并进入S1110。

在S1109中，HTTP处理部201生成应当发送给客户端装置100的响应消息，并进入S1110。

在S1110中，HTTP处理部201对在S1101中接收到的请求41中是否包含通信结束通知（“Connection：Close”报头）进行判定。当判定为包含通信结束通知时（S1110中为“是”），HTTP处理部201将多播接收已结束的情况通知给多播处理部203（S1111），并进入S1112。另一方面，当判定为不包含通信结束通知时（S1110中为“否”），进入S1112。

在S1112中，HTTP处理部201对在S1104中接收到的响应中是否包含通信结束通知（“Connection：Close”报头）进行判定。当判定为包含通信结束通知时（S1112中为“是”），进入S1119。在S1119中，在HTTP处理部201与代理服务器250之间，发送和接收LEAVE消息43，并进入S1115。

另一方面，当判定为不包含通信结束通知时（S1110中为“否”），进入S1113。S1113中，HTTP处理部201对在S1104中接收到的响应是否是最后一个媒体段的响应进行判定（S113）。即，参照报头部的X-Media-Segment-index报头，来判定媒体段的索引值、与表示构成目标视频内容的媒体段的个数的值是否相同。

当判定为是最后一个媒体段时（S1113中为“是”），进入S1115。另一方面，当判定为不是最后一个媒体段时（S1113中为“否”），将在S1109中生成的响应消息直接发送给客户端装置100（S1114），并回到S1101。

在S1115中，HTTP处理部201对在S1109中生成的响应消息附加通信结束通知（S1115）。然后，HTTP处理部201将包含通信结束通知的响应消息发送给客户端装置100（S1116），并解除与客户端装置100的连接状态（S1117），结束处理。

（多播处理部203的动作）

下面参照图15对多播处理部203的动作进行说明。另外，这里说明的动作是在HTTP处理部201进行上述S1106的处理的情况下开始的动作。

图15是表示多播处理部203的动作的流程图。首先，多播处理部203从HTTP处理部201接收表示开始进行多播接收的通知（S1201）。

之后，多播处理部203进行初始化来接收多播数据。具体而言，为了接收多播配送（为了应答定期从代理服务器250发送至的的询问），而从HTTP处理部201中获取多播组地址（S1202）。

之后，多播处理部203依次对多播包进行接收（S1203），并将在S1205中接收到的多个包转换成媒体段的HTTP格式的响应消息（S1204）。

之后，多播处理部203将通过转换得到的响应消息缓存到缓存部202中（S1205），并参照响应消息中包含的报头部的X-Media-Segment-index报头（S1206）。即，判定媒体段的索引值、与表示构成目标视频内容的媒体段的个数的值是否相同。

在多播处理部203尚未完成对目标视频内容的所有数据进行接收时（S1207中为“否”），即，在媒体段的索引值、与表示构成目标视频内容的媒体段的个数的值不同时，回到S1203。

另一方面，在多播处理部203完成了对目标视频内容的所有数据进行接收时（S1207中为“是”），进入S2108。

在S1208中，多播处理部203将多播接收结束的情况通知给HTTP处理部201，结束处理。

[代理服务器250的动作]

接着，对配送服务器300的代理服务器250的动作进行说明，但会分为HTTP处理部251和多播处理部253的动作来进行说明。

（HTTP处理部251的动作）

下面参照图16及图18对HTTP处理部251的动作进行说明。

HTTP处理部251从代理服务器200接收到对目标视频内容的媒体段的请求（S1301）。

接着，HTTP处理部251将接收到的请求发送给配送服务器300（S1302），并从配送服务器300接收与该请求相对应的响应（S1303）。

HTTP处理部251判定是否已经在对目标视频内容进行多播配送（S1304）。即，HTTP处理部251参照多播组信息存储部254，来对是否存在已加入到目标多播组中的代理服务器200进行判定。

当判定为正在对目标视频内容进行多播配送时（S1304中为“是”），进入S1306。另一方面，当判定为未在对目标视频内容进行多播配送时（S1304中为“否”），进入S1305。

在S1305中，HTTP处理部251对来自客户端装置100的要求目标视频内容的要求频度进行确认。该S1305的处理与图6中S05的处理相同。即，HTTP处理部251对在一定期间内所接收到的、针对同一目标视频内容的请求41的次数进行计数。这里，若在请求41中包含的URI中，内容的文件名“content1”相同，则HTTP处理部251将其作为针对同一目标视频内容的请求来进行计数。例如，当接收到包含“content1/2”的请求41和包含“content1/3”的请求41时，将两者作为针对同一目标视频内容的请求来进行计数。

当在一定期间内接收到针对同一目标视频内容的请求的次数为规定的次数以上时（S1305中为“是”），进入S1306。另一方面，当在一定期间内接收到针对同一目标视频内容的请求的次数小于规定的次数时（S1305中为“否”），进入S1307。

在S1306中，HTTP处理部251生成将<配送方式>设为多播配送的X-alternative-cast报头，将X-alternative-cast报头附加到在S1304中从配送服务器300发送至的响应消息的报头部中。这里，对于已经在对目标视频内容进行多播配送的情况，X-alternative-cast报头的<配送地址>是在对目标视频内容进行配送时所使用的多播组地址。另一方面，对于未在对目标视频内容进行多播配送的情况，HTTP处理部251将任意未使用的D类多播组地址作为<配送地址>。

在S1307中，HTTP处理部251将响应消息发送给代理服务器200，进入S1308。

当从代理服务器200接收到JOIN消息时（S1308中为“是”），HTTP处理部251对是否已经在对目标视频内容进行多播配送进行判定（S1309）。当判定为已经对目标视频内容进行多播配送时（S1309中为“是”），进入S1311。此外，对于在一定期间内未从代理服务器200接收到JOIN消息的情况（S1308中为“否”），也进入S1311。

另一方面，当判定为已经在对目标视频内容进行多播配送时（S1309中为“是”），HTTP处理部251以持久连接方式与配送服务器300连接，并开始从配送服务器300获取目标视频内容的各响应消息的处理（后面使用图18进行详细阐述）（S1310）。

在S1310中，HTTP处理部251对从配送服务器300获取的响应消息的报头部中是否包含“Connection：Close”报头进行判定（S1311）。

当判定为包含有“Connection：Close”报头时（S1311中为“是”），HTTP处理部251维持待机状态，直到从代理服务器200接收到LEAVE消息（S1312），并在接收之后结束处理。

另一方面，当判定为不包含“Connection：Close”报头时（S1311中为“否”），进入S1313。HTTP处理部251对多播处理部是否向其通知了多播配送结束进行判定（S1313）。当判定为未被通知多播配送结束时（S1313中为“否”），直接结束处理。

另一方面，当判定为被通知了多播配送结束时（S1313中为“是”），HTTP处理部251解除与配送服务器的连接状态（S1314），结束处理。

下面参照图18对从配送服务器300获取目标视频内容的各响应消息的上述处理进行说明。

首先，HTTP处理部251基于最近一次从配送服务器300接收到的响应消息，来生成接下来应当发送给配送服务器300的请求的URI（S1501）。例如，当最近一次从配送服务器300接收到的响应消息的内容－位置（Content-Location）的末尾是“content1/1”时，生成“/content1/2”来作为请求的URI。

接着，HTTP处理部251向配送服务器300发送请求（S1502），并从配送服务器300接收响应（S1503）。

然后，HTTP处理部251将从配送服务器300接收到的响应与在S1502中发送的请求的URI信息关联地缓存到缓存部252中（S1504）。

最后，HTTP处理部251对是否接收了目标视频内容（文件名是“content1”的内容）的所有响应消息进行判定（S1505）。当判定为存在有尚未接收的响应消息时（S1505中为“否”），返回到S1501。另一方面，当判定为已接收了所有响应消息时（S1505中为“是”），结束处理。

（多播处理部253的动作）

下面参照图17对多播处理部253的动作进行说明。另外，这里说明的动作是在上述S1308中HTTP处理部251接收到JOIN消息的情况下开始的动作。

首先，多播处理部253从HTTP处理部251获取JOIN消息（S1401）。

接着，多播处理部253基于JOIN消息中包含的目标视频内容的文件名来确认目标多播组，并将发送了JOIN消息的代理服务器200的地址登录到目标多播组中（S1402）。

接着，多播处理部253从缓存部252中读出响应消息（S1403），并将其转换成多个多播包（S1404）。

然后，多播处理部253将通过转换得到的多个多播包配送给代理服务器200（S1405）。

之后，多播处理部253对是否从HTTP处理部251接收了LEAVE消息进行判定（S1406）。当判定为未接收LEAVE消息时（S1406中为“NO”），返回S1403。

另一方面，当判定为接收了LEAVE消息时（S1406中为“是”），多播处理部253将发送了该LEAVE消息的代理服务器200的地址从目标多播组中删除（S1407），进入S1408。

在S1408中，多播处理部253对是否存在属于目标多播组的其它代理服务器200进行判定。当判定为存在时（S1408中为“是”），回到S1403。

当判定为不存在时（S1408中为“否”），多播处理部253将目标视频内容的多播配送已结束（多播配送结束）通知到HTTP处理部251（S1409），结束处理。

[客户端装置100的动作]

（客户端装置100的动作之一）

接着，参照图19～图21，说明从客户端装置100自用户处接收到目标视频内容的重放指示起、到完成整个目标视频内容的重放为止的客户端装置100的动作。

客户端装置100的HTTP处理部101将目标视频内容的媒体段的请求发送给代理服务器200（S1701），并从代理服务器200接收响应（S1702）。

HTTP处理部101对在S1702中接收到的响应消息中是否包含moov报头进行判定（S1703）。当判定为包含有moov报头时（S1703中为“是”），进入S1704，当判定为不包含moov报头时（S1703中为“否”），进入S1705。

在S1704中，重放部102通过参照moov报头，来进行重放目标视频内容所需的初始化处理。

在S1705中，通过参照在S1702中接收到的响应消息的X-Time stamp的值，来判定媒体段内是否存在缺失部（缺失的影片片段）。

这里参照图20对影片片段的缺失进行说明。图20中的左侧部分表示从配送服务器300发送到代理服务器250的响应消息，图20中的右侧部分表示发送到客户端装置100的响应消息。

从图20中的左侧部分所示的响应消息转换得到的多个多播包52被发送给代理服务器200，但是在通过干线网络500的过程中可能会丢失一部分的包52。在图20的例子中，丢失了构成影片片段03及影片片段04的包52，客户端装置100所接收的响应51是缺失了影片片段03及影片片段04后的数据。

另外，成为仅缺失了影片片段03及影片片段04的数据的原因在于，响应51是以影片片段为各部分的、多部分格式的响应消息。此外，如图20所示，在本实施方式中影片片段是时间为1秒的数据，但相邻的各个部分所包含的时间戳（影片片段02的X-Timestamp：1.00和影片片段05的X-Timestamp：4.00）之差不是1秒而是3秒，因此重放部102能够检测出缺失了影片片段03及影片片段04这两个影片片段。

当判定在S1702中接收到的响应消息中不存在缺失部时（S1705中为“否”），进入S1713，当判定存在缺失部时（S1705中为“是”），进入S1706。

在S1706中，HTTP处理部101对是否对缺失部进行补全进行判定。即，基于事先由用户利用未图示的操作部所进行的设定（应当在对缺失部进行补全后再对媒体段进行重放的设定，或者应当对媒体段进行重放而不对缺失部进行补全的设定），来判断是否对缺失部进行补全。

当判定为不对缺失部进行补全时（S1706中为“否”），重放部102对接收到的媒体段内的影片片段数据的重放时间进行调整（S1707）。即，在媒体段内的影片片段数据中，利用X-Timestamp描述MovieFragment的重放开始时间，客户端从X-Timesamp中获取应当进行重放的时刻的Movi eFragment数据并进行重放。若媒体段内产生缺失，则因应当进行重放的时刻的影片片段不存在，从而导致看似重放停止，因此对X-Timestamp的值进行调整，以使影片片段（在时间上）连续。例如，将影片片段05的X-Timestamp获取为2.00，以使得从影片片段02开始连续。然后，对之后的影片片段的X-Timestamp进行同样的调整以使其连续。此外，也可以在重放时进行调整。例如，对于缺失的影片片段是目标视频内容的从第t秒起到第t+1秒为止的应当进行重放的影片片段的情况，重放部102进行控制，以在第t-1秒到第t+1秒为止的两秒内对缺失的影片片段的前一个影片片段进行重放（例如，（a）以1/2倍速对前一个影片片段进行重放，或者，（b）在最初的1秒内对前一个影片片段进行正常重放，并在之后的1秒内对构成该影片片段的最后一帧（静态图像）进行重放）。作为该控制可以举出如下处理：例如，重放部102在上述前一个影片片段的moof报头中记录应当重放2秒的信息。在S1707的处理之后进入S1713。

另一方面，当判定为要对缺失部进行补全时（S1706中为“否”），HTTP处理部101向代理服务器200发送获取缺失部的影片片段的请求（S1708），进入S1709。获取缺失的影片片段的请求可以是包含缺失的影片片段的媒体段的请求，也可以是仅获取缺失的影片片段的请求。

仅获取缺失的影片片段的请求的URI是例如/<目标视频内容的文件名>/<媒体段的索引编号>/<表示缺失的影片片段是该媒体段内的第几个影片片段的值>的结构。例如，当缺失的影片片段的时间戳（X-timestamp）为45时，请求的URI为/content1/2/16。

当成为应当开始对在S1702中接收到的媒体段进行重放的时刻时，重放部102对HTTP处理部101是否已经获取了与S1708的请求相对应的缺失部的影片片段进行判定（S1709）。当判定为已获取时（S1709中为“是”），重放部102利用所获取到的新的影片片段来对缺失的影片片段进行补全（替换为新的影片片段）（S1710）。在S1710的处理之后进入S1713。

另一方面，当判定为尚未获取到时（S1709中为“是”），重放部102对所接收到的媒体段内的影片片段数据的重放时间进行调整（S1711）。上述S1711的处理与S1707的处理相同。

之后，重放部102依次对在S1702中接收到的媒体段的各影片片段进行重放（S1712）。在S1712的处理之后进入S1714。

在S1713中，重放部102依次对在S1702中接收到的（或者在S1710中补全后的））媒体段的各影片片段进行重放，进入S1714。

在S1714中，重放部102对是否应当将重放后的媒体段储存到未图示的存储部中进行判定。即，对于重放部102，在从用户处经由操作部接收到表示应当对目标视频内容进行录像的指示时判定为应当进行储存，在未接收到表示应当进行录像的指示时判定为不应当进行储存。

当判定为应当对重放后的媒体段进行储存时（S1714中为“是”），在S1715中进行了后文阐述的数据补全处理之后，将重放后的媒体段储存到存储部中（S1716）。在S1716的处理之后，进入S1717。另一方面，当判定为不应当进行储存时（S1714中为“否”），进入S1717。

在S1717中，重放部102对在S1713中重放的媒体段是否为目标视频内容的最后一个媒体段进行判定。当判定为不是最后一个媒体段时（S1717中为“否”），返回S1701。另一方面，当判定为是最后一个媒体段时（S1717中为“是”），进入S1718。

在S1718中，HTTP处理部101解除与代理服务器200的连接状态，并结束对目标视频内容进行重放，进入S1719。

在S1719中，重放部102对是否对目标视频内容的各媒体段进行了录像进行判定。当判定为进行了录像时（S1719中为“是”），进行S1720的数据补全处理，结束处理。当判定为未进行录像时（S1719中为“否”），直接结束处理。

（关于数据补全处理）

下面参照图21对S1715及S1720中进行的数据补全处理的流程进行说明。图21是表示客户端装置100的数据补全处理的流程的流程图。

如图21所示，客户端装置100的重放部102对在S1713中重放的媒体段中是否存在缺失部进行判定（S1801）。当判定为存在缺失部时（S1801），虽然在S1708中已经发出了获取缺失部的影片片段的请求，但这里会对HTTP处理部101是否已经获取与该请求相对应的缺失部的影片片段进行判定（S1802）。当判定为已获取了缺失部的影片片段时（S1802中为“是”），进入S1803，当判定为尚未获取缺失部的影片片段时（S1802中为“否”），进入S1804。

在S1803中，HTTP处理部101对是否对缺损部进行补全进行判定。即，基于由用户预先经由未图示的操作部进行的设定（是在完成了整个目标视频内容的重放之后再进行补全的设定，还是在目标视频内容的重放过程中进行补全的设定），来判定是否对缺失部进行补全。

当判定为对缺失部进行补全时（S1803中为“是”），进入S1806。另一方面，当判定为不对缺失部进行补全时（S1803中为“否”），结束数据补全处理。

在S1804中，HTTP处理部101对是否应当获取缺失部的影片片段进行判定。这里，在被指示了应当不对缺损部进行补全就对媒体段进行重放时，HTTP处理部101判定为应当对缺失部的影片片段进行获取，当被指示了应当在对缺失部进行补全后再对媒体段进行重放时，HTTP处理部101判定为不应当对缺失部的影片片段进行获取。

当判定为应当对缺失部的影片片段进行获取时（S1804中为“是”），HTTP处理部101从代理服务器200获取缺失部的影片片段（S1805），进入S1806。另一方面，当判定为不应当对缺失部的影片片段进行获取时（S1804中为“否”），结束数据补全处理。

在S1806中，重放部102利用在S1708或S1806中获取到的新的影片片段来对缺失的影片片段进行补全，并结束数据补全处理。

以上对客户端装置100的动作进行了说明。由以上说明可知，当接收到的媒体段中存在缺失部时，客户端装置100从代理服务器200获取缺失部的影片片段。这里，在对包含缺失部的媒体段进行重放之前、对缺失部的影片片段进行获取的情况下，客户端装置100能够在对缺失部进行了补全的状态下，对媒体段进行重放。此外，在对包含缺失部的媒体段进行重放之后、再获取缺失部的媒体段的情况，通过在对缺损部进行了补全的状态下对媒体段进行储存，从而能够以完整的状态对目标视频内容进行录像。

（客户端装置100的动作之二）

接着，参照图22，说明客户端装置100在对目标视频内容进行重放的过程中、从用户处接收到重放中断指示时的客户端装置100的动作。

客户端装置100的重放部102在对目标视频内容进行重放的过程中（S1901），重放部102随时对是否从用户处接收到重放中断指示进行判定（S1902）。

当判定为接收到重放中断指示时（S1902中），HTTP处理部101生成在报头部中附加了“Connection：Close”报头的请求作为接下来应当发送给代理服务器200的请求（S1903）。

之后，HTTP处理部101将在S1903中生成的请求发送给代理服务器200（S1904）。

若接收到与在S1904中发送的请求相对应的响应，则当该响应的媒体段的重放结束的时刻，结束（中断）目标视频内容的重放（S1905）。

（配送系统1的动作例2）

接着，参照图24，对当客户端装置100发出目标视频内容的配送要求时，配送系统1中进行的动作的另一个具体例进行说明。

在该动作例中，假设在动作开始的时刻，客户端装置100-1～100-4这四台客户端装置100已经在从配送服务器300接收目标视频内容的多播配送，且新的客户端装置100-5发出了目标视频内容的配送要求。

此外，在该动作例中，从未图示的实时摄像机输入到配送服务器300的实时视频在被作为目标视频内容而实时地配送给客户端装置100。此外，由于输入到配送服务器300的实时视频会被记录到存储部302，之后，再进行实时配送，因此在实时配送结束之后，客户端装置100能够从配送服务器300接收目标视频内容的VOD配送。

图24是表示配送系统1的上述动作例的序列图。另外，图24中省略了对客户端装置100-2～100-4及代理服务器200-2～200-4的动作的描述。

代理服务器250的多播处理部253将目标视频内容的多播包52发送给代理服务器200（S40）。

接着，若客户端装置100-1向代理服务器200发送目标视频内容的媒体段的请求41（S41），则代理服务器200的HTTP处理部201使用在S40中接收到的多播包52来生成该媒体段的响应51，并向客户端装置100-1发送响应51（S42）。

接着，客户端装置100-5向代理服务器200-5发送目标视频内容的请求43（S43）。这里，请求43是用于要求对整个目标视频内容进行发送的请求。即，请求43不同于用于要求对目标视频内容中的指定媒体段进行发送的请求41。

接收了请求43的代理服务器200-5的HTTP处理部201将请求43中继给代理服务器250（S44）。

接收了请求43的代理服务器250的HTTP处理部251对请求的URI（“/content1/”）进行确认（S45）。即，对是否已经在对目标视频内容（文件名为“content1”的内容）进行多播配送（即，是否已存在属于目标多播组的通信装置）进行判定。这里，由于代理服务器200-1～200-4属于目标多播组，因此判定为正在进行多播配送。

判定为正在对目标视频内容进行多播配送的HTTP处理部251生成X-alternative-cast报头。然后，HTTP处理部251对缓存部252中已缓存完的最新的媒体段（假设索引值为t的媒体段）的响应消息51附加将<配送地址>设为目标多播组的地址的X-alternative-cast报头（S46）。

然后，HTTP处理部251将包含X-alternative-cast报头的响应消息51'发送给代理服务器200-5（S47）。

代理服务器200-5的HTTP处理部201将响应消息51'转换为响应消息51，并发送给客户端装置100-5（S48）。客户端装置100-5的重放部102对HTTP处理部101接收到的最新的媒体段（索引值为t的媒体段）的响应消息51进行重放。由此，客户端装置100-5开始对实时视频进行重放。

另一方面，代理服务器200-5的HTTP处理部201向代理服务器250发送多播接收要求（JOIN消息）42（S49）。

若代理服务器250的HTTP处理部251接收到JOIN消息42，则向代理服务器200-5发送对于JOIN消息42的响应（S50）。而且，HTTP处理部251将代理服务器200-5的地址作为属于目标多播组的地址来记录到多播组信息存储部254中（S51）。

之后，多播处理部253将索引值是t+1以后的媒体段的多播包52发送给代理服务器200-1～200-5（S52）。

另一方面，在S48中，接收了索引值为t的媒体段的响应消息51的客户端装置100-5的HTTP处理部101向代理服务器200-5发送要求下一个（索引值为t+1的）媒体段的请求41（S53），并接收与请求41相对应的响应51（索引值为t+1的媒体段）（S54）。

之后，客户端装置100-5对后续的媒体段（索引值为t+2、t+3、…）重复进行S53和S54的处理。

从以上对动作例2的说明中可知，当由代理服务器250进行目标视频内容的多播配送时，来自客户端装置100的目标视频内容的配送要求不会到达配送服务器300。

因此，即使对来自配送服务器300的目标视频内容的配送进行接收的客户端装置100的台数增加，也能抑制配送服务器300的处理负担、及配送服务器300和代理服务器250之间网络的负担。因此，能够高效地从配送服务器300向各客户端装置100配送目标视频内容。

此外，如上所述，客户端装置100也能够根据来自用户的指示，对目标视频内容进行重放，并同时进行录像。在上述动作例2中，在对客户端装置100-5进行设定，以对目标视频内容进行录像的情况下，客户端装置100-5中储存有目标视频内容中的索引值为t以后的媒体段。

因此，对于实时配送结束后被进行VOD配送的目标视频内容，客户端装置100-5通过发送对索引值为t以前的媒体段进行要求的请求41，并对t-1个响应51进行获取及储存，由此能够高效地对实时配送的整个目标视频内容进行录像。

（代理服务器250的优点）

如上所述，在配送系统1的代理服务器250中，当HTTP处理部251检测到从代理服务器200发送的要求目标视频内容的请求41时，代理服务器250代替配送服务器300向代理服务器200发送表示能够通过多播通信对目标视频内容进行发送的X-alternative-cast信息。此外，当多播处理部253从代理服务器200接收到JOIN消息42时，将代理服务器200登录到目标多播组中。然后，多播处理部253使用多播通信将缓存部252中的目标视频内容中继给登录在目标多播组中的各代理服务器200。

即，当被配送目标视频内容的客户端装置100为三台（接收配送要求的频度小于一定频度）时，如图12(a)所示，配送服务器300对同一内容的媒体段接收三次配送要求，且每次返回媒体段的响应。另一方面，如图12(b)所示，若被配送目标视频内容的客户端装置100达到（接收配送要求的频度在一定频度以上）规定的台数（四台），则之后配送服务器300对同一内容的媒体段只需进行一次接收配送要求并返回媒体段响应的处理即可。因此，抑制了配送服务器300的处理负担，及配送服务器300和代理服务器250之间网络的负担。

此外，如图12(a)所示，当被配送目标视频内容的客户端装置100为三台（接收配送要求的频度小于一定频度）时，代理服务器250也对同一内容的媒体段接收三次配送要求，且每次返回媒体段的响应。另一方面，如图12(b)所示，若被配送目标视频内容的客户端装置100达到（接收配送要求的频度在一定频度以上）规定的台数（四台），则代理服务器250能够对媒体段进行多播配送。即，代理服务器250为了将同一内容的媒体段配送给四台客户端装置100而发送的数据的数据量是一个媒体段的数据量。因此，抑制了干线网络、特别是代理服务器250附近区域的频带负载。

而且，如上所述，媒体段是以MIME多部分格式从配送服务器300发送到代理服务器250，上述MIME多部分格式的各部分为影片片段，但代理服务器250将一个部分（影片片段）的全部或部分数据储存到一个多播包中来进行多播配送。因此，即使在对多个多播包进行传输的过程中丢失了一个多播包，该丢失也只会对一个影片片段产生影响。因此，能够使客户端装置100稳定地对视频内容进行重放。

(实施方式2)

在本实施方式中，代理服务器200通过发送IGMP的JOIN消息及LEAVE消息，来进行多播组的加入及退出。

IGMP是在IP广播（IP多播）中，多媒体路由器在进行多播数据的路由处理时所使用的协议。

通常，多媒体路由器利用IGMP来掌握是否存在加入到多播组中的主机设备。多媒体路由器对加入到多播组中的主机设备发送多播数据。因此，主机设备需要向多媒体路由器发送要求加入到该多播数据的发送目的地、即多播组的IGMP JOIN消息，来接收某个多播数据。

此外，主机设备需要每隔一定期间对从多媒体路由器发送的询问（IGMPQUERY）进行应答（发送IGMP REPORT），以继续接收多播数据。而且，主机设备需要发送要求从该多播数据的发送目的地、即多播组中退出的IGMPLEAVE消息，以不再接收多播数据。

因此，多媒体路由器需要进行以下各种处理：即，使主机设备加入多播组的处理、询问的发送处理、使主机设备从多播组中退出的处理等。

其中，使主机设备从多播组中退出的处理需要一定时间。这是因为，当多媒体路由器接收到IGMP LEAVE消息时，会通过询问来对是否存在应当发送多播数据的其它主机设备进行确认，之后再停止多播数据的发送。

因此，在主机设备发送IGMP LEAVE消息后的一段时间内，仍会对主机设备发送多播数据。

因此，若主机设备在接收某一视频内容的多播配送时进行了信道切换，则在一段时间内，不仅会向其发送信道切换后的视频内容的多播数据，也会向其发送信道切换前的视频内容的多播数据。即，由于在多播配送中通常会对一定的带宽进行补偿，因此，存在以下问题：即，在信道切换时会对网络的频带带来没必要的压力。

这里，为了避免对网络的频带造成压力的问题，能采用以下方式：即在不对主机设备发送信道切换前的视频内容的多播数据之后，再使主机设备加入到作为信道切换后的视频内容的发送目的地的多播组中。然而，在这种情况下，从停止重放信道切换前的视频内容、到开始重放切换后的视频内容的期间中会产生其它问题，即延迟。

下面，参照图25对本实施方式中配送系统1的动作例进行如下的说明。另外，在本实施方式中，假设在客户端装置100-1中对文件名为“content1”的视频内容（也称为“切换前视频内容”）进行重放的过程中，从用户处发出了将应当重放的视频内容切换为文件名为“content2”的视频内容（也称为“切换后视频内容”）的信道切换的指示。此外，假设在发出信道切换的指示之前，代理服务器250已在对其它客户端装置100进行切换后视频内容的多播配送。

图25是表示上述动作例的序列图。如实施方式1所示，对于从客户端装置100-1接收了切换前视频内容的请求41的代理服务器200，会从代理服务器250接收到响应51a，并向代理服务器200发送IGMP JOIN消息，该IGMP JOIN消息是要求加入到对切换前视频内容进行多播配送的发送目的地的多播组（称为“切换前多播组”）的消息（S50）。

接收了IGMP JOIN消息的多播处理部253开始向代理服务器200发送切换前视频内容的多播包52（S51）。之后，利用与实施方式1相同的方法（重复下面S51～S54的处理），使得切换前视频内容的响应51从代理服务器200-1被配送到客户端装置100-1。

即，代理服务器200-1的多播处理部203对在S51中配送的多个多播包52进行汇总，并转换为媒体段的响应51（S52），缓存到缓存部202中（S53）。

另一方面，若客户端装置100-1向代理服务器200-1发送对切换前视频内容的媒体段进行要求的请求41，则HTTP处理部201从缓存部202中读取相对应的响应51（S54），并发送给客户端装置100-1。

假设在对上述S51～S54的处理进行重复的期间（即，在客户端装置100-1对切换前视频内容进行重放的过程中），客户端装置100-1经由操作部从用户处接收了上述信道切换的指示。

接收了信道切换指示的客户端装置100-1的HTTP处理部101向代理服务器200发送切换前视频内容的请求41'（即，附加了“Connection：Clo se”报头的请求）（S55）。

HTTP处理部101同时向代理服务器200发送切换后视频内容的请求41（S56）。

若代理服务器200-1的HTTP处理部201在S56中新接收到切换后视频内容的请求41，则对是否接收了切换前视频内容的请求41'进行判定。这里，由于在S55中接收了请求41'，因此判定为请求URI产生了变更（S57）。由于判定为请求URI产生了变更，因此HTTP处理部201将请求41中继给代理服务器250（S60）。

另一方面，由于HTTP处理部201在S56中接收到请求41'，因此多播处理部203向代理服务器250发送要求从切换前多播组中退出的IGMP LEAVE消息（S58）。

代理服务器250的多播处理部253开始进行使代理服务器200-1从切换前多播组中退出的处理（S59）。如上所述，由于该处理需要一定的时间，因此在一段时间内，仍会向代理服务器200-1发送切换前视频内容的多播包52。对于这种情况，代理服务器200-1将舍弃多播包52。

另一方面，接收了请求41的代理服务器250的HTTP处理部251将请求41中继给配送服务器300（S61）。

由于已经在对切换后视频内容进行多播配送，因此，若HTTP处理部251从配送服务器300接收到与请求41相对应的响应51，则对响应消息51附加将<配送地址>设为切换目标多播组的地址的X-alternative-cast报头（S62），并生成响应51'。

之后，HTTP处理部251向代理服务器200-1发送切换后视频内容的响应51'（S63）。

接收了响应51'的代理服务器200-1的HTTP处理部201向客户端装置100-1发送切换后视频内容的响应51（S64）。从该时刻起，开始在客户端装置100-1中对切换后视频内容进行重放。

然后，多播处理部203向代理服务器250发送要求加入切换后多播组的IGMP JOIN消息。由此，切换后视频内容的多播包52被配送到代理服务器200中。这里，对于多播处理部203向代理服务器250发送要求加入切换后多播组的IGMP JOIN消息的时刻，优选为多播处理部203判定出应当发送IGMPJOIN消息的时刻。具体而言，优选的，从多播处理部203不再对切换前视频内容的多播包52进行接收及舍弃起、经过一定时间之后，判定为应当发送IGMP JOIN消息，在经过上述一定时间之前的时刻判定为不应当发送IGMPJOIN消息。

另外，当HTTP处理部201在S56中接收到切换后视频内容（第二内容）的请求41时，也可以对应当发送给客户端装置100-1的切换前视频内容（第一内容）的响应51中附加“Connection：Close”报头，之后，将其发送给客户端装置100-1。对于这种情况，在刚发送完响应之后的时刻，解除为了对切换前视频内容进行中继、而在客户端装置100-1和代理服务器200之间建立的连接状态。

如上所述，在本实施方式的配送系统1中，若在进行信道切换时，客户端装置100向代理服务器200发送切换前视频内容的请求41'（包含“Connection：Close”报头的HTTP请求）和切换后视频内容的请求41，则能够立即开始对切换后视频内容进行重放。此外，在信道切换期间也不会对客户端装置100和代理服务器200之间的网络频带造成压力。

因此，与通过多播通信来对视频内容进行接收（即，在信道切换时，向多媒体路由器发送要求从切换前多播组中退出的IGMP LEAVE消息）的现有的客户端装置相比，配送系统1的客户端装置100可起到如下效果：能够兼顾迅速重放切换后视频内容和抑制客户端装置100侧的网络频带负载。

此外，由于能够迅速重放切换后视频内容，因此当切换后视频内容是已经在进行实时配送的实时视频的内容时，能够使用户在较早的时刻收看到实时视频。

而且，在例如通过由H.264规定的压缩方式来对视频内容进行压缩编码的情况下，对于本实施方式的客户端装置100和上述现有的客户端装置，这两者从进行信道切换起到开始对切换后视频内容进行重放为止所需的时间之差可能会进一步变大。

即，当视频内容被压缩编码时，例如，用户无法收看到视频，直至客户端装置获取经编码而得的关键帧的数据，并对其进行解码。在IP多播配送中，可能会在传输过程中发生多播包的缺失。即，对于像现有的那样、客户端装置直接接收切换后视频内容的多播包的情况，多播包的缺失所造成的关键帧的缺少可能会导致延迟开始对切换后视频内容进行重放。

另一方面，如上所述，在本实施方式的客户端装置100中，在从进行信道切换起、到开始对切换后视频内容进行重放为止的期间，客户端装置100和配送服务器300之间始终利用可靠性高的HTTP通信来进行通信。即，在开始对切换后视频内容进行重放之前，从配送服务器300向客户端装置100配送切换后视频内容的过程中不会发生关键帧的缺少。因此，对于本实施方式的客户端装置100，即使在切换后视频内容被压缩编码的情况下，也能够可靠且迅速地开始切换后视频内容的重放。

另外，优选配送服务器300或代理服务器250能够对X-Transport-Speed报头进行处理，客户端装置100向代理服务器200发送包含X-Transport-Speed报头的HTTP请求。X-Transport-Speed报头是用于向HTTP服务器要求以在报头中指定的值所对应的传输速度、来对数据进行传输的报头。

对于这种情况，客户端装置100能够通过将X-Transport-Speed报头设定为较大的值来高速地对切换后视频内容的数据进行接收。因此，即使是切换后视频内容的数据的起始部分中不包含关键帧的情况，客户端装置100也能够较迅速地开始重放切换后视频内容。

另外，上文中，以代理服务器250起到多媒体路由器的作用（即，在代理服务器200和代理服务器250之间的通信路径上不存在多媒体路由器）为前提对本实施方式进行了说明。然而，也可以设想干线网络500是在代理服务器200和代理服务器250之间设置有多媒体路由器的网络。对于这种情况，代理服务器200向位于其与代理服务器250的通信路径上的多媒体路由器中、最靠近代理服务器200的多媒体路由器发送IGMP JOIN、IGMP LEAVE等通知。

(附记事项1)

在实施方式1及2中，假设了客户端装置100以媒体段为单位来发出目标视频内容的请求，但客户端装置100也能以目标视频内容整体为单位来发出请求。对于这种情况，代理服务器250将从代理服务器200接收到的请求转换为以媒体段为单位的请求。

例如，当HTTP处理部251接收到要求目标视频内容整体的请求（开头以“GET/content1/1HTTP/1.1”为起始的请求消息）时，生成开头以“GET/content1/1HTTP/1.1”为起始的请求41，将其发送该给配送服务器300，并接收相应的响应。

之后，HTTP处理部251生成以“GET/content1/t/HTTP/1.1”为起始的请求41，将其发送给配送服务器300，并接收相应的响应，对于2以上的t，一边使t递增，一边重复进行上述处理，直至接收到整个目标视频内容。

(附记事项2)

在实施方式1及2中，假设了当代理服务器250从代理服务器200接收到请求41时，若未在进行多播配送，则将请求41中继给配送服务器300，但在未在进行多播配送的状态下也可以使代理服务器250按如下方式动作。

即，对于代理服务器250从代理服务器200接收到请求41时、缓存部252中缓存有与请求41相对应的响应51的情况，也可以将缓存的响应51（或基于响应51生成得到的响应51'）发送给代理服务器200。

(附记事项3)

在实施方式1及2的说明中，各装置的IP地址是以IPv4规定的地址，但并不限于此。即，各装置的IP地址也可以是以IPv6规定的地址。对于这种情况，代理服务器250可以使用将由Ipv6构成的网络规定为对象的多播配送方式来进行多播配送。

(附记事项4)

实施方式1中，假设进行以下处理：即，客户端装置100对接收到的媒体段是否存在缺失部进行判定，当判定为存在缺失部时，对缺失部的数据进行获取（即，发出要求配送缺失部的影片片段（或包含缺失部的媒体段）），但该处理也可以由客户端装置100的代理服务器200来进行。此外，代理服务器200也可以利用数据包再发送技术、FEC（Forward Error Correction：前向纠错）等来获取缺失部的数据。

由此，当代理服务器200是多个客户端装置100的代理服务器时，相比各客户端装置100分别获取缺失部的数据，能够更高效地获取缺失部的数据。

(附记事项5)

在实施方式1及2中，对于在客户端装置100和代理服务器200之间发生网络故障等情况，从客户端装置100发送的请求41可能暂时不能到达代理服务器200，或从代理服务器200发送的响应51可能暂时不能到达客户端装置100，从而可能会在一定期间内无法适当地接收视频内容。

对于上述情况，在上述一定期间内，代理服务器200中缓存的响应51的累积量可能会超过缓存部202的存储容量，可能会舍弃之后从代理服务器250多播配送过来的多播包52。

然而，即使在上述情况下，当在上述一定期间后，从客户端装置100接收到对未缓存在缓存部202中的响应51进行要求的请求41时，代理服务器200也能够通过对请求41进行中继，来从代理服务器250中获取响应51。此外，由于客户端装置100能在上述一定期间内掌握无法获取哪些媒体段，因此能够重新获取所有无法在上述一定期间内获取到的媒体段。

另外，对于所提供的视频内容是包括基本层和扩展层的层级化的内容（可扩展内容）的情况，或所提供的视频内容是具有多个品质（多个不同的比特率、分辨率或帧率）的内容的情况(例如13段和1段)，可以使代理服务器200进行如下的动作来抑制缓存部202中缓存的数据的累积量超过缓存部202的存储容量。

即，对于代理服务器200的多播处理部203，当判定为缓存部202中缓存的数据量超过了一定的阈值时，可以仅从由多播包52构成的层级化的媒体段中提取一部分层级的数据来转换成响应消息，并缓存在缓存部202中。例如，当由多播包52构成的媒体段包括基本层和扩展层时，可以将仅提取了基本层后得到的响应消息缓存到缓存部202中。

而且，对于多播处理部203，当判定为缓存部202中缓存的数据量超过了一定的阈值时，可以仅从由多播包52构成的、包括多个品质的数据的媒体段中提取一部分品质的数据来转换成响应消息，并缓存在缓存部202中。例如，当由多播包52构成的媒体段包括1段（one seg）的数据和13段的数据时，可以将仅提取了1段的数据后得到的响应消息缓存到缓存部202中。

另外，对于这种情况，代理服务器200的HTTP处理部201对缓存部202中缓存的响应51进行读取，并且将表示所能提供的层级、品质（比特率）等的信息附加到响应51的报头部或多部分的各部分中，由此能够改变客户端装置100应当获取的层级（或品质）。

（程序、存储介质）

客户端装置100、代理服务器200、250及配送服务器300（300'）的各个模块既可以利用在集成电路（IC芯片）上形成的逻辑电路来以硬件方式实现，也可使用CPU（Central Processing Unit：中央处理器）来以软件方式实现。

对于后者的情况，客户端装置100、代理服务器200、250及配送服务器300包括：对实现各个功能的程序的命令进行执行的CPU，储存上述程序的ROM（Read Only Memory：只读存储器），展开上述程序的RAM（Random AccessMemory：随机存储器），储存上述程序及各种数据的存储器等存储装置（记录介质）等。而且，本发明的目的也可以通过以下方式来实现：将以计算机能读取的方式记录有实现上述功能的软件即客户端装置100、代理服务器200、250及配送服务器300的控制程序的程序代码（执行形式程序、中间代码程序、源程序）的记录介质提供给上述客户端装置100、代理服务器200、250及配送服务器300，该计算机（或CPU、MPU）读出并执行记录介质中记录的程序代码。

作为上述记录介质，能够使用例如，磁带或盒式磁带等带类、包含软盘（注册商标）／硬盘等磁盘和CD-ROM／MO／MD／DVD／CD－R等光盘的盘片类、IC卡（包含存储卡）／光卡等卡类、掩模ROM／EPROM／EEPROM／闪存ROM等半导体存储器类、或者PLD（Programmable logic device：可编程序逻辑设备）和FPGA（Field Programmable Gate Array：现场可编程门阵列）等逻辑电路类等。

此外，也可以经由通信网络将上述程序代码提供给客户端装置100、代理服务器200、250及配送服务器300。该通信网络能传输程序代码即可，没有特别限定。例如，能够利用互联网、内联网、外联网、LAN、ISDN、VAN、CATV通信网、虚拟专用网（Virtual Private Network）、电话线网、移动体通信网、卫星通信网等。此外，构成该通信网络的传输介质也只要是能传输程序代码的介质即可，并不限于特定的结构或种类。例如，既可以利用IEEE1394、USB、电力线输送、电缆TV线路、电话线、ADSL（AsymmetricDigital SubscriberLine：非对称数字用户线路）线路等有线线路，也可以利用IrDA和遥控器等红外线、Bluetooth（注册商标）、IEEE802.11无线、HDR（High Data Rate：高速数据传送）、NFC（NearField Communication：近距离无线通信）、DLNA（Digital Living Network Alliance：数字生活网络联盟）、移动电话网、卫星线路、地面波数字网等无线。

另外，应当认为这里所揭示的实施方式的各个方面都是举例表示，而不是限制性的。应当认为本发明的范围并不由上述说明表示，而是由权利要求的范围表示，包含与权利要求的范围同等的意义及范围内的所有变更。

如上所述，优选的，在本发明的代理服务器中，存在多个上述通信装置，上述发送装置能够根据来自上述通信装置的要求对多个不同的内容进行发送，仅在代理服务器检测到一定期间内、一定数量以上的通信装置就同一内容发送了上述第一要求时，上述发送单元向上述通信装置发送上述信息。

根据上述结构，当本发明的代理服务器就同一内容在短时间内通过单播通信从多个通信装置接收到表示应当发送内容的要求时，能够通过多播通信将该内容中继给上述多个通信装置。此外，对于同一内容，在仅从少量的通信装置通过单播通信而接收到表示应当发送内容的要求时，通过单播通信将该内容中继给上述少量的通信装置。

因此，上述代理服务器可以进一步起到以下效果：能够根据网络的频带负载的状况来良好地维持以下两者之间的平衡，即，利用多播通信来抑制网络的频带负载，以及利用单播通信来进行稳定的传输。

优选的，上述发送装置采用以下结果：即，根据来自上述通信装置的要求，依次对通过将上述内容分割成多份得到的各分割数据进行发送，且上述代理服务器的上述中继单元依次将上述存储部中缓存的各分割数据中继给上述通信装置。

根据上述结构，代理服务器可以进一步起到能够更高效地进行多播通信的效果。

优选的，在上述代理服务器中，上述内容是视频内容，且上述视频内容包括多个影片片段。

根据上述结构，上述代理服务器可以进一步起到如下效果：可以对重放上述内容的重放装置中的上述视频内容进行精细的重放控制。

优选的，在上述代理服务器中，从上述发送装置发送的上述视频内容是各部分包括一个上述影片片段的多部分格式的数据。

根据上述结构，在从上述代理服务器对上述视频内容进行传输的过程中，即使是缺失了一个部分的数据的情况，上述通信装置无法接收的影片片段也只是一个。

因此，代理服务器可以进一步起到如下效果：能够在短时间内使上述通信装置获取缺失的数据。

优选的，在上述代理服务器中，各部分不仅包括上述一个影片片段，还包括表示对上述视频内容进行重放的重放装置应当在第几个顺位对上述多个影片片段中的该影片片段进行重放的值。

根据上述结构，上述代理服务器可以进一步起到如下效果：使接收了多部分格式的数据的通信装置判定所接收的各部分中是否包含上述表示应当在第几个顺位进行重放的值，由此能够使其容易地掌握缺失的影片片段。

优选的，对于上述代理服务器，上述中继单元通过多播通信将多个包发送给各通信装置，由此来向各通信装置中继应当进行中继的视频内容，且上述多个包分别包括一个影片片段的整体或一部分数据。

根据上述结构，即使在上述代理服务器通过多播通信发送给通信装置的传输过程中、M个包中缺失了N个包的情况下，上述通信装置也能够接收M-N个以上的影片片段。

因此，上述代理服务器可以进一步起到如下效果：即使对于传输过程中缺少了相当数量的包，也能够使上述通信装置在短时间内获取缺失的数据。

另外，如下所述的代理服务器也包含在本发明的范畴内：作为对上述代理服务器（发送侧代理服务器）发送上述第一要求的上述通信装置而发挥作用的代理服务器，包括：根据从对上述内容进行重放的重放装置接收到的上述第一要求，来将该内容中继给上述重放装置的中继单元；以及当代理服务器通过对从上述重放装置接收到的上述第一要求进行中继而接收到上述信息时，对是否应当将上述第二要求发送给上述发送侧代理服务器进行判定的第一判定单元。

根据上述结构，对于上述代理服务器，仅当上述第一判定单元判定为应当将上述第二要求发送给上述发送侧代理服务器时，通过多播通信从发送侧代理服务器接收内容。

因此，上述代理服务器可以进一步起到如下效果：能够根据状况来适当选择是通过多播通信抑制网络频带负载，还是通过单播通信来确保稳定的传输。

此外，优选的，对于上述代理服务器，上述中继单元在向上述重放装置中继上述内容的期间，保持为了对该内容进行中继而与上述重放装置建立的连接状态，对于在向上述重放装置中继第一内容期间中、接收到表示应当发送第二内容的第一要求的情况，解除为了对上述第一内容进行中继而与上述重放装置建立的连接状态。

根据上述结构，对于上述代理服务器，当上述重放装置将进行重放的内容从上述第一内容切换到上述第二内容时，能够立即结束与上述第一内容有关的处理。

因此，上述代理服务器可以进一步起到如下效果：能够降低上述重放装置对上述内容进行切换所导致的处理负担。

此外，优选的，对于上述代理服务器，进一步包括：当在向上述重放装置中继上述第一内容期间中、接收到表示应当发送上述第二内容的第一要求时，向上述发送侧代理服务器发送将本装置从被中继上述第一内容的各通信装置所属的多播组中解除的要求的发送单元；以及对从不再向本装置发送上述第一内容起、是否经过了一定时间进行判定的第二判定单元；当上述第二判定单元判定为经过了一定时间时，上述第一判定单元判定应当向上述发送侧代理服务器发送上述第二要求。

根据上述结构，上述代理服务器可以进一步起到如下效果：能够抑制代理服务器间网络的无用的频带负载，上述负载的产生原因在于，在上述重放装置将进行重放的内容从上述第一内容切换为上述第二内容的情况下，会从上述发送侧代理服务器通过多播通信接收上述第一内容及上述第二内容两者。

另外，本发明也能够实现包括上述各代理服务器、上述重放装置和上述发送装置的通信系统。另外，以下内容也包含在本发明的范畴内：用于使本发明所涉及的代理服务器进行动作的程序、即特征在于使计算机作为上述各单元来发挥作用的中继控制程序；以及记录有该中继控制程序的、计算机可读取的记录介质。

工业上的实用性

本发明所涉及的通信系统能够作为视频配送系统而广泛利用。

标号说明

100   客户端装置（重放装置、通信装置）

100-1、100-2   客户端装置

110   HTTP处理部

120   重放部

200   客户端装置的代理服务器（通信装置）

200-1、200-2   客户端装置的代理服务器

201   HTTP处理部（中继单元）

202   缓存部

203   多播处理部（发送单元、第一判定单元、第二判定单元）

250   配送服务器的代理服务器

251   HTTP处理部（发送单元）

252   缓存部（存储部）

253   多播处理部（登录单元、中继单元）

254   多播组信息存储部

300   配送服务器

301   HTTP处理部

302   存储部

Claims (17)

1.一种代理服务器，根据来自通信装置的要求，将从发送装置发送的内容缓存到存储部中，并将该内容中继给所述通信装置，其特征在于，包括：

发送单元，当检测到所述通信装置通过单播通信向所述发送装置发出了表示应当发送内容的第一要求时，该发送单元向所述通信装置发送表示该代理服务器能够代替所述发送装置来通过多播通信对该内容进行发送的信息；

登录单元，当从所述通信装置接收到表示应当使用多播通信来发送所述内容的第二要求时，该登录单元将所述通信装置登录到多播组中；以及

中继单元，该中继单元使用多播通信将缓存在所述存储部中的该内容中继给登录在所述多播组中的各通信装置。

2.如权利要求1所述的代理服务器，其特征在于，

存在多个所述通信装置，

所述发送装置能够根据来自所述通信装置的要求对多个不同的内容进行发送，

仅在检测到在一定期间内、一定数量以上的通信装置就同一内容发送了所述第一要求时，所述发送单元向所述通信装置发送所述信息。

3.如权利要求1或2所述的代理服务器，其特征在于，

所述第一要求是HTTP请求消息，

所述发送单元对将所述信息作为报头信息包含在内的HTTP响应消息进行发送，

所述报头信息包括表示所述多播组的地址的值。

4.如权利要求1至3中任一项所述的代理服务器，其特征在于：

所述发送装置根据来自所述通信装置的要求，来依次对通过将所述内容分割成多份得到的各分割数据进行发送，

所述中继单元依次将缓存在所述存储部中的各分割数据中继给所述通信装置。

5.如权利要求1至4中任一项所述的代理服务器，其特征在于：

所述内容是视频内容，

所述视频内容由多个影片片段构成。

6.如权利要求5所述的代理服务器，其特征在于，

从所述发送装置发送的所述视频内容是各部分包括一个所述影片片段的、多部分格式的数据。

7.如权利要求6所述的代理服务器，其特征在于，

各部分不仅包括所述一个影片片段，还包括表示对所述视频内容进行重放的重放装置应当在第几个顺位对所述多个影片片段中的这一个影片片段进行重放的值。

8.如权利要求5至7中任一项所述的代理服务器，其特征在于：

所述中继单元通过多播通信将多个包发送给各通信装置，由此将应当进行中继的视频内容中继给各通信装置，

所述多个包分别包括一个影片片段的整体或一部分的数据。

9.一种代理服务器，作为向发送侧代理服务器发送所述第一要求的所述通信装置发挥作用，该发送侧代理服务器是权利要求1至8中任一项所述的代理服务器，其特征在于，包括：

中继单元，该中继单元根据从对所述内容进行重放的重放装置接收到的所述第一要求来将该内容中继给所述重放装置；以及

第一判定单元，当对从所述重放装置接收到的所述第一要求进行中继并由此接收到所述信息时，该第一判定单元对是否应当将所述第二要求发送给所述发送侧代理服务器进行判定。

10.如权利要求9所述的代理服务器，其特征在于，

所述中继单元在向所述重放装置中继所述内容的期间，保持为了对该内容进行中继而与所述重放装置建立的连接状态，

当在将第一内容中继给所述重放装置期间中、接收到表示应当发送第二内容的第一要求时，所述中继单元解除为了对所述第一内容进行中继而与所述重放装置建立的连接状态。

11.如权利要求10所述的代理服务器，其特征在于，还包括：

发送单元，当在将所述第一内容中继给所述重放装置的期间、接收到表示应当发送所述第二内容的第一要求时，该发送单元向所述发送侧代理服务器发送要求，该要求表示将本装置从会被中继所述第一内容的各通信装置所属的多播组中解除；以及

第二判定单元，该第二判定单元对从不再向本装置发送所述第一内容起、是否经过了一定时间进行判定，

当所述第二判定单元判定为经过了一定时间时，所述第一判定单元判定为应当向所述发送侧代理服务器发送所述第二要求。

12.一种通信系统，其特征在于，包括：重放装置，该重放装置对所述内容进行重放；如权利要求1至8中任一项所述的代理服务器；如权利要求9至11中任一项所述的代理服务器；以及所述通信装置。

13.一种中继方法，根据来自通信装置的要求，将从发送装置发送的内容缓存到存储部中，并将该内容中继给所述通信装置，其特征在于，包括：

发送过程，在该发送过程中，当检测到所述通信装置通过单播通信向所述发送装置发出了表示应当发送内容的第一要求时，向所述通信装置发送表示该代理服务器能够代替所述发送装置来通过多播通信对该内容进行发送的信息；

登录过程，在该登录过程中，当从所述通信装置接收到表示应当使用多播通信来发送所述内容的第二要求时，将所述通信装置登录到多播组中；以及

中继过程，在该中继过程中，使用多播通信将缓存在所述存储部中的该内容中继给登录在所述多播组中的各通信装置。

14.一种中继控制程序，该程序使权利要求1至8中任一项所述的代理服务器进行动作，其特征在于，该程序用于使计算机发挥上述各单元的功能。

15.一种记录介质，其特征在于，该记录介质记录有权利要求14所述的中继控制程序，并能由计算机读取。

16.一种中继控制程序，该程序使权利要求9至11中任一项所述的代理服务器进行动作，其特征在于，该程序用于使计算机发挥上述各单元的功能。

17.一种记录介质，其特征在于，该记录介质记录有权利要求16所述的中继控制程序，并能由计算机读取。

Images