CN100419772C - 在数字版权管理系统中合并版权控制信息的方法及系统 - Google Patents

Abstract

本发明公开了一种在数字版权管理系统中合并版权控制信息的方法，该方法根据所述版权控制信息中包含的能够有效标识对应的原始媒体内容的媒体内容标识，获取包含同一媒体内容标识的所有版权控制信息；将所述所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中，由合并后的版权控制信息控制用户使用所述媒体内容。本发明还同时公开了一种数字版权管理系统及终端设备。

Description

在数字版权管理系统中合并版权控制信息的方法及系统

技术领域

本发明涉及通信技术的数字版权管理技术，尤其涉及在数字版权管理系统中合并版权控制信息的方法及系统。

背景技术

数字版权管理(DRM)该技术可以有效防止用户通过网络和计算机非法复制、传送数字媒体内容，从而保护媒体内容开发者的利益，是实现将媒体内容通过网络进行销售的前提条件之一。其基本原理是：媒体内容的发行者(ContentIssuer，CI)将加密后的数字媒体内容上传到网络服务器供用户下载，而将媒体内容的解密密钥、使用权限等交给权限发行者(Right Issuer，RI)管理，后者将密钥、使用权限等信息写入权限对象(Right Object，RO)中；用户如果要使用媒体内容，除了从CI服务器上下载加密的媒体内容外，还必须向RI购得与该媒体内容相应的RO；此外，用户终端设备上必须有一个版权代理模块(DRM Agent)，该模块能读取RO中的密钥(CEK)对媒体内容进行解密，并根据RO中所描述的权限信息控制用户对媒体内容的使用。这种将占用空间较大的媒体内容与占用空间较小的RO相分离的技术，除了是技术本身的需要外，也给用户带来了很大的方便，尤其在合理使用设备上的存储空间方面：例如，用户可以先批量购买若干RO，然后再视存储空间的裕量而下载部分对应的媒体内容到设备上使用，也可以删除部分暂时不需要使用的媒体内容以腾出存储空间，而仅保留相应的RO，待需要使用的时候，再重新下载。

随着媒体业务的不断发展，CI提供的媒体内容将越来越丰富，相应地，RI发行的RO也将越来越多，不仅如此，随着商业运作的发展，RI也会越来越多，同一个CI发行的媒体内容，其RO可能由多个RI来发行，在众多的RI、琳琅满目的RO面前，用户很可能在不经意间为同一份媒体内容重复购买了RO(这些RO可能包含同一份媒体内容完全相同的使用权限，也可能完全不同)，造成同一设备上同一份媒体内容存在多个RO的现象。

由于技术的有效保护，RO将成为一种利益的载体，进而成为人们礼尚往来的工具，可以预见的是，朋友之间互赠RO将是日益繁荣的景象，尤其是在值得庆祝的节日期间。不过用户在享受物质交流带来快乐的同时，也将遇到一些尴尬的场面，因为用户会经常发现不同的朋友给自己赠送了同一份媒体内容的RO，或者自己手头已有这份媒体内容的RO(这些RO包含的权限也可能完全相同也可能完全不同)，从而也造成同一设备上同一份媒体内容存在多个RO的现象。

随着家庭网络技术与DRM技术的发展，人们将轻易建立自己的家庭网络。家庭的不同成员可能由于缺乏默契，同时为同一份媒体内容购买了绑定到家庭域的RO(这些RO包含的权限可能完全相同也可能完全不同)，造成在家庭域范围内同一份媒体内容有多个RO的现象。此外，家庭网络上的各个设备可以共享家庭媒体服务中心上的受保护媒体内容，采取的方式之一就是媒体服务中心将RO拆分给其他设备使用，例如，将包含某媒体内容的100次使用权限的RO拆分成5个包含20次使用权限的RO，再分配给网络中的5个设备使用。不过这些通过拆分方式分配给各个设备的RO，可能不会全部消费完毕，从而形成“残余”。用户自然会将这些残余的RO转移到家庭媒体服务中心，从而也造成同一个设备上同一份媒体内容存在多个RO的现象。

综上所述，不论是在用户的家庭域范围内，还是在用户的单个设备上，同一份媒体内容存在多个RO的现象，将成为一个不可回避的现实。为方便叙述，姑且将这种现象称为RO同主现象。

RO同主现象或许不会对媒体内容的安全构成威胁，但必将影响用户使用媒体内容过程中的良好体验。首先，RO同主可能引起存储空间的浪费。这不仅仅因为RO本身占用一定的存储空间而形成浪费，更为重要的是，多个RO可能意味着用户需要下载多个DCF文件，这些文件实际上都来源于同一份原始媒体内容，所不同的可能仅仅是加密的密钥不同，因此从本质上说，用户要为同一份媒体内容付出多倍的存储空间，即是一种浪费。其次，RO同主将引起管理成本的浪费。例如：甲有1首歌的100个RO，每一个RO只包含该首歌的1次播放权限，而乙拥有1首歌的1个RO，RO中包含该首歌的100次播放权限，两人获得的享受机会相同，但相比之下乙要轻松很多。再次，RO同主将引起用户的困惑。想象一个场景：甲下载了一幅图片并购买了第一个RO，该RO允许他在显示屏上显示但不能输出到打印机，后来朋友赠送给他第二个RO，该RO允许他通过打印机打印但不能在显示屏上显示。很自然的，甲希望能够像往常打印其他内容一样，边在显示屏上查看边打印，因为他认为自己同时拥有了显示和打印的权限。但遗憾的是，甲通过自己购买的RO打开图片后却发现不允许打印，改用朋友赠送的那个RO后，虽然可以打印，但却没有显示的权限，打印机在打印图片的过程中，在显示屏上看不到图片，因此在图片完整打印出来之前，甲会担心打印出来的内容可能不是自己所想要的。甲在使用过程中没有达到预期的效果，因此，困惑就产生了。

目前业务提供了直接将两个许可信息(License)中的权限信息进行合并的技术方案，虽然采用这种方案能够允许用户将两个License进行合并，但存在以下足：

(1)无法识别两个License是否指向同一个原始媒体内容，因此，合并两个指向不同原始媒体内容的License可能导致侵犯媒体内容版权。因为将价值1美元的媒体内容的License加到价值5美元的媒体内容的License上，是对CI利益的侵害。

