专利名称：在设备之间实现许可协商的方法和系统的制作方法
技术领域：
本发明涉及数字版权管理领域，特别是涉及在设备之间实现许可协商的方法和系统。
背景技术：
随着终端能力的日益强大，越来越多的人开始自己制作并且和他人共享数字内容。这些数字内容需要版权管理，例如有的人可能希望从观看自己作品的他人那里获得一定的费用或者希望自己的作品只在一段时间内被共享和观看。个人可以授权业务提供商为其发放许可，例如业务提供商维护一个网站，用户个人上传自己的作品，要下载某个内容的用户通过该网站选择并下载合适的许可，这样，通过数字版权管理可保护网络中个人提供的数字内容。
数字版权管理是一项针对数字内容的版权保护技术，从而有效地防止通过网络和计算机非法复制、拷贝、传送数字内容。数字内容的发行者将数字内容加密后上传到网络，用户如果要使用数字内容，必须向权限发行者请求并获得该数字内容的许可，许可中包含相关的密钥，可以用来解密获取数字内容；同时许可中包含对内容的使用权利和使用条件，终端只能在满足使用条件的情况下根据使用权利使用数字内容。
设备和服务器之间通过网站或者协议相互协商许可，例如用户通过网页选择已有的一个许可或者在网页上选择相应的参数，定制一个特殊的许可。
在上述情况下，许可发放的信息和控制权完全在业务提供商掌握中，个人只能依赖于对业务提供商的信任，而无法自己控制许可的发行。随着P2P技术的兴起，个人可以更加方便的共享自己设备上的内容。同样的，个人也需要能够通过设备使自己也能发放许可，从而可以自己控制许可的数量以及类型。
目前，每一个请求许可的设备都需要和发放许可的源设备进行许可协商，随着个人能够通过设备发放许可，造成源设备的负荷压力越来越重，从而影响服务质量，甚至造成源设备崩溃。另外，在协商过程中，如果协商产生分歧则只能重新开始协商过程，造成设备之间交互次数过多，给源设备带来过大的负荷压力。
发明内容
本发明提供一种在设备之间实现许可协商的方法和系统，以解决现有技术中请求许可过多导致源设备负荷压力过大而影响服务质量的问题。
进一步解决协商过程中产生分歧时存在设备之间交互次数过多而导致源设备负荷压力过大的问题。
本发明方提供以下技术方案，一种在设备之间实现许可协商的方法，包括下述步骤需要获得许可的请求设备从用于发放许可的源设备获得正式许可后保存协商信息，并登记为许可协商的代理设备；后续的请求设备从已登记的代理设备中选择一个代理设备进行许可协商，并在协商成功后将协商结果通知所述源设备；所述源设备依据所述协商结果向请求设备发放许可。
根据上述方法获得正式许可的请求设备在与所述源设备相互独立的服务设备上登记为代理设备，后续的请求设备从该服务设备上选择代理设备进行许可协商；或者获得正式许可的请求设备在所述源设备上登记为代理设备，后续的请求设备从该源设备上选择代理设备进行许可协商。
在协商成功后进一步将协商的候选许可通知源设备，源设备确定该候选许可符合要求后向请求设备发放正式许可。
所述候选许可由请求设备提供，并且在协商过程中被代理设备所述接受；或者，所述候选许可由代理设备提供，并且在协商过程中被请求设备接受。
源设备确定所述候选许可不符合要求时，进一步向请求设备发送本源设备提供的候选许可，指示其重新协商。
在许可中携带许可的类型信息，设备在协商过程中依据该类型信息确定许可为正式许可或为候选许可。
一种许可管理系统，包括源设备，用于与其他设备进行许可协商，并负责发放许可；服务设备，用于将获得正式许可的设备登记为代理源设备进行许可协商的代理设备；代理设备，用于代替所述源设备完成许可协商，并且该代理设备已从所述源设备获得正式许可；请求设备，用于从所述服务设备选择代理设备进行许可协商，并在协商成功后从所述源设备获得许可。
所述源设备与服务服务相互独立设置；或者，所述源设备与服务设备设置为一体。
本发明有益效果如下通过本发明把向服务器进行登记设备作为代理设备，使其他请求获得许可的设备不用与发放许可的设备进行协商，通过代理设备就能进行许可协商，这样就减少了请求获得许可的设备与发放许可设备的交互次数，减轻了发放许可的设备的压力。在协商时如果发生分歧，通过在候选许可列表中修改许可的内容，使请求方和接收方之间不必重新定义一套元数据表达方法和许可生成规则，简化了协商步骤。
图1为本发明实施例中设备之间实现许可协商系统的组网示意图；图2为本发明实施例中许可协商基本流程图；图3A、图3B、图3C为本发明实施例中请求获得许可的设备和发放许可的设备进行协商流程图；
图4A、图4B、图4C为本发明实施例中请求获得许可的设备通过代理设备进行协商流程图；图5为本发明实施例中发放许可的设备处理许可请求流程图；图6为本发明实施例中请求获得许可的设备处理候选许可流程图；图7为本发明实施例中请求获得许可的设备处理正式许可流程图；图8为本发明实施例中设备之间实现许可协商流程图。
具体实施例方式
针对目前在数字版权管理中，请求获得许可的请求设备与发放许可的源设备的交互次数过于频繁，造成发放许可的源设备负担过重等问题，本发明在请求设备从源设备获得正式许可后登记为代理设备，其他后续需要获得许可的请求设备选择这些代理设备进行许可协商，并且在协商成功后由源设备发放正式许可。所述许可协商是指对许可所包含的权利和限制的协商，比如内容可以播放多少次，每次付费数额等。当接收方不同意对方的许可，可以在许可中添加协商的信息。
参见图1所示，本实施例中的许可管理系统包括源设备、服务器、代理设备和请求设备。源设备用于与请求设备进行许可协商，以及向协商成功的请求发放许可；服务器用于将获得正式许可的设备登记为代理源设备进行许可协商的代理设备；代理设备用于代替源设备完成许可协商；请求设备从所述服务器的代理设备列表中选择代理设备进行许可协商，协商成功后从发放许可的设备得到正式许可，从而使用对应的数字内容。所述服务器可以是一个或多个独立的网络实体，也可以由源设备承担登记代理设备的功能。代理设备列表中至少包括有各设备的地址，还可包括其他相关信息；所述列表中的代理设备可以包括源设备。
参阅图2所示，本实施例中请求设备从源设备获得正式许可并作为代理设备进行许可协商的主要流程如下步骤200、需要获得许可的请求设备A与源设备进行许可协商。
步骤210、协商成功后，源设备向请求设备A发放正式许可，请求设备A保存与源设备进行许可协商时的信息。
步骤220、请求设备A向服务器登记，由服务器将请求设备A记录到代理设备的地址列表中(以下称设备A)。
步骤230、请求设备B向服务器请求代理设备的地址列表。
步骤240、服务器向请求设备B返回地址列表。
步骤250、设备B选择从地址列表中选择设备A，设备A根据与源设备进行协商时的信息与设备B进行许可协商。
步骤260、许可协商成功后，源设备向设备B发放正式许可。
在初始状态下，除了源设备具有正式许可外，其他设备还未获得正式许可，此时请求设备只能通过与源设备进行许可协商以获得正式许可，图3A显示了需要获得许可证的请求设备A与源设备进行协商的过程步骤300、请求设备A向源设备发送请求许可消息，该许可请求消息中包含请求设备生成的候选许可。
如果请求设备A不能生成候选许可或不提供候选许可，则候选许可的内容为空。
步骤301、源设备收到请求消息后，根据协商策略判断不接受候选许可，并根据协商策略生成一个或多个候选许可，加入到候选许可列表中。
如果请求消息中的候选许可内容为空，则将默认的一个或多个候选许可加入到候选许可列表中，发送给请求获得许可的设备。
步骤302、请求设备A不接受源设备提供的候选许可，则根据协商策略修改候选许可内容并生成一个新的候选许可发送给源设备，重复协商过程。
步骤310、请求设备A与源设备进行多次交互后，再次向源设备发送请求许可消息。
步骤311、源设备根据协商策略接收了请求设备A的候选许可，向请求设备A发放一个正式许可。
步骤312、请求设备A检查正式许可和接受的候选许可一致，安装许可并向源设备发送确认消息。如果确认不一致，则丢弃许可，进行重新协商或中断协商过程。当然，请求设备A也可以不向源设备发送确认消息。
在步骤320至323，则给出了请求设备A接受源终端提供的一个候选许可后，通知源设备接受该许可，源设备生成正式许可返回给请求设备A；请求设备A检查正式许可和接受的候选许可一致，安装许可并向源设备发送确认消息。如果确认不一致，则丢弃许可，进行重新协商或中断协商过程。
在重复协商过程中，双方可以根据许可的类型对候选许可列表中的内容进行修改，每一次重复过程都可以进行修改。但双方也有可能无限期的进行协商，为了防止这种情况的发生，协商双方可以在协商策略中各自规定最大的协商次数，如果超过了所设定的次数，则向对方发送协商失败的消息，终止本次协商。协商的一方还可以向另一方发送不可修改的候选许可，接收方只能选择接受或拒绝该许可，如果拒绝，则通知对方结束本次协商。
参阅图3B所示，请求设备与源设备进行多次协商后，当请求设备再次向源设备发送请求许可消息后，源设备判断协商次数大于规定的次数，决定停止协商，向请求设备发送协商失败消息。
参阅图3C所示，请求设备与源设备进行多次协商后，当源设备向请求设备发送不可修改的候选后，请求设备不接受候选许可，向源设备发送协商失败消息，决定停止协商。
参阅图4A所示，请求设备与代理设备进行许可协商，并由代理设备将协商结果通知源设备的主要处理过程如下步骤410、请求设备从服务器选择代理设备进行许可协商。
步骤411、代理设备接受请求设备提供的候选许可，协商成功，并将协商结果通知源设备。
步骤412、源设备检查代理设备接受的候选许可符合要求，向请求设备返回一个正式许可。该许可由源设备直接发给请求设备，采用此方式时，在步骤411中代理设备将请求设备的地址通知源设备；或者，由源设备发送给代理设备，由代理设备转发给请求设备。
在该步骤中，如果确定不符合要求，则根据协商策略向请求设备发送新的候选许可列表，重新开始协商或者向请求设备发送协商失败的消息，结束本次协商。重新协商过程请求设备可以和源设备直接进行交互，也可以通过代理设备间接进行交互。
步骤413、请求设备检查正式许可和接受的候选许可一致，安装正式许可并返回确认消息，结束协商过程。确认消息可以直接发送给源设备，也可以通过代理设备转发给源设备。当然，也可不向源设备发送确认消息。
如果不一致，则抛弃正式许可，并向源设备请求一个新的许可或者发送协商失败的消息，结束本次协商。该协商失败的消息可以直接发送给源设备，也可以通过代理设备转发给源设备。当然，也可以不向源设备发送协商失败的消息。
参阅图4B所示，请求设备与代理设备进行许可协商，并由请求设备将协商结果通知源设备的主要处理过程如下步骤450、请求终端从服务器选择代理设备进行许可协商。
步骤451、代理设备接受请求终端提供的候选许可，向请求设备发送接受许可消息。
步骤452、请求设备将协商结果通知源设备。
步骤453、源设备检查协商过程中接受的候选许可符合要求，向请求设备返回一个正式许可。
如果不符合要求，则根据协商策略向请求设备发送新的候选许可列表，重新开始协商或者向请求设备发送协商失败的消息，结束本次协商。重新协商过程请求设备可以和源设备直接进行交互，也可以通过代理设备间接进行交互。
步骤454、请求设备检查正式许可和接受的候选许可一致，安装正式许可并返回确认消息，结束协商过程。当然，也可不向源设备发送确认消息。
如果不一致，则抛弃正式许可，并向源设备请求一个新的许可或者发送协商失败的消息，结束本次协商。
图4A和图4B中，均由代理设备接受候选许可，在图4C的步骤470到步骤473，给出了由请求设备接受候选许可并直接将协商结果通知源设备的处理过程，在请求设备直接将协商结果通知源设备的同时，也可向代理设备发送结束协商的消息，当然，也可不发送该消息。其余流程和上述同理，不再赘述。
在图4C流程中请求设备接受候选许可后也可通知代理设备，由代理设备将协商结果通知源设备，采用此方式的其余流程都和图4A同理，不再赘述。
本实施例在许可协商过程中，通过在许可中增加类型信息来表示协商过程以及提示接收方可以对候选许可列表内容做怎样的修改。许可的类型分为正式、非正式可修改、非正式不可修改和已接受四种。如下表所示
任何设备在消费数字内容时都只能使用类型为“正式”的许可，这种类型的许可包含了解密数字内容的密钥，而其他类型的许可中不包含密钥信息，这样就保证终端无法利用协商过程中的候选许可消费数字内容，并且也能够减少协商时不必要的数据量。对于没有类型元素的许可，一般默认为“正式”许可。
类型为“非正式可修改”的许可用来使接收方对候选许可进行修改。比如在协商过程中发送方发送候选许可且该许可的类型为“非正式可修改”，如果接收方不同意这个许可，则接收方能够对该许可进行修改，再向对方返回修改后的许可。
类型为“非正式不可修改”的许可用来帮助协商的一方终止协商过程。比如源设备可以在协商策略中规定一次协商过程最大的交互次数，当达到最大值时，该设备向请求设备发送一个类型为“非正式不可修改”的候选许可。请求设备只能选择接受该许可完成本次协商或者拒绝该许可从而终止本次协商。
类型为“已接受”的许可用来帮助请求终端通知源终端或者代理终端接受上次发放的某个候选许可，其许可ID应该和该候选许可的许可ID相同。
一个许可类型的表示方法的实例如下(但并不限于此)<许可>
<许可ID>12345678</许可ID>
<类型>非正式可修改</类型>
<内容>吉祥三宝.mp3</内容>
<权利>
播放<限制>
<次数>10</次数>
<费用>1元</费用>
</限制>
</权利>
<数字签名>oweiurq98qhajgh</数字签名>
</许可>
该候选许可规定了花费一元能够播放10次吉祥三宝这首MP3，并且许可类型是非正式可修改，如果接收方不同意这个候选许可，则能够对候选许可的内容进行修改，比如播放次数和费用。
类似的，发送方可以在每个权利或者限制元素下增加类型子元素或属性，用来表示该权利或限制能否修改、增加或删除。比如
<许可>
<许可ID>12345678</许可ID>
<类型>非正式可修改</类型>
<内容>吉祥三宝.mp3</内容>
<权利>
播放<限制 类型可增加/不可删除>
<次数类型不可修改>10</次数>
<费用>1元</费用>
</限制>
</权利>
<数字签名>oweiurq98qhajgh</数字签名>
</许可>
该候选许可的接收方可以增加新的限制，并且可以就费用进行协商，但是不能修改次数限制。不同元素下的类型有不同的语义以及不同的默认值，子元素的类型只有在许可类型为“非正式可修改”时才起作用，在协商过程中，对其他类型的许可不起作用。
参阅图5所示，在许可协商过程中源设备侧的主要处理过程如下步骤500、源设备收到其他终端发送的许可请求消息。
步骤501、源设备对请求消息进行解析，判断该消息中是否包含候选许可，如果包含则执行步骤502；否则执行步骤511。
步骤502、源设备通过解析许可中的类型元素判断该值是否是“已接受”如果是“接受”则说明请求设备接受了该候选许可，执行步骤503；否则，执行步骤509。
步骤503、源设备查找与发来的候选许可ID相同的保存的候选许可。但在某些情况下，找不到对应的候选许可。比如保存的候选许可缓冲区满了，对应的候选许可被删除或者发送来的候选许可是由代理设备和请求设备协商生成的，在源设备并没有对应的候选许可。
步骤504、源设备判断是否找到对应的候选许可。如果找到，则执行步骤505；否则执行步骤508。
步骤505、源设备比较两个对应的许可是否相同。比较时，忽略许可中为了协商而添加的附加信息。比如类型元素或属性。如果两个许可相同，则执行步骤506；否则执行步骤507，说明失败的原因是由于接受的许可和保存的候选许可不相同。
步骤506、源设备生成一个正式许可，将该许可发送给请求设备。
步骤507、源设备向请求设备发送协商失败消息，并在消息中表明失败的原因。
步骤508、源设备重新判断是否接受该候选许可。为了防止不必要的协商，这里的候选许可默认为“非正式不可修改”的类型。如果源设备接受该许可，则执行步骤506；否则执行步骤507，说明失败的原因是由于源终端不接受协商的结果。
步骤509、源设备判断是否接受该候选许可。如果接受，则执行步骤506；否则执行步骤510。
步骤510、源设备通过候选许可中的类型元素判断该候选许可能否被修改。如果候选许可类型值为“非正式可修改”，则执行步骤511；如果候选许可类型值为“非正式不可修改”，则执行步骤507，说明失败的原因是由于源终端不接受该候选许可。
步骤511、源设备根据候选许可中的协商信息和协商策略，生成候选许可列表。其中包含一个或多个候选许可。
步骤512、源设备将候选许可列表发送给请求设备。
参阅图6所示，在许可协商过程中，请求侧设备的主要处理过程如下步骤600、请求设备收到源设备或者代理设备发送的候选许可列表。
步骤601、请求设备取出候选列表中第一个侯选许可。
步骤602、请求设备根据协商策略判断是否接受该候选许可。如果接受，则执行步骤603；如果不接受则执行步骤604。
步骤603、请求设备将候选许可的类型改为“已接受”，对许可进行数字签名，并把签名保存到许可中，然后将修改后的许可发送给源设备或代理设备。
步骤604、请求设备判断候选许可列表中是否有没处理过的许可。如果有，则执行步骤605；否则执行步骤606。
步骤605、请求设备取出下一个没有处理过的候选许可，并执行步骤602。
步骤606、请求设备判断发送方提供的候选许可能否修改。如果其类型值为“非正式不可修改”，则执行步骤607；如果其类型值为“非正式可修改”，则执行步骤608。
步骤607、请求设备向对方发送协商失败消息。
步骤608、请求设备根据协商策略以及可修改的候选许可，重新生成新的候选许可。
步骤609、请求终端将新的候选许可发送给对方。
参阅图7所示，请求终端侧对正式许可的主要处理过程如下步骤700、请求终端收到来自源设备的一个协商响应信息，该信息包括一个正式许可，即类型为“正式”或者不包含类型元素的许可。
步骤701、请求设备取出保存的上次协商时用到的候选许可。
步骤702、请求设备比较保存的候选许可与正式许可是否相同。比较时，设备忽略许可中为了协商而添加的附加信息，比如类型元素或属性。如果两个许可相同，则执行步骤703；否则执行步骤704。
步骤703、请求设备在本地安装正式许可，在需要时使用该许可消费对应的数字内容。设备可以向源设备发送协商成功的消息，以便源设备可以进行后续的处理，此消息并非必要，可根据具体情况选择是否发送。
步骤704、请求设备丢弃正式许可。设备可向源设备发送协商失败消息结束许可协商(此消息并非必要，可根据具体情况选择是否发送)。设备也可自动开始新一轮的许可协商过程。
为了便于本领域一般技术人员理解和实现本发明，一个具体实例如图8所示，其处理流程如下步骤800、设备A向源设备发送请求许可信息。
步骤801、源设备发送候选许可列表给设备A，其中该列表包括一个或多个候选许可。
步骤802、设备A接受候选列表中的一个候选许可，并将该许可发给源设备。
步骤803、源设备发放正式许可，设备A安装该许可，随后可以用该许可消费对应的内容。
步骤804、设备A保存了源设备发放的候选许可列表，并向服务器登记自己的地址，服务器记录设备A为一个可用的代理设备。该实施例中的服务器是由源设备承担的。
步骤805、设备B向服务器(源设备)发送请求代理设备地址列表。
步骤806、服务器将代理设备地址的列表发送给设备B。
步骤807、设备B根据响应最快策略选择了设备A为自己的代理设备，并向该设备发送请求许可。该实施例中如果源设备是响应最快的设备，则设备B可以和源设备直接进行协商。
步骤808、设备A把保存的候选许可列表发送给设备B。
步骤809、设备B不接受列表中的任何一个候选许可，并根据协商策略和许可类型修改了候选许可的内容，把生成的一个候选许可列表发送给设备A。生成的候选许可列表包含一个或多个候选许可。
步骤810、设备A接受了新的候选许可，将该许可发送给源设备。
步骤811、源设备接受该许可，并向设备B发放正式许可，设备B安装该许可，随后可以用该许可消费对应的内容。
上述内容中设备B和源设备进行完许可协商后也可以向服务器登记成为代理终端。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
权利要求
1.一种在设备之间实现许可协商的方法，其特征在于，包括下列步骤需要获得许可的请求设备从用于发放许可的源设备获得正式许可后保存协商信息，并登记为许可协商的代理设备；后续的请求设备从已登记的代理设备中选择一个代理设备进行许可协商，并在协商成功后将协商结果通知所述源设备；所述源设备依据所述协商结果向请求设备发放许可。
2.如权利要求1所述的方法，其特征在于，获得正式许可的请求设备在与所述源设备相互独立的服务设备上登记为代理设备，后续的请求设备从该服务设备上选择代理设备进行许可协商；或者获得正式许可的请求设备在所述源设备上登记为代理设备，后续的请求设备从该源设备上选择代理设备进行许可协商。
3.如权利要求2所述的方法，其特征在于，已登记的代理设备中包含所述源设备。
4.如权利要求2所述的方法，其特征在于，请求设备根据本地的选择策略从已登记的代理设备中选择一个代理设备。
5.如权利要求1所述的方法，其特征在于，在协商成功后进一步将协商的候选许可通知源设备，源设备确定该候选许可符合要求后向请求设备发放正式许可。
6.如权利要求5所述的方法，其特征在于，所述候选许可由请求设备提供，并且在协商过程中被代理设备接受；或者所述候选许可由代理设备提供，并且在协商过程中被请求设备接受。
7.如权利要求5所述的方法，其特征在于，请求设备接收到正式许可后，进一步确定其与接受的候选许可是否一致，若是，则安装该许可，否则丢弃该正式许可。
8.如权利要求7所述的方法，其特征在于，请求设备丢弃所述正式许可后，进一步向源设备请求一个新的许可。
9.如权利要求5所述的方法，其特征在于，源设备确定所述候选许可不符合要求时，进一步向请求设备发送本源设备提供的候选许可，指示其重新协商；或者源设备通知请求设备协商失败，结束此次协商。
10.如权利要求1所述的方法，其特征在于，在协商成功后由代理设备将协商结果通知源设备；或者由请求设备将协商结果通知源设备。
11.如权利要求10所述的方法，其特征在于，源设备通过所述代理设备向请求设备发放许可；或者，源设备直接向请求设备发放许可。
12.如权利要求1至11任一项所述的方法，其特征在于，在许可中携带许可的类型信息，设备在协商过程中依据该类型信息确定许可为正式许可或为候选许可。
13.如权利要求12所述的方法，其特征在于，所述该类型包括正式许可、候选可修改许可、候选不可修改许可和候选接受许可。
14.如权利要求13所述的方法，其特征在于，对于候选可修改许可，在许可中的权利或限制元素中携带用于表明该权利或限制是否能够改变的属性信息。
15.一种许可管理系统，其特征在于，包括源设备，用于与其他设备进行许可协商，并负责发放许可；服务设备，用于将获得正式许可的设备登记为代理源设备进行许可协商的代理设备；代理设备，用于代替所述源设备完成许可协商，并且该代理设备已从所述源设备获得正式许可；请求设备，用于从所述服务设备选择代理设备进行许可协商，并在协商成功后从所述源设备获得许可。
16.如权利要求15所述的许可管理系统，其特征在于，所述源设备与服务设备相互独立设置；或者，所述源设备与服务设备设置为一体。
全文摘要
本发明公开了一种在设备之间实现许可协商的方法，用以解决现有技术中请求许可过多导致源设备负荷压力过大而影响服务质量的问题；该方法需要获得许可的请求设备从用于发放许可的源设备获得正式许可后保存协商信息，并登记为许可协商的代理设备；后续的请求设备从已登记的代理设备中选择一个代理设备进行许可协商，并在协商成功后将协商结果通知所述源设备；所述源设备依据所述协商结果向请求设备发放许可。本发明同时公开了一种许可管理系统。
文档编号H04L29/06GK101090389SQ200610083958
公开日2007年12月19日 申请日期2006年6月16日 优先权日2006年6月16日
发明者周皓隽, 冯雯洁 申请人:华为技术有限公司