CN102474518B - 用于会话转移的策略转移方法及装置 - Google Patents

Abstract

用于转移与从一个终端节点到另一终端节点的单播会话相关联的策略的系统和方法利用网络中的IPTV控制器获得在节目转移完成时允许在节点之间转移观看策略的解密密钥。

Description

用于会话转移的策略转移方法及装置

技术领域

本说明书涉及在从一个节点到另一个节点转移会话时与会话相关联的策略的转移。 

背景技术

在当前领域中，诸如开放式IPTV功能(OITF)终端等用户终端能够从内容源接收传送。多播会话经常用于某些类型的内容，特别是内容点播(Content-On-Demand，COD)会话。将COD会话单播允许内容供应商执行与内容相关联的策略。此类策略能够涉及诸如哪个或哪些终端被授权播放内容、播出要求等因素及本领域技术人员将理解的其它此类因素。在单播会话中，内容供应商一般使用与接收方独特关联的解密密钥将内容流加密。这允许内容供应商确保接收方不能简单地转发或复制接收的流。要将会话解密，用户的终端获得将内容单播的数字权限，一般为能够用于将内容解密的解密密钥的形式。密钥一般绑定到它们发放到的终端。相应地，即使终端绑定到用户，但如果解密密钥绑定到第一终端，则由于它将在第二终端不起作用，因此，用户一般在终端之间转移会话也受阻。因此，通过寻求防止未授权的复制或转发，内容供应商防止用户能够以合法方式将内容转移到另一节点。

本领域技术人员将领会到，术语会话转移和会话复制经常用于指有关但不同的过程。为了清晰的缘故，下面概述了这些术语之间的差别。会话转移允许用户将正在进行的会话(如单播内容点播会话)从当前正在在其流传送内容的装置(其将称为原始装置)转移到用户能够在其中继续观看内容流的另一装置(称为目标装置)。在会话成功 转移后，终止原始会话。会话复制允许用户复制正在由原始装置接收的正在进行的会话(如单播内容点播会话)。接收复制的会话的节点是目标装置。用户能够在原始或目标装置恢复观看内容。在成功复制后，原始会话继续被维护。在复制操作后，原始装置和目标装置与内容提供商之间具有完全独立的会话。

启动会话转移或会话复制能够由原始节点或目标节点执行。如果过程由原始节点启动，则在会话和随附内容被推送到目标节点时，使用术语“推转移(push transfer)”。相反，在过程由目标节点启动时，在会话和随附内容由目标节点从原始节点拉动时，使用术语“拉转移(pull transfer)”。本领域技术人员将领会到，术语装置或术语目标和原始节点一般指诸如开放式IP TV功能(OITF)终端等机顶盒，但为了本公开的目的，这些术语应理解为包括能够接收和显示会话及随附内容的任何物理实体。这包括结合OITF或某个移动装置的装置，所述移动装置具有到诸如基于IMS的受管理网络等相同数据分组网络的访问权。

用于会话的转移或复制的机制是多个其它专利和申请的主题。然而，迄今未解决的一个问题是在转移或复制会话时诸如数字权限管理(DRM)有关策略和与播出有关的策略等策略被转移的方式。要理解与这些策略的转移相关联的问题，重要的是先理解DRM系统在IPTV部署中如何发挥作用。在启动内容点播会话时，内容提供商可认为对会话中提供的内容加密并应用其它策略到内容是必需的。加密防止了接收方或OITF的用户将会话内容重新传送到未授权的用户。内容使用特定于OITF的密钥来加密。一般使用阻止密钥转移的标准技术将密钥绑定到OITF。相应地，在第一OITF寻求转移会话时，即使该转移根据内容提供商安排的策略来进行，OITF特定的加密也防止会话被轻松地转移或复制。本领域技术人员将领会，转移会话而未转移将内容解密的能力是没有什么价值的。

IPTV节点之间的会话转移已在多个现有技术参考文献中讨论过。作为本领域无意于穷举的抽样，欧洲专利申请EP 2 007 101引用了会 话转移，且甚至专门讨论了IPTV会话转移。然而，未提供有关将如何完成DRM权限的转移的信息。在没有用于转移终端特定DRM权限到目标终端的机制的情况下，如上所述，能够转移会话是没有什么价值的。

