用于播放利用DRM(数字权利管理)方案保护的数字内容的方法和相应的系统

摘要

本发明涉及用于播放受到DRM方案保护的数字内容的方法和系统，其中所述数字内容被存储在服务器中并且被下载或流送到用户设备。所述方法包括：执行用户设备内部的DRM应用，所述DRM应用实施服务器与用户设备的本地播放器之间的代理；把DRM代理应用连接到服务器，选择将要下载的数字内容，并且获取相应的远程播放列表。此外，所述方法还包括：把远程播放列表变换成具有可以从本地播放器读取的格式的本地播放列表，并且在本地播放器内部执行本地播放列表的多个本地分组。

说明书

技术领域

本发明涉及一种用于播放利用DRM方案保护的数字内容的方法和相应的系统，其中所述数字内容被存储在服务器提供商处并且被下载到用户设备中以供解密和播放。更具体来说，本发明涉及一种前述类型的方法和系统，其中所述DRM方案要求通过用户设备的特定播放器来播放所述数字内容。

背景技术

利用DRM（数字权利管理）来保护数字内容的已知方法防止未经授权的再分发并且限制用户能够拷贝所购买的内容的方式，从而限制近来特别随着对等文件交换程序的广泛使用而日益增多的对于商业数字素材的盗版。

可以通过把防止将数字内容拷贝到未经授权的用户设备的代码嵌入在所述数字内容中而实施一种用于保护数字内容的已知方法。例如通过指定可以在期间访问内容的时间段或者通过限制可以在其上安装或读取内容的设备的数目来提供进一步的保护。更具体来说，受保护数字内容和代码被从客户端传送到购买所述内容的用户的设备。数字内容被存储在客户端中或者通过来自网络的流送而从客户端获取。当用户设备接收到具有受保护格式的数字内容时，其利用所述代码对所述数字内容进行解密。

前面提到的方法的限制在于，客户端或内容提供商不仅负责以受保护格式递送数字内容，而且还负责实现DRM，即生成并存储用于用户设备的代码。换句话说，所述方法对于客户端具有显著影响。此外，这种方法还存在安全性方面的限制，这是因为允许读取受保护数字内容的代码被传送到用户设备并且最终对用户可用；换句话说，所述代码不会在用户设备中读取受保护数字内容之后被消耗或破坏，而是仍然对用户可用。

可能希望减少保护数字内容对于客户端或内容提供商的影响并且增强DRM的安全性，从而使得在用户设备一侧不容易获得允许用户设备读取数字内容提供商的代码，从而克服当前方法的限制。

下面将讨论不同类型的内容服务以及每一种类型中的常见DRM问题。

在租赁服务中，消费者购买对于一个固定时间段使用内容的权利。在例如视频点播（VOD）之类的租赁服务中，内容使用寿命通常较短（例如24小时），并且在单个设备上观看内容。这可能是将以消费者友好的方式实施的最简单的服务类型。

在订购租赁服务中，消费者可以访问一个很大的内容库。例如在流送视频订购服务中，订户可以支付月费以便访问多种电影或电视节目。在订购租赁服务中，消费者对于一个较长时间段获得内容使用权，因此可以考虑例如内容的便携性（在设备之间移动内容或者在不同设备上多次访问内容）、设备升级以及对于DRM技术的升级之类的问题。可以为订户发出新的执照以允许下一个订购时段的访问。这一处理应当尽可能是无缝的，并且不会对于访问订购内容造成任何中断。

在“购买拥有”模型中，消费者购买对于所期望时间长度的消费内容的权利。这种服务类型中的一项常见要求是在设备损坏、被盗或升级的情况下备份内容和执照的能力。可能还需要应对DRM技术的升级，从而可以在升级之后购买新的内容但是仍然可以使用先前购买的内容。消费者常常将期望在多个设备上访问内容。

一些DRM内容服务仅仅向一种类型的设备递送内容。更加常见的是，内容发行商希望向例如Android电话和iPhone之类的多种不同设备递送内容。对于不同设备和操作系统需要相同DRM技术的多种实现方式。DRM客户端可以与媒体播放器、下载管理器、文件系统以及设备上的其他组件集成在一起。其结果是，DRM客户端常常在制造或供应期间被安装在设备上。Microsoft Playready DRM客户端例如可能无法在内容服务的目标消费者所使用的所有设备上都可用。

此外，许多DRM技术把执照绑定到特定设备。这意味着必须为消费者希望在其上播放内容的每一个设备发出新的执照，并且可能必须跟踪特定消费者所拥有的设备。

内容可以被下载或流送。流送内容常常被存储在服务器侧而不是被存储在客户端设备上。这样做的优点在于设备升级或DRM技术的更新所造成的问题较少，这是因为早前的DRM内容不必被移植到新的设备或DRM版本。

下面将阐述各种内容服务的实例以及与之相关联的典型DRM问题。

视频点播包括设计租赁的服务类型，例如对于电影和电视节目的24小时访问。内容递送涉及下载或流送，并且设备包括PC或已连接TV。这种服务类型的DRM可用性问题很少，前提是DRM客户端对于所有目标设备类型都可用。

“无限制”视频订购服务包括涉及订购租赁和流送内容递送的服务类型。设备包括PC、已连接TV、平板电脑和移动电话。使得对于所有目标设备类型都可用的DRM客户端可能需要附加的开发。续订应当尽可能透明，并且用户在内容访问中不应当遇到任何中断。例如执照预先递送和沉默执照递送之类的特征便于“不可见”续订。

视频下载拥有是一种购买拥有服务类型，其内容递送是通过下载。设备包括PC、已连接TV、平板电脑和移动电话。应当在服务器侧备份内容和执照，以便允许用户在设备丢失或升级时移动所述内容和执照。在升级DRM技术时，早前的内容必须仍然可播放。在重大升级中，可能需要向订户递送先前购买的内容的新版本。

已经知道，一种用于播放受到DRM方案保护的数字内容的方法提供：只有在获取执照并且将其用来解密从服务器提供商处下载的内容的情况下，用户设备才对所述内容进行播放。DRM（数字权利管理）方案还可能要求利用特定播放器来播放数字内容，所述特定播放器被允许对以流送方式从服务器下载或接收的数字内容进行解密。此外，来自服务器提供商的流送格式可以由DRM方案提供。

在这方面，用户设备可能存储有不同于DRM方案所请求的特定播放器的本地播放器。术语“本地播放器”指的是由用户设备的制造商与操作系统一起存储的播放器；本地播放器可以比“非本地”播放器更快，这是因为其与操作系统的集成度更高。举例来说，本地播放器可以使用操作系统的加速器来改进提供电影时的性能。

因此，如果DRM方案所请求的特定播放器不是用户设备的本地播放器，则数字内容再现的性能可能会降低。

在这方面，从iPhone移动用户设备的本地播放器（即从Quick TimePlayer）无法读取及解密利用Microsoft的DRM PlayReady方案下载或流送的数字内容。在这种情况下，必须把特定的非本地播放器下载到iPhone移动设备中以用于解密及播放这样的内容。由于与用户设备的操作系统（即iOS）的通信较慢，因此iPhone内部的非本地播放器的性能可能会低于Quick Time Player。

因此，可能需要解决的一个技术问题是如何在不下载特定播放器的情况下播放利用DRM方案保护的数字内容，但是DRM方案又需要这样的特定播放器来解密及播放从服务器提供商下载或流送的数字内容。另一个技术问题在于，特别对于在用户设备中解密及播放数字内容的阶段，如何提供一种具有安全并且得到改进的性能和灵活性（例如在不会泄露解密密钥和内容的情况下）的用于安全地播放通过DRM方案保护的数字内容的方法，从而克服当前影响现有技术方法的限制。

发明内容

