对等内容分发网络、方法及管理器与流程

本发明大体上涉及一种提供媒体合规引擎的内容分发网络以及相关联的方法。根据本发明的媒体合规引擎借助于本地网关服务器进行操作，本地网关服务器利用对等网络和多个数据来源(云)以优化媒体的分发以及使报告过程流线化。根据本发明的媒体合规引擎将来自流提供商的请求与经优化的数据源和网络进行匹配。通过这么做，媒体合规引擎可以使带宽消耗、许可及报告成本最小化。

技术实现要素：

本发明提供了一种对等内容分发网络(CDN)，该CDN可以被添加至任意现有的标准内容分发网络或者服务器配置，而无需对后端系统进行任何改变。当最终用户在客户端机器上安装本地对等网关服务器时，创建根据本发明的对等CDN。网关服务器经由加密或未加密的连接(例如，HTTP、HTTPS、安全套接字、和/或套接字)接收来自媒体消费客户端的一个或多个请求。

本地网关服务器作为对等网络上的对等体(peer)并且具有加密的缓存器，该加密的缓存器用于对被分发至其他对等体的数据或者被本地分发至数据消费客户端的数据进行存储。本地网关服务器还从相关的远程数据源(例如，服务器或其他CDN)拖拉(pull)资源。消费客户端仅需要将单个请求传递至网关服务器，以及网关服务器独立于客户端无关而对资源和网络连接进行管理。这种类型的设置使得不仅能够将媒体分发至独立的桌面应用，而且能够将媒体分发至具有标准网页浏览器能力(例如，HTTP、HTTPS和/或套接字)的浏览器、媒体播放器和移动应用。

本发明提供了一种可以从本地机器上的客户端接收通信的对等(P2P)网关服务器。该通信或请求可以被格式化为定向在本地网关服务器处的标准HTTP请求，该本地网关服务器可以在本地域名下进行注册。可以想到，如果创建了引用网关服务器所驻留的保留端口的新传输协议，则可以对一个或多个请求不同地进行格式化。在这种情况下，请求将被略微不同地格式化(即，没有HTTP前缀)。

本发明提供了一种资源名称服务器(RNS)，该RNS将资源URL和资源位置(即，IP地址)进行缓存，并且利用机器地址来解析资源请求。不相匹配的媒体类型的通用过程或方法可以是如下所示。

1、客户端向网关服务器发送对于资源的请求。

2、然后，网关服务器将该请求发送至RNS，以使用资源地址来解析该资源请求。

3、一旦该资源请求与最优的(代价最低的)资源位置相匹配，则将资源位置数据返回至网关服务器。

4、然后，网关将对于资源数据的请求发送至合适的机器或服务器群集。

5、然后，机器或服务器群集通过将所请求的数据提供至位于本地机器上的网关服务器来进行响应。

6、网关过程对该数据进行组织并验证，然后将资源分发至本地机器上的客户端。

读者将注意的是，在传统的客户端-服务器关系中，客户端向服务器请求数据并且服务器根据客户端请求来分发数据。在传统的未被管理的对等网络中，每个对等体可以既作为服务器(即，数据的分发方)又作为客户端(即，数据的接收方)。在未被管理环境中，对于数据的请求从一个对等体传递至另一个对等体，直到文件被定位为止。

被管理的对等网络具有集中式服务器，该集中式服务器对资源进行索引。这样的网络中的对等体报告并注册它们的可用性，从而使得资源定位更容易并且更迅速。在混合系统中，对等网络是用在集中式数据源/索引服务器旁边的，以提供低成本的对等体分发，但还提供集中式数据源的连贯性和速度，并且以便如被管理的对等网络那样加快资源分发。在这种情况下，数据来源服务器和对等体的混合对数据进行分发。

根据本发明，客户端是独立的客户端，以及数据请求来源于独立的客户端，并且由独立的客户端(浏览器、桌面或移动应用)消耗。与上文作为前序的网络不同，对于数据的请求并不是利用对等体来发起，而是如在传统的客户端服务器关系中的那样利用独立的客户端来发起。

网关服务器接收请求，然后使用资源名称服务器(即，资源索引服务器)来解析对于资源的请求。RNS以资源位置(IP地址)来作出响应，该资源位置可以是资源来源或对等体。假定网络是数据来源不可知的，对等体数据并不由中央数据服务器所管理，而是当该请求在网关服务器处被传递并缓存时，在RNS上对对等体数据进行索引。

因此，在这样的网络中，数据源与资源索引服务器分离，从而使得独立的客户端所作出任何对于数据的请求都能够从数据来源或对等(P2P)网络来组成，因为当从独立的客户端发送请求时，P2P网络内的数据被缓存。

附图说明

根据下面的关于本发明的图示的简要描述的考虑，本发明的其他特征将变得更加明显，在附图中：

图1是数据文件的分片布置的概略描绘，该数据文件包括子流数据包的各行和验证数据包的各列；

图2是根据本发明的系统概述的第一概略描绘，示出了位于服务器群集的云与资源名称服务器(resource name server)中间的网关服务器；

图3是根据本发明的系统概述的第二概略描绘，示出了位于服务器群集的云与资源名称服务器中间的网关服务器；

图4是域名服务器系统概述的概略描绘；

图5是资源名称服务器系统概述的概略描绘；

图6是非插件安全措施概述的概略描绘；

图7是传统的客户端-服务器关系的概略描绘，通过该客户端-服务器关系，客户端请求数据并且服务器分发数据；

图8是对等的未被管理的网络概述的概略描绘，通过该对等的未被管理的网络，每个对等体可以既用作服务器又可以用作客户端，其中，对于数据的请求从一个对等体传送至另一个对等体，直到文件被定位为止；

图9是对等的被管理的网络的概述的概略描绘，其中，集中式服务器对资源进行索引，并且其中，各对等体报告并注册它们的可用性；

图10是对等集中式混合网络概述的概略描绘，对等网络通过该对等集中式混合网络而被用在集中式数据源/索引服务器旁边以提供低成本的对等体分发但提供集中式数据源的连贯性和速度；

图11是对等网关服务器网络概述的概略描绘；

图12是如何经由本地服务器和浏览器来构建安全连接的概略描绘；

图13是如何经由插件来验证本地网关服务器的概略描绘；

图14是使用初始请求和无文件匹配的资源索引布置的概略描绘；

图15是使用后续请求和无文件匹配的资源索引布置的概略描绘；

图16是使用初始请求的逐步的云索引布置的概略描绘；

图17是本地资源索引布置的概略描绘；

图18是第一被索引的资源请求处理布置的概略描绘；

图19是第二被索引的资源请求处理布置的概略描绘；

图20是第三被索引的资源请求处理布置的概略描绘；

图21是第四被索引的资源请求处理布置的概略描绘；

图22是分许可(sub-licensing)的云分发布置的概略描绘；

图23是分许可的对等分发布置的概略描绘；

图24是根据本发明的用于请求在移动设备上播放歌曲的流提供商的第一概略描绘；