(2)在合并License过程中不能合理兼顾用户合并权限的需要与合并所引起的利益平衡问题，即不能有效兼顾版权发布者(RI)和用户的利益。

发明内容

本发明提供一种在数字版权管理系统中合并版权控制信息的方法及系统，以解决现有技术中不能识别不同的版权控制信息是否指向同一个原始媒体内容，而权限合并后可能导致侵犯媒体内容版权的问题；进一步，解决现有技术中在权限合并时不能较好的兼顾版权发布者和用户利益的问题。

本发明提供以下技术方案：

一种在数字版权管理系统中合并版权控制信息的方法，所述版权控制信息用于控制媒体内容的使用权限；该方法包括如下步骤：

根据所述版权控制信息中包含的能够有效识别对应的原始媒体内容的媒体内容标识，获取包含同一媒体内容标识的所有版权控制信息；

将所述所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中，由合并后的版权控制信息控制用户使用所述媒体内容。

其中：

优先将在预进行合并操作的本地保存有对应受保护文件的版权控制信息作为基准版权控制信息，所述受保护文件通过加密原始媒体内容后得到。

在合并版权控制信息中过程，进一步删除所述基准版权控制信息之外其他被合并的版权控制信息，使用户仅持有合并后的版权控制信息。

所述版权控制信息中包含有版权发布者标识；由终端设备根据该标识向对应的版权发布者服务器请求本地合并资格，并且终端设备仅在获得本地合并资格授权后在本地执行合并操作。

若包含同一媒体内容标识的版权控制信息保存在不同的物理终端设备上，则首先将版权控制信息集中到其中一个负责执行合并操作的终端设备上。

若所述包含同一媒体内容标识的所有版权控制信息中部分或全部版权控制信息分别由不同的版权发布者提供，所述终端设备则分别向各版权发布者服务器请求本地合并资格，并且在得到各版权发布者的本地合并资格授权后在本地执行合并操作。

终端设备在合并版权控制信息前进一步根据预设条件判断版权控制信息中的权限合并是否不利于版权发布者；并且，在确定不利于版权发布者时放弃合并操作，或者根据版权控制信息中相关元素属性决定放弃或继续合并操作。

终端设备在合并版权控制信息前进一步根据预设条件判断权限合并是否不利于版权控制信息的持有者；并且，在确定不利于版权控制信息持有者时，提示用户和根据用户的选择决定放弃或继续合并操作，或者根据配置文件决定放弃或继续合并操作。

若终端设备未获得授权资格，则将需要合并的版权控制信息传送到对应的版权发布者服务器，由版权发布者服务器进行合并操作，并将合并后的版权控制信息传送给终端设备。

由终端设备将包含同一媒体内容标识的所有版权控制信息直接传送到所述基准版权控制信息对应的版权发布者服务器，由该版权发布者服务器进行合并操作，并将合并后的版权控制信息传送给终端设备。

若包含同一媒体内容标识的版权控制信息保存在不同的物理终端上，则首先将版权控制信息集中到所述版权发布者服务器。

若所述包含同一媒体内容标识的所有版权控制信息中部分或全部版权控制信息分别由不同的版权发布者提供，所述执行版权控制信息合并的版权发布系统分别向对应的版权发布者服务器请求合并资格，并且在得到各版权发布者的合并资格授权后在本地执行合并操作。

版权发布者服务器在合并版权控制信息前进一步根据预设条件判断版权控制信息中的权限合并是否不利于版权发布者；并且，在确定不利于版权发布者时根据配置文件决定放弃或继续合并操作。

版权发布者服务器在合并版权控制信息前进一步根据预设条件判断权限合并是否不利于版权控制信息的持有者；并且，在确定不利于版权控制信息持有者放弃合并操作。

在合并版权控制信息前通知终端设备删除需要合并的版权控制信息，并在确定终端设备已删除需要合并的版权控制信息后进行合并操作。

所述版权发布者服务器将所有包含同一媒体内容标识的所有版权控制信息合并后产生一个或多个合并后的版权控制信息。

一种生成版权控制信息的方法，所述版权控制信息用于控制媒体内容的使用权限；该方法包括如下步骤：

利用密钥加密媒体内容生成受保护文件，并且所述媒体内容和所述受保护文件中具有能够有效标识该媒体内容的媒体内容标识；

依据所述受保护文件生成至少包含所述媒体内容标识的版权控制信息，使该版权控制信息能够通过所述媒体内容标识关联到所述媒体内容。

其中：利用不同的密钥分别加密所述包含媒体内容标识对应的的媒体内容，生成多个所述文件。

在生成版权控制信息时在该版权控制信息中进一步加入版权发布者标识，使得能够通过版权控制信息中的该版权发布者标识关联到版权发布者服务器。

一种生成版权控制信息的系统，包括：

利用密钥加密原始媒体内容生成受保护文件，并且所述原始媒体内容和所述受保护文件中包含能够有效标识该媒体内容的媒体内容标识的受保护文件生成装置；

依据所述受保护文件生成至少包含所述媒体内容标识的版权控制信息，使该版权控制信息能够通过所述媒体内容标识关联到所述原始媒体内容的版权控制信息生成装置。

一种终端设备，包括：

用于根据版权控制信息中包含的媒体内容标识，获取包含同一媒体内容标识的所有版权控制信息的获取模块；

用于将所述获取单元获取的所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的合并模块。

所述终端设备还包括：用于在合并版权控制信息过程中删除所述基准版权控制信息之外其他被合并的版权控制信息的删除模块。

所述终端设备还包括：用于根据版权控制信息中包含的版权发布者标识，向对应的版权发布者服务器请求本地合并资格，并且仅在获得本地合并资格授权后允许所述合并模块在本地执行合并操作的资格请求模块；

所述终端设备还包括：用于在合并版权控制信息前根据预设条件判断权限合并是否不利于版权控制信息的持有者或/和不利于版权控制信息发布者，并根据判断结果控制所述合并模块放弃或合并版权控制信息的判断模块。

一种版权发布者服务器，包括：

用于接受并存储包含同一媒体内容标识的所有版权控制信息的接受模块；

用于将所述接受模块的所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的合并模块。

所述版权发布者服务器进一步包括：用于在合并版权控制信息过程中通知待合并的版权控制信息的持有者删除其本地待合并的版权控制信息，并且仅在确认所述持有者已删除其本地的版权控制信息后允许所述合并模块进行合并的通知模块。