作为本发明的基础的方法是在用户设备内部存储一项应用，其把利用预定DRM方案保护的数字内容转换成可由用户设备的本地播放器读取的数字格式。所述应用也被称作DRM代理应用，其通过DRM服务器应对解密、执照获取和权利管理，所述DRM服务器通过网络连接到用户设备。所述应用作为本地web服务器运行在用户设备上，例如运行在iPhone用户设备上，并且与用户设备的本地播放器进行通信。

根据本发明的一个实施例，DRM应用支持来自远程服务器的Apple HTTP流送还有Microsoft Smooth Streaming，从而允许本地播放器播放根据不同DRM流送协议管理的数字内容。有利的是，数字内容执行的性能得以提高，这是因为本地播放器被专门设计成与用户设备操作系统和DRM代理应用进行通信。

根据前面所报告的方法，所述技术问题通过一种用于播放受到DRM方案保护的数字内容的方法得以解决，其中所述数字内容被存储在服务器提供商处并且被流送到用户设备以供播放，所述方法包括：执行用户设备内部的DRM应用，所述应用将服务器和用户设备的本地播放器对接；把DRM应用连接到服务器，选择将要下载的数字内容，并且获取相应的远程播放列表；把远程播放列表变换成具有可以从本地播放器读取的格式的本地播放列表，并且在本地播放器内部播放本地播放列表的多个本地分组。播放本地播放列表的步骤对于每一个分组包括：从DRM应用向所述服务器请求相应的远程分组；向DRM应用返回远程分组；获取用以解密远程分组的执照；以及在DRM应用中解密远程分组，并且把已解密分组返回到本地播放器以作为将被显示的本地分组。

有利的是，即使DRM方案要求使用不同的特定播放器，仍然使用用户设备的本地播放器来播放内容；本地播放器与用户设备的操作系统之间的通信比这样的操作系统与特定的非本地播放器之间的通信更快。实际上，本地播放器可以使用由用户设备的操作系统提供的加速器来提供数字内容。

在本发明的一个实施例中，用户设备是iPhone，并且DRM方案是AppleHTTP流送或Microsoft Smooth Streaming，其中从远程服务器下载或流送内容。优选的是，根据该实施例，本地播放器是Quick time Player。所述用于播放内容的方法还支持来自例如HBO之类的电视内容提供商的流送。因此，可以使用用户设备的本地播放器（例如iPad、iPhone或Android的本地播放器）来直接播放从HBO流送的电影。

根据本发明的一个方面，获取执照的步骤包括：把DRM代理应用连接到DRM服务器，并且发送包括在已加密数字内容中的URL以用于获取执照。有利的是，执照请求被嵌入在已加密数字内容中。

优选的是，在激活本地播放器之前执行执照请求，并且只有在从DRM服务器获取执照的情况下才激活本地播放器。有利的是，根据本发明的该方面，如果没有获取执照，则不花费时间来激活本地播放器。

根据本发明的一个实施例，远程播放列表的所有远程分组都与相同的执照相关联，并且仅仅执行一次获取步骤，优选地是对于远程播放列表的第一个远程分组执行。

在另一个实施例中，远程播放列表仅仅包括一个远程分组以作为对应于全部数字内容的一个完整文件；根据该实施例，DRM代理应用把该远程分组划分成由本地播放器分开执行的多个本地分组。

所述方法支持基于Microsoft Smooth Streaming的DRM方案，在这种情况下，获取相应的远程播放列表的步骤包括获取SmoothStreaming（平滑流送）播放列表和Manifest（清单）文件。DRM代理可以被配置成在远程播放列表中的各个可用比特率当中的一个比特率下操作。

通过后面给出的描述，根据本发明的其他优点和特征将变得显而易见。

附图说明

图1是示出了根据本发明的系统组件和方法阶段的方块图。

图2是示出了根据本发明的另一个实施例的系统组件和方法阶段的方块图。

图3是示意性地表示根据本发明的一个实施例的系统和方法的方块图。

图4是示出了根据本发明的一个实施例的与多媒体播放器一起操作的用户设备中的代理服务器和多媒体服务器的示意图。

图5是示意性地示出了根据本发明的一个实施例的用于播放利用DRM方案保护的数字内容的方法的通信时序图。

图6是示意性地示出了根据本发明的一个实施例的用于播放利用DRM方案保护的数字内容的方法的通信时序图。

图7是示意性地示出了根据本发明的一个实施例的用于播放利用DRM方案保护的数字内容的方法的通信时序图。

图8是示出了根据本发明的一个实施例的实施DRM代理（proxy）的代理程序（agent）与播放通过DRM方案保护的数字内容的用户设备的其他应用的集成的示意图。

图9是示出了根据本发明的一个方面的当在代理服务器与多媒体服务器之间使用例如Apple HTTP流送协议之类的特殊协议时的示例性通信流程的示意图。

图10是示出了根据本发明的一个方面的在用户设备与多媒体服务器之间采用的一些安全性细节的示意图。

具体实施方式

下面将参照附图更加全面地描述本发明，在附图中示出了本发明的优选实施例。但是本发明可以通过许多不同形式来具体实现，而不应当被理解成受限于这里所阐述的实施例。相反，提供这些实施例是为了使得本公开内容透彻且完整，并且将向本领域技术人员完全传达本发明的范围。相同的附图标记始终指代相同的元件。在附图中为了更加清楚起见可能夸大了一些层和区段的尺寸。

参照图1和2，其中示意性地表示根据本发明的用于利用DRM保护数字内容的系统和方法，其中客户端站点2或内容提供商与用户设备3通信以便通过受保护格式传送数字内容。通常来说，客户端站点2存储数字内容（例如图1），或者以流送形式从网络获取数字内容（图2）。

举例来说，用户设备3可以是蜂窝设备，其能够通过无线（即蜂窝）通信网络发送及接收呼叫、消息、电子邮件和数据。但是也可以使用其他类型的无线设备（和网络），比如无线局域网（WLAN）设备。此外，用户设备3可以被允许通过多于一种类型的无线网络（比如通过蜂窝网络和WLAN）进行通信。

根据本发明，DRM服务器1生成用于客户端站点2内的加密处理和用户设备3内的解密处理的密钥。更具体来说，所述方法包括以下阶段。密钥生成阶段，其中DRM服务器1导出用于保护内容的至少一个密钥；密钥传送阶段，其中把密钥从DRM服务器1传送到客户端站点2；以及内容递送阶段，其中客户端站点2把受保护内容传送到用户设备3。

为了解密数字内容，用户设备3从DRM服务器1请求（多个）密钥，所述请求可以包括密钥标识，其与受保护内容一起由客户端站点2传送到设备3，并且还被DRM服务器1用来导出用于设备3的所述一个或多个密钥。

有利的是，所述密钥由DRM服务器1提供到客户端站点2和用户设备3，但是不在客户端站点2与用户设备3之间传送。此外，可以在DRM服务器1中生成几个密钥并且将其传送到客户端站点2以便“直接（on thefly）”对相应的几项数字内容进行加密，例如用户设备3可以从DRM服务器1请求几个密钥以用于解密各项受保护数字内容。

在加密数字内容之前，从客户端站点2的DRM分批保护器模块21请求密钥生成阶段的执行。在接收到来自DRM服务器1的加密密钥之后，DRM分批保护器模块21优选地离线加密数字内容。更具体来说，DRM分批保护器模块21从本地目录或者从URL（统一资源定位符）读取数字内容，并且从由DRM服务器1提供的KEY_FILE（密钥文件）获取加密密钥。优选地，KEY_FILE受到口令保护。

密钥生成阶段可以包括执行存储在DRM服务器1内部的SOAP（简单对象访问协议）API（应用程序接口），并且作为输入接收将被加密的数字内容的标识符（例如电影的标题）以及与其中数字内容被划分的分段或流的数目相关联的密码周期数（CPN）。SOAP API的输出是将被用于在多个分段或流中加密数字内容的多个加密密钥。