图25是根据本发明的用于请求在移动设备上播放歌曲的流提供商的第二概略描绘；

图26是根据本发明的网关服务器增强系统概述的概略描绘；

图27是根据本发明的预先记录的媒体队列布置的概略描绘；

图28是根据本发明的流分割布置的概略描绘；

图29是根据本发明的MP3文件结构的概略描绘，示出音频流的帧头和音频帧；

图30是用于通过互联网对无线电广播(radio)进行流式传输的现有技术方法的概略描绘；

图31是根据本发明的用于在不进行音频混频的情况下进行广告整合(integration)的系统概述的概略描绘；

图32是根据本发明的广告标记布置的概略描绘；

图33是与对来自浏览器和/或其他媒体消费客户端的HTTP请求进行路由有关的方法的概略描绘。

具体实施方式

现在更具体地参考附图，本发明提供了一种用于云不可知对等数据流式传输的内容分发网络及相关联的方法。如上面所讨论的，本发明包括如在3处描绘和引用的对等(P2P)网关服务器。P2P网关服务器3(如在200处)接收来自本地机器101上的客户端2的通信。

这些请求可以被格式化为被定向在本地网关服务器3处的标准HTTP请求，该本地网关服务器将在本地域名下进行注册。尽管对来自网页浏览器和其他设备(所述其他设备可以包括对本地注册的域名和协议的使用)的HTTP请求进行路由是可行的方法，但是当对来自浏览器和其他媒体消费客户端的HTTP请求进行路由时，下面的方法是优选的。

针对对等远程服务器4或资源名称服务器4，向消费客户端2给出了完全格式化的域名。为了简便起见，读者将考虑域名www.rns_server.com。为了通过如144处的对等内容分发网络(CDN)请求媒体401，客户端2包含具有RNS公共域名的统一资源定位符(URL)、以及具有所请求的媒体的位置的GET变量，形式为www.rns_server.com？media＝www.somemediasource.com/media.mp4&protocol＝http。

当RNS 4接收到该请求时，RNS 4查询404两个截然不同的数据库。第一查询使用发出请求的设备的公共互联网协议(IP)地址来识别发出请求的设备的本地网络101内是否存在任何网络对等体3。第二查询搜索资源数据库以识别对等(P2P)CDN 144内的、具有所请求的可用于流式传输(如，在200、207、208、209以及210处)的媒体的对等体3。

基于查询404的结果，可能发生如下事情。首先，如果在本地网络上不存在被注册的对等体，则该请求被重定向(如，在403处)至媒体的远程源104，并且P2P网络144将不会被利用。如果本地网络101内存在被注册的对等体3，则该请求连同资源位置和过去在第二查询404中检索到的可用性数据一起被重定向(如，在402处)至本地网络对等体3。然后，本地网络对等体3对媒体流进行处理(如，在200、207、208、209以及210处)。

因此，读者将理解的是，在4处引用的资源名称服务器(RNS)是本发明的实践的核心。RNS 4缓存资源URL和资源位置(IP地址)，并且利用机器地址(IP地址)来解析资源请求。不相匹配的媒体类型的通用过程将是如下所示。客户端2向网关服务器3发送(如，在200处)对于资源的请求。

然后，网关服务器3将该请求发送(如，在201处)至被划分的RNS 4，以利用资源地址(如，在204处)来解析(如，在202处)传入的资源ID/URL请求(如，在203处)，然后，如图5将更具体描绘的那样，资源或IP地址被传送回(如，在205处)至网关服务器3。换言之，一旦资源请求203与最优(例如，(a)价格最有效益或者(b)最高源音质)资源位置204相匹配(如，在202处)，资源位置数据或一个或多个IP地址204就被返回(如，在205处)至网关服务器3。

然后，网关服务器3将一个或多个对于资源数据的请求发送(如，在206、207和208处)至合适的机器(102和/或103)或如104处的服务器群集。然后，机器102/103或服务器群集104通过将所请求的数据提供(如，在209处)至位于机器101上的网关服务器3来进行响应。机器101上的网关服务器3对209处提供的数据进行处理(即，组织并验证)，然后将资源分发210至客户端2。

图7、图8、图9以及图10中基本上概略地描绘了特定的客户端-服务器关系。图7中描绘了传统的客户端-服务器关系；图8中描绘了未被管理的对等网络；图9中描绘了被管理的对等网络；以及图10中描绘了集中式/混合对等网络。

在传统的客户端-服务器关系中，如图7中所描绘的，客户端105向服务器106请求211数据，以及服务器106按照周期的方式分发212数据。在传统的未被管理的对等网络中，每个对等体(或客户端/服务器组合)107可以既作为用于分发数据的服务器106又作为用于接收数据的客户端105。在图8中大体上描绘的未被管理环境中，对于数据的请求211从一个对等体107传递至另一个对等体107，直到文件被定位为止。

在图9中大体上描绘的被管理的对等网络具有起到对资源进行索引的作用的集中式资源索引服务器108。在由此进行的请求214之后，所索引的资源被分发213至对等体107。然后，所索引的资源的可用性由对等体107进行报告和注册。这种类型的布置使得对资源进行定位更容易和更迅速。

在图10中大体上描绘的混合系统中，对等网络用在集中式数据源/索引服务器109旁边。在由一个或多个对等体107作出的对于资源和数据的请求216之后，所索引的资源和数据二者都从服务器109分发215至对等体107。这种类型的布置提供了低成本的对等体分发，但还提供集中式数据源的连贯性和速度，并且为了如在被管理的对等网络中那样加快资源分发。在这种情况下，数据的混合来源于服务器109，并且对等体107分发数据。

在图2和图3中大体上所描绘的来源不可知的对等内容分发网络(CDN)144中，客户端2是独立的客户端。换言之，数据请求来源于独立的客户端2(即，浏览器、桌面或移动应用)并且由独立的客户端2进行消耗。与在其他网络中不同，对于数据的请求并不是利用对等体107来发起，而是利如图7中大体上所描绘的传统的客户端服务器关系中的那样，利用独立的客户端2来发起。

网关服务器3接收来自客户端2的请求，然后利用资源名称服务器或RNS或资源索引服务器4来解析对于资源的请求。RNS 4以资源位置(例如，IP地址)进行响应，该资源位置可以是资源来源或对等体。假定该网络是数据来源不可知的，则对等体数据并不由中央数据服务器进行管理，而是当在网关服务器3处传递并且缓存该请求时，在RNS 4上对对等体数据进行索引。

在这样的网络中，数据源与资源索引服务器或RNS 4分离。这使得独立的客户端2所作出的任何对于数据的请求都能够由数据来源或对等网络来组成，因为当从独立的客户端2发送请求时，对等网络内的数据被缓存。

本发明并不限于使用HTTP或网页套接字，而是还可以使用标准文件传输协议(FTP、WebDAV、SMB、AFP等……)。在这种情况下，客户端可以是独立的FTP(或者任意标准文件传输协议客户端)。如果FTP目录(或者WebDAV、SMB、AFP等……)作为网络驱动器而被安装在操作系统内，则操作系统可以作为客户端。在这种情况下，网关服务器可以作为文件服务器来进行操作。

