CN101321056B - 转发许可的方法、设备及系统 - Google Patents

Abstract

本发明公开了一种转发许可的方法，该方法包括：第一发布设备接收转发许可的请求消息，其中，所述许可为第二发布设备发布的许可；所述第一发布设备确定已经与所述第二发布设备建立联系后，转发所述许可。本发明同时公开一种许可发布设备和通信系统。采用本发明可以实现一个发布设备转发另一发布设备所发布的许可，提高许可转发的灵活性。

Description

转发许可的方法、设备及系统

技术领域

本发明涉及数字版权管理技术领域，尤其涉及转发许可的方法、设备及系统。

背景技术

数字版权管理(Digital Rights Management，DRM)主要通过权利限制和内容保护方案控制数字内容的使用，保护内容所有者的合法权益。数字内容的发行者(Content Issuer，CI)将数字内容加密后，用户将加密的数字内容数据包下载到终端设备上；许可服务器(Rights Issuer，RI)负责分发与数字内容相对应的许可证，其中包括内容加密密钥及对应的权限。设备只有同时拥有内容数据包和许可证，才能正常使用所购买的数字内容。DRM终端(DRM Agent)利用设备的公钥解密得到许可加密密钥，进而得到许可证中的内容加密密钥以解密数字内容，并根据许可证中的权限信息控制用户对数字内容的具体使用。

以开放移动联盟(OMA，Open Mobile Alliance)DRM标准为例，许可证采用权限对象(RO，Rights Object)的方式表示，RO中包含有权利、限制、密钥、签名等信息。

许可证中的权利及限制，统称为许可权限。许可权限或许可权限的载体称为许可。

根据RO所包含的限制的不同，RO可分为有状态RO和无状态RO。有状态RO中包含有对某权利进行限制的信息，例如次数(count)、时间(包括时间段、累计时间等)等状态限制信息；而无状态RO中的所有权利下都不包含状态限制。例如，若RO中包含有打印的权利，及打印次数的限制，则此RO为有状态RO；若RO中包含有打印、浏览等权利，而对RO中的任一权利均无状态限制，则此RO为无状态RO。无状态RO中所包含的权利均属于非消耗类权利，即对该权利的使用不会影响后续的使用。

在OMA SRM(Secure Removal Media，安全可移动媒介)标准中，每个有状态RO对应一个状态信息(Extended State Format，ESF)，以记录其当前消费状态。

在OMA DRM2.0标准中，RO中封装有内容加密密钥CEK、许可加密密钥REK，其中REK用于加密CEK，拥有CEK就可解密已加密的数字内容。

在OMA DRM2.0标准中，设备在安装RO前需要对RO进行安全验证，如对RO进行完整性验证等。RO可分为域RO与设备RO。对于域RO，RI还要将其中的<rights>部分进行数字签名，设备在安装域RO之前需要进一步验证对<rights>的数字签名是否正确。设备对RO进行验证之前必须获取相关的验证密钥，例如，设备获取到RI的公钥后，对RI所做的数字签名进行验证。

在OMA DRM2.1标准中，提供了一个终端通过RI转发该RI发布的许可到另一终端的处理流程，即提出了通过RI转发RO的业务模型，但现有技术中只能由发布RO的RI转移该RO，不能通过其它设备转发该RO。而发明人在实现本发明的过程中发现，在很多场景下需要转发设备转发其他设备发布的RO，现有技术则无法满足这种需求。例如，如图1所示，现有正在制定的OMASCE标准中的系统架构中，包括：DRM请求者DRM Requestor100、许可服务器RI101、域管理器DA/DEA102、DRM代理DRM Agent103、导入设备LRM(Local Rights Manager)104；其中，LRM104用以实现将非OMA DRM系统中的保护内容或许可权限导入到OMA DRM系统中；RI101用于生成许可，包括为LRM代理生成许可；DA/DEA102负责用户域管理，包括接受RI、DRMAgent、LRM加入用户域。另外，LRM同时也是一种RO发布设备。在系统中可以部署多个RI或LRM等RO发布设备，一种可能的情况是，终端需要通过RI将LRM所发布的许可转发给另一终端。

另一方面，在通过转发设备实现RO转发的过程中，如果转发设备不对所转发的RO进行验证，则转发过程很可能会被非法设备利用而成为一种散布RO的途径。而现有技术也不能满足在RO转发过程中对RO进行验证的需求。

发明内容

本发明实施例提供一种转发许可的方法及系统，用以实现一个发布设备转发另一发布设备所发布的许可，提高许可转发的灵活性。

本发明实施例提供一种转发许可的方法，该方法包括步骤：

第一发布设备接收请求转发许可的请求消息，其中，所述许可为第二发布设备发布的许可；所述第一发布设备与所述第二发布设备为开放移动联盟标准中的许可导入设备LRM或者许可服务器RI；所述许可为所述开放移动联盟标准中规定的权限对象RO；

所述第一发布设备确定已经与所述第二发布设备建立联系后，所述第一发布设备向目的设备转发所述许可；所述建立联系指所述第一发布设备支持转发所述第二发布设备发布的许可。

本发明实施例还提供一种许可发布设备，所述许可发布设备为开放移动联盟标准中的导入设备LRM或者许可服务器RI，所述许可发布设备包括：