DRM分批保护器模块21把CPN和数字内容的标识符传送到DRM服务器1，并且作为响应从DRM服务器1接收所述多个加密密钥。根据本发明的一个方面，把增大的CPN从DRM分批保护器模块21传送到DRM服务器1，并且可以接收另外的加密密钥以便加密另外的数据分段或流。

在加密密钥的该另一请求中，内容标识符不被修改。优选地，CPN是被用于密钥调度目的的一个无符号64比特整数，这是因为即使对于相同的内容标识符，不同的数字也会产生不同的内容加密密钥。

根据一个优选实施例，DRM分批保护器模块21还传送被用于加密数字内容的DRM保护系统的类型；所述类型例如可以包括作为DRM保护系统的“PlayReady”、“Windows媒体DRM”和“Apple HTTP流送”，或者使用对称密钥进行保护的任何其他DRM系统。

在所使用的DRM保护系统是“PlayReady”、“Windows媒体DRM”和“Apple HTTP流送”的情况下，后文中将给出从DRM服务器1到客户端站点2（即到DRM分批保护器模块21）的输出或响应的一些实例。

利用PlayReady，密钥供应响应可以包括：-作为一个16字节阵列的密钥ID，其包括针对PlayReady以及针对由用户设备查询的授权API的内容的标识，正如从后面的描述可以明显看出的那样。所述密钥ID还是PlayReady受保护报头的一部分；-作为一个至少由30个字节构成的字节阵列的种子，其中包括被用来与密钥ID相组合地生成内容密钥的种子；-作为一个16字节阵列的内容加密密钥，其被用来对内容进行AES-128加密。可以基于密钥ID和种子确定性地计算内容加密密钥，但是作为一个优选实施例，其特别由SOAP API返回。

利用Windows媒体DRM，密钥供应响应可以包括：作为一个16字节阵列的密钥ID，其包括针对Windows媒体DRM以及针对授权API的内容的标识，并且其还是WMDRM受保护报头的一部分；以及作为一个至少由30个字节构成的字节阵列的种子，其包括被用来与密钥ID相组合地生成内容密钥的种子。

利用Apple HTTP流送，密钥供应响应可以包括：密钥ID，即具有针对授权API的内容的标识符的一个16字节阵列；以及内容加密密钥，即包括用于加密数字内容的AES密钥的一个16字节阵列。

下面是根据本发明的一个实施例的用于把外部内容标识符变换成密钥ID、种子和/或内容加密密钥的步骤的实例：

1、给定内容标识符的UTF-8编码，例如标识符“The Family Guy,Season2,Episode6”，作为到MD5算法的输入。

2、对于密码数字的十进制表示（例如“12345”）的UTF-8编码被给作为到相同的MD5算法的输入。

3、计算MD5散列，作为输出返回16字节的阵列（其作为密钥ID）。

4、把密钥ID给作为到密钥管理器表的输入。一项变换通过遍历SHA-256和一个秘密64KB“密钥表”把任何字节阵列转变成另一个32字节阵列。所述密钥表可以是一个256乘256字节的方阵，其包括利用强密码随机数发生器生成的伪随机数。该表可用于DRM服务器1，其例如存在于一个本地文件中。把具有任意长度的初始“内容ID”转变成可以被用作种子的一个32字节阵列，正如本领域技术人员将认识到的那样。

5、把密钥ID和种子作为输入给到一项算法，所述算法的输出为内容加密密钥，其长度优选地是16字节。

如前所述，对于Playready至少返回密钥ID和种子，并且对于Windows媒体也是一样。对于Apple HTTP流送，返回密钥ID和内容加密密钥。

根据本发明，通过避免把密钥存储在DRM服务器内而是通过内部服务器表并且利用密钥标识导出（多个）密钥，获得了DRM处理的更高安全性。

优选地，DRM服务器1与客户端站点2之间的（多个）密钥的传送是通过安全信道进行的，更优选地是带外进行。此外，DRM服务器1与客户端站点2之间的密钥传送受到口令保护。

在本发明的一个方面中，从客户端站点2到设备1的受保护内容的传送是通过流送，其中在传送之前利用由DRM服务器生成的不同加密密钥对每一个流分别进行加密（如图2中所示）。

在本发明的另一方面中，从客户端站点2到设备3的内容传送是在单块中进行的，之前被存储在客户端站点2中。在这种情况下，数字内容已经在客户端的存储装置中本地可用，并且不用从网络获取。

在本发明的一个优选实施例中，所述（多个）密钥仅被用于DRM服务器1与客户端站点2之间的一个通信会话，随后则被标记为被消耗或使用。该实施例提高了DRM的安全性。此外，用户设备3在对受保护内容进行解密之后也消耗（多个）密钥。

受保护内容可以被递送到与客户端站点2相关联的内容递送网络4（其优选地是web服务器或边缘高速缓存网络），以便改进到用户设备3的递送时间。

后面将参照DRM服务器1内部的通信流程更加详细地公开所述方法。

已经知道，应用程序接口（API）是一个特定的规则和规范集合，软件程序可以遵循所述应用程序接口来访问及利用由实施该API的另一个特定软件程序所提供的服务和资源。换句话说，API是不同软件程序之间的接口并且促进其交互，其方式类似于用户接口促进人类与计算机之间的交互。

可以对于应用、库、操作系统等等创建API，以作为定义其“词汇表”和资源请求管理（例如函数调用管理）的一种方式。其可以包括针对例程的规范、数据结构、对象类以及被用来在API的消费者程序与实施者程序之间进行通信的协议。

根据所述方法，SOAP API（其在下文中也被称作密钥供应API）可以被实施DRM保护的任何人使用，例如被具有对流送样本进行加密所需的所有密钥素材的第三方媒体编码器使用。所递送的密钥素材在原理上可以与任何DRM技术一起使用，但是其特别专注于以下环境，其中例如包括Microsoft PlayReady、Apple流送和Windows媒体DRM10.1.x。

这一新的API可以提供对于现场流送情形的支持，其中很重要的是能够甚至在同一现场流内切换内容密钥。出于这些目的，引入“密码周期数”（CPN）的概念。编码器销售商可以通过简单地增大CPN为给定流获得新的加密密钥，而无须改变主内容标识符。

为了便于使用该API，用户被允许传入对于他来说有意义的任何内容标识符，比如：“Title,Season6,Episode2”（或者任何该类字符串）。密钥供应API将利用下面描述的特殊规程把这些内容标识符转变成内容加密密钥。

在这一阶段之后，密钥供应API将返回一个标识符，例如一个16字节的“密钥ID”，其可以在后来从DRM服务器1请求执照时被使用。

所有这些规程都可以在无需把内容ID、加密密钥或种子存储在任何数据库表中的情况下来实施。作为一个实例：

密钥供应公共接口涉及被称作密钥供应的服务。该服务可以在密钥供应请求中接受以下参数：DRM保护系统，例如“PlayReady”、“Windows媒体DRM”和“Apple HTTP流送”的其中之一；外部内容标识符，例如对于内容提供商来说有意义的任何标识符，比如“Title1”或“Title2,Season4,Episode1”；可选的密码周期数，例如可以被用于密钥调度目的的一个无符号64比特整数，即使对于相同的外部内容标识符，不同的数字也将产生不同的内容加密密钥。

密钥供应响应可以是三种类型的其中之一：PlayReady，Windows媒体DRM，或者Apple HTTP流送。PlayReady密钥供应响应：密钥ID，其例如是包含向PlayReady以及后来向授权API唯一地标识内容的密钥ID的一个16字节阵列，其还可能需要是PlayReady受保护报头的一部分；种子，其例如是包含被用来（与密钥ID相组合地）生成内容密钥的种子的一个至少由30个字节构成的字节阵列；内容加密密钥，其例如是可以被用来对内容进行AES-128加密的一个16字节阵列，尽管这可以基于密钥ID和种子而被确定性的计算出，但其出于方便起见而被返回。Windows媒体DRM密钥供应响应：密钥ID，其例如是包含向Windows媒体DRM以及后来向授权API唯一地标识内容的密钥ID的一个16字节阵列，其还可能需要是WMDRM受保护报头的一部分；种子，其例如是代表被用来（与密钥ID相组合地）生成内容密钥的种子的一个至少由30个字节构成的字节阵列。AppleHTTP流送密钥供应响应：密钥ID，其例如是包含后来向授权API唯一地标识内容的密钥ID的一个16字节阵列；内容加密密钥，其例如是包含对内容进行加密所需的AES密钥的一个16字节阵列。