所述版权发布者服务器进一步包括：用于根据版权控制信息中包含的版权发布者标识，向对应的其他版权发布者服务器请求合并资格，并且仅在获得合并资格授权后允许所述合并模块在本地执行合并操作的资格请求模块。

所述版权发布者服务器进一步包括：用于在合并版权控制信息前根据预设条件判断权限合并是否不利于版权控制信息的持有者或/和不利于版权控制信息发布者，并根据判断结果控制所述合并模块放弃或合并版权控制信息的判断模块。

一种数字版权管理系统，包括：

用于将包含同一媒体内容标识的所有版权控制信息上传送的终端设备；

用于接收上传的版权控制信息和将版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的版权发布者服务器。

本发明有益效果如下：

1、采用本发明，用户能够及时自行消除设备上版权控制信息的同主现象，从而消除其所带来的存储空间的浪费、管理成本的浪费和使用混乱等问题，大大提高用户体验。

2、由于本发明能够对关联相同媒体内容的版权对象进行合并，因而用户在进行版权控制信息赠送时将不用再担心受赠方是否已经拥有相应版权控制信息，这将在一定程度上促进用户之间的赠送行为，从而提高媒体内容的消费量。

3、由于本发明对关联相同媒体内容的版权对象中的权限进行合并，因而能够有效避免权限合并导致的权利冲突；同时，在权限合并中能够有效兼顾终端用户与RI的利益，同时也不失灵活性，可有效促进媒体内容生产和消费的良性循环。

4、本发明中生成的版权对象携带媒体内容标识，进一步携带版权发布者标识，因而能够根据媒体内容标识识别不同版权对象是否同主，根据版权发布者标识能够直接关联到版权发布者服务器，从而方便应用和管理。

附图说明

图1为现有技术模型下原始媒体内容、数字版权管理内容格式(DCF)文件和版权对象(RO)之间的关系示意图；

图2为本发明实施例中生成RO的系统示意图；

图3为本发明实施例中生成RO的流程图；

图4为本发明实施例中原始媒体内容、数字版权管理内容格式(DCF)文件和版权对象(RO)之间的关系示意图；

图5为本发明实施例中合并同主RO的主要流程图；

图6为本发明实施例中判断RO是否为同主RO的流程图；

图7为本发明实施例中终端设备请求本地RO合并资格的流程图；

图8为本发明实施例中由服务器进行RO的合并的流程图；

图9为本发明实施例中RI服务器之间互相认证合并资格的信令流程图；

图10为本发明实施例中终端设备合并一组同主RO的主要流程图；

图11为本发明实施例中在终端设备本地进行RO合并操作的具体流程图；

图12为本发明实施例中在RI服务器上合并一组同主RO的流程图；

图13为本发明实施例中用户拥有的多个终端设备组成一个域的示意图；

图14为本发明实施例中在域服务器上合并RO的流程图；

图15为本发明实施例中终端设备结构示意图；

图16为本发明实施例中的RI服务器结构示意图。

具体实施方式

本实施例中以版权控制信息为版权对象(RO)、受保护文件为数字版权管理内容格式(DCF)文件为例进行说明，但本发明并不限于此。

现有技术模型下原始媒体内容、数字版权管理内容格式(DCF)文件、版权对象(RO)三者之间的关系如图1所示。通常，内容发布者(CI)为了确保其发行的媒体内容的安全，不会只使用一个加密密钥(CEK)加密原始媒体内容并形成一个DCF文件供成千上万的用户下载，而是使用多个CEK为同一原始媒体内容进行加密，形成多个版本的DCF文件供用户下载。CI为每一个DCF文件分配唯一的内容标识(ContentID)并记录在DCF文件头中。RI提供的RO中，保存了对应的DCF文件的ContentID，由此形成RO与DCF文件的关联。而DCF文件中，并没有记录原始媒体内容的任何信息，DCF文件与原始媒体内容没有形成任何关联。

一般而言，只有对同主RO进行合并才有意义。而RO同主的本质在于RO所对应的DCF文件“本质上相同”，即DCF文件来自同一份未加密、未受保护的原始媒体内容。从图1可知，要判断两个RO是否关联到同一个原始媒体内容(即为同主RO)，不能仅根据RO中所包含的ContentID是否相同来判断，事实上，ContentID不同的RO，也有可能是同主RO。如图1中，ContentID为001的RO与ContentID为050的RO，虽然ContentID不同，但却是同主RO。因此，要判断RO是否同主，关键是判断RO对应的DCF文件是否来源于同一个原始媒体内容，但由于现有技术缺乏DCF文件与原始媒体内容之间的关联，因此，按现有技术对REL、DCF的定义，无法自动识别出同主RO，尤其是无法仅凭RO本身来识别。

为了能够识别同主RO，在本发明实施例中为各原始媒体内容增加一个能够有效标识该媒体内容的媒体内容标识，该媒体内容标识最终包含在生成的RO中，通过该媒体内容标识可识别不同的RO是否为同主RO，从而可方便后续的RO合并。

参阅图2所示，内容发行者(CI)服务器用于根据原始的媒体内容生成DCF文件，版权发布者(RI)服务器用于根据DCF文件生成RO。其中，CI服务器和RI服务器可以是相互独立的物理实体，也可以是同一物理实体。

参阅图3所示，生成包含媒体内容标识的版权对象的过程如下：

步骤300、在CI服务器上生成原始媒体内容，该原始媒体内容的路径(含文件名)能够有效标识所述媒体内容的媒体内容标识，即利用路径和文件名来标识一个原始媒体内容(并不限于此，例如也可以采用数据库系统来维护媒体内容标识)。

步骤310、CI服务器利用不同的加密钥密钥CEK分别加密所述原始媒体内容，生成多个包含媒体内容标识的DCF文件。

步骤320、RI服务器根据CI服务器提供的不同的DCF文件中的加密密钥、对媒体内容的使用权限，以及根据DCF文件格式的头中的信息生成RO，该RO中至少包含有媒体内容标识。该RO中进一步包含RI的信息。

由于RO中包含了原始媒体内容的媒体内容标识，因此，根据该RO即可关联到对应的原始媒体内容；进一步的，可从RO直接获知RI的信息。

在DCF文件格式的头中增加描述原始媒体内容的信息的一个实例如下(不限于此)，该实例中修改DCF的Common Headers Box：

