专利名称：分布网络中的数字权利管理的制作方法
技术领域：
本发明总地涉及用于内容传递的技术。
背景技术：
在现有技术中已知内容供应商把它的内容传递要求转移到内容传递网络(“CDN”)。内容传递网络是内容服务器与相关的控制机构的集合，它们通过以自己的名义向最终用户传递内容而从网址起源服务器分担工作。管理良好的CDN通过提供网址的网页的某些或所有内容，由此减小客户的基础结构花费而同时增强最终用户从网址浏览的体验而达到这个目的。为了最佳的性能，CDN服务器供应商可以保持对因特网的拓扑、可靠性和等待时间的客观、详细、实时的观察，该观察然后被用来推动动态的基于DNS的系统将最终用户引导到最好的CDN服务器来处理具体的请求。
数字权利管理(DRM)是指用于数字媒体内容(典型地音频作品或视听作品)保护的技术。DRM通过在发行之前加密内容和通过使访问仅限于已获得播放内容的适当许可的那些最终用户而达到。DRM许可实施是在播放器/客户端处完成的，因此(DRM的)客户端一侧的完整性对于方案行得通是关键的。Microsoft、Real和Apple已开发了用于它们的音频和视听内容发行的专用DRM技术。Apple的DRM技术被用于它的iTunes音乐服务。Microsoft和Real网络支持对点播和直播媒体内容的DRM保护。围绕DRM有一些标准化的努力(MPEG4/ISMA和Open Mobile Alliance(开放移动联盟))，但这些标准仍处在规范阶段。
端到端DRM系统典型地包括三个部分加密、商业逻辑和许可传递。DRM从内容加密开始。一旦内容被加密，就需要密钥来解锁内容。加密的内容可以通过任意数目的传递方法被传递HTTP、流传递、FTP、P2P、电子邮件等等。想要播放内容的最终用户访问电子商务网址并利用商业逻辑过程进行交易，通常牵涉到注册、登录和/或付费之一；一旦完成，就向最终用户发放播放内容的许可。发放的许可典型地包括(i)密钥(用于解密内容)，(ii)一组权利(例如，播放正好一次，在30天内播放等等)，和(iii)伴有许可仅仅在被发往的最终用户机器上才有效的属性。当最终用户试图播放DRM保护的内容时，播放器首先检验在机器上的许可缓存，如果找到许可，则通过解密内容而开始播放。如果没有找到许可，则播放器试图一般从被嵌入在内容中的铺面(storefront)URL得到许可。最终，是由播放器/客户端来实施DRM。在典型的DRM情景下，媒体文件(例如数据流)被使用密钥的打包器组件加密。替换地，数据流可以由编码器在处理中被加密。流式服务器把加密的数据流提供给最终用户浏览器的媒体播放器。如上所述，播放器需要从许可服务器得到许可(它包括密钥)，以便解密和播放内容。
在过去，DRM许可密钥的监控和管理以集中的方式进行，主要解决保密性问题。特别希望能够利用内容传递网络的分布特性来促进分布式的(非集中的)许可传递基础结构。本发明解决这个需要。
发明内容
本发明的目的是提供用于数字权利管理(DRM)许可传递的分布式体系结构。
本发明的再一个目的是利用内容传递网络(CDN)的分布式基础结构来实现DRM许可密钥的管理和分发，优选地是以非集中方式(即，分布方式)。
本发明的另一个目的是提供用于许可传递的分布式体系结构，其中提供许可密钥分发的实体(例如CDN)不保持或者不能访问用于保护内容的预期用户的识别信息。
因此，本发明设想与其中存储有关最终用户的信息的任何集中数据库分开的分布式许可传递基础结构，该最终用户可能希望得到由许可保护的内容。这个解决方案的优点在于，它把商业逻辑与任何验证体系分隔开，因而允许内容供应商实施适于他们的商业活动的灵活的商业规则。在优选实施方式中，CDN服务供应商不需要保持CDN客户的所有最终用户的数据库。CDN提供许可传递，但不直接涉及验证发出请求的最终用户的身份、收集付费或得到信用卡信息；相反，CDN只在发放许可之前验证最终用户的请求(而不是用户)，并最终传递数据流。本发明因此在实施DRM的CDN解决方案提供的环境中将商业逻辑与许可传递分隔开。
本发明的更一般的目的是在内容传递网络(CDN)上促进音乐发行和基于预订的媒体服务。
一般地说，本发明被实施在分布式网络运行环境(诸如CDN)内，其中内容供应商从由服务供应商(例如CDN运营商)管理的服务器(例如CDN边缘服务器)卸载用于传递的给定内容。假设给定的内容通过使用数字权利管理方案来确保安全。根据本发明，提供一组分布式的许可服务器进程来管理内容许可的发放。每个许可服务器进程用来生成许可，给定的最终用户客户端利用该许可获得用于给定内容的给定权利。该组分布式的许可服务器进程以非集中的方式进行，而不访问与请求给定内容的最终用户有关的验证信息。
以上概述了本发明的某些更相关的特性。这些特性应当看作为仅仅是说明性的。许多其它有利的结果可以通过以不同的方式应用所公开的发明或通过修改将被描述的发明而达到。
图1是其中可以实施本发明的已知的分布网络(例如内容传递网络)的框图；图2显示在图1的分布网络中用于边缘服务器的典型机器配置；
图3显示在根据本发明的CDN中实施的DRM解决方案的基本组件；图4是关于受DRM保护的内容如何由CDN传递的更详细说明；图5显示由CDN许可服务器进程执行的令牌验证过程；图6显示CDN许可服务器进程如何生成和传递许可；以及图7显示可以由许可服务器创建和使用的动态权利对象，以逐个请求地增强动态许可权利。
具体实施例方式
众所周知，通过使用因特网内容传递网络(CDN)传递数字内容(例如，HTTP内容、流媒体和应用)。CDN是被设置来代表第三方内容供应商有效地传递内容并在地理上分布的内容传递节点的网络。典型地，CDN被实施为内容传递基础结构、请求-处理机构(优选地基于DNS)和分布式基础结构的组合。内容传递基础结构通常包括位于战略位置(例如，因特网接入点、因特网存在点等等)的一组“代理”起源服务器，用于传递内容到发出请求的最终用户。请求-处理机构(典型地一组名称服务器)将内容传递基础结构中的服务器分配给发出请求的用户，使得对于web内容传递，最小化给定客户端的响应时间，以及对于流媒体传递，提供最高质量。分布式基础结构由点播或基于推送的机构组成，它们将内容从起源服务器移送到所述代理。有效的CDN从对于给定的发出请求的客户端最佳的代理处提供经常访问的内容。在典型的CDN中，单个服务供应商运行请求处理器、代理机构和内容分发器。另外，该服务供应商建立与内容发布者之间的商业关系，代表他们的起源服务器网址来提供分布式传递系统。
如图1所示，因特网内容传递基础结构通常包括位于战略位置(例如，因特网接入点等等)的一组“代理”起源服务器102，用于传递内容的拷贝到发出请求的最终用户119。代理起源服务器例如在2000年8月9日公开的、题目为“Requirements for Surrogate in the HTTP”的IETF因特网草案中被定义，该文件在此引用以供参考。机构104把内容传递基础结构中的服务器102分配给发出请求的用户。典型地，机构104被实施在由CDN服务供应商管理的DNS子系统内(或与它相邻)。分布基础结构由点播或基于推送的机构组成，它们将内容从起源服务器移送到所述代理。CDN服务供应商(CDNSP)可以将多个代理起源服务器集合组织为一组或所谓的“区域”。在这种安排中，CDN区域106典型地包括由一个或多个内容服务器构成的一个集合(或一簇)，它们共享公共后端网络，例如LAN，并且位于或接近于因特网接入点。因此，例如，典型的CDN区域可以共存于因特网服务供应商(ISP)存在点(PoP)108内。代表性的CDN内容服务器是运行某种操作系统(例如，Linux、Windows NT、Win2K)的、基于Pentium(奔腾)的缓存设备，它具有适当的RAM和硬盘存储装置用于CDN应用和内容传递网络内容(例如，HTTP内容、流媒体和应用)。这样的内容服务器有时被称为“边缘”服务器，因为它们位于或接近于因特网的所谓的外部作用区或“边缘”。CDN典型地还包括网络代理109，它监视网络以及服务器负荷。这些网络代理典型地共存于第三方数据中心或其它位置。映射制作软件107接收从网络代理生成的数据，并周期地创建将IP地址(例如，客户端一侧的本地名称服务器的IP地址)与CDN区域动态关联起来的映射。
可以使用例如在参与的内容供应商服务器处运行的内容迁移器或重写工具106来识别内容用于从CDN向外传递。工具106重写被嵌入的对象URL以指向CDNSP域。对这样的内容的请求通过CDNSP管理的DNS来解析，以识别“最好的”区域，然后识别在该区域内没有过载并且很可能容纳所请求内容的边缘服务器。不使用内容供应商一侧的迁移(例如，使用工具106)，参与的内容供应商可以仅仅让CDNSP通过DNS指令(例如，CNAME)服务于整个区域(或子区域)。在任一种情形下，CDNSP可以把对象专用的元数据提供给CDN内容服务器，以确定CDN内容服务器如何处理对由CDN提供的对象的请求。这里所使用的元数据是指用于对象的一组控制选项和参数(例如，相关信息、起源服务器识别信息、负载平衡信息、客户码、其它控制码等等)，这样的信息可以经由配置文件在HTTP标题中或以其它方式被提供到CDN内容服务器。以这样的方式从CDN提供的对象的统一资源定位符(URL)不需要被内容供应商修改。当例如通过使得最终用户导航到网址和选择URL而对对象发出请求时，客户的DNS系统将名称查询(无论URI中是哪个域)引导到CDNSP DNS请求路由机构。代表性的CDN DNS请求路由机构例如在美国专利No.6,108,703中被描述，该专利在此引用以供参考。一旦边缘服务器被识别，浏览器就把对象请求传送到服务器，它应用从配置文件供应的元数据或HTTP响应标题来确定将如何处理对象。CDN也可以包括其它基础结构，例如分布式数据查询和收集系统，该系统收集来自边缘服务器的使用和其它数据，积聚在一个区域或一组区域中的该数据，并把该数据传送到其它后端系统，以促进监视、登录、警告、记帐、管理以及其它操作和监管功能。
如在图1上还看到的，CDNSP还可以运行包括由一个或多个服务器组成的集合的元数据输送系统116，以使元数据可被提供到CDNSP内容服务器。输送系统116可包括至少一个控制服务器118和一个或多个测试用服务器(staging server)120a-n，每个测试用服务器典型地是HTTP服务器(例如，Apache)。元数据由CDNSP或内容供应商(例如，使用安全外部网应用)被提供到控制服务器118，并周期地传递到测试用服务器120a-n。测试用服务器如有必要把元数据传递到CDN内容服务器。元数据对于控制如何在边缘服务器处管理内容是有用的。
上述的内容传递网络仅仅是说明性的。本发明可以利用任何内容传递基础结构。
图2显示用于CDN内容边缘机器(有时被称为服务器)的典型机器配置。典型地，机器200包括运行操作系统202的商品硬件。机器可选地包括虚拟机204和应用服务器206，以促进一个或多个客户应用或应用组件210的执行。为了处理HTTP内容，机器200典型地实施一个缓存212。机器还包括用于客户配置数据214的存储库，客户配置数据214典型地是客户专用元数据的形式，它控制如何在机器上管理内容。服务器管理器216使用客户配置数据上覆和控制缓存212。对于流媒体，该机器根据所支持的媒体格式的需要包括一个或多个媒体服务器215，例如Windows媒体服务器(WMS)。服务器管理器216还可以根据客户配置数据控制媒体服务器。还提供系统管理模块218和系统安全模块220，用来帮助实现这些和其它传统功能。该机器还可包括登录过程、名称服务器进程、数据积聚过程等等。为了本发明的目的，正如下面描述的，给定的机器包括权利管理许可服务器进程225，它实现非集中的基于DRM的许可服务模型。许可服务器进程225为从该机器提供的受保护内容或者从与该机器共存的机器提供的受保护内容提供DRM许可。
作为附加的背景技术，数字权利管理(DRM)解决方案在现有技术上是公知的。从微软公司可得到的一种这样的已知的DRM系统包括可被合并到根据本发明的内容传递网络(CDN)的数字权利管理器。在本例中，Windows媒体权利管理器通过打包数字媒体文件帮助保护数字媒体(例如歌曲和视频)。本发明当然不限于与任何特定厂商的DRM解决方案一起使用。事实上，本发明承认第三方DRM解决方案(从DRM解决方案供应商可得到的)的存在，并关心该解决方案(具体地，许可服务器)如何利用CDN的分布式或非集中基础结构在CDN内被实施。
在典型的DRM解决方案中，打包的媒体文件是已用密钥加密和加锁的媒体文件的版本。在微软DRM解决方案中，在Windows媒体权利管理器中创建和使用密钥。具体地，被用来加密内容的密钥根据种子和KeyID来计算，即种子+KeyID＝密钥。典型地，为了本发明的目的，每个内容供应商选择一个种子，这个种子然后被用来加密该内容供应商的所有内容。KeyID分量被设计成随文件改变。内容供应商可以每个文件使用不同的KeyID，或替换地，它可以选择使用单个KeyID加密它的所有文件(或一系列文件)。为给定的KeyID发出的许可将应用于使用同一KeyID加密的所有文件。为了生成一个密钥，需要许可密钥种子和密钥ID。许可密钥种子是仅对于内容所有者和DRM许可服务器已知的数值。内容所有者为每个受保护的文件创建一个KeyID。这个数值被包括在打包的文件中。当许可服务器需要为打包文件发出许可时，可以通过从打包的文件中取出密钥ID而重新创建密钥。Windows媒体许可服务使用许可密钥种子和来自打包文件的密钥ID来创建密钥。密钥被包括在被发送到最终用户的计算机的许可中。使用被包括在许可中的密钥，在客户的计算机处的播放器就可以打开并播放受保护的文件。
图3显示本发明的DRM CDN解决方案。完整的端到端DRM解决方案的三个主要组件是(i)打包器300，(ii)许可服务器302和(iii)电子商务铺面(或它的等同物)304。打包器300典型地是被用来加密内容的软件(可在处理器上执行的一组程序指令)。这个软件可以在CDN客户基地(起源服务器)处或在一个或多个CDN服务器上运行。许可服务器302发出许可到最终用户的播放器，并且由CDN管理。根据本发明的技术优点，许可服务器302利用CDN自身的基本基础结构以分布式的或非集中的方式运行，而不是以现有技术的集中方式运行。电子商务铺面304优选地由内容供应商或由某个代表内容供应商的第三方来设立和管理。以下的处理流程解释了本发明的基本操作。在步骤(1)，最终用户访问内容供应商的网址并进行商业交易。在注册/登录和/或付费收集后，一旦内容供应商决定使内容对于最终用户是可得到的，内容供应商的网址就生成一个令牌(使用在CDN服务器供应商和内容供应商之间约定的共享秘密)，并把最终用户的浏览器(播放器)发送到CDN许可服务器。典型地，这将在后台完成，同时最终用户待在内容供应商的网址。在步骤(2)，许可服务器验证由最终用户的浏览器呈交的令牌。令牌通常具有把许可发给“对于内容C具有权利R的用户U”的信息。许可服务器首先通过使用共享秘密验证令牌，以保证令牌已由内容供应商的网址发出。一旦发现令牌是有效的，它就生成和发布DRM许可<U，R，C>到最终用户。典型地，整个步骤2对于最终用户是透明的。替换地，内容供应商的网址可以选择直接从CDN许可服务器得到许可，并把许可转发到最终用户。这在图3上被显示为步骤2’。后一种方法保证安全得多的工作流程，因为许可服务器可被配置成(例如经由元数据访问控制表(ACL))把许可只发给内容供应商的网络服务器。在步骤(3)，最终用户在内容供应商的网址上点击URL，以便播放流。这个请求将命中CDN流式服务器。流式服务器将发送加密的内容到播放器。由于已经存在许可，重放将开始。在用户试图在没有首先进入内容供应商的网址之前直接从CDN服务器播放一段内容的情形下，被嵌入在内容中的铺面URL把最终用户的播放器引导到内容供应商的网址。
图4更详细地显示用于流式或点播媒体内容传递的这一过程。在步骤0，CDN供应的打包程序400生成密钥，生成并签名内容标题，然后用该信息加密文件(例如，Windows媒体文件)。打包的媒体文件的内容标题包含以下的信息KeyID和许可获取URL。在步骤1，最终用户访问内容供应商的网址402并进行商业交易。在注册/登录和/或付费收集后，一旦内容供应商决定使内容对于最终用户是可得到的，内容供应商的网址402就生成一个令牌(使用在CDN服务器供应商和内容供应商之间约定的共享秘密)，并根据选定的安全模型进行以下步骤之一(a)客户网址联系CDN许可服务器以得到许可；这在图4上被显示为步骤3，或(b)客户网址发送最终用户的浏览器到CDN许可服务器(通常这将在后台中完成，同时最终用户待在内容供应商的网址)；这在图4上被显示为步骤3’。正如在图上看到的，在步骤2，CDN供应的令牌器406(软件程序、进程、线程等等)生成令牌，优选地使用在CDN服务供应商与内容供应商之间约定的共享秘密，该令牌被用来联系CDNSP DRM许可服务器404。这个过程在下面更详细地描述。在步骤3，CDN许可服务器404验证由客户网址(或最终用户的浏览器)呈交的令牌。令牌通常具有把许可发给“对于内容C具有权利R的用户U”的信息。优选地，许可服务器404首先优选地使用令牌要素而验证令牌，保证令牌已由内容供应商的网址发出。一旦发现令牌是有效的，它就生成并发出包含在播放器处用来解密所加密的内容的密钥的DRM许可。该过程在下面更详细地描述。在步骤4，最终用户试图访问受保护的内容并播放该内容。如果最终用户不具有有效的许可，则最终用户需要得到许可。加密文件(或直播流)的内容标题包括许可获取URL。当最终用户尝试播放不具有许可的DRM保护媒体文件时，播放器打开许可获取URL并试图得到许可。典型地，这将是通往请求注册/续订或付费的内容供应商网址的URL(即，步骤1)。
在CDN可以开始为客户的DRM保护内容发出许可之前，几个秘密必须被提供并由CDN和它的客户共享。以下描述用于两种类型的流媒体的处理过程。秘密通常被分解为打包内容(对于直播和点播)所需的秘密和令牌生成所需的秘密。在一种实施方式中，CDN可以向客户提供一个应用程序，这允许CDNSP或客户生成所有需要的共享秘密。这些共享秘密必须被保秘，并通过某个秘密信道被传送到另一方。点播视频的供应一般需要生成DRM VOD XML文件(有时称为DRMVOD规范)，用户把它加载到CDN打包器工具以便使用这组共享秘密打包文件。所需要的标签包括Key_seed，即加密种子，Header_private_key，即用于签名标题的私钥，Header_public_key，即用于签名标题的公钥，Licence_URL，即许可获取URL，和Individualization，即必需的客户个性化水平。也可以实施附加标签(密钥和证书)。供应工具可依赖于DRM供应商的SDK(例如，Windows媒体格式SDK)，以生成种子和密钥。供应直播视频需要生成DRM简档出口文件，它典型地是包括编码器生成与CDNSP许可服务器兼容的DRM保护的直播流所必需的信息的密码保护的加密文件，还需要生成包括Key_seed标签和Header_public_key标签及其相关数值的XML文件(有时称为DRM直播规范)。后面的文件还可包括Profile_import_password标签，它规定用于输入相关的DRM简档的密码。同样地，供应工具可以依赖DRM供应商的SDK来生成DRM简档。
在代表性的实施方式中，有令牌生成和解析所需要的两种附加的共享秘密。令牌要素是用于DRM令牌的MD5摘要计算所需要的。Base64-编码的128比特Rijndael密钥可被用来加密可选地包括进来的加密种子和公钥。客户和CDN为了成功的安全许可传递必须安全地共享这些值。Rijndael密钥并不是对于所有的令牌生成场景都必需的。
一旦客户决定向最终用户颁发许可，它就必须把这个预想的许可的细节传送到CDN许可服务器。这个信息可以在由最终用户客户端(例如，最终用户浏览器媒体播放器)使用的URL中被传送，以请求许可，例如查询串形式的令牌。下一节将描述查询串的格式和确定可以使用查询串的哪些可选的分量的工作流程。在代表性实施例中，有两个主要的供应/令牌生成工作流程元数据中的共享秘密和查询串中的共享秘密。在第一工作流程中，客户使用CDN DRM供应工具生成DRM VOD规范(连同它的相关DRM简档一起)和/或DRM直播规范。生成的规范中的数值被安全地传送到CDNSP，在规范标识符下被输入到CDN的元数据输送系统(图1上标号116)。在这种情形下，当客户生成在许可传递时使用的查询串令牌时，它将在查询串中指定该标识符。在第二工作流程中，假设客户不想要把它们的共享秘密(加密种子和公钥)加到元数据(或许因为CDN不实施这样的输送系统)。这可能是由于客户一方的安全考虑，或因为客户的具体工作流程需要经常的规范生成。在这种情形下，客户(或代表客户的第三方)管理它自己的加密种子和公钥的数据库。它们在每个许可请求期间在查询串中被传送到CDN许可服务器。为了保持这两个秘密的安全，优选地，它们在被放入查询串之前使用Rijndael加密器被加密。被用于这种加密的Rijndael密钥可以按客户被供应，并可以以与该客户有关的元数据被存储在许可服务器。在这种情形下也规定规范标识符，并且这个标识符可被用来确定令牌要素和Rijndael密钥。
优选地，CDN许可服务器(程序、进程、执行线程等等)仅仅在请求具有与其相关的有效令牌时才以有效的DRM许可应答许可请求。如上所述，优选地，在客户网址处使用CDN供应的工具生成令牌。用于到CDN许可服务器的DRM许可请求的代表性URL可以采用以下形式http://abc.wm.edgedrm.net/getLicense？<query string>，其中<query string>是一系列名称值对，取“name＝value”的形式，连续的名称值对由&号分隔开。在下面的表1中阐述由许可服务器识别的必需名称
表1令牌类型和标志表示令牌类型，标志的16比特字段表示任何可选的查询串参数的必要存在。定义的比特值被列出在以下的表2中。查询串解析器将忽略被设置但未定义的标志位。
表2-查询串标志位图定义MD5摘要在令牌生成时被计算，并被包括在查询串中。许可服务器在接收许可请求后重新计算摘要，并在处理请求之前验证该摘要是相同的。优选地，基于被包括在查询串中的所有识别出的名称-值对的数值、在请求URL中的其它信息以及由许可服务器和客户共享的秘密令牌要素来计算摘要。必要的时间戳是令牌创建时间。可选的时间窗参数被用来阻止仅仅通过重新发送原始许可请求而对过期的许可进行许可重新获取。如果在查询串中没有找到时间窗参数，则许可服务器可以使用在用于给定客户的元数据中规定的数值。查询串必须包含规范标识符。加密种子/公钥对可以出现在查询串中。如果在查询串中找到加密种子和公钥，则这些数值将在许可生成期间使用。如果在查询串中没有加密种子和公钥，则从元数据中取得与(在查询串中)规定的规范标识符相关联的加密种子/公钥。如果在查询串中没有规定权利ID，则许可服务器将使用在元数据中规定的缺省权利简档来生成许可。许可通过包括在发出请求的客户机上生成的ClientInfo串而被绑定于特定的客户机。所述串包含一条或多条数据，例如加密的客户ID、有关在最终用户计算机上的给定软件的版本信息、与个人有关的其它版本信息等等。ClientInfo串是生成许可所必需的，它保证许可仅仅在最终用户原先试图从它得到许可的机器上是良好的。生成ClientInfo串的具体的方式是特定于DRM实施方案的，它不属于本发明的范围。
在代表性的实施例中，客户专用信息被存储在按客户的元数据中。代表性的元数据文件包括以下信息许可密钥种子(用于内容加密的在CDNSP与客户之间的共享秘密)、令牌要素(用来计算令牌摘要的在CDNSP与客户之间共享的数值)、公钥(被用于签名许可)、客户代码(用来向CDN标识客户)、失败动作URL(客户的网址URL，具有无效令牌的许可请求将被重新引导到这里)、Rijndael密钥(用来解密许可密钥种子，如果作为令牌的一部分被提供的话)、优先权值(如果客户具有用于单个内容项的多个许可，则被使用)、权利ID以及规范ID。内容供应商可以规定一列权利简档。权利简档描述将和许可一起颁发的特定的一组权利。客户一般在元数据中设置一个或多个这样的权利简档，并在与许可请求一问发送的令牌中指示将用于给定许可的权利ID。如上所述，用户可以选择通过查询串规定加密种子和公钥或者他们可以把加密种子和公钥关联到作为查询串的一部分被传送的规范标识符。CDN许可服务器使用规范标识符从元数据中选择匹配的共享秘密，并使用这些秘密来生成许可。虽然不是必需的，但通过指定不同的规范ID，共享秘密可被旋转。这主要对于旋转和令牌生成有关的秘密是有用的。CDN客户可能要求文件只在通过规定最小个性化版本号(这个号码可被包括在ClientInfo串中)而已被“个性化”的应用上播放。如果消费者试图使用没有被个性化的播放器播放需要个性化的媒体文件，则不颁发许可，播放器提示消费者获得安全升级。
下面提供有关CDN许可服务器的细节。在说明性的实施例中，许可服务器是运行在用作许可服务器的边缘服务器上的进程。该进程在给定的端口(例如，端口8083)上侦听并接受来自最终用户浏览器媒体播放器(或类似物)的DRM请求。如果必须的话，客户网址优选地把许可服务器进程与在端口80上的DRM请求相联系，该请求然后在给定的端口上被隧穿至许可服务器进程。边缘服务器许可进程在给定的端口上侦听并接受诸如HTTP GET或POST请求这样的请求。正如已描述的，该进程采用来自用户供应的令牌的输入和客户元数据参数(例如，被用来保护内容的加密密钥种子，和被用来保护令牌的令牌要素)来生成许可。在运行中，在该进程期间有两个主要步骤要执行验证所提供的令牌，以及许可生成和传递。令牌验证过程被显示于图5的流程图，许可生成和传递过程被显示于图6的流程图。
如图5所示，到CDN许可服务器进程的DRM请求总是包含以查询串为形式的令牌。如果令牌出现不是有效的，则不处理该请求。为了检验令牌的有效性，边缘服务器许可进程使用在以上的令牌生成段落中提到的相同方案创建伪令牌摘要。然后它比较生成的令牌摘要与供应的摘要。如果它们匹配，则许可服务器进程认定该请求是有效的。因此，参照图5，例程从步骤502开始从请求的查询串中提取参数。然后在步骤504进行测试，以确定与令牌相关的给定时间是否到期。如果是的话，则例程分支到步骤506，发出“无许可”重引导到客户的地点(和/或在替换例中，记录访问拒绝错误)。然而，如果在步骤504测试的结果是否定的话，则许可服务器进程使用查询参数和元数据信息来计算摘要。这是步骤508。然后在步骤510进行测试，以确定该摘要是否匹配于与令牌有关的摘要。如果在步骤508测试的结果是否定的话，则例程在步骤506，发出“无许可”重引导。然而，如果在步骤510测试的结果是肯定的，则令牌被验证，然后在步骤512生成许可。
图6显示许可生成过程。如上所述，许可至少包括播放加密内容的密钥以及许可的权利和条件，并且它还可包括具体的DRM解决方案可能需要或必要的其它信息(例如，优先权值，标识CDN的属性等等)。例程在如图5描述的服务器进程已验证令牌后开始。在步骤602，例程从请求的查询串中提取参数。在步骤604进行测试，以检验ClientInfo串(例如，客户端性能，版本等等)等等。如果在步骤604测试的结果表示有问题的话，则例程分支到步骤606，并发出“无许可”重引导，记录错误等等。然而，如果在步骤604测试的结果是肯定的话，则例程在步骤608继续进行，使用Key_ID和许可密钥种子创建密钥对象。在这个步骤期间，服务器进程还使用Rights_ID和定义的许可权利来创建权利对象。在步骤610，服务器进程然后使用密钥对象、权利对象和Key_ID创建许可对象，并签名许可。在步骤612，进行测试，以确定在创建各种对象时是否有错误。如果是的话，例程分支返回到步骤606。然而，如果在步骤612测试的结果是否定的话，则例程在步骤614继续进行，构建许可(优选地，作为XML文件)，并把该许可传递到发出请求的最终用户的浏览器媒体播放器(或其它渲染引擎，视情况而定)。
虽然许可服务器进程被描述为单个实体，但这不是必要的。一个或多个功能可以在一个或多个执行线程中实施，或者可以实施多个线程或进程。一般地，提供令牌验证和许可生成功能的一个或多个进程、程序、线程等的任何集合可以在给定的边缘服务器中被实施。许可服务器还可包括辅助功能，例如数据记录、负载报告等等，用来存储和输出运行数据到其它CDN进程。此外，不要求许可服务器进程不同于其它边缘服务器进程(例如，元数据处理、对象缓存等)。另外，不要求CDN中(甚至给定的区域中)的每个边缘服务器都支持服务器许可进程。可以有在CDN中运行的服务器许可机器的专用子集，虽然是以分布的方式。然而，根据本发明，不希望有生成用于CDN源起内容的许可密钥的任何集中地点。正如这里使用的，“许可服务器进程”应当被广义地看作为可由一个或多个处理器执行的给定的软件指令、程序序列、代码部分等等。根据本发明，一组这样的进程提供分布式许可服务并以非集中方式运行，优选地不用访问与请求给定内容的最终用户有关的验证信息。
根据本发明的另一个特性，除了具有在Rights_ID中规定的许可权利(它们在CDN许可服务器的元数据中可以得到)以外，系统可被适配于处理动态权利令牌。在这个变例中，CDN许可服务器进程动态地按请求管理不同的权利，这在处理按许可的权利时提供大得多的灵活性并避免元数据权利供应。优选地，动态权利由令牌工具使用高级选项和输入而生成。令牌生成器典型地在客户的网址上执行，如图4所示。当使用动态权利时，在许可请求中仍需要Rights_ID。在这种情形下，许可服务器进程首先应用由Rights_ID规定的权利，然后它替代或添加在动态权利许可请求中规定的权利。下面的表3列出具有给定类型的令牌生成器(例如，Perl，ASP和Java)的代表性动态权利和它们的语义。
表3.代表性的动态权利通过图7所示的动态权利对象说明如何建立动态权利的代表性例子。在这个例子中，内容供应商使用ASP令牌生成器创建对象。内容供应商然后设置该对象的想要的属性，然后可以按许可请求的不同使用这些属性。
本发明具有许多优点。如上所述，本发明提供高度可缩放的、高度可得到的、分布式许可服务器基础结构，以及被用于受保护内容的传递的CDN的特有优点。如上所述，在优选实施例中，本发明提供与内容保护分隔开的商业逻辑(付费处理等等)。通过让内容供应商(或代表它的某个实体)操纵商业逻辑，同时让CDN掌管安全性(许可服务)而实现这种分隔，其中CDN也负责提供受保护的内容。这使得CDN客户能够实施适用于它们的商业模式的灵活的商业法则。优选地，CDN不涉及跟踪数据库中它的客户的最终用户身份。
本发明不限于使用于特定的类型的内容，例如流媒体，而是对于包括Web内容、软件下载等等的任何保护内容的传递是有用的。另外，正如这里使用的，“受保护的”内容应当被广义地看作为覆盖已知的或以后开发的、用于保护内容不受到在给定的最终用户机器处的未验证的活动影响的方法。
另外，如果需要的话，CDN可以实施密钥管理基础结构，以管理通过CDN许可服务器进程生成的许可密钥。
在描述了我们的发明后，我们要求的权利要求为如下。
权利要求
1.一种分布式网络，在该分布式网络中，内容供应商从由内容传递网络服务供应商管理的服务器卸载用于传递的给定内容，其中使用数字权利管理方案来保证给定内容的安全，改进包括一组分布式的许可服务器进程，每个许可服务器进程用来生成许可，给定的最终用户利用该许可获得对给定内容的给定权利；其中该组分布式的许可服务器进程以非集中的方式运行，不访问与请求给定内容的最终用户相关的验证信息。
2.在如权利要求1所述的在分布式网络中，其中，给定内容是媒体流。
3.在如权利要求2所述的在分布式网络中，其中媒体流是直播流或者被存储在分布式网络中的点播流。
4.在如权利要求1所述的在分布式网络中，其中许可服务器进程包括第一代码，用来确定与最终用户许可请求有关的给定令牌的有效性；和第二代码，响应于第一代码生成许可。
5.在如权利要求1所述的在分布式网络中，其中许可中的给定权利是由许可服务器基于存储在许可服务器中的元数据文件中的数据确立的。
6.在如权利要求1所述的在分布式网络中，其中许可中的给定权利由许可服务器基于给定令牌中的数据按请求动态地确立。
7.一种分布式网络，在该分布式网络中，内容供应商从由内容传递网络服务供应商管理的服务器卸载用于传递的给定内容，其中通过商业逻辑获得访问给定内容的授权，并且使用权利管理方案保证给定内容的安全，改进包括一组分布式的许可服务器进程，每个许可服务器进程用来生成许可，给定的最终用户利用该许可获得对给定内容的给定权利；其中该组分布式的许可服务器进程以非集中的方式进行，不访问商业逻辑或与请求给定内容的最终用户有关的任何验证信息。
8.一种运行在分布式网络中的设备，在该分布式网络中，内容供应商卸载用于传递的给定内容，其中通过第三方商业逻辑获得访问给定内容的授权，并且使用权利管理方案保证给定内容的安全，包括处理器；操作系统；至少一个内容服务器进程，用于在由第三方商业逻辑进行验证后将给定内容提供给发出请求的最终用户客户机，利用权利管理方案保证所述给定内容的安全；以及许可服务器进程，用来生成许可，给定的最终用户利用该许可获得对由内容服务器进程提供的给定内容的给定权利，其中许可服务器进程在不访问商业逻辑或与请求给定内容的最终用户有关的任何验证信息的情况下运行。
全文摘要
本发明在分布式网络操作环境下(例如CDN)实施，其中内容供应商从由服务供应商(诸如CDN运营商)管理的服务器(例如，CDN边缘服务器)卸载用于传递的给定内容。假设使用数字权利管理方案来保证给定内容的安全。根据本发明，提供一组分布式的许可服务器进程，用以管理内容许可的发放。每个许可服务器进程用来生成许可，给定的最终用户利用该许可得到对给定内容的给定权利。该组分布式的许可服务器进程以非集中的方式进行，而不访问第三方商业逻辑(例如，付费机制)或与请求给定内容的最终用户有关的任何验证信息。
文档编号G06Q10/00GK101065768SQ200580027085
公开日2007年10月31日 申请日期2005年6月10日 优先权日2004年6月10日
发明者拉克施米纳拉亚南·古纳希兰, 阿布杜尔·萨拉姆·菲萨尔·帕丁加莱维迪尔 申请人:阿卡麦科技公司