可以提供用于把任意外部内容标识符变换成密钥ID、种子和/或内容加密密钥的一个最终步骤。

后面将详细描述从用户设备向DRM服务器1请求（多个）密钥的阶段。所述请求优选地由另一个API（其也被表示为授权或执照API）服务，并且被存储在DRM服务器1中。授权API向PlayReady、WMDRM或Apple CEK返回执照。所述API将内容标识作为输入并且对于PlayReady或WMDRM将测试作为输入。所述API被编程来应对不同的内容标识：如果接收到内容ID，例如xxxxdomain.com，则获取内容源数据（最明显的是种子）并且传递到应用（例如CrossTalk），从而生成执照；如果以某种特定格式接收到当前ID，例如cid:#yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyydomain.com，其长度为32个字符并且是密钥ID的十六进制编码，则将所述字符转换成一个16字节密钥ID（并且执行后面的步骤）：如果接收到一个16字节密钥ID，则把所述密钥ID作为输入给到密钥管理器表，随后丢弃最后2个字节并且输出一个30字节种子。

随后只有以下3种情况的其中之一可以适用：-PlayReady，密钥ID和种子被作为输入给到执照服务器以便获得执照；-Windows媒体DRM，密钥ID和种子被作为输入给到执照服务器以便获得执照；以及-Apple HTTP流送，密钥ID和种子被作为输入给到一项算法，所述算法将其转变成内容加密密钥。

关于客户端站点2，下面将讨论优选地作为离线内容保护工具的DRM分批保护器的结构和运作细节。通过前面公开的密钥供应API使得对内容进行离线包装的能力成为可能，其允许提前生成所期望数量的内容保护密钥。

DRM分批保护器21可以具有两种操作模式：KEY_FILE（密钥文件）和PROTECT（保护）。当工作在KEY_FILE模式下时，DRM分批保护器21调用指定DRM服务器的密钥供应API，并且获取被输入到一个文件中的指定数量的内容加密密钥。内容加密密钥受到同样在命令行上指定的口令的保护。当工作在PROTECT模式下时，DRM分批保护器21从指定输入目录读取内容，对其进行保护，并且将其写入到指定输出目录。被用于进行保护的密钥是从已在KEY_FILE模式下创建的密钥文件提取的。PlayReady包封保护得到DRM分批保护器21的支持。

根据本发明，可以为DRM分批保护器21增加一种被称作LIVE（现场）的模式。当工作在该模式下时，DRM分批保护器能够加密被现场分段的内容。DRM分批保护器能够从一个目录或者从一个URL读取未经处理的内容。当指定URL时，其应当指向播放列表（主）。所有其他DRM分批保护器属性应当是有效的。应当从密钥文件中取得加密密钥。

当工作在LIVE模式下时，DRM分批保护器21可以执行以下动作：下载主播放列表（如果指定了URL的话）或者从文件系统中读取；读取播放列表并且提取出在主播放列表中指定的子播放列表，或者返回主播放列表；对于每一个子播放列表分出一个线程，其将把未经处理的内容与受保护内容同步；并且DRM分批保护器将持续运行直到其接收到Control-C命令为止，随后各个线程将优雅关停，并且DRM分批保护器将退出。

根据本发明，DRM分批保护器可以被调度成在指定时间间隔下执行。举例来说，默认可以是10s。

在同步内容时，DRM分批保护器21可以施行以下步骤：把播放列表读取到存储器中并且从中获取所有未经处理的内容文件；检查在输出目录中是否已经存在已加密文件版本，如果没有的话则将其添加到新文件列表中；在针对新文件的检查完成之后，输出目录中的不存在于播放列表中的所有旧文件将被添加到旧文件列表中并且将最终被删除。可以如下执行同步处理：删除来自前一次运行的旧文件（这样做是为了防止在某些DRM代理程序可能仍在使用时删除文件）；对新文件进行加密；把新播放列表拷贝到输出目录；以及更新旧文件列表从而将在下一次运行时将其删除。

DRM分批保护器21可以在发生错误时将其记入日志并且继续运行。

在保护期间，当尝试获取在播放列表中指定的内容文件时从所述URL可能发生从未经处理的内容服务器返回404错误的情况。DRM分批保护器21应当在DEBUG（调试）级别把这样的错误记入日志，并且尝试对于线程在所调度的间隔下休眠的一半时间休眠。

如果在尝试刷新播放列表时返回错误，DRM分批保护器21应当在所调度的线程休眠间隔之后重试，如果再次返回相同的错误，则每次返回错误时应当把线程休眠间隔增大2、3、4、5倍。一旦线程休眠间隔被增大到其原始时间的5倍，DRM分批保护器21就应当继续运行直到从服务器接收到有效响应为止。一旦接收到有效响应，线程调度的休眠时间将回到正常。

可以为DRM分批保护器21添加一项属性，其将使得以更加友好的格式重写播放列表文件。这一点可以通过从播放列表和内容文件名称中去除任何非字母和非数字字符以及添加适当的文件扩展名来实现。应被添加到播放列表和内容文件的扩展名应当被作为属性指定，并且例如对于播放列表文件默认地是.m3u8，并且对于内容文件默认地是.ts。

为了满足恒定可用性的要求，可以利用监测更新DRM分批保护器21。这样将允许很容易地检查DRM分批保护器状态，并且在需要时采取任何附加措施。在这里可以重复使用来自DRM服务器的SNMP监测框架。

本发明还涉及一种用于保护数字内容的系统，其包括：DRM（数字权利管理）服务器，其被配置成导出至少一个密钥；以及客户端，其被配置成存储数字内容或者接收将要保护的流送数据内容，从DRM服务器接收所导出的密钥，以及向用户设备传送包括密钥标识的受保护数字内容。DRM服务器被配置成从用户设备接收密钥标识，以便导出用于该用户设备的密钥。

客户端站点2包括DRM分批保护器模块21，其被配置成在加密将要保护的数字内容之前从DRM服务器1请求密钥生成，随后在从DRM服务器接收到作为加密密钥的所导出密钥之后在DRM分批保护器模块中离线施行加密。DRM分批保护器模块21被配置成从一个本地目录或者从一个URL（统一资源定位符）读取数字内容，并且从被DRM服务器提供到DRM分批保护器模块的具有口令保护的密钥文件中获取加密密钥。

DRM服务器1包括SOAP API，其被编程来从DRM分批保护器模块21接收数字内容的标识以及与将在其中加密数字内容的流或分段的数目相关联的一个数字作为输入，并且作为输出返回用于保护数字内容的至少一项代码。在本发明的一个实施例中，所述代码包括密钥ID和种子。DRM分批保护器模块21被编程来从所述密钥ID和种子导出内容加密密钥。在另一个实施例中，SOAP API被编程来向DRM分批保护器模块21直接返回内容加密密钥。

优选地，密钥ID、种子和内容加密密钥的格式遵循多种DRM保护系统，其中例如包括“PlayReady”、“Windows媒体DRM”、“Apple HTTP流送”。

后文中将简要概述根据本发明的一种示例性方法和系统的特征。密钥在DRM服务器1中生成，并且被安全地带外递送到客户端2，优选地是被递送到客户端的分批保护器。所递送的密钥的数目取决于加密任务。从内部密钥表导出密钥，从而在DRM服务器本身当中不存储密钥。密钥由密钥id标识并且构成密钥导出函数的基础，密钥表可以在每个客户端的基础上存在，从而通过在各个客户端之间分离密钥空间进一步提高了安全性。利用所选择的口令对所递送的密钥文件进行加密。