aligned(8)class OMADRMCommonHeaders extends FullBox(′ohdr′，version，0){

   unsigned int(8)EncryptionMethod；//Encryption method

   unsigned int(8)PaddingScheme；//Padding type

   unsigned int(64)PlaintextLength；//Plaintext content length in bytes

   unsigned int(16)ContentIDLength；//Length of ContentID field in bytes

   unsigned int(16)RawContentIDLength；//Length of RawContentID field in bytes

   unsigned int(16)RightsIssuerURLLength；//Rights Issuer URL field length in bytes

   unsigned int(16)TextualHeadersLength；//Length of the TextualHeaders array in bytes

   char            ContentID[]；     //Content ID string

   char            RawContentID[]；        //Raw Content ID string

   char           RightsIssuerURL[]；//Rights Issuer URL string

   string         TextualHeaders[]；//Additional headers as Name:Value pairs

   Box            ExtendedHeaders[]；//Extended headers boxes

  }

其中RawContentID为DCF文件对应原始媒体内容的唯一标识。采用这种方式，CI可以通过规范原始媒体内容文件的文件名等方式为每一份原始媒体内容维护唯一标识，无需改变原始媒体内容的文件格式。

通过修改权限表达语言(REL)在RO增加媒体内容标识和RI信息等，增加的信息包括：

A、RO发行者RI的信息；

B、相应DCF文件的发行者CI的信息；

C、相应DCF文件对应的原始媒体内容的信息。

其中，CI的信息和原始媒体内容的信息构成了能够唯一标识原始媒体内容的媒体内容标识(当然并不限于此，如前述的“路径+文件名”方式)。

一个修改REL的具体实施如下(但不限于此)：

(1)修改<rights>元素的定义

原定义：<！ELEMENT o-ex:rights(o-ex:context，o-ex:agreement)>

现定义：<！ELEMENT o-ex:rights(oma-dd:issuer，o-ex:context，o-ex:agreement)>

<！ELEMENT oma-dd:issuer(o-ex:context)>

其中，元素<issuer>包含该RO的发行者RI的标识。

(2)修改<asset>元素的定义

原定义：

<！ELEMENT o-ex:asset(o-ex:context？，0-ex:inherit？，o-ex:digest？，ds:KeyInfo？)>

现定义：

<！ELEMENT o-ex:asset (oma-dd:issuer？，o-ex:context？，oma-dd:raw？，o-ex:inherit？，o-ex:digest？，ds:KeyInfo？)>

<！ELEMENT oma-dd:issuer(o-ex:context)>

<！ELEMENT oma-dd:raw(o-ex:context)>

其中，元素<isser>包含该<asset>对应的DCF文件的发行者CI的标识，而<raw>包含了<asset>对应DCF文件的原始媒体内容的标识。

对于上述的RO，通过读取“rights/issuer/context/uid”信息，即可获知RI的信息。

按上述过程生成RO后，原始媒体内容、DCF文件以及RO三者之间的关系如图4所示。

参阅图5所示，合并同主RO的主要过程如下：

步骤500、用户请求自动合并RO。

步骤510、搜索设备上所有有效的RO，得到RO列表。

步骤520、根据RO中包含的媒体内容标识将RO列表分组，将包含同一媒体内容标识的所有RO分为一组，即同主RO为一组。

步骤530、对每组RO进行合并。即分别将各组同主RO中的其中一个RO作为基准RO，并将该组中其他RO合并到该基准RO中。

参阅图6所示，判断RO是否为同主RO的过程如下：

步骤600、获取两个不同的RO文件。

步骤610、两个RO文件中“rights/agreement/asset”元素个数是否相同，若不同，则进行步骤650，若相同，则进行步骤620。

步骤620、两个RO文件中“asset/issuer”是否分别相同，若不同，则进行步骤650，若相同，则进行步骤630。

步骤630、两个RO文件中“asset/raw”是否分别相同，若不同，则确定该两个RO不是同主RO，若相同，则进行步骤640。

步骤640、确定该两个RO为同主RO。

步骤650、确定该两个RO不是同主RO。

对于同主RO的合并，终端设备中的DRM代理(Agent)与RI服务器之间需要有某些交互，这是因为：一方面，RO的合并牵涉到RI的利益，RO的合并规则需要得到RI的认可，如果要合并的两个RO来自两个RI，则还需要得到两个RI的认可。如果考虑RO的合并规则可能随着业务的发展而灵活变更，执行合并RO操作最好由RI服务器来完成。但另一方面，考虑合并的效率、网络以及RI服务器的压力等因素，RO的合并工作又最好能够由DRMAgent来完成。

为了兼顾RO合并的效率以及RI在RO合并过程中的参与性，同主RO的合并工作既可以由终端设备上的DRM Agent执行(本地合并)，也可以由RI服务器执行(远程合并)。

对于本地合并，在合并之前进一步由RI对DRM Agent进行认证，在RI信任DRMAgent的前提下，DRMAgent可对RI所发行的RO进行合并，否则，DRM Agent提示用户。在RI对DRM Agent不信任的情况下，合并工作可以由RI服务器执行，即终端设备可将RO发送到RI服务器进行合并。

参阅图7所示，终端设备请求本地RO合并资格的过程如下：

步骤700、终端设备上的DRM代理向RI服务器发送RO合并资格请求消息(DRM Agent RO Combination Qualification Request)。

该消息至少包含如下信息：

-设备标识(Device ID)；

-DRM代理标识(DRMAgent ID)；

-RI标识(RI ID)；

-验证标识(Device Nonce，用于保证一个请求和一个响应一一对应)；

-请求时间(Request Time)；

-签名(Signature)。

步骤710、RI服务器接收到所述请求消息后，利用其中的DRM Agent ID获取DRM Agent的相关信息，例如，当前版本、所采用的合并规则等，从而决定是否授予该DRM Agent本地合并的资格。

步骤720、RI服务器向DRM代理发送RO合并资格响应消息(DRMAgentRO Combination Qualification Response)。

该消息至少包含如下信息：

-状态(Status)；

-设备标识(Device ID)；

-DRM代理标识(DRMAgent ID)；

-RI标识(RI ID)；

-验证标识(Device Nonce)；

-签名(Signature)。