类似地，美国专利申请公布No.2003/3022990讨论了会话转移。然而，没有讨论如何转移DRM权限到第二OITF。此参考文献讨论转移状态信息，这能够设想到包括DRM密钥或其它策略，但它将原样从第一OITF转移到第二OITF。如更早所述，发放到第一OITF的OITF特定密钥的转移将对第二OITF毫无用处(考虑到密钥绑定到特定OITF装置并且只能够在预期装置上使用)。

因此，最好是在转移会话时具有用于在节点之间转移策略的简单、有效的机制，以使得能够回放合法转移到节点的策略受保护的内容。

发明内容

本发明的目的是消除或减轻现有技术的至少一个缺点。

在结合附图查看本发明特定实施例的以下描述后，本领域的技术人员将明白本发明的其它方面和特征。

附图说明

现在将通过仅示例的方式，参照附图描述本发明的实施例，其中：

图1示出显示基于拉(pull)的策略转移的消息流程图国；

图2示出显示基于推(push)的策略转移的消息流程图国；

图3示出显示根据本发明的一实施例的示范转移的消息流程图；

图4是示出由本发明的IPTV控制服务器所执行的方法的流程图；

图5是示出图4所示方法的一示范实施例的流程图；以及

图6是示出本发明的系统的逻辑图的一示范实施例的框图。

具体实施方式

本发明涉及在转移与内容相关联的会话时诸如数字权限管理策略 等策略从一个终端节点到另一终端节点的转移。这使得诸如播出策略或装置特定加密密钥等策略能够从一个OITF成功转移到另一OITF。

下面可参照可根据附图编号的特定要素。下面的讨论应视为在性质上是示范的，并且不应视为本发明的范围的限制。本发明的范围在权利要求中定义，并且不应视为受下面所述的实现细节限制，这如本领域技术人员将领会到的，能够通过将要素替代为等效功能要素而被修改。

在本发明中，提供了用于会话转移的机制，其允许转移策略，包括转移与会话相关联的DRM权限。本领域技术人员将领会到，虽然以下讨论专门涉及会话转移，但相同的方法和系统能够应用到会话复制的有关过程。

下面的讨论公开了管理策略转移的方法，其中，IPTV控制器接收会话转移已启动的指示，此时，该控制器请求与会话相关联的内容的许可并接收令牌。此令牌被插入目的地为转移接收方(目标装置)的消息中，从而允许转移接收方获得要求的解密密钥。该消息优选包括与会话相关联的策略。操作以执行此类方法的IPTV控制器将包括：DRM接口，通过该接口，能够在检测到转移请求时获得令牌；用于识别转移请求并将接收的令牌插入目的地为转移接收方的消息中的处理器；以及OITF接口，通过该接口接收转移的指示、转移请求及与会话有关的策略，并且通过该接口传送经修改以包括获得的DRM令牌的策略。

在下面的讨论中，使用了多个术语，并且理解这些术语的含意有助于理解本发明。启动OITF是用于请求转移的用户终端。始发OITF是已经正在接收要转移的会话中的内容的终端，而目标OITF是将接收转移的会话的终端。本领域技术人员将领会到，视采用推或拉转移而定，始发OITF或目标OITF能够是启动OITF。

在启动会话转移时，启动OITF向目标OITF发出转移请求。此消息通过对两个OITF负责的IPTV控制服务器来路由，从而允许IPTV 控制服务器请求和获得用于转移接收方的适当DRM权限或许可。发送到转移接收方的消息的至少一个能够在IPTV CS保留，直至获得DRM权限。这些权限随后能够嵌入保留的消息中并随后被发送。注意，用于将这些权限独立发送到转移接收方的其它方式而不保留任何消息是可能的。在接收这些权限时，接收方OITF随后能够设置转移的会话并将内容解码而毫无问题。下面描述执行上述过程的示范方法。