接收模块，用于接收请求转发许可的请求消息，其中，所述许可为另一发布设备发布的许可；

建立模块，用于与所述另一发布设备建立联系，所述建立联系是指所述第一发布设备支持转发所述第二发布设备发布的许可；所述许可为所述开放移动联盟标准中规定的权限对象RO；

确定模块，用于根据所述请求消息确定本发布设备是否已经与所述另一发布设备建立联系，并且在未建立联系时，控制所述建立模块执行与所述另一发布设备建立联系的操作；

发送模块，用于在确认本发布设备已经与所述另一发布设备建立联系后，向目的设备转发所述许可。

本发明实施例还提供一种通信系统，包括：

第一、二发布设备，用于发布许可和转发许可；所述第一发布设备与所述第二发布设备为开放移动联盟标准中的许可导入设备LRM或者许可服务器RI；所述许可为所述开放移动联盟标准中规定的权限对象RO；

请求转发许可的设备，用于请求第一发布设备转发第二发布设备发布的许可；

其中，所述第一发布设备在确定已经与所述第二发布设备建立联系后，所述第一发布设备向目的设备转发所述许可；所述建立联系指所述第一发布设备支持转发所述第二发布设备发布的许可。

本发明实施例中，第一发布设备接收请求转发许可的请求消息，其中，所述许可为第二发布设备发布的许可；所述第一发布设备确定已经与所述第二发布设备建立联系后，转发所述许可，从而使一个发布设备可以转发其它发布设备所发布的许可，大大提高了许可转发的灵活性。

附图说明

图1为背景技术中OMA SCE标准的系统结构图；

图2为本发明实施例中通信系统的结构示意图；

图3、图4、图5、图6为本发明实施例中第一发布设备的结构示意图；

图7为本发明实施例中转发许可的处理流程图；

图8为本发明实施例中第一发布设备在接收到请求设备发送的请求消息之前，与第二发布设备建立联系并转发请求设备提供的许可的处理流程图；

图9为本发明实施例中由第一发布设备触发第一发布设备与第二发布设备建立联系的处理流程图；

图10为本发明实施例中由请求设备触发第一发布设备与第二发布设备建立联系的处理流程图；

图11为本发明实施例中由请求设备触发第一发布设备与第二发布设备建立联系的一个具体实例的流程图；

图12为本发明实施例中请求设备通过向第一发布设备发送的请求转发许可的请求消息，触发第一发布设备与第二发布设备建立联系的处理流程图；

图13为本发明实施例中请求设备与第一发布设备之间进行交互的处理流程图；

图14为本发明实施例中一个转发许可的具体实例的流程图；

图15为本发明实施例中第一发布设备通过目的设备的归属设备，将许可转发给目的设备的处理流程图。

图16为本发明实施例中验证配对关系证明的流程图。

具体实施方式

本发明实施例中，第一发布设备接收请求转发许可的请求消息，其中，请求转发的许可为第二发布设备发布的许可；第一发布设备确定已经与第二发布设备建立联系(如建立信任关系)后，转发该许可，从而使一个发布设备可以转发其它发布设备所发布的许可，提高许可转发的灵活性。

本发明实施例中一种通信系统的结构如图2所示，包括：第一发布设备200、第二发布设备201、请求转发许可的设备202；第一发布设备200和第二发布设备201，用于发布许可和转发许可；请求转发许可的设备202，用于请求第一发布设备200转发第二发布设备201发布的许可；其中，第一发布设备200在确定已经与第二发布设备201建立联系后，转发该许可。图2中还包括一目的设备203，用于接收第一发布设备200转发的许可。

第一发布设备200和第二发布设备201可以是许可服务器，也可以是导入设备。第一发布设备200和第二发布设备201是不同的发布设备。请求转发许可的设备202和目的设备203可以是终端设备或许可发布设备，例如，请求转发许可的设备202是第二发布设备201，即由第二发布设备201请求第一发布设备200将第二发布设备201发布的许可转发给目的设备203。请求转发许可的设备202和目的设备203可以是不同的设备，也可以是相同的设备(例如，在请求时还未确定目的设备，或者，转发到目的设备的处理失败，此时可能请求转发许可的设备202会请求收回转发的许可)。为便于描述，下面简称请求转发许可的设备为请求设备。

在一个实施例中，第一发布设备200结构如图3所示，包括：接收模块300、建立模块301、确定模块302、发送模块303；接收模块300，用于接收请求设备请求转发许可的请求消息，其中，请求转发的许可为第二发布设备201发布的许可；建立模块301，用于与第二发布设备201建立联系；确定模块302，用于根据接收到的请求转发许可的请求消息，确定本发布设备是否已经与第二发布设备201建立联系，并且在未建立联系时，控制建立模块301执行与第二发布设备201建立联系的操作；发送模块302，用于在本发布设备已经与第二发布设备201建立联系后，转发该许可。

如图4所示，在一个实施例中，图3所示的第一发布设备200还可以包括验证模块304，用于在接收到该许可后，对许可中的数字签名进行验证。

如图5所示，在一个实施例中，图3所示的第一发布设备200还可以包括封装模块305，用于在转发许可前，对许可重新进行封装。