DRM Agent接收到该消息后，将对其中的Status进行分析。当Status的值为“Success”(不限于此)的时候，表明获得本地合并的资格，而值为“Failure”(不限于此)的时候表明未获得本地合并的资格，DRM Agent将不能对本地RO进行合并。此时，如果用户愿意，可以通过进行远程RO合并。

DRM Agent向RI请求本地合并资格是一次性的工作，合并多个来自同一RI的RO时，只需要请求一次合并资格。不过，所获得的资格也不是永久的，因为随着业务的发展，RO的结构以及合并规则可能发生变化，DRMAgent可能需要升级后才能够重新获得本地合并RO的资格，可以视需要确定DRMAgent重新获取本地合并RO资格的时间间隔。

远程合并又需要分同RI的RO合并与不同RI的RO合并，前者待合并的RO来自同一个RI，后者待合并的RO来自不同的RI。对于不同RI的RO合并，则存在两个RI之间是否互相信任的问题，因此，需要通过信令进行认证。

参阅图8所示，由服务器进行RO的合并过程如下：

步骤800、终端设备上的DRM代理向RI服务器发送RO合并请求消息(ROCombination Request)。该消息至少包含如下信息：

-设备标识(Device ID)；

-RI标识(RI ID)；

-验证标识(Device Nonce)；

-请求时间(Request Time)；

-受保护的版权对象(Protected ROs)(受保护的、待合并的RO列表，第一个RO为基准RO)；

-签名(Signature)。

步骤810、RI服务器接收到该消息后，根据服务器上的合并规则对RO列表进行分析，例如，列表中包含的RO是否都由本RI发行、是否同主、是否符合同主RO的合并规则要求等，从而判断是否对RO进行合并。

步骤820、RI服务器向DRM代理发送RO合并报告(RO CombinationReport)，以通知DRMAgent，是否对RO进行合并、不合并的理由是什么等。。该消息至少包含如下信息：

-状态(Status)；

-设备标识(Device ID)；

-RI标识(RI ID)；

-版权对象信息(RO Infos)(DRMAgent此前要求合并的RO信息列表)；

-验证标识(Device Nonce)；

-签名(Signature)。

DRM Agent接收到该消息后，将分析其中的Status。如果Status值为失败原因，例如为“ROs serve different media”(不限于此)，则说明RI服务器因RO不同主而无法完成合并，本次信令交互结束(即不再进行步骤820、830)；如果Status值为成功信息，例如为“Success”(不限于此)，说明RI服务器可以成功合并所提交的RO，DRM Agent必须将本地待合并的RO删除(以保持权限数据的平衡或一致性)。(本例以可以完全合并为例)

步骤830、DRM代理向RI服务器发送RO合并确认消息(RO CombinationAcknowledge)，向RI服务器表明本地RO已经删除，该信息至少包含如下信息：

-设备标识(Device ID)；

-RI标识(RI ID)；

-版权信息(RO Infos)(DRM Agent此前要求合并的，已被删除的RO信息列表)；

-验证标识(Device Nonce)；

-签名(Signature)。

步骤840、RI服务器接收到RO合并确认消息后(RO CombinationAcknowledge)消息后，实施合并操作。

步骤850、RI服务器将DRM代理发送RO合并响应消息(RO CombinationResponse)，将合并的结果返回给DRMAgent。该消息至少包含如下信息：

-状态(Status)；

-设备标识(Device ID)；

-RI标识(RI ID)；

-验证标识(Device Nonce)；

-受保护的版权对象(PotectedROs)(受保护的、合并了的RO列表，合并结果可能是多个RO)；

-签名(Signature)。

由于规则的限制，RI可能无法将DRM Agent所提交多个RO合并成一个RO，有时候合并的结果可能是多个。

参阅图9所示，RI服务器之间互相认证合并资格的信令流程如下：

步骤900、执行RO合并的RI服务器A向RI服务器B发送RO合并资格请求消息(RI RO Combination Request)。该消息包括：

步骤910、RI服务器B对RI服务器A进行认证。

步骤920、RI服务器B向RI服务器发送RO合并资格响应消息(RI ROCombination Qualification Response)，表明是否允许合并。

图9的流程与图7中终端设备请求合并资格的信令流程相似，其消息不同之处在于请求消息中包含的不是DRMAgent ID而是RI ID。

同样的道理，RI向他RI请求合并资格是一次性的事情，获得他RI授予的合并资格后，后续的来自该RI的RO的合并将不再需要进行资格认证。同样的，这个资格也不是永久有效，也可视需要调整重新认证的时间间隔。

RO同主是RO进行合并的必要条件，但不是充分条件，有些RO尽管同主，但考虑终端用户或者RI的利益，有可能不适合进行合并。例如，盲目地将两个无限次数播放权限合并为一个无限次数播放权限，其结果将损害终端用户的利益，因为终端用户已经为两个无限次数播放权限付了两次费，合并之后就造成用户成本的沉没，实际上，将这种包含无限次数播放权限的RO向RI提出撤销或者赠送给朋友或许是更划算的事情；这是一方面，但另一方面，如果硬性规定不允许进行这样的合并，又会造成对价值无所谓、一心只希望进行RO合并的用户带来不方便。再如，简单将一个很快就要到期的100次播放权限加到一个到期时间还有1年的1次播放权限，形成一个到期时间还有1年的101次播放权限，可能不是所有的RI都愿意看到的事情，因为既然用了时间限制，RI就希望用户在指定时间内消费完毕，而这种合并方法显然违背了RI的本来意图。同样的，也不能硬性规定不允许这样的合并。

因此，在合并过程中需要兼顾RI和终端用户的利益，同时考虑终端用户的良好体验。

如前所述，RO合并过程中可能产生利益不平衡问题，这包括两种倾向：对RI不利和对用户不利。本实施例中分别就这两种倾向作开放式处理：

	在RI服务器进行合并	在DRM Agent进行合并
			不利于RI的倾向	是否允许该倾向的合并，通过部署在RI服务器上的配置文件决定。	禁止在DRM Agent侧进行有该倾向的合并，除非RO中元素属性表明RI愿意如此。
不利于用户的倾向	禁止在RI服务器上进行有该倾向的合并。	是否允许该倾向的合并，通过人机交互或者部署在终端设备上的配置文件决定。

例如，在DRMAgent上进行如下两个权限合并：

<permission>

   <play/>

</permission>

与

<permission>

     <play>

         <constraint>

              <count>100</count>

         </constraint>

     </play>