利用密钥对分批保护器进行配置，并且其随后开始保护内容。该内容可以是存储在客户端上的盘中的一些文件或者所获取的流送资源，并且“直接”对其进行保护。按照来自先前递送的安全密钥文件的要求消耗密钥。随后密钥被标记为已消耗。

受保护内容被递送到客户端的内容递送网络，例如简单的web服务器或边缘高速缓存网络。这取决于客户端应当向用户设备递送内容的速度如何。

设备下载内容，检测出其受到DRM保护，并且发起执照获取。

DRM服务器接收执照请求，并且基于所接收到的信息生成加密密钥。密钥id被用来导出密钥。其作为执照获取协议的一部分而被装运。设备消耗执照并且可以解密内容。

现在将参照图3-8描述本发明的另一方面。

图3示意性地表示请求数字内容的用户设备100，向用户设备提供内容的多媒体服务器200或提供商服务器，以及管理DRM方案的执照的执照服务器300或DRM服务器。

参照图3，用户设备100包括多媒体播放器、DRM融合代理程序120、DRM存储库130、代理服务器150和本地文件系统140。代理服务器150被存储在用户设备中，并且向多媒体播放器110提供HTTP流送服务。

用户设备100包括用于播放数字内容的多媒体播放器110或本地播放器，用于下载及解密内容的DRM融合代理程序120，用于存储加密密钥的DRM存储库130，以及本地文件系统140。有利的是，用户设备100还包括DRM应用（其也被表示为代理服务器150），其允许多媒体播放器110播放根据不同DRM方案提供的预定HTTP流送服务。

更具体来说，代理服务器150作为用户设备100上的本地web/流送服务器运行，并且把静态或流送内容转换成可从多媒体播放器110读取的流送格式。

举例来说，用户设备100可以是iPhone，并且多媒体播放器110可以是iPhone的本地播放器，即Quick Time Player，其被用来根据Apple HTTP现场流送方案来下载及播放数字内容，但是本发明的范围不限于此。

代理服务器150可以通过DRM融合代理程序120应对执照获取、权利管理。根据本发明，代理服务器150把根据其他DRM方案提供的HTTP流送转换成可由iPhone本地播放器110读取的格式。

多媒体服务器200可以包括如图1中所表示的前端媒体服务器210和内容储存库220。前端210从用户设备100接收针对访问多媒体内容的请求，并且在处理之后发送响应。更具体来说，前端210访问内容储存库220并且获取用户设备100所请求的多媒体内容，同时多媒体服务器200支持几种通信协议，比如Apple HTTP现场流送、Microsoft平滑流送或者针对用户设备的静态文件传送。

在多媒体服务器200与代理服务器150之间使用的具体协议不限于前面提供的实例。

图4示意性地表示出用户设备100中的代理服务器150（或DRM应用）的各个组件的更加详细的视图，其中用户设备100与多媒体播放器110（或本地播放器）一起操作并且与多媒体服务器200或服务器提供商进行通信。在所描述的实例中，平滑流送服务器（IIS7）被用作多媒体服务器200，并且众所周知的所谓的PlayReady标准被用作DRM标准。用户设备100的多媒体播放器110支持HTTP协议以用于流送。

后面将讨论涉及用户请求或者在用户请求之后的处理步骤或阶段。每一个步骤在图4中具有相应的附图标记。后面将详细解释每一个步骤。

首先在步骤1中，多媒体播放器110从GUI接收“播放电影”的指示。为用户呈现一个图形接口，从而允许他/她播放与特定平滑流送URL相关联的电影。随后在步骤2中，可下载代理程序API接收所述平滑流送URL，并且从web服务器（例如IIS7）下载平滑流送清单。在随后的步骤3中，web服务器返回平滑流送清单。平滑流送清单可以包括播放列表。

此时，API(2)应用某种相对直接明了的变换，以便将其变换成HLS播放列表。所述转换可以如下工作：

a、创建指向各个特定于比特率的播放列表的主播放列表，其中特定于比特率的播放列表的数目与对应于视频流的<QualityLevel>（质量水平）条目的数目一样多。

b、对于每一个<QualityLevel>条目，创建一个特定于比特率的播放列表。这些播放列表当中的每一个将包含一定数目的TS分段，从而足以使得每一个分段将具有近似10秒的长度。举例来说，原始的平滑流送清单将包含分别代表一个平滑流送片段的20个<c>条目。这些片段当中的每一个可以具有3秒的d（持续时间）属性。在这种情况下，最终播放列表将具有总共7个TS分段：其中6个为约9秒，最后一个为约6秒。

c、每一个TS分段实际上是指向一个随机化端口上的本地主机（即所述设备本身）的一个（混淆的）URL。

此外，此时可下载代理程序API在创建HLS播放列表时所使用的端口上启动一个本地HTTPS侦听器。随后在步骤4中，调用（call）PlayReady执照服务器300以进行干预。如果平滑流送清单包含<Protection>（保护）元素，则其内容受到DRM保护。在这种情况下，所述API利用包含在所述清单中的PlayReady内容报头从执照服务器请求并接收执照。所述API向本地播放器110发送播放列表。

在步骤5中，本地播放器110例如利用Apple的比特率节流算法将挑选最适当的比特率，并且尝试在该比特率下顺序地播放各个分段。其通过这样做将找到本地web服务器150。应当提到的是，本地播放器110不需要对于实际的网络状况具有完全的掌握，这是因为其将仅与本地web服务器150进行通信而不是与位于因特网上的内容服务器200进行通信。

这意味着如果本地播放器110正在使用某种试探算法来尝试估计可用带宽，其可能无法这样做，除非本地web服务器150以某种方式在本地接口上模拟这些状况，例如通过对数据递送速率进行节流以便匹配WAN接口的数据递送速率。因此，根据本发明，对于数据递送速率的这一节流动作会对例如HLS之类的流送协议造成重要影响，这是因为其仅仅使用这些算法来决定将要播放哪一个流。

随后在步骤6中，本地HTTPS服务器150可以从本地播放器接收三种可能类型的请求：

a、主播放列表请求。在这种情况下，本地服务器将提供起初计算的主HLS播放列表。

b、特定于比特率的播放列表请求。在这种情况下，本地服务器将提供起初计算的所请求的特定于比特率的HLS播放列表。

c、单一TS分段。在这种情况下，本地web服务器将组装一个TS分段，正如后面在步骤7到11中所描述的那样。

传入本地HTTPS请求包含用户想要获取的平滑流送片段的起始时间标记，步骤7。所述API随后使用一个算法集合来做出以下确定：

a、需要多少平滑流送片段以达到总共10秒；

b、相应的音频片段的起始时间标记；以及

c、需要多少音频片段。

此时，HTTP客户端将向平滑流送服务器施行一定数目的并行HTTP GET（HTTP获取）请求，以便获取所有这些视频和音频平滑流送片段。随后，步骤8，web服务器返回所有的所请求平滑流送片段，其在此时仍然是PlayReady DRM加密的。

如果下载的片段被加密，则在步骤9中，DRM代理程序120将在存储器130中利用先前获取的执照对其进行解密。提供另外的步骤10，其中随后对平滑流送片段进行解析，以便提取出未经处理的H.264流和未经处理的AAC流。所有未经处理的H.264流随后被连续在一起以便达到大约10秒的长度，并且对于所有未经处理的AAC流也是一样。

在步骤11中，MPEG2传输流多路复用器组件取得连续的H.264流和连续的AAC流并且将其多路复用在一起，从而确保时间标记是同步的。其从而生成MPEG2传输流分段。该分段在编号为12的步骤中被返回到本地HTTPS服务器150。HTTPS服务器150通过在步骤13中返回多路复用的TS分段而满足本地请求，本地播放器110按照正确的序列顺序播放所述多路复用的TS分段。