图1示出基于拉的策略和会话转移的示范消息流程。在此类转移中，用户从内容要转移到的节点(目标节点)调用会话(和策略)转移。在图1所示方法中，用户通过从OITF2(目标节点)启动转移来启动拉转移。如图所示，与此讨论相关的节点包括OITF1 100和OITF2 102，两者均是开放式IPTV终端功能单元。在当前所示实施例中，它们均在相同IMS网关(IG)104后的网络段上。本领域技术人员将领会，如IPTV有关标准中定义的诸如IG 104等IG服务于多个目的，但为了以下讨论的缘故，它也表示在用户的控制下的网络与作为整体的IPTV网络之间的分界点。资源和接纳控制子系统(RAC)106及认证和会话管理服务器(ASM)108用于确保用户具有对各种内容、网络资源的访问权限，以及具有对网络中不同服务器的访问权，本领域技术人员将很好地理解其操作。IPTV控制服务器110是网络中的中央节点，其与OITF和内容源均创建信令会话，从而允许它有效地“引导业务”和参与会话的建立、修改和拆除。内容输送网络控制器/簇控制器(CDNC/CC)112作为IMS网络与从其服务内容的网络之间的网关。CDNC/CC 112执行负载平衡和其它此类必需的功能以便内容提供商能够服务于期望数量的连接。相应地，CDNC/CC 112确定在用户创建会话时将使用的内容输送功能(CDF)116节点。在当前优选实施例中，CDF 116由CDNC/CC 112从池中选择，并且如果可能，在会话暂停并随后恢复时或在会话转移时被维护。这有助于确保在新会话中维护任何用户特定的内容信息(例如，内容流中的位置)。在一些情况下， 在转移后，可要求新CDF(例如，OITF2和原始CDF不支持相同的编码格式)，CDF 116与CDNC/CC 112之间的链路被拆除，并且到新CDF的链路被建立。这能够以对用户透明的方式来执行。

如图1所示，用户正在接收与在OITF1 100的内容点播会话相关联的内容。在会话118中，内容正从CDF 116接收。在用户确定在OITF1接收的会话应转移时，用户从目标节点OITF2 102启动转移。在步骤120中，用户使用OITF2 102注册到网络上，并且请求用户帐户参与的所有活动会话的列表。对此请求的响应为用户提供当前与用户帐户相关联的所有内容流的列表。用户随后选择正在输送到OITF1 100的内容流。如在步骤122中所示，为了启动转移，OITF2 102向IG 104发出转移或复制正在进行的会话的请求。在步骤124中，在确定转移的请求涉及相同网络段上的两个节点(例如，在同一房子中)时，IG 104与IPTV控制服务器110通信，并且将媒体流置于保持，从而允许它在新会话在建立时释放与原始会话相关联的资源(在会话转移的情况下)并避免网络资源的双重预订。在会话复制的情况下，可以不严格要求暂停媒体流。在此点，IPTV CS 110已得知会话转移将可能被启动。如在步骤126中所示的，IPTV CS 110能够选择性地为会话加书签，以便用户能够轻松地返回到请求会话转移所在的媒体流中的点。

在步骤128中，OITF2 102请求OITF1 100转移与正在转移的会话相关联并且由OITF 100存储的策略。这些策略能够包括播出策略、指示会话是否能够被复制及在能够复制时能够复制的次数的复制策略、确定会话是否能够被记录以及在记录它时它能够在何处、何时和如何回放的副本保护策略及本领域技术人员将明白的其它类似约束。虽然OITF1 100和OITF2 102存在于相同网络段上，但请求穿过IPTV CS 110。由于请求穿过IPTV CS 110，因此，响应将沿相同路径并且也穿过IPTV CS 110。在IPTV CS 110将包含策略(例如，回放策略)的回复传送到OITF2 102前，请求130被发出到DRM服务器114以 获得用于OITF2 102的许可。在响应中，DRM服务器114向IPTV CS 110发出将允许OITF2 102获得有效解密密钥的令牌。在130中接收的令牌优选插入在步骤128中从OITF1 100接收的策略中。如果OITF1 100在令牌可用前用策略作出响应，则IPTV CS 110能够引入延迟并且将缓冲消息。在步骤133中，作为130的结果而接收的令牌随后由OITF2 102用于获取与会话相关联的DRM密钥。随后，在步骤134中，OITF2 102与CDNC/CC 112建立转移的会话，并且在必需时在步骤136中原始会话能够被拆除。来自CDF 116的内容流随后在OITF2 102终止，并且以OITF2 102将能够使用接收的密钥将其解密的此类方式进行加密。本领域技术人员将领会，在简化的方法中，令牌能够在与其它策略不同的消息中传送到目标节点。