</permission>

第一个为无限次播放权限，而第二个为100次播放权限。很显然，将二者进行合并的结果不可能是100次播放权限，因为这对用户而言明显不利。但也不能简单地将合并结果定为无限次播放权限，因为这意味着用户花钱购买的100次播放权限消失了。这种情况下，应该通过人机交互的方式，告诉用户合并的结果将为无限制播放权限，所购限100次播放权限将消失，是否继续？如果用户同意，则合并结果为无限次播放权限，如果用户不同意，则不进行合并。

为了减少合并过程中频繁的人机交互，可以在终端设备上部署一个配置文件，将用户习惯的选择以配置文件的形式固化下来，当合并过程中需要用户做出决定的时候，取而代之的是读取配置文件信息，而不是弹出对话框让用户确认。该配置文件的结构大致如下：

无限次数与无限次数合并，其结果为无限次数，是否愿意？	No
		无限次数与有限次数合并，其结果为无限次数，是否愿意？	Yes

再如，在RI服务器上进行如下两个权限的合并：

<permission>

    <play>

        <constraint>

           <count>100</count>

           <datetime>

               <start>2004-12-31T23:59:59Z</start>

                   <end>2005-12-31T23:59:59Z</end><！--当前时间为2005年12月-->

               </datetime>

          </constraint>

     </play>

</permission>

与

<permission>

     <play>

         <constraint>

           <count>100</count>

             <datetime>

                  <start>2004-12-31T23:59:59Z</start>

                  <end>2006-12-31T23:59:59Z</end><！--当前时间为2005年12月-->

            </datetime>

         </constraint>

     </play>

</permission>

第一个为快要到期的100次播放权限，而第二个为到期时间还有一年的100次播放权限。合并结果为到期时间还有一年的200次播放权限，还是不允许这样的合并，完全视RI的业务需要。因此，RI可以在服务器上部署类似下面的配置文件(并不限于此)：

有时间限制的播放次数进行合并，其结果为播放次数相加，时间限制以到期时间长的为准，是否愿意？	Yes

以上方法既保护了终端用户和RI的利益，也为那些不考虑利益平衡关系而只需要合并功能的用户提供了方便。

参阅图10所示，终端设备合并一组同主RO的主要过程如下：

步骤1000、遍历一组同主RO，将其中一个RO定为基准RO。

在确定基准RO时，优先将DCF文件在本地的RO作为基准RO，以避免下载DCF文件而耗用资源；如果该组所有RO对应的DCF文件都不在本地，则选择其中一个RO为基准RO，如选择RO列表中的第一个RO为基准RO，并下载其对应的DCF文件。

步骤1010、向RO对应的RI请求本地合并资格。

如果该组中的部分或全部RO对应不同的DCF文件，则需要分别向各RI请求本地合并资格。如果此前已向其中的RI申请过并获得本地合并资格，则可以不再重复申请。

步骤1020、判断是否所有RI均授权本地合并资格，若是，则进行步骤1030，否则，进行步骤1040。

步骤1030、由终端设备上的DRM代理对该组中的RO进行本地合并操作，各组RO合并完成后结束RO合并流程。

步骤1040、提示用户是否愿意进行远程合并，若用户选择是，则进行步骤1050，否则，放弃RO合并结束流程。

步骤1050、将该组中的RO发送到基准RO对应的RI，由RI进行远程合并。

参阅图11所示，在终端设备本地合并一组同主RO的具体过程如下：

步骤1100、读取一组同主RO中的基准RO，如列表中的第一个RO。

步骤1110、读取下一个非基准RO。

步骤1120、判断将所述下一个非基准RO合并到基准RO是否有对用户或RI不利的倾向，若是，则进行步骤1130，否则进行步骤1140。

步骤1130、是否允许合并，若是，则进行步骤1140，否则，进行步骤1150。

步骤1140、将所述非基准RO合并到所述基准RO中。

步骤150、判断该组中是否还有未合并的非基准RO，若是，则读取下一个非基准RO，并转步骤1120，否则结该组RO合并。

在上述流程中，当出现某个非基准RO合并到基准RO中不利于用户或RI并且不允许这种合并时，则不将该非基准RO合并到基准RO中，对其他允许合并的RO仍然进行合并。当然，也可以选择放弃合并该组中所有的RO。

参阅图12所示，在RI服务器上合并一组同主RO的具体过程如下：

步骤1200、DRM代理向RI服务器发送RO合并请求消息，消息中RO列表的第一个RO为基准RO，其余为非基准RO。

步骤1205、判断该组中所有RO是否均来自本RI，若是，则进行步骤1220，否则，进行步骤1210。

步骤1210、根据RO中的RI信息，向其他RI服务器发送RI合并资格请求消息。

步骤1215、根据接收到的响应，判断其他RI是否均授权合并RO，若是，则进行步骤1220，否则，进行步骤1255。

步骤1220、判断所有非基准RO与基准RO的合并对RI不利，且配置文件都不允许这样的合并，若是，则进行步骤1225，否则，进行步骤1225。

步骤1225、RI服务器向DRM代理发送RO合并报告消息，表明RO可能成功合并。

步骤1230、DRM代理删除本地待合并的RO。

步骤1235、DRM代理向RI发送RO合并确认消息，通知RI服务器已成功删除待合并的RO。

步骤1240、RI服务器根据配置文件要求，将每一个非基准RO中的权限信息合并到基准RO上。

步骤1245、RI服务器向DRM代理发送RO合并响应消息，将合并结果发送给DRM代理。

步骤1250、DRM代理保存合并后的RO，结束合并流程。

步骤1255、RI服务器向DRM代理发送RO合并报告消息，表明无法合并RO。

步骤1260、DRM代理提示用户无法完成合并RO，并结束合并流程。

以上主要是针对需要合并的RO都在同一个终端设备上的情况。如图13所示，当用户拥有多个终端设备，并且组成了一个域，要合并的RO分散在域中的各个设备上时，RO合并由域服务器上的DRM代理完成。参阅图14所示，其合并的主要处理过程如下：

步骤1400、用户请求自动合并域中的RO。

步骤1410、搜索域内所有设备上的有效的RO，并将这些RO转移到域服务器上，形成RO列表。

步骤1420、根据RO中包含的媒体内容标识将RO列表分组，将包含同一媒体内容标识的所有RO分为一组，即同主RO为一组。