注意，在这样的布置中存在多种安全问题。根据本发明的所提出的解决方案或布置潜在地容易受到“中间人攻击”和/或未授权的客户端访问。这些问题可以通过提供特定客户端和/或服务器认证装置来解决。客户端和/或服务器认证装置基本上起到检验客户端和/或服务器真实性的作用。

客户端和/或服务器认证装置可以由如下面将更详细描述的多个不同的机制来例举。例如，所述认证装置可以借助于媒体插件认证(客户端认证)和浏览器扩展来提供，媒体插件认证(客户端认证)和浏览器扩展对本地服务器进行验证以确保本地服务器不是被破坏的服务器(这将需要某种唯一ID、会话令牌、或关键字配对)。

与插件一起的客户端支持的脚本也可以通过在插件内嵌入某种形式的检验标识来对客户端和服务器二者进行认证，然后，这种形式的验证标识被传递至客户端所支持的脚本，该客户端所支持的脚本使用AJAX来验证所述检验标识。使用与浏览器插件协作的客户端支持的脚本是优选的，因为浏览器插件在一个过程中提供客户端和服务器两者的检验。将在下面进行讨论该方法。

参考图12和图13，读者将考虑经由浏览器插件和客户端支持的脚本来进行的客户端检验。创建安全连接的过程是以安装本地服务器开始的。当本地服务器已经被安装时，该服务器将创建自签名证书，并且将该自签名证书添加至根证书树。这使得服务器能够创建来自浏览器的安全连接。

为了添加另一安全层，本地服务器110加载媒体处理浏览器插件24的多个实例(例如，闪客(flash)、银光(sliver light)等……)。本地服务器110可以容易地加载媒体处理浏览器插件24的多达1000倍的实例。每个实例中都嵌入有如27处的唯一的加密密钥。代替加载多个实例，如果插件库允许进行自定义代码注入，则加密密钥27可以被注入到插件组件文件中。

当浏览器创建如26处的安全连接时，服务器110为所发起的连接创建唯一的会话，然后将具有媒体插件实例24的会话与及其所嵌入的加密密钥27配对，或者创建加密密钥27并且将该加密密钥27注入到插件组件文件中。然后，插件组件文件25被加载至浏览器111中。插件文件25经由客户端支持的脚本对来自浏览器111的所有请求加密，并且将被加密的请求经由被加密的连接26发送至服务器110。唯一加密密钥27还可以是唯一的令牌，该唯一的令牌用于对请求进行签名以对这些请求进行验证。

为了取回加密密钥或令牌27，必须对本地服务器110所提供的插件文件25进行反编译，然后使用新的“破解版”插件实例来与服务器110重建连接。然而，由于服务器110对于每个会话选择了不同的加密密钥27，因此，在新的安全套接字连接26被创建的时刻，先前的加密密钥27到期。这使得经由反编译所取回的加密密钥27毫无价值。

关于使用本地服务器来分发内容的主要问题之一是“中间人攻击”的可能性，在该场景中，恶意软件可能冒充有效的网关并且有可能拦截用户数据。为了避免这种形式的攻击，本系统采用了如下方法：该方法要求通过经由浏览器插件组件25呈现有效的服务器检验标识31来检验有效网关的真实性。此后将进行更详细地描述该过程。

每个本地网关服务器110通过创建检验标识31来向远程主机112进行自身的注册(如，在19处)，其中该检验标识被链接至本地机器的公共互联网协议。该检验标识31及其相关的公共互联网协议被存储在远程主机112上的数据库29中。当加载了将使用本地网关服务器110的网页30时，浏览器111向本地服务器110发送(如，在217处)请求。服务器110通过呈现其检验标识31来进行响应。

然后，浏览器111将带有检验标识31的请求发送(如，在218处)至远程主机112。如果该检验标识31与远程数据库29中所存储的检验标识和互联网协议地址相匹配，则远程服务器112沿着路径218发送验证了本地网关服务器110的响应。在检验之后，然后浏览器111继续从本地服务器110加载(如，在26处)媒体插件24。然后，媒体插件24创建至本地网关服务器110的安全连接219，媒体插件24将通过该安全连接219来分发数据(例如，基于音乐的数据)。

参考图6，读者将考虑非插件安全措施。根据本发明的不需要使用媒体插件的方法涉及：使客户端2向网关服务器3发送对于被注册的会话标识113的请求(如，在220处)以验证该网关服务器3的真实性。会话标识114是网关服务器所预注册的(如，在221处)并且在单次认证后失效。

这需要网关服务器3提前注册多个会话114，并且每个会话标识113仅对于单次验证是有效的。网关服务器3将会话标识113呈现(如，在222处)给客户端2。然后，客户端2通过验证服务器116对所接收到的会话标识115进行验证(如，在223处)。验证服务器116将客户端2所发送的会话标识115与所注册的会话标识114匹配(如，在224和225处)。如果发现存在匹配，则验证服务器116向客户端2确认(如，在224处)网关服务器3的有效性。

存在其他可替代的方法来保证有效的连接，包括：操作系统集成，该操作系统集成会具有为网关服务器预留的本地域名，使得其他应用不能冒充合法的网关服务器；或者通过创建用于经由这样的系统来传送数据的传输协议。这两种都是可行的解决方案。然而，自定义的协议解决方案需要不同的请求格式化，正如下面所例举的：rstp://domain.com/resource_directory/resource_name？var＝123(而不是http://vertigo/domain.com/resource_directory/resource_name？var＝123)。

另一种使系统安全的方式是将经由该系统分发的内容限定为媒体(音乐、图像、视频等)，并且将文件分布限制为与网站或应用的结构和码无关的内容。通过这种方式，更难引入恶意码，因为只有媒体文件才被允许。这样做考虑了安全性。换言之，HTML、Javascript、CSS、PHP文件等……不能经由网关服务器来进行分发。另一种约束是：如果网站(结构、码以及媒体)经由https而被加载并且是敏感的，则使客户端(浏览器)限制对这样的网关或协议的使用。

参考图1，读者将考虑根据本发明的特定的数据有效性和安全性方面。数据来源不可知CDN 144中的问题之一是数据的有效性。例如，如果对等体之一具有被损坏的数据，或者如果某人过去想要创建恶意对等体，该恶意对等体注册了与原始数据无关的文件作为原始文件的对等体缓存的版本，则系统的可靠性和实用性会受到损坏。

这就是对于应当可靠和有用的系统而言必须包括数据分片和验证方法的原因。因此，为了防止单个对等体受到可能的破坏或者以不恰当的方式故意替换数据，优选的是，经由特定数据分发分片装置来对跨越多个对等体的数据的分发进行分片。根据本发明的数据分发分片装置可以由多种机制来例举。例如，数据分发分片可以通过将数据199分成如行117、118、119和120处的数据包或子流来实现。该分片可以被优化以满足系统的需要。