如图6所示，在一个实施例中，图4所示的第一发布设备200还可以包括封装模块305，用于在转发许可前，对许可重新进行封装。

本发明实施例中，一种转发许可的处理流程如图7所示，包括；

步骤700、第一发布设备接收请求设备请求转发许可的请求消息，其中，请求转发的许可为第二发布设备发布的许可。

步骤701、第一发布设备确定是否已经与第二发布设备建立联系。

步骤702、第一发布设备在确定已经与第二发布设备建立联系后，转发请求设备提供的许可。

第一发布设备可以在接收到请求设备发送的请求消息之前，与第二发布设备建立联系，也可以在接收到请求设备发送的请求消息之后，与第二发布设备建立联系。在一个实施例中，第一发布设备在接收到请求设备发送的请求消息之前，与第二发布设备建立联系并转发请求设备提供的许可的处理流程如图8所示，包括：

步骤800、第一发布设备与第二发布设备建立联系，如通过注册协议完成。在二者建立联系之后，第一发布设备支持转发第二发布设备发布的许可；或第一发布设备与第二发布设备相互支持转发对方发布的许可。在二者建立联系之后，第一发布设备和/或第二发布设备可记录对方的设备标识信息、有效期、设备证书、设备公钥其中之一或任意组合。

步骤801、请求设备获取第二发布设备发布的许可。

步骤802、请求设备向第一发布设备发送请求转发许可的请求消息，其中，请求转发的许可为第二发布设备发布的许可。

第一发布设备需要获取许可，以实现将许可转发的目的，为此，请求设备可以通过请求消息将许可、该许可对应的许可加密密钥或内容加密密钥等信息提供给第一发布设备，如在请求消息中携带该许可等信息，若该许可为有状态许可，在请求消息中还携带有该许可的状态信息。当然，请求设备也可以通过其它消息将该许可等信息提供给第一发布设备，例如通过新增一条消息将该许可、许可状态信息、许可加密密钥或内容加密密钥等信息提供给第一发布设备。另外，第一发布设备也可以从所述第二发布设备获得该许可等信息。

步骤803、第一发布设备在接收到请求消息后，对请求消息进行处理，如对请求消息进行验证及解析等。可选的，第一发布设备可以验证请求设备在请求消息或其它消息中提供的许可是否合法或正确，如验证许可中对权限信息<rights>的数字签名；第一发布设备也可以验证许可是否为与第一发布设备已经建立联系的发布设备所发布的许可。当然，第一发布设备也可以对许可的完整性进行验证。

许可中可以携带多次转发的信息，例如，该许可经过多次转发，当前许可中携带有多个转发该许可的发布设备的相关信息，如转发该许可的发布设备加入的数字签名等。第一发布设备在对请求设备发送的请求消息进行验证时，需要对各转发该许可的发布设备的相关信息进行验证，当对其中一个转发该许可的发布设备的相关信息验证失败时，第一发布设备可以拒绝请求设备的转发许可请求。当然，在此情况下，第一发布设备需要与各转发该许可的发布设备分别建立联系。

步骤804、第一发布设备将响应结果反馈给请求设备，在响应消息中携带验证成功或失败的状态信息。若第一发布设备接收到请求消息后，无法完成转发许可到目的设备的处理，例如对请求消息的验证失败，则第一发布设备可以将该许可的相关信息返回给请求设备，例如，通知请求设备获取该许可的相关信息。

步骤805至步骤806、在验证成功时，第一发布设备将请求设备提供的许可转发给目的设备。例如，第一发布对所述许可重新进行封装后转发给目的设备，如将许可中的内容加密密钥CEK及权限信息<rights>提取出来并重新进行封装。当然，对于有状态许可，由于请求设备在向第一发布设备提供该许可时，还提供该许可的状态信息，因此第一发布设备可以根据该许可及其状态信息重新进行封装。又如，第一发布设备也可以直接将该许可(若为有状态许可，还包括许可的状态信息)转发给目的设备。

图8所示流程中，请求设备可以直接获取第二发布设备发布的许可，也可以通过其它发布设备的转发，以获取第二发布设备发布的许可。许可可能会经过多次的转发，第二发布设备既可以是最近一次转发过程中的转发设备，也可以是之前转发过程中的其中一个转发设备，还可以是许可的初始发布设备。

步骤800中，第一发布设备与第二发布设备建立联系时，可以由第一发布设备触发第一发布设备与第二发布设备建立联系，也可以由第二发布设备触发第一发布设备与第二发布设备建立联系，还可以由请求设备触发第一发布设备与第二发布设备建立联系。

在一个实施例中，由第一发布设备触发第一发布设备与第二发布设备建立联系的处理流程如图9所示(由第二发布设备触发第一发布设备与第二发布设备建立联系的处理流程与此类似)，包括：

步骤900、第一发布设备向第二发布设备发送触发第一发布设备与第二发布设备建立联系的触发消息。

步骤901、第二发布设备接收到触发消息后，向第一发布设备请求建立联系，如发送注册请求消息(R2R registration request)，该消息中可以携带双方的设备标识信息，其携带的参数定义的一个实例如表1所示：

表1注册请求消息R2R registration request