因此，前面描述的方法允许利用Microsoft平滑流送编码以及利用Microsoft PlayReady DRM编码的内容到达iOS设备并且被平滑地播放，同时保留平滑流送协议的自适应流送能力。

此外，所述方法使得有可能同时保持该内容尽可能长时间地受到DRM保护，以避免窥探、拦截和捕获。换句话说，所述方法允许对于iOS环境上的具有本地播放器的可下载代理程序实现受到DRM保护的平滑流送库。

参照图5，该图示意性地表示出根据本发明的用于播放数字内容的方法，其中在该例中，iPhone的DRM代理与相应的Quick time Player通信并且通过Apple HTTP流送与HTTP流送远程媒体服务器进行通信。用户设备30从GUI（图形用户接口）中的内容列表选择数字内容；从用户的角度来看，所述应用简单地打开本地播放器Quick time Player，其在很短的延迟之后开始播放内容。

但是可以执行对于用户隐藏的以下步骤：DRM代理显示具有内容列表的GUI；所述列表是从网站获取的或者被硬编码在所述应用中；用户选择所期望的内容，优选地在内容与播放列表之间存在一一对应关系，因此DRM代理可以检测到对于用户所请求的内容将从服务器获取哪一个播放列表；DRM代理获取原始播放列表，比如HarryPotter.m3u，其例如包括以下分组：“http://mediaserver/packet1.ts”、“http://mediaserver/packet2.ts”...；DRM代理把所述播放列表变换成本地播放列表（在本发明的一个方面中，经过变换的播放列表例如是HarryPotter-local.m3u，其把真实的主机名称/端口替换为本地主机名称/端口“http://localhost:9999/packet1.ts”、“http://localhost:9999/packet2.ts”...）；DRM代理把经过变换的播放列表传递到本地播放器，比如Quick time Player；本地播放器被允许读取M3U格式，其从本地播放列表请求第一个文件，即http://localhost:9999/packet1.ts；DRM代理对主机名称应用逆变换，并且从媒体服务器请求http://mediaserver/packet1.ts；媒体服务器传送相应的分组packet1.ts，更具体来说，packet1.ts是受到PlayReady封装加密的；DRM代理调用（call）DRM服务器中的DRM代理程序，检查其是否具有对应于packet1.ts的执照，并且如果没有检测到执照，则DRM代理调用（call）DRM代理程序并且导览到包括在已加密内容的报头中的沉默执照获取URL，例如http://drmserver/licenseacq.asmx，并且在这一点上根据本发明的一个方面，所有分组packet1.ts、packet2.ts在DRM方面具有相同的内容标识（其例如对于整部电影都是相同的），因此共享相同的执照/解密密钥（在这一点上，在本发明的一个不同实施例中，执照获取在以所述播放列表启动本地播放器之前开始；这样做的有利之处在于，如果无法获得执照，则不需要启动本地播放器）；DRM服务器沉默地返回有效执照；DRM代理调用（call）DRM融合代理程序并且在存储器中对packet1.ts进行解密；以及DRM代理把已解密的packet1返回到本地播放器，本地播放器向用户显示视频分组。

根据本发明的另一个实施例，DRM代理不进行解密而是留下每一个分组被加密。其在播放列表的顶部插入EXT-X-KEY项目，这例如是利用被用在PlayReady加密中的相同的AES-128密钥而实现的。DRM代理取代对分组进行解密，而是将仅仅继续去除PlayReady封装报头，从而仅仅留下未经处理的AES-128加密的数据。DRM代理随后将该未经处理的数据传递回到本地播放器。本地播放器利用EXT-X-KEY获得解密密钥并且由其自身对分组进行解密。

本地播放器请求第二播放列表项目http://localhost:9999/packet2.ts。DRM代理调用（call）DRM代理程序并且检查其是否具有对应于packet2.ts的执照，在前面给出的实例中，即所有分组都具有相同的解密密钥，因此可以获得执照密钥。DRM代理调用（call）DRM代理程序，在存储器中对packet2.ts进行解密。

DRM代理向本地播放器返回已解密的packet2，本地播放器向用户显示视频分组。对于所有视频再现重复最后的这四个步骤。

参照图6，该图示意性地表示出根据本发明的另一方面的用于播放数字内容的方法。在该例中，iPhone的DRM代理与相应的Quick time Player通信以播放静态文件。更具体来说，执行以下步骤：DRM代理示出具有内容列表的GUI。该列表可以从网站获取或者被硬编码在所述应用中；用户选择所期望的内容；DRM代理获取整个经过PlayReady封装加密加密的文件HarryPotter-encrypted.mp4；DRM代理在尚未解密该文件的情况下创建一个新的本地播放列表，该新播放列表例如是HarryPotter-local.m3u，其具有以下形式：“http://localhost:9999/packet1.ts”、“http://localhost:9999/packet2.ts”、“http://localhost:9999/packet3.ts”，在这一步骤中，DRM代理使用试探法基于内容长度来确定将要使用的分组数目（“N”），这是因为事先在存储器中解密整部电影对存储器的消耗非常大；DRM代理把经过变换的播放列表传递到本地播放器；检测到M3U格式的本地播放器从其播放列表请求第一个文件，即http://localhost:9999/packet1.ts；DRM代理检查是否有执照可用于整个电影文件，如果没有检测到执照，则如前所述，DRM代理调用（call）DRM代理程序并且导览到包含在已加密内容的报头中的沉默执照获取URL，例如http://drmserver/licenseacq.asmx（此外在该例中假设仅有一个DRM内容ID（其例如对于整部电影是相同的），因此所有分组都共享相同的执照/解密密钥），根据一个不同实施例，执照获取在调用本地播放器之前开始；DRM服务器沉默地返回有效执照；DRM代理调用（call）DRM代理程序并且在存储器中解密N分之1的电影加上足以到达下一个MPEG2边界的数据，这就是已解密的packet1，并且在这一点上，为了符合HTTP流送规范，每一个分组都终止在MPEG2边界上并且还有一些附加的限制；DRM代理把已解密的packet1返回到本地播放器，其向用户显示视频分组。

同样在该例中，根据本发明的另一个实施例，DRM代理完全不进行解密而是留下整部电影被加密。其在播放列表的顶部插入EXT-X-KEY项目，这例如是利用被用在PlayReady加密中的相同的AES-128密钥而实现的。DRM代理取代对电影进行解密，而是继续去除PlayReady封装报头，从而仅仅留下未经处理的AES-128加密的数据，并且随后简单地切断长度为(电影长度)/(分组数目)的仍被加密的分组。DRM代理随后将该未经处理的数据传递回到本地播放器。本地播放器利用EXT-X-KEY获得解密密钥并且由其自身对分组进行解密。

本地播放器请求第二播放列表项目http://localhost:9999/packet2.ts。DRM代理调用（call）DRM代理程序并且检查其是否具有对应于整个电影文件的执照。如果所有分组都具有相同的解密密钥，则可以获得所述执照。DRM代理调用（call）DRM代理程序并且在存储器中解密接下来的N分之1的电影加上足以到达下一个MPEG2边界的数据，即已解密的packet2。DRM代理把已解密的packet2返回到本地播放器，其向用户显示视频分组。重复最后的四个步骤以便显示所有的数字内容。

参照图7，该图示意性地表示出根据本发明的另一方面的用于播放数字内容的方法。在该例中，iPhone的DRM代理与相应的Quick time Player并且与来自远程服务器的Microsoft平滑流送进行通信以播放数字内容。更具体来说，执行以下步骤：DRM代理示出具有内容列表的GUI，该列表可以从网站获取或者被硬编码在所述应用中；用户选择所期望的内容；优选地，在内容与播放列表之间存在一一映射，从而DRM代理检测到将从服务器获取的播放列表；DRM代理获取原始平滑流送播放列表和清单文件。

