WO2009046671A1 - Procédé, système et appareil pour obtenir des informations de gestion d'utilisateur - Google Patents

Description

一种获取用户管理信息的方法、 系统和设备 本申请要求于 2007 年 9 月 30 日提交中国专利局、 申请号为 200710162759.X, 发明名称为 "获取用户管理信息的方法、 系统和设 备"的中国专利申请的优先权，其全部内容通过引用结合在本申请中。 技术领域

本发明涉及移动通信领域， 特别是一种获取用户管理信息的方 法、 系统和设备。 背景技术

手机电视业务，是利用具有操作系统和视频功能的智能手机观看 电视的业务。 显然， 由于手机用户普及率高且手机拥有携带方便等特 性， 手机电视业务显示出了比普通电视更广泛的影响力。

目前， 手机电视业务的实现方式主要有三种。 第一种是利用移动 网络实现的方式， 如中国移动推出的手机电视业务。 第二种是利用卫 星广播的方式， 韩国的运营商计划釆用这种方式。 第三种是在手机中 安装数字电视的接收模块， 直接接收数字电视信号。

利用移动网络实现的方式有目前中国移动推出的手机电视业务， 主要是依靠现有的 GPRS ( General Packet Radio Service, 通用分组无 线服务）移动网络实现的。 这种手机电视业务实际上是利用流媒体技 术， 把手机电视作为一种数据业务推出来。 不过， 客户需要在安装有 操作系统的手机终端 （一般是 PDA ( Personel Digital Assisitan, 个人 数字助理）手机等高档产品）上再下载安装相应的播放软件， 而相应 的电视节目内容则由中国移动与内容提供商 SP ( Service Provider,服 务供应商）合作提供。

利用卫星网络实现的方式即利用手机来接受卫星播发的电视节 目信号是一个非常新颖的想法。 目前只有韩国在力推这种手机电视广 播方式 DMB ( Digital Multimedia Broadcasting, 数字媒体广播）。 据 SK称， 这种 DMB接收机能提供高质量的图像， 使用该接收机模块 能使用户能够同时接收地面无线电视广播和卫星电视广播的信号。

然而， 在手机电视业务中， 服务器获得终端状态以及进行内容统 计等管理手段目前没有方法实现。

现有技术的缺点在于，通过广播的方式可以使终端获取服务器发 送来的节目内容， 但是有很多的终端信息， 釆用广播的方式是无法进 行管理的。比如收视率的统计以及针对正在观看电视的互动文档的更 新的过程。 另外， 当 SG ( Service Guide, 服务指南） 更新后， 无法 及时将更新内容发送到合适的用户；且服务器无法及时地获知用户的 状态 （在线 online状态， 观看频道状态等）。 发明内容

本发明的实施例提供一种获取用户管理信息的方法、 系统和设 备， 用于实现对终端用户管理信息的统计。

为达到上述目的，本发明的实施例提供一种获取用户管理信息的 方法， 包括：

接收终端发送的携带用户管理信息的消息；

从所述消息中获取所述终端的用户管理信息；

对所述用户管理信息进行信息处理。

本发明的实施例还提供一种获取用户管理信息的系统， 包括： 服务器， 用于接收终端发送的用户管理信息， 并保存所获取的所 述终端的用户管理信息；

终端， 用于向所述服务器发送用户管理信息。

本发明的实施例还提供一种服务器， 用于获取用户管理信息， 包 括：

接收模块， 用于接收终端发送的用户管理信息；

统计模块，用于保存所述接收模块获取的所述终端的用户管理信 息。 本发明的实施例还提供一种终端 ,用于向服务器发送用户管理信 息， 包括：

用户管理信息生成模块， 用于生成用户管理信息，

用户管理信息发送模块，用于将所述生成的用户管理信息以消息 形式发送。

与现有技术相比， 本发明的实施例具有以下优点：

通过终端与服务器间的消息交互，实现了对终端用户管理信息的 统计、 交互更新以及收视率的统计等信息的互通的目的。 附图说明

图 1为本发明的实施例一中获取用户管理信息的方法的流程图； 图 2为本发明的实施例二中获取用户管理信息的方法的流程图； 图 3为本发明的实施例三中获取用户管理信息的方法的流程图； 图 4为本发明的实施例四中获取用户管理信息的方法的流程图； 图 5为本发明的实施例五中获取用户管理信息的系统的结构图。 具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细 描述：

本发明的实施例一中， 一种获取用户管理信息的方法如图 1 所 示， 包括以下步骤：

步骤 slOl、 接收终端发送的携带用户管理信息的消息。

步骤 s 102、 从消息中获取终端的用户管理信息。

步骤 sl03、 对用户管理信息进行信息处理。

具体地， 本发明的实施例中， 通过终端与服务器间的消息交互， 达到交互更新以及收视率的统计和其他相应信息的互通的目的。终端 与服务器间的交互消息可以进行规定，满足一定的格式并携带少数必 要的信息即可， 这样的消息有利于服务器处理， 也有助于减小服务器 负担。服务器对终端信息的记录以及统计的结果可以按照一定的策略 完成， 并且服务器处理终端上报的互动信息也根据策略来完成。

本发明的主要实施方法在于： 当用户接入（Login ) 某频道后， 终端要将业务标识 Service ID和用户标识 User ID等用户管理信息保 存在本地，当接收节目达到一定时间后，终端要将 Service ID、 User ID 和频道标识 Channel ID等用户管理信息发送到服务器。当终端退出节 目后，还要将 Service ID、 Channel ID和 User ID等用户管理信息发送 到服务器， 完成一次退出 （ Logout )。 Login与 Logout的作用主要在 于为服务器提供终端的用户管理信息， 为服务器统计收视率、 界定终 端的观看行为提供依据。

当用户接入（Login ) 某频道后， 终端也可以直接将 Service ID 和 User ID等用户管理信息发送到服务器， 不需要等待接收该频道的 节目达到一定时间。 上述情况下， 该用户管理信息不包括频道信息， 即 Channel ID。 当终端退出节目后， 可以将 Service ID、 Channel ID 和 User ID等用户管理信息发送到服务器， 完成一次退出 （ Logout )。

服务器获取终端的用户管理信息之后 ,还可以对获取的用户管理 信息进行信息处理， 至少包括以下一种操作：

记录用户登录状态； 记录用户观看节目状态信息； 记录用户需要 更新的业务信息。

其中， 用户登录状态， 至少包括以下一种信息： 终端标识、 用户 标识、 业务订阅关系、 登陆时间、 登陆方式、 用户密钥的有效期； 用 户观看节目状态信息，至少包括以下一种信息：用户观看的节目标识、 用户观看的频道标识、 用户收看频道的开始时间、 用户观看频道的退 出时间； 用户需要更新的业务信息， 至少包括以下一种信息： 用户密 钥是否需要更新、 用户互动信息是否需要更新、 用户业务 SG是否需 要更新。

服务器获取终端的用户管理信息之后，还可以获取频道节目的收 看时间，该频道节目的收看时间可以根据用户管理信息中携带的消息 发送时间获取；或根据服务器向终端发送节目第一帧和最后一帧的时 间获取。

服务器获取终端的用户管理信息之后，还可以获取频道或节目的 收视率。 获取频道或节目的收视率的具体步骤， 可以包括： 对需要进 行统计的频道或节目设置标识；接收终端在接收或退出频道或节目的 内容时发送的消息；根据消息获取频道或节目的收视率。也可以包括： 向所有终端或特定的终端发送是否在收看特定频道或节目的消息；接 收正在收看特定频道或节目的终端发送的响应消息；根据响应消息获 取频道或节目的收视率。

本发明的实施例二提供了一种将终端接入节目频道（ Login ) 和 终端退出播放节目 （Logout )时服务器获取用户管理信息的方法。 用 户管理信息包括以下信息中的一种或多种： 消息类型标识、 消息发送 时间、 终端标识、 业务标识、 节目标识、 终端是否在线的状态、 终端 识别码、 用户标识信息以及频道标识， 所述消息类型标识包括登录消 息标识和注销消息标识。对于服务器而言， 终端在订阅了频道后不会 有任何消息发送到服务器。 终端的状态、 用户的情况、 订阅频道的更 新情况等对服务器来说都是不知道的， 因此需要提供一种方法来解决 这样的问题。本方案提供的方法可以为服务器进一步掌握终端接收节 目的情况和交互提供手段。

请参照流程图图 2 , 该方案的实施思想主要在于， 当终端用户收 看某一时刻的节目时， 终端会接入（ Login )到播放该节目的频道。 接入后的用户管理信息， 包括 Service ID、 User ID等用户管理信息会 被终端发送到服务器。用户管理信息的形式可以通过多种方式发送到 服务器上。 服务器会保存用户管理信息并对接收到的消息做出响应。 当终端退出 （Logout )接收节目后， 还会与服务器进行一次交互： 终 端将退出时的用户管理信息，包括， Service ID、 Channel ID和 User ID 等用户管理信息发给服务器。服务器根据退出的用户管理信息对保存 的终端接入节目的情况进行一次综合记录。