分片可以通过简单地限制每个对等体最多分发特定的媒体文件的示例性三分之一或四分之一来实现。这是通过使用如稍后在下面更加详细讨论的那样的资源名称服务器或RNS 4来管理的。连同数据分发分片一起，每个数据文件具有随之的用于数据的特定扇区(如，在列121、122、123和124处)的验证数据包。这样做的原因是：在每个对等体再次提供数据之前，每个提供数据的对等体必须首先缓存媒体。因此，作为一个示例，如果对等体分发数据子流117，则还应该将用于文件的扇区121的验证数据包与该数据一起分发。该验证数据包是通过预定算法所创建的校验和。

因此，如果发送子流118的对等体过去要分发被损坏的或者恶意的数据，则接收方对等体将能够通过使用来自发送子流117的对等体的验证校验和来检测这种情况以对发送子流118的对等体所分发的内容进行验证。如果无法对该内容进行验证，则对等体将向原始的源或数据来源的源发送数据请求。本发明进一步考虑了设定请求的每天最小阈值，这使得能够进行这样的对等数据验证。否则，验证服务器将提供校验和，并且，当对于资源的第一请求被传送至网关服务器时，会创建这些校验和。

参考图4和图5，读者将比较地考虑域名服务器(DNS)与资源名称服务器(RNS)之间的特定差异。DNS 130与RNS 4之间的主要差异在于如何处理对于资源的请求。在DNS 130内，对于资源的请求(如，在226处)被解析(如，在227处)为域名129或者起始授权机构(SOA)126，该起始授权机构具有SOA 126的目录128内的特定资源127。客户端2从DNS接收(如，在228处)SOA的IP地址，并且然后向SOA 126作出对于资源127的请求(如，在229处)。

在资源名称服务器或RNS 4内，RNS 4对将对于资源的请求(如，在201处)解析(如，在202处)为多个已存储或已缓存该唯一资源的机器。相应地，不仅具有该资源的SOA的IP地址可以作为有效的资源位置被返回(如，在205处)，而且缓存有资源的对等体的IP地址也可以被返回。换言之，在DNS系统内，URL更像特定资源的地址，在RNS 4内，URL 240被看作用于将唯一资源链接至多个位置的唯一标识。

在图14和图15中，描绘了特定的没有文件匹配的资源索引的手段；以及，在图16和图17中，描绘了特定的具有文件匹配的资源索引的方法。在处理合规时出现的主要问题之一是如何对正在播放的内容进行检验。用户经常损坏或修改元数据。因此，为了更有效地流式传输本地媒体，我们需要提供一种方式来以非常高的确定程度来检验本地驱动器上的媒体文件或歌曲是否对应于被存储在云上的媒体文件或歌曲。

这是通过使用与元数据无关的文件匹配系统或装置并且索引所有的本地文件以及将这些本地文件与云文件进行匹配来实现的。根据本发明存在必须相对于库而匹配的两种文件源：(1)来源于其他流提供商或者来自于外部云的文件源，以及(2)在本地机器上的文件源。

参考图16，逐步索引247的过程开始于来自第三方客户端应用的请求。这可以是如131处的独立的桌面应用或通过如132处的浏览器来播放的网站。应用131或浏览器132将适当格式化的且有效的URL(如，241和242)传递至本地网关服务器(133)。本地网关服务器133使用URL(如，在241和242处)从相关的云245和云246(或者相关的对等网络，或者任何可能的基于网络的资源)检索所请求的资源以用于流式传输(如，在243和244处)。一旦资源已经被下载以用于流式传输(如，在243和244处)，则本地服务器133开始如247处的索引的过程(具有子例程248至252)。在图17中，大体上描绘了本地资源索引253(具有子例程254至258)。

在图18中，大体上描绘了被索引的资源请求处理259。在资源已经被索引后，当由第三方客户端作出后续请求时，会出现下列过程。假定媒体流服务提供商(如，在132处)使用其标准URL将请求242提交到本地服务器133，请求242到达并且本地服务器133查询本地文件系统数据库135和索引服务器134以确定是否该资源先前已经被索引。(URL用于确定该资源是否存在于索引服务器134中或者本地文件系统137中)。在这种情况下，本地服务器133确定资源已经被索引并且是在对等网络138上可获得的。然后，从对等网络138检索该媒体到并且将该媒体提供给媒体流服务提供商(如，在132处)用于回放。

在另一种情况下，媒体流服务提供商(如，在131处)使用URL作出相似的请求。这次，服务器133通过查询指示资源被索引并且与本地文件137相关联的本地数据库来进行确定。然后，例如，服务器133将该文件提供给第三方基于云的音乐流转化器(streamer)(例如，Spotify)(如，在131处)。访问本地网关服务器(133)的系统或应用有可能在会话开始时，对会话期间会需要的所有资源进行传递。然后，服务器133将从资源索引服务器(134)拖拉相关联的字段。通过这种方式，所有被索引的数据被本地存储以用于快速访问和路由。

根据本发明的网关服务器提供了用于针对数据(例如，音乐)传送进行智能路由和版税报告二者的某些手段。假定音乐可以传送自多个源，根据本发明的本地网关服务器可以对客户端应用作出的交互音乐请求和非交互音乐请求二者进行分发，并且对来自在带宽成本和版税义务二者方面最优的(例如，(a)价格最有效益或者(b)最高源音质)位置的实际传送进行路由。这样的系统导致唯一的合规引擎或合规设备，其允许利用从多种类型的服务平台或者跨越多种类型的服务平台生成的报告和版税义务，从而满足所有权利持有人的需求和标准。

传输源的示例包括但不限于：(1)基于云的流转化器；(2)第三方基于云的存储器提供商，其使得设备拥有者可以进行数据购买；(3)基于Vertigo云的虚拟柜(受到版权法的512(c)的保护)；(4)由用户/子服务所匹配的数据所驱动的Vertigo所许可的音乐；(5)本地拥有和存储的音乐文件，该文件可以在听众的设备或者经由Wi-Fi而连接的另一个被拥有的并且合格的设备上获得；(6)从被链接的PC传送至移动设备；(7)对等所拥有的文件，对等所拥有的文件可用于传送并且路由以在文件从上述所列出的(1)、(3)和(4)进行流式传输之前替换该文件。

音乐路由和路由结果报告的几个示例如下。参考图19，读者将考虑当听众经由相关的流式传输客户端(如，在140处)(例如，网站或独立的桌面应用)正在收听非交互互联网无线电广播频道并且互联网无线电广播服务提供商正准备对已经存储于听众的设备上并且在听众的设备上可获得的文件139进行流式传输(如，在230处)时，根据本发明的网关服务器141将所索引的本地文件139与互联网无线电广播服务提供商的到来的请求进行匹配(如，在231处)并且对文件139进行流式传输(如，在232处)，而不是来自如142处的互联网无线电广播服务提供商的播放。