参数Parameters	定义Description
		Device0 ID	第一发布设备的标识信息
Device1 ID	第二发布设备的标识信息
		Expired Time	有效期
CertificateChain/PubKey	第二发布设备的证书链或公钥

步骤902、第一发布设备接收到触发消息后，验证其是否接受该注册请求消息，若接受，则后续支持中转第二发布设备所发布的许可。第一发布设备向第二发布设备返回注册响应消息(R2R registration response)，该消息携带的参数定义的一个实例如表2所示：

表2注册响应消息R2R registration response

参数Parameters	定义Description
		status	响应状态信息，成功或拒绝原因
CertificateChain/PubKey	第一发布设备的证书链或其公钥

在一个实施例中，由请求设备触发第一发布设备与第二发布设备建立联系的处理流程如图10所示，包括：

步骤1000、请求设备向第一发布设备发送触发第一发布设备与第二发布设备建立联系的触发消息Registration Initiate request，其中，请求设备可以在触发消息中携带第二发布设备的标识信息，后续第一发布设备可以根据第二发布设备的标识信息，与第二发布设备建立联系(请求设备向第二发布设备发送触发第二发布设备与第一发布设备建立联系的触发消息的处理流程与此类似，此时请求设备在触发消息中携带第一发布设备的标识信息，由第二发布设备根据第一发布设备的标识信息，与第一发布设备建立联系)。触发消息RegistrationInitiate request中的具体参数定义的一个实例如表3所示：

表3触发消息Registration Initiate request

参数Parameters	定义Description
		Device ID	请求设备ID
Device2 ID	第一发布设备的标识信息
		Device3 ID[O]	第二发布设备的标识信息，可选

步骤1001、第一发布设备接收到触发消息后，验证其是否接受该触发消息，若接受，则与第二发布设备建立联系，例如，根据触发消息中包含的第二发布设备的标识信息，与第二发布设备建立联系。若触发消息中包含第二发布设备的标识信息，而第一发布设备将第二发布设备的标识信息与本地记录的当前已建立联系的发布设备的标识信息进行比较，根据比较结果确定已经与第二发布设备建立联系时，可以不再发起建立联系的处理流程。

步骤1002、第一发布设备向请求设备返回响应消息(Registration Initiateresponse)，该消息携带的参数定义的一个实例如表4所示：

表4响应消息Registration Initiate response

参数Parameters	定义Description
		status	响应状态信息；“成功”，或是失败的原因
Device IDs[O]	与第一发布设备建立联系的发布设备的标识信息，可选

若触发消息中未携带有第二发布设备的标识信息，则响应消息中返回与第一发布设备建立联系的一个或多个发布设备的标识信息。

一个具体实例如图11所示(假设由终端设备DRM Agent0，请求导入设备LRM-01与许可服务器RI-01建立联系)：

步骤1100、DRM Agent0向LRM-01发送触发消息Registration Initiaterequest，触发LRM-01与RI-01建立联系，触发消息中参数定义的一个实例如表5所示：

表5触发消息Registration Initiate request

参数Parameters	定义Description
		DRM Agent0	请求设备的标识信息
LRM-01	许可发布设备的标识信息
		RI-01	许可转发设备的标识信息

步骤1101、LRM-01向RI-01请求建立联系，如发送注册请求消息R2RRegistration request，希望与RI-01建立联系。

步骤1102、RI-01向LRM-01返回建立联系的注册响应消息R2R registrationresponse。

步骤1103、LRM-01向DRM Agent0返回响应消息Registration Initiateresponse。若LRM-01接收到RI-01返回的注册响应消息R2R registrationresponse中携带注册失败的状态信息，则LRM-01返回给DRM Agent0的响应消息Registration Initiate response中携带失败状态信息。

请求设备发送给第一发布设备的转发许可的请求消息，也可以触发第一发布设备与第二发布设备建立联系，其处理流程如图12所示，步骤1200至步骤1206的处理与图8及图10中相应步骤的处理类似，其中，在步骤1201中，第一发布设备在接收到请求设备发送的请求转发许可的请求消息后，可以先验证是否已经与第二发布设备建立联系，如将请求消息中携带的第二发布设备的标识信息与本地记录的当前已建立联系的发布设备的标识信息进行比较，根据比较结果验证是否已经与第二发布设备建立联系。若尚未与第二发布设备建立联系，则执行与第二发布设备建立联系的处理流程。

第二发布设备可以在许可中携带第一发布设备的标识信息，如设备ID或设备地址URL，后续请求设备可以根据许可中携带的第一发布设备的标识信息，向第一发布设备发送请求转发许可的请求消息。当然，第二发布设备可以在许可中携带多个与其已建立联系的发布设备的标识信息。

在一个实施例中，请求设备与第一发布设备之间进行交互的处理流程如图13所示，包括；

步骤1300、第一发布设备触发请求设备向其请求转发许可。

步骤1301、请求设备向第一发布设备请求转发第二发布设备发布的许可；其中，请求消息中可以携带请求转发的许可及该许可对应的许可加密密钥等信息，对于有状态许可还携带有该许可的状态信息。请求消息rights transferrequest中参数定义的一个实例如表6所示：

表6请求消息rights transfer request

