法律状态公告日
法律状态信息
法律状态
2015-05-13
专利权的转移 IPC(主分类):H04L9/14 变更前: 变更后: 登记生效日:20150424 申请日:20050113
专利申请权、专利权的转移
2012-01-04
授权
授权
2005-11-02
实质审查的生效
实质审查的生效
2005-09-07
公开
公开
技术领域
本发明涉及权限管理(RM)系统，尤其涉及在这一RM系统中使用灵活的权限模板从许可证服务器获取一段数字内容的经签署的权限标签(SRL)所执行的步骤。
背景技术
权限管理和实施对于诸如数字音频、数字视频、数字文本、数字数据、数字多媒体等数字内容是高度需要的，这样的数字内容要被分发到一个或多个用户。数字内容可以是静态的，例如，诸如文本文档，或者它可以形成流，诸如实况事件的流音频/视频。分发的典型模式包括有形设备，如磁盘(软盘)、磁带、光盘(压缩盘)(CD)等，以及无形媒质，如电子公告板、电子网络、因特网等等。在被用户接收时，这类用户在诸如个人计算机上的媒体播放器等适当的呈现设备的帮助下呈现或“播放”该数字内容。
在一个情形中，诸如作者、出版人、广播公司等内容所有者或权限所有者希望将这些数字内容分发到每一用户或接收者，以交换许可证费用或某些其它报酬。则在这一情形中，内容可以是歌曲、歌曲专辑、电影等等，并且分发的目的是生成许可证费用。给定选择，这样的内容所有者可能希望限制用户对这类分发的数字内容可以采取的行动。例如，内容所有者可能希望限制用户复制并向该第二用户重新分发这一内容，至少是拒付来自第二用户的内容所有者的许可证费用时。
另外，内容所有者可能希望向用户提供以不同的许可证费用购买不同类型的使用许可证的灵活性，而同时使用户受到实际购买的许可证类型的期限的限制。例如，内容所有者可能希望允许分发的数字内容仅被播放有限次数、仅被播放某一总时间、仅在某一类型的机器上播放、仅在某一类型的媒体播放器上播放、仅由某一类型的用户播放等等。
在另一情形中，内容开发者，如组织中的雇员，希望将这类数字内容分发到组织中的一个或多个其它雇员，或分发到组织外部的个人，但是仍希望防止其他人呈现该内容。此处，内容的分发与以机密或受限方式的基于组织的内容共享更相似，而与基于广播的分发与交换许可证费用或某些其它报酬相反。则在这一情形中，内容可以是诸如可在办公室设置内交换的文档演示、电子表格、数据库、电子邮件等等，并且内容开发者可能希望确保内容保留在办公室设置内并且不被诸如竞争者或对手等非授权的个人呈现。再一次，这类内容开发者希望限制接受者可以在这一分发的数字内容上作出的行动。例如，内容所有者限制用户复制和向第二用户重新分发这些内容，至少是在必须被允许呈现内容的个人的范围之外展现内容时。
另外，内容开发者可能希望向各种接受者提供不同级别的呈现权限。例如，内容开发者可能希望允许受保护的数字内容对于一类个人可被察看，但不可打印，而对于另一类个人可察看并可打印。
然而，在任一情形中，在发生了分发之后，这类内容所有者/开发者在数字内容上具有极少(如果有的话)控制。鉴于实际上每一个人计算机都包括作出这一数字内容的原样的数字副本、将这一原样数字副本下载到可写磁盘或光盘、或将这类原样数字副本通过诸如因特网等网络发送到任何目的地所必须的软件和硬件，这就尤其是有问题的。
当然，作为分发内容的交易的一部分，内容所有者/开发者可能要求数字内容的用户/接受者允诺不以不受欢迎的方式重新分发这类数字内容。然而，这一允诺是很容易作出且很容易违背的。内容所有者/开发者可试图通过若干已知安全设备的任一种防止这一重新分发，这通常涉及加密和解密。然而，很少能防止适度确定的用户来解密经加密的数字内容、将这类数字内容以非加密的形式保存、然后重新分发同一内容。
因此，需要提供一种允许任意形式的数字内容的受控制的呈现或播放的权限管理和实施体系结构和方法，其中，这一控制是灵活的，并可由这一数字内容的内容所有者/开发者来定义。更具体地，需要一种允许并方便这类受控制呈现的体系结构，尤其是在文档要在定义的一组个人或一类个人之中共享的办公室或组织环境等中。尤其具体地，需要一种向这一环境中的数字内容的发行人提供指定对于这一数字内容的用户和这类用户的权限的预定义模板的体系结构，在这一体系结构中，该模板本质上是灵活的。
发明内容
本发明通过提供用于发行数字内容以使许可证服务器能够向期望呈现该内容的一个或多个用户签发对应于该内容的数字许可证的系统和方法，满足了本领域中的上述需求。
在一个方法中，内容依照内容密钥(CK)来加密，以生成(CK(内容))，并且内容密钥(CK)依照许可证服务器的公钥(PU-RM)来保护。从权限模板检索要与该内容相关联的权限数据，并且也从所检索的权限模板中检索用于修改所检索的权限数据的规则。从权限模板所检索的权限数据依照这些规则来修改，并且权限数据和受保护的内容密钥(CK)作为权限标签被提交到许可证服务器由其签署。许可证服务器由此可确认权限标签，如果标签有效，则基于对应于(PU-RM)的私钥(PR-RM)，并至少部分地基于权限数据来创建数字签名，以获得经签署的权限标签(SRL)，并返回该SRL。
返回的SRL被接收，并与(CK(内容))串接以形成内容包，并且内容包被分发到一个或多个用户。由此，期望呈现内容的用户从内容包中检索SRL，并向许可证服务器提交所检索的SRL，作为对对应于内容的许可证的请求的一部分。许可证服务器基于(PU-RM)，并至少部分地基于受保护的权限数据确认SRL的签名、访问SRL中的权限数据、并审阅该数据来确定是否向该用户授予许可证，如果是，则向该用户签发许可证，其中，该许可证包括用户可访问的受保护形式的(CK)。
在另一方法中，启用多个许可证服务器来签发对应于内容的数字许可证。具体地，从权限模板的权限数据中检索被启用来签发许可证的每一许可证服务器的公钥(PUx-RM)，并且依照每一所启用的许可证服务器的公钥(PUx-RM)来保护内容密钥(CK)，以得到每一启用的许可证服务器的(PUx-RM(CK))。由此，每一启用的许可证服务器的权限数据和(PUx RM(CK))作为权限标签被提交到许可证服务器由其签署。期望呈现该内容的用户检索所得的SRL，并向启用的许可证服务器之一提交所检索的SRL，作为对应于该内容的许可证的请求的一部分。启用的许可证服务器然后确认该SRL、访问SRL中的权限数据、并审阅该数据来确定是否向该用户授予许可证，如果是，则从对应于这一许可证服务器的权限数据中检索(PUx-RM(CK))、从其检索(CK)、并向用户签发许可证，其中，该许可证包括用户可访问的受保护形式的(CK)。
在又一方法中，从权限数据中检索多个发行服务器的标识，并且选择多个发行服务器中的一个。由此，权限数据和受保护的内容密钥(CK)作为权限标签被提交到所选择的发行服务器由其签署。
在再一方法中，通过在权限模板内定义要与该内容相关联的权限数据以及用于修改这些权限数据的规则、并基于规则标识未修改的权限数据的部分，来产生权限模板。所标识的部分的至少某些被标记，并且基于所标记的部分来签署该权限模板，以产生一数字签名。由此，发行内容的发行人可依照规则来修改该模板的权限数据，但是不允许修改该模板的所标记的部分，因此，不应当阻止数字签名被核实。
附图说明
当结合附图阅读以下本发明的实施例的详细描述时，可以更清楚本发明的其它特征。
图1是表示可在其中实现本发明的示例性非限制计算环境的框图。
图2是表示具有可在其中实现本发明的各种计算装置的示例性网络环境的框图。
图3是依照本发明用于发行数字内容的系统和方法的一个较佳实施例的功能框图。
图4提供了依照本发明用于发行权限已管理的数字内容的方法的一个较佳实施例的流程图。
图4A所示是由图4的方法产生的经签署的权限标签的结构的框图。
图5是依照本发明用于许可被管理数字内容的权限的系统和方法的一个较佳实施例的功能框图。
图6A和6B提供了依照本发明用于许可被管理数字内容的权限的方法的一个较佳实施例的流程图。
图7所示是基于信任的系统的一个示例的实施体系结构的框图。
图8所示是依照本发明的一个实施例由RM服务器向用户签发以允许用户离线发行证书的框图。
图9所示是依照本发明的一个实施例指定要被结合到权限标签中的信息的权限模板的框图。
图10所示是依照本发明的一个实施例创建图9的权限模板，并基于权限模板创建图4A的经签署的权限标签所执行的步骤的流程图。
图11所示是依照本发明的一个实施例创建并采用灵活的权限模板所执行的步骤的流程图。
具体实施方式
示例性计算装置
图1和以下讨论旨在提供可在其中实现本发明的合适的计算环境的简要总体描述。然而应当理解，可以考虑手持式、便携式和其它所有种类的计算装置可用于本发明。尽管下文描述了通用计算机，这仅是一个示例，本发明仅需要具有网络服务器互操作和交互的薄客户机。由此，本发明可以在包含了极少或最小的客户机资源的网络化、主机化(hosted)服务的环境中实现，如，其中客户机装置仅担当万维网的浏览器或接口的网络化环境。
尽管并非所需，本发明可通过应用编程接口(API)来实现，API由开发者使用，和/或包括在网络浏览软件中，软件将在诸如由客户机工作站、服务器或其它装置等一个或多个计算机执行的程序模块的计算机可执行指令的一般上下文中描述。一般而言，程序模块包括例程、程序、对象、组件、数据结构等等，执行特定的任务或实现特定的抽象数据类型。通常，程序模块的功能可以如所需地组合或分布在各种实施例中。此外，本领域的技术人员可以理解，本发明可以用其它计算机系统配置来实践。适用于本发明的其它公知的计算系统、环境和/或配置包括，但不限于，个人计算机(PC)、自动提款机、服务器计算机、手持式或膝上设备、多处理器系统、基于微处理器的系统、可编程消费者电子产品、网络PC、小型机、大型机等等。本发明也可以在分布式计算环境中实践，其中，任务由通过通信网络或其它数据传输媒质连接的远程处理设备来执行。在分布式计算环境中，程序模块可以位于本地和远程计算机存储媒质中，包括存储器存储设备。
由此，图1示出了可在其中实现本发明的合适的计算系统环境100的一个示例，尽管已在上文中清楚地说明，计算系统100仅是合适的计算环境的一个示例，并非暗示对本发明的使用范围或功能的局限。也不应将计算环境100解释为对示例性操作环境100中示出的任一组件或其组合具有依赖或需求。
参考图1，用于实现本发明的示例系统包括计算机110形式的通用计算装置。计算机110的组件可包括但不限于，处理单元120、系统存储器130以及将包括系统存储器的各类系统组件耦合至处理单元120的系统总线121。系统总线121可以是若干种总线结构类型的任一种，包括存储器总线或存储器控制器、外围总线以及使用各类总线体系结构的局部总线。作为示例而非局限，这类体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强ISA(EISA)总线、视频电子技术标准协会(VESA)局部总线以及外围部件互连(PCI)总线(也称为Mezzanine总线)。
计算机110通常包括各种计算机可读媒质。计算机可读媒质可以是可由计算机110访问的任一可用媒质，包括易失和非易失媒质、可移动和不可移动媒质。作为示例而非局限，计算机可读媒质包括计算机存储媒质和通信媒质。计算机存储媒质包括以用于储存诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任一方法或技术实现的易失和非易失，可移动和不可移动媒质。计算机存储媒质包括但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CDROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储设备、或可以用来储存所期望的信息并可由计算机110访问的任一其它媒质。通信媒质通常在诸如载波或其它传输机制的已调制数据信号中包含计算机可读指令、数据结构、程序模块或其它数据，并包括任一信息传送媒质。术语“已调制数据信号”指以对信号中的信息进行编码的方式设置或改变其一个或多个特征的信号。作为示例而非局限，通信媒质包括有线媒质，如有线网络或直接连线连接，以及无线媒质，如声学、RF、红外和其它无线媒质。上述任一的组合也应当包括在计算机可读媒质的范围之内。
系统存储器130包括以易失和/或非易失存储器形式的计算机存储媒质，如只读存储器(ROM)131和随机存取存储器(RAM)132。基本输入/输出系统133(BIOS)包括如在启动时帮助在计算机110内的元件之间传输信息的基本例程，通常储存在ROM 131中。RAM 132通常包含处理单元120立即可访问或者当前正在操作的数据和/或程序模块。作为示例而非局限，图1示出了操作系统134、应用程序135、其它程序模块136和程序数据137。
计算机110也可包括其它可移动/不可移动、易失/非易失计算机存储媒质。仅作示例，图1示出了对不可移动、非易失磁媒质进行读写的硬盘驱动器141、对可移动、非易失磁盘152进行读写的磁盘驱动器151以及对可移动、非易失光盘156，如CD ROM或其它光媒质进行读写的光盘驱动器155。可以在示例性操作环境中使用的其它可移动/不可移动、易失/非易失计算机存储媒质包括但不限于，磁带盒、闪存卡、数字多功能盘、数字视频带、固态RAM、固态ROM等等。硬盘驱动器141通常通过不可移动存储器接口，如接口140连接到系统总线121，磁盘驱动器151和光盘驱动器155通常通过可移动存储器接口，如接口150连接到系统总线121。
图1讨论并示出的驱动器及其关联的计算机存储媒质为计算机110提供了计算机可读指令、数据结构、程序模块和其它数据的存储。例如，在图1中，示出硬盘驱动器141储存操作系统144、应用程序145、其它程序模块146和程序数据147。注意，这些组件可以与操作系统134、应用程序135、其它程序模块136和程序数据137相同，也可以与它们不同。这里对操作系统144、应用程序145、其它程序模块146和程序数据147给予不同的标号来说明至少它们是不同的副本。用户可以通过输入设备，如键盘162和定位设备161(通常指鼠标、跟踪球或触摸板)向计算机110输入命令和信息。其它输入设备(未示出)可包括麦克风、操纵杆、游戏垫、圆盘式卫星天线、扫描仪等等。这些和其它输入设备通常通过耦合至系统总线的用户输入接口160连接至处理单元120，但是也可以通过其它接口和总线结构连接，如并行端口、游戏端口或通用串行总线(USB)。
监视器191或其它类型的显示设备也通过接口，如视频接口190连接至系统总线121。图形接口182，如Northbridge，也可连接到系统总线121。Northbridge是与CPU或主机处理单元120进行通信的芯片组，并承担加速图形端口(AGP)通信的责任。一个或多个图形处理单元(GPU)184可与图形接口182通信。在这一点上，GPU 184一般包括片上存储器存储，如寄存器存储，并且GPU 184与视频存储器186通信。然而，GPU 184只是协处理器的一个示例，并且由此，各种协处理设备可包括在计算机110中。监视器191或其它类型的显示设备也可以通过接口，如接口190连接到系统总线121，接口190进而与视频存储器186通信。除监视器191之外，计算机也包括其它外围输出设备，如扬声器197和打印机196，通过输出外围接口195连接。
计算机110可以在使用到一个或多个远程计算机，如远程计算机180的逻辑连接的网络化环境中操作。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其它公用网络节点，并通常包括许多或所有上述与计算机110相关的元件，尽管在图1中仅示出了存储器存储设备181。图1描述的逻辑连接包括局域网(LAN)171和广域网(WAN)173，但也可包括其它网络。这类网络环境常见于办公室、组织范围计算机网络、内联网以及因特网。
当在LAN网络环境中使用时，计算机110通过网络接口或适配器170连接至LAN 171。当在WAN网络环境中使用时，计算机110可包括调制解调器172或其它装置，用于通过WAN 173，如因特网建立通信。调制解调器172可以是内置或外置的，通过用户输入接口160或其它合适的机制连接至系统总线121。在网络化环境中，描述的与计算机110相关的程序模块或其部分可储存在远程存储器存储设备中。作为示例而非局限，图1示出了远程应用程序185驻留在存储器设备181中。可以理解，示出的网络连接是示例性的，也可以使用在计算机之间建立通信链路的其它装置。
本领域的普通技术人员可以理解，计算机110或其它客户机装置可作为计算机网络的一部分来部署。在这一点上，本发明涉及具有任意数量的存储器或存储单元，以及在任意数量的存储单元或卷宗上发生的任意数量的应用程序和进程的任一计算机系统。本发明可应用到具有远程或本地存储的、服务器计算机和客户机计算机在网络环境中部署的环境。本发明也可应用到具有编程语言功能、解释和执行能力的独立的计算装置。
分布式计算通过计算装置和系统之间的直接交换方便了计算机资源和服务的共享。这些资源和服务包括信息交换、高速缓存、和文件的盘存储。分布式计算利用了网络连接的优点，允许客户机调节其总能力来有益于整个组织。在这一点上，各种装置可具有可交互来包含本发明用于可信图形流水线的验证技术的应用程序、对象或资源。
图2提供了一个示例性网络化或分布式计算环境的的示意图。分布式计算环境包括计算对象10a、10b等，以及计算对象或装置110a、110b、110c等。这些对象可包括程序、方法、数据存储、可编程逻辑等等。对象可包括诸如PDA、电视机、MP3播放器、电视、个人计算机等相同或不同设备的部分。每一对象可通过通信网络14彼此通信。该网络本身可包括其它计算对象和计算装置，它们向图2的系统提供了服务。依照本发明的一个方面，每一对象10或110可包含可请求本发明用于可信图形流水线的验证技术的应用程序。
也可以理解，诸如110c等对象可主存(host)在另一计算装置10或110上。由此，尽管所描述的物理环境示出连接的装置为计算机，然而这一图示仅是示例性的，物理环境可替换地被描绘或描述为包括诸如PDA、电视机、MP3播放器等各种数字设备，诸如接口、COM对象等软件对象。
有各种支持分布式计算环境的系统、组件和网络配置。例如，计算系统可由有线或无线系统、局域网或广域网连接在一起。当前，许多网络都被耦合到因特网，它提供了广泛分布的计算的基础结构，并包含许多不同的网络。
在家庭网络环境中，有至少四种离散的网络传输媒质，它们的每一个都支持一个唯一的协议，如电力线、数据(有线和无线)、语音(如电话)和娱乐媒体。诸如电灯开关和电器等大多数家庭控制设备可使用电力线来连接。数据服务可作为宽带(如，DSL或线缆调制解调器)进入家庭，并可使用有线(如，HomeRF或802.11b)或无线(如，HomePNA、Cat5、甚至是电力线)连接来访问。语音话务可作为有线(如，Cat3)或无线(如，蜂窝电话)进入家庭，并可在家庭中使用Cat3配线来分布。娱乐媒体可通过圆盘式卫星天线或线缆进入家庭，并通常在家庭中使用同轴电缆来分布。IEEE 1394和DVI可作为用于媒体设备群集的数字互联出现。所有这些网络环境和作为协议标准出现的其它环境可被互联，以形成可通过因特网连接到外部世界的内联网。简言之，存在各种全异的来源用于数据的存储和传输，因此，向前进，计算设备将需要保护数据处理流水线的所有部分上的内容的方法。
因特网通常指使用TCP/IP协议组的网络和网关的集合，该协议在计算机网络领域中是公知的。TCP/IP是“传输控制协议/互联网程序”的首字母缩写。因特网可被描述为由执行允许用户在网络上交互并共享信息的网络协议的计算机互联的地理上分布的远程计算机的系统。由于这一广泛分布的信息共享，诸如因特网等远程网络由此更一般地演变成一种开放系统，开发者可为该系统设计软件应用程序，用于执行专门的操作或服务，它本质上是没有限制的。
由此，网络基础结构启用了诸如客户机/服务器、对等、或混合体系结构等网络拓朴的主机。“客户机”是使用不相关的另一组或另一类的服务的类或组的成员。由此，在计算中，客户机是进程，即，粗略地是一组指令或任务，它请求由另一程序提供的服务。客户机进程使用请求的服务，而无需“知道”关于其它程序或服务本身的任何工作细节。在客户机/服务器体系结构中，尤其是在网络化系统中，客户机通常是访问由另一计算机，如服务器提供的共享网络资源的计算机。在图2的示例中，计算机110a、110b等可以被认为是客户机，而计算机10a、10b等可以被认为是服务器，其中，服务器10a、10b等维护随后在客户机计算机110a、110b等中复制的数据。
服务器通常是可通过诸如因特网等远程网络访问的远程计算机系统。客户机进程可以在第一计算机系统中活动，而服务器进程可以在第二计算机系统中活动，它们通过通信媒质彼此通信，由此提供了分布式功能，并允许多个客户机利用服务器的信息收集能力的优势。
客户机和服务器使用由协议层提供的功能彼此通信。例如，超文本传输协议(HTTP)是一种可用于万维网(WWW)的常见协议。通常，计算机网络地址，如统一资源定位器(URL)或互联网协议(IP)地址用于服务器或客户机的彼此标识。网络地址可以被称为统一资源定位器地址。例如，通信可在通信媒质上提供。具体地，客户机和服务器可通过用于高容量通信的TCP/IP连接被彼此耦合。
由此，图2示出了可采用本发明的示例性网络化或分布式环境，其中，服务器通过网络/总线与客户机计算机通信。更详细地，依照本发明，若干服务器10a、10b等通过通信网络/总线14与若干客户机或远程计算装置110a、110b、110c、110d、110e等互联，通信网络/总线14可以是LAN、WAN、内联网、因特网等，客户机或远程计算装置可以是便携式计算机、手持式计算机、薄客户机、网络化电器，或其它设备，如VCR、TV、烤箱、灯、加热器等等。由此，考虑本发明可应用到它希望结合其来处理、储存或呈现来自可信来源的安全内容的任何计算装置。
例如，在通信网络/总线14是因特网的网络环境中，服务器10可以是Web服务器，客户机110a、110b、110c、110d、110e等通过诸如HTTP等众多已知协议的任一种与之进行通信。服务器10也可担当客户机110，这是分布式计算环境的特征。在适当时，通信可以是有线或无线的。客户机装置110可以通过通信网络/总线14通信或不通信，并可具有与其相关联的独立的通信。例如，在TV或VCR的情况下，可以有或没有网络化方面来控制它。每一客户机计算机110和服务器计算机10可配备各种应用程序模块或对象135，并可连接或访问各种类型的存储元件或对象，在这些存储元件或对象上可储存文件或向其下载或移植文件的部分。由此，本发明可在具有可访问计算机网络/总线14并与其交互的客户机计算机110a、110b等，以及可与客户机计算机110a、110b等和其它装置111以及数据库20交互的服务器10a、10b等计算机网络环境中使用。
权限管理(RM)综述
如已知的，并现在参考图7，权限管理(RM)和实施对于诸如数字音频、数字视频、数字文本、数字数据、数字多媒体等数字内容12而言是高度期望的，其中，这类数字内容12将要分发到用户。在由用户接收之后，该用户在诸如个人计算机14上的媒体播放器等适当的呈现设备的帮助下呈现或“播放”该数字内容。
通常，分发这些数字内容12的内容所有者或开发者(以下称为“所有者”)希望限制用户可以对所分发的数字内容12作出的行动。例如，内容所有者可能希望限制用户复制并向第二用户重新分发内容12，或可能希望允许分发的数字内容12仅被播放有限的次数、仅被播放某一总时间、仅在某一类型的机器上播放、仅在某一类型的媒体播放器上播放、仅由某一类型的用户播放等等。
然而，在发生分发之后，该内容所有者对数字内容12具有极少(如果有的话)的控制。因此，RM系统10允许任意形式的数字内容12的受控制的呈现或播放，这一控制是灵活的，并可由该数字内容的内容所有者来定义。通常，内容12以包13的形式通过适当的分发通道被分发到用户。所分发的该数字内容包13可包括用对称加密/解密密钥(KD)来加密(即，(KD(CONTENT)))的数字内容12，以及标识内容、如何获取该内容的许可证等的其它信息。
基于信任的RM系统10允许数字内容12的所有者在该数字内容12被允许在用户的计算设备14上呈现之前指定必须满足的许可证规则。这些许可证规则可包括上述的时间要求，并可包含在数字许可证16内，用户/用户的计算设备14(在下文中，这些术语是可互交换的，除非环境另外要求)必须从内容的所有者或其代理人获取该许可证。这类许可证16也包括用于解密该数字内容的解密密钥(KD)，该数字内容可能是依照可用用户的计算设备可解密的密钥来加密的。
一段数字内容12的内容所有者必须信任用户的计算设备14将遵守由该内容所有者在许可证16中指定的规则和要求，即，该数字内容12不会被呈现，除非满足了许可证16中的规则和要求。然后，较佳地，向用户的计算设备14提供可信组件或机制18，它不会呈现该数字内容12，除非依照包含在与数字内容12相关联的许可证16内并由用户获取的许可证规则。
可信组件18通常具有许可证评估器20，它确定该许可证16是否有效、审阅这一许可证16中的许可证规则和要求、并基于所审阅的许可证规则和要求来确定请求的用户是否具有以所寻求的方式呈现请求的数字内容12的权限，等等。应当理解，许可证评估器20在RM系统10中是可信的，以依照许可证16中的规则和要求来实现数字内容12的所有者的愿望，并且用户应当无法为任何目的，无论是邪恶的还是其它的，来容易地改变这一可信元件。
应当理解，许可证16中的规则和要求可基于若干因素的任一个来指定用户是否具有呈现该数字内容12的权限，这些因素包括用户是谁、用户在哪里、用户使用的计算设备类型是什么、调用RM系统的呈现应用程序是什么、日期、时间等等。另外，许可证16的规则和要求可将许可证16限制到例如预定数量的播放，或预定的播放时间。
规则和要求可在许可证16中依照适当的语言和句法来指定。例如，语言可以简单地指定必须满足的属性和值(例如，DATE(日期)必须晚于X)，或可要求依照指定的脚本的功能的执行(例如，IF DATE大于X，THEN DO...)。
在许可证评估器20确定了许可证16有效，并且用户满足其中的规则和要求之后，可呈现该数字内容12。具体地，为呈现内容12，从许可证12获取解密密钥(KD)，并将其应用到内容包13的(KD(CONTENT))，以得到实际的内容12，然后实际地呈现真实的内容12。
发行数字内容
图3是依照本发明用于发行数字内容的系统和方法的一个较佳实施例的功能框图。此处所使用的术语“发行”指应用程序或服务随后对可信实体建立一组权限和条件的过程，该实体可对该内容，以及向可签发这些权限和条件的那些人签发这些权限和条件。依照本发明，发行过程包括加密数字内容并关联可持久实施的权限的列表，内容的作者想要提供它给该内容的所有可能的用户。该过程可以安全的方式来实现，以禁止对任何权限或对内容的访问，除非是内容的作者预期的。
在本发明的一个较佳实施例中，具体可采用三个实体来发行安全数字内容：内容准备应用程序302，它在客户机300上执行并准备用于发行的内容；权限管理(RM)应用程序接口(API)306，它也驻留在客户机设备300上；以及RM服务器320，它通过通信网络330通信上耦合至客户机300。在本发明的一个较佳实施例中，通信网络330包括因特网，尽管应当理解，通信网络330可以是任何局域网或广域网，例如，产权内联网(proprietary intranet)。
内容准备应用程序302可以是产生数字内容的任一应用程序。例如，应用程序302可以是文字处理程序或产生数字文本文件、数字音乐、视频或其它这类内容的其它发行程序。内容也可包括流内容，如实况或录制事件的流音频/视频。依照本发明，内容准备应用程序要求其用户使用用户提供的密钥来加密该内容。应用程序402使用该密钥来加密该数字内容，由此形成了一经加密的数字内容文件304。内容应用程序也要求用户为数字内容文件304提供权限数据。权限数据包括在数字内容中具有权限的每一实体的各自的身份。这一实体可以是，例如，个人、一类个人或设备。对于每一这样的实体，权限数据也包括该实体在内容中所具有的权限的列表，以及可施加在那些权限的任一个或所有上的任何条件。这类权限可包括对数字内容进行读、编辑、复制、打印等的权限。另外，权限可以是包含性的或排除性的。包含性权限指示指定的用户在内容中具有指定的权限(如，用户可编辑数字内容)。排除性权限指示指定的用户在内容中具有除指定的那些之外的权限(如，用户可对数字内容作出除复制之外的任何行动)。
依照本发明的一个实施例，客户机API306可将经加密的数字内容和权限数据传递到RM服务器320。使用以下详细描述的过程，RM服务器320确定它是否可实施用户已指派的权限，如果是，则RM服务器320签署该权限数据，以形成经签署的权限标签(SRL)308。然而，一般而言，任何可信实体可较佳地使用RM服务器320所信任的密钥来签署权限数据。例如，客户机可使用由RM服务器320提供给它的密钥来签署权限数据。
权限标签308可包括表示权限描述、经加密的内容密钥、以及权限描述和经加密的密钥上的数字签名的数据。如果RM服务器签署了权限标签，它通过客户机API 306将经签署的权限标签308传递回客户机，它将经签署的权限标签308储存在客户机设备300上。内容准备应用程序302然后将经签署的权限标签308与经加密的数字内容文件304相关联。例如，SRL 308可以与经加密的数字内容文件串接，以形成一权限已管理的内容文件310。然而，一般而言，权限数据不需要与数字内容相组合。例如，权限数据可被储存在一已知的位置中，并且可将对该储存的权限数据的引用与经加密的数字内容相组合。该引用可包括指示该权限数据储存在何处(例如，包含该权限数据的数据存储)的标识符，以及对应于特定存储位置上的特定权限数据的标识符(例如，标识包含所关注的特定权限数据的文件)。权限已管理的内容310然后可被传送到任何人，任何地方，并且仅具有消费该内容的权限的那些实体可消费该内容，并且仅依照所分配的权限。
图4是依照本发明用于发行权限已管理的数字内容的示例性方法400的流程图，其中，权限标签由RM服务器签署。然而，应当理解，该实施例仅为示例性的，权限标签一般可由任一可信的实体来签署。一般而言，依照本发明用于发行数字内容的方法可包括：使用内容密钥(CK)加密数字内容、生成与数字内容相关联的权限描述、依照RM服务器的公钥(PU-RM)加密内容密钥(CK)来得到(PU-RM(CK))、以及基于对应于权限描述和(PU-RM(CK))的组合上的(PU-RM)的私钥(PR-RM)来创建数字签名。
在步骤402，应用程序302生成用于加密数字内容的内容密钥(CK)。较佳地，内容密钥(CK)是对称密钥，尽管一般而言，可使用任一密钥来加密数字内容。对称密钥算法，有时候也被称为“机密密钥”算法，使用它们在加密消息时的同一密钥来解密消息。为此，较佳的是(CK)可被保密。在发送者和接收者之间共享(CK)应当非常仔细地完成，以避免这一(CK)的非授权截取。由于(CK)在加密者和解密者之间共享，(CK)较佳地在发送任何经加密的消息之前被传递。
若干对称密钥生成算法在本领域中是已知的。在一个较佳的实施例中，使用数据加密标准(DES)，尽管应当理解，可使用任一对称算法。这类对称密钥算法的示例包括但不限于，三重DES、国际数据加密算法(IDEA)、Cast、Cast-128、RC4、RC5和SkipJack。
在步骤404，应用程序302用对称内容密钥(CK)加密数字内容，以形成经加密的数字内容304，它可使用符号(CK(内容))来写出。使用应用程序302的作者也可生成与数字内容相关联的权限数据。该权限数据可包括可被授权来消费该内容的实体的列表，和每一实体拥有的对于该内容的特定权限，以及可施加在这些权限上的任何条件。例如，这类权限可包括察看内容、打印内容等等。应用程序302向API306提供权限数据。XML/XrML格式的权限数据的示例作为附录1附加在后。
在步骤406，API 306生成第二加密密钥(DES1)，它用于加密内容密钥(CK)。较佳地，(DES1)也是对称密钥。在步骤408，API 306用(DES1)加密(CK)，以得到(DES1(CK))。在步骤410，API 306丢弃(CK)，其结果是(CK)现在只能通过解密(DES1(CK))来获得。为确保(CK(内容))被保护到中央RM服务器320，并且该内容的所有“许可证请求”是依照该权限数据在中央完成的，在步骤412，API 306联系提供的RM服务器320，并检索其公钥(PU-RM)。在步骤414，API 306用(PU-RM)加密(DES1)，以得到(PU-RM(DES1))。由此，(CK)可被保护到(PU-RM)以确保RM服务器320是能够获得对(CK)的访问权限的唯一实体，这是解密(CK(内容))所要求的。在步骤416，API 306用(DES1)加密权限数据(即，授权实体的列表以及与列表中每一实体相关联的各自的权限和条件)，以得到(DES1(权限数据))。
在一个简化且可能较佳的实施例中，(CK)可用于直接加密权限数据，以得到(CK(权限数据))，并且由此放弃完全使用(DES1)。当然，在这一情况下，(PU-RM(DES1))将替代为(PU-RM(CK))。然而，使用(DES1)来加密权限数据使这一(DES1)可符合服从于RM服务器的任一特定算法，而(CK)可由实体独立于RM服务器来指定，并且可不服从于RM服务器。
在步骤418，内容保护应用程序302可向RM服务器320提交(PU-RM(DES1))和(DES1(权限数据))或(CK(权限数据))，作为用于签署的权限标签。可选地，客户机本身可签署权限数据。如果权限数据被提交到服务器用于签署，则在步骤420，RM服务器320访问权限数据，并核实它可在提交的权限标签中实施的权限和条件。为核实它能够实施该权限数据，RM服务器320对(PU-RM(DES1))应用(PR-RM)，以得到(DES1)，然后对(DES1(权限数据))应用(DES1)，以得到用一般文字的权限数据。服务器320然后可作出任何策略核查来核实权限数据中指定的用户、权限和条件在由服务器320实施的策略之内。服务器320签署包括(PU-RM(DES1))和(DES1(权限数据))的原始提交的权限标签，以得到经签署的权限标签(SRL)308，其中，签名基于RM服务器320的私钥(PR-RM)，并向API 306返回SRL 308，API306然后向客户机应用程序320呈现返回的SRL 308。
SRL 308是经数字地签署的文档，令其是防篡改的。另外，SRL 308加密内容不依赖于所使用的实际密钥类型和算法，但是保持与它所保护的内容的坚固的1对1关系。现在参考图4A，在本发明的一个实施例中，SRL 308可包括内容上的信息，它是SRL 308的基础，可能包括内容ID；签署SRL 308的RM服务器上的信息，包括(PU-RM(DES1))，以及诸如URL等参考信息，用于在网络上查找RM服务器，以及当URL失败时的后退信息；描述SRL 308本身的信息；(DES1(权限数据))；(DES1(CK))；以及S(PR-RM)，等等。XML/XrML的示例SRL 308作为附录2附加在后。
通过确保可信实体签署权限数据来创建经签署的权限标签308，RM服务器声明它将依照如权限标签308的权限数据中所描述的发行者提出的期限来签发内容的许可证。应当理解，要求用户获取许可证来呈现内容，尤其是因为许可证内包含内容密钥(CK)。当用户希望获得加密内容的许可证时，用户可向RM服务器320或其它许可证签发实体提出许可证请求，包括内容的SRL 308以及核实用户的凭证的证书。许可证签发实体然后可解密(PU-RM(DES1))和(DES1(权限数据))来产生权限数据、列出作者(如果有的话)向许可证请求实体授予的所有权限、并仅用那些特定的权限来构造许可证。
较佳地，在应用程序302接收SRL 308之后，这一应用程序302将经签署的权限标签308与对应的(CK(内容))304串接，以形成权限已管理的数字内容。可选地，权限数据储存在一已知位置上，具有到由加密的数字内容提供的位置的引用。由此，RM启用的呈现应用程序可通过呈现应用程序试图呈现的该段内容来发现经签署的权限标签308。该发现触发应用程序向RM许可证服务器320启动许可请求。例如，发行应用程序302可将URL储存到RM许可服务器320，或者RM许可服务器320可在数字地签署之前将其自己的URL作为一个元数据嵌入到权限标签中，使得由呈现应用程序调用的RM客户机API 306可识别正确的RM许可服务器320。较佳地，例如，在签署权限标签之前将诸如全局唯一标识符(GUID)等唯一的标识符放入权限标签中。
在本发明的一个较佳实施例中，简单对象访问协议(SOAP)可用于内容保护应用程序302或呈现应用程序与RM服务器320之间的通信。另外，可提供API库，如API 306，使得诸如应用程序302等应用程序不需要实现客户端的RM协议，而相反只要作出本地的API调用。较佳地，使用XrML—一种XML语言—来描述数字内容的权限描述、许可证以及权限标签，尽管应当理解，任一合适的格式也可用于权限描述和其它数据。
获取发行内容的许可证
图5是依照本发明用于许可被管理数字内容的权限的系统和方法的一个较佳实施例的功能框图。此处所使用的术语“许可”指应用程序或服务请求并接收令许可证中指定的实体能够依照许可证中指定的期限来消费内容的许可证的过程。许可过程的输入可包括与对其请求许可证的内容相关联的经签署的权限标签(SRL)308，以及为其请求许可证的实体的公钥证书。注意，请求许可证的实体不必要是为其请求许可证的实体。通常，许可证包括来自SRL 308的权限描述、可解密经加密的内容的加密密钥、以及权限描述和加密密钥上的数字签名。数字签名断言实体和指定的权限是合法的。
应用程序302消费被管理的内容的权限310的一种方法是令客户机API 306将被管理的内容的权限310的经签署的权限标签308通过通信网络330转发到RM服务器320。RM服务器320的位置，例如，可在SRL 308的参考信息中找到。在这一实施例中，通过以下详细描述的过程，RM许可服务器320可使用权限标签中的权限描述来确定它是否能够签发许可证，如果是，则导出权限描述以包括在许可证内。如上所述，权限标签308可包含依照RM服务器320的公钥(PU-RM)加密的内容密钥(CK)(即，(PU-RM(CK)))。在签发许可证的过程中，它然后使用许可证请求中传递的公钥证书中的公钥(PU-ENTITY)来重新加密(CK)(即，(PU-ENTITY(CK)))。新加密的(PU-ENTITY(CK))是服务器320放入许可证中的内容。由此，许可证可被返回到调用者，而没有暴露(CK)的风险，因为仅相关联的私钥(PR-ENTITY)的持有者可从(PU-ENTITY(CK))中恢复(CK)。客户机API 306然后使用(CK)来解密经加密的内容，以形成经解密的数字内容312。客户机应用程序302然后可依照许可证中提供的权限来使用经解密的数字内容312。
可选地，例如，客户机，如发行客户机，可签发其自己的许可证来消费内容。在这一实施例中，可在客户机计算机上运行一安全过程，它向客户机提供了在适当的环境下解密数字内容所需的密钥。
图6A和6B提供了依照本发明用于许可被管理数字内容的权限的方法600的一个较佳实施例的流程图。依照本发明，请求实体可代表一个或多个潜在的被许可者提交一许可证请求。请求实体可以是或不是潜在被许可者之一。潜在被许可者可以是人、组、设备、或可以任何方式消费该内容的任何其它这样的实体。现在参考RM服务器处理许可证请求的实施例来描述方法600，尽管应当理解，许可证请求处理也可在客户机上执行，并且许可证也可以由客户机直接签发。
在步骤602，例如，许可证签发实体，如RM服务器接收一许可证请求。较佳地，许可证请求包括一个或多个请求的被许可者的每一个的公钥证书或身份。
在步骤604，验证请求实体(即，作出许可证请求的实体)。依照本发明的一个实施例，许可证签发实体可被配置成使用协议(如，询问—响应)验证来确定请求实体的身份，或者它可被配置成不需要请求实体的验证(也称为“允许匿名验证”)。当需要验证时，可使用任一类型的验证模式(如，上文提及的询问—响应模式、用户id和密码模式，如MICROSOFT.NET、PASSPORT、WINDOWS验证、x509等等)。较佳地，允许匿名验证，以及支持由综合信息系统所支持的任何协议验证模式。验证步骤的结果是身份，例如，如“匿名”身份(对于匿名验证)，或个人账号身份。如果因任何原因不能验证许可证请求，则返回错误并且不授予许可证。
在步骤606，经验证的实体被授权—即，确定是否允许在步骤608验证的实体请求许可证(或者为其本身或者代表另一实体)。较佳地，许可证签发实体储存允许(或不允许)请求许可证的实体的列表。在一个较佳的实施例中，该身份列表中的身份是作出请求的实体的身份，而非为其请求许可证的实体的身份，尽管它可以是其中的任一个。例如，可能不允许以个人账号身份来直接作出许可证请求，但是可信服务器进程可代表这一实体来作出许可证请求。
依照本发明，许可证请求可包括每一潜在的被许可者的公钥证书或身份。如果许可证只是为一个被许可者请求的，则仅指定一个证书或身份。如果许可证是为多个被许可者请求的，则可对每一潜在被许可者指定证书或身份。
较佳地，许可证签发实体具有每一有效的被许可者的公钥证书。然而，应用程序302可能希望为给定的用户生成许可证，而应用程序302可能没有对该用户的公钥证书的访问权限。在这一情况下，应用程序302可在许可证请求中指定该用户的身份，结果，许可证签发实体可调用执行在目录服务中查找的已注册证书插入模块，并返回适当的用户的公钥证书。
如果在步骤608，签发实体确定公钥证书未包括在许可证请求内，则签发实体使用指定的身份执行目录服务或在数据库中的查找，以找出适当的公钥证书。如果在步骤610，签发实体确定证书在目录中，则在步骤612，检索该证书。在一个较佳的实施例中，使用证书插件通过目录访问协议从目录服务中检索公钥证书。如果对给定的潜在的被许可者，无论是在请求中还是在目录中都无法找到证书，则许可证服务器不为该潜在被许可者生成证书，并且在步骤614，向请求实体返回错误。
假定许可证签发实体具有至少一个潜在的被许可者的公钥证书，则在步骤616，签发实体确认被许可者证书的信任。较佳地，签发实体用一组可信证书签发者证书来配置，并且它确定被许可者证书的签发者是否在可信签发者的列表中。如果在步骤616，签发实体确定被许可者证书的签发者不在可信签发者列表中，则该被许可者请求失败，并在步骤614生成错误。由此，其证书不是由可信签发者签发的任何潜在被许可者都不会接收到许可证。
另外，签发实体较佳地在证书链中的所有实体上执行数字签名确认，该链是从可信签发者证书到个别的被许可者公钥证书。确认链中的数字签名的过程是一种公知的算法。如果给定的潜在被许可者的公钥证书不生效，或者链中的证书不生效，则潜在被许可者是不可信的，并且因此，不向该潜在被许可者签发许可证。否则，在步骤618，可签发许可证。该过程在步骤620重复，直到处理了要为其请求许可证的所有实体。
如图6B所示，许可证签发实体进而着手确认在许可证请求中接收的经签署的权限标签308。在一个较佳的实施例中，签发实体可使用一权限标签插件，以及一后端数据库，以在服务器上储存由签发实体签署的每一权限标签的主体副本。权限标签由在发行时放入其中的GUID标识。在许可时(步骤622)，签署实体分析许可证请求中输入的权限标签，并检索其GUID。它然后将该GUID传递到权限标签插件，它签发对数据库的查询以检索主权限标签的副本。主权限标签可以比许可证请求中发送的权限标签的副本更新，并且它可以是以下步骤的请求中所使用的权限标签。如果基于GUID在数据库中没有找到任何权限标签，则在步骤624，签发实体核查其策略，以确定它是否仍被允许基于请求中的权限标签签发证书。如果策略不允许这一行为，则在步骤626许可证请求失败，并在步骤628向API 306返回错误。
在步骤630，许可证签发实体确认权限标签308。确认权限标签上的数字签名，并且如果许可证签发实体不是该权限标签的签发者(签署它的实体)，则许可证签发实体确定权限标签的签发者是另一可信实体(如，允许与许可证签发实体共享关键资料的实体)。如果权限标签不生效，或者它不是由可信实体签发的，则在步骤626许可证请求失败，并在步骤628向API 306返回错误。
在作出了所有的确认之后，许可证签署实体对每一批准的被许可者将权限标签308转换成证书。在步骤632，许可证签发实体为每一被许可者签发的许可证生成相应的权限描述。对于每一被许可者，签发实体对照权限标签的权限描述中指定的实体来评估该被许可者的公钥证书中指定的实体。权限描述向每一权限或权限组分配可行使证书中该权限或权限组的一组身份。对于该被许可者身份所关联的每一权限或权限组，将该权限或权限组复制到该证书的一新的数据结构中。所得的数据结构是该特定被许可者的证书中的权限描述。作为该过程的一部分，证书签发实体评估可与该权限标签的权限描述中的权限或权限组的任一个相关联的任何前置条件。例如，权限可具有与其相关联的时间前置条件，它限制该权限签发实体在指定时间之后不可签发许可证。在这一情况下，签发实体需要核查当前时间，并且如果已超过了前置条件中指定的时间，则签发实体不能向被许可者签发该权限，即使该被许可者的身份是与该权限相关联的。
在步骤636，签发实体从权限标签308中取出(PU-RM(DES1))和(DES1(CK))，并应用(PR-RM)来获取(CK)。签发实体然后使用(PU-ENTITY)—被许可者的公钥证书—来重新加密(CK)，以得到(PU-ENTITY(CK))。在步骤638，签发实体将生成的权限描述与(PU-ENTITY(CK))串接，并使用(PR-RM)数字地签署所得的数据结构。该经签署的数据结构是该特定被许可者的许可证。
在步骤640，当签发实体确定对特定的请求没有更多的许可证要生成时，它将具有生成的零个或多个许可证。在步骤642，生成的许可证连同与那些许可证相关联的证书链(如，服务器自己的公钥证书以及签发其证书的证书等等)一起被返回到请求实体。
在依照本发明的系统的一个实施例中，可使用多个许可者密钥。在这一实施例中，加密地穿过权限标签308到许可证的内容密钥(CK)实际上可以是任意数据。一个尤其有用的变体是分别使用在权限描述中具有不同权限或不同主体的多个单独、加密的相关的内容密钥(CK)。例如，专辑上的歌曲的数字版本都可以用不同的密钥(CK)来加密。这些密钥(CK)可包括在同一权限标签中，但是一个主体可以有播放这些歌曲之一的权限(如，他可能只有获得其许可证中一个密钥的权限)，而第二主体可能具有播放所有歌曲的权限(她可能具有获得其许可证中所有密钥的权限)。
较佳地，依照本发明的系统使发行应用程序/用户能够在权限标签308中指定被许可者组或类。在这一实施例中，许可证签发实体将评估权限标签中指定的任何组/类来确定当前被许可者实体是否为那些组或类的成员。如果找到指定的组/类中的成员资格，则签发实体可将与该组/类相关联的权限或权限组添加到用于该许可证的权限描述数据结构中。
在本发明的一个较佳实施例中，RM服务器中的发行和许可证协议接口支持验证和调用应用程序或用户的验证，并且RM服务器的管理控制台允许管理员生成用于许可和发行接口的访问控制列表。这使服务器的顾客能够应用其中允许用户/应用程序发行、许可或两者的策略。
自发行经签署的权限标签308
在本发明的一个实施例中，SRL 308可由请求用户本身来签署。因此，用户不需要联系RM服务器320来获取相关联的内容片段的SRL 308。作为结果，自发行也可被称为离线发行。在这一实施例中，可要求用户联系RM服务器320来请求基于自发行的SRL 308的许可证。也应当理解，可令发行实体能够签发其自己的许可证。
具体地，并且现在参考图8，在该实施例中，首先通过从RM服务器320接收包括依照用户的公钥(PU-ENTITY)加密的公钥(PU-CERT)和对应的私钥(PR-CERT)的RM证书810来得到(PU-ENTITY(PR-CERT))，向用户供应自发行。该证书应当由RM服务器320的私钥签署，使得这一RM服务器320可核实该证书，如下文更详细讨论的。可以理解，RM证书810授权用户自发行。同样可以理解，密钥对(PU-CERT，PR-CERT)与(PU-ENTITY，PR-ENTITY)分离，并专用于自发行。注意，可省却密钥对(PU-CERT，PR-CERT)，在这一情况下，RM证书810仅包括用户的公钥(PU-ENTITY)并且由RM服务器320的私钥(PR-RM)签署，使得该RM服务器320可核实该证书。
自发行与图4所示的发行不同，对于所执行的步骤，用户本质上代替了RM服务器320。值得注意的是，用户用从RM证书810(即，S(PR-CERT))获得的(PR-CERT)来签署包括(PU-RM(DES1))和(DES1(权限数据))的所提交的权限标签，以得到经签署的权限标签(SRL)308。应当理解，用户通过从RM证书810获取(PU-ENTITY(PR-CERT))并向其应用(PR-ENTITY)，来从该RM证书810获取(PR-CERT)。尽管注意到，用户无法核实RM服务器320可实施提交的权限标签中的权限，尤其是因为用户没有(PR-RM)来应用到(PU-RM(DES1))。因此，RM服务器320本身应当在请求许可证时基于自发行SRL 308来执行核实。
一旦用户自发行了SRL 308，用户将这一自发行的SRL 308与用于产生内容的RM证书的RM证书810串接，并且具有SRL 308和RM证书810的这一内容被分发到另一用户。之后，其它用户以如图6A和6B所示的基本上相同的方式从RM服务器320获取该内容的许可证。尽管在此处，许可证请求用户向RM服务器320提交串接到内容上的自发行的SRL 308和RM证书810。RM服务器320然后基于对应的(PU-RM)核实RM证书810中的S(PR-RM)，并从RM证书810中获取(PU-CERT)。RM服务器320然后基于所获取的(PU-CERT)核实SRL 308中的S(PR-CERT)，并如上所述地继续。尽管注意到，由于用户不核实RM服务器320可实施SRL 308中的权限，并且如上所述，RM服务器320本身应当在这一时刻执行核实。
权限模板
如上所述，通过定义用户或用户类、定义每一定义的用户或用户类的权限、然后定义任何使用条件，来向用户提供了在权限标签中创建几乎任何种类和类别的权限数据的自由度。然而，并且值得注意的是，对多个权限标签重复地定义权限数据可以是棘手且重复的，尤其是当对不同的内容段重复定义同一用户或用户类、权限和条件。例如，这一情况可以在组织或办公室环境中发生，其中，用户重复地发行要与特定的所定义的用户团队共享的不同的内容段。因此，在这一情况下，在本发明的一个实施例中，创建了一种权限模板，用户可重复地采用该权限模板创建权限标签，其中，权限模板已在其中包括了预定义的用户组或用户类、每一定义的用户或用户类的预定义的权限、以及预定义的使用条件。
在本发明的一个实施例中，并且转向图9，权限模板900基本上具有与将要在权限标签中相同的权限数据。然而，由于发行内容之前(DES1)和/或(CK)是未知的，权限数据不能依照这一(DES1)或(CK)(在本情况中为权限标签)来加密。因此，在本发明的一个实施例中，在用图4的步骤416的(DES1)或(CK)加密权限数据来产生(DES1(权限数据))或(CK(权限数据))的过程中，提交的是具有未加密权限数据的权限模板900。当然，在被如此加密之前，从提交的权限模板900检索权限数据。
在构造权限模板时，RM服务器320和其公钥(PU-RM)可以是已知或未知的。此外，即使已知，也可以有或没有一个以上RM服务器320，其每一个都有自己的(PU-RM)。然而，在构造权限模板时RM服务器320和其公钥(PU-RM)已知的情况下，并且在仅采用了一个RM服务器320，或只有一个RM服务器320将用于权限模板900的情况下，这一权限模板也在其中包括RM服务器上签署的信息，它得自权限模板900的权限标签，包括其公钥(PU-RM)。尽管该(PU-RM)出现在SRL308中作为加密(DES1)或(CK)以得到(PU-RM(DES1))或(PU-RM(CK))，再一次可以理解，(DES1)和/或(CK)在内容被发行之前是未知的，并且因此，权限模板900中的(PU-RM)不能加密这一(DES1)或(CK)，如同权限标签中的情况一样。因此，在本发明的一个实施例中，在用图4的步骤414的(PU-RM)加密(DES1)以产生(PU-RM(DES1))的过程中，或在产生(PU-RM(CK))的过程中，提交的是具有未加密的(PU-RM)的权限模板900。当然，在被采用之前，从提交的权限模板900检索(PU-RM)。
同样在上述情况中，RM服务器上的可包括在权限模板中的其它信息还可能包括诸如用于查找网络上的RM服务器的URL等参考信息，以及如果URL失败时的后退信息。在任何情况下，权限模板也包括描述权限模板900本身的信息等。注意，权限模板900也可提供涉及要发行的内容的信息的空间，如出现在权限标签中涉及内容和/或加密密钥(CK)和(DES1)的信息，尽管如果权限模板的实例化实际上未被转换成权限标签，则这一空间是不必要的。
尽管迄今为止所揭示的权限模板900主要是用于用户的方便，然而也可理解，在某些情况下，用户不应当有在权限标签中定义权限数据的不受限制的自由度，并且权限模板900可用于限制可被创建的权限标签的范围或类型。例如，并且尤其在组织或办公室环境的情况下，可以预定义一种策略，特定的用户应当总是仅向特定用户类发行内容，或该用户应当从不向特定用户类发行内容。在任一情况下，并且在本发明的一个实施例中，这一策略被实施为一个或多个权限模板900中的预定义权限数据，并且用户在发行内容时被限制采用这些权限模板来创建权限标签。特别地，由用户用于指定用户的发行策略的权限模板或权限模板组可指定任何特定类型的发行策略，而不会脱离本发明的精神和范围。
现在转向图10，为指定受限制用户或类似用户的权限模板900，管理员或类似人员实际上通过定义预定义权限数据(步骤1001)，并定义可能必要的和适当的任何其它数据，如涉及特定RM服务器320的信息(步骤1003)，来构造权限模板900。值得注意的是，为完成受限制的用户或类似用户所使用的权限模板，必须将权限模板900变为正式的。即，权限模板900必须被识别为受限制的用户或类似用户可采用的权限模板。因此，在本发明的一个实施例中，由管理员或类似人员构造的权限模板被提交给RM服务器320由其签署，在其中，这类签署使权限模板变为正式的(步骤1005)。
注意，签署RM服务器320是其信息在权限模板900中的RM服务器320，如果这类信息的确在权限模板900中。同样注意，RM服务器320可仅在作出任何必要的核查之后签署权限模板900，或者可在不做任何核查的情况下签署。最后要注意，来自RM服务器的模板签名S(PR-RM-T)(其中，-T表示签名是用于ORT 900的)应当至少基于权限模板900中的预定义权限数据，但是也可基于其它信息而不脱离本发明的精神和范围。如上所述，签名S(PR-RM-T)可被结合到权限标签中，并且可与其结合地核实，并且因此，不论签名基于什么，它都应当以未改变形式被结合到权限标签中。
在RM服务器320签署了权限模板900并向管理员或类似人员返回该模板之后，管理员接收具有S(PR-RM-T)的经签署的并且现在是正式的权限模板900(步骤1007)，并将该正式的权限模板(ORT)900转发到一个或多个用户供其使用(步骤1009)。因此，对于要基于ORT 900发行内容的用户，该用户检索ORT 900(步骤1011)，并通过提供任何必要的信息，诸如内容上的信息、适当的密钥信息、来自ORT 900用(DES1)或(CK)加密以得到(DES1(权限数据))或(CK(权限数据))的的权限数据、以及来自ORT 900的任何其它信息，来基于该ORT 900构造权限标签(步骤1013)。值得注意的是，与权限标签一起，用户还包括来自ORT 900的签名S(PR-RM-T)。
之后，如上所述，用户向RM服务器320提交权限标签用于签署(步骤1015)。此处，尽管RM服务器320将不签署所提交的权限标签，除非核实其中的S(PR-RM-T)。即，RM服务器320通过拒绝在这一提交的权限标签不包括ORT 900的签名S(PR-RM-T)的情况下签署提交的权限标签，来强制用户必须将提交的权限标签基于ORT 900。具体地，RM服务器320从所提交的权限标签检索该S(PR-RM-T)以及这一签名所基于的任何信息，然后基于(PU-RM)核实该签名。注意，提交的权限标签中的权限数据是依照(DES1)(即，(DES1(权限数据)))或(CK)(即，(CK(权限数据)))来加密的。因此，RM服务器320必须首先如上结合图7所述地来解密经加密的权限数据，以能够基于提交的权限标签中的权限数据来核实签名。
一旦被核实，RM服务器320用S(PR-RM-L)签署提交的权限标签，以产生SRL308，如上所述(其中，-L表示该签名是用于SRL 308的)。此处，S(PR-RM-L)可替换S(PR-RM-T)，或作为该S(PR-RM-T)的补充。如果是补充，则S(PR-RM-L)可部分地基于S(PR-RM-T)。注意，可使用(PR-RM)来产生S(PR-RM-T)和S(PR-RM-L)，或可对S(PR-RM-T)和S(PR-RM-L)的每一个使用不同的(PR-RM)。在RM服务器320签署权限标签并向用户返回SRL 308之后，用户接收具有S(PR-RM-L)的SRL 308(步骤1017)，并进而将该SRL串接到要发行的内容，如上所述。
灵活的权限模板
如果ORT 900的S(PR-RM-T)是至少部分地基于ORT 900中的预定义权限数据的，则在SRL 308中出现的该权限数据不能被修改或改变。否则，出现在SRL 308中的S(PR-RM-T)将不能得到核实。然而，在本发明的一个实施例中，ORT 900中的权限数据可在预定的规则之内变化，这些规则也包括在ORT 900之内。例如，规则可指定要包括在SRL 308中的一组或多组权限数据，或可允许从一组替换数据中选择。可以理解，规则可以是以任一合适的句法陈述的任何特定的规则，而不脱离本发明的精神和范围。此处，在创建权限标签时，用适当的规则解释程序向用户解释规则。尽管权限数据可以变化，然而规则不会同样地变化，并且因此，ORT900的模板签名S(PR-RM-T)可以部分地基于规则而不基于权限数据本身。如果是，则包括在ORT 900中的规则也可包括在SRL 308中。
在本发明的一个实施例中，如上所述，ORT 900中的预定义权限数据是部分固定不变的，并且是部分可变、灵活且规则驱动的。此处，ORT 900的模板签名S(PR-RM-T)部分地基于权限数据的固定部分的至少一个，以及权限数据的灵活部分的规则。
诸如ORT 900等权限模板中的灵活性可以若干方式的任一种来展示，如后文所陈述的。
如上所述，并结合图4A可见到的，ORT 900可指定一个或多个特定用户或用户组的每一个及其权限，其中，这些用户由此可基于该SRL 308来获取许可证16。然而，这一ORT 900尤其不允许发行者在发行基于这一ORT 900的SRL 308时关于指定这些用户、这些权限和任何相关的条件等的任何选项。换言之，迄今为止所揭示的ORT 900不允许发行者在定义可基于ORT 900获取许可证16的这类用户、要在许可证16中指定的这类用户的权限、要在许可证16中指定的且用户必须满足来采用这些权限的条件等等中的灵活性。
因此，在本发明的一个实施例中，通过在其中指定任何要求的用户子集、每一用户的任何要求的许可证权限子集、和权限的任何要求的条件子集，以及当发行者在基于ORT 900发行的过程中选择这些用户、权限和条件时所采用的对应规则，而令ORT 900变得灵活。表示这类用户、权限和条件以及其规则的伪代码如下：<RIGHTS TEMPLATE> ... <USERS，RIGHTS，CONDITIONS>
<USERS>
<DEFINITION OF ALLOWABLE USERS>
...
</DEFINITION OF ALLOWABLE USERS>
<RULES>
...
</RULES>
</USERS>
<RIGHTS>
<DEFINITION OF ALLOWABLE RIGHTS>
...
</DEFINITION OF ALLOWABLE RIGHTS>
<RULES>
...
</RULES>
</RIGHTS>
<CONDITIONS>
<DEFINITION OF ALLOWABLE CONDITIONS>
...
</DEFINITION OF ALLOWABLE CONDITIONS>
<RULES>
...
</RULES>
</CON DITIONS> </USERS，RIGHTS，CONDITIONS> ...</RIGHTS TEMPLATE>
例如，对于用户，ORT 900可允许发行者指定组织内的任何用户，或组织内仅在预定义组内的用户、或仅指定的个别用户、或其组合。同样，ORT 900可允许发行者指定任何用户或用户组，但也可要求发行者将特定的管理用户指定为“最后一人”用户，它可在组织中没有其它用户能如此获取许可证16的情况下获取该许可证16。
对于权限和条件，ORT 900可允许发行者向特定用户或用户组授予所有权限、或可将特定用户或用户组限制到特定权限、或只要另一用户可获取所有权限就将一个用户限制到特定权限、或其组合。同样，ORT 900可要求发行者向特定用户或用户组授予所有权限，例如上述最后一人用户。类似地，ORT 900可要求第一类型用户的权限以第一方式调节，并且第二类型用户的同一权限以第二方式调节。因此，应当理解，在ORT 900中指定用户、权限、条件等的方式可以是任何适当的方式，而不脱离本发明的精神和范围。
如上所述，并结合图4A和9所见到的，ORT 900以及从其导出的SRL 308可指定一个或多个特定用户或用户组的每一个以及其权限，其中，这些用户由此可获取基于该SRL 308的许可证16。然而，该ORT 900尤其不会同样地指定一个或多个用户或用户组的每一个，其中，这些用户可采用ORT 900来发行。换言之，迄今为止所揭示的ORT 900不允许关于可使用该ORT 900来发行的用户的任何选择性。
因此，在本发明的一个实施例中，通过在其中指定可采用ORT 900来发行的一个或多个用户或用户组的每一个，并且可能让对应的规则陈述如何确保希望采用ORT 900来发行的发行者确实是ORT 900中指定的发行者，并因此该规则由ORT900遵循来基于该ORT 900发行，而令ORT 900变得灵活。表示允许发行的这类用户的伪代码如下：<RIGHTS TEMPLATE> ... <USERS ALLOWED TO PUBLISH>
<DEFINITION OF ALLOWED USERS>
...
</DEFINITION OF ALLOWED USERS>
<RULES>
...
</RULES>
</USERS ALLOWED TO PUBLISH>
...
</RIGHTS TEMPLATE>
由此，作为一个示例，组织中的财务部门可具有为其创建的特定的财务ORT 900，其中，该特定的财务ORT 900在其中指定了这一财务部门的所有成员和组织的会计部门的所有成员可使用该财务ORT 900。同样，组织中的法律部门可具有为其创建的特定的法律ORT 900，其中，该特定的法律ORT 900在其中指定了该法律部门中是律师的所有成员可使用该法律ORT 900。
注意，对应的规则可能只要求潜在的发行者在ORT 900中具体地列出，或潜在的发行者是ORT 900中具体列出的组的成员。可选地，对应的规则可要求潜在的发行者在ORT 900中具体地列出，并且潜在的发行者是ORT 900中具体列出的组的成员，或者要求潜在的发行者满足另一更复杂的要求。应当理解，对应的规则可以是任一合适的规则，而不脱离本发明的精神和范围。
如上所述，并可结合图4A所见到的，SRL 308包括RM服务器320的公钥，它加密(DES1)或(CK)来产生(PU-RM(DES1))或(PU-RM(CK))，由此，仅这一RM服务器320可在向请求用户签发许可证的过程中访问(DES1)或(CK)。相应地，结合图9所见到的，ORT 900包括这一(PU-RM)，并由此使用这一ORT 900导致SRL 308被特别地捆绑到RM服务器320，并也导致许可证16被特别地捆绑到这一RM服务器320。
因此，在本发明的一个实施例中，通过在其中包括若干不同的RM服务器320的每一个的公钥(PUx-RM)，以及指定如何在基于ORT 900构造权限标签时通过其对应的(PUx-RM)来选择这些不同的一个或多个RM服务器320的对应的规则，而令ORT 900变得灵活。表示允许连同规则一起许可的这一RM服务器320的伪代码如下：<RIGHTS TEMPLATE> ... <LICENSING SERVERS>
<SERVER 1>
<NAME>
...
</NAME>
<ADDRESS>
...
</ADDRESS>
<PUBLIC KEY>
...
</PUBLIC KEY>
</SERVER 1>
<SERVER 2>
<NAME>
...
</NAME>
<ADDRESS>
...
</ADDRESS>
<PUBLIC KEY>
...
</PUBLIC KEY>
</SERVER 2>
...
<RULES>
...
</RULES>
</LICENSING SERVERS>
...</RIGHTS TEMPLATE>
例如，ORT 900可指定公钥(PU1-RM)、(PU2-RM)和(PU3-RM)，它们分别对应于第一、第二和第三RM服务器320，以及指定从这一ORT 900导出的权限标签的规则可包括这些第一、第二和第三RM服务器320的任一个或全部。注意，这些第一、第二和第三RM服务器320可以是发行者的组织内和/或发行者的组织外的RM服务器320。在后一情况下，如果发行者的组织外的用户具有从指定的RM服务器320的任一个获取许可证16的权限，可向这些用户提供对由这些发行者发行的内容12的访问权限。
现在应当理解，发行者在从ORT 900中选择每一特定的(PUx-RM)以出现在SRL 308中时，实际上将这一(PUx-RM)放置在SRL 308中作为加密(CK)或(DES1)(后文称为“(CK)”或等效称法)。作为示例，如果发行者从ORT 900选择(PU1-RM)和(PU3-RM)，所得的SRL 308将包括(PU1-RM(CK))和(PU3-RM(CK))。作为结果，允许用户从第一或第三RM服务器320获取许可证16，另外也认为这些用户具有从RM服务器320如此获取这一许可证16的权限。
以类似的方式，如上所述并结合图9可以见到的ORT 900不指定可在发行过程中基于这一ORT 900提供SRL 308的特定的RM服务器320。因此，在本发明的一个实施例中，通过在其中包括可被用于如此发行的特定的RM服务器320的一个或多个的每一个的公钥(PUx-RM)，以及指定如何在基于这一ORT 900构造权限标签时通过其对应的(PUx-RM)从RM服务器320中选择的对应的规则，而令ORT900变得灵活。类似于上述内容，表示允许连同规则一起发行的这一RM服务器320的伪代码如下：<RIGHTS TEMPLATE> ... <PUBLISHING SERVERS>
<SERVER 1>
<NAME>
...
</NAME>
<ADDRESS>
...
</ADDRESS>
<PUBLIC KEY>
...
</PUBLIC KEY>
</SERVER 1>
<SERVER 2>
<NAME>
...
</NAME>
<ADDRESS>
...
</ADDRESS>
<PUBLIC KEY>
...
</PUBLIC KEY>
</SERVER 2>
...
<RULES>
...
</RULES> </PUBLISHING SERVERS> ...
</RIGHTS TEMPLATE>
例如，ORT 900可指定分别对应于上述第一、第二和第三服务器320的上述公钥(PU1-RM)、(PU2-RM)和(PU3-RM)，以及指定权限标签仅仅是通过该第一、第二或第三RM服务器320从该ORT 900导出的规则。可选地，规则可指定要采用第一RM服务器320(除非不可用)，在不可用的情况下可采用第二或第三RM服务器320。如上所述，这些第一、第二和第三RM服务器320可以是发行者的组织内和/或发行者的组织外的RM服务器320。
ORT 900中可用于基于该ORT 900来发行的RM服务器320的列表不必要出现在从该ORT 900导出的SRL 308中，尤其是因为这一列表可能在这一SRL 308中无用。然而，该列表仍可出现在SRL 308中，而不脱离本发明的精神和范围。
注意，迄今为止所揭示的ORT 900其中包括直接地陈述的信息，由此，改变这一信息的唯一方法是改变ORT 900。然而，可以理解，可能必须以更迅速的方式来改变这一信息。例如，如果某一用户不应当再在组织的一个或多个ORT 900中具体地列出，则编辑每一这样的ORT 900来从中移除该用户是棘手的，尤其是如果该组织是相当大的且用户可以在该组织的上百甚至上千个这样的ORT 900中列出。同样，如果某一RM服务器320要作为许可证16的签发者添加到组织的一个或多个ORT 900中，则再一次，编辑每一这样的ORT来向其添加RM服务器320也是棘手的。
因此，在本发明的一个实施例中，诸如易受改变的那些特定信息片段不必要直接出现在ORT 900中，而相反，可在ORT 900中被表示为到可从其获取该信息的未知的引用。这一引用可例如是指针或其类似物。包括这一引用的伪代码如下：<RIGHTS TEMPLATE> ... <LICENSING SERVERS>
<SERVER 1>
[REFERENCE TO SERVER 1 INFORMATION]]
</SERVER 1>
<SERVER 2>
[REFERENCE TO SERVER 2 INFORMATION]]
</SERVER 2>
...
</LICENSING SERVERS>
...</RIGHTS TEMPLATE>
当然，如有必要，通过这一引用获取的该信息应当直接出现在从ORT 900导出的SRL 308中。应当理解，可从其获取信息的位置应当是不易受希望试图改变这一位置内的这一信息的罪恶的实体所影响的安全位置。
可以理解，ORT 900中所引用的信息可以是任何合适的信息，而不脱离本发明的精神和范围。例如，所引用的这一信息可包括发行者可用于发行的特定RM服务器320的公钥、发行者可用于发行的所有RM服务器320的公钥的列表、ORT 900和从其导出的SRL 308中上述最后一人用户的特定用户、ORT 900和从其导出的SRL 308中的所有用户的列表、特定用户的权限列表、特定权限的条件列表等等。
在本发明的另一实施例中，诸如易受改变的那些信特定信息片段可通过通配符、变量或其类似物出现在ORT 900中。由此，作为一个示例，与个别地指定ABC公司的每一用户相反，ORT 900可通过诸如“*@ABC”等项来简单地指定所有这类用户，其中，“*”是用于每一用户的通配符，而“@ABC”表示ABC公司。包括这一通配符的伪代码如下：<RIGHTS TEMPLATE>
...
<USERS ALLOWED TO PUBLISH>
<DEFINITION OF ALLOWED USERS>
*@ABC
</DEFINITION OF ALLOWED USERS>
... </USERS ALLOWED TO PUBLISH> ...</RIGHTS TEMPLATE>
类似地，一些类型的通配符的使用可包括“M*@engineering@XYZ”，即，XYZ公司的工程部门中用户名以M开头的所有用户；“@projectx@research@PDQ”，即，PDQ公司的研究部门中项目X的所有用户；等等。再一次，如有必要，通过这一通配符、变量或其类似物获得的信息应当直接出现在从ORT 900导出的SRL308中。
通常，在基于ORT 900构建SRL 308时，包括其签名S(PR-RM-T)的ORT 900被放置在权限标签中，并且由此，可在权限标签内通过替换引用、变量、通配符和ORT 900中可变化的其它解析权限数据来修改。之后，如结合图6A和6B所述的，向适当的RM服务器320提交的具有被修改的权限数据的权限标签用于签署以产生SRL 308。表示这一SRL 308的伪代码如下：<SIGNED RIGHTS LABEL> ... <TEMPLATE>
[TEMPLATE INFO]
<TEMPLATE SIGNATURE/> </TEMPLATE> ... [RIGHTS LABEL INFORMATION] <RIGHTS LABEL SIGNATURE/> ...</SIGNED RIGHTS LABEL>
由此，并如上所述，出现在SRL 308中的ORT 900的签名S(PR-RM-T)必须基于ORT 900中不变化的权限数据的至少某些部分。否则，这一签名S(PR-RM-T)在权限数据出现在从这一ORT 900导出的SRL 308中时将不会核实它。然而，如果缺少任何预定义的方案，试图核实签名S(PR-RM-T)的核实者可能不知道权限数据的哪些部分实际上是签名所基于的那些不改变部分，并且由此，不知道实际上如何来核实签名。
因此，在本发明的一个实施例中，权限数据以加标签的格式，如可扩充标记语言(XML)格式出现在ORT 900中，并由此出现在SRL 308中，其中，作为签名S(PR-RM-T)的基础的该权限数据的每一部分被如此地标记。例如，作为基础的权限数据的每一部分用一特殊的标签来标记，或可用具有特殊属性的标签来标记。表示具有已标记部分的ORT 900的伪代码如下：<RIGHTS TEMPLATE>
...
<PUBLISHING SERVERS>
<SERVER 1，marked＝yes>
...
</SERVER 1>
<SERVER 2>
...
</SERVER 2>
...
<RULES，marked＝yes>
...
</RULES>
</PUBLISHING SERVERS>
...</RIGHTS TEMPLATE>
现在应当理解，为核实SRL 308中的签名S(PR-RM-T)，核实者然后只需标识SRL 308中被标记为签名S(PR-RM-T)的基础的权限数据的每一部分、检索这些标记的部分并将它们适当地串接来形成一签名块、然后采用这一签名块来核实签名S(PR-RM-T)。当然，标记部分的串接可以任一合适的方式来完成，而不脱离本发明的精神和范围。例如，这一串接可以按照每一标记的部分在SRL 308中出现的顺序来进行。
在揭示了灵活的ORT 900之后，转向图11，可以与下列相同的方式来执行SRL308以及基于其上的许可证16的创建。预备性地，ORT 900本身由组织内适当的实体创作，并适当地置于数据库或其类似物内，使得该ORT 900潜在地可由希望基于该ORT 900来发行的任何发行者访问(步骤1101)。例如，这一ORT 900可向WBPA公司的法律部门的任一用户(即，*@legal@WBPA)授予权限、可允许发行者指定每一这样的用户的任何权限以及每一这样的权限的任何条件、可定义这一法律部门的所有执行成员(即，*@exec@legal@WBPA)能够基于这一ORT 900发行、并且可指定如由各自的公钥(PU1-RM)、(PU2-RM)、(PU3-RM)标识的三个特定的RM服务器320用于签发许可证16。储存在数据库或其类似物中的ORT 900应当包括可能以与上述的类似方式陈述ORT 900的这些特征陈述的描述部分。在创作ORT 900的过程中，其作者适当地标记其中应当不被修改的权限数据的部分，然后基于权限数据的这些标记的部分签署ORT 900，以得到包括在这一ORT 900内的数字签名。
之后，作者起草某种类型的内容12，并决定发行这一创作的内容12(步骤1103)。因此，这样的作者—现在担当发行者—用内容密钥(CK)加密内容12(步骤1105)、在上述数据库或其类似物中查找感兴趣的一个或多个ORT 900、并可能基于每一ORT 900的描述部分，作者/发行者选择适当的ORT 900来使用(步骤1107)。在本发明的一个实施例中，数据库或其类似物中的每一ORT 900都向发行者显示，但是仅当发行者在ORT 900内被定义为能够使用该ORT时才显示。由此，对于上述示例ORT 900，这一ORT 900仅在发行者是WBPA公司的法律部门的执行成员时才对该发行者显现，并且如果发行者是WBPA公司的法律部门的执行成员，对应的发行者只能使用这一ORT 900。否则，假定另一ORT 900满足这一发行者的发行需求，发行者必须使用该另一ORT 900。
现在假定上述示例ORT 900实际上可由该发行者使用，则向该发行者呈现该ORT 900，并且然后给予发行者修改与ORT 900中的规则和其上的限制相一致的权限数据的指令(步骤1109)。由此，基于上述的示例ORT 900，发行者可选择WBPA公司的法律部门的一个或多个用户的任一个作为权限的接收者，并可选择每一这样的用户的任何权限和每一这样的权限的任何条件。
一旦作者完成了修改ORT 900的权限数据，发行者然后基于这一修改的权限数据，以类似于上述的方式来发行(步骤1111)。此处，可以理解，ORT 900中修改的权限数据和ORT 900中的签名连同依照(PU1-RM)、(PU2-RM)和(PU3-RM)的每一个加密来产生(PU1-RM(CK))、(PU2-RM(CK))和(PU3-RM(CK))的内容密钥(CK)，以及可能的其它数据一起被放入权限标签中，并且然后将权限数据发送到适当的RM服务器用于签署，以产生基于其上的SRL 308。之后，发行者串接SRL308和加密的内容12，以形成包13，并适时地将具有加密内容12的包13分发到一个或多个用户(步骤1113)。
在接收包13并希望呈现其中的内容12时，特定的用户通过ORT 900向SRL308中指定的三个特定许可证签发RM服务器320之一呈现包13的SRL 308以及适当的证书，如由各自的公钥(PU1-RM)、(PU2-RM)、(PU3-RM)所标识的(步骤1115)，并且如果适当，用户从RM服务器320接收许可证16(步骤1117)。应当理解，授权RM服务器320仅在SRL 308的签名被核实，并且仅当放置在SRL 308中的ORT 900的签名被核实时，才签发这一许可证，其中，ORT 900的签名对照SRL 308中适当标记的权限数据来核实。也应当理解，授权RM服务器320用用户的公钥(PU-USER)加密(CK)来形成(PU-USER(CK))，以替换SRL 308中的(PUx-RM(CK))，其中，(PU-USER)从所呈现的证书中获得。当然，假定许可证16向用户授予权限以已探寻的方式呈现内容12的权限，则用户实际上是基于这一许可证16来呈现这一内容12。
总结
实现结合本发明执行的过程所需要的程序设计是相对直截了当的，并且应当对相关的编程公众是显而易见的。因此，这些程序不附加于此。可使用任何特定的程序来实现本发明，而不脱离其精神和范围。
由此，描述了用于通过经签署的权限标签签发数字内容和服务的使用许可证的系统和方法。本领域的技术人员可以理解，可对本发明的较佳实施例作出许多改变和修改，并且这些改变和修改可在不脱离本发明的精神和范围的情况下作出。因此，所附权利要求书旨在覆盖落入本发明的精神和范围之内的所有这样的等效变化方案。
在上文的描述中，可以看到，本发明包括一种允许任意形式的数字内容12的受控制的呈现或播放的新的而且有用的体系结构和方法，其中，这一控制是灵活的，且可由这一数字内容12的内容所有者/开发者来定义。该体系结构允许并方便了这一受控制的呈现，尤其是在办公室或组织环境或其类似环境中，其中，文档要在定义的个人组或个人类之间共享。该体系结构也向这一环境中的数字内容12的发行者提供了一种预定义的模板/ORT 900，它指定了对于这一数字内容的用户和这类用户的权限，其中，该模板/ORT 900本质上是灵活的。
附录1
示例权限数据<？xml version＝″1.0″？><XrML version＝″1.2″>
<BODY type＝″Rights Template″>
<DESCRIPTOR>
<OBJECT>
<ID type″GUID″>c43...</ID>
<NAME>$$411$411name$411desc</NAME>
</OBJECT>
</DESCRIPTOR>
<WORK>
<OBJECT>
<ID/>
</OBJECT>
<RIGHTSGROUP name＝″MAIN RIGHTS″>
<RIGHTSLIST>
<VIEW>
<USERUST>
<ACCESS>
<PRINCIPAL>
<OBJECT>
<ID/>
<NAME>test@company.com</NAME>
</OBJECT>
</PRINCIPAL>
</ACCESS>
</USERLIST>
<NIEW>
<RIGHT name＝″generic″>
<USERLIST>
<ACCESS>
<PRINCIPAL>
<OBJECT>
<ID/>
<NAME>test@company.com</NAME>
</OBJECT>
</PRINCIPAL>
</ACCESS>
</USERLIST>
</RIGHT>
</RIGHTSLIST>
</RIGHTSGROUP>
</WORK>
</BODY>
<SIGNATURE>
<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>
<DIGEST>
<ALGORITHM>SHA1</ALGORITHM>
<PARAMETER name＝″codingtype″>
<VALUE encoding＝″string″>surface-coding<NALUE>
</PARAMETER>
<VALUE encoding＝″base64″size＝″160″>Mwl...＝<NALUE>
</DIGEST>
<VALUE encoding＝″base64″size＝″1024″>Msi...＝<NALUE> </SIGNATURE></XrML>
附录2
示例经签署的权限标签(SRL)308<？xml version＝″1.0″？><XrML version＝″1.2″>
<BODY type＝″Rights Label"version＝″3.0″>
<ISSUEDTIME>2002-01-01_12:00:00</ISSUEDTIME>
<DESCRIPTOR>
<OBJECT>
<ID/>
<NAME>$$409$...</NAME>
</OBJECT>
</DESCRIPTOR>
<ISSUER>
<OBJECT type＝″RM-Server″>
<ID type＝″GUID″>{d81...}</ID>
<NAME>Test RM Server</NAME>
<ADDRESS type＝″URL″>http：//licensing.dev.com</ADDRESS>
</OBJECT>
<PUBLICKEY>
<ALGORITHM>RSA</ALGORITHM>
<PARAMETER name＝″public-exponent″>
<VALUE encoding＝″integer32″>65537<NALUE>
</PARAMETER>
<PARAMETER name＝″modulus″>
<VALUE encoding＝″base64″size＝″1024″>NcO...＝<NALUE>
</PARAMETER>
</PUBLICKEY>
<ENABLINGBITS type＝″sealed-key″>
<VALUE encoding＝″base64″size＝″1024″>tFg...＝<NALUE>
</ENABLINGBITS>
<SECURITYLEVEL name＝″Server-Version″value＝″2.0″/>
<SECURITYLEVEL name＝″Server-SKU″value＝″22222-3333″/>
</ISSUER>
<DISTRIBUTIONPOINT>
<OBJECT type＝″LICENSE ACQUISITION URL″>
<ID type＝″GUID″>{0F4...}</ID>
<NAME>RM Server Cluster</NAME>
<ADDRESS type＝″URL″>http：//localhost/Licensing</ADDRESS>
</OBJECT>
</DISTRIBUTIONPOINT>
<WORK>
<OBJECT type＝″TEST-FORMAT″>
<ID type＝″MYID″>FDB-1</ID>
</OBJECT>
<METADATA>
<SKU type＝″PIDTYPE″>PID</SKU>
</METADATA>
<PRECONDITIONLIST>
<TIME/>
</PRECONDITIONLIST>
</WORK>
<AUTHDATA name＝″Encrypted Rights data″>PAB...</AUTHDATA>
</BODY>
<SIGNATURE>
<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>
<DIGEST>
<ALGORITHM>SHA1</ALGORITHM>
<PARAMETER name＝″codingtype″>
<VALUE encoding＝″string″>surface-coding</VALUE>
</PARAMETER>
<VALUE encoding＝″base64″size＝″160″>Prc...＝</VALUE>
</DIGEST>
<VALUE encoding＝″base64″size＝″1024″>EHd...＝</VALUE>
</SIGNATURE>
</XrML>
机译： 在权限管理系统中使用灵活的权限模板获取数字内容的签名权限标签（SRL）
机译： 在权限管理系统中使用灵活的权限模板获取数字内容的签名权限标签（SRL）
机译： 在权限管理系统中使用灵活的权限模板获取数字内容的签名权限标签（SRL）