注意，所有的资源(不论是本地的还是远程的)都被索引，这使得能够进行快速匹配。在流式传输232之后，本地文件的使用被报告(如，在233处)给合规服务器143。当流式传输232本地文件139时，唱片公司(label)可能要求互联网无线电广播服务提供商支付少量费用，因为没有办法保证这些文件不被盗版。作为根据服务器141的高效资源分配的结果，互联网无线电广播服务提供商140不必支付带宽或支付整个许可，并且然后这些节约成本可以一起被传递至互联网无线电广播服务提供商。

图20试图描绘一种如下情况的场景：当听众正收听非交互互联网无线电广播服务提供商频道并且互联网无线电广播服务提供商客户端140正准备对不能在听众的设备上获得的、但是可以在根据本发明的对等网络144内的对等体141上获得的文件进行流式传输(如，在230处)。互联网无线电广播服务提供商没有节省版税，但是根据本发明的对等网络144传送(如，在233处)文件139来代替互联网无线电广播服务提供商的文件，从而为互联网无线电广播服务提供商节省了带宽。然后，如果需要的话，则服务器141可以向合规服务器143在233处报告播放过哪首歌。

图21试图描绘一种如下情况的场景：当听众针对特定事件在如145处的他们的媒体流服务提供商账户中创建十首歌的播放列表时。听众刚好是餐厅老板或经理并且该事件是商业环境中的公共事件。媒体流服务提供商账户145不允许用于商业环境，而这些歌曲其中的三首歌曲实际上可经由听众的云存储柜被下载到本地设备上，所购买的媒体许可协议也不允许用于在商业环境中传送。

商业许可提供商设备146被安装在具有广播所有十首歌曲的合法权利的建筑物上，但是在提供商的本地安装的设备146上仅可获得所请求的十首歌曲播放列表中的五首歌曲。根据本发明的系统对媒体流提供商的媒体播放器145所作出的播放列表进行同步，并且将丢失的文件与Vertigo云中可获得的文件进行匹配(如，在231处)，以及按照提供商的许可协议向商业许可的提供商的设备146传送234歌曲。取决于带宽成本，这种传输可以来自于Vertigo的对等网络144。如果需要的话，服务器141可以将所有的传送和流式传输报告233给合规服务器143以跟踪歌曲被播放过的次数。

在图24中所描绘的场景中，流提供商147请求在移动设备148上播放歌曲151。该请求发送自移动设备148上的移动设备应用149，并且被发送至根据本发明的远程服务器150。如果请求237该歌曲的移动设备148被(如，在235处)链接至具有本地存储的文件的个人计算机152，而不是将对于歌曲的请求路由至数据来源服务器147(即，流提供商的服务器)，则该请求被发送至个人计算机152并且从个人计算机152流式传输(如，在236处)至移动设备148。在这样的情况下，不再需要任何额外的流式传输权利并且不会引起带宽成本。如果根据本发明请求237被发送至远程服务器150并且文件既不存在于所链接的个人计算机152上又不存在于云上，则请求237被发送(如，在238处)至数据来源服务器147，然后数据来源服务器147将文件流式传输239至设备148。

在图25中所描绘的场景中，流提供商147请求在移动设备148上播放歌曲。该请求发送自移动设备148上的移动应用149，并且被发送至根据本发明的远程服务器150。如果移动设备148正请求过去从个人计算机152上传(如，在240处)至云服务153的歌曲，则远程服务器150将请求237路由236至云柜或服务153，其中移动设备148被链接(如，在235处)至个人计算机152。在这种情况下，不需要许可，但是将适用带宽收费。如果请求237被发送至根据本发明的远程服务器150并且文件既不存在于所链接的个人计算机152上又不存在于所链接的云153上，则请求237被发送(如，在238处)至数据来源服务器147，然后文件可以被流式传输(如，在239处)至设备148。

如上面的示例内所描述的、根据本发明的服务器150以及该服务器150的智能音乐路由引擎不仅针对带宽和版税成本从包括但不限于上述示例1至6的资源中选择最便宜的传送点中的歌曲，而且还已经对这样的传送的合规方面进行评估，并且出于版税的目的而报告这样的活动。

参考图22和图23，读者将考虑根据本发明的特定分许可布置。针对流式传输的内容的自动分许可而对本地网关进行的使用是取决于权利持有人与内容分发方(即，流服务提供商)之间的协议的条款的。下面所描述的是这种可能的情况：假定流提供商具有要求他们分享从流式传输许可的媒体中获得的收入的一部分的协议。可能存在如下的要求：这样的许可专门允许流提供商成为批发商。

在图22中，描绘了第一种情况的场景。在这种情况下，流服务提供商155向本地网关服务器150传递请求，伴随着该请求，提供商155必须设置特定参数以允许本地服务器150以最优的价格进行流式传输241。这将指示服务器150可以从分许可的账户(如，在156处)进行流式传输。在该图中，存在三个分许可的账户，标记为157、158和159。

当来自客户端应用155的请求到达时，本地服务器150确定(如，在242处)哪个分许可账户(如，从账户157至159中选择出的分许可账户)具有针对给定请求241的最优许可成本。然后，歌曲从分许可方云(例如，从账户157)被流式传输243。然后，流提供商代表分许可方157被计费(如，在244处)。该计费将包括基于分许可方许可协议的许可成本和流式传输成本。然后，分许可方向权利持有人160支付245版税并且留下覆盖流式传输的成本和从该交易中获得的利润所需要的金钱。

在图23中所描绘的第二种情况下，主要的不同之处见于如何覆盖流式传输的成本。由于数据是从根据本发明的对等网络161被流式传输246的，因此与使用对等网络161相关联的费用被支付247给拥有该网络161的服务提供商162，并且然后许可的成本被一起传递244给分许可方157，然后分许可方157将版税支付245给权利持有人160并且留下从交易中获得的利润。

上述分许可情况是可能的，因为本地服务器150跟踪并报告流，即，谁从哪(哪个分许可方)进行流式传输，并且因此可以适当地路由版税付款。系统的独特性不是其允许进行这样的跟踪，而是可以访问对等网络并且仍然可以报告这样的使用情况。上面所提出的第二种情况的场景只对于本地网关服务器150是可能的，而对于标准的服务器至服务器的请求或者某种形式的重写或重定向，可以发生第一场景。

根据本发明，通过使用本地服务器内容而获得的一些许可利润/优势是明显的。在这方面，当歌曲存在于在由服务的最终用户所控制或拥有的本地服务器上时，本地媒体使用开始播放。这将是已经存在于该用户的个人媒体库账户或者用户的本地计算机的任意部分中的标题或专辑。该内容可能已经通过购买、下载或赠送的方式而被放置在用户的个人媒体库账户或者用户的本地计算机的任意部分处。服务提供商或本系统/方法的所有者的责任不在于确认最终用户的计算机上的本地文件的合法来源。

流提供商将不能对本地所控制的录音或音乐作品进行复制、分布或表演。因此，针对计算或报告没有使用权利并且不需要额外的许可费。关键是能够快速并准确地识别出这些跟踪以便于不会中断最终用户的体验。