参数Parameters	定义Description
		Device ID	请求设备的标识信息
Carrier ID	第一发布设备的标识信息
		Target Device ID	转发许可的目的设备的标识信息
RO	转发的许可
		ESF	对于有状态许可，携带该许可的状态信息
REK或CEK	许可加密密钥或内容加密密钥
		ISSUER ID	第二发布设备的标识信息
RO ID	许可标识

其中，REK、CEK、ESF等可以不与许可一起通过该请求消息传递给第一发布设备，可以在第一发布设备完成以许可的数字签名验证后，再由请求设备通过其它消息传送给第一发布设备。若该请求消息中传送REK，则第一发布设备可以根据REK解密出许可中封装的CEK；若该请求消息中传送CEK，则第一发布设备无需解密许可中的CEK密文，而是可以将该请求消息中传送的CEK直接封装入转发给目的设备的许可中。

第一设备可以根据许可中的标识信息，提取出第二发布设备的ID，再根据第二发布设备的公钥验证许可的合法来源。可选的，请求设备在该请求消息中携带第二发布设备的ID，第一发布设备查找第二发布设备的公钥并验证许可的合法来源，从而无需从许可中解析出第二发布设备的ID，提高了处理效率。

若该请求消息的交互通过安全通道完成，则该请求消息中可以直接携带REK或CEK的明文；否则，需要将REK或CEK以加密的形式传与第一发布设备，例如，以第一发布设备的公钥对REK或CEK进行加密，在该请求消息中携带加密后的密文，第一发布设备接收到该请求消息后，以本发布设备的私钥解密出REK或CEK的明文。

一种实施例中，请求设备不在该请求消息中携带许可，后续由第一发布设备根据RO ID从第二发布设备获取该许可。

本发明实施例中，设备的标识信息可以是设备标识、地址、名称等信息。

第一发布设备接收到请求消息后，验证是否接受请求；若接受，则后续可将请求设备提供的许可转发给目的设备；若不接受，则可以丢弃所接收到的许可。

步骤1302、第一发布设备向请求设备返回响应消息rights transfer response，该消息中参数定义的一个实例如表7所示：

表7响应消息rights transfer response

参数Parameters	定义Description
		status	响应状态，成功或失败原因等。

请求设备在收到响应消息，或者，请求设备在向第一发布设备发送请求转发许可的请求消息后，可以删除本地对应的许可、许可的状态信息等信息。

第一发布设备接收到的域许可中可以携带第二发布设备的数字签名，如对权限信息<rights>部分的数字签名；当然，为了验证设备许可，第一发布设备接收到的设备许可中也可以携带第二发布设备的数字签名，例如对设备许可中权限信息<rights>部分的数字签名。

第一发布设备接收到许可后，对许可中的数字签名进行验证。当许可被多个发布设备转发过时，许可中可包含有多个数字签名，若对其中一个数字签名验证失败，则第一发布设备拒绝请求设备的转发许可请求。

第一发布设备在验证成功后，在许可中携带第一发布设备的数字签名。此时，第一发布设备可以舍弃原许可中的数字签名。另一种方法，第一发布设备也可以保留原许可中所有的数字签名并加入第一发布设备的数字签名。当然，第一发布设备也可以仅保留原许可中第二发布设备的数字签名并加入第一发布设备的数字签名，而舍弃其它发布设备的数字签名，相比之下，此种情况比保留原许可中所有的数字签名在处理时更简单易行。第二发布设备既可以是最近一次转发过程中的转发设备，也可以是之前转发过程中的其中一个转发设备，还可以是许可的初始发布设备。

请求设备发送的请求转发许可的请求消息中可以包含转发的目的设备的标识信息，第一发布设备确定已经与第二发布设备建立联系后，可以根据请求消息中包含的目的设备的标识信息，将许可转发给该目的设备。

如图14所示，本发明实施例中，一个转发许可的具体实例如下：

假设：某LRM(标识LRM-01)、RI(标识RI-01)间通过注册协议建立联系并完成相关信息的交互，以相互支持转发对方所发布的RO(RI可中转LRM发布的RO；LRM也可中转RI发布的RO)；设备DRM Agent0通过现有的1-passRights Object Acquisition协议从LRM-01获取一个具有5次播放权利的RO(RO-01)；之后，DRM Agent0消费了RO-01中的两次播放权限，需要通过RI-01将当前剩余的权限转发给DRM Agent1；RI-01将待转发的RO通过现有的2-pass Rights Object Acquisition Protocol转发给目的设备DRM Agent1。

步骤1400、LRM-01向RI-01发送注册请求消息R2R Registration request，该消息中携带的参数定义的一个实例如表8所示：

表8注册请求消息R2R Registration request

步骤1401、RI-01接收到LRM-01发送的请求转发RO的请求消息后，验证后接受其请求，向LRM-01返回注册响应消息R2R Registration response，该消息中携带的参数定义的一个实例如表9所示：

表9注册响应消息R2R Registration response

参数Parameters	定义Description
		success	响应状态信息，“成功”

步骤1402、DRM Agent0从LRM-01获取一个RO(RO-01)并安装，以下是RO-01中的部分描述：