本领域技术人员将领会，将OITF2 102发出的会话策略转移到OITF1 100的请求能够使用诸如基于SIP的OPTION消息等建立的控制协议进行格式化。此OPTION消息将指示OITF1 100获得与正在转移的会话相关联的策略。此消息通过IPTV控制服务器110传送到OITF1 100。在检测到OPTION消息时，IPTV CS 110能够如上所述启动到DRM服务器114的许可请求。对OPTION消息的响应一般是OITF1 100发出的SIP 200 OK()消息，并且通过IPTV CS 110来中继。如上所述，此SIP 200 OK()消息被拦截并修改为包括步骤130中由DRM服务器114发出的令牌。上述SIP OPTION消息的使用是示范性的。本领域技术人员将领会，其它SIP消息能够用于实现上述目的而不脱离本发明。

上述方法允许用户从目标节点(在此情况下为OITF2 102)调用会话转移，并且借助于通过IPTV CS 110路由转移有关的请求，目标节点为IPTV CS 110提供从DRM服务器114获得令牌的能力，而令牌将允许目标节点获得解密密钥的集合。随后，在从始发节点接收响应时，将此令牌提供到目标节点。本领域技术人员将领会，如果始发节点不能转移会话，或者由于其它原因受阻(如由于策略阻止会话转 移或由于用户阻止恶意请求)，则目标终端不能获得将允许它从DRM服务器114获得解密密钥的令牌。因此，启用了某种安全性程度以防止恶意转移请求，并且也允许实行诸如禁止转移权限的策略。

图2示出本发明的方法的另一示范实施例。在此示范实施例中，用户将利用OITF1 100(始发和启动)以使用推机制将会话转移到OITF2 102(目标节点)。图1所示相同网络节点再次在图2中使用。本领域技术人员也将领会，虽然执行了许多相同的步骤，但一些步骤将以与图1所示顺序稍微不同的顺序执行。在步骤138中，用户正在OITF1 100上观看视频点播会话。在观看此会话的同时，用户决定会话应转移到OITF2 102。在步骤140中，该用户请求为该用户注册的所有OITF和其它装置的列表。在步骤144中，OITF1 100向OITF2 102发出启动会话转移的请求。此请求通过IPTV CS 110来路由。在此步骤期间，IG 104也得知会话将被转移或复制。与会话相关联的某些策略必须被遵守，如要求强制播出的约束。在IPTV CS 110接收会话转移正在被启动的指示时，它从DRM服务器114请求在步骤130中发出用于新装置的许可。在此示例中，转移的指示可以是从OITF1 100推送到OITF2 102的策略的接收。此外，在此步骤中，IPTV CS 110从DRM服务器114接收令牌。在OITF1 100向OITF2 102发出转移会话的请求时，如144中所示的，它能够采用SIP REFER消息的形式。而在前一示例中，OITF2 102向OITF1 100发出请求，并且由于在响应中IPTV CS 110是在信令路径中嵌入令牌，因此，在当前示例中，OITF1 100能够在单个消息中将包括与会话相关联的策略的所有会话转移信息传送到OITF2 102。结果，IPTV CS 110能够保留REFER消息，直至它能够在步骤130中获得DRM令牌。在步骤130中接收DRM令牌后，IPTV CS 110在SIP REFER消息中嵌入令牌，并且在132中将消息转发到OITF2 102。如前面示例中所述，DRM令牌能够在与其它策略不同的消息中传送，这将减轻缓冲步骤144中由IPTV 110接收的SIP REFER消息的需要。在接收策略和令牌时，OITF2 102能够 如上相对于图1所述从DRM服务器获取DRM密钥。类似地，在此点IG 104能够检测到会话转移在相同网络段的两个终端之间进行，相应地，如上所述，它在步骤124中在两端均保留媒体。类似地，步骤126、134和136如上相对于图1所述来执行，以允许会话转移完成。