在如下情况下会出现对来自根据本发明的服务器的媒体的使用：当已经从本系统/方法的所有者以更加有利的费率许可的歌曲可以被用于代替来自流提供商的歌曲时。这可以通过使用内容控制器而直接作出的许可来实现。这些新的直接协议直接地向艺术家提供更加透明的版税结构和报告过程。

直接许可还考虑交互使用和非交互使用二者，以为在线使用创建更大程度上的“一站式”关系。该协议还将提供独特的版税付款，该版税付款是通过从分发效率所获得的节约费用来计算的。目前不存在这样的协议：将被共享的文件所创收的节约费用的一部分分发回行业。

对于流提供商而言使用这些文件的利润来自于横跨交互和非交互使用中所减少的版税率。根据对这些标题的使用所计算出的所有表演和收听小时数将从标准的“全费率”版税计算中去除并且将基于更有利的费率。

在下面的情况下出现对被控制的对等媒体的使用：当文件位于被控制的用户服务器的安全缓存器中并且可以代替计划用于按照流提供商数据供应进行播放的文件时。根据本发明的系统和方法，尽管没有来自版税费用的节约成本，但是存在分发节约，这将使得按照直接许可的艺术家受益。因此，可以来自这个安全缓存器的标题越多，则对流提供商和音乐行业二者更加有益。

下面是从虚构的流提供商规划的样本月(sample month)的突破。该突破意味着：不仅显示与多个来源的内容的使用所涉及的节约费用，还显示该独特的合规计算过程对于整个节约费用过程来说是多么关键。

合规引擎和报告工具具有拖拉下列信息的能力：

1)基于所有表演权利组织所需要的独特的规范的使用报告。这些规范包括如下项。

a.根据平台(流供应商)提供独特的报告

b.基于平台类型并根据流提供商提供安全地录入收入信息的能力

c.根据独特的用户会话的使用报告以根据播放总数并根据收听会话总数来创建平均收听小时总数

d.将所有的使用和收入信息聚集到每个SP每个PRO的单独使用报告中的能力

2)针对声音交换报告和付费的使用规范

a.根据平台(流供应商)提供独特的报告

b.基于平台类型并根据流提供商提供安全地录入收入信息的能力

c.根据独特的用户会话的使用报告以根据播放总数并根据收听会话总数来创建平均收听小时总数

d.将所有的使用和收入信息聚集到每个SP的单独使用报告中的能力

3)针对唱片公司(Record Labels)和出版商的通用使用规范——用于交互使用

4)权利模块“合规仪表板(Compliance Dashboard)”——批量改变或单独改变(根据媒体资产)由内容控制器针对各中协议类型所授予的权利、版税率、清算状态和使用的能力：

a.唱片公司许可协议

b.居住许可协议

c.商业许可协议

d.多平台许可协议

e.捆绑权利协议

f.版税共享协议(发行管理)

g.弃权/免费(Waiver/gratis)

5)横跨用于以下“内容源类型”中的每个类型的所有多个单独的平台和服务来提供以上所有报告要求的个体的和聚集的账户的能力

a.100％流提供商(SP)内容

b.本地服务器内容

c.被控制的P2P内容

d.Vertigo许可的内容

6)版税计算引擎——该系统有能力基于进入合规仪表板中的费率、按照数据范围、内容源类型以及流提供商来将使用数据结合而计算所欠的版税。下面的计算将被用于本地服务器内容去除。X/X+Y x(按照播放或流式传输小时费率)＝总的版税。X＝本地服务器内容，以及Y＝流提供商内容。

针对所有权利社团、商店、源精确地进行计算和报告并且计算被控制的且专用的内容使用并且将分发成本节约费用合并到总的全部版税的能力使得其成为独一无二的合规服务。

文档的这部分公开了本地网关服务器如何可以用来使得传统无线电广播站互联网流更加高效并且提高所流式传输的音频的质量。本发明(更确切地说，本公开内容的该部分)关注于无线电广播，该无线电广播主要播放与脱口秀、体育广播等……相对的音乐。可以获得显著的节约，并且音频的质量将获得显著的改进，这是因为如下事实：基于音乐的无线电广播是实况音频与预先记录的音频的混频。

如果预先记录的音频可以从实况音频或演播室混频中分离出来并且经由对等网络或通过本地文件系统(可以用来确保合适的歌曲被播放的元数据文件匹配系统)而被分发至本地计算机，则可以实现显著的节约和音频质量的提高。然后，预先记录的音频和演播室混频可以在本地计算机上被混频以确保连贯的广播内容与质量。本公开内容将说明这是如何能够被实现的。

图30中大体上描绘了用于经由互联网来流式传输无线电广播的现有方法。目前的用于经由互联网来分发广播流的方法通常涉及使用(如，在163处的)媒体播放设备(例如，通常为个人计算机)，该媒体播放设备播放预先记录的音频(音乐轨道、广告等……)并且将该音频输出248至音板164。然后，在演播室或记录系统170处，该音频与电台的音乐节目主持人的言论和/或评论以及被输入249到音板164中的其他实况音频165全部相混频。

然后，该音板混频被作为单个音频流而被输出(如，在250处)至计算机166。然后，计算机166对音频流进行压缩并且将该音频流输出至被压缩的音频文件167(这通常为MP3文件)。该MP3文件没有设定的持续时间，因为该文件是实况流式传输的并且新数据正不断地被附加至该文件的末尾。该MP3文件通常位于内容分发网络168上，并且对音频流进行压缩并转码的计算机166在它压缩该文件时将该文件与新数据附加251在一起。然后，内容分发网络168将该文件分发252给客户端169。此外，这是一个简单的系统概述并且可能与市场上的大多数配置相似。

在图26至29中大体上描绘了根据本发明的网关服务器增强系统。该增强系统开始于无线电广播演播室170和计算机163，它们将预先记录的音频输出248至音板164。根据本发明的计算机163可以具有如专用软件所例举的某些事件标记关联装置，当该专用软件被安装或者被应用时允许......

1、电台的音乐节目主持人对歌曲进行排队以用于广播；软件创建歌曲队列171，然后歌曲队列171被分布至客户端172，客户端172对该广播进行流式传输。队列171包含电台的音乐节目主持人计划在广播期间播放的歌曲。本地服务器184预先加载253这些歌曲，使得：当电台的音乐节目主持人决定播放一首歌曲时，该歌曲将在客户端172处可获得以用于回放。这些歌曲可以经由远程内容分发网络客户端173、对等网络客户端174进行分发，或者由本地文件系统175进行匹配并且进行流式传输。