DRM代理把所述播放列表变换成本地播放列表，经过变换的播放列表（HarryPotter-local.m3u）具有与原始清单相同数目的分组，但是指向本地DRM代理上的“文件”：“http://localhost:9999/packet1.ts”、“http://localhost:9999/packet2.ts”...；DRM代理把经过变换的播放列表传递到本地播放器，预期播放列表名称不会在UI中的任何地方出现；理解M3U格式的本地播放器从其播放列表中请求第一个文件http://localhost:9999/packet1.ts。

DRM代理服务器播放列表中给出的各个比特率当中选择适当的比特率。在这一点上，根据本发明的第一方面，比特率是恒定的。DRM代理把播放列表条目变换成符合平滑流送URL格式的HTTP GET请求（http://mediaserver/QualityLevels(chosenBitrate)/Fragments(video=startTime001)），并且把该请求发送到媒体服务器。媒体服务器提供开始于startTime001的视频分组。所述分组受到PlayReady封装加密。DRM代理调用（call）DRM代理程序并且检查其是否具有对应于整部电影的执照。

如果执照不可用，则DRM代理调用（call）DRM融合代理程序并且导览到包含在已加密分组的PlayReady报头中的沉默执照获取URL，例如http://drmserver/licenseacq.asmx。同样在该例中，假设所有分组在DRM方面具有相同的内容ID；可以在利用播放列表调用本地播放器之前开始执照获取。DRM服务器沉默地返回有效执照。DRM代理调用（call）DRM代理程序并且在存储器中把视频分组解密成已解密的packet1。在这一点上，如果受到平滑流送支持的编解码器也不是用于HTTP流送的有效编解码器，则在此阶段需要附加的解码/再编码步骤。DRM代理把已解密的packet1返回到本地播放器，其向用户显示视频分组。

在本发明的一个不同实施例中，DRM代理完全不进行解密而是留下每一个分组被加密。其在播放列表的顶部插入EXT-X-KEY项目，这是利用被用在PlayReady加密中的相同的AES-128密钥而实现的。DRM代理取代对分组进行解密，而是继续去除PlayReady封装报头，从而仅仅留下未经处理的AES-128加密的数据。DRM代理随后将未经处理的数据传递回到本地播放器。本地播放器利用EXT-X-KEY获得解密密钥并且由其自身对分组进行解密。

本地播放器请求第二播放列表项目http://localhost:9999/packet2.ts。DRM代理调用（call）DRM融合代理程序并且检查其是否具有对应于整部电影的执照。同样在该例中假设这是成立的。DRM代理调用（call）DRM融合代理程序，并且在存储器中解密视频分组。DRM代理把已解密的packet2返回到本地播放器，其向用户显示视频分组。对于所有数字内容执行重复最后四个步骤16-19。

为了实施本发明的方法，提供一种可下载到用户设备中的代理程序，其充当DRM应用以便播放受到集中DRM方案保护数字内容。所述代理程序与用户设备平台的本地媒体播放器集成在一起。这样做相对于使用第三方播放器是有利的，因为可以使用用户设备硬件加速来解码及提供视频，从而使得重放更加平滑并且允许更高质量的内容。

此外，通过利用本地播放器来播放受到DRM保护的内容，可以提供与用户设备的其他应用集成在一起的更加简单的用户接口。所述代理程序通过HTTP现场流送协议支持流送内容，并且支持例如Microsoft的平滑流送之类的其他流送协议以及下载到设备的内容。图8示意性地表示出用户设备应用与所述代理程序的集成以及与外部设备的通信。

所述代理程序与由顾客创建的应用集成在一起并且对用户隐藏，因为其在屏幕上没有UI元件。优选地，所述代理程序利用公共API来管理顾客应用和/或本地播放器。所述代理程序的API包括允许顾客应用或本地播放器获取对应于受保护内容的执照并且准备本地播放器对其进行播放的方法或指令集合。该API被提供作为用Objective C编写的静态链接库。包括在iOS SDK（软件开发工具包）中的媒体播放器框架允许所述应用定制本地播放器的一些特征，例如视频提供视图的尺寸和位置或者重放控制。只有当与所述代理程序相结合地使用时，其才可以被用来播放利用PlayReady DRM保护的内容。

根据本发明，此外还提供了用于播放受到DRM方案保护并且被存储在服务器提供商中的数字内容的用户设备。所述用户设备包括将服务器和用户设备的本地播放器对接的DRM应用，所述DRM应用被配置成：

-选择将要下载的数字内容并且获取相应的远程播放列表；

-把远程播放列表变换成本地播放列表，其中本地播放列表具有可从本地播放器读取的格式并且与将在本地播放器中播放的数字内容的多个本地分组相关联，并且对于每一个本地分组：

-向服务器请求相应的远程分组；

-获取用以解密远程分组的执照；

-解密远程分组并且把已解密分组返回到本地播放器以作为将被播放的本地分组。

DRM应用被配置成连接到DRM服务器以便获取执照，并且发送包括在数字内容中的URL以便获取执照。其还被配置成在激活本地播放器之前获取执照，并且只有在执照被获取的情况下才激活本地播放器。更具体来说，DRM应用被配置成获取可用于解密远程播放列表的所有远程分组的一份执照，所述执照优选地与远程播放列表的第一远程分组相关联。从DRM应用获取的远程播放列表可以包括对应于整个数字内容的仅仅一个远程分组，并且DRM应用被配置成把所述远程分组划分成多个本地分组以供在本地播放器中显示。

根据本发明的一方面，DRM应用被配置成获取平滑流送播放列表和清单文件，并且在远程播放列表中可用的各个比特率当中选择一个比特率。此外，本地播放器被配置成请求HTTP连接以用于接收数字内容，并且DRM应用被配置成保护本地播放器与服务器提供商之间的通信安全以及：

-利用与内容相关联的第一URL从本地播放器接收针对访问服务器提供商的内容的请求，其中第一URL不包括对于所述内容提供来自服务器提供商的直接流送的有效URL；

-基于来自本地播放器的请求，向服务器提供商发送用于接收与内容相关联的远程播放列表的请求；

-从服务器提供商接收远程播放列表，其中包括对于内容的至少一个比特率信息；

-基于远程播放列表生成本地播放列表，所述本地播放列表包括至少一个比特率信息、相应的URL和相应的端口号，其中相应的URL包括用户设备，并且相应的端口号是随机生成的；

-如果内容受到DRM保护，则向DRM服务器请求与内容相关联的执照；

-向本地播放器发送本地播放列表；

-通过基于由本地播放器选择的本地播放列表的比特率确定的端口，从本地播放器接收与内容相关联的HTTP请求；

-向服务器提供商请求具有所述所选比特率的内容流送；

-从服务器提供商接收与数字内容相关联的所述分组；

-如果所述多个分组受到DRM保护，则利用所述执照解密所述分组；以及

-向本地播放器发送对应于HTTP请求的HTTP响应，所述HTTP连接响应包括已解密内容。

DRM应用还被配置成：在接收到分组之后，对分组进行解析并且把已解析分组分别临时存储到音频流缓冲器和视频流缓冲器中；以及利用同步信息把已解析音频流和已解析视频流混合（mux）到一个分段中，其中HTTP连接响应包括将由多媒体播放器播放的所述分段。已解析视频流是H.264流，已解析音频流是AAC流，并且所述混合由MPEG2传输流混合器施行。

根据一个实施例，所述第一URL是平滑流送URL，远程播放列表是平滑流送清单，并且本地播放列表是HLS播放列表。通过HTTP协议利用一定数目的并行HTTP GET施行到内容服务器的多媒体内容流送。

有利的是，根据本发明，即使DRM方案需要不同的特定播放器，也使用用户设备的本地播放器来播放内容。有利的是，用户设备的本地播放器与操作系统之间的通信比这样的操作系统与特定的非本地播放器之间的通信更快。实际上，本地播放器可以使用由用户设备的操作系统提供的加速器来提供数字内容。有利的是，避免了在用户设备中下载第三方播放器。