本领域技术人员将领会到，IPTV控制服务器110虽然对于用户体验不是必定首要的，但在两个公开方法中均能够检测转移请求并获得DRM有关令牌，所述令牌随后被插入发送到目标节点的转移消息中。这种将令牌插入到目的地为转移目标的消息中允许转移目标接收使得能够检索解密密钥的令牌，而解密密钥允许访问DRM加密内容。

图3示出一示范消息传递图以便在理解本发明的一些动态中使用。所示示例是基于拉的转移，其中，OITF2 102既是目标节点，又是始发节点。图3中重复了上面在图1和图2中描述的相同网络节点以便实现一致性。CDF 116将流传送会话146传送到OITF1 100。在步骤150中，基于拉的转移请求从OITF2 102传送到始发节点OITF1 100。如果在OITF2 1021与IPTV CS 110之间的节点需要知道进行中的转移，则通知能够由IMS网络来提供。在当前所示实施例中，这采用了OITF2 102通过IPTV CS 110向OITF1 100发出会话策略转移请求(消息150a)的形式，IPTV CS 110随后将请求作为消息150b转发到OITF1 100。在确定会话策略转移已启动时，IPTV CS 110在消息152中从DRM服务器114请求用于OITF2 102的数字权限管理令牌。在消息154中，从OITF1 100接收会话策略。消息156从DRM服务器114接收，其包含DRM令牌。如在此示范实施例中所示是，在步骤158中，令牌嵌在154中接收的策略中。本领域技术人员将领会，在推转移的未示出示例中，启动节点是始发节点OITF1 100，并且IPTV CS 110接收的会话转移在进行的第一指示是会话转移消息154的接收。在此类情况下，消息154之后将是消息152中对DRM令牌的请求，而不是消息152在前。

在步骤158中，从OITF1 100接收的会话策略修改为嵌入令牌， 并且修改的策略在消息160中从IPTV CS 110传送到OITF2 102。在消息162和164中，OITF2 102将令牌传送到DRM服务器114，并且在交换中接收有效的解密密钥。在消息166中，OITF2 102与CDNC/CC 112初始化转移的(或复制的)会话。如在数据流程168中所示的，CDF 116开始将内容点播会话传送到OITF2 102。在步骤170中，如果请求的是会话转移而不是会话复制，则释放在OITF1 100终止的原始会话。

从OITF终端之一的角度而言，转移请求既不直接发送到另一OITF，也不是通过IMS网关104中继的响应。相反，请求和转移指示通过IPTV CS 110来路由。本领域技术人员将领会，如果转移是推转移，其中OITF1 100既是始发节点，又是启动节点，则对此消息流程进行小的变化。为了简明的缘故，差异未在独立的图中示出，因为基于图1和图3所示的拉转移与如图2所示的推转移之间功能性的差别，本领域技术人员将容易理解消息流程。

图4示出在IPTV控制服务器执行的方法的一示范实施例。本领域技术人员将领会，这些抽象的步骤能够在多种不同方法中实施。在此流程图中概述的步骤已得到充分抽象，以允许它们覆盖推和拉两种实施例。在步骤172中，IPTV CS接收会话转移的指示。本领域技术人员将领会，在推情形中，该指示是会话策略的接收，会话策略在从OITF1启动的会话转移请求中从OITF1转移到OITF2，并且与任何其它会话转移信息一起传送。在拉情形中，在IPTV CS的会话转移的指示是对拉策略的请求的接收，该请求从OITF2向OITF1发出。在步骤174中，IPTV控制服务器获得用于转移接收方的DRM令牌。本领域技术人员将领会，此步骤能够如在图1和图2中所示，通过向DRM服务器发出请求并等待请求的响应来执行。在步骤176中，用于允许转移接收方初始化会话的会话转移信息被修改以包括DRM令牌。在推情形中，会话转移信息由IPTV CS在会话转移请求中接收，并且经常是会话转移的第一指示。随后缓冲会话转移信息，直至接收DRM 令牌。在拉转移中，响应IPTV CS将步骤172中接收的会话策略转移请求作为会话转移的指示来转发，在未示出的步骤中接收会话转移信息。在步骤178中，将修改的会话转移信息传送到转移接收方。本领域技术人员将领会，步骤176中修改的会话转移信息能够是步骤172中接收的指示，或者能够是图4未示出的单独步骤中接收的信息。本领域技术人员将领会，无需在所有实施例中修改会话转移指示以结合DRM令牌，相反，应理解，能够从其它方单独(且甚至在单独的消息中)传送令牌。