本实施例具体流程如图 2所示， 步骤如下：

步骤 s201 , 终端启动， 并向服务器发送 Loglnlnfo消息。 Loglnlnfo消息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:31 :22GMT

Accept-Ranges:bytes

Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www.sample.com:8080

Connection: close

<CR>

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- >

<LogReport

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\Documents and Settings\Administrator\桌面 \Edit3.xsd">

<Message— Type Message— Type— Type="LogMnfo"/>

<User_ID User_ID_Type="abc"/>

<Service_ID Service— ID— Type="01"/>

<Program_ID Program— ID— Type=" 11 "/> 本实施例中， Loglnlnfo 消息以 XML ( Extensible Markup Language,可扩展标记语言）的形式作为消息体加在 HTTP( Hyper Text Transfer Protocol ,超文本传输协议） POST头的后面，带到服务器上。 消息头和消息体间用回车 <0 >间隔开， 回车上面的为消息头， 下面 的为消息体。消息头中描述了要请求的主机和端口，连接方式为 close , 表示不必持续连接， HTTP1.1支持非持续连接。

Loglnlnfo消息包括了 Service ID( Identification,标识符）、 User ID (例如： IMSI ( International Mobile Subscriber Identification Number, 客户识别码）信息）， 以及其他接入用户管理信息。 终端的 Loglnlnfo 消息具有某种格式， 例如如图 2所示。 消息的发送是通过交互信道完 成的。 保存 Loglnlnfo消息的服务器可以是交互服务器， 也可以是专 门用来记录统计数据的服务器。本实施例中 Loglnlnfo以 html的形式 发送到服务器上。

发送 Loglnlnfo的方法可以是通过多种方法， 例如 HTTP POST 方法。 这里只是举例说明， 如有其它方式可以替代， 其原理与思想是 一致的。

终端启动时会将 Login的消息 Loglnlnfo上报给服务器， 同时服 务器将该用户状态制成 online。 终端到服务器上取 SG以及其他相关 数据。 而当服务器上的相关数据有更新的时候， 此时服务器可以向已 经在线的用户进行数据更新的通知 Push消息发送给 online的终端， 则终端可以及时感知服务器上的数据变化， 及时取回数据。

步骤 s202, 终端获取 SG。

手机电视终端接收频道节目的前提是该终端已经注册在服务器 上， 并且已经激活， 可以接入频道接收节目。

步骤 s203 ,未定购频道的终端才艮据获取的 SG重新建立频道定购。 确定的定购关系描述的是用户对 SG中频道订阅的情况。 它可以 是以表的方式保存在服务器端。 以服务器来同步终端。

A 定购的方式可以是外部的： 例如通过上网或拨打电话的方式 来完成。 定购的结果会记录到服务器上；

B 也可以是内部的： 通过终端在 SG上进行定购。 每当终端定 购或退定一个频道， 服务器上的定购关系表都会进行一次修改， 并随 后同步给终端。

C 定购关系可以是服务器向终端同步， 服务器会在终端启动时 将定购关系与 online状态的用户进行同步，也可根据服务器策略定期 同步； 定购关系也可以是终端来维护， 向服务器进行同步， 当用户进 行定购以后，本地的定购关系会通过 HTTP的 POST方式发到服务器 上与服务器同步。

用户接入频道后可以接收 SG。 SG 中有频道内容的预告。 通过 SG, 终端可以获得相关的频道列表， 并根据该频道列表提供的频道 接收节目内容。

如果釆用广播接收的方式， 终端根据之前收到的手机频道导航

SG, 选择希望收看的频道。 通过 SG上显示的频道标识， 用户终端在 选择后， 终端会开始节目的接收。

步骤 s204, 服务器端向终端发送节目内容。

服务器可以釆用广播的方式将内容发送出去，也可以用流媒体的 方式发送内容。

如果终端在接收到节目内容一段时间后（可以设定为 1分钟）没 有退出， 那么该信息就将被发送到服务器。服务器可以记录终端接入 时间。

终端侧接入到频道后的处理首先要在本地记录当前的状态信息， 规定的一段时间可以是网络设定的， 也可以是内容提供商设定的。 该 时间被终端用来判定是否要向服务器发送统计信息。如果终端接入频 道的时间超过了该设定时间， 则可以认为用户是在观看节目； 否则， 如果在这段时间内终端退出了该频道，则认为用户没有收看该频道节 。

步骤 s205 , 服务器对终端进行鉴权。

鉴权消息的内容可以如下所示：

HTTP/1.1 401 Unauthorized

Server: Microsoft-IIS/5.1

WWW- Authenticate: Digest

realm="testrealm(¾host.com" ,

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

opaque="5ccc069c403ebaf f0171e9517f40e41"

<CR> 服务器收到终端发来的 POST消息， 对终端要进行一次认证， 服 务器会发质询给终端。所谓"发出质询"，就是给客户端发送一个 HTTP 响应， 其状态码为 401 (Unauthorized) , 并且包含消息头 WWW-Authenticate , 客户端看到这个响应就知道这个 URI ( Uniform Resource Identifier, 通用资源标志符） 需要认证。

domain: 一个 URI 列表， 指示要保护的域。 可能是一个列表， 提示用户这些 URI釆用一样的认证， 如果为空或忽略则为整个服务 哭口

nonce: 随机字符串， 每次 401 都不一样。 跟算法有关。 算法类 i^X Base64力口密： time-stamp H(time-stamp "： " ETag "： " private-key) 。 time-stam 为服务器时钟， ETag为请求的 Etag头。

opaque : 服务器产生的由客户发送请求时原样返回。 最好是 Base64 串或十六进制字符串。 realm-value是一个两端加引号的大小 写相关的字符串， 表示要求认证的"领域（realm ) "。 领域是由服务器 自己决定的， 不同的服务器可以设置自己的领域， 同一个服务器也可 以有多个领域。质询中包含领域信息是为了让客户端知道哪个范围的 用户名是合法的。 服务器对终端进行鉴权的消息可以没有消息体。

服务器为了获得终端接入用户的身份，需要对终端刚接入时或切 换节目或频道时进行认证。 这个认证与用户注册时认证目的不同， 这 个对接入用户的认证可以保证观看节目的用户为接入用户，可以保证 收视率统计的客观性。 认证的方式有多种， 例如 HTTP的摘要认证方 式。

服务器接收到用户发来的 Loglnlnfo , 在将该消息中的数据写入 数据库前， 为了确定接入节目的用户的身份，及 Loglnlnfo的合理性， 必须对用户进行一次认证。 因为用户在发送 Loglnlnfo的时候不知道 是否认证， 因此服务在收到 Loglnlnfo时会发送一个 HTTP的 401消 息， 该消息包括了一个挑战（challenge ), challenge 需要用户名及密 码等相关认证信息以加密的方式发到服务器。 步骤 S206 , 终端向服务器发送一个对认证的响应。

响应消息的内容可以如下所示：

Authorization: Digest username="Mufasa",

realm="testrealm(¾host.com" ,

nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

qop=auth,

nc=00000001,

cnonce="0a4fl l3b",

response="6629fae49393a05397450978507c4efl ",

opaque="5ccc069c403ebaf f0171e9517f40e41" 终端在收到 Challenge 消息后会将自 己的用户名及密码和 Challenge一起加密传给服务器。 这样的好处是可以不用明文发送密 码。

当认证成功后服务器会保持之前终端的接收；如果终端认证未通 过， 用户也可以继续观看节目， 但对于服务器统计 Loglnlnfo是无效 的。

步骤 s201 -s206为标准的 HTTP摘要认证的方式， 其中的各字段 可参考 RFC2617。 摘要认证的方法在这里只是举例说明。

步骤 s207 , 服务器发送 200 OK消息到终端。

终端的用户名及密码通过服务器的认证， 服务器发送 200 Ok到 终端； 本实施例中是以 HTTP方式举例说明， 因此这里用 200 OK表 示认证成功。

步骤 s208, 服务器向终端正常发送节目内容。

终端接入到频道后如果不在规定的时间内退出，继续接收节目内 容， 则服务器可以釆用广播发送的方式， 也可以釆用其它的发送方式 发送节目内容。 如果服务器釆用广播的方式发送节目内容， 终端从该 频道的广播中接收内容。 如果釆用其它方式（例如流媒体）， 服务器 可以在与终端建立的链路上发送内容。 对于流媒体方式可以用单播， 也可以用组播发送节目内容；

步骤 S209 , 终端退出当前观看的节目。

退出消息的内容可以如下所示：

Http/1.1200OK

Server:Microsoft-IIS/5.0

Date:Sat,20Jul200720:31 :22GMT

Accept-Ranges:bytes

Content-Length: 1205

Content- Type： text/html

Options :Post

Loglnlnfo

用户退出当前观看节目的时间是任意的， 可以在节目结束后， 也 可以在播放途中退出。当用户退出后将触发终端发送状态消息到服务 器。

步骤 s210, 终端发送一条 LogOutlnfo消息到服务器。

LogOutlnfo消息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:55:22GMT

Accept-Ranges:bytes

Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www. sam . com :8080

Connection: close

<CR>

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- > <LogReport

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\Documents and Settings\Administrator\桌面 \Edit3.xsd">

<Message— Type Message— Type— Type="LogOutInfo"/>

<User_ID User_ID_Type="abc"/>

<Service_ID Service— ID— Type="01 "/>

<Program_ID Program— ID— Type=" 11 "/> 本实施例用 HTTP的 POST方法将 LogOutlnfo的 XML数据信息 发到服务器上， POST 消息中的含义与第 4 步相同。 LogOutlnfo 的 XML形式数据为消息体。

该消息包括了 Service ID、 User ID ,服务器记录终端退出时间 End Time。 终端的 LogOutlnfo消息具有某种格式， 例如如图 3所示。 消 息的发送是通过交互信道完成的。 保存 LogOutlnfo 消息的服务器可 以是交互服务器， 也可以是专门用来记录统计数据的服务器。

LogOutlnfo消息可以用 HTTP方式将消息带到服务器由服务器来 完成处理并加入数据库中， 也可以用 SMS(Short Message Service, 短 消息业务)或其它方式。本例中通过 HTTP POST方法将消息带到服务 器的方式只是举例说明， 也可以用其它的承载手段代替， 但所涉及的 原理和思想是一致的。

步骤 s211 , 服务器正确接收的 LogOutlnfo消息后， 返回 200 OK 消息给终端。

返回应答可以通过交互信道， 也可以通过其它的方式。 本例中用 200 OK代表发送内容成功到达。 在不同的网络环境中也可以釆用其 它的应答方式， 所涉及的思想和原理都是一样的。

步骤 s212,服务器在终端退出节目后，对终端的状态信息进行保 存。

服务器将终端上报的 Loglnlnfo和 LogOutlnfo状态信息加入到本 地数据库中或保存在其它的服务器中。 服务器从 Loglnlnfo 和 LogOutlnfo消息中获得需要的数据。根据这些数据，服务器可以对终 端的订阅以及观看节目的情况有基本的了解。服务器数据库中保存的 状态信息可以是与表 4统计表相同或类似。

手机终端在收看某频道节目内容的时候，比较可行的方式是通过

SG, 呈现出频道列表， 终端可以选择一个频道的节目进入观看。 当 终端通过 SG提供的频道列表接入频道观看时， 终端会记录下当前接 入的用户管理信息， 包括接入的 User ID、 Service ID、 Program ID等。 当终端接入该频道的一个节目一定时间后 （例如一分钟）， 则可以认 为用户是在观看该节目， 此时终端需要将用户管理信息发送到服务 器。 当终端退出该频道或退出观看节目的时候， 终端会记录下当前退 出的用户管理信息， 包括接入的 User ID、 Service ID、 Program ID等。 该服务器可以是交互服务器也可以是专门用来记录终端信息的服务 例如 Loglnlnfo和 LogOutlnfo消息可以是如下表 1的数据结构形

本发明涉及到的终端与服务器间的消息类型 Loglnlnfo消息和 LogOutlnfo消息都是强制必须的消息。 方向都 是从终端到服务器。

Loglnlnfo和 LogOutlnfo消息的数据结构组成如下表 2和 3所示：

Message-Type Mandatory String 消息类型标识" Loglnlnfo"

User ID Mandatory String 终端用户 ID

Service ID Mandatory String 业务的 ID ( i.e Channel ID )

Program ID Mandatory String 观看的节目 ID

Online state Mandatory String 在线状态

IMSI Mandatory String 客户识别码（IMSI )

Channel stat Mandatory String 频道标识， 用来标帜该频道 的统计情况 表 2 Loglnlnfo消息组成

表 3 LogOutlnfo消息组成

用 schema表示该数据结构 ¾口下：

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- >

<xs： schema xmlns :xs="http：〃 www. w3. org/2001 /XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs: element name="LogReport" type="LogReportType'7> <xs： complexType name="LogReportType">

<xs:sequence>

<xs: element name="Message_Type">

<xs： complexType>

<xs： attribute name="Message_Type_Type" use="required">

<xs:simpleType>

<xs： restriction base="xs： NMTOKEN"> <xs: enumeration value="LogOutInfo'7> <xs: enumeration value="LogInInfo"/> </xs:restriction>

</xs： simpleType>

</xs:attribute>

</xs:complexType>

</xs:element>

<xs: element name="User_ID">

<xs： complexType>

<xs： attribute name="User_ID_Type" type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Service_ID">

<xs： complexType>

<xs： attribute name=" Service— ID— Type " type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Program_ID">

<xs： complexType> <xs： attribute name="Program_ID_Type type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Online_state">

<xs： complexType>

<xs： attribute name: ' ' Online— state— Type type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="IMSI">

<xs： complexType>

<xs: attribute name="IMSI_Type" type="xs:string use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Channel_stat">

<xs： complexType>

<xs: attribute name="Channel— stat— Type type="xs: string" use="required"/>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:schema> 以上的消息都由终端发送到服务器， 并由服务器保存。 在服务器 侧也可以构造一个类似下面的数据结构来保存需要记录的状态信息。 如下表 4所示： User ID Service ID Program ID StartTime EndTime

01234 01 Oil 10: 50 11 : 30

02462 01 Oil 10: 20 11 : 15

55208 02 021 12: 05 12: 25

04567 03 032 12: 00 12: 30

49653 02 021 12: 15 12: 25 表 4 统计表

该数据结构的 schema如下：

<?xml version:" 1.0" encoding="UTF-8 " ?>

<!-W3C Schema generated by XMLSPY v5 rel. 4 U (http://www.xmlspy.com)-->

<xs： schema xmlns :xs="http：〃 www. w3. org/2001 /XMLSchema" elementFormDefault="qualified">

<xs: element name="Stat">

<xs： complexType>

<xs: attribute name="User ID" type="xs: string use= required"/>

<xs： attribute name=" Service— ID " type="xs: string use= required"/>

<xs: attribute name="Program_ID type="xs: string use= required"/>

<xs: attribute name=" StartTime" type="xs: string use= required"/>

<xs: attribute name="EndTime" type="xs: string use= required"/>

</xs:complexType>

</xs:element> </xs:schema>

该表中模拟了一些数据来表示在服务器侧保存的信息内容。本例 中每一个用户都有一个唯一的 User ID, 对于不同的频道也有不同的 Service ID, 例如上表中 User ID为 01234的用户与 User ID为 02462 的用户都在观看 Service ID为 01的频道， 所看节目内容相同， 他们 观看的节目 Program ID为 011。他们的观看时间分别从 10: 50和 10: 20开始。 User ID为 55208的用户和 User ID为 49653的用户都在观 看 Service ID为 02的频道， 说观看的节目也相同， 都是 Program ID 为 021 , 但是前者 12: 05接入观看， 而后者从 12: 15开始观看， 节 目结束后他们都停止了观看， 因此 EndTime都是 12: 25。

服务器上保存记录形式可以多样， 本方案只是举例说明， 可以用 其它的数据结构组织这些统计数据，但所涉及的思想与方法都是相同 的。

表 4中一个频道对应一个服务器。同一时间相同频道只有一个节 目。 Service ID、 Program ID由提供节目的内容提供商规定。 也可以 是一个频道在一段时间内只提供一个节目给用户观看。 User ID、 Service ID、 Program ID, EndTime、 StartTime这些属性只是举例说明 终端观看节目的状态信息， 如果需要可以进行修改与扩展。

本实施例中的服务器可以是互动服务器，也可以是专门用来保存 统计信息的服务器。由于本实施例中的消息相对内容少，数据易统计， 因此对服务器的负担小。 此外， 对于本例中的服务器， 如果能够支持 一定量的用户数量，增加这样的统计后并不会对支持的用户数有太多 的改变。

本实施例中所涉及的发送用户管理信息的消息 Loglnlnfo、 LogOutlnfo只是举例说明，其他类似携带状态信息的消息方法也可以 完成状态信息的发送， 所涉及的原理与思想都是一致的。

本发明的实施例三提供了一种将终端接入节目频道（ Login ) 和 终端退出播放节目 （Logout )时将用户管理信息发送到服务器， 由服 务器根据用户管理信息对节目或用户偏好做统计的方法。该方法可以 为服务器进一步掌握终端接收节目和频道的情况提供手段。

请参照流程图图 3 , 该方案的实施思想主要在于， 当终端用户收 看某一时段的节目时， 终端会接入（Login )到播放该节目的频道。 当终端接收节目达到一定时间后，终端的用户管理信息， 包括 Service ID、 节目标识 Program ID、 User ID和 Channel ID等信息会被终端发 送到服务器。 用户管理信息可以以消息的方式发送到服务器上。服务 器会根据本地策略判断是否要接收到的终端用户管理信息并进行保 存， 做出相应的回答。 当终端退出 （Logout )接收节目后， 还会与服 务器进行一次交互：终端将退出时的用户管理信息，包括， Service ID、 Program ID、 User ID和 Channel ID等信息发给服务器。

服务器根据退出的用户管理信息对保存的终端接入节目的情况 进行统计。 服务器可以根据记录的终端 Login和 Logout的时间算出 用户接入该节目的总时长， 服务器还会根据 User ID和 Service ID、 Program ID和 Channel ID统计出关注度最高的频道，以及关注度最高 的节目内容。根据这样的统计， 服务器可以对那些关注度高的频道和 节目增加更多的网络资源， 保证这些节目在用户观看时的观看质量； 内容提供商也可以根据这样的统计对提供的频道和节目做一定的调 整， 增加关注度高的节目的播放， 根据用户的兴趣开发节目。

本实施例具体流程如图 3所示， 步骤如下：

步骤 s301 , 终端启动， 并获取 SG。

手机电视终端接收频道节目的前提是该终端已经注册在服务器 上， 并且已经激活， 可以接入频道接收节目。

步骤 s302,未定购频道的终端才艮据获取的 SG重新建立频道定购。 确定的定购关系描述的是用户对 SG中频道订阅的情况。 它可以 是以表的方式保存在服务器端。 以服务器来同步终端。

A 定购的方式可以是外部的： 例如通过上网或拨打电话的方式 来完成。 定购的结果会记录到服务器上；

B 也可以是内部的： 通过终端在 SG上进行定购。 每当终端定 购或退定一个频道， 服务器的定购关系表都会进行一次修改， 并随后 同步给终端。

C 定购关系可以是服务器向终端同步， 服务器会在终端启动时 将定购关系与 online状态的用户进行同步，也可根据服务器策略定期 同步； 定购关系也可以是终端来维护， 向服务器进行同步， 当用户进 行定购以后，本地的定购关系会通过 HTTP的 POST方式发到服务器 上与服务器同步。

用户接入频道后可以接收 SG。 SG 中有频道内容的预告。 通过 SG终端可以获得相关的频道列表， 并根据该频道列表提供的频道接 收节目内容。

如果釆用广播接收的方式， 终端根据之前收到的手机频道导航 SG, 选择希望收看的频道。 通过 SG上显示的频道标识， 用户终端在 选择后， 终端会开始节目的接收。

步骤 s303 , 服务器端向终端发送节目内容。

服务器可以釆用广播的方式将内容发送出去，也可以用流媒体的 方式发送内容。

如果终端在接收到节目内容一段时间后（可以设定为 1分钟）没 有退出， 那么该信息就将被发送到服务器。服务器可以记录终端接入 时间。

终端侧接入到频道后的处理首先要在本地记录当前的用户管理 信息， 规定的一段时间可以是网络设定的， 也可以是内容提供商设定 的。 该时间被终端用来判定是否要向服务器发送统计信息。 如果终端 接入频道的时间超过了该设定时间， 则可以认为用户是在观看节目； 否则， 如果在这段时间内终端退出了该频道， 则认为用户没有收看该 频道节目。

步骤 s304, 终端向服务器发送 Loglnlnfo消息。

Loglnlnfo消息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:31 :22GMT

Accept-Ranges:bytes Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www.sample.com:8080

Connection: close

<CR>

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- >

<LogReport

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\Documents and Settings\Administrator\桌面 \Edit3.xsd">

<Message— Type Message— Type— Type="LogMnfo"/>

<User_ID User_ID_Type="abc"/>

<Service_ID Service— ID— Type="01 "/>

<Program_ID Program— ID— Type=" 11 "/> 本实施例中， Loglnlnfo 消息以 XML ( Extensible Markup Language ,可扩展标记语言）的形式作为消息体加在 HTTP( Hyper Text Transfer Protocol,超文本传输协议） POST头的后面，带到服务器上。 消息头和消息体间用回车 <0 >间隔开， 回车上面的为消息头， 下面 的为消息体。消息头中描述了要请求的主机和端口，连接方式为 close , 表示不必持续连接， HTTP1.1支持非持续连接。

Loglnlnfo消息包括了 Service ID、 User ID (例如： IMSI信息）、 以及其它接入状态信息。 终端的 Loglnlnfo消息具有某种格式， 例如 如图 2所示。 消息的发送是通过交互信道完成的。 保存 Loglnlnfo消 息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服 务器。 本实施例中 Loglnlnfo以 html的形式发送到服务器上。 发送 Loglnlnfo的方法可以是通过多种方法， 例如 HTTP POST 方法。 这里只是举例说明， 如有其它方式可以替代， 其原理与思想是 一致的。

终端接收节目达到一定时间后， 会将 Login的消息 Loglnlnfo上 报给服务器， 同时服务器将该用户状态制成 online。 终端到服务器上 取 SG以及其他相关数据。 而当服务器上的这些相关数据有更新的时 候， 此时服务器可以向已经在线的用户进行数据更新的通知 Push消 息发送给 online的终端， 则终端可以及时感知服务器上的数据变化， 及时取回数据。

步骤 s305 , 服务器对终端进行鉴权。

鉴权消息的内容可以如下所示：

HTTP/1.1 401 Unauthorized

Server: Microsoft-IIS/5.1

WWW- Authenticate: Digest

realm="testrealm(¾host.com",

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

opaque="5ccc069c403ebaf f0171e9517f40e41"

<CR> 服务器收到终端发来的 POST消息， 对终端要进行一次认证， 服 务器会发质询给终端。所谓"发出质询"，就是给客户端发送一个 HTTP 响应， 其状态码为 401 (Unauthorized) , 并且包含消息头 WWW-Authenticate , 客户端看到这个响应就知道这个 URI ( Uniform Resource Identifier , 通用资源标志符 ) 需要认证。

domain: 一个 URI 列表， 指示要保护的域。 可能是一个列表， 提示用户这些 URI釆用一样的认证， 如果为空或忽略则为整个服务 哭口

nonce: 随机字符串， 每次 401 都不一样。 跟算法有关。 算法类 i^X Base64力口密： time-stamp H(time-stamp "： " ETag "： " private-key) 。 time-stam 为服务器时钟， ETag为请求的 Etag头。

opaque : 服务器产生的由客户发送请求时原样返回。 最好是 Base64 串或十六进制字符串。 realm-value是一个两端加引号的大小 写相关的字符串， 表示要求认证的"领域（ realm ) "。 领域是由服务器 自己决定的， 不同的服务器可以设置自己的领域， 同一个服务器也可 以有多个领域。质询中包含领域信息是为了让客户端知道哪个范围的 用户名是合法的。 服务器对终端进行鉴权的消息可以没有消息体。

服务器为了获得终端接入用户的身份， 需要对终端进行一次认 证。 这个认证与用户注册时认证目的不同， 这个对接入用户的认证可 以保证观看节目的用户为接入用户， 可以保证收视率统计的客观性。 认证的方式有多种， 例如 HTTP的摘要认证方式。

服务器接收到用户发来的 Loglnlnfo , 在将该消息中的数据写入 数据库前， 为了确定接入节目的用户的身份，及 Loglnlnfo的合理性， 必须对用户进行一次认证。 因为用户在发送 Loglnlnfo的时候不知道 是否认证， 因此服务在收到 Loglnlnfo时会发送一个 HTTP的 401消 息， 该消息包括了一个挑战（challenge ), challenge 需要用户名及密 码等相关认证信息以加密的方式发到服务器。

步骤 s306 , 终端向服务器发送一个对认证的响应；

响应消息的内容可以如下所示：

Authorization: Digest username="Mufasa",

realm="testrealm(¾host.com" ,

nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

qop=auth,

nc=00000001 ,

cnonce="0a4fl l3b",

response="6629fae49393a05397450978507c4efl ",

opaque="5ccc069c403ebaf f0171e9517f40e41 " 终端在收到 Challenge 消息后会将自 己的用户名及密码和 Challenge一起加密传给服务器。 这样的好处是可以不用明文发送密 码。

当认证成功后服务器会保持之前终端的接收；如果终端认证未通 过， 用户也可以继续观看节目， 但对于服务器统计 Loglnlnfo是无效 的。

步骤 s301-s306为标准的 HTTP摘要认证的方式， 其中的各字段 可参考 RFC2617。 摘要认证的方法在这里只是举例说明。

步骤 s307 , 服务器发送 200 OK消息到终端。

终端的用户名及密码通过服务器的认证， 服务器发送 200 Ok到 终端； 本实施例中是以 HTTP方式举例说明， 因此这里用 200 OK表 示认证成功。

步骤 s308, 服务器向终端正常发送节目内容；

终端接入到频道后如果不在规定的时间内退出，继续接收节目内 容， 则服务器可以釆用广播发送的方式， 也可以釆用其他的发送方式 发送节目内容。 如果服务器釆用广播的方式发送节目内容， 终端从该 频道的广播中接收内容。 如果釆用其它方式（例如流媒体）， 服务器 可以在与终端建立的链路上发送内容。 对于流媒体方式可以用单播， 也可以用组播发送节目内容；

步骤 s309, 终端退出当前观看的节目。

用户退出当前观看节目的时间是任意的， 可以在节目结束后， 也 可以在播放途中退出。当用户退出后将触发终端发送状态消息到服务 器。

步骤 s310, 终端发送一条 LogOutlnfo消息到服务器。

LogOutlnfo消息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:55:22GMT

Accept-Ranges:bytes Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www. sam . com :8080

Connection: close

<CR>

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- >

<LogReport

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\Documents and Settings\Administrator\桌面 \Edit3.xsd">

<Message— Type Message— Type— Type="LogOutInfo"/>

<User_ID User_ID_Type="abc"/>

<Service_ID Service— ID— Type="01 "/>

<Program_ID Program— ID— Type=" 11 "/> 本实施例用 HTTP的 POST方法将 LogOutlnfo的 XML数据信息 发到服务器上， POST 消息中的含义与第 4 步相同。 消息体为 LogOutlnfo的 XML形式数据。

该消息包括了 Service ID、 User ID、 以及当前退出时间 EndTime 等。 终端的 LogOutlnfo消息具有某种格式， 例如如图 3所示。 消息 的发送是通过交互信道完成的。 保存 LogOutlnfo 消息的服务器可以 是交互服务器， 也可以是专门用来记录统计数据的服务器。

LogOutlnfo消息可以用 HTTP方式将消息带到服务器由服务器来 完成处理并加入数据库中， 也可以用 SMS或其它方式。 本例中通过 HTTP POST方法将消息带到服务器的方式只是举例说明， 也可以用 其它的承载手段代替， 但所涉及的原理和思想是一致的。 步骤 s311 , 当服务器正确接收的 LogOutlnfo消息后返回 200 OK 消息给终端。

返回应答可以通过交互信道， 也可以通过其它的方式。 本例中用 200 OK代表发送内容成功到达。 在不同的网络环境中也可以釆用其 它的应答方式， 所涉及的思想和原理都是一样的。

步骤 s312, 服务器在终端退出节目后对终端的状态信息进行保 存， 并进行统计。

服务器根据终端上报的 Loglnlnfo和 LogOutlnfo状态信息进行频 道的收视率统计或节目的收视率统计；

收视率统计的两种方式：

A SG 中可以包括频道标识， 这样当服务器需要对某时间段的 某个频道做收视率统计的时候， 可以在 SG中该频道设置需要进行收 视率统计的标识， 例如 CCTV2 stat = TRUE 2007-08-09 12: 00 ~ 13: 00, 表明 CCTV2这个频道在 2007-08-09 12: 00 ~ 13: 00, 如果用户 选择的该频道， 则需要向服务器发送消息， 以表明该用户正在收看或 收看结束这样动作， 服务器以此来进行收视率的统计， 或进行其他相 关的统计操作。

B 另一种收视率统计的方式是： 服务器向目前在线的所有用户 或其中一部分用户终端发送消息，要求该用户反馈当前是否在收看该 频道， 用户终端回复该消息， 并携带相关信息 ， 以表明对该服务器 请求的答复， 这样可以实现服务器上进行相关数据的统计工作；

并且可以统计该用户对节目的偏好。服务器从记录的终端观看节 目的 StartTime与 EndTime得出该用户观看节目的总时长。 根据不同 用户观看的节目， 可以统计出哪个 Program ID的参与用户人数最多， 也可以统计出哪个 Service ID的接入人数最多。 同时服务器可以根据 用户以前保存在服务器上的数据， 对用户的偏好做出统计， 可以查找 出该用户参与最多的 Program ID和 Service ID是哪些。根据这些数据， 内容提供商可以为该用户提供类似于包月的服务。用户保存在服务器 上的状态信息可以是类似表 8的形式。 手机终端在收看某频道节目内容的时候，比较可行的方式是通过

SG,通过 SG所呈现出来的频道列表， 终端可以选择一个频道进入观 看。 当终端通过 SG提供的频道列表接入频道观看时， 终端会记录下 当前接入的用户管理信息， 包括接入的 User ID、 Service ID, Program ID等。 当终端接入该频道的一个节目一定时间后（例如一分钟）， 则 可以认为用户是在观看该节目，此时终端需要将用户管理信息发送到 服务器。 当终端退出该频道或退出观看节目的时候， 终端会记录下当 前退出的用户管理信息， 包括接入的 User ID、 Service ID、 Program ID 等。该服务器可以是交互服务器也可以是专门用来记录终端信息的服 务器。例如 Loglnlnfo和 LogOutlnfo消息的定义数据结构形式如下表 5所示。

表 5 本发明涉及到的终端与服务器间的消息类型 Loglnlnfo消息和 LogOutlnfo消息都是强制必须的消息。 方向都 是从终端到服务器。

Loglnlnfo和 LogOutlnfo消息的数据组成入下表 6和 7所示：

IMSI Mandatory String 客户识别码（IMSI )

Channel stat Mandatory String 频道标识， 用来标帜该频道 的统计情况 表 6 Loglnlnfo消息组成

Information Req Type Description

Element

Message-Type Mandatory String 消息类型标识" Loglnlnfo"

User ID Mandatory String 终端用户 ID

Service ID Mandatory String 业务的 ID ( i.e Channel ID )

Program ID Mandatory String 观看的节目 ID

Online state Mandatory String 在线状态

IMSI Mandatory String 客户识别码 ( IMSI )

Channel stat Mandatory String 频道标识， 用来标帜该频道的 统计情况

表 7 LogOutlnfo消息组成

用 schema表示该数据结构：

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- >

<xs： schema xmlns :xs="http：〃 www. w3. org/2001 /XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs: element name="LogReport" type="LogReportType'7>

<xs： complexType name="LogReportType">

<xs:sequence>

<xs: element name="Message_Type">

<xs： complexType>

<xs： attribute name="Message_Type_Type" use="required">

<xs:simpleType>

<xs： restriction base="xs： NMTOKEN"> <xs: enumeration value="LogOutInfo'7> <xs: enumeration value="LogInInfo"/> </xs:restriction>

</xs： simpleType>

</xs:attribute>

</xs:complexType>

</xs:element>

<xs: element name="User_ID">

<xs： complexType>

<xs： attribute name="User_ID_Type" type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Service_ID">

<xs： complexType>

<xs： attribute name=" Service— ID— Type " type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Program_ID">

<xs： complexType>

<xs： attribute name="Program_ID_Type" type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Online state "> <xs： complexType>

<xs： attribute name: ' ' Online— state— Type type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="IMSI">

<xs： complexType>

<xs: attribute name="IMSI_Type" type="xs:string use="required"/>

</xs:complexType>

</xs:element>

<xs: element name="Channel_stat">

<xs： complexType>

<xs: attribute name="Channel— stat— Type type="xs： string" use="required"/>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:schema> 以上的消息都由终端发送到服务器， 并由服务器保存。 在服务器 侧也可以构造一个类似下面的数据结构来保存需要记录的状态信息 (用户管理信息）：

55208 02 21 12:05 12:25 20m

4567 03 32 12:00 12:30 30m

49653 02 21 12:15 12:25 10m 表 8 统计表

该数据结构的 schema如下：

<?xml version:" 1.0" encoding="UTF-8 " ?>

<!-W3C Schema generated by XMLSPY v5 rel. 4 U (http://www.xmlspy.com)-->

<xs： schema xmlns :xs="http：〃 www. w3. org/2001 /XMLSchema" elementFormDefault="qualified">

<xs: element name="Stat">

<xs： complexType>

<xs: attribute name="User_ID" type="xs: string use="required"/>

<xs： attribute name=" Service— ID " type="xs: string use="required"/>

<xs: attribute name="Program_ID type="xs: string use="required"/>

<xs: attribute name="StartTime" type="xs: string use="required"/>

<xs: attribute name="EndTime" type="xs: string use="required"/>

</xs:complexType>

</xs:element>

</xs:schema> 上表 8中模拟了一些数据来表示在服务器侧保存的信息内容。本 例中每一个用户都有一个唯一的 User ID, 对于不同的频道也有不同 的 Service ID,例如上表中 User ID为 01234的用户与 User ID为 02462 的用户都在观看 Service ID为 01的频道， 所看节目内容相同， 他们 观看的节目 Program ID为 011。他们的观看时间分别从 10: 50和 10: 20开始。 User ID为 55208的用户和 User ID为 49653的用户都在观 看 Service ID为 02的频道， 说观看的节目也相同， 都是 Program ID 为 021 , 但是前者 12: 05接入观看， 而后者从 12: 15开始观看， 节 目结束后他们都停止了观看， 因此 EndTime都是 12: 25。 Time属性 为该用户收看节目的时长，从表中可以看出 55208用户和 49653用户 的观看节目时长是一致的。

服务器上保存记录形式可以多样， 本方案只是举例说明， 可以用 其它的数据结构组织这些统计数据，但所涉及的思想与方法都是相同 的。

表 8中一个频道对应一个服务器。同一时间相同频道只有一个节 目。 Service ID、 Program ID由提供节目的内容提供商规定。 也可以 是一个频道在一段时间内只提供一个节目给用户观看。 User ID、 Service ID、 Program ID, EndTime、 StartTime这些属性只是举例说明 终端观看节目的状态信息， 如果需要可以进行修改与扩展。

StartTime和 EndTime是服务器记录的终端接入和退出频道时的 时间， 该时间是终端记录当前播发的节目内容的时间， Time 为二者 差值， 表示用户连续观看该节目的时长。 因为每个节目内容都是由服 务器以数据包的形式一帧一帧的发送到终端的，每一帧都会有一个时 间戳信息， 这个时间戳是由服务器加上的， 因此可以从第一帧的数据 包中提取接入时间， 从最后一帧提取退出时间， 所得差值为终端接入 频道的持续时长。 数据包的时间是与终端本地时间无关的网络时间， 由服务器决定，因此无论终端本地时间是否准确都不会影响终端接入 频道的时长。 这样的时间记录对于统计用户观看时间是比较合理的， 基本可以保证记录时间就是观看时间。并且对于服务器而言能够获得 比较准确的统计。

本实施例中的服务器可以是互动服务器，也可以是专门用来保存 统计信息的服务器。由于本实施例中的消息相对内容少，数据易统计， 因此对服务器的负担小。 此外， 对于本例中的服务器， 如果能够支持 一定量的用户数量，增加这样的统计后并不会对支持的用户数有太多 的改变。

本实施例中所涉及的发送用户管理信息 （状态信息） 的消息

Loglnlnfo, LogOutlnfo只是举例说明，其他类似携带用户管理信息的 消息方法也可以完成状态信息的发送，所涉及的原理与思想都是一致 的。

本发明的实施例四提供了一种将终端接入节目频道（ Login ) 和 终端退出播放节目 （Logout )时将用户管理信息发送到服务器， 由服 务器才艮据用户管理信息完成与终端的交互更新的方法。用户成功订阅 了频道后， 在观看一个频道的过程中可能会参与节目的互动， 例如互 动话题的讨论， 互动游戏等等。 通过终端与服务器的交互更新可以达 到在本地终端就能同时完成节目观看与互动参与的效果。

请参照流程图图 3 , 该方案的主要思想在于， 终端在接入观看一 个节目的过程中， 如果该节目中有互动参与的部分， 那么服务器可以 给终端发送该节目互动信息，如果在该节目的播放过程中互动信息发 生了更新，那么服务器可以根据终端的状态信息将互动的更新信息发 给终端。通常在观看一个互动节目的时候会有互动信息的下发与更新 两种情况， 互动信息可以与节目内容一起下发到终端， 但是互动信息 的类型在一个节目当中的形式等都会是一致的，因此只要对节目的互 动信息进行更新， 用户就可以不断的参与到该互动节目中来。 而这样 的互动信息的更新是根据终端发给服务器的状态信息进行发送的。

实施例四的具体流程如图 4所示， 步骤如下：

步骤 s401 , 终端启动， 并向服务器发送 Loglnlnfo消息。

Loglnlnfo消息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:31 :22GMT

Accept-Ranges:bytes Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www.sample.com:8080

Connection: close

<CR>

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- >

<LogReport

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\Documents and Settings\Administrator\桌面 \Edit3.xsd">

<Message— Type Message— Type— Type="LogMnfo"/>

<User_ID User_ID_Type="abc"/>

<Service_ID Service— ID— Type="01 "/>

<Program_ID Program— ID— Type=" 11 "/> 本实施例中， Loglnlnfo 消息以 XML ( Extensible Markup Language ,可扩展标记语言）的形式作为消息体加在 HTTP( Hyper Text Transfer Protocol,超文本传输协议） POST头的后面，带到服务器上。 消息头和消息体间用回车 <0 >间隔开， 回车上面的为消息头， 下面 的为消息体。消息头中描述了要请求的主机和端口，连接方式为 close , 表示不必持续连接， HTTP1.1支持非持续连接。

Loglnlnfo消息包括了 Service ID、 User ID (例如： IMSI信息）， 以及其他接入状态信息。 终端的 Loglnlnfo消息具有某种格式， 例如 如图 2所示。 消息的发送是通过交互信道完成的。 保存 Loglnlnfo消 息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服 务器。 本实施例中 Loglnlnfo以 html的形式发送到服务器上。 发送 Loglnlnfo的方法可以是通过多种方法， 例如 HTTP POST 方法。 这里只是举例说明， 如有其它方式可以替代， 其原理与思想是 一致的。

终端启动时会将 Login的消息 Loglnlnfo上报给服务器， 同时服 务器将该用户状态制成 online。 终端到服务器上取 SG以及其他相关 数据。 而当服务器上的这些相关数据有更新的时候， 此时服务器可以 向已经在线的用户进行数据更新的通知 Push消息发送给 online的终 端， 则终端可以及时感知服务器上的数据变化， 及时取回数据。

步骤 s402, 终端获取 SG。

手机电视终端接收频道节目的前提是该终端已经注册在服务器 上， 并且已经激活， 可以接入频道接收节目。

步骤 s403 ,未定购频道的终端才艮据获取的 SG重新建立频道定购。 确定的定购关系描述的是用户对 SG中频道订阅的情况。 它可以 是以表的方式保存在服务器端。 以服务器来同步终端。

A 定购的方式可以是外部的： 例如通过上网或拨打电话的方式 来完成。 定购的结果会记录到服务器上；

B 也可以是内部的： 通过终端在 SG上进行定购。 每当终端定 购或退定一个频道， 服务器上的定购关系表都会进行一次修改， 并随 后同步给终端。

C 定购关系可以是服务器向终端同步， 服务器会在终端启动时 将定购关系与 online状态的用户进行同步，也可根据服务器策略定期 同步； 定购关系也可以是终端来维护， 向服务器进行同步， 当用户进 行定购以后，本地的定购关系会通过 HTTP的 POST方式发到服务器 上与服务器同步。

用户接入频道后可以接收 SG。 SG 中有频道内容的预告。 通过 SG终端可以获得相关的频道列表， 并根据该频道列表提供的频道接 收节目内容。

如果釆用广播接收的方式， 终端根据之前收到的手机频道导航 SG, 选择希望收看的频道。 通过 SG上显示的频道标识， 用户终端在 选择后， 终端会开始节目的接收。

步骤 S404 , 服务器向终端发送节目内容。

服务器可以釆用广播的方式将内容发送出去，也可以用流媒体的 方式发送内容。

如果终端在接收到节目内容一段时间后（可以设定为 1分钟）没 有退出， 那么该信息就将被发送到服务器。服务器可以记录终端接入 时间。

终端侧接入到频道后的处理首先要在本地记录当前的状态信息， 规定的一段时间可以是网络设定的， 也可以是内容提供商设定的。 该 时间被终端用来判定是否要向服务器发送统计信息。如果终端接入频 道的时间超过了该设定时间， 则可以认为用户是在观看节目； 否则， 如果在这段时间内终端退出了该频道，则认为用户没有收看该频道节 。

步骤 s405 , 服务器对终端进行鉴权。

鉴权消息的内容可以如下所示：

HTTP/1.1 401 Unauthorized

Server: Microsoft-IIS/5.1

WWW- Authenticate: Digest

realm="testrealm(¾host.com" ,

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

opaque="5ccc069c403ebaf f0171e9517f40e41"

<CR> 服务器收到终端发来的 POST消息， 对终端要进行一次认证， 服 务器会发质询给终端。所谓"发出质询"，就是给客户端发送一个 HTTP 响应， 其状态码为 401 (Unauthorized) , 并且包含消息头 WWW-Authenticate , 客户端看到这个响应就知道这个 URI ( Uniform Resource Identifier, 通用资源标志符） 需要认证。 domain: 一个 URI 列表， 指示要保护的域。 可能是一个列表， 提示用户这些 URI釆用一样的认证， 如果为空或忽略则为整个服务 哭口

nonce: 随机字符串， 每次 401 都不一样。 跟算法有关。 算法类 i^X Base64力口密： time-stamp H(time-stamp "： " ETag "： " private-key) 。 time-stam 为服务器时钟， ETag为请求的 Etag头。

opaque : 服务器产生的由客户发送请求时原样返回。 最好是 Base64 串或十六进制字符串。 realm-value是一个两端加引号的大小 写相关的字符串， 表示要求认证的"领域（realm ) "。 领域是由服务器 自己决定的， 不同的服务器可以设置自己的领域， 同一个服务器也可 以有多个领域。质询中包含领域信息是为了让客户端知道哪个范围的 用户名是合法的。 服务器对终端进行鉴权的消息可以没有消息体。

服务器为了获得终端接入用户的身份， 需要对终端进行一次认 证。 这个认证与用户注册时认证目的不同， 这个对接入用户的认证可 以保证观看节目的用户为接入用户， 可以保证收视率统计的客观性。 认证的方式有多种， 例如 HTTP的摘要认证方式。

服务器接收到用户发来的 Loglnlnfo , 在将该消息中的数据写入 数据库前， 为了确定接入节目的用户的身份，及 Loglnlnfo的合理性， 必须对用户进行一次认证。 因为用户在发送 Loglnlnfo的时候不知道 是否认证， 因此服务在收到 Loglnlnfo时会发送一个 HTTP的 401消 息， 该消息包括了一个挑战（challenge ), challenge 需要用户名及密 码等相关认证信息以加密的方式发到服务器。

步骤 s406 , 终端向服务器发送一个对认证的响应；

响应消息的内容可以如下所示：

Authorization: Digest username="Mufasa",

realm="testrealm(¾host.com" ,

nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

qop=auth, nc=00000001,

cnonce="0a4fl l3b",

response="6629fae49393a05397450978507c4efl"

opaque="5ccc069c403ebaf f0171e9517f40e41" 终端在收到 Challenge 消息后会将自 己的用户名及密码和 Challenge一起加密传给服务器。 这样的好处是可以不用明文发送密 码。

当认证成功后服务器会保持之前终端的接收；如果终端认证未通 过， 用户也可以继续观看节目， 但对于服务器统计 Loglnlnfo是无效 的。

步骤 s401 -s406为标准的 HTTP摘要认证的方式， 其中的各字段 可参考 RFC2617。 摘要认证的方法在这里只是举例说明。

步骤 s407 , 服务器发送 200 OK消息到终端。

终端的用户名及密码通过服务器的认证， 服务器发送 200 Ok到 终端； 本实施例中是以 HTTP方式举例说明， 因此这里用 200 OK表 示认证成功。

步骤 s408, 服务器向终端发送节目内容及互动信息。

终端接入到频道后如果不在规定的时间内退出，继续接收节目内 容， 则服务器可以釆用广播发送的方式， 也可以釆用其它的发送方式 发送节目内容。 如果服务器釆用广播的方式发送节目内容， 终端从该 频道的广播中接收内容。 如果釆用其它方式（例如流媒体）， 服务器 可以在与终端建立的链路上发送内容。 对于流媒体方式可以用单播， 也可以用组播发送节目内容；

交互媒体文档及包含的交互媒体对象可以随节目内容一起下发， 也可以在收看节目内容之前下发。

步骤 s409, 服务器向终端发送互动更新。

当互动节目的互动信息发生改变时，服务器可以将互动信息的更 新发送到终端。 服务器在发送前需要根据终端上报的 Loglnlnfo信息 对终端的观看情况做出判断， 比如 Channel ID, User ID等， 有了这 些信息服务器才可以将互动更新准确的发给观看节目的用户；发送更 新的方法有很多种， 比如消息体的携带或者短消息等， 但是原理和思 想是一致的；

步骤 s410, 终端用户向服务器发送互动信息。

互动信息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:51 :22GMT

Accept-Ranges:bytes

Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www. sam . com :8080

Connection: close

<CR>

(用户互动信息） 当节目播放过程中出现互动参与时， 用户可以通过 HTTP POST 方法将节目互动过程中个人的选择以消息体的形式发送到服务器，也 可以在互动话题讨论的过程中以 SMS方式将讨论的内容发送到服务 器， 达到完成节目互动的目的。 用户编辑消息的过程可以是一个简单 的选择， 也可以是以文字描述的形式发表意见， 这些操作都不会影响 终端继续接收服务器发送的节目内容。因此在互动参与期间用户可以 不终断节目的观看就完成互动的操作。

步骤 s411 , 服务器收到用户发来的互动信息， 并进行处理。 互动服务器接收到用户发来的互动信息， 根据互动服务器的策 略， 可以将此信息进行实时的处理， 也可以在节目结束后处理。 互动 服务器会提取用户的互动信息， 并根据信息内容向用户发送互动内 容。 比如， 当用户在互动节目的选择中选择了 A 片段， 那么接下来 互动服务器会根据用户的互动选择播放 A片段。

步骤 s412 J良务器将当前处理完毕的互动参与结果连同节目内容 一起发送到终端。

用户可以在参与一次互动后就立刻将服务器处理的互动统计结 果发送到终端用户， 使终端用户可以立刻知道参与后的结果， 或当前 该互动节目的整体参与情况。因此发送的当前互动参与结果可以是用 户参与完毕后个人的结果， 也可以是当前所有参与者的整体参与结 果。

这样的互动过程在一个互动节目中可以有多次。本例中用虚线表 示返回的参与结果， 意味着参与结果可以返回给用户也可以不返回。 这是根据互动服务器及该互动节目的策略所制定。

步骤 s413 , 终端退出当前观看的节目。

用户退出当前观看节目的时间是任意的， 可以在节目结束后， 也 可以在播放途中退出。当用户退出后将触发终端发送状态消息到服务 器。

步骤 s414, 终端发送一条 LogOutlnfo消息到服务器。

LogOutlnfo消息的内容可以如下所示：

POST/HTTP/1.1

Date:Sat,20Jul200720:55:22GMT

Accept-Ranges:bytes

Accept-Language： zh-cn

Content-Length: 1205

Content- Type： text/xml

Host:host: www. sam . com :8080

Connection: close

<CR>

<?xml version:" 1.0" encoding="UTF-8 " ?>

<！— edited with XML SPY v5 rel. 4 U (http://www.xmlspy.com) by Registred (Registred) -- > <LogReport

xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\Documents and Settings\Administrator\桌面 \Edit3.xsd">

<Message— Type Message— Type— Type="LogOutInfo"/>

<User_ID User_ID_Type="abc"/>

<Service_ID Service— ID— Type="01 "/>

<Program_ID Program— ID— Type=" 11 "/> 本实施例用 HTTP的 POST方法将 LogOutlnfo的 XML数据信息 发到服务器上， POST消息中的含义与步骤 s404相同。 消息体的内容 为 LogOutlnfo的 XML形式的数据。

该消息包括了 Service ID、 User ID, 服务器此时可以记录当前退 出时间 EndTime。 终端的 LogOutlnfo消息具有一定的格式如图 7所 示。 消息的发送是通过互动信道完成的。 保存 LogOutlnfo 消息的服 务器可以是交互服务器， 也可以是专门用来记录统计数据的服务器。

LogOutlnfo消息可以用 HTTP POST方法将消息带到服务器由服 务器来完成处理并加入数据库中， 也可以用 SMS的承载方式。 本例 中通过 HTTP POST方法将消息带到服务器的方式只是举例说明， 也 可以用其它的承载手段代替， 但所涉及的原理和思想是一致的。

步骤 s415 ,当服务器正确接收的 LogOutlnfo消息后，返回 200 OK 消息给终端。

返回应答可以通过互动信道， 也可以通过其它的方式。 比如 Λ良务 器可以端对端的将应答发送的终端， 也可以 Push到终端。 本例中用 200 OK代表发送内容成功到达。 在不同的网络环境中也可以釆用其 它的应答方式， 所涉及的思想和原理都是一样的。

步骤 s416,服务器在终端退出节目后，对用户的互动信息进行保 存， 并根据互动节目中用户的参与进行统计。

服务器保存用户在互动节目中发送的互动信息，在节目完毕后对 用户的互动信息进行统计。 最后可以将统计的结果反馈给用户。 统计 的内容可以是节目的参与度或者该节目的整体互动的结果。 比如， 在 一个选择性的互动节目结束后， 互动服务器会统计选择 A 的观众与 选择 B的观众人数。这样的举例只是为了更明确的说明互动更新的结 果和形式。

步骤 s417 , 服务器将最终的互动节目统计结果发送给用户。 终端用户参与完毕一个节目后可以得到一个参与的结果，该结果 可以包括该终端用户的参与结果以及整体节目的参与结果。本实施例 用虚线表示最终结果的发送， 表示这一步是可选的。

通过终端在接收节目内容的过程中对互动节目的反馈，以及服务 器对用户的选择做出的相应可以达到互动更新的目的。本实施例中所 用到的消息承载以及消息发送方式只是举例，可以用其它的承载方式 及发送方式替代， 但其原理和思想是一致的。

本实施例中的 LogOutlnfo和 Loglnlnfo 消息可以保存在服务器 上， 用以对终端的节目观看信息进行统计。保存的数据结构形式可以 用与表 8类似或相同的表，该表可以保存在服务器上也可以保存在专 门用来记录统计结果的数据库中。

本发明的实施例五提供了一种手机电视业务中获取用户管理信 息的系统， 如图 5所示包括：

服务器 10, 用于向终端 20提供服务指南中包括的可选节目， 向 通过鉴权的终端 20发送终端 20选择的节目内容； 并根据终端 20发 送的用户管理信息， 存储终端 20的用户管理信息；

终端 20, 用于在启动时向服务器 10发送用户管理信息。

具体的， 服务器 10进一步包括：

接收模块 11 , 用于接收终端 20发送的用户管理信息； 鉴权模块 12 , 用于对请求收看节目的终端 20进行鉴权； 节目发送模块 13 , 用于向通过鉴权模块鉴权的终端 20发送终端 20选择的节目内容；

统计模块 14, 用于根据接收模块 11存储的内容获取终端 20的 用户管理信息.

节目订购模块 15 , 用于接受终端 20对服务指南中包括的可选节 目的订购或退订， 并根据订购或退订结果更新本地存储的终端 20订 购节目信息。

互动节目处理模块 16 , 用于进行互动节目中与终端 20的互动功 能的实现。

其中， 互动节目处理模块 16进一步包括：

互动信息添加子模块 161 ,用于将互动信息和 /或互动更新信息添 加到节目发送模块中并向终端 20发送；

互动响应接收子模块 162, 用于接收终端 20根据互动信息添加 子模块 171发送的互动信息和 /或互动更新信息返回的互动信息响应； 互动结果获取子模块 163 , 用于处理互动响应接收子模块 172接 收的互动信息响应， 处理得到终端 20的互动参与结果。

具体地， 终端 20进一步包括：

用户管理信息生成模块 21 , 用于生成用户管理信息，

用户管理信息发送模块 22 , 用于将生成的用户管理信息以消息 形式发送。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解 到本发明可借助软件加必需的通用硬件平台的方式来实现， 当然也可 以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解， 本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以 软件产品的形式体现出来， 该软件产品存储在一个存储介质中， 包括 以上公开的仅为本发明的几个具体实施例， 但是， 本发明并非局 限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护 范围。

Claims

权利要求

1、 一种获取用户管理信息的方法， 其特征在于， 包括： 接收终端发送的携带用户管理信息的消息；

从所述消息中获取所述终端的用户管理信息；

对所述用户管理信息进行信息处理。

2、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述用户管理信息， 至少包括以下一种信息：

消息类型标识、 消息发送时间、终端标识、业务标识、节目标识、 终端是否在线的状态、 终端识别码、 用户标识信息以及频道标识， 所 述消息类型标识包括登录消息标识和注销消息标识。

3、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述对用户管理信息进行信息处理， 至少包括以下一种操作：

记录用户登录状态； 记录用户观看节目状态信息； 记录用户需要 更新的业务信息；

所述用户登录状态， 至少包括以下一种信息： 终端标识、 用户标 识、 业务订阅关系、 登陆时间、 登陆方式、 用户密钥的有效期；

所述用户观看节目状态信息， 至少包括以下一种信息： 用户观看 的节目标识、 用户观看的频道标识、 用户收看频道的开始时间、 用户 观看频道的退出时间；

所述用户需要更新的业务信息， 至少包括以下一种信息： 用户密 钥是否需要更新、 用户互动信息是否需要更新、 用户业务服务指南 SG是否需要更新。

4、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述对用户管理信息进行信息处理， 还包括：

获取频道节目的收看时间，所述频道节目的收看时间根据所述用 户管理信息中携带的消息发送时间获取； 或

根据向所述终端发送节目第一帧和最后一帧的时间获取。

5、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述对用户管理信息进行信息处理， 还包括：

获取频道或节目的收视率。

6、 如权利要求 5所述获取用户管理信息的方法， 其特征在于， 所述获取频道或节目的收视率， 具体包括：

对需要进行统计的频道或节目设置标识；

接收所述终端在接收或退出所述频道或节目的内容时发送的消 息；

根据所述消息获取频道或节目的收视率。

7、 如权利要 5所述获取用户管理信息的方法， 其特征在于， 所 述获取频道或节目的收视率， 具体包括：

向所有终端或特定的终端发送是否在收看特定频道或节目的消 息；

接收正在收看所述特定频道或节目的终端发送的响应消息； 根据所述响应消息获取频道或节目的收视率。

8、 如权利要求 1或 2所述获取用户管理信息的方法， 其特征在 于， 所述从消息中获取终端的用户管理信息之后， 还包括：

获取互动节目统计信息。

9、 如权利要求 8所述获取用户管理信息的方法， 其特征在于， 所述获取互动节目统计信息， 具体包括：

接收到所述终端发送的所述用户管理信息后，向所述终端发送互 动节目， 所述互动节目内容中包括互动信息和 /或互动更新信息； 接收所述终端发送的互动信息响应；

才艮据所述互动信息响应， 处理得到互动节目的统计信息。

10、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述接收终端发送的携带用户管理信息的消息， 具体包括：

接收所述终端在启动时、或切换所观看的节目或频道时发送的所 述用户管理信息。

11、 如权利要求 10所述获取用户管理信息的方法， 其特征在于， 所述从消息中获取终端的用户管理信息之后， 还包括： 根据所述终端在启动时、或切换所观看的节目或频道时发送的鉴 权请求， 发起对所述终端的鉴权。

12、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述从消息中获取终端的用户管理信息之后， 还包括：

向所述终端发送所述终端选择的节目内容；

判断所述终端接收所述节目内容超过预设时间时，发起对所述终 端的鉴权。

13、 如权利要求 1所述获取用户管理信息的方法， 其特征在于， 所述从消息中获取终端的用户管理信息之后， 还包括：

向所述终端提供 SG中包括的可选节目。

14、如权利要求 13所述获取用户管理信息的方法， 其特征在于， 所述向终端提供 SG中包括的可选节目后， 还包括：

接受所述终端对所述服务指南中包括的可选节目的订购或退订； 接收所述终端订购的节目发生变化时对终端订购节目信息的更 新。

15、 一种获取用户管理信息的系统， 其特征在于， 包括： 服务器， 用于接收终端发送的用户管理信息， 并保存所获取的所 述终端的用户管理信息；

终端， 用于向所述服务器发送用户管理信息。

16、如权利要求 15所述获取用户管理信息的系统， 其特征在于， 所述服务器进一步包括：

接收模块， 用于接收所述终端发送的用户管理信息；

统计模块，用于保存所述接收模块获取的所述终端的用户管理信 息。

17、如权利要求 15所述获取用户管理信息的系统， 其特征在于， 所述终端进一步包括：

用户管理信息发送模块，用于向所述服务器发送所述用户管理信 息。

18、 一种服务器， 用于获取用户管理信息， 其特征在于， 包括： 接收模块， 用于接收终端发送的用户管理信息； 统计模块，用于保存所述接收模块获取的所述终端的用户管理信 息。

19、 如权利要求 18所述服务器， 其特征在于， 还包括： 节目订购模块，用于接受所述终端对服务指南中包括的可选节目 的订购或退订，并根据订购或退订结果更新本地存储的终端订购节目 信息。

20、 如权利要求 18所述服务器， 其特征在于， 还包括： 鉴权模块， 用于对请求收看节目的终端进行鉴权。

21、 如权利要求 18所述服务器， 其特征在于， 还包括： 互动节目处理模块，用于进行互动节目中与所述终端的互动功能 的实现。

22、 一种终端， 用于向服务器发送用户管理信息， 其特征在于， 包括：

用户管理信息生成模块， 用于生成用户管理信息，

用户管理信息发送模块，用于将所述生成的用户管理信息以消息 形式发送。