步骤1403、DRMAgent0依据RO中封装的转发设备ID信息向RI-01发送请求消息Rights transfer request，请求RI-01将RO-01权限转移给DRM Agent1；请求消息中携带的参数定义的一个实例如表10所示，DRMAgent0对该请求消息进行数字签名。

表10请求消息Rigbts transfer request

参数Parameters	定义Description
		DRM Agent0	请求设备标识
RI-01	转发设备的标识
		DRM Agent1	转发的接收设备的标识
RO-01	转发的RO
		ESF	RO-01所属的ESF
LRM-01	RO-01发布设备的ID
		REK	许可加密密钥

步骤1404、RI-01接收到请求消息Rights transfer request后，首先验证消息的合法性及完整性，其中包括：验证请求设备ID及本设备ID与消息中参数是否匹配；验证消息的数字签名是否正确。

若消息验证正确，则进一步验证RO的合法性。RI首先验证RO中封装的转发设备标识是否与本设备标识匹配；然后用LRM-01的公钥验证RO中<rights>部分的数字签名是否正确；再依据REK解析出RO中封装的内容密钥CEK。

步骤1405、若消息及RO验证通过，RI-01向DRM Agent0返回请求响应消息Rights transfer response，其中携带“成功”的状态信息。

步骤1406、DRM Agent1向RI-01发送许可请求消息RO request，请求获取RO-01。

步骤1407、RI-01用本设备的私钥对<rights>部分进行数字签名，封装入RO中，并丢弃LRM-01在原RO中的数字签名；对RO重新进行封装(重新计算其MAC值，封装入RO中)；在RO重新封装的过程中，RI-01将当前RO的状态信息封装入RO的权限信息中，从而使转发给目的设备的RO中携带当前允许目的设备可使用的权限。重新封装后的RO中部分描述如下：

步骤1408、RI-01向DRM Agent1返回许可响应消息RO response。若RI-01接受了DRM Agent1的请求，则RO response在返回消息中携带有重新封装的许可。

另一实施例中，第一发布设备确定已经与第二发布设备建立联系后，进一步判断转发的目的设备是否归属于第一发布设备，若是，则直接将许可转发给该目的设备；否则，将许可转发给该目的设备的归属设备，再由该归属设备将许可转发给该目的设备。此时也可以认为第一发布设备相对于该归属设备而言，为转发许可的请求设备。

特别是针对对于一次转发或多次转发的情况，实现时既可以是每一次转发作为独立的操作，也可以是前次转发的完整过程包含后续转发，即前次转发在后续转发完成后结束。例如，设备0请求RI-0转发RO给设备1，RI-0先将RO转移发给RI-1，再通过RI-1将RO最终转发给设备1。即完整的实现过程可以包括多次转发的过程。若各次转发独立完成，则设备0与RI-0完成转发交互，无需关注后续转发。若需包括多次转发的过程，则设备0向RI-0发起转发请求后，待后续转发实现后，本次转发会话结束。

一个具体实例如图15所示：

假设：DRM Agent0请求RI-0将RO转移给设备DRM Agent1；RI-0接收到请求后，根据其设备归属匹配表，查得目的设备的归属设备为RI-1，请求RI-1将该RO转移给DRM Agent1；RI-1在将该RO转移给DRM Agent1后，向RI-0响应；RI-0接收到该响应后，向DRM Agent0返回响应。此时，本转发会话过程结束。

步骤1500、DRM Agent0当前拥有一个RO(RO-1)。

步骤1501、DRM Agent0向RI-0请求将该RO转给设备DRM Agent1。

步骤1502至步骤1503、RI-0收到该请求后，验证请求(包括RO)合法后，提取出转移的权限及内容密钥，重新封装该RO，生成RO-2。

步骤1504、RI-0请求RI-1将RO-2转给设备DRM Agent1；该请求消息的具体参数定义的一个实例如表11所示：

表11请求消息Rights transfer request

参数Parameters	定义Description
		RI-0	请求设备标识
RI-1	转发设备的标识
		DRM Agent1	转发的接收设备标识
RO-2	转发的RO

步骤1505至步骤1506、RI-1收到该请求后，完成相关的验证及重新封装的处理过程。

步骤1507、RI-1将封装后的RO传送给DRM Agent1。

步骤1508、RI-1向RI-0返回响应，通知RI-0已完成转移请求。

步骤1509、RI-0接收到RI-1已完成转移请求的响应后，向DRM Agent0返回一个响应，通知DRM Agent0其已完成转移请求。本次会话结束。

本发明实施例中，第二发布设备与第一发布设备建立联系(如双方的信任关系)后，第二发布设备所发布的许可就可以经由第一发布设备在第一发布设备所能支持发送的任意两个设备之间进行转发。进一步，第一发布设备(如OMA SCE1.0标准中的许可导入设备，逻辑上包括LRM和DEA)为了安全起见，要求许可发送设备和接收设备必须具有第一发布设备指定的配对关系才能进行许可的转发。如图16所示，包括如下步骤：

步骤1600、此步骤与前述步骤800类似，第一发布设备与第二发布设备建立联系，如通过注册协议完成。

步骤1601、请求设备获取第二发布设备发布的许可。