图5示出建立在图4所示方法上的基于拉的方法的一示范实施例。图4的步骤172实施为图5的步骤180，其中，IPTV控制服务器接收会话策略转移消息以拉出寻址到始发终端的策略。本领域技术人员将领会，一般基于转移是推还是拉转移而采用不同SIP消息，这将为本领域技术人员很好地理解。在步骤182中，会话策略转移消息被转发到始发终端。图4的步骤174在图5的步骤184中实施，在该步骤中获得与会话和转移接收方相关联的DRM令牌。在步骤186中，接收来自始发终端的回复。图4的步骤176在图5的步骤188中实施，在该步骤中修改步骤186中接收的响应以包括步骤184中获得的令牌。图4的步骤178的实施例是图5的步骤190，在该步骤中将修改的响应传送到目标终端。本领域技术人员将领会，术语始发终端指要转移的会话已经在其正在接收的终端。目标终端指会话转移的目的地。基于图2中示出的消息及图4中示出的方法步骤，本领域技术人员将理解对应的基于推的方法而无需单独的图形。如前面所述，此基于推的方法将采用本领域技术人员将明白的不同SIP消息。

本领域技术人员将领会，设计成执行本发明的方法的IPTV控制服务器将包括消息处理器，用于拦截从一个节点到另一节点的转移请求，并在操作上连接到DRM服务器接口以便从DRM服务器获得令牌。此令牌被插入到转移接收方的拦截消息中以允许转移接收方检索相关解密密钥。

图6示出IPTV CS 110的一示范实施例。IPTV CS 110也在DRM服务器与源和目的地OITF两者交互。相应地，它包括OITF接口192和DRM接口194。通过这些接口发送并且由IPTV CS 110修改的消息由消息处理器196处理。消息处理器196在操作上连接到OITF接口192以接收和路由会话转移请求和指示。响应接收会话要转移的指示，处理器196通过DRM接口194向DRM服务器发出请求。此请求优选识别要转移的会话和(如果必要的话)会话将转移到的终端。令牌通过DRM接口194来接收，并且此令牌被添加到转移指示，所述转移指示可以是会话转移的指示，或者可包含在单独的消息中并随后传送到会话转移接收方。

本发明的实施例可表示为在机器可读媒体(也称为计算机可读媒体、处理器可读媒体或其中实施有计算机可读程序代码的计算机可用媒体)中存储的软件产品。机器可读媒体可以是任何适合的有形媒体，包括磁、光或电存储媒体，包括磁盘、紧致盘只读存储器(CD-ROM)、数字多功能盘只读存储器(DVD-ROM)存储器装置(易失性或非易失性)或类似的存储机制。机器可读媒体可包含各种指令集、代码序列、配置信息或其它数据，它们在执行时促使处理器执行根据本发明的一实施例的方法中的步骤。本领域技术人员将领会，实现所述发明所必需的其它指令和操作也可存储在机器可读媒体上。从机器可读媒体运行的软件可与电路接口以执行所述任务。

本发明的上述实施例仅旨在作为示例。在不脱离仅由本文所附权利要求定义的本发明范围的情况下，本领域的技术人员可对特定实施例实现变更、修改和改变。

Claims (20)

1.一种用于从一个终端节点到另一个终端节点的会话转移或会话复制以允许策略的转移的方法，该策略包括与将要转移或将要复制的会话相关联的DRM有关策略，所述方法包括：