2、软件还可以对从音板164返回的音频输出176进行压缩(如，在256处)。软件还可以将事件标记嵌入在音频流179的帧头177中。每个MP3音频流/文件179包括多个音频帧178，每个音频帧178具有帧头177。当新音频被添加时，新帧178被附加至文件。这些帧头177的长度为32位。在每个帧头177内，存在一位被预留供私有应用所使用。在事件开始时该位被设置为“1”，并且在常规的流式传输期间可以被设置为“0”。该数据会被嵌入到来自音板164的流176和/或256二者中。每个帧头177还包含仅为信息并且不会影响音频回放的位(例如，“版权”、“原始的”)。每个帧头177具有不会影响音频回放的至少3个位(包括私有位)。这些位可以被用于创建事件ID。该ID可以通过使用这些位(在事件指示符位之后)来创建，以创建“0”和“1”的组合从而使得足够独特的ID能够容纳足够的事件以组成10秒的回放。因此，如果使用具有原始事件指示符位的帧头，连同一起使用直接跟随的帧头，则总共至少5位可以用于创建至少32或2⁵个独特的标记。这将有够多的独特标记来覆盖足够的事件以用于可能的10秒的延迟。如果需要更多的标记，则可以添加另一帧头以将标记的总量从32增加至256。由于每个事件在10秒时间帧内具有独特的标记，因此这些标记可以被用于使两个单独的流(一个流仅包含实况音频，而另一个流会是完全的混频)同步以切换并转变为完全远程混频的流和本地混频的流(这会是从演播室流式传输的实况音频的流和由本地服务器在事件标记处混频到该流中的预先记录的音频)。该事件标记还会链接至混频指令以对来自演播室的音频混频进行模拟。

3、应用还创建事件队列。这会是这样的事件队列：基于在标记之后的独特的位ID，将该事件队列将与事件标记相匹配(如上面所解释的)。这些事件会被记录在正在压缩音频的计算机163上，使得每个事件被注册在这些事件在其中发生的确切的帧178处，确保事件的定时被嵌入到实况音频流256中在这些事件在原始演播室混频176中所发生的确切位置处。这些事件将包含关于如下各项的信息：

a.在事件标记处需要播放什么样的预先记录的音频。

b.对于该预先记录的音频，在哪一帧处开始回放。

c.应该以哪一音量开始回放。

d.此外，如果音量之前正在淡入，则最适合音量的斜率和方向的均衡淡入/淡出。这将被用于模拟演播室淡入/淡出。这种信息可以由外围衰减器180来记录，该外围衰减器允许电台的音乐节目主持人在音频被输出到音板164时控制257音频并且将音量的变化报告回计算机163。

e.事件的结束(通常需要事件的结束以标记何时淡入/淡出停止)。

f.以及更多的……，这仅仅是最有可能的类型的事件的示例。

4、应用还会对远程服务器或内容分发网络150上的实况音频流文件181和完全混频文件182进行更新258。

一旦在演播室170内由应用将两个流181/182记录并编码在计算机163上，则文件181/182二者都被上传258至内容分发网络或远程服务器185以用于分发259至客户端172。客户端支持的应用183(例如，浏览器等……)通过使用合适地格式化的URL来发送对于无线电广播流的请求。该URL被构造成主域名的子域，例如，这种格式的URL可以被用于引用无线电广播站流radiostation.vertigomusic.com/[show id]。如果vertigo网关服务器184未被安装，则该URL应当将客户端引导至完全混频的演播室流182并且将以与传统的互联网无线电广播流(参见上文和图30)相同的方式播放该文件。

如果vertigo网关服务器184已经被安装，则服务器184向自身注册该子域名并且然后处理来自本地客户端应用183的对该子域名的所有请求。在这种情况下，当由客户端应用183作出关于流的请求时，该请求由网关服务器184提供260。网关服务器184通过提供来自远程内容分发网络185的完全混频的流182来开始。一旦该流开始，则网关服务器184请求预先记录的音频队列171并且开始对来自对等网络174、一个或多个远程内容分发网络173或本地源175的预先记录的音频进行缓存253。网关服务器184还从远程数据库186加载261事件队列，该远程数据库186由演播室计算机163不断地更新。当流181是实况时，网关184会连贯地接收对事件261的更新。

为了从完全的演播室混频182转变成仅为实况音频的流181，网关服务器184加载流181和182二者并且仅提供全混频182。为了确保网关服务器184和混频应用187具有足够的时间来完成所有任务，服务器184从实况数据接收起的10至20秒之后启动所述流，创建可以被用于为系统创建时间以执行混频和转变的自定义延迟。网关服务器184等待全演播室混频182帧头177中的事件位以转变为实况音频流181。

网关服务器184在该事件位处将这两个流182/181对齐。这是通过对事件位之后的位码进行匹配来实现的。如果两个事件的位码相匹配，则事件被认为是匹配的，因为只有流的最后10至15秒被搜索。32个独特位码提供了足够的独特性以保证相匹配的事件实际上是一样的。一旦事件位是匹配的，则网关服务器184在出现事件位的帧178处从全演播室混频182转变到实况音频混频181。使用该方法以帧到帧的精确性提供从流到流的无缝转变。

一旦网关服务器184已经转变到仅实况音频的流181，则当事件位出现时，网关服务器184开始遵循被存储在事件数据库186中的混频指令。由于仅针对事件位对实况数据流的最后10至15秒进行跟踪，因而位代码被用于对数据库186内的与事件位码匹配的事件数据进行定位。

因此，假定第一事件是为了回放预先记录的音频队列171内的第一首歌，应用已经缓冲了该音频的至少10％至20％。在这种情况下，网关服务器184将实况音频流181和预先记录的音频数据188传送至内部混频应用187(这可以是如SoX的命令行应用、或自定义构建的应用)。

网关服务器184还将混频数据发送261至应用，该应用对实况音频流181和预先记录的音频进行混频以模拟完全演播室混频182。这是通过使用如下数据来实现的：该数据被记录在演播室170处并且与用于模拟电台的音乐节目主持人的淡化和定时的事件相关联。然后，应用187输出新的本地混频的文件189，然后该新的本地混频的文件189被提供给发起请求的客户端183。这可以全部无缝地实现，因为服务器可以在实况数据传送与将数据提供给客户端应用之间创建很大的延迟。只要该延迟是在提供音频的开始处创建的，则该延迟时间帧就可以被用于混频并准备音频。

在广播电台或节目仅是对广告进行整合并且不是将实况流与预先记录的音频(例如，音乐)进行混频的情况下，系统考虑特定的广告整合手段，该广告整合手段可以按照如下所描述的那样并且如图31和图32所大体上描绘的那样进行工作。

无线电广播节目可以通过软件191而被记录在计算机190上，该软件191可以对音频进行编码并且标记何时需要播放广告或其他预先记录的文件。在预定时间的音频沉默后，放置广告标记。为了实现这一目的，编码应用191创建延迟300，该延迟比指示音频沉默301的预定广告长几秒。因此，如果无线电广播个性是记录并且需要插入广告休息，则无线电广播个性简单地将麦克风静音或使麦克风沉默如301处的5秒。在5秒的沉默(如，在301处)(作为示例)之后，编码应用不是在5秒的沉默的结束302处而是在开始303处标记音频流。通过这种方式，最终听众不会听到沉默而是听到广告。

