专利名称：Drm保护的内容共享的制作方法
技术领域：
本发明 一般地涉及信息的共享。
背景技术：
多个用户之间的内容共享正在增长。 一个标准OMA DRM v.2 (2004年3月15日)将权限对象的使用描述为可分布到用户的设备。 基于从中央源接收到的权限对象，具有权限对象的用户的设备接着 可以浏览从中央源提供的内容。
然而，该标准并没有解决点对点通信和多方通信中受保护的实 时多媒体共享。
发明内容
提供该发明内容是以便以简化的形式引入概念的选择，这将在 下面在
具体实施方式
部分进一步描述。该发明内容部分不旨在标识 出所要求保护的主题的关键特征或必要特征。
在本发明的第一方面中， 一个或多个权限对象可以在用户的系 统间传送，由此支持受保护内容的点对点传输。权限对象可以在本 地产生或从远端源接收。
在本发明的第二方面中， 一个或多个权限对象可以经由中央服 务器从第一用户的系统传送到其他用户的系统，由此支持使用受保 护实时多媒体进行的多方通信。
在考虑了下面的示例性实施方式的详细描述后，本公开的这些 和其他方面将变得明显。
通过参考考虑了附图的示例性实施方式的下面描述，可以获得本发明的更为全面的了解以及其潜在的优势。
图1示出内容正在从第一用户分布到其他的用户；
图2示出未受保护内容正在从内容提供商发送到第一用户，并
接着发送到各种用户；
图3示出未受保护内容正在从内容提供商发送到各种用户；图4示出根据本发明的多个方面的受保护内容正在从第 一用户
发送到其他用户；
图5示出根据本发明的多个方面受保护内容正在从第一内容提
供商发送到各种用户；
图6示出根据本发明的多个方面的使用SIP建立连接；
图7示出根据本发明的多个方面的用户发送权限对象到另 一个
用户；
图8示出根据本发明的多个方面的用户正在将本地产生的权限对象发送到另一个用户；
图9示出根据本发明的多个方面的用户正在经由中央服务器或媒体控制单元向其他用户发送权限对象；以及
图10示出可以结合本发明的一个或多个方面4吏用的用户设备的示例'l"生例子。
具体实施例方式
可以以各种方式来体现先前所总结的各个方面。下面的描述通过图示示出了其中多个方面可被实现的各种组合和配置。将理解到所述的方面和/或实施方式仅仅是例子，并且可以<吏用其他的方面和/或实施方式，并可以做出结构和功能的修改而没有偏离本公开的范围。
注意到在下面的描述中将论述单元之间的各种连接。注意到，除非特别指出，否则这些连接通常可以是直接的或间接的，并且本说明书不旨在在该方面做出限制。
OMA DRMv2.0引入了域的概念，其可以用于电话会议中内容的交互式共享。OMA DRMv2.0域是一组设备，其具有由权限发布者(其可以是或可以不是内容提供商)所提供的公共域密钥。属于域的设备可以共享由域密钥所保护的域权限对象(RO)。域RO定义关于内容的约束，该内容可以在属于域的设备间共享。因此，域内的设备可以共享域权限对象并且能够消费和共享由域权限对象所控制的任意DCF。 OMADRM域概念是以网络为中心的。这里，斥又限发布者(RI)定义域、管理域密钥、并且控制哪些设备和多少设备包括在域中以及被从域中排除。在获得域绑定(bound)内容(必须是对于实时内容)前，用户可以请求将设备添加到域中，或在接收到域
绑定内容(非实时内容)后，不断地做出这些请求。
OMA DRMv2.0域概念可以用于支持电话会议中的内容共享。这可以如下获得
a. 使用CEK(内容加密密钥)来保护将被共享的内容。CEK连同相关的权限被封装在域权限对象(DRO)中。使用域密钥来保护DRO中的CEK;
b. 由共享媒体的用户(在下面的例子中，用户l)来分发与内容关联的DRO;以及
c. 属于域的其他参与者能够解密流并且遵守内容使用权限。如果他们不属于域，则他们可以发起加入域过程。
下面的描述机制使用OMADRMv2.0域操作冲莫式以及SIP协议来在点对点和多方会议环境中共享受保护内容。
这里使用了下面的缩写OMA-开放移动联盟DRM-数字权限管理RO-权限对象SDP-会话描述协议RTP-实时协议SSRC-同步源CSRC-贡献源MCU-媒体控制单元
图l示出从第一用户分布到其他用户的内容。图l示出用户1 101具有未受保护(非-DRM)的内容。用户1 101经由接入点102连接到网络103。正如本领域技术人员所能理解的，接入点可以是有线或无线接入点。图1也示出附加的用户(用户2-3 104， 106)，也通过接入点105和107进行连接。内容提供商1 108和内容提供商2 111分别经由接入点110和113连接到网络103。图1中示出的一个或多个设备或服务器可以具有一个或多个输入、 一个或多个输出、 一个或多个处理器、以及一个或多个存储设备，正如本领域技术人员所知的能够交换信息和传输这里所述的对象。为了解释的目的，各种最终用户设备被描述为"用户"，因为设备支持最终用户对内容的使用。将理解到设备能够至少接收和处理这里所述的权限对象。
这里，如箭头114和115所示，用户1 101可以向用户2 104和用户3 106发送未受保护的内容。
图2示出未受保护的内容，其从内容提供商发送到第一用户，接着发送到各种用户。这里，内容提供商1 108首先将非DRM内容109发送到用户1 101，如由箭头201所示出，接着第一用户1101随后将非DRM内容转发(箭头202和203 )到用户2 104和用户3 106，如关于图1所示出的。
图3示出从内容提供商发送到各种用户的非保护内容。用户1101将指令301发送到内容提供商1 108，以便将非DRM内容109发送到用户1 101、用户2 104和用户3 106。下面，如箭头302、 303和304所示，将非DRM内容提供给用户1 101、 2 104和3 106。
图4示出根据本发明的多个方面的从第一用户发送到其他用户的受保护内容。用户1 101包括DRM内容。DRM内容可以已由用户1 101来创建或已从远端源接收。这里，用户1 101向用户2 104和用户3 106发送;^又限对象以允许用户2和用户3来浏览DRM内容。
9如果用户1 101没有发送权限对象或用户2 104、用户3 106没有接受该权限对象，则用户可能不能浏览由DRM保护401、 403和405所示出的DRM内容。
图5示出根据本发明的多个方面的从第一内容提供商发送到各种用户的保护内容。内容提供商2 111向用户1 101、用户2 104和用户3 106发送DRM内容112。这里，用于DRM内容的权限对象可以已经由用户1 101发送到其他用户。如果先前用户1 101没有发送权限对象或用户2 104、用户3 106没有接受权限对象，则用户可能无法浏览由DRM保护503和505所示出的DRM内容。
图6示出根据本发明的多个方面的使用SIP建立连接。图6示出使用会话发起协议的常规INVITE/200OK过程，其中各种权限对象能够在用户之间发送。用户1 601向SIP代理1 602发送INVITE,接着代理1 602经由200 OK消息接受INVITE。接着SIP代理1 602向SIP代理2 603发送INVITE (或相关的INVITE ) 。 SIP代理2 603接着经由200 OK消息接受INVITE。下一步，SIP代理2 603向用户2 604发送INVITE (或另 一个相关的INVITE)。用户2 604接着接受INVITE并且发送回200 OK消息。通过该过程，建立内呼叫(in-call)信令路径。可以理解各种组件可以或可以不经由ACK消息来确认200 OK消息的接收，如图6中的虛线所示。
图7示出根据本发明的多个方面的用户向另 一个用户发送权限对象。这里，第三方内容由用户1 702所共享。
用户1 702想将其从第三方内容提供商701所接收的文件与用户2 703共享。内容提供商已经对文件进行了加密以便确保只有属于域的用户才能够使用该文件并且他们尊重使用权限。在这点上，第三方内容提供商701将加密内容发送到用户1 702。接着用户1 702向用户2 703发送加入邀请，其中加入邀请也包括一个或多个片又限对象。
用户1 702开始与用户2 703的邀请/答复。在该媒体行上，用户1 702包括用于DRM保护的内容的权限对象，其对应于作为SIPINVITE—部分(邀请)保护的媒体。
由于RO是XML对象，而XML无法包括在SDP描述中，因此仅仅尝试将RO添加到INVITE消息也是困难的。
下面描述针对该问题的两种方法。首先， 一个可以使用SDPng,其次， 一个可以使用SIP INVITE消息的主体字段。
IETF MMUSIC工作组正在开发下一代SDP协议(称为SDPng )以便克服设计者和实施者在SDP中所面临的限制。SDPng是基于XML协议的，从而包括RO对象也是显而易见的。使用XML来对RO对象进行指定并且元素可以包括在SDPng中。
在会话建立阶段期间，RO对象可以在SIP消息主体中携带。当使用SIP消息主体时，可以接着将包含在该主体中的RO与RO所应用于的媒体行(media line)进行关联。这里，这通过图7中修改的RO示出。这可以通过以下来完成，1)在SDP媒体行中声明属性，该属性声明流被保护；2)以DRM保护应用于的媒体行的某个指示来扩展ROXML元素。例如，这可以通过参考与由客户端所发送的SDP中的媒体行相关联的标签(a=label)属性来完成。
将SIP主体中的RO元素与媒体关联的另 一种方式是创建新的XML元素，其将RO对象和与媒体关联的标签属性封装在SDP中。通过这种方式，不需要修改RO对象。下面将描述使用每个媒体行中的标签实现媒体和RO对象之间的关联。这也可以通过唯一地标识媒体流的SDP "mid"属性来实现。
针对该扩展的RO可以定义新的多目的互联网邮件扩展(mime)类型。为了描述性的目的，该多目的互联网邮件扩展类型可以表示为"应用/DRM-RO+xml"。这可以包括在SIP消息的内容类型才艮头中。
下面给出具有RO属性和新的多目的互联网邮件扩展类型的SIPINVITE消息的例子。INVITE sip:useri@hub1.example.com SIP/2.0Via: SIP/2.0/UDP hub3.example.comFrom: sip: 13034513355@hub3.example.comTo: sip: 13039263142@hub1 .example.comCall-ID: DEN 1231999021712095500999@huM .example.comCSeq: 8348 INVITEContact: <sip:user1 @example.com:>Content-Length: 436
Content-Type: multipart/mixed; boundary=unique-boundary-1M匿-Version: 1.0
—unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646v=0
o-useM 2890844526 2890842807 IN IP4 126.16.64.4
s=DRM seminar
c=IN IP4 MG122.example.com
m=audio 9092 RTP/AVP 97 98
a=label:1
a=rtpmap:97 AMR/8000a=fmtp:97 octet-align=1
a=rtpmap:98 RTP.ENC.AESCWI128/8000
a=fmtp:98 opt-97; ContentlD="content1000221@Conteritlssuer.com";
m-video 5600 RTP/AVP 96 100a=label:2
a=rtpmap:96 H263/90000
a=rtpmap:100 RTP.ENC.AESCM128/90000
a-fmtp:100 opt=99; ContenWD="content6188164@Contentlssuer.com";
—unjque-boundary-1
Content-type: application/DRM-RO+xml<DRM-RO>
<Media label-'T' type="audio" /><Actual DRM Object ></Actual DRM Object></DRM-RO—imique-boundry-1<DRM-RO><Media label="2" type="video" /><Actual DRM Object></Actual DRM Object</DRM-RO>—unique-boundry-1
在上面的例子中，用户1 702发送具有音频和视频媒体的SIPINVITE消息。音频和视频媒体是受DRM保护的。在媒体行2中，声明净荷类型指示发送者可以发送加密的或未加密的数据。媒体流由它们的标签属性来标识。内容类型报头指示这是多部分/混合MIME消息。INVITE消息主体包括对应于音频和S见频力某体的两个
12DRM-RO对象。DRM-RO对象封装RO对象和4某体属性。
当用户2 703接收到该SIP INVITE消息时，它从SDP知道音频和视频媒体流都是受保护的并且SIP主体的主体包括RO对象。如果用户2 703期望进行该呼叫，则其解析SIP消息的主体以便提取针对每个媒体的RO对象。
用户2 703 (回答者)需要在他的回答中接受针对DRM保护内容的邀请(通过接受所提供的净荷类型)。如果其还想与用户1 702共享受DRM保护内容，则其需要包括RO作为其回答的一部分。如果其确定接受了净荷类型但没有指定RO，则用户1 702将向用户2703发送受DRM保护数据，而用户2 703将向用户1 702发送非DRM保护数据。
换句话说，RO本身不具有邀请/回答的暗示。其仅是个声明性属性，表示在发送方向上与RTP流关联的RO。
当用户1 702完成与用户2 703的受DRM保护文件的共享时，用户1 702可能想共享另一个文件。在这点上，用户1 702可能需要更新RO。这也可以通过邀请/回答模型来完成。用户1 702将以新的RO来更新它的邀"i青。
图8示出根据本发明的多个方面的用户将本地生成的权限对象发送到另一个用户。这里，用户1 801与用户2 802共享个人内容。
与先前的使用情况不同的是，用户1 801想共享的内容不是来自于第三方。内容可以是来自用户1 801电话的直播相机浏览或用户1801预先所录制的任何多媒体文件。不像先前的使用情况，可能内容不是由内容提供商来授权而是由用户1801自身来授权，并且目标不是保护第三方权限而是用户1801的内容本身。
可以执行与先前的使用情况相同的机制。不同之处在于用户1801只需要自己创建RO并且可能在内容被发送的同时对其进行加密。
用户1 801依赖于DRM域机制以确保用户2 802被适当地验证并且将遵守RO规则。图9示出根据本发明的多个方面的用户1 901经由中央服务器或媒体控制单元902向其他用户(用户2 902)发送权限对象。这里，多方共享DRM内容。这里，中央服务器或媒体控制单元902可以包括用于从用户设备接收信息的一个或多个输入，向用户设备发送权限对象和受保护内容的 一个或多个输出，以及存储来自于用户设备
的一个或多个权限对象的一个或多个存储器。
在多方会议会话中，多个参与者(用户1 901和用户2 903 )连接到会议服务器或"桥，，或MCU902。每个用户901、 903可以建立起点对点信令(SIP)和媒体会话(RTP)会话。
一个或多个用户可能希望与其他的用户共享某个DRM保护内容。由于内容被保护，所以MCU 902将不修改RTP分组的加密内容，而是将在不同的内容之间进行切换(例如，在不同的视频之间进行切换)。可替换地，MCU902可以尝试混合^见频。然而，混合一见频可能与各种DRM内容规定相沖突。
根据不同的策略，MCU可以在不同的流之间切换。不同的策略例如可以基于端点媒体控制(这意味着每个参与者可以向MCU902发送请求以订制其想从会议服务器接收到的媒体)。可替换地，月艮务器可以选择其想发送到所有参与者(例如，有源扬声器、解调器等)的媒体流。
如在点对点DRM共享使用情况中所描述的，每个用户可以执行与MCU的单独邀请/回答协商。
如在图9中所示，用户901可以针对他想保护的每个々某体发送扩展的权限对象作为邀请/回答的一部分(类似于上面所解释的SIPINVITE消息)。MCU902接下来接受加密媒体但将不指定任何的RO。这意味着从MCU902到用户1 901的200 0K消息中有针对加密媒体的净荷类型，但200 OK消息的主体将不包含任何RO对象。用户可以不将此考虑为一个错误，因为用户知道它正在加入到会议。另外，通过下面将描述的另一个过程，它将了解特定的RO对象。
当MCU902向用户1 901发送回200 OK消息时，MCU 902不包括RO对象，因为MCU902将向用户1 901转发多个其他用户的媒体，这些其他用户具有每个都根据其自己的权限对象而加密的其自己的媒体。相应地，当用户1 901需要访问到其他媒体时，它将及时地接收到权限对象。通过如下所解释的SIP订制/通知机制，可以
解决该通知。
对于SIP,会议中的用户使用SIP的SUBSCRIBE方法来订制到会议状态。使用SIP NOTIFY向参与者通知会议状态改变。
例如，用户1 901已经加入到会议并且将他的媒体权限对象发送到MCU作为邀请/回答的一部分。下一步，用户2 903加入到会议。MCU902向用户2 902通知用户1 901处于会i义中。该通知可以以用户1 901的RO来扩展。这可以通过将ROXML插入到通知的会议信息/多个用户/一个用户/端点/媒体信息中来完成，其在http:〃www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-12.txt中定义。
在IETF草案http:
〃www.ietf.org/internet画drafts/draft國ietf-sipping-conference-package-12.t
xt中，使用XML来通知会议状态。会议状态中的媒体元素指定端点
(或端用户)媒体流特性像媒体类型、SSRC、标签等。下面描述媒体
XML元素可以;故扩展为具有称为DRM-RO的另一个子元素。该元素
指定与媒体关联的RO对象。该子元素是媒体元素中的可选元素，
因此在没有加密的地方，DRM-RO子元素也将不存在。
来自会议数据包草案的媒体元素可以如下表示。<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>534232</src-id>
<status>sendrecv</status>
</media>
可以利用RO对象将该媒体元素扩展为<media id=T>
<display-text>main audio</display-text>
<type>3udio</type>
<label>34567</label>
15<src-id>534232</src-id>
<status>sendrscv</st3tus>
<DRM-RO
(下面示出示例性的域RO)
</DRM-RO> </media>
当会议服务器902发送通知消息时，其可以包括具有相应媒体 的RO对象。当MCU或会议服务器902接收来自每个参与者901、 903的SIP INVITE消息时，其解析SIP主体并且针对使用标签属性 互相关起来的每个相应々某体来提取RO对象。当MCU 902在NOTIFY 消息中发送会议状态时，如上所述，其将针对相应媒体的RO对象 包括在媒体元素中。
剩余的步骤是应用正确的RO来解密来自MCU 902的进入分组。 换句话说，参与者可以首先识别出RTP分组来自于哪个参与者并且 针对该参与者来应用正确的RO。这可以通过使用RTP CSRC字段来 进行。
当MCU 902从用户1 901向用户2 903转发媒体时，它创建具 有MCUSSRC的新RTP分组，但包括用户1 901的SSRC作为CSRC 列表中的仅有CSRC。另外通过来自MCU的通知消息，每个参与者 知道每个媒体发送者的SSRC,即端用户正在发送的每个媒体的 SSRC。因此用户2 903知道用户1 901的每个々某体流的SSRC。因此， 当MCU将用户1 901的视频发送到用户2 903时，它将包括MCU 的SSRC作为SSRC和用户1 901的SSRC作为CSRC。当用户2 903 接收到该RTP分组时，其将CSRC与其通过通知已经创建的SSRC 列表进行相关。基于此，它可以使用正确的RO对象(如果媒体是 加密的)来解密该媒体。
在如点对点的使用情况中，不仅该机制可以用于保护第三方内 容，而且还可以用于保护在用户电话上未受保护的内容或由直播的 照相机/麦克风所捕获的实时内容。
下面提供可以根据本发明的一个或多个方面使用的域权 对象 的域RO例子 <roap:protectedRO
xml^s:[■o3p=''urn:onr>a:bac:dldrm:roap-1.0', xmlns:ds-"http://www.w3.org/2000/D9/xmldsig#" xm Ins :xenc-"http :〃www.w3. org/2001 /04/xmlenc#" xmlns:o-ex="http:〃odrl.net/1.1 /ODRL-EX" xmlns:o-dd="http:〃odrl.net/"1.1/ODRL-DD" xmlns:xsi=''http:〉/www.w3.org/2001/XMLSchema-instance">" <roap:ro id="n8yu98hy0e2109eu09ewf09u" cfomainRO-"true" version="1,0" riLJRL="http:〃www.ROs-r-us.com"> <rilD>
<key I dentifier xsi: type="roap:X509SPKI Hash"> <hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash> </keylderrtifier> </rilD>
<rights o-ex:id="REL1"> <o-ex:context> <o-dd:version>2.0</o-dd:vei"sion> <o-dd:uid>RjghtsObjectlD</o-dd:uid> </o-ex:context> <o-ex:3gresment> <o-ex:ssset> <o-sx:context>
<o-dd:uid>ContentlD</o-dd:uid>
</o-ex:context>
<o-ex:digest>
<ds:DigestMethod Algoritlim="littp://www.w3.org/2000/09/xmldsig#shar/> <ds:DigestValue>bLLLc+Um/5/NvmYKiHDLaErK0fk=</ds:DigestValue>
</o-ex:digest>
<ds:Keylnfo>
<xenc: EncryptedKey>
<xenc:Encryption(Vlethod Algorithm="http://www.w3.or9/2001/04/xmlenc#kw-aes1287>
<ds:Keylnfo>
《ds:RetrievalMethod URI-"#K—MAC—and_K—REK7> </ds:Keylnfo> <xenc:CipherData>
<xenc:CipherValue>EncryptedCEK</xenc:CipherValue:> </xenc:CipherData> </xenc:EncryptedKey> </ds:Keylnfo> </o-ex:asset> <o-ex:permission> <o-dd:play/> </o-sx:permission> </o-ex:3greement> </rights> <signaturs><ds:Signedlnfo>
<ds:CanonicalizationMethod Algorthm="http://www.w3.org/2001/10/xml-exc-c14n#'7>
<ds:SignatureMethod Algorithm-"http:〃www. rsasecurity.com/rsalabs/pkcs/schemas/pkcs-1#rsa-pss-default7>
<cfs: Reference URI-"#RELr> <ds:Transforms>
<ds:Transform Algorithm="http:〃www.w3.org/2001/10/xml-exc-c14n#7> </ds:Transforms>
<ds:DigestMethod Algorithm-"http:〃www.w3,org/2000/09/xmldsig#sha17> <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> </ds:Reference> </ds:Signedlnfo>
<ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=>i/ds:SignatureValue> <ds:Keylnfo> <roap:X509SPKIHash> <hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash> </roap:X509SPKIHash> </ds:Keylrrfo> </signature>
<encKey ld-"K—MAC_and_K—REK"> <xenc:EncrypVionMethod
Algoiithm="Mtp:〃www.w3.org/2001/04/xmlenc#)<w-aes1287:> <ds:Keyinfo>
<roap:domainlD>Domain-XYZ-001</roap:domainlD> </ds:Keylnfo> <xenc:CipherData>
<xenc:CipherValue>32fdsorew9ufdsoi09ufdskrew9urew0uderty5346wq</xenc:CipherValue> </xenc:CipherD3ta> </sncKeiy> </roap:ro> <m3C>
<ds:Signedlnfo>
<ds:CanonicalizationMethod Algorithm="http:〃www.w3.org/2001/10/xml-exc-c14n#7> <ds:SignatureMethod
Algorithm="http:〃www.w3.org/2000/09/xmldsig#hmac-sha17> <ds:Reference URI='"#n8yu98hy0e2109eu09ewf09ii"> <ds:Transforms>
<ds:Transform Algorrthm=http:〃www.w3.org/2001/10/xml-exc-c14n#/> </ds:Transforms>
<ds: DigestMethod Algorithm="http:〃www.w3.org/2000/09/xmldsig#sha17> <ds:DigestValue:>j6lwx3rvEPO0vKtMup4NbeVLi8nk=</ds:DigestValue:> </ds:Reference> </ds:Signedlnfo;>
<ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue;> <ds:Keylnfo>
<ds:RetrievalMethod URN"#K—MAC—and—K—REK'7>
</ds:Keylnfo> </msc>
</roap:protectedRO 通用移动终端
图IO示出用户设备1001的示例性操作环境。用户设备1001可 以包括连接到用户接口 1003的处理器1002,存储器1004和/或其他存储器、以及显示器1005。用户设备1001也可以包括电源1006 (其 可以包括电池或其他电源)，扬声器1007和天线1008 (分开表示但 可以组合)。用户接口 1003可以进一步包括小键盘、触摸屏、语音 接口、 一个或多个箭头键、操纵杆、数据手套、鼠标、滚动球、触 摸屏、显示屏和/或其他人-机接口机构。
由用户设备1001内的处理器1002和其他组件所使用的计算机 可执行指令和数据可以存储在计算机可读存储器1004中。存储器 1004可以以只读存储器模块或随机存取存储器模块的任意组合来实 现，可选地包括易失性和非易失性存储器并且可选地是可拆卸的。 软件1009可以存储在存储器1004和/或其他存储器中以向处理器 1002提供指令，以便使得用户设备1001来执行各种功能。可替换地， 用户设备1001的 一些或所有的计算机可执行指令可以包括在硬件或 固件中(未示出)。
用户设备1001可以配置成基于蓝牙标准，通过特定的蓝牙模块 1010来发送和接收传输。附加地，用户设备1001也可以配置成通过 FM/AM无线电接收器1011、无线局域网(WLAN)收发器1012以 及电信收发器1013来接收、解码和处理传输。在本发明的一个方面 中，用户设备1001可以接收无线电数据流(RDS)消息。用户设备 1001可以配备有附加的和/或不同的接收器/收发器，例如， 一个或多 个数字音频广播(DAB)接收器、世界数字广播(DRM)接收器、 仅前向链路(FLO)接收器、数字多媒体广播(DMB)接收器等。 每个接收器可以物理的或逻辑的，因为硬件可以被组合以提供接收 和解译多种格式和传输标准的单个接收器，如所期望的那样。即，
移动终端设备中的每个接收器可以与移动终端设备中的一个或多个 其他接收器共享部件或子组件，或每个接收器可以是独立的子组件。 本发明的 一 个或多个方面可以使用在软件被-险证和/或被执行的 任何的数据处理设备上，该数据处理设备包括但不限于台式计算机、 膝上型计算机和便携式计算机、个人数字助理、智能电话、个人通 信设备、服务器、路由器等。可以部分地通过使用数字签名来完成软件的认证和/或验证。
尽管以特定于结构的特征和/或方法的动作的语言描述了主题， 但应该理解在所附权利要求书中所定义的主题并不必限于上述的特 定特征或动作。相反，上述的特定特征和动作仅作为实现权利要求 的示例形式而公开。本领域技术人员在阅读了本公开后，在所附权 利要求书的范围和精神内可以做出各种其他实施方式、修改和改变。
权利要求
1.一种用户设备，包括存储器，存储权限对象和受保护内容；输出，其将权限对象发送到另一个用户设备和将受保护内容发送到另一个用户设备。
2. 根据权利要求1所述的用户设备，进一步包括 输入，用于从服务器接收权限对象。
3. 根据权利要求1所述的用户设备，其中所述用户设备产生所述权限对象。
4. 根据权利要求1所述的用户设备，进一步包括 输入，用于从服务器接收受保护内容。
5. 根据权利要求1所述的用户设备，其中所述输出在可扩展标 记语言中发送作为SDPng消息一部分的权限对象。
6. 根据权利要求1所述的用户设备，其中所述输出发送作为SIP 消息体一部分的权限对象，其中所述发送的权限对象是存储在所述 存储器中的权限对象的修改版本。
7. 根据权利要求1所述的用户设备，其中所述输出发送作为SIP invite—部分的权限对象，其中发送的权限对象被封装在所述SIP消 息体中。
8. 根据权利要求1所述的用户设备，进一步包括 从另 一个用户设备接收对权限对象的接受的输入。
9. 根据权利要求1所述的用户设备，进一步包括 更新所述权限对象的处理器，所述输出将所述更新的权限对象发送到所述另一个用户设备。
10. —种用户设备，包括 存储权限对象和受保护内容的存储器；将所述权限对象和受保护内容发送到服务器的输出，该服务器将所述权限对象和所述受保护内容转发到另 一个用户设备。
11. 根据权利要求IO所述的用户设备，进一步包括 生成所述权限对象的处理器。
12. 根据权利要求IO所述的用户设备，进一步包括 生成所述受保护内容的处理器。
13. 根据权利要求IO所述的用户设备，其中所述输出在可扩展 标记语言中发送作为SDPng消息一部分的4又限对象。
14. 根据权利要求IO所述的用户设备，其中所述输出发送作为 SIP消息体一部分的权限对象，其中所述发送的权限对象是存储在所 述存储器中的权限对象的修改版本。
15. 根据权利要求IO所述的用户设备，其中所述输出发送作为 SIP invite —部分的权限对象，其中发送的权限对象被封装在所述SIP 消息体中。
16. 根据权利要求IO所述的用户设备，进一步包括 从另一个用户设备接收对权限对象的接受的输入。
17. 根据权利要求IO所述的用户设备，进一步包括 更新所述权限对象的处理器，所述输出将所述更新的权限对象发送到所述另一个用户设备。
18. —种向另一个用户设备发送受保护内容的方法，包括 从第一用户的第一用户设备发送权限对象到另一个用户的所述另一个用户设备；从所述第 一用户设备发送受保护内容到所述另 一个用户设备。
19. 根据权利要求18所述的方法，进一步包括 从所述另一个用户设备接收对所述权限对象的接受。
20. 根据权利要求18所述的方法，其中发送所述权限对象包括 在可扩展标记语言中发送作为SDPng消息一部分的权限对象。
21. 根据权利要求18所述的方法，所述发送所述权限对象包括 发送作为SIP消息体一部分的权限对象，其中所述发送的权限对象 是存储在所述第一用户设备中的权限对象的修改版本。
22. 根据权利要求18所述的方法，所述发送所述权限对象包括 发送作为SIP invite—部分的权限对象，其中发送的权限对象被封装 在所述SIP消息体中。
23. —种向用户设备提供内容的服务器，包括从第 一用户的第 一用户设备接收权限对象和受保护内容的输入； 存储所述权限对象的存储器；将所述权限对象和所述受保护内容发送到第二用户的第二用户 设备的输出，其中所述权限对象允许所述第二用户设备来浏览所述受保护内容。
24. 根据权利要求23所述的服务器，其中至少在所述第一用户 和所述第二用户之间传送作为会议一部分的所述受保护内容。
25. 根据权利要求23所述的服务器，其中所述输出进一步将所 述权限对象和所述受保护内容发送到所述第三用户的第三用户设 备，同时所述输出将所述受保护内容发送到所述第二用户设备。
26. 根据权利要求23所述的服务器，其中当第三用户加入到所 述服务器时，所述输出进一步将通知发送到所述第 一和第二用户设 备，所述通知包括至少一个新的权限对象。
27. 根据权利要求26所述的服务器，其中所述通知是NOTIFIY 消息，其涉及所述第三用户已订制到的至少所述第一和第二用户之 间的会议。
28. 根据权利要求23所述的服务器，所述输出进一步发送附加 受保护内容，其具有哪个权限对象涉及所述附加受保护内容的指示。
29. 根据权利要求28所述的服务器，哪个权限对象涉及所述附 加受保护内容的指示被包括在实时协议RTP的CSRC字段中。
30. —种方法，包括在第 一用户设备处经由服务器接收来自第二用户设备的第 一权 限对象，以及经由所述服务器接收来自第三用户设备的第二权限对 象；基于所述第一权限对象来接收第一受保护内容； 接收来自所述服务器的、包括通知的第二受保护内容，以便使用所述第二权限对象来访问所述第二受保护内容；以及在所述第一权限对象和所述第二权限对象之间进行切换。
31. 根据权利要求30所述的方法，其中所述通知位于实时协议 RTP的CSRC字段中。
32. 根据权利要求30所述的方法，其中所述接收权限对象是来 自所述服务器的SIP NOTIFY消息的一部分，所述NOTIFY消息响 应于所述第一用户已经订制到由所述服务器处理的所述第二和第三 用户之间的会议。
33. —种用户设备，包括用于1)经由服务器接收来自第二用户设备的第一权限对象，以 及经由所述服务器接收来自第三用户设备的第二权限对象，以及2) 基于所述第 一权限对象来接收第一受保护内容， 以及3 )接收来自所 述服务器的、包括通知的第二受保护内容，以便使用所述第二权限 对象来访问所述第二受保护内容的装置；以及用于在所述第一权限对象和所述第二权限对象之间进行切换的 装置。
34. 根据权利要求33所述的用户设备，其中用于切换的装置使 用所述通知来确定使用哪些权限对象，所述通知包含于实时协议 RTP的CSRC字段中。
35. 根据权利要求33所述的用户设备，进一步包括用于将SIP SUBSCRIBE请求发送到所述服务器，以便加入到由 所述服务器处理的、在第二用户设备和所述第三用户设备之间的会 议的装置，其中所述用于接收的装置提取来自所述服务器的NOTIFY消息 的权限对象，并且来自所述服务器的NOTIFY消息响应于所述 SUBSCRIBE请求。
全文摘要
描述了一种用于将受保护实时内容从一个用户发送到另一个用户的系统和方法。在第一方面中，用户向另一个用户发送权限对象。在第二个方面中，用户经由中间服务器向另一个用户发送权限对象以便进行多方通信。在该第二方面中，用户能够如所需的那样在指定的权限对象之间进行切换。
文档编号H04L29/06GK101601253SQ200780051130
公开日2009年12月9日 申请日期2007年12月12日 优先权日2006年12月28日
发明者D·莱昂, S·维玛, U·钱德拉 申请人:诺基亚公司