- 接收用于会话转移或会话复制的请求的指示；

- 获得用于所述会话转移或会话复制的所述接收方的数字权限管理令牌，所述数字权限管理令牌允许所述会话转移或会话复制的所述接收方获得所请求的解密密钥；并且

- 将所述数字权限管理令牌传送到所述会话转移或会话复制的所述接收方，

其中接收所述指示的步骤包括从所述会话的当前终端节点接收寻址到预期转移或复制接收方的会话转移或会话复制信息，以及其中传送的步骤包括修改所述会话转移或会话复制信息以包括所述数字权限管理令牌，并且将所修改的会话信息传送到所述转移或复制接收方。

2.如权利要求1所述的方法，其中接收用于会话转移或会话复制的请求的指示的步骤包括接收来自所述转移接收方的启动会话转移或会话复制的请求。

3.如权利要求2所述的方法，其中接收用于会话转移或会话复制的请求的所述指示的步骤之后是传送启动会话转移或会话复制的所述请求到所述会话的当前终端节点的步骤。

4.如权利要求3所述的方法，其中传送所述数字权限管理令牌的步骤包括从所述会话的当前终端节点接收会话转移或会话复制信息、修改所述会话转移或会话复制信息以包括所述数字权限管理令牌、以及将所修改的会话信息传送到所述转移或复制接收方。

5.如权利要求1所述的方法，还包括至少在已接收所述数字权限管理令牌前接收并保留从发出所述指示的节点所接收的会话转移或会话复制信息的步骤。

6.如权利要求1所述的方法，其中获得数字权限管理令牌的步骤包括向数字权限管理服务器发出请求。

7.如权利要求6所述的方法，其中到所述数字权限管理服务器的所述请求包括要转移或要复制的会话的指示。

8.如权利要求6所述的方法，其中到所述数字权限管理服务器的所述请求识别预期转移或复制接收方。

9.如权利要求6所述的方法，其中获得数字权限管理令牌的步骤还包括从所述数字权限管理服务器接收数字权限管理令牌的步骤。

10.如权利要求9所述的方法，其中所接收的数字权限管理令牌特定于要转移或要复制的会话。

11.如权利要求9所述的方法，其中所接收的数字权限管理令牌特定于预期转移或复制接收方。

12.如权利要求1所述的方法，其中所接收的指示是基于会话启动协议的消息。

13.如权利要求12所述的方法，其中所接收的指示是会话启动协议OPTION消息和会话启动协议REFER消息之一。

14.如权利要求12所述的方法，其中所述会话转移或会话复制信息是会话启动协议OPTION消息和会话启动协议200 OK消息之一。

15.如权利要求1所述的方法，其中接收和传送的步骤在到因特网协议电视控制服务器的终端接口来执行，并且获得的步骤在数字权限管理接口来执行。

16.一种用于获得用于转移或复制的会话的数字权限管理许可的IPTV控制服务器，所述控制服务器包括：

- 终端接口，用于接收与要转移或要复制的会话相关联的会话转移或会话复制请求和策略的指示； 

- 数字权限管理接口，用于接收数字权限管理令牌，所述数字权限管理令牌允许所述会话转移或会话复制的接收方获得所请求的解密密钥；以及 

- 处理器，用于通过所述数字权限管理接口发出对所述数字权限管理令牌的请求以响应会话转移或会话复制的所述指示的接收，用于修改与要转移或要复制的会话相关联的策略以包括所接收的数字权限管理令牌，以及用于通过所述终端接口将用于所述会话转移或会话复制的所修改的策略传送到所述转移或复制的预期接收方。

17.如权利要求16所述的控制服务器，其中所述终端接口是到开放式IPTV终端功能的接口。

18.如权利要求16所述的控制服务器，其中所述数字权限管理接口是到所述数字权限管理服务器的接口。

19.如权利要求16所述的控制服务器，其中所述数字权限管理令牌与要转移或要复制的会话独特关联。

20.如权利要求16所述的控制服务器，其中所述数字权限管理令牌与所述转移或复制的预期接收方独特关联。