步骤1430、对每组RO进行合并。即分别将各组同主RO中的其中一个RO作为基准RO，并将该组中其他RO合并到该基准RO中。(具体处理过程请参阅图12中RI服务器对一组同主RO的合并过程)

步骤1440、根据需要将合并的RO重新转移到域中的设备上。

相应的，本发明实施例中的终端设备结构如图15所示，终端设备的DRM代理单元除了包括完成现有基本功能的功能模块外，还进一步包括：获取模块150、合并模块151、删除模块152、资格请求模块153和判断模块154，其中：

获取模块150，用于根据版权对象(RO)中包含的媒体内容标识，获取包含同一媒体内容标识的所有版权对象。

合并模块151，与获取模块150具有逻辑上的连接关系，用于将所述获取单元获取的所有版权对象中的一个版权对象作为基准版权对象，并将其他版权对象合并到该基准版权对象中。

删除模块152，与合并模块151具有逻辑逻辑上的连接关系，用于在合并版权对象中过程删除所述基准版权对象之外其他被合并的版权对象。

资格请求模块153，与所述合并模块151具有逻辑上的连接关系，用于根据版权对象中包含的版权发布者标识，向对应的版权发布者服务器请求本地合并资格，并且仅在获得本地合并资格授权后允许所述合并模块在本地执行合并操作。

判断模块154，与所述获取模块150和合并模块151具有逻辑上的连接关系，用于在合并版权对象前根据预设条件判断权限合并是否不利于版权对象的持有者或/和不利于版权对象发布者，并根据判断结果控制所述合并模块151放弃或合并版权对象。

相应的，本发明实施例中的RI服务器的结构如图16所示，RI服务器除了包括完成现有基本功能的功能模块外，还进一步包括：接受模块160、合并模块161、通知模块162、资格请求模块163和判断模块164，其中：

接受模块160，用于接受并存储终端设备发送来的包含同一媒体内容标识的所有版权对象。

合并模块161，与所述接受模块160具有逻辑上的连接关系，用于将所述接受模块的所有版权对象中的一个版权对象作为基准版权对象，并将其他版权对象合并到该基准版权对象中。

通知模块162，与所述合并模块161具有逻辑上的连接关系，用于在合并版权对象中过程删通知待合并的版权对象的持有者删除待合并的版权对象，并且仅在确认持有者已删除版权对象后允许所述合并模块进行合并。

资格请求模块163，与所述合并模块161具有逻辑上的连接关系，用于根据版权对象中包含的版权发布者标识，向对应的其他版权发布者服务器请求合并资格，并且仅在获得合并资格授权后允许所述合并模块在本地执行合并操作。

判断模块164，与所述接受模块160和合并模块161具有逻辑上的连接关系，用于在合并版权对象前根据预设条件判断权限合并是否不利于版权对象的持有者或/和不利于版权对象发布者，并根据判断结果控制所述合并模块放弃或合并版权对象。

虽然上述以数字版权管理中的DCF文件以及用于控制媒体内容使用权限的版权对象(RO)为例进行说明，但本发明的实现并不限于此，如，控制媒体内容使用权限的版权控制信息也可以为二进制的许可文件(License)等。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (34)

1. 一种在数字版权管理系统中合并版权控制信息的方法，所述版权控制信息用于控制用户对媒体内容的使用权限；其特征在于，包括如下步骤：

根据所述版权控制信息中包含的能够有效标识对应的原始媒体内容的媒体内容标识，获取包含同一媒体内容标识的所有版权控制信息；

将所述所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中，由合并后的版权控制信息控制用户使用所述媒体内容。

2. 如权利要求1所述的方法，其特征在于，优先将在预进行合并操作的本地保存有对应受保护文件的版权控制信息作为基准版权控制信息，所述受保护文件通过加密原始媒体内容后得到。

3. 如权利要求1所述的方法，其特征在于，在合并版权控制信息过程中，进一步删除所述基准版权控制信息之外其他被合并的版权控制信息，使用户仅持有合并后的版权控制信息。

4. 如权利要求1所述的方法，其特征在于，所述版权控制信息中包含有版权发布者标识；由终端设备根据该标识向对应的版权发布者服务器请求本地合并资格，并且终端设备仅在获得本地合并资格授权后在本地执行合并操作。

5. 如权利要求4所述的方法，其特征在于，若包含同一媒体内容标识的版权控制信息保存在不同的物理终端设备上，则首先将版权控制信息集中到其中一个负责执行合并操作的终端设备上。

6. 如权利要求4所述的方法，其特征在于，若所述包含同一媒体内容标识的所有版权控制信息中部分或全部版权控制信息分别由不同的版权发布者提供，所述终端设备则分别向各版权发布者服务器请求本地合并资格，并且在得到各版权发布者的本地合并资格授权后在本地执行合并操作。

7. 如权利要求4所述的方法，其特征在于，终端设备在合并版权控制信息前进一步根据预设条件判断版权控制信息中的权限合并是否不利于版权发布者；并且，在确定不利于版权发布者时放弃合并操作，或者根据版权控制信息中相关元素属性决定放弃或继续合并操作。

8. 如权利要求4或7所述的方法，其特征在于，终端设备在合并版权控制信息前进一步根据预设条件判断权限合并是否不利于版权控制信息的持有者；并且，在确定不利于版权控制信息持有者时，提示用户和根据用户的选择决定放弃或继续合并操作，或者根据配置文件决定放弃或继续合并操作。

9. 如权利要求4所述的方法，其特征在于，若终端设备未获得授权资格，则将需要合并的版权控制信息传送到对应的版权发布者服务器，由版权发布者服务器进行合并操作，并将合并后的版权控制信息传送给终端设备。

10. 如权利要求1所述的方法，其特征在于，由终端设备将包含同一媒体内容标识的所有版权控制信息直接传送到所述基准版权控制信息对应的版权发布者服务器，由该版权发布者服务器进行合并操作，并将合并后的版权控制信息传送给终端设备。

11. 如权利要求9或10所述的方法，其特征在于，若包含同一媒体内容标识的版权控制信息保存在不同的物理终端上，则首先将版权控制信息集中到所述版权发布者服务器。

