媒体书签的制作方法

专利名称：媒体书签的制作方法
技术领域：
本发明涉及电子通信网络，更具体地，涉及分组交换通信网络中的媒体内容传送。
背景技术：
常用的网页浏览器应用(例如，Mozilla的Firefox和Microsoft的Internet Explorer)提供了书签，书签允许用户返回至特定互联网网页和浏览器可访问的其他文件 位置。由统一资源标识符(URI)来标识每个网页，不论何时用户创建针对该网页的书签，都 记录URI。用户可以给书签以更容易记忆的、对用户友好的名称，将书签整理并归类到文件
本由绝绝
大T寸寸。互联网协议电视(IPTV)还使用浏览器技术来使IPTV服务提供商能够提供部署在 通信网络(例如，有线或无线电话网络)中的媒体服务。一般地，IPTV是用于对被编码为 IP数据分组系列的多媒体流进行接收和显示的系统。在若干上下文中，IPTV的工作正在进 行中，包括例如开放IPTV论坛，该开放IPTV论坛对端对端平台进行详细描述，该端对端平 台用于在互联网和具有受控的服务质量(Q0Q性能的被管理网络上向用户设备(UE)提供 多媒体和IPTV服务。在www. openiptvforum. org处可获得功能性的IPTV架构的版本1. 1 规范，并且，该架构使用了第三代伙伴计划(3GPP)所详细描述的IP多媒体子系统(IMS)。 UE可以以多种方式访问通过IMS提供的服务，该多种方式包括有线线路(例如，以太网、电 缆调制解调器、数字订户线路等等)和无线(例如，3GPP所详细描述的蜂窝无线电、IEEE 802. 11、IEEE 802. 16 等等)。在3GPP 技术规范(TS) 23. 228V8. 4. O, IP Multimedia Subsystem(IMS)Stage 2 (Release 8)，March 2008以及TS 23. 2 的先前版本中详细描述了 IMS。例如，在以下 文献中描述了 IMS :R. Noldus et al.，“Multi-Access for the IMS Network”，Ericsson Review No. 2,pp. 81-86(2008) ；U. Olsson et al. ,"Communication Services-The Key to IMS Service Growth", Ericsson Review No. 1，pp. 8-13(2008)；以及 P. Arberg et al.， "Network Infrastructure for IPTV^, Ericsson Review No. 3，pp. 79-83 (2007)。在以下文 献中描述了进行基于 IMS 的 IPTV 的方法Μ· Cedervall et al，“0pen IPTV Forum-Toward an Open IPTV Standard，，，Ericsson Review No. 3，pp. 74-78(2007)，以及 Τ. Cagenius et al. , "Evolving the TV experience Anytime, Anywhere, Any Device，，，Ericsson Review No. 3，pp. 107-111(2006)。3GPP网络中的IMS使用会话发起协议(SIP)和会话描述协议(SDP)，作为其基本 信令机制。SIP是由互联网工程任务组(IETF)在请求注释(RFC)3261中所定义的机制， 用于发现端点并对端点之间的控制信号进行路由，SIP是简单操作集合，包括REGISTER、 INVITE、ACK和BYE。SDP是用于声明媒体的协议。在IMS网络中，媒体传输基于实时传输 协议(RTP)等。3GPP TS 24. 229 V7. 11. O, IP Multimedia Call Control Protocol Based on Session Initiation Protocol(SIP)and Session Description Protocol (SDP), Stage 3, Release 7 (March 2008)对基于SIP和SDP的IP多媒体呼叫控制协议进行了详细描述。TS 24. 229的第5节对UE处的SIP使用进行了详细描述，TS 24. 229的第6节对SDP使用 进行了详细描述。对于UE (对IPTV来说，该UE可以是机顶盒(STB)或集成有STB能力的TV)，为了访 问IMS和IPTV服务，该UE注册在服务呼叫会话控制功能(S-CSCF)中，S-CSCF是IMS核心节 点并且本质上是SIP服务器。IMS还包括多个接入节点，接入节点包括代理CSCF (P-CSCF)、 媒体网关控制功能(MGCF)以及一个或多个边界网关(BG)，该一个或多个BG将UE访问转交 给核心节点，并通过该核心节点来访问驻留在媒体服务器上的内容。UE可以包括IP多媒体 订户标识模块(ISIM)，ISIM是驻留在通用集成电路卡(UICC)上的应用或计算机程序，其使 UE能够注册并访问IMS。典型地，使用发起UE对IMS的注册所必需的参数来预配置ISIM， 该参数包括私有用户标识、一个或多个公共用户标识以及归属网络域名。由IPTV提供的当前TV体验不允许用户识别由实况流传输或视频点播(VoD)传送 的节目中的特定场景，以便能够以最小的努力返回到该场景。对于实况流传输，用户不得不 存储节目，然后倒回到所期望的场景，这是一件耗时的事情。VoD可以提供预定义的“场景选 择”，这可以有助于使所期望场景的位置变窄，但是，仍然必须手动发现实际的所期望场景。当前TV体验的另一缺陷是用户不能够从另一观看设备获取所期望的场景，除非 该另一设备可与原始观看设备访问相同的本地存储器。如今，在不改变观看特性的情况下， 例如在暂停期间定住帧的情况下，典型地，也不可能干涉正在播放的节目，然而在暂停期间 定住帧可能影响看节目的用户的观看体验。

发明内容
在本发明的一方面，提供了一种对向电子通信网络的用户显示的媒体信息加书签 的方法。该方法包括产生书签请求消息；向通信网络中的控制服务器发送所述书签请求 消息；以及基于所述书签请求消息来更新书签列表。所述书签请求消息至少包括用户的标 识符、媒体信息的标识符、时间指示符以及书签显示名称。在本发明的另一方面，提供了一种电子通信系统的用于访问和渲染媒体信息的用 户设备。该用户设备包括被配置为与网络中的一个或多个实体交换电子信号的收发器； 被可编程地配置为根据存储器中的指令处理由电子信号携带的信息的电子处理器；以及被 配置为向电子处理器提供用户输入的设备。所述处理器被配置为具有互联网协议电视 (IPTV)功能，能够至少通过以下操作来对向用户显示的媒体信息加书签产生书签请求消 息，所述书签请求消息至少包括用户的标识符、媒体信息的标识符、时间指示符以及书签显 示名称；以及向所述通信网络中的控制服务器发送所述书签请求消息。在本发明的另一方面，提供了一种用于依照请求来存储和获取书签的IPTV用户 简档服务器。该服务器包括被配置为与电子通信网络的一个或多个实体交换电子信号的 收发器；被可编程地配置为处理由所述电子信号携带的信息的电子处理器；以及被配置为 存储可获取的书签的存储器。所述处理器被配置为与用户的简档相关联地存储媒体信息 书签的列表，所述列表至少包括媒体信息的标识符、时间指示符和书签显示名称。


通过结合附图阅读本描述，将理解本发明的若干特征、目的和优势，在附图中
图1示出了在媒体加书签的方法中，通信网络和在通信网络实体之间的信号流；图2示出了根据会话发起协议的书签消息的示例；图3示出了根据XML配置访问协议的消息的示例；图4示出了在媒体加书签的方法中，另一通信网络和在通信网络实体之间的另一 信号流；图5示出了根据XML配置访问协议的消息的另一示例；图6示出了用于返回所获取的书签的消息的示例；图7是用户设备的框图；图8是IPTV用户简档服务器的框图；以及图9是示出了获取书签的方法的流程图。
具体实施例方式如以下更详细描述的，发明人已经认识到，可以以明确的方式来标记IPTV节目中 时间中的特定时刻(例如，场景)或者更一般地，通过IMS访问的媒体内容。将场景的标记 信息(可被称为书签)优选地存储在网络中，例如作为用户的MS或IPTV服务简档的一部 分。将标记信息存储在网络中而不是本地设备中使得能够从任何地方利用任何设备来访问 书签。本领域技术人员将理解，加书签意味着将来返回到节目中的场景，因此，可以假定，节 目将继续在至少某时间段内可访问，例如，以某种方式通过非易失性存储器而可访问。使用这样的书签，用户可以在相同或者不同的媒体渲染设备上从加书签的点向前 重新开始观看节目，并向其他人发送书签，例如作为聊天或其他社交网络交互中的链接，以 使得这些其他人可以从加书签的场景处或附近观看节目(当然，假设这些其他人有权访问 该内容)。图1示出了根据本发明，在针对内容点播(CoD)的媒体加书签的方法中，通信网络 100中的实体之间的典型信号流。将理解，所示出的方法在IMS的上下文中采用适于IMS的 消息，但一般地，可以使用其他上下文和其他类型的消息。在步骤152中，用户指示针对观看媒体信息集合的请求，该媒体信息集合例如是 在用户可使用诸如UE或机顶盒之类的设备通过IMS 104访问的媒体服务器102上可用的 媒体内容。用户可以以很多方式指示该请求，例如，通过点击在UE上运行的浏览器应用中 的链接或URI。步骤1M-166涉及针对所请求的内容建立IMS会话的过程。在步骤154中，UE中 的IPTV终端功能(ITF) 106布置向IMS 104发送SIP INVITE消息，IMS 104将该INVITE消 息转发给与该IMS相关联的IPTV控制服务器108。本领域技术人员将理解，在IMS的上下 文中，SIP INVITE是合适的，而在其他上下文中，可以使用其他类型的消息。ITF 106是UE中使得能够选择并向用户显示IPTV媒体信息的功能，该UE例如是 STB、集成的TV/STB、个人计算机、移动电话或其他用户设备。与本申请中描述的其他功能一 样，典型地，由UE中适当编程的电子处理器或具有存储器的等效物来实现ITF 106，该电子 处理器或具有存储器的等效物处理由UE和网络100中的其他实体交换的信号所携带的信 息。IPTV控制服务器108是用于实现确定和控制用户可用的媒体信息的功能的编程处理器。
IPTV控制服务器108将用户的请求转发给媒体控制器110，在步骤156中，媒体控 制器110向具有用户所请求的内容的媒体服务器102发送DESCRIBE消息。DESCRIBE消息 可以是实时流传输协议(RTSP)消息或根据其他合适协议的消息。在步骤158中，媒体服务 器102以包括RTSP会话标识符在内的RTSP 200 OK消息来响应媒体控制器110。在步骤 160中，媒体控制器110向媒体服务器102发送包括会话标识符在内的RTSP SETUP消息，媒 体服务器在步骤162中以RTSP200 OK消息对此进行响应。在步骤164中，媒体控制器110 使用IMS 104，通过IPTV控制服务器108向ITF 106传递包括RTSP会话标识符在内的SIP 200 OK消息。在步骤166中，ITF 106以适当的肯定应答消息进行响应，该适当的肯定应答 消息从IMS 104传递至IPTV控制服务器108和媒体控制器110并指示建立了 IMS会话。步骤168和170涉及用户播放内容的过程。在步骤168中，用户的ITF 106向媒体 控制器110发送RTSP PLAY消息，该RTSP PLAY消息包括向媒体服务器102转发的已建立 的会话标识符。在步骤170中，媒体服务器102以RTSP 200 OK消息向媒体控制器110进 行响应，该RTSP 200 OK消息包括媒体控制器110向ITF 106转发的会话标识符。媒体控 制器110例如通过启动合适的定时器来记录播放请求的起始时间，以便将来用于建立任意 书签(步骤17 。在不通过IMS控制平面进行传递的情况下，接着进行从媒体服务器102 至UE的ITF106的内容传送。当内容是交互式内容时，如双头箭头所指示，媒体服务器102 和ITF 106交换适当的信息。在步骤174中，用户向ITF 106指示针对将点或场景以书签形式加到内容中的请 求，例如，通过在UE的显示器上、或在特定按钮上、或在与UE上加书签相关联的其他控制设 备上、在遥控器上等等点击来进行。响应于用户的请求，ITF 106中的书签功能可以建议书 签的显示名称，这可以基于内容的标题和/或其他特性。用户可以在请求书签时或者稍后， 通过修改所存储的书签的适当编程的过程来修改所建议的书签显示名称。在步骤176中，ITF 106向IMS 104发送向IPTV控制服务器108转发的SIP INFO 消息。该INFO消息或其他携带书签信息的合适消息包括基于媒体内容和观看时间的一个 或多个信息元素等。在步骤178中，IPTV控制服务器108以SIP 200 OK消息对INFO消息 进行响应，SIP 200 OK消息由IMS 108向ITF 106转发。图2中示出了书签消息的示例，图2示出了包括节目的URI( “〈entry uri =...”)、从节目的起始处的时间偏移或位移(“〈time-offset〉... ”)、以及书签显示 名称(“〈display-name. ···>，，)在内的 SIP NFO 消息。在图 2 中，行 IPTV-bookmarks xmins = " urn:Bookmarks:2008"指示了其中对IPTV书签进行定义的纲要，并包括该信 息元素的值的示例。从SIP翻译成英文，该行可以被解读为“Here is the complex type known as IPTV-Bookmarks, which contains elements and attributes defined by the schema that can be found at urn:Bookmarks:2008，，。将注意至丨J,从先前的、用户从该 ITF 106注册至网络的识别和认证过程中，IPTV控制服务器108知道在图2中通过信息元 素sip:username@iptVproVider. com标识的用户。以内容点播为例，合适的书签消息至少 包括以下信息元素用于标识媒体内容的URI、时间指示符、以及书签显示名称。如上所述， URI和显示名称已经为ITF 106所知，时间指示符可以是如下所述的标记或时间值。IPTV控制服务器108可以确定由于节目自身的可用性或者由于涉及用户对加书 签的使用的一些考虑，对节目加书签仅在有限时间段内可用。如果书签仅在这种有限时间段内可用，则IPTV控制服务器108可以将〈expiration〉元素添加至有关的书签信息。本领域技术人员将理解，SIP INFO消息仅是书签消息的示例，还可以使用其他类 型的消息和其他协议。诸如SIP INFO消息之类的书签消息可以包括返回正在显示的媒体 信息的当前状态所必需的多种信息元素。例如，如果内容与游戏相关联，则书签消息将包括 当获取书签时足以恢复游戏状态的游戏元数据。其示例将是如果媒体信息包括交互式智 力竞赛节目，则在特定点处对内容加书签将记录该时间点处用户的得分和其他参与者的得 分。稍后，当用户从该书签重新开始内容时，将恢复智力竞赛的状态。使用定时器或其他合适的机制来确定从内容起始处到书签时间(例如，产生书签 请求的时间)的时间位移。如图1所示，在确认用户的播放请求(步骤168)时，启动媒体控 制器的定时器(步骤172)。例如，时间指示符可以是ITF 106中合适的定时器所确定的时 间位移值，或者，时间指示符可以是使媒体控制器110中合适的定时器被读取(由步骤180 示出)的标记。在接收到书签请求(步骤176)时，在步骤182中获取所经过的时间值或其 他合适的指示。考虑到加书签的实际方面，典型地，在用户认识到应当创建书签的时间与用户实 际按下“书签”按钮并产生书签请求的时间之间有迟滞。从而，书签时间应当被设置为比ITF 接收书签请求更早的某个时间。一个选项是使媒体控制器110被布置为在其获取的所经 过的时间值中减去合适的“反应时间”。作为备选，ITF 106可以被布置为当用户选择书签 以用于回放时，从由媒体获取的实际经过时间减去“反应时间”。“反应时间”的量可以是用 户可选择的，并可以被存储为用户简档的另一方面。在步骤184和186中，IPTV控制服务器108更新书签列表，优选地，该书签列表中 的书签是IPTV控制服务器108或关联的IPTV用户简档服务器112所存储的相应用户简档 的一部分。可以在用户的ITF106处维持用户简档的拷贝。该更新有利地使用了可扩展标 记语言(XML)配置访问协议(XCAP)，XCAP是用于以新的书签更新用户简档的高效机制。在 步骤184中，IPTV控制服务器108向IPTV用户简档服务器112发送XCAP PUT消息，XCAP PUT消息包括有关的书签信息，例如书签地址、内容的URI、时间位移、书签的到期时间(如 果有的话)的指示、以及书签显示名称。在步骤186中，IPTV用户简档服务器112对消息 (例如，超文本传输协议(HTTP) 200 OK消息)进行响应，以指示成功创建书签。在步骤188中，通过从IPTV控制服务器108向ITF 106发送的SIP NOTIFY消息， 向用户的在ITF 106上的本地书签应用通知所添加的书签。根据标准SIP使用，ITF 106 以SIP 200 OK消息对NOTIFY消息进行肯定应答(步骤190)。将意识到，对于步骤188和 190，用户的ITF先前将已经使用SIP SUBSCRIBE消息，请求接收简档的改变的通知，该SIP SUBSCRIBE消息包含针对书签应用的xcap-diff事件封装等。响应于这样的请求，在步骤 188中向用于产生书签请求的ITF发送SIP NOTIFY消息。还向其他ITF发送NOTIFY消息，该其他ITF与已订阅接收这样的通知的用户相关 联，该订阅是通过使用xcap-diff事件封装，从要求接收简档改变的ITF发送SUBSCRIBE消 息而进行的。针对新的ITF(即，不具有用户简档的拷贝的ITF)，这样的订阅请求可能导致 下载用户的整个简档。然后，从网络到该ITF的后续通知导致仅发送简档的改变。NOTIFY 消息还可以用于向ITF通知书签已到期，从而ITF可以删除书签、禁用书签、或者以视觉方 式向用户指示书签不再有效。
XCAP允许客户端读取、写入和修改以XML格式存储在服务器上的应用配置数据。 每个这样的应用配置数据可以称为“应用用法”，并与被称为应用唯一标识符(AUID)的唯 一名称相关联。用户的IPTV书签是这种应用用法的特定情况，并且，在XCAP请求中将这种 书签的AUID与用户名一起使用，以访问存储了用户的书签信息的逻辑数据存储器。本领域技术人员将理解，xcap-diff涉及对文档格式进行定义的IETF草案，该文 档格式可以用于指示XCAP所管理的文档中已经发生改变。当若干客户端共享存储在服务 器上的相同XML文档并使用XCAP来改变所共享的文档时，这是有用的。由于客户端可以同 时改变文档，因此没有简单的方式来查明客户端已在其存储器中高速缓存的文档是最近的 版本。为了处理该问题，客户端可以使用事件封装(例如，在IETF RFC 3265中定义的事件 封装)来订阅XCAP文档中的改变事件。xcap-diff-event是这样的事件封装，并且，订阅该 事件封装的客户端将被通知所关注的XML文档的任何改变。所使用的数据格式是XML文档 格式，称为XCAP diff文档，其可以指示文档已发生改变，并提供其先前的和新的实体标签。 可选地，其还可以包括一组补丁操作(例如，I-D. ietf-simple-xml-patch-ops)，其指示如 何将文档从改变之前的版本变换到改变之后的版本。还可以以该格式来传送XCAP文档的 XML元素和属性内容。图3示出了可从IPTV控制服务器向IPTV用户简档服务器发送的XCAP PUT消息 的示例。如上注意到的，XCAP是允许容易地辨认出XML信息的片断并在形成完整系统的功 能之间对该片断进行交换的协议。使用XCAP，便没有必要发送整个用户简档以利用书签对 其进行更新。从图3中可见，XCAP消息包括书签地址(“http://userprofileserver.iptvprovider.com···，，)、媒 体 信 息 的 URI (“〈entry uri =... ”)、从媒体信息的起始处的时间位移(“〈time-offset〉. · · ”)、书签 停止可用的时间(“〈expiration〉. · · ”)、以及书签显示名称(“<display-name〉·.. ”)。将注 意到，从先前的、用户从该ITF 106注册至IPTV控制服务器108的识别和认证过程中，IPTV 控制服务器108和IPTV用户简档服务器112知道在图3中通过信息元素sipmsernameO iptvprovider. com 标识的用户。图4示出了根据本发明，在针对线性TV的媒体加书签的方法中，另一通信网络 100'中的实体之间的典型信号流。一般地，线性TV是根据预定义进度表而呈现的媒体信 息的节目。在步骤402中，用户指示针对观看线性TV节目的请求，该线性TV节目是用户可以 利用由访问设备(例如，STB)实现的ITF 106来访问的。用户可以以多种方式指示该请求， 例如，通过在运行于UE上的浏览器应用中的链接或URI上点击来指示。步骤404-408涉及针对线性TV建立IMS控制会话的过程。在步骤404中，用户的 ITF 106布置向IMS 104发送SIP INVITE消息，IMS 104向与IMS 104相关联的IPTV控 制服务器108转发用户的请求。IPTV控制服务器108在步骤406中以通过IMS 104向ITF 106转发的SIP 200 OK消息进行答复。在步骤408中，ITF 106以适当的肯定应答消息进 行响应，该适当的肯定应答消息从IMS传递至IPTV控制服务器并指示建立了 IMS会话。在步骤410中，ITF 106发布互联网组管理协议(IGMP)JOIN消息，以加入针对由 用户请求的线性TV频道的多播地址。向数字订户线路接入复用器(DSLAM) 114或其他合 适网络设备发送JOIN消息，从而，向用户的ITF 106传送线性TV频道中的内容。一般地，DSLAM是可将若干用户连接到网络的复用器，多播组是高效且当前流行的机制，用于在通信 网络上传送线性TV频道。IP主机使用IGMP来管理IP多播组，并且，所连接的路由器使用 IGMP来发现针对流传输视频和其他内容的组成员。由RFC 1112定义IGMP版本1，由RFC 2236定义IGMP版本2，由RFC 3376定义IGMP版本3。在步骤412中，用户向ITF 106指示针对将点或场景以书签形式加到节目中的请 求，例如，通过在UE的显示器上、或在特定按钮上、或在与UE上加书签相关联的其他控制设 备上、在遥控器上等等点击来进行。响应于用户的请求，ITF 106中的书签功能可以建议书 签的显示名称，这可以基于节目的标题和/或其他特性，并且，ITF 106中的书签功能可以 使用户能够在请求时修改所建议的书签显示名称，或者如果稍后进行修改，则通过修改所 存储的书签的过程来进行。在步骤414 中，ITF 106 向 IMS 104 发送 SIP INFO 消息，IMS 104 向 IPTV 控制服 务器108转发该消息。如果ITF 106得到未正在记录线性TV节目的信息，那么典型地，ITF 106将不创建和发送SIP INFO消息，并将合适地劝告用户。ITF 106可以从节目进度表获得 这样的信息，其可以包括用于示出是否可以对节目加书签的图标或其他指示。优选地，INFO 或其他合适的消息至少包括以下信息元素节目多播地址、所请求的节目的内容标识符、以 及用户所选择的书签显示名称。在步骤416中，IPTV控制服务器108查明节目是否是可用 的；例如，该服务器确定在网络100'中是否正在记录该节目。如果未正在记录该节目，则不可能创建书签，这是因为该节目在稍后的时间将不 是可访问的，以及，可以向用户提供合适的消息。ITF106基于其自身的定时器以及节目进 度表的拷贝，将时间偏移包括在其书签消息中。然后，IPTV控制服务器108确定正在记录 的节目的描述符的URI。如果成功完成步骤416，则IPTV控制服务器108通过IMS 104将 SIP 200 OK消息返回(步骤418)给ITF 106，以指示操作成功。将注意到，即使正在记录节目，典型地，IPTV控制服务器也不知道节目是何时开始 播放的，即，JOIN消息是何时从ITF 106向DSLAM 114发送的(步骤410)。IPTV控制服务 器不能计算书签时间，因此，时间偏移由ITF 106确定。在步骤420和422中，IPTV控制服务器108更新书签列表，优选地，书签列表中的 书签是IPTV控制服务器108或关联的IPTV用户简档服务器112所存储的相应用户简档的 一部分。如以上结合图1和图3所述，该更新有利地使用了 XCAP，作为用于以新的书签更新 用户简档的高效机制。在步骤420中，IPTV控制服务器108向IPTV用户简档服务器112发 送XCAP PUT消息，XCAP PUT消息包括用于稍后获取节目的有关书签信息，例如书签地址、 网络记录内容的URI、时间位移、和书签显示名称。XCAP PUT消息还可以包括用于指示书签 的有效周期的到期元素。在步骤422中，IPTV用户简档服务器112以HTTP 200 OK消息进 行响应，以指示成功创建书签。在步骤似4中，通过从IPTV控制服务器108经由IMS 104向ITF 106发送的SIP NOTIFY消息，向用户的在ITF 106上的本地书签应用通知所添加的书签。根据标准SIP使 用，ITF 106以SIP 200 OK消息对NOTIFY消息进行肯定应答(步骤426)。应当意识到，对 于步骤似4和426，用户先前将已经订阅如上所述针对书签应用的xcap-diff事件封装。在创建书签后，用户可以简单地通过从合适的访问设备(例如，STB或其他UE)访 问他或她的IPTV用户简档，获取他或她的书签列表，并且，可以从与在其上创建书签的设备不同的设备进行这种访问。当通过浏览器来登录或签入IPTV系统时，典型地，向用户呈 现可选择的链接的菜单，其中之一可以是面向“IPTV书签”的链接。通过选择该链接，用户 的ITF向已存储如上所述的IPTV书签的IPTV用户简档服务器发送针对获取所存储的书签 的请求。图5示出了作为合适的请求消息的XCAP GET消息，用于从用户简档的书签部分 取得特定用户的书签。在图5中，书签AUID被称为“IPTV-Bookmark”。请求消息包括对 用户进行标识(如“sip:username@iptvprovider. com”)和对服务提供商进行标识(如 “iptvprovider.com，，)的信息元素。应当意识到，在对请求消息进行操作之前，典型地，IPTV用户简档服务器112或其 他网络实体将调用合适的用户认证和访问控制过程，例如，要求用户输入用户名和密码。如 果这些过程成功完成并且访问被授权，则在合适的消息中返回书签列表。图6示出了适于将所获取的书签从IPTV用户简档服务器112返回给ITF 106的 HTTP 200 OK消息。从图6中可见，以所返回的书签的项目作为书签条目的属性，该消息包 括每个书签的URI ( “〈entry uri =... ”)、对节目的起始处的时间位移("time-offset =...”)、以及书签列表名称(“〈list name = ...”)。每个书签条目可以包括到期信息 ("expiration =... ”)，例如日期和时间，如果在创建书签时设置了这样的信息。将这些 结果显示给用户，用户可以从所显示的结果中进行选择。包括在用户的访问设备中的ITF 106中的网页浏览器解析该消息。本领域技术人员将理解，用户可以使用ITF 106中的网页 浏览器来修改或编辑从书签列表中选择的一个或多个书签，并使用合适的XCAP消息向网 络发送改变，以修改表示所列出的书签的XML文档。将理解，可以以多种方式获取书签列表，这些方式以实质上相同的方式开始。在 IPTV用户简档服务器112保存与用户简档中的书签有关的信息后，IPTV用户简档服务器 112向IPTV控制服务器108发送OK消息(步骤186和422)。IPTV控制服务器108将OK 消息视为成功保存，并产生SIP NOTIFY消息(步骤188和424)。SIP NOTIFY消息包含描 述书签信息的XML主体。基本上，这样的XML主体可以与由IPTV控制服务器108向IPTV 用户简档服务器112发送以请求保存书签的PUT消息的主体相同，但可以包括网络添加的 元素，例如时间偏移。ITF 106可以使用这种SIP NOTIFY消息中的信息来更新其本地书签 列表。与在本申请中描述的媒体内容有关而与用于显示该媒体内容并创建书签的设备 无关的书签向用户提供多得多的节目回放能力，这是因为可以从对用户可用的任何合适设 备访问和使用书签。在例如交互式TV的情况下，这样的能力特别有用，其中，使得能够捕获 并随后恢复游戏或其他交互式内容的状态。此外，使用IPTV书签XCAP应用用法，可以将书 签请求转换成容易向合适目录中的用户简档添加条目的XCAP请求。用户可以在适当认证 后从任何设备访问该目录，并获取所存储的书签。本领域技术人员将理解，本申请中描述的方法和设备可以在多种类型的电子通信 网络中实现，例如，在移动无线网络中实现。图7是用于访问和渲染本申请中描述的媒体节目内容的典型UE700(例如，移动电话、STB、计算机等)的框图。UE 700包括收发器702，适于与 图1和图4所示的网络实体中的一个或多个交换电子信号。这些信号所携带的信息由处理器704处理，处理器704可以包括一个或多个子处理器，并执行一个或多个软件模块和应用 (包括例如ITF 106)以执行上述的UE 700的操作。通过键区、遥控器或其他设备706提供 至UE 700的用户输入，并且，向显示器708提供呈现给用户的信息。如果显示器具有触摸屏 能力，则可以通过该显示器来提供用户输入。可以将软件应用存储在合适的应用存储器710 中，并且，UE还可以将所期望的信息下载和/或高速缓存到合适的存储器712中。UE 700 还可以包括可用于将其他组件(例如，计算机、麦克风等等)连接到UE 700的接口 714。在创建书签的过程中，ITF 106经由键区706或接口 714接收传递给处理器704的 书签请求，处理器704通过先前的会话建立，将内容或节目的存储器712中的信息呈现给用 户。基于处理器704自身在存储器712中对节目进度表的拷贝，处理器704还知道节目中 的时间偏移，并且，使用该信息，处理器704形成适当的SIP INFO消息(步骤176或414)， 并经由收发器702将其发送至IMS 104。收发器702接收对用户的书签的更新进行指示的 SIP NOTIFY消息(步骤188或424)，并且处理器704在其在存储器712中对书签的本地拷 贝中记录该更新。通过使处理器704形成SIP 200 OK消息，ITF 106对SIPN0TIFY消息的 接收进行肯定应答，SIP 200 OK消息由收发器702发送至网络(步骤190或426)，然后，处 理器704可以经由显示器708向用户呈现书签的指示或实际书签本身。图8是典型的IPTV用户简档服务器112的框图，如本申请中所述，IPTV用户简档 服务器112用于依照请求来存储和获取书签。IPTV用户简档服务器112包括收发器802， 适于与图1和图4所示的网络实体中的一个或多个交换电子信号。这些信号所携带的信息 由处理器804处理，处理器804可以包括一个或多个子处理器，并执行一个或多个软件模块 和应用，以执行上述的IPTV用户简档服务器112的操作。具体地，处理器804将用户书签存 储在合适的存储器806中，并响应于接收到的请求，从存储器806中获取所选择的书签。将 理解，典型的IPTV用户简档服务器112是网络中的数据库服务器，因此，键区/显示器808 通常对于用户输入/输出来说是不需要的，尽管可以针对管理功能来提供这样的接口。可 以将由处理器804执行的软件应用存储在合适的应用存储器810中。图9是示出了从IPTV用户简档服务器112中获取书签的方法的流程图。如上所 述，用户通过从用户的UE向IPTV用户简档服务器112发送(步骤902)请求(优选地，诸 如图5所示之类的XCAP GET消息)来获取他或她的书签列表。发送这样的请求可以包括 登录或签入IPTV系统，以及可能向IPTV用户简档服务器112提供用户名和密码。如果访 问被授权(在步骤904中为“是”)，则IPTV用户简档服务器112在合适的消息中向用户的 UE返回(步骤906)书签列表，该合适的消息例如是诸如图6所示之类的HTTP 200 OK消 息。可以如上所述向各个UE返回所返回的书签或书签列表。在用户的UE处，有利地，由浏 览器或者用户的UE所实现的其他合适应用对所返回的消息进行解析，并在UE的显示器上 呈现所获取的书签或书签列表(步骤908)。如果访问未被授权(在步骤904中为“否”)， 则在UE的显示器上呈现失败或类似的差错消息。此处描述的本发明可以被视为完全体现在以下任何形式的计算机可读存储介质 内，上述任何形式的计算机可读存储介质中已存储了适当的指令集合，以由指令执行系统、 装置或设备(例如，基于计算机的系统、包含处理器的系统、或可从介质取得指令并执行指 令的其他系统)使用或者与所述指令执行系统、装置或设备结合使用。此处使用的“计算 机可读介质”可以是可包含、存储、通信或传输由所述指令执行系统、装置或设备使用或者与所述指令执行系统、装置或设备结合使用的程序的任何装置。计算机可读介质可以是例 如但不限于电子、磁、光、电磁、红外或半导体系统、装置、设备或介质。计算机可读介质的 更多具体示例(非详尽的列表)包括具有一条或多条线的电连接、便携式计算机磁盘、RAM、 ROM、以及可擦除可编程只读存储器(EPR0M或闪存)。期望可以在许多种环境中实现本发明，包括例如在移动通信设备中。还将意识到， 在必要时，重复执行上述过程。为了便于理解，依照例如可由可编程计算机系统的元件执行 的动作序列来描述本发明的方面。将认识到，可以由专用电路(例如，相互连接以执行专用 功能的离散逻辑门、或特定用途集成电路)、一个或多个处理器所执行的程序指令、或这两 者的组合来执行各种动作。因此，可以以多种不同形式来体现本发明，以上并未描述其全部，并且，所有这样 的形式都是在本发明的范围之内想到的。针对本发明各个方面中的每一个方面，任何这样 的形式可以被称为“逻辑，被配置为，，执行所述动作，或者备选地，被称为“逻辑”，执行所述 动作。需要强调的是，当在本申请中使用时，术语“包括”指定了存在所提到的特征、组分、 步骤或组件，并且不排除存在或添加一个或多个其他特征、组分、步骤、组件或其组合。上述具体实施例仅是示意性的，并且决不应被视为限制性的。本发明的范围由权 利要求所确定，并且，落在权利要求范围内的所有变型和等效物预期包括在其中。
权利要求
1.一种对向电子通信网络(100;100')的用户显示的媒体信息加书签的方法，包括(a)产生书签请求消息，其中，所述书签请求消息至少包括用户的标识符、媒体信息的 标识符、时间指示符以及书签显示名称；(b)向通信网络中的控制服务器(108；112)发送所述书签请求消息；以及(c)基于所述书签请求消息来更新书签列表。
2.根据权利要求1所述的方法，其中，所述媒体信息是媒体内容或媒体节目。
3.根据权利要求2所述的方法，还包括确定在所述网络中是否正在记录所述媒体节 目；以及如果未正在记录所述媒体节目，则响应于所述书签请求消息，发送不可用消息。
4.根据权利要求1所述的方法，还包括获取书签；以及向至少一个用户设备发送所获 取的书签。
5.根据权利要求1所述的方法，还包括订阅以接收所述书签列表的改变的通知；以及 发送指示所述书签列表中的改变的至少一个通知消息。
6.根据权利要求1所述的方法，其中，产生书签请求消息的步骤包括基于所述媒体信 息的至少一个特征，建议显示名称。
7.根据权利要求1所述的方法，其中，所述书签请求消息是SIPINFO消息。
8.根据权利要求1所述的方法，其中，所述时间指示符是从所述媒体信息的起始处到 产生所述书签请求消息的时间的时间位移。
9.根据权利要求1所述的方法，其中，更新书签列表的步骤包括将到期指示包括在书 签中。
10.根据权利要求1所述的方法，其中，所述书签请求消息包括所述媒体信息的元数据。
11.根据权利要求10所述的方法，其中，所述媒体信息是交互式媒体内容，以及，所述 元数据使得能够恢复所述交互式媒体内容的状态。
12.根据权利要求1所述的方法，其中，所述书签列表与用户的所存储的简档相关联。
13.根据权利要求12的方法，其中，所述简档由所述控制服务器存储。
14.根据权利要求1所述的方法，其中，更新书签列表的步骤包括从所述控制服务器 向被配置为存储用户的简档的用户简档服务器发送更新消息，以及，所述更新消息依照于 可扩展标记语言配置访问协议XCAP。
15.根据权利要求14所述的方法，其中，所述更新消息是指示所述媒体信息的标识符、 所述时间位移和所述书签显示名称的XCAP PUT消息。
16.一种电子通信网络(100 ； 100')的用于访问和渲染媒体信息的用户设备(700)， 包括收发器(702)，被配置为与网络中的一个或多个实体(104 ；110 ； 114)交换电子信号；电子处理器(704)，被可编程地配置为根据存储器(710、712)中的指令来处理所述电 子信号所携带的信息；以及被配置为向所述电子处理器提供用户输入的设备(706;708)；其中，所述处理器被配置为具有互联网协议电视IPTV功能，能够至少通过以下操作 来对向用户显示的媒体信息加书签(a)产生书签请求消息，其中，所述书签请求消息至少包括用户的标识符、媒体信息的标识符、时间指示符以及书签显示名称；以及(b)向通信网络中的控制服务器(108 ；112)发送所述书签请求消息。
17.根据权利要求16所述的用户设备，其中，所述书签请求消息是SIPINFO消息。
18.根据权利要求16所述的用户设备，其中，所述时间指示符是从所述媒体信息的起 始处到产生书签请求的时间的时间位移。
19.根据权利要求16所述的用户设备，其中，所述书签请求消息包括所述媒体信息的 元数据，以及，如果所述媒体信息是交互式媒体内容，以及，所述元数据使得能够恢复所述 交互式媒体内容的状态。
20.一种互联网协议电视用户简档服务器(112)，用于依照请求来存储和获取书签，所 述互联网协议电视用户简档服务器(11 包括收发器(802)，被配置为与电子通信网络(100;100')的一个或多个实体(104;108) 交换电子信号；电子处理器(804)，被可编程地配置为处理所述电子信号所携带的信息；以及存储器(806 ；810)，被配置为存储可获取的书签；其中，所述处理器被配置为与用户的简档相关联地存储媒体信息书签的列表，所述列 表至少包括媒体信息的标识符、时间指示符和书签显示名称。
21.根据权利要求20所述的服务器，其中，所述列表是基于从控制服务器接收到的更 新消息来更新的，以及，所述更新消息依照于可扩展标记语言配置访问协议XCAP。
22.根据权利要求21所述的服务器，其中，所述更新消息是指示所述媒体信息的标识 符、时间位移和所述书签显示名称的XCAPPUT消息。
全文摘要
可以以明确的方式对节目或其他媒体内容中的诸如场景之类的特定时间实例加标签。优选地，将场景的可被称为书签的标签信息存储在通信网络中，作为用户的服务简档的一部分。使用这样的书签，用户可以在相同或者不同的媒体设备上从加书签的点向前重新开始观看节目，并向其他人发送书签，例如作为聊天或其他社交网络交互中的链接，以使得这些其他人可以从加书签的场景处或附近观看节目(当然，假设这些其他人有权访问该内容)等等。
文档编号G06F3/00GK102119373SQ200880130696
公开日2011年7月6日 申请日期2008年8月6日 优先权日2008年8月6日
发明者乔治·福蒂, 保罗·希格斯, 尼洛·米特拉 申请人:艾利森电话股份有限公司