一旦预定时间帧的沉默过去之后，应用191提示无线电广播个性以指示应该播放多久广告，并且根据所选择时间帧来整合广告。然后，该音频流由应用191进行编码和标记，并且被上传至无线电广播个性的选择的服务器或内容分发网络192。

当听众从他们的设备193通过客户端应用194(例如，浏览器或移动应用)请求无线电广播流时，则请求被发送270至网关服务器195。然后，网关服务器195向云/服务器192发送271对于音频流的请求，云/服务器192作出响应并将音频分发272至网关服务器195。

然后，网关服务器195将音频流分发273至客户端194。网关服务器195创建小的缓冲区(2至5秒的数据)，使得当在音频流内识别出广告标记时，网关服务器195可以从广告服务器196获取274合适的广告并且在指定的时间处整合该广告。在移动应用中，应用将必须在不需要网关服务器194的情况下整合这些广告。移动应用将必须将其整合到应用的源代码中。因此，其将具有将检测广告标记的代码，并且然后在广告标记的起始处整合广告。

尽管上面的描述包含很多特异性，但是该特异性并不应解释为限制本发明的范围，而是作为本发明的范例。例如，考虑到本发明基本上提供了一种用于将选择的数据文件分发(例如，流式传输)至最终用户的对等(P2P)内容分发网络。

根据本发明的所谓的P2P内容分发网络(CDN)或P2P CDN优选地包括如在2处的客户端、如在3处的P2P网关服务器、如在4处的资源名称服务器(RNS)，以及计算机组成的网络，该计算机组成的网络可以包括：本地服务器、对等体连接的服务器、云柜、云存储器、云媒体和/或一个或多个商业(音乐)流服务提供基础设施。

客户端与P2P网关服务器通信，并且P2P网关服务器与RNS和计算机组成的网络通信。RNS的基本上用于缓存计算机组成的网络内的数据资源位置并且使用计算机组成的网络内的最优(例如，(a)价格最有效益或者(b)最高源音质)数据资源位置来解析资源请求。

P2P网关服务器经由RNS进行请求并接收最优数据资源位置；借助于最优数据资源位置向计算机组成的网络请求并接收数据文件，以及对所接收到的数据文件进行处理以用于将数据文件分发至客户端和最终用户。

根据本发明的内容分发网络或CDN包括大量任选但是优选的被添加在基本系统上的组件，这些组件包括特定的客户端和/或服务器认证装置，这些认证装置用于按照上文所更加详细讨论的那样验证客户端和/或服务器的真实性。此外，为了增强非损坏的数据流的分发，本发明考虑了同样在上文被讨论的特定的数据分发分片装置。

经由特定的资源索引装置可以优选地对资源位置进行索引，该资源索引装置可与RNS结合地协作以进一步增强网络或方法的效率。注意，资源索引装置可以优选地包括特定的文件匹配装置，该文件匹配装置用于独立于数据文件元数据而快速且有效地匹配数据文件。根据本发明的文件匹配装置在No.13/065,254的允许的美国专利申请、现在为No.8,589,171的授权的美国专利中进行了更完整的详细说明，这些说明书要求该专利的权益，并已经通过引用将说明书合并于此。

因此，根据本发明的文件匹配装置优选地可以包括特定的数据提取装置、特定的简要的统计推导装置、特定的自定义标记生成装置、特定的自定义标记关联装置以及特定的自定义标记访问装置。

数据提取装置从第一数据文件中提取波形数据。所提取的波形数据包括长度段值(length segment value)，其中关于数据提取基线来提取长度段值，并且长度段值包括波谷到基线的长度段值以及波峰到基线的长度段值。概括统计量推导装置从所提取的波形数据推导概括统计量，所述概括统计量是从所述长度段值推导出的，并且包括波谷到基线的长度段统计量以及波峰到基线的长度段统计量。

自定义标记生成装置基于所推导出的概括统计量来生成自定义标记；以及自定义标记关联装置将所述自定义标记与所述第一数据文件相关联从而构建出经自定义标记的数据文件。当将第二数据文件与经标记的数据文件进行比较时，自定义标记访问装置访问所述自定义标记以呈现肯定的数据文件匹配。

如上文所更详细讨论的，P2P内容分发网络还可以包括特定的事件标记关联装置，事件标记关联装置用于对数据文件的帧头中的事件标记进行关联以用于对数据文件传送进行增强。在这最后一方面，读者会记得本发明还考虑了特定的广告整合装置，广告整合装置可以被进一步用于经由所指定的事件标记关联装置将广告内容整合到数据文件中。

鉴于本发明的数据来源不可知特点，进一步地考虑数据路由管治系统。根据本发明的数据路由管治系统优选地以组合的方式包括数据路由合规设备或引擎和所描述的内容分发网络。因此，数据路由合规设备与内容分发网络通信，其中，内容分发网络包括多个数据源，这些数据源包括或存储数据文件。

内容分发网络将所选择的数据文件从最优数据源位置分发至最终用户，其中，最优数据源位置是从包括数据源的群组中选择的。因此，根据本发明的合规设备或引擎提供对数据文件传送的(a)行业权利管理、(b)合规监测和/或(c)合规报告。

基本上，本发明可以被说成提供如下功能：(1)从本地服务器(例如，数字无线电广播，例如，无线电广播)分发间接请求流；从对等体连接的服务器分发间接请求流；从第二直接请求源(例如，iTunes Match或Spotify或云柜(例如，DropBox)或者云中的任何媒体)分发间接请求流；基于第二直接请求源的播放或流式传输的权利从对等体连接的服务器分发间接请求流；基于(a)价格最有效益或者(b)最高源音质来从第二直接请求源分发直接请求流；以及(6)基于第二直接请求源的播放或流式传输的权利从对等体连接的源分发直接请求流。鉴于本系统的数据来源不可知或云不可知方面，系统还提供(a)行业权利管理、(b)合规监测和/或(c)合规报告，其中，所分发的内容是来源于第二源，而不是包括上述示例1至6的原始请求的源服务。

上述说明书还被相信支持特定来源不可知数据分发方法，该方法用于最优地(例如，成本有效地)向计算机组成的环境中的最终用户分发所选择的数据。根据本发明的来源不可知数据分发方法可以被说成优选地包括如下步骤：使客户端、对等(P2P)网关服务器和资源名称服务器(RNS)与计算机组成的网络进行通信；以及经由RNS在计算机组成的网络内缓存数据资源位置。

最优的数据资源位置可以由P2P网关服务器经由客户端从RNS所缓存的数据资源位置中请求，其中，经由RNS、使用最优资源位置来解析资源请求。由P2P网关服务器经由RNS来接收最优资源位置，其后，借助于所接收的最优资源位置或者通过所接收的最优资源位置使得能够请求来自计算机组成的网络的数据文件。然后，所请求的数据文件被传送(即，发送和接收)并且对数据文件进行处理以用于将数据文件分发至客户端。