12. 如权利要求9或10所述的方法，其特征在于，若所述包含同一媒体内容标识的所有版权控制信息中部分或全部版权控制信息分别由不同的版权发布者提供，所述执行版权控制信息合并的版权发布系统分别向对应的版权发布者服务器请求合并资格，并且在得到各版权发布者的合并资格授权后在本地执行合并操作。

13. 如权利要求9或10所述的方法，其特征在于，版权发布者服务器在合并版权控制信息前进一步根据预设条件判断版权控制信息中的权限合并是否不利于版权发布者；并且，在确定不利于版权发布者时根据配置文件决定放弃或继续合并操作。

14. 如权利要求9或10所述的方法，其特征在于，版权发布者服务器在合并版权控制信息前进一步根据预设条件判断权限合并是否不利于版权控制信息的持有者；并且，在确定不利于版权控制信息持有者放弃合并操作。

15. 如权利要求9或10所述的方法，其特征在于，在合并版权控制信息前通知终端设备删除需要合并的版权控制信息，并在确定终端设备已删除需要合并的版权控制信息后进行合并操作。

16. 如权利要求9或10所述的方法，其特征在于，所述版权发布者服务器将所有包含同一媒体内容标识的所有版权控制信息合并后产生一个或多个合并后的版权控制信息。

17. 一种生成版权控制信息的方法，所述版权控制信息用于控制媒体内容的使用权限；其特征在于，包括如下步骤：

利用密钥加密媒体内容生成受保护文件，并且所述媒体内容和所述受保护文件中具有能够有效标识该媒体内容的媒体内容标识；

依据所述受保护文件生成至少包含所述媒体内容标识的版权控制信息，使该版权控制信息能够通过所述媒体内容标识关联到所述媒体内容。

18. 如权利要求17所述的方法，其特征在于，利用不同的密钥分别加密所述包含媒体内容标识对应的的媒体内容，生成多个所述文件。

19. 如权利要求17所述的方法，其特征在于，在生成版权控制信息时在该版权控制信息中进一步加入版权发布者标识，使得能够通过版权控制信息中的该版权发布者标识关联到版权发布者服务器。

20. 一种生成版权控制信息的系统，其特征在于，包括：利用密钥加密原始媒体内容生成受保护文件，并且所述原始媒体内容和所述受保护文件中包含能够有效标识该媒体内容的媒体内容标识的受保护文件生成装置；

依据所述受保护文件生成至少包含所述媒体内容标识的版权控制信息，使该版权控制信息能够通过所述媒体内容标识关联到所述原始媒体内容的版权控制信息生成装置。

21. 如权利要求20所述的系统，其特征在于，所述版权控制信息生成装置在生成版权控制信息时在该版权控制信息中进一步加入版权发布者标识。

22. 一种终端设备，其特征在于，包括：

用于根据版权控制信息中包含的媒体内容标识，获取包含同一媒体内容标识的所有版权控制信息的获取模块；

用于将所述获取单元获取的所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的合并模块。

23. 如权利要求22所述的终端设备，其特征在于，还包括：

用于在合并版权控制信息过程中删除所述基准版权控制信息之外其他被合并的版权控制信息的删除模块。

24. 如权利要求22所述的终端设备，其特征在于，还包括：

用于根据版权控制信息中包含的版权发布者标识，向对应的版权发布者服务器请求本地合并资格，并且仅在获得本地合并资格授权后允许所述合并模块在本地执行合并操作的资格请求模块。

25. 如权利要求22、23或24所述的终端设备，其特征在于，还包括：

用于在合并版权控制信息前根据预设条件判断权限合并是否不利于版权控制信息的持有者或/和不利于版权控制信息发布者，并根据判断结果控制所述合并模块放弃或合并版权控制信息的判断模块。

26. 一种版权发布者服务器，其特征在于，包括：

用于接受并存储包含同一媒体内容标识的所有版权控制信息的接受模块；

用于将所述接受模块的所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的合并模块。

27. 如权利要求26所述的版权发布者服务器，其特征在于，该版权发布者服务器进一步包括：

用于在合并版权控制信息过程中通知待合并的版权控制信息的持有者删除其本地待合并的版权控制信息，并且仅在确认所述持有者已删除其本地的版权控制信息后允许所述合并模块进行合并的通知模块。

28. 如权利要求26所述的版权发布者服务器，其特征在于，该版权发布者服务器进一步包括：

用于根据版权控制信息中包含的版权发布者标识，向对应的其他版权发布者服务器请求合并资格，并且仅在获得合并资格授权后允许所述合并模块在本地执行合并操作的资格请求模块。

29. 如权利要求26、27或28所述的版权发布者服务器，其特征在于，该版权发布者服务器进一步包括：

用于在合并版权控制信息前根据预设条件判断权限合并是否不利于版权控制信息的持有者或/和不利于版权控制信息发布者，并根据判断结果控制所述合并模块放弃或合并版权控制信息的判断模块。

30. 一种数字版权管理系统，其特征在于，包括：

用于将包含同一媒体内容标识的所有版权控制信息上传送的终端设备；

用于接收上传的版权控制信息和将版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的版权发布者服务器。

31. 如权利要求30所述的数字版权管理系统，其特征在于，所述版权发布者服务器包括：

用于接受并存储包含同一媒体内容标识的所有版权控制信息的接受模块；

用于将所述接受模块的所有版权控制信息中的一个版权控制信息作为基准版权控制信息，并将其他版权控制信息合并到该基准版权控制信息中的合并模块。

32. 如权利要求31所述的数字版权管理系统，其特征在于，所述版权发布者服务器进一步包括：

用于在合并版权控制信息过程中通知待合并的版权控制信息的持有者删除保存在其本地的待合并的版权控制信息，并且仅在确认持有者已删除保存在其本地的版权控制信息后允许所述合并模块进行合并的通知模块。

33. 如权利要求31所述的的数字版权管理系统，其特征在于，所述版权发布者服务器进一步包括：

用于根据版权控制信息中包含的版权发布者标识，向对应的其他版权发布者服务器请求合并资格，并且仅在获得合并资格授权后允许所述合并模块在本地执行合并操作的资格请求模块。

34. 如权利要求31、32或33所述的数字版权管理系统，其特征在于，所述版权发布者服务器进一步包括：

用于在合并版权控制信息前根据预设条件判断权限合并是否不利于版权控制信息的持有者或/和不利于版权控制信息发布者，并根据判断结果控制所述合并模块放弃或合并版权控制信息的判断模块。

Images