步骤1602、第二发布设备与请求设备进行交互，将请求设备与目的设备进行配对，向请求设备颁发关于请求设备与目的设备具有配对关系的证明，所述证明中包含请求设备标识、目的设备标识以及第二发布设备对该证明的签名。

步骤1603、此步骤与前述步骤802类似，请求设备向第一发布设备发送请求转发许可的请求消息，其中，请求转发的许可为第二发布设备发布的许可。此外，请求设备还将由第二发布设备颁发的自身与目的设备具有配对关系的证明发送给第一发布设备，这可与转发许可的请求消息一起发送，也可以在转发许可的请求消息之前或之后发送。

步骤1604、此步骤与前述步骤803类似，第一发布设备在接收到请求消息后，对请求消息进行处理，除了验证待转发的许可外，第一发布设备还验证由第二发布设备颁发的、由请求设备发送的、关于请求设备与目的设备的配对证明，主要包括：验证第二发布设备对配对关系证明的签名、验证配对关系证明中的请求设备是否为转发请求设备以及验证配对关系证明中的接收设备是否为转发接收设备。如果验证成功，则允许转发，否则不允许转发。

步骤1605至步骤1607、此步骤与前述步骤804至806类似，第一发布设备将响应结果反馈给请求设备，在响应消息中携带验证成功或失败的状态信息。在验证成功时，第一发布设备将请求设备提供的许可转发给目的设备。

上述实施例中，第二发布设备可能进一步限定配对关系证明所涉及的许可，则可在步骤1602所述的配对关系证明中增加许可标识列表，这样在步骤1604中，将进一步包括验证所述待转发的许可的标识是否在配对关系证明中的许可标识列表中存在。

一个配对关系证明的格式的例子可以如下：

配对关系证明

{

请求设备标识

目的设备标识

许可标识列表

}

以及授予配对关系设备(第二发布设备)对上述数据的签名。

相应的，在一个实施例中，对于许可发布设备用于上述实施例的第一发布设备，许可发布设备还可以包括配对关系验证模块，用于接收许可转发请求后，验证许可转发请求设备与目的设备的配对关系证明。对于许可发布设备用于上述实施例的第二发布设备，许可发布设备还可以包括配对关系授予模块，用于向获取许可的设备颁发该获取许可的设备设备与目的设备的配对关系证明。

本领域普通技术人员可以理解上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。

本发明实施例中，第一发布设备接收请求转发许可的请求消息，其中，请求转发的许可为第二发布设备发布的许可；第一发布设备确定已经与第二发布设备建立联系后，转发该许可，从而使一个发布设备可以转发其它发布设备所发布的许可，提高了许可转发的灵活性，可以为用户带来良好的消费体验。进一步的，在转发许可时，引入对许可进行封装和验证的过程，防止了许可的非法转移和扩散，保护了许可使用者及许可发布者的利益。

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

Claims (26)

1.一种转发许可的方法，其特征在于，该方法包括步骤：

第一发布设备接收请求转发许可的请求消息，其中，所述许可为第二发布设备发布的许可；所述第一发布设备与所述第二发布设备为开放移动联盟标准中的许可导入设备LRM或者许可服务器RI；所述许可为所述开放移动联盟标准中规定的权限对象RO；

所述第一发布设备确定已经与所述第二发布设备建立联系后，所述第一发布设备向目的设备转发所述许可；所述建立联系指所述第一发布设备支持转发所述第二发布设备发布的许可。

2.如权利要求1所述的方法，其特征在于，发送所述请求消息的设备通过所述请求消息将所述许可提供给所述第一发布设备；或，所述第一发布设备从所述第二发布设备获取所述许可。

3.如权利要求2所述的方法，其特征在于，所述第一发布设备接收到所述许可后，对所述许可中的数字签名进行验证。

4.如权利要求3所述的方法，其特征在于，所述许可中包含有多个数字签名时，若对其中一个数字签名验证失败，则所述第一发布设备拒绝所述的请求转发许可的请求消息。

5.如权利要求3所述的方法，其特征在于，所述第一发布设备在验证成功后，在转发的许可中携带所述第一发布设备的数字签名。

6.如权利要求5所述的方法，其特征在于，所述第一发布设备保留所述许可中所有的数字签名并加入所述第一发布设备的数字签名；或，所述第一发布设备保留所述许可中所述第二发布设备的数字签名并加入所述第一发布设备的数字签名，舍弃其它发布设备的数字签名；或，所述第一发布设备舍弃所述许可中所有的数字签名并加入所述第一发布设备的数字签名；或，所述第一发布设备保留所述许可的初始发布设备的数字签名并加入所述第一发布设备的数字签名，舍弃其它发布设备的数字签名。

7.如权利要求1或2所述的方法，其特征在于，所述第一发布设备在收到请求消息后，对所述许可重新进行封装后转发。

8.如权利要求7所述的方法，其特征在于，所述许可为有状态许可，发送所述请求消息的设备向所述第一发布设备提供所述许可的状态信息，所述第一发布设备根据所述许可及其状态信息重新进行封装。

9.如权利要求7所述的方法，其特征在于，所述第一发布设备根据发送所述请求消息的设备提供的许可加密密钥、内容加密密钥、许可标识、许可发布设备标识其中之一或任意组合，对所述许可重新进行封装。