下面将参照图9和10讨论本发明的另一方面。

现在将参照图9讨论用户设备100与多媒体服务器200之间的示例性通信流程。

用户设备100包括多媒体播放器110和代理服务器150。多媒体播放器110与代理服务器150通信以便从多媒体服务器200获取多媒体内容。

代理服务器150被安装在用户设备100中。代理服务器150可以被实施为单独的软件，或者可以是运行在用户设备110中的应用程序。如果代理服务器被实施为一项应用，其可以是独立应用，或者可以被提供为由另一个程序使用的模块。

代理服务器150可以通过蜂窝网络、无线LAN或有线通信协议与多媒体服务器200通信。被用于代理服务器150与多媒体服务器200之间的通信的具体协议不限制本发明的范围，并且作为一个实例被提供在这里。一般来说，由于用户设备100和多媒体服务器200的位置远离，因此在用户设备100与多媒体服务器200之间传送分组会花费时间。也就是说，当代理服务器向多媒体服务器200发送可以包括例如针对播放列表或实际多媒体数据的请求的数据分组250时，数据分组250到达多媒体服务器200的过程存在延迟。此外，当可以包括播放列表或实际多媒体数据的一个分段的数据分组240经过网络传递时，其也需要时间来到达代理服务器150。数据分组250和240经过网络传递所花的这些时间可以根据网络状态而不同，从而会影响分组250和240的数据速率。

与此同时，对于多媒体播放器110与代理服务器150之间的通信，也可能会有一些延迟。但是由于多媒体播放器110和代理服务器150都运行在用户设备100中，因此与分组250和240的延迟相比，对应于传送分组115和125的延迟非常低。也就是说，分组115和分组125的数据速率远高于分组250和分组240的数据速率。

在某些情况下，一旦从多媒体服务器200接收到数据分组240，代理服务器150可以向多媒体播放器发送数据125。也就是说，代理服务器150可以仅仅把所接收到的分组重定向到多媒体播放器110。

但是在另一个实例中，代理服务器150可以缓冲接收自多媒体服务器200的数据。随后如果缓冲了足够数量的数据，代理服务器150可以开始向多媒体播放器110发送其数据。代理服务器150可以周期性地检查缓冲器的状态，并且如果没有足够的数据以供发送到多媒体播放器110，其可以暂停发送并且等待缓冲器再次充满。

在任一个前述实例中，多媒体播放器110都不确切知晓代理服务器150和多媒体服务器200的工作方式，除非存在用以在多媒体播放器110与代理服务器150之间对此进行通知的协议。

举例来说，可以假设多媒体播放器110使用基于HTTP建立的多媒体流送协议，并且代理服务器150充当HTTP服务器。如果多媒体播放器110被编程为不对其所连接的服务器位于何处做出区别，则其将按照相同的方式运作而不管服务器是否位于本地设备中。

多媒体播放器110有时可以基于其接收到的数据使用试探算法来尝试估计可用带宽。在这种情况下，多媒体播放器110分析分组125，并且估计其数据速率。如果每当多媒体播放器110请求时代理服务器150向多媒体播放器110发送尽可能多的数据，则多媒体播放器110可能会错误地估计数据速率，例如将其估计成高于实际数据速率，这是因为在一个较短时段期间可能会有数据突发。多媒体播放器很可能会估计出比代理服务器150与多媒体服务器200之间的实际数据速率更高的数据速率。

可以指出的是，这里的目标是模拟例如从WAN接口到本地接口中的网络状况，从而使得代理服务器可以按照对于多媒体播放器110透明的方式工作，也就是说不会影响播放器用来估计可用带宽的试探法。

根据所述方法，在解决这一问题时，代理服务器150估计用户设备300与多媒体服务器200之间的数据速率，并且基于所估计的数据速率向多媒体播放器200发送对应于多媒体内容的数据流。可能存在多种方式来估计用户设备100与多媒体播放器200之间的数据速率。如果用户设备100的网络驱动器软件通过一个API提供一定平均数据速率，则代理服务器150可以调用（call）所述API以获取代理服务器150与多媒体服务器200之间的实际网络速度。

在另一个替换实施例中，代理服务器150可以根据对应于所接收到的多媒体内容的多个分组240测量对应于多项多媒体内容的数据速率。举例来说，如果代理服务器150可以对于在特定间隔期间接收到的数据的数量进行计数，则可以考虑所述数量和间隔以计算近似数据速率。甚至可以周期性地施行对于数据速率的测量。

一旦计算出近似数据速率，代理服务器150可以控制其在多媒体播放器110与代理服务器150之间的数据分组125的数据速率。举例来说，其可以不是尽可能快地答复来自多媒体播放器110的请求115，而是在等待一段持续时间之后答复，从而使得多媒体播放器110相信其正与远程服务器通信。例如可以基于代理服务器150与多媒体服务器200之间的近似数据速率来确定将要等待的持续时间。或者代理服务器150可以基于近似数据速率向多媒体播放器110流送数据125。

下面将讨论本发明的系统如何应对可下载DRM代理程序的安全性。秘密密钥和执照被存储在HDS（PlayReady数据库）中。其存储与DRM执照有关的所有永久性信息，其中包括执照密钥（秘密）。所述数据库利用从唯一设备私有密钥导出的密钥对存储在HDS中的所有密钥进行加密。所述唯一设备私有密钥（和证书）是在第一次初始化DRM融合代理程序的运行时间创建的也就是说是在安装之后第一次运行所述应用的运行时间创建的。为了创建所述设备密钥和证书，在以下规程中使用模型密钥（或应用密钥）：

-对于可下载应用，所述唯一模型密钥应当是应用镜像的一部分；

-所生成的设备密钥被存储为一个已加密文件（通过从模型密钥导出的密钥加密）。

总而言之，信任密钥的根是应用或模型私有密钥。其以加密格式被存储在应用镜像中。

必须提到的是，DRM融合代理程序通过使用SW混淆技术保护设备密钥。

模型密钥被用来在第一次初始化应用时创建设备唯一密钥。所述设备密钥或证书被用于在执照获取期间向PlayReady服务器进行认证。接收自服务器的所有执照都包含利用从设备唯一密钥导出的其他密钥所包裹的密钥。通过反调试、混淆来提供对于密钥的运行时间保护。

在这一点上，同样重要的是提供一种安全时钟实现方式，这是通过以下步骤获得的：

-系统时钟的回退检测；

-与安全网络时间服务器（其例如由Microsoft提供）同步系统时间，其在检测到用户修改系统时钟的情况下被调用。

通过混淆和反篡改技术来保护包括所有敏感的与DRM有关的功能和参数的DRM核心软件库。

在图10中给出了包括iOS本地播放器内的安全性措施的与iOS本地播放器的集成的示意图。关于媒体内容服务器200应当提到的是，其主要任务是如下：把受到PlayReady保护的媒体重新格式化成与本地播放器兼容的HLS本地流；但是决不把已解密数据存储在闪存上，并且不应用解码/再编码；只有当准备好显示媒体时才按需启动媒体内容服务器；内部地址对于外部各方或其他所安装的应用不可见；在每一个重放会话上使用随机侦听端口和媒体URL；在媒体内容服务器与本地播放器之间应用的HTTP认证；在启动本地媒体播放器时从DRM融合代理程序传递所生成的凭证；在媒体内容服务器与本地播放器之间应用的SSL加密；由媒体内容服务器利用SSL加密本地媒体流并且由本地媒体播放器进行解密。

默认地应用SW混淆、反调试和反篡改规程以保护DRM融合代理程序软件。

受益于在前面的描述和相关联的附图中给出的教导，本领域技术人员将会想到本发明的许多修改和其他实施例。因此应当理解的是，本发明不限于所公开的具体实施例，并且各种修改和实施例应当被包括在所附权利要求书的范围内。