10.如权利要求1所述的方法，其特征在于，所述第一发布设备接收到所述请求消息前与所述第二发布设备建立联系，其中，由所述第一发布设备触发所述第一发布设备与所述第二发布设备建立联系；或，由所述第二发布设备触发所述第一发布设备与所述第二发布设备建立联系；或，发送所述请求消息的设备触发所述第一发布设备与所述第二发布设备建立联系。

11.如权利要求1所述的方法，其特征在于，所述许可中携带有所述第一发布设备的标识信息，发送所述请求消息的设备根据所述第一发布设备的标识信息，向所述第一发布设备发送所述请求消息。

12.如权利要求1所述的方法，其特征在于，所述第一发布设备接收到所述请求消息后与所述第二发布设备建立联系，其中，由发送所述请求消息的设备触发所述第一发布设备与所述第二发布设备建立联系。

13.如权利要求10或12所述的方法，其特征在于，发送所述请求消息的设备触发所述第一发布设备与所述第二发布设备建立联系包括：

向所述第一发布设备提供所述第二发布设备的标识信息，所述第一发布设备根据所述第二发布设备的标识信息，与所述第二发布设备建立联系；

或，向所述第二发布设备提供所述第一发布设备的标识信息，所述第二发布设备根据所述第一发布设备的标识信息，与所述第一发布设备建立联系。

14.如权利要求1所述的方法，其特征在于，所述第一发布设备与所述第二发布设备建立联系后，所述第一发布设备或/和所述第二发布设备记录对方的设备标识信息、有效期、设备证书、设备公钥其中之一或任意组合。

15.如权利要求14所述的方法，其特征在于，所述许可中携带有所述第二发布设备的标识信息，所述第一发布设备将所述第二发布设备的标识信息与本地记录的当前已建立联系的发布设备的标识信息进行比较，根据比较结果确定是否已经与所述第二发布设备建立联系。

16.如权利要求1所述的方法，其特征在于，所述请求消息中包含有转发的目的设备的标识信息，所述第一发布设备确定已经与所述第二发布设备建立联系后，根据所述目的设备的标识信息，将所述许可转发给所述目的设备。

17.如权利要求1所述的方法，其特征在于，所述第一发布设备确定已经与所述第二发布设备建立联系后，进一步判断转发的目的设备是否归属于所述第一发布设备，若是，则直接将所述许可转发给所述目的设备；否则，将所述许可转发给所述目的设备的归属设备，再由所述目的设备的归属设备将所述许可转发给所述目的设备。

18.如权利要求1所述的方法，其特征在于，所述第二发布设备与所述第一发布设备为许可服务器或导入设备。

19.如权利要求1所述的方法，其特征在于，发送所述请求消息的设备为所述第二发布设备。

20.如权利要求1所述的方法，其特征在于，所述第一发布设备还收到由第二发布设备颁发的转发请求设备与转发接收设备的配对关系证明；第一发布设备验证所述配对关系证明并在验证通过后转发所述许可。

21.如权利要求20所述的方法，其特征在于，所述验证配对关系证明具体包括：验证第二发布设备对配对关系证明的签名，验证配对关系证明中的请求设备是否为所述转发请求设备，验证配对关系证明中的接收设备是否为所述转发接收设备。

22.如权利要求21所述的方法，其特征在于，所述验证配对关系证明还包括：验证所述许可的标识是否在所述配对关系证明的许可标识列表中存在。

23.一种许可发布设备，其特征在于，所述许可发布设备为开放移动联盟标准中的导入设备LRM或者许可服务器RI，所述许可发布设备包括：

接收模块，用于接收请求转发许可的请求消息，其中，所述许可为另一发布设备发布的许可；

建立模块，用于与所述另一发布设备建立联系，所述建立联系是指所述第一发布设备支持转发所述第二发布设备发布的许可；所述许可为所述开放移动联盟标准中规定的权限对象RO；

确定模块，用于根据所述请求消息确定本发布设备是否已经与所述另一发布设备建立联系，并且在未建立联系时，控制所述建立模块执行与所述另一发布设备建立联系的操作；

发送模块，用于在确认本发布设备已经与所述另一发布设备建立联系后，向目的设备转发所述许可。

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

验证模块，用于在接收到所述许可后，对所述许可中的数字签名进行验证；或/和，

封装模块，用于在转发所述许可前，对所述许可重新进行封装。

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

配对关系验证模块，用于接收所述请求转发许可的请求消息后，验证许可转发请求设备与目的设备的配对关系证明；或/和，

配对关系授予模块，用于向获取许可的设备颁发该获取许可的设备与目的设备的配对关系证明。

26.一种通信系统，其特征在于，包括：

第一、二发布设备，用于发布许可和转发许可；所述第一发布设备与所述第二发布设备为开放移动联盟标准中的许可导入设备LRM或者许可服务器RI；所述许可为所述开放移动联盟标准中规定的权限对象RO；

请求转发许可的设备，用于请求第一发布设备转发第二发布设备发布的许可；

其中，所述第一发布设备在确定已经与所述第二发布设备建立联系后，所述第一发布设备向目的设备转发所述许可；所述建立联系指所述第一发布设备支持转发所述第二发布设备发